JP2005517256A - 通信ネットワークとサービス・プロバイダとの間でリアルタイム情報交換を行う方法及びＢｕｓｉｎｅｓｓ−Ｔｏ−Ｂｕｓｉｎｅｓｓエンジン - Google Patents

Abstract

Ｂｕｓｉｎｅｓｓ ｔｏ Ｂｕｓｉｎｅｓｓ（Ｂ２Ｂ）エンジン１９００を使用して、移動局１９２５と少なくとも１つの固定局１９４０、１９４５、１９５０の間でリアルタイム情報を提供する方法及び装置。移動局ＭＳを利用する加入者は、付近の固定局、つまり、レストラン１９４０を探索する要求をＢ２Ｂエンジンに送信することができる。Ｂ２Ｂエンジンと相互接続されている、予約管理会社、つまり、サービス・プロバイダは、Ｂ２Ｂエンジンとの統合のため、メンバ・レストラン及びレストラン・モジュール１９０５に予約アプリケーションを提供することができる。Ｂ２Ｂエンジン１９００は、レストラン１９４０と移動局１９２５との間でリアルタイム情報をやり取りする交換ポイントを備える。レストラン・モジュール及びＢ２Ｂエンジンは、予約アプリケーションと通信し、携帯電話加入者の推定到着時刻に応じて予約を自動的に出し、管理する。到着前に調整を行い、人の介入なしですべてのプロシージャを自動的に実行することができる。

Description

（関連出願の相互引用）
本米国非仮特許出願は、２０００年９月２２日に出願された米国同時係属仮出願第６０／２３５，１４２号の優先権を主張し、参照によりその開示全体を組み込む。

本米国非仮出願は、米国非仮特許出願第０９／７５５，９４２号、第０９／７５５，９３９号、第０９／７５５，９４７号、第０９／７５５，３６０号、及び第０９／７５５，９４８号の一部継続出願であり、すべて２００１年１月５日に出願されたものである。米国非仮特許出願第０９／７５５，９４２号、第０９／７５５，９３９号、第０９／７５５，９４７号、第０９／７５５，３６０号、及び第０９／７５５，９４８号は、参照により、その全体が本明細書に組み込まれる。

本発明は、一般に、付加価値情報交換（value-added information-exchanging）ネットワーク・サービスに関するものであり、具体的には、限定ではなく実施形態として通信ネットワーク及びサービス・プロバイダの両方とインターフェースし、情報交換を円滑に進めることができるＢｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓ（Ｂ２Ｂ）エンジンなどに関するものである。

インターネット上での情報の入手がしやすくなるにつれ、さまざまなコンテンツが利用可能になってきている。通常、ユーザは、インターネット・サービス・プロバイダ（ＩＳＰ）を通じて固定されたホーム・サイト又はオフィス・サイトにあるそのようなコンテンツにアクセスする。インターネット上のコンテンツ・プロバイダは、ＩＳＰを通じて、直接ユーザに広告又はその他の商業情報とともにそのコンテンツを転送する。一部のＩＳＰは、現在、追加コンテンツを提供する形でキャッシュ、例えば、Ｙａｈｏｏ及びＡｍｅｒｉｃａ Ｏｎ Ｌｉｎｅ（ＡＯＬ（登録商標））を維持しているが、大半のＩＳＰは純粋に情報の伝達役に徹しており、したがって、この技術及びサービスの成熟とともに価値を高めることを期待されていない。

同時進行している最近の開発は、携帯電話ユーザによる無線インターネット・アクセスである。通信及びインターネットの統一により、さまざまなデバイスがますます多目的になってきて、今やデータを、携帯電話、パーソナル・デジタル・アシスタント（ＰＤＡ）、又はその他の通信デバイスによりインターネットを無線で利用することが可能である。しかし、ＩＳＰの場合と同様、インターネット・コンテンツ・プロバイダも、既存の通信機器を情報を受け渡すための単なる導管として使用しており、そのため、通信事業者が所有するこれらの物理的接続の認知されている価値を故意に過小評価している。このような運用のパラダイムは、図１に例示され、一般には、番号１００で示されており、多数のコンテンツ・プロバイダ、例えば、レストラン情報１０５、気象情報１１０、及び他のそのようなポータル１１５は、それぞれのデータをＡｐｉｐｅ＠、つまり、通信事業者の機器１２０を通じてリアルタイム・ユーザに流す。

通信ネットワーク・インフラストラクチャのコストが高いこと、また認知された陳腐化を避ける必要があることから、通信システム事業者は、技術統一の利点を活かすためにコンテンツ・プロバイダとユーザとの間のインターフェースを再構成しなければならない。特に、通信インフラストラクチャ及びサービスを軽視することを避け、アイデンティティの喪失を避ける代替えパラダイムを実現するシステム及び方法が必要である。さらに、図１のパラダイム１００では、携帯電話加入者に関係する位置状況、多数の将来のアプリケーションにおいて重要となるエリアなどの本質的にサービング通信ネットワーク内で提供されるリアルタイム情報を利用することはできない。

移動局との間でやり取りされる位置及び情報に関係する従来技術の方法の実施形態には、一般にＧＰＳシステムを使用してユーザの位置変化を追跡し、車両の地理座標に関する情報をディスパッチャからユーザに送ることを記述する米国特許第５，５５９，５２０号が含まれる。

米国特許第５，９２６，１０８号は、一般に動画情報をページャに供給することを説明している。ページャでは、まず、システムに情報を要求し、次に、システムは、ページャの位置を判別して、自分の位置及びオプションによりページャ・ユーザの予約チケットに基づいて動画情報を送信する。

米国特許第６，１３１，０２８号は、一般にユーザの地理的位置に基づいて特定の事前に定義されている機能を備えることを説明している。これらの機能は、位置に基づく呼転送又は事前定義された事業所指令とすることが可能である。

米国特許第５，９３０，６９９号は、一般に、移動局の位置に基づき企業に関する情報を提供することを説明している。セルのアイデンティティは、システムによって判別され、そのエリア内の企業に関する情報が移動局に送信される。

米国特許第６，０９１，９５６号は、一般に、現在の位置又は潜在的宛先においてモバイル・コンピュータが遭遇する場所及びイベントに関するサービスを提供するシステムを説明している。モバイル・コンピュータは、ユーザが訪れることを望んでいる場所に関係するイベントを通知される。この情報に基づき、モバイル・コンピュータは、他の人に対し応答する、完全に回避する、又は通信するか、或いはそのようなイベントにかんがみて自分の計画を修正することができる。

米国特許第６，１０８，５３３号は、一般に、キーワードを使用してデータベース内の情報を検索する機能を、移動局に付加することを説明している。このような情報については、移動局の位置に関する知識及びそのエリア・ロケーション・データベース内での移動局によって与えられるキーワードの検索を必要とする場合がある。

米国特許第６，１１５，６１１号は、一般に、情報センターが複数の移動端末に接続されていることについて説明している。移動端末は、位置情報だけでなく移動端末ユーザにとって有用な情報センターからの他の情報にアクセスする。情報センターは、移動端末からの情報及び／又はサービスを蓄積し、移動端末位置情報に関係する移動端末に情報を提供するために使用される。

したがって、本発明のいくつかの実施形態の目的は、通信ネットワーク事業者により大きな価値をもたらし、ネットワークの技術的な利点を活かすことができる、移動体でのインターネット利用のための、新しいシステム、方式、及び／又は方法を提示することである。

他の目的は、本発明のいくつかの実施形態のシステム、方式、及び／又は方法において、携帯電話加入者及び利用可能なコンテンツに関する通信ネットワーク内で利用可能なリアルタイム情報をよりよく利用し、それにより、ネットワーク機能を活用して収益を生み出すことである。

本発明のいくつかの実施形態の他の目的は、本明細書で説明されているイネーブラ（enabler）が通信ネットワークのリアルタイム機能を活用することである。

本発明のいくつかの実施形態の他の目的は、イネーブラが、ユーザの状況、例えば、ユーザの位置、ユーザ・ステータスなどに基づきサービスをよりよく個人化できるようにすることである。

方法、システム、及び配置により、通信ネットワークと情報サービス・プロバイダとの間の情報交換を円滑にする。例えば、いくつかの実施形態によれば、Ｂｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓ（Ｂ２Ｂ）エンジンは通信ネットワーク及び情報サービス・プロバイダとの間のインターフェースを実現する１つ又は複数の論理モジュールを備える。Ｂ２Ｂエンジンを使用することにより、例えば、通信ネットワークから情報サービス・プロバイダへのリアルタイム情報の報告が容易になる。このリアルタイム情報は、加入者ユニットの位置を含み、例えば、Ｂ２Ｂエンジン内のマッピング・データ構造に基づいて取得及び／又は報告することができる。このデータ構造では、サービス・クラスを、関連するガイダンスを指示する、又は与えることができる１つ又は複数のパラメータとともに、それぞれの値、及び規定されたパラメータを得るためのメカニズムにマッピングすることができる。このメカニズムは、特定のネットワーク・ノード／エンティティだけでなく、収集の頻度、位置伝送プレシピテーション・ソース（location transmission precipitation source）などをも含むことができる。このようなＢ２Ｂエンジン例では、例えば、通信ネットワーク事業者と情報サービス・プロバイダ事業者との間の合意による１つ又は複数の要件に基づき、位置に合わせてあつらえたコンテンツ・データ及び／又はサービス（location-tailored content data and/or services）を加入者に提供することができる。

開示されている発明は、本発明の重要な実施形態を示す、参照により明細書に組み込まれている、付属の図面を参照して説明される。

本出願の多数の革新的教示について、本発明の好ましい実施形態を特に参照して説明する。しかし、このような種類の実施形態は、本発明の革新的教示の多数の有益な用途のうちのごくわずかの実施形態であるにすぎないことは理解されるであろう。概して、本出願の明細書のステートメントでは、さまざまな請求されている発明内容の範囲を必ずしも定めていない。さらに、発明の特徴／実施形態に適用されるステートメントもあれば、適用されないステートメントもある。

本発明は、リアルタイム・ネットワークに固有の携帯電話加入者の現在の活動、プリファレンス、位置、使用及び行動パターンなどの、携帯電話加入者のリアルタイム情報に基づいて、個人化された、カスタマイズ可能なインテリジェント型情報及び関連するサービスを携帯電話加入者に提供するシステム及び方法を規定する。

上で述べたように、図１は、情報を通信加入者に供給する従来の通信システムを例示している。従来技術では、例えば、レストラン及び気象情報１０５及び１１０のコンテンツは、コンテンツ・プロバイダからエンド・ユーザに直接供給される。しかし、通信事業者１２０は、このパラダイムでは、多くの現在のＩＳＰと同様に、情報をエンド・ユーザに受け渡すパイプ・プロバイダにすぎない。特に、以下で詳述するように、通信事業者１２０は、ユーザに関するリアルタイム情報１３０をコンテンツ・プロバイダと共有せず、コンテンツ・プロバイダから直接、もちろんリアルタイムで活動するユーザに一方向で情報を受け渡す手段にすぎない。例えば、携帯電話加入者が従来のシステムで加入者の現在位置に関連する気象情報を取り出すために、サービング（serving：サービスを提供する）移動体通信ネットワークはすでに携帯電話加入者のおおよその位置を知ってはいるが、サービング移動体通信ネットワークは単にそのような情報の伝達のためのコンジット（conduit）として動作するだけなので、携帯電話加入者は、それでも、手動で位置情報をインターネット・コンテンツ・プロバイダに供給する必要がある。

そこで、図２を参照すると、本発明の好ましい実施形態によるＢｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓ（Ｂ２Ｂ）エンジン２１０が例示されている。Ｂｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓエンジン２１０は、図６及び７と関連する説明を参照して以下でより完全に例示し、説明するように、多数のアプリケーション・モジュール２２０を含む。好ましい構成では、Ｂ２Ｂエンジン２１０は、参照番号２２４で図２に一般的に示されているネットワーク・ハードウェア、例えば、Ｓｐａｒｃプロセッサで実行され、安定しており以下で詳述するさまざまな機能を実行するオペレーティング・システム／ミドルウェア２２２、例えば、Ｓｏｌａｒｉｓ ＯＳを使用する。もちろん、当業者であれば理解しているように、本発明の実装において、他のハードウェア及びソフトウェアを使用することもできる。さらに図２を参照すると、Ｂ２Ｂエンジン２１０は、通信システム２３０及びインターネット２５０に接続されている。

通信システム２３０は、多数の加入者又はユーザ端末、例えば、携帯電話、パーソナル・デジタル・アシスタント（ＰＤＡ）、又は無線若しくは有線通信デバイス或いは信号を受信することができる機器にサービスを提供する無線サービス・プロバイダ又は任意のサービス・プロバイダを含むのが好ましい。さらに、Ｂ２Ｂエンジン２１０は、情報をユーザに事前に供給するコンテンツ・プロバイダ・アプリケーションを含む、一般に参照番号２５０で示される、インターネットにリンク２４８を介して結合される。供給される情報は、気象サーバ２６０、金融サーバ２６２、ニュース・サーバ２６４、及び／又は広告サーバ２６６上に置かれ、そこから各リンク２５２を介してインターネット２５０に転送することができ、それぞれのサービスのゲートウェイとなる。

