JPWO2008087713A1 - クライアント端末、アプリケーション提供サーバ及びアプリケーション提供システム - Google Patents

Abstract

宅内端末が提供するサービスを規定する情報を含む端末情報と自端末のサービス処理能力を規定する情報とを比較してサービスを利用する際に実行されるアプリケーションの取得条件を抽出し、この取得条件に基づいてアプリケーション提供サーバからメタ情報を取得し、このメタ情報に基づいて指定されたアプリケーション本体をアプリケーション提供サーバから取得するクライアント端末。

Description

この発明は、ネットワーク上において利用可能な各端末の機能に応じて、これらの機能を利用するアプリケーションやユーザインタフェースを容易に選択可能なクライアント端末、アプリケーションを提供するアプリケーション提供サーバ、及びこれらを備えたアプリケーション提供システムに関するものである。

例えば、特許文献１に開示されるデータ中継装置では、宅内ネットワーク上に接続された端末が提供する機能を調査した後、自らが保持するサービス台帳に従い、その機能から実現可能なサービスを列挙してユーザに通知する。

また、通知を受けたユーザから利用するサービスの選択を受け付け、ユーザがサービスを選択すると、データ中継装置は、このサービスを構成する機能を持つ各端末をそれぞれ設定する。これにより、ユーザは、選択したサービスの利用が可能となる。

このように、ネットワーク上の各端末の機能を利用するサービスをユーザに提示し、提示を受けたユーザは、選択したサービスを直ちに利用可能となるので、ユーザが各端末を設定するための複雑な知識を要さずともサービスを簡単に利用することができる。

さらに、このデータ中継装置では、宅外ネットワークに接続された端末からサービス台帳の更新データを取得し、取得した更新データに従って新たに実現可能なサービスを列挙してユーザに通知する。これにより、データ中継装置が宅外ネットワークから新たなサービス台帳を取得することで、新たなサービスを利用することができた。

特開２０００−３３２８１１号公報

従来では、宅内ネットワークに接続された宅内端末が提供する機能の組み合わせとしてサービスを利用することはできた。しかしながら、サービスを利用する際に用いるアプリケーションやユーザインタフェースに関しては、予め宅内端末に用意されているものを使用するしかないという課題があった。

この発明は、上記のような課題を解決するためになされたもので、宅内ネットワークに接続された宅内端末が提供するサービスを利用するにあたり、これらサービスを利用する際に実行されるアプリケーションやユーザインタフェースを、予め宅内端末に用意されているものに限定されず、ユーザの好みに応じて選択し実行することができるクライアント端末、アプリケーション提供サーバ及びアプリケーション提供システムを得ることを目的とする。

この発明に係るクライアント端末は、宅内ネットワークに接続された宅内端末から、該宅内端末が提供するサービスを規定する情報を含む端末情報を取得し、自端末によるサービスの処理能力を規定する情報と比較して、これら情報から自端末で宅内端末より提供されたサービスを利用する際に実行されるアプリケーションの取得条件を抽出し、このアプリケーションの取得条件に基づいて、宅外ネットワーク上のアプリケーション提供サーバからアプリケーションに関するメタ情報を取得すると共に、このメタ情報に基づいて指定されたアプリケーション本体を、宅外ネットワーク上のアプリケーション提供サーバから取得するものである。

このことによって、宅内ネットワーク上の各宅内端末から提供されるサービス機能を利用するアプリケーションを容易に選択し実行することができるという効果がある。

この発明の実施の形態１によるアプリケーション提供システムの構成を示すブロック図である。 実施の形態１のアプリケーション提供システムの動作の流れを示すシーケンス図である。 宅内端末の端末情報の一例を示す図である。 端末能力マッチング部が管理する自クライアント端末能力の一例を示す図である。 アプリケーション取得条件の一例を示す図である。 端末能力マッチング処理の流れを示すフローチャートである。 アプリケーション・メタデータ検査要求の一例を示す図である。 アプリケーション・メタ情報の一例を示す図である。 アプリケーション・メタデータ検索応答の一例を示す図である。 アプリケーション選択用ＧＵＩの一例を示す図である。 アプリケーション本体取得要求を示す図である。 アプリケーション本体取得応答を示す図である。 アプリケーション本体の実行により表示されるＧＵＩ画面を示す図である。 この発明の実施の形態２によるアプリケーション提供システムの構成を示すブロック図である。 実施の形態２のアプリケーション提供システムによる動作の流れを示すシーケンス図である。 実施の形態２による宅内端末の端末情報の一例を示す図である。

以下、この発明をより詳細に説明するために、この発明を実施するための最良の形態について、添付の図面に従って説明する。
実施の形態１．
先ず、この発明における用語の定義をする。
この発明におけるサービスとは、宅内端末、及び情報提供サーバが外部に提供する機能であり、各サービスに対して入出力が定義される。この発明におけるアプリケーションとは、クライアント端末上で動作する応用ソフトウェアをいい、上記サービスや予めクライアント端末を制御するために定義されたＡＰＩ（Application Program Interface）を利用して動作する。特に、“アプリケーション本体”とは、アプリケーションとして実行されるソフトウェア自身を示し、“アプリケーション・メタ情報”とは、アプリケーションの名称や説明などのアプリケーションの属性を記述する付加情報を示すものとする。

図１は、この発明の実施の形態１によるアプリケーション提供システムの構成を示すブロック図である。図１において、実施の形態１によるアプリケーション提供システムは、クライアント端末１００、宅内端末１２０〜１２２、アプリケーション提供サーバ１４０及び情報提供サーバ１５０を備える。クライアント端末１００は、宅内ネットワーク１１０に接続されており、この宅内ネットワーク１１０には宅内端末１２０〜１２２も接続されている。

宅外ネットワーク１３０は、宅内ネットワーク１１０からアクセス可能に構成されている。アプリケーション提供サーバ１４０は、クライアント端末１００上において実行可能なアプリケーションを提供する。情報提供サーバ１５０は、宅外ネットワーク１３０に接続され、クライアント端末１００上にて実行されるアプリケーションに対して情報を提供する。

