JP2005535988A - 予約方法およびシステム - Google Patents

Abstract

本発明は、予約システムで予約を行い、複数の予約システム間で予約を同期させるための方法およびシステムに関する。システムは、少なくとも１つの予約システム（１００）と、仲介者サービス（１０２）と、移動装置とすることができ、ダイロアグを含む少なくとも１つの顧客端末装置（１０４）を使用する顧客とを含む。顧客は、ダイアログを使用してシステムに情報を入力し、仲介者は、少なくとも１つの予約システム、少なくとも１つのサービス提供者、および少なくとも１つの顧客から、問い合せと回答を受信する。仲介者は、情報を上記３者の間で転送し、情報をそれらに適合させる。本発明の方法およびシステムは、スモール・メッセージ・サービス・メッセージを交換するモバイル電話ユーザが使用するのに特に適している。

Description

本発明は、遠隔通信システムに関する。詳細には、本発明は、予約システムで予約を行い、少なくとも１つのサービス提供者と、仲介者サービスと、顧客と、移動装置とすることができ、ダイロアグを含む少なくとも１つの顧客端末装置とが関与する、少なくとも１つの予約システムを含む複数の予約システムで予約を同期させるための方法およびシステムに関する。さらに、本発明のシステムは、予約システムと、サービス提供者と、仲介者と、顧客端末装置とを接続するのに使用される遠隔通信接続を含む。

インターネットを介して予約され、または利用されるサービスが増え続けている。インターネットから、銀行、医療サービス、旅行代理店、自動車整備などに接続された、いくつものオンライン・サービスを利用することができる。

移動コンピューティング／通信装置の普及が進んだことにより、インターネット上のサービスに新たな課題が加わった。移動端末は、ユーザが必要とするとき、必要な場所まで、情報を送り届けることができる。ユーザは、いつどこにいても、手元の装置から情報やアプリケーションにアクセスしたいと望む。ユーザはまた、どこにいようとも、こうした情報にアクセスし更新したいと望む。

しかし、すべての端末が移動端末であるわけではないことに留意することは重要である。将来のサービスは、移動体と非移動体の両方を含む多種多様な端末装置と通信できなければならない。異なる端末装置は、非常に異なった機能を有する。

異なるサービスおよび端末装置の相互運用を可能にするには、複数のレベルで規格が必要になる。例えば、共通の通信プロトコルをもつだけでは十分ではない。共通の概念と、あるデータがあるコンテキストで何を意味するかについての共通の理解とを共有することが非常に重要である。しかし、膨大な数の企業、組織、およびその他の当該分野の関係者が存在するため、これらの問題について同意を形成することは非常に困難である。

多くのサービスが予約を取り扱わなければならない。予約の例として、医療サービスへの予約、ホテル、航空便、レンタカーなど旅行関連の予約、催し物のチケット予約、自動車整備の予約、住宅補修の予約などがある。こうしたサービスが互いに情報を入手し合えれば、非常に有益であろう。例えば、顧客がコンサートのチケットを予約した場合、その顧客は、レストランにテーブルの予約も入れたいと思うかもしれない。レストランの予約サービスが、劇場の予約システムから、日付や顧客名などの基本情報を取得できれば都合がよい。残念ながら、種類が異なる予約システム間で情報を交換するための方法は存在していない。

サービス間で情報を交換するための多くの方法が存在する。予約またはカレンダ機能を含むサービスについて言えば、情報交換はしばしば、予約またはカレンダ入力を同期させる目的で行われる。この目的に関して、いくつかの重要な規格化の努力が続けられている。例えば、１つの共通データ同期プロトコルを開発し、その普及を図るための業界の第一歩として、ＳｙｎｃＭＬが提唱された。

ｖＣａｌｅｎｄａｒは、個人スケジュール情報用の交換フォーマットである。ｖＣａｌｅｎｄａｒは、多種多様なカレンダおよびスケジューリング製品に適用可能であり、様々な転送方法によって情報を交換する際に役立つ。多くの製造元がこの仕様を採用しているが、それは、その製品でカレンダおよびスケジュール情報を交換できるようにするためである。ｖＣａｌｅｎｄａｒは、ｘ／ＯｐｅｎおよびＸＡＰＩＡカレンダ／スケジューリングＡＰＩ（ＣＳＡ）、ＩＳＯ８６０１国際日時規格、および関連するＭＩＭＥ電子メール規格といった業界規格に基づく公開仕様である。ｖＣａｌｅｎｄａｒフォーマットは、カレンダおよびスケジューリング・アプリケーション内に普通に保存されたデータを利用し、イベントやトゥードゥー（ｔｏ−ｄｏ）といった項目に関する情報のクロス・プラットフォーム交換を円滑に行えるようにする。イベントは、カレンダ上の指定時間量を表すカレンダおよびスケジューリング・エンティティである。トゥードゥーは、行為項目または任務を表すカレンダおよびスケジューリング・エンティティである。例えば、トゥードゥーは、ある人に割り当てられた作業項目とすることができる。

ｖＣａｒｄは、一般に従来の名刺に記されている個人情報の交換を自動化する。ｖＣａｒｄは、インターネット・メール、ボイス・メール、ウェブ・ブラウザ、テレフォニ・アプリケーション、コール・センタ、ビデオ会議、ＰＩＭ（個人情報マネージャ）、ＰＤＡ（携帯情報端末）、ポケット・ベル、ファックス、オフィス機器、スマート・カードといったアプリケーションで使用される。ｖＣａｒｄ情報には、文字列に加えて、画像、企業ロゴ、ライブ・ウェブ・アドレスなどの要素も含まれ得る。

上記の例が示すように、予約システムを同期させることのできるシステムを構築するため、多くの努力がなされてきた。これら既存のソリューションのすべてに共通する問題は、どのソリューションも、異なるシステムが互いに共有できる共通のセマンティクスを提供しないことである。例えば、入力が不確かであれば、異なるシステムはそれを異なる方法で解釈するかもしれない。

