コンテンツ管理システム
【課題】
既に有効なコンテンツをダウンロードしているユーザに対し、同じコンテンツを重複してダウンロードできる仕組みを提供する。
【解決手段】
コンテンツを配信するシステム側で、ユーザが購入しようとしているコンテンツは、そのユーザが既にダウンロードしている有効期限内のコンテンツであるか否かを調べ、そうである場合は、重複買いのための新しいコンテンツID、DL情報、メタ情報を用意して、同じコンテンツの重複買いを可能とする。
既に有効なコンテンツをダウンロードしているユーザに対し、同じコンテンツを重複してダウンロードできる仕組みを提供する。
【解決手段】
コンテンツを配信するシステム側で、ユーザが購入しようとしているコンテンツは、そのユーザが既にダウンロードしている有効期限内のコンテンツであるか否かを調べ、そうである場合は、重複買いのための新しいコンテンツID、DL情報、メタ情報を用意して、同じコンテンツの重複買いを可能とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザからの要求に応じて記憶装置に格納してあるコンテンツをユーザにダウンロードさせる技術に関する。
【背景技術】
【０００２】
ユーザが視聴するコンテンツに関し通信網を介し提供する形態には、大きくストリーミングとダウンロードがあり、記憶装置に格納してあるコンテンツをダウンロードしてそのコンテンツを視聴する公知技術の１つとして特許文献１に記載がある。
【０００３】
航空機において乗客が座席に着席した状態で、音楽や映像などのコンテンツを楽しみたい時に、その要求に遠隔的に応える様にした航空機内エンターテイメントシステム装置が開発・提供されるようになってきている。ＭＰＥＧ１／２等の画像の高能率圧縮技術を用いて、たとえば、５０から２００タイトルの映画コンテンツ等、たくさんのコンテンツの選択視聴が可能になってきている。
【０００４】
従来の航空機内エンターテイメントシステムの構成として特許文献１の図１２において、１２１はプログラムビデオサービスコントロールユニット、１２２はビデオサーバ、１２３は分配・結合器、１２４から１２６は分配器、１２７から１２９はシート端末、１３０から１３２は液晶ディスプレイである。
ビデオサーバ１２２にはＭＰＥＧ２方式等で圧縮された映像信号が記録されている。各シート端末からのリクエストを受信することにより、プログラムビデオサービスコントロールユニット１２１が、ビデオサーバ１２２よりＭＰＥＧ２方式で圧縮されて記録されているデータを読み出し、各シート端末に対しコンテンツの配布を行う。コンテンツは、分配・結合器１２３、分配器１２４、１２５、１２６を経由してコンテンツが配布される。コンテンツは、ＭＰＥＧ２のトランスポートストリーム形式で１６ＱＡＭ等の変調方式で変調を行い、同軸ケーブル等を介して伝送される。
【０００５】
このときプログラムビデオサービスコントロールユニット１２１とシート端末１２７、１２８、１２９の間はＴＣＰ／ＩＰプロトコルにより通信が行われる。このＴＣＰ／ＩＰの信号についても周波数変調がかけられて、コンテンツ配信と同じ同軸ケーブルを通じて通信を行う。このため、分配・結合器１２３は、ＭＰＥＧ２のトランスポートストリームと、ＴＣＰ／ＩＰ信号の信号についての周波数的な多重と、多重分離の機能を持つ、また分配器１２４、１２５、１２６においては、信号の分岐を行い、各シート端末に対し同じ信号の分配を行う。シート端末１２７、１２８、１２９においては圧縮されて伝送されてくる映像音声信号について、ＭＰＥＧ２の圧縮伸張を行い、液晶ディスプレイ１３０、１３１、１３２への表示を行う。
【０００６】
上記のシステムは、一般的にビデオオンデマンドシステム（ＶＯＤシステム）と呼ばれている。特許文献１の航空機内エンターテイメントシステムは、航空機内というクローズしたネットワーク環境で使用され、且つ各シート端末の固定ユーザへのビデオ配信に限定されているため、ユーザ認証や端末認証、配信されるビデオに対するライセンス認証、配信されるビデオの暗号化を考慮してはいない。現在、ケーブルＴＶやディジタルＴＶで実現されているＶＯＤシステムを使用したＶＯＤサービスにおいては、不特定使用者でのオンデマンドなビデオ配信を実現するため、ユーザ認証や端末認証、配信されるビデオに対するライセンス認証、配信されるビデオの暗号化を行うのが一般的である。
【０００７】
ＶＯＤサービスにおいては、ユーザは視聴したいビデオのコンテンツを選択後、リアルタイムにビデオ配信が行われ、ユーザはそれをその場で即座に視聴することになる。しかし、ＶＯＤサービスでビデオを受信している間は、大量のビデオ情報がネットワークに流れることになり、その間は極めてネットワーク負荷を増大させ、又ビデオ情報の伝送には極めてリアルタイム性が要求され、ビデオ情報の伝送の優先順位が高くなっているため、ネットワークを使用した他の情報処理を並行して行おうとすると、他の情報処理の処理速度が遅くなるばかりでなく、他の情報処理を阻害することにもなりえる。
【０００８】
そこで、ユーザが端末からビデオ情報のダウンロードを要求し、ネットワークを使用していない間にビデオ情報を端末にダウンロードし端末に記憶しておき、ユーザが所望するタイミングで記憶したビデオ情報を視聴するサービスが検討されている。これをＤＬサービスと称する。ＤＬサービスにおいては、ビデオ情報は予め端末にダウンロードされ記憶されているため、ユーザの視聴中にはネットワークを使用しないため、ネットワーク負荷を増大させる問題は発生しない。又、一度ダウンロードしたビデオ情報を、そのビデオ情報の視聴可能期間においては、再度何度でも端末上で視聴可能である。これは、レンタルビデオをレンタルビデオ屋から借りてきて、レンタル期間中は何度でも視聴出来ることに似ている。又近年、端末の進歩は甚だしく、固定端末：テレビ、デスクトップＰＣ等、移動端末：携帯電話、ＰＤＡ、モバイルＰＣ等の何れからでも、インターネットに接続して、どの端末からでも同一の情報にアクセス可能である。そこで、ユーザが移動中に、例えば携帯電話で次の日視聴したいビデオをビデオ一覧表から選択し、予め携帯端末からＤＬサービスの要求を行っておき、帰宅後次の日に自宅のＴＶに予めダウンロードされているユーザの所望するビデオを所望するタイミングで視聴することが可能となる。
【０００９】
このようなユーザの利便性は到底ＶＯＤサービスにおいて得られるものではない。つまりＤＬサービスは、モバイル情報化社会において、ユーザの都合に鑑み柔軟に対応可能なユーザにとって利便性の高い情報提供サービスであると言える。勿論ＤＬサービスにおいても、不特定使用者でのビデオのＤＬサービスを実現するためには、ユーザ認証や端末認証、配信されるビデオに対するライセンス認証、配信されるビデオの暗号化を行うのが一般的である。
【００１０】
【特許文献１】特開２００２−３４０５９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
先ず図１０を用いて、従来DLサービスで一般的にセンタシステムがDLサービスの提供と管理を行うための情報：主に鍵とコンテンツの関係を説明する。通常、ユーザの端末にダウンロードされるコンテンツ1003自体は対応する暗号鍵1002で暗号化されている。これはＤＬサービスにおいては、対応する暗号鍵1002で暗号化されたコンテンツ1003がユーザの端末にダウンロードされた後、ユーザが所望するタイミングでダウンロードされたコンテンツ1003を視聴する際、ユーザの端末は対応する暗号鍵1002をセンタシステムから取得し、ユーザの端末上で暗号鍵1002を用いて暗号1002で暗号化されたコンテンツ1003の暗号を解いて視聴を行うためである。暗号鍵1002とコンテンツ1003それぞれに対応して、ＤＬサービスの提供と管理を行う素コンテンツ識別情報1001を有している。
【００１２】
素コンテンツ識別情報1001は、販売情報としてコンテンツ名（コンテンツ自体のタイトル、例えば図１０においてはＭＨ，Ｏ３，Ｏ２）、暗号鍵（例えば、図１０においてはＫｅｙＡ、ＫｅｙＢ、ＫｅｙＣ）、ライセンス条件（例えばエキスポート可／不可、１８歳未満視聴禁／１５歳未満視聴禁）、ユーザＩＤ、販売日、視聴期間等、コンテンツや暗号鍵のＤＬを実際に実行するためのＤＬ情報としてＤＬコンテンツ提供場所、ライセンス（暗号鍵）提供場所、メタ情報（コンテンツ自体に付随する言語、ジャンル、番宣、タイトルの簡単な紹介や出演者等）提供場所等、メタ情報としてコンテンツ自体に付随する言語、ジャンル、番宣、タイトルの簡単な紹介や出演者等、の情報を含むと共に、それらの情報には１個の識別子：コンテンツＩＤ（図１０においては、ＣＮＴ１２３４，ＣＮＴ１２０１，ＣＮＴ１３０１）が付与されている。ＤＬサービスの提供と管理においては、このコンテンツＩＤを識別子に用いている。
【００１３】
以上のように、従来のＤＬサービスでは、コンテンツＩＤでユーザＩＤと販売日、視聴期間等が一体で、素コンテンツ識別情報1001として管理されているため、あるユーザがあるコンテンツについて、ＤＬサービスを利用している間（視聴期間中）は、再度ダウンロードを行うことは出来ない。つまり、ユーザが過去にダウンロードして現在も有効なコンテンツを保有している場合、あらたにそのコンテンツを購入しようとしても、このコンテンツの購入に必要となる素コンテンツ情報や、コンテンツの視聴に必要となる暗号鍵1002について何ら考慮されていない。
【００１４】
ここで図１３を用いて、ＤＬサービスのサービスイメージと、重複買いシチュエーションの重要性、必要性について説明する。図１３の（ａ）は重複買いできないＤＬサービスの場合の例を表している。この場合、ユーザは初回ＤＬとして１１／１９の夜に最初のＤＬサービスの要求を行っている。ここでは、例としてタイトル：ＭＨについて２泊３日でＤＬサービスの要求を行い、1301は、実際にコンテンツのダウンロードが行われ、その後ユーザが視聴可能な期間を表しており、１１／２１中までならダウンロードされたコンテンツをユーザは視聴可能である。通常、コンテンツの容量というのは２〜３時間の映画を想定した場合、ネットワークのトラフィックにもよるがダウンロードにも同等程度の時間を必要としたりなどする。それ故コンテンツのダウンロードはユーザが端末を使用していないトラフィックも低い深夜の時間帯に行なうなど端末の商品企画によっては十分考えられることである。また、これも端末の商品企画次第であるが、端末によっては、或いはベーシックな端末仕様としては、ダウンロードが完了してから再生できる動作となる為、こういったベーシックな端末を所持するユーザにとっては、ダウンロードを完了してから視聴可能となるなどする。端末によっては、プログレッシブダウンロード（プログレッシブダウンロードとは、コンテンツをダウンロードしながら再生視聴できることを意味する）の機構を具備した端末も考えられるが、市場に投入される端末が全てそういった高機能端末であるとは限らない。
【００１５】
図１３でユーザは、突然の遠隔出張になり、出張から帰宅するのは１１／２２以降であるとする。この場合ユーザは、1301で折角ダウンロードしたコンテンツを視聴出来ないことになる。又１１／２２になって帰宅し、直ぐに再度ＤＬサービスの要求を行ったとしても、上述の如くダウンロードを行うのに時間を要することも考えられる為、直ぐには視聴出来ないという問題が発生し得る。1302は、１１／２２になって帰宅し、直ぐに再度タイトル：ＭＨについて当日限りが有効期限のＤＬサービスの要求を行った後、実際にコンテンツのダウンロードが行われて、視聴可能な期間を表している。
【００１６】
それに対して、図１３の（ｂ）はユーザに重複買いを許容する場合のＤＬサービスの例を表している。この場合、１１／２０に遠隔出張が決定したタイミングで、再ＤＬとして１１／２０に再度のＤＬサービスの要求を行っている。ここでは、例としてタイトル：ＭＨについて２泊３日で再度ＤＬサービスの要求を行い、1303は、実際にコンテンツのダウンロードが行われ、その後ユーザが視聴可能な期間を表しており、１１／２２中までならダウンロードされたコンテンツをユーザは視聴可能である。このように、既にＤＬサービスの要求を行ったコンテンツについて視聴可能な期間内にユーザが視聴出来ないことが決定したタイミングで、再ＤＬを実行可能な機会を提供することは、ユーザの視聴機会を高めると共に、ＤＬサービスにおけるダウンロード待ちの煩わしさを軽減すると共に、ユーザの都合に鑑み柔軟に対応可能なユーザにとって利便性の高いＤＬサービスが提供可能となる。
【００１７】
又、別の例についても説明する。子供が貸出日同日内返却（当日レンタル）でコンテンツをダウンロードしたが、急に、親戚が入院し今から家族全員外出する事が判明した。帰宅後、直ぐに視聴出来るよう、病院に行く前に、３泊４日で再ＤＬしたいが重複買いができない場合はこのような要求に対応出来ない。ゆえ、当日レンタルが期限切れになり、帰宅後でしか、再ＤＬを行うことが出来ない。明日まで待つしかないということになるわけである。しかし、重複買いできるＤＬサービスの場合には、病院に行く前に、３泊４日で再ＤＬを行い、帰宅後既にダウンロードされているコンテンツを直ぐに視聴可能となるわけである。この例で言えることは、ＴＶの場合１人１台という概念は一般的に無く、家族皆で利用するのが通常のような場合、家族の誰かが購入していることを知らずに、別の人が同一のコンテンツを購入する場合も考えられる。そこで、本当に必要性に迫られて重複買いするのか、誤って重複買いするのかは、ユーザが正規に判断し、必要とするユーザへ重複買いの機会を提供することが必要である。上記のように重複買いできるＤＬサービスを提供する場合、本当に必要で重複買いするのか、誤って重複買いを行っているかの判別をユーザに支援しなければいけないという課題も重要である。
【課題を解決するための手段】
【００１８】
上記課題を解決するために本発明では、ユーザからのコンテンツダウンロード要求を受けたセンタシステムが、当該ユーザが視聴可能な同じコンテンツを既にダウンロードしているか否かを判断し、そのようなコンテンツを既にダウンロードしている場合は、そのコンテンツのコンテンツID、DL情報、メタ情報を重複買い用の情報としてそれぞれ新たに作成し、ユーザに視聴可能な同じコンテンツの重複買いを可能とする機能・手段を備える。
【発明の効果】
【００１９】
上記のように、重複買いできるＤＬサービスにより、ユーザの視聴機会を高めると共に、ＤＬサービスにおけるダウンロード待ちの煩わしさを軽減すると共に、ユーザの都合に鑑み柔軟に対応可能なユーザにとって利便性の高いＤＬサービスが提供可能となる。
【発明を実施するための最良の形態】
【００２０】
以下、図面を用いて本件発明の実施例の一つを説明する。図１は、本発明におけるネットワーク構成の一実施例を示したものである。例えばPCやテレビ、PDA等のユーザ端末
105、106、107が、例えばインターネット等の通信網104を介して、コンテンツの配信を制御するセンタシステム101に接続されている。センタシステム101は通信網104を介してユーザ端末105等からコンテンツの配信要求を受信し、配信が可能と判断した場合には通信網104を介してユーザ端末105等にコンテンツをダウンロードする。センタシステム101は、その機能や要求される処理能力に応じて、複数のサブシステム102、103に分けて適宜構成して良く、必ずしも一台の装置で実装される必要は無い。また、サブシステム102や103は地理的に離れた、異なるネットワーク上に存在させても良い。
【００２１】
図２は、図１においてセンタシステム101とユーザ端末105を例示し、両者が有する機能部の一実施例について説明する図である。ユーザ端末105は、ユーザの操作を受けてセンタシステム101に情報を送信し、またはセンタシステム101から受信した情報を処理して、必要に応じてユーザに伝える処理を行なう端末処理部201と、センタシステム101との間で送受信する情報を格納する記憶部202を有する。
【００２２】
センタシステム101は、ユーザからコンテンツのダウンロード要求を受け付ける販売受付部203と、ユーザがどのようなコンテンツのダウンロードをしているのかを管理する販売管理部205と、ユーザがコンテンツをダウンロードするために必要な情報であるダウンロード情報を作成し、ユーザに提供するＤＬ情報提供部207と、ユーザがＤＬ情報提供部207から取得したダウンロード情報を用いてコンテンツ本体をダウンロードする場合に、ユーザにコンテンツ本体を配信する処理を行なうＤＬ配信部210とを有する。また、センタシステム101は、コンテンツごとにそのダウンロード情報を提供する場所、例えばＵＲＬ等を格納する記憶部204と、ユーザごとのコンテンツ販売情報やコンテンツの再生に必要な鍵情報、ユーザがコンテンツを重複して買う場合にそのコンテンツのダウンロード情報を提供する場所である、一時的に使用されるＵＲＬ等を格納する記憶部206と、コンテンツのメタ情報やＤＬ情報を格納する記憶部208と、コンテンツ本体を格納する記憶部211とを有する。
【００２３】
図３はセンタシステム101の中で、販売受付部203、販売管理部205、ＤＬ情報提供部207についてさらに詳細な実施例を説明するための図である。以下、図2と図3を参照しながら、ユーザ端末105がコンテンツをダウンロードする一連の処理について説明する。
【００２４】
センタシステム101はユーザ端末105にコンテンツの一覧等を提供し、ユーザはユーザ端末105の表示画面に表示されるコンテンツの中から所望のコンテンツを選択する。ユーザが表示画面上のコンテンツをクリックする等の購入操作を実行すると、ユーザ端末105の端末処理部201は、センタシステム101に対し、コンテンツの購入を要求するメッセージを送信する。
【００２５】
センタシステム101の販売受付部203は、ユーザ端末105からコンテンツの購入を要求するメッセージを受信すると、販売受付処理部301により、ユーザが要求しているコンテンツを識別するための情報であるコンテンツIDと、ユーザ情報、さらにはユーザが希望するそのコンテンツの期限情報を特定する。この実施例では、コンテンツIDは例えば「１２３４」であり、ユーザIDは例えば「１１０１」であり、期限情報は２泊３日であるとする。販売受付処理部部301は、コンテンツID「１２３４」を販売管理部205に送信し、販売管理部205の重複買い判定部302は、このユーザがコンテンツID「１２３４」で特定されるコンテンツを、現在時点で正規に視聴可能な権利を有しているか否か、記憶部206の販売情報を参照して調べる。このように販売管理部205は、このユーザが、既にダウンロードしている実行可能なコンテンツを持っているにもかかわらず、同じ内容のコンテンツを重複して購入しようとしているのかを判定する。
【００２６】
記憶部206に格納される情報の一実施例を図4に示す。図4の実施例で記憶部206には、ユーザごとの販売情報400、401と、鍵情報410と、ワンタイムURL409とが格納されている。販売情報については、ユーザID1101のユーザ用に販売情報400のテーブルを、ユーザID1102のユーザ用に販売情報401のテーブルをそれぞれ用意している。各テーブルには、コンテンツを識別するためのコンテンツID402と、コンテンツを販売した日付である販売日403と、そのコンテンツの視聴可能な期間を表す視聴期間404と、現在の日付がコンテンツの販売日から視聴期間内にあるかどうか等の条件により、そのコンテンツのレコードが有効か否かを示すレコード有効／無効フラグ406と、そのコンテンツをダウンロードするために必要な情報を入手できる場所を指定する、ＵＲＬ等の場所情報406と、その他の情報407のカラムを有する。なお、本実施例では場所情報としてURLを例示しているが、URL以外のIPアドレス等のアドレス情報や、その他ネットワーク上のロケーションを特定できる情報を場所情報として用いることができる。
【００２７】
図4で、コンテンツID「１２０１」と「１２０１−１」は、重複買いが発生していることを表す。コンテンツID「１２０１」の提供場所情報406が「標準」となっているのは、もともとコンテンツＩＤ「１２０１」のコンテンツのために用意されている提供場所を使用できるからである。一方、コンテンツＩＤ「１２０１−１」の提供場所情報406が「URL：abc」となっているのは、重複買いを可能とするために、後述するＤＬ情報提供部207が重複買い用の提供場所を一時的に作成しているためである。
【００２８】
重複買い判定部302は、販売情報テーブル400にコンテンツID「１２３４」が既に登録されており、しかも視聴期間内でエントリが有効であるため、ユーザが同じコンテンツを重複買いしようとしていると判断する。この場合、重複処理部303は、新たなコンテンツID「１２３４−１」を作成し、さらにこの新たなコンテンツIDを用いてコンテンツをダウンロードするために用いるワンタイムURLを作成し、販売情報テーブル400にコンテンツID「１２３４−１」と作成したワンタイムURLを提供場所情報406として登録する。
【００２９】
コンテンツID「１２３４」と「１２３４−１」はともに、同じコンテンツを指し示す識別情報であるが、ダウンロードの過程が異なるために、同じコンテンツでありながらも異なる識別子を与えている。そして本実施例では、DL情報やメタ情報を、同じコンテンツを指すコンテンツID「１２３４」と「１２３４−１」それぞれに作成している点が特徴である。
【００３０】
そしてローカルコンテンツ処理指示部304は、DL情報提供部207のワンタイム提供データ作成処理部305に対して、コンテンツID「１２３４−１」とワンタイムURL、さらには素コンテンツID「１２３４」とコンテンツの提供期限を通知し、これらIDとURLを用いてユーザにコンテンツをダウンロードさせるためのDL情報ならびにメタ情報の作成を指示する。なお、ユーザは必ずしもメタ情報の入手を要求するとは限らないため、メタ情報の作成は本実施例では必須ではなく、省略しても良い。
【００３１】
DL情報とは、コンテンツをコンテンツID「１２３４−１」で特定してダウンロードするために必要な情報、例えばメタ情報の提供場所であるURL等や、コンテンツそのものをダウンロードするURL等の場所、さらにはダウンロードしたコンテンツを実行するためのライセンスの提供場所等を含む。このDL情報は、例えばRFC4287に記載されているタグ言語を利用しても良い。
【００３２】
また、メタ情報とはコンテンツID「１２３４−１」により特定されダウンロードされるコンテンツの属性を示す情報であり、例えばコンテンツが映画であればそのジャンルや言語等の情報を含み、さらにどのユーザに対してどれだけの有効期間でダウンロードされるのかといった情報や、ユーザの利用ライセンス（例えば視聴権利など）に関わる条件といった情報も含む。このメタ情報は、例えばARIB(Association of Radio Industries and Businesses) STD-B38で書き方のきまりが規格化されている、記述言語型メタデータの元となるデータ群である。ワンタイム提供データ作成処理部305は、作成したDL情報やメタ情報を記憶部208に格納する。
【００３３】
DL情報の一実施例を図5に示す。DL情報509は、重複買いでは無い、素のコンテンツIDでコンテンツを特定した場合のDL情報であり、DL情報510は重複買いのため素コンテンツIDを基に新たに作成されたコンテンツIDによりコンテンツを特定した場合のDL情報である。DL情報510は、ＤＬ情報を取得できる場所を示すＤＬ情報提供場所501と、コンテンツＩＤ502と、例えば映画の題名等のコンテンツタイトル503と、重複買い用のコンテンツＩＤでダウンロードする場合にメタ情報を取得できる場所を示すメタ情報提供場所504と、コンテンツ本体をダウンロードするための場所であるＤＬコンテンツ提供場所505と、そのコンテンツを実行するためのライセンスを取得するための場所であるライセンス提供場所506と、重複買いしたコンテンツの有効期限を示す取扱い期限507と、その他の情報508とを有する。
【００３４】
DL情報509とDL情報510を比較した場合に、もとのコンテンツＩＤと重複買い用のコンテンツＩＤとでは、ＤＬ情報提供場所501とメタ情報提供場所504が異なり、ＤＬコンテンツ提供場所505とライセンス提供場所506が同じである点が特徴である。つまり、ＤＬ情報提供場所501やメタ情報提供場所504をコンテンツＩＤごとに用意することで、コンテンツを取得する上で必要なデータだけを複数用意し、ＤＬコンテンツ提供場所505を同じにすることでコンテンツ本体は1つで足り、またライセンス提供場所506を同じとすることでコンテンツ再生用の鍵も1つで済むようにしている。
【００３５】
メタ情報の一実施例を図6に示す。図6中、メタ情報610は重複買いの対象ではない、もとのコンテンツＩＤで特定されるコンテンツに付随する情報を格納したテーブルであり、メタ情報611は、重複買いの対象である、重複処理部303により作成されたコンテンツＩＤにより特定されるコンテンツに付随する情報を格納したテーブルである。メタ情報611には、メタ情報を取得できるURL等の場書情報を表すメタ情報提供場所601と、コンテンツID602と、コンテンツタイトル603と、DLコンテンツ提供場所604と、ライセンス提供場所605と、そのコンテンツで使用される言語606と、そのコンテンツのジャンル607と、宣伝情報である番宣608と、その他ユーザに提供される情報609とが格納されている。
【００３６】
メタ情報610とメタ情報611の両テーブルを比較した場合に、もとのコンテンツＩＤと重複買い用のコンテンツＩＤとでは、メタ情報提供場所601が異なり、ＤＬコンテンツ提供場所505とライセンス提供場所506が同じである。
【００３７】
ローカルコンテンツ処理指示部304は、販売受付部203のワンタイム処理部306に、ユーザの重複買いを受け付けることを伝えるACKと、コンテンツID「１２３４−１」のために作成したワンタイムURLを通知する。ワンタイム処理部306はこのワンタイムURLをDL情報提供場所データとして、記憶部204に格納する。DL情報提供場所データの一実施例を図7に示す。この実施例のとおり、DL情報提供場所データ７00は、少なくともコンテンツIDとDL情報提供場所とを対応付けた情報である。
【００３８】
そして販売受付処理部301は、ユーザに対し、コンテンツの購入を受け付けた旨を伝えるメッセージと、そのコンテンツをダウンロードするためにアクセスする必要があるワンタイムURLを送信する。この後、ユーザ端末105の表示画面にはワンタイムURLが表示される等し、ユーザがワンタイムURLをクリックする、もしくはユーザ端末105が自動的にワンタイムURLにアクセスする等すると、端末処理部201はセンタシステム101に対しDL情報を要求するメッセージを送信する。
【００３９】
なお、センタシステム101は、ユーザ端末105に対し、このユーザが視聴可能なコンテンツを重複して購入しようとしていることを知らせるメッセージや、さらには、それでも購入するのか意思を確認するメッセージを送信しても良い。このメッセージに対しユーザがそれでも重複買いをする旨の意思表示をセンタシステム101に返信した場合に、センタシステム101はユーザ端末105に購入を受け付けた旨とワンタイムURLを送信するようにしても良い。この場合は、意図せずに間違って同じコンテンツを購入しようとしているユーザに注意を促すことができる。
【００４０】
DL情報提供部207のDL情報提供処理部307は、このメッセージを受信すると、記憶部208を参照してコンテンツID「１２３４−１」でコンテンツを特定する場合のDL情報を取得し、ユーザ端末105に返信する。DL情報とは、コンテンツをコンテンツID「１２３４−１」で特定してダウンロードするために必要な情報、例えばメタ情報の提供場所であるURL等や、コンテンツの本体そのものをダウンロードするURL等の場所、さらにはダウンロードしたコンテンツを実行するためのライセンスの提供場所等を含む。ユーザ端末105は、受信したDL情報を入手DL情報212として記憶部202に保存する。
【００４１】
次にユーザ端末105は、受信したDL情報212に含まれるコンテンツID「１２３４−１」を用いて、同じくDL情報212に含まれるメタ情報の提供場所に対し、メタ情報を要求する。DL情報提供部207のDL情報提供処理部307はメタ情報の要求を受けて、記憶部208を参照し、ユーザがアクセスしたメタ情報の提供場所に対応するメタ情報を取得して、これをユーザ端末105に返信する。つまり、DL情報提供処理部307は、図6のテーブルGを参照し、ユーザが用いたメタ情報の提供場所に対応するエントリのメタ情報をユーザに提供する。
【００４２】
ユーザ端末処理部201は、提供されたメタ情報を入手メタ情報213として記憶部202に保存する。なお、このメタ情報の取得はコンテンツをダウンロードするにあたりユーザ端末105にとって必須の処理ではないため、省略しても良い。
【００４３】
次にユーザ端末105は、入手DL情報212もしくは入手メタ情報213に含まれるDLコンテンツ提供場所情報を用いて、コンテンツ本体のダウンロードを要求する。センタシステム101のDL配信部210は、この要求に用いられているURL等の場所情報に対応するコンテンツを記憶部211から取得し、ユーザ端末105にダウンロードさせる。ユーザ端末105は、ダウンロードしたコンテンツ本体を、DLコンテンツ本体214として記憶部202に格納する。ここで、コンテンツ本体のダウンロードを要求する、DLコンテンツ提供場所情報は、同じコンテンツについては同じ場所情報となる。つまり、コンテンツID「１２３４」と「１２３４−１」とは同じコンテンツを指すものであるため、DLコンテンツ提供場所情報も同じURL等の情報となる。これにより、重複してコンテンツを買う場合であっても、そのためにコンテンツ本体と暗号鍵の組み合わせをあらかじめ複数用意しておく必要がなくなる。
【００４４】
最後にユーザ端末105は、入手DL情報212もしくは入手メタ情報213に含まれるライセンス提供場所情報を用いて、コンテンツを実行するためのライセンスを要求する。センタシステム101のライセンス要求受付部209は、この要求に用いられているコンテンツ識別しに対応するコンテンツのライセンスの取得を販売管理部205に問い合わせる。販売管理部205の販売レコード照合処理部308は、記憶部206に格納されている当該ユーザの販売情報を参照して、そのユーザにライセンスを与えられるか否かを判断する。この判断は例えば、レコードが有効であるかどうかや、そのユーザに許された実行回数を超えていない等の条件によりなされる。
【００４５】
販売レコード照合処理部308がライセンス可能と判断した場合には、販売レコード照合処理部308は、ライセンス要求に含まれるコンテンツID「１２３４−１」をコンテンツID変換処理部309に送信する。コンテンツID変換処理部309はこのコンテンツID「１２３４−１」をもとのコンテンツID「１２３４」に変換し、記憶部２０６に格納された、図４のテーブルAに示される鍵情報を参照し、コンテンツID「１２３４」に対応する暗号鍵「Key A」を取得し、これを販売レコード照合処理部308に渡す。販売レコード照合処理部308は、ライセンス要求受付部209に暗号鍵を送信する。暗号鍵を受信したライセンス要求受付部209は、その暗号鍵をユーザ端末105に送信し、ユーザ端末105はそれを入手ライセンス215として記憶部202に格納する。
【００４６】
ここで、ライセンス提供場所情報もDLコンテンツ提供場所情報と同様に、同じコンテンツについては同じ場所となるため、コンテンツID「１２３４」と「１２３４−１」とでは同じURL等の場所情報となる。これにより、重複してコンテンツを買う場合であっても、そのために1つのコンテンツに対して複数の暗号鍵を用意しておく必要がなくなる。
【００４７】
ここまでの操作を終えたユーザ端末は、取得したコンテンツを暗号鍵を用いて実行し、例えば動画を再生するなどして利用することができる。
【００４８】
図8は、ユーザ端末105からコンテンツの販売要求を受けたときの処理フローの一実施例である。まず、重複買い判定部302は、販売要求に含まれるユーザ情報やコンテンツIDを用いて記憶部206の当該ユーザの販売情報を参照し(801)、そのユーザについて、そのコンテンツIDで特定される視聴可能なコンテンツの販売レコードが記憶されているかどうかを確認する(802)。販売レコードが無い場合は重複買いではないため、販売管理部205の通常処理部310により記憶部206に新たな販売レコードを作製し(803)、通常処理指示部311を介して販売受付機能部203の通常処理部312に重複買いではない通常のコンテンツ販売処理のメニューをユーザ端末105に送信するよう指示する（804）。
【００４９】
重複買いである場合は、重複処理部303が、重複買い用の新たなコンテンツIDを販売コンテンツID402として、また生成したDL情報の提供場所をワンタイム情報場所情報406として、記憶部206の新たな販売レコードに格納する(805)。ローカルコンテンツ処理指示部304はワンタイム提供データ作成処理部305にDL情報とメタ情報の作成を指示して、ワンタイム提供データ作成処理部305はそれらデータを作成の後、記憶部208に格納する(806)。そしてローカルコンテンツ処理指示部304は、生成したワンタイム提供場所情報を販売受付処理部301に通知し(807)、ここからさらにユーザ端末にワンタイム提供場所情報が展開される。
【００５０】
図９は、図２のセンタシステムの機能部をサーバ装置により実現した場合の一構成例である。図９では、販売受付部203がDLサービスポータル901とポータルアプリケーションサーバ902により実現され、記憶部204がDL情報提供場所DB903で実現されている。また、販売管理部205が顧客・販売管理サーバ904で、記憶部206が販売レコード等DB905でそれぞれ実現されている。DL情報提供部207はDL情報提供アプリケーションサーバ906とDL情報提供Web907により、記憶部208はDL情報提供DB908によりそれぞれ実現されている。ライセンス要求受付部209はライセンス要求受付Web909により実現され、DL配信部210はDL配信サーバ910とコンテンツ管理サーバ911により実現される。また記憶部211はDLコンテンツDBにより実現されている。これはあくまでも一構成例であり、図２の機能部は任意のサーバやコンピュータ等の情報処理装置により、適宜自由に機能を分割、または組み合わせて構成して良い。例えば図2や図3の機能部をそれぞれ別の装置として実現しても良いし、将来コンピュータの処理能力が向上すれば、センタシステム101を一台の装置で実現する場合もあるかもしれない。
【００５１】
図１２は、重複買いをした場合の、ユーザ端末105の表示画面の一例である。画面1201には、タイトル1204が同じO3のコンテンツにつき、購入した情報1202と1203とが表示されている。ユーザは、同じコンテンツについて最初に購入した情報1203と、それに重複して購入した情報1202のうち、好きな方を選択してコンテンツを実行することが可能となる。
【００５２】
従来のＤＬサービスは、[発明が解決しようとする課題]の図１０で説明したように、コンテンツＩＤでユーザＩＤと販売日、視聴期間等が一体で、素コンテンツ識別情報1001として管理されており、あるユーザがあるコンテンツについて、ＤＬサービスを利用している間（視聴期間中）は、同一コンテンツについて再度ダウンロードを行うことは出来ないものであった。
【００５３】
重複買いできるＤＬサービスを比較的単純に提供する方法としては、重複買いを予め考慮し、同一コンテンツに対し、暗号鍵を複数用意しておき、予め、コンテンツに対し該暗号鍵で暗号化を施し、暗号鍵の数分Ｎのコンテンツ本体（暗号化済み）をコンテンツ管理サーバなどで、管理しておく。それにより用意した複数の重複買いが可能となる。しかし、この方法では、
（１）同一コンテンツに対し複数の暗号鍵で複数回暗号化を行うためコンテンツを準備する際の受入れ作業が大幅にアップし作業効率が悪い、
（２）全コンテンツを複数鍵分、事前に用意する必要がある為、センタで管理するべきコンテンツの容量が×Nで膨張する、
（３）センタ管理容量が増大する為、消費電力も高く、環境面でマイナスである、
という重要な問題が発生する。
【００５４】
本実施例による重複買いできるＤＬサービスにおけるセンタシステム101がDLサービスの提供と管理を行うための情報：主に鍵とコンテンツの関係を、図１１を用いて説明する。本実施例においては、ユーザの端末にダウンロードされるコンテンツ1101自体は対応する暗号鍵1102で暗号化されており、1101と1102のその対応は一体一である。先ず、あるユーザに対して初回ＤＬの際にはデフォルトの素コンテンツ識別情報1103を用いて、ＤＬサービスの提供を行う。次に重複販売（重複買い）の再ＤＬの場合には、ローカルコンテンツ識別情報1104を用いて、ＤＬサービスの提供を行う。これにより、コンテンツ1101と暗号鍵1102の一対に対して、再ＤＬが可能となる。又再度同一コンテンツについて、再ＤＬの要求があった場合は、3つめのローカルコンテンツ識別情報1104を作成し用いて、再ＤＬを可能とすることが出来る。
【００５５】
ローカルコンテンツ識別情報1104の識別子：コンテンツＩＤは、素コンテンツ識別情報1103の識別子：コンテンツＩＤとは別に付与することにより、そのＤＬサービスで使用しているコンテンツ識別情報を識別することが可能となり、ＤＬサービス中の端末とセンタの通信においては、素コンテンツ識別情報1103：コンテンツＩＤとローカルコンテンツ識別情報1104の識別子：コンテンツＩＤとをユニークに設定し使用することにより、重複買いできるＤＬサービスのための通信が可能となる。図１１の例においては、タイトル：Ｏ３、タイトル：Ｏ２のそれぞれのコンテンツは対応する暗号鍵ＫｅｙＢ、ＫｅｙＣで暗号化されている。又、タイトル：Ｏ３、タイトル：Ｏ２のそれぞれのコンテンツは、コンテンツＩＤ：ＣＮＴ１２０１、コンテンツＩＤ：ＣＮＴ１３０１でそれぞれ初回ＤＬが行われており、重複販売（重複買い）時には、コンテンツＩＤ：ＣＮＴ１２０１−１、コンテンツＩＤ：ＣＮＴ１３０１−２で再ＤＬが行われていることを表している。
【００５６】
本実施例では図１１に示すとおり、コンテンツ本体1101と暗号鍵1102とは図10の従来例と同様に一対一に対応するが、コンテンツIDはもとのコンテンツID1103 に加えて重複販売時用のコンテンツID1104を新たに作成し、この新たなコンテンツIDごとにDL情報とメタ情報を作成するようにしている。これにより、複数のコンテンツIDでコンテンツ本体1101と暗号鍵1102を共有し得る構成とし、コンテンツ本体1101と暗号鍵1102の組み合わせを無駄に複製しないでも済むようにしている。
【図面の簡単な説明】
【００５７】
【図１】ネットワーク構成の一実施例。
【図２】センタシステムおよびユーザ端末の一構成例。
【図３】販売受付からDL情報提供までに関わる機能部の一構成例。
【図４】販売管理情報その他の一実施例。
【図５】DL情報の一実施例。
【図６】メタ情報の一実施例。
【図７】DL情報提供場所DBが格納する情報の一実施例。
【図８】センタシステムがユーザからコンテンツの購入要求を受け付けたときの処理フローの一実施例。
【図９】センタシステムをサーバやDBで構成した場合の一実施例。
【図１０】従来のサービスにおける鍵とコンテンツの関係を示す図。
【図１１】本実施例によるサービスにおける鍵とコンテンツの関係を示す図。
【図１２】重複買いをする場合にユーザ端末に表示される画面の一実施例。
【図１３】重複買いをする場合にユーザに認められるコンテンツの実行状況を示す図。
【符号の説明】
【００５８】
101…センタシステム
105、106、107…ユーザ端末
203…販売受付部
205…販売管理部
207…DL情報提供部
209…ライセンス要求受付部
210…DL配信部
302…重複買い判定部
303…重複処理部
304…ローカルコンテンツ処理指示部
305…ワンタイム提供データ作成処理部
306…ワンタイム処理部
400、401…販売情報
409…ワンタイムURL情報
410…鍵情報
509…DL情報（素コンテンツID）
510…DL情報(重複買い用コンテンツID)
610…メタ情報（素コンテンツID）
611…メタ情報(重複買い用コンテンツID)
【技術分野】
【０００１】
本発明は、ユーザからの要求に応じて記憶装置に格納してあるコンテンツをユーザにダウンロードさせる技術に関する。
【背景技術】
【０００２】
ユーザが視聴するコンテンツに関し通信網を介し提供する形態には、大きくストリーミングとダウンロードがあり、記憶装置に格納してあるコンテンツをダウンロードしてそのコンテンツを視聴する公知技術の１つとして特許文献１に記載がある。
【０００３】
航空機において乗客が座席に着席した状態で、音楽や映像などのコンテンツを楽しみたい時に、その要求に遠隔的に応える様にした航空機内エンターテイメントシステム装置が開発・提供されるようになってきている。ＭＰＥＧ１／２等の画像の高能率圧縮技術を用いて、たとえば、５０から２００タイトルの映画コンテンツ等、たくさんのコンテンツの選択視聴が可能になってきている。
【０００４】
従来の航空機内エンターテイメントシステムの構成として特許文献１の図１２において、１２１はプログラムビデオサービスコントロールユニット、１２２はビデオサーバ、１２３は分配・結合器、１２４から１２６は分配器、１２７から１２９はシート端末、１３０から１３２は液晶ディスプレイである。
ビデオサーバ１２２にはＭＰＥＧ２方式等で圧縮された映像信号が記録されている。各シート端末からのリクエストを受信することにより、プログラムビデオサービスコントロールユニット１２１が、ビデオサーバ１２２よりＭＰＥＧ２方式で圧縮されて記録されているデータを読み出し、各シート端末に対しコンテンツの配布を行う。コンテンツは、分配・結合器１２３、分配器１２４、１２５、１２６を経由してコンテンツが配布される。コンテンツは、ＭＰＥＧ２のトランスポートストリーム形式で１６ＱＡＭ等の変調方式で変調を行い、同軸ケーブル等を介して伝送される。
【０００５】
このときプログラムビデオサービスコントロールユニット１２１とシート端末１２７、１２８、１２９の間はＴＣＰ／ＩＰプロトコルにより通信が行われる。このＴＣＰ／ＩＰの信号についても周波数変調がかけられて、コンテンツ配信と同じ同軸ケーブルを通じて通信を行う。このため、分配・結合器１２３は、ＭＰＥＧ２のトランスポートストリームと、ＴＣＰ／ＩＰ信号の信号についての周波数的な多重と、多重分離の機能を持つ、また分配器１２４、１２５、１２６においては、信号の分岐を行い、各シート端末に対し同じ信号の分配を行う。シート端末１２７、１２８、１２９においては圧縮されて伝送されてくる映像音声信号について、ＭＰＥＧ２の圧縮伸張を行い、液晶ディスプレイ１３０、１３１、１３２への表示を行う。
【０００６】
上記のシステムは、一般的にビデオオンデマンドシステム（ＶＯＤシステム）と呼ばれている。特許文献１の航空機内エンターテイメントシステムは、航空機内というクローズしたネットワーク環境で使用され、且つ各シート端末の固定ユーザへのビデオ配信に限定されているため、ユーザ認証や端末認証、配信されるビデオに対するライセンス認証、配信されるビデオの暗号化を考慮してはいない。現在、ケーブルＴＶやディジタルＴＶで実現されているＶＯＤシステムを使用したＶＯＤサービスにおいては、不特定使用者でのオンデマンドなビデオ配信を実現するため、ユーザ認証や端末認証、配信されるビデオに対するライセンス認証、配信されるビデオの暗号化を行うのが一般的である。
【０００７】
ＶＯＤサービスにおいては、ユーザは視聴したいビデオのコンテンツを選択後、リアルタイムにビデオ配信が行われ、ユーザはそれをその場で即座に視聴することになる。しかし、ＶＯＤサービスでビデオを受信している間は、大量のビデオ情報がネットワークに流れることになり、その間は極めてネットワーク負荷を増大させ、又ビデオ情報の伝送には極めてリアルタイム性が要求され、ビデオ情報の伝送の優先順位が高くなっているため、ネットワークを使用した他の情報処理を並行して行おうとすると、他の情報処理の処理速度が遅くなるばかりでなく、他の情報処理を阻害することにもなりえる。
【０００８】
そこで、ユーザが端末からビデオ情報のダウンロードを要求し、ネットワークを使用していない間にビデオ情報を端末にダウンロードし端末に記憶しておき、ユーザが所望するタイミングで記憶したビデオ情報を視聴するサービスが検討されている。これをＤＬサービスと称する。ＤＬサービスにおいては、ビデオ情報は予め端末にダウンロードされ記憶されているため、ユーザの視聴中にはネットワークを使用しないため、ネットワーク負荷を増大させる問題は発生しない。又、一度ダウンロードしたビデオ情報を、そのビデオ情報の視聴可能期間においては、再度何度でも端末上で視聴可能である。これは、レンタルビデオをレンタルビデオ屋から借りてきて、レンタル期間中は何度でも視聴出来ることに似ている。又近年、端末の進歩は甚だしく、固定端末：テレビ、デスクトップＰＣ等、移動端末：携帯電話、ＰＤＡ、モバイルＰＣ等の何れからでも、インターネットに接続して、どの端末からでも同一の情報にアクセス可能である。そこで、ユーザが移動中に、例えば携帯電話で次の日視聴したいビデオをビデオ一覧表から選択し、予め携帯端末からＤＬサービスの要求を行っておき、帰宅後次の日に自宅のＴＶに予めダウンロードされているユーザの所望するビデオを所望するタイミングで視聴することが可能となる。
【０００９】
このようなユーザの利便性は到底ＶＯＤサービスにおいて得られるものではない。つまりＤＬサービスは、モバイル情報化社会において、ユーザの都合に鑑み柔軟に対応可能なユーザにとって利便性の高い情報提供サービスであると言える。勿論ＤＬサービスにおいても、不特定使用者でのビデオのＤＬサービスを実現するためには、ユーザ認証や端末認証、配信されるビデオに対するライセンス認証、配信されるビデオの暗号化を行うのが一般的である。
【００１０】
【特許文献１】特開２００２−３４０５９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
先ず図１０を用いて、従来DLサービスで一般的にセンタシステムがDLサービスの提供と管理を行うための情報：主に鍵とコンテンツの関係を説明する。通常、ユーザの端末にダウンロードされるコンテンツ1003自体は対応する暗号鍵1002で暗号化されている。これはＤＬサービスにおいては、対応する暗号鍵1002で暗号化されたコンテンツ1003がユーザの端末にダウンロードされた後、ユーザが所望するタイミングでダウンロードされたコンテンツ1003を視聴する際、ユーザの端末は対応する暗号鍵1002をセンタシステムから取得し、ユーザの端末上で暗号鍵1002を用いて暗号1002で暗号化されたコンテンツ1003の暗号を解いて視聴を行うためである。暗号鍵1002とコンテンツ1003それぞれに対応して、ＤＬサービスの提供と管理を行う素コンテンツ識別情報1001を有している。
【００１２】
素コンテンツ識別情報1001は、販売情報としてコンテンツ名（コンテンツ自体のタイトル、例えば図１０においてはＭＨ，Ｏ３，Ｏ２）、暗号鍵（例えば、図１０においてはＫｅｙＡ、ＫｅｙＢ、ＫｅｙＣ）、ライセンス条件（例えばエキスポート可／不可、１８歳未満視聴禁／１５歳未満視聴禁）、ユーザＩＤ、販売日、視聴期間等、コンテンツや暗号鍵のＤＬを実際に実行するためのＤＬ情報としてＤＬコンテンツ提供場所、ライセンス（暗号鍵）提供場所、メタ情報（コンテンツ自体に付随する言語、ジャンル、番宣、タイトルの簡単な紹介や出演者等）提供場所等、メタ情報としてコンテンツ自体に付随する言語、ジャンル、番宣、タイトルの簡単な紹介や出演者等、の情報を含むと共に、それらの情報には１個の識別子：コンテンツＩＤ（図１０においては、ＣＮＴ１２３４，ＣＮＴ１２０１，ＣＮＴ１３０１）が付与されている。ＤＬサービスの提供と管理においては、このコンテンツＩＤを識別子に用いている。
【００１３】
以上のように、従来のＤＬサービスでは、コンテンツＩＤでユーザＩＤと販売日、視聴期間等が一体で、素コンテンツ識別情報1001として管理されているため、あるユーザがあるコンテンツについて、ＤＬサービスを利用している間（視聴期間中）は、再度ダウンロードを行うことは出来ない。つまり、ユーザが過去にダウンロードして現在も有効なコンテンツを保有している場合、あらたにそのコンテンツを購入しようとしても、このコンテンツの購入に必要となる素コンテンツ情報や、コンテンツの視聴に必要となる暗号鍵1002について何ら考慮されていない。
【００１４】
ここで図１３を用いて、ＤＬサービスのサービスイメージと、重複買いシチュエーションの重要性、必要性について説明する。図１３の（ａ）は重複買いできないＤＬサービスの場合の例を表している。この場合、ユーザは初回ＤＬとして１１／１９の夜に最初のＤＬサービスの要求を行っている。ここでは、例としてタイトル：ＭＨについて２泊３日でＤＬサービスの要求を行い、1301は、実際にコンテンツのダウンロードが行われ、その後ユーザが視聴可能な期間を表しており、１１／２１中までならダウンロードされたコンテンツをユーザは視聴可能である。通常、コンテンツの容量というのは２〜３時間の映画を想定した場合、ネットワークのトラフィックにもよるがダウンロードにも同等程度の時間を必要としたりなどする。それ故コンテンツのダウンロードはユーザが端末を使用していないトラフィックも低い深夜の時間帯に行なうなど端末の商品企画によっては十分考えられることである。また、これも端末の商品企画次第であるが、端末によっては、或いはベーシックな端末仕様としては、ダウンロードが完了してから再生できる動作となる為、こういったベーシックな端末を所持するユーザにとっては、ダウンロードを完了してから視聴可能となるなどする。端末によっては、プログレッシブダウンロード（プログレッシブダウンロードとは、コンテンツをダウンロードしながら再生視聴できることを意味する）の機構を具備した端末も考えられるが、市場に投入される端末が全てそういった高機能端末であるとは限らない。
【００１５】
図１３でユーザは、突然の遠隔出張になり、出張から帰宅するのは１１／２２以降であるとする。この場合ユーザは、1301で折角ダウンロードしたコンテンツを視聴出来ないことになる。又１１／２２になって帰宅し、直ぐに再度ＤＬサービスの要求を行ったとしても、上述の如くダウンロードを行うのに時間を要することも考えられる為、直ぐには視聴出来ないという問題が発生し得る。1302は、１１／２２になって帰宅し、直ぐに再度タイトル：ＭＨについて当日限りが有効期限のＤＬサービスの要求を行った後、実際にコンテンツのダウンロードが行われて、視聴可能な期間を表している。
【００１６】
それに対して、図１３の（ｂ）はユーザに重複買いを許容する場合のＤＬサービスの例を表している。この場合、１１／２０に遠隔出張が決定したタイミングで、再ＤＬとして１１／２０に再度のＤＬサービスの要求を行っている。ここでは、例としてタイトル：ＭＨについて２泊３日で再度ＤＬサービスの要求を行い、1303は、実際にコンテンツのダウンロードが行われ、その後ユーザが視聴可能な期間を表しており、１１／２２中までならダウンロードされたコンテンツをユーザは視聴可能である。このように、既にＤＬサービスの要求を行ったコンテンツについて視聴可能な期間内にユーザが視聴出来ないことが決定したタイミングで、再ＤＬを実行可能な機会を提供することは、ユーザの視聴機会を高めると共に、ＤＬサービスにおけるダウンロード待ちの煩わしさを軽減すると共に、ユーザの都合に鑑み柔軟に対応可能なユーザにとって利便性の高いＤＬサービスが提供可能となる。
【００１７】
又、別の例についても説明する。子供が貸出日同日内返却（当日レンタル）でコンテンツをダウンロードしたが、急に、親戚が入院し今から家族全員外出する事が判明した。帰宅後、直ぐに視聴出来るよう、病院に行く前に、３泊４日で再ＤＬしたいが重複買いができない場合はこのような要求に対応出来ない。ゆえ、当日レンタルが期限切れになり、帰宅後でしか、再ＤＬを行うことが出来ない。明日まで待つしかないということになるわけである。しかし、重複買いできるＤＬサービスの場合には、病院に行く前に、３泊４日で再ＤＬを行い、帰宅後既にダウンロードされているコンテンツを直ぐに視聴可能となるわけである。この例で言えることは、ＴＶの場合１人１台という概念は一般的に無く、家族皆で利用するのが通常のような場合、家族の誰かが購入していることを知らずに、別の人が同一のコンテンツを購入する場合も考えられる。そこで、本当に必要性に迫られて重複買いするのか、誤って重複買いするのかは、ユーザが正規に判断し、必要とするユーザへ重複買いの機会を提供することが必要である。上記のように重複買いできるＤＬサービスを提供する場合、本当に必要で重複買いするのか、誤って重複買いを行っているかの判別をユーザに支援しなければいけないという課題も重要である。
【課題を解決するための手段】
【００１８】
上記課題を解決するために本発明では、ユーザからのコンテンツダウンロード要求を受けたセンタシステムが、当該ユーザが視聴可能な同じコンテンツを既にダウンロードしているか否かを判断し、そのようなコンテンツを既にダウンロードしている場合は、そのコンテンツのコンテンツID、DL情報、メタ情報を重複買い用の情報としてそれぞれ新たに作成し、ユーザに視聴可能な同じコンテンツの重複買いを可能とする機能・手段を備える。
【発明の効果】
【００１９】
上記のように、重複買いできるＤＬサービスにより、ユーザの視聴機会を高めると共に、ＤＬサービスにおけるダウンロード待ちの煩わしさを軽減すると共に、ユーザの都合に鑑み柔軟に対応可能なユーザにとって利便性の高いＤＬサービスが提供可能となる。
【発明を実施するための最良の形態】
【００２０】
以下、図面を用いて本件発明の実施例の一つを説明する。図１は、本発明におけるネットワーク構成の一実施例を示したものである。例えばPCやテレビ、PDA等のユーザ端末
105、106、107が、例えばインターネット等の通信網104を介して、コンテンツの配信を制御するセンタシステム101に接続されている。センタシステム101は通信網104を介してユーザ端末105等からコンテンツの配信要求を受信し、配信が可能と判断した場合には通信網104を介してユーザ端末105等にコンテンツをダウンロードする。センタシステム101は、その機能や要求される処理能力に応じて、複数のサブシステム102、103に分けて適宜構成して良く、必ずしも一台の装置で実装される必要は無い。また、サブシステム102や103は地理的に離れた、異なるネットワーク上に存在させても良い。
【００２１】
図２は、図１においてセンタシステム101とユーザ端末105を例示し、両者が有する機能部の一実施例について説明する図である。ユーザ端末105は、ユーザの操作を受けてセンタシステム101に情報を送信し、またはセンタシステム101から受信した情報を処理して、必要に応じてユーザに伝える処理を行なう端末処理部201と、センタシステム101との間で送受信する情報を格納する記憶部202を有する。
【００２２】
センタシステム101は、ユーザからコンテンツのダウンロード要求を受け付ける販売受付部203と、ユーザがどのようなコンテンツのダウンロードをしているのかを管理する販売管理部205と、ユーザがコンテンツをダウンロードするために必要な情報であるダウンロード情報を作成し、ユーザに提供するＤＬ情報提供部207と、ユーザがＤＬ情報提供部207から取得したダウンロード情報を用いてコンテンツ本体をダウンロードする場合に、ユーザにコンテンツ本体を配信する処理を行なうＤＬ配信部210とを有する。また、センタシステム101は、コンテンツごとにそのダウンロード情報を提供する場所、例えばＵＲＬ等を格納する記憶部204と、ユーザごとのコンテンツ販売情報やコンテンツの再生に必要な鍵情報、ユーザがコンテンツを重複して買う場合にそのコンテンツのダウンロード情報を提供する場所である、一時的に使用されるＵＲＬ等を格納する記憶部206と、コンテンツのメタ情報やＤＬ情報を格納する記憶部208と、コンテンツ本体を格納する記憶部211とを有する。
【００２３】
図３はセンタシステム101の中で、販売受付部203、販売管理部205、ＤＬ情報提供部207についてさらに詳細な実施例を説明するための図である。以下、図2と図3を参照しながら、ユーザ端末105がコンテンツをダウンロードする一連の処理について説明する。
【００２４】
センタシステム101はユーザ端末105にコンテンツの一覧等を提供し、ユーザはユーザ端末105の表示画面に表示されるコンテンツの中から所望のコンテンツを選択する。ユーザが表示画面上のコンテンツをクリックする等の購入操作を実行すると、ユーザ端末105の端末処理部201は、センタシステム101に対し、コンテンツの購入を要求するメッセージを送信する。
【００２５】
センタシステム101の販売受付部203は、ユーザ端末105からコンテンツの購入を要求するメッセージを受信すると、販売受付処理部301により、ユーザが要求しているコンテンツを識別するための情報であるコンテンツIDと、ユーザ情報、さらにはユーザが希望するそのコンテンツの期限情報を特定する。この実施例では、コンテンツIDは例えば「１２３４」であり、ユーザIDは例えば「１１０１」であり、期限情報は２泊３日であるとする。販売受付処理部部301は、コンテンツID「１２３４」を販売管理部205に送信し、販売管理部205の重複買い判定部302は、このユーザがコンテンツID「１２３４」で特定されるコンテンツを、現在時点で正規に視聴可能な権利を有しているか否か、記憶部206の販売情報を参照して調べる。このように販売管理部205は、このユーザが、既にダウンロードしている実行可能なコンテンツを持っているにもかかわらず、同じ内容のコンテンツを重複して購入しようとしているのかを判定する。
【００２６】
記憶部206に格納される情報の一実施例を図4に示す。図4の実施例で記憶部206には、ユーザごとの販売情報400、401と、鍵情報410と、ワンタイムURL409とが格納されている。販売情報については、ユーザID1101のユーザ用に販売情報400のテーブルを、ユーザID1102のユーザ用に販売情報401のテーブルをそれぞれ用意している。各テーブルには、コンテンツを識別するためのコンテンツID402と、コンテンツを販売した日付である販売日403と、そのコンテンツの視聴可能な期間を表す視聴期間404と、現在の日付がコンテンツの販売日から視聴期間内にあるかどうか等の条件により、そのコンテンツのレコードが有効か否かを示すレコード有効／無効フラグ406と、そのコンテンツをダウンロードするために必要な情報を入手できる場所を指定する、ＵＲＬ等の場所情報406と、その他の情報407のカラムを有する。なお、本実施例では場所情報としてURLを例示しているが、URL以外のIPアドレス等のアドレス情報や、その他ネットワーク上のロケーションを特定できる情報を場所情報として用いることができる。
【００２７】
図4で、コンテンツID「１２０１」と「１２０１−１」は、重複買いが発生していることを表す。コンテンツID「１２０１」の提供場所情報406が「標準」となっているのは、もともとコンテンツＩＤ「１２０１」のコンテンツのために用意されている提供場所を使用できるからである。一方、コンテンツＩＤ「１２０１−１」の提供場所情報406が「URL：abc」となっているのは、重複買いを可能とするために、後述するＤＬ情報提供部207が重複買い用の提供場所を一時的に作成しているためである。
【００２８】
重複買い判定部302は、販売情報テーブル400にコンテンツID「１２３４」が既に登録されており、しかも視聴期間内でエントリが有効であるため、ユーザが同じコンテンツを重複買いしようとしていると判断する。この場合、重複処理部303は、新たなコンテンツID「１２３４−１」を作成し、さらにこの新たなコンテンツIDを用いてコンテンツをダウンロードするために用いるワンタイムURLを作成し、販売情報テーブル400にコンテンツID「１２３４−１」と作成したワンタイムURLを提供場所情報406として登録する。
【００２９】
コンテンツID「１２３４」と「１２３４−１」はともに、同じコンテンツを指し示す識別情報であるが、ダウンロードの過程が異なるために、同じコンテンツでありながらも異なる識別子を与えている。そして本実施例では、DL情報やメタ情報を、同じコンテンツを指すコンテンツID「１２３４」と「１２３４−１」それぞれに作成している点が特徴である。
【００３０】
そしてローカルコンテンツ処理指示部304は、DL情報提供部207のワンタイム提供データ作成処理部305に対して、コンテンツID「１２３４−１」とワンタイムURL、さらには素コンテンツID「１２３４」とコンテンツの提供期限を通知し、これらIDとURLを用いてユーザにコンテンツをダウンロードさせるためのDL情報ならびにメタ情報の作成を指示する。なお、ユーザは必ずしもメタ情報の入手を要求するとは限らないため、メタ情報の作成は本実施例では必須ではなく、省略しても良い。
【００３１】
DL情報とは、コンテンツをコンテンツID「１２３４−１」で特定してダウンロードするために必要な情報、例えばメタ情報の提供場所であるURL等や、コンテンツそのものをダウンロードするURL等の場所、さらにはダウンロードしたコンテンツを実行するためのライセンスの提供場所等を含む。このDL情報は、例えばRFC4287に記載されているタグ言語を利用しても良い。
【００３２】
また、メタ情報とはコンテンツID「１２３４−１」により特定されダウンロードされるコンテンツの属性を示す情報であり、例えばコンテンツが映画であればそのジャンルや言語等の情報を含み、さらにどのユーザに対してどれだけの有効期間でダウンロードされるのかといった情報や、ユーザの利用ライセンス（例えば視聴権利など）に関わる条件といった情報も含む。このメタ情報は、例えばARIB(Association of Radio Industries and Businesses) STD-B38で書き方のきまりが規格化されている、記述言語型メタデータの元となるデータ群である。ワンタイム提供データ作成処理部305は、作成したDL情報やメタ情報を記憶部208に格納する。
【００３３】
DL情報の一実施例を図5に示す。DL情報509は、重複買いでは無い、素のコンテンツIDでコンテンツを特定した場合のDL情報であり、DL情報510は重複買いのため素コンテンツIDを基に新たに作成されたコンテンツIDによりコンテンツを特定した場合のDL情報である。DL情報510は、ＤＬ情報を取得できる場所を示すＤＬ情報提供場所501と、コンテンツＩＤ502と、例えば映画の題名等のコンテンツタイトル503と、重複買い用のコンテンツＩＤでダウンロードする場合にメタ情報を取得できる場所を示すメタ情報提供場所504と、コンテンツ本体をダウンロードするための場所であるＤＬコンテンツ提供場所505と、そのコンテンツを実行するためのライセンスを取得するための場所であるライセンス提供場所506と、重複買いしたコンテンツの有効期限を示す取扱い期限507と、その他の情報508とを有する。
【００３４】
DL情報509とDL情報510を比較した場合に、もとのコンテンツＩＤと重複買い用のコンテンツＩＤとでは、ＤＬ情報提供場所501とメタ情報提供場所504が異なり、ＤＬコンテンツ提供場所505とライセンス提供場所506が同じである点が特徴である。つまり、ＤＬ情報提供場所501やメタ情報提供場所504をコンテンツＩＤごとに用意することで、コンテンツを取得する上で必要なデータだけを複数用意し、ＤＬコンテンツ提供場所505を同じにすることでコンテンツ本体は1つで足り、またライセンス提供場所506を同じとすることでコンテンツ再生用の鍵も1つで済むようにしている。
【００３５】
メタ情報の一実施例を図6に示す。図6中、メタ情報610は重複買いの対象ではない、もとのコンテンツＩＤで特定されるコンテンツに付随する情報を格納したテーブルであり、メタ情報611は、重複買いの対象である、重複処理部303により作成されたコンテンツＩＤにより特定されるコンテンツに付随する情報を格納したテーブルである。メタ情報611には、メタ情報を取得できるURL等の場書情報を表すメタ情報提供場所601と、コンテンツID602と、コンテンツタイトル603と、DLコンテンツ提供場所604と、ライセンス提供場所605と、そのコンテンツで使用される言語606と、そのコンテンツのジャンル607と、宣伝情報である番宣608と、その他ユーザに提供される情報609とが格納されている。
【００３６】
メタ情報610とメタ情報611の両テーブルを比較した場合に、もとのコンテンツＩＤと重複買い用のコンテンツＩＤとでは、メタ情報提供場所601が異なり、ＤＬコンテンツ提供場所505とライセンス提供場所506が同じである。
【００３７】
ローカルコンテンツ処理指示部304は、販売受付部203のワンタイム処理部306に、ユーザの重複買いを受け付けることを伝えるACKと、コンテンツID「１２３４−１」のために作成したワンタイムURLを通知する。ワンタイム処理部306はこのワンタイムURLをDL情報提供場所データとして、記憶部204に格納する。DL情報提供場所データの一実施例を図7に示す。この実施例のとおり、DL情報提供場所データ７00は、少なくともコンテンツIDとDL情報提供場所とを対応付けた情報である。
【００３８】
そして販売受付処理部301は、ユーザに対し、コンテンツの購入を受け付けた旨を伝えるメッセージと、そのコンテンツをダウンロードするためにアクセスする必要があるワンタイムURLを送信する。この後、ユーザ端末105の表示画面にはワンタイムURLが表示される等し、ユーザがワンタイムURLをクリックする、もしくはユーザ端末105が自動的にワンタイムURLにアクセスする等すると、端末処理部201はセンタシステム101に対しDL情報を要求するメッセージを送信する。
【００３９】
なお、センタシステム101は、ユーザ端末105に対し、このユーザが視聴可能なコンテンツを重複して購入しようとしていることを知らせるメッセージや、さらには、それでも購入するのか意思を確認するメッセージを送信しても良い。このメッセージに対しユーザがそれでも重複買いをする旨の意思表示をセンタシステム101に返信した場合に、センタシステム101はユーザ端末105に購入を受け付けた旨とワンタイムURLを送信するようにしても良い。この場合は、意図せずに間違って同じコンテンツを購入しようとしているユーザに注意を促すことができる。
【００４０】
DL情報提供部207のDL情報提供処理部307は、このメッセージを受信すると、記憶部208を参照してコンテンツID「１２３４−１」でコンテンツを特定する場合のDL情報を取得し、ユーザ端末105に返信する。DL情報とは、コンテンツをコンテンツID「１２３４−１」で特定してダウンロードするために必要な情報、例えばメタ情報の提供場所であるURL等や、コンテンツの本体そのものをダウンロードするURL等の場所、さらにはダウンロードしたコンテンツを実行するためのライセンスの提供場所等を含む。ユーザ端末105は、受信したDL情報を入手DL情報212として記憶部202に保存する。
【００４１】
次にユーザ端末105は、受信したDL情報212に含まれるコンテンツID「１２３４−１」を用いて、同じくDL情報212に含まれるメタ情報の提供場所に対し、メタ情報を要求する。DL情報提供部207のDL情報提供処理部307はメタ情報の要求を受けて、記憶部208を参照し、ユーザがアクセスしたメタ情報の提供場所に対応するメタ情報を取得して、これをユーザ端末105に返信する。つまり、DL情報提供処理部307は、図6のテーブルGを参照し、ユーザが用いたメタ情報の提供場所に対応するエントリのメタ情報をユーザに提供する。
【００４２】
ユーザ端末処理部201は、提供されたメタ情報を入手メタ情報213として記憶部202に保存する。なお、このメタ情報の取得はコンテンツをダウンロードするにあたりユーザ端末105にとって必須の処理ではないため、省略しても良い。
【００４３】
次にユーザ端末105は、入手DL情報212もしくは入手メタ情報213に含まれるDLコンテンツ提供場所情報を用いて、コンテンツ本体のダウンロードを要求する。センタシステム101のDL配信部210は、この要求に用いられているURL等の場所情報に対応するコンテンツを記憶部211から取得し、ユーザ端末105にダウンロードさせる。ユーザ端末105は、ダウンロードしたコンテンツ本体を、DLコンテンツ本体214として記憶部202に格納する。ここで、コンテンツ本体のダウンロードを要求する、DLコンテンツ提供場所情報は、同じコンテンツについては同じ場所情報となる。つまり、コンテンツID「１２３４」と「１２３４−１」とは同じコンテンツを指すものであるため、DLコンテンツ提供場所情報も同じURL等の情報となる。これにより、重複してコンテンツを買う場合であっても、そのためにコンテンツ本体と暗号鍵の組み合わせをあらかじめ複数用意しておく必要がなくなる。
【００４４】
最後にユーザ端末105は、入手DL情報212もしくは入手メタ情報213に含まれるライセンス提供場所情報を用いて、コンテンツを実行するためのライセンスを要求する。センタシステム101のライセンス要求受付部209は、この要求に用いられているコンテンツ識別しに対応するコンテンツのライセンスの取得を販売管理部205に問い合わせる。販売管理部205の販売レコード照合処理部308は、記憶部206に格納されている当該ユーザの販売情報を参照して、そのユーザにライセンスを与えられるか否かを判断する。この判断は例えば、レコードが有効であるかどうかや、そのユーザに許された実行回数を超えていない等の条件によりなされる。
【００４５】
販売レコード照合処理部308がライセンス可能と判断した場合には、販売レコード照合処理部308は、ライセンス要求に含まれるコンテンツID「１２３４−１」をコンテンツID変換処理部309に送信する。コンテンツID変換処理部309はこのコンテンツID「１２３４−１」をもとのコンテンツID「１２３４」に変換し、記憶部２０６に格納された、図４のテーブルAに示される鍵情報を参照し、コンテンツID「１２３４」に対応する暗号鍵「Key A」を取得し、これを販売レコード照合処理部308に渡す。販売レコード照合処理部308は、ライセンス要求受付部209に暗号鍵を送信する。暗号鍵を受信したライセンス要求受付部209は、その暗号鍵をユーザ端末105に送信し、ユーザ端末105はそれを入手ライセンス215として記憶部202に格納する。
【００４６】
ここで、ライセンス提供場所情報もDLコンテンツ提供場所情報と同様に、同じコンテンツについては同じ場所となるため、コンテンツID「１２３４」と「１２３４−１」とでは同じURL等の場所情報となる。これにより、重複してコンテンツを買う場合であっても、そのために1つのコンテンツに対して複数の暗号鍵を用意しておく必要がなくなる。
【００４７】
ここまでの操作を終えたユーザ端末は、取得したコンテンツを暗号鍵を用いて実行し、例えば動画を再生するなどして利用することができる。
【００４８】
図8は、ユーザ端末105からコンテンツの販売要求を受けたときの処理フローの一実施例である。まず、重複買い判定部302は、販売要求に含まれるユーザ情報やコンテンツIDを用いて記憶部206の当該ユーザの販売情報を参照し(801)、そのユーザについて、そのコンテンツIDで特定される視聴可能なコンテンツの販売レコードが記憶されているかどうかを確認する(802)。販売レコードが無い場合は重複買いではないため、販売管理部205の通常処理部310により記憶部206に新たな販売レコードを作製し(803)、通常処理指示部311を介して販売受付機能部203の通常処理部312に重複買いではない通常のコンテンツ販売処理のメニューをユーザ端末105に送信するよう指示する（804）。
【００４９】
重複買いである場合は、重複処理部303が、重複買い用の新たなコンテンツIDを販売コンテンツID402として、また生成したDL情報の提供場所をワンタイム情報場所情報406として、記憶部206の新たな販売レコードに格納する(805)。ローカルコンテンツ処理指示部304はワンタイム提供データ作成処理部305にDL情報とメタ情報の作成を指示して、ワンタイム提供データ作成処理部305はそれらデータを作成の後、記憶部208に格納する(806)。そしてローカルコンテンツ処理指示部304は、生成したワンタイム提供場所情報を販売受付処理部301に通知し(807)、ここからさらにユーザ端末にワンタイム提供場所情報が展開される。
【００５０】
図９は、図２のセンタシステムの機能部をサーバ装置により実現した場合の一構成例である。図９では、販売受付部203がDLサービスポータル901とポータルアプリケーションサーバ902により実現され、記憶部204がDL情報提供場所DB903で実現されている。また、販売管理部205が顧客・販売管理サーバ904で、記憶部206が販売レコード等DB905でそれぞれ実現されている。DL情報提供部207はDL情報提供アプリケーションサーバ906とDL情報提供Web907により、記憶部208はDL情報提供DB908によりそれぞれ実現されている。ライセンス要求受付部209はライセンス要求受付Web909により実現され、DL配信部210はDL配信サーバ910とコンテンツ管理サーバ911により実現される。また記憶部211はDLコンテンツDBにより実現されている。これはあくまでも一構成例であり、図２の機能部は任意のサーバやコンピュータ等の情報処理装置により、適宜自由に機能を分割、または組み合わせて構成して良い。例えば図2や図3の機能部をそれぞれ別の装置として実現しても良いし、将来コンピュータの処理能力が向上すれば、センタシステム101を一台の装置で実現する場合もあるかもしれない。
【００５１】
図１２は、重複買いをした場合の、ユーザ端末105の表示画面の一例である。画面1201には、タイトル1204が同じO3のコンテンツにつき、購入した情報1202と1203とが表示されている。ユーザは、同じコンテンツについて最初に購入した情報1203と、それに重複して購入した情報1202のうち、好きな方を選択してコンテンツを実行することが可能となる。
【００５２】
従来のＤＬサービスは、[発明が解決しようとする課題]の図１０で説明したように、コンテンツＩＤでユーザＩＤと販売日、視聴期間等が一体で、素コンテンツ識別情報1001として管理されており、あるユーザがあるコンテンツについて、ＤＬサービスを利用している間（視聴期間中）は、同一コンテンツについて再度ダウンロードを行うことは出来ないものであった。
【００５３】
重複買いできるＤＬサービスを比較的単純に提供する方法としては、重複買いを予め考慮し、同一コンテンツに対し、暗号鍵を複数用意しておき、予め、コンテンツに対し該暗号鍵で暗号化を施し、暗号鍵の数分Ｎのコンテンツ本体（暗号化済み）をコンテンツ管理サーバなどで、管理しておく。それにより用意した複数の重複買いが可能となる。しかし、この方法では、
（１）同一コンテンツに対し複数の暗号鍵で複数回暗号化を行うためコンテンツを準備する際の受入れ作業が大幅にアップし作業効率が悪い、
（２）全コンテンツを複数鍵分、事前に用意する必要がある為、センタで管理するべきコンテンツの容量が×Nで膨張する、
（３）センタ管理容量が増大する為、消費電力も高く、環境面でマイナスである、
という重要な問題が発生する。
【００５４】
本実施例による重複買いできるＤＬサービスにおけるセンタシステム101がDLサービスの提供と管理を行うための情報：主に鍵とコンテンツの関係を、図１１を用いて説明する。本実施例においては、ユーザの端末にダウンロードされるコンテンツ1101自体は対応する暗号鍵1102で暗号化されており、1101と1102のその対応は一体一である。先ず、あるユーザに対して初回ＤＬの際にはデフォルトの素コンテンツ識別情報1103を用いて、ＤＬサービスの提供を行う。次に重複販売（重複買い）の再ＤＬの場合には、ローカルコンテンツ識別情報1104を用いて、ＤＬサービスの提供を行う。これにより、コンテンツ1101と暗号鍵1102の一対に対して、再ＤＬが可能となる。又再度同一コンテンツについて、再ＤＬの要求があった場合は、3つめのローカルコンテンツ識別情報1104を作成し用いて、再ＤＬを可能とすることが出来る。
【００５５】
ローカルコンテンツ識別情報1104の識別子：コンテンツＩＤは、素コンテンツ識別情報1103の識別子：コンテンツＩＤとは別に付与することにより、そのＤＬサービスで使用しているコンテンツ識別情報を識別することが可能となり、ＤＬサービス中の端末とセンタの通信においては、素コンテンツ識別情報1103：コンテンツＩＤとローカルコンテンツ識別情報1104の識別子：コンテンツＩＤとをユニークに設定し使用することにより、重複買いできるＤＬサービスのための通信が可能となる。図１１の例においては、タイトル：Ｏ３、タイトル：Ｏ２のそれぞれのコンテンツは対応する暗号鍵ＫｅｙＢ、ＫｅｙＣで暗号化されている。又、タイトル：Ｏ３、タイトル：Ｏ２のそれぞれのコンテンツは、コンテンツＩＤ：ＣＮＴ１２０１、コンテンツＩＤ：ＣＮＴ１３０１でそれぞれ初回ＤＬが行われており、重複販売（重複買い）時には、コンテンツＩＤ：ＣＮＴ１２０１−１、コンテンツＩＤ：ＣＮＴ１３０１−２で再ＤＬが行われていることを表している。
【００５６】
本実施例では図１１に示すとおり、コンテンツ本体1101と暗号鍵1102とは図10の従来例と同様に一対一に対応するが、コンテンツIDはもとのコンテンツID1103 に加えて重複販売時用のコンテンツID1104を新たに作成し、この新たなコンテンツIDごとにDL情報とメタ情報を作成するようにしている。これにより、複数のコンテンツIDでコンテンツ本体1101と暗号鍵1102を共有し得る構成とし、コンテンツ本体1101と暗号鍵1102の組み合わせを無駄に複製しないでも済むようにしている。
【図面の簡単な説明】
【００５７】
【図１】ネットワーク構成の一実施例。
【図２】センタシステムおよびユーザ端末の一構成例。
【図３】販売受付からDL情報提供までに関わる機能部の一構成例。
【図４】販売管理情報その他の一実施例。
【図５】DL情報の一実施例。
【図６】メタ情報の一実施例。
【図７】DL情報提供場所DBが格納する情報の一実施例。
【図８】センタシステムがユーザからコンテンツの購入要求を受け付けたときの処理フローの一実施例。
【図９】センタシステムをサーバやDBで構成した場合の一実施例。
【図１０】従来のサービスにおける鍵とコンテンツの関係を示す図。
【図１１】本実施例によるサービスにおける鍵とコンテンツの関係を示す図。
【図１２】重複買いをする場合にユーザ端末に表示される画面の一実施例。
【図１３】重複買いをする場合にユーザに認められるコンテンツの実行状況を示す図。
【符号の説明】
【００５８】
101…センタシステム
105、106、107…ユーザ端末
203…販売受付部
205…販売管理部
207…DL情報提供部
209…ライセンス要求受付部
210…DL配信部
302…重複買い判定部
303…重複処理部
304…ローカルコンテンツ処理指示部
305…ワンタイム提供データ作成処理部
306…ワンタイム処理部
400、401…販売情報
409…ワンタイムURL情報
410…鍵情報
509…DL情報（素コンテンツID）
510…DL情報(重複買い用コンテンツID)
610…メタ情報（素コンテンツID）
611…メタ情報(重複買い用コンテンツID)
【特許請求の範囲】
【請求項１】
ユーザからの要求に応じて、当該ユーザの指定するコンテンツをユーザにダウンロードさせるコンテンツ管理システムにおいて、
前記ユーザから、第１のコンテンツIDによりコンテンツを指定したコンテンツ購入要求を受信する販売受付部と、
前記ユーザの購入要求対象であるコンテンツが、前記ユーザにより既に購入されており、かつ、前記ユーザが実行可能なコンテンツであるか否かを判断し、前記ユーザに実行可能なコンテンツである場合には、第２のコンテンツIDと、前記コンテンツを当該第２のコンテンツIDにより指定してダウンロードするために前記ユーザがアクセスすべき場所であるワンタイムURLを作成する販売管理部とを有し、
前記販売受付部は、前記販売管理部から受信した前記第２のコンテンツIDと前記ワンタイムURLを前記ユーザ端末に送信することを特徴とするコンテンツ管理システム。
【請求項２】
請求項１に記載のコンテンツ管理システムにおいて、
前記販売管理部から前記第２のコンテンツIDとワンタイムURLを受信し、前記第２のコンテンツIDに対応する、前記コンテンツをダウンロードするために必要なダウンロード情報を作成するダウンロード情報提供部とを有し、
前記ダウンロード情報提供部は、前記ワンタイムURLを用いて前記ユーザがアクセスした場合に、前記ユーザに前記ダウンロード情報を提供することを特徴とするコンテンツ管理システム。
【請求項３】
請求項２に記載のコンテンツ管理システムにおいて、
前記ダウンロード情報には、前記コンテンツをダウンロードするために前記ユーザがアクセスすべきコンテンツ提供場所情報が含まれ、
前記コンテンツ提供場所情報を用いて前記ユーザがアクセスした場合に、前記ユーザにコンテンツを配信する配信部を有することを特徴とするコンテンツ管理システム。
【請求項４】
請求項２に記載のコンテンツ管理システムにおいて、
前記ダウンロード情報には、前記コンテンツを実行するためのライセンスを得るためにユーザがアクセスすべきライセンス提供場所情報が含まれ、
前記ライセンス提供場所情報を用いて前記ユーザがアクセスした場合に、前記ユーザにライセンスを提供するライセンス要求受付部を有することを特徴とするコンテンツ管理システム。
【請求項５】
請求項２に記載のコンテンツ管理システムにおいて、
前記販売管理部は、前記第２のコンテンツIDに対応する、前記コンテンツに付随するメタ情報も作成し、
前記ダウンロード情報には、前記メタ情報を取得するために前記ユーザがアクセスすべきメタ情報提供場所情報が含まれ、
前記ダウンロード情報提供部は、前記メタ情報提供場所情報を用いて前記ユーザがアクセスした場合に、前記ユーザに前記メタ情報を提供することを特徴とするコンテンツ管理システム。
【請求項６】
請求項１に記載のコンテンツ管理システムにおいて、
前記ユーザが購入したコンテンツのコンテンツIDと、当該コンテンツが実行可能か否かを表す情報とを含む販売情報を保持する記憶部を有し、
前記販売管理部は、前記記憶部の前記販売情報を参照して、前記コンテンツに前記第２のコンテンツIDと前記ワンタイムURLを作成するか否か判断することを特徴とするコンテンツ管理システム。
【請求項７】
請求項１に記載のコンテンツ管理システムにおいて、
前記第２のコンテンツIDと前記ワインタイムURLを送信する前に、前記ユーザに対し、同じコンテンツを重複して買おうとしていることを通知することを特徴とするコンテンツ管理システム。
【請求項１】
ユーザからの要求に応じて、当該ユーザの指定するコンテンツをユーザにダウンロードさせるコンテンツ管理システムにおいて、
前記ユーザから、第１のコンテンツIDによりコンテンツを指定したコンテンツ購入要求を受信する販売受付部と、
前記ユーザの購入要求対象であるコンテンツが、前記ユーザにより既に購入されており、かつ、前記ユーザが実行可能なコンテンツであるか否かを判断し、前記ユーザに実行可能なコンテンツである場合には、第２のコンテンツIDと、前記コンテンツを当該第２のコンテンツIDにより指定してダウンロードするために前記ユーザがアクセスすべき場所であるワンタイムURLを作成する販売管理部とを有し、
前記販売受付部は、前記販売管理部から受信した前記第２のコンテンツIDと前記ワンタイムURLを前記ユーザ端末に送信することを特徴とするコンテンツ管理システム。
【請求項２】
請求項１に記載のコンテンツ管理システムにおいて、
前記販売管理部から前記第２のコンテンツIDとワンタイムURLを受信し、前記第２のコンテンツIDに対応する、前記コンテンツをダウンロードするために必要なダウンロード情報を作成するダウンロード情報提供部とを有し、
前記ダウンロード情報提供部は、前記ワンタイムURLを用いて前記ユーザがアクセスした場合に、前記ユーザに前記ダウンロード情報を提供することを特徴とするコンテンツ管理システム。
【請求項３】
請求項２に記載のコンテンツ管理システムにおいて、
前記ダウンロード情報には、前記コンテンツをダウンロードするために前記ユーザがアクセスすべきコンテンツ提供場所情報が含まれ、
前記コンテンツ提供場所情報を用いて前記ユーザがアクセスした場合に、前記ユーザにコンテンツを配信する配信部を有することを特徴とするコンテンツ管理システム。
【請求項４】
請求項２に記載のコンテンツ管理システムにおいて、
前記ダウンロード情報には、前記コンテンツを実行するためのライセンスを得るためにユーザがアクセスすべきライセンス提供場所情報が含まれ、
前記ライセンス提供場所情報を用いて前記ユーザがアクセスした場合に、前記ユーザにライセンスを提供するライセンス要求受付部を有することを特徴とするコンテンツ管理システム。
【請求項５】
請求項２に記載のコンテンツ管理システムにおいて、
前記販売管理部は、前記第２のコンテンツIDに対応する、前記コンテンツに付随するメタ情報も作成し、
前記ダウンロード情報には、前記メタ情報を取得するために前記ユーザがアクセスすべきメタ情報提供場所情報が含まれ、
前記ダウンロード情報提供部は、前記メタ情報提供場所情報を用いて前記ユーザがアクセスした場合に、前記ユーザに前記メタ情報を提供することを特徴とするコンテンツ管理システム。
【請求項６】
請求項１に記載のコンテンツ管理システムにおいて、
前記ユーザが購入したコンテンツのコンテンツIDと、当該コンテンツが実行可能か否かを表す情報とを含む販売情報を保持する記憶部を有し、
前記販売管理部は、前記記憶部の前記販売情報を参照して、前記コンテンツに前記第２のコンテンツIDと前記ワンタイムURLを作成するか否か判断することを特徴とするコンテンツ管理システム。
【請求項７】
請求項１に記載のコンテンツ管理システムにおいて、
前記第２のコンテンツIDと前記ワインタイムURLを送信する前に、前記ユーザに対し、同じコンテンツを重複して買おうとしていることを通知することを特徴とするコンテンツ管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２００９−１２８９５７（Ｐ２００９−１２８９５７Ａ）
【公開日】平成２１年６月１１日（２００９．６．１１）
【国際特許分類】
【出願番号】特願２００７−２９９９８３（Ｐ２００７−２９９９８３）
【出願日】平成１９年１１月２０日（２００７．１１．２０）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２１年６月１１日（２００９．６．１１）
【国際特許分類】
【出願日】平成１９年１１月２０日（２００７．１１．２０）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]