配信方法、サーバ及び受信端末
【課題】
ＩＰＴＶなどのコンテンツ配信を普及させる上で、著作権遵守や不正データ受信、不正アクセス、および、個人情報漏洩を防ぎ、専門知識を十分持たないユーザであっても、サービス提供側からの利用における十分な安全性の確保が課題である。また、コンテンツ視聴の権利を購入する関係上、配信によってユーザの手元に届くコンテンツの完全性も課題である。
【解決手段】
ハイブリッド・ピアツーピア型のコンテンツ配信において、サーバにてユーザの公開意思を確認し、コンテンツ配信済クライアントと未配信クライアント双方の認証による保証とを相互に行う。また、配信完了後のコンテンツをサーバにおいて完全性を保証する。さらに、両クライアントのネットワークの関係や予約状態考慮の優先度に基づいた配信接続を構築する。
ＩＰＴＶなどのコンテンツ配信を普及させる上で、著作権遵守や不正データ受信、不正アクセス、および、個人情報漏洩を防ぎ、専門知識を十分持たないユーザであっても、サービス提供側からの利用における十分な安全性の確保が課題である。また、コンテンツ視聴の権利を購入する関係上、配信によってユーザの手元に届くコンテンツの完全性も課題である。
【解決手段】
ハイブリッド・ピアツーピア型のコンテンツ配信において、サーバにてユーザの公開意思を確認し、コンテンツ配信済クライアントと未配信クライアント双方の認証による保証とを相互に行う。また、配信完了後のコンテンツをサーバにおいて完全性を保証する。さらに、両クライアントのネットワークの関係や予約状態考慮の優先度に基づいた配信接続を構築する。
【発明の詳細な説明】
【技術分野】
【０００１】
技術分野は、ネットワークを介したコンテンツの配信に関する。
【背景技術】
【０００２】
近年、端末性能の向上やネットワーク回線の大容量化、ハードディスクの大容量化にともない、映像や音楽、文字列や説明情報（メタデータ）などのデータからなるコンテンツを、サーバからクライアント端末にＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークを通じて配信し、端末で視聴を行うコンテンツ配信システムが構成されている。このようなコンテンツ配信を用いて、テレビ番組や映画などの映像を配信するＩＰテレビ（ＩＰＴＶ）サービスが開発されている。
【０００３】
特許文献１には、「コンテンツの配信を要求するクライアントが、配信品質やライセンス条件が良いクライアントからの配信を受けることを可能とする技術を提供すること」（特許文献１［００１２］参照）を課題とし、その解決手段として「サーバは、接続可能なクライアントをいくつかリストアップしてコンテンツの配信を要求するクライアントに送り、コンテンツの配信を要求するクライアントは、リストアップされた各クライアントの配信品質やライセンス条件などの接続環境から最適なクライアントを選択し、選択されたクライアントからコンテンツの配信を受けること」（特許文献１［００１３］参照）が記載されている。
【０００４】
また、特許文献２には、「各ピアの負荷を分散させたピアツーピア型コンテンツ配信システムを提供する」を課題とし、その解決手段として「コンテンツを相互に配信する多数のダイナミックピアＤＰと、コンテンツの配信を管理するセンタサーバＣＳとを備える。各ダイナミックピアＤＰは自身の動作状況をセンタサーバＣＳに通知し、センタサーバＣＳはその動作状況に基づいて各ダイナミックピアＤＰの負荷を計算し、登録する。各ダイナミックピアＤＰはセンタサーバＣＳからコンテンツリストを取得し、所望のコンテンツを所持している他のダイナミックピアＤＰを探し、負荷が最も低いダイナミックピアＤＰからコンテンツをダウンロードする。本システムはさらに、新規コンテンツを最初にアップロードするためのスタティックピアＳＰを備える。コンテンツはスタティックピアＳＰを起点に各ダイナミックピアＤＰに配信される」ことが記載されている（引用文献２要約参照）。
【０００５】
【特許文献１】特開２００５−１３５１４０号公報
【特許文献２】特開２００６−７２４３２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ＩＰＴＶサービスはその形態から大別すると、ストリーミング、ダウンロード、およびプログレッシブダウンロードの３つのサービスがある。
【０００７】
ストリーミングは、サーバからコンテンツのデータをクライアントに逐次配信し、クライアントでは到着したデータから映像や音声等を再生することでユーザに提示する。このため、十分に帯域の広いネットワークがある場合に、ほぼリアルタイムにユーザがコンテンツを視聴可能なことが特徴である。
【０００８】
ダウンロードはクライアントがサーバからあらかじめコンテンツデータのすべてを取得して蓄積しておき、蓄積が完了した後に視聴再生を行う。このため、リアルタイムに視聴する必要が無い場合、予めすべてのコンテンツデータを配信完了して蓄積することで、ユーザが所望する時間に何度も視聴することが可能であり、十分に帯域の広いネットワークでなくてもコンテンツ配信を受けられることが特徴である。
【０００９】
また、プログレッシブダウンロードは、これら２つの中間に位置し、コンテンツのすべての配信が完了する前に、端末に蓄積された中から逐次視聴を行う。これにより、蓄積完了を待つ必要が必ずしも無く、帯域が十分広くない場合にも蓄積時間を短縮することができ、また、蓄積完了後であればユーザ所望のタイミングで何度も視聴するというメリットを提供できる。
【００１０】
商用ＩＰＴＶサービス、特にダウンロード系サービスは、コンテンツをセンタサーバから取得する、いわゆるサーバ・クライアント型のシステムとなっていることが一般的である。ここではセンタサーバ側に保持している多くのコンテンツリストの中からユーザが任意のコンテンツを指定し、配信を開始する。
【００１１】
ここで、ユーザが指定したタイトルの一部や、出演者名の文字列やコンテンツのジャンル属性等をサーバに送付して、これに適するリストで絞り込む機能を用いて所望のコンテンツの検索が行われている。
【００１２】
また、配信を受ける端末が正当な機器であるかやユーザが正当であるかを認証する仕組みや、コンテンツを配信または再生する権利を購入するための課金処理、コンテンツの不正視聴を避けるためのデータの暗号化とそれを解除するための鍵管理等、多くの管理処理をサービス事業者が行う必要があり、一般的にはサーバ・クライアント型が適しているとされている。
【００１３】
一方、ＰＣやインターネットを用いた一般的なコンテンツ、すなわちファイル共有の一形態として、ピアツーピア（以下Ｐ２Ｐと略す）型配信がある。この配信形態は、コンテンツを保持している端末（ピア又はクライアントともいう）が、他の端末に対してのサーバとして動作し、端末から端末へ、すなわちピアからピアへとコンテンツが配信されていく。この形態は、配信は特定されたサーバが行うクライアント・サーバ型配信とは異なり、端末が次々とサーバの役割を果たしていくため、ねずみ算的にコンテンツ配信が行われるという特徴がある。
【００１４】
Ｐ２Ｐ型配信は、ピュアＰ２Ｐ型およびハイブリッドＰ２Ｐ型の２つに分類できる。ピュアＰ２Ｐ型は基本的にすべての通信をピアが行い、センタサーバに依存しないため、ネットワークの耐障害性が非常に高い、また、実装上匿名性を持たせることが可能という特徴があり、コンテンツの配信効率が良い。
【００１５】
一方のハイブリッドＰ２Ｐ型は、コンテンツの転送はピア同士で行うが、コンテンツの所在解決やピア同士の割り当てはセンタサーバで行う。つまり、コンテンツやそれが存在するピアの検索をセンタサーバで行い、処理負荷の高い実際の配信をピアで行うため、すべての端末動作の管理がしやすく合理的なコンテンツ配信方法である。
【００１６】
これらを鑑みると、ＩＰＴＶでのダウンロード配信サービスにおいても、Ｐ２Ｐ型、特にハイブリッドＰ２Ｐ型のコンテンツ配信方法を用いることで、管理されたコンテンツ配信を行うＩＰＴＶサービスの普及を行う技術が開発されている。
【００１７】
例えば、特許文献１においては、ハイブリッドＰ２Ｐ型でコンテンツを配信するシステムにおいて、配信品質やライセンス条件がよい（期間が残っている）ピアからの再配信を受けることが可能となっている。これにより、複数存在するピアの中から最良の接続環境を有するものからの配信を受けることができ、安定した配信品質やライセンス条件を確保することができる。
【００１８】
また、特許文献２では、ピアが自身の動作状況をセンタサーバに通知することで、センタサーバが負荷の最も低いピアを選択してＰ２Ｐ型コンテンツ配信を実現している。
【００１９】
特許文献１および特許文献２においては、いずれもピアの選択を行う方式の一手段として、それぞれ、ネットワーク配信品質とライセンス、あるいは、ピアの負荷状態から行うことと、それらを用いた配信手順が開示されている。
【００２０】
しかしながら、特許文献１および特許文献２では、再配信を行うピアの選択という観点で、ネットワークトラフィックあるいは装置の負荷を基に選択しており、ピアからの再配信を行う際コンテンツおよび対象ピアが正当で安全であるか、あるいはコンテンツが正当で安全であるかの保証を行うことが開示されておらず、困難である。Ｐ２Ｐ型コンテンツ配信では手軽に配信が行えることから、コンテンツ制作者側の著作権を無視した配信を行ったり、コンピュータウィルス等の不正なデータを受信してしまうことで端末に悪影響を及ぼす、または、不正にアクセスされたりユーザの知らない間に秘密データが流出してしまうといった問題が生じており、これらを解決した上でのＩＰＴＶサービスの普及が必須である。
【００２１】
特に商用ＩＰＴＶサービスでは、ユーザがネットワークやコンテンツ配信サービス、およびそれを享受する端末の専門知識を十分持たない場合が多く、サービス提供側からの利用における十分な安全性の確保が課題である。また、コンテンツ視聴の権利を購入する関係上、配信によってユーザの手元に届くコンテンツの完全性も課題である。
【課題を解決するための手段】
【００２２】
本発明の一実施の態様は、端末がサーバにコンテンツの配信を要求するコンテンツ配信要求情報を送信し、サーバは端末からコンテンツ配信要求情報を受信すると、その端末に他の端末へコンテンツ配信要求情報を送信するよう指示するリダイレクト指示を送信し、端末はサーバからリダイレクト指示を受信すると他の端末にコンテンツ配信要求情報を送信し、他の端末はコンテンツ配信要求情報を受信すると端末にコンテンツを配信する。
【発明の効果】
【００２３】
上記手段によれば、より安全なコンテンツ配信が実現できる。例えば、ＩＰＴＶをハイブリッドP２P型のコンテンツ配信方式を用いる場合にも、コンテンツ配信サービスに纏わる問題からのユーザの安心と安全を高いレベルで確保することが可能になる。
【００２４】
また、コンテンツの制作者サイド、およびサーバ運営者サイドから見た場合の不正コンテンツ流通の危険性を低減することが可能になる。
【００２５】
また、配信接続ピアを合理的に設定することで、高速なコンテンツ配信、および、端末の利用状況を考慮したなコンテンツ配信が実現できる。
【発明を実施するための最良の形態】
【００２６】
以下、本発明の実施例を図面を用いて説明する。ただし、本発明の適用は本実施例に限定されない。なお、本発明で説明しているコンテンツとは、映像や音声や文字情報などのいくつかのメディアで構成する番組情報を想定して説明する。
【００２７】
図１は本発明を実施するための基本的なシステム構成図である。
インターネット１５０を中心として、サーバ１００およびクライアント１２０,１３０,１３１,１４０が接続されている。
【００２８】
サーバ１００は、演算部１０７を中心として、ネットワークを用いて他の機器、特にクライアントと通信を行うための通信部１０８、クライアントを管理するクライアント管理部１０３、コンテンツを管理するコンテンツ管理部１０６、および配信状況を管理する配信管理部１１０から構成される。
【００２９】
ここで、クライアント管理部１０３では、クライアントと認証を行うための認証情報１０１と、クライアントとの通信状況を記録する通信情報１０２と、コンテンツへの課金状況を記録する課金情報１０４とを管理している。
【００３０】
図２はクライアントの認証情報１０１の一例の説明図である。認証情報は、クライアントのＩＤ（管理番号）と予め定めたクライアントに一意の識別子、クライアントの所有者とその住所および連絡先などが記載されている。
【００３１】
図３は通信情報１０２の一例の説明図である。通信情報には、前述のクライアントＩＤに結び付けて、クライアントのアドレスおよびネットワークポート、および、当該クライアントがサーバと通信した際の経路情報やその際の回線速度を記録する。
【００３２】
以下の処理では、これらのアドレスやポート番号はそれぞれのクライアントとの通信に用いる情報とする。また、経路情報の検出は、経路上のルータを検出する「tracert」等の一般的なコマンドを用いることができる。また、回線速度はクライアントとサーバが行った通信に際しての、送信または受信したデータサイズとそれらにかかった時間から平均値として算出することができる。
【００３３】
なお、この説明ではＩＰｖ４（Internet Protocol version ４）の様式にて記載しているが、IPv６や電話回線など、他の方式であっても良い。
【００３４】
図４は課金情報１０４の一例の説明図である。課金情報には、前述のクライアントIDに結び付けて、支払い方法及び名義人、配信済みのコンテンツＩＤ、および、コンテンツの配信サービスあるいは配信されたコンテンツを再生視聴したことにより発生するクライアントへの課金額などを記録する。
【００３５】
なお、これらクライアント管理部１０３が管理する各種情報は、ハードディスク等の記録メディアを用いて記録され、クライアント管理部が管理するメモリ上に読み込まれても良い。
【００３６】
コンテンツ管理部１０６では、コンテンツデータおよび付随する情報から構成するコンテンツ情報１０５を管理する。図５はコンテンツ情報１０５の説明図である。コンテンツ情報は、コンテンツのＩＤ（管理番号）と、コンテンツのフォーマットや内容等の説明情報、コンテンツデータ、および、コンテンツのサイズやコンテンツの完全性を保証するために用いるチェックサム情報、インターネット等の通信路にて悪意の第３者から保護するためＲＳＡ暗号技術などを用いて暗号化されたコンテンツを解読して再生するための鍵情報、そしてコンテンツの配信サービスあるいは配信されたコンテンツを再生視聴したことにより発生する料金などを記録する。また、コンテンツ情報１０５はコンテンツデータを蓄積している蓄積部ともいえる。
【００３７】
なお、これら各種情報は、ハードディスク等の記録メディアを用いて記録され、コンテンツ管理部１０６が管理するメモリ上に読み込まれても良い。また、コンテンツデータと、コンテンツデータを説明するデータ（メタデータ）としていくつかに分けて管理しても良い。また、コンテンツデータを保有するサーバと、コンテンツデータのコンテンツ情報を保有するサーバとが別のサーバであってもよい。すなわち、サーバ１００はコンテンツデータは保有せず、コンテンツデータのコンテンツ情報を用いて後述するコンテンツの配信の管理を行なうサーバであってもよい。
【００３８】
配信管理部１１０では、コンテンツ配信を行ったコンテンツ保有クライアント情報１０９を管理する。図６はコンテンツ保有クライアント情報１０９の説明図である。コンテンツ保有クライアント情報は、前述のコンテンツIDに対応させて、既にコンテンツを配信したクライアントのＩＤを記載する。
【００３９】
次にクライアント１２０,１３０,１３１,１４０について説明する。本発明でのクライアントは、配信済クライアント１２０,１３０,１３１と未配信クライアント１４０に分けて説明する。ただし、クライアントはＰ２Ｐ型配信で言うクライアントとしてもサーバとしても動作するサーブレット（servelet）として動作するため、あるコンテンツに対しては未配信クライアントの動作を行っても、別のコンテンツに対しては配信済クライアントの動作を行っても良い。
【００４０】
また、それぞれのクライアントのブロック構成は同じであるとするが、以後説明するそれぞれにおける処理ステップを行うことができれば必ずしも同じ構成でなくてもよい。例えば、クライアントがＰＣ等の汎用機器や、ＴＶ等の特定機器として構成されていてもよい。
【００４１】
配信済クライアント１２０,１３０,１３１（以下便宜的に代表して１２０について説明する）は、演算部１２５を中心として、クライアント機器を識別するために予め設定された識別子１２１、ネットワークを用いて他の機器と通信を行うための通信部１２４、コンテンツを管理するコンテンツ管理部１２２、およびユーザへ表示を行う表示部１２６、ユーザからの指示を受ける入力部１２７及びクライアントの設定部１２８から構成する。
【００４２】
未配信クライアント１４０も同様に、演算部１４５、識別子１４１、通信部１４４、コンテンツ管理部１４２、および表示部１４６、入力部１４７及びクライアントの設定部１４８から構成する。
【００４３】
なお、上記表示部は必ずしもディスプレイ等である必要はなく、当該クライアント機器と別体のディスプレイ等に表示するデータを出力する出力部であってもよい。
【００４４】
それぞれのクライアントが持つコンテンツ管理部１２２,１４２ではコンテンツ情報１２３,１４３を管理する。このコンテンツ情報は、サーバでのコンテンツ情報１０５,図５と同様の形式であるとし、それぞれのクライアントが既に配信を受けたコンテンツに関しての各種情報が管理される。図７はそれぞれのクライアントが持つ識別子１２１,１４１の説明図である。識別子は、予め定める方式による、クライアントの一意性を保証するための記号列であり、図のようにクライアントのＩＤと対応付けて保持しても良い。
【００４５】
次に、サーバ１００、配信済クライアント１２０,１３０,１３１、および、未配信クライアント１４０での動作を説明する。図８および図９はサーバ１００、配信済クライアント１２０,１３０,１３１、および、未配信クライアント１４０における処理フローの説明図である。以下、それぞれの処理を時間を追って説明する。なお、各処理はサーバあるいはクライアントの演算部において主に処理され、それぞれに接続された各部と連携して実行されるとする。また、通信はサーバ、クライアントともに通信部を用い、インターネットを経由して行われるが、以下便宜上、説明を割愛する。
【００４６】
まず、配信済クライアントではサーバからコンテンツを配信（ステップ８２１）されたコンテンツを保存している（ステップ８０１）。
【００４７】
次に、配信済クライアントでは、本発明を用いたＰ２Ｐ型配信によるサーバの代理としての配信を行うかどうかのユーザ意思を確認するため、代理配信受入れ設定を行う（ステップ８０２）。図１０は代理配信受入れの表示画面の一例である。図のような表示を配信済クライアントの表示部１２６を用いて、サーバの代理での他ユーザ（未配信クライアントのユーザ）からの配信要求の設定を求め、リモコンや操作パネル、マウス等の入力部１２７より指示を受ける。なお、この代理配信受入れ設定は、クライアントの設定１２８に記録する。
【００４８】
次に、コンテンツ配信について説明する。まず、サーバ１００からコンテンツ情報１０５のうち、鍵情報やチェックサム等の一部の情報を除いて、配信可能なコンテンツの情報（例えばコンテンツのタイトル、内容の説明、出演者の名前等の情報）を未配信クライアント１４０に配信する（ステップ８２２,８４１）。
【００４９】
未配信クライアントでは、配信されたコンテンツ情報を基に、表示部１４６および入力部１４７を用いて、サーバが配信可能なコンテンツのうちからユーザが配信を所望するコンテンツを選択する（ステップ８４２）。図１１はコンテンツ選択の表示画面の一例の説明図である。配信されたコンテンツ情報のうち、ユーザに必要な内容等の表示を行い、配信を所望するコンテンツに対してチェックを入れることで選択を行う（ステップ８４２）。
【００５０】
ここで、すべてのコンテンツを表示し選択させるのではなく、ジャンルやキーワードによる絞込み検索を行えるようにしてもよい。また、この検索処理はサーバにて行い、その結果をクライアントに送信することにしてもよい。また、図１１では配信を所望するコンテンツに対してチェックを入れることで選択が行われているが、必ずしもこれに限定されるわけではなく、選択されたコンテンツの表示の色が変わる等、他の方法で選択が行なわれてもよい。
【００５１】
次に、選択されたコンテンツ、図１１の場合にはコンテンツＩＤ”１００００１”をサーバに伝達するために、サーバとの接続を確立し（ステップ８４３,８２３）、クライアントの認証を行う（ステップ８２４,８４４）。なお、ステップ８２４,８４４で認証に失敗した場合は、当該クライアントは配信サービスを受けられず、処理をここで打ち切り終了してもよい。または、例えば、解像度など質が劣るコンテンツを配信するようサーバ側で変更する等により受けられる配信サービスを制限するようにしてもよい。または、例えば認証を受けるための正規クライアントおよび正規ユーザとしてサーバへの入会や登録を促すためのコンテンツの配信や案内を表示してもよい。
【００５２】
認証には、未配信クライアントが持つ識別子１４１をサーバに伝達し、サーバの認証情報１０１を用いてクライアント管理部が照合し、結果を未配信クライアントに送付する。認証された未配信クライアントは次にコンテンツIDを用いて配信要求をサーバに伝達する（ステップ８４５,８２５）。
【００５３】
サーバでは、コンテンツ保有クライアント情報１０９から配信管理部が当該コンテンツに対応するクライアントＩＤを取得し（ステップ８２６）、それに基づいてクライアント管理部１０３にて通信情報１０２から情報を入手する（ステップ８２７）。この際、未配信クライアントに関しても入手する。
【００５４】
次に、入手した各配信済クライアントの通信情報から、クライアントの優先度を算出しその優先度の高い順に並べる（ステップ８２８）。
【００５５】
ここで、優先度の計算について説明する。図１２は優先度の計算フローの説明図である。まず、優先度を初期化し（ステップ１２０１）、未配信クライアント及び対象となるひとつの配信済クライアントの通信情報を取得する。
【００５６】
未配信クライアントのうちの予め定めた定数Ｎ番目までの経路のうち、ｎ番目と配信済クライアントの経路を比較し（ステップ１２０３）、同一の経路が含まれる場合（ステップ１２０３でＹｅｓの場合）には優先度に対して１/２のｎ乗を掛け合わせる（ステップ１２０４）。すなわち、未配信クライアントと配信済クライアントとの間にルータが一つ増える度に優先度を１/２にする。
【００５７】
また、Ｎ番目位以内に経路重複が無い場合（ステップ１２０３でＮｏの場合）には１/２のＮ乗を優先度に掛け合わせる（ステップ１２０５）。さらに、未配信クライアントに向かう回線の速度を評価するよう、未配信クライアントの下り回線の速度、および、対象の配信済クライアントの上り回線の速度を優先度に掛け合わせる（ステップ１２０６）。
【００５８】
また、後ほど取得する、対象の配信済クライアントの今後Ｍ（予め定義された定数）時間の間に予定されている、録画や視聴、配信等の既存の予約状態があるかどうかを評価し（ステップ１２０７）、ｍ時間内に予約がある場合（ステップ１２０７でＹｅｓの場合）には優先度に１/２の（Ｍ−ｍ）乗を掛け合わせる（ステップ１２０８）。
【００５９】
すなわち、直近に予約がある場合には優先度が低くなるように計算に加える。今後Ｍ時間の間の予定を取得していない場合や今後Ｍ時間の間に予約がない場合（ステップ１２０７でＮｏの場合）、予約による優先度操作は行わないとする。
【００６０】
このようにして、優先度を入手したすべての配信済クライアントに対して求め、優先度の高い順にリストを作成する（ステップ８２８）。図１３はこの配信済みクライアントの優先リストの例である。算出した優先度をキーにして、高い順に並べることで、以下のステップを続ける際にネットワーク構築上より合理的な順に配信済クライアントを順に評価する。
【００６１】
図８の説明に戻り、以下のフローの説明を続ける。優先度の順に配信済クライアントをひとつ選定し折衝を開始するが、リストがない、あるいは最後まで折衝したが適切な代理サーバがないと判断した場合には（ステップ８３０でＮｏの場合）、サーバが未配信コンテンツに対してコンテンツを配信する（ステップ８３１，８４６および、図９ステップ９３０,９６０）。ここで折衝とは、単純にネットワーク経由での接続を試みること、あるいは、その時点での接続により検出できる優先度計算に用いた各種情報に差異があり、優先度の再計算結果が以前の優先度より低い場合に、リスト以降にあるクライアントの優先度とそれぞれ比較してこのクライアントとの接続を行わないような判断をすること等を意味する。またこの際、新たな各種情報により当該クライアント情報の更新を行ってもよい。
【００６２】
リストから配信済クライアントが入手できた場合（ステップ８３０でＹｅｓの場合）には、サーバから配信済クライアントに接続を試みる（ステップ８３２,８０３）。
【００６３】
接続を確立した後認証を行うために、配信済クライアントの識別子１２１とサーバの認証情報１０１を用いてクライアント管理部１０３が照合し、結果を配信済クライアントに送付する（ステップ８０４,８３３）。
【００６４】
次に、前述のように設定された代理配信の受入れ設定から、未配信クライアントのユーザの意思を伝達する（ステップ８３４,８０５）。もし受入れ意思が無い場合（ステップ８３５でＮｏの場合）には、対象配信済クライアントとの接続を終了し（ステップ８３８,８０７）、次の優先度を持つリスト上の配信済クライアントに対象を移し、同様に評価する（ステップ８２９〜８３５）。
【００６５】
また、前述のステップ８０２のユーザ意思の確認設定の代わりに、ステップ８０５でユーザ意思を入力してもよい。この際には図１０の画面に準じてもよいし、図１４のように同時に要求された代理配信をまとめて表示し、ユーザの意思を確認してもよい。図１４では、要求案件ごとに、コンテンツのタイトル、および、要求した未配信クライアントのＩＤ、そして、許可するかどうかのフラグを表示する。そして、ユーザは入力部を用いてこの許可フラグを設定し、フラグ状態を表示する。これらフラグは、すべてを許可１４０２、あるいは、すべてを拒否１４０３するために、同時に設定するボタンを設けてもよい。この際、ユーザの代理配信を促すために、ポイントによるユーザ優遇サービスを行ってもよく、前述の要求案件ごとに付与ポイントを予め定義し、代理配信の許可を行い実際に代理配信を行った際に、各クライアントに対してポイントを付与する。付与された累積ポイントは画面１２６上に表示し１４０１、必要に応じてユーザが確認することができる。なお、各クライアントのポイントはサーバにて管理してもよい。このポイントに基づくユーザ優遇サービスとは、例えばポイントによりコンテンツ視聴の価格から予め設定した条件により割引したり、最終的な利用料請求からの割引や、他のサービスを受ける際の条件として用いたりしてもよい。
【００６６】
なお、ステップ８０２の代理配信受け入れ設定では、これらのユーザの受入れ意思を予め条件として設定しておき、それら条件に該当するかどうかを判断し半自動化してもよい。例えば、図１５のような画面により、代理配信を行う未配信クライアント毎に条件を追加していき１５０１、それぞれのクライアント毎に「いつも許可」１５０２や「いつも拒否」１５０３、「毎回確認」１５０４をそれぞれのボタンにより設定する。この際、クライアントＩＤの設定には、ユーザがＩＤを入力部より適宜してもよいし、配信要求があった際の図１０などの意思表示画面において適宜ボタンを用意し、該当要求を行ったクライアントＩＤを保持しながら画面遷移をして設定してもよい。「毎回確認」１５０４を設定した場合には、該当クライアントから配信要求があった場合に図１０のような画面でユーザからの操作を行うようにし、「いつも許可」１６０２や「いつも拒否」１６０３設定していた場合にはこれを省いて許可・拒否をすることで半自動的に意思伝達を実現する。また、図１６のような画面により、コンテンツ毎に条件を追加していき１６０１、「いつも許可」１６０２や「いつも拒否」１６０３、「毎回確認」１６０４を設定してもよい。この際、コンテンツまたはそのＩＤの設定はユーザがＩＤを入力部より適宜してもよいし、配信要求があった際の図１０などの意思表示画面において適宜ボタンを用意し、該当要求のあったコンテンツＩＤを保持しながら画面遷移をして設定してもよい。「毎回確認」１６０４を設定した場合には、該当コンテンツの配信要求があった場合に図１０のような画面でユーザからの操作を行うようにし、「いつも許可」１６０２や「いつも拒否」１６０３設定していた場合にはこれを省いて許可・拒否をすることで半自動的に意思伝達を実現する。
【００６７】
受入れ意思があるユーザの配信済クライアントであった場合（ステップ８３５でＹｅｓの場合）には、指定された先までの予約状況を問い合わせ（ステップ８３５,８３６）、予約状況を加味した優先度を再度計算する（ステップ８３７）。ここでの優先度の計算は上述した図１２に示すフローにより行われる。
【００６８】
求めた優先度が予め定めた閾値を超えていない場合（ステップ８３９でＮｏの場合）、対象となる配信済クライアントとの接続を終了し、（ステップ８３８,８０７）、次の優先度を持つリスト上の配信済クライアントに対象を移し、同様に評価する（ステップ８２９〜８３５）。これらを優先度リストのすべてで評価していくことにより、適切な配信済クライアントが選択され、適切な配信済クライアントが無い場合にはサーバが選択される。
【００６９】
優先度が予め定めた閾値を超えていた場合（ステップ８３９でＹｅｓの場合）、当該配信済クライアントがコンテンツ配信を行う配信済クライアントとして決定する。
【００７０】
図９にて、コンテンツ配信を行う配信済クライアントが決定し、その後の実際のコンテンツ配信が行われるフローについて説明する。
【００７１】
既に未配信クライアントおよび配信済クライアントが認証済みであるので、配信済クライアントに対して未配信クライアントを保証するための通信を行う（ステップ９２１,９０１）。また、未配信クライアントに対して、配信済クライアントの保証となる、リダイレクト指示を伝達する（ステップ９２２,９４１）。なお、リダイレクトとは、サーバが配信する代わりに、配信済クライアントのひとつを選択することで代理サーバとなるようにする処理である。
【００７２】
これらにより、配信済クライアントと未配信クライアントとは、サーバにより互いの保証をされ、ファイヤウォールを超えた通信を行うことができる設定等、それぞれの通信設定を開始する。
【００７３】
次に、未配信クライアントと配信済クライアントとの間で接続要求が送受信され、（ステップ９４２,９０２）、その後所望のコンテンツの配信要求を伝達する（ステップ９４３,９０３）。これにより、配信済クライアントから未配信クライアントに対してコンテンツが配信され、未配信クライアントはコンテンツを保存する（ステップ９０４,９４４）。
【００７４】
コンテンツの配信が終了すると、両者間の接続を終了し（ステップ９０５,９４５）、通信設定も終了する（ステップ９０６,９４６）。
【００７５】
次に、コンテンツが正しく配信されたかどうかの検証について説明する。すなわち、未配信クライアントでは、配信中から、あるいは配信後に、コンテンツの一意性や完全性を検証するための情報、例えばコンテンツのサイズやチェックサム（バイナリデータを頭から加算した際の和のうち、指定されたバイトの値）を用いて、これをサーバのコンテンツ情報内のデータと照合することで実現する（ステップ９４７,９２３）。
【００７６】
例えば、配信されたコンテンツのコンテンツサイズとサーバのコンテンツ情報内の当該コンテンツのサイズとを比較し、一致しなければ完全性が否定され、コンテンツは正しく配信されなかったと判断してもよい。なお、コンテンツのサイズの一致の判断は、完全に一致することを条件としてもよいが、コンテンツサイズの不一致の程度が所定の範囲内であれば一致と判断するようにしてもよい。
【００７７】
また、例えば配信されたコンテンツのチェックサムとサーバのコンテンツ情報内の当該コンテンツのチェックサムとを比較し、一致しなければ配信されたコンテンツとサーバのコンテンツ情報が示すコンテンツとは異なるものであるとして一意性が否定され、コンテンツは正しく配信されなかったと判断してもよい。
【００７８】
なお、照合に用いる情報は、例えばパリティやＣＲＣ（Ciclic Redundancy Check）やＭＤ５（Message Digest Algorithm５）などのハッシュ、その他の技術による検証であってもよい。
【００７９】
これによりコンテンツの一意性、完全性を確保し、未配信クライアントのユーザに対するコンテンツの保証が行われる。なお、この後、サーバのコンテンツ管理部１０３およびクライアント管理部１０６により課金情報１０４の更新などの課金処理を行うことになるが、配信完了をもって課金するか、あるいは、ユーザが視聴再生を行ったときに課金するかは適宜設定すればよい。
【００８０】
上記によりコンテンツが正しく配信されたと判断された場合（ステップ９２４、９４８）、サーバでは接続の際に得られた配信済クライアント、および、未配信クライアントの経路情報や回線速度等（図３）の各種情報を更新記録し（ステップ９２５）、サーバ、未配信クライアントともに処理を終了する。なお、正しく配信されたと判断されなかった場合には、再度コンテンツの配信と保存を行い（ステップ９３０、９６０）、コンテンツの一意性と完全性を確認する処理を行う。なお、あらかじめ配信と保存を再度行う回数を定め、その回数に達した場合には接続の経路上、あるいは、サーバおよび両クライアント装置に異状が無いかの調査を行い、その回復を行った後再度配信と保存を行ってもよい。
【００８１】
なお、これまでに説明した識別子は、外部からの盗用、なりすまし等の悪用をされないよう、暗号化や異常時の自己破壊などの適切な手段で保管されることが望まれる。また、サーバやクライアントが持つ通信部による相互の通信は、他技術、例えばＳＳＬ（Secure Socket Layer）等の技術を用いるなどして、相互信頼と外部の悪用を防止した通信を行うためのデータ暗号化を行うことも望まれる。
【００８２】
また、本発明で説明しているコンテンツとは、映像や音声や文字情報などのいくつかのメディアで構成する番組情報を想定して説明を行ったが、これに留まらず、ＰＣ（パーソナルコンピュータ）等で用いられるファイル、実行可能なオブジェクトデータ、メール、ＷＷＷ（World Wide Web）により送受されるマークアップ記述や動作記述を行うスクリプト、その他にもネットワークを用いて伝送が行われる一般的電子データであってもよい。したがって、ネットワークを用いた多くの産業で汎用的に用いられる可能性がある。
【図面の簡単な説明】
【００８３】
【図１】システム構図の一例
【図２】認証情報１０１の一例
【図３】通信情報１０２の一例
【図４】課金情報１０４の一例
【図５】コンテンツ情報１０５の一例
【図６】コンテンツ保有クライアント情報１０９の一例
【図７】クライアントが持つ識別子１２１,１４１の一例
【図８】サーバ、配信済クライアント、及び未配信クライアントの処理フローの一例
【図９】サーバ、配信済クライアント、及び未配信クライアントの処理フローの一例
【図１０】代理配信受入れの表示画面の一例
【図１１】コンテンツ選択の表示画面の一例
【図１２】優先度の計算フローの一例
【図１３】配信済みクライアントの優先リストの一例
【図１４】代理配信受入れの表示画面（まとめて表示）の一例
【図１５】代理配信対象クライアント条件の一例
【図１６】代理配信対象コンテンツ条件の一例
【符号の説明】
【００８４】
１００サーバ
１０１認証情報
１０２通信情報
１０３クライアント管理部
１０４課金情報
１０５コンテンツ情報
１０６コンテンツ管理部
１０７演算部
１０８通信部
１０９コンテンツ保有クライアント情報
１１０配信管理部
１２０１３０１３１配信済クライアント
１２１識別子
１２２コンテンツ管理部
１２３コンテンツ情報
１２４通信部
１２５演算部
１２６表示部
１２７入力部
１２８設定情報
１４０未配信クライアント
１４１識別子
１４２コンテンツ管理部
１４３コンテンツ情報
１４４通信部
１４５演算部
１４６表示部
１４７入力部
１４８設定情報
１５０インターネット
【技術分野】
【０００１】
技術分野は、ネットワークを介したコンテンツの配信に関する。
【背景技術】
【０００２】
近年、端末性能の向上やネットワーク回線の大容量化、ハードディスクの大容量化にともない、映像や音楽、文字列や説明情報（メタデータ）などのデータからなるコンテンツを、サーバからクライアント端末にＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークを通じて配信し、端末で視聴を行うコンテンツ配信システムが構成されている。このようなコンテンツ配信を用いて、テレビ番組や映画などの映像を配信するＩＰテレビ（ＩＰＴＶ）サービスが開発されている。
【０００３】
特許文献１には、「コンテンツの配信を要求するクライアントが、配信品質やライセンス条件が良いクライアントからの配信を受けることを可能とする技術を提供すること」（特許文献１［００１２］参照）を課題とし、その解決手段として「サーバは、接続可能なクライアントをいくつかリストアップしてコンテンツの配信を要求するクライアントに送り、コンテンツの配信を要求するクライアントは、リストアップされた各クライアントの配信品質やライセンス条件などの接続環境から最適なクライアントを選択し、選択されたクライアントからコンテンツの配信を受けること」（特許文献１［００１３］参照）が記載されている。
【０００４】
また、特許文献２には、「各ピアの負荷を分散させたピアツーピア型コンテンツ配信システムを提供する」を課題とし、その解決手段として「コンテンツを相互に配信する多数のダイナミックピアＤＰと、コンテンツの配信を管理するセンタサーバＣＳとを備える。各ダイナミックピアＤＰは自身の動作状況をセンタサーバＣＳに通知し、センタサーバＣＳはその動作状況に基づいて各ダイナミックピアＤＰの負荷を計算し、登録する。各ダイナミックピアＤＰはセンタサーバＣＳからコンテンツリストを取得し、所望のコンテンツを所持している他のダイナミックピアＤＰを探し、負荷が最も低いダイナミックピアＤＰからコンテンツをダウンロードする。本システムはさらに、新規コンテンツを最初にアップロードするためのスタティックピアＳＰを備える。コンテンツはスタティックピアＳＰを起点に各ダイナミックピアＤＰに配信される」ことが記載されている（引用文献２要約参照）。
【０００５】
【特許文献１】特開２００５−１３５１４０号公報
【特許文献２】特開２００６−７２４３２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ＩＰＴＶサービスはその形態から大別すると、ストリーミング、ダウンロード、およびプログレッシブダウンロードの３つのサービスがある。
【０００７】
ストリーミングは、サーバからコンテンツのデータをクライアントに逐次配信し、クライアントでは到着したデータから映像や音声等を再生することでユーザに提示する。このため、十分に帯域の広いネットワークがある場合に、ほぼリアルタイムにユーザがコンテンツを視聴可能なことが特徴である。
【０００８】
ダウンロードはクライアントがサーバからあらかじめコンテンツデータのすべてを取得して蓄積しておき、蓄積が完了した後に視聴再生を行う。このため、リアルタイムに視聴する必要が無い場合、予めすべてのコンテンツデータを配信完了して蓄積することで、ユーザが所望する時間に何度も視聴することが可能であり、十分に帯域の広いネットワークでなくてもコンテンツ配信を受けられることが特徴である。
【０００９】
また、プログレッシブダウンロードは、これら２つの中間に位置し、コンテンツのすべての配信が完了する前に、端末に蓄積された中から逐次視聴を行う。これにより、蓄積完了を待つ必要が必ずしも無く、帯域が十分広くない場合にも蓄積時間を短縮することができ、また、蓄積完了後であればユーザ所望のタイミングで何度も視聴するというメリットを提供できる。
【００１０】
商用ＩＰＴＶサービス、特にダウンロード系サービスは、コンテンツをセンタサーバから取得する、いわゆるサーバ・クライアント型のシステムとなっていることが一般的である。ここではセンタサーバ側に保持している多くのコンテンツリストの中からユーザが任意のコンテンツを指定し、配信を開始する。
【００１１】
ここで、ユーザが指定したタイトルの一部や、出演者名の文字列やコンテンツのジャンル属性等をサーバに送付して、これに適するリストで絞り込む機能を用いて所望のコンテンツの検索が行われている。
【００１２】
また、配信を受ける端末が正当な機器であるかやユーザが正当であるかを認証する仕組みや、コンテンツを配信または再生する権利を購入するための課金処理、コンテンツの不正視聴を避けるためのデータの暗号化とそれを解除するための鍵管理等、多くの管理処理をサービス事業者が行う必要があり、一般的にはサーバ・クライアント型が適しているとされている。
【００１３】
一方、ＰＣやインターネットを用いた一般的なコンテンツ、すなわちファイル共有の一形態として、ピアツーピア（以下Ｐ２Ｐと略す）型配信がある。この配信形態は、コンテンツを保持している端末（ピア又はクライアントともいう）が、他の端末に対してのサーバとして動作し、端末から端末へ、すなわちピアからピアへとコンテンツが配信されていく。この形態は、配信は特定されたサーバが行うクライアント・サーバ型配信とは異なり、端末が次々とサーバの役割を果たしていくため、ねずみ算的にコンテンツ配信が行われるという特徴がある。
【００１４】
Ｐ２Ｐ型配信は、ピュアＰ２Ｐ型およびハイブリッドＰ２Ｐ型の２つに分類できる。ピュアＰ２Ｐ型は基本的にすべての通信をピアが行い、センタサーバに依存しないため、ネットワークの耐障害性が非常に高い、また、実装上匿名性を持たせることが可能という特徴があり、コンテンツの配信効率が良い。
【００１５】
一方のハイブリッドＰ２Ｐ型は、コンテンツの転送はピア同士で行うが、コンテンツの所在解決やピア同士の割り当てはセンタサーバで行う。つまり、コンテンツやそれが存在するピアの検索をセンタサーバで行い、処理負荷の高い実際の配信をピアで行うため、すべての端末動作の管理がしやすく合理的なコンテンツ配信方法である。
【００１６】
これらを鑑みると、ＩＰＴＶでのダウンロード配信サービスにおいても、Ｐ２Ｐ型、特にハイブリッドＰ２Ｐ型のコンテンツ配信方法を用いることで、管理されたコンテンツ配信を行うＩＰＴＶサービスの普及を行う技術が開発されている。
【００１７】
例えば、特許文献１においては、ハイブリッドＰ２Ｐ型でコンテンツを配信するシステムにおいて、配信品質やライセンス条件がよい（期間が残っている）ピアからの再配信を受けることが可能となっている。これにより、複数存在するピアの中から最良の接続環境を有するものからの配信を受けることができ、安定した配信品質やライセンス条件を確保することができる。
【００１８】
また、特許文献２では、ピアが自身の動作状況をセンタサーバに通知することで、センタサーバが負荷の最も低いピアを選択してＰ２Ｐ型コンテンツ配信を実現している。
【００１９】
特許文献１および特許文献２においては、いずれもピアの選択を行う方式の一手段として、それぞれ、ネットワーク配信品質とライセンス、あるいは、ピアの負荷状態から行うことと、それらを用いた配信手順が開示されている。
【００２０】
しかしながら、特許文献１および特許文献２では、再配信を行うピアの選択という観点で、ネットワークトラフィックあるいは装置の負荷を基に選択しており、ピアからの再配信を行う際コンテンツおよび対象ピアが正当で安全であるか、あるいはコンテンツが正当で安全であるかの保証を行うことが開示されておらず、困難である。Ｐ２Ｐ型コンテンツ配信では手軽に配信が行えることから、コンテンツ制作者側の著作権を無視した配信を行ったり、コンピュータウィルス等の不正なデータを受信してしまうことで端末に悪影響を及ぼす、または、不正にアクセスされたりユーザの知らない間に秘密データが流出してしまうといった問題が生じており、これらを解決した上でのＩＰＴＶサービスの普及が必須である。
【００２１】
特に商用ＩＰＴＶサービスでは、ユーザがネットワークやコンテンツ配信サービス、およびそれを享受する端末の専門知識を十分持たない場合が多く、サービス提供側からの利用における十分な安全性の確保が課題である。また、コンテンツ視聴の権利を購入する関係上、配信によってユーザの手元に届くコンテンツの完全性も課題である。
【課題を解決するための手段】
【００２２】
本発明の一実施の態様は、端末がサーバにコンテンツの配信を要求するコンテンツ配信要求情報を送信し、サーバは端末からコンテンツ配信要求情報を受信すると、その端末に他の端末へコンテンツ配信要求情報を送信するよう指示するリダイレクト指示を送信し、端末はサーバからリダイレクト指示を受信すると他の端末にコンテンツ配信要求情報を送信し、他の端末はコンテンツ配信要求情報を受信すると端末にコンテンツを配信する。
【発明の効果】
【００２３】
上記手段によれば、より安全なコンテンツ配信が実現できる。例えば、ＩＰＴＶをハイブリッドP２P型のコンテンツ配信方式を用いる場合にも、コンテンツ配信サービスに纏わる問題からのユーザの安心と安全を高いレベルで確保することが可能になる。
【００２４】
また、コンテンツの制作者サイド、およびサーバ運営者サイドから見た場合の不正コンテンツ流通の危険性を低減することが可能になる。
【００２５】
また、配信接続ピアを合理的に設定することで、高速なコンテンツ配信、および、端末の利用状況を考慮したなコンテンツ配信が実現できる。
【発明を実施するための最良の形態】
【００２６】
以下、本発明の実施例を図面を用いて説明する。ただし、本発明の適用は本実施例に限定されない。なお、本発明で説明しているコンテンツとは、映像や音声や文字情報などのいくつかのメディアで構成する番組情報を想定して説明する。
【００２７】
図１は本発明を実施するための基本的なシステム構成図である。
インターネット１５０を中心として、サーバ１００およびクライアント１２０,１３０,１３１,１４０が接続されている。
【００２８】
サーバ１００は、演算部１０７を中心として、ネットワークを用いて他の機器、特にクライアントと通信を行うための通信部１０８、クライアントを管理するクライアント管理部１０３、コンテンツを管理するコンテンツ管理部１０６、および配信状況を管理する配信管理部１１０から構成される。
【００２９】
ここで、クライアント管理部１０３では、クライアントと認証を行うための認証情報１０１と、クライアントとの通信状況を記録する通信情報１０２と、コンテンツへの課金状況を記録する課金情報１０４とを管理している。
【００３０】
図２はクライアントの認証情報１０１の一例の説明図である。認証情報は、クライアントのＩＤ（管理番号）と予め定めたクライアントに一意の識別子、クライアントの所有者とその住所および連絡先などが記載されている。
【００３１】
図３は通信情報１０２の一例の説明図である。通信情報には、前述のクライアントＩＤに結び付けて、クライアントのアドレスおよびネットワークポート、および、当該クライアントがサーバと通信した際の経路情報やその際の回線速度を記録する。
【００３２】
以下の処理では、これらのアドレスやポート番号はそれぞれのクライアントとの通信に用いる情報とする。また、経路情報の検出は、経路上のルータを検出する「tracert」等の一般的なコマンドを用いることができる。また、回線速度はクライアントとサーバが行った通信に際しての、送信または受信したデータサイズとそれらにかかった時間から平均値として算出することができる。
【００３３】
なお、この説明ではＩＰｖ４（Internet Protocol version ４）の様式にて記載しているが、IPv６や電話回線など、他の方式であっても良い。
【００３４】
図４は課金情報１０４の一例の説明図である。課金情報には、前述のクライアントIDに結び付けて、支払い方法及び名義人、配信済みのコンテンツＩＤ、および、コンテンツの配信サービスあるいは配信されたコンテンツを再生視聴したことにより発生するクライアントへの課金額などを記録する。
【００３５】
なお、これらクライアント管理部１０３が管理する各種情報は、ハードディスク等の記録メディアを用いて記録され、クライアント管理部が管理するメモリ上に読み込まれても良い。
【００３６】
コンテンツ管理部１０６では、コンテンツデータおよび付随する情報から構成するコンテンツ情報１０５を管理する。図５はコンテンツ情報１０５の説明図である。コンテンツ情報は、コンテンツのＩＤ（管理番号）と、コンテンツのフォーマットや内容等の説明情報、コンテンツデータ、および、コンテンツのサイズやコンテンツの完全性を保証するために用いるチェックサム情報、インターネット等の通信路にて悪意の第３者から保護するためＲＳＡ暗号技術などを用いて暗号化されたコンテンツを解読して再生するための鍵情報、そしてコンテンツの配信サービスあるいは配信されたコンテンツを再生視聴したことにより発生する料金などを記録する。また、コンテンツ情報１０５はコンテンツデータを蓄積している蓄積部ともいえる。
【００３７】
なお、これら各種情報は、ハードディスク等の記録メディアを用いて記録され、コンテンツ管理部１０６が管理するメモリ上に読み込まれても良い。また、コンテンツデータと、コンテンツデータを説明するデータ（メタデータ）としていくつかに分けて管理しても良い。また、コンテンツデータを保有するサーバと、コンテンツデータのコンテンツ情報を保有するサーバとが別のサーバであってもよい。すなわち、サーバ１００はコンテンツデータは保有せず、コンテンツデータのコンテンツ情報を用いて後述するコンテンツの配信の管理を行なうサーバであってもよい。
【００３８】
配信管理部１１０では、コンテンツ配信を行ったコンテンツ保有クライアント情報１０９を管理する。図６はコンテンツ保有クライアント情報１０９の説明図である。コンテンツ保有クライアント情報は、前述のコンテンツIDに対応させて、既にコンテンツを配信したクライアントのＩＤを記載する。
【００３９】
次にクライアント１２０,１３０,１３１,１４０について説明する。本発明でのクライアントは、配信済クライアント１２０,１３０,１３１と未配信クライアント１４０に分けて説明する。ただし、クライアントはＰ２Ｐ型配信で言うクライアントとしてもサーバとしても動作するサーブレット（servelet）として動作するため、あるコンテンツに対しては未配信クライアントの動作を行っても、別のコンテンツに対しては配信済クライアントの動作を行っても良い。
【００４０】
また、それぞれのクライアントのブロック構成は同じであるとするが、以後説明するそれぞれにおける処理ステップを行うことができれば必ずしも同じ構成でなくてもよい。例えば、クライアントがＰＣ等の汎用機器や、ＴＶ等の特定機器として構成されていてもよい。
【００４１】
配信済クライアント１２０,１３０,１３１（以下便宜的に代表して１２０について説明する）は、演算部１２５を中心として、クライアント機器を識別するために予め設定された識別子１２１、ネットワークを用いて他の機器と通信を行うための通信部１２４、コンテンツを管理するコンテンツ管理部１２２、およびユーザへ表示を行う表示部１２６、ユーザからの指示を受ける入力部１２７及びクライアントの設定部１２８から構成する。
【００４２】
未配信クライアント１４０も同様に、演算部１４５、識別子１４１、通信部１４４、コンテンツ管理部１４２、および表示部１４６、入力部１４７及びクライアントの設定部１４８から構成する。
【００４３】
なお、上記表示部は必ずしもディスプレイ等である必要はなく、当該クライアント機器と別体のディスプレイ等に表示するデータを出力する出力部であってもよい。
【００４４】
それぞれのクライアントが持つコンテンツ管理部１２２,１４２ではコンテンツ情報１２３,１４３を管理する。このコンテンツ情報は、サーバでのコンテンツ情報１０５,図５と同様の形式であるとし、それぞれのクライアントが既に配信を受けたコンテンツに関しての各種情報が管理される。図７はそれぞれのクライアントが持つ識別子１２１,１４１の説明図である。識別子は、予め定める方式による、クライアントの一意性を保証するための記号列であり、図のようにクライアントのＩＤと対応付けて保持しても良い。
【００４５】
次に、サーバ１００、配信済クライアント１２０,１３０,１３１、および、未配信クライアント１４０での動作を説明する。図８および図９はサーバ１００、配信済クライアント１２０,１３０,１３１、および、未配信クライアント１４０における処理フローの説明図である。以下、それぞれの処理を時間を追って説明する。なお、各処理はサーバあるいはクライアントの演算部において主に処理され、それぞれに接続された各部と連携して実行されるとする。また、通信はサーバ、クライアントともに通信部を用い、インターネットを経由して行われるが、以下便宜上、説明を割愛する。
【００４６】
まず、配信済クライアントではサーバからコンテンツを配信（ステップ８２１）されたコンテンツを保存している（ステップ８０１）。
【００４７】
次に、配信済クライアントでは、本発明を用いたＰ２Ｐ型配信によるサーバの代理としての配信を行うかどうかのユーザ意思を確認するため、代理配信受入れ設定を行う（ステップ８０２）。図１０は代理配信受入れの表示画面の一例である。図のような表示を配信済クライアントの表示部１２６を用いて、サーバの代理での他ユーザ（未配信クライアントのユーザ）からの配信要求の設定を求め、リモコンや操作パネル、マウス等の入力部１２７より指示を受ける。なお、この代理配信受入れ設定は、クライアントの設定１２８に記録する。
【００４８】
次に、コンテンツ配信について説明する。まず、サーバ１００からコンテンツ情報１０５のうち、鍵情報やチェックサム等の一部の情報を除いて、配信可能なコンテンツの情報（例えばコンテンツのタイトル、内容の説明、出演者の名前等の情報）を未配信クライアント１４０に配信する（ステップ８２２,８４１）。
【００４９】
未配信クライアントでは、配信されたコンテンツ情報を基に、表示部１４６および入力部１４７を用いて、サーバが配信可能なコンテンツのうちからユーザが配信を所望するコンテンツを選択する（ステップ８４２）。図１１はコンテンツ選択の表示画面の一例の説明図である。配信されたコンテンツ情報のうち、ユーザに必要な内容等の表示を行い、配信を所望するコンテンツに対してチェックを入れることで選択を行う（ステップ８４２）。
【００５０】
ここで、すべてのコンテンツを表示し選択させるのではなく、ジャンルやキーワードによる絞込み検索を行えるようにしてもよい。また、この検索処理はサーバにて行い、その結果をクライアントに送信することにしてもよい。また、図１１では配信を所望するコンテンツに対してチェックを入れることで選択が行われているが、必ずしもこれに限定されるわけではなく、選択されたコンテンツの表示の色が変わる等、他の方法で選択が行なわれてもよい。
【００５１】
次に、選択されたコンテンツ、図１１の場合にはコンテンツＩＤ”１００００１”をサーバに伝達するために、サーバとの接続を確立し（ステップ８４３,８２３）、クライアントの認証を行う（ステップ８２４,８４４）。なお、ステップ８２４,８４４で認証に失敗した場合は、当該クライアントは配信サービスを受けられず、処理をここで打ち切り終了してもよい。または、例えば、解像度など質が劣るコンテンツを配信するようサーバ側で変更する等により受けられる配信サービスを制限するようにしてもよい。または、例えば認証を受けるための正規クライアントおよび正規ユーザとしてサーバへの入会や登録を促すためのコンテンツの配信や案内を表示してもよい。
【００５２】
認証には、未配信クライアントが持つ識別子１４１をサーバに伝達し、サーバの認証情報１０１を用いてクライアント管理部が照合し、結果を未配信クライアントに送付する。認証された未配信クライアントは次にコンテンツIDを用いて配信要求をサーバに伝達する（ステップ８４５,８２５）。
【００５３】
サーバでは、コンテンツ保有クライアント情報１０９から配信管理部が当該コンテンツに対応するクライアントＩＤを取得し（ステップ８２６）、それに基づいてクライアント管理部１０３にて通信情報１０２から情報を入手する（ステップ８２７）。この際、未配信クライアントに関しても入手する。
【００５４】
次に、入手した各配信済クライアントの通信情報から、クライアントの優先度を算出しその優先度の高い順に並べる（ステップ８２８）。
【００５５】
ここで、優先度の計算について説明する。図１２は優先度の計算フローの説明図である。まず、優先度を初期化し（ステップ１２０１）、未配信クライアント及び対象となるひとつの配信済クライアントの通信情報を取得する。
【００５６】
未配信クライアントのうちの予め定めた定数Ｎ番目までの経路のうち、ｎ番目と配信済クライアントの経路を比較し（ステップ１２０３）、同一の経路が含まれる場合（ステップ１２０３でＹｅｓの場合）には優先度に対して１/２のｎ乗を掛け合わせる（ステップ１２０４）。すなわち、未配信クライアントと配信済クライアントとの間にルータが一つ増える度に優先度を１/２にする。
【００５７】
また、Ｎ番目位以内に経路重複が無い場合（ステップ１２０３でＮｏの場合）には１/２のＮ乗を優先度に掛け合わせる（ステップ１２０５）。さらに、未配信クライアントに向かう回線の速度を評価するよう、未配信クライアントの下り回線の速度、および、対象の配信済クライアントの上り回線の速度を優先度に掛け合わせる（ステップ１２０６）。
【００５８】
また、後ほど取得する、対象の配信済クライアントの今後Ｍ（予め定義された定数）時間の間に予定されている、録画や視聴、配信等の既存の予約状態があるかどうかを評価し（ステップ１２０７）、ｍ時間内に予約がある場合（ステップ１２０７でＹｅｓの場合）には優先度に１/２の（Ｍ−ｍ）乗を掛け合わせる（ステップ１２０８）。
【００５９】
すなわち、直近に予約がある場合には優先度が低くなるように計算に加える。今後Ｍ時間の間の予定を取得していない場合や今後Ｍ時間の間に予約がない場合（ステップ１２０７でＮｏの場合）、予約による優先度操作は行わないとする。
【００６０】
このようにして、優先度を入手したすべての配信済クライアントに対して求め、優先度の高い順にリストを作成する（ステップ８２８）。図１３はこの配信済みクライアントの優先リストの例である。算出した優先度をキーにして、高い順に並べることで、以下のステップを続ける際にネットワーク構築上より合理的な順に配信済クライアントを順に評価する。
【００６１】
図８の説明に戻り、以下のフローの説明を続ける。優先度の順に配信済クライアントをひとつ選定し折衝を開始するが、リストがない、あるいは最後まで折衝したが適切な代理サーバがないと判断した場合には（ステップ８３０でＮｏの場合）、サーバが未配信コンテンツに対してコンテンツを配信する（ステップ８３１，８４６および、図９ステップ９３０,９６０）。ここで折衝とは、単純にネットワーク経由での接続を試みること、あるいは、その時点での接続により検出できる優先度計算に用いた各種情報に差異があり、優先度の再計算結果が以前の優先度より低い場合に、リスト以降にあるクライアントの優先度とそれぞれ比較してこのクライアントとの接続を行わないような判断をすること等を意味する。またこの際、新たな各種情報により当該クライアント情報の更新を行ってもよい。
【００６２】
リストから配信済クライアントが入手できた場合（ステップ８３０でＹｅｓの場合）には、サーバから配信済クライアントに接続を試みる（ステップ８３２,８０３）。
【００６３】
接続を確立した後認証を行うために、配信済クライアントの識別子１２１とサーバの認証情報１０１を用いてクライアント管理部１０３が照合し、結果を配信済クライアントに送付する（ステップ８０４,８３３）。
【００６４】
次に、前述のように設定された代理配信の受入れ設定から、未配信クライアントのユーザの意思を伝達する（ステップ８３４,８０５）。もし受入れ意思が無い場合（ステップ８３５でＮｏの場合）には、対象配信済クライアントとの接続を終了し（ステップ８３８,８０７）、次の優先度を持つリスト上の配信済クライアントに対象を移し、同様に評価する（ステップ８２９〜８３５）。
【００６５】
また、前述のステップ８０２のユーザ意思の確認設定の代わりに、ステップ８０５でユーザ意思を入力してもよい。この際には図１０の画面に準じてもよいし、図１４のように同時に要求された代理配信をまとめて表示し、ユーザの意思を確認してもよい。図１４では、要求案件ごとに、コンテンツのタイトル、および、要求した未配信クライアントのＩＤ、そして、許可するかどうかのフラグを表示する。そして、ユーザは入力部を用いてこの許可フラグを設定し、フラグ状態を表示する。これらフラグは、すべてを許可１４０２、あるいは、すべてを拒否１４０３するために、同時に設定するボタンを設けてもよい。この際、ユーザの代理配信を促すために、ポイントによるユーザ優遇サービスを行ってもよく、前述の要求案件ごとに付与ポイントを予め定義し、代理配信の許可を行い実際に代理配信を行った際に、各クライアントに対してポイントを付与する。付与された累積ポイントは画面１２６上に表示し１４０１、必要に応じてユーザが確認することができる。なお、各クライアントのポイントはサーバにて管理してもよい。このポイントに基づくユーザ優遇サービスとは、例えばポイントによりコンテンツ視聴の価格から予め設定した条件により割引したり、最終的な利用料請求からの割引や、他のサービスを受ける際の条件として用いたりしてもよい。
【００６６】
なお、ステップ８０２の代理配信受け入れ設定では、これらのユーザの受入れ意思を予め条件として設定しておき、それら条件に該当するかどうかを判断し半自動化してもよい。例えば、図１５のような画面により、代理配信を行う未配信クライアント毎に条件を追加していき１５０１、それぞれのクライアント毎に「いつも許可」１５０２や「いつも拒否」１５０３、「毎回確認」１５０４をそれぞれのボタンにより設定する。この際、クライアントＩＤの設定には、ユーザがＩＤを入力部より適宜してもよいし、配信要求があった際の図１０などの意思表示画面において適宜ボタンを用意し、該当要求を行ったクライアントＩＤを保持しながら画面遷移をして設定してもよい。「毎回確認」１５０４を設定した場合には、該当クライアントから配信要求があった場合に図１０のような画面でユーザからの操作を行うようにし、「いつも許可」１６０２や「いつも拒否」１６０３設定していた場合にはこれを省いて許可・拒否をすることで半自動的に意思伝達を実現する。また、図１６のような画面により、コンテンツ毎に条件を追加していき１６０１、「いつも許可」１６０２や「いつも拒否」１６０３、「毎回確認」１６０４を設定してもよい。この際、コンテンツまたはそのＩＤの設定はユーザがＩＤを入力部より適宜してもよいし、配信要求があった際の図１０などの意思表示画面において適宜ボタンを用意し、該当要求のあったコンテンツＩＤを保持しながら画面遷移をして設定してもよい。「毎回確認」１６０４を設定した場合には、該当コンテンツの配信要求があった場合に図１０のような画面でユーザからの操作を行うようにし、「いつも許可」１６０２や「いつも拒否」１６０３設定していた場合にはこれを省いて許可・拒否をすることで半自動的に意思伝達を実現する。
【００６７】
受入れ意思があるユーザの配信済クライアントであった場合（ステップ８３５でＹｅｓの場合）には、指定された先までの予約状況を問い合わせ（ステップ８３５,８３６）、予約状況を加味した優先度を再度計算する（ステップ８３７）。ここでの優先度の計算は上述した図１２に示すフローにより行われる。
【００６８】
求めた優先度が予め定めた閾値を超えていない場合（ステップ８３９でＮｏの場合）、対象となる配信済クライアントとの接続を終了し、（ステップ８３８,８０７）、次の優先度を持つリスト上の配信済クライアントに対象を移し、同様に評価する（ステップ８２９〜８３５）。これらを優先度リストのすべてで評価していくことにより、適切な配信済クライアントが選択され、適切な配信済クライアントが無い場合にはサーバが選択される。
【００６９】
優先度が予め定めた閾値を超えていた場合（ステップ８３９でＹｅｓの場合）、当該配信済クライアントがコンテンツ配信を行う配信済クライアントとして決定する。
【００７０】
図９にて、コンテンツ配信を行う配信済クライアントが決定し、その後の実際のコンテンツ配信が行われるフローについて説明する。
【００７１】
既に未配信クライアントおよび配信済クライアントが認証済みであるので、配信済クライアントに対して未配信クライアントを保証するための通信を行う（ステップ９２１,９０１）。また、未配信クライアントに対して、配信済クライアントの保証となる、リダイレクト指示を伝達する（ステップ９２２,９４１）。なお、リダイレクトとは、サーバが配信する代わりに、配信済クライアントのひとつを選択することで代理サーバとなるようにする処理である。
【００７２】
これらにより、配信済クライアントと未配信クライアントとは、サーバにより互いの保証をされ、ファイヤウォールを超えた通信を行うことができる設定等、それぞれの通信設定を開始する。
【００７３】
次に、未配信クライアントと配信済クライアントとの間で接続要求が送受信され、（ステップ９４２,９０２）、その後所望のコンテンツの配信要求を伝達する（ステップ９４３,９０３）。これにより、配信済クライアントから未配信クライアントに対してコンテンツが配信され、未配信クライアントはコンテンツを保存する（ステップ９０４,９４４）。
【００７４】
コンテンツの配信が終了すると、両者間の接続を終了し（ステップ９０５,９４５）、通信設定も終了する（ステップ９０６,９４６）。
【００７５】
次に、コンテンツが正しく配信されたかどうかの検証について説明する。すなわち、未配信クライアントでは、配信中から、あるいは配信後に、コンテンツの一意性や完全性を検証するための情報、例えばコンテンツのサイズやチェックサム（バイナリデータを頭から加算した際の和のうち、指定されたバイトの値）を用いて、これをサーバのコンテンツ情報内のデータと照合することで実現する（ステップ９４７,９２３）。
【００７６】
例えば、配信されたコンテンツのコンテンツサイズとサーバのコンテンツ情報内の当該コンテンツのサイズとを比較し、一致しなければ完全性が否定され、コンテンツは正しく配信されなかったと判断してもよい。なお、コンテンツのサイズの一致の判断は、完全に一致することを条件としてもよいが、コンテンツサイズの不一致の程度が所定の範囲内であれば一致と判断するようにしてもよい。
【００７７】
また、例えば配信されたコンテンツのチェックサムとサーバのコンテンツ情報内の当該コンテンツのチェックサムとを比較し、一致しなければ配信されたコンテンツとサーバのコンテンツ情報が示すコンテンツとは異なるものであるとして一意性が否定され、コンテンツは正しく配信されなかったと判断してもよい。
【００７８】
なお、照合に用いる情報は、例えばパリティやＣＲＣ（Ciclic Redundancy Check）やＭＤ５（Message Digest Algorithm５）などのハッシュ、その他の技術による検証であってもよい。
【００７９】
これによりコンテンツの一意性、完全性を確保し、未配信クライアントのユーザに対するコンテンツの保証が行われる。なお、この後、サーバのコンテンツ管理部１０３およびクライアント管理部１０６により課金情報１０４の更新などの課金処理を行うことになるが、配信完了をもって課金するか、あるいは、ユーザが視聴再生を行ったときに課金するかは適宜設定すればよい。
【００８０】
上記によりコンテンツが正しく配信されたと判断された場合（ステップ９２４、９４８）、サーバでは接続の際に得られた配信済クライアント、および、未配信クライアントの経路情報や回線速度等（図３）の各種情報を更新記録し（ステップ９２５）、サーバ、未配信クライアントともに処理を終了する。なお、正しく配信されたと判断されなかった場合には、再度コンテンツの配信と保存を行い（ステップ９３０、９６０）、コンテンツの一意性と完全性を確認する処理を行う。なお、あらかじめ配信と保存を再度行う回数を定め、その回数に達した場合には接続の経路上、あるいは、サーバおよび両クライアント装置に異状が無いかの調査を行い、その回復を行った後再度配信と保存を行ってもよい。
【００８１】
なお、これまでに説明した識別子は、外部からの盗用、なりすまし等の悪用をされないよう、暗号化や異常時の自己破壊などの適切な手段で保管されることが望まれる。また、サーバやクライアントが持つ通信部による相互の通信は、他技術、例えばＳＳＬ（Secure Socket Layer）等の技術を用いるなどして、相互信頼と外部の悪用を防止した通信を行うためのデータ暗号化を行うことも望まれる。
【００８２】
また、本発明で説明しているコンテンツとは、映像や音声や文字情報などのいくつかのメディアで構成する番組情報を想定して説明を行ったが、これに留まらず、ＰＣ（パーソナルコンピュータ）等で用いられるファイル、実行可能なオブジェクトデータ、メール、ＷＷＷ（World Wide Web）により送受されるマークアップ記述や動作記述を行うスクリプト、その他にもネットワークを用いて伝送が行われる一般的電子データであってもよい。したがって、ネットワークを用いた多くの産業で汎用的に用いられる可能性がある。
【図面の簡単な説明】
【００８３】
【図１】システム構図の一例
【図２】認証情報１０１の一例
【図３】通信情報１０２の一例
【図４】課金情報１０４の一例
【図５】コンテンツ情報１０５の一例
【図６】コンテンツ保有クライアント情報１０９の一例
【図７】クライアントが持つ識別子１２１,１４１の一例
【図８】サーバ、配信済クライアント、及び未配信クライアントの処理フローの一例
【図９】サーバ、配信済クライアント、及び未配信クライアントの処理フローの一例
【図１０】代理配信受入れの表示画面の一例
【図１１】コンテンツ選択の表示画面の一例
【図１２】優先度の計算フローの一例
【図１３】配信済みクライアントの優先リストの一例
【図１４】代理配信受入れの表示画面（まとめて表示）の一例
【図１５】代理配信対象クライアント条件の一例
【図１６】代理配信対象コンテンツ条件の一例
【符号の説明】
【００８４】
１００サーバ
１０１認証情報
１０２通信情報
１０３クライアント管理部
１０４課金情報
１０５コンテンツ情報
１０６コンテンツ管理部
１０７演算部
１０８通信部
１０９コンテンツ保有クライアント情報
１１０配信管理部
１２０１３０１３１配信済クライアント
１２１識別子
１２２コンテンツ管理部
１２３コンテンツ情報
１２４通信部
１２５演算部
１２６表示部
１２７入力部
１２８設定情報
１４０未配信クライアント
１４１識別子
１４２コンテンツ管理部
１４３コンテンツ情報
１４４通信部
１４５演算部
１４６表示部
１４７入力部
１４８設定情報
１５０インターネット
【特許請求の範囲】
【請求項１】
コンテンツを有する第１の端末から当該コンテンツを第２の端末に配信する配信方法であって、
前記第２の端末はサーバに前記コンテンツの配信を要求するコンテンツ配信要求情報を送信し、
前記サーバは前記第２の端末から前記第１のコンテンツ配信要求情報を受信すると、前記第２の端末に前記第１の端末へのコンテンツ配信要求情報の送信を指示するリダイレクト指示を送信し、
前記第２の端末は前記サーバからリダイレクト指示を受信すると前記第１の端末にコンテンツ配信要求情報を送信し、
前記第１の端末は前記第２の端末からコンテンツ配信要求情報を受信すると前記第２の端末に前記コンテンツを配信する配信方法。
【請求項２】
請求項１の配信方法であって、
前記サーバは前記第２の端末にコンテンツが正しく配信されたか否かの検証を行なう配信方法。
【請求項３】
請求項１の配信方法であって、
前記サーバは複数の端末から前記第１の端末を選択する配信方法。
【請求項４】
請求項３の配信方法であって、
前記サーバは、前記複数の端末と前記第２の端末との経路、前記複数の端末の回線速度、前記第２の端末の回線速度に基づいて前記複数の端末から前記第１の端末を選択する配信方法。
【請求項５】
通信回線を介して情報を送受信する通信部と、
通信回線を介して接続する端末を管理する端末管理部と、
コンテンツを配信した端末の情報を管理する配信管理部と、
前記通信部を介して第１の端末からコンテンツを配信する要求を受信すると、前記配信管理部で管理する端末の情報、及び前記端末管理部で管理する端末の情報に基づいて第２の端末を選択し、前記第１の端末に前記第２の端末へのコンテンツを配信する要求の送信を指示するリダイレクト指示を送信する演算部とを有するサーバ。
【請求項６】
請求項５のサーバであって、
コンテンツの情報を管理するコンテンツ管理部を有し、
前記演算部は前記コンテンツ管理部が管理するコンテンツの情報に基づいて、前記第２の端末から前記第１の端末へ配信されたコンテンツが正常であるか否かの検証を行なうサーバ。
【請求項７】
通信回線を介して情報を送受信する通信部と、
前記通信回線を介して配信されたコンテンツを蓄積する蓄積部と、
コンテンツの配信を要求する情報を前記通信部を介してサーバに送信し、当該サーバから他の端末へ当該コンテンツの配信を要求する情報を送信する指示を受信し、当該他の端末へ当該コンテンツの配信を要求する情報を送信する演算部とを有する受信端末。
【請求項８】
請求項７の受信端末であって、
前記演算部は、前記他の端末から配信されたコンテンツが正常であるか否かの検証を要求する情報を前記通信部を介して前記サーバに送信する受信端末。
【請求項１】
コンテンツを有する第１の端末から当該コンテンツを第２の端末に配信する配信方法であって、
前記第２の端末はサーバに前記コンテンツの配信を要求するコンテンツ配信要求情報を送信し、
前記サーバは前記第２の端末から前記第１のコンテンツ配信要求情報を受信すると、前記第２の端末に前記第１の端末へのコンテンツ配信要求情報の送信を指示するリダイレクト指示を送信し、
前記第２の端末は前記サーバからリダイレクト指示を受信すると前記第１の端末にコンテンツ配信要求情報を送信し、
前記第１の端末は前記第２の端末からコンテンツ配信要求情報を受信すると前記第２の端末に前記コンテンツを配信する配信方法。
【請求項２】
請求項１の配信方法であって、
前記サーバは前記第２の端末にコンテンツが正しく配信されたか否かの検証を行なう配信方法。
【請求項３】
請求項１の配信方法であって、
前記サーバは複数の端末から前記第１の端末を選択する配信方法。
【請求項４】
請求項３の配信方法であって、
前記サーバは、前記複数の端末と前記第２の端末との経路、前記複数の端末の回線速度、前記第２の端末の回線速度に基づいて前記複数の端末から前記第１の端末を選択する配信方法。
【請求項５】
通信回線を介して情報を送受信する通信部と、
通信回線を介して接続する端末を管理する端末管理部と、
コンテンツを配信した端末の情報を管理する配信管理部と、
前記通信部を介して第１の端末からコンテンツを配信する要求を受信すると、前記配信管理部で管理する端末の情報、及び前記端末管理部で管理する端末の情報に基づいて第２の端末を選択し、前記第１の端末に前記第２の端末へのコンテンツを配信する要求の送信を指示するリダイレクト指示を送信する演算部とを有するサーバ。
【請求項６】
請求項５のサーバであって、
コンテンツの情報を管理するコンテンツ管理部を有し、
前記演算部は前記コンテンツ管理部が管理するコンテンツの情報に基づいて、前記第２の端末から前記第１の端末へ配信されたコンテンツが正常であるか否かの検証を行なうサーバ。
【請求項７】
通信回線を介して情報を送受信する通信部と、
前記通信回線を介して配信されたコンテンツを蓄積する蓄積部と、
コンテンツの配信を要求する情報を前記通信部を介してサーバに送信し、当該サーバから他の端末へ当該コンテンツの配信を要求する情報を送信する指示を受信し、当該他の端末へ当該コンテンツの配信を要求する情報を送信する演算部とを有する受信端末。
【請求項８】
請求項７の受信端末であって、
前記演算部は、前記他の端末から配信されたコンテンツが正常であるか否かの検証を要求する情報を前記通信部を介して前記サーバに送信する受信端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２００９−１２９３８６（Ｐ２００９−１２９３８６Ａ）
【公開日】平成２１年６月１１日（２００９．６．１１）
【国際特許分類】
【出願番号】特願２００７−３０６７５１（Ｐ２００７−３０６７５１）
【出願日】平成１９年１１月２８日（２００７．１１．２８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２１年６月１１日（２００９．６．１１）
【国際特許分類】
【出願日】平成１９年１１月２８日（２００７．１１．２８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]