JP2013143665A - コンテンツ視聴システム - Google Patents

Abstract

【課題】切替先の機器が使用できない場合でも、ユーザが特に意識することなく、継続して視聴が可能なシステムを提供する。
【解決手段】コンテンツ視聴システムであって、第１のクライアントが前記コンテンツサーバから送信されているコンテンツを再生中に、コンテンツの送信先を変更する引継操作を行うＵＩ部により引継要求を受けると、前記第１のクライアントは、機器情報受信部により、引継先の第２のクライアントの状態確認を行い、前記状態確認の結果として、前記第２のクライアントが不在又はビジーである場合に、その旨を前記第２のクライアントから受信するとともに、前記第１のクライアントに引継情報として、コンテンツと再生開始位置とを保存し、前記第２のクライアントからの引継可能応答を待って、前記引継情報を前記第２のクライアントに送り、前記コンテンツサーバへの前記引継情報に基づくコンテンツ要求を促すクライアント制御部を有する。
【選択図】図５

Description

本発明は、コンテンツ視聴技術に関し、特に、異なるクライアント間でコンテンツを継続して視聴することができる視聴システムに関する。

近年、無線通信技術の進歩とコンテンツの増加に伴い、いつでもどこでも、所望のコンテンツを視聴できる環境が整いつつある。例えば、下記特許文献１に記載の技術では、家庭に設置されたホームコンテンツサーバと、コンテンツを再生する視聴デバイスと、を備えたシステムにおいて、同一コンテンツの視聴を異なる視聴デバイスの間で切り換えた場合でも、視聴者が同じシーンから継続して視聴できるようにするためのシステムが提案されている。

当該システムでは、切換元のクライアントから切替先のクライアントに対して切換要求を行った後、切替先のクライアントが了承通知を送信すると、切替元のクライアントから切替先のクライアントに対して引継に必要なコンテンツ情報を送信するように構成されている。切替先のクライアントは、受け取ったコンテンツ情報を基に、サーバからコンテンツを取得して再生する。これにより、同一コンテンツの視聴を異なる視聴デバイスの間で切り換えた場合でも、視聴者が同じシーンから継続して視聴することができる。

特許第４５３３０２０号公報

しかしながら、コンテンツの継続視聴を行おうとする場合に、切替先の機器の電源が入っていない場合や、切替先の機器が通話中などで使用できない場合など、すぐに継続視聴を行うことができない場合もある。

上記特許文献１に記載の技術では、切替先のクライアントが使用中の場合、非許可応答を返して動作を終了していた(0089段落)。また、切替先クライアントの電源が入っていない場合は想定されていなかった。このため、再度切換元のクライアントで継続視聴の操作をする手間が必要となっていた。

本発明は、切替先の機器の電源が入っていない場合や、切替先の機器が通話中などで使用できない場合でも、ユーザが特に意識することなく、継続して視聴が可能なシステムを提供することを目的とする。

本発明の一観点によれば、コンテンツを送信するコンテンツサーバと、コンテンツを再生するクライアントと、を有するコンテンツ視聴システムであって、第１のクライアントが前記コンテンツサーバから送信されているコンテンツを再生中に、コンテンツの送信先を変更する引継要求を受けると、前記第１のクライアントは、引継先の第２のクライアントの状態確認を行い、前記状態確認の結果として、前記第２のクライアントが不在又はビジーである場合に、その旨を前記第２のクライアントから受信するとともに、前記第１のクライアントに引継情報として、コンテンツと再生開始位置とを保存し、前記第２のクライアントからの引継可能応答を待って、前記引継情報を前記第２のクライアントに送り、前記コンテンツサーバへの前記引継情報に基づくコンテンツ要求を促すことを特徴とするコンテンツ視聴システムが提供される。

前記第１のクライアントは、前記第２のクライアントが不在の場合には、存在通知の後に、前記第１のクライアントが前記第２のクライアントにリソース確保を要求するようにしても良く、前記第２のクライアントがビジーの場合には、ビジー解消通知の前に、前記第１のクライアントが前記第２のクライアントにリソース確保を要求するようにしても良い。

また、本発明においては、前記第１のクライアントと前記第２のクライアントとが、コンテンツを再生する機能を有するレンダラと、コンテンツを引き継ぐための入力を行うコントローラと、により、別体に構成されるようにしても良い。

本発明は、明細書に記載の引継方法であっても良く、当該引継方法をコンピュータに実行させるためのプログラムであっても良く、当該プログラムを記録するコンピュータ読み取り可能な記録媒体であっても良い。

本発明によれば、継続視聴のための操作を行った際に、引継先のクライアントに電源が入っていないなど、すぐに継続視聴を行うことができない場合でも、再度継続視聴操作を行うことなく、クライアントの準備ができ次第、継続視聴が可能となるという利点がある。

本発明の第１の実施の形態によるコンテンツ視聴システムの一構成例を示す図である。 本実施の形態によるコンテンツサーバの一構成例を示す機能ブロック図である。 クライアント内部のデータの流れを示す図である。 クライアント制御部とコンテンツサーバ、別の（引継先）クライアントとの間のデータの送受信の様子を示す図である。 コンテンツサーバと、引継元クライアントと、引継先クライアントとの間における基本的な処理を時系列的に示すシーケンス図である。 引継を行う前における、コンテンツサーバと引継元クライアントとの間の処理の例を示すシーケンス図である。 クライアント（１）が、クライアント（２）への引継を行う例である コンテンツサーバを経由して引継を行う例を示す図である。 図６に示す処理の後に、通話中の引継先クライアントへ引継を行う処理を示すシーケンス図である。 存在確認を定期的に行う処理の流れを示すフローチャート図である。 本発明の第２の実施の形態によるコンテンツ視聴システムの一構成例を示す機能ブロック図である。 コントローラの内部におけるデータの流れを示す図である。 コントローラ制御部のデータ送受信について示す図である。 本実施の形態によるレンダラの一構成例を示す機能ブロック図であり、データの流れを合わせて示す図である。 本実施の形態によるレンダラの一構成例を示す機能ブロック図であり、データの流れを合わせて示す図である。 本実施の形態によるコンテンツ視聴装置の動作例を示すシーケンス図である。

