JP2012120240A - リモートコントロール・フレームワーク - Google Patents

Abstract

【課題】リモートコントロールフレームワークは、複数のターゲットデバイスがベアラの種類に関わらず複数のリモートコントロールデバイスにより制御されることを可能にする。
【解決手段】任意のターゲットデバイスがコントロールデバイスとしての役割を果たしてもよく、任意のコントロールデバイスがターゲットデバイスとしての役割を果たしてもよい。フレームワークは、任意のターゲットデバイス上で実行する任意のアプリケーションが任意のコントローラデバイスにより制御されることを可能にする。
【選択図】図３

Description

本発明は、デバイスのリモートコントロールを可能にする方法に関する。

本発明の以下の説明を明確にするため、デバイスという用語は、任意の種類の有線又は無線接続を介して任意の種類の外部デバイスによりリモートコントロールできるエンティティを示すために使用される。

無線リモートコントロールを最初に実証したのは、１８９８年にMadison Square Gardensの電気博覧会において特設された池で無線制御のボートを公開したNikola Teslaであった。特許文献１がその発明に関して発行された。

この素晴らしい歴史にも関わらず、家庭電気／電子機器に対してリモートコントロール技術が商業面で初めて本格的に利用されたのは、Zenithがテレビに関連してその技術を使用した約５０年後であった。最初のテレビのリモートコントロール「Lazy Bones」は１９５０年に登場し、長い電線でテレビに接続されていた。テレビの有線リモートコントロールは寿命の短い技術であった（ユーザがコードにつまずくことが主な理由であった）が、スライド映写機及びディクタフォン用の有線リモート等の従来の有線リモートからSonyのRMVD1が最新の例であるデジタルカムコーダ等のより現代的な機器まで多くの他の種類の電子機器に対して製造し続けられている。

現在、そのようなデバイスの殆どを構成するのは無線リモートコントロールである。１９５５年、Zenithの「Flashmatic」が最初に登場した無線テレビリモートコントロールであり、テレビの光電セルに対して生成される可視光線信号により動作した。その翌年、Robert Adlerの「Space Commander」がZenithの最初の現実的な無線リモートコントロールとなった。それは機械的に動作する超音波装置であった。超音波は、１９８０年代に赤外線送信装置が開発されるまでリモートコントロール技術の基礎となっていた。赤外線により必要とされるＬＯＳ通信が非現実的である場合に一般にＲＦ（無線周波数）が使用されるが、赤外線は依然として今日のリモートコントロールデバイスに対する選択肢となる技術である。

無線リモートは一般に多種多様であるが、特に電線が必要とされる機器において有線リモートが復活してきていることは明らかである。その最も分かりやすい例は、オーディオ機能性を有する機器である。これは、ハンズフリーヘッドセットのオーディオリードに挿入されたモジュールのボタン及び高性能デジタル音楽プレーヤ上のより複雑な形態のボタンを介して制御される移動電話を含む（AppleのiPod（登録商標）、Creative Zen（登録商標）及びiRiver（登録商標）等の全ての市場のリーダはオプションの又は一体型の有線リモートコントロールを有する）。

要約すると、現在の電気／電子機器のリモートコントロールは、今日、以下の状況において広く普及している。その状況では、機器を動作するユーザと機器自体とが物理的に近接することが、以下のいずれかの場合に該当する。
・不可能である場合；飛行機又は船等の乗り物の場合。
・困難である場合：通常、壁又は天井の高い位置に取り付けられる空調装置等の機器の場合。
・使用環境に不適切であると考えられる物理的変更又は努力を必要とするため不便である場合；テレビ、ＤＶＤ及び音楽プレーヤ等の最近の音響映像機器及びオーディオ機器の場合。

近年まで、機器のリモートコントロール技術は多くの関連技術において制限されていた。
・リモートコントロールデバイスは、それらにより制御され、近接して接続される機器と共に製造・販売されていた。通信には、プロプライエタリ信号及びプロトコルが使用された。これは、赤外線装置にも当てはまる。赤外線データ協会（ＩｒＤＡ、非特許文献１を参照）により開発された赤外線通信に対する規格が存在するが、リモートコントロールはそれを利用していない。実際には、「種々の符号化システムが使用されており、一般に、異なる製造業者は異なるコード及び異なるデータ送信速度を使用する」とある（非特許文献２より）。

尚、この説明において、種々の製造業者の機器と共に使用されるプログラマブルリモートコントロールの存在は、それらリモートコントロールが共通の規格に準拠することの証明ではない。そのようなプログラマブルデバイスは、全ての状況で機能する単一モードで実行できるのではなく、種々の製造業者の各々の動作モード、送信プロトコル、データ転送速度及び制御コードをエミュレートできる。
・リモートコントロール機器が供給されたが、それらは全て専用の拡張不可能なデバイスであった。リモートコントロール機器は、固定の機能セットを有し、製造時に組み込まれた機能以外の機能を実行できなかった。
・同様に、リモートコントロールされる全ての機器は、特にそのために設計される必要があった。それら機器の機能は固定され、機器の製造時に組み込まれた機能以外の機能を実行できなかった。

しかし、電子機器は益々多機能でプログラマブルになってきている。電子機器は、汎用コンピュータで採用される同一種類の中央処理装置及びメモリを中心に構築される傾向にある。その場合に上述の制限を回避できるようになってきていることの実質的な証拠が存在する。

リモートコントロール技術の分野において、一般に、プログラマブルコンピュータで使用される同一のプロセッサ及びメモリ構成要素を中心に構築される機器は、規格化された通信技術を利用できる。それら規格には以下のものがある。
・Ｂｌｕｅｔｏｏｔｈ（非特許文献３のBluetooth Special Interest Groupのウェブサイトを参照）。これは、特定の状況で使用されるように設計された種々のプロファイルにおいて実装される低電力の狭域無線ネットワーキングプロトコルである。Ｂｌｕｅｔｏｏｔｈの最も一般的な用途の１つは、移動電話の無線ヘッドセットにおいて、ヘッドセットが移動電話をリモートコントロールすることを可能にするハンズフリープロファイル又はヘッドセットプロファイルを利用することである。
・Ｆｉｒｅｗｉｒｅ／ＩＥＥＥ１３９４（非特許文献４の1394 Trade Associationのウェブサイト又は非特許文献５のThe Institute of Electrical and Electronic Engineers High Performance Serial Bus Bridges Working Group P1394.1を参照）。これは、回線を介して実行する高速シリアルプロトコルであり、マルチメディア機器のリモートコントロールに益々使用されてきている。規格は、Digital Remote Control Command Setを含む。
・ＡＮＳＩ／ＣＥＡ−２０２７；これは、比較的新しい規格であり、全米家電協会（ＣＥＡ）により２００４年７月に完成された。これは、ＩＰ（インターネットプロトコル）を使用してホームネットワークを介して相互接続されるオーディオ／ビデオ機器の制御に使用されるインタフェースを規定する。

それら規格の使用が増加しているが、多くの企業がそれら規格を十分に利用していないことが明らかである。例えば、AppleがＦｉｒｅｗｉｒｅを発明したにも関わらず、AppleはApple自体のリモートコントロールにおいてその技術を使用していない。iPodのリモートコントロールで使用される専用プロトコルを逆行分析するにはある程度の労力が必要であった。それについては、非特許文献６に説明されている。

上述の規格に基づく技術と同様に、機器がプログラム可能デジタルコンピュータを内蔵すると仮定すると、２つの機器が互換性のあるソフトウェアを実行している時、それら双方の機器をリンクすることにより一方が他方を制御できることが明らかとなった。従って、より大型の固定機器（パーソナルコンピュータ等）はより小型の移動機器（携帯電話等）により制御され、多くの場合、従来のリモートコントロールの機能性の上位セットを与える。この技術の例は多く存在し、それら技術により、Ｗｉｎｄｏｗｓ（登録商標）ＰＣを制御するBemused（非特許文献７）及びBluetooth Remote Control（非特許文献８）等のＢｌｕｅｔｏｏｔｈを介してパーソナルコンピュータ上でメディアプレーヤ及び他のアプリケーションを制御するために移動電話を使用できる。Salling Clickerは、移動電話がAppleのMacintosh（非特許文献９）を制御することを可能にし、Linuxに対する実現例が更に存在する（非特許文献１０等）。

上述の従来技術は、専用の融通性のないプロプライエタリリモートコントロール解決策から汎用性があり融通性のある規格に基づくリモートコントロール解決策に徐々に進歩していることを示す。

しかし、上述の全ての規格に基づく解決策は、ベアラ技術特有の解決策であり、また、多くの場合にそのベアラと共に使用されるトランスポートプロトコル特有の解決策であるということにより制限される。リモートコントロール信号伝送用の多くの可能なベアラは、以下を含むがそれらに限定されないことが、当業者には認識されるだろう。
・Ｂｌｕｅｔｏｏｔｈ（多くの可能なプロファイルのうちの任意の１つを使用する）。
・ＩＰを使用する信号伝送方法を使用する無線イーサネット（登録商標、８０２．１１）。
・赤外線（プロプライエタリ及びＩｒＤＡ）。
・プロプライエタリＲＦ解決策。
・ＩＥＥＥ１３９４コマンドセット又はＡＮＳＩ／ＣＥＡ−２０２７を利用するＩＥＥＥ１３９４（Ｆｉｒｅｗｉｒｅ）。
・ＵＳＢ−ＯＴＧ（On-The-Go）を含むＵＳＢ（Universal Serial Bus）。
・ＲＳ−２３２シリアルプロトコルを含む他の有線解決策。

現在、それらベアラのうち任意の１つを使用するリモートコントロールと協働するように設計される機器は、リモートコントロールが標準のプロトコルを使用するか否かに関わらず他の種類のベアラと協働できない。特定用途向け有線リモートコントロールと共に使用されるように設計されたＭＰ３又は他の音楽プレーヤは、利用可能な業界標準のインタフェースを有するが、一般的なＦｉｒｅｗｉｒｅ、ＵＳＢ、Ｂｌｕｅｔｏｏｔｈ又は赤外線リモートコントロールデバイスと協働させられない。

リモートコントロールデバイスが同一のベアラを使用しても、互換性のないプロトコルが実装される場合、機器は動作できない。例えば、Ｂｌｕｅｔｏｏｔｈヘッドセット及びハンズフリープロファイルは非常に異なり、ヘッドセットプロファイルのみをサポートするＢｌｕｅｔｏｏｔｈ対応移動電話はハンズフリープロファイルのみをサポートするＢｌｕｅｔｏｏｔｈ周辺装置と協働しないことが周知である。この種の非互換性を容易に修正する方法がないため、そのような非互換性は多くの消費者の悩みの原因となっている。
米国特許第６１３，８０９号公報 インターネット〈http://www.irda.org/〉 インターネット〈http://www.epanorama.net/links/irremote.html〉 インターネット〈http://www.bluetooth.com/〉 インターネット〈http://www.1394ta.org/〉 インターネット〈http://grouper.ieee.org/groups/1394/1/index.html〉 インターネット〈http://www.maushammer.com/systems/ipod-remote/ipod-remote.html〉 インターネット〈http://www.compsoc.man.ac.uk/~ashley/bemused/〉 インターネット〈http://www.labtech.epitech.net/remotecontrol/〉 インターネット〈http://homepage.mac.com/jonassalling/Shareware/Clicker〉 インターネット〈http://www.iptel-now.de/HOWTO/BT_REMOTE/bt_remote.html〉

従って、本発明の目的は、コマンドを転送するのに使用されるプロトコル又はベアラに関わらず、任意の種類のリモートコントロールデバイスからそれらコマンドを受信するために機器上で実行するアプリケーションソフトウェアにより使用される一般的なリモートコントロール・インタフェースを提供することにより、リモートコントロール解決策と特定のベアラ技術との間の密接な結び付きが原因である上述の問題を少なくとも改善するリモートコントロール・インタフェースを提供することである。

同一の一般的なソフトウェアインタフェースは、プロトコル又はベアラに関わらず、リモートコントロールデバイスにより使用され、機器にコマンドを送出する。

更に、その一般的なソフトウェアインタフェースを実装するプログラマブル演算装置を内蔵する機器は、リモートコントロールデバイスから単にコマンドを受信するためにソフトウェアインタフェースを使用できるだけでなく、リモートコントロールデバイスとして動作するためにソフトウェアインタフェースを使用できる（適切なアプリケーションと共に）。