別の問題は、予約システムが複数の異なる、通常は非常に複雑なユーザ・インタフェースをもつことである。歯科医の予約を入れ、そこまで乗っていくタクシーも予約したい場合、顧客は、すべての予約情報を両方の予約システムに異なる方法で入力する必要がある。

さらに別の問題は、顧客に複数の質問をしたときに、顧客からの回答を管理するのが至難の業となることである。例えば、フィンランドをはじめ多くの国では、ＳＭＳテキスト・メッセージで通信を行うのはごく当たり前のことであり、ＳＭＳテキスト・メッセージが通信事業者の収入源となっているので、ＳＭＳテキスト・メッセージを使用して、どちらの選択肢を選択するかを顧客に尋ねることは道理にかなっている。しかし、顧客が複数のテキスト・メッセージを送信して、複数の質問に回答した場合、質問を指し示す情報が自動的に回答に含まれることはないので、どの回答がどの質問に対応するのかを明らかにすることが困難となることがある。例えば、航空便のチケットに加えて、タクシーとホテルの部屋も予約したいかどうか、サービスが顧客に質問し、一方の質問には「イエス」、もう一方の質問には「ノー」と顧客が回答した場合、顧客がどちらの申し出を了承したのか、サービスが常に判別できるとはかぎらない。

本発明の目的は、上述した短所を解消すること、または少なくともそれらを著しく縮減することである。本発明は、特に移動サービスにとって必須の新しいタイプの付加価値サービスを可能にする。

本発明のさらなる目的は、少なくとも１つのサービス提供者と、ショート・テキスト・メッセージを送受信可能なモバイル電話を用いて通信を行う複数のユーザとが関与する、予約タイプのトランザクションの実行を可能にする方法およびシステムを提供することである。

本発明のさらなる目的は、複数のサービス提供者と、ショート・テキスト・メッセージを送受信可能なモバイル電話を用いて通信を行う複数のユーザとの間で、予約タイプのトランザクションの実行を可能にする方法およびシステムを提供することである。

以下のセクションで、本発明の実施形態の例をいくつか挙げて、本発明を詳しく説明する。

本発明は、予約システムとユーザ端末装置との間で行われる情報の交換および同期に関する。サービスの例として、医療サービスへの予約、ホテル、航空便、レンタカーなど旅行関連の予約、催し物のチケット予約、自動車整備の予約、住宅補修の予約などがある。
本発明による予約システムは、少なくとも１つのサービス提供者の予約システムと、少なくとも１つのサービス提供者と、仲介者と、顧客と、テキスト・メッセージを受信可能な移動装置とすることができ、ダイロアグを含む少なくとも１つの顧客端末装置と、遠隔通信接続とを含み、遠隔通信接続は、サービス提供者の予約システムと、サービス提供者と、仲介者と、顧客端末装置とを互いに接続するのに使用される。

サービス提供者とは、顧客が面会予約（ａｐｐｏｉｎｔｍｅｎｔ）、確保予約（ｒｅｓｅｒｖａｔｉｏｎ）、またはその他の予約（ｂｏｏｋｉｎｇ）を入れたいと思う相手のことであり、予約システムが割り当てるリソースを含む。サービス提供者は、サービス提供者の予約サービスによって事業を行う。本出願における仲介者とは、サービス提供者の予約サービスがネットワークを介して利用可能なネットワーク・ベースのサービスのことであり、ネットワークは、顧客がサービス提供者相手のトランザクションを遂行するのに必要な情報を伝達するのに必要となる、追加のセマンティクス、変換、および同期サービスを提供する。サービス提供者の予約サービスおよび仲介者は好ましくは、インターネットや私設イントラネットなどにおけるネットワーク・サーバ上で動作するアプリケーションである。一般に、本発明のシステムは、複数のサービス提供者および（サービス提供者の予約サービスを実施する）サービス提供者の予約システムを含むが、サービス提供者が１つだけの簡単な予約システムを有することも可能であり、その場合、仲介者とサービス提供者とを、単一のアプリケーションとして密接に統合することができる。

顧客は好ましくは、ショート・メッセージ・サービス（ＳＭＳ）メッセージなどのショート・テキスト・メッセージを受信可能なモバイル電話を用いて通信を行う顧客を含む。もちろん、ＳＭＳメッセージを取り扱うことのできるシステムは、より高度な機能を用いるその他の顧客にも対応する。仲介者は好ましくは、モバイル電話プロバイダによって運営され、今日よく知られているＳＭＳゲートウェイを介して、モバイル電話顧客と通信を行う。仲介者は、ダイアログを使用して顧客と通信を行う。ダイアログは、顧客に情報を提示し、簡単な回答を可能にするショート・メッセージである。ダイアログは好ましくは、イエス／ノー形式の簡単な選択肢をユーザに提示し、または順序づけられたリストからの選択を可能にする。ダイアログは、予約の受け付け通知など、一方向メッセージとすることもできる。トランザクションは一般に、一連のダイアログを含むことができ、各ダイアログには簡単な応答が伴う。ダイアログにはメッセージによる非同期通信が関係する。上述したシステムは、顧客の必要を満たすため、異なるサービス提供者のシステム間で予約を連動させること、例えば、航空便の予約と空港への交通機関の予約の連動を可能にする。

図１は、単一のサービス提供者向けの単一のサービス提供者予約システム１００と、ネットワークを介してサービス提供者と通信を行う仲介者１０２と、ダイアログが提示されるモバイル電話を有するユーザとを含む最も簡単なシステムの図である。

図２には、ネットワークを介して仲介者と通信を行う複数のサービス提供者予約システムが示されている。

図３には、様々なサービス提供者システムおよびダイアログを伝えるモバイル電話を有するユーザと通信を行う、ＢｏｏｋＩＴと名づけられた仲介者が示されている。

