JP2014010842A - アプリケーションを発見する方法 - Google Patents

Abstract

【課題】家庭用電子機器とスマートフォンなどの間で、ＡＶ用エンターテイメントをシームレスに楽しめるようにする。
【解決手段】 スマートフォンなどの第２のスクリーン装置１１０が、ローカルネットワーク１１４を検索して第１のスクリーン装置１０２上のディスカバリーサーバー１０６の存在を探す。ディスカバリーサーバー１０６は、第１のスクリーン装置１０２と第２のスクリーン装置１１０間の通信をアシストして、特定のアプリケーション１０４が第１のスクリーン装置１０２上で起動されるようにし、第２のスクリーン装置上１１０のローカルなアプリケーションから制御できるようにする。
【選択図】図１Ａ

Description

関連出願の相互参照

この出願は、２０１２年７月２５日に出願された米国仮出願第６１/６７５,７５６号および２０１２年６月２８日に出願された米国仮出願第６１/６６５,８２７号は、ここで十分に説明されたものとして全てについて参照され援用される。

本開示は、一般的なネットワーク内のコンピュータープログラムアプリケーションの存在を発見する手法に関する。本開示は、より具体的には、第１のスクリーンオーディオビジュアル（ＡＶ）装置および第２のスクリーン付きコンピューター装置の調整に便利なアプリケーションの発見技術に関する。

このセクションで説明された手法は、追行されることが可能な手法であるが、必ずしも以前に考案され追行された手法を必要とするものではない。したがって、特に指摘がない限り、単にこのセクションに含まれることで、このセクションで説明された手法のいずれかを先行技術として認めるものではない。

家庭環境や商業環境におけるビデオベースのエンターテイメントシステムには、テレビ、デジタルビデオレコーダー、ディスクプレーヤー、および、ケーブル放送や衛星放送のシステムと互換性があるセットトップボックスなど、様々なプライマリ表示システムがある。このようなプライマリ表示システムは、多くはエンターテイメントや他の機能に関するアプリケーションプログラムの提供が可能な専用のコンピューターを備え、通常、大型スクリーン表示装置または表示ユニット上でプログラムを駆動または表示を行うことが可能である。同じ環境で、他の専用のコンピューター装置と、スマートフォン、タブレットコンピューター、ラップトップコンピューター、ネットブックコンピューター、他のコンピューターやワークステーションなどの汎用のコンピューター装置が、使用されるのは当たり前である。しかし、ＳＳＤＰやＢｏｎｊｏｕｒ／ｍＤＮＳなどのローカルネットワーク上の装置を発見するための特定のプロトコルが有効になっているときに、現在の技術では、コンピューター装置で提供されるアプリケーションが、プライマリ表示システム上で実行しているアプリケーションを特定し、アプリケーションからデータを取得し、アプリケーションと連携して操作を行うのは困難であるとされてきた。他の例では、ローカルネットワーク上のラップトップコンピューターが、プライマリ表示システムにおいて、プライマリ表示システムで提供される個別のエンターテイメント向けのコンピュータープログラムアプリケーションを特定して起動する方法もないかもしれない。そのため、従来、プライマリ表示システムが提供しているアプリケーションを特定し、起動し、利用して、シャットダウンするためには、通常はユーザーがプライマリ表示システムと直接やり取りを行わなければならなかった。

様々な実施形態に組み込まれて利用されるコンピューター システムのアーキテクチャの図を示す。 一実施形態におけるディスカバリーアプリケーションの方法を示す図を示す。 ＤＩＡＬサービスディスカバリー部の１つの実装方法を示すメッセージシーケンスの図である。 Ｍ−ＳＥＡＲＣＨ要求の一例である。 Ｍ−ＳＥＡＲＣＨ応答の一例である。 装置記述要求の一例である。 装置記述応答の一例である。 アプリケーションを起動するメッセージシーケンスの図である。 アプリケーション起動要求の一例である。 アプリケーション起動応答の一例である。 アプリケーション情報要求を示す。 アプリケーション情報応答に対するＸＭＬを示す。 アプリケーション情報応答を示す。 一実施形態に組み込まれるコンピューターシステムを示す。

以下、本発明の完全な理解を提供するために、多数の特定の詳細について説明することを目的とする。しかし、本発明は、これら実施形態でなくとも実施できることは明らかである。他の例では、不必要に本発明が不明瞭になることを避けるために、よく知られている構造と装置をブロック図の形式で示す。

１．０ 技術的な導入
一実施形態では、第２のスクリーンアプリケーションが第１のスクリーン装置上の第１のスクリーンアプリケーションを発見し起動することを可能にする方法または通信プロトコルを開示する。この開示の１つの最終目的は、家庭用電子機器の所有者が、オーディオビジュアル（ＡＶ）指向のエンターテイメントを体験する一部として、スマートフォンやタブレットコンピューターのアプリケーションを統合してシームレスに楽しめるようにすることである。

１．１ 技術
この開示では、以下の用語は以下の意味を持つ。

第１のスクリーン：テレビ、ディスクプレーヤー、セットトップボックス、ゲームコンソール、デジタルビデオレコーダー、または、主に演奏やオーディオビジュアル（ＡＶ）番組の画像表示を行うことが可能な同様の装置である。第１のスクリーン装置は、多くの場合、ユーザー環境に置かれたプライマリ表示システムである。

第２のスクリーン：スマートフォン、タブレットコンピューター、ラップトップコンピューター、ネットブックコンピューター、または、他の個人用のコンピューター装置である。第２のスクリーン装置は、多くの場合、セカンダリー表示システムであるが、多くの場合、第１のスクリーン装置より高性能あるいは汎用性の高い計算性能と入力機能を備えている。

ディスカバリーサーバー：ここで説明するプロトコルのサーバー側の機能が提供、実行、または、実装されるコンピューター装置である。一実施形態では、ディスカバリーサーバーは、第１のスクリーン装置である。

ディスカバリークライアント：ディスカバリーサーバーに置かれる、または、ディスカバリーサーバーが提供するコンピュータープログラムアプリケーションを発見して起動要求を行うことが可能なコンピューター装置である。一実施形態では、ディスカバリークライアントは第２のスクリーン装置である。

具体的な例を示すために、本開示のいくつかのセクションでは、Ｎｅｔｆｌｉｘ（登録商標）、ＹｏｕＴｕｂｅ（登録商標）などの商用のサービスについて説明し、ｉＰｈｏｎｅ（登録商標）、スマートフォン、および、Ａｎｄｒｏｉｄ（登録商標）ベースのタブレット型コンピューターなどの市販のコンピューター装置について説明する。しかし、開示された特定のサービスや装置は単なる例であり、他の実施形態では、コンピューター装置やアプリケーションの他の形態が組み込まれてもよい。

２．０ システムアーキテクチャー
図１Ａに、様々な形態の実施に用いられるコンピューターシステムの構造を示す。一実施形態において、第１のスクリーン装置１０２と第２のスクリーン付きコンピューター装置１１０は、ローカルネットワーク１１４に接続される。例えば、第１のスクリーン装置１０２は、プロセッサが搭載されたテレビ、セットトップボックス、ゲームコンソール、デジタルビデオレコーダー、ディスクプレーヤー、または、ビデオディスプレイ１０８が装備または駆動できる家庭用電化製品などの他の構成要素であってもよい。第１のスクリーン装置１０２には、第１のスクリーン用アプリケーション１０４とディスカバリーサーバー１０６が設けられ、実行される。様々な実施形態において、任意の数の第１のスクリーン用アプリケーション１０４をサポートすることが可能であるが、説明を明確にするために、図１Ａでは単に、第１のスクリーン用アプリケーションが１つだけ設けられた様子を示す。第１のスクリーン用アプリケーションの例として、「Ｎｅｔｆｌｉｘ」と互換性があるプレーヤーなどのビデオプレーヤーがある。

