JP6159717B2 - 異なる通信インターフェースの使用を介した装置の制御 - Google Patents

Description

［関連出願の相互参照］
本出願は、２０１１年５月１２日に出願された米国特許仮出願第６１／４８５，６０８号明細書の利益および／または優先権を主張するものであり、参照によりその全体が本明細書に具体的に組み込まれる。

本発明は２つの装置間でコマンドの通信を行う分野に関し、特に、第１のコマンドセットが第１の通信インターフェースを介して通信され、第２のコマンドセットが第２の通信インターフェースを介して通信される、２つの装置間の通信に関する。

家庭での設定において、ユーザは、ディスプレイ装置およびセットトップボックスを使用してケーブル事業者、電話事業者、衛星事業者などのマルチサービス事業者（ＭＳＯ）から受信するプログラムを表示させることができる。異なるプログラムオプションを選択するために、ユーザは、タブレット、電話機、リモートコントロールなどの制御装置を使用して、チャンネルの変更、プログラムの記録、電子プログラムガイドの表示などを含む種々のアクションを実行するようセットトップボックスに命令することもできる。制御装置からセットトップボックスへ送信されるコマンドがサポートされない場合があるが、これはコマンドそのものがセットトップボックスに認識されないことがあるからである。制御装置からのコマンドがセットトップボックスに無視される場合もあり、これはセットトップ専用のコマンドセットを発行する認証された制御装置に対してのみセットトップボックスが応答する、という専用コマンドがあり得るからである。

具体的には、セットトップボックスは、認証された分類の制御装置と相互運用可能となっている、電子プログラムガイドのルックアップ、記録ビデオなどの特別なアプリケーションを実装することができる。セットトップボックスと連携することが可能な認証された分類の制御装置の例には、セットトップボックスと同じ製造者による制御装置が含まれ、該制御装置において、セットトップボックス上で制御可能なアプリケーションを実行させるためのライセンスを購入済みである、該制御装置が種々のセキュリティプロトコルを使用して認証されたものであるなどの場合がある。従って、ユーザが、認証されない分類の制御装置をセットトップボックス装置と共に使用し、異なるコマンド、ステータス、およびイベントのメッセージが該装置間で往復して伝送されるＭＳＯから受信する媒体の記録または再生を制御したい場合には問題がある。

２つの装置間において、制御装置から受信装置に対してどのコマンドをサポート可能であるかについての判定を行う方法およびシステムが提示される。そのような判定がなされると、第１のコマンドが、第１の通信インターフェースを通じて制御装置から受信装置へ伝送される。そして、制御装置は、第２のコマンドを、第１の通信インターフェースとは異なる第２の通信インターフェースを通じてやはり受信装置に伝送する。制御装置および受信装置に第２の通信インターフェースを介して連結されるサーバは、第２のコマンドを第１の形式から第２の形式に変換することができる。

本開示のこれらおよび他の態様、特徴、および利点は、添付の図面と関連付けて読まれるべき以下の好ましい実施形態の詳細な説明によって、記載され明らかになるであろう。
図面において、全体を通して同様の参照番号は同様の要素であることを示す。
本開示に従う、コンテンツを配信するための例示的システムのブロック図である。 異なる装置間でコマンドを配信するための方法のフローチャートである。 装置間でコマンドを伝送する際に使用する異なる通信インターフェースを判定するための方法のフローチャートである。

記載される実施形態は、ＭＳＯからの顧客宅内機器をユーザの家庭において典型的に配備する際に適用することができる。オーディオ、ビデオ、テキスト、コンピュータゲーム、ビデオゲームなどの媒体が記録および／または再生のために受信される任意のタイプの設定に対して、以下に記載する原理を適用可能であることが想定される。

ここで、図１を参照すると、本開示の一実施形態に従って、マルチサービス事業者から媒体を受信するために使用されるシステム１００が示されている。図１内の装置間で使用可能な通信インターフェースには、無線周波数、同軸ケーブル、光ファイバーケーブル、電話回線、デジタル加入者回線、ケーブル、Ｔ３、イーサネット（登録商標）などを含むことができる。システム１００の装置は、１つまたは複数のプロセッサを使用してコンピュータ使用可能コードを実行することが可能である。

制御装置１０５は、受信装置１１０を介する媒体の選択および／または再生を制御するために使用可能なタブレット、電話機、コンピュータ、リモートコントロール、入力装置、パーソナルアクセスデバイス、ディスプレイ装置などの装置である。具体的には、制御装置１０５は、受信装置１１０にコマンドを発行し、該コマンドはＭＳＯから受信するプログラムの記録および／または再生を制御するために使用される。加えて、制御装置１０５からのコマンドは、電子プログラムガイド機能、ビデオオンデマンドの購入および再生などの受信装置１１０上のアプリケーションを可能にするべく使用することができる。選択的な一実施形態において、制御装置１０５は、ストリーミングなどの技術を使用することにより受信装置１１０を介して受信される媒体の再生を行うことが可能であり、または、制御装置１０５は、媒体を後で再生するためにダウンロードすることができ、その場合その媒体は受信装置１１０を介して受信される。受信装置１１０はまた、アプリケーションサーバ１３０、ヘッドエンドサーバ１４０、およびコンテンツサーバ１５０と通信するべく構成されてよい。

受信装置１１０は、ＭＳＯから媒体（メディア）を受信可能なセットトップボックス、コンピュータ、ディスプレイ装置、受信機などの装置とすることができる。受信装置１１０は、アプリケーションサーバ１３０、ＭＳＯのヘッドエンドサーバ１４０、および、媒体が格納されるコンテンツサーバ１５０と共に動作するべく構成されてよい。一実施形態において、制御装置１０５および受信装置１１０は、ＲＦコマンドを使用するなど第１の通信スキームを使用してお互いに通信可能であり、一方、そのような装置は第２の通信形式を使用してお互いに通信可能であり、その場合アプリケーションサーバ１３０およびヘッドエンドサーバ１４０が、以下に記載するように第２の通信形式の仲介として動作する。コンテンツサーバ１５０は、記録および／または再生のために受信装置１１０に配信されるオーディオ、ビデオ、テキスト、コンピュータゲーム、ビデオゲームなどの媒体を含むことができる。

制御装置１０５、受信装置１１０、アプリケーションサーバ１３０、ヘッドエンドサーバ１４０、およびコンテンツサーバ１５０は、ＥＢＩＦ（Ｅｎｈａｎｃｅｄ ＴＶ Ｂｉｎａｒｙ Ｉｎｔｅｒｃｈａｎｇｅ Ｆｏｒｍａｔ）などのメッセージスキームを使用して、図１に示す任意の他の装置と通信することが可能であるが、他のメッセージスキームを使用することも可能である。典型的には、ＥＢＩＦコマンドは、パケットのヘッダ内の送信先装置のデバイスＩＤ番号（装置に固有のＩＤ、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス、ＩＰアドレスなどとすることができる）、およびパケットペイロード内の送信元装置のＩＤ番号を使用して伝送される。

