JP6861058B2 - 端末装置及びプログラム - Google Patents

Description

本発明は、端末装置及びプログラムに関する。

近年、放送通信連携サービスを実現するためのシステムに関する研究開発が盛んに行われている。ハイブリッドキャストは、日本の代表的な放送通信連携サービスの一つであり、その技術仕様が策定されている（例えば、非特許文献1、2参照）。この技術仕様の規格に則り、２０１３年よりハイブリッドキャストのサービスが開始されている。例えば、ＨＴＭＬ（Hypertext Markup Language）５を用いて記述された放送マネージドアプリケーションによるサービスが、複数の放送局より提供されている。「アプリケーション」とは、アプリケーションプログラムの略称であり、以下では、「アプリ」とも記載する。放送マネージドアプリは、放送送信側から送信される放送サービスの制御信号を用いて、起動、終了、強制終了などのライフサイクルが制御されるアプリである。

ハイブリッドキャストでは、テレビなどの受信装置と、スマートフォンやタブレットなどの端末装置とが連携する機能を利用することが可能である。以下では、受信装置と連携する端末装置を連携端末とも記載する。連携機能の具体的な一例として、テレビで実行される放送マネージドアプリと、端末装置にインストールされたコンパニオンアプリ上で動作するＷｅｂ（ウェブ）アプリとの間で、テキストメッセージを相互に送受信することができる。

また、テレビ及び連携端末において、複数の放送外マネージドアプリを実行する技術がある（例えば、特許文献１参照）。放送外マネージドアプリとは、ユーザの操作によって、ライフサイクルが制御されるアプリである。

一方、近年、様々な機器同士がＷｉ−ＦｉやＢｌｕｅｔｏｏｔｈ（登録商標）等の通信手段を用いて通信を行う、ＩｏＴ（Internet of Things）環境の構築に向けた取り組みが盛んに行われている。テレビをこれらＩｏＴ機器と連携動作させることにより、新たな視聴サービスを創出することが期待できる。

特開２０１５−１４６４７８号公報

"ＩＰＴＶ規定 放送通信連携システム仕様 ＩＰＴＶＦＪ ＳＴＤ−００１０ ２．１版"、一般社団法人 ＩＰＴＶフォーラム、２０１６年３月７日 "ＩＰＴＶ規定 ＨＴＭＬ５ブラウザ仕様 ＩＰＴＶＦＪ ＳＴＤ−００１１ ２．２版"、一般社団法人 ＩＰＴＶフォーラム、２０１６年３月７日

現行のハイブリッドキャストの放送マネージドアプリ規格においては、テレビと連携端末においてそれぞれ一つのアプリしか同時には実行できない上、双方のアプリが同一のサービス事業者から提供される場合にのみ連携することができる。また、特許文献1においても、放送マネージドアプリと同様、テレビのアプリと連携端末のアプリの一対で個々のサービスを提供することが記載されている。そのため既存技術においては、連携端末で実行されるアプリのサービス提供者が複数あるなど、連携端末で実行されるアプリが複数個である場合に、テレビで実行される1個のアプリと、連携端末で実行される複数個のアプリとが連携することについては考慮されていなかった。

また、ハイブリッドキャストにより、テレビ（受信装置）は連携端末とは直接接続することができるようになったが、その他のＩｏＴ機器とは、ローカルな環境で直接接続する手段が存在しないという問題がある。

本発明は、このような事情を考慮してなされたもので、放送の受信装置において実行される放送通信連携サービスのアプリと、ＩｏＴ機器において実行されるアプリとを連携させることができる端末装置及びプログラムを提供する。

［１］本発明の一態様による端末装置は、放送を受信する機能を有する受信装置で稼働する受信装置側アプリケーションと連携動作する端末側アプリケーションを実行させるアプリケーション実行部と、通信機能を有する外部機器との間で通信を行う機器通信入出力部と、連携動作する前記受信装置側アプリケーション及び前記端末側アプリケーションの少なくともいずれかからのメッセージを、前記機器通信入出力部を介して送信する機器連携部と、を具備することを特徴とする。

［２］また、本発明の一態様は、上述の端末装置において、送信先を識別するための送信先識別情報を含む前記メッセージを受け取り、前記送信先識別情報に基づいて前記メッセージを分配し、前記送信先識別情報が示す送信先が前記外部機器である場合には前記メッセージを前記外部機器に送信するために前記機器連携部に渡すメッセージ制御部、をさらに備えることを特徴とする。

［３］また、本発明の一態様は、上述の端末装置において、前記機器連携部は、前記機器通信入出力部を介して前記外部機器からのメッセージを受信し、前記メッセージ制御部は、前記機器連携部が受信した前記外部機器からの前記メッセージに含まれる送信先識別情報に基づいて、前記メッセージを前記受信装置側アプリケーションまたは前記端末側アプリケーションのいずれかの送信先に分配する、ことを特徴とする。

［４］また、本発明の一態様は、上述の端末装置において、前記機器連携部は、前記メッセージに含まれるサービス識別情報が示すサービスを前記外部機器が受け入れるか否かを表す情報を前記外部機器の属性に対応付けて保持する機器利用可能サービス表を記憶し、前記サービス識別情報に基づいて前記メッセージを前記外部機器に送信するか否かを判断する、ことを特徴とする。

［５］また、本発明の一態様は、上述の端末装置において、前記機器通信入出力部は、前記外部機器との間で用いられる通信プロトコルの種類毎に存在し、前記機器連携部は、使用する通信プロトコルに応じた前記機器通信入出力部を介して前記メッセージを前記外部機器に送信する、ことを特徴とする。

［６］また、本発明の一態様は、コンピュータを、上述した端末装置のいずれかとして機能させるためのプログラムである。

本発明によれば、放送の受信装置において実行される放送通信連携サービスのアプリと、端末装置と通信する外部機器とを連携させることが可能となる。

本発明の一実施形態による放送通信連携システムの全体構成図である。 同実施形態による受信装置、連携端末、及びＩｏＴ機器のスタック図である。 同実施形態による受信装置の内部の機能構成を示す機能ブロック図である。 同実施形態によるアプリ実行部の詳細な機能構成を示す機能ブロック図である。 同実施形態による連携端末の機能構成を示す機能ブロック図である。 同実施形態による連携端末が備えるメッセージ制御部の詳細な機能構成を示す機能ブロック図である。 同実施形態によるＩｏＴ機器の機能構成を示す機能ブロック図である。 同実施形態による放送マネージドアプリの記述例を示す図である。 同実施形態による装置間でやりとりされるメッセージの設定例を示す図である。 同実施形態による連携端末がメッセージを受信したときの処理フローを示すフローチャート（１／２）である。 同実施形態による連携端末がメッセージを受信したときの処理フローを示すフローチャート（２／２）である。 同実施形態による連携端末がメッセージを発行するときの処理フローを示すフローチャートである。 同実施形態による受信装置と連携端末の間でメッセージを送信する場合のシーケンス図である。 同実施形態による連携端末内のウェブサービス間でメッセージを送信する場合のシーケンス図である。 同実施形態によるメッセージの設定例を示す図である。 同実施形態による受信装置と連携端末の間でセッションの識別子に基づきメッセージを送信する場合のシーケンス図である。 同実施形態による受信装置と連携端末の間でセッションの識別子に基づきメッセージを送信する場合のシーケンス図である。 同実施形態によるメッセージの設定例を示す図である。 同実施形態による連携端末内のウェブアプリ間でセッションの識別子に基づきメッセージを送信する場合のシーケンス図である。 同実施形態による連携端末内のウェブアプリ間でセッションの識別子に基づきメッセージを送信する場合のシーケンス図である。 同実施形態による連携端末が備える機器連携部の詳細な機能構成を示す機能ブロック図である。 同実施形態による連携端末内の機器管理部がメッセージ制御部から受信するメッセージの例を示す図である。 同実施形態による連携端末内の機器連携部の処理シーケンスを示すフローチャートである。 同実施形態の応用例であって、受信装置とＩｏＴ機器（ピアノ玩具）とが連係動作する手順を示すシーケンス図（１／２）である。 同実施形態の応用例であって、受信装置とＩｏＴ機器（ピアノ玩具）とが連係動作する手順を示すシーケンス図（２／２）である。

以下、図面を参照しながら本発明の実施形態を詳細に説明する。以下では、「アプリケーションプログラム」を、「アプリケーション」又は「アプリ」とも記載する。また、以下の説明では、アプリに記述された命令で指定される処理を実行することを、単に「アプリを実行」又は「アプリの実行」と呼ぶことがある。

図1は、本実施形態の一実施形態による放送通信連携システム１の全体構成図である。
放送通信連携システム１は、放送送出装置２と、サービスサーバ３と、受信装置４と、連携端末５と、ＩｏＴ機器１０とを有する。なお、「ＩｏＴ」は、「Internet of Things（モノのインターネット）」の略である。放送送出装置２及びサービスサーバ３は送信側（例えば、放送事業者側）の装置であり、受信装置４、連携端末５、及びＩｏＴ機器１０は、受信側（例えば、放送の視聴者側）の装置である。

放送送出装置２は、放送信号を送出する。サービスサーバ３は、アプリ本体やアプリで利用するコンテンツデータを、インターネットを介して受信側の装置へ配信する。アプリ本体とは、アプリケーションのプログラムである。受信装置４は、例えば、ハイブリッドキャスト対応テレビである。連携端末５は、例えば、スマートフォンやタブレット端末などの端末装置である。ＩｏＴ機器１０は、連携端末５と通信し得るあらゆる種類の機器である。なお、ＩｏＴ機器と連携端末５との間の通信は、近距離において行われる場合も、遠距離において行われる場合もある。受信装置４及び連携端末５は、インターネットを介してサービスサーバ３と相互に通信できる。また、受信装置４と連携端末５は、無線ＬＡＮ（Local Area Network）等のローカルネットワークを介して接続する。また、連携端末５とＩｏＴ機器１０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信手段を介して接続する。

ＩｏＴ機器１０は、連携端末５の外部に存在する「外部機器」の一種である。ＩｏＴ機器１０は、無線等によるデータ通信の機能を有している。ＩｏＴ機器１０の具体例を次に列挙する。ＩｏＴ機器１０は、例えば、電気製品（情報機器、照明機器、その他家電製品等）や、計測のための機器や、情報収集のための機器や、発電のための機器や、エネルギー（電力、ガス等）制御のための機器や、空調機器等であり得る。また、ＩｏＴ機器１０は、認証のための機能（生体認証を含む）を有する機器であり得る。また、ＩｏＴ機器１０は、例えば映像コンテンツに所謂「４Ｄ」演出効果を与えるための機器であって、光の効果を与える機器や、音の効果を与える機器や、物質（液状、霧状、気体等）を噴出するための機器や、物や人を傾けたり加速度を与えたりするための機器等であり得る。また、ＩｏＴ機器１０は、玩具や、ゲーム機や、ゲームのコントローラーや、テレビや映像レコーダーやオーディオ装置のリモコンや、楽器（電子楽器を含む）や、音声合成装置や、集音のための機器や、音声認識装置等であり得る。また、ＩｏＴ機器１０は、建物内や街角や店舗や公共施設等に設置され、情報機器等と通信し合う装置等であり得る。また、ＩｏＴ機器１０は、ここに例示したものに限られず、あらゆる物であり得る。

放送通信連携サービスの形態は複数存在するが、本実施形態の放送通信連携システム１では、ハイブリッドキャスト技術仕様（非特許文献１、２）に基づき、受信装置４において、デジタル放送サービスとインターネットサービスとが連携動作することを想定する。
受信装置４が、放送またはインターネットにより配信されるアプリを実行することで、インターネット上のコンテンツを取得できるようになり、ユーザが放送通信連携サービスを利用できるようになる。さらに、ハイブリッドキャスト技術仕様に則り、受信装置４と連携端末５にインストールした端末側連携アプリとが連携動作する。

なお、本実施形態においては、受信装置４において動作するアプリは、放送事業者が配信する放送マネージドアプリとする。放送マネージドアプリは、放送送出装置２から送信される放送サービスの制御信号に基づいて、起動、終了、強制終了などのライフサイクルが制御される。

