JP6873762B2 - 通信装置、通信システム、通信方法、および、プログラム - Google Patents

Description

本発明は、複数装置間の通信に関する。

近年、通信装置が表示している画面や再生している音声をワイヤレスでミラーリングする技術がＷｉ−Ｆｉ Ｄｉｓｐｌａｙ（Ｍｉｒａｃａｓｔ）として標準化されている。ミラーリングとは、送信装置が表示している画面や再生している音声の情報を、ネットワークを介して受信装置へ伝送することで、表示している画面や再生している音声を送信装置と受信装置とで共有する技術である。Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙでは、表示している画面や再生している音声の情報を送信するソース機器と、ソース機器から画面や音声の情報を受信するシンク機器とが定められている。

特許文献１には、上述したミラーリング機能と、シンク機器がソース機器以外の外部装置からコンテンツを取得して表示するコンテンツリダイレクト機能とについて開示されている。コンテンツリダイレクト機能では、ソース機器がシンク機器に外部装置が有するコンテンツの情報を送信し、シンク機器が外部装置からコンテンツを取得して再生する。

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

しかし、特許文献１では、シンク機器におけるコンテンツリダイレクト機能を制御するためには、ユーザがソース機器を操作して、ソース機器からシンク機器に指示情報を送信する必要があった。ここで、ソース機器は、シンク機器におけるコンテンツリダイレクトの状態（例えば再生中、終了、エラーなど）を把握していないため、コンテンツリダイレクトの状態に応じた制御を自律的に行うことができなかった。従って、ユーザがシンク機器におけるコンテンツリダイレクトの状態を把握して、適切にソース機器を操作する必要があった。

上述の課題を鑑み、本発明は、外部装置が有するコンテンツの情報を送信する装置が、当該情報の送信先における当該コンテンツの再生処理に関する状態に応じた制御を自律的に行えるようにすることを目的とする。

上記目的を達成するため、本発明の通信装置は、前記通信装置が表示している画面の画面データあるいは再生している音声の音声データとの少なくとも一方を他の通信装置に送信する第１の送信手段と、外部装置が有するコンテンツの関連情報を前記他の通信装置に送信する第２の送信手段と、前記第１の送信手段によって前記他の通信装置に前記画面データあるいは前記音声データの少なくとも一方を送信している際に前記第２の送信手段によって前記関連情報を送信した場合、前記第１の送信手段による送信を停止する停止手段と、前記第２の送信手段によって前記関連情報を送信した場合に、前記関連情報に基づいて前記他の通信装置において行われる前記コンテンツの再生処理に関する状態の情報を前記他の通信装置から受信する受信手段と、前記受信手段により前記情報として前記コンテンツの再生処理が終了したことを示す情報を受信した場合に前記第１の送信手段による送信を再開するか否かを選択するユーザ操作を受け付ける受付手段と、前記受付手段によって前記第１の送信手段による送信を再開することを選択するユーザ操作を受け付けた場合は、前記第１の送信手段による送信を再開するように制御し、前記受付手段によって前記第１の送信手段による送信を再開しないことを選択するユーザ操作を受け付けた場合は、前記第１の送信手段による送信を再開しないように制御する制御手段と、を有する。

本発明によれば、外部装置が有するコンテンツの情報を送信する装置が、当該情報の送信先における当該コンテンツの再生処理に関する状態に応じた制御を自律的に行えるようになる。

通信システムのネットワーク構成を示す図である。 通信装置１０１、通信装置１０２のハードウェア構成を示す図である。 通信装置１０１と通信装置１０２がコンテンツリダイレクトを実施する際に実現するフローチャートである。 通信装置１０２が通信装置１０１にコンテンツリダイレクトの状態の情報を通知する際に実現するフローチャートである。 通信装置１０２が通信装置１０１にコンテンツリダイレクトの状態の情報を通知する際に実現する他のフローチャートである。 通信装置１０１が表示する表示画面を示す図である。

以下、添付の図面を参照して実施形態を詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

図１に本実施形態に係る通信システムのネットワーク構成を示す。ネットワーク１１０上では、各装置はＩＥＥＥ８０２．１１シリーズ規格に準拠した無線通信方式で通信を行う。本実施形態において、通信装置１０１と通信装置１０２とは直接通信する。しかしこれに限らず、アクセスポイント１０３を介して通信してもよい。

なお、ネットワーク１１０上で、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離無線通信、ＵＷＢ（Ｕｌｔｒａ Ｗｉｄｅ Ｂａｎｄ）、ＺｉｇＢｅｅ、ＭＢＯＡなどの他の無線通信方式に準拠した通信方式も利用してもよい。近距離無線通信としては、Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ（以下ＮＦＣと称す）がある。ここで、ＭＢＯＡは、Ｍｕｌｔｉ Ｂａｎｄ ＯＦＤＭ Ａｌｌｉａｎｃｅの略である。また、ＵＷＢには、ワイヤレスＵＳＢ、ワイヤレス１３９４、ＷｉＮＥＴなどが含まれる。また、有線ＬＡＮなどの有線通信方式に準拠した通信方式も適用可能である。

ここで、本実施形態では、通信装置１０１と通信装置１０２は、通信装置１０１を送信装置、通信装置１０２を受信装置として、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ仕様に基づいたミラーリングを行う。このとき、送信装置および受信装置は夫々Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ仕様に基づいてデータの送信処理及び受信処理を行う。なお、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙに限らず他の通信方式を用いてミラーリングを行ってもよい。Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ仕様に基づいたミラーリングでは、ソース機器が表示している画面や再生している音声の情報を、ネットワークを介してシンク機器へ伝送する。そして、シンク機器は受信した画面の表示や、受信した音声をソース機器と同期して、再生する。つまり、表示している画面や再生している音声を送信装置と受信装置とで共有して再生する。本実施形態において、通信装置１０１は自装置が表示している画面や再生している音声の情報を通信装置１０２へ送信する。また、通信装置１０２は通信装置１０１から送信される通信装置１０１に表示されている画面や再生している音声の情報を受信して再生する。即ち、通信装置１０１は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙにおけるソース機器の役割を担い、通信装置１０２はシンク機器の役割を担う。

本実施形態ではＷｉ−Ｆｉ Ｄｉｓｐｌａｙ仕様に従い、通信装置１０１と通信装置１０２の間の無線接続にＷｉ−Ｆｉ Ｐ２Ｐ（Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ）を用いる。ここで、Ｐ２ＰとはＰｅｅｒ−ｔｏ−Ｐｅｅｒの略である。しかし、これに限らずＩＥＥＥ８０２．１１シリーズに規定されたインフラストラクチャモードなどによる無線接続を行ってもよい。

通信装置１０１の具体的な例としては、タブレット、スマートフォン、ＰＣ、携帯電話、カメラ、ビデオカメラなどの入力装置が挙げられるが、これらに限定されない。また、通信装置１０２の具体的な例としては、タブレット、スマートフォン、ＰＣ、携帯電話、テレビ、ヘッドマウントディスプレイ、プロジェクター、ディスプレイ、カーナビゲーション装置などの出力装置が挙げられるが、これらに限定されない。

通信装置１０１（ソース機器）と通信装置１０２（シンク機器）とはコンテンツリダイレクト機能を利用できる。コンテンツリダイレクト機能では、ソース機器はシンク機器に、ソース機器以外の外部装置からコンテンツを取得させ、シンク機器に当該コンテンツを再生させる。また、ソース機器は、シンク機器にコンテンツを外部装置から取得させるために必要な情報を送信する。