ディスカバリーサーバー１０６は、１以上のコンピュータプログラムで構成され、このコンピュータプログラムには、ここでさらに説明するように、第１のスクリーン装置内に互換性があるアプリケーションを発見するために、ディスカバリークライアント１１２からの要求に対して、応答および処理を行う機能を備える。一実施形態では、ディスカバリーサーバー１０６には、ここでさらに説明する機能を実行するように、ＤＩＡＬサービスディスカバリー部１０６ＡおよびＤＩＡＬ ＲＥＳＴサービス部１０６Ｂが設けられる。ここでは、ＤＩＡＬは、発見（Discovery）および起動（Launch）に関し、図１Ａに示す、いくつかの運用可能なユニットの一般的な機能を指すものとする。

一般的に、ＤＩＡＬサービスディスカバリー部１０６Ａは、ディスカバリーサーバー１０６を発見するためのディスカバリークライアント１１２の要求に応答し、ＤＩＡＬ ＲＥＳＴサービス部１０６Ｂは、ディスカバリークライアント１１２のアプリケーションの起動要求と第１のスクリーン装置１０２のアプリケーション管理部との間のインターフェイスとしても機能する。一実施形態では、第１のスクリーン装置１０２は、さらに、ユニバーサルプラグアンドプレイ(ＵＰｎＰ)サーバー１０７、または、代わりにＨＴＴＰサーバーを備え、第１のスクリーン装置１０２が提供する第１のスクリーン用アプリケーション１０４および他のアプリケーションに関する情報へのアクセスを提供するように構成される。一実施形態において、ＵＰｎＰサーバー１０７は、利用可能なＵＰｎＰサービスのリストを含む第１のスクリーン装置１０２のメタデータで表された装置記述１０９を用いて、この開示の範囲外の手法を通して設定される。例えば、装置記述１０９には、第１のスクリーン装置１０２に対して「Ｓｍａｒｔ ＨＤＴＶ ＸＹＺ―９００」という名称を規定する「ｆｒｉｅｎｄｌｙ Ｎａｍｅ」フィールドが含まれるようにしてもよい。さらに、装置記述１０９で、「Ａｐｐｌｉｃａｔｉｏｎ−ＵＲＬ」ヘッダーフィールドがＨＴＴＰの要求に対応するＨＴＴＰの応答を提供するようにしてもよい。このＡｐｐｌｉｃａｔｉｏｎ−ＵＲＬが、ディスカバリーサーバー１０６のＤＩＡＬ ＲＥＳＴサービス部１０６Ｂを指すようにしてもよい。このＡｐｐｌｉｃａｔｉｏｎ−ＵＲＬに、注目している特定のアプリケーション名を続けることによって、第２のスクリーン付きコンピューター装置１１０などのＵＰｎＰクライアント装置が、クエリを実行し、第１のスクリーン用アプリケーション１０４と０個以上の第１のスクリーン装置１０２が提供している他のアプリケーションを制御することができる。ネーミングの一貫性を保つために、ＵＰｎＰクライアントは、後述のセクション７.０で記載されるように、ＤＩＡＬレジストリ内に登録された明確に定義されたアプリケーション名（Ａｐｐｌｉｃａｔｉｏｎ Ｎａｍｅ）を利用するようにしてもよい。アプリケーションＵＲＬを介してアクセスできるアプリケーションは、装置記述１０９で規定されたＵＰｎＰサービスの一覧から分けられて区別されることに注意すべきである。

第２のスクリーン付きコンピューター装置１１０は、スマートフォン、タブレットコンピューター、ラップトップコンピューター、ネットブックコンピューターや他のコンピューターのいずれか、または、ワークステーションで構成される。第２のスクリーン付きコンピューター装置１１０は、ディスカバリークライアント１１２と第２のスクリーン用アプリ１１３を提供または実行する。第１のスクリーン装置１０２、または、ローカルネットワーク１１４に接続されているビデオ向けまたはエンターテイメント向けの他の装置を発見するために、ディスカバリークライアント１１２は、さらにここに記載するディスカバリー要求を開始するための機能を備えている。第１のスクリーン用アプリケーション１０４から恩恵を受けることが可能な、あるいは、スクリーン用アプリケーション１０４から提供されたデータまたはスクリーン用アプリケーション１０４へ提供するデータを用いることが可能な、あらゆる種類の実行可能なアプリケーションで、第２のスクリーン用アプリ１１３を構成するようにしてもよい。例えば、第２のスクリーン用アプリ１１３が、テレビ番組のスケジュール、メディアのファイル管理、および、インターネットサーバー上で提供されるアプリケーションへアクセスするためのイターネットブラウザーのうち少なくとも１つを、提供するようにしてもよい。

ローカルネットワーク１１４は、複数の有線ネットワークリンク、無線ネットワークルーター、またはネットワークインフラなどの他の要素で構成される。一実施形態においては、ローカルネットワーク１１４は、ケーブルモデム、ＤＳＬモデム、または、公衆通信回線１１８や相互接続ネットワーク（インターネットとして知られるグローバルな相互接続ネットワークの集まりなど）に接続する他のアクセス装置などのアクセスルーター１１６に接続される。ローカルネットワーク１１４を第１のスクリーン装置１０２と第２のスクリーン付きコンピューター装置１１０に接続するリンクを、有線リンクまたは無線リンクで構成してもよい。例えば、アクセスルーター１１６は、無線ローカルエリアネットワーク(ＷＬＡＮ)ルーターとケーブルモデムの組合せ、ＤＳＬモデム、または他のアクセス装置であってもよく、装置１０２、１１０が、互換性のある無線用ネットワークインターフェイスカードを備えていてもよい。

一実施形態では、ディスカバリーリポジトリ１２０は、ネットワーク１１８に接続され、ディスカバリーサーバー１０６とディスカバリークライアント１１２からネットワークプロトコルを用いてアクセスすることが可能である。一般的に、ディスカバリーリポジトリ１２０は、リレーショナルデータベース、フラットファイルシステム、または、第１のスクリーン用アプリケーション１０４または第２のスクリーン用アプリ１１３で広く利用することが可能な名前が知られた集中的に情報を保持するためのデータ記憶装置で構成される。ディスカバリーリポジトリ１２０の構成および利用について、さらにここで説明する。

図１Ａの破線は、ディスカバリークライアント１１２と図１Ａの他の構成要素間の仮想通信パスを示している。

３．０ 使用例
様々な実施形態において、このセクションで説明する一般的な手法で第２のスクリーン装置と第１のスクリーン用アプリケーション間の通信を確立するために、異なる手法が組み込まれるようにしてもよい。

図１Ｂに、一実施形態における、アプリケーションを発見する方法を示す。ブロック１３０で、第２のスクリーン装置で実行しているディスカバリーサービスクライアントは、第２のスクリーン装置と１つ以上の第１のスクリーン装置の双方に接続されるローカルネットワークに対してディスカバリー要求を開始する。ディスカバリー要求で、マルチスクリーンサービスを指定すると、リッスン（待ち受け）状態のマルチスクリーン用のエンターテイメント向けサービスをサポートするサーバーが、要求を認識して応答することができる。ブロック１３２で、ディスカバリーサービスクライアントは、第１のスクリーン装置の１つからディスカバリー応答を受信して、第１のスクリーン装置上のディスカバリーサーバーの名前と場所を特定する。第１のスクリーン装置が、ＳＳＤＰまたはＵＰｎＰをサポートしている場合は、第１のスクリーン装置のＳＳＤＰサーバーまたはＵＰｎＰサーバーから応答が来る。他の実施形態では、マルチスクリーンサービスまたは同等のサービスを指定したディスカバリー要求を認識して応答する他のサーバーが、第１のスクリーン装置に実装される。この時点で、第２のスクリーン装置のディスカバリーサービスクライアントは、ネットワーク内に互換性のあるサーバーが存在し、さらに特定のアプリケーションに関するデータを取得するために接続されることが分かっている。さらにここで説明するように、あらゆる技術とプロトコルを用いてディスカバリーサーバーを実装することができる。