理由ベースの顧客ダイアログは、サービス提供者が各予約イベントに関連して独自のダイアログを作成することができるので、顧客の観点から見て望ましい改良である。ダイアログは、ある予約状況に密接に関連している。ダイアログは適切な時点に自動的に活動状態になり、または顧客が必要に応じてダイアログを活動化することができ、またはシステム内の別のエンティティがダイアログにメッセージを送信して、ダイアログを活動化することができる。次にダイアログは、システム内の別のエンティティに問い合せを送信するか、または顧客に通知を出し、おそらくは顧客の選択を問い合わせる。このタイプのダイアログによって、顧客は１つのユーザ・インタフェースだけを使用して、複数の予約システムに予約を入れることができる。ダイアログは、例えば、インターネットを介して、または移動体ネットワークさえも介して、リモート予約システムに接続する。

仲介者サービスは、サービス提供者の予約システム間で予約情報を送信することができる。例えば、航空便予約システムに予約が入力された後、タクシー予約システムが、空港までの乗車を顧客に勧めることができる。この適用例では、予約記帳（ｂｏｏｋｉｎｇ）は、各リソース毎に（先の例では、航空便予約またはタクシー予約毎に）割り当てられるが、予約（ｒｅｓｅｒｖａｔｉｏｎ）は、同じイベントに関するすべてのリソースの予約記帳を合併したもの（先の例では、航空便予約とタクシー予約を合併したもの）となる。顧客と仲介者と予約システムの間のダイアログ、および保存された顧客個人情報を用いることで、顧客は、押し付けがましい広告ではなく、顧客が必要とするサービスの理由に基づいた提供を確実に受けられるようになる。

顧客は予約を入れるばかりでなく、予約の確認、変更、および取り消しを、インターネット、電子メール、および移動端末をはじめとする、しかしこれらに限定されない、様々なタイプの通信手段を使用して行うことができる。顧客はまた、仲介者の同期機能を使用して、仲介者またはサービス提供者によって提供されるカレンダと端末装置のカレンダとを同期させることもできる。

サービス提供者は定期的に、予約申し込みについて顧客の注意を喚起することができ、したがって、顧客忠実度を向上させることができる。仲介者は、サービス提供者の予約システムを統合して、それぞれが事業を必要以上に拡張することなく、より総合的なサービスを提供できるよう、サービス提供者を支援する。国際化に合わせて、仲介者は、例えば、多くの言語、タイム・ゾーン、通貨、およびデータ・フォーマットをサポートすることができる。

少なくとも１つのダイアログ、仲介者、サービス提供者、およびサービス提供者の予約システムを含むシステムは、以下に示すレベルのいずれか１つにあることができる。

１．システムにダイアログの所定の組が存在する。その内容および可能な選択肢はあらかじめ設定されている。例えば、顧客が航空便を予約した場合、ダイアログは常に一定のその他の予約を提案する。顧客がその前に行った行為は考慮されない。

２．例えば、顧客が自ら作成した個人情報、使用履歴、および顧客所在地などに基づいた、動的または「知的」ダイアログがいくつでも存在する。簡単なロジックが判断を支援する。これは低レベルのエキスパート・システムである。

３．システムは自ら判断を行うことができ、顧客の意思決定を支援することができる。このレベルでは、ダイアログは高レベルのエキスパート・システムを含むことができる。ダイアログはエージェントとして動作することができ、複数のサービス提供者と交渉を行って、顧客の直接の関与なしに、最適の提案を得ることができる。

本発明の方法の好ましい実施形態では、顧客はサービス提供者が提供するサービスを予約する。予約は、仲介者サービスに接続された端末を使用して実行することができる。初めに、顧客は、ダイアログを使用して仲介者サービスに接続する。顧客は予約問い合せをダイアログに入力し、ダイアログはその問い合せを仲介者に送信する。仲介者は、可能性のある予約についてサービス提供者の情報システムに、それらのサービスが解釈できる概念および用語を使用して問い合せを行う。問い合せは、顧客の選好に基づいている。顧客は、予約問い合せをダイアログに入力するとき、特定の予約に関連するいくつかの選好を明らかにする。さらに、ダイアログおよび仲介者サービスは、顧客が毎回すべての選好を入力しないですむように、顧客の通常時の選好を保存しておき、それらを使用することができる。

問い合せおよび予約の管理は、高度な状態モデルに基づいている。各予約は、複数のフェーズを含み、フェーズはそのステータスを存続期間にわたって追跡する状態によって記述される。例えば、仲介者が予約についてサービス提供者に問い合せを行った場合、各システムの対応するエントリは、予約が懸案中であり承認されていないことを示す状態を有する。ある状態が意味する内容について各システムが共通の理解を有していない場合、仲介者が状態の翻訳を行う。フェーズおよび状態を含む好ましい予約プロセスについて、実施例１で説明する。

サービス提供者に予約を問い合わせるのに加えて、仲介者は、複数のサービス提供者システムで予約を同期させることができる。同期は、仲介者サービスで内容が定められた規則に基づいている。例えば、規則は、「顧客が航空便のチケット予約の問い合せを行った場合、空港へのタクシー予約についても質問せよ」というものにすることができる。したがって、顧客からの問い合せは、仲介者サービスで数を増し、複数の問い合せとなる場合がある。サービス提供者は、要求されたサービスを提供できるかどうか、また座席や時刻など追加の情報をいくつか追加できるかどうかを仲介者に回答する。仲介者は、収集した情報を一まとめにしてダイアログに送信し、ダイアログは選択肢の簡単なリストを顧客に提示する。例えば、ダイアログは、航空便に関する３つの選択肢を提示し、すでに暫定的に仲介者によって予約されているタクシーの予約も顧客が希望するかどうかを質問することができる。顧客は、選択肢の簡単なリストから希望項目を選択することによって、決定を下すことができる。ダイアログは、顧客選択情報を仲介者に送信し、仲介者は、顧客選択に従って予約を確定し、不必要な予約を取り消す。