連携端末５に実装される端末側連携アプリは、通信により接続される他の装置である受信装置４と連携して動作するコンパニオンアプリである。端末側連携アプリは、受信装置４により実行される放送マネージドアプリと連携動作する1以上のサービスアプリを実行する。また、この端末側連携アプリは、ＩｏＴ機器１０で実行されるアプリと連携動作する。

放送マネージドアプリとサービスアプリとは連携動作することにより、ユーザへ提供するサービスを実行する。サービスとは、ユーザが連携端末５に行った操作に従って動作した結果の画像、映像、音声を、連携端末５に、又は、受信装置４及び連携端末５に出力することである。サービスの実行には、受信装置４が有する受信機機能から取得した情報などが利用される。受信機機能は、放送信号を受信し、ユーザにより選択されたチャンネルの番組映像や音声などのコンテンツデータを放送信号から取得し、デコードして出力する一連の機能である。ユーザに提供するサービスは任意であるが、一例として、ＳＮＳ（ソーシャルネットワークサービス）、天気予報やニュースなどの情報の提供、外国語字幕の提供、テレビ映像とは異なる角度からの映像の提示などがある。

また、本実施形態の放送通信連携システム１では、受信装置４の動作及び連携端末５の動作（ユーザが連携端末５に行った操作に従った動作を含む）の結果のデータを、ＩｏＴ機器１０に渡す。そして、ＩｏＴ機器１０は、渡されたデータに従った動作をする。また、ＩｏＴ機器１０は、ＩｏＴ機器１０が保持するデータ（ＩｏＴ機器１０が収集したデータを含む）を、連携端末５や受信装置４に渡す。連携端末５や受信装置４は、ＩｏＴ機器１０から渡されたデータに従った動作をすることが可能である。

本実施形態では、端末側連携アプリまたはＩｏＴ機器側連携アプリにおいて実行されるサービスアプリがウェブアプリである場合を例に説明する。ウェブアプリとは、ウェブブラウザにより実行されるアプリである。ウェブアプリは、任意の手段により連携端末５に実装される。例えば、ウェブアプリは、放送マネージドアプリから取得が指示されたアプリでもよく、ユーザ操作により取得したアプリでもよく、連携端末５に予め実装されたアプリでもよい。放送マネージドアプリ及びウェブアプリのプログラムは、例えば、ＨＴＭＬ（Hypertext Markup Language）により記述される。

図２は、受信装置４、連携端末５、及びＩｏＴ機器１０のスタック図である。受信装置４は、ハードウェア、ＯＳ（Operation System）、レジデント及びアプリ実行部の４層から構成される。アプリ実行部は、例えばＨＴＭＬ５ブラウザであり、放送マネージドアプリを実行する。ＯＳ上で実行されるレジデントには、メモリに常駐するソフトウェアによる放送の受信機機能が搭載される。アプリ実行部で実行される放送マネージドアプリは、非特許文献1により規定される拡張ＡＰＩ（Application Program Interface）を通してレジデントの受信機機能にアクセスすることができる。ハードウェアは、ＣＰＵ（central processing unit）、各種メモリ、チューナー、デコーダ、通信装置、表示装置、入力装置などを含む。

連携端末５は、ハードウェア、ＯＳ及びネイティブアプリ実行部の３層から構成される。ネイティブアプリ実行部は、ｉＯＳ（登録商標）やＡｎｄｒｏｉｄ（登録商標）など端末のＯＳが提供するアプリを実行する。ネイティブアプリ実行部では、複数のネイティブアプリが動作可能である。ネイティブアプリは、特定のＯＳやプラットフォームで実行可能なプログラムである。本実施形態における端末側連携アプリはネイティブアプリであり、ネイティブアプリ実行部において動作する。なお、端末側連携アプリは、ネイティブアプリでなくてもよい。例えば、端末側連携アプリは、ネイティブアプリから、ネイティブアプリではないブラウザを呼び出し、ブラウザによりウェブアプリを実行させてもよい。
ハードウェアは、ＣＰＵ、各種メモリ、通信装置、表示装置、入力装置などを含む。

ＩｏＴ機器１０の構成としては、様々な形態が考えられるが、ここで図示する構成はＷｏＴ（Web of Things）として検討が進んでいる典型的な構成である３層構成である。即ち、ＩｏＴ機器１０は、ハードウェア、ＯＳ、アプリ実行部の3層から構成される機器である。アプリ実行部はＨＴＭＬ５ブラウザであり、ＩｏＴ機器向けに記述されたウェブアプリを実行する。ＩｏＴ機器１０のハードウェアとしては、ＣＰＵ、各種メモリ、通信装置、表示装置、入力装置などを含む。なお、ここで図示する構成は一例であり、異なる構成であってもよい。例えば、ＨＴＭＬブラウザはウェブアプリのコードをＯＳが実行可能な形式に解釈する機能を有するが、このブラウザの機能を連携端末５が代わりに提供してもよい。この場合、連携端末５は、ウェブアプリのコードを解釈し、そのコードをＩｏＴ機器１０のＯＳで実行可能な形式のデータ（コード）に変換し、変換後のコードをＩｏＴ機器１０に送信する。ＩｏＴ機器はこの連携端末５側から送られたコードをＯＳ層で解釈し、実行する。また、ここに例示した構成に限らず、他の構成によって装置間で機能を適切に配置してもよい。

ハイブリッドキャストにおける端末連携機能は、受信装置４のアプリ実行部で動作する放送マネージドアプリと、連携端末５のネイティブアプリ実行部が実行する端末側連携アプリの内部で動作するウェブアプリの間で実現される。放送マネージドアプリとウェブアプリとの間では、非特許文献1で規定される拡張ＡＰＩを用いてテキストメッセージを送信する。テキストメッセージには、任意のメッセージ内容を記述することができる。例えば、メッセージ内容は、アプリに対する各種の実行命令や、アプリが動作する際に用いられる付加的な情報などでもよい。

また、連携端末５とＩｏＴ機器１０との連携機能は、連携端末５で動作するコンパニオンアプリの内部で動作するウェブアプリと、ＩｏＴ機器１０のアプリ実行部で動作するウェブアプリとの間で実現される。連携端末５のコンパニオンアプリからＩｏＴ機器１０に、メッセージを送信することができる。また、携帯端末５は、ＩｏＴ機器１０からのメッセージを受信することができる。なお、連携端末５とＩｏＴ機器１０との間で送受信されるメッセージは、テキスト形式でもよく、バイナリ形式でも良い。

図３は、受信装置４の内部構成を示すブロック図であり、本実施形態と関係する機能ブロックのみを抽出して示してある。同図に示す受信装置４は、放送受信部４０１、分離部４０２、映像復号部４０３、音声復号部４０４、データ放送実行部４０５、通信入出力部４０６、リモコン入力制御部４０７、電源制御部４０８、アプリ実行部４０９、アプリ制御部４１０、放送通信連携部４１１、端末連携部４１２、映像合成部４１３、映像表示部４１４、音声合成部４１５及び音声出力部４１６を備えて構成される。
なお、連携端末５と連携動作するアプリケーションであって、受信装置４側で実行されるアプリケーションを「受信装置側アプリケーション」と呼ぶ。

放送受信部４０１は、チューナーであり、放送送出装置２から送出された放送信号を受信し、復調する。分離部４０２は、放送受信部４０１が受信し、復調した放送信号を、映像データ、音声データなどのコンテンツデータや、コンテンツデータ以外のデータに分離する。コンテンツ以外のデータには、例えば、データ放送や、受信チャンネル、番組情報が記述されたＳＩ（Service Information）や、イベントメッセージなどが含まれる。映像復号部４０３は、映像データを復号する。音声復号部４０４は、音声データを復号する。データ放送実行部４０５は、ＢＭＬ（Broadcast Markup Language）ブラウザであり、データ放送を実行する。

通信入出力部４０６は、通信ネットワークに接続するためのインターフェースである。
通信入出力部４０６は、インターネットなどを介してアプリマーケット、アカウント管理サーバ、アプリ配信サーバなどのサービスサーバ３と接続する。また、通信入出力部４０６は、無線ＬＡＮなどのローカルネットワークを介して連携端末５と接続する。リモコン入力制御部４０７は、リモコン（リモートコントローラ）からユーザがリモコンに行った操作を示すデータを受信する。電源制御部４０８は、受信装置４の電源の制御を行う。

アプリ実行部４０９は、放送マネージドアプリを実行するウェブ（Ｗｅｂ）ブラウザである。放送マネージドアプリは、１以上のサービスの機能を提供する。アプリ制御部４１０は、放送信号から分離されたデータに含まれる情報に基づいて、放送マネージドアプリの起動や終了などの制御を行う。例えば、アプリ制御部４１０は、現在選択されている放送事業者（チャンネル）の放送マネージドアプリを、放送信号から分離されたＡＩＴに設定されている情報などに基づいて制御する。アプリ制御部４１０は、起動した放送マネージドアプリの識別情報を端末連携部４１２に通知する。

放送通信連携部４１１は、放送マネージドアプリにおいて放送又は通信により取得したコンテンツを連携動作させるために、アプリ実行部４０９に対して拡張ＡＰＩで規定される機能を提供する。具体的には、放送通信連携部４１１は、受信中の放送信号に含まれるＳＩやイベントメッセージなどの情報や受信装置４が備える機能などへのアクセス手段を提供する。端末連携部４１２は、連携端末５とのペアリング処理と、受信装置４の放送マネージドアプリと連携端末５のウェブアプリ間の通信を仲介する処理とを行う。端末連携部４１２は、後述する図５に示す連携端末５の端末連携部５３１とペアで動作する。端末連携部４１２は、起動された放送マネージドアプリの識別情報を連携端末５に通知する。

映像合成部４１３は、映像復号部４０３が復号した放送番組の映像データと、データ放送実行部４０５やアプリ実行部４０９の処理結果に基づき出力された映像データとを合成し、映像表示部４１４に出力する。映像表示部４１４は、一般的なディスプレイであり、映像合成部４１３が合成した映像データの映像を表示する。

音声合成部４１５は、音声復号部４０４が復号した放送番組の音声データと、データ放送実行部４０５やアプリ実行部４０９の処理結果に基づき出力された音声データとを合成し、音声出力部４１６に出力する。音声出力部４１６は、一般的なスピーカーであり、音声合成部４１５が合成した音声データを音声により出力する。

図４は、アプリ実行部４０９の詳細な構成を示す機能ブロック図である。アプリ実行部４０９は、サービス実行部４２１、サービス実行管理部４２２及びメッセージ制御部４２３を有する。なお、アプリ実行部４０９は複数のサービス実行部４２１を備え得るが、同時に動作する放送マネージドアプリは一つのみとする。同図では、アプリ実行部４０９が備える複数のサービス実行部４２１をそれぞれ、サービス実行部４２１−１、４２１−２、４２１−３、…と記載している。

サービス実行部４２１は、アプリ制御部４１０による制御に基づき、放送マネージドアプリに含まれるサービス機能を実行する。サービス実行管理部４２２は、各サービス実行部４２１の起動及び終了の制御や状態管理を行い、複数のサービス実行部４２１を並列に実行させる。

メッセージ制御部４２３は、サービス実行部４２１が実行する放送マネージドアプリのサービス機能と連携端末５が実行するウェブアプリとの間のメッセージを適切に送受信するための制御を行う。メッセージ制御部４２３は、サービス識別管理部４２３１、メッセージ受信部４２３２、メッセージ判定部４２３３、メッセージ分配部４２３４及び送信元サービス設定部４２３５を有する。

サービス識別管理部４２３１は、サービス実行部４２１の識別子と、そのサービス実行部４２１により実行されるサービスの識別子との対応表を例えばリスト形式で管理する。
サービスの識別子は、予め決められる。なお、各放送マネージドアプリは、プレフィックスを付加することなどにより、送信先のアドレスとして、サービス毎に予め決められた識別子を、メッセージの一部に付加して送受信を行う。

メッセージ受信部４２３２は、連携端末５からのメッセージ、及び、サービス実行部４２１からのメッセージを受信する。メッセージ受信部４２３２は、受信したメッセージを、メッセージ判定部４２３３及びメッセージ分配部４２３４に送信する。なお、メッセージ受信部４２３２は、メッセージ判定部４２３３に宛先の判定に必要な情報のみを送信してもよい。