このような収集された情報に基づいていくつかのサービスを収集し提供するためのインターネット・ポータルをインターネット２５０に接続することもできる。このようなポータルは、さらに、他の関連するサーバ２６０、２６２、２６４、２６６と通信し、インターネット２５０を介してそのような収集された情報を要求者に伝達することができる。

そこで図３を参照すると、本発明の好ましい実施形態が示されており、図１に示されている従来のパラダイムと比較した本発明の代替えパラダイムを示している。サービング通信事業者１２０に接続されているＢ２Ｂエンジン２１０は、特定の携帯電話加入者と関連する特定のリアルタイム情報を、レストラン情報プロバイダ１０５、気象情報プロバイダ１１０、又はサービスポータル１１５などのコンテンツ・プロバイダのいずれか１つに伝達する。次に、これらのコンテンツ・プロバイダ又はポータルはそれぞれ、特定の携帯電話加入者に関連する受信されたリアルタイム情報を使用して、その特定の加入者のリアルタイム・ステータス又はプリファレンスに合わせてカスタマイズされたサービスを提供することができる。例えば、付近のイタリアン・レストランに対する要求については、携帯電話加入者が手動で現在の位置をタイピングすることなく要求側携帯電話加入者に応答し、提供する。Ｂ２Ｂエンジンは、自動的に、要求側携帯電話加入者の現在地を自動的に受信し、このリアルタイム情報（位置情報）を事前にコンテンツ・プロバイダに伝達する。

図８でさらに説明されているように、特定のコンテンツ・プロバイダが特定の携帯電話加入者と関連する特定のリアルタイム情報又はイベントを受信するために、コンテンツ・プロバイダはＢ２Ｂエンジンへの加入登録を必要とする。コンテンツ・プロバイダは、特定の携帯電話加入者と関連する移動体識別番号を提供し、Ｂ２Ｂエンジンに加入登録し、コンテンツ・プロバイダを監視し、その特定の携帯電話加入者と関連する特定のリアルタイム情報をコンテンツ・プロバイダに提供する必要がある場合がある。例えば、気象情報プロバイダは、特定の加入者の位置及びＡｏｎ＠情報を監視するためＢ２Ｂエンジンに加入登録することができる。その結果、その特定の携帯電話加入者が移動局をオンにすると、必ず、Ｂ２Ｂエンジンによってそのようなリアルタイム情報が気象情報プロバイダに提供される。次に、気象情報プロバイダは、自動的に、その特定の位置に関連する現在の気象情報を携帯電話加入者に送る。携帯電話加入者は、手動で気象情報を要求することも、ユーザが手動で現在の自分の位置を入力する必要もない。自分の電話をＡｏｎ＠に切り換える動作により、それらの事前に定義されているサービスの生成のトリガが自動的にかかる。他の例では、ユーザが市内に到着すると、この都市の気象情報、この都市に関する見出しニュース、その都市の交通状況などがユーザに送信される。これはすべて、ユーザのことを知らなくても自動的に実行されるが、ユーザのプリファレンスに応じて、ネットワークはそのインテリジェント型機能により、この位置にある間にユーザがこの情報を必要とすると判断を下す。さらに、旅行中のユーザが犯罪多発地域又は芳しくない近隣を通る場合、Ｂ２Ｂエンジンはインテリジェント型機能により、ユーザの位置を知り、この現在の位置の犯罪発生率又は最新見出しニュースに関する情報をどれが送信するかをポータルに通知する。これは、移動中の人々の役に立ち、また一般に、旅行頻度にかかわらず人々の役に立つ。さらに、本発明の好ましい実施形態では、ネットワークは全体として相互接続され、インテリジェント型機能により、ユーザ・ステータスに関する情報の交換が行われ、エンド・ユーザに最良のサービスを提供することができる。提案されているＢ２Ｂエンジンは、この相互接続機能を備え、インテリジェント型機能により、情報プロバイダ又はポータルをユーザが属する移動体事業者に接続する。非リアルタイム・システム、ポータル、及びリアルタイム・システム、移動体事業者は動作面の特質の違いがあっても円滑に相互作用し、動作する。

レストラン情報１０５、気象情報１１０、及びポータル１１５などのコンテンツ・プロバイダ情報では、図１のように、又はそれとは別に、要求された情報又はサービスをチャネル方式又はパイプ方式で通信事業者１２０に直接流すか、又は図２に関して説明した、及びさらに詳しく後述する、エンジン２１０などの、Ｂ２Ｂエンジン２１０を通じて通信事業者に送信することができる。本発明のＢ２Ｂエンジン２１０は、通信ネットワーク上に配置され、コンテンツ・プロバイダと通信事業者１２０との間に挟み込む形が好ましいことは理解されるであろう。したがって、Ｂ２Ｂエンジン２１０は、それぞれのユーザに関連する前述のリアルタイム情報１３０、例えば、位置及び／又はプリファレンスを取得し、この情報を処理する役割を持つ。Ｂ２Ｂエンジン２１０は、リアルタイム・ステータス情報を受信した後、リアルタイム・データをコンテンツ・プロバイダに転送し、それにより、それぞれのユーザのリアルタイム状況及びプリファレンスに応じてカスタマイズを許可する。

次に図面の図４を参照すると、例えば、Ｇｌｏｂａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｍｏｂｉｌｅ（ＧＳＭ）システム、Ｐｅｒｓｏｎａｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ（ＰＣＳ）、又は他の移動体通信規格に従って通信事業者１２０が移動体事業者である本発明の他の好ましい実施形態が示されている。移動体ネットワーク内に配置されているＢ２Ｂエンジン２１０は、移動体事業者１２０とそれぞれのコンテンツ・プロバイダ、例えば、前述のレストラン情報１０５、気象情報１１０、及びポータル１１５との間のリアルタイム情報交換を維持する。Ｂ２Ｂエンジン２１０は、ネットワーク及びそれぞれのユーザと通信し、さまざまな加入者情報、つまり、申請及び必須条件に関する加入者規則２４２、加入者のプリファレンス２４４、加入者ステータス２４６、及び携帯電話加入者のニーズを満たすのに必要なインテリジェント機能要因２４８を判別することにより、移動体事業者のネットワークとの通信で携帯電話加入者に関するリアルタイム情報を判別する。この加入者情報は、ユーザ毎に収集され、コンテンツ・プロバイダに送られ、コンテンツ・プロバイダはこの情報を携帯電話加入者に提供する。レストラン情報１０５、気象情報１１０、及びポータル１１５は、ユーザのリアルタイム・ステータスに応じてカスタマイズされ、加入登録しているユーザのリアルタイム・ステータス、要件、プリファレンス、規則、及び／又は位置に関してＢ２Ｂエンジン２１０により、Ｂ２Ｂエンジン２１０からリアルタイムでコンテンツ・プロバイダに送られる。

本発明の好ましい実施形態では、本発明のＢｕｓｉｎｅｓｓ−Ｔｏ−Ｂｕｓｉｎｅｓｓ（Ｂ２Ｂ）エンジン２１０を使用して、リアルタイム・システム、例えば、前述の通信事業者１２０及び非リアルタイム・システム、例えば、コンテンツ・プロバイダを統合する。本明細書で説明しているように、Ｂ２Ｂエンジン２１０は、コンテンツ・プロバイダによってすでに要求されているいくつかの加入登録イベントに従ってそれぞれの通信事業者１２０及び関連するネットワーク要素と通信し、加入者に関するリアルタイム情報を取得し、加入者情報を処理し、その情報をコンテンツ・プロバイダに供給する。

本発明の他の好ましい実施形態では、複数の通信事業者１２０がおり、それぞれ異なる加入者が関連付けられている。この実施形態のそれぞれの通信事業者１２０は、独立に活動し、それぞれの加入者に関するリアルタイム情報をコンテンツ・プロバイダに供給する。本発明の好ましい実施形態では、それぞれの通信事業者１２０は、一意的な識別番号を発行される。それぞれのコンテンツ・プロバイダは、識別可能な通信事業者１２０により出される要求に従って、要求された情報を通信事業者１２０ネットワーク内に加入登録されているユーザに送信する。

次に図５を参照すると、本発明のＢｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓ（Ｂ２Ｂ）エンジン２１０とネットワークの異なる要素との間のやり取りの実施形態が示されている。無線通信システム、有線通信システム、及びＩＳＰなどのリアルタイム・システム２７０は、Ｂ２Ｂエンジン２１０とインターフェースし、加入者及びユーザに関するリアルタイム情報をＢ２Ｂエンジン２１０に供給する。コンテンツ・プロバイダ２７２は、Ｂ２Ｂエンジン２１０に結合されており、Ｂ２Ｂエンジン２１０からのリアルタイム情報及び加入者の行動情報を取得する。

コンテンツ・プロバイダ２７２は、さらに、情報をエンド・ユーザ、例えば、無線通信加入者、有線通信加入者、又はＩＳＰ加入者に提供するが、一般に、Ｂ２Ｂエンジン２１０を通じて、参照番号２７４により示されている。

さらに図５を参照すると、これらの監視されているリアルタイム・イベントを外部コンテンツ・プロバイダに伝達するのではなく、Ｂ２Ｂエンジンと関連するアプリケーション・モジュール及びサービスは、独立に、特定の所望のサービスを生成し、それらの監視されている携帯電話加入者に提供することができる。したがって、多数のＢ２Ｂ開発者２７８は、Ｂ２Ｂエンジン２１０でアプリケーション・モジュールを開発し、更新することにより、新しいサービスをサポート及び／又は既存のサービスを強化する。

本発明の他の実施形態では、Ｂ２Ｂエンジン２１０は、情報をエンド・ユーザに提供するため、ポータル又はコンテンツ・アグリゲータ（aggregators）に接続されている。ポータル及びコンテンツ・アグリゲータは、さまざまなコンテンツ・プロバイダから情報を収集し、収集された情報を後で詳しく説明するさまざまな手段を通じてエンド・ユーザに供給する。

特に、ユーザは、まず、ポータル又はコンテンツ・アグリゲータに加入登録する。ユーザの加入登録後、ポータルではその加入登録を、イベントとして、Ｂ２Ｂエンジン２１０に受け渡す。Ｂ２Ｂエンジン２１０は、ユーザの加入登録イベントを受け取って、それをＢ２Ｂエンジン・メモリ２１０Ａ又はデータベース内に格納する。データベースは、Ｂ２Ｂエンジン２１０内の内部データベース又はＢ２Ｂエンジン２１０によりアクセスすることが可能な外部データベースであるのが好ましいことは理解されるであろう。

もちろん、当業者であれば、Ｂ２Ｂエンジン２１０をさまざまな動作プロトコルを使用する通信ネットワークに組み込むには、情報の流れ及び相互交換を円滑にするために必要なさまざまなデータベース、インターフェース、及びポータルを作成する作業を伴うことを理解するであろう。例えば、ユーザのプリファレンスは、プリファレンス・データベースに格納することができ、トリガ条件又はイベント（規則）は通信を開始する動作をする。インターネットの移動体ユーザは、固定局とある程度同等なアクセスだけでなく、モビリティ（mobility：移動、移動性）に基づき、強化され、個人化されたサービスへのアクセスを期待するであろう。

すでに説明したように、移動体事業者に関しては、加入者との関係（月々の請求書、個人情報）を利用することにより単なるパイプ・プロバイダ以上のものになり、無線インターネットを利用して新しい収益を生み出す機会が得られる。次に、コンテンツ・プロバイダは、コンテンツを利用可能にし、移動体インターネット加入者にとって個人的なものにするというさまざまな難題に直面する。実際、通信事業者によるインターネット・サービスの個人化は、特に、縦方向のポータル及び個人化されたユーザ・プロファイルの出現で、インターネット上でますます個人化されるサービスを提供するトレンドと一致している。

図２〜５に関して上で説明し、以下で詳しく述べるが、本発明のシステム及び方法は、移動体ネットワーク内に固有の加入者活動、プリファレンス、位置、使用、及び行動パターンを利用し、個人化されたカスタマイズ可能な移動体インターネット・サービスをリアルタイムで提供するインテリジェント型エンジンである。特に、本発明により、コンテンツ・プロバイダは、移動体ネットワークのモビリティに基づいて個人化されたコンテンツを構築することができ、携帯電話加入者は、モビリティに基づいて個人化されたコンテンツを受信することができ、移動体事業者は、移動体通信ネットワーク内のモビリティ情報を利用して価値連鎖を上げることができる。さらに、本発明は、移動体通信ネットワーク内の携帯電話加入者と関連するリアルタイム情報に基づいて新しいインターネット・サービスを構築するサービス・プロバイダ用のプラットフォームを実現する。

本発明のポータル及びインターフェースに関して以下で説明するように、リアルタイム移動体インターネット環境を作成する際にさまざまな新しい機能が用意される。特に、個人プリファレンスのユーザ・インターフェース及びデータベースは、個人プリファレンスを選択し、インターネット加入者のプリファレンスを通信事業者によって管理されているデータベースに格納するメカニズムを備える。必須のリアルタイム・モビリティ情報は、通信システムにおけるネットワーク・ノード及び／又はネットワーク要素とのインターフェースを介して提供される。規則ベースの環境では、無線インターネット加入者はリアルタイム・イベントに基づいて新しいサービスをカスタマイズ又は開発することができる。規則ベースのカスタマイズ可能なサービスの例を以下に示す。