以下、本発明の実施の形態によるコンテンツ視聴システムについて、図面を参照しながら説明を行う。まず、本発明の第１の実施の形態によるコンテンツ視聴システムについて説明する。図１は、本実施の形態によるコンテンツ視聴システムの一構成例を示す図である。図１に示すように、本実施の形態によるコンテンツ視聴システムは、コンテンツを配信・提供するコンテンツサーバ１と、コンテンツを受信してユーザが視聴するクライアント（１）３と、クライアント（２）５とを有している。コンテンツサーバ１と、クライアント（１）３と、クライアント（２）５とは、例えば、ネットワークＮＴを介して、無線通信や近距離通信などによりネットワーク接続可能に構成されている。クライアントは、さらに多く存在していても良いが、簡単のために、引き継ぎ元と引き継ぎ先の２つのクライアントが存在する例について説明する。例としては、コンテンツサーバは、自宅のレコーダや外部のコンテンツを提供するサーバであり、クライアントは、コンテンツを受信し再生することが可能な携帯端末であっても良い。

図２は、本実施の形態によるコンテンツサーバの一構成例を示す機能ブロック図である。図２に示すコンテンツサーバ１は、コンテンツサーバ１を制御するサーバ制御部１１と、コンテンツを格納するコンテンツ格納部１５と、クライアント３、５と通信を行う通信部２５と、を有している。サーバ制御部１１は、機器情報送信部１７と、コンテンツ情報送信部２１と、コンテンツ送信部２３と、を有している。機器情報送信部１７は、クライアント３、５からの存在確認の問い合わせに対して機器情報（機器ＩＤ等）を返信して、コンテンツサーバ１の存在をクライアント３、５に通知する。コンテンツ情報送信部２１は、クライアント３、５からのコンテンツリストの要求に対して、自己が配信できるコンテンツリストを返信する。コンテンツ送信部２３は、コンテンツリストを参照したクライアント３、５からのコンテンツ要求に対して、コンテンツ格納部１５からコンテンツを取得して、クライアント３、５に要求されたコンテンツを送信する。

図３及び図４は、クライアント３、５の一構成例を示す機能ブロック図であり、図３は、クライアント内部のデータの流れを示す図であり、図４は、クライアント制御部とコンテンツサーバ、別のクライアントとの間のデータの送受信の様子を示す図である。図３に示すように、クライアント３、５は、クライアント制御部３１と、ユーザ操作を行うためのユーザインタフェイス部（ＵＩ部）４７と、コンテンツを再生する再生部５１と、データの送受信を行う通信部５３と、を有している。図４では、図３の構成に加えて、コンテンツサーバ１，或いは別のクライアント５との間におけるデータ送受信の様子を示している。

クライアント制御部３１は、機器情報送信部３３と、機器情報受信部３５と、引継情報送信部３７と、引継情報受信部４１と、コンテンツ情報受信部４３と、コンテンツ受信部４５と、を有している。

機器情報送信部３３は、図４に示すように、別のクライアント５からの存在確認に対して機器情報（機器ＩＤ等）を送信して自己（クライアント３）の存在を別のクライアント５に通知する。機器情報受信部３５は、別のクライアント５からの存在確認に対して、機器情報を提示して自己（クライアント３）の存在を通知する。

引き継ぎを行う前の再生処理においては、ＵＩ部４７より、サーバ選択画面表示からサーバを選択し（後述する図６のシーケンス図の２−３参照）、機器情報受信部３５が、ＵＩ部４７などにより選択されたサーバの情報をコンテンツ情報受信部４３に送り、一方、ＵＩ部４７において表示された、コンテンツ選択画面表示においてコンテンツを選択してコンテンツ情報受信部４３に送り、サーバ情報とコンテンツ選択情報とにより特定されるコンテンツのコンテンツ情報をコンテンツ受信部４５に送り、再生部５１にコンテンツを送ってコンテンツを再生させる。

一方、引き継ぎを行う際には、ＵＩ部４７より、引継先選択画面表示から引継先のクライアントを選択し（後述する図７のシーケンス図の３−２参照）、引継情報受信部４１が引継先のクライアントの情報を受信すると、これに基づいて、選択された引継先のクライアント（別のクライアント５）に対して存在確認を行い、機器情報送信部３３とともに、存在確認の送信と存在通知の受信とを行う。引継先のクライアントの存在が確認されると、引継情報送信部３７が引継先のクライアント（別のクライアント５）に対して、リソースの確保要求と引継情報とを送り、リソース確保通知を受け取る。