本実施形態では、当該必要な情報として、通信装置１０１はクラウドサーバ１０４上にあるコンテンツの情報（例えばコンテンツ識別子、コンテンツの所在情報（ＵＲＩ、ＵＲＬなど））を通信装置１０２へ送信する。ここでコンテンツ識別子とは、コンテンツを一意に決定するための識別子のことである。また、ＵＲＩはＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒの、ＵＲＬはＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒの夫々、略である。通信装置１０２は通信装置１０１から受信したコンテンツの情報を基に、ルーター機能を備えたアクセスポイント１０３を介してクラウドサーバ１０４上にあるコンテンツを受信して再生する。

図２に、通信装置１０１のハードウェア構成を示す。

通信装置１０１は、記憶部２０１、制御部２０２、機能部２０３、入力部２０４、出力部２０５、通信部２０６、および、アンテナ２０７を備える。

記憶部２０１はＲＯＭやＲＡＭなどのメモリにより構成され、後述する各種動作を行うためのプログラムや、無線通信のための通信パラメータなどの各種情報を記憶する。なお、記憶部２０１として、ＲＯＭ、ＲＡＭなどのメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体を用いてもよい。また、記憶部２０１が複数のメモリなどを備えていてもよい。

制御部２０２はＣＰＵやＭＰＵなどのプロセッサにより構成され、記憶部２０１に記憶されたプログラムを実行することにより、通信装置１０１全体を制御する。また、制御部２０２は、記憶部２０１に記憶されたプログラムを実行することで、ソース機器としてのミラーリング機能、および、コンテンツリダイレクト機能を実現する。ここで、ソース機器としてのミラーリング機能とは、自装置が表示している画面をキャプチャし符号化した画面データや、符号化した音声データをシンク機器に送信する機能である。また、ソース機器としてのコンテンツリダイレクト機能とは、シンク機器で再生したいコンテンツを、シンク機器がソース機器以外の外部装置から取得するために必要な情報をシンク機器に送信する機能である。なお、制御部２０２は、記憶部２０１に記憶されたプログラムとＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）との協働により通信装置１０１全体を制御するようにしてもよい。また、制御部２０２がマルチコアなどの複数のプロセッサを備え、複数のプロセッサにより通信装置１０１全体を制御するようにしてもよい。

また、制御部２０２は、機能部２０３を制御して、撮像やコンテンツの閲覧などの所定の処理を実行する。機能部２０３は、通信装置１０１が所定の処理を実行するためのハードウェアである。例えば、通信装置１０１がカメラである場合、機能部２０３は撮像部であり、撮像処理を行う。このとき、撮像部が生成したデータは、出力部２０５によって画面上に表示され、制御部２０２のミラーリング機能によって他の通信装置に送信されることでミラーリングが実行される。

入力部２０４は、ユーザからの各種操作の受付を行う。出力部２０５は、モニタ画面やスピーカーなどを介してユーザに対して各種出力を行う。ここで、出力部２０５による出力とは、画面上への表示の他、スピーカーによる音声出力や、振動出力などであってもよい。なお、タッチパネルのように入力部２０４と出力部２０５の両方を１つのモジュールで実現するようにしてもよい。

通信部２０６は、ＩＥＥＥ８０２．１１シリーズに準拠した無線通信の制御や、有線ＬＡＮなどの有線通信の制御、ＩＰ通信の制御を行う。また、通信部２０６はアンテナ２０７を制御して、無線通信のための無線信号の送受信を行う。通信装置１０１は通信部２０６を介して、画像データ、文書データ、音声データ、映像データなどのコンテンツを通信装置１０２と通信する。

通信装置１０２は通信装置１０１と同様のハードウェア構成を有する。通信装置１０２の記憶部２０１、機能部２０３、入力部２０４、出力部２０５、通信部２０６、および、アンテナ２０７は通信装置１０１と同様であるため説明を省略する。

通信装置１０２の制御部２０２はＣＰＵやＭＰＵなどのプロセッサにより構成され、記憶部２０１に記憶されたプログラムを実行することにより通信装置１０２全体を制御する。また、通信装置１０２の制御部２０２は、記憶部２０１に記憶されたプログラムを実行することで、シンク機器としてのミラーリング機能、および、コンテンツリダイレクト機能を実現する。ここで、シンク機器としてのミラーリング機能とは、ソース機器が表示している画面のキャプチャである符号化された画面データや符号化された音声データを受信し、復号、再生する機能である。また、シンク機器としてのコンテンツリダイレクト機能とは、ソース機器から送られた情報を元にソース機器以外から再生したいコンテンツを取得し、再生する機能である。なお、通信装置１０２の制御部２０２は、記憶部２０１に記憶されたプログラムとＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）との協働により通信装置１０２全体を制御するようにしてもよい。また、通信装置１０２の制御部２０２がマルチコアなどの複数のプロセッサを備え、複数のプロセッサにより通信装置１０２全体を制御するようにしてもよい。

なお、本実施形態において通信装置１０１および通信装置１０２は、画像の表示と音声の再生のどちらも行える装置となっている。しかし、通信装置１０１と通信装置１０２のどちらも、画像の表示か音声の再生のどちらかしか行えない装置であってもよい。

続いて、図３に、通信装置１０１と通信装置１０２がコンテンツリダイレクトを実施する際の通信装置１０１、１０２が実現するフローチャートを示す。夫々、（ａ）が通信装置１０１により、また、（ｂ）が通信装置１０２により実現されるフローチャートである。

（ａ）に示すフローチャートは、通信装置１０１の記憶部２０１に記憶されたプログラムを制御部２０２が読み出して、実行することで実現される。また、（ｂ）に示すフローチャートは、通信装置１０２の記憶部２０１に記憶されたプログラムを制御部２０２が読み出して、実行することで実現される。

なお、図３に示すフローチャートの少なくとも一部または全部をハードウェアにより実現してもよい。ハードウェアにより実現する場合、例えば、所定のコンパイラを用いることで、各ステップを実現するためのプログラムからＦＰＧＡ上に専用回路を生成し、これを利用すればよい。ＦＰＧＡとは、Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙの略である。また、ＦＰＧＡと同様にしてＧａｔｅ Ａｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。また、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）により実現するようにしてもよい。

本フローチャートの（ａ）は、ソース機器（通信装置１０１）の電源が入ることで開始される。なお、ソース機器において所定のアプリケーションが起動したことに応じて開始するようにしてもよい。また、（ｂ）はシンク機器（通信装置１０２）の電源が入ることで開始される。なお、シンク機器において所定のアプリケーションが起動したことに応じて開始するようにしてもよい。

まず、ソース機器は、ユーザにより入力部２０４から画面・音声共有の開始操作が行われたかを判定する（ステップＳ３０１）。開始操作とは、例えば、ユーザによる画面・音声共有を開始するための制御ボタンの押下である。開始操作が行われないと（ステップＳ３０１のいいえ）、再度ステップＳ３０１の判定を行う。

開始操作が行われると（ステップＳ３０１のはい）、ソース機器とシンク機器間においてデバイス探索が行われる。具体的には、ソース機器は、デバイス発見要求としてＩＥＥＥ８０２．１１シリーズに準拠したＰｒｏｂｅ Ｒｅｑｕｅｓｔを送信する（ステップＳ３０２）。当該信号を受信したシンク機器は、当該信号に対する応答としてＩＥＥＥ８０２．１１シリーズに準拠したＰｒｏｂｅ Ｒｅｓｐｏｎｓｅを送信する（ステップＳ３０３）。これにより、ソース機器とシンク機器は互いを発見する。そして、ソース機器において発見されたデバイスの一覧が表示され、デバイス一覧から、接続相手装置（シンク機器）が選択される（ステップＳ３０４）。