本発明の第１の側面によると、１つ以上のターゲットデバイスが任意のベアラを介して任意のコントローラデバイスからコマンドを受信できるようにする一般的なリモートコントロール・インタフェースを提供することにより、
・ＵＳＢ及び単純なシリアルを含む固定配線と、
・赤外線と、
・超音波と、
・Ｂｌｕｅｔｏｏｔｈ及び８０２．１１無線ネットワーキングを含むがそれらに限定されないＲＦと、
を含むがそれらに限定されない複数のベアラのうち少なくとも１つを介して送出されたコマンドを使用して、１つ以上のコントローラデバイスが前記１つ以上のターゲットデバイスをリモートコントロールできるようにする方法が提供される。

本発明の第２の側面によると、第１の面の方法に従って動作するように構成される演算装置が提供される。

本発明の第３の側面によると、第１の面の方法に従って演算装置を動作させるオペレーティングシステムが提供される。

次に添付の図面を参照し、更なる例として本発明の一実施形態を説明する。

以下の説明において、本発明の一般的なインタフェースをリモートコントロールフレームワークと呼ぶ。それは、機器上で実行する任意のアプリケーション又はソフトウェアにより使用される。しかし、リモートコントロールフレームワークは、外部リモートコントロールコマンドを送出又は受信するためにベアラプラグインモジュールを内部的に使用する。プラグインは、疎結合アプリケーションに特定のサービスを提供する実行可能コードの置き換え可能な項目、あるいは実行時にプラグインをロード又は開始できるサービスとして規定される。

特有の各ベアラは、それ自体のプラグインを必要とする。各ベアラプラグインは、同一の一般的なアプリケーション・プログラミング・インタフェース（ＡＰＩ）を外部に実装するが、リモートコントロールデバイスに対してコマンドを送出及び受信するために関連するベアラ技術の特定の特徴及び必要条件を使用するように内部でカスタマイズされる。

ベアラプラグインの例には、ワイヤードヘッドセット、赤外線リモートコントロール及びＢｌｕｅｔｏｏｔｈオーディオ・ビデオ・リモート・コントロール・プロファイル（ＡＶＲＣＰ）がある。

図１は、リモートコントローラ及び被コントロール機器としての役割を果たせるデバイスに対して、そのアーキテクチャの１つの好適な実現例を示す図である。本発明の実現例は、離散的な信頼性の高い安全な方法で同時に実行される制御機能及び複数のコントローラをカプセル化する別のデバイスを更に含んでもよい。マルチメディア及びホームセキュリティは、制御の複雑さがその種のデバイスを保証するような技術分野である。しかし、この好適な実現例は、機器を制御でき、自身がリモートコントロールされ、本発明は、それら機能のいずれか１つが欠如しており、専用リモートコントローラに適するか又は制御を必要とする専用機器に適するバージョンにおいて実現される。

図１の矢印は、本発明に係る典型的なアーキテクチャに対する制御及びコマンドの流れを示す。

図１は、被コントロール機器として使用されている装置６上で実行するオーディオアプリケーション２及びビデオアプリケーション４を示す。それらアプリケーションは、リモートコントロールサーバ８からコマンドを受信する。リモートコントロールサーバ８は、コマンドの送信元であるリモートコントローラ又はコマンドを転送するのに使用されるベアラの種類に関わらず、そのようなコマンドを全てのアプリケーションに渡す安定したターゲットクライアントＡＰＩ１０を提供する。

図１は、リモートコントローラとして使用される場合に装置上で実行可能なリモートコントローラアプリケーション１２を更に示す。これは、それ自体のコントローラクライアントＡＰＩ１４を使用してリモートコントロールサーバ８を介してコマンドを送出する。このＡＰＩは、任意の送信先機器及びベアラの種類に対して安定している。

リモートコントロールサーバ８は、可能な拡張機能を有する利用可能なＡＶＲＣＰ、ワイヤードリモート及び赤外線に対するプラグイン１４、１６、１８を有する。拡張機能の１つを図１のボックス２０で示す。本実施形態において、リモートコントロールサーバはターゲットセレクタ２２を含む。ターゲットセレクタは３つの役割を実行する。
１）入力コマンドに対して、コマンドを受信するべきターゲットアプリケーションを判定する。
２）出力コマンドに対して、リモートコントロールアプリケーションがベアラ及び機器の指定に失敗した場合に制御されるデフォルトベアラ及び機器を判定する。デフォルトベアラを判定するためにユーザ又は機器により使用される機構（例えば、ある種のControl Panel）が多く存在することは、当業者には認識されるだろう。
３）制御される機器を指定するリモートコントロールアプリケーションにより送出される出力コマンドに対して、ゲートキーパとして動作する。ベアラより上のレベルでの通信を許可又は拒否する。

図１の点線２４は、本発明を実現する装置の境界を示す。装置が被コントロール機器として使用されている時、コマンドはその境界を越えて受信されるか又は「入力される」。装置がリモートコントロールとして使用されている時、コマンドはその境界を越えて渡されるか又は「出力される」。それらコマンドに対するベアラの特性は、リモートコントロールサーバ８内にカプセル化される。

尚、図１の下部に示す更なるデバイス２６は、リモートコントロールフレームワークをデバイス自体で実行してもよいが、必ずしもその必要はない。サーバにプラグインするモジュールは、任意の種類のベアラを介して任意のプロトコルを実装するように設計される。

被コントロール機器に対して追加のリモートコントロールのサポートを追加することは、単にその機器のリモートコントロールフレームワークに追加のプラグインモジュールを追加することである。従って、ＵＳＢリモートコントロールは、例えば図１の拡張ボックス２０の代わりに、リモートコントロールサーバがＵＳＢプラグイン（不図示）を利用できるようにすることを要求する。これは、オープンオペレーティングシステム上のインストール可能なソフトウェアモジュールとして提供されてもよい。あるいは、ＯＴＡ（over-the-air）又はサービスセンターアップグレード等の手段によって、あるいはオペレーティングシステムにより認識されるＥＰＲＯＭ等のユーザが挿入可能なモジュールによってハードウェアアップグレードとして提供される。

リモートコントロールにより追加の機器を制御する機能を追加することは、その機器自体のリモートコントロールフレームワークにプラグインモジュールを追加することによって同様に管理される。

次に説明する本発明の例は、Symbian Ltdにより製造される移動電話用の高度なオペレーティングシステムであるSymbian OS（登録商標）を実行する携帯電話における本発明の一実現例である。従って、Symbian OSに関する種々の教本（J.StichburyによるSymbian OS Explained、Wiley、２００４年、ISBN 0470021306等）及びSymbian Ltdにより発表された種々の開発キット（http://www.symbian.com/developer/techlib/sdl.htmlにおいて見つけられる開発キット等）に説明されるように、そのオペレーティングシステムを有するデバイスを構築する当業者には周知の用語及び語法を使用する。本明細書において説明する実現例は、種々のオペレーティングシステム及び種々のデバイス上で実行するように適応されることが当業者には当然理解されるだろう。

このリモートコントロールシステム（ＲｅｍＣｏｎ）の例は、電話機及び特に電話機上で実行するＭＰ３プレーヤ等の音楽アプリケーションをＢｌｕｅｔｏｏｔｈステレオオーディオヘッドセットから制御するための本発明の使用方法を示す。制御されるアプリケーションをターゲットと呼ぶ。例えばこの例において、ユーザは再生、一時停止及び「次のトラック」等の機能を実行するためにヘッドセットと対話してもよい。実質上、ヘッドセットは電話機のリモートコントロールのために使用される。

更に一般的には、電話機は、任意の適切なベアラ又はプロトコルを介して別のデバイスにより制御されてもよい。従って、本発明の拡張性を実証するために、説明される別の最初の実装は、任意の単純なプロトコルを使用するシリアル転送を介して動作する相対的に基本的なプラグインの実装である。

本発明のリモートコントロールシステムにより、デバイスを他のデバイスに対するリモートコントロールとして使用できる。この機能性に対するデバイス上のアプリケーションをコントローラと呼ぶ。例えば、デバイスはテレビのリモートコントロールに使用されてもよい。

システムは、リモートコントロールメッセージを送信及び受信するために使用されるトランポート及びプロトコル（ベアラと総称される）に関して拡張可能である。本明細書において、ヘッドセットは一般にＢｌｕｅｔｏｏｔｈヘッドセットと考えられるが、ワイヤードヘッドセット等の他の種類のヘッドセットをサポートできることも明らかである。

ベアラの拡張性に依存せず、システムは送出及び受信されるメッセージに関して拡張可能である。従って、新しいベアラプロトコルに準拠することは新しいメッセージをサポートすることを更に含んでもよい。

更にそのシステムにより、複数のクライアントアプリケーションが同時にシステムを使用することが可能になる。１つのコントローラ及び１つのターゲットではなく、複数のターゲットが複数のコントローラと同時に使用される。

コントローラクライアントは、コマンドを送出し且つ応答を受信する。ターゲットクライアントは、コマンドを受信し且つ応答を送出する。従って、コントローラＡＰＩにより、コネクションレス動作（コマンドはデバイスの製造業者により決定されたようにシステムによりルーティングされる）及びコネクション指向動作（クライアントは相手側に対する任意の関連するアドレス指定情報及びベアラを指定する）が可能になる。クライアントは、任意の時点で存在する種々の接続の状態を監視できる。従って、システムはベアラアグノスティックである。

図２は、システムを概略的に示す図である。

図２に示すアーキテクチャの構成要素の一部は、当業者には周知の標準プロトコルを実装する。それらプロトコルは以下を含む。
・ＡＶＣＴＰ（Audio Video Control Transmission Protocol）。
・ＡＶＤＴＰ（Audio-Video Distribution Transport Protocol）。
・ＡＶＲＣＰ（Audio Video Remote Control Profile）。
・Ｌ２ＣＡＰ（Logical Link Controller and Adaptation Protocol）。
・ＲＴＰ（Real Time Protocol）。
・ＳＢＣ（Sub Band Codec）。

図２に示すアーキテクチャの他の構成要素は、本実現例に特有である。
・Media Player appは、マルチメディアフレームワーク（ＭＭＦ）を使用してＡＶＤＴＰを介してＢｌｕｅｔｏｏｔｈヘッドセットにオーディオを送出する。ＭＭＦは、MMF Client API及びMMF Controller Plug-inにより表される。Media Player appはＲｅｍＣｏｎターゲットであり、ＡＶＲＣＰを介してヘッドセットからリモートコントロールコマンド（次のトラック、一時停止等）を受信する。
・Remote Controller appはＲｅｍＣｏｎコントローラであり、ＡＶＲＣＰを介してリモートデバイスにリモートコントロールコマンドを送出する。
・DevSoundは、ＲｅｍＣｏｎコントローラと考えられる。これは、Audio Policy Serverを介してリモートの音量を直接設定する方法である（すなわち、メディアの音量はシステムプロパティと考えられ、Media Player app毎に処理されない）。
・RemCon Target API及びRemCon Controller APIは上述のコマンド拡張性を含む。
・ＲｅｍＣｏｎサーバは、上述のメッセージルーティングポリシー及びベアラ拡張性フレームワークを含む。

設計の最も重要な構成要素の概要を次に説明する。

＜ＲｅｍＣｏｎ＞
デバイス上で実行するＲｅｍＣｏｎサーバのインスタンスが最大１つ存在する。それは非常駐サーバである。すなわち、それは常に使用されているわけではなく、リソースを節約するためにクライアントがいない場合にはシャットダウンする。

＜ベアラ＞
ベアラはＲｅｍＣｏｎに対するプラグインとして実装され、全てのベアラは標準インタフェースをインスタンス化する。

リモートコントロールシステムのこの特定の実現例は、ＢｌｕｅｔｏｏｔｈシステムのＡＶＲＣＰ及びＡＶＣＴＰ拡張機能の実現例と関連付けられる。従って、
・ＡＶＲＣＰはＲｅｍＣｏｎに対するベアラプラグインとして配信される。
・ＡＶＣＴＰはＢｌｕｅｔｏｏｔｈプロトコルモジュールの一部として配信される。
また、その特定の実現例は、上述の参照シリアルベアラと関連付けられる。

サーバは、
ａ）それら構成要素と協働し、
ｂ）可能な限り、任意の他の考えられるベアラと協働するように、すなわちベアラアグノスティックの状態でいるように設計される。

コネクション指向及びコネクションレスの可能な２つの種類のベアラが存在するが、本実現例は、コネクションレスベアラがコネクション指向の挙動をエミュレートすることを必要とする。従って、ＡＶＲＣＰベアラプラグインと同様に、ベアラＡＰＩはコネクション指向である。