一実施形態において、アプリケーションサーバ１３０は、通信インターフェースを通じて受信される、制御装置１０５からのコマンドを解釈するように構成される。具体的には、ＲＥＳＴ（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ）サービスが、制御装置１０５からコマンドを受信するアプリケーションサーバ１３０上でホストされる。ＲＥＳＴの用語体系を利用して、特定のサーバ、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスなどを対象とすることができるＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）「／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓ」を使用して、制御装置１０５からアプリケーションサーバ１３０にコマンドが伝送される。記載されるサービスの関連ＵＲＩは、本開示の明細書で提供される例においては同一であるが、サーバ名およびＩＰアドレスは異なることに留意されたい。ＵＲＩには、シングルパスの一部をプレフィックスすることもでき、そのようなプレフィックスは必要に応じで修正可能である。

そして、アプリケーションサーバ１３０は、ＵＲＩ「／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓ」を使用して、受信したコマンドまたはステータスリクエストをヘッドエンドサーバ１４０に転送することができる。アプリケーションサーバ１３０は、受信したＵＲＩをＥＢＩＦコマンドに変換することができ、該コマンドは次に受信装置１１０に転送され、それによって該コマンドがＴＶＷｏｒｋ、ＥｎａｂｌｅＴＶ、アプリケーションフレームワークなどのＥＢＩＦインタープリタフレームワークにより解釈され、これにより、ＥＢＩＦコマンドで指定されるアクションを受信装置１１０に実行させる。

本開示の実施形態には、リバースコマンドパスを含むことができ、その場合受信装置１１０がＥＢＩＦ形式を使用してヘッドエンドサーバ１４０にコマンドを発行する。ヘッドエンドサーバは、ＲＥＳＴスキームを使用してＥＢＩＦコマンドをＵＲＩ「／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ｏｒｉｇｉｎａｔｅｄ＿ｍｅｓｓａｇｅｓ」に解釈して、これが、ＲＥＳＴ ＰＵＴリクエストコマンドを使用してアプリケーションサーバ１３０に伝送される。アプリケーションサーバ１３０は、該コマンドを、本実施形態においては制御装置１０５である、先に記述したＵＲＩで特定される装置に固有のキューにコピーすることができる。制御装置１０５は、現在キューに入っているいずれかのコマンドをアプリケーションサーバ１３０に要求することができ、それにより、そのようなコマンドは、一度配信されるとアプリケーションサーバ１３０内のキューから削除される。アプリケーションサーバ１３０は、そのようなコマンドをヘッドエンドサーバ１４０から受信した時はいつも、受信したコマンドを制御装置１０５に伝送るべく構成されてもよい。説明した原理の様々な実施形態では、図１の装置間でコマンドを通信する際に「ｐｕｓｈ」、「ｐｕｌｌ」、またはそのような技術の組み合わせを使用することができることに、留意されたい。ＲＥＳＴフレームワークでは、ＰＵＴ ＨＴＴＰコマンドを使用して「ｐｕｓｈ」コマンドが実行され、一方、ＧＥＴ ＨＴＴＰを使用して「ｐｕｌｌ」コマンドが実行される。このタイプのＥＢＩＦ／ＲＥＳＴ技術を利用して、マッピングを使用して制御装置１０５を受信装置１１０にマッピングすることが可能であり、図１に示すようなシステムに装置が加えられたり削除されたりすると、リマッピング操作を行うことができる。

本開示の一実施形態において、アプリケーションサーバ１３０は、制御装置１０５から受信したコマンドメッセージを同一の世帯内にある受信装置１１０に送信するために使用されるサービスをホストする。「／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓ」のようなＵＲＩコマンドを使用して、コマンドおよびステータスリクエストの両方が送信される。このサービスを実装することにより、ヘッドエンドサーバ１４０によりホストされる／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓサービスに、リクエストが中継される。

／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓのエンドポイントは、ＨＴＴＰ ＰＵＴバーブをサポートする。各メッセージの内容は単一コマンドまたはステータスリクエストのメッセージである。本サービスによりサポートされるＭＩＭＥコンテンツ型は「ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｔｅｃｈｎｉｃｏｌｏｒ．ｃ３＿ｅｂｉｆ．ｒｅｑｕｅｓｔ．ｖｌ」であり、これはカスタムエンコーディングに関連するコンテンツ型の識別子である。リクエストには、リクエストがアドレス指定される受信装置の識別子を含まなければならない。この識別子は、カスタムＨＴＴＰヘッダ「ｘ−ｃ３−ｅｂｉｆ−ｓｔｂ−ｉｄｅｎｔｉｆｉｅｒ」内に格納される。ＳＴＢ識別子の値は、メッセージの送信先である受信装置１１０のＭＡＣアドレスである。ＭＡＣアドレスは識別子内に記述される。ＨＴＴＰリクエストのボディを形成するコマンドメッセージは、本明細書に記載するパイプ区切り形式で配信することができる。

このサービスエンドポイントでは、全ての他のＲＥＳＴサービスで使用されるセキュリティ用の同一のｘ−ｄｅｖｉｃｅ−ｔｏｋｅｎ／ｘ−ｕｓｅｒ−ｔｏｋｅｎＨＴＴＰヘッダを使用する。従って、アプリケーションサーバ１３０は、送信元の制御装置１０５およびＨＴＴＰヘッダでアドレス指定される受信装置１１０を推測することが可能である。理想的には、制御装置１０５の識別子はコマンドメッセージを用いて送信されるｘ−ｄｅｖｉｃｅ−ｔｏｋｅｎ／ｘ−ｕｓｅｒ−ｔｏｋｅｎヘッダに関連する装置と一致すべきである。

ヘッドエンドサーバ１４０は、アプリケーションサーバ１３０から受信装置１１０にコマンドメッセージを中継するために使用されるサービスをホストする。サービスエンドポイント／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓを使用して、装置間でコマンドおよびステータスメッセージの両方を送信する。本開示の一実施形態において、サービスは、ＥＢＩＦプロトコルを使用して、ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓに記述されるアドレス指定された制御装置に、メッセージをルートする。

サービスエンドポイントがＵＲＩ「／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓ」において使用されるとき、メッセージの内容が単一コマンドまたはステータスリクエストのメッセージである、ＨＴＴＰ ＰＵＴコマンドが使用される。メッセージの形式は、そのようなリクエストがアドレス指定される受信装置１１０を識別できるようにしなければならない。識別子はＨＴＴＰヘッダ「ｘ−ｃ３−ｅｂｉｆ−ｓｔｂ−ｉｄｅｎｔｉｆｉｅｒ」内に格納される。ｓｔｂ識別子の値は、そのようなコマンドを受信すべき制御装置１１０のＭＡＣアドレスにしなければならない。ＨＴＴＰリクエストの本体を形成するコマンドメッセージは、本明細書に記載するパイプ区切り形式で配信することができる。

アプリケーションサーバ１３０はまた、受信装置１１０によって発行される任意のコマンドをアプリケーションサーバ１３０に通知するために使用することができる、ＵＲＩ「／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ｏｒｉｇｉｎａｔｅｄ＿ｍｅｓｓａｇｅｓ」にてサービスをホストするように構成することができる。また、アプリケーションサーバ１３０は、コマンドおよびステータスリクエストのコマンドレスポンスを受信装置１１０から制御装置１０５に中継することができる。先に記述したキューに注目すると、コマンドまたはステータスメッセージは、アプリケーションサーバ１３０により蓄積可能であり、これらは次に、ある時間が経過した後制御装置１０５に「ｐｕｓｈ」されるか、または、情報のリクエストにより制御装置１０５からアプリケーションサーバ１３０に「ｐｕｌｌ」される。

