Система и способ оптимизированного поиска снизу вверх



Система и способ оптимизированного поиска снизу вверх
Система и способ оптимизированного поиска снизу вверх
Система и способ оптимизированного поиска снизу вверх
Система и способ оптимизированного поиска снизу вверх
Система и способ оптимизированного поиска снизу вверх
Система и способ оптимизированного поиска снизу вверх
Система и способ оптимизированного поиска снизу вверх
Система и способ оптимизированного поиска снизу вверх
Система и способ оптимизированного поиска снизу вверх
Система и способ оптимизированного поиска снизу вверх
Система и способ оптимизированного поиска снизу вверх

 


Владельцы патента RU 2557761:

СИКС КОНТИНЕНТС ХОТЕЛС, ИНК. (US)

Изобретение относится к средствам поиска комнат гостиницы. Технический результат заключается в повышении эффективности поиска и достоверности результатов поиска. В способе: создают предварительно вычисленную базу данных, содержащую атрибуты доступности в реальном времени, связанные с комнатами гостиницы на множестве продолжительности остановок, прием запроса на наличие комнат, по меньшей мере, одной гостиницы для диапазона дат, определяют первый результат поиска из предварительно вычисленной базы данных, определяют второй результат поиска, полученный из другого источника, создают конечный результат поиска посредством объединения указанных результатов. Система реализует указанный способ. 3 н. и 18 з.п. ф-лы,8 ил.

 

УРОВЕНЬ ТЕХНИКИ

Существующие системы бронирования гостиницы и путешествия используют подход к поиску сверху вниз, создавая одиночные ячейки доступности, когда они находятся в результате поискового запроса. Например, такие системы могут позволять пользователю вводить критерий запроса, такой как, наименование гостиницы, дата прибытия и дата отбытия, чтобы находить доступные комнаты гостиницы на выбранное количество ночей (т.е. однократную продолжительность остановки). Только после обнаружения товарных единиц (т.е. комнат гостиницы), чтобы найти тарифы и доступность специальных наборов товарных единиц применяется бизнес-логика.

Этот известный в уровне техники подход имеет несколько недостатков. Из-за того, что этот подход выполняется сверхувниз, товарные единицы (например, продаваемые комнаты) необходимо искать и находить по каждому запросу. Дополнительно, запрос поиска должен иметь как минимум название/код гостиницы, дату прибытия и дату отбытия. Запрос доступности будет отклонен, если эти минимальные элементы не присутствуют в запросе.

Более того, ключевая услуга известного в уровне техники подхода позволяет обеспечивать за раз проверку только одной гостиницы, и при наличии того, что в запросе используются даты прибытия и отбытия, тарифы и ответ доступности, отражает только специальное количество ночей. Основной поиск не позволяет использовать альтернативные даты, и таким образом, не находить альтернативные тарифы.

Если выполняется поиск города (т.е. фокусирование поиска на одном городе), этот запрос разбивается на множественные поиски одиночных гостиниц, и каждый такой ключевой поиск гостиницы выполняется поочередно. Ключевая услуга поиска не распознает отношение между множественными гостиницами. Так как каждый ключевой запрос выполняется по одной гостинице, причем каждый запрос требует выполнения сложных бизнес-правил для нахождения тарифов и доступности, при этом стоимость времени и ресурсов CPU является высокой. Дополнительно, при наличии CPU- и ресурсоемкого свойства каждого запроса, время ответа может быть относительно медленным. Необходимость находить и вычислять тарифы и правила доступности для каждого запроса занимает время.

Также, в известных в уровне техники системах запрос является очень характерным для пользователя и не обеспечивает систему транзакции, чтобы помогать находить альтернативные типы товаров, например, различные типы комнат и т.д.

Возможно наибольшим недостатком существующего уровня техники является одиночная ячейка доступности.

Одиночная ячейка доступности получается из четко определенной продолжительности остановки (LOS) в поисковом запросе. LOS получается из начальной даты и конечной даты в поисковом запросе. Для множественных возможных совокупностей, которые могут быть получены из LOS в поисковом запросе, отсутствует видимость. Например, если запросчик желает также оценить различные опции в отношении LOS, он будет требовать несколько отдельных запросов поиска для каждой опции LOS. Известный уровень техники не обеспечивает гибкость альтернативных дат или единиц товара. Стоимость и время, требуемые для создания ответа с полной гибкостью, не экономичны в настоящее время. Например, если клиент желает проверить доступность для первой недели мая, потребуются 49 отдельных ячеек доступности. Семь ячеек доступности на каждый день недели (т.е. 7 дней X 7 значений LOS в день). Эта транзакция будет увеличивать стоимость в 48 раз (т.е. разницу между 1 запросом и 49 запросами), и будет приводить к очень большому времени ответа клиенту (т.е. плохой ориентированности на пользователя).

В связи с этим, существует необходимость в уровне техники улучшений систем транзакции гостиницы и путешествий, как описано дополнительно подробно ниже.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Сопровождающие чертежи, которые включены в и образуют часть этого описания, иллюстрируют варианты выполнения и вместе с описанием служат для объяснения принципов этих способов и систем:

Фиг.1А изображает схему системы бронирования гостиницы.

Фиг.1B изображает архитектуру базовых конструктивных блоков настоящего изобретения в одном варианте выполнения.

Фиг.2 изображает архитектуру настоящего изобретения в уже другом варианте выполнения.

Фиг.3 изображает схему последовательности высокого уровня, изображающую изобретение в одном варианте выполнения.

Фиг.4 представляет собой структурную блок-схему архитектуры для использования изобретением в одном варианте выполнения.

Фиг.5 представляет собой схему, изображающую различные калькуляторы, которые могут быть использованы настоящим изобретением в одном варианте выполнения.

Фиг.6 представляет собой UML образец, который может быть использован для калькуляторов маски.

Фиг.7 изображает этапы, которые могут быть пройдены настоящим изобретением в одном варианте выполнения.

ПОДРОБНОЕ ОПИСАНИЕ

До раскрытия и описания настоящих способов и систем должно быть понятно, что терминология, используемая здесь, предназначена для описания только особых вариантов выполнения и не предназначена для ограничения.

Как используется в описании и приложенной формуле изобретения, диапазоны могут быть выражены здесь как от "около" одного особого значения и/или до "около" другого особого значения. Когда упоминается такой диапазон, вариант выполнения может включать, например, только от одного особого значения и/или до другого особого значения. Подобным образом, когда применяется значения в качестве приближений, путем использования предыдущего выражения "около", будет понятно, что особое значение образует другой вариант выполнения. Будет дополнительно понятно, что предельные значения каждого из диапазонов важны и в отношении к другому предельному значению, и независимы от другого предельного значения.