次に、本実施の形態によるコンテンツ視聴システムにおける各機器間の処理について詳細に説明する。図５は、コンテンツサーバ１と、引継元クライアント（１）３と、引継先クライアント（２）５と、の間における基本的な処理を時系列的に示すシーケンス図である。まず、コンテンツサーバ１が引継元クライアント（１）３に対して、コンテンツを送信している（コンテンツ送信： １−１）。引継元クライアント（１）３では、送信されたコンテンツを再生し、ユーザがそのコンテンツを視聴することができる。ユーザは、コンテンツ再生中において、引継元クライアント（１）３から引継先クライアント（２）５に、コンテンツの視聴デバイスを引き継ぎたいと考えて、そのための操作等が行われるとその操作が検出されて、引継元クライアント（１）３は引継先クライアント（２）５に、その状態を確認する（状態確認： １−２）。引継先クライアント（２）５の状態とは、スリープ状態（電源オフなど）、Ｂｕｓｙ（ビジー）状態（他の機能を使用中など）、Ｒｅａｄｙ（レディー）状態（引継可能な状態）などであり、Ｒｅａｄｙ状態の場合には、すぐに引継が可能であるので、引継元クライアント（１）３は引継先クライアント（２）５に引継を行う。すなわち、特許文献１のように、引継元のクライアント（１）３から引継先のクライアント（２）５に対して切換要求を行った後、引継先のクライアント（２）５が切換要求に対する了承通知を送信すると、引継元のクライアント（１）３から引継先のクライアント（２）５に対して引継に必要なコンテンツ情報を送信する。引継先のクライアント（２）５は、受け取ったコンテンツ情報（コンテンツ、そのＩＤ等、引き継ぐ際の再生開始位置）を基に、コンテンツサーバ１からコンテンツを取得して再生する。

一方、引継先クライアント（２）５の状態が、スリープ状態、Ｂｕｓｙ状態などの場合には、すぐには引き継ぎができないため、引継元のクライアント（１）３は、コンテンツサーバ１に対して、コンテンツの送信を停止する旨を指示し（コンテンツ送信停止：１−３）、引継要求を保留する。この引継要求を引継元クライアント（１）３に保存しても良い（引継（指示）情報保存： １−４）。尚、コンテンツの再生は、この時点で停止しても良いし、引継処理が完了した後にコンテンツの再生を停止するようにしても良い。いずれにするかは、一般的には、引継を望むタイミングで停止するのがユーザの意図（操作、設定等）に沿うようにすれば良い。

次いで、引継先クライアント（２）５の状態が、スリープ状態、Ｂｕｓｙ状態などからＲｅａｄｙ状態に遷移すると、状態確認処理（１−２）の応答として、引継先クライアント（２）５から引継元クライアント（１）３に対して引継可能通知がなされる（引継可能通知： １−５）。そこで、引継元クライアント（１）３から引継先クライアント（２）５に対して、引継用の引継情報として、コンテンツを指定する情報とコンテンツの再生を再開する位置（タイミング）を示す情報とが送信される（引継情報送信： １−６）。尚、コンテンツの再生を再開するタイミングは、コンテンツ送信停止指示（１−３）においてコンテンツサーバ１が記憶することができるため、この記憶に基づいてコンテンツの送信を再開するようにしても良い。また、コンテンツを指定する情報としては、コンテンツそのもの、或いはコンテンツを特定するコンテンツＩＤとそのコンテンツを提供するコンテンツサーバのＵＲＬなどであっても良い。

引継可能通知の受信に応じて、引継先クライアンと（２）５からのコンテンツ要求（コンテンツ要求： １−７）がなされ、コンテンツサーバ１から引継先クライアント（２）５に対して、再開タイミングからのコンテンツが送信される（コンテンツ送信： １−８）。送信されたコンテンツを、引継先クライアント（２）５において再生することで、ユーザは、引継元クライアント（１）３で視聴していたコンテンツを引継先クライアント（２）５で、切れ目無く再生させ引き続き視聴することができる。

尚、引継可能通知（１−５）は、引継先クライアント（２）５が引継元クライアント（１）３に通知しても良いし、コンテンツサーバ１が引継先クライアント（２）５に問い合わせを継続的に行うようにして、引継先クライアント（２）５がＲｅａｄｙ状態になったことを引継先クライアント（２）５からの返信により知ると、コンテンツサーバ１からを引継先クライアント（２）５に対してコンテンツを送信するようにしても良い。

いずれの場合も、引継先クライアント（２）５がＲｅａｄｙ状態になると、引継可能通知を直接又は間接的にコンテンツサーバ１にその旨を送り、コンテンツサーバ１からのコンテンツの送信再開を行う。

次に、図５に示したコンセプトに関する、より具体的な動作について説明する。

（引継を行う前の再生処理）
図６は、コンテンツの引継を行う前における、コンテンツサーバ１と引継元クライアント（１）３との間の処理の例を示すシーケンス図である。まず、引継元クライアント（１）３が、コンテンツを送信することができるコンテンツサーバ１の存在を確認する（存在確認： ２−１）。これに対して、コンテンツサーバ１が引継元クライアント（１）３に対して存在を通知すると（存在通知： ２−２）、引継元クライアント（１）３側でコンテンツを送信するコンテンツサーバを選択する（サーバ選択： ２−３）ことができる。

引継元クライアント（１）３は、選択したコンテンツサーバ１に対してコンテンツサーバ１が送信可能なコンテンツリストを要求する（コンテンツリスト要求： ２−４）。これに対して、コンテンツリスト等のコンテンツのタイトルを知ることができる情報が返信されると（コンテンツリスト送信： ２−５）、引継元クライアント（１）３側で、送信を要求するコンテンツを選択する（コンテンツ選択： ２−６）ことができる。この選択操作に基づいて、引継元クライアント（１）３は、選択したコンテンツをコンテンツサーバ１に対して要求する（コンテンツ要求： ２−７）と、この要求に対して、要求されたコンテンツが送信される（コンテンツ送信： ２−８）。引継元クライアント（１）３は、送信されたコンテンツを再生できる（コンテンツ再生： ２−９）。

以上のシーケンスにより、コンテンツサーバ１から送信されるコンテンツを引継元クライアント（１）３で視聴することができる。

（電源が入っていないクライアントへの引継）
図６の状態から、コンテンツの再生を引継元クライアント（１）３から引継先クライアント（２）５に引き継ぐ際に、引継先クライアント（２）５の電源が入っていない場合の処理について、図７を参照しながら説明する。