ブロック１３４では、ディスカバリーサービスクライアントは、ディスカバリーサーバーに、第１のスクリーン装置で利用可能な１つ以上のアプリケーションの場所と必要であれば名前の情報を要求する。ブロック１３４は、最初にＤＩＡＬ ＲＥＳＴ ＡＰＩを呼び出す位置を特定し、２つのステップの処理を用いてアプリケーションの情報に対するＤＩＡＬ ＲＥＳＴ ＡＰＩを問い合わせるようにしてもよい。例えば、ディスカバリーサービスクライアントはディスカバリーサーバーのＵＰｎＰ装置記述を得るためにＨＴＴＰ要求を最初に送信する。ＨＴＴＰ応答には、ＵＰｎＰ装置記述が含まれ、また、ＤＩＡＬ ＲＥＳＴ ＡＰＩを指しているＡｐｐｌｉｃａｔｉｏｎ−ＵＲＬヘッダーフィールドも含まれている。次に、Ａｐｐｌｉｃａｔｉｏｎ−ＵＲＬは、既知のインストールされているアプリケーションの名前および／または場所の情報を問い合わせるために用いられ、構造化されたドキュメントまたは別の応答の形態で構成される。いくつかの実施形態において、ディスカバリーサービスクライアントには、インストールされている可能性があるアプリケーションの名前があらかじめ設定され、インストールされている特定の名前のアプリケーションに関する情報を返すようにディスカバリーサーバーに要求する。したがって、ディスカバリーサービスクライアントは、例えば、特定のアプリケーション名とＡｐｐｌｉｃａｔｉｏｎ−ＵＲＬを繋げて、ディスカバリーサーバーに問い合わせることによって、第１のスクリーン装置に特定のアプリケーションがインストールされているか否かを決定することができる。特定の実施形態では、ディスカバリーサービスクライアントは、ブロック１３６の処理の後に戻ってきたアクションによって、特定のアプリケーションがインストールされているか否かを決定することができるので、ブロック１３４は必要に応じて省略するようにしてもよい。

ブロック１３６で、ディスカバリーサービスクライアントは、必要に応じて、１つ以上の指定されたパラメーター値を用いて、ディスカバリーサーバーに第１のスクリーン装置上の指定されたアプリケーションの起動を要求する。それに応じて、ディスカバリーサーバーは、オペレーティングシステムのアプリケーションマネージャーや、指定されたアプリケーションを起動させる第１のスクリーン装置上の他の機能とやり取り（インタラクション）を行うようにしてもよい。この手法では、ディスカバリーサービスクライアントは、第１のスクリーン装置上でアプリケーションを直接呼び出したり、起動させたりするように機能する情報やコードを用いて構成することは要求されない。その結果、第１のスクリーン装置は、ディスカバリーサービスクライアントあるいは第２のスクリーン装置が特別な構成でなくても、第２のスクリーン用アプリがなくても、アプリケーションを管理するために、プロセッサ、オペレーティングシステム、または他のプラットフォームの任意の組合せを用いるようにし、さらに、第２のスクリーン装置で、最終的に第１のスクリーン装置上のアプリケーションの起動または呼び出しが可能になるようにする。

さらに、表１を用いて後述するように、起動要求に応じて様々なアクションが発生する。たとえば、起動要求により「４０４ Ｎｏｔ Ｆｏｕｎｄ」のアクションが発生した場合、ディスカバリーサービスクライアントは、特定のアプリケーションがインストールされていないと判定する可能性がある。

ブロック１３８では、ディスカバリーサービスクライアントが、第２のスクリーン装置上で実行または提供されるローカルのアプリに第１のスクリーン用アプリケーションを識別するデータを提供する。ブロック１４０では、第１のスクリーン用アプリケーションと第２のスクリーン用アプリで通信を行い、ローカルネットワークを介して直接やり取りを行う。そのような通信が、ＵＲＬ、または、さらにここで記載するように、第１のスクリーン装置上で提供される中間サービスを介して第１のスクリーン用アプリケーションに渡すことが可能な他の構造化識別子を通じて行なわれるように、ディスカバリークライアントを構成するようにしてもよい。この結果、第２のスクリーン用アプリは、第１のスクリーンアプリケーションと効率的に通信を行うことが可能になり、操作を連携し、データを共有し、機能または実行の管理を行う。

様々な実施形態において、図１Ｂの一般的な方法は、以下に例示する手法において、第１のスクリーンサービス、第２のスクリーンサービスまたはクラウドベースのサービスとして実施してもよい。

３．１ 第１のスクリーンサービス
一実施形態では、「ｉＰｈｏｎｅ」のスマートフォンで実行されている「Ｎｅｔｆｌｉｘ」のアプリケーションは、「Ｎｅｔｆｌｉｘ」対応のテレビを発見すると、ユーザーが映画を鑑賞できるように、テレビ上で「Ｎｅｔｆｌｉｘ」アプリを起動する。ここでは、「「Ｎｅｔｆｌｉｘ」対応テレビ」は、「Ｎｅｔｆｌｉｘ」アプリが既にインストールされているコンピューター機能を備えたテレビ表示装置をいう。このような実施形態は、次の一般的な処理で構成することができる。

（ａ）「ｉＰｈｏｎｅ」上の「Ｎｅｔｆｌｉｘ」アプリが、ネットワークテレビ上でディスカバリーサービスを発見する。

（ｂ）「ｉＰｈｏｎｅ」上の「Ｎｅｔｆｌｉｘ」アプリは、ディスカバリーサービスを用いてネットワークテレビを要求して、テレビ上で「Ｎｅｔｆｌｉｘ」アプリを起動する。

（ｃ）「ｉＰｈｏｎｅ」上の「Ｎｅｔｆｌｉｘ」アプリは、テレビ上の「Ｎｅｔｆｌｉｘ」アプリケーションを発見する。

（ｄ）「ｉＰｈｏｎｅ」上の「Ｎｅｔｆｌｉｘ」アプリとテレビ上の「Ｎｅｔｆｌｉｘ」アプリが映画を上映するために通信する。

３．２ 第２のスクリーンサービス
一実施形態では、「Ａｎｄｒｏｉｄ」タブレット上の「ＹｏｕＴｕｂｅ」アプリが「ＹｏｕＴｕｂｅ」対応テレビを発見すると、テレビ上で「ＹｏｕＴｕｂｅ」アプリを起動して、テレビでビデオを再生する。ビデオの終了後は、テレビを元の再生していたテレビ番組に戻す。このような実施形態は、次の一般的な処理で構成することができる。

（ａ）タブレット上の「ＹｏｕＴｕｂｅ」アプリが、ネットワークテレビ上のディスカバリーサービスを発見する。

（ｂ)タブレット上の「ＹｏｕＴｕｂｅ」アプリが、ディスカバリーサービスを用いて、タブレット上の「ＹｏｕＴｕｂｅ」アプリに対応するネットワークアドレス(ＩＰアドレスとポート値など)を渡して、テレビ上で「ＹｏｕＴｕｂｅ」アプリを起動する。

（ｃ）テレビ上の「ＹｏｕＴｕｂｅ」アプリがビデオを上映するためにタブレット上の「ＹｏｕＴｕｂｅ」アプリと通信した後、通常のテレビのユーザーインターフェイスに戻って終了する。

３．３ クラウドベースのサービス
一実施形態では、「Ａｎｄｒｏｉｄ」ベースのスマートフォンのＷｅｂｃａｍＸアプリが、ＷｅｂｃａｍＸ対応のテレビを発見し、ウェブカメラのストリームを表示するために、テレビ上でブラウザベースのＨＴＭＬ５ ＷｅｂｃａｍＸアプリが起動される。この例では、ＷｅｂｃａｍＸアプリケーションは、ここに記載された技術の実施可能性と利用可能性を示すために記載された仮想的な例である。このような実施形態は、次の一般的な処理で構成することができる。

（ａ）スマートフォン上のＷｅｂｃａｍＸアプリがネットワークテレビ上のディスカバリーサービスを発見する。

（ｂ）スマートフォン上のＷｅｂｃａｍＸアプリはディスカバリーサービスを用いて、乱数または擬似乱数に基づいて一意に決められたトークンを渡して、ＷｅｂｃａｍＸアプリケーション用のＵＲＬで始まるＨＴＭＬ５のベースのブラウザの起動をテレビに要求する。

（ｃ）スマートフォン上のＷｅｂｃａｍＸアプリは、サーバーが２つのアプリケーション間のトラフィックが正しくルーティングするように一意に決められたトークンを用いて、クラウドベースのＷｅｂｃａｍＸサーバーを用いたテレビ上でＷｅｂｃａｍＸアプリと通信する。