"Дополнительный" или "дополнительно" значит, что, в дальнейшем описанный случай или обстоятельство может или не может возникать, и что описание включает примеры, где возникает указанный случай или обстоятельство, и примеры, где он не возникает.

Во всем описании и формуле изобретения этого описания слово "содержать" и варианты этого слова, например, "содержащий" и "содержит" означает "включающий, но без ограничения" и не предназначено для исключения, например, других добавлений, компонентов, чисел или этапов. Выражение "примерный" означает "пример" и не предназначено для передачи обозначения предпочтительного или идеального варианта выполнения. "Такой, как" не используется в ограничительном смысле, а используется в целях приведения примеров.

Здесь раскрываются компоненты, которые могут быть использованы для выполнения раскрытых способов и систем. Здесь раскрыты эти и другие компоненты, и понятно, что при раскрытии совокупностей, поднаборов, взаимосвязей, групп и т.д. этих компонентов, причем специальная ссылка каждой различной индивидуальной и объединенных совокупностей и их перестановки не может быть подробно раскрыта, каждый рассмотрен и описан здесь особым образом для всех способов и систем. Это применяется ко всем аспектам этой заявки, включая, но не ограничивая, этапы в раскрытых способах. Таким образом, Если имеется множество дополнительных этапов, которые могут быть выполнены, понятно, что каждый из этих дополнительных этапов может быть выполнен с любым специальным вариантом выполнения или совокупностью вариантов выполнения раскрытых способов.

Настоящие способы и системы могут быть понятны более ясно путем ссылки на следующее далее подробное описание предпочтительных вариантов выполнения и примеров, включенных в него, и на фигуры и им предшествующее, и следующее далее описание.

Настоящее изобретение обеспечивает улучшенную систему транзакции доступности комнат гостиницы. Фиг.1А изображает архитектуру системы бронирования гостиницы известного уровня техники; а именно системы HOLEDEX (HDX), предлагаемая Six Continents Hotels, Inc. для ее мировой сети гостиниц. Настоящее изобретение может быть использовано в сочетании с этой системой или любой другой пригодной системой бронирования гостиницы, доступной на рынке.

В системе бронирования на фиг.1А сервер HDX 101 хранит текущую доступность по датам, тарифам, а также другой подробной информации, касающейся комнат гостиницы. Различные клиенты 102а, 102b, 102c и 102d могут подавать запросы серверу HDX 101. Например, клиенты 102а могут содержать веб-сайты путешествий, связанные с сервером HDX 101 с помощью промежуточного центра 103 данных, использующего, например, протокол OTA или XML, чтобы связываться с сервером HDX 101. Клиенты 102b могут содержать глобальные системы распределения (GDS), например, Sabre, Galileo, WorldSpan, Amadeus или TravelWeb, использующие, например, протокол Pegasus, чтобы связываться с сервером HDX 101. Корпоративные собственники брендов гостиниц могут связываться с помощью клиентов 102c с сервером HDX посредством, например, протоколов 3270 или XML. Наконец, индивидуальные гостиницы 102d могут связываться с сервером HDX 101, используя, например, протокол XML и/или HMI.

Запросы поиска доступности, поданные клиентом (102а, 102b, 102c и/или 102d) в сервер HDX 101, могут включать как минимум код гостиницы, дату прибытия и дату отбытия. Так как поиск множественных гостиниц, множественных диапазонов данных и т.д., может обычно приводить к необходимости множественных поисков на сервере HDX 101, настоящее изобретение обеспечивает улучшенный путь выполнения поисков, как описано дополнительно ниже. Наибольшая трудность в сегодняшних средах (т.е. аппаратном обеспечении и сети) в каждом главном центре данных представляет собой огромный рост 60% трафика доступности каждый год. Наиболее эффективный процесс поиска представляет собой неустойчивый баланс между предварительно вычисленными данными и готовыми данными. Когда миллионы запросов поиска попадают в систему бронирования каждый день, накопление имеющейся части уже вычисленных данных доступности переводится в мощную систему транзакции доступности. Для определения того, как наиболее эффективно выполнять поиски на сервере HDX 101, процесс определения доступности размечается с возможностью распределения по категориям каждого этапа, основываясь на различных критериях. Тогда как распределение по категориям может принимать многие формы, в одном варианте выполнения может быть использованы следующие критерии из Таблицы А:

Таблица А
Критерий Метка
Процесс нахождения Каждый элемент доступности классифицируется (низкий-высокий), основываясь на количестве ячеек базы данных и логике, требуемой для нахождения товарной единицы, для запроса. Например, в одном варианте выполнения, классифицирование может быть следующим:
Гостиница = низкий
Категория тарифа = низкий
Торговая единица = высокий
Циклы обработки Каждый компонент бизнес-логики может быть классифицирован (низкий-высокий), основываясь на величине необходимого времени обработки. Например, в одном варианте выполнения классифицирование может быть следующим:
Закрыть для прибытия = низкий
Остановиться на несколько дней = средний
Чистый доход = высокий
Уровень доступности Каждый компонент бизнес-логики может быть связан с элементом доступности, который выполняет специальную бизнес-логику. Например, в одном варианте выполнения:
Чистый доход = товарная единица
Остановиться на несколько дней = категория тарифа

Как изображено на фиг.1B, настоящее изобретение включает PreCompute Availability Database 151 (База данных предварительно вычисленной доступности), а также Availability Rule Calculator Engine 152 (Механизм вычисления правил доступности). В одном варианте выполнения PreCompute Availability Database 151 может содержать относительную базу данных, которая имеет 2 главные характеристики:

• Каждая строка представляет наименьший возможный продаваемый блок (товарную единицу) за один день. Процесс обнаружения для обнаружения набора единиц товара в день не требуется. Каждая товарная единица в день может быть получена из категории тарифа высокого уровня, которая использует определение кода тарифа с помощью типов комнат, связанных с классом и доступностью диапазона дат.

• Размер таблицы должны быть управляемым. Таблица быстро обновляется и считывается. Количество элементов для каждой товарной единицы является само по себе выборочным для того, чтобы поддерживать минимальное количество элементов для предварительного вычисления в каждой строке.

Первичный код базы данных может быть образован с помощью: кода гостиницы, даты, типа комнаты и категории тарифа. Другие ключевые данные каждой строки могут представлять собой в одном варианте выполнения:

• Физическую продолжительность остановки (LOS). Это строковое значение представляет битовую маску для каждой ночи вплоть до остановки, например, на 14 дней (любая другая максимальная LOS может быть также выбрана). Физическая доступность типа комнаты может использовать представления о планировке, полном количестве комнат и пролете типа комнат дома. Эти правила могут применяться повторно для каждой ночи маски LOS.

• Величину тарифа. Величина тарифа может быть получена из кода тарифа, связанного с категорией тарифа товарной единицы. Значение этой величины может быть фиксированной величиной или процентным значением. В то же время, эта величина может быть найдена в уровне кода тарифа или из другого основного кода тарифа.

