JP2013115592A - 情報処理装置、情報処理方法及び情報処理プログラム - Google Patents

Abstract

【課題】テレビ番組を特定するURIとインターネット上のサービスとの連携サービスを複数のユーザが利用する場合において、あるユーザが生成したURIを異なるユーザが利用する場合に、ユーザ間の環境の違いによらず、当該異なるユーザが、URIを利用したサービスを利用可能とする。
【解決手段】情報処理装置１０１は、コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第１の機器１０２から受信する受信部１０１１と、前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出部１０１３と、複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部１０１６と、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出部が抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成部１０１５と、を備える。
【選択図】図１

Description

本発明の実施形態は、情報処理装置に関する。

近年、テレビで放送される番組毎に、グローバルユニークな識別子であるURI（ＵｎｉｖｅｒｓＡｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を付与して、当該URIを利用して、インターネット上のサービスとテレビ放送番組とを連携したサービスを提供する動きがある。テレビ放送される番組毎に、URIを付与する方法として、テレビ放送の放送波に含まれるＳＩ（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍaｔｉｏｎ）情報からURIを自動生成する方法が定められている（非特許文献１）。尚、この方法による場合、URIは、放送局等に依存した識別子となる。その結果、一つの番組でも、地域によって異なるURIが付与されることが想定される。

テレビ放送される番組毎に、URIを付与して、テレビ番組と連携するインターネット上のサービスとして、例えば、SNS（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ）を想定できる。SNSにおいては、テレビ放送される番組に付与されたURIを複数のユーザ間で共有して利用することとなる。例えば、あるユーザＡがユーザＢに、現在視聴している番組を知らせる際に、同時に該当番組のURIを伝えると、ユーザＢは、URIを利用することで（例えば、URIをクリックするなどの簡易操作を行うことで）、該当番組を視聴することができる。

このようなテレビ番組を特定するURIとインターネット上のサービスを連携したサービス、特に、URIを複数のユーザ間で共有して利用するようなサービスの場合、いくつかの課題がある。具体的には、ユーザＡが利用するテレビＡが生成したURIを、ユーザBが利用するテレビBでは処理できないケースが起こり得る。例えば、テレビＡがURIを生成した時刻から、一定時間経過した時点でテレビＢがアクセスすると、既に該当番組が終了している場合があり得る。この場合、ユーザBは、URIをクリックするだけでは、URIによって特定される番組を視聴することができない。また、テレビＡ、Ｂ各々が属する放送区域が異なる場合、例えば、テレビAが東京にあり、テレビBが大阪にある場合、テレビAが生成したURIから、テレビBは、番組を特定できない。なぜなら、テレビ番組のURIは、テレビ番組の放送局等によって特定されるからである。

M. McRobert,"Automatic Service Discovery with TVDNS",［online］,June 12, 2010, Project Bird, ［ 2011年11月14日検索］, インターネット＜ URL ：http://projectbaird.com/discovery/tvdns/＞,該当箇所：TVDNS Specification (r02 - 2010-06-12)節

本発明の一観点によれば、テレビ番組を特定するURIとインターネット上のサービスとの連携サービスを複数のユーザが利用する場合において、あるユーザが生成したURIを異なるユーザが利用する場合に、ユーザ間の環境の違いによらず、当該異なるユーザが、URIを利用したサービスを利用可能とする。

本発明の一観点に係る情報処理装置は、コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第１の機器から受信する受信部と、前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出部と、複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部と、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出部が抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成部と、を備える。

本発明の実施形態に係るシステムの構成を示すブロック図。 図１の応答情報記憶部１０１６のデータ構造の一例を示す図。 本発明の第１実施例に係るシステムの構成を示すブロック図。 図３のシステムの情報処理装置１０１の応答情報記憶部１０１６のデータ構造の一例を示す図。 図３の情報処理装置１０１を含むシステムの装置間のシーケンスを示した図。 図３の情報処理装置１０１の内部処理のフローチャート。 図３の情報処理装置１０１が応答するＷｅｂページのテンプレートの一例。 機器制御プログラムの擬似コードを示す図。 コンテンツURIのリンク先として、図３のコンテンツ受信装置１０３上に表示されるＷｅｂページの一例を示す図。 第２実施例にかかる情報処理装置２０１を含むシステムの構成を示すブロック図。 図１０の情報処理装置２０１の変換用情報記憶部２０１２の記憶するデータ構造の一例を示す図。 図１０の情報処理装置２０１のコンテンツ情報記憶部２０１３が記憶するデータ構造の一例を示す図。 図１０の情報処理装置２０１の応答情報記憶部１０１６のデータ構造の一例を図。 図１０の情報処理装置２０１の動作を示すフローチャート。 図１０の情報処理装置２０１が応答する機器制御プログラムをリンクするＷｅｂページのテンプレートの一例。 図１０の情報処理装置２０１が応答する機器制御プログラムの擬似コード。 図１０のコンテンツ受信装置１０３上に表示されるＷｅｂページの一例を示す図。 第３実施例にかかる情報処理装置３０１を含むシステムを示すブロック図。 図１８の情報処理装置３０１の応答情報記憶部１０１６のデータ構造の一例。 図１８の情報処理装置３０１を含むシステムの機器間の動作シーケンス図。 第４実施例にかかる情報処理装置４０１を含むシステムを示すブロック図。 図２１の情報処理装置４０１のコンテンツクラス情報記憶部４０１１のデータ構造の一例を示す図。 図２２の情報閲覧装置３０２に表示されるＷｅｂページの一例を示す図。

以下、本発明の実施の形態について、図面を参照しながら説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。

図１は、実施形態にかかる情報処理装置１０１の構成を示すブロック図である。

実施形態に係るシステムは、情報処理装置１０１と、コンテンツ受信装置１０２及び１０３と、サービス提供装置１０４とを備える。情報処理装置１０１と、コンテンツ受信装置１０２及び１０３と、サービス提供装置１０４とは、ネットワーク１０５で接続されている。また、コンテンツ受信装置１０２、１０３は、ネットワーク１０６から情報を受信する通信インタフェースを備えている。

情報処理装置１０１は、受信部１０１１と、送信部１０１２と、第１抽出部１０１３と、応答生成部１０１５と、応答情報記憶部１０１６とを有する。

受信部１０１１は、コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、コンテンツ受信装置１０３から受信する。

第１抽出部１０１３は、受信部１０１１が受信したコンテンツ識別情報が構成する要素情報を抽出する。

応答情報記憶部１０１６は、コンテンツ識別情報が構成する要素情報に関する条件各々と応答情報とを対応付けて記憶している。図２に、応答情報記憶部１０１６が記憶する情報の例を示す。応答情報記憶部１０１６は、要素情報に関する条件毎に対応付けて応答情報を記憶している。

応答生成部１０１５は、応答情報記憶部１０１６が記憶する要素情報に関する条件のうち、第１抽出部１０１３が抽出した要素情報がみたす条件に対応づけて記憶された応答情報を含む応答メッセージを生成する。例えば、第１抽出部１０１３が抽出した要素情報が、図２の条件１を満たす場合、応答生成部１０１５は、条件１に対応付けて記憶された応答情報１を含む応答メッセージを生成する。

送信部１０１２は、応答生成部1015が生成した応答メッセージを、コンテンツ受信装置１０３に送信する。

以下の第1実施例では、以上説明した実施形態についての具体例を説明する。

第1実施例では、コンテンツの例として、テレビ番組とする。また、コンテンツ識別情報の例として、コンテンツURI（Uniform Resource Identifier）とする。コンテンツURIは、Weｂ上でテレビ番組を一意に特定する識別子である。また、コンテンツ識別子が構成する要素情報は、コンテンツURIを構成する値である、ネットワークIDとサービスIDとトランスポートストリームIDと、放送番組の開始時刻の４値とする。これら４値の各々を要素情報と称することとする。また、第1実施例では、応答情報記憶部１０１６が記憶する、コンテンツ識別情報が構成する要素情報に関する条件は、前述した４要素の１つである「放送番組の開始時刻」に関する条件であるとする。より具体的には、「現在時刻が、放送番組の開始前か否か」の条件であるとする。また、第1実施例における応答情報は、後述するように制御命令文字列と制御命令プログラムパスである。また、第1実施例における応答メッセージは、応答情報記憶部１０１６から取得した応答情報を埋めこんだWebページである。また、第1実施例の情報処理装置１０１は、更に、第２抽出部１０１４を備えている。