図７においては、引継元クライアント（１）３がコンテンツを再生している（コンテンツ再生： ３−１）。ここで、ＵＩ部４７などから、コンテンツの再生を行う機器を引継先クライアント（２）５に引き継ぐための操作（入力）を、例えば引継先クライアント（２）５のＵＲＬなどを指定して行うと（引継入力： ３−２）、引継元クライアント（１）３から引継先クライアント（２）５に対して、存在確認の問い合わせが行われる（存在確認： ３−３）。ここで、引継先クライアント（２）５の電源が入っていない場合等においては、引継先クライアント（２）５からの応答がない（応答なし： ３−４）。少なくとも１回の応答なしの処理を経ると、引継元クライアント（１）３は、コンテンツの送信停止をコンテンツサーバ１に依頼する（コンテンツ送信停止： ３−５）とともに、自己のコンテンツの再生を終了（停止）する（コンテンツ再生終了： ３−６）。この際、例えば、「引継指示を受け付けました。引継先クライアント（２）５の電源を入れると自動的に引継が行われます。」などと表示することでユーザに報知するようにしても良い。

次いで、引継元クライアント（１）３は、引継指示を保存（保留）する（引継指示保存： ３−７）。ここでは、コンテンツの再生開始（再開）位置、すなわち、引継元クライアント（１）３でどの位置までコンテンツを再生させたかに関する再生開始位置の情報を保持する。シーケンス３−６で、引継情報が保存された後、シーケンス３−８（電源ＯＮ）の存在通知が一定時間行われない場合には、タイムアウトとして、引継を中断してもよい。

引継先クライアント（２）５が電源オン状態になる起動時に、引継先クライアント（２）５は、引継元クライアント（１）３を含む対象となる全てのクライアント機器に対して存在通知（存在通知： ３−９）を送信する。引継元クライアント（１）３は、引継先クライアント（２）５からの存在通知（３−９）を受け取ると、引継先クライアント（２）５に対して、リソース確保要求を行う（リソース確保要求： ３−１０）。引継先クライアント（２）５において、リソース確保要求に対して引継を行うためのリソースを確保すると、引継元クライアント（１）３に対して、リソースを確保した旨を通知する（リソース確保通知： ３−１１）。この際、「引継元クライアント（１）３からの引継再生を行います。」などと表示させるようにしても良い。

引継元クライアント（１）３は、引継先クライアント（２）５に対して、引継用の引継情報を送信する（引継情報送信： ３−１２）。この引継情報には、少なくともコンテンツを特定するコンテンツ特定情報と上記再生開始位置とが含まれる。コンテンツ特定情報は、上述のように、コンテンツのＩＤ、コンテンツ取得のためのＵＲＬなどである。

引継用の引継情報を受け取った引継先クライアント（２）５は、引継用の引継情報を基に、コンテンツサーバ１に対してコンテンツの送信要求を行う（コンテンツ要求： ３−１３）。これに対して、コンテンツサーバ１は、要求されたコンテンツを例えば再生開始位置から引継先クライアント（２）５に対して送信する（３−１４）。引継先クライアント（２）５において、コンテンツを再生開始位置から再生する（コンテンツ再生： ３−１５）。或いは、コンテンツサーバ１からコンテンツ全体を送信し、引継先クライアント（２）５において、再生開始位置から再生するようにしても良い（コンテンツ再生： ３−１５）。

以上に説明したように、図７に示すシーケンス図に基づいて、引継要求時には、引継先クライアントの電源が入っていない場合でも、引継先クライアントの電源がオンされた後に、スムーズにコンテンツの送信の引継処理を行い、再生開始位置からコンテンツを視聴することができる。従って、ユーザは、異なるクライアント間でスムーズにコンテンツの引継を行うことができる。

尚、ここでは、引継先クライアント（２）５の電源が入っていないとは、完全に電源オフの状態を指す。

完全に電源オフの状態では、存在確認（３−３）を受け取れないが存在通知（３−９）では、存在確認の受信の有無に関係なく、ネットワーク内のすべての機器に対して存在通知を送信する。引継元クライアント（１）３は、存在通知を受け取った際に、自身が保存する引継指示の相手先から存在通知が送信されたかどうかを確認し、その場合には、リソース確保要求（３−１０）を行う。

（コンテンツサーバ経由の引継）
図７は、上記のように、クライアント（１）３が、クライアント（２）５への引継を行う例である。一方、図８は、図７と異なり、コンテンツサーバ１を経由して引継を行う例を示す図である。図８に示すように、コンテンツサーバ１内のコンテンツを、引継元クライアント（１）３を用いて再生している（コンテンツ再生： ４−１）。引継元クライアント（１）３の再生を引継先クライアント（２）５へ引き継ぐための引継入力が行われる（引継入力： ４−２）。引継先のクライアントとして引継先クライアント（２）５が選択された場合に、引継元クライアント（１）３は、コンテンツサーバ１経由で、引継先クライアント（２）５に対して、存在確認を行う（存在確認： ４−３）。

ここで、引継先クライアント（２）５の電源が入っていない場合には、引継先クライアント（２）５は存在確認に応答できない。従って、コンテンツサーバ１から引継先引継元クライアント（１）３への存在通知に関して、コンテンツサーバ１を介しての応答はない（応答なし： ４−４）。

そこで、引継元クライアント（１）３は、コンテンツサーバ１からの存在通知への応答がない場合に、コンテンツ再生を終了する（コンテンツ再生終了： ４−５）。このとき、コンテンツサーバ１に送信停止指示を行う。この際、例えば、「引継指示を受け付けました。引継先クライアント（２）５の電源を入れると自動的に引継が行われます」と表示するようにしても良い。

尚、コンテンツ再生の終了のタイミングは、後述するコンテンツの引継先クライアント（２）へのコンテンツの送信前までであれば良い。そして、引継元クライアント（１）３は、引継指示を内部のメモリなどに保存する（引継指示保存： ４−６）。