／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ｏｒｉｇｉｎａｔｅｄ＿ｍｅｓｓａｇｅｓのエンドポイントは、ＨＴＴＰ ＰＵＴバーブ（ｖｅｒｂ）をサポートする。各メッセージの内容は、単一コマンドまたはステータスリクエストのメッセージである。本サービスによりサポートされるＭＩＭＥコンテンツ型は「ｔｅｘｔ／ｗｗｗ−ｕｒｌ−ｆｏｒｍｅｎｃｏｄｅｄ」であり、データ内容は理想的には受信装置１１０からアプリケーションサーバ１３０に送信されるデータと同一である。／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ｏｒｉｇｉｎａｌｅｄ＿ｍｅｓｓａｇｅｓサービスは、アプリケーションサーバ上に存在するメッセージであり、好ましくはほとんど修正されない。

ＨＴＴＰリクエストは、メッセージを発行した受信装置１１０を識別することができる。この識別子はＨＴＴＰヘッダ「ｘ−ｃ３−ｅｂｉｆ−ｓｔｂ−ｉｄｅｎｔｉｆｉｅｒ」内に格納され、ｓｔｂ識別子の値は受信装置１１０のＭＡＣアドレスである。ヘッダには、ＥＢＩＦ形式でコマンドを発行した（帯域外メッセージと帯域内メッセージを比較して）第２の受信装置の場所を含むこともできる。メッセージボディのボディには、コマンドを受信することになる送信先の制御装置１０５を識別する情報を含まなければならない。メッセージがコマンドまたはステータスレスポンスメッセージである場合、メッセージ内の識別子は、元のリクエストにおける元の送信先識別子に記述される制御装置１０５の識別子と一致しなければならない。メッセージがイベントメッセージである場合は、メッセージ内の識別子は、受信装置１１０からイベントメッセージが通知されるように先にサブスクライブした制御装置１０５と一致しなければならない。

アプリケーションサーバ１３０は、本発明の一実施形態において、サービスを操作するべく構成される。サービスを使用して、受信装置１１０から発信されて任意の制御装置１０５に対してアドレス指定されるコマンドメッセージをキューに入れ最終的に配信する。サービスエンドポイント／ｃ３＿ｅｂｉｆ／ｄｅｖｉｃｅ＿ｑｕｅｕｅを使用して、コマンド、ステータスレスポンス、およびイベントメッセージが受信される。このサービスを実装することにより、制御装置１０５に対してアドレス指定されるメッセージをキューに入れる。ＧＥＴサービスリクエストに対するレスポンスは、特定の制御装置１０５に対してアドレス指定される、キューに入っている全てのメッセージを返し、これらのメッセージをアプリケーションサーバ１３０のキューから消去する。

／ｃ３＿ｅｂｉｆ／ｄｅｖｉｃｅ＿ｑｕｅｕｅエンドポイントは、ＨＴＴＰ ＧＥＴコマンドをサポートする。各メッセージの内容は単一コマンドまたはステータスリクエストのメッセージである。メッセージの形式は、受信装置１１０のレスポンスメッセージのＸＭＬパッケージである。個々のレスポンスメッセージは、受信装置内のコマンドＡｐｐにより発信されるコマンドメッセージと同一にフォーマットされる。メッセージのコレクションはＸＭＬ形式で「ｗｒａｐ」され、本開示の実施形態において、ＸＭＬ形式では、コマンドレスポンスメッセージのコレクションが、単一のルートエレメントを用いて単一のＸＭＬドキュメントにパッケージ化される。個々のレスポンスメッセージはまた、発信元受信装置の識別子（ＭＡＣアドレス）を、各コマンドレスポンスメッセージに関連付けることもできる。このサービスでサポートされるＭＩＭＥコンテンツ型は、「ｔｅｘｔ／ｘｍｌ」であるが、メッセージ内に含まれる個々のコマンドレスポンスメッセージは、コンテンツ型の識別子「ｔｅｘｔ／ｗｗｗ−ｕｒｌ−ｆｏｒｍｅｎｃｏｄｅｄ」に従ってフォーマットされる。

サービスに対するリクエストを処理するために、リクエストにはキューがアクセスされるべき制御装置１０５の識別子を含まなければならない。識別子は通常のＲＥＳＴサービス装置のトークンまたはユーザ装置のトークンにより提供され、これはリクエストと共に送信されることが必要である。トークンから、アプリケーションサーバ１３０は、装置ＩＤを推測することが可能である。レスポンスで返されるメッセージには、アプリケーションサーバ１３０の／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ｏｒｉｇｉｎａｔｅｄ＿ｍｅｓｓａｇｅｓサービスを介して装置に対してアドレス指定される全ての配信されないコマンドレスポンスメッセージが含まれる。

アプリケーションサーバ１３０は、コマンドリクエストを変換してＣ３ＥＢＩＦＣｈａｎｎｅｌＦａｃａｄｅインターフェースの実装に中継するサービスを「／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓ」にて実行することができる。インターフェースは、アプリケーションサーバ１３０とヘッドエンドサーバ１４０との間の通信チャネルをサポートするための統一されたｆａｃａｄｅ（ファサード）であるべく設計される。実装により、アプリケーションサーバ１３０とヘッドエンドサーバ１４０との間の双方向のメッセージ交換の「ｐｕｓｈ」通知スタイルをサポートすることができる。／ｃ３＿ｅｂｉｆ／ｄｅｖｉｃｅ＿ｑｕｅｕｅサービスはまた、コマンドレスポンスを同一のＣ３ＥＢＩＦＣｈａｎｎｅｌＦａｃａｄｅインターフェースから変換してキューに入れる。

記載されるインターフェースは、「ｐｕｓｈ」スタイルメッセージ送信操作を使用して、制御装置１０５が発信するメッセージを受信装置１１０に中継することを含むいくつかの操作をサポートするべく設計される。別の操作では、受信装置１１０が発信するキューに入れられたメッセージが提供され、これが、Ｃ３ＥＢＩＦＣｈａｎｎｅｌＦａｃａｄｅを使用して制御装置１０５に配信され、「ｐｕｌｌ」スタイルメッセージ回収操作を使用して発信されるイベントを受信することができる。サポートされる他の操作では、受信装置１１０から発信されるイベントに特定の関心事を登録または登録取り消しをする制御装置１０５が提供される。