＜第１実施例＞
まず、第1実施例の動作の概要を説明する。図３は、第1実施例にかかるシステムを示すブロック図である。

図３において、ユーザＡが、デジタルテレビ（コンテンツ受信装置１０２）で番組１（コンテンツ１）を視聴している場合を想定する。この場合に、ユーザAが、例えばリモコンに設けられた共有ボタンを押す等の何らかのアクションを行うと、コンテンツ受信装置１０２が、ソーシャルネットワークサービス上に「この番組を視聴しています（http://tv.example.info/network_101/service_201/ts_301/20101201190000」といったメッセージを送信する。このメッセージに含まれるURIが、Ｗｅｂ上で番組１を一意に特定する識別子である（以降、この識別子をコンテンツURIと称する）。このコンテンツURIは、放送波に含まれるＳＩ情報を利用してコンテンツ受信装置１０２が生成する。本実施例においては、ユーザＢが、コンテンツ受信装置１０２が生成したメッセージを、デジタルテレビ（コンテンツ受信装置１０３）上で読む。ここで、ユーザＢがコンテンツURIを選択（クリック）すると、URIに紐付けられた情報処理装置１０１上のＷｅｂページがコンテンツ受信装置１０３に表示される。この時、該当Ｗｅｂページには、既に番組が始まっていれば、「この番組を視聴する」ボタンが、番組がまだ始まっていなければ「この番組を予約する」ボタンが表示される。ユーザＢは、画面に表示されたボタンを押下することで、ユーザＡが送信した番組に対する視聴・録画予約のアクションを、簡単に実行できる。本実施例では、後述するように、コンテンツ受信装置１０２が生成したURIに対応する番組の開始時刻若しくは終了時刻と、URIをコンテンツ受信装置１０３上に表示する時刻との関係に応じて、Weｂページを、「番組を視聴」若しくは「番組予約」と切り替えることで、ユーザBが、上述の２つの時刻間の関係によらず、番組を視聴することができる。

次に、以上のユースケースにおける、Ｗｅｂページを応答する情報処理装置１０１について、図３を用いて説明する。

第１実施例に係るシステムは、情報処理装置１０１と、コンテンツ受信装置１０２及び１０３と、サービス提供装置１０４とを備える。情報処理装置１０１と、コンテンツ受信装置１０２及び１０３と、サービス提供装置１０４とは、ネットワーク１０５で接続されている。また、コンテンツ受信装置１０２、１０３は、ネットワーク１０６から情報を受信する通信インタフェースを備えている。

次に、第1実施例のシステムを構成するネットワーク及び装置について説明する。

ネットワーク１０５は、インターネット、または、品質保証された閉域網であるＮＧＮ（Ｎｅｘｔ ＧｅｎｅｒＡｔｉｏｎ Ｎｅｔｗｏｒｋ）などのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークである。本実施例においては、ネットワーク１０５は、インターネットであるとする。

ネットワーク１０６は、コンテンツを配信するネットワークであり、地上波デジタル放送網、ＢＳ、ＣＳなどの衛生放送網、ケーブルテレビ、ＮＧＮ、インターネットなどを想定している。本実施例においては、ネットワーク１０６は、地上波デジタル放送網であるものとする。

情報処理装置１０１は、ＣＰＵ、主記憶、補助記憶で構成される、通常のコンピュータのハードウェア構成である。情報処理装置１０１は、ネットワーク１０５（インターネット）に接続する通信インタフェースを備え、インターネット上でコンテンツURIに対応するＷｅｂページを返すサービスを提供している。

コンテンツ受信装置１０２、１０３は、情報処理装置１０１と同様、通常のコンピュータのハードウェア構成をとっており、コンテンツを表示するディスプレイと、キーボード、マウス、タッチパネル等の入出力インタフェースとを備えている。また、ネットワーク１０５とネットワーク１０６に対する通信インタフェースを備えている。具体的には、デジタルテレビ、ハードディスク・レコーダなどのデジタルＡＶ機器、ＰＣ、スマートフォン、スレートデバイスなどである。本実施例においては、コンテンツ受信装置１０２、１０３共にデジタルテレビであるとする。

サービス提供装置１０４は、情報処理装置１０１と同様のハードウェア構成である。サービス提供装置１０４は、ネットワーク１０５を介して、コンテンツ受信装置１０２、１０３のユーザ間のコミュニケーションを実現するソーシャルネットワークサービス等を提供する。本実施例においては、ソーシャルネットワークサービスとして、マイクロブログサービスを想定して説明する。

次に、情報処理装置１０１のＣＰＵが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について図３に則して説明する。

情報処理装置１０１は、受信部１０１１と、送信部１０１２と、第１抽出部１０１３と、第２抽出部１０１４と、応答生成部１０１５と、応答情報記憶部１０１６とを有する。いずれも、ＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に生成されるものである。

このうち、応答情報記憶部３０５はデータベース管理システムである。これは、リレーショナルデータベース、ＸＭＬ（ｅＸｔｅｎｓｉＢｌｅ Ｍａｒｋｕｐ ＬＡｎｇｕＡｇｅ）データベース、Ｋｅｙ／ＶＡｌｕｅストアなど、不揮発もしくは揮発記憶領域上にデータを記憶し、指定したキーをベースにデータを取得できる機能を備えて入れば、実現方式は問わない。単一のデータベース管理システムで構築されている必要はなく、複数のデータベース管理システムを併用してもよい。これは、第２実施例以降における変換用情報記憶部、機種情報記憶部、関連コンテンツ情報記憶部についても同様である。

以下、情報処理装置１０１の各部について説明する。

受信部１０１１は、ネットワーク１０５上のコンテンツ受信装置１０３から、コンテンツURIに対応するＷｅｂページの取得要求を受信する。この時に利用される通信プロトコルは、ＨＴＴＰ、ＦＴＰ等、ＴＣＰプロトコルをベースとしたものでもよく、ＴＣＰ／ＩＰベースに限定されない独自プロトコルであってもよい。実施例においては、インターネット上で両者とＨＴＴＰ（Ｓ）リクエストを受信する、ＨＴＴＰサーバの受信部である。

送信部１０１２は、前記Ｗｅｂページの取得要求に対する応答（後述する応答生成部１０１５が生成する応答情報。具体的にはＷｅｂページ）を、コンテンツ受信装置１０２に送信する。利用されるプロトコルについては、受信部１０１１と同様である。本実施例においては、ＨＴＴＰ（Ｓ）レスポンスを送信するものであり、ＨＴＴＰサーバの送信部である。

第２抽出部１０１４は、受信部１０１１から受信したコンテンツURIに対するＷｅｂページの取得要求に含まれる、送信元のコンテンツ受信装置１０３にかかる情報を抽出する。具体的には、ＨＴＴＰリクエストに含まれるＵｓｅｒ−Ａｇｅｎｔヘッダ情報から、Ｗｅｂブラウザの種別や画面サイズ、機種情報等を抽出する処理や、ＩＰアドレス等から地域情報を抽出する処理を行う。本実施例においては、ＨＴＴＰを前提としたこれらの処理を想定しているが、他の通信プロトコルを前提とした、送信元の機器情報を抽出する他の仕組みであっても構わない。