引継先クライアント（２）５の電源が入れられる（電源ＯＮ： ４−７）まで、すなわち、引継先クライアント（２）５が電源オン状態になる起動時まで、引継先クライアント（２）５は、引継元クライアント（１）３を含む対象となる全てのクライアント機器に対して存在通知（存在通知： ４−８）の送信を、例えばあるタイミング毎に継続して行う。引継元クライアント（１）３は、引継先クライアント（２）５からの存在通知を受け取ると（４−８）、コンテンツサーバ１経由で引継先クライアント（２）５に対してリソース確保要求を行う（リソース確保要求： ４−９）。

引継先クライアント（２）５において、リソース確保要求に対して引継を行うためのリソースを確保すると、コンテンツサーバ１経由で引継元クライアント（１）３に対してリソースを確保した旨を通知する（リソース確保通知： ４−１０）。これに対して、引継元クライアント（１）３は、コンテンツサーバ１に対して、（４−６）の処理で保存した引継指示の引継情報を送信し、コンテンツサーバ１は、引継情報を、引継先クライアント（２）５に転送する（引継情報送信： ４−１１）。この引継情報に基づいて、図７の場合と同様に、引継先クライアント（２）５は、コンテンツサーバ１に対してコンテンツを要求し（コンテンツ要求： ４−１２）、コンテンツサーバは、引継先クライアント（２）５に対して、要求されたコンテンツを引継情報に基づく再生開始位置から送信する（４−１４）。引継先クライアント（２）５は、コンテンツサーバ１から受け取ったコンテンツを、引継情報に基づく再生開始位置から再生することができる。

ここで、シーケンス（４−８）で引継情報が保存された後、シーケンス（４−１０）のリソース確保通知が一定時間行われない場合には、タイムアウト処理を行い、引継処理を中断するようにしてもよい。これらの際のタイムアウト時間は、ユーザが指定できるようにしてもよい。また、タイムアウトを発生させず、ユーザ入力により引継のキャンセルが可能なようにしてもよい。

本実施の形態では、引継情報を送信する前に、引継先のクライアントに対して「リソース確保要求」を実行する。「リソース確保要求」に対して「保留通知」が行われた場合、引継指示が保存される。その後、引継先クライアントから「リソース確保通知」が送信された場合、引継処理を実行する。

従来は、引継先クライアントが引継できない状態の場合、非許可応答を返していた。そのため、引継先クライアントが引継可能になった後で、再度引継処理を行う必要があった。例えば、引継先クライアントが携帯電話であり、通話中などの引継不可能状態であった場合、通話終了を待ってから、改めて引継元クライアントで引継操作を行う必要があり、手間がかかっていた。

上記の技術では、引継元クライアントで操作を行った際に引継先クライアントが引継出来る状態になかった場合であっても、引継先クライアントが引継できる状態になった際に自動的に引継が行われるため、操作の手間を削減することができる。

このように、本実施の形態では、クライアント間の直接通信を行う必要がないため、クライアント機器の処理負担を軽減することができる。

（引継できない状態のクライアントへの引継）
図９は、図６に示す処理の後に、通話中の引継先クライアントへ引継を行う処理を示すシーケンス図である。

まず、コンテンツサーバ１から送信されるコンテンツを、引継元クライアント（１）３が再生している（コンテンツ再生： ５−１）。次いで、引継元クライアント（１）の再生を引継先クライアント（２）５へ引き継ぐための引継入力が行われる（引継入力： ５−２）。

引継先のクライアントとしてクライアント（２）５が選択された場合に、引継元クライアント（１）３は、引継先クライアント（２）５に対して、存在確認を行う（存在確認： ５−３）。電源はオンであるため、引継先クライアント（２）５は、引継元クライアント（１）３からの存在確認に対して存在通知を送信することができる（５−４）。

引継元クライアント（１）３は、引継先クライアント（２）５からの存在通知を受信すると（存在通知： ５−４）、引継先クライアント（２）に対してリソース確保要求を行う（リソース確保要求： ５−５）。

引継先クライアント（２）５が通話中の場合等には、その時点でコンテンツの再生等を行うことはできないため、引継元クライアント（１）３に対して引継の保留通知を送信する（保留通知： ５−６）。引継元クライアント（１）３は、引継先クライアント（２）５から保留通知を受信した場合に、コンテンツ再生を終了する（コンテンツ再生終了： ５−７）。この際、「引継指示を受け付けました。引継先クライアント（２）５が使用可能になると自動的に引継が行われます。」などと表示し、再生を終了するようにしても良い。また、コンテンツサーバ１に送信停止指示を行う（５−７）。引継元クライアント（１）３は、引継指示を内部に保存する（引継操作記憶処理： ５−８）。引継先クライアント（２）５の通話が終了し、引継が可能になると（通話終了： ５−９）、引継先クライアント（２）は、リソース確保要求（５−５）に対して引継を行うためのリソースを確保し、引継元クライアント（１）３に対してリソース確保通知を行う（リソース確保通知： ５−１０）。ここで、「引継元クライアント（１）３からの引継再生を行います。」などと表示するようにすると良い。

引継元クライアント（１）３は、引継先クライアント（２）５に対して、引継用の引継情報を送信する（引継情報送信： ５−１１）。この引継情報には、少なくともコンテンツを特定するコンテンツ特定情報と再生開始位置とが含まれる。引継先クライアント（２）５は、受け取った引継情報を基に、コンテンツサーバ１に対してコンテンツの送信要求を行う（コンテンツ要求： ５−１２）。コンテンツサーバ１は、引継先クライアント（２）５に対してコンテンツを送信する（コンテンツ送信： ５−１３）。引継先クライアント（２）５は、コンテンツサーバ１から受け取ったコンテンツを再生開始位置から再生する（コンテンツ再生： ５−１４）。