なお、シンク機器がＰｒｏｂｅ Ｒｅｑｕｅｓｔを送信し、ソース機器がＰｒｏｂｅ Ｒｅｓｐｏｎｓｅを送信することで、互いを発見するようにしてもよい。また、接続相手装置の選択を、シンク機器において行ってもよい。

またデバイス探索に用いられる信号は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ仕様に基づき、ＩＥＥＥ８０２．１１シリーズに準拠したＢｅａｃｏｎなどの無線信号でもよい。また、ＮＦＣ、ＱＲコード（登録商標）、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）などを利用することで、ソース機器が接続相手装置を発見することも可能である。例えば、ソース機器がＮＦＣの通信機能を有しているとき、ソース機器とシンク機器とのペアリングをＮＦＣタッチ操作で行い、以降の通信はＷｉ−Ｆｉ Ｄｉｓｐｌａｙ規格に基づいて行うことも可能である。

ここで、ステップＳ３０５、ステップＳ３０６に進む前に、ソース機器とシンク機器はサービス探索を行っても良い。サービス探索はＷｉ−Ｆｉ Ｐ２Ｐ仕様に基づいて行われる。このサービス探索を行うことで、ソース機器とシンク機器の少なくとも一方は相手装置が提供するサービスについての情報を得ることができる。

次にソース機器は、ステップＳ３０４で選択した相手装置であるシンク機器と接続セットアップを行う（ステップＳ３０５）。このとき同時にシンク機器も、ソース機器との接続セットアップを行う（ステップＳ３０６）。具体的にはＷｉ−Ｆｉ Ｄｉｓｐｌａｙの接続処理を行い、その後、ＴＣＰの接続処理を行う。これらの接続処理を行うことにより、接続セットアップが完了する。ＴＣＰとはＴｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌの略である。

Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ接続を確立させる方法として、２種類の方法、即ち、Ｗｉ−Ｆｉ Ｐ２ＰまたはＴＤＬＳから選ぶことができるが、本実施形態ではＷｉ−Ｆｉ Ｐ２Ｐ仕様に従って行う。ここで、ＴＤＬＳはＴｕｎｎｅｌｅｄ Ｄｉｒｅｃｔ Ｌｉｎｋ Ｓｅｔｕｐの略である。

ここで、ステップＳ３０５とステップＳ３０６の詳細な手順について説明する。まず、シンク機器からソース機器にＰｒｏｂｅ Ｒｅｑｕｅｓｔが送信される。Ｐｒｏｂｅ Ｒｅｑｕｅｓｔを受け取ったソース機器はシンク機器に対してＰｒｏｂｅ Ｒｅｓｐｏｎｓｅを送信する。これにより、ソース機器とシンク機器は相手装置の存在を確認する。続いてＧＯを決定するため、ソース機器はＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔを送信する。この信号にはソース機器のＩｎｔｅｎｔ値が含まれる。ＧＯはＧｒｏｕｐ Ｏｗｎｅｒの略であり、ＧＯになった機器はＷｉ−Ｆｉ Ｐ２Ｐの無線通信でアクセスポイントと同様の役割を担う。ＧＯにならなかった機器はＣｌｉｅｎｔになりステーションの役割を担う。

ＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔに対する応答としてシンク機器からはＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅが送られる。この信号にはシンク機器のＩｎｔｅｎｔ値が含まれる。各装置は、シンク機器とソース機器の各々のＩｎｔｅｎｔ値の大小を比較し、Ｉｎｔｅｎｔ値の大きかった方の機器がＧＯとなる。本実施形態ではソース機器がＧＯになったとする。なお、シンク機器がＧＯとなっても良い。最後にソース機器からシンク機器にＧＯ Ｎｅｇｏｔｉａｔｉｏｎ Ｃｏｎｆｉｒｍが送られることで、ソース機器、シンク機器の役割が、それぞれＧＯ、Ｃｌｉｅｎｔのいずれになるかが決定する。ここでは、ソース機器がＧＯ、シンク機器がＣｌｉｅｎｔとして決定したものとする。

その後、ＷＰＳ方式を用いて接続やセキュリティに関する情報など、ソース機器とシンク機器間のネットワーク接続を確立するために必要なパラメータ情報を共有する。なお、ＷＰＳはＷｉ−Ｆｉ Ｐｒｏｔｅｃｔｅｄ Ｓｅｔｕｐの略である。そして、交換したパラメータ情報に基づいて、Ｃｌｉｅｎｔであるシンク機器がＧＯであるソース機器へ、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔを送信する。当該信号を受信したソース機器が、応答としてＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅを送信する。

以上のようにして、ソース機器シンク機器との間で、Ｗｉ−Ｆｉ Ｐ２Ｐ仕様に従ったＷｉ−Ｆｉ Ｄｉｓｐｌａｙ接続、即ち、Ｗｉ−Ｆｉ Ｐ２Ｐ接続が確立する。なお、上記で挙げた各無線信号を送信する機器について、シンク機器とソース機器の役割（ＧＯとＣｌｉｅｎｔ）を入れ替えても良い。また、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ接続を確立させるにあたっては、上記に挙げたもの以外の無線信号を用いても良い。具体的には、Ｂｅａｃｏｎ、Ｒｅａｓｓｏｃｉａｔｉｏｎメッセージ、Ｐ２Ｐ Ｉｎｖｉｔａｔｉｏｎメッセージ、Ｐｒｏｖｉｓｉｏｎ Ｄｉｓｃｏｖｅｒｙメッセージ等を用いても良い。

続いて、ソース機器シンク機器との間でＴＣＰ接続を確立する。この接続はソース機器がＴＣＰサーバの、シンク機器がＴＣＰクライアントの役割を担い、３ Ｗａｙ Ｈａｎｄ Ｓｈａｋｅを行うことで確立される。

このように、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ接続の確立とＴＣＰ接続が確立されたことにより、接続セットアップが完了する。

続いてソース機器は、Ｃａｐａｂｉｌｉｔｙ Ｎｅｇｏｔｉａｔｉｏｎを行う（ステップＳ３０７）。同様にシンク機器もＣａｐａｂｉｌｉｔｙ Ｎｅｇｏｔｉａｔｉｏｎを行う（ステップＳ３０８）。Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ仕様では、Ｃａｐａｂｉｌｉｔｙ ＮｅｇｏｔｉａｔｉｏｎにはＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）を利用するよう規定されている。ＲＴＳＰはストリーミングを制御するためのプロトコルである。また、下位層のトランスポートプロトコルとしては一般的にＴＣＰが用いられる。Ｃａｐａｂｉｌｉｔｙ ＮｅｇｏｔｉａｔｉｏｎにはＲＴＳＰ Ｍ１〜Ｍ４までの所定のメッセージがソース機器、シンク機器間で交換される。このＲＴＳＰメッセージの交換によって、ソース機器はシンク機器の能力情報を得て、使用するパラメータを決定し、シンク機器へ通知する。シンク機器は、通知されたパラメータを設定する。具体的な能力情報とは、例えば画面については、対応する画面の解像度、フレームレート、コーデックなどの情報である。また音声については、対応するコーデックやサンプリング周波数などの情報である。本ステップのＣａｐａｂｉｌｉｔｙ Ｎｅｇｏｔｉａｔｉｏｎの結果、ソース機器とシンク機器の間でミラーリング時に使用する画面や音声の符号化方式の種類や映像の解像度、フレームレートなどが決定される。なお、送受信する能力情報は、これらの情報の一部であってもよい。