クライアント端末１００は、ネットワーク端末情報管理部１０１、端末能力マッチング部１０２、アプリケーション・メタ情報取得部１０３、アプリケーション選択部１０４、アプリケーション本体取得部１０５、アプリケーション実行部１０６、端末制御部１０７及びネットワークＩＦ１０８の各機能ブロックを有して構成される。

ネットワーク端末情報管理部１０１は、宅内ネットワーク１１０上の他の宅内端末の端末情報を取得し管理する。端末能力マッチング部１０２は、自クライアント端末１００の能力とネットワーク端末情報管理部１０１が取得した他の宅内端末の端末情報とを比較して、アプリケーションの取得条件を抽出する。アプリケーション・メタ情報取得部１０３は、端末能力マッチング部１０２が抽出した取得条件に基づいて、アプリケーション提供サーバ１４０からアプリケーションに関するメタ情報を取得する。

アプリケーション選択部１０４は、取得したアプリケーション・メタ情報をユーザへ提示しユーザからのアプリケーションの選択を受け付ける。アプリケーション本体取得部１０５は、ユーザによって選択されたアプリケーションのアプリケーション本体を取得する。アプリケーション実行部１０６は、アプリケーション本体取得部１０５により取得されたアプリケーションを実行する。端末制御部１０７は、アプリケーション実行部１０６からの指示に従い、クライアント端末１００及び宅内端末１２０〜１２２の動作を制御する。

ネットワークＩＦ１０８は、ネットワーク端末情報管理部１０１、アプリケーション・メタ情報取得部１０３、アプリケーション本体取得部１０５及び端末制御部１０７が、宅内ネットワーク１１０と通信する際のインタフェースである。なお、以降の説明では、特に記載はしないが、クライアント端末１００と、各宅内端末１２０〜１２２、アプリケーション提供サーバ１４０及び情報提供サーバ１５０との通信には、全てネットワークＩＦ１０８を経由するものとする。

アプリケーション提供サーバ１４０は、アプリケーション・メタ情報検索部１４１、アプリケーション蓄積部１４２、アプリケーション本体配信部１４３、及びネットワークＩＦ１４４の各機能ブロックを有して構成される。

アプリケーション・メタ情報検索部１４１は、クライアント端末１００からアプリケーションに関するメタ情報の取得要求を受付け、指定されたアプリケーション取得条件に基づいて、アプリケーション蓄積部１４２から取得するアプリケーション・メタ情報の検索を行い、検索されたメタ情報をクライアント端末１００へ配信する。

アプリケーション蓄積部１４２は、アプリケーション本体とアプリケーション本体に関連づけられたメタ情報を管理する。アプリケーション本体配信部１４３は、クライアント端末１００から指定されたアプリケーション本体をアプリケーション蓄積部１４２から取得し、クライアント端末１００へ配信する。

ネットワークＩＦ１４４は、アプリケーション・メタ情報検索部１４１とアプリケーション本体配信部１４３とが、宅外ネットワーク１３０を介して通信する際のインタフェースである。なお、以降の説明では、特に記載はしないが、アプリケーション提供サーバ１４０とクライアント端末１００との間での通信は、全てネットワークＩＦ１４４を経由するものとする。

次に動作について説明する。
図２は、実施の形態１のアプリケーション提供システムによる動作の流れを示すシーケンス図であり、この図に沿って説明する。
クライアント端末１００のネットワーク情報端末管理部１０１は、宅内ネットワーク１１０上に宅内端末が存在するか否かを確認し、存在を確認した宅内端末へ端末情報取得要求を送信し（ステップＳＴ２０１）、該宅内端末からの応答としてその端末情報を受信する（ステップＳＴ２０２）。

宅内ネットワーク１１０上に宅内端末が存在するか否かの確認方法としては、ユーザからの要求により確認するか、自ら定期的に確認するか、或いは宅内端末が発信する宅内ネットワーク１１０における自らの存在を示すイベント通知を受信して宅内端末の存在を確認する。

なお、図２の例では、宅内端末１２０に対してのみ端末情報取得要求を送信して端末情報を取得する場合を示しているが、他の宅内端末１２１や宅内端末１２２に対して、それぞれステップＳＴ２０１の処理とステップＳＴ２０２の処理を繰り返して各宅内端末の端末情報を取得するようにしても良い。

ここで、宅内端末の端末情報について説明する。
図３は、宅内端末の端末情報の一例を示す図である。図３において、宅内端末の端末情報は、端末番号３０１、端末名３０２、端末タイプ３０３、端末ＩＤ３０４、端末制御用アドレス３０５、及びサービス３０６の各項目から構成される。また、サービス３０６は、サービス定義３０７、配信可能コンテンツフォーマット３０８、及び同時配信可能数３０９を含む。

端末番号３０１は、ネットワーク端末情報管理部１０１が使用する内部管理用の端末番号である。端末名３０２は、各宅内端末の名前を規定する情報である。端末タイプ３０３は、各宅内端末の機能タイプを規定する情報であり、図３の例では、コンテンツ・サーバを示している。端末ＩＤ３０４は、宅内ネットワーク１１０において個々の宅内端末を一意に識別するためのＩＤ情報である。

端末制御用アドレス３０５は、各宅内端末のネットワーク上のアドレス情報である。サービス３０６は、宅内端末が提供するサービスが設定される。サービス定義３０７には、具体的なサービス名やサービスを利用する際に求められるパラメータなどが定義される。

配信可能コンテンツフォーマット３０８は、コンテンツ配信サービスに関連付けられた配信可能なコンテンツのフォーマットが設定される。同時配信可能数３０９は、配信可能コンテンツフォーマット３０８で規定されるフォーマットの情報を最大で幾つ同時に配信可能かを示す同時配信可能数が設定される。

なお、図３に示す端末ＩＤ３０４は、ネットワークＩＦ１０８がイーサネット（登録商標）である場合の例を示しており、ネットワークＩＦ１０８を構成するハードウェアに固有のＭＡＣ（Media Access Control）アドレスが端末ＩＤとして用いられている。また、端末制御用アドレス３０５は、ＨＴＴＰ（Hyper Text Transfer Protocol）を用いて制御される例を示している。