コネクション指向ベアラのインスタンス化により、入力接続のリスニングが開始される。そのようなベアラは入力接続を受け付け、ＲｅｍＣｏｎサーバに通知する。

尚、ＲｅｍＣｏｎサーバは、特定のリモートデバイスへの接続を試みるためにベアラに命令できる。

＜コントローラ＞
コントローラエンティティは、リモートターゲットにメッセージを送出し、提供される応答に対応する。

コネクションレスモードのコントローラがコマンドを送出する場合、使用される実際のベアラ（及びベアラ内の特定の接続）は、通常デバイスに特有であり且つその製造業者により提供されるプラグイン、ここではTarget Selector Plug-In（ＴＳＰ）として周知のプラグインにより指定される。これについては、ターゲットと関連して以下に更に詳細に説明する。コネクション指向モードのコントローラがコマンドを送出する時、使用される接続は、コントローラにより既に開かれている。しかし、そのコントローラがその時点で指定されたリモートにコマンドを送出してもよいかを制御できる。

ベアラは、コマンドを送信し且つ応答を受信するために使用される。サーバは、各コントローラにより送出されたコマンドの知識を保持する。サーバは、接続を介して適切な開始コマンドを送出したコントローラクライアントに接続を介して入力される応答を向ける。

コントローラＡＰＩは、システムの全てのベアラを介して全ての接続に関する情報を配信するNotifyConnectionsChange APIを更に含む。

＜ターゲット＞
コントローラクライアントと同様に、同時に動作するターゲットクライアントが２つ以上存在する可能性がある。ベアラプロトコルが入力コマンドの対象となるターゲットを必ずしもカプセル化しないため、ターゲットの動作はコントローラの動作より不確実である。特定の入力コマンドに対応する必要があるターゲットは、実行時に変更されるだけでなく、ターゲット（クライアント）が制御又は知識さえも有さないように変更される。図示する目的で、ユーザがＭＰ３プレーヤアプリケーションを使用して音楽を聴いており、電話がかかってきてユーザが電話をとる場合、ターゲットアプリケーション（ヘッドセットにより開始される音量制御変更のための）はＭＰ３プレーヤアプリケーションから電話機アプリケーションに変更される。デバイスのユーザインタフェース（ＵＩ）が「マルチメディア音量」と「通話音量」との区別を保持する場合、それらアプリケーションの各々は、それ自体のスクリーン上の表示を更新するために音量制御変更をリスンする必要がある。

実質上、システムは、ユーザが常にリモートコントロールされると考えるものをモデル化しようとする。現在の実現例では、これは一般に非常に単純である。ユーザは、テレビを制御するためにテレビのリモートコントロールを使用し、ビデオレコーダを制御するためにビデオのリモートコントロールを使用する。これにより、物理コントローラとターゲットとの間のマッピングは明示的になる。

しかし、単一のリモートコントローラ（ヘッドセット）により制御される電話機上で実行する複数のターゲットアプリケーションを使用すると、このマッピングはより不明瞭になる。マッピングを確立するために使用される要素には以下の要素がある。
（ａ）デバイスの読み出し専用メモリ（ＲＯＭ）におけるアプリケーションの順序。
（ｂ）アプリケーションがフォアグラウンドであるか否か。
（ｃ）ユーザ動作の最近の履歴。
（ｄ）アプリケーションの相対的に考えられる重要さ（例えば、電話機アプリケーションの場合、通話がアクティブである時期が最も重要である）。
（ｅ）音楽の大音量部分が開始されたことをＭＰ３プレーヤが認識した場合、音量低下コマンドは他のアプリケーションではなくＭＰ３プレーヤに命令した可能性が高い。
（ｆ）一般にユーザが再生リストの特定のトラックの開始後すぐに「次のトラック」を実行したことをＭＰ３プレーヤが記憶・認識した場合、ユーザは次のトラックもスキップすることを意図する可能性が高い。
（ｇ）ユーザがトラックに対する「ユーザ評価」を提供するサービスのウェブからストリームされた音楽を聴いており、他のユーザがよくないと考えるトラックに対して「次のトラック」を選択する場合、そのユーザも同じように考えるだろう。

単に例である上述の可能性は、一般的なオペレーティングシステムがマッピングの問題に対して最終的な回答を提供することが不可能であることを明らかにする。従って、ユーザインタフェースを判定するデバイスの製造業者は、マッピングを決定するのに有利な立場にいる場合が多い。

従って、ユーザインタフェースシステムに従って最も理にかなう規則の１つの集合を実現するためにデバイスの製造業者により使用されるTarget Selector Plug-in（ＴＳＰ）と呼ばれる機構が提供される。ＴＳＰは、現在のクライアントターゲットプロセスＩＤのリストを提供され、メッセージを受信するターゲットクライアントのリストをＲｅｍＣｏｎに戻す（プロセスＩＤにより）と予想される。

ターゲットに対してコマンドを配信するベアラをターゲットが認識すると予想されないため、ターゲットクライアントがリモートコントロールシステムに接続する時は必ず、全ての入手可能なベアラはロードされ、入力接続のリスニングを開始する必要がある。尚、ターゲットクライアントはベアラに対してアグノスティックであるが、ベアラの存在に全く気付かないわけではない。ターゲットは、上述のNotifyConnectionsChange APIを入手できる。

＜ターゲット・セレクタ・プラグイン（ＴＳＰ：Target Selector Plug-in）＞
ＴＳＰは、以下の３つの決定を担う。
１．各入力コマンドに対して、どのターゲットにコマンドを配信するか。
２．コネクションレスモードのコントローラに対して、どのリモートターゲットに出力コマンドを配信するか（すなわち、どのベアラ／ベアラリモートアドレスにコマンドを配信するか）。
３．コネクション指向モードのコントローラに対して、特定のコマンドを特定のリモートに送出するというコントローラの要求を許可するか又は拒否するか。

ＴＳＰインタフェースの単一の参照実装がＲｅｍＣｏｎにより提供される。対象を絞る目的で、このインタフェースは潜在的な受信者の配列を提供される。このように、指定受信者の配列を示すことができ、メッセージは各々に配信される。

上述のように、ＴＳＰは特定のインタフェースポリシーに従って実装するめにデバイスの製造業者に提供される。

動作中のデバイスにおいて、単一のＴＳＰは読み出し専用メモリ（ＲＯＭ）の構築時に提供される。１つのＵＩを有するデバイス上の問題に応じる適切な方法は論理的に１つのみ存在するため、そのようなプラグインは論理的にシステムに１つのみ存在する。実際には、コマンドはＲｅｍＣｏｎにより配信される。ＴＳＰはＲｅｍＣｏｎによりクエリされるため、メッセージを配信すべき場所を認識している。

ターゲットクライアントは、それら目的のためにプロセスＩＤ及びセキュアＩＤにより識別される。ＲｅｍＣｏｎは、ターゲットクライアントがクライアントプロセス毎に１つのみ許可されるようにターゲットクライアントの確立を監視する。各コマンドに対して、ＴＳＰは現在開いているターゲットクライアントのＩＤのリストを提供されるため、利用可能なターゲットを認識している。ＴＳＰは、更なるターゲットクライアントアプリケーションを開くようにトリガすること及びそれらのＩＤを配列に追加することを自由に行なえる。

リモートターゲットは、ベアラの固有の識別子（ＵＩＤ）及びベアラ特有の接続情報パッケージの組合せにより識別される。コネクション指向コントローラが正確に機能できるように、ベアラ特有の接続パッケージの種類は既に第３者に公開されているべきである。

ＴＳＰ ＡＰＩは、その実装の際に最大限の融通性を得るために要求／コールバック機構を介して機能する。コールバックは、同期的又は非同期的であってもよい。ＴＳＰは、アドレス指定するためにＲｅｍＣｏｎによりＴＳＰに渡された任意のコマンドを理解できるように設計され、コマンドをアドレス指定する目的を達成するのに十分である。これは、Core APIコマンド及び拡張コマンドを含む。ＴＳＰがコマンドを「エラー」とする場合、そのコマンドは配信されない。

＜ターゲット・リスニング機構＞
システムには、ＴＳＰインスタンスが１つのみ存在する。従って、多くのベアラからの入力事象は、非同期ＡＰＩを介してＴＳＰに送出される前にＲｅｍＣｏｎにキュー登録される。ターゲットに対しては、コマンドが「アドレス指定」されると、選択されたターゲットクライアントの各々が未解決の受信要求を有する場合、コマンドはそれら選択されたターゲットクライアントに提供される。

当該ターゲットの受信要求が完了した場合、ターゲットは提供されたデータを処理し、（通常）要求を再度通知する。ターゲットＸがその時点で未解決の「Receive要求」を有していない時にターゲットＸがコマンドを受信すべきであるとＴＳＰが示す場合、そのコマンドは、ターゲットＸがReceive要求を通知するまでキュー登録される。更に入力応答は、そのようにキュー登録される。

＜拡張ＡＰＩ＞
フレームワークは、例えば種々のデバイス製造業者に特有のＡＰＩをサポートするために、Core APIの拡張機能をサポートする。コントローラクライアントは、コマンドを送出する時にコマンドが送出される際に介するベアラを必ずしも認識しない。従って、ベアラ特有の形式へのコマンドのパッケージ化は「サーバ側」で実行される。

拡張ＡＰＩは以下から構成される。
（ａ）「新しい」メッセージ、並びにそれらメッセージを送出及び受信するＡＰＩに一意の識別子を提供するクライアント側ＤＬＬ（ダイナミックリンクライブラリ）。
（ｂ）既存の各ベアラプラグインに対する「コンバータ」プラグイン。サーバはそれらプラグインを管理し、ベアラ特有の形式に及びベアラ特有の形式からメッセージを変換するというベアラからの要求に対応する。

特定のベアラの形式と特定の拡張ＡＰＩとの変換を行なうためのコンバータプラグインが見つからない場合、ベアラはＡＰＩからのメッセージを処理できず、それらメッセージはドロップされる。

＜コンバータ＞
コンバータはプラグインであり、以下の２つの間の変換を担う。
（ａ）１つのクライアント側ＡＰＩのメッセージ形式（Core APIであるか又は拡張機能である）。
（ｂ）１つのベアラのメッセージ形式。

従って、システムには最も重要なＮ個のコンバータが存在する。Ｎはベアラの数とＡＰＩの数との積である。実際には、Ｎはそれより小さくてもよい。その理由は、
ａ）拡張ＡＰＩが複数のベアラをサポートしないことを選択し、
ｂ）ベアラプロトコルが拡張機能をサポートできない可能性があるからである。

以下の説明において、特定のコンバータは、以下の規則に従って命名される。Converter(A, B)は、ＡＰＩのＡメッセージ形式とベアラのＢメッセージ形式との変換を行なうコンバータである。例えば、ＲｅｍＣｏｎの動作はConverter(Core, Serial)及びConverter(ExtApi1, Serial)を提供し、ＡＶＲＣＰはConverter(Core, Avrcp)及びConverter(ExtApil, Avrcp)を提供する。

本発明の実用的な一実施形態を図３に示す。図中、以下の実行ファイルを示す。
（ａ）ＲｅｍＣｏｎサーバ。
（ｂ）クライアント側ＡＰＩの３つのダイナミックリンクライブラリ（ＤＬＬ）。
・RemCon Core API。
・ＲｅｍＣｏｎ中間クライアント側（拡張機能に対するフレームワーク）。
・ＲｅｍＣｏｎ内部クライアント側。
（ｃ）Song Title API及びAbsolute Volume APIを供給する拡張ＡＰＩ（ExtraApi1）。
（ｄ）TargetSelectorPlug-in ＴＳＰに対する基本ＤＬＬ。
（ｅ）参照ＴＳＰ。
（ｆ）BearerPlug-in ベアラプラグインに対する基本ＤＬＬ、参照SerialBearer及びAVRCP Bearer。
（ｇ）ConverterPlug-in コンバータプラグインに対する基本ＤＬＬ。
・Converter(Core, Serial)。
・Converter(ExtApi1, Serial)。
・Converter(Core, AVRCP)。
・Converter(ExtApi1, AVRCP)。

一般に、それら構成要素に対するクラス定義は以下の通りである。