メッセージ判定部４２３３は、メッセージ受信部４２３２から受信したメッセージに付加されたサービスの識別子と、サービス識別管理部４２３１に記憶される対応表とを照合してメッセージの送信先を決定し、メッセージ分配部４２３４に通知する。メッセージ判定部４２３３は、メッセージに付加された送信元のサービスの識別子と送信先のサービスの識別子とが同一の場合は連携端末５を送信先とし、異なる場合はサービス実行部４２１を送信先とする。また、メッセージ判定部４２３３は、実施形態によっては、サービス間の通信チャンネルを確立するための識別子の発行や、その識別子に基づいたメッセージの送信先の決定を行う。

メッセージ分配部４２３４は、メッセージ受信部４２３２から受信したメッセージを、メッセージ判定部４２３３が決定した送信先に送信する。送信元サービス設定部４２３５は、サービス実行部４２１が連携端末５または他のサービス実行部４２１に対して送信するメッセージに、そのサービス実行部４２１において実行中の放送マネージドアプリのサービスの識別子を付加する。

図５は、連携端末５の構成を示す機能ブロック図であり、本実施形態と関係する機能ブロックのみを抽出して示してある。同図においては、端末側連携アプリを中心とした機能構成を示す。連携端末５は、ハードウェア部５１、ＯＳ部５２、連携アプリ実行制御部５３及び他アプリ実行制御部５４を有する。
なお、受信装置４と連携動作するアプリケーションであって、連携端末５側で実行されるアプリケーションを「端末側アプリケーション」と呼ぶ。

ハードウェア部５１は、ＣＰＵ、各種メモリ、通信装置、ディスプレイ（表示装置）、ユーザ操作を入力するための入力デバイス（入力装置）などの各種ハードウェアからなる。ディスプレイがタッチパネルである場合、入力デバイスは、タッチパネルに配されたタッチセンサーである。ハードウェア部５１は、通信装置により実現される通信入出力部５１１及び機器通信入出力部５１２を有する。

通信入出力部５１１は、通信ネットワークに接続するためのインターフェースである。
通信入出力部５１１は、インターネットなどを介してサービスサーバ３と接続する。また、通信入出力部５１１は、無線ＬＡＮなどのローカルネットワークを介して受信装置４と接続する。機器通信入出力部５１２は、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信手段に接続するためのインターフェースである。機器通信入出力部５１２は、Ｗｉ−Ｆｉ、ＢＬＥ（Bluetooth Low Energy）など、通信プロトコルごとに設けられる。機器通信入出力部５１２は、Ｂｌｕｅｔｏｏｔｈ（登録商標）等を介してＩｏＴ機器１０と接続する。なお、ＩｏＴ機器との接続に使用するプロトコルによっては、機器通信入出力部５１２は、通信入出力部５１１と共用される場合がある。つまり、機器通信入出力部５１２は、通信機能を有するＩｏＴ機器１０との間で通信を行う。ＯＳ部５２は、ＯＳにより実現され、端末全体を制御し、連携アプリ実行制御部５３及び他アプリ実行制御部５４に、ハードウェア部５１へのインターフェースを提供する。

連携アプリ実行制御部５３は、ＣＰＵがメモリに記憶された端末側連携アプリを読み出して実行することにより実現される。連携アプリ実行制御部５３は、端末連携部５３１、サービス実行部５３２、サービス実行管理部５３３、メッセージ制御部５３４及び機器連携部５３５を有する。複数のサービス実行部５３２をそれぞれ、サービス実行部５３２−１、５３２−２、５３２−３、…と記載する。

端末連携部５３１は、受信装置４とのペアリング処理と、受信装置４の放送マネージドアプリと連携端末５のウェブアプリ間の通信を仲介する処理とを行う。端末連携部５３１は、受信装置４の端末連携部４１２とペアで動作する。

サービス実行部（アプリケーション実行部）５３２は、個々のサービスを提供するためのウェブアプリを実行する。サービス実行部５３２の実装方法としては、Ａｎｄｒｏｉｄ（登録商標）搭載端末におけるＷｅｂＶｉｅｗ、ｉＯＳ搭載端末におけるＵＩＷｅｂＶｉｅｗなどが挙げられる。サービス実行部５３２は複数存在することを前提としており、各サービス実行部５３２には一意の識別子が割り当てられ、サービスの識別子としても用いられる。各サービス実行部５３２は、以下のようなウェブアプリを実行する。

（１）現在実際にサービスが提供されている受信装置４の放送マネージドアプリと連携したウェブアプリ。なお、このウェブアプリを実行するのは一つのサービス実行部５３２である。
（２）複数の放送局が配信する放送マネージドアプリと連携して共通に利用することができるウェブアプリ。
（３）受信装置４と連携しないウェブアプリ。
上記のウェブアプリのうちの（１）と（２）に関して、サービス実行部５３２は、放送を受信する機能を有する受信装置４で稼働する受信装置側アプリケーションと連携動作する端末側アプリケーションを実行させるものである。

サービス実行管理部５３３は、各サービス実行部５３２の起動及び終了の制御や状態管理を行い、複数のサービス実行部５３２を並列に実行させる。サービス実行管理部５３３は、受信装置４からの指示又はユーザ操作に基づいて、サービス実行部５３２、または、サービス実行部５３２上で実行されるウェブアプリの起動及び終了の制御や、フォアグラウンドでの動作又はバックグラウンドでの動作など状態の変更を行う。

ハイブリッドキャストでは、受信装置４と連携端末５との間でテキストメッセージを送受信するためのＡＰＩが規定されている。メッセージ制御部５３４は、受信装置４が実行する放送マネージドアプリと連携端末５の各サービス実行部５３２が実行するウェブアプリとの間、および、サービス実行部５３２の間のメッセージを適切に送受信するための制御を行う。また、メッセージ制御部５３４は、連携端末５の各サービス実行部５３２が実行するウェブアプリとＩｏＴ機器１０のアプリ実行部が実行するアプリとの間のメッセージを適切に送受信するための制御を行う。具体的には、メッセージ制御部５３４は、送信先を識別するための送信先識別情報を含むメッセージを受け取り、送信先識別情報に基づいてメッセージを分配し、送信先識別情報が示す送信先がＩｏＴ機器１０（外部機器）である場合にはメッセージをＩｏＴ機器１０に送信するために機器連携部５３５に渡す。また、メッセージ制御部５３４は、機器連携部５３５が受信したＩｏＴ機器１０からのメッセージに含まれる送信先識別情報に基づいて、メッセージを受信装置側アプリケーションまたは端末側アプリケーションのいずれかの送信先に分配する。メッセージ制御部５３４の詳細を、後で図６を用いて説明する。

機器連携部５３５は、ＩｏＴ機器１０とのペアリング処理と、ＩｏＴ機器１０と連携端末５とのアプリ間の通信を仲介する。また、機器連携部５３５は、連携端末５の各サービス実行部５３２−１、５３２−２、５３２−３、・・・のウェブアプリとＩｏＴ機器１０のアプリ実行部との間のメッセージを適切に送受信するための制御を行う。機器連携部５３５は、連携動作する受信装置側アプリケーション及び端末側アプリケーションの少なくともいずれかからのメッセージを、機器通信入出力部５１２を介して送信する。また、機器連携部５３５は、機器通信入出力部５１２を介してＩｏＴ機器１０からのメッセージを受信する。なお、機器連携部５３５については、後で図２１を用いて説明する。

図６は、メッセージ制御部５３４の詳細な構成を示す機能ブロック図である。メッセージ制御部５３４は、サービス識別管理部５３４１、メッセージ受信部５３４２、メッセージ判定部５３４３、メッセージ分配部５３４４及び送信元サービス設定部５３４５を有する。

サービス識別管理部５３４１は、サービス実行部５３２の識別子と、そのサービス実行部５３２が実行するウェブアプリにより提供されるサービスであるウェブサービスの識別子との対応表を例えばリスト形式で管理する。ウェブサービスの識別子は、予め決められる。なお、各ウェブサービスは、プレフィックスを付加することなどにより、送信先のアドレスとして、ウェブサービス毎に予め決められた識別子を、メッセージの一部に付加して送受信を行う。

メッセージ受信部５３４２は、受信装置４からのメッセージ、ＩｏＴ機器１０からのメッセージ、及び、各サービス実行部５３２からのメッセージを受信する。メッセージ受信部５３４２は、受信したメッセージを、メッセージ判定部５３４３及びメッセージ分配部５３４４に送信する。なお、メッセージ受信部５３４２は、メッセージ判定部５３４３に宛先の判定に必要な情報のみを送信してもよい。

メッセージ判定部５３４３は、メッセージ受信部５３４２から受信したメッセージに付加されたサービスの識別子と、サービス識別管理部５３４１に記憶される対応表とを照合してメッセージの送信先を決定し、メッセージ分配部５３４４に通知する。メッセージ判定部５３４３は、メッセージに付加された送信元のサービスの識別子と送信先のサービスの識別子とが同一の場合は、同じくメッセージに付加された送信先識別子を参照し、受信装置４またはその他のＩｏＴ機器１０を送信先とする。また、メッセージに付加された送信元のサービスの識別子と送信先のサービスの識別子とが異なる場合は、各サービス実行部５３２を送信先とする。また、メッセージ判定部５３４３は、実施形態によっては、サービス間の通信チャンネルを確立するための識別子の発行や、その識別子に基づいたメッセージの送信先の決定を行う。

メッセージ分配部５３４４は、メッセージ受信部５３４２から受信したメッセージを、メッセージ判定部５３４３が決定した送信先に送信する。送信元サービス設定部５３４５は、サービス実行部５３２が受信装置４または他のサービス実行部５３２に対して送信するメッセージに、送信元のサービス実行部５３２の識別子を付加する。

図７は、ＩｏＴ機器の機能構成を示すブロック図である。図示するように、ＩｏＴ機器１０の少なくとも一部は、コンピュータを用いて実現され、ソフトウェア、ＯＳ、ハードウェアの３層で構成される。ＩｏＴ機器１０は、機能として、アプリ実行部１０１１及び通信入出力部１０３１を含む。

アプリ実行部１０１１は、アプリを実行する機能を有する。アプリ実行部１０１１は、例えば、ウェブブラウザで実現される。ただし、ウェブブラウザ以外の機能としてアプリを実行するようにしてもよい。アプリは、例えば、ＩｏＴ機器１０に組み込まれている。ただし、ＩｏＴ機器１０の種別や機能によっては、ＩｏＴ機器１０が、Ｗｉ−ＦｉやＢｌｕｅｔｏｏｔｈ（登録商標）等の通信手段を用いてインターネットや外部機器に接続し、更新版のアプリを取得して更新するようにしてもよい。また、ここでは、１つのＩｏＴ機器１０は1つのサービスのみを実行可能であると想定して説明するが、１つのＩｏＴ機器１０が複数のサービスを実行してもよい。アプリ実行部１０１１は、ソフトウェアで実現される。ただし、その機能の少なくとも一部をハードウェアで実現するようにしてもよい。

通信入出力部１０３１は、通信ネットワークとのインターフェースである。通信入出力部１０３１は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ−Ｆｉ等により、連携端末５と通信する。通信入出力部１０３１は、ハードウェアで実現される。ただし、その機能の少なくとも一部をソフトウェアで実現するようにしてもよい。ハードウェアは、ＣＰＵ、メモリ、通信装置等を含む。

上述したように、受信装置４で実行される放送マネージドアプリは一つである。そこで、複数のサービスを一つの放送マネージドアプリで実行するために、一つのＨＴＭＬ文書（アプリケーションプログラム）内に複数のサービスそれぞれを実行させるためのプログラムを記述する。例えば、放送局Ａが提供する現行の放送マネージドアプリでのサービスＡに加え、放送局Ａと放送局Ｂとが共通に提供するサービスＸを同時に運用することを想定する。このとき、放送局Ａが提供するサービスＡのＨＴＭＬ文書内と、放送局Ｂが提供する放送マネージドアプリのサービスＢのＨＴＭＬ文書内に、サービスＸの機能をJavaScript（登録商標）等で記述する。さらに、複数のサービスで個々にデバイス間でメッセージを送受信するため、連携端末５のサービス実行管理部５３３と同等の機能を有するサービス実行管理部４２２の機能、連携端末５のメッセージ制御部５３４と同等の機能を有するメッセージ制御部４２３の機能を、サービスＡとサービスＢの両方のサービスのＨＴＭＬ文書内にサービスＸの機能と同様に記述する。サービス実行管理部４２２の機能には、サービス実行部４２１の起動や終了などの制御、サービスごとに画面に表示するか否かの制御が含まれる。