上述のｆａｃａｄｅのＪＡＶＡ（登録商標）実装を以下に示す。
ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ Ｃ３ＥＢＯＦＣｈａｎｎｅｌＦａｃａｄｅ ｛
／＊＊
＊ Ｃ３メッセージを識別されたＳＴＢに送信
＊＊／
ｐｕｂｌｉｃ ｖｏｉｄ ｓｅｎｄ（Ｓｔｒｉｎｇ ｓｔｂＩｄ， Ｓｔｒｉｎｇ ｍｅｓｓａｇｅＣｏｎｔｅｎｔ） ｔｈｒｏｗｓ ＮａｖｉＳｙｓｔｅｍＥｘｃｅｐｔｉｏｎ；
／＊＊
＊ 所与の装置にキューに入れられるメッセージを返す
＊ ＠ｐａｒａｍ ｄｅｖｉｃｅＩｄ Ｏｐａｑｕｅ装置の識別子。内部マップキーとして使用。
＊ ＠ｐａｒａｍ ｍａｘＣｏｕｎｔ Ｍａｘｉｍｕｍ 返されるメッセージの数。＜＝０であるどの値も
＊ 「ｎｏ ｌｉｍｉｔ」と解釈され、任意の多数のキューに入れられる
＊ メッセージが返されてよい。
＊ ＠ｒｅｔｕｒｎｓ Ａ ｌｉｓｔ ｏｆ Ｔｕｐｌｅ２＜Ｓｔｒｉｎｇ， Ｓｔｒｉｎｇ＞、 ＳＴＢ識別子と
＊ Ｃ３ メッセージボディのペア。 Ｉｆ ＜ｉ＞ｍａｘＣｏｕｎｔ＜／ｉ＞ ＞ ０， ｔｈｅｎ ｔｈｅ
＊ ｌｉｓｔ ｓｉｚｅ ｉｓ ＜＝ ＜ｉ＞ｍａｘＣｏｕｎｔ＜／ｉ＞．
＊＊／
ｐｕｂｌｉｃ Ｌｉｓｔ＜Ｔｕｐｌｅ２＜Ｓｔｒｉｎｇ， Ｓｔｒｉｎｇ＞＞ ｒｅｃｅｉｖｅＤｅｖｉｃｅＭｅｓｓａｇｅｓ（
Ｓｔｒｉｎｇ ｄｅｖｉｃｅｌｄ， ｉｎｔ ｍａｘＣｏｕｎｔ） ｔｈｒｏｗｓ ＮａｖｉＳｙｓｔｅｍＥｘｃｅｐｔｉｏｎ；
｝

メッセージベースのシステムにおいてｐｕｓｈ／ｐｕｌｌの正反対の逆転性がある場合は常に、メッセージのキューでは「ｐｕｌｌ」の機構を介して最終的に配信されるようにメッセージをバッファリングすることが必要とされる。上述のシステムは、制御装置１０５に対する受信装置１１０のシーケンスにおいてｐｕｓｈ／ｐｕｌｌの正反対の逆転性を有する。具体的には、ヘッドエンドサーバ１４０が、／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ｏｒｉｇｉｎａｔｅｄ＿ｍｅｓｓａｇｅｓＲＥＳＴサービスを介して制御メッセージをアプリケーションサーバ１３０にｐｕｓｈし、制御装置１０５がこれらのメッセージを／ｃ３＿ｅｂｉｆ／ｄｅｖｉｃｅ＿ｑｕｅｕｅＲＥＳＴサービスを介してアプリケーションサーバ１３０からｐｕｌｌする。

このｐｕｓｈ／ｐｕｌｌの正反対の逆転性はＣ３ＥＢＩＦＣｈａｎｎｅｌＦａｃａｄｅインターフェースにおいて露出される。インターフェースは、コマンドメッセージを受信装置１１０に送信するためのｐｕｓｈメソッド（ｓｅｎｄ）、および、特定の制御装置１０５に対してアドレス指定されるメッセージを回収するためのｐｕｌｌメソッド（ｒｅｃｉｅｖｅＤｅｖｉｃｅＭｅｓｓａｇｅｓ）を提示する。従って、キューイングの実装はＣ３ＥＢＩＦＣｈａｎｎｅｌＦａｃａｄｅの実装に内在し、ＲＥＳＴサービスベースのインターフェース実装に固有のものである。

カスタムパイプ区切り形式を使用して、本明細書に記載されるサービスのいくつかの実施形態のコマンド、ステータスリクエストメッセージ、およびイベントが表される。具体的には、記載されたサービスをサポートするいくつかの実施形態において、全く同一のパイプ区切りコマンドメッセージ形式を使用して、中継ポイントにてメッセージの構文解析を必要とすることなく、メッセージの中継および配信を円滑にする。アプリケーションサーバ１３０においてこれらのサービスに含まれるものには、制御装置１０５によりメッセージを受信装置１１０に伝送するために使用される／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓＲＥＳＴサービスリクエストボディ、アプリケーションサーバ１３０とヘッドエンドサーバ１４０との間のメッセージを受信装置１１０に伝送するために使用されるヘッドエンドサーバ１４０の／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓＲＥＳＴサービスリクエストボディがある。この形式は上述のｆａｃａｄｅインターフェースにも使用される。

パイプ区切り形式はコマンドの伝送に使用され、それにおいて、記載される実施形態のいくつかでは同じタイプのＸＭＬ形式を使用して、異なる中継ポイントにおけるメッセージ構文解析を必要とすることなく、メッセージの中継および配信を最小化する。すなわち、そのようなコマンドは、メッセージを受信装置１１０からアプリケーションサーバ１３０に中継するために使用される、／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ｏｒｉｇｉｎａｔｅｄ＿ｍｅｓｓａｇｅｓサービスのＲＥＳＴサービスリクエストボディ内に見出される。Ｃ３ＥＢＩＦＣｈａｎｎｅｌＦａｃａｄｅのコマンドｒｅｃｅｉｖｅＤｅｖｉｃｅＭｅｓｓａｇｅｓは、そのような情報を、返されるコマンドメッセージの内容に使用される第２のメンバの返されるＴｕｐｌｅ２オブジェクト内に置く。加えて、アプリケーションサーバ１３０の／ｃ３＿ｅｂｉｆ／ｄｅｖｉｃｅ＿ｑｕｅｕｅサービス内の返り値は、伝送されたＸＭＬドキュメント内でそのようにラップされてもよい。

コマンドメッセージがＸＭＬメッセージボディとしてエンコードされる場合、第１のメッセージ型は、コマンドおよびステータスリクエストのメッセージであり、これらは特定の受信装置１１０を対象とする制御装置１０５から発信されるメッセージである。コマンドレスポンス、ステータスレスポンス、および自発イベントメッセージを含む他のメッセージ型は、受信装置から登録された制御装置１０５に発信されるコマンドである。

コマンドおよびステータスのメッセージは、いくつかの実施形態においてカスタムバイナリ、パイプ区切り形式でエンコード可能である。記載された形式は、ＥＢＩＦ通信用のＥｎａｂｌｅＴＶにより既に使用されている。メッセージは、２バイトの「トリガ値」０ｘ０００１で始まる。メッセージの次の２バイトは、バイトで表すと２バイトビッグエンディアンの整数長のメッセージである。より具体的には、この整数のこの値は、「トリガ値」の２バイトとメッセージ長の２バイトを含まない、残りのメッセージの長さである。メッセージの残りはＡＳＣＩＩエンコードされたパイプ区切りのペイロードである。メッセージは、文字列フィールドの配列であると見なしてよく、それにおいてフィールドはパイプ文字区切りにより分離される。第１のフィールドは常にＡＳＣＩＩ１０進法でエンコードされたメッセージ型コードである。残りのフィールドは数および内容の両方においてメッセージ固有である。メッセージ全体は、常に最終パイプ文字により終了される。