クライアント端末１００は、サービス３０６に示されたサービスを利用することができ、サービスを利用する際には端末制御用アドレス３０５によって特定されるアドレスに対して、サービス定義３０７によって定義されるサービスに適切なパラメータを設定した上で、ＨＴＴＰメッセージを送信することにより、当該サービスを利用することができる。

ここで、サービス３０６に記述されている複数のサービスにおいて、サービス名に続く括弧の中にコンマで区切られて列挙されているのがパラメータであり、それぞれＩＮと記述されているのが入力、ＯＵＴと記述されているのが出力である。サービスの利用時には、ＩＮに所望のパラメータを設定し、そのサービスの応答においてＯＵＴに記述された出力を得る。

図３に示す端末情報では、それぞれ端末番号３０１が“１”、“２”の宅内端末であるリビングのＤＶＤレコーダ及び書斎のＰＣに関する情報が示されている。これら２つの宅内端末は、共に映像をストリーミングにより配信する“コンテンツ・サーバ”タイプの端末であり、サービス定義３０７には併せて以下の４種類のサービスが定義されている。
（１）コンテンツメタデータ取得
（２）コンテンツ配信_地上デジタルライブ放送
（３）コンテンツ配信_ＢＳデジタルライブ放送
（４）コンテンツ配信_蓄積コンテンツ

これらのサービスをクライアント端末１００が使用する際には、先ず（１）コンテンツメタデータ取得サービスによりコンテンツのメタデータを取得し、（２）、（３）、（４）のそれぞれのコンテンツ配信サービスに対して、メタデータの中に含まれるコンテンツアドレスを与える。これによりそれぞれのコンテンツのストリーミング配信を利用できる。なお、（２）、（３）は、それぞれ現在放送中のライブ放送のストリームを配信し、（４）は予め端末に蓄積され保存された蓄積コンテンツのストリーミングを配信するサービスである。

また、例えば端末番号３０１が“１”であるＤＶＤレコーダのサービス３０６において、“コンテンツ配信_地上デジタルライブ放送”サービスに関して、配信可能コンテンツフォーマット３０８が“ＭＰＥＧ−２ ＴＳ”、同時配信可能数３０９が“２”と記されている。これは、地上デジタル放送においてライブ放送中のＭＰＥＧ−２ ＴＳフォーマットによるストリームを、２チャンネル分独立して配信可能ということを示している。

図２の説明に戻ると、ネットワーク情報管理部１０１は、端末情報が更新された旨を、更新された端末情報と共に端末能力マッチング部１０２へ通知する（ステップＳＴ２０３）。端末能力マッチング部１０２では、クライアント端末１００としてソフトウェア及びハードウェアを含めた端末としての能力を管理しており、管理している端末能力と、ネットワーク端末情報管理部１０１から通知された宅内ネットワーク１１０上の端末情報との比較を行い、どのようなサービスを利用できるかのマッチングを行う（ステップＳＴ２０４）。

ここで、端末能力マッチング部１０２が管理するクライアント端末１００の能力を示す自クライアント端末能力について説明する。
図４は、端末能力マッチング部が管理する自クライアント端末能力の一例を示す図である。図４において、自クライアント端末能力４００は、大きく分けてクライアント端末ソフトウェアバージョン４０１及び制御可能サービス４０２の各項目から構成されている。また、制御可能サービス４０２には、サービス名４０３、デコード可能コンテンツフォーマット４０４、及び同時デコード可能数４０５の各項目の情報から構成される。

クライアント端末ソフトウェアバージョン４０１は、アプリケーション本体を実行する主体となるアプリケーション実行部１０６や端末制御部１０７の機能を表すソフトウェア基盤のバージョン番号であり、バージョン番号毎にアプリケーションが使用できるＡＰＩが規定される。制御可能サービス４０２は、クライアント端末１００がそのサービスを認識して制御することが可能なサービスを規定する情報であり、以下の情報から構成される。

サービス名４０３には、制御可能サービス４０２のサービス名が設定される。デコード可能コンテンツフォーマット４０４は、コンテンツ配信サービスを利用する際にクライアント端末１００がデコードすることが可能なフォーマットである。同時デコード可能数４０５は、クライアント端末１００においてデコード可能コンテンツフォーマット４０４に設定された情報を最大で幾つ同時にデコード可能かを示す情報である。

次に、マッチング結果について説明する。
図５は、端末能力マッチング部によるマッチング処理を行った結果として得られるアプリケーション取得条件の一例を示す図である。図５において、アプリケーション取得条件５００は、ステップＳＴ２０４において、端末能力マッチング部１０２がサービス３０６と自クライアント端末能力４００とを比較してマッチング処理することにより得られる。このアプリケーション取得条件は、アプリケーションの実行に対する制約となる条件である。

図５に示すアプリケーション取得条件５００は、クライアント端末ソフトウェアバージョン５０１及び利用可能サービス５０２の各項目の情報から構成される。また、利用可能サービス５０２は、サービス名５０３、デコード可能コンテンツフォーマット５０４及び同時デコード可能数５０５の各情報から構成される。図５の例では、マッチングの結果、端末情報におけるサービス３０６のうち、ＢＳデジタル放送ライブ配信を除く下記２つのサービスが利用可能であることが検出されている。
（１ａ）コンテンツメタデータ取得
（２ａ）コンテンツ配信_地上デジタルライブ放送

特に、“コンテンツ配信_地上デジタルライブ放送”サービスに関しては、端末番号３０１が“１”のＤＶＤレコーダから２つ、端末番号３０１が“２”の書斎ＰＣから１つのサービスを利用可能で計３つのサービスを利用可能であることから、同時デコード可能数５０５には“３”と記載されている。すなわち、クライアント端末１００は、“コンテンツ配信_地上デジタルライブ放送”サービスから得られる３つのストリームを同時にデコードすることができることが検出されている。

ここで、ステップＳＴ２０４において実施される端末能力マッチング処理を図６のフローチャートを用いて詳細に述べる。ここで、具体的に述べるのは、各端末から取得したサービス３０６の情報と、クライアント端末１００の能力を示す自クライアント端末能力４００とから、どのようにアプリケーション取得条件５００を求めるかということである。

