▶ インスティテュート フューア ランドファンクテクニック ゲーエムベーハーの特許一覧
特許7416481第１のデバイス上の第１のアプリケーションと第２のデバイス上の第２のアプリケーションとの間の接続の確立
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-01-09
(45)【発行日】2024-01-17
(54)【発明の名称】第１のデバイス上の第１のアプリケーションと第２のデバイス上の第２のアプリケーションとの間の接続の確立
(51)【国際特許分類】
H04W 80/12 20090101AFI20240110BHJP
H04W 84/10 20090101ALI20240110BHJP
H04N 21/41 20110101ALI20240110BHJP
H04W 76/14 20180101ALI20240110BHJP
【ＦＩ】
H04W80/12
H04W84/10
H04N21/41
H04W76/14
【請求項の数】
19
(21)【出願番号】P 2022513901
(86)(22)【出願日】2020-07-20
(65)【公表番号】
(43)【公表日】2022-11-01
(86)【国際出願番号】 EP2020070413
(87)【国際公開番号】W WO2021043490
(87)【国際公開日】2021-03-11
【審査請求日】2023-02-28
(31)【優先権主張番号】19194998.1
(32)【優先日】2019-09-02
(33)【優先権主張国・地域又は機関】EP
(73)【特許権者】
【識別番号】511109386
【氏名又は名称】インスティテュート フューア ランドファンクテクニック ゲーエムベーハー
(74)【代理人】
【識別番号】110000877
【氏名又は名称】弁理士法人ＲＹＵＫＡ国際特許事務所
(72)【発明者】
【氏名】プロブスト、マイケル
(72)【発明者】
【氏名】メルケル、クラウス
(72)【発明者】
【氏名】ジーグラー、クリストフ
【審査官】伊東 和重
(56)【参考文献】
【文献】特表２０１７－５１０１３１（ＪＰ，Ａ）
【文献】特表２０１７－５０２３７３（ＪＰ，Ａ）
【文献】特表２０１６－５４１０３４（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４－７／２６
Ｈ０４Ｗ ４／００－９９／００
Ｈ０４Ｎ ２１／００－２１／８５８
(57)【特許請求の範囲】
【請求項1】
第１のデバイス上の第１のアプリケーションと前記第１のデバイス上の通信サービスとの間の接続を、第２のアプリケーションに割り当てられた識別を使用して確立することと、第２のデバイス上で実行される前記第２のアプリケーションと前記通信サービスとの間の接続を、前記識別を使用して確立することと、
前記通信サービスを介して前記第１のアプリケーションと前記第２のアプリケーションとの間に通信チャネルを確立することと、
前記第２のアプリケーションによって、前記第１のアプリケーションから第１のメッセージを受信することと、を包含し、前記第１のメッセージが、前記第２のデバイス上で実行される第３のアプリケーション、及び／又は前記第２のデバイス上で実行される前記第３のアプリケーションの第１のサービスを指定する、方法。
【請求項2】
前記第１のデバイスは、画像データ及び音声データを再生するように形成されている、請求項１に記載の方法。
【請求項3】
前記第１のデバイスは、ＨｂｂＴＶ対応受信デバイスとして形成されている、請求項１又は２に記載の方法。
【請求項4】
前記第１のデバイス上の前記第１のアプリケーションは第１の放送チャネルに割り当てられ、かつ前記第１のデバイスが前記第１の放送チャネルの画像データ及び音声データを再生する場合に、自動的に開始されるか、又は手動で開始され得る、請求項２又は請求項３に記載の方法。
【請求項5】
前記第２のアプリケーションは、前記第１のアプリケーションに前記第３のアプリケーション及び／又は前記第１のサービスの実行を起動する権限が付与されているかどうかを検査し、前記第１のアプリケーションに、前記第３のアプリケーション及び／又は前記第１のサービスの前記実行を起動する権限が付与されている場合に、前記第３のアプリケーション及び／又は前記第１のサービスの実行をさせる、請求項１～請求項４のいずれか一項に記載の方法。
【請求項6】
前記第１のアプリケーションを終了すること、及び前記第１のデバイス上の第４のアプリケーションを実行することと、前記識別を使用して、前記通信サービスを介して前記第４のアプリケーションと前記第２のアプリケーションとの間に通信チャネルを確立することと、
前記第２のアプリケーションによって、前記第４のアプリケーションから第２のメッセージを受信することと、をさらに包含し、前記第２のメッセージが、前記第２のデバイス上で実行される第５のアプリケーション、及び／又は前記第２のデバイス上で実行される前記第５のアプリケーションの第２のサービスを指定する、請求項１～請求項５のいずれか一項に記載の方法。
【請求項7】
前記第２のデバイス上で実行される前記第２のアプリケーションによって第３のメッセージを配布することと、前記第１のデバイスによって前記第３のメッセージに応答することと、をさらに包含し、前記応答は、前記第１のデバイス上の前記通信サービスのアドレスを含む、請求項１～請求項６のいずれか一項に記載の方法。
【請求項8】
前記第２のデバイス上で実行される前記第２のアプリケーションは、前記通信チャネルに関する確立試行を前記通信チャネルが確立されるまで繰り返す、請求項１～請求項７のいずれか一項に記載の方法。
【請求項9】
インスタンスの識別が前記第２のデバイス上の前記第２のアプリケーションに割り当てられている、請求項１～請求項８のいずれか一項に記載の方法。
【請求項10】
前記第１のデバイス上の前記識別が前記第１のアプリケーションによって永続的に記憶され、かつ前記記憶された識別へのアクセスが、前記第１のアプリケーションと同じソースからのものであるアプリケーションに限定されている、請求項１～請求項９のいずれか一項に記載の方法。
【請求項11】
前記第２のアプリケーションが前記識別を前記第１のアプリケーションに伝送し、前記第１のアプリケーションが前記識別を前記第１のデバイス上に永続的に記憶する、請求項９又は請求項１０に記載の方法。
【請求項12】
前記識別は、前記第１のデバイス上で実行される、前記第１のアプリケーションとは別のソースからのものである第５のアプリケーションに提供され、前記第１のデバイス上の前記第５のアプリケーションにより永続的に記憶される、請求項１～請求項１１のいずれか一項に記載の方法。
【請求項13】
前記第１のアプリケーションは、前記識別を前記第５のアプリケーションに転送し、前記第５のアプリケーションは、前記識別を前記第１のデバイス上に永続的に記憶する、請求項１２に記載の方法。
【請求項14】
前記第２のアプリケーションは、さらなるアプリケーションの識別及びソースを前記第１のデバイス上の第６のアプリケーションに伝送し、前記第６のアプリケーションは、前記さらなるアプリケーションを実行し、かつ前記識別を付与し、前記さらなるアプリケーションが前記識別を前記第１のデバイス上に記憶し、かつそのソースに割り当てる、請求項９又は請求項１０に記載の方法。
【請求項15】
前記識別は、前記第１のデバイス上のアプリケーションによりユーザ入力から導出され、かつ永続的に記憶される、請求項９又は１０に記載の方法。
【請求項16】
前記第１のデバイス上の前記第１のアプリケーションは、前記識別を用いて、前記第３のアプリケーション及び／又は前記第３のアプリケーションによって提供される前記第１のサービスを指定する第４のメッセージを前記第２のデバイス上の前記第２のアプリケーションに外部通信サービスを介して送信する、請求項９～請求項１５のいずれか一項に記載の方法。
【請求項17】
前記第１のデバイス上の前記第１のアプリケーションは、前記識別を使用して、外部通信サービスを介して前記第２のデバイス上の前記第２のアプリケーションに第５のメッセージを送信し、前記第５のメッセージは、前記第２のアプリケーションに前記第２のアプリケーションと前記通信サービスとの間に接続を確立するよう促す、請求項９～請求項１５のいずれか一項に記載の方法。
【請求項18】
前記第２のデバイス上で実行される前記第３のアプリケーション、及び／又は前記第２のデバイス上で実行される前記第１のサービスが、前記第１のメッセージに反応して、又は操作入力に反応して即座に、又は後の時点に実行される、請求項１～請求項１７のいずれか一項に記載の方法。
【請求項19】
前記第３のアプリケーションは、前記第１のデバイス上の再生と調整されたユーザインターフェースを提供し、前記調整は、前記第１のアプリケーションと前記第３のアプリケーションとの間で確立される通信チャネルを用いて行われる、請求項１～請求項１８のいずれか一項に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、異なったデバイス上のアプリケーション間の接続の確立に関する。特に、本発明は、ＨｂｂＴＶデバイス上のＨｂｂＴＶアプリケーションと携帯機器上の第２のアプリケーションとの間の接続の確立に関する。
【背景技術】
【0002】
ＨｂｂＴＶ仕様のバージョン２は、ＨｂｂＴＶアプリケーション（「Ａｐｐ」）を表示できるローカルネットワーク上のデバイス（例えばタブレット、携帯電話など）を見つけ出し、見つかったデバイス上でアプリケーションを開始できるメカニズムを定義する。しかしＨｂｂＴＶ－２は、ＨｂｂＴｖアプリケーションがデバイスの検索（「Ｄｉｓｃｏｖｅｒｙ」）とアプリケーションの開始（「Ｌａｕｎｃｈ」）をトリガできるインターフェースを表すにすぎない。したがって、表示可能なデバイス（「Ｓｅｃｏｎｄ Ｓｃｒｅｅｎ」）とＨｂｂＴＶデバイスとの間の通信には、典型的にはメーカ固有のプロトコルが使用される。
【発明の概要】
【発明が解決しようとする課題】
【0003】
ＨｂｂＴＶ２規格は、ＨｂｂＴＶデバイスのメーカが、ＨｂｂＴＶデバイス及びそれぞれの表示可能なデバイス上でメーカ固有のプロトコルのエンドポイントを実装するアプリケーションを提供することを企図する。ＨｂｂＴＶ規格に準拠したこのようなメーカ固有のランチャアプリケーションには次の弱点がある。
１．ＨｂｂＴＶデバイス用の「ランチャ」アプリケーションを提供する義務がすべてのメーカにあるわけではない。これは、対応するサービスのエリアに悪影響を及ぼす可能性がある。
２．インストール及び規定の使用に関して「ランチャ」アプリケーションのユーザガイドのための拘束力のあるガイドラインがない。
したがって、異なるメーカの「ランチャ」アプリケーションは、これらの点で異なる。「Ｓｅｃｏｎｄ Ｓｃｒｅｅｎ」アプリケーションのプロバイダは、表示可能なデバイス上で実行されるＨｂｂＴＶデバイスのために、どの「ランチャ」アプリケーションが適しているのか、ユーザはこれをどこで入手できるのか、どのようにして正しく使用するのかをユーザに知らせるという課題に直面する。
１．ＨｂｂＴＶデバイス用の「ランチャ」アプリケーションを提供する義務がすべてのメーカにあるわけではない。これは、対応するサービスのエリアに悪影響を及ぼす可能性がある。
２．インストール及び規定の使用に関して「ランチャ」アプリケーションのユーザガイドのための拘束力のあるガイドラインがない。
したがって、異なるメーカの「ランチャ」アプリケーションは、これらの点で異なる。「Ｓｅｃｏｎｄ Ｓｃｒｅｅｎ」アプリケーションのプロバイダは、表示可能なデバイス上で実行されるＨｂｂＴＶデバイスのために、どの「ランチャ」アプリケーションが適しているのか、ユーザはこれをどこで入手できるのか、どのようにして正しく使用するのかをユーザに知らせるという課題に直面する。
【課題を解決するための手段】
【0004】
本発明は、異なるデバイス上のアプリケーション間の接続を確立するための従来技術から知られている方法のこれらの、及び他の問題を克服する。その場合、本発明は、ＨｂｂＴＶに限定されるものではなく、全く一般に、異なるデバイス上のアプリケーション間の接続を確立するために使用され得る。
【0005】
本発明による方法は、第１のデバイス上の第１のアプリケーションと第１のデバイス上の通信サービスとの間の接続を、第２のアプリケーションに割り当てられた識別を使用して確立することと、第２のデバイス上で実行される第２のアプリケーションと通信サービスとの間の接続を、識別を使用して確立することと、通信サービスを介して第１のアプリケーションと第２のアプリケーションとの間に通信チャネルを確立することと、第２のアプリケーションによって、第１のアプリケーションから第１のメッセージを受信することと、を包含し、第１のメッセージが、第２のデバイス上で実行される第３のアプリケーション、及び／又は第２のデバイス上で実行される第３のアプリケーションの第１のサービスを指定する。
【0006】
その場合、本明細書及び特許請求の範囲の枠内で使用される「接続を確立する」という表現は、特に、ユーザデータをあるデバイス上のアプリケーションから別のデバイス上のアプリケーションに伝送できるようにするために用いられるメッセージの送受信と解されるべきである。さらに、本明細書及び特許請求の範囲の枠内で使用される「アプリケーション」という用語は、特に、以前は利用できなかったサービスをデバイスに追加し、それによってデバイスの使用可能性を広げるソフトウェアプログラムと解されるべきである。ソフトウェアプログラムを、例えば端末のオペレーティングシステム（例えば「ｎａｔｉｖｅ」Ａｎｄｒｏｉｄ（登録商標）、又はｉＯＳ（登録商標）アプリケーション）で実行するために特別に設計することができる。しかし、ソフトウェアプログラムを、他のアプリケーションによって解釈及び実行されるように設計することもできる（例えばＨＴＭＬコード、ＣＳＳコード及び／又はＪａｖａＳｃｒｉｐｔ（登録商標）コードを含む、かつウェブブラウザ又はウェブブラウザを含むアプリケーションによって実行されるウェブサイト）。
【0007】
これに関連して、本明細書及び特許請求の範囲の枠内で使用される「デバイス」という用語は、特に、機能ユニット内の電気及び電子コンポーネントの相互接続と解されるべきであり、電気及び電子コンポーネントは、様々なデバイスにオペレーティングシステムをインストールできるようにするコンポーネント関連のソフトウェアレイヤを備えることができる。
【0008】
これに加えて、本明細書及び特許請求の範囲の枠内で使用される「通信サービス」という用語は、特に、あるデバイスから別のデバイスへのメッセージの伝送を可能にすることに寄与する、デバイス上のソフトウェアレイヤによって提供されるサービスと解されるべきである。これに関連して、本明細書及び特許請求の範囲の枠内で使用される「通信チャネル」という用語は、特に、あるデバイス上のアプリケーションから別のデバイス上のアプリケーションにメッセージを伝送できる伝送経路と解されるべきである。さらに、本明細書及び特許請求の範囲の枠内で使用される「識別」という用語は、特に、エンティティ（例えば、アプリケーションのタイプ又はアプリケーションのインスタンス）を一義的に割り当てることが可能なデジタル再生可能な情報と解されるべきである。
【0009】
殊に、第１のデバイスは、画像データ及び音声データを再生するように形成されている。例えば、第１のデバイスはテレビ受像機として形成され得る。
【0010】
殊に、第１のデバイスはＨｂｂＴＶ対応受信デバイスとして形成されている。例えば、第１のデバイスは、ＨｂｂＴＶ対応テレビ受像機として形成され得る。
【0011】
殊に、第１のデバイス上の第１のアプリケーションは第１の放送チャネルに割り当てられ、かつ第１のデバイスが第１の放送チャネルの画像データ及び音声データを再生する場合に、自動的に開始されるか、又は手動で開始され得る。例えば、第１のアプリケーションは放送局によって発行され、放送局の放送チャネルに関する情報及びサービス、並びに／又は放送チャネルに対してインタラクティブな要素を提供することができる。
【0012】
殊に、第２のアプリケーションは、第１のアプリケーションに第３のアプリケーション及び／又は第１のサービスの実行を起動する権限が付与されているかどうかを検査し、第１のアプリケーションに、第３のアプリケーション及び／又は第１のサービスの実行を起動する権限が付与されている場合に、第３のアプリケーション及び／又は第１のサービスの実行をさせる。
【0013】
殊に、方法は、第１のアプリケーションを終了すること、及び第１のデバイス上の第４のアプリケーションを実行することと、識別を使用して、通信サービスを介して第４のアプリケーションと第２のアプリケーションとの間に通信チャネルを確立することと、第２のアプリケーションによって、第４のアプリケーションから第２のメッセージを受信することと、をさらに包含し、第２のメッセージが、第２のデバイス上で実行される第５のアプリケーション、及び／又は第２のデバイス上で実行される第５のアプリケーションの第２のサービスを指定する。
【0014】
第１のアプリケーションの終了と、第１のデバイス上の第４のアプリケーションの実行は、例えば第１の放送チャネルと第２の放送チャネルとの間の切替えの結果であり得、第２のデバイス上で他のアプリケーション及び／又はサービスが開始されることをもたらすことができ、その場合、切替過程及びこれに伴う第２の放送チャネルへのユーザの注意のシフトが考慮される。
【0015】
方法は、第２のデバイス上で実行される第２のアプリケーションによって第３のメッセージを配布することと、第１のデバイスによって第３のメッセージに応答することと、をさらに包含することができ、応答は、第１のデバイス上の通信サービスのアドレスを含む。
【0016】
すなわち、第２のアプリケーションは、ネットワーク上で第１のデバイスを検索することができ、その場合、検索は、第１のデバイスが第１のデバイス上の通信サービスのアドレスで応答した場合に完了する。
【0017】
第２のデバイス上で実行される第２のアプリケーションは、通信チャネルに関する確立試行を通信チャネルが確立されるまで繰り返すように設定され得る。
【0018】
第１のアプリケーションと第２のアプリケーションとの間の通信チャネルは、第２のデバイス上の第２のアプリケーションのインスタンスを識別する識別を双方で使用して確立され得る。したがって、異なるデバイスで実行される同一のアプリケーションを区別し、それによって的確にアドレス指定することができる。
【0019】
識別は、第１のアプリケーションによって第１のデバイス上に永続的に記憶することができ、記憶された識別へのアクセスを、第１のアプリケーションと同じソース（例えば同じＷｅｂ－Ｏｒｉｇｉｎ）からのものであるアプリケーションに限定することができる。
【0020】
例えば、記憶された識別へのアクセスを、同じ放送局により発行された、又は同じインターネットアドレスで提供されるアプリケーションに限定することができる。
【0021】
第２のアプリケーションは、識別を第１のアプリケーションに伝送することができ、第１のアプリケーションは、識別を第１のデバイスに永続的に記憶する。
【0022】
識別は、第１のデバイス上で実行される、第１のアプリケーションとは別のソースからのものである第５のアプリケーションに提供され、第１のデバイス上の第５のアプリケーションにより永続的に記憶され得る。
【0023】
すなわち、識別を、必要な場合、アプリケーションから他のアプリケーションに転送することができ、それによってこれらのアプリケーションが適切なデバイス／アプリケーションの検索及び検出のプロセスを実行する必要がなくなる。
【0024】
第１のアプリケーションは、識別を第５のアプリケーションに転送するように設定されていてもよく、第５のアプリケーションは、第２の識別を第１のデバイス上に永続的に記憶するように設定されていてもよい。
【0025】
第２のアプリケーションは、権限が付与されたアプリケーションの識別及びソースを第１のデバイス上の第６のアプリケーションに伝送することができ、第６のアプリケーションは、権限が付与されたアプリケーションを実行し、識別を付与し、権限が付与されたアプリケーションは、識別を第１のデバイス上に記憶し、かつそのソースに割り当てる。
【0026】
識別は、第１のデバイス上のアプリケーションによりユーザ入力から導き出され、かつ永続的に記憶され得る。
【0027】
第１のデバイス上の第１のアプリケーションは、識別を用いて、第３のアプリケーション及び／又は第３のアプリケーションによって提供される第１のサービスを識別する第４のメッセージを、外部通信サービスを介して第２のデバイス上の第２のアプリケーションに送信することができる。
【0028】
第１のデバイス上の第１のアプリケーションは、識別を使用して、外部通信サービスを介して第２のデバイス上の第２のアプリケーションに第５のメッセージを送信することができ、第５のメッセージは、第２のアプリケーションに第２のアプリケーションと通信サービスとの間に接続を確立するよう促す。
【0029】
第２のデバイス上で実行される第３のアプリケーション、及び／又は第２のデバイス上で実行される第１のサービスが、第１のメッセージに反応して、又は操作入力に反応して即座に、又は後の時点に実行され得る。
【0030】
殊に、第３のアプリケーションは、第１のデバイス上の再生と調整されたユーザインターフェースを提供し、調整は、第１のアプリケーションと第３のアプリケーションとの間で確立される通信チャネルを用いて行われる。
【0031】
その場合、言うまでもなく、方法の枠内で実行されるステップは、デバイスに永続的に記憶され、ステップを実行するようにデバイスを設定するインストラクションによって実行され得る。
【0032】
以下、本発明が、詳細な説明において実施例をもとにして説明され、図面が参照される。
【図面の簡単な説明】
【0033】
【発明を実施するための形態】
【0034】
その場合、図面において同じ、又は機能的に類似した要素には同じ参照符号が付されている。
【0035】
図１ａは、内部又は外部無線ユニット１４ａを介して第２のデバイス１６及び第３のデバイス１８とデータを交換することができる第１のデバイス１２を備える第１のシステム１０を示す。第１のデバイス１２は、画像データ及び／又は音声データを再生するように設定され得る。例えば、第１のデバイス１２は、１つ又は複数の放送チャネルを無線インターフェース又はケーブルインターフェースを介して受信するように、並びに選択された放送チャネルを含む画像データ及び／又は音声データを（画面上に、又は１つ若しくは複数のスピーカで）再生するように設定されているテレビ受像機（例えばＨｂｂＴＶ対応テレビ受像機）であり得る。第２のデバイス１６及び第３のデバイス１８は、携帯機器（例えばタブレット、携帯電話など）として形成され得、同様に画像データ及び／又は音声データを（画面上に、及び１つ又は複数のスピーカで）再生するように設定され得る。デバイス１２、１６、１８は、ネットワーク（例えば、ＷＬＡＮ対応ルータ１４ａによって構成されるホームネットワークなどの）ノードであり得、ネットワーク内でアドレスによりアドレス指定可能であり得る。
【0036】
図１ｂは、第２のデバイス１６及び第３のデバイス１８が無線経路を介してではなく、有線伝送経路を介して（例えば、ルータ１４ｂ及びイーサネット（登録商標）接続を介して）第１のデバイス１２と接続されるという点で、図１ａに示されるシステム１０とは異なる第２のシステム１０を示す。図１ｃは、第２のデバイス１６が無線経路を介してではなく、有線伝送経路を介して（例えば、ルータ１４ｂ及びイーサネット接続を介して）第１のデバイス１２と接続されるという点で、図１ａに示されるシステム１０とは異なる第３のシステム１０を示す。図１ｄは、第３のデバイス１８が無線経路を介してではなく、有線伝送経路を介して（例えば、ルータ１４ｂ及びイーサネット接続を介して）第１のデバイス１２と接続されるという点で、図１ａに示されるシステム１０とは異なる第４のシステム１０を示す。
【0037】
図１ｅは、第１のデバイス１２が無線を介してルータ１４ｂと接続され、ルータ１４ｂも同様に無線を介して第２のデバイス１６及び第３のデバイス１８と接続されるという点で、図１ｂ～図１ｄに示されるシステム１０とは異なる第５のシステム１０を示す。その場合、当然のことながら、第２のデバイス１６及び／又は第３のデバイス１８をルータ１４ｂと有線伝送経路を介して接続することもできる。
【0038】
図２は、第１のデバイス１２と第２のデバイス１６との間に通信チャネルを確立するためのプロセスを示す。この場合、第１のアプリケーション２０の識別、ＩＤが、例えばタイプ識別子「Ｔｙｐ１」（例えば、「ランチャアプリ実装の名称」）の形で利用可能であると想定される。図２に示されるセッションは、第１のアプリケーション２０（例えば、ＨｂｂＴＶアプリケーション）が通信サービス２２（例えば、ＡＰＰ２ＡＰＰローカルエンドポイント）への接続を開く（第１のアプリケーションが対応するＵＲＬにＩＤを付ける）ことで始まる。
【0039】
図５及び図６に示されるように、図２に示されたシーケンスに、通信サービス２２（又はＡＰＰ２ＡＰＰリモートエンドポイント）を見つけ出し、それに接続するための第２のアプリケーション２４による試行がすでに先行する可能性がある。例えば、第２のアプリケーション２４は、通信サービス発見ルーチンを（例えば、ＨｂｂＴＶ－２で表される「Ｄｉｓｃｏｖｅｒｙ」ルーチンによって）実行することができ、第２のアプリケーションは、この通信サービス発見ルーチンによって通信サービス２２（例えばＡＰＰ２ＡＰＰリモートエンドポイント）を見つけ出す。その場合、通信サービス２２を常に利用可能にするか、又は第１のアプリケーション２０が通信サービス２２への接続を開いたままにしている間だけ利用可能にすることもできる。例えば、ＨｂｂＴＶ－２仕様では、ＨｂｂＴＶアプリケーションによって開かれた後のみ、及びＨｂｂＴＶアプリケーションが通信サービス２２への接続を閉じるまでの間のみＡＰＰ２ＡＰＰリモートエンドポイントのＡＰＰ２ＡＰＰリモートＵＲＬに到達可能であり得る。したがって、対応するリモートステーション（又はＡＰＰ２ＡＰＰローカルエンドポイント）に接続しているアプリケーションがないため、接続試行が失敗する可能性がある。接続されていたアプリケーションが終了したため、それまで確立されていた接続が中断された可能もある。
【0040】
第２のアプリケーション２４が通信サービス２２（又はＡＰＰ２ＡＰＰリモートエンドポイント）を見つけ出した後、第２のアプリケーションは、この通信サービスと、図２に示されるように接続を確立することができ、第２のアプリケーションは、例えば（第２のアプリケーションに割り当てられた）ＩＤをＡＰＰ２ＡＰＰリモートＵＲＬに付け、対応するリクエスト３０を通信サービス２２に送信する。リクエスト３２における第１のアプリケーション２０とリクエスト３０における第２のアプリケーションによって示されたＩＤが一致する場合、第１のデバイス１２上の通信サービス２２は、２つのアプリケーション２０、２４の間に接続を作成する。通信サービス２２は、メッセージ３４（「ｐａｉｒｉｎｇｃｏｍｐｌｅｔｅｄ」）によって第１のアプリケーション２０及び／又は第２のアプリケーション２４に接続の確立について知らせることができる。次に、第１のアプリケーション２０は、第２のアプリケーション２４における通信サービス２２により、第２のデバイス１６（例えば、「Ｓｅｃｏｎｄ Ｓｃｒｅｅｎ」）上の第３のアプリケーション２６及び／又は第１のサービス２８の開始を対応するメッセージ３６で要求することができる。
【0041】
第２のアプリケーション２４は、第１のデバイス１２上の様々なプロバイダのアプリケーション２０（例えば様々なＨｂｂＴＶアプリケーション）、又は様々なソースからのアプリケーション２０が第２のデバイス１６上のアプリケーション／サービスを開始することを可能にするように設定され得る。アプリケーション２０が第１のデバイス１２上で第２のアプリケーション２４と接続できるようにするために、それぞれのアプリケーション２０が、例えば第２のアプリケーション２４のタイプ識別子及び／又はインスタンス識別子であり得るＩＤを知る必要がある。第１のデバイス１２上の特定のアプリケーション２０によって記憶されたＩＤは、同じソースからのものである（又は同じソースからダウンロードされた）アプリケーション２０によってしか読み取ることができないことが企図され得る。これに関連して、ソースは、例えば通信プロトコル（例えばｈｔｔｐ又はｈｔｔｐｓ）、ホスト（例えばｗｗｗ．ｉｒｔ．ｄｅ）、及びアプリケーションをダウンロードできるポート（例えば８０）によって定義でき、異なった発行者のアプリケーション２０は、通常、異なったソースから入手される。ただし、発行者は、様々なソースを介してアプリケーション２０を提供することもできる。
【0042】
異なったデバイス（例えば、第２のデバイス１６及び第３のデバイス１８）上で実行される同じタイプのアプリケーション２４は、図３に示されるように、リクエスト３０が行われる場合、インスタンスを区別できるＩＤを（明示的又は暗黙的に）伝送するという点で区別され得る。ＩＤは、セットアップルーチンの範囲内で、第１のデバイス１２上の（様々なソースからの）１つ又は複数の第１のアプリケーション２０に伝送され得る。この１つ又は複数のアプリケーション２０は、第１のデバイス１２上でＩＤを永続的に記憶することができる。セットアップルーチンは、後からどのアプリケーション２０（又はどのソースからのどのアプリケーション２０）と特定のタイプのアプリケーション２４とが接続することを許すのかをユーザが設定できるように設計され得る。
【0043】
図４に示されるように、第１のアプリケーション２０は、開始される第３のアプリケーション２６又は開始される第１のサービス２８に関するメッセージ３６に、第１のアプリケーション２０を識別する情報（例えば、第１のアプリケーション２０のアプリケーションタイプ）を追加することができる。第２のアプリケーション２４は、情報をもとにして、第１のアプリケーション２０に、一般に任意のアプリケーション／サービスを開始する、又は特に第３のアプリケーション２６及び／若しくは第２のサービス２８を開始する権限が付与されているかどうかを検査することができる。例えば、第２のアプリケーション２４は、情報を「ブラックリスト」（開始が禁止されているアプリケーション／サービスのリスト）又は「ホワイトリスト」（開始が許可されているアプリケーション／サービスのリスト）と比較することができる。
【0044】
第１のアプリケーション２０がどのリストにも現れない場合、第２のアプリケーション２４は、第１のアプリケーション２０によるこの（及び将来の）アプリケーション開始及び／又はサービス開始に同意するかどうかを示すようにユーザに促すことができる。第１のアプリケーション２０にそれぞれのアプリケーション及び／又はそれぞれのサービスを開始する権限が与えられている場合、第２のアプリケーション２４は、これを第１のアプリケーション２０に通知し、続いて、要求されたアプリケーション又は要求されたサービスの開始を試行することができる。第１のアプリケーション２０にそうすることの権限が与えられていない場合、第２のアプリケーション２４は、これを第１のアプリケーション２０に通知することもできる。この場合、第２のアプリケーション２４は、例えば第１のアプリケーション２０が「ブラックリスト」に載っていることの根拠として詳細を提供することができる。このことは、第１のアプリケーション２０が適切な注意事項をユーザに示すことを可能にする。
【0045】
上記の解決策はＨｂｂＴＶ分野において、ＨｂｂＴＶ－２で規定されているメーカ固有の「ランチャ」アプリケーションに対する代替案を提供する。上記の代替案は、ＴＶサービスを包括し、「Ｓｅｃｏｎｄ Ｓｃｒｅｅｎ」へのアプリケーション／サービスの「Ｌａｕｎｃｈ」を可能にし、その場合、追加のＷｅｂサーバなしで済ませられる。後者には、ユーザ数に応じて運用コストが増加しないという利点がある。これに加えて、第１のデバイス１２上のＩＤを除いて、第２のアプリケーション２４の外部にデータが記憶される必要がない。例えば、開始されたアプリケーション／サービスの履歴、及びユーザが大切にするアプリケーション／サービスのお気に入りリストを含むユーザプロフィールを、第２のデバイス１６上の第２のアプリケーション２４に保存することができる。したがって、ユーザは自分のデータに対して完全かつ単独の支配権を持ち、データの読み取り、消去、及び変更はユーザにしかできない。
【0046】
ユーザが（第２のアプリケーション２４と接続できるはずである）各アプリケーション２０のＩＤを個別に入力しなければならないことを防ぐために、これらのアプリケーション２０のリストを第２のアプリケーション２４に保存することができ、第２のアプリケーション２４を、第１のデバイス１２上のアプリケーション２０を次々にアドレス指定し、その際、これらのアプリケーションにＩＤを通知するように設定することができる。
【0047】
そのために、ＨｂｂＴＶアプリケーションの場合、例えばＨｂｂＴＶ－２からのＤｉｓｃｏｖｅｒｙプロトコル及びＬａｕｎｃｈプロトコルを使用できる。例えば、第２のアプリケーション２４は、通信サービスを介して、又はすでに開始ＵＲＬのパラメータとして第１のデバイス１２上のアプリケーション２０にＩＤを伝送することができ、これらのアプリケーションは、このＩＤを第１のデバイス１２（例えばＣｏｏｋｉｅ）に永続的に記憶することができる。その場合、ＩＤを後からの接続のために利用可能である。ＩＤを（場合によって）必要とする第１のデバイス１２上のアプリケーション２０のリストは、第２のアプリケーション２４の「Ｕｐｄａｔｅ」時に更新され得る。更新後、（第１のデバイス１２上のアプリケーション２０の順次アドレス指定を伴う）新たなセットアップを実行することができる。
【0048】
例えば、第２のアプリケーション２４は、（例えばＨｂｂＴＶ仕様からのＤＩＡＬプロトコルによるＨｂｂＴＶ環境で）第１のデバイス１２上の特定のソースからのアプリケーション２０を開始することができ、その際に、ＩＤを伝送することができる。そのソースからのアプリケーション２０はＩＤを記憶することができ、別のソースからのアプリケーション２０に転送することができる。別のソースからのアプリケーション２０もまたＩＤを記憶することができ、このアプリケーション自体としては、別のソースからのアプリケーション２０に転送することができる、等々である。
【0049】
アプリケーション２０がＩＤをどこに転送すべきかを様々な方法で定義することができる。例えば、特定のソースからのアプリケーション２０に、ＩＤが転送されるべき別のアプリケーション２０のリストを提供することができ、そのリストを転送時に、リスト上の第１のアプリケーション２０にＩＤとともに渡すことができる。次に、リスト上の第１のアプリケーション２０をリストから削除し、リストをＩＤとともにリスト上の次のアプリケーション２０に渡すことができる、等々である。
【0050】
さらに、第１のアプリケーション２０は、第２のアプリケーション２４への接続を確立し、それがＩＤを記憶したことを第２のアプリケーション２４に通知することができる。続いて、第２のアプリケーション２４は第１のアプリケーション２０に、別のソースからの別のアプリケーション２０にＩＤを転送するようコマンドを送信することができ、次いで、このアプリケーションは、第２のアプリケーション２４への接続を確立する、等々である。
【0051】
さらに、第２のアプリケーション２４（例えば、ＨｂｂＴＶ－２仕様からのＤＩＡＬプロトコルによるＨｂｂＴＶ環境で）は、権限が付与されたソースのすべてのアプリケーション２０を次々に開始し、その際に、それぞれＩＤを伝送することができる。
【0052】
さらに、第２のアプリケーション２４は、第１のデバイス１２上のアプリケーションを開始し、その際に、権限が付与されたソースのすべてのアプリケーション２０のＵＲＬを伝送することができる。次に、開始されたアプリケーションは、権限が付与されたソースのアプリケーション２０をインラインフレームとして結びつけ、インラインフレームでＩＤをアプリケーション２０に渡すことができる。ＩＤを、例えば、ＵＲＬパラメータを介して、権限が付与されたソースからのアプリケーション２０のアドレスに渡すことができる。さらに、ＩＤを、インラインフレームに埋め込むことによって、Ｗ３Ｃ Ｗｅｂ－Ｍｅｓｓａｇｉｎｇ－ＡＰＩを用いて、開始されたアプリケーションと権限が付与されたアプリケーション２０との間で転送することができる。
【0053】
これに加えて、Ｗｅｂｓｅｒｖｉｃｅも使用できる。第１のデバイス１２上のアプリケーション２０を第２のアプリケーション２４と接続したいが、ＩＤがない場合、アプリケーション２０は、Ｗｅｂｓｅｒｖｉｃｅのアプリケーションへの転送を設定することができる。ＷｅｂｓｅｒｖｉｃｅのアプリケーションにＩＤが提供されていない場合、ユーザにＩＤの入力を要求することができる。ユーザがＩＤを入力すると、Ｗｅｂｓｅｒｖｉｃｅのアプリケーションは、このＩＤを第１のデバイス１２に記憶することができる。続いて、Ｗｅｂｓｅｒｖｉｃｅのアプリケーションは、第１のデバイス１２上のアプリケーション２０へのリダイレクトを設定し、その際に、ＩＤを伝送することができる。第１のデバイス１２上のアプリケーション２０は、第１のデバイス１２上にＩＤを記憶することができる。したがって、Ｗｅｂｓｅｒｖｉｃｅのアプリケーションへの転送により、第１のデバイス１２上のすべてのアプリケーション２０にＩＤを利用可能にすることができる。
【0054】
これに加えて、Ａｎｄｒｏｉｄ及びｉＯＳオペレーティングシステムを有する第２のデバイス１６では、ＷｅｂｓｅｒｖｉｃｅはＧｏｏｇｌｅの「Ｆｉｒｅｂａｓｅ－Ｃｌｏｕｄ－Ｍｅｓｓａｇｉｎｇ」Ｓｅｒｖｉｃｅへの中央ゲートウェイとして用いることもできる（第２のデバイス１６のための他のプラットフォームは同等のサービスを提供する）。デバイス１６上においてバックグラウンドで実行され、特別な特権を持たないアプリケーション２４は、典型的には、メインメモリやＣＰＵなどのリソースを解放するために、一定時間後にオペレーティングシステムによってクリーンアップされる。この状態では、上記のアプリケーション２４はもはやＣｏｄｅを実行することができない。すなわち、第２のアプリケーション２４は、クリーンアップされた状態では、ネットワーク（ホームネットワーク）内の第１のデバイス１２又は通信サービス２２を検索することも、第１のアプリケーション２０からのメッセージに反応することもできなくなっている。ユーザによる第２のアプリケーション２４の新たな開始の他に、第２のアプリケーション２４を再び実行できるようにするために、期限が決められたタスク（例えばＡｎｄｒｏｉｄでの「ＪｏｂＳｃｈｅｄｕｌｅｒ」）及び「Ｆｉｒｅｂａｓｅ－Ｃｌｏｕｄ－Ｍｅｓｓａｇｅ」（ＦＣＭ）を利用することができる。ＦＣＭは、Ｆｉｒｅｂａｓｅ－Ｃｌｏｕｄ－Ｍｅｓｓａｇｉｎｇ－Ｓｅｒｖｉｃｅによりデバイス１６上のアプリケーションに送信され得るプッシュメッセージである。
【0055】
アプリケーション２４は、ＦＣＭへの反応として、ユーザにメッセージを（例えば、場合によってはバイブレーションアラーム及び／又は信号音によって補助されるステータスバーの「アイコン」としての「Ｎｏｔｉｆｉｃａｔｉｏｎ」）表示することができ、その場合、ユーザはそれによって第２のアプリケーション２４を再び開始することができる。Ａｎｄｒｏｉｄでは、ＦＣＭによっていわゆる「Ｆｏｒｅｇｒｏｕｎｄ」Ｓｅｒｖｉｃｅとしてアプリケーション２４を開始することもできる。これは、デバイス１６上においてバックグラウンドで実行されるサービスであるが、例えばステータスバーのアイコンによってユーザに可視である。第１のデバイス１２上のＦＣＭアプリケーション２０に関連して、Ｗｅｂｓｅｒｖｉｃｅは、第２のデバイス１６上の到達可能でない第２のアプリケーション２４でこれらの第２のアプリケーションを再び到達可能にするアクションをトリガする可能性を提供する。
【符号の説明】
【0056】
１０ システム
１２ 第１のデバイス
１４ａ 無線ユニット
１４ｂ ルータ
１６ 第２のデバイス
１８ 第３のデバイス
２０ 第１のアプリケーション
２２ 通信サービス
２４ 第２のアプリケーション
２６ 第３のアプリケーション
２８ 第１のサービス
３０ リクエスト
３２ リクエスト
３４ メッセージ
３６ メッセージ
１２ 第１のデバイス
１４ａ 無線ユニット
１４ｂ ルータ
１６ 第２のデバイス
１８ 第３のデバイス
２０ 第１のアプリケーション
２２ 通信サービス
２４ 第２のアプリケーション
２６ 第３のアプリケーション
２８ 第１のサービス
３０ リクエスト
３２ リクエスト
３４ メッセージ
３６ メッセージ
【図1a】
【図1b】
【図1c】
【図1d】
【図1e】
【図2】
【図3】
【図4】
【図5】
【図6】