図４には、顧客によって発行され、ダイアログＤＩＮＱ１を使用して仲介者に送信される問い合せＣＩＮＱ１のシーケンス図が示されている。仲介者は、ＣＩＮＱ１およびＤＩＮＱ１に対応する問い合せＭＩＮＱ１を、サービス提供者予約システムである予約システム１に宛てて発行する。最終的に、顧客には選択を求める応答ＤＡＮＳ１が返送され、顧客は選択ＣＳＥＬ１によってそれに回答し、予約システム１に予約を入れる。仲介者は、予約サービス２が提供する補足的なサービスに対する潜在的な必要を認識し、予約システム２に宛てて問い合せＭＩＮＱ２を発行する。その結果、最終的に、複数の選択肢を含む提案ＤＡＮＳ２が顧客に返送され、そこから選択ＣＳＥＬ２が行われ、予約システム２に補足的な予約が入れられる。

予約は、他の手段でも同様に、例えば、サービス提供者に電話をかけることによって、またはサービス提供者のオフィスに出向くことによっても行うことができる。その場合、サービス提供者は、顧客の予約について仲介者に通知して、仲介者が顧客にその他の選択事項を通知できるようにする。例えば、歯科医は、顧客が予約を入れたことを仲介者に知らせて、仲介者がタクシー予約も提案できるようにすることができる。

また、仲介者サービスに注意喚起機能を追加して、定められた時になると、仲介者が顧客に新規予約を入れたいかどうかを尋ねるようにすることもできる。例えば、仲介者は、最後に歯科医に予約を入れてから１年たつことを知らせる通知を顧客に送信し、顧客が新規予約を入れたいかどうかを尋ねることができる。顧客が許可していれば、仲介者は顧客のカレンダをチェックして、提示する選択項目が顧客に便利なものになるようにする。ダイアログは、簡単で扱いやすい方法で選択項目を提示する。顧客は、自分にとって最適な選択項目を選択しさえすればよく、または新たな選択項目の提示もしくは予約の見送りを求める旨を選択しさえすればよい。図５は、最初の問い合せＭＩＮＱ１が仲介者によって発行された状況についてのタイム・シーケンス図である。

好ましい予約システム
本発明による好ましい予約システムを、ＢｏｏｋＩＴと名づけるシステムに関して、以下で説明する。

ＢｏｏｋＩＴは、インターネットなどのネットワークを介してサービス提供者とその他の当事者との間のインタフェースをとるため、またテキスト・メッセージを受信可能なモバイル電話を携行するエンド・ユーザ顧客とのインタフェースをとるために設計されている。前者は好ましくは、一般的なＸＭＬインタフェースによって達成される。ｖＣａｒｄおよびｖＣａｌｅｎｄａｒはすべての主要な予約およびカレンダ・システムで使用されるので、ＢｏｏｋＩＴもｖＣａｒｄおよびｖＣａｌｅｎｄａｒ規格をサポートする。

ＢｏｏｋＩＴは、非同期通信用のＳＭＳゲートウェイを介したショート・メッセージ・サービス（ＳＭＳ）を使用して、モバイル電話ユーザと通信を行う。ＢｏｏｋＩＴは、安全な転送およびＳＭＳメッセージのマッピングのため、新規な動的ダイアログ・マトリクス（ＤＤＭ）を使用する。ＤＤＭについては以下でさらに説明する。

サービス提供者の予約システムとＢｏｏｋＩＴプロセスとを明確に区別する必要がある。前者は、時間とリソースの予約のみが関係する標準的な予約を取り扱う。後者は、予約、実行、および会計から構成される。両プロセスとも目的とするところは同じである。ＢｏｏｋＩＴプロセスは、以下の７つのフェーズから構成される。

フェーズ（ステータス処理）
フェーズは、（ゴム・バンドのように）リソースどうしを結びつける。予約に関連するデータは、ＢｏｏｋＩＴプロセスの各フェーズにおいて、それぞれのフェーズでの必要性を反映して変更される。ステータスおよび値については、以下に示す表を参照されたい。

各フェーズについて、以下でより詳細に説明する。
１．ファイリング
ファイリングは、ＢｏｏｋＩＴプロセスおよび予約プロセスの初期設定を意味する。初期設定の結果、基本情報を有するエントリがデータベースに挿入される。スケジュール情報は有していないので、このエントリはカレンダには現れない。このエントリは、オープン・タスクとして、オーナ別のタスク・リストに表示することができる。

２．要求
要求フェーズでは、予約要求が、先にファイリングされたタスクが必要とするリソースに送信される。ほとんどのケースで必須のスケジュール情報がないので、このフェーズは、スケジューリング・フェーズと一緒に実行することができる。

３．スケジューリング
スケジュールが、オーナおよびリソースに与えられる。スケジューリングの一部として、また結果として、以下のデータが必要とされる。
ａ 提案開始時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｂ 提案開始場所（座標）
ｃ 提案終了時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｄ 提案終了場所（座標）

４．確定
承諾したリソースによってそれが承諾されたときの時刻および場所。このフェーズに関連するデータは、
ａ 承諾開始時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｂ 承諾開始場所（座標）
ｃ 承諾終了時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｄ 承諾終了場所（座標）
である。

デフォルトでは、上記データは、プランニング・フェーズからコピーされる。
実行する上で、プランニングされた時刻が必要でない場合、これのために同じデータ構造を使用することができ、ステータスは実際の意味のデータを指示する。

５．実行
リソースが予約されたタスクを実行する。このフェーズに関連するデータは、実際のタスクに関連する異なる属性および値から構成される。さらに、以下の静的構造も必要とされる。
ａ 実際開始時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｂ 実際開始場所（座標）
ｃ 実際終了時刻（タイム・ゾーンを伴うＩＳＯタイム・スタンプ）
ｄ 実際終了場所（座標）
ｅ 使用される製品、追加料金、マイレージ、・・・

デフォルトでは、上記データは、確定フェーズからコピーされる。
１．会計
このフェーズで、以前のフェーズにおいてデータ構造に保存されたすべてのデータが、請求書作成の目的で分析され、処理される。
このフェーズに関連するデータは会計データであり、別途定義される。