図２を参照すると、フローチャート２００が示されている。フローチャート２００では、チャネル変更コマンドを受信装置１１０に発行する制御装置１０５について記載する。本実施形態において、制御装置１０５がＩＤ「ｔａｂＸＹＺ」を持ち、受信装置１１０がＭＡＣアドレス「００−Ｂ０−Ｄ０−８６−ＢＢ−Ｆ８」を持つ。変更チャネルコマンドを要求するリクエストは、仮想チャネル「５」に対するものである。先に、制御装置１０５は、「ＣＡＦＥＢＡＢＥ」に適合する装置のトークンをアプリケーションサーバ１３０から取得している。

ステップ２０５にて、制御装置１０５は、パイプ区切り形式のコマンドをアプリケーションサーバ１３０に送信する。コマンドの形式は以下の通り。

＃ ＨＴＴＰ ＰＵＴ ｒｅｑｕｅｓｔ ｔｏ ／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓ

＃ ＨＴＴＰ ｈｅａｄｅｒ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｔｅｃｈｎｉｃｏｌｏｒ．ｃ３＿ｅｂｉｆ．ｒｅｑｕｅｓｔ．ｖｌ
ｘ−ｃ３−ｅｂｉｆ−ｓｔｂ−ｉｄｅｎｔｉｆｉｅｒ： ００−Ｂ０−Ｄ０−８６−ＢＢ−Ｆ８
ｘ−ｄｅｖｉｃｅ−ｔｏｋｅｎ： ＣＡＦＥＢＡＢＥ

＃ Ｍｅｓｓａｇｅ ｂｏｄｙ
［［０ｘ００ ０ｘ０１ ０ｘ００ ＯｘＯＣ
０ｘ７Ｃ ０ｘ７４ ０ｘ６１ ０ｘ６２
０ｘ５８ ０ｘ５９ ０ｘ５Ａ ０ｘ７Ｃ
０ｘ３４ ０ｘ７Ｃ ０ｘ３５ ０ｘ７Ｃ］］

＃ Ｅｘｐｌａｎａｔａｔｏｒｙ ｂｒｅａｋｄｏｗｎ ｏｆ ｔｈｅ ｍｅｓｓａｇｅ ｂｏｄｙ
＃ ［［０ｘ００ ０ｘ０１］］ − ｔｒｉｇｇｅｒ ｗｏｒｄ
＃ ［［０ｘ００ ０ｘ０Ｃ］］ − ｍｓｇ ｌｅｎｇｔｈ ｗｏｒｄ
＃ “｜ｔａｂＸＹＺ” − ｓｏｕｒｃｅ ｄｅｖｉｃｅ ＩＤ
＃ “｜４” − ｍｅｓｓａｇｅ ｔｙｐｅ
＃ “｜５” − ａｒｇ． ｔｏ ｍｓｇ −− ｖｉｒｔｕａｌ ｃｈａｎｎｅｌ ｎｕｍｂｅｒ
＃ “｜” − ｔｅｒｍｉｎａｔｉｎｇ ｐｉｐｅ ｃｈａｒ

＃ ＨＴＴＰ ２００ ｒｅｓｐｏｎｓｅ
ステップ２１０にで、アプリケーションサーバ１３０は、パイプ区切り形式のコマンドメッセージを以下の形式を使用してヘッドエンドサーバ１４０に転送する。
＃ ＨＴＴＰ ＰＵＴ ｒｅｑｕｅｓｔ ｔｏ ／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ａｄｄｒｅｓｓｅｄ＿ｍｅｓｓａｇｅｓ

＃ ＨＴＴＰ ｈｅａｄｅｒ
Ｃｏｎｔｅｎｔ ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｔｅｃｈｎｉｃｏｌｏｒ．ｃ３＿ｅｂｉｆ．ｒｅｑｕｅｓｔ．ｖｌ
ｘ−ｃ３−ｅｂｉｆ−ｓｔｂ−ｉｄｅｎｔｉｆｉｅｒ： ００−Ｂ０−Ｄ０−８６−ＢＢ−Ｆ８

＃ Ｍｅｓｓａｇｅ ｂｏｄｙ
［［０ｘ００ ０ｘ０１ ０ｘ００ ＯｘＯＣ
０ｘ７Ｃ ０ｘ７４ ０ｘ６１ ０ｘ６２
０ｘ５８ ０ｘ５９ ０ｘ５Ａ ０ｘ７Ｃ
０ｘ３４ ０ｘ７Ｃ ０ｘ３５ ０ｘ７Ｃ］］

＃ Ｅｘｐｌａｎａｔａｔｏｒｙ ｂｒｅａｋｄｏｗｎ ｏｆ ｔｈｅ ｍｅｓｓａｇｅ ｂｏｄｙ
＃ ［［０ｘ００ ０ｘ０１］］ − ｔｒｉｇｇｅｒ ｗｏｒｄ
＃ ［［０ｘ００ ０ｘ０Ｃ］］ − ｍｓｇ ｌｅｎｇｔｈ ｗｏｒｄ
＃ “｜ｔａｂＸＹＺ” − ｓｏｕｒｃｅ ｄｅｖｉｃｅ ＩＤ
＃ “｜４” − ｍｅｓｓａｇｅ ｔｙｐｅ
＃ “｜５” − ａｒｇ． ｔｏ ｍｓｇ −− ｖｉｒｔｕａｌ ｃｈａｎｎｅｌ ｎｕｍｂｅｒ
＃ “｜” − ｔｅｒｍｉｎａｔｉｎｇ ｐｉｐｅ ｃｈａｒ

＃ ＨＴＴＰ ２００ ｒｅｓｐｏｎｓｅ
ステップ２１５にて、ヘッドエンドサーバ１４０はパイプ区切り形式のコマンドメッセージを受信装置１１０に転送する。ヘッドエンドサーバ１４０は、以下の形式のメッセージに記述される対象の受信装置のＭＡＣアドレスを解決する。
＃ Ｓｅｎｄ ｖｉａ ＥＢＩＦ ｔｏ ＳＴＢ ｋｎｏｗｎ ｂｙ ＭＡＣ ａｄｄｒｅｓｓ ００−０Ｂ−Ｄ０−８６−ＢＢ−Ｆ８

＃ Ｍｅｓｓａｇｅ ｂｏｄｙ
［［０ｘ００ ０ｘ０１ ０ｘ００ ＯｘＯＣ
０ｘ７Ｃ ０ｘ７４ ０ｘ６１ ０ｘ６２
０ｘ５８ ０ｘ５９ ０ｘ５Ａ ０ｘ７Ｃ
０ｘ３４ ０ｘ７Ｃ ０ｘ３５ ０ｘ７Ｃ］］

＃ Ｅｘｐｌａｎａｔａｔｏｒｙ ｂｒｅａｋｄｏｗｎ ｏｆ ｔｈｅ ｍｅｓｓａｇｅ ｂｏｄｙ
＃ ［［０ｘ００ ０ｘ０１］］ − ｔｒｉｇｇｅｒ ｗｏｒｄ
＃ ［［０ｘ００ ＯｘＯＣ］］ − ｍｓｇ ｌｅｎｇｔｈ ｗｏｒｄ
＃ “｜ｔａｂＸＹＺ” − ｓｏｕｒｃｅ ｄｅｖｉｃｅ ＩＤ
＃ “｜４” − ｍｅｓｓａｇｅ ｔｙｐｅ
＃ “｜５” − ａｒｇ． ｔｏ ｍｓｇ −− ｖｉｒｔｕａｌ ｃｈａｎｎｅｌ ｎｕｍｂｅｒ
＃ “Ｉ” − ｔｅｒｍｉｎａｔｉｎｇ ｐｉｐｅ ｃｈａｒ