移動体の電源投入後、
ｆｉｎａｎｃｅ．ｙａｈｏｏ．ｃｏｍにアクセスして情報を取得し、
ショート・メッセージ・サービスを介して移動体に配信する

この例では、無線インターネット加入者は、自移動体の電源投入をリアルタイム・イベントとして使用して、サービスを呼び出し、そのサービスをカスタマイズして特定のフォーマットで特定のＷｅｂサイトからニュースを配信するようにする。他のサービス例を以下に示す。

新しい町への到着を検出した後、
呼び出し先を新しい番号に切り換える
ホテルの部屋及び自動車のレンタルの要求を旅行コーディネータに配信する
確認の受信を待つ
確認の肯定応答を行う
ユーザに警告を送る

この例では、無線インターネット加入者は、例えば飛行機の到着時刻を利用して、旅行ニーズの調整を円滑にするためさまざまなアクションを開始する。時間帯変更が生じた場合、時間変更の確認を加入者に求める警告を生成することができる。

上で詳しく説明したように、所望のすべてのイベントは、コンテンツ・プロバイダによりＢ２Ｂエンジンに加入登録される。Ｂ２Ｂエンジンは、その後、サービング移動体通信ネットワークと通信し、携帯電話加入者に対する特定のイベントが発生したかどうかを判別し、そのようなトリガ・イベントを加入登録されたコンテンツ・プロバイダに伝達し、コンテンツ・プロバイダが自動的にすべてのサービスを遂行するようにできる。

Ｂｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓ（Ｂ２Ｂ）の多数の特徴について、上で説明されている。説明されている機能を実行し、ネットワークとの相互接続を可能にするため、いくつかの機能及びコンポーネントがＢ２Ｂエンジンで使用可能になっていなければならない。そこで、図６を参照すると、本発明の好ましい実施形態によるさまざまなＢｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓ（Ｂ２Ｂ）エンジン２１０のアプリケーション・モジュール２２０が例示されている。図に示されているように、Ｂ２Ｂエンジン・アプリケーション・モジュール２２０は、さまざまなディスクリート・モジュールを備え、それぞれ、システム内で重要な役割を果たす。特に、Ｂ２Ｂアプリケーション・モジュール２２０は、インターフェース・モジュール（ＩＭ）２８０、データ収集モジュール（ＤＣＭ）２８２、行動解析モジュール（ＢＡＭ）２８４、サービス開発環境（ＳＤＥ）２８６、リアルタイム配信モジュール（ＲＤＭ）２８８、規則開発環境（ＲＤＥ）２９０、ビジネス・データ／エンド・ユーザ加入登録モジュール（ＢＤＳＭ）２９２、サービス実行モジュール（ＳＥＭ）２９４、パフォーマンス及び課金モジュール（ＰＡＣＭ）２９６、並びにオペレーション及びメンテナンス・モジュール（ＯＡＭＭ）２９８を含む。

前述のインターフェース・モジュール（ＩＭ）２８０は、アプリケーション・モジュール２８２〜２９６とコンテンツ・プロバイダ及び通信システムとのインターフェースをとる役目を持つ。ＩＭ ２８０は、異なる通信システム及びＩＳＰなど、複数の外部コンポーネントとインターフェースする。ＩＭ ２８０は、コンテンツ・プロバイダともインターフェースする。ＩＭ ２８０の主要機能の１つは、ネットワーク内の外部コンポーネントをＢ２Ｂエンジン２１０内のアプリケーション・モジュールにリンクすることである。好ましい実施形態では、ＩＭ ２８０は、データ収集モジュール（ＤＣＭ）２８２及びリアルタイム配信モジュール（ＲＤＭ）２８８と内部的にインターフェースする。もちろん、ＩＭ ２８０は、さらに、システム要件に応じて、他の内部モジュールだけでなく、ネットワークの外部コンポーネントともインターフェースすることが可能であることも理解されるであろう。

さらに図６を参照すると、データ収集モジュール（ＤＣＭ）２８２は、通信システム及びＩＳＰからリアルタイム・データを取り出し、格納する役目を持つ。ＤＣＭ ２８２は、コンテンツ・プロバイダからデータ加入登録に関する情報を得るため、ビジネス・データ加入登録モジュール（ＢＤＳＭ）２９２と内部的にインターフェースする。ＤＣＭ ２８２は、さらに、行動分析モジュール（ＢＡＭ）２８４及びリアルタイム配信モジュール（ＲＤＭ）２８８とインターフェースし、リアルタイム情報をコンテンツ・プロバイダに配信する。

行動分析モジュール（ＢＡＭ）２８４は、ＢＤＳＭ ２９２からの加入登録情報をチェックし、リアルタイム・データに対し分析を実行する一組の人工知能プログラムであるのが好ましい。ＢＡＭ ２８４は、その結果をコンテンツ・プロバイダに配信するため、ＲＤＭ ２８８に結合されているのが好ましい。さらに、ＢＤＳＭ ２９２及びＲＤＭ ２８８とインターフェースするために、ＢＡＭ ２８４は、データ収集モジュール（ＤＣＭ）２８２とインターフェースしている。

規則開発環境（ＲＤＥ）２９０を使用すると、サービスの開発に使用される規則を開発することができる。ＲＤＥ ２９０は、規則を規則リポジトリ（Ｒｒｅｐ）に格納する。これらの規則は、新しいサービスが採用され、システム内のさまざまなコンポーネントのプリファレンスに従って変更されるのにあわせて常に更新される可能性がある。サービス開発環境（ＳＤＥ）２８６を使用することにより、通信事業者又はエンド・ユーザは一組の規則に基づいていくつかの新しいサービス群を開発することができる。ＳＤＥ ２８６は、サービスを開発するため規則リポジトリと、またサービス実行モジュール（ＳＥＭ）２９４と内部的にインターフェースされる。サービス実行モジュール（ＳＥＭ）２９４は、使用されるサービスを実行し、ＳＤＥ ２８６及びＢＤＳＭ ２９２と内部的にインターフェースされる。

ビジネス・データ／エンド・ユーザ加入登録モジュール（ＢＤＳＭ）２９２を使用することにより、コンテンツ・プロバイダはリアルタイム及び行動データを購読することができ、またエンド・ユーザはサービスに加入登録することもできる。そのために、ＢＤＳＭ ２９２は、ＲＤＭ ２８８と内部的にインターフェースされている。パフォーマンス及び課金モジュール（ＰＡＣＭ）２９６は、統計量を収集し、コンテンツ・プロバイダによってリアルタイム・データが要求された回数及び加入者がサービスにアクセスする回数を追跡する役割を持つ。ＰＡＣＭ ２９６は、さらに、ネットワーク及びその能力を最大限利用するのに役立つと思われる他の統計データも追跡する。ＰＡＣＭ ２９６はさらに、後処理の課金も行う。

最後に、オペレーション及びメンテナンス・モジュール（ＯＡＭＭ）２９８は、Ｂ２Ｂエンジン２１０の管理及び構成を行う役目を持つ。ＯＡＭＭ ２９８は、コンテンツ・プロバイダの構成、Ｂ２Ｂエンジンのメンテナンス、システムに発生した障害の処理、及びシステム内のセキュリティ問題、並びに他の運用及びメンテナンス機能の管理を行うことができる。

図６に関して例示され、上で説明されているＢ２Ｂエンジン・アプリケーション・モジュール２２０は、結合して１つのモジュールにまとめるか、又は少なくともいくつかを結合してまとめられるという事実にも拘わらず、独立しているものとして取り扱うのが好ましい。ディスクリート・モジュールは、アプリケーション用にモジュール型設計であるのが好ましく、またＪａｖａ（登録商標）ベースであるのが好ましい。それとは別に、上述の特性に適している他のプログラミング言語として、例えば、Ｃ＋＋、Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔｓ、Ｊａｖａ（登録商標）Ｂｅａｎｓ、ＪＳＰ、などを採用することもできる。上述のように、本発明の重要な一態様はリアルタイムに近い能力を持つ。リアルタイム環境の処理に加えて、システムは、障害を減らし、フォルト・トレラント・システムを持つように設計されている。

Ｂ２Ｂエンジンの他の好ましい実施形態は、さらに、モジュール性と異なるモジュール・アーキテクチャを採用する実装を例示するが、図７に示されている。この実施形態のＢ２Ｂエンジンは、参照番号３１０で示されており、上述のようにインターフェース・モジュール３１５並びにオペレーション及びメンテナンス・モジュール３２０も含む。しかし、この実施形態は、インテリジェンス・モジュール（ＩＮＭ）３２５、イベント受信及び処理モジュール（ＥＲＰＭ）３３０、課金モジュール（ＣＭ）３３５、加入登録データベース（ＳＤ）３４０、有効性確認モジュール（ＶＭ）３４５、データ収集モジュール（ＤＣＭ）３５０、及びイベント転送モジュール（ＥＦＭ）３５５を備えるのが好ましい。

ポータルから加入登録イベントを受信すると、Ｂ２Ｂエンジンインターフェース・モジュール（ＩＭ）３１５により、ＩＭ ３１５は有効性確認モジュール（ＶＭ）３４５とインターフェースし、この加入登録イベントの有効性を確認する。ＶＭ ３４５は、データ収集モジュール（ＤＣＭ）３５０とインターフェースし、これにより、加入者アイデンティティを送信し、イベントを加入登録データベース（ＳＤ）に格納することができる。ＳＤは、セキュリティで保護されていなければならず、また加入者の数に合わせて拡張できるようにスケーラビリティを有するのが好ましい。ＤＣＭ ３５０は、さらに、加入登録されているユーザがＢ２Ｂエンジン３１０データベースに正常に登録されていることをポータルに通知する役割を持つ。携帯電話加入者のステータスを示すネットワーク・ノードから受信したイベントは、インターフェース・モジュールに到達し、イベント受信及び処理モジュール（ＥＲＰＭ）３３０で処理される。これらのイベントは、有効性確認モジュール（ＶＭ）３４５を使用して有効性の確認が行われ、その際にＳＤに加入登録されているユーザ・プリファレンスにアクセスするが、これは、ユーザが登録されているＢ２Ｂエンジン３１０加入者であることを確認するために実行される。

ユーザ・プロファイルの有効性を確認した後、セキュリティ保護程度の高いＨＴＴＰ通知メッセージを介し、イベント転送モジュール（ＥＦＭ）３５５を使用して、イベントはパックされ、通知がポータルに送信される。加入登録ユーザ・ステータスに関してこの通知がポータルに送信された後、課金モジュール（ＣＭ）３３５は、送信された情報に関するポータルの課金レコードを作成する。

図６及び７に関して上述したように、これらのモジュールは、システムで必要とする機能を実現するさまざまな構成に配置することが可能である。しかし、異なる視点からＢ２Ｂエンジン２１０／３１０を見ると、モジュールの異なるアーキテクチャを実装することも可能である。

ポータルとＢ２Ｂエンジンとの相互作用をよく理解するために、図８を参照すると、ポータルからのユーザの加入登録イベントの伝送が詳しく説明されている。図８は、加入登録イベント及びこの加入登録に関するポータル３６２とＢ２Ｂエンジン３６４との相互作用に対する一般に参照番号３６０で示されているタイミング図を表す。ユーザは、まず、例えば、ポータル３６２のＷｅｂサイト、例えば、一般に参照番号３６６で示される、ｗｗｗ．ｙａｈｏｏ．ｃｏｍなどを通じて、複数のメカニズムを使用してポータル・サービスに加入登録する。しかし、ユーザは、さまざまな人及びプリファレンス情報をポータル３６２に送る必要がある。この情報には、ユーザ識別番号（ＭＳＩＳＤＮ）、移動体事業者、及び監視する所望のコンテンツ又はイベントに関連するさまざまなプリファレンスが含まれる。ポータル３６２は、供給されたユーザ情報すべてをデータベースに格納する３６８。情報を格納した後３６８、ポータル３６２はイベント通知３７０を送信して、加入登録ユーザを移動体事業者を担当する適切なＢ２Ｂエンジン３６４に通知する。本発明の好ましい実施形態では、Ｂ２Ｂエンジン３６４は移動体事業者、又は場合によっては複数の移動体事業者を受け持つ。Ｂ２Ｂエンジン３６４に送信された通知イベント３７０は、ユーザの移動局識別番号（ＭＳＩＳＤＮ）、加入登録詳細、イベント、並びにユーザ及び他の関連する情報のプリファレンスを含む。この通知イベントは、Ｓｅｃｕｒｅｄ ＨＴＴＰプロトコルを使用して送信するのが好ましい。

Ｂ２Ｂエンジン３６４は、イベント通知３７０を受信し、その中の情報を処理する。この内部有効性確認は、図６及び７に関して説明されているものなど、レイヤ化アーキテクチャを使用して好ましい実施形態において実施される。図８を再び参照すると、イベント通知３７０を受信した後、参照番号３７２によって一般に示される第１のレイヤ又はクラスは、新しい接続の確立を要求する（ステップ３７４）。第２のレイヤ又はクラス７６６は、この加入登録イベントを、ユーザ識別番号（ＭＳＩＳＤＮ）の有効性を確認し（ステップ３８２）、加入登録情報をデータベースに格納する（ステップ３８４）第３のレイヤ又はクラス３８０の中に挿入する（ステップ３７８）。有効性確認ステップ３８４が完了すると、好ましくはＨＴＴＰプロトコルを使用して、加入登録イベント通知３７０に関する肯定応答をポータル３６２に送信する（ステップ３８６）。その後、Ｂ２Ｂエンジンは、その特定の携帯電話加入者に関連する要求されたリアルタイム情報を監視する。