第１抽出部１０１３は、受信部１０１１で受信したコンテンツURIから、コンテンツが放送された地域、放送局、放送時間等の情報を抽出する。地上波デジタル放送においては、コンテンツを一意に識別する情報として、放送波にＳＩ情報として含まれるネットワークＩＤ、サービスＩＤ、トランスポートストリームIＤ、開始時刻の４値の組み合わせが利用できる。ネットワークIDは、地上波、BS放送、CS放送といった粒度の通信網を表す情報である。サービスIDは、放送局を識別する情報であり、系列で一意の識別子ではなく、地方放送局毎に付与される識別情報である。トランスポートストリームIDは、放送局が送出するストリーム（MPEG-2 TS）を識別するための番号である。開始時刻は、放送番組の開始時刻である。以上の4値をもって、番組を一意に識別することができる。

コンテンツURIが、この４値を含むように構成されている場合、第１抽出部１０１３は、URI解析によって、これら４つの値を抽出する。具体的には、ネットワークＩＤが１０１、サービスＩＤが２０１、トランスポートストリームＩＤが３０１、開始時刻が２０１０年１２月１日１９時であった場合に、コンテンツURIは、例えば、以下のように表現できる。第１抽出部１０１３は、このURIから、各値を取得する処理を行う。

http://tv.nameservice.com/n_101/s_201/t_301/20101201190000

なお、コンテンツURIの形式は、上記フォーマットに限定されるものではない。対象が、放送コンテンツである場合であっても、開始時刻情報の代わりにイベントＩＤ情報を利用する等、他の方法もある。ネットワーク１０６上でコンテンツを一意に識別するための情報が含まれる範囲においては、他のフォーマットであっても構わない。

応答生成部１０１５は、第１抽出部１０１３及び第２抽出部１０１４で抽出した情報に基づき、コンテンツURIに対応する応答情報を生成する。応答情報は、例えば、ＨＴＭＬデータ（Ｗｅｂページ）、ＸＭＬデータ、あるいは、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）データなど様々な形式のデータが想定できる。ここでは、Ｗｅｂページを返すものとする。本実施例では、例えば、第１抽出部１０１３が抽出した開始時刻情報を利用し、現在時刻が、番組の開始時刻を過ぎている場合に、Webページとして、チャンネル変更ボタンと、ボタン押下をトリガに実行される機種に応じたチャンネル変更命令プログラムとを埋め込んだページを返す。また、現在時刻が、開始時刻より前である場合には、Webページとして、録画予約ボタンと、ボタン押下をトリガに実行される機種に応じた録画予約命令プログラムを埋め込んだWebページを返す。

応答情報記憶部１０１６は、第１抽出部１０１３及び第２抽出部１０１４で抽出した情報と、応答情報を対応付けて記憶する。また、応答生成部１０１５からの前記属性情報をキーとした応答情報取得要求を受けて、対応する応答情報を返す。図４は、応答情報記憶部１０１６のデータ構造の一例を示すものである。図４に示すように、コンテンツの時制（時刻条件と称する。）（開始時刻前か否かを表すブール値）、制御命令文字列（「録画予約する」「視聴する」等、ボタンに表示する文字列）、制御プログラムパスの４つのカラムで構成されている。これは、Ｗｅｂページ上に、該当コンテンツに対する１つの操作ボタン（「録画予約する」あるいは「視聴する」の２種類）を表示するというシンプルな目的に特化したデータ構造であり、応答するＷｅｂページの内容に応じて、さらに多くの情報で構成してもよいし、反対に、より少ない情報で構成してもよい。尚、本例では、開始時刻に応じた処理のみを説明しているが、終了時刻に応じた処理のバリエーションも想定できる。例えば、図４のカラム名として、終了時刻前か否かをいれ、終了時刻前か否かに応じて、応答情報を変更するようにしてもよい。この場合、終了時刻前か否かを、たとえば、コンテンツの終了時刻を取得し、現在時刻と終了時刻を比較して、判断する。このように、開始時刻や終了時刻を時刻条件と称することとする。また、図４の時刻条件は、図２の要素情報に関する条件に対応する。また、図４の制御命令文字列と制御命令プログラムパスは、図２の応答情報に対応する。図４に示すように、第1実施例の応答情報記憶部１０１６は、複数のエントリについて、要素情報に関する条件毎に、応答情報を記憶している。

次に、図３〜図９を用いて、本実施例に係る情報処理装置１０１の動作について説明する。図５は、本実施例に係る情報処理装置１０１を含むシステム構成要素間のシーケンスを示した図である。図６は、情報処理装置１０１の内部処理のフローチャートである。図７は、情報処理装置１０１が応答するＷｅｂページのテンプレートの一例である。図８は、機器制御プログラムの擬似コードを示すものである。図９は、コンテンツURIのリンク先として、コンテンツ受信装置１０３上に表示されるＷｅｂページの一例を示す図である。

まず、本実施例の前提として、２人のユーザを想定する。コンテンツ受信装置１０２のユーザ（ユーザＡ）と、コンテンツ受信装置１０３のユーザ（ユーザＢ）である。ユーザＡとユーザＢは共に、他ユーザとのコミュニケーションを実現する、サービス提供装置１０４が提供するSNSに加入している。また、コンテンツ受信装置１０２、１０３は、このSNSにメッセージを送信したり、メッセージを閲覧したりするSNSクライアント機能と搭載しているものとする。

以下、図５のシーケンス図をベースに処理手順を説明する。図５は、情報処理装置１０１を含むシステムの装置間のシーケンスを示した図である。

まず、ユーザＡがコンテンツ受信装置１０２上で、コンテンツ（地上波デジタル放送番組）視聴中に、リモコンもしくは画面上に表示された「この番組をみんなに薦める」ボタンを押す（ステップＳ１０１）。コンテンツ受信装置１０２は、ボタン押下のイベントを受けて、受像している番組を識別する情報（ネットワークＩＤ、サービスＩＤ、トランスポートストリームＩＤ、開始時刻の４値）をＳＩ情報から取得する（ステップＳ１０２）。続いて、コンテンツ受信装置１０２は、この４値を用いて、コンテンツURIを生成する（ステップＳ１０３）。前述したように、受像中の番組のネットワークＩＤが１０１、サービスＩＤが２０１、トランスポートストリームＩＤが３０１、番組の開始時刻が２０１０年１２月１日１９時である場合に、生成されるコンテンツURIは、http://tv.nameservice.com /n_101/s_201 /t_301/20101201190000となる。続いて、コンテンツ受信装置１０２は、生成したコンテンツURIを引用したメッセージ（例えば、「この番組を視聴していますhttp://tv.nameservice.com/n_101/s_201/t_301/20101201190000」など）を生成する（ステップＳ１０４）。このとき、ネットワークＩＤ等と同様に、当該番組のタイトル文字列情報を、ＳＩ情報から取得し、これをメッセージに含めてもよいし（「番組XXXを視聴しています。http://... 」）、あるいは、コンテンツURIがデフォルトで入力されたテキストボックスを表示してユーザにメッセージを入力を促すように構成してもよい。メッセージ生成のフォーマット、実現形式は問わない。コンテンツ受信装置１０２は、生成したメッセージを、ネットワーク１０５上のサービス提供装置１０４に送信する（ステップＳ１０５）。本実施例においては、このメッセージ送信は、ＨＴＴＰ ＰＯＳＴメソッドで送信されるものとするが、ＨＴＴＰ ＰＵＴやＧＥＴなど別のメソッドであってもよく、ＨＴＴＰプロトコルに限定されるものでもない。