ステップ２２０にて、受信装置１１０は受信したコマンドを処理する。ある時点の後、ステップ２２５にて、受信装置１１０がコマンドをヘッドエンドサーバ１４０にＨＴＴＰリクエストを介して送信し、それにおいてメッセージの内容はｎａｍｅ／ｖａｌｕｅ ｐａｉｒの一部としてエンコードされる。選択的に、ヘッドエンドサーバ１４０は、ＸＭＬのバックチャネルを介したメッセージの受信を確認する。受信装置１１０からヘッドエンドサーバ１４０へのメッセージの形式は以下の通り。

＃ ＨＴＴＰ ＰＯＳＴ ｒｅｑｕｅｓｔ ｔｏ ＜ｕｎｄｏｃｕｍｅｎｔｅｄ ｅｎｄｐｏｉｎｔ ＵＲＩ？＞

＃ ＨＴＴＰ ｈｅａｄｅｒ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ｔｅｘｔ／ｗｗｗ−ｕｒｌ−ｆｏｒｍｅｎｃｏｄｅｄ

＃ Ｍｅｓｓａｇｅ ｂｏｄｙ （ｌｉｎｅ ｂｒｅａｋｓ ａｒｅ ｆｏｒ ｄｏｃ ｐｕｒｐｏｓｅｓ ｏｎｌｙ）
＃ ＜ｕｎｄｏｃｕｍｅｎｔｅｄ ｎａｍｅ／ｖａｌｕｅ ｐａｉｒｓ？＞

ステップ２３０にて、ヘッドエンドサーバ１４０は、受信したメッセージをバイナリパイプ区切り形式に変換し、次にこれがアプリケーションサーバ１３０に転送される。変換されたメッセージの形式は以下の通り。

＃ ＨＴＴＰ ＰＵＴ ｒｅｑｕｅｓｔ ｔｏ ／ｃ３＿ｅｂｉｆ／ｓｔｂ＿ｏｒｉｇｉｎａｔｅｄ＿ｍｅｓｓａｇｅｓ

＃ ＨＴＴＰ ｈｅａｄｅｒ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ｔｅｘｔ／ｗｗｗ−ｕｒｌ−ｆｏｒｍｅｎｃｏｄｅｄ
ｘ−ｃ３−ｅｂｉｆ−ｓｔｂ−ｉｄｅｎｔｉｆｉｅｒ： ００−Ｂ０−Ｄ０−８６−ＢＢ−Ｆ８
ｘ−ｃ３−ｅｂｉｆ−ｃｌｉｅｎｔ−ｉｄｅｎｔｉｆｉｅｒ： ｔａｂＸＹＺ

＃ ＜ ｕｎｄｏｃｕｍｅｎｔｅｄ ｎａｍｅ／ｖａｌｕｅ ｐａｉｒｓ？＞

ステップ２３５にて、アプリケーションサーバ１３０は、コマンドレスポンスメッセージに埋め込まれるＩＤを使用して対象の制御装置１０５を解決する。メッセージのコピーが、受信装置１１０のＭＡＣアドレスと共に、制御装置１０５に関連するアプリケーションサーバ１３０内のキューに置かれる。ステップ２４０にて、制御装置１０５は最終的に、アプリケーションサーバ１３０内のキューにあるメッセージを要求するが、そこには他のメッセージを格納することもできる。そのようなメッセージは以下に示すようなＸＭＬドキュメントの形式で配信される。

＃ ＨＴＴＰ ｒｅｓｐｏｎｓｅ ｆｒｏｍ ｒｅｑｕｅｓｔ

＃ ＨＴＴＰ ｈｅａｄｅｒ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ｔｅｘｔ／ｘｍｌ

＃ Ｍｅｓｓａｇｅ ｂｏｄｙ （ｌｉｎｅ ｂｒｅａｋｓ ａｒｅ ｆｏｒ ｄｏｃ ｐｕｒｐｏｓｅｓ ｏｎｌｙ）
＜Ｒｅｓｐｏｎｓｅｓ＞
＜Ｒｅｓｐｏｎｓｅ＞
＜ｓｔｂ＞００−Ｂ０−Ｄ０−８６−ＢＢ−Ｆ８＜／ｓｔｂ＞
＜ｍｅｓｓａｇｅ＞＜！ＣＤＡＴＡ［［
＃＜ｕｎｄｏｃｕｍｅｎｔｅｄ ｎａｍｅ／ｖａｌｕｅ ｐａｉｒｓ？＞
］］！＞＜／ｍｅｓｓａｇｅ＞
＜／Ｒｅｓｐｏｎｓｅ＞
＜／Ｒｅｓｐｏｎｓｅｓ＞

ステップ２４５にて、制御装置１０５は、受信したＸＭＬドキュメントを構文解析し、包含されるメッセージを処理する。

ステップ２５０にて、受信装置１１０は、変更チャネルコマンドが成功したことをヘッドエンドサーバ１４０に通知する。メッセージの内容は、ｎａｍｅ／ｖａｌｕｅ ｐａｉｒの組としてエンコードされる。選択的に、ヘッドエンドサーバ１４０は、ＸＭＬのバックチャネルを介したメッセージの受信を確認する。ステップ２５５では、ヘッドエンドサーバ１４０がメッセージをバイナリパイプ区切り形式に変換し、そのようなメッセージはアプリケーションサーバ１３０に転送される。

ステップ２６０にて、アプリケーションサーバ１３０は意図される制御装置１０５をメッセージの対象として解決し、それにおいてレスポンスメッセージ「ｃｈａｎｎｅｌ ｃｈａｎｇｅｄ」のコピーおよび受信装置１１０のＩＤが送信される。ステップ２６５にて、制御装置１０５は最終的に、アプリケーションサーバ１３０内のメッセージのキューの内容を要求する。

ここで図３を参照すると、フローチャート３００が示されている。フローチャート３００は、２つの装置間で使用されるメッセージスキームを判定することを対象とする。ステップ３０５にて、受信装置１１０は、発見機構を使用して制御装置１０５を同定するプログラムを実行することができ、該発見機構に含まれるものは、ＵＰｎＰ（ｕｎｉｖｅｒｓａｌ ｐｌｕｇ ａｎｄ ｐｌａｙ）、ＨＤＭＩ（登録商標）（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）を介するデバイスルックアップ、制御装置１０５上でサポートされるアプリケーションを判定するアプリケーションを受信装置１１０上で実行すること、リモートサーバから受信される情報、ＩＰアドレスのルックアップ、および他の技術がある。そのような情報から、受信装置は、制御装置１０５が特定のコマンドを発行することを認証され、他のコマンドは制限されるということを判定することができる。例えば、認証されるコマンドは、受信装置１１０が出力する量を増減させるコマンドとすることができる。サポートされないコマンドは、制御装置１１５から受信される場合は記録チャネルまたはＥＰＧ情報コマンドであり得る。

ステップ３０５の選択的部分として、受信装置１１０がサポートされるべきコマンドを認識すると、受信装置１１０は制御装置１０５にこれらの装置がお互いにインターフェースで連通可能な場合にサポートされるコマンドセットを通知する。例えば、サポートされるのであれば、赤外線を使用するＲＦインターフェースが使用可能である一方、図２の通信スキームも使用可能である。

