(57)【要約】      （修正有）【課題】課金に関する処理の集中を回避することを可能としたノード装置、情報送信処理プログラム、及び情報配信方法等を提供する。【解決手段】ユーザノード１ａは、コンテンツ購入申込みメッセージを送信し、このメッセージは当該コンテンツに最も近いものを有するルートノード１ｘに到着し、このノードは、当該コンテンツ保存のコンテンツホルダノード１ｂに転送し、コンテンツホルダノード１ｂは、ユーザノード１ａに対応する提供可否関連情報を保存のアクセス権管理ノード１ｙ１〜１ｙ１０に対し、当該コンテンツ提供可否を確認するための購入登録メッセージを送信し、アクセス権管理ノード１ｙ１〜１ｙ１０は、当該ユーザＩＤに対応の提供可否関連情報を参照して購入可能と判別した場合、ユーザのプール金額を更新し、コンテンツホルダノード１ｂに購入可否メッセージを返信し、コンテンツホルダノード１ｂは、ユーザノード１ａに回答情報を送信する。【選択図】図７
2006185171.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して互いに通信可能な複数のノード装置を備えた情報配信システムであって、配信情報が１以上の前記ノード装置に保存され、かつ、前記配信情報の提供可否に関連する提供可否関連情報であって夫々の前記ノード装置に対応する前記提供可否関連情報が、他の前記ノード装置に分散保存されている情報配信システムに含まれる前記ノード装置であって、
他の前記ノード装置から前記ネットワークを介して送信されてきた前記配信情報の提供要求を示す要求情報を受信する要求情報受信手段と、
前記受信された要求情報の送信元である前記ノード装置に対応する前記提供可否関連情報を保存している前記ノード装置に対して、当該配信情報の提供可否を前記ネットワークを介して確認する提供可否確認手段と、
前記要求情報の送信元である前記ノード装置に対して、前記確認された提供可否に基づく回答情報を前記ネットワークを介して送信する提供可否情報送信手段と、
を備えることを特徴とするノード装置。
【請求項２】
請求項１に記載のノード装置において、
前記要求情報の送信元である前記ノード装置に対応する前記提供可否関連情報は、複数の前記ノード装置に保存されており、
前記提供可否確認手段は、前記提供可否関連情報を保存している前記複数のノード装置に対して、当該配信情報の提供可否を前記ネットワークを介して確認し、当該確認された複数の提供可否に基づいて当該配信情報の提供可否を決定し、
前記提供可否送信手段は、前記要求情報の送信元である前記ノード装置に対して、前記決定された提供可否に基づく回答情報を前記ネットワークを介して送信することを特徴とするノード装置。
【請求項３】
請求項１又は２に記載のノード装置において、
前記提供可否確認手段は、前記提供可否関連情報を保存している前記ノード装置に対して、前記配信情報の提供可否を確認するための確認情報を送信し、当該確認情報に応じて返信されてきた当該配信情報の提供可否に基づく回答情報を受信することによって、前記配信情報の提供可否を確認することを特徴とするノード装置。
【請求項４】
請求項３に記載のノード装置において、
前記複数のノード装置のうち、前記決定された配信情報の提供可否と異なる回答情報を返信した前記ノード装置に対して、前記提供可否関連情報の修正要求を示す修正要求情報を送信する修正要求情報送信手段を更に備えることを特徴とするノード装置。
【請求項５】
請求項２乃至４の何れか一項に記載のノード装置において、
前記要求情報には、当該要求情報の送信元である前記ノード装置に対応する前記第１識別情報が含まれており、
前記提供可否確認手段は、前記要求情報に含まれる前記第１識別情報に基づいて、互いに異なる複数の第２識別情報を生成し、夫々の前記第２識別情報に対応する夫々の前記ノード装置に対して、前記配信情報の提供可否を確認することを特徴とするノード装置。
【請求項６】
ネットワークを介して互いに通信可能な複数のノード装置を備えた情報配信システムであって、配信情報が１以上の前記ノード装置に保存され、かつ、前記配信情報の提供可否に関連する提供可否関連情報であって夫々の前記ノード装置に対応する前記提供可否関連情報が、他の前記ノード装置に分散保存されている情報配信システムに含まれる前記ノード装置であって、
任意の前記ノード装置から前記ネットワークを介して送信されてきた当該配信情報の提供可否を確認するための確認情報を受信する確認情報受信手段と、
前記受信された確認情報に関わる配信情報の提供が可能か否かを前記提供可否関連情報を参照して判別する提供可否判別手段と、
前記確認情報を送信した前記ノード装置に対して、前記判別された提供可否に基づく回答情報を前記ネットワークを介して返信する提供可否情報返信手段と、を備えることを特徴とするノード装置。
【請求項７】
請求項６に記載のノード装置において、
前記提供可否判別手段により、前記配信情報の提供が可能と判別された場合には、前記提供可否関連情報を更新する提供可否関連情報更新手段を更に備えることを特徴とするノード装置。
【請求項８】
請求項６又は７に記載のノード装置において、
請求項３に記載のノード装置から前記ネットワークを介して送信されてきた前記修正要求情報を受信する修正要求情報受信手段と、
前記受信された修正要求情報に基づいて、前記提供可否関連情報を修正する提供可否関連情報修正手段と、を更に備えることを特徴とするノード装置。
【請求項９】
請求項１乃至８の何れか一項に記載のノード装置において、
前記提供可否関連情報には、前記配信情報の提供に対して課金を行うために必要な課金情報が含まれていることを特徴とするノード装置。
【請求項１０】
ネットワークを介して互いに通信可能な複数のノード装置を備えた情報配信システムであって、配信情報が１以上の前記ノード装置に保存され、かつ、前記配信情報の提供可否に関連する提供可否関連情報であって夫々の前記ノード装置に対応する前記提供可否関連情報が、他の前記ノード装置に分散保存されている情報配信システムに含まれるコンピュータを、
他の前記ノード装置から前記ネットワークを介して送信されてきた前記配信情報の提供要求を示す要求情報を受信する要求情報受信手段、
前記受信された要求情報の送信元である前記ノード装置に対応する前記提供可否関連情報を保存している前記ノード装置に対して、当該配信情報の提供可否を前記ネットワークを介して確認する提供可否確認手段、及び、
前記要求情報の送信元である前記ノード装置に対して、前記確認された提供可否に基づく回答情報を前記ネットワークを介して送信する提供可否情報送信手段として機能させることを特徴とする情報送信処理プログラム。
【請求項１１】
ネットワークを介して互いに通信可能な複数のノード装置を備えた情報配信システムであって、配信情報が１以上の前記ノード装置に保存され、かつ、前記配信情報の提供可否に関連する提供可否関連情報であって夫々の前記ノード装置に対応する前記提供可否関連情報が、他の前記ノード装置に分散保存されている情報配信システムに含まれるコンピュータを、
前記配信情報の保存元である前記ノード装置から前記ネットワークを介して送信されてきた当該配信情報の提供可否を確認するための確認情報を受信する確認情報受信手段、
前記受信された確認情報に関わる配信情報の提供が可能か否かを前記提供可否関連情報を参照して判別する提供可否判別手段、及び、
前記確認情報を送信した前記ノード装置に対して、前記判別された提供可否に基づく回答情報を前記ネットワークを介して返信する提供可否情報返信手段として機能させることを特徴とする情報送信処理プログラム。
【請求項１２】
請求項１０又は１１に記載の情報送信処理プログラムがコンピュータ読み取り可能に記録されていることを特徴とする記録媒体。
【請求項１３】
ネットワークを介して互いに通信可能な複数のノード装置を備えた情報配信システムであって、配信情報が１以上の前記ノード装置に保存され、かつ、前記配信情報の提供可否に関連する提供可否関連情報であって夫々の前記ノード装置に対応する前記提供可否関連情報が、他の前記ノード装置に分散保存されている情報配信システムにおける情報配信方法であって、
前記配信情報の保存元である前記ノード装置が、他の前記ノード装置から前記ネットワークを介して送信されてきた当該配信情報の提供要求を示す要求情報を受信し、当該要求情報の送信元である前記ノード装置に対応する前記提供可否関連情報を保存している前記ノード装置に対して、当該配信情報の提供可否を確認するための確認情報を送信する工程と、
前記提供可否関連情報を保存している前記ノード装置が、前記確認情報を受信し、当該確認情報に関わる配信情報の提供が可能か否かを前記提供可否関連情報を参照して判別し、当該判別された提供可否に基づく回答情報を、前記確認情報を送信した前記ノード装置に対して前記ネットワークを介して返信する工程と、
前記配信情報の保存元である前記ノード装置が、前記提供可否に基づく回答情報を受信し、当該提供可否に基づく回答情報を、前記要求情報の送信元である前記ノード装置に対して前記ネットワークを介して送信する工程と、
を備えることを特徴とする情報配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して互いに接続された複数のノード装置を備えたピアツーピア（Peer to Peer（P2P））型の情報配信システム及び方法等に関し、例えば、コンテンツデータが１以上のノード装置に保存されたコンテンツ配信システム及び方法等の技術分野に関する。
【背景技術】
【０００２】
従来から、広く知られているクライアント−サーバ型のコンテンツ配信システムでは、一般に、認証サーバを用いて（つまり、課金サーバとして）、クライアント（ユーザ）毎の認証、課金を管理している。或いは、ダイヤルアップ接続での認証に用いられるRadiusサーバが、課金サーバとして、クライアント（ユーザ）毎の課金を管理していることも多い。
【０００３】
このようなコンテンツ配信システムにおいては、クライアントが視聴のためにコンテンツ配信サーバに対してコンテンツデータの配信を要求すると、コンテンツ配信サーバは、課金サーバに対してコンテンツデータのアクセス（配信）を許可して良いかの問合せメッセージを送信し、当該許可を示す応答メッセージが返信された場合は、クライアントに対してコンテンツデータの配信を行うようになっている。
【０００４】
例えば、特許文献１における課金システムにおいては、コンテンツ料金を回収する際においてコンテンツのミラーリングによるトラヒック集中の回避等を可能とする課金方法が開示されている。
【特許文献１】特開２００２−７４１９１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のコンテンツ配信システムのように、クライアントがコンテンツデータの視聴のたびに問合せメッセージを逐一送信する場合、多数のクライアントからの当該メッセージに対する課金に関する処理が課金サーバに集中して、課金サーバに対して多大の処理負荷を与えてしまうという問題がある。このことは、当該システムを利用するクライアントの数が増せば、増すほど顕著になる。
【０００６】
本発明は、以上の問題等に鑑みてなされたものであり、課金に関する処理の集中を回避することを可能としたノード装置、情報送信処理プログラム、及び情報配信方法等を提供することを課題とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えた情報配信システムであって、配信情報が１以上の前記ノード装置に保存され、かつ、前記配信情報の提供可否に関連する提供可否関連情報であって夫々の前記ノード装置に対応する前記提供可否関連情報が、他の前記ノード装置に分散保存されている情報配信システムに含まれる前記ノード装置であって、他の前記ノード装置から前記ネットワークを介して送信されてきた前記配信情報の提供要求を示す要求情報を受信する要求情報受信手段と、前記受信された要求情報の送信元である前記ノード装置に対応する前記提供可否関連情報を保存している前記ノード装置に対して、当該配信情報の提供可否を前記ネットワークを介して確認する提供可否確認手段と、前記要求情報の送信元である前記ノード装置に対して、前記確認された提供可否に基づく回答情報を前記ネットワークを介して送信する提供可否情報送信手段と、を備えることを特徴とする。
【０００８】
請求項１に記載の発明によれば、配信情報の提供可否に関連する提供可否関連情報であって夫々のノード装置に対応する提供可否関連情報が、他のノード装置に分散保存されるようにしておき、ネットワークを介して送信されてきた配信情報の提供要求を示す要求情報を受信すると、受信された要求情報の送信元であるノード装置に対応する提供可否関連情報を保存しているノード装置に対して、当該配信情報の提供可否を前記ネットワークを介して確認し、当該確認された提供可否に基づく回答情報を、要求情報の送信元であるノード装置に対して、ネットワークを介して送信するように構成したので、配信情報の提供可否に関する処理（例えば課金に関する処理）をノード装置毎に分散させ、処理の集中を回避することができる。
【０００９】
請求項２に記載の発明は、請求項１に記載のノード装置において、前記要求情報の送信元である前記ノード装置に対応する前記提供可否関連情報は、複数の前記ノード装置に保存されており、前記提供可否確認手段は、前記提供可否関連情報を保存している前記複数のノード装置に対して、当該配信情報の提供可否を前記ネットワークを介して確認し、当該確認された複数の提供可否に基づいて当該配信情報の提供可否を決定し、前記提供可否送信手段は、前記要求情報の送信元である前記ノード装置に対して、前記決定された提供可否に基づく回答情報を前記ネットワークを介して送信することを特徴とする。
【００１０】
請求項２に記載の発明によれば、提供可否関連情報の正確性を保ち、配信情報の提供可否を正確に決定することができる。
【００１１】
請求項３に記載の発明は、請求項１又は２に記載のノード装置において、前記提供可否確認手段は、前記提供可否関連情報を保存している前記ノード装置に対して、前記配信情報の提供可否を確認するための確認情報を送信し、当該確認情報に応じて返信されてきた当該配信情報の提供可否に基づく回答情報を受信することによって、前記配信情報の提供可否を確認することを特徴とする。
【００１２】
請求項４に記載の発明は、請求項３に記載のノード装置において、前記複数のノード装置のうち、前記決定された配信情報の提供可否と異なる提供可否に基づく回答情報を返信した前記ノード装置に対して、前記提供可否関連情報の修正要求を示す修正要求情報を送信する修正要求情報送信手段を更に備えることを特徴とする。
【００１３】
請求項５に記載の発明は、請求項２乃至４の何れか一項に記載のノード装置において、前記要求情報には、当該要求情報の送信元である前記ノード装置に対応する前記第１識別情報が含まれており、前記提供可否確認手段は、前記要求情報に含まれる前記第１識別情報に基づいて、互いに異なる複数の第２識別情報を生成し、夫々の前記第２識別情報に対応する夫々の前記ノード装置に対して、前記配信情報の提供可否を確認することを特徴とする。
【００１４】
請求項６に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えた情報配信システムであって、配信情報が１以上の前記ノード装置に保存され、かつ、前記配信情報の提供可否に関連する提供可否関連情報であって夫々の前記ノード装置に対応する前記提供可否関連情報が、他の前記ノード装置に分散保存されている情報配信システムに含まれる前記ノード装置であって、任意の前記ノード装置から前記ネットワークを介して送信されてきた当該配信情報の提供可否を確認するための確認情報を受信する確認情報受信手段と、前記受信された確認情報に関わる配信情報の提供が可能か否かを前記提供可否関連情報を参照して判別する提供可否判別手段と、前記確認情報を送信した前記ノード装置に対して、前記判別された提供可否に基づく回答情報を前記ネットワークを介して返信する提供可否情報返信手段と、を備えることを特徴とする。
【００１５】
請求項７に記載の発明は、請求項６に記載のノード装置において、前記提供可否判別手段により、前記配信情報の提供が可能と判別された場合には、前記提供可否関連情報を更新する提供可否関連情報更新手段を更に備えることを特徴とする。
【００１６】
請求項８に記載の発明は、請求項６又は７に記載のノード装置において、請求項３に記載のノード装置から前記ネットワークを介して送信されてきた前記修正要求情報を受信する修正要求情報受信手段と、前記受信された修正要求情報に基づいて、前記提供可否関連情報を修正する提供可否関連情報修正手段と、を更に備えることを特徴とする。
【００１７】
請求項８に記載の発明によれば、ノード装置に保存されている提供可否関連情報が食い違う場合であっても、上記決定された提供可否と異なる回答を返信したノード装置に対しては、提供可否関連情報の修正を行うようにしたので、複数のノード装置間において提供可否関連情報の内容を一致させ、当該提供可否関連情報の正確性を保つことができる。
【００１８】
請求項９に記載の発明は、請求項１乃至８の何れか一項に記載のノード装置において、前記提供可否関連情報には、前記配信情報の提供に対して課金を行うために必要な課金情報が含まれていることを特徴とする。
【００１９】
請求項１０に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えた情報配信システムであって、配信情報が１以上の前記ノード装置に保存され、かつ、前記配信情報の提供可否に関連する提供可否関連情報であって夫々の前記ノード装置に対応する前記提供可否関連情報が、他の前記ノード装置に分散保存されている情報配信システムに含まれるコンピュータを、他の前記ノード装置から前記ネットワークを介して送信されてきた前記配信情報の提供要求を示す要求情報を受信する要求情報受信手段、前記受信された要求情報の送信元である前記ノード装置に対応する前記提供可否関連情報を保存している前記ノード装置に対して、当該配信情報の提供可否を前記ネットワークを介して確認する提供可否確認手段、及び、前記要求情報の送信元である前記ノード装置に対して、前記確認された提供可否に基づく回答情報を前記ネットワークを介して送信する提供可否情報送信手段として機能させることを特徴とする。
【００２０】
請求項１１に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えた情報配信システムであって、配信情報が１以上の前記ノード装置に保存され、かつ、前記配信情報の提供可否に関連する提供可否関連情報であって夫々の前記ノード装置に対応する前記提供可否関連情報が、他の前記ノード装置に分散保存されている情報配信システムに含まれるコンピュータを、前記配信情報の保存元である前記ノード装置から前記ネットワークを介して送信されてきた当該配信情報の提供可否を確認するための確認情報を受信する確認情報受信手段、前記受信された確認情報に関わる配信情報の提供が可能か否かを前記提供可否関連情報を参照して判別する提供可否判別手段、及び、前記確認情報を送信した前記ノード装置に対して、前記判別された提供可否に基づく回答情報を前記ネットワークを介して返信する提供可否情報返信手段として機能させることを特徴とする。
【００２１】
請求項１２に記載の発明は、請求項１０又は１１に記載の情報送信処理プログラムがコンピュータ読み取り可能に記録されていることを特徴とする。
【００２２】
請求項１３に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えた情報配信システムであって、配信情報が１以上の前記ノード装置に保存され、かつ、前記配信情報の提供可否に関連する提供可否関連情報であって夫々の前記ノード装置に対応する前記提供可否関連情報が、他の前記ノード装置に分散保存されている情報配信システムにおける情報配信方法であって、前記配信情報の保存元である前記ノード装置が、他の前記ノード装置から前記ネットワークを介して送信されてきた当該配信情報の提供要求を示す要求情報を受信し、当該要求情報の送信元である前記ノード装置に対応する前記提供可否関連情報を保存している前記ノード装置に対して、当該配信情報の提供可否を確認するための確認情報を送信する工程と、前記提供可否関連情報を保存している前記ノード装置が、前記確認情報を受信し、当該確認情報に関わる配信情報の提供が可能か否かを前記提供可否関連情報を参照して判別し、当該判別された提供可否に基づく回答情報を、前記確認情報を送信した前記ノード装置に対して前記ネットワークを介して返信する工程と、前記配信情報の保存元である前記ノード装置が、前記提供可否に基づく回答情報を受信し、当該提供可否に基づく回答情報を、前記要求情報の送信元である前記ノード装置に対して前記ネットワークを介して送信する工程と、を備えることを特徴とする。
【発明の効果】
【００２３】
本発明によれば、配信情報の提供可否に関連する提供可否関連情報であって夫々のノード装置に対応する提供可否関連情報（例えば、課金を行うために必要な課金情報が含まれている）が、他のノード装置に分散保存されるようにしておき、ネットワークを介して送信されてきた配信情報の提供要求を示す要求情報を受信すると、受信された要求情報の送信元であるノード装置に対応する提供可否関連情報を保存しているノード装置に対して、当該配信情報の提供可否を前記ネットワークを介して確認し、当該確認された提供可否に基づく回答情報を、要求情報の送信元であるノード装置に対して、ネットワークを介して送信するように構成したので、配信情報の提供可否に関する処理（例えば課金に関する処理）をノード装置毎に分散させ、処理の集中を回避することができる。
【発明を実施するための最良の形態】
【００２４】
以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、コンテンツ配信システムに対して本発明を適用した場合の実施形態である。
【００２５】
［１．コンテンツ配信システムの構成等］
始めに、図１を参照して、情報配信システムとしてのコンテンツ配信システムの概要構成等について説明する。
【００２６】
図１は、本実施形態に係るコンテンツ配信システムにおける各ノード装置の接続態様の一例を示す図である。
【００２７】
図１の下部枠１０１内に示すように、ＩＸ（Internet eＸchange）３、ＩＳＰ（Internet Service Provider）４、ＤＳＬ（Digital Subscriber Line）回線事業者（の装置）５、ＦＴＴＨ（Fiber To The Home）回線事業者（の装置）６、及び通信回線（例えば、電話回線や光ケーブル等）７等によって、インターネット等のネットワーク（現実世界のネットワーク）８が構築されている。
【００２８】
コンテンツ配信システムＳは、このようなネットワーク８を介して相互に接続された複数のノード装置１ａ，１ｂ，１ｃ・・・１ｘ，１ｙ，１ｚ・・・を備えて構成されることになり、ピアツーピア方式のネットワークシステムとなっている。各ノード装置１ａ，１ｂ，１ｃ・・・１ｘ，１ｙ，１ｚ・・には、ノード装置を示す情報として固有の製造番号及びＩＰ（Internet Protocol）アドレスが割り当てられている。なお、製造番号及びＩＰアドレスは、複数のノード装置１間で重複しないものである。また、以下の説明において、ノード装置１ａ，１ｂ，１ｃ・・・１ｘ，１ｙ，１ｚ・・・を総称して「ノード１」というものとする。
【００２９】
そして、このコンテンツ配信システムＳにおいては、特定のアルゴリズム、例えば、後述する分散ハッシュテーブル（以下、ＤＨＴ（Distribute Hash Table）という）を利用したアルゴリズムによって、図１の上部枠１００内に示すような、オーバーレイネットワーク９が構築されることになる。つまり、このオーバーレイネットワーク９は、既存のネットワーク８を用いて形成された仮想的なリンクを構成するネットワークを意味する。
【００３０】
本実施形態においては、ＤＨＴを利用したアルゴリズムによって構築されたオーバーレイネットワーク９を前提としており、このオーバーレイネットワーク９上に配置されたノード１を、オーバーレイネットワーク９に参加しているノード１という。オーバーレイネットワーク９への参加は、未だ参加していないノード１が、既に参加している任意のノード１に対して参加要求を送ることによって行われる。
【００３１】
また、オーバーレイネットワーク９に参加している各ノード１は、ノードＩＤを有しており、当該ノードＩＤは、例えば、ＩＰアドレスあるいは製造番号を共通のハッシュ関数（例えば、ＳＨＡ−１等）によりハッシュ化した値（例えば、ｂｉｔ長は１６０ｂｉｔ）であり、一つのＩＤ空間に偏りなく分散して配置されることになる。このように共通のハッシュ関数により求められた（ハッシュ化された）ノードＩＤは、当該ＩＰアドレスあるいは製造番号が異なれば、同じ値になる確率が極めて低いものである。なお、ハッシュ関数については公知であるので詳しい説明を省略する。なお、本実施形態では、ＩＰアドレス（グローバルＩＰアドレス）を共通のハッシュ関数によりハッシュ化した値をノードＩＤとする。
【００３２】
また、オーバーレイネットワーク９に参加している各ノード１は、夫々、ＤＨＴを保持している。このＤＨＴには、他のノード１への経路情報、すなわち、ノードＩＤ空間内で適度に離れた他のノード１のノードＩＤとそのＩＰアドレスが、複数登録されている。このようなＤＨＴは、ノード１がオーバーレイネットワーク９に参加する際に与えられることになる。また、コンテンツ配信システムＳにおいては、ノード１のオーバーレイネットワーク９への参加若しくは脱退が頻繁に行われるため、定期的に（例えば数十分から数時間間隔で）ＤＨＴの更新が必要かどうかが確認されると共に、その更新情報が他のノード１にＤＨＴに登録されている経路を介して伝達されるようになっている。これにより、ＤＨＴを最新の状態に保つことが可能となる。なお、ＤＨＴの生成方法については公知であるので詳しい説明を省略する。
【００３３】
更に、オーバーレイネットワーク９に参加している複数のノード１には、コンテンツ（例えば、映画や音楽等）データが分散して保存（格納）されている。例えば、ノード１ａには、タイトルがＸＸＸの映画のコンテンツデータが保存されており、一方、ノード１ｂには、タイトルがＹＹＹの映画のコンテンツデータが保存されるというように、互いに異なるコンテンツデータが、複数のノード１に分散されて保存される。また、あるコンテンツデータは、１つのノード１に保存されているとは限らず、複数のノード１に同じコンテンツデータが保存されうる。これらのコンテンツデータには、夫々、コンテンツ名（タイトル）等が付与されている。
【００３４】
そして、このように分散保存されているコンテンツデータの所在を示す所在情報（例えば、コンテンツデータが保存されているノード１のＩＰアドレス）もまた、オーバーレイネットワーク９に参加している複数のノード１に分散して保存されている。例えば、あるコンテンツデータのコンテンツ名（或いは、当該コンテンツデータの先頭数バイトでも良い）が、上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化され（つまり、ノード１のＩＰアドレスのハッシュ値と同一のＩＤ空間に配置）、そのハッシュ値（当該ハッシュ値がコンテンツＩＤとなる）と最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するノード１に、当該コンテンツデータの所在情報が保存されることになる。つまり、同一のコンテンツデータ（コンテンツＩＤが同一）が、夫々、複数のノード１に保存されている場合であっても、かかるコンテンツデータの所在を示す所在情報（複数のノード１のＩＰアドレス等）は、１つのノード１で管理することができる（なお、本実施形態においては、１のノード１では、１のコンテンツＩＤに対応するコンテンツデータの所在情報が保存される（つまり、ノード１と上記所在情報とは１対１の関係にある）が、これに限定されるものではない））。
【００３５】
これにより、あるコンテンツデータを取得（ダウンロード）したいユーザが使用するノード（以下、これを「ユーザノード」という）１ａは、当該コンテンツデータのコンテンツＩＤが付加されたクエリ（問合せ情報）を他のノード１に対して送出することにより、当該コンテンツＩＤが付加されたクエリは、いくつかのノード（以下、これを「中継ノード」という）を経由されて（各中継ノードにおいて、上記ＤＨＴが参照されてコンテンツＩＤが転送される）そのコンテンツデータの所在を示す所在情報を保存しているノード（以下、これを「ルートノード」という）１ｘまで辿り着き、当該ルートノード１ｘから当該所在情報を取得（受信）することが可能となり、取得した所在情報に基づいて上記コンテンツデータを保存している例えばノード（以下、これを「コンテンツホルダノード」という）１ｂに接続し、そこから当該コンテンツデータを取得（受信）することが可能になる。なお、コンテンツＩＤがルートノード１ｘに辿り着くまでの間に当該ルートノード１ｘと同じ所在情報をキャッシュしているノード１から当該所在情報を取得（受信）されるようにしてもよい。
【００３６】
なお、各ユーザノードのユーザには、夫々、固有の第１識別情報としてのユーザ登録番号（ユーザ認証番号）が割り当てられている。
【００３７】
図２は、ＤＨＴのノードＩＤ空間において、ユーザノードから送出されたクエリがルートノードまで転送される様子の一例を示す図である。図２の例において、各中継ノードは、受信したクエリに付加されたコンテンツＩＤと、ＤＨＴに登録されているノードＩＤとを比較して、次に転送すべきノード１を特定（例えば、コンテンツＩＤの上位数桁が一致するノードＩＤに対応するノード１のＩＰアドレスを特定）し、そこにクエリを転送することになる。なお、ユーザノードからルートノードに至るまでのＤＨＴを用いたクエリの転送方法は公知であるので更なる詳しい説明を省略する。
【００３８】
ところで、上記において、ルートノード１ｘは、クエリを送信したユーザノード１ａに対して所在情報を送信する構成を説明したが、本実施形態においては、ルートノード１ｘが所在情報をユーザノード１ａに返送するのではなく、クエリをさらにコンテンツホルダノード１ｂに転送し、当該コンテンツホルダノード１ｂは、ユーザノード（コンテンツを購入、視聴するユーザのノード）１ａのアクセス権を管理するノード（以下、これを「アクセス権管理ノード」という）に、アクセス権があるか否か、言い換えれば、コンテンツデータの提供（購入又は視聴）が可能か否かを確認した上で、アクセス権があれば、当該ユーザノード１ａに対してコンテンツデータを送信し、また、当該コンテンツデータの提供に対する課金処理を行うことを特徴としている。なお、本実施形態においては、コンテンツデータの提供に対するユーザへの課金方式は、前払い方式と後払い方式とが選択可能になっている。
【００３９】
図３は、ＤＨＴのノードＩＤ空間において、ユーザノードからクエリが送出された後、当該ユーザノードに対してコンテンツデータが送信される様子の一例を示す図である（情報の流れは図中(1)から(7)の順）。図３の例においては、コンテンツホルダノード１ｂがアクセス権管理ノード１ｙに対し、ユーザノード１ａのアクセス権があるか否かを確認（図中(4)〜（6））した上で、当該ユーザノードに対してコンテンツデータを送信している。
【００４０】
上記アクセス権管理ノードは、夫々のユーザノード毎に存在し、夫々のユーザノード（言い換えれば、ユーザ）に対する上記コンテンツデータの提供可否に関連する提供可否関連情報を保存、管理している。また、かかる提供可否関連情報には、例えばコンテンツデータの提供に対して課金を行うために必要な課金情報が含まれている。
【００４１】
そして、夫々のユーザノードに対応する提供可否関連情報は、例えば、各ユーザに対して割り当てられたユーザ登録番号（ユーザ認証番号）が上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化され（つまり、ノード１のＩＰアドレスのハッシュ値と同一のＩＤ空間に配置）、そのハッシュ値（当該ハッシュ値がユーザＩＤとなる）と最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するノード１（つまり、ユーザノードとは異なる他のノード（アクセス権管理ノード））に保存されることになる。つまり、各ユーザノードのユーザのユーザＩＤは、互いに異なるので、アクセス権管理ノードも、ユーザノード毎に異ならせることができる。従って、ユーザ毎の例えば課金処理等が分散されるので、処理の集中を回避することができる。
【００４２】
また、ノード１は、例えば電源断等により、コンテンツ配信システムＳから脱退する可能性があるので、その対策として、ユーザ登録番号からユーザＩＤを生成するときに、当該ユーザ登録番号の末尾に文字や記号等を加え、更に加えた文字や記号等を少しずつ変える（いわゆるソルトする）ことにより互いに異なる複数の第２識別情報としてのユーザＩＤを生成し、夫々のユーザＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する夫々のノード１を、アクセス権管理ノードとすれば、更に好ましい。すなわち、１つのユーザノードに対応して、複数のユーザＩＤに対応するアクセス権管理ノードが存在することになるので、何れかのアクセス権管理ノードが脱退しても、例えば課金処理等の実行性を高めることができる。
【００４３】
次に、図４を参照して、ノード１の構成及び機能について説明する。
【００４４】
図４は、ノード１の概要構成例を示す図である。
【００４５】
各ノード１は、図４に示すように、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成されたコンピュータとしての制御部１１と、各種データ（例えば、コンテンツデータ、所在情報、提供可否関連情報等）及びプログラム等を記憶保存（格納）するためのＨＤＤ等から構成された記憶部１２と、受信されたコンテンツデータを一時蓄積するバッファメモリ１３と、コンテンツデータに含まれるエンコードされたビデオデータ（映像情報）及びオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）するデコーダ部１４と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部１５と、当該映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ，液晶ディスプレイ等の表示部１６と、上記デコードされたオーディオデータをアナログオーディオ信号にＤ（Digital）／Ａ（Analog）変換した後これをアンプにより増幅して出力する音声処理部１７と、当該音声処理部１７から出力されたオーディオ信号を音波として出力するスピーカ１８と、ＩＣカードを挿入するＩＣカードスロットを有し挿入されたＩＣカードから情報（例えば、ユーザ登録番号）を読み取るためのＩＣカードリーダ部１９と、ネットワーク８を通じて他のノード１との間の情報の通信制御を行うための通信部２０と、ユーザからの指示を受け付け当該指示に応じた指示信号を制御部１１に対して与える入力部（例えば、キーボード、マウス、或いは、操作パネル等）２１と、を備えて構成され、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４、ＩＣカードリーダ部１９及び通信部２０は、バス２２を介して相互に接続されている。なお、ＩＣカードは、例えばノード１の購入時に、ユーザ登録によりユーザに配布される。また、各ＩＣカードには、ユーザ登録順に連番で固有のユーザ登録番号が記録され、更に、課金方式（前払いにするか、或いは後払いにするかをユーザが選択して決定する）も記録され、ユーザは、記録されたこれらの情報を変更できないようになっている。
【００４６】
そして、制御部１１は、ＣＰＵが記憶部１２等に記憶されたプログラム（本発明の情報送信処理プログラムを含む）を読み出して実行することにより、ノード１全体を統括制御すると共に、ユーザノード、中継ノード、ルートノード、コンテンツホルダノード、アクセス権管理ノード、及び後述する会計ノードの何れか１以上のノードとして機能するようになっている。つまり、ノード１は、その場面によって、ユーザノードであったり、コンテンツホルダノードであったり、或いは、アクセス権管理ノードであったりするのである。
【００４７】
例えば、ノード１がコンテンツホルダノードである場合、制御部１１は、本発明の要求情報受信手段、提供可否確認手段、提供可否情報送信手段、及び修正要求情報送信手段等として機能し、アクセス権管理ノードである場合、制御部１１は、確認情報受信手段、提供可否判別手段、提供可否情報返信手段、修正要求情報受信手段、及び提供可否関連情報修正手段等として機能することとなる。なお、これらの各手段についての詳細は後述する。
【００４８】
なお、情報送信処理プログラムは、例えば、ネットワーク８上の所定のサーバからダウンロードされるようにしてもよいし、例えば、ＣＤ−ＲＯＭ等の記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしてもよい。
【００４９】
[２．コンテンツ配信システムの動作]
次に、コンテンツ配信システムＳの動作について説明する。
【００５０】
始めに、図５乃至図９等を参照して、コンテンツ配信システムＳにおける前払い時の流れ、購入時の流れ、視聴時の流れ、課金情報収集時の流れについて、夫々、その概略を説明する。
【００５１】
（ｉ）前払い時の流れ
図５は、ＤＨＴのノードＩＤ空間における前払い時の情報の流れの一例を示す図である。
【００５２】
図５に示すように、ＤＨＴのノードＩＤ空間には、ユーザノード１ａ、コンテンツホルダノード１ｂ、ルートノード１ｘ、アクセス権管理ノード１ｙ1〜１ｙ10、及び会計ノード１ｚが存在、つまり、オーバーレイネットワーク９に参加している。アクセス権管理ノード１ｙ1〜１ｙ10は、夫々、ユーザノード１ａに対するコンテンツデータの提供可否に関連する提供可否関連情報を保存、管理している。また、課金管理センター（システム）Ｃは、オーバーレイネットワーク９外にあって、ユーザからの入金確認やユーザノード１ａのユーザに対する料金請求を行う機能を有し、会計ノード１ｚとの間で情報の授受を行うようになっている。会計ノード１ｚは、課金管理センターＣの管理者が、専用のノードを設置するか、あるいは、オーバーレイネットワーク９の中から任意のノードを１つ選んで、その役目を割り当てても良い。
【００５３】
そして、ユーザが例えば銀行振り込みなどで入金をして、その旨を課金管理センターＣに通知する（例えば、「ユーザ登録番号「１０２９３９５６」の者が、１５，０００円振り込みました」、と通知される）。これに対して、課金管理センターＣが当該入金を確認すると、当該課金管理センターＣは、その制御下にある会計ノード１ｚに対して、ユーザ登録番号及び入金額を含む入金指示を示す入金指示情報を送信する。会計ノード１ｚは、当該入金指示情報を受信すると、当該ユーザ登録番号に基づいて互いに異なる複数のユーザＩＤを生成する。例えば、ユーザ登録番号の末尾に、０，１，２，３，４，５，６，７，８，９の１０種類の数字が付加された番号が作成され、夫々の番号が、上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化されて複数のユーザＩＤが生成される。
【００５４】
次いで、会計ノード１ｚは、生成された夫々のユーザＩＤ及びＤＨＴに従って、ユーザＩＤ及び入金額を含む“前払い”メッセージを送信する。送信された“前払い”メッセージは、ＤＨＴに従って中継ノードを転送されていき、夫々のユーザＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する（つまり、夫々のユーザＩＤに対応する）アクセス権管理ノード１ｙ1〜１ｙ10に到着する。
【００５５】
上記“前払い”メッセージを受信した夫々のアクセス権管理ノード１ｙ1〜１ｙ10は、未だ当該ユーザの提供可否関連情報が生成されていない場合には、当該“前払い”メッセージ中のユーザＩＤ及び入金額に従って提供可否関連情報を新たに生成し、一方、既に当該ユーザの提供可否関連情報が生成されている場合には、当該“前払い”メッセージ中のユーザＩＤ及び入金額に従って提供可否関連情報を更新する。
【００５６】
図６は、アクセス権管理ノードに保存されている提供可否関連情報の一例を示す図である。図６の例では、提供可否関連情報５１には、課金対象ユーザのユーザＩＤ、課金方式（前払いと後払いが選択可能）、プール金額（前払い金額）、及び後日請求金額（後払い金額）等の課金情報の他、視聴ログ、購入コンテンツリストが含まれている。例えば、上記前払い時においては、“前払い”メッセージ中の入金額がプール金額（前払い金額）に加算されることになる。
【００５７】
なお、１つのアクセス権管理ノードは、複数の課金対象ユーザの提供可否関連情報を保存、管理することもあり得るので、提供可否関連情報はユーザＩＤ毎に管理される。また、ユーザノード（課金対象となるノード１）は、かかる提供可否関連情報を直接操作（例えば、情報の追加、変更等）することはできないようになっている。つまり、ユーザが不正に課金情報を変更できないようになっている。
【００５８】
また、あるノード１がオーバーレイネットワーク９に参加するときは、例えば、自己（自ノード）のノードＩＤに最も近いノードＩＤを有するノード１からＤＨＴの一部を委譲されるが、上記提供可否関連情報も、同様に委譲されるようにすれば望ましい。つまり、新規参加するノード１のノードＩＤに最も近いノードＩＤを有するノード１が提供可否関連情報を保存していた場合、その提供可否関連情報に対応するユーザＩＤが新規参加するノード１のノードＩＤと既存のノード１のノードＩＤとのどちらに近いかで、その提供可否関連情報がどちらのノード１に保存されるべきかが判断され、例えば、新規参加するノード１のノードＩＤの方がユーザＩＤに近ければ提供可否関連情報が当該新規参加するノード１に委譲されることになる。
【００５９】
（ii）購入時の流れ
図７は、ＤＨＴのノードＩＤ空間における購入時の情報の流れの一例を示す図である。
【００６０】
先ず、ユーザノード１ａは、コンテンツの電子カタログ（タイトルリスト：コンテンツタイトルと、そのコンテンツＩＤと、１回視聴時の利用金額、購入時の料金、等の組を表にしたもの。上映時間、監督、俳優などの情報が付記されていても良い）を表示部１６における表示画面上に表示する。当該電子カタログは、例えば全てのノード１に配信されており、ユーザはユーザノード１ａ上で閲覧することができる。なお、ここで言っている「購入」は、自ノード内にコンテンツのコピーを作ることではなく、ネットワーク上にあるコンテンツを、無条件で（課金されることなく）視聴できる権利を無期限に得る、という意味である。初めに一定金額を支払ってこの権利を得れば、いわゆる「購入して所有している」のと同じことになる。
【００６１】
そして、ユーザが、上記表示された電子カタログから、購入を希望するコンテンツを入力部２１を操作して選択して“購入ボタン”を押下すると、ユーザノード１ａは、選択されたコンテンツに対応するコンテンツＩＤ及びＤＨＴに従って、コンテンツＩＤ、自己（当該ユーザノード１ａ）のＩＰアドレス、ユーザ登録番号及び課金方式を含む“購入申込”メッセージ（コンテンツデータの無期限かつ無条件の視聴権利（すなわち購入）要求を示す要求情報）を送信する。送信された“購入申込”メッセージは、ＤＨＴに従って中継ノードを転送されていき、当該コンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するルートノード１ｘに到着する。そして、当該“購入申込”メッセージを受信したルートノード１ｘは、当該“購入申込”メッセージを、当該コンテンツＩＤに対応するコンテンツデータを保存しているコンテンツホルダノード１ｂに転送する。
【００６２】
コンテンツホルダノード１ｂは、ルートノード１ｘからネットワーク８を介して転送（送信）されてきた“購入申込”メッセージを受信する。次いで、コンテンツホルダノード１ｂは、受信された“購入申込”メッセージの送信元であるユーザノード１ａに対応する提供可否関連情報を保存しているアクセス権管理ノード１ｙ1〜１ｙ10に対して、当該コンテンツデータの提供可否をネットワーク１０を介して確認する。例えば、“購入申込”メッセージに含まれるユーザ登録番号に基づいて互いに異なる複数（ここでは、１０個）のユーザＩＤを生成（例えば、上記会計ノード１ｚと同様、ユーザ登録番号の末尾に、０，１，２，３，４，５，６，７，８，９の１０種類の数字が付加された番号を作成し、夫々の番号が、上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化して複数のユーザＩＤを生成）、夫々のユーザＩＤに対応する夫々のアクセス権管理ノード１ｙ1〜１ｙ10に対して（つまり、ユーザＩＤ及びＤＨＴに従って）、コンテンツデータの提供可否を確認するための確認情報としての“購入登録”メッセージ（コンテンツＩＤ、ユーザＩＤ、コンテンツホルダノード１ｂのＩＰアドレス、及び課金方式を含む）を送信することにより確認する。送信された“購入登録”メッセージは、ＤＨＴに従って中継ノードを転送されていき、夫々のユーザＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する（つまり、夫々のユーザＩＤに対応する）アクセス権管理ノード１ｙ1〜１ｙ10に到着する。
【００６３】
夫々のアクセス権管理ノード１ｙ1〜１ｙ10は、コンテンツデータの保存元であるコンテンツホルダノード１ｂから中継ノード及びネットワーク１０を介して送信されてきた“購入登録”メッセージを受信すると、“購入登録”メッセージに関わるコンテンツデータ（つまり、当該コンテンツＩＤに対応するコンテンツデータ）の無期限かつ無条件の視聴権利の獲得（すなわち、購入）が可能か否かを当該ユーザＩＤに対応する提供可否関連情報を参照して判別する。例えば、“購入登録”メッセージ中の課金方式が前払いの場合は、提供可否関連情報に含まれるプール金額（前払い金額）の残高から当該コンテンツＩＤに対応するコンテンツデータの価格（コンテンツの電子カタログを参照する）が引かれ、マイナスになれば購入不可と判別され、マイナスにならなければ購入可能と判別される。また、“購入登録”メッセージ中の課金方式が後払いの場合は、購入可能と判別される。
【００６４】
そして、夫々のアクセス権管理ノード１ｙ1〜１ｙ10は、前払いであって購入可能（購入成功）と判別した場合、当該ユーザＩＤに対応する提供可否関連情報に含まれるプール金額（前払い金額）の残高から当該コンテンツＩＤに対応するコンテンツデータの価格が引かれた金額をプール金額（前払い金額）として更新し、一方、前払いであって購入不可と判別した場合、プール金額（前払い金額）の更新を行わない。また、夫々のアクセス権管理ノード１ｙ1〜１ｙ10は、後払いであって購入可能と判別した場合、提供可否関連情報に含まれる後日請求金額（後払い金額）に当該コンテンツデータの価格を加算し、購入コンテンツリストにコンテンツＩＤ等を追加する更新を行う。なお、ユーザＩＤに対応する提供可否関連情報が未だ作成されていない場合には、このタイミングで作成されることになる。
【００６５】
次いで、夫々のアクセス権管理ノード１ｙ1〜１ｙ10は、“購入登録”メッセージを送信したコンテンツホルダノード１ｂに対して、上記判別された購入可否（購入可能或いは不可）及び課金情報（例えば、プール金額（前払い金額）又は後日請求金額（後払い金額）を含む）を含む“購入可否（購入成否）”メッセージをネットワーク１０を介して返信する。なお、アクセス権管理ノードが１つである場合には、“購入可否（購入成否）”メッセージは、アクセス権管理ノードからネットワーク１０を介して直接ユーザノード１ａに送信されるように構成しても良い。
【００６６】
そして、コンテンツホルダノード１ｂは、上記“購入登録”メッセージに応じて夫々のアクセス権管理ノード１ｙ1〜１ｙ10から返信されてきた“購入可否”メッセージを受信し、これによって購入可否を確認し、続いて、“購入申込”メッセージの送信元であるユーザノード１ａに対して、当該確認された購入可否に基づく回答情報をネットワーク１０を介して送信することになる。
【００６７】
ところで、正常ならば１０個のアクセス権管理ノード１ｙ1〜１ｙ10から、“購入可否"メッセージがコンテンツホルダノード１ｂに返信されて１０個とも同じ回答が返ってくる筈であるが、何れかのアクセス権管理ノード１ｙ1〜１ｙ10が、電源断や通信事故等により、一時的にコンテンツ配信システムＳから脱退していたことにより、１０個の夫々のアクセス権管理ノード１ｙ1〜１ｙ10が有する提供可否関連情報が食い違う場合があり得る。かかる場合、コンテンツホルダノード１ｂは、上記確認された複数の購入可否に基づいて（例えば、多数決により）、当該コンテンツデータの購入可否を決定、例えば過半数以上のアクセス権管理ノードが購入可能とした場合、購入可能（購入成功）と決定し、当該購入可能及び課金情報を含む“購入可否"メッセージを、ユーザノード１ａに対してネットワーク１０を介して送信する。一方、例えば過半数以上のアクセス権管理ノードが購入不可とした場合、コンテンツホルダノード１ｂは、購入不可（購入失敗）と決定し、当該購入不可及び課金情報を含む“購入可否"メッセージを、ユーザノード１ａに対してネットワーク１０を介して送信する。
【００６８】
そして、上記決定された提供可否（最も多い回答：購入可能又は購入不可）と異なる提供可否に基づく回答情報（回答）を返信したアクセス権管理ノードに対しては、提供可否関連情報の修正が行われる。具体的には、アクセス権管理ノード１ｙ1〜１ｙ10からの“購入可否"メッセージには、現状の課金情報が含まれるので、多数決で選択されたアクセス権管理ノードの課金情報を正当とみなし（同じ購入可能（購入成功）を返信した中でも、課金情報が食い違うこともあり得るが、その場合も、最も一致するものが多い課金情報を正当とみなし）、正当とみなされない課金情報を含む“購入可否"メッセージを返信したアクセス権管理ノードに対して、提供可否関連情報の修正要求を示す修正要求情報として、ユーザＩＤ及び修正課金情報（正当とみなされた課金情報）を含む“情報修正"メッセージを、上述したようにユーザＩＤ及びＤＨＴに従ってネットワーク１０を介して送信する。そして、“情報修正"メッセージを受信したアクセス権管理ノードは、“情報修正"メッセージ中の修正課金情報に基づいて、提供可否関連情報に含まれる課金情報を修正（当該課金情報を修正課金情報に更新）する。これにより、アクセス権管理ノード１ｙ1〜１ｙ10の相互間で課金情報の食い違いが発生したとしても、同じになるように修正することができる。
【００６９】
（iii）視聴時の流れ
図８は、ＤＨＴのノードＩＤ空間における視聴時の情報の流れの一例を示す図である。なお、ここで言っている「視聴」は、いわゆるペイパービュー(Pay per view)方式の課金を行うことを想定しており、一回ごとの視聴に、支払い金額が発生する。
【００７０】
先ず、上記購入時の流れと同様、ユーザが、表示部１６における表示画面上に表示された電子カタログから、視聴を希望するコンテンツを入力部２１を操作して選択して“視聴ボタン”を押下すると、ユーザノード１ａは、選択されたコンテンツに対応するコンテンツＩＤ及びＤＨＴに従って、コンテンツＩＤ、自己（当該ユーザノード１ａ）のＩＰアドレス、ユーザ登録番号及び課金方式を含む“視聴要求”メッセージ（コンテンツデータの提供（ここでは、視聴）要求を示す要求情報）を送信する。送信された“視聴要求”メッセージは、ＤＨＴに従って中継ノードを転送されていき、当該コンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するルートノード１ｘに到着する。そして、当該“視聴要求”メッセージを受信したルートノード１ｘは、当該“視聴要求”メッセージを、当該コンテンツＩＤに対応するコンテンツデータを保存しているコンテンツホルダノード１ｂに転送する。
【００７１】
コンテンツホルダノード１ｂは、ルートノード１ｘからネットワーク８を介して転送（送信）されてきた“視聴要求”メッセージを受信する。次いで、コンテンツホルダノード１ｂは、受信された“視聴要求”メッセージの送信元であるユーザノード１ａに対応する提供可否関連情報を保存しているアクセス権管理ノード１ｙ1〜１ｙ10に対して、当該コンテンツデータの提供可否をネットワーク１０を介して確認する。例えば、“視聴要求”メッセージに含まれるユーザ登録番号に基づいて互いに異なる複数（ここでは、１０個）のユーザＩＤを生成（ユーザＩＤの生成方法は、購入時の流れと同様）、夫々のユーザＩＤに対応する夫々のアクセス権管理ノード１ｙ1〜１ｙ10に対して（つまり、ユーザＩＤ及びＤＨＴに従って）、コンテンツデータの提供可否を確認するための確認情報としての“視聴確認”メッセージ（コンテンツＩＤ、ユーザＩＤ、コンテンツホルダノード１ｂのＩＰアドレス、及び課金方式を含む）を送信することにより確認する。送信された“視聴確認”メッセージは、ＤＨＴに従って中継ノードを転送されていき、夫々のユーザＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する（つまり、夫々のユーザＩＤに対応する）アクセス権管理ノード１ｙ1〜１ｙ10に到着する。
【００７２】
夫々のアクセス権管理ノード１ｙ1〜１ｙ10は、コンテンツデータの保存元であるコンテンツホルダノード１ｂから中継ノード及びネットワーク１０を介して送信されてきた“視聴確認”メッセージを受信すると、“視聴確認”メッセージに関わるコンテンツデータ（つまり、当該コンテンツＩＤに対応するコンテンツデータ）の提供（ここでは、視聴）が可能か否かを当該ユーザＩＤに対応する提供可否関連情報を参照して判別する。例えば、“視聴確認”メッセージ中のコンテンツＩＤが、提供可否関連情報中の購入コンテンツリストに含まれている場合は、視聴可能と判別される。一方、“視聴確認”メッセージ中のコンテンツＩＤが、提供可否関連情報中の購入コンテンツリストに含まれていない場合は、“視聴確認”メッセージ中の課金方式が確認され、前払いであれば、提供可否関連情報に含まれるプール金額（前払い金額）の残高から当該コンテンツＩＤに対応するコンテンツデータの価格（コンテンツの電子カタログを参照する）が引かれ、マイナスになれば視聴不可と判別され、マイナスにならなければ視聴可能と判別される。また、“視聴確認”メッセージ中のコンテンツＩＤが、提供可否関連情報中の購入コンテンツリストに含まれていない場合であって、“視聴確認”メッセージ中の課金方式が後払いであれば、視聴可能と判別される。
【００７３】
そして、夫々のアクセス権管理ノード１ｙ1〜１ｙ10は、コンテンツＩＤが購入コンテンツリストに含まれておらず、かつ、前払いであって視聴可能と判別した場合、当該ユーザＩＤに対応する提供可否関連情報に含まれるプール金額（前払い金額）の残高から当該コンテンツＩＤに対応するコンテンツデータの価格が引かれた金額をプール金額（前払い金額）として更新し、一方、前払いであって視聴不可と判別した場合、プール金額（前払い金額）の更新を行わない。また、夫々のアクセス権管理ノード１ｙ1〜１ｙ10は、コンテンツＩＤが購入コンテンツリストに含まれておらず、かつ、後払いであって視聴可能と判別した場合、提供可否関連情報に含まれる後日請求金額（後払い金額）に当該コンテンツデータの価格を加算する更新を行う。なお、ユーザＩＤに対応する提供可否関連情報が未だ作成されていない場合には、このタイミングで作成されることになる。
【００７４】
次いで、夫々のアクセス権管理ノード１ｙ1〜１ｙ10は、“視聴確認”メッセージを送信したコンテンツホルダノード１ｂに対して、上記判別された視聴可否（視聴可能或いは不可）及び課金情報（例えば、プール金額（前払い金額）又は後日請求金額（後払い金額）を含む）を含む“視聴可否”メッセージをネットワーク１０を介して返信する。なお、アクセス権管理ノードが１つである場合には、“視聴可否”メッセージは、アクセス権管理ノードからネットワーク１０を介して直接ユーザノード１ａに送信されるように構成しても良い。
【００７５】
そして、コンテンツホルダノード１ｂは、上記“視聴確認”メッセージに応じて夫々のアクセス権管理ノード１ｙ1〜１ｙ10から返信されてきた“視聴可否”メッセージを受信し、これによって視聴可否を確認し、続いて、“視聴要求”メッセージの送信元であるユーザノード１ａに対して、当該確認された視聴可否に基づく回答情報を含むコンテンツデータをネットワーク１０を介して送信することになる。
【００７６】
ところで、正常ならば１０個のアクセス権管理ノード１ｙ1〜１ｙ10から、“視聴可否"メッセージがコンテンツホルダノード１ｂに返信されて１０個とも同じ回答が返ってくる筈であるが、何れかのアクセス権管理ノード１ｙ1〜１ｙ10が、電源断や通信事故等により、一時的にコンテンツ配信システムＳから脱退していたことにより、１０個の夫々のアクセス権管理ノード１ｙ1〜１ｙ10が有する提供可否関連情報が食い違う場合があり得る。かかる場合、コンテンツホルダノード１ｂは、上記確認された複数の視聴可否に基づいて（例えば、多数決により）、当該コンテンツデータの視聴可否を決定、例えば過半数以上のアクセス権管理ノードが視聴可能とした場合、視聴可能と決定し、当該視聴可能及び課金情報を含む“視聴可否"メッセージを含むコンテンツデータを、ユーザノード１ａに対してネットワーク１０を介して送信する。一方、例えば過半数以上のアクセス権管理ノードが視聴不可とした場合、コンテンツホルダノード１ｂは、視聴不可と決定し、当該視聴不可及び課金情報を含む“視聴可否"メッセージを含むコンテンツデータを、ユーザノード１ａに対してネットワーク１０を介して送信する。
【００７７】
そして、上記決定された提供可否（最も多い回答：視聴可能又は視聴不可）と異なる提供可否に基づく回答情報（回答）を返信したアクセス権管理ノードに対しては、提供可否関連情報の修正が行われる。具体的には、アクセス権管理ノード１ｙ1〜１ｙ10からの“視聴可否"メッセージには、現状の課金情報が含まれるので、多数決で選択されたアクセス権管理ノードの課金情報を正当とみなし（同じ視聴可能を返信した中でも、課金情報が食い違うこともあり得るが、その場合も、最も一致するものが多い課金情報を正当とみなし）、正当とみなされない課金情報を含む“視聴可否"メッセージを返信したアクセス権管理ノードに対して、提供可否関連情報の修正要求を示す修正要求情報として、ユーザＩＤ及び修正課金情報（正当とみなされた課金情報）を含む“情報修正"メッセージを、上述したようにユーザＩＤ及びＤＨＴに従ってネットワーク１０を介して送信する。そして、“情報修正"メッセージを受信したアクセス権管理ノードは、“情報修正"メッセージ中の修正課金情報に基づいて、提供可否関連情報に含まれる課金情報を修正（当該課金情報を修正課金情報に更新）する。これにより、アクセス権管理ノード１ｙ1〜１ｙ10の相互間で課金情報の食い違いが発生したとしても、同じになるように修正することができる。
【００７８】
（iv）課金情報収集時の流れ
図９は、ＤＨＴのノードＩＤ空間における課金情報収集時の情報の流れの一例を示す図である。
【００７９】
先ず、課金管理センターＣは、一定期間（例えば、月に一回程度）毎に、その制御下にある会計ノード１ｚに対して、ユーザ登録番号を含む課金情報（後日請求金額）収集指示を示す請求金額収集指示情報を送信する。会計ノード１ｚは、当該請求金額収集指示情報を受信すると、当該ユーザ登録番号に基づいて互いに異なる複数のユーザＩＤを生成する。例えば、ユーザ登録番号の末尾に、０，１，２，３，４，５，６，７，８，９の１０種類の数字が付加された番号が作成され、夫々の番号が、上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化されて複数のユーザＩＤが生成される。なお、課金管理センターＣは、全てのユーザノードに対応するユーザ登録番号を含む請求金額収集指示情報を会計ノード１ｚに対して送信することになるが、各ユーザノードに対応する請求金額収集指示情報を、所定時間間隔（例えば、１時間）毎に会計ノード１ｚに対して送信するようにすれば、ネットワーク負荷を低減できるので、好ましい。
【００８０】
以下の説明では、１つのユーザノード１ａに対応するユーザ登録番号を含む請求金額収集指示を代表して説明する。
【００８１】
会計ノード１ｚは、複数のユーザＩＤを生成すると、夫々のユーザＩＤに対応する夫々のアクセス権管理ノード１ｙ1〜１ｙ10に対して（つまり、ユーザＩＤ及びＤＨＴに従って）、ユーザＩＤ及び会計ノード１ａのＩＰアドレスを含む“課金収集"メッセージを送信する。送信された“課金収集”メッセージは、ＤＨＴに従って中継ノードを転送されていき、夫々のユーザＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する（つまり、夫々のユーザＩＤに対応する）アクセス権管理ノード１ｙ1〜１ｙ10に到着する。
【００８２】
上記“課金収集”メッセージを受信した夫々のアクセス権管理ノード１ｙ1〜１ｙ10は、提供可否関連情報から後日請求金額（後払い金額）を取得し、当該後日請求金額及びユーザＩＤを含む“請求額回答"メッセージを会計ノード１ｚに対して送信（返信）すると共に、提供可否関連情報に含まれる後日請求金額（後払い金額）を“０”に更新する（戻す）。
【００８３】
そして、会計ノード１ｚは、夫々のアクセス権管理ノード１ｙ1〜１ｙ10から返信されてきた“請求額回答"メッセージを受信すると、当該“請求額回答"メッセージに含まれる後日請求金額を示す情報を課金管理センターＣに対して送信する。これにより、課金管理センターＣからユーザに対して後日請求金額の請求が行われることになる。
【００８４】
ところで、正常ならば１０個のアクセス権管理ノード１ｙ1〜１ｙ10から、“請求額回答"メッセージが会計ノード１ｚに返信されて１０個とも同じ回答が返ってくる筈であるが、何れかのアクセス権管理ノード１ｙ1〜１ｙ10が、電源断や通信事故等により、一時的にコンテンツ配信システムＳから脱退していたことにより、１０個の夫々のアクセス権管理ノード１ｙ1〜１ｙ10が有する後日請求金額が食い違う場合があり得る。かかる場合、会計ノード１ｚは、例えば、多数決により当該請求金額（例えば、最も一致するものが多い請求金額）を決定し、決定された請求金額を示す情報を課金管理センターＣに対して送信する。
【００８５】
次に、図１０乃至図２１等を参照して、コンテンツ配信システムＳにおける各ノードにおける処理について説明する。
【００８６】
なお、図１０は、上述したメッセージ種別毎に含まれるパラメータ（情報）を示す図である。
【００８７】
（v）ユーザノードにおける処理
図１１は、ユーザノードにおける制御部１１の処理を示すフローチャートである。
【００８８】
図１１の処理は、例えば表示部１６における表示画面上に電子カタログが表示されている状態において、入力部２１におけるボタンが押下されたときに実行され、制御部１１は、先ず、押下されたボタンの状態を読み取り（ステップＳ１）、“購入ボタン”であるか否かを判別し（ステップＳ２）、“購入ボタン”である場合には（ステップＳ２：Ｙ（ＹＥＳ））、選択されたコンテンツに対応するコンテンツＩＤ（例えば、当該コンテンツ名をノードＩＤを得るときと共通のハッシュ関数によりハッシュ化して得る）と、ＩＣカードリーダ部１９によりＩＣカードから読み取られたユーザ登録番号及び課金方式と、更には、当該ユーザノード１ａのＩＰアドレスと、を取得し、これらの情報が含まれる“購入申込”メッセージを生成して、これをＤＨＴに従ってルートノード１ｘに向けて通信部２０等を介して送信する（ステップＳ３）。これに対してコンテンツホルダノード１ｂから送信されてきた“購入可否”メッセージを制御部１１は受信し（ステップＳ４）、当該メッセージに含まれる購入可否の結果を表示部１６に表示する（ステップＳ５）。
【００８９】
一方、“購入ボタン”でない場合には（ステップＳ２：Ｎ（ＮＯ））、制御部１１は、“視聴ボタン”であるか否かを判別し（ステップＳ６）、“視聴ボタン”である場合には（ステップＳ６：Ｙ）、選択されたコンテンツに対応するコンテンツＩＤと、ＩＣカードリーダ部１９によりＩＣカードから読み取られたユーザ登録番号及び課金方式と、更には、当該ユーザノード１ａのＩＰアドレスと、を取得し、これらの情報が含まれる“視聴要求”メッセージを生成して、これをＤＨＴに従ってルートノード１ｘに向けて通信部２０等を介して送信する（ステップＳ７）。これに対してコンテンツホルダノード１ｂから送信（例えば、ストリーミング配信）されてきた“視聴可否"メッセージを含むコンテンツデータを制御部１１は受信し（ステップＳ８）、当該コンテンツデータをバッファメモリ１３に蓄積しつつ、映像処理部１５を介して表示部１６に表示（視聴可の場合、コンテンツデータに含まれる視聴可を示す情報及び当該コンテンツに係るビデオデータ等を表示、視聴不可の場合、コンテンツデータに含まれる視聴不可を示す情報のみを表示）し、音声処理部１７を介してスピーカ１８から出力する（ステップＳ９）。
【００９０】
なお、図１１に示すステップＳ１０では、制御部１１が実行するその他の処理（例えば、その他のボタンの判別処理）が行われるが、本発明と直接の関係がないので、説明を省略する。
【００９１】
（vi）中継ノード、ルートノード、及びコンテンツホルダノードにおける処理
図１２は、中継ノード、ルートノード、及びコンテンツホルダノードにおける制御部１１の処理を示すフローチャートであり、図１３は、図１２に示すステップＳ１４における処理の詳細（サブルーチン）を示すフローチャートであり、図１４は、図１２に示すステップＳ２０における処理の詳細（サブルーチン）を示すフローチャートである。
【００９２】
図１２に示す処理は、メッセージ受信イベントが発生（送信されてきたメッセージを、制御部１１が通信部２０を介して受信）したときに実行され、制御部１１は、先ず、受信したメッセージを読み取り（ステップＳ１１）、“視聴要求”メッセージであるか否かを判別し（ステップＳ１２）、“視聴要求”メッセージである（つまり、制御部１１が要求情報受信手段として受信した）場合には（ステップＳ１２：Ｙ）、自己がコンテンツホルダノード１ｂであるか否かを判別する（ステップＳ１３）。自己がコンテンツホルダノード１ｂであるか否かは、例えば、当該メッセージに含まれるコンテンツＩＤが、自己の記憶部１２に記憶しているコンテンツデータに対応するものであるか否かにより判別される。
【００９３】
そして、自己がコンテンツホルダノード１ｂである場合には（ステップＳ１３：Ｙ）、ステップＳ１４に移行され、コンテンツホルダノード１ｂでない場合には（ステップＳ１３：Ｎ）、ステップＳ１５に移行される。なお、ステップＳ１４の“視聴要求”メッセージの処理の詳細（図１３）は後述する。
【００９４】
ステップＳ１５では、制御部１１は、自己がルートノード１ｘであるか否かを判別する。自己がルートノード１ｘであるか否かは、例えば、当該メッセージに含まれるコンテンツＩＤに自己のノードＩＤが最も近いか否か（ＤＨＴをみて、他に転送すべきノードがないか否か）により判別される。
【００９５】
そして、自己がルートノード１ｘでない場合（つまり、中継ノードである場合）には（ステップＳ１５：Ｎ）、制御部１１は、“視聴要求”メッセージを、ＤＨＴに従ってルートノード１ｘに向けて通信部２０等を介して送信する（ステップＳ１６）。
【００９６】
一方、自己がルートノード１ｘである場合には（ステップＳ１５：Ｙ）、制御部１１は、“視聴要求”メッセージを、コンテンツホルダノード１ｂのＩＰアドレスに従って通信部２０等を介してコンテンツホルダノード１ｂに送信する（ステップＳ１７）。なお、ルートノード１ｘは、コンテンツホルダノード１ｂのＩＰアドレスを記憶部１２に記憶保存している所在情報から取得することになる。
【００９７】
上記ステップＳ１２において視聴要求”メッセージでない場合には（ステップＳ１２：Ｎ）、制御部１１は、“購入申込”メッセージであるか否かを判別し（ステップＳ１８）、“購入申込”メッセージである場合には（ステップＳ１８：Ｙ）、上記ステップＳ１３と同様、自己がコンテンツホルダノード１ｂであるか否かを判別する（ステップＳ１９）。
【００９８】
そして、自己がコンテンツホルダノード１ｂである場合には（ステップＳ１９：Ｙ）、ステップＳ２０に移行され、コンテンツホルダノード１ｂでない場合には（ステップＳ１９：Ｎ）、ステップＳ２１に移行される。なお、ステップＳ２０の“購入申込”メッセージの処理の詳細（図１４）は後述する。
【００９９】
ステップＳ２１では、制御部１１は、上記ステップＳ１５と同様、自己がルートノード１ｘであるか否かを判別する。そして、自己がルートノード１ｘでない場合（つまり、中継ノードである場合）には（ステップＳ２１：Ｎ）、制御部１１は、“購入申込”メッセージを、ＤＨＴに従ってルートノード１ｘに向けて通信部２０等を介して送信する（ステップＳ２２）。
【０１００】
一方、自己がルートノード１ｘである場合には（ステップＳ２１：Ｙ）、制御部１１は、“購入申込”メッセージを、コンテンツホルダノード１ｂのＩＰアドレスに従って通信部２０等を介してコンテンツホルダノード１ｂに送信する（ステップＳ２３）。
【０１０１】
なお、上記ステップＳ１５又はステップＳ２１において自己がルートノード１ｘである場合に、当該メッセージに含まれるコンテンツＩＤに対応するコンテンツデータを保存している複数のコンテンツホルダノードのＩＰアドレスを認識している場合には、そのうち１つのコンテンツホルダノード１ｂを選定（例えば、ランダムに選定）してこれに転送することになる。
【０１０２】
また、図１２に示すステップＳ２４では、例えば、図１５に示すアクセス権管理ノードにおける制御部１１のメッセージ処理が行われる。
【０１０３】
次に、図１３に示す処理において、制御部１１は、“視聴要求”メッセージ中のユーザ登録番号に基づいて（例えば、上述したようにユーザ登録番号をハッシュ化して）互いに異なる複数（ここでは、１０個）のユーザＩＤを生成する（ステップＳ３１）。
【０１０４】
次いで、制御部１１は、アクセス権管理ノードの数を示す“ｎ”の値を初期化（“１”に設定）し（ステップＳ３２）、コンテンツデータの視聴可否を確認するための確認情報としての“視聴確認”メッセージを生成し、これをＤＨＴに従ってｎ番目のユーザＩＤに対応するアクセス権管理ノード１ｙｎに向けて通信部２０等を介して送信する（ステップＳ３３）。これに対してアクセス権管理ノード１ｙｎから送信（返信）されてきた“視聴可否”メッセージを受信し（ステップＳ３４）、記憶部１２に記憶する。
【０１０５】
次いで、制御部１１は、上記“ｎ”を“１”だけインクリメントし（ステップＳ３５）、当該“ｎ”が“１０”より大きいか否かを判別し（ステップＳ３６）、“ｎ＞１０”でない場合には（ステップＳ３６：Ｎ）、ステップＳ３３に戻り同様の処理を繰り返す。こうして、制御部１１は、提供可否確認手段として、アクセス権管理ノード１ｙ1〜１ｙ10から夫々の“視聴可否”メッセージを取得し、当該コンテンツデータの視聴可否を確認することになる。
【０１０６】
一方、“ｎ＞１０”である場合には（ステップＳ３６：Ｙ）、制御部１１は、全ての“視聴可否”メッセージに含まれる“視聴可否”を集計し、例えばその過半数が視聴可能であるか否かを判別し（ステップＳ３７）、過半数が視聴可能である場合には（ステップＳ３７：Ｙ）、提供可否確認手段として視聴可能と決定し、当該視聴可能及び課金情報を含む“視聴可否"メッセージ（確認された提供可否に基づく回答情報）を含むコンテンツデータ（なお、確認された提供可否に基づく回答情報がコンテンツデータであっても良い）を、提供可否情報送信手段として、ユーザノード１ａのＩＰアドレスに従って通信部２０等を介してユーザノード１ａに送信（例えば、ストリーミング配信）する（ステップＳ３８）。続いて、制御部１１は、上記“視聴可否”メッセージに含まれる課金情報のうち最も一致する数が多い課金情報を修正課金情報として選定し、修正要求情報送信手段として、当該修正課金情報及びユーザＩＤを含む“情報修正"メッセージを生成し、これをＤＨＴに従って視聴不可を返信したアクセス権管理ノードに向けて通信部２０等を介して送信し（ステップＳ３９）、図１２に示す処理に戻る。
【０１０７】
一方、ステップＳ３７において、過半数が視聴可能でない場合には（ステップＳ３７：Ｎ）、視聴不可と決定し、当該視聴不可及び課金情報を含む“視聴可否"メッセージを含むコンテンツデータを、ユーザノード１ａのＩＰアドレスに従って通信部２０等を介してユーザノード１ａに送信する（ステップＳ４０）。続いて、制御部１１は、上記“視聴可否”メッセージに含まれる課金情報のうち最も一致する数が多い課金情報を修正課金情報として選定し、当該修正課金情報及びユーザＩＤを含む“情報修正"メッセージを生成し、これをＤＨＴに従って視聴可能を返信したアクセス権管理ノードに向けて通信部２０等を介して送信し（ステップＳ４１）、図１２に示す処理に戻る。
【０１０８】
次に、図１４に示す処理において、制御部１１は、“購入申込”メッセージ中のユーザ登録番号に基づいて（例えば、上述したようにユーザ登録番号をハッシュ化して）互いに異なる複数（ここでは、１０個）のユーザＩＤを生成する（ステップＳ５１）。
【０１０９】
次いで、制御部１１は、アクセス権管理ノードの数を示す“ｎ”の値を初期化（“１”に設定）し（ステップＳ５２）、コンテンツデータの購入可否を確認するための確認情報としての“購入登録”メッセージを生成し、これをＤＨＴに従ってｎ番目のユーザＩＤに対応するアクセス権管理ノード１ｙｎに向けて通信部２０等を介して送信する（ステップＳ５３）。これに対してアクセス権管理ノード１ｙｎから送信（返信）されてきた“購入可否”メッセージを受信し（ステップＳ５４）、記憶部１２に記憶する。
【０１１０】
次いで、制御部１１は、上記“ｎ”を“１”だけインクリメントし（ステップＳ５５）、当該“ｎ”が“１０”より大きいか否かを判別し（ステップＳ５６）、“ｎ＞１０”でない場合には（ステップＳ５６：Ｎ）、ステップＳ５３に戻り同様の処理を繰り返す。こうして、制御部１１は、提供可否確認手段として、アクセス権管理ノード１ｙ1〜１ｙ10から夫々の“購入可否”メッセージを取得し、当該コンテンツデータの購入可否を確認することになる。
【０１１１】
一方、“ｎ＞１０”である場合には（ステップＳ５６：Ｙ）、制御部１１は、全ての“購入可否”メッセージに含まれる“購入可否”を集計し、例えばその過半数が購入可能であるか否かを判別し（ステップＳ５７）、過半数が購入可能である場合には（ステップＳ５７：Ｙ）、提供可否確認手段として購入可能と決定し、当該購入可能及び課金情報を含む“購入可否"メッセージを、提供可否情報送信手段として、ユーザノード１ａのＩＰアドレスに従って通信部２０等を介してユーザノード１ａに送信する（ステップＳ５８）。続いて、制御部１１は、上記“購入可否”メッセージに含まれる課金情報のうち最も一致する数が多い課金情報を修正課金情報として選定し、修正要求情報送信手段として、当該修正課金情報及びユーザＩＤを含む“情報修正"メッセージを生成し、これをＤＨＴに従って購入不可を返信したアクセス権管理ノードに向けて通信部２０等を介して送信し（ステップＳ５９）、図１２に示す処理に戻る。
【０１１２】
一方、ステップＳ５７において、過半数が購入可能でない場合には（ステップＳ５７：Ｎ）、購入不可と決定し、当該購入不可及び課金情報を含む“購入可否"メッセージを、ユーザノード１ａのＩＰアドレスに従って通信部２０等を介してユーザノード１ａに送信する（ステップＳ６０）。続いて、制御部１１は、上記“購入可否”メッセージに含まれる課金情報のうち最も一致する数が多い課金情報を修正課金情報として選定し、当該修正課金情報及びユーザＩＤを含む“情報修正"メッセージを生成し、これをＤＨＴに従って購入可能を返信したアクセス権管理ノードに向けて通信部２０等を介して送信し（ステップＳ６１）、図１２に示す処理に戻る。
【０１１３】
（vii）アクセス権管理ノードにおける処理
図１５は、アクセス権管理ノードにおける制御部１１の処理を示すフローチャートであり、図１６は、図１５に示すステップＳ７３における処理の詳細（サブルーチン）を示すフローチャートであり、図１７は、図１５に示すステップＳ７５における処理の詳細（サブルーチン）を示すフローチャートであり、図１８は、図１５に示すステップＳ７７における処理の詳細（サブルーチン）を示すフローチャートである。
【０１１４】
図１５に示す処理は、メッセージ受信イベントが発生（送信されてきたメッセージを制御部１１が通信部２０を介して受信）したときに実行され、制御部１１は、先ず、受信したメッセージを読み取り（ステップＳ７１）、そのメッセージが“購入登録”メッセージであるか否かを判別し（ステップＳ７２）、“購入登録”メッセージである（つまり、制御部１１が確認情報受信手段として受信した）場合には（ステップＳ７２：Ｙ）、ステップＳ７３に移行され、“購入登録”メッセージでない場合には（ステップＳ７２：Ｎ）、ステップＳ７４に移行される。なお、ステップＳ７３の“購入登録”メッセージの処理の詳細（図１６）は後述する。
【０１１５】
ステップＳ７４では、制御部１１は、受信したメッセージが“視聴確認”メッセージであるか否かを判別し、“視聴確認”メッセージである（つまり、制御部１１が確認情報受信手段として受信した）場合には（ステップＳ７４：Ｙ）、ステップＳ７５に移行され、“視聴確認”メッセージでない場合には（ステップＳ７４：Ｎ）、ステップＳ７６に移行される。なお、ステップＳ７５の“視聴確認”メッセージの処理の詳細（図１７）は後述する。
【０１１６】
ステップＳ７６では、制御部１１は、受信したメッセージが“前払い”メッセージであるか否かを判別し、“前払い”メッセージである場合には（ステップＳ７６：Ｙ）、ステップＳ７７に移行され、“前払い”メッセージでない場合には（ステップＳ７６：Ｎ）、ステップＳ７８に移行される。なお、ステップＳ７７の“前払い”メッセージの処理の詳細（図１８）は後述する。
【０１１７】
ステップＳ７８では、制御部１１は、受信したメッセージが“課金収集”メッセージであるか否かを判別し、“課金収集”メッセージである場合には（ステップＳ７８：Ｙ）、ステップＳ７９に移行され、“課金収集”メッセージでない場合には（ステップＳ７８：Ｎ）、ステップＳ８１に移行される。
【０１１８】
ステップＳ７９では、制御部１１は、提供可否関連情報から後日請求金額（後払い金額）を取得して“請求額回答"メッセージを生成し、これを会計ノード１ｚのＩＰアドレスに従って通信部２０等を介して会計ノード１ｚに送信（返信）する。そして、制御部１１は、提供可否関連情報に含まれる後日請求金額（後払い金額）を“０”に更新する（ステップＳ８０）。
【０１１９】
ステップＳ８１では、制御部１１は、受信したメッセージが“情報修正”メッセージであるか否かを判別し、“情報修正”メッセージである（つまり、制御部１１が修正要求情報受信手段として受信した）場合には（ステップＳ８１：Ｙ）、提供可否関連情報修正手段として、当該情報修正"メッセージ中の修正課金情報に基づいて、提供可否関連情報に含まれる課金情報を修正（当該課金情報を修正課金情報に更新）する（ステップＳ８２）。
【０１２０】
一方、“情報修正”メッセージでない場合には（ステップＳ８１：Ｎ）、ステップＳ８３に移行される。なお、当該ステップＳ８３では、例えば、図１２に示す中継ノード、ルートノード、及びコンテンツホルダノードにおける制御部１１のメッセージ処理が行われる。
【０１２１】
次に、図１６に示す処理において、制御部１１は、“購入登録”メッセージ中のユーザＩＤに対応する提供可否関連情報が既に作成されているか否かを判別し（ステップＳ９１）、既に作成されている場合には（ステップＳ９１：Ｙ）、ステップＳ９３に移行し、未だ作成されていない場合には（ステップＳ９１：Ｎ）、新たに、提供可否関連情報を作成し（ステップＳ９２）、ステップＳ９３に移行する。
【０１２２】
ステップＳ９３では、制御部１１は、“購入登録”メッセージ中の課金方式が前払い方式であるか否かを判別し、前払い方式でない場合には（ステップＳ９３：Ｎ）、提供可否判別手段として購入可能と判別し、続いて、提供可否関連情報更新手段として、当該“購入登録”メッセージ中のコンテンツＩＤ等を購入コンテンツリストに追加する（ステップＳ９４）と共に、上記提供可否関連情報に含まれる後日請求金額（後払い金額）に当該コンテンツデータの価格を加算する（ステップＳ９５）更新を行い、ステップＳ９６に移行する。
【０１２３】
一方、ステップＳ９３において“購入登録”メッセージ中の課金方式が前払い方式である場合には（ステップＳ９３：Ｙ）、制御部１１は、“購入登録”メッセージ中のユーザＩＤに対応する提供可否関連情報に含まれるプール金額（前払い金額）の残高から当該コンテンツＩＤに対応するコンテンツデータの価格を減算し（ステップＳ９７）、当該残高がマイナスになったか否かを判別する（ステップＳ９８）。
【０１２４】
当該残高がマイナスにならなかった場合には（ステップＳ９８：Ｎ）、制御部１１は、提供可否判別手段として購入可能と判別し、続いて、提供可否関連情報更新手段として、“購入登録”メッセージ中のコンテンツＩＤ等を購入コンテンツリストに追加すると共に、提供可否関連情報に含まれるプール金額の残高から当該コンテンツＩＤに対応するコンテンツデータの価格が減算された金額をプール金額として更新し（ステップＳ９９）、ステップＳ９６に移行する。
【０１２５】
ステップＳ９６では、制御部１１は、提供可否情報返信手段として、上記判別された購入可能及び課金情報を含む“購入可否”メッセージを生成し、これをコンテンツホルダノード１ｂのＩＰアドレスに従って通信部２０等を介してコンテンツホルダノード１ｂに送信（返信）する。
【０１２６】
一方、ステップＳ９８において残高がマイナスになった場合には（ステップＳ９８：Ｙ）、制御部１１は、提供可否判別手段として購入不可と判別し、当該購入不可等を含む“購入可否”メッセージを生成し、これをコンテンツホルダノード１ｂのＩＰアドレスに従って通信部２０等を介してコンテンツホルダノード１ｂに送信（返信）して（ステップＳ１００）、図１５に示す処理に戻る。
【０１２７】
次に、図１７に示す処理において、制御部１１は、“視聴確認”メッセージ中のユーザＩＤに対応する提供可否関連情報が既に作成されているか否かを判別し（ステップＳ１１１）、既に作成されている場合には（ステップＳ１１１：Ｙ）、ステップＳ１１３に移行し、未だ作成されていない場合には（ステップＳ１１１：Ｎ）、新たに、提供可否関連情報を作成し（ステップＳ１１２）、ステップＳ１１３に移行する。
【０１２８】
ステップＳ１１３では、制御部１１は、“視聴確認”メッセージ中のコンテンツＩＤが、提供可否関連情報中の購入コンテンツリストに含まれているか否かを判別し、含まれている場合には（ステップＳ１１３：Ｙ）、提供可否判別手段として視聴可能と判別して、ステップＳ１１７に移行する。
【０１２９】
一方、コンテンツＩＤが購入コンテンツリストに含まれていない場合には（ステップＳ１１３：Ｎ）、制御部１１は、“視聴確認”メッセージ中の課金方式が前払い方式であるか否かを判別し、前払い方式でない場合には（ステップＳ１１４：Ｎ）、提供可否判別手段として視聴可能と判別し、続いて、提供可否関連情報更新手段として、当該“視聴確認”メッセージ中のコンテンツＩＤ等を購入コンテンツリストに追加する（ステップＳ１１５）と共に、上記提供可否関連情報に含まれる後日請求金額（後払い金額）に当該コンテンツデータの価格を加算する（ステップＳ１１６）更新を行い、ステップＳ１１７に移行する。
【０１３０】
一方、ステップＳ１１４において“視聴確認”メッセージ中の課金方式が前払い方式である場合には（ステップＳ１１４：Ｙ）、制御部１１は、“視聴確認”メッセージ中のユーザＩＤに対応する提供可否関連情報に含まれるプール金額（前払い金額）の残高から当該コンテンツＩＤに対応するコンテンツデータの価格を減算し（ステップＳ１１８）、当該残高がマイナスになったか否かを判別する（ステップＳ１１９）。
【０１３１】
当該残高がマイナスにならなかった場合には（ステップＳ１１９：Ｎ）、制御部１１は、提供可否判別手段として視聴可能と判別し、続いて、提供可否関連情報更新手段として、“視聴確認”メッセージ中のコンテンツＩＤ等を購入コンテンツリストに追加すると共に、提供可否関連情報に含まれるプール金額の残高から当該コンテンツＩＤに対応するコンテンツデータの価格が減算された金額をプール金額として更新し（ステップＳ１２０）、ステップＳ１１７に移行する。
【０１３２】
ステップＳ１１７では、制御部１１は、提供可否情報返信手段として、上記判別された視聴可能及び課金情報を含む“視聴確認”メッセージを生成し、これをコンテンツホルダノード１ｂのＩＰアドレスに従って通信部２０等を介してコンテンツホルダノード１ｂに送信（返信）する。
【０１３３】
一方、ステップＳ１１９において残高がマイナスになった場合には（ステップＳ１１９：Ｙ）、制御部１１は、提供可否判別手段として視聴不可と判別し、当該視聴不可等を含む“視聴可否”メッセージを生成し、これをコンテンツホルダノード１ｂのＩＰアドレスに従って通信部２０等を介してコンテンツホルダノード１ｂに送信（返信）して（ステップＳ１２１）、図１５に示す処理に戻る。
【０１３４】
次に、図１８に示す処理において、制御部１１は、“前払い”メッセージ中のユーザＩＤに対応する提供可否関連情報が既に作成されているか否かを判別し（ステップＳ１３１）、既に作成されている場合には（ステップＳ１３１：Ｙ）、ステップＳ１３３に移行し、未だ作成されていない場合には（ステップＳ１３１：Ｎ）、新たに、提供可否関連情報を作成し（ステップＳ１３２）、ステップＳ１３３に移行する。そして、制御部１１は、“前払い”メッセージ中の入金額を、提供可否関連情報に含まれるプール金額（前払い金額）に加算し（ステップＳ１３３）、これを記憶部１２に記憶保存して、図１５に示す処理に戻る。
【０１３５】
（viii）会計ノードにおける処理
図１９は、会計ノードにおける制御部１１の処理を示すフローチャートであり、図２０は、図１９に示すステップＳ１４３における処理の詳細（サブルーチン）を示すフローチャートであり、図２１は、図１９に示すステップＳ１４５における処理の詳細（サブルーチン）を示すフローチャートである。
【０１３６】
図１９の処理において、制御部１１は、課金管理センターＣから送信されてきた指示情報を受信すると（ステップＳ１４１）、当該指示情報が入金指示情報であるか否かを判別し（ステップＳ１４２）、入金指示情報である場合には（ステップＳ１４２：Ｙ）、ステップＳ１４３に移行し、入金指示情報でない場合には（ステップＳ１４２：Ｎ）、ステップＳ１４４に移行する。なお、ステップＳ１４３の入金指示の処理の詳細（図２０）は後述する。
【０１３７】
ステップＳ１４４では、制御部１１は、上記課金管理センターＣからの指示情報が請求金額収集指示情報であるか否かを判別し、請求金額収集指示情報である場合には（ステップＳ１４４：Ｙ）、ステップＳ１４５に移行し、請求金額収集指示情報でない場合には（ステップＳ１４４：Ｎ）、ステップＳ１４６に移行する。なお、ステップＳ１４５の請求金額収集指示の処理の詳細（図２１）は後述する。また、図１９に示すステップＳ１４６では、例えば、図１２に示す中継ノード、ルートノード、及びコンテンツホルダノードにおける制御部１１のメッセージ処理、或いは、図１５に示すアクセス権管理ノードにおける制御部１１のメッセージ処理が行われる。
【０１３８】
次に、図２０に示す処理において、制御部１１は、入金指示情報に含まれるユーザ登録番号に基づいて（例えば、上述したようにユーザ登録番号をハッシュ化して）互いに異なる複数（ここでは、１０個）のユーザＩＤを生成する（ステップＳ１５１）。
【０１３９】
次いで、制御部１１は、アクセス権管理ノードの数を示す“ｎ”の値を初期化（“１”に設定）し（ステップＳ１５２）、ユーザＩＤ及び入金額を含む“前払い”メッセージを生成し、これをＤＨＴに従ってｎ番目のユーザＩＤに対応するアクセス権管理ノード１ｙｎに向けて通信部２０等を介して送信する（ステップＳ１５３）。
【０１４０】
次いで、制御部１１は、上記“ｎ”を“１”だけインクリメントし（ステップＳ１５４）、当該“ｎ”が“１０”より大きいか否かを判別し（ステップＳ１５５）、“ｎ＞１０”でない場合には（ステップＳ１５５：Ｎ）、ステップＳ１５３に戻り同様の処理を繰り返す。こうして、“前払い”メッセージを受信した夫々のアクセス権管理ノード１ｙ1〜１ｙ10において上記入金額が提供可否関連情報に登録されることになる。
【０１４１】
一方、“ｎ＞１０”である場合には（ステップＳ１５５：Ｙ）、図１９に示す処理に戻る。
【０１４２】
次に、図２１に示す処理において、制御部１１は、請求金額収集指示情報に含まれるユーザ登録番号に基づいて（例えば、上述したようにユーザ登録番号をハッシュ化して）互いに異なる複数（ここでは、１０個）のユーザＩＤを生成する（ステップＳ１６１）。
【０１４３】
次いで、制御部１１は、アクセス権管理ノードの数を示す“ｎ”の値を初期化（“１”に設定）し（ステップＳ１６２）、“課金収集”メッセージを生成して、これをＤＨＴに従ってｎ番目のユーザＩＤに対応するアクセス権管理ノード１ｙｎに向けて通信部２０等を介して送信する（ステップＳ１６３）。これに対してアクセス権管理ノード１ｙｎから送信（返信）されてきた“請求額回答”メッセージを受信し（ステップＳ１６４）、記憶部１２に記憶する。
【０１４４】
次いで、制御部１１は、上記“ｎ”を“１”だけインクリメントし（ステップＳ１６５）、当該“ｎ”が“１０”より大きいか否かを判別し（ステップＳ１６６）、“ｎ＞１０”でない場合には（ステップＳ１６６：Ｎ）、ステップＳ１６３に戻り同様の処理を繰り返す。こうして、会計ノード１zは、夫々のアクセス権管理ノード１ｙ1〜１ｙ10から後日請求金額（後払い金額）を取得することになる。
【０１４５】
一方、“ｎ＞１０”である場合には（ステップＳ１６６：Ｙ）、制御部１１は、全ての“請求額回答”メッセージに含まれる“後日請求金額（後払い金額）”を比較し、例えば、最も一致するものが多い金額を請求金額として決定し、決定された請求金額を示す情報を課金管理センターＣに対して送信し（ステップＳ１６７）、図１９に示す処理に戻る。
【０１４６】
以上説明したように、上記実施形態によれば、コンテンツデータの提供可否に関連する提供可否関連情報であって夫々のユーザノードに対応する提供可否関連情報（例えば、課金を行うために必要な課金情報が含まれている）が、夫々のユーザノードのユーザＩＤに対応するアクセス権管理ノードに分散保存されるようにしておき、コンテンツホルダノードは、ユーザノードからコンテンツデータの“購入申込”又は“視聴要求”メッセージを受信すると、当該ユーザノードに対応する提供可否関連情報を保存しているアクセス権管理ノードに対して、当該コンテンツデータの提供（購入又は視聴）可否をネットワーク８を介して確認し、当該確認された提供可否を含むコンテンツデータを、上記ユーザノードに対して送信するようにしたので、コンテンツデータの提供可否に関する処理（例えば課金に関する処理）をユーザノード毎に分散させ、処理の集中を回避することができる。
【０１４７】
また、１つのユーザノードに対応する提供可否関連情報を、当該ユーザノードのユーザのユーザ登録番号に基づいて複数生成された互いに異なるユーザＩＤに夫々対応するアクセス権管理ノードに保存しておき、コンテンツホルダノードは、これら複数のアクセス権管理ノードに対して、当該コンテンツデータの提供（購入又は視聴）可否をネットワーク８を介して確認し、例えば多数決により当該可否を決定するようにしたので、アクセス権管理ノードが、電源断や通信事故等により、一時的にコンテンツ配信システムＳから脱退していた場合であっても、提供可否関連情報（例えば、課金情報）の正確性を保ち、コンテンツデータの提供可否を正確に決定することができ、また、正確に課金に関する処理を行うことができる。
【０１４８】
更に、夫々のアクセス権管理ノードが有する課金情報が食い違う場合であっても、上記決定された提供可否（最も多い回答：購入可能又は購入不可）と異なる回答を返信したアクセス権管理ノードに対しては、提供可否関連情報の修正を行うようにしたので、複数のアクセス権管理ノード間において提供可否関連情報の内容を一致させ、当該提供可否関連情報の正確性を保つことができる。
【０１４９】
なお、上記実施形態においては、複数のアクセス権管理ノードからの提供（購入又は視聴）可否に基づき、多数決により当該コンテンツデータの提供（購入又は視聴）可否を決定するようにしたが、これに限定されるものではなく、例えば、コンテンツ配信システムＳからの脱退履歴をも考慮してコンテンツデータの提供（購入又は視聴）可否を決定するようにしてもよい。
【０１５０】
また、上記実施形態においては、ＤＨＴを利用したアルゴリズムによって構築されたオーバーレイネットワーク９を前提として説明したが、本発明はこれに限定されるものではない。
【０１５１】
また、上記実施形態においては、コンテンツホルダノード１ｂが、アクセス権管理ノード１ｙ1〜１ｙ10に対して、当該コンテンツデータの提供可否を確認するように構成したが、これに限定されるものではなく、ルートノード１ｘが、当該コンテンツデータの提供可否を確認し、当該確認された提供可否に基づく回答情報をネットワーク１０を介してユーザノード１ａに対して送信するように構成してもよい。
【図面の簡単な説明】
【０１５２】
【図１】本実施形態に係るコンテンツ配信システムにおける各ノード装置の接続態様の一例を示す図である。
【図２】ＤＨＴのノードＩＤ空間において、ユーザノードから送出されたクエリがルートノードまで転送される様子の一例を示す図である。
【図３】ＤＨＴのノードＩＤ空間において、ユーザノードからクエリが送出された後、当該ユーザノードに対してコンテンツデータが送信される様子の一例を示す図である。
【図４】ノード１の概要構成例を示す図である。
【図５】ＤＨＴのノードＩＤ空間における前払い時の情報の流れの一例を示す図である。
【図６】アクセス権管理ノードに保存されている提供可否関連情報の一例を示す図である。
【図７】ＤＨＴのノードＩＤ空間における購入時の情報の流れの一例を示す図である。
【図８】ＤＨＴのノードＩＤ空間における視聴時の情報の流れの一例を示す図である。
【図９】ＤＨＴのノードＩＤ空間における課金情報収集時の情報の流れの一例を示す図である。
【図１０】メッセージ種別毎に含まれるパラメータ（情報）を示す図である。
【図１１】ユーザノードにおける制御部１１の処理を示すフローチャートである。
【図１２】中継ノード、ルートノード、及びコンテンツホルダノードにおける制御部１１の処理を示すフローチャートである。
【図１３】図１２に示すステップＳ１４における処理の詳細（サブルーチン）を示すフローチャートである。
【図１４】図１２に示すステップＳ２０における処理の詳細（サブルーチン）を示すフローチャートである。
【図１５】アクセス権管理ノードにおける制御部１１の処理を示すフローチャートである。
【図１６】図１５に示すステップＳ７３における処理の詳細（サブルーチン）を示すフローチャートである。
【図１７】図１５に示すステップＳ７５における処理の詳細（サブルーチン）を示すフローチャートである。
【図１８】図１５に示すステップＳ７７における処理の詳細（サブルーチン）を示すフローチャートである。
【図１９】会計ノードにおける制御部１１の処理を示すフローチャートであり、
【図２０】図１９に示すステップＳ１４３における処理の詳細（サブルーチン）を示すフローチャートである。
【図２１】図１９に示すステップＳ１４５における処理の詳細（サブルーチン）を示すフローチャートである。
【符号の説明】
【０１５３】
１  ノード装置
８  ネットワーク
１１  制御部
１２  記憶部
１３  バッファメモリ
１４  デコーダ部
１５  映像処理部
１６  表示部
１７  音声処理部
１８  スピーカ
１９  エンコーダ部
２０  通信部
２１  入力部
２２  バス
Ｓ  コンテンツ配信システム
【図１】
2006185171.tif 000003
【図２】
2006185171.tif 000004
【図３】
2006185171.tif 000005
【図４】
2006185171.tif 000006
【図５】
2006185171.tif 000007
【図６】
2006185171.tif 000008
【図７】
2006185171.tif 000009
【図８】
2006185171.tif 000010
【図９】
2006185171.tif 000011
【図１０】
2006185171.tif 000012
【図１１】
2006185171.tif 000013
【図１２】
2006185171.tif 000014
【図１３】
2006185171.tif 000015
【図１４】
2006185171.tif 000016
【図１５】
2006185171.tif 000017
【図１６】
2006185171.tif 000018
【図１７】
2006185171.tif 000019
【図１８】
2006185171.tif 000020
【図１９】
2006185171.tif 000021
【図２０】
2006185171.tif 000022
【図２１】
2006185171.tif 000023