Способ и система приема заказов

Способ и система приема заказов

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

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

Уровень техники

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

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

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

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

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

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

В принципе может иметься множество способов обмена информацией между различными сервисами. Применительно к услугам, которые включают прием заказа или календарные функции, обмен информацией часто принимает форму синхронизации заказов или ввода календарной информации. В этой связи реализуется несколько серьезных инициатив по стадартизации. Например, по инициативе промышленности осуществляется разработка и продвижение проекта 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 указаны данные, доступные на каждом этапе. Данные по этапу оформления заказа выделены шрифтом.

Таблица 1
Обращение	Х					X
Запрашивание	Х	Х				X
Составление расписания	Х	Х	Х			X
Подтверждение	Х	Х	Х	Х	X
Выполнение	Х	Х	Х	Х	Х	X
Отчетность	Х	Х	Х	Х	Х	X
Завершение	Х	Х	Х	Х	Х	X	X
Этап/Данные	Идентификац.	Ресурсы	Предлагаемое время	Принятое время	Данные о выполнении задания	Отчетность	Закрытие

Статусы этапов, значения и переходы

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

Таблица 2
Этап	Статус	Следующий этап	vEvent	vTodo
Обращение		Запрашивание
Запрашивание		Составление расписания	Отправлено	Отправлено
Составление расписания	Ожидается	Подтверждение	Требуется действие	Требуется действие
Составление рас