＜ＲｅｍＣｏｎ＞
●class CRemConServer : pulic CPolicyServer, public MRemConTargetSelectorPluginObserver
CRemConServerは、ＲｅｍＣｏｎサーバに対する具体的なサーバの種類である。
サーバは、コマンドキューを有し、制御する。サーバは、ＲｅｍＣｏｎの中心であり、全てのメッセージのルーティングを処理する。

●class CRemConSession : public CSession2
CRemConSessionは、具体的なサーバ側のセッションの種類である。
付加されたクライアント側RRemConハンドル毎に１つのインスタンスが作成される。

セッションは、クライアント側からの全てのＩＰＣコールに対応する。

セッションは、クライアントのプロセスＩＤを保持するメンバを有する。これは、セッションにより使用され、ターゲットセッションの完全にインスタント化されたインスタンスがクライアントプロセス毎に最大１つ作成されることを保証する。

この種のオブジェクトはクライアントの要求に対応し、後で完了するために、そのような非同期ＡＰＩ毎にRMessage2メンバを保持する。

●class CBearerManager : public CBase, public MRemConBearerObserver
CBearerManagerは１つであり、CRemConServerに所有される。
CBearerManagerは、インスタント化の際に全てのベアラプラグインをロードする。CBearerManagerは、ベアラに対するインタフェースである。

＜ベアラ＞
ここで、ベアラＡＰＩの設計及び参照シリアルベアラの設計を説明する。尚、各ベアラは、可能な各ＡＰＩにおいて全てのメッセージをサポートするように要求される。メッセージを送出しようとした場合にKErrNotSupportedを返すことによりそれを行なうことを許可されるが、単純にメッセージを無視又はドロップすることは許可されない。実際には、ＡＰＩを識別するＵＩＤはベアラにより使用され、適切なコンバータにメッセージを転送する。そのＡＰＩに対するコンバータが存在しない場合、KErrNotSupportedが適切な応答である。コンバータが見つけられるが特定のメッセージをサポートしない（ベアラ固有の理由により）場合、KErrNotSupportedが応答として返される。

●ベアラＡＰＩ
概要
ベアラはプラグインとなる。ベアラはコンバータプラグイン（原則的に、各ベアラは拡張ＡＰＩ毎に１つ及びCore APIに対して１つ有する）を使用して、ベアラプロトコル特有のメッセージ形式とクライアントが使用しやすいベアラアグノスティックのメッセージ形式との間で各メッセージを変換する。コンバータプラグインが特定の１組のベアラ／ＡＰＩに供給されない場合、そのベアラはそのＡＰＩに属するメッセージを送出又は受信できない。

ＲｅｍＣｏｎにより、ベアラは複数の同時接続をサポートできる。

ベアラは、サーバのスタートアップ時にインスタンス化される。ベアラのインスタンス化により、入力接続をリスンする。入力接続は、ベアラにより自動的に受け入れられ、ベアラのポリシーに準拠する。これは、プロトコル別のポリシー又は他のセキュリティポリシーを含む。ＲｅｍＣｏｍがセキュリティ保護されることを保証するのが望ましいことは明らかであるが、本発明は、任意の特定のセキュリティモデルを指定しないか又はそれに依存しない。

ＲｅｍＣｏｎは、新しい接続及び関連する（例えば、リモートアドレス）パラメータの存在を通知される。ベアラは、多重化又は複数の「リモートコントロールチャネル」をサポートできる。ＲｅｍＣｏｎは、任意のベアラ接続の状態をベアラにより通知される。

ベアラＡＰＩは、同時に送出される複数のコマンド及び応答をサポートできる。ベアラがキュー登録をサポートできる場合、ＲｅｍＣｏｎは、１つ以上の接続においてそのベアラで同時に未解決である多くのSendコマンドを通知できる。ベアラがキュー登録をサポートしない場合、ベアラはＲｅｍＣｏｎにエラーを返す必要があり、ＲｅｍＣｏｎは、それに従ってクライアントの元の要求を完了する。

送出要求の完了のタイミングの可能な例は以下を含む。
（ａ）ベアラがトランスポートを介して要求を送出しようとした後。
（ｂ）ベアラがメッセージに対する責任があると仮定された時、すなわちベアラが要求を送出したか又は送出のために要求をキュー登録した時。
（ｃ）応答が到着した時。

コネクションレスコントローラの場合、コマンドがＴＳＰによりアドレス指定されると、結果として得られるアドレス指定されたメッセージは、関連するベアラ接続を介して送出される。いずれかが失敗した場合、特定の命令された動作は中止され、コントローラクライアントはそのエラーを通知される。

ＲｅｍＣｏｎは、入手可能なベアラプラグインをクエリするＡＰＩを提供しない。これは、通常のオペレーティングシステム（ＯＳ）機能と共に使用される全てのプラグイン及びインタフェースの特性が公開情報であるため、必要に応じて通常のオペレーティングシステム（ＯＳ）機能を使用して達成される。

１度に１つの接続のみをサポートするコネクション指向ベアラは、作成された時にリスニングを開始する。ベアラが接続された場合（接続を受け入れることにより又はコネクション指向コントローラにより駆動された時）、ベアラは、ＲｅｍＣｏｎに接続の状態を通知する。何らかの理由により接続が終了した場合、ベアラはＲｅｍＣｏｎに通知する。

複数の接続（例えば、ＡＣＲＣＰ）をサポートするコネクション指向ベアラは、作成された時にリスニングを開始する。接続がリスナを使用して確立された場合、（更なる）入力接続をリスンし続ける。ＲｅｍＣｏｎは、接続の状態に関して最新情報を維持する。

コネクションレスベアラは、ベアラＡＰＩのコネクション指向の挙動をエミュレートする必要がある。シリアルベアラは、コネクションレスの挙動をサポートし、ＣＯＭポートが正常に開かれた場合にシリアルベアラが「接続されている」ことをＲｅｍＣｏｎに示すことができる。ポートを開くのに問題があった場合、少しの間をおいてから接続を再試行する。

関連するＡＰＩ
（尚、「@」で開始する行はＡＰＩパラメータを記録するか又は状態を返す。）
●class CRemConBearerPlug-in : public CBase
virtual void ConnectRequest(const TRemConAddress& aAddr) = 0;
ＲｅｍＣｏｎにより呼び出され、ベアラを別の相手に接続する。
@param aAddr リモートアドレス情報。

virtual void DisconnectRequest(const TRemConAddress& aAddr) = 0;
ＲｅｍＣｏｎにより呼び出され、ベアラを別の相手から切断する。
@param aAddr リモートアドレス情報。

メッセージの送出
virtual TInt SendCommand(TUid aInterfaceUid,
TUint aOperationId,
TUint aTransactionId,
RBuf8& aData,
const TRemConAddress& aAddr) = 0;
virtual TInt SendResponse(TUid aInterfaceUid,
TUint aOperationId,
TUint aTransactionId,
RBuf8& aData,
const TRemConAddress& aAddr) = 0;
ＲｅｍＣｏｎにより呼び出され、接続においてメッセージを送出する。ベアラは、返すことにより同期的に要求の完了（すなわち、メッセージを送出したか又は送出するためにメッセージをキュー登録したこと）を示す必要がある。
@param aInterfaceUid クライアントＡＰＩインタフェースのＵＩＤ。
@param aOperationId ＡＰＩ内の動作ＩＤ。
@param aTransactionId そのコマンド又は応答が属するトランザクションの識別子。
@param aData ＡＰＩ別のメッセージデータ。ベアラがKErrNoneを返す場合、ＲｅｍＣｏｎはベアラがその所有権を取得したと考える。
@param aAddr リモートアドレス情報。
@return Error。

尚、SendCommand要求を受け付けた後、ベアラは少なくとも１つの応答（本当に相手側からのものであるか否か）を生成する必要がある。

メッセージの受信
virtual TInt GetResponse(TUid& aInterfaceUid,
TUint& aTransactionId,
TUint& aOperationId,
RBuf8& aCommandData,
TRemConAddress& aAddr) = 0;
virtual TInt GetCommand(TUid& aInterfaceUid,
TUint& aTransactionId,
TUint& aOperationId,
RBuf8& aCommandData,
TRemConAddress& aAddr) = 0;
ＲｅｍＣｏｎにより呼び出され、NewCommand又はNewResponseを使用してベアラにより先に通知されたメッセージを取得する。
@param aInterfaceUid クライアントＡＰＩインタフェースのＵＩＤ。
@param aOperationId ＡＰＩ内の動作ＩＤ。
@param aTransactionId コマンド又は応答のトランザクションＩＤ。
@param aData ＡＰＩ別のメッセージデータ。所有権はベアラにより返される。
@param aAddr リモートアドレス情報。

virtual void Client Status(TBool aControllerPresent, TBool aTargetPresent) = 0;
これはＲｅｍＣｏｎにより呼び出され、コントローラクライアントが存在するか（aControllerPresent）及びターゲットクライアントが存在するか（aTargetPresent）を示す。
これは、以下の時に呼び出される：
（ａ）コントローラクライアントの数が０から１に又は１から０に変更された時。
（ｂ）ターゲットクライアントの数が０から１に又は１から０に変更された時。
aControllerPresentは、コントローラが存在する場合に真値であり、存在しない場合はEFalseである。作成者は、ETrueと比較しないことが分かる。このＡＰＩは、ＡＶＲＣＰベアラによるサービス発見プロトコル（ＳＤＰ）レコードの作成及び破壊を容易にするために提供される。ＲｅｍＣｏｎは失敗に関心がないため、戻り値の種類はvoidである。

virtual TSecurityPolicy SecurityPolicy() = 0;
@return トランスポートを使用（接続、送出、受信）する必要がある機能。
ＲｅｍＣｏｎは、任意の予想されるトランスポートを使用するのに十分な機能を有するが、コントローラクライアントが機能を有するかをチェックする必要がある。このＡＰＩは、ＲｅｍＣｏｎがコントローラクライアントの要求を監視できるように呼び出される。コネクション指向コントローラの場合、クライアントが自身をベアラと関連付けようとした時にチェックが行なわれる。コネクションレスコントローラの場合、ＴＳＰがクライアントの送信のために特定のベアラを選択した後にチェックが行なわれる。

●class MRemConBearerObserver
CRemConBearerPlug-inは、この種のオブジェクトに対する参照を有する。その参照は、要求の完了をＲｅｍＣｏｎに対して信号伝送するために使用される。

virtual TInt MrcboConnectIndicate(const TRemConAddress& aAddr) = 0;
入力接続が確立された時にベアラにより呼び出される。
@param aAddr リモートアドレス情報。
@return Error。

virtual void MrcboDisconnectIndicate(const TRemConAddress& aAddr) = 0;
接続がリモートエンドから切断された時にベアラにより呼び出される。
@param aAddr リモートアドレス情報。

virtual TInt MrcboConnectConfirm(const TRemConAddress& aAddr, TInt aError) = 0;
ベアラにより呼び出され、出力接続要求の完了を示す（CRemConBearerPlug-in::Connect)。
@param aAddr リモートアドレス情報。
@param aError エラー。
@return Error これがKErrNoneでない場合、ベアラは接続をドロップする。

virtual void MrcboDisconnectConfirm(const TRemConAddress& aAddr, TInt aError) = 0;
ベアラにより呼び出され、切断要求の完了を示す（CRemConBearerPlug-in::Disconnect)。
@param aAddr リモートアドレス情報。
@param aError エラー。

入力メッセージ
・virtual TInt MrcboNewResponse(const TRemConAddress& aAddr) = 0;
・virtual TInt MrcboNewCommand(const TRemConAddress& aAddr) = 0;
新しいメッセージがキューにおいて入手可能であり、ＲｅｍＣｏｎにより取得される時、ベアラにより呼び出される。ＲｅｍＣｏｎは、GetResponse又はGetCommandを呼び出す。
@param aAddr リモートアドレス情報。

virtual CRemConConverter& MrcboConverter(TUid aInterfaceUid, TUid aBearerUid) = 0;
コンバータのアクセス機構。与えられる２つのＵＩＤは、コンバータを一意に識別するために使用される。コンバータは、ＲｅｍＣｏｎにより管理され、単にそのインタフェースを介してベアラによりアクセスされる。
@param aBearerUid ベアラの実装のＵＩＤ。
@param aInterfaceUid インタフェースのＵＩＤ。

●シリアルベアラ
シリアルベアラは、ベアラインタフェースの具象実装である。CRemConSerialBearerは、CRemConBearerPlug-inから派生する。CRemConSerialBearerは、シリアル回線でデータを受信及び送出するためにRComm::Read及びRComm::Writeを使用するActive Objectsを有する。それらは、観察者インタフェースを介して完了したことを通知する。