図８は、放送マネージドアプリの記述例を示す図である。同図は、放送局Ａの放送マネージドアプリを、ＨＴＭＬ文書として記述した例である。同図に示すように、divでサービスＡ、サービスＸのそれぞれ表示する要素をグループ化し、idを指定する（serviceA、common_serviceX）。サービス実行部４２１で実行される各サービスの機能は、JavaScript（登録商標）で記述し、head部分にインクルードする（serviceA.js、common_serviceX）。さらに、サービス実行管理部４２２によるサービス実行部４２１の起動や終了などの制御機能（common_appcontrol.js）、メッセージ制御部４２３の機能（common_messaging.js）、及び、サービス実行管理部４２２によるサービス毎の表示の制御機能（common_viewcontrol.js）も同様にインクルードする。このようにＨＴＭＬ文書として記述された放送マネージドアプリをアプリ実行部４０９が実行することにより、アプリ実行部４０９は、サービス実行部４２１、サービス実行管理部４２２及びメッセージ制御部４２３として動作する。これにより、受信装置４上の放送マネージドアプリと、連携端末５上のコンパニオンアプリ双方に同等の機能が導入されるため、複数のサービスを一対の受信装置４と連携端末５上で利用できるようになる。
なお、サービス実行管理部４２２、メッセージ制御部４２３及びサービス実行部４２１として動作する機能部が、予め受信装置４のアプリ実行部４０９に実装されていてもよい。

連携端末５のサービス実行管理部５３３は、受信装置４からの指示、又は、連携端末５にユーザが入力した指示に従って、サービス実行部５３２によるウェブアプリの起動又は停止を行う。具体的には、受信装置４のアプリ実行部４０９が実行している放送マネージドアプリからサービス起動指示が出力されると、端末連携部４１２は連携端末５を送信先とし、通信入出力部４０６を介してサービス起動指示を送信する。サービス起動指示には、起動対象のウェブアプリを特定する情報が含まれる。連携端末５の端末連携部５３１は、通信入出力部５１１を介して受信したサービス起動指示をサービス実行管理部５３３へ出力する。サービス実行管理部５３３は、受信したサービス起動指示により起動が指示されたウェブアプリを起動する。あるいは、連携端末５の入力デバイスによりユーザが起動対象のウェブアプリの情報を入力すると、サービス実行管理部５３３は、その起動対象のウェブアプリを起動する。これにより、連携アプリ実行制御部５３において、サービス実行部５３２が動作する。

図９は、放送通信連携システム１内の装置間でやりとりされるメッセージの例を示す概略図である。図９（ａ）は、受信装置４において放送マネージドアプリのサービスＰの機能を実行しているサービス実行部４２１から、連携端末５の端末側連携アプリにおいてサービスＰのウェブアプリを実行しているサービス実行部５３２へ送信されるメッセージＭ１１を示す。図９（ｂ）は、連携端末５の端末側連携アプリにおいてサービスＰのウェブアプリを実行しているサービス実行部５３２から、同じく端末側連携アプリにおいてサービスＱのウェブアプリを実行しているサービス実行部５３２に送信されるメッセージＭ２１を示す。メッセージＭ１１は、放送マネージドアプリのサービスＰの機能を実行しているサービス実行部４２１により記述されるメッセージであり、メッセージＭ１２は、サービスＰのウェブアプリを実行しているサービス実行部５３２において記述されるメッセージである。メッセージＭ１１、Ｍ２１には、送信先のサービスの識別子（それぞれ、dst:ServiceP、dst:ServiceQ）、メッセージ本体（message)が記述される。

図９（ｃ）は、連携端末５の端末側連携アプリにおいてサービスＰのウェブアプリを実行しているサービス実行部５３２から、ＩｏＴ機器１０においてサービスＰのウェブアプリを実行しているアプリ実行部１０１１に送信されるメッセージＭ３１を示す。メッセージＭ３１には、送信先のサービスの識別子（dst:ServiceP）、装置の種別（dev:IoT）、及びメッセージ本体（message)が記述される。また、メッセージＭ３１において、送信先のＩｏＴ機器１０を識別する情報は、メッセージ本体の中に記述されている。

図９（ｄ）に示すメッセージＭ１２、図９（ｅ）に示すメッセージＭ２２、及び図９（ｆ）に示すメッセージＭ３２は、連携端末５のメッセージ受信部５３４２が受信するメッセージである。メッセージＭ１２は、メッセージＭ１１に送信元のサービスＰの識別子(src:ServiceP)が付加されたものである。メッセージＭ２２は、メッセージＭ２１に送信元のサービスＰの識別子(src:ServiceP)が付加されたものである。メッセージＭ３２は、メッセージＭ３１に送信元のサービスＰの識別子(src:ServiceP)が付加されたものである。

具体的には、受信装置４の送信元サービス設定部４２３５が、メッセージＭ１１に送信元のサービスＰの識別子を追加し、メッセージＭ１２となる。メッセージＭ１２の場合は、放送マネージドアプリを実行することにより生成されるメッセージ制御部４２３が有する送信元サービス設定部４２３５の機能（図８におけるcommon_messaging.js）によって、送信元のサービスの識別子が設定される。一方、メッセージＭ２２の場合は、連携端末５の送信元サービス設定部５３４５が、メッセージＭ２１に送信元のサービスＰの識別子を付加する。

なお、メッセージのフォーマットはこれらの記述例に限らない。また、本実施形態では、送信元のサービスの識別子と送信先のサービスの識別子のみを記述したが、受信装置４、連携端末５、もしくはＩｏＴ機器１０を送信先として記述しても構わない。

図１０，図１１及び図１２は、メッセージ制御部４２３及びメッセージ制御部５３４の動作を示す処理フローである。以下では、メッセージ制御部５３４を例にして説明するが、メッセージ制御部４２３も同様に動作する。

図１０及び図１１は、メッセージ受信時の処理フローを示すフローチャートである。なお、図１０と図１１とは、結合子により接続されている。連携端末５の端末連携部５３１は、通信入出力部５１１を介して受信装置４から受信したメッセージを、メッセージ受信部５３４２に出力する。メッセージ受信部５３４２は、端末連携部５３１からメッセージを受信する（ステップＳ１０５）。メッセージ受信部５３４２は、受信したメッセージから送信先のサービスの識別子及び送信元のサービスの識別子を検出する（ステップＳ１１０）。メッセージ受信部５３４２は、メッセージが読み出した送信先のサービスの識別子及び送信元のサービスの識別子をメッセージ判定部５３４３に通知し、メッセージ全体をメッセージ分配部５３４４に通知する（ステップＳ１１５）。

メッセージ判定部５３４３は、サービス識別管理部５３４１に、送信先のサービスの識別子により特定されるサービスをサービス実行部５３２が実行しているか否かの照合を依頼する（ステップＳ１２０）。サービス識別管理部５３４１は、メッセージ判定部５３４３から通知された送信先のサービスの識別子と対応付けて対応表に登録されているサービス実行部５３２の識別子を取得する。サービス識別管理部５３４１は、サービス実行部５３２の識別子が取得できた場合はその識別子を設定した照合結果を、取得できなかった場合はサービス実行部５３２がないことを示す照合結果を出力する。

メッセージ判定部５３４３は、サービス識別管理部５３４１から、送信先のサービスの識別子により特定されるサービスを実行するサービス実行部５３２があることを示す照合結果を受信したと判断すると（ステップＳ１２５：はい）、ステップＳ１３５に移る。

一方、メッセージ判定部５３４３は、サービス識別管理部５３４１から送信先のサービスの識別子により特定されるサービスを実行するサービス実行部５３２がないことを示す照合結果を受信したと判断すると（ステップＳ１２５：いいえ）、ステップＳ１３０の処理を行う。すなわち、メッセージ判定部５３４３は、エラーをメッセージの送信元に返送するなど、所定のエラー処理を行う（ステップＳ１３０）。

ステップＳ１２５からＳ１３５に移った場合、引き続き下記の処理を行う。
メッセージ判定部５３４３は、送信先の識別子と送信元の識別子が同一であるか否かを判定する（ステップＳ１３５）。
図１１に移って、送信先の識別子と送信元の識別子が同一であると判定された場合（ステップＳ１４０：はい）、ステップＳ１４５に進む。送信先の識別子と送信元の識別子が同一ではないと判定された場合（ステップＳ１４０：いいえ）、ステップＳ１６５に進む。

メッセージ判定部５３４３は、送信先のデバイスが受信機（受信装置４）であるかＩｏＴ機器１０であるかを判定する（ステップＳ１５０）。送信先のデバイスが受信機（受信装置４）である場合（ステップＳ１５０：はい）、メッセージ判定部５３４３は、メッセージ分配部５３４４に対して、端末連携部５３１を経由してメッセージを送信するよう通知する（ステップＳ１５５）。送信先のデバイスがＩｏＴ機器１０である場合（ステップＳ１５０：いいえ）、メッセージ判定部５３４３は、メッセージ分配部５３４４に対して、機器連携部５３５を経由してメッセージを送信するよう通知する（ステップＳ１６０）。これらのいずれの場合も、次に、ステップＳ１７０に移る。

送信先の識別子と送信元の識別子が同一ではない場合（ステップＳ１４０：いいえ）の処理は次の通りである。即ち、メッセージ判定部５３４３は、メッセージ分配部５３４４に対して、メッセージに記述された送信先のサービス実行部５３２にメッセージを送信するよう通知する。具体的には、メッセージ判定部５３４３は、メッセージに記述された送信先の識別子のサービスを実行するサービス実行部５３２にメッセージを送信するようにする（ステップＳ１６５）。次に、ステップＳ１７０に移る。

ステップＳ１５５、Ｓ１６０、Ｓ１７０のいずれかの処理の完了後、メッセージ分配部５３４４は、メッセージ判定部５３４３からの指示に従い、端末連携部５３１、機器連携部５３５、もしくは各サービス実行部５３２のいずれかにメッセージを送信する。
以上で、このフローチャートの処理を終了する。

図１２は、メッセージ発行時の処理フローを示すフローチャートである。サービス実行部５３２は、メッセージを設定し、送信元サービス設定部５３４５に通知する（ステップＳ２０５）。送信元サービス設定部５３４５は、受信したメッセージに対して、送信元の識別子として、メッセージの送信元のサービス実行部５３２が実行しているサービスの識別子を追加し、メッセージ受信部５３４２に通知する（ステップＳ２１０）。メッセージ受信部５３４２は、メッセージから読み出した送信先のサービスの識別子及び送信元のサービスの識別子をメッセージ判定部５３４３に通知し、メッセージ全体をメッセージ分配部５３４４に通知する（ステップＳ２１５）。

メッセージ判定部５３４３は、送信先と送信元の識別子が同一か否かを判定する（ステップＳ２２０）。メッセージ判定部５３４３は、送信先と送信元の識別子が同一と判定した場合（ステップＳ２２５：はい）、メッセージ分配部５３４４に対して、端末連携部５３１を経由して受信装置４に、または機器連携部５３５を経由してＩｏＴ機器１０に、メッセージを送信するよう通知する（ステップＳ２３０）。メッセージ分配部５３４４は、メッセージ判定部５３４３の指示に従い、メッセージを端末連携部５３１または機器連携部５３５の適切な方に出力する。端末連携部５３１側に出力された場合、端末連携部５３１は、メッセージ分配部５３４４から受信したメッセージを、通信入出力部５１１を介して受信装置４に送信する。また、機器連携部５３５側に出力された場合、機器連携部５３５は、メッセージ分配部５３４４から受信したメッセージを、機器通信入出力部５１２を介してＩｏＴ機器１０に送信する（ステップＳ２４０）。