先ず、端末能力マッチング部１０２は、クライアント端末ソフトウェアバージョン４０１の設定情報（図４の例では、バージョン１．２）をクライアント端末ソフトウェアバージョン５０１として登録する（ステップＳＴ６０１）。次に、サービス３０６中の各サービスを順にチェックしていく。サービス３０６中の全てのサービスをチェックしたら処理を完了する（ステップＳＴ６０２）。選択されたサービス３０６中のサービスに対して、制御可能サービス４０２中の各サービスを順にチェックしていく。

ある選択されたサービス３０６中のサービスに対して、制御可能サービス４０２中の全てのサービスについてチェックを完了したら、次のサービス３０６中のサービスをチェックするためステップＳＴ６１２の処理へ進む（ステップＳＴ６０３）。

制御可能サービス４０２にまだチェックしていないサービスが残っていたら、次にサービス定義３０６中のサービス名とサービス名４０３が一致しているか否かを調べる（ステップＳＴ６０４）。ここで、一致していなかったら、端末能力マッチング部１０２は、次の制御可能サービス４０２を調べるためにステップＳＴ６１１の処理へ進み、一致していたら、ステップＳＴ６０５の処理へ進む。

ステップＳＴ６０５において、端末能力マッチング部１０２は、配信コンテンツフォーマット３０８とデコ−ド可能コンテンツフォーマット４０４が一致しているか否かを調べる。このとき、一致していなかったら、ステップＳＴ６１１の処理へ進む。また、一致していたら、同時配信可能数３０９に設定される数値が同時デコード可能数４０５に設定されている数値以下であるという関係が成り立つか否かを判定する（ステップＳＴ６０６）。

ステップＳＴ６０６の判定において上記関係が成り立っていなかったら、ステップＳＴ６１１の処理へ進む。上記関係が成り立っていたら、端末能力マッチング部１０２は、自クライアント端末１００が当該サービスを制御でき、かつ配信可能コンテンツフォーマットをデコードできる能力を持っていると判断し、ステップＳＴ６０７の処理に進む。

ステップＳＴ６０７において、端末能力マッチング部１０２は、下記式（１）によって同時デコード可能数４０５を更新し、同時配信可能数３０９に設定された数値分だけクライアント端末１００におけるデコード能力が割り当てられたことを管理する。
同時デコード可能数４０５←同時デコード可能数４０５−同時配信可能数３０９ ・・・（１）

次に、現在登録を試みているサービス名４０３のサービスが既に利用可能サービス５０２に登録されているかどうかをチェックする（ステップＳＴ６０８）。このとき、登録されていたら、下記式（２）によって予め登録されていた同時デコード可能５０５の数値に新たにマッチングがとれた同時配信可能数３０９に設定されている数値を加えて同時デコード可能５０５の値を更新する（ステップＳＴ６０９）。
同時デコード可能数５０５←同時デコード可能数５０５＋同時配信可能数３０９ ・・・（２）

一方、登録されていなかったら、端末能力マッチング部１０２は、サービス名４０３、デコード可能コンテンツフォーマット４０４及び同時デコード可能数４０５を、それぞれサービス名５０３、デコード可能コンテンツフォーマット５０４及び同時デコード可能数５０５として利用可能サービスへ登録する（ステップＳＴ６１０）。ステップＳＴ６０９あるいはステップＳＴ６１０の処理が完了したら、ステップＳＴ６１１の処理へ進み、次の制御可能サービスをチェックする。

なお、上述の端末能力マッチング処理は、映像コンテンツのストリーミング配信、及びストリーミング配信される映像コンテンツのデコードを例に挙げて説明したが、必ずしも端末能力のマッチング処理はこの例に限定されるものではない。例えば、画像や音楽コンテンツの配信サービスとクライアント端末１００側におけるデコード能力のマッチング、ゲームコンテンツの配信サービスとクライアント端末１００側におけるゲームの実行能力のマッチング、メール配信サービスとクライアント端末１００側におけるメール受信能力のマッチング、などの汎用的に各宅内端末が提供するサービスと自クライアント端末１００の能力のマッチングを取るようにしてもよい。

端末能力マッチング部１０２は、以上に詳細を述べたステップＳＴ２０４の端末能力マッチング処理によって取得したアプリケーション取得条件５００を、アプリケーション・メタ情報取得部１０３へ通知する（ステップＳＴ２０５）。

アプリケーション・メタ情報取得部１０３は、次にアプリケーション提供サーバ１４０のアプリケーション・メタ情報検索部１４１に対してアプリケーション取得条件５００にマッチするアプリケーション・メタ情報の取得を要求する（ステップＳＴ２０６）。図７は、ステップＳＴ２０６でアプリケーション提供サーバ１４０側へ送信されるアプリケーション・メタデータ検査要求の一例を示す図である。図７の例では、ＳＯＡＰ（Simple Object Access Protocol）に従ったデータ態様で、アプリケーション取得条件５００がＸＭＬ（eXtensible Markup Language）文書として構成されている。

なお、クライアント端末ソフトウェアバージョン５０１は、図７中の“ＣｌｉｅｎｔＳｏｆｔｗａｒｅＶｅｒｓｉｏｎ”、利用可能サービス５０２は図７中の“ＡｖａｉｌａｂｌｅＳｅｒｖｉｃｅｓ”というタグ名で囲まれた部分に表記されている。利用可能サービス５０２の各要素であるサービス名５０３、デコード可能コンテンツフォーマット５０４及び同時デコード可能数５０４は、図７中のタグ名“ＡｖａｉｌａｂｌｅＳｅｒｖｉｃｅｓ”で囲まれた部分に表記される文字列において、それぞれ“：”で区切られて表記される。また、未定義情報は“＊”で表記されている

アプリケーション・メタ情報検索要求７００を受信したアプリケーション提供サーバ１４０内部のアプリケーション・メタ情報検索部１４１は、先ず、クライアント端末１００から受信したアプリケーション・メタ情報検索要求７００に含まれるＸＭＬ文書を解析して、アプリケーション取得条件５００を抽出する。次に、アプリケーション・メタ情報検索部１４１は、アプリケーション蓄積部１４３に対してアプリケーション・メタ情報取得要求を送信し、アプリケーション提供サーバ１４０で管理されるアプリケーションのメタ情報を要求する（ステップＳＴ２０７）。