７．完了
タスクが完了する。ＢｏｏｋＩＴ全体の観点からは、タスクが正常に完了したかどうかは問題とされない。問題となるのは、オーガナイザへの会計行為が処理される会計フェーズにおいてである。このフェーズでは、ＢｏｏｋＩＴプロセスを完了するため、（データベース内容、一時ファイルなどの）ハウスキーピングが行われる。
各フェーズで利用可能なデータを以下の表に示す。予約フェーズはイタリックで示してある。

フェーズ・ステータス、値、および遷移
以下の表には、フェーズ、そのステータス、および値が、とる値に基づいた次の論理フェーズへの遷移と併せて示されている。さらに、適用可能な場合には、対応するｖＣａｌｅｎｄａｒステータスも示されている。

内部フェーズである休止、再開、取り消しは、すべての関連フェーズについて任意の時点で以下のように動作する。

図６に、フェーズからフェーズへのワーク・フロー遷移が示されている。条件については、上記の表を参照されたい。また、取り消しステータスは常に会計に遷移することに留意されたい。

予約（全体）の確定
予約全体が正常に完了するには、予約を受諾したすべてのリソースが、同じスケジューリングをもつ必要がある。さらに、異なる役割にリソースがあり、実行フェーズに関連するデータは大きく異なることができる。

予約全体についての様々なステータスを以下に示す。
ａ 「応答なし」（０）は、「オーガナイザが行った要求に誰も応答していない」場合。
ｂ 「拒否なし」（１）は、「被要求者がまだ全員は応答していないが、応答した者は承諾している」場合。
ｃ 「全員承諾」（２）は、「被要求者が全員許諾した」場合。
ｄ 「一部拒否」（３）は、「一部の被要求者が拒否した」場合。
ｅ 「全員拒否」（４）は、「被要求者が全員拒否した」場合。
以下の判定表は、予約全体のステータスを評価する際に役に立つ。「不確定」は、この条件だけでは結果の真偽を明白に確定できないことを意味する。

情報および上記の判定表に基づいて、オーガナイザ／アプリケーションは、予約をどのように処理するかを決定しなければならない。これは、事前設定された規則に基づいてシステムが自動的に決定することができ、またはオーガナイザが人手を介して決定することもできる。

本発明によって解決される主要な問題の１つは、顧客に複数の質問が提示され、顧客がＳＭＳテキスト・メッセージ、または問い合せを明示的に指示する情報が回答に自動的に含まれない類似の技術を使用しているときに、顧客の回答を管理するのが難しいという問題である。本発明は、動的ダイアログ・マトリックスを使用して、この問題を解決する。問い合せは常に、何らかのタイプの受信機アドレスまたは識別情報を含む。ＳＭＳテキスト・メッセージの場合、これは、いわゆる、Ｂ加入者番号と呼ばれる。一方、送信側のＡ加入者番号もしくは発呼線識別情報（ＣＬＩ）、または類似の識別情報も、各テキスト・メッセージに付加される。したがって、顧客またはＢ加入者は通常、移動装置の回答または応答機能を使用して、容易に回答することができる。顧客に問い合せを送信する仲介者サービスが、異なる問い合せに異なるＡ加入者番号を使用するならば、顧客がどの番号に回答を送信しているかに基づいて、回答を識別することが可能になる。例えば、仲介者が顧客に、Ａ加入者番号Ａ１を使用して問い合せ「タクシーも予約しますか？」を送信し、次にＡ加入者番号Ａ２から問い合せ「ホテルの部屋も予約しますか？」を送信した場合、第１の質問に対する顧客の回答は番号Ａ１に返送され、第２の回答は番号Ａ２に返送される。仲介者は、ダイアログ・マトリックスを使用して、問い合せと回答とを追跡する。マトリックスでは、列が各顧客に、行が仲介者の使用する各Ａ加入者番号に対応する。同様に、行を各顧客に対応させ、それに伴い、列を各Ａ加入者番号に対応させることも可能なことは明らかであろう。あるＡ加入者番号から顧客に問い合せを送信した後、ステータスおよび回答が、マトリックスの対応するシェルに格納される。その結果、仲介者は、顧客がある問い合せに回答したかどうか、またどのような回答内容であるかを知ることができる。また、マトリックスを使用して顧客行動についての情報を収集し、例えば、それをマーケティングのために使用することも可能である。仲介者は、限られた数のＡ加入者番号が必要なだけである。ダイアログ・マトリックスは、ある顧客に次の問い合せを送信する際に、どのＡ加入者番号が使用できるかを知るのに使用することもできる。

図７に、上述した動的ダイアログ・マトリックスの使用の様子を示す。
動的ダイアログ・マトリックスは、メッセージを送受信する能力だけを有するモバイル電話ユーザを認証するための、強力でありながら非常に簡潔なセキュリティ対策となる。問題は、サービスが送信者の識別情報を確認することである。ユーザの識別を試みるための１つの方法は、送信者のアドレスをチェックすることである。通常、ＳＭＳ、電子メール、およびその他の同様のメッセージには、送信者アドレスが付加されている。そのアドレスは、例えば、送信者のＡ加入者番号もしくは発呼線識別情報（ＣＬＩ）、電子メール・アドレス、またはＩＰアドレスとすることができる。しかし、送信者のアドレスを改ざんするのは非常に容易である。サービス提供者から見て、サービス提供者からユーザへのダウンリンクは、一般に比較的信頼でき、他者がメッセージを捕捉したり、変更したりするのは難しいが、ユーザからサービス提供者へのアップリンクは、はるかに攻撃を受けやすく、偽りの送信者アドレスを与えることはそれほど難しくはない。上記の問題に対するよく知られたソリューションは、通信の安全を確保する暗号技術、例えば、公開鍵基盤（ＰＫＩ）を使用するというものである。例えば、ユーザ装置は、ユーザの秘密鍵を使用してメッセージを暗号化するため、マイクロチップを、ＧＳＭ装置であればセキュアＳＩＭカードなどを備えることができる。サービス提供者は、ユーザの公開鍵を使用してメッセージを復号できれば、それがユーザからのものであると確信することができる。しかし、このソリューションは、あまり一般的でなく、安価でなく、またはこれまで規格化されていない特殊な装置を必要とする。そのようなソリューションに頼っていては、潜在的ユーザの数が著しく制限される。