• Доход LOS. Это строковое значение может представлять битовую маску для каждой ночи вплоть до остановки, например, на 14 дней (или любую другую максимальную LOS). Компонент управления доходом может использовать вычисление чистого дохода, основываясь на LOS. Положительный доход может быть представлен открытым (1), а отрицательный доход может быть представлен закрытым (0). Может быть несколько опций дохода, которые могут указывать на использование другого значения, основываясь на другом тарифе или коррекциях. Эти правила могут применяться повторно для каждой ночи маски LOS.

• Код тарифа. Концепция паритета может использовать код тарифа для поддержания уровней отношения между всеми кодами тарифа.

Структура этой относительной базы данных создает очень быстрый путь получения единиц товара. Возможно соединять PreCompute Availability Database 151 с таблицами атрибутов для того, чтобы обеспечивать фильтры на этом начальном этапе. Некоторые из атрибутов, наподобие типа кровати, количества кроватей и/или максимальной вместимости могут в одном варианте выполнения помогать предварительно выбирать товарные единицы. Это отличается от известного уровня техники, который применяет фильтры в конце процесса определения доступности, что приводит к лишним циклам обработки на несоответствующих товарных единицах.

Значения, которые управляются с помощью LOS, могут использовать представление битовой маски. Каждый бит представляет ночь, и значения могут быть открытыми (1) или закрытыми (0). Здесь нет ограничений того, как долго LOS может представлять. Подходящее значение может соответствовать подходящей аудитории или бренду гостиницы. Например, в одном варианте выполнения бренды c продленным сроком пребывания могут иметь вплоть до 28 дней или больше предварительно вычисленных LOS.

Как показано на фиг.2, в одном варианте выполнения Availability Rule Calculator Engine 152 и PreCompute Availability Database 151 могут содержать предварительно вычисленную структуру, содержащую приложение J2EE 201, которое использует сообщения из Web Sphere MQ 202 и обрабатывает эти сообщения и обновляет базу данных Oracle 203 требуемыми данными. Эта структура может содержать приложение J2EE 201, которое может включать приложение Core Java 204. Фиг.2 изображает всю структуру с главными компонентами в каждом из приложений, согласно одному варианту выполнения настоящего изобретения. Другие пригодные структуры могут быть также использованы.

Фиг.3 представляет собой схему последовательности высокого уровня, которая изображает в общем ход обработки сообщений в PreCompute Engine на Фиг.1B и 2. Эта схема последовательности показывает сценарий, когда сообщения поступают в последовательность и сразу же обрабатываются. Фиг.4 представляет собой блок схему архитектуры структуры, которая изображает полную схему настоящего изобретения в одном варианте выполнения.

Компоненты структуры на Фиг.2-4 будут определены дополнительно подробно ниже.

• PreComputeMDBean 211 - PreComputeMDBean 211 представляет собой управляемый сообщениями компонент, который ожидает в очереди 411 последовательностей MQ 202, которая принимает сообщения из HOLEDEX 101. Он вызывает MessageManager 214, причем сообщение XML принимается из HOLIDEX 101.

• Stateless Session Beans 212: Могут быть использованы следующие компоненты 212 сеанса без запоминания состояния:

• BootStrapBean: используемый для запуска приложения. Log4j и другие ориентированные на Timer Task компоненты инициализируются здесь, когда приложение запускается.

• MessageManagerBean: Этот EJB используется для обработки сообщений для всех источников и клиентов. В основном, он может вызывать MessageManager 214 или продолжать его. Также этот компонент может вызываться с помощью MDB 211.

• Timer Beans 231 - Этот EJB использует Timer Service. Этот EJB используется для обработки сообщений, которые откладываются в таблице отложенных сообщений. Этот EJB работает в заданное время и вызывает MessageManager, блокирует любую гостиницу, которая имеет отложенные сообщения и обрабатывает сообщение. Важно обрабатывать результаты из Holidex последовательно. Выполнение кластерной среды (т.е. различные узлы могут получать обновления для одной и той же гостиницы в одно и то же время) требует выполнения этого способа обработки обновлений.

• Metric Manager 232 - Этот не сохраняющий данные компонент используется для сбора измерений в заданное время, используя Timer Service (сообщение каждый час). Он выполняет TimedObject. Этот EJB будет инициализироваться с помощью BootStrapBean при этом будет создаваться таймер.

• Data Clients 233 - компонент DataClients представляет собой одиночный компонент, который находится внутри PreCompute engine. Его роль является двойной. Во-первых, он обеспечивает специальную информацию, касающуюся того, как товарные единицы должны быть основаны на интересах Push-клиентов. И, во-вторых, он обеспечивает средство оповещения этих Push-клиентов об изменениях, как только они происходят.

Logging 234 - Log4J будут использоваться в качестве механизма регистрации данных для приложения. Зарегистрированные сообщения будут направляться в файл на сервер, на котором работает сервер приложения. Конфигурация для Log4j должна быть загружена, используя Bootstrap EJB или используя класс запуска в сервере приложения. Имеются различные уровни регистрации: отладка, информирование, предупреждение и ошибка.

MessageManager 214 - MessageManager 214 главным образом может выполнять две операции. Первая, он преобразует XML сообщение в объект Java, и далее, он может вызывать особый PreCompute Manager 216, основываясь на типе сообщения. Он также регулирует обработку последовательности сообщений, основываясь на коде гостиницы и последовательном номере сообщения. Если сообщения не находятся в последовательности, сообщение будут храниться в отдельной таблице для его обработки.

ManagerFactory 218 - класс Manager Factory 218 динамически создает PreComputeManagers 216, основываясь на типе сообщения. Как только он создает Manager, он может запоминать его для более позднего использования.

Классы XMLSchema Java - Эти классы XMLSchema Java могут быть частью Message Manager 214, и создаются, основываясь на XML сообщениях, принятых из HOLTDEX 101. Эти классы содержат значение XML элементов и атрибутов в их способе. Эти классы XML компонентов используются в качестве носителей данных, таким образом, исключая объект отдельного переноса данных для каждого сообщения.

PreComputeManager 216 - В одном варианте выполнения для каждого типа сообщения или для совокупности типов сообщения будет отдельный PreCompute Manager 216. Их основная функция заключается в преобразовании принятых объектов Java в требуемые области базы данных, используя определенную бизнес-логику и классы PreCompute. Большая часть обработки деловой информации происходит здесь и во вспомогательных классах.

• HotelLockUtil 220 - Этот класс используется для блокирования данных гостиницы в таблице сообщений House. Эти сообщения обрабатываются для гостиницы, как только запись блокируется. Необходимо блокировать гостиницу для того, чтобы обрабатывать сообщения в последовательном порядке и предотвращать условие состязания с другими сообщениями для той же гостиницы. Если сообщения записываются не по порядку, это будет делать недействительной всю базу данных.