アプリケーション蓄積部１４３は、アプリケーション・メタ情報検索部１４１からの要求の内容によって、自らが管理するアプリケーション・メタ情報の一部、或いは全てをアプリケーション・メタ情報検索部１４１へ送信する（ステップＳＴ２０８）。次に、アプリケーション・メタ情報検索部１４１は、既に抽出したアプリケーション取得条件５００を用いてアプリケーション・メタ情報の検索を行い（ステップＳＴ２０９）、図８に示すようなアプリケーション・メタ情報８００を得る。

図８に示すアプリケーション・メタ情報は、ＩＤ８０１、カテゴリ８０２、アプリケーション名８０３、アプリケーション本体取得用アドレス８０４、サムネイル取得用アドレス８０５、クライアント端末要件８０６、説明８０７及び人気度８０８の各項目の情報から構成される。

ここで、ＩＤ８０１は、各アプリケーション・メタ情報を識別するための各情報に固有なＩＤである。カテゴリ８０２は、アプリケーションが属するカテゴリを示す情報が設定される。アプリケーション名８０３は、アプリケーションに設定されたアプリケーション名を示す。アプリケーション本体取得用アドレス８０４には、アプリケーション本体を取得するためのネットワーク上のアドレスが設定される。サムネイルの取得用アドレス８０５は、アプリケーションのＧＵＩイメージを参照するための小型画像のネットワーク上のアドレスである。

クライアント端末要件８０６は、アプリケーションを動作させる際にクライアント端末１００上において必要となる要件が設定される。説明８０７には、アプリケーションに関する説明が設定される。人気度８０８は、アプリケーションのダウンロード数などに基づいてアプリケーション提供サーバ１４０が独自に割り付けた人気度である。

ステップＳＴ２０９において、図７に示すアプリケーション・メタデータ検索要求７００に基づく検索処理は、クライアント端末要件８０６に記載された情報を対象として実行される。なお、クライアント端末要件８０６の利用可能サービスの一つである“コンテンツ配信＿＊”は、コンテンツ配信サービスであれば、何でも要件を満たすことを示しており、例えば、コンテンツ配信_地上デジタルライブ放送、コンテンツ配信_ＢＳデジタルライブ放送、コンテンツ配信_蓄積コンテンツのいずれのコンテンツ配信サービスでも、検索時には一致すると判定される。

上述では、アプリケーション・メタ情報取得条件５００を検索キー、クライアント端末要件８０６を検索対象としてアプリケーション・メタ情報を検索する例を示したが、必ずしもクライアント端末要件８０６のみを検索対象とする必要はなく、ユーザが明示的に自ら好む下記の情報（１ｂ）、（２ｂ）、（３ｂ）を指定して、それぞれの情報をアプリケーション・メタデータ検索要求７００に含めるようにしても良い。
（１ｂ）アプリケーションのカテゴリ
（２ｂ）任意のキーワード
（３ｂ）人気度

この場合、アプリケーション・メタ情報検索部１４１は、それぞれアプリケーション・メタ情報８００におけるカテゴリ８０２、アプリケーション名８０３、説明８０７や人気度８０８を検索対象として検索を行う。また、アプリケーション・メタ情報８００として、アプリケーション本体が実行時に参照する情報提供サーバ１５０が提供するサービスも同様に管理しておき、ユーザがそのサービスを指定して検索を行うようにしても良い。

検索されたアプリケーション・メタ情報８００は、アプリケーション・メタ情報検索部１４１によって、図９に示すアプリケーション・メタデータ検索応答９００としてＸＭＬ文書化され、アプリケーション・メタ情報に検索要求に対する応答として、クライアント端末１００のアプリケーション・メタ情報取得部１０３へ送信される（ステップＳＴ２１０）。

アプリケーション・メタ情報取得部１０３は、アプリケーション・メタ情報検索応答を受信すると、ＸＭＬ文書として受信したアプリケーション・メタ情報検索応答９００を解析し、アプリケーション・メタ情報８００を抽出して保存する。ここで、アプリケーション・メタ情報検索部１４１が検索した結果であるアプリケーション・メタ情報８００は、アプリケーション・メタ情報取得部１０３において完全に同一の情報を復元可能であるものとし、アプリケーション・メタ情報取得部１０３が取得し保存したメタ情報もアプリケーション・メタ情報８００として参照されるものとする。アプリケーション・メタ情報取得部１０３は、アプリケーション・メタ情報８００と共に、アプリケーション・メタ情報８００を取得した旨をアプリケーション選択部１０４へ通知する（ステップＳＴ２１１）。

アプリケーション選択部１０４は、アプリケーション・メタ情報８００からアプリケーション選択用ＧＵＩ画面を構成する。図１０は、アプリケーション選択用ＧＵＩの一例を示す図である。図１０において、アプリケーション選択用ＧＵＩ１０００は、アプリケーション名１００１、カテゴリ１００２、星表示１００３、説明１００４、サムネイル１００５及びカーソル１００６が表示される。

ここで、アプリケーション名１００１としては、アプリケーション名８０３から取得した情報が表示される。また、カテゴリ１００２には、カテゴリ８０２から取得した情報が表示される。星表示１００３とは、人気度８０８から取得した情報に基づいて設定されたアプリケーションの人気度を星の数で図示している。説明１００４は、説明８０７から取得した情報を表示する。サムネイル１００５は、サムネイル取得用アドレス８０５を参照してクライアント端末１００が取得する画像である。カーソル１００６は、ユーザが選択中であるアプリケーションを図示するものである。

ユーザは、図１０に示すように分かりやすく表示されたアプリケーション一覧を眺めながら、自らの好みのアプリケーションを選択できる。ユーザによってある１つのアプリケーションが選択されると（ステップＳＴ２１２）、アプリケーション選択部１０４は、選択されたアプリケーションに対応するアプリケーション本体用取得アドレス８０４と共に、アプリケーション選択通知をアプリケーション本体取得部へ送信する（ステップＳＴ２１３）。