CRemConSerialBearerは、インスタンス化の際にcommポートを開き、すぐにＲｅｍＣｏｎに対して「接続完了」を示す。CRemConSerialBearerは、ＲｅｍＣｏｎからコマンドを送出する要求を受信すると、ＡＰＩ ＵＩＤ及び動作ＵＩＤを固定長バッファにパッケージ化し（適切なコンバータを使用して）、それを再試行せずにシリアル回線を介して送出する。RComm::Writeが完了した時、CRemConSerialBearerは通知され、観察者のSendCompleteを呼び出す。CRemConSerialBearerは、ＲｅｍＣｏｎからコマンドを受信する要求を受信した場合、固定バッファサイズのためにRComm::Readをキュー登録する。これが完了すると、ストリングは、適切なコンバータを使用してＡＰＩ ＵＩＤと動作ＩＤとに分解され、ReceiveCompleteを介して観察者に通知される。

ＴＳＰ
●概要
ＴＳＰはプラグインである。

class CRemConTargetSelectorPlug-in : public CBase
●virtual void AddressOutgoingCommand(TUid aInterfaceUid, TUint aOperationId, const TClientInfo& aSender, TSglQue＜TRemConAddress＞& aConnections, TSglQue＜TBearerSecurity＞& aBearerSecurity) = 0;
これはＲｅｍＣｏｎにより呼び出され、所定の出力（すなわち、コネクションレスコントローラからの）コマンド（aInterfaceUid/aOperationId）をアドレス指定する。aConnectionsは、渡される時は空である。ＴＳＰは、０個以上のTRemoteAddressesを追加し、ＲｅｍＣｏｎのOutgoingCommandAddressedを呼び出す。ＴＳＰはこれを非同期的に行なってもよい。ＲｅｍＣｏｎは、関連する接続情報と共にコマンドを所定のベアラに向ける。

●virtual void PermitOutgoingCommand(TUid aInterfaceUid, TUint aOperationId, const TClientInfo& aSender, const TRemConAddress& aConnection) = 0;
これは、コネクション指向コントローラがコマンドを送出しようとした時にＲｅｍＣｏｎにより呼び出される。ＴＳＰは、ETrue（送出可能）又はEFalse（送出不可能）を有するOutgoingCommandPermittedを呼び出す。

●virtual void AddressIncomingCommand(TUid aInterfaceUid, TUint aOperationId, TSglQue＜TClientInfo＞& aClients)= 0;
これはＲｅｍＣｏｎにより呼び出され、所定の入力コマンドをアドレス指定する。aClientsは、渡される時、現在のターゲットクライアントの集合を含む。ＴＳＰは、０個以上の項目を追加又は０個以上の項目をその収集データから除去し、ＲｅｍＣｏｎのIncomingCommandAddressedを呼び出す。ＴＳＰは、これを非同期的に行なってもよい。ＴＳＰは、クライアントアプリケーションを自由に開始でき、適切なTClientInfo（少なくともクライアントアプリケーションのプロセスＩＤと共に読み込まれる）をその収集データに自由に追加できる。ＲｅｍＣｏｎは、所定のクライアントのいずれかが依然として存在することを仮定せずにそれら所定のクライアントにコマンドを向ける。

class MRemConTargetSelectorPluginObserver
ＲｅｍＣｏｎにより実装される。

●virtual void MrctspoOutgoingCommandAddressed(TInt aError) = 0;
ＴＳＰにより呼び出され、先のAddressOutgoingCommand要求が応じられたことを示す。（参照により渡された配列は、適切に読み込まれる。）１つのAddressOutgoingCommandのみが常に未解決であってもよいが、２つ以上のAddressOutgoingCommand及びAddressIncomingCommandが同時に未解決であってもよい。

●virtual void MrctspoOutgoingCommandPermitted(TBool alsPermitted) = 0;
ＴＳＰにより呼び出され、PermitOutgoingCommandの最新の呼び出しにより表されるコントローラの送出が許可されるか否かを決定したことを示す。

●virtual void MrctspoIncomingCommandAddressed(TInt aError) = 0;
ＴＳＰにより呼び出され、先のAddressIncomingCommand要求が応じられたことを示す（参照により渡された配列は、適切に読み込まれる）。尚、１つのAddressIncomingCommandのみが常に未解決であってもよいが、２つ以上のAddressOutgoingCommand及びAddressIncomingCommandが同時に未解決であってもよい。

TClientInfo
これは、クライアントセッションのプロセスＩＤ及び現在の送出メッセージをラップする単純な種類であり、セキュリティの目的で使用されてもよい。

クライアント側
●概要
ＲｅｍＣｏｎクライアント側は、コマンド及び応答の送出及び受信をサポートする。これは拡張可能である。図３に示すように３つの層を有する：
１．RRemConを含む単一のＤＬＬから成るサーバに最近接する「内部」クライアント側
２．単一のＤＬＬから成り、（ａ）内部クライアント側から適切な「外部」ＤＬＬに入力されるメッセージを渡し、（ｂ）基本ＡＰＩインターフェースに抽象インタフェースを提供し、（ｃ）最後のクライアントに中央セッションの作成及び制御点を提供する「中間」層
３．実際のＡＰＩ ＤＬＬから成る「外部」層。Core API DLL及び「拡張ＡＰＩ１」ＤＬＬ（曲名及び絶対音量メッセージをサポートする）は、この層で提供される。第３者は、この層に更なるＡＰＩを追加してもよい。この層の各ＤＬＬは、「ＡＰＩ ＵＩＤ」により一意に識別される。

内部クライアント側は、一般的なデータを送出及び受信する。データは、インタフェースＵＩＤ（特定の外部層ＤＬＬと関連付けられる）、そのインタフェース内の動作のＩＤ及び任意の関連するデータから成る。インタフェースＵＩＤ及び動作ＩＤは共に、一意のメッセージ識別子を構成する。

クライアントは、使用したい外部層ＤＬＬ及び中間層に静的にリンクする。初期化の際、クライアントは、中間層ＤＬＬのメソッドを呼び出し、外部層ＤＬＬからのオブジェクトを中間層に登録する（インタフェースＵＩＤにより）。中間層は、ＲｅｍＣｏｎセッションを開くメソッドを提供する。

メッセージがクライアントにより送出されると、外部層ＤＬＬはインタフェースＵＩＤを追加し、中間層はそのデータ全体をＲｅｍＣｏｎに単純に転送する。コマンドが受信されると、ＴＳＰは、そのコマンドが配信されるターゲットを決定する。応答が受信されると、ＲｅｍＣｏｎは元の要求を送出したコントローラクライアントにその応答を渡す。ＲｅｍＣｏｎサーバは、「内部」クライアント側の指示されたターゲットRRemConセッションにメッセージを配信し、そのセッションは中間層にメッセージを配信する。中間層は、メッセージのインタフェースＵＩＤを解析し、そのＵＩＤを有する登録された外部層オブジェクトを有する場合、その外部層オブジェクトにメッセージを渡す。外部層ＤＬＬは動作ＩＤを解析し、関連する（記述子）データを任意で分解し、それ自体のＡＰＩを介して最後のクライアントにメッセージを渡す。

●内部クライアント側（RRemCon）
「中間」クライアント側は、サーバに最近接する。「中間」クライアント側は、単一のＲクラス、RRemCon及びいくつかの補助の種類から成る。

悪用又は誤用する可能性のあるエンティティが制御を行わないようにするために、この時点でＲｅｍＣｏｎのアクセスを監視するある種のセキュリティを実現するのが好ましい。本発明は、任意の特定のセキュリティモデルに関してアグノスティックである。

クライアントは、このRemCon APIの内部層にアクセスできない。

class RRemCon : public RSessionBase
RRemConは、ＲｅｍＣｏｎサーバのクライアント側のセッションの種類に対する抽象ベースクラスである。これは、システムのデバッグビルドにのみサーバヒープ障害デバッグＡＰＩを提供するために使用される。ここでは、それらについては詳細に示さない。以下のＡＰＩは、派生した具象クラスのインスタンスから入手可能である。

●IMPORT_C TVersion Version() const;
ＲｅｍＣｏｎサーバのバージョンを返す。このＡＰＩは、Connectの前に呼び出される唯一のＡＰＩ（Closeを除く）である。

●IMPORT_C TInt Connect();
これは、標準セッションハンドル接続メソッドである。ハンドルの作成が成功した場合、更なるＩＰＣコールがＲｅｍＣｏｎサーバに対して行なわれ、クライアントの「種類」をターゲット又はコントローラとして設定する。

●IMPORT_C void Send(TRequestStatus& aStatus, TUid aInterfaceUid, TUint aOperationId, TUint& aNumRemotes, const TDesC8& aData = KNullDesC8());
Sendは、コマンドに対する応答を送出するために「ターゲット」により使用され、コマンドを送出するために「コントローラ」により使用される。

ターゲットクライアントが応答を送出する時、応答は、元のコマンドを転送したベアラで送出される。このアドレス指定は、ＲｅｍＣｏｎ自体により実行される。aInterfaceUidは、メッセージが属するインタフェース（Core又は拡張機能）のＵＩＤを含む。aOperationIDは、そのインタフェース内の動作のＩＤである。aDataは、任意の関連するデータである。クライアントがターゲットであり（すなわち、応答を送信する）、ＲｅｍＣｏｎサーバが対応するコマンドをそのクライアントに配信したことを記憶していない場合、クライアントは混乱する。

完了時、aNumRemotesは、メッセージが送出されたリモート数を含む。メッセージが応答であるか又はコネクション指向コントローラからのメッセージである場合、これは、成功時には１であり且つ失敗時には０になる。クライアントがコネクションレスコントローラである場合、aNumRemotesは、コマンドが送出されることをＴＳＰが要求したリモートのうち成功した数（ベアラレベルで）を示す。尚、ＴＳＰはコマンドを０個のリモートに送出するようにしてもよい。これはエラーではなく成功したと考えられる。

●IMPORT_C TInt SendCancel();
非同期的なSend要求の完了に対するクライアントの関心を消去する。

●IMPORT_C void Receive(TRequestStatus& aStatus, TUid& aInterfaceUid, TUint& aOperationId, TDes8& aData);
Receiveは、コマンドを受信するためにターゲットにより使用され、コマンドに対する応答を受信するためにコントローラにより使用される。

ターゲットは、全てのベアラから効率的にコマンドを受信し、ＴＳＰ機構に準拠する。コントローラクライアントは、各コマンドを発信したコントローラ及びコマンドが出力された際に介した接続を記憶するＲｅｍＣｏｎにより応答を配信してもらう。

●IMPORT_C TInt ReceiveCancel();
非同期的なReceive要求の完了に対するクライアントの関心を消去する。

●IMPORT_C TInt GetConnections(TSglQue＜TRemConAddress＞& aConnections);
全てのベアラ上の現在存在する接続に対する同期ゲッタである。TRemConAddressは、ベアラ（実装ＵＩＤにより）及びベアラ別の接続情報を示す。接続が配列にある場合、接続はＲｅｍＣｏｎのベアラレベルの接続として存在する。接続が配列に存在しない場合、接続はシステムのベアラレベルの接続として存在しない。他の状態は該当しない。成功時、クライアントはキュー中の項目を破壊する役割を果たす。

●IMPORT_C void NotifyConnectionsChange(TRequestStatus& aState);
ベアラ接続の状態の変化に対する通知。完了時、クライアントは、実際の接続を検査するためにGetConnectionsを使用するのが好ましい。

●IMPORT_C TInt NotifyConnectionsChangeCancel();
ベアラ接続状態変更通知の完了に対するクライアントの関心を消去する。

class RRemConController : public RRemCon
これは具体的なコントローラセッションの種類である。

●IMPORT_C TInt GoConnectionOriented(const TRemConAddress& aConnection);
所定のアドレスを使用してコントローラをコネクション指向にする。このアドレスはセッションから全てのコマンドを送出するために使用され、全ての応答はそのリモートから入力される（あるいは、対応するベアラにより生成される）。クライアントに関わるセキュリティ関連の問題が存在しないと仮定すると、ＲｅｍＣｏｎはそれに従ってGoConnectionOrientedを完了する。これは、ＲｅｍＣｏｎ自体が行なう唯一のセキュリティチェックであり、コネクション指向クライアントとベアラとの間にある全てのものである。各コマンドは、送出時にＴＳＰにより「許可」される。