Ｃａｐａｂｉｌｉｔｙ Ｎｅｇｏｔｉａｔｉｏｎが完了すると、ソース機器は、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙのセッションを確立する（ステップＳ３０９）。同様にシンク機器もＷｉ−Ｆｉ Ｄｉｓｐｌａｙのセッションを確立する（ステップＳ３１０）。Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ仕様では、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙのセッションの確立にはＲＴＳＰ Ｍ５〜Ｍ７までの所定のメッセージがソース機器とシンク機器間で交換される。これらのＲＴＳＰメッセージの交換によって、使用するポート番号の設定などが行われ、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙのセッションが確立される。

ステップＳ３０９、Ｓ３１０までのＲＴＳＰメッセージ交換を終えると、ソース機器でミラーリング処理が行われる（ステップＳ３１１）。ソース機器におけるミラーリング処理は、例えば、表示されている画面のキャプチャ、キャプチャ画像の符号化、多重化、データ送信処理である。同様に、シンク機器でもミラーリング処理が行われる（ステップＳ３１２）。シンク機器におけるミラーリング処理は、例えば、データ受信、逆多重化、キャプチャ画像の復号化、復号されたキャプチャ画像の再生処理である。これらの処理が行われることで、ソース機器からシンク機器へ、ソース機器に表示されている画面や再生している音声の情報のストリーム（画面・音声ストリーム）が送信される。

なお、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ仕様では、画面・音声ストリーム用のプロトコルとしてＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）を用いる。ＲＴＰは動画像や音声などのマルチメディアデータを、ネットワークを介してリアルタイムに送受信するためのプロトコルであり、下位層のトランスポートプロトコルとしてＵＤＰを利用する。なおＵＤＰとはＵｓｅｒ Ｄａｔａ Ｐｒｏｔｏｃｏｌの略である。

続いて、ソース機器でユーザにより入力部２０４からコンテンツリダイレクトの開始指示が出されたかを判定する（ステップＳ３１３）。ここで、コンテンツリダイレクトの開始指示は、例えば、ソース機器で、コンテンツリダイレクトのサービス対象とされているコンテンツ（クラウドサーバ１０４上にあるコンテンツ）をユーザが選択するなどの操作が考えられる。あるいはシンク機器がコンテンツを特定するために必要な情報をユーザが入力するといった操作も開始指示となる。またコンテンツ再生中にユーザが特定の操作を行うことで開始指示が出されたとしても良い。

ユーザからコンテンツリダイレクトの開始が指示されていない場合（ステップＳ３１３のいいえ）、ステップＳ３１１に戻り、ソース機器はミラーリング処理を継続する。ユーザからコンテンツリダイレクトの開始が指示された場合（ステップＳ３１３のはい）、ソース機器はシンク機器へコンテンツリダイレクト機能をサポートしているか問合せる（ステップＳ３１４）。問合せを受け取ったシンク機器は、その応答として、コンテンツリダイレクト機能への対応の是非や、シンク機器がコンテンツリダイレクト機能よって再生できる動画共有サービス名などの情報をソース機器へ通知する（ステップＳ３１５）。

次に、ソース機器は、シンク機器がコンテンツリダイレクト機能をサポートしているか否かを判定する（ステップＳ３１６）。ここでの判定は、前述のステップＳ３１５でシンク機器から送信された応答の内容から判定すればよい。

ステップＳ３１６の判定の結果、シンク機器がコンテンツリダイレクト機能をサポートしていないと判定した場合（ステップＳ３１６のいいえ）、ソース機器はステップＳ３１１へと処理を戻し、画面・音声ストリームの送信を継続する。このとき、ソース機器とシンク機器の少なくとも一方は、シンク機器がコンテンツリダイレクト機能をサポートしていないことをユーザに通知しても良い。

一方、ステップＳ３１６でシンク機器がコンテンツリダイレクト機能をサポートしていると判定した場合（ステップＳ３１６のはい）、ソース機器はシンク機器へコンテンツの情報を通知する（ステップＳ３１７）。シンク機器は、ソース機器から送信されたコンテンツ情報を受信する（ステップＳ３１８）。ここで送受信するコンテンツの情報は、例えば、クラウドサーバ１０４上にあるコンテンツを識別するための識別子や、サービス名、コンテンツの所在情報（ＵＲＩ、ＵＲＬ）、再生開始時間（オフセット）などの情報である。なお、送受信するコンテンツの情報は、これらの情報の一部であってもよい。

前述したステップＳ３１８までの処理で、コンテンツリダイレクトの開始準備が整ったソース機器は、実行中のミラーリング処理を一時停止して、画面等の送信を制限する（ステップＳ３１９）。同様に、シンク機器も実行中のミラーリング処理を一時停止する（ステップＳ３２０）。ミラーリングを実行中にコンテンツリダイレクトを実施する場合、ミラーリング処理を一時停止することにより、ソース機器とシンク機器各々におけるミラーリングの処理負荷を軽減し、消費電力を抑えることが可能である。

なお、ミラーリング処理の一時停止は、ステップＳ３１７とステップＳ３１８で行われるコンテンツ情報の送受信としてのメッセージ交換を契機に行う。

続いて、シンク機器はステップＳ３１８で受信したコンテンツ情報を基に、クラウドサーバ１０４からコンテンツを受信し、再生する（ステップＳ３２１）。ここでは、シンク機器はアクセスポイント１０３を介してクラウドサーバ１０４からコンテンツを受信する。

また、ここでのコンテンツ受信の方法やプロトコルは、コンテンツの種類やサービスの種類によって様々である。例えばＨＬＳ方式やＨＴＴＰのＧＥＴメソッドなどを用いてもよい。ここでＨＬＳとはＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇの、ＨＴＴＰはＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌの夫々略である。

コンテンツリダイレクトによるコンテンツの受信と再生を開始したシンク機器は、ステップＳ３２２に進む。このステップでは、シンク機器はコンテンツリダイレクトの状態を検知し、ソース機器に当該状態の情報を通知する。このときソース機器は、ステップＳ３２３でシンク機器からコンテンツリダイレクトの状態の情報を受信する。そして、シンク機器とソース機器の夫々でコンテンツリダイレクトの状態に応じた所定の制御を行う。なお、ステップＳ３２２、及びステップＳ３２３における処理の詳細は、後述する図４、５で説明する。

続いてソース機器とシンク機器はミラーリングが終了したかを夫々、判定する（ステップＳ３２４、ステップＳ３２５）。なお、ミラーリングは夫々ステップＳ３２２、Ｓ３２３において終了し得る。

ミラーリングが終了したと判定されると、ソース機器は図３に示すフローチャートを終了する（ステップＳ３２４のはい）。同様に、シンク機器も図３に示すフローチャートを終了する（ステップＳ３２５のはい）。

ミラーリングが終了していないと判定されると、ソース機器はステップＳ３１１に戻り、一時停止していたミラーリング処理を再開する（ステップＳ３２４のいいえ）。同様の場合、シンク機器はステップＳ３１２に戻り、一時停止していたミラーリング処理を再開する（ステップＳ３２５のいいえ）。

以上、図３のフローチャートには、コンテンツリダイレクトを実行する際、ソース機器とシンク機器が実現する処理を示した。

図４及び図５では、前述の図３のステップＳ３２２、Ｓ３２３で行われる処理について説明する。図４及び図５では、シンク機器はコンテンツリダイレクトの状態を検知し、ソース機器に当該状態の情報を通知する。そしてシンク機器とソース機器はコンテンツリダイレクトの状態に応じて夫々所定の制御を行う。また、図６は図４及び図５でソース機器が表示する表示画面の一例である。

図４の（ａ）、（ｂ）は、夫々図３のステップＳ３２３、ステップＳ３２２に相当するフローチャートである。