アプリケーション本体取得部１０５は、取得したアプリケーション本体取得用アドレス８０４から、図１１に示すようなアプリケーション本体取得要求１１００を生成し、アプリケーション提供サーバ１４０へ送信する（ステップＳＴ２１４）。アプリケーション提供サーバ１４０のアプリケーション本体配信部１４２は、アプリケーション本体取得要求１１００を受信すると、取得したアプリケーション本体取得要求１１００を解析して、所望のアプリケーション本体がアプリケーション蓄積部１４３のどこにあるかを特定し、アプリケーション本体をアプリケーション蓄積部１４３に対して要求する（ステップＳＴ２１５）。

アプリケーション蓄積部１４３では、アプリケーション本体配信部１４２から送信されたアプリケーション本体取得要求を参照して、アプリケーション本体を特定し、アプリケーション本体配信部１４２へアプリケーション本体を送信する（ステップＳＴ２１６）。所望のアプリケーション本体を受けとったアプリケーション本体配信部１４２は、ステップＳＴ２１４において受信したアプリケーション本体取得要求に対する応答として、図１２に示すようなアプリケーション本体を含むアプリケーション本体取得応答１２００を構成し、クライアント端末１００へアプリケーション本体を送信する（ステップＳＴ２１７）。

なお、上述の説明では、ユーザが選んだ１つのアプリケーションを選択した例を示したが、ステップＳＴ２１２においてユーザが複数のアプリケーションを一度に選択し、ステップＳＴ２１４からステップＳＴ２１７までの処理を複数回繰り返して、複数のアプリケーションを一度に取得しても良い。

ユーザによって選択されたアプリケーション本体を取得したアプリケーション本体取得部１０５は、アプリケーション本体を取得したことをアプリケーション本体と共にアプリケーション実行部１０６へ通知する（ステップＳＴ２１８）。アプリケーション本体を取得したアプリケーション実行部１０６は、アプリケーション本体を実行する（ステップＳＴ２１９）。

アプリケーション本体がＧＵＩ等の画面表示を伴うものである場合、例えば図１３に示すようなＧＵＩ画面を起動する。図１３に示す３Ｄ的な表示が可能なコンテンツのザッピング用アプリケーション１３００では、宅内ネットワーク１１０を通じて宅内端末が提供するコンテンツ配信サービスから配信されるストリームを受信し、クライアント端末１００によってデコードされ、画面表示を行う。

ユーザは、図示しないリモコンによって本アプリケーションを操作可能であり、例えば３Ｄ表示ザッピングアプリケーション１３００において、現在ＣＨ１（画面手前）→ＣＨ２→ＣＨ３→ＣＨ４→ＣＨ５（画面後ろ）と順に画面手前から並んでいる。このように各チャンネルの動画が表示される状態で、例えばリモコンの右方向ボタンを押下すると、チャンネルの並びが、ＣＨ２（画面手前）→ＣＨ３→ＣＨ４→ＣＨ５→ＣＨ１（画面後ろ）と変化し、また左ボタンを押下した場合には、チャンネルの並びが、ＣＨ５（画面手前）→ＣＨ１→ＣＨ２→ＣＨ３→ＣＨ４（画面後ろ）などと変化することにより、ザッピングが行える。

なお、図５に示すアプリケーション取得条件５００では、“コンテンツ配信_地上デジタルライブ放送”サービスによって配信されるＭＰＥＧ−２ ＴＳフォーマットのストリームが３つ同時にデコード可能であるとの条件が指定されている。従って、図８に示すアプリケーション・メタ情報８００に示されるアプリケーション・メタ情報の検索結果は、３Ｄ表示ザッピングアプリケーション１３００のクライアント端末要件８０６を満たしている。

一方、図１３における３Ｄ表示ザッピングアプリケーション１３００では、実際に起動された３Ｄ表示ザッピングアプリケーションとして、５つの画面（ＣＨ１〜ＣＨ５）が同時にデコードされる例が示されている。このような場合、アプリケーション開発者は、提供するアプリケーションが対応する最大限の機能（５つの画面同時デコード）をクライアント端末要件８０６として設定するのではなく、アプリケーションが意図したレベルで動作する最低限の機能（例えば、３つの画面同時デコード）をクライアント端末要件として設定し、アプリケーション実行部１０６が、端末能力マッチング部１０２からアプリケーション取得条件５００を取得して、自クライアント端末１００の能力に合わせてアプリケーション本体を設定するようにしてもよい。

アプリケーション実行部１０６は、アプリケーション・メタ情報８００が取得され、クライアント端末ソフトウェアバージョン５０１が指定された上で、アプリケーション本体を取得し実行する。これにより、アプリケーション本体が呼び出すＡＰＩは、全て実行可能なことが保証されている。

アプリケーション実行部１０６は、アプリケーション本体を実行するにあたり、ＧＵＩ画面の遷移等のクライアント端末１００に閉じた処理を行う場合、端末制御部１０７に端末制御要求を行う（ステップＳＴ２２０）。これに応じて、端末制御部１０７は、自クライアント端末１００を適切に制御する処理を行い（ステップＳＴ２２１）、この処理結果を制御応答としてアプリケーション実行部１０６へ送信する（ステップＳＴ２２２）。

また、アプリケーション・メタ情報８００のクライアント端末要件８０６に記載されたサービスを利用する場合、アプリケーション実行部１０６は、宅内端末１２０へサービス要求を送信し（ステップＳＴ２２３）、その応答を取得してサービスを利用する（ステップＳＴ２２４）。

アプリケーション実行部１０６は、アプリケーション本体の実行に際して情報提供サーバ１５０が提供する様々なサービスを利用する場合、情報提供サーバ１５０へサービス要求を送信し（ステップＳＴ２２５）、その応答を取得してサービスを利用する（ステップＳＴ２２６）。
なお、図２に示す下記（１ｃ）、（２ｃ）、（３ｃ）の処理ステップは、アプリケーション本体の実行手順によって実際には順不同に実施されるものであり、必ずしも図２に示した順序で実行される必要は無い。
（１ｃ）ステップＳＴ２２０〜ステップＳＴ２２２
（２ｃ）ステップＳＴ２２３、ステップＳＴ２２４
（３ｃ）ステップＳＴ２２５、ステップＳＴ２２６