• PendingMessageUtil - Этот класс используется для хранения, извлечения и удаления сообщений в таблице отложенных сообщений. Когда сообщения считываются из очереди MQ, используя кластерную среду, необходимо обрабатывать сообщения по очереди. Каждое сообщение гостиницы имеет последовательный номер для поддержания последовательного порядка обработки.

• Validation Classes 222 (Классы проверки достоверности) - В одном варианте выполнения имеются отдельные классы проверки для каждого сообщения. Эти классы проверки проверяют сообщения и, если они находят ошибки, они запускают PreComputeException.

• Data Access Objects (DAOs) 226 - Data Access Objects 226 отделяют операции связи и CRUD, относящихся к базе данных Oracle 203. PreCompute Manager 216 вызывает подходящий DAO 226 для обновления таблицы. DAO 226 может быть основан на одиночной таблице или основан на связанных таблицах. В основном этот DAO 226 достигает соединения с базой данных из класса 228 DBConnector, подготавливает заявки SQL в базу данных и выполняет операции CRUD. Как только эти операции выполняются, он разъединяет соединение с базой данных 203.

• DBConnector 228 - DBConnector 228 представляет собой класс Java, который выделяет механизм соединения для базы данных 203. В одном варианте выполнения он будет получать соединение с базой данных 203 вызовом объекта источника данных. Это класс будет иметь различные способы, такие как, разъединение соединения, откат транзакции и т.д.

• PreCompute Utility Components - Общая для всех функция, необходимая для приложения, может быть разработана в качестве вспомогательных классов, таких как, проверка даты или преобразование специальных данных, которые необходимы приложению. Могут иметься определенные вспомогательные классы, характерные для типов сообщений.

Availability Rule Calculator Engine 152 может включать логику, сгруппированную в две категории:

• Бизнес-логику, которая основана на значении даты прибытия поискового запроса, таким образом она не может быть предварительно вычислена. Пример такой логики будет представлять собой предварительно приобретенные ограничения.

• Бизнес-логику, которая была незначительно разделена во время обработки (основываясь на критерии, описанном ранее относительно Таблицы А), при этом она была связана с четко определенным элементом доступности.

Целевая задача заключается в разработке хорошего баланса между логиками PreCompute Availability Database 151 и Availability Rule Calculator Engine 152. Этот баланс может динамически регулироваться для поддержания высоких характеристик работоспособности. В случае, когда новая логика добавляется в модель доступности, это может преобразовывать подсчет в части элементов доступности, которые будут создавать новый баланс (т.е. золотую середину) между логиками PreCompute Availability Database 151 и Availability Rule Calculator Engine 152.

Availability Rule Calculator 152 управляет "активной" логикой процесса определения доступности. Бизнес-правила могут быть разделены на различные компоненты (т.е. калькуляторы доступности), таким образом, они могут быть выполнены независимо. Могут иметься определенные границы и ограничения, которые могут быть применены в реальном времени с каждым запросом. Например, они могут представлять атрибуты, которые гостиницы могут устанавливать для управления доступностью; например: предварительное приобретение, остановка на ночь, минимальная/максимальная остановка, специальные требования. Другие границы и ограничения могут обнаруживаться только на уровне гостиницы, уровне категории тарифа и уровне кода тарифа. Порядок того, как бизнес-правила применяются, может иметь непосредственное влияние во время цикла обработки.

Availability Rule Calculator engine 152 может иметь два главных компонента:

• Сборщик товарных единиц, организатор процесса определения доступности. Он использует CollectionOptions для установления того, какие правила и порядок правил будут применяться.

• Калькуляторы правил доступности. Каждый калькулятор (описанный дополнительно ниже относительно Фиг.5) осуществляет интерфейс MaskCalculator 507 и должен обеспечивать способ getMask(), который будет вызывать сборщик. Возвращенная маска логически умножается вместе с другими масками на текущую маску Productltems LOS, чтобы применять правило. Они также должны подавать код причины выполнением getReasonCode().

В одном варианте выполнения Availability Rule Calculator engine 152 может создаваться и работать, как описано дополнительно подробно ниже.

Модель классов

С внутренней стороны сборщик 502 совместно работает с несколькими компонентами "калькулятора" (507 и 601-606 на Фиг.6, описанными дополнительно ниже), причем каждому назначается особый класс правила продолжительностью остановки (LOS). В общем, каждый калькулятор возвращает битовую маску, которая логически умножается вместе с масками Productltem LOS, чтобы получить полную маску LOS.

Контекст сборки

Объект 503 CollectionContext используется для сохранения глобального состояния относительно цикла сборки. Когда посетитель взывает collect() на сборщике 502 (с помощью интерфейса 504 ProductltemCollector), сборщик 502 будет создавать объект 503 CollectionContext. CollectionContext 503 может иметь следующие характеристики:

• Код гостиницы

• Коды категорий тарифа

• Даты

• Объект базы данных

• Опции сборки

• Запомненные факты

CollectionContext 503 переводят в конструктор для каждого калькулятора. Конструктор задает среду каждого калькулятора, и представляет собой компонент программного обеспечения этого класса. Калькуляторы используют CollectionContext 503, чтобы получать базу данных 203 для выполнения запроса таблиц CRS. Они также используют его, чтобы делиться фактами друг с другом посредством объекта контекста. Например, Если гостиница обнаружена гостиницей HIRO, тогда этот факт может быть важным для более, чем одного калькулятора.

Калькуляторы

Калькуляторы (601-606) являются ключевыми компонентами бизнес-логики для PACE engine (механизма РАСЕ). CollectionStrategy 505 определяет, какие калькуляторы использовать, основываясь на том, что было установлено в опциях сборки 506. Каждый калькулятор осуществляет инерфейс MaskCalculator 507 и должен обеспечивать способ getMask(), который будет вызывать сборщика 502. Возвращенная маска логически умножается вместе с другими масками на текущую маску Productltems LOS, чтобы применять правило. Код причины также может быть предоставлен выполнением, например, getReasonCode().

Образцовый интерфейс для MaskCalculator 507 может быть:

Может иметься любое количество MaskCalculator 507. Фиг.6 изображает пример для текущей установки. В одном варианте выполнения калькуляторы могут содержать очень специфичные правила границ или ограничений модели доступности IHG, такие как:

• Arrival Calculator 601 - Он использует день прибытия запроса проверки, установлена ли в гостинице недоступная дата или закрытая для прибытия, или уровня категории тарифа.

• MinMax Calculator 602 - Он использует дату прибытия и дату отбытия для получения LOS. Значение LOS должно удовлетворять минимальному и максимальному количеству дней ограничения остановки, если оно существует.

