(57)【要約】【課題】  本発明は、予約システムで予約を行い、複数の予約システム間で予約を同期させるための方法およびシステムに関する。【解決手段】  システムは、少なくとも１つの予約システム（１００）と、仲介者サービス（１０２）と、移動装置とすることができ、ダイロアグを含む少なくとも１つの顧客端末装置（１０４）を使用する顧客とを含む。顧客は、ダイアログを使用してシステムに情報を入力し、仲介者は、少なくとも１つの予約システム、少なくとも１つのサービス提供者、および少なくとも１つの顧客から、問い合せと回答を受信する。仲介者は、情報を上記３者の間で転送し、情報をそれらに適合させる。本発明の方法およびシステムは、スモール・メッセージ・サービス・メッセージを交換するモバイル電話ユーザが使用するのに特に適している。【選択図】  図１
2010205295.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ・ネットワーク上で通信を行い、コンピュータ・ネットワーク上で仲介者アプリケーション・サーバと通信する少なくとも１つのサービス提供者と複数の顧客との間で複数の予約を行う１つの仲介者として動作するように適合された仲介者アプリケーション・サーバであって、該複数の顧客の各々は、１つのそれぞれの顧客識別子アドレスを有し、ＳＭＳメッセージを使用して該仲介者アプリケーション・サーバと通信可能である１つのそれぞれの顧客端末装置を使用し、該仲介者アプリケーション・サーバは、
ａ）  該仲介者が該顧客端末装置から複数のＳＭＳメッセージを受信できる複数の加入者アドレスと、
ｂ）  ロジック及びリソースとを含み、該ロジック及びリソースは、
該顧客の該顧客端末装置に送信するために、該少なくとも１つのサービス提供者と１つの顧客とに関連する問い合わせに応答する一連の複数のＳＭＳメッセージを準備し、該一連の複数のＳＭＳメッセージの各々は、１つのそれぞれの回答を含み、
１つの異なる特定の応答アドレスを該一連の複数のＳＭＳメッセージの各々のＳＭＳメッセージと関連付け、該１つの異なる特定のアドレスは、該複数の加入者アドレスから選択され、
該顧客端末装置に該一連のＳＭＳメッセージの各々を送信し、
該複数のアドレスで、該顧客端末装置から、該送信された一連の複数のＳＭＳメッセージと関連する複数の応答ＳＭＳメッセージを任意の順序で受信し、該応答ＳＭＳメッセージの各々は、該顧客端末装置の該顧客識別子アドレスと、該応答ＳＭＳメッセージが関連する該送信された一連のＳＭＳメッセージに含まれる該１つのそれぞれの質問に対する１つの回答とを含み、該応答ＳＭＳメッセージの各々は、該応答ＳＭＳメッセージが関連する該送信された一連のＳＭＳメッセージと関連付けられた該１つの特定の応答アドレスで受信され、
顧客識別子アドレスによって索引付けされた第１の軸と応答アドレスによって索引付けされた第２の軸と回答によって索引付けされた第３の軸とを有する１つのマトリクスを使用して、送信された複数の質問と受信された複数の回答の追跡を行い、
該１つのマトリックスに、応答ＳＭＳメッセージの各々を保存し、
該含まれている顧客識別子アドレスと応答ＳＭＳメッセージが受信された該１つの特定の応答アドレスを使用して該応答ＳＭＳメッセージの各々を評価するように適合されたロジック及びリソースを含み、
それによって、該仲介者アプリケーション・サーバは、該応答ＳＭＳメッセージが受信された順序とは無関係に、該顧客がある質問に応答したか否か及びその回答が何であるのかを判定することか可能である仲介者アプリケーション・サーバ。
【請求項２】
請求項１に記載の仲介者アプリケーション・サーバにおいて、該顧客識別子アドレスは、顧客のＡ−加入者番号からなる識別子である仲介者アプリケーション・サーバ。
【請求項３】
請求項１に記載の仲介者アプリケーション・サーバにおいて、応答を評価する該ロジック及びリソースがさらに、該応答の各々のセマンティクスを分析する仲介者アプリケーション・サーバ。
【請求項４】
請求項１に記載の仲介者アプリケーション・サーバにおいて、該問い合わせが該顧客端末装置を識別する１つのサービス要求に応答する仲介者アプリケーション・サーバ。
【請求項５】
請求項１に記載の仲介者アプリケーション・サーバにおいて、該ロジック及びリソースが、異なる複数の加入者アドレスのうちどれが現在使用可能であるかを追跡するとともに、その現在使用可能なアドレスからランダムに各特定の応答アドレスを選択するように適合される仲介者アプリケーション・サーバ。
【請求項６】
請求項１に記載の仲介者アプリケーション・サーバにおいて、該一連の複数のＳＭＳメッセージのうちの少なくとも１つが、順序づけて配列された選択肢のリストから１つの項目を選択することによって回答できる１つの質問を含み、各選択肢は、順番を振られた位置を有する仲介者アプリケーション・サーバ。
【請求項７】
請求項１に記載の仲介者アプリケーション・サーバにおいて、該マトリックスが、該選択の該順番を振られた位置を保存するために索引づけされた第３の軸をさらに含む仲介者アプリケーション・サーバ。
【請求項８】
少なくとも１つのサービス提供者から１つの顧客のために複数のリソースの予約を実行する仲介者アプリケーション・サーバに関する方法であって、該仲介者アプリケーション・サーバは、少なくとも１つのサービス提供者とコンピュータ・ネットワーク上で通信し、複数の顧客と通信するように適合され、該複数の顧客の各々は、１つのそれぞれの顧客識別子アドレスを有し、ＳＭＳメッセージを使用して該仲介者アプリケーション・サーバと通信可能である１つのそれぞれの顧客端末装置を使用し、該仲介者アプリケーション・サーバは、該仲介者が該複数の顧客端末装置からの複数のＳＭＳメッセージを受信することが可能である複数の加入者アドレスを含み、該仲介者は、
ａ）  該顧客の該顧客端末装置に送信するために、該少なくとも１つのサービス提供者と１つの顧客とに関連する問い合わせに応答する一連の複数のＳＭＳメッセージを準備する動作を実行し、該一連の複数のＳＭＳメッセージの各々は、１つのそれぞれの回答を含み、
ｂ）  １つの異なる特定の応答アドレスを該一連の複数のＳＭＳメッセージの各々のＳＭＳメッセージと関連付ける動作を実行し、該１つの異なる特定のアドレスは、該複数の加入者アドレスから選択され、
ｃ）  該顧客端末装置に該一連のＳＭＳメッセージの各々を送信する動作と、
ｄ）  該複数のアドレスで、該顧客端末装置から、該送信された一連の複数のＳＭＳメッセージと関連する複数の応答ＳＭＳメッセージを任意の順序で受信する動作を実行し、該応答ＳＭＳメッセージの各々は、該顧客端末装置の該顧客識別子アドレスと、該応答ＳＭＳメッセージが関連する該送信された一連のＳＭＳメッセージに含まれる該１つのそれぞれの質問に対する１つの回答とを含み、該応答ＳＭＳメッセージの各々は、該応答ＳＭＳメッセージが関連する該送信された一連のＳＭＳメッセージと関連付けられた該１つの特定の応答アドレスで受信され、
ｅ）  顧客識別子アドレスに対応する第１の軸と応答アドレスに対応する第２の軸と回答に対応する第３の軸とを有する１つのマトリクスを使用して、送信された複数の質問と受信された複数の回答の追跡する動作と、
ｆ）  該１つのマトリックスに、応答ＳＭＳメッセージの各々を保存する動作と、
ｇ）  該含まれている顧客識別子アドレスと応答ＳＭＳメッセージが受信された該１つの特定の応答アドレスを使用して該応答ＳＭＳメッセージの各々を評価する動作とを実行し、
それによって、該仲介者アプリケーション・サーバは、該応答ＳＭＳメッセージが受信された順序とは無関係に、該顧客がある質問に応答したか否か及びその回答が何であったのかを判定することが可能である仲介者アプリケーション・サーバに関する方法。
【請求項９】
請求項８に記載の方法において、応答を評価する動作が、応答のセマンティクスを分析する動作をさらに含む方法。
【請求項１０】
請求項８に記載の方法において、１つの異なる特定の応答アドレスを該一連の複数のＳＭＳメッセージの各々のＳＭＳメッセージと関連付ける動作が、該特定の応答アドレスが無作為に選択されるように実行される方法。
【請求項１１】
請求項８に記載の方法において、該問い合わせが、該顧客端末装置からの１つのサービス要求に応答する仲介者アプリケーション・サーバ。
【請求項１２】
請求項８に記載の方法において、該顧客識別子アドレスは、顧客のＡ−加入者番号からなる識別子である方法。
【請求項１３】
請求項８に記載の方法において、該一連の複数のＳＭＳメッセージを準備する動作が、順序づけて配列された選択肢のリストから１つの項目を選択することによって回答できる形式で該一連の複数のＳＭＳメッセージのうちの少なくとも１つを準備する動作を含み、各選択肢は、順番を振られた位置を有する方法。
【請求項１４】
請求項１３に記載の方法において、第３の軸が、選択の該順番を振られた位置を保存するために索引づけされ、該方法が、該マトリックスの該第３の軸上に該選択を保存する動作をさらに含む方法。
【請求項１５】
請求項８に記載の方法を実行する仲介者アプリケーション・サーバとしてプログラミングされるネットワーク・サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、遠隔通信システムに関する。詳細には、本発明は、予約システムで予約を行い、少なくとも１つのサービス提供者と、仲介者サービスと、顧客と、移動装置とすることができ、ダイロアグを含む少なくとも１つの顧客端末装置とが関与する、少なくとも１つの予約システムを含む複数の予約システムで予約を同期させるための方法およびシステムに関する。さらに、本発明のシステムは、予約システムと、サービス提供者と、仲介者と、顧客端末装置とを接続するのに使用される遠隔通信接続を含む。
【背景技術】
【０００２】
インターネットを介して予約され、または利用されるサービスが増え続けている。インターネットから、銀行、医療サービス、旅行代理店、自動車整備などに接続された、いくつものオンライン・サービスを利用することができる。
【０００３】
移動コンピューティング／通信装置の普及が進んだことにより、インターネット上のサービスに新たな課題が加わった。移動端末は、ユーザが必要とするとき、必要な場所まで、情報を送り届けることができる。ユーザは、いつどこにいても、手元の装置から情報やアプリケーションにアクセスしたいと望む。ユーザはまた、どこにいようとも、こうした情報にアクセスし更新したいと望む。
【０００４】
しかし、すべての端末が移動端末であるわけではないことに留意することは重要である。将来のサービスは、移動体と非移動体の両方を含む多種多様な端末装置と通信できなければならない。異なる端末装置は、非常に異なった機能を有する。
【０００５】
異なるサービスおよび端末装置の相互運用を可能にするには、複数のレベルで規格が必要になる。例えば、共通の通信プロトコルをもつだけでは十分ではない。共通の概念と、あるデータがあるコンテキストで何を意味するかについての共通の理解とを共有することが非常に重要である。しかし、膨大な数の企業、組織、およびその他の当該分野の関係者が存在するため、これらの問題について同意を形成することは非常に困難である。
【０００６】
多くのサービスが予約を取り扱わなければならない。予約の例として、医療サービスへの予約、ホテル、航空便、レンタカーなど旅行関連の予約、催し物のチケット予約、自動車整備の予約、住宅補修の予約などがある。こうしたサービスが互いに情報を入手し合えれば、非常に有益であろう。例えば、顧客がコンサートのチケットを予約した場合、その顧客は、レストランにテーブルの予約も入れたいと思うかもしれない。レストランの予約サービスが、劇場の予約システムから、日付や顧客名などの基本情報を取得できれば都合がよい。残念ながら、種類が異なる予約システム間で情報を交換するための方法は存在していない。
【０００７】
サービス間で情報を交換するための多くの方法が存在する。予約またはカレンダ機能を含むサービスについて言えば、情報交換はしばしば、予約またはカレンダ入力を同期させる目的で行われる。この目的に関して、いくつかの重要な規格化の努力が続けられている。例えば、１つの共通データ同期プロトコルを開発し、その普及を図るための業界の第一歩として、ＳｙｎｃＭＬが提唱された。
【０００８】
ｖＣａｌｅｎｄａｒは、個人スケジュール情報用の交換フォーマットである。ｖＣａｌｅｎｄａｒは、多種多様なカレンダおよびスケジューリング製品に適用可能であり、様々な転送方法によって情報を交換する際に役立つ。多くの製造元がこの仕様を採用しているが、それは、その製品でカレンダおよびスケジュール情報を交換できるようにするためである。ｖＣａｌｅｎｄａｒは、ｘ／ＯｐｅｎおよびＸＡＰＩＡカレンダ／スケジューリングＡＰＩ（ＣＳＡ）、ＩＳＯ８６０１国際日時規格、および関連するＭＩＭＥ電子メール規格といった業界規格に基づく公開仕様である。ｖＣａｌｅｎｄａｒフォーマットは、カレンダおよびスケジューリング・アプリケーション内に普通に保存されたデータを利用し、イベントやトゥードゥー（ｔｏ−ｄｏ）といった項目に関する情報のクロス・プラットフォーム交換を円滑に行えるようにする。イベントは、カレンダ上の指定時間量を表すカレンダおよびスケジューリング・エンティティである。トゥードゥーは、行為項目または任務を表すカレンダおよびスケジューリング・エンティティである。例えば、トゥードゥーは、ある人に割り当てられた作業項目とすることができる。
【０００９】
ｖＣａｒｄは、一般に従来の名刺に記されている個人情報の交換を自動化する。ｖＣａｒｄは、インターネット・メール、ボイス・メール、ウェブ・ブラウザ、テレフォニ・アプリケーション、コール・センタ、ビデオ会議、ＰＩＭ（個人情報マネージャ）、ＰＤＡ（携帯情報端末）、ポケット・ベル、ファックス、オフィス機器、スマート・カードといったアプリケーションで使用される。ｖＣａｒｄ情報には、文字列に加えて、画像、企業ロゴ、ライブ・ウェブ・アドレスなどの要素も含まれ得る。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００２−０４１７６２号公報
【特許文献２】特開２０００−１６３４７９号公報
【特許文献３】特開２０００−１２２９９７号公報
【特許文献４】特開２００２−０４１５８０号公報
【特許文献５】特開２００１−１２５９３２号広報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上記の例が示すように、予約システムを同期させることのできるシステムを構築するため、多くの努力がなされてきた。これら既存のソリューションのすべてに共通する問題は、どのソリューションも、異なるシステムが互いに共有できる共通のセマンティクスを提供しないことである。例えば、入力が不確かであれば、異なるシステムはそれを異なる方法で解釈するかもしれない。
【００１２】
別の問題は、予約システムが複数の異なる、通常は非常に複雑なユーザ・インタフェースをもつことである。歯科医の予約を入れ、そこまで乗っていくタクシーも予約したい場合、顧客は、すべての予約情報を両方の予約システムに異なる方法で入力する必要がある。
【００１３】
さらに別の問題は、顧客に複数の質問をしたときに、顧客からの回答を管理するのが至難の業となることである。例えば、フィンランドをはじめ多くの国では、ＳＭＳテキスト・メッセージで通信を行うのはごく当たり前のことであり、ＳＭＳテキスト・メッセージが通信事業者の収入源となっているので、ＳＭＳテキスト・メッセージを使用して、どちらの選択肢を選択するかを顧客に尋ねることは道理にかなっている。しかし、顧客が複数のテキスト・メッセージを送信して、複数の質問に回答した場合、質問を指し示す情報が自動的に回答に含まれることはないので、どの回答がどの質問に対応するのかを明らかにすることが困難となることがある。例えば、航空便のチケットに加えて、タクシーとホテルの部屋も予約したいかどうか、サービスが顧客に質問し、一方の質問には「イエス」、もう一方の質問には「ノー」と顧客が回答した場合、顧客がどちらの申し出を了承したのか、サービスが常に判別できるとはかぎらない。
【課題を解決するための手段】
【００１４】
本発明の目的は、上述した短所を解消すること、または少なくともそれらを著しく縮減することである。本発明は、特に移動サービスにとって必須の新しいタイプの付加価値サービスを可能にする。
【００１５】
本発明のさらなる目的は、少なくとも１つのサービス提供者と、ショート・テキスト・メッセージを送受信可能なモバイル電話を用いて通信を行う複数のユーザとが関与する、予約タイプのトランザクションの実行を可能にする方法およびシステムを提供することである。
【００１６】
本発明のさらなる目的は、複数のサービス提供者と、ショート・テキスト・メッセージを送受信可能なモバイル電話を用いて通信を行う複数のユーザとの間で、予約タイプのトランザクションの実行を可能にする方法およびシステムを提供することである。
【図面の簡単な説明】
【００１７】
【図１】本発明による第１の有利なシステムの図である。
【図２】本発明による第２の有利なシステムの図である。
【図３】本発明による第３の有利なシステムの図である。
【図４】本発明による、システム内で送信されるメッセージの第１の有利なシーケンス例を表す図である。
【図５】システム内で送信されるメッセージの第２の有利なシーケンス例を表す図である。
【図６】本発明による、問い合せと応答に適用される動的ダイアログ・マトリックスの例を示す図である。
【図７】本発明の好ましい実施形態における予約プロセスのフェーズを示す図である。
【図８】本発明の好ましい実施形態による、実施例２に対応するマトリックス図である。
【発明を実施するための最良の形態】
【００１８】
以下のセクションで、本発明の実施形態の例をいくつか挙げて、本発明を詳しく説明する。
【００１９】
本発明は、予約システムとユーザ端末装置との間で行われる情報の交換および同期に関する。サービスの例として、医療サービスへの予約、ホテル、航空便、レンタカーなど旅行関連の予約、催し物のチケット予約、自動車整備の予約、住宅補修の予約などがある。
本発明による予約システムは、少なくとも１つのサービス提供者の予約システムと、少なくとも１つのサービス提供者と、仲介者と、顧客と、テキスト・メッセージを受信可能な移動装置とすることができ、ダイロアグを含む少なくとも１つの顧客端末装置と、遠隔通信接続とを含み、遠隔通信接続は、サービス提供者の予約システムと、サービス提供者と、仲介者と、顧客端末装置とを互いに接続するのに使用される。
【００２０】
サービス提供者とは、顧客が面会予約（ａｐｐｏｉｎｔｍｅｎｔ）、確保予約（ｒｅｓｅｒｖａｔｉｏｎ）、またはその他の予約（ｂｏｏｋｉｎｇ）を入れたいと思う相手のことであり、予約システムが割り当てるリソースを含む。サービス提供者は、サービス提供者の予約サービスによって事業を行う。本出願における仲介者とは、サービス提供者の予約サービスがネットワークを介して利用可能なネットワーク・ベースのサービスのことであり、ネットワークは、顧客がサービス提供者相手のトランザクションを遂行するのに必要な情報を伝達するのに必要となる、追加のセマンティクス、変換、および同期サービスを提供する。サービス提供者の予約サービスおよび仲介者は好ましくは、インターネットや私設イントラネットなどにおけるネットワーク・サーバ上で動作するアプリケーションである。一般に、本発明のシステムは、複数のサービス提供者および（サービス提供者の予約サービスを実施する）サービス提供者の予約システムを含むが、サービス提供者が１つだけの簡単な予約システムを有することも可能であり、その場合、仲介者とサービス提供者とを、単一のアプリケーションとして密接に統合することができる。
【００２１】
顧客は好ましくは、ショート・メッセージ・サービス（ＳＭＳ）メッセージなどのショート・テキスト・メッセージを受信可能なモバイル電話を用いて通信を行う顧客を含む。もちろん、ＳＭＳメッセージを取り扱うことのできるシステムは、より高度な機能を用いるその他の顧客にも対応する。仲介者は好ましくは、モバイル電話プロバイダによって運営され、今日よく知られているＳＭＳゲートウェイを介して、モバイル電話顧客と通信を行う。仲介者は、ダイアログを使用して顧客と通信を行う。ダイアログは、顧客に情報を提示し、簡単な回答を可能にするショート・メッセージである。ダイアログは好ましくは、イエス／ノー形式の簡単な選択肢をユーザに提示し、または順序づけられたリストからの選択を可能にする。ダイアログは、予約の受け付け通知など、一方向メッセージとすることもできる。トランザクションは一般に、一連のダイアログを含むことができ、各ダイアログには簡単な応答が伴う。ダイアログにはメッセージによる非同期通信が関係する。上述したシステムは、顧客の必要を満たすため、異なるサービス提供者のシステム間で予約を連動させること、例えば、航空便の予約と空港への交通機関の予約の連動を可能にする。
【００２２】
図１は、単一のサービス提供者向けの単一のサービス提供者予約システム１００と、ネットワークを介してサービス提供者と通信を行う仲介者１０２と、ダイアログが提示されるモバイル電話を有するユーザとを含む最も簡単なシステムの図である。
【００２３】
図２には、ネットワークを介して仲介者と通信を行う複数のサービス提供者予約システムが示されている。
【００２４】
図３には、様々なサービス提供者システムおよびダイアログを伝えるモバイル電話を有するユーザと通信を行う、ＢｏｏｋＩＴと名づけられた仲介者が示されている。
【００２５】
理由ベースの顧客ダイアログは、サービス提供者が各予約イベントに関連して独自のダイアログを作成することができるので、顧客の観点から見て望ましい改良である。ダイアログは、ある予約状況に密接に関連している。ダイアログは適切な時点に自動的に活動状態になり、または顧客が必要に応じてダイアログを活動化することができ、またはシステム内の別のエンティティがダイアログにメッセージを送信して、ダイアログを活動化することができる。次にダイアログは、システム内の別のエンティティに問い合せを送信するか、または顧客に通知を出し、おそらくは顧客の選択を問い合わせる。このタイプのダイアログによって、顧客は１つのユーザ・インタフェースだけを使用して、複数の予約システムに予約を入れることができる。ダイアログは、例えば、インターネットを介して、または移動体ネットワークさえも介して、リモート予約システムに接続する。
【００２６】
仲介者サービスは、サービス提供者の予約システム間で予約情報を送信することができる。例えば、航空便予約システムに予約が入力された後、タクシー予約システムが、空港までの乗車を顧客に勧めることができる。この適用例では、予約記帳（ｂｏｏｋｉｎｇ）は、各リソース毎に（先の例では、航空便予約またはタクシー予約毎に）割り当てられるが、予約（ｒｅｓｅｒｖａｔｉｏｎ）は、同じイベントに関するすべてのリソースの予約記帳を合併したもの（先の例では、航空便予約とタクシー予約を合併したもの）となる。顧客と仲介者と予約システムの間のダイアログ、および保存された顧客個人情報を用いることで、顧客は、押し付けがましい広告ではなく、顧客が必要とするサービスの理由に基づいた提供を確実に受けられるようになる。
【００２７】
顧客は予約を入れるばかりでなく、予約の確認、変更、および取り消しを、インターネット、電子メール、および移動端末をはじめとする、しかしこれらに限定されない、様々なタイプの通信手段を使用して行うことができる。顧客はまた、仲介者の同期機能を使用して、仲介者またはサービス提供者によって提供されるカレンダと端末装置のカレンダとを同期させることもできる。
【００２８】
サービス提供者は定期的に、予約申し込みについて顧客の注意を喚起することができ、したがって、顧客忠実度を向上させることができる。仲介者は、サービス提供者の予約システムを統合して、それぞれが事業を必要以上に拡張することなく、より総合的なサービスを提供できるよう、サービス提供者を支援する。国際化に合わせて、仲介者は、例えば、多くの言語、タイム・ゾーン、通貨、およびデータ・フォーマットをサポートすることができる。
【００２９】
少なくとも１つのダイアログ、仲介者、サービス提供者、およびサービス提供者の予約システムを含むシステムは、以下に示すレベルのいずれか１つにあることができる。
【００３０】
１．システムにダイアログの所定の組が存在する。その内容および可能な選択肢はあらかじめ設定されている。例えば、顧客が航空便を予約した場合、ダイアログは常に一定のその他の予約を提案する。顧客がその前に行った行為は考慮されない。
【００３１】
２．例えば、顧客が自ら作成した個人情報、使用履歴、および顧客所在地などに基づいた、動的または「知的」ダイアログがいくつでも存在する。簡単なロジックが判断を支援する。これは低レベルのエキスパート・システムである。
【００３２】
３．システムは自ら判断を行うことができ、顧客の意思決定を支援することができる。このレベルでは、ダイアログは高レベルのエキスパート・システムを含むことができる。ダイアログはエージェントとして動作することができ、複数のサービス提供者と交渉を行って、顧客の直接の関与なしに、最適の提案を得ることができる。
【００３３】
本発明の方法の好ましい実施形態では、顧客はサービス提供者が提供するサービスを予約する。予約は、仲介者サービスに接続された端末を使用して実行することができる。初めに、顧客は、ダイアログを使用して仲介者サービスに接続する。顧客は予約問い合せをダイアログに入力し、ダイアログはその問い合せを仲介者に送信する。仲介者は、可能性のある予約についてサービス提供者の情報システムに、それらのサービスが解釈できる概念および用語を使用して問い合せを行う。問い合せは、顧客の選好に基づいている。顧客は、予約問い合せをダイアログに入力するとき、特定の予約に関連するいくつかの選好を明らかにする。さらに、ダイアログおよび仲介者サービスは、顧客が毎回すべての選好を入力しないですむように、顧客の通常時の選好を保存しておき、それらを使用することができる。
【００３４】
問い合せおよび予約の管理は、高度な状態モデルに基づいている。各予約は、複数のフェーズを含み、フェーズはそのステータスを存続期間にわたって追跡する状態によって記述される。例えば、仲介者が予約についてサービス提供者に問い合せを行った場合、各システムの対応するエントリは、予約が懸案中であり承認されていないことを示す状態を有する。ある状態が意味する内容について各システムが共通の理解を有していない場合、仲介者が状態の翻訳を行う。フェーズおよび状態を含む好ましい予約プロセスについて、実施例１で説明する。
【００３５】
サービス提供者に予約を問い合わせるのに加えて、仲介者は、複数のサービス提供者システムで予約を同期させることができる。同期は、仲介者サービスで内容が定められた規則に基づいている。例えば、規則は、「顧客が航空便のチケット予約の問い合せを行った場合、空港へのタクシー予約についても質問せよ」というものにすることができる。したがって、顧客からの問い合せは、仲介者サービスで数を増し、複数の問い合せとなる場合がある。サービス提供者は、要求されたサービスを提供できるかどうか、また座席や時刻など追加の情報をいくつか追加できるかどうかを仲介者に回答する。仲介者は、収集した情報を一まとめにしてダイアログに送信し、ダイアログは選択肢の簡単なリストを顧客に提示する。例えば、ダイアログは、航空便に関する３つの選択肢を提示し、すでに暫定的に仲介者によって予約されているタクシーの予約も顧客が希望するかどうかを質問することができる。顧客は、選択肢の簡単なリストから希望項目を選択することによって、決定を下すことができる。ダイアログは、顧客選択情報を仲介者に送信し、仲介者は、顧客選択に従って予約を確定し、不必要な予約を取り消す。
【００３６】
図４には、顧客によって発行され、ダイアログＤＩＮＱ１を使用して仲介者に送信される問い合せＣＩＮＱ１のシーケンス図が示されている。仲介者は、ＣＩＮＱ１およびＤＩＮＱ１に対応する問い合せＭＩＮＱ１を、サービス提供者予約システムである予約システム１に宛てて発行する。最終的に、顧客には選択を求める応答ＤＡＮＳ１が返送され、顧客は選択ＣＳＥＬ１によってそれに回答し、予約システム１に予約を入れる。仲介者は、予約サービス２が提供する補足的なサービスに対する潜在的な必要を認識し、予約システム２に宛てて問い合せＭＩＮＱ２を発行する。その結果、最終的に、複数の選択肢を含む提案ＤＡＮＳ２が顧客に返送され、そこから選択ＣＳＥＬ２が行われ、予約システム２に補足的な予約が入れられる。
【００３７】
予約は、他の手段でも同様に、例えば、サービス提供者に電話をかけることによって、またはサービス提供者のオフィスに出向くことによっても行うことができる。その場合、サービス提供者は、顧客の予約について仲介者に通知して、仲介者が顧客にその他の選択事項を通知できるようにする。例えば、歯科医は、顧客が予約を入れたことを仲介者に知らせて、仲介者がタクシー予約も提案できるようにすることができる。
【００３８】
また、仲介者サービスに注意喚起機能を追加して、定められた時になると、仲介者が顧客に新規予約を入れたいかどうかを尋ねるようにすることもできる。例えば、仲介者は、最後に歯科医に予約を入れてから１年たつことを知らせる通知を顧客に送信し、顧客が新規予約を入れたいかどうかを尋ねることができる。顧客が許可していれば、仲介者は顧客のカレンダをチェックして、提示する選択項目が顧客に便利なものになるようにする。ダイアログは、簡単で扱いやすい方法で選択項目を提示する。顧客は、自分にとって最適な選択項目を選択しさえすればよく、または新たな選択項目の提示もしくは予約の見送りを求める旨を選択しさえすればよい。図５は、最初の問い合せＭＩＮＱ１が仲介者によって発行された状況についてのタイム・シーケンス図である。
【実施例１】
【００３９】
好ましい予約システム
本発明による好ましい予約システムを、ＢｏｏｋＩＴと名づけるシステムに関して、以下で説明する。
【００４０】
ＢｏｏｋＩＴは、インターネットなどのネットワークを介してサービス提供者とその他の当事者との間のインタフェースをとるため、またテキスト・メッセージを受信可能なモバイル電話を携行するエンド・ユーザ顧客とのインタフェースをとるために設計されている。前者は好ましくは、一般的なＸＭＬインタフェースによって達成される。ｖＣａｒｄおよびｖＣａｌｅｎｄａｒはすべての主要な予約およびカレンダ・システムで使用されるので、ＢｏｏｋＩＴもｖＣａｒｄおよびｖＣａｌｅｎｄａｒ規格をサポートする。
【００４１】
ＢｏｏｋＩＴは、非同期通信用のＳＭＳゲートウェイを介したショート・メッセージ・サービス（ＳＭＳ）を使用して、モバイル電話ユーザと通信を行う。ＢｏｏｋＩＴは、安全な転送およびＳＭＳメッセージのマッピングのため、新規な動的ダイアログ・マトリクス（ＤＤＭ）を使用する。ＤＤＭについては以下でさらに説明する。
【００４２】
サービス提供者の予約システムとＢｏｏｋＩＴプロセスとを明確に区別する必要がある。前者は、時間とリソースの予約のみが関係する標準的な予約を取り扱う。後者は、予約、実行、および会計から構成される。両プロセスとも目的とするところは同じである。ＢｏｏｋＩＴプロセスは、以下の７つのフェーズから構成される。
【００４３】
フェーズ（ステータス処理）
フェーズは、（ゴム・バンドのように）リソースどうしを結びつける。予約に関連するデータは、ＢｏｏｋＩＴプロセスの各フェーズにおいて、それぞれのフェーズでの必要性を反映して変更される。ステータスおよび値については、以下に示す表を参照されたい。
【００４４】
各フェーズについて、以下でより詳細に説明する。
１．ファイリング
ファイリングは、ＢｏｏｋＩＴプロセスおよび予約プロセスの初期設定を意味する。初期設定の結果、基本情報を有するエントリがデータベースに挿入される。スケジュール情報は有していないので、このエントリはカレンダには現れない。このエントリは、オープン・タスクとして、オーナ別のタスク・リストに表示することができる。
【００４５】
２．要求
要求フェーズでは、予約要求が、先にファイリングされたタスクが必要とするリソースに送信される。ほとんどのケースで必須のスケジュール情報がないので、このフェーズは、スケジューリング・フェーズと一緒に実行することができる。
【００４６】
３．スケジューリング
スケジュールが、オーナおよびリソースに与えられる。スケジューリングの一部として、また結果として、以下のデータが必要とされる。
ａ  提案開始時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｂ  提案開始場所（座標）
ｃ  提案終了時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｄ  提案終了場所（座標）
【００４７】
４．確定
承諾したリソースによってそれが承諾されたときの時刻および場所。このフェーズに関連するデータは、
ａ  承諾開始時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｂ  承諾開始場所（座標）
ｃ  承諾終了時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｄ  承諾終了場所（座標）
である。
【００４８】
デフォルトでは、上記データは、プランニング・フェーズからコピーされる。
実行する上で、プランニングされた時刻が必要でない場合、これのために同じデータ構造を使用することができ、ステータスは実際の意味のデータを指示する。
【００４９】
５．実行
リソースが予約されたタスクを実行する。このフェーズに関連するデータは、実際のタスクに関連する異なる属性および値から構成される。さらに、以下の静的構造も必要とされる。
ａ  実際開始時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｂ  実際開始場所（座標）
ｃ  実際終了時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｄ  実際終了場所（座標）
ｅ  使用される製品、追加料金、マイレージ、・・・
【００５０】
デフォルトでは、上記データは、確定フェーズからコピーされる。
１．会計
このフェーズで、以前のフェーズにおいてデータ構造に保存されたすべてのデータが、請求書作成の目的で分析され、処理される。
このフェーズに関連するデータは会計データであり、別途定義される。
【００５１】
７．完了
タスクが完了する。ＢｏｏｋＩＴ全体の観点からは、タスクが正常に完了したかどうかは問題とされない。問題となるのは、オーガナイザへの会計行為が処理される会計フェーズにおいてである。このフェーズでは、ＢｏｏｋＩＴプロセスを完了するため、（データベース内容、一時ファイルなどの）ハウスキーピングが行われる。
各フェーズで利用可能なデータを以下の表に示す。予約フェーズはイタリックで示してある。
【００５２】
【表１】
2010205295.tif 000003
【００５３】
フェーズ・ステータス、値、および遷移
以下の表には、フェーズ、そのステータス、および値が、とる値に基づいた次の論理フェーズへの遷移と併せて示されている。さらに、適用可能な場合には、対応するｖＣａｌｅｎｄａｒステータスも示されている。
【００５４】
【表２】
2010205295.tif 000004
内部フェーズである休止、再開、取り消しは、すべての関連フェーズについて任意の時点で以下のように動作する。
【００５５】
【表３】
2010205295.tif 000005
【００５６】
図６に、フェーズからフェーズへのワーク・フロー遷移が示されている。条件については、上記の表を参照されたい。また、取り消しステータスは常に会計に遷移することに留意されたい。
【００５７】
予約（全体）の確定
予約全体が正常に完了するには、予約を受諾したすべてのリソースが、同じスケジューリングをもつ必要がある。さらに、異なる役割にリソースがあり、実行フェーズに関連するデータは大きく異なることができる。
【００５８】
予約全体についての様々なステータスを以下に示す。
ａ  「応答なし」（０）は、「オーガナイザが行った要求に誰も応答していない」場合。
ｂ  「拒否なし」（１）は、「被要求者がまだ全員は応答していないが、応答した者は承諾している」場合。
ｃ  「全員承諾」（２）は、「被要求者が全員許諾した」場合。
ｄ  「一部拒否」（３）は、「一部の被要求者が拒否した」場合。
ｅ  「全員拒否」（４）は、「被要求者が全員拒否した」場合。
以下の判定表は、予約全体のステータスを評価する際に役に立つ。「不確定」は、この条件だけでは結果の真偽を明白に確定できないことを意味する。
【００５９】
【表４】
2010205295.tif 000006
【００６０】
情報および上記の判定表に基づいて、オーガナイザ／アプリケーションは、予約をどのように処理するかを決定しなければならない。これは、事前設定された規則に基づいてシステムが自動的に決定することができ、またはオーガナイザが人手を介して決定することもできる。
【００６１】
本発明によって解決される主要な問題の１つは、顧客に複数の質問が提示され、顧客がＳＭＳテキスト・メッセージ、または問い合せを明示的に指示する情報が回答に自動的に含まれない類似の技術を使用しているときに、顧客の回答を管理するのが難しいという問題である。本発明は、動的ダイアログ・マトリックスを使用して、この問題を解決する。問い合せは常に、何らかのタイプの受信機アドレスまたは識別情報を含む。ＳＭＳテキスト・メッセージの場合、これは、いわゆる、Ｂ加入者番号と呼ばれる。一方、送信側のＡ加入者番号もしくは発呼線識別情報（ＣＬＩ）、または類似の識別情報も、各テキスト・メッセージに付加される。したがって、顧客またはＢ加入者は通常、移動装置の回答または応答機能を使用して、容易に回答することができる。顧客に問い合せを送信する仲介者サービスが、異なる問い合せに異なるＡ加入者番号を使用するならば、顧客がどの番号に回答を送信しているかに基づいて、回答を識別することが可能になる。例えば、仲介者が顧客に、Ａ加入者番号Ａ１を使用して問い合せ「タクシーも予約しますか？」を送信し、次にＡ加入者番号Ａ２から問い合せ「ホテルの部屋も予約しますか？」を送信した場合、第１の質問に対する顧客の回答は番号Ａ１に返送され、第２の回答は番号Ａ２に返送される。仲介者は、ダイアログ・マトリックスを使用して、問い合せと回答とを追跡する。マトリックスでは、列が各顧客に、行が仲介者の使用する各Ａ加入者番号に対応する。同様に、行を各顧客に対応させ、それに伴い、列を各Ａ加入者番号に対応させることも可能なことは明らかであろう。あるＡ加入者番号から顧客に問い合せを送信した後、ステータスおよび回答が、マトリックスの対応するシェルに格納される。その結果、仲介者は、顧客がある問い合せに回答したかどうか、またどのような回答内容であるかを知ることができる。また、マトリックスを使用して顧客行動についての情報を収集し、例えば、それをマーケティングのために使用することも可能である。仲介者は、限られた数のＡ加入者番号が必要なだけである。ダイアログ・マトリックスは、ある顧客に次の問い合せを送信する際に、どのＡ加入者番号が使用できるかを知るのに使用することもできる。
【００６２】
図７に、上述した動的ダイアログ・マトリックスの使用の様子を示す。
動的ダイアログ・マトリックスは、メッセージを送受信する能力だけを有するモバイル電話ユーザを認証するための、強力でありながら非常に簡潔なセキュリティ対策となる。問題は、サービスが送信者の識別情報を確認することである。ユーザの識別を試みるための１つの方法は、送信者のアドレスをチェックすることである。通常、ＳＭＳ、電子メール、およびその他の同様のメッセージには、送信者アドレスが付加されている。そのアドレスは、例えば、送信者のＡ加入者番号もしくは発呼線識別情報（ＣＬＩ）、電子メール・アドレス、またはＩＰアドレスとすることができる。しかし、送信者のアドレスを改ざんするのは非常に容易である。サービス提供者から見て、サービス提供者からユーザへのダウンリンクは、一般に比較的信頼でき、他者がメッセージを捕捉したり、変更したりするのは難しいが、ユーザからサービス提供者へのアップリンクは、はるかに攻撃を受けやすく、偽りの送信者アドレスを与えることはそれほど難しくはない。上記の問題に対するよく知られたソリューションは、通信の安全を確保する暗号技術、例えば、公開鍵基盤（ＰＫＩ）を使用するというものである。例えば、ユーザ装置は、ユーザの秘密鍵を使用してメッセージを暗号化するため、マイクロチップを、ＧＳＭ装置であればセキュアＳＩＭカードなどを備えることができる。サービス提供者は、ユーザの公開鍵を使用してメッセージを復号できれば、それがユーザからのものであると確信することができる。しかし、このソリューションは、あまり一般的でなく、安価でなく、またはこれまで規格化されていない特殊な装置を必要とする。そのようなソリューションに頼っていては、潜在的ユーザの数が著しく制限される。
【００６３】
ＤＤＭを使用することによって、新規なソリューションが提供される。サービスがモバイル電話ユーザに要求を送信する場合、各要求には、異なる、好ましくは無作為に選択された、応答番号が含まれる。したがって、受け入れてもよい回答は、正しい応答アドレスに送信された回答だけである。
【実施例２】
【００６４】
動的ダイアログ・マトリックスの使用法
この簡単な例は、翌朝の航空便のチケットの入手について述べたものである。システムは、短い応答を必要とするＳＭＳメッセージとして一連の質問を送信する。各メッセージには、応答を識別できるように目印が付けられているので、論理的に要求されない限り（例えば、ある質問に対する回答が次の質問の内容に影響するなど）、必ずしも特定の順序でメッセージを送信したり、メッセージに応答したりする必要はない。
【００６５】
電話番号がＩＤ＝０４１８  ９７９  ８１３であるユーザが、チケットを要求する。システムは、以下の要求を個々のＳＭＳメッセージとして送信する。
以下の出発時刻から１つを選択してください。
６：００  ａ．ｍ．：回答Ａ
７：３０  ａ．ｍ．：回答Ｂ
８：１５  ａ．ｍ．：回答Ｃ
上記以外：回答Ｄ
送信者：＋３５８４４０８４４  ０２７
チケット・クラスを選択してください。
ファースト・クラス：回答Ａ
ビジネス・クラス：回答Ｂ
エコノミ・クラス：回答Ｃ
最も安い入手可能チケット：回答Ｄ
送信者：＋３５８４４０８４４  ０１１
選択してください。
窓側の席：回答Ａ
通路側の席：回答Ｃ
送信者：＋３５８４４０８４４  ０３４
機内食を選択してください。
野菜食：回答Ａ
ビーフ：回答Ｂ
チキン：回答Ｃ
送信者：＋３５８４４０８４４  ００３
【００６６】
上記およびその他のいくつか質問に対して顧客から受信した回答は以下のようであった。
参照番号＋３５８４４０８４４  ０２７の質問に対して「Ａ」
参照番号＋３５８４４０８４４  ０１１の質問に対して「Ｄ」
参照番号＋３５８４４０８４４  ０３４の質問に対して「Ａ」
参照番号＋３５８４４０８４４  ００３の質問に対して「Ｂ」
参照番号＋３５８４４０８５９  ７５１の質問に対して「Ｄ」
参照番号＋３５８４４０８４４  ２７７の質問に対して「Ａ」
参照番号＋３５８４４０８４１  ３６８の質問に対して「Ｃ」
この結果から、サービス提供者は顧客が、
朝一番の航空便            （＝Ａ）
最も安い入手可能チケット  （＝Ｄ）
窓側の席                  （＝Ａ）
ビーフの機内食            （＝Ｂ）
などを選択したことを知ることができる。
【００６７】
マトリックスを用いれば、顧客は好きな順序で質問に回答できること、いくつかの質問には回答しなくてもよいことに留意することが重要である。未回答の質問に回答が必要であれば、システムは回答を促すことができる。回答が必要なければ、システムは、その情報なしで処理を行うことができる。
【００６８】
図８に、上記の応答を３次元マトリックスとして示す。顧客番号がＸ軸に、応答番号がＹ軸に、回答がＺ軸にプロットされている。電話番号が０４１８  ９７９  ８１３であるユーザは、Ｘ軸の最も左のユーザである。Ｙ軸の応答番号に対応する回答が、Ｚ軸にプロットされている。
【００６９】
セキュリティ補強は、セマンティクス分析を使用して達成される。マトリックス・セルには、問い合せの情報と、どのような回答であれば受け入れられるかについての情報をもつことができる。回答が基準を満たさなければ、その回答は拒否される。例えば、サービス提供者がユーザに注文数を回答するよう求めたときに、ユーザが「イエス」と回答したならば、明らかにユーザは質問の内容を知っておらず、そのメッセージは問い合せに対する回答ではない。
【００７０】
上記のサービス提供者は実際には仲介者であり、「本当の」サービス提供者はどこか他の場所にいることも可能である。その場合、仲介者だけがマトリックス・ベース・システムをもてばよく、実際のサービス提供者は、仲介者のマトリックス・システムまたは暗号化チャネルのようなその他の安全な手段を使用して、仲介者と通信を行う。例えば、自動車共用システムを以下のようにして実施することができる。自動車は成り行き任せに市内のあちこちに駐車されている。ユーザは、自動車が必要になると、どこに最も近い自動車があるかを尋ねるメッセージを仲介者に送信する。仲介者は、自動車の所在地を知らせるメッセージを送信する。その回答は無作為のアドレスｙ’から届く。ユーザは、自動車の所に到着すると、レンタル時間の開始を申告するとともに、自動車のロックを遠隔操作で解除するよう仲介者に求めるメッセージをｙ’に送信する。このメッセージは、ユーザだけが知っているアドレスに送信されるので、比較的信頼性が高い。したがって、メッセージは、ロックを解除し、請求を開始するための妥当な理由となる。一方、仲介者と自動車の間の通信は、ユーザにも第三者にも秘匿されている。自動車は特殊な装置を装備しているため、ロック解除などの遠隔指令は暗号化することができる。または、自動車と仲介者の間の通信も、マトリックスを使用して実施することができる。いずれの場合も、仲介者はユーザと自動車の間の「ファイアウォール」として機能し、第三者が権限なしに自動車を使用できないようにする。
【００７１】
本発明を、いくつかの好ましい実施形態を参照しながら、かなり詳しく説明してきたが、その他の実施形態も可能である。したがって、添付の特許請求の範囲の主旨および範囲は、本明細書の好ましい実施形態に限定されるものではない。
【図１】
2010205295.tif 000007
【図２】
2010205295.tif 000008
【図３】
2010205295.tif 000009
【図４】
2010205295.tif 000010
【図５】
2010205295.tif 000011
【図６】
2010205295.tif 000012
【図７】
2010205295.tif 000013
【図８】
2010205295.tif 000014