まず、シンク機器はコンテンツリダイレクトの状態を監視する（ステップＳ４０１）。そして、シンク機器はソース機器へ通知すべきコンテンツリダイレクトの状態を検知したかを判定する（ステップＳ４０２）。具体的には、コンテンツを再生しているシンク機器内の再生アプリケーション（例えばブラウザやプレーヤーなど）がコンテンツリダイレクトの状態を監視し、判定する。

ここでコンテンツリダイレクトの状態とは、コンテンツの再生処理に関する状態である。具体的には、シンク機器からのユーザ操作によるコンテンツリダイレクトの状態や、コンテンツの再生に関する状態、コンテンツの受信に関する状態などである。

それぞれ具体的に説明する。まずシンク機器からのユーザ操作によるコンテンツリダイレクトの状態とは、ユーザからシンク機器の入力部２０４によってコンテンツリダイレクトに対する制御が行われたときのコンテンツリダイレクトの状態である。例えば、シンク機器にユーザからコンテンツリダイレクトを一時停止させる操作が入力されると、コンテンツリダイレクトは一時停止する。シンク機器はコンテンツリダイレクトを一時停止させるユーザ操作が入力されたことを検知する。ここではユーザ操作の例として一時停止を用いたが、他に停止、終了、再生、早送り、巻き戻しなど、他の再生制御指示であってもよい。

また、コンテンツの再生に関する状態とは、コンテンツが再生されているときのコンテンツリダイレクトの状態である。例えば、コンテンツの再生が開始されると、シンク機器は再生が開始されてから経過した時間を検知し、ソース機器に通知する。シンク機器は経過時間以外にも、再生速度、再生方向、再生位置、音声出力レベル、再生エラー番号、コンテンツの再生終了などを検知する。ここでコンテンツの再生終了とは、コンテンツが終端まで再生された場合をさす。他にも、複数のコンテンツが連続で再生されるように設定されているか、一つのコンテンツを繰り返し再生するように設定されているかを検知してもよい。なお、再生エラー番号とは、コンテンツの再生に関して何かエラーが起きたとき、そのエラーの種別や内容を表す番号である。

最後にコンテンツの受信に関する状態とは、コンテンツが受信されているときのコンテンツリダイレクトの状態である。例えば、シンク機器がコンテンツをダウンロードしているとき、シンク機器はダウンロードが完了するまでの推定残り時間を検知する。シンク機器は他に、ダウンロードの進捗状況や受信エラー番号などを検知してもよい。なお、受信エラー番号とは、コンテンツの受信に関してエラーが起きたとき、そのエラーの種別や内容を表す番号である。コンテンツリダイレクトのエラー原因としては、クラウドサーバ１０４の障害や、シンク機器がクラウドサーバ１０４に接続できたもののコンテンツを見つけられない場合、認証エラー、タイムアウト、その他通信障害など、様々な原因が考えられる。

また、ソース機器へ通知すべきコンテンツリダイレクトの状態を検知したと判定する場合とは、シンク機器へのユーザ操作等によりコンテンツリダイレクトの状態が変わった場合である。しかしこれに限らず、コンテンツの再生が終了した場合、再生あるいは受信エラーが発生した場合、またはコンテンツリダイレクトを開始してから終了するまでの間の所定の時間が経過するごとの何れであってもよい。

なお、複数のコンテンツが連続で再生されるように設定されている場合、コンテンツの再生が終了した場合というのは、一つのコンテンツの再生が終了したときでもよいし、全てのコンテンツの再生が終了したときでもよい。あるいは任意のコンテンツの再生が終了したときでもよい。また、コンテンツが繰り返し再生されるように設定されている場合は、コンテンツが一回再生され終わったときをコンテンツの再生が終了したタイミングとしてもよいし、任意の回数再生され終わったときとしてもよい。

シンク機器はソース機器へ通知すべきコンテンツリダイレクトの状態を検知すると（ステップＳ４０２のはい）、ソース機器にコンテンツリダイレクトの状態の情報を通知し（ステップＳ４０３）、ステップＳ４０６に進む。シンク機器はソース機器へ通知すべきコンテンツリダイレクトの状態を検知しないと（ステップＳ４０２のいいえ）、前述の図３のステップＳ３２１に戻り、コンテンツの受信と再生を続ける。

ソース機器は、ステップＳ４０４でコンテンツリダイレクトの状態の情報をシンク機器から通知されたか判定する。コンテンツリダイレクトの状態の情報を通知されていないと（ステップＳ４０４のいいえ）、ステップＳ４０４にもどる。コンテンツリダイレクトの状態の情報を通知されていると（ステップＳ４０４のはい）、ステップＳ４０５に進む。

ソース機器はステップＳ４０５に進むと、コンテンツリダイレクトの終了を判定する。コンテンツリダイレクトの終了とは、シンク機器におけるユーザ操作に基づくコンテンツリダイレクトの終了や、コンテンツが終端に達したことによるコンテンツの再生終了、あるいはコンテンツの再生エラーや受信エラーといったエラーが発生した場合を指す。ここでソース機器はこの判定をステップＳ４０４で受けた通知に基づいて行う。また、シンク機器もステップＳ４０６に進むと、コンテンツリダイレクトの終了を判定する。なお、シンク機器はステップＳ４０２で検知した結果に基づいて、この判定を行う。

シンク機器はコンテンツリダイレクトの終了を判定すると（ステップＳ４０６のはい）、コンテンツリダイレクトの終了がシンク機器におけるユーザ操作によるものかを判定する（ステップＳ４０７）。ユーザ操作によるコンテンツリダイレクトの終了の場合（ステップＳ４０７のはい）、シンク機器はクラウドからのコンテンツの受信を終了する（ステップＳ４０８）。そして、ステップＳ４１２に進む。

ユーザ操作によるコンテンツリダイレクトの終了でない場合（ステップＳ４０７のいいえ）、シンク機器はステップＳ４１２に進む。ユーザ操作によるコンテンツリダイレクトの終了でない場合とは、例えば、コンテンツが終端に達したことによるコンテンツの再生終了、あるいはエラーによりコンテンツリダイレクトが終了した場合である。

ソース機器はコンテンツリダイレクトの終了ではないと判定すると（ステップＳ４０５のいいえ）、ソース機器はコンテンツリダイレクトの状態を出力部２０５の再生制御ＵＩ表示へ反映する（ステップＳ４０９）。具体的には、ソース機器がシンク機器からコンテンツリダイレクトの状態の情報の通知を受けた場合に、ソース機器は図６（ｄ）に示すコンテンツリダイレクト状態表示６０４を表示する。コンテンツリダイレクト状態表示６０４には、相手装置であるシンク機器におけるコンテンツリダイレクトの状態を再生制御のユーザーインターフェースへ反映して表示する。

このようにソース機器はシンク機器におけるコンテンツリダイレクトの状態を検知することができる。また、ユーザはソース機器における図６（ｄ）のコンテンツリダイレクト状態表示６０４から、コンテンツリダイレクトの状態を知ることができる。

また、ソース機器において、ユーザがソース機器の操作部からコンテンツリダイレクトの再生制御（例えば、早送り、巻き戻し、一時停止等）を行うことを許可し、操作部を介して為されたユーザ操作をソース機器からシンク機器へ通知するようにしてもよい。この場合、シンク機器は、ソース機器からの通知に従ってコンテンツリダイレクトの処理を行う。これにより、ユーザは、ソース機器の操作部からコンテンツリダイレクトの再生制御を行うことができる。