• Revenue Calculator 603 - Он проверяет, что LOS для специальной величины тарифа создает положительный доход.

• RoomSS Calculator 604 - Он проверяет, что специальный тип комнаты связан со стратегией продажи комнат гостиницы. Стратегия продаж комнат гостиницы указывает типы комнат, которые видны для продажи.

• StayoverDays Calculator 605 - Он использует дату прибытия и дату отбытия для получения LOS. Значение LOS должно удовлетворять дням недели, на которые требуется остаться на ночь.

• Active Days Calculator 606 - Он использует дату прибытия и дату отбытия для получения LOS. Значение LOS должно удовлетворять дням недели, которые помечены активными.

Запас правил гостиницы

Предпочтительно иметь PACE engine, являющийся максимальной эффективным. На фиг.5 и 6 большая часть этого может ложиться на выполнение нескольких MaskCalculator 507, так как они включают правила гостиницы, зашифрованные в базе данных CRS. Каждый раз PACE engine создает новый MaskCalculator 507, причем Calculator 507 может оптимизировать себя предварительно выбирая данные, которые ему необходимы только один раз, из базы данных 203, и далее используя их повторно для каждого применения способа getMask(). Тем не менее, наличие запроса базы данных всеми калькуляторами для правил, которые редко изменяются, значительно влияет на работоспособность, и должно быть исключено.

Чтобы предусмотреть это, объект 503 CollectionContext (фиг.5) может включать возможность обеспечения запоминания правил для нескольких MaskCalculator 507. Как только MaskCalculator 507 создаст свои правила из базы данных 203, он может запоминать их на CollectionContext 503. Это, в свою очередь, означает, что все MaskCalculator 507 могут сначала выяснять, присутствуют ли еще необходимые правила до достижения базы данных 203 и создания правил заново. Эта модель будет способствовать увеличению работоспособности, и в связи с этим, может быть использована во всех возможных случаях.

Вот как способы могут выглядеть для запоминания правил:

После того, как MaskCalculator 507 запоминает правила, правила могут оставаться в памяти до тех пор, пока не возникнет один из следующих случаев:

• изменение правил гостиницы в базе данных 203

• память LRU стирает правила гостиницы для управления ресурсами

• приложение перезапускается

В одном варианте выполнения каждый из нескольких MaskCalculator 507 может делать попытки использовать способы запоминания и проверять их надежность. Если пригодное решение для управления запоминанием-изменением не доступно, тогда PACE engine может обеспечивать, что запоминание не активируется. Все же, несколько MaskCalculator 507 могут выполнять активацию запоминания в любое время.

Стратегии сборки

Так как PACE engine может быть использован в различных целях, одиночный алгоритм поиска для всех случаев не подходит. Например, запросы доступности из приложения Pull могут смотреть на ограничения более высоких уровней первыми и товарные единицы последними, при этом приложение Push может хотеть смотреть на товарные единицы первыми и применять правила в наиболее эффективном порядке.

Чтобы предусмотреть это, PACE engine может использовать интерфейс CollectionStrategy 505, чтобы представлять, как действительно выполняется сборка. Это в основном представляет собой выполнение шаблона разработки Abstract Algorithm, известного специалистам в области техники. Выбор стратегии может быть основан на установках в CollectionOptions 506.

Образцовый интерфейс для CollectionStrategy 505 обеспечен ниже:

В одном варианте выполнения поддержанные CollectionStrategie 505 могут включать:

Класс Описание
Основная стратегия Абстрактный класс с основным шаблонным способом вычисления
Стратегия по умолчанию Продолжает основную стратегию с критерием SQL для кодов категорий тарифов
Стратегия ID торговых единиц Продолжает основную стратегию с критерием SQL для id торговых единиц

Запросы

Когда PACE engine вызывается, d конечном итоге, он может считывать товарные единицы из таблицы товарных единиц и применять MaskCalculator 507, чтобы получать конечную LOS. Запрос, используемый для выбора товарных единиц? может учитывать нескольких факторов. Они включают:

• Критерий выбора

• Историю LOS

• Исключения прямых продаж

Секции ниже описывают эти аспекты для запроса более подробно.

• Базовый запрос

• История LOS

• Исключения прямых продаж

(1) Базовый запрос

Базовый запрос представляет наиболее простую форму SQL, которая выбирает товарные единицы. В действительности, действующий SQL не может быть использован. Но он описывается, так как он может служить в качестве базы для других полностью образованных запросов. Другими словами, для понимания всех запросов, важно понимание базового запроса.

Критерий для базового запроса включает следующее:

• Код гостиницы

• Диапазон дат

• Коды категорий тарифа

• Действующий статус

• Принятое изменение (дополнительно)

• Исключенные коды комнат (дополнительно)

• ID товарных единиц (дополнительно)

"Действующий статус" предназначен только для пропускания строк Product Item (товарная единица). Принятое изменившие используется для выбора строк с принятым значением, равным или большим специализированного значения. Типы исключенных комнат используются для фильтрования исключенных комнат. Наконец, последний из ID товарных единиц может быть включен вместо принятого изменения для более точного выбора товарных единиц.

Значение маркера и ID товарных единиц используются для содействия фильтрованию только тех товарных единиц, которые действительно преобразованы с помощью PreCompute. В то время, как имеются различные пути, которые могут быть использованы для наилучшего указания, когда и почему изменяются товарные единицы для PreCompute, причем принятое количество плюс ID товарных единиц могут быть использованы в одном варианте выполнения.

Порядок, при котором товарные единицы подаются в ProductltemConsumer важен по двум причинам. Первая, он позволяет нескольким Calculator 507 (Калькуляторам) эффективно вести себя в контекстном переключении. Вторая, он позволяет нескольким ProductltemConsumer просто получать результаты их создания.

В связи с этим, результаты могут быть упорядочены следующим образом:

• Дата

• Код категории тарифа

• Код комнаты

Основываясь на вышеприведенных идеях и со ссылкой на Фиг.7 в одном варианте выполнения настоящее изобретение может выполнять этапы, на которых:

• создают предварительно вычисленную базу данных, содержащую атрибуты доступности в реальном времени, связанные с комнатами гостиницы на множестве продолжительности остановок (этап 701);

• принимают запрос для, по меньшей мере, одной гостиницы на диапазоне дат, причем диапазон дат имеет начальную дату и конечную дату (этап 702);

• вычисляют доступность для каждого дня в пределах диапазона дат на множестве продолжительности остановок применением бизнес-требований согласно запросу (этап 703);

• создают конечную доступность для каждого дня в пределах диапазона дат на множестве продолжительности остановок объединением доступности из предварительно вычисленной базы данных и атрибутов запроса (этап 704); и

• образуют конечную доступность комнат гостиницы для по меньшей мере одной гостиницы для каждого дня в пределах диапазона дат на множестве продолжительности остановок (этап 705).