Ｂ２Ｂエンジンは、上で説明されているように、さまざまな方法で動作することが可能である。本発明の一実施形態では、Ｂ２Ｂエンジンは、更新された情報を要求するため関連するネットワーク・ノードのポーリングを行う。他の実施形態では、ネットワーク・ノードは、ユーザのステータスの変化をＢ２Ｂエンジンに通知するようにプログラムされる。さらに他の実施形態では、移動局は、ステータス情報をＢ２Ｂエンジンに報告することができ、これは、移動局内のアプリケーション・クライアント・プログラムをトリガすることにより実行される。しかし、これらの好ましい実施形態は、同時に機能させることが可能である。例えば、あるネットワーク・ノードがＢ２Ｂエンジンにそのステータスを報告するのと同時に、Ｂ２Ｂエンジンは、他のネットワーク・ノードのポーリングを行うことができる。また、移動局は、そのステータスをＢ２Ｂエンジンに報告することが可能であり、またこの同じステータス・レポートをネットワーク・ノードによっても供給することが可能である。しかし、Ｂ２Ｂエンジンは、インテリジェント型機能により、送信された情報が関係し、冗長であると判別し、両方の情報を組み合わせて、ユーザ・ステータスの詳細な情報に基づいて高度な機能を実行する。

通信ネットワーク内のＢ２Ｂエンジン及びさまざまなモジュールの位置に関する上記の説明を念頭に置いて、図９に注目すると、これは、本発明の好ましい実施形態におけるＢ２Ｂエンジン４１０の相互作用例を示している。例示されているように、Ｂ２Ｂエンジン４１０はフロントエンド・ポータル４２０、移動局４３０（無線接続を介して）、並びにオペレーション及びメンテナンス（Ｏ＆Ｍ）４１５管理システムに接続されている。Ｏ＆Ｍシステム４１５を使用すると、事業者又は製品の所有者は、Ｂ２Ｂエンジンの運用及びメンテナンスを実行することができる。すべての障害及びアラーム処理は、このＯ＆Ｍシステム４１５を通じて制御し、監視することができる。また、リモート管理システムは、本明細書で示されているようにアクセス可能であるか、又は図６を参照して前のほうで説明したように、Ｂ２Ｂエンジン内の一モジュールである。図に示されているように、移動局４３０は、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）ツール・キット４３２及び／又は加入者識別モジュール（ＳＩＭ）開発ツール・キット４３４を備えることができる。

ＷＡＰツール・キット４３２は、当業で知られているように、ユーザが無線でインターネットのコンテンツ及びサービスにアクセスできるようにするＷＡＰアプリケーションを開発し、サポートするために使用される。ＷＡＰツール・キット４３２は、移動局４３０内に配置するのが好ましく、またＷＡＰプロトコルをサポートできるのも好ましい。

ＳＩＭツール・キット４３４は、移動局４３０の中に置かれ、移動局を使用し、インターネット上でのトランザクションを可能にする、付加価値サービス及び電子商取引に使用される。例えば、ＳＩＭツール・キット対応移動局を使用するユーザは、銀行口座のチェック、請求書支払い、及び今日の有線インターネット・アクセスで実行される他のすべてのサービスを享受できる。ＳＩＭツール・キット４３４は、参照番号４３６により一般に図９で示されているＳＩＭカードにプログラムされるのが好ましく、さらに、ネットワークとエンド・ユーザとの間のインターフェースを可能にする。移動体機器（ＭＥ）／加入者インターフェース・モジュール（ＳＩＭ）のＢ２Ｂエンジンとの相互作用の好ましい実施形態については、図１０〜１３を参照して以下で説明する。すでに指摘したように、Ｂｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓエンジン４１０は、さらに、情報をエンド・ユーザに供給する、フロントエンド・ポータル４２０、又は多数のポータルにも接続される。当業者であれば、この情報は、それぞれのユーザ・プリファレンスに従って手直しされ、さまざまなコンテンツ・プロバイダから収集される。本発明の好ましい実施形態におけるポータル４２０は、当業者であれば理解しているように、ダミー・ポータル４２２又はインターネット接続をうまく活用するように設計されているポータル、例えば、いわゆるワイズ・ポータル４２４とすることが可能であることも理解されるであろう。

図１０を参照すると、無線電話用のＡＯＦＦ＠Ｔｒｉｇｇｅｒの一例が示されており、それらのステップは、一般に、参照番号４５０で示されている。一般に参照番号４５２で示される、移動局（ＭＳ）は、その中に置かれている加入者識別モジュール（ＳＩＭ）ツール・キット４５４を備える。ＳＩＭツール・キット４５４は、定められた間隔で、図において一般に参照番号４５６で示されている、加入者ステータス及び移動局４５２ＩＳＤＮ番号（ＭＳＩＳＤＮ）を含む、ショート・メッセージ・サービス（ＳＭＳ）メッセージを送信する。ＳＩＭツール・キット４５４は、このアクションを実行して、関連するＢ２Ｂエンジン４５８に常に、ＭＳ ４５２のリアルタイム情報と位置を知らせる。このメッセージを受信すると、Ｂ２Ｂエンジン４５８のタイマー４６０が開始する。所定の時間間隔内で、タイマー４７４がタイムアウトにならず、他のメッセージがタイムアウト前に受信された場合、タイマーはリセットされる。しかし、Ｂ２Ｂエンジン４５８のタイマー４７２がタイムアウトになる、つまり、Ｂ２Ｂエンジン４５８が決められた時間内にユーザからメッセージを受信しなかった場合、Ｂ２Ｂエンジン４５８では、例えば、ＳＭＳメッセージ４６２がＢ２Ｂエンジン４５８に送信された後しばらくして、移動局４５２の電源がオフになってしまったと想定する。これは、例えば、ユーザがビジー状態であるか、又は眠っている状態であること、及びポータルにより加入登録ユーザに新しいコンテンツを送信すべきでないことを示すものとすることができる。Ｂ２Ｂエンジン４５８がタイマーの期間内にＳＭＳメッセージ４６２の後に他のメッセージを受信することに失敗した後、Ｂ２Ｂエンジン４５８はこのイベントの有効性を確認して処理し４６４、そのユーザのＭＳＩＳＤＮ及び加入登録ＯＦＦイベントの指示を含む、イベント通知４６６をこのイベントと関連するポータル４６８に転送する。その後、ポータル４６８は、通知を受信したことを肯定応答する４７０。

次に図１１を参照すると、本発明の好ましい実施形態において、システム及び方法の通常の動作を示すタイミング図が例示されており、それらのステップは、一般に、参照番号５００で示されている。図１２に関して説明されている実施形態と同様に、加入登録されているエンド・ユーザはポータル５０２で、特にポータル・データベースに情報及びプリファレンスを入力する（ステップ５０４）。エンド・ユーザのプリファレンスがポータル・データベースに格納された後５０４、好ましくはイベントが発生する前に、ＳＩＭアプリケーションがリアルタイム・サービス用及び無線アクティブ化で加入登録されたユーザ用に初期化され、複数のＳＩＭデータがポータル・データベースから、例えば無線インターフェースを介して、ショート・メッセージ交換センター（ＳＭＳＣ）５０８にダウンロードされる（ステップ５０６）。その後、ＳＩＭデータは、ピアツーピアで、一般に参照番号５１４で示される、番号ＳＩＭカードを内蔵する移動体機器（ＭＥ）５１２に送信される（ステップ５１０）。

ユーザ・プリファレンス、位置などの変更に関するイベントが発生すると、移動体機器５１２内に配置されている、一般に参照番号５１６で示される、ＳＩＭツール・キットは、Ｂ２Ｂエンジン５２０に加入登録されたユーザのステータスを通知し、ユーザのＭＳＩＳＤＮ番号を供給するＳＭＳメッセージ５１８を送信する。特にソケット・リスナ（socket listener）５２２で、Ｂ２Ｂエンジン５２０に到達すると、前述のＳＭＳメッセージ５１８は、ソケット・リスナ５２２によりＢ２Ｂエンジン５２０内に展開され（ステップ５２４）、その後、ＳＭＳメッセージング５１８で与えられる情報に基づいて新しいイベントを作成する（ステップ５２６）。Ｂ２Ｂエンジン５２０において一般に参照番号５２８で示される第２のレイヤ又はクラスは、新しいイベント情報５２６を受信した後、新しい接続８３０を確立し、一般に参照番号５３４で示されている、ユーザ・アイデンティティ及びプリファレンスをＢ２Ｂデータベース内に格納されている情報と比較することにより、加入登録されている５２６イベントの有効性を確認する５３２。新しい接続及び有効性確認情報を受け取った後、一般に図内の参照番号５３６で示される第３のレイヤ又はクラスでは、イベントを処理し（ステップ５３８）、任意選択により、Ｂ２Ｂデータベース５３４内に修正された情報を格納する。処理されたイベント５３８情報は、第３のクラス５３６により第４のクラス５４０に転送される。Ｂ２Ｂエンジン５２０内の第４のレイヤ５４０によりイベント通知メッセージ５４２がポータル５０２に送信され、イベントが受信されたことをポータル５０２に通知し、ポータル８０２にユーザのＭＳＩＳＤＮを与える。

ポータル５０２は、イベント通知メッセージ５４２を受信した後、肯定応答メッセージ５４４をＢ２Ｂエンジン５２０に送信し、好ましくはＨＴＴＰプロトコルを使用して、イベント通知５４２の受信を肯定応答する。本発明の好ましい実施形態では、供給されるすべての情報に対する課金５４６が発生し、肯定応答メッセージ５４４の後に、ポータル５０２に供給されるリアルタイム・イベント情報の課金５４６が発生する。イベントに関係するすべての関連情報をログに記録する課金レコードがＢ２Ｂエンジン内に作成される。例示されているように、情報は、ＳＭＳメッセージを使用してポータル５０２によりＭＥ５１２のエンド・ユーザに配信されるのが好ましい。もちろん、コンテンツは、それとは別に、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）を使用し、ＳＭＳメッセージ又はその他のそのようなプロトコルでＷＡＰを使用して、送信することが可能であることも理解されるであろう。

上述のように、特に図１２及び１３に関して、加入登録されているユーザは、ＳＩＭアプリケーションがプログラムされ実行される、ＳＩＭカード５１４を備える、移動局とも呼ばれる移動体機器（ＭＥ）５１２を採用している。本発明の好ましい実施形態では、Ｂ２Ｂエンジン５２０クライアント・アプリケーションは加入者識別モジュール（ＳＩＭ）に常駐し、移動体機器（ＭＥ）／ネットワーク・エンティティ内で発生するリアルタイム・イベントをＢ２Ｂエンジン８２０サーバ・ノードに報告する役割を持つ。クライアント・アプリケーションでは、ＳＩＭカード５１４からのトリガを使用して、ＳＩＭツール・キット・オペレーション５１６を呼び出し、ショート・メッセージをＢ２Ｂエンジン・サーバ５２０にＭＥ−Ｎｅｔｗｏｒｋ内で発生しているリアルタイム・イベントに関する情報とともに送信する。この実施形態では、送信されたショート・メッセージは、Ｂ２Ｂエンジンが宛先であり、移動体通信事業者はこの送信された情報のコンジットとして機能する。

ＳＩＭアプリケーション・ツール・キット５１６は、ＳＩＭ ５１４内に存在するアプリケーションが移動体機器（ＭＥ）５１２と相互作用し操作して、ＭＥプロファイルをＳＩＭ ５１４にダウンロードすること、データ（ステップ５０６）をＳＩＭ ５１４にダウンロードすること、ユーザのメニュー選択をＳＩＭ ５１４に転送すること、ＳＩＭ ５１４によりＭＯショート・メッセージ制御を行うこと、及びセキュリティ対策を実施することができるメカニズムを備える。プロアクティブ（proactive）ＳＩＭ ５１４は、当業者であれば理解するように、テキストの表示、発信音の再生、ショート・メッセージの送信、呼のセットアップを表示することが可能である。

ＳＩＭ ５１４及びＭＥ ５１２との相互作用は、図１２及び１３に関して説明されている以下の実施形態を参照すると最もよく示され、リアルタイム・サービスのＢ２Ｂエンジンにイベントを報告するＳＩＭ／移動体エンティティの好ましい実施形態を例示している。ユーザ・ステータス又はプリファレンスの変更後、Ｂ２Ｂエンジンは移動体機器（ＭＥ）によりそのような変更に関して更新される。これらの図では、Ｂ２Ｂエンジン・サーバに報告されるイベント例はＯＮ／ＯＦＦ、セル・グローバル・アイデンティティ（ＣＧＩ）、及び位置エリア（ＬＡ）変更である。