●IMPORT_C TInt GoConnectionless();
所定のリモートを使用してコントローラをコネクションレスにする。ＴＳＰは、送出される各コマンドをアドレス指定するために使用される。

●IMPORT_C void ConnectBearer(TRequestStatus& aStatus);
コントローラクライアントは、このＡＰＩを呼び出し、GoConnectionOrientedに先に登録されたTRemConAddressを使用してベアラレベルの接続を作成しようとしてもよい。このＡＰＩは、コネクション指向コントローラによってのみ使用される。

●IMPORT_C TInt ConnectBearerCancel();
「ベアラ接続」要求の完了に対するクライアントの関心を消去する。

●IMPORT_C void DisconnectBearer(TRequestStatus& aStatus);
コントローラクライアントは、このＡＰＩを呼び出し、GoConnectionOrientedに先に登録されたTRemConAddressを使用してベアラレベルの接続を破壊しようとしてもよい。このＡＰＩは、コネクション指向コントローラによってのみ使用される。

●IMPORT_C TInt DisconnectBearerCancel();
「ベアラ切断」要求の完了に対するクライアントの関心を消去する。

class RRemConTarget : public RRemCon
これは、具体的なターゲットセッションの種類である。

TRemConAddress
これは、ＵＩＤ（ベアラの実装ＵＩＤ）及び小さなバッファをラップする単純な種類であり、ベアラ別の接続情報を保持する。

●中間層
class CRemConInterfaceSelector : public CBase
これは具象クラスである。これは、RRemConController及びRRemConTargetセッションを所有し、各々に対してセッション上にReceive要求を保持するActive Objectを所有する。このクラスは、ＲｅｍＣｏｎとのクライアントの対話の中心である。クライアントは、CRemConInterfaceSelectorをインスタンス化する。所望のＡＰＩインタフェースのインスタンスが作成され、CRemConInterfaceSelectorにより所有される。インスタンスは、コントローラとターゲットセッションとの少なくともいずれかを開き（セレクタのＡＰＩを介して）、（ａ）インタフェースを使用してコマンドを送出し且つ応答を待つか又は（ｂ）インタフェースを使用してコマンドを待ち且つ応答を送出する。

●IMPORT_C void OpenControllerL()
コントローラセッションを開くためにクライアントにより使用される。これは、デフォルトをコネクションレスにする。

●IMPORT_C void OpenTargetL();
ターゲットセッションを開くためにクライアントにより使用される。
RRemCon* APIをラップするために他のＡＰＩが提供される。

class CRemConInterfaceBase : public CBase
これは、Core APIを含むＡＰＩインタフェースに対するベースクラスである。

●メッセージの受信
virtual void MrcibNewResponse(TUint aOperationId, const TDesC8& aData) = 0;
virtual void MrcibNewCommand(TUint aOperationId, const TDesC8& aData) = 0;
これらは、適切な種類のメッセージがCRemConInterfaceBaseのインスタンス化に属するインタフェースＵＩＤと共に入力された時に中間層により呼び出される。

外部層
提供される構成要素は、'Core' API外部層ＤＬＬを含む。これは、CRemConInterfaceBaseの実装を提供し、１つはコントローラクライアントに対するものであり、１つはターゲットクライアントに対するものである。また、Song Title/Absolute Volume APIを提供するためにテスト「拡張」外部層ＤＬＬを提供する。

コンバータ
コンバータは、インタフェースを実装するプラグインであり、ステートレスである。

ＡＰＩは、実質的に以下の２つの機能から成る。
・ベアラ特有の形式からインタフェース特有の形式に変換する第１の機能。
・逆方向に変換する第２の機能。

尚、ベアラはコンバータを使用する義務がない。ベアラは、その全ての変換コードをハードコーディングできる。しかし、これは、ベアラが今後のＡＰＩ拡張機能の変換方法を理解していることを前提とする。これは、ベアラが既に存在するメッセージのセットのみをサポートする場合には十分に受け入れられるが、拡張性に対してはコンバータが使用されるのが好ましい。

●class CRemConConverterPlugin : public CBase
virtual TInt InterfaceToBearer(TUid aInterfaceUid, TUint aOperationId, const TDesC8& aData, TRemConMessageType aMsgType, TDes8& aBearerData) const = 0;
ベアラにより呼び出され、インタフェース特有のデータ（インタフェースＵＩＤ、動作ＩＤ、メッセージの種類及びデータ）をベアラ特有の（パッケージ化）形式に変換する。

virtual TInt BearerToInterface(const TDesC8& aBearerData, TUid& aInterfaceUid, TUint& aOperationId, TRemConMessageType& aMsgType, TDes8& aData) const = 0;
ベアラにより呼び出され、ベアラ特有のデータ（パッケージ化された）をインタフェース特有のデータ（インタフェースＵＩＤ、動作ＩＤ、メッセージの種類及びデータ）に変換する。

virtual TBool SupportedUids(const TUid& aInterfaceUid, const TUid& aBearerUid) const = 0;
ＲｅｍＣｏｎにより呼び出され、そのコンバータがそのインタフェースとそのベアラとの変換を行なうかを見つける。

virtual TBool SupportedInterface(const TDesC8& aInterfaceData, const TUid& aBearerUid) const = 0;
ＲｅｍＣｏｎにより呼び出され、そのコンバータがそのインタフェースとそのベアラとの変換を行なうかを見つける。aInterfaceDataは、ベアラ特有の形式のインタフェース識別子である。

サーバシステムに対する典型的な動作例は以下の通りである。

スタートアップ
●クライアントスタートアップコードの例
クライアントは以下を行なう義務がある：
CRemConInterfaceSelector* iInterfaceSelector = CRemConInterfaceSelector::NewL();
クライアントは、使用したいインタフェースのインスタンスを作成する必要がある。例えば、ターゲットとしての役割を果たし且つCore APIを使用したいアプリケーションの場合：
CRemConCoreApiTarget* iCoreIf = CRemConCoreApiTarget::NewL(*iInterfaceSelector, *this);
式中、「this」はMRemConCoreApiTargetObserverを実装する。iCoreIfはインタフェースセレクタにより所有されており、インタフェースセレクタはクライアントにより所有される。

MRemConCoreApiTargetObserverは、種々の入力Core APIコマンドが配信される時期を作成者に通知するために純粋仮想を有する。CRemConCoreApiTargetは、アプリケーションがそれらコマンドに対する応答を送出することを可能にするメソッドを更に有する。

クライアントは、コントローラ又はターゲットセッションを作成する必要がある。CRemConInterfaceSelectorのインスタンス毎にいずれか一方が作成されてもよい。１つのターゲットのみがクライアントプロセス毎に接続されてもよい。

コントローラセッションを作成する：
iInterfaceSelector-＞OpenControllerL();
コントローラセッションは、コネクションレスモードで開かれる（送出されるコマンドはＴＳＰによりルーティングされる）。コントローラをコネクション指向にするために、以下が後続してもよい：
TRemConAddress addr;
addr.BearerUid() = TUid::Uid(0x1020453C);
//ベアラ特有の接続データ無し
iInterfaceSelector-＞GoConnectionOrientedL(addr);
クライアントはこの時点でベアラレベルの接続を確立し、第１のコマンドの送出を迅速にすることを要望する：
TRequestStatus stat;
iInterfaceSelector-＞ConnectBearer(stat);
User::WaitForRequest(stat);
上記例において、実装ＵＩＤ 0x1020453Cのベアラが使用される。これはテストシリアルベアラである。コネクション指向コントローラにより送出されるコマンドは、この呼出しにおいて与えられる特定の接続に向けられる。ターゲットセッションを開くために、以下が呼び出される：
iInterfaceSelector-＞OpenTargetL();
サーバ側
ＲｅｍＣｏｎサーバは、第１のセッション（コントローラ又はターゲット）の接続によりサーバ自体のプロセスにおいて開始される。サーバが既に実行している場合、単純にセッションが接続される。

第１に、CRemConServerの１つのインスタンスが作成される。このサーバがＣ＋＋構築後にまず行なうことは、一意のサーバ名を使用してStartLを介してカーネルにサーバ自体を登録することである。実行しているサーバのインスタンスが既に存在する場合（接続を試みる２つ以上のクライアント側によりトリガされる競合条件のため）、StartLは終了し、初期のサーバは容易に破壊される。これにより、システムにおいて完全にインスタンス化されたＲｅｍＣｏｎサーバは１つだけ存在することが保証される。

StartLの後、サーバは、関連する動作により以下のオブジェクトの作成に関して設定を行なう。
（ａ）任意の要求されたシステムロギングオブジェクト又はプラグイン（Symbianの共通オブジェクトモジュール等）のフレームワークオブジェクト等の必要とされる任意のオペレーティングシステムオブジェクト。
（ｂ）シャットダウンタイマ。これは、接続されたセッションが存在しない時にサーバを終了するために使用される。これは、最後のセッションが閉じた時にのみ開始される。
（ｃ）GetConnections及びNotifyConnectionsChange APIをサポートする１つの接続履歴オブジェクト。
（ｄ）CBearerManagerの１つのインスタンス。ベアラマネージャの作成により、全てのベアラプラグインが列挙され且つインスタンス化される（ConstructLにおいて）。これにより、コネクション指向ベアラは入力接続のリスニングを開始する。テストシリアル（コネクションレス）ベアラは、ＣＯＭポートを開き、出力接続を行なうのを要求されたかのように迅速にConnectCompleteにより呼び戻す。システムにベアラの実装が存在しない場合、ＲｅｍＣｏｎは混乱する。これは、有効なデバイス構成である場合にＲｅｍＣｏｎが実装される必要がなかったからである。
（ｅ）メッセージをログ記録するために使用されるCMessageQueueの５つのインスタンス。各々は、ＴＳＰによるアドレス指定又は許可の付与を保留する出力コマンド；送出された出力コマンド（リモートからの応答を保留にする）；ＴＳＰによるアドレス指定を保留する入力コマンド；通知されるクライアントReceive要求を保留する入力メッセージ；コントローラセッションに配信された入力コマンド（コントローラからの応答を待つ）に対して存在する。
（ｆ）コンバータマネージャの１つのインスタンス。これは、各コンバータの１つのインスタンスを作成する。
（ｇ）ＴＳＰの１つのインスタンス。システムにおいて、ＴＳＰインタフェースの実装が正確に１つ存在しない場合、ＲｅｍＣｏｎは混乱する。ＴＳＰは、希望する任意のインスタンス化を実行してもよいが、ＲｅｍＣｏｎは、コマンドをアドレス指定するために使用されるオブジェクトを正常に返す以外のことを行なうことを予想していない。

上記動作の全ては同期して発生する。その後、システムは正常にインスタンス化される。このすぐ後、CActiveScheduler::Startはサーバスタートアップコードで呼び出され、任意の更なる動作は非同期的に発生する。それら動作は以下を含む。
（ａ）リモートエンドからのベアラを介する接続に対する変更。入力接続が発生した場合、ＲｅｍＣｏｎはベアラにより伝えられる。接続がリモートでドロップされた場合、ＲｅｍＣｏｎは伝えられる。ＲｅｍＣｏｎはその情報を使用してクライアント通知を完了する。
（ｂ）特定の接続のベアラに対するＲｅｍＣｏｎが開始した接続又は切断要求の完了。ＲｅｍＣｏｎは、リモートでトリガされた接続変更と同様の方法でそれらを処理する。接続及び切断要求は、クライアントにより開始される。ＲｅｍＣｏｎが特定の接続を介してメッセージを送出したい時、ＲｅｍＣｏｎは最初にそれが存在するかをチェックしない（ベアラが存在する場合）。すなわち、Ｒｅｍｃｏｎはベアラにメッセージを提供し、そのメッセージを処理するためにベアラをそのままにしておく。
（ｃ）ベアラからの入力メッセージ。
（ｄ）入力クライアント要求。クライアントがセッションを閉じ、それが最後のセッションである場合、サーバはシャットダウンを開始する。通常の「シャットダウン」の例を以下に説明する。クライアントがメッセージを送信しようとする場合、メッセージは、ＴＳＰによりアドレス指定されるか又はクライアントにより明示的にアドレス指定される（コネクション指向である場合）。

シャットダウン
ＲｅｍＣｏｎから切断するために、クライアントは、インタフェースオブジェクト及びインタフェースセレクタを削除する必要がある。最後の開いているセッションを閉じることにより、サーバのシャットダウンがトリガされる。

