以下、図面を参照しながら本発明の実施形態を詳細に説明する。以下では、「アプリケーションプログラム」を、「アプリケーション」又は「アプリ」とも記載する。また、以下の説明では、アプリに記述された命令で指定される処理を実行することを、単に「アプリを実行」又は「アプリの実行」と呼ぶことがある。
図1は、本実施形態の一実施形態による放送通信連携システム1の全体構成図である。放送通信連携システム1は、放送送出装置2と、サービスサーバ3と、受信装置4と、連携端末5と、ログサーバ6とを有する。放送送出装置2、サービスサーバ3及びログサーバ6は送信側の装置であり、受信装置4及び連携端末5は、受信側の装置である。
放送送出装置2は、放送信号を送出する。サービスサーバ3は、アプリ本体やアプリで利用するコンテンツデータを、インターネットを介して受信側の装置へ配信する。アプリ本体とは、アプリケーションのプログラムである。受信装置4は、例えば、ハイブリッドキャスト対応テレビである。連携端末5は、例えば、スマートフォンやタブレット端末などの端末装置である。受信装置4及び連携端末5は、インターネットを介してサービスサーバ3と相互に通信できる。また、受信装置4と連携端末5は、無線LAN(Local Area Network)等のローカルネットワークを介して接続する。ログサーバ6は、連携端末5において収集したログデータを記憶する。なお、ログデータを連携端末5のみに蓄積する場合、放送通信連携システム1はログサーバ6を備えなくてもよい。
放送通信連携サービスの形態は複数存在するが、本実施形態の放送通信連携システム1では、ハイブリッドキャスト技術仕様(非特許文献1、2)に基づき、受信装置4において、デジタル放送サービスとインターネットサービスとが連携動作することを想定する。受信装置4が、放送またはインターネットにより配信されるアプリを実行することで、インターネット上のコンテンツを取得できるようになり、ユーザが放送通信連携サービスを利用できるようになる。さらに、ハイブリッドキャスト技術仕様に則り、受信装置4と連携端末5にインストールした端末側連携アプリとが連携動作する。
なお、本実施形態においては、受信装置4において動作するアプリは、放送事業者が配信する放送マネージドアプリとする。放送マネージドアプリは、放送送出装置2から送信される放送サービスの制御信号に基づいて、起動、終了、強制終了などのライフサイクルが制御される。
連携端末5に実装される端末側連携アプリは、通信により接続される他の装置である受信装置4と連携して動作するコンパニオンアプリである。端末側連携アプリは、受信装置4により実行される放送マネージドアプリと連携動作する1以上のサービスアプリを実行する。
放送マネージドアプリとサービスアプリとは連携動作することにより、ユーザへ提供するサービスを実行する。サービスとは、ユーザが連携端末5に行った操作に従って動作した結果の画像、映像、音声を、連携端末5に、又は、受信装置4及び連携端末5に出力することである。サービスの実行には、受信装置4が有する受信機機能から取得した情報などが利用される。受信機機能は、放送信号を受信し、ユーザにより選択されたチャンネルの番組映像や音声などのコンテンツデータを放送信号から取得し、デコードして出力する一連の機能である。ユーザに提供するサービスは任意であるが、一例として、SNS(ソーシャルネットワークサービス)、天気予報やニュースなどの情報の提供、外国語字幕の提供、テレビ映像とは異なる角度からの映像の提示などがある。
本実施形態では、端末側連携アプリにおいて実行されるサービスアプリがウェブアプリである場合を例に説明する。ウェブアプリとは、ウェブブラウザにより実行されるアプリである。ウェブアプリは、任意の手段により連携端末5に実装される。例えば、ウェブアプリは、放送マネージドアプリから取得が指示されたアプリでもよく、ユーザ操作により取得したアプリでもよく、連携端末5に予め実装されたアプリでもよい。放送マネージドアプリ及びウェブアプリのプログラムは、例えば、HTML(Hypertext Markup Language)により記述される。
図2は、受信装置4及び連携端末5のスタック図である。受信装置4は、ハードウェア、OS(Operation System)、レジデント及びアプリ実行部の4層から構成される。アプリ実行部は、例えばHTML5ブラウザであり、放送マネージドアプリを実行する。OS上で実行されるレジデントには、メモリに常駐するソフトウェアによる放送の受信機機能が搭載される。アプリ実行部で実行される放送マネージドアプリは、非特許文献1により規定される拡張API(Application Program Interface)を通してレジデントの受信機機能にアクセスすることができる。ハードウェアは、CPU(central processing unit)、各種メモリ、チューナー、デコーダ、通信装置、表示装置、入力装置などを含む。
連携端末5は、ハードウェア、OS及びネイティブアプリ実行部の3層から構成される。ネイティブアプリ実行部は、iOS(登録商標)やAndroid(登録商標)など端末のOSが提供するアプリを実行する。ネイティブアプリ実行部では、複数のネイティブアプリが動作可能である。ネイティブアプリは、特定のOSやプラットフォームで実行可能なプログラムである。本実施形態における端末側連携アプリはネイティブアプリであり、ネイティブアプリ実行部において動作する。なお、端末側連携アプリは、ネイティブアプリでなくてもよい。例えば、端末側連携アプリは、ネイティブアプリから、ネイティブアプリではないブラウザを呼び出し、ブラウザによりウェブアプリを実行させてもよい。ハードウェアは、CPU、各種メモリ、通信装置、表示装置、入力装置などを含む。
ハイブリッドキャストにおける端末連携機能は、受信装置4のアプリ実行部で動作する放送マネージドアプリと、連携端末5のネイティブアプリ実行部が実行する端末側連携アプリの内部で動作するウェブアプリの間で実現される。放送マネージドアプリとウェブアプリとの間では、非特許文献1で規定される拡張APIを用いてテキストメッセージを送信する。テキストメッセージには、任意のメッセージ内容を記述することができる。例えば、メッセージ内容は、アプリに対する各種の実行命令や、アプリが動作する際に用いられる付加的な情報などでもよい。
図3は、受信装置4の内部構成を示すブロック図であり、本実施形態と関係する機能ブロックのみを抽出して示してある。同図に示す受信装置4は、放送受信部401、分離部402、映像復号部403、音声復号部404、データ放送実行部405、通信入出力部406、リモコン入力制御部407、電源制御部408、アプリ実行部409、アプリ制御部410、放送通信連携部411、端末連携部412、映像合成部413、映像表示部414、音声合成部415及び音声出力部416を備えて構成される。
放送受信部401は、チューナーであり、放送送出装置2から送出された放送信号を受信し、復調する。分離部402は、放送受信部401が受信し、復調した放送信号を、映像データ、音声データなどのコンテンツデータや、コンテンツデータ以外のデータに分離する。コンテンツ以外のデータには、例えば、データ放送や、受信チャンネル、番組情報が記述されたSI(Service Information)や、イベントメッセージなどが含まれる。映像復号部403は、映像データを復号する。音声復号部404は、音声データを復号する。データ放送実行部405は、BML(Broadcast Markup Language)ブラウザであり、データ放送を実行する。
通信入出力部406は、通信ネットワークに接続するためのインターフェースである。通信入出力部406は、インターネットなどを介してアプリマーケット、アカウント管理サーバ、アプリ配信サーバなどのサービスサーバ3と接続する。また、通信入出力部406は、無線LANなどのローカルネットワークを介して連携端末5と接続する。リモコン入力制御部407は、リモコン(リモートコントローラ)からユーザがリモコンに行った操作を示すデータを受信する。電源制御部408は、受信装置4の電源の制御を行う。
アプリ実行部409は、放送マネージドアプリを実行するウェブ(Web)ブラウザである。放送マネージドアプリは、1以上のサービスの機能を提供する。アプリ制御部410は、放送信号から分離されたデータに含まれる情報に基づいて、放送マネージドアプリの起動や終了などの制御を行う。例えば、アプリ制御部410は、現在選択されている放送事業者(チャンネル)の放送マネージドアプリを、放送信号から分離されたAITに設定されている情報などに基づいて制御する。アプリ制御部410は、起動した放送マネージドアプリの識別情報を端末連携部412に通知する。
放送通信連携部411は、放送マネージドアプリにおいて放送又は通信により取得したコンテンツを連携動作させるために、アプリ実行部409に対して拡張APIで規定される機能を提供する。具体的には、放送通信連携部411は、受信中の放送信号に含まれるSIやイベントメッセージなどの情報や受信装置4が備える機能などへのアクセス手段を提供する。端末連携部412は、連携端末5とのペアリング処理と、受信装置4の放送マネージドアプリと連携端末5のウェブアプリ間の通信を仲介する処理とを行う。端末連携部412は、後述する図5に示す連携端末5の端末連携部531とペアで動作する。端末連携部412は、起動された放送マネージドアプリの識別情報を連携端末5に通知する。
映像合成部413は、映像復号部403が復号した放送番組の映像データと、データ放送実行部405やアプリ実行部409の処理結果に基づき出力された映像データとを合成し、映像表示部414に出力する。映像表示部414は、一般的なディスプレイであり、映像合成部413が合成した映像データの映像を表示する。
音声合成部415は、音声復号部404が復号した放送番組の音声データと、データ放送実行部405やアプリ実行部409の処理結果に基づき出力された音声データとを合成し、音声出力部416に出力する。音声出力部416は、一般的なスピーカーであり、音声合成部415が合成した音声データを音声により出力する。
図4は、アプリ実行部409の詳細な構成を示す機能ブロック図である。アプリ実行部409は、サービス実行部421、サービス実行管理部422及びメッセージ制御部423を有する。なお、アプリ実行部409は複数のサービス実行部421を備え得るが、同時に動作する放送マネージドアプリは一つのみとする。同図では、アプリ実行部409が備える複数のサービス実行部421をそれぞれ、サービス実行部421−1、421−2、421−3、…と記載している。
サービス実行部421は、アプリ制御部410による制御に基づき、放送マネージドアプリに含まれるサービス機能を実行する。サービス実行管理部422は、各サービス実行部421の起動及び終了の制御や状態管理を行い、複数のサービス実行部421を並列に実行させる。
メッセージ制御部423は、サービス実行部421が実行する放送マネージドアプリのサービス機能と連携端末5が実行するウェブアプリとの間のメッセージを適切に送受信するための制御を行う。メッセージ制御部423は、サービス識別管理部4231、メッセージ受信部4232、メッセージ判定部4233、メッセージ分配部4234及び送信元サービス設定部4235を有する。
サービス識別管理部4231は、サービス実行部421の識別子と、そのサービス実行部421により実行されるサービスの識別子との対応表を例えばリスト形式で管理する。サービスの識別子は、予め決められる。なお、各放送マネージドアプリは、プレフィックスを付加することなどにより、送信先のアドレスとして、サービス毎に予め決められた識別子を、メッセージの一部に付加して送受信を行う。
メッセージ受信部4232は、連携端末5からのメッセージ、及び、サービス実行部421からのメッセージを受信する。メッセージ受信部4232は、受信したメッセージを、メッセージ判定部4233及びメッセージ分配部4234に送信する。なお、メッセージ受信部4232は、メッセージ判定部4233に宛先の判定に必要な情報のみを送信してもよい。
メッセージ判定部4233は、メッセージ受信部4232から受信したメッセージに付加されたサービスの識別子と、サービス識別管理部4231に記憶される対応表とを照合してメッセージの送信先を決定し、メッセージ分配部4234に通知する。メッセージ判定部4233は、メッセージに付加された送信元のサービスの識別子と送信先のサービスの識別子とが同一の場合は連携端末5を送信先とし、異なる場合はサービス実行部421を送信先とする。また、メッセージ判定部4233は、実施形態によっては、サービス間の通信チャンネルを確立するための識別子の発行や、その識別子に基づいたメッセージの送信先の決定を行う。
メッセージ分配部4234は、メッセージ受信部4232から受信したメッセージを、メッセージ判定部4233が決定した送信先に送信する。送信元サービス設定部4235は、サービス実行部421が連携端末5または他のサービス実行部421に対して送信するメッセージに、そのサービス実行部421において実行中の放送マネージドアプリのサービスの識別子を付加する。
図5は、連携端末5の構成を示す機能ブロック図であり、本実施形態と関係する機能ブロックのみを抽出して示してある。同図においては、端末側連携アプリを中心とした機能構成を示す。連携端末5は、ハードウェア部51、OS部52、連携アプリ実行制御部53及び他アプリ実行制御部54を有する。
ハードウェア部51は、CPU、各種メモリ、通信装置、ディスプレイ(表示装置)、ユーザ操作を入力するための入力デバイス(入力装置)などの各種ハードウェアからなる。ディスプレイがタッチパネルである場合、入力デバイスは、タッチパネルに配されたタッチセンサーである。ハードウェア部51は、通信装置により実現される通信入出力部511、及び、各種のセンサー512を有する。同図では、n個(nは自然数)のセンサーをセンサー512−1〜512−nと記載している。
通信入出力部511は、通信ネットワークに接続するためのインターフェースである。通信入出力部511は、インターネットなどを介してサービスサーバ3及びログサーバ6と接続する。また、通信入出力部511は、無線LANなどのローカルネットワークを介して受信装置4と接続する。センサー512は、連携端末5の状態や連携端末5が存在する環境に関する情報を検出する。センサー512は、例えば、GPS(Global Positioning System)、加速度センサー、温度センサー、磁気センサー、輝度センサー、近接センサーなどであるが、これらに限定されない。
OS部52は、OSにより実現され、端末全体を制御し、連携アプリ実行制御部53及び他アプリ実行制御部54に、ハードウェア部51へのインターフェースを提供する。
連携アプリ実行制御部53は、CPUがメモリに記憶された端末側連携アプリを読み出して実行することにより実現される。連携アプリ実行制御部53は、端末連携部531、サービス実行部532、サービス実行管理部533、メッセージ制御部534、ID管理部551、接続状態管理部552、リモコン部553、ログ管理部554、ログアクセス制御部555、ユーザポリシー設定部556及び事業者ポリシー設定部557を有する。複数のサービス実行部532をそれぞれ、サービス実行部532−1、532−2、532−3、…と記載する。
端末連携部531は、受信装置4とのペアリング処理と、受信装置4の放送マネージドアプリと連携端末5のウェブアプリ間の通信を仲介する処理とを行う。端末連携部531は、受信装置4の端末連携部412とペアで動作する。
サービス実行部532は、個々のサービスを提供するためのウェブアプリを実行する。サービス実行部532の実装方法としては、Android(登録商標)搭載端末におけるWebView、iOS搭載端末におけるUIWebViewなどが挙げられる。サービス実行部532は複数存在することを前提としており、各サービス実行部532には一意の識別子が割り当てられ、サービスの識別子としても用いられる。各サービス実行部532は、以下のようなウェブアプリを実行する。
(1)現在実際にサービスが提供されている受信装置4の放送マネージドアプリと連携したウェブアプリ。なお、このウェブアプリを実行するのは一つのサービス実行部532である。
(2)複数の放送局が配信する放送マネージドアプリと連携して共通に利用することができるウェブアプリ。
(3)受信装置4と連携しないウェブアプリ。
サービス実行管理部533は、各サービス実行部532の起動及び終了の制御や状態管理を行い、複数のサービス実行部532を並列に実行させる。サービス実行管理部533は、受信装置4からの指示又はユーザ操作に基づいて、サービス実行部532、または、サービス実行部532上で実行されるウェブアプリの起動及び終了の制御や、フォアグラウンドでの動作又はバックグラウンドでの動作など状態の変更を行う。また、サービス実行管理部533は、実行中のウェブアプリの提供者の識別情報とウェブアプリの識別情報の一方又は両方を管理する。ウェブアプリの提供者の識別情報として、例えば、ウェブアプリの取得先のドメイン名を用いることができる。
ID管理部551は、個々の利用者IDを発行し、管理する。利用者IDは、例えば、連携端末5、連携端末5に実装された端末側連携アプリ、又は、連携端末5のユーザを一意に特定する識別情報である。利用者IDは、ユーザが入力したものでもよく、ID管理部551が外部の装置と協働するなどして生成したものでもよい。
接続状態管理部552は、連携端末5が受信装置4と接続状態であるか否かを検知し、その状態を管理する。リモコン部553は、受信装置4のソフトウェアリモコンに相当する。具体的には、リモコン部553は、チャンネルボタン、色ボタン、dボタン、上下左右ボタン、決定ボタン、戻るボタン、音量ボタン、電源ボタンなどのユーザインターフェースと、ユーザがそれらを操作したときに、その操作に応じた命令を発行し、端末連携部531及び通信入出力部511を介して受信装置4に送信する機能を有する。
ログ管理部554は、ユーザが端末側連携アプリを利用する際に取得可能な、複数の種類のログデータを統合的に管理する。ログデータには、ログが得られた時刻の情報が含まれる。ログアクセス制御部555は、サービス実行部532において実行中のウェブアプリに対して、ログ管理部554において管理される各種ログデータへのアクセスを許可するか否かのアクセス制御を行う。ログアクセス制御部555は、このアクセス制御を、ユーザポリシー設定部556にユーザのポリシーとして設定された条件、及び、事業者ポリシー設定部557に事業者のポリシーとして設定された条件に基づいて行う。
ユーザポリシー設定部556は、ログ管理部554に各種ログデータの管理を認可するか否かの認否や、ウェブアプリからの各種ログデータへのアクセスを認可するか否かの認否を、ユーザがポリシーとして設定する機能を有する。ユーザポリシー設定部556は、内部に備えるユーザポリシー記憶部5561に、ユーザが設定したポリシーを示すユーザポリシーデータを書き込む。なお、ユーザポリシー記憶部5561は、ユーザポリシー設定部556の外部に備えられてもよい。ログデータを記憶するログ記憶部が、連携端末5のログ管理部554内と、インターネットを介して接続されるログサーバ6などのクラウドのサーバ内との両方に実装される場合は、どちらを利用するかのポリシーをユーザポリシー設定部556にさらに設定することもできる。ログ管理部554は、取得したログデータを、ユーザポリシー記憶部5561に記憶されるポリシーに従って、後述する図6に示すログ管理部554内のログ記憶部5542に書き込むか、ログサーバ6に送信する。ユーザがユーザポリシーの設定を行うための機能は、端末側連携アプリによる画面として提供し、連携端末5のグラフィカルユーザインターフェース(GUI)を介してユーザが設定することを想定する。
事業者ポリシー設定部557は、ウェブアプリからログ管理部554が管理するログデータへのアクセスを認可するか否かの認否を、放送事業者がポリシーとして設定する機能を有する。アクセスの認否は、ウェブアプリを提供する事業者ごとに設定されてもよく、ウェブアプリ又はサービスごとに設定されてもよい。事業者ポリシー設定部557は、内部に備える事業者ポリシー記憶部5571に、放送事業者により設定されたポリシーを示す事業者ポリシーデータを書き込む。この事業者ポリシーデータは、端末側連携アプリのアップデートや、インターネット上のサービスサーバ3から事業者のポリシーに関するデータを連携端末5に送信することにより更新される。あるいは、事業者ポリシー設定部557は、受信装置4が放送信号から取得した事業者ポリシーデータを、通信入出力部511及び端末連携部531を介して受信し、事業者ポリシー記憶部5571に記憶される事業者ポリシーデータを更新してもよい。なお、事業者ポリシー記憶部5571は、事業者ポリシー設定部557の外部に備えられてもよい。
連携端末5におけるログ管理について説明する。
図6は、ログ管理部554の詳細な構成を示す図である。ログ管理部554は、ログデータベース部5541、放送サービス判定部5543、ログアクセス用API提供部5544及び外部管理インターフェース部5545を備える。
ログデータベース部5541は、端末側連携アプリの各機能部からログデータを取得し、取得したログデータを管理するデータベースである。ログデータベース部5541は、他の機能部から取得したログデータをログ記憶部5542へ書き込むログ書込処理と、ログ記憶部5542に記憶されるログデータを読み出して他の機能部へ出力するログ読出処理を行う。なお、ログサーバ6にログデータベース部5541として動作する機能部を設けてもよい。以下に、ログデータベース部5541がログデータを取得する機能部と、具体的にその機能部から取得するログデータを示す。
(1)ログデータベース部5541は、サービス実行管理部533から、どのサービス実行部532又はウェブアプリが実行されているかの状態を示すログデータを取得する。状態取得方法は、サービス実行管理部533から定期的に送信する場合と、状態変化時にのみ送信する場合の2通りが考えられる。
(2)ログデータベース部5541は、接続状態管理部552から、連携端末5が受信装置4と接続しているか否かの状態を示す接続情報をログデータとして取得する。状態取得方法は、接続状態管理部552から定期的に送信する場合と、状態変化時にのみ送信する場合の2通りが考えられる。このログデータは、連携端末5が受信装置4と連携可能であるかを判定するために用いられる。
(3)ログデータベース部5541は、リモコン部553から、リモコン部553が提供するユーザインターフェースによるユーザの操作履歴をログデータとして取得する。例えば、数字キーが押されたことにより、放送チャンネルの選局が行われたこと、dボタンが押されたことによりハイブリッドキャストまたはデータ放送が起動されたこと、電源ボタンが押されたことにより受信装置4の電源がON/OFFされたこと、などを検知するために用いる。ここでは、リモコン部553は、ボタンが押されたというイベント発行時にログデータベース部5541に、そのイベント(ユーザによるボタンの操作)を示すログデータを通知する。
(4)ログデータベース部5541は、メッセージ制御部534から、受信装置4の放送マネージドアプリと連携端末5のウェブサービス間又は連携端末5のウェブサービス間で送受信するメッセージや、受信装置4と連携端末5のメッセージ制御部423間で送受信するコマンドを取得し、取得したメッセージ又はコマンドに関する情報をログデータとする。例えば、ログデータには、メッセージ又はコマンドの送信元を特定する情報と、メッセージ又はコマンドの送信先を特定する情報と、メッセージ又はコマンドの内容に関する情報とのうち少なくとも一部が含まれる。メッセージ又はコマンドの内容に関する情報とは、メッセージ又はコマンドの内容の全て又は一部、あるいは、メッセージ又はコマンドの内容の全て又は一部に任意のデータ処理を行って得られる情報である。例えば、受信装置4の放送マネージドアプリから連携端末5のウェブアプリを起動するために端末連携部531に送信されるsetURLForCompanionDeviceの値をコマンドから取得し、どの放送局のサービスであるかを検知するために用いることができる。setURLForCompanionDeviceの値は、具体的には、起動対象のウェブアプリのURL(Universal Resource Locator)を示す。メッセージの具体例については後述する。
(5)ログデータベース部5541は、連携端末5のハードウェアに実装されるGPS、加速度センサー、輝度センサーなど多様なセンサー512から、センサー512の検出結果を示すログデータを取得する。
(6)ログデータベース部5541は、サービス実行部532からウェブアプリの実行状態や、サービス実行部532により実行されるウェブアプリが行ったサービスサーバ3へのアクセスの履歴や、サービス実行部532により実行されるウェブアプリを提供しているときにユーザが行った操作履歴データをログデータとして取得する。操作履歴データは、例えば、タップ、スワイプなどの画面の操作の履歴である。
ログデータベース部5541は、収集した上記のログデータに、時刻情報に加え、ID管理部551から取得した利用者IDを対応付けてログ記憶部5542に書き込む。利用者IDは、ユーザのID、デバイスのID、又は、端末側連携アプリのIDなどである。さらに、ログデータベース部5541は、ログデータに、個々のログデータを識別するためのログIDと、ログデータの種類を表すログTypeを付加して、ログ記憶部5542に書き込む。ログTypeの例については、後述する図8を用いて説明する。
放送サービス判定部5543は、リモコン部553から取得した操作履歴のデータや、メッセージ制御部534から取得したsetURLForCompanionDevice()の値に基づいて、受信装置4において受信中の放送サービスを判定する機能を提供する。放送サービスの判定方法の詳細については後述する。ログアクセス用API提供部5544は、サービス実行部532により実行されるウェブアプリがログデータベース部5541にアクセスするためのAPIを提供する。
外部管理インターフェース部5545は、ログデータがログサーバ6に蓄積される場合に、ログサーバ6との間の通信を制御する。図6では、連携端末5がログデータベース部5541を実装する場合を示しているが、通信ネットワークに接続されるクラウド上のログサーバ6に、ログデータベース部5541と同様の機能を実装する場合が考えられる。ログサーバ6がログデータベース部5541と同様の機能を実装する場合、外部管理インターフェース部5545は、ログデータベース部5541が収集し、ログ記憶部5542に記憶させたログデータを定期的に、又は、ログデータの発生の都度、読み出してログサーバ6に送信する。あるいは、連携端末5はログデータベース部5541を設けず、外部管理インターフェース部5545が、接続状態管理部552をはじめとする各機能部から取得したログデータを直接ログサーバ6に送信してもよい。
次に、放送サービス判定部5543が受信装置4において受信中の放送サービスを判定する方法について説明する。判定に用いるデータとしては、以下の3つが挙げられる。
(1)リモコン部553から受信した操作履歴のデータを用いる。ユーザが連携端末5を使って受信装置4の放送サービスを選局する際には、リモコン部553がディスプレイに表示させた数字キーなどを操作することが考えられる。この操作によって押下された数字キーのデータが、リモコン部553から放送サービス判定部5543に送信される。放送サービス判定部5543は、この数字キーに基づいて、放送事業者又はチャンネルを判定する。放送サービス判定部5543は、リモコン部553から数字キーが操作されたことを示す操作履歴が出力された場合、その数字キーに基づき判定した放送事業者又はチャンネルの情報を設定した視聴履歴のログデータを生成し、ログデータベース部5541に出力する。
(2)受信装置4から受信したURLの値を用いる。受信装置4において放送マネージドアプリが起動しており、かつ、端末連携サービスが提供されている場合は、放送マネージドアプリから端末側連携アプリに対してsetURLForCompanionDevice()関数を用いて、端末側連携アプリ上で動作させるウェブアプリのURLをコマンドで送信することが考えられる。メッセージ制御部534はそのコマンドを受信した際に、受信したコマンドから取得したURL値を放送サービス判定部5543に送信する。放送サービス判定部5543は、例えば、ドメイン名など、そのURLに含まれる情報に基づいて放送事業者を判別する。放送サービス判定部5543は、判別した放送事業者の情報を設定した視聴履歴のログデータを生成してログデータベース部5541に出力する。
(3)受信装置4から受信した視聴履歴のデータを用いる。受信装置4の放送マネージドアプリは、受信中の放送サービスのservice_idやevent_idの値を視聴履歴のデータとして取得し、sendTextToCompanionDevice()関数を用いて連携端末5に送信する。この場合、メッセージ制御部534は、放送マネージドアプリから送信されたメッセージによりservice_idやevent_idを受信した際に、その値を放送サービス判定部5543に送信する。放送サービス判定部5543は、メッセージの内容から取得したservice_idの値やevent_idの値に基づいて放送事業者を判別する。放送サービス判定部5543は、判別した放送事業者の情報を設定した視聴履歴のログデータを生成してログデータベース部5541に出力する。
図7は、放送サービス判定部5543が実装する放送事業者判定データベースの例を示す図である。放送サービス判定部5543は、この放送事業者判定データベースを参照して、受信装置4において受信中のチャンネルの放送事業者を判定する。予め全ての放送事業者には、一意の事業者IDが割り当てられている。放送では、リモコンにより入力されるチャンネルの番号、つまり、数字キーに割り当てられる放送事業者が地域ごとに異なる。そのため、地域ごとに放送事業者判定テーブルを設ける。各放送事業者判定テーブルは、放送事業者の事業者IDを主キーとし、放送事業者名、service_id、放送マネージドアプリからsetURLForCompanionDevice()関数を用いて送信されるURLのドメイン名、数字キーを対応付けてレコードに格納する。一つの事業者IDに対応してドメイン名やservice_idが複数存在する場合もある。
予めユーザは、どの地域に設置された受信装置4を利用しているのかを連携端末5に設定する。あるいは、放送サービス判定部5543は、連携端末5が備えるGPSの出力に基づいて地域の情報を取得してもよい。放送サービス判定部5543は、その地域の情報に基づき、放送事業者判定データベースを構成する放送事業者判定テーブルのうち、参照するテーブルを決定する。放送サービス判定部5543は、数字キー、受信装置4からのURLの値、受信装置4からの視聴履歴のデータが入力されると、決定した放送事業者判定テーブルを参照して放送サービスを提供している放送事業者を特定し、ログデータベース部5541に通知する。
次に、ログ管理部554とログアクセス制御部555との関係について述べる。サービス実行部532により実行中のウェブアプリが、ログデータベース部5541に格納されたログデータを利用する際には、ログアクセス用のAPIをコールする。ログアクセス用API提供部5544が提供するこのAPIがコールされた際、または、ログアクセス用API提供部5544がAPIのコール結果としてログデータベース部5541から読み出したログデータをサービス実行部532へ渡す際に、ログアクセス制御部555は、ユーザポリシー設定情報及び事業者ポリシー設定情報を参照してウェブアプリにログデータを提供するか否かを判定し、アクセス制御を実行する。
図8は、ユーザポリシー記憶部5561に記憶されるユーザポリシー設定情報の例を示す図である。ユーザポリシー設定情報は、ログの種類を表す項目の情報をキーとし、各項目に対応して、ログの管理を認可するか否か、及び、ウェブアプリからのアクセスを認可するか否かをそれぞれ示すレコードからなる。キーとして用いられる項目の情報は、ログの項目を特定するログTypeと、項目名とにより示される。同図では、認可を「1」、否認を「0」としている。ログ管理が「0」である場合は、ログアクセスも「0」に設定される。各項目の例を以下に示す。ここで設定されたユーザポリシー設定情報がログアクセス制御部555に通知され、ログアクセス制御部555はユーザポリシー設定情報に従って以下のように各APIに対するアクセス制御を実行する。
(1)項目「サービス利用履歴」は、どのサービスを利用したかの情報を示すログデータであり、サービス実行管理部533から得られる。
(2)項目「Web閲覧履歴」は、サービス実行部532がサービスサーバ3により提供されるウェブページにアクセスしたときの取得先のURLの情報を示すログデータであり、サービス実行部532から得られる。
(3)項目「画面操作履歴」は、ウェブアプリの操作履歴を示すログデータであり、サービス実行部532から得られる。
(4)項目「テレビとの接続状態」は、連携端末5との接続状態を示すログデータであり、接続状態管理部552から得られる。
(5)項目「リモコン操作履歴」は、リモコン部553に対するユーザの操作履歴を示すログデータであり、リモコン部553から得られる。
(6)項目「視聴履歴」は、受信装置4において受信した放送サービスの履歴を示すログデータであり、放送サービス判定部5543から得られる。
(7)項目「GPS」は、センサー512の一つであるGPSから得られたログデータに相当する。
(8)項目「加速度センサー」は、センサー512の一つである加速度センサーから得られたログデータに相当する。
ログデータベース部5541は、ユーザポリシー設定情報のログ管理に「0」が設定されている項目のログデータについてはログ記憶部5542に書き込まずに破棄し、ログ管理に「1」が設定されている項目のログデータについてはログ記憶部5542に書き込む。また、ログアクセス制御部555は、ユーザポリシー設定情報のログアクセスに「0」が設定されている項目のログデータについては、サービス実行部532からのアクセスを認可しない。
ログアクセス制御部555は、ユーザポリシー設定情報のログアクセスに「1」が設定されている項目のログデータについてはサービス実行部532からの利用を認可する。ただし、ログアクセス制御部555は、ログ管理部554のログデータベース部5541で管理されているログデータのうち、放送サービス判定部5543を経由して記録された視聴履歴のログデータについては、事業者ポリシー設定部557の設定情報に従ってウェブアプリからのアクセス制御を行う。視聴履歴には、各放送サービスの受信開始から終了までの時刻を含めることとする。
図9は、事業者ポリシー記憶部5571に記憶される事業者ポリシー設定情報の例を示す図である。事業者ポリシー設定情報は、地域毎の事業者ポリシー設定テーブルから構成される。各地域の事業者ポリシー設定テーブルは、図7に示すその地域の放送事業者判定テーブルと同様の放送事業者を示す情報をキーとする。つまり、図9に示す事業者ポリシー設定テーブルは、事業者ID、放送事業者名、放送事業者のドメイン(自局ドメイン)、数字キーをキーとし、各放送事業者の視聴履歴へのアクセスを認可するウェブアプリのドメインが記述される。
事業者ポリシー設定部557は、連携端末5に設定された地域に対応した事業者ポリシー設定テーブルを事業者ポリシー記憶部5571から読み出してログアクセス制御部555に通知する。ログアクセス制御部555は、通知された事業者ポリシー設定テーブルの設定に従って、サービス実行部532からのログデータへのアクセス制御を実行する。以下では、ドメイン「XXX」が含まれるURLを取得先としてサービスサーバ3から取得したアプリを、ドメイン「XXX」のアプリと記載する。
例えば、放送事業者「AAA東京」は、自社のドメイン「aaa.co.jp」のウェブアプリと、第3者のドメイン「xyz.co.jp」のウェブアプリから、自社の放送の視聴履歴を示すログデータへのアクセスを認可する。また、放送事業者「CCC」は、全てのドメインのウェブアプリからの自社の放送の視聴履歴を示すログデータへのアクセスを認可する。
さらに、ログアクセス制御部555は、事業者ポリシー設定情報を用いて、視聴履歴だけでなく、各事業者のウェブアプリ又はサービスに関するログデータへのアクセス制御を行ってもよい。例えば、図9に示す事業者ポリシー設定情報の場合、放送事業者「AAA東京」は、自社のドメイン「aaa.co.jp」のウェブアプリと、第3者のドメイン「xyz.co.jp」のウェブアプリから、自社のドメインのウェブアプリに関するログデータへのアクセスを認可する。また、放送事業者「CCC」は、全てのドメインのウェブアプリからの自社のドメインのウェブアプリに関するログデータへのアクセスを認可する。ウェブアプリに関するログデータは、例えば、利用サービス、Web閲覧履歴、画面操作履歴などのログデータである。そのため、ウェブアプリに関するログデータには、ウェブアプリが提供しているサービスのID、ウェブアプリの取得先のURL又はそのURLから得られる事業者の識別(例えば、ドメインや事業者ID)などの情報が含まれるか付加されるようにする。
なお、図9に示す事業者ポリシー設定情報には、放送事業者毎に、視聴履歴の利用を認可するドメインの情報が設定されているが、視聴履歴の利用を認可しないドメインの情報を設定してもよい。また、上記では、事業者ポリシー設定情報に、視聴履歴の利用を認可する又は認可しないドメインを放送事業者毎に設定しているが、視聴履歴の利用を認可する又は認可しない事業者、ウェブアプリ、サービスを放送事業者毎に設定してもよい。各事業者が自社の提供するウェブアプリ又はサービスに関するログデータの利用についてアクセス制御をさらに行う場合、事業者ポリシー設定情報に、各事業者のウェブアプリ又はサービス毎に、ログデータの利用を認可する又は認可しないドメイン、事業者、ウェブアプリ、サービスの情報を設定する。これにより、ログアクセス制御部555は、事業者ポリシー設定情報に従い、ある放送事業者が提供する全て又は一部のウェブアプリ又はサービスに関するログデータへのアクセスの認否を、ログアクセス用のAPIをコールしたウェブアプリ、そのウェブアプリのドメイン、そのウェブアプリを提供している事業者、又は、そのウェブアプリにより提供されるサービスに基づいて制御する。
次に、受信装置4と連携端末5におけるメッセージの送受信について説明する。
ハイブリッドキャストでは、受信装置4と連携端末5との間でテキストメッセージを送受信するためのAPIが規定されている。メッセージ制御部534は、受信装置4が実行する放送マネージドアプリと連携端末5の各サービス実行部532が実行するウェブアプリとの間、および、サービス実行部532の間のメッセージを適切に送受信するための制御を行う。メッセージ制御部534の詳細を、図10を用いて説明する。
図10は、メッセージ制御部534の詳細な構成を示す機能ブロック図である。メッセージ制御部534は、サービス識別管理部5341、メッセージ受信部5342、メッセージ判定部5343、メッセージ分配部5344及び送信元サービス設定部5345を有する。
サービス識別管理部5341は、サービス実行部532の識別子と、そのサービス実行部532が実行するウェブアプリにより提供されるサービスであるウェブサービスの識別子との対応表を例えばリスト形式で管理する。ウェブサービスの識別子は、予め決められる。なお、各ウェブサービスは、プレフィックスを付加することなどにより、送信先のアドレスとして、ウェブサービス毎に予め決められた識別子を、メッセージの一部に付加して送受信を行う。
メッセージ受信部5342は、受信装置4からのメッセージ、及び、各サービス実行部532からのメッセージを受信する。メッセージ受信部5342は、受信したメッセージを、メッセージ判定部5343及びメッセージ分配部5344に送信する。なお、メッセージ受信部5342は、メッセージ判定部5343に宛先の判定に必要な情報のみを送信してもよい。
メッセージ判定部5343は、メッセージ受信部5342から受信したメッセージに付加されたサービスの識別子と、サービス識別管理部5341に記憶される対応表とを照合してメッセージの送信先を決定し、メッセージ分配部5344に通知する。メッセージ判定部5343は、メッセージに付加された送信元のサービスの識別子と送信先のサービスの識別子とが同一の場合は受信装置4を送信先とし、異なる場合はサービス実行部532を送信先とする。また、メッセージ判定部5343は、実施形態によっては、サービス間の通信チャンネルを確立するための識別子の発行や、その識別子に基づいたメッセージの送信先の決定を行う。
メッセージ分配部5344は、メッセージ受信部5342から受信したメッセージを、メッセージ判定部5343が決定した送信先に送信する。送信元サービス設定部5345は、サービス実行部532が受信装置4または他のサービス実行部532に対して送信するメッセージに、送信元のサービス実行部532の識別子を付加する。
上述したように、受信装置4で実行される放送マネージドアプリは一つである。そこで、複数のサービスを一つの放送マネージドアプリで実行するために、一つのHTML文書(アプリケーションプログラム)内に複数のサービスそれぞれを実行させるためのプログラムを記述する。例えば、放送局Aが提供する現行の放送マネージドアプリでのサービスAに加え、放送局Aと放送局Bとが共通に提供するサービスXを同時に運用することを想定する。このとき、放送局Aが提供するサービスAのHTML文書内と、放送局Bが提供する放送マネージドアプリのサービスBのHTML文書内に、サービスXの機能をJavaScript(登録商標)等で記述する。さらに、複数のサービスで個々にデバイス間でメッセージを送受信するため、連携端末5のサービス実行管理部533と同等の機能を有するサービス実行管理部422の機能、連携端末5のメッセージ制御部534と同等の機能を有するメッセージ制御部423の機能を、サービスAとサービスBの両方のサービスのHTML文書内にサービスXの機能と同様に記述する。サービス実行管理部422の機能には、サービス実行部421の起動や終了などの制御、サービスごとに画面に表示するか否かの制御が含まれる。
図11は、放送マネージドアプリの記述例を示す図である。同図は、放送局Aの放送マネージドアプリを、HTML文書として記述した例である。同図に示すように、divでサービスA、サービスXのそれぞれ表示する要素をグループ化し、idを指定する(serviceA、common_serviceX)。サービス実行部421で実行される各サービスの機能は、JavaScript(登録商標)で記述し、head部分にインクルードする(serviceA.js、common_serviceX)。さらに、サービス実行管理部422によるサービス実行部421の起動や終了などの制御機能(common_appcontrol.js)、メッセージ制御部423の機能(common_messaging.js)、及び、サービス実行管理部422によるサービス毎の表示の制御機能(common_viewcontrol.js)も同様にインクルードする。このようにHTML文書として記述された放送マネージドアプリをアプリ実行部409が実行することにより、アプリ実行部409は、サービス実行部421、サービス実行管理部422及びメッセージ制御部423として動作する。これにより、受信装置4上の放送マネージドアプリと、連携端末5上のコンパニオンアプリ双方に同等の機能が導入されるため、複数のサービスを一対の受信装置4と連携端末5上で利用できるようになる。
なお、サービス実行管理部422、メッセージ制御部423及びサービス実行部421として動作する機能部が、予め受信装置4のアプリ実行部409に実装されていてもよい。
連携端末5のサービス実行管理部533は、受信装置4からの指示、又は、連携端末5にユーザが入力した指示に従って、サービス実行部532によるウェブアプリの起動又は停止を行う。具体的には、受信装置4のアプリ実行部409が実行している放送マネージドアプリからサービス起動指示が出力されると、端末連携部412は連携端末5を送信先とし、通信入出力部406を介してサービス起動指示を送信する。サービス起動指示には、起動対象のウェブアプリを特定する情報が含まれる。サービス起動指示として、例えば、setURLForCompanionDevice()関数によるコマンドが用いられる。連携端末5の端末連携部531は、通信入出力部511を介して受信したサービス起動指示をサービス実行管理部533へ出力する。サービス実行管理部533は、受信したサービス起動指示により起動が指示されたウェブアプリを起動する。あるいは、連携端末5の入力デバイスによりユーザが起動対象のウェブアプリの情報を入力すると、サービス実行管理部533は、その起動対象のウェブアプリを起動する。これにより、連携アプリ実行制御部53において、サービス実行部532が動作する。
図12は、メッセージの例を示す。
図12(a)は、受信装置4において放送マネージドアプリのサービスPの機能を実行しているサービス実行部421から、連携端末5の端末側連携アプリにおいてサービスPのウェブアプリを実行しているサービス実行部532へ送信されるメッセージM11を示す。図12(b)は、連携端末5の端末側連携アプリにおいてサービスPのウェブアプリを実行しているサービス実行部532から、同じく端末側連携アプリにおいてサービスQのウェブアプリを実行しているサービス実行部532に送信されるメッセージM21を示す。メッセージM11は、放送マネージドアプリのサービスPの機能を実行しているサービス実行部421により記述されるメッセージであり、メッセージM12は、サービスPのウェブアプリを実行しているサービス実行部532において記述されるメッセージである。メッセージM11、M21には、送信先のサービスの識別子(dst:ServiceP、dst:ServiceQ)、メッセージ本体(message)が記述される。
図12(c)に示すメッセージM12及び図12(d)に示すメッセージM22は、連携端末5のメッセージ受信部5342が受信するメッセージである。メッセージM12は、メッセージM11に送信元のサービスPの識別子(src:ServiceP)が付加されたものであり、メッセージM22は、メッセージM21に送信元のサービスPの識別子(src:ServiceP)が付加されたものである。
具体的には、受信装置4の送信元サービス設定部4235が、メッセージM11に送信元のサービスPの識別子を追加し、メッセージM12となる。メッセージM12の場合は、放送マネージドアプリを実行することにより生成されるメッセージ制御部423が有する送信元サービス設定部4235の機能(図11におけるcommon_messaging.js)によって、送信元のサービスの識別子が設定される。一方、メッセージM22の場合は、連携端末5の送信元サービス設定部5345が、メッセージM21に送信元のサービスPの識別子を付加する。
なお、メッセージのフォーマットはこれらの記述例に限らない。また、本実施形態では、送信元のサービスの識別子と送信先のサービスの識別子のみを記述したが、受信装置4もしくは連携端末5を送信先として記述しても構わない。
図13及び図14は、メッセージ制御部423及びメッセージ制御部534の動作を示す処理フローである。以下では、メッセージ制御部534を例にして説明するが、メッセージ制御部423も同様に動作する。
図13は、メッセージ受信時の処理フローを示す。連携端末5の端末連携部531は、通信入出力部511を介して受信装置4から受信したメッセージを、メッセージ受信部5342に出力する。メッセージ受信部5342は、端末連携部531からメッセージを受信する(ステップS105)。メッセージ受信部5342は、受信したメッセージから送信先のサービスの識別子及び送信元のサービスの識別子を検出する(ステップS110)。メッセージ受信部5342は、メッセージが読み出した送信先のサービスの識別子及び送信元のサービスの識別子をメッセージ判定部5343に通知し、メッセージ全体をメッセージ分配部5344に通知する(ステップS115)。
メッセージ判定部5343は、サービス識別管理部5341に、送信先のサービスの識別子により特定されるサービスをサービス実行部532が実行しているか否かの照合を依頼する(ステップS120)。サービス識別管理部5341は、メッセージ判定部5343から通知された送信先のサービスの識別子と対応付けて対応表に登録されているサービス実行部532の識別子を取得する。サービス識別管理部5341は、サービス実行部532の識別子が取得できた場合はその識別子を設定した照合結果を、取得できなかった場合はサービス実行部532がないことを示す照合結果を出力する。
メッセージ判定部5343は、サービス識別管理部5341から、送信先のサービスの識別子により特定されるサービスを実行するサービス実行部532があることを示す照合結果を受信したと判断すると(ステップS125:はい)、ステップS130の処理を行う。すなわち、メッセージ判定部5343は、メッセージ分配部5344に対して、メッセージに記述された送信先のサービスの識別子により特定されるウェブサービスを実行しているサービス実行部532に、メッセージを送信するよう通知する(ステップS130)。メッセージ分配部5344は、メッセージ判定部5343の指示に従い、メッセージに記述された送信先のサービスの識別子により特定されるサービス実行部532に、メッセージを送信する(ステップS135)。
一方、メッセージ判定部5343は、サービス識別管理部5341から送信先のサービスの識別子により特定されるサービスを実行するサービス実行部532がないことを示す照合結果を受信したと判断すると(ステップS125:いいえ)、ステップS140の処理を行う。すなわち、メッセージ判定部5343は、エラーをメッセージの送信元に返送するなど、所定のエラー処理を行う(ステップS140)。
図14は、メッセージ発行時の処理フローを示す。サービス実行部532は、メッセージを設定し、送信元サービス設定部5345に通知する(ステップS205)。送信元サービス設定部5345は、受信したメッセージに対して、送信元の識別子として、メッセージの送信元のサービス実行部532が実行しているサービスの識別子を追加し、メッセージ受信部5342に通知する(ステップS210)。メッセージ受信部5342は、メッセージから読み出した送信先のサービスの識別子及び送信元のサービスの識別子をメッセージ判定部5343に通知し、メッセージ全体をメッセージ分配部5344に通知する(ステップS215)。
メッセージ判定部5343は、送信先と送信元の識別子が同一か否かを判定する(ステップS220)。メッセージ判定部5343は、送信先と送信元の識別子が同一と判定した場合(ステップS225:はい)、メッセージ分配部5344に対して、端末連携部531を経由して受信装置4にメッセージを送信するよう通知する(ステップS230)。メッセージ分配部5344は、メッセージ判定部5343の指示に従い、メッセージを端末連携部531に出力し、端末連携部531は、メッセージ分配部5344から受信したメッセージを、通信入出力部511を介して受信装置4に送信する(ステップS240)。
一方、メッセージ判定部5343は、送信先と送信元の識別子が同一ではないと判定した場合(ステップS225:いいえ)、ステップS235の処理を行う。すなわち、メッセージ判定部5343は、サービス識別管理部5341から、メッセージに記述された送信先のサービスの識別子に対応して対応表に登録されているサービス実行部532の識別子を読み出す。メッセージ判定部5343は、読み出した識別子により特定されるサービス実行部532、つまり、メッセージに記述された送信先のサービスの識別子により特定されるウェブサービスを実行しているサービス実行部532へメッセージを送信するよう、メッセージ分配部5344に通知する(ステップS235)。メッセージ分配部5344は、メッセージ判定部5343により送信先として指示されたサービス実行部532に、メッセージを送信する(ステップS240)。
図15は、受信装置4と連携端末5の間のシーケンス図である。受信装置4のサービス実行部421は、連携端末5において実行されるサービスの識別子を宛先に設定したメッセージを発行する(ステップS305)。送信元サービス設定部4235は、サービス実行部421から受信したメッセージに送信元のサービスの識別子を設定し、メッセージ受信部4232に出力する(ステップS310)。メッセージ受信部4232は、メッセージから取得した送信元のサービスの識別子及び送信先のサービスの識別子をメッセージ判定部4233に通知し(ステップS315)、メッセージ全体をメッセージ分配部4234に通知する(ステップS320)。メッセージ判定部4233は、送信元のサービスの識別子及び送信先のサービスの識別子が同一であるため、連携端末5にメッセージを送信するようメッセージ分配部4234に通知する(ステップS325)。メッセージ分配部4234は、メッセージを端末連携部412に出力し(ステップS330)、端末連携部412は、メッセージを、通信入出力部406を介して連携端末5に送信する。
連携端末5の通信入出力部511は、受信装置4から受信したメッセージを端末連携部531に出力する(ステップS335)。メッセージ受信部5342は、端末連携部531からメッセージを受信する(ステップS340)。メッセージ受信部5342は、メッセージから取得した送信元のサービスの識別子及び送信先のサービスの識別子をメッセージ判定部5343に通知し(ステップS345)、メッセージ全体をメッセージ分配部5344に通知する(ステップS350)。メッセージ判定部5343は、送信先のサービスの識別子により特定されるウェブサービスが存在することを示す照合結果をサービス識別管理部5341から受信すると、ステップS355の処理を行う。すなわち、メッセージ判定部5343は、送信先のサービスの識別子により特定されるウェブサービスを実行しているサービス実行部532へメッセージを出力するようメッセージ分配部5344に指示する(ステップS355)。メッセージ分配部5344は、メッセージ判定部5343に指示されたサービス実行部532へメッセージを出力する(ステップS360)。
図15では、受信装置4から連携端末5へのメッセージの送信例を示したが、連携端末5から受信装置4へのメッセージ送信も同様の手順で実行できる。
図16は、連携端末5のウェブアプリ間でメッセージを送信する場合のシーケンス図である。同図では、サービス実行部532−1をサービス実行部(1)、サービス実行部532−2をサービス実行部(2)と記載している。
サービス実行部532−1は、サービス実行部532−2が実行しているサービスの識別子を宛先に設定したメッセージを発行する(ステップS405)。送信元サービス設定部5345は、サービス実行部532−1から受信したメッセージに送信元のサービスの識別子を設定し、メッセージ受信部5342に出力する(ステップS410)。メッセージ受信部5342は、メッセージから取得した送信元のサービスの識別子及び送信先のサービスの識別子をメッセージ判定部5343に通知し(ステップS415)、メッセージ全体をメッセージ分配部5344に通知する(ステップS420)。メッセージ判定部5343は、送信元のサービスの識別子及び送信先のサービスの識別子が異なるため、送信先のサービスの識別子により特定されるウェブサービスを実行しているサービス実行部532−2にメッセージを送信するようメッセージ分配部5344に通知する(ステップS425)。メッセージ分配部5344は、メッセージ判定部5343に指示されたサービス実行部532−2へメッセージを出力する(ステップS430)。
図16では、連携端末5のウェブアプリ間でメッセージを送信する場合ついて示しているが、受信装置4のサービス実行部421間でメッセージを送信する場合についても同様の手順で実行できる。
上述した、図12〜図16の例では、全てのメッセージに送信元のサービスの識別子と送信先のサービスの識別子を付加して送信していたが、サービス間のチャンネルの識別子を付加する実施形態をとっても構わない。この場合、受信装置4の放送マネージドアプリのサービスと連携端末5のウェブサービスとの間、又は、連携端末5におけるウェブサービス間で、メッセージングを開始する前に、接続処理を実行してサービス間のチャンネルを確立する。以降、受信装置4及び連携端末5は、接続解除の処理が実行されるまでは、確立したチャンネルにおいて割り当てられたセッションの識別子に基づき、送信元と送信先の識別子を付加せずにメッセージを送信する。
図17は、受信装置4の放送マネージドアプリのサービスと連携端末5のウェブサービスとの間でセッションの識別子に基づきメッセージを送信する場合のメッセージの設定例を示す図である。図17(a)は、接続登録メッセージM31を、図17(b)は接続登録確認メッセージM32を、図17(c)は接続解除メッセージM33を、図17(d)は接続解除確認メッセージM34を、図17(e)はメッセージ本体が設定されたメッセージM35を示す。
接続登録メッセージM31、接続登録確認メッセージM32、接続解除メッセージM33、接続解除確認メッセージM34、メッセージM35には、type属性が含まれている。このtype属性により、メッセージが登録(publish)/登録確認(subscribe)/接続解除(unpublish)/接続解除確認(unsubscribe)/メッセージ本体(body)のいずれであるかが識別可能である。
また、接続登録メッセージM31、接続登録確認メッセージM32、接続解除メッセージM33、接続解除確認メッセージM34には、送信元のサービスの識別子(src)及び送信先のサービスの識別子(dst)が設定され、接続登録確認メッセージM32及び接続解除確認メッセージM34には、さらに、確立したチャンネルに割当てられたセッションの識別子(subscribe_ID)が記述される。メッセージ本体(message)が設定されたメッセージM35には、送信元及び送信先は設定されず、セッションの識別子(subscribe_ID)とメッセージの内容(message)が記述される。
図18及び図19は、受信装置4と連携端末5の間でセッションの識別子に基づきメッセージを送信する場合のシーケンス図である。
図18は、接続登録処理のシーケンスを示す。受信装置4のサービス実行部421は、接続登録メッセージを発行する(ステップS505)。サービス実行部421が発行した接続登録メッセージには、接続登録メッセージであることを示す「publish」が設定されたtype属性と、送信先のサービスの識別子が設定されたdst属性とが含まれる。送信元サービス設定部4235は、このメッセージに、送信元のサービスの識別子を設定したsrc属性を追加する。送信元サービス設定部4235は、src属性が追加された接続登録メッセージをメッセージ受信部4232に出力する(ステップS510)。
メッセージ受信部4232は、接続登録メッセージに設定されている送信先のサービスの識別子及び送信元のサービスの識別子をメッセージ判定部4233に通知し(ステップS515)、接続登録メッセージ全体をメッセージ分配部4234に通知する(ステップS520)。メッセージ判定部4233は、送信先と送信元のサービスの識別子が同一であるため、連携端末5にメッセージを送信するようメッセージ分配部4234に通知する(ステップS525)。メッセージ分配部4234は、接続登録メッセージを端末連携部412に出力し(ステップS530)、端末連携部412は、メッセージ分配部4234から受信した接続登録メッセージを、通信入出力部406を介して連携端末5に送信する。
連携端末5の通信入出力部511は、受信装置4からメッセージを受信し、端末連携部531に出力する(ステップS535)。メッセージ受信部5342は、端末連携部531からメッセージを受信する(ステップS540)。メッセージ受信部5342は、受信したメッセージをメッセージ判定部5343に出力する(ステップS545)。メッセージ判定部5343は、受信したメッセージのtype属性により接続登録メッセージであると判断すると、subscribe_IDを発行し、送信元及び送信先のサービスの識別子と対応付けて記憶する。なお、接続が解除される度に新規のsubscribe_IDを発番してもよく、送信元と送信先のペアに対して予め決定したsubscribe_IDを割り当てても構わない。さらに、メッセージ判定部5343は、接続登録確認メッセージを生成する。接続登録確認メッセージには、接続登録確認メッセージを示す「subscribe」が設定されたtype属性と、発行したsubscribe_IDと、接続登録メッセージに設定されていたdst属性及びsrc属性とが含まれる。メッセージ判定部5343は、生成した接続登録確認メッセージをメッセージ分配部5344に通知し、受信装置4へ送信するよう指示する(ステップS550)。
メッセージ分配部5344は、接続登録確認メッセージを端末連携部531に出力し(ステップS555)、端末連携部531は、接続登録確認メッセージを、通信入出力部511を介して受信装置4に送信する(ステップS560)。
受信装置4の通信入出力部406は、連携端末5から受信したメッセージを端末連携部412に出力する。メッセージ受信部4232は、端末連携部412からメッセージを受信する(ステップS565)。メッセージ受信部4232は、受信したメッセージのtype属性から接続登録確認メッセージであると判断する。メッセージ受信部4232は、接続登録確認メッセージから取得したsubscribe_IDと、送信元及び送信先のサービスの識別子をメッセージ判定部4233に出力する(ステップS570)。メッセージ判定部4233は、subscribe_IDと、送信元及び送信先のサービスの識別子とを対応付けて登録する。さらに、メッセージ受信部4232は、接続登録確認メッセージを、送信先のサービスの識別子により特定される放送マネージドアプリを実行しているサービス実行部421にsubscribe_IDを通知する(ステップS575)。
図19は、メッセージ送信処理のシーケンスを示す。受信装置4のサービス実行部421は、メッセージ本体を設定したメッセージを発行する(ステップS605)。メッセージには、メッセージ本体であることを示す「body」が設定されたtype属性と、送信先のサービスに応じたsubscribe_IDと、メッセージ内容とが含まれる。送信元サービス設定部4235は、サービス実行部421から受信したメッセージに送信元のサービスの識別子を設定する。なお、送信元のサービスの識別子の設定は行わなくてもよい。送信元サービス設定部4235は、送信元のサービスの識別子が設定されたメッセージを、メッセージ受信部4232に出力する(ステップS610)。
メッセージ受信部4232は、メッセージに設定されているsubscribe_IDをメッセージ判定部4233に通知し(ステップS615)、メッセージ全体をメッセージ分配部4234に通知する(ステップS620)。メッセージ判定部4233は、subscribe_IDに対応して記憶される送信先及び送信元のサービスの識別子が同一であるため、連携端末5にメッセージを送信するようメッセージ分配部4234に通知する(ステップS625)。メッセージ分配部4234は、メッセージを端末連携部412に出力し(ステップS630)、端末連携部412は、メッセージ分配部4234から受信したメッセージを、通信入出力部406を介して連携端末5に送信する。
連携端末5の通信入出力部511は、受信装置4から受信したメッセージを端末連携部531に出力する(ステップS635)。メッセージ受信部5342は、端末連携部531からメッセージを受信する(ステップS640)。メッセージ受信部5342は、受信したメッセージのtypeによりメッセージ本体であると判断すると、メッセージから読み出したsubscribe_IDをメッセージ判定部5343に出力し(ステップS645)、メッセージをメッセージ分配部5344に出力する(ステップS650)。メッセージ判定部5343は、subscribe_IDに対応した送信元及び送信先のサービスの識別子が同じであるため、送信先のサービスの識別子により特定されるサービスを実行しているサービス実行部532へメッセージを出力するようメッセージ分配部5344に指示する(ステップS655)。メッセージ分配部5344は、メッセージ判定部5343に指示されたサービス実行部532へメッセージを出力する(ステップS660)。
図18及び図19では、受信装置4から連携端末5へのメッセージの送信例を示したが、連携端末5から受信装置4へのメッセージ送信も同様の手順で実行できる。
図20は、連携端末5のウェブアプリ間でセッションの識別子に基づきメッセージを送信する場合のメッセージの記述例を示す図である。図20(a)は、接続登録メッセージM41を、図20(b)は接続登録確認メッセージM42を、図20(c)は接続解除メッセージM43を、図20(d)は接続解除確認メッセージM44を、図20(e)はメッセージ本体が設定されたメッセージM45を示す。M41〜M45のメッセージに含まれる属性はそれぞれ、図17に示すM31〜M35のメッセージと同様である。
すなわち、接続登録メッセージM41、接続登録確認メッセージM42、接続解除メッセージM43、接続解除確認メッセージM44、メッセージM45には、type属性が含まれている。また、接続登録メッセージM41、接続登録確認メッセージM42、接続解除メッセージM43、接続解除確認メッセージM44には、送信元のサービスの識別子(src)及び送信先のサービスの識別子(dst)が設定され、接続登録確認メッセージM42及び接続解除確認メッセージM44には、さらに、確立したチャンネルに割当てられたセッションの識別子(subscribe_ID)が記述される。メッセージ本体(message)が設定されたメッセージM45には、送信元及び送信先は設定されず、セッションの識別子(subscribe_ID)とメッセージの内容(message)が記述される。
図21及び図22は、連携端末5のウェブアプリ間でセッションの識別子に基づきメッセージを送信する場合のシーケンス図である。このシーケンスは、図18及び図19に示すシーケンスと基本的な手順の差異はない。ただし、受信装置4と連携端末5との間でメッセージを送信する場合、連携端末5は、メッセージ分配部5344から端末連携部531を経由して送受信を行うが、ウェブアプリ間の場合は、メッセージ分配部5344から連携端末5内のメッセージ受信部5342にメッセージを送信し、以降、同様の処理が実行される。
図21は、連携端末5のウェブアプリ間の接続登録処理のシーケンスを示す。連携端末5のサービス実行部532−1は、接続登録メッセージを発行する(ステップS705)。サービス実行部532−1が発行した接続登録メッセージには、接続登録メッセージであることを示す「publish」が設定されたtype属性と、サービス実行部532−2により実行される送信先のサービスの識別子が設定されたdst属性とが含まれる。送信元サービス設定部5345は、このメッセージに、送信元のサービスの識別子を設定したsrc属性を追加する。送信元サービス設定部5345は、src属性が追加された接続登録メッセージをメッセージ受信部5342に出力する(ステップS710)。
メッセージ受信部5342は、接続登録メッセージに設定されている送信先のサービスの識別子及び送信元のサービスの識別子をメッセージ判定部5343に通知し(ステップS715)、接続登録メッセージ全体をメッセージ分配部5344に通知する(ステップS720)。メッセージ判定部5343は、送信先と送信元のサービスの識別子が異なるため、メッセージ受信部5342にメッセージを送信するようメッセージ分配部5344に通知する(ステップS725)。メッセージ分配部5344は、接続登録メッセージをメッセージ受信部5342に出力する(ステップS730)。
メッセージ受信部5342は、受信したメッセージをメッセージ判定部5343に出力する(ステップS735)。メッセージ判定部5343は、受信したメッセージのtypeにより接続登録メッセージであると判断すると、subscribe_IDを発行し、送信元及び送信先のサービスの識別子と対応付けて記憶する。さらに、メッセージ判定部5343は、接続登録確認メッセージを生成する。メッセージ判定部5343は、生成した接続登録確認メッセージをメッセージ分配部5344に通知し、メッセージ受信部5342へ送信するよう指示する(ステップS740)。メッセージ分配部5344は、接続登録確認メッセージをメッセージ受信部5342に出力する(ステップS745)。
メッセージ受信部5342は、受信した接続登録確認メッセージから取得したsubscribe_IDと、送信元及び送信先のサービスの識別子をメッセージ判定部5343に出力する(ステップS750)。メッセージ判定部5343は、subscribe_IDと、送信元及び送信先のサービスの識別子とを対応付けて登録する。さらに、メッセージ受信部5342は、接続登録確認メッセージを、送信先のサービスの識別子により特定されるウェブアプリを実行しているサービス実行部532−1にsubscribe_IDを通知する(ステップS755)。
図22は、連携端末5のウェブアプリ間のメッセージ送信処理のシーケンスを示す。連携端末5のサービス実行部532−1は、メッセージ本体を設定したメッセージを発行する(ステップS805)。送信元サービス設定部5345は、サービス実行部532−1から受信したメッセージに送信元のサービスの識別子を設定する。なお、送信元のサービスの識別子の設定は行わなくてもよい。送信元サービス設定部5345は、送信元のサービスの識別子が設定されたメッセージを、メッセージ受信部5342に出力する(ステップS810)。
メッセージ受信部5342は、メッセージに設定されているsubscribe_IDをメッセージ判定部5343に通知し(ステップS815)、メッセージ全体をメッセージ分配部5344に通知する(ステップS820)。メッセージ判定部5343は、subscribe_IDに対応して記憶される送信先及び送信元のサービスの識別子が異なるため、送信先のサービスの識別子により特定されるウェブサービスを実行しているサービス実行部532−2にメッセージを送信するようメッセージ分配部5344に通知する(ステップS825)。メッセージ分配部5344は、メッセージ判定部5343に指示されたサービス実行部532−2へメッセージを出力する(ステップS830)。
図21及び図22では、連携端末5のウェブアプリ間でメッセージを送信する場合ついて示しているが、受信装置4において放送マネージドアプリにより実行されるサービス間でのメッセージ送信についても同様の手順で実行できる。
以上説明した実施形態によれば、放送通信連携システム1は、受信装置4と、連携端末5(端末装置)とを有する。受信装置4は、放送信号に含まれるコンテンツデータを出力する処理と、放送信号と連携した動作により複数のサービスを提供するアプリケーション(放送マネージドアプリ)を実行する処理とを実行する。連携端末5は、通信入出力部511(通信部)と、複数のサービス実行部532と、サービス実行管理部533と、メッセージ制御部534と、ログ管理部554とを備える。通信入出力部511は、受信装置4と通信する。サービス実行部532はそれぞれ、個別のサービスを提供するアプリケーションであるサービスアプリケーション(ウェブアプリ)を、受信したメッセージを用いて実行する。サービス実行管理部533は、複数のサービス実行部532を並列動作させる。メッセージ制御部534は、受信装置4において実行されているアプリケーションから発行され、通信入出力部511が受信したメッセージを宛先のサービス実行部532に出力する処理と、サービス実行部532から発行されたメッセージを受信装置4又は他のサービス実行部532に出力する処理との少なくとも一方を行う。ログ管理部554は、メッセージ制御部534における処理の対象となったメッセージに関するログデータを取得する。
また、ログ管理部554は、通信入出力部511が受信したメッセージから得られた、受信装置4において受信中の放送サービスに関する情報を取得する。放送サービスに関する情報は、例えば、イベント、視聴履歴などである。また、ログ管理部554は、センサー512(センサー部)による連携端末5の状態又は連携端末5の環境に関する情報の検出結果に関するログデータ、受信装置4との接続状態に関するログデータ、サービス実行部532によるサービスアプリケーションの実行状態に関するログデータ、サービス実行部532がサービスアプリケーションを実行することにより行ったアクセスの履歴に関するログデータを取得する。また、連携端末5は、ユーザ操作に従って受信装置4に対する制御信号を、通信入出力部511を介して出力するリモコン部553を備えており、ログ管理部554は、リモコン部553に行われたユーザ操作に関するログデータを取得する。また、ログ管理部554は、ユーザ操作により受信が指示された放送サービスに関するログデータを取得する。
ログ管理部554は、取得したログデータを、連携端末5が備えるログ記憶部5542に蓄積する処理と、ログデータを蓄積するログ記憶部を備えた外部装置であるログサーバ6に通信入出力部511を介して送信する処理との少なくとも一方を行う。ログ管理部554は、ログサーバ6に送信するログデータには、利用者の識別情報を付加する。連携端末5は、サービス実行部532から取得が指示されたログデータを、ログ記憶部5542又はログサーバ6から読み出して返送するログアクセス制御部555をさらに備えてもよい。
以上説明した実施形態によれば、ハイブリッドキャストなどの放送通信連携サービスを行う連携端末において、各種ログを取得し、管理することができる。連携端末は、受信装置との連携時に、受信装置側の放送マネージドアプリや、連携端末のリモコン機能を利用し、視聴ログとして受信中の放送のチャンネルや番組の識別子をなどの視聴履歴を取得することができる。加えて、連携端末は、受信装置と非連携時にも、受信装置との接続状態や、GPSなどのハードウェアのセンサーのデータを取得できる。よって、受信装置との連携状態の有無に関わらず、連携端末の利用者の行動履歴を取得することができる。これにより、連携端末のウェブアプリと受信装置の放送マネージドアプリとの双方が動作しているときに限らず、連携端末の利用者の行動履歴を永続的に利用可能となる。そして、収集したログから得られる利用者の状況に応じて、放送と関連したコンテンツや情報のターゲティングをすることが可能になる。
なお、上述の受信装置4及び連携端末5は、内部にコンピュータシステムを有している。そして、受信装置4及び連携端末5の一部の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、CPU及び各種メモリやOS、周辺機器等のハードウェアを含むものである。
また、「コンピュータシステム」は、WWWシステムを利用している場合であれば、ホームページ提供環境(あるいは表示環境)も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。