管理サーバ、および管理サーバの動作方法
【課題】「閉じた」プライベート再生システムにおいて、従来の視聴履歴に応じたリクエスト画面に反映されているのは、あくまでプライベート再生システム内のユーザー個人の視聴履歴のみである、という課題である。つまり、「閉じている」プライベート再生システム内の記録再生装置に記録されているコンテンツに関して、外の他人がどのような評価を持っているのか、といった他人の視聴履歴が反映されない。
【解決手段】以上の課題を解決するために、本発明は、ユーザーごとに「閉じている」プライベート再生システムにおいても、「開いて」他のユーザーの視聴履歴を反映したリクエスト画面を利用可能とするコンテンツ再生システムを提供する。
【解決手段】以上の課題を解決するために、本発明は、ユーザーごとに「閉じている」プライベート再生システムにおいても、「開いて」他のユーザーの視聴履歴を反映したリクエスト画面を利用可能とするコンテンツ再生システムを提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、家庭内などの記録再生装置に記録されたコンテンツを、専用の携帯再生装置にて再生するための技術に関する。
【背景技術】
【０００２】
従来、以下のようなコンテンツのプライベートな再生システムが提供されている。このプライベート再生システムでは、自宅のＨＤＤレコーダーなどで受信した番組や録画した番組、あるいはその他の記録再生装置にて取得、記録した音楽、テキスト、Ｗｅｂページなどのコンテンツデータを、ネットワークを介して携帯電話などの携帯再生装置に送信し再生することができる。そして、このようなコンテンツのプライベート再生システムにおいて、携帯電話などの携帯再生装置上で再生コンテンツを選択、リクエストするためのインターフェースが様々提供されている。
例えば特許文献１では、上記コンテンツのプライベート再生システムにおいて、携帯電話などの携帯再生装置でのコンテンツの視聴履歴を記憶し、記憶した視聴履歴を記録再生装置に送信する、という構成を備える携帯再生装置（携帯型情報端末装置）に関する技術が開示されている。そして、このような視聴履歴を利用して、例えば視聴途中のコンテンツを上位に、あるいは視聴途中コンテンツのみ表示する、といった具合のリクエスト画面（コンテンツの再生リクエストのためのインターフェース画面）を携帯再生装置や記録再生装置に表示することができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２８６８５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、上記技術には以下のような課題がある。すなわち、前記視聴履歴に応じたリクエスト画面に反映されているのは、あくまでプライベート再生システム内のユーザー個人の視聴履歴のみである、という課題である。つまり、「閉じている」プライベート再生システム内の記録再生装置に記録されているコンテンツに関して、世間一般（自身のプライベート再生システム外の他人）がどのような評価を持っているのか、といった他人の視聴履歴が反映されない、ということである。
【課題を解決するための手段】
【０００５】
以上の課題を解決するために、本発明は、ユーザーごとに「閉じている」プライベート再生システムにおいても、「開いて」他のユーザーの視聴履歴を反映したリクエスト画面を利用可能とする管理サーバを提供する。
【０００６】
具体的には、記録再生装置とこの記録再生装置に記録されたコンテンツ専用の再生リクエスト機能を有する携帯再生装置とからなる複数のプライベート再生システムにおける前記再生リクエストを管理する管理サーバであって、同一コンテンツに対する再生リクエストを、プライベート再生システムを横断的に集計する集計部と、集計部での集計結果に基づく再生リクエストのためのインターフェース画面であって、前記集計された再生リクエストで示されるコンテンツのコンテンツ名を含むリクエスト画面を生成し、前記携帯再生装置に対して送信するリクエスト画面送信部と、を有するとともに、前記リクエスト画面に含まれるコンテンツ名に対応するコンテンツが前記リクエスト画面の送信先のプライベート再生システムに存在しないと判断した場合、前記コンテンツ名に対応するコンテンツを取得可能なサイトへのリンクを前記リクエスト画面に挿入することを特徴とする管理サーバを提供する。
【発明の効果】
【０００７】
以上のような構成をとる本発明によって、上記「閉じた」プライベート再生システムにおいても、プライベートユーザー以外の他人の視聴回数（リクエスト回数）が「開いて」反映されたリクエスト画面を利用することができるようになる。
【０００８】
そして、一般的にユーザーにおけるコンテンツへの興味、とりわけ放送番組や音楽などのエンターテインメント系コンテンツへの興味に関しては、選択の正当性を事象の一致に求める心理的傾向から、視聴回数などで表される他人の評価に左右され易い。したがって、（プライベートユーザー以外の）他人の視聴回数が反映されたリクエスト画面をプライベート再生システムのユーザーに対して提示することで、従来以上に該リクエスト画面に表示されたコンテンツを視聴したい、と思わせる訴求効果も期待できる。
【発明を実施するための形態】
【０００９】
以下に、図を用いて本発明の実施の形態を説明する。なお、本発明はこれら実施の形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施しうる。なお、実施例１において、主に請求項１、２、６、７について説明する。また、実施例２において、主に請求項３、８について説明する。また、実施例３において、主に請求項４、９について説明する。また、実施例４において、主に請求項５、１０について説明する。
【００１０】
≪実施例１≫
<概要>
図１は、本実施例のコンテンツ再生システムにおける携帯再生装置の一例である携帯電話上に表示されたリクエスト画面の一例を表す図である。この図にあるように、プライベート再生システムαを構成する記録再生装置αに対して再生リクエストを送信するためのリクエスト画面が、同プライベート再生システムに属する携帯電話αのディスプレイにて表示されている。そして、そのリクエスト画面には、「１．月曜ドラマ：１０３５２人」、「２．ニュース１０：８９９８人」、「３．クイズ三択：２４９４人」といった具合に、他のプライベート再生システムβやγ、・・・を横断して集計されたそのコンテンツに関する視聴人数（リクエスト数）順で並べられたコンテンツ名が表示されている。
【００１１】
このように本実施例のコンテンツ再生システムでは、コンテンツの視聴人数（リクエスト数）を、プライベート再生システムを横断して「開いて」集計する。そして、その集計結果を反映したリクエスト画面を「閉じた」プライベート再生システムにて利用することができる。それにより、ユーザーはコンテンツに関する他人の関心度などを知ることができ、例えばそのような世間一般の関心度を参考として、自身のプライベート再生システムにて見たいコンテンツの再生リクエストを実行することができる。
【００１２】
<機能的構成>
図２は、本実施例のコンテンツ再生システムにおける機能ブロックの一例を表す図である。この図にあるように、本実施例のコンテンツ再生システムは、「プライベート再生システム」（０２１０α、０２１０β、０２１０γ）を複数備えるとともに、それらプライベート再生システムでのリクエストを管理する「管理サーバ」（０２００）を含むシステムである。
【００１３】
なお、以下に記載する本システムを構成する各装置やサーバの機能ブロックは、ハードウェア、ソフトウェア、又はハードウェア及びソフトウェアの両方として実現され得る。具体的には、コンピュータを利用するものであれば、ＣＰＵや主メモリ、バス、あるいは二次記憶装置（ハードディスクや不揮発性メモリ、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭなどの記憶メディアとそれらメディアの読取ドライブなど）、印刷機器や表示装置、その他の外部周辺装置などのハードウェア構成部やその外部周辺機器用のＩ／Ｏポート、それらハードウェアを制御するためのドライバプログラムやその他アプリケーションプログラム、情報入力に利用されるユーザーインターフェースなどが挙げられる。
【００１４】
またこれらハードウェアやソフトウェアは、主メモリ上に展開したプログラムをＣＰＵで演算処理したり、メモリやハードディスク上に保持されているデータや、インターフェースを介して入力されたデータなどを加工、蓄積、出力処理したり、あるいは各ハードウェア構成部の制御を行ったりするために利用される。また、この発明は装置として実現できるのみでなく、方法としても実現可能である。また、このような発明の一部をソフトウェアとして構成することができる。さらに、そのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品、及び同製品を記録媒体に固定した記録媒体も、当然にこの発明の技術的な範囲に含まれる（本明細書の全体を通じて同様である）。
【００１５】
ここで、まず、「プライベート再生システムα」（０２１０α）について説明する。なお、図では省略しているがプライベート再生システムβやγも、以下に説明するα同様の構成を備えている。
【００１６】
「プライベート再生システムα」（０２１０α）は、「記録再生装置」（０２１１α）と、この記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する「携帯再生装置」（０２１２α）とからなる。
【００１７】
「記録再生装置」（０２１１α）とは、コンテンツデータを記録、再生する機能を備えた端末装置であって、例えば放送番組コンテンツを受信し記録保持する、ＨＤＤ／ＤＶＤなどの各種レコーダーなどが挙げられる。なお、以下にコンテンツデータの一例として記録媒体に記録されている放送番組の動画データ、又はチューナにて受信中の放送番組の動画データを例に挙げ説明するが、もちろん、コンテンツデータはそれに限定されず、その他の動画データや音楽データ、書物などのテキストデータ、Ｗｅｂページデータなどであっても良い。
【００１８】
図３は、この記録再生装置における機能ブロックの一例を表す図である。この図にあるように、「記録再生装置」（０３１１）は、「コンテンツ保持部」（０３１１Ａ）と、「コンテンツリスト送信部」（０３１１Ｂ）と、「リクエスト受信部」（０３１１Ｃ）と、「コンテンツ送信部」（０３１１Ｄ）と、からなる。
【００１９】
「コンテンツ保持部」（０３１１Ａ）は、放送番組データやその他の動画データ、音楽データ、テキストデータ、Ｗｅｂページデータなどのコンテンツを保持する機能を有し、例えばＨＤＤやＤＶＤ、不揮発性メモリなどの記録媒体によって実現することができる。そして、プライベート再生システムでは、携帯再生装置である携帯電話などからのリクエストに応じて、このコンテンツ保持部に保持されているコンテンツがその携帯電話などに送信されることになる。
【００２０】
「コンテンツリスト送信部」（０３１１Ｂ）は、後述する管理サーバ（０３００）に対してコンテンツリストを送信する機能を有する。「コンテンツリスト」とは、コンテンツ保持部にて保持しているコンテンツのタイトル名や識別情報などをリスト化したデータであって、このコンテンツリストを参照して、管理サーバではそれぞれのプライベート再生システムごとに適したリクエスト画面を生成することができる。なお、このコンテンツリストを利用したリクエスト画面の詳細については、管理サーバの構成要件である「リクエスト画面送信部」の項にて説明する。
【００２１】
「リクエスト受信部」（０３１１Ｃ）は、携帯電話などの携帯再生装置から送信されるコンテンツ再生のリクエストを受信する機能を有する。ここで受信するリクエストには、例えば携帯再生装置が携帯電話であれば電話番号等の携帯再生装置を特定するための情報が含まれており、記録再生装置では例えばその電話番号を宛先として次のようにコンテンツを送信することになる。なお、このリクエスト受信部は、図に示すように携帯電話などから出力されたリクエストを管理サーバ経由で受信しても良いし、後述するように携帯電話などから管理サーバを経由せずに送信されたリクエストを受信するよう構成されていても良い。
【００２２】
「コンテンツ送信部」（０３１１Ｄ）は、リクエストの受信に応じて、自身に専用の携帯再生装置に対してコンテンツを送信する機能を有する。なお、携帯再生装置が自身に専用のものであるかの判断は、例えば受信したリクエストに含まれる電話番号などと、後述するような登録処理によって取得した電話番号などのマッチング処理などにより行うと良い。また、このコンテンツ送信部で実行するコンテンツの送信に関して、例えば管理サーバ経由でコンテンツを送信することで、送受信されるコンテンツの管理を管理サーバにて行うよう構成しても良い。もちろん、トラフィックの関係などからコンテンツの送信は管理サーバを経由しないで実行されても構わない。
【００２３】
そして、この記録再生装置のコンテンツ保持部に保持されているコンテンツの再生用のリクエストを送信し、コンテンツ送信部から送信されたコンテンツを取得するのが次の「携帯再生装置」（０３１２。図２中では０２１２α）である。
【００２４】
「携帯再生装置」（０２１２α）は、前述のように、この記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する端末装置である。なお、この携帯再生装置について、本明細書では主に携帯電話を例に挙げて説明する。もちろん、携帯再生装置はＰＤＡ、スマートフォン、ノートパソコン、ネットワーク対応携帯動画プレイヤー、あるいは記録再生装置専用に設計などされた独自の携帯情報端末などであっても良い。
【００２５】
図４は、この携帯再生装置における機能ブロックの一例を表す図である。この図にあるように、「携帯再生装置」（０４１２）は、「リクエスト画面受信部」（０４１２Ａ）と、「リクエスト送信部」（０４１２Ｂ）と、「コンテンツ受信部」（０４１２Ｃ）と、「コンテンツ再生表示部」（０４１２Ｄ）と、からなる。
【００２６】
「リクエスト画面受信部」（０４１２Ａ）は、管理サーバから送信されるリクエスト画面を受信する機能を有する。なお、リクエスト画面については管理サーバの構成要件である「リクエスト画面送信部」の項にて後述するが、その特徴は、他のプライベート再生システムでのリクエスト数が横断的に集計された集計結果が反映されている点である。そして、ここで受信したリクエスト画面をディスプレイなどにて表示し、そのリクエスト画面上のコンテンツ名などを選択することで、コンテンツ再生用のリクエストが携帯電話などの携帯再生装置に受付けられる。
【００２７】
「リクエスト送信部」（０４１２Ｂ）は、リクエスト画面受信部にて受信したリクエスト画面での選択に応じてコンテンツ再生用のリクエストを送信する機能を有する。このリクエスト送信部からのリクエスト送信は、後述するように管理サーバ経由で記録再生装置に送信するよう構成しても良いし、管理サーバを経由せずに送信するよう構成しても良い。
【００２８】
図５は、携帯再生装置のリクエスト送信部から記録再生装置に対して送信されるリクエストの一例を表す概略図である。この図にあるように、前述のリクエスト画面の番組名選択などにより生成されたリクエストには「Title（番組名）」や「Channel（放送チャンネル）」、「Time（放送時間）」、「Region（放送地域）」などの、再生を要求するコンテンツを識別するための情報が記述されている。そして、プライベート再生システムでは、このようなリクエストを参照し識別されるコンテンツを専用の携帯再生装置である携帯電話などに対して送信することで、記録再生装置に記録されているコンテンツの携帯電話などでの再生を実行している。
【００２９】
また、このリクエストに含まれる「番組名」などのコンテンツ識別情報は、例えば、記録再生装置がコンテンツ管理用にコンテンツに別途付している「Ａ１２３４」などのＩＤ情報などであっても構わない。またそのＩＤ情報は、例えば電子番組表の当該番組に付されているＩＤ情報を流用して付されたものであっても良い。またそのような場合には、このコンテンツ再生システムに属する全てのプライベート再生システムにおいて同一の電子番組表を利用するよう構成することで、同一のコンテンツには同一のＩＤ情報が付されるようにしても良い。そのようにすることで、後述するコンテンツの同一性の識別がより簡便な処理で実行できるようになる。
【００３０】
また、このリクエストには携帯再生装置に固有に付されている「Tel No.（電話番号）」や、あるいはＭＡＣアドレスや製造番号なども記述されている。リクエストを受信する記録再生装置では、この「Tel No.」などを利用してコンテンツの送信先を特定しコンテンツを送信することができる。また、後述するようにこの「Tel No.」などを利用して携帯再生装置が自身に専用のものであるか判断することで、プライベート再生システムのプライベート性を確保することもできる。
【００３１】
「コンテンツ受信部」（０４１２Ｃ）は、リクエストに応じて記録再生装置より送信されたコンテンツを受信する機能を有する。「コンテンツ再生表示部」（０４１２Ｄ）は、コンテンツ受信部にて受信したコンテンツを、例えばディスプレイなどに再生表示する機能を有する。このようにして、このプライベート再生システムでは、携帯再生装置である携帯電話などからのリクエストに応じて記録再生装置のコンテンツを携帯電話などにて再生表示することができる。
【００３２】
なおプライベート再生システムにおける記録再生装置と携帯再生装置との関係性を示す「専用」とは、記録再生装置が、許可された携帯再生装置からのコンテンツ再生リクエストのみ受付けるよう構成されていることをいう。ある携帯再生装置をある記録再生装置の専用とするための方法としては、例えば、予め記録再生装置に合わせて設定用意された専用端末を携帯再生装置として利用する方法が挙げられる。あるいは一般的な携帯電話やＰＤＡ、ノートパソコン、ネットワーク対応携帯動画プレイヤーなどの携帯情報端末を、この記録再生装置に各種識別情報などを登録することで専用の携帯再生装置として利用する方法なども挙げられる。
【００３３】
図６は、一般的な携帯情報端末を、記録再生装置の専用とするための情報登録の一例を説明するための図である。この図にあるように携帯再生装置が携帯電話であれば、設定登録処理によってその電話番号「０８０−１１１１−××××」が、記録再生装置の通信ユニットに登録される。そしてリクエストに含まれる電話番号と、登録された電話番号「０８０−１１１１−××××」とをＣＰＵの論理演算処理で一致するか判断する。そして一致した場合には記録再生装置はリクエストに応じた処理を行い、一致しなかった場合には非対応とすることで、一般的な携帯電話端末を、記録再生装置の専用とすることができる、という具合である。また、携帯電話番号以外にも、例えば、機器固有に設定されているＳＩＭ（Subscriber Identity Module）カードの識別情報や、電子メールアドレスなどを利用しても良い。あるいは携帯再生装置が携帯電話端末以外であればＭＡＣアドレスや装置固有の製造番号などを利用しても良い。また図示していないが記録再生装置の通信ユニットのＭＡＣアドレス「００−０２−Ｃ８−５Ｅ−××−××」などを携帯電話端末に登録しても良い。
【００３４】
このように、プライベート再生システムαは、例えば登録された電話番号などを参照することで、他のプライベート再生システムβやγの携帯電話などの携帯再生装置からの再生リクエストには応じないよう処理する、という「閉じた」プライベート再生システムとなっている。
【００３５】
しかし、本実施例のコンテンツ再生システムでは、図７に示すように、このプライベート再生システム内の携帯電話などの携帯再生装置からのリクエスト送信に際し、同時に該リクエストを次のような構成を備える管理サーバにも送信させる（ａ）、あるいは管理サーバを経由して送信させる（ｂ）。それによって、このような「閉じた」プライベート再生システムにおいても、管理サーバを利用することで、他のプライベート再生システムも対象として「開いて」集計された視聴回数が反映されたリクエスト画面を利用することができる、ということを特徴とする。
【００３６】
図２に戻り、次に、コンテンツ再生システムに含まれる「管理サーバ」について説明する。「管理サーバ」（０２００）は、「集計部」（０２０１）と、「リクエスト画面送信部」（０２０２）と、を有する。なお、この管理サーバは、プライベート再生システムにおけるリクエストを管理する機能を有するが、この「リクエストの管理」とは、以下に記載する「集計部」におけるリクエストの横断的集計や「リクエスト画面送信部」におけるリクエスト画面の送信に関連して実行するリクエストの取得、保持、識別判断などの処理をいう。
【００３７】
「集計部」（０２０１）は、同一コンテンツに対するリクエストを、プライベート再生システムを横断的に集計する機能を有する。なお、この集計部での「リクエストの横断的な集計」は、例えば前述のようにプライベート再生システム内のリクエストを管理サーバにも送信させる、あるいは管理サーバを経由して送信させることで実行することができる。
【００３８】
図８は、この集計部における複数のプライベート再生システムでの横断的なリクエスト数集計の一例を表す概念図である。この図にあるように、プライベート再生システムβにて携帯電話などから出力された「リクエスト：月曜ドラマ」が、管理サーバ経由にて同じプライベート再生システムβに属する記録再生装置に送信される。また、プライベート再生システムγや、プライベート再生システムαにて携帯電話などから記録再生装置に送信された「リクエスト：月曜ドラマ」や、「リクエスト：月８"鳥獣戯画"」が、プライベート再生システム内でのリクエスト送信とともに管理サーバに対しても送信される。
【００３９】
そして管理サーバでは、このようにして取得したリクエストの、例えば「月曜ドラマ」や「月８"鳥獣戯画"」などのタイトルからコンテンツの同一性を識別し、同一のコンテンツごとにそのリクエスト数を集計する、という具合である。
【００４０】
なお、本実施例のコンテンツ再生システムに含まれる複数のプライベート再生システムは、例えば同一の電子番組表を利用するなどしなければ、コンテンツ識別情報などに互換性がない各々が独立したシステムとなる可能性が高い。つまり例えばデータ名の変更などから同一コンテンツであってもリクエストに含まれるコンテンツタイトルが異なる、などのケースもあり得る。そこで管理サーバでのリクエストの横断的集計に必要となる「コンテンツの同一性の識別」に関しては、放送番組であればリクエストに含まれる「放送チャンネル」や「放送時間」、「放送地域」などの情報を利用して、図８中の「月曜ドラマ」と「月８"鳥獣戯画"」の同一性などを識別し集計しても良い。また、放送番組では同一コンテンツであっても放送地域ごとにそのチャンネル情報や放送時間情報は異なることもある。そこで電子番組表情報を利用して「地域情報」をキーとして番組情報の検索取得を行い、その番組情報を利用して同一性を識別するよう構成しても良い。
【００４１】
また、取得したリクエストに含まれるコンテンツの識別情報が、前述のように「Ａ１２３４」などの記録再生装置が管理用にコンテンツに付した識別ＩＤである場合には、記録再生装置からその識別ＩＤとコンテンツタイトルなどを関連付けたコンテンツリストを取得することで、上記コンテンツの同一性の識別処理を行うと良い。
【００４２】
またリクエストのあったコンテンツそのものの全部又は一部を管理サーバにて取得するよう構成することで、コンテンツの内容そのもの、例えば音声周波数やフレームデータ、テキスト文章、などのマッチング処理によってコンテンツの同一性を識別するよう構成しても良い。
【００４３】
図９は、このようなコンテンツデータのマッチング処理による同一性の識別の一例を説明するための図である。この図にあるように、例えば音声周波数マッチング処理であれば、図中（ａ）の所定範囲内の音声周波数の波形が、図中（ｂ）に含まれているかをマッチング処理によって判断する。そして閾値以上のマッチング率を示した場合にコンテンツが同一であると判断する、という具合である。また、フレームマッチング処理であれば、図中（ａ）のコンテンツに含まれるフレーム画像が、図中（ｂ）のコンテンツに含まれているかをマッチング処理によって判断する。そして閾値以上のマッチング率を示した場合にコンテンツが同一であると判断する、という具合である。
【００４４】
このように、本実施例では「閉じた」プライベート再生システムにおいて携帯電話などの携帯再生装置から記録再生装置に対して送信されるリクエストを管理サーバにて取得する。そしてリクエストに含まれるコンテンツの識別情報やその他識別情報、マッチング処理などを利用することで同一コンテンツを識別し、コンテンツ別に複数のプライベート再生システムでのリクエストを横断的に集計することができる。そして、このように「開いて」集計したリクエスト回数から、次の「リクエスト画面送信部」によって集計された視聴回数が反映されたリクエスト画面を、「閉じた」プライベート再生システムに対して送信することができる。
【００４５】
なお、ここで集計されるリクエストは、上記携帯電話などから記録再生装置へのリクエスト以外にも、記録再生装置自身が再生を行うためのリクエストなども含まれていて構わない。また、上記のようにリクエストがあった時点でリクエストをカウントする以外に、そのリクエストによって実際に携帯電話などでのコンテンツ再生が実行されたか否かを示す情報を取得した時点でカウントすることで、リクエストに応じたコンテンツ実再生数を集計するよう構成しても良い。
【００４６】
また、この集計部での集計処理は、所定期間内のみの集計結果でも良いし、現在までの累積集計数であっても良い。また、連続ドラマ等のコンテンツであれば各話ごとの集計でも良いしシリーズ累計での集計でも良い。あるいは再生終了を示す情報を取得することで、カウント対象となるリクエストを、まだ再生終了していない現在再生中のコンテンツへのリクエストのみとする構成であっても良い。
【００４７】
また、管理サーバに性別や年齢、居住地などのユーザー情報を登録しておき、かつリクエストにユーザーＩＤを含むよう構成することで、性別や年齢別などのリクエスト数を集計するようにしても良い。また、予めプライベート再生システムごとにコンテンツリストを取得しておき、類似するコンテンツリストのプライベート再生システムをグループ化することで、同グループに属するプライベート再生システムにおけるリクエストのみを集計するように構成しても良い。それによって、コンテンツに対する興味傾向が類似すると思われるユーザーのリクエスト数を中心に集計されたリクエスト画面をユーザーに提供することもできる。
【００４８】
「リクエスト画面送信部」（０２０２）は、集計部（０２０１）での集計結果に基づいて携帯電話などの携帯再生装置に対してリクエストのためのインターフェース画面であるリクエスト画面を送信する機能を有する。「集計結果に基づくリクエスト画面」とは、例えば、コンテンツ別のリクエスト集計数の多い順にコンテンツ名やサムネイル画像などを並べて表示するリクエスト画面が挙げられる。あるいは世間一般には知られていないコンテンツに興味を示すようなユーザーに対しては、逆にリクエスト集計数の少ない順に並べて表示するリクエスト画面を送信しても良い。また、集計数が閾値以上／以下のコンテンツのみ表示するリクエスト画面なども挙げられる。
【００４９】
図１０は、このリクエスト画面送信部から送信されるリクエスト画面の一例を表す図である。図にあるように、このリクエスト画面は、携帯再生装置である携帯電話αのリクエスト送信先である記録再生装置αの保持コンテンツリストを元にしたリクエスト画面である。
【００５０】
つまり、記録再生装置αの保持コンテンツリストを、管理サーバが携帯電話αの識別ＩＤなどを利用して別途取得し、集計部での集計結果を反映させることで生成したリクエスト画面である。このように記録再生装置αに専用の携帯電話αに対しては、記録再生装置αが保持していて、すぐにリクエスト再生が可能なコンテンツのみがリクエスト画面に表示されるようにしても良い。
【００５１】
あるいは図１１に示すように、管理サーバが管理している全部又は一部のコンテンツの、例えばリクエスト数集計結果順にコンテンツ名を並べたリクエスト画面であっても良い。
【００５２】
図１１は、このリクエスト画面送信部から送信されるリクエスト画面の、別の一例を表す図である。この図にあるように、このリクエスト画面は、記録再生装置αの保持するコンテンツに関わらず、管理サーバが管理している全部又は一部のコンテンツのリクエスト数集計結果順にコンテンツ名などを並べたリクエスト画面である。このようにして、ユーザーは自身のプライベート再生システムでは記録しておらず再生できないコンテンツに関しても、そのリクエスト数など世間一般の関心度を知ることができる。
【００５３】
なお図１１に示すように、このリクエスト画面においては、記録再生装置αの保持コンテンツリストを利用して、記録再生装置αが保持していないコンテンツに関して白抜き文字やアイコン添付など通常とは異なった表示を行い、すぐの再生ができないことを通知可能に構成しても良い。
【００５４】
また、記録再生装置αが保持していないコンテンツに関しては、記録再生装置にて新規に記録されるようにするための記録リクエストを送信する「Ｇｅｔ」ボタンなどが表示されるようにしても良い。例えばリクエスト画面上でこのボタンをクリックすると、電子番組表などを参照し、同一コンテンツの再放送などがあるか検索し、あれば予約録画命令（記録リクエスト）を生成し記録再生装置に送信する、という具合である。あるいは音楽コンテンツであればネットワーク上の音楽データ販売サイトへのリンクを利用して、ボタン押下によってそのサイトにユーザーを誘導する、あるいは自動的にそのサイトでの該音楽コンテンツの購入リクエストを行う、といった具合である。
【００５５】
また、このリクエスト画面を利用して選択されたコンテンツのリクエストも、もちろん管理サーバに送信され、集計部での集計処理に用いられるよう構成すると良い。
【００５６】
このように本実施例のコンテンツ再生システムによって、ユーザーごとに「閉じた」プライベート再生システムにおいて、プライベートユーザー以外の他人のコンテンツ別リクエスト回数が反映されたリクエスト画面を利用することができるようになる。
【００５７】
なお、図１０や１１に示すような、記録再生装置の保持コンテンツリストを利用したリクエスト画面の生成、取得処理は、具体的には例えば以下のようにして実行されると良い。まず、記録再生装置から取得した保持コンテンツリストに含まれるコンテンツタイトルなどコンテンツの識別情報が、管理サーバ自身の保持するカウントリストのコンテンツ識別情報に含まれているか、をＣＰＵの論理演算処理によって判断し、識別情報が一致するものを抽出する。そして図１０のリクエスト画面の生成、取得においては、抽出したコンテンツの識別情報に該当するコンテンツのみをリスト化などする、という具合である。一方、図１１のリクエスト画面の生成、取得においては、管理サーバ自身の保持するカウントリストのコンテンツ識別情報のうち、抽出されたコンテンツのみをリクエスト可能とし、それ以外のコンテンツに関してはリクエスト不可のアイコンを添付したり、そのコンテンツを取得可能なサイトへのリンクを挿入したりする、という具合である。
【００５８】
ところで上記構成要件によるリクエストの横断的集計処理やリクエスト画面の送信処理を行うためには、当然、携帯再生装置である携帯電話などからのリクエストを取得するための構成要件や、コンテンツリストを取得するための構成要件なども必要となる。以下、そのような上記説明した「集計部」や「リクエスト画面送信部」の処理に関し副次的に必要となる構成要件について簡単に説明する。
【００５９】
図１２は、この管理サーバにおけるさらに詳細な機能ブロックの一例を表す図である。この図にあるように、「管理サーバ」（１２００）は、「集計部」（１２０１）と、「リクエスト画面送信部」（１２０２）と、を有する。なお、これら「集計部」と「リクエスト画面送信部」はすでに記載済みであるので、その詳細な説明は省略する。
【００６０】
そして、この管理サーバは、さらに「リクエスト取得部」（１２０３）と、「コンテンツリスト取得部」（１２０４）と、「同一コンテンツ識別部」（１２０５）と、を有し、また場合によっては「リクエスト転送部」（１２０６）などを有していても良い。
【００６１】
「リクエスト取得部」（１２０３）は、携帯電話などの携帯再生装置から出力されたリクエストを、前述のようにしてプライベート再生システムを横断して取得する機能を有する。そして、ここで取得したリクエストを、次の同一コンテンツ識別部にて同一コンテンツごとに分類し、「集計部」にて同一コンテンツ別に横断的に集計する。また、場合によっては記録再生装置に取得したリクエストを転送しても良い。
【００６２】
「コンテンツリスト取得部」は、記録再生装置からコンテンツリストを取得する機能を有する。そして、ここで取得したコンテンツリストを利用することで、図１０や図１１で説明したようなリクエスト画面を生成、取得することができる、という具合である。
【００６３】
「同一コンテンツ識別部」（１２０５）は、取得したリクエストに関し、そのリクエスト対象のコンテンツを識別する機能を有する。この同一コンテンツ識別部でのコンテンツ識別方法としては、具体的には、前述のようにリクエストに含まれる「コンテンツタイトル」からリクエスト対象のコンテンツを識別する方法が挙げられる。あるいは、図示しないコンテンツ取得部にてコンテンツの一部を取得し、前述のマッチング処理をＣＰＵの論理演算処理により実行することでコンテンツを識別する方法も挙げられる。そして、ここでコンテンツを識別することで、集計部にて同一コンテンツごとに分類し、そのリクエスト数をプライベート再生システムを横断して集計することができる、という具合である。
【００６４】
なお、リクエスト取得部で取得したリクエストが、管理サーバを経由して記録再生装置に送信されるよう構成されている場合、「リクエスト転送部」（１２０６）にて取得したリクエストを転送すると良い。
【００６５】
<ハードウェア的構成>
図１３は、上記機能的な各構成要件をハードウェアとして実現した際の、コンテンツ再生システムの管理サーバにおける構成の一例を表す概略図である。この図を利用して管理サーバでのリクエストの集計及びリクエスト画面の送信処理におけるそれぞれのハードウェア構成部の働きについて説明する。
【００６６】
この図にあるように、本実施例のコンテンツ再生システムに含まれる管理サーバは、各種演算処理を行う「ＣＰＵ（中央演算装置）」（１３０１）と、「主メモリ」（１３０２）と、を備えている。また集計結果などを保持する「ＨＤＤ」（１３０３）や、プライベート再生システムと情報の送受信を行う「Ｉ／Ｏ（インプット／アウトプット）」（１３０４）も備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。
【００６７】
また、本実施例のコンテンツ再生システムに含まれる携帯電話などの携帯再生装置αも同様に、各種演算処理を行う「ＣＰＵ」（１３１１）と、「主メモリ」（１３１２）と、を備えている。また管理サーバや記録再生装置と情報の送受信を行う「Ｉ／Ｏ」（１３１３）や、表示用にコンテンツを展開する「フレームメモリ」（１３１４）、コンテンツを再生表示する「ディスプレイ」（１３１５）も備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。
【００６８】
また、「主メモリ」は、各種処理を行うプログラムを「ＣＰＵ」に実行させるために読み出すと同時にそのプログラムの作業領域でもあるワーク領域を提供する。また、この「主メモリ」や「ＨＤＤ」、「フラッシュメモリ」にはそれぞれ複数のアドレスが割り当てられており、「ＣＰＵ」で実行されるプログラムは、そのアドレスを特定しアクセスすることで相互にデータのやりとりを行い、処理を行うことが可能になっている。
【００６９】
ここで、プライベート再生システムαやβ、γの携帯電話などの携帯再生装置にて図示しない「ＵＩ（ユーザーインターフェース）」によってコンテンツ再生のリクエスト操作が実行される。すると、その操作に応じてコンテンツの識別情報や自身の電話番号等を含むリクエストが「主メモリ」に格納され、管理サーバ経由で記録再生装置に送信するため「Ｉ／Ｏ」から出力される。あるいは記録再生装置と管理サーバとのそれぞれにあててリクエストが別々に送信される。
【００７０】
すると管理サーバでは、そのリクエストを「Ｉ／Ｏ」にて受信し、「主メモリ」のアドレス１に格納する。そしてこのようにして取得した様々なリクエストに含まれる例えば「タイトル」などのコンテンツ識別情報を利用して、「ＣＰＵ」の論理演算処理によりコンテンツの同一性の識別処理を実行する。そして識別されたコンテンツ毎に、そのリクエスト数の加算、集計処理をＣＰＵのカウント処理によって実行する。そして集計結果をカウントリストとして「ＨＤＤ」のアドレス１に格納する。
【００７１】
一方、携帯電話などの携帯再生装置の「ＵＩ」が操作され「Ｉ／Ｏ」からリクエスト画面の送信要求があった場合などには、管理サーバにて、その「カウントリスト」を利用して「リクエスト画面」の生成、送信処理が行われる。まず、リクエスト画面の送信要求に含まれる携帯再生装置αの識別情報を利用して、リクエスト送信先の記録再生装置のＭＡＣアドレスを取得する。そして、その記録再生装置の保持コンテンツリストの取得要求を該記録再生装置に送信する。そして要求に応じて該記録再生装置から「Ｉ／Ｏ」にて取得した保持コンテンツリストを「主メモリ」のアドレス２に格納する。
【００７２】
そして、「ＨＤＤ」に格納されたリクエスト数の集計結果であるカウントリストと、記録再生装置の保持コンテンツリストから図１０や図１１で示すようなリクエスト画面用の情報を生成し、「主メモリ」のアドレス３に格納する。そして、そのリクエスト画面用の情報を「Ｉ／Ｏ」から「携帯再生装置α」に送信する、という具合である。
【００７３】
また、そのリクエスト画面を利用して携帯電話などである携帯再生装置αから出力されたリクエストを「Ｉ／Ｏ」にて取得する。そして、そのリクエストで示されるコンテンツのリクエスト数加算、集計処理が「ＣＰＵ」の演算処理により実行され、カウントリストが更新される。そして、リクエストが管理サーバ経由で記録再生装置に送信されるよう構成されている場合には、そのリクエストに含まれる送信先の記録再生装置に対して、該リクエストを「Ｉ／Ｏ」から送信する。
【００７４】
そして、そのリクエストを受信した記録再生装置では、例えばリクエストに含まれる電話番号と、前述のように自身に登録されている登録機器を示す電話番号とが一致するか否か、を自身の「ＣＰＵ」の論理演算処理によって判断する。そして一致するとの判断結果である場合には、自身専用の携帯再生装置からのリクエストであるとして、コンテンツを携帯電話などの携帯再生装置に対して送信する。
【００７５】
そして、携帯電話などの携帯再生装置では、「Ｉ／Ｏ」にてそのコンテンツを受信し、その受信データを「フレームメモリ」に展開する。そして展開したコンテンツデータを「ディスプレイ」に表示する、という具合である。
【００７６】
<処理の流れ>
図１４は、本実施例のコンテンツ再生システムに含まれる管理サーバにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。この図にあるように、まず、記録再生装置とこの記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する携帯電話などの携帯再生装置とからなるプライベート再生システムを複数備えるとともに、前記リクエストを管理する管理サーバを含むコンテンツ再生システムにおいて、管理サーバは、同一コンテンツに対するリクエストを、プライベート再生システムを横断的に集計する（ステップＳ１４０１）。
【００７７】
そして、集計結果に基づいてリクエスト画面を取得し（ステップＳ１４０２）、取得したリクエスト画面を携帯電話などの携帯再生装置に対して送信する（ステップＳ１４０３）。
【００７８】
図１５は、本実施例のコンテンツ再生システムにおいて、リクエストを横断的に集計するまでの処理の流れの一例を表すシーケンス図である。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。この図にあるように、まず、記録再生装置にて、専用の携帯再生装置の登録処理などが、例えば電話番号の取得、登録などにより実行される（ステップＳ１５０１）。
【００７９】
その後、携帯電話などの携帯再生装置にて、例えば管理サーバから送信されたリクエスト画面を利用したコンテンツのリクエスト選択操作が実行され、選択コンテンツの識別情報や携帯再生装置自身の電話番号等を含むリクエストが記録再生装置、および管理サーバに対してそれぞれ送信される（ステップＳ１５０２）。
【００８０】
すると、記録再生装置では専用の携帯再生装置からのリクエストであるか否かを判断するため、例えば受信したリクエストに含まれる例えば電話番号と、ステップＳ１５０１で取得、登録された電話番号が一致するか否かを判断する（ステップＳ１５０３）。ここで、一致した場合、記録再生装置は携帯電話などの携帯再生装置に対してリクエストに該当するコンテンツを送信する（ステップＳ１５０４）。
【００８１】
そして、携帯電話などの携帯再生装置では、記録再生装置から送信されたコンテンツを受信し、例えばディスプレイなどに再生表示する（ステップＳ１５０５）。
【００８２】
一方、管理サーバでは、リクエスト数をカウントするため、以下のような処理を実行する。まず、携帯電話などの携帯再生装置からのリクエストを受信すると、そのリクエストに含まれるコンテンツ識別情報を利用した判断処理や、あるいは別途取得するコンテンツ自体のマッチング処理などにより、コンテンツの同一性を識別する（ステップＳ１５０６）。そして、識別された同一のコンテンツ別に、そのリクエスト数を集計し（ステップＳ１５０７）、その集計結果をカウントリストなどとして記憶媒体に更新、蓄積する（ステップＳ１５０８）。
【００８３】
そして、このような処理を複数のプライベート再生システムに横断して実行することで、本実施例のコンテンツ再生システムでは、携帯電話などの携帯再生装置からのリクエストを同一コンテンツ別に横断的に集計する、という具合である。続いて図１６を用いて、このように集計されたリクエスト数に基づくリクエスト画面の生成、取得処理や、そのリクエスト画面を利用したリクエスト処理の一例について説明する。
【００８４】
図１６は、本実施例のコンテンツ再生システムにおいて、リクエスト画面を利用したリクエスト処理の流れの一例を表すシーケンス図である。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。ここで図１５にて説明したような各処理が実行され、この図にあるように、まず、管理サーバにて、同一のコンテンツ別に集計されたリクエスト数をカウントリストなどとして記憶媒体に更新、蓄積する（ステップＳ１６０１）。
【００８５】
その後、携帯電話などの携帯再生装置にてＵＩなどを用いてリクエスト画面の送信要求操作がなされると、携帯再生装置から管理サーバに対してリクエスト画面の送信要求が出力される（ステップＳ１６０２）。
【００８６】
管理サーバでは、このリクエスト画面の送信要求を受けると、該送信要求を送信してきた携帯再生装置が属するプライベート再生システムの記録再生装置を特定するため、以下のような処理を行う。例えば送信要求に含まれる携帯電話などの携帯再生装置の電話番号や機器ＩＤを参照し、自身が保持している「携帯再生装置−記録再生装置テーブル」から記録再生装置を特定する。あるいは該送信要求そのものに、記録再生装置のＩＰアドレスなどが含まれていれば、それを利用することもできる。そして、そのようにして特定された記録再生装置に対して保持コンテンツリストの送信要求を出力する（ステップＳ１６０３）。すると、その送信要求を受付けた記録再生装置は、予め保持している自身のコンテンツリストを管理サーバに対して送信する（ステップＳ１６０４）。
【００８７】
管理サーバでは、そのコンテンツリストを取得し、取得したコンテンツリストと、更新蓄積している同一コンテンツ別の集計結果から、前述のように図１０や図１１で示すようなリクエスト画面を生成、取得する（ステップＳ１６０５）。そして、そのリクエスト画面を、送信要求を出力した携帯電話などの携帯再生装置に対して送信する（ステップＳ１６０６）。
【００８８】
そして、携帯電話などの携帯再生装置では、受信したリクエスト画面をディスプレイなどに表示し、リクエストコンテンツの選択を受付ける（ステップＳ１６０７）。そしてユーザーがＵＩにてリクエスト画面上のいずれかのコンテンツ名などを選択すると、選択されたコンテンツのリクエストを記録再生装置、および管理サーバに対してそれぞれ送信する（ステップＳ１６０８）。
【００８９】
その後は、図１５を用いて説明したようにリクエストに応じたコンテンツの送信、再生処理や、同一コンテンツ別のリクエスト数集計などが実行される、という具合である。なお、上記処理例では、携帯電話などの携帯再生装置からのリクエストが管理サーバと記録再生装置に別々に送信される例について説明したが、もちろん、携帯再生装置からのリクエストは管理サーバのみに送信され、管理サーバ経由で記録再生装置に送信される構成であっても構わない。
【００９０】
<その他の機能的構成>
また、本実施例のコンテンツ再生システムは、以下のような構成を備えていても良い。図１７は、本実施例のコンテンツ再生システムにおける機能ブロックの、別の一例を表す図である。この図にあるように、コンテンツ再生システムは、「記録再生装置」（１７１１）と「携帯再生装置」（１７１２）とからなる「プライベート再生システム」（１７１０）と、「管理サーバ」（１７００）と、からなっている。そして、管理サーバは、「通信手段」（１７００ａ）と、「コンテンツＩＤ取得手段」（１７００ｂ）と、「集計手段」（１７００ｃ）と、「制御手段」（１７００ｄ）と、「ユーザー管理手段」（１７００ｅ）と、を有する。
【００９１】
また、記録再生装置は、「通信手段」（１７１１ａ）と、「記憶手段」（１７１１ｂ）と、「コンテンツ抽出手段」（１７１１ｃ）と、を有する。また、携帯再生装置は、「通信手段」（１７１２ａ）と、「表示手段」（１７１２ｂ）と、を有している。
【００９２】
ここで、携帯電話などの携帯再生装置の「通信手段」から記録再生装置に対してリクエストが送信されると、管理サーバでもそのリクエストを自身の「通信手段」にて取得する。そして「コンテンツＩＤ取得手段」にてそのリクエストに含まれる「タイトル」などのコンテンツＩＤを取得する。すると、そのコンテンツＩＤを利用して「集計手段」にてコンテンツ別にそのリクエスト数を集計する。そして、例えばコンテンツ別の累計リクエスト数などを図示しない管理サーバの「記憶手段」等に記憶しておく。
【００９３】
そして、ユーザーが携帯電話などの携帯再生装置を操作し、「通信手段」から管理サーバに接続する。管理サーバでは、「ユーザー管理手段」に格納されている「携帯再生装置ＩＤ−記録再生装置ＭＡＣアドレステーブル」などを参照し、同じプライベート再生システムの該携帯再生装置と記録再生装置とを接続する。
【００９４】
続いて記録再生装置では「記憶手段」に格納しているコンテンツリストを「通信手段」から管理サーバに対して出力する。すると、管理サーバでは、図示しない「記憶手段」に記憶されている累計リクエスト数の大小順に、取得したコンテンツリストを並び替え、図１０に示すようなリクエスト画面を「制御手段」の処理により生成、取得する。あるいは図１１に示すように「記憶手段」にて累計リクエスト数が記憶されている全部又は一部のコンテンツのうち、取得したコンテンツリストを参照しコンテンツリストにあるものは再生可能にし、ないものは再生不可能な状態で表示するリクエスト画面を「制御手段」の処理により生成、取得する。
【００９５】
そして、生成、取得したリクエスト画面を管理サーバの「通信手段」から携帯電話などの携帯再生装置に対して送信する。すると、携帯電話などの携帯再生装置の「表示手段」に、そのリクエスト画面が表示され、リクエスト順などに並べられたコンテンツの中からユーザーは所望のコンテンツを選択する。
【００９６】
すると、携帯電話などの携帯再生装置の「通信手段」から該リクエストが管理サーバ経由で記録再生装置に送信される。記録再生装置では、「コンテンツ抽出手段」にて、該リクエストに該当するコンテンツのデータを抽出し、「通信手段」から出力する。そしてそのコンテンツデータが、例えば管理サーバ経由でリクエストを送信した携帯電話などの携帯再生装置の「通信手段」に配信され、「表示手段」にてコンテンツが再生表示される。
【００９７】
また、それとともに管理サーバの「集計手段」では、そのリクエストに応じて該コンテンツのリクエスト数をカウントアップし、図示しない「記憶手段」に格納されているそのコンテンツの累積リクエスト数を更新する、という具合である。
【００９８】
<効果の簡単な説明>
以上のように、本実施例のコンテンツ再生システムによって、コンテンツの視聴人数（リクエスト数）を、プライベート再生システムを横断して「開いて」集計し、その集計結果を反映したリクエスト画面を「閉じた」プライベート再生システムにて利用することができる。それにより、ユーザーはコンテンツに関する他人の関心度などを知ることができ、例えばそのような世間一般での関心度を参考として、自身のプライベート再生システムにて見たいコンテンツの再生リクエストを実行することができる。
【００９９】
≪実施例２≫
<概要>
本実施例は、実施例１を基本として、その記録再生装置がキーワードなどによる自動録画などのコンテンツの自動取得機能を備えていることを特徴とするコンテンツ再生システムである。そして、このように記録再生装置が自動録画などの機能を備えている場合、以下のような事態が頻繁に発生することが予想される。つまり、キーワードなどの条件を絞り込まない限り、記録再生装置にはユーザーの意図しない多くのコンテンツが自動で記録されていくことになる。すると、ユーザーは記録再生装置に自動録画したが視聴する時間がない番組を数多く抱えてしまうことになる。そして、視聴できない番組は記録媒体から順次消去されていく、という事態である。
【０１００】
そして本発明は、上記のように自動記録によって膨大な数となっているコンテンツの中からユーザーが視聴するコンテンツを選択するための有効な手段となりうる。なぜならば上記の通り本発明では、ユーザーが他のユーザーの意見（リクエスト回数）を参照してコンテンツを選択し、再生リクエストを実行することができるからである。
【０１０１】
<機能的構成>
図１８は、本実施例のコンテンツ再生システムの記録再生装置における機能ブロックの一例を表す図である。この図にあるように、コンテンツ再生システムは、「管理サーバ」（１８００）と、「プライベート再生システム」（１８１０）と、からなっている。また、プライベート再生システムは「記録再生装置」（１８１１）と、「携帯再生装置」（１８１２）と、を有している。なお、「管理サーバ」および「携帯再生装置」については実施例１で記載済みのものと同様であるのでその説明は省略する。
【０１０２】
そして、本実施例の特徴点は、その記録再生装置が「受付部」（１８１１Ａ）と「特定記録部」（１８１１Ｂ）を有する点である。
【０１０３】
「受付部」（１８１１Ａ）は、コンテンツ属性を含む検索条件を利用者から受付ける機能を有する。「コンテンツ属性」とは、コンテンツの属性を示す情報をいい、例えば、コンテンツ名やその他キーワード、コンテンツ内容、コンテンツのソースアドレス、あるいはコンテンツのデータ形式などが挙げられる。また、コンテンツが放送番組であれば、スポーツ、ドラマ、映画などその番組のジャンルや、出演者／監督／プロデューサーなどのスタッフ名、制作／放送者名、放送時間帯などの情報も挙げられる。また、その他コンテンツであれば、それに類する例えばコンテンツ作成者などの情報が挙げられる。
【０１０４】
そして「受付部」では、ＧＵＩ（グラフィカル・ユーザー・インターフェース）や入力デバイスの操作によって入力されたこれらコンテンツ属性を受付ける、という具合である。そして本実施例の記録再生装置は、例えば従来の自動録画装置と同様に、それらコンテンツ属性をキーワードとして電子番組表などを利用して該当する番組を検索することができる。
【０１０５】
「特定記録部」（１８１１Ｂ）は、受付けた検索条件に合致するコンテンツを電子番組表などのコンテンツテーブルから特定し記録する機能を有する。「コンテンツテーブル」とは、複数のコンテンツを検索可能にテーブル化したものをいい、例えば電子番組表や、音楽販売サイトの楽曲リスト、ＲＳＳのテーブルリストなどが挙げられる。
【０１０６】
そして、受付部で受付けたコンテンツ属性を検索キーとしてこのコンテンツテーブルを検索することで、ユーザーが所望するコンテンツを特定し自動記録を実行することができる。
【０１０７】
図１９は、この特定記録部の処理によって記録されたコンテンツの一例を表す図である。この図にあるように、例えば受付部にて「映画」、「野球」という検索条件（キーワード）がコンテンツ属性として受付けられ、特定記録部にて電子番組表の検索による上記キーワードを含む番組が特定される。そして、その特定結果に基づく自動録画処理によってこの記録再生装置内の記録媒体には、例えば映画「スパイマン」、「沈没」、「ザ・ボクシング４」や、野球中継「９月７日 Ｑ対Ｋ」、「９月８日 Ｋ対Ｙ」「９月８日 Ｐ対Ｑ」などが記録蓄積されていく、という具合である。
【０１０８】
そして、このように受付けられたコンテンツ属性に応じて自動録画が行われると、その記録コンテンツ総数は膨大なものになる。そこで本実施例のコンテンツ再生システムでは、このように膨大な数のコンテンツの中からリクエスト対象を選択するために、上記実施例で記載したように他のユーザーの意見が参照可能なリクエスト画面が表示する、ということである。
【０１０９】
なお、この記録再生装置において前記特定記録を実行するための構成として、さらに詳細には図２０で示すような構成を有していると良い。
【０１１０】
図２０は、本実施例のコンテンツ再生システムの記録再生装置における、さらに詳細な機能ブロックの一例を表す図である。この図にあるように、本実施例の「記録再生装置」（２０１１）は、「受付部」（２０１１Ａ）と、「特定記録部」（２０１１Ｂ）と、「電子番組表取得部」（２０１１Ｃ）と、「特定部」（２０１１Ｄ）と、を有していても良い。なお、「受付部」と「特定記録部」は上記記載済みであるのでその説明は省略する。
【０１１１】
「電子番組表取得部」（２０１１Ｃ）は、電子番組表を取得する機能を有する。この電子番組表取得部は、例えばインターネット上のＷｅｂサーバからネットワークを介して電子番組表を取得するよう構成したり、あるいはチューナーからデジタル放送波に含まれる電子番組表を取得するよう構成したりすることで実現できる。そして、このように取得した電子番組表を利用して、受付部にて受付けたコンテンツ属性を示す例えばキーワードなどを検索キーとした検索処理などが実行される。
【０１１２】
「特定部」（２０１１Ｄ）は、受付けた検索条件に合致するコンテンツを電子番組表などのコンテンツテーブルから特定する機能を有する。電子番組表のデータには、番組の放送時間帯や放送チャンネル情報の他、番組タイトルや出演者、ジャンル、内容（あらすじ）などの情報も記述されている。そこで、検索条件である例えば「映画」などをキーワードとして電子番組表を「ＣＰＵ」の論理演算処理などで検索し、検索条件に合致する番組を特定することができる。なお、この特定部は例えば学習型の検索特定機能を有していてもよい。この学習機能によって、コンテンツに対するユーザーの未視聴消去操作などに応じて、例えば番組タイトルに「映画」が含まれる番組は検索結果として特定せず、ジャンルが「映画」の番組のみ特定する、といった処理を行うよう構成しても良い。
【０１１３】
そして、このように特定された番組の放送時間帯や放送チャンネルの情報を利用して予約録画処理が実行され、特定記録部による特定番組の自動録画が実行される、という具合である。
【０１１４】
<ハードウェア的構成>
図２１は、上記機能的な各構成要件をハードウェアとして実現した際の、コンテンツ再生システムの記録再生装置おける構成の一例を表す概略図である。なお、管理サーバや携帯再生装置における構成の説明は、上記実施例にて記載済みであるので省略する。この図を利用して記録再生装置での特定番組の自動録画処理におけるそれぞれのハードウェア構成部の働きについて説明する。
【０１１５】
この図にあるように、本実施例の記録再生装置は、各種演算処理を行う「ＣＰＵ」（２１０１）と、「主メモリ」（２１０２）と、を備えている。またコンテンツの記録保持などを行う「ＨＤＤ」（２１０３）や、携帯電話などの携帯再生装置や管理サーバとの間で情報の送受信を行う「Ｉ／Ｏ」（２１０４）、キーワードなどの検索条件の入力を受付ける「ＵＩ（ユーザーインターフェース）」（２１０５）、コンテンツの一例である放送番組と、電子番組表を受信する「チューナ」（２１０６）も備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。
【０１１６】
また、「主メモリ」は、各種処理を行うプログラムを「ＣＰＵ」に実行させるために読み出すと同時にそのプログラムの作業領域でもあるワーク領域を提供する。また、この「主メモリ」や「ＨＤＤ」にはそれぞれ複数のアドレスが割り当てられており、「ＣＰＵ」で実行されるプログラムは、そのアドレスを特定しアクセスすることで相互にデータのやりとりを行い、処理を行うことが可能になっている。
【０１１７】
ここで、ユーザーがリモコンなどの入力デバイスを利用してコンテンツ属性を示す例えば「映画」などの検索条件を入力する。するとその入力された検索条件が「ＵＩ」にて受付けられ、検索用のキーワードとして「主メモリ」のアドレス１に格納される。また、「チューナ」にて受信し、「ＨＤＤ」のアドレス１に記録保持されている電子番組表のデータが読み出され、「主メモリ」のアドレス２に格納される。
【０１１８】
そして、「ＣＰＵ」の論理演算処理によって、電子番組表に含まれる番組データの中からキーワードに一致する語句を含む番組が特定される。そして特定された番組データに含まれる放送時間帯や放送チャンネルの情報を利用して、該番組の予約録画命令が生成され「主メモリ」のアドレス３に格納される。その後、予約録画命令で示される時間になったことを内蔵時計などによって判断し、チューナを同じく予約録画命令で示される放送チャンネルの受信に合わせる処理、およびそれによって受信した放送番組の「ＨＤＤ」への記録処理が実行される、という具合である。
【０１１９】
以上のようなハードウェア構成の働きによって「ＵＩ」にて受付けた検索条件に合致する特定番組の自動録画を実行することができる。
【０１２０】
<処理の流れ>
図２２は、本実施例のコンテンツ再生システムの記録再生装置における処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。この図にあるように、まず、記録再生装置とこの記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する携帯電話などの携帯再生装置とからなるプライベート再生システムを複数備えるとともに、前記リクエストを管理する管理サーバを含むコンテンツ再生システムにおいて、記録再生装置はコンテンツ属性を含む検索条件の入力を利用者から受付ける（ステップＳ２２０１）。また、電子番組表などのコンテンツテーブルを取得する（ステップＳ２２０２）。そして受付けた検索条件に合致するコンテンツを電子番組表などのコンテンツテーブルから特定し（ステップＳ２２０３）、特定したコンテンツを、ＨＤＤなどの記録媒体に記録する（ステップＳ２２０４）。
【０１２１】
そして、このように検索条件に合致するコンテンツを自動記録する記録再生装置に関し、図１４や図１５、１６で説明したような処理の流れによって自動記録されたコンテンツを選択するためのリクエスト画面が携帯電話などの携帯再生装置に提示される、という具合である。
【０１２２】
<効果の簡単な説明>
以上のように本実施例のコンテンツ再生システムによって、自動記録によって膨大な数のコンテンツを保持している記録再生装置を含むプライベート再生システムにおいて、他のユーザーの意見（リクエスト回数）が参照可能なリクエスト画面を提供することができる。
【０１２３】
≪実施例３≫
<概要>
本実施例は、実施例１や実施例２を基本として、管理サーバから携帯電話などの携帯再生装置へのリクエスト画面データの送信において以下のような特徴を有するコンテンツ再生システムである。すなわち、選択すべきコンテンツ数が多いためにリクエスト画面が携帯電話などの表示ディスプレイに収まりきらない場合、リクエスト画面データを該表示ディスプレイ１画面分に収まるサイズに分割して、分割リクエスト画面を順次送信するよう構成されたコンテンツ再生システムである。
【０１２４】
このようにして、携帯電話などディスプレイの表示サイズが小さい携帯再生装置が多いプライベート再生システムにおいて、その表示画面サイズに応じて通信トラフィックを分散させることができ、効率的なデータの送受信を行うことができるようになる。
【０１２５】
<機能的構成>
図２３は、本実施例のコンテンツ再生システムの管理サーバにおける機能ブロックの一例を表す図である。この図にあるように、コンテンツ再生システムは、「管理サーバ」（２３００）と、複数の「プライベート再生システム」α、β、γ・・・と、からなっている。また、「管理サーバ」（２３００）は、実施例１を基本として、「集計部」（２３０１）と、「リクエスト画面送信部」（２３０２）と、を有する。なお、管理サーバのこれら「集計部」や「リクエスト画面送信部」、またプライベート再生システムの詳細は上記実施例にて記載済みであるのでその説明は省略する。
【０１２６】
そして、本実施例の特徴点は、管理サーバが、さらに「リクエスト画面生成部」（２３０３）と、「リクエスト画面送信制御部」（２３０４）と、を有する点である。
【０１２７】
「リクエスト画面生成部」（２３０３）は、同一コンテンツに対するリクエスト数を集計し集計結果に基づいてリクエスト数が多い順にコンテンツを選択可能に並べたリクエスト画面を生成する機能を有する。なお、リクエスト画面の生成処理については、例えば図１０や図１１を利用して上記実施例にて記載済みであるのでその詳細な説明は省略する。
【０１２８】
そして本実施例では、このリクエスト画面生成部にて生成したリクエスト画面に対して、次のリクエスト画面送信制御部にて送信先の携帯再生装置のディスプレイサイズに応じて以下のような処理を行うことを特徴とする。
【０１２９】
「リクエスト画面送信制御部」（２３０４）は、リクエスト画面の送信先である携帯再生装置において１画面内に表示できる範囲を生成したリクエスト画面が超えている場合には携帯再生装置からのリクエスト画面要求ごとにリクエスト数が多い順に１画面分ずつリクエスト画面を分割してリクエスト画面送信部に送信させる機能を有する。
【０１３０】
図２４は、このリクエスト画面送信制御部でのリクエスト画面を分割する制御処理の一例を表す概念図である。この図にあるように、まず、リクエスト画面生成部にてリクエスト画面を生成する。つづいて、例えば「３２０ピクセル×２４０ピクセル」といった具合に、携帯再生装置からその表示画面サイズやディスプレイの表示可能サイズなどの情報を取得する。そして、そのサイズ情報に応じて生成したリクエスト画面を例えば３画面分に分割する処理を行う、という具合である。また、画面データの分割処理の際には、次画面送信要求用のボタンが表示されるようにすることで、携帯再生装置における該ボタンの押下操作に応じて次のリクエスト画面を送信するよう構成しても良い。
【０１３１】
そして、このようにして分割されたリクエスト画面が、「リクエスト画面送信部」（２３０２）より、携帯再生装置からのリクエスト画面要求に応じてリクエスト数が多い順に１画面分ずつ送信される、という具合である。
【０１３２】
なお、このリクエスト画面送信制御部でのリクエスト画面の分割処理は、リクエスト数が多い順の分割でなくても構わない。前述のように、例えばリクエスト数の少ない順など、ユーザー指定などされたルールにしたがった順番に並べられ分割されたリクエスト画面を送信しても良い。
【０１３３】
図２５は、本実施例のコンテンツ再生システムの管理サーバにおける、さらに詳細な機能ブロックの一例を表す図である。この図にあるように、本実施例の「管理サーバ」（２５００）は、上記「集計部」（２５０１）と、「リクエスト画面送信部」（２５０２）と、「リクエスト画面生成部」（２５０３）と、「リクエスト画面送信制御部」（２５０４）と、に加え、さらに「画面サイズ情報取得部」（２５０５）と、「画面分割手段」（２５０６）と、「リクエスト画面要求取得部」（２５０７）と、を有していても良い。なお、「集計部」と「リクエスト画面送信部」と「リクエスト画面生成部」と「リクエスト画面送信制御部」は上記記載済みであるのでその説明は省略する。
【０１３４】
「画面サイズ情報取得部」（２５０５）は、携帯電話などの携帯再生装置の画面サイズ情報を取得する機能を有する。「画面サイズ情報」とは、例えば表示画面の解像度やインチ数などの画面サイズを表す情報をいう。
【０１３５】
なお、この画面サイズ情報の取得については、当初携帯再生装置から管理サーバに送信されるリクエスト画面の送信要求に含まれて、そのリクエスト画面の送信要求があるたびに取得する構成としても良い。あるいは、管理サーバに予め携帯再生装置の識別情報と関連づけた画面サイズ情報を登録させておくことで、リクエスト画面の送信要求に含まれる識別情報に基づいて、登録情報からその画面サイズ情報を取得するよう構成しても良い。
【０１３６】
「画面分割手段」（２５０６）は、リクエスト画面生成部（２５０３）にて生成されたリクエスト画面を分割する機能を有する。この画面分割手段でのリクエスト画面の分割処理方法としては、例えば以下のような処理方法が挙げられる。例えばリクエスト画面生成部の処理によって、図２４に示すようなコンテンツを上位から下位に縦に並べて配置する画面構成のリクエスト画面が生成された。そして、そのリクエスト画面のリサイズ前の表示サイズは縦長で「横６４０×縦１４００」となっている。
【０１３７】
ここで、ＣＰＵの論理演算による比較処理の結果、携帯再生装置の画面サイズ情報で示される解像度「横３２０×縦２４０」のディスプレイには、この「６４０×１４００」のリクエスト画面はリサイズ処理しても１画面で表示することはできない、と判断される。そこで画面分割手段では、リクエスト画面の横縦比を保持したまま横サイズが「３２０ピクセル」になるようリサイズ処理する。そして、リサイズ後のリクエスト画面を、画面サイズ情報で示される縦のサイズ、例えば「２４０ピクセル」で区切り、リクエスト画面を「３２０×２４０」の携帯再生装置の１画面上に収まるよう３分割する、という具合である。
【０１３８】
「リクエスト画面要求取得部」（２５０７）は、携帯再生装置からのリクエスト画面の送信要求を取得する機能を有する。ここで取得するリクエスト画面の送信要求は、前述の通り、例えば携帯電話などの携帯再生装置の「ＵＩ」が操作され送信されてきたリクエスト画面の送信要求である。また、その携帯再生装置での画面送信要求の操作に関しては、例えば分割されたリクエスト画面上に次ページ送信要求用のボタンを設けることで実現しても良い。
【０１３９】
そして、このリクエスト画面要求取得部にて携帯再生装置からのリクエスト画面の送信要求を取得するごとに、分割されたリクエスト画面を携帯再生装置に対して順次送信する、という具合である。また、携帯再生装置にて該分割リクエスト画面を利用したコンテンツのリクエスト処理が実行されると、その旨の情報を取得するよう構成しても良い。それによってその後の分割リクエスト画面の送信を停止することもできる。
【０１４０】
<ハードウェア的構成>
図２６は、上記機能的な各構成要件をハードウェアとして実現した際の、コンテンツ再生システムの管理サーバにおける構成の一例を表す概略図である。この図を利用して管理サーバでのリクエスト画面の分割送信処理におけるそれぞれのハードウェア構成部の働きについて説明する。
【０１４１】
この図にあるように、本実施例のコンテンツ再生システムに含まれる管理サーバは、実施例１と同様に「ＣＰＵ」（２６０１）と、「主メモリ」（２６０２）と、「ＨＤＤ」（２６０３）と、「Ｉ／Ｏ」（２６０４）と、を備えている。そして、実施例１で説明したような処理が実行され、カウントリストの「ＨＤＤ」への記録保持や更新処理などが実行される。
【０１４２】
そして携帯電話などの携帯再生装置の「ＵＩ」が操作され「Ｉ／Ｏ」からリクエスト画面の送信要求が管理サーバに対して送信されると、同じく実施例１で説明したように管理サーバにて「カウントリスト」を利用した「リクエスト画面」の生成、送信処理が行われる。そしてその際に、本実施例では以下のようにリクエスト画面の分割処理が実行されることを特徴とする。
【０１４３】
まず、例えば実施例１で記載したような処理を経て生成されたリクエスト画面が「主メモリ」のアドレス１に格納される。また、携帯再生装置からの画面送信要求に含まれる該携帯再生装置のディスプレイの画面サイズ情報「３２０×２４０」が「主メモリ」のアドレス２に格納される。そして、「ＣＰＵ」の論理演算処理によってリクエスト画面が携帯再生装置のディスプレイ１画面に収まるようリサイズできるか否か判断される。その判断の結果、１画面には収まらないと野判断結果が「ＣＰＵ」から出力されると、同じく「ＣＰＵ」の四則演算処理などによってリクエスト画面の分割サイズの決定、および分割処理が実行される。そして分割されたリクエスト画面Ａ，Ｂ，Ｃが、それぞれ「主メモリ」のアドレス３，４，５に格納される。そして、管理サーバは画面送信要求の送信元の携帯再生装置に対して、まず分割リクエスト画面Ａを送信する。
【０１４４】
携帯再生装置ではこの分割リクエスト画面Ａを受信すると、そのディスプレイに分割リクエスト画面Ａを表示する。そしてその分割リクエスト画面Ａにて表示されるコンテンツの選択操作などに応じて、コンテンツの再生リクエストが記録再生装置に送信され、携帯電話などの携帯再生装置でのコンテンツ再生が実行される。また、そのコンテンツの再生リクエスト送信や携帯再生装置でのコンテンツ再生を実行した旨を示す情報を管理サーバにて取得する。すると管理サーバでは、次ページ以降の分割リクエスト画面の送信を停止する。
【０１４５】
また、この分割リクエスト画面Ａにユーザーが再生を所望するコンテンツが無い場合、ユーザーは例えばその分割リクエスト画面Ａ上に設けられた「次ページ送信ボタン」を押下する。すると、次画面の送信要求が管理サーバに対して送信され「Ｉ／Ｏ」にて取得される。そして。そしてその送信要求が「主メモリ」のアドレス６に格納され、それに応じて次ページである分割リクエスト画面Ｂを「Ｉ／Ｏ」から携帯再生装置に返信する。このようにして、分割したリクエスト画面が携帯電話などの携帯再生装置に１画面分ずつ順次送信される、という具合である。
【０１４６】
<処理の流れ>
図２７は、本実施例のコンテンツ再生システムに含まれる管理サーバにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。この図にあるように、まず、記録再生装置とこの記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する携帯電話などの携帯再生装置とからなるプライベート再生システムを複数備えるとともに、前記リクエストを管理する管理サーバを含むコンテンツ再生システムにおいて、管理サーバは、同一コンテンツに対するリクエストを、プライベート再生システムを横断して集計する（ステップＳ２７０１）。
【０１４７】
そして、集計結果に基づいてリクエスト画面を生成、取得し（ステップＳ２７０２）、送信先である携帯再生装置において１画面内に表示できる範囲を、そのリクエスト画面が超えているか判断する（ステップＳ２７０３）。その結果超えているとの判断結果が出力された場合には、携帯再生装置からのリクエスト画面要求ごとにリクエスト数が多い順に１画面分ずつリクエスト画面を分割して送信する（ステップＳ２７０４）。
【０１４８】
図２８は、本実施例のコンテンツ再生システムにおいて、リクエスト画面を分割し送信する処理の流れの一例を表すシーケンス図である。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。なお、本図では、リクエスト画面の分割処理に関する管理サーバと携帯再生装置におけるステップのみ記載し、前述の横断的なリクエストの集計処理に関するステップや、分割前のリクエスト画面の生成にかかる記録再生装置の処理などに関しては、その記載を省略している。
【０１４９】
この図にあるように、まず管理サーバにて、同一のコンテンツ別に集計されたリクエスト数をカウントリストなどとして記憶媒体に更新、蓄積する（ステップＳ２８０１）。
【０１５０】
その後、携帯電話などの携帯再生装置にてＵＩなどを用いてリクエスト画面の送信要求操作がなされると、携帯再生装置から管理サーバに対してリクエスト画面の送信要求が出力される（ステップＳ２８０２）。また、本実施例では、その送信要求に、携帯再生装置自身のディスプレイの画面サイズ情報などを含むことを特徴とする。
【０１５１】
管理サーバでは、この画面サイズ情報を含むリクエスト画面の送信要求を受けると、実施例１で記載したような処理によって記録再生装置を特定し、その記録再生装置のコンテンツリストに応じたリクエスト画面を、集計結果に基づいて生成、取得する（ステップＳ２８０３）。
【０１５２】
そして、生成したリクエスト画面が画面サイズ情報で示される携帯再生装置の１画面上に収まるか否かの判断処理が実行される（ステップＳ２８０４）。そしてリクエスト画面が携帯再生装置の１画面上に収まらないとの判断結果が出力されると、その生成取得したリクエスト画面に関し、画面サイズ情報に基づいて携帯再生装置の１画面上に収まるよう分割処理を実行する（ステップＳ２８０５）。そして、分割されたリクエスト画面の１ページ目を、送信要求を出力した携帯電話などの携帯再生装置に対して送信する（ステップＳ２８０６）。
【０１５３】
そして、携帯電話などの携帯再生装置では、受信した分割リクエスト画面をディスプレイなどに表示し、リクエストコンテンツの選択を受付ける（ステップＳ２８０７）。そして、ユーザーがＵＩにて分割リクエスト画面上のいずれかのコンテンツ名などを選択すると、選択されたコンテンツのリクエストが記録再生装置、および管理サーバに対してそれぞれ送信され、携帯再生装置でのコンテンツの再生が実行される。
【０１５４】
また、携帯再生装置にて次ページ送信要求のボタン操作などが受付けられる（ステップＳ２８０８）と、管理サーバにて、該次ページ送信要求の受信（ステップＳ２８０９）、および携帯再生装置に対する分割リクエスト画面の次ページの送信処理が実行される（ステップＳ２８１０）。
【０１５５】
<効果の簡単な説明>
以上のように本実施例のコンテンツ再生システムによって、携帯電話などのディスプレイの表示サイズが小さい携帯再生装置が多いプライベート再生システムにおいて、その表示画面サイズに応じて通信トラフィックを分散させることができ、効率的なデータの送受信を行うことができるようになる。
【０１５６】
≪実施例４≫
<概要>
本実施例は、実施例１から３のいずれかを基本として、管理サーバから携帯電話などの携帯再生装置に対して送信されるリクエスト画面に関して以下のような特徴を有するコンテンツ再生システムである。すなわち送信されるリクエスト画面が、例えば「プライムタイム（１９時から２３時）における他のプライベート再生システムでのリクエスト数が反映されたリクエスト画面」、「９月１０日〜１７日における同リクエスト画面」といった具合に、所定の時間帯ごとの集計結果が反映されたリクエスト画面である点である。
【０１５７】
このようにしてユーザーは、例えば所定の時間帯において多くリクエストされているコンテンツなどを知ることができる。
【０１５８】
<機能的構成>
図２９は、本実施例のコンテンツ再生システムの管理サーバおよび携帯再生装置における機能ブロックの一例を表す図である。この図にあるように、コンテンツ再生システムは、実施例１を基本として、「管理サーバ」（２９００）と、「プライベート再生システムα」（２９１０）と、からなっている。また、プライベート再生システムは「記録再生装置」（２９１１）と、「携帯再生装置」（２９１２）と、を有している。そして管理サーバが「集計部」（２９０１）と、「リクエスト画面送信部」（２９０２）と、を有している。なお、これら「管理サーバ」とその構成要件である「集計部」と「リクエスト画面送信部」、および「記録再生装置」と「携帯再生装置」については上記実施例で記載済みであるのでその説明は省略する。もちろん、上記実施例２や３を基本として、それぞれで説明したその他の構成要件を有していても良い。
【０１５９】
そして、本実施例の特徴点は、第一に管理サーバがさらに「時間帯制御部」（２９０３）を有する点である。また第二の特徴点は、携帯再生装置が「時間帯リクエスト画面要求部」（２９１２Ａ）を有する点である。
【０１６０】
まず、管理サーバの特徴点から説明する。「時間帯制御部」（２９０３）は、同一コンテンツに対するリクエスト数をリクエスト時間帯ごとに集計する機能と、携帯再生装置からの時間帯リクエスト画面要求に応じてリクエスト時間帯ごとのリクエスト画面を送信するようリクエスト画面送信部を制御する機能と、を有する。この時間帯制御部は、具体的には、例えば「時間帯リクエスト画面要求取得手段」と「時間帯集計制御手段」と「時間帯リクエスト画面送信制御手段」と、を有していると良い。
【０１６１】
「時間帯リクエスト画面要求取得手段」は、後述する携帯再生装置からの時間帯リクエスト画面要求を取得する機能を有する。「時間帯リクエスト画面要求」とは、例えば「プライムタイムにおけるリクエスト数が集計されたリクエスト画面」、「９月１０日〜１７日における同リクエスト画面」といった具合に、そのコンテンツのリクエスト数集計の時間帯を指定して行われるリクエスト画面の送信要求をいう。
【０１６２】
「時間帯集計制御手段」は、集計部（２９０１）での複数のプライベート再生システムの横断的リクエスト集計において、前記時間帯リクエスト画面要求で示される時間帯でのリクエストのみ集計するよう集計部を制御する機能を有する。具体的には、そのリクエストに含まれるリクエストの送信時間情報を利用して、前記リクエスト時間帯ごとのリクエスト数の集計を行う、という具合である。
【０１６３】
「時間帯リクエスト画面送信制御手段」は、前記時間帯集計制御手段の制御によって集計されたリクエスト数に基づいて時間帯リクエスト画面を生成、取得し、リクエスト画面送信部（２９０２）からその時間帯リクエスト画面を送信するよう制御する機能を有する。
【０１６４】
続いて、携帯再生装置の特徴点について説明する。「時間帯リクエスト画面要求部」（２９１２Ａ）は、時間帯ごとの集計結果に基づくリクエスト画面の要求を送信するよう構成されている。具体的には、ユーザーインターフェースなどを利用して、例えば「プライムタイム（１９時から２３時）」や「９月１０日〜９月１７日」などの時間帯を示す情報をユーザーに入力させる。そして、その入力情報を指定時間帯として含むリクエスト画面要求を生成し、管理サーバや記録再生装置に対し送信する、という具合である。
【０１６５】
図３０は、この時間帯リクエスト画面送信処理の一例を表す概念図である。この図にあるように、まず、プライベート再生システムから横断的に集計するリクエストに、「１０月１２日 ２０：３１」や「１０月１５日 ２２：０１」といった具合に、そのリクエストの送信時間を含むよう構成する。
【０１６６】
そして、管理サーバが携帯再生装置から「プライムタイムのリクエスト画面」といった時間帯リクエスト画面要求を受信すると、リクエストに含まれる送信時間を利用して、指定時間帯「１９時から２３時」に該当するコンテンツがＣＰＵの演算処理などにより抽出され、リクエスト数が集計される。そして、時間帯リクエスト画面要求で指定された時間帯のリクエスト数が反映されたリクエスト画面が、携帯再生装置に送信される、という具合である。
【０１６７】
<ハードウェア的構成>
図３１は、上記機能的な各構成要件をハードウェアとして実現した際の、コンテンツ再生システムの管理サーバにおける構成の一例を表す概略図である。この図を利用して管理サーバでの時間帯リクエスト画面の生成処理におけるそれぞれのハードウェア構成部の働きについて説明する。
【０１６８】
この図にあるように、本実施例のコンテンツ再生システムに含まれる管理サーバは、実施例１と同様に「ＣＰＵ」（３１０１）と、「主メモリ」（３１０２）と、「ＨＤＤ」（３１０３）と、「Ｉ／Ｏ」（３１０４）と、を備えている。そして、実施例１で説明したような処理によって、プライベート再生システムを横断したリクエストが取得され、「ＨＤＤ」のアドレス１、２，・・・などに記録、保持される。そしてこのとき取得するリクエストには、そのリクエストの送信時間情報などが含まれていることを特徴とする。
【０１６９】
その後、ユーザー操作に応じて携帯再生装置から「１９時から２３時のリクエスト数が集計されたリクエスト画面」といった具合に時間帯を指定した時間帯リクエスト画面要求が送信される。
【０１７０】
その時間帯リクエスト画面要求は、管理サーバの「Ｉ／Ｏ」にて受信され「主メモリ」のアドレス１に格納される。すると「ＣＰＵ」の論理演算処理によって、その要求に含まれる「指定時間帯」と「ＨＤＤ」に記録保持されているリクエストに含まれる「リクエスト送信時間」とが比較され、指定時間帯に含まれる時間に送信されたリクエストのみが抽出される。そしてその抽出結果に基づくコンテンツごとのリクエスト数の集計が、実施例１で記載したような処理によって実行され、集計結果が「主メモリ」のアドレス２に格納される。そしてその集計結果を利用して時間帯リクエスト画面が生成され、「Ｉ／Ｏ」から携帯再生装置に対して送信される、という具合である。
【０１７１】
<処理の流れ>
図３２は、本実施例のコンテンツ再生システムに含まれる管理サーバにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。この図にあるように、まず、記録再生装置とこの記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する携帯電話などの携帯再生装置とからなるプライベート再生システムを複数備えるとともに、前記リクエストを管理する管理サーバを含むコンテンツ再生システムにおいて、管理サーバは、その送信時間情報を含むリクエストを、プライベート再生システムを横断して取得する（ステップＳ３２０１）。
【０１７２】
その後、携帯再生装置から送信された時間帯リクエスト画面要求を取得する（ステップＳ３２０２）と、取得したリクエストに含まれる送信時間情報に基づいて、時間帯リクエスト画面要求で示される時間帯ごとに同一コンテンツに対するリクエスト数を集計する（ステップＳ３２０３）。そして、集計結果に基づいて時間帯リクエスト画面を生成、取得し（ステップＳ３２０４）、その時間帯リクエスト画面を携帯再生装置に対して送信する（ステップＳ３２０５）。
【０１７３】
図３３は、本実施例のコンテンツ再生システムにおいて、時間帯リクエスト画面を送信する処理の流れの一例を表すシーケンス図である。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。なお、本図では、時間帯リクエスト画面の送信処理に関する管理サーバと携帯再生装置におけるステップのみ記載し、前述の横断的なリクエストの集計処理や記録再生装置の処理などに関しては、その記載を省略している。
【０１７４】
この図にあるように、まず管理サーバにて、プライベート再生システムを横断して、自身の送信時間情報を含むリクエストを取得し、記録媒体に蓄積するため記録する（ステップＳ３３０１）。
【０１７５】
その後、携帯電話などの携帯再生装置にてＵＩなどを用いて時間帯を指定したリクエスト画面の送信要求操作がなされると、携帯再生装置から管理サーバに対して時間帯リクエスト画面要求が出力される（ステップＳ３３０２）。管理サーバでは、この時間帯リクエスト画面要求を受けると、取得したリクエストに含まれる送信時間情報に基づいて時間帯リクエスト画面要求で示される時間帯ごとに、同一コンテンツに対するリクエスト数を集計する（ステップＳ３３０３）。また図示していないが実施例１で記載した処理によって記録再生装置のコンテンツリストなどを取得する。そして集計結果やコンテンツリストに基づいて時間帯リクエスト画面を生成、取得する（ステップＳ３３０４）。そして、生成した時間帯リクエスト画面を、送信要求を出力した携帯電話などの携帯再生装置に対して送信する（ステップＳ３３０５）。
【０１７６】
そして、携帯電話などの携帯再生装置では、受信した時間帯リクエスト画面をディスプレイなどに表示し、リクエストコンテンツの選択を受付ける（ステップＳ３３０６）。そして、ユーザーがＵＩにてリクエスト画面上のいずれかのコンテンツ名などを選択すると、選択されたコンテンツのリクエストが記録再生装置、および管理サーバに対してそれぞれ送信され、携帯再生装置でのコンテンツの再生が実行される。
【０１７７】
<効果の簡単な説明>
以上のように本実施例のコンテンツ再生システムによって、ユーザーは、所定の時間帯において多くリクエストされているコンテンツなどを知ることができる。
【図面の簡単な説明】
【０１７８】
【図１】実施例１のコンテンツ再生システムにおける携帯再生装置のリクエスト画面の一例を表す図
【図２】実施例１のコンテンツ再生システムにおける機能ブロックの一例を表す図
【図３】実施例１のコンテンツ再生システムの記録再生装置における機能ブロックの一例を表す図
【図４】実施例１のコンテンツ再生システムの携帯再生装置における機能ブロックの一例を表す図
【図５】実施例１のコンテンツ再生システムのプライベート再生システムにおいて携帯再生装置から記録再生装置に対して送信されるリクエストの一例を表す概略図
【図６】実施例１のコンテンツ再生システムに含まれるプライベート再生システムの一例を説明するための図
【図７】本実施例のコンテンツ再生システムにおける管理サーバへのリクエスト送信例を説明するための概念図
【図８】実施例１のコンテンツ再生システムに含まれる管理サーバの集計部での複数のプライベート再生システムでの横断的なリクエスト集計の一例を表す概念図
【図９】実施例１のコンテンツ再生システムに含まれる管理サーバの集計部でのコンテンツデータのマッチング処理によるコンテンツの同一性識別の一例を説明するための図
【図１０】実施例１のコンテンツ再生システムに含まれる管理サーバのリクエスト画面送信部から送信されるリクエスト画面の一例を表す図
【図１１】実施例１のコンテンツ再生システムに含まれる管理サーバのリクエスト画面送信部から送信されるリクエスト画面の、別の一例を表す図
【図１２】実施例１のコンテンツ再生システムの管理サーバにおけるさらに詳細な機能ブロックの一例を表す図
【図１３】実施例１のコンテンツ再生システムに含まれる管理サーバにおけるハードウェア構成の一例を表す概略図
【図１４】実施例１のコンテンツ再生システムに含まれる管理サーバにおける処理の流れの一例を表すフローチャート
【図１５】実施例１のコンテンツ再生システムおいて、リクエストを横断的に集計するまでの処理の流れの一例を表すシーケンス図
【図１６】実施例１のコンテンツ再生システムにおいて、リクエスト画面を利用したリクエスト処理の流れの一例を表すシーケンス図
【図１７】実施例１のコンテンツ再生システムにおける機能ブロックの、別の一例を表す図
【図１８】実施例２のコンテンツ再生システムにおける機能ブロックの一例を表す図
【図１９】実施例２の記録再生装置の特定記録部での処理によって記録されたコンテンツの一例を表す図
【図２０】実施例２のコンテンツ再生システムの記録再生装置における、さらに詳細な機能ブロックの一例を表す図
【図２１】実施例２のコンテンツ再生システムの記録再生装置におけるハードウェア構成の一例を表す概略図
【図２２】実施例２のコンテンツ再生システムの記録再生装置における処理の流れの一例を表すフローチャート
【図２３】実施例３のコンテンツ再生システムの管理サーバにおける機能ブロックの一例を表す図
【図２４】実施例２の管理サーバのリクエスト画面送信制御部でのリクエスト画面を分割する制御処理の一例を表す概念図
【図２５】実施例３のコンテンツ再生システムの管理サーバにおけるさらに詳細な機能ブロックの一例を表す図
【図２６】実施例３のコンテンツ再生システムの管理サーバにおけるハードウェア構成の一例を表す概略図
【図２７】実施例３のコンテンツ再生システムの管理サーバにおける処理の流れの一例を表すフローチャート
【図２８】実施例３のコンテンツ再生システムにおいて、リクエスト画面を分割し送信する処理の流れの一例を表すシーケンス図
【図２９】実施例４のコンテンツ再生システムにおける機能ブロックの一例を表す図
【図３０】実施例４の管理サーバでの時間帯リクエスト画面送信処理の一例を表す概念図
【図３１】実施例４のコンテンツ再生システムの管理サーバにおけるハードウェア構成の一例を表す概略図
【図３２】実施例４のコンテンツ再生システムの管理サーバにおける処理の流れの一例を表すフローチャート
【図３３】実施例４のコンテンツ再生システムにおいて、時間帯リクエスト画面を送信する処理の流れの一例を表すシーケンス図
【符号の説明】
【０１７９】
０２００ 管理サーバ
０２０１ 集計部
０２０２ リクエスト画面送信部
０２１０α プライベート再生システムα
０２１１α 記録再生装置
０２１２α 携帯再生装置
０２１０β プライベート再生システムβ
０２１０γ プライベート再生システムγ
【技術分野】
【０００１】
本発明は、家庭内などの記録再生装置に記録されたコンテンツを、専用の携帯再生装置にて再生するための技術に関する。
【背景技術】
【０００２】
従来、以下のようなコンテンツのプライベートな再生システムが提供されている。このプライベート再生システムでは、自宅のＨＤＤレコーダーなどで受信した番組や録画した番組、あるいはその他の記録再生装置にて取得、記録した音楽、テキスト、Ｗｅｂページなどのコンテンツデータを、ネットワークを介して携帯電話などの携帯再生装置に送信し再生することができる。そして、このようなコンテンツのプライベート再生システムにおいて、携帯電話などの携帯再生装置上で再生コンテンツを選択、リクエストするためのインターフェースが様々提供されている。
例えば特許文献１では、上記コンテンツのプライベート再生システムにおいて、携帯電話などの携帯再生装置でのコンテンツの視聴履歴を記憶し、記憶した視聴履歴を記録再生装置に送信する、という構成を備える携帯再生装置（携帯型情報端末装置）に関する技術が開示されている。そして、このような視聴履歴を利用して、例えば視聴途中のコンテンツを上位に、あるいは視聴途中コンテンツのみ表示する、といった具合のリクエスト画面（コンテンツの再生リクエストのためのインターフェース画面）を携帯再生装置や記録再生装置に表示することができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２８６８５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、上記技術には以下のような課題がある。すなわち、前記視聴履歴に応じたリクエスト画面に反映されているのは、あくまでプライベート再生システム内のユーザー個人の視聴履歴のみである、という課題である。つまり、「閉じている」プライベート再生システム内の記録再生装置に記録されているコンテンツに関して、世間一般（自身のプライベート再生システム外の他人）がどのような評価を持っているのか、といった他人の視聴履歴が反映されない、ということである。
【課題を解決するための手段】
【０００５】
以上の課題を解決するために、本発明は、ユーザーごとに「閉じている」プライベート再生システムにおいても、「開いて」他のユーザーの視聴履歴を反映したリクエスト画面を利用可能とする管理サーバを提供する。
【０００６】
具体的には、記録再生装置とこの記録再生装置に記録されたコンテンツ専用の再生リクエスト機能を有する携帯再生装置とからなる複数のプライベート再生システムにおける前記再生リクエストを管理する管理サーバであって、同一コンテンツに対する再生リクエストを、プライベート再生システムを横断的に集計する集計部と、集計部での集計結果に基づく再生リクエストのためのインターフェース画面であって、前記集計された再生リクエストで示されるコンテンツのコンテンツ名を含むリクエスト画面を生成し、前記携帯再生装置に対して送信するリクエスト画面送信部と、を有するとともに、前記リクエスト画面に含まれるコンテンツ名に対応するコンテンツが前記リクエスト画面の送信先のプライベート再生システムに存在しないと判断した場合、前記コンテンツ名に対応するコンテンツを取得可能なサイトへのリンクを前記リクエスト画面に挿入することを特徴とする管理サーバを提供する。
【発明の効果】
【０００７】
以上のような構成をとる本発明によって、上記「閉じた」プライベート再生システムにおいても、プライベートユーザー以外の他人の視聴回数（リクエスト回数）が「開いて」反映されたリクエスト画面を利用することができるようになる。
【０００８】
そして、一般的にユーザーにおけるコンテンツへの興味、とりわけ放送番組や音楽などのエンターテインメント系コンテンツへの興味に関しては、選択の正当性を事象の一致に求める心理的傾向から、視聴回数などで表される他人の評価に左右され易い。したがって、（プライベートユーザー以外の）他人の視聴回数が反映されたリクエスト画面をプライベート再生システムのユーザーに対して提示することで、従来以上に該リクエスト画面に表示されたコンテンツを視聴したい、と思わせる訴求効果も期待できる。
【発明を実施するための形態】
【０００９】
以下に、図を用いて本発明の実施の形態を説明する。なお、本発明はこれら実施の形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施しうる。なお、実施例１において、主に請求項１、２、６、７について説明する。また、実施例２において、主に請求項３、８について説明する。また、実施例３において、主に請求項４、９について説明する。また、実施例４において、主に請求項５、１０について説明する。
【００１０】
≪実施例１≫
<概要>
図１は、本実施例のコンテンツ再生システムにおける携帯再生装置の一例である携帯電話上に表示されたリクエスト画面の一例を表す図である。この図にあるように、プライベート再生システムαを構成する記録再生装置αに対して再生リクエストを送信するためのリクエスト画面が、同プライベート再生システムに属する携帯電話αのディスプレイにて表示されている。そして、そのリクエスト画面には、「１．月曜ドラマ：１０３５２人」、「２．ニュース１０：８９９８人」、「３．クイズ三択：２４９４人」といった具合に、他のプライベート再生システムβやγ、・・・を横断して集計されたそのコンテンツに関する視聴人数（リクエスト数）順で並べられたコンテンツ名が表示されている。
【００１１】
このように本実施例のコンテンツ再生システムでは、コンテンツの視聴人数（リクエスト数）を、プライベート再生システムを横断して「開いて」集計する。そして、その集計結果を反映したリクエスト画面を「閉じた」プライベート再生システムにて利用することができる。それにより、ユーザーはコンテンツに関する他人の関心度などを知ることができ、例えばそのような世間一般の関心度を参考として、自身のプライベート再生システムにて見たいコンテンツの再生リクエストを実行することができる。
【００１２】
<機能的構成>
図２は、本実施例のコンテンツ再生システムにおける機能ブロックの一例を表す図である。この図にあるように、本実施例のコンテンツ再生システムは、「プライベート再生システム」（０２１０α、０２１０β、０２１０γ）を複数備えるとともに、それらプライベート再生システムでのリクエストを管理する「管理サーバ」（０２００）を含むシステムである。
【００１３】
なお、以下に記載する本システムを構成する各装置やサーバの機能ブロックは、ハードウェア、ソフトウェア、又はハードウェア及びソフトウェアの両方として実現され得る。具体的には、コンピュータを利用するものであれば、ＣＰＵや主メモリ、バス、あるいは二次記憶装置（ハードディスクや不揮発性メモリ、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭなどの記憶メディアとそれらメディアの読取ドライブなど）、印刷機器や表示装置、その他の外部周辺装置などのハードウェア構成部やその外部周辺機器用のＩ／Ｏポート、それらハードウェアを制御するためのドライバプログラムやその他アプリケーションプログラム、情報入力に利用されるユーザーインターフェースなどが挙げられる。
【００１４】
またこれらハードウェアやソフトウェアは、主メモリ上に展開したプログラムをＣＰＵで演算処理したり、メモリやハードディスク上に保持されているデータや、インターフェースを介して入力されたデータなどを加工、蓄積、出力処理したり、あるいは各ハードウェア構成部の制御を行ったりするために利用される。また、この発明は装置として実現できるのみでなく、方法としても実現可能である。また、このような発明の一部をソフトウェアとして構成することができる。さらに、そのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品、及び同製品を記録媒体に固定した記録媒体も、当然にこの発明の技術的な範囲に含まれる（本明細書の全体を通じて同様である）。
【００１５】
ここで、まず、「プライベート再生システムα」（０２１０α）について説明する。なお、図では省略しているがプライベート再生システムβやγも、以下に説明するα同様の構成を備えている。
【００１６】
「プライベート再生システムα」（０２１０α）は、「記録再生装置」（０２１１α）と、この記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する「携帯再生装置」（０２１２α）とからなる。
【００１７】
「記録再生装置」（０２１１α）とは、コンテンツデータを記録、再生する機能を備えた端末装置であって、例えば放送番組コンテンツを受信し記録保持する、ＨＤＤ／ＤＶＤなどの各種レコーダーなどが挙げられる。なお、以下にコンテンツデータの一例として記録媒体に記録されている放送番組の動画データ、又はチューナにて受信中の放送番組の動画データを例に挙げ説明するが、もちろん、コンテンツデータはそれに限定されず、その他の動画データや音楽データ、書物などのテキストデータ、Ｗｅｂページデータなどであっても良い。
【００１８】
図３は、この記録再生装置における機能ブロックの一例を表す図である。この図にあるように、「記録再生装置」（０３１１）は、「コンテンツ保持部」（０３１１Ａ）と、「コンテンツリスト送信部」（０３１１Ｂ）と、「リクエスト受信部」（０３１１Ｃ）と、「コンテンツ送信部」（０３１１Ｄ）と、からなる。
【００１９】
「コンテンツ保持部」（０３１１Ａ）は、放送番組データやその他の動画データ、音楽データ、テキストデータ、Ｗｅｂページデータなどのコンテンツを保持する機能を有し、例えばＨＤＤやＤＶＤ、不揮発性メモリなどの記録媒体によって実現することができる。そして、プライベート再生システムでは、携帯再生装置である携帯電話などからのリクエストに応じて、このコンテンツ保持部に保持されているコンテンツがその携帯電話などに送信されることになる。
【００２０】
「コンテンツリスト送信部」（０３１１Ｂ）は、後述する管理サーバ（０３００）に対してコンテンツリストを送信する機能を有する。「コンテンツリスト」とは、コンテンツ保持部にて保持しているコンテンツのタイトル名や識別情報などをリスト化したデータであって、このコンテンツリストを参照して、管理サーバではそれぞれのプライベート再生システムごとに適したリクエスト画面を生成することができる。なお、このコンテンツリストを利用したリクエスト画面の詳細については、管理サーバの構成要件である「リクエスト画面送信部」の項にて説明する。
【００２１】
「リクエスト受信部」（０３１１Ｃ）は、携帯電話などの携帯再生装置から送信されるコンテンツ再生のリクエストを受信する機能を有する。ここで受信するリクエストには、例えば携帯再生装置が携帯電話であれば電話番号等の携帯再生装置を特定するための情報が含まれており、記録再生装置では例えばその電話番号を宛先として次のようにコンテンツを送信することになる。なお、このリクエスト受信部は、図に示すように携帯電話などから出力されたリクエストを管理サーバ経由で受信しても良いし、後述するように携帯電話などから管理サーバを経由せずに送信されたリクエストを受信するよう構成されていても良い。
【００２２】
「コンテンツ送信部」（０３１１Ｄ）は、リクエストの受信に応じて、自身に専用の携帯再生装置に対してコンテンツを送信する機能を有する。なお、携帯再生装置が自身に専用のものであるかの判断は、例えば受信したリクエストに含まれる電話番号などと、後述するような登録処理によって取得した電話番号などのマッチング処理などにより行うと良い。また、このコンテンツ送信部で実行するコンテンツの送信に関して、例えば管理サーバ経由でコンテンツを送信することで、送受信されるコンテンツの管理を管理サーバにて行うよう構成しても良い。もちろん、トラフィックの関係などからコンテンツの送信は管理サーバを経由しないで実行されても構わない。
【００２３】
そして、この記録再生装置のコンテンツ保持部に保持されているコンテンツの再生用のリクエストを送信し、コンテンツ送信部から送信されたコンテンツを取得するのが次の「携帯再生装置」（０３１２。図２中では０２１２α）である。
【００２４】
「携帯再生装置」（０２１２α）は、前述のように、この記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する端末装置である。なお、この携帯再生装置について、本明細書では主に携帯電話を例に挙げて説明する。もちろん、携帯再生装置はＰＤＡ、スマートフォン、ノートパソコン、ネットワーク対応携帯動画プレイヤー、あるいは記録再生装置専用に設計などされた独自の携帯情報端末などであっても良い。
【００２５】
図４は、この携帯再生装置における機能ブロックの一例を表す図である。この図にあるように、「携帯再生装置」（０４１２）は、「リクエスト画面受信部」（０４１２Ａ）と、「リクエスト送信部」（０４１２Ｂ）と、「コンテンツ受信部」（０４１２Ｃ）と、「コンテンツ再生表示部」（０４１２Ｄ）と、からなる。
【００２６】
「リクエスト画面受信部」（０４１２Ａ）は、管理サーバから送信されるリクエスト画面を受信する機能を有する。なお、リクエスト画面については管理サーバの構成要件である「リクエスト画面送信部」の項にて後述するが、その特徴は、他のプライベート再生システムでのリクエスト数が横断的に集計された集計結果が反映されている点である。そして、ここで受信したリクエスト画面をディスプレイなどにて表示し、そのリクエスト画面上のコンテンツ名などを選択することで、コンテンツ再生用のリクエストが携帯電話などの携帯再生装置に受付けられる。
【００２７】
「リクエスト送信部」（０４１２Ｂ）は、リクエスト画面受信部にて受信したリクエスト画面での選択に応じてコンテンツ再生用のリクエストを送信する機能を有する。このリクエスト送信部からのリクエスト送信は、後述するように管理サーバ経由で記録再生装置に送信するよう構成しても良いし、管理サーバを経由せずに送信するよう構成しても良い。
【００２８】
図５は、携帯再生装置のリクエスト送信部から記録再生装置に対して送信されるリクエストの一例を表す概略図である。この図にあるように、前述のリクエスト画面の番組名選択などにより生成されたリクエストには「Title（番組名）」や「Channel（放送チャンネル）」、「Time（放送時間）」、「Region（放送地域）」などの、再生を要求するコンテンツを識別するための情報が記述されている。そして、プライベート再生システムでは、このようなリクエストを参照し識別されるコンテンツを専用の携帯再生装置である携帯電話などに対して送信することで、記録再生装置に記録されているコンテンツの携帯電話などでの再生を実行している。
【００２９】
また、このリクエストに含まれる「番組名」などのコンテンツ識別情報は、例えば、記録再生装置がコンテンツ管理用にコンテンツに別途付している「Ａ１２３４」などのＩＤ情報などであっても構わない。またそのＩＤ情報は、例えば電子番組表の当該番組に付されているＩＤ情報を流用して付されたものであっても良い。またそのような場合には、このコンテンツ再生システムに属する全てのプライベート再生システムにおいて同一の電子番組表を利用するよう構成することで、同一のコンテンツには同一のＩＤ情報が付されるようにしても良い。そのようにすることで、後述するコンテンツの同一性の識別がより簡便な処理で実行できるようになる。
【００３０】
また、このリクエストには携帯再生装置に固有に付されている「Tel No.（電話番号）」や、あるいはＭＡＣアドレスや製造番号なども記述されている。リクエストを受信する記録再生装置では、この「Tel No.」などを利用してコンテンツの送信先を特定しコンテンツを送信することができる。また、後述するようにこの「Tel No.」などを利用して携帯再生装置が自身に専用のものであるか判断することで、プライベート再生システムのプライベート性を確保することもできる。
【００３１】
「コンテンツ受信部」（０４１２Ｃ）は、リクエストに応じて記録再生装置より送信されたコンテンツを受信する機能を有する。「コンテンツ再生表示部」（０４１２Ｄ）は、コンテンツ受信部にて受信したコンテンツを、例えばディスプレイなどに再生表示する機能を有する。このようにして、このプライベート再生システムでは、携帯再生装置である携帯電話などからのリクエストに応じて記録再生装置のコンテンツを携帯電話などにて再生表示することができる。
【００３２】
なおプライベート再生システムにおける記録再生装置と携帯再生装置との関係性を示す「専用」とは、記録再生装置が、許可された携帯再生装置からのコンテンツ再生リクエストのみ受付けるよう構成されていることをいう。ある携帯再生装置をある記録再生装置の専用とするための方法としては、例えば、予め記録再生装置に合わせて設定用意された専用端末を携帯再生装置として利用する方法が挙げられる。あるいは一般的な携帯電話やＰＤＡ、ノートパソコン、ネットワーク対応携帯動画プレイヤーなどの携帯情報端末を、この記録再生装置に各種識別情報などを登録することで専用の携帯再生装置として利用する方法なども挙げられる。
【００３３】
図６は、一般的な携帯情報端末を、記録再生装置の専用とするための情報登録の一例を説明するための図である。この図にあるように携帯再生装置が携帯電話であれば、設定登録処理によってその電話番号「０８０−１１１１−××××」が、記録再生装置の通信ユニットに登録される。そしてリクエストに含まれる電話番号と、登録された電話番号「０８０−１１１１−××××」とをＣＰＵの論理演算処理で一致するか判断する。そして一致した場合には記録再生装置はリクエストに応じた処理を行い、一致しなかった場合には非対応とすることで、一般的な携帯電話端末を、記録再生装置の専用とすることができる、という具合である。また、携帯電話番号以外にも、例えば、機器固有に設定されているＳＩＭ（Subscriber Identity Module）カードの識別情報や、電子メールアドレスなどを利用しても良い。あるいは携帯再生装置が携帯電話端末以外であればＭＡＣアドレスや装置固有の製造番号などを利用しても良い。また図示していないが記録再生装置の通信ユニットのＭＡＣアドレス「００−０２−Ｃ８−５Ｅ−××−××」などを携帯電話端末に登録しても良い。
【００３４】
このように、プライベート再生システムαは、例えば登録された電話番号などを参照することで、他のプライベート再生システムβやγの携帯電話などの携帯再生装置からの再生リクエストには応じないよう処理する、という「閉じた」プライベート再生システムとなっている。
【００３５】
しかし、本実施例のコンテンツ再生システムでは、図７に示すように、このプライベート再生システム内の携帯電話などの携帯再生装置からのリクエスト送信に際し、同時に該リクエストを次のような構成を備える管理サーバにも送信させる（ａ）、あるいは管理サーバを経由して送信させる（ｂ）。それによって、このような「閉じた」プライベート再生システムにおいても、管理サーバを利用することで、他のプライベート再生システムも対象として「開いて」集計された視聴回数が反映されたリクエスト画面を利用することができる、ということを特徴とする。
【００３６】
図２に戻り、次に、コンテンツ再生システムに含まれる「管理サーバ」について説明する。「管理サーバ」（０２００）は、「集計部」（０２０１）と、「リクエスト画面送信部」（０２０２）と、を有する。なお、この管理サーバは、プライベート再生システムにおけるリクエストを管理する機能を有するが、この「リクエストの管理」とは、以下に記載する「集計部」におけるリクエストの横断的集計や「リクエスト画面送信部」におけるリクエスト画面の送信に関連して実行するリクエストの取得、保持、識別判断などの処理をいう。
【００３７】
「集計部」（０２０１）は、同一コンテンツに対するリクエストを、プライベート再生システムを横断的に集計する機能を有する。なお、この集計部での「リクエストの横断的な集計」は、例えば前述のようにプライベート再生システム内のリクエストを管理サーバにも送信させる、あるいは管理サーバを経由して送信させることで実行することができる。
【００３８】
図８は、この集計部における複数のプライベート再生システムでの横断的なリクエスト数集計の一例を表す概念図である。この図にあるように、プライベート再生システムβにて携帯電話などから出力された「リクエスト：月曜ドラマ」が、管理サーバ経由にて同じプライベート再生システムβに属する記録再生装置に送信される。また、プライベート再生システムγや、プライベート再生システムαにて携帯電話などから記録再生装置に送信された「リクエスト：月曜ドラマ」や、「リクエスト：月８"鳥獣戯画"」が、プライベート再生システム内でのリクエスト送信とともに管理サーバに対しても送信される。
【００３９】
そして管理サーバでは、このようにして取得したリクエストの、例えば「月曜ドラマ」や「月８"鳥獣戯画"」などのタイトルからコンテンツの同一性を識別し、同一のコンテンツごとにそのリクエスト数を集計する、という具合である。
【００４０】
なお、本実施例のコンテンツ再生システムに含まれる複数のプライベート再生システムは、例えば同一の電子番組表を利用するなどしなければ、コンテンツ識別情報などに互換性がない各々が独立したシステムとなる可能性が高い。つまり例えばデータ名の変更などから同一コンテンツであってもリクエストに含まれるコンテンツタイトルが異なる、などのケースもあり得る。そこで管理サーバでのリクエストの横断的集計に必要となる「コンテンツの同一性の識別」に関しては、放送番組であればリクエストに含まれる「放送チャンネル」や「放送時間」、「放送地域」などの情報を利用して、図８中の「月曜ドラマ」と「月８"鳥獣戯画"」の同一性などを識別し集計しても良い。また、放送番組では同一コンテンツであっても放送地域ごとにそのチャンネル情報や放送時間情報は異なることもある。そこで電子番組表情報を利用して「地域情報」をキーとして番組情報の検索取得を行い、その番組情報を利用して同一性を識別するよう構成しても良い。
【００４１】
また、取得したリクエストに含まれるコンテンツの識別情報が、前述のように「Ａ１２３４」などの記録再生装置が管理用にコンテンツに付した識別ＩＤである場合には、記録再生装置からその識別ＩＤとコンテンツタイトルなどを関連付けたコンテンツリストを取得することで、上記コンテンツの同一性の識別処理を行うと良い。
【００４２】
またリクエストのあったコンテンツそのものの全部又は一部を管理サーバにて取得するよう構成することで、コンテンツの内容そのもの、例えば音声周波数やフレームデータ、テキスト文章、などのマッチング処理によってコンテンツの同一性を識別するよう構成しても良い。
【００４３】
図９は、このようなコンテンツデータのマッチング処理による同一性の識別の一例を説明するための図である。この図にあるように、例えば音声周波数マッチング処理であれば、図中（ａ）の所定範囲内の音声周波数の波形が、図中（ｂ）に含まれているかをマッチング処理によって判断する。そして閾値以上のマッチング率を示した場合にコンテンツが同一であると判断する、という具合である。また、フレームマッチング処理であれば、図中（ａ）のコンテンツに含まれるフレーム画像が、図中（ｂ）のコンテンツに含まれているかをマッチング処理によって判断する。そして閾値以上のマッチング率を示した場合にコンテンツが同一であると判断する、という具合である。
【００４４】
このように、本実施例では「閉じた」プライベート再生システムにおいて携帯電話などの携帯再生装置から記録再生装置に対して送信されるリクエストを管理サーバにて取得する。そしてリクエストに含まれるコンテンツの識別情報やその他識別情報、マッチング処理などを利用することで同一コンテンツを識別し、コンテンツ別に複数のプライベート再生システムでのリクエストを横断的に集計することができる。そして、このように「開いて」集計したリクエスト回数から、次の「リクエスト画面送信部」によって集計された視聴回数が反映されたリクエスト画面を、「閉じた」プライベート再生システムに対して送信することができる。
【００４５】
なお、ここで集計されるリクエストは、上記携帯電話などから記録再生装置へのリクエスト以外にも、記録再生装置自身が再生を行うためのリクエストなども含まれていて構わない。また、上記のようにリクエストがあった時点でリクエストをカウントする以外に、そのリクエストによって実際に携帯電話などでのコンテンツ再生が実行されたか否かを示す情報を取得した時点でカウントすることで、リクエストに応じたコンテンツ実再生数を集計するよう構成しても良い。
【００４６】
また、この集計部での集計処理は、所定期間内のみの集計結果でも良いし、現在までの累積集計数であっても良い。また、連続ドラマ等のコンテンツであれば各話ごとの集計でも良いしシリーズ累計での集計でも良い。あるいは再生終了を示す情報を取得することで、カウント対象となるリクエストを、まだ再生終了していない現在再生中のコンテンツへのリクエストのみとする構成であっても良い。
【００４７】
また、管理サーバに性別や年齢、居住地などのユーザー情報を登録しておき、かつリクエストにユーザーＩＤを含むよう構成することで、性別や年齢別などのリクエスト数を集計するようにしても良い。また、予めプライベート再生システムごとにコンテンツリストを取得しておき、類似するコンテンツリストのプライベート再生システムをグループ化することで、同グループに属するプライベート再生システムにおけるリクエストのみを集計するように構成しても良い。それによって、コンテンツに対する興味傾向が類似すると思われるユーザーのリクエスト数を中心に集計されたリクエスト画面をユーザーに提供することもできる。
【００４８】
「リクエスト画面送信部」（０２０２）は、集計部（０２０１）での集計結果に基づいて携帯電話などの携帯再生装置に対してリクエストのためのインターフェース画面であるリクエスト画面を送信する機能を有する。「集計結果に基づくリクエスト画面」とは、例えば、コンテンツ別のリクエスト集計数の多い順にコンテンツ名やサムネイル画像などを並べて表示するリクエスト画面が挙げられる。あるいは世間一般には知られていないコンテンツに興味を示すようなユーザーに対しては、逆にリクエスト集計数の少ない順に並べて表示するリクエスト画面を送信しても良い。また、集計数が閾値以上／以下のコンテンツのみ表示するリクエスト画面なども挙げられる。
【００４９】
図１０は、このリクエスト画面送信部から送信されるリクエスト画面の一例を表す図である。図にあるように、このリクエスト画面は、携帯再生装置である携帯電話αのリクエスト送信先である記録再生装置αの保持コンテンツリストを元にしたリクエスト画面である。
【００５０】
つまり、記録再生装置αの保持コンテンツリストを、管理サーバが携帯電話αの識別ＩＤなどを利用して別途取得し、集計部での集計結果を反映させることで生成したリクエスト画面である。このように記録再生装置αに専用の携帯電話αに対しては、記録再生装置αが保持していて、すぐにリクエスト再生が可能なコンテンツのみがリクエスト画面に表示されるようにしても良い。
【００５１】
あるいは図１１に示すように、管理サーバが管理している全部又は一部のコンテンツの、例えばリクエスト数集計結果順にコンテンツ名を並べたリクエスト画面であっても良い。
【００５２】
図１１は、このリクエスト画面送信部から送信されるリクエスト画面の、別の一例を表す図である。この図にあるように、このリクエスト画面は、記録再生装置αの保持するコンテンツに関わらず、管理サーバが管理している全部又は一部のコンテンツのリクエスト数集計結果順にコンテンツ名などを並べたリクエスト画面である。このようにして、ユーザーは自身のプライベート再生システムでは記録しておらず再生できないコンテンツに関しても、そのリクエスト数など世間一般の関心度を知ることができる。
【００５３】
なお図１１に示すように、このリクエスト画面においては、記録再生装置αの保持コンテンツリストを利用して、記録再生装置αが保持していないコンテンツに関して白抜き文字やアイコン添付など通常とは異なった表示を行い、すぐの再生ができないことを通知可能に構成しても良い。
【００５４】
また、記録再生装置αが保持していないコンテンツに関しては、記録再生装置にて新規に記録されるようにするための記録リクエストを送信する「Ｇｅｔ」ボタンなどが表示されるようにしても良い。例えばリクエスト画面上でこのボタンをクリックすると、電子番組表などを参照し、同一コンテンツの再放送などがあるか検索し、あれば予約録画命令（記録リクエスト）を生成し記録再生装置に送信する、という具合である。あるいは音楽コンテンツであればネットワーク上の音楽データ販売サイトへのリンクを利用して、ボタン押下によってそのサイトにユーザーを誘導する、あるいは自動的にそのサイトでの該音楽コンテンツの購入リクエストを行う、といった具合である。
【００５５】
また、このリクエスト画面を利用して選択されたコンテンツのリクエストも、もちろん管理サーバに送信され、集計部での集計処理に用いられるよう構成すると良い。
【００５６】
このように本実施例のコンテンツ再生システムによって、ユーザーごとに「閉じた」プライベート再生システムにおいて、プライベートユーザー以外の他人のコンテンツ別リクエスト回数が反映されたリクエスト画面を利用することができるようになる。
【００５７】
なお、図１０や１１に示すような、記録再生装置の保持コンテンツリストを利用したリクエスト画面の生成、取得処理は、具体的には例えば以下のようにして実行されると良い。まず、記録再生装置から取得した保持コンテンツリストに含まれるコンテンツタイトルなどコンテンツの識別情報が、管理サーバ自身の保持するカウントリストのコンテンツ識別情報に含まれているか、をＣＰＵの論理演算処理によって判断し、識別情報が一致するものを抽出する。そして図１０のリクエスト画面の生成、取得においては、抽出したコンテンツの識別情報に該当するコンテンツのみをリスト化などする、という具合である。一方、図１１のリクエスト画面の生成、取得においては、管理サーバ自身の保持するカウントリストのコンテンツ識別情報のうち、抽出されたコンテンツのみをリクエスト可能とし、それ以外のコンテンツに関してはリクエスト不可のアイコンを添付したり、そのコンテンツを取得可能なサイトへのリンクを挿入したりする、という具合である。
【００５８】
ところで上記構成要件によるリクエストの横断的集計処理やリクエスト画面の送信処理を行うためには、当然、携帯再生装置である携帯電話などからのリクエストを取得するための構成要件や、コンテンツリストを取得するための構成要件なども必要となる。以下、そのような上記説明した「集計部」や「リクエスト画面送信部」の処理に関し副次的に必要となる構成要件について簡単に説明する。
【００５９】
図１２は、この管理サーバにおけるさらに詳細な機能ブロックの一例を表す図である。この図にあるように、「管理サーバ」（１２００）は、「集計部」（１２０１）と、「リクエスト画面送信部」（１２０２）と、を有する。なお、これら「集計部」と「リクエスト画面送信部」はすでに記載済みであるので、その詳細な説明は省略する。
【００６０】
そして、この管理サーバは、さらに「リクエスト取得部」（１２０３）と、「コンテンツリスト取得部」（１２０４）と、「同一コンテンツ識別部」（１２０５）と、を有し、また場合によっては「リクエスト転送部」（１２０６）などを有していても良い。
【００６１】
「リクエスト取得部」（１２０３）は、携帯電話などの携帯再生装置から出力されたリクエストを、前述のようにしてプライベート再生システムを横断して取得する機能を有する。そして、ここで取得したリクエストを、次の同一コンテンツ識別部にて同一コンテンツごとに分類し、「集計部」にて同一コンテンツ別に横断的に集計する。また、場合によっては記録再生装置に取得したリクエストを転送しても良い。
【００６２】
「コンテンツリスト取得部」は、記録再生装置からコンテンツリストを取得する機能を有する。そして、ここで取得したコンテンツリストを利用することで、図１０や図１１で説明したようなリクエスト画面を生成、取得することができる、という具合である。
【００６３】
「同一コンテンツ識別部」（１２０５）は、取得したリクエストに関し、そのリクエスト対象のコンテンツを識別する機能を有する。この同一コンテンツ識別部でのコンテンツ識別方法としては、具体的には、前述のようにリクエストに含まれる「コンテンツタイトル」からリクエスト対象のコンテンツを識別する方法が挙げられる。あるいは、図示しないコンテンツ取得部にてコンテンツの一部を取得し、前述のマッチング処理をＣＰＵの論理演算処理により実行することでコンテンツを識別する方法も挙げられる。そして、ここでコンテンツを識別することで、集計部にて同一コンテンツごとに分類し、そのリクエスト数をプライベート再生システムを横断して集計することができる、という具合である。
【００６４】
なお、リクエスト取得部で取得したリクエストが、管理サーバを経由して記録再生装置に送信されるよう構成されている場合、「リクエスト転送部」（１２０６）にて取得したリクエストを転送すると良い。
【００６５】
<ハードウェア的構成>
図１３は、上記機能的な各構成要件をハードウェアとして実現した際の、コンテンツ再生システムの管理サーバにおける構成の一例を表す概略図である。この図を利用して管理サーバでのリクエストの集計及びリクエスト画面の送信処理におけるそれぞれのハードウェア構成部の働きについて説明する。
【００６６】
この図にあるように、本実施例のコンテンツ再生システムに含まれる管理サーバは、各種演算処理を行う「ＣＰＵ（中央演算装置）」（１３０１）と、「主メモリ」（１３０２）と、を備えている。また集計結果などを保持する「ＨＤＤ」（１３０３）や、プライベート再生システムと情報の送受信を行う「Ｉ／Ｏ（インプット／アウトプット）」（１３０４）も備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。
【００６７】
また、本実施例のコンテンツ再生システムに含まれる携帯電話などの携帯再生装置αも同様に、各種演算処理を行う「ＣＰＵ」（１３１１）と、「主メモリ」（１３１２）と、を備えている。また管理サーバや記録再生装置と情報の送受信を行う「Ｉ／Ｏ」（１３１３）や、表示用にコンテンツを展開する「フレームメモリ」（１３１４）、コンテンツを再生表示する「ディスプレイ」（１３１５）も備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。
【００６８】
また、「主メモリ」は、各種処理を行うプログラムを「ＣＰＵ」に実行させるために読み出すと同時にそのプログラムの作業領域でもあるワーク領域を提供する。また、この「主メモリ」や「ＨＤＤ」、「フラッシュメモリ」にはそれぞれ複数のアドレスが割り当てられており、「ＣＰＵ」で実行されるプログラムは、そのアドレスを特定しアクセスすることで相互にデータのやりとりを行い、処理を行うことが可能になっている。
【００６９】
ここで、プライベート再生システムαやβ、γの携帯電話などの携帯再生装置にて図示しない「ＵＩ（ユーザーインターフェース）」によってコンテンツ再生のリクエスト操作が実行される。すると、その操作に応じてコンテンツの識別情報や自身の電話番号等を含むリクエストが「主メモリ」に格納され、管理サーバ経由で記録再生装置に送信するため「Ｉ／Ｏ」から出力される。あるいは記録再生装置と管理サーバとのそれぞれにあててリクエストが別々に送信される。
【００７０】
すると管理サーバでは、そのリクエストを「Ｉ／Ｏ」にて受信し、「主メモリ」のアドレス１に格納する。そしてこのようにして取得した様々なリクエストに含まれる例えば「タイトル」などのコンテンツ識別情報を利用して、「ＣＰＵ」の論理演算処理によりコンテンツの同一性の識別処理を実行する。そして識別されたコンテンツ毎に、そのリクエスト数の加算、集計処理をＣＰＵのカウント処理によって実行する。そして集計結果をカウントリストとして「ＨＤＤ」のアドレス１に格納する。
【００７１】
一方、携帯電話などの携帯再生装置の「ＵＩ」が操作され「Ｉ／Ｏ」からリクエスト画面の送信要求があった場合などには、管理サーバにて、その「カウントリスト」を利用して「リクエスト画面」の生成、送信処理が行われる。まず、リクエスト画面の送信要求に含まれる携帯再生装置αの識別情報を利用して、リクエスト送信先の記録再生装置のＭＡＣアドレスを取得する。そして、その記録再生装置の保持コンテンツリストの取得要求を該記録再生装置に送信する。そして要求に応じて該記録再生装置から「Ｉ／Ｏ」にて取得した保持コンテンツリストを「主メモリ」のアドレス２に格納する。
【００７２】
そして、「ＨＤＤ」に格納されたリクエスト数の集計結果であるカウントリストと、記録再生装置の保持コンテンツリストから図１０や図１１で示すようなリクエスト画面用の情報を生成し、「主メモリ」のアドレス３に格納する。そして、そのリクエスト画面用の情報を「Ｉ／Ｏ」から「携帯再生装置α」に送信する、という具合である。
【００７３】
また、そのリクエスト画面を利用して携帯電話などである携帯再生装置αから出力されたリクエストを「Ｉ／Ｏ」にて取得する。そして、そのリクエストで示されるコンテンツのリクエスト数加算、集計処理が「ＣＰＵ」の演算処理により実行され、カウントリストが更新される。そして、リクエストが管理サーバ経由で記録再生装置に送信されるよう構成されている場合には、そのリクエストに含まれる送信先の記録再生装置に対して、該リクエストを「Ｉ／Ｏ」から送信する。
【００７４】
そして、そのリクエストを受信した記録再生装置では、例えばリクエストに含まれる電話番号と、前述のように自身に登録されている登録機器を示す電話番号とが一致するか否か、を自身の「ＣＰＵ」の論理演算処理によって判断する。そして一致するとの判断結果である場合には、自身専用の携帯再生装置からのリクエストであるとして、コンテンツを携帯電話などの携帯再生装置に対して送信する。
【００７５】
そして、携帯電話などの携帯再生装置では、「Ｉ／Ｏ」にてそのコンテンツを受信し、その受信データを「フレームメモリ」に展開する。そして展開したコンテンツデータを「ディスプレイ」に表示する、という具合である。
【００７６】
<処理の流れ>
図１４は、本実施例のコンテンツ再生システムに含まれる管理サーバにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。この図にあるように、まず、記録再生装置とこの記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する携帯電話などの携帯再生装置とからなるプライベート再生システムを複数備えるとともに、前記リクエストを管理する管理サーバを含むコンテンツ再生システムにおいて、管理サーバは、同一コンテンツに対するリクエストを、プライベート再生システムを横断的に集計する（ステップＳ１４０１）。
【００７７】
そして、集計結果に基づいてリクエスト画面を取得し（ステップＳ１４０２）、取得したリクエスト画面を携帯電話などの携帯再生装置に対して送信する（ステップＳ１４０３）。
【００７８】
図１５は、本実施例のコンテンツ再生システムにおいて、リクエストを横断的に集計するまでの処理の流れの一例を表すシーケンス図である。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。この図にあるように、まず、記録再生装置にて、専用の携帯再生装置の登録処理などが、例えば電話番号の取得、登録などにより実行される（ステップＳ１５０１）。
【００７９】
その後、携帯電話などの携帯再生装置にて、例えば管理サーバから送信されたリクエスト画面を利用したコンテンツのリクエスト選択操作が実行され、選択コンテンツの識別情報や携帯再生装置自身の電話番号等を含むリクエストが記録再生装置、および管理サーバに対してそれぞれ送信される（ステップＳ１５０２）。
【００８０】
すると、記録再生装置では専用の携帯再生装置からのリクエストであるか否かを判断するため、例えば受信したリクエストに含まれる例えば電話番号と、ステップＳ１５０１で取得、登録された電話番号が一致するか否かを判断する（ステップＳ１５０３）。ここで、一致した場合、記録再生装置は携帯電話などの携帯再生装置に対してリクエストに該当するコンテンツを送信する（ステップＳ１５０４）。
【００８１】
そして、携帯電話などの携帯再生装置では、記録再生装置から送信されたコンテンツを受信し、例えばディスプレイなどに再生表示する（ステップＳ１５０５）。
【００８２】
一方、管理サーバでは、リクエスト数をカウントするため、以下のような処理を実行する。まず、携帯電話などの携帯再生装置からのリクエストを受信すると、そのリクエストに含まれるコンテンツ識別情報を利用した判断処理や、あるいは別途取得するコンテンツ自体のマッチング処理などにより、コンテンツの同一性を識別する（ステップＳ１５０６）。そして、識別された同一のコンテンツ別に、そのリクエスト数を集計し（ステップＳ１５０７）、その集計結果をカウントリストなどとして記憶媒体に更新、蓄積する（ステップＳ１５０８）。
【００８３】
そして、このような処理を複数のプライベート再生システムに横断して実行することで、本実施例のコンテンツ再生システムでは、携帯電話などの携帯再生装置からのリクエストを同一コンテンツ別に横断的に集計する、という具合である。続いて図１６を用いて、このように集計されたリクエスト数に基づくリクエスト画面の生成、取得処理や、そのリクエスト画面を利用したリクエスト処理の一例について説明する。
【００８４】
図１６は、本実施例のコンテンツ再生システムにおいて、リクエスト画面を利用したリクエスト処理の流れの一例を表すシーケンス図である。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。ここで図１５にて説明したような各処理が実行され、この図にあるように、まず、管理サーバにて、同一のコンテンツ別に集計されたリクエスト数をカウントリストなどとして記憶媒体に更新、蓄積する（ステップＳ１６０１）。
【００８５】
その後、携帯電話などの携帯再生装置にてＵＩなどを用いてリクエスト画面の送信要求操作がなされると、携帯再生装置から管理サーバに対してリクエスト画面の送信要求が出力される（ステップＳ１６０２）。
【００８６】
管理サーバでは、このリクエスト画面の送信要求を受けると、該送信要求を送信してきた携帯再生装置が属するプライベート再生システムの記録再生装置を特定するため、以下のような処理を行う。例えば送信要求に含まれる携帯電話などの携帯再生装置の電話番号や機器ＩＤを参照し、自身が保持している「携帯再生装置−記録再生装置テーブル」から記録再生装置を特定する。あるいは該送信要求そのものに、記録再生装置のＩＰアドレスなどが含まれていれば、それを利用することもできる。そして、そのようにして特定された記録再生装置に対して保持コンテンツリストの送信要求を出力する（ステップＳ１６０３）。すると、その送信要求を受付けた記録再生装置は、予め保持している自身のコンテンツリストを管理サーバに対して送信する（ステップＳ１６０４）。
【００８７】
管理サーバでは、そのコンテンツリストを取得し、取得したコンテンツリストと、更新蓄積している同一コンテンツ別の集計結果から、前述のように図１０や図１１で示すようなリクエスト画面を生成、取得する（ステップＳ１６０５）。そして、そのリクエスト画面を、送信要求を出力した携帯電話などの携帯再生装置に対して送信する（ステップＳ１６０６）。
【００８８】
そして、携帯電話などの携帯再生装置では、受信したリクエスト画面をディスプレイなどに表示し、リクエストコンテンツの選択を受付ける（ステップＳ１６０７）。そしてユーザーがＵＩにてリクエスト画面上のいずれかのコンテンツ名などを選択すると、選択されたコンテンツのリクエストを記録再生装置、および管理サーバに対してそれぞれ送信する（ステップＳ１６０８）。
【００８９】
その後は、図１５を用いて説明したようにリクエストに応じたコンテンツの送信、再生処理や、同一コンテンツ別のリクエスト数集計などが実行される、という具合である。なお、上記処理例では、携帯電話などの携帯再生装置からのリクエストが管理サーバと記録再生装置に別々に送信される例について説明したが、もちろん、携帯再生装置からのリクエストは管理サーバのみに送信され、管理サーバ経由で記録再生装置に送信される構成であっても構わない。
【００９０】
<その他の機能的構成>
また、本実施例のコンテンツ再生システムは、以下のような構成を備えていても良い。図１７は、本実施例のコンテンツ再生システムにおける機能ブロックの、別の一例を表す図である。この図にあるように、コンテンツ再生システムは、「記録再生装置」（１７１１）と「携帯再生装置」（１７１２）とからなる「プライベート再生システム」（１７１０）と、「管理サーバ」（１７００）と、からなっている。そして、管理サーバは、「通信手段」（１７００ａ）と、「コンテンツＩＤ取得手段」（１７００ｂ）と、「集計手段」（１７００ｃ）と、「制御手段」（１７００ｄ）と、「ユーザー管理手段」（１７００ｅ）と、を有する。
【００９１】
また、記録再生装置は、「通信手段」（１７１１ａ）と、「記憶手段」（１７１１ｂ）と、「コンテンツ抽出手段」（１７１１ｃ）と、を有する。また、携帯再生装置は、「通信手段」（１７１２ａ）と、「表示手段」（１７１２ｂ）と、を有している。
【００９２】
ここで、携帯電話などの携帯再生装置の「通信手段」から記録再生装置に対してリクエストが送信されると、管理サーバでもそのリクエストを自身の「通信手段」にて取得する。そして「コンテンツＩＤ取得手段」にてそのリクエストに含まれる「タイトル」などのコンテンツＩＤを取得する。すると、そのコンテンツＩＤを利用して「集計手段」にてコンテンツ別にそのリクエスト数を集計する。そして、例えばコンテンツ別の累計リクエスト数などを図示しない管理サーバの「記憶手段」等に記憶しておく。
【００９３】
そして、ユーザーが携帯電話などの携帯再生装置を操作し、「通信手段」から管理サーバに接続する。管理サーバでは、「ユーザー管理手段」に格納されている「携帯再生装置ＩＤ−記録再生装置ＭＡＣアドレステーブル」などを参照し、同じプライベート再生システムの該携帯再生装置と記録再生装置とを接続する。
【００９４】
続いて記録再生装置では「記憶手段」に格納しているコンテンツリストを「通信手段」から管理サーバに対して出力する。すると、管理サーバでは、図示しない「記憶手段」に記憶されている累計リクエスト数の大小順に、取得したコンテンツリストを並び替え、図１０に示すようなリクエスト画面を「制御手段」の処理により生成、取得する。あるいは図１１に示すように「記憶手段」にて累計リクエスト数が記憶されている全部又は一部のコンテンツのうち、取得したコンテンツリストを参照しコンテンツリストにあるものは再生可能にし、ないものは再生不可能な状態で表示するリクエスト画面を「制御手段」の処理により生成、取得する。
【００９５】
そして、生成、取得したリクエスト画面を管理サーバの「通信手段」から携帯電話などの携帯再生装置に対して送信する。すると、携帯電話などの携帯再生装置の「表示手段」に、そのリクエスト画面が表示され、リクエスト順などに並べられたコンテンツの中からユーザーは所望のコンテンツを選択する。
【００９６】
すると、携帯電話などの携帯再生装置の「通信手段」から該リクエストが管理サーバ経由で記録再生装置に送信される。記録再生装置では、「コンテンツ抽出手段」にて、該リクエストに該当するコンテンツのデータを抽出し、「通信手段」から出力する。そしてそのコンテンツデータが、例えば管理サーバ経由でリクエストを送信した携帯電話などの携帯再生装置の「通信手段」に配信され、「表示手段」にてコンテンツが再生表示される。
【００９７】
また、それとともに管理サーバの「集計手段」では、そのリクエストに応じて該コンテンツのリクエスト数をカウントアップし、図示しない「記憶手段」に格納されているそのコンテンツの累積リクエスト数を更新する、という具合である。
【００９８】
<効果の簡単な説明>
以上のように、本実施例のコンテンツ再生システムによって、コンテンツの視聴人数（リクエスト数）を、プライベート再生システムを横断して「開いて」集計し、その集計結果を反映したリクエスト画面を「閉じた」プライベート再生システムにて利用することができる。それにより、ユーザーはコンテンツに関する他人の関心度などを知ることができ、例えばそのような世間一般での関心度を参考として、自身のプライベート再生システムにて見たいコンテンツの再生リクエストを実行することができる。
【００９９】
≪実施例２≫
<概要>
本実施例は、実施例１を基本として、その記録再生装置がキーワードなどによる自動録画などのコンテンツの自動取得機能を備えていることを特徴とするコンテンツ再生システムである。そして、このように記録再生装置が自動録画などの機能を備えている場合、以下のような事態が頻繁に発生することが予想される。つまり、キーワードなどの条件を絞り込まない限り、記録再生装置にはユーザーの意図しない多くのコンテンツが自動で記録されていくことになる。すると、ユーザーは記録再生装置に自動録画したが視聴する時間がない番組を数多く抱えてしまうことになる。そして、視聴できない番組は記録媒体から順次消去されていく、という事態である。
【０１００】
そして本発明は、上記のように自動記録によって膨大な数となっているコンテンツの中からユーザーが視聴するコンテンツを選択するための有効な手段となりうる。なぜならば上記の通り本発明では、ユーザーが他のユーザーの意見（リクエスト回数）を参照してコンテンツを選択し、再生リクエストを実行することができるからである。
【０１０１】
<機能的構成>
図１８は、本実施例のコンテンツ再生システムの記録再生装置における機能ブロックの一例を表す図である。この図にあるように、コンテンツ再生システムは、「管理サーバ」（１８００）と、「プライベート再生システム」（１８１０）と、からなっている。また、プライベート再生システムは「記録再生装置」（１８１１）と、「携帯再生装置」（１８１２）と、を有している。なお、「管理サーバ」および「携帯再生装置」については実施例１で記載済みのものと同様であるのでその説明は省略する。
【０１０２】
そして、本実施例の特徴点は、その記録再生装置が「受付部」（１８１１Ａ）と「特定記録部」（１８１１Ｂ）を有する点である。
【０１０３】
「受付部」（１８１１Ａ）は、コンテンツ属性を含む検索条件を利用者から受付ける機能を有する。「コンテンツ属性」とは、コンテンツの属性を示す情報をいい、例えば、コンテンツ名やその他キーワード、コンテンツ内容、コンテンツのソースアドレス、あるいはコンテンツのデータ形式などが挙げられる。また、コンテンツが放送番組であれば、スポーツ、ドラマ、映画などその番組のジャンルや、出演者／監督／プロデューサーなどのスタッフ名、制作／放送者名、放送時間帯などの情報も挙げられる。また、その他コンテンツであれば、それに類する例えばコンテンツ作成者などの情報が挙げられる。
【０１０４】
そして「受付部」では、ＧＵＩ（グラフィカル・ユーザー・インターフェース）や入力デバイスの操作によって入力されたこれらコンテンツ属性を受付ける、という具合である。そして本実施例の記録再生装置は、例えば従来の自動録画装置と同様に、それらコンテンツ属性をキーワードとして電子番組表などを利用して該当する番組を検索することができる。
【０１０５】
「特定記録部」（１８１１Ｂ）は、受付けた検索条件に合致するコンテンツを電子番組表などのコンテンツテーブルから特定し記録する機能を有する。「コンテンツテーブル」とは、複数のコンテンツを検索可能にテーブル化したものをいい、例えば電子番組表や、音楽販売サイトの楽曲リスト、ＲＳＳのテーブルリストなどが挙げられる。
【０１０６】
そして、受付部で受付けたコンテンツ属性を検索キーとしてこのコンテンツテーブルを検索することで、ユーザーが所望するコンテンツを特定し自動記録を実行することができる。
【０１０７】
図１９は、この特定記録部の処理によって記録されたコンテンツの一例を表す図である。この図にあるように、例えば受付部にて「映画」、「野球」という検索条件（キーワード）がコンテンツ属性として受付けられ、特定記録部にて電子番組表の検索による上記キーワードを含む番組が特定される。そして、その特定結果に基づく自動録画処理によってこの記録再生装置内の記録媒体には、例えば映画「スパイマン」、「沈没」、「ザ・ボクシング４」や、野球中継「９月７日 Ｑ対Ｋ」、「９月８日 Ｋ対Ｙ」「９月８日 Ｐ対Ｑ」などが記録蓄積されていく、という具合である。
【０１０８】
そして、このように受付けられたコンテンツ属性に応じて自動録画が行われると、その記録コンテンツ総数は膨大なものになる。そこで本実施例のコンテンツ再生システムでは、このように膨大な数のコンテンツの中からリクエスト対象を選択するために、上記実施例で記載したように他のユーザーの意見が参照可能なリクエスト画面が表示する、ということである。
【０１０９】
なお、この記録再生装置において前記特定記録を実行するための構成として、さらに詳細には図２０で示すような構成を有していると良い。
【０１１０】
図２０は、本実施例のコンテンツ再生システムの記録再生装置における、さらに詳細な機能ブロックの一例を表す図である。この図にあるように、本実施例の「記録再生装置」（２０１１）は、「受付部」（２０１１Ａ）と、「特定記録部」（２０１１Ｂ）と、「電子番組表取得部」（２０１１Ｃ）と、「特定部」（２０１１Ｄ）と、を有していても良い。なお、「受付部」と「特定記録部」は上記記載済みであるのでその説明は省略する。
【０１１１】
「電子番組表取得部」（２０１１Ｃ）は、電子番組表を取得する機能を有する。この電子番組表取得部は、例えばインターネット上のＷｅｂサーバからネットワークを介して電子番組表を取得するよう構成したり、あるいはチューナーからデジタル放送波に含まれる電子番組表を取得するよう構成したりすることで実現できる。そして、このように取得した電子番組表を利用して、受付部にて受付けたコンテンツ属性を示す例えばキーワードなどを検索キーとした検索処理などが実行される。
【０１１２】
「特定部」（２０１１Ｄ）は、受付けた検索条件に合致するコンテンツを電子番組表などのコンテンツテーブルから特定する機能を有する。電子番組表のデータには、番組の放送時間帯や放送チャンネル情報の他、番組タイトルや出演者、ジャンル、内容（あらすじ）などの情報も記述されている。そこで、検索条件である例えば「映画」などをキーワードとして電子番組表を「ＣＰＵ」の論理演算処理などで検索し、検索条件に合致する番組を特定することができる。なお、この特定部は例えば学習型の検索特定機能を有していてもよい。この学習機能によって、コンテンツに対するユーザーの未視聴消去操作などに応じて、例えば番組タイトルに「映画」が含まれる番組は検索結果として特定せず、ジャンルが「映画」の番組のみ特定する、といった処理を行うよう構成しても良い。
【０１１３】
そして、このように特定された番組の放送時間帯や放送チャンネルの情報を利用して予約録画処理が実行され、特定記録部による特定番組の自動録画が実行される、という具合である。
【０１１４】
<ハードウェア的構成>
図２１は、上記機能的な各構成要件をハードウェアとして実現した際の、コンテンツ再生システムの記録再生装置おける構成の一例を表す概略図である。なお、管理サーバや携帯再生装置における構成の説明は、上記実施例にて記載済みであるので省略する。この図を利用して記録再生装置での特定番組の自動録画処理におけるそれぞれのハードウェア構成部の働きについて説明する。
【０１１５】
この図にあるように、本実施例の記録再生装置は、各種演算処理を行う「ＣＰＵ」（２１０１）と、「主メモリ」（２１０２）と、を備えている。またコンテンツの記録保持などを行う「ＨＤＤ」（２１０３）や、携帯電話などの携帯再生装置や管理サーバとの間で情報の送受信を行う「Ｉ／Ｏ」（２１０４）、キーワードなどの検索条件の入力を受付ける「ＵＩ（ユーザーインターフェース）」（２１０５）、コンテンツの一例である放送番組と、電子番組表を受信する「チューナ」（２１０６）も備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。
【０１１６】
また、「主メモリ」は、各種処理を行うプログラムを「ＣＰＵ」に実行させるために読み出すと同時にそのプログラムの作業領域でもあるワーク領域を提供する。また、この「主メモリ」や「ＨＤＤ」にはそれぞれ複数のアドレスが割り当てられており、「ＣＰＵ」で実行されるプログラムは、そのアドレスを特定しアクセスすることで相互にデータのやりとりを行い、処理を行うことが可能になっている。
【０１１７】
ここで、ユーザーがリモコンなどの入力デバイスを利用してコンテンツ属性を示す例えば「映画」などの検索条件を入力する。するとその入力された検索条件が「ＵＩ」にて受付けられ、検索用のキーワードとして「主メモリ」のアドレス１に格納される。また、「チューナ」にて受信し、「ＨＤＤ」のアドレス１に記録保持されている電子番組表のデータが読み出され、「主メモリ」のアドレス２に格納される。
【０１１８】
そして、「ＣＰＵ」の論理演算処理によって、電子番組表に含まれる番組データの中からキーワードに一致する語句を含む番組が特定される。そして特定された番組データに含まれる放送時間帯や放送チャンネルの情報を利用して、該番組の予約録画命令が生成され「主メモリ」のアドレス３に格納される。その後、予約録画命令で示される時間になったことを内蔵時計などによって判断し、チューナを同じく予約録画命令で示される放送チャンネルの受信に合わせる処理、およびそれによって受信した放送番組の「ＨＤＤ」への記録処理が実行される、という具合である。
【０１１９】
以上のようなハードウェア構成の働きによって「ＵＩ」にて受付けた検索条件に合致する特定番組の自動録画を実行することができる。
【０１２０】
<処理の流れ>
図２２は、本実施例のコンテンツ再生システムの記録再生装置における処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。この図にあるように、まず、記録再生装置とこの記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する携帯電話などの携帯再生装置とからなるプライベート再生システムを複数備えるとともに、前記リクエストを管理する管理サーバを含むコンテンツ再生システムにおいて、記録再生装置はコンテンツ属性を含む検索条件の入力を利用者から受付ける（ステップＳ２２０１）。また、電子番組表などのコンテンツテーブルを取得する（ステップＳ２２０２）。そして受付けた検索条件に合致するコンテンツを電子番組表などのコンテンツテーブルから特定し（ステップＳ２２０３）、特定したコンテンツを、ＨＤＤなどの記録媒体に記録する（ステップＳ２２０４）。
【０１２１】
そして、このように検索条件に合致するコンテンツを自動記録する記録再生装置に関し、図１４や図１５、１６で説明したような処理の流れによって自動記録されたコンテンツを選択するためのリクエスト画面が携帯電話などの携帯再生装置に提示される、という具合である。
【０１２２】
<効果の簡単な説明>
以上のように本実施例のコンテンツ再生システムによって、自動記録によって膨大な数のコンテンツを保持している記録再生装置を含むプライベート再生システムにおいて、他のユーザーの意見（リクエスト回数）が参照可能なリクエスト画面を提供することができる。
【０１２３】
≪実施例３≫
<概要>
本実施例は、実施例１や実施例２を基本として、管理サーバから携帯電話などの携帯再生装置へのリクエスト画面データの送信において以下のような特徴を有するコンテンツ再生システムである。すなわち、選択すべきコンテンツ数が多いためにリクエスト画面が携帯電話などの表示ディスプレイに収まりきらない場合、リクエスト画面データを該表示ディスプレイ１画面分に収まるサイズに分割して、分割リクエスト画面を順次送信するよう構成されたコンテンツ再生システムである。
【０１２４】
このようにして、携帯電話などディスプレイの表示サイズが小さい携帯再生装置が多いプライベート再生システムにおいて、その表示画面サイズに応じて通信トラフィックを分散させることができ、効率的なデータの送受信を行うことができるようになる。
【０１２５】
<機能的構成>
図２３は、本実施例のコンテンツ再生システムの管理サーバにおける機能ブロックの一例を表す図である。この図にあるように、コンテンツ再生システムは、「管理サーバ」（２３００）と、複数の「プライベート再生システム」α、β、γ・・・と、からなっている。また、「管理サーバ」（２３００）は、実施例１を基本として、「集計部」（２３０１）と、「リクエスト画面送信部」（２３０２）と、を有する。なお、管理サーバのこれら「集計部」や「リクエスト画面送信部」、またプライベート再生システムの詳細は上記実施例にて記載済みであるのでその説明は省略する。
【０１２６】
そして、本実施例の特徴点は、管理サーバが、さらに「リクエスト画面生成部」（２３０３）と、「リクエスト画面送信制御部」（２３０４）と、を有する点である。
【０１２７】
「リクエスト画面生成部」（２３０３）は、同一コンテンツに対するリクエスト数を集計し集計結果に基づいてリクエスト数が多い順にコンテンツを選択可能に並べたリクエスト画面を生成する機能を有する。なお、リクエスト画面の生成処理については、例えば図１０や図１１を利用して上記実施例にて記載済みであるのでその詳細な説明は省略する。
【０１２８】
そして本実施例では、このリクエスト画面生成部にて生成したリクエスト画面に対して、次のリクエスト画面送信制御部にて送信先の携帯再生装置のディスプレイサイズに応じて以下のような処理を行うことを特徴とする。
【０１２９】
「リクエスト画面送信制御部」（２３０４）は、リクエスト画面の送信先である携帯再生装置において１画面内に表示できる範囲を生成したリクエスト画面が超えている場合には携帯再生装置からのリクエスト画面要求ごとにリクエスト数が多い順に１画面分ずつリクエスト画面を分割してリクエスト画面送信部に送信させる機能を有する。
【０１３０】
図２４は、このリクエスト画面送信制御部でのリクエスト画面を分割する制御処理の一例を表す概念図である。この図にあるように、まず、リクエスト画面生成部にてリクエスト画面を生成する。つづいて、例えば「３２０ピクセル×２４０ピクセル」といった具合に、携帯再生装置からその表示画面サイズやディスプレイの表示可能サイズなどの情報を取得する。そして、そのサイズ情報に応じて生成したリクエスト画面を例えば３画面分に分割する処理を行う、という具合である。また、画面データの分割処理の際には、次画面送信要求用のボタンが表示されるようにすることで、携帯再生装置における該ボタンの押下操作に応じて次のリクエスト画面を送信するよう構成しても良い。
【０１３１】
そして、このようにして分割されたリクエスト画面が、「リクエスト画面送信部」（２３０２）より、携帯再生装置からのリクエスト画面要求に応じてリクエスト数が多い順に１画面分ずつ送信される、という具合である。
【０１３２】
なお、このリクエスト画面送信制御部でのリクエスト画面の分割処理は、リクエスト数が多い順の分割でなくても構わない。前述のように、例えばリクエスト数の少ない順など、ユーザー指定などされたルールにしたがった順番に並べられ分割されたリクエスト画面を送信しても良い。
【０１３３】
図２５は、本実施例のコンテンツ再生システムの管理サーバにおける、さらに詳細な機能ブロックの一例を表す図である。この図にあるように、本実施例の「管理サーバ」（２５００）は、上記「集計部」（２５０１）と、「リクエスト画面送信部」（２５０２）と、「リクエスト画面生成部」（２５０３）と、「リクエスト画面送信制御部」（２５０４）と、に加え、さらに「画面サイズ情報取得部」（２５０５）と、「画面分割手段」（２５０６）と、「リクエスト画面要求取得部」（２５０７）と、を有していても良い。なお、「集計部」と「リクエスト画面送信部」と「リクエスト画面生成部」と「リクエスト画面送信制御部」は上記記載済みであるのでその説明は省略する。
【０１３４】
「画面サイズ情報取得部」（２５０５）は、携帯電話などの携帯再生装置の画面サイズ情報を取得する機能を有する。「画面サイズ情報」とは、例えば表示画面の解像度やインチ数などの画面サイズを表す情報をいう。
【０１３５】
なお、この画面サイズ情報の取得については、当初携帯再生装置から管理サーバに送信されるリクエスト画面の送信要求に含まれて、そのリクエスト画面の送信要求があるたびに取得する構成としても良い。あるいは、管理サーバに予め携帯再生装置の識別情報と関連づけた画面サイズ情報を登録させておくことで、リクエスト画面の送信要求に含まれる識別情報に基づいて、登録情報からその画面サイズ情報を取得するよう構成しても良い。
【０１３６】
「画面分割手段」（２５０６）は、リクエスト画面生成部（２５０３）にて生成されたリクエスト画面を分割する機能を有する。この画面分割手段でのリクエスト画面の分割処理方法としては、例えば以下のような処理方法が挙げられる。例えばリクエスト画面生成部の処理によって、図２４に示すようなコンテンツを上位から下位に縦に並べて配置する画面構成のリクエスト画面が生成された。そして、そのリクエスト画面のリサイズ前の表示サイズは縦長で「横６４０×縦１４００」となっている。
【０１３７】
ここで、ＣＰＵの論理演算による比較処理の結果、携帯再生装置の画面サイズ情報で示される解像度「横３２０×縦２４０」のディスプレイには、この「６４０×１４００」のリクエスト画面はリサイズ処理しても１画面で表示することはできない、と判断される。そこで画面分割手段では、リクエスト画面の横縦比を保持したまま横サイズが「３２０ピクセル」になるようリサイズ処理する。そして、リサイズ後のリクエスト画面を、画面サイズ情報で示される縦のサイズ、例えば「２４０ピクセル」で区切り、リクエスト画面を「３２０×２４０」の携帯再生装置の１画面上に収まるよう３分割する、という具合である。
【０１３８】
「リクエスト画面要求取得部」（２５０７）は、携帯再生装置からのリクエスト画面の送信要求を取得する機能を有する。ここで取得するリクエスト画面の送信要求は、前述の通り、例えば携帯電話などの携帯再生装置の「ＵＩ」が操作され送信されてきたリクエスト画面の送信要求である。また、その携帯再生装置での画面送信要求の操作に関しては、例えば分割されたリクエスト画面上に次ページ送信要求用のボタンを設けることで実現しても良い。
【０１３９】
そして、このリクエスト画面要求取得部にて携帯再生装置からのリクエスト画面の送信要求を取得するごとに、分割されたリクエスト画面を携帯再生装置に対して順次送信する、という具合である。また、携帯再生装置にて該分割リクエスト画面を利用したコンテンツのリクエスト処理が実行されると、その旨の情報を取得するよう構成しても良い。それによってその後の分割リクエスト画面の送信を停止することもできる。
【０１４０】
<ハードウェア的構成>
図２６は、上記機能的な各構成要件をハードウェアとして実現した際の、コンテンツ再生システムの管理サーバにおける構成の一例を表す概略図である。この図を利用して管理サーバでのリクエスト画面の分割送信処理におけるそれぞれのハードウェア構成部の働きについて説明する。
【０１４１】
この図にあるように、本実施例のコンテンツ再生システムに含まれる管理サーバは、実施例１と同様に「ＣＰＵ」（２６０１）と、「主メモリ」（２６０２）と、「ＨＤＤ」（２６０３）と、「Ｉ／Ｏ」（２６０４）と、を備えている。そして、実施例１で説明したような処理が実行され、カウントリストの「ＨＤＤ」への記録保持や更新処理などが実行される。
【０１４２】
そして携帯電話などの携帯再生装置の「ＵＩ」が操作され「Ｉ／Ｏ」からリクエスト画面の送信要求が管理サーバに対して送信されると、同じく実施例１で説明したように管理サーバにて「カウントリスト」を利用した「リクエスト画面」の生成、送信処理が行われる。そしてその際に、本実施例では以下のようにリクエスト画面の分割処理が実行されることを特徴とする。
【０１４３】
まず、例えば実施例１で記載したような処理を経て生成されたリクエスト画面が「主メモリ」のアドレス１に格納される。また、携帯再生装置からの画面送信要求に含まれる該携帯再生装置のディスプレイの画面サイズ情報「３２０×２４０」が「主メモリ」のアドレス２に格納される。そして、「ＣＰＵ」の論理演算処理によってリクエスト画面が携帯再生装置のディスプレイ１画面に収まるようリサイズできるか否か判断される。その判断の結果、１画面には収まらないと野判断結果が「ＣＰＵ」から出力されると、同じく「ＣＰＵ」の四則演算処理などによってリクエスト画面の分割サイズの決定、および分割処理が実行される。そして分割されたリクエスト画面Ａ，Ｂ，Ｃが、それぞれ「主メモリ」のアドレス３，４，５に格納される。そして、管理サーバは画面送信要求の送信元の携帯再生装置に対して、まず分割リクエスト画面Ａを送信する。
【０１４４】
携帯再生装置ではこの分割リクエスト画面Ａを受信すると、そのディスプレイに分割リクエスト画面Ａを表示する。そしてその分割リクエスト画面Ａにて表示されるコンテンツの選択操作などに応じて、コンテンツの再生リクエストが記録再生装置に送信され、携帯電話などの携帯再生装置でのコンテンツ再生が実行される。また、そのコンテンツの再生リクエスト送信や携帯再生装置でのコンテンツ再生を実行した旨を示す情報を管理サーバにて取得する。すると管理サーバでは、次ページ以降の分割リクエスト画面の送信を停止する。
【０１４５】
また、この分割リクエスト画面Ａにユーザーが再生を所望するコンテンツが無い場合、ユーザーは例えばその分割リクエスト画面Ａ上に設けられた「次ページ送信ボタン」を押下する。すると、次画面の送信要求が管理サーバに対して送信され「Ｉ／Ｏ」にて取得される。そして。そしてその送信要求が「主メモリ」のアドレス６に格納され、それに応じて次ページである分割リクエスト画面Ｂを「Ｉ／Ｏ」から携帯再生装置に返信する。このようにして、分割したリクエスト画面が携帯電話などの携帯再生装置に１画面分ずつ順次送信される、という具合である。
【０１４６】
<処理の流れ>
図２７は、本実施例のコンテンツ再生システムに含まれる管理サーバにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。この図にあるように、まず、記録再生装置とこの記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する携帯電話などの携帯再生装置とからなるプライベート再生システムを複数備えるとともに、前記リクエストを管理する管理サーバを含むコンテンツ再生システムにおいて、管理サーバは、同一コンテンツに対するリクエストを、プライベート再生システムを横断して集計する（ステップＳ２７０１）。
【０１４７】
そして、集計結果に基づいてリクエスト画面を生成、取得し（ステップＳ２７０２）、送信先である携帯再生装置において１画面内に表示できる範囲を、そのリクエスト画面が超えているか判断する（ステップＳ２７０３）。その結果超えているとの判断結果が出力された場合には、携帯再生装置からのリクエスト画面要求ごとにリクエスト数が多い順に１画面分ずつリクエスト画面を分割して送信する（ステップＳ２７０４）。
【０１４８】
図２８は、本実施例のコンテンツ再生システムにおいて、リクエスト画面を分割し送信する処理の流れの一例を表すシーケンス図である。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。なお、本図では、リクエスト画面の分割処理に関する管理サーバと携帯再生装置におけるステップのみ記載し、前述の横断的なリクエストの集計処理に関するステップや、分割前のリクエスト画面の生成にかかる記録再生装置の処理などに関しては、その記載を省略している。
【０１４９】
この図にあるように、まず管理サーバにて、同一のコンテンツ別に集計されたリクエスト数をカウントリストなどとして記憶媒体に更新、蓄積する（ステップＳ２８０１）。
【０１５０】
その後、携帯電話などの携帯再生装置にてＵＩなどを用いてリクエスト画面の送信要求操作がなされると、携帯再生装置から管理サーバに対してリクエスト画面の送信要求が出力される（ステップＳ２８０２）。また、本実施例では、その送信要求に、携帯再生装置自身のディスプレイの画面サイズ情報などを含むことを特徴とする。
【０１５１】
管理サーバでは、この画面サイズ情報を含むリクエスト画面の送信要求を受けると、実施例１で記載したような処理によって記録再生装置を特定し、その記録再生装置のコンテンツリストに応じたリクエスト画面を、集計結果に基づいて生成、取得する（ステップＳ２８０３）。
【０１５２】
そして、生成したリクエスト画面が画面サイズ情報で示される携帯再生装置の１画面上に収まるか否かの判断処理が実行される（ステップＳ２８０４）。そしてリクエスト画面が携帯再生装置の１画面上に収まらないとの判断結果が出力されると、その生成取得したリクエスト画面に関し、画面サイズ情報に基づいて携帯再生装置の１画面上に収まるよう分割処理を実行する（ステップＳ２８０５）。そして、分割されたリクエスト画面の１ページ目を、送信要求を出力した携帯電話などの携帯再生装置に対して送信する（ステップＳ２８０６）。
【０１５３】
そして、携帯電話などの携帯再生装置では、受信した分割リクエスト画面をディスプレイなどに表示し、リクエストコンテンツの選択を受付ける（ステップＳ２８０７）。そして、ユーザーがＵＩにて分割リクエスト画面上のいずれかのコンテンツ名などを選択すると、選択されたコンテンツのリクエストが記録再生装置、および管理サーバに対してそれぞれ送信され、携帯再生装置でのコンテンツの再生が実行される。
【０１５４】
また、携帯再生装置にて次ページ送信要求のボタン操作などが受付けられる（ステップＳ２８０８）と、管理サーバにて、該次ページ送信要求の受信（ステップＳ２８０９）、および携帯再生装置に対する分割リクエスト画面の次ページの送信処理が実行される（ステップＳ２８１０）。
【０１５５】
<効果の簡単な説明>
以上のように本実施例のコンテンツ再生システムによって、携帯電話などのディスプレイの表示サイズが小さい携帯再生装置が多いプライベート再生システムにおいて、その表示画面サイズに応じて通信トラフィックを分散させることができ、効率的なデータの送受信を行うことができるようになる。
【０１５６】
≪実施例４≫
<概要>
本実施例は、実施例１から３のいずれかを基本として、管理サーバから携帯電話などの携帯再生装置に対して送信されるリクエスト画面に関して以下のような特徴を有するコンテンツ再生システムである。すなわち送信されるリクエスト画面が、例えば「プライムタイム（１９時から２３時）における他のプライベート再生システムでのリクエスト数が反映されたリクエスト画面」、「９月１０日〜１７日における同リクエスト画面」といった具合に、所定の時間帯ごとの集計結果が反映されたリクエスト画面である点である。
【０１５７】
このようにしてユーザーは、例えば所定の時間帯において多くリクエストされているコンテンツなどを知ることができる。
【０１５８】
<機能的構成>
図２９は、本実施例のコンテンツ再生システムの管理サーバおよび携帯再生装置における機能ブロックの一例を表す図である。この図にあるように、コンテンツ再生システムは、実施例１を基本として、「管理サーバ」（２９００）と、「プライベート再生システムα」（２９１０）と、からなっている。また、プライベート再生システムは「記録再生装置」（２９１１）と、「携帯再生装置」（２９１２）と、を有している。そして管理サーバが「集計部」（２９０１）と、「リクエスト画面送信部」（２９０２）と、を有している。なお、これら「管理サーバ」とその構成要件である「集計部」と「リクエスト画面送信部」、および「記録再生装置」と「携帯再生装置」については上記実施例で記載済みであるのでその説明は省略する。もちろん、上記実施例２や３を基本として、それぞれで説明したその他の構成要件を有していても良い。
【０１５９】
そして、本実施例の特徴点は、第一に管理サーバがさらに「時間帯制御部」（２９０３）を有する点である。また第二の特徴点は、携帯再生装置が「時間帯リクエスト画面要求部」（２９１２Ａ）を有する点である。
【０１６０】
まず、管理サーバの特徴点から説明する。「時間帯制御部」（２９０３）は、同一コンテンツに対するリクエスト数をリクエスト時間帯ごとに集計する機能と、携帯再生装置からの時間帯リクエスト画面要求に応じてリクエスト時間帯ごとのリクエスト画面を送信するようリクエスト画面送信部を制御する機能と、を有する。この時間帯制御部は、具体的には、例えば「時間帯リクエスト画面要求取得手段」と「時間帯集計制御手段」と「時間帯リクエスト画面送信制御手段」と、を有していると良い。
【０１６１】
「時間帯リクエスト画面要求取得手段」は、後述する携帯再生装置からの時間帯リクエスト画面要求を取得する機能を有する。「時間帯リクエスト画面要求」とは、例えば「プライムタイムにおけるリクエスト数が集計されたリクエスト画面」、「９月１０日〜１７日における同リクエスト画面」といった具合に、そのコンテンツのリクエスト数集計の時間帯を指定して行われるリクエスト画面の送信要求をいう。
【０１６２】
「時間帯集計制御手段」は、集計部（２９０１）での複数のプライベート再生システムの横断的リクエスト集計において、前記時間帯リクエスト画面要求で示される時間帯でのリクエストのみ集計するよう集計部を制御する機能を有する。具体的には、そのリクエストに含まれるリクエストの送信時間情報を利用して、前記リクエスト時間帯ごとのリクエスト数の集計を行う、という具合である。
【０１６３】
「時間帯リクエスト画面送信制御手段」は、前記時間帯集計制御手段の制御によって集計されたリクエスト数に基づいて時間帯リクエスト画面を生成、取得し、リクエスト画面送信部（２９０２）からその時間帯リクエスト画面を送信するよう制御する機能を有する。
【０１６４】
続いて、携帯再生装置の特徴点について説明する。「時間帯リクエスト画面要求部」（２９１２Ａ）は、時間帯ごとの集計結果に基づくリクエスト画面の要求を送信するよう構成されている。具体的には、ユーザーインターフェースなどを利用して、例えば「プライムタイム（１９時から２３時）」や「９月１０日〜９月１７日」などの時間帯を示す情報をユーザーに入力させる。そして、その入力情報を指定時間帯として含むリクエスト画面要求を生成し、管理サーバや記録再生装置に対し送信する、という具合である。
【０１６５】
図３０は、この時間帯リクエスト画面送信処理の一例を表す概念図である。この図にあるように、まず、プライベート再生システムから横断的に集計するリクエストに、「１０月１２日 ２０：３１」や「１０月１５日 ２２：０１」といった具合に、そのリクエストの送信時間を含むよう構成する。
【０１６６】
そして、管理サーバが携帯再生装置から「プライムタイムのリクエスト画面」といった時間帯リクエスト画面要求を受信すると、リクエストに含まれる送信時間を利用して、指定時間帯「１９時から２３時」に該当するコンテンツがＣＰＵの演算処理などにより抽出され、リクエスト数が集計される。そして、時間帯リクエスト画面要求で指定された時間帯のリクエスト数が反映されたリクエスト画面が、携帯再生装置に送信される、という具合である。
【０１６７】
<ハードウェア的構成>
図３１は、上記機能的な各構成要件をハードウェアとして実現した際の、コンテンツ再生システムの管理サーバにおける構成の一例を表す概略図である。この図を利用して管理サーバでの時間帯リクエスト画面の生成処理におけるそれぞれのハードウェア構成部の働きについて説明する。
【０１６８】
この図にあるように、本実施例のコンテンツ再生システムに含まれる管理サーバは、実施例１と同様に「ＣＰＵ」（３１０１）と、「主メモリ」（３１０２）と、「ＨＤＤ」（３１０３）と、「Ｉ／Ｏ」（３１０４）と、を備えている。そして、実施例１で説明したような処理によって、プライベート再生システムを横断したリクエストが取得され、「ＨＤＤ」のアドレス１、２，・・・などに記録、保持される。そしてこのとき取得するリクエストには、そのリクエストの送信時間情報などが含まれていることを特徴とする。
【０１６９】
その後、ユーザー操作に応じて携帯再生装置から「１９時から２３時のリクエスト数が集計されたリクエスト画面」といった具合に時間帯を指定した時間帯リクエスト画面要求が送信される。
【０１７０】
その時間帯リクエスト画面要求は、管理サーバの「Ｉ／Ｏ」にて受信され「主メモリ」のアドレス１に格納される。すると「ＣＰＵ」の論理演算処理によって、その要求に含まれる「指定時間帯」と「ＨＤＤ」に記録保持されているリクエストに含まれる「リクエスト送信時間」とが比較され、指定時間帯に含まれる時間に送信されたリクエストのみが抽出される。そしてその抽出結果に基づくコンテンツごとのリクエスト数の集計が、実施例１で記載したような処理によって実行され、集計結果が「主メモリ」のアドレス２に格納される。そしてその集計結果を利用して時間帯リクエスト画面が生成され、「Ｉ／Ｏ」から携帯再生装置に対して送信される、という具合である。
【０１７１】
<処理の流れ>
図３２は、本実施例のコンテンツ再生システムに含まれる管理サーバにおける処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。この図にあるように、まず、記録再生装置とこの記録再生装置に記録されたコンテンツ専用のリクエスト機能を有する携帯電話などの携帯再生装置とからなるプライベート再生システムを複数備えるとともに、前記リクエストを管理する管理サーバを含むコンテンツ再生システムにおいて、管理サーバは、その送信時間情報を含むリクエストを、プライベート再生システムを横断して取得する（ステップＳ３２０１）。
【０１７２】
その後、携帯再生装置から送信された時間帯リクエスト画面要求を取得する（ステップＳ３２０２）と、取得したリクエストに含まれる送信時間情報に基づいて、時間帯リクエスト画面要求で示される時間帯ごとに同一コンテンツに対するリクエスト数を集計する（ステップＳ３２０３）。そして、集計結果に基づいて時間帯リクエスト画面を生成、取得し（ステップＳ３２０４）、その時間帯リクエスト画面を携帯再生装置に対して送信する（ステップＳ３２０５）。
【０１７３】
図３３は、本実施例のコンテンツ再生システムにおいて、時間帯リクエスト画面を送信する処理の流れの一例を表すシーケンス図である。なお、以下に示すステップは、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。なお、本図では、時間帯リクエスト画面の送信処理に関する管理サーバと携帯再生装置におけるステップのみ記載し、前述の横断的なリクエストの集計処理や記録再生装置の処理などに関しては、その記載を省略している。
【０１７４】
この図にあるように、まず管理サーバにて、プライベート再生システムを横断して、自身の送信時間情報を含むリクエストを取得し、記録媒体に蓄積するため記録する（ステップＳ３３０１）。
【０１７５】
その後、携帯電話などの携帯再生装置にてＵＩなどを用いて時間帯を指定したリクエスト画面の送信要求操作がなされると、携帯再生装置から管理サーバに対して時間帯リクエスト画面要求が出力される（ステップＳ３３０２）。管理サーバでは、この時間帯リクエスト画面要求を受けると、取得したリクエストに含まれる送信時間情報に基づいて時間帯リクエスト画面要求で示される時間帯ごとに、同一コンテンツに対するリクエスト数を集計する（ステップＳ３３０３）。また図示していないが実施例１で記載した処理によって記録再生装置のコンテンツリストなどを取得する。そして集計結果やコンテンツリストに基づいて時間帯リクエスト画面を生成、取得する（ステップＳ３３０４）。そして、生成した時間帯リクエスト画面を、送信要求を出力した携帯電話などの携帯再生装置に対して送信する（ステップＳ３３０５）。
【０１７６】
そして、携帯電話などの携帯再生装置では、受信した時間帯リクエスト画面をディスプレイなどに表示し、リクエストコンテンツの選択を受付ける（ステップＳ３３０６）。そして、ユーザーがＵＩにてリクエスト画面上のいずれかのコンテンツ名などを選択すると、選択されたコンテンツのリクエストが記録再生装置、および管理サーバに対してそれぞれ送信され、携帯再生装置でのコンテンツの再生が実行される。
【０１７７】
<効果の簡単な説明>
以上のように本実施例のコンテンツ再生システムによって、ユーザーは、所定の時間帯において多くリクエストされているコンテンツなどを知ることができる。
【図面の簡単な説明】
【０１７８】
【図１】実施例１のコンテンツ再生システムにおける携帯再生装置のリクエスト画面の一例を表す図
【図２】実施例１のコンテンツ再生システムにおける機能ブロックの一例を表す図
【図３】実施例１のコンテンツ再生システムの記録再生装置における機能ブロックの一例を表す図
【図４】実施例１のコンテンツ再生システムの携帯再生装置における機能ブロックの一例を表す図
【図５】実施例１のコンテンツ再生システムのプライベート再生システムにおいて携帯再生装置から記録再生装置に対して送信されるリクエストの一例を表す概略図
【図６】実施例１のコンテンツ再生システムに含まれるプライベート再生システムの一例を説明するための図
【図７】本実施例のコンテンツ再生システムにおける管理サーバへのリクエスト送信例を説明するための概念図
【図８】実施例１のコンテンツ再生システムに含まれる管理サーバの集計部での複数のプライベート再生システムでの横断的なリクエスト集計の一例を表す概念図
【図９】実施例１のコンテンツ再生システムに含まれる管理サーバの集計部でのコンテンツデータのマッチング処理によるコンテンツの同一性識別の一例を説明するための図
【図１０】実施例１のコンテンツ再生システムに含まれる管理サーバのリクエスト画面送信部から送信されるリクエスト画面の一例を表す図
【図１１】実施例１のコンテンツ再生システムに含まれる管理サーバのリクエスト画面送信部から送信されるリクエスト画面の、別の一例を表す図
【図１２】実施例１のコンテンツ再生システムの管理サーバにおけるさらに詳細な機能ブロックの一例を表す図
【図１３】実施例１のコンテンツ再生システムに含まれる管理サーバにおけるハードウェア構成の一例を表す概略図
【図１４】実施例１のコンテンツ再生システムに含まれる管理サーバにおける処理の流れの一例を表すフローチャート
【図１５】実施例１のコンテンツ再生システムおいて、リクエストを横断的に集計するまでの処理の流れの一例を表すシーケンス図
【図１６】実施例１のコンテンツ再生システムにおいて、リクエスト画面を利用したリクエスト処理の流れの一例を表すシーケンス図
【図１７】実施例１のコンテンツ再生システムにおける機能ブロックの、別の一例を表す図
【図１８】実施例２のコンテンツ再生システムにおける機能ブロックの一例を表す図
【図１９】実施例２の記録再生装置の特定記録部での処理によって記録されたコンテンツの一例を表す図
【図２０】実施例２のコンテンツ再生システムの記録再生装置における、さらに詳細な機能ブロックの一例を表す図
【図２１】実施例２のコンテンツ再生システムの記録再生装置におけるハードウェア構成の一例を表す概略図
【図２２】実施例２のコンテンツ再生システムの記録再生装置における処理の流れの一例を表すフローチャート
【図２３】実施例３のコンテンツ再生システムの管理サーバにおける機能ブロックの一例を表す図
【図２４】実施例２の管理サーバのリクエスト画面送信制御部でのリクエスト画面を分割する制御処理の一例を表す概念図
【図２５】実施例３のコンテンツ再生システムの管理サーバにおけるさらに詳細な機能ブロックの一例を表す図
【図２６】実施例３のコンテンツ再生システムの管理サーバにおけるハードウェア構成の一例を表す概略図
【図２７】実施例３のコンテンツ再生システムの管理サーバにおける処理の流れの一例を表すフローチャート
【図２８】実施例３のコンテンツ再生システムにおいて、リクエスト画面を分割し送信する処理の流れの一例を表すシーケンス図
【図２９】実施例４のコンテンツ再生システムにおける機能ブロックの一例を表す図
【図３０】実施例４の管理サーバでの時間帯リクエスト画面送信処理の一例を表す概念図
【図３１】実施例４のコンテンツ再生システムの管理サーバにおけるハードウェア構成の一例を表す概略図
【図３２】実施例４のコンテンツ再生システムの管理サーバにおける処理の流れの一例を表すフローチャート
【図３３】実施例４のコンテンツ再生システムにおいて、時間帯リクエスト画面を送信する処理の流れの一例を表すシーケンス図
【符号の説明】
【０１７９】
０２００ 管理サーバ
０２０１ 集計部
０２０２ リクエスト画面送信部
０２１０α プライベート再生システムα
０２１１α 記録再生装置
０２１２α 携帯再生装置
０２１０β プライベート再生システムβ
０２１０γ プライベート再生システムγ
【特許請求の範囲】
【請求項１】
記録再生装置とこの記録再生装置に記録されたコンテンツ専用の再生リクエスト機能を有する携帯再生装置とからなる複数のプライベート再生システムにおける前記再生リクエストを管理する管理サーバであって、
同一コンテンツに対する再生リクエストを、プライベート再生システムを横断的に集計する集計部と、
集計部での集計結果に基づく再生リクエストのためのインターフェース画面であって、前記集計された再生リクエストで示されるコンテンツのコンテンツ名を含むリクエスト画面を生成し、前記携帯再生装置に対して送信するリクエスト画面送信部と、
を有するとともに、
前記リクエスト画面に含まれるコンテンツ名に対応するコンテンツが前記リクエスト画面の送信先のプライベート再生システムに存在しないと判断した場合、前記コンテンツ名に対応するコンテンツを取得可能なサイトへのリンクを前記リクエスト画面に挿入することを特徴とする管理サーバ。
【請求項２】
同一コンテンツに対する再生リクエスト数を集計し集計結果に基づいて再生リクエスト数が多い順にコンテンツを選択可能に並べたリクエスト画面を生成するリクエスト画面生成部と、
リクエスト画面の送信先である前記携帯再生装置において１画面内に表示できる範囲を生成したリクエスト画面が超えている場合には当該携帯再生装置からのリクエスト画面要求ごとに再生リクエスト数が多い順に１画面分ずつリクエスト画面を分割してリクエスト画面送信部に送信させるリクエスト画面送信制御部と、
を有する請求項１に記載の管理サーバ。
【請求項３】
前記携帯再生装置は、時間帯ごとの集計結果に基づくリクエスト画面の要求を送信するための時間帯リクエスト画面要求部を有する携帯再生装置であって、
同一コンテンツに対する再生リクエスト数をリクエスト時間帯ごとに集計し、前記携帯再生装置からの時間帯リクエスト画面要求に応じてリクエスト時間帯ごとのリクエスト画面を送信するようリクエスト画面送信部を制御する時間帯制御部を有する請求項１または２に記載の管理サーバ。
【請求項４】
記録再生装置とこの記録再生装置に記録されたコンテンツ専用の再生リクエスト機能を有する携帯再生装置とからなる複数のプライベート再生システムにおける前記再生リクエストを管理する管理サーバの動作方法であって、
同一コンテンツに対する再生リクエストを、プライベート再生システムを横断的に集計する集計ステップと、
集計ステップでの集計結果に基づく再生リクエストのためのインターフェース画面であって、前記集計された再生リクエストで示されるコンテンツのコンテンツ名を含むリクエスト画面を生成し、前記携帯再生装置に対して送信するリクエスト画面送信ステップと、
を計算機に実行させるとともに、
前記リクエスト画面に含まれるコンテンツ名に対応するコンテンツが前記リクエスト画面の送信先のプライベート再生システムに存在しないと判断した場合、前記コンテンツ名に対応するコンテンツを取得可能なサイトへのリンクを前記リクエスト画面に挿入することを特徴とする管理サーバの動作方法。
【請求項５】
同一コンテンツに対する再生リクエスト数を集計し集計結果に基づいて再生リクエスト数が多い順にコンテンツを選択可能に並べたリクエスト画面を生成するリクエスト画面生成ステップと、
リクエスト画面の送信先である前記携帯再生装置において１画面内に表示できる範囲を生成したリクエスト画面が超えている場合には当該携帯再生装置からのリクエスト画面要求ごとに再生リクエスト数が多い順に１画面分ずつリクエスト画面を分割してリクエスト画面送信ステップにて送信させるリクエスト画面送信制御ステップと、
を計算機に実行させる請求項４に記載の管理サーバの動作方法。
【請求項６】
前記携帯再生装置は、時間帯ごとの集計結果に基づくリクエスト画面の要求を送信するための時間帯リクエスト画面要求ステップを計算機に実行させる携帯再生装置であって、
同一コンテンツに対する再生リクエスト数をリクエスト時間帯ごとに集計し、前記携帯再生装置からの時間帯リクエスト画面要求に応じてリクエスト時間帯ごとのリクエスト画面を送信するようリクエスト画面送信ステップを制御する時間帯制御ステップを計算機に実行させる請求項４または５に記載の管理サーバの動作方法。
【請求項１】
記録再生装置とこの記録再生装置に記録されたコンテンツ専用の再生リクエスト機能を有する携帯再生装置とからなる複数のプライベート再生システムにおける前記再生リクエストを管理する管理サーバであって、
同一コンテンツに対する再生リクエストを、プライベート再生システムを横断的に集計する集計部と、
集計部での集計結果に基づく再生リクエストのためのインターフェース画面であって、前記集計された再生リクエストで示されるコンテンツのコンテンツ名を含むリクエスト画面を生成し、前記携帯再生装置に対して送信するリクエスト画面送信部と、
を有するとともに、
前記リクエスト画面に含まれるコンテンツ名に対応するコンテンツが前記リクエスト画面の送信先のプライベート再生システムに存在しないと判断した場合、前記コンテンツ名に対応するコンテンツを取得可能なサイトへのリンクを前記リクエスト画面に挿入することを特徴とする管理サーバ。
【請求項２】
同一コンテンツに対する再生リクエスト数を集計し集計結果に基づいて再生リクエスト数が多い順にコンテンツを選択可能に並べたリクエスト画面を生成するリクエスト画面生成部と、
リクエスト画面の送信先である前記携帯再生装置において１画面内に表示できる範囲を生成したリクエスト画面が超えている場合には当該携帯再生装置からのリクエスト画面要求ごとに再生リクエスト数が多い順に１画面分ずつリクエスト画面を分割してリクエスト画面送信部に送信させるリクエスト画面送信制御部と、
を有する請求項１に記載の管理サーバ。
【請求項３】
前記携帯再生装置は、時間帯ごとの集計結果に基づくリクエスト画面の要求を送信するための時間帯リクエスト画面要求部を有する携帯再生装置であって、
同一コンテンツに対する再生リクエスト数をリクエスト時間帯ごとに集計し、前記携帯再生装置からの時間帯リクエスト画面要求に応じてリクエスト時間帯ごとのリクエスト画面を送信するようリクエスト画面送信部を制御する時間帯制御部を有する請求項１または２に記載の管理サーバ。
【請求項４】
記録再生装置とこの記録再生装置に記録されたコンテンツ専用の再生リクエスト機能を有する携帯再生装置とからなる複数のプライベート再生システムにおける前記再生リクエストを管理する管理サーバの動作方法であって、
同一コンテンツに対する再生リクエストを、プライベート再生システムを横断的に集計する集計ステップと、
集計ステップでの集計結果に基づく再生リクエストのためのインターフェース画面であって、前記集計された再生リクエストで示されるコンテンツのコンテンツ名を含むリクエスト画面を生成し、前記携帯再生装置に対して送信するリクエスト画面送信ステップと、
を計算機に実行させるとともに、
前記リクエスト画面に含まれるコンテンツ名に対応するコンテンツが前記リクエスト画面の送信先のプライベート再生システムに存在しないと判断した場合、前記コンテンツ名に対応するコンテンツを取得可能なサイトへのリンクを前記リクエスト画面に挿入することを特徴とする管理サーバの動作方法。
【請求項５】
同一コンテンツに対する再生リクエスト数を集計し集計結果に基づいて再生リクエスト数が多い順にコンテンツを選択可能に並べたリクエスト画面を生成するリクエスト画面生成ステップと、
リクエスト画面の送信先である前記携帯再生装置において１画面内に表示できる範囲を生成したリクエスト画面が超えている場合には当該携帯再生装置からのリクエスト画面要求ごとに再生リクエスト数が多い順に１画面分ずつリクエスト画面を分割してリクエスト画面送信ステップにて送信させるリクエスト画面送信制御ステップと、
を計算機に実行させる請求項４に記載の管理サーバの動作方法。
【請求項６】
前記携帯再生装置は、時間帯ごとの集計結果に基づくリクエスト画面の要求を送信するための時間帯リクエスト画面要求ステップを計算機に実行させる携帯再生装置であって、
同一コンテンツに対する再生リクエスト数をリクエスト時間帯ごとに集計し、前記携帯再生装置からの時間帯リクエスト画面要求に応じてリクエスト時間帯ごとのリクエスト画面を送信するようリクエスト画面送信ステップを制御する時間帯制御ステップを計算機に実行させる請求項４または５に記載の管理サーバの動作方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【公開番号】特開２０１２−１１００５５（Ｐ２０１２−１１００５５Ａ）
【公開日】平成２４年６月７日（２０１２．６．７）
【国際特許分類】
【出願番号】特願２０１２−４４７０９（Ｐ２０１２−４４７０９）
【出願日】平成２４年２月２９日（２０１２．２．２９）
【分割の表示】特願２００８−５４４０８７（Ｐ２００８−５４４０８７）の分割
【原出願日】平成１９年９月５日（２００７．９．５）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２４年６月７日（２０１２．６．７）
【国際特許分類】
【出願日】平成２４年２月２９日（２０１２．２．２９）
【分割の表示】特願２００８−５４４０８７（Ｐ２００８−５４４０８７）の分割
【原出願日】平成１９年９月５日（２００７．９．５）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]