(57)【要約】      （修正有）【課題】自動車のドライバーがサービス提供サーバーに容易にアクセスできるテレコミュニケーションプラットフォームのためのサービス集約システムの提供。【解決手段】リクエスト管理モジュール１１と、ターゲットデータＤ４およびリクエストＲをリクエスト管理モジュール１１から受信し、データＤ４、Ｒの全セットをリクエストＲが意図しない非関連サービスデータ提供サーバーＳ１、Ｓ２、Ｓ３に伝送するリクエスト分析モジュール１２とを含むデータ管理サーバー１０を具備し、非関連サーバーＳ１、Ｓ２、Ｓ３はリクエスト管理モジュール１１によって集約される付加データＤ１、Ｄ２、Ｄ３を応答として提供し、その後データＤ１、Ｄ２、Ｄ３、Ｄ４の全セットはリクエスト管理モジュール１１によってテレコミュニケーションプラットフォーム１００に伝送される。【選択図】図２
2009060581.tif 000002
【特許請求の範囲】
【請求項１】
テレコミュニケーションプラットフォーム（１００）のためのサービス集約システムであって、
サービスデータ提供サーバー（Ｓ１、Ｓ２、Ｓ３、Ｓ４）につながっているデータ管理サーバー（１０）を含み、サーバー（１０、Ｓ１、Ｓ２、Ｓ３、Ｓ４）の全セットが、管理サーバー（１０）によって形成されるセンターと、管理サーバー（１０）とサービスデータ提供サーバー（Ｓ１、Ｓ２、Ｓ３、Ｓ４）との間に形成されるブランチと、からなるスターを形成し、
前記管理サーバー（１０）は、前記テレコミュニケーションプラットフォーム（１００）から生じたリクエスト（Ｒ）を受信し、リクエスト（Ｒ）が意図する関連サービスデータ提供サーバー（Ｓ４）に当該リクエストを伝送するように設計されたリクエスト管理モジュール（１１）を含み、前記関連サービスデータ提供サーバー（Ｓ４）は、前記リクエスト（Ｒ）に応答してターゲットデータ（Ｄ４）を提供し、
前記管理サーバー（１０）は、前記ターゲットデータ（Ｄ４）と前記リクエスト（Ｒ）を前記リクエスト管理モジュール（１１）から受信し、データ（Ｄ４、Ｒ）の全セットを、リクエスト（Ｒ）が意図しない非関連サービスデータ提供サーバー（Ｓ１、Ｓ２、Ｓ３）に伝送するリクエスト分析モジュール（１２）を含み、
前記非関連サーバー（Ｓ１、Ｓ２、Ｓ３）は、前記リクエスト管理モジュール（１１）によって集約される付加データ（Ｄ１、Ｄ２、Ｄ３）を応答して提供し、その後データ（Ｄ１、Ｄ２、Ｄ３、Ｄ４）の全セットがリクエスト管理モジュール（１１）によって前記テレコミュニケーションプラットフォーム（１００）に伝送される、サービス集約システム。
【請求項２】
前記非関連サーバー（Ｓ１、Ｓ２、Ｓ３）は、受信した前記ターゲットデータ（Ｄ４）をフィルターにかけることで当該非関連サーバー（Ｓ１、Ｓ２、Ｓ３）が応答して付加データ（Ｄ１、Ｄ２、Ｄ３）を提供できるようなパラメータを抽出するように設計されている、請求項１記載のサービス集約システム。
【請求項３】
前記リクエスト管理モジュール（１１）は、ターゲットデータを充実させるために付加データ（Ｄ１、Ｄ２、Ｄ３）をターゲットデータ（Ｄ４）に組み込むように設計されている、請求項１記載のサービス集約システム。
【請求項４】
前記管理サーバー（１０）は、前記サーバー（Ｓ１、Ｓ２、Ｓ３、Ｓ４）への前記リクエストの伝送をフィルターにかけて強化することで優先サービスを提示するように設計されたドライバーカスタマイズモジュール（１３）を含む、請求項１記載のサービス集約システム。
【請求項５】
前記ドライバーカスタマイズモジュール（１３）は、優先パラメータのデータベースを含む、請求項４記載のサービス集約システム。
【請求項６】
前記ドライバーカスタマイズモジュール（１３）は、前記リクエスト（Ｒ）から前記優先パラメータを抽出し、これを前記優先パラメータのデータベースに保存する、請求項５記載のサービス集約システム。
【請求項７】
前記管理サーバー（１０）は、種々のサービス提供サーバー（Ｓ１〜Ｓ４）へのアクセスを制御できる識別モジュール（１４）を含む、請求項１記載のサービス集約システム。
【請求項８】
前記識別モジュール（１４）は、前記種々のサービス提供サーバー（Ｓ１〜Ｓ４）の請求を制御できる請求モジュール（１４１）を含む、請求項７記載のサービス集約システム。
【請求項９】
前記請求モジュール（１４１）は、サービス提供サーバー（Ｓ４）へのアクセスの費用を負担するように設計された参加サービス提供サーバー（Ｐ１〜Ｐ４）につなげられる、請求項８記載のサービス集約システム。
【請求項１０】
前記リクエスト管理モジュール（１１）は、前記サービス提供サーバー（Ｓ４）によって戻された付加データ（Ｄ４）を前記参加サービス提供サーバー（Ｐ１〜Ｐ４）に送信する、請求項９記載のサービス集約システム。
【請求項１１】
前記参加サービス提供サーバー（Ｐ１〜Ｐ４）は、前記リクエスト管理モジュール（１１）によって集約される参加ターゲットデータ（Ｃ１）を戻す、請求項１０記載のサービス集約システム。
【請求項１２】
前記参加ターゲットデータ（Ｃ１）が商業的データである、請求項１１記載のサービス集約システム。
【請求項１３】
前記テレコミュニケーションプラットフォーム（１００）がモバイルプラットフォームである、請求項１記載のサービス集約システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスを供給するサーバーとテレコミュニケーションシステムとの通信の分野に関する。本発明は、より具体的に言うと、ワイヤレステレコミュニケーションリンクを介して遠隔サービスに接続する、自動車に埋め込まれたシステムに関する。
【背景技術】
【０００２】
自動車は、サービスを求めることで運転中に情報を要求できる。例えば、自動車に乗っている人が運転中に交通状況や天候状況を要求できる。サービスを介して情報を要求するには、情報を受信しながら車両を移動させられる無線通信手段が必要となる。従来の方法では、衛星、電話、無線、ＷＩＦＩを介した通信によって情報を車両に伝送することができる。
【０００３】
こういった種々の情報媒体のおかげで、ドライバーは車両の埋め込みシステムを介して種々のサービスを要求し、最良のルートや天候状況を確認でき、また旅を楽にするために商品やサービスを注文することができる（レストランの席の予約、ホテルの部屋の予約など）。
【０００４】
既存の通信システムは、所望の情報を獲得するためにドライバーが多数のパラメータを埋め込みシステムに入力しなければならないため、あまり適当ではない。つまり車両のドライバーが自身のルートの途中に位置する町でホテルの部屋を予約したいならば、ドライバーは多数の問い合わせをしなければならない。まず初めにドライバーは、第１のサービスでルートを要求するために出発する町と到着する町の名前を入力する必要がある。そしてドライバーはこのルートを分析し、どの町が途中に位置するかを決めなければならない。次にドライバーは町の名前を再入力して第２のサービスを要求し、その町にあるホテルの詳細を獲得しなければならない。最後にドライバーは電話をかけ、例えば銀行カード情報を提示して部屋を予約しなければならない。
【０００５】
車両におけるこのようなサービスの管理は、不適切で危険ですらある。パラメータを多数入力することでドライバーの集中が落ちるため、事故の危険性が高くなる。だからドライバーはサービスを調べるために停止しなければならず、旅の時間が長くなってしまう。
【０００６】
情報の要求は時間がかかり、また実際に面倒であるため、ドライバーがサービスを調べることを思いとどまらせてしまう。さらに、ドライバーは所望の情報を獲得するために種々のサービス加入を強いられるため、自身の識別や支払いに関するステップが繰り返される。このようなサービス管理システムは遅く、非実用的で、深い集中を要する。したがってユーザにとってほとんど興味のないものになってしまう。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本願の発明は、このような欠点を解消することを目的とする。
【課題を解決するための手段】
【０００８】
この目的のために、本発明はテレコミュニケーションプラットフォームのためのサービス集約システムに関し、このシステムは、
サービスデータ提供サーバーにつながっているデータ管理サーバーを含み、サーバーの全セットが、管理サーバーによって形成されるセンターと、管理サーバーとサービスデータ提供サーバーとの間に形成されるブランチとからなるスターを形成し、
管理サーバーは、テレコミュニケーションプラットフォームから生じたリクエストを受信し、リクエストが意図する関連サービスデータ提供サーバーにリクエストを伝送するように設計されたリクエスト管理モジュールを含み、関連サービスデータ提供サーバーは、リクエストに応答してターゲットデータを提供し、
管理サーバーは、ターゲットデータとリクエストをリクエスト管理モジュールから受信し、データの全セットを、リクエストが意図しない非関連サービスデータ提供サーバーに伝送するリクエスト分析モジュールを含み、
非関連サーバーはリクエスト管理モジュールによって集約される付加データを応答して提供し、その後データの全セットはリクエスト管理モジュールによってテレコミュニケーションプラットフォームに伝送される。
【０００９】
ドライバーがある項目の情報を獲得するためにリクエストを送信すると、付加情報がドライバーに提示されるため、ドライバーが何回も要求する必要性を回避することができる。サーバーによって形成されるネットワークのスター型構成によって、テレコミュニケーションプラットフォームが伝送した情報を有利に集めることができるため、各サービスへのアクセスのリクエストの不要な重複を避けることができる。
【００１０】
相乗効果によって互いを充実させるために、相互作用するデータの組み合わせを形成する「データ集約」によって理解できる。データ集約は、データの並列化またはグループ化とは異なる。
【００１１】
好ましくは、非関連サーバーは、受信したターゲットデータをフィルターにかけることで、当該非関連サーバーが応答して付加データを提供できるようなパラメータを抽出するように設計される。
【００１２】
好ましくは、リクエスト管理モジュールは、ターゲットデータを充実させるために付加データをターゲットデータに組み込むように設計される。
【００１３】
こうして付加データは、関連サービスデータ提供サーバーによって提供されるターゲットデータに依存するダイナミックデータとなる。これは、予め選択されたデータまたはスタティックデータがドライバーに伝送されるデータポータルとは異なる。
【００１４】
好ましくは、管理サーバーは、サーバーへのリクエストの伝送をフィルターにかけて強化することで優先サービスを提示するように設計されたドライバーカスタマイズモジュールを含む。
【００１５】
さらに好ましくは、ドライバーカスタマイズモジュールは優先パラメータのデータベースを含む。ドライバーカスタマイズモジュールはリクエストから優先パラメータを抽出し、これを優先パラメータのデータベースに保存する。
【００１６】
好ましくは、管理サーバーは、種々のサービス提供サーバーへのアクセスを制御できる識別モジュールを含む。
【００１７】
さらに好ましくは、識別モジュールは、種々のサービス提供サーバーの請求を制御できる請求モジュールを含む。この請求モジュールは、サービス提供サーバーへのアクセスの費用を負担するように設計された参加サービス提供サーバーにつなげられる。
【００１８】
さらに好ましくは、リクエスト管理モジュールは、サービス提供サーバーによって戻された付加データを参加サービス提供サーバーに送信する。
【００１９】
さらに好ましくは、参加サービス提供サーバーは、リクエスト管理モジュールによって集約される参加ターゲットデータを戻す。
【００２０】
さらに好ましくは、参加ターゲットデータは商業的データである。
【００２１】
本発明の集約システムの最も有利な形態では、テレコミュニケーションプラットフォームはモバイルプラットフォームである。
【００２２】
本発明は、以下の説明と添付図面を用いることで、よりよく理解されるであろう。
【発明を実施するための最良の形態】
【００２３】
本発明は、図１に示されているように、自動車に配置された、ここではモバイルプラットフォームであるテレコミュニケーションプラットフォーム１００とサービス提供サーバーＳ１〜Ｓ４との通信に関する。本発明のこの例示的な実施例では、モバイルテレコミュニケーションプラットフォーム１００は携帯電話１００の形をとり、自動車のドライバー１が電話１００を操作してサービスにアクセスする。
【００２４】
携帯電話１００は、電話網を介して端末につなぐ通常の機能のほかに、多数のサービスへのアクセスを可能にするＷＩＦＩ、ＢＬＵＥＴＯＯＴＨ、無線型の通信機能を含むことができる。
【００２５】
この例では、ドライバー１は加入している電話網を介して種々のサービスにアクセスする。分かりやすくするために、加入者と自動車のドライバー１とが同一人物であると仮定する。種々のサービスにアクセスするために、ドライバー１は電話網を介してリクエストＲを管理サーバー１０に送信し、管理サーバー１０がリクエストＲを処理する。
【００２６】
図２を参照すると、管理サーバー１０はサービス提供サーバーＳ１〜Ｓ４に有線ベースまたは無線でつながっており、サーバーＳ１〜Ｓ４は管理サーバー１０から生じたリクエストＲ’を受信する。このリクエストＲ’は、リクエストＲと同一であるかまたはこのリクエストＲに基づいて変更されている。つまり、携帯電話１００が送信する一切のリクエストＲは管理サーバー１０によってリレーされ、サービス提供サーバーＳ１〜Ｓ４に到達する。
【００２７】
サービス提供サーバーＳ１〜Ｓ４はリクエストに応えてデータを提供するサーバーの形をとり、提供されるデータはリクエストの性質に関して異なる（地理的位置、株式市場の値、店の名前など）。リクエストがデータ提供サーバーによる受信に適さない場合、そのサーバーは応答しない。言い換えると、データ提供サーバーは受信したリクエストをフィルターにかけ、そのリクエストからサーバーがデータを提供できるようなパラメータを抽出する。したがって気象サーバーの場合、受信したリクエストは、ウェザーオーディット（weather audit）位置を獲得するために少なくとも１つの位置（都市名、住所、地理座標など）を含んでいなければならない。サーバーは、株式市場の値に応答して気象データは提供しない。
【００２８】
管理サーバー１０は、自身とサービス提供サーバーＳ１〜Ｓ４によって形成されるネットワークの中心である。このネットワークは、管理サーバーが電話１００と各サービス提供サーバーＳ１〜Ｓ４との間に配置され、この管理サーバーがアクセスしているサービスへの加入者の識別を個別に保証するいわゆるパラレルネットワークに対してスター型ネットワークと呼ばれる。
【００２９】
管理サーバー１０は、携帯電話１００から生じたリクエストＲを受信し、これを関連サービスデータ提供サーバー、ここでは例えばサーバーＳ４に伝送するように設計されたリクエスト管理モジュール１１を含む。以下の例では、単一のリクエストＲの処理に限定して説明する。
【００３０】
ドライバー１がリクエストＲを送信するときに、このリクエストのあて先を決定することができる。ドライバー１は、例えばナビゲーションサービスにアクセスしたいと指示する。リクエストＲが管理モジュール１１に到達すると、このリクエストＲはそれが意図されたサービス提供サーバーＳ４に向けられる。
【００３１】
もちろん、リクエストＲのあて先を文脈分析によって決定することもでき、ドライバー１が町の名前を再入力するだけで、管理サーバー１０はサービス提供サーバーを介してその町までのルートを提示する。
【００３２】
サービス提供サーバーＳ４はリクエストＲを受信し、ターゲットデータＤ４をリクエスト管理モジュール１１に戻す。
【００３３】
リクエスト管理モジュール１１がターゲットデータＤ４を受信すると、このモジュールはリクエストＲとターゲットデータＤ４をリクエスト分析モジュール１２に伝送する。リクエスト分析モジュール１２は、管理サーバー１０に位置しリクエスト管理モジュール１１につながっている。図２では、データＤ４とリクエストＲをＲ’で参照している。
【００３４】
リクエスト分析モジュール１２はデータＲ’を受信し、これを非関連サービスデータ提供サーバーＳ１〜Ｓ３に伝送する。各サービスデータ提供サーバーＳ１〜Ｓ３は、データＲ’の受信後にこのデータＲ’をフィルターにかけ、サーバーが応答して付加データＤ１〜Ｄ３を戻せるようなパラメータを抽出する。付加データＤ１〜Ｄ３の全セットがリクエスト管理モジュール１１に伝送される。
【００３５】
付加データＤ１〜Ｄ３は、ターゲットデータＤ４を充実させるためにこれに組み込まれる。
【００３６】
その後データＤ１〜Ｄ４の全セットをリクエスト管理モジュール１１によって携帯電話１００に伝送し、音声（ボイスオーダー）または視覚（携帯電話１００における画像の表示）によってドライバー１と通信する。ドライバーは自身の携帯電話１００でターゲットデータを見つつ、リクエストしなかった付加データＤ１〜Ｄ３から利益を得る。
【００３７】
本発明のサービス集約システムを、例示的な実施例を用いて説明する。
【００３８】
自動車のドライバー１は、Ａ町からＢ町に行こうとしている。ドライバーは、ルートリクエストＲを管理サーバー１０に送信し、自身の携帯電話１００を使い電話網を介してＡ町とＢ町の名前を指定する。メッセージ管理モジュール１１はこのリクエストＲを処理し、リクエストが意図するサーバーを決定する。
【００３９】
この例では、リクエストＲはナビゲーションサーバーＳ４を意図している。このナビゲーションサーバーＳ４は、リクエストＲに応答して、ターゲットデータＤ４を戻す。このターゲットデータＤ４は、Ａ町からＢ町へのルートの図式によるプランと、ドライバー１が旅程においてとるべき方向（左、右、直進など）とにそれぞれ対応する画像と音声のファイルのセットを含む。データＤ４はまた、ルートの種々の地理座標を、その座標の予想到着時刻を伴って含む。
【００４０】
ターゲットデータＤ４の受信後、リクエスト管理モジュール１１はリクエストＲをターゲットデータＤ４と共に（データＲ’）リクエスト分析モジュール１２に伝送する。データＲ’は別のサービス提供サーバーＳ３に伝送され、このサーバーはデータＲ’をフィルターにかけてサーバーＳ３が応答してデータを戻せるようなパラメータを抽出する。この例では、サーバーＳ３はルートの地理座標をその座標の予想到着時刻と共にパラメータとして抽出する。サービス提供サーバーＳ３は、所定の地理座標における所定の時間帯の気象状況を提供することができる。気象サービスサーバーＳ３は、付加データＤ３のセットをリクエスト管理モジュール１１に戻す。付加データＤ３は、ナビゲーションサービスＳ４が戻した地理データと時間データの各ペアの気象状況に対応する。リクエスト管理モジュール１１は、ターゲットデータＤ４、この場合はルートと、付加データＤ３、この場合はそのルートに沿った気象状況とを集約する。こうしてドライバー１には、気象状況はＡ町近傍では穏やかであるが途中悪化するということが自身の携帯電話１００を見ることで知らされる。
【００４１】
その後ターゲットデータＤ４と付加データＤ３の全セットを、リクエスト管理モジュール１１によって携帯電話１００に送信する。するとドライバー１は、自身の携帯電話１００を介してＡ町からＢ町へのルートと旅程に沿った気象状況を受信する。これによって、ドライバー１は気象状況に適したタイヤを車両に有利に装備することができる。
【００４２】
リクエスト分析モジュール１２は、ターゲットデータＤ４とリクエストＲを幾つかのサービス提供サーバーＳ１〜Ｓ３に伝送することもでき、各サーバーＳ１〜Ｓ３は、受信したデータをフィルターにかけ、サーバーＳ１〜Ｓ３が応答してデータを提供できるようなパラメータを抽出するための独自の方法を持っている。これと同様に、リクエスト分析モジュール１２は、例えばＡ町からＢ町へのルートの図式によるプランやドライバー１が旅程においてとるべき方向などのターゲットデータＤ４の一部をブロックすることで、サービス提供サーバーに伝送されるデータをフィルターにかけることができる。非関連サービス提供サーバーＳ１〜Ｓ３が応答してデータを戻せるようなパラメータを抽出するために、サーバーＳ１〜Ｓ３に送られるデータＲ’のフィルタリングを、リクエスト分析モジュール１２で実現することもできる。これによって、非関連データを非関連サーバーＳ１〜Ｓ３に伝送することを有利に回避することができる。
【００４３】
別の実施形態では、本システムは、図３に示すように、リクエストのサーバーＳ１、Ｓ２、Ｓ３、Ｓ４への伝送をフィルターにかけるように設計されたドライバーカスタマイズモジュール１３を含む。
【００４４】
ドライバーカスタマイズモジュール１３は優先パラメータでパラメータ化され、ドライバー１が送信したリクエストＲのフィルタリングと強化を確実にする。例えば、ドライバーカスタマイズモジュール１３は海岸道路優先パラメータを含む。
【００４５】
引き続き先の例を参照すると、ドライバー１がリクエストＲにおいて出発がＡ町で到着がＢ町であるとリクエスト管理モジュール１１に示すと、ドライバーカスタマイズモジュール１３は、海岸付近を通るＡ町からＢ町へのルートを付加的に要求するようにリクエストＲを変更する。
【００４６】
同様にドライバーカスタマイズモジュール１３が、ドライバー１は高度の高い場所付近の天候状況にのみ興味があると規定したパラメータを含むならば、サーバーＳ４によって戻されるターゲットデータＤ４はカスタマイズモジュール１３によってフィルターにかけられ、高度がドライバー１の優先パラメータよりも高い地理データのみを気象サーバーＳ３に送信する（図３）。
【００４７】
したがって、カスタマイズモジュール１３によってより正確な情報をドライバー１に提供することができ、ドライバー１が興味のないデータをサービス提供サーバーＳ１〜Ｓ３に伝送してしまうことも回避できる。図３を参照すると、ドライバーカスタマイズモジュール１３はリクエストＲから生じた一切のデータをサービス提供サーバーＳ１に伝送しない。
【００４８】
もちろん、リクエスト管理モジュール１１、リクエスト分析モジュール１２、カスタマイズモジュール１３を単一のモジュール内でグループ化できる。
【００４９】
優先パラメータはドライバー１の携帯電話１００によって手作業で再入力してもよいし、リクエストＲの分析時に抽出してもよい。したがって、ドライバー１がルートとそれに続いて高度による天候状況を何回も要求すると、各ルートリクエストとそれに対応する気象状況のリクエストを合わせた優先パラメータがカスタマイズデータベースに保存される。ドライバー１は、高度による気象状況を伴う旅のルートをそのまま得るにはＡ町とＢ町の名前を指示するだけで十分である。
【００５０】
図４を参照すると、本発明のシステムはここで、ドライバー１がリクエストＲを処理可能なサービス提供サーバーＳ１〜Ｓ４へのアクセスを本当に許可されているかどうかを確認できる単一の識別モジュール１４を含む。したがって、各サービス提供サーバーＳ１〜Ｓ４はサーバー固有の識別モジュールを必要としない。
【００５１】
識別モジュール１４は、ドライバー１が加入しているサービス提供サーバーＳ１〜Ｓ４の名前とそのサーバーＳ１〜Ｓ４の識別コードやパスワードを含む識別データベースからなる。ドライバー１がサービスを要求する場合、このドライバーは管理サーバー１０で１回の識別ステップを実行するだけでよく、識別モジュール１４がリクエストＲを関連するサービス提供サーバーＳ１〜Ｓ４それぞれについて個々に識別する責任を負う。
【００５２】
例示的な実施例では、ドライバー１はルートリクエストＲを管理サーバー１０に送信し、識別モジュール１４は識別情報、この場合は識別子とパスワードを提供するようにドライバーに求める。識別情報を検証・確認した後、データベースに保存されている識別データをドライバー１が加入している気象サーバーＳ３とナビゲーションサーバーＳ４に送る。こうしてドライバー１は、自身の電話１００の最少の操作で有利に且つ迅速にサービスにアクセスできる。
【００５３】
識別モジュール１４は、ドライバー１がサービスに集中してアクセスできるように、請求モジュール１４１を有利に含む。識別データベースは、識別情報のほかに、ドライバー１の請求データを含む。つまり所与のサービスについて、データベースは顧客コード、請求先住所、送付先住所などのドライバー１の請求データを含む。
【００５４】
請求モジュール１４１によって、携帯電話１００と種々のサービス提供サーバーＳ１〜Ｓ４との全てのやりとりを集中させることができる。
【００５５】
管理サーバー１０に位置する識別・請求モジュール１４は、携帯電話１００からリクエストＲを受信し、それを分析してドライバー１が加入者であるかどうか、またこのドライバーが支払いサービスにアクセス可能かどうかを確認する。確認後、リクエストＲは図４に示すようにリクエスト管理モジュール１１に伝送される。
【００５６】
携帯電話１００から生じ、ドライバー１が加入していないサービス提供サーバーＳ４を意図したリクエストＲを、識別・請求モジュール１４が受信した場合には、このリクエストを参加サーバーＰ１〜Ｐ４と呼ばれ図４に示されている参加サービス提供サーバーＰ１〜Ｐ４につなげる。
【００５７】
サービス提供サーバーＳ１〜Ｓ４であってもよい参加サーバーＰ１〜Ｐ４は、識別・請求モジュール１４とかけあって、ドライバー１が加入していないサービスＳ４へのアクセスの費用を負担する。つまりドライバー１が支払いナビゲーションサービスＳ４にアクセスしたい場合には、リクエストＲが識別・請求モジュール１４で分析される。識別・請求データベースでは、サービスＳ４へのアクセスの費用を負担できる参加サーバーＰ１〜Ｐ４の識別子が存在するかどうかを確認するためにチェックを行う。確認できた場合、識別・請求モジュール１４は参加サーバーＰ１から発された参加認証リクエストを携帯電話１００に送信する。
【００５８】
ドライバー１が招待を断った場合、ドライバーはリクエストＲを自身の携帯電話１００を介して識別・請求モジュール１４に送信する。参加サーバーＰ１は作動しないままで、ドライバー１は支払いサービス提供サーバーＳ４にアクセスするために請求データを入力しなければならない。
【００５９】
ドライバー１が参加の申し入れを受けた場合、請求モジュール１４はサービス提供サーバーＳ４のサービスを参加サーバーＰ１に請求する。ドライバー１のリクエストＲはターゲットデータＤ４を戻すサービス提供サーバーＳ４に伝送され、ターゲットデータＤ４と元のリクエストＲは参加サーバーＰ１に伝送される。
【００６０】
非関連サービス提供サーバーなどの参加サーバーＰ１は、参加付加データＣ１をリクエスト管理モジュール１１に戻し、ターゲットデータＤ４を強化する。
【００６１】
関連サービス提供サーバーＳ４がナビゲーションサービスＳ４である先の例を引き続き参照すると、ドライバー１はリクエストＲを送信してナビゲーションサービスＳ４にアクセスし、参加サーバーＰ１を使用するための招待を受け、このサーバーがナビゲーションサービスＳ４へのアクセスの費用を負担する。参加サーバーＰ１はここではドライバー１のルート沿いにあるレストランやホテルのリストＣ１を提供する広告サーバーの形をとっている。
【００６２】
地理座標に関連付けられたレストランとホテルのリストＣ１は管理モジュール１１に送られ、ナビゲーションサービスＳ４によって提供されるルートＤ４に追加される。ドライバー１はルートを無料で受信し、もう一方でルートに集約されたターゲットとなった商業的な提案から利益を受ける。
【００６３】
本発明の別の例示的な実施例では、自動車に配置されるテレコミュニケーションプラットフォームは、衛星回線を有するオンボードコンピュータ１００の形をとる。このオンボードコンピュータ１００は、ここではＧＰＳ（グローバルポジショニングシステム）データ受信機につながっており、車両の位置をＧＰＳ座標（緯度、経度）で与えることができる。
【００６４】
オンボードコンピュータ１００は、リクエストＲを管理サーバー１０に送信し、それと同時に車両のＧＰＳ座標をリクエストＲに組み込む。するとオンボードコンピュータ１００を使って町の名前を指示するだけで、ドライバー１は現在のＧＰＳ座標から目的地の町までのルートを要求することができる。
【００６５】
サービス集約システムによって、オンボードコンピュータ１００の最少の操作しか必要とせずに車両から情報を自動的に読み出すことで、サービス情報を獲得することができる。
【００６６】
もちろん、オンボードコンピュータ１００はＧＰＳ座標のほかに燃料レベルまたはタイヤの圧力も伝送できる。
【００６７】
本発明を携帯電話またはオンボードコンピュータの形をとるモバイルテレコミュニケーションプラットフォーム１００について示してきた。本発明は、例えば、データパーソナルアシスタント、通信用の埋め込みシステム、通信用のＧＰＳ受信機といった、サービス提供サーバーへの接続に適しており、従来「クライアント」という用語で表されるあらゆる他の装置を含むことができる。本発明はまた、ユーザが例えば２つの場所の間のルートを付加データと共に獲得するためにリクエストを送信するパーソナルコンピュータなどの固定テレコミュニケーションプラットフォームにも関連する。
【図面の簡単な説明】
【００６８】
【図１】管理サーバーが中心のスター型ネットワークを形成する管理サーバーとサービス提供サーバーを表す。
【図２】図１の管理サーバーモジュールとサービス提供サーバーとのやりとりの図を表す。
【図３】カスタマイズモジュールを有する、本発明の管理サーバーの別の実施形態を表す。
【図４】識別・請求モジュールを有する、本発明の管理サーバーの別の実施形態を表す。
【図１】
2009060581.tif 000003
【図２】
2009060581.tif 000004
【図３】
2009060581.tif 000005
【図４】
2009060581.tif 000006
【外国語明細書】
2009060581000001.pdf