ＤＤＭを使用することによって、新規なソリューションが提供される。サービスがモバイル電話ユーザに要求を送信する場合、各要求には、異なる、好ましくは無作為に選択された、応答番号が含まれる。したがって、受け入れてもよい回答は、正しい応答アドレスに送信された回答だけである。

動的ダイアログ・マトリックスの使用法
この簡単な例は、翌朝の航空便のチケットの入手について述べたものである。システムは、短い応答を必要とするＳＭＳメッセージとして一連の質問を送信する。各メッセージには、応答を識別できるように目印が付けられているので、論理的に要求されない限り（例えば、ある質問に対する回答が次の質問の内容に影響するなど）、必ずしも特定の順序でメッセージを送信したり、メッセージに応答したりする必要はない。

電話番号がＩＤ＝０４１８ ９７９ ８１３であるユーザが、チケットを要求する。システムは、以下の要求を個々のＳＭＳメッセージとして送信する。

以下の出発時刻から１つを選択してください。
６：００ ａ．ｍ．：回答Ａ
７：３０ ａ．ｍ．：回答Ｂ
８：１５ ａ．ｍ．：回答Ｃ
上記以外：回答Ｄ
送信者：＋３５８４４０８４４ ０２７

チケット・クラスを選択してください。
ファースト・クラス：回答Ａ
ビジネス・クラス：回答Ｂ
エコノミ・クラス：回答Ｃ
最も安い入手可能チケット：回答Ｄ
送信者：＋３５８４４０８４４ ０１１

選択してください。
窓側の席：回答Ａ
通路側の席：回答Ｃ
送信者：＋３５８４４０８４４ ０３４

機内食を選択してください。
野菜食：回答Ａ
ビーフ：回答Ｂ
チキン：回答Ｃ
送信者：＋３５８４４０８４４ ００３

上記およびその他のいくつか質問に対して顧客から受信した回答は以下のようであった。
参照番号＋３５８４４０８４４ ０２７の質問に対して「Ａ」
参照番号＋３５８４４０８４４ ０１１の質問に対して「Ｄ」
参照番号＋３５８４４０８４４ ０３４の質問に対して「Ａ」
参照番号＋３５８４４０８４４ ００３の質問に対して「Ｂ」
参照番号＋３５８４４０８５９ ７５１の質問に対して「Ｄ」
参照番号＋３５８４４０８４４ ２７７の質問に対して「Ａ」
参照番号＋３５８４４０８４１ ３６８の質問に対して「Ｃ」
この結果から、サービス提供者は顧客が、
朝一番の航空便 （＝Ａ）
最も安い入手可能チケット （＝Ｄ）
窓側の席 （＝Ａ）
ビーフの機内食 （＝Ｂ）
などを選択したことを知ることができる。

マトリックスを用いれば、顧客は好きな順序で質問に回答できること、いくつかの質問には回答しなくてもよいことに留意することが重要である。未回答の質問に回答が必要であれば、システムは回答を促すことができる。回答が必要なければ、システムは、その情報なしで処理を行うことができる。

図８に、上記の応答を３次元マトリックスとして示す。顧客番号がＸ軸に、応答番号がＹ軸に、回答がＺ軸にプロットされている。電話番号が０４１８ ９７９ ８１３であるユーザは、Ｘ軸の最も左のユーザである。Ｙ軸の応答番号に対応する回答が、Ｚ軸にプロットされている。

セキュリティ補強は、セマンティクス分析を使用して達成される。マトリックス・セルには、問い合せの情報と、どのような回答であれば受け入れられるかについての情報をもつことができる。回答が基準を満たさなければ、その回答は拒否される。例えば、サービス提供者がユーザに注文数を回答するよう求めたときに、ユーザが「イエス」と回答したならば、明らかにユーザは質問の内容を知っておらず、そのメッセージは問い合せに対する回答ではない。

上記のサービス提供者は実際には仲介者であり、「本当の」サービス提供者はどこか他の場所にいることも可能である。その場合、仲介者だけがマトリックス・ベース・システムをもてばよく、実際のサービス提供者は、仲介者のマトリックス・システムまたは暗号化チャネルのようなその他の安全な手段を使用して、仲介者と通信を行う。例えば、自動車共用システムを以下のようにして実施することができる。自動車は成り行き任せに市内のあちこちに駐車されている。ユーザは、自動車が必要になると、どこに最も近い自動車があるかを尋ねるメッセージを仲介者に送信する。仲介者は、自動車の所在地を知らせるメッセージを送信する。その回答は無作為のアドレスｙ’から届く。ユーザは、自動車の所に到着すると、レンタル時間の開始を申告するとともに、自動車のロックを遠隔操作で解除するよう仲介者に求めるメッセージをｙ’に送信する。このメッセージは、ユーザだけが知っているアドレスに送信されるので、比較的信頼性が高い。したがって、メッセージは、ロックを解除し、請求を開始するための妥当な理由となる。一方、仲介者と自動車の間の通信は、ユーザにも第三者にも秘匿されている。自動車は特殊な装置を装備しているため、ロック解除などの遠隔指令は暗号化することができる。または、自動車と仲介者の間の通信も、マトリックスを使用して実施することができる。いずれの場合も、仲介者はユーザと自動車の間の「ファイアウォール」として機能し、第三者が権限なしに自動車を使用できないようにする。

本発明を、いくつかの好ましい実施形態を参照しながら、かなり詳しく説明してきたが、その他の実施形態も可能である。したがって、添付の特許請求の範囲の主旨および範囲は、本明細書の好ましい実施形態に限定されるものではない。