次に図１２を参照すると、Ｂ２Ｂエンジン５５２へのユーザＡＯＮ＠表示の、一般に図内の参照番号５５０で示される、タイミング図が詳しく例示されている。最初に、所定の移動体機器（ＭＥ）５５４はまず、関連するＳＩＭ ５５６を初期化する。この初期化（ステップ５５８）では、ＳＩＭデバイス５５６をアクティブ化し、テストし、どのような機能がサポートされているかを確認する。現在、このＳＩＭ ５５６初期化は、他の初期化プロトコルをそれとは別に使用できることも理解されるが、ＧＳＭ１１．１１規格に従って実行されるのが好ましい。プロアクティブ（proactive）ＳＩＭ ５５６の識別は、この段階で、プロアクティブＳＩＭサービスをＳＩＭサービス・テーブル内でアクティブ化することにより（ステップ５６０）実行される。しかし、ＭＥ ５５４がプロアクティブＳＩＭ機能をサポートしていない場合、プロアクティブＳＩＭ ５５６はプロアクティブＳＩＭ関連コマンドをＭＥに送信しないし、またその逆の送信もしない。ＭＥ ５５４は、アイドル・モードでは、呼び出し中とともに、ＳＴＡＴＵＳコマンドを定期的に、プロアクティブＳＩＭ ５５６に送信し（ステップ５６２）、それによりプロアクティブＳＩＭ ５５６がコマンドで応答することができるようにしているが、それはＭＥ ５５４が常にＳＩＭ ５５６にコマンドを開始する故である。

ＭＥ ５５４による電源投入後、送信される第１のメッセージはＳＴＡＴＵＳメッセージ（ステップ５６４）であり、これを使用して、ＳＩＭカードに常駐する適切なＢ２Ｂエンジン５５２クライアント・アプリケーションをトリガする（ステップ５６４）。クライアント・アプリケーションは、ＳＩＭ ５５６上の適切なファイルを読み取り、関連情報をショート・メッセージにパックし、ＭＥに送信するようＳＩＭに要求する（ステップ５７０）。ＳＩＭ ８５６は、他の情報が利用可能であることをＭＥ ５５４に通知するメッセージを送信する（ステップ５６６）。その後、ＭＥ ５５４は、ＦＥＴＣＨコマンドを使用して応答し（ステップ５６８）、ＳＩＭ ５５６から情報を取得する。ＳＩＭ ５５６は、前述のＦＥＴＣＨコマンド５６８を受信した後、作成されたショート・メッセージをクライアント・アプリケーションからＭＥ ５５４に送信し（ステップ５７０Ａ）、Ｂ２Ｂエンジンに情報を送信する。その後、ＭＥ ５５４は、ショート・メッセージをＢ２Ｂエンジンに送信し（ステップ５７２）、ＭＳ ５５４がオンになっていることを通知する。Ｂ２Ｂエンジン５５２では、このメッセージを受信し、解釈して、さらに、機能を強化したサービスを提供する。その後、ＭＥ ５５４は、ＳＩＭ ５５６に応答し、イベントに関するメッセージが送信されたことを通知する（ステップ５７４）。そして、ＳＩＭ ５５６は、応答に対し肯定応答し、通常の終了メッセージを送信する（ステップ５７６）。すると移動局はオンになり、ＭＥ ５５４、ＳＩＭ ５５６、及びクライアント・アプリケーション５５２などのすべての要素はそのイベントの発生を認識する。前述のように、ＭＥ ８５４は、定期的ステータス・コマンドをＳＩＭ８５６に送信し（ステップ５７８）、その後、ＭＥ ５５４はオンになり、ＳＩＭカード５５２上のクライアント・アプリケーション８５２にトリガが発生し（ステップ５８０）、そこから、定期的ＳＭＳメッセージ（ステップ５７８）を送信することが可能である。

そこで、図１３を参照すると、本発明の好ましい他の実施形態による、Ｂ２Ｂエンジン５５２へのＭＥ ５５４の位置エリア変更表示のタイミング図が例示されている。例示されているように、ＳＩＭ ５５６初期化及びプロアクティブＳＩＭの決定（ステップ５５８及び５６０）は、最初に、ここでもまた、好ましくはＧＳＭ１１．１１プロトコルに従って、実行される。当業ではよく知られているように、移動体機器５５４は、クライアント・アプリケーション及びＳＩＭにより、位置変更を監視するよう要求され、そのような変更があった場合、ＭＥ ５５４はその変更をＢ２Ｂエンジン５５２に通知する。上述のような位置情報は、ＧＰＳ情報、セル・グローバル・アイデンティティ情報、又は携帯電話加入者に関連する経路選択エリア情報とすることができる。さらに、移動体機器５５４は、ＵＳＳＤメッセージ又はＷＡＰなどの他のパケット・ベースのプロトコルを使用して通信することもできる。

上述のように、位置に変化があった場合、ＭＥ ５５４の適切な処理が呼び出される。ＭＥは、設定位置更新ステータス・メッセージ（ステップ５８６）をＳＩＭ ８５６に送信し、その後、エンベロープ・コマンド（ステップ５８８）を介して、ＳＩＭ内に常駐するクライアント・アプリケーションに、位置エリア更新が発生していることを通知する。クライアント・アプリケーションにトリガがかかり５８８Ａ、このデータをエンベロープ・コマンドから取り出し、ＳＩＭ ５５６から適切なデータを読み取って加え、ショート・メッセージをパックする。このパックされた（packed）ショート・メッセージは、図１３で示されているように、クライアント・アプリケーションによりＳＩＭ ５５６に送信され（ステップ５９０）、ステップ５９０Ａで、ＳＩＭはＭＥに、ショート・メッセージを送信する要求を通知する。ＭＥでは、ＦＥＴＣＨコマンド５９２を使用して、ＳＩＭに、５９３で実行するショート・メッセージのデータを供給するよう要求する。ＭＥは、パックされたショート・メッセージをＢ２Ｂエンジン（ステップ５９４）に送信し、エンジンではこのデータを使用して、機能強化されたサービスを提供する。ＭＥ ５５４は、その後、いつものように、ショート・メッセージが送信されたこと（ステップ５９６）をＳＩＭ ５５６に通知し、ＳＩＭ ５５６は通常の終了メッセージ（ステップ５９８）を返す。

更新された情報は、移動局によりＢ２Ｂエンジンに送信され、上述のように、Ｂ２Ｂエンジン内のステータス及びプリファレンスの更新が行われる。しかし、本発明の他の好ましい実施形態では、ネットワーク・ノードが所望の加入者イベント更新を自己監視し、自動的に、リアルタイムでデータをＢ２Ｂエンジンに供給する。

次に図１４を参照すると、Ｂ２Ｂエンジン２１０は、ポータル６４０又はコンテンツ・アグリゲータに接続されることに加えて、例えば、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）又は他のパケット・ベースの通信プロトコルを使用することにより、一般に図１４内の参照番号６００で示される、ネットワーク内のさまざまな他のノードにも接続される。本発明の好ましい実施形態を参照して説明されているように、これらのノードは、加入登録されているユーザに関するリアルタイム情報を収集するようにすることができることは理解されるであろう。これは、リアルタイム加入者イベント及び活動を監視し、受信した加入者イベントに関するリアルタイム情報をＢ２Ｂエンジンに供給するようにネットワーク・ノードをプログラムすることにより達成することが可能である。ネットワーク要素は、そのネットワーク・エリア内でサービスを受けているすべての加入者のすべての加入者イベント及び活動を監視し、転送するか、又はそれとは別に、ネットワーク要素は、Ｂ２Ｂエンジンに加入登録されている加入者の加入者イベント及び活動を監視し、転送することができる。Ｂ２Ｂエンジン２１０は、ネットワーク６００内のネットワーク・ノードとインターフェースし、それらのノードから加入登録されているイベントに関する情報を受け取る。移動通信交換局（ＭＳＣ）／ビジター位置登録（ＶＬＲ）６１５は、モビリティ情報、ＶＬＲレコード、及び関連するイベントの呼制御を、例えば、メッセージＴＣＰ／ＩＰなどのプロトコルを使用して、加入者に送信する。リアルタイム情報の送信は、位置更新又は登録信号を加入登録ユーザから受信するとトリガがかかる。

さらに、システム６００の無線ネットワーク・サブシステム（ＲＮＳ）６２０からのハンドオーバ・トリガ及び無線関係トリガ・イベントがＢ２Ｂエンジンに送信される。当業者であれば理解するであろうが、サービング汎用パケット無線システム（ＧＰＲＳ）サービス・ノード（ＳＧＳＮ）６２５は、例えば、汎用パケット無線システム（ＧＰＲＳ）などのパケット・ドメイン・ネットワークに関係するような、Ｂ２Ｂエンジン２１０にモビリティ及び呼制御関係情報を供給する。

移動体位置決定センター（ＭＰＣ）６３０は、Ｂ２Ｂエンジン２１０に、通信ネットワーク内の携帯電話加入者の位置に関する情報を供給する。当業者であれば、ＭＰＣ ６３０は、グローバル・ポジショニング・サービス（ＧＰＳ）又は例えば、ＴＣＰ／ＩＰプロトコルを使用して位置決定情報を転送することにより携帯電話加入者局を特定する他の手段により実現することができることが理解されよう。中央サービス制御機能（ＣＳＣＦ）６３５ユニットは、Ｂ２Ｂエンジン２１０に、加入者のアドレス番号をインターネット・プロトコル（ＩＰ）アドレスに変換した結果を供給し、さらに、例えば、メッセージ及びＴＣＰ／ＩＰプロトコルを使用して、制御関係イベント／情報を供給することも可能である。

また、通信分野の当業者であれば、移動局（ＭＳ）上での交換の後、サービングＭＳＣ／ＶＬＲ（移動通信交換局／ビジター位置登録）は、ＭＳに関連するホーム位置登録（ＨＬＲ）と通信することにより、ＭＳを登録し、ＭＳを許可することを理解するであろう。次に、ＨＬＲは、後述の好ましい実施形態に示されているように、この登録及び許可の後、好ましい情報を移動局に転送するようにＢ２Ｂエンジンに通知する。

ネットワーク・ノードは、加入登録されているユーザに関係する情報を認識するようにインテリジェント型機能でプログラムされ、イベントのトリガが発生すると、リアルタイム情報をＢ２Ｂエンジンに送信して、エンド・ユーザ・ステータスの更新を通知する。この情報は、Ｂ２Ｂエンジン・データベース内に格納される。Ｂ２Ｂエンジン２１０は、ノードにより送信された情報／イベントを処理し、このフォーマットされた情報をポータル６４０に転送する。Ｂ２Ｂエンジン２１０により情報／イベントをポータル３４０に供給した後、ポータル６４０に対し、例えば、ビリング・ゲートウェイ（ＢＧＷ）６４５により、このリアルタイム情報の請求を行う。ＢＧＷ ６４５は、提供されるリアルタイム情報のポータルの代金請求の時期及び請求額に関する情報を提供する。これは、関連情報を各ユーザ要求アクションに対する課金レコードに記録することにより行われる。ビリングは、図７に示されているように、課金モジュールを使用してＢ２Ｂエンジン内で内部的に実行されるか、又は図１４に示されているように、ＢＧＷなどのＢ２Ｂエンジンに接続されている外部アプリケーションとすることが可能である。また、ＢＧＷは、ユーザ毎に移動体事業者のビリングを担当するか、又は例えば、ネットワークにアクセスする加入者に対する残っている収支又は加入者使用の収支に関する情報を提供することが可能である。ＢＧＷ機能は、各加入登録ユーザのサービス及びプランに応じて、多数あり、また柔軟である。

上述の好ましい実施形態では、ネットワーク・ノードは、イベントをＢ２Ｂエンジンに報告することを望んでいるネットワーク・ノードのそれぞれでプログラムされているクライアント・アプリケーション（ＣＬ）／監視エージェント（ＭＡ）を含むのが好ましい。これらのネットワーク・ノードは、ユーザに関係するいくつかのトリガを監視し、それらをＢ２Ｂエンジンに報告する。ＨＬＲ及び／又はＭＳＣ／ＶＬＲなどのいくつかのネットワーク・ノードへのクライアント・アプリケーション・プログラムのロードを使用して、加入者の行動、ステータス、モビリティ・パラメータなどに関係するいくつかの使用可能になっているトリガを監視することが可能である。ユーザ・ステータス又はプリファレンスに変更があった場合に、Ｂ２Ｂエンジンに情報を供給するネットワーク・ノードの一実施形態を以下に示す。ユーザ・ステータスの更新又はデータベース内のユーザに関する変更があった場合、ＨＬＲクライアント・アプリケーションはトリガされ、Ｂ２Ｂエンジンに更新を送信し、そのような変更のあることをエンジンに通知する。ＨＬＲ内のこのクライアント・アプリケーションは、変更を認識し、自動的にこの変更をＢ２Ｂエンジンに報告するようにされる。すべてのネットワーク・ノードは、さらに、クライアント・アプリケーションのトリガ・メカニズムを使用して、イベントを認識し、このイベントをＢ２Ｂエンジンに通知するようにプログラムされる。例えば、ＭＳＣ／ＶＬＲは、ユーザのモビリティを追跡し、変更が検出された場合、例えば、ユーザの位置が変更されると、ＭＳＣ／ＶＬＲクライアント・アプリケーションにトリガがかかり、Ｂ２Ｂエンジンにこの変更が通知される。さらに、ＭＳＣは、ＭＰＣと連携動作をして、ユーザの位置をピンポイントで特定し、情報をＢ２Ｂエンジンに送る。さらに、ＭＳＣ／ＶＬＲクライアント・アプリケーションは、ＲＮＳと相互作用し、ユーザに関係するハンドオーバ又は無線トリガが発生したことをＢ２Ｂエンジンに通知するようにプログラムされる。また、ＲＮＳは、更新プロセスにおける関係するすべてのネットワーク・ノードとしてクライアント・アプリケーションを含む。

