(57)【要約】  本発明は複数のアプリケーションとサービスとの間に通信及び相互運用性を提供することに関する。そのようなアプリケーション及びサービスは異なるプラットフォーム上で動作するか、又は異なるプラットフォーム上に関連付けられている。本発明の装置によって、メッセージセットが提供される。このメッセージセットを用いて、サービスは利用可能なサービスを広告することが可能であり、アプリケーションは所望のサービスを識別することが可能である。一定の実施形態では、アプリケーションは表示サービスなど、利用可能なサービスに申し込む。一部の実施形態のさらなる一態様では、異なるプラットフォーム上で実行可能なアプリケーション及び異なるプラットフォームから利用可能なサービスでは、それら自身によってプラットフォーム間の通信がサポートされる必要はない。むしろ、そのようなサポートはプラットフォーム自身の一部として提供されるファシリティから取得される。
2008500610.tif 000002
【特許請求の範囲】
【請求項１】
サーバ装置、遠隔プラットフォーム及び通信チャネルからなる情報伝達システムであって、
サーバ装置は、
サービスエンジンと、
サーバ通信インタフェースと、
サーバ接続フレームワークプロセスと、
少なくとも第１タイプであり、かつ、第１組の能力を有するサーバサービスファシリティと、を備えることと、
遠隔プラットフォームは、
クライアントアプリケーションと、
サーバ装置の通信インタフェースとの互換性を有する通信インタフェースと、
クライアント接続フレームワークプロセスと、
少なくとも第１タイプであり、第２組の能力を有するクライアントサービスファシリティと、を備えることと、
通信チャネルにおいてサーバ装置の通信インタフェース及び遠隔プラットフォームの通信インタフェースが動作可能に相互接続されることと、
サーバ通信インタフェース、サーバ接続フレームワークプロセス、クライアント通信インタフェース及びクライアント接続フレームワークプロセスは、サーバサービスファシリティをクライアントアプリケーションに広告するように動作することと、
クライアントアプリケーションはサーバ装置のサービスファシリティを発見し、クライアント接続フレームワークプロセスとサーバ接続フレームワークプロセスとの間の対話を通してサービスファシリティとの論理的な通信経路を確立することと、
論理的な通信経路を確立した後、論理的な通信経路を用いて、通信チャネルを介してクライアントアプリケーションからサーバサービスファシリティへデータが渡されることと、を含む情報伝達システム。
【請求項２】
クライアントアプリケーションはサーバサービスファシリティにコンテンツを送りつける請求項１に記載のシステム。
【請求項３】
サーバサービスファシリティ及びクライアントサービスファシリティは表示装置を備える請求項１に記載のシステム。
【請求項４】
サーバの表示装置の面積はクライアントの表示装置の面積より大きい請求項３に記載のシステム。
【請求項５】
サーバサービスファシリティは音声サービスを含み、クライアントアプリケーションは音声コンテンツを提供する請求項１に記載のシステム。
【請求項６】
クライアントアプリケーションは視覚コンテンツを提供することを含む請求項５に記載のシステム。
【請求項７】
第１組の能力は第２組の能力より高い請求項１に記載のシステム。
【請求項８】
サーバ装置はユーザ入力を含むことと、サーバのユーザ入力において受信される第１ユーザアクションはクライアントアプリケーションに第１イベントとして渡されることと、を含む請求項１に記載のシステム。
【請求項９】
遠隔プラットフォームはユーザ入力を含むことと、遠隔プラットフォームのユーザ入力
において受信される第２ユーザアクションはクライアントアプリケーションにおいて第１イベントとして受信されることと、を含む請求項３に記載のシステム。
【請求項１０】
遠隔プラットフォームは携帯電話を含む請求項１に記載のシステム。
【請求項１１】
サーバ装置はＷｉｎ３２プラットフォームを含む請求項１に記載のシステム。
【請求項１２】
サーバサービスファシリティは視覚表示出力装置及びブラウザアプリケーションを含む請求項１に記載のシステム。
【請求項１３】
クライアント装置にサービスファシリティを提供するための方法であって、
利用可能なサーバサービスファシリティをサーバ装置において広告する広告工程と、
物理的な相互接続を用いてクライアント装置をサーバ装置と通信状態にする通信工程と、
利用可能なサービスファシリティをクライアント装置によって発見する発見工程と、
サービスと、クライアント装置上で動作するクライアントアプリケーションとの間の論理通信チャネルを確立するチャネル確立工程と、
クライアントアプリケーションからサービスファシリティに第１データを提供するデータ提供工程と、
サーバサービスファシリティは提供されたデータを用いてサービスを提供することと、
データ提供工程は、サーバ装置との物理的な相互接続を用いて、論理通信チャネルを介してクライアント装置からサーバサービスファシリティにデータを渡す工程を含むことと、からなる方法。
【請求項１４】
サービスファシリティはクライアント装置をサーバ装置と通信状態にするために用いられる物理的な相互接続とは別の物理的な相互接続によって中央システムに相互接続される出力装置を含む請求項１３に記載の方法。
【請求項１５】
サーバサービスファシリティは視覚的な出力装置を含み、提供された第１データは視覚的な出力装置によって表示される視覚的なコンテンツを含む請求項１４に記載の方法。
【請求項１６】
サーバ装置に関連付けられたユーザ入力において第１イベントを受信する工程と、
第１イベントをクライアントアプリケーションに配信する工程と、
クライアントアプリケーションにおいて第１イベントを受信することに応答して、クライアントアプリケーションからサービスに第２データを提供する工程と、視覚的な出力装置によって表示される視覚的なコンテンツは変更されることと、を含む請求項１５に記載の方法。
【請求項１７】
クライアント装置に関連付けられたユーザ入力において第１イベントを受信する工程と、
クライアントアプリケーションにおいて第１イベントを受信することに応答して、クライアントアプリケーションからサーバサービスファシリティに第２データを提供する工程と、視覚的な出力装置によって表示される視覚的なコンテンツは変更されることと、を含む請求項１５に記載の方法。
【請求項１８】
クライアント装置を識別する工程と、
識別されたクライアント装置に第１追加コンテンツを関連付ける工程と、視覚的な出力装置によって表示される視覚的なコンテンツは第１追加コンテンツを含むことと、を含む請求項１５に記載の方法。
【請求項１９】
サービスは視覚的な出力装置及びブラウザアプリケーションを含むことと、
クライアントアプリケーションにおいて第２データを生成する工程と、
第２の視覚的なコンテンツを含む第２データをクライアントアプリケーションからサーバサービスファシリティに提供する工程と、ブラウザアプリケーションは自動リフレッシュサイクルの一部として第２の視覚的なコンテンツを読み出し、表示することと、を含む請求項１５に記載の方法。
【請求項２０】
第１サービスを含む用途に利用可能なサービスに関連したサービス関連情報を管理し、かつ、複数の物理的な通信インタフェースを提供するための中央システムと、
アプリケーション関連情報を処理する少なくとも第１アプリケーションと、
第１アプリケーションによって用いられる少なくとも第１機能を提供するために中央システム上で動作する少なくとも第１サービスエンジンと、第１サービスエンジンは第１サービスを自身に関連付け、自身と通信状態とすることと、
少なくとも第１情報発信源と、第１情報発信源は物理的な通信インタフェースのうちの１つに相互接続され、かつ、第１情報発信源から第１サービスエンジンと通信を行うことと、アプリケーション関連情報は第１アプリケーションを用いて処理するために取得されることと、
少なくとも中央システム及び第１サービスエンジンの各々と通信を行う少なくとも第１インタフェースマネージャと、同インタフェースマネージャは中央システムと、第１インタフェースマネージャと通信可能な通信リンク技術との間の通信の互換性を提供するためのインタフェースマネージャであることと、
中央システムは第１サービスエンジンへの第１インタフェースマネージャ用の第１通信経路を確立するために用いられ、確立された後、第１インタフェースマネージャは中央システムとは独立して同情報発信源からのアプリケーション関連情報の取得に用いられることと、
中央システムはインタフェースマネージャと、相互接続された装置との間の第２通信経路を確立するために用いられることと、
第１通信経路及び第２通信経路は、中央システムを通して完成されることと、からなる情報伝達装置。
【請求項２１】
中央システムは第１サービスエンジンと通信を行って第１サービスエンジンから状態情報を取得し、第１サービスエンジンと第１アプリケーションとの間の通信について第１サービスエンジンに警告することを含む、請求項２０に記載の装置。
【請求項２２】
第１インタフェースマネージャは第１アプリケーションを用いて第１サービスエンジンと通信を行う請求項２０に記載の装置。
【請求項２３】
外部システム上で実行可能な第２アプリケーションを含むことと、外部システム上では第１インタフェースマネージャを用いて第１サービスエンジンにアクセスすることが可能であり、かつ、第１インタフェースマネージャとは独立に第１アプリケーションが情報発信源からアプリケーション関連情報を取得することが可能であることと、を含む請求項２０に記載の装置。
【請求項２４】
中央システムはオペレーティング・システムと、１つ以上のプロセッサを有するコントローラと、メモリとを含むことと、メモリのうちの少なくとも一部は少なくとも第２アプリケーションによる使用のためのサービス関連情報を記憶することと、を含む請求項２０に記載の装置。
【請求項２５】
第１アプリケーションは中央システムと直接通信を行う車両診断アプリケーションを含む請求項２０に記載の装置。
【請求項２６】
第１サービスエンジンは全地球測位システム（ＧＰＳ）、媒体指向システムトランスポート（ＭＯＳＴ）、車載車両診断プログラム（ＯＢＤ−ＩＩ）、コントローラ・エリア・ネットワーク（ＣＡＮ）及びユニバーサル・シリアル・バス（ＵＳＢ）のうちの１つ以上と関連している請求項２０に記載の装置。
【請求項２７】
通信リンク技術はユニバーサル・シリアル・バス（ＵＳＢ）、伝送制御プロトコル／ユニバーサル・データグラム・プロトコル（ＴＣＰ／ＵＤＰ）、コントローラ・エリア・ネットワーク（ＣＡＮ）及びＲＳ−２３２シリアル・ポートのうちの１つ以上を含む請求項２０に記載の装置。
【請求項２８】
通信リンク技術は無線技術を含み、かつ、ＷｉＦｉ、超広帯域（ＵＷＢ）ブルートゥース、パーソナル・エリア・ネットワーキング、ＣＯＭＡ、ＤＡＴＡＴＡＣ、ＧＳＭ／ＧＰＲＳ／ＥＤＧＥ、ＵＭＴＳ、Ｍｏｂｉｔｅｘ及び統合デジタル強化ネットワークインタフェースのうちの１つ以上に関連する請求項２０に記載の装置。
【請求項２９】
第１インタフェースマネージャは中央システムからメッセージを受信し、メッセージを用いて、第１インタフェースマネージャによって割り当てられた第１通信ポートに第１サービスをマッピングするテーブルを生成する請求項２０に記載の装置。
【請求項３０】
第１インタフェースマネージャは外部システムにメッセージを提供し、第１サービスが利用可能であることを示し、かつ、第１サービスが外部システムにより参照される方法を示すことを含む請求項２０に記載の装置。
【請求項３１】
第１インタフェースマネージャは外部システムに関連付けられた少なくとも第１遠隔サービスを、第１サービスエンジンにアクセスするために用いられる第２通信経路と関係づけるマッピングテーブルを生成する請求項２０に記載の装置。
【請求項３２】
通信リンク技術を用いて第１インタフェースマネージャと通信を行う外部システムに含まれる第２インタフェースマネージャと、
第２インタフェースマネージャは外部システムの第１遠隔サービスエンジンに関連付けられた識別子が含まれるメッセージを第１インタフェースマネージャに送信することと、
第１インタフェースマネージャは第１遠隔サービスエンジンとアドレスを関係づけることと、を含む請求項２０に記載の装置。
【請求項３３】
第１インタフェースマネージャは通信リンク技術にアドレスをマッピングする請求項３２に記載の装置。
【請求項３４】
通信リンク技術はユニバーサル・シリアル・バス（ＵＳＢ）、伝送制御プロトコル／ユニバーサル・データグラム・プロトコル（ＴＣＰ／ＵＤＰ）、コントローラ・エリア・ネットワーク（ＣＡＮ）及びＲＳ−２３２シリアル・ポートのうちの１つ以上に関連する請求項３３に記載の装置。
【請求項３５】
第２インタフェースマネージャはアドレスに対する第１遠隔サービスエンジンのマッピングに関連した情報を記憶する請求項３２に記載の装置。
【請求項３６】
使用可能な少なくとも第１遠隔サービスに関連した情報を含む遠隔サービス情報を管理する外部システムを含むことと、外部システムは少なくとも第１遠隔サービスに関して中央システムに通知することと、中央システムは第１サービスに関して外部システムに通知することと、を含む請求項２０に記載の装置。
【請求項３７】
中央システムは携帯電話の一部である請求項２０に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は複数の装置と機能との間に相互運用性を提供することに関する。詳細には、装置及びアプリケーションが異なるプラットフォーム上に実装され異なる通信リンク技術を用いる場合でも、本発明の実施形態により、そのような分散された装置及びアプリケーションを相互運用することが可能となる。
【背景技術】
【０００２】
装置の能力が益々向上してきたために、装置間で情報を交換することが益々望ましくなっている。しかしながら、異なる装置は、異なる互換性のない通信リンク技術を用いることが多い。従って、装置に情報を交換させることは、困難になっている。
【０００３】
例えば、同じネットワークに相互接続されることによって、互いに正式には関連付けられていない異なる装置間で通信を可能とすることも、装置の携帯性が増すにつれて益々望ましくなっている。特に、任意の数の異なる装置がユーザ又は作業空間に関連付けできることから、異なる装置が情報を交換したり、資源を共有したりすることは望ましい。例えば、ユーザに関連付けられた全地球測位システム（ＧＰＳ）受信機が、そのユーザに関連付けられマッピングアプリケーションを動作させる携帯情報端末（ＰＤＡ）に位置情報を提供して、情報を交換することは望ましい。更に、そのようなＰＤＡが、同様にユーザに関連付けられた無線電話によってＰＤＡに記憶される電話帳に保持された番号の自動ダイヤル呼出しを行うことは望ましい。更に他の例では、そのような装置がユーザの車両に配置されたりそれと関連付けられたりする場合、コントローラ・エリア・ネットワーク（ＣＡＮ）等の車両データバスと通信を行うことや、互いに情報を交換することは望ましい。
【０００４】
様々な種類の装置の機能を統合するシステムが最近利用可能になったが、そのような構成は、真に柔軟ではない。例えば、ＰＤＡと電話、又はＰＤＡとＧＰＳ受信機を統合する装置が、現在では入手可能である。しかしながら、そのような装置は、使用が厄介で高価な傾向がある。更に、追加の装置と通信を行うそのような装置の能力は、制限されているか存在しない。更に他の例として、車両製造業者は、自動車によって提供される音声、視覚的な表示、及びデータ入力機能に相互接続可能な携帯電話を提案している。しかしながら、そのようなシステムは、新しい技術、例えば、新しいセルラー式通信技術が利用可能になった場合、更新することが困難又は不可能である。また、そのようなシステムは、車両において他の場合には利用可能な様々な機能を統合することが不可能であり、これによって情報共有の可能性が制限される。また、そのようなシステムは、通常、特定モデルの携帯電話以外の装置に車両を相互接続する能力を有しない。更に、そのようなシステムは、高価である。
【０００５】
多くの場合、異なる装置に情報を共有させることの困難さは、異なる装置が互換性のないファームウェア又はオペレーティング・システムを用いることが多くあることであった。更に、異なる装置は、異なる通信リンク技術を用いることが多い。従って、装置が互いに通信を行うために、開発者が広範囲にわたる専用コードを先行して計画し、そのような相互運用性を可能とするように提供する必要があった。特に、開発者は、自らの開発の一部として、既知の装置間の相互運用性をサポートするプログラミングを予想し提供することが要求される。従って、そのような他の装置の厳密な動作パラメータの知識が事前に入手可能でない限り、装置を他の装置と相互運用することは不可能であった。また互いの通信を意図した装置には、互換性を有する通信リンク技術を提供することが必要であった。
【０００６】
これらの幾つかの制限を克服するための試みがなされてきた。例えば、コンピュータネットワークは、異なる装置間で情報を交換するために用いられてきた。しかしながら、そのような構成では、個々の装置が、装置それ自体との統合又はその装置用の専用アダプタを用いることを通して、そのネットワークを介した通信に要求される全ての層を提供する必要があった。更に、異なる装置が、情報を共有するために、装置のうちの少なくとも１つの高レベルプロトコルは、他の装置の高レベルプロトコルと適合する必要がある。従って、既存のネットワークを含む通信リンクとの互換性を有するように装置が構成された場合でさえ、情報が交換されるか資源が共有されるときには、依然として装置は１つ又は複数の他の装置の要件に適合する必要がある。例えば、標準の通信プロトコルを用いて相互接続し得る車両の装置の種類を拡張しようという試みがなされてきた。しかしながら、そのようなシステムは、各相互接続される装置が標準のプロトコルに特別に適合する必要があるという問題を解決せず、標準のプロトコルは、全ての相互接続される装置によって要求されるメッセージを含まなければならず、更に、相互接続された装置は、システムによって用いられる通信リンク技術をサポートする必要がある。従って、そのようなシステムは、実現するのに柔軟性がなく高価なままであり、また、システムに付加し得る装置及びそれらの装置の能力に関する予備知識が必要であった。
【０００７】
更なる例として、携帯電話ハンドセット及びデジタル音楽プレーヤ等の移動装置は、物理的な装置サイズ及び必要電力を最小限に維持するために、強制的に小さい表示部及びキーパッドを利用する。しかしながら、新しい世代のこれらの装置は演算能力及びデータ記憶能力を急速に拡大してきている。携帯性の低い又は静止型の演算装置は、より能力の高いキーパッド又は他の入力技術／ファシリティ及びより能力の高い表示装置又は他の出力技術／ファシリティのうちの１つ以上を有し得る。これらのもっと能力がある技術／ファシリティは、車両ダッシュボード「ヘッドユニット」システムの一部である場合、旅客ジェット機の座席の背もたれ内にある場合、居間にあるテレビモニタ又はオーディオシステムである場合、又はユーザのデスクトップ上のパソコンシステムの一部である場合がある。更に、そのような演算装置は、特定の携帯装置から利用不可能な入力、出力又は他のサービスを提供し得る。しかしながら、そのような携帯性の低い又は静止型の演算装置の強化された能力は、すぐ近くの携帯装置にとって、たいてい利用不可能なままである。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は、従来技術のこれらの及び他の問題並びに不利な点の解決に関する。
【課題を解決するための手段】
【０００９】
本発明の実施形態によれば、異なる装置間の相互運用性を可能とするための装置が提供される。そのような装置によれば、中央通信インタフェースシステム（ＣＩＳ）は異なる装置及びアプリケーションがそれら自体のサービスを広告し、他の装置又はアプリケーションのサービスを検索することを可能とする接続フレームワークプロセスを有する。更に、接続フレームワークプロセスがファシリティ又は機構として機能することによって、装置又はアプリケーションは他の装置又はアプリケーションからの要求されたイベントを申込み、受信し得る。
【００１０】
本発明の実施形態によれば、強化された能力を提供するシステムとコンテンツ担持移動装置が交信するようになるとき、移動装置はそれらの能力を発見し、アクセスすることが可能である。例えば、本発明の実施形態により、コンテンツ担持移動装置は、移動装置が通信を行っている別の装置上で利用可能な強化された表示能力を発見し、アクセスすることが可能となる。詳細には、移動装置は他の装置と通信を行い、その装置の能力を発見し、適切な認証及び認可によって、その装置を通して利用可能な強化された表示装置に接続を確立し得る。本発明の実施形態によって、移動装置は表示能力に加えて、例えば、望ま
しい音声能力を含む別の装置から利用可能な任意の強化された能力を利用することが可能となる。
【００１１】
別の装置の強化された表示能力に移動装置がアクセスすることを可能とする本発明の実施形態によれば、携帯装置はＨＴＭＬ等の高度マークアップ言語の形態で表示装置にコンテンツを提供し得る。移動装置によって提供されるコンテンツには、例えば、移動装置に強化された表示能力を提供するシステムの一部として、又はそれと接続した状態で提供されるタッチスクリーンその他の入力装置を通してユーザが操作し得る制御手段が含まれる。移動装置によって提供されるコンテンツのストリームは、移動装置上で動作するアプリケーションによって生成され得る。更に、強化された表示能力を備えたシステム上に表示されるコンテンツに対応する又は関連付けられたコンテンツを携帯装置上の表示装置を用いて表示するように、他の装置へ配信されたコンテンツのストリームが補助出力として生成される。更に他の本発明の実施形態によれば、強化された表示能力を提供するシステムを通して受信されたユーザ入力は、メッセージ又はイベントとして移動装置に送り返される。そして、移動装置は、メッセージ又はイベントにアクセスしたり、受信したりして、それに応じて処理を行う。即ち、移動装置上で動作するアプリケーションは、強化された表示能力を提供するシステムにおいて入力された入力を通して制御され得る。更に他の本発明の実施形態によれば、入力は移動装置それ自体を通してユーザによって入力されてもよい。強化された表示能力を有するシステムに移動装置によって提供されたコンテンツの変更は、ユーザからの入力に応答して、移動装置及び強化された表示装置の双方において更新され得る。更に他の本発明の実施形態によれば、強化された表示能力を提供するシステムによって表示されるコンテンツは、移動装置によって供給されたものに追加してコンテンツを含むように修正又は強化され得る。例えば、ユーザにとって関心の対象であり得る強化されたサービス又は追加のコンテンツのプロバイダに関連したコンテンツは、移動装置からのコンテンツと組み合わせて又は同時に提供され得る。また、本発明の実施形態では、ブラウザ又は他の装置プラットフォームの何らかの他のファシリティによる他の装置プラットフォーム上での実行のために、携帯装置から他の装置プラットフォームに配信される実行可能なスクリプト又はコードが提供される。
【００１２】
また、装置の実施形態は、インタフェースを提供して、複数の異なる通信リンク技術又は通信チャネルを用いる異なる装置がインタフェースシステムと動作可能に相互接続することを可能とする。そのようなインタフェースには、物理的なハードウェア（即ち、標準ネットワーク通信階層モデルの第１層）と、サポートされる又は可能とされる特定の通信リンク技術による必要に応じてリンク層（第２層）、ネットワーク層（第３層）及びトランスポート層（第４層）の機能を提供するソフトウェアツール又はモジュールとの双方が含まれてよい。通信インタフェースシステムによって提供される通信資源は、システムの若しくは装置をシステムに相互接続する通信リンクの特定のインスタンスと接続された状態で利用可能な異なるサービス、他のアプリケーション又は装置の存在に関する事前知識なしで、そのサービス、他のアプリケーション又は装置、情報にアクセスする、又はその情報を取得するために、アプリケーションによって用いられる。その結果、他のアプリケーションと情報若しくはプロセスを共有したり、他のアプリケーション若しくはサービスから利用可能な情報及びプロセスにアクセスしたりすることを望むアプリケーション又はサービスには、そのようなアプリケーションが同じ若しくは異なるプラットフォーム又は装置上で動作するか否かに関わらず、通信インタフェースシステムが理解可能なメッセージに対して高レベルの通信を適合することのみが必要である。詳細には、サービスの広告やイベントへの申込み等の機能を実行するために、本明細書に開示の通信インタフェースシステムの実施形態では、通信インタフェースシステムによって要求されるメッセージを用いることとは別に、必要な場合、サービス又はアプリケーションに要求される又はサービス若しくはアプリケーションの特別な特徴を利用するために要求される特別なメッセージの変換を取り扱うことが可能である。これに代えて、又はこれに加えて、通信インタフ
ェースシステムの実施形態は、ハンドルを提供し、サービスによって提供される生のデータにアプリケーションがアクセスすることを可能とする。
【００１３】
異なる装置、サービス及びアプリケーションにサポートを提供するために、本発明の実施形態に基づく通信インタフェースシステムは、様々なサービスエンジン構成要素を提供し得る。サービスエンジンを用いることによって、サービスエンジンを通してシステムに相互接続される装置に通信インタフェースシステムが１つ又は複数の標準インタフェースを提示することが可能となる。そのようなサービスエンジンにより、相互接続された装置によって業界又は分野標準データフォーマットが利用可能となる。従って、インタフェースシステムと通信を可能とするために、相互接続された装置への修正は不要である。更に、標準データフォーマットと適合しない装置用のアダプタソフトウェアを含むサービスエンジンは、非標準装置に提供され得る。特定の相互接続された装置に合わせて標準化されたサービスエンジン又はインタフェースを提供することによって、インタフェースは、ローカルデータインタフェースのように見える（例えば、プロセス間通信のように見える）。更に、サービスエンジンを通してサービス又はアプリケーションによって要求されるサービス又はアプリケーションレベルメッセージをサポートすることによって、通信インタフェースシステムの無い状態で別個のサービス又はアプリケーションが互いと全く通信不可能な場合にも、サービス又はアプリケーションを通して利用可能な任意の情報又は資源が任意の他のサービス又はアプリケーションに提供され得る。
【００１４】
本発明の更なる実施形態によれば、通信インタフェースシステムは、第２通信フレームワークプロセスを提供する装置にインタフェース接続され得る。従って、各々本発明の実施形態に基づく通信フレームワークプロセスを動作させる複数の装置は、互接続されたハブとして動作し得る。
【発明を実施するための最良の形態】
【００１５】
図１Ａは、本発明の実施形態に基づく通信システム１００の構成要素を示すブロック図である。一般的に、通信システム１００には、家庭、自動車、職場、又は他の環境に用い得る及び／又はそれら用に特別に構成されるプラグ・アンド・プレイのテレマティクス制御ユニット又は通信インタフェースシステム（ＣＩＳ）１０４が含まれる。図１Ａに示すように、ＣＩＳ１０４は、電話、スマートホン、セルラー電話、携帯情報端末、メディアプレーヤ、デジタルカメラ、又は他の携帯装置等の携帯装置１０に相互接続し得る。更に、ＣＩＳ１０４は、１つ又は複数のアクセサリ１４に相互接続し得る。アクセサリの例には、ブルートゥース（登録商標）又はＷｉＦｉ（登録商標）インタフェース、メモリ、全地球測位システム（ＧＰＳ）装置、磁気カード読取り機、モニタ、又は他のアクセサリ装置を含む無線通信装置が挙げられる。アクセサリ１４がインタフェースである場合、これは、モジュール式の携帯装置ポート又は他の種類のポート１１０として機能し得る。また、ＣＩＳ１０４の実施形態は、車両電子回路１０８に相互接続し得る。例えば、ＣＩＳ１０４は、計器盤、ヘッドユニット、カーラジオ、埋め込み式電子制御ユニット、又は他の車両電子回路に相互接続して、車両１０８に関連付けられた情報及びアプリケーションへのアクセス又はそれらの制御を行い得る。ＣＩＳ１０４の実施形態は、それら自体、携帯であってよい。従って、ＣＩＳ１０４は、ドッキングステーション１８に相互接続し得る。ドッキングステーション１８は、例えば、ユーザの家庭及び／又は職場に配置してよく、また、それ自体、スピーカホン、ジュークボックス、電波時計、映像画面、又は他の装置を含み得る。従って、ＣＩＳ１０４は多種多様な電子装置に動作可能に相互接続し得ることが認識できる。更に、そのような相互接続を用いて、ＣＩＳ１０４上で動作する若しくはそれに関連付けられたアプリケーション間、又は、装置１０、アクセサリ１４、ドッキングステーション１８、若しくは車両電子回路１０４等の様々な相互接続された構成要素間において、情報を共有又は取得し得る。更に、ＣＩＳ１０４に相互接続される様々な携帯装置１０、アクセサリ１４、車両電子回路１０８又はドッキングステーション１８の
うちの１つ又は複数には、遠隔プラットフォームを含み得る。
【００１６】
ＣＩＳ１０４に相互接続される様々な構成要素に関しては、異なるポートを提供し得る。例えば、携帯装置ポート１１０は、ＣＩＳ１０４を１つ又は複数の携帯装置１０に相互接続するために用い得る。携帯装置ポート１１０と接続した状態で用いられる通信リンク技術の例としては、ユニバーサル・シリアル・バス（ＵＳＢ）、簡易シリアル・ポート（例えば、ＲＳ−２３２／ＲＳ−４２２）、ＩＥＥＥ１３９４、アナログ又はデジタル音声、ブルートゥース、ＩＥＥＥ８０２．１１、例えば、ローカルエリアネットワーク、ワイドエリアネットワーク及び／又は広帯域バージョン等で、例えば、ＷｉＦｉ、ＷｉＭａｘ及びＷｉＭｏｂｉｌｅ（ＩＥＥＥ８０２．１１）、超広帯域（ＵＷＢ）等、小型フラッシュスロット、セキュリティ保護されたデジタルスロット又は他のメモリカードスロット、イーサネット（登録商標）、又は他の通信リンク技術が挙げられる。アクセサリポート１１１は、ＣＩＳ１０４にアクセサリを相互接続するために提供し得る。アクセサリポート１１１に関連した用途に適する通信リンク技術には、ＵＳＢ、簡易シリアル・ポート、ＩＥＥＥ１３９４、アナログ又はデジタル音声、ＵＷＢ、小型フラッシュスロット、セキュリティ保護されたデジタルスロット又は他のメモリカードスロット、ブルートゥース、ＩＥＥＥ８０２．１１、イーサネット又は他の通信リンク技術が含まれる。車両１０８に関連付けられた電子回路に相互接続するための車両インタフェースポート１１２には、媒体指向システムトランスポート（ＭＯＳＴ；Ｍｅｄｉａ  Ｏｒｉｅｎｔｅｄ  Ｓｙｓｔｅｍｓ  Ｔｒａｎｓｐｏｒｔ）システム、コントローラ・エリア・ネットワーク（ＣＡＮ）、ＩＤＢ−Ｍ（１３９４）又は他のインタフェースを含み得る。ドッキングステーションポート１１３は、ＵＳＢ、簡易シリアル・ポートＩＥＥＥ１３９４、イーサネット、アナログ又はデジタル音声、ブルートゥース、ＩＥＥＥ８０２．１１、ＵＷＢ、又は他の通信リンク技術を用い得る。本明細書において提供される説明から当業者には認識されるように、ＣＩＳ１０４によって提供される特定のポート１１０〜１１３は、ＣＩＳ１０４の意図した使用方法又は特徴レベルを考慮して選択し得る。更に、ポート１１０〜１１３の複数のインスタンスを提供し得る。更に、単一のポート１１０〜１１３は、複数のポートタイプを含んでよく、また、複数の相互接続された装置、アクセサリ、又は他の構成要素１０〜１８又は１０８をサポートし得る。例えば、単一のＵＳＢポートは、１つ又は複数の携帯装置１０、１つ又は複数のアクセサリ１４、又は１つ又は複数のドッキングステーション１８等の様々な構成要素に相互接続し得る。
【００１７】
図１Ｂには、本発明の実施形態に基づく通信システム又は装置１００の代表的な状況を示す。図１Ｂに示す通信システム１００の本例において、通信インタフェースシステム（ＣＩＳ）１０４は、有線の車両特定インタフェース、即ち、車両インタフェースポート１１２を通して、車両電子回路１０８に相互接続される。一般的に、通信インタフェースシステム１０４は、本明細書の別の箇所において更に詳細に述べるように、通信フレームワークプロセスを特徴とする通信環境１１４を提供するプラットフォームである。図１Ｂに示す通信インタフェースシステム１０４は、機械的なアダプタ又はポケットアダプタ１１６を通信インタフェースシステム１０４に相互接続させる汎用ポートが含まれる携帯装置ポート１１０（図１Ａ参照）を提供する。ポケットアダプタ１１６は、やはり通信インタフェースシステム１０４によって提供される通信フレームワークプロセスを動作させる携帯電話１２４ａが含まれる携帯装置１０等の遠隔プラットフォーム１２０を受け入れ得る。これに代えて、ポケットアダプタ１１６は、非通信フレームワークプロセス使用可能携帯電話１２４ｂが含まれる携帯装置１０を受け入れ得るが、この場合、通信フレームワークプロセスは、ポケットアダプタ１１６によって提供し得る（その製品適用には、遠隔プラットフォーム１２０を含み得る）。更にこれに代えて、非通信フレームワークプロセス使用可能電話１２４ｂが含まれる携帯装置１０は、本明細書の別の箇所において述べるように、サービスエンジンを通して通信インタフェースシステム１０４と通信を行い得る。
【００１８】
図１Ｂに示す本例の通信システム１００は、通信インタフェースシステム１０４から車両１０８に標準車両メッセージを渡すことを可能にし、また、電話１２４が、車両電子回路１０８を通して利用可能なサービス、情報又は資源（以下、サービス）にアクセスすることを可能にする。また、構成１００は、電話１２４に標準メッセージを渡すことを可能にする。しかしながら、ＣＩＳ１０４を用いる車両へのそのような通信リンクは、ホルダ又は受け台で支持される電話１２４に限定されない。従って、本発明の実施形態に基づくシステム１００は、携帯又は埋め込まれた装置１０，１４を車両１０８にインタフェース接続させ、車両電子回路１０８又は装置１０，１４が他の相互接続された装置と直接インタフェース接続する必要がない。
【００１９】
特に、接続フレームワークプロセスを提供することによって、通信インタフェースシステム及び／又は通信インタフェースシステム１０４上で動作するアプリケーションに相互接続される装置は、サービスを広告し得る。これらの通信インタフェースシステム常駐サービスは、通信インタフェースシステム１０４、ＣＩＳ１０４から離れた若しくはＣＩＳ１０４とは別のプラットフォーム１２０（電話１２４等）、車両１０８その他、接続フレームワークプロセス共有プロトコルをサポートする任意のプラットフォーム上で動作するか、それらに相互接続される他のアプリケーションによって用いられ得る。同様に、電話１２４ａ等の遠隔演算プラットフォーム１２０上で動作する又はそれを通して利用可能なサービスは、通信インタフェースシステム１０４常駐アプリケーション又は他のプラットフォームに常駐するアプリケーションによってサービスが利用されるように広告し得る。従って、図１Ｂに示す本例におけるテレマティクスアプリケーション等の分散アプリケーションを含む、アプリケーション及び／又はサービス間の通信を標準化するファシリティを提供することによって、本発明の実施形態は、装置とアプリケーションとの間のネットワーク効果を生み出し、個々の装置及びアプリケーションに価値を付加し得る。
【００２０】
サービスは、アプリケーション等、装置又は任意の資源に関連付けられた任意の情報発信源に関連し得る又はそれを用いて提供し得る。サービスの例としては、高度なディスプレイ、ユーザインタフェース、デジタル又はアナログメディアプレーヤ、電力／充電、ステレオ音声機能、全地球測位システム（ＧＰＳ）装置データ、車載車両診断プログラムデータ（ＯＢＤ−ＩＩ等）、テキスト−音声（ＴＴＳ）エンジン、音声認識エンジン、音声ベースのユーザインタフェースファシリティ、携帯電話（埋め込み式、携帯及び／又はプラグ・アンド・プレイ）又は他の通信装置、及び携帯情報端末（ＰＤＡ）が挙げられる。
【００２１】
次に、図２において、図１Ａ又は１Ｂの通信システム１００等の通信構成に含まれる構成要素のソフトウェアとハードウェア要素との間の関係を示す。図２において分かるように、アプリケーション及びサービス２０４は、通信インタフェースシステム１０４上で動作し得る。特に、アプリケーション及びサービス２０４は、オペレーティング・システム２０８と、また、接続フレームワークプロセス２１０のアプリケーション・サービスインタフェース２１２の機能と直接対話する。アプリケーション・サービスインタフェース２１２は、通信インタフェースシステムメッセージ（又は制御メッセージ）２１６を利用し、また、接続フレームワークプロセス２１０によって提供される接続インタフェースシステムサービス２２０へのアクセスを提供する。本発明の実施形態によれば、接続フレームワークプロセス２１０は、インターネットプロトコル（ＩＰ）、伝送制御プロトコル（ＴＣＰ）、ユニバーサル・データグラム・プロトコル（ＵＤＰ）、及び任意の汎用プラグ・アンド・プレイ装置（１つ又は複数）を用いる他のプロトコル（１つ又は複数）等の様々なプロトコルをサポートする。更に、本発明の実施形態には、マルチスレッド処理及び／又はマルチタスク処理をサポートし、また、アプリケーションがシステム資源を破壊するのを防止する保護機構が含まれるオペレーティング・システム２０８を含み得る。また、オペレーティング・システム２０８は、プロセス間通信（ＩＰＣ）用の携帯オペレーティング・システムインタフェース（ＰＯＳＩＸ）準拠の機構を提供し得る。
【００２２】
図２に示す本例構成において、遠隔プラットフォーム１２０は、接続フレームワークプロセス２１０の使用可能な電話１２４である。図２に示すように、遠隔プラットフォーム１２０の一部として提供される又はそれらに関連付けられたアプリケーション及びサービス２２４は、遠隔プラットフォームのオペレーティング・システム２２８と直接対話し、接続フレームワークプロセス２１０のアプリケーション・サービスインタフェース２３２への直接のアクセスを有する。遠隔プラットフォーム１２０のアプリケーション・サービスインタフェース２３２は、通信インタフェースシステムメッセージ２１６を利用し、また、接続インタフェースシステムサービス２３６を利用可能にする。本明細書において提供される説明から当業者には認識されるように、遠隔プラットフォーム１２０（即ち、電話１２４）上で動作する接続フレームワークプロセス２１０及び関連する機能２３２，２３６は、通信インタフェースシステム１０４上で動作するものと全く同じである必要はない。本発明の実施形態に関連して、遠隔プラットフォーム１２０上のオペレーティング・システム２２８は、通信インタフェースシステム１０４上で動作するオペレーティング・システム２０８と同じ又は同様な能力を提供し得る。
【００２３】
図２に示すように、通信インタフェースシステム１０４と接続フレームワークプロセスの使用可能な遠隔プラットフォーム１２０とによって用いられる通信インタフェースシステムメッセージ２１６は、全く同じであってよい。即ち、一組のメッセージが定義されてよい。本明細書の別の箇所において更に詳細に述べるように、通信インタフェースシステムメッセージ２１６を用いて、装置及びアプリケーションは、サービスを広告し、それに申し込み（ｓｕｂｓｃｒｉｂｅ）得る。特定のサービスを識別し、それにアクセスするための機構を提供することに加えて、アプリケーション・サービスインタフェース２１２，２３２によって提供される接続インタフェース機能と、接続インタフェースシステムサービス２２０，２３６と、通信インタフェースシステムメッセージ２１６とは、ネットワーク層２４０，２４２及びハードウェア層又は物理層２４４，２４６を制御し、これによって、アプリケーション及びサービス２０４，２２４は、通信インタフェースシステムメッセージ２１６を用いて及び／又はより高レベルの他のプロトコルを用いて、互いに通信を行うことができる。例えば、本発明の実施形態によれば、ネットワーク通信階層モデルの第１層〜第４層は、通信インタフェースシステム接続フレームワークプロセス２１０によって、また、通信インタフェースシステム１０４に接続された遠隔装置１２０（例えば、電話１２４）の接続フレームワークプロセス２１０（存在する場合）によって提供される機能及びサービスによって対応される。本明細書の別の箇所において更に詳細に述べるように、プラットフォーム間の通信リンクのネットワーク層及び物理層の制御は、インタフェースエンジンを組み込む通信インタフェースを用いて達成し得る。
【００２４】
図２に示すように、通信インタフェースシステム１０４は、自動車の電子回路の一部であってもよく、それに相互接続していてもよい。従って、本発明の実施形態は、車両にインストールされるシステム１００の一部として配備し得る。更に、図２に示すように、遠隔プラットフォーム１２０には、それら自体は特定の車両用途に設計されたり特別に適合されたりしていない装置１０又はアクセサリ１４を含む民生電子回路を含み得る。本明細書の別の箇所において更に詳細に述べるように、通信インタフェースシステム１０４は、車両の電子回路系への相互接続に加えて、又はそれに代えて、有線又は無線接続を通して、装置及び／又はアプリケーションに相互接続し得る。更に、図２の電話１２４等の通信フレームワークプロセスを提供する遠隔プラットフォーム１２０が含まれる場合、装置及びアプリケーションは、遠隔プラットフォーム１２０に相互接続し得る。従って、通信インタフェースシステム１０４及び相互接続された遠隔プラットフォーム１２０（電話１２４等）は、相互接続された通信ハブとして機能し得る。
【００２５】
次に、図３において、本発明の実施形態に基づく通信インタフェースシステム１０４の
一部として含み得る様々なハードウェア構成要素を示す。一般的に、通信インタフェースシステム１０４には、オペレーティング・システムソフトウェア２０８と、アプリケーション及び関連するサービス２０４を含むアプリケーションソフトウェアとを動作させることが可能なプロセッサ３０４を含み得る。更に、プロセッサ３０４は、通信サービスインタフェース２１２、通信インタフェースシステムサービス２２０、及び通信インタフェースシステムメッセージ２１６の機能を含む、インストールされた接続フレームワークプロセス２１０の動作に関連して命令を実行する。本発明の実施形態によれば、プロセッサ３０４には、プログラム可能な汎用プロセッサ又はコントローラを含み得る。
【００２６】
メモリ３０８は、オペレーティング・システム２０８、アプリケーション２０４、通信フレームワークプロセス２１０並びに通信サービス及びメッセージプログラム２１２〜２２０を記憶するために、また、そのようなアプリケーション及びプログラムの動作に関連するデータを記憶するために提供し得る。メモリ３０８には、様々な記憶装置を単体で又は組み合わせて含み得る。例えば、メモリ３０８には、ＤＲＡＭ若しくはＳＤＲＡＭ、磁気記憶装置、又は光学記憶装置等のソリッドステートメモリを含み得る。更に、メモリ３０８は、全体的に又は部分的にプロセッサ３０４に統合し得る。例えば、本発明の実施形態によれば、プロセッサ３０４及びメモリ３０８は、ファームウェアとして記憶されたオペレーティング・システム２０８、アプリケーション２０４、通信フレームワークプロセス２１０並びに通信サービス及びメッセージ２１２〜２２０プログラムとの統合されたコントローラとして実現し得る。ファームウェアとして維持されるプログラムを有する実施形態を含む本発明の実施形態に関連して、フラッシュメモリ又は他の再構成可能なメモリ装置３０８を提供し、サポートされるサービス及び装置の拡張を可能にし、また、ソフトウェアの更新及びパッチを簡易化することは優位な点である。
【００２７】
通信インタフェースシステム１０４には、更に、複数のインタフェースが含まれる。例えば、通信インタフェースシステム１０４が車両にインストールされる実施形態に関連して、車両インタフェース３１２を提供し得る。車両インタフェース３１２は、車載ネットワーク等の車載車両システムへの物理的な接続を提供する。更に、車両インタフェース３１２は、車両から受信された又は車両へ配信された命令の必要なフォーマット処理を提供する。一例として、車両インタフェース３１２には、コントローラ・エリア・ネットワーク（ＣＡＮ）インタフェースを含み得る。本発明の代表的な一実施形態において、車両インタフェース３１２は、ドーターボードとして提供し得る。他の実施形態によれば、車両インタフェース３１２は、通信インタフェースシステム１０４と統合される又はそれに含まれる。更に、通信インタフェースシステム１０４には、複数の異なる車両システムサービス又はネットワーク用の車両インタフェース３１２を含み、例えば、単一の車両に含まれる複数のシステムとの同時接続を可能にし得る。
【００２８】
更に、通信インタフェースシステム１０４には、電話インタフェース３１６を含み得る。アダプタ３２０は、電話インタフェース３１６と関連付けて、相互接続された電話（例えば、電話１２４）への必要な物理的接続を提供し得る。従って、アダプタ３２０には、通信インタフェースシステム１０４と電話１２４との間の電気的な相互接続を提供するためのコード及び／又は電話への電気的な相互接続を提供するための、また、電話１２０若しくは１２４を物理的に所定の位置に保持するためのポケットタイプアダプタを含み得る。異なる電話１２４用に構成されたアダプタ３２０を提供することによって、多種多様な電話構成に対応し得る。これに代えて、電話インタフェース３１６は、アダプタ３２０を用いることなく、電話１２４に直接相互接続し得る。
【００２９】
通信インタフェースシステム１０４には、更に、１つ又は複数の有線インタフェース３２４を含み得る。図３には３つの異なる有線インタフェース３２４ａ〜ｎを示すが、任意の数の有線インタフェース３２４を提供し得ることが認識される。提供し得る有線インタ
フェース３２４の例としては、ユニバーサル・シリアル・バス（ＵＳＢ）、ＩＥＥＥ１３９４、ＲＳ−２３２、高度道路交通システムデータバス（ＩＤＢ）、コントローラ・エリア・ネットワーク（ＣＡＮ）、イーサネット、媒体指向システムトランスポート（ＭＯＳＴ）システム又は他の有線インタフェースが挙げられる。電気信号を交換するためのそのようなインタフェースに加えて、有線インタフェース３２４には、更に、光通信を可能にするためのインタフェースを含み得る。有線インタフェース３２４は、一般的に、通信インタフェースシステム１０４を装置、ネットワーク又は遠隔プラットフォーム１２０に相互接続し得る。
【００３０】
本発明の実施形態に基づく通信インタフェースシステム１０４には、更に、複数の無線インタフェース３２８を含み得る。図３には３つの無線インタフェース３２８ａ〜ｎを示すが、任意の数の無線インタフェース３２８を提供し得ることを認識すべきである。無線インタフェース３２８の例としては、ブルートゥース、超広帯域（ＵＷＢ）、例えば、ＩＥＥＥ８０２．１１ａ、８０２．１１ｂ、及び８０２．１１ｇ等のＷｉＦｉ、例えば、ＩＥＥＥ８０２．１５．３ａ、ＣＤＭＡ２０００等のパーソナル・エリア・ネットワーキング、及びＤＡＴＡＴＡＣ、ＧＳＭ／ＧＰＲＳ／ＥＤＧＥ、ＵＭＴＳ、Ｍｏｂｉｔｅｘ又は強化統合デジタルネットワーク（ｉｎｔｅｇｒａｔｅｄ  ｄｉｇｉｔａｌ  ｅｎｈａｎｃｅｄ  ｎｅｔｗｏｒｋ）インタフェースが挙げられる。無線インタフェース３２８は、一般的に、通信インタフェースシステム１０４を装置、ネットワーク又は遠隔プラットフォーム１２０に相互接続し得る。
【００３１】
当業者には認識されるように、有線インタフェース３２４及び無線インタフェース３２８は、様々な通信プロトコルに関連して動作し又はそれらを組み込み得る。そのような通信プロトコルの例としては、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）及びユニバーサル・データグラム・プロトコル（ＵＤＰ）が挙げられる。更に、有線インタフェース３２４又は無線インタフェース３２８には、ポート１００，１１１，１１２及び１１３のうちの１つ以上を含み得る。
【００３２】
次に、図４において、複数の装置に連動して相互接続される通信インタフェースシステム１０４のブロック図を機能ブロック図で示す。一般的に、接続フレームワークプロセス２１０は、通信インタフェースシステム１０４の中央プロセス又はシステムである。接続フレームワークプロセス２１０は登録されたサービスを分類整理し、イベントを取り扱い、利用可能なサービス及び情報に関する情報の同期化を制御する。これに代えて、又はこれに加えて、イベント取り扱い及び情報の同期化は、オペレーティング・システム２０８，２２８から利用可能なファシリティによって取り扱われ得る（図２参照）。
【００３３】
接続フレームワークプロセス２１０は、装置又はアプリケーションから利用可能なサービスを、接続フレームワークプロセス２１０に関連する他の装置又はアプリケーションに広告するためのサービステーブル４０４を提供する。サービスエンジン等のアプリケーションは、接続フレームワークプロセス２１０の一部として提供されるサービスインタフェースを用いて、サービスを広告したり、又は、クライアントアプリケーションにサービス状態及び利用可能性の変更について助言し得る。サービス及びアプリケーションは、他のサービス又はアプリケーションからそれらに利用可能な情報及び資源を、接続フレームワークプロセス２１０の一部として提供されるクライアントインタフェースを用いて、サービステーブル４０４を参照することによって発見し得る。従って、サービステーブル４０４は、サービス及びサービス記述子のレジストリ、それらのサービスへアクセスする場合に用いられる機能、現在のサービス状態、サービスにアクセスするために必要な権限、あらゆる関連する装置のクラス及び性能基準及び利用可能なサービスに関する他の情報を含み得る。更に、「サービス」は、アプリケーション４２２、装置４２０、又は１つ又は複数のアプリケーション及び装置の組合せを含み又はそれらによって提供され得ることを認
識すべきである。例えば、ナビゲーションサービスが含まれるサービスは、ＧＰＳ受信機４２０ａ、関連するＧＰＳサービスエンジン４１６ａ、及びマッピングアプリケーション４２２によって提供し得る。更に、一定の例は、装置４２０、固有のファシリティ、サービスエンジン４１６、及び／又は通信インタフェースシステム１０４上で動作するアプリケーションを通して、遠隔プラットフォーム１２０及び／又は遠隔プラットフォーム上で動作するアプリケーション４２２に提供されるサービスを説明するが、本発明の実施形態は、そのように限定されない。例えば、サービスは、遠隔プラットフォーム１２０によって他の遠隔プラットフォーム１２０に又は通信インタフェースシステム１０４に提供されてよい。更なる一例として、１つのプラットフォーム１０４，１２０上のサービス又はそれらのプラットフォームを通して提供されるサービスは、別のプラットフォーム１０４，１２０上のサービス又はそれらのプラットフォームを通して提供されるサービスと協働して動作し得る。
【００３４】
更に、接続フレームワークプロセス２１０は、イベントテーブル４０８を用いて、イベント申し込み及び通知方式をサポートする。特に、接続フレームワークプロセス２１０によってサポートされるイベント方式は、イベントが起こる場合、アプリケーション固有イベントオブジェクトの出力を提供する。１つ又は複数の他の実施形態において、接続フレームワークプロセス２１０の代わりに、根底にあるＯＳ（オペレーティング・システム）は、イベントテーブル４０８を通してイベントオブジェクトを提供し得る。一般的に、これらのイベントオブジェクトは、データ及び／又は実行可能な機能に対する参照を含む。イベントテーブル４０８は、イベント及び各イベントに申し込まれたプロセスのリストを含む。イベントが起こる場合、接続フレームワークプロセス２１０は、イベントに関して通知されるプロセスの有無についてイベントテーブル４０８をチェックする。必要条件をそなえたサービス及びアプリケーション（即ち、充分な権限を備えたサービス及びアプリケーション）は、イベントを生成し受信するために登録することが許される。テーブルにアクセスするアプリケーションは、一般的に、イベントの受信に登録するために、一組の所定のメッセージ（即ち、通信インタフェースシステムメッセージ２１６）を用いる。
【００３５】
また、接続フレームワークプロセス２１０は、サービス開始テーブル４１０を提供し得る。一般的に、サービス開始テーブル４１０は、サービスエンジンに関する情報を含む。そのような情報には、それらが起動時に開始されるか又は他のサービスエンジン若しくはアプリケーションからの要求及び他の情報に応じて開始されるか否かにかかわらず、ローカルサービスエンジン及びアプリケーションの実行可能なファイルが含まれ得る。
【００３６】
接続フレームワークプロセス２１０の一部として又はそれによって提供される通信プロセスランタイムサービス／イベントインタフェース４１２は、サービスの広告及びサービスの発見を制御する。更に、通信プロセスランタイムサービス／イベントインタフェース４１２は、イベントへの申込み及びイベントの一斉送信に関連して、サービス及びアプリケーションによって用いられる。一般的に、接続フレームワークプロセス２１０は、通信ランタイム呼出しとして通信プロセスランタイムサービス／イベントインタフェース４１２から受信されたイベント申し込みをイベントテーブル４０８に記録し得る。アプリケーション（又はサービスエンジン）がイベントを生成する場合、再度、通信プロセスルーチンサービス／イベントインタフェース４１２を介して中継された通信ランタイム呼出しを通して、接続フレームワークプロセス２１０は、イベントテーブル４０８をチェックし、イベントについて各加入者に通知する。サービスエンジン及びアプリケーション双方は、イベントに申込みし得る。従って、通信ランタイムサービス／イベントインタフェース４１２を通して行われる通信ランタイム呼出しを提供することによって、また、サービステーブル４０４及びイベントテーブル４０８を提供することによって、接続フレームワークプロセス２１０は、クライアントインタフェース及びサービスインタフェースと接続した状態で、要求されたサービスを分類整理し、サービス配信の同期化を行い、イベントを取
扱い、そして、あらゆる他の接続されたアプリケーション又は資源と利用可能なサービスに関する情報との同期化を制御することができる。従って、通信インタフェースシステム１０４上で動作する接続フレームワークプロセス２１０は、通信インタフェースシステム１０４の中央プロセスとして機能することが認識される。
【００３７】
更に、１つ又は複数のサービスエンジン４１６（例えば、サービスエンジン４１６ａ〜ｃ）は、サービスを利用可能にする様々なローカルに接続された装置４２０を、通信ランタイムサービス／イベントインタフェース４１２を通して接続フレームワークプロセス２１０に、また、クライアントアプリケーションにインタフェース接続するために提供し得る。本発明の更なる実施形態によれば、サービスエンジン４１６は、クライアントアプリケーションを接続フレームワークプロセス２１０に、また、サービスに、ポートの連携又は支援の有無に関わらず、インタフェース接続し得る。例えば、ＧＰＳ受信機４２０ａ、車載車両診断プログラムＩＩ（ＯＢＤ−ＩＩ）インタフェース４２０ｂ、又はいずれか他の装置４２０ｃは、車両通信バス１１２とのポート若しくはインタフェースによって又はポート若しくはインタフェース（例えば、ポート１１０，１１１，１１３。図１Ａ参照）を通して装置４２０との直接相互接続によって等提供される直接相互接続を通して通信インタフェースシステム１０４に相互接続し得る。一般的に、サービスエンジン４１６は、相互接続されたサービスを用いて、アプリケーション用の標準インタフェースを提示する。従って、サービスエンジン４１６は、サービス４２０を提供する相互接続されたサービス又は装置によって用いられるメッセージ若しくはデータフォーマットのメッセージを、接続フレームワークプロセス２１０及び通信ランタイムサービス／イベントインタフェース４１２のメッセージ及びメッセージフォーマット又はプロトコルに、適合又は変換するアダプタソフトウェアとして機能し得る。また、サービスエンジン４１６は、アプリケーション固有メッセージを接続フレームワークプロセスの及び／又はクライアントアプリケーションのフォーマット又はプロトコルにフォーマット化し得る。サービスエンジン４１６に加えて、様々なローカルアプリケーション４２２が、通信インタフェースシステム１０４上で動作し得る。
【００３８】
通信インタフェースシステム１０４は、更に、標準化された通信インタフェース４２４を提供し得る。一般的に、標準化された通信インタフェース４２４は、通信インタフェースシステム１０４に遠隔的に接続された装置上においてサービスへのアクセスを提供する。本明細書の別の箇所において更に詳細に述べるように、標準化された通信インタフェース４２４は、アプリケーション（例えば、ローカルアプリケーション４２２又はローカルに接続された装置４２０を通して提供されるサービス）を、遠隔装置によって提供されるサービスにアクセスさせ、また、サービスを遠隔アプリケーションに提供させる。一般的に、通信インタフェース４２４は、通信技術固有のアドレスをネットワーク標準化サービスパイプ又はチャネルにマッピングする。通信チャネルを確立するために用い得る通信技術の例としては、ＴＣＰ／ＵＤＰ、ＵＳＢ、及び簡易シリアル・ポートが挙げられる。通信インタフェース４２４を通して通信チャネルを確立し得る他の通信技術の例としては、コントローラ・エリア・ネットワーク（ＣＡＮ）バス又は媒体指向システムトランスポート（ＭＯＳＴ）バスが挙げられる。通信インタフェース４２４を通してサービスパイプ又は通信チャネルにアクセスすることによって、アプリケーションは、一定の同じやり方でローカル及び遠隔サービスにアクセスすることが可能である。従って、サービス固有機能にとっては、標準化されたインタフェース４２４は、インターネット「ソケット」インタフェースと極めて似通って見える。更に、本明細書において提供される説明から認識されるように、通信インタフェースには、１つ又は複数のポート１１０〜１１２（図１Ａ参照）の特徴を含み又は組み込み得る。
【００３９】
次に、図５において、本発明の実施形態に基づくサービス初期化プロセスを示す。最初に、ステップ５００において、通信インタフェースシステム１０４は、例えば、システム
がオンになると初期化を行う（即ち、起動する）。そして、接続フレームワークプロセス２１０は、サービス開始テーブル４１０を点検する（ステップ５０４）。ステップ５０８において、「起動時開始」の値を有するサービスが、接続フレームワークプロセス２１０によって見つけられたか否かに関して判断を行う。サービス開始テーブル４１０において、「起動時開始」値のサービスが見つけられた場合、サービスエンジン４１６その他、それらのサービスに関連するアプリケーションが開始される（ステップ５１２）。そして、サービス状態又は確立メッセージが、開始された各サービスによって接続フレームワークプロセス２１０に返され、各サービスに対してサービス制御チャネルが確立される（ステップ５１６）。返信として、接続フレームワークプロセス２１０は、開始された各サービスに初期化メッセージを送信する（ステップ５２０）。そして、サービス又は複数のサービスが、初期化を行い、接続フレームワークプロセス２１０との接続性を検証する（ステップ５２４）。そして、各サービスは、「投稿サービス」メッセージを接続フレームワークプロセス２１０に送信して、サービステーブル４０４でのリスト化のために、そのサービスによって提供されるサービスを報告する（ステップ５２８）。
【００４０】
「投稿サービス」メッセージが送信された後、又は、「起動時開始」値を備えたサービスがサービス開始テーブル４１０にリスト化されていないと判断された後、サービスが要求されたか否かに関して判断を行う（ステップ５３２）。例えば、サービスは、関連装置４２０が開始されるのに応じて、通信インタフェースシステム１０４それ自体の開始後に開始して、クライアントアプリケーション４２２からの要求その他、ポケットアダプタ１１６への電話１２４の接続等の何らかのイベントを受信し得る。サービスが要求された場合、プロセスは、ステップ５１２に戻り、呼び出されたサービスを開始し、関連付けられたサービスをサービステーブル４０４に入力する。
【００４１】
サービスが要求されていないと判断されると、通信インタフェースシステム１０４が電源遮断されているか否かに関して判断を行う（ステップ５３６）。通信インタフェースシステム１０４が電源遮断されていない場合、プロセスは、ステップ５３２に戻り得る。通信インタフェースシステム１０４が電源遮断されている場合、プロセスは終了する。
【００４２】
次に、図６において、本発明の実施形態に基づくサービス登録プロセスを示す。特に、接続フレームワークプロセス２１０とサービスエンジン４１６との間のメッセージの交換を例示した。最初に、接続フレームワークプロセス２１０は、要求されたサービスエンジン４１６に呼出しサービスメッセージを送信する（ステップ６００）。一般的に、呼出しメッセージは、サービスエンジンを開始又はそれにアクセスするのに必要な任意のアクションであってよい。これに代えて、呼出しメッセージは、他のサービスエンジンによって又はクライアントアプリケーション等、他のアプリケーションによって、サービスエンジン４１６に送信し得る。呼出しサービスメッセージには、呼出しキーが含まれ、これは、呼出しサービスメッセージの命令ライン上で送り得る。本明細書において提供される説明から当業者には認識されるように、呼出しメッセージは、システム起動時、サービスが必要である時、又はクライアントアプリケーションが開始する時など、様々な時に送信し得る。
【００４３】
呼出しメッセージに応答して、サービスエンジン４１６は、確立メッセージを返す（ステップ６０４）。サービスエンジン４１６がどのようにして呼び出されたかにかかわらず、接続フレームワークプロセス２１０へのその最初の通信（即ち、確立メッセージ）は、接続フレームワークプロセス２１０の主制御チャネル又はパブリック制御チャネルを介して送信される。サービスエンジン４１６によって返された確立メッセージは、接続フレームワークプロセス２１０によって提供された呼出しキーを含み、また、更なる通信に関連して用いられるサービス制御チャネルを識別する。
【００４４】
そして、接続フレームワークプロセス２１０は、ＨｉＹａメッセージを返し、サービスエンジン４１６によって生成されたサービス制御チャネルを介して通信を確立する（ステップ６０８）。専用のサービス制御チャネルの確立に続き、その専用のチャネルを介して、接続フレームワークプロセス２１０とサービスエンジン４１６との間の後続の通信が起こる。
【００４５】
また、サービス制御チャネルの確立に続き、セキュリティメッセージを交換し得る（ステップ６１２）。一実施形態において、そのようなセキュリティ関連対策は、２００４年１月２８日に出願され、本出願の譲受人に譲渡され、また、その全体を本明細書において引用・参照する米国特許出願第１０／７６７，５４８号、表題「セキュリティ保護されたテレマティクス（Ｓｅｃｕｒｅ  Ｔｅｌｅｍａｔｉｃｓ）」のシステム及び／又は方法の少なくとも一部を用いて実現し得る。一般的に、セキュリティメッセージには、認可及び認証サービスプロトコルを含み得る。例えば、セキュリティプロトコルにより、接続フレームワークプロセス２１０は、サービスエンジン４１６に関連するサービスへのアクセスを要求するアプリケーションの識別を検証し、また、アプリケーションがそのサービスへのアクセスを認可されていることを検証し得る。データセキュリティを提供することに加えて、そのような手順は、装置、サービス及び／又はアプリケーション相互運用性に関するライセンス協定を実現することに関連しても用い得る。
【００４６】
サービスエンジン４１６は、それを通して利用可能なサービスを、投稿サービスメッセージを接続フレームワークプロセス２１０に送信することによって、接続フレームワークプロセス２１０に投稿し得る（ステップ６１６）。投稿サービスメッセージの一部として提供されるサービス記述情報及び識別子を用いて、接続フレームワークプロセスは、適合するサービスの有無についてサービステーブル４０４を調査する。適合するものがない場合、接続フレームワークプロセスは、新しいサービスＩＤを割り当て、サービス記述情報をサービステーブル４０４に入力し、投稿メッセージ確認応答においてこの新しいサービスＩＤを返す（ステップ６２０）。投稿されたサービスと既にサービステーブル４０４に入力されたサービスとが合致する場合、接続フレームワークプロセス２１０は、投稿メッセージ確認応答において、サービスエンジン４１６に既存のサービスＩＤを返す。この照合機能を実施することによって、接続フレームワークプロセス２１０は、サービスＩＤがユニークであること、また、サービステーブル４０４に含まれる複製のサービス広告が存在しないことを保証する。例えば、サービスエンジン４１６が再開される場合、又は、オンデマンドサービスエンジン４１６の開始によって提供されるサービスに関連して、対応する投稿サービスメッセージが受信されるときには、サービスに対するサービステーブル４０４の入力項目が存在する。従って、投稿サービスメッセージのコンテンツを任意の既存のサービス広告と照合することによって、接続フレームワークプロセス２１０は、サービスＩＤの拡散を制御し、エラー回復をサポートし得る。本発明の実施形態によれば、サービスエンジン４１６は全て、それらが如何にして呼び出されたかにかかわらず、投稿サービスメッセージ及び返信投稿メッセージ確認応答を用いて、サービス広告情報と、サービスＩＤが割り当てられた接続フレームワークプロセスとの同期化を行う。
【００４７】
クライアントローカルアプリケーション４２２等のクライアントが、広告されたサービス（即ち、サービステーブル４０４にリスト化されたサービス）を要求する場合、オープンサービスメッセージが、接続フレームワークプロセス２１０によって適用可能なサービスエンジン４１６に送信される（ステップ６２４）。サービスエンジンは、要求に応答して、サービスオープンメッセージにより、そのサービスエンジン４１６を通して利用可能な広告されたサービスを開く（ステップ６２８）。
【００４８】
接続フレームワークプロセス２１０は、要求状態メッセージを用いて、関連するサービスエンジン４１６からサービスの状態をいつでも要求し得る（ステップ６３２）。サービ
スエンジン４１６は、状態報告メッセージで返信する（ステップ６３６）。要求状態メッセージが受信されていなくても、状態報告メッセージはサービスエンジン４１６によって送信され得る。従って、サービスエンジン４１６は、定期的に又は一定のイベントの発生後に、状態報告メッセージを送信し得る。
【００４９】
接続フレームワークプロセス２１０は、クローズサービスメッセージを用いて、特定のインスタンス用の（即ち、特定のクライアントに関連する）サービス又は関連するサービスの全てのユーザ用のサービスを閉じるようにサービスエンジン４１６に命令し得る（ステップ６４０）。従って、クローズサービスメッセージは、提供されたサービスの１つ又は複数のインスタンスを識別し得る。クローズサービスメッセージに応答して、サービスエンジン４１６は、確認応答としてサービスクローズメッセージを返す（ステップ６４４）。また、サービスエンジン４１６は、サービスクローズメッセージを接続フレームワークプロセス２１０に送信して、命令されていないサービス閉止について接続フレームワークプロセス２１０に通知し得る。
【００５０】
次に、図７において、有線インタフェース３２４を通して通信インタフェースシステム１０４に直接相互接続される装置４２０によって提供されるサービスへアクセスするローカルクライアントアプリケーション４２２を示すブロック図を示す。より詳細には、図７の例では、ＲＳ−２３２タイプ有線インタフェース３２４によって、通信インタフェースシステム１０４に相互接続されるＧＰＳ受信機装置４２０からデータにアクセスする位置ベースのクライアントアプリケーション４２２を示す。接続フレームワークプロセス２１０、サービスエンジン４１６、及びアプリケーション４２２の間の通信に用いられるメッセージセットは、本明細書に提供された様々な図に関連して与えられたもの等の例に関連して述べたものと同じであってよい。即ち、図７の例におけるＲＳ−２３２シリアルインタフェース等の有線インタフェース３２４を用いると、通信の参加者が用いる必要があるメッセージは変わらない。従って、例えば、異なるインタフェースを用いて通信インタフェースシステム１０４に相互接続される装置４２０と通信を行うためにアプリケーション４２２の修正を必要としない。更に、図７に示すＧＰＳ受信機等、通信インタフェースシステム１０４によって用いられるものに対応するメッセージをサポートすることが可能な装置４２０は、アプリケーション４２２と連係して動作するために特別に修正する必要がない。図７に示す構成例は、ＲＳ−２３２シリアル相互接続を介した装置４２０との通信に必要なＲＳ−２３２有線インタフェース３２４を組み込む又はそれと接続された状態で動作するサービスエンジン４１６を提供することによって、装置４２０及びアプリケーション４２２は相互運用するために修正する必要がないことを実証する。即ち、適切なサービスエンジン４１６を提供することによって、通信インタフェースシステム１０４に関連するアプリケーション４２２は、装置４２０によって用いられるインタフェースのタイプに対する事前の知識又は特別な適応なしで、別個の装置４２０に連動して接続し得る。
【００５１】
次に、図８において、例えば、図７に全体的に示すように、相互接続された装置４２０によって提供されるサービスへのローカルアプリケーション４２２のアクセスを提供することに関連した通信インタフェースシステム１０４の動作を示す。図示の目的のために、本発明におけるローカルアプリケーション４２２はクライアント位置ベースのアプリケーションであり、サービスには、ＧＰＳ装置４２０によって提供される位置情報が含まれる。最初に、ステップ８００において、位置ベースのアプリケーション４２２は、問い合わせサービスルーチンを呼出し、ＧＰＳ装置からの標準化された位置データへのアクセスを要求する。問い合わせサービスルーチンによって、接続フレームワークプロセス２１０は、サービステーブル４０４を読み込む（ステップ８０４）。ステップ８０８において、位置ベースのアプリケーション４２２からの要求を満たすサービスが利用可能であるか否かに関して判断を行う。要求されたサービスが利用可能である場合、アプリケーション４２２が適切に認証され認可されていると仮定すると、要求されたサービスに対するハンドル
が、例えば、利用可能な１つ以上のサービスを識別するサービスリストの形態でアプリケーションに返される（ステップ８１２）。次いで、アプリケーションはサービスに対するハンドルの仕様が含まれるオープンサービスメッセージを用いて、（例えば、サービスエンジン４１６に接触することによって）サービスを開き、サービス資源を割り当て、位置ベースのアプリケーション４２２をサポートする（必要な場合）（ステップ８１６）。
【００５２】
ステップ８２０において、位置ベースのアプリケーション４２２は、読み込みサービスルーチンを用いて、位置データを呼び出す。特に、オープンサービスに関連するハンドルを指定する読み込みサービスメッセージは、位置ベースのアプリケーション４２２からサービスエンジン４１６に送信される（ステップ８２４）。次いで、サービス固有送信サービスメッセージは、サービスエンジン４１６と装置４２０との間のリンクによって、必要に応じてフォーマット化され、要求された情報は装置４２０から取得され、サービスエンジン４１６によって位置ベースのアプリケーションに返される（ステップ８２８）。この情報が、アプリケーション４２２によって提供されるバッファ又はオブジェクトに書き込まれることによって、位置ベースのアプリケーション４２２に返され得る。ステップ８２８において要求された情報をアプリケーションに返した後、又は、ステップ８０８においてアプリケーションの要求を満たすサービスが利用可能でないと判断した後、プロセスは終了し得る。
【００５３】
次に、図９において、本発明の実施形態に基づくサービス発見プロセスを示す。最初に、ステップ９００において、クライアントアプリケーション４２２は、接続フレームワークプロセス２１０のパブリック制御チャネル又は主制御チャネルを用いて、確立メッセージを送信する。これに応じて、接続フレームワークプロセス２１０は、確立メッセージの一部として接続フレームワークプロセス２１０に提供されたクライアントアプリケーションの制御チャネル上でＨｉＹａを送信する（ステップ９０４）。ステップ９００，９０４に関連して用いられ、サービス発見プロセスの一部として接続フレームワークプロセスとクライアントアプリケーション４２２との間の通信を確立する確立メッセージ及びＨｉＹａメッセージは、図６に関連して説明されたサービス登録プロセスのステップ６０４，６０８において用いられる確立メッセージ及びＨｉＹａメッセージと同じであってよい。専用のクライアント制御チャネルが確立された後、認可及び認証メッセージの交換によって認証及び認可ステップを実施し得る（ステップ９０９）。
【００５４】
あらゆる要求された認証及び認可が正常に完了された場合、サービス発見が開始され、問い合わせサービスメッセージがクライアントアプリケーション４２２から接続フレームワークプロセスに送信される（ステップ９１３）。（問い合わせサービスメッセージの形態での）利用可能なサービスに関する情報に対するクライアントアプリケーション４２２の要求に応答して、接続フレームワークプロセス２１０は、クライアントアプリケーション４２２に受信が認可されたサービスのリストを含むサービスリストメッセージを返す（ステップ９１７）。本発明の実施形態によれば、クライアントアプリケーション４２２によって送信される問い合わせサービスメッセージは、遠隔プラットフォームが利用可能な全てのサービスに対して、全ての利用可能なサービスに対して、又はシステムと接続された状態で利用可能な他のカテゴリのサービスに対して、特定のサービスタイプ若しくはクラスの指定を又はローカルサービスに対する問い合わせを行い得る。
【００５５】
クライアントアプリケーション４２２によって要求されたサービスが利用可能である場合、クライアントアプリケーション４２２は、オープンサービスメッセージを用いて、サービスを要求し得る（ステップ９２０）。接続フレームワークプロセス２１０は、オープンサービスメッセージを受信すると、要求されたサービスが利用可能であることを検証し、サービスオープンメッセージで応答し得る（ステップ９２４）。サービスオープンメッセージを受信した後、クライアントアプリケーション４２２は、サービスエンジン４１６
に直接接続する。本発明の実施形態によれば、クライアントアプリケーション４２２と接続フレームワークプロセス２１０との間の通信は、確立メッセージ及びＨｉＹａメッセージを用いて確立されるクライアント制御チャネルを用いる。更に、クライアント制御チャネルが、登録サービスの一部としてアプリケーション４２２と接続された状態で（即ち、クライアントアプリケーション４２２と同様にサービスを消費し得るアプリケーションのサービスエンジン４１６の機能と接続された状態で）確立される場合、そのチャネルは、サービスの要求に用い得る。同様に、制御チャネルがアプリケーション・シーク・サービス（即ち、クライアントアプリケーション４２２のような）と接続フレームワークプロセス２１０との間に確立される場合、サービス発見プロセスと接続された状態で確立される専用のチャネルは、アプリケーションによって用いられ、そのようなアプリケーションがサービスエンジン４１６として動作している場合、サービスを報告し得る。従って、一旦専用のチャネルが、第１プロセスに関連して、アプリケーション４１６及び／又は４２２と接続フレームワークプロセス２１０との間に確立されると、アプリケーション４１６及び／又は４２２と接続フレームワークプロセス２１０との間に第２プロセスに用いるための別個の接続を確立する必要はない。
【００５６】
接続フレームワークプロセス２１０は、要求状態メッセージを用いて、管理されるプロセス又はクライアントアプリケーション４２２の状態をいつでも要求し得る（ステップ９２８）。更に、クライアントアプリケーション４２２は、接続フレームワークプロセス２１０からサービスの状態をいつでも要求し得る（ステップ９２８）。クライアントアプリケーション４２２が接続フレームワークプロセス２１０から要求状態メッセージを受信する場合、クライアントアプリケーション４２２は、状態報告メッセージで返信するように義務付けられている（ステップ９３２）。同様に、接続フレームワークプロセス２１０が、クライアントアプリケーション４２２から要求状態メッセージを受信する場合、接続フレームワークプロセス２１０は、クライアントアプリケーション４２２に状態報告メッセージで返信する必要がある（ステップ９３２）。一般的に、状態報告メッセージ９３２は、要求状態メッセージの受信後、指定された期間内に受信側エンティティによって送信される必要がある。
【００５７】
クライアントアプリケーション４２２がもはやサービスを必要としない場合その他、セッションが終了した場合、クライアントアプリケーション４２２は、クローズサービスメッセージを用いて接続フレームワークプロセスに通知する（ステップ９３６）。次いで、接続フレームワークプロセスはサービスエンジン４１６に通知する。更に、接続フレームワークプロセス２１０は、サービスクローズドメッセージをクライアントアプリケーション４２２に送信することによって（ステップ９４０）、サービスの閉止を確認応答する。
【００５８】
次に、図１０において、通信インタフェースシステム１０４が遠隔プラットフォーム１２０と接続した状態で動作しているシステム１００を例示する。一般的に、通信インタフェースシステム１０４には、接続フレームワークプロセス２１０が含まれる。サービステーブル４０４、イベントテーブル４０８、及びサービス開始テーブル４１０は、ＣＩＳ１０４によって維持される。図１０にはその接続フレームワークプロセス２１０に含まれるものとして示すが、一部の又は全てのテーブルは別のプロセス若しくはアプリケーションによって又はオペレーティング・システムによって提供し得る。更に、通信インタフェースシステム１０４には、接続ランタイムサービス／イベントインタフェース４１２が含まれる。また、１つ又は複数のサービスエンジン４１６が、通信インタフェースシステム１０４上で動作し得る。例えば、図１０に示すように、ＧＰＳエンジンが含まれるサービスエンジン４１６を含み得る。装置４２０は、サービスエンジン４１６に相互接続し得る。例えば、図１０に示すように、ＧＰＳ受信機４２０は、ＧＰＳエンジン４１６と通信を行い得る。
【００５９】
また、通信インタフェースシステム１０４には、更に、標準化された通信インタフェース４２４を含み得る。本発明の実施形態によれば、標準化された通信インタフェース４２４ａには、インタフェースエンジン又はマネージャ９０８ａを含み得る。一実施形態において、本出願と同じ譲受人に譲渡された米国特許第６，１２２，５１４号、「通信チャネル選択（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｃｈａｎｎｅｌ  Ｓｅｌｅｃｔｉｏｎ）」に記載されたように、標準化された通信インタフェース４２４ａには、用いられる選択通信チャネルを決定するためのリンク選択装置又はモジュールを含み得る。サービスマップ９１２ａは、インタフェースエンジン９０８によって維持し得る。一般的に、通信インタフェース４２４ａは、通信リンク９１６を介して、通信インタフェースシステム１０４を遠隔プラットフォーム１２０に接続する。通信リンク９１６には、デジタルデータ及び命令を伝達するのに適する任意の通信相互接続を含み得る。従って、通信リンク９１６の例としては、ブルートゥース又は他の無線接続（この場合、インタフェースマネージャ４２４には、無線インタフェース３２８が含まれる）、又はＵＳＢその他の有線接続（この場合、インタフェースマネージャ４２４には、有線インタフェース３２４が含まれる）、が挙げられる。インタフェースエンジン９０８は、ＵＳＢドライバによる方法などを含む様々な方法で、初期化又は開始され得る。
【００６０】
遠隔プラットフォーム１２０には、一般的に、サービステーブル４０４ｂ、イベントテーブル４０８ｂ及びサービス開始テーブル４１０ｂを含む接続フレームワークプロセス２１０ｂが含まれる。遠隔プラットフォーム１２０は、更に、サービス／イベントインタフェース４１２ｂ及び標準通信インタフェース４２４ｂを提供し得る。標準通信インタフェース４２４ｂには、インタフェースエンジン即ちマネージャ９０８ｂを含み得るが、これと接続した状態で、サービスマップ９１２ｂが維持される。更に、１つ又は複数のアプリケーション４２２が、遠隔プラットフォーム１２０上で動作し得る。
【００６１】
インタフェースエンジン９０８は、外部の（プラットフォーム外）通信を規格化する。特に、インタフェースエンジン９０８は、通信技術固有アドレスをネットワーク標準化サービスパイプにマッピングする。インタフェースエンジン９０８によってサポートし得る通信技術の例としては、ＴＣＰ／ＵＤＰ、ＵＳＢ、及び簡易シリアル・ポートが挙げられる。更に、ＣＡＮ等の様々なバス技術をサポートし得る。サービスパイプ又は通信リンク９１６を用いて、アプリケーション４２２は、同じやり方でローカル及び遠隔サービスにアクセスすることが可能である。即ち、インタフェースエンジン９０８の動作の結果としては、クライアントアプリケーション４２２に対してローカルな又は遠隔的なプラットフォーム上で動作するサービスエンジン４１６と接続された状態でサービスが運用されるか否かは重要でない。更に、プラットフォーム間（即ち、ＣＩＳ１０４と遠隔プラットフォーム１２０との間）の特定の通信リンク９１６は、重要でない。
【００６２】
プラットフォーム１０４又は１２０から遠隔である（即ち、離れている）プラットフォーム１０４又は１２０上で、アプリケーション４２２が動作しており、それと関連してサービスが動作しているか又は利用可能な場合、サービスに関連するプラットフォーム１０４又は１２０に関連付けられたインタフェースエンジン９０８は、遠隔アプリケーション４２２のプロキシとして機能する。更に、サービスの広告に関しては、プラットフォーム１０４又は１２０上で動作するインタフェースエンジン９０８は、遠隔（即ち、他の）プラットフォームからの利用可能なサービスを広告する。更に、インタフェースエンジン９０８は、通信リンク９１６によって用いられる接続技術にとって適切なインタフェース制御ポートを監視し、受信されたあらゆる制御メッセージを処理する。また、インタフェースエンジン９０８は、通信リンク９１６を介して確立された通信パイプを提供又はサポートし得るが、通信リンク９１６を通して、異なるプラットフォーム１０４，１２０上のクライアントアプリケーション及びサービスは、互いに接続し得る。特に、インタフェースエンジン９０８は、ローカルサービスエンジンへの接続のように見える接続をローカルア
プリケーション４２２に提供するために動作する。更に、遠隔アプリケーション４２２がローカルサービスを要求する場合、ローカルインタフェースエンジン９０８は、ローカルサービスへの通信パイプを確立する必要がある。インタフェースエンジン９０８とローカルサービスエンジン４１６との間に通信が確立されると、インタフェースエンジン９０８は、通信リンク９１６を介して、ローカルプラットフォーム（例えば、ＣＩＳ１０４）と遠隔プラットフォーム（例えば、遠隔プラットフォーム１２０）との間でデータを橋渡しし得る。更に、インタフェースエンジン９０８は、ローカル内部プロセス通信技術又はプロトコルと、プラットフォーム１０４，１２０間において通信リンク９１６によって用いられる通信技術又はプロトコルとの間の橋渡しを提供する。インタフェースエンジン９０８により提供される橋渡し機能には、メッセージのフレーミング、バッファリング、及びフロー制御が含まれる。
【００６３】
インタフェースエンジン９０８は、接続する外部のプラットフォーム、即ち、プラットフォーム１０４又は１２０との同期化を行う。この同期化には、プラットフォーム１０４，１２０間における共有可能なサービスに関する情報の完全な交換又は特定のサービスに対する要求を含み得る。次いで、図１１において、本発明の実施形態に基づくプラットフォーム１０４，１２０の同期化を行うためのプロセスを例示する。説明を簡単にするために、サービスがＣＩＳ１０４に関連付けられていると仮定し、サービスを要求するクライアントアプリケーション４２２は通信リンク９１６によってＣＩＳ１０４に相互接続される遠隔プラットフォーム１２０に関連付けられていると仮定する（図１０参照）。
【００６４】
図１１に示すように、プラットフォーム１０４，１２０間の初期の通信は、パブリックチャネル又はポート上の確立メッセージである（ステップ１１００）。一般的に、チャネル又はポートの識別は、通信リンク９１６の技術又はプロトコルに依存する。図１１に示すプロセス例において、確立メッセージは、遠隔プラットフォーム１２０上で動作するインタフェースエンジン９０８ｂによって送信される。ＣＩＳ１０４上で動作するインタフェースエンジン９０８ａは、確立メッセージを受信し、確立メッセージの一部として送信側インタフェースエンジン９０８ｂによって指定された制御ポート上でＨｉＹａメッセージにより応答する（ステップ１１０４）。確立メッセージがＣＩＳ１０４上のサービスエンジン９０８ａによって送信された場合、遠隔プラットフォーム１２０上で動作するインタフェースエンジン９０８ｂは、ＨｉＹａメッセージにより応答する。そして、認可及び認証メッセージは、プラットフォーム１０４，１２０間で交換し得る（ステップ１１０８）。
【００６５】
ステップ１１１２において、遠隔プラットフォーム１２０上で動作するインタフェースエンジン９０８ｂは、共有可能なサービスのリストを要求する。ＣＩＳ１０４上のインタフェースエンジン９０８ａはサービスリストメッセージで応答するが、これは、遠隔プラットフォーム１２０のアクセスが認可されているサービスのリストを含む（ステップ１１１６）。特に、識別されないかも知れないが見込みがあり得るクライアントアプリケーション４２２用のプロキシとして機能して、サービス側インタフェースエンジン９０８ａはＣＩＳ１０４上で動作する通信フレームワークプロセス２１０ａによって確立された又はそれに関連付けられたサービステーブル４０４ａから遠隔プラットフォーム１２０と共有し得るサービスのリストを取得する。サービスリストは、そのような情報が、ＣＩＳ１０４上で動作するインタフェースエンジン９０８ａに利用可能になった場合、遠隔プラットフォーム１２０に関連付けられた要求側アプリケーション４２２に固有であってよい。遠隔プラットフォーム１２０上のインタフェースエンジン９０８ｂは、ＣＩＳ１０４から受信されたサービスリストを遠隔プラットフォーム１２０上の接続フレームワークプロセス２１０ｂに提供し、関連付けられたサービステーブル４０４ｂに配置し得る。
【００６６】
遠隔プラットフォーム１２０上で動作するクライアントアプリケーション４２２が、共
有されるサービスを要求する場合、遠隔プラットフォーム１２０上で動作するインタフェースエンジン９０８ｂは、ＣＩＳ１０４に関連付けられたインタフェースエンジン９０８ａにオープンサービスメッセージを送信する（ステップ１１２０）。一般的に、オープンサービスメッセージは、要求されたサービスを識別し、また、要求側クライアントアプリケーション４２２を識別し得る。オープンサービスメッセージに応答して、サービス側インタフェースエンジン９０８ａは、ローカルプラットフォーム１０４上のサービスを開く。一般的に、ローカルプラットフォーム１０４上のインタフェースエンジンは、遠隔プラットフォーム１２０上のクライアントアプリケーション４２２用のプロキシとしての役割を果たすが、ローカルプラットフォーム１０４上で動作するクライアントアプリケーション４２２がサービスを開くのと同じやり方で、要求されたサービスを開く（例えば、図６及び関連の説明参照）。遠隔オープンメッセージはローカル又はサービス側インタフェースエンジン９０８によって返され、要求されたサービスをどこに接続すべきかについて、クライアント又は遠隔インタフェースエンジン９０８ｂに通知する（ステップ１１２４）。そして、識別されたポート又は通信チャネルは、アプリケーション固有メッセージを伝達するために用いられる。
【００６７】
インタフェースエンジン９０８は、他のプラットフォーム上のサービスの状態をいつでも要求し得る。このことは、要求状態メッセージを送信することによって行われる（ステップ１１２８）。図１１のプロセス例に関連して、要求状態メッセージは、サービス側インタフェースエンジン９０８ａによって報告されるサービスの状態に関して、クライアント側インタフェースエンジン９０８ｂによって送信し得る。要求状態メッセージに応答して、サービス側インタフェースエンジン９０８ａは状態報告メッセージを返す（ステップ１１３２）。状態報告メッセージに含まれる情報は、（その状態が要求された）サービスに関連するサービスエンジン４１６に要求状態メッセージを送信することによって、サービス側インタフェースエンジン９０８ａによって取得し得る。
【００６８】
追加の共有可能なサービスが利用可能になると（又は、なる場合）、インタフェースエンジン９０８は、他のプラットフォームに通知し得る。例えば、追加のサービスがＣＩＳ１０４から利用可能になると、サービス側インタフェースエンジン９０８ａは、それらのサービスをリスト化している投稿サービスメッセージを送信し得る（ステップ１１３６）。投稿サービスメッセージに応答して、受信側インタフェースエンジン９０８ｂは、投稿メッセージ確認応答を送信する。（ステップ１１４０）。
【００６９】
クライアントアプリケーション４２２がサービスの使用を終えると、クライアント側インタフェースエンジン９０８ｂは、クローズサービスメッセージをサービス側インタフェースエンジン９０８ａに送信する（ステップ１１４４）。そして今度は、サービス側インタフェースエンジン９０８ａは、インタフェースエンジンの専用の制御チャネルを用いて、接続フレームワークプロセス２１０ａに通知する。そして、接続フレームワークプロセス２１０ａは、メッセージをサービスエンジン４１６に渡す。クローズサービスメッセージに応答して、サービス側インタフェースエンジン９０８は、サービスクローズドメッセージを送信する（ステップ１１４８）。サービスクローズドメッセージは、サービスインスタンスが閉じられるという（即ち、特定のクライアントアプリケーションに関するサービスの提供が閉じられるという）又はサービス全体が閉じられるという通知を提供するためにも送信し得る。
【００７０】
図１１に関連して提供される例は、１つのインタフェースエンジン９０８ａをサービス側インタフェースエンジンとして、また、他方のインタフェースエンジン９０８ｂをクライアント側インタフェースエンジンとして説明するが、本発明の実施形態は、そのように制限されないことを認識すべきである。特に、インタフェースエンジン９０８ａ及び９０８ｂ双方共、サービスクライアント及びサービスプロバイダとしての役割を果たし得る。
そのような状況において、図１１に関連して例示したメッセージは、双方向に渡される。
【００７１】
次に、図１２において、システム１００の構成要素間の様々な通信チャネル又は論理的な接続を例示する。特に、図１２には、システム１００の異なるエンティティ又は構成要素間のメッセージ及びデータの伝送に関して述べた様々な通信チャネル又はパイプの概要を示す。クライアントアプリケーション４２２は、アプリケーション４２２に利用可能なサービスを発見するために、通信チャネルＣ−１を介して、ローカル接続フレームワークプロセス２１０と直接通信を行う。特に、クライアントアプリケーション４２２は、最初に、通信フレームワークプロセスのパブリック制御チャネル上の通信フレームワークプロセス２１０に直接送信される確立メッセージを用いて、接続フレームワークプロセス２１０との通信を確立する。クライアントアプリケーション４２２がローカル接続フレームワークプロセス２１０との通信を確立した後、それらのエンティティ間の後続の通信は、クライアントアプリケーション４２２の制御チャネルを用い得る。特に、メッセージは、問い合わせサービスメッセージに応じて、利用可能なサービスを発見するために、また、クライアントアプリケーション４２２に渡されるサービスリストに含まれるサービスを要求するために、チャネルＣ−１を介して、クライアントアプリケーション４２２とローカル接続フレームワークプロセス２１０との間において直接渡し得る。接続フレームワークプロセス２１０が、チャネルＣ−１を介して、サービスオープンメッセージをクライアントアプリケーション４２２に直接送信することによって、オープンサービスメッセージに応答した後、クライアントアプリケーション４２２は要求されたサービスに関連するサービスエンジン４１６に直接接続し得る。
【００７２】
クライアントアプリケーション４２２とサービスエンジン４１６との間の通信を、通信チャネルＣ−２によって図１２に表す。一般的に、通信チャネルＣ−２に沿って渡される通信情報は、アプリケーション固有である。即ち、メッセージ及びデータのフォーマットは、接続フレームワークプロセス２１０の一部として確立されるメッセージ（例えば、制御メッセージ２１６）ではなくサービスエンジン４１６又はローカルアプリケーション４２２によって決定される。本発明の実施形態によれば、サービスエンジン４１６は、基本的なメッセージ及びデータフォーマット処理、並びにサービスを利用可能にする装置４２０と装置に相互接続されるサービスエンジン４１６との間の物理的なリンクの制御を取り扱う。従って、そのような機能は、クライアントアプリケーション４２２が取り扱う必要がない。本発明の実施形態によれば、サービスエンジン４１６は標準ネットワーク通信階層モデルの第１層〜第４層を取り扱い得る。
【００７３】
クライアントアプリケーション４２２が、接続フレームワークプロセス２１０を通して、遠隔プラットフォーム１２０上で利用可能なサービスに申し込んだ場合、クライアントアプリケーション４２２と（通信マネージャ４２４の一部として提供される）インタフェースエンジン９０８との間の通信チャネルＣ−３を用い得る。特に、遠隔サービスに関するサービスオープンメッセージがクライアントアプリケーション４２２によって受信された後は、チャネルＣ−３が用いられる。ローカルサービスエンジン４１６とクライアントアプリケーション４２２との間の通信リンクＣ−２を介して渡されるメッセージ及びデータと同様に、インタフェースエンジン９０８とクライアントアプリケーション４２２との間の通信リンクＣ−３を介して渡されるメッセージ及びデータは、アプリケーション固有であってよい。特に、インタフェースエンジン９０８は、クライアントアプリケーション４２２に対して、ローカルサービスエンジン４１６のように見える。更に、クライアントアプリケーション４２２は、遠隔プラットフォーム１２０にＣＩＳ１０４を相互接続するために用いられる通信リンク技術９１６を意識する必要がない。特に、適切なプロトコルへのアプリケーション固有メッセージのフォーマット化処理、及び物理的な接続の制御は、インタフェースエンジン９０８によって取り扱われる。本発明の実施形態によれば、標準ネットワークモデルの第１層〜第４層は、インタフェースエンジン９０８によって取り
扱われる。
【００７４】
サービスエンジン４１６は、利用可能なサービス広告に関連して接続フレームワークプロセス２１０と直接通信を行う。そのような通信は、通信チャネルＣ−４に沿って渡される。更に、サービスエンジン４１６とローカル接続フレームワークプロセス２１０との間の直接相互接続は、要求状態及び状態報告メッセージを搬送するために用い得る。接続フレームワークプロセス２１０とサービスエンジン４１６との間において搬送し得る他のメッセージには、全てのアプリケーションに又は特定のアプリケーション４２２に対するサービスを閉じる命令が含まれる。一般的に、用いられる制御チャネルの識別を含んでいる確立メッセージが送信された後、サービスエンジン４１６とローカル接続フレームワークプロセス２１０との間の通信は、サービスエンジン４１６によって指定された制御チャネルを用いる。
【００７５】
また、サービスエンジン４１６は、例えば、遠隔プラットフォーム１２０上で動作する又はそれに関連付けられたクライアントアプリケーション４２２にサービスを提供する場合、通信チャネルＣ−５を介して、インタフェースエンジン９０８と直接通信を行い得る。一般的に、インタフェースエンジン９０８は、遠隔プラットフォーム１２０上のクライアントアプリケーション４２２用のプロキシとして機能し、アプリケーション固有メッセージ及びデータをサービスエンジン４１６とインタフェースエンジン９０８との間に渡し、遠隔プラットフォーム１２０及びクライアントアプリケーション４２２に配信し得る。
【００７６】
また、接続フレームワークプロセス２１０は、チャネルＣ−６を介してインタフェースエンジンと直接通信を行い得る。一般的に、接続フレームワークプロセス２１０とインタフェースエンジン９０８との間の通信は、遠隔プラットフォーム１２０にＣＩＳ１０４上で利用可能なサービスの広告に関連して、また、遠隔プラットフォーム上で利用可能なサービスに対する遠隔プラットフォーム１２０への問い合わせに関連して起こる。
【００７７】
次に、図１３において、クライアントアプリケーションによるサービスへのアクセスの確立を例示する。図１３によって示した例によれば、アクセスされるサービスは、通信インタフェースシステム１０４プラットフォームそれ自体上で動作する車載車両診断プログラムＩＩサービスエンジン４１６ｂであり、車両診断アプリケーション（図４参照）が含まれるローカルアプリケーション４２２によってアクセスされる。最初に、接続フレームワークプロセス２１０は、呼出しサービス制御チャネルメッセージをサービスエンジン４１６ｂに送信するが、これには、サービスエンジン４１６ｂによって用いるために生成されるサービス制御チャネルの名前を指定する命令ライン引数が含まれる（ステップ１３００）。これに応答して、また、サービスエンジン４１６を動作させている状態で、サービスエンジンは、接続フレームワークプロセス２１０によって指定されたサービス制御チャネルに接続し、サービスエンジン４１６ｂ用のサービス制御チャネルの識別を含む確立メッセージを送信する（ステップ１３０４）。接続フレームワークプロセス２１０は、ＨｉＹａメッセージを送信して、制御チャネルを介して通信を確立し、また、サービス４１２に対して、任意のサービス固有の初期化を実行するように命令する（ステップ１３０８）。そして、サービスエンジン４１６ｂは、初期化を行い、サービスを提供する装置（即ち、車載診断システムＩＩ（ＯＢＤ−ＩＩ）インタフェース４２０ｂ）への接続性を検証し、認証及び認可が実行される（ステップ１３１２）。次いで、サービスエンジン４１６ｂは、投稿サービスメッセージを接続フレームワークプロセス２１０に送信して、サービスエンジン４１６ｂによって提供されるサービスを報告する（ステップ１３１６）。これらのサービス（又はサービスエンジンを通して提供される単一のサービス）は、サービステーブル４０４にリスト化される。投稿サービスメッセージに応答して投稿メッセージ確認応答が送信される（ステップ１３１８）。投稿メッセージ確認応答は、サービスに割り当てられたサービス識別子（サービスＩＤ）をサービスエンジン４１６ｂに伝達する。
【００７８】
ローカルアプリケーション４２２、即ち、本例では車両診断アプリケーションは、ユーザ又は他のプロセスによって呼び出され得る。呼び出されると、ローカルクライアントアプリケーション４２２は、確立メッセージをパブリック制御チャネル上で接続フレームワークプロセス２１０に送信する（ステップ１３２０）。接続フレームワークプロセス２１０は、クライアント制御チャネル上においてＨｉＹａメッセージで応答し（ステップ１３２４）、認証及び認可が実行される（ステップ１３２８）。図１３に示すように、クライアントアプリケーション４２２は、サービスエンジン４１６が接続フレームワークプロセス２１０との通信を確立しているのとほぼ同時に、接続フレームワークプロセス２１０との通信を確立し得る。これに代えて、様々なエンティティ間の通信は、異なる時点において確立し得る。こうして専用のサービス制御チャネルが確立された状態で、ローカルアプリケーション４２２は、問い合わせサービスメッセージを接続フレームワークプロセス２１０に送信する（ステップ１３３２）。問い合わせサービスメッセージには、要求されたサービスを指定する「サービスクラス」及び「サービスタイプ」等の記述子を含み得る。
【００７９】
問い合わせサービスメッセージに応答して、接続フレームワークプロセス２１０は、アプリケーションの通信チャネルに接続する。そして、追加の認可及び認証サービスプロトコルを処理し得る（ステップ１３３６）。特に、接続フレームワークプロセス２１０は、サービスへのアクセスを要求するアプリケーションの識別を検証し、また、アプリケーションがサービスへのアクセスを認可されていることを検証し得る。従って、本発明の実施形態によれば、サービス問い合わせが許されるには認可が必要であり得る。データセキュリティを提供することに加えて、そのような手順は、装置、サービス及び／又はアプリケーション相互運用性に関するライセンス協定を実現することに関連して有用なことがある。一実施形態において、そのようなセキュリティ関連対策は、本出願の譲受人に譲渡され、また、本明細書においてその全体を引用・参照する２００４年１月２８日に出願した米国特許出願第１０／７６７，５４８号、表題「セキュリティ保護されたテレマティクス（Ｓｅｃｕｒｅ  Ｔｅｌｅｍａｔｉｃｓ）」のシステム及び／又は方法の少なくとも一部を用いて実現し得る。
【００８０】
アプリケーション４２２が、認証され認可された後、接続フレームワークプロセス２１０は、サービステーブル４０４において利用可能なものとして示され、また、アプリケーション４２２によって要求されたサービスタイプ及びクラスと合致するサービスのリストをサービスリストメッセージの一部として送信する（ステップ１３４０）。本発明の実施形態によれば、利用するのに充分な権限をアプリケーションが有するサービスだけが、アプリケーション４２２に明らかにされる。
【００８１】
そして、アプリケーション４２２は、アプリケーションの要件を満たす接続フレームワークプロセス２１０から受信されたリストのサービスを識別する。２つ以上のサービスがアプリケーション要求の基準を満たす場合、通常、複数のサービスをリスト化し得るが、このサービスリストは単一のサービスだけを含む。アプリケーション４２２は、選択されたサービスを識別するオープンサービスメッセージを用いて、その選択を接続フレームワークプロセス２１０に伝達する（ステップ１３４４）。オープンサービスメッセージを受信すると、接続フレームワークプロセス２１０は、アプリケーション４２２から受信されたサービスＩＤを調べ、登録されたサービスエンジン（本例では、ＯＢＤ−ＩＩサービスエンジン４１６ｂ）にオープン命令メッセージを送信する（ステップ１３４８）。接続フレームワークプロセス２１０によってサービスエンジン４１６ｂに送信されたメッセージに含まれているのは、要求側アプリケーション４２２を識別するために用いられる接続フレームワークプロセス２１０によって生成されたインスタンス・キーである。オープンサービス命令の受信に応答して、サービスエンジン４１６ｂは、任意のサービス固有の初期化を実施し、要求されたサービスを提供するのに必要な任意の接続固有の資源を割り当て
る。更に、サービスエンジン４１６ｂは、アプリケーション４２２によってサービスにアクセスするために用いられるサービスインスタンス通信パイプを生成する。この通信チャネルの名前又は識別子は、サービスオープンメッセージにおいて接続フレームワークプロセス２１０に送信される（ステップ１３５２）。そして、サービスオープンメッセージは、接続フレームワークプロセス２１０からアプリケーション４２２に送信されるが、これには、接続フレームワークプロセス２１０によって割り当てられたインスタンス・キー及びサービス通信チャネル名又は識別子が含まれる（ステップ１３５６）。
【００８２】
サービスエンジン４１６ｂ用の通信チャネルの識別がこうしてアプリケーション４２２に伝達され、アプリケーション４２２とサービスエンジン４１６ｂとの間の直接通信を開始し得る。直接通信を初期化するために、アプリケーション４２２は、サービス確立メッセージをサービスエンジン４１６ｂに直接（即ち、図１２の通信チャネルＣ−２を用いて）送信する（ステップ１３６０）。サービスエンジン４１６ｂは、サービス接続メッセージでアプリケーション４２２に返信する（ステップ１３６４）。これに代えて、サービス確立メッセージに含まれるインスタンス・キーが合致しない又は別のアプリケーションが同じインスタンス・キーを用いてサービスエンジン４１６ｂに接続されている場合、サービスエンジン４１６ｂは、接続を拒否し、接続フレームワークプロセス２１０にエラーを報告し得る。サービス確立メッセージ及びサービス接続メッセージが正常に交換される場合、アプリケーション４２２とサービスエンジン４１６ｂとの間のアプリケーション固有通信は、こうして開始し得る（ステップ１３６８）。本発明の他の実施形態によれば、サービス確立メッセージ及びサービス接続メッセージ等の制御メッセージは、サービスとクライアントアプリケーションとの間の直接通信を始めるために必要でない。アプリケーション固有通信には、サービスエンジン４１６ｂからアプリケーション４２２への情報の配信を含み得る。これに代えて、又は更に、この通信には、アプリケーション４２２とサービスエンジン４１６ｂとの間の情報の交換を含み得る。例えば、本例に関連して、アプリケーション４２２は、サービスエンジン４１６ｂから車両性能パラメータ情報を取得し得る。
【００８３】
確立された通信チャネルを用いたアプリケーション４２２へのメッセージの送信に加えて又はこれに代えて、サービスは情報をイベントとして提供又は一斉送信（ｂｒｏａｄｃａｓｔ）し得る。そして、接続フレームワークプロセス２１０は、そのようなイベントの受信に応答して、イベントテーブル４０８を参照して、どのアプリケーション又はアプリケーション４２２が、イベントについて通知されるべきか又はそれらに配信されたイベントの含まれる情報を有するべきか判断し得る。
【００８４】
接続フレームワークプロセス２１０は、状態要求メッセージをサービスエンジン４１６に送信することによって、定期的にサービスエンジン４１６の状態を要求し得る（ステップ１３７２）。返信において、サービスエンジン４１６は、サービス状態メッセージを送信する。（ステップ１３７６）。状態要求及びサービス状態メッセージは、サービスエンジンの制御チャネルを用いて送受信される。図１３に示すように、状態要求メッセージは、アプリケーション固有通信に挿入し得る。
【００８５】
アプリケーション４２２が、サービスへのアクセスをもはや必要としない場合、クローズサービスメッセージが、アプリケーション４２２から接続フレームワークプロセス２１０に送信され（ステップ１３８０）、そして今度は、これによってサービスエンジン４１６に通知が行われる（ステップ１３８４）。サービスエンジン４１６は、要求を確認応答し（ステップ１３８８）、あらゆるセッション固有の資源を整理する。そして、サービスエンジン４１６は、セッションが終了したことについて接続フレームワークプロセス２１０に通知する（ステップ１３９２）。
【００８６】
次に、図１４において、本発明の実施形態に基づく通信インタフェースシステム１０４から利用可能なサービスに遠隔プラットフォーム１２０上で動作するアプリケーション４２２をアクセスさせるためのプロセスを例示する。特に、図１４には、通信インタフェースシステム１０４に関連するＧＰＳ受信機４２０から利用可能な位置情報へのアクセスに対する遠隔プラットフォーム１２０上の位置ベースのアプリケーション４２２からの要求を示す。最初に、ステップ１４００において、位置ベースのアプリケーション４２２は、問い合わせサービスルーチンを呼出し、位置情報へのアクセスを要求する。問い合わせサービスルーチンは、サービステーブル４０４ｂを読み込む（ステップ１４０４）。ステップ１４０８において、要求を満たすサービスが利用可能であるか否かに関して判断を行う。通信インタフェースシステム１０４等、他のプラットフォームを通して利用可能なサービスに関しては、サービスが、遠隔プラットフォーム１２０によって受信されたサービスリストメッセージに含まれていた場合、サービステーブル４０４ｂには、そのようなサービスに対する参照が含まれる。要求されたサービスに対する参照がサービステーブル４０４ｂに含まれる場合、サービスが利用可能であると判断され、そのサービス用のサービスＩＤが、接続フレームワークプロセス２１０ｂからアプリケーション４２２に返される（ステップ１４１２）。要求を満たすサービスが利用可能でない場合、プロセスは終了し得る。
【００８７】
ステップ１４１６において、アプリケーション４２２は、接続フレームワークプロセス２１０を通して、オープンサービスルーチンを用いてサービスを開き、また、遠隔プラットフォーム１２０と通信インタフェースシステム１０４との間のインタフェース又は通信リンク９１６の両端間の通信セッションが生成される。そして、アプリケーション４２２は、サービスエンジン４１６（これを通してサービスが利用可能である）に直接送信される読み込みサービスルーチンを用いて、位置データを呼び出す（ステップ１４２０）。読み込みサービスルーチン呼出しは、遠隔プラットフォーム上のサービステーブル４０４ｂにリスト化されたサービス固有機能にマッピングされる（ステップ１４２４）。遠隔プラットフォーム１２０上で呼び出されたサービス固有のルーチンは、サービスエンジン４１６の動作しているプラットフォーム（ここでは、通信インタフェースシステム１０４）の規約又はフォーマットに適合するために必要なあらゆるパラメータ変換を実施する。本発明の他の実施形態によれば、ストリームデータモデル（これによって、アプリケーションメッセージが、配信を保証するチャネルから読み込まれ、また、そのチャネルに書き込まれる）が、マッピングされた読み込み及び書き込み呼出しの代わりに用いられる。
【００８８】
変換されたパラメータ又はデータは、インタフェースエンジン９０８ａ，９０８ｂの間に確立される標準通信インタフェース４２４の通信ルーチンを介して、遠隔プラットフォーム１２０から通信インタフェースシステム１０４に伝達される。即ち、インタフェースエンジン９０８は、通信リンク９１６を用いて、通信インタフェースシステム１０４と遠隔プラットフォーム１２０との間において、サービスルーチンメッセージの送信を実現するのに必要なステップを実行する。例えば、インタフェースエンジン９０８は、インタフェースエンジン９０８間の特定の通信リンク９１６に関連する下位４層（即ち、物理層からトランスポート層）に関連する機能を実行し得る。当業者には認識されるように、そのような通信に対する特定の要件は、特定の通信リンク９１６によって決定される。通信インタフェースシステムを遠隔プラットフォーム１２０に相互接続するために用い得る通信リンク９１６の例としては、ＵＳＢ、イーサネット、及びブルートゥース相互接続が挙げられる。一般的に、任意の種類の有線又は無線インタフェースが、接続を確立するために用い得る。更に、本明細書において提供される説明から認識されるように、適切なインタフェースエンジン９０８を提供することによって、また、適切に資源に参照をマッピングすることによって、通信インタフェースシステム１０４及び相互接続された遠隔プラットフォーム１２０がプラットフォーム間のリンク９１６の特定要件に適合する必要はない。
【００８９】
ステップ１４２８において、通信インタフェースシステム１０４上で動作するインタフェースエンジン９０８ａは、位置データの呼出しを受信し、サービスエンジン４１６に対しサービス固有の読み込みサービスルーチン呼出しを実行する。そして、サービスエンジン４１６は、要求された位置情報を取得し、それをインタフェースエンジン９０８ａに返す（ステップ１４３２）。従って、通信インタフェースシステム上で動作するインタフェースエンジン９０８ａを提供することによって、情報に対する要求及びその要求に対する応答が、あたかもそのような情報を要求するアプリケーション（本例では、位置ベースのアプリケーション４２２）が通信インタフェースシステム１０４上で直接動作しているかのように操作されることが認識される。
【００９０】
インタフェースエンジン９０８ａは、返された情報のうちのいずれか必要なネットワーク又はホストデータフォーマット変換を実施し、要求された情報を含む結果メッセージを生成する。次いで、この結果メッセージは通信リンク９１６を介して中継され、遠隔プラットフォーム１２０上で動作するインタフェースエンジン９０８ｂが、ネットワークメッセージを分解し、そして、受信された結果に対していずれか要求された変換を実行する（ステップ１４３６）。そして、受信された結果に含まれる要求された位置情報は、要求側アプリケーション４２２に返される（ステップ１４４０）。そして、プロセスは終了し得る。
【００９１】
次に、図１５において、遠隔サービスアクセスプロセスシナリオを例示する。特に、通信インタフェースシステム１０４上で動作するサービスからの情報が、そのような情報を要求し遠隔プラットフォーム１２０上で動作するアプリケーション４２２に渡される例によるメッセージの交換を示す。より詳細には、本例は、セルラー式ハンドセットを含む遠隔プラットフォーム１２０上で動作する位置ベースのアプリケーション４２２が含まれるアプリケーションに情報を渡すＧＰＳサービスエンジン４１６が含まれるサービスエンジン４１６を伴う。更に、図１５の例において、インタフェースエンジン９０８ａ，９０８ｂの間の通信リンク９１６には、ユニバーサル・シリアル・バス（ＵＳＢ）通信リンクが含まれる。
【００９２】
一般的に、サービスの交換を実行し得る前、各プラットフォーム上のサービスは、各プラットフォーム１０４，１２０上で実施されるサービス初期化メッセージを通して準備される必要がある（ステップ１５００）。次いで、共有されるサービス情報の交換は、通信インタフェースシステム１０４及び遠隔プラットフォーム１２０によって、サービスメッセージの交換を通して行い得る（ステップ１５０４）。各プラットフォームが他方のプラットフォームからサービスのリストを受信した後、遠隔プラットフォーム上で利用可能なサービスは、それらのそれぞれのサービステーブル４０４に投稿される。
【００９３】
次に、示した本例において、位置ベースのアプリケーション４２２は、利用可能なサービスに対して問い合わせを行い、アプリケーションの要件を満たすサービスを開く（ステップ１５０８）。次に、オープンサービスメッセージは、ＵＳＢ通信リンクを通じて移送され、最終的にサービスエンジン４１６によって受信される（ステップ１５１２）。サービスエンジン４１６は、通信リンクを通じて移送され最終的に位置ベースのアプリケーション４２２に配信されるサービスオープンメッセージで応答する（ステップ１５１６）。サービスオープンメッセージが、位置ベースのアプリケーション４２２によって受信された後、アプリケーション固有通信が開始し得る（ステップ１５２０）。アプリケーション固有通信には、サービスエンジン４１６から位置ベースのアプリケーション４２２へのＧＰＳデータ等の情報の伝達を含み得る。重要なこととして、これらの通信は、通信インタフェースシステム１０４の接続フレームワークプロセス２１０とは独立に又はそれを更に伴うことなく、起こる。即ち、通信リンクが、クライアントアプリケーション４２２と終点マネージャ９０８ｂとの間において、また、サービスエンジン４１６と終点マネージャ
９０８ａとの間において確立された後、接続フレームワークプロセス２１０の機能は、サービスエンジン４１６と位置ベースのアプリケーション４２２との間の情報伝達又は他の通信を行うのには、もはや必要ない。また、直接通信は、インタフェースエンジン９０８ａ，９０８ｂの間において起こる。本質的に、情報伝達等のこれらの通信は、あたかも接続フレームワークプロセス２１０が存在しないかのように、通信リンクが確立された後に起こる。アプリケーション４２２が位置ベースの情報をもはや必要としない場合、サービスは閉じられ、整理が行われる（ステップ１５２４）。通信リンクが確立された後の例示の通信動作に関連する本説明は、遠隔プラットフォーム１２０上で実行する位置ベースのアプリケーション４２２に関するが、通信リンクが確立された後起こる通信の独立性は遠隔プラットフォーム環境に限定されない。特に、通信インタフェースシステム１０４に対してローカルなアプリケーション等の実行されるアプリケーションが、接続フレームワークプロセス２１０から遠隔でない場合、アプリケーション４２２とサービスエンジン４１６との間の同じ直接接続（即ち、接続フレームワークプロセスを通じない）が存在する。そのような場合、アプリケーションは、まさに今説明した例と同様に、独立にまた、接続フレームワークプロセス２１０を伴うことなく、サービスエンジン又は他のサービスとの直接通信を有する。
【００９４】
次に、図１６において、複数の遠隔装置１２０ａ，１２０ｂに相互接続される通信インタフェースシステム１０４のブロック図を例示する。図１６の例において、通信インタフェースシステムには、各々、関連するサービスマップ９１２ａ１，９１２ａ２を有する、第１、第２のインタフェースエンジン９０８ａ１，９０８ａ２が含まれる。従って、それぞれ第１、第２の遠隔装置１２０ａ，１２０ｂへの第１、第２の通信リンク９１６ａ，９１６ｂは、異なる通信リンク技術を用い得る。例えば、第１インタフェースエンジン９０８ａ１は有線インタフェース３２４を含み得る。また、第２インタフェースエンジン９１２ａ２は無線インタフェース３２８を含み得る。また図示したように、通信インタフェースシステムは、サービスエンジン４１６ｂｌ，４１６ｂ２を継続して提供し得るが、これらは、通信インタフェースシステム１０４に直接相互接続される装置４２０と協働して動作してもよく、しなくてもよい。
【００９５】
一般的に、各遠隔プラットフォーム１２０は、インタフェースエンジン９０８ｂ１，９０８ｂ２及び関連付けられたサービスマップ９１２ｂ１，９１２ｂ２を提供する。また、これらは完全に遠隔プラットフォーム１２０として機能することから、各々、接続フレームワークプロセス２１０ｂ１，２１０ｂ２が含まれる。遠隔プラットフォーム１２０上の接続フレームワークプロセス２１０ｂには、各々、サービステーブル４０４、イベントテーブル４０８及びサービス開始テーブル４１０が含まれる（図１６には図示せず）。更に、各遠隔プラットフォームには、サービスイベントインタフェース４１２ｂ１，４１２ｂ２が含まれる。また、遠隔プラットフォーム１２０は、クライアントアプリケーション４１６ｂ１，４１６ｂ２をサポートし得る。
【００９６】
一般的に、通信インタフェースシステム１０４が複数の遠隔プラットフォーム１２０に相互接続されるシステムの動作は、単一の遠隔プラットフォーム１２０が用いられる場合と同じである。特に、複数の遠隔プラットフォーム１２０は適切なインタフェースエンジン９０８を提供して、各遠隔プラットフォーム１２０によって用いられる通信リンク９１６をサポートすることによって対応し得る。更に、複数の遠隔プラットフォーム１２０によって用いられる通信リンク９１６が同じである場合、また、そのようなリンクが複数のプラットフォームをサポートし得る場合、単一のインタフェースエンジン９０８ａが複数の遠隔プラットフォーム１２０をサポートし得ることが認識される。
【００９７】
本発明の実施形態に基づく接続フレームワークプロセス２１０によって維持されるサービステーブル４０４は、通信インタフェースシステム１０４又は相互接続された遠隔プラ
ットフォーム１２０を通して利用可能なサービスに関連したレコードを含む。そのような情報の維持に関連して、通信インタフェースシステム１０４又は遠隔プラットフォーム１２０に関連するサービステーブル４０４には、通信インタフェースシステム１０４ａ又は遠隔プラットフォーム１２０に利用可能な各サービス用の静的サービステーブルレコード１７００（図１７Ａ参照）を含み得る。各レコード１７００は、フィールド名１７０４によって識別される複数のフィールドを提供し得る。レコード１７００には、更に、データタイプ１７０８及びフィールド記述１７１２等の各フィールド名１７０４に対応する情報を含み得る。例えば、名前フィールドは、管理されるアプリケーションの名前を指定し得る。また、サービス実行可能フィールドは、呼び出される実行可能な画像を指定し得る。開始時間フィールドが提供され、アプリケーションが起動時又はオンデマンドで開始されるべきか否かを指定し得る。実行可能なＩＤフィールドは、実行可能な画像用のユニークなＩＤを指定する。また、サービスクラス及びサービスタイプフィールドは、利用可能なサービスを更に分類整理するために提供され、補助フィールドは、更なるサービス記述情報のために提供され得る。最大参照数フィールドは、サービスへの最大の同時接続数を指定する。遠隔アクセスフィールドは、遠隔プラットフォーム上のアプリケーションからのアクセスが許可されるか否かを指定する。状態頻度フィールドは、接続フレームワークプロセス監視の状態を指定するために提供し得る。また、状態タイムアウトフィールドは、状態要求に応答するために許される最大時間を指定する。再開方針フィールドは、タイムアウトに応答して行われるアクションを指定する。例えば、アプリケーションは状態応答タイムアウト時に終了されてもよく、再開されてもよい。権限フィールドは、クライアントがサービスに接続するのに必要な権限を指定するために提供し得る。
【００９８】
次に、図１７Ｂにおいて、サービステーブル４０４の一部として維持される動的サービステーブルレコード１７１６の一部として提供し得るフィールドを示す。動的サービステーブルレコード１７１６の一部として維持し得るそのようなフィールドの例としては、サービスに割り当てられるサービスＩＤが挙げられる。現在のサービスへの接続数を含むフィールドも提供し得る。更に、これを通して接続フレームワークプロセス２１０がサービスを提供するサービスエンジン４１６と通信を行う制御チャネルを提供し得る。サービス状態フィールドは、サービスが、呼び出されていないか、呼び出されたか、実行中か、又は、応答していないかを示すために、動的サービステーブルレコード１７１６の一部として含み得る。従って、動的サービステーブルレコードに含まれるレコードは、システム１００の通常動作中に変化するサービスに関する情報用のフィールドを含むことが認識される。更に、静的なサービステーブルレコード１７００は、頻繁には変化しない情報並びにアプリケーション及びサービスの動作の開始点を提供する情報を含むことが認識される。本明細書において提供される説明から当業者には認識されるように、静的サービステーブルレコード１７００は不揮発性メモリに記憶されてよく、動的サービステーブルレコード１７１６は揮発性メモリに記憶されてよい。更に、静的及び動的レコードは、単一の組合せレコードとして維持されてよい。
【００９９】
動的サービステーブルレコード１７１６に含み得るフィールドの例としては、レコード１７１６が関係するサービスのサービス識別子を指定するサービスＩＤフィールドが挙げられる。サービスクラスフィールドは、特定のサービスが属するクラスを指定し得る。他方、サービスタイプフィールドは、サービスタイプを指定する。参照カウントフィールドを提供して、サービスに現在接続されている（例えば、個別のアプリケーション４２２からの）接続数を示し得る。最大参照値フィールドを提供して、任意の時間に維持し得るサービスへの同時接続の最大数を示し得る。また、サービスへの遠隔アクセスが許可されるか否かを示すためのフィールドを提供し得る。接続フレームワークプロセス２１０によって用いられサービスを提供するサービスエンジンと通信を行い得る制御チャネルを識別するために、制御タイプフィールドを提供し得る。追加の一例として、サービス状態フィールドを提供して、サービスの現在のサービス状態を示し得る。フィールドの適切な値は、
各フィールドに関連付けられたデータタイプ１７０８によって指定し得る。例えば、データタイプ１７０８は、データワード又はブール文字列であってよい。
【０１００】
サービス開始テーブル４１０は、プラットフォーム（即ち、対象のサービス開始テーブル４１０が確立される通信インタフェースシステム１０４又は遠隔プラットフォーム１２０）に対してローカルなサービスエンジンに関する情報を含む。一般的に、各サービス開始テーブル４１０は、プラットフォーム１０４又は１２０上の各サービスエンジン用のレコードを含み得る。次に、図１８において、サービス開始テーブル４１０のレコード１８００の例を示す。各レコード１８００には、フィールド名１８０４、データタイプ１８０８及びフィールド記述１８１２によって識別される、複数のフィールドを含み得る。個々のフィールドには、名前毎にレコード１８００が関係するサービスエンジンを識別するサービスエンジンフィールドと、そのサービスエンジンの実行可能なファイルに対する参照を提供するサービス実行可能フィールドとを含み得る。開始時間フィールドは、起動時に実行可能であるか、又はオンデマンドで（即ち、サービス要求に応じて）実行可能であるかを示すために提供し得る。状態頻度フィールドを提供して、通信フレームワークプロセス２１０がサービスの状態を監視すべき頻度を示し得る。また、サービスクラス及びサービスタイプを指定するためのフィールドも含み得る。更に、サービスが状態要求に応答することの許される最大時間を示す、状態応答フィールドを提供し得る。追加の一例として、サービスが最大指定時間内に状態要求への応答を失敗した場合に行われるアクションを示す再開方針フィールドを示し得る。
【０１０１】
次に、図１９において、様々な装置間における情報交換を簡易化する際、本発明の一実施形態に基づく通信インタフェースシステム１０４の使用を伴うシナリオ例を示す。最初に、ステップ１９００において、通信インタフェースシステム１０４上で動作する事故警告アプリケーション４２２は、利用可能なサービスを決定するためにサービステーブル４０４に問い合わせを行う。ステップ１９０４において、事故警告アプリケーション４２２は、ＯＢＤ−ＩＩ車両事故サービスエンジン４１６を通して、車両バスから利用可能な有効な安全情報を申し込む。特に、車両事故検出サービスエンジン４１６は、例えば、ＯＢＤ−ＩＩインタフェース４２０において車両バスに物理的な相互接続を提供するドーターカードの一部として提供されるポートと共に動作し得る。更に、事故警告アプリケーション４２２は、携帯電話１２４から利用可能な通信サービスを申し込む。本明細書において提供される説明から認識されるように、携帯電話１２４には、標準通信インタフェース４２４を通して通信インタフェースシステム１０４に相互接続された遠隔プラットフォーム１２０を含み得る。これに代えて、携帯電話１２４は、例えば、携帯電話１２４が、特別に設けられたアダプタ又はポートを通して相互接続される場合、サービスエンジン４１６を通して通信インタフェースシステム１０４に相互接続し得る。
【０１０２】
ステップ１９０８において、車両事故検出サービスエンジン４１６は、車両バスから事故表示を受信する。そのような事故表示は、例えば、エアバッグが点火されたという有効安全システム表示の形態であってよい。ステップ１９１２において、車両事故検出サービスエンジン４１６は、接続フレームワークプロセス２１０によって維持されるイベントテーブル４０８にメッセージを投稿する。事故メッセージ用の登録申し込みとして、車両事故検出サービスエンジン４１６によって投稿された事故メッセージが、事故警告アプリケーション４２２に渡される（ステップ１９１６）。
【０１０３】
ステップ１９２０において、事故警告アプリケーションは、ＧＰＳサービスエンジン４１６においてブルートゥース無線インタフェースを通して通信インタフェースシステム１０４に相互接続されたＧＰＳ装置４２０に位置情報を要求する。この要求は、必要に応じて、ＧＰＳサービスエンジン４１６によってフォーマット化され、ＧＰＳサービスエンジン４１６に渡される。ステップ１９２４において、要求された情報が事故警告アプリケー
ションに返される。
【０１０４】
ステップ１９２８において、事故警告アプリケーション４２２は、緊急サービスセンタを呼び出すように、通信インタフェースシステム１０４に相互接続された電話１２４に指示する。事故警告アプリケーション４２２は、テキスト・音声変換モジュールに位置情報を送信（ステップ１９３２）し、緊急サービスセンタオペレータに音声によって車両の位置が渡される（ステップ１９３６）。
【０１０５】
図１９に関連して提示されたシナリオの例から、本発明の実施形態は、強化されたユーザサービスを提供するために複数の異なる通信リンクを用いて、利用可能なサービスを集合化し得ることが認識される。更に、サービス及びイベントを広告し申し込むのに必要なメッセージの送受信とは別に、アプリケーション及びサービスが通信インタフェースシステムを通して又はそれに関連して相互運用するように特別に構成される必要がない。更に、装置がそれらの固有の通信能力を用いて、通信インタフェースシステム１０４を通して互いに通信を行い得ることが認識される。特に、装置又は遠隔プラットフォームと通信インタフェースシステム１０４との通信を可能とする複数の異なる通信インタフェース、例えば、有線インタフェース３２４又は無線インタフェース３２８を提供することによって、複数の異なる通信リンク技術をサポートし得る。
【０１０６】
次に、図２０において、代表的なシナリオにおける通信インタフェースシステム１０４の使用方法を示すが、このシナリオに従って、車両に関連する動作パラメータが診断のために遠隔サービスセンタに提供される。特に、車両２００４内に配置された通信インタフェースシステム１０４は、ＯＢＤ−ＩＩインタフェース等の車両電子回路インタフェースが含まれる装置４２０．１を通して車両バス２００８に相互接続される。通信インタフェースシステム１０４の一部として提供されたサービスエンジン４１６は、車両電子回路インタフェース４２０．１に提供される。
【０１０７】
車両バス２００８から取得されるデータは、サービスエンジン４２０．１によってローカルエリアネットワーク（ＬＡＮインタフェース）が含まれる通信インタフェース４２０．１に提供され、そして、ＬＡＮインタフェース４２４．１によって、遠隔プラットフォーム１２０．１に渡し得る。遠隔プラットフォーム１２０．１には、ワイドエリアネットワークデータプラットフォームを含み得る。遠隔プラットフォーム１２０．１には、ＬＡＮインタフェース４２４．１に対して補完的な通信インタフェース４２４．２が含まれる。ＷＡＮデータプラットフォーム１２０．１上のＬＡＮインタフェース４２４．２から、車両バス２００８から取得されたデータは、ワイドエリアネットワークインタフェース（ＷＡＮインタフェース）を含み、やはりＷＡＮデータプラットフォーム１２０．１上にある通信インタフェース４２４．３に渡し得る。
【０１０８】
次いで、ＷＡＮインタフェース４２４．３は、サービスセンタ２０１２に関連付けられた補完的な通信インタフェース４２４．４にデータを送信し得る。更に、サービスセンタ２０１２に関連付けられた通信インタフェース４２４．４又はＷＡＮインタフェースは、遠隔プラットフォーム１２０．２の一部として（即ち、接続フレームワークプロセス２１０使用可能プラットフォームとして）提供し得る。これに代えて、サービスセンタ２０１２に関連付けられた通信インタフェース４２４．４には、装置４２０．２を含み得るが、この場合、車両２００４におけるＷＡＮデータプラットフォーム１２０．１のＷＡＮインタフェース４２４．３は、サービスエンジン４１６（図２０に図示せず）を通してそのプラットフォームのローカルエリアネットワーク通信インタフェース４２４．２と通信を行う。サービスセンタ２０１２に関連付けられたワイドエリアネットワークインタフェース４２４から、車両バス２００８から取得されたデータがサービスファシリティ２０１６に提供される。サービスファシリティは、ＷＡＮインタフェース４２４．４を備える装置４
２０．２の一部であってもよく、別個の装置４２０として遠隔プラットフォーム１２０．２に相互接続されてもよい。
【０１０９】
通信インタフェースシステム１０４には、接続フレームワークプロセス２１０使用可能携帯電話１２４を含み得るが、この場合、通信インタフェースシステム１０４には、携帯電話通信インタフェース４２４．５を含み得る。本明細書において提供される説明から当業者には認識されるように、そのようなセルラー式通信インタフェース４２４．５は、サービスセンタ２０１２に車両バス２００８からのデータを配信するための代替手段を提供し得る。
【０１１０】
様々な通信リンク技術が、図２０に関連して説明された通信インタフェース４２４と関連付け得る。例えば、通信インタフェースシステム１０４には、セルラー式通信インタフェース４２４．５に加えてＷｉＦｉインタフェース等の無線ローカルエリアネットワークが含まれるローカルエリアネットワーク通信インタフェース４２４．１を含み得る。一般的に、遠隔プラットフォーム１２０．１に関連付けられたローカルエリアネットワークインタフェース４２４．２は、通信インタフェースシステム１０４のローカルエリアネットワークインタフェース４２４．１によって適用される通信リンク技術をサポートする。従って、引き続き本例において、遠隔プラットフォーム１２０．１のローカルエリアネットワークインタフェース４２４．２には、ＷｉＦｉ等の無線ローカルエリアネットワークを含み得る。遠隔プラットフォーム１２０．１の一部として提供されるワイドエリアネットワークインタフェース４２４．３によって用いられる通信リンク技術の例としては、ＷｉＭａｘ又はＷｉＭｏｂｉｌｅが挙げられる。そして、サービスセンタ２０１２に関連付けられたワイドエリアネットワークインタフェース４２４．４は、遠隔プラットフォーム１２０．１のワイドエリアネットワークインタフェース４２４．４の通信リンク技術をサポートし得る。
【０１１１】
当業者には認識されるように、通信インタフェースシステム１０４又は遠隔プラットフォーム１２０と関連付け得る接続フレームワークプロセス２１０又はサービスエンジン４１６等の様々な構成要素は、関連する説明を理解しやすいように、図２０からは省略した。しかしながら、本明細書の別の箇所において述べるように、そのような構成要素が含まれてもよい。更に、サービスセンタ２０１２と車両バス２００８との間の通信は、双方向であってよいことが認識される。例えば、サービスセンタ２０１２に提供された車両パラメータに関するデータに応答して、サービスセンタ２０１２は車両２００４の動作の修正を生じる命令を発行し得る。
【０１１２】
本明細書において提供される説明から、通信インタフェースシステム１０４は、異なる装置及び／又はアプリケーション間のデータの交換を含むそれらの相互運用を可能にするハブとして機能し得ることが認識される。更に、１つ又は複数の遠隔プラットフォームと接続した状態で用いられる場合、複数のそのようなハブは、相互接続し得る。
【０１１３】
次に、図２１において、本発明の実施形態に基づく通信システム１００の構成要素を示す。より詳細には、通信インタフェースシステム１０４を、遠隔プラットフォーム１２０に相互接続された状態で示す。図２１に示す通信インタフェースシステム１０４には、少なくとも１つ又は複数の態様において、遠隔プラットフォーム１２０の能力を超える又は補完し得る能力を有するサービスプラットフォームが含まれる。例えば、通信インタフェースシステム１０４には、携帯電話ハンドセットを含む遠隔プラットフォーム１２０と通信を行うＷｉｎ３２ベースの演算システムを含み得る。サービスプラットフォームとして機能する通信インタフェースシステム１０４と接続して利用可能なサービスファシリティには、様々なユーザ入力装置２１００及びユーザ出力装置２１０２を含み得る。ユーザ入力装置２１００の例としては、ポインティングデバイス、キーボード、キーパッド、マイ
クロホン及びタッチスクリーンが挙げられる。ユーザ出力装置２１０２の例としては、タッチスクリーン入力装置２１００を備えた視覚的なディスプレイを含む映像ディスプレイ及びスピーカが挙げられる。
【０１１４】
通信インタフェースシステム１０４には、一般的に、接続フレームワークプロセス２１０が含まれ、これは、サービステーブル、イベントテーブル及びサービス初期化テーブルを提供し得る。更に、接続フレームワークプロセス２１０は、通信プロセスランタイムサービス／イベントインタフェースを提供し得る。
【０１１５】
また、通信インタフェースシステム１０４には、一般的に、サービスエンジン４１６が含まれる。サービスエンジン４１６により、遠隔プラットフォーム１２０上のアプリケーションは、標準の一組の命令を用いて、通信システムインタフェース１０４上のサービスファシリティを発見し利用することが可能になる。更に、サービスエンジン４１６は、通信インタフェースシステム１０４上で動作するサービス４２０と遠隔プラットフォーム１２０上で動作するアプリケーション４２２との間の双方向の通信を可能にし得る。従って、サービスエンジン４１６は、通信インタフェースシステム１０４上で動作する又は通信インタフェースシステム１０４を通して利用可能なサービス４２０と通信を行う。一例として、サービス４２０には、ブラウザアプリケーション２１０８と組み合わせたウェブサーバ２１０４を含み得る。汎用ブラウザ２１０８によっては提供されない、本明細書において説明される一定の機能を実施する又は可能とするために、プラグイン２１１０がブラウザ２１０８と関連付けられてよい。サービス４２０には、それ自体、サービスファシリティを含み得る。また、サービス４２０は、１つ又は複数のユーザ入力装置２１００、ユーザ出力装置２１０２、又は他の通信インタフェースシステム１０４機能若しくは装置と組み合わせて動作して、遠隔プラットフォーム上で動作するアプリケーション４２２によって用い得るサーバサービスファシリティを提供し得る。例えば、ブラウザ及びユーザ出力装置２１０２が含まれるサービス４２０には、コンテンツを表示するために遠隔プラットフォーム１２０のアプリケーション４２２によって用い得るサービスファシリティを含み得る。総括すると、サービスエンジン４１６及びサービス４２０には、遠隔プラットフォーム１２０上のアプリケーション４２２を含むアプリケーション又はプラットフォームが利用可能な資源又はサービスが含まれる。図２１の例において、資源には、表示装置が含まれるユーザ出力装置２１０２と組み合わせて動作する表示サービスが含まれる。しかしながら、本発明の実施形態は、そのように制限されない。例えば、サービスには、音声出力、音声入力、手動入力、処理その他、遠隔プラットフォーム１２０の機能を超える能力を有する又はそれを少なくとも補完するサービスを含み得る。
【０１１６】
また、標準通信インタフェース又はインタフェースエンジン４２４も提供される。インタフェースエンジン４２４は、一般的に、通信インタフェースシステム１０４上の接続フレームワークプロセス２１０及びサービスエンジン４１６と通信を行う。更に、インタフェースエンジン４２４は、遠隔プラットフォーム又はプラットフォーム１２０によって通信インタフェースシステム１０４上のサービス４２０へのアクセスを簡易化する。
【０１１７】
一般的に、遠隔プラットフォーム１２０には、接続フレームワークプロセス２１０及びインタフェースエンジン４２４（図２１では、組み合わせて示す）が含まれる。本明細書の別の箇所で説明するように、一般的に、接続フレームワークプロセス２１０及びインタフェースエンジン４２４は、遠隔プラットフォーム１２０に関連する又は遠隔プラットフォーム１２０上で動作するアプリケーション４２２等のエンティティと、通信インタフェースシステム１０４に関連する又は通信インタフェースシステム１０４上で動作する装置又はエンティティとの間の通信を簡易化し可能にするように機能する。
【０１１８】
また、遠隔プラットフォーム１２０には、ユーザ入力装置２１１２及びユーザ出力装置
２１１６を含み得る。例えば、携帯電話が含まれる遠隔プラットフォーム１２０に関連して、ユーザ入力装置２１１２には、キーパッド、ソフトキー、及びマイクロホンを含み得る。更に、マイクロホンが含まれるユーザ入力装置２１１２は、音声起動命令機能に接続して用い得る。ユーザ出力装置２１１６の例としては、液晶表示装置（ＬＣＤ）等の視覚的な表示装置、スピーカ、呼び出しベル及び表示ランプが挙げられる。
【０１１９】
また、遠隔プラットフォーム１２０には、一般的に、アプリケーション又はアプレット４２２が含まれる。例えば、アプリケーション又はアプレット４２２には、遠隔プラットフォーム１２０に固有の機能、又はユーザが遠隔プラットフォーム１２０上で若しくは遠隔プラットフォーム１２０に接続して選択的に動作させ得るアプリケーションを含み得る。更に、アプリケーション４２２には、ユーザインタフェースが含まれるコンテンツを提供する機能を含み得る。そのようなコンテンツには、視覚的及び／又は音声コンテンツを含み得る。例えば、アプリケーション４２２は、視覚的なコンテンツを生成その他、提供して表示し得る。従って、遠隔プラットフォームは、視覚的な表示装置が含まれるユーザ出力装置２１１６を用いてコンテンツを表示することが可能なアプリケーション４２２が含まれるクライアントサービスファシリティを提供し得る。当業者には認識されるように、携帯電話等の比較的小さい視覚的な表示装置２１１６を備えた携帯装置が遠隔プラットフォーム１２０に含まれる場合、遠隔プラットフォーム１２０の領域における強化された表示能力にアクセスすることが望ましい。以下の議論のほとんどは、通信インタフェースシステム１０４の視覚的な表示能力を用いて、移動又は携帯電話等の移動装置が含まれる遠隔プラットフォーム１２０上のアプリケーション４２０によって提供されるコンテンツを表示する例に関するが、サービスプラットフォームとして機能する通信インタフェースシステム１０４によって他のサービスファシリティを提供し得ること、また、アプリケーション４２２によって他の種類のコンテンツを提供し得ることが認識される。例えば、音声コンテンツは、遠隔プラットフォームに接続して提供し得る。更に、遠隔プラットフォーム１２０は、移動又は携帯電話に限定されない。例えば、携帯音楽プレーヤ、ハンドヘルドコンピュータ、携帯情報端末、携帯記憶装置、携帯ＧＰＳ受信機又は任意の他の装置に遠隔プラットフォーム１２０を含み得る。
【０１２０】
次に、図２２において、本発明の実施形態に基づく遠隔プラットフォーム１２０によるサービス発見のためのプロセスの態様を示す。最初に、ステップ２２００において、通信インタフェースシステム１０４上のブラウザ２１０８が、ローカルウェブサーバ２１０４に現れてそれを既定ページとしてヒットする。本発明の他の実施形態によれば、ブラウザ２１０８及びウェブサーバ２１０４は、単一又は統合された表示サーバが含まれるサービス４２０に組み合わせ得る。そのような表示サーバ４２０は、セキュリティ機能及びコンテンツアクセス制御を提供して、例えば、携帯装置の表示サービスへのアクセスを制御し、また、コンテンツオーバーレイを制御し得る。更に、統合された表示サーバ４２０は、汎用ブラウザ２１０８とウェブサーバ２１０４との組合せより小型であってよい。更に他の本発明の実施形態によれば、ブラウザ２１０８とウェブサーバ２１０４との組合せは、プラグイン２１１０と関連付け得るが、そうでない場合、プログラムコードを組み込み、所望のセキュリティ機能、コンテンツオーバーレイ及び他の強化策を可能にして、特定タイプ又はクラスのアプリケーション４２２での使用を簡易化し得る。
【０１２１】
既定ページは、表示されると、表示サービスエンジン４１６を呼び出すスクリプトを実行する（ステップ２２０４）。本発明の実施形態によれば、表示サービスエンジン４１６には、ヒューマン・インタフェース・システム・サービス・プログラム又はエンジン（ＨＩＳ−ＳＥ）が含まれる。表示サービスエンジン４１６は呼び出されると、通信インタフェースシステム１０４が含まれるサービスプラットフォーム上で動作する接続フレームワークプロセス２１０を起動して、接続する（ステップ２２０８）。ステップ２２１２において、表示サービスエンジン４１６は、表示制御サービスの利用可能性を接続フレームワ
ークプロセス２１０に投稿する。更に、表示サービスエンジン４１６は、表示データサービスを接続フレームワークプロセス２１０に投稿する（ステップ２２１６）。表示制御サービス及び表示データサービスは、表示サービスエンジン４１６の異なる論理的なスレッドとして実装され得る。特に、表示制御サービスは、アプリケーション固有制御メッセージを取り扱うように動作し、他方、表示データサービスは、本発明の実施形態に基づき、アプリケーション固有の生のＨＴＭＬコンテンツを取り扱うように動作し得る。また、そのようなコンテンツには、データ及び／又は実行可能なコードを含み得る。更に、或る例によってＨＴＭＬを含むマークアップ言語の用途について述べたが、本発明の実施形態は、特定の種類のマークアップ言語に限定されないことが認識される。従って、本発明の実施形態に関連して用い得る他のマークアップ言語の例としては、ＸＭＬ、ＸＨＴＭＬ、ＳＧＭＬ等が挙げられる。
【０１２２】
表示サービスの利用可能性の投稿には、通信インタフェースシステム１０４を通して利用可能な表示属性及び能力に関する投稿情報を含み得る。例えば、色サポート、寸法、解像度又は他の属性等の属性は、広告し得る。更に、サービスの広告には、要求される何らかの資格証明の通知又は広告されたサービスにアクセスするために支払うことが必要な料金を含み得る。
【０１２３】
通信インタフェースシステム１０４及び遠隔プラットフォーム１２０上のインタフェースエンジン４２４は、プラットフォーム１０４，１２０上のサービステーブルの同期化を行うように作用する（ステップ２２２０）。本例によれば、サービスプラットフォーム又は通信インタフェースシステム１０４を遠隔プラットフォーム１２０に相互接続するためにＲＳ−２３２又はユニバーサル・シリアル・バス（ＵＳＢ）リンク等のシリアル通信リンクが用いられることから、インタフェースエンジン４２４にはシリアルインタフェースエンジンが含まれる。しかしながら、本明細書において提供される本開示を考慮すると、他の種類の通信リンク及びインタフェースエンジン４２４を用いてもよいことが、当業者には認識される。
【０１２４】
ステップ２２２４において、遠隔プラットフォーム１２０上の表示クライアント又はアプリケーション４２２が起動し、遠隔プラットフォーム１２０上で動作する接続フレームワークプロセス４２４に接続し、サービスの問い合わせを行う。接続フレームワークプロセス４２４は、サービスエンジン４１６によって広告された表示制御及び表示データサービスで応答する（ステップ２２２８）。表示クライアント４２２には、２つの論理的なスレッド、即ち、制御メッセージを取り扱うための表示制御クライアントと、生のＨＴＭＬデータを表示サービスエンジンに送信するための表示データクライアントと、を含み得る。次いで、表示クライアント４２２は、利用可能な表示制御及び表示データサービスについて通知されることに応答して、表示制御及び表示データサービスを開くように要求し得る（ステップ２２３２）。本発明の実施形態によれば、表示制御及び表示データサービスを開くように要求することに先立って、表示クライアント４２２は、表示装置の適性を評価し得る。更に、表示装置の利用可能性は、遠隔プラットフォーム１２０が含まれる携帯装置のユーザに広告し得る。更に、支払いが要求される場合、サービスを開く前に、ユーザからの認可を要求してよい。
【０１２５】
表示クライアント４２２の要求に応じて、インタフェースエンジン４２４は、表示制御クライアントと表示制御サービスとの間の接続、及び表示データクライアントと表示データサービスとの間の接続を開く（ステップ２２３６）。即ち、別個の制御通信及びデータ通信パイプライン又は通信経路が、表示サービスエンジン４１６及び表示クライアント４２２の論理的なスレッド間に開かれる。更に、表示サービスエンジン４１６とクライアント４２２との間の通信は、ユーザに対して実質的に連続的なコンテンツを提示する間でも断続的であってよい。
【０１２６】
次に、図２３において、表示サービスを提供する通信インタフェースシステム１０４が含まれるシステム１００と、電話等の携帯装置が含まれる遠隔プラットフォーム１２０との動作の態様を示す。特に、例えば、図２２に関連して例示したステップを用いて確立された、通信チャネルを用いたプラットフォーム１０４，１２０の間におけるコンテンツ及び命令の交換の態様を例示する。表示クライアント又はアプリケーション４２２の表示制御クライアントスレッドは、確立メッセージをサービスエンジン４１６の表示制御サービススレッドに送信する（ステップ２３０４）。これに応じて、表示サービス４１６は、利用可能なポートを開き、ポート番号を含む確認応答メッセージをアプリケーション４２２に送り返し、ブラウザ２１０８の１つのインスタンスにそのポート番号をマッピングする（ステップ２３０８）。
【０１２７】
ステップ２３１２において、表示クライアント４２２が表示するページを有するか否かに関して判断を行う。表示クライアント４２２が通信インタフェースシステム１０４の表示サービス４２０を用いて表示するページを有する場合、表示制御クライアントはサービスエンジン４１６の表示制御サービススレッドにメッセージを送信して、ページの準備が整っていることを示す（ステップ２３１６）。次いで、表示制御サービスは、ブラウザ２１０８に関連付けられたプラグイン２１１０にメッセージを転送する（ステップ２３２０）。プラグイン２１１０は、要求されたページを読み出すようにブラウザ２１０８に指示するように動作する（ステップ２３２４）。
【０１２８】
ブラウザ２１０８は、ブラウザ２１０８のインスタンス−表示クライアント４２２ペアに割り当てられるポート番号に接続し、示されたファイルを要求する（ステップ２３２８）。サービスエンジン４１６の表示制御サービススレッドは表示クライアントアプリケーション４２２の表示制御クライアントスレッドに要求を転送する（ステップ２３３２）。
【０１２９】
表示クライアントアプリケーション４２２の表示データクライアントスレッドは、要求されたＨＴＭＬページをサービスエンジン４１６の表示データサービススレッドに送信する（ステップ２３３６）。そして、サービスエンジン４１６の表示データサービスは、ページをブラウザ２１０８に転送し、ブラウザ２１０８は、例えば、通信インタフェースシステム１０４に関連付けられた映像出力装置が含まれるユーザ出力装置２１０２上にページを表示する（ステップ２３４０）。
【０１３０】
ステップ２３４４において、ブラウザ２１０８が自動リフレッシュする時間か否かに関して判断を行う。当業者には認識されるように、ブラウザ２１０８には、ウェブサーバ２１０４からの初期ページの受信の一部として、自動リフレッシュレートを割り当て得る。本発明の他の実施形態、例えば、統合された表示サーバが含まれるサービス４２０を用いる実施形態によれば、表示サービス４２０には、表示クライアントアプリケーション４２２等、別のエンティティによって指示された時、リフレッシュ要求を実行するように指示し得る。ブラウザ２１０８が自動リフレッシュを実行すべきであると判断される場合、プロセスはステップ２３２８に戻り、示されたファイルの最新のインスタンスを取得する。ブラウザ２１０８が自動リフレッシュする時間でない場合、表示サービス４２０が中断されたか否かに関して判断する（ステップ２３４８）。サービス４２０が中断していない場合、プロセスはステップ２３４４に戻り、次の自動リフレッシュサイクルを待つ。サービス４２０が中断される場合、プロセスは終了する。
【０１３１】
次に、図２４において、表示サーバとして動作する通信インタフェースシステム１０４が含まれるシステム１００と、携帯装置が含まれ表示クライアントアプリケーション４２２を動作させる遠隔プラットフォーム１２０との動作の更なる態様を示す。特に、本発明の実施形態に基づく、通信インタフェースシステム１０４から遠隔プラットフォーム１２
０へのイベントの送信を示す。最初に、ステップ２４０４において、ブラウザ２１０８によって表示されるページ上でクリックが受信されたか否かに関する判断を行う。即ち、ユーザが通信インタフェースシステム１０４によって提供されるユーザ入力装置２１００との対話を通して入力を行ったか否かを判断し得る。例えば、ユーザは、タッチスクリーン表示装置、表示装置に接続して動作されるポインティングデバイス、キーボードその他、通信インタフェースシステム１０４に関連付けられたユーザ入力装置２１００を通して入力を提供し得る。
【０１３２】
クリック等の入力、即ち、表示された項目の選択が受信されたと判断される場合、入力は、ウェブサーバ２１０４に送信され、更に、表示サービスエンジン４１６に送信される（ステップ２４０８）。次いで、表示サービスエンジン４１６は、ブラウザ２１０８によって投稿されたデータへのポインタと共に、入力に関する情報をユーザイベントとして表示クライアント４２２に送信する（ステップ２４１２）。即ち、イベントに関連したメッセージ又は他のデータは、例えば、インタフェースエンジン４２４が通信を行う通信リンクに関連付けられたバッファに投稿される。次いで、表示クライアント４２２は、バッファからデータを読み出し、データを処理する（ステップ２４１６）。従って、イベントに関連付けられたメッセージ又はイベントが含まれるメッセージは、あたかもイベントがクライアントアプリケーション４２２に対してローカルであるかのように、クライアントアプリケーション４２２に伝達される。また、当業者には認識されるように、イベントが含まれるメッセージ又はイベントに関連するメッセージは、データパケットペイロードの一部等のように、クライアントアプリケーション４２２にも直接伝達し得る。例えば、メッセージ又は他のデータは、データを取得するためのＨＴＴＰ「ｇｅｔ」命令として、又はイベント若しくはデータを送信するための「ｐｏｓｔ」命令として、クライアントアプリケーション４２２に伝達し得る。一般的に、イベント、データ及び／又はメッセージが含まれるデータが、クライアントアプリケーション４２２に直接配信される又はクライアントアプリケーションによる読み出しのためにバッファに配置されるか否かは、プラットフォーム１０４，１２０の間の通信リンク９１６に依存し、従って、インタフェースエンジン４２４間において命令及びデータを転送するために用いられる通信プロトコルに依存する。
【０１３３】
ステップ２４２０において、表示サービス４２０を中断すべきか否かに関して判断を行う。また、ステップ２４０４においてブラウザ２１０８によって表示されるページ上でクリックが受信されていないと判断される場合、表示サービス４２０を中断するか否かに関する判断が行われる。サービス４２０が継続する場合、プロセスはステップ２４０４に戻り、クリック又は他のイベントの検出を待つ。サービス４２０が中断される場合、プロセスは終了する。
【０１３４】
次に、図２５において、本発明の実施形態のセキュリティ及びカスタマイズされたコンテンツ態様について述べる。特に、ステップ２５０４において、表示クライアントアプリケーション４２２のインスタンスが識別される。例えば、表示サービスエンジン４１６は、表示クライアントアプリケーション４２２のインスタンスを識別する。次いで、表示クライアントアプリケーション４２２のインスタンスが認証されたか否か及び／又は通信インタフェースシステム１０４から利用可能な表示サービス４２０の使用が認可されるか否かに関する判断を行い得る（ステップ２５０８）。表示サービス４２０の使用が認可される場合、表示サービスの使用が許可される（ステップ２５１２）。この認可には、ユーザ及び／又は遠隔プラットフォーム１２０から支払い情報を取得する工程を含み得る。
【０１３５】
次いで、ローカル又は個人専用のコンテンツが識別された表示クライアントアプリケーション４２２のインスタンス用のブラウザ２１０８のホスト（即ち、通信インタフェースシステム１０４）から利用可能であるか否かに関する判断を行い得る。ローカル又は個人
専用のコンテンツが利用可能である場合、表示サービス上の表示クライアントアプリケーション４２２からのコンテンツの表現は、例えば、そのコンテンツをスキニングすることによってカスタマイズされる（ステップ２５２０）。そのようなカスタマイズされたコンテンツの例としては、例えば、通信インタフェースシステム１０４の供給元若しくは製造業者に関連付けられた広告ロゴの表示、又は識別された表示クライアントアプリケーション４２２若しくは表示クライアントアプリケーション４２２の登録されたユーザに特に適すると判断される通信インタフェースシステム１０４上に維持される若しくは通信インタフェースシステム１０４に関連するコンテンツを挙げることができる。表示クライアントアプリケーション４２２のインスタンスが表示サービス４２０を用いることについて認証又は認可されていない場合、又は表示サービス４２０の使用を許可するが、ローカル若しくは個人専用のコンテンツが利用可能でないと判断した後、カスタマイズされた若しくは個人専用のコンテンツを認証及び選択するプロセスは終了する。
【０１３６】
本発明の実施形態によれば、サーバプラットフォーム又は通信インタフェースシステム１０４によって提供されるファシリティを通してユーザに提示されるコンテンツは、複数の発信源から生じ得る。例えば、コンテンツのスキニングには、通信インタフェースシステム１０４に固有の又はそれに関連付けられた発信源からのコンテンツをクライアントアプリケーション４２２からのコンテンツと組み合わせる工程を含み得る。例えば、通信インタフェースシステム１０４は、通信インタフェースシステム１０４に対してローカルな発信源から生じるコンテンツからなるフレームを生成し、クライアントアプリケーション４２２から提供されるコンテンツは、そのフレームによって含まれ得る。更なる一例として、通信インタフェースシステム１０４によって提供される表示資源は、異なる発信源からのコンテンツを、例えば、異なるフレームで同時に表示し得る。更に、そのようなコンテンツの発信源には、クライアントアプリケーション４２２に関連付けられた発信源及び通信インタフェースシステム１０４に関連付けられた発信源を含み得る。一例として、通信インタフェースシステムが自動車に関連付けられている場合、その自動車の動作パラメータに関するコンテンツの発信源は、第１フレームに表示される。他方、歌その他の音声コンテンツを含むコンテンツ用のコンテナとして用いられる携帯電話が含まれる遠隔プラットフォーム１２０の動作の態様を制御するために選択し得るメニュー項目が含まれるコンテンツは、第２フレームに表示し得る。
【０１３７】
次に、図２６において、本発明の更なる実施形態に基づく通信システム１００の構成要素を示す。一般的に、図２６に示す通信システム１００は、図２１に示す通信システム１００と同様である。しかしながら、図２６の通信システム１００には、表示資源２６０４を含むサービスが含まれる。表示資源２６０４には、ブラウザ２１０８と、図２１に示す実施形態に含まれるウェブサーバ２１０４の機能を組み込むヒューマン・インタフェース・システム・サービスエンジン（ＨＩＳ−ＳＥ）４１６と、が含まれる。従って、図２６に示す通信システム１００は、別個のウェブサーバ２１０４を含まない。
【０１３８】
一般的に、通信システムインタフェース１０４は、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（商標）システム上で動作する構成要素を備えたサービスプラットフォームを含み得る。例えば、通信インタフェースシステム１０４には、自動車ヘッドユニット及び／又はコンピュータシステム、例えば、ナビゲーション及び／又はオーディオシステムを提供し、ＷｉｎｄｏｗｓＣＥ（商標）自動車オペレーティング・システムを動作させるシステムを含み得る。更に、ブラウザ２１０８には、Ｎｅｔｓｃａｐｅ（商標）４．８ブラウザ等の標準ブラウザを含み得る。接続フレームワークプロセス２１０は、サービス広告及び発見を簡易化し、また、本明細書の別の箇所において述べるように、広告されたサービスへのアクセスを調整するフレームワークモジュールである。同様に、インタフェースエンジン４２４は、接続フレームワークプロセス２１０と通信を行う。本明細書の別の箇所において述べるように、インタフェースエンジン４２４は、通信インタフェースシステム１０４
のプロセス間通信機構、例えば、ＷＩＮ３２プロセス間通信機構間の変換や、通信インタフェースシステム１０４と遠隔プラットフォーム１２０との間のインタフェースを透明性に取り扱う。更に、インタフェースエンジン４２４は、通信インタフェースシステム１０４上で遠隔プラットフォーム１２０に対して利用可能なサービスの広告及びそれらのサービスへのアクセスを取り扱う。図２６に示すサービスエンジン４１６には、クライアントアプリケーション４２２がブラウザ２１０８の能力を利用できるようにするヒューマン・インタフェース・システム・サービス・エンジン（ＨＩＳ−ＳＥ）が含まれる。
【０１３９】
本発明の代表的な実施形態による遠隔プラットフォーム１２０には、携帯電話、携帯情報端末、携帯音楽プレーヤ、又は他の種類の装置等の移動装置を含み得る。一例によれば、遠隔プラットフォーム１２０には、Ｑｕａｌｃｏｍｍ（商標）から利用可能なＢＲＥＷアプリケーション環境又はプラットフォームを利用する携帯電話が含まれる。遠隔プラットフォーム１２０には、組み合わせられた接続フレームワークプロセス２１０及びインタフェースエンジン４２４が含まれ、これらによって、一般的に、通信インタフェースシステム１０４上の対応する構成要素と同じ能力が提供される。図２６の例において、接続フレームワークプロセス２１０及びインタフェースエンジン４２４は組み合わせられたモジュールとして示すが、この理由は、ＢＲＥＷ環境が通信インタフェースシステム１０４のＷＩＮ３２環境等の他の環境と同じくマルチタスク処理をサポートしないことから、ＢＲＥＷ環境等の一定の環境に接続し、単一の組み合わせられたモジュールにおいてそのようなモジュールの機能を提供することが、より得策であり得るためである。従って、接続フレームワークプロセス２１０又はインタフェースエンジン４２４などのモジュールを、組み合わせモジュールとして提供するか否かは、プラットフォーム１０４，１２０のオペレーティング・システム及び／又は環境に依存し得る。クライアントアプリケーション４２２は、ＢＲＥＷアプレットとして図２６に示す。一般的に、クライアントアプリケーション４２２は、ユーザ入力装置２１００及び／又は２１１２及び／又はユーザ出力装置２１０２及び／又は２１１６と接続して機能を実施することが可能なオペレーティング・システム又はプラットフォーム上で動作するソフトウェアアプリケーションであってよい。
【０１４０】
本発明の実施形態によれば、システム１００は、遠隔プラットフォーム１２０に関連付けられたアプリケーション４２２が、相互接続された通信インタフェースシステム１０４から利用可能な能力を利用する及び／又はそれらと共に動作することを可能にする。一例は、携帯電話、携帯情報端末、若しくはＭＰ３又はＡｐｐｌｅから利用可能なｉＰｏｄ又はｉＰｏｄ  ｐｈｏｔｏ等の他のメディアプレーヤ等の携帯装置が含まれ、また、限定された表示能力を有するか又は表示能力を全く有せず、通信インタフェースシステム１０４に接続して、通信インタフェースシステム１０４のユーザ出力装置２１０２として含まれる表示装置を用いる遠隔プラットフォーム１２０に関連する。特に、本発明の実施形態によるクライアントアプリケーション４２２は、コンテンツをブラウザ２１０８に送信することによって、通信インタフェースシステム１０４上で動作するブラウザ２１０８を操作することが可能である。そのような機能と接続して、サービスエンジン４１６は、クライアントアプリケーション４２２がコンテンツをブラウザ２１０８に送りつけ（ｐｕｓｈ）、そして、ユーザ入力その他、外部発信源からの入力から生じるブラウザ２１０８からの応答を受信するために必要な接続性を提供する。
【０１４１】
ブラウザ２１０８を通したユーザへのコンテンツの提供に関連して、そのようなコンテンツは、ドキュメントオブジェクトモデル（ＤＯＭ）に基づき得るが、これは、ＨＴＭＬページのオブジェクトベースの表現を記述するＷ３Ｃ仕様である。特に、画像、タグ、リンク（ＵＲＬ）、フレーム等のページの全要素は、ＤＯＭで表される。ＪａｖａＳｃｒｉｐｔ、ＶＢｓｃｒｉｐｔ又は他のブラウザサポートのスクリプト言語を用いて、ＤＯＭのオブジェクトは、その場で修正し得る。従って、クライアントアプリケーション４２２は、遠隔プラットフォーム１２０上で動作するアプリケーション４２２の必要に応答して、
ブラウザ２１０８を通して表示されるページを修正し得る。
【０１４２】
ユーザ入力は、ブラウザ２１０８インタフェースによって、（例えば、表示装置又は他のユーザ出力装置２１０２に関連して動作するポインティングデバイス又は他のユーザ入力装置２１００に接続して）収集したり、また、ＨＴＭＬフォームを投稿することによって、遠隔プラットフォーム１２０のクライアントアプリケーション４２２に投稿したりしてよい。スクリプト言語と共に、ユーザ入力は遠隔装置１２０のクライアントアプリケーション４２２への投稿に先立って、「健全性チェック」を行い得る。従って、移動装置が含まれる遠隔プラットフォーム１２０の通常の能力と比較して、自動車ヘッドユニット又は通信インタフェースシステム１０４が含まれる他のコンピュータプラットフォームの一部として提供される表示装置の通常より大きい表示面積は、優位な点として用い得る。更に、クライアントアプリケーション４２２とブラウザ２１０８との間で渡されるデータのコンテンツは、何らかの特定のタイプである必要がない。例えば、クライアントアプリケーション４２２からブラウザ２１０８にデータを提供する工程に関連して、様々なマルチメディアインターネットメッセージ拡張（ＭＩＭＥ）タイプを適用し得る。更に、そのようなデータには、ストリームデジタル媒体や、より静的なデータコンテンツを含み得る。
【０１４３】
次に、図２７において、統合された表示資源２６０４を組み込むシステム１００の動作の態様を示す。最初に、ステップ２７００において、通信インタフェースシステム１０４上の接続フレームワークプロセスモジュール２１０が開始される。接続フレームワークプロセスの開始に関連して、インタフェースエンジン４２４もまた開始して、遠隔プラットフォーム１２０との通信を可能にし得る。例えば、インタフェースエンジン４２４は、接続フレームワークプロセス２１０によって開始し得る。ステップ２７０４において、ＨＩＳ−ＳＥモジュール４１６が開始される。ＨＩＳ−ＳＥ４１６は、開始時、又はＨＩＳ−ＳＥ４１６を通して利用可能なサービスが要求された後に、接続フレームワークプロセス２１０によって開始し得る。開始すると、ＨＩＳ−ＳＥ４１６は、接続フレームワークプロセス２１０に接続し、ＨＩＳ−ＳＥ４１６サービスの利用可能性を広告する。ステップ２７０８において、ブラウザ２１０８が起動される。ブラウザ２１０８は、ＨＩＳ−ＳＥ４１６モジュールによって起動し得る。起動すると、ブラウザ２１０８は、ＨＩＳ−ＳＥ４１６ポートを指定され、ソケット接続が確立される。ＨＩＳ−ＳＥ４１６ポートは、ブラウザ２１０８の「既定ページ」であってよい。
【０１４４】
ブラウザ２１０８とＨＩＳ−ＳＥ４１６との間に接続が確立されると、ＨＩＳ−ＳＥ４１６からブラウザ２１０８に既定のＨＴＭＬページが送信される（ステップ２７１２）。このページは、２つ以上のＨＴＭＬフレーム、即ち、隠し（ｈｉｄｄｅｎ）フレーム及び１つ以上の可視フレームを含む。隠しフレームは、ＨＩＳ−ＳＥ４１６モジュールを意味する発信源ＵＲＬを有する。ブラウザ２１０８はＨＩＳ−ＳＥ４１６への接続を確立し、発信源に隠しフレームを要求する。隠しフレーム発信源のこの接続は、サービス（本例では、表示資源２６０４）が利用可能である間は維持される。既定ＨＴＭＬページには、各フレームのドキュメントオブジェクトへの書き込みを可能とする各可視フレームの機能も含まれる。例えば、そのような機能は、ＪａｖａＳｃｒｉｐｔ機能を通して提供し得る。これらの機能における呼出しを利用して、ＨＩＳ−ＳＥ４１６は、クライアントアプリケーションが要求するときはいつでも、ページ上の任意の可視フレームにコンテンツを送りつけ得る。コンテンツは、サービスが利用可能である間は維持される隠しフレームへの接続を通して送りつけられる。ステップ２７１６において、コンテンツは、ユーザ出力装置２１０２として提供される表示装置を通して表示される。例えば、既定ＨＴＭＬページの表示部は、相互接続された遠隔プラットフォーム１２０上で利用可能なクライアントアプリケーション４２２の分類、又はそのような分類の表示用テンプレート等のＨＴＭＬコンテンツを含み得る。また、通信インタフェースシステム１０４が関連付けられた自動車の製造業者、交通情報発信源、天気予報発信源、デジタルエンターテイメント発信源、又は
他の発信源等のうちの１つ以上の外部発信源から、直接通信インタフェースシステム１０４を通して又は１つ以上の相互接続された遠隔プラットフォーム１２０を通して提供されるか否かにかかわらず、表示される部分はコンテンツを取得し得る。本明細書において提供される説明から当業者には認識されるように、説明されたステップの順番は、変更し得る。
【０１４５】
次に、図２８において、通信リンク９１６を介して通信インタフェースシステム１０４と通信を行う状態で配置され、１つ又は複数のアプリケーション４２２を動作させる携帯電話が含まれる遠隔プラットフォーム１２０の動作の態様を示す。例えば、遠隔プラットフォーム１２０には、ＢＲＥＷアプリケーション４２２用のＢＲＥＷプラットフォームを提供する携帯電話を含み得る。ステップ２８０４において、遠隔プラットフォーム１２０と通信インタフェースシステム１０４との間の通信は、物理的な接続を確立することによって使用可能になる。これには、例えば、ユニバーサル・シリアル・バスの相互接続若しくは他の有線コネクタを通して、又は何らかの他の種類の有線若しくは無線通信チャネルを確立することによって、有線接続を確立する工程を含み得る。ステップ２８０８において、接続フレームワークプロセス及びインタフェースエンジン２１０，４２４が開始される。接続フレームワークインタフェースエンジン２１０，４２４のモジュールは、初期化を行うと、接続フレームワークプロセスプロトコルに従って、通信インタフェースシステム１０４から「Ｅｓｔａｂ」メッセージを受信し、利用可能なサービスのリストが交換される。本発明の実施形態によれば、接続フレームワークプロセス／インタフェースエンジン２１０，４２４のモジュールは、相互接続された通信インタフェースシステム１０４から利用可能であり得るサービスに対するアプリケーション４２２による要求に応答して、開始し得る。
【０１４６】
本例では、ＢＲＥＷアプレットであるクライアントアプリケーション４２２が開始され、表示資源２６０４の利用可能性及び位置を発見するために接続フレームワークプロセスプロトコルが用いられる（ステップ２８１２）。そして、ＢＲＥＷアプレット４２２は、表示資源２６０４のサービスのインスタンスを開く。
【０１４７】
表示資源２６０４のインスタンスを開いた後、ＢＲＥＷアプレット４２２は、通信インタフェースシステム１０４に関連付けられたユーザ出力装置２１０２による表示のためにブラウザ２１０８にコンテンツを送りつける（ステップ２８１６）。このコンテンツは、１つ又は複数のフレームアクセス機能に対する呼出しの形態であってよく、それぞれのフレームドキュメントに書き込まれるコンテンツを表すそれらの機能に引数を渡す。表示されるフレームの態様は、例えば、ドキュメントオブジェクトモデルを用いて、ＢＲＥＷアプレット４２２から修正され得る。更に、ブラウザ２１０８に送りつけられたコンテンツは、隠しフレームを通して表示されるフレームにそのコンテンツを送りつけることによって、ＢＲＥＷアプレット４２２により必要に応じて更新し得る。より詳細には、隠しフレームのヘッダには表示されるフレームを書き込む機能を含み、また、アプレットは、そのような機能への呼出しが含まれるＪａｖａＳｃｒｉｐｔを送信して、関連した表示されるフレームを更新し得る。更に、このことは、隠しフレームが決して終了されない（即ち、永続的である）ことから、いつでも行い得る。
【０１４８】
ブラウザ２１０８によって表示されるページが既定ページ発信源（ＨＩＳ−ＳＥ４１６）に戻るリンクを含む場合、このリンク上でクリックすると、新しい要求（例えば、ＨＴＴＰ「ｇｅｔ」又は「ｐｏｓｔ」）が、ブラウザ２１０８によって生成される。この要求は、ブラウザ２１０８とＨＩＳ−ＳＥ４１６との間の新しいソケット接続を確立する（ステップ２８２０）。そして、ＨＩＳ−ＳＥ４１６は、単純な１バイトアドレスをソケットに割り当て、表示資源２６０４を利用するＢＲＥＷアプレット４２２にこのアドレスを備えた要求を渡し得る（ステップ２８２４）。この要求は、ユーザによってＢＲＥＷアプレ
ット４２２に送信される命令又はアプレット４２２によって用いられる投稿情報を表し得る。ステップ２８２８において、アプレット４２２は、割り当てられたアドレスバイトをその応答の先頭に付加し、そして、そのようにアドレス指定されて、ＨＩＳ−ＳＥ４１６に応答を返す。そして、ＨＩＳ−ＳＥは、アドレスバイトを除去し、適切なソケット（即ち、アドレスバイトによって識別されたソケット）を介して、応答の残りをブラウザ２１０８に渡す（ステップ２８３２）。従って、ブラウザ２１０８の隠しフレームとアプレット４２２からコンテンツを送りつけるためのＨＩＳ−ＳＥ４１６との間において維持される永続的なソケットに加えて、任意の数の過渡的なソケットが、ブラウザ２１０８における又はそれを通したユーザ入力の結果として生成される要求を取り扱うために、確立し得ることが認識される。更に、クライアントアプリケーション４２２からブラウザ２１０８にコンテンツを送りつけるための永続的な隠しフレームの確立を提供する実施形態に関連するブラウザ２１０８は、その目的のためのプラグインを含む必要がないことが認識される。従って、既製のブラウザ２１０８に対する修正又はそれに対する特別な対応は不要である。本明細書において提供される説明から当業者には認識されるように、説明されたステップの順番は変更され得る。
【０１４９】
本発明の更なる実施形態によれば、ＨＩＳ−ＳＥ４１６の機能は、ウェブサーバ２１０４の機能と組み合わせられるだけでなく、ブラウザ２１０８の機能とも組み合わせられて、単一の統合された表示サービス構成要素２６０４を提供する。そのような表示サービス２６０４は、認証されたクライアントアプリケーション４２２が、それらの都合で表示サービス２６０４に接続したり、そこから切断したりすることを許可する。更に、そのような実施形態は、サービスインスタンスが開いたままであるために、ＨＩＳ−ＳＥ４１６とブラウザ２１０８との間に隠しフレームを利用して永続的な接続が維持されることを必要としない。即ち、専用の表示サービス２６０４を提供することによって、従来のブラウザ２１０８の隠しフレームへの永続的なチャネルを要求する代わりに、新しい又は更新されたコンテンツに、そのようなコンテンツがクライアントアプリケーション４２２から利用可能な時、応答する能力を表示サービス２６０４に構築し得る。
【０１５０】
本明細書に含まれる一定の記述は、遠隔プラットフォーム１２０について、ある程度、通信インタフェースシステム１０４より能力が低いものとして説明したが、本発明の実施形態は、そのように限定されない。特に、遠隔プラットフォーム１２０は、サービスプラットフォームとして機能する通信インタフェースシステム１０４の能力及び／又は特徴を拡張し得る（また、そうすることが多い）。例えば、遠隔プラットフォーム１２０は、通信インタフェースシステム１０４には利用可能でないコンテンツ及び／又は接続性を提供し得る。
【０１５１】
更に、本明細書に提供される一定の例は、通信インタフェースシステム１０４上の表示装置へのコンテンツの提供について議論したが、他の形態のコンテンツも提供し得る。例えば、音声コンテンツを提供し得る。更に、通信インタフェースシステム１０４によって提供される表示サービス２６０４は、他のプラットフォームによって又は同じ通信インタフェースシステム１０４によって提供される他のサービスのサポートに提供し得ることが認識される。例えば、音声コンテンツのための記憶媒体として用いられるコンテンツ用電話又は他のコンテナが含まれる遠隔プラットフォーム１２０には、メニュー項目をユーザに表示するために、表示サービス２６０４に申し込むクライアントアプリケーション４２２を含み得る。更に、ユーザは、通信インタフェースシステム１０４の一部として提供されるユーザ入力２１００を通してそれらのメニュー項目から選択し得る。その同じクライアントアプリケーション４２２、又は第１クライアントアプリケーション４２２と協働して動作する別のクライアントアプリケーション４２２は、インタフェースエンジン４２４を通して音声データを通信インタフェースシステム１０４上で動作する別のサービスエンジン４１６に提供し得る。従って、そのような接続性の状況例は、遠隔プラットフォーム
１２０が、携帯電話又は携帯音楽プレーヤを含み、音声コンテンツ用のコンテナとして用いられている場合であり、また、通信インタフェースシステム１０４に自動車のヘッドユニットが含まれる場合であり、この場合、表示装置は、例えば、ナビゲーションシステム及び自動車のステレオシステムが含まれるオーディオシステムに接続して用い得るダッシュボード内取り付け用の表示装置である。
【０１５２】
クライアントアプリケーション４２２及び遠隔プラットフォーム１２０が、通信インタフェースシステム１０４から利用可能な音声能力が含まれるサービスを用いる実施形態の例では、クライアントアプリケーション４２２は、最初に、接続フレームワークプロセス２１０及びインタフェースエンジン４２４を通して利用可能なサービスを発見し識別し得る。クライアントアプリケーション４２２は、サービスプロバイダ（即ち、通信インタフェースシステム）１０４と「オープンサービス」ルーチンを開始する。通信インタフェースシステム又はサービスプロバイダ１０４は、遠隔プラットフォーム１２０上のクライアント４２２へのチャネルを開き、サービスプロバイダ１０４は、永続的にそのチャネル上で新しい情報を「リッスン」する。例えば、サービスに音声／映像サービスが含まれる場合、サービスプロバイダ１０４は、チャネル上でクライアント４２２を新しい音声／視覚情報がないかリッスンする。そのような情報の例は、ＭＰ３音声、ＭＰＥＧ音声／映像、及び生の音声ストリームデータである。クライアントアプリケーション４２２は、ユーザに提示する新しい情報を有する場合、永続的なチャネルを介して、サービスプラットフォーム１０４にその情報を送りつける。これは、サービスプラットフォーム１０４上のサービスからの情報に対してどのような要求もせずに、そのように行われる。このようにサービスは、情報を受信し、それが適切に分かるように、それを描画する。例えば、サービスは、選択して既存の情報を切断して、新しい情報だけを再生してよい。更に、サービスプラットフォーム１０４は、新しい情報と既存の情報とを混ぜたり、既存の情報で新しい情報を時間分割多重化したりしてよい。
【０１５３】
自動車において利用可能な音声サービスの使用を伴うシナリオの一例において、サービスプラットフォーム又は通信インタフェースシステム１０４には自動車ヘッドユニットが含まれ、遠隔プラットフォーム１２０にはＭＰ３の使用可能な携帯電話が含まれる。更に、自動車ヘッドユニットは、如何にしてＭＰ３フォーマット化デジタル音楽を復号するか、また、それを如何にして自動車のステレオシステムを通して再生するかを理解するＭＰ３音声サービスを提供し得る。このＭＰ３音声サービスは、車両内接続フレームワークプロセス２１０にサービスとして登録される。ユーザは、ヘッドユニット１０４に物理的な相互接続又はリンク９１６を提供する受け台において携帯電話１２０を連結することによって、ＭＰ３の使用可能な携帯電話１２０を車両ヘッドユニット１０４と相互接続し得る。携帯電話１２０上のクライアントアプリケーション４２２は、インタフェースエンジン４２４を介して接続フレームワークプロセス２１０と通信を確立し、利用可能なサービスに対して問い合わせを行う。接続フレームワークプロセス２１０は、ＭＰ３音声サービスで応答する。クライアントアプリケーション４２２は、ユーザが電話メニュー上でＭＰ３ファイルを選択するのを待つ。選択が行われると、クライアントアプリケーション４２２は、「オープンサービス」メッセージを介して、音声サービスへの接続を開く。音声サービスは、例えば、音声サービスエンジン４１６の動作によって、ＭＰ３音声を受信し得る通信チャネルで応答する。クライアントアプリケーション４２２は、ヘッドユニット１０４によって提供される音声サービスにＭＰ３符号化音声ストリームを送りつける。音声サービスは、例えば、サービスエンジン４１６の動作を通して、ストリームを復号し、自動車ステレオシステムを通してそれを出力する。携帯電話１２０は、データ端が出現するまで、又は、ユーザによって何らかのアクションが行われて現在のストリームを終了するか又は新しいストリームを開始するまで、継続的にＭＰ３フォーマット化音声を音声サービスに送りつける。
【０１５４】
当業者には認識されるように、サービスプラットフォーム１０４に音声ストリームデータを送りつけることに関する上述の例は、他の箇所に常駐する音声及び／又は映像情報を再生することが可能な従来のメディアプレーヤとは多くの点において異なる。特に、従来のシステムは、通常、何らかの要求機構を介して、メディアプレーヤが情報の読み出しを開始することを要求する。例えば、この要求は、オペレーティング・システムへのファイルオープン呼出しの形態又はＨＴＴＰ「ｇｅｔ」命令である。即ち、コンテンツを含む装置がそのコンテンツをサービスプロバイダに送りつけて再生させる本発明の実施形態とは対照的に、メディアプレーヤは、情報を読み出す必要がある。
【０１５５】
本発明の更なる実施形態によれば、サービスプラットフォーム１０４と遠隔プラットフォーム１２０との間の双方向通信は、例えば、サービスプラットフォーム１０４上で動作するユーザインタフェースサービスと接続して、サポートされる。特に、一旦ユーザインタフェースサービスが発見され識別されると、クライアントアプリケーション４２２は、サービスプラットフォーム１０４との「オープンサービス」を開始する。サービスプラットフォーム１０４は、遠隔プラットフォーム１２０上で動作するクライアントアプリケーション４２２へのチャネルを開き、新しいユーザインタフェース情報がないかそのチャネルを永続的に「リッスン」する。クライアントアプリケーション４２２は、ユーザに提示する新しい情報を有する場合、音声ＸＭＬ等のマークアップページをフォーマット化し、サービスプラットフォーム１０４にそれを送りつける。サービスプラットフォーム１０４は、例えば、ブラウザ２１０８によって表示される文脈中のあるページを既に有している場合でも、新しいページを受信し、それが適切に分かるように、それを提示する。例えば、既存のコンテンツは、新しいコンテンツで置き換えたり、既存のコンテンツ及び新しいコンテンツを互いに追加したり、あるいは、サービスプラットフォーム１０４は、動的に、既存のコンテンツと新しいコンテンツの表示を切換えたりし得る。更に、クライアントアプリケーション４２２によって提供されるコンテンツ、即ち、例えば、表示サービスによって出力されるコンテンツは、他のサービスに関連する機能を提供し得る。例えば、サービスプラットフォーム１０４のサービスとして提供される自動音声認識システムは、クライアントアプリケーション４２２からのコンテンツを含む新しいページに含まれるワードが認識される場合、通知をクライアントアプリケーション４２２に送り返し得る。通知に応じて、クライアントアプリケーション４２２は、新しいページのフォーマット化を選択し、それをサービスプロバイダ１０４に送りつけたり、あるいは、何らかの他のアクションを起こし得る。従って、遠隔プラットフォーム１２０上で動作するクライアントアプリケーション４２２は、リアルタイムで、どのユーザインタフェースが文脈内にあるか命令する。特に、クライアントアプリケーション４２２は、何らかのユーザアクションに基づきサービスがページを要求するのを待たない。
【０１５６】
双方向通信を伴うシナリオの一例において、音声ユーザインタフェースサービスは、自動車のヘッドユニットが含まれるサービスプラットフォーム１０４を通して利用可能であり得る。既定値によって、このユーザインタフェースは、暖房、ラジオ、座席調整、又は自動車に関連する他の機能を制御し得る。本発明の実施形態によれば、音声ユーザインタフェースサービスは、その利用可能性を接続フレームワークプロセス２１０に登録する。ユーザがＭＰ３機能の携帯電話１２０を自動車に持ち込み、それを受け台に連結すると、クライアントアプリケーション４２２は遠隔プラットフォーム１２０に関連付けられた接続フレームワークプロセス２１０を通して、及びインタフェースエンジン４２４を通して、車両内接続フレームワークプロセス２１０との通信を確立し得る。従って、クライアントアプリケーション４２２は、接続フレームワークプロセス２１０を通して、音声ユーザインタフェースが利用可能であると判断し、そして、クライアントアプリケーション４２２は、「オープンサービス」命令を介して、音声ユーザインタフェースサービスへの接続を開き得る。音声サービスは、アプリケーションデータの有無について、リッスンしているチャネル識別子で返信する。そして、クライアントアプリケーション４２２は、それが
音声ユーザインタフェースサービスに送信する音声ＸＭＬページを構成し得る。このドキュメントは、文法の一部として認識ワード「ＭＰ３」を備えた音声対話システムを表す音声ユーザインタフェースサービスは、この文法ワードをその現在のページに追加する。従って、現在の組の利用可能なユーザ命令は、例えば、「暖房」、「ラジオ」、「座席」及び「ＭＰ３」を含み得る。ユーザがワード「ＭＰ３」と言うと、音声ユーザインタフェースサービスに関連付けられた自動音声認識装置は、このワードを認識し、このイベントの通知（即ち、ワード「ＭＰ３」の認識）が、クライアントアプリケーション４２２に送り返される。これに応じて、クライアントアプリケーション４２２は、そのメモリからＭＰ３歌題名のリストを読み出し、これらの歌題名からなる新しいページを構成し、それを音声サービスに送信する。そして、音声サービスは、例えば、「トラック番号１」、「トラック番号２」等を含むように、その現在の状況を更新し得る。ユーザが、例えば、「トラック番号１」と言うと、通知がクライアントアプリケーション４２２送り返され、クライアントアプリケーション４２２は、そのメモリにあるトラック番号１用のストリームＭＰ３フォーマット化データで応答する。
【０１５７】
クライアントアプリケーション４２２は、音声ユーザインタフェースサービスに新しいページを自由にいつでも送りつける。例えば、遠隔プラットフォーム１２０上のクライアントアプリケーション４２２がＭＰ３ファイル又はページを音声ユーザインタフェースサービスに送りつけており、その間、同時にナビゲーションアプリケーションとして動作している又は動作していて、進路変更が間近に必要な場合、クライアントアプリケーション４２２は、現在の情報伝達の停止を選択し、適切な音声プロンプト（「ここで左折」）を再生し得る。そして、クライアントアプリケーション４２２は、ＭＰ３ストリームを再開し得る。更に、１つのクライアントアプリケーション４２２が、要求されたトラックが含まれる音声コンテンツを提供しており、その間、他のクライアントアプリケーション４２２若しくは他のサービスが、サービスプラットフォーム１０４若しくは他の遠隔プラットフォーム１２０上で動作しており、又は、例えば、ナビゲーション情報を提供するように動作している場合、そのような他のクライアントアプリケーション４２２又はサービスは、ＭＰ３音声ストリームの再生に割込み、ナビゲーション情報を提供し得る。ＭＰ３音声ストリームに割込み、これらの例によるナビゲーション情報を提供するために、サービスプロバイダは、新しいページに対する要求を発行する必要がないことに留意すべきである。その代わり、各クライアントアプリケーション４２２又は音声情報を有するサービスは、音声情報が含まれるデータを音声サービスに独立に送りつけ得る。従って、複数のストリームのそのような情報が提示される際、如何に最適に音声情報を提示するか判断するのは音声サービス次第である。
【０１５８】
同様に、遠隔プラットフォーム上で動作するクライアントアプリケーション４２２は、「ＭＰ３」及び「電話制御」からなるユーザインタフェースを表すページを送りつけた場合、電話イベントの発生に基づき、そのページを更新し得る。例えば、着信電話呼出しが起こった場合、音声サービスによって求められておらず有効な認識ワードを「応答」、「保留」又は「無音」のみにする新しいページを電話は送りつけ得る。ワード「ＭＰ３」が含まれた以前のページは、もはや文脈中にない。
【０１５９】
本明細書に提供される説明を解釈した後、そのような実施形態が、音声ＸＭＬブラウザを実現するもの等の従来のシステムとは異なることは、当業者には認識される。特に、従来技術において、音声ＸＭＬブラウザは、ＨＴＴＰ：Ｇｅｔ命令を用いて、サーバからの音声ＸＭＬページに対する要求を介して、ユーザデータ表現を行い得る。サーバは、ユーザインタフェースを表す音声ＸＭＬページでこの要求に応答する。このページは、（音声ブラウザからの他の要求を介して、）再生する或る音声ファイルの位置のように単純であってよいし、又は、完全な対話システム表現のように複雑であってもよい。後者の場合、ローカルの自動音声認識システムは、音声ＸＭＬページに提示された任意のワードのユー
ザによる発声がないかリッスンする。ワードが認識されると、ブラウザは、音声ＸＭＬページから、どの新しいページが読み出されるべきか判断し、サーバに対して他のページ要求を行う。サーバは、新しいページで応答し、プロセスは、それ自体を繰り返す。一旦サーバが、要求に応じてページを送信すると、それは、もはやユーザインタフェースの制御の下にはないことを更に留意されたい。特に、サーバは、音声ブラウザが情報に対する他の要求を送信するのを待つ必要がある。
【０１６０】
本発明の実施形態は、遠隔プラットフォーム１２０にサービスを提供し得る汎用デスクトップコンピュータ又は他の何らかのプラットフォーム等の静止型のプラットフォームが含まれる通信システムインタフェース１０４への遠隔プラットフォーム１２０の相互接続に関連して用い得ることを移動環境に加えて認識すべきである。例えば、通信システムインタフェース１０４には、移動プラットフォーム１２０に又はそれと協働してサービスを提供することが可能な汎用デスクトップを含み得る。そのようなサービスには、バッテリ充電、高帯域幅エリアネットワーク接続、マルチリンク機能、外部無線周波数アンテナ、カラー及び／又は高解像度モニタ、ステレオスピーカ及びデータ記憶装置を含み得る。
【０１６１】
音声サービス等のサービスを提供することに加えて、通信インタフェースシステム１０４と遠隔プラットフォーム１２０との組合せは、マルチメディア用途に用い得る。例えば、移動ＴＶ機能を有する携帯電話が含まれる遠隔プラットフォーム１２０は、通信インタフェースシステム１０４に相互接続して、通信インタフェースシステム１０４の表示及び／又は音声出力を利用し得る。更に、優れた出力をユーザに潜在的に提供することに加えて、遠隔プラットフォーム１２０は、通信インタフェースシステム１０４の出力機能を用いることによってバッテリ電力を節約し得る。
【０１６２】
本明細書に提供された様々な例は、車両における通信インタフェースシステム１０４の配備について説明したが、本発明は、それに制限されないことを認識すべきである。特に、本発明の実施形態は、プロトコル及びメッセージの広範囲にわたる事前準備を必要とせずに、装置とアプリケーションとの間の相互運用性が望まれる場合、任意の用途に配備又は適合し得る。例えば、本明細書において述べた通信インタフェースシステム１０４機能は、静止又は移動ワークステーションと接続して有用に展開して、通信インタフェースシステム１０４に利用可能な装置が変わる際、柔軟な機能を提供し得る。
【図面の簡単な説明】
【０１６３】
【図１Ａ】本発明の実施形態に基づくシステムの構成要素のブロック図。
【図１Ｂ】本発明の実施形態に基づく構成要素の概略図。
【図２】本発明の実施形態に基づく通信インタフェースシステムと、相互接続された遠隔プラットフォームとの間の通信レベルを示すブロック図。
【図３】本発明の実施形態に基づく通信インタフェースシステムに含み得るハードウェア構成要素を示すブロック図。
【図４】本発明の実施形態に基づく、相互接続された装置と共に通信インタフェースシステムを示すブロック図。
【図５】本発明の実施形態に基づくサービス初期化プロセスを示すフローチャート。
【図６】本発明の実施形態に基づくサービス登録プロセスを示す図。
【図７】本発明の実施形態に基づく相互接続された装置からデータにアクセスするローカルアプリケーションを示すブロック図。
【図８】本発明の実施形態に基づく、ローカルアプリケーションによる相互接続された装置へのアクセスを簡易化する際の通信インタフェースシステム動作の態様を示すフローチャート。
【図９】本発明の実施形態に基づくサービス発見プロセスを示す図。
【図１０】本発明の実施形態に基づく装置からデータにアクセスする遠隔プラットフォームを示すブロック図。
【図１１】本発明の実施形態に基づくプラットフォーム間制御メッセージプロセスを示す図。
【図１２】本発明の実施形態に基づく通信チャネルを示す図。
【図１３】本発明の実施形態に基づくサービスへのアクセスを確立する工程に関連した情報及びメッセージフローを示す図。
【図１４】本発明の実施形態に基づく、遠隔プラットフォームに関連付けられたサービスへのアクセスを簡易化する際の通信インタフェースシステム動作の態様を示すフローチャート。
【図１５】本発明の実施形態に基づくシステムの要素間の通信を示す図。
【図１６】本発明の実施形態に基づく複数の遠隔プラットフォームに相互接続された通信インタフェースシステムを示すブロック図。
【図１７Ａ】本発明の実施形態に基づく静的サービステーブルレコードのコンテンツを示す図。
【図１７Ｂ】本発明の実施形態に基づく動的サービステーブルレコードのコンテンツを示す図。
【図１８】本発明の実施形態に基づくサービス開始テーブルレコードのコンテンツを示す図。
【図１９】代表的なシナリオに関連する本発明の実施形態に基づく通信インタフェースシステムの動作の態様を示すフローチャート。
【図２０】代表的なアプリケーションにおける本発明の実施形態に基づく通信インタフェースシステムを示す図。
【図２１】本発明の実施形態に基づく遠隔プラットフォームに相互接続される通信インタフェースシステムを示すブロック図。
【図２２】本発明の実施形態に基づくサービス発見及び接続確立の態様を示すフローチャート。
【図２３】本発明の実施形態に基づく、通信インタフェースシステムと遠隔プラットフォームとの間のアプリケーション固有メッセージ伝達を示すフローチャート。
【図２４】通信インタフェースシステム上で動作するサービスを用いる遠隔プラットフォーム上で動作するアプリケーションの制御態様を示すフローチャート。
【図２５】本発明の実施形態に基づくセキュリティ及びカスタマイズされたコンテンツを提供するためのプロセスの態様を示すフローチャート。
【図２６】本発明の他の実施形態に基づく遠隔プラットフォームに相互接続される通信インタフェースシステムを示すブロック図。
【図２７】本発明の実施形態に基づく統合された表示装置資源を組み込むシステムの動作の態様を示すフローチャート。
【図２８】本発明の実施形態に基づく通信インタフェースシステムと通信を行う遠隔プラットフォームの動作の態様を示すフローチャート。
【図１Ａ】
2008500610.tif 000003
【図１Ｂ】
2008500610.tif 000004
【図２】
2008500610.tif 000005
【図３】
2008500610.tif 000006
【図４】
2008500610.tif 000007
【図５】
2008500610.tif 000008
【図６】
2008500610.tif 000009
【図７】
2008500610.tif 000010
【図８】
2008500610.tif 000011
【図９】
2008500610.tif 000012
【図１０】
2008500610.tif 000013
【図１１】
2008500610.tif 000014
【図１２】
2008500610.tif 000015
【図１３】
2008500610.tif 000016
【図１４】
2008500610.tif 000017
【図１５】
2008500610.tif 000018
【図１６】
2008500610.tif 000019
【図１７Ａ】
2008500610.tif 000020
【図１７Ｂ】
2008500610.tif 000021
【図１８】
2008500610.tif 000022
【図１９】
2008500610.tif 000023
【図２０】
2008500610.tif 000024
【図２１】
2008500610.tif 000025
【図２２】
2008500610.tif 000026
【図２３】
2008500610.tif 000027
【図２４】
2008500610.tif 000028
【図２５】
2008500610.tif 000029
【図２６】
2008500610.tif 000030
【図２７】
2008500610.tif 000031
【図２８】
2008500610.tif 000032
【手続補正書】
【提出日】平成18年12月18日(2006.12.18)
【手続補正１】
【補正対象書類名】図面
【補正対象項目名】図２４
【補正方法】変更
【補正の内容】
【図２４】
2008500610.tif 000033