４．０ 発見方法の例の概要
説明を明確にするために、この開示の特定のセクションでは、ＤＩＡＬなどの簡略表示した特定の用語を用いる。ただし、別の実施形態では、機能的に同等の方法、または別の名前、ラベル、あるいは識別名称を用いる機構を実装するようにしてもよく、ＤＩＡＬなどの用語は、単に例として挙げられる。

一実施形態では、ＤＩＡＬ サービスディスカバリー部１０６ＡとＤＩＡＬ ＲＥＳＴサービス部１０６Ｂを介して、この技術を実施してもよい。ＲＥＳＴは、ここでは、分散システムのソフトウェアアーキテクチャのＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒスタイルを指す。説明を明確にするため、ここではＲＥＳＴサービスを用いて説明するが、別の実施形態では、ＳＯＡＰやＷＳＤＬを用いるようにしてもよい。一実施形態ではＤＩＡＬサービスディスカバリー部が、ローカルネットワークのセグメント上のディスカバリーサーバーを発見して、これらの装置上でＤＩＡＬ ＲＥＳＴサービスへアクセスするために、ディスカバリークライアント装置を有効にする。

一実施形態ではＤＩＡＬ ＲＥＳＴサービスは、ディスカバリークライアントが、ディスカバリーサーバー装置上で提供または実行されているアプリケーションを問い合わせ、起動し、任意に停止することを可能にする。

５．０ ＤＩＡＬサービスディスカバリー
一実施形態では、ＤＩＡＬサービスディスカバリー部１０６Ａは、ＳＳＤＰ（Simple Service Discovery Protocol）で構造化されたメッセージ内で指定された検索対象（Search Target）を用い、ＵＰｎＰ(ユニバーサルプラグアンドプレイ)装置記述のＨＴＴＰ(ハイパーテキスト転送プロトコル)要求に対する応答で指定されたヘッダーを用いるように実装される。ＳＳＤＰプロトコルは、ｕｐｎｐ．ｏｒｇのＨＴＴＰサーバーのフォルダ/sdcps-and-certification/standards/device-architecture-documentsに、この記事を記載した時点において参照可能な状態で、ＵＰｎＰ装置のアーキテクチャ１.１（２００８年１０月１５日）に記載されている。

一実施形態において、Ｒ. Ｆｉｅｌｄｉｎｇ「ハイパーテキスト転送プロトコル ＨＴＴＰ １.１」Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔ （ＲＦＣ） ２６１６、１９９９ 年 ６ 月刊、Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｓｏｃｉｅｔｙ出版、に記載されているように、ＤＩＡＬ ＲＥＳＴサービス部１０６Ｂは、ＨＴＴＰを用いてアクセスされる。一実施形態において、ディスカバリークライアントとディスカバリーサーバーは、ＵＰｎＰプロトコルのセクション２．１の要件をサポートし、特に、ＨＴＴＰ１.０が、通常、常にサポートされ、ＨＴＴＰ１.１もサポートされる可能性がある。

この構成（arrangement）による効果は、できれば第１のスクリーン装置上で既存のＵＰｎＰサーバーをサポートするが、第１のスクリーン装置に必須ではないことである。あるいは、第１のスクリーン装置は、同等の機能を提供するＨＴＴＰサーバーを実装することも可能である。さらに、ここに記載した構成は、新たに標準となりつつあるＷｅｂインタラクション（interaction）と互換性がある規定の通信メカニズムを用いて、ディスカバリークライアント１１２と第２のスクリーン用アプリ１１３によって、第１のスクリーン用アプリケーション１０４の効率的な発見を促進する。

図２は、ＤＩＡＬサービスディスカバリー部の１つの実装方法を示すメッセージの流れを示す図である。図２では、一連のメッセージはＵＰｎＰサーバーとＤＩＡＬクライアント（図１ＡのＵＰｎＰサーバー１０７とディスカバリークライアント１１２のそれぞれに対応する）間でネットワークを介して渡される。

図２のメッセージ（１）は、Ｍ−ＳＥＡＲＣＨ要求であり、図３にその一例を示す。一実施形態において、ディスカバリークライアントが１以上のディスカバリーサーバーを発見するときは、ＵＤＰ経由でＵＰｎＰ装置のアーキテクチャのセクション１．３．２で定義されているＭ−ＳＥＡＲＣＨ要求を、マルチキャストアドレス２３９.２５５.２５５.２５０のＵＤＰポート１９００に送信する。図２のように、第１のスクリーン装置上のＵＰｎＰサーバーに要求が送られ、ＵＰｎＰをサポートするこれらの第１のスクリーン装置でＵＰｎＰサーバーの機能の利用が可能になる。要求には、値「urn:dial-multiscreen-org:service:dial:１」が検索対象（ＳＴ）ヘッダーに含まれる。

別の実施形態では、異なるＳＴ値が用いられてもよく、上記で提供された値の例は重要な意味を持つものではない。上記のマルチキャストアドレスはＩＰｖ４に対するものであり、他の実施形態では、ＩＰｖ６と互換性がある同等のマルチキャストアドレスに基づいて、ＩＰｖ６アドレスに対して同様のプロセスを用いるようにしてもよい。

図２のメッセージ（２）は、Ｍ−ＳＥＡＲＣＨ応答であり、図４に一例を示す。一実施形態では、ＳＳＤＰサーバー、または上記で定義したＳＴヘッダーを含むＭ−ＳＥＡＲＣＨ要求を受信したＵＰｎＰサーバーが、ＵＰｎＰ装置のアーキテクチャのセクション１．３．３．で定義されているように応答する。応答には、ルート装置のＵＰｎＰ記述に対する絶対ＨＴＴＰ ＵＲＬがＬＯＣＡＴＩＯＮヘッダーに含まれる。第１のスクリーン装置で実行されている下位層のサービス記述よりも、第１のスクリーン装置１０２に適用可能な最上位層のＵＰｎＰ記述が戻され、ルート装置が参照される。ＵＲＬのホスト部分を解決してＩＰアドレスに変換する、または、ＵＲＬのホスト部分がＩＰアドレスを含むようにする。応答のＳＴヘッダーには、前述の節で指定されたものと同じ識別子が含まれる。図２に示すように、ＤＩＡＬクライアントによって、メッセージ（２）が受信されると、ＤＩＡＬ対応のテレビを発見する処理が完了する。

図２のメッセージ（３）は、装置記述要求であり、図５に一例を示す。一実施形態では、メッセージ（２）に示されるＭ−ＳＥＡＲＣＨ応答を受信すると、ディスカバリークライアントがＨＴＴＰ ＧＥＴ要求を、Ｍ−ＳＥＡＲＣＨ応答のＬＯＣＡＴＩＯＮヘッダーで受け取ったＵＲＬに送信する。一実施形態では、ＳＳＤＰヘッダーのフィールド名を照合するときは、大文字小文字の区別はしない。

図２のメッセージ（４）は、装置記述応答であり、図６に一例を示す。一実施形態では、装置記述に対するＨＴＴＰ ＧＥＴ要求の受信に応じて、ディスカバリーサーバーは、ＵＰｎＰ装置のアーキテクチャのセクション２で定義されたようにＵＰｎＰ装置記述を構成するＨＴＴＰ応答を返す。さらに、一実施形態では、要求はリダイレクトされない。要求が成功であれば、ＨＴＴＰ応答は、Ａｐｐｌｉｃａｔｉｏｎ−ＵＲＬと表記されたヘッダーフィールドを含み、その値がＤＩＡＬ ＲＥＳＴサービスを特定する絶対ＨＴＴＰ ＵＲＬの値であり、ＤＩＡＬ ＲＥＳＴサービスのＵＲＬとして参照される。ＵＲＬのホストの部分でＩＰアドレスを特定する、または、ＵＲＬのホストの部分を解決してＩＰアドレスに変換する。図２に示すように、一旦、ＤＩＡＬクライアントでメッセージ（４）が受信されると、ＤＩＡＬ ＲＥＳＴサービスを探索する処理が完了する。

一実施形態において、ＡＢＮＦ記法では、アプリケーションＵＲＬヘッダーのフォーマットは:
Application-URL = “Application-URL” “:” absoluteURI
となる。