この形態では、引継情報を送信する前に、引継先のクライアントに対して「リソース確保要求」を実行する。「リソース確保要求」に対して「保留通知」が行われた場合、引継指示が保存される。その後、引継先クライアントから「リソース確保通知」が送信された後に引継処理が実行される。

従来は、引継先クライアントがすぐには引継できない状態の場合、非許可応答を返していたが、そのため、引継先クライアントが引継可能になった後で、再度引継処理を行う必要があった。例えば、引継先クライアントが携帯電話であり、通話中などの引継不可能状態であった場合、通話終了を待ってから改めて引継元クライアントで引継操作を行う必要があり、操作の手間がかかっていた。本実施の形態では、引継元クライアントで操作を行った際に引継先クライアントが引継出来る状態になかったとしても、引継先クライアントが引継できる状態になった際に自動的に引継が行われるため、操作等の手間を削減することができるという利点がある。

（存在確認を定期的に行う処理）
図１０は、存在確認を定期的に行う処理の流れを示すフローチャート図である。
図１０に示すように、コンテンツサーバ１内のコンテンツを、引継元クライアント（１）３を用いて再生している状態（コンテンツ再生： ６−１）から引継処理を開始する。引継元クライアント（１）３は、ネットワーク内の全ての機器に対して定期的に存在確認を行う（存在確認： ６−２）。引継元クライアント（１）３は、存在通知（応答）を受信できない場合、存在通知を送信した機器に関する情報を保存し、引継元クライアント（１）３の再生を引継先クライアント（２）５へ引き継ぐための引継入力が行われる（引継入力： ６−４）。

引継元クライアント（１）３は、引継先クライアント（２）５が存在確認に応答していないため（応答なし： ６−３）、「引継指示を受け付けました。クライアント（２）５の電源を入れると自動的に引継が行われます。」などと表示し、再生を終了する（６−５）。このとき、コンテンツサーバ１に送信停止指示を行う（コンテンツ再生終了： ６−５）。引継元クライアント（１）３は、引継指示を内部に保存する（引継指示保存： ６−６）。

次いで、引継先クライアント（２）の電源が入れられると、引継先クライアント（２）５は、電源ＯＮ（６−７）による起動時に、ネットワーク内の全ての機器に対して存在通知を送信する（存在通知： ６−８）。

引継元クライアント（１）３は、引継先クライアント（２）５からの存在通知を受信すると、引継先クライアント（２）５に対してリソース確保要求を行う（リソース確保要求： ６−９）。引継先クライアント（２）５は、リソース確保要求に対して引継を行うためのリソースを確保し、引継元クライアント（１）３に対してリソース確保通知を行う（リソース確保通知： ６−１０）。また、例えば、「引継元クライアント（１）３からの引継再生を行います。」等と表示するようにしても良い。

引継元クライアント（１）３は、引継先クライアント（２）５に対して引継用の引継情報を送信する（引継情報送信： ６−１１）。この引継情報には、少なくともコンテンツと再生開始位置とが含まれる。引継先クライアント（２）５は、受け取った引継用情報を基に、コンテンツサーバ１に対してコンテンツの取得要求を行う（コンテンツ要求： ６−１２）。コンテンツサーバ１は、引継先クライアント（２）５に対してコンテンツを送信する（コンテンツ送信： ６−１３）。引継先クライアント（２）５は、コンテンツサーバ１から受け取ったコンテンツを再生する（コンテンツ再生： ６−１４）。この処理手順を行うと、”すぐに引継が可能なクライアント”と”電源を入れる必要があるクライアント”とを区別してユーザに提示することが可能となる。

次に、本発明の第２の実施の形態によるコンテンツ視聴システムについて図面を参照しながら説明を行う。図１１は、本実施の形態によるコンテンツ視聴システムの一構成例を示す機能ブロック図である。図１１に示すように、本実施の形態によるコンテンツ視聴システムでは、コンテンツサーバ１と、コントローラ１０１と、レンダラ（１）１０３及びレンダラ（２）１０５、とが、ネットワークＮＴにより接続されている。

本実施の形態において、レンダラはコンテンツを再生する機能を有し、コントローラはコンテンツを引き継ぐための入力を行う。

図１２、図１３は、コントローラ１０１の内部におけるデータの流れと、コントローラ制御部のデータ送受信について示す図である。コントローラ１０１は、以下の部分から構成されている。

コントローラ１０１は、ネットワークＮＴ内のコンテンツサーバ１やレンダラ１０３、１０５との通信を行う通信部６７と、ユーザに対して、サーバ・コンテンツ・レンダラ・引継先の選択を行わせるユーザインタフェイス（ＵＩ）部４７と、コントローラ１０１の動作を制御するコントローラ制御部５２と、を備えている。

コントローラ制御部５２は、以下の部分から構成される。
１）ネットワークＮＴ内にあるコンテンツサーバ１に対して、存在確認を行い、存在通知の受信を行う、機器情報受信部３５。
２）ネットワークＮＴ内にあるコンテンツサーバ１に対して、コンテンツリスト要求を行い、コンテンツリストの受信を行う、コンテンツ情報受信部４３。
３）ネットワークＮＴ内にあるレンダラ１０３、１０５に対して、コンテンツの再生の指示を行う、再生指示送信部６５。
４）ネットワークＮＴ内でコンテンツを再生しているレンダラ１０３に対して、引継指示の送信を行う、引継指示送信部６１。
５）ネットワークＮＴ内にある引継元のレンダラ１０３および引継先のレンダラ１０５から、引継の状況についての通知を受信する、引継状況受信部６３。