図１５は、加入者ステータス及び位置の変化をネットワーク・ノードにより通知する他の例を例示している。ＶＬＲ ６５２は、加入者ステータス及び位置の変更があった場合、標準の既存のプロトコル、例えば、ＭＡＰ ６５８を使用して、そのような変更のあることをＨＬＲ ６５４に通知する。ステータス変更の判別は、ＶＬＲ ６５２とＨＬＲ ６５４の両方の内部の監視エージェント（ＭＡ）６５６を使用して実行される。ＨＬＲ ６５４は、次に、このような状況ではＶＬＲ ６４４として動作しているＢ２Ｂエンジン６６０と相互作用する。Ｂ２Ｂエンジン６６０は、この場合、ＧＳＭサービス制御機能（ｇｓｍＳＣＦ）６６２ノードであり、ＨＬＲ ６５４から加入者ステータス及び位置情報を取得し、それをデータベースに格納する。次に、Ｂ２Ｂエンジンは、この情報に対して必要なオペレーションを実行し、その結果に応じて動作する。一般に、クライアント・アプリケーションが加入者ステータスの変更を表すネットワーク・ノード（つまり、ＨＬＲ、ＭＳＣ／ＶＬＲなど）内のトリガ・イベントをキャッチすると、ネットワーク・ノード内のクライアント・アプリケーションはＢ２Ｂエンジンに通知する。

さらに図１４を参照すると、Ｂ２Ｂエンジン２１０は、上で説明したように、この情報を要求せずに、ネットワーク・ノードから加入登録されているユーザに関する情報／イベントを受信することも可能である。しかし、本発明の他の好ましい実施形態では、さらに図１４を参照すると、これらのネットワーク・ノードは、加入登録されているユーザに関するリアルタイム情報を収集するよう要求される。加入登録イベントがＢ２Ｂエンジン２１０データベースに格納されている場合、例えば、移動体アプリケーション部（ＭＡＰ）、ＴＣＰ／ＩＰ、又は類似のプロトコルを使用することにより、ホーム位置登録（ＨＬＲ）６１０をボーリングして、携帯電話加入者の登録情報を調べる。

Ｂ２Ｂエンジン２１０は、ネットワーク６００内の通信ノードとインターフェースし、それらのノードから加入登録されているイベントに関する情報を要求する。Ｂ２Ｂエンジン２１０は、例えば、メッセージＴＣＰ／ＩＰ又は類似のプロトコルを使用して、移動通信交換局（ＭＳＣ）／ビジター位置登録（ＶＬＲ）６１５をポーリングし、モビリティ情報、ＶＬＲレコード、及び加入者への関連するイベントの呼制御を要求する。

Ｂ２Ｂエンジン２１０は、システム６００の無線ネットワーク・サブシステム（ＲＮＳ）３２０にハンドオーバ・トリガ及び無線関係トリガ・イベントを要求する。移動体位置決定センター（ＭＰＣ）３３０をポーリングし、Ｂ２Ｂエンジン２１０に、通信ネットワーク内の携帯電話加入者の位置に関する情報を供給することが可能である。当業者であれば、上述のように、ＭＰＣ ６３０を携帯電話加入者局を特定する他の手段とすることも可能であることを理解するであろう。中央サービス制御機能（ＣＳＣＦ）６３５ユニットをポーリングして、Ｂ２Ｂエンジン２１０に、加入者のアドレス番号をインターネット・プロトコル（ＩＰ）アドレスに変換した結果を供給し、さらに、例えば、メッセージ及びＴＣＰ／ＩＰプロトコルを使用して、制御関係イベント／情報を供給することも可能である。

Ｂ２Ｂエンジン２１０は、例えば、ＴＣＰ／ＩＰプロトコルを使用して、ポーリングしポータル６４０に提供する必要な情報を収集するための前述の要素又はノードを知るインテリジェント型機能を備える。情報は、通信デバイスのステータスを判別する際にＢ２Ｂエンジンの要求条件に応じて選択的に要求することも可能である。Ｂ２Ｂエンジン２１０は、ノードにより送信された情報／イベントを処理し、この収集された情報をポータル６４０に送信する。Ｂ２Ｂエンジン２１０により情報／イベントをポータル６４０に供給した後、前の実施形態を参照しながら上で説明したようにこのリアルタイム情報の請求が行われる。

例えば、Ｂ２ＢエンジンがＨＬＲからの加入者のステータスなどの特定の情報を必要とする場合、メッセージがＨＬＲに送信され、その情報を要求する。次に、ＨＬＲは、現在の加入者ステータスをＢ２Ｂエンジンに知らせる応答メッセージで応答する。この同じ要求メカニズムを他のネットワーク・ノードでも使用することができる。メッセージは、Ｂ２Ｂエンジンにより加入者に関する情報を要求するネットワーク・ノードに送信することができる。そのようなメッセージを受信した後、ネットワーク・ノードは、情報を取得してＢ２Ｂエンジンに送信する。Ｂ２Ｂエンジンは、ＧＳＭサービス制御機能（ｇｓｍＳＣＦ）ノードとして機能し、ＨＬＲに定期的に又は周期的間隔でＨＬＲに問い合わせを行い、加入者のステータス及び位置情報を取得する。

Ｂ２Ｂエンジン２１０が稼働するネットワーク環境は、上で完全に説明されている。一般に、Ｂｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓエンジンによって提供されるサービスには多数の実装がある。しかし、図１６を参照すると、本発明のＢ２Ｂエンジン２１０の他のオペレーションが例示されている。この他の構成では、Ｂ２Ｂエンジン２１０は、例えば、ショート・メッセージ・サービス（ＳＭＳ）メッセージを使用して、図９〜１３を参照して説明されているように、携帯電話加入者６６０から、加入者ステータス、位置エリア、及びその他のイベントなどのリアルタイム・イベントを受信する。Ｂ２Ｂエンジン２１０は、好ましい実施形態を参照して上で説明したように、ネットワーク内の異なるノードをポーリングすることにより、他の情報のほかに、この情報を取得する。しかし、ネットワーク・ノードは、上で説明されている好ましい他の実施形態で説明されているように、加入者に関する変更が生じた場合に必ず、ユーザの更新されたステータス情報をＢ２Ｂエンジンに送信する。Ｂ２Ｂエンジン２１０は、さらに、加入登録されているユーザ・プリファレンスに基づいてイベントを解析し、収集した情報／イベントを処理する。

これらの処理されたイベントは、次に、例えば、ＨＴＴＰプロトコルを使用して、ポータル／コンテンツ・アグリゲータ／コンテンツ・プロバイダ６４０に送信される。次に、ポータル６４０は、Ｂ２Ｂエンジン２１０により提供されるイベント情報に応じてコンテンツを個人化する。ポータルは、コンテンツを、例えば移動局、ＰＤＡなどの狭帯域デバイスにコンテンツを要求するために使用される無線マークアップ言語（ＷＭＬ）に変換する。個人化されたコンテンツを含むＷＭＬは、ワイヤレス・アプリケーション・プロトコル・ゲートウェイ（ＷＡＰＧＷ）を介して携帯電話経由で加入登録ユーザに配信される。しかし、ポータルは、さらに、ＳＭＳメッセージ又は他の専用ワイヤレス・データ・プロトコルを使用して個人化されたコンテンツを配信することもできる。図１６に例示されているように、コンテンツは、ワイヤレス・アプリケーション・プロトコル・ゲートウェイ（ＷＡＰＧＷ）を通じて移動局に送信することが可能である。ＷＡＰＧＷは、移動体ネットワークとポータルなどの専用インターネット・アプリケーション・サービスとの間の直接的接続を行うネットワーク・ノードである。コンテンツを加入者に送信するのに使用することが可能な方法は多数存在する。例えば、ショート・メッセージ（ＳＭＳ）又はＳＭＳメッセージ上で送信されるＷＡＰを使用してショート・メッセージ・サービス・センター（ＳＭＳＣ）を経由してコンテンツを送信することが可能である。さらに、移動局に送信されるコンテンツは、未構造化補助サービス・データ（ＵＳＳＤ：Unstructured Supplementary Service Data）とすることも可能である。これは、ポータルから情報を取り出して、ＳＭＳＣに送信し、ショート・メッセージとして配信するＵＳＳＤゲートウェイを使用して実行することが可能である。ＧＰＲＳなどの他のトランスポート・ベアラも、ポータルから移動局にコンテンツを送信するために使用することが可能である。今日の移動体技術におけるシステムのアクセス高速化に向かう進歩は、第三世代（３Ｇ）無線システムへの道を切り開く。汎用パケット無線サービス（ＧＰＲＳ）及びＥｖｏｌｖｅｄ Ｄａｔａ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）などのデータ・パケット・トランスポート・システムは、コンテンツを容易にかつ迅速に配信することができる高速接続を実現する。これらのトランスポート・ベアラを念頭に置き、移動局、Ｂ２Ｂエンジン、及びインターネット・ポータルの間のすべての通信は、本明細書で説明したこれらのトランスポート・ベアラを使用して実行することが可能である。例えば、上で説明したように、ＳＭＳＣを介して移動局によりＳＭＳメッセージを送信する代わりに、移動局は、高速アクセスを利用するデータ・パケットを送信することによりＧＰＲＳネットワークを使用するＢ２Ｂと通信することが可能である。

図１７を参照すると、Ｂ２Ｂエンジン２１０は、さらに、ポータル６４０又はコンテンツ・アグリゲータに接続されることに加えて、例えば、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）を使用することにより、ネットワーク内のさまざまな他のノードにも接続される。一般に、これらのネットワーク・ノードは、通常、加入登録ユーザに関するリアルタイム情報を収集するために使用されることを理解されたい。ネットワーク内のノードは、標準プロトコルを使用して互いに通信する。これらのプロトコルは、ネットワーク・ノード間の通信手段を簡単にし、必須の標準と互換性を持つようにするために使用される。さらに図１７を参照すると、ネットワーク・ノードと前述のＢ２Ｂエンジン２１０との間の通信で使用されるプロトコルの好ましい実施形態が例示されている。Ｂ２Ｂエンジン２１０は、例えば、標準ＩＥＥＥ８０２．３接続を使用して、イベント情報を供給するネットワーク内のすべてのノードとインターフェースされるのが好ましいことを理解されたい。

ノード間の通信は、レイヤ化構造を使用して、他の通信標準と同様に、実行される。例えば、採用されるすべてのプロトコルは、その下位レイヤにおいて伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）を使用する。しかし、上位レイヤでは、各ノードは異なるプロトコルを使用する。例えば、Ｂ２Ｂエンジン２１０は、インターネット通信で一般的に使用されるハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用してポータル６４０と通信する。ＨＬＲ ６１０では、ＭＡＰプロトコルを使用する。移動体位置決定センター（ＭＰＣ）６３０では、ＭＰＣプロトコルを使用するのが好ましい。ショート・メッセージング・サービス・センター（ＳＭＳＣ）６５０は、ショート・メッセージ・ピアツーピア（ＳＭＰＰ）プロトコルを使用するのが好ましい。使用される特定のプロトコルは、当業でよく知られており、ネットワーク内の異なるノード間の相互接続を行う手段となる。しかし、さまざまな他のプロトコルを使用してノード間通信をサポートすることも可能であることは理解されるであろう。

図１８を参照すると、これは、異なるネットワーク・アーキテクチャとインターフェースするＢ２Ｂエンジンを例示している。Ｂ２Ｂエンジンは、この図及び前の図１４に示されているように、２．５Ｇ無線通信システム７１０とインターフェースしている。しかし、Ｂ２Ｂエンジンは、第二世代（２Ｇ）無線通信事業者システム７３０などの他のシステムとインターフェースすることが可能である。また、これは、現在開発中の３Ｇ無線通信システム７５０とも相互接続することができる。Ｂ２Ｂエンジンに接続されるシステム・アーキテクチャは異なるが、上で説明したように、同じプロシージャをシステム内のそれぞれのネットワーク・ノードとともに使用することが可能である。例えば、Ｂ２Ｂエンジンは、３Ｇ無線通信システム７５０内のネットワーク・ノードのそれぞれをポーリングするか、又はネットワーク・ノードが加入者ステータスの更新に関するイベントをＢ２Ｂエンジン２１０に報告することが可能である。本発明で説明しているエンジンは、多くのシステムで使用することが可能であり、２．５Ｇ無線通信システムについて上で説明したのと同じプロシージャを、他のシステムとともに、３Ｇ無線システムも適用することが可能である。３Ｇ無線システム内のネットワーク・ノードは、呼制御ネットワーク・ノード７６０、７７０、７８０、及び接続性制御ネットワーク・ノード７９０において分離されている。メディア・ゲートウェイ（ＭＧＷ）７９２は、すべての接続手段を受け持つが、制御レイヤ内のサーバは呼制御を実行する。次に、制御レイヤは、図に示されていないが、アプリケーション・ゲートウェイとインターフェースし、特定の固定又は移動ベアラ技術からサービスを今までに例のないレベルで分離することができ、いつでも、どこでも、どのようにしてでもサービス配信が可能である。Ｂ２Ｂエンジンは、ＧＳＭ／ＥＤＧＥ、ＷＣＤＭＡ、及びｃｄｍａ２０００などの異なるベアラ技術に接続することができる。Ｂ２Ｂエンジンは、さらに、携帯電話加入者を追跡し、且つ／又は記録するすべての接続及び制御ネットワーク・ノードともインターフェースする。ネットワーク・ノードは、しかしながら、図１４及び１５を参照して上で説明しているように、モビリティ・エージェントを含むように再プログラムすることが好ましい。