以上のように、この実施の形態１によれば、ユーザがクライアント端末１００を介して、宅内ネットワーク１１０上に分散している各宅内端末１２０〜１２２が提供するサービスを複合して利用するアプリケーションを面倒な設定をすることなく実行することができる。また、クライアント端末１００では、アプリケーション提供サーバ１４０が提供するアプリケーションに関するメタ情報を参照しながら、好みのアプリケーションを選択、取得した後に実行するので、常に新しいＧＵＩや新しい機能を有するアプリケーションを使用することができる。

実施の形態２．
図１４は、この発明の実施の形態２によるアプリケーション提供システムの構成を示すブロック図である。なお、図１４において、図１と同一又はこれに相当する構成要素には、同一符号を付して重複する説明を省略する。実施の形態２によるアプリケーション提供システムでは、クライアント端末１４００が、ネットワークＩＦ１４０３，１４０４を介して宅内ネットワーク１４１０，１４２０に接続している。

宅内ネットワーク１４１０は、通信プロトコルＡで通信が行われ、宅内端末１４１１〜１４１３が接続される。また、宅内ネットワーク１４２０は、通信プロトコルＡとは異なる通信プロトコルＢで通信が行われ、宅内端末１４２１〜１４２３が接続される。

端末制御部１４０１は、ネットワーク端末情報管理部１４０２から宅内ネットワーク１４１０，１４２０にそれぞれ接続された各宅内端末の端末情報を取得し、各宅内端末に対して適切なプロトコルを選択して制御を行う。ネットワーク端末情報管理部１４０２は、宅内ネットワーク１４１０，１４２０にそれぞれ接続された宅内端末の端末情報を取得し管理する。

ネットワークＩＦ１４０３は、端末制御部１４０１、ネットワーク端末情報管理部１４０２、アプリケーション・メタ情報取得部１０３及びアプリケーション本体取得部１０５が、宅内ネットワーク１４１０を介して通信する際のインタフェースである。ネットワークＩＦ１４０４は、端末制御部７０１、ネットワーク端末情報管理部１４０２が、宅内ネットワーク１４２０を介して通信する際のインタフェースである。

次に動作について説明する。
図１５は、実施の形態２のアプリケーション提供システムによる動作の流れを示すシーケンス図であり、この図に沿って説明する。なお、上記実施の形態１と同様に処理されるステップに関しては、同一のステップ番号を付して重複説明を省略する。

先ず、ネットワーク端末情報管理部１４０２は、宅内ネットワーク１４１０，１４２０上にある宅内端末が存在するか否かを確認し、存在を確認した宅内端末へ端末情報取得要求を送信する（ステップＳＴ１５０１、ステップＳＴ１５０３）。

宅内ネットワーク１４１０，１４２０上に宅内端末が存在するか否かの確認方法としては、ユーザからの要求により確認するか、自ら定期的に確認するか、或いは宅内端末が発信する宅内ネットワーク１４１０，１４２０における自らの存在を示すイベント通知を受信して宅内端末の存在を確認する。

図１５に示す例では、ネットワーク端末情報管理部１４０２が、宅内端末１４１１の存在を先に確認し、宅内端末１４１１へ端末情報取得要求を送信（ステップＳＴ１５０１）し、その応答として宅内端末１４１１から端末情報を受信する（ステップＳＴ１５０２）。この後、宅内端末１４２１の存在を確認し、宅内端末１４２１へ端末情報取得要求を送信（ステップＳＴ１５０３）し、その応答として宅内端末１４１１から端末情報が受信される（ステップＳＴ１５０４）。ここで、宅内端末１４１１と宅内端末１４２１は、それぞれ異なる通信プロトコルに対応する端末であり、ネットワーク端末情報管理部１４０２は、これらの端末情報を取得する際においても、それぞれ通信プロトコルを使い分けて通信する。

図１６は、実施の形態２による宅内端末の端末情報の一例を示す図であり、ステップＳＴ１５０２及びステップＳＴ１５０４の処理において、ネットワーク端末情報管理部１４０２がそれぞれ取得する端末情報の一例を示している。図１６に示すように、該端末情報は、端末番号３０１、通信プロトコル１６０１、端末名３０２、端末タイプ３０３、端末ＩＤ３０４、端末制御用アドレス３０５、及びサービス３０６の各項目から構成される。通信プロトコル１６０１には、端末情報を提供した宅内端末が対応する通信プロトコルが設定される。この他の情報は、上記実施の形態１で示したものと同様であるので説明を省略する。

以降の説明では、端末番号３０１が“１”の端末情報は、宅内端末１４１１から取得したものであり、端末番号３０１が“２”の端末情報は、宅内端末１４２１から取得したものとする。また、端末能力マッチング部１０２において端末能力マッチングの対象となるサービス３０６に関しては、通信プロトコルの違いによらずに意味的に正しい比較が行えるよう、予めサービス定義３０７、配信可能コンテンツフォーマット３０８、同時配信可能数３０９などの情報を汎用的に取り扱えるよう変換した上で、端末情報として登録する。

図１５におけるステップＳＴ２０３〜ステップＳＴ２１９までの処理は、上記実施の形態１で示したものと同様であるので説明を省略する。宅内ネットワーク１４１０を介して、クライアント端末１００は、アプリケーション提供サーバ１４０と通信を行い、上記実施の形態１と同様の処理によってアプリケーション・メタ情報及びアプリケーション本体を取得する。

ステップＳＴ２１９において、アプリケーション実行部１０６は、アプリケーション本体を実行するにあたり、宅内ネットワーク上の宅内端末のサービスを使用する処理についても、端末制御部１４０１に処理を要求する（ステップＳＴ１５０５）。端末制御部１４０１は、制御対象となっている宅内端末を識別し、ネットワーク端末情報管理部１４０２へ当該宅内端末の端末情報の取得を要求する。