セッションが閉じられると必ずデストラクタが呼び出される。これは、サーバにその事象を無条件に通知し、サーバは、そのセッションに属するコマンドをキューから除去し、開いているセッションの数を監視する。開いているセッションの数がゼロになった場合、シャットダウンタイマが開始される。シャットダウンタイマが終了した時、サーバはCActiveScheduler::Stopを呼び出すことにより終了する。任意の新しいセッションが到着した場合（随時）、シャットダウンタイマはキャンセルされ、セッションが要求された時にサーバが終了しないことを確実にする。

CActiveScheduler::Stopが呼び出された時、CActiveScheduler::Startを呼び出した後、実行はサーバスタートアップコードに戻る。サーバオブジェクトは、すぐに破壊される。以下の事象は以下の順番で発生する。
（ａ）ベアラマネージャが破壊される。これにより、ベアラ上の全ての未解決の要求が取り消され、同期をとって破壊される。ベアラの破壊は、容易に動作するように構成され、接続を閉じ、サービスプロバイダ上のそれ自体の要求を適切に取り消す。
（ｂ）この時、シャットダウンタイマは安全に破壊される。
（ｃ）メッセージの配列が破壊される。
（ｄ）ＴＳＰが破壊される。しかし、ＴＳＰにより現在アドレス指定されている入力コマンドがある場合、ＴＳＰに未解決の要求が存在する可能性がある。従って、ＴＳＰは、未解決の要求を取り消し、同時にＴＳＰ自体を完全に除去するように構成される。
（ｅ）コンバータマネージャが破壊される。これは全てのコンバータインスタンスを破壊する。
（ｆ）接続履歴オブジェクトが破壊される。
（ｇ）作成されたオペレーティングシステムオブジェクトが更に破壊される。

サーバの破壊は、開始されると取消しできない。サーバのシャットダウンが発生している間にクライアントが接続しようとする場合、カーネルはクライアントの接続の試みをエラーで完了する。この状況において、クライアント側はサーバを再起動し、接続を再度試みる。

出力コマンド及び入力応答
出力コマンドの例は、インスタンス化されたインタフェースにより提供されるＡＰＩを使用して、コントローラクライアントがコマンドを送出することにより開始してもよい。例えば：
TRequestStatus stat;
iCoreIf-＞Play(stat);
User::WaitForRequest(stat);
Core APIは、Play（例えば）要求を一般的な「動作ＩＤ」及び関連するデータ（例えば、再生速度）に変換してもよい。Core APIは、そのインタフェースＵＩＤを有する中間層にそのデータを渡す。中間層は、メッセージをサーバに送出するためにコントローラセッションを使用する。

サーバは、コントローラセッションを検査する。CRemConMessageは接続アドレス（コントローラがコネクション指向の場合）、インタフェースＵＩＤ、動作ＩＤ、関連するデータ、メッセージの種類（コマンド又は応答）及び元のセッションのＩＤを含んで構成される。

セッションがコネクション指向コントローラの場合、このメッセージは「ＴＳＰへの出力保留アクセス」キューに配置され、許可付与のためにＴＳＰに提供される。許可が与えられた場合、メッセージは「出力送出」キューに配置され、所定の接続アドレスを有する適切なベアラに配信される。ベアラは、その要求の受入れを同期をとって指示する。エラーの場合、メッセージは「出力送出」キューから除去される。クライアントの送出要求は、すぐに完了される。許可がＴＳＰにより拒否された場合、クライアントの要求はKErrPermissionDeniedで完了される。

コントローラがコネクションレスである場合、メッセージは「ＴＳＰへの出力保留アクセス」キューに配置され、アドレス指定（可能性として非同期的な）のためにＴＳＰに提供される。ＴＳＰがアドレス指定要求を完了した時、メッセージは、「ＴＳＰへの出力保留アクセス」キューから除去され、各々がＴＳＰにより指示される各アドレスに対するものであるＮ個のコピーが「出力送出」キューに挿入され、関連するアドレス指定情報を有する適切なベアラにＮ回送出される。この時点までのエラーはキューをロールバックし、クライアントにエラーを返す。この例におけるＴＳＰの目的は、実質的には、メッセージを送出するためにメッセージの接続アドレスフィールドを読み込むことである。

その後ある時点で、リモートは、送出されたコマンドに対する応答を送出してもよい。応答のリモートアドレス、インタフェースＵＩＤ及び動作ＩＤは、「出力送出」キューに対してチェックされる。一致した項目が見つけられた場合、元のコマンドの送信元セッションＩＤは、クライアントコントローラに対する入力応答をアドレス指定するために使用される。一致したコマンドが見つけられない場合、応答はドロップされる。応答は、クライアントReceive要求を完了するために使用され、「出力送出」キューから一致したコマンドが完全に除去される。尚、中間層（CRemConInterfaceSelector）は、中間層が有する任意の接続されたコントローラ又はターゲットに未解決のReceive要求を維持する。クライアントがReceive要求を未解決にしない場合、「入力保留Receive」キューは、応答及びコマンドの双方をキュー登録するために使用されてもよい。

クライアント側において、新しい応答は特定のコントローラセッションに対してサーバにより配信される。所有するインタフェースセレクタは、インタフェースＵＩＤをオンにし、インタフェース上のNewResponseを呼び出す。インタフェースは、動作ＩＤを検査し、関連するデータを任意で分解し、例えば、観察者（クライアント）のPlayResponseを呼び出す。

要約すると、クライアントはコマンドを送出する非同期要求を行なう。要求は完了し、クライアントは後でPlayResponseを呼び出してもらう。

ＴＳＰがPlayコマンドを複数のリモートに向け、複数のリモートがそれぞれ応答を生成する場合、PlayResponseはクライアントで複数回呼び出される。

入力コマンド及び出力応答
この例は、ベアラが入力コマンドをＲｅｍＣｏｎに配信することにより開始する。ＲｅｍＣｏｎは、リモートアドレス、インタフェースＵＩＤ、動作ＩＤ、関連するデータ及びメッセージの種類（コマンド又は応答）を含むCRemConMessageを作成する。このメッセージは、「入力保留アドレス」キューに配置され、アドレス指定のためにＴＳＰに送出される。

本質的に、この例におけるＴＳＰの目的は、アドレスのセッションＩＤフィールドを読み込むことである。これが行なわれると、メッセージは「入力保留アドレス」キューから除去され、Ｎ個のコピーは「入力配信」キューに追加され、各々は関連するターゲットクライアントに配信される。コマンドがセッションに到着した時、クライアントがReceive要求を未解決にしない場合、「入力保留Receive」キューが使用されてもよい。中間層はインタフェースＵＩＤをチェックし、メッセージを適切なインタフェースオブジェクトに転送する。インタフェースはメッセージを分解し、例えばクライアント上のPlayを呼び出し、Playコマンドが受信されたことを示す。

クライアントは、応答を送出することを選択してもよい。クライアントはPlayResponseを呼び出し、PlayResponseは中間層のターゲットセッションを介してＲｅｍＣｏｎにメッセージを送出する。サーバは、コマンドがセッションＩＤ、インタフェースＵＩＤ及び動作ＩＤと一致するか「入力配信」キューをチェックし、応答を適切なベアラにアドレス指定するために見つけられたコマンドのリモートアドレスを使用する。見つけられたコマンドは、キューから除去され且つ破壊される。

リモートコントロールクライアントアプリケーションは、以下のように実装されてもよい。この例は、既存のリモートコントロールＡＰＩを使用してリモートコントロールシステムのクライアントを実現することを含む。

まず、アプリケーションがコントローラに対するものか又はターゲットに対するものかを決定する。他のデバイスをリモートコントロールする必要がある場合、コントローラのアプリケーションが必要とされる。リモートコントロールされる必要がある場合、ターゲットのアプリケーションが必要とされる。コントローラ及びターゲットの双方になることが常に許可される。

コントローラが必要とされる場合、通信するリモート及び通信の際に介するベアラを認識する必要がある。この情報が周知である場合、アプリケーションはコネクション指向モードで動作してもよい。ここで、リモートコントロールシステムはベアラ及びリモートのアドレスを明示的に示される。この情報が周知でない場合、アプリケーションはコネクションレスモード（デフォルト）で動作する必要がある。この場合、コマンドはシステムにより（特にデバイスの製造業者により提供されるTarget Selector Plug-inにより）ルーティングされる。

使用される必要のあるＡＰＩを決定する必要がある。Play、Stop等を含む多くの基本動作を範囲に含むCore APIが提供される（TrackInfo API及びAbsolute Volume APIが提供されるが、そのようなメッセージをＢｌｕｅｔｏｏｔｈを介して送出及び受信できる必要がある下位レベルの実装をしない。）。

次に、コントローラのセットアップについて説明する。

第１のステップは、CRemConInterfaceSelectorのインスタンスを作成することである。これは、クライアント側の中心であり、サーバ上のセッション及びインタフェースオブジェクトを所有し、それらの間でメッセージをルーティングする。

CRemConInterfaceSelector*sel = CRemConInterfaceSelector::NewL();
次に、所望のＡＰＩのコントローラインタフェースのインスタンスが作成される（この例においては、Core API）。

CRemConCoreApiController* cont = CRemConCoreApiController::NewL(*this, *sel);
このコードは、これがMRemConCoreApiControllerObserverを実装する種類のオブジェクトであるのが前提である。このミックスインは、入力応答（コマンドに対する）が配信される方法を判定する。この時、contの所有権はselにある。

次に、インタフェースセレクタにコントローラセッションをサーバと接続するように伝える必要がある。

sel-＞OpenControllerL();
この時点で、コントローラセッションはコネクションレスである。送出されたコマンドはＴＳＰによりアドレス指定される。制御されるベアラ及びリモートが周知である場合、次のコードが使用されてもよい：
TRemConAddress addr;
addr.BearerUid() = xxx; //xxx＝ベアラのＵＩＤ
addr.Addr() = yyy; //yyy＝ベアラ特有の形式のリモートのアドレス
sel-＞GoConnectionOrientedL(addr);
GoConnectionOrientedLが成功すると、アプリケーションはコネクション指向になり、コントローラセッションは指定された単一のリモートとの通信専用になる。ＴＳＰは、特定のコマンドをアドレス指定をしないが、送出される各コマンドを依然として許可又は拒否する。尚、リモートとのベアラレベルの接続はこの動作により確立されない。

以下を使用して再びコネクションレスになることが可能である。

sel-＞GoConnecctionlessL();
コネクション指向になると、送出される第１のコマンドの待ち時間を短縮するために、以下のように、リモートとのベアラレベルの接続を明示的にセットアップできる：
TRequestStatus stat;
sel-＞ConnectBearer(stat);
User::WaitForRequest(stat);
これが行なわれない場合、第１の（及び任意の後続する）コマンドが送出された時、サーバは必要に応じて接続を確立しようとする。ConnectBearerは、待ち時間を短縮するために１つの能力として提供される。

ベアラレベルの接続は以下のように切断される：
TRequestStatus stat;
sel-＞DisconnectBearer(stat);
User::WaitForRequest(stat);
尚、ベアラレベルの接続は任意に制御されるべきではない。アプリケーションが現在「コネクション指向」であるベアラレベルの接続のみを制御できる。これは、ConnectBearer及びDisconnectBearerのTRemConAddressパラメータが欠如している理由である。

尚、リモートはリモート自体の命令でアプリケーション接続を確立又は切断してもよい。リモートが接続を切断する場合、送出される次のコマンドにより、サーバはその接続を再び確立しようとする。これは、不測の待ち時間を伴う可能性がある。再接続が失敗した場合、送出は失敗する。それにも関わらず、アプリケーションはコネクション指向のままである。接続の向きは、実際のベアラレベルの接続に依存しない。

ベアラレベルにおいて、接続の状態に関心があると考えられる場合、CRemConInterfaceSelectorの以下のＡＰＩが使用されてもよい：
IMPORT_C TInt GetConnections(TSglQue＜TRemConAddress＞& aConnections);
IMPORT_C void NotifyConnectionsChange(TRequestStatus& aStatus);
IMPORT_C TInt NotifyConnectionsChangeCancel();
GetConnectionsは、システム中に現在存在する全ての接続を供給する。NotifyConnectionsChangeは、その設定が変更された時期のみを示す。

●コマンドの送出及び応答の受信
contは、以下のようにコマンドを送出するために使用される。
TRequestStatus stat;
cont-＞Play(stat);
User::WaitForRequest(stat);
応答はMRemConCoreApiControllerObserverインタフェースを介して配信される。