一方、ソース機器はコンテンツリダイレクトの終了と判定すると（ステップＳ４０５のはい）、コンテンツリダイレクトの終了をユーザに通知する（ステップＳ４１０）。この通知は、例えば出力部２０５へ表示することで行われる。

例えば、シンク機器におけるユーザ操作によるコンテンツリダイレクトの終了が通知された場合、ソース機器は図６（ａ）に示すコンテンツリダイレクト終了表示画面６０１を表示する。コンテンツリダイレクト終了表示画面６０１には、相手装置であるシンク機器においてコンテンツリダイレクトが終了されたことを通知するメッセージとともに、ミラーリングによる画面・音声共有を再開するか否かを選択する選択画面が表示される。

選択画面が表示されると、ソース機器はステップＳ４１１に進み、ミラーリングによる画面・音声共有を再開するかを判定する。ステップＳ４１１の判定は、ステップＳ４１０でソース機器に表示された選択画面におけるユーザの選択に基づいて判定される。

ユーザが画面・音声共有を再開する選択をした場合（図６（ａ）のＹＥＳを選択した場合）、ソース機器はステップＳ４１３に進み、ミラーリングによる画面・音声共有の再開処理を行う（ステップＳ４１１のはい）。一方、ユーザが画面・音声共有を再開しない選択をした場合（図６（ａ）のＮＯを選択した場合）には、ソース機器はステップＳ４１５に進み、ミラーリングによる画面・音声共有の終了処理を行う（ステップＳ４１１のいいえ）。

また、シンク機器もミラーリングによる画面・音声共有を行うか判定する（ステップＳ４１２）。この判定は、ソース機器がステップＳ４１３もしくはＳ４１５において送信した信号に基づいて行われ、判定結果はソース機器と一致する。ミラーリングを行う場合にはステップＳ４１４に進み、行わない場合にはステップＳ４１６に進む。

ミラーリングによる画面・音声共有を行う場合について詳細に説明する。

この場合、ソース機器は、シンク機器にＲＴＳＰ ＰＬＡＹメッセージを送信させるトリガーであるＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージをシンク機器へ送信する（ステップＳ４１３）。シンク機器は、ソース機器からＲＴＳＰ ＰＬＡＹメッセージを送信させるトリガーであるＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージを受信すると、ミラーリングを行うと判定する（ステップＳ４１２のはい）。そして、シンク機器は当該メッセージに応じてＲＴＳＰ ＰＬＡＹメッセージを発行、送信する（ステップＳ４１４）。ＲＴＳＰ ＰＬＡＹメッセージは画面等の送信開始を意味するメッセージであるので、ソース機器は画面等の送信制限を解除し、画面等の送信を再開する（ステップＳ３２４の「いいえ」に続くステップＳ３１１）。また、シンク機器はソース機器からの画面等の受信、および、再生を再開する（ステップＳ３２５の「いいえ」に続くステップＳ３１２）。このようにして、ミラーリングによる画面・音声共有が再開される。

なお、明示的にＲＴＳＰ ＰＬＡＹメッセージの送受信をすることなくミラーリングを再開することも可能である。この場合、ソース機器が画面等の送信制限を解除し、画面等の送信を再開すると共に、シンク機器が画面等の受信、および、再生を再開すればよい。

次に、ミラーリングによる画面・音声共有を行わない場合について詳細に説明する。これは、ユーザが画面・音声共有を再開しない選択をした場合（図６（ａ）のＮＯを選択した場合）である。

この場合、ソース機器はシンク機器に、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ仕様に準拠したＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージを送信する（ステップＳ４１５）。ＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージは、シンク機器がＲＴＳＰ ＴＥＡＲＤＯＷＮメッセージを送信するトリガーになる。このときシンク機器はミラーリングが再開されないと判定し（ステップＳ４１２のいいえ）、ステップＳ４１６に進む。そして、シンク機器はこのメッセージに応じてＲＴＳＰ ＴＥＡＲＤＯＷＮメッセージを発行、送信する（ステップＳ４１６）。この結果、シンク機器とソース機器間の通信が切断される。具体的には、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙセッションが切断される。このとき、シンク機器とソース機器間のＴＣＰ接続やＷｉ−Ｆｉ Ｐ２Ｐ接続が切断されても良い。なお、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ接続として、ＴＤＬＳに準拠したＴＤＬＳ接続を行っていた場合には、Ｗｉ−Ｆｉ Ｐ２Ｐ接続に代えて、ＴＤＬＳ接続が切断されるようにする。

なお、ユーザによる画面・音声共有の再開是非の指示がなく所定時間経過した場合には、自動的に画面・音声共有を再開してもよい。この場合、ステップＳ４１１での判定は「はい」になる。ここでのタイムアウト時間は任意の時間を予めユーザが設定することができ、時間０を設定することで即時に画面・音声共有を再開することも可能である。あるいはユーザによる画面・音声共有の再開是非の指示がなく所定時間経過した場合に、自動的に画面・音声共有を終了してもよい。この場合、ステップＳ４１１での判定は「いいえ」になる。所定時間が経過した場合に、再開するか否かは予めユーザが設定しておいてもよいし、機器にプリセットされていてもよい。

このようにソース機器はシンク機器においてコンテンツリダイレクトの終了操作が行われたことを検知した際に、画面・音声共有を再開するか否かを任意に選択することもできる。

またステップＳ４１０で表示される画面の他の例として、例えば、シンク機器から、コンテンツが終端に達したことによるコンテンツの再生終了が通知された場合、ソース機器は図６（ｂ）に示すコンテンツリダイレクト完了表示画面６０２を表示する。コンテンツリダイレクト完了表示画面６０２には相手装置であるシンク機器においてコンテンツの再生が完了した旨のメッセージとともに、ミラーリングによる画面・音声共有を再開するか否かを選択する選択画面を表示する。図６（ｂ）のＹＥＳ及びＮＯを選択した場合の動作は、夫々、図６（ａ）においてＹＥＳ及びＮＯを選択した場合の動作と同様であるため説明を省略する。

このようにソース機器はシンク機器においてコンテンツの再生が終了したことを検知した際に、ミラーリングによる画面・音声共有を再開するか否かを任意に選択することができる。

またステップＳ４１０で表示される画面の他の例として、例えば、シンク機器からコンテンツリダイレクトのエラーが通知された場合、ソース機器は、図６（ｃ）に示すコンテンツリダイレクトエラー表示画面６０３を表示する。ここで、エラーとは再生エラーもしくは受信エラーを指す。コンテンツリダイレクトエラー表示画面６０３には相手装置であるシンク機器においてコンテンツリダイレクトによるコンテンツ取得に失敗した旨のメッセージとともに、ミラーリングによる画面・音声共有を再開するか否かを選択する選択画面を表示する。このときコンテンツリダイレクトエラー表示画面６０３にエラー番号、もしくは、エラー番号に応じた表示をしてもよい。これにより、ユーザはエラー原因の把握とミラーリングの再開の可否の選択を一つの画面上でできるようになる。なお、図６（ｃ）のＹＥＳ及びＮＯを選択した場合の動作は、夫々、図６（ａ）においてＹＥＳ及びＮＯを選択した場合の動作と同様であるため説明を省略する。

このように図６（ｃ）のコンテンツリダイレクトエラー表示画面６０３により、ソース機器はシンク機器においてコンテンツリダイレクトにエラーが発生したこと、及びエラーの原因を検知する。また、ミラーリングによる画面・音声共有を再開するか否かを任意に選択することもできる。