より詳細には、図１２、図１３に示すように、通信部６７は、コントローラ制御部５２との間で、送受信データをやり取りする。機器情報受信部３５は、ＵＩ部４７がサーバ選択画面を表示し、ユーザ操作等によりサーバが選択されると、サーバ情報をコンテンツ情報受信部４３に送るとともに、コンテンツサーバ１との間で存在確認のやり取りを行う。コンテンツ情報受信部４３は、ＵＩ部４７がコンテンツ選択画面表示を行い、コンテンツを選択すると、そのコンテンツ情報を再生指示送信部６５に送る。そして、コンテンツサーバ１との間で、コンテンツリストの要求と受け取りを行う。

再生指示送信部６５は、ＵＩ部４７によるレンダラ選択画面表示からのレンダラ選択操作に応じて、再生指示をレンダラに送信する。引継状況受信部６３は、ＵＩ部に対して引継状況を知らせる。引継指示送信部６１は、ＵＩ部４７における引継先選択画面表示からの引継先選択操作に応じて、レンダラに引継指示を送る。

図１４及び図１５は、本実施の形態によるレンダラの一構成例を示す機能ブロック図であり、データの流れを合わせて示す図である。

本実施の形態によるレンダラ１０３、１０５は、以下の構成を有している。

ネットワークＮＴ内のコンテンツサーバ１・コントローラ１０１・レンダラ１０３とは異なるレンダラ１０５との通信を行う通信部１５３。
コンテンツ受信部１４５が受信したコンテンツを再生する、再生部１５１。
レンダラ１０３、１０５の動作を制御するレンダラ制御部１６０。

ここで、レンダラ制御部１６０は、以下の機能部を含んで構成される。
１）ネットワークＮＴ内にある別のレンダラ１０５からの存在確認に対して、自身のレンダラ１０３の情報を存在通知として送信する、機器情報送信部１３３。
２）ネットワークＮＴ内にある別のレンダラ１０５に対して、存在確認を行い、存在通知の受信を行う、機器情報受信部１３５。
３）ネットワークＮＴ内にあるコンテンツサーバ１に対して、コンテンツ要求を行い、コンテンツの受信を行う、コンテンツ受信部１４５。
４）ネットワークＮＴ内にある引継先レンダラ１０５に対して、リソース確保要求や引継情報送信を行う、引継情報送信部１４１。
５）ネットワークＮＴ内にある引継先レンダラ１０５から、リソース確保要求や引継情報の受信を行う、引継情報受信部１３７。
６）ネットワークＮＴ内にあるコントローラ１０１から、コンテンツの再生指示を受信する、再生指示受信部１６３。
７）ネットワークＮＴ内にあるコントローラ１０１から、再生中コンテンツの引継指示を受信する、引継指示受信部１６５。
８）ネットワークＮＴ内にあるコントローラ１０１に対して、引継の状況を通知する、引継状況送信部１６１。

引継指示受信部１６５がコントローラ１０１からの引継指示を受信すると、引継情報送信部１４１に対して引継指示を行う。引継情報送信部１４１は、機器情報受信部１３５との間で、存在確認指示と存在通知とのやり取りを行うとともに、再生部１５１に、再生停止指示を送り、また、引継状況送信部１６１に対して引継状況を送り、引継状況送信部１６１がコントローラ１０１に引継状況を送る。そして、別のレンダラ１０５との間で、リソース確保要求と引継情報と、リソース確保通知とのやり取りを行う。

機器情報受信部１３５は、別のレンダラ１０５との間で、存在確認と存在通知とのやり取りを行う。機器情報送信部１３３は、レンダラ１０５との間で、存在確認のやり取りを行う。引継状況送信部１６１は、引継情報受信部からの引継状況も受け取り、コントローラ１０１に対して引継状況を通知する。引継情報受信部１３７は、引継情報をコンテンツ受信部１４５に送る。コンテンツ受信部１４５は、コントローラ１０１からの再生指示を受け取る再生指示受信部１６３からのコンテンツ情報も受け取り、再生部１５１に対してコンテンツを送信する。そして、コンテンツサーバ１に対してコンテンツ要求を行い、要求したコンテンツを受け取る。通信部１５３は、レンダラ制御部１６０との間で、送受信データをやり取りする。

図１６は、本実施の形態によるコンテンツ視聴装置の動作例を示すシーケンス図である。このシーケンス図は、「コンテンツを再生する機能のみを持つレンダラ」と、「操作用のＵＩのみを持つコントローラ」を用いて引継を行う場合のシーケンス図である。

図１６に示すように、引継元レンダラ（１）１０３は、コンテンツサーバ１内のコンテンツを再生している（コンテンツ再生： ７−１）。引継元レンダラ（１）１０３のコンテンツ再生を、引継先レンダラ（２）１０５へ引き継ぐための引継入力が、コントローラ１０１で行われる（引継入力： ７−２）。コントローラ１０１は、引継元レンダラ（１）１０３に対して引継指示を送信する（引継指示： ７−３）。引継先レンダラとしてレンダラ（２）１０５が選択された場合、引継元レンダラ（１）１０３は、引継先レンダラ（２）１０５に対して、存在確認を行う（存在確認： ７−４）。引継先レンダラ（２）１０５の電源が入っていない場合には、引継先レンダラ（２）は存在確認に応答しない（応答なし： ７−５）。引継元レンダラ（１）１０３は、引継先レンダラ（２）１０５が存在確認に応答しない場合、コントローラ１０１にその旨を引継状況通知として通知する（引継情報通知： ７−６）。

コントローラ１０１は、例えば、「引継指示を受け付けました。引継先レンダラ（２）１０５の電源を入れると自動的に引継が行われます。」などと表示するようにしても良い（引継情報表示： ７−７）。引継元レンダラ（１）１０３は、コンテンツの再生を終了する（コンテンツ再生終了： ７−８）。このとき、コンテンツサーバ１に対して、送信停止指示を行う（コンテンツ送信停止： ７−８）。