一実施形態では、さらにここで記載されるように、このような応答を受け取ったディスカバリークライアントは、提供されたＵＲＬを用いてＤＩＡＬ ＲＥＳＴサービスにアクセスする。一実施形態では、ＵＰｎＰで定義された装置記述の「ｆｒｉｅｎｄｌｙＮａｍｅ」フィールドは、ディスカバリークライアント装置のユーザーインターフェイスを表示するために用いられるようにしてもよい。例えば、このような名前が、対話入力でディスカバリーサーバー装置の選択を行うためにユーザーにリストやメニューで提供されてもよい。

前述の手法を用いて、第２スクリーンのクライアントコンピュータは、最初に、第１のスクリーン装置の応答を返したディスカバリーサービスの存在を発見し、次に、第１のスクリーン装置で利用できるアプリケーションを記述した他の情報の位置がわかる。その後、第２スクリーンのクライアントコンピュータは、第１のスクリーン装置の１つ以上のアプリケーションを選択的に起動し、第１のスクリーン装置１０２のアプリケーションマネージャーとインターフェイス接続するＤＩＡＬ ＲＥＳＴサービスの各構成部などを用いて、興味ある機能を実行する。

６．０ ＤＩＡＬ ＲＥＳＴ サービス
６．１ アプリケーションリソース
一実施形態では、ＤＡＩＬ ＲＥＳＴサービス部１０６Ｂは、ＵＲＬによって特定されるリソース（例えば、「Ｎｅｔｆｌｉｘ」または「ＹｏｕＴｕｂｅ」）などのアプリケーションと同時に使用される。特定のアプリケーションに関する操作は、その特定のアプリケーションに対する特定ＵＲＬ （Ａｐｐｌｉｃａｔｉｏｎ Ｒｅｓｏｕｒｃｅ ＵＲＬ と表記される）にＨＴＴＰ要求を送信するようにしてもよい。一例として、ＤＩＡＬ ＲＥＳＴサービス部１０６Ｂについて説明するが、他の実施形態では、ＲＥＳＴの代わりに、ＳＯＡＰ、独自のＴＣＰベースのプロトコル、または、ＸＭＰＰに基づいたインスタントメッセージを送るためのＪａｂｂｅｒ−ｓｔｙｌｅのプロトコルを使用するようにしてもよい。

一実施形態では、アプリケーションリソースのＵＲＬは、アプリケーションＵＲＬとアプリケーション名をつなげることによって形成される。ここでは、プラットフォームとなるアプリケーションマネージャーは、第１のスクリーン装置１０２のあらゆる機能ユニットであり、アプリケーションの起動、フォーク（forking）またはスポーン（spawning）処理、実行機能、あるいは、同様の機能を実行する。アプリケーションマネージャーは第１のスクリーン装置１０２を制御するオペレーティングシステムのユニットやサービスであってもよい。

各アプリケーションのアプリケーション名はアプリケーションプロバイダによって定義される。アプリケーション名は、第７セクションで更に説明されるＤＩＡＬレジストリに登録される。

６．２ アプリケーションの起動
図７はアプリケーションの起動を説明するメッセージの手順を示す図である。図７は、一連のメッセージが、ＤＩＡＬ ＲＥＳＴサービスとＤＩＡＬクライアント（図１ＡのＤＩＡＬ ＲＥＳＴサービス部１０６Ｂとディスカバリークライアント１１２がそれぞれ対応する）間のネットワークを通じて渡される。

アプリケーションの起動要求を送る前に、ＤＩＡＬクライアントは、最初に、メッセージ（１）、または、Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ（アプリケーション情報要求）を送って既存の特定のアプリケーションがインストールされていること確認する。「２００ ＯＫ」というメッセージ（２）をＤＩＡＬ ＲＥＳＴサービスから受信すると、ＤＩＡＬクライアントはメッセージ（３）の送信が可能になる。しかし、別のメッセージ（２）を受信した場合、図１０、図１１Ａ、図１１Ｂ、および表２を用いて後述するように、ＤＩＡＬクライアントは、それに従って応答するようにしてもよい。例えば、特定のアプリケーションがインストール可能であるがインストールされていない場合は、ＤＩＡＬクライアントは、特定のアプリケーションのインストールを開始し、成功したことを検証するようにしてもよい。

一実施形態では、図７のメッセージ（３）に示すように、ディスカバリーサービスのアプリケーションを起動するディスカバリークライアントが、所望のアプリケーションのＡｐｐｌｉｃａｔｉｏｎ Ｒｅｓｏｕｒｃｅ（アプリケーションリソース）ＵＲＬにＨＴＴＰのＰＯＳＴ要求の形式でアプリケーション起動要求を送る。一例が図８に示される。一実施形態では、ここに記載されている方法を用いて、いずれのアプリケーションが利用可能なるかは、ディスカバリーサーバーを組み込む団体（party）の裁量による設定で決まる。様々な実施形態において、ディスカバリーサーバーは、ここに記載された技術を用いて、第１のスクリーン装置上で動く１つ、いくつか、または全てのアプリケーションを起動するために利用できるようしてもよい。ＰＯＳＴ要求のメッセージの本文は空であっても、起動中のアプリケーションに渡される引数の文字列が含まれるようにしてもよい。一実施形態では、ＰＯＳＴ要求のメッセージの本文部が空でなければ、ＭＩＭＥのタイプが「ｔｅｘｔ／ｐｌａｉｎ」であり、キャラクターのエンコードは一般的にＵＴＦ-８で行われ、ＭＩＭＥパラメーター「ｃｈａｒｓｅｔ」を含めることでキャラクターのエンコードが明確に指定される。

様々な実施形態において、様々なプラットフォームやアプリケーションで、引数の文字列がアプリケーションに渡される方法が異なっていてもよい。引数の受け渡しは重大ではない、あるいは、この開示の範囲ではない。引数のフォーマットは起動するアプリケーションに必要な条件に合わせるべきである。例えば、キー値のペア、ＪＳＯＮ、またはＸＭＬが用いられるようにしてもよく、引数のフォーマットを選択することは特別重大ではない。一実施形態では、ディスカバリーサーバーはアプリケーションに引数の文字列を直接渡すようにしてよいが、アプリケーションは安全性のチェックが行われたとは考えていない。従って、アプリケーションは通常それぞれで引数のデータの安全性のチェックを行っている。安全性のセキュリティチェックの例には、キャラクターのエンコードのチェックが含まれる。

有効なＰＯＳＴ要求の受信に応じて、ディスカバリーサーバーはＰＯＳＴ ＵＲＬから最初にアプリケーション名を取得する。ＰＯＳＴ ＵＲＬが無効である、またはアプリケーション名を得る処理を行うことができなければ、ディスカバリーサーバーはＨＴＴＰプロトコル仕様で指定されたＨＴＴＰ応答コードを戻す。

一実施形態では、図７のメッセージ（４）に示すように、ディスカバリーサービスは、ＨＴＴＰ応答の形式でアプリケーション起動応答をディスカバリークライアントに送信し、図８にその一例を示す。ディスカバリーサーバーは、アプリケーション名が認識できないか、メッセージ本文内のコンテンツの長さがディスカバリーサーバーでサポートできる最大サイズを超えているか、現在のアプリケーションの状態がＮｏｔ Ｓｔａｒｔｅｄ（アプリケーションが実行されていない）；Ｓｔａｒｔｉｎｇ（アプリケーションが他のＤＩＡＬ ＲＥＳＴのためにリスタート、または、他の理由によりリスタート中である）；Ｒｕｎｎｉｎｇ（アプリケーションが実行中）；メッセージ本体が空（ｅｍｐｔｙ）であるか等の、要因に応じた複数の応答アクションを実行する。特定の応答アクションは、アプリケーション起動応答に反映される。テーブル１は、一実施形態に組み込まれる応答動作をまとめたものである。

上記の特定されたアクションの後でアプリケーションが実行されると、図７のメッセ−ジ（４）に示すようにディスカバリーサーバーはＨＴＴＰ応答の応答コード「２０１ Ｃｒｅａｔｅｄ」を返信する。この場合、応答ヘッダーには、アプリケーションの実行中のインスタンスを特定する絶対ＵＲＬが含まれ、Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｓｔａｎｃｅ ＵＲＬと表記される。ＵＲＬのホスト部分がＩＰアドレスである、またはＵＲＬのホスト部分を解決してＩＰアドレスに変換され、応答本文はｎｕｌｌである。