В то время, как способы и системы описаны в связи с предпочтительными вариантами выполнения и специальными примерами, не предполагается, что объем охраны ограничивается изложенными особыми вариантами выполнения, так как здесь варианты выполнения предназначены во всех отношениях для иллюстрации, а не ограничения.

Кроме тех случаев, когда изложено иначе, никоим образом не предполагается, что любой способ, изложенный здесь, подразумевается как требующий, чтобы его этапы выполнялись в специальном порядке. Соответственно, где пункт формулы изобретения на способ в действительности не описывает порядок, устанавливаемый его этапами, или, иначе, особым образом не устанавливает в формуле изобретения или описании, что этапы ограничиваются специальным порядком, никоим образом не предполагается, что порядок принимается в любом отношении. Это справедливо для любой возможной неясной основы для интерпретации, включающей: сущность логики относительно порядка этапов или рабочего хода; понятное значение, полученное из грамматической организации или пунктуации; количество или тип вариантов выполнения, описанных в описании.

Для специалиста в области техники будет ясно, что различные преобразования и варианты могут быть выполнены без отклонения от объема охраны или замысла изобретения. Другие варианты выполнения будут ясны специалисту в области техники из рассмотрения описания и практики, раскрытых здесь. Предполагается, что описание и примеры рассматриваются только в качестве примера с правильным объемом охраны и замыслом, определенным следующей далее формулой изобретения.

1. Способ улучшения поисков в базе данных посредством баланса между предварительно вычисленными данными и готовыми данными, содержащий этапы, на которых:
создают, посредством компьютерной системы, предварительно вычисленную базу данных, содержащую данные, вычисленные до приема запроса к предварительно вычисленной базе данных, причем данные содержат атрибуты доступности в реальном времени, ассоциированные с комнатами гостиницы, по множеству длительностей пребывания;
принимают, посредством компьютерной системы, запрос к предварительно вычисленной базе данных, причем запрос содержит запрашивание для по меньшей мере одной гостиницы в диапазоне дат, причем диапазон дат имеет начальную дату и конечную дату;
определяют, посредством компьютерной системы, первый результат поиска из предварительно вычисленной базы данных, основываясь на запросе, причем первый результат поиска содержит первую доступность, ассоциированную с по меньшей мере одной из множества длительностей пребывания;
вычисляют, посредством компьютерной системы, основываясь на запросе и на требованиях, второй результат поиска, причем второй результат поиска вычислен из источника, отличного от предварительно вычисленной базы, причем второй результат поиска содержит доступность для каждого дня в пределах диапазона дат по множеству длительностей пребывания, причем требования содержат требование установления времени обработки для вычисления второго
результата поиска;
создают, посредством компьютерной системы, конечный результат посредством объединения первого результата поиска и второго результата поиска, причем конечный результат содержит конечную доступность для каждого дня в пределах диапазона дат по множеству длительностей пребывания; и
формируют, посредством компьютерной системы, конечный результат, причем этап формирования содержит формирование конечной доступности комнат гостиницы для по меньшей мере одной гостиницы для каждого дня в пределах диапазона дат по множеству длительностей пребывания.

2. Способ по п. 1, в котором создание конечной доступности для каждого дня в пределах диапазона дат по множеству длительностей пребывания включает в себя использование битовой маски для представления длительности пребывания, причем каждый бит представляет день в длительности пребывания.

3. Способ по п. 1, в котором запрос принимают от веб-сайта организации путешествий.

4. Способ по п. 1, в котором запрос принимают от клиента.

5. Способ по п. 1, в котором этап вычисления выполняют с правилом границ.

6. Способ по п. 1, в котором этап вычисления выполняют с правилом ограничения.

7. Способ по п. 1, дополнительно содержащий этап передачи конечной доступности комнат гостиницы на веб-сайт организации путешествий.

8. Способ по п. 1, дополнительно содержащий этап передачи конечной доступности комнат гостиницы клиенту.

9. Способ по п. 1, в котором создание конечной доступности для каждого дня в пределах диапазона дат включает в себя объединение предварительно вычисленных данных, ассоциированных с первой доступностью из предварительно вычисленной базы данных, и динамически вычисленных данных, ассоциированных со второй доступностью.

10. Способ по п. 9, дополнительно содержащий регулирование отношения между предварительно вычисленными данными и динамически вычисленными данными.

11. Способ по п. 10, в котором регулирование отношения между предварительно вычисленными данными и динамически вычисленными данными основано, по меньшей мере частично, на времени обработки по меньшей мере одного из одного или более требований, основанных на времени обработки.

12. Способ по п. 1, дополнительно содержащий:
категоризацию множества этапов процесса запроса доступности во множество категорий, причем процесс запроса доступности обрабатывает запрос для вывода конечной доступности комнат гостиницы;
ассоциирование множества оценок с множеством категорий, причем каждая оценка основана, по меньшей мере частично, на комбинации обращений к базе данных, логики процесса нахождения и времени обработки;
перед приемом запроса, выполнение этапа из множества этапов, основываясь, по меньшей мере частично, на соответствующей оценке этого этапа, для генерации данных предварительно вычисленной базы данных; и
если логика добавляется к процессу запроса доступности, обновление оценок, ассоциированных с множеством категорий, и определение, должен ли этап выполняться после приема запроса, основываясь, по меньшей мере частично, на обновленных оценках.

13. Система улучшения поисков в базе данных посредством баланса между предварительно вычисленными данными и готовыми данными, содержащая:
один или более процессоров;
память, включающую в себя исполняемые инструкции, которые, при исполнении одним или более процессорами, побуждают систему по меньшей мере:
создавать предварительно вычисленную базу данных, содержащую данные, вычисленные до приема запроса к предварительно вычисленной базе данных, причем данные содержат атрибуты доступности в реальном времени, ассоциированные с комнатами гостиницы, по множеству длительностей пребывания;
принимать запрос к предварительно вычисленной базе данных, причем запрос содержит запрашивание для по меньшей мере одной гостиницы в диапазоне дат, причем диапазон дат имеет начальную дату и конечную дату;
определять первый результат поиска из предварительно вычисленной базы данных, основываясь на запросе, причем первый результат поиска содержит первую доступность, ассоциированную с по меньшей мере одной из множества длительностей пребывания;
вычислять, основываясь на запросе и на требованиях, второй результат поиска, причем второй результат поиска вычислен из источника, отличного от предварительно вычисленной базы, причем второй результат поиска содержит доступность для каждого дня в пределах диапазона дат по множеству длительностей пребывания, причем требования содержат требование установления времени обработки для вычисления второго результата поиска;
создавать конечный результат посредством объединения первого результата поиска и второго результата поиска, причем конечный результат содержит конечную доступность для каждого дня в пределах диапазона дат по множеству длительностей пребывания; и
формировать конечный результат, причем формирование содержит формирование конечной доступности комнат гостиницы для по меньшей мере одной гостиницы для каждого дня в пределах диапазона дат по множеству длительностей пребывания.