ステップ３１０にて、制御装置１０５は、サポートされるコマンドをコマンドセットの一部として第１の通信インターフェースを介して受信装置１１０に通信する。ステップ３１５にて、制御装置１０５は、第２のコマンドを第２のコマンドセットの一部として第２の通信インターフェースを使用して通信する。本開示に従う、この第２の通信インターフェースの一実施形態が図２に関連して記載されたが、他の実施形態が使用されてよく本開示の範囲内にあるとみなされる。

第１の実施形態において、通信インターフェースは、サーバまたは他の装置が介在することなく制御装置１０５と受信装置１１０とを物理的に連結させる接続である。第２の実施形態において、通信インターフェースは、制御装置１０５と受信装置１１０との間の連結とすることができ、それにおいては、図２に関連して記載されるように本開示に従い、両装置間の通信が他の装置および／またはサーバを介して発生する。

異なるコマンドの例が表Ｉに示され、これらのコマンドは、制御装置１０５から発行されると制御装置１１０の動作に影響を与える。オープンのコマンドは第１の通信インターフェースを通じて伝送可能であり、制限のあるコマンドは第２の通信インターフェースを通じて伝送可能であることに留意されたい。そのような判定は、本開示の実施形態に従い、上記で記述した発見技術に応答して受信装置１１０から受信される情報に応答して行うことが可能である。本開示の別の実施形態において、制御装置１０５は、受信装置１１０をポーリングして、どのコマンドが制限されるかまたはオープンであるかを、そのようなコマンドを伝送する際に使用すべき通信インターフェースを判定する時に、判定することができる。伝送されるコマンドの形式も、そのようなコマンドが制限されるかオープンであるかにより影響を受け得る。例えば、オープンのコマンドはＲＦ信号、ＸＭＬ、テキストなどとすることができる。制限のあるコマンドは、必要に応じて第２の形式に変換可能であるＥＢＩＦ、ＵＰｎＰ、ＨＤＭＩなどの形式とすることができる。

制限のあるコマンドおよびオープンのコマンドの分類は、装置の配置、ソフトウェアのアップグレード、ハードウェアのアップグレードなどによって変更されて良い。すなわち、本原理を用いる実施形態に従い、異なる装置に対する同一のコマンドを、異なって分類することができる。例えば、第１の制御装置１０５が受信装置１１０と通信すると、コマンドは、オープンであるとして分類可能である。第２の制御装置１０５が同じ受信装置１１０と通信すると、同一のコマンドが制限あるものとして分類可能である。

本原理に従う一実施形態において、コマンドが、制御装置１０５から受信装置１１０に発行された際に「制限のある」コマンドであると判定される場合、制御装置１０５には、発行されたコマンドが成功裏に受信装置１１０に伝送されたかどうかが分からないかもしれない。従って、コマンドがいつ受信装置１１０に所望の操作を実行させたのかを示すためにアプリケーションサーバ１３０などの介在する装置を使用することができる。すなわち、受信装置１１０は、ヘッドエンドサーバ１４０を介してアプリケーションサーバ１３０に、所望の操作が成功したことを示すメッセージを発行することができる。本原理に従う一実施形態において、受信装置１１０がそのようなメッセージを発行するのは、装置が、受信装置１１０が応答したコマンドをどの装置が最初に発行したのかについて知らない場合である。本原理に従う別の実施形態において、受信装置１１０が、受信したコマンドが成功したことを発行するのは、制御装置１０５がコマンドを発行したが、そのコマンドが制限のあるコマンドであって、オープンのコマンドではないということを受信装置が認識するときである。

本開示の一実施形態において、第１の実施形態と第２の実施形態とを混合して採用することが可能である。図面で示した要素がハードウェア、ソフトウェア、またはその組み合わせの様々な形式で実装可能であることは理解すべきである。好ましくは、これらの要素は、１つまたは複数の適切にプログラムされた汎用の装置上でハードウェアとソフトウェアとの組み合わせにおいて実装され、これにはプロセッサ、メモリ、および入／出力インターフェースが含まれてよい。

本説明では本開示の原理が例示されている。従って、本開示の原理を具現化しその範囲に含まれる種々の配置構成は、本明細書に明示的に記載も表示もされないが、当業者が考案可能であること理解されたい。

本明細書において列挙される全ての例および条件付き言語は、情報提供を目的として、本開示の原理および本発明者により技術の促進のために提供される概念を、読者が理解する助けとなることが意図され、そのような具体的に列挙される例および条件に制限されることはないと解釈されるべきである。

さらに、本開示の原理、態様、および実施形態を列挙する本明細書における全ての記述のみならずその具体例も、構造上および機能上両方の等価物を包含することが意図される。加えて、そのような等価物には、現在既知である等価物のみならず将来開発される等価物、すなわち、構造にかかわらず同じ機能を実行する任意の開発される要素が含まれることが意図される。

従って、例えば、本明細書において提示されるブロック図が、本開示の原理を具現化する例示的な回路の概念図を表すことを当業者は理解するであろう。同様に、任意のフローチャート、フロー図、状態遷移図、疑似コードなどが種々の処理を表し、該処理が実質的にコンピュータ可読媒体内において表され、そのようにコンピュータまたはプロセッサにより実行されるが、そういったコンピュータまたはプロセッサが明示的に示されているかどうかに係わらない、ということを理解されるであろう。コンピュータ可読媒体および記述されるコードは、一時的な状態（信号）および非一時的な状態（例えば、ＣＤ−ＲＯＭ、ＤＶＤ、ブルーレイ、ハードドライブ、フラッシュカード、または他のタイプの有形の記憶媒体等の有形の媒体上において）において実装可能である。

図面に示される種々の要素の機能は、専用のハードウェアのみならず、適切なソフトウェアに関連してソフトウェアを実行可能なハードウェアを使用することにより提供されてよい。プロセッサにより提供される場合、機能は、単一の専用プロセッサ、単一の共有プロセッサ、または複数の個別のプロセッサにより提供されてよく、これらプロセッサはいくつかが共有されてもよい。さらに、用語「プロセッサ」または「コントローラ」を明示的に使用することは、ソフトウェアを実行可能なハードウェアに排他的に言及することである解釈されるべきでなく、また、「ＤＳＰ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）」ハードウェア、ソフトウェアを記憶するための「ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）」、「ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）」、および不揮発性記憶装置が暗黙的に含まれてよいがこれらに限定されない。

他のハードウェアが、従来のものおよび／または特別のものも、含まれて良い。同様に、図面に示される任意のスイッチは単に概念的なものである。その機能は、プログラム論理の演算、専用論理、プログラム制御と専用ロジックとの相互作用を介して、または手動でも実行することができ、文脈からより具体的に理解されるように、実装者により特別な技術が選択可能である。