なお、ステップＳ４１０はスキップしてもよい。この場合、図６（ａ）〜（ｃ）のＹＥＳが選択された場合と同様の動作（ミラーリングの再開）を行う。なお、これに代えて、図６（ａ）〜（ｃ）のＮＯが選択された場合と同様の動作（終了動作）を行うようにしてもよい。いずれの動作を行うかは、予め設定されていてもよいし、ユーザの設定であってもよい。このとき、ステップＳ４１１での判定はユーザ操作ではなく、予め定められた設定や、ユーザの設定などに従って行われる。

あるいは、ステップＳ４１２〜ステップＳ４１６に代えて、シンク機器がステップＳ４０７あるいはステップＳ４０８の後、自発的にＲＴＳＰ ＰＬＡＹ Ｒｅｑｕｅｓｔをソース機器に送信してもよい。ソース機器はステップＳ４１１でミラーリングを再開すると判定した場合、ＲＴＳＰ ＰＬＡＹ Ｒｅｑｕｅｓｔに対する応答としてＲＴＳＰ ＰＬＡＹ Ｒｅｓｐｏｎｓｅを、ステータスコードをＲＴＳＰ ＯＫとしてシンク機器に送信する。その後、ソース機器が画面等の送信制限を解除し、画面等の送信を再開すると共に、シンク機器が画面等の受信、および、再生をすることで、ミラーリングによる画面・音声共有が再開される。

一方、ステップＳ４１１でミラーリングを再開しないと判定された場合、ソース機器は、ＲＴＳＰ ＰＬＡＹ Ｒｅｑｕｅｓｔに対する応答として、ＲＴＳＰ ＯＫとは異なるステータスコードを含むＲＴＳＰ ＰＬＡＹ Ｒｅｓｐｏｎｓｅを送信する。この場合、ステータスコードとしてＮＧもしくは所定のエラー番号を含めることができる。そして、ソース機器はミラーリング終了処理を行う。同様にシンク機器もミラーリング終了処理を行う。

もしくは、ステップＳ４０７またはステップＳ４０８のあと、シンク機器は自発的にＲＴＳＰ ＴＥＡＲＤＯＷＮ Ｒｅｑｕｅｓｔを送信してもよい。ソース機器はステップＳ４１１でミラーリングを再開すると判定した場合、ＲＴＳＰ ＴＥＡＲＤＯＷＮ Ｒｅｑｕｅｓｔを受信しても、ミラーリング再開処理を行う。具体的には、ソース機器は、ＲＴＳＰ ＴＥＡＲＤＯＷＮ Ｒｅｑｕｅｓｔに対する応答として、ＲＴＳＰ ＯＫとは異なるステータスコードを含むＲＴＳＰ ＴＥＡＲＤＯＷＮ Ｒｅｓｐｏｎｓｅを送信する。この場合、ステータスコードとしてＮＧもしくは所定のエラー番号を含めることができる。そして、ソース機器はミラーリング再開処理を行う。同様に、シンク機器もミラーリング再開処理を行う。一方、ソース機器がステップＳ４１１でミラーリングを終了すると判定した場合は、ＲＴＳＰ ＴＥＡＲＤＯＷＮ Ｒｅｓｐｏｎｓｅを、ステータスコードをＲＴＳＰ ＯＫにしてシンク機器に送信する。この結果、Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙのセッションが切断され、ミラーリングは終了する。

次に、図５にシンク機器がコンテンツリダイレクトの状態を検知し、ソース機器に当該状態の情報を通知する場合の別の処理のフローチャートを示す。図５の（ａ）、（ｂ）は、夫々図３のステップＳ３２３、ステップＳ３２２に相当する。図５では、ソース機器からのトリガーに応じて、シンク機器はコンテンツリダイレクトを終了する。

このときシンク機器のステップＳ５０１〜Ｓ５０３、Ｓ５０６は、夫々前述の図４のステップＳ４０１〜Ｓ４０３、Ｓ４０６と同様のため省略する。またソース機器のステップＳ５０４、Ｓ５０５、Ｓ５０７と、前述の図４のステップＳ４０４、Ｓ４０５、Ｓ４０９は夫々同様のため省略する。

シンク機器は、シンク機器におけるユーザ操作によるコンテンツリダイレクトの終了か判定する（ステップＳ５０８）。この判定は、ステップＳ５０２で検知した結果に基づいて行う。シンク機器におけるユーザ操作によるコンテンツリダイレクトの終了と判定した場合（ステップＳ５０８のはい）、シンク機器はステップＳ５１０に進む。

このとき、ソース機器もシンク機器におけるユーザ操作によるコンテンツリダイレクトの終了か判定する（ステップＳ５０９）。この判定はステップＳ５０４で受信した通知に基づいて行う。シンク機器におけるユーザ操作によるコンテンツリダイレクトの終了と判定した場合（ステップＳ５０９のはい）、ソース機器はステップＳ５１１に進む。

シンク機器はコンテンツリダイレクトの終了処理が行われるよう、ソース機器にコンテンツリダイレクト終了要求を送信するよう指示する（ステップＳ５１０）。ソース機器は送信された指示を受信する（ステップＳ５１１）。

なお、ステップＳ５０３、Ｓ５０４において、シンク機器からソース機器に前述の通知がされたことに応じて、ソース機器がコンテンツリダイレクト終了要求を送信するようにしてもよい。即ち、ソース機器は、前述の通知があった場合、コンテンツリダイレクト終了要求の送信指示があったものとみなす。この場合、ステップＳ５１０とステップＳ５１１をスキップすることができる。

次に、ソース機器はステップＳ５１１で送信指示を受信すると、シンク機器へコンテンツリダイレクト終了要求を送信する（ステップＳ５１２）。シンク機器はソース機器から送信されたコンテンツリダイレクト終了要求を受信する（ステップＳ５１３）。コンテンツリダイレクト終了要求を受信したシンク機器は、クラウドサーバ１０４からのコンテンツ受信を終了する（ステップＳ５１４）。

そしてシンク機器はステップＳ５１７に進む。また、シンク機器におけるユーザ操作によるコンテンツリダイレクトの終了でないと判定した場合（ステップＳ５０８のいいえ）、シンク機器は同様にステップＳ５１７に進む。

ソース機器は、ステップＳ５１２でシンク機器へコンテンツリダイレクト終了要求を送信すると、ステップＳ５１５に進む。また、シンク機器におけるユーザ操作によるコンテンツリダイレクトの終了でないと判定した場合（ステップＳ５０９のいいえ）、ソース機器は同様にステップＳ５１５に進む。

ステップＳ５１５〜Ｓ５２１の処理は、夫々、前述の図４のステップＳ４１０〜Ｓ４１６と同様のため、説明を省略する。

以上、図４及び図５のフローチャートの処理に示したように、シンク機器からソース機器にコンテンツリダイレクトの状態の情報が通知されることにより、ソース機器はシンク機器におけるコンテンツリダイレクトの状態を検知することが可能となる。そしてソース機器はコンテンツリダイレクトの状態に応じた制御を自律的に行うことができる。

なお、コンテンツリダイレクトで複数のコンテンツを連続で再生してもよい。この場合、コンテンツリダイレクトを行っている際に、シンク機器で今再生しているコンテンツ以降に再生するコンテンツを、ソース機器で指定できるようにする。このとき、シンク機器は図３のステップＳ３２２でコンテンツの再生が終了したことを検知し、ステップＳ３２３でソース機器に通知する。ソース機器はステップＳ３２４でコンテンツリダイレクトの状態を受信すると、次にユーザが再生したいコンテンツがあると、ステップＳ３１７に戻り、シンク機器にコンテンツの情報を送信する。シンク機器はコンテンツの情報を受信すると（ステップＳ３１８）、クラウドサーバ１０４からコンテンツを受信する（ステップＳ３２１）。このとき、ミラーリングはすでに一時停止しているのでステップＳ３１９とステップＳ３２０はスキップする。ステップＳ３２２以降は先述と同じ動作になるため、説明を省略する。