14. Система по п. 13, в которой создание предварительно вычисленной базы данных, содержащей атрибуты доступности в реальном времени, ассоциированные с комнатами гостиницы, по множеству длительностей пребывания включает в себя использование битовой маски для представления длительности пребывания, причем каждый бит представляет день в длительности пребывания.

15. Система по п. 13, в которой запрос принимается от вебсайта для организации путешествий.

16. Система по п. 13, в которой запрос принимается от клиента.

17. Система по п. 13, в которой вычисление второй доступности для каждого дня включает использование правила границ.

18. Система по п. 13, в которой вычисление второй доступности для каждого дня включает использование правила ограничений.

19. Система по п. 13, в которой упомянутые инструкции дополнительно побуждают один или более процессоров совместно передавать конечную доступность комнат гостиницы на веб-сайт организации путешествий.

20. Система по п. 13, в которой упомянутые инструкции дополнительно побуждают один или более процессоров совместно передавать конечную доступность комнат гостиницы клиенту.

21. Считываемый компьютером носитель, содержащий считываемый компьютером программный код, сохраненный на нем, причем считываемый компьютером программный код, при исполнении, обеспечивает выполнение способа улучшения поисков в базе данных посредством баланса между предварительно вычисленными данными и готовыми данными, содержащего:
создание предварительно вычисленной базы данных, содержащей данные, вычисленные до приема запроса к предварительно вычисленной базе данных, причем данные содержат атрибуты доступности в реальном времени, ассоциированные с комнатами гостиницы по множеству длительностей пребывания;
прием запроса к предварительно вычисленной базе данных, причем запрос содержит запрашивание для по меньшей мере одной гостиницы в диапазоне дат, причем диапазон дат имеет начальную дату и конечную дату;
определение первого результата поиска из предварительно вычисленной базы данных, основываясь на запросе, причем первый результат поиска содержит первую доступность, ассоциированную с по меньшей мере одной из множества длительностей пребывания;
вычисление, основываясь на запросе и на требованиях, второго результата поиска, причем второй результат поиска вычислен из источника, отличного от предварительно вычисленной базы, причем второй результат поиска содержит доступность для каждого дня в пределах диапазона дат по множеству длительностей пребывания, причем требования содержат требование установления времени обработки для вычисления второго результата поиска;
создание конечного результата посредством объединения первого результата поиска и второго результата поиска, причем конечный результат содержит конечную доступность для каждого дня в пределах диапазона дат на множестве длительностей пребывания; и
формирование конечного результата, причем формирование содержит формирование конечной доступности комнат гостиницы для по меньшей мере одной гостиницы для каждого дня в пределах диапазона дат по множеству длительностей пребывания.



 

Похожие патенты:

Изобретение относится к области медицины. Техническим результатом является повышение точности эпидемиологического районирования.

Изобретение относится к области городского водопровода и канализации и предназначено для определения показателей надежности и бесперебойности сетей водоснабжения и водоотведения.

Изобретение относится к устройству, способам и компьютеру для аутентификации потребителя и проведения платежной транзакции. Технический результат заключается в повышении скорости проведения платежной транзакции.

Изобретение относится к устройствам медицинского мониторинга. Техническим результатом является обеспечение управления временным согласованием синхронизации.

Изобретение относится к компьютерной технике, а именно к системам интеллектуальных автоматизированных помощников. Техническим результатом является повышение точности представления пользователю релевантной информации за счет учета параметров задачи, логически выведенных из контекстной информации.
Изобретение относится к вычислительной технике. Технический результат заключается в подтверждении факта отправки документа или файла с указанием даты и времени отправки по электронной почте.

Изобретение относится к обеспечению безопасности проведения операций в платежных системах с использованием банковских карт. Технический результат заключается в уменьшении риска осуществления несанкционированных держателем карты операций по карте в случае ее компрометации.

Изобретение относится к формированию и эксплуатации базы данных информации о вакансиях и кадровых ресурсах. Техническим результатом является повышение быстродействия поиска при ранжировании данных о кадрах или вакансиях.

Изобретение относится к области оптимизации выбора и доставки продуктов в сети. Технический результат - оптимизация выбора продукта или услуги в отношении требований клиентов и обеспечение динамической интеграции этих требований.

Изобретение относится к компьютерной технике. Технический результат - автоматизированное управление климатом на ограниченной территории.

Изобретение относится к области компьютерной медицины. Предложен способ поддержки принятия клинического решения, где в компьютерный механизм принятия решений вводят данные, указывающие группу носителей аллергена и значения носителя аллергена, которые получают путем количественного определения антител IgE в биологической жидкости; идентификации носителей с помощью предварительно определенной структуры, представляющей известные взаимосвязи между антителами IgE и носителями аллергена, где по меньшей мере один носитель аллергена ассоциирован с множеством антител IgE; и присваивания значений носителям аллергенов на основании результатов теста антител IgE. Также рассмотрены машиночитаемый носитель, включающий инструкции, предписывающие выполнение компьютером способа по изобретению, и система поддержки принятия клинического решения. Данное изобретение позволяет уменьшить сложность механизма принятия решений за счет сокращения количества данных, вводимых в механизм принятия решений, и может найти применение в диагностике аллергий и других заболеваний. 3 н. и 11 з.п. ф-лы, 8 ил., 3 табл., 9 пр.

Изобретение относится к медицинской технике, а именно к средствам коррекции зрения пациентам. Устройство для удаленной коррекции зрения содержит компьютерный процессор, находящийся в связи с устройством хранения данных, и передатчик, один или более инструментов измерения зрения, способных измерять данные характеристик глаза пациента и связанных с процессором. В устройстве хранения данных хранятся инструкции, побуждающие процессор получать данные о пациенте, получать данные, описывающие характеристики глаза пациента, связываться по сети связи с удаленным практикующим врачом по наблюдению за зрением, определять, требуется ли коррекция зрения, генерировать средства коррекции зрения, генерировать или отображать одно или более моделирований зрения на основании сгенерированных средств коррекции зрения, генерировать и отображать одно или более моделирований внешнего вида пациента, носящего генерированные средства коррекции зрения. Использование изобретения позволяет повысить точность подбора контактных линз или очков. 17 з.п. ф-лы, 4 ил.