他方、例えば、アプリケーションのスタートまたはリスタートを成功させることができないときは、ディスカバリーサーバーはＨＴＴＰ応答のコード「５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ」を返す。様々な実施形態において、アプリケーションが既に実行中に引数が提供され、第１のスクリーン装置で実行中のアプリケーションに対して新たな引数の提供する方法がサポートされていなければ、新しい引数を用いてアプリケーションをリスタートしてもよい。さらに、アプリケーションを実行するために、ホストシステムは、一般的に、フォーク、実行、スポーン、または、同等の機能をブロックしない形態を用いるが、あらゆる直接的なシステムエラーが検出されるとＨＴＴＰ 「５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ」のエラーが返される原因となる。もしエラーとなることなくアプリケーションを実行するシステムコマンドが成功すれば、ここで開示された目的のためにアプリケーションが実行される。したがって、必要に応じて、図７のメッセージ（１）および（２）で行う特定のアプリケーションが既にインストールされているか否かのチェックを省略して、アプリケーション起動応答メッセージ（４）で「４０４ Ｎｏｔ Ｆｏｕｎｄ」や「５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ」を受け取って特定のアプリケーションを利用可能にするように指示してもよい。

Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｓｔａｎｃｅ ＵＲＬは、情報の要求や実行しているアプリケーションのインスタンスを止めるために用いられる場合もある。

６．３ アプリケーションの停止
一実施形態では、ディスカバリーサーバー上で実行しているアプリケーションのインスタンスを止めるためにディスカバリークライアントは、Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｓｔａｎｃｅ ＵＲＬにＨＴＴＰ ＤＥＬＥＴＥ要求を送信する。一実施形態では、アプリケーションインスタンスの停止を許可するために、ディスカバリーサーバーはＨＴＴＰ ＤＥＬＥＴＥ要求を必要に応じてサポートする。ＨＴＴＰ ＤＥＬＥＴＥ要求がサポートされていれば、ＤＥＬＥＴＥ要求の受信に応じて、ディスカバリーサーバーは、最初に要求のＵＲＬが実行されているアプリケーションインスタンスに対応するか否かを判定する。実行されていれば、ディスカバリーサーバーは、ＨＴＴＰ仕様に定義された適切なＨＴＴＰ応答コードの応答を送信する。提供されたＵＲＬが現在実行中のアプリケーションインスタンスに対応していなければ、サーバーは、ＨＴＴＰ応答で応答コード「４０４ Ｎｏｔ Ｆｏｕｎｄ」を返す。

そうでければ、ディスカバリーサーバーはＨＴＴＰ応答で応答コード「２００ ＯＫ」を送信し、実行しているアプリケーションを停止させる。これらの操作は、非同期で実行されるようにしてもよい。

６．４ アプリケーション情報の問い合わせ
一実施形態では、アプリケーションに関する情報を発見したいディスカバリークライアントは、上述のセクション６．１で説明したように、ＨＴＴＰのＧＥＴ要求をＡｐｐｌｉｃａｔｉｏｎ Ｒｅｓｏｕｒｃｅ ＵＲＬへ送信する。図１０に、アプリケーション情報要求（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ）を示す。

一実施形態では、ＧＥＴ要求などの受信に応じて、ディスカバリーサーバーは、最初に要求ＵＲＬからアプリケーション名を抽出する。ＧＥＴ要求が無効またはアプリケーション名の抽出の処理ができないときは、ディスカバリーサーバーは、ＨＴＴＰ仕様に定義されている適切なＨＴＴＰ応答コードを返す。

アプリケーション名が認識できない場合は、ＨＴＴＰ応答で応答コード「４０４ Ｎｏｔ Ｆｏｕｎｄ」を返す。

そうでなければ、ディスカバリーサーバーは、応答コード「２００ ＯＫ」とＨＴＴＰ応答の形式でアプリケーション情報の応答を送信し、図１１Ｂにその一例を示す。応答のＭＩＭＥタイプが「ｔｅｘｔ／ｘｍｌ」であり、キャラクターのエンコードがＵＴＦ-８で行われ、ＭＩＭＥパラメーター「ｃｈａｒｓｅｔ」を用いて指定される。ディスカバリークライアントが、認識されないＸＭＬ要素や属性を無視するように構成された場合を除き、ＸＭＬドキュメントは、図１１Ａに示されるようなスキーマに従う。テーブル２は、一実施形態におけるスキーマの意味をまとめたものである。

６．５ アプリケーションをインストールするトリガー
一実施形態では、ディスカバリーサーバーは、クライアントに現在インストールされていない特定のアプリケーションをアプリケーションインストールするためのトリガーをサポートするようにしてもよい。

一実施形態では、アプリケーション名が認識され、アプリケーションがインストールされておらず、ディスカバリーサーバーがこの特定のアプリケーションをアプリケーションインストールするためのトリガーをサポートしている場合には、ディスカバリーサーバーは、「ｉｎｓｔａｌｌａｂｌｅ＝」の文字列で始まる「状態（state）」要素を返す。要素の残りの部分に絶対ＵＲＬが含まれる。ＵＲＬのホスト部分がＩＰアドレス、またはＵＲＬのホスト部分を解決してＩＰアドレスに変化する。その後、ディスカバリークライアントは、特定のＵＲＬにＨＴＴＰ ＧＥＴ要求を送信して、ディスカバリーサーバー上でアプリケーションのインストールを開始するようにしてもよい。

ディスカバリーサーバーでそのような要求を受信すると、アプリケーション名が認識され、アプリケーションがインストールされていないとともに、ディスカバリーサーバーが指定されたアプリケーション名でアプリケーションをインストールするトリガーをサポートしていない場合には、ディスカバリーサーバーがＨＴＴＰ応答で応答コード「４０４ Ｎｏｔ ｆｏｕｎｄ」を返す。

一実施形態では、アプリケーションがインストール可能であれば、ＧＥＴ要求を通じて、ディスカバリークライアントが、提供されたインストール可能なＵＲＬを要求するか否かを選択する。例えば、ディスカバリークライアントを実行している同じコンピューター上で提供された第２スクリーンアプリは、「アプリケーションがインストールされていません。今、インストールしますか？」というようなユーザーインターフェイス用のメッセージを生成するようにしてもよい。第１のスクリーン装置がインストール要求を扱う過程には、この開示の範囲外であるが、アプリを直接インストール、市場におけるアプリのプレゼンテーション、または、購買施設などの様々な選択がある。

７．０ ディスカバリーレジストリ
一実施形態では、各アプリケーションに対する正確な名前が明確に定義されることを保証し、名前が衝突しないようにするために、アプリケーション名はＤＩＡＬ Ｒｅｇｉｓｔｒｙと呼ばれるデータレジストリに登録される。一実施形態では、サービスプロバイダーがレジストリを維持し、レジストリはここに記載されるディスカバリーサーバーまたはディスカバリークライアントを備える他のあらゆる団体で利用可能である。アプリケーション名は確実に登録され、あるいはアプリケーションの接頭部（プレフィックス）のみを登録することによって、共通のプレフィックスを持つ一連のアプリケーション名を登録するようにしてもよい。

一実施形態では、各アプリケーション名とアプリケーションのプレフィックスは、上記で参照したＢｅｒｎｅｒｓ−Ｌｅｅ（ＲＦＣ ３９８６）に記載されている「ｐｃｈａｒ」プロダクションに一致する文字の並びで構成される。いくつかの実施形態では、アプリケーションのプレフィックスは会社名がわかるように、例えば、「Ａｃｍｅ」、「ｃｏｍ．ａｃｍｅ」などで構成される。

一実施形態では、アプリケーション名はアプリケーション名が市場で実際に利用可能になった時に登録されるようにしてもよく、これで予め登録された名前やプレフィックスが衝突することはない。プレフィックスの会社名でアプリケーションやそれらを実行する装置が市場に盛んに供給されるようになれば、アプリケーションのプレフィックスを登録することができる。以前の登録と混同されるかもしれない名前やプレフィックス、またはここに記載されたディスカバリーサービスに使用する予定のない名前やプレフィックスを登録するべきではない。