図１５の例では、宅内端末１４１１に対する制御が要求されており、端末制御部１４０１は、ネットワーク端末情報制御部１４０２へ宅内端末１４１１の端末情報を要求し（ステップＳＴ１５０６）、その応答として宅内端末１４１１の端末情報が端末制御部１４０１へ送信される（ステップＳＴ１５０７）。端末制御部１４０１は、宅内端末１４１１の端末情報のうち通信プロトコル１６０１に設定される情報を取得して、宅内端末１４１１との間における通信プロトコルが通信プロトコルＡであることを認識し、該通信プロトコルＡに従って宅内端末１４１１へサービスを要求する（ステップＳＴ１５０８）。

宅内端末１４１１では、通信プロトコルＡに従ってサービス応答を送信する（ステップＳＴ１５０９）。端末制御部１４０１は、通信プロトコルＡに従って受信したサービス応答を実行中のアプリケーションが理解できるように予め定められた汎用的な形式に変換し、アプリケーション実行部１０６へ端末制御応答として出力する（ステップＳＴ１５１０）。

なお、図１５におけるステップＳＴ１５１１からステップＳＴ１５１６までの各処理も、上述と同様にして宅内端末１４２１との間で通信プロコトルＢに従った通信により、宅内端末１４２１に対するサービス要求やその応答が行われる。また、ステップＳＴ２２５及びステップＳＴ２２６の処理に関しては、上記実施の形態１と同様であるので説明を省略する。

以上のように、この実施の形態２によれば、ユーザが管理するクライアント端末１００に異なる通信プロトコルで通信する異なる複数の宅内端末が接続されている場合であっても、宅内端末の端末情報として通信プロトコルを登録しておくことにより、通信プロトコルの差異に応じた通信によりクライアント端末１００が宅内端末からサービスの提供を受ける。これにより、ユーザは、通信プロトコルの差異を気にすることなく、異なる宅内端末のサービスを複合して利用するアプリケーションを実行することができる。また、アプリケーションの開発者にとっては、異なる通信プロトコル用のアプリケーションを別々に開発する必要がなくなるので、効率的にアプリケーション開発を行うことが可能となる。

以上のように、この発明に係るアプリケーション提供システムでは、ユーザが管理するクライアント端末において、ネットワーク上の各端末の機能を利用するアプリケーションやユーザインタフェースを容易に選択し実行することができるので、テレビ向けポータルサイトのような外部ネットワーク上の端末との連携によりアプリケーションが実行されるシステムに適している。

Claims (6)

1. 宅内ネットワークに接続された宅内端末から、該宅内端末が提供するサービスを規定する情報を含む端末情報を取得して管理するネットワーク端末情報管理部と、
   自端末によるサービスの処理能力を規定する情報と前記ネットワーク端末情報管理部により前記宅内端末から取得された端末情報とを比較して、これら情報から自端末で前記宅内端末より提供されたサービスを利用する際に実行されるアプリケーションの取得条件を抽出する端末能力マッチング部と、
   前記端末能力マッチング部が抽出したアプリケーションの取得条件に基づいて、宅外ネットワーク上のアプリケーション提供サーバから前記アプリケーションに関するメタ情報を取得するアプリケーション・メタ情報取得部と、
   前記アプリケーション・メタ情報取得部により取得されたメタ情報をユーザへ提示し、ユーザからのアプリケーション選択を受け付けるアプリケーション選択部と、
   前記アプリケーション選択部で指定されたアプリケーション本体を、前記宅外ネットワーク上のアプリケーション提供サーバから取得するアプリケーション本体取得部とを備えたクライアント端末。
2. アプリケーション本体取得部によって取得されたアプリケーション本体を実行するアプリケーション実行部と、
   前記アプリケーション実行部からの指示によって自端末によるアプリケーションの実行動作及び宅内端末からのサービス提供を制御する端末制御部とを備えたことを特徴とする請求項１記載のクライアント端末。
3. アプリケーション・メタ情報取得部は、アプリケーションの取得条件として、前記アプリケーションのカテゴリ、任意のキーワード、人気度、及び、前記アプリケーションを実行する際に宅外ネットワークに接続された情報提供サーバから提供されるサービスの組み合わせを含む情報を端末能力マッチング部から取得し、該アプリケーションの取得条件に基づいてアプリケーション提供サーバから前記アプリケーションに関するメタ情報を取得することを特徴とする請求項１に記載のクライアント端末。
4. 異なる通信プロトコルによって通信が行われる複数の異なる宅内端末に接続される場合、
   ネットワーク端末情報管理部は、前記宅内端末の端末情報において該宅内端末に対応する通信プロトコルの識別情報を登録して管理し、
   端末制御部は、前記ネットワーク端末情報管理部から制御対象の宅内端末に対応した通信プロトコルの識別情報を取得し、アプリケーション実行部からの指示を該通信プロトコルに従うデータ態様に変換して送信することにより、前記宅内端末からのサービス提供を制御することを特徴とする請求項２記載のクライアント端末。
5. アプリケーション本体、及び該アプリケーション本体に関連づけて該アプリケーションに関するメタ情報を蓄積し管理するアプリケーション蓄積部と、
   クライアント端末から通知されたアプリケーションの取得条件に基づいて、前記アプリケーション蓄積部から該取得条件に一致するメタ情報を検索し、前記クライアント端末へ該取得条件に一致するメタ情報を配信するアプリケーション・メタ情報検索部と、
   前記クライアント端末から要求されたアプリケーション本体を前記アプリケーション蓄積部から取得し、該要求元のクライアント端末へ配信するアプリケーション本体配信部とを備えたアプリケーション提供サーバ。
6. 請求項１記載のクライアント端末と、
   アプリケーション本体、及び該アプリケーション本体に関連づけて該アプリケーションに関するメタ情報を蓄積し管理するアプリケーション蓄積部と、前記クライアント端末から通知されたアプリケーションの取得条件に基づいて、前記アプリケーション蓄積部から該取得条件に一致するメタ情報を検索し、前記クライアント端末へ該取得条件に一致するメタ情報を配信するアプリケーション・メタ情報検索部と、前記クライアント端末から要求されたアプリケーション本体を前記アプリケーション蓄積部から取得し、該要求元のクライアント端末へ配信するアプリケーション本体配信部とを有するアプリケーション提供サーバとを備えたアプリケーション提供システム。

Images