Область техники, к которой относится изобретение
Настоящее изобретение относится к области телекоммуникации. Более конкретно, настоящее изобретение относится к системе и способу оформления заказа (резервирования) в системе приема заказов и синхронизации приема заказов в нескольких системах приема заказов с участием, по меньшей мере, одного провайдера (поставщика) услуг (сервиса), службы-посредника, клиента и, по меньшей мере, одного терминального клиентского устройства, которое может являться мобильным устройством и которое поддерживает диалог. Кроме того, система по изобретению содержит линии телекоммуникации, которые используются для связывания систем приема заказов, провайдеров услуг, посредника и терминального клиентского устройства.
Уровень техники
Объем услуг (сервисов), которые заказываются или используются через Интернет, постоянно возрастает. Интернет обеспечивает возможность использовать в онлайновом режиме различные сервисы, включая различные банковские услуги, услуги в области здравоохранения, услуги турагентств, обслуживание автомобилей и др.
Растущая популярность мобильных компьютерных и коммуникационных устройств выдвигает новые требования к услугам, предоставляемым через Интернет. Мобильные терминалы способны доводить информацию до пользователей, когда это необходимо и где это необходимо. Пользователи хотят иметь повсеместный доступ к информации и к различным приложениям с устройства, которое у них имеется. Кроме того, они хотят иметь этот доступ и возможность обновления информации из любого места, в котором они могут оказаться.
Однако в этой связи следует отметить, что не все терминалы будут мобильными. Сервисы будущего должны быть способны вступать в коммуникацию с весьма разнообразными терминальными устройствами, как мобильными, так и стационарными. При этом различные терминальные устройства обладают весьма различными возможностями.
Возможность взаимодействия различных сервисов и терминальных устройств требует наличия стандартов на нескольких уровнях. Недостаточно, в частности, иметь только общие коммуникационные протоколы.
Весьма важным представляется наличие общих концепций и понимания того, что именно означает определенный набор данных в определенном контексте. Однако достичь соглашения по данным аспектам оказалось очень сложно из-за наличия в интересующей области огромного количества различных фирм, организаций и других действующих лиц.
Возможность осуществлять прием заказов является необходимой для многих сервисов. В этой связи можно указать осуществление предварительной записи на услуги в области здравоохранения, оформление заказов (в рамках туристических услуг) на гостиницы, авиабилеты и прокат автомобилей; бронирование билетов на различные мероприятия; оформление предварительных заказов на обслуживание автомобиля; оформление предварительных заказов на обслуживание квартиры и т.д. Было бы весьма полезным, если бы перечисленные сервисы могли получать информацию друг от друга. Например, если пользователь заказывает билет на концерт, он может захотеть заказать также и столик в ресторане. В этой связи службе резервирования мест в ресторане было бы удобно получить соответствующую информацию (например, дату и имя заказчика) от системы приема заказов на театральные билеты. К сожалению, способы обмена информацией между различными системами приема заказов (резервирования) пока не разработаны.
В принципе может иметься множество способов обмена информацией между различными сервисами. Применительно к услугам, которые включают прием заказа или календарные функции, обмен информацией часто принимает форму синхронизации заказов или ввода календарной информации. В этой связи реализуется несколько серьезных инициатив по стадартизации. Например, по инициативе промышленности осуществляется разработка и продвижение проекта SyncML в качестве единственного, общего протокола синхронизации данных.
vCalendar представляет собой формат обмена информацией персонального планирования. Он применим к широкому набору продуктов, связанных с календарными функциями и составлением расписаний, и является полезным при обмене информацией между широким набором методов переноса информации. Данный формат принят значительным количеством поставщиков, поскольку он дает возможность их продуктам обмениваться календарной и плановой информацией. vCalendar - это открытая спецификация, основанная на промышленных стандартах, таких как х/Open и ХАР1А Calendaring and Scheduling API (CSA), а также международный стандарт ISO 8601 в отношении указания даты и времени и взаимосвязанные стандарты MIME в отношении электронной почты. Формат vCalendar использует данные, которые обычно записываются в рамках приложения, связанного с календарем или планированием, облегчая тем самым обмен информацией о таких предметах, как события и пункты плана, между различными платформами. Под событием понимается запись в календаре или в плане о некотором мероприятии, занимающем определенное время. Пункт плана - это запись в календаре или в плане, соответствующая некоторому действию, которое должно быть совершено, или некоторой договоренности (встрече, визиту и т.д.). Например, пунктом плана может являться запись о работе, порученной соответствующему лицу.
vCard обеспечивает автоматизацию обмена персональной информацией, обычно записываемой на традиционной визитной карточке. vCard используется в применениях типа электронной почты, голосовой почты, веб-браузеров, телефонной связи, центров обработки звонков, видеоконференций, персональных информационных менеджеров (PIMs=Personal Information Managers), персональных цифровых ассистентов (PDAs=Personal Data Assistants), пейджеров, факсов, офисного оборудования и интеллектуальных карт (смарт-карт). В дополнение к тексту, в состав информации vCard могут входить такие элементы, как изображения, фирменные логотипы, активируемые сетевые адреса и т.д.
Как видно из приведенных примеров, предпринимались многочисленные попытки построить системы, которые способны синхронизировать системы приема заказов. Общая проблема, свойственная всем этим существующим решениям, состоит в том, что они не обеспечивают общую семантику для различных систем. Например, если введенные данные имели предварительный характер, различные системы могут интерпретировать эти данные различным образом.
Еще одна проблема заключается в том, что системы приема заказов имеют различные и часто весьма сложные пользовательские интерфейсы. Если пользователь хочет получить назначение к стоматологу и заказать такси, которое доставит его к этому стоматологу, он будет должен ввести всю необходимую для заказа информацию в обе системы приема заказов с использованием различных режимов ввода.
Дальнейшая проблема состоит в том, что задача обработки ответов пользователя (клиента) становится все более сложной. Например, представляется разумным использовать текстовые CMC-сообщения (SMS messages) для того, чтобы спросить клиента, какие именно варианты он считает предпочтительными. Обращение к данным сообщениям объясняется тем, что во многих странах, например, в Финляндии, связь посредством данных текстовых сообщений является весьма распространенной, причем они приносят доход операторам связи. Однако, если клиент отвечает на несколько запросов путем посылки большого количества текстовых сообщений, может оказаться затруднительным определить, какой именно ответ соответствует определенному вопросу. Это связано с тем, что ответ не обязательно включает ссылку на заданный вопрос. Например, сервис может спросить клиента, желает ли он, в дополнение к заказу авиабилета, заказать также такси и номер в гостинице, и клиент отвечает "да" на первый вопрос и "нет" на второй вопрос. В таком случае сервису не всегда будет ясно, какое именно из предложений принято клиентом.
Раскрытие изобретения
Задача, на решение которой направлено настоящее изобретение, заключается в устранении или, по крайней мере, в существенном ослаблении рассмотренных выше недостатков. Изобретение позволяет предложить услуги нового типа, которые особенно важны для различных мобильных сервисов.
Дальнейшая задача заключается в разработке способа и системы, способных осуществлять транзакции типа оформления заказов с участием, по меньшей мере, одного провайдера услуг и множества пользователей, каждый из которых пользуется для осуществления коммуникации мобильным телефоном, способным принимать и посылать короткие текстовые сообщения.
Еще одна задача заключается в разработке способа и системы, способных осуществлять транзакции типа оформления заказов между множеством провайдеров услуг и множеством пользователей, каждый из которых пользуется для осуществления коммуникации мобильным телефоном, способным принимать и посылать короткие текстовые сообщения.
В первом аспекте изобретение предлагает способ осуществления коммуникации между службой-посредником и клиентским терминалом, снабженным адресом, идентифицирующим клиента, включающий:
(а) инициирование коммуникации с клиентским терминалом, включающее ассоциирование с конкретным адресом для ответа, по которому должен быть отправлен ответ на диалог, причем коммуникация включает множество обменов в режиме диалог-ответ с клиентским терминалом, а конкретный адрес для ответа выбирают из множества адресов, по которым служба-посредник способна получать ответы;
(б) инициирование диалога с клиентским терминалом с использованием указанного конкретного адреса для ответа, причем инициирование включает ассоциирование различных адресов для ответа с различными обменами в режиме диалог-ответ;
(в) получение от клиентского терминала ответа на конкретный адрес для ответа, причем указанный ответ содержит адрес, идентифицирующий клиента; и
(г) оценивание ответа при использовании адреса, идентифицирующего клиента, и конкретного адреса, на который получен указанный ответ.
Во втором аспекте изобретение предлагает службу-посредник, контролирующую коммуникации между, по меньшей мере, одним провайдером услуг и клиентским терминалом, снабженным адресом, идентифицирующим клиента, содержащую:
(а) множество адресов, на которые служба-посредник способна получать сообщения от клиентского терминала;
(б) логику и ресурсы, адаптированные для:
(i) инициирования коммуникации с клиентским терминалом по поводу конкретного провайдера услуг, включая ассоциирование коммуникации с конкретным адресом для ответа, по которому должен быть отправлен ответ на диалог, причем коммуникация включает множество обменов с клиентским терминалом в режиме диалог-ответ, а конкретный адрес для ответа выбран из множества адресов;
(ii) инициирования диалога с клиентским терминалом с использованием указанного конкретного адреса для ответа, причем различные адреса для ответа ассоциируются с различными обменами в режиме диалог-ответ;
(iii) получения ответа на конкретный адрес для ответа и
(iv) оценивания ответа при использовании адреса, идентифицирующего клиента, и конкретного адреса, на который получен указанный ответ.
В третьем аспекте изобретение предлагает сервер приложения-посредника, осуществляющего коммуникацию через компьютерную сеть и действующего в качестве службы-посредника при оформлении заказов между, по меньшей мере, одним провайдером услуг и множеством клиентов, каждый из которых использует клиентский терминал, снабженный адресом, идентифицирующим клиента, и способный осуществлять коммуникацию с сервером, используя короткие сообщения такого типа, когда ответ необязательно содержит прямую ссылку на предшествующее сообщение, причем сервер приложения-посредника содержит:
(а) множество адресов, по которым сервер приложения-посредника способен получать коммуникации с клиентских терминалов, и
(б) логику и ресурсы, выполненные с возможностью
идентифицировать запросы, поступающие в ответ на запрос на обслуживание, каждый из которых ассоциируется с адресом, идентифицирующим клиента, и с, по меньшей мере, одним провайдером услуг,
подготавливать сообщения, обусловленные запросами, в том числе, по меньшей мере, одно сообщение, соответствующее каждому запросу,
ассоциировать с каждым сообщением конкретный адрес для ответа, выбранный из множества адресов,
посылать каждое сообщение клиентскому терминалу, имеющему адрес, идентифицирующий клиента и ассоциированный с соответствующим запросом на обслуживание,
получать ответы на сообщения, каждый из которых включает адрес, идентифицирующий клиента, на множество адресов,
хранить информацию, относящуюся к ответам, в матрице, первая ось которой соответствует адресам, идентифицирующим клиентов, а вторая ось - адресам ответов, и оценивать ответы с использованием адреса, идентифицирующего клиента, и адреса, по которому был получен ответ.
В четвертом аспекте изобретение предлагает способ осуществления функций указанного сервера приложения-посредника, осуществляющего коммуникацию по компьютерной сети и действующего в качестве службы-посредника между, по меньшей мере, одним провайдером услуг, осуществляющим коммуникацию по компьютерной сети, и множеством клиентов, каждый из которых имеет идентифицирующий его адрес и осуществляет коммуникацию с сервером приложения-посредника посредством коротких сообщений такого типа, когда ответ необязательно содержит прямую ссылку на предшествующее сообщение, причем способ включает выполнение сервером приложения-посредника следующих действий:
(а) идентифицирование запросов, поступающих в ответ на запрос на обслуживание, каждый из которых ассоциируется с адресом, идентифицирующим клиента;
(б) подготовку сообщений, обусловленных запросами;
(в) ассоциирование с каждым сообщением конкретного адреса для ответа, выбранного из множества адресов, доступных для получения сообщений от клиентских терминалов;
(г) посылку каждого сообщения по адресу, идентифицирующему клиента и ассоциированному с соответствующим запросом на обслуживание,
(д) получение ответов на сообщения на множество адресов;
(е) хранение информации, относящейся к ответам, в матрице, первая ось которой соответствует адресам, идентифицирующим клиентов, а вторая ось - адресам для ответов; и
(ж) оценивание ответов с использованием адреса, идентифицирующего клиента, и адреса для ответа.
Краткое описание чертежей
Далее изобретение будет описано более подробно на примерах нескольких вариантов своего осуществления.
На фиг.1 схематично представлен один из возможных вариантов системы по изобретению.
На фиг.2 представлен второй возможный вариант системы по изобретению.
На фиг.3 представлен третий возможный вариант системы по изобретению.
На фиг.4 представлена диаграмма, иллюстрирующая один из предпочтительных вариантов последовательности сообщений, передаваемых системой по настоящему изобретению.
На фиг.5 представлена диаграмма, иллюстрирующая второй предпочтительный вариант последовательности сообщений, передаваемых системой по настоящему изобретению.
На фиг.6 показан пример динамической диалоговой матрицы применительно к схеме запросов и ответов согласно изобретению.
Фиг.7 иллюстрирует этапы процесса оформления заказа в соответствии с предпочтительным вариантом осуществления изобретения.
На фиг.8 представлена матричная диаграмма, соответствующая Примеру 2 согласно предпочтительному варианту изобретения.
Осуществление изобретения
Изобретение относится к обмену информацией и к синхронизации информации между системами приема заказов и терминальными клиентскими устройствами. Резервируемые услуги могут, например, соответствовать заказанным посещениям служб здравоохранения, резервированию мест в гостиницах, авиабилетов, сдаваемым в прокат автомобилям, бронированию билетов на различные мероприятия, оформлению предварительных заказов на обслуживание автомобиля; оформлению предварительных заказов на обслуживание квартиры и т.д.
Система оформления заказов согласно изобретению содержит, по меньшей мере, одну систему приема заказов, имеющуюся у провайдера услуг, по меньшей мере, одного провайдера услуг, по меньшей мере, одного посредника, клиента, по меньшей мере, одно терминальное клиентское устройство, которое может представлять собой мобильное устройство, способное принимать текстовые сообщения и поддерживать диалог, и линии телекоммуникации, служащие для связывания систем приема заказов у провайдеров услуг, провайдеров услуг, посредника и терминального клиентского устройства.
Провайдеры услуг - это те, с кем клиенты хотят договориться о визите, о заказе или каком-либо ином резервировании. При этом провайдеры располагают ресурсами, которые могут быть распределены с использованием системы приема заказов. Провайдеры услуг осуществляют свой бизнес через систему приема заказов, имеющуюся у соответствующего провайдера. В контексте данного описания под посредником понимается сетевая служба, которая является доступной по сети для систем приема заказов, имеющихся у провайдеров услуг, и которая обеспечивает дополнительные услуги в отношении семантики, перевода и синхронизации, необходимые для передачи информации, требующейся клиенту для завершения транзакции с провайдером услуг. Системы приема заказов, имеющиеся у провайдеров услуг, и посредник предпочтительно представляют собой приложения, функционирующие на сетевых серверах, например, в Интернет или в частных сетях типа Интранет. В общем случае система по изобретению будет включать в себя множество провайдеров услуг и их систем приема заказов (реализующих услуги в области приема заказов на услуги провайдера). Однако возможно построение системы и с простой системой приема заказов только для единственного провайдера услуг. В этом случае посредник и провайдер услуг могут быть тесно интегрированы в рамках единого приложения.
В состав клиентов предпочтительно входят клиенты, осуществляющие коммуникацию посредством мобильных телефонов, способных получать короткие текстовые сообщения, такие как CMC-сообщения. Разумеется, система, которая способна работать с CMC-сообщениями, будет взаимодействовать и с другими клиентами, обладающими более широкими возможностями. Посредник предпочтительно осуществляет коммуникацию с клиентами через СМС-шлюз, подобный тем, которые поддерживаются провайдерами мобильной телефонной связи и в настоящее время являются хорошо известными. Посредник осуществляет коммуникацию с клиентами с использованием диалогов.
Диалоги - это короткие сообщения, которые сообщают информацию клиенту и допускают простой ответ. Диалоги предпочтительно предоставляют пользователю простые варианты выбора типа да/нет или позволяют осуществить выбор из упорядоченного списка. Диалог может быть также односторонним, например, для подтверждения резервирования. Типичная транзакция может включать последовательность диалогов, каждый из которых предусматривает простой ответ. Диалоги представляют собой асинхронную коммуникацию посредством сообщений. Рассматриваемая система позволяет синхронизировать оформление заказа в различных системах, имеющихся у провайдеров услуг, для того, чтобы удовлетворить потребности клиента, например, для того, чтобы скоординировать заказ авиабилета с доставкой в аэропорт.
На фиг.1 представлена диаграмма простейшей системы, содержащей единственную систему 100 приема заказов, имеющуюся у единственного провайдера услуг. В состав системы по изобретению входят также посредник 102, который осуществляет связь с провайдером услуг по сети, и пользователь 104 с мобильным телефоном, через который он осуществляет диалог.
На фиг.2 показано множество систем 110 резервирования, связанных с посредником 112 по сети.
На фиг.3 условно изображен посредник, обозначенный, как BookIT, который поддерживает связь с множеством систем, имеющихся у различных провайдеров услуг, и с пользователями, имеющими мобильные телефоны, поддерживающие диалоги.
Обоснованный (т.е. обусловленный какой-либо причиной) диалог представляется желательным усовершенствованием с точки зрения клиента, поскольку провайдеры услуг могут создать свои собственные диалоги в связи с каждым событием, связанным с приемом заказа. Диалог оказывается тесно увязанным с конкретной ситуацией приема заказа. Он автоматически активизируется в нужный момент; альтернативно, клиент может активировать диалог по мере необходимости. Еще в одном варианте какая-то другая часть системы может поспать сообщение, чтобы активировать диалог. После этого диалог посылает запрос в другую часть системы или информирует клиента, или, возможно, осведомляется о предпочтениях клиента. Посредством диалога подобного типа клиент-может оформить заказ в нескольких системах приема заказов, используя единственный интерфейс. Диалог осуществляет коммуникацию с удаленными системами приема заказов, например, через Интернет или даже мобильные сети.
Служба посредника может обеспечивать передачу информации, связанной с оформлением заказа, между системами приема заказов, имеющимися у провайдеров услуг. Например, после того, как заказ введен в систему заказа авиабилетов, система заказа такси может предложить клиенту доставить его в аэропорт. В подобной ситуации термин "оформление заказа" будет относиться к управлению единственным ресурсом (т.е. в рассмотренном примере к заказу либо авиабилета, либо такси), тогда как термин "резервирование" будет означать сочетание заказов на все ресурсы, связанные с одним и тем же событием (т.е. в рассмотренном примере заказ авиабилета плюс заказ такси). Диалог между клиентом, посредником и системами приема заказов в сочетании с сохраняемым профилем пользователя обеспечивает получение клиентом не назойливой рекламы, а обоснованной услуги, в которой он нуждается.
Клиент может производить резервирования, а также подтверждать, изменять или отменять их с использованием различных средств коммуникации, включая Интернет, электронную почту и мобильные терминалы, но не ограничиваясь ими. Кроме того, используя функции синхронизации, обеспечиваемые посредником, клиент может также синхронизовать календарь, обеспечиваемый посредником или провайдером услуг, с календарем в терминальном устройстве.
Провайдер услуг может напоминать клиентам об осуществлении резервирования на регулярной основе и тем самым повышать лояльность пользователей по отношению к себе. Посредник может оказывать помощь провайдерам услуг по взаимодействию их систем приема заказов с целью предоставления более полных услуг без неоправданного расширения их собственных бизнесов. Например, с учетом тенденции к интернационализации услуг посредник может поддерживать различные языки, работать в различных часовых поясах, с различными валютами и форматами данных.
Система, в состав которой входят, по меньшей мере, диалог, посредник, провайдер услуг и система информации, имеющаяся у провайдера услуг, может быть выполнена на одном из следующих уровней.
1. В системе имеется заданный набор диалогов. Их содержание и предоставляемый набор альтернатив определены заранее. Например, если клиент оформляет заказ на авиарейс, диалог всегда предлагает оформить и некоторые другие заказы. Предшествующие действия клиента не учитываются.
2. Существует неограниченное количество динамических, или "интеллектуальных" диалогов, которые основаны, например, на профиле, созданном самим клиентом, на записях о предыдущих обращениях и на местоположении клиента. Принятие решений поддерживается простой логикой. Данный вариант соответствует экспертной системе низкого уровня.
3. Система способна самостоятельно принимать решения и поддерживать процесс принятия решений клиентом. На этом уровне диалог может включать экспертную систему высокого уровня. Она может функционировать в качестве агента и вести переговоры с несколькими провайдерами услуг для того, чтобы получить наилучшее предложение без прямого вмешательства клиента.
В одном предпочтительном варианте осуществления способа по изобретению клиент заказывает услугу у провайдера услуг. Оформление заказа может производиться с помощью терминала, который связан со службой посредника. Сначала клиент, используя диалог, соединяется со службой посредника. Клиент вводит в диалог запрос на обслуживание (резервирование), и диалог направляет этот запрос посреднику. Посредник осведомляется о возможных резервированиях, обращаясь к информационной системе провайдера услуг, используя понятия и терминологию, которые эта система способна интерпретировать. Запрос основывается на предпочтениях клиента. Клиент приводит такие предпочтения, которые связаны с конкретным заказом, когда он вводит запрос на резервирование в диалог. Кроме того, в диалоге и в службе посредника могут быть записаны общие предпочтения клиента, которые могут быть использованы, так что у клиента не будет необходимости вводить все свои предпочтения каждый раз.
Управление запросами и оформлением заказов основывается на сложной модели состояний. Оформление каждого заказа включает в себя несколько этапов, которые описываются состояниями, отслеживающими статус заказа на протяжении его жизненного цикла. Например, после того как посредник осведомился о резервировании у провайдера услуг, соответствующие записи в каждой системе имеют состояние, соответствующее тому, что оформление заказа ожидается, но не завершено. Если у систем отсутствует общее понимание того, что означает каждое состояние, посредник осуществляет соответствующий перевод. Предпочтительный процесс оформления заказа включает этапы и состояния, описанные далее в Примере 1.
В дополнение к обращению с запросом на резервирование к провайдеру услуг, посредник способен синхронизировать оформление заказов в нескольких системах, имеющихся у провайдеров услуг. Синхронизация базируется на правилах, определенных в рамках службы посредника. Например, может действовать следующее правило: "если клиент запрашивает о заказе авиабилета, следует запросить также о заказе такси до аэропорта". Таким образом, запрос от клиента может быть преобразован в службе посредника в несколько запросов.
Провайдеры услуг отвечают посреднику, если они в состоянии предоставить запрошенную услугу, причем они могут привести какую-либо дополнительную информацию, например, касающуюся мест или расписания. Посредник комбинирует полученную информацию и посылает ее в диалог, который показывает клиенту простой перечень имеющихся вариантов. Например, диалог может показать три варианта полета и задать вопрос, не хочет ли клиент также зарезервировать такси, которое на самом деле уже предварительно заказано посредником. Клиент принимает решение, делая выбор между вариантами, представленными в показанном ему списке альтернатив. Диалог посылает информацию о сделанном клиентом выборе посреднику, который подтверждает заказы в соответствии с выборами, сделанными клиентом, и отменяет излишние резервирования.
На фиг.4 приведена диаграмма последовательности действий в связи с запросом CINQ1, посланным клиентом посреднику с использованием диалога DINQ1. Посредник посылает в систему 1 приема заказов, имеющуюся у провайдера услуг, запрос MINQ1, который соответствует CINQ1 и DINQ1. В результате клиент получает ответ DANS1, предлагающий ему некоторый выбор. Клиент отвечает, указывая свой выбор CSEL1; в результате происходит прием (оформление) заказа от клиента системой 1 приема заказов. Посредник осознает потенциальную потребность в дополнительной услуге от системы 2 приема заказов и инициирует запрос MINQ2 в эту систему. В результате клиенту поступает предложение DANS2, содержащее несколько альтернативных вариантов. Клиент делает свой выбор CSEL2, что приводит к оформлению дополнительного заказа в системе 2 приема заказов.
Заказы могут оформляться и с использованием иных средств, например, посредством обращения к провайдеру услуг по телефону или посещения офиса провайдера услуг. В таком случае провайдер услуг может проинформировать посредника о заказах, сделанных клиентом, для того, чтобы посредник мог проинформировать клиента о других возможных вариантах. Например, стоматолог может сообщить посреднику о том, что клиент договорился о визите, с тем чтобы посредник мог предложить клиенту сделать также заказ на такси.
Кроме того, в службе посредника можно предусмотреть также услугу по напоминанию, так что в определенное время посредник запрашивает, не хочет ли клиент оформить новый заказ. Например, посредник может уведомить клиента о том, что прошел год с момента, когда у клиента был последний визит к своему стоматологу, и спросить, не хочет ли клиент заказать новый визит. Такое уведомление уже может включать несколько различных вариантов в отношении данного визита. Посредник предварительно проверил календарь клиента (если клиент дал на это свое разрешение), так что предлагаемые варианты должны быть удобны для клиента. Диалог представляет предлагаемые варианты простым и удобным образом. Клиенту нужно только выбрать вариант, наиболее удобный для него, или решить, что он хочет получить новый набор вариантов или отложить оформление заказа. На фиг.5 представлена последовательность действий для ситуации, когда первоначальный запрос, MINQ1, был инициирован посредником.
Пример 1 - предпочтительная система оформления заказов
Предпочтительная система оформления заказов согласно изобретению будет описана применительно к системе, именуемой BooklT.
Система BooklT разработана в качестве интерфейса между, с одной стороны, системами приема заказов, имеющимися у провайдеров услуг, и другими субъектами, связанными по сети типа Интернет, и, с другой стороны, конечными пользователями (клиентами), оснащенными мобильными телефонами, способными принимать текстовые сообщения. Связь между субъектами первой группы осуществляется предпочтительно с использованием интерфейса типа XML. Система BooklT поддерживает стандарты vCard и vCalendar, поскольку они используются всеми основными системами приема заказов и системами календаря.
Коммуникацию с пользователями мобильными телефонами система BookIT осуществляет с использованием CMC-сообщений через межсетевой интерфейс (шлюз) SMS Gateway для асинхронной коммуникации. Для безопасной передачи CMC-сообщений и отображения их в памяти система BookIT использует новую динамичную матрицу диалога Dynamic Dialogue Matrix (DDM).
Необходимо проводить четкое разграничение между процессом приема заказов у провайдера услуг и процессом, осуществляемым системой BookIT (именуемым в дальнейшем "процесс BookIT"). Первый процесс охватывает стандартный режим приема заказов, касающийся только резервирования ресурса с указанием времени. Второй процесс включает в себя оформление заказов, реализацию и финансирование. Более конкретно, процесс BookIT состоит из следующих семи этапов (см. также фиг.7).
Этапы (учет статуса)
Этапы устанавливают (гибкую) связь между ресурсами. На каждом из этапов процесса BookIT данные, относящиеся к заказу, должны корректироваться для того, чтобы учесть потребности данного этапа. Соответствующие статусы и значения указаны в Таблице 1. Далее все этапы будут описаны более подробно.
1. Обращение
Обращение соответствует инициализации процесса BookIT и процесса приема заказа. В результате инициализации в базу данных исходной информации вводится новая запись. Она не будет отражена в календаре, т.к. не является информацией, связанной с расписанием. Эта запись может быть отображена как открытое задание в отдельном списке заданий, соотнесенном с конкретным владельцем.
2. Запрашивание
На этапе запрашивания обслуживания производится посылка запроса на оформление заказа. Этот запрос направляется ресурсам, необходимым для выполнения ранее введенного задания. Поскольку при этом не задается расписание, которое в большинстве случаев будет иметь существенное значение, данный этап может выполняться совместно с этапом составления расписания.
3. Составление расписания
Расписание выдается владельцу и ресурсам. В качестве части и результата данного этапа необходимо иметь следующие данные:
(а) предлагаемое время начала выполнения (метка даты/времени по стандарту ISO с указанием часового пояса);
(б) предлагаемая локализация начала выполнения (координаты);
(в) предлагаемое время окончания выполнения (метка даты/времени по стандарту ISO с указанием часового пояса);
(г) предлагаемая локализация окончания выполнения (координаты).
4. Подтверждение
Время и локализация, как они приняты ресурсами, осуществившими принятие. Данные, относящиеся к этому этапу, таковы:
(а) принятое время начала выполнения (метка даты/времени по стандарту ISO с указанием часового пояса);
(б) принятая локализация начала выполнения (координаты);
(в) принятое время окончания выполнения (метка даты/времени по стандарту ISO с указанием часового пояса);
(г) принятая локализация окончания выполнения (координаты).
По умолчанию данные копируются с этапа составления расписания.
На практике, если предлагаемое (планируемое) время не является обязательным, на данном этапе могут использоваться те же структуры данных, причем статус указывает истинное значение данных.
5. Выполнение
Ресурсы выполняют заказанную задачу. Данные, относящиеся к этому этапу, состоят из различных атрибутов и их значений, которые привязаны к конкретному заданию. В дополнение требуются следующие статические структуры:
(а) действительное время начала выполнения (метка даты/времени по стандарту ISO с указанием часового пояса);
(б) действительная локализация начала выполнения (координаты);
(в) действительное время окончания выполнения (метка даты/времени по стандарту ISO с указанием часового пояса);
(г) действительная локализация окончания выполнения (координаты);
(д) использованные продукты, дополнительные услуги, пройденное расстояние,..
По умолчанию данные копируются с этапа подтверждения.
6. Отчетность
На этом этапе производится анализ всех данных, записанных в запоминающие структуры на предыдущих этапах, и их обработка. Данные, относящиеся к этому этапу (учетные данные) будут рассмотрены далее.
7. Завершение
Задание завершено. С точки зрения процесса BookIT в целом, несущественно, было ли задание успешным или нет. Этот вопрос важен для этапа отчетности, на котором производятся финансовые операции по отношению к организатору. Для того чтобы завершить процесс BookIT, на этапе завершения производятся записи учетного характера (касающиеся содержания базы данных, временных файлов и т.д.).
В приводимой ниже Таблице 1 указаны данные, доступные на каждом этапе. Данные по этапу оформления заказа выделены шрифтом.
Статусы этапов, значения и переходы
Таблица 2 описывает этапы, их статусы, а также значения вместе с переходами к следующему логическому этапу на основе полученных значений. В дополнение, там, где это возможно, указаны соответствующие статусы vCalendar.
Внутренние этапы "Пауза", "Повторный запуск" и "Отменен" для всех релевантных этапов в любой момент соответствуют действиям, указанным в Таблице 3.
На фиг.6 приведена блок-схема, иллюстрирующая переходы от этапа к этапу. Условия для переходов показаны в Таблице 3. Следует отметить, что статус "Отменен" всегда ведет к этапу отчетности.
Подтверждение резервирования (в целом)
Для того чтобы резервирование в целом было успешным, все ресурсы, которые приняли резервирование, должны иметь то же самое расписание. Кроме того, различные ресурсы должны играть различные роли, причем данные, относящиеся к этапу выполнения, могут варьироваться в широком диапазоне.
Различные статусы, относящиеся к резервированию в целом, могут быть следующими.
(а) "Нет ответов" (0), что означает "Никто не ответил на запрос, сделанный организатором".
(б) "Нет отказов" (1), что означает "Пока ответили не все запрошенные субъекты. Те, кто ответили, приняли предложение".
(в) "Все приняли" (2), что означает "Все запрошенные субъекты подтвердили принятие".
(г) "Несколько отказов" (3), что означает "Часть запрошенных субъектов ответили отказом".
(д) "Все отказали" (4), что означает "Все запрошенные субъекты ответили отказом".
Приведенная ниже Таблица 4 - это таблица решений, помогающая при оценке статуса оформляемого заказа в целом. "Может быть" означает, что данное условие не дает ответа в отношении того, является ли результат безусловно истинным или ложным.
На основе имеющейся информации и таблицы решений организатор/приложение должны принять решение о том, как поступить в отношении резервирования. Решение должно быть принято автоматически (на основе заранее принятых правил) или вручную.
Одна важная проблема, решенная изобретением, состоит в трудностях управления ответами клиента в случае, когда клиенту был задан ряд вопросов, а клиент пользуется текстовыми CMC-сообщениями или аналогичной технологией, в которой ответ не обязательно включает в явной форме ссылку на запрос. Согласно изобретению данная проблема решается благодаря использованию динамичных матриц диалога (DDM). Запрос всегда включает в той или иной форме адрес или идентификацию получателя. Применительно к CMC-сообщениям такой адрес представляет собой так называемый "номер подписчика В". С другой стороны, к каждому текстовому сообщению всегда присоединяется ассоциируемый с отправителем "номер подписчика А" или установленный номер вызывающего абонента (Calling Line Identity - CLI), или аналогичный идентификатор. Поэтому клиент (подписчик В) обычно без труда может ответить на сообщение, используя реализованную в мобильном устройстве функцию ответа.
Если служба посредника, которая посылает запросы клиенту, использует в различных запросах различные номера подписчика А, становится возможным произвести дифференциацию ответов, основываясь на номере, на который клиент посылает свой ответ. Например, если посредник посылает клиенту запрос "Не требуется ли Вам также такси?", используя в качестве номера подписчика А номер А1, а затем посылает запрос "Не нужен ли Вам номер в гостинице?", используя номер А2, то ответ клиента на первый вопрос возвращается на номер А1, а второй ответ возвращается на номер А2. Используя матрицу диалога, посредник отслеживает запросы и ответы. В данной матрице имеется столбец для каждого клиента и строка для каждого номера подписчика А, который использует посредник. Очевидно, можно, наоборот, предусмотреть строку для каждого клиента и столбец для каждого номера подписчика А. В результате посредник способен установить, ответил ли клиент на конкретный запрос, и какой именно он дал ответ.
Кроме того, можно использовать данную матрицу для сбора информации о поведении клиента и использовать эту информацию, например, для целей маркетинга. При этом посреднику требуется иметь только ограниченное количество номеров подписчика А. Матрицу диалога можно также использовать для того, чтобы определить, какие номера подписчика А можно использовать при отсылке следующего запроса конкретному клиенту.
Описанное выше использование динамичной матрицы диалога иллюстрируется фиг.8.
Динамическая матрица диалога является также мощным, но весьма простым средством обеспечения безопасности при аутентификации пользователя мобильным телефоном, который обладает только возможностью посылать и получить сообщения. Проблема для сервиса состоит в том, чтобы подтвердить идентификацию отправителя. Один из вариантов осуществления идентификации состоит в проверке адреса отправителя. Обычно CMC-сообщения, сообщения, отправляемые по электронной почте, или аналогичные сообщения снабжаются адресом отправителя. Таким адресом может являться, например, номер подписчика А, присвоенный отправителю, или установленный номер вызывающего абонента (CLI), или адрес электронной почты, или IP-адрес.Однако адрес отправителя может быть легко фальсифицирован. С точки зрения провайдера услуг, нисходящая линия связи от провайдера услуг к пользователю является относительно надежной, и перехват и изменение третьими лицами сообщений, передаваемых по этой линии, представляется затруднительным. Однако восходящая линия связи от пользователя к провайдеру услуг является значительно менее защищенной, и указание ложного адреса отправителя не вызывает значительных трудностей.
Хорошо известное решение рассмотренной проблемы состоит в использовании технологии шифрования с целью защиты коммуникации. Хорошим примером такого подхода являются инфраструктуры с открытым ключом. Так, пользовательское устройство (например, GSM-устройство) может быть снабжено микрочипом, защищенной SIM-картой, для того, чтобы шифровать сообщения с помощью своего индивидуального ключа. В этом случае провайдер услуг может быть уверен, что сообщение поступило именно от пользователя, при условии, что оно может быть дешифровано с помощью открытого ключа пользователя. Однако такое решение требует наличия специальных устройств, которые в настоящий момент еще не являются общеупотребительными, недорогими или стандартизованными. Использование именно такого решения существенно ограничивает количество потенциальных пользователей.
Применение матрицы DDM обеспечивает новое решение. Когда служба посылает запрос на мобильный телефон пользователя, каждый такой запрос содержит индивидуальный номер для ответа, предпочтительно выбранный случайным образом. В этом случае приемлемым будет только тот ответ, который послан на правильный адрес для ответа.
Пример 2 - Использование динамической матрицы диалога
Данный простой пример относится к бронированию авиабилетов на завтрашний утренний рейс. Система посылает серию вопросов в виде CMC-сообщений, требующих короткого ответа. Каждое сообщение помечено таким образом, что ответ на него может быть идентифицирован. Благодаря этому нет необходимости посылать сообщения или принимать ответы в определенной последовательности, если только такое требование не задается используемой логикой (например, если ответ на один вопрос влияет на содержание следующего вопроса).
Пользователь, идентификатором (ID) которого является номер его телефона (т.е. ID=0418979813) послал запрос на билет. Система посылает, в виде индивидуальных CMC-сообщений, следующие запросы:
Пожалуйста, выберите одно из следующих времен вылета:
6.00 - ответ А
7.30 - ответ Б
8.15 - ответ В.
Если ни один из вариантов не походит, ответ Г.
Отправитель:+358440844 027
Пожалуйста, выберите класс билета:
Первый класс - ответ А
Бизнес класс - ответ Б
Экономический - ответ В.
Самый дешевый из имеющихся - ответ Г.
Отправитель: +358440844 011
Пожалуйста, выберите:
Место у окна - ответ А
Место у прохода - ответ Б
Отправитель: +358440844 034
Пожалуйста, выберите вариант меню:
Вегетарианское - ответ А
Говядина - ответ Б
Курица - ответ В.
Отправитель: +358440844 003
Полученные от пользователя ответы на приведенные и некоторые другие вопросы, оказались следующими:
'А' на вопрос, ассоциированный с номером +358440844027
'Г' на вопрос, ассоциированный с номером +358440844011
'А' на вопрос, ассоциированный с номером +358440844034
'Б' на вопрос, ассоциированный с номером +358440844003
'Г' на вопрос, ассоциированный с номером +358440859751
'А' на вопрос, ассоциированный с номером +358440844277
'В' на вопрос, ассоциированный с номером +358440841368.
Отсюда провайдер услуг может определить, что пользователь выбрал:
- первый утренний рейс (=А)
- самый дешевый доступный билет (=Г)
- место у окна (=А)
- говядину в меню (=Б) и т.д.
Важно отметить, что при использовании матрицы пользователь может отвечать на вопросы в любом порядке, причем он может даже не ответить на некоторые вопросы. Если ответы на них важны, система может напомнить о необходимости ответа. Если нет, система может продолжить работу и без получения ответов.
Приведенные ответы показаны также на фиг.8 в форме трехмерной матрицы. При этом по оси Х указываются номера пользователей, по оси Y - номера ответов, а по оси Z - номера для отправки ответов. Рассмотренный пользователь с номером телефона 0418979813 соответствует крайней левой позиции по оси X. Номера для отправки ответов указываются по оси Z с учетом номеров ответов, отложенных по оси Y.
Дополнительная защищенность может быть достигнута за счет использования семантического анализа. В оболочках матриц может содержаться информация о запросе и о том, какие варианты ответов являются приемлемыми. Если ответ не отвечает установленным критериям, он отбрасывается. Например, если провайдер услуг просит пользователя сообщить, сколько именно изделий заказано, а пользователь отвечает "да", становится очевидным, что пользователь не знает, в чем именно состоял вопрос, и полученное сообщение не является ответом на запрос.
Возможна также ситуация, когда в качества провайдера услуг выступает посредник, тогда как "истинный" провайдер услуг находится в другом месте. В этом случае достаточно, чтобы только посредник располагал рассмотренной матричной системой, тогда как реальный провайдер услуг осуществляет коммуникацию с посредником, используя либо матричную систему посредника, либо иные защищенные средства, в частности, криптоканал.
Например, система совместного пользования автомобилями (car sharing system) может быть реализована следующим образом. Автомобили распределены в пределах города случайным образом. Когда пользователю требуется автомобиль, он посылает посреднику сообщение с вопросом, где находится ближайший автомобиль. Посредник посылает ему сообщение с указанием местоположения автомобиля. Этот ответ приходит с адреса у', выбранного случайным образом. Когда пользователь находит автомобиль, он посылает по адресу у" сообщение, подтверждающее, что период аренды автомобиля начался, и содержащее обращенную к посреднику просьбу дистанционно разблокировать замки автомобиля. Данное сообщение имеет довольно высокую степень надежности, поскольку оно послано по адресу, известному только пользователю. Как следствие, такое сообщение представляет собой достаточное основание для того, чтобы разблокировать замки и начать формирование счета. С другой стороны, коммуникация между посредником и автомобилем является "невидимой" для пользователя и посторонних лиц. Автомобиль может быть оборудован специальными устройствами, позволяющими использовать зашифрованные команды на разблокирование замков и т.д. В альтернативном варианте коммуникация между автомобилем и посредником может быть также реализована с применением матриц. В любом случае посредник функционирует как межсетевое устройство защиты (брандмауэр) между пользователем и автомобилем, предотвращая возможность его использования лицами, не имеющими авторизации.
Хотя настоящее изобретение было подробно описано применительно к определенным предпочтительным вариантам его осуществления, возможны также и другие варианты изобретения. В связи с этим объем защиты изобретения, определяемый прилагаемой формулой изобретения, не должен сводиться только к предпочтительным вариантам изобретения.
Изобретение относится к способам и системам для осуществления резервирования в системах приема заказов и для синхронизации заказов, направляемых в несколько систем приема заказов. Технический результат, в частности, заключается в разработке способа и системы, способных осуществлять транзакции типа оформления заказов между множеством провайдеров услуг и множеством пользователей. Для этого система по изобретению содержит, по меньшей мере, одну систему приема заказов, службу-посредника и клиента, пользующегося, по меньшей мере, одним терминальным клиентским устройством, которое может представлять собой мобильное устройство и которое обеспечивает возможность диалога. Клиент использует диалог для того, чтобы ввести информацию в систему по изобретению. Служба-посредник принимает запросы и ответы от, по меньшей мере, одной системы приема заказов от, по меньшей мере, одного провайдера услуг и от, по меньшей мере, одного клиента. Посредник передает и адаптирует циркулирующую между ними информацию. Способ и система по изобретению предназначены, в первую очередь, для использования владельцами мобильных телефонов, способных работать с CMC-сообщениями. 2 н. и 19 з.п. ф-лы, 4 табл., 8 ил.
(а) множество адресов, по которым сервер приложения-посредника способен получать коммуникации с клиентских терминалов, и
(б) ресурсы, выполненные с возможностью
идентифицировать запросы, поступающие в ответ на запрос на обслуживание, каждый из которых ассоциируется с адресом, идентифицирующим клиента, и с, по меньшей мере, одним провайдером услуг,
подготавливать сообщения, обусловленные запросами, в том числе, по меньшей мере, одно сообщение, соответствующее каждому запросу,
ассоциировать с каждым сообщением конкретный адрес для ответа, выбранный из множества адресов,
посылать каждое сообщение клиентскому терминалу, имеющему адрес, идентифицирующий клиента и ассоциированный с соответствующим запросом на обслуживание,
получать ответы на сообщения, каждый из которых включает адрес, идентифицирующий клиента, на множество адресов,
хранить информацию, относящуюся к ответам, в матрице, первая ось которой соответствует адресам, идентифицирующим клиентов, а вторая ось - адресам ответов, и оценивать ответы с использованием адреса, идентифицирующего клиента, и адреса, по которому был получен ответ.
(а) идентифицирование запросов, поступающих в ответ на запрос на обслуживание, каждый из которых ассоциируется с адресом, идентифицирующим клиента,
(б) подготовку сообщений, обусловленных запросами;
(в) ассоциирование с каждым сообщением конкретного адреса для ответа, выбранного из множества адресов, доступных для получения сообщений от клиентских терминалов;
(г) посылку каждого сообщения по адресу, идентифицирующему клиента и ассоциированному с соответствующим запросом на обслуживание,
(д) получение ответов на сообщения на множество адресов;
(е) хранение информации, относящейся к ответам, в матрице, первая ось которой соответствует адресам, идентифицирующим клиентов, а вторая ось - адресам для ответов; и
(ж) оценивание ответов с использованием адреса, идентифицирующего клиента, и адреса для ответа.
| US 2001049638 А, 06.12.2001 | |||
| СИСТЕМА ПРЕДОСТАВЛЕНИЯ ПЛАТНЫХ УСЛУГ В ТЕЛЕКОММУНИКАЦИОННОЙ СЕТИ (ВАРИАНТЫ) | 2000 |
|
RU2167498C1 |
| US 5987467 A, 16.11.1999 | |||
| JP 2002092376 А, 29.03.2002 | |||
| ПОЛУПРОВОДНИКОВЫЙ МАЛОГАБАРИТНЫЙ КООРДИНАТНЫЙ ДЕТЕКТОР РЕНТГЕНОВСКОГО (РАДИАЦИОННОГО) ИЗЛУЧЕНИЯ | 2007 |
|
RU2367979C2 |