一方、メッセージ判定部５３４３は、送信先と送信元の識別子が同一ではないと判定した場合（ステップＳ２２５：いいえ）、ステップＳ２３５の処理を行う。すなわち、メッセージ判定部５３４３は、サービス識別管理部５３４１から、メッセージに記述された送信先のサービスの識別子に対応して対応表に登録されているサービス実行部５３２の識別子を読み出す。メッセージ判定部５３４３は、読み出した識別子により特定されるサービス実行部５３２、つまり、メッセージに記述された送信先のサービスの識別子により特定されるウェブサービスを実行しているサービス実行部５３２へメッセージを送信するよう、メッセージ分配部５３４４に通知する（ステップＳ２３５）。メッセージ分配部５３４４は、メッセージ判定部５３４３により送信先として指示されたサービス実行部５３２に、メッセージを送信する（ステップＳ２４０）。

図１３は、受信装置４と連携端末５の間のシーケンス図である。受信装置４のサービス実行部４２１は、連携端末５において実行されるサービスの識別子を宛先に設定したメッセージを発行する（ステップＳ３０５）。送信元サービス設定部４２３５は、サービス実行部４２１から受信したメッセージに送信元のサービスの識別子を設定し、メッセージ受信部４２３２に出力する（ステップＳ３１０）。メッセージ受信部４２３２は、メッセージから取得した送信元のサービスの識別子及び送信先のサービスの識別子をメッセージ判定部４２３３に通知し（ステップＳ３１５）、メッセージ全体をメッセージ分配部４２３４に通知する（ステップＳ３２０）。メッセージ判定部４２３３は、送信元のサービスの識別子及び送信先のサービスの識別子が同一であるため、連携端末５にメッセージを送信するようメッセージ分配部４２３４に通知する（ステップＳ３２５）。メッセージ分配部４２３４は、メッセージを端末連携部４１２に出力し（ステップＳ３３０）、端末連携部４１２は、メッセージを、通信入出力部４０６を介して連携端末５に送信する。

連携端末５の通信入出力部５１１は、受信装置４から受信したメッセージを端末連携部５３１に出力する（ステップＳ３３５）。メッセージ受信部５３４２は、端末連携部５３１からメッセージを受信する（ステップＳ３４０）。メッセージ受信部５３４２は、メッセージから取得した送信元のサービスの識別子及び送信先のサービスの識別子をメッセージ判定部５３４３に通知し（ステップＳ３４５）、メッセージ全体をメッセージ分配部５３４４に通知する（ステップＳ３５０）。メッセージ判定部５３４３は、送信先のサービスの識別子により特定されるウェブサービスが存在することを示す照合結果をサービス識別管理部５３４１から受信すると、ステップＳ３５５の処理を行う。すなわち、メッセージ判定部５３４３は、送信先のサービスの識別子により特定されるウェブサービスを実行しているサービス実行部５３２へメッセージを出力するようメッセージ分配部５３４４に指示する（ステップＳ３５５）。メッセージ分配部５３４４は、メッセージ判定部５３４３に指示されたサービス実行部５３２へメッセージを出力する（ステップＳ３６０）。

図１３では、受信装置４から連携端末５へのメッセージの送信例を示したが、連携端末５から受信装置４へのメッセージ送信も同様の手順で実行できる。

図１４は、連携端末５のウェブアプリ間でメッセージを送信する場合のシーケンス図である。同図では、サービス実行部５３２−１をサービス実行部（１）、サービス実行部５３２−２をサービス実行部（２）と記載している。

サービス実行部５３２−１は、サービス実行部５３２−２が実行しているサービスの識別子を宛先に設定したメッセージを発行する（ステップＳ４０５）。送信元サービス設定部５３４５は、サービス実行部５３２−１から受信したメッセージに送信元のサービスの識別子を設定し、メッセージ受信部５３４２に出力する（ステップＳ４１０）。メッセージ受信部５３４２は、メッセージから取得した送信元のサービスの識別子及び送信先のサービスの識別子をメッセージ判定部５３４３に通知し（ステップＳ４１５）、メッセージ全体をメッセージ分配部５３４４に通知する（ステップＳ４２０）。メッセージ判定部５３４３は、送信元のサービスの識別子及び送信先のサービスの識別子が異なるため、送信先のサービスの識別子により特定されるウェブサービスを実行しているサービス実行部５３２−２にメッセージを送信するようメッセージ分配部５３４４に通知する（ステップＳ４２５）。メッセージ分配部５３４４は、メッセージ判定部５３４３に指示されたサービス実行部５３２−２へメッセージを出力する（ステップＳ４３０）。

図１４では、連携端末５のウェブアプリ間でメッセージを送信する場合ついて示しているが、受信装置４のサービス実行部４２１間でメッセージを送信する場合についても同様の手順で実行できる。

上述した、図９から図１４までの例では、全てのメッセージに送信元のサービスの識別子と送信先のサービスの識別子を付加して送信していたが、サービス間のチャンネルの識別子を付加する実施形態をとっても構わない。この場合、受信装置４の放送マネージドアプリのサービスと連携端末５のウェブサービスとの間、又は、連携端末５におけるウェブサービス間で、メッセージングを開始する前に、接続処理を実行してサービス間のチャンネルを確立する。以降、受信装置４及び連携端末５は、接続解除の処理が実行されるまでは、確立したチャンネルにおいて割り当てられたセッションの識別子に基づき、送信元と送信先の識別子を付加せずにメッセージを送信する。

図１５は、受信装置４の放送マネージドアプリのサービスと連携端末５のウェブサービスとの間でセッションの識別子に基づきメッセージを送信する場合のメッセージの設定例を示す図である。図１５（ａ）は、接続登録メッセージＭ３１を、図１５（ｂ）は接続登録確認メッセージＭ３２を、図１５（ｃ）は接続解除メッセージＭ３３を、図１５（ｄ）は接続解除確認メッセージＭ３４を、図１５（ｅ）はメッセージ本体が設定されたメッセージＭ３５を示す。

接続登録メッセージＭ３１、接続登録確認メッセージＭ３２、接続解除メッセージＭ３３、接続解除確認メッセージＭ３４、メッセージＭ３５には、type属性が含まれている。
このtype属性により、メッセージが登録（publish）／登録確認（subscribe）／接続解除（unpublish）／接続解除確認（unsubscribe）／メッセージ本体（body）のいずれであるかが識別可能である。

また、接続登録メッセージＭ３１、接続登録確認メッセージＭ３２、接続解除メッセージＭ３３、接続解除確認メッセージＭ３４には、送信元のサービスの識別子（src）及び送信先のサービスの識別子（dst）が設定され、接続登録確認メッセージＭ３２及び接続解除確認メッセージＭ３４には、さらに、確立したチャンネルに割当てられたセッションの識別子（subscribe_ID）が記述される。メッセージ本体（message）が設定されたメッセージＭ３５には、送信元及び送信先は設定されず、セッションの識別子（subscribe_ID）とメッセージの内容（message）が記述される。

図１６及び図１７は、受信装置４と連携端末５の間でセッションの識別子に基づきメッセージを送信する場合のシーケンス図である。

図１６は、接続登録処理のシーケンスを示す。受信装置４のサービス実行部４２１は、接続登録メッセージを発行する（ステップＳ５０５）。サービス実行部４２１が発行した接続登録メッセージには、接続登録メッセージであることを示す「publish」が設定されたtype属性と、送信先のサービスの識別子が設定されたdst属性とが含まれる。送信元サービス設定部４２３５は、このメッセージに、送信元のサービスの識別子を設定したsrc属性を追加する。送信元サービス設定部４２３５は、src属性が追加された接続登録メッセージをメッセージ受信部４２３２に出力する（ステップＳ５１０）。

メッセージ受信部４２３２は、接続登録メッセージに設定されている送信先のサービスの識別子及び送信元のサービスの識別子をメッセージ判定部４２３３に通知し（ステップＳ５１５）、接続登録メッセージ全体をメッセージ分配部４２３４に通知する（ステップＳ５２０）。メッセージ判定部４２３３は、送信先と送信元のサービスの識別子が同一であるため、連携端末５にメッセージを送信するようメッセージ分配部４２３４に通知する（ステップＳ５２５）。メッセージ分配部４２３４は、接続登録メッセージを端末連携部４１２に出力し（ステップＳ５３０）、端末連携部４１２は、メッセージ分配部４２３４から受信した接続登録メッセージを、通信入出力部４０６を介して連携端末５に送信する。

連携端末５の通信入出力部５１１は、受信装置４からメッセージを受信し、端末連携部５３１に出力する（ステップＳ５３５）。メッセージ受信部５３４２は、端末連携部５３１からメッセージを受信する（ステップＳ５４０）。メッセージ受信部５３４２は、受信したメッセージをメッセージ判定部５３４３に出力する（ステップＳ５４５）。メッセージ判定部５３４３は、受信したメッセージのtype属性により接続登録メッセージであると判断すると、subscribe_IDを発行し、送信元及び送信先のサービスの識別子と対応付けて記憶する。なお、接続が解除される度に新規のsubscribe_IDを発番してもよく、送信元と送信先のペアに対して予め決定したsubscribe_IDを割り当てても構わない。さらに、メッセージ判定部５３４３は、接続登録確認メッセージを生成する。接続登録確認メッセージには、接続登録確認メッセージを示す「subscribe」が設定されたtype属性と、発行したsubscribe_IDと、接続登録メッセージに設定されていたdst属性及びsrc属性とが含まれる。メッセージ判定部５３４３は、生成した接続登録確認メッセージをメッセージ分配部５３４４に通知し、受信装置４へ送信するよう指示する（ステップＳ５５０）。

メッセージ分配部５３４４は、接続登録確認メッセージを端末連携部５３１に出力し（ステップＳ５５５）、端末連携部５３１は、接続登録確認メッセージを、通信入出力部５１１を介して受信装置４に送信する（ステップＳ５６０）。

受信装置４の通信入出力部４０６は、連携端末５から受信したメッセージを端末連携部４１２に出力する。メッセージ受信部４２３２は、端末連携部４１２からメッセージを受信する（ステップＳ５６５）。メッセージ受信部４２３２は、受信したメッセージのtype属性から接続登録確認メッセージであると判断する。メッセージ受信部４２３２は、接続登録確認メッセージから取得したsubscribe_IDと、送信元及び送信先のサービスの識別子をメッセージ判定部４２３３に出力する（ステップＳ５７０）。メッセージ判定部４２３３は、subscribe_IDと、送信元及び送信先のサービスの識別子とを対応付けて登録する。
さらに、メッセージ受信部４２３２は、接続登録確認メッセージを、送信先のサービスの識別子により特定される放送マネージドアプリを実行しているサービス実行部４２１にsubscribe_IDを通知する（ステップＳ５７５）。

図１７は、メッセージ送信処理のシーケンスを示す。受信装置４のサービス実行部４２１は、メッセージ本体を設定したメッセージを発行する（ステップＳ６０５）。メッセージには、メッセージ本体であることを示す「body」が設定されたtype属性と、送信先のサービスに応じたsubscribe_IDと、メッセージ内容とが含まれる。送信元サービス設定部４２３５は、サービス実行部４２１から受信したメッセージに送信元のサービスの識別子を設定する。なお、送信元のサービスの識別子の設定は行わなくてもよい。送信元サービス設定部４２３５は、送信元のサービスの識別子が設定されたメッセージを、メッセージ受信部４２３２に出力する（ステップＳ６１０）。

メッセージ受信部４２３２は、メッセージに設定されているsubscribe_IDをメッセージ判定部４２３３に通知し（ステップＳ６１５）、メッセージ全体をメッセージ分配部４２３４に通知する（ステップＳ６２０）。メッセージ判定部４２３３は、subscribe_IDに対応して記憶される送信先及び送信元のサービスの識別子が同一であるため、連携端末５にメッセージを送信するようメッセージ分配部４２３４に通知する（ステップＳ６２５）。
メッセージ分配部４２３４は、メッセージを端末連携部４１２に出力し（ステップＳ６３０）、端末連携部４１２は、メッセージ分配部４２３４から受信したメッセージを、通信入出力部４０６を介して連携端末５に送信する。