本発明による第１の有利なシステムの図である。 本発明による第２の有利なシステムの図である。 本発明による第３の有利なシステムの図である。 本発明による、システム内で送信されるメッセージの第１の有利なシーケンス例を表す図である。 システム内で送信されるメッセージの第２の有利なシーケンス例を表す図である。 本発明による、問い合せと応答に適用される動的ダイアログ・マトリックスの例を示す図である。 本発明の好ましい実施形態における予約プロセスのフェーズを示す図である。 本発明の好ましい実施形態による、実施例２に対応するマトリックス図である。

Claims (43)

1. 顧客識別子アドレスを有する顧客端末と通信を行う仲介者に関する方法であって、
   ａ）前記顧客端末との通信を初期化する工程であって、ダイアログに対する応答を送信する必要がある特定の応答アドレスを関連づける工程と、前記仲介者が応答を受信する複数のアドレスから前記特定の応答アドレスを選択する工程とを含む工程と、
   ｂ）前記特定の応答アドレスを含む前記顧客端末へのダイアログを開始する工程と、
   ｃ）前記特定の応答アドレスで前記顧客端末から前記顧客識別子アドレスを含む応答を受信する工程と、
   ｄ）前記顧客識別子アドレスと前記応答が受信された前記特定の応答アドレスを使用して前記応答を評価する工程とを含む方法。
2. 前記応答を評価する工程が、前記応答のセマンティクスを分析する工程をさらに含む、請求項１に記載の方法。
3. 前記通信が、特定のサービス提供者に関係する、請求項１に記載の方法。
4. 前記複数のアドレスから前記特定の応答アドレスを選択する工程が、無作為選択による、請求項１に記載の方法。
5. 前記通信が、前記顧客端末との複数のダイアログおよび応答の交換を含み、開始する工程が、異なる応答アドレスを異なるダイアログおよび応答の交換に関連づける工程を含む、請求項１に記載の方法。
6. 交換が開始されたのとは異なる順序で個々の応答が受信された場合でも、前記応答を評価する工程が続行できる、請求項５に記載の方法。
7. 通信を初期化する工程が、前記顧客端末および特定のサービス提供者を識別する設定要求に応答する、請求項３に記載の方法。
8. 顧客識別子アドレスに対応する第１の軸と応答アドレスに対応する第２の軸とを有するマトリックスに前記応答を保存する工程をさらに含む、請求項４に記載の方法。
9. 前記仲介者が、それぞれ異なる顧客識別子アドレスを有する複数の他の顧客端末とも同時に通信を行い、前記方法が、前記複数のアドレスのうちどれが現在使用可能であるかを追跡する工程をさらに含む、請求項７に記載の方法。
10. 通信を初期化する工程が、現在使用可能なアドレスから前記特定の応答アドレスを選択する工程をさらに含む、請求項８に記載の方法。
11. 少なくとも１つのサービス提供者と顧客識別子アドレスを有する顧客端末との間の通信を制御する仲介者であって、
    ａ）前記仲介者が前記顧客端末からメッセージを受信できる複数のアドレスと、
    ｂ）ｉ）ダイアログに対する応答を送信する必要がある特定の応答アドレスを関連づける工程と、前記仲介者が応答を受信する複数のアドレスから前記特定の応答アドレスを選択する工程とを含む初期化を、特定のサービス提供者に関連する前記顧客端末との通信に関して実行し、
    ｉｉ）前記特定の応答アドレスを含む前記顧客端末へのダイアログを開始し、
    ｉｉｉ）前記特定の応答アドレスで応答を受信し、
    ｉｖ）前記顧客識別子アドレスと前記応答が受信された前記特定の応答アドレスを使用して前記応答を評価するように適合されたロジックおよびリソースとを含む仲介者。
12. 前記応答を評価する前記ロジックおよびリソースがさらに、前記応答のセマンティクスを分析する、請求項１１に記載の仲介者。
13. 前記通信が、前記顧客端末との複数のダイアログおよび応答の交換を含み、異なる応答アドレスが、異なるダイアログおよび応答の交換に関連づけられる、請求項１１に記載の仲介者。
14. 個々の応答が個々の問い合せとは異なる順序で受信された場合でも、前記ロジックおよびリソースが、ダイアログに対する応答を処理するように適合される、請求項１３に記載の仲介者。
15. 前記通信を初期化するように適合される前記ロジックおよびリソースが、顧客識別子アドレスに対応する第１の軸と応答アドレスに対応する第２の軸とを有するマトリックスを含む、請求項１１に記載の仲介者。
16. 前記通信を初期化する前記ロジックおよびリソースが、前記顧客端末および前記特定のサービス提供者を識別する設定要求に応答するように適合される、請求項１１に記載の仲介者。
17. 前記複数のアドレスから前記特定の応答アドレスを選択する前記ロジックおよびリソースが、無作為に選択アドレスを選択する、請求項１１に記載の仲介者。
18. 前記顧客識別子アドレスが、顧客のＡ加入者番号、発呼線識別情報、電子メール・アドレス、およびＩＰアドレスからなる群から選択される、請求項１１に記載の仲介者。
19. 少なくとも１つのサービス提供者と顧客が使用する顧客識別子アドレスを有する顧客端末とを有する予約システムを制御する仲介者であって、
    ａ）前記仲介者が前記顧客端末からメッセージを受信できる複数のアドレスと、
    ｂ）前記サービス提供者に関係する問い合せに応答する少なくとも１つのダイアログを準備し、
    前記複数のアドレスから選択される特定の応答アドレスを各ダイアログに関連づけ、
    前記少なくとも１つのダイアログを前記顧客端末に送信し、
    前記特定の応答アドレスで前記顧客端末装置から前記顧客識別子アドレスを含む応答を受信し、
    前記顧客識別子アドレスと前記応答が受信された前記特定の応答アドレスを使用して前記応答を評価するように適合されたロジックおよびリソースとを含む仲介者。