８．０ 実装例−ハードウェアの概要
図１２は、本発明の実施形態を実装したコンピューターシステム１２００を示すブロック図である。コンピューターシステム１２００は、バス１２０２または情報を通信するための通信機構と、情報を処理するバス１２０２と接続されたプロセッサ１２０４とを備える。コンピューターシステム１２００は、またランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置などの主記憶装置１２０６を備え、プロセッサ１２０４で実行するための情報及び命令を記憶するためにバス１２０２と接続されている。主記憶装置１２０６は、また一時的な変数またはプロセッサ１２０４で実行される命令が実行中に発生する中間情報を記憶するために用いられる。コンピューターシステム１２００は、さらに、読み取り専用メモリ（ＲＯＭ）または他の静的記憶装置を備え、静的な情報やプロセッサ１２０４の命令を記憶するためにバス１２０２に接続される。磁気ディスクまたは光ディスクなどの記憶装置１２１０は、情報および命令を記憶するために提供され、バス１２０２に接続される。

コンピューターシステム１２００は、ブラウン管（ＣＲＴ）などのディスプレイにバス１２０２を介して接続され、コンピューターのユーザーに情報を表示する。入力装置１２１４は、英数字と他のキーを備え、バス１２０２に接続されて、プロセッサ１２０４に情報およびコマンド選択を通信する。他のタイプのユーザー入力装置は、マウス、トラックボール、または、カーソルの方向キーなどのカーソル制御部１２１６を備え、方向の情報およびコマンド選択をプロセッサ１２０４に通信するとともに、カーソルの動きをディスプレイ１２１２上で制御する。この入力装置は、一般的には、第１軸（例えば、ｘ）と第２軸（例えば、ｙ）の２軸で２つの自由度を持ち、この装置で平面上の特定の位置に持っていくようにする。

本発明は、ここに記載された技術を組み込むためにコンピューターシステム１２００を利用するものに関する。本発明の一実施形態に従えば、主記憶装置１２０６に記憶されている１以上の命令による１以上のシーケンスがプロセッサ１２０４で実行されると、これらの技術が、コンピューターシステム１２００で実施される。このような命令は、記憶装置１２１０などの他のマシン読み取り可能な媒体から主記憶装置１２０６へ読み込まれる。主記憶装置１２０６に含まれる命令のシーケンスを実行すると、プロセッサ１２０４がここに記載した処理ステップを実行する。別の実施形態では、本発明を実施するために、ハードウェア組込型回路がソフトウェア命令と組み合わされて、またはその代わりに、用いられるようにしてもよい。つまり、本発明の実施形態はハードウェア回路とソフトウェアのあらゆる組合せに限定されるものではない。

「マシン読み取り可能な媒体」という用語は、ここでは特定の方法でマシンを動作させるために提供されているデータにかかわるあらゆる媒体を指すものとして用いられる。一実施形態では、コンピューターシステム１２００の利用されるように構成され、様々なマシン読み取り可能な媒体が含まれ、例えば、プロセッサ１２０４で実行される命令を提供する。そのような媒体は、多くの形式を取り、記録媒体や転送媒体に限定されるものではない。記録媒体は、不揮発性媒体および揮発性媒体の両方で構成される。不揮発性媒体には、例えば、記憶装置１２１０などの光ディスクまたは磁気ディスクが含まれる。揮発性媒体には、主記憶装置１２０６などの動的メモリが含まれる。転送媒体には、無線通信や赤外線データ通信で生成されるもののように、音または光の波の形式を取ることも可能である。全てのこのような媒体は、マシンに命令を読み込む物理的なメカニズムによって検出されるように媒体によって運ばれた命令になり得るように、実体のあるものでなければはらない。

記録媒体の一般的な形式には、例えば、フロッピーディスク（登録商標）、フレキシブルディスク、ハードディスク、磁気テープまたはあらゆる他の磁気データ記憶媒体、ＣＤ−ＲＯＭ、あらゆる他の光学データ記憶媒体、パンチカード、紙テープ、穴のパターンがあるあらゆる物理的な媒体、ＰＲＯＭおよびＥＰＲＯＭ、フラッシュＥＰＲＯＭ、その他のメモリチップまたはメモリカートリッジ、以下に記載の搬送波、または、コンピューターが読み取ることが可能な他のあらゆる媒体がある。

様々な形式のマシン読み取り可能な媒体が、プロセッサ１２０４で実行する１以上の命令の１以上のシーケンスを運ぶために用いられる。例えば、命令は最初にリモートコンピューターの磁気ディスク上に置かれる。そのリモートコンピューターが、動的メモリに命令をロードして、モデムを用いた電話回線を通して命令を送信するようにしてもよい。モデムに接続されたコンピューターシステム１２００は、電話回線でデータを受け取り、赤外線変換器でデータを赤外線信号に変換することができる。赤外線検出器は、赤外線信号で運ばれたデータを受信し、適切な回路がバス１２０２にデータを乗せる。バス１２０２は主記憶装置１２０６にデータを運び、そこからプロセッサ１２０４が命令を取り出して実行する。主記憶装置から取り出された命令は、必要であれば、プロセッサ１２０４で実行される前または後に記憶装置１２１０に記憶される。

コンピューターシステム１２００は、また、バス１２０２に接続された通信インターフェイス１２１８を備える。通信インターフェイス１２１８は、ローカルネットワーク１２２２に接続されたネットワークリンク１２２０に接続している双方向のデータ通信を提供する。例えば、通信インターフェイス１２１８は、サービス総合ディジタル網（ＩＳＤＮ）カードや電話回線のタイプに応じたデータ通信接続を提供するモデムであってもよい。他の例では、通信インターフェイス１２１８は、ローカルエリアネットワーク（ＬＡＮ）カードで互換性のあるＬＡＮにデータ通信接続するようにしてもよい。また、無線リンクが組み込まれてもよい。あらゆるこのような実装において、通信インターフェイス１２１８は、情報の様々なタイプを表すデジタルデータストリームを運ぶ電気信号、電磁気信号、光信号の送受信を行う。

ネットワークリンク１２２０は、通常は、１以上のネットワークを介して他のデータ装置にデータ通信を提供する。例えば、ネットワークリンク１２２０が、ホストコンピューター１２２４またはインターネットサービスプロバイダー（ＩＳＰ）１２２６が運営しているデータ機器へローカルネットワーク１２２２を介して接続を提供するようにしてもよい。ＩＳＰ１２２６は、今、通常「インターネット」１２２８といわれる世界的なパケットデータ通信ネットワークを介して、次々と、データ通信サービスを提供する。ローカルネットワーク１２２２とインターネット１２２８はどちらもデータストリームを運ぶ電気信号、電磁気信号、または、光信号を用いる。様々なネットワークを介した信号とネットワークリンク１２２０および通信インターフェイス１２１８における信号は、コンピューターシステム１２００へあるいはコンピューターシステム１２００からデータを運ぶものであり、情報を運ぶ搬送波の典型的な形式である。

コンピューターシステム１２００は、メッセージを送信し、ネットワークやネットワークリンク１２２０や通信インターフェイス１２１８を介してプログラムコードなどのデータを受信する。インターネットの例では、サーバー１２３０は、インターネット１２２８、ＩＳＰ１２２６、ローカルネットワーク１２２および通信インターフェイス１２１８を介してアプリケーションプログラムに要求されたコードを送信する。

コードが受信されると、受信されたコードはプロセッサ１２０４で実行され、後で実行するために記憶装置１２１０または他の不揮発性記憶装置に記憶されるようにしてもよい。このようにして、コンピューターシステム１２００は搬送波の形式でアプリケーションコードを取得するようにしてもよい。

９．０ 開示の他の側面
上記の明細書において、本発明の実施形態が、実装ごとに異なる多数の特定の具体的な形態を参照しながら説明された。つまり、何が発明であり、かつ、出願人によって意図され発明の唯一の独占的な権利の範囲の指標は、本出願の特許請求の範囲と、その請求項の形式、それに続く修正を含めて決められる。ここで請求項に含まれる用語に対して明確に行われた定義は、請求項で用いられる用語の意味を規定することになる。従って、請求項に明示的に記載されていない限定、要素、特性、特徴、利点、または、属性は、請求項の権利範囲に何ら限定を与えるものではない。明細書及び図面は、それにより、限定的な意味を与えるものではなく例示としてみなされるべきものである
ここに記載された主題のあらゆる側面が、以下の番号が振られた項目に示される。