連携端末５の通信入出力部５１１は、受信装置４から受信したメッセージを端末連携部５３１に出力する（ステップＳ６３５）。メッセージ受信部５３４２は、端末連携部５３１からメッセージを受信する（ステップＳ６４０）。メッセージ受信部５３４２は、受信したメッセージのtypeによりメッセージ本体であると判断すると、メッセージから読み出したsubscribe_IDをメッセージ判定部５３４３に出力し（ステップＳ６４５）、メッセージをメッセージ分配部５３４４に出力する（ステップＳ６５０）。メッセージ判定部５３４３は、subscribe_IDに対応した送信元及び送信先のサービスの識別子が同じであるため、送信先のサービスの識別子により特定されるサービスを実行しているサービス実行部５３２へメッセージを出力するようメッセージ分配部５３４４に指示する（ステップＳ６５５）。メッセージ分配部５３４４は、メッセージ判定部５３４３に指示されたサービス実行部５３２へメッセージを出力する（ステップＳ６６０）。

図１６及び図１７では、受信装置４から連携端末５へのメッセージの送信例を示したが、連携端末５から受信装置４へのメッセージ送信も同様の手順で実行できる。

図１８は、連携端末５のウェブアプリ間でセッションの識別子に基づきメッセージを送信する場合のメッセージの記述例を示す図である。図１８（ａ）は、接続登録メッセージＭ４１を、図１８（ｂ）は接続登録確認メッセージＭ４２を、図１８（ｃ）は接続解除メッセージＭ４３を、図１８（ｄ）は接続解除確認メッセージＭ４４を、図１８（ｅ）はメッセージ本体が設定されたメッセージＭ４５を示す。Ｍ４１〜Ｍ４５のメッセージに含まれる属性はそれぞれ、図１５に示すＭ３１〜Ｍ３５のメッセージと同様である。

すなわち、接続登録メッセージＭ４１、接続登録確認メッセージＭ４２、接続解除メッセージＭ４３、接続解除確認メッセージＭ４４、メッセージＭ４５には、type属性が含まれている。また、接続登録メッセージＭ４１、接続登録確認メッセージＭ４２、接続解除メッセージＭ４３、接続解除確認メッセージＭ４４には、送信元のサービスの識別子（src）及び送信先のサービスの識別子（dst）が設定され、接続登録確認メッセージＭ４２及び接続解除確認メッセージＭ４４には、さらに、確立したチャンネルに割当てられたセッションの識別子（subscribe_ID）が記述される。メッセージ本体（message）が設定されたメッセージＭ４５には、送信元及び送信先は設定されず、セッションの識別子（subscribe_ID）とメッセージの内容（message）が記述される。

図１９及び図２０は、連携端末５のウェブアプリ間でセッションの識別子に基づきメッセージを送信する場合のシーケンス図である。このシーケンスは、図１６及び図１７に示すシーケンスと基本的な手順の差異はない。ただし、受信装置４と連携端末５との間でメッセージを送信する場合、連携端末５は、メッセージ分配部５３４４から端末連携部５３１を経由して送受信を行うが、ウェブアプリ間の場合は、メッセージ分配部５３４４から連携端末５内のメッセージ受信部５３４２にメッセージを送信し、以降、同様の処理が実行される。

図１９は、連携端末５のウェブアプリ間の接続登録処理のシーケンスを示す。連携端末５のサービス実行部５３２−１は、接続登録メッセージを発行する（ステップＳ７０５）。サービス実行部５３２−１が発行した接続登録メッセージには、接続登録メッセージであることを示す「publish」が設定されたtype属性と、サービス実行部５３２−２により実行される送信先のサービスの識別子が設定されたdst属性とが含まれる。送信元サービス設定部５３４５は、このメッセージに、送信元のサービスの識別子を設定したsrc属性を追加する。送信元サービス設定部５３４５は、src属性が追加された接続登録メッセージをメッセージ受信部５３４２に出力する（ステップＳ７１０）。

メッセージ受信部５３４２は、接続登録メッセージに設定されている送信先のサービスの識別子及び送信元のサービスの識別子をメッセージ判定部５３４３に通知し（ステップＳ７１５）、接続登録メッセージ全体をメッセージ分配部５３４４に通知する（ステップＳ７２０）。メッセージ判定部５３４３は、送信先と送信元のサービスの識別子が異なるため、メッセージ受信部５３４２にメッセージを送信するようメッセージ分配部５３４４に通知する（ステップＳ７２５）。メッセージ分配部５３４４は、接続登録メッセージをメッセージ受信部５３４２に出力する（ステップＳ７３０）。

メッセージ受信部５３４２は、受信したメッセージをメッセージ判定部５３４３に出力する（ステップＳ７３５）。メッセージ判定部５３４３は、受信したメッセージのtypeにより接続登録メッセージであると判断すると、subscribe_IDを発行し、送信元及び送信先のサービスの識別子と対応付けて記憶する。さらに、メッセージ判定部５３４３は、接続登録確認メッセージを生成する。メッセージ判定部５３４３は、生成した接続登録確認メッセージをメッセージ分配部５３４４に通知し、メッセージ受信部５３４２へ送信するよう指示する（ステップＳ７４０）。メッセージ分配部５３４４は、接続登録確認メッセージをメッセージ受信部５３４２に出力する（ステップＳ７４５）。

メッセージ受信部５３４２は、受信した接続登録確認メッセージから取得したsubscribe_IDと、送信元及び送信先のサービスの識別子をメッセージ判定部５３４３に出力する（ステップＳ７５０）。メッセージ判定部５３４３は、subscribe_IDと、送信元及び送信先のサービスの識別子とを対応付けて登録する。さらに、メッセージ受信部５３４２は、接続登録確認メッセージを、送信先のサービスの識別子により特定されるウェブアプリを実行しているサービス実行部５３２−１にsubscribe_IDを通知する（ステップＳ７５５）。

図２０は、連携端末５のウェブアプリ間のメッセージ送信処理のシーケンスを示す。連携端末５のサービス実行部５３２−１は、メッセージ本体を設定したメッセージを発行する（ステップＳ８０５）。送信元サービス設定部５３４５は、サービス実行部５３２−１から受信したメッセージに送信元のサービスの識別子を設定する。なお、送信元のサービスの識別子の設定は行わなくてもよい。送信元サービス設定部５３４５は、送信元のサービスの識別子が設定されたメッセージを、メッセージ受信部５３４２に出力する（ステップＳ８１０）。

メッセージ受信部５３４２は、メッセージに設定されているsubscribe_IDをメッセージ判定部５３４３に通知し（ステップＳ８１５）、メッセージ全体をメッセージ分配部５３４４に通知する（ステップＳ８２０）。メッセージ判定部５３４３は、subscribe_IDに対応して記憶される送信先及び送信元のサービスの識別子が異なるため、送信先のサービスの識別子により特定されるウェブサービスを実行しているサービス実行部５３２−２にメッセージを送信するようメッセージ分配部５３４４に通知する（ステップＳ８２５）。メッセージ分配部５３４４は、メッセージ判定部５３４３に指示されたサービス実行部５３２−２へメッセージを出力する（ステップＳ８３０）。

図１９及び図２０では、連携端末５のウェブアプリ間でメッセージを送信する場合ついて示しているが、受信装置４において放送マネージドアプリにより実行されるサービス間でのメッセージ送信についても同様の手順で実行できる。

次に、連携端末５内の機器連携部５３５についてさらに詳細に説明する。連携端末５において、メッセージ制御部５３４の処理により、ＩｏＴ機器１０へのメッセージは機器連携部５３５に送られる。一例として、複数のＩｏＴ機器１０のうちのどのＩｏＴ機器１０にメッセージを送るかを表す情報は、メッセージ本文内に記述される。機器連携部５３５は、メッセージ本文を解釈することによって送信先を判断し、メッセージを配分する役割を担う。

図２１は、機器連携部の詳細な構成を示すブロック図である。図示するように、機器連携部５３５は、機器管理部５３５１及び機器通信部５３５２（５３５２−１及び５３５２−２）を有する。

機器管理部５３５１は、サービス実行部５３２からメッセージ制御部５３４経由で送られてきたメッセージを受信する。また、機器管理部５３５１は、連携端末５の周辺に存在する通信可能なＩｏＴ機器１０の表を保有し、送信先のＩｏＴ機器１０が存在するか否かを判定する。また、ＩｏＴ機器１０の各々が接続を許可するサービスの表を保有し、ＩｏＴ機器１０がサービスからのメッセージの送信を許可するか否かを判定する。メッセージの送信が可能である場合、機器管理部５３５１は、使用する通信プロトコルに対応した機器通信部５３５２にメッセージを送信する。

機器通信部５３５２は、必要に応じて、送信するメッセージの形式を、送信先のＩｏＴ機器１０に則した形式に変換する。なお、変換後のメッセージの形式は、送信先であるＩｏＴ機器１０の内部構成や機能によってさまざまである。機器通信部５３５２は、それらのそれぞれに柔軟に対応してメッセージの形式を変換する機能を有する。変換後のメッセージの形式は、一例として、ウェブブラウザで解釈可能な形式である。また、別の例として、バイナリ形式であってもよい。さらに他の形式であってもよい。そして機器通信部５３５２は、ハードウェアの通信機能（機器通信入出力部５１２）を呼び出し、メッセージを送信する。なお、機器連携部５３５は、複数の系統の機器通信部５３５２を有していてよい。図２１に示す機能構成においても、複数の機器通信部５３５２が存在しており、例えばプロトコル毎に使い分けられる。ここでは符号に枝番を付している。即ち、機器通信部５３５２−１は、情報通信入出力部５１２−１を通して情報の送受信を行う。また、機器通信部５３５２−２は、情報通信入出力部５１２−２を通して情報の送受信を行う。ここでは系統数が２である場合を示しているが、系統数は任意である。

図２２は、機器管理部５３５１がメッセージ制御部５３４から受信するメッセージの例を示す概略図である。図示するメッセージにおいて、次の情報が記述されている。即ち、送信先のサービスを識別する情報が記述されている（dst: serviceP）。また、機器種別がＩｏＴ機器であることを表す情報が記述されている（dev: IoT）。

また、このメッセージ（message）内部には、次の情報が記述されている。即ち、通信プロトコル（protocol: Bluetooth Low Energy）は、メッセージの送信に用いる通信プロトコルを示すものである。また、機器特定要素（target info:）は、対象とする機器を特定する要素である。機器特定要素は、例えば、コマンドタイプ、デバイスタイプ、デバイスメーカー、デバイスネーム、デバイスＩＤ、及びコマンドを含む。コマンドタイプ（command type: control light）は、送信する命令の機能の種別を表すものである。例えば、「調光する」、「速度を変更する」、「電気を点ける」などといったコマンドタイプがあり得る。デバイスタイプ（device type: light）は、送信先のデバイスの種類を示すものである。例えば、「ロボット」、「電球」などといった機器種別が考えられる。デバイスメーカー（device maker: maker A）は、送信先の機器のメーカー（製造業者）を一意に識別する情報である。デバイスネーム（device name: A's LIGHT）は、送信先の機器の名称を表す情報である。例えば、製品群名、製品名などがデバイスネームとして用いられる。デバイスＩＤ（device id: l_00000001）は、送信先の機器をＭＡＣアドレス等のレベルで識別するための情報である。なお、「ＭＡＣアドレス」は、「Media Access Control Address」を意味する。コマンド（command: hogehogehoge）は、送信先の機器への命令を含む情報である。命令は、例えば、ＨＴＭＬ５で記述されるものである。

機器管理部５３５１は、ＩｏＴ機器宛のメッセージの送信先の判定と、メッセージの送信の可否の判定を行う。そのために機器管理部５３５１は、自らが保持する２種類の表を参照する。

機器管理部５３５１が保持する第１の表は、通信可能機器表である。通信可能機器表は、連携端末５が通信可能なＩｏＴ機器１０の情報を持つ表である。通信可能機器表は、通信可能なＩｏＴ機器１０毎に、通信プロトコル及び機器特定要素の情報を有している。機器管理部５３５１は、受け取ったメッセージの送信先として指定された機器が、通信可能な状態で存在するか否かを調べるためにこの通信可能機器表を参照する。なお、通信可能機器表を更新する方法は、実装に依存する。連携端末５は、適切なタイミングにおいて通信可能なＩｏＴ機器１０をサーチし、検出できたＩｏＴ機器１０の情報に基づいて通信可能機器表を更新する。