20. 前記ロジックおよびリソースが、顧客識別子アドレスによって索引づけされた第１の軸と応答アドレスによって索引づけされた第２の軸とを含むマトリックスを含む、請求項１９に記載の仲介者。
21. 前記顧客識別子アドレスが、顧客のＡ加入者番号、発呼線識別情報、電子メール・アドレス、およびＩＰアドレスからなる群から選択される識別子を含む、請求項１９に記載の仲介者。
22. 前記応答を評価する前記ロジックおよびリソースがさらに、前記応答のセマンティクスを分析する、請求項１９に記載の仲介者。
23. 前記問い合せが、前記顧客端末装置を識別するサービス要求に応答する、請求項１９に記載の仲介者。
24. 複数のダイアログが、前記問い合せに応答して準備され、特定の応答アドレスを関連づけるように適合された前記ロジックおよびリソースが、各ダイアログに関連づけるために異なる特定の応答アドレスを選択し、個々の応答が個々のダイアログとは異なる順序で受信された場合でも、前記ロジックおよびリソースが、応答を評価するように適合される、請求項１９に記載の仲介者。
25. 前記ロジックおよびリソースが、前記複数の異なるアドレスのうち現在使用可能なアドレスを追跡するとともに、その現在使用可能なアドレスから無作為に前記特定の応答アドレスを割り当てるロジックおよびリソースを含む、請求項２４に記載の仲介者。
26. 前記少なくとも１つのダイアログが、順序づけて配列された選択肢のリストから１つの項目を選択することによって回答できる質問であり、各選択肢は、順番を振られた位置を有する、請求項２４に記載の仲介者。
27. 前記マトリックスが、前記選択の前記順番を振られた位置を保存するために索引づけされた第３の軸をさらに含む、請求項２６に記載の仲介者。
28. 顧客のためにサービス提供者にリソースの予約を入れる仲介者に関する方法であって、前記顧客は、顧客識別子アドレスを有し、顧客端末装置を使用して前記仲介者と通信を行い、前記仲介者が、
    ａ）問い合せに応答する少なくとも１つのダイアログを準備する動作と、
    ｂ）顧客端末装置からの受信メッセージで使用可能な複数のアドレスから選択される特定の応答アドレスを各ダイアログに関連づける動作と、
    ｃ）前記少なくとも１つのダイアログを前記顧客端末装置に送信する動作と、
    ｄ）前記顧客端末装置から前記少なくとも１つのダイアログへの前記顧客識別子アドレスを含む応答を受信する動作と、
    ｅ）前記顧客識別子アドレスと前記特定の応答アドレスを使用して前記少なくとも１つのダイアログへの前記応答を評価する動作とを含む動作を実行する方法。
29. 前記応答を評価する動作が、前記応答のセマンティクスを分析する、請求項２８に記載の方法。
30. 前記少なくとも１つのダイアログへの前記応答を、顧客識別子によって索引づけされた第１の軸と応答アドレスによって索引づけされた第２の軸とを含むマトリックスに保存する、請求項２８に記載の方法。
31. 特定の応答アドレスを各ダイアログに関連づける動作が、前記特定の応答アドレスを無作為に選択するように実行される、請求項２８に記載の方法。
32. 前記問い合せが、前記顧客端末装置からのサービス要求に応答する、請求項２８に記載の方法。
33. 前記顧客識別子アドレスが、顧客のＡ加入者番号、発呼線識別情報、電子メール・アドレス、およびＩＰアドレスからなる群から選択される識別子を含む、請求項２８に記載の方法。
34. 前記少なくとも１つのダイアログを準備する動作が、順序づけて配列された選択肢のリストから選択することによって回答できる形式で、前記少なくとも１つのダイアログを準備する動作をさらに含み、各選択肢は、前記選択肢のリスト内に順番を振られた位置を有する、請求項２８に記載の方法。
35. 前記少なくとも１つのダイアログは、異なる特定の応答アドレスが各ダイアログに関連づけられるように複数のダイアログを含み、ダイアログが送信されたのとは異なる順序で応答が受信された場合でも、前記応答を評価する動作が続行できる、請求項２８に記載の方法。
36. 前記マトリックスが、選択の前記順番を振られた位置を保存するために索引づけされた第３の軸をさらに含み、前記方法が、前記選択を前記第３の軸上の前記少なくとも１つの応答に保存する工程をさらに含む、請求項３４に記載の方法。
37. 前記顧客端末装置がモバイル電話を含み、前記ダイアログがＳＭＳメッセージを含む、請求項３４に記載の方法。
38. 請求項２８に記載の方法を実行する仲介者としてプログラムされるネットワーク・サーバ。
39. 請求項３４に記載の方法を実行する仲介者としてプログラムされるネットワーク・サーバ。
40. 顧客を認証する仲介者に関する方法であって、前記顧客は、ＳＭＳメッセージを送受信でき、顧客発呼線識別番号を有するモバイル電話装置を使用し、前記仲介者が、
    ａ）複数の使用可能な応答アドレスから一意の応答アドレスをＳＭＳダイアログに割り当てる動作と、
    ｂ）前記ＳＭＳダイアログを前記顧客発呼線識別番号に基づき前記顧客に送信する動作と、
    ｃ）前記ＳＭＳダイアログへの応答が前記一意の応答アドレスで受信された場合、前記顧客を認証する動作とを含む動作を実行する方法。
41. 前記一意の応答アドレスが、前記複数の使用可能な応答アドレスから無作為に割り当てられる、請求項４０に記載の方法。
42. 前記仲介者が、前記方法を実行するようにプログラムされるネットワーク・サーバを含み、前記方法が、顧客発呼線識別番号によって索引づけされた第１の軸と応答アドレスによって索引づけされた第２の軸とを含むマトリックスに前記応答を保存する、請求項４０に記載の方法。
43. 前記認証動作が、前記応答のセマンティクスを分析する動作をさらに含む、請求項４０に記載の方法。

Images