また、上で説明した移動体事業者はＧＳＭ事業者であり、当業者であれば、本発明は、ＰＣＳ事業者、ＤＡＭＰＳ事業者、又は／及び任意の既存の移動体事業者で使用可能であることを理解するであろう。さらに、単一のＢ２Ｂエンジンは、さまざまな移動体事業者をさまざまなポータルに相互接続することが可能である。移動体事業者にはさまざまな特質がありえ、異なる標準を使用することにより、例えばＢ２Ｂエンジンは、ＰＣＳ事業者とともにＧＳＭ事業者にも同時にサービスを提供することが可能である。

さらに、３Ｇ移動局は、ユーザ・ステータスの更新をＢ２Ｂエンジンに通知するクライアント・アプリケーションを備えるが、ＧＳＭネットワーク内のＳＩＭカードにプログラムされているクライアント・アプリケーションを備えるＧＳＭ電話機に関してすでに述べているものと類似している。上述のようなＳＩＭカードは、移動体機器がアプリケーションを格納することができるプログラム可能なモジュールを備えることが可能な任意の手段とすることが可能である。上述のＳＩＭカードは、さらに、移動局内の固定モジュールを移動体機器（ＭＥ）の一部とするような、いくつかの機能を格納し実行することができるプログラム可能な手段とすることも可能である。

しかし、当業者であれば、本明細書で説明しているように、ポータル及びコンテンツ・アグリゲータはＢ２Ｂエンジンに外部接続されることを理解するであろう。しかし、請求されている本発明の好ましい実施形態では、ポータル及び／又はコンテンツ・アグリゲータは、Ｂ２Ｂエンジン内にも組み込むことができる。つまり、Ｂ２Ｂエンジンはデータ・コンテンツを収集し、データ・コンテンツを選択的にユーザに供給することを担当することが可能であることを意味する。

当業者であれば、本明細書の実施形態を参照して説明されているリアルタイム情報及びリアルタイム・ネットワークが、遅延を無視し、且つ／又はネットワーク・ノード及び他の機器内で処理するそのようなネットワーク及び情報の理想的タイミングを表すことを理解するであろう。一般に、リアルタイム・ネットワークは、リアルタイム又はリアルタイムに近い速度で機能する任意のネットワークでよい。また、リアルタイム情報は、実質的にリアルタイム又はリアルタイムに近い情報とすることもできる。

図１９は、本発明の教示による、位置に基づく予約システム内の相互接続されたレストラン・アプリケーション・モジュールを使用するＢ２Ｂエンジンの高水準ブロック図である。すでに説明したように、当業者であれば理解するであろうが、市場には位置に基づく予約アプリケーションが出回っている。これらのアプリケーションは、位置に基づく自動化されたレストラン検索を実行する。しかし、予約プロセスは、検索により見つかったレストランを顧客が呼び出すことによりそのまま完了し、レストラン職員は手動で、レストランのテーブル管理システムに予約を入力する。対照的に、本発明では、本発明により実現される予約サービスが予約状況をチェックし、予約を記憶し、予約を定期的に顧客のＥＴＡで更新し、検索が利用可能になったときに顧客に通知するプロセス全体を自動化する。

Ｂ２Ｂエンジン１９００は、Ｂ２Ｂエンジン２１０が図３で説明されているようにコンテンツ・プロバイダにより提供されるさまざまなモジュールに結合されるのと同じようにしてレストラン・モジュール１９０５に結合される。レストラン・モジュール１９０５は、Ｂ２Ｂエンジン１９００を介して移動体位置決定センター１９２０に対するネットワーク内のサーバ上に実装することが可能である。データベース１９１０を利用して、携帯電話加入者局（ＭＳ）１９２５及びメンバ１９４０、１９４５、及び１９５０からＢ２Ｂエンジン１９００に受信されたデータ（要求、ビリング情報など）を格納することができる。本発明のオペレーションは、示されているメンバのそれぞれについて本質的に同じである。本発明の原理の説明を簡素化し、分かりやすくするために、メンバ（レストラン）１９４０を備えるオペレーションのみについて説明されることに注意されたい。当業者であれば、本発明のオペレーションは、医者、歯医者、劇場などの予約を利用する他のメンバについて同じであることを理解するであろう。

本発明では、予約管理会社は、メンバ企業との契約を履行し、メンバのコンピュータ・システム上にインストールする予約プログラム・アプリケーションを提供する。さらに、管理会社では、インストールし、Ｂ２Ｂエンジン１９００との相互接続を行うレストラン・モジュール１９０５を提供する。予約アプリケーション（図に示されていない）は、レストラン予約情報を含むメンバのコンピュータ・システム（図に示されていない）内のデータベースへの読み込み／書き出しアクセスを行う。ＭＳ １９２５とＢ２Ｂエンジン１９００との間の通信を実行する、クライアント・モジュール１９３０は、無線事業者を介して管理会社により関係者に提供される。クライアント・モジュール１９３０は、ＭＳ １９２５上にインストールされ、レストラン・モジュール１９０５と接続する。

本発明のオペレーションで、レストラン・モジュール１９０５は、Ｂ２Ｂエンジン１９００及びレストラン１９４０のコンピュータ・システムに接続されているデータベースから情報を受け取る。本発明の実施形態では、Ｂ２Ｂエンジン１９００は、最も早いうちに空いている席のある最寄りの中華レストランについて、ＭＳＣ／ＶＬＲ １９１５を介して、ＭＳ １９２５から、情報要求を受信することができる。Ｂ２Ｂエンジン１９００は、その要求をレストラン・モジュール１９０５に送信し、その後、ＭＳ １９２５の現在位置に関する要求をＢ２Ｂエンジン１９００に送信する。

Ｂ２Ｂエンジン１９００は、Ｂ２Ｂエンジン１９００を介して、移動体位置決定センター（ＭＰＣ）１９２０にＭＳ １９２５の現在位置データを要求し、そこから受信する。ＭＰＣ １９２０では、本明細書ですでに説明した方法に従ってＭＳ １９２５の現在位置を判別する。その後、ＭＳ １９２５の位置を、予約管理会社との契約を締結しているメンバのデータベース１９１０に格納されているプロファイルと比較する。メンバのプロファイルには、位置情報、レストランの種類、メニュー、時間数などを含めることができる。

レストラン・モジュール１９０５では、次に、インターネット１９３５を介して、Ｂ２Ｂエンジン１９００を使用しレストラン１９４０のコンピュータ・システムに常駐している予約アプリケーションにアクセスする（それとは別に、モジュール１９０５は有線又は無線伝送を介して直接にアクセスすることができる）。レストラン・モジュール１９０５は、加入者（本明細書では顧客とも呼ばれる）要件と一致する利用可能なレストラン・テーブルに関係するレストラン・データベースから情報を取り出す。さらに、レストラン・モジュール１９０５は、まもなく利用可能になることをレストランにより予定されているテーブルに関連する情報を取り出すように設定することができる。次に、レストラン・モジュール１９０５は、Ｂ２Ｂエンジン１９００からＭＳ １９２５に情報を伝送する。

Ｂ２Ｂエンジン１９００から予約情報を受信した後、加入者はレストランを選択し、Ｂ２Ｂエンジン１９００への選択を確認し、その後、その情報をレストラン・モジュール１９０５に転送する。レストラン・モジュール１９０５は、その後、Ｂ２Ｂエンジン１９００を介してレストラン１９４０のコンピュータ・システム上の予約アプリケーションにアクセスする。その後、予約の確認が予約アプリケーションによりアクセス可能なデータベースに書き込まれる。

その後、レストラン・モジュール１９０５は、定期的に、ＭＰＣ １９２０をトリガし、レストラン１９４０の加入者の予約確認から到着までの間に、ＭＳ １９２５の位置を決定する。レストラン１９４０のＭＳ １９２５の到着時間は、ＭＰＣ １９２０により与えられた現在の位置とレストラン１９４０との間の距離を計算することにより推定される。この情報は推定到着時間（ＥＴＡ）であり、その後、レストラン１９４０のコンピュータ予約システムに送信され、ＭＳ １９２５の確認済み予約が更新される。

クライアント・モジュール１９３０は、ＭＳ １９２５上に常駐しており、また、ＭＳ １９２５の定期的位置更新の予約を自動的に生成することもできる。予約が確認された後、クライアント・モジュール１９３０は、レストラン・モジュール１９０５の代わりに、ＭＰＣ １９２０への位置更新要求を生成することができる。この定期的更新要求は、例えば、レストラン・モジュール１９０５で生成されたトリガ、ＭＳ １９２５若しくはモジュール１９３０に格納されているプログラム、又は予約アプリケーションにより送信されたトリガでさえも、開始できる。ＭＳ １９２５の位置が決定され、レストラン１９４０のＭＳ １９２５のＥＴＡが計算される。次に、Ｂ２Ｂエンジン１９００は、ＥＴＡをレストラン１９４０の予約アプリケーションに伝送することができる。

図２０は、本発明の実施形態により、Ｂ２Ｂエンジン１９００、レストラン・モジュール１９０５、及びレストラン・コンピュータ・システムの予約アプリケーションの間の通信の流れを示すブロック図である。図１９で説明されているように、Ｂ２Ｂエンジン１９２５は、レストラン・モジュール１９０５及びＭＰＣ １９２０と相互作用し、レストラン１９４０の位置でＭＳ １９２５のＥＴＡを供給する。すでに述べたように、クライアント・モジュールＭＳ １９３０は、ＭＳ １９２５上に常駐しており、レストラン１９４０の予約アプリケーションのＥＴＡ更新をトリガとなることができる。予約アプリケーション２００５は、予約管理会社により、メンバ・レストラン１９４０に提供され、レストラン・コンピュータ・システム２０００にインストールされる。レストラン管理会社は、さらに、Ｂ２Ｂエンジン１９００に接続されているレストラン・モジュール１９０５を稼働させる。予約アプリケーション２００５及びレストラン・モジュール１９０５は、インターネット１９３５及びＢ２Ｂエンジン１９００を介して互いに通信する。

ＭＳ １９２５がメッセージを送信し、例えば４人席のレストラン予約要求を出す場合、レストラン・モジュール１９０５により、Ｂ２Ｂエンジン１９００は接続されているデータベースをチェックし、加入者に近いところにある公認レストランを決定する。次に、Ｂ２Ｂエンジン１９００は、予約情報の要求を適切なレストランに転送する。レストラン１９４０の場合、Ｂ２Ｂエンジン１９００はその要求を、レストラン・コンピュータ・システム２０００内に常駐する、予約アプリケーション２００５に送信する。予約アプリケーション２００５は、レストラン・コンピュータ・システム２０００に接続されている、予約データベース２０１５に問い合わせを実行し、レストランのテーブルのステータスを判別する。予約アプリケーション２００５は、テーブルに関する関連情報を蓄積し、要求に当てはまるテーブルを一時的に予約し、その後、その情報をＢ２Ｂエンジン１９４０に送信し、その後加入者に送信する。加入者が返信の内容に同意し、予約を確認すると仮定すると、予約はレストラン・コンピュータ・システム２０００内で確認済みステータスに更新される。予約データベース２０１２は、予約アプリケーション２００５により、加入者の名前を一時的予約テーブルにリンクすることで、更新することができる（加入者の名前をＢ２Ｂエンジン・データベース内のＭＳ １９２５と関連する加入者プロファイルから取り出せるため加入者が名前を送信する必要はない）。予約アプリケーション２００５は、テーブルが利用可能になる時間を推定し（現在占有されている場合、そうでなければ、予約アプリケーションはテーブルを予約する）、加入者の予想ＥＴＡをデータベース２０１５に入力し、表示装置２０１０に表示する。

すでに説明したように、Ｂ２Ｂエンジン１９００は、ＭＰＣ １９２０に位置情報に関するクエリー（query）を実行し、そこから位置情報を受信し、加入者及びレストラン位置情報をレストラン・モジュール１９０５に供給する。インターネットは無線及び有線デバイスによりアクセス可能であり、Ｂ２Ｂエンジン１９００とレストラン１９４０との間の伝送は、有線、無線、又はその組み合わせのいずれかにより、実施できることが当技術分野では周知である。その後、モジュール１９０５は、レストランで加入者の初期ＥＴＡを計算し、インターネット１９３５を介してＥＴＡを予約アプリケーション２００５に伝送する。その後、予約アプリケーション２００５は、初期ＥＴＡをデータベースに入力し、表示装置２０１０は更新され、加入者の確認済み予約及び到着時間が反映される。