Изобретение относится к области городского водопровода и канализации и предназначено для определения и обеспечения показателей надежности и бесперебойности сетей водоснабжения и водоотведения. Технический результат - расширение области применения устройства, при котором его можно будет применять не только для оценки показателей аварийности отдельных участков сетей, но и вероятностных показателей надежности всей сети в целом. Система для определения и обеспечения показателей надежности и бесперебойности сетей водоснабжения и водоотведения содержит блок первичной обработки информации, блок расчета показателей надежности элементов сети, блок определения вероятностных показателей надежности сети, блок определения технологических показателей надежности сети водоотведения, блок оптимизации показателей надежности сети. 29 з.п. ф-лы, 4 ил.

Изобретение относится к области добавления адреса гиперссылки в закладку. Технический результат - упрощение доступа, поиска и хранения web-контента. Способ управления закладками содержит этапы, на которых: принимают ввод, указывающий, что пользователь выбрал часть документа; если принятый ввод указывает, что пользователь выбрал функцию добавления закладки, отображают меню добавления закладки в качестве всплывающего окна в документе посредством выполнения этапов, на которых: анализируют все гиперссылки, содержащиеся в выбранной части документа; извлекают по меньшей мере один адрес из каждой из всех проанализированных гиперссылок; добавляют все извлеченные адреса в закладку; и отображают представление закладки и добавленные в нее извлеченные адреса в меню добавления закладки. 2 н. и 16 з.п. ф-лы, 10 ил.

Изобретение относится к области распределения активов устройств беспроводной связи. Техническим результатом является повышение эффективности распределения активов устройств беспроводной связи. Способ содержит: обеспечение варианта выбора распределения для множества беспроводных устройств, чтобы участвовать в распределении одного или более активов беспроводных устройств, при этом вариант выбора распределения обеспечивает пользователям беспроводного устройства возможность идентификации одного или более условий в качестве предисловия к распределению активов беспроводных устройств; прием от беспроводного устройства приемлемости варианта выбора распределения, включающей в себя идентификацию по меньшей мере одного актива беспроводного устройства, подлежащего распределению в соответствии с по меньшей мере одним условием из одного или более условий, проведение аукциона в отношении по меньшей мере одного актива беспроводного устройства с упомянутым по меньшей мере одним условием, действующим в качестве по меньшей мере одного ограничивающего условия предложения цены, налагаемого на аукцион. 5 н. и 11 з.п. ф-лы, 8 ил.

Изобретение относится к области управления прикладной программой оплаты, установленной на мобильном устройстве, таком как мобильный телефон. Техническим результатом является обеспечение защиты от мошеннического использования прикладной программы оплаты в ситуациях, в которых мобильное устройство потеряно или украдено. Эмитент устройства оплаты может удаленно управлять прикладной программой оплаты, давая команду оператору беспроводной сети передать сообщение на мобильный телефон, причем сообщение содержит команду для выполнения операции, связанной с прикладной программой оплаты. Эмитент может удаленно сбросить счетчик или пароль, ассоциированный с прикладной программой оплаты, блокировать или разблокировать прикладную программу оплаты и установить данные управления доступом равными предварительно определенному значению, предотвратить неавторизованное использование прикладной программы оплаты в ситуации, в которой мобильный телефон потерян или украден или эмитент желает ограничить доступ к прикладной программе оплаты по другим причинам, таким как ограничение его подверженности к неавторизованному использованию устройства оплаты. 6 н. и 9 з.п. ф-лы, 13 ил.

Изобретение относится к системам обработки информации в топливно-энергетическом комплексе (ТЭК). Техническим результатом является повышение эффективности анализа и обработки информации за счет виртуального моделирования экономических и техногенных процессов программным и математическим обеспечением с использованием информации по экономическому и техногенному состоянию объектов ТЭК от множества локальных систем мониторинга. Предложена система анализа и обработки информации в топливно-энергетическом комплексе. Система содержит центр мониторинга, включающий средства коммуникаций, системное программное и прикладное программное обеспечения, базы мета- и геопространственных данных, средства отображения и документирования, сервер архива базы данных локальных систем мониторинга и множество локальных систем мониторинга. Система также включает в себя центр управления топливно-экономическим комплексом с блоком выбора оптимального решения, центром анализа и обработки информации полученных результатов моделирования экономических и техногенных процессов в системе топливно-энергетического комплекса с расположенным в нем блоком виртуального моделирования с различными программным и математическим обеспечением экономических и техногенных процессов. 1 ил.

Изобретение относится к средствам обработки аутентификации удаленной переменной. Технический результат повышает защищенность данных в каналах аутентификации. Субъект-отправитель инициирует по каналу инициирования удаленный платеж с использованием альтернативного имени. Альтернативное имя может быть связано с одним или более псевдонимами, которые идентифицируют портативные устройства потребителя, и метаданными. Метаданные описывают, какие каналы доступны для аутентификации. Субъект-отправитель выбирает псевдоним и соответствующий канал аутентификации. Субъект-отправитель аутентифицируется у эмитента по выбранному каналу аутентификации. 4 н. и 16 з.п. ф-лы, 7 ил.

Изобретение относится к установлению соответствия стандартных измерений локальным измерениям. Техническим результатом является повышение надежности при формировании данных о пациенте. Система и способ включают в себя этапы, на которых считывают структурированный отчет, сопоставляют измерения структурированного отчета с соответствующими локальными измерениями из базы данных локальных измерений и вырабатывают сводную страницу, включающую в себя измерения структурированного отчета, сопоставленные с соответствующими локальными измерениями посредством файлов соответствия, и дополнительно включающую в себя несопоставленные измерения структурированного отчета, которые не могут быть сопоставлены с соответствующими локальными измерениями посредством файлов соответствия, отображают сводную страницу. 3 н. и 4 з.п. ф-лы, 9 ил.

Изобретение относится к области рекламы и вычислительной техники. Достигаемый технический результат - оптимизация процесса размещения массива рекламных роликов в сетях плазменных экранов с выполнением всех заданных условий размещения и минимизации штрафа за недоборы планов сплитов роликов и неравномерность их размещения. Способ включает в себя этапы: предварительно выделяют и фиксируют для каждого ролика заданные условия размещения ролика в виде сплита, а также условия формирования массива сплитов роликов; сортируют сплиты роликов по приоритету и создают соответствующий условиям формирования массив сплитов роликов для оптимального размещения в доступных объемах размещения; размещают минимальные квоты сплитов роликов инвентарных групп рекламы в рекламных блоках каналов плазменных экранов; разделяют массив сплитов роликов на 2-мерный массив по одинаковым приоритетам сплитов; размещают сплиты роликов с положительным приоритетом и компенсируют недобор сплитов по регионам; размещают сплиты роликов с отрицательным приоритетом и компенсируют недобор сплитов по регионам; производят минимизацию остатков неиспользованных доступных объемов размещения и формируют выходные массивы роликов для размещения в сетях плазменных экранов; размещают выходные массивы роликов в рекламных блоках по каналам плазменных экранов соответствующих сетей. 1 з.п. ф-лы, 4 ил.
Наверх