１． ネットワークにディスカバリー要求の送信を開始し、ディスカバリー要求に応じて、第１のスクリーン装置上のディスカバリーサーバーを特定したディスカバリー応答を受け取り、前記第１のスクリーン装置上で特定のアプリケーションの起動するように前記ディスカバリーサーバーに起動要求を送信し、第２のスクリーン装置上で実行されているローカルなアプリケーションに対する前記特定のアプリケーションを特定し、ネットワークを介して、前記ローカルなアプリケーションと前記特定のアプリケーション間でやり取りする方法が、１以上の計算装置で実行される。

２．前記１以上の計算装置が前記第２のスクリーン装置である、第１項の方法。

３．前記双方向のやり取り（インタラクション）は、前記第１のスクリーン装置上で前記特定のアプリケーションを用いて映画を上演することを含み、前記映画は前記ローカルなアプリケーションを用いて選択される、第１〜２項いずれかの方法。

４．前記やり取りを行うステップは、前記第１のスクリーン装置上で前記特定のアプリケーションを用いてビデオを上演することを含み、前記ビデオは、前記ローカルなアプリケーションに対応するネットワークアドレスを前記ローカルなアプリケーションから前記特定のアプリケーションに渡すことにより選択される、第１〜３項いずれかの方法。

５．前記特定のアプリケーションは、前記ビデオの上映後に終了する、第４項の方法。

６．前記特定のアプリケーションは、前記第１のスクリーン装置のウェッブブラウザーで実行されるブラザーベースのアプリケーションであり、前記起動要求により前記ブラウザベースのアプリケーションのネットワークアドレスを特定する、第１〜５項いずれかの方法。

７．前記ブラウザベースのアプリケーションのネットワークアドレスは、前記ネットワークの外部のクラウドアドレスである、第６項の方法。

８．起動要求の前にさらに、アプリケーション情報を前記ディスカバリーサーバーに送信することによって前記特定のアプリケーションが利用可能であるかを確認するとともに、前記ディスカバリーサーバーから得たアプリケーション情報の応答を照合する、第１〜７項いずれかの方法。

９．前記アプリケーション情報の応答の照合が、前記特定のアプリケーションがインストールされていないがインストールすることが可能であることを示し、前記確認が前記特定のアプリケーションのインストールが開始に応じて行われる、第８項の方法。

１０．前記ネットワークがローカルネットワークである、第１〜９項いずれかの方法。

１１．前記ディスカバリーサーバーは複数のディスカバリーサーバーから選択された、第１〜９項いずれかの方法。

１２．前記ディスカバリー応答が前記ディスカバリーサーバーの位置と名前を特定する、第１〜１１項いずれかの方法。

１３．前記ディスカバリー要求がユニバーサルプラグアンドプレイ（ＵＰｎＰ）を用いて送信される、第１〜１２項いずれかの方法。

１４．前記起動要求がさらに１以上の特定のパラメーター値を含んでいる、第１〜１３項いずれかの方法。

１５．第１のスクリーン装置が、テレビ、セットトップボックス、ゲームコンソール、デジタルビデオレコーダー、ディスクプレーヤー、または、主にオーディオビジュアル番組の画像表示の再生または生成を行うことが可能な同様の装置で構成される、第１〜１４項いずれかの方法。

１６．第２のスクリーン装置が、スマートフォン、タブレットコンピューター、ラップトップコンピューター、ネットブックコンピューター、または、他の汎用のコンピューター装置およびワークステーションのいずかで構成される、第１〜１５項いずれかの方法。

１７．１以上のプロセッサによって実行されると第１〜１６項のいずれかに記載された方法を実行する１以上の命令のシーケンスを記憶するコンピューター読み取り可能な記録媒体。

１８．１以上のプロセッサ上に組み込まれたときに第１〜１６項いずれかに記載された方法を実行する命令を搬送するためのコンピュータプログラム製品。

１９．第２のスクリーンの計算器は、第１〜１６項のいずれかに記載された方法を実行するプロセッサを備えている。

Claims (15)

1. ネットワークにディスカバリー要求の送信を開始するステップと、
   前記ディスカバリー要求に応じて、第１のスクリーン装置上のディスカバリーサーバーを特定したディスカバリー応答を受信するステップと、
   前記第１のスクリーン装置上で特定のアプリケーションを起動するように前記ディスカバリーサーバーに起動要求を送信するステップと、
   第２のスクリーン装置上で実行されているローカルなアプリケーションに対する前記特定のアプリケーションを特定するステップと、
   前記ネットワークを介して、前記ローカルなアプリケーションと前記特定のアプリケーション間でインタラクションを行うステップと、
   を備えた方法であって、
   該方法を、１以上のコンピューター装置を用いて実行する方法。
2. 前記１以上のコンピューター装置が前記第２のスクリーン装置であることを特徴とする請求項１記載の方法。
3. 前記インタラクションを行うステップが、前記特定のアプリケーションを用いて前記第１のスクリーン装置上で映画を上演することを含み、
   前記映画は、前記ローカルなアプリケーションを用いて選択されることを特徴とする請求項１記載の方法。
4. 前記インタラクションを行うステップが、前記第１のスクリーン装置上で前記特定のアプリケーションを用いてビデオを上演することを含み、
   前記ビデオは、前記ローカルなアプリケーションに対応するネットワークアドレスを前記ローカルなアプリケーションから前記特定のアプリケーションに渡すことにより選択されることを特徴とする請求項１記載の方法。
5. 前記特定のアプリケーションは、前記ビデオの上映後に終了することを特徴とする請求項４記載の方法。
6. 前記特定のアプリケーションは、前記第１のスクリーン装置のウェッブブラウザーで実行されるブラウザベースのアプリケーションであり、
   前記起動要求が、前記ブラウザベースのアプリケーションのネットワークアドレスを特定することを特徴とする請求項１記載の方法。
7. 前記ブラウザベースのアプリケーションのネットワークアドレスは、前記ネットワークの外部のクラウドアドレスであることを特徴とする請求項６記載の方法。
8. 前記起動要求の前に、アプリケーション情報を前記ディスカバリーサーバーに送信し、前記ディスカバリーサーバーからのアプリケーション情報の応答を照合することによって、前記特定のアプリケーションが利用可能であるかを確認するステップをさらに備えることを特徴とする請求項１記載の方法。
9. 前記アプリケーション情報の応答の照合が、前記特定のアプリケーションがインストールされていないがインストールすることが可能であることを示すものであり、
   前記確認は、前記特定のアプリケーションのインストールが開始に応じて行われることを特徴とする請求項８記載の方法。
10. 前記ディスカバリーサーバーは複数のディスカバリーサーバーから選択されることを特徴とする請求項１記載の方法。
11. 前記ディスカバリー要求が、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）を用いて送られるものであり、前記ディスカバリー応答が前記ディスカバリーサーバーの位置および名前を特定するものであることを特徴とする請求項１記載の方法。
12. 前記起動要求が、さらに１以上の特定のパラメーター値を含むことを特徴とする請求項１記載の方法。
13. 第１のスクリーン装置が、テレビ、セットトップボックス、ゲームコンソール、デジタルビデオレコーダー、ディスクプレーヤー、または、主にオーディオビジュアル番組の画像表示の再生または生成を行うことが可能な同様の装置で構成され、
    第２のスクリーン装置が、スマートフォン、タブレットコンピューター、ラップトップコンピューター、ネットブックコンピューター、または、他の汎用のコンピューター装置およびワークステーションのいずか一方、で構成されることを特徴とする請求項１記載の方法。
14. 請求項１〜１３のいずれか１項に記載された方法を実行するように構成された１以上のデバイスを備えた装置。
15. １以上のプロセッサによって実行される請求項１〜１３のいずれか１項に記載された方法の命令を記録したコンピューター読み取り可能な記録媒体。

Images