ネットワーク認証・決済システム、ネットワーク装置及びプログラム
【課題】 コンテンツの利用許諾の申込み手続きを簡便に行うようにする。
【解決手段】 コンテンツ配信元であるサーバ装置を含むネットワークと、コンテンツ利用側であるクライアント装置を含むネットワークどうしを通信回線を介して相互接続し、一方のネットワーク上を流れる各種情報を他方のネットワークに中継するネットワーク装置によって、ネットワークを構成している１乃至複数のクライアント装置全てに関するユーザ認証の手続きを一括して処理する。このようにすると、ネットワーク構成されたどのクライアント装置を用いた場合であっても、ネットワーク装置によってネットワーク認証・決済が一括して処理される、つまりネットワーク装置でのみ処理が完結することとなるのでユーザがクライアント装置側で手続きを行わなくてよく、従って従来に比べて通信ネットワークを介してのコンテンツの利用許諾の申込み手続きを簡便に行うことができるようになる。
【解決手段】 コンテンツ配信元であるサーバ装置を含むネットワークと、コンテンツ利用側であるクライアント装置を含むネットワークどうしを通信回線を介して相互接続し、一方のネットワーク上を流れる各種情報を他方のネットワークに中継するネットワーク装置によって、ネットワークを構成している１乃至複数のクライアント装置全てに関するユーザ認証の手続きを一括して処理する。このようにすると、ネットワーク構成されたどのクライアント装置を用いた場合であっても、ネットワーク装置によってネットワーク認証・決済が一括して処理される、つまりネットワーク装置でのみ処理が完結することとなるのでユーザがクライアント装置側で手続きを行わなくてよく、従って従来に比べて通信ネットワークを介してのコンテンツの利用許諾の申込み手続きを簡便に行うことができるようになる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークを利用して配信される各コンテンツの利用をユーザ毎に許諾するネットワーク認証・決済システム、ネットワーク装置及びプログラムに関し、特に各クライアント装置からの通信ネットワークを介した各コンテンツに対する利用許諾の申込み手続きを簡素化する技術に関する。
【背景技術】
【０００２】
最近では、各家庭におけるパーソナルコンピュータの普及、インターネットに代表される有線あるいは無線の通信ネットワークの発達及び通信回線におけるデータ転送速度の高速化、さらには携帯型音楽プレーヤーや携帯型ゲーム機器などの普及に伴い、音楽や映像を中心としたコンテンツのデジタル化・ネットワーク化及びそれに伴う通信ネットワークを利用したデジタルコンテンツの配信サービスが一般化している。通信ネットワークを介してコンテンツ配信サービスからコンテンツ（例えば、楽曲や映像に係る各種デジタル化されたメディアデータ、あるいはソフトウエアプログラムなど）の配信をうける場合、ユーザはコンテンツを利用可能な各端末機器（クライアント装置）からコンテンツ配信元（サーバ装置）に対して、通信ネットワークを介して各コンテンツ毎に利用許諾の申込み手続きをすることが行われている。一方、コンテンツ配信元では利用許諾したユーザに対してのみ当該コンテンツを利用できるように管理することで、コンテンツの健全な流通を確保するようにしている。これに関連するものとして、例えば下記に示す特許文献１又は特許文献２に記載されている発明などがある。
【特許文献１】特開2004-54440号公報
【特許文献２】特開2003-58657号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上述したように、通信ネットワークを介してコンテンツの配信をうける場合、ユーザは各端末機器からコンテンツ配信元に対して通信ネットワークを介してコンテンツの利用許諾の申込み手続きを行うのであるが、従来においては配信をうけたいコンテンツのコンテンツ配信元毎に、また配信をうけるコンテンツ毎に、さらにはコンテンツを利用する各端末機器毎に、ユーザはコンテンツの利用許諾の手続きとして、例えばユーザIDやユーザパスワードの入力などのユーザ認証手続き及びコンテンツ購入に係る決済方法の指定などの決済手続きをいちいち行わなければならなかった。しかし、こうしたコンテンツの利用許諾の申込み手続きをわざわざコンテンツを利用する各端末機器毎にコンテンツ配信の度に行うのは面倒であるし、またこうした手続きには時間がかかり都合が悪い、という問題点があった。
【０００４】
本発明は上述の点に鑑みてなされたもので、従来に比べて各クライアント装置からの通信ネットワークを介してのコンテンツの利用許諾の申込み手続きを簡便に行うことのできる、ネットワーク認証・決済システム、ネットワーク装置及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００５】
本発明の請求項１に係るネットワーク認証・決済システムは、所定の通信回線を介してサーバ装置及びクライアント装置間においてユーザ認証を行うネットワーク認証・決済システムであって、異なるネットワークどうしを通信回線を介して相互接続し、一方のネットワーク上を流れる各種情報を他方のネットワークに中継するネットワーク装置と、個々のクライアント装置からのリクエストに応じて、該リクエストしたクライアント装置を含むネットワークに接続されている前記ネットワーク装置を探索して特定する特定手段と、前記特定したネットワーク装置に対してユーザ固有の固有情報を問合せる固有情報問合せ手段と、前記固有情報の問合せに応じて前記特定したネットワーク装置から返答される固有情報に基づきユーザ認証を行うユーザ認証手段と、前記ユーザ認証によりユーザを認証した場合に所定の証明書情報を発行し、該発行した証明書情報を前記ネットワーク装置に送付する送付手段とを含む、１のネットワークを構成してなるサーバ装置と、前記ネットワーク装置を含むネットワークに接続されてなり、ユーザ操作に応じたリクエストを前記ネットワーク上に送信する送信手段と、前記リクエストに応じて他のネットワークから各種情報を受信する受信手段とを含む、前記サーバ装置とは異なるネットワークを構成する１乃至複数のクライアント装置とを具えてなり、前記ネットワーク装置は、ネットワークを構成している１乃至複数のクライアント装置全てに関するユーザ認証の手続きを一括して処理することを特徴とする。
【０００６】
この発明によると、コンテンツ配信元であるサーバ装置を含むネットワークと、コンテンツ利用側であるクライアント装置を含むネットワークどうしを通信回線を介して相互接続し、一方のネットワーク上を流れる各種情報を他方のネットワークに中継するネットワーク装置によって、クライアント装置側のネットワークを構成している１乃至複数のクライアント装置全てに関するユーザ認証の手続きを一括して処理する。このように、ネットワーク装置に対して、異なるネットワーク間で各種情報を中継する通信経路制御機能だけでなく、コンテンツ配信時におけるネットワーク認証・決済を行うネットワークサービス管理機能を担わせるようにしたことから、ユーザはコンテンツの利用許諾の申込み手続きをわざわざコンテンツを利用する各クライアント装置毎にコンテンツ配信の度に行わなくてもよい。すなわち、ネットワーク構成されたどのクライアント装置を用いた場合であっても、これらのクライアント装置と共にネットワークを構成しているネットワーク装置によってネットワーク認証・決済が一括して処理される、つまりネットワーク装置でのみ処理が完結することとなるのでユーザがクライアント装置側で手続きを行わなくてよく、従って従来に比べて通信ネットワークを介してのコンテンツの利用許諾の申込み手続きを簡便に行うことができるようになる。
【０００７】
本発明の請求項３に係るネットワーク装置は、異なるネットワークどうしを相互接続し、一方のネットワーク上を流れるデータを他方のネットワークに中継するネットワーク装置であって、ユーザ固有の固有情報及び／又は電子マネー情報を読み取るデータ読み取り手段と、他のネットワークを構成するサーバ装置からの前記固有情報の問合せに応じて、前記読み取ったユーザ固有の固有情報を前記サーバ装置に対して送信する固有情報送信手段と、前記サーバ装置からの証明書情報の問合せに応じて、証明書情報を送信する証明書情報送信手段と、前記サーバ装置からの電子決済要求に応じて、前記読み取った電子マネー情報に基づき電子決済を行い、その成否に関する決済情報を前記サーバ装置に対して送信するマネー情報送信手段と、前記サーバ装置から配信されたデータを取得する取得手段とを具えてなり、前記サーバ装置とは異なるネットワークを構成する１乃至複数のクライアント装置全てに関し、ユーザ認証の手続き及び／又はデータ利用許諾にかかる電子決済の手続きを一括処理することを特徴とする。
これによると、ネットワーク装置ではデータ読み取り手段から読み取ったユーザ固有の固有情報及び／又は電子マネー情報に基づき、ユーザ認証の手続き及び／又はデータ利用許諾にかかる電子決済の手続きを一括処理するので、ユーザは従来に比べて通信ネットワークを介してのコンテンツの利用許諾の申込み手続きを簡便に行うことができるようになる。
【０００８】
この発明は装置の発明として構成し実施することができるのみならず、方法の発明として構成し実施することができる。また、本発明はコンピュータまたはＤＳＰ等のプロセッサのプログラムの形態で実施することができるし、そのようなプログラムを記憶した記録媒体の形態で実施することもできる。
【発明の効果】
【０００９】
この発明によれば、クライアント装置と通信ネットワークとの間に介在するネットワーク装置において、通信ネットワークを利用して配信される各コンテンツの利用をユーザ毎に許諾するネットワーク認証・決済を行うようにしたことから、ユーザは各クライアント装置から特に意識することなしに通信ネットワークを介しての各コンテンツの利用許諾の申込み手続きを簡便に行うことができるようになる、という優れた効果が得られる。
【発明を実施するための最良の形態】
【００１０】
以下、添付図面を参照しながらこの発明を詳細に説明する。
【００１１】
図１は、本発明に係るネットワーク認証・決済システムを適用したコンテンツ配信システムの一実施例の全体システム構成を略示するシステムブロック図である。なお、コンテンツ配信システムとしては図１に示す以外のハードウェアを有する場合もあるが、ここでは必要最小限の資源を用いた場合について説明する。
【００１２】
この実施例に示すコンテンツ配信システムは、コンテンツ配信サービスを提供するコンテンツ配信元でありコンテンツを配信する側のサーバシステムＡと、コンテンツ配信サービスの提供を受けるエンドユーザであり配信された所望のコンテンツを利用する側のクライアントシステムＢとが、インターネットＸなどの既存の通信ネットワークを介して双方向通信可能に適宜に接続されるシステムである。これらの両システムを接続する通信ネットワークは有線回線に限られず、携帯電話回線や衛星通信回線等の無線回線を含んでいてよい。また、公衆電話回線網やインターネット等に限らず、LAN（Local Area Network）等を含んでいてもよい。
【００１３】
コンテンツ配信元であるサーバシステムＡは、各コンテンツ毎の利用許諾状況（例えば、データ再生のみの再生権、データ再生に加えてミキシングなどのデータ編集をも含む編集権などの個々の利用形態（権利）毎に付与する許諾・未許諾を表す利用許諾状況）に関する管理情報を蓄積するデータベースである権利管理（DRM(Digital Rights Management)）DB（Ａ１）、コンテンツ配信サービスの提供を受けるべくユーザ登録した個々のユーザの属性（例えば、氏名や電子メールアドレス、ユーザIDなど）等を蓄積するデータベースであるユーザDB（Ａ２）、ユーザに提供する楽曲データや動画データや音声データ、あるいはテキストデータなどのデジタル化された各種コンテンツを多数記憶するコンテンツストレージ（Ａ３）などの記憶装置を含む。さらに、前記ユーザDB（Ａ２）を参照してユーザアカウントの管理・ネットワーク認証等を行うアカウントモジュール（Ａ４）、前記権利管理DB（Ａ１）を参照して利用許諾の申込み手続きがなされたコンテンツの利用許諾・未許諾を行う権利管理モジュール（Ａ５）、コンテンツ購入・利用・閲覧に対する対価の支払にかかるコンテンツ課金及びネットワーク決済等を行う決済モジュール（Ａ６）、当該サーバシステムＡとエンドユーザ側のクライアントシステムＢとの間で双方向通信を行うためのインタフェースとなる配信サーバ（Ａ７）などの各種処理装置（又は各機能を実現するプログラムであってもよい）を含んでいる。
【００１４】
詳しくは図示しないが、上記配信サーバＡ７は、各種情報等をエンドユーザに対して提示するWWW（World Wide Web）サイトの表示（所謂Webページ）に関する例えばHTML（Hyper Text Markup Language）で記述されているページ記述情報などを、エンドユーザからのアクセス要求に応じてエンドユーザに供給する所謂WWWサーバと、コンテンツを実際にコンテンツストレージＡ３内に蓄積し、またコンテンツストレージＡ３から蓄積されているコンテンツを読み出してエンドユーザに供給するコンテンツサーバとを含む。コンテンツサーバは、上記サーバシステムＡ内にコンテンツストレージＡ３とともに配置してもよいし、インターネット等を介した他のシステム側に配置してもよい。インターネット等を介した他のシステム側に配置する場合、コンテンツサーバには個々のユーザが使用するクライアント装置も含まれ得る。こうした場合には、インターネット上に接続されているユーザ個人が保有するパーソナルコンピュータ内に記憶されているコンテンツなどを、他のユーザに対して供給することもできる。
【００１５】
なお、サーバシステムＡの一部を構成する配信サーバＡ７はシステム内に１個に限らず複数個あってよく、各配信サーバＡ７が各々独自に用意したコンテンツを提供し得るようになっていてよい。このように、配信サーバＡ７が複数存在する場合には、コンテンツの所在を管理するインデクスサーバＡ８が配置される。図示のように、配信サーバＡ７が１台のみである場合は、当該配信サーバＡ７がインデクスサーバＡ８を兼ねることから、別にインデクスサーバＡ８を用意する必要はない。
なお、上記したサーバシステムＡを構成する各DB（Ａ１、Ａ２）、コンテンツストレージＡ３、各モジュール（Ａ４〜Ａ６）、配信サーバＡ７は各々が単独の装置として配置されていてもよいし、複数の機能を兼ね備えた１の装置（例えば、権利管理モジュールＡ５を兼ね備えた配信サーバＡ７など）として配置するようにしてあってもよい。
【００１６】
他方、コンテンツ配信サービスの提供を受けるエンドユーザ側であるクライアントシステムＢは、WAN（Wide Area Network）とWAN、LANとLAN、WANとLANなどの異なるネットワークどうしを相互接続する中継機器であるルータＢ１と、配信されたコンテンツを再生・編集するなどのコンテンツ利用・作成が可能な、パーソナルコンピュータＢ２、電子楽器などの電子音楽装置Ｂ３、ミキシング機能を具えたMTR／ミキサＢ４、例えばテレビやビデオやステレオあるいは冷蔵庫等（所謂ネットワーク家電）のその他のコンテンツ利用機器Ｂ５などの、前記ルータＢ１で管理される家庭内LANにネットワーク接続することが可能なクライアント装置を含む。すなわち、前記ルータＢ１はNAT（Network Address Translation）機能やIPマスカレード機能を備え、プロバイダから付与された１つのIPアドレスを複数のクライアント装置で利用できるようにするネットワーク装置である。このルータＢ１を利用することで家庭内LANを容易に構築することができ、また該家庭内LANに接続された複数のクライアント装置までのデータ転送のための経路をルーティング（経路選択）することで、複数のクライアント装置から同時にインターネットへと接続することができるようになる。
【００１７】
図示のように、家庭内LANのルータＢ１には、例えばFeliCa（商標）対応のICカードや携帯電話に搭載されたIC等から当該ICに記憶されている情報を読み取ることのできるカードリーダＣＲが接続されている。該カードリーダＣＲで読み取り可能なICカードや携帯電話等には固有のID番号（後述するようにユーザIDに相当する）と電子マネーデータとが記憶されており、クライアントシステムＢではサーバシステムＡとの間で前記ルータＢ１による暗号化通信を行うことによって、カードリーダＣＲで読み取ったこれらの情報の授受を行うことのできるようにしている。これについての詳細は後述することから、ここでは説明を省略する（後述する図６及び図７参照）。
【００１８】
家庭内LANにネットワーク接続することが可能なクライアント装置（Ｂ２〜Ｂ５）は、所定の文字列情報で構成されるネットワークアドレスであるURL（Uniform Resource Locator）などを指定することによってインターネットＸ上に接続された配信サーバＡ７内にあるWWWサイトのいずれかへアクセスし、該アクセスしたWWWサイトからユーザ所望のコンテンツを単に受信して利用することができるだけでなく、クライアント装置（Ｂ２〜Ｂ５）から配信サーバＡ７に対してクライアント装置側で作成したコンテンツを送信して登録することができる。こうしたクライアント装置（Ｂ２〜Ｂ５）と配信サーバＡ７との間におけるコンテンツを含む各種情報の送受信は、従来知られているようにTCP/IP、FTPやHTTP（HTTPS）などの公知のプロトコル（通信手順又は通信規約などとも呼ぶ）にのっとって、インターネット用ブラウザなどの所定のソフトウエアプログラムを用いて行われるようになっている。
【００１９】
なお、サーバシステムＡにインターネットＸを介して接続可能なクライアント装置として用いられる機器は図１に示したものに限らず、ルータＢ１によりインターネットＸを介して配信サーバＡ７との間で各種情報を送受信して処理できるものであればどのような形態の機器であってもよい。すなわち、カラオケや自動演奏ピアノのような自動演奏装置であってもよいし、ゲーム機器若しくは携帯電話やPDAなどの携帯型端末機器などであってもよい。また、サーバシステムＡに対して、同時に複数のクライアントシステムＢがインターネットＸを介して接続されることは言うまでもない。
なお、クライアントシステムＢとしては、ルータＢ１やクライアント装置に対してさらに別のルータが接続されている階層型のネットワーク構成であってよい。
【００２０】
ここで、図１に示したサーバシステムＡとクライアントシステムＢ間において、公知のプロトコルに従って行われる一連の処理単位である所謂セッションの概要について、場合を分けて説明する。図２は１セッション内に含まれる処理の流れを概念的に示した処理概念図であり、図２（ａ）にユーザ登録時におけるセッション概要を、図２（ｂ）にコンテンツ利用時におけるセッション概要を、図２（ｃ）にコンテンツ登録時におけるセッション概要をそれぞれ示す。なお、説明を理解し易くするために、図中では処理順に番号を付してある。
【００２１】
図２（ａ）を用いてユーザ登録時におけるセッション概要を説明する。まずユーザは、自身の情報（氏名や電子メールアドレス等）とともに「ユーザ登録要求」をサーバシステムＡに送信する（番号１の登録要求）。すると、サーバシステムＡはクライアントシステムＢに含まれるユーザ側LANのルータＢ１と交信して、該ルータＢ１に接続されているカードリーダＣＲに挿入されたICカードから読み取ったユニークなIDを問合せ、該カードIDを受け取る（番号２のID問合せ）。サーバシステムＡでは、正しいカードIDであるか／不正なカードIDであるか、既存のIDと重複するかしないかなどの確認を行い、カードIDの確認ができた時点で上記「ユーザ登録要求」とともに受信したユーザ情報に前記確認したカードIDとを紐付け、これらをユーザDB（Ａ２）に登録する（番号３のユーザ登録）。登録が完了した旨を、Webページでのレスポンスあるいは電子メールなどを用いて、ユーザに通知する（番号４の登録通知）。このようにして、コンテンツ配信サービスを受けたいユーザはユーザ登録を行うことができる。
【００２２】
図２（ｂ）を用いてコンテンツ利用時におけるセッション概要を説明する。ユーザは配信サーバＡ７のWWWサーバを介して利用可能なコンテンツをブラウズし、ユーザ所望のコンテンツの取得をサーバシステムＡに対して要求する（番号１を付したブラウズ及び番号２を付した取得要求）。サーバシステムＡではクライアントシステムＢに含まれるユーザ側LANのルータＢ１と交信し、該ルータＢ１に接続されているカードリーダＣＲに挿入されたICカードから読み取ったカードIDを受け取り、このカードIDに基づいてユーザ認証を行う（番号３を付したID認証）。さらに、ICカードから読み取った電子マネーデータに基づき当該ICカードに蓄えられている電子マネーを原資にして、コンテンツ利用に対する対価の支払にかかる決済が可能かどうかを確認する（番号４を付した決済及び番号５を付したDRM決済）。こうしたコンテンツの利用可能性、決済額については権利管理モジュールＡ５により管理される。コンテンツの利用可能性が確認され、電子マネーによる決済が完了すると、サーバシステムＡからクライアントシステムＢに対してコンテンツが提供される（番号６のコンテンツ提供）。このようにして、ユーザは所望のコンテンツの提供を受けることができる。
【００２３】
図２（ｃ）を用いてコンテンツ登録時におけるセッション概要を説明する。ユーザが「コンテンツの登録要求」をサーバシステムＡに送信すると（番号１を付した登録要求）、上記コンテンツ利用時と同様にしてユーザ認証を行う（番号２を付したID認証：図２（ｂ）では番号３を付したID認証と同）。ユーザ認証が完了すると、ユーザからは登録するコンテンツに関する情報（例えばURL、コンテンツ名等の付加情報）が送信される（番号４を付した情報送信）。登録されるコンテンツの権利情報を権利管理モジュールＡ５にて更新するとともに、該登録されたコンテンツへアクセスするためのインデクス情報を更新する（番号６を付したDRM登録、インデクス）。各種情報の更新が完了したことに応じて、クライアントシステムＢに対して登録完了通知が返される（番号７を付した登録通知）。このようにして、ユーザは自らが作成したコンテンツ（例えば、後述する図４（ａ）に示すようなメディア制御データなど）を配信可能に登録することができる。
なお、上記番号４〜番号７を付した各処理に前後して、図中において番号３を付した登録手数料を課金する決済を行うようにしてもよいし、また図中において番号５を付したコンテンツとしてデータ本体（メディアデータ）をもサーバシステムＡに送信してサーバシステムＡ上にデータを記憶させるようにしてあってもよい。
【００２４】
次に、図１に示したサーバシステムＡ側の各装置（各モジュール（Ａ４〜Ａ６）又は配信サーバＡ７）又はクライアントシステムＢ側の各装置（クライアント装置（Ｂ２〜Ｂ５）又はルータＢ１）いずれかのハード構成の一実施例について、図３を用いて簡単に説明する。図３は、上記各装置いずれか１つの全体構成の一実施例を示すハード構成ブロック図である。ただし、上記各装置は同じようなハード構成を用いるものとして説明することができることから、代表としてクライアント装置（Ｂ２〜Ｂ５）についてのブロック図を１つだけ用いて説明する。
【００２５】
本実施例に示すクライアント装置は、マイクロプロセッサユニット（ＣＰＵ）１、リードオンリメモリ（ＲＯＭ）２、ランダムアクセスメモリ（ＲＡＭ）３からなるマイクロコンピュータによって制御されるようになっている。ＣＰＵ１は、このクライアント装置全体の動作を制御するものである。このＣＰＵ１に対して、データ及びアドレスバス１Ｄを介してＲＯＭ２、ＲＡＭ３、入力デバイス４、出力デバイス５、LAN通信インタフェース６、外部記憶装置７がそれぞれ接続されている。ＲＯＭ２は、ＣＰＵ１により実行される各種プログラムや各種データを格納するものである。ＲＡＭ３は、ＣＰＵ１が所定のプログラムを実行する際に発生する各種データを一時的に記憶するワーキングメモリとして、あるいは現在実行中のプログラムやそれに関連するデータを記憶するメモリ等として使用される。ＲＡＭ３の所定のアドレス領域がそれぞれの機能に割り当てられ、レジスタやフラグ、テーブル、メモリなどとして利用される。
【００２６】
入力デバイス４は、各種のスイッチやボタン、ユーザ自身の情報（氏名や電子メールアドレス等）やURLなどを入力するための文字データ入力用のキーボードや数値データ入力用のテンキー、若しくはディスプレイ上に表示されたWebページからポインタを操作して配信を受けたいコンテンツをクリックするためのマウス、あるいは入力に応じて楽曲データを生成する鍵盤、デジタイザ、マイクロフォンなどの入力機器である。出力デバイス５はWebページ等の各種画面を表示するための例えば液晶表示パネル（ＬＣＤ）やＣＲＴなどのディスプレイ、あるいはサーバＭＳから送信された曲データに基づき楽音を発生する音源（サウンドカード）等である。LAN通信インタフェース６は、家庭内LAN等の通信ネットワークに接続され、該通信ネットワークを介して接続された機器間で各種情報を送受信するための通信インタフェースである。上記LAN通信インタフェース６は、有線のものに限らず無線のものであってもよい。また、双方を具えていてもよい。さらに、図示していないが、外部のMIDI機器等からMIDI規格の楽音情報（つまり、MIDIデータ）を当該クライアント装置へ入力したり、あるいは当該クライアント装置からMIDI規格の楽音情報（MIDIデータ）を外部のMIDI機器等へ出力するためのMIDIインタフェースを具えていてもよい。
【００２７】
外部記憶装置７は、ＣＰＵ１が実行する各種制御プログラム（例えば、周知のネットワーク用ブラウザや各種アプリケーションソフトウエアなど）を記憶する。前記ＲＯＭ２に制御プログラムが記憶されていない場合、この外部記憶装置７（例えばハードディスク）に制御プログラムを記憶させておき、それを前記ＲＡＭ３に読み込むことにより、ＲＯＭ２に制御プログラムを記憶している場合と同様の動作をＣＰＵ１にさせることができる。このようにすると、制御プログラムの追加やバージョンアップ等が容易に行える。なお、外部記憶装置７はハードディスク（HD）に限られず、フロッピィーディスク（FD）、コンパクトディスク（CD）、光磁気ディスク（MO）、DVD（Digital Versatile Diskの略）等の着脱自在な様々な形態の外部記憶媒体を利用する記憶装置であってもよい。若しくは、半導体メモリなどであってもよい。なお、クライアント装置は入力デバイス４や出力デバイス５などを１つの装置本体に内蔵したものに限らず、それぞれが別々に構成され、所定のインタフェースを用いて前記各装置を接続するように構成されたものにも同様に適用できることはいうまでもない。
【００２８】
なお、ルータＢ１もコンピュータ装置の一種であるが、基本的にデータの中継を行うものであることから、ボタンやディスプレイ等の入力デバイス５や出力デバイス６を装備していなくてもよい。ただし、入力デバイスとしてICカードから情報を読み取るカードリーダＣＲを具備する。また、家庭内LANに接続するためのLAN通信インタフェース６に加えて、インターネットに接続するためのWAN通信インタフェース８を具備する。このWAN通信インタフェース８は、プロトコルとしてPPPoE（Point to Point Protocol over Ethernet）等の所謂ブロードバンドなどと呼ばれている高速なデータ転送が可能な通信回線に対応したものが望ましい。
【００２９】
次に、図１に示したサーバシステムＡを構成する配信サーバ（Ａ７）、ユーザDB（Ａ２）、権利管理DB（Ａ１）、さらにはインデクスサーバ（Ａ８）のそれぞれに記憶される各種データ（レコード）について説明する。図４は各種データのデータ構成の一実施例を示す概念図であり、図４（ａ）に配信サーバに記憶されてコンテンツとして配信されるリソースデータ、図４（ｂ）にユーザDBに記憶されるユーザ情報に関するレコードデータ、図４（ｃ）に権利管理DBに記憶される利用許諾状況又は権利情報に関するレコードデータ、図４（ｄ）にインデクスサーバに記憶されるコンテンツの所在を表すデータをそれぞれ示している。
【００３０】
配信サーバＡ７に記憶されコンテンツとして配信対象となるリソースデータとしては、楽曲データや映像データ等（具体的には、MIDIデータ、オーディオデータ、楽譜データ、ビデオデータ、画像データ、テキストデータなど）のデータ本体そのものであり、トラック又はパート単位に構成されているメディアデータと（図示せず）、複数のメディアデータの組み合わせ及びその組み合わせ方を規定することで、例えば１の楽曲を構成する複数の前記メディアデータをパッケージとしてまとめるようにして定義した定義データと、メディアデータの特殊なものとしてのメディア制御データとに大きく分けられる。図４（ａ）上段に示すように、定義データは、メディア制御データのリソースID、パッケージ化する複数のメディアデータそれぞれに対応するリソースID（メディアデータ１のリソースID、・・・、メディアデータｎのリソースID）からなる。これらの定義データ内容はＸＭＬ等の記述言語で記載されており、個々のメディア制御データあるいはメディアデータに予め付されている各リソースIDと共に各リソースへのURLが記述されている。なお、サーバシステムＡにインデクスサーバＡ８を配置しているような場合には、インデクスサーバＡ８には後述のように、配信対象となるリソースを一意に特定するためのリソースIDと当該リソースのネットワーク上における所在を示すURLとが組にして記憶されており、配信サーバＡ７はインデクスサーバＡ８に対してURLを取得したいリソースのリソースIDを通知し、そのレスポンスとして当該リソースIDに対応するリソースへのURLを取得することにより、定義データにおいて各リソースへのURLの記述を省略することができる。
【００３１】
他方、図４（ａ）下段に示すように、メディア制御データは、リソースIDと制御チャンネル（ＣＨ）とのバインド情報、制御コマンド｛Δｔ、チャンネル、制御イベント｝の組などの情報からなる。ヘッダ部分にあるリソースIDと制御チャンネルとのバインド情報は、リソースIDをどの制御チャンネルに割り当てるかを規定する情報である（他にもタイムコードの種別、時間分解能等の情報もある）。各制御コマンドは、コマンド実行タイミングを表す情報と、制御チャンネル情報と、コマンドの内容を示す制御イベント情報とでなる。タイミング情報は再生開始からのデルタタイムで表す方式と、直前のイベントからのデルタタイムで表す方式が考えられる。前者の場合には、１イベントあたりの時間情報量はかさむがタイミング制御のための時間タイマは１つでよい。後者の場合には、１イベントあたりの時間情報量は節約できるが、各制御チャンネル毎にタイミング制御のための時間タイマを設ける必要がある。例えば、メディア制御データのコード体系としてはSMF（Single MIDI Format）を引き継ぎ、イベント情報の解釈を転化する。こうしたメディア制御データの一例としては、制御コマンドとして、各チャンネルにバインドされたリソースの再生開始や各チャンネル間のボリュームバランスあるいはエフェクト効果等を含むミキシング情報データ等がある。クライアントシステムＢでは、定義データにおいて規定されたリソースを適宜サーバシステムＡより取得し、メディア制御データに規定された制御コマンドにより各リソースの再生制御を行う。
【００３２】
図４（ｂ）に示すように、ユーザDB（Ａ２）に記憶されるユーザ情報に関するレコードデータは、カードID、ユーザ個人情報、許諾情報１〜Ｎ、権利情報１〜Ｍとからなる。すなわち、この実施例においてユーザDBは「カードID」をユーザ固有の一義的な識別情報とみなし、このカードIDを主キーとして、ユーザの氏名やメールアドレス等のユーザ個人情報、許諾されているリソースに関する情報（後述する利用許諾状況に関するレコードに含まれる許諾シリアル番号）、権利を持っているリソースに関する情報（後述する権利情報に関するレコードに含まれる権利シリアル番号）を１レコード中に記録する。なお、１ユーザが複数のカードを所有していたり、１つのカードを複数ユーザが共用している場合もあるため、カードIDとは別にユーザIDを定め、各ユーザID毎に上記同様のレコードを保持するようにしてもよい。このような場合には、１ユーザIDと複数のカードIDとを対応付けたテーブルと、１カードIDに複数のユーザIDを対応付けたテーブルとを設けるようにするとよい。
【００３３】
図４（ｃ）に示すように、権利管理DB（Ａ１）に記憶されるデータとしては、利用許諾状況に関するレコードデータと、権利情報に関するレコードデータとがある。図４（ｃ）上段に示すように、利用許諾状況に関するレコードは、許諾シリアル番号、リソースID、許諾先カードID、許諾開始日時、履歴（日時、ルータ・クライアントアドレス）からなる。利用許諾状況に関するレコードは利用許諾する利用形態の１許諾ごとに１レコードが作成され、レコード作成時にユニークなシリアルナンバ（ID）である許諾シリアル番号が付与される。リソースIDは許諾しているリソースのID、許諾先カードIDは許諾した相手のユーザID、許諾開始日時は許諾を開始した日時、履歴は当該リソースの利用履歴（日時とルータのアドレス、クライアントのアドレスが１セットで記録される）である。
【００３４】
図４（ｃ）下段に示すように、権利情報に関するレコードは、権利シリアル番号、リソースID、許諾元カードID、利用条件情報、関連権利情報とからなる。権利情報に関するレコードは１リソース毎に１レコードが作成され、レコード作成時にユニークなシリアルナンバ（ID）である権利シリアル番号が付与される。リソースIDは対応するリソースのID、許諾元カードIDは権利を保有している者のユーザID、利用条件情報は利用条件に関する情報、関連権利情報は権利の親子関係などの権利に関する関連情報である。前記利用条件に関する情報として主なものを示すと、例えば許諾可能な相手のID（あるいはユーザ個人情報から特定される年齢等のユーザ属性）、許諾対価、提供形態（ダウンロードによる利用を許容する／ストリームによる利用を許諾するなど）、単独利用の可否（関連する他のリソースとともに利用する場合にのみ利用を許諾するなど）などが挙げられる。また、前記関連権利情報として主なものを示すと、当該権利のリソースが二次著作物である場合における二次著作物であることを示す属性値＋その原著作物に相当するリソースの権利シリアル番号、当該権利のリソースが他のリソースとの組み合わせによる利用が必須である場合における当該リソースが組み合わせコンテンツの一部であることを示す属性値＋その組み合わせを規程するデータファイルの権利シリアル番号などが挙げられる。
【００３５】
図４（ｄ）に示すように、インデクスサーバ（Ａ８）に記憶されるコンテンツの所在を表すデータは、リソースID、URL、その他の情報（etc）とからなる。すなわち、インデクスサーバは権利管理DBにより管理され、クライアントに配信可能なリソース毎にユニークなシリアル番号（ID）を付与し、各リソースIDに当該リソースへのURLやリソースのデータ種別等を蓄積している。
【００３６】
従来から知られているように、コンテンツ配信システムにおいて、利用制限付きのコンテンツの配信を受けようとする各クライアント装置（Ｂ２〜Ｂ５）は、コンテンツ配信元からユーザ認証と、利用形態に応じた課金に対する電子決済とが正常に完了しない限り、ユーザ所望の利用形態でのコンテンツ配信を受けることができない。図１に示したコンテンツ配信システムにおいても同様である。そこで、図１に示したコンテンツ配信システムを構成するサーバシステムＡとクライアントシステムＢ間におけるユーザアクセス開始からコンテンツ取得までの、コンテンツ利用時におけるセッションとしてTCP/IP、HTTP（HTTPS）等の公知の通信手順に基づく一連の通信手順について、図５〜図７を用いて説明する。以下に示す図５〜図７は、図１に示したコンテンツ配信システムを構成するサーバシステムＡ及びクライアントシステムＢ間における通信手順を示すシーケンス図である。なお、説明の都合上、各通信手順には便宜的に番号を付してある。
【００３７】
まず、利用制限の無いリソースデータ（メディアデータなど）へのアクセス時におけるサーバシステムＡ及びクライアントシステムＢ間の通信手順について、図５を用いて説明する。サーバシステムＡ上の利用制限の無いリソースデータへアクセスする場合には、公知のTCP/IP、HTTP（HTTPS）等に従ったパケット伝送、メッセージ交換が行われる。すなわち、クライアント装置からインターネットゲートウェイたるルータに対して、ルータアドレスを問合せする（番号１）。ルータは、各クライアント装置からの前記問合せに応じてアドレスを返答する（番号２）。これにより、クライアント装置はルータを介してインターネットに接続できるようになる。なお、通常上記番号１及び番号２を付した各処理手順は、クライアント装置が家庭内LANに接続された際に解決されるので、セッション毎に上記問合せを行う必要はない。クライアント装置がインターネットに接続されてアクセスリクエストが行われると、クライアント装置からユーザ所望の利用制限の無いリソースデータを配信する配信サーバに対してHTTPリクエストを送る（番号３）。配信サーバはHTTPリクエストを受信すると、HTTPレスポンスをクライアント装置に対して返信する（番号４）。こうして、クライアント装置はサーバシステムＡ上の利用制限の無いリソースデータについては、特にユーザ認証や決済などを行うことなくアクセスするだけで取得することができるようになっている。
【００３８】
利用制限付きのリソースデータへのアクセス時におけるサーバシステムＡ及びクライアントシステムＢ間の通信手順について、図６及び図７を用いて説明する。図６は、利用制限付きのリソースデータへのアクセス時における処理手順全体の概要を示す。以下では、カードIDの認証証明を受けていない未承認のクライアント装置から利用制限付きのリソースデータ（単にDRMリソースと呼ぶ）へのアクセスリクエストが行われた場合と、カードIDの認証証明を既に受けた同じクライアントから再度DRMリソースへのアクセスリクエストが行われた場合とに、場合を分けて説明する。なお、サーバシステムＡと各クライアント装置（Ｂ２〜Ｂ５）間、サーバシステムＡとルータＢ１間においては、それぞれ個別にSSL（Secure Sockets Layer）等による伝送路の秘匿化が行われることは言うまでもない。
【００３９】
まず、カードIDの認証証明を受けていない未承認のクライアント装置からDRMリソースへのアクセスリクエストが行われた場合について説明する。番号１及び番号２を付した各処理手順については、既に説明済みの図５と同様であることから説明を省略する。クライアント装置がインターネットに接続されてアクセスリクエストが行われると、クライアント装置からユーザ所望のDRMリソースを配信する配信サーバに対してHTTPリクエストを送る（番号３）。配信サーバではDRMリソースへのアクセスリクエストを検出すると、リクエストを発生したクライアント装置までの伝送路を逆に辿り、複数のクライアント装置のルーティング（経路選択）を管理しているルータを探し出す（番号１２）。そして、配信サーバはルータに対して証明書の問合せを行う（番号５）。この際に、クライアント装置までの伝送路を逆に辿り、ネットワーク構成の末端から順に「クライアント対応のICカードを持っているか？」を順次に問合せる。該問合せに応じて、ルータはICカードを持っている（挿入済みである）こと及び「未証明」である旨のレスポンスを返答する（番号６）。なお、通常クライアント装置までの間には複数のルータが介在するので、上記番号１２、番号５、番号６を付した一連の通信手順については複数回繰り返される場合がある。
【００４０】
クライアント対応のICカードを持っているルータが発見されたら、サーバシステムＡのアカウントモジュールはそのルータに対してカードIDの問合せを行うので（番号７）、ルータはカードIDを通知する（番号８）。さらに、アカウントモジュールはルータが返答してきたカードIDで認証を行い、IDの認証が成功した段階でルータに対し証明書の発行を行う（番号９）。この証明書は、ルータにおいて保持されるようになっている。その後、配信サーバは番号５を付した問合せを再度行い、これに対応する番号６を付したルータから「証明有り」のレスポンスを受け取った場合に、ルータに記憶されている該証明書を権利管理モジュールが参照することのできるように証明書を要求し（番号１０）、権利管理モジュールではルータから受け取った証明書を検証する（番号１１）。無効な（有効期限が切れている）証明書であって、証明書の検証に失敗（NG）した場合には、再度番号７を付したID問合せによるID認証から上記処理をやり直す。一方、有効な（有効期限が切れていない）証明書であって、証明書の検証に成功（OK）した場合には、配信サーバはクライアント装置に対してルータを介してDRMリソースを提供する（番号４´）。
【００４１】
一方、カードIDの認証証明を既に受けた同じクライアント装置から再度DRMリソースへのアクセスリクエストが行われた場合には、前回のセッション時にそのクライアント装置に対応するルータが判明済みであるので、前回のセッション時にクライアントアドレスにルータのアドレスを関連付けて記憶させておくことで、図に示すような番号１２、番号５、番号６、番号７、番号８、番号９と続く認証証明にかかる一連の通信手順を行うことなく、ルータに対して直接証明書発行後の証明書の問合せ（番号５）を行うことができるようになる（ただし、上記認証証明にかかる一連の通信手順を再度行うようにしてもよい）。証明書の応答の結果として、有効な証明書（有効期限が切れていない）が返答されたらDRMリソースをルータを介してクライアント装置に対して提供する。なお、サーバシステムＡとルータ間において伝送路が秘匿化されていない場合には、番号１０を付した証明書要求に先立って伝送路の秘匿化を行う。
【００４２】
以上のように、アクセス先がDRMリソースの場合は、図６に示したとおりの通信手順に従ってIDの認証あるいは証明書の検証を行う。これらユーザの認証や証明書の検証は、例えば受信した証明書に関する情報のメッセージダイジェストを生成し、発行時に生成したダイジェストの整合性をチェックする。あるいは、証明書に関する情報の中から証明書の有効期限に関する情報を抽出する。
【００４３】
次に、図６に示した配信サーバからクライアント装置へのDRMリソースを配信する際のHTTPレスポンス時（図６において番号４´を付した処理）における具体的なリソース提供時における通信手順について、図７を用いて説明する。ただし、ここでは場合分けとして、まだ利用許諾されていないコンテンツヘアクセスして決済に成功した場合を図７（ａ）に、過去にアクセス済みであって既に利用許諾済みのコンテンツへ再度アクセスした場合を図７（ｂ）に、まだ利用許諾されていないコンテンツへアクセスしたが決済に失敗した場合を図７（ｃ）に、そもそも利用が許諾されないコンテンツへアクセスした場合を図７（ｄ）に、それぞれ図を分けて説明する。なお、ここでも説明の都合上、各通信手順には便宜的に番号を付してある。
【００４４】
図７（ａ）を用いて、まだ利用許諾されていないコンテンツヘアクセスして決済に成功した場合について説明する。配信サーバはクライアント装置からDRMリソースのリクエストを受けると（番号３）、DRMリソースの提供を開始する前に、権利管理モジュールに対して、カードIDに対応するコンテンツの利用許諾状況を表す権利リポジトリ（あるいはリクエストされたコンテンツのリソースIDに対応する権利リポジトリ）を問合せる（番号１３）。カードIDに対応するコンテンツの利用許諾状況を表す権利リポジトリは、ユーザDBに蓄積されたデータレコード中の一群の許諾情報ないし対応する権利管理DBに蓄積された各利用許諾状況のデータレコードに対応し、コンテンツのリソース中に対応する権利リポジトリは、権利管理DBに蓄積された権利情報レコードに対応する。この例では「カードID（のユーザ）」に対して「リソースID」に対応するDRMリソースの利用が未だ許諾されていないので、権利管理モジュールは権利管理DBを参照した上で「未許諾」である旨を配信サーバに返答する（番号１４）。未許諾の返答を受けた配信サーバは、ルータに対して「カードID」の電子マネーを原資とした電子決済を要求する（番号１５）。ルータは要求された決済額に相当する決済を行い、該決済が完了したことを配信サーバに返答する（番号１６）。配信サーバではこの返答を受けて、権利管理モジュールに対して「カードID」に対応する権利リポジトリに「リソースID」の利用権を追加するよう（あるいは、「リソースID」に対応する許諾先リポジトリに「カードID」を追加するよう）に更新要求する（番号１７）。その結果、権利リポジトリが「未許諾」から「許諾」に更新されると、「カードID（のユーザ）」に対して「リソースID」の利用が許諾された状態になるので、その返答（番号１８）に応じて配信サーバはクライアント装置に対してDRMリソースの提供を開始する（番号４´）。この際に、提供するDRMリソースに対して、（当該リソースを元々提供している）許諾元IDや許諾先ID（例えばカードIDが該当してよい）を明示する情報を付加したり、あるいは、これらのIDをキーとして暗号化（エンコード）を施して配信する。
【００４５】
図７（ｂ）に示すように、過去にアクセス済みであって既に利用許諾済みのコンテンツへ再度アクセスした場合には、「カードID（のユーザ）」に対して「リソースID」の利用は既に許諾されているので、配信サーバとルータ間で電子決済関連の手続き（図７（ａ）の番号１４〜番号１７を付した一連の通信手順）を踏むことなく、DRMリソースの提供が開始される。
【００４６】
図７（ｃ）に示すように、まだ利用許諾されていないコンテンツへアクセスしたが決済に失敗した場合（例えば、ICカードにチャージされている電子マネーが足りないなどによりルータでの電子決済が失敗した場合）、ルータは配信サーバに対してその旨を通知する（番号１６´）。配信サーバでは決済失敗の通知を受けた場合に、DRMリソースに対するアクセスを一切拒否して、クライアント装置に対してエラー通知（決済に失敗したためリソースは提供不能である旨）をレスポンスする（番号４）。
【００４７】
図７（ｄ）に示すように、そもそも利用が許諾されることのないコンテンツへアクセスした場合（リクエストされたリソースが許諾不可のものであった場合）、権利管理モジュールは「許諾不可」である旨を配信サーバに返答し（番号１９）、配信サーバはクライアント装置に対してエラー通知（リソースは許諾不可である旨）をレスポンスする（番号４）。なお、ここで「許諾不可」である場合とは、例えば特定の許諾先ID（例えばカードIDが該当してよい）にのみアクセスを許諾しうるよう、権利者により予め設定されている場合等である。
【００４８】
上述したような通信手順に従い、サーバシステムＡとルータＢ１間で認証・決済の手続きをした上で、サーバシステムＡはクライアント装置（Ｂ２〜Ｂ５）に対してコンテンツを配信する。そこで、上記通信手順にのっとりコンテンツを配信する処理について説明する。ただし、実際にはサーバシステムＡとクライアントシステムＢとの間では、通信手順にのっとり所定の情報を送受信しながら並行して各々の処理を実行するものであることから、ここでは説明を理解しやすくするために、ユーザアクセス開始からコンテンツ取得までの処理を各々のシステムでそれぞれ独立に実行される処理に分けて説明する。すなわち、配信サーバＡ７が主となり実行するサーバシステムＡ側の処理である「コンテンツ配信処理」を図８に、ルータＢ１が実行するクライアントシステムＢ側における認証・決済の手続きを行う「認証・決済処理」を図９に、それぞれ図を分けて説明する。
【００４９】
図８は、サーバシステムＡで実行する「コンテンツ配信処理」の一実施例を示すフローチャートである。当該処理は、サーバシステムＡ中における特にWWWサーバとして機能する配信サーバＡ７が主となり実行する処理である。なお、図５〜図７と当該処理フローとの対応関係を理解し易くするために、図中において各処理内容の前に図５〜図７に示した通信手順の番号に相当する番号を便宜的に付してある。
【００５０】
ステップＳ１は、クライアントシステムＢからコンテンツ配信要求などの各種リクエスト（HTTPリクエスト）を受け付ける。ステップＳ２は、コンテンツ配信要求であってアクセス対象として指定されているコンテンツが利用制限付きのリソースデータ（DRMリソース）であるか否かを判定する。この判定に応じて、HTTPリクエストを受け付けると、利用制限のない一般のリソース（non DRMリソース）を配信する一般リソース配信用の配信処理と、利用制限のあるDRMリソースを配信するDRMリソース配信用の配信処理とを切り替える。すなわち、コンテンツ配信要求以外のリクエスト、あるいはコンテンツ配信要求であるがアクセス対象として指定されているコンテンツがDRMリソース以外のリソースである場合には（ステップＳ２の他）、一般リソース配信用の配信処理としてクライアントシステムＢに対して通常のレスポンスを行って当該処理を終了する（ステップＳ３）。他方、アクセス対象がDRMリソースである場合には（ステップＳ２のDRMリソース）、DRMリソース配信用の配信処理としてステップＳ４以降の処理を実行する。まず、コンテンツ配信を要求してきたクライアントシステムＢのルータの特定を行う（ステップＳ４）。ルータが未特定である場合には（ステップＳ４の未特定）、ルータを特定するあるいはルータ特定に失敗するまでルータ探索を行う（ステップＳ６）。ルータの特定に失敗した場合には（ステップＳ４の特定失敗）、クライアントシステムＢに対してエラーレスポンス（HTTPレスポンス）を行って当該処理を終了する（ステップＳ５）。
【００５１】
一方、ルータの特定に成功した場合には（ステップＳ４の特定）、特定したルータに対して「証明書問合せ」を送信する（ステップＳ７）。ステップＳ８は、前記「証明書問合せ」を送信したルータからの返答が「証明あり」か「証明なし」であるかを判定する。この際に、特定したルータ以外からの返答であった場合には（ステップＳ８の非該当ルータ）、ステップＳ４に戻ってルータの特定をやり直す。ステップＳ８において特定ルータからの返答が「証明なし」である場合には（ステップＳ８の証明なし）、ルータに対してカードIDを問合せ（ステップＳ１９）、該問合せたカードIDに基づきID認証を行い（ステップＳ２０）、さらに前記ID認証に成功したか失敗したかを判定する（ステップＳ２１）。ID認証に失敗した場合には（ステップＳ２１の失敗）、クライアントシステムＢに対してエラーレスポンスを行い当該処理を終了する（ステップＳ２３）。ID認証に成功した場合には（ステップＳ２１の成功）、ルータに対して発行した証明書を送信する（ステップＳ２２）。
【００５２】
上記ステップＳ８において、特定したルータからの返答が「証明あり」である場合には（ステップＳ８の証明あり）、特定したルータに対して記憶されている「証明書」を送付するよう要求する（ステップＳ９）。そして、該要求に基づきルータから送信された「証明書」が有効であるか無効であるかの検証を行い（ステップＳ１０）、「証明書」の検証に成功したか否かを判定する（ステップＳ１１）。「証明書」の検証に失敗した場合、つまり送付された証明書が有効期限の切れている無効な証明書である場合には（ステップＳ１１の失敗）、上述したステップＳ１９〜ステップＳ２３の処理を実行して処理を終了する。「証明書」の検証に成功した場合、つまり送付された証明書が有効期限の切れていない有効な証明書である場合には（ステップＳ１１の成功）、権利管理DBを参照して権利リポジトリを確認し（ステップＳ１２）、利用許諾状況を判定する（ステップＳ１３）。利用許諾状況が許諾不可である場合には（ステップＳ１３の許諾不可）、クライアントシステムＢに対してエラーレスポンスを送信してコンテンツ配信を行うことなく当該処理を終了する（ステップＳ１８）。利用許諾状況が許諾である場合には（ステップＳ１３の許諾）、クライアントシステムＢに対してDRMリソースの配信を開始する（ステップＳ１７）。利用許諾状況が未許諾である場合には（ステップＳ１３の未許諾）、決済要求を行って（ステップＳ１４）、該要求に基づく決済が完了したか否かを判定する（ステップＳ１５）。そして、決済が完了した場合には（ステップＳ１５の完了）権利リポジトリを更新し（ステップＳ１６）、コンテンツ配信を開始する（ステップＳ１７）。決済が失敗した場合には（ステップＳ１５の失敗）、ステップＳ１８の処理へジャンプしてコンテンツ配信を行うことなく当該処理を終了する。
【００５３】
なお、上記したステップＳ１２〜ステップＳ１６までの処理は権利管理モジュールＡ５により、また上記したステップＳ１９〜ステップＳ２２の処理はアカウントモジュールＡ４により各々実行される処理であり、これらの処理は配信サーバＡ８から各モジュールＡ５又はＡ４に対して各処理を行うよう制御されることにより実行されるようになっている。
【００５４】
図９は、ルータ側で実行される「認証・決済処理」の一実施例を示すフローチャートである。該処理は上記したサーバシステムＡ側で実行される「コンテンツ配信処理」にあわせてクライアントシステムＢ側のルータＢ１で並列的に動作される処理フローであって、配信サーバＭＳからの要求に基づきクライアントシステムＢを構成する全てのクライアント装置（Ｂ２〜Ｂ５）に関する認証・決済を一括して行う処理である。ルータＢ１はその名のとおりパケットデータのルーティング（経路選択）を行うが、本発明にかかる処理を実現するために（機能的には全機能を実装していないにしろ）HTTPサーバプロセスを立ち上げている。少なくとも、HTTPサーバプロセスはSSL等による秘匿通信はサポートしている。HTTPサーバプロセスは特定のポートを各種情報リクエスト受付用に開いておき、ここにリクエストが入った場合に当該処理を実行する。なお、フローの前提としてSSL等による秘匿通信の確立処理があり、またルータ本来のルーティング機能（経路選択機能）に関する処理もあるが、それらの処理についてはここでは図示及び説明を省略する。
【００５５】
ステップＳ３１は、サーバシステムＡからの各種リクエスト（HTTPリクエスト）を受け付ける。ステップＳ３２は、該ルータに接続済みのカードリーダにICカードが挿入済みであり、また該挿入されたICカードが正規のカードであって読み取ることができるか否かを判定する。カードリーダにICカードが挿入されていない、あるいは正規のカードでないためにカードIDなどの情報が読み取れないなどの場合には（ステップＳ３２のなし）、カードエラーであることをサーバシステムＡに対して返答する（ステップＳ３３）。カードリーダにICカードが挿入されており、該ICカードが正規のカードであってカードIDなどの情報が読み取れる場合には（ステップＳ３２のあり）、サーバシステムからのリクエスト内容を判定し（ステップＳ３４）、該リクエスト内容に従う処理を各々実行する。リクエスト内容が「証明書関連」であって「証明要求」である場合には（ステップＳ３４の証明書関連かつステップＳ３５のＹＥＳ）、証明書を送信する（ステップＳ３６）。「証明書問合せ」である場合には（ステップＳ３４の証明書関連かつステップＳ３５のＮＯ：証明問合）、証明有無（証明あり又は証明なし）をサーバシステムＡに対して返答する（ステップＳ３７）。証明書を受信した場合には（ステップＳ３４の証明書関連かつステップＳ３５のＮＯ：証明書受信）、サーバより受信した証明書をカードIDに対応付けて保持する（ステップＳ３８）。リクエスト内容が「ID要求」である場合には（ステップＳ３４のID要求）、挿入済みのカードからカードIDを読み取ってサーバシステムＡに対して送信する（ステップＳ３９及びステップＳ４０）。リクエスト内容が「決済要求」である場合には（ステップＳ３４の決済要求）、挿入済みのカードから電子マネーデータを読み取り残高を確認する（ステップＳ４１及びステップＳ４２）。該読み取った電子マネー残高がコンテンツ利用・購入にかかる対価である所定の金額以上である場合には（ステップＳ４２のＯＫ）、電子マネーデータの更新を行うと共に、決済が完了したことを返答する（ステップＳ４３及びステップＳ４４）。電子マネー残高がコンテンツ利用・購入にかかる対価である金額に満たない場合には（ステップＳ４２のＮＧ）、決済に失敗したことをサーバシステムＡに対して返答する（ステップＳ４５）。
【００５６】
以上のようにして、この発明に係るネットワーク認証・決済システムを適用したコンテンツ配信システムにおいては、利用制限付きのリソースデータ（DRMリソース）へのアクセス時に、クライアントシステムＢを構成する各々のクライアント装置（Ｂ２〜Ｂ５）を認証証明に関与させることなく、従来において個々のクライアント装置（Ｂ２〜Ｂ５）毎に行われていた認証証明に関する処理手順についてのすべてを、当該クライアントシステムＢを構成するネットワーク内のルータＢ１に一括して任せるようにしている。上述したように、ルータＢ１に接続されているカードリーダに挿入されたICカードの情報がキーとなり認証を行うので、一度購入したコンテンツを他の利用態様の際に再度購入するといった、ユーザにとってはわずらわしい手間が省ける。例えば、ユーザがCDで楽曲を購入した場合などに、従来ではCDに収録された曲をカラオケで利用したり携帯電話の着信音に利用しようとする場合には再度使用料を支払わなければならなかったが、ネットワーク装置に予め登録済みのICカードを挿入するあるいは携帯電話をかざすだけで既に購入済であることの確認ができるようになるので、そうしたことをなくすことができる。さらに、登録済みであって十分に電子マネーがチャージしてあるICカードをルータＢ１にさしておくだけで自動的に認証乃至決済が行われるので、ユーザはコンテンツの利用権の許諾を受けるための手続きを、特段に意識することなく簡便に行うことができるようになる。このように、本発明によると、クライアント装置に接続されネットワークを構成するルータは従来知られた「通信経路の制御機能」だけでなく、「ネットワークサービス管理機能」を担う従来にないネットワーク装置となる。
なお、以上において、ICカード自体に電子マネーが保持されているものを前提として説明を行ったが、ICカードによってはカードIDを保持するものの、電子マネーを保持・管理する能力を持たない場合もありえる。こういった場合は、ルータＢ１において番号８を付したID返答に際して（図６参照）、当該カードIDを保持しているICカードは決済機能を備えていない旨の情報を添付してサーバシステムＡに通知し、前述のサーバシステムＡに配置された決済モジュールＡ６がクライアントシステムＢに配置されているルータＢ１（ネットワーク装置）に成り代わり、所定の決済手法（例えばクレジット決済等）により決済を行う。決済モジュールＡ６への決済要求は、ルータＢ１から行ってもよいし、サーバシステムＡ内で行ってもよい。
【００５７】
ここで、サーバシステムＡによるDRMリソースの配信からクライアントシステムＢによるDRMリソースの利用までのデータ処理態様について、図１０を用いて簡単に説明する。図１０は、サーバシステムＡ及びクライアントシステムＢで行われるデータ処理態様について示す機能ブロック図である。ただし、この実施例では、DRMリソースを所定のブロック（フレーム）単位で逐次送信し、受信側では受け取ったブロック単位のデータを逐次デコードして再生するストリーミング配信型を例にする。
【００５８】
サーバシステムＡではコンテンツ配信対象とされたDRMリソースをコンテンツストレージＡ３からブロック（フレーム）単位に読み出して、該読み出されたブロック（フレーム）単位のDRMリソースに対して、許諾元ID、許諾先ID、リソースIDなどの情報を所謂電子透かしとして埋め込みする（Ｄ１）。そして、許諾先ID、リソースID、クライアントアドレスあるいは配信要求時刻等（あるいは、これらの情報を元にMD5等の一方向性関数により取得される情報）から暗号化キーを作成し（Ｄ２）、該作成された暗号化キーとパケット送信毎にパケットをカウントするパケットカウンタ（Ｄ５）からのパケット番号とに基づいて暗号化（スクランブル）及びパケット化を行う（Ｄ３及びＤ４）。具体的には、例えば作成された暗号化キーとパケット番号とを乱数種として乱数列を生成し、１ブロック内に含まれるデータを所定バイトづつ取り込み、順次取得する乱数値に応じてサイクリックにシフトする（スクランブルをかける）。このようにしてパケット毎に暗号化されたDRMリソースを、クライアントシステムＢ（エンドユーザ）に対して送信する。
【００５９】
他方、受信側でありエンドユーザであるクライアントシステムＢ側では、上記した手順と逆の手順を踏む。すなわち、サーバシステムＡからパケット毎に暗号化されたDRMリソースを受信すると、まずアンパケットによりデータを復元する（Ｅ１）。そして、カードID（許諾先IDに相当する）、リソースID、クライアントアドレスあるいは配信要求時刻等から復号化キーを作成し（Ｅ３）、該作成された複合化キーとパケット送信毎にパケットをカウントするパケットカウンタ（Ｅ２）からのパケット番号とに基づいて復号化を行う（Ｅ４）。この際に、サーバシステムＡ側での暗号化キーとクライアントシステムＢ側で生成した復号化キーとが一致していなければ、正しく復号化することができない。そこで、図１０の場合には、暗号化キー生成ブロック（Ｄ２）と復号化キー生成ブロック（Ｅ３）とは処理的には同じ処理を行うものであり、暗号化（又は復号化）する際のデータの処理手順がそれぞれ逆となるだけである。こうして復号化されたDRMリソースに基づいて、DRMリソース再生などのコンテンツ利用がなされる。
【００６０】
上記のようにして、サーバクライアントＡからDRMリソースの配信をうけた各クライアント装置（Ｂ２〜Ｂ５）では、権利付与されている制限範囲内（購入したコンテンツの利用許諾状況による）で、該配信されたDRMリソースを利用することができる。例えば、ユーザがクライアント装置（Ｂ２〜Ｂ５）のいずれかを用いて、ユーザ所望のある楽曲（定義データにより規定される、ひとまとまりのパッケージとして定義された１乃至複数のリソースで構成されたもの）の利用権を購入する。すると、権利管理 DBにユーザが所持しているICカードの固有情報に紐付けされて、購入した楽曲（コンテンツ）を構成する各要素コンテンツの利用が可能となる。要素コンテンツとは、ギタートラックやボーカルトラックなどの楽曲を構成する各トラック（又はパート）単位のコンテンツのことであり、前記配信される楽曲（１のコンテンツ）と区別するために便宜的に用いる。つまり、１のコンテンツは１乃至複数の要素コンテンツを含む。このような１乃至複数の要素コンテンツからなる１のコンテンツを配信する際には、各要素コンテンツ毎にユーザ認証・決済が行われて、利用許諾されている要素コンテンツのみが配信される。そこで、ユーザは購入した楽曲を構成する１乃至複数の要素コンテンツのうち、決済しないなどにより一部の要素コンテンツを除いた状態でコンテンツ再生することができる。例えば、ギターパートとボーカルパートに関しては決済を行わずに、これらを除いた他のパートについてはサーバシステムＡからストリーミング配信により取得することにより、ユーザ自身の演奏によるギター演奏や歌唱を前記ストリーミング再生される本来のバック演奏に併せて行うことができる。
【００６１】
上記したように、図１に示すコンテンツ配信システムでは、MP3等の音楽ファイルや映像データなどのコンテンツを、トラック（パート）単位で配信・購入するのに最適である。また、上述した図１０に示すようにして配信されるコンテンツ、及び／又はクライアント装置（コンテンツ利用・作成装置）を用いたユーザ自身の制作（演奏）によるコンテンツを適宜に組み合わせて、各ユーザは自身が操作できるクライアント装置上において新たにオリジナルなコンテンツを作成することができる。また、各ユーザがクライアント装置で作成したオリジナルなコンテンツを適宜に利用許諾を設定し、サーバシステムＡにコンテンツ登録することで、Web上で広く他のユーザに対して公開することが可能となる。そこで、１曲を構成するトラックあるいはパートといった単位で利用が認められたコンテンツの配信を受け、これを利用してユーザオリジナルなコンテンツを作成することのできるクライアント装置の機能について図１１を用いて、ユーザ個々のクライアント装置で作成したコンテンツをサーバシステム側に登録する際の通信手順について図１２を用いてそれぞれ説明する。
【００６２】
図１１は、クライアント装置が具えるコンテンツ利用・作成にかかる各種機能を示す機能ブロック図である。これらの各機能全体の動作は、図示しない制御部により統制制御される。通信インタフェース６を介してルータＢ１からDRMリソースが供給されると、スイッチＦ２は、該受信したデータをキャッシュＦ４（例えばハードディスクを含む、任意に再読出しが可能なキャッシュ）又はDRMデコーダ（図１０参照）の何れに供給するかを制御する。具体的には、通常の受信データであればキャッシュＦ４に格納し、DRMリソースのストリームデータであればDRMデコーダＦ３に供給する。バッファＦ５は、DRMリソースの再生同期化を行うためのものであり、DRMリソースの時間管理情報（タイムスタンプやデルタタイム等）に基づいた再生読出し制御を行う（なお、DRMリソースが複数あればこれらが相互に同期するよう調整する）。ミキサ部Ｆ７は、各リソースあるいはマイクなどの外部入力装置８から入力したデータを、メディア制御データあるいはマウスやボリューム等の入力デバイス４からの操作子信号に応じて適宜にミックスダウンして出力デバイス５（ディスプレイ・スピーカ等）に出力する。出力制御部Ｆ６は、受信したデータの出力状態（例えば、ディスプレイ上に表示する際の表示配置位置など）を制御して、描画情報や音声データなどを出力デバイス５に対して出力する。操作解釈部Ｆ８はマウスやボリューム等の操作信号を受付け（操作イベントを受け付け）、どういった操作が行われたかを解釈する。例えば、URLの入力がキーボードによりなされた場合には、そのURLのリクエストを送信するよう制御し、ボリューム等が操作された場合はミキサ部Ｆ７に対して相当の制御信号（ミキシング制御データ）を送る。操作解釈部Ｆ８は、上述のとおり、サーバシステムＡより提供されるメディア制御データと同等のミキシング制御データを出力するが、このミキシング制御データまたは、出力制御部Ｆ６あるいはミキサ部Ｆ７に入力されるメディア制御データとミキシング制御データとを結合したものを別途記憶しておくように構成してもよい。操作解釈部Ｆ８は、この記録されたデータを新規な要素コンテンツ（メディア制御データ）としてサーバシステムＡに登録するために、通信インタフェース６を介して送信するように制御する。
また、上述のように、１つのコンテンツを構成する１乃至複数のコンテンツのうち、一部のコンテンツを除いた状態でコンテンツを再生するとともに、クライアントシステムＢで入力あるいは再生される他の要素コンテンツと組み合わせて、ユーザオリジナルなコンテンツを作成する場合には、メディア制御データをそのまま利用し、対応するリソースを取得しない（空いた）チャンネルに、クライアントシステムＢで入力あるいは再生される他の要素コンテンツを割り当てるようにしてもよいし、クライアントシステムＢにて新規にメディア制御データを作成するようにしてもよい。あるいは、定義データあるいはメディア制御データにおいて、あらかじめクライアントシステムＢ内の外部入力装置８に対応するリソース（当該リソースは権利管理DBでは管理されない）およびチャンネルを利用可能に定義しておき、これを適用するようにしてもよい。
【００６３】
図１２は、コンテンツ登録時におけるシステム間の通信手順を示すシーケンス図である。ただし、ここでは上記図６に示した認証証明に関する手順から後の手順について説明する。図１２に示すように、コンテンツ登録時における通信手順としては、まずクライアント装置からは登録したいコンテンツ（クライアントシステムＢで入力・記録乃至保持されている音声データや映像データ等の各種コンテンツあるいは上記ミキシング制御データ）の情報とともに、ユーザが任意に決定した利用条件や関連権利の情報がHTTPリクエストにより送付される（番号３）。サーバシステムでは送付された情報に基づき、コンテンツにユニークなリソースIDを発行し、その他の情報（カードIDや権利条件等）とともに権利管理DBに新規登録、あるいはユーザDBのレコードを更新する。コンテンツ登録の際において、実体データを単一のサーバシステムに伝送する必要は無く、ユーザは任意のサーバシステム（なお、クライアントシステム自体がサーバ機能を有する場合を含む）に実体データを配置するようにしてよい。ただし、このように構成する場合は、登録情報と実体データとの整合性を確認するために、権利管理 DB（Ａ１）あるいはインデクスサーバ（Ａ８）に登録するコンテンツの情報として、チェックサムなど権利管理DB（Ａ１）に登録した情報と実体データとの整合性を検証するための情報を併せて登録することが必要となる。また、コンテンツ登録の際に、実体データを単一のサーバシステムＡに伝送しない場合には、権利管理 DB（Ａ１）、ユーザDB（Ａ２）、インデクスサーバ（Ａ８）に対して、登録したコンテンツ（を参照するためのリソースIDやURL等）の情報が登録されるのみである。なお、実体データをも伝送したような場合には、さらにサーバシステムＡのコンテンツストレージ（Ａ３）に実体データが保存される。
【００６４】
上述したように、ユーザはある楽曲の利用権を購入すると、ユーザは購入した楽曲を構成する要素コンテンツのうち、一部の要素コンテンツを除いてコンテンツ再生することができる。そこで、ユーザは例えばギターパートを除いたコンテンツを再生し、本来のバック演奏に併せてユーザ自身の演奏によるギター演奏をオリジナルなコンテンツとして作成することができる。また、複数の購入した楽曲を構成するそれぞれの要素コンテンツあるいは自身が演奏したギター演奏などを任意に組み合わせたオリジナルなコンテンツを、権利者の承諾の元に新たに作成することができる。こうすると、例えば楽曲のリミックスやヒップホップのようなサンプリングを行う楽曲の製作や、映像コンテンツの一部の映像トラックの一部を他の映像データに差し替えたパロディ版の製作などを行うことができるようになる。また、こうして作成したオリジナルなコンテンツを、権利範囲を設けてサーバシステムに登録することで広くそのコンテンツを他のユーザに対しても公開することができるようになる。また、こうしたコンテンツ公開にかかるユーザ認証・決済処理を簡易に行うこともできるようになる。
【図面の簡単な説明】
【００６５】
【図１】本発明に係るネットワーク認証・決済システムを適用したコンテンツ配信システムの一実施例の全体システム構成を略示するシステムブロック図である。
【図２】１セッション内に含まれる処理の流れを概念的に示した処理概念図であり、図２（ａ）はユーザ登録時、図２（ｂ）はコンテンツ利用時、図２（ｃ）はコンテンツ登録時におけるセッション概要を示す。
【図３】図１に示したサーバシステム又はクライアントシステムの各装置いずれか１つの全体構成の一実施例を示すハード構成ブロック図である。
【図４】データ構成の一実施例を示す概念図であり、図４（ａ）はリソースデータ、図４（ｂ）はユーザ情報に関するレコードデータ、図４（ｃ）は利用許諾状況又は権利情報に関するレコードデータ、図４（ｄ）はコンテンツの所在を表すデータである。
【図５】利用制限の無いリソースデータへのアクセス時におけるシステム間の通信手順を示すシーケンス図である。
【図６】利用制限付きのリソースデータへのアクセス時におけるシステム間の通信手順を示すシーケンス図である。
【図７】図６に示したDRMリソースを配信する際のHTTPレスポンス時における具体的なリソース提供時における通信手順を示すシーケンス図であり、図７（ａ）はまだ利用許諾されていないコンテンツヘアクセスして決済に成功した場合、図７（ｂ）は過去にアクセス済みであって既に利用許諾済みのコンテンツへ再度アクセスした場合、図７（ｃ）はまだ利用許諾されていないコンテンツへアクセスしたが決済に失敗した場合、図７（ｄ）はそもそも利用が許諾されないコンテンツへアクセスした場合である。
【図８】コンテンツ配信処理の一実施例を示すフローチャートである。
【図９】認証・決済処理の一実施例を示すフローチャートである。
【図１０】サーバシステム及びクライアントシステムで行われるデータ処理態様について示す機能ブロック図である。
【図１１】クライアント装置が具えるコンテンツ利用・作成にかかる各種機能を示す機能ブロック図である。
【図１２】コンテンツ登録時におけるシステム間の通信手順を示すシーケンス図である。
【符号の説明】
【００６６】
Ａ…サーバシステム、Ａ１…権利管理（DRM）DB、Ａ２…ユーザDB、Ａ３…コンテンツストレージ、Ａ４…アカウントモジュール、Ａ５…権利管理モジュール、Ａ６…決済モジュール、Ａ７…配信サーバ、Ａ８…インデクスサーバ、Ｂ…クライアントシステム、Ｂ１…ルータ、Ｂ２…パーソナルコンピュータ、Ｂ３…電子音楽装置、Ｂ４…MTR/ミキサ、Ｂ５…その他のコンテンツ利用機器、１…ＣＰＵ、２…ＲＯＭ、３…ＲＡＭ、４…入力デバイス、５…LAN通信インタフェース、６…WAN通信インタフェース、７…出力デバイス、ＣＲ…カードリーダ、Ｃ…ICカード、１Ｄ…通信バス（データ及びアドレスバス）、Ｘ…インターネット
【技術分野】
【０００１】
本発明は、通信ネットワークを利用して配信される各コンテンツの利用をユーザ毎に許諾するネットワーク認証・決済システム、ネットワーク装置及びプログラムに関し、特に各クライアント装置からの通信ネットワークを介した各コンテンツに対する利用許諾の申込み手続きを簡素化する技術に関する。
【背景技術】
【０００２】
最近では、各家庭におけるパーソナルコンピュータの普及、インターネットに代表される有線あるいは無線の通信ネットワークの発達及び通信回線におけるデータ転送速度の高速化、さらには携帯型音楽プレーヤーや携帯型ゲーム機器などの普及に伴い、音楽や映像を中心としたコンテンツのデジタル化・ネットワーク化及びそれに伴う通信ネットワークを利用したデジタルコンテンツの配信サービスが一般化している。通信ネットワークを介してコンテンツ配信サービスからコンテンツ（例えば、楽曲や映像に係る各種デジタル化されたメディアデータ、あるいはソフトウエアプログラムなど）の配信をうける場合、ユーザはコンテンツを利用可能な各端末機器（クライアント装置）からコンテンツ配信元（サーバ装置）に対して、通信ネットワークを介して各コンテンツ毎に利用許諾の申込み手続きをすることが行われている。一方、コンテンツ配信元では利用許諾したユーザに対してのみ当該コンテンツを利用できるように管理することで、コンテンツの健全な流通を確保するようにしている。これに関連するものとして、例えば下記に示す特許文献１又は特許文献２に記載されている発明などがある。
【特許文献１】特開2004-54440号公報
【特許文献２】特開2003-58657号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上述したように、通信ネットワークを介してコンテンツの配信をうける場合、ユーザは各端末機器からコンテンツ配信元に対して通信ネットワークを介してコンテンツの利用許諾の申込み手続きを行うのであるが、従来においては配信をうけたいコンテンツのコンテンツ配信元毎に、また配信をうけるコンテンツ毎に、さらにはコンテンツを利用する各端末機器毎に、ユーザはコンテンツの利用許諾の手続きとして、例えばユーザIDやユーザパスワードの入力などのユーザ認証手続き及びコンテンツ購入に係る決済方法の指定などの決済手続きをいちいち行わなければならなかった。しかし、こうしたコンテンツの利用許諾の申込み手続きをわざわざコンテンツを利用する各端末機器毎にコンテンツ配信の度に行うのは面倒であるし、またこうした手続きには時間がかかり都合が悪い、という問題点があった。
【０００４】
本発明は上述の点に鑑みてなされたもので、従来に比べて各クライアント装置からの通信ネットワークを介してのコンテンツの利用許諾の申込み手続きを簡便に行うことのできる、ネットワーク認証・決済システム、ネットワーク装置及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００５】
本発明の請求項１に係るネットワーク認証・決済システムは、所定の通信回線を介してサーバ装置及びクライアント装置間においてユーザ認証を行うネットワーク認証・決済システムであって、異なるネットワークどうしを通信回線を介して相互接続し、一方のネットワーク上を流れる各種情報を他方のネットワークに中継するネットワーク装置と、個々のクライアント装置からのリクエストに応じて、該リクエストしたクライアント装置を含むネットワークに接続されている前記ネットワーク装置を探索して特定する特定手段と、前記特定したネットワーク装置に対してユーザ固有の固有情報を問合せる固有情報問合せ手段と、前記固有情報の問合せに応じて前記特定したネットワーク装置から返答される固有情報に基づきユーザ認証を行うユーザ認証手段と、前記ユーザ認証によりユーザを認証した場合に所定の証明書情報を発行し、該発行した証明書情報を前記ネットワーク装置に送付する送付手段とを含む、１のネットワークを構成してなるサーバ装置と、前記ネットワーク装置を含むネットワークに接続されてなり、ユーザ操作に応じたリクエストを前記ネットワーク上に送信する送信手段と、前記リクエストに応じて他のネットワークから各種情報を受信する受信手段とを含む、前記サーバ装置とは異なるネットワークを構成する１乃至複数のクライアント装置とを具えてなり、前記ネットワーク装置は、ネットワークを構成している１乃至複数のクライアント装置全てに関するユーザ認証の手続きを一括して処理することを特徴とする。
【０００６】
この発明によると、コンテンツ配信元であるサーバ装置を含むネットワークと、コンテンツ利用側であるクライアント装置を含むネットワークどうしを通信回線を介して相互接続し、一方のネットワーク上を流れる各種情報を他方のネットワークに中継するネットワーク装置によって、クライアント装置側のネットワークを構成している１乃至複数のクライアント装置全てに関するユーザ認証の手続きを一括して処理する。このように、ネットワーク装置に対して、異なるネットワーク間で各種情報を中継する通信経路制御機能だけでなく、コンテンツ配信時におけるネットワーク認証・決済を行うネットワークサービス管理機能を担わせるようにしたことから、ユーザはコンテンツの利用許諾の申込み手続きをわざわざコンテンツを利用する各クライアント装置毎にコンテンツ配信の度に行わなくてもよい。すなわち、ネットワーク構成されたどのクライアント装置を用いた場合であっても、これらのクライアント装置と共にネットワークを構成しているネットワーク装置によってネットワーク認証・決済が一括して処理される、つまりネットワーク装置でのみ処理が完結することとなるのでユーザがクライアント装置側で手続きを行わなくてよく、従って従来に比べて通信ネットワークを介してのコンテンツの利用許諾の申込み手続きを簡便に行うことができるようになる。
【０００７】
本発明の請求項３に係るネットワーク装置は、異なるネットワークどうしを相互接続し、一方のネットワーク上を流れるデータを他方のネットワークに中継するネットワーク装置であって、ユーザ固有の固有情報及び／又は電子マネー情報を読み取るデータ読み取り手段と、他のネットワークを構成するサーバ装置からの前記固有情報の問合せに応じて、前記読み取ったユーザ固有の固有情報を前記サーバ装置に対して送信する固有情報送信手段と、前記サーバ装置からの証明書情報の問合せに応じて、証明書情報を送信する証明書情報送信手段と、前記サーバ装置からの電子決済要求に応じて、前記読み取った電子マネー情報に基づき電子決済を行い、その成否に関する決済情報を前記サーバ装置に対して送信するマネー情報送信手段と、前記サーバ装置から配信されたデータを取得する取得手段とを具えてなり、前記サーバ装置とは異なるネットワークを構成する１乃至複数のクライアント装置全てに関し、ユーザ認証の手続き及び／又はデータ利用許諾にかかる電子決済の手続きを一括処理することを特徴とする。
これによると、ネットワーク装置ではデータ読み取り手段から読み取ったユーザ固有の固有情報及び／又は電子マネー情報に基づき、ユーザ認証の手続き及び／又はデータ利用許諾にかかる電子決済の手続きを一括処理するので、ユーザは従来に比べて通信ネットワークを介してのコンテンツの利用許諾の申込み手続きを簡便に行うことができるようになる。
【０００８】
この発明は装置の発明として構成し実施することができるのみならず、方法の発明として構成し実施することができる。また、本発明はコンピュータまたはＤＳＰ等のプロセッサのプログラムの形態で実施することができるし、そのようなプログラムを記憶した記録媒体の形態で実施することもできる。
【発明の効果】
【０００９】
この発明によれば、クライアント装置と通信ネットワークとの間に介在するネットワーク装置において、通信ネットワークを利用して配信される各コンテンツの利用をユーザ毎に許諾するネットワーク認証・決済を行うようにしたことから、ユーザは各クライアント装置から特に意識することなしに通信ネットワークを介しての各コンテンツの利用許諾の申込み手続きを簡便に行うことができるようになる、という優れた効果が得られる。
【発明を実施するための最良の形態】
【００１０】
以下、添付図面を参照しながらこの発明を詳細に説明する。
【００１１】
図１は、本発明に係るネットワーク認証・決済システムを適用したコンテンツ配信システムの一実施例の全体システム構成を略示するシステムブロック図である。なお、コンテンツ配信システムとしては図１に示す以外のハードウェアを有する場合もあるが、ここでは必要最小限の資源を用いた場合について説明する。
【００１２】
この実施例に示すコンテンツ配信システムは、コンテンツ配信サービスを提供するコンテンツ配信元でありコンテンツを配信する側のサーバシステムＡと、コンテンツ配信サービスの提供を受けるエンドユーザであり配信された所望のコンテンツを利用する側のクライアントシステムＢとが、インターネットＸなどの既存の通信ネットワークを介して双方向通信可能に適宜に接続されるシステムである。これらの両システムを接続する通信ネットワークは有線回線に限られず、携帯電話回線や衛星通信回線等の無線回線を含んでいてよい。また、公衆電話回線網やインターネット等に限らず、LAN（Local Area Network）等を含んでいてもよい。
【００１３】
コンテンツ配信元であるサーバシステムＡは、各コンテンツ毎の利用許諾状況（例えば、データ再生のみの再生権、データ再生に加えてミキシングなどのデータ編集をも含む編集権などの個々の利用形態（権利）毎に付与する許諾・未許諾を表す利用許諾状況）に関する管理情報を蓄積するデータベースである権利管理（DRM(Digital Rights Management)）DB（Ａ１）、コンテンツ配信サービスの提供を受けるべくユーザ登録した個々のユーザの属性（例えば、氏名や電子メールアドレス、ユーザIDなど）等を蓄積するデータベースであるユーザDB（Ａ２）、ユーザに提供する楽曲データや動画データや音声データ、あるいはテキストデータなどのデジタル化された各種コンテンツを多数記憶するコンテンツストレージ（Ａ３）などの記憶装置を含む。さらに、前記ユーザDB（Ａ２）を参照してユーザアカウントの管理・ネットワーク認証等を行うアカウントモジュール（Ａ４）、前記権利管理DB（Ａ１）を参照して利用許諾の申込み手続きがなされたコンテンツの利用許諾・未許諾を行う権利管理モジュール（Ａ５）、コンテンツ購入・利用・閲覧に対する対価の支払にかかるコンテンツ課金及びネットワーク決済等を行う決済モジュール（Ａ６）、当該サーバシステムＡとエンドユーザ側のクライアントシステムＢとの間で双方向通信を行うためのインタフェースとなる配信サーバ（Ａ７）などの各種処理装置（又は各機能を実現するプログラムであってもよい）を含んでいる。
【００１４】
詳しくは図示しないが、上記配信サーバＡ７は、各種情報等をエンドユーザに対して提示するWWW（World Wide Web）サイトの表示（所謂Webページ）に関する例えばHTML（Hyper Text Markup Language）で記述されているページ記述情報などを、エンドユーザからのアクセス要求に応じてエンドユーザに供給する所謂WWWサーバと、コンテンツを実際にコンテンツストレージＡ３内に蓄積し、またコンテンツストレージＡ３から蓄積されているコンテンツを読み出してエンドユーザに供給するコンテンツサーバとを含む。コンテンツサーバは、上記サーバシステムＡ内にコンテンツストレージＡ３とともに配置してもよいし、インターネット等を介した他のシステム側に配置してもよい。インターネット等を介した他のシステム側に配置する場合、コンテンツサーバには個々のユーザが使用するクライアント装置も含まれ得る。こうした場合には、インターネット上に接続されているユーザ個人が保有するパーソナルコンピュータ内に記憶されているコンテンツなどを、他のユーザに対して供給することもできる。
【００１５】
なお、サーバシステムＡの一部を構成する配信サーバＡ７はシステム内に１個に限らず複数個あってよく、各配信サーバＡ７が各々独自に用意したコンテンツを提供し得るようになっていてよい。このように、配信サーバＡ７が複数存在する場合には、コンテンツの所在を管理するインデクスサーバＡ８が配置される。図示のように、配信サーバＡ７が１台のみである場合は、当該配信サーバＡ７がインデクスサーバＡ８を兼ねることから、別にインデクスサーバＡ８を用意する必要はない。
なお、上記したサーバシステムＡを構成する各DB（Ａ１、Ａ２）、コンテンツストレージＡ３、各モジュール（Ａ４〜Ａ６）、配信サーバＡ７は各々が単独の装置として配置されていてもよいし、複数の機能を兼ね備えた１の装置（例えば、権利管理モジュールＡ５を兼ね備えた配信サーバＡ７など）として配置するようにしてあってもよい。
【００１６】
他方、コンテンツ配信サービスの提供を受けるエンドユーザ側であるクライアントシステムＢは、WAN（Wide Area Network）とWAN、LANとLAN、WANとLANなどの異なるネットワークどうしを相互接続する中継機器であるルータＢ１と、配信されたコンテンツを再生・編集するなどのコンテンツ利用・作成が可能な、パーソナルコンピュータＢ２、電子楽器などの電子音楽装置Ｂ３、ミキシング機能を具えたMTR／ミキサＢ４、例えばテレビやビデオやステレオあるいは冷蔵庫等（所謂ネットワーク家電）のその他のコンテンツ利用機器Ｂ５などの、前記ルータＢ１で管理される家庭内LANにネットワーク接続することが可能なクライアント装置を含む。すなわち、前記ルータＢ１はNAT（Network Address Translation）機能やIPマスカレード機能を備え、プロバイダから付与された１つのIPアドレスを複数のクライアント装置で利用できるようにするネットワーク装置である。このルータＢ１を利用することで家庭内LANを容易に構築することができ、また該家庭内LANに接続された複数のクライアント装置までのデータ転送のための経路をルーティング（経路選択）することで、複数のクライアント装置から同時にインターネットへと接続することができるようになる。
【００１７】
図示のように、家庭内LANのルータＢ１には、例えばFeliCa（商標）対応のICカードや携帯電話に搭載されたIC等から当該ICに記憶されている情報を読み取ることのできるカードリーダＣＲが接続されている。該カードリーダＣＲで読み取り可能なICカードや携帯電話等には固有のID番号（後述するようにユーザIDに相当する）と電子マネーデータとが記憶されており、クライアントシステムＢではサーバシステムＡとの間で前記ルータＢ１による暗号化通信を行うことによって、カードリーダＣＲで読み取ったこれらの情報の授受を行うことのできるようにしている。これについての詳細は後述することから、ここでは説明を省略する（後述する図６及び図７参照）。
【００１８】
家庭内LANにネットワーク接続することが可能なクライアント装置（Ｂ２〜Ｂ５）は、所定の文字列情報で構成されるネットワークアドレスであるURL（Uniform Resource Locator）などを指定することによってインターネットＸ上に接続された配信サーバＡ７内にあるWWWサイトのいずれかへアクセスし、該アクセスしたWWWサイトからユーザ所望のコンテンツを単に受信して利用することができるだけでなく、クライアント装置（Ｂ２〜Ｂ５）から配信サーバＡ７に対してクライアント装置側で作成したコンテンツを送信して登録することができる。こうしたクライアント装置（Ｂ２〜Ｂ５）と配信サーバＡ７との間におけるコンテンツを含む各種情報の送受信は、従来知られているようにTCP/IP、FTPやHTTP（HTTPS）などの公知のプロトコル（通信手順又は通信規約などとも呼ぶ）にのっとって、インターネット用ブラウザなどの所定のソフトウエアプログラムを用いて行われるようになっている。
【００１９】
なお、サーバシステムＡにインターネットＸを介して接続可能なクライアント装置として用いられる機器は図１に示したものに限らず、ルータＢ１によりインターネットＸを介して配信サーバＡ７との間で各種情報を送受信して処理できるものであればどのような形態の機器であってもよい。すなわち、カラオケや自動演奏ピアノのような自動演奏装置であってもよいし、ゲーム機器若しくは携帯電話やPDAなどの携帯型端末機器などであってもよい。また、サーバシステムＡに対して、同時に複数のクライアントシステムＢがインターネットＸを介して接続されることは言うまでもない。
なお、クライアントシステムＢとしては、ルータＢ１やクライアント装置に対してさらに別のルータが接続されている階層型のネットワーク構成であってよい。
【００２０】
ここで、図１に示したサーバシステムＡとクライアントシステムＢ間において、公知のプロトコルに従って行われる一連の処理単位である所謂セッションの概要について、場合を分けて説明する。図２は１セッション内に含まれる処理の流れを概念的に示した処理概念図であり、図２（ａ）にユーザ登録時におけるセッション概要を、図２（ｂ）にコンテンツ利用時におけるセッション概要を、図２（ｃ）にコンテンツ登録時におけるセッション概要をそれぞれ示す。なお、説明を理解し易くするために、図中では処理順に番号を付してある。
【００２１】
図２（ａ）を用いてユーザ登録時におけるセッション概要を説明する。まずユーザは、自身の情報（氏名や電子メールアドレス等）とともに「ユーザ登録要求」をサーバシステムＡに送信する（番号１の登録要求）。すると、サーバシステムＡはクライアントシステムＢに含まれるユーザ側LANのルータＢ１と交信して、該ルータＢ１に接続されているカードリーダＣＲに挿入されたICカードから読み取ったユニークなIDを問合せ、該カードIDを受け取る（番号２のID問合せ）。サーバシステムＡでは、正しいカードIDであるか／不正なカードIDであるか、既存のIDと重複するかしないかなどの確認を行い、カードIDの確認ができた時点で上記「ユーザ登録要求」とともに受信したユーザ情報に前記確認したカードIDとを紐付け、これらをユーザDB（Ａ２）に登録する（番号３のユーザ登録）。登録が完了した旨を、Webページでのレスポンスあるいは電子メールなどを用いて、ユーザに通知する（番号４の登録通知）。このようにして、コンテンツ配信サービスを受けたいユーザはユーザ登録を行うことができる。
【００２２】
図２（ｂ）を用いてコンテンツ利用時におけるセッション概要を説明する。ユーザは配信サーバＡ７のWWWサーバを介して利用可能なコンテンツをブラウズし、ユーザ所望のコンテンツの取得をサーバシステムＡに対して要求する（番号１を付したブラウズ及び番号２を付した取得要求）。サーバシステムＡではクライアントシステムＢに含まれるユーザ側LANのルータＢ１と交信し、該ルータＢ１に接続されているカードリーダＣＲに挿入されたICカードから読み取ったカードIDを受け取り、このカードIDに基づいてユーザ認証を行う（番号３を付したID認証）。さらに、ICカードから読み取った電子マネーデータに基づき当該ICカードに蓄えられている電子マネーを原資にして、コンテンツ利用に対する対価の支払にかかる決済が可能かどうかを確認する（番号４を付した決済及び番号５を付したDRM決済）。こうしたコンテンツの利用可能性、決済額については権利管理モジュールＡ５により管理される。コンテンツの利用可能性が確認され、電子マネーによる決済が完了すると、サーバシステムＡからクライアントシステムＢに対してコンテンツが提供される（番号６のコンテンツ提供）。このようにして、ユーザは所望のコンテンツの提供を受けることができる。
【００２３】
図２（ｃ）を用いてコンテンツ登録時におけるセッション概要を説明する。ユーザが「コンテンツの登録要求」をサーバシステムＡに送信すると（番号１を付した登録要求）、上記コンテンツ利用時と同様にしてユーザ認証を行う（番号２を付したID認証：図２（ｂ）では番号３を付したID認証と同）。ユーザ認証が完了すると、ユーザからは登録するコンテンツに関する情報（例えばURL、コンテンツ名等の付加情報）が送信される（番号４を付した情報送信）。登録されるコンテンツの権利情報を権利管理モジュールＡ５にて更新するとともに、該登録されたコンテンツへアクセスするためのインデクス情報を更新する（番号６を付したDRM登録、インデクス）。各種情報の更新が完了したことに応じて、クライアントシステムＢに対して登録完了通知が返される（番号７を付した登録通知）。このようにして、ユーザは自らが作成したコンテンツ（例えば、後述する図４（ａ）に示すようなメディア制御データなど）を配信可能に登録することができる。
なお、上記番号４〜番号７を付した各処理に前後して、図中において番号３を付した登録手数料を課金する決済を行うようにしてもよいし、また図中において番号５を付したコンテンツとしてデータ本体（メディアデータ）をもサーバシステムＡに送信してサーバシステムＡ上にデータを記憶させるようにしてあってもよい。
【００２４】
次に、図１に示したサーバシステムＡ側の各装置（各モジュール（Ａ４〜Ａ６）又は配信サーバＡ７）又はクライアントシステムＢ側の各装置（クライアント装置（Ｂ２〜Ｂ５）又はルータＢ１）いずれかのハード構成の一実施例について、図３を用いて簡単に説明する。図３は、上記各装置いずれか１つの全体構成の一実施例を示すハード構成ブロック図である。ただし、上記各装置は同じようなハード構成を用いるものとして説明することができることから、代表としてクライアント装置（Ｂ２〜Ｂ５）についてのブロック図を１つだけ用いて説明する。
【００２５】
本実施例に示すクライアント装置は、マイクロプロセッサユニット（ＣＰＵ）１、リードオンリメモリ（ＲＯＭ）２、ランダムアクセスメモリ（ＲＡＭ）３からなるマイクロコンピュータによって制御されるようになっている。ＣＰＵ１は、このクライアント装置全体の動作を制御するものである。このＣＰＵ１に対して、データ及びアドレスバス１Ｄを介してＲＯＭ２、ＲＡＭ３、入力デバイス４、出力デバイス５、LAN通信インタフェース６、外部記憶装置７がそれぞれ接続されている。ＲＯＭ２は、ＣＰＵ１により実行される各種プログラムや各種データを格納するものである。ＲＡＭ３は、ＣＰＵ１が所定のプログラムを実行する際に発生する各種データを一時的に記憶するワーキングメモリとして、あるいは現在実行中のプログラムやそれに関連するデータを記憶するメモリ等として使用される。ＲＡＭ３の所定のアドレス領域がそれぞれの機能に割り当てられ、レジスタやフラグ、テーブル、メモリなどとして利用される。
【００２６】
入力デバイス４は、各種のスイッチやボタン、ユーザ自身の情報（氏名や電子メールアドレス等）やURLなどを入力するための文字データ入力用のキーボードや数値データ入力用のテンキー、若しくはディスプレイ上に表示されたWebページからポインタを操作して配信を受けたいコンテンツをクリックするためのマウス、あるいは入力に応じて楽曲データを生成する鍵盤、デジタイザ、マイクロフォンなどの入力機器である。出力デバイス５はWebページ等の各種画面を表示するための例えば液晶表示パネル（ＬＣＤ）やＣＲＴなどのディスプレイ、あるいはサーバＭＳから送信された曲データに基づき楽音を発生する音源（サウンドカード）等である。LAN通信インタフェース６は、家庭内LAN等の通信ネットワークに接続され、該通信ネットワークを介して接続された機器間で各種情報を送受信するための通信インタフェースである。上記LAN通信インタフェース６は、有線のものに限らず無線のものであってもよい。また、双方を具えていてもよい。さらに、図示していないが、外部のMIDI機器等からMIDI規格の楽音情報（つまり、MIDIデータ）を当該クライアント装置へ入力したり、あるいは当該クライアント装置からMIDI規格の楽音情報（MIDIデータ）を外部のMIDI機器等へ出力するためのMIDIインタフェースを具えていてもよい。
【００２７】
外部記憶装置７は、ＣＰＵ１が実行する各種制御プログラム（例えば、周知のネットワーク用ブラウザや各種アプリケーションソフトウエアなど）を記憶する。前記ＲＯＭ２に制御プログラムが記憶されていない場合、この外部記憶装置７（例えばハードディスク）に制御プログラムを記憶させておき、それを前記ＲＡＭ３に読み込むことにより、ＲＯＭ２に制御プログラムを記憶している場合と同様の動作をＣＰＵ１にさせることができる。このようにすると、制御プログラムの追加やバージョンアップ等が容易に行える。なお、外部記憶装置７はハードディスク（HD）に限られず、フロッピィーディスク（FD）、コンパクトディスク（CD）、光磁気ディスク（MO）、DVD（Digital Versatile Diskの略）等の着脱自在な様々な形態の外部記憶媒体を利用する記憶装置であってもよい。若しくは、半導体メモリなどであってもよい。なお、クライアント装置は入力デバイス４や出力デバイス５などを１つの装置本体に内蔵したものに限らず、それぞれが別々に構成され、所定のインタフェースを用いて前記各装置を接続するように構成されたものにも同様に適用できることはいうまでもない。
【００２８】
なお、ルータＢ１もコンピュータ装置の一種であるが、基本的にデータの中継を行うものであることから、ボタンやディスプレイ等の入力デバイス５や出力デバイス６を装備していなくてもよい。ただし、入力デバイスとしてICカードから情報を読み取るカードリーダＣＲを具備する。また、家庭内LANに接続するためのLAN通信インタフェース６に加えて、インターネットに接続するためのWAN通信インタフェース８を具備する。このWAN通信インタフェース８は、プロトコルとしてPPPoE（Point to Point Protocol over Ethernet）等の所謂ブロードバンドなどと呼ばれている高速なデータ転送が可能な通信回線に対応したものが望ましい。
【００２９】
次に、図１に示したサーバシステムＡを構成する配信サーバ（Ａ７）、ユーザDB（Ａ２）、権利管理DB（Ａ１）、さらにはインデクスサーバ（Ａ８）のそれぞれに記憶される各種データ（レコード）について説明する。図４は各種データのデータ構成の一実施例を示す概念図であり、図４（ａ）に配信サーバに記憶されてコンテンツとして配信されるリソースデータ、図４（ｂ）にユーザDBに記憶されるユーザ情報に関するレコードデータ、図４（ｃ）に権利管理DBに記憶される利用許諾状況又は権利情報に関するレコードデータ、図４（ｄ）にインデクスサーバに記憶されるコンテンツの所在を表すデータをそれぞれ示している。
【００３０】
配信サーバＡ７に記憶されコンテンツとして配信対象となるリソースデータとしては、楽曲データや映像データ等（具体的には、MIDIデータ、オーディオデータ、楽譜データ、ビデオデータ、画像データ、テキストデータなど）のデータ本体そのものであり、トラック又はパート単位に構成されているメディアデータと（図示せず）、複数のメディアデータの組み合わせ及びその組み合わせ方を規定することで、例えば１の楽曲を構成する複数の前記メディアデータをパッケージとしてまとめるようにして定義した定義データと、メディアデータの特殊なものとしてのメディア制御データとに大きく分けられる。図４（ａ）上段に示すように、定義データは、メディア制御データのリソースID、パッケージ化する複数のメディアデータそれぞれに対応するリソースID（メディアデータ１のリソースID、・・・、メディアデータｎのリソースID）からなる。これらの定義データ内容はＸＭＬ等の記述言語で記載されており、個々のメディア制御データあるいはメディアデータに予め付されている各リソースIDと共に各リソースへのURLが記述されている。なお、サーバシステムＡにインデクスサーバＡ８を配置しているような場合には、インデクスサーバＡ８には後述のように、配信対象となるリソースを一意に特定するためのリソースIDと当該リソースのネットワーク上における所在を示すURLとが組にして記憶されており、配信サーバＡ７はインデクスサーバＡ８に対してURLを取得したいリソースのリソースIDを通知し、そのレスポンスとして当該リソースIDに対応するリソースへのURLを取得することにより、定義データにおいて各リソースへのURLの記述を省略することができる。
【００３１】
他方、図４（ａ）下段に示すように、メディア制御データは、リソースIDと制御チャンネル（ＣＨ）とのバインド情報、制御コマンド｛Δｔ、チャンネル、制御イベント｝の組などの情報からなる。ヘッダ部分にあるリソースIDと制御チャンネルとのバインド情報は、リソースIDをどの制御チャンネルに割り当てるかを規定する情報である（他にもタイムコードの種別、時間分解能等の情報もある）。各制御コマンドは、コマンド実行タイミングを表す情報と、制御チャンネル情報と、コマンドの内容を示す制御イベント情報とでなる。タイミング情報は再生開始からのデルタタイムで表す方式と、直前のイベントからのデルタタイムで表す方式が考えられる。前者の場合には、１イベントあたりの時間情報量はかさむがタイミング制御のための時間タイマは１つでよい。後者の場合には、１イベントあたりの時間情報量は節約できるが、各制御チャンネル毎にタイミング制御のための時間タイマを設ける必要がある。例えば、メディア制御データのコード体系としてはSMF（Single MIDI Format）を引き継ぎ、イベント情報の解釈を転化する。こうしたメディア制御データの一例としては、制御コマンドとして、各チャンネルにバインドされたリソースの再生開始や各チャンネル間のボリュームバランスあるいはエフェクト効果等を含むミキシング情報データ等がある。クライアントシステムＢでは、定義データにおいて規定されたリソースを適宜サーバシステムＡより取得し、メディア制御データに規定された制御コマンドにより各リソースの再生制御を行う。
【００３２】
図４（ｂ）に示すように、ユーザDB（Ａ２）に記憶されるユーザ情報に関するレコードデータは、カードID、ユーザ個人情報、許諾情報１〜Ｎ、権利情報１〜Ｍとからなる。すなわち、この実施例においてユーザDBは「カードID」をユーザ固有の一義的な識別情報とみなし、このカードIDを主キーとして、ユーザの氏名やメールアドレス等のユーザ個人情報、許諾されているリソースに関する情報（後述する利用許諾状況に関するレコードに含まれる許諾シリアル番号）、権利を持っているリソースに関する情報（後述する権利情報に関するレコードに含まれる権利シリアル番号）を１レコード中に記録する。なお、１ユーザが複数のカードを所有していたり、１つのカードを複数ユーザが共用している場合もあるため、カードIDとは別にユーザIDを定め、各ユーザID毎に上記同様のレコードを保持するようにしてもよい。このような場合には、１ユーザIDと複数のカードIDとを対応付けたテーブルと、１カードIDに複数のユーザIDを対応付けたテーブルとを設けるようにするとよい。
【００３３】
図４（ｃ）に示すように、権利管理DB（Ａ１）に記憶されるデータとしては、利用許諾状況に関するレコードデータと、権利情報に関するレコードデータとがある。図４（ｃ）上段に示すように、利用許諾状況に関するレコードは、許諾シリアル番号、リソースID、許諾先カードID、許諾開始日時、履歴（日時、ルータ・クライアントアドレス）からなる。利用許諾状況に関するレコードは利用許諾する利用形態の１許諾ごとに１レコードが作成され、レコード作成時にユニークなシリアルナンバ（ID）である許諾シリアル番号が付与される。リソースIDは許諾しているリソースのID、許諾先カードIDは許諾した相手のユーザID、許諾開始日時は許諾を開始した日時、履歴は当該リソースの利用履歴（日時とルータのアドレス、クライアントのアドレスが１セットで記録される）である。
【００３４】
図４（ｃ）下段に示すように、権利情報に関するレコードは、権利シリアル番号、リソースID、許諾元カードID、利用条件情報、関連権利情報とからなる。権利情報に関するレコードは１リソース毎に１レコードが作成され、レコード作成時にユニークなシリアルナンバ（ID）である権利シリアル番号が付与される。リソースIDは対応するリソースのID、許諾元カードIDは権利を保有している者のユーザID、利用条件情報は利用条件に関する情報、関連権利情報は権利の親子関係などの権利に関する関連情報である。前記利用条件に関する情報として主なものを示すと、例えば許諾可能な相手のID（あるいはユーザ個人情報から特定される年齢等のユーザ属性）、許諾対価、提供形態（ダウンロードによる利用を許容する／ストリームによる利用を許諾するなど）、単独利用の可否（関連する他のリソースとともに利用する場合にのみ利用を許諾するなど）などが挙げられる。また、前記関連権利情報として主なものを示すと、当該権利のリソースが二次著作物である場合における二次著作物であることを示す属性値＋その原著作物に相当するリソースの権利シリアル番号、当該権利のリソースが他のリソースとの組み合わせによる利用が必須である場合における当該リソースが組み合わせコンテンツの一部であることを示す属性値＋その組み合わせを規程するデータファイルの権利シリアル番号などが挙げられる。
【００３５】
図４（ｄ）に示すように、インデクスサーバ（Ａ８）に記憶されるコンテンツの所在を表すデータは、リソースID、URL、その他の情報（etc）とからなる。すなわち、インデクスサーバは権利管理DBにより管理され、クライアントに配信可能なリソース毎にユニークなシリアル番号（ID）を付与し、各リソースIDに当該リソースへのURLやリソースのデータ種別等を蓄積している。
【００３６】
従来から知られているように、コンテンツ配信システムにおいて、利用制限付きのコンテンツの配信を受けようとする各クライアント装置（Ｂ２〜Ｂ５）は、コンテンツ配信元からユーザ認証と、利用形態に応じた課金に対する電子決済とが正常に完了しない限り、ユーザ所望の利用形態でのコンテンツ配信を受けることができない。図１に示したコンテンツ配信システムにおいても同様である。そこで、図１に示したコンテンツ配信システムを構成するサーバシステムＡとクライアントシステムＢ間におけるユーザアクセス開始からコンテンツ取得までの、コンテンツ利用時におけるセッションとしてTCP/IP、HTTP（HTTPS）等の公知の通信手順に基づく一連の通信手順について、図５〜図７を用いて説明する。以下に示す図５〜図７は、図１に示したコンテンツ配信システムを構成するサーバシステムＡ及びクライアントシステムＢ間における通信手順を示すシーケンス図である。なお、説明の都合上、各通信手順には便宜的に番号を付してある。
【００３７】
まず、利用制限の無いリソースデータ（メディアデータなど）へのアクセス時におけるサーバシステムＡ及びクライアントシステムＢ間の通信手順について、図５を用いて説明する。サーバシステムＡ上の利用制限の無いリソースデータへアクセスする場合には、公知のTCP/IP、HTTP（HTTPS）等に従ったパケット伝送、メッセージ交換が行われる。すなわち、クライアント装置からインターネットゲートウェイたるルータに対して、ルータアドレスを問合せする（番号１）。ルータは、各クライアント装置からの前記問合せに応じてアドレスを返答する（番号２）。これにより、クライアント装置はルータを介してインターネットに接続できるようになる。なお、通常上記番号１及び番号２を付した各処理手順は、クライアント装置が家庭内LANに接続された際に解決されるので、セッション毎に上記問合せを行う必要はない。クライアント装置がインターネットに接続されてアクセスリクエストが行われると、クライアント装置からユーザ所望の利用制限の無いリソースデータを配信する配信サーバに対してHTTPリクエストを送る（番号３）。配信サーバはHTTPリクエストを受信すると、HTTPレスポンスをクライアント装置に対して返信する（番号４）。こうして、クライアント装置はサーバシステムＡ上の利用制限の無いリソースデータについては、特にユーザ認証や決済などを行うことなくアクセスするだけで取得することができるようになっている。
【００３８】
利用制限付きのリソースデータへのアクセス時におけるサーバシステムＡ及びクライアントシステムＢ間の通信手順について、図６及び図７を用いて説明する。図６は、利用制限付きのリソースデータへのアクセス時における処理手順全体の概要を示す。以下では、カードIDの認証証明を受けていない未承認のクライアント装置から利用制限付きのリソースデータ（単にDRMリソースと呼ぶ）へのアクセスリクエストが行われた場合と、カードIDの認証証明を既に受けた同じクライアントから再度DRMリソースへのアクセスリクエストが行われた場合とに、場合を分けて説明する。なお、サーバシステムＡと各クライアント装置（Ｂ２〜Ｂ５）間、サーバシステムＡとルータＢ１間においては、それぞれ個別にSSL（Secure Sockets Layer）等による伝送路の秘匿化が行われることは言うまでもない。
【００３９】
まず、カードIDの認証証明を受けていない未承認のクライアント装置からDRMリソースへのアクセスリクエストが行われた場合について説明する。番号１及び番号２を付した各処理手順については、既に説明済みの図５と同様であることから説明を省略する。クライアント装置がインターネットに接続されてアクセスリクエストが行われると、クライアント装置からユーザ所望のDRMリソースを配信する配信サーバに対してHTTPリクエストを送る（番号３）。配信サーバではDRMリソースへのアクセスリクエストを検出すると、リクエストを発生したクライアント装置までの伝送路を逆に辿り、複数のクライアント装置のルーティング（経路選択）を管理しているルータを探し出す（番号１２）。そして、配信サーバはルータに対して証明書の問合せを行う（番号５）。この際に、クライアント装置までの伝送路を逆に辿り、ネットワーク構成の末端から順に「クライアント対応のICカードを持っているか？」を順次に問合せる。該問合せに応じて、ルータはICカードを持っている（挿入済みである）こと及び「未証明」である旨のレスポンスを返答する（番号６）。なお、通常クライアント装置までの間には複数のルータが介在するので、上記番号１２、番号５、番号６を付した一連の通信手順については複数回繰り返される場合がある。
【００４０】
クライアント対応のICカードを持っているルータが発見されたら、サーバシステムＡのアカウントモジュールはそのルータに対してカードIDの問合せを行うので（番号７）、ルータはカードIDを通知する（番号８）。さらに、アカウントモジュールはルータが返答してきたカードIDで認証を行い、IDの認証が成功した段階でルータに対し証明書の発行を行う（番号９）。この証明書は、ルータにおいて保持されるようになっている。その後、配信サーバは番号５を付した問合せを再度行い、これに対応する番号６を付したルータから「証明有り」のレスポンスを受け取った場合に、ルータに記憶されている該証明書を権利管理モジュールが参照することのできるように証明書を要求し（番号１０）、権利管理モジュールではルータから受け取った証明書を検証する（番号１１）。無効な（有効期限が切れている）証明書であって、証明書の検証に失敗（NG）した場合には、再度番号７を付したID問合せによるID認証から上記処理をやり直す。一方、有効な（有効期限が切れていない）証明書であって、証明書の検証に成功（OK）した場合には、配信サーバはクライアント装置に対してルータを介してDRMリソースを提供する（番号４´）。
【００４１】
一方、カードIDの認証証明を既に受けた同じクライアント装置から再度DRMリソースへのアクセスリクエストが行われた場合には、前回のセッション時にそのクライアント装置に対応するルータが判明済みであるので、前回のセッション時にクライアントアドレスにルータのアドレスを関連付けて記憶させておくことで、図に示すような番号１２、番号５、番号６、番号７、番号８、番号９と続く認証証明にかかる一連の通信手順を行うことなく、ルータに対して直接証明書発行後の証明書の問合せ（番号５）を行うことができるようになる（ただし、上記認証証明にかかる一連の通信手順を再度行うようにしてもよい）。証明書の応答の結果として、有効な証明書（有効期限が切れていない）が返答されたらDRMリソースをルータを介してクライアント装置に対して提供する。なお、サーバシステムＡとルータ間において伝送路が秘匿化されていない場合には、番号１０を付した証明書要求に先立って伝送路の秘匿化を行う。
【００４２】
以上のように、アクセス先がDRMリソースの場合は、図６に示したとおりの通信手順に従ってIDの認証あるいは証明書の検証を行う。これらユーザの認証や証明書の検証は、例えば受信した証明書に関する情報のメッセージダイジェストを生成し、発行時に生成したダイジェストの整合性をチェックする。あるいは、証明書に関する情報の中から証明書の有効期限に関する情報を抽出する。
【００４３】
次に、図６に示した配信サーバからクライアント装置へのDRMリソースを配信する際のHTTPレスポンス時（図６において番号４´を付した処理）における具体的なリソース提供時における通信手順について、図７を用いて説明する。ただし、ここでは場合分けとして、まだ利用許諾されていないコンテンツヘアクセスして決済に成功した場合を図７（ａ）に、過去にアクセス済みであって既に利用許諾済みのコンテンツへ再度アクセスした場合を図７（ｂ）に、まだ利用許諾されていないコンテンツへアクセスしたが決済に失敗した場合を図７（ｃ）に、そもそも利用が許諾されないコンテンツへアクセスした場合を図７（ｄ）に、それぞれ図を分けて説明する。なお、ここでも説明の都合上、各通信手順には便宜的に番号を付してある。
【００４４】
図７（ａ）を用いて、まだ利用許諾されていないコンテンツヘアクセスして決済に成功した場合について説明する。配信サーバはクライアント装置からDRMリソースのリクエストを受けると（番号３）、DRMリソースの提供を開始する前に、権利管理モジュールに対して、カードIDに対応するコンテンツの利用許諾状況を表す権利リポジトリ（あるいはリクエストされたコンテンツのリソースIDに対応する権利リポジトリ）を問合せる（番号１３）。カードIDに対応するコンテンツの利用許諾状況を表す権利リポジトリは、ユーザDBに蓄積されたデータレコード中の一群の許諾情報ないし対応する権利管理DBに蓄積された各利用許諾状況のデータレコードに対応し、コンテンツのリソース中に対応する権利リポジトリは、権利管理DBに蓄積された権利情報レコードに対応する。この例では「カードID（のユーザ）」に対して「リソースID」に対応するDRMリソースの利用が未だ許諾されていないので、権利管理モジュールは権利管理DBを参照した上で「未許諾」である旨を配信サーバに返答する（番号１４）。未許諾の返答を受けた配信サーバは、ルータに対して「カードID」の電子マネーを原資とした電子決済を要求する（番号１５）。ルータは要求された決済額に相当する決済を行い、該決済が完了したことを配信サーバに返答する（番号１６）。配信サーバではこの返答を受けて、権利管理モジュールに対して「カードID」に対応する権利リポジトリに「リソースID」の利用権を追加するよう（あるいは、「リソースID」に対応する許諾先リポジトリに「カードID」を追加するよう）に更新要求する（番号１７）。その結果、権利リポジトリが「未許諾」から「許諾」に更新されると、「カードID（のユーザ）」に対して「リソースID」の利用が許諾された状態になるので、その返答（番号１８）に応じて配信サーバはクライアント装置に対してDRMリソースの提供を開始する（番号４´）。この際に、提供するDRMリソースに対して、（当該リソースを元々提供している）許諾元IDや許諾先ID（例えばカードIDが該当してよい）を明示する情報を付加したり、あるいは、これらのIDをキーとして暗号化（エンコード）を施して配信する。
【００４５】
図７（ｂ）に示すように、過去にアクセス済みであって既に利用許諾済みのコンテンツへ再度アクセスした場合には、「カードID（のユーザ）」に対して「リソースID」の利用は既に許諾されているので、配信サーバとルータ間で電子決済関連の手続き（図７（ａ）の番号１４〜番号１７を付した一連の通信手順）を踏むことなく、DRMリソースの提供が開始される。
【００４６】
図７（ｃ）に示すように、まだ利用許諾されていないコンテンツへアクセスしたが決済に失敗した場合（例えば、ICカードにチャージされている電子マネーが足りないなどによりルータでの電子決済が失敗した場合）、ルータは配信サーバに対してその旨を通知する（番号１６´）。配信サーバでは決済失敗の通知を受けた場合に、DRMリソースに対するアクセスを一切拒否して、クライアント装置に対してエラー通知（決済に失敗したためリソースは提供不能である旨）をレスポンスする（番号４）。
【００４７】
図７（ｄ）に示すように、そもそも利用が許諾されることのないコンテンツへアクセスした場合（リクエストされたリソースが許諾不可のものであった場合）、権利管理モジュールは「許諾不可」である旨を配信サーバに返答し（番号１９）、配信サーバはクライアント装置に対してエラー通知（リソースは許諾不可である旨）をレスポンスする（番号４）。なお、ここで「許諾不可」である場合とは、例えば特定の許諾先ID（例えばカードIDが該当してよい）にのみアクセスを許諾しうるよう、権利者により予め設定されている場合等である。
【００４８】
上述したような通信手順に従い、サーバシステムＡとルータＢ１間で認証・決済の手続きをした上で、サーバシステムＡはクライアント装置（Ｂ２〜Ｂ５）に対してコンテンツを配信する。そこで、上記通信手順にのっとりコンテンツを配信する処理について説明する。ただし、実際にはサーバシステムＡとクライアントシステムＢとの間では、通信手順にのっとり所定の情報を送受信しながら並行して各々の処理を実行するものであることから、ここでは説明を理解しやすくするために、ユーザアクセス開始からコンテンツ取得までの処理を各々のシステムでそれぞれ独立に実行される処理に分けて説明する。すなわち、配信サーバＡ７が主となり実行するサーバシステムＡ側の処理である「コンテンツ配信処理」を図８に、ルータＢ１が実行するクライアントシステムＢ側における認証・決済の手続きを行う「認証・決済処理」を図９に、それぞれ図を分けて説明する。
【００４９】
図８は、サーバシステムＡで実行する「コンテンツ配信処理」の一実施例を示すフローチャートである。当該処理は、サーバシステムＡ中における特にWWWサーバとして機能する配信サーバＡ７が主となり実行する処理である。なお、図５〜図７と当該処理フローとの対応関係を理解し易くするために、図中において各処理内容の前に図５〜図７に示した通信手順の番号に相当する番号を便宜的に付してある。
【００５０】
ステップＳ１は、クライアントシステムＢからコンテンツ配信要求などの各種リクエスト（HTTPリクエスト）を受け付ける。ステップＳ２は、コンテンツ配信要求であってアクセス対象として指定されているコンテンツが利用制限付きのリソースデータ（DRMリソース）であるか否かを判定する。この判定に応じて、HTTPリクエストを受け付けると、利用制限のない一般のリソース（non DRMリソース）を配信する一般リソース配信用の配信処理と、利用制限のあるDRMリソースを配信するDRMリソース配信用の配信処理とを切り替える。すなわち、コンテンツ配信要求以外のリクエスト、あるいはコンテンツ配信要求であるがアクセス対象として指定されているコンテンツがDRMリソース以外のリソースである場合には（ステップＳ２の他）、一般リソース配信用の配信処理としてクライアントシステムＢに対して通常のレスポンスを行って当該処理を終了する（ステップＳ３）。他方、アクセス対象がDRMリソースである場合には（ステップＳ２のDRMリソース）、DRMリソース配信用の配信処理としてステップＳ４以降の処理を実行する。まず、コンテンツ配信を要求してきたクライアントシステムＢのルータの特定を行う（ステップＳ４）。ルータが未特定である場合には（ステップＳ４の未特定）、ルータを特定するあるいはルータ特定に失敗するまでルータ探索を行う（ステップＳ６）。ルータの特定に失敗した場合には（ステップＳ４の特定失敗）、クライアントシステムＢに対してエラーレスポンス（HTTPレスポンス）を行って当該処理を終了する（ステップＳ５）。
【００５１】
一方、ルータの特定に成功した場合には（ステップＳ４の特定）、特定したルータに対して「証明書問合せ」を送信する（ステップＳ７）。ステップＳ８は、前記「証明書問合せ」を送信したルータからの返答が「証明あり」か「証明なし」であるかを判定する。この際に、特定したルータ以外からの返答であった場合には（ステップＳ８の非該当ルータ）、ステップＳ４に戻ってルータの特定をやり直す。ステップＳ８において特定ルータからの返答が「証明なし」である場合には（ステップＳ８の証明なし）、ルータに対してカードIDを問合せ（ステップＳ１９）、該問合せたカードIDに基づきID認証を行い（ステップＳ２０）、さらに前記ID認証に成功したか失敗したかを判定する（ステップＳ２１）。ID認証に失敗した場合には（ステップＳ２１の失敗）、クライアントシステムＢに対してエラーレスポンスを行い当該処理を終了する（ステップＳ２３）。ID認証に成功した場合には（ステップＳ２１の成功）、ルータに対して発行した証明書を送信する（ステップＳ２２）。
【００５２】
上記ステップＳ８において、特定したルータからの返答が「証明あり」である場合には（ステップＳ８の証明あり）、特定したルータに対して記憶されている「証明書」を送付するよう要求する（ステップＳ９）。そして、該要求に基づきルータから送信された「証明書」が有効であるか無効であるかの検証を行い（ステップＳ１０）、「証明書」の検証に成功したか否かを判定する（ステップＳ１１）。「証明書」の検証に失敗した場合、つまり送付された証明書が有効期限の切れている無効な証明書である場合には（ステップＳ１１の失敗）、上述したステップＳ１９〜ステップＳ２３の処理を実行して処理を終了する。「証明書」の検証に成功した場合、つまり送付された証明書が有効期限の切れていない有効な証明書である場合には（ステップＳ１１の成功）、権利管理DBを参照して権利リポジトリを確認し（ステップＳ１２）、利用許諾状況を判定する（ステップＳ１３）。利用許諾状況が許諾不可である場合には（ステップＳ１３の許諾不可）、クライアントシステムＢに対してエラーレスポンスを送信してコンテンツ配信を行うことなく当該処理を終了する（ステップＳ１８）。利用許諾状況が許諾である場合には（ステップＳ１３の許諾）、クライアントシステムＢに対してDRMリソースの配信を開始する（ステップＳ１７）。利用許諾状況が未許諾である場合には（ステップＳ１３の未許諾）、決済要求を行って（ステップＳ１４）、該要求に基づく決済が完了したか否かを判定する（ステップＳ１５）。そして、決済が完了した場合には（ステップＳ１５の完了）権利リポジトリを更新し（ステップＳ１６）、コンテンツ配信を開始する（ステップＳ１７）。決済が失敗した場合には（ステップＳ１５の失敗）、ステップＳ１８の処理へジャンプしてコンテンツ配信を行うことなく当該処理を終了する。
【００５３】
なお、上記したステップＳ１２〜ステップＳ１６までの処理は権利管理モジュールＡ５により、また上記したステップＳ１９〜ステップＳ２２の処理はアカウントモジュールＡ４により各々実行される処理であり、これらの処理は配信サーバＡ８から各モジュールＡ５又はＡ４に対して各処理を行うよう制御されることにより実行されるようになっている。
【００５４】
図９は、ルータ側で実行される「認証・決済処理」の一実施例を示すフローチャートである。該処理は上記したサーバシステムＡ側で実行される「コンテンツ配信処理」にあわせてクライアントシステムＢ側のルータＢ１で並列的に動作される処理フローであって、配信サーバＭＳからの要求に基づきクライアントシステムＢを構成する全てのクライアント装置（Ｂ２〜Ｂ５）に関する認証・決済を一括して行う処理である。ルータＢ１はその名のとおりパケットデータのルーティング（経路選択）を行うが、本発明にかかる処理を実現するために（機能的には全機能を実装していないにしろ）HTTPサーバプロセスを立ち上げている。少なくとも、HTTPサーバプロセスはSSL等による秘匿通信はサポートしている。HTTPサーバプロセスは特定のポートを各種情報リクエスト受付用に開いておき、ここにリクエストが入った場合に当該処理を実行する。なお、フローの前提としてSSL等による秘匿通信の確立処理があり、またルータ本来のルーティング機能（経路選択機能）に関する処理もあるが、それらの処理についてはここでは図示及び説明を省略する。
【００５５】
ステップＳ３１は、サーバシステムＡからの各種リクエスト（HTTPリクエスト）を受け付ける。ステップＳ３２は、該ルータに接続済みのカードリーダにICカードが挿入済みであり、また該挿入されたICカードが正規のカードであって読み取ることができるか否かを判定する。カードリーダにICカードが挿入されていない、あるいは正規のカードでないためにカードIDなどの情報が読み取れないなどの場合には（ステップＳ３２のなし）、カードエラーであることをサーバシステムＡに対して返答する（ステップＳ３３）。カードリーダにICカードが挿入されており、該ICカードが正規のカードであってカードIDなどの情報が読み取れる場合には（ステップＳ３２のあり）、サーバシステムからのリクエスト内容を判定し（ステップＳ３４）、該リクエスト内容に従う処理を各々実行する。リクエスト内容が「証明書関連」であって「証明要求」である場合には（ステップＳ３４の証明書関連かつステップＳ３５のＹＥＳ）、証明書を送信する（ステップＳ３６）。「証明書問合せ」である場合には（ステップＳ３４の証明書関連かつステップＳ３５のＮＯ：証明問合）、証明有無（証明あり又は証明なし）をサーバシステムＡに対して返答する（ステップＳ３７）。証明書を受信した場合には（ステップＳ３４の証明書関連かつステップＳ３５のＮＯ：証明書受信）、サーバより受信した証明書をカードIDに対応付けて保持する（ステップＳ３８）。リクエスト内容が「ID要求」である場合には（ステップＳ３４のID要求）、挿入済みのカードからカードIDを読み取ってサーバシステムＡに対して送信する（ステップＳ３９及びステップＳ４０）。リクエスト内容が「決済要求」である場合には（ステップＳ３４の決済要求）、挿入済みのカードから電子マネーデータを読み取り残高を確認する（ステップＳ４１及びステップＳ４２）。該読み取った電子マネー残高がコンテンツ利用・購入にかかる対価である所定の金額以上である場合には（ステップＳ４２のＯＫ）、電子マネーデータの更新を行うと共に、決済が完了したことを返答する（ステップＳ４３及びステップＳ４４）。電子マネー残高がコンテンツ利用・購入にかかる対価である金額に満たない場合には（ステップＳ４２のＮＧ）、決済に失敗したことをサーバシステムＡに対して返答する（ステップＳ４５）。
【００５６】
以上のようにして、この発明に係るネットワーク認証・決済システムを適用したコンテンツ配信システムにおいては、利用制限付きのリソースデータ（DRMリソース）へのアクセス時に、クライアントシステムＢを構成する各々のクライアント装置（Ｂ２〜Ｂ５）を認証証明に関与させることなく、従来において個々のクライアント装置（Ｂ２〜Ｂ５）毎に行われていた認証証明に関する処理手順についてのすべてを、当該クライアントシステムＢを構成するネットワーク内のルータＢ１に一括して任せるようにしている。上述したように、ルータＢ１に接続されているカードリーダに挿入されたICカードの情報がキーとなり認証を行うので、一度購入したコンテンツを他の利用態様の際に再度購入するといった、ユーザにとってはわずらわしい手間が省ける。例えば、ユーザがCDで楽曲を購入した場合などに、従来ではCDに収録された曲をカラオケで利用したり携帯電話の着信音に利用しようとする場合には再度使用料を支払わなければならなかったが、ネットワーク装置に予め登録済みのICカードを挿入するあるいは携帯電話をかざすだけで既に購入済であることの確認ができるようになるので、そうしたことをなくすことができる。さらに、登録済みであって十分に電子マネーがチャージしてあるICカードをルータＢ１にさしておくだけで自動的に認証乃至決済が行われるので、ユーザはコンテンツの利用権の許諾を受けるための手続きを、特段に意識することなく簡便に行うことができるようになる。このように、本発明によると、クライアント装置に接続されネットワークを構成するルータは従来知られた「通信経路の制御機能」だけでなく、「ネットワークサービス管理機能」を担う従来にないネットワーク装置となる。
なお、以上において、ICカード自体に電子マネーが保持されているものを前提として説明を行ったが、ICカードによってはカードIDを保持するものの、電子マネーを保持・管理する能力を持たない場合もありえる。こういった場合は、ルータＢ１において番号８を付したID返答に際して（図６参照）、当該カードIDを保持しているICカードは決済機能を備えていない旨の情報を添付してサーバシステムＡに通知し、前述のサーバシステムＡに配置された決済モジュールＡ６がクライアントシステムＢに配置されているルータＢ１（ネットワーク装置）に成り代わり、所定の決済手法（例えばクレジット決済等）により決済を行う。決済モジュールＡ６への決済要求は、ルータＢ１から行ってもよいし、サーバシステムＡ内で行ってもよい。
【００５７】
ここで、サーバシステムＡによるDRMリソースの配信からクライアントシステムＢによるDRMリソースの利用までのデータ処理態様について、図１０を用いて簡単に説明する。図１０は、サーバシステムＡ及びクライアントシステムＢで行われるデータ処理態様について示す機能ブロック図である。ただし、この実施例では、DRMリソースを所定のブロック（フレーム）単位で逐次送信し、受信側では受け取ったブロック単位のデータを逐次デコードして再生するストリーミング配信型を例にする。
【００５８】
サーバシステムＡではコンテンツ配信対象とされたDRMリソースをコンテンツストレージＡ３からブロック（フレーム）単位に読み出して、該読み出されたブロック（フレーム）単位のDRMリソースに対して、許諾元ID、許諾先ID、リソースIDなどの情報を所謂電子透かしとして埋め込みする（Ｄ１）。そして、許諾先ID、リソースID、クライアントアドレスあるいは配信要求時刻等（あるいは、これらの情報を元にMD5等の一方向性関数により取得される情報）から暗号化キーを作成し（Ｄ２）、該作成された暗号化キーとパケット送信毎にパケットをカウントするパケットカウンタ（Ｄ５）からのパケット番号とに基づいて暗号化（スクランブル）及びパケット化を行う（Ｄ３及びＤ４）。具体的には、例えば作成された暗号化キーとパケット番号とを乱数種として乱数列を生成し、１ブロック内に含まれるデータを所定バイトづつ取り込み、順次取得する乱数値に応じてサイクリックにシフトする（スクランブルをかける）。このようにしてパケット毎に暗号化されたDRMリソースを、クライアントシステムＢ（エンドユーザ）に対して送信する。
【００５９】
他方、受信側でありエンドユーザであるクライアントシステムＢ側では、上記した手順と逆の手順を踏む。すなわち、サーバシステムＡからパケット毎に暗号化されたDRMリソースを受信すると、まずアンパケットによりデータを復元する（Ｅ１）。そして、カードID（許諾先IDに相当する）、リソースID、クライアントアドレスあるいは配信要求時刻等から復号化キーを作成し（Ｅ３）、該作成された複合化キーとパケット送信毎にパケットをカウントするパケットカウンタ（Ｅ２）からのパケット番号とに基づいて復号化を行う（Ｅ４）。この際に、サーバシステムＡ側での暗号化キーとクライアントシステムＢ側で生成した復号化キーとが一致していなければ、正しく復号化することができない。そこで、図１０の場合には、暗号化キー生成ブロック（Ｄ２）と復号化キー生成ブロック（Ｅ３）とは処理的には同じ処理を行うものであり、暗号化（又は復号化）する際のデータの処理手順がそれぞれ逆となるだけである。こうして復号化されたDRMリソースに基づいて、DRMリソース再生などのコンテンツ利用がなされる。
【００６０】
上記のようにして、サーバクライアントＡからDRMリソースの配信をうけた各クライアント装置（Ｂ２〜Ｂ５）では、権利付与されている制限範囲内（購入したコンテンツの利用許諾状況による）で、該配信されたDRMリソースを利用することができる。例えば、ユーザがクライアント装置（Ｂ２〜Ｂ５）のいずれかを用いて、ユーザ所望のある楽曲（定義データにより規定される、ひとまとまりのパッケージとして定義された１乃至複数のリソースで構成されたもの）の利用権を購入する。すると、権利管理 DBにユーザが所持しているICカードの固有情報に紐付けされて、購入した楽曲（コンテンツ）を構成する各要素コンテンツの利用が可能となる。要素コンテンツとは、ギタートラックやボーカルトラックなどの楽曲を構成する各トラック（又はパート）単位のコンテンツのことであり、前記配信される楽曲（１のコンテンツ）と区別するために便宜的に用いる。つまり、１のコンテンツは１乃至複数の要素コンテンツを含む。このような１乃至複数の要素コンテンツからなる１のコンテンツを配信する際には、各要素コンテンツ毎にユーザ認証・決済が行われて、利用許諾されている要素コンテンツのみが配信される。そこで、ユーザは購入した楽曲を構成する１乃至複数の要素コンテンツのうち、決済しないなどにより一部の要素コンテンツを除いた状態でコンテンツ再生することができる。例えば、ギターパートとボーカルパートに関しては決済を行わずに、これらを除いた他のパートについてはサーバシステムＡからストリーミング配信により取得することにより、ユーザ自身の演奏によるギター演奏や歌唱を前記ストリーミング再生される本来のバック演奏に併せて行うことができる。
【００６１】
上記したように、図１に示すコンテンツ配信システムでは、MP3等の音楽ファイルや映像データなどのコンテンツを、トラック（パート）単位で配信・購入するのに最適である。また、上述した図１０に示すようにして配信されるコンテンツ、及び／又はクライアント装置（コンテンツ利用・作成装置）を用いたユーザ自身の制作（演奏）によるコンテンツを適宜に組み合わせて、各ユーザは自身が操作できるクライアント装置上において新たにオリジナルなコンテンツを作成することができる。また、各ユーザがクライアント装置で作成したオリジナルなコンテンツを適宜に利用許諾を設定し、サーバシステムＡにコンテンツ登録することで、Web上で広く他のユーザに対して公開することが可能となる。そこで、１曲を構成するトラックあるいはパートといった単位で利用が認められたコンテンツの配信を受け、これを利用してユーザオリジナルなコンテンツを作成することのできるクライアント装置の機能について図１１を用いて、ユーザ個々のクライアント装置で作成したコンテンツをサーバシステム側に登録する際の通信手順について図１２を用いてそれぞれ説明する。
【００６２】
図１１は、クライアント装置が具えるコンテンツ利用・作成にかかる各種機能を示す機能ブロック図である。これらの各機能全体の動作は、図示しない制御部により統制制御される。通信インタフェース６を介してルータＢ１からDRMリソースが供給されると、スイッチＦ２は、該受信したデータをキャッシュＦ４（例えばハードディスクを含む、任意に再読出しが可能なキャッシュ）又はDRMデコーダ（図１０参照）の何れに供給するかを制御する。具体的には、通常の受信データであればキャッシュＦ４に格納し、DRMリソースのストリームデータであればDRMデコーダＦ３に供給する。バッファＦ５は、DRMリソースの再生同期化を行うためのものであり、DRMリソースの時間管理情報（タイムスタンプやデルタタイム等）に基づいた再生読出し制御を行う（なお、DRMリソースが複数あればこれらが相互に同期するよう調整する）。ミキサ部Ｆ７は、各リソースあるいはマイクなどの外部入力装置８から入力したデータを、メディア制御データあるいはマウスやボリューム等の入力デバイス４からの操作子信号に応じて適宜にミックスダウンして出力デバイス５（ディスプレイ・スピーカ等）に出力する。出力制御部Ｆ６は、受信したデータの出力状態（例えば、ディスプレイ上に表示する際の表示配置位置など）を制御して、描画情報や音声データなどを出力デバイス５に対して出力する。操作解釈部Ｆ８はマウスやボリューム等の操作信号を受付け（操作イベントを受け付け）、どういった操作が行われたかを解釈する。例えば、URLの入力がキーボードによりなされた場合には、そのURLのリクエストを送信するよう制御し、ボリューム等が操作された場合はミキサ部Ｆ７に対して相当の制御信号（ミキシング制御データ）を送る。操作解釈部Ｆ８は、上述のとおり、サーバシステムＡより提供されるメディア制御データと同等のミキシング制御データを出力するが、このミキシング制御データまたは、出力制御部Ｆ６あるいはミキサ部Ｆ７に入力されるメディア制御データとミキシング制御データとを結合したものを別途記憶しておくように構成してもよい。操作解釈部Ｆ８は、この記録されたデータを新規な要素コンテンツ（メディア制御データ）としてサーバシステムＡに登録するために、通信インタフェース６を介して送信するように制御する。
また、上述のように、１つのコンテンツを構成する１乃至複数のコンテンツのうち、一部のコンテンツを除いた状態でコンテンツを再生するとともに、クライアントシステムＢで入力あるいは再生される他の要素コンテンツと組み合わせて、ユーザオリジナルなコンテンツを作成する場合には、メディア制御データをそのまま利用し、対応するリソースを取得しない（空いた）チャンネルに、クライアントシステムＢで入力あるいは再生される他の要素コンテンツを割り当てるようにしてもよいし、クライアントシステムＢにて新規にメディア制御データを作成するようにしてもよい。あるいは、定義データあるいはメディア制御データにおいて、あらかじめクライアントシステムＢ内の外部入力装置８に対応するリソース（当該リソースは権利管理DBでは管理されない）およびチャンネルを利用可能に定義しておき、これを適用するようにしてもよい。
【００６３】
図１２は、コンテンツ登録時におけるシステム間の通信手順を示すシーケンス図である。ただし、ここでは上記図６に示した認証証明に関する手順から後の手順について説明する。図１２に示すように、コンテンツ登録時における通信手順としては、まずクライアント装置からは登録したいコンテンツ（クライアントシステムＢで入力・記録乃至保持されている音声データや映像データ等の各種コンテンツあるいは上記ミキシング制御データ）の情報とともに、ユーザが任意に決定した利用条件や関連権利の情報がHTTPリクエストにより送付される（番号３）。サーバシステムでは送付された情報に基づき、コンテンツにユニークなリソースIDを発行し、その他の情報（カードIDや権利条件等）とともに権利管理DBに新規登録、あるいはユーザDBのレコードを更新する。コンテンツ登録の際において、実体データを単一のサーバシステムに伝送する必要は無く、ユーザは任意のサーバシステム（なお、クライアントシステム自体がサーバ機能を有する場合を含む）に実体データを配置するようにしてよい。ただし、このように構成する場合は、登録情報と実体データとの整合性を確認するために、権利管理 DB（Ａ１）あるいはインデクスサーバ（Ａ８）に登録するコンテンツの情報として、チェックサムなど権利管理DB（Ａ１）に登録した情報と実体データとの整合性を検証するための情報を併せて登録することが必要となる。また、コンテンツ登録の際に、実体データを単一のサーバシステムＡに伝送しない場合には、権利管理 DB（Ａ１）、ユーザDB（Ａ２）、インデクスサーバ（Ａ８）に対して、登録したコンテンツ（を参照するためのリソースIDやURL等）の情報が登録されるのみである。なお、実体データをも伝送したような場合には、さらにサーバシステムＡのコンテンツストレージ（Ａ３）に実体データが保存される。
【００６４】
上述したように、ユーザはある楽曲の利用権を購入すると、ユーザは購入した楽曲を構成する要素コンテンツのうち、一部の要素コンテンツを除いてコンテンツ再生することができる。そこで、ユーザは例えばギターパートを除いたコンテンツを再生し、本来のバック演奏に併せてユーザ自身の演奏によるギター演奏をオリジナルなコンテンツとして作成することができる。また、複数の購入した楽曲を構成するそれぞれの要素コンテンツあるいは自身が演奏したギター演奏などを任意に組み合わせたオリジナルなコンテンツを、権利者の承諾の元に新たに作成することができる。こうすると、例えば楽曲のリミックスやヒップホップのようなサンプリングを行う楽曲の製作や、映像コンテンツの一部の映像トラックの一部を他の映像データに差し替えたパロディ版の製作などを行うことができるようになる。また、こうして作成したオリジナルなコンテンツを、権利範囲を設けてサーバシステムに登録することで広くそのコンテンツを他のユーザに対しても公開することができるようになる。また、こうしたコンテンツ公開にかかるユーザ認証・決済処理を簡易に行うこともできるようになる。
【図面の簡単な説明】
【００６５】
【図１】本発明に係るネットワーク認証・決済システムを適用したコンテンツ配信システムの一実施例の全体システム構成を略示するシステムブロック図である。
【図２】１セッション内に含まれる処理の流れを概念的に示した処理概念図であり、図２（ａ）はユーザ登録時、図２（ｂ）はコンテンツ利用時、図２（ｃ）はコンテンツ登録時におけるセッション概要を示す。
【図３】図１に示したサーバシステム又はクライアントシステムの各装置いずれか１つの全体構成の一実施例を示すハード構成ブロック図である。
【図４】データ構成の一実施例を示す概念図であり、図４（ａ）はリソースデータ、図４（ｂ）はユーザ情報に関するレコードデータ、図４（ｃ）は利用許諾状況又は権利情報に関するレコードデータ、図４（ｄ）はコンテンツの所在を表すデータである。
【図５】利用制限の無いリソースデータへのアクセス時におけるシステム間の通信手順を示すシーケンス図である。
【図６】利用制限付きのリソースデータへのアクセス時におけるシステム間の通信手順を示すシーケンス図である。
【図７】図６に示したDRMリソースを配信する際のHTTPレスポンス時における具体的なリソース提供時における通信手順を示すシーケンス図であり、図７（ａ）はまだ利用許諾されていないコンテンツヘアクセスして決済に成功した場合、図７（ｂ）は過去にアクセス済みであって既に利用許諾済みのコンテンツへ再度アクセスした場合、図７（ｃ）はまだ利用許諾されていないコンテンツへアクセスしたが決済に失敗した場合、図７（ｄ）はそもそも利用が許諾されないコンテンツへアクセスした場合である。
【図８】コンテンツ配信処理の一実施例を示すフローチャートである。
【図９】認証・決済処理の一実施例を示すフローチャートである。
【図１０】サーバシステム及びクライアントシステムで行われるデータ処理態様について示す機能ブロック図である。
【図１１】クライアント装置が具えるコンテンツ利用・作成にかかる各種機能を示す機能ブロック図である。
【図１２】コンテンツ登録時におけるシステム間の通信手順を示すシーケンス図である。
【符号の説明】
【００６６】
Ａ…サーバシステム、Ａ１…権利管理（DRM）DB、Ａ２…ユーザDB、Ａ３…コンテンツストレージ、Ａ４…アカウントモジュール、Ａ５…権利管理モジュール、Ａ６…決済モジュール、Ａ７…配信サーバ、Ａ８…インデクスサーバ、Ｂ…クライアントシステム、Ｂ１…ルータ、Ｂ２…パーソナルコンピュータ、Ｂ３…電子音楽装置、Ｂ４…MTR/ミキサ、Ｂ５…その他のコンテンツ利用機器、１…ＣＰＵ、２…ＲＯＭ、３…ＲＡＭ、４…入力デバイス、５…LAN通信インタフェース、６…WAN通信インタフェース、７…出力デバイス、ＣＲ…カードリーダ、Ｃ…ICカード、１Ｄ…通信バス（データ及びアドレスバス）、Ｘ…インターネット
【特許請求の範囲】
【請求項１】
所定の通信回線を介してサーバ装置及びクライアント装置間においてユーザ認証を行うネットワーク認証・決済システムであって、
異なるネットワークどうしを通信回線を介して相互接続し、一方のネットワーク上を流れる各種情報を他方のネットワークに中継するネットワーク装置と、
個々のクライアント装置からのリクエストに応じて、該リクエストしたクライアント装置を含むネットワークに接続されている前記ネットワーク装置を探索して特定する特定手段と、前記特定したネットワーク装置に対してユーザ固有の固有情報を問合せる固有情報問合せ手段と、前記固有情報の問合せに応じて前記特定したネットワーク装置から返答される固有情報に基づきユーザ認証を行うユーザ認証手段と、前記ユーザ認証によりユーザを認証した場合に所定の証明書情報を発行し、該発行した証明書情報を前記ネットワーク装置に送付する送付手段とを含む、１のネットワークを構成してなるサーバ装置と、
前記ネットワーク装置を含むネットワークに接続されてなり、ユーザ操作に応じたリクエストを前記ネットワーク上に送信する送信手段と、前記リクエストに応じて他のネットワークから各種情報を受信する受信手段とを含む、前記サーバ装置とは異なるネットワークを構成する１乃至複数のクライアント装置とを
具えてなり、
前記ネットワーク装置は、ネットワークを構成している１乃至複数のクライアント装置全てに関するユーザ認証の手続きを一括して処理することを特徴とするネットワーク認証・決済システム。
【請求項２】
前記サーバ装置は、ユーザ認証されたクライアント装置からのデータ配信リクエストに応じて、該リクエストに応じたデータの利用が当該ユーザに関して許諾済みであるか否かを判定し、未許諾である場合に前記クライアント装置に対して電子決済を行うよう要求する決済要求手段と、前記電子決済の要求に応じて取得した決済情報に応じて前記データの利用許諾を更新する更新手段とを具え、
前記ネットワーク装置は、前記サーバ装置からの電子決済の要求に応じて電子決済を行い、その成否に関する決済情報を前記サーバ装置に対して通知することを、前記クライアント装置に代わって行うことを特徴とする請求項１に記載のネットワーク認証・決済システム。
【請求項３】
異なるネットワークどうしを相互接続し、一方のネットワーク上を流れるデータを他方のネットワークに中継するネットワーク装置であって、
ユーザ固有の固有情報及び／又は電子マネー情報を読み取るデータ読み取り手段と、
他のネットワークを構成するサーバ装置からの前記固有情報の問合せに応じて、前記読み取ったユーザ固有の固有情報を前記サーバ装置に対して送信する固有情報送信手段と、
前記サーバ装置からの証明書情報の問合せに応じて、証明書情報を送信する証明書情報送信手段と、
前記サーバ装置からの電子決済要求に応じて、前記読み取った電子マネー情報に基づき電子決済を行い、その成否に関する決済情報を前記サーバ装置に対して送信する決済情報送信手段と、
前記サーバ装置から配信されたデータを取得する取得手段とを
具えてなり、
前記サーバ装置とは異なるネットワークを構成する１乃至複数のクライアント装置全てに関し、ユーザ認証の手続き及び／又はデータ利用許諾にかかる電子決済の手続きを一括処理することを特徴とするネットワーク装置。
【請求項４】
前記サーバ装置から送信された証明書情報を記憶する記憶手段を具えてなり、前記証明書情報送信手段は前記記憶手段に記憶した証明書情報を送信することを特徴とする請求項３に記載のネットワーク装置。
【請求項５】
前記ネットワーク装置は、１乃至複数のクライアント装置を下位とする階層型のネットワークを構成するように接続し、下位のクライアント装置に関するユーザ認証の手続き及び／又はデータ利用許諾にかかる電子決済の手続きについて、一括して処理することを特徴とする請求項３又は４に記載のネットワーク装置。
【請求項６】
所定の通信回線を介して各種情報を送受信するサーバ装置のコンピュータに、
個々のクライアント装置からのリクエストに応じて、該リクエストしたクライアント装置を含むネットワークに接続されているネットワーク装置を探索して特定する手順と、
前記特定したネットワーク装置に対してユーザ固有の固有情報を問合せる手順と、
前記固有情報の問合せに応じて前記特定したネットワーク装置から返答される固有情報に基づきユーザ認証を行う手順と、
前記ユーザ認証によりユーザを認証した場合に所定の証明書情報を発行し、該発行した証明書情報を前記ネットワーク装置に送付する手順と
を実行させるためのプログラム。
【請求項７】
サーバ装置を含むネットワークとクライアント装置を含む異なるネットワークどうしを通信回線を介して相互接続し、一方のネットワーク上を流れる各種情報を他方のネットワークに中継するネットワーク装置のコンピュータに、
ユーザ固有の固有情報及び／又は電子マネー情報を読み取る手順と、
他のネットワークを構成するサーバ装置からの前記固有情報の問合せに応じて、前記読み取ったユーザ固有の固有情報を前記サーバ装置に対して送信する手順と、
前記サーバ装置からの証明書情報の問合せに応じて、証明書情報を送信する手順と、
前記サーバ装置からの電子決済要求に応じて、前記読み取った電子マネー情報に基づき電子決済を行い、その成否に関する決済情報を前記サーバ装置に対して送信する手順と、
前記サーバ装置から配信されたデータを取得する手順とを
を実行させるためのプログラム。
【請求項１】
所定の通信回線を介してサーバ装置及びクライアント装置間においてユーザ認証を行うネットワーク認証・決済システムであって、
異なるネットワークどうしを通信回線を介して相互接続し、一方のネットワーク上を流れる各種情報を他方のネットワークに中継するネットワーク装置と、
個々のクライアント装置からのリクエストに応じて、該リクエストしたクライアント装置を含むネットワークに接続されている前記ネットワーク装置を探索して特定する特定手段と、前記特定したネットワーク装置に対してユーザ固有の固有情報を問合せる固有情報問合せ手段と、前記固有情報の問合せに応じて前記特定したネットワーク装置から返答される固有情報に基づきユーザ認証を行うユーザ認証手段と、前記ユーザ認証によりユーザを認証した場合に所定の証明書情報を発行し、該発行した証明書情報を前記ネットワーク装置に送付する送付手段とを含む、１のネットワークを構成してなるサーバ装置と、
前記ネットワーク装置を含むネットワークに接続されてなり、ユーザ操作に応じたリクエストを前記ネットワーク上に送信する送信手段と、前記リクエストに応じて他のネットワークから各種情報を受信する受信手段とを含む、前記サーバ装置とは異なるネットワークを構成する１乃至複数のクライアント装置とを
具えてなり、
前記ネットワーク装置は、ネットワークを構成している１乃至複数のクライアント装置全てに関するユーザ認証の手続きを一括して処理することを特徴とするネットワーク認証・決済システム。
【請求項２】
前記サーバ装置は、ユーザ認証されたクライアント装置からのデータ配信リクエストに応じて、該リクエストに応じたデータの利用が当該ユーザに関して許諾済みであるか否かを判定し、未許諾である場合に前記クライアント装置に対して電子決済を行うよう要求する決済要求手段と、前記電子決済の要求に応じて取得した決済情報に応じて前記データの利用許諾を更新する更新手段とを具え、
前記ネットワーク装置は、前記サーバ装置からの電子決済の要求に応じて電子決済を行い、その成否に関する決済情報を前記サーバ装置に対して通知することを、前記クライアント装置に代わって行うことを特徴とする請求項１に記載のネットワーク認証・決済システム。
【請求項３】
異なるネットワークどうしを相互接続し、一方のネットワーク上を流れるデータを他方のネットワークに中継するネットワーク装置であって、
ユーザ固有の固有情報及び／又は電子マネー情報を読み取るデータ読み取り手段と、
他のネットワークを構成するサーバ装置からの前記固有情報の問合せに応じて、前記読み取ったユーザ固有の固有情報を前記サーバ装置に対して送信する固有情報送信手段と、
前記サーバ装置からの証明書情報の問合せに応じて、証明書情報を送信する証明書情報送信手段と、
前記サーバ装置からの電子決済要求に応じて、前記読み取った電子マネー情報に基づき電子決済を行い、その成否に関する決済情報を前記サーバ装置に対して送信する決済情報送信手段と、
前記サーバ装置から配信されたデータを取得する取得手段とを
具えてなり、
前記サーバ装置とは異なるネットワークを構成する１乃至複数のクライアント装置全てに関し、ユーザ認証の手続き及び／又はデータ利用許諾にかかる電子決済の手続きを一括処理することを特徴とするネットワーク装置。
【請求項４】
前記サーバ装置から送信された証明書情報を記憶する記憶手段を具えてなり、前記証明書情報送信手段は前記記憶手段に記憶した証明書情報を送信することを特徴とする請求項３に記載のネットワーク装置。
【請求項５】
前記ネットワーク装置は、１乃至複数のクライアント装置を下位とする階層型のネットワークを構成するように接続し、下位のクライアント装置に関するユーザ認証の手続き及び／又はデータ利用許諾にかかる電子決済の手続きについて、一括して処理することを特徴とする請求項３又は４に記載のネットワーク装置。
【請求項６】
所定の通信回線を介して各種情報を送受信するサーバ装置のコンピュータに、
個々のクライアント装置からのリクエストに応じて、該リクエストしたクライアント装置を含むネットワークに接続されているネットワーク装置を探索して特定する手順と、
前記特定したネットワーク装置に対してユーザ固有の固有情報を問合せる手順と、
前記固有情報の問合せに応じて前記特定したネットワーク装置から返答される固有情報に基づきユーザ認証を行う手順と、
前記ユーザ認証によりユーザを認証した場合に所定の証明書情報を発行し、該発行した証明書情報を前記ネットワーク装置に送付する手順と
を実行させるためのプログラム。
【請求項７】
サーバ装置を含むネットワークとクライアント装置を含む異なるネットワークどうしを通信回線を介して相互接続し、一方のネットワーク上を流れる各種情報を他方のネットワークに中継するネットワーク装置のコンピュータに、
ユーザ固有の固有情報及び／又は電子マネー情報を読み取る手順と、
他のネットワークを構成するサーバ装置からの前記固有情報の問合せに応じて、前記読み取ったユーザ固有の固有情報を前記サーバ装置に対して送信する手順と、
前記サーバ装置からの証明書情報の問合せに応じて、証明書情報を送信する手順と、
前記サーバ装置からの電子決済要求に応じて、前記読み取った電子マネー情報に基づき電子決済を行い、その成否に関する決済情報を前記サーバ装置に対して送信する手順と、
前記サーバ装置から配信されたデータを取得する手順とを
を実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００７−２６１８９（Ｐ２００７−２６１８９Ａ）
【公開日】平成１９年２月１日（２００７．２．１）
【国際特許分類】
【出願番号】特願２００５−２０８６４５（Ｐ２００５−２０８６４５）
【出願日】平成１７年７月１９日（２００５．７．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＴＨＥＲＮＥＴ
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
【公開日】平成１９年２月１日（２００７．２．１）
【国際特許分類】
【出願日】平成１７年７月１９日（２００５．７．１９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＴＨＥＲＮＥＴ
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
[ Back to top ]