本開示の教示を組み込む実施形態が本明細書において示され詳細に記載されたが、当業者は、これらの教示をさらに組み込む多くの他の変形実施形態を容易に考案可能である。上記の教示に照らして修正および変形が当業者により行われることが可能であることに留意されたい。
＜付記１＞
装置間でコマンドを通信する方法であって、
第１のインターフェースおよび第２のインターフェースを介して装置に少なくとも１つのコマンドを伝送するかどうかを、前記装置から受信される情報に応答して判定するステップ、
を含む、前記方法。
＜付記２＞
前記判定するステップは、送信されることとなる少なくとも１つのコマンドに応答して、オープン・コマンドまたは制限されたコマンドとして判定されることをさらに含む、付記１に記載の方法。
＜付記３＞
前記少なくとも１つのコマンドがオープン・コマンドであると判定される場合に、前記少なくとも１つのコマンドを前記第１のインターフェースを通じて前記装置に伝送するステップ、
をさらに含む、付記２に記載の方法。
＜付記４＞
前記少なくとも１つのコマンドが制限されたコマンドであると判定される場合に、前記少なくとも１つのコマンドを前記第２のインターフェースを通じて前記装置に伝送するステップ、
をさらに含む、付記２に記載の方法。
＜付記５＞
前記伝送するステップは、前記少なくとも１つのコマンドを第１の形式でサーバに伝送し、前記コマンドは、前記サーバにより前記装置への伝送のために第２の形式に変換される、付記４に記載の方法。
＜付記６＞
前記第１の形式はＲｅｓｔ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）形式であり、第２の形式はＥｎｈａｎｃｅｄ ＴＶ Ｂｉｎａｒｙ Ｉｎｔｅｒｅｘｃｈａｎｇｅ Ｆｏｒｍａｔ（ＥＢＩＦ）形式である、付記５に記載の方法。
＜付記７＞
前記第２の少なくとも１つのコマンドが前記少なくとも１つのコマンドを伝送した装置に伝送されている時に、前記サーバが、前記第２の形式から第１の形式に前記装置から受信される第２の少なくとも１つのコマンドを変換する、付記５に記載の方法。
＜付記８＞
前記第１のインターフェースは、制御装置と前記装置との間で直接的に接続される物理リンクであり、前記第２のインターフェースは、第１の形式から第２の形式へ前記少なくとも１つのコマンドの変換を実行する介在するサーバによりネットワークを介する、付記１に記載の方法。
＜付記９＞
装置間でコマンドを通信するシステムであって、
第１の通信媒体を通じて第２の装置に第１のコマンドを伝送する第１の装置であって、前記第１の装置は第２の通信媒体を通じて前記第２の装置に第２のコマンドを伝送し、前記通信媒体は前記第１のコマンドおよび前記第２のコマンドがオープンであるか制限されたものであるかに依拠して選択される、前記第１の装置と、
前記第２の通信媒体を介して前記第１の装置と前記第２の装置との間に介在するサーバであって、前記サーバは、変換されたコマンドを前記第２の装置に転送する前に、前記第１の装置から受信される前記第２のコマンドを、第１の形式から第２の形式に変換する、前記サーバと、
を備える、前記システム。
＜付記１０＞
コマンドを伝送する装置であって、
コマンドを装置に、第１のインターフェースを介して伝送すべきか、または第２のインターフェースを介して伝送すべきかを、前記コマンドの属性によって判定する手段と、
前記コマンドを第１のインターフェースを通じて伝送する手段と、
前記コマンドを第２のインターフェースを通じて伝送する手段と
を備える、前記装置。
＜付記１１＞
前記コマンドの前記属性が、オープン・コマンドまたは制限的なコマンドのいずれかである、付記１０に記載の装置。

Claims (8)

1. 制御装置と受信装置との間でコマンドを通信する方法であって、
   前記制御装置において、サポートされるコマンドセットを受信することと、
   前記制御装置において、少なくとも１つのコマンドを受信することと、
   前記少なくとも１つのコマンドが前記サポートされるコマンドセットに含まれるかを判定することと、
   前記少なくとも１つのコマンドを第１の通信インターフェースまたは第２の通信インターフェースを介して前記受信装置に伝送するかを判定することであって、前記第２の通信インターフェースは、サーバを含み、前記第１の通信インターフェースは、直接的に接続された無線リンクを含み、前記サポートされるコマンドセットは、前記第１の通信インターフェースを介して伝送される、こととを含み、
   前記第１または第２の通信インターフェースのいずれを介して伝送されるかの判定において、前記少なくとも１つのコマンドが前記サポートされるコマンドセットに含まれる場合、前記少なくとも１つのコマンドが前記第１の通信インターフェースを介して伝送され、前記少なくとも１つのコマンドが前記サポートされるコマンドセットに含まれない場合、前記少なくとも１つのコマンドが前記第２の通信インターフェースを介して伝送される、前記方法。
2. 前記少なくとも１つのコマンドは、第１の形式で前記サーバに伝送され、前記コマンドは、前記受信装置への伝送のために、前記サーバによって第２の形式に変換される、請求項１に記載の方法。
3. 前記第１の形式はＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）形式であり、第２の形式はＥｎｈａｎｃｅｄ ＴＶ Ｂｉｎａｒｙ Ｉｎｔｅｒｅｘｃｈａｎｇｅ Ｆｏｒｍａｔ（ＥＢＩＦ）形式である、請求項２に記載の方法。
4. 前記少なくとも１つのコマンドを伝送した前記制御装置に第２の少なくとも１つのコマンドが伝送されようとするときに、前記サーバが、前記受信装置から受信された前記第２の少なくとも１つのコマンドを前記第２の形式から第１の形式に変換する、請求項２に記載の方法。
5. 制御装置と受信装置との間でコマンドを通信するシステムであって、
   前記システムは、前記制御装置と前記受信装置とを備え、
   前記制御装置は、
   サポートされるコマンドセットを受信し、
   少なくとも１つのコマンドを受信し、
   前記少なくとも１つのコマンドが前記サポートされるコマンドセットに含まれるかを判定し、
   前記少なくとも１つのコマンドを第１の通信インターフェースまたは第２の通信インターフェースを介して前記受信装置に伝送するかを判定し、前記第２の通信インターフェースは、サーバを含み、前記第１の通信インターフェースは、直接的に接続された無線リンクを含み、前記サポートされるコマンドセットは、前記第１の通信インターフェースを介して伝送され、
   前記第１または第２の通信インターフェースのいずれを介して伝送されるかの判定において、前記少なくとも１つのコマンドが前記サポートされるコマンドセットに含まれる場合、前記少なくとも１つのコマンドが前記第１の通信インターフェースを介して伝送され、前記少なくとも１つのコマンドが前記サポートされるコマンドセットに含まれない場合、前記少なくとも１つのコマンドが前記第２の通信インターフェースを介して伝送される、前記システム。
6. 前記少なくとも１つのコマンドは、第１の形式で前記サーバに伝送され、前記コマンドは、前記受信装置への伝送のために、前記サーバによって第２の形式に変換される、請求項５に記載のシステム。
7. 前記第１の形式はＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）形式であり、第２の形式はＥｎｈａｎｃｅｄ ＴＶ Ｂｉｎａｒｙ Ｉｎｔｅｒｅｘｃｈａｎｇｅ Ｆｏｒｍａｔ（ＥＢＩＦ）形式である、請求項６に記載のシステム。
8. 前記少なくとも１つのコマンドを伝送した前記制御装置に第２の少なくとも１つのコマンドが伝送されようとするときに、前記サーバが、前記受信装置から受信された前記第２の少なくとも１つのコマンドを前記第２の形式から第１の形式に変換する、請求項６に記載のシステム。

Images