テーブルの準備が整ったら、レストラン職員は、レストラン・コンピュータ・システムにその情報を入力し、予約アプリケーション２００５はその後、テーブルの準備が整ったことを加入者に通知することができる。その後、予約アプリケーション２００５は、初期確認時間と予約アプリケーション・モジュール１９０５により最初に計算された加入者のＥＴＡの間で定期的にＢ２Ｂエンジン１９００にクエリーを実行する。加入者のＥＴＡは、クエリー毎に計算することができ、最後のＥＴＡと異なる場合、予約アプリケーション２００５は表示されているＥＴＡを更新することができる。それとは別に、図１９に示され説明されているように、クライアント・モジュールは、Ｂ２Ｂエンジン１９００への定期的位置更新を自動的に生成することができ、Ｂ２ＢエンジンはＥＴＡ情報を伝送し、現在のＥＴＡを予約アプリケーション２００５に供給する。

加入者に予約されているテーブルが空でなく、加入者が席を取るのに間に合わない可能性がある。その後、そのテーブルに割り当てられているウェイターは、修正された予想空き席時間を入力することができる。予約アプリケーション２００５は、システム上で加入者の要求と一致するテーブルを自動的にスキャンし、加入者が予約を再度割り当てるのに間に合う代替えが利用可能かどうかを調べる。テーブルが空いていなければ、予約アプリケーション２００５は、メッセージを加入者に送信し、テーブルが利用可能になる新しい時間を知らせる。さらに、レストラン側は、加入者が修正された予約を受け入れることを奨励する所定のインセンティブを用意することもできる、つまり、レストラン側は、テーブルが定刻に利用できない状態にある場合に、到着したときに、無料ドリンクのクーポンを含めることができる。このクーポンは、データベース２０１５内の加入者の予約にリンクすることができる。加入者が到着し、テーブルが利用できる状態にない場合、レストラン職員は、クーポンについてデータベース２０１５にアクセスして、無料ドリンクを加入者に提供することができる。

図２１は、本発明により、Ｂｕｓｉｎｅｓｓ Ｔｏ Ｂｕｓｉｎｅｓｓ（Ｂ２Ｂ）エンジン及びリアルタイム情報相互交換を使用して位置に基づく予約システムにより予約を管理する方法を例示する。本発明によれば、位置に基づく予約システムは、Ｂ２Ｂエンジン、加入者ＭＳ上のクライアント・モジュール、及びメンバ・レストラン・コンピュータ・システムにインストールされている予約アプリケーションと相互接続されているレストラン・モジュールを含む。無線システム事業者は、加入者の移動局（ＭＳ）内にインストールするクライアント・モジュールを提供する。クライアント・モジュールは、レストラン・モジュールへの通信アクセスを行えるようにする。

レストラン・モジュールを運営、管理する予約管理会社は、レストランと会員契約を交わし、予約アプリケーション・ソフトウェアをレストランに提供する。レストランに提供される予約アプリケーション・ソフトウェアは、レストランの所有する予約管理システムに統合することができる。管理会社は、レストラン・モジュール及びＢ２Ｂエンジンとの相互接続を実現し、Ｂ２Ｂエンジンに接続されているデータベースへの管理会社による読み込み／書き出しアクセスを可能にする。管理会社によって提供される、メンバ（レストラン）に関する情報は、データベースに格納することができる。次に、レストラン・モジュールは、すでに説明されているアプリケーション・モジュールと類似の方法でＢ２Ｂエンジンと相互作用する。

このプロセスは、無線加入者が加入者のＭＳを介してＢ２Ｂエンジンに問い合わせを送信することにより位置に基づく予約システムと通信すると開始する（無線加入者はすでに事業者に登録し、レストラン予約システムに参加している）。問い合わせは、例えば、最寄りの中華レストランの４人席の予約又は最短待ち時間の最寄りの中華レストランの４人席の予約の要求を含むことができる（プロセス・ステップ２１００）。

レストラン・モジュールは、通信（テキスト・メッセージ、音声）を受信し、Ｂ２Ｂエンジンに、ＭＰＣ １９２０などの移動体位置決定センター（ＭＰＣ）への信号送出を行わせて、移動局の位置を判別する。すでに説明したように、加入者のＭＳ、例えば加入者アイデンティティ・モジュール（ＳＩＭ）のメモリ内に格納されている情報から移動局の位置を判別することを含む移動局の位置を判別する方法が多数ある（プロセス・ステップ２１０５）。

Ｂ２Ｂエンジンは、最寄りの中華レストランに対する要求及び予約の要求を含むレストラン・モジュールへのクエリー内のＭＳの位置情報を利用する。次に、レストラン・モジュールは、レストラン・メンバ・プロファイルを含むＢ２Ｂエンジンに接続されているデータベースを検索し、予約の余地のある現在の加入者のＭＳ位置近くにある中華レストランを決定する（プロセス・ステップ２１１０）。メンバ・レストラン・プロファイルは、さらに、レストランの決定を支援する、加入者からアクセスできる住所、電話番号、メニュー、食品種別、価格設定などを含むこともできる。その後、レストラン・モジュールは、有線、無線、又はインターネット接続を介してレストランのコンピュータ・システムに常駐している各レストランの予約アプリケーションと通信する。

レストラン・モジュールは、ＭＳの現在位置に最も近いレストランの位置及びパーティ・サイズ（つまり、４人）と一致する各レストランの予約空き状況を判別する。テーブルの推定待ち時間などの追加情報も含め、加入者の選択肢を広げることもできる。レストラン・モジュールを使用し、Ｂ２Ｂエンジンは、一定範囲のレストラン選択肢を与えるため空き状況及び待ち時間をチェックする。Ｂ２Ｂエンジンは、ショート・メッセージ・サービス（ＳＭＳ）又は他の類似のテキスト・ベースのメッセージ送受信（若しくは音声メッセージ送受信）を使用し、加入者の名前でレストラン・データベースに一時的予約を入れ、各レストランでの待ち時間を含む位置及び予約情報を加入者のＭＳに送信する（プロセス・ステップ２１１５）。

加入者は、レストラン・モジュールにより提供される選択肢を検討した後、レストランの選択を決定し、Ｂ２Ｂエンジンに送信する。加入者は、すぐ席を利用できるレストランを選択することを決定することができる。他方、加入者は、待ち時間のある加入者が好んでいるレストランを選択することもできる。Ｂ２Ｂエンジンは、次に、加入者の選択を選択されたレストランの予約アプリケーションに伝達する（プロセス・ステップ２１２０）。

選択されたレストランの予約アプリケーションは、Ｂ２Ｂエンジン（レストラン・モジュールを使用している）から４人分の予約の確認を受信し、その情報をレストラン予約データベースに入力する。次に、Ｂ２Ｂエンジンに相互接続されている、レストラン・モジュールは、「固定局」（つまり、レストラン）の位置及び移動局（加入者）の現在位置を使用する加入者のＥＴＡを計算する。予約情報（ＥＴＡを含む）は、自動的に、表示装置（ＣＲＴ、フラット・パネル・ディスプレイなどでよい）上でレストラン・フロア要員に示される。この表示装置には、テーブル番号、ＥＴＡ、パーティの名前、喫煙／非喫煙、パーティでの番号、テーブルを到着したパーティに用意できる時刻を含めることができる。

現在４人席を占有しているパーティがそのテーブルを退席するのが遅れている場合、テーブルの割り当てウェイターが、新しい予想席空き時間を入力することによりレストラン・システム内のテーブル空き状況を調整することができる。予約アプリケーションでは、次に、加入者の予想到着時間と新しいテーブル空き時間とを比較する。表示装置に表示されている加入者のＥＴＡは、実際の到着時刻になるまで定期的に更新される。すでに指摘したように、予約アプリケーション又は加入者のＭＳは、ＭＳの現在位置を決定するためＢ２Ｂエンジンに定期的に信号を送ることができる。

加入者のＥＴＡが修正された予想テーブル空き時間よりも早い場合、加入者を、加入者を受け入れる用意を整えられる他のテーブルに割り当てることができる。加入者のＥＴＡに間に合うテーブルが空いていない場合、予約アプリケーションは、席空き時間をレストラン・モジュールに通知する。このときに、予約アプリケーションは、次に空く４人席テーブルをレストランのバーで待つように無料ドリンク・クーポンの提供を加入者に送信するようにレストラン・モジュールに信号を自動的に送ることができる。予想されるテーブル空き及びクーポン提供を新しいメッセージに含め、レストラン・モジュールはそれを加入者に転送する。その後、加入者は、レストランの新しい選択を行うか、又はレストラン申し出を受け入れるかの選択をすることができる（プロセス・ステップ２１２５）。

予約の確認からレストラン到着までの間、加入者のＥＴＡは、定期的に更新し、レストランの予約管理システムにより表示することができる。レストランでは、この期間に、加入者のＥＴＡ更新のため、Ｂ２Ｂエンジンに定期的に信号を送信するように予約アプリケーションを設定できる。Ｂ２Ｂエンジンは、定期的要求を受信すると、ＭＰＣをチェックして、加入者の現在位置を判別し、レストラン・モジュールはレストランの位置で加入者の更新されたＥＴＡを計算する。それとは別に、加入者のＭＳ上に常駐する、クライアント・モジュールは、移動体位置決定センターの代わりに定期的位置要求を自動的に生成することができる。

レストラン・モジュールは、加入者の位置を監視し続ける。テーブルが空くと、予約アプリケーションはレストラン・モジュールに通知し、その後、予約済みの席が空いたことを加入者に通知する。加入者がレストランに到着し、席に着くと、予約管理アプリケーションは更新される。システムでは、テーブルを「占有済み」と表示し、アプリケーションは、自動的に、定期的ＥＴＡ更新を取り消す（プロセス・ステップ２１３０）。

当業者であれば理解するように、本出願で説明している革新的概念は、各種用途に関して修正し変更を加えることができる。したがって、特許出願されている主題の範囲は、説明されている教示の特定の例に限られないが、その代わりに、請求項により定められる。

さまざまなインターネット・ベースのコンテンツを加入者に提供する従来の通信システムの図である。 外部コンテンツ・プロバイダとインターフェースするＢｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓエンジンを備え、リアルタイム加入者情報を提供する、本発明の原理による通信システムの図である。 本発明によるＢｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓエンジンを使い通信事業者とコンテンツ・プロバイダとの間のやり取りを説明する図２の通信システムの他の図である。 Ｂｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓエンジンを使用する移動体通信事業者とコンテンツ・プロバイダとの間のやり取りを説明する図２及び３に例示されている本発明の好ましい実施形態の図である。 本発明のＢｕｓｉｎｅｓｓ−ｔｏ−Ｂｕｓｉｎｅｓｓエンジンとネットワークの異なる要素との間のやり取りの実施形態の図である。 本発明の好ましい実施形態による多数のアプリケーション・モジュールのアーキテクチャを例示する図である。 本発明の他の実施形態による図６に示されているものからのアプリケーション・モジュールの他のアーキテクチャを例示する図である。 ユーザ加入初期化で使用される信号の流れを例示する流れ図である。 本発明のＢ２Ｂエンジンを使用するポータルとユーザ機器との間の好ましいインターフェースを例示する図である。 本発明の教示に従って「ＯＦＦ」トリガを開始する際に使用される多数の信号を例示する流れ図である。 本発明の教示に従って通信システム内に発生するイベントの信号の流れを例示する他の流れ図である。 本発明のＢ２Ｂエンジンに対するユーザ・オン指示を例示する流れ図である。 本発明のＢ２Ｂエンジンに対する位置エリア更新を例示する流れ図である。 Ｂ２Ｂエンジンと複数のネットワーク・ノードとの間の多数のやり取りを説明する、本発明の好ましい実施形態によるアーキテクチャを例示する図である。 Ｂ２Ｂエンジンへのネットワーク・ノード通知の実施形態を示す図である。 本発明の教示によるさまざまなネットワーク要素からＢ２Ｂエンジンへの携帯電話加入者に関連するリアルタイム情報の通信を示す図である。 本発明と関連して使用される、特にＢ２Ｂエンジンと複数のネットワーク・ノードとの間の多数のプロトコルを例示する図である。 Ｂ２Ｂエンジンと異なるネットワーク・アーキテクチャとの構成及び相互作用の実施形態を示す図である。 本発明の教示による相互接続されたレストラン・アプリケーション・モジュールを使用するＢ２Ｂエンジンの高水準ブロック図である。 本発明の実施形態によるＢ２Ｂエンジン、相互接続された予約アプリケーション、及びレストラン・コンピュータ・システムにおける予約アプリケーションの間の通信の流れを示すブロック図である。 本発明の一実施形態によりＢ２Ｂエンジン及びリアルタイム情報相互交換を使用して予約システムを管理する方法を例示する図である。

Claims (25)

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. 前記Ｂ２Ｂエンジンは、前記情報サービス・プロバイダ、前記インターネット及び前記通信ネットワークに相互接続され、前記通信ネットワークは、無線ネットワーク及び有線ネットワークを含む請求項１３に記載のＢ２Ｂエンジン。
    

Images