情報処理装置、情報処理方法及び情報処理プログラム
【課題】テレビ番組を特定するURIとインターネット上のサービスとの連携サービスを複数のユーザが利用する場合において、あるユーザが生成したURIを異なるユーザが利用する場合に、ユーザ間の環境の違いによらず、当該異なるユーザが、URIを利用したサービスを利用可能とする。
【解決手段】情報処理装置101は、コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第1の機器102から受信する受信部1011と、前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出部1013と、複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部1016と、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出部が抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成部1015と、を備える。
【解決手段】情報処理装置101は、コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第1の機器102から受信する受信部1011と、前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出部1013と、複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部1016と、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出部が抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成部1015と、を備える。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、情報処理装置に関する。
【背景技術】
【0002】
近年、テレビで放送される番組毎に、グローバルユニークな識別子であるURI(UniversAl Resource Identifier)を付与して、当該URIを利用して、インターネット上のサービスとテレビ放送番組とを連携したサービスを提供する動きがある。テレビ放送される番組毎に、URIを付与する方法として、テレビ放送の放送波に含まれるSI(Service Information)情報からURIを自動生成する方法が定められている(非特許文献1)。尚、この方法による場合、URIは、放送局等に依存した識別子となる。その結果、一つの番組でも、地域によって異なるURIが付与されることが想定される。
【0003】
テレビ放送される番組毎に、URIを付与して、テレビ番組と連携するインターネット上のサービスとして、例えば、SNS(Social Network Service)を想定できる。SNSにおいては、テレビ放送される番組に付与されたURIを複数のユーザ間で共有して利用することとなる。例えば、あるユーザAがユーザBに、現在視聴している番組を知らせる際に、同時に該当番組のURIを伝えると、ユーザBは、URIを利用することで(例えば、URIをクリックするなどの簡易操作を行うことで)、該当番組を視聴することができる。
【0004】
このようなテレビ番組を特定するURIとインターネット上のサービスを連携したサービス、特に、URIを複数のユーザ間で共有して利用するようなサービスの場合、いくつかの課題がある。具体的には、ユーザAが利用するテレビAが生成したURIを、ユーザBが利用するテレビBでは処理できないケースが起こり得る。例えば、テレビAがURIを生成した時刻から、一定時間経過した時点でテレビBがアクセスすると、既に該当番組が終了している場合があり得る。この場合、ユーザBは、URIをクリックするだけでは、URIによって特定される番組を視聴することができない。また、テレビA、B各々が属する放送区域が異なる場合、例えば、テレビAが東京にあり、テレビBが大阪にある場合、テレビAが生成したURIから、テレビBは、番組を特定できない。なぜなら、テレビ番組のURIは、テレビ番組の放送局等によって特定されるからである。
【先行技術文献】
【非特許文献】
【0005】
【非特許文献1】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)節
【発明の概要】
【発明が解決しようとする課題】
【0006】
本発明の一観点によれば、テレビ番組を特定するURIとインターネット上のサービスとの連携サービスを複数のユーザが利用する場合において、あるユーザが生成したURIを異なるユーザが利用する場合に、ユーザ間の環境の違いによらず、当該異なるユーザが、URIを利用したサービスを利用可能とする。
【課題を解決するための手段】
【0007】
本発明の一観点に係る情報処理装置は、コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第1の機器から受信する受信部と、前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出部と、複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部と、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出部が抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成部と、を備える。
【図面の簡単な説明】
【0008】
【図1】本発明の実施形態に係るシステムの構成を示すブロック図。
【図2】図1の応答情報記憶部1016のデータ構造の一例を示す図。
【図3】本発明の第1実施例に係るシステムの構成を示すブロック図。
【図4】図3のシステムの情報処理装置101の応答情報記憶部1016のデータ構造の一例を示す図。
【図5】図3の情報処理装置101を含むシステムの装置間のシーケンスを示した図。
【図6】図3の情報処理装置101の内部処理のフローチャート。
【図7】図3の情報処理装置101が応答するWebページのテンプレートの一例。
【図8】機器制御プログラムの擬似コードを示す図。
【図9】コンテンツURIのリンク先として、図3のコンテンツ受信装置103上に表示されるWebページの一例を示す図。
【図10】第2実施例にかかる情報処理装置201を含むシステムの構成を示すブロック図。
【図11】図10の情報処理装置201の変換用情報記憶部2012の記憶するデータ構造の一例を示す図。
【図12】図10の情報処理装置201のコンテンツ情報記憶部2013が記憶するデータ構造の一例を示す図。
【図13】図10の情報処理装置201の応答情報記憶部1016のデータ構造の一例を図。
【図14】図10の情報処理装置201の動作を示すフローチャート。
【図15】図10の情報処理装置201が応答する機器制御プログラムをリンクするWebページのテンプレートの一例。
【図16】図10の情報処理装置201が応答する機器制御プログラムの擬似コード。
【図17】図10のコンテンツ受信装置103上に表示されるWebページの一例を示す図。
【図18】第3実施例にかかる情報処理装置301を含むシステムを示すブロック図。
【図19】図18の情報処理装置301の応答情報記憶部1016のデータ構造の一例。
【図20】図18の情報処理装置301を含むシステムの機器間の動作シーケンス図。
【図21】第4実施例にかかる情報処理装置401を含むシステムを示すブロック図。
【図22】図21の情報処理装置401のコンテンツクラス情報記憶部4011のデータ構造の一例を示す図。
【図23】図22の情報閲覧装置302に表示されるWebページの一例を示す図。
【発明を実施するための形態】
【0009】
以下、本発明の実施の形態について、図面を参照しながら説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【0010】
図1は、実施形態にかかる情報処理装置101の構成を示すブロック図である。
【0011】
実施形態に係るシステムは、情報処理装置101と、コンテンツ受信装置102及び103と、サービス提供装置104とを備える。情報処理装置101と、コンテンツ受信装置102及び103と、サービス提供装置104とは、ネットワーク105で接続されている。また、コンテンツ受信装置102、103は、ネットワーク106から情報を受信する通信インタフェースを備えている。
【0012】
情報処理装置101は、受信部1011と、送信部1012と、第1抽出部1013と、応答生成部1015と、応答情報記憶部1016とを有する。
【0013】
受信部1011は、コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、コンテンツ受信装置103から受信する。
【0014】
第1抽出部1013は、受信部1011が受信したコンテンツ識別情報が構成する要素情報を抽出する。
【0015】
応答情報記憶部1016は、コンテンツ識別情報が構成する要素情報に関する条件各々と応答情報とを対応付けて記憶している。図2に、応答情報記憶部1016が記憶する情報の例を示す。応答情報記憶部1016は、要素情報に関する条件毎に対応付けて応答情報を記憶している。
【0016】
応答生成部1015は、応答情報記憶部1016が記憶する要素情報に関する条件のうち、第1抽出部1013が抽出した要素情報がみたす条件に対応づけて記憶された応答情報を含む応答メッセージを生成する。例えば、第1抽出部1013が抽出した要素情報が、図2の条件1を満たす場合、応答生成部1015は、条件1に対応付けて記憶された応答情報1を含む応答メッセージを生成する。
【0017】
送信部1012は、応答生成部1015が生成した応答メッセージを、コンテンツ受信装置103に送信する。
【0018】
以下の第1実施例では、以上説明した実施形態についての具体例を説明する。
【0019】
第1実施例では、コンテンツの例として、テレビ番組とする。また、コンテンツ識別情報の例として、コンテンツURI(Uniform Resource Identifier)とする。コンテンツURIは、Web上でテレビ番組を一意に特定する識別子である。また、コンテンツ識別子が構成する要素情報は、コンテンツURIを構成する値である、ネットワークIDとサービスIDとトランスポートストリームIDと、放送番組の開始時刻の4値とする。これら4値の各々を要素情報と称することとする。また、第1実施例では、応答情報記憶部1016が記憶する、コンテンツ識別情報が構成する要素情報に関する条件は、前述した4要素の1つである「放送番組の開始時刻」に関する条件であるとする。より具体的には、「現在時刻が、放送番組の開始前か否か」の条件であるとする。また、第1実施例における応答情報は、後述するように制御命令文字列と制御命令プログラムパスである。また、第1実施例における応答メッセージは、応答情報記憶部1016から取得した応答情報を埋めこんだWebページである。また、第1実施例の情報処理装置101は、更に、第2抽出部1014を備えている。
【0020】
<第1実施例>
まず、第1実施例の動作の概要を説明する。図3は、第1実施例にかかるシステムを示すブロック図である。
【0021】
図3において、ユーザAが、デジタルテレビ(コンテンツ受信装置102)で番組1(コンテンツ1)を視聴している場合を想定する。この場合に、ユーザAが、例えばリモコンに設けられた共有ボタンを押す等の何らかのアクションを行うと、コンテンツ受信装置102が、ソーシャルネットワークサービス上に「この番組を視聴しています(http://tv.example.info/network_101/service_201/ts_301/20101201190000」といったメッセージを送信する。このメッセージに含まれるURIが、Web上で番組1を一意に特定する識別子である(以降、この識別子をコンテンツURIと称する)。このコンテンツURIは、放送波に含まれるSI情報を利用してコンテンツ受信装置102が生成する。本実施例においては、ユーザBが、コンテンツ受信装置102が生成したメッセージを、デジタルテレビ(コンテンツ受信装置103)上で読む。ここで、ユーザBがコンテンツURIを選択(クリック)すると、URIに紐付けられた情報処理装置101上のWebページがコンテンツ受信装置103に表示される。この時、該当Webページには、既に番組が始まっていれば、「この番組を視聴する」ボタンが、番組がまだ始まっていなければ「この番組を予約する」ボタンが表示される。ユーザBは、画面に表示されたボタンを押下することで、ユーザAが送信した番組に対する視聴・録画予約のアクションを、簡単に実行できる。本実施例では、後述するように、コンテンツ受信装置102が生成したURIに対応する番組の開始時刻若しくは終了時刻と、URIをコンテンツ受信装置103上に表示する時刻との関係に応じて、Webページを、「番組を視聴」若しくは「番組予約」と切り替えることで、ユーザBが、上述の2つの時刻間の関係によらず、番組を視聴することができる。
【0022】
次に、以上のユースケースにおける、Webページを応答する情報処理装置101について、図3を用いて説明する。
【0023】
第1実施例に係るシステムは、情報処理装置101と、コンテンツ受信装置102及び103と、サービス提供装置104とを備える。情報処理装置101と、コンテンツ受信装置102及び103と、サービス提供装置104とは、ネットワーク105で接続されている。また、コンテンツ受信装置102、103は、ネットワーク106から情報を受信する通信インタフェースを備えている。
【0024】
次に、第1実施例のシステムを構成するネットワーク及び装置について説明する。
【0025】
ネットワーク105は、インターネット、または、品質保証された閉域網であるNGN(Next GenerAtion Network)などのIP(Internet Protocol)ネットワークである。本実施例においては、ネットワーク105は、インターネットであるとする。
【0026】
ネットワーク106は、コンテンツを配信するネットワークであり、地上波デジタル放送網、BS、CSなどの衛生放送網、ケーブルテレビ、NGN、インターネットなどを想定している。本実施例においては、ネットワーク106は、地上波デジタル放送網であるものとする。
【0027】
情報処理装置101は、CPU、主記憶、補助記憶で構成される、通常のコンピュータのハードウェア構成である。情報処理装置101は、ネットワーク105(インターネット)に接続する通信インタフェースを備え、インターネット上でコンテンツURIに対応するWebページを返すサービスを提供している。
【0028】
コンテンツ受信装置102、103は、情報処理装置101と同様、通常のコンピュータのハードウェア構成をとっており、コンテンツを表示するディスプレイと、キーボード、マウス、タッチパネル等の入出力インタフェースとを備えている。また、ネットワーク105とネットワーク106に対する通信インタフェースを備えている。具体的には、デジタルテレビ、ハードディスク・レコーダなどのデジタルAV機器、PC、スマートフォン、スレートデバイスなどである。本実施例においては、コンテンツ受信装置102、103共にデジタルテレビであるとする。
【0029】
サービス提供装置104は、情報処理装置101と同様のハードウェア構成である。サービス提供装置104は、ネットワーク105を介して、コンテンツ受信装置102、103のユーザ間のコミュニケーションを実現するソーシャルネットワークサービス等を提供する。本実施例においては、ソーシャルネットワークサービスとして、マイクロブログサービスを想定して説明する。
【0030】
次に、情報処理装置101のCPUが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について図3に則して説明する。
【0031】
情報処理装置101は、受信部1011と、送信部1012と、第1抽出部1013と、第2抽出部1014と、応答生成部1015と、応答情報記憶部1016とを有する。いずれも、CPUのプログラム実行時にRAMなどの主記憶部上に生成されるものである。
【0032】
このうち、応答情報記憶部305はデータベース管理システムである。これは、リレーショナルデータベース、XML(eXtensiBle Markup LAnguAge)データベース、Key/VAlueストアなど、不揮発もしくは揮発記憶領域上にデータを記憶し、指定したキーをベースにデータを取得できる機能を備えて入れば、実現方式は問わない。単一のデータベース管理システムで構築されている必要はなく、複数のデータベース管理システムを併用してもよい。これは、第2実施例以降における変換用情報記憶部、機種情報記憶部、関連コンテンツ情報記憶部についても同様である。
【0033】
以下、情報処理装置101の各部について説明する。
【0034】
受信部1011は、ネットワーク105上のコンテンツ受信装置103から、コンテンツURIに対応するWebページの取得要求を受信する。この時に利用される通信プロトコルは、HTTP、FTP等、TCPプロトコルをベースとしたものでもよく、TCP/IPベースに限定されない独自プロトコルであってもよい。実施例においては、インターネット上で両者とHTTP(S)リクエストを受信する、HTTPサーバの受信部である。
【0035】
送信部1012は、前記Webページの取得要求に対する応答(後述する応答生成部1015が生成する応答情報。具体的にはWebページ)を、コンテンツ受信装置102に送信する。利用されるプロトコルについては、受信部1011と同様である。本実施例においては、HTTP(S)レスポンスを送信するものであり、HTTPサーバの送信部である。
【0036】
第2抽出部1014は、受信部1011から受信したコンテンツURIに対するWebページの取得要求に含まれる、送信元のコンテンツ受信装置103にかかる情報を抽出する。具体的には、HTTPリクエストに含まれるUser−Agentヘッダ情報から、Webブラウザの種別や画面サイズ、機種情報等を抽出する処理や、IPアドレス等から地域情報を抽出する処理を行う。本実施例においては、HTTPを前提としたこれらの処理を想定しているが、他の通信プロトコルを前提とした、送信元の機器情報を抽出する他の仕組みであっても構わない。
【0037】
第1抽出部1013は、受信部1011で受信したコンテンツURIから、コンテンツが放送された地域、放送局、放送時間等の情報を抽出する。地上波デジタル放送においては、コンテンツを一意に識別する情報として、放送波にSI情報として含まれるネットワークID、サービスID、トランスポートストリームID、開始時刻の4値の組み合わせが利用できる。ネットワークIDは、地上波、BS放送、CS放送といった粒度の通信網を表す情報である。サービスIDは、放送局を識別する情報であり、系列で一意の識別子ではなく、地方放送局毎に付与される識別情報である。トランスポートストリームIDは、放送局が送出するストリーム(MPEG-2 TS)を識別するための番号である。開始時刻は、放送番組の開始時刻である。以上の4値をもって、番組を一意に識別することができる。
【0038】
コンテンツURIが、この4値を含むように構成されている場合、第1抽出部1013は、URI解析によって、これら4つの値を抽出する。具体的には、ネットワークIDが101、サービスIDが201、トランスポートストリームIDが301、開始時刻が2010年12月1日19時であった場合に、コンテンツURIは、例えば、以下のように表現できる。第1抽出部1013は、このURIから、各値を取得する処理を行う。
【0039】
http://tv.nameservice.com/n_101/s_201/t_301/20101201190000
なお、コンテンツURIの形式は、上記フォーマットに限定されるものではない。対象が、放送コンテンツである場合であっても、開始時刻情報の代わりにイベントID情報を利用する等、他の方法もある。ネットワーク106上でコンテンツを一意に識別するための情報が含まれる範囲においては、他のフォーマットであっても構わない。
【0040】
応答生成部1015は、第1抽出部1013及び第2抽出部1014で抽出した情報に基づき、コンテンツURIに対応する応答情報を生成する。応答情報は、例えば、HTMLデータ(Webページ)、XMLデータ、あるいは、JSON(JavaScript Object Notation)データなど様々な形式のデータが想定できる。ここでは、Webページを返すものとする。本実施例では、例えば、第1抽出部1013が抽出した開始時刻情報を利用し、現在時刻が、番組の開始時刻を過ぎている場合に、Webページとして、チャンネル変更ボタンと、ボタン押下をトリガに実行される機種に応じたチャンネル変更命令プログラムとを埋め込んだページを返す。また、現在時刻が、開始時刻より前である場合には、Webページとして、録画予約ボタンと、ボタン押下をトリガに実行される機種に応じた録画予約命令プログラムを埋め込んだWebページを返す。
【0041】
応答情報記憶部1016は、第1抽出部1013及び第2抽出部1014で抽出した情報と、応答情報を対応付けて記憶する。また、応答生成部1015からの前記属性情報をキーとした応答情報取得要求を受けて、対応する応答情報を返す。図4は、応答情報記憶部1016のデータ構造の一例を示すものである。図4に示すように、コンテンツの時制(時刻条件と称する。)(開始時刻前か否かを表すブール値)、制御命令文字列(「録画予約する」「視聴する」等、ボタンに表示する文字列)、制御プログラムパスの4つのカラムで構成されている。これは、Webページ上に、該当コンテンツに対する1つの操作ボタン(「録画予約する」あるいは「視聴する」の2種類)を表示するというシンプルな目的に特化したデータ構造であり、応答するWebページの内容に応じて、さらに多くの情報で構成してもよいし、反対に、より少ない情報で構成してもよい。尚、本例では、開始時刻に応じた処理のみを説明しているが、終了時刻に応じた処理のバリエーションも想定できる。例えば、図4のカラム名として、終了時刻前か否かをいれ、終了時刻前か否かに応じて、応答情報を変更するようにしてもよい。この場合、終了時刻前か否かを、たとえば、コンテンツの終了時刻を取得し、現在時刻と終了時刻を比較して、判断する。このように、開始時刻や終了時刻を時刻条件と称することとする。また、図4の時刻条件は、図2の要素情報に関する条件に対応する。また、図4の制御命令文字列と制御命令プログラムパスは、図2の応答情報に対応する。図4に示すように、第1実施例の応答情報記憶部1016は、複数のエントリについて、要素情報に関する条件毎に、応答情報を記憶している。
【0042】
次に、図3〜図9を用いて、本実施例に係る情報処理装置101の動作について説明する。図5は、本実施例に係る情報処理装置101を含むシステム構成要素間のシーケンスを示した図である。図6は、情報処理装置101の内部処理のフローチャートである。図7は、情報処理装置101が応答するWebページのテンプレートの一例である。図8は、機器制御プログラムの擬似コードを示すものである。図9は、コンテンツURIのリンク先として、コンテンツ受信装置103上に表示されるWebページの一例を示す図である。
【0043】
まず、本実施例の前提として、2人のユーザを想定する。コンテンツ受信装置102のユーザ(ユーザA)と、コンテンツ受信装置103のユーザ(ユーザB)である。ユーザAとユーザBは共に、他ユーザとのコミュニケーションを実現する、サービス提供装置104が提供するSNSに加入している。また、コンテンツ受信装置102、103は、このSNSにメッセージを送信したり、メッセージを閲覧したりするSNSクライアント機能と搭載しているものとする。
【0044】
以下、図5のシーケンス図をベースに処理手順を説明する。図5は、情報処理装置101を含むシステムの装置間のシーケンスを示した図である。
【0045】
まず、ユーザAがコンテンツ受信装置102上で、コンテンツ(地上波デジタル放送番組)視聴中に、リモコンもしくは画面上に表示された「この番組をみんなに薦める」ボタンを押す(ステップS101)。コンテンツ受信装置102は、ボタン押下のイベントを受けて、受像している番組を識別する情報(ネットワークID、サービスID、トランスポートストリームID、開始時刻の4値)をSI情報から取得する(ステップS102)。続いて、コンテンツ受信装置102は、この4値を用いて、コンテンツURIを生成する(ステップS103)。前述したように、受像中の番組のネットワークIDが101、サービスIDが201、トランスポートストリームIDが301、番組の開始時刻が2010年12月1日19時である場合に、生成されるコンテンツURIは、http://tv.nameservice.com /n_101/s_201 /t_301/20101201190000となる。続いて、コンテンツ受信装置102は、生成したコンテンツURIを引用したメッセージ(例えば、「この番組を視聴していますhttp://tv.nameservice.com/n_101/s_201/t_301/20101201190000」など)を生成する(ステップS104)。このとき、ネットワークID等と同様に、当該番組のタイトル文字列情報を、SI情報から取得し、これをメッセージに含めてもよいし(「番組XXXを視聴しています。http://... 」)、あるいは、コンテンツURIがデフォルトで入力されたテキストボックスを表示してユーザにメッセージを入力を促すように構成してもよい。メッセージ生成のフォーマット、実現形式は問わない。コンテンツ受信装置102は、生成したメッセージを、ネットワーク105上のサービス提供装置104に送信する(ステップS105)。本実施例においては、このメッセージ送信は、HTTP POSTメソッドで送信されるものとするが、HTTP PUTやGETなど別のメソッドであってもよく、HTTPプロトコルに限定されるものでもない。
【0046】
サービス提供装置104は、コンテンツ受信装置102から該当メッセージを受信すると、ユーザAのメッセージを購読しているユーザBを同定し(ステップS106)、ユーザB(すなわち、コンテンツ受信装置103)に対して同メッセージを送信する。この送信シーケンスは、コンテンツ受信装置103上のSNSクライアントが、定期的にサービス提供装置104に対して、メッセージの有無を問い合わせるポーリングによって実現してもよいし、サービス提供装置104からコンテンツ受信装置に対して、メッセージをプッシュするように実現してもよい。本実施例においては、前者の方法で実現されるものとする。具体的には、コンテンツ受信装置102がHTTP GETリクエストによって、購読対象(ユーザA)からの新着メッセージを要求(ステップS107)し、結果を受信する(ステップS108)。この通信プロトコルについては、ステップS105と同様、様々な実現方式(通信プロトコル)が許容される。なお、後者の方法については、コンテンツ受信装置104がHTTPクライアント、コンテンツ受信装置103がHTTPサーバとしてふるまうように実現する方法や、HTTPロングポーリングや、WebSocketを利用して、コンテンツ受信装置103側が、サービス提供装置104に対するTCPコネクションを生成、維持し、このコネクションを利用して、サービス提供装置104がコンテンツ受信装置102に対してメッセージを送信する方法などが考えられる。
【0047】
次に、コンテンツ受信装置103は、受信したユーザAからのメッセージをコンテンツ受信装置103の画面上に表示する(ステップS109)。ここまでの処理で、ユーザBのコンテンツ受信装置103の画面上に、ユーザAの送信したコンテンツURIを含むメッセージが表示されることになる。
【0048】
ここで、ユーザBが、ユーザAの「この番組を視聴しています。http://tv.name service.com/n_101/s_201/t_301/20101201190000」メッセージを閲覧し、このコンテンツURIを選択する(ステップS110)。選択方法は、ポインティングデバイスでクリックする、あるいはリモコンで選択・決定するなど、様々な方法が考えられる。この選択処理をトリガとして、コンテンツ受信装置103は、情報処理装置101に対してアクセスする(すなわち、コンテンツURIに紐付けられたWebページの取得要求を送信する)(ステップS111)。これは、通常のHTMLにおけるハイパーリンクを辿る手段と同じであり、HTTP GETリクエストによって実現される。
【0049】
情報処理装置101は、Webページの取得要求を受信して、コンテンツURI処理(コンテンツURI解析と対応するWebページの生成)を行ない(ステップS112)、コンテンツURIに対応するWebページを、コンテンツ受信装置103に応答する(ステップS113)。
【0050】
ここで、情報処理装置101におけるステップS112のコンテンツURI処理を、図6のフローチャートを用いて説明する。
【0051】
情報処理装置101の受信部1011は、Webページの取得要求を受信し、これを第2抽出部1014に渡す(ステップS1001)。第2抽出部1014は、受信要求に含まれる情報から、送信元のコンテンツ受信装置103にかかる情報を抽出する(ステップS1002)。具体的には、HTTPリクエストに含まれるUser−Agentヘッダから、コンテンツ受信装置103上に搭載されているWebレンダリングエンジンの種類やバージョン、画面サイズ情報を取得する。ここでは、Webページのレイアウトを決定する画面サイズを取得する。続いて、第1抽出部1013が、コンテンツURI自体を解析し、地上波デジタル放送上で、コンテンツを一意に識別するための4値(ネットワークID、サービスID、トランスポートストリームID、開始時刻)を取得する(ステップS1003)。これは、前述したとおり、本実施例では、それぞれ101、102、103、2010年12月1日19:00である。次に、応答生成部1015が、第2抽出部1014が抽出した画面サイズ、第2抽出部1013が抽出した4値を入力に取り、まず、現在時刻(アクセス時刻)をシステムから取得し(ステップS1004)、現在時刻とコンテンツの開始時刻とを比較し、現在時刻がコンテンツの開始時刻前か否かを判定する(ステップS1005)。続いて、応答生成部1015は、応答情報記憶部1016から機種情報と開始前か否かのブール値をキーとして、制御命令文字列と制御命令プログラムパス(URL:Universal Resource Locator)を取得する(ステップS1006)。ここでは、コンテンツ受信装置103からの取得要求の時刻(つまり現在時刻)が、コンテンツの開始時刻後であったとして、図4における1番目のエントリ(http://tv.nameservice.com/apis/changeChannel.js)が取得される。応答生成部1015は、図7に一例を示す、Webページのテンプレートに、機器操作プログラムへのパス情報、制御命令文字列、および、コンテンツURIから取得した4値を埋め込む。具体的には、図7の$1, $2, $3, $4, $5, $6に、それぞれの値を埋め込み、応答メッセージ(Webページ)を生成し(ステップS1007)、送信する(ステップS1008)。
【0052】
続いて、図5を用いて、コンテンツ受信装置103の挙動について説明する。コンテンツ受信装置103は、情報処理装置101からの応答メッセージを受信すると、これをディスプレイ上に表示する(ステップS114)。表示されるWebページの一例を、図9に示す。本実施例では、「この番組を視聴する」ボタンが表示される。ユーザBが表示されたボタンを押下すると(ステップS115)、図8の&&&TODO行目のチャンネル変更API(Application Program Interface)(device.execute (networkId, serviceId, transportStreamId, startDate))が呼び出される。この例では、API内部で呼び出されている機器制御関数(setChannelNative(networkId, serviceId, transportStreamId))が、実際にコンテンツ受信装置103の受像チャンネルを、与えられたパラメータに応じて変更する(ステップS116)。なお、ユーザBが、当該コンテンツURIをクリックした時刻が、コンテンツの開始時間よりも前であった場合には、情報処理装置101は、ステップS1006において録画予約のための制御プログラムを取得し、コンテンツ受信装置103上に表示されるボタンは、「この番組を録画予約する」となる。
【0053】
以上のように、本実施例の情報処理装置101によれば、コンテンツURIを処理する時点での、コンテンツの時制(開始時刻を過ぎたか否か)の変化に合わせて、すなわち、コンテンツの時制という属性値の発信側(コンテンツ受信装置102)と受信側(コンテンツ受信装置103)の差異に関わらず、複数機器間で当該コンテンツURIをシェアし、これを利用した機器操作を簡単に実現できている。本実施例において、ユーザBによる、コンテンツ受信装置103のチャンネル変更/録画予約までの操作ステップは、コンテンツURIの選択と、選択の結果表示されたWebページのボタン押下の2ステップである。さらに、ボタン押下というユーザアクションを省略し、Webページのコンテンツ受信装置103での読み込みをトリガとして、上記のdevice.execute関数を自動実行することも可能である。この場合は、ユーザBは、コンテンツURIのリンクを辿る(クリックする)という1アクションで、実機器の操作を行うことが可能になる。
【0054】
尚、情報処理装置101は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、受信部1011、送信部1012、第1抽出部1013、第2抽出部1014、応答生成部1015、応答情報記憶部1016は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、情報処理装置101は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD−ROMなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、応答情報記憶部1016は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD−R、CD−RW、DVD−RAM、DVD−Rなどの記憶媒体などを適宜利用して実現することができる。
【0055】
<第2実施例>
次に、図10を用いて、第2の実施の形態の情報処理装置201について説明する。
【0056】
まず、本実施例の想定する具体的なユースケースについて説明する。
【0057】
第1実施例と同様、ユースケースの骨子は、ユーザAによるコンテンツURIを引用したメッセージを、ユーザBが閲覧するとともに、このコンテンツURIをクリックすることで機器を制御するというものである。第2実施例と第1実施例との差分は、2つある。第1に、ユーザBが属する放送区域が、ユーザAの属する放送区域と異なる点である。そして、情報処理装置201は、ユーザB及びAが異なる放送区域であっても、ユーザB及びAがコンテンツURIを利用したサービスを障害なく利用できるようにしている。第2に、第1実施例においては、全ての操作対象機種が共通化された同じAPIを利用していたが、第2実施例では、そうではない点である。すなわち、第2実施例では、情報処理装置201は、操作対象機器の機種やメーカ毎にWebページからアクセスするための異なるAPIセットを持っていて、操作対象機器に合わせて、呼び出すAPIを変更することができるようにしている。
【0058】
図10は、情報処理装置201の構成を示すブロック図である。
【0059】
以下、情報処理装置201と情報処理装置101との差分を説明する。
【0060】
情報処理装置201のハードウェア構成は第1実施例と同様であるが、新たな機能ブロックとして、変換部2011、変換用情報記憶部2012、コンテンツ情報記憶部2013が追加されている。いずれも、CPUのプログラム実行時にRAMなどの主記憶部上に生成されるものである。
【0061】
まず、情報処理装置201と情報処理装置101との差分として、新たな機能ブロックの説明をする。
【0062】
変換部2011は、コンテンツURIを、Webページ取得要求元の環境に応じて変換する。この際、第2抽出部1014が抽出する情報と、後述する変換用情報記憶部2012に記憶された情報に基づいて変換する。本実施例においては、コンテンツ受信装置103の放送区域のチャンネル編成に合わせて、コンテンツURIに含まれる放送コンテンツの識別情報を構成するネットワークID、サービスID、(および、トランスポートストリームID)を変更する。
【0063】
変換用情報記憶部2012は、変換部2011がコンテンツURIの変換に利用する情報を記憶する。例えば、本実施例においては、地域毎のチャンネル編成の対応関係を管理する。図11は、変換用情報記憶部2012の記憶するデータ構造の一例を示すものである。図11に示すように、地域及び放送系列毎の放送局情報(ネットワークID、サービスID(、トランスポートストリームID))を管理する変換部2011は、この変換用情報記憶部2012を利用して、コンテンツ受信装置102上で生成されたコンテンツURIのネットワークIDとサービスIDから放送系列を同定し、コンテンツ受信装置103の放送区域における同放送系列のネットワークIDとサービスIDを求め、この値でコンテンツURIを変換する。すなわち、図11は、コンテンツURIの変換のために、機器情報に含まれる放送区域情報を用い、変換対象が放送局情報(ネットワークID+サービスID)であることを想定したデータ構造になっている。これはあくまで一例であり、様々なバリエーションが考えられる。例えば、変換対象がネットワークIDのみ(例えば、地上波からBSへの変換)であってもよく、変換対象がコンテンツの開始時間までも含むもの(地域によって開始時間までも異なる場合)であってもよい。
【0064】
それぞれのバリエーションによって、変換用情報記憶部2012のデータ構造は異なり、各バリエーションにおける変換対象の情報と、変換に用いる情報とを含むものとなる。
【0065】
尚、図11で示した情報は、第1変換用情報に対応し、コンテンツ受信装置103の放送区域が、第1の機器に関する第1情報に対応する。 コンテンツ情報記憶部2013は、コンテンツ識別情報と、コンテンツの様々な属性(メタデータ)を記憶する。例えば、番組タイトルやジャンル、出演者、番組の説明文、開始時間や終了時刻(あるいは、尺)などである。図12は、情報処理装置201のコンテンツ情報記憶部2013が記憶するデータ構造の一例を示す図ある。本実施例においては、図12に示すように、タイトルと開始時刻、終了時刻、番組説明文を管理しているものとする。この構成は一例であり、現在、放送波のSI情報に含まれるあらゆる番組メタデータや、当該番組に関連する商品や類似番組、シリーズ番組などの番組に付随する情報も合わせて管理してもよい。
【0066】
情報処理装置201と情報処理装置101との差分として、情報処理装置101が有す構成要素であるが、異なる機能を有する構成要素を説明する。
【0067】
応答情報記憶部1016の、情報処理装置101の応答情報記憶部1016のデータ構造からの変更点について説明する。第2実施例における応答情報記憶部1016のデータ構造の一例を図13に示す。第1実施例との差分は、機種情報が追加されている点、当該機種情報ごとに制御命令プログラムパスが異なる点にある。すなわち、コンテンツ受信装置が外部公開する機能(チャンネル変更や録画予約)のインタフェース(API)が、機種ごとに独自のものであった場合には、アクセス元(コンテンツ受信装置)の機種情報に応じた応答情報(制御命令プログラム)が必要になる。図13の機種情報(条件1)は、第2抽出部1014が抽出した、アクセス元の機器の機器情報に関する条件に対応する。また、図13の「放送中か否か」(条件2)は、図2の要素情報に関する条件に対応する。また、図13の制御命令文字列と制御命令プログラムパスは、図2の応答情報に対応する。第2実施例の応答情報記憶部1016は、複数のエントリについて、機器情報に関する条件(条件1及び)要素情報に関する条件(条件2)毎に、応答情報(制御命令文字列及び制御命令パス)を記憶している。 次に、図10〜図17を用いて、情報処理装置201の動作を説明する。図17は、情報処理装置201の内部処理のフローチャートを示したものである。図15、図16は、それぞれ本実施例における情報処理装置201が応答するWebページのテンプレートの一例と、Webページにリンクされる機器制御プログラムの擬似コードを示すものである。図17は、コンテンツURIのリンク先として、コンテンツ受信装置103上に表示されるWebページの一例を示す図である。
【0068】
本実施例のシステム構成は、第1実施例と同様であり、システム構成要素間の通信シーケンスも、第1実施例と等しく、図5に従う。ここでは、本実施例における差分のみについて、図3を用いて説明する。
【0069】
第1の差分は、コンテンツURIに基づくWebページ取得要求(ステップS111)において、コンテンツ受信装置103が、属する放送区域情報を送信する点である。この放送区域の情報は、HTTP GETメソッドによる送信時にコンテンツURIにクエリ文字列として追加して送ってもよいし、あるいはリクエストヘッダに独自項目を追加し、そのフィールドに埋め込んでもよい。あるいは、HTTP POSTメソッドによるリクエストの形式をとり、リクエストボティに埋め込んでもよい。なお、別の方法として、情報処理装置201が、ユーザの属する放送区域を、IPアドレスや経由したネットワーク上のノード情報から算出する方法が考えられる。この場合は、精度面では劣るが、コンテンツ受信装置103が、明示的に放送区域情報を送信せずに済む。
【0070】
第2の差分は、情報処理装置201におけるコンテンツURI処理(ステップS112)である。図14のフローチャートを用いて説明する。第1実施例(図6)との差分は、まず、コンテンツURIの解析処理(ステップS2003)の後に、コンテンツURIの変換処理が入る点である。変換部2011は、変換用情報記憶部2012を利用して、ユーザAの環境におけるコンテンツURIをユーザBの環境に合わせたものに変換する。
【0071】
例えば、ユーザAが東京、ユーザBが大阪の場合、図11に情報に基づき、ネットワークID(101)、サービスID(201)、トランスポートストリームID(301)の3値とユーザAの放送区域(東京)から、ユーザAの視聴している番組の放送局系列識別子が1であることがわかる。同じ放送局系列識別子(1)と、ユーザBの属する放送区域(大阪)から、ユーザBの環境における当該コンテンツの上記3値は、101、203、303である。すなわち、変換後のコンテンツURIは、以下のようになる。
【0072】
http://tv.nameservice.com/n_101/s_203/t_303/20101201190000
なお、この変換後のコンテンツURIは、あくまでコンテンツURI形式にシリアライズした場合の例であり、実際は、情報処理装置201の内部処理として、コンテンツURIを構成するコンテンツ識別情報(本実施例の場合は、ネットワークID、サービスID、トランスポートストリームID、開始時刻の4値)の変換のみに留めてよい。
【0073】
変換部2011の処理は、変換元の{ AreaId, NetworkId, ServiceId, TransportStreamId}の4値から、ServiceGroupIdを導出し、このServiceGroupIdと変換先のAreaIdから、変換先の{NetworkId, ServiceId, TransportStreamId}を求める処理になる。
【0074】
続いて、応答生成部1015が、(変換前もしくは変換後の)コンテンツURIから、図12に示した情報を用いて、コンテンツ情報を取得する(ステップS2005)。コンテンツ情報を取得することにより、図17に示すように生成するWebページに番組情報を含めることができる。また、番組の終了時刻(あるいは尺)情報を参照することで、現在時刻に番組が終了しているか否かを判定することができる。第1実施例においては、時制の判定材料に開始時刻のみを利用していたが、終了時刻を利用することで、図14のように、放送中か否かを判定することが出来る。本実施例では、現在時刻を参照し(ステップS2006)、既に番組が終わっている場合には、(例えば「既にこの番組は終了しています」等の)エラーメッセージページを生成して(ステップS2009)、これを送信する(ステップS2011)。 一方、番組が終っていない場合には、時制と、第2抽出部1014で抽出した機種情報に基づき、応答情報記憶部1016から、機種に応じた機器制御プログラムや、表示文字列などの図15に一例を示したWebページテンプレートに設定する諸情報を取得する(ステップS2008)。この情報をテンプレートに設定し、Webページを生成し(ステップS2009)、これを送信する(ステップS2010)。Webページのテンプレートには、図15に示すように、コンテンツ情報記憶部2013から取得した放送局、タイトル、番組説明を挿入する変数($2, $3, $4)が追加されており、応答生成部1015は、この3つを含めた、コンテンツ情報記憶部2013、応答情報記憶部1016から取得した合計9つの変数を、図14のテンプレートに埋め込む。以上が、コンテンツURI処理の第1実施例との差分となる。
【0075】
第3の差分は、コンテンツ受信装置103の表示するWebページである(ステップS114)。図17に示すように、コンテンツ情報記憶部2013の情報が、Webページに反映されている。
【0076】
第4の差分は、ボタン押下で実行される機器制御プログラムである。図16に示すように、APIの内部で呼び出される関数(録画予約)がreserve_42xx001()となっている。つまり、デジタルテレビ42X001向けのコードが埋めこまれている。応答生成部1015が、機種に応じた機器制御プログラムをリンクすることで、内部機能へのアクセスAPIの標準規格が存在しない場合でも、本実施例は実現可能であることを示している。
【0077】
以上のように、本実施例によれば、ユーザAとユーザBの属する放送区域が異なる場合であっても、コンテンツURIを、ユーザの環境に合わせて変換することで、コンテンツURIを適切に処理する(実機器操作につなげる)ことができる。また、機器の内部機能を利用するためのAPI標準が存在しない場合であっても、機種に応じた制御プログラムを動的に埋め込むことで、コンテンツURIからの実機器操作を実現できている。
【0078】
<第3実施例>
図18は、第3実施例にかかる情報処理装置301である。
【0079】
まず、第3実施例の想定する具体的なユースケースについて説明する。
【0080】
第1、2実施例と同様、第3実施例のユースケースの骨子は、ユーザAによるコンテンツURIを引用したメッセージを、ユーザBが閲覧し、このコンテンツURIをクリックすることで機器を制御するというものである。第1及び2実施例との差分は、2つある。第1は、ユーザBがデジタルテレビ(コンテンツ受信装置103)を操作しているのではなく、PCもしくはタブレット端末を利用しているという点である。具体的には、ユーザBは、テレビの前で、ラップトップPC上でSNSを閲覧しており、ユーザAが提示するコンテンツURIをクリックすると、ネットワーク経由でコンテンツ受信装置103の制御を行う。第2は、放送が終了している番組についても録画済みであれば再生を行う、という機器制御を想定している点である。
【0081】
図18は、本発明の第3実施例に係る情報処理装置301の機能ブロックを含むシステム構成図である。システム構成上の第1実施例(図3)との差分は、ネットワーク303と情報閲覧装置302が追加されている点にある。
【0082】
ここで、ネットワーク303は、ネットワーク105と同様、IP(Internet Protocol)ネットワークであり、特に宅内LANを想定している。
【0083】
情報閲覧装置302は、前述した本実施例のユースケースにおける、ラップトップPCに対応するものである。したがって、コンテンツ受信装置102、103と同様、CPU、主記憶、補助記憶で構成される、通常のコンピュータのハードウェア構成となっている。
【0084】
次に、情報処理装置301について、第2実施例にかかる情報処理装置201との差分を説明する。情報処理装置301のハードウェア構成は情報処理装置201と同様であるが、新たな機能ブロックとして、第3抽出部3011が追加されている。
【0085】
第3抽出部3011は、情報閲覧装置302がWebページ取得要求時に付与する操作対象機器情報、あるいは、プロトコル情報を抽出する。具体的には、情報閲覧装置302は、コンテンツURIを利用した実機操作(チャンネル変更等)を自機器で行わない場合に、周辺機器の機種情報や、発見・遠隔操作するためのプロトコル情報をWebページ取得要求に含める。これは、既存のHTTPリクエストヘッダを利用して、この情報を追加するようにしてもよいし、新たなHTTPリクエストヘッダを設けてもよいし、リクエストURL(すなわちコンテンツURI)に含めてもよいし、あるいは、HTTP POSTリクエストを利用し、HTTPペイロードに記述するようにしてもよい。
【0086】
次に、応答情報記憶部1016のデータ構造の変更点について説明する。本実施例における応答情報記憶部1016のデータ構造の一例を図19に示す。第2実施例の応答情報記憶部1016との差分として、制御プロトコル情報が追加されている。これは、コンテンツ受信装置103が周辺機器にコンテンツURI操作を要求するための制御プロトコルを特定するものである。図19の機種情報(条件1)は、第2抽出部1014が抽出した、アクセス元の機器の機器情報に関する条件に対応する。図19の「時制」(条件3)は、図2の要素情報に関する条件に対応する。本実施例では、上述した条件に加えて、更に、制御プロトコル情報に関する条件(条件2)を記憶している。また、図19の制御命令文字列と制御命令プログラムパスは、図2の応答情報に対応する。第3の実施例の応答情報記憶部1016は、複数のエントリについて、及び機器情報に関する条件(条件1)及び制御プロトコル情報に関する条件(条件2)及び要素情報に関する条件(条件3)毎に、応答情報(制御命令文字列及び制御命令パス)を記憶している。 次に図14、図18〜図20を用いて、情報処理装置301の動作を説明する。図20は、情報処理装置301を含むシステム構成要素間の基本シーケンスを示したものである。
【0087】
以下、図20のシーケンス図をベースに処理手順を説明する。
【0088】
まず、ステップS301からステップS310までの処理は、第1実施例におけるステップS101からS110までと同じであるため説明を省略する。この時点で、ユーザBの情報閲覧装置302の画面上に、ユーザAの送信したコンテンツURI(第1実施例と同様、http://tv.name service.com/n_101/s_201/t_301/20101201190000 であるとする)を含むメッセージが表示され、ユーザBがこのコンテンツURIをクリックしたことになる。
【0089】
以降の動作については、第2実施例との差分のみを説明する。
【0090】
動作シーケンスの第1の差分は、ステップS311の操作機器情報取得処理が追加されている点である。情報閲覧装置302は、webページ取得要求メッセージに、webページを用いて操作する制御対象機器に関する情報を取得し(ステップS311)、この情報を埋め込んで送信する(ステップS312)。これは、前述したようにHTTPリクエストヘッダ、ペイロード、クエリ文字列等様々な実現方式が考えられる。なお、埋め込む情報は、プロトコル情報だけでもよいし、機種情報、宅内IPアドレス/ポート番号情報、メールアドレスなど、ネットワーク105を介したリモートアクセスに必要な他の情報を埋めこんでもよい。前者の場合は、制御プロトコルに基づいて実際に制御する機器を発見・特定し、制御命令を送信するまでの一連の処理を制御プログラムに埋め込む必要があるが、後者の場合は、発見処理を割愛できる。本実施例においては、図19に示すように、制御プロトコル情報のみを含むものとする。
【0091】
動作シーケンスの第2の差分は、ステップS313のコンテンツURI処理である。処理のフローチャートは第2実施例のフローチャート(図14)と同様であるが、ステップS2002の端末側情報抽出処理において、前記の制御対象機器情報を抽出する点と、ステップS 2008の機器制御プログラム取得処理において、得られた機種情報およびプロトコル情報をキーとして情報を取得する点において異なっている。
【0092】
第3の差分は、情報閲覧装置302がWebページを取得し、ユーザBがWebページ上のボタンをクリックした後の処理である。図14のステップS2008において、図19のエントリ1が選択された場合、Webページには、DLNAプロトコルをベースにした機器発見、機器制御プログラムが埋めこまれている。ユーザBが「録画コンテンツを再生する」ボタンをクリックすると、情報閲覧装置302は、DLNAプロトコルに基づく、機器発見ステップ(DLNA Search)を実行し、録画コンテンツを管理するCDS(Content Directory Service)を有する機器として、コンテンツ受信装置103を発見する(ステップS317、S318)。続いて、情報閲覧装置302は、発見されたコンテンツ受信装置103に対して、ネットワークID、サービスID、トランスポートストリームID及び開始時刻の4値をキーとした、コンテンツ検索・再生ステップ(DLNA Action)を実行する(ステップS319)。コンテンツ受信装置103は、対象コンテンツが録画済みであれば、要求された再生処理を行ない(ステップS320)、正常実行した旨を応答する(ステップS321)。録画していなければ、検索エラーメッセージを応答する。
【0093】
以上のように、本実施例によれば、コンテンツURI処理を要求する機器以外の機器を操作対象とすることができる。すなわち、ラップトップPCでSNSを閲覧している状況で、近くのデジタルテレビにコンテンツURIに基づく実機器操作を実行させることが可能になっている。
【0094】
<第4実施例>
図21は、第4実施例にかかる情報処理装置401を含むシステムを示すブロック図である。
【0095】
本実施例の想定する具体的なユースケースについて記す。
【0096】
第1、2、3実施例と同様、第4実施例のユースケースの骨子は、ユーザAによるコンテンツURIを引用したメッセージを、ユーザBが閲覧し、このコンテンツURIをクリックすることで、コンテンツURIに紐付けられたコンテンツを視聴・予約等を行うものである。第4実施例の、第1、2、3実施例との差分は、3つある。第1の差分は、図21に示すように、第4実施例にかかる情報処理装置401を含むシステムが、コンテンツ受信装置103を備えておらず、ユーザBが情報閲覧装置302のみを保持している点である。第2の差分は、コンテンツURIに紐付けられているのが、放送コンテンツではなく、ネットコンテンツであるという点である。第3の差分は、情報処理装置401がWebページに関連情報を付与して送信する点である。より具体的には、ユーザBは、ラップトップPC上でSNSを閲覧しており、テレビを所有していない(第1の差分に対応する。)。そして、ユーザAが提示するコンテンツURIをクリックすると、当該コンテンツは放送コンテンツであるが、ユーザBはテレビを有していないので、放送経由では視聴できない。情報処理装置401は、「この番組をインターネットで視聴する」ボタン(インターネット上のVoD(Video On Demand)サービス上で公開された当該コンテンツのURIへのリンク)を含むページを返す(第2の差分に対応する。)。このとき、ページには、当該コンテンツに関連するコンテンツ・商品情報も埋め込んで返す(第3の差分に対応する)。
【0097】
以下、本実施例の詳細について、図21を用いて説明する。
【0098】
本実施例のシステム構成上の第3実施例との差分は、ネットワーク303とコンテンツ受信装置103が無い点と、ネットワーク105上のコンテンツ配信サービス提供装置402が追加されている点である。
【0099】
コンテンツ配信サービス提供装置402のハードウェア構成は、サービス提供装置104と同様である。コンテンツ配信サービス提供装置402が提供するサービスは、放送局が、放送後の番組を有料配信するVoDサービスや、一般的なビデオ共有サービスなどが想定される。本実施例においては、放送局が提供する有料VoDサービスであるとする。
【0100】
次に、情報処理装置401における、第3実施例との差分を説明する。情報処理装置401のハードウェア構成は第3実施例と同様であるが、新たな機能ブロックとして、コンテンツクラス情報記憶部4011、コンテンツ関連情報記憶部4012が追加されている。また、変換部2011の機能も差分がある。
【0101】
コンテンツクラス情報記憶部4011は、配信メディアに依存するコンテンツ情報と、配信メディアに依存しないコンテンツ情報(以下、コンテンツクラス情報と呼ぶ)を関連付けて記憶する。具体例を挙げると、ある放送局が、ある日時に、放送番組として放送する映画Aと、パッケージとしての映画Aを紐付けるものである。コンテンツクラス情報記憶部4011のデータ構造の一例を、図22に示す。図22に示すように、配信メディアの種別情報(メディア種別)と、配信メディア(地上波デジタル放送サービス、および、インターネットVoDサービス)上で一意にコンテンツを識別する情報(メディア依存コンテンツID)と、当該コンテンツのパッケージとしての、コンテンツクラス識別子が対応付けられている。図22では省略しているが、コンテンツクラス識別子の属性情報(コンテンツパッケージ名、製作年月日、製作者などの配信メディアに依存しないコンテンツ情報)を別テーブルに管理しても構わない。図22は、あくまで一例であり、複数の配信メディアを横断してコンテンツを紐付ける情報であれば、他の情報を含んでもよい。また、ある配信メディアにおけるコンテンツ識別子(コンテンツURI)を、コンテンツクラス識別子に代用しても構わない。
【0102】
尚、図22で示した情報は、第2変換用情報に対応し、情報閲覧装置302が提供可能なメディアを示す情報が、第1の機器に関する第2情報に対応する。
【0103】
コンテンツ関連情報記憶部4012は、コンテンツURIに紐付けられたコンテンツ情報、または、コンテンツクラス情報に関連するコンテンツや商品の情報を記憶するものである。コンテンツクラス識別子と、関連情報を紐付けて記憶しても構わないし、メディア依存のコンテンツ識別子(コンテンツURI)と関連情報を紐付けて記憶しても構わない。
【0104】
次に、情報処理装置401の動作を説明する。以下では、情報処理装置401の動作の、第3実施例との差異を説明する。差異点は、変換部306と、応答生成部1015の処理である。
【0105】
まず、変換部306は、第2抽出部1014が抽出した情報から、要求機器が情報閲覧装置302(ラップトップPC、タブレットPCなど、地上波デジタル放送受信チューナを有さない機器)であることを把握する。さらに、第3抽出部3011が抽出した情報から、操作対象機器(つまり、コンテンツ受信装置103)が存在しないことを把握してもよい。変換部306は、把握した情報から、情報閲覧装置302が、放送サービスを視聴できないことを判定し、コンテンツクラス情報記憶部4011から、コンテンツURIが指すメディア依存のコンテンツ(前述の実施例に示したように、ネットワークID、サービスID、トランスポートストリームID、開始時刻で特定されるコンテンツ)から、対応するインターネットVoDサービスのコンテンツURIを取得する。これは、図22に示すように、同じコンテンツクラス識別子を持ち、配信メディア種別がインターネットVoDサービスである情報を、コンテンツクラス記憶部311から検索することで取得できる。図22では、コンテンツ1とコンテンツ3が同じコンテンツクラス識別子を有するため、地上波デジタル放送番組(http://tv.nameservice.com/n_101/s_201/t_301/20101201190000)の、インターネットVoDサービスにおけるURIが、http://vod.example.com/101/201/301/20101201190000であることが分かる。
【0106】
次に、応答生成部1015は、変換部306が取得したインターネットVoDサービスにおけるコンテンツURIを、Webページにリンクとして埋め込む。Webページのテンプレートに埋め込む方法については、第1〜第3の実施例に示したとおりである。このとき、インターネットVoDサービスにおけるコンテンツURI、もしくは、コンテンツクラス識別子をキーとして、関連コンテンツ情報記憶部306から、関連するコンテンツ・商品(シリーズコンテンツであった場合には、他シリーズのVoDコンテンツや、DVDパッケージ等)を埋め込んでも構わない。生成されるWebページの具体例を図23に示す。Webページを受信したユーザB(情報閲覧装置302)は、表示されたリンクをクリックすると、インターネットVoDサービス(コンテンツ配信サービス提供装置306)上で公開された当該コンテンツにワンステップでアクセスできる。
【0107】
以上のように、本実施形態によれば、配信メディアをまたがったコンテンツURI管理を行うことで、放送が視聴できない環境におけるユーザに、別の配信メディアにおけるコンテンツへのリンクを返すことできる。さらに、コンテンツ関連情報をWebページに埋め込むことで、広告や関連商品販売の機会を得る構成をとることも可能になっている。
【0108】
以上説明した少なくとも1つ実施例の効果は、テレビ番組を特定するURIとインターネット上のサービスとの連携サービスを複数のユーザが利用する場合において、あるユーザが生成したURIを異なるユーザが利用する場合に、ユーザ間の環境の違いによらず、当該異なるユーザが、URIを利用したサービスを利用可能とすることである。
【0109】
本発明のいくつか実施形態を説明したが、これら実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【0110】
101、201、301、401・・・情報処理装置、102、103・・・コンテンツ受信装置、104・・・サービス提供装置、302・・・情報閲覧装置、105、106、303・・・ネットワーク、1011・・・受信部、1012・・・送信部、1013・・・第1抽出部、1014・・・第2抽出部、1015・・・応答生成部、1016・・・応答情報記憶部、2011・・・変換部、2012・・・変換用情報記憶部、2013・・・コンテンツ情報記憶部 、3011・・・第3抽出部、4011・・・コンテンツクラス情報記憶部、4012・・・コンテンツ関連情報記憶部。
【技術分野】
【0001】
本発明の実施形態は、情報処理装置に関する。
【背景技術】
【0002】
近年、テレビで放送される番組毎に、グローバルユニークな識別子であるURI(UniversAl Resource Identifier)を付与して、当該URIを利用して、インターネット上のサービスとテレビ放送番組とを連携したサービスを提供する動きがある。テレビ放送される番組毎に、URIを付与する方法として、テレビ放送の放送波に含まれるSI(Service Information)情報からURIを自動生成する方法が定められている(非特許文献1)。尚、この方法による場合、URIは、放送局等に依存した識別子となる。その結果、一つの番組でも、地域によって異なるURIが付与されることが想定される。
【0003】
テレビ放送される番組毎に、URIを付与して、テレビ番組と連携するインターネット上のサービスとして、例えば、SNS(Social Network Service)を想定できる。SNSにおいては、テレビ放送される番組に付与されたURIを複数のユーザ間で共有して利用することとなる。例えば、あるユーザAがユーザBに、現在視聴している番組を知らせる際に、同時に該当番組のURIを伝えると、ユーザBは、URIを利用することで(例えば、URIをクリックするなどの簡易操作を行うことで)、該当番組を視聴することができる。
【0004】
このようなテレビ番組を特定するURIとインターネット上のサービスを連携したサービス、特に、URIを複数のユーザ間で共有して利用するようなサービスの場合、いくつかの課題がある。具体的には、ユーザAが利用するテレビAが生成したURIを、ユーザBが利用するテレビBでは処理できないケースが起こり得る。例えば、テレビAがURIを生成した時刻から、一定時間経過した時点でテレビBがアクセスすると、既に該当番組が終了している場合があり得る。この場合、ユーザBは、URIをクリックするだけでは、URIによって特定される番組を視聴することができない。また、テレビA、B各々が属する放送区域が異なる場合、例えば、テレビAが東京にあり、テレビBが大阪にある場合、テレビAが生成したURIから、テレビBは、番組を特定できない。なぜなら、テレビ番組のURIは、テレビ番組の放送局等によって特定されるからである。
【先行技術文献】
【非特許文献】
【0005】
【非特許文献1】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)節
【発明の概要】
【発明が解決しようとする課題】
【0006】
本発明の一観点によれば、テレビ番組を特定するURIとインターネット上のサービスとの連携サービスを複数のユーザが利用する場合において、あるユーザが生成したURIを異なるユーザが利用する場合に、ユーザ間の環境の違いによらず、当該異なるユーザが、URIを利用したサービスを利用可能とする。
【課題を解決するための手段】
【0007】
本発明の一観点に係る情報処理装置は、コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第1の機器から受信する受信部と、前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出部と、複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部と、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出部が抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成部と、を備える。
【図面の簡単な説明】
【0008】
【図1】本発明の実施形態に係るシステムの構成を示すブロック図。
【図2】図1の応答情報記憶部1016のデータ構造の一例を示す図。
【図3】本発明の第1実施例に係るシステムの構成を示すブロック図。
【図4】図3のシステムの情報処理装置101の応答情報記憶部1016のデータ構造の一例を示す図。
【図5】図3の情報処理装置101を含むシステムの装置間のシーケンスを示した図。
【図6】図3の情報処理装置101の内部処理のフローチャート。
【図7】図3の情報処理装置101が応答するWebページのテンプレートの一例。
【図8】機器制御プログラムの擬似コードを示す図。
【図9】コンテンツURIのリンク先として、図3のコンテンツ受信装置103上に表示されるWebページの一例を示す図。
【図10】第2実施例にかかる情報処理装置201を含むシステムの構成を示すブロック図。
【図11】図10の情報処理装置201の変換用情報記憶部2012の記憶するデータ構造の一例を示す図。
【図12】図10の情報処理装置201のコンテンツ情報記憶部2013が記憶するデータ構造の一例を示す図。
【図13】図10の情報処理装置201の応答情報記憶部1016のデータ構造の一例を図。
【図14】図10の情報処理装置201の動作を示すフローチャート。
【図15】図10の情報処理装置201が応答する機器制御プログラムをリンクするWebページのテンプレートの一例。
【図16】図10の情報処理装置201が応答する機器制御プログラムの擬似コード。
【図17】図10のコンテンツ受信装置103上に表示されるWebページの一例を示す図。
【図18】第3実施例にかかる情報処理装置301を含むシステムを示すブロック図。
【図19】図18の情報処理装置301の応答情報記憶部1016のデータ構造の一例。
【図20】図18の情報処理装置301を含むシステムの機器間の動作シーケンス図。
【図21】第4実施例にかかる情報処理装置401を含むシステムを示すブロック図。
【図22】図21の情報処理装置401のコンテンツクラス情報記憶部4011のデータ構造の一例を示す図。
【図23】図22の情報閲覧装置302に表示されるWebページの一例を示す図。
【発明を実施するための形態】
【0009】
以下、本発明の実施の形態について、図面を参照しながら説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【0010】
図1は、実施形態にかかる情報処理装置101の構成を示すブロック図である。
【0011】
実施形態に係るシステムは、情報処理装置101と、コンテンツ受信装置102及び103と、サービス提供装置104とを備える。情報処理装置101と、コンテンツ受信装置102及び103と、サービス提供装置104とは、ネットワーク105で接続されている。また、コンテンツ受信装置102、103は、ネットワーク106から情報を受信する通信インタフェースを備えている。
【0012】
情報処理装置101は、受信部1011と、送信部1012と、第1抽出部1013と、応答生成部1015と、応答情報記憶部1016とを有する。
【0013】
受信部1011は、コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、コンテンツ受信装置103から受信する。
【0014】
第1抽出部1013は、受信部1011が受信したコンテンツ識別情報が構成する要素情報を抽出する。
【0015】
応答情報記憶部1016は、コンテンツ識別情報が構成する要素情報に関する条件各々と応答情報とを対応付けて記憶している。図2に、応答情報記憶部1016が記憶する情報の例を示す。応答情報記憶部1016は、要素情報に関する条件毎に対応付けて応答情報を記憶している。
【0016】
応答生成部1015は、応答情報記憶部1016が記憶する要素情報に関する条件のうち、第1抽出部1013が抽出した要素情報がみたす条件に対応づけて記憶された応答情報を含む応答メッセージを生成する。例えば、第1抽出部1013が抽出した要素情報が、図2の条件1を満たす場合、応答生成部1015は、条件1に対応付けて記憶された応答情報1を含む応答メッセージを生成する。
【0017】
送信部1012は、応答生成部1015が生成した応答メッセージを、コンテンツ受信装置103に送信する。
【0018】
以下の第1実施例では、以上説明した実施形態についての具体例を説明する。
【0019】
第1実施例では、コンテンツの例として、テレビ番組とする。また、コンテンツ識別情報の例として、コンテンツURI(Uniform Resource Identifier)とする。コンテンツURIは、Web上でテレビ番組を一意に特定する識別子である。また、コンテンツ識別子が構成する要素情報は、コンテンツURIを構成する値である、ネットワークIDとサービスIDとトランスポートストリームIDと、放送番組の開始時刻の4値とする。これら4値の各々を要素情報と称することとする。また、第1実施例では、応答情報記憶部1016が記憶する、コンテンツ識別情報が構成する要素情報に関する条件は、前述した4要素の1つである「放送番組の開始時刻」に関する条件であるとする。より具体的には、「現在時刻が、放送番組の開始前か否か」の条件であるとする。また、第1実施例における応答情報は、後述するように制御命令文字列と制御命令プログラムパスである。また、第1実施例における応答メッセージは、応答情報記憶部1016から取得した応答情報を埋めこんだWebページである。また、第1実施例の情報処理装置101は、更に、第2抽出部1014を備えている。
【0020】
<第1実施例>
まず、第1実施例の動作の概要を説明する。図3は、第1実施例にかかるシステムを示すブロック図である。
【0021】
図3において、ユーザAが、デジタルテレビ(コンテンツ受信装置102)で番組1(コンテンツ1)を視聴している場合を想定する。この場合に、ユーザAが、例えばリモコンに設けられた共有ボタンを押す等の何らかのアクションを行うと、コンテンツ受信装置102が、ソーシャルネットワークサービス上に「この番組を視聴しています(http://tv.example.info/network_101/service_201/ts_301/20101201190000」といったメッセージを送信する。このメッセージに含まれるURIが、Web上で番組1を一意に特定する識別子である(以降、この識別子をコンテンツURIと称する)。このコンテンツURIは、放送波に含まれるSI情報を利用してコンテンツ受信装置102が生成する。本実施例においては、ユーザBが、コンテンツ受信装置102が生成したメッセージを、デジタルテレビ(コンテンツ受信装置103)上で読む。ここで、ユーザBがコンテンツURIを選択(クリック)すると、URIに紐付けられた情報処理装置101上のWebページがコンテンツ受信装置103に表示される。この時、該当Webページには、既に番組が始まっていれば、「この番組を視聴する」ボタンが、番組がまだ始まっていなければ「この番組を予約する」ボタンが表示される。ユーザBは、画面に表示されたボタンを押下することで、ユーザAが送信した番組に対する視聴・録画予約のアクションを、簡単に実行できる。本実施例では、後述するように、コンテンツ受信装置102が生成したURIに対応する番組の開始時刻若しくは終了時刻と、URIをコンテンツ受信装置103上に表示する時刻との関係に応じて、Webページを、「番組を視聴」若しくは「番組予約」と切り替えることで、ユーザBが、上述の2つの時刻間の関係によらず、番組を視聴することができる。
【0022】
次に、以上のユースケースにおける、Webページを応答する情報処理装置101について、図3を用いて説明する。
【0023】
第1実施例に係るシステムは、情報処理装置101と、コンテンツ受信装置102及び103と、サービス提供装置104とを備える。情報処理装置101と、コンテンツ受信装置102及び103と、サービス提供装置104とは、ネットワーク105で接続されている。また、コンテンツ受信装置102、103は、ネットワーク106から情報を受信する通信インタフェースを備えている。
【0024】
次に、第1実施例のシステムを構成するネットワーク及び装置について説明する。
【0025】
ネットワーク105は、インターネット、または、品質保証された閉域網であるNGN(Next GenerAtion Network)などのIP(Internet Protocol)ネットワークである。本実施例においては、ネットワーク105は、インターネットであるとする。
【0026】
ネットワーク106は、コンテンツを配信するネットワークであり、地上波デジタル放送網、BS、CSなどの衛生放送網、ケーブルテレビ、NGN、インターネットなどを想定している。本実施例においては、ネットワーク106は、地上波デジタル放送網であるものとする。
【0027】
情報処理装置101は、CPU、主記憶、補助記憶で構成される、通常のコンピュータのハードウェア構成である。情報処理装置101は、ネットワーク105(インターネット)に接続する通信インタフェースを備え、インターネット上でコンテンツURIに対応するWebページを返すサービスを提供している。
【0028】
コンテンツ受信装置102、103は、情報処理装置101と同様、通常のコンピュータのハードウェア構成をとっており、コンテンツを表示するディスプレイと、キーボード、マウス、タッチパネル等の入出力インタフェースとを備えている。また、ネットワーク105とネットワーク106に対する通信インタフェースを備えている。具体的には、デジタルテレビ、ハードディスク・レコーダなどのデジタルAV機器、PC、スマートフォン、スレートデバイスなどである。本実施例においては、コンテンツ受信装置102、103共にデジタルテレビであるとする。
【0029】
サービス提供装置104は、情報処理装置101と同様のハードウェア構成である。サービス提供装置104は、ネットワーク105を介して、コンテンツ受信装置102、103のユーザ間のコミュニケーションを実現するソーシャルネットワークサービス等を提供する。本実施例においては、ソーシャルネットワークサービスとして、マイクロブログサービスを想定して説明する。
【0030】
次に、情報処理装置101のCPUが主記憶部や補助記憶部に記憶された各種プログラムを実行することにより実現される各種機能について図3に則して説明する。
【0031】
情報処理装置101は、受信部1011と、送信部1012と、第1抽出部1013と、第2抽出部1014と、応答生成部1015と、応答情報記憶部1016とを有する。いずれも、CPUのプログラム実行時にRAMなどの主記憶部上に生成されるものである。
【0032】
このうち、応答情報記憶部305はデータベース管理システムである。これは、リレーショナルデータベース、XML(eXtensiBle Markup LAnguAge)データベース、Key/VAlueストアなど、不揮発もしくは揮発記憶領域上にデータを記憶し、指定したキーをベースにデータを取得できる機能を備えて入れば、実現方式は問わない。単一のデータベース管理システムで構築されている必要はなく、複数のデータベース管理システムを併用してもよい。これは、第2実施例以降における変換用情報記憶部、機種情報記憶部、関連コンテンツ情報記憶部についても同様である。
【0033】
以下、情報処理装置101の各部について説明する。
【0034】
受信部1011は、ネットワーク105上のコンテンツ受信装置103から、コンテンツURIに対応するWebページの取得要求を受信する。この時に利用される通信プロトコルは、HTTP、FTP等、TCPプロトコルをベースとしたものでもよく、TCP/IPベースに限定されない独自プロトコルであってもよい。実施例においては、インターネット上で両者とHTTP(S)リクエストを受信する、HTTPサーバの受信部である。
【0035】
送信部1012は、前記Webページの取得要求に対する応答(後述する応答生成部1015が生成する応答情報。具体的にはWebページ)を、コンテンツ受信装置102に送信する。利用されるプロトコルについては、受信部1011と同様である。本実施例においては、HTTP(S)レスポンスを送信するものであり、HTTPサーバの送信部である。
【0036】
第2抽出部1014は、受信部1011から受信したコンテンツURIに対するWebページの取得要求に含まれる、送信元のコンテンツ受信装置103にかかる情報を抽出する。具体的には、HTTPリクエストに含まれるUser−Agentヘッダ情報から、Webブラウザの種別や画面サイズ、機種情報等を抽出する処理や、IPアドレス等から地域情報を抽出する処理を行う。本実施例においては、HTTPを前提としたこれらの処理を想定しているが、他の通信プロトコルを前提とした、送信元の機器情報を抽出する他の仕組みであっても構わない。
【0037】
第1抽出部1013は、受信部1011で受信したコンテンツURIから、コンテンツが放送された地域、放送局、放送時間等の情報を抽出する。地上波デジタル放送においては、コンテンツを一意に識別する情報として、放送波にSI情報として含まれるネットワークID、サービスID、トランスポートストリームID、開始時刻の4値の組み合わせが利用できる。ネットワークIDは、地上波、BS放送、CS放送といった粒度の通信網を表す情報である。サービスIDは、放送局を識別する情報であり、系列で一意の識別子ではなく、地方放送局毎に付与される識別情報である。トランスポートストリームIDは、放送局が送出するストリーム(MPEG-2 TS)を識別するための番号である。開始時刻は、放送番組の開始時刻である。以上の4値をもって、番組を一意に識別することができる。
【0038】
コンテンツURIが、この4値を含むように構成されている場合、第1抽出部1013は、URI解析によって、これら4つの値を抽出する。具体的には、ネットワークIDが101、サービスIDが201、トランスポートストリームIDが301、開始時刻が2010年12月1日19時であった場合に、コンテンツURIは、例えば、以下のように表現できる。第1抽出部1013は、このURIから、各値を取得する処理を行う。
【0039】
http://tv.nameservice.com/n_101/s_201/t_301/20101201190000
なお、コンテンツURIの形式は、上記フォーマットに限定されるものではない。対象が、放送コンテンツである場合であっても、開始時刻情報の代わりにイベントID情報を利用する等、他の方法もある。ネットワーク106上でコンテンツを一意に識別するための情報が含まれる範囲においては、他のフォーマットであっても構わない。
【0040】
応答生成部1015は、第1抽出部1013及び第2抽出部1014で抽出した情報に基づき、コンテンツURIに対応する応答情報を生成する。応答情報は、例えば、HTMLデータ(Webページ)、XMLデータ、あるいは、JSON(JavaScript Object Notation)データなど様々な形式のデータが想定できる。ここでは、Webページを返すものとする。本実施例では、例えば、第1抽出部1013が抽出した開始時刻情報を利用し、現在時刻が、番組の開始時刻を過ぎている場合に、Webページとして、チャンネル変更ボタンと、ボタン押下をトリガに実行される機種に応じたチャンネル変更命令プログラムとを埋め込んだページを返す。また、現在時刻が、開始時刻より前である場合には、Webページとして、録画予約ボタンと、ボタン押下をトリガに実行される機種に応じた録画予約命令プログラムを埋め込んだWebページを返す。
【0041】
応答情報記憶部1016は、第1抽出部1013及び第2抽出部1014で抽出した情報と、応答情報を対応付けて記憶する。また、応答生成部1015からの前記属性情報をキーとした応答情報取得要求を受けて、対応する応答情報を返す。図4は、応答情報記憶部1016のデータ構造の一例を示すものである。図4に示すように、コンテンツの時制(時刻条件と称する。)(開始時刻前か否かを表すブール値)、制御命令文字列(「録画予約する」「視聴する」等、ボタンに表示する文字列)、制御プログラムパスの4つのカラムで構成されている。これは、Webページ上に、該当コンテンツに対する1つの操作ボタン(「録画予約する」あるいは「視聴する」の2種類)を表示するというシンプルな目的に特化したデータ構造であり、応答するWebページの内容に応じて、さらに多くの情報で構成してもよいし、反対に、より少ない情報で構成してもよい。尚、本例では、開始時刻に応じた処理のみを説明しているが、終了時刻に応じた処理のバリエーションも想定できる。例えば、図4のカラム名として、終了時刻前か否かをいれ、終了時刻前か否かに応じて、応答情報を変更するようにしてもよい。この場合、終了時刻前か否かを、たとえば、コンテンツの終了時刻を取得し、現在時刻と終了時刻を比較して、判断する。このように、開始時刻や終了時刻を時刻条件と称することとする。また、図4の時刻条件は、図2の要素情報に関する条件に対応する。また、図4の制御命令文字列と制御命令プログラムパスは、図2の応答情報に対応する。図4に示すように、第1実施例の応答情報記憶部1016は、複数のエントリについて、要素情報に関する条件毎に、応答情報を記憶している。
【0042】
次に、図3〜図9を用いて、本実施例に係る情報処理装置101の動作について説明する。図5は、本実施例に係る情報処理装置101を含むシステム構成要素間のシーケンスを示した図である。図6は、情報処理装置101の内部処理のフローチャートである。図7は、情報処理装置101が応答するWebページのテンプレートの一例である。図8は、機器制御プログラムの擬似コードを示すものである。図9は、コンテンツURIのリンク先として、コンテンツ受信装置103上に表示されるWebページの一例を示す図である。
【0043】
まず、本実施例の前提として、2人のユーザを想定する。コンテンツ受信装置102のユーザ(ユーザA)と、コンテンツ受信装置103のユーザ(ユーザB)である。ユーザAとユーザBは共に、他ユーザとのコミュニケーションを実現する、サービス提供装置104が提供するSNSに加入している。また、コンテンツ受信装置102、103は、このSNSにメッセージを送信したり、メッセージを閲覧したりするSNSクライアント機能と搭載しているものとする。
【0044】
以下、図5のシーケンス図をベースに処理手順を説明する。図5は、情報処理装置101を含むシステムの装置間のシーケンスを示した図である。
【0045】
まず、ユーザAがコンテンツ受信装置102上で、コンテンツ(地上波デジタル放送番組)視聴中に、リモコンもしくは画面上に表示された「この番組をみんなに薦める」ボタンを押す(ステップS101)。コンテンツ受信装置102は、ボタン押下のイベントを受けて、受像している番組を識別する情報(ネットワークID、サービスID、トランスポートストリームID、開始時刻の4値)をSI情報から取得する(ステップS102)。続いて、コンテンツ受信装置102は、この4値を用いて、コンテンツURIを生成する(ステップS103)。前述したように、受像中の番組のネットワークIDが101、サービスIDが201、トランスポートストリームIDが301、番組の開始時刻が2010年12月1日19時である場合に、生成されるコンテンツURIは、http://tv.nameservice.com /n_101/s_201 /t_301/20101201190000となる。続いて、コンテンツ受信装置102は、生成したコンテンツURIを引用したメッセージ(例えば、「この番組を視聴していますhttp://tv.nameservice.com/n_101/s_201/t_301/20101201190000」など)を生成する(ステップS104)。このとき、ネットワークID等と同様に、当該番組のタイトル文字列情報を、SI情報から取得し、これをメッセージに含めてもよいし(「番組XXXを視聴しています。http://... 」)、あるいは、コンテンツURIがデフォルトで入力されたテキストボックスを表示してユーザにメッセージを入力を促すように構成してもよい。メッセージ生成のフォーマット、実現形式は問わない。コンテンツ受信装置102は、生成したメッセージを、ネットワーク105上のサービス提供装置104に送信する(ステップS105)。本実施例においては、このメッセージ送信は、HTTP POSTメソッドで送信されるものとするが、HTTP PUTやGETなど別のメソッドであってもよく、HTTPプロトコルに限定されるものでもない。
【0046】
サービス提供装置104は、コンテンツ受信装置102から該当メッセージを受信すると、ユーザAのメッセージを購読しているユーザBを同定し(ステップS106)、ユーザB(すなわち、コンテンツ受信装置103)に対して同メッセージを送信する。この送信シーケンスは、コンテンツ受信装置103上のSNSクライアントが、定期的にサービス提供装置104に対して、メッセージの有無を問い合わせるポーリングによって実現してもよいし、サービス提供装置104からコンテンツ受信装置に対して、メッセージをプッシュするように実現してもよい。本実施例においては、前者の方法で実現されるものとする。具体的には、コンテンツ受信装置102がHTTP GETリクエストによって、購読対象(ユーザA)からの新着メッセージを要求(ステップS107)し、結果を受信する(ステップS108)。この通信プロトコルについては、ステップS105と同様、様々な実現方式(通信プロトコル)が許容される。なお、後者の方法については、コンテンツ受信装置104がHTTPクライアント、コンテンツ受信装置103がHTTPサーバとしてふるまうように実現する方法や、HTTPロングポーリングや、WebSocketを利用して、コンテンツ受信装置103側が、サービス提供装置104に対するTCPコネクションを生成、維持し、このコネクションを利用して、サービス提供装置104がコンテンツ受信装置102に対してメッセージを送信する方法などが考えられる。
【0047】
次に、コンテンツ受信装置103は、受信したユーザAからのメッセージをコンテンツ受信装置103の画面上に表示する(ステップS109)。ここまでの処理で、ユーザBのコンテンツ受信装置103の画面上に、ユーザAの送信したコンテンツURIを含むメッセージが表示されることになる。
【0048】
ここで、ユーザBが、ユーザAの「この番組を視聴しています。http://tv.name service.com/n_101/s_201/t_301/20101201190000」メッセージを閲覧し、このコンテンツURIを選択する(ステップS110)。選択方法は、ポインティングデバイスでクリックする、あるいはリモコンで選択・決定するなど、様々な方法が考えられる。この選択処理をトリガとして、コンテンツ受信装置103は、情報処理装置101に対してアクセスする(すなわち、コンテンツURIに紐付けられたWebページの取得要求を送信する)(ステップS111)。これは、通常のHTMLにおけるハイパーリンクを辿る手段と同じであり、HTTP GETリクエストによって実現される。
【0049】
情報処理装置101は、Webページの取得要求を受信して、コンテンツURI処理(コンテンツURI解析と対応するWebページの生成)を行ない(ステップS112)、コンテンツURIに対応するWebページを、コンテンツ受信装置103に応答する(ステップS113)。
【0050】
ここで、情報処理装置101におけるステップS112のコンテンツURI処理を、図6のフローチャートを用いて説明する。
【0051】
情報処理装置101の受信部1011は、Webページの取得要求を受信し、これを第2抽出部1014に渡す(ステップS1001)。第2抽出部1014は、受信要求に含まれる情報から、送信元のコンテンツ受信装置103にかかる情報を抽出する(ステップS1002)。具体的には、HTTPリクエストに含まれるUser−Agentヘッダから、コンテンツ受信装置103上に搭載されているWebレンダリングエンジンの種類やバージョン、画面サイズ情報を取得する。ここでは、Webページのレイアウトを決定する画面サイズを取得する。続いて、第1抽出部1013が、コンテンツURI自体を解析し、地上波デジタル放送上で、コンテンツを一意に識別するための4値(ネットワークID、サービスID、トランスポートストリームID、開始時刻)を取得する(ステップS1003)。これは、前述したとおり、本実施例では、それぞれ101、102、103、2010年12月1日19:00である。次に、応答生成部1015が、第2抽出部1014が抽出した画面サイズ、第2抽出部1013が抽出した4値を入力に取り、まず、現在時刻(アクセス時刻)をシステムから取得し(ステップS1004)、現在時刻とコンテンツの開始時刻とを比較し、現在時刻がコンテンツの開始時刻前か否かを判定する(ステップS1005)。続いて、応答生成部1015は、応答情報記憶部1016から機種情報と開始前か否かのブール値をキーとして、制御命令文字列と制御命令プログラムパス(URL:Universal Resource Locator)を取得する(ステップS1006)。ここでは、コンテンツ受信装置103からの取得要求の時刻(つまり現在時刻)が、コンテンツの開始時刻後であったとして、図4における1番目のエントリ(http://tv.nameservice.com/apis/changeChannel.js)が取得される。応答生成部1015は、図7に一例を示す、Webページのテンプレートに、機器操作プログラムへのパス情報、制御命令文字列、および、コンテンツURIから取得した4値を埋め込む。具体的には、図7の$1, $2, $3, $4, $5, $6に、それぞれの値を埋め込み、応答メッセージ(Webページ)を生成し(ステップS1007)、送信する(ステップS1008)。
【0052】
続いて、図5を用いて、コンテンツ受信装置103の挙動について説明する。コンテンツ受信装置103は、情報処理装置101からの応答メッセージを受信すると、これをディスプレイ上に表示する(ステップS114)。表示されるWebページの一例を、図9に示す。本実施例では、「この番組を視聴する」ボタンが表示される。ユーザBが表示されたボタンを押下すると(ステップS115)、図8の&&&TODO行目のチャンネル変更API(Application Program Interface)(device.execute (networkId, serviceId, transportStreamId, startDate))が呼び出される。この例では、API内部で呼び出されている機器制御関数(setChannelNative(networkId, serviceId, transportStreamId))が、実際にコンテンツ受信装置103の受像チャンネルを、与えられたパラメータに応じて変更する(ステップS116)。なお、ユーザBが、当該コンテンツURIをクリックした時刻が、コンテンツの開始時間よりも前であった場合には、情報処理装置101は、ステップS1006において録画予約のための制御プログラムを取得し、コンテンツ受信装置103上に表示されるボタンは、「この番組を録画予約する」となる。
【0053】
以上のように、本実施例の情報処理装置101によれば、コンテンツURIを処理する時点での、コンテンツの時制(開始時刻を過ぎたか否か)の変化に合わせて、すなわち、コンテンツの時制という属性値の発信側(コンテンツ受信装置102)と受信側(コンテンツ受信装置103)の差異に関わらず、複数機器間で当該コンテンツURIをシェアし、これを利用した機器操作を簡単に実現できている。本実施例において、ユーザBによる、コンテンツ受信装置103のチャンネル変更/録画予約までの操作ステップは、コンテンツURIの選択と、選択の結果表示されたWebページのボタン押下の2ステップである。さらに、ボタン押下というユーザアクションを省略し、Webページのコンテンツ受信装置103での読み込みをトリガとして、上記のdevice.execute関数を自動実行することも可能である。この場合は、ユーザBは、コンテンツURIのリンクを辿る(クリックする)という1アクションで、実機器の操作を行うことが可能になる。
【0054】
尚、情報処理装置101は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、受信部1011、送信部1012、第1抽出部1013、第2抽出部1014、応答生成部1015、応答情報記憶部1016は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、情報処理装置101は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD−ROMなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、応答情報記憶部1016は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD−R、CD−RW、DVD−RAM、DVD−Rなどの記憶媒体などを適宜利用して実現することができる。
【0055】
<第2実施例>
次に、図10を用いて、第2の実施の形態の情報処理装置201について説明する。
【0056】
まず、本実施例の想定する具体的なユースケースについて説明する。
【0057】
第1実施例と同様、ユースケースの骨子は、ユーザAによるコンテンツURIを引用したメッセージを、ユーザBが閲覧するとともに、このコンテンツURIをクリックすることで機器を制御するというものである。第2実施例と第1実施例との差分は、2つある。第1に、ユーザBが属する放送区域が、ユーザAの属する放送区域と異なる点である。そして、情報処理装置201は、ユーザB及びAが異なる放送区域であっても、ユーザB及びAがコンテンツURIを利用したサービスを障害なく利用できるようにしている。第2に、第1実施例においては、全ての操作対象機種が共通化された同じAPIを利用していたが、第2実施例では、そうではない点である。すなわち、第2実施例では、情報処理装置201は、操作対象機器の機種やメーカ毎にWebページからアクセスするための異なるAPIセットを持っていて、操作対象機器に合わせて、呼び出すAPIを変更することができるようにしている。
【0058】
図10は、情報処理装置201の構成を示すブロック図である。
【0059】
以下、情報処理装置201と情報処理装置101との差分を説明する。
【0060】
情報処理装置201のハードウェア構成は第1実施例と同様であるが、新たな機能ブロックとして、変換部2011、変換用情報記憶部2012、コンテンツ情報記憶部2013が追加されている。いずれも、CPUのプログラム実行時にRAMなどの主記憶部上に生成されるものである。
【0061】
まず、情報処理装置201と情報処理装置101との差分として、新たな機能ブロックの説明をする。
【0062】
変換部2011は、コンテンツURIを、Webページ取得要求元の環境に応じて変換する。この際、第2抽出部1014が抽出する情報と、後述する変換用情報記憶部2012に記憶された情報に基づいて変換する。本実施例においては、コンテンツ受信装置103の放送区域のチャンネル編成に合わせて、コンテンツURIに含まれる放送コンテンツの識別情報を構成するネットワークID、サービスID、(および、トランスポートストリームID)を変更する。
【0063】
変換用情報記憶部2012は、変換部2011がコンテンツURIの変換に利用する情報を記憶する。例えば、本実施例においては、地域毎のチャンネル編成の対応関係を管理する。図11は、変換用情報記憶部2012の記憶するデータ構造の一例を示すものである。図11に示すように、地域及び放送系列毎の放送局情報(ネットワークID、サービスID(、トランスポートストリームID))を管理する変換部2011は、この変換用情報記憶部2012を利用して、コンテンツ受信装置102上で生成されたコンテンツURIのネットワークIDとサービスIDから放送系列を同定し、コンテンツ受信装置103の放送区域における同放送系列のネットワークIDとサービスIDを求め、この値でコンテンツURIを変換する。すなわち、図11は、コンテンツURIの変換のために、機器情報に含まれる放送区域情報を用い、変換対象が放送局情報(ネットワークID+サービスID)であることを想定したデータ構造になっている。これはあくまで一例であり、様々なバリエーションが考えられる。例えば、変換対象がネットワークIDのみ(例えば、地上波からBSへの変換)であってもよく、変換対象がコンテンツの開始時間までも含むもの(地域によって開始時間までも異なる場合)であってもよい。
【0064】
それぞれのバリエーションによって、変換用情報記憶部2012のデータ構造は異なり、各バリエーションにおける変換対象の情報と、変換に用いる情報とを含むものとなる。
【0065】
尚、図11で示した情報は、第1変換用情報に対応し、コンテンツ受信装置103の放送区域が、第1の機器に関する第1情報に対応する。 コンテンツ情報記憶部2013は、コンテンツ識別情報と、コンテンツの様々な属性(メタデータ)を記憶する。例えば、番組タイトルやジャンル、出演者、番組の説明文、開始時間や終了時刻(あるいは、尺)などである。図12は、情報処理装置201のコンテンツ情報記憶部2013が記憶するデータ構造の一例を示す図ある。本実施例においては、図12に示すように、タイトルと開始時刻、終了時刻、番組説明文を管理しているものとする。この構成は一例であり、現在、放送波のSI情報に含まれるあらゆる番組メタデータや、当該番組に関連する商品や類似番組、シリーズ番組などの番組に付随する情報も合わせて管理してもよい。
【0066】
情報処理装置201と情報処理装置101との差分として、情報処理装置101が有す構成要素であるが、異なる機能を有する構成要素を説明する。
【0067】
応答情報記憶部1016の、情報処理装置101の応答情報記憶部1016のデータ構造からの変更点について説明する。第2実施例における応答情報記憶部1016のデータ構造の一例を図13に示す。第1実施例との差分は、機種情報が追加されている点、当該機種情報ごとに制御命令プログラムパスが異なる点にある。すなわち、コンテンツ受信装置が外部公開する機能(チャンネル変更や録画予約)のインタフェース(API)が、機種ごとに独自のものであった場合には、アクセス元(コンテンツ受信装置)の機種情報に応じた応答情報(制御命令プログラム)が必要になる。図13の機種情報(条件1)は、第2抽出部1014が抽出した、アクセス元の機器の機器情報に関する条件に対応する。また、図13の「放送中か否か」(条件2)は、図2の要素情報に関する条件に対応する。また、図13の制御命令文字列と制御命令プログラムパスは、図2の応答情報に対応する。第2実施例の応答情報記憶部1016は、複数のエントリについて、機器情報に関する条件(条件1及び)要素情報に関する条件(条件2)毎に、応答情報(制御命令文字列及び制御命令パス)を記憶している。 次に、図10〜図17を用いて、情報処理装置201の動作を説明する。図17は、情報処理装置201の内部処理のフローチャートを示したものである。図15、図16は、それぞれ本実施例における情報処理装置201が応答するWebページのテンプレートの一例と、Webページにリンクされる機器制御プログラムの擬似コードを示すものである。図17は、コンテンツURIのリンク先として、コンテンツ受信装置103上に表示されるWebページの一例を示す図である。
【0068】
本実施例のシステム構成は、第1実施例と同様であり、システム構成要素間の通信シーケンスも、第1実施例と等しく、図5に従う。ここでは、本実施例における差分のみについて、図3を用いて説明する。
【0069】
第1の差分は、コンテンツURIに基づくWebページ取得要求(ステップS111)において、コンテンツ受信装置103が、属する放送区域情報を送信する点である。この放送区域の情報は、HTTP GETメソッドによる送信時にコンテンツURIにクエリ文字列として追加して送ってもよいし、あるいはリクエストヘッダに独自項目を追加し、そのフィールドに埋め込んでもよい。あるいは、HTTP POSTメソッドによるリクエストの形式をとり、リクエストボティに埋め込んでもよい。なお、別の方法として、情報処理装置201が、ユーザの属する放送区域を、IPアドレスや経由したネットワーク上のノード情報から算出する方法が考えられる。この場合は、精度面では劣るが、コンテンツ受信装置103が、明示的に放送区域情報を送信せずに済む。
【0070】
第2の差分は、情報処理装置201におけるコンテンツURI処理(ステップS112)である。図14のフローチャートを用いて説明する。第1実施例(図6)との差分は、まず、コンテンツURIの解析処理(ステップS2003)の後に、コンテンツURIの変換処理が入る点である。変換部2011は、変換用情報記憶部2012を利用して、ユーザAの環境におけるコンテンツURIをユーザBの環境に合わせたものに変換する。
【0071】
例えば、ユーザAが東京、ユーザBが大阪の場合、図11に情報に基づき、ネットワークID(101)、サービスID(201)、トランスポートストリームID(301)の3値とユーザAの放送区域(東京)から、ユーザAの視聴している番組の放送局系列識別子が1であることがわかる。同じ放送局系列識別子(1)と、ユーザBの属する放送区域(大阪)から、ユーザBの環境における当該コンテンツの上記3値は、101、203、303である。すなわち、変換後のコンテンツURIは、以下のようになる。
【0072】
http://tv.nameservice.com/n_101/s_203/t_303/20101201190000
なお、この変換後のコンテンツURIは、あくまでコンテンツURI形式にシリアライズした場合の例であり、実際は、情報処理装置201の内部処理として、コンテンツURIを構成するコンテンツ識別情報(本実施例の場合は、ネットワークID、サービスID、トランスポートストリームID、開始時刻の4値)の変換のみに留めてよい。
【0073】
変換部2011の処理は、変換元の{ AreaId, NetworkId, ServiceId, TransportStreamId}の4値から、ServiceGroupIdを導出し、このServiceGroupIdと変換先のAreaIdから、変換先の{NetworkId, ServiceId, TransportStreamId}を求める処理になる。
【0074】
続いて、応答生成部1015が、(変換前もしくは変換後の)コンテンツURIから、図12に示した情報を用いて、コンテンツ情報を取得する(ステップS2005)。コンテンツ情報を取得することにより、図17に示すように生成するWebページに番組情報を含めることができる。また、番組の終了時刻(あるいは尺)情報を参照することで、現在時刻に番組が終了しているか否かを判定することができる。第1実施例においては、時制の判定材料に開始時刻のみを利用していたが、終了時刻を利用することで、図14のように、放送中か否かを判定することが出来る。本実施例では、現在時刻を参照し(ステップS2006)、既に番組が終わっている場合には、(例えば「既にこの番組は終了しています」等の)エラーメッセージページを生成して(ステップS2009)、これを送信する(ステップS2011)。 一方、番組が終っていない場合には、時制と、第2抽出部1014で抽出した機種情報に基づき、応答情報記憶部1016から、機種に応じた機器制御プログラムや、表示文字列などの図15に一例を示したWebページテンプレートに設定する諸情報を取得する(ステップS2008)。この情報をテンプレートに設定し、Webページを生成し(ステップS2009)、これを送信する(ステップS2010)。Webページのテンプレートには、図15に示すように、コンテンツ情報記憶部2013から取得した放送局、タイトル、番組説明を挿入する変数($2, $3, $4)が追加されており、応答生成部1015は、この3つを含めた、コンテンツ情報記憶部2013、応答情報記憶部1016から取得した合計9つの変数を、図14のテンプレートに埋め込む。以上が、コンテンツURI処理の第1実施例との差分となる。
【0075】
第3の差分は、コンテンツ受信装置103の表示するWebページである(ステップS114)。図17に示すように、コンテンツ情報記憶部2013の情報が、Webページに反映されている。
【0076】
第4の差分は、ボタン押下で実行される機器制御プログラムである。図16に示すように、APIの内部で呼び出される関数(録画予約)がreserve_42xx001()となっている。つまり、デジタルテレビ42X001向けのコードが埋めこまれている。応答生成部1015が、機種に応じた機器制御プログラムをリンクすることで、内部機能へのアクセスAPIの標準規格が存在しない場合でも、本実施例は実現可能であることを示している。
【0077】
以上のように、本実施例によれば、ユーザAとユーザBの属する放送区域が異なる場合であっても、コンテンツURIを、ユーザの環境に合わせて変換することで、コンテンツURIを適切に処理する(実機器操作につなげる)ことができる。また、機器の内部機能を利用するためのAPI標準が存在しない場合であっても、機種に応じた制御プログラムを動的に埋め込むことで、コンテンツURIからの実機器操作を実現できている。
【0078】
<第3実施例>
図18は、第3実施例にかかる情報処理装置301である。
【0079】
まず、第3実施例の想定する具体的なユースケースについて説明する。
【0080】
第1、2実施例と同様、第3実施例のユースケースの骨子は、ユーザAによるコンテンツURIを引用したメッセージを、ユーザBが閲覧し、このコンテンツURIをクリックすることで機器を制御するというものである。第1及び2実施例との差分は、2つある。第1は、ユーザBがデジタルテレビ(コンテンツ受信装置103)を操作しているのではなく、PCもしくはタブレット端末を利用しているという点である。具体的には、ユーザBは、テレビの前で、ラップトップPC上でSNSを閲覧しており、ユーザAが提示するコンテンツURIをクリックすると、ネットワーク経由でコンテンツ受信装置103の制御を行う。第2は、放送が終了している番組についても録画済みであれば再生を行う、という機器制御を想定している点である。
【0081】
図18は、本発明の第3実施例に係る情報処理装置301の機能ブロックを含むシステム構成図である。システム構成上の第1実施例(図3)との差分は、ネットワーク303と情報閲覧装置302が追加されている点にある。
【0082】
ここで、ネットワーク303は、ネットワーク105と同様、IP(Internet Protocol)ネットワークであり、特に宅内LANを想定している。
【0083】
情報閲覧装置302は、前述した本実施例のユースケースにおける、ラップトップPCに対応するものである。したがって、コンテンツ受信装置102、103と同様、CPU、主記憶、補助記憶で構成される、通常のコンピュータのハードウェア構成となっている。
【0084】
次に、情報処理装置301について、第2実施例にかかる情報処理装置201との差分を説明する。情報処理装置301のハードウェア構成は情報処理装置201と同様であるが、新たな機能ブロックとして、第3抽出部3011が追加されている。
【0085】
第3抽出部3011は、情報閲覧装置302がWebページ取得要求時に付与する操作対象機器情報、あるいは、プロトコル情報を抽出する。具体的には、情報閲覧装置302は、コンテンツURIを利用した実機操作(チャンネル変更等)を自機器で行わない場合に、周辺機器の機種情報や、発見・遠隔操作するためのプロトコル情報をWebページ取得要求に含める。これは、既存のHTTPリクエストヘッダを利用して、この情報を追加するようにしてもよいし、新たなHTTPリクエストヘッダを設けてもよいし、リクエストURL(すなわちコンテンツURI)に含めてもよいし、あるいは、HTTP POSTリクエストを利用し、HTTPペイロードに記述するようにしてもよい。
【0086】
次に、応答情報記憶部1016のデータ構造の変更点について説明する。本実施例における応答情報記憶部1016のデータ構造の一例を図19に示す。第2実施例の応答情報記憶部1016との差分として、制御プロトコル情報が追加されている。これは、コンテンツ受信装置103が周辺機器にコンテンツURI操作を要求するための制御プロトコルを特定するものである。図19の機種情報(条件1)は、第2抽出部1014が抽出した、アクセス元の機器の機器情報に関する条件に対応する。図19の「時制」(条件3)は、図2の要素情報に関する条件に対応する。本実施例では、上述した条件に加えて、更に、制御プロトコル情報に関する条件(条件2)を記憶している。また、図19の制御命令文字列と制御命令プログラムパスは、図2の応答情報に対応する。第3の実施例の応答情報記憶部1016は、複数のエントリについて、及び機器情報に関する条件(条件1)及び制御プロトコル情報に関する条件(条件2)及び要素情報に関する条件(条件3)毎に、応答情報(制御命令文字列及び制御命令パス)を記憶している。 次に図14、図18〜図20を用いて、情報処理装置301の動作を説明する。図20は、情報処理装置301を含むシステム構成要素間の基本シーケンスを示したものである。
【0087】
以下、図20のシーケンス図をベースに処理手順を説明する。
【0088】
まず、ステップS301からステップS310までの処理は、第1実施例におけるステップS101からS110までと同じであるため説明を省略する。この時点で、ユーザBの情報閲覧装置302の画面上に、ユーザAの送信したコンテンツURI(第1実施例と同様、http://tv.name service.com/n_101/s_201/t_301/20101201190000 であるとする)を含むメッセージが表示され、ユーザBがこのコンテンツURIをクリックしたことになる。
【0089】
以降の動作については、第2実施例との差分のみを説明する。
【0090】
動作シーケンスの第1の差分は、ステップS311の操作機器情報取得処理が追加されている点である。情報閲覧装置302は、webページ取得要求メッセージに、webページを用いて操作する制御対象機器に関する情報を取得し(ステップS311)、この情報を埋め込んで送信する(ステップS312)。これは、前述したようにHTTPリクエストヘッダ、ペイロード、クエリ文字列等様々な実現方式が考えられる。なお、埋め込む情報は、プロトコル情報だけでもよいし、機種情報、宅内IPアドレス/ポート番号情報、メールアドレスなど、ネットワーク105を介したリモートアクセスに必要な他の情報を埋めこんでもよい。前者の場合は、制御プロトコルに基づいて実際に制御する機器を発見・特定し、制御命令を送信するまでの一連の処理を制御プログラムに埋め込む必要があるが、後者の場合は、発見処理を割愛できる。本実施例においては、図19に示すように、制御プロトコル情報のみを含むものとする。
【0091】
動作シーケンスの第2の差分は、ステップS313のコンテンツURI処理である。処理のフローチャートは第2実施例のフローチャート(図14)と同様であるが、ステップS2002の端末側情報抽出処理において、前記の制御対象機器情報を抽出する点と、ステップS 2008の機器制御プログラム取得処理において、得られた機種情報およびプロトコル情報をキーとして情報を取得する点において異なっている。
【0092】
第3の差分は、情報閲覧装置302がWebページを取得し、ユーザBがWebページ上のボタンをクリックした後の処理である。図14のステップS2008において、図19のエントリ1が選択された場合、Webページには、DLNAプロトコルをベースにした機器発見、機器制御プログラムが埋めこまれている。ユーザBが「録画コンテンツを再生する」ボタンをクリックすると、情報閲覧装置302は、DLNAプロトコルに基づく、機器発見ステップ(DLNA Search)を実行し、録画コンテンツを管理するCDS(Content Directory Service)を有する機器として、コンテンツ受信装置103を発見する(ステップS317、S318)。続いて、情報閲覧装置302は、発見されたコンテンツ受信装置103に対して、ネットワークID、サービスID、トランスポートストリームID及び開始時刻の4値をキーとした、コンテンツ検索・再生ステップ(DLNA Action)を実行する(ステップS319)。コンテンツ受信装置103は、対象コンテンツが録画済みであれば、要求された再生処理を行ない(ステップS320)、正常実行した旨を応答する(ステップS321)。録画していなければ、検索エラーメッセージを応答する。
【0093】
以上のように、本実施例によれば、コンテンツURI処理を要求する機器以外の機器を操作対象とすることができる。すなわち、ラップトップPCでSNSを閲覧している状況で、近くのデジタルテレビにコンテンツURIに基づく実機器操作を実行させることが可能になっている。
【0094】
<第4実施例>
図21は、第4実施例にかかる情報処理装置401を含むシステムを示すブロック図である。
【0095】
本実施例の想定する具体的なユースケースについて記す。
【0096】
第1、2、3実施例と同様、第4実施例のユースケースの骨子は、ユーザAによるコンテンツURIを引用したメッセージを、ユーザBが閲覧し、このコンテンツURIをクリックすることで、コンテンツURIに紐付けられたコンテンツを視聴・予約等を行うものである。第4実施例の、第1、2、3実施例との差分は、3つある。第1の差分は、図21に示すように、第4実施例にかかる情報処理装置401を含むシステムが、コンテンツ受信装置103を備えておらず、ユーザBが情報閲覧装置302のみを保持している点である。第2の差分は、コンテンツURIに紐付けられているのが、放送コンテンツではなく、ネットコンテンツであるという点である。第3の差分は、情報処理装置401がWebページに関連情報を付与して送信する点である。より具体的には、ユーザBは、ラップトップPC上でSNSを閲覧しており、テレビを所有していない(第1の差分に対応する。)。そして、ユーザAが提示するコンテンツURIをクリックすると、当該コンテンツは放送コンテンツであるが、ユーザBはテレビを有していないので、放送経由では視聴できない。情報処理装置401は、「この番組をインターネットで視聴する」ボタン(インターネット上のVoD(Video On Demand)サービス上で公開された当該コンテンツのURIへのリンク)を含むページを返す(第2の差分に対応する。)。このとき、ページには、当該コンテンツに関連するコンテンツ・商品情報も埋め込んで返す(第3の差分に対応する)。
【0097】
以下、本実施例の詳細について、図21を用いて説明する。
【0098】
本実施例のシステム構成上の第3実施例との差分は、ネットワーク303とコンテンツ受信装置103が無い点と、ネットワーク105上のコンテンツ配信サービス提供装置402が追加されている点である。
【0099】
コンテンツ配信サービス提供装置402のハードウェア構成は、サービス提供装置104と同様である。コンテンツ配信サービス提供装置402が提供するサービスは、放送局が、放送後の番組を有料配信するVoDサービスや、一般的なビデオ共有サービスなどが想定される。本実施例においては、放送局が提供する有料VoDサービスであるとする。
【0100】
次に、情報処理装置401における、第3実施例との差分を説明する。情報処理装置401のハードウェア構成は第3実施例と同様であるが、新たな機能ブロックとして、コンテンツクラス情報記憶部4011、コンテンツ関連情報記憶部4012が追加されている。また、変換部2011の機能も差分がある。
【0101】
コンテンツクラス情報記憶部4011は、配信メディアに依存するコンテンツ情報と、配信メディアに依存しないコンテンツ情報(以下、コンテンツクラス情報と呼ぶ)を関連付けて記憶する。具体例を挙げると、ある放送局が、ある日時に、放送番組として放送する映画Aと、パッケージとしての映画Aを紐付けるものである。コンテンツクラス情報記憶部4011のデータ構造の一例を、図22に示す。図22に示すように、配信メディアの種別情報(メディア種別)と、配信メディア(地上波デジタル放送サービス、および、インターネットVoDサービス)上で一意にコンテンツを識別する情報(メディア依存コンテンツID)と、当該コンテンツのパッケージとしての、コンテンツクラス識別子が対応付けられている。図22では省略しているが、コンテンツクラス識別子の属性情報(コンテンツパッケージ名、製作年月日、製作者などの配信メディアに依存しないコンテンツ情報)を別テーブルに管理しても構わない。図22は、あくまで一例であり、複数の配信メディアを横断してコンテンツを紐付ける情報であれば、他の情報を含んでもよい。また、ある配信メディアにおけるコンテンツ識別子(コンテンツURI)を、コンテンツクラス識別子に代用しても構わない。
【0102】
尚、図22で示した情報は、第2変換用情報に対応し、情報閲覧装置302が提供可能なメディアを示す情報が、第1の機器に関する第2情報に対応する。
【0103】
コンテンツ関連情報記憶部4012は、コンテンツURIに紐付けられたコンテンツ情報、または、コンテンツクラス情報に関連するコンテンツや商品の情報を記憶するものである。コンテンツクラス識別子と、関連情報を紐付けて記憶しても構わないし、メディア依存のコンテンツ識別子(コンテンツURI)と関連情報を紐付けて記憶しても構わない。
【0104】
次に、情報処理装置401の動作を説明する。以下では、情報処理装置401の動作の、第3実施例との差異を説明する。差異点は、変換部306と、応答生成部1015の処理である。
【0105】
まず、変換部306は、第2抽出部1014が抽出した情報から、要求機器が情報閲覧装置302(ラップトップPC、タブレットPCなど、地上波デジタル放送受信チューナを有さない機器)であることを把握する。さらに、第3抽出部3011が抽出した情報から、操作対象機器(つまり、コンテンツ受信装置103)が存在しないことを把握してもよい。変換部306は、把握した情報から、情報閲覧装置302が、放送サービスを視聴できないことを判定し、コンテンツクラス情報記憶部4011から、コンテンツURIが指すメディア依存のコンテンツ(前述の実施例に示したように、ネットワークID、サービスID、トランスポートストリームID、開始時刻で特定されるコンテンツ)から、対応するインターネットVoDサービスのコンテンツURIを取得する。これは、図22に示すように、同じコンテンツクラス識別子を持ち、配信メディア種別がインターネットVoDサービスである情報を、コンテンツクラス記憶部311から検索することで取得できる。図22では、コンテンツ1とコンテンツ3が同じコンテンツクラス識別子を有するため、地上波デジタル放送番組(http://tv.nameservice.com/n_101/s_201/t_301/20101201190000)の、インターネットVoDサービスにおけるURIが、http://vod.example.com/101/201/301/20101201190000であることが分かる。
【0106】
次に、応答生成部1015は、変換部306が取得したインターネットVoDサービスにおけるコンテンツURIを、Webページにリンクとして埋め込む。Webページのテンプレートに埋め込む方法については、第1〜第3の実施例に示したとおりである。このとき、インターネットVoDサービスにおけるコンテンツURI、もしくは、コンテンツクラス識別子をキーとして、関連コンテンツ情報記憶部306から、関連するコンテンツ・商品(シリーズコンテンツであった場合には、他シリーズのVoDコンテンツや、DVDパッケージ等)を埋め込んでも構わない。生成されるWebページの具体例を図23に示す。Webページを受信したユーザB(情報閲覧装置302)は、表示されたリンクをクリックすると、インターネットVoDサービス(コンテンツ配信サービス提供装置306)上で公開された当該コンテンツにワンステップでアクセスできる。
【0107】
以上のように、本実施形態によれば、配信メディアをまたがったコンテンツURI管理を行うことで、放送が視聴できない環境におけるユーザに、別の配信メディアにおけるコンテンツへのリンクを返すことできる。さらに、コンテンツ関連情報をWebページに埋め込むことで、広告や関連商品販売の機会を得る構成をとることも可能になっている。
【0108】
以上説明した少なくとも1つ実施例の効果は、テレビ番組を特定するURIとインターネット上のサービスとの連携サービスを複数のユーザが利用する場合において、あるユーザが生成したURIを異なるユーザが利用する場合に、ユーザ間の環境の違いによらず、当該異なるユーザが、URIを利用したサービスを利用可能とすることである。
【0109】
本発明のいくつか実施形態を説明したが、これら実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【0110】
101、201、301、401・・・情報処理装置、102、103・・・コンテンツ受信装置、104・・・サービス提供装置、302・・・情報閲覧装置、105、106、303・・・ネットワーク、1011・・・受信部、1012・・・送信部、1013・・・第1抽出部、1014・・・第2抽出部、1015・・・応答生成部、1016・・・応答情報記憶部、2011・・・変換部、2012・・・変換用情報記憶部、2013・・・コンテンツ情報記憶部 、3011・・・第3抽出部、4011・・・コンテンツクラス情報記憶部、4012・・・コンテンツ関連情報記憶部。
【特許請求の範囲】
【請求項1】
コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第1の機器から受信する受信部と、
前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出部と、
複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部と、
前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出部が抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成部と、
を備える情報処理装置。
【請求項2】
前記第1要素情報は、前記コンテンツに関する時刻情報である請求項1記載の情報処理装置。
【請求項3】
前記要素情報を変換するための第1変換用情報を記憶する第2記憶部と、
前記第1の機器に関する第1の情報と、前記第1変換用情報とをもとに、前記要素情報を変換する第1変換部と、を更に備える
請求項1又は2記載の情報処理装置。
【請求項4】
前記第1の機器に関する第1の情報は、前記応答情報要求に含まれる情報である請求項3記載の情報処理装置。
【請求項5】
前記コンテンツ識別情報を変換するための第2変換用情報を記憶する第3記憶部と、
前記第1の機器に関する第2の情報と、前記第2変換用情報とをもとに、前記コンテンツ識別情報を変換する第2変換部と、を更に備える
請求項1又は4記載の情報処理装置。
【請求項6】
前記第1の機器に関する第2の情報は、前記応答情報要求に含まれる情報である請求項5記載の情報処理装置。
【請求項7】
前記第1変換用情報は、コンテンツ識別情報を構成する要素情報と、放送区域及び放送局の組み合わせとを対応付けた情報であり、前記第1の機器に関する第1の情報は、前記第1の機器の属する放送区域であり、
前記第1変換部は、前記抽出部が抽出した要素情報と対応付けて記憶された放送区域が前記第1の機器の属する放送区域と異なる場合に、前記抽出部が抽出した要素情報を、前記第1の機器の属する放送区域及び前記抽出部が抽出した要素情報に対応付けられた放送局の組み合わせと対応付けられた要素情報に変換する
請求項3又は6記載の情報処理装置。
【請求項8】
前記第2変換用情報は、コンテンツ識別情報と、前記コンテンツを提供するメディアの情報とを対応付けた情報であり、前記第1の機器に関する第2の情報は、前記第1の機器が提供可能なメディアを示す情報であり、
前記変換部は、前記応答要求に含まれるコンテンツ識別情報によって特定されるコンテンツを提供するメディアが、前記第1の機器が提供可能なメディアと異なる場合に、前記第1の機器が提供可能なコンテンツのメディアに対応付けて記憶されたコンテンツ識別情報に変換し、
前記生成部は、前記変換部が変換後の要素情報がみたす前記条件に対応する応答情報を含む応答メッセージを生成する
請求項5又は7記載の情報処理装置。
【請求項9】
更に、第2抽出部を備え、
前記応答情報要求は、更に、前記第1の機器にかかる機器情報を含み、
前記第2抽出部は、前記応答情報要求から前記機器情報を抽出し、
前記記憶部は、前記応答情報を、前記要素情報に関する条件と前記機器情報に関する条件との組み合わせと対応付けて記憶し、
前記生成部は、前記第2抽出部が抽出した機器情報がみたす条件に対応する応答情報を含む応答メッセージを生成する
請求項1又は8記載の情報処理装置。
【請求項10】
前記応答メッセージは、前記第1の機器に表示される情報を含む請求項9記載の情報処理装置。
【請求項11】
前記応答メッセージは、前記応答メッセージに対応する前記コンテンツに対する処理を実行できるようにするユーザインターフェース情報としての制御命令プログラムを含む請求項10に記載の情報処理装置。
【請求項12】
前記制御プログラムは、前記コンテンツに対する処理を実行する実行機器の機種に応じて異なるプログラムである請求項11記載の情報処理装置。
【請求項13】
前記コンテンツに関する情報であるコンテンツ要素情報を記憶するコンテンツ情報記憶部をさらに備え、
前記生成部は、前記第応答メッセージに、前記コンテンツ要素情報を含める
請求項12記載の情報処理装置。
【請求項14】
前記生成部が生成した応答メッセージを前記第1機器に送信する送信部を備える請求項13記載の情報処理装置。
【請求項15】
前記第1機器と、前記コンテンツに対する処理を実行する実行機器とが異なる場合に、前記生成部は、前記応答メッセージに、前記実行機器を制御するための制御プロトコル情報を含める請求項14記載の情報処理装置。
【請求項16】
コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第1の機器から受信する受信ステップと、
前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出ステップと、
複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部を参照し、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出ステップで抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成ステップと、
を備える情報処理方法。
【請求項17】
コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第1の機器から受信する受信機能と、
前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出機能と、
複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部を参照し、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出機能で抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成機能と、
を備える情報処理プログラム。
【請求項1】
コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第1の機器から受信する受信部と、
前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出部と、
複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部と、
前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出部が抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成部と、
を備える情報処理装置。
【請求項2】
前記第1要素情報は、前記コンテンツに関する時刻情報である請求項1記載の情報処理装置。
【請求項3】
前記要素情報を変換するための第1変換用情報を記憶する第2記憶部と、
前記第1の機器に関する第1の情報と、前記第1変換用情報とをもとに、前記要素情報を変換する第1変換部と、を更に備える
請求項1又は2記載の情報処理装置。
【請求項4】
前記第1の機器に関する第1の情報は、前記応答情報要求に含まれる情報である請求項3記載の情報処理装置。
【請求項5】
前記コンテンツ識別情報を変換するための第2変換用情報を記憶する第3記憶部と、
前記第1の機器に関する第2の情報と、前記第2変換用情報とをもとに、前記コンテンツ識別情報を変換する第2変換部と、を更に備える
請求項1又は4記載の情報処理装置。
【請求項6】
前記第1の機器に関する第2の情報は、前記応答情報要求に含まれる情報である請求項5記載の情報処理装置。
【請求項7】
前記第1変換用情報は、コンテンツ識別情報を構成する要素情報と、放送区域及び放送局の組み合わせとを対応付けた情報であり、前記第1の機器に関する第1の情報は、前記第1の機器の属する放送区域であり、
前記第1変換部は、前記抽出部が抽出した要素情報と対応付けて記憶された放送区域が前記第1の機器の属する放送区域と異なる場合に、前記抽出部が抽出した要素情報を、前記第1の機器の属する放送区域及び前記抽出部が抽出した要素情報に対応付けられた放送局の組み合わせと対応付けられた要素情報に変換する
請求項3又は6記載の情報処理装置。
【請求項8】
前記第2変換用情報は、コンテンツ識別情報と、前記コンテンツを提供するメディアの情報とを対応付けた情報であり、前記第1の機器に関する第2の情報は、前記第1の機器が提供可能なメディアを示す情報であり、
前記変換部は、前記応答要求に含まれるコンテンツ識別情報によって特定されるコンテンツを提供するメディアが、前記第1の機器が提供可能なメディアと異なる場合に、前記第1の機器が提供可能なコンテンツのメディアに対応付けて記憶されたコンテンツ識別情報に変換し、
前記生成部は、前記変換部が変換後の要素情報がみたす前記条件に対応する応答情報を含む応答メッセージを生成する
請求項5又は7記載の情報処理装置。
【請求項9】
更に、第2抽出部を備え、
前記応答情報要求は、更に、前記第1の機器にかかる機器情報を含み、
前記第2抽出部は、前記応答情報要求から前記機器情報を抽出し、
前記記憶部は、前記応答情報を、前記要素情報に関する条件と前記機器情報に関する条件との組み合わせと対応付けて記憶し、
前記生成部は、前記第2抽出部が抽出した機器情報がみたす条件に対応する応答情報を含む応答メッセージを生成する
請求項1又は8記載の情報処理装置。
【請求項10】
前記応答メッセージは、前記第1の機器に表示される情報を含む請求項9記載の情報処理装置。
【請求項11】
前記応答メッセージは、前記応答メッセージに対応する前記コンテンツに対する処理を実行できるようにするユーザインターフェース情報としての制御命令プログラムを含む請求項10に記載の情報処理装置。
【請求項12】
前記制御プログラムは、前記コンテンツに対する処理を実行する実行機器の機種に応じて異なるプログラムである請求項11記載の情報処理装置。
【請求項13】
前記コンテンツに関する情報であるコンテンツ要素情報を記憶するコンテンツ情報記憶部をさらに備え、
前記生成部は、前記第応答メッセージに、前記コンテンツ要素情報を含める
請求項12記載の情報処理装置。
【請求項14】
前記生成部が生成した応答メッセージを前記第1機器に送信する送信部を備える請求項13記載の情報処理装置。
【請求項15】
前記第1機器と、前記コンテンツに対する処理を実行する実行機器とが異なる場合に、前記生成部は、前記応答メッセージに、前記実行機器を制御するための制御プロトコル情報を含める請求項14記載の情報処理装置。
【請求項16】
コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第1の機器から受信する受信ステップと、
前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出ステップと、
複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部を参照し、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出ステップで抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成ステップと、
を備える情報処理方法。
【請求項17】
コンテンツをネットワーク上で識別するコンテンツ識別情報を含む応答情報要求を、第1の機器から受信する受信機能と、
前記コンテンツ識別情報を構成する複数の要素情報を抽出する抽出機能と、
複数の前記要素情報のうち第1要素情報に関する条件と応答情報とを対応付けて記憶する記憶部を参照し、前記記憶部が記憶する前記第1要素情報に関する条件のうち、前記抽出機能で抽出した第1要素情報がみたす条件に対応付けて記憶された前記応答情報を含む応答メッセージを生成する生成機能と、
を備える情報処理プログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【公開番号】特開2013−115592(P2013−115592A)
【公開日】平成25年6月10日(2013.6.10)
【国際特許分類】
【出願番号】特願2011−259632(P2011−259632)
【出願日】平成23年11月28日(2011.11.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVASCRIPT
【出願人】(000003078)株式会社東芝 (54,554)
【Fターム(参考)】
【公開日】平成25年6月10日(2013.6.10)
【国際特許分類】
【出願日】平成23年11月28日(2011.11.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVASCRIPT
【出願人】(000003078)株式会社東芝 (54,554)
【Fターム(参考)】
[ Back to top ]