サービス提供装置１０４は、コンテンツ受信装置１０２から該当メッセージを受信すると、ユーザＡのメッセージを購読しているユーザＢを同定し（ステップＳ１０６）、ユーザＢ（すなわち、コンテンツ受信装置１０３）に対して同メッセージを送信する。この送信シーケンスは、コンテンツ受信装置１０３上のSNSクライアントが、定期的にサービス提供装置１０４に対して、メッセージの有無を問い合わせるポーリングによって実現してもよいし、サービス提供装置１０４からコンテンツ受信装置に対して、メッセージをプッシュするように実現してもよい。本実施例においては、前者の方法で実現されるものとする。具体的には、コンテンツ受信装置１０２がＨＴＴＰ ＧＥＴリクエストによって、購読対象（ユーザＡ）からの新着メッセージを要求（ステップＳ１０７）し、結果を受信する（ステップＳ１０８）。この通信プロトコルについては、ステップＳ１０５と同様、様々な実現方式（通信プロトコル）が許容される。なお、後者の方法については、コンテンツ受信装置１０４がＨＴＴＰクライアント、コンテンツ受信装置１０３がＨＴＴＰサーバとしてふるまうように実現する方法や、ＨＴＴＰロングポーリングや、ＷｅｂＳｏｃｋｅｔを利用して、コンテンツ受信装置１０３側が、サービス提供装置１０４に対するＴＣＰコネクションを生成、維持し、このコネクションを利用して、サービス提供装置１０４がコンテンツ受信装置１０２に対してメッセージを送信する方法などが考えられる。

次に、コンテンツ受信装置１０３は、受信したユーザＡからのメッセージをコンテンツ受信装置１０３の画面上に表示する（ステップＳ１０９）。ここまでの処理で、ユーザＢのコンテンツ受信装置１０３の画面上に、ユーザＡの送信したコンテンツURIを含むメッセージが表示されることになる。

ここで、ユーザＢが、ユーザＡの「この番組を視聴しています。http://tv.name service.com/n_101/s_201/t_301/20101201190000」メッセージを閲覧し、このコンテンツURIを選択する（ステップＳ１１０）。選択方法は、ポインティングデバイスでクリックする、あるいはリモコンで選択・決定するなど、様々な方法が考えられる。この選択処理をトリガとして、コンテンツ受信装置１０３は、情報処理装置１０１に対してアクセスする（すなわち、コンテンツURIに紐付けられたＷｅｂページの取得要求を送信する）（ステップＳ１１１）。これは、通常のＨＴＭＬにおけるハイパーリンクを辿る手段と同じであり、ＨＴＴＰ ＧＥＴリクエストによって実現される。

情報処理装置１０１は、Ｗｅｂページの取得要求を受信して、コンテンツURI処理（コンテンツURI解析と対応するＷｅｂページの生成）を行ない（ステップＳ１１２）、コンテンツURIに対応するＷｅｂページを、コンテンツ受信装置１０３に応答する（ステップＳ１１３）。

ここで、情報処理装置１０１におけるステップＳ１１２のコンテンツURI処理を、図６のフローチャートを用いて説明する。

情報処理装置１０１の受信部１０１１は、Ｗｅｂページの取得要求を受信し、これを第２抽出部１０１４に渡す（ステップＳ１００１）。第２抽出部１０１４は、受信要求に含まれる情報から、送信元のコンテンツ受信装置１０３にかかる情報を抽出する（ステップＳ１００２）。具体的には、ＨＴＴＰリクエストに含まれるＵｓｅｒ−Ａｇｅｎｔヘッダから、コンテンツ受信装置１０３上に搭載されているＷｅｂレンダリングエンジンの種類やバージョン、画面サイズ情報を取得する。ここでは、Ｗｅｂページのレイアウトを決定する画面サイズを取得する。続いて、第１抽出部１０１３が、コンテンツURI自体を解析し、地上波デジタル放送上で、コンテンツを一意に識別するための４値（ネットワークＩＤ、サービスＩＤ、トランスポートストリームＩＤ、開始時刻）を取得する（ステップＳ１００３）。これは、前述したとおり、本実施例では、それぞれ１０１、１０２、１０３、２０１０年１２月１日１９：００である。次に、応答生成部１０１５が、第２抽出部１０１４が抽出した画面サイズ、第２抽出部１０１３が抽出した４値を入力に取り、まず、現在時刻（アクセス時刻）をシステムから取得し（ステップＳ１００４）、現在時刻とコンテンツの開始時刻とを比較し、現在時刻がコンテンツの開始時刻前か否かを判定する（ステップＳ１００５）。続いて、応答生成部１０１５は、応答情報記憶部１０１６から機種情報と開始前か否かのブール値をキーとして、制御命令文字列と制御命令プログラムパス（ＵＲＬ：Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を取得する（ステップＳ１００６）。ここでは、コンテンツ受信装置１０３からの取得要求の時刻（つまり現在時刻）が、コンテンツの開始時刻後であったとして、図４における１番目のエントリ（http://tv.nameservice.com/apis/changeChannel.js）が取得される。応答生成部１０１５は、図７に一例を示す、Ｗｅｂページのテンプレートに、機器操作プログラムへのパス情報、制御命令文字列、および、コンテンツURIから取得した４値を埋め込む。具体的には、図７の$1, $2, $3, $4, $5, $6に、それぞれの値を埋め込み、応答メッセージ（Ｗｅｂページ）を生成し（ステップＳ１００７）、送信する（ステップＳ１００８）。

続いて、図５を用いて、コンテンツ受信装置１０３の挙動について説明する。コンテンツ受信装置１０３は、情報処理装置１０１からの応答メッセージを受信すると、これをディスプレイ上に表示する（ステップＳ１１４）。表示されるＷｅｂページの一例を、図９に示す。本実施例では、「この番組を視聴する」ボタンが表示される。ユーザＢが表示されたボタンを押下すると（ステップＳ１１５）、図８の&&&TODO行目のチャンネル変更ＡＰＩ（Application Program Interface）（device.execute (networkId, serviceId, transportStreamId, startDate)）が呼び出される。この例では、ＡＰＩ内部で呼び出されている機器制御関数（setChannelNative(networkId, serviceId, transportStreamId)）が、実際にコンテンツ受信装置１０３の受像チャンネルを、与えられたパラメータに応じて変更する（ステップＳ１１６）。なお、ユーザＢが、当該コンテンツURIをクリックした時刻が、コンテンツの開始時間よりも前であった場合には、情報処理装置１０１は、ステップＳ１００６において録画予約のための制御プログラムを取得し、コンテンツ受信装置１０３上に表示されるボタンは、「この番組を録画予約する」となる。

以上のように、本実施例の情報処理装置１０１によれば、コンテンツURIを処理する時点での、コンテンツの時制（開始時刻を過ぎたか否か）の変化に合わせて、すなわち、コンテンツの時制という属性値の発信側（コンテンツ受信装置１０２）と受信側（コンテンツ受信装置１０３）の差異に関わらず、複数機器間で当該コンテンツURIをシェアし、これを利用した機器操作を簡単に実現できている。本実施例において、ユーザＢによる、コンテンツ受信装置１０３のチャンネル変更／録画予約までの操作ステップは、コンテンツURIの選択と、選択の結果表示されたＷｅｂページのボタン押下の２ステップである。さらに、ボタン押下というユーザアクションを省略し、Ｗｅｂページのコンテンツ受信装置１０３での読み込みをトリガとして、上記のdevice.execute関数を自動実行することも可能である。この場合は、ユーザＢは、コンテンツURIのリンクを辿る（クリックする）という１アクションで、実機器の操作を行うことが可能になる。

尚、情報処理装置１０１は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、受信部１０１１、送信部１０１２、第１抽出部１０１３、第２抽出部１０１４、応答生成部１０１５、応答情報記憶部１０１６は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、情報処理装置１０１は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、応答情報記憶部１０１６は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。

＜第２実施例＞
次に、図１０を用いて、第２の実施の形態の情報処理装置２０１について説明する。

まず、本実施例の想定する具体的なユースケースについて説明する。

第１実施例と同様、ユースケースの骨子は、ユーザＡによるコンテンツURIを引用したメッセージを、ユーザＢが閲覧するとともに、このコンテンツURIをクリックすることで機器を制御するというものである。第2実施例と第１実施例との差分は、２つある。第1に、ユーザＢが属する放送区域が、ユーザＡの属する放送区域と異なる点である。そして、情報処理装置２０１は、ユーザB及びAが異なる放送区域であっても、ユーザB及びAがコンテンツURIを利用したサービスを障害なく利用できるようにしている。第2に、第１実施例においては、全ての操作対象機種が共通化された同じＡＰＩを利用していたが、第2実施例では、そうではない点である。すなわち、第2実施例では、情報処理装置２０１は、操作対象機器の機種やメーカ毎にＷｅｂページからアクセスするための異なるＡＰＩセットを持っていて、操作対象機器に合わせて、呼び出すＡＰＩを変更することができるようにしている。