１つのコマンドの送出のみが常に未解決である。コネクションレスコントローラが実装される場合、ＴＳＰは複数のリモートに対してコマンドをアドレス指定した可能性がある。この場合、単一のコマンドの送出の結果として複数の応答を得てもよく、それら応答は、フィルタリングされるか又は適切な場合には使用される。

ＴＳＰが複数のリモートにコマンドを送出し、それら送出の１つ以上が失敗した場合、エラー値は失敗した送出のうちの１つから提供される。更に、コマンドが正常に送出されたリモート数が提供される。ベアラは、送出した各コマンドに対する応答を取り戻す義務がある。ベアラに依存して、その応答を実際にリモートから得ても得なくてもよい。送出は、ベアラレベルで成功するか又は失敗する。すなわち、ベアラは送出の管理をするか又は管理をしない。従って、「成功した」送出の結果、要求されたリモートへの送信を行なわない場合がある。

尚、リモートに送出された各コマンドには、サーバのヒープに割り当てられているメモリが関与し、これはクライアントの終了時又は応答の受信時にのみ解放される。通信を要求されないリモートが存在しないと考えられる適切な理由が存在する場合、リモートはサーバのメモリへの負荷を軽減するためにリモートへのコマンドの送出を停止するように構成されるのが好ましい。

●切断
リモートコントロールシステムの介入を無くすために、全ての未解決の非同期的な要求は取り消されるべきであり、インタフェースセレクタは削除されるべきである。

ターゲット
●セットアップ
これは、コネクション指向の概念がないこと以外はコントローラのセットアップに非常に類似する。ターゲットはミックスインを実装し、インタフェースセレクタは、そのミックスインを介して、入力コマンドを配信し且つ応答を送出するためのオブジェクトをインスタンス化する。全ての入力コマンドは、ＴＳＰによりアドレス指定される。出力応答は、元のコマンドを発信したリモートに対して明示的にアドレス指定される。

CRemConInterfaceSelector* sel = CRemConInterfaceSelector::NewL();
CRemConCoreApiTarget* targ = CRemConCoreApiTarget::NewL(*this, *sel);
この時、targの所有権はselにある。

次に、クライアントはサーバ上にターゲットセッションを開く。

sel-＞OpenTargetL();
●コマンドの受信及び応答の送出
入力コマンドは、MRemConCoreApiTargetObserverミックスインを介して（上記例においては）提供される。

コマンドを受信すると、応答の送出を要求される。

TRequestStatus stat;
cont-＞PlayResponse(stat, response);
User::WaitForRequest(stat);
常に、１つの応答のみが未解決である。コマンドが迅速に入力されると、それらコマンドに対する応答をキュー登録する必要がある。しかし、ターゲットに配信される各コマンドにはサーバのヒープに割り当てられたメモリが関与し、それはクライアントの終了時又は応答の送出時にのみ解放される。

●切断
リモートコントロールシステムの介入を無くすために、全ての未解決の非同期的な要求は取り消されるべきであり、インタフェースセレクタは削除されるべきである。

新しいリモートコントロールＡＰＩは以下のように実装されてもよい。

新しいＡＰＩを実装するために、外部層ＤＬＬの作成及びコンバータのグループの作成の２つの作業が行なわれる必要がある。

外部層ＤＬＬ
外部層ＤＬＬのジョブは以下の通りである。
（ａ）使用し易いＡＰＩをクライアントに提供すること。
（ｂ）クライアントＡＰＩのフィールド／項目とＤＬＬの内部データ形式（動作ＩＤ及び動作別データのフィールドのレイアウトの双方を含む）との変換を行なうこと。
（ｃ）必要なだけ上述のものを発表し、（ｉ）クライアントにＡＰＩを使用する権限を与え、（ii）コンバータの作成者に権限を与えること。

Core APIにおいて確立されたパターンに従って、以下のステップが後続してもよい。
・remconinterfacebase.libにリンクする静的ＤＬＬを作成する。
・ＡＰＩに対して新しいＵＩＤを割り当てる。
・CRemConInterfaceBaseから得られる新しいＡＰＩのコントローラ及びターゲットの種類の各々に対してクラスを定義する。
・NewL及びデストラクタメソッド、並びにエクスポートされた公開メソッドを提供する−コントローラの場合はコマンドを送出し、ターゲットの場合は応答を送出する。
・入力応答及びコマンドのそれぞれを通知されるクライアントに対して、コントローラ及びターゲットの各々の観察者のミックスインを定義する。
・各インタフェースにおいて、CRemConInterfaceBase::MrcibNewMessageは、入力メッセージを復号化し且つ適切なミックスインメソッドを呼び出すために実装される。
・動作識別子及びＡＰＩの各メッセージの形式を指定する。それらはコンバータを形成するために使用される。

＜コンバータ＞
クライアントが外部層ＤＬＬを使用してメッセージを送出する場合、ベアラは以下の情報を受信する。メッセージを発信したＡＰＩのＵＩＤ、メッセージの動作ＩＤ及び任意の動作別データを含む記述子である。動作別データのデータ形式とベアラにより要求される形式とを変換することがコンバータのジョブである。

コンバータＡＰＩは、remotecontrol\converterplag-in\publicにある（しかし実際には、epoc32\include\remconの#includeである）。Core_Serialコンバータは、remotecontrol\test\converters\Core_Serialにある。

Core_Serialコンバータに確立されたパターンに従って、新しい実装ＵＩＤがコンバータに対して割り当てられるべきであり、ＥＣＯＭプラグインとしてConverter APIを実装する。CRemConConverterPlug-in::SupportedUids(const TUid& aInterfaceUid, const TUid& aBearerUid)は、所定のＡＰＩと所定のベアラとの間のメッセージ形式の変換がサポートされるか否かを判定するために実装されるべきである。

CRemConConverterPlug-in::SupportedInterface(const TDesC8& aInterfaceData, const TUid& aBearerUid)は、僅かに異なる方法で配置される以外は同一のサポート問題に応じるために実装される。この場合、ＡＰＩは所定のベアラの形式でパッケージにより識別される。残りのコンバータの実装は相対的に単純である。

コンバータは、ステートレスな同期的なデータ処理マシンである。変換を行なうために、コンバータはＡＰＩの動作ＩＤ及びＡＰＩのＵＩＤを認識する必要がある。

しかし、ベアラは、メッセージを「理解する」ためにコンバータの助けを明示的に要求する必要がある。ベアラが要求しない場合、コンバータは呼び出されない。すなわち、ベアラは、変換方法を既に認識しているＡＰＩ以外のＡＰＩに対して実質的に閉じられている。これは、ベアラによっては完全に有効になる。

しかし、新しいＡＰＩが実装される場合、コンバータは既存の各ベアラに提供される必要がある。この情報が提供されない場合、事実上、フレームワークはベアラの形式と新しいＡＰＩの形式との間でメッセージを変換する方法をベアラに通知できない。実質上、これは、新しいＡＰＩがその特定のベアラを介して使用されないのと同等である。これは、特定のフレームワークの必要条件によっては問題ない。

コンバータは、ＡＰＩにより発表されるフォーマティング情報だけでなくベアラからのフォーマティング情報を必要とする。しかし、道理上、ベアラの形式はプロプライエタリリモートコントロールＡＰＩである発表された仕様（例えば、ＡＶＲＣＰ）として存在する可能性が高い。

ＴＳＰは以下のように実装されてもよい。

まず、ＴＳＰ ＡＰＩを実装するプラグインは、新しい実装ＵＩＤで実装される。

ＴＳＰは、以下の問題に応じることができるように準備すべきである。
（ａ）サーバは、現在接続されている（すなわち、サーバに接続されている）どのターゲットクライアントに対して、以下の入力コマンド（インタフェースＵＩＤ及び動作ＩＤ、並びにターゲットクライアントのセキュアＩＤを含むターゲットクライアントに関する情報の集合を有する）を配信すべきか。
（ｂ）サーバは、どのリモートに対して、以下の出力コマンド（インタフェースＵＩＤ及び動作ＩＤ、セキュアＩＤ及びRMessage2を含んでコマンドを送出しようとするコントローラクライアントに関する情報、並びにベアラに対するTSecurityPolicyの集合を有する）を配信すべきか。

尚、ＴＳＰがクライアントＸにコマンドを提供した場合、ＴＳＰは元のコマンドを配信したベアラを介して１つの応答を正確に送出する権限をクライアントＸに効果的に与える。

そのようなＤＬＬは、ＲＯＭに１つのみ存在する必要がある。

新しいリモートコントロールベアラは、以下のように実装される。

ベアラＡＰＩを実装するプラグインは、新しい実装ＵＩＤで作成される。

ベアラＡＰＩはコネクション指向である。送出及び配信される全てのメッセージは、特定の受信者アドレス又は特定の送信者アドレスと関連付けられる。サーバは、特定のリモートに対してベアラレベルの送出を発行する前にそのリモートに対するベアラレベルの接続を確立する役割を果たす。

実際のベアラは、実際にはコネクション指向でない可能性がある。例えば、テストシリアルベアラは、シリアルケーブルを介して単純に動作する。従って、（ａ）テストシリアルベアラは、ベアラ特有のリモートアドレス形式を有さず（そのため、「リモートアドレス」は単純にシリアルベアラのＵＩＤから成る）、（ｂ）最初にシリアルポートを開いた場合、スタートアップ時に入力接続を実質的に「示す」ことによりコネクション指向の挙動をエミュレートする必要がある。この「接続」は切断されることはない。

ベアラは、サーバスタートアップ時にインスタンス化され、すぐに入力接続のリスニングを開始する必要がある。各接続は、サーバまで示される。

本発明は、現在の非一般的なフレームワークを介して重要な利点を提供する一般的なリモートコントロールフレームワークを提供することが上述から分かる。利点は以下を含む。
・リモートコントロールされるアプリケーションの作成を容易にすること。既存のリモートコントロール解決策が１つのベアラ技術と常に結び付けられるため、従来、アプリケーションが関係する特定のベアラ技術を利用するように開発されない限り、一般的なリモートコントロールのためのアプリケーションを提供できなかった。
・デバイスの製造時には応じることができなかった新しい技術を使用するアフターマーケットアクセサリをリリースするというデバイスの製造業者の能力。本発明なしでは、そのようなアクセサリは新しいバージョンの制御可能なアプリケーションと共に出荷する必要があるだろう。
・複数の制御可能なアプリケーションをデバイス上で同時に実行する能力。２つ以上のアプリケーションが存在する場合、その能力は複数の可能なターゲットアプリケーションのうちの１つを選択する機構を提供する。

特定の実施形態を参照して本発明を説明したが、添付の請求の範囲により規定される本発明の範囲内で変更が行なわれてもよいことは理解されるだろう。

本発明のそのような変更の可能な一例は、複数のオーディオアプリケーションを有する演算装置に適用可能であり、全ての複数のオーディオアプリケーションはリモートコントロールコマンドを受信するように登録されている。複数のオーディオアプリケーションを有するそのようなデバイスは、インターネット、ボイスメモ又は音声入力アプリケーションからのストリームオーディオ及びローカルなボイスメールストアを再生できるＭＰ３プレーヤ、ラジオ、ブラウザプラグイン等のオーディオデータを再生できる多くのマルチメディアアプリケーションを有する移動電話を含んでもよい。

全てのアプリケーションがリモートコントロールコマンドを受信するように登録されている場合、リモートコントロールマネージャがデバイス上のリモートコントロールコマンドを既にオーディオを再生している１つのアプリケーションに配信できるようにすることにより、アプリケーションが既にオーディオを再生していた場合、本実施形態はそのようなコマンドの正確な配信を可能にする。

本発明に係るリモートコントロールアーキテクチャを示す図である。 本発明に係るリモートコントロールアーキテクチャを概略的に示す図である。 本発明に係るリモートコントロールアーキテクチャの実際的な一実施形態を示す図である。

Claims (1)

1. １つ以上のターゲットデバイスが任意のベアラを介して任意のコントローラデバイスからコマンドを受信できるようにする一般的なリモートコントロール・インタフェースを提供することにより、
   ・ＵＳＢ及び単純なシリアルを含む固定配線と、
   ・赤外線と、
   ・超音波と、
   ・Ｂｌｕｅｔｏｏｔｈ及び８０２．１１無線ネットワーキングを含むがそれらに限定されないＲＦと、
   を含むがそれらに限定されない複数のベアラのうち少なくとも１つを介して送出されたコマンドを使用して、１つ以上のコントローラデバイスが前記１つ以上のターゲットデバイスをリモートコントロールできるようにする方法。

Images