本実施形態において、ミラーリング処理を開始してからコンテンツリダイレクトを行ったが、ミラーリング処理を経ずにコンテンツリダイレクトを開始してもよい。具体的には、図３のステップＳ３０１でユーザがコンテンツリダイレクトの開始操作を行ったか判定してもよい。この場合、図３のステップＳ３１１〜Ｓ３１３、ステップＳ３１９〜Ｓ３２０も省略される。

また、コンテンツリダイレクトが終了した場合、図４のステップＳ４１０とステップＳ４１１、図５のステップＳ５１５とステップＳ５１６は省略されてもよい。この場合、図４のステップＳ４０５が「はい」と判定されると、ステップＳ４１５に進んでもよい。図５も同様にステップＳ５０９の「いいえ」あるいはステップＳ５１２の後、ステップＳ５２０に進んでもよい。

即ち、ソース機器は、ミラーリングからコンテンツリダイレクトを行った場合と、ミラーリングを経ずにコンテンツリダイレクトを行った場合とで、コンテンツリダイレクト終了の通知を受けた場合の処理を変更してもよい。

また、図３〜５に示したフローチャートの各ステップを不図示の複数のＣＰＵもしくは装置で分散して行うようにしてもよい。複数の装置で分散して行う場合、ソース機器についてはソースシステム、シンク機器についてはシンクシステムとして動作する。

以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）などとしての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、撮像装置、ｗｅｂアプリケーションなど）から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１ 通信装置（ソース機器）
１０２ 通信装置（シンク機器）
１０３ 無線アクセスポイント
１０４ クラウドサーバ
１１０ 無線ネットワーク
２０１ 記憶部
２０２ 制御部
２０３ 機能部
２０４ 入力部
２０５ 出力部
２０６ 通信部
２０７ アンテナ

Claims (15)

1. 通信装置であって、
   前記通信装置が表示している画面の画面データあるいは再生している音声の音声データとの少なくとも一方を他の通信装置に送信する第１の送信手段と、
   外部装置が有するコンテンツの関連情報を前記他の通信装置に送信する第２の送信手段と、
   前記第１の送信手段によって前記他の通信装置に前記画面データあるいは前記音声データの少なくとも一方を送信している際に前記第２の送信手段によって前記関連情報を送信した場合、前記第１の送信手段による送信を停止する停止手段と、
   前記第２の送信手段によって前記関連情報を送信した場合に、前記関連情報に基づいて前記他の通信装置において行われる前記コンテンツの再生処理に関する状態の情報を前記他の通信装置から受信する受信手段と、
   前記受信手段により前記情報として前記コンテンツの再生処理が終了したことを示す情報を受信した場合に前記第１の送信手段による送信を再開するか否かを選択するユーザ操作を受け付ける受付手段と、
   前記受付手段によって前記第１の送信手段による送信を再開することを選択するユーザ操作を受け付けた場合は、前記第１の送信手段による送信を再開するように制御し、前記受付手段によって前記第１の送信手段による送信を再開しないことを選択するユーザ操作を受け付けた場合は、前記第１の送信手段による送信を再開しないように制御する制御手段と、
   を有することを特徴とする通信装置。
2. 前記コンテンツの関連情報は、前記コンテンツの識別子であることを特徴とする請求項１に記載の通信装置。
3. 前記他の通信装置との無線通信を切断する切断手段をさらに有し、
   前記制御手段は、前記受付手段によって前記第１の送信手段による送信を再開しないことを選択するユーザ操作を受け付けた場合は、前記切断手段によって前記他の通信装置との前記無線通信を切断するように制御することを特徴とする請求項１又は２に記載の通信装置。
4. 前記第２の送信手段は、前記受信手段によって前記コンテンツの再生処理が終了したことを示す情報を受信した場合、前記他の通信装置の前記外部装置からの前記コンテンツの受信を終了させるための終了要求を送信することを特徴とする請求項１から３の何れか一項に記載の通信装置。
5. 前記コンテンツの再生処理が終了したことを示す情報とは、前記他の通信装置が前記コンテンツの再生の終了を指示するユーザ操作を受け付けたことを示す情報であることを特徴とする請求項１から４の何れか一項に記載の通信装置。
6. 前記コンテンツの再生処理が終了したことを示す情報とは、前記他の通信装置において前記コンテンツが終端まで再生されたことを示す情報であることを特徴とする請求項１から４の何れか一項に記載の通信装置。
7. 前記コンテンツの再生処理が終了したことを示す情報とは、前記他の通信装置おいて前記コンテンツの受信エラーが発生したことを示す情報であることを特徴とする請求項１から４の何れか一項に記載の通信装置。
8. 前記コンテンツの再生処理が終了したことを示す情報とは、前記他の通信装置において前記コンテンツの再生エラーが発生したことを示す情報であることを特徴とする請求項１から４の何れか一項に記載の通信装置。
9. 前記受信手段により受信した前記情報に基づく表示を行うように制御する表示制御手段をさらに有することを特徴とする請求項１から８の何れか一項に記載の通信装置。
10. 前記通信装置は、前記他の通信装置とＷｉ−Ｆｉ Ｐ２Ｐ接続を確立することを特徴とする請求項１から９の何れか一項に記載の通信装置。
11. 前記通信装置は、前記他の通信装置とＷｉ−Ｆｉ Ｄｉｓｐｌａｙセッションを確立することを特徴とする請求項１から１０の何れか一項に記載の通信装置。
12. 前記通信装置は、前記他の通信装置とＩＥＥＥ８０２．１１シリーズ規格に準拠した通信を行うことを特徴とする請求項１から１１の何れか一項に記載の通信装置。
13. 前記第１の送信手段は、Ｗｉ−Ｆｉ Ｍｉｒａｃａｓｔ規格に準拠して、前記画面データあるいは前記音声データの少なくとも一方を送信することを特徴とする請求項１から１２の何れか一項に記載の通信装置。
14. 通信装置の制御方法であって、
    前記通信装置が表示している画面の画面データあるいは再生している音声の音声データとの少なくとも一方を他の通信装置に送信する第１の送信工程と、
    外部装置が有するコンテンツの関連情報を前記他の通信装置に送信する第２の送信工程と、
    前記第１の送信工程において前記他の通信装置に前記画面データあるいは前記音声データの少なくとも一方を送信している際に前記第２の送信工程において前記関連情報を送信した場合、前記第１の送信工程による送信を停止する停止工程と、
    前記第２の送信工程において前記関連情報を送信した場合に、前記関連情報に基づいて前記他の通信装置において行われる前記コンテンツの再生処理に関する状態の情報を前記他の通信装置から受信する受信工程と、
    前記受信工程において前記情報として前記コンテンツの再生処理が終了したことを示す情報を受信した場合に前記第１の送信工程における送信を再開するか否かを選択するユーザ操作を受け付ける受付工程と、
    前記受付工程において前記第１の送信工程における送信を再開することを選択するユーザ操作を受け付けた場合は、前記第１の送信工程における送信を再開するように制御し、前記受付工程において前記第１の送信工程における送信を再開しないことを選択するユーザ操作を受け付けた場合は、前記第１の送信工程における送信を再開しないように制御する制御工程と、
    を有することを特徴とする制御方法。
15. コンピュータを請求項１から１３の何れか一項に記載の通信装置の各手段として機能させるためのプログラム。

Images