図１０は、情報処理装置２０１の構成を示すブロック図である。

以下、情報処理装置２０１と情報処理装置１０１との差分を説明する。

情報処理装置２０１のハードウェア構成は第１実施例と同様であるが、新たな機能ブロックとして、変換部２０１１、変換用情報記憶部２０１２、コンテンツ情報記憶部２０１３が追加されている。いずれも、ＣＰＵのプログラム実行時にＲＡＭなどの主記憶部上に生成されるものである。

まず、情報処理装置２０１と情報処理装置１０１との差分として、新たな機能ブロックの説明をする。

変換部２０１１は、コンテンツURIを、Ｗｅｂページ取得要求元の環境に応じて変換する。この際、第２抽出部１０１４が抽出する情報と、後述する変換用情報記憶部２０１２に記憶された情報に基づいて変換する。本実施例においては、コンテンツ受信装置１０３の放送区域のチャンネル編成に合わせて、コンテンツURIに含まれる放送コンテンツの識別情報を構成するネットワークＩＤ、サービスＩＤ、（および、トランスポートストリームＩＤ）を変更する。

変換用情報記憶部２０１２は、変換部２０１１がコンテンツURIの変換に利用する情報を記憶する。例えば、本実施例においては、地域毎のチャンネル編成の対応関係を管理する。図１１は、変換用情報記憶部２０１２の記憶するデータ構造の一例を示すものである。図１１に示すように、地域及び放送系列毎の放送局情報（ネットワークＩＤ、サービスＩＤ（、トランスポートストリームＩＤ））を管理する変換部２０１１は、この変換用情報記憶部２０１２を利用して、コンテンツ受信装置１０２上で生成されたコンテンツURIのネットワークＩＤとサービスＩＤから放送系列を同定し、コンテンツ受信装置１０３の放送区域における同放送系列のネットワークＩＤとサービスＩＤを求め、この値でコンテンツURIを変換する。すなわち、図１１は、コンテンツURIの変換のために、機器情報に含まれる放送区域情報を用い、変換対象が放送局情報（ネットワークID＋サービスID）であることを想定したデータ構造になっている。これはあくまで一例であり、様々なバリエーションが考えられる。例えば、変換対象がネットワークIDのみ（例えば、地上波からBSへの変換）であってもよく、変換対象がコンテンツの開始時間までも含むもの（地域によって開始時間までも異なる場合）であってもよい。

それぞれのバリエーションによって、変換用情報記憶部２０１２のデータ構造は異なり、各バリエーションにおける変換対象の情報と、変換に用いる情報とを含むものとなる。

尚、図１１で示した情報は、第1変換用情報に対応し、コンテンツ受信装置１０３の放送区域が、第1の機器に関する第1情報に対応する。 コンテンツ情報記憶部２０１３は、コンテンツ識別情報と、コンテンツの様々な属性（メタデータ）を記憶する。例えば、番組タイトルやジャンル、出演者、番組の説明文、開始時間や終了時刻（あるいは、尺）などである。図１２は、情報処理装置２０１のコンテンツ情報記憶部２０１３が記憶するデータ構造の一例を示す図ある。本実施例においては、図１２に示すように、タイトルと開始時刻、終了時刻、番組説明文を管理しているものとする。この構成は一例であり、現在、放送波のＳＩ情報に含まれるあらゆる番組メタデータや、当該番組に関連する商品や類似番組、シリーズ番組などの番組に付随する情報も合わせて管理してもよい。

情報処理装置２０１と情報処理装置１０１との差分として、情報処理装置１０１が有す構成要素であるが、異なる機能を有する構成要素を説明する。

応答情報記憶部１０１６の、情報処理装置１０１の応答情報記憶部１０１６のデータ構造からの変更点について説明する。第2実施例における応答情報記憶部１０１６のデータ構造の一例を図１３に示す。第１実施例との差分は、機種情報が追加されている点、当該機種情報ごとに制御命令プログラムパスが異なる点にある。すなわち、コンテンツ受信装置が外部公開する機能（チャンネル変更や録画予約）のインタフェース（API）が、機種ごとに独自のものであった場合には、アクセス元（コンテンツ受信装置）の機種情報に応じた応答情報（制御命令プログラム）が必要になる。図１３の機種情報（条件１）は、第２抽出部１０１４が抽出した、アクセス元の機器の機器情報に関する条件に対応する。また、図１３の「放送中か否か」（条件２）は、図２の要素情報に関する条件に対応する。また、図１３の制御命令文字列と制御命令プログラムパスは、図２の応答情報に対応する。第2実施例の応答情報記憶部１０１６は、複数のエントリについて、機器情報に関する条件（条件１及び）要素情報に関する条件（条件２）毎に、応答情報（制御命令文字列及び制御命令パス）を記憶している。 次に、図１０〜図１７を用いて、情報処理装置２０１の動作を説明する。図１７は、情報処理装置２０１の内部処理のフローチャートを示したものである。図１５、図１６は、それぞれ本実施例における情報処理装置２０１が応答するＷｅｂページのテンプレートの一例と、Webページにリンクされる機器制御プログラムの擬似コードを示すものである。図１７は、コンテンツURIのリンク先として、コンテンツ受信装置１０３上に表示されるＷｅｂページの一例を示す図である。

本実施例のシステム構成は、第１実施例と同様であり、システム構成要素間の通信シーケンスも、第１実施例と等しく、図５に従う。ここでは、本実施例における差分のみについて、図３を用いて説明する。

第１の差分は、コンテンツURIに基づくＷｅｂページ取得要求（ステップＳ１１１）において、コンテンツ受信装置１０３が、属する放送区域情報を送信する点である。この放送区域の情報は、ＨＴＴＰ ＧＥＴメソッドによる送信時にコンテンツURIにクエリ文字列として追加して送ってもよいし、あるいはリクエストヘッダに独自項目を追加し、そのフィールドに埋め込んでもよい。あるいは、ＨＴＴＰ ＰＯＳＴメソッドによるリクエストの形式をとり、リクエストボティに埋め込んでもよい。なお、別の方法として、情報処理装置２０１が、ユーザの属する放送区域を、ＩＰアドレスや経由したネットワーク上のノード情報から算出する方法が考えられる。この場合は、精度面では劣るが、コンテンツ受信装置１０３が、明示的に放送区域情報を送信せずに済む。

第２の差分は、情報処理装置２０１におけるコンテンツURI処理（ステップＳ１１２）である。図１４のフローチャートを用いて説明する。第１実施例（図６）との差分は、まず、コンテンツURIの解析処理（ステップＳ２００３）の後に、コンテンツURIの変換処理が入る点である。変換部２０１１は、変換用情報記憶部２０１２を利用して、ユーザＡの環境におけるコンテンツURIをユーザＢの環境に合わせたものに変換する。

例えば、ユーザＡが東京、ユーザＢが大阪の場合、図１１に情報に基づき、ネットワークＩＤ（１０１）、サービスＩＤ（２０１）、トランスポートストリームＩＤ（３０１）の３値とユーザＡの放送区域（東京）から、ユーザＡの視聴している番組の放送局系列識別子が１であることがわかる。同じ放送局系列識別子（１）と、ユーザＢの属する放送区域（大阪）から、ユーザＢの環境における当該コンテンツの上記３値は、１０１、２０３、３０３である。すなわち、変換後のコンテンツURIは、以下のようになる。

http://tv.nameservice.com/n_101/s_203/t_303/20101201190000

なお、この変換後のコンテンツURIは、あくまでコンテンツURI形式にシリアライズした場合の例であり、実際は、情報処理装置２０１の内部処理として、コンテンツURIを構成するコンテンツ識別情報（本実施例の場合は、ネットワークＩＤ、サービスＩＤ、トランスポートストリームＩＤ、開始時刻の４値）の変換のみに留めてよい。

変換部２０１１の処理は、変換元の{ AreaId, NetworkId, ServiceId, TransportStreamId}の４値から、ServiceGroupIdを導出し、このServiceGroupIdと変換先のAreaIdから、変換先の{NetworkId, ServiceId, TransportStreamId}を求める処理になる。

続いて、応答生成部１０１５が、（変換前もしくは変換後の）コンテンツURIから、図１２に示した情報を用いて、コンテンツ情報を取得する（ステップＳ２００５）。コンテンツ情報を取得することにより、図１７に示すように生成するＷｅｂページに番組情報を含めることができる。また、番組の終了時刻（あるいは尺）情報を参照することで、現在時刻に番組が終了しているか否かを判定することができる。第１実施例においては、時制の判定材料に開始時刻のみを利用していたが、終了時刻を利用することで、図１４のように、放送中か否かを判定することが出来る。本実施例では、現在時刻を参照し（ステップＳ２００６）、既に番組が終わっている場合には、（例えば「既にこの番組は終了しています」等の）エラーメッセージページを生成して（ステップＳ２００９）、これを送信する（ステップＳ２０１１）。 一方、番組が終っていない場合には、時制と、第２抽出部１０１４で抽出した機種情報に基づき、応答情報記憶部１０１６から、機種に応じた機器制御プログラムや、表示文字列などの図１５に一例を示したＷｅｂページテンプレートに設定する諸情報を取得する（ステップＳ２００８）。この情報をテンプレートに設定し、Ｗｅｂページを生成し（ステップＳ２００９）、これを送信する（ステップＳ２０１０）。Webページのテンプレートには、図１５に示すように、コンテンツ情報記憶部２０１３から取得した放送局、タイトル、番組説明を挿入する変数（$2, $3, $4）が追加されており、応答生成部１０１５は、この３つを含めた、コンテンツ情報記憶部２０１３、応答情報記憶部１０１６から取得した合計９つの変数を、図１４のテンプレートに埋め込む。以上が、コンテンツURI処理の第１実施例との差分となる。

第３の差分は、コンテンツ受信装置１０３の表示するＷｅｂページである（ステップＳ１１４）。図１７に示すように、コンテンツ情報記憶部２０１３の情報が、Ｗｅｂページに反映されている。

第４の差分は、ボタン押下で実行される機器制御プログラムである。図１６に示すように、ＡＰＩの内部で呼び出される関数（録画予約）がreserve_42xx001()となっている。つまり、デジタルテレビ４２Ｘ００１向けのコードが埋めこまれている。応答生成部１０１５が、機種に応じた機器制御プログラムをリンクすることで、内部機能へのアクセスＡＰＩの標準規格が存在しない場合でも、本実施例は実現可能であることを示している。

以上のように、本実施例によれば、ユーザＡとユーザＢの属する放送区域が異なる場合であっても、コンテンツURIを、ユーザの環境に合わせて変換することで、コンテンツURIを適切に処理する（実機器操作につなげる）ことができる。また、機器の内部機能を利用するためのＡＰＩ標準が存在しない場合であっても、機種に応じた制御プログラムを動的に埋め込むことで、コンテンツURIからの実機器操作を実現できている。

＜第3実施例＞
図１８は、第３実施例にかかる情報処理装置３０１である。

まず、第3実施例の想定する具体的なユースケースについて説明する。

第１、２実施例と同様、第3実施例のユースケースの骨子は、ユーザＡによるコンテンツURIを引用したメッセージを、ユーザＢが閲覧し、このコンテンツURIをクリックすることで機器を制御するというものである。第１及び２実施例との差分は、２つある。第1は、ユーザＢがデジタルテレビ（コンテンツ受信装置１０３）を操作しているのではなく、ＰＣもしくはタブレット端末を利用しているという点である。具体的には、ユーザＢは、テレビの前で、ラップトップＰＣ上でSNSを閲覧しており、ユーザＡが提示するコンテンツURIをクリックすると、ネットワーク経由でコンテンツ受信装置１０３の制御を行う。第２は、放送が終了している番組についても録画済みであれば再生を行う、という機器制御を想定している点である。

図１８は、本発明の第３実施例に係る情報処理装置３０１の機能ブロックを含むシステム構成図である。システム構成上の第１実施例（図３）との差分は、ネットワーク３０３と情報閲覧装置３０２が追加されている点にある。

ここで、ネットワーク３０３は、ネットワーク１０５と同様、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークであり、特に宅内ＬＡＮを想定している。

情報閲覧装置３０２は、前述した本実施例のユースケースにおける、ラップトップＰＣに対応するものである。したがって、コンテンツ受信装置１０２、１０３と同様、ＣＰＵ、主記憶、補助記憶で構成される、通常のコンピュータのハードウェア構成となっている。

次に、情報処理装置３０１について、第２実施例にかかる情報処理装置２０１との差分を説明する。情報処理装置３０１のハードウェア構成は情報処理装置２０１と同様であるが、新たな機能ブロックとして、第3抽出部３０１１が追加されている。

第3抽出部３０１１は、情報閲覧装置３０２がＷｅｂページ取得要求時に付与する操作対象機器情報、あるいは、プロトコル情報を抽出する。具体的には、情報閲覧装置３０２は、コンテンツURIを利用した実機操作（チャンネル変更等）を自機器で行わない場合に、周辺機器の機種情報や、発見・遠隔操作するためのプロトコル情報をＷｅｂページ取得要求に含める。これは、既存のＨＴＴＰリクエストヘッダを利用して、この情報を追加するようにしてもよいし、新たなＨＴＴＰリクエストヘッダを設けてもよいし、リクエストＵＲＬ（すなわちコンテンツURI）に含めてもよいし、あるいは、ＨＴＴＰ ＰＯＳＴリクエストを利用し、ＨＴＴＰペイロードに記述するようにしてもよい。

次に、応答情報記憶部１０１６のデータ構造の変更点について説明する。本実施例における応答情報記憶部１０１６のデータ構造の一例を図１９に示す。第２実施例の応答情報記憶部１０１６との差分として、制御プロトコル情報が追加されている。これは、コンテンツ受信装置１０３が周辺機器にコンテンツURI操作を要求するための制御プロトコルを特定するものである。図１９の機種情報（条件１）は、第２抽出部１０１４が抽出した、アクセス元の機器の機器情報に関する条件に対応する。図１９の「時制」（条件３）は、図２の要素情報に関する条件に対応する。本実施例では、上述した条件に加えて、更に、制御プロトコル情報に関する条件（条件２）を記憶している。また、図１９の制御命令文字列と制御命令プログラムパスは、図２の応答情報に対応する。第3の実施例の応答情報記憶部１０１６は、複数のエントリについて、及び機器情報に関する条件（条件１）及び制御プロトコル情報に関する条件（条件２）及び要素情報に関する条件（条件３）毎に、応答情報（制御命令文字列及び制御命令パス）を記憶している。 次に図１４、図１８〜図２０を用いて、情報処理装置３０１の動作を説明する。図２０は、情報処理装置３０１を含むシステム構成要素間の基本シーケンスを示したものである。

以下、図２０のシーケンス図をベースに処理手順を説明する。

まず、ステップＳ３０１からステップＳ３１０までの処理は、第１実施例におけるステップＳ１０１からＳ１１０までと同じであるため説明を省略する。この時点で、ユーザＢの情報閲覧装置３０２の画面上に、ユーザＡの送信したコンテンツURI（第１実施例と同様、http://tv.name service.com/n_101/s_201/t_301/20101201190000 であるとする）を含むメッセージが表示され、ユーザＢがこのコンテンツURIをクリックしたことになる。

以降の動作については、第２実施例との差分のみを説明する。

動作シーケンスの第１の差分は、ステップＳ３１１の操作機器情報取得処理が追加されている点である。情報閲覧装置３０２は、webページ取得要求メッセージに、webページを用いて操作する制御対象機器に関する情報を取得し（ステップＳ３１１）、この情報を埋め込んで送信する（ステップＳ３１２）。これは、前述したようにＨＴＴＰリクエストヘッダ、ペイロード、クエリ文字列等様々な実現方式が考えられる。なお、埋め込む情報は、プロトコル情報だけでもよいし、機種情報、宅内ＩＰアドレス／ポート番号情報、メールアドレスなど、ネットワーク１０５を介したリモートアクセスに必要な他の情報を埋めこんでもよい。前者の場合は、制御プロトコルに基づいて実際に制御する機器を発見・特定し、制御命令を送信するまでの一連の処理を制御プログラムに埋め込む必要があるが、後者の場合は、発見処理を割愛できる。本実施例においては、図１９に示すように、制御プロトコル情報のみを含むものとする。

動作シーケンスの第２の差分は、ステップＳ３１３のコンテンツURI処理である。処理のフローチャートは第２実施例のフローチャート（図１４）と同様であるが、ステップＳ２００２の端末側情報抽出処理において、前記の制御対象機器情報を抽出する点と、ステップＳ ２００８の機器制御プログラム取得処理において、得られた機種情報およびプロトコル情報をキーとして情報を取得する点において異なっている。

第３の差分は、情報閲覧装置３０２がＷｅｂページを取得し、ユーザＢがＷｅｂページ上のボタンをクリックした後の処理である。図１４のステップＳ２００８において、図１９のエントリ１が選択された場合、Ｗｅｂページには、ＤＬＮＡプロトコルをベースにした機器発見、機器制御プログラムが埋めこまれている。ユーザＢが「録画コンテンツを再生する」ボタンをクリックすると、情報閲覧装置３０２は、ＤＬＮＡプロトコルに基づく、機器発見ステップ（ＤＬＮＡ Ｓｅａｒｃｈ）を実行し、録画コンテンツを管理するＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）を有する機器として、コンテンツ受信装置１０３を発見する（ステップＳ３１７、Ｓ３１８）。続いて、情報閲覧装置３０２は、発見されたコンテンツ受信装置１０３に対して、ネットワークＩＤ、サービスＩＤ、トランスポートストリームＩＤ及び開始時刻の４値をキーとした、コンテンツ検索・再生ステップ（ＤＬＮＡ Ａｃｔｉｏｎ）を実行する（ステップＳ３１９）。コンテンツ受信装置１０３は、対象コンテンツが録画済みであれば、要求された再生処理を行ない（ステップＳ３２０）、正常実行した旨を応答する（ステップＳ３２１）。録画していなければ、検索エラーメッセージを応答する。

以上のように、本実施例によれば、コンテンツURI処理を要求する機器以外の機器を操作対象とすることができる。すなわち、ラップトップＰＣでSNSを閲覧している状況で、近くのデジタルテレビにコンテンツURIに基づく実機器操作を実行させることが可能になっている。

＜第4実施例＞
図２１は、第４実施例にかかる情報処理装置４０１を含むシステムを示すブロック図である。

本実施例の想定する具体的なユースケースについて記す。

第１、２、３実施例と同様、第4実施例のユースケースの骨子は、ユーザＡによるコンテンツURIを引用したメッセージを、ユーザＢが閲覧し、このコンテンツURIをクリックすることで、コンテンツURIに紐付けられたコンテンツを視聴・予約等を行うものである。第4実施例の、第１、２、３実施例との差分は、３つある。第1の差分は、図２１に示すように、第4実施例にかかる情報処理装置４０１を含むシステムが、コンテンツ受信装置１０３を備えておらず、ユーザＢが情報閲覧装置３０２のみを保持している点である。第2の差分は、コンテンツURIに紐付けられているのが、放送コンテンツではなく、ネットコンテンツであるという点である。第3の差分は、情報処理装置４０１がＷｅｂページに関連情報を付与して送信する点である。より具体的には、ユーザＢは、ラップトップＰＣ上でSNSを閲覧しており、テレビを所有していない（第1の差分に対応する。）。そして、ユーザＡが提示するコンテンツURIをクリックすると、当該コンテンツは放送コンテンツであるが、ユーザＢはテレビを有していないので、放送経由では視聴できない。情報処理装置４０１は、「この番組をインターネットで視聴する」ボタン（インターネット上のＶｏＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）サービス上で公開された当該コンテンツのURIへのリンク）を含むページを返す（第2の差分に対応する。）。このとき、ページには、当該コンテンツに関連するコンテンツ・商品情報も埋め込んで返す（第3の差分に対応する）。

以下、本実施例の詳細について、図２１を用いて説明する。

本実施例のシステム構成上の第３実施例との差分は、ネットワーク３０３とコンテンツ受信装置１０３が無い点と、ネットワーク１０５上のコンテンツ配信サービス提供装置４０２が追加されている点である。

コンテンツ配信サービス提供装置４０２のハードウェア構成は、サービス提供装置１０４と同様である。コンテンツ配信サービス提供装置４０２が提供するサービスは、放送局が、放送後の番組を有料配信するＶｏＤサービスや、一般的なビデオ共有サービスなどが想定される。本実施例においては、放送局が提供する有料ＶｏＤサービスであるとする。

次に、情報処理装置４０１における、第３実施例との差分を説明する。情報処理装置４０１のハードウェア構成は第３実施例と同様であるが、新たな機能ブロックとして、コンテンツクラス情報記憶部４０１１、コンテンツ関連情報記憶部４０１２が追加されている。また、変換部２０１１の機能も差分がある。

コンテンツクラス情報記憶部４０１１は、配信メディアに依存するコンテンツ情報と、配信メディアに依存しないコンテンツ情報（以下、コンテンツクラス情報と呼ぶ）を関連付けて記憶する。具体例を挙げると、ある放送局が、ある日時に、放送番組として放送する映画Ａと、パッケージとしての映画Ａを紐付けるものである。コンテンツクラス情報記憶部４０１１のデータ構造の一例を、図２２に示す。図２２に示すように、配信メディアの種別情報（メディア種別）と、配信メディア（地上波デジタル放送サービス、および、インターネットＶｏＤサービス）上で一意にコンテンツを識別する情報（メディア依存コンテンツID）と、当該コンテンツのパッケージとしての、コンテンツクラス識別子が対応付けられている。図２２では省略しているが、コンテンツクラス識別子の属性情報（コンテンツパッケージ名、製作年月日、製作者などの配信メディアに依存しないコンテンツ情報）を別テーブルに管理しても構わない。図２２は、あくまで一例であり、複数の配信メディアを横断してコンテンツを紐付ける情報であれば、他の情報を含んでもよい。また、ある配信メディアにおけるコンテンツ識別子（コンテンツURI）を、コンテンツクラス識別子に代用しても構わない。

尚、図２２で示した情報は、第２変換用情報に対応し、情報閲覧装置３０２が提供可能なメディアを示す情報が、第1の機器に関する第２情報に対応する。

コンテンツ関連情報記憶部４０１２は、コンテンツURIに紐付けられたコンテンツ情報、または、コンテンツクラス情報に関連するコンテンツや商品の情報を記憶するものである。コンテンツクラス識別子と、関連情報を紐付けて記憶しても構わないし、メディア依存のコンテンツ識別子（コンテンツURI）と関連情報を紐付けて記憶しても構わない。

次に、情報処理装置４０１の動作を説明する。以下では、情報処理装置４０１の動作の、第３実施例との差異を説明する。差異点は、変換部３０６と、応答生成部１０１５の処理である。

まず、変換部３０６は、第２抽出部１０１４が抽出した情報から、要求機器が情報閲覧装置３０２（ラップトップＰＣ、タブレットＰＣなど、地上波デジタル放送受信チューナを有さない機器）であることを把握する。さらに、第３抽出部３０１１が抽出した情報から、操作対象機器（つまり、コンテンツ受信装置１０３）が存在しないことを把握してもよい。変換部３０６は、把握した情報から、情報閲覧装置３０２が、放送サービスを視聴できないことを判定し、コンテンツクラス情報記憶部４０１１から、コンテンツURIが指すメディア依存のコンテンツ（前述の実施例に示したように、ネットワークＩＤ、サービスＩＤ、トランスポートストリームＩＤ、開始時刻で特定されるコンテンツ）から、対応するインターネットＶｏＤサービスのコンテンツURIを取得する。これは、図２２に示すように、同じコンテンツクラス識別子を持ち、配信メディア種別がインターネットＶｏＤサービスである情報を、コンテンツクラス記憶部３１１から検索することで取得できる。図２２では、コンテンツ１とコンテンツ３が同じコンテンツクラス識別子を有するため、地上波デジタル放送番組（http://tv.nameservice.com/n_101/s_201/t_301/20101201190000）の、インターネットVoDサービスにおけるURIが、http://vod.example.com/101/201/301/20101201190000であることが分かる。

次に、応答生成部１０１５は、変換部３０６が取得したインターネットＶｏＤサービスにおけるコンテンツURIを、Ｗｅｂページにリンクとして埋め込む。Ｗｅｂページのテンプレートに埋め込む方法については、第１〜第３の実施例に示したとおりである。このとき、インターネットＶｏＤサービスにおけるコンテンツURI、もしくは、コンテンツクラス識別子をキーとして、関連コンテンツ情報記憶部３０６から、関連するコンテンツ・商品（シリーズコンテンツであった場合には、他シリーズのＶｏＤコンテンツや、ＤＶＤパッケージ等）を埋め込んでも構わない。生成されるＷｅｂページの具体例を図２３に示す。Ｗｅｂページを受信したユーザＢ（情報閲覧装置３０２）は、表示されたリンクをクリックすると、インターネットＶｏＤサービス（コンテンツ配信サービス提供装置３０６）上で公開された当該コンテンツにワンステップでアクセスできる。

以上のように、本実施形態によれば、配信メディアをまたがったコンテンツURI管理を行うことで、放送が視聴できない環境におけるユーザに、別の配信メディアにおけるコンテンツへのリンクを返すことできる。さらに、コンテンツ関連情報をＷｅｂページに埋め込むことで、広告や関連商品販売の機会を得る構成をとることも可能になっている。

以上説明した少なくとも１つ実施例の効果は、テレビ番組を特定するURIとインターネット上のサービスとの連携サービスを複数のユーザが利用する場合において、あるユーザが生成したURIを異なるユーザが利用する場合に、ユーザ間の環境の違いによらず、当該異なるユーザが、URIを利用したサービスを利用可能とすることである。

本発明のいくつか実施形態を説明したが、これら実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０１、２０１、３０１、４０１・・・情報処理装置、１０２、１０３・・・コンテンツ受信装置、１０４・・・サービス提供装置、３０２・・・情報閲覧装置、１０５、１０６、３０３・・・ネットワーク、１０１１・・・受信部、１０１２・・・送信部、１０１３・・・第１抽出部、１０１４・・・第２抽出部、１０１５・・・応答生成部、１０１６・・・応答情報記憶部、２０１１・・・変換部、２０１２・・・変換用情報記憶部、２０１３・・・コンテンツ情報記憶部 、３０１１・・・第３抽出部、４０１１・・・コンテンツクラス情報記憶部、４０１２・・・コンテンツ関連情報記憶部。

Claims (17)

1. コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第１の機器から受信する受信部と、
   前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出部と、
   複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部と、
   前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出部が抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成部と、
   を備える情報処理装置。
2. 前記第1要素情報は、前記コンテンツに関する時刻情報である請求項１記載の情報処理装置。
3. 前記要素情報を変換するための第1変換用情報を記憶する第2記憶部と、
   前記第1の機器に関する第1の情報と、前記第1変換用情報とをもとに、前記要素情報を変換する第1変換部と、を更に備える
   請求項１又は２記載の情報処理装置。
4. 前記第1の機器に関する第1の情報は、前記応答情報要求に含まれる情報である請求項３記載の情報処理装置。
5. 前記コンテンツ識別情報を変換するための第2変換用情報を記憶する第３記憶部と、
   前記第1の機器に関する第2の情報と、前記第2変換用情報とをもとに、前記コンテンツ識別情報を変換する第２変換部と、を更に備える
   請求項１又は４記載の情報処理装置。
6. 前記第1の機器に関する第２の情報は、前記応答情報要求に含まれる情報である請求項５記載の情報処理装置。
7. 前記第1変換用情報は、コンテンツ識別情報を構成する要素情報と、放送区域及び放送局の組み合わせとを対応付けた情報であり、前記第1の機器に関する第1の情報は、前記第1の機器の属する放送区域であり、
   前記第1変換部は、前記抽出部が抽出した要素情報と対応付けて記憶された放送区域が前記第1の機器の属する放送区域と異なる場合に、前記抽出部が抽出した要素情報を、前記第1の機器の属する放送区域及び前記抽出部が抽出した要素情報に対応付けられた放送局の組み合わせと対応付けられた要素情報に変換する
   請求項３又は６記載の情報処理装置。
8. 前記第2変換用情報は、コンテンツ識別情報と、前記コンテンツを提供するメディアの情報とを対応付けた情報であり、前記第1の機器に関する第2の情報は、前記第1の機器が提供可能なメディアを示す情報であり、
   前記変換部は、前記応答要求に含まれるコンテンツ識別情報によって特定されるコンテンツを提供するメディアが、前記第1の機器が提供可能なメディアと異なる場合に、前記第1の機器が提供可能なコンテンツのメディアに対応付けて記憶されたコンテンツ識別情報に変換し、
   前記生成部は、前記変換部が変換後の要素情報がみたす前記条件に対応する応答情報を含む応答メッセージを生成する
   請求項５又は７記載の情報処理装置。
9. 更に、第2抽出部を備え、
   前記応答情報要求は、更に、前記第1の機器にかかる機器情報を含み、
   前記第2抽出部は、前記応答情報要求から前記機器情報を抽出し、
   前記記憶部は、前記応答情報を、前記要素情報に関する条件と前記機器情報に関する条件との組み合わせと対応付けて記憶し、
   前記生成部は、前記第2抽出部が抽出した機器情報がみたす条件に対応する応答情報を含む応答メッセージを生成する
   請求項１又は８記載の情報処理装置。
10. 前記応答メッセージは、前記第１の機器に表示される情報を含む請求項９記載の情報処理装置。
11. 前記応答メッセージは、前記応答メッセージに対応する前記コンテンツに対する処理を実行できるようにするユーザインターフェース情報としての制御命令プログラムを含む請求項１０に記載の情報処理装置。
12. 前記制御プログラムは、前記コンテンツに対する処理を実行する実行機器の機種に応じて異なるプログラムである請求項１１記載の情報処理装置。
13. 前記コンテンツに関する情報であるコンテンツ要素情報を記憶するコンテンツ情報記憶部をさらに備え、
    前記生成部は、前記第応答メッセージに、前記コンテンツ要素情報を含める
    請求項１２記載の情報処理装置。
14. 前記生成部が生成した応答メッセージを前記第１機器に送信する送信部を備える請求項１３記載の情報処理装置。
15. 前記第１機器と、前記コンテンツに対する処理を実行する実行機器とが異なる場合に、前記生成部は、前記応答メッセージに、前記実行機器を制御するための制御プロトコル情報を含める請求項１４記載の情報処理装置。
16. コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第１の機器から受信する受信ステップと、
    前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出ステップと、
    複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部を参照し、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出ステップで抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成ステップと、
    を備える情報処理方法。
17. コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第１の機器から受信する受信機能と、
    前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出機能と、
    複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部を参照し、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出機能で抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成機能と、
    を備える情報処理プログラム。

Images