そして、引継元レンダラ（１）１０３は、引継指示を内部に保存する（引継操作記憶： ７−９）。ここで、引継先レンダラ（２）１０５の電源が入れられるとする。引継先レンダラ（２）１０５は、起動時に（７−１０： 電源ＯＮ）、ネットワークＮＴ内の全ての機器に対して存在通知を送信する。

引継元レンダラ（１）１０３は、引継先レンダラ（２）１０５からの存在通知を受信すると（７−１１）、引継先レンダラ（２）１０５に対してリソース確保要求を行う（７−１２）。引継先レンダラ（２）１０５は、リソース確保要求に対して引継を行うためのリソースを確保し、引継元レンダラ（１）１０３に対してリソース確保通知を行う（リソース確保要求： ７−１３）。

引継元レンダラ（１）１０３は、引継先レンダラ（２）１０５に対して、引継用情報を送信する（引継情報送信： ７−１４）。この引継用の引継情報には、少なくともコンテンツと再生開始位置とが含まれる。引継先レンダラ（２）１０５は、受け取った引継情報を基に、コンテンツサーバ１に対してコンテンツの取得要求を行う（コンテンツ要求： ７−１５）。コンテンツサーバ１は、引継先レンダラ（２）１０５に対してコンテンツを送信する（コンテンツ送信： ７−１６）。引継先レンダラ（２）１０５は、コントローラ１に引継処理が行われたことを通知する（コンテンツ引継通知： ７−１７）。コントローラ１は、例えば、「レンダラ（２）１０５で引継再生を開始します。」などの表示をする（引継情報表示： ７−１８）。引継先レンダラ（２）は、コンテンツサーバ１から受け取ったコンテンツを再生する（コンテンツ再生： ７−１９）。

以上のように、このシーケンスでは、引継操作記憶（７−９）と電源ＯＮ（７−１０）との間においても、コントローラ１０１を使って操作が可能である。例えば、引継操作をキャンセルすることや、引継先を変更する処理を行うことができるようになる。

尚、引継入力の際には、引継先のクライアントやレンダラを指定する必要がある。引継先となりうるクライアントやレンダラの情報(ＩＰアドレス等の機器を指定する情報)は、どのように取得してもよいが、一例として以下に示す取得方法を用いることができる。

１）ネットワーク内に存在確認を送信し、受信した存在通知を解析することにより、クライアントやレンダラの情報を取得する。

ネットワーク内のクライアントやレンダラが起動時に送信する(または定期的に送信する)存在通知を解析することにより、クライアントやレンダラの情報を取得する。ユーザが、クライアントやレンダラの情報を手動で入力するようしにて、過去に接続したクライアントやレンダラの情報を記憶しておけば、情報を確認することができる。

上記の実施の形態において、添付図面に図示されている構成等については、これらに限定されるものではなく、本発明の効果を発揮する範囲内で適宜変更することが可能である。その他、本発明の目的の範囲を逸脱しない限りにおいて適宜変更して実施することが可能である。

また、本実施の形態で説明した機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。尚、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。

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

本発明は、コンテンツ視聴装置として利用可能である。

ＮＴ…ネットワーク、１…コンテンツサーバ、３…引継元クライアント（１）、５…引継先クライアント（２）、１１…サーバ制御部、１５…コンテンツ格納部、１７…機器情報送信部、２１…コンテンツ情報送信部、２３…コンテンツ送信部、２５…通信部、３１…クライアント制御部、３３…機器情報送信部、３５…機器情報受信部、３７…引継情報送信部、４１…引継情報受信部、４３…コンテンツ情報受信部、４５…コンテンツ受信部、４７…ＵＩ部、５１…再生部、５３…通信部、１０１…コントローラ、１０３、１０５…レンダラ。

Claims (5)

1. コンテンツを送信するコンテンツサーバと、コンテンツを再生するクライアントと、を有するコンテンツ視聴システムであって、
   第１のクライアントが前記コンテンツサーバから送信されているコンテンツを再生中に、コンテンツの送信先を変更する引継操作を行うＵＩ部により引継要求を受けると、
   前記第１のクライアントは、
   機器情報受信部により、引継先の第２のクライアントの状態確認を行い、前記状態確認の結果として、前記第２のクライアントが不在又はビジーである場合に、その旨を前記第２のクライアントから受信するとともに、前記第１のクライアントに引継情報として、コンテンツと再生開始位置とを保存し、前記第２のクライアントからの引継可能応答を待って、前記引継情報を前記第２のクライアントに送り、前記コンテンツサーバへの前記引継情報に基づくコンテンツ要求を促すクライアント制御部を有することを特徴とするコンテンツ視聴システム。
2. 前記第１のクライアントの前記クライアント制御部は、
   前記第２のクライアントが不在の場合には、存在通知の後に、前記第１のクライアントが前記第２のクライアントにリソース確保を要求することを特徴とする請求項１に記載のコンテンツ視聴システム。
3. 前記第１のクライアントの前記クライアント制御部は、
   前記第２のクライアントがビジーの場合には、ビジー解消通知の前に、前記第１のクライアントが前記第２のクライアントにリソース確保を要求することを特徴とする請求項１に記載のコンテンツ視聴システム。
4. 前記コンテンツサーバは、
   前記第１のクライアントと前記第２のクライアントとの間の存在確認のやり取りを、仲介するサーバ制御部を有することを特徴とする請求項１から３までのいずれか１項に記載のコンテンツ視聴システム。
5. 前記第１のクライアントと前記第２のクライアントとが、コンテンツを再生する機能を有するレンダラと、コンテンツを引き継ぐための入力を行うコントローラと、により、別体に構成されていることを特徴とする請求項１から４までのいずれか１項に記載のコンテンツ視聴システム。

Images