機器管理部５３５１が保持する第２の表は、機器利用可能サービス表である。機器利用可能サービス表は、ＩｏＴ機器１０毎に、接続を許可するサービスの種類の情報を一覧形式で持つ。この機器利用可能サービス表は、例えばコンパニオンアプリのアップデート等の際に、併せて更新することができる。また、別のタイミングで機器利用可能サービス表を適宜更新するようにしてもよい。つまり、機器連携部５３５内の機器管理部５３５１は、メッセージに含まれるサービス識別情報が示すサービスをＩｏＴ機器１０が受け入れるか否かを表す情報をＩｏＴ機器１０の属性に対応付けて保持する機器利用可能サービス表を記憶し、サービス識別情報に基づいてメッセージをＩｏＴ機器１０に送信するか否かを判断する。

図２３は、機器連携部の動作シーケンスを示すフローチャートである。以下、このフローチャートに沿って説明する。

機器管理部５３５１は、メッセージ制御部５３４からメッセージを受信する（ステップＳ９０５）。機器管理部５３５１は、受信したメッセージの本文（図２１におけるmessage: {…}）に含まれる通信プロトコル及び機器特定要素を抽出する（ステップＳ９１０）。そして、機器管理部５３５１は、メッセージ本文から抽出した通信プロトコル及び機器特定要素と、自らが維持する通信可能機器表とを比較し、メッセージ送信先であるＩｏＴ機器１０が、自装置の周辺に通信可能な状態で存在するか否かを判定する（ステップＳ９１５）。送信先のＩｏＴ機器１０が存在しない場合（ステップＳ９２０：いいえ）、エラー処理を行うためにステップＳ９４５に移る。送信先のＩｏＴ機器１０が存在する場合（ステップＳ９２０：はい）、次のステップＳ９２５に移る。

機器管理部５３５１は、メッセージに含まれるサービス識別子と、自らが維持する機器利用可能サービス表を比較する。この比較結果に基づいて、機器管理部５３５１は、存在する送信先のＩｏＴ機器１０がメッセージ送信元のサービスからの接続を許可するか否かを判定する（ステップＳ９２５）。許可しない場合、つまりそのＩｏＴ機器１０が受け入れるサービスの中に、送信元のサービスが含まれない場合（ステップＳ９３０：いいえ）、エラー処理を行うためにステップＳ９４５に移る。許可する場合、つまりそのＩｏＴ機器１０が受け入れるサービスの中に、送信元のサービスが含まれる場合（ステップＳ９３０：はい）、次のステップＳ９３５に移る。

機器管理部５３５１は、メッセージ本文に含まれる通信プロトコルの情報を基に、メッセージを送信する機器通信部５３５２を判定し、該当する機器通信部５３５２にメッセージを渡す（ステップＳ９３５）。このとき、メッセージを送信可能なＩｏＴ機器１０が複数存在する場合の処理は、実装に依存する。例えば、予め定められたルールに従って優先度の高いＩｏＴ機器１０にメッセージを送信してもよく、またその都度、ＩｏＴ機器１０を選択してメッセージを送信してもよい。機器通信部５３５２は、機器管理部からメッセージを受信する。そして機器通信部５３５２は、メッセージ本文に含まれる機器特定要素を基に、機器通信入出力部５１２を介して、送信先のＩｏＴ機器１０にメッセージを送信する（ステップＳ９４０）。

ステップＳ９２０またはＳ９３０から、ステップＳ９４５に移った場合の処理は、次の通りである。即ち、機器管理部５３５１は、メッセージを適切に送信する先がないため（接続が許可されない場合を含む）、エラーを送信元に通知するなどといったエラー処理を行う（ステップＳ９４５）。

受信装置４とＩｏＴ機器１０とが連携するまでの手順は次の通りである。受信装置４において実行する放送マネージドアプリからＩｏＴ機器１０へメッセージを送る例を示す。まず受信装置４が連携端末５にメッセージを送る。メッセージ内には、連携端末５からＩｏＴ機器１０にメッセージを送るように記述されている。また、メッセージ内には、送信先のＩｏＴ機器１０を特定する情報と、送信先であるそのＩｏＴ機器１０に与える命令が記述されている。連携端末５は、送信先のＩｏＴ機器１０を特定する情報に従って、ＩｏＴ機器１０にメッセージを送る。ＩｏＴ機器１０はメッセージに記述された命令に従って動作する。この結果、受信装置４とＩｏＴ機器１０とは連携端末５を介して連携動作することになる。

また、連携端末５において実行するコンパニオンアプリから、受信装置４とＩｏＴ機器１０とのそれぞれに、関連したメッセージを送信するようにしてもよい。この方法を用いて受信装置４とＩｏＴ機器１０とが連携して動作するようにすることも可能である。

次に、受信装置４と連携端末５とＩｏＴ機器１０との連携動作を利用した具体的なサービスの実行手順の一例を説明する。
図２４及び図２５は、具体的なサービスの例を実現するための手順であって、受信装置４とＩｏＴ機器１０が双方向にメッセージのやり取りを行う手順の例を示すシーケンス図である。図２４と図２５は一連の手順の流れを示している。即ち、図２４に示す手順の実行後に、図２５に示す手順が実行される。

ここでは、テレビで放送される音楽番組とピアノ玩具との連携サービスを例とする。
このサービスは、放送される音楽番組の中での演奏に合わせてピアノ玩具の鍵盤が光る「お手本モード」と、ピアノ玩具の鍵盤を叩くことでその音階が受信装置４の画面上に表示される「練習モード」とで構成される。前提として、受信装置４と連携端末５とにおいて、番組に連動したウェブアプリが実行されている。以下で説明する手順において、受信装置４や連携端末５の動作は、それぞれの装置で稼働するアプリの動作である。また、受信装置４と連携端末５とのペアリングは既に完了している。また、連携端末５は、接続可能なＩｏＴ機器１０のリストを既に保持している。

まず図２４において、受信装置４で稼働するアプリから連携端末５に、現在利用可能なサービス名と、サービスに対応するＩｏＴ機器１０のリストを送信する（ステップＳ１００５）。連携端末５は、受信装置４から受信したＩｏＴ機器１０のリストと、予め保持している接続可能なＩｏＴ機器１０のリストと比較する。該当するＩｏＴ機器１０が接続可能な状態で存在する場合、連携端末５は、例えば通知機能を用いて、ユーザに機器連携サービスが利用可能であること、及び対象となるＩｏＴ機器１０のリストを通知する（ステップＳ１０１０）。なお、ステップＳ１００５およびＳ１０１０の処理は、所定の時間間隔で繰り返し行われてもよい。このときの状態は、図示する「サービス・機器選択前」の状態である。

ユーザは上記の通知に応じて、サービス及び機器を選択する操作を連携端末５において行う（ステップＳ１０１５）。このユーザの選択に応じて、連携端末５は、ＩｏＴ機器１０に接続要求を行う（ステップＳ１０２０）。このとき、連携端末５が必要に応じてユーザにペアリングキーの入力を要求するようにしてもよい。ＩｏＴ機器１０は、連携端末５からの接続要求に応答して、接続受付を連携端末５に返す（ステップＳ１０２５）。連携端末５は、ＩｏＴ機器１０からの接続受付を受信したことによって接続の成功を認識すると、接続の成功をユーザに通知し、サービス画面に遷移する。また、連携端末５は、接続したＩｏＴ機器１０のデバイスＩＤを受信装置４に通知する（ステップＳ１０３０）。受信装置４は、通知されたデバイスＩＤを保持する。これにより、受信装置４とＩｏＴ機器１０との間で双方向にメッセージをやり取りする準備が完了する。このときの状態は、図示する「サービス・機器選択後」の状態である。

連携端末の画面には、モードを選択することのできるユーザインタフェースが表示されている。具体的には、ユーザは「お手本モード」と「練習モード」とを選択できる。ここで、ユーザは、連携端末５を操作して「お手本モード」への移行を選択する（ステップＳ１０３５）。ユーザから選択に応じて、連携端末５は、受信装置４に「お手本モード」が選択されたことを通知する（ステップＳ１０４０）。

受信装置４において稼働するアプリは、不図示のサービスサーバ装置からインターネット等の通信手段を介して、演奏データを取得する。サービスサーバ装置は、放送されている音楽番組の中での演奏に合わせたタイミングで、この演奏データを受信装置４に送信する。演奏データは、放送中の音楽番組において演奏中の曲の楽譜データと、楽譜データ上において現在演奏されている箇所を示すデータ（拍子のデータ、あるいは楽譜データ上の特定の音符を指し示すデータ）とで構成される。受信装置４は、サービスサーバ装置から受信した演奏データに基づいて、画面への表示を行う。具体的には、受信装置４は、上記の楽譜データに基づいて楽譜を画面上に描画するとともに、その楽譜上で現在演奏されている箇所を例えば色を変えるなどして指し示す。

図２５に移って、受信装置４は、演奏データをテレビの画面に表示するのと同時に、「演奏個所に応じた鍵盤を光らせる」という命令を含んだメッセージを、連携端末５に送信する（ステップＳ１０４５）。図示する具体例では、この命令は「『ミ』を光らせる」という命令である。そして連携端末５は、その命令を含んだメッセージをＩｏＴ機器１０に送信する（ステップＳ１０５０）。なお、このとき、最初に取得したデバイスＩＤを用いて、このＩｏＴ機器１０がメッセージの送信先として指定されている。図示する例では、鍵盤上の「ミ」のキーの色が、他の色と異なっている。なお、メッセージの送信先として、複数のデバイスＩＤを指定してもよい。また、デバイスＩＤの代わりに、デバイスネーム等、他の識別子を用いて指定してもよい。ＩｏＴ機器１０（ピアノ玩具）は、メッセージに応じて鍵盤の所定のキーを光らせる。なお、このときの状態は、図示する「鍵盤へのメッセージ送信」の状態である。

次に、ユーザは連携端末５を操作することによって、「練習モード」への移行を選択する（ステップＳ１０５５）。連携端末５は、受信装置４に、「練習モード」へ移行したことを通知する（ステップＳ１０６０）。また、連携端末５は、ＩｏＴ機器１０に、「練習モード」へ移行したことを通知する（ステップＳ１０６５）。この状態において、ユーザは、鍵盤を操作する（ステップＳ１０７０）。

この状態において、ＩｏＴ機器１０（ピアノ玩具）は、ユーザが鍵盤を叩く都度、どのキーが叩かれたかを表す情報を含んだメッセージを連携端末に送信する（ステップＳ１０７５）。ここでＩｏＴ機器１０から連携端末５に送信されるメッセージ自体には、送信先の受信装置を識別する情報は含まれていない。しかしながら連携端末５は、最初にＩｏＴ機器１０への接続要求を行った受信装置４のＩＤを保持している。そのため、連携端末５は、このＩｏＴ機器と連携している受信装置４のみにメッセージを転送することができる（ステップＳ１０８０）。受信装置４は、どのキーが叩かれたかを表すメッセージを受信し、キーの種類に応じた動作をする。このように、ＩｏＴ機器１０から受信装置４へのメッセージの送信が行われる。なお、図示する具体例では、ＩｏＴ機器１０からは「『ラ』を弾いた」というメッセージが、連携端末５経由で、受信装置４に送られる。受信装置４側では、画面に表示している楽譜上の、叩かれたキーに対応する位置（高さ）を光らせるなどといたビジュアル表現を行う。このときの状態は、図示する「鍵盤からのメッセージ受信」の状態である。

以上説明したように、サービスの利用開始時に、連携端末５が、受信装置４とＩｏＴ機器１０とを接続する処理を行う。これによって、以後、受信装置４とＩｏＴ機器１０との間で、連携端末５を経由する形での双方向のメッセージのやり取りが可能となる。

以上説明した実施形態の構成において、受信装置４で実行するサービスから、連携端末５を介して、連携端末と通信接続が可能なＩｏＴ機器１０にメッセージを送ることが可能となる。あるいは、連携端末５から受信装置４とＩｏＴ機器１０との双方に、関連したメッセージを送ることが可能となる。これにより、受信装置４とＩｏＴ機器１０を連携した新たな視聴サービスを実現することが可能となる。

また、以上説明した実施形態によれば、放送通信連携システム１は、受信装置４と、連携端末５（端末装置）とを有する。受信装置４は、放送信号に含まれるコンテンツデータを出力する処理と、放送信号と連携した動作により複数のサービスを提供するアプリケーション（放送マネージドアプリ）を実行する処理とを実行する。連携端末５は、個別のサービスを提供するアプリケーションであるサービスアプリケーション（サービスアプリ、ウェブアプリ）を複数並列で実行させる。受信装置４が実行するアプリケーションに含まれるサービスの機能と、サービスアプリケーションにより提供されるサービスの機能とが連携して、ユーザにサービスを提供する。

連携端末５は、サービスアプリケーションを複数並列で実行させる連携アプリ実行制御部５３と、受信装置４と通信する通信入出力部５１１（通信部）とを備える。連携アプリ実行制御部５３は、複数のサービス実行部５３２と、メッセージ判定部５３４３と、メッセージ分配部５３４４と、送信元サービス設定部５３４５とを有する。各サービス実行部５３２は、受信したメッセージを用いてサービスアプリケーションを実行する。メッセージ判定部５３４３は、受信装置４において実行されているアプリケーションから発行され、通信入出力部５１１が受信したメッセージに設定されている送信先の情報に基づいて、メッセージの宛先のサービス実行部５３２を判定する。メッセージ分配部５３４４は、メッセージ判定部５３４３が判定した宛先のサービス実行部５３２にメッセージを出力する。

また、メッセージ判定部５３４３は、サービス実行部５３２が発行したメッセージの宛先を判定する。メッセージ分配部５３４４は、サービス実行部５３２により発行されたメッセージの宛先が受信装置４であるとメッセージ判定部５３４３により判定された場合、当該メッセージを通信入出力部５１１により受信装置４に送信する。また、メッセージ分配部５３４４は、サービス実行部５３２により発行されたメッセージの宛先が他のサービス実行部５３２であるとメッセージ判定部５３４３により判定された場合、当該メッセージを宛先と判定された他のサービス実行部５３２に出力する。

なお、サービス実行部５３２は、受信装置４において実行されるアプリケーションが提供するサービスの識別子又は他のサービス実行部５３２において実行されるサービスアプリケーションが提供するサービスの識別子を送信先の情報に設定したメッセージを発行してもよい。送信元サービス設定部５３４５は、サービス実行部５３２が発行したメッセージの送信元の情報に、当該メッセージを発行したサービス実行部５３２において実行されるサービスアプリケーションが提供するサービスの識別子を設定する。このとき、メッセージ判定部５３４３は、送信元サービス設定部５３４５により送信元の情報が設定されたメッセージから取得した送信元のサービスの識別子及び送信先のサービスの識別子に基づき、メッセージの宛先が受信装置４であるか他のサービス実行部５３２であるかを判定してもよい。メッセージ分配部５３４４は、メッセージ判定部５３４３により判定された宛先に、サービス実行部５３２により発行されたメッセージを出力する。

また、連携アプリ実行制御部５３は、サービス実行部５３２と受信装置４との間、又は、異なるサービス実行部５３２の間で通信チャンネルの確立及び解除を行う端末連携部５３１をさらに備えてもよい。この場合、メッセージ判定部５３４３は、受信装置４から受信したメッセージに設定されている通信チャンネルの識別情報に基づいてメッセージの宛先となるサービス実行部５３２を判定する処理と、サービス実行部５３２から発行されたメッセージに設定されている通信チャンネルの識別情報に基づいてメッセージの宛先が他のサービス実行部５３２であるか受信装置４であるかを判定する処理との少なくとも一方を行う。メッセージ分配部５３４４は、メッセージ判定部５３４３により判定された宛先に、サービス実行部５３２により発行されたメッセージを出力する。

また、受信装置４は、放送信号を受信し、放送信号に含まれるコンテンツデータを出力する受信機機能部と、アプリケーションに含まれる複数のサービスの機能を複数並列で実行させるアプリ実行部４０９と、連携端末５と通信する通信入出力部４０６（通信部）とを有する。受信機機能部は、例えば、放送受信部４０１、分離部４０２、映像復号部４０３、音声復号部４０４、データ放送実行部４０５、リモコン入力制御部４０７、電源制御部４０８、映像合成部４１３、映像表示部４１４、音声合成部４１５、音声出力部４１６などである。アプリ実行部４０９は、サービス実行部４２１と、メッセージ判定部４２３３と、メッセージ分配部４２３４と、送信元サービス設定部４２３５を備える。サービス実行部４２１はそれぞれ、受信機機能部から取得した情報と、受信したメッセージの記述とを用いて、アプリケーションに含まれるサービスの機能のそれぞれを実行する。メッセージ判定部４２３３は、連携端末５において実行されているサービスアプリケーションから発行され、通信入出力部４０６が受信したメッセージに設定されている送信先の情報に基づいて、メッセージの宛先のサービス実行部４２１を判定する。メッセージ分配部４２３４は、メッセージ判定部４２３３により判定された宛先のサービス実行部４２１にメッセージを出力する。

また、メッセージ判定部４２３３は、サービス実行部４２１が発行したメッセージの宛先を判定する。メッセージ分配部４２３４は、サービス実行部４２１により発行されたメッセージの宛先が連携端末５であるとメッセージ判定部４２３３により判定された場合、当該メッセージを通信入出力部４０６により連携端末５に送信する。また、メッセージ分配部４２３４は、サービス実行部４２１により発行されたメッセージの宛先が他のサービス実行部４２１であるとメッセージ判定部４２３３により判定された場合、当該メッセージを宛先と判定された他のサービス実行部４２１に出力する。

なお、サービス実行部４２１は、連携端末５において実行されるサービスアプリケーションにより提供されるサービスの識別子又は他のサービス実行部４２１において実行されるサービスの識別子を送信先の情報に設定したメッセージを発行してもよい。送信元サービス設定部４２３５は、サービス実行部４２１が発行したメッセージの送信元の情報に、当該メッセージを発行したサービス実行部４２１において実行されるサービスの識別子を設定する。このとき、メッセージ判定部４２３３は、送信元サービス設定部４２３５により送信元の情報が設定されたメッセージから取得した送信元のサービスの識別子及び送信先のサービスの識別子に基づき、メッセージの宛先が連携端末５であるか他のサービス実行部４２１であるかを判定してもよい。メッセージ分配部４２３４は、メッセージ判定部４２３３により判定された宛先にサービス実行部４２１により発行されたメッセージを出力する。

また、受信装置４は、サービス実行部４２１と連携端末５との間、又は、異なるサービス実行部４２１の間で通信チャンネルの確立及び解除を行う端末連携部４１２をさらに備えてもよい。この場合、メッセージ判定部４２３３は、連携端末５から受信したメッセージに設定されている通信チャンネルの識別情報に基づいてメッセージの宛先となるサービス実行部４２１を判定する処理と、サービス実行部４２１から発行されたメッセージに設定されている通信チャンネルの識別情報に基づいてメッセージの宛先が他のサービス実行部４２１であるか連携端末５であるかを判定する処理との少なくとも一方を行う。メッセージ分配部４２３４は、メッセージ判定部４２３３により判定された宛先に、サービス実行部４２１により発行されたメッセージを出力する。

以上説明した実施形態によれば、ハイブリッドキャストなどの放送通信連携サービスにおいて、放送マネージドアプリのように受信装置で実行されるアプリが1個（サービス提供者が一つ）、連携端末で実行されるアプリが複数個（サービス提供者が複数）ある場合でも、受信装置において実行される1個のアプリに対して連携端末において実行される複数個のアプリが連携することができる。これにより、現行のハイブリッドキャストの運用において、受信装置の実装を変えることなく、連携端末に実装するコンパニオンアプリ（端末側連携アプリ）を改修するだけで、複数のマルチスクリーンサービスを並列して実行することが可能になる。

また、メッセージの送信時に、メッセージ本体に送信先のサービス識別子を記述するだけで、受信装置または連携端末のいずれが送信先として適切であるかを判定し、送信することができる。これにより、アプリの制作者は、装置内と装置外を意識せず、サービス名を設定するような命令を記述するだけで、適切なアプリにメッセージを送信することができる。

なお、上述の受信装置４及び連携端末５は、内部にコンピュータシステムを有している。そして、受信装置４及び連携端末５の一部の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、ＣＰＵ及び各種メモリやＯＳ、周辺機器等のハードウェアを含むものである。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。

１…放送通信連携システム
２…放送送出装置
３…サービスサーバ
４…受信装置
５…連携端末
１０…ＩｏＴ機器（外部機器）
５１…ハードウェア部
５２…ＯＳ部
５３…連携アプリ実行制御部
５４…他アプリ実行制御部
４０１…放送受信部
４０２…分離部
４０３…映像復号部
４０４…音声復号部
４０５…データ放送実行部
４０６…通信入出力部
４０７…リモコン入力制御部
４０８…電源制御部
４０９…アプリ実行部
４１０…アプリ制御部
４１１…放送通信連携部
４１２…端末連携部
４１３…映像合成部
４１４…映像表示部
４１５…音声合成部
４１６…音声出力部
４２１…サービス実行部
４２２…サービス実行管理部
４２３…メッセージ制御部
５１１…通信入出力部
５１２…機器通信入出力部
５３１…端末連携部
５３２−１〜５３２−３…サービス実行部（アプリケーション実行部）
５３３…サービス実行管理部
５３４…メッセージ制御部
５３５…機器連携部
１０１１…アプリ実行部
１０３１…通信入出力部
４２３１…サービス識別管理部
４２３２…メッセージ受信部
４２３３…メッセージ判定部
４２３４…メッセージ分配部
４２３５…送信元サービス設定部
５３４１…サービス識別管理部
５３４２…メッセージ受信部
５３４３…メッセージ判定部
５３４４…メッセージ分配部
５３４５…送信元サービス設定部
５３５１…機器管理部
５３５２，５３５２−１，５３５２−２…機器通信部

Claims (5)

1. 放送信号を受信する機能を有する受信装置で稼働し、前記放送信号から分離されたデータに基づいて制御される受信装置側放送マネージドアプリケーションと連携動作する端末側アプリケーションを実行させるアプリケーション実行部と、
   通信機能を有する外部機器との間で通信を行う機器通信入出力部と、
   連携動作する前記受信装置側放送マネージドアプリケーション及び前記端末側アプリケーションの少なくともいずれかからのメッセージを、前記機器通信入出力部を介して送信する機器連携部と、
   送信先を識別するための送信先識別情報を含む前記メッセージを受け取り、前記送信先識別情報に基づいて前記メッセージを分配し、前記送信先識別情報が示す送信先が前記外部機器である場合には前記メッセージを前記外部機器に送信するために前記機器連携部に渡すメッセージ制御部と、
   を備える端末装置。
2. 前記機器連携部は、前記機器通信入出力部を介して前記外部機器からのメッセージを受信し、
   前記メッセージ制御部は、前記機器連携部が受信した前記外部機器からの前記メッセージに含まれる送信先識別情報に基づいて、前記メッセージを前記受信装置側放送マネージドアプリケーションまたは前記端末側アプリケーションのいずれかの送信先に分配する、
   ことを特徴とする請求項１に記載の端末装置。
3. 前記機器連携部は、前記メッセージに含まれるサービス識別情報が示すサービスを前記外部機器が受け入れるか否かを表す情報を前記外部機器の属性に対応付けて保持する機器利用可能サービス表を記憶し、前記サービス識別情報に基づいて前記メッセージを前記外部機器に送信するか否かを判断する、
   ことを特徴とする請求項１または２に記載の端末装置。
4. 前記機器通信入出力部は、前記外部機器との間で用いられる通信プロトコルの種類毎に存在し、
   前記機器連携部は、使用する通信プロトコルに応じた前記機器通信入出力部を介して前記メッセージを前記外部機器に送信する、
   ことを特徴とする請求項１から３までのいずれか一項に記載の端末装置。
5. コンピュータを、請求項１から４までのいずれか一項に記載の端末装置として機能させるためのプログラム。

Images