(57)【要約】【課題】コンテンツの購入をより便利に行えるようにする。【解決手段】コンテンツデータがプレゼントされる際、プレゼント側からは、自己を識別するための第１の情報、プレゼント先を識別するための第２の情報、および、プレゼントするコンテンツデータを決定するための第３の情報が、送信されてくる。そのような情報が送信されてきた場合、第２の情報を基に、プレゼンを受け取る側に対して、そのプレゼンを受け取るか否かのメールが出される。そして、そのメールに対する返答として受け取るという返事の場合のみ、プレゼントの処理が実行される。本発明は、コンテンツデータにかかわる処理を実行するサーバに適用できる。【選択図】      図３０
2004265334.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツの配信を制御する第１の情報処理装置、コンテンツの配信を要求する第２の情報処理装置、および、コンテンツの配信を受ける第３の情報処理装置から構成される情報処理システムにおいて、
前記第１の情報処理装置は、
前記コンテンツを識別するための第１のＩＤを管理する第１の管理手段と、
前記第２の情報処理装置を識別するための第２のＩＤと前記第３の情報処理装置を識別するための第３のＩＤを管理する第２の管理手段と、
前記第２の情報処理装置から、前記コンテンツの配信の要求があった場合、
前記第１の管理手段により管理されている前記第１のＩＤを、前記第２の情報処理装置に供給する供給手段と、
前記第２の情報処理装置から、前記第１のＩＤ、前記第２のＩＤを特定するための情報、および、前記第３のＩＤを特定するための情報を、それぞれ受信した場合、その情報から、前記第２の管理手段により管理されている前記第２のＩＤと前記第３のＩＤを、それぞれ特定する特定手段と、
前記特定手段により特定された前記第３のＩＤに対応する前記第３の情報処理装置に、前記第１のＩＤで識別される前記コンテンツを配信する配信手段とを備え、
前記第２の情報処理装置は、
前記第１の情報処理装置に、前記コンテンツの配信を要求する要求手段と、
前記要求手段による要求に対応し、前記供給手段により供給された前記第１のＩＤのうち、ユーザにより選択された前記コンテンツに対応する前記第１のＩＤを送信し、前記第２のＩＤを特定するための情報と前記第３のＩＤを特定するための情報を、それぞれ送信する送信手段と
を備え、
前記第３の情報処理装置は、
前記配信手段により配信された前記コンテンツを受信し、記憶する記憶手段を備える
ことを特徴とする情報処理システム。
【請求項２】
第１の装置を識別するための第１のＩＤを管理する第１の管理手段と、
第２の装置を識別するための第２のＩＤを管理する第２の管理手段と、
コンテンツを識別するための第３のＩＤを管理する第３の管理手段と、
前記第１の装置から、前記コンテンツの配信の要求があった場合、前記第３の管理手段により管理されている前記第３のＩＤを、前記第１の装置に供給する供給手段と、
前記第１の装置から、前記第１のＩＤを特定するための情報、前記第２のＩＤを特定するための情報、および、前記第３のＩＤを、それぞれ受信した場合、その情報から、前記第１の管理手段により管理されている前記第１のＩＤと、前記第２の管理手段により管理されている前記第２のＩＤを、それぞれ特定する特定手段と、
前記特定手段により特定された前記第２のＩＤに対応する前記第２の装置に、前記第３のＩＤで識別される前記コンテンツを配信する配信手段と
を備えることを特徴とする情報処理装置。
【請求項３】
前記特定手段より特定された前記第１のＩＤで識別される前記第１の装置のユーザに、前記配信手段により配信される前記コンテンツの料金を課金する課金手段を
さらに備えることを特徴とする情報処理装置。
【請求項４】
前記特定手段により前記第２のＩＤが特定された後、その第２のＩＤで識別される前記第２の装置のユーザに、前記コンテンツの配信を受けるか否かを問い合わせる問い合わせ手段と、
前記問い合わせ手段による問い合わせの返答として、前記第２の装置のユーザから、前記コンテンツの配信を受けるとの内容の返答を受信した場合、前記特定手段により特定された前記第２のＩＤに対応する前記第２の装置に、前記第３のＩＤで識別される前記コンテンツを配信するスケジュールを作成する作成手段を
さらに備え、
前記配信手段は、前記作成手段により作成された前記スケジュールに基づき、前記コンテンツを配信する
ことを特徴とする請求項２に記載の情報処理装置。
【請求項５】
前記作成手段は、前記第１の装置のユーザまたは前記第２の装置のユーザが、前記コンテンツを配信する時刻を指定している場合、その指定された時刻に前記コンテンツを配信するスケジュールを作成する
ことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記第２の装置から、前記スケジュールの提供の要求があり、かつ、前記作成手段により前記第２の装置に対する前記スケジュールが作成されていた場合、そのスケジュールを前記第２の装置に提供する提供手段を
さらに備えることを特徴とする請求項４に記載の情報処理装置。
【請求項７】
前記第１の管理手段と前記第２の管理手段は、同一のテーブルを管理し、そのテーブルは、前記第１のＩＤと前記第２のＩＤを含むＩＤ、ユーザを識別するためのユーザＩＤ、パスワード、および、メールアドレスを、それぞれ関連づけたものであり、
前記特定手段は、前記第１のＩＤを特定するための情報とし、前記ユーザＩＤとパスワードの少なくとも一方の情報を用い、前記第２のＩＤを特定するための情報として、前記メールアドレスを用いる
ことを特徴とする請求項２に記載の情報処理装置。
【請求項８】
第１の装置を識別するための第１のＩＤを管理する第１の管理ステップと、
第２の装置を識別するための第２のＩＤを管理する第２の管理ステップと、
コンテンツを識別するための第３のＩＤを管理する第３の管理ステップと、
前記第１の装置から、前記コンテンツの配信の要求があった場合、前記第３の管理ステップの処理で管理されている前記第３のＩＤを、前記第１の装置に供給する供給ステップと、
前記第１の装置から、前記第１のＩＤを特定するための情報、前記第２のＩＤを特定するための情報、および、前記第３のＩＤを、それぞれ受信した場合、その情報から、前記第１の管理ステップの処理で管理された前記第１のＩＤと、前記第２の管理ステップの処理で管理された前記第２のＩＤを、それぞれ特定する特定ステップと、
前記特定ステップの処理で特定された前記第２のＩＤに対応する前記第２の装置への、前記第３のＩＤで識別される前記コンテンツの配信を制御する配信制御ステップと
を含むことを特徴とする情報処理方法。
【請求項９】
第１の装置を識別するための第１のＩＤを管理する第１の管理ステップと、
第２の装置を識別するための第２のＩＤを管理する第２の管理ステップと、
コンテンツを識別するための第３のＩＤを管理する第３の管理ステップと、
前記第１の装置から、前記コンテンツの配信の要求があった場合、前記第３の管理ステップの処理で管理されている前記第３のＩＤを、前記第１の装置に供給する供給ステップと、
前記第１の装置から、前記第１のＩＤを特定するための情報、前記第２のＩＤを特定するための情報、および、前記第３のＩＤを、それぞれ受信した場合、その情報から、前記第１の管理ステップの処理で管理された前記第１のＩＤと、前記第２の管理ステップの処理で管理された前記第２のＩＤを、それぞれ特定する特定ステップと、
前記特定ステップの処理で特定された前記第２のＩＤに対応する前記第２の装置への、前記第３のＩＤで識別される前記コンテンツの配信を制御する配信制御ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。
【請求項１０】
第１の装置を識別するための第１のＩＤを管理する第１の管理ステップと、
第２の装置を識別するための第２のＩＤを管理する第２の管理ステップと、
コンテンツを識別するための第３のＩＤを管理する第３の管理ステップと、
前記第１の装置から、前記コンテンツの配信の要求があった場合、前記第３の管理ステップの処理で管理されている前記第３のＩＤを、前記第１の装置に供給する供給ステップと、
前記第１の装置から、前記第１のＩＤを特定するための情報、前記第２のＩＤを特定するための情報、および、前記第３のＩＤを、それぞれ受信した場合、その情報から、前記第１の管理ステップの処理で管理された前記第１のＩＤと、前記第２の管理ステップの処理で管理された前記第２のＩＤを、それぞれ特定する特定ステップと、
前記特定ステップの処理で特定された前記第２のＩＤに対応する前記第２の装置への、前記第３のＩＤで識別される前記コンテンツの配信を制御する配信制御ステップと
をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は情報処理システム、情報処理装置および方法、並びにプログラムに関し、コンテンツデータの購入に用いて好適な情報処理システム、情報処理装置および方法、並びにプログラムに関する。
【０００２】
【従来の技術】
近年、インターネットなどのネットワークの普及により、そのネットワーク上で、さまざまな商品を購入する（そのような購入のための手続を行う）ということが一般的になってきている。ネットワーク上で購入できる商品は、さまざまなものがあり、有体物に限らず、無体物もある。無体物としては、例えば、音楽データや映像データなどがある。
【０００３】
無体物の商品のなかには、購入だけでなく、レンタルといった形態もある。いずれの形態にしても、購入者は、コンテンツデータが記憶されているコンパクトディスクなどを販売する音楽店や、コンパクトディスクなどの貸し出しを行うレンタル店などに行かなくても、所望の音楽データや映像データなどのコンテンツデータを、家庭内のコンピュータなどから購入することが可能とされている。
【０００４】
これらの無体物の商品は、有体物の商品と異なり、コピーなどが容易であり、１人の購入者が、他の人にその商品のコピーを渡すといったことが行われる可能性があり、そのような好ましくない行為が行われる可能性がある。よって、このようなコピーなどの好ましくない行為を防ぐような仕組みが、無体物の商品には設けられているのが一般的である。
【０００５】
例えば、コンテンツデータとともに、ライセンス（利用権利）に関するデータも合わせて提供（送信）するようにする。そのライセンスデータにより、ユーザ側に提供されたコンテンツデータの再生などが管理されるようにすることにより、コピーなどの好ましくない行為を防ぐことが行われている。
【０００６】
ユーザがコンテンツデータをネットワークを介して購入する場合、例えば、まず、ユーザは、そのコンテンツデータを扱っているサイトにネットワークを介してアクセスし、そのサイトの指示に従って、所定の情報の入力などの処理を行い、コンテンツデータの購入にかかわる処理を行う。
【０００７】
そのようなコンテンツデータの購入ための処理が終了されると、そのコンテンツデータが、そのサイトから、ネットワークを介して、ユーザ側の装置にダウンロードされる。そのダウンロードされたコンテンツデータは、その装置内のハードディスクドライブなどの記録媒体に、ライセンスデータと共に記憶される。
【０００８】
ライセンスデータは、ユーザ側の装置にダウンロードされた後、コンテンツデータを記憶している装置の固有のＩＤ情報と関連付けられる（バインドされる）。その関連付けがあるために、仮にコンテンツデータがコピーされても、ダウンロードを行った装置以外の、ライセンスデータに基づく関連付けが行えない装置で、そのコピーされたコンテンツデータが再生されてしまうようなことを防ぐことが可能となっている。
【０００９】
【発明が解決しようとする課題】
このように、コンテンツデータは、購入の処理が行われた装置に、ダウンロードされ、その装置で再生される。従って、ユーザが、外出先などで、家の装置とは別の装置で、コンテンツデータの購入を行った場合、購入の処理を行った装置とは異なる家の装置では、購入したコンテンツデータを再生できないといった問題があった。
【００１０】
このよう問題を換言すれば、ユーザが、外出先などで、家の装置とは別の装置を用いて、家の装置に、所望のコンテンツデータを記憶させるための処理を行うことができないといった問題である。従って、ユーザは、コンテンツデータの再生を所望する装置以外の装置で、コンテンツデータの購入を行えないといった課題があった。
【００１１】
このようなことは、コンテンツデータ（ライセンスデータ）を、購入した装置以外の装置で再生することはできないことを示しており、例えば、ユーザＡが、ユーザＢに、コンテンツデータ（ライセンスデータ）をプレゼントするといったことができないことを示唆している。換言すれば、コンテンツデータの購入にかかる料金を支払う人と、その購入されたコンテンツデータを取得する人が、別の人とすることができないといった課題があった。
【００１２】
本発明はこのような状況に鑑みてなされたものであり、ユーザが所望する装置に対して、その装置とは異なる装置からでも、コンテンツデータの購入の処理が行えるようにし、そのコンテンツデータを他のユーザにプレゼントすることができるようにすることを目的とする。
【００１３】
【課題を解決するための手段】
本発明の情報処理システムの第１の情報処理装置は、コンテンツを識別するための第１のＩＤを管理する第１の管理手段と、第２の情報処理装置を識別するための第２のＩＤと第３の情報処理装置を識別するための第３のＩＤを管理する第２の管理手段と、第２の情報処理装置から、コンテンツの配信の要求があった場合、第１の管理手段により管理されている第１のＩＤを、第２の情報処理装置に供給する供給手段と、第２の情報処理装置から、第１のＩＤ、第２のＩＤを特定するための情報、および、第３のＩＤを特定するための情報を、それぞれ受信した場合、その情報から、第２の管理手段により管理されている第２のＩＤと第３のＩＤを、それぞれ特定する特定手段と、特定手段により特定された第３のＩＤに対応する第３の情報処理装置に、第１のＩＤで識別されるコンテンツを配信する配信手段とを備え、第２の情報処理装置は、第１の情報処理装置に、コンテンツの配信を要求する要求手段と、要求手段による要求に対応し、供給手段により供給された第１のＩＤのうち、ユーザにより選択されたコンテンツに対応する第１のＩＤを送信し、第２のＩＤを特定するための情報と第３のＩＤを特定するための情報を、それぞれ送信する送信手段とを備え、第３の情報処理装置は、配信手段により配信されたコンテンツを受信し、記憶する記憶手段を備えることを特徴とする。
【００１４】
本発明の情報処理装置は、第１の装置を識別するための第１のＩＤを管理する第１の管理手段と、第２の装置を識別するための第２のＩＤを管理する第２の管理手段と、コンテンツを識別するための第３のＩＤを管理する第３の管理手段と、第１の装置から、コンテンツの配信の要求があった場合、第３の管理手段により管理されている第３のＩＤを、第１の装置に供給する供給手段と、第１の装置から、第１のＩＤを特定するための情報、第２のＩＤを特定するための情報、および、第３のＩＤを、それぞれ受信した場合、その情報から、第１の管理手段により管理されている第１のＩＤと、第２の管理手段により管理されている第２のＩＤを、それぞれ特定する特定手段と、特定手段により特定された第２のＩＤに対応する第２の装置に、第３のＩＤで識別されるコンテンツを配信する配信手段とを備えることを特徴とする。
【００１５】
前記特定手段より特定された第１のＩＤで識別される第１の装置のユーザに、配信手段により配信されるコンテンツの料金を課金する課金手段をさらに備えるようにすることができる。
【００１６】
前記特定手段により第２のＩＤが特定された後、その第２のＩＤで識別される第２の装置のユーザに、コンテンツの配信を受けるか否かを問い合わせる問い合わせ手段と、問い合わせ手段による問い合わせの返答として、第２の装置のユーザから、コンテンツの配信を受けるとの内容の返答を受信した場合、特定手段により特定された第２のＩＤに対応する第２の装置に、第３のＩＤで識別されるコンテンツを配信するスケジュールを作成する作成手段をさらに備え、配信手段は、作成手段により作成されたスケジュールに基づき、コンテンツを配信するようにすることができる。
【００１７】
前記作成手段は、第１の装置のユーザまたは第２の装置のユーザが、コンテンツを配信する時刻を指定している場合、その指定された時刻にコンテンツを配信するスケジュールを作成するようにすることができる。
【００１８】
前記第２の装置から、スケジュールの提供の要求があり、かつ、作成手段により第２の装置に対するスケジュールが作成されていた場合、そのスケジュールを第２の装置に提供する提供手段をさらに備えるようにすることができる。
【００１９】
前記第１の管理手段と前記第２の管理手段は、同一のテーブルを管理し、そのテーブルは、第１のＩＤと第２のＩＤを含むＩＤ、ユーザを識別するためのユーザＩＤ、パスワード、および、メールアドレスを、それぞれ関連づけたものであり、特定手段は、第１のＩＤを特定するための情報とし、ユーザＩＤとパスワードの少なくとも一方の情報を用い、第２のＩＤを特定するための情報として、メールアドレスを用いるようにすることができる。
【００２０】
本発明の情報処理方法は、第１の装置を識別するための第１のＩＤを管理する第１の管理ステップと、第２の装置を識別するための第２のＩＤを管理する第２の管理ステップと、コンテンツを識別するための第３のＩＤを管理する第３の管理ステップと、第１の装置から、コンテンツの配信の要求があった場合、第３の管理ステップの処理で管理されている第３のＩＤを、第１の装置に供給する供給ステップと、第１の装置から、第１のＩＤを特定するための情報、第２のＩＤを特定するための情報、および、第３のＩＤを、それぞれ受信した場合、その情報から、第１の管理ステップの処理で管理された第１のＩＤと、第２の管理ステップの処理で管理された第２のＩＤを、それぞれ特定する特定ステップと、特定ステップの処理で特定された第２のＩＤに対応する第２の装置への、第３のＩＤで識別されるコンテンツの配信を制御する配信制御ステップとを含むことを特徴する。
【００２１】
本発明の記録媒体のプログラムは、第１の装置を識別するための第１のＩＤを管理する第１の管理ステップと、第２の装置を識別するための第２のＩＤを管理する第２の管理ステップと、コンテンツを識別するための第３のＩＤを管理する第３の管理ステップと、第１の装置から、コンテンツの配信の要求があった場合、第３の管理ステップの処理で管理されている第３のＩＤを、第１の装置に供給する供給ステップと、第１の装置から、第１のＩＤを特定するための情報、第２のＩＤを特定するための情報、および、第３のＩＤを、それぞれ受信した場合、その情報から、第１の管理ステップの処理で管理された第１のＩＤと、第２の管理ステップの処理で管理された第２のＩＤを、それぞれ特定する特定ステップと、特定ステップの処理で特定された第２のＩＤに対応する第２の装置への、第３のＩＤで識別されるコンテンツの配信を制御する配信制御ステップとを含むことを特徴とする。
【００２２】
本発明のプログラムは、第１の装置を識別するための第１のＩＤを管理する第１の管理ステップと、第２の装置を識別するための第２のＩＤを管理する第２の管理ステップと、コンテンツを識別するための第３のＩＤを管理する第３の管理ステップと、第１の装置から、コンテンツの配信の要求があった場合、第３の管理ステップの処理で管理されている第３のＩＤを、第１の装置に供給する供給ステップと、第１の装置から、第１のＩＤを特定するための情報、第２のＩＤを特定するための情報、および、第３のＩＤを、それぞれ受信した場合、その情報から、第１の管理ステップの処理で管理された第１のＩＤと、第２の管理ステップの処理で管理された第２のＩＤを、それぞれ特定する特定ステップと、特定ステップの処理で特定された第２のＩＤに対応する第２の装置への、第３のＩＤで識別されるコンテンツの配信を制御する配信制御ステップとをコンピュータに実行させることを特徴とする。
【００２３】
本発明においては、コンテンツデータの送信先の装置を決定するためのＩＤが管理され、コンテンツを識別するためのＩＤが管理され、第１の装置から、コンテンツの配信の要求があった場合、管理されているコンテンツを識別するためのＩＤが、その第１の装置に供給される。そして、第１の装置からの情報を受信した場合、その情報から、コンテンツデータの送信先、コンテンツデータの購入にかかる料金の請求先が決定される。
【００２４】
【発明の実施の形態】
以下に、本発明の実施の形態について図面を参照して説明する。図１は本発明を適用した情報処理装置を含む情報処理システムの一実施の形態の構成を示す図である。ネットワーク１は、インターネットやＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）から構成されるネットワークである。ネットワーク１には、サービスプロバイダ２が接続されている。
【００２５】
サービスプロバイダ２は、ここでは、コンテンツデータをユーザ側の装置に提供するサービスを行うプロバイダであるとする。
【００２６】
ユーザＡは、ネットワーク１に接続できる装置として、ＳＴＢ（Ｓｅｔ  Ｔｏｐ  Ｂｏｘ）１１、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）１２、および、携帯電話機１３を所有している。同様に、ユーザＢは、ネットワーク１に接続できる装置として、ＳＴＢ２１、ＰＣ２２、および、携帯電話機２３を所有している。ＳＴＢ１１，２１とＰＣ１２，２２は、ユーザＡ、ユーザＢのそれぞれの家に設置された状態で、ネットワーク１と接続され、携帯電話機１３，２３は、ユーザＡ、ユーザＢの家以外の場所でもネットワーク１に接続されるように構成されている。
【００２７】
ユーザＡおよびユーザＢが所有するＳＴＢ１１とＳＴＢ２１、ＰＣ１２とＰＣ２２、および、携帯電話機１３と携帯電話機２３は、それぞれ基本的な構成や機能は同様であるとし、以下の説明においてこれらの装置に係わる説明を行う場合、特に必要がなければ、ＳＴＢ１１、ＰＣ１２、および携帯電話機１３を例に挙げて説明し、ＳＴＢ２１、ＰＣ２２、および携帯電話機２３に関する説明は同様であるとして省略する。
【００２８】
図２は、サービスプロバイダ２の構成例を示すブロック図である。サービスプロバイダ２は、コンピュータなどから構成される。サービスプロバイダ２のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）４１は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）４２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）４３には、ＣＰＵ４１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。入出力インタフェース４５は、キーボードやマウスから構成される入力部４６が接続され、入力部４６に入力された信号をＣＰＵ４１に出力する。また、入出力インタフェース４５には、ディスプレイやスピーカなどから構成される出力部４７も接続されている。
【００２９】
さらに、入出力インタフェース４５には、ハードディスクなどから構成される記憶部４８、および、インターネットなどから構成されるネットワーク１を介して他の装置（例えば、ＳＴＢ１１）とデータの授受を行う通信部４９も接続されている。ドライブ５０は、磁気ディスク６１、光ディスク６２、光磁気ディスク６３、半導体メモリ６４などの記録媒体からデータを読み出したり、データを書き込んだりするときに用いられる。
【００３０】
図３は、ＳＴＢ１１の内部構成例を示す図である。ＣＰＵ８１は、ＲＯＭ８２に格納されている制御プログラムをＲＡＭ８３に展開し、赤外線受光部８４から供給されたユーザからの指示に基づいて、ＳＴＢ１１の全体の動作を制御する。
【００３１】
例えば、ＣＰＵ８１は、ＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ）を図示されていないが、ＳＴＢ１１に接続されているモニタに表示することがユーザから指示された場合、デマルチプレクサ８７から供給されてきたＥＰＧデータに基づく画面をモニタ上に表示させるための処理を実行する。
【００３２】
赤外線受光部８４は、図示されていないＳＴＢ１１用のリモートコントローラから投光された赤外線を受光し、ユーザからの指示に対応するコマンドをＣＰＵ８１に出力する。
【００３３】
記憶部８５は、録画予約や視聴予約が設定された番組の情報や、他の装置（この場合、サービスプロバイダ２）から供給されたＩＤなどの情報を記憶する。通信部８６は、ＣＰＵ８１からの指示に基づいて、所定のチャンネルの信号を抽出し、その信号に対してアナログディジタル変換処理、ＱＰＳＫ（Ｑｕａｄｒａｔｕｒｅ  Ｐｈａｓｅ  Ｓｈｉｆｔ  Ｋｅｙｉｎｇ）復調処理、あるいは誤り訂正処理などを施し、取得したトランスポートストリームを後段のデマルチプレクサ８７に出力する。
【００３４】
また、通信部８６は、ネットワーク１を介してサービスプロバイダ２とデータの授受を行い、その授受したデータに対する処理も行う。
【００３５】
デマルチプレクサ８７は、供給されてきたトランスポートストリームをバッファメモリ８８に一時的に保存し、例えば、図示せぬＩＣカードから供給されるデスクランブル鍵を用いて、デスクランブルを施す。そして、デマルチプレクサ８７は、デスクランブルが施されたデータから、ＣＰＵ８１により指示された番組のビデオデータを構成するパケットを、その識別子に基づいて抽出し、抽出したパケットをビデオデコーダ８９に出力する。また、デマルチプレクサ８７は、番組の音声データが格納されているパケットを抽出し、それをオーディオデコーダ９０に出力する。
【００３６】
ビデオデコーダ８９は、供給されたパケットを、例えば、ＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）２方式に基づいて再生し、再生した映像信号を図示せぬモニタに供給して表示させる。オーディオデコーダ９０は、供給されてきたパケットを同様に再生し、再生した音声信号を図示せぬスピーカに供給して出力させる。
【００３７】
図４は、ＰＣ１２の内部構成例を示すブロック図である。ＰＣ１２のＣＰＵ１０１は、ＲＯＭ１０２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ１０３には、ＣＰＵ１０１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。入出力インタフェース１０５は、キーボードやマウスから構成される入力部１０６が接続され、入力部１０６に入力された信号をＣＰＵ１０１に出力する。また、入出力インタフェース１０５には、ディスプレイやスピーカなどから構成される出力部１０７も接続されている。
【００３８】
さらに、入出力インタフェース１０５には、ハードディスクなどから構成される記憶部１０８、および、インターネットなどから構成されるネットワーク１を介して他の装置（例えば、サービスプロバイダ２）とデータの授受を行う通信部１０９も接続されている。ドライブ１２０は、磁気ディスクなどの記録媒体からデータを読み出したり、データを書き込んだりするときに用いられる。
【００３９】
図５は、携帯電話機１３の外観構成例を示す図である。図５に示すように携帯電話機１３は、中央のヒンジ部１２１を境に表示部１２２と本体１２３とに分けられており、当該ヒンジ部１２１を介して折り畳み可能に形成されている。
【００４０】
表示部１２２には、上端左部に送受信用のアンテナ１２４が引出し及び収納可能な状態に取り付けられており、当該アンテナ１２４を介してネットワーク１との接続を制御する基地局との間で電波を送受信する。また表示部１２２には、上端中央部にほぼ１８０度の角度範囲で回動自在なカメラ部１２５が設けられており、当該カメラ部１２５のＣＣＤカメラ１２６によって所望の撮像対象を撮像することができるように構成されている。
【００４１】
カメラ部１２５が回動されると、ＣＣＤカメラ１２６の代わりにスピーカ（不図示）が表れ、ユーザは、そのスピーカから通話音を聞くことが可能に構成されている。
【００４２】
さらに表示部１２２には、その正面に液晶ディスプレイ１２７が設けられており、電波の受信状態、電池残量、電話帳として登録されている相手先名や電話番号及び発信履歴等の他、電子メールの内容、簡易ホームページ、カメラ部１２５のＣＣＤカメラ１２６で撮像した画像などを表示する。
【００４３】
一方、本体１２３には、その表面に「０」乃至「９」の数字キー、発呼キー、リダイヤルキー、終話及び電源キー、クリアキー及び電子メールキー等の操作キー１２８が設けられており、当該操作キー１２８を用いて各種指示を入力することができるように構成されている。
【００４４】
また本体１２３には、マイクロフォン１２９が設けられており、そのマイクロフォン１２９によって通話時のユーザの音声を集音する。本体１２３には、操作キー１２８の上部に回動自在なジョグダイヤル１３０が当該本体１２３の表面から僅かに突出した状態で設け等られており、当該ジョグダイヤル１３０に対する回動操作に応じて液晶ディスプレイ１２７に表示されている電話帳リストや電子メールのスクロール動作、簡易ホームページのページ捲り動作及び画像の送り動作等の種々の動作を実行する。
【００４５】
本体１２３には、当該本体１２３の左側面上部に抜差自在なメモリスティック（ソニー株式会社の商標）１４０を挿着するためのメモリスティックスロット１３１が設けられており、ユーザの操作に応じて電子メール、簡易ホームページ、ＣＣＤカメラ１２６で撮像した画像を記録し得るように構成されている。
【００４６】
また携帯電話機１３は、メモリスティック１４０を挿着可能に構成されているために、当該メモリスティック１４０を介して他の電子機器との間でデータの共有化を図ることができる。
【００４７】
図６に示すように、携帯電話機１３は、表示部１２２及び本体１２３の各部を統括的に制御する主制御部１６０に対して、電源回路部１６１、操作入力制御部１６２、画像エンコーダ１６３、カメラインターフェース部１６４、ＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）制御部１６５、画像デコーダ１６６、多重分離部１６７、記録再生部１６８、変復調回路部１６９、及び、音声コーデック１７０がメインバス１７１を介して互いに接続されると共に、画像エンコーダ１６３、画像デコーダ１６６、多重分離部１６７、変復調回路部１６９及び音声コーデック１７０が同期バス１７２を介して互いに接続されて構成されている。
【００４８】
電源回路部１６１は、ユーザの操作により終話及び電源キーがオン状態にされると、バッテリパックから各部に対して電力を供給することにより携帯電話機１３を動作可能な状態に起動する。
【００４９】
携帯電話機１３は、ＣＰＵ、ＲＯＭ及びＲＡＭ等でなる主制御部１６０の制御に基づいて、音声通話モード時にマイクロフォン１２９で集音した音声信号を音声コーデック１７０によってディジタル音声データに変換し、これを変復調回路部１６９でスペクトラム拡散処理し、送受信回路部１７３でディジタルアナログ変換処理及び周波数変換処理を施した後にアンテナ１２４を介して送信する。
【００５０】
また携帯電話機１３は、音声通話モード時にアンテナ１２４で受信した受信信号を増幅して周波数変換処理及びアナログディジタル変換処理を施し、変復調回路部１６９でスペクトラム逆拡散処理し、音声コーデック１７０によってアナログ音声信号に変換した後、これをスピーカ１７４を介して出力する。
【００５１】
携帯電話機１３は、データ通信モード時に例えば簡易ホームページ等にリンクされた動画像ファイルのデータを受信する場合、アンテナ１２４を介して基地局から受信した受信信号を変復調回路部１６９でスペクトラム逆拡散処理し、その結果得られる多重化データを多重分離部１６７に送出する。
【００５２】
多重分離部１６７は、多重化データを分離することにより符号化画像データと音声データとに分け、同期バス１７２を介して当該符号化画像データを画像デコーダ１６６に供給すると共に当該音声データを音声コーデック１７０に供給する。
【００５３】
画像デコーダ１６６は、符号化画像データをＭＰＥＧ（Ｍｏｖｉｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ  ）２やＭＰＥＧ４等の所定の符号化方式に対応した復号化方式でデコードすることにより再生動画像データを生成し、これをＬＣＤ制御部１６５を介して液晶ディスプレイ１２７に供給し、これにより、例えば、簡易ホームページにリンクされた動画像ファイルに含まれる動画データが表示される。
【００５４】
このとき同時に音声コーデック１７０は、音声データをアナログ音声信号に変換した後、これをスピーカ１７４に供給し、これにより、例えば、簡易ホームページにリンクされた動画像ファイルに含まる音声データが再生される。
【００５５】
携帯電話機１３は、受信した簡易ホームページ等にリンクされたデータをユーザの操作により記録再生部１６８を介してメモリスティック１４０に記録することが可能である。
【００５６】
上述したような構成を有する各装置において、本実施の形態を実現するための機能について、以下に説明する。図７は、サービスプロバイダ２が、後述する処理を実施するために必要となる機能を示したサービスプロバイダ２の機能ブロック図である。
【００５７】
サービスプロバイダ２のコンテンツ送信予約部２０１は、ユーザからのコンテンツの送信に関する予約や購入の要求を受け付ける。コンテンツデータベース２０２は、コンテンツ自体のデータ（以下、適宜、コンテンツデータと称する）と、そのコンテンツデータに関するデータ、例えば、コンテンツデータのサイズや、有効期限などのデータ（以下、適宜、コンテンツ付随データと称する）を、それぞれ関連付けて記憶している。
【００５８】
送信先データベース２０３は、コンテンツデータの購入などに関する事前の契約を交わしているユーザに関する情報（以下、適宜、ユーザ情報と称する）が記憶されている。コンテンツ送信予約部２０１は、ユーザからのコンテンツの送信に関する予約や購入の要求を受けた際、コンテンツデータベース２０２に記憶されているコンテンツ付随データと、送信先データベース２０３に記憶されているユーザ情報を参照して、その要求を受け付けるか否かの判断を行う。その結果、受け付けると判断した場合、所定の情報を、スケジュール作成部２０４に出力する。
【００５９】
コンテンツ送信予約部２０１は、ユーザＡ（図１）などからの所定のコンテンツの送信予約や購入など要求を受け付けるサイト（ネットワーク１上で閲覧することができるホームページ）に関するデータも管理しており、そのようなデータをアクセスしてきたユーザに提供し、ユーザは、そのデータに基づく画面を参照して予約や購入などを要求することができるようになっている。
【００６０】
スケジュール作成部２０４は、ユーザから要求があったコンテンツに対するコンテンツデータを、どのタイミングでユーザ側に提供するかなどの送信スケジュールを作成する。この作成されたスケジュールに基づいて、コンテンツ送信部１０５は、コンテンツデータベース２０２からコンテンツデータを読み出し、ユーザ側の装置に対して送信する。
【００６１】
ライセンス発行部２０６は、ユーザに提供するコンテンツデータに、そのコンテンツデータが不正に再生されることを防ぎつつ、ユーザ側で正常に再生できるようにするためのライセンス（利用権利）のデータを発行し、付加する。通信制御部２０７は、サービスプロバイダ２内のネットワーク１を介したデータの授受を制御する。
【００６２】
図２に示したサービスプロバイダ２と図７に示したサービスプロバイダ２との対応関係について説明するに、コンテンツデータ２０２と送信先データベース２０３は、それぞれ、記憶部４８内に設けられているデータベースである。また、コンテンツ送信予約部２０１が管理するサイトに関するデータを記憶する部分は、記憶部４８に設けられているようにしても良い。
【００６３】
コンテンツ送信予約部２０１、スケジュール作成部２０４、コンテンツ送信部２０５、および、ライセンス発行部２０６は、それぞれ、ＲＯＭ４２や記憶部４８に記憶されているプログラムが起動され、その起動されたプログラムに従ってＣＰＵ４１が処理を実行することにより実現される機能である。よって、必要に応じ、プログラムやデータなどは、ＲＡＭ４３に展開され、記憶される。
【００６４】
通信制御部２０７は、通信部４９により行われるデータの授受を制御するための機能である。
【００６５】
このような機能を有するサービスプロバイダ２とデータの授受を行うＳＴＢ１１の機能について説明する。図８は、ＳＴＢ１１の機能のうち、サービスプロバイダ２とのデータの授受や、後述する処理を行うのに必要な機能を示した機能ブロック図である。通信制御部２２１は、ネットワーク１を介してサービスプロバイダ２とのデータの授受を制御する。通信制御部２２１により制御されたデータは、送信制御部２２２に供給される。
【００６６】
送信制御部２２２は、サービスプロバイダ２とのコンテンツデータや送信スケジュールに関するデータなどの授受にかかる制御を行う。記憶部２２３は、送信制御部２２２から供給されたコンテンツデータなどを記憶する。ライセンス管理部２２４は、送信制御部２２２からの供給されたライセンスデータを記憶すると共に、その記憶したライセンスデータに基づき、記憶部２２３におけるコンテンツデータの記憶や、再生部２２６におけるコンテンツデータの再生を管理する。
【００６７】
機器ＩＤ管理部２２５は、ＳＴＢ１１を識別するための情報として、サービスプロバイダ２から供給された機器ＩＤを管理する。
【００６８】
ここで、図３に示したＳＴＢ１１と図８に示したＳＴＢ１１との対応関係について説明するに、通信制御部２２１は、通信部８６における通信の制御を機能である。記憶部２２３、ライセンス管理部２２４のライセンスデータを記憶する部分、および、機器ＩＤ管理部２２５の機器ＩＤを記憶する部分は、それぞれ、記憶部８５に設けられている。
【００６９】
送信制御部２２２、ライセンス管理部２２４、および、機器ＩＤ管理部２２５は、それぞれ、ＲＯＭ８２や記憶部８５に記憶されているプログラムが起動され、その起動されたプログラムに従ってＣＰＵ８１が処理を実行することにより実現される機能である。よって、必要に応じ、プログラムやデータなどは、ＲＡＭ８３に展開され、記憶される。
【００７０】
再生部２２６は、デマルチプレクサ８７、ビデオデコーダ８９、オーディオデコーダ９０など、再生に係わる部分により実行される機能である。
【００７１】
次に、サービスプロバイダ２とＳＴＢ１１が行うデータの授受について説明する。ＳＴＢ１１がサービスプロバイダ２からのコンテンツデータをダウンロードするには、前提として、ＳＴＢ１１（ユーザＡ）が、サービスプロバイダ２（サービスプロバイダ２を管理している会社）と契約している必要がある。ここでは、契約が行われることにより、サービスプロバイダ２からＳＴＢ１１を識別するための機器ＩＤが与えられ、機器ＩＤが与えられることにより、サービスプロバイダ２にＳＴＢ１１が登録されるとして説明する。
【００７２】
図９のフローチャートを参照して、ＳＴＢ１１をサービスプロバイダ２に登録させる際の処理について説明する。ステップＳ１１において、ＳＴＢ１１は、サービスプロバイダ２にアクセスする。このアクセスは、ユーザＡが、ＳＴＢ１１に対して所定の操作を行うことにより、ネットワーク１を介して行われる。
【００７３】
サービスプロバイダ２は、ステップＳ２１において、ＳＴＢ１１からのアクセスの要求を受信すると、ステップＳ２２において、登録フォームに関するデータを送信する。なお、登録フォームに関するデータを送信する前に、アクセスを要求してきたＳＴＢ１１は、既に登録されているか否かなどの判断を行う処理を設けるようにし、既に登録されているＳＴＢ１１に対して登録フォームのデータを送信しないようにしても良い。ここでは、登録の処理を説明するため、登録フォームのデータが送信されるとして説明する。
【００７４】
ステップＳ２２における処理は、コンテンツ送信予約部２０１（図７）において行われる。すなわち、ＳＴＢ１１からのアクセスの要求、この場合、結果として登録の要求になるわけだが、その要求は、サービスプロバイダ２の通信制御部２０７の制御のもと、コンテンツ送信予約部２０１に供給される。コンテンツ送信予約部２０１は、アクセスの要求があったときの常に提供する初期画面として、または、登録時の専用の初期画面として、その初期画面のデータを管理しており、その管理しているデータを、登録フォームのデータとして送信する。
【００７５】
ステップＳ１２において、サービスプロバイダ２から送信された初期画面のデータは、ＳＴＢ１１において受信される。ＳＴＢ１１の通信制御２２１の制御のもと受信された初期画面のデータは、送信制御部２２２に供給される。送信制御部２２２は、供給された（送信された）データが、初期画面に関するデータであると判断すると、再生部２２６に、そのデータを供給する。
【００７６】
再生部２２６は、供給されたデータを再生する。その結果、ＳＴＢ１１に接続されている、例えばテレビジョン受像機の画面上には、図１０に示すような画面が表示される。図１０に示しのは、登録用の初期画面であり、その画面には、ユーザＩＤを入力するためのユーザＩＤ入力欄２５１、パスワード入力するためのパスワード入力欄２５２、および、メールアドレスを入力するためのメールアドレス入力欄２５３が設けられている。
【００７７】
ユーザＩＤは、ユーザが任意に付けることが可能なＩＤであり、アルファベット、数字、仮名文字などから構成される所定の桁数の文字列である。パスワードも同様に、ユーザが任意に付けることが可能な、所定の桁数の文字列である。メールアドレスは、ＳＴＢ１１が電子メールなどと称されるメールを送受信する機能を有し、そのＳＴＢ１１にアドレスが割り当てられている時には、そのアドレスでも良い。
【００７８】
しかしながら、後述する処理を実行するうえでは、このメールアドレス入力欄２５３に入力されるメールアドレスは、ＳＴＢ１１以外の装置、例えば、ＰＣ１２または携帯電話機１３に割り当てられているメールアドレスの方が良い。従って、図１０に示したように、メールアドレス入力欄２５３の上の項目は“メールアドレス”ではなく、“ＰＣまたは携帯電話機のメールアドレス”などと、具体的に記述するようにしても良い。
【００７９】
ここでは、このようなユーザＩＤ、パスワード、およびメールアドレスを入力するようになっているが、これらの情報以外の情報が入力される、または、これらの情報以外の情報も入力されるようにしても良い。このような画面で入力される情報は、ＳＴＢ１１を一意に区別することができる情報であれば良く、ここでは、ユーザＩＤでユーザＡのＳＴＢ１１を、他のＳＴＢ（例えば、ＳＴＢ２１（図１））と区別が付くようにされている。
【００８０】
ユーザＩＤでＳＴＢ１１が一意に区別されるようにしているので、ユーザＩＤとして、メールアドレスが用いられるようにしても良い。すなわち、メールアドレスでＳＴＢ１１が一意に区別されるようにしても良い。ユーザＩＤをメールアドレスとした場合、図１０に示したテレビジョン受像機２４１上の画面において、ユーザＩＤ入力欄２５１とメールアドレス入力欄２５３を別々に設ける必要はなく、どちらか一方のみが設けられるようにすればよい。
【００８１】
また、図１０に示すような画面がユーザ側のテレビジョン受像機２４１上に表示されるとしたが、このような画面がテレビジョン受像機２４１上に表示されるタイミングとしては、サービスプロバイダ２が提供する初期画面内の１つの選択項目として、“登録”といった項目が設けられ、その“登録”といった項目が選択された際に表示されるようにしても良い。このようにした場合においても、基本的に上述したようなＳＴＢ１１とサービスプロバイダ２との間で、画面に関するデータの授受が行われることにより行われる。
【００８２】
ここでは、図１０に示したような画面が、ユーザ側のテレビジョン受像機２４１上に表示され、ユーザが、ユーザＩＤ、パスワード、メールアドレスを、それぞれ入力するとして以下の説明を行う。
【００８３】
図９のフローチャートの説明に戻り、ステップＳ１３において、図１０に示したような画面に対してユーザが、所望の文字列を入力すると、そのデータは、サービスプロバイダ２に対して送信される。ユーザＩＤなどに係わるデータを、ステップＳ２３において受信したサービスプロバイダ２は、ステップＳ２４において、受信したデータに基づく、ユーザＩＤ、パスワード、および、メールアドレスを記憶する。
【００８４】
ここで、ステップＳ２４において行われる記憶の処理について説明する。ＳＴＢ１１からのユーザＩＤなどに係わるデータは、サービスプロバイダ２の通信制御部２０７により受信され、コンテンツ送信予約部２０１に供給される。上述したように、コンテンツ送信予約部２０１は、処理の１つのとして、登録に関する処理も行う。
【００８５】
コンテンツ送信予約部２０１は、通信制御部２０７から供給されたデータが、新たに登録を要求してきたＳＴＢ１１（ユーザ）からのデータであると判断すると、そのデータを、送信先データベース２０３に書き込む（記憶させる）。図１１は、送信先データベース２０３のデータの構成例を示す図である。図１１に示すように、送信先データベース２０３には、機器ＩＤ、ユーザＩＤ、パスワード、および、メールアドレスが、それぞれ関連付けられて管理されている。ここでは、送信先データベース２０３に記憶されている、図１１に示したようなデータを、適宜、送信先テーブルと記述する。
【００８６】
機器ＩＤは、予め送信先テーブルに記述されている。図１１に示した送信先テーブルにおいては、０００００１乃至９９９９９９が、機器ＩＤとして、予め記述（用意）されている。なお、ここでは、予め送信先テーブルに機器ＩＤが記憶されているとして説明するが、このような登録が行われる際に、生成され、その生成された機器ＩＤが用いられるようにしても良い。
【００８７】
このような送信先テーブルに、ステップＳ２３において受信されたユーザＩＤ、パスワード、およびメールアドレスが、それぞれ、対応する部分に書き込まれる。ここでは、ユーザＩＤとして“アイウ”、パスワードとして“××××”、および、メールアドレスとして“△△△＠ｚ．ｃｏ．ｊｐ”が受信され、機器ＩＤ“０００００１”の欄に書き込まれたとする。
【００８８】
このような送信先データベース２０３への書き込み（記憶）がステップＳ２４において行われ、その処理が終了すると、ステップＳ２５において機器ＩＤの送信が行われる。ステップＳ２５においてサービスプロバイダ２から送信される機器ＩＤは、書き込みが行われた欄に対応する機器ＩＤである。すなわち、この場合、機器ＩＤとしては、“０００００１”が読み出され、ＳＴＢ１１に対して送信される。
【００８９】
サービスプロバイダ２側では、このような機器ＩＤの送信を終了すると、ＳＴＢ１１の登録に関する処理を終了したことになるので、そのことをＳＴＢ１１のユーザに対して知らせるために、ステップＳ２６において、登録の完了の通知が行われる。
【００９０】
この登録の完了の通知であるが、単に、“登録を完了しました”といったメッセージが、ＳＴＢ１１に接続されているテレビジョン受像機２４１の画面に表示されるようにしても良いし、他のメッセージや画像が表示されるようにしても良い。
【００９１】
また、例えば、登録を要求されたユーザＩＤが、既に送信先データベース２０３に記憶されている場合、ユーザＩＤを変更するように指示するメッセージが、ユーザＩＤが変更された後に、登録が完了するということをユーザに認識させるようなメッセージと共に送信されるようにしても良い。
【００９２】
ここで、同一のユーザＩＤが、送信先テーブルに存在しないようにするのは、上述したように、ユーザＩＤで、一意にＳＴＢ１１を区別するようにしているためである。従って、同一のユーザＩＤが存在すると、一意にＳＴＢ１１を区別することができないため、そのようなことがないような処理が行われる必要がある。
【００９３】
一方、ＳＴＢ１１においては、ステップＳ１４において、サービスプロバイダ２からの機器ＩＤを受信し、ステップＳ１５において、完了通知を受信する。ステップＳ１４において受信された機器ＩＤは、ステップＳ１６において、ＳＴＢ１１の機器ＩＤ管理部２２５（図８）に記憶される。ステップＳ１５において受信された完了通知に基づいて、登録の処理が終了される、ユーザＩＤを変更するなどの処理が実行される。仮に、ユーザＩＤの変更が実行される際には、そのユーザＩＤの変更がサービスプロバイダ２において許可された場合のみ、ステップＳ１６における機器ＩＤの記憶が行われる。
【００９４】
ところで、ＳＴＢ１１において、図１０に示したような画面に設けられている、それぞれの欄に文字列が入力される際、その文字列の入力の処理は、ＳＴＢ１１に対して指示を出すためのリモートコントローラ（不図示）により行われるが、そのリモートコントローラは、通常、文字入力を行うのに適した構成とされていない。また、ＳＴＢ１１自体が、文字列を入力する機能を有しない可能性もある。
【００９５】
そこで、上述したように、ＳＴＢ１１において登録の処理を行うよりも、文字列の入力に適した構成とされている他の装置で、ＳＴＢ１１をサービスプロバイダ２に登録するための処理を行えるようにした方が、ユーザにとって簡便に登録の処理が行えると考えられる。そこで、ここでは、文字入力に適した構成の装置としてＰＣ１２を用いた場合を例に挙げ、ＳＴＢ１１を、サービスプロバイダ２に登録するための処理について、図１２のフローチャートを参照して説明する。
【００９６】
ステップＳ４１において、ＳＴＢ１１は、サービスプロバイダ２にアクセスする。サービスプロバイダ２は、ステップＳ６１において、ＳＴＢ１１からのアクセスの要求を受信する。このようなＳＴＢ１１とサービスプロバイダ２との接続に係わる処理は、図９に示したステップＳ１１とステップＳ２１の処理と同様に行われる。
【００９７】
ステップＳ６２において、サービスプロバイダ２は、ＳＴＢ１１に対して機器ＩＤとエイリアス（ａｌｉａｓ）ＩＤを送信する。機器ＩＤは、ユーザには提供されないＩＤであり、ユーザは、機器ＩＤを知得することができないものとされている。これに対し、エイリアスＩＤは、ユーザに提供されるＩＤであり、ユーザが知得できるＩＤとされている。
【００９８】
この機器ＩＤとエイリアスＩＤは、ここでは、サービスプロバイダ２から供給されるものとして説明する。機器ＩＤとエイリアスＩＤは、サービスプロバイダ２側で関連付けられて予め記憶されている。従って、エイリアスＩＤで機器ＩＤを一意に特定することができるようにされている。
【００９９】
ステップＳ６２において、サービスプロバイダ２から機器ＩＤとエイリアスＩＤが、ＳＴＢ１１に対して送信されると、ＳＴＢ１１は、ステップＳ４２において、その機器ＩＤとエイリアスＩＤを受信する。この受信は、通信制御部２２１の制御のもと行われ、送信制御部２２２に供給される。送信制御部２２２は、ステップＳ４３において、供給された機器ＩＤとエイリアスＩＤを機器ＩＤ管理部２２５に供給し、管理（記憶）させる。
【０１００】
このようにして、機器ＩＤとエイリアスＩＤが、機器ＩＤ管理部２２５に記憶されると、ステップＳ４４において、記憶されているエイリアスＩＤが、ＰＣ１２に対して送信（提供）される。このエイリアスＩＤのＰＣ１２への提供は、直接的でも良いし、間接的でも良い。
【０１０１】
まず、直接的にＳＴＢ１１からＰＣ１２に対してエイリアスＩＤが提供される場合について説明する。例えば、ＳＴＢ１１とＰＣ１２が家庭内ネットワークで接続されているような場合、そのネットワークを介してエイリアスＩＤの送受信が行われる。その送受信が行われるタイミングは、エイリアスＩＤがＳＴＢ１１において記憶されるときや、ＰＣ１２が起動されたときなどが考えられる。また、後述するように、ＰＣ１２がサービスプロバイダ２にアクセスしたとき（接続されたとき）、ＰＣ１２が、家庭内ネットワークを介してＳＴＢ１１から、そのＳＴＢ１１に記憶されているエイリアスＩＤを取得するようにしても良い。
【０１０２】
また、ＳＴＢ１１から電子メールなどで、ＰＣ１１にエイリアスＩＤが送信さるようにしても良い。いずれにしても、ＳＴＢ１１からＰＣ１２に対して、エイリアスＩＤが、直接的に送受信される。
【０１０３】
間接的にＳＴＢ１１からＰＣ１２に対してエイリアスＩＤが提供される場合について説明する。例えば、まず、ＳＴＢ１１において、エイリアスＩＤが記憶されたとき、エイリアスＩＤを記憶したことをユーザに認識させるためのメッセージと、その記憶されたエイリアスＩＤが、接続されているテレビジョン受像機２４１の画面上に表示されるようにする。ユーザは、そのテレビジョン受像機２４１の画面上に表示されたエイリアスＩＤを、紙媒体などに記録する。
【０１０４】
そして、ユーザは、その紙媒体などに記録したエイリアスＩＤを、ＰＣ１２に記憶させる（後述するように、所定の欄に入力する）。この記憶させるタイミングは、例えば、ＰＣ１２がサービスプロバイダ２にアクセスしたとき（接続されたとき）などが考えられる。
【０１０５】
このようなＳＴＢ１１からＰＣ１２に対してエイリアスＩＤが提供される方法が考えられるため、エイリアスＩＤをＰＣ１２が受信するタイミングは、図１２に示したように、ステップＳ５２の処理が行われる前でも良いし、後でも良く、そのようなタイミングは、適宜、エイリアスＩＤの提供の方法に合わせて変更可能である。
【０１０６】
なお、ここでは、ＰＣ１２により処理が行なわれる例を挙げて説明しているため、上述したような方法が考えられるが、携帯電話機１３により処理を行う場合、携帯電話機１３のＣＣＤカメラ１２６（図５）で、テレビジョン受像機２４１上に表示されているエイリアスＩＤを撮像し、その撮像されたエイリアスＩＤが、携帯電話機１３内の処理により認識され、記憶されるようにしても良い。
【０１０７】
また、ＣＣＤカメラ１２６のような撮像装置を有している装置においては、例えば、二次元バーコードなどと称される情報を提示するコードが用いられて、エイリアスＩＤがユーザ側の装置に提供されるようにしても良い。
【０１０８】
ＳＴＢ１１からＰＣ１２（または携帯電話機１３）に対して、どのようなタイミングでエイリアスＩＤが提供されるかに係わらず、ＳＴＢ１１においてエイリアスＩＤが記憶された後の時点で、ＰＣ１２が、ステップＳ５２において、サービスプロバイダ２にアクセスを開始する。サービスプロバイダ２は、上述したように、ネットワーク１上で閲覧することが可能なサイトを管理している。ユーザは、ＰＣ１２を操作し、そのサイトを閲覧できる状態にする。
【０１０９】
このようにして、ＰＣ１２においてサービスプロバイダ２が管理するサイトを閲覧できる状態にされると、サービスプロバイダ２側から、ステップＳ６４において、登録フォームのデータがＰＣ１２に対して送信される。送信された登録フォームのデータは、ステップＳ５３において、ＰＣ１２に受信される。そして、その受信されたデータに基づく登録用の画面が、ＰＣ１２の出力部１０７（図４）としてのディスプレイ上に表示される。
【０１１０】
図１３は、ＰＣ１２のディスプレイ２６１上に表示された登録フォームの一例を示す図である。図１３に示したディスプレイ２６１上に表示された登録フォームは、図１０に示したテレビジョン受像機２４１上に表示された登録フォームに、エイリアスＩＤを入力するためのエイリアスＩＤ入力欄２５４が追加された構成とされている。
【０１１１】
ユーザは、ＰＣ１２の入力部１０６としてのキーボード（不図示）を操作し、図１３に示した登録フォームの各欄に、情報（文字列）を入力する。エイリアスＩＤ入力欄２５４には、既にＳＴＢ１１のエイリアスＩＤが取得されているときには、そのエイリアスＩＤが、ユーザの入力によらず表示されているようにしても良い。
【０１１２】
通常、ＰＣ１２は、入力部１０６として、文字列を入力しやすいキーボードを備えており、登録フォームに必要な文字列を入力するには、ＳＴＢ１１よりも適していると考えられる。従って、ＳＴＢ１１のサービスプロバイダ２への登録の処理を、ＳＴＢ１１とは異なる装置であるＰＣ１２において行えることは、ユーザにとって、登録の処理を簡便に行えるという利点がある。
【０１１３】
図１３に示したような登録画面の所定の欄に、各種情報が入力されると、その情報は、ステップＳ５４において、ＰＣ１２からサービスプロバイダ２に対して送信される。サービスプロバイダ２は、ＰＣ１２からの情報を、ステップＳ６５において受信すると、その受信した情報を、ステップＳ６６において記憶する。そして、情報の記憶が終了されると、ステップＳ６７において、登録完了の通知が、ＰＣ１２に対して送信される。
【０１１４】
ステップＳ５５において、ＰＣ１２側では、サービスプロバイダ２からの登録完了の通知を受信すると、その通知に対応する処理、例えば、ユーザに対して登録の処理が終了したことを認識させるためのメッセージをディスプレイ２６１上に表示させるなどの処理が実行される。
【０１１５】
このような図１２にあるＳＴＢ１１側とＰＣ１２側とサービスプロバイダ２側で行われる処理は、ここでは１回であるとして説明するが、複数回繰り返されるようにしても良い。複数回繰り返されることにより、例えば、１つの端末に、家族毎に異なるユーザＩＤとパスワードを登録させるといったことが可能となる。換言すれば、この場合、ＳＴＢ１１に対して、複数のユーザが登録を行えることになる。
【０１１６】
複数のユーザが１台の装置に対して登録を行う場合、図１２にあるＳＴＢ１１側とＰＣ１２側とサービスプロバイダ２側で行われる処理が複数回、繰り返し行われることにより実現可能である。複数回、処理が繰り返し行われる場合、連続的に行われても良いし、時間間隔があいて行われても良い。ただし、後述するように、エイリアスＩＤが削除（変更）されるようにした場合、その変更がされる前までに処理が行われる必要がある。ただし、エイリアスＩＤを変更しないようにした場合、または、エイリアスＩＤ以外の情報で、ユーザ登録できるようにしたような場合には、そのような限定を解除することができる。
【０１１７】
図１２に示したフローチャートの説明に戻り、サービスプロバイダ２が、ステップＳ６６において行う記憶の処理や、ステップＳ６７において行う登録の完了通知は、図９のステップＳ２４やステップＳ２６で、それぞれ行われる処理と基本的に同様であり、また、ステップＳ６７の処理に対応する処理としてＰＣ１２側で行われる処理は、図９のステップＳ２６の処理に対応する処理としてＳＴＢ１１側で行われる処理と基本的に同様であるのでその詳細な説明は省略する。
【０１１８】
但し、サービスプロバイダ２側でステップＳ６６において行われる記憶の処理は、図９のステップＳ２４において行われる記憶の処理とは異なる処理を含むため、ここでは、その異なる処理について説明を追加する。まず、図１２のフローチャートに基づいて処理が行われる場合の、サービスプロバイダ２の送信先データベース２０３（図７）の送信先テーブルを、図１４に示す。
【０１１９】
図１４に示した送信先データベース２０３の送信先テーブルは、図１１に示した送信先テーブルに、“エイリアスＩＤ”が書き込まれる欄が設けられた構成とされている。上述したように、エイリアスＩＤは、機器ＩＤと関連付けられ、機器ＩＤを一意に特定するために設けられたＩＤである。さらにエイリアスＩＤは、ユーザが知得できる情報として、ユーザに提供されるＩＤである。従って、送信先テーブルにおいて、エイリアスＩＤは、機器ＩＤと予め関連付けられて書き込まれている。
【０１２０】
サービスプロバイダ２は、図１４に示したような送信先テーブルを管理しているわけだが、ステップＳ６２（図１２）の処理で、ＳＴＢ１１側に送信されるのは、この送信先テーブル内の、機器ＩＤとその機器ＩＤに関連付けられているエイリアスＩＤである。すなわち、ＳＴＢ１１には、ＰＣ１２がサービスプロバイダ２にアクセスする前の段階で、機器ＩＤと、エイリアスＩＤの組が提供されている。
【０１２１】
そのような状態のとき、サービスプロバイダ２は、ユーザ側のＰＣ１２から、ユーザＩＤ、パスワード、メールアドレス、および、エイリアスＩＤの情報を受信するわけだが、その受信は、まず、通信制御部２０７により制御され、コンテンツ送信予約部２０１に供給される。
【０１２２】
コンテンツ送信予約部２０１は、供給された情報のうち、エイリアスＩＤを読み出す。そして、コンテンツ送信予約部２０１は、その読み出したエイリアスＩＤが書き込まれている、送信先データベース２０３で管理されている送信先テーブルの欄を、送信先テーブルを参照して決定する。
【０１２３】
コンテンツ送信予約部２０１は、決定した送信先テーブルの欄に、供給されたユーザＩＤ、パスワード、およびメールアドレスを書き込む。このようにして、図１４に示したような送信先テーブルの各欄に、登録を要求してきた各ユーザの情報が書き込まれる。
【０１２４】
このように、エイリアスＩＤというＩＤを設けることにより、機器ＩＤというユーザに知得されては不都合な情報を公開することなく、かつ、登録を要求する装置（この場合、ＳＴＢ１１）以外の装置（この場合、ＰＣ１２）からでも、所定の装置の登録の処理を行うことができるようになる。
【０１２５】
ところで、機器ＩＤというのは、基本的に有限個のＩＤである。しかしながら、図１２のフローチャートを再度参照するに、ステップＳ４３において、機器ＩＤが、ＳＴＢ１１に記憶された後、ユーザは、必ずしも、ＰＣ１２などの装置を用いて、ＳＴＢ１１をサービスプロバイダ２に登録するといった処理を行うとは限らない。換言すれば、ＳＴＢ１１に割り当てた機器ＩＤに対応する、送信先テーブルの欄に、ユーザの情報が書き込まれない状態が、長期間継続される可能性がある。
【０１２６】
このようなことは、有限個の機器ＩＤの中に、無駄な機器ＩＤが存在してしまう可能性があることを示唆している。そこで、ＳＴＢ１１に機器ＩＤが記憶されてから、所定の期間内に、登録の処理が行われなければ、その機器ＩＤを他の装置に割り当ててしまうといった機能を、サービスプロバイダ２側に持たせるようにし、効率的に機器ＩＤを割り当てるようにしても良い。
【０１２７】
そのようにした場合、まず、サービスプロバイダ２側では、登録の処理が行われずに（機器ＩＤとエイリアスＩＤの組を提供したにもかかわらず、対応する欄にユーザＩＤなどの情報が書き込まれることなく）所定の期間が経過したと判断される機器ＩＤを検出する。そして、その検出の結果、所定の期間が経過したと判断された機器ＩＤに関連付けられているエイリアスＩＤを変更する。
【０１２８】
このように、エイリアスＩＤを変更することにより、仮に、所定の期間が過ぎた後に、変更前のエイリアスＩＤを記憶したＳＴＢ１１のユーザにより登録の処理が行われても、その時点でのエイリアスＩＤが異なるため、その登録を許可しないといった処理を実行することが可能となる。また、エイリアスＩＤを変更することにより、他のＳＴＢに、その変更後のエイリアスＩＤを提供することが可能となり、機器ＩＤの有効利用をはかることが可能となる。
【０１２９】
ところで、図１２に示したフローチャートに基づき、ＳＴＢ１１がサービスプロバイダ２に登録された後の時点では、ＳＴＢ１１に割り当てられた機器ＩＤを一意に特定するための情報として、エイリアスＩＤ（情報１とする）と、ユーザＩＤ（情報２とする）の２つの情報が存在することになる。従って、ＳＴＢ１１がサービスプロバイダ２に登録された後の時点では、情報１が用いられて機器ＩＤが特定されても、情報２が用いられて機器ＩＤが特定されても、どちらでも良い。
【０１３０】
このようなことを考慮すると、情報２としてのユーザＩＤで、機器ＩＤを特定するとすれば、情報１としてのエイリアスＩＤを、送信先テーブル（図１４）に記憶しておく（管理しておく）必要はない。そこで、エイリアスＩＤのうち、既に登録の処理が行われ、対応する欄にユーザＩＤなどのユーザ情報が書き込まれているエイリアスＩＤは、削除されるようにしても良い。削除するようにすれば、その削除したエイリアスＩＤを、他の機器ＩＤと関連付けるといった、エイリアスＩＤの再利用を行うことが可能となる。
【０１３１】
基本的に、機器ＩＤは、多くのユーザ（装置）と契約をかわすために、多くのＩＤを用意しておく必要があり、それらの多くのＩＤ内に、同一のＩＤが存在しないようにするためには、桁数が多い文字列が用いられることになる。仮に、機器ＩＤとエイリアスＩＤを１対１で関連付けた場合、エイリアスＩＤも、機器ＩＤと同じ数だけ用意しなくてはならず、機器ＩＤと同じくらいの桁数の文字列で構成されることになる。
【０１３２】
しかしながら、エイリアスＩＤは、ユーザ側に提供されるＩＤであり、必要に応じ、ユーザ自身が、入力などを行わなくてはならない文字列である。ユーザ自身が、エイリアスＩＤを入力するといった状況が発生する可能性があることを考慮すると、そのエイリアスＩＤを構成する文字列の桁数は短い方が好ましい。
【０１３３】
そこで、上述するように、エイリアスＩＤを再利用するようにすれば、予め用意しておく必要があるエイリアスＩＤの数は、機器ＩＤよりも少ない数で良くなり（１対１対応でなくても良くなり）、エイリアスＩＤの数を減らすことが可能となる。エイリアスＩＤの数が少なくても良くなれば、エイリアスＩＤを構成する文字列の桁数を少なくしても、同一のエイリアスＩＤが存在しないように、エイリアスＩＤを割り振ることが可能となる。
【０１３４】
エイリアスＩＤについて、さらに説明する。例えば図１に示すように、ユーザＡが、ＳＴＢ１１、ＰＣ１２、および、携帯電話機１３といった、コンテンツデータを受信可能な複数の装置を所有していることが考えられる。すなわち、１人のユーザが、コンテンツデータを受信させたい複数の装置を所有していることが考えられる。そのような場合、１人のユーザが、上述したような登録の処理を、登録したい装置毎に行う。
【０１３５】
その結果、装置毎に、エイリアスＩＤ、ユーザＩＤ、パスワード、および、メールアドレスを登録する必要がある。なお、上述したように、ユーザＩＤにより、機器ＩＤを一意に特定できるようにした場合、たとえ同一のユーザであっても、同じユーザＩＤを登録することはできない。よって、ユーザは、複数の装置を登録させた場合、複数のユーザＩＤで登録をし、それを覚えなくてはならない。仮に、エイリアスＩＤで機器ＩＤを一意に特定するようにしても、同様に、ユーザは、複数のエイリアスＩＤを覚えなくてはならない。
【０１３６】
このようなことはユーザ側にとって、使い勝手が良いとはいえない。そこで、使い勝手を向上させるために、さらに、以下のような処理を設ける。勿論、以下に説明するような処理は、１人のユーザは、１台の装置しかサービスプロバイダ２に登録できないといったような規則が設けられているような場合には、必要はない処理である。
【０１３７】
上述したように、所定の機器がサービスプロバイダ２に登録された後は、その機器に割り振られていたエイリアスＩＤは、サービスプロバイダ２側で管理する必要はなくなる。そこで、そのエイリアスＩＤを、ユーザ側で変更できるようにすることにより、ユーザ側の使い勝手を向上させるようにする。
【０１３８】
ここでは、前提として、ＳＴＢ１１は、既に、機器ＩＤとエイリアスＩＤを記憶し、ＰＣ１２は、そのＳＴＢ１１に対して割り振られたエイリアスＩＤを記憶（取得）しているとする。この記憶（取得）に係わるまで処理は、例えば、図１２に示したフローチャートの、ＳＴＢ１１とサービスプロバイダ２との間で行われる処理と同様にして行われるため、ここでは、その説明は省略する。
【０１３９】
図１５のフローチャートを参照して、ＰＣ１２でＳＴＢ１１をサービスプロバイダ２に登録する際の処理について説明する。ＰＣ１２側の処理としてのステップＳ８１乃至Ｓ８３の処理と、サービスプロバイダ２側の処理としてのステップＳ９１乃至Ｓ９３の処理は、それぞれ、図１２のフローチャートのステップＳ５２乃至Ｓ５４と、ステップＳ６３乃至Ｓ６５と同様の処理なので、その説明は省略する。
【０１４０】
サービスプロバイダ２は、ステップＳ９３において、ＰＣ１２から、ユーザＩＤ、パスワード、メールアドレス、および、ＳＴＢ１１に、その時点で割り当てられているエイリアスＩＤの情報を受信すると、ステップＳ９４において、ユーザ認証（パスワードの確認）が行われる。ここでは、既に登録されているユーザが、エイリアスＩＤを端末名称に変更するためにアクセスしてきた場合の処理であるので、このような認証が行われる。
【０１４１】
ステップＳ９４において、送信先テーブルに、受信されたユーザＩＤと同一のユーザＩＤが、記憶され、パスワードが一致していると判断された場合、すなわち、ユーザ認証が行われたと判断された場合、ステップＳ９５に進み、変更フォームのデータが読み出される。変更フォームとは、ここでは、エイリアスＩＤを端末名称に変更するためのフォームであり、端末名称とは、ユーザが登録した装置（ここでは、ＳＴＢ１１）に、ユーザが付ける名前である。
【０１４２】
一方、ステップＳ９４において、送信先テーブルに、受信されたユーザＩＤと同一のユーザＩＤはない、または、パスワードが一致しないと判断された場合、すなわち、ユーザ認証ができなかったと判断された場合、ステップＳ９６に進み、再入力フォームのデータが読み出される。この再入力フォームとは、ユーザ認証ができなかったのは、ユーザＩＤまたはパスワードが間違って入力されたためであると判断し、再度、ユーザＩＤとパスワードの入力をユーザ側に求めるためのフォームである。
【０１４３】
ステップＳ９７において、読み出された変更フォームまたは再入力フォームのデータが、ＰＣ１２に対して送信される。そのデータは、ステップＳ８４において、ＰＣ１２に受信される。ＰＣ１２は、受信したデータに基づく画面として、図１６または図１７に示すような画面を、ディスプレイ２６１上に表示させる。図１６に示した画面は、変更フォームのデータに基づく変更用の画面であり、図１７に示した画面は、再入力フォームのデータに基づく再入力用の画面である。
【０１４４】
図１６に示した変更用の画面には、変更前のエイリアスＩＤが表示される欄２８１と、変更後の端末名称が入力される欄２８２が設けられている。図１７に示した再入力用の画面には、ユーザＩＤとパスワードを入力するための欄が、それぞれ設けられている。
【０１４５】
図１６に示した画面で欄２８２に表示されるエイリアスＩＤは、例えば、ステップＳ９７において、サービスプロバイダ２が変更用フォームのデータを送信する際、ステップＳ９３において受信され、記憶されたエイリアスＩＤを添付して送信される。そのようにされることにより、ユーザ側のＰＣ１２のディスプレイ２６１上には、エイリアスＩＤが入力された状態の画面が表示される。
【０１４６】
ユーザは、図１６に示したような画面の欄２８２に、所望の名称を入力する。例えば、この場合ＳＴＢ１１がサービスプロバイダ２に登録される際の処理なので、“ＳＴＢ”といった名称が、欄２８２に入力される。端末名称が入力される欄２８２は、文字が入力されるような欄とし、ユーザが自由な名称を付ける（入力する）ことが可能な状態としても良いし、プルダウンメニュー方式で、ユーザが、そのプルダウンメニュー内から、所望な名称を選択できるような状態としても良い。
【０１４７】
いずれにせよ、図１６に示したような画面で、ユーザが所望の端末名称を入力（選択）すると、また、必要に応じ他の情報も入力すると、その情報は、ステップＳ８４において、ＰＣ１２からサービスプロバイダ２に対して送信される。サービスプロバイダ２は、ステップＳ９８において、ＰＣ１２からの変更に関するデータを受信する。
【０１４８】
なお、図１７に示したような画面で、ユーザが再入力したユーザＩＤとパスワードが入力された場合には、サービスプロバイダ２側では、再度、ステップＳ９４以降の処理が繰り返される。
【０１４９】
サービスプロバイダ２は、ステップＳ９９において、変更の処理を実行し、ステップＳ１００において、その変更したデータを記憶する。この変更、記憶の処理は、受信した変更前のエイリアスＩＤから、送信先テーブルの対応する欄を決定し、その欄のエイリアスＩＤが書き込まれている部分に、変更後の端末名称を新たに書き込むといった処理である。
【０１５０】
なお、ここでは、エイリアスＩＤが、端末名称に書き換えられるとして説明するが、エイリアスＩＤは、そのまま記憶されたままにし、端末名称が追加して記憶されるようにしても良い。また、そのように、エイリアスＩＤを記憶したままにした場合、後述する処理において、エイリアスＩＤを用いるようにしても良い。
【０１５１】
このようにして、サービスプロバイダ２側で、変更後の情報が記憶されると、ステップＳ１０１において、完了通知がＰＣ１２に対して行われる。ステップＳ１０１において行われる処理と、その処理に対応するＰＣ１２側のステップＳ８５における処理は、図１２にステップＳ６７において行われる処理と、その処理に対応するＰＣ１２側のステップＳ５５における処理と同様な処理なので、その説明は省略する。
【０１５２】
このような図１５に示したフローチャートに基づく処理が行われる場合、サービスプロバイダ２の送信先データベース２０３に記憶されている送信先テーブルは、模式的に示すと図１８に示したようになる。図１８に示した送信先テーブルの例では、ユーザＩＤが“アイウ”、パスワードが“××××”、メールアドレスが“△△△＠ｚ．ｃｏ．ｊｐ”のユーザは、端末名称として、“ＳＴＢ”と“ＰＣ”という２つの装置を登録しており、その“ＳＴＢ”という装置に対しては、“０００００１”という機器ＩＤが割り当てられており、その“ＰＣ”という装置に対しては、“０１００２１”という機器ＩＤが割り当てられていることを示している。
【０１５３】
また、ユーザＩＤが“カキク”、パスワードが“○○○○”、メールアドレスが“△×△＠ｘ．ｃｏ．ｊｐ”のユーザは、端末名称として、“パソコン”、“ＳＴＢ”、および、“ケイタイ”という３つの装置を登録しており、その“パソコン”という装置に対しては、“００１２３４”という機器ＩＤが割り当てられており、その“ＳＴＢ”という装置に対しては、“００１２３５”という機器ＩＤが割り当てられており、その“ケイタイ”という装置に対しては、“００１２３６”という機器ＩＤが割り当てられていることを示している。
【０１５４】
このように、１つのユーザＩＤに対して、複数の装置（端末名称）が関連付けられ、それらの装置毎に、機器ＩＤが関連付けらる。このような送信先テーブルが用いられることにより、ユーザ側においては、１人のユーザが、同一のユーザＩＤで、自己の所有する複数の装置の中から、所望の装置に対して、コンテンツデータを受信させる（購入させる）ことが可能となる。以下に、図１８に示したような送信テーブルが用いられる場合を例に挙げて、コンテンツデータの購入に係わる処理について説明する。
【０１５５】
まず、図１９のフローチャートを参照して、機器ＩＤを記憶している装置が、サービスプロバイダ２からコンテンツデータを購入する場合について説明する。ここでは、機器ＩＤを記憶している装置として、ＳＴＢ１１を例に挙げ、ＳＴＢ１１が、サービスプロバイダ２からコンテンツデータを購入する場合について説明する。
【０１５６】
ステップＳ１２１において、ＳＴＢ１１は、サービスプロバイダ２に対してアクセスを開始する。このアクセスの開始は、ユーザの指示により行われる。ステップＳ１３１において、サービスプロバイダ２は、ＳＴＢ１１からのアクセスの要求を受信する。
【０１５７】
サービスプロバイダ２は、ＳＴＢ１１からのアクセスの要求が、コンテンツデータの購入に関する要求であると判断すると、ステップＳ１３２において、コンテンツデータに関する情報を、アクセスを要求してきたＳＴＢ１１に対して送信する。ここで送信されるデータは、コンテンツデータベース２０２で記憶されているコンテンツ付随データである。図２０にコンテンツデータベース２０２に記憶されているコンテンツ付随データの構成例を示す。
【０１５８】
コンテンツ付随データは、コンテンツデータを一意に特定するためにコンテンツデータ毎に割り当てられているコンテンツＩＤ、そのコンテンツデータのサイズ、そのコンテンツデータを購入する際にかかる料金、そのコンテンツデータにより提供されるコンテンツの内容などの情報である。
【０１５９】
ステップＳ１２２において、サービスプロバイダ２からのデータを受信したＳＴＢ１１は、その受信したデータに基づく画面を、接続されているテレビジョン受像機２４１に表示させる。ユーザは、そのテレビジョン受像機２４１上に表示された画面を参照し、購入したいコンテンツデータを決定する。
【０１６０】
ユーザにより、購入したいコンテンツデータが決定されると、その決定されたコンテンツデータに割り当てられているコンテンツＩＤが、機器ＩＤと共にサービスプロバイダ２に対して送信される。機器ＩＤは、ＳＴＢ１１の機器ＩＤ管理部２２５により管理されている機器ＩＤが読み出され、コンテンツＩＤと共に送信される。
【０１６１】
ステップＳ１３３において、サービスプロバイダ２は、ＳＴＢ１１からのデータを受信する。サービスプロバイダ２は、ステップＳ１３４において、受信したデータに含まれる機器ＩＤを抽出する。そして、その機器ＩＤを有する装置が、購入を要求してきたコンテンツデータを購入するための正当の権利を有する装置であるか否かを、抽出した機器ＩＤを元に、送信先データベース２０３に記憶されているデータや、コンテンツデータベース２０２に記憶されているコンテンツ付随データなどを参照して判断する。
【０１６２】
ステップＳ１３４において、コンテンツデータの購入を許可すると判断された場合、ステップＳ１３５に進み、コンテンツデータの購入を許可しないと判断された場合、図１９に示したコンテンツデータの購入に係わる処理は終了される。なお、ステップＳ１３４において、コンテンツデータの購入を許可しないと判断された場合、ユーザに、そのことを認識させるようなメッセージが送信されるようにした方が良い。
【０１６３】
ステップＳ１３５において、コンテンツデータとライセンスデータがＳＴＢ１１に対し送信される。この送信は、スケジュール作成部２０４により作成されるスケジュールに従って行われる。詳細は後述するが、スケジュール作成部２０４は、コンテンツデータをどのようなタイミングでユーザ側に提供するかを判断し、その判断に基づくスケジュールを作成し、そのスケジュールに基づいてコンテンツデータが送信されるように制御を行う。
【０１６４】
またスケジュール作成部２０４は、コンテンツデータを送信するとき、ライセンス発行部２０６に対してライセンスデータを発行するように指示を出す。ライセンスデータとは、不正なコピーや再生を防ぐためのデータなどを含む利用条件に関するデータのことであり、コンテンツデータと共にユーザ側に提供されるデータである。
【０１６５】
ライセンス発行部２０６は、図２１に示したようなデータが記述されたテーブルを記憶している。すなわち、ライセンスＩＤ、そのライセンスＩＤで識別される利用条件、および、その利用条件が適用されるコンテンツＩＤが、それぞれ関連付けられているテーブルである。利用条件としては、購入、レンタル、一回だけコピー可能などの条件を含むものである。
【０１６６】
１つの利用条件には、１つのライセンスＩＤが割り当てられるが、１つのライセンスＩＤには、複数のコンテンツＩＤを関連付けることが可能とされている。これは、同一の利用条件を複数のコンテンツに対して適用できるようにするためである。１つのライセンスＩＤが、複数の利用条件と関連付けられているようにしても良い。すなわち、複数の利用条件の組み合わせで、１つのライセンスデータが生成されるようにし、その１つのライセンスデータに対して、１つのライセンスＩＤを割り当てるようにしても良い。
【０１６７】
このようなデータを用いて、ライセンス発行部２０６は、ライセンスデータを発行する。なお、図２０に示したコンテンツ付随データと図２１に示したライセンスデータは、一例であり、それらのデータ以外のデータも追加して記憶させるようにしても良く、また、後述する処理においても、追加されたデータも用いられて処理が行われるようにしても良い。
【０１６８】
スケジュール作成部２０４は、コンテンツデータベース２０２に記憶されているコンテンツ付随データと、ライセンス発行部２０６に記憶されているデータからスケジュールを作成する。図２２に作成されるスケジュールの一例を示す。
【０１６９】
スケジュールは、コンテンツデータの送信要求があったときに、随時、その要求に対応するスケジュールが作成されるわけだが、その複数のスケジュールを区別するためのトランザクション（Ｔｒａｎｓａｃｔｉｏｎ）ＩＤが、スケジュールの先頭に設けられている。
【０１７０】
ユーザから要求されたコンテンツを識別するためのコンテンツＩＤが、コンテンツデータベース２０２（図２０）から読み出され、トランザクションＩＤと関連付けられる。ライセンスＩＤは、ユーザから要求されたコンテンツに適用される利用条件に対応するＩＤが、ライセンス発行部２０６から読み出され、関連付けられる。送信先機器ＩＤは、ユーザがコンテンツデータの送信先として指定した装置に割り当てられている機器ＩＤであり、必要に応じ、送信先データベース２０３から読み出される。
【０１７１】
課金先ユーザＩＤとは、コンテンツデータの購入により発生する課金を、請求するユーザのＩＤである。送信時刻は、ユーザが指定した場合には、その指定した時刻が基本的に設定される。また、ユーザが指定しなかった場合や、ユーザが指定した時刻には送信が行えない場合には、サービスプロバイダ２側で設定した時刻が設定される。送信状態は、コンテンツデータの送信がまだ行われてない、送信中である、送信が終了したなど、送信状態に係わる情報が書き込まれる。
【０１７２】
このようなスケジュールに基づき、コンテンツデータの送信が行われる。この場合、ＳＴＢ１１からの要求であり、特に後の時点で送信する要求（必要性）がなければ、すぐにその要求に対応しても良いので、スケジュール内の送信時刻は、そのスケジュールが作成された時刻が書き込まれるようにしても良い。
【０１７３】
通信制御部２０７は、スケジュール作成部２０４により作成されたスケジュールに基づき、コンテンツデータとライセンスデータ（利用条件）を、ＳＴＢ１１に送信する。
【０１７４】
ステップＳ１２４において、ＳＴＢ１１は、サービスプロバイダ２からのデータを受信する。ＳＴＢ１１は、ステップＳ１２５において、受信したデータを記憶する。この記憶の処理は、まず、通信制御部２２１の制御のもと受信されたデータが、送信制御部２２２に供給される。送信制御部２２２は、供給されたデータのうち、コンテンツデータを記憶部２２３に供給し、ライセンスデータをライセンス管理部２２４に供給する。
【０１７５】
記憶部２２３とライセンス管理部２２４は、それぞれ、供給されたデータを記憶する。このようにして、ＳＴＢ１１において、コンテンツデータの購入が行われる。なお、課金については説明していないが、このような購入の処理が行われた際には、課金の処理もサービスプロバイダ２側で行われる。なお、以下の説明においても、説明は省略するが、コンテンツデータの購入の処理が行われときには、課金の処理も行われる。
【０１７６】
次に、ＰＣ１２でコンテンツデータの購入の処理を行い、ＳＴＢ１１に購入されたコンテンツデータを記憶させる際の処理について説明する。この場合、購入の処理を行う装置と、購入されたコンテンツデータが記憶される装置とが異なる場合である。図２３のフローチャートを参照して、そのような場合の処理について説明する。なお、図２３に示したフローチャートを参照した説明は、まず、全体の処理についての概略を説明し、その後、各装置における詳細な処理を説明する。
【０１７７】
ＰＣ１２におけるステップＳ１５１乃至Ｓ１５３の処理は、図１９のステップＳ１２１乃至Ｓ１２３においてＳＴＢ１１が行う処理と基本的に同様であり、その処理に対応してサービスプロバイダ２が行うステップＳ１６１乃至Ｓ１６３の処理は、図１９のステップＳ１３１乃至Ｓ１３２においてサービスプロバイダ２が行う処理と基本的に同様であるので、その説明は省略する。
【０１７８】
ただし、ステップＳ１５３において、ＰＣ１２からは、ユーザが購入を決定したコンテンツデータを識別するためのコンテンツＩＤのみが送信され、機器ＩＤは送信されない。これは、機器ＩＤは、ＳＴＢ１１に割り当てられたＩＤであり、ＳＴＢ１１において管理されているＩＤであるため、ＰＣ１２から、そのＳＴＢ１１の機器ＩＤを送信することはできないからである。
【０１７９】
ステップＳ１６３においてＰＣ１２からのデータを受信したサービスプロバイダ２は、ステップＳ１６４において、購入フォームのデータをＰＣ１２に対して送信する。サービスプロバイダ２は、受信したデータ内に、機器ＩＤが含まれていないことにより、機器ＩＤを有しない装置から、コンテンツデータの購入の要求が出されたと判断し、購入後のコンテンツデータの送信先の装置や、そのユーザが契約を交わしている正規のユーザであるか否かを確認するための情報を送信させるために、購入フォームのデータを送信する。
【０１８０】
ステップＳ１５４において、購入フォームのデータを受信したＰＣ１２は、そのデータに基づく購入用の画面を、ディスプレイ２６１上に表示させる。ユーザは、その画面を参照し、必要な項目、例えば、ユーザＩＤとパスワードを入力する。その入力されたユーザＩＤとパスワードのデータは、ステップＳ１５５において、ＰＣ１２からサービスプロバイダ２に送信される。
【０１８１】
サービスプロバイダ２は、ステップＳ１６５において、ＰＣ１２からのデータを受信し、ステップＳ１６６において、その受信したデータを記憶すると共に、そのデータに基づくスケジューリングを行う。詳細は後述するが、図２２示したようなスケジュールを作成するためのスケジューリングなどの処理が実行される際、パスワードによる認証の処理や、コンテンツデータの送信先の装置の確定などの処理なども行われる。ここでは、そのような処理も終了し、ステップＳ１６７に処理が進んだとして説明する。
【０１８２】
ステップＳ１６７において、サービスプロバイダ２は、コンテンツの購入に係わる処理、すなわち、コンテンツの購入の受付が完了したことを、ユーザに通知する。その通知を、ステップＳ１５６において受信したユーザ側のＰＣ１２は、その通知に基づく処理、例えば、“コンテンツの購入の受付の処理は終了しました”といったようなメッセージをディスプレイ２６１上に表示させるという処理を実行する。
【０１８３】
一方、ＳＴＢ１１は、ステップＳ１８１において、サービスプロバイダ２に対して、スケジュールを問い合わせる。ＳＴＢ１１は、自分宛のスケジュール（自分が、コンテンツデータの送信先として指定されているスケジュール）が作成されていないか否かを問い合わせる。このような問い合わせは、例えば、１時間毎に、ＳＴＢ１１からサービスプロバイダ２に対して行われる。ここでは、上述したような処理が実行された結果、ＳＴＢ１１宛のスケジュールが作成された後の時点で、ＳＴＢ１１がサービスプロバイダ２に対して問い合わせを実行し、その問い合わせが、ステップＳ１６８において、サービスプロバイダ２に受信された場合を例に挙げて説明する。
【０１８４】
サービスプロバイダ２は、ＳＴＢ１１からの問い合わせに対して、そのＳＴＢ１１宛のスケジュールが存在していると判断すると、ステップＳ１６９において、ＳＴＢ１１宛のスケジュールを送信する。この判断は、例えば、ＳＴＢ１１が、問い合わせを行うとき、自分の機器ＩＤを送信し、サービスプロバイダ２が、その機器ＩＤに関連付けられているスケジュールが、スケジュール作成部２０４で作成（記憶）されているか否かを判断することにより行われる。
【０１８５】
ステップＳ１６９においてサービスプロバイダ２から送信されたスケジュールは、ステップＳ１８２において、ＳＴＢ１１により受信される。その受信されたスケジュールには、送信予定時刻に関する情報も含まれている。その情報が示す時刻になると、ＳＴＢ１１は、サービスプロバイダ２に対して、コンテンツデータの送信を要求する。その要求は、ステップＳ１７０においてサービスプロバイダ２に受信され、サービスプロバイダ２は、その要求に対応し、ステップＳ１７１において、コンテンツデータの送信を開始する。
【０１８６】
このようなコンテンツデータの送信が開始されると、サービスプロバイダ２は、ステップＳ１７２において、ＰＣ１２に対して、購入されたコンテンツデータのＳＴＢ１１に対する送信が開始されたことを通知する。また、そのコンテンツデータのＳＴＢ１１に対する送信が終了した時点で（ステップＳ１７３）、送信が終了されたことがＰＣ１２に対して通知される。この通知は、例えば、電子メールで行われる。
【０１８７】
一方、ＳＴＢ１１は、ステップＳ１８５において、送信されたコンテンツデータを記憶する。
【０１８８】
このようにして、ＰＣ１２において、コンテンツの購入の処理が行われ、ＳＴＢ１１に、購入されたコンテンツデータが記憶される。
【０１８９】
次に、図２３に示したフローチャートの処理の詳細を、各装置毎に説明する。まずＰＣ１２が行う処理について説明するが、ＰＣ１２の処理は、基本的に、サービスプロバイダ２側からのデータに基づく画面の表示、その画面に対応して入力された情報の送信といった処理の繰り返しであるので、その説明は省略するが、必要に応じ、サービスプロバイダ２の処理とあわせて説明する。
【０１９０】
図２４に示したフローチャートを参照して、サービスプロバイダ２が行う処理のうち、コンテンツの購入に係わる処理（上述した説明において、ＰＣ１２とのやりとりにかかわる処理）について説明する。サービスプロバイダ２は、ステップＳ２０１において、他の装置からのアクセスがあったか否かを判断する。他の装置からのアクセスがあったと判断されるまで、ステップＳ２０１の処理が繰り返され、待機状態が維持される。
【０１９１】
一方、ステップＳ２０１において、他の装置からアクセスがあったと判断された場合、ステップＳ２０２に進み、コンテンツ付随データが、コンテンツデータベース２０２から読み出され、アクセスしてきた他の装置に対して送信される。このようにして、コンテンツ付随データが送信されると、サービスプロバイダ２は、ユーザが購入を所望するコンテンツを決定し、その決定されたコンテンツのコンテンツＩＤを受信するまで、待機状態を維持する。
【０１９２】
サービスプロバイダ２から他の装置（例えば、ＰＣ１２）に送信されるコンテンツ付随データには、コンテンツＩＤが含まれる。そして、ユーザにより購入が決定されたコンテンツに対応するコンテンツＩＤが、少なくともサービスプロバイダ２に送信され、ユーザからの購入の要求として受信されるようになっている。サービスプロバイダ２は、このようなユーザ側からのコンテンツの購入の要求を受信したか否かを、ステップＳ２０３において判断する。
【０１９３】
ステップＳ２０３において、コンテンツの購入の要求を受信したと判断されるまで、待機状態が維持され、受信したと判断されると、ステップＳ２０４に処理が進められる。ステップＳ２０４において、受信されたコンテンツの購入の要求内に、機器ＩＤが含まれるか否かが判断される。
【０１９４】
上述したように、ＳＴＢ１１など、その装置がコンテンツデータの受信装置となる装置（機器ＩＤを取得し、記憶している装置）から、購入の要求が出されるときには、コンテンツＩＤと共に、機器ＩＤも送信されてくるが、ＰＣ１１や携帯電話機１３など、その装置がコンテンツデータの受信装置とならない装置（機器ＩＤを取得していない装置）から、購入の要求が出されるときには、コンテンツＩＤのみが送信されてくる。
【０１９５】
そこで、ステップＳ２０４の処理として、受信された要求（データ）に、機器ＩＤのデータが含まれているか否かの判断を行う。この判断により、コンテンツの購入の要求を出してきた装置が、コンテンツデータを受信することが可能な装置として、既に登録されている装置であるか否かを判断することができる。
【０１９６】
なお、ステップＳ２０４の処理は省略され、必ず、購入フォームが送信されるようにしても良い。これは、例えば、ＰＣ１２が、自身に割り当てられた機器ＩＤを取得し、記憶しているような状況で、そのＰＣ１２でコンテンツデータの購入の処理がされたが、その購入されたコンテンツデータ自体は、ＳＴＢ１１に記憶させたいというユーザの要望に対応するためである。または、他の方法で、ユーザに、購入されたコンテンツデータの送信先を指定させるための処理を含めるようにしても良い。
【０１９７】
ステップＳ２０４において、受信されたデータに機器ＩＤは含まれていないと判断された場合、ステップＳ２０５に進み、購入フォームのデータの送信が行われる。この購入フォームのデータとは、図２５に示すような画面を、ユーザ側の装置、例えば、ＰＣ１２のディスプレイ２６１上に表示させるためのデータである。
【０１９８】
図２５に示したように、購入フォームのデータに基づく画面では、ユーザＩＤを入力するための欄とパスワードを入力するための欄が設けられている。ユーザＩＤとパスワードを入力させるのは、ユーザＩＤにより機器ＩＤを特定し、パスワードによりユーザ認証を行うためである。なお、エイリアスＩＤをサービスプロバイダ２の送信先テーブルに記憶させたままにするようにした場合、そのエイリアスＩＤが送受信されるようにしても良い。
【０１９９】
ユーザ側の装置で、ユーザが、図２５に示したような画面を参照して、ユーザＩＤとパスワードを入力すると、その情報は、サービスプロバイダ２に送信され、サービスプロバイダ２は、その送信されたユーザＩＤとパスワードの情報を、ステップＳ２０６において受信する。サービスプロバイダ２は、ステップＳ２０７において、受信したユーザＩＤから、機器ＩＤを特定する。
【０２００】
サービスプロバイダ２の送信先データベース２０３には、図１８に示したような送信先テーブルが記憶されているわけだが、そのテーブルが参照されて、機器ＩＤが特定される。例えば、受信されたユーザＩＤが“アイウ”であり、パスワードが“××××”である場合、図１８を参照するに、機器ＩＤとして、“０００００１”と“０１００２１”の２つの機器ＩＤが特定される。
【０２０１】
ステップＳ２０８において、特定された機器ＩＤは、複数あるか否かが判断される。上述したような状況では、２つの機器ＩＤが特定されるので、ステップＳ２０８において、特定された機器ＩＤは、複数あると判断され、ステップＳ２０９に処理が進められる。ステップＳ２０９において、送信先決定フォームのデータが送信される。送信先決定フォームのデータとは、どの装置に対してコンテンツデータを受信させ、記憶させるかということをユーザに選択（決定）させるための画面を、ユーザ側の装置で表示されるようにするためのデータである。
【０２０２】
送信先決定フォームのデータとして送信されるデータには、少なくとも、ステップＳ２０７において特定された機器ＩＤに対応する端末名称（図１８）が含まれる。図２６は、ユーザ側の購入の処理が、その時点で行われている装置、例えば、ＰＣ１２のディスプレイ２６１上に表示される画面の一例である。図２６に示した画面は、図１８に示した送信先テーブルに基づいて処理が行われたとすると、機器ＩＤ“０００００１”と“０１００２１に、それぞれ対応する端末名称”ＳＴＢ“と”ＰＣ“が表示されている状態である。また、それぞれの端末名称を選択するためのラジオボタンが、それぞれの名称の前に設けられている。
【０２０３】
このように、コンテンツの購入を要求してきたユーザが、複数の装置を、コンテンツデータの送信先の装置として登録していたような場合、ユーザが付けた端末名称で、その購入したコンテンツのコンテンツデータを記憶させる（ダウンロードさせる）装置を選択できるようにされている。図２６に示したような画面が参照されることにより選択された端末名称の情報は、サービスプロバイダ２に送信される。
【０２０４】
なお、ダウンロード先の装置として、ユーザが１つの装置しか選択できないように設定されていても良いし、複数の装置が選択できるようにように設定されていても良い。そのような設定は、課金の処理に応じて、サービスプロバイダ２側で設定されればよい。
【０２０５】
サービスプロバイダ２側では、その送信されてきたダウンロード先として選択された端末名称の情報を、ステップＳ２１０において受信する。サービスプロバイダ２側では、端末名称の情報を受信することにより、購入されたコンテンツデータの送信先の装置の機器ＩＤを特定することが可能となる。
【０２０６】
ステップＳ２１１において、受信されたデータの記憶と、そのデータに基づくスケジューリングが行われる。スケジューリングとは、購入が要求されたコンテンツにかかわる図２２に示したようなデータ構成のデータが、スケジュール作成部２０４において作成されることである。
【０２０７】
このようなスケジューリングの処理が行われるステップＳ２１１の処理には、ステップＳ２０４において、受信された要求（データ）は機器ＩＤを含むと判断されたとき、または、ステップＳ２０８において、特定された機器ＩＤは、１つであると判断されたときも来る。いずれの場合も、結果として、コンテンツデータの送信先の装置の機器ＩＤが１つに特定されたときに、スケジューリングの処理が実行される。
【０２０８】
スケジューリングの処理が行われる際、コンテンツデータの送信時刻に関する情報を取得する必要がある。そこで、例えば、図２６に示すように、ユーザ側のディスプレイ２６１上に表示される画面において、“送信を希望する時刻を入力してください”といったメッセージを表示させるようにし、そのメッセージの下に、ユーザが所望の時刻を入力できる欄を設けるようにしても良い。そして、その設けられた欄に、時刻が入力された場合、その時刻が、送信予定時刻として書き込まれるようにすれば良い。
【０２０９】
また、このようにした場合において、ユーザが送信時刻を指定しなかったときにはサービスプロバイダ２側で設定し、書き込むようにすればよい。または、ユーザが指定することはできないようにし、サービスプロバイダ２側だけで設定できるようにしても良い。
【０２１０】
スケジューリングの処理が実行される際、コンテンツデータの購入を要求してきたユーザは、サービスプロバイダ２が提供するサービスを受けられるユーザとして正規に登録されているているか否かが判断され、正式に登録されていると判断されたときだけ、スケジューリングの処理が実行される。正規に登録されているユーザであるか否かの判断は、受信されたパスワードが、ユーザＩＤと関連付けられて送信先テーブルに登録されているか否かを判断することにより行われる。
【０２１１】
スケジューリングの処理が終了されると、ステップＳ２１２において、購入受付完了の通知が、ユーザ側の装置に対して行われる。このようにして、サービスプロバイダ２側では、購入にかかわる処理が行われる。
【０２１２】
次に、図２７のフローチャートを参照して、サービスプロバイダ２側で行われるコンテンツデータの送信にかかわる処理（上述した説明においては、ＳＴＢ１１との間で行われる処理）について説明する。サービスプロバイダ２は、ステップＳ２３１において、他の装置から、スケジュールに関する問いあわせ、または、コンテンツデータの送信要求があったか否かを判断する。
【０２１３】
ステップＳ２３１において、他の装置からの問い合わせまたは要求があったと判断されるまで、待機状態が維持され、他の装置からの問い合わせまたは要求があったと判断されと、ステップＳ２３２に処理が進められる。ステップＳ２３２において、他の装置からの問い合わせまたは要求は、スケジュールに関する問い合わせであるか否かが判断される。ステップＳ２３２において、スケジュールに関する問い合わせであると判断されると、ステップＳ２３３に処理が進められる。
【０２１４】
ステップＳ２３３において、スケジュールの問い合わせをしてきた装置の機器ＩＤに対応するスケジュールが、スケジュール作成部２０４により作成され、記憶されているか否かが判断される。他の装置（例えば、ＳＴＢ１１）は、スケジュールに関する問い合わせを所定の間隔で、サービスプロバイダ２に対して行うわけだが、その問い合わせを行う際、自己の機器ＩＤを送信する。
【０２１５】
従って、サービスプロバイダ２側では、その送信されてきた機器ＩＤを用いて、その機器ＩＤにかかわるスケジュールが、スケジュール作成部２０４に記憶されているか否かを判断する。スケジュール作成部２０４は、図２２に示したようなデータ構造を有するスケジュールが、複数記憶されているわけだが、そのスケジュールのデータ内の“送信先機器ＩＤ”が参照され、送信されてきた機器ＩＤと一致する“送信先機器ＩＤ”があるか否かが判断される。
【０２１６】
ステップＳ２３３において、受信された機器ＩＤ（装置）に関するスケジュールはないと判断された場合、ステップＳ２３１に戻り、それ以降の処理が繰り返される。一方、ステップＳ２３３において、受信された機器ＩＤに関するスケジュールがあると判断された場合、ステップＳ２３４に処理が進められ、その判断されたスケジュールが、スケジュール作成部２０４から読み出され、スケジュールの問い合わせをしてきた装置に対して送信される。
【０２１７】
なお、ステップＳ２３４において読み出されるスケジュールは、スケジュール内の情報の１つである“送信状態”（図２２）が、まだコンテンツデータの送信を行っていないことを示す情報であるもののみである。また、“送信状態”が、まだコンテンツデータの送信を行っていないことを示す情報であっても、既にスケジュール自体が、送信されているような場合には、再度同一のスケジュールを送信する必要はないので、そのようなスケジュールも読み出されないようにしても良い。
【０２１８】
再度、同一のスケジュールが送信されないようにするには、例えば、スケジュール自体が送信されたか否かを示すフラグを用意し、そのフラグを図２２に示したスケジュールのデータの１つとして含ませるようにしても良いし、“送信状態”にそのような情報を含ませるようにしても良い。
【０２１９】
ステップＳ２３４において、スケジュールの送信が終了されると、ステップＳ２３１に戻り、それ以降の処理が繰り返される。
【０２２０】
一方、ステップＳ２３２において、他の装置からの問い合わせまたは要求は、スケジュールの問い合わせではないと判断された場合、すなわち、コンテンツデータの送信の要求であると判断された場合、ステップＳ２３５に処理が進められる。ステップＳ２３５において、送信が要求されたコンテンツデータの送信が開始される。
【０２２１】
コンテンツデータの送信の要求を出す装置（例えば、ＳＴＢ１１）は、その要求を出す際、トランザクションＩＤの情報を少なくとも送信する。トランザクションＩＤが送信されくることにより、サービスプロバイダ２側では、スケジュール作成部２０４に記憶されているスケジュールのうち、どのスケジュールが実行されているのかを特定することが可能となる。
【０２２２】
そして、実行されているスケジュールが特定されることにより、送信すべきコンテンツのコンテンツＩＤを特定することができる。その特定されたコンテンツＩＤに関連付けられているコンテンツデータが、コンテンツデータベース２０２（図７）から読み出され、送信される。
【０２２３】
ステップＳ２３５において、コンテンツデータの送信が開始されると、ステップＳ２３６において、コンテンツデータの送信が開始されたことが、ユーザ側の所定の装置に対して通知される。所定の装置とは、サービスプロバイダ２の送信先テーブルに登録されているメールアドレス（図１８）が割り当てられている装置である。
【０２２４】
ステップＳ２３７において、サービスプロバイダ２は、コンテンツデータを全て送信したか否か、すなわち、送信が終了したか否かを判断する。ステップＳ２３７において、コンテンツデータの送信が終了されたと判断されるまで、ステップＳ２３７の処理は繰り返され、コンテンツデータの送信が終了されたと判断されると、ステップＳ２３８に処理が進められる。
【０２２５】
コンテンツデータが送信される際、ライセンスデータも送信される。コンテンツデータは、ライセンスデータがないと再生できないようにされている。例えば、コンテンツデータは、ユーザ側の装置に送信される際、暗号化されて送信され、その暗号化をとくためのデータが、ライセンスデータに含まれている。そのため、コンテンツデータとライセンスデータの両方が、ユーザ側（ＳＴＢ１１）に送信される必要がある。その送信するタイミングは、必ずしも同時である必要はない。すなわち、コンテンツデータとライセンスデータは、同時に送信されても良いし、異なる時刻（別々）に送信されるようにしても良い。
【０２２６】
例えば、コンテンツデータは比較的データ量が多いため、送信するための送信回線が空いている時間、例えば、夜間などに送信され、その後の時点または前の時点で、比較的データ量が少ないライセンスデータが、ユーザが視聴する時間に間に合うように送信されるようにしても良い。
【０２２７】
ステップＳ２３８において、図１８に示したスケジュールのデータ内の“送信状態”の情報が、コンテンツデータの送信が終了したことを示す情報に書き換えられる。情報が書き換えられるのではなく、その対応するスケジュールが削除されるようにしても良い。このような、“送信状態”の情報が、コンテンツデータの送信が終了したことを示す情報に書き換えらるのは、課金の処理を実行するために行われるので、課金の処理が終了した時点で、削除されるようにしても良い。
【０２２８】
そして、ステップＳ２３９において、コンテンツデータの送信が終了したことを示す通知が行われる。この通知の処理は、ステップＳ２３６における通知の処理と同様に行われる。
【０２２９】
このようにして、サービスプロバイダ２側では、コンテンツデータの送信にかかわる処理を制御している。なお、ステップＳ２３６における通知の処理と、ステップＳ２３９における通知の処理は、必ずしも必要な処理ではなく、通知を行わないようにしても良いし、どちらか一方の通知だけが行われるようにしても良い。
【０２３０】
このようなサービスプロバイダ２の処理に対応して行われる、コンテンツデータの送信を受ける側の装置の処理について、図２８のフローチャートを参照して説明する。ここでは、ＳＴＢ１１における処理を例に挙げて説明する。
【０２３１】
ＳＴＢ１１は、ステップＳ２５１において、スケジュールをサービスプロバイダ２に対して問い合わせる時刻であるか否かを判断する。ＳＴＢ１１は、例えば、予め１時間おきなどの所定の時間間隔で問い合わせを実行するように設定されている。
【０２３２】
その設定されている時間間隔が経過したために、問い合わせを実行する時刻が来たか否かが判断される。ステップＳ２５１において、問い合わせの時刻であると判断されると、ステップＳ２５２において、機器ＩＤが機器ＩＤ管理部２２５（図８）から読み出され、サービスプロバイダ２に対して送信される。機器ＩＤが送信されると、サービスプロバイダ２側で、上述したような処理が行われ、その結果として、スケジュールの情報が送信されてくると、ステップＳ２５３において、そのスケジュールが受信される。
【０２３３】
受信されたスケジュールは、例えば、配信制御部２２２（図８）に記憶される。この記憶される（送信されてくる）スケジュールには、少なくとも、トランザクションＩＤと、送信時刻に関する情報が含まれている。配信制御部２２２は、ステップＳ２５４において、記憶しているスケジュールに含まれている“送信時刻”を参照し、送信時刻になったか否かを判断する。送信時刻になったか否かの判断は、ＳＴＢ１１側にとっては、コンテンツデータの送信を要求する時刻になったか否かの判断である。
【０２３４】
ステップＳ２５４において、コンテンツデータの送信を要求する時刻になったと判断されるまで、ステップＳ２５４の処理が繰り返され、要求する時刻になったと判断されると、ステップＳ２５５に処理が進められる。ステップＳ２５５において、トランザクションＩＤが読み出され、サービスプロバイダ２に対して送信される。
【０２３５】
トランザクションＩＤが送信されると、それに対応するサービスプロバイダ２側の処理の結果として、コンテンツデータが送信されてくる。その送信されてきたコンテンツデータは、ステップＳ２５６において、ＳＴＢ１１に受信され、記憶される。
【０２３６】
このようにして、ＳＴＢ１１側では、他の装置により、購入の処理がされたコンテンツデータを記憶する。
【０２３７】
このように、コンテンツデータの送信を受ける側（この場合、ＳＴＢ１１）から、サービスプロバイダ２に対して、スケジュールの問い合わせ、コンテンツデータの送信要求を出させるようにしたのは、ＳＴＢ１１側が常にスケジュールや、コンテンツデータの受信が可能な状態にされているわけではないからである。
【０２３８】
換言すれば、ＳＴＢ１１の電源が常にオンの状態にされているわけでなく、オフの状態にされているときもあり、そのようなオフの状態のときに、サービスプロバイダ２側から、スケジュールやコンテンツデータを送信されてきたとしても、そのスケジュールやコンテンツデータを、ＳＴＢ１１側が受信し、記憶することができないからである。このようなことを考慮し、ＳＴＢ１１から、スケジュールの問い合わせやコンテンツデータの送信要求を出すようにしている。
【０２３９】
ＳＴＢ１１の電源が常にオンにされている、または、オフにされている状態でも、コンテンツデータなどを受信できる機能をＳＴＢ１１が有しているような場合には、サービスプロバイダ２が、スケジュールを作成した時点で、そのスケジュールをＳＴＢ１１側に送信するようにしても良い。またコンテンツデータも、送信時刻になった時点で、ＳＴＢ１１からの要求がなくても、サービスプロバイダ２側から送信されるようにしても良い。
【０２４０】
上述した実施の形態においては、ＰＣ１２により購入の処理を実行し、ＳＴＢ１１にダウンロードさせる例をあげて説明したが、携帯電話機１３により購入の処理を実行することも可能である。携帯電話機１３により購入の処理を実行する場合も、ＰＣ１２により購入の処理を実行する場合と同様に処理が行われる。
【０２４１】
このように、所定の装置で購入の処理をし、他の装置が、その購入されたコンテンツデータを記憶できるようにすることにより、例えば、ユーザが外出先などから、自宅の装置に所望のコンテンツのコンテンツデータをダウンロードさせるといったことができるようになり、ユーザが所望のコンテンツデータを取得しやすくなる。
【０２４２】
上述した実施の形態においては、基本的にコンテンツデータを購入するユーザと、そのコンテンツデータに基づくコンテンツを楽しむユーザは、同一であるとして説明した。換言すれば、購入されたコンテンツデータにかかる料金を支払うユーザ（課金の対象とされるユーザ）と、そのコンテンツデータを取得するユーザは同一であるとして説明した。さらに換言するならば、コンテンツデータの購入にかかわる処理を実行する装置と、その購入されたコンテンツデータを記憶する装置は、同一のユーザが所有する装置であるとして説明した。
【０２４３】
次に、ユーザＡ（図１）がコンテンツデータの購入の処理をし、ユーザＢが、そのユーザＡが購入したコンテンツデータをユーザＢの所有する装置で楽しむといったようなことを行えるようにする。このようなことを換言するならば、ユーザＡがユーザＢにコンテンツデータ（ライセンスデータ）をプレゼントするといった行為になる。
【０２４４】
付言するに、上述したように、コンテンツデータは、ライセンスデータがなければ、再生することができないようになっている。例えば、コンテンツデータは、ネットワーク１経由で提供される必要はなく、ＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）やＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）などの記録媒体に記録され、その記録媒体がプレゼントされ、その記録媒体が再生される装置に、ライセンスデータがネットワーク１経由で提供されるような場合も考えられるし、そのようにされたとしても、以下のような処理を適用することは可能である。
【０２４５】
また、ライセンスデータの意味を考えた場合、コンテンツデータが無料で配布されるようなときには、必ずしもライセンスデータが必要とは限らず、コンテンツデータのみで再生されるようにしても良い。
【０２４６】
このようなことを考慮した場合、ライセンスデータがプレゼントされるようにした方が好ましい場合がある。以下の説明では、コンテンツデータがプレゼントされるとして表記するが、その意味は、コンテンツデータとライセンスデータがプレゼントされるという意味と、ライセンスデータのみがプレゼントされるという意味を含むとする。
【０２４７】
そのようなコンテンツデータのプレゼントにかかわる処理について説明する。ここでは、ユーザＡがＰＣ１２でコンテンツデータの購入（プレゼント）の処理を実行し、ユーザＢがＳＴＢ２１（図１）に、ユーザＡからプレゼントされたコンテンツデータを取得（記憶）させる場合を例に挙げて説明する。このことを換言すると、サービスプロバイダ２は、ユーザＡに対して課金の処理を行い、ユーザＢに対してコンテンツデータを送信することになる。
【０２４８】
まず、全体の処理の流れ（ＰＣ１２、サービスプロバイダ２、およびＳＴＢ２１の間で行われる処理の流れ）としては、既に説明した図２３に示したフローチャートの処理と、基本的に同様である。図２３のフローチャートのうち、ＰＣの処理は、ユーザＡのＰＣ１２で行われる処理であり、ＳＴＢの処理は、ユーザＢのＳＴＢ２１で行われる処理である。
【０２４９】
ただし、プレゼントにかかわる処理が行えるようにした場合、サービスプロバイダ２側で、そのプレゼントにかかわる処理を行う必要がある。そこで、サービスプロバイダ２側の処理について説明する。まず、図２９と図３０のフローチャートを参照して、サービスプロバイダ２側で、プレゼントの処理を含む、コンテンツの購入にかかわる処理について説明する。
【０２５０】
図２９に示したフローチャートは、図２４に示したフローチャートに、ステップＳ３０７とステップＳ３０８の処理を追加した構成とされている。すなわち、図２９に示したフローチャートのステップＳ３０１乃至Ｓ３０６の処理は、図２４に示したフローチャートのステップＳ２０１乃至Ｓ２０６の処理と基本的に同様である。また、図２９に示したフローチャートのステップＳ３０９乃至Ｓ３１４の処理は、図２４に示したフローチャートのステップＳ２０７乃至Ｓ２１２の処理と基本的に同様である。
【０２５１】
ここでは、既に図２４のフローチャートを参照して説明したサービスプロバイダ２の処理については、適宜、その説明を省略し、プレゼントの処理を実行するために必要な処理について説明する。サービスプロバイダ２が、プレゼントの処理を実行する場合、ステップＳ３０５で送信される購入フォームのデータが、上述した実施の形態の場合と異なる。
【０２５２】
上述した実施の形態においては、購入フォームのデータに基づく画面は、図２５に示したような画面であるとして説明したが、プレゼントの処理が行われる場合、図３１に示すような画面がユーザ側の装置（この場合、ユーザＡのＰＣ１２のディスプレイ２６１）に表示されるような購入フォームのデータが、ステップＳ３０５において送信される。
【０２５３】
図３１に示した画面には、ユーザＩＤを入力するための欄、パスワードを入力する欄、および、“プレゼントですか？”というメッセージに対してＹＥＳの時にチェックされるラジオボタンが設けられている。ユーザは、購入するコンテンツデータを、他のユーザにプレゼントする意志がある場合、“プレゼントですか？”というメッセージに対応するラジオボタンをチェックする。図３１に示した画面例は、ラジオボタンがチェックされた状態を示している。
【０２５４】
このような画面をユーザ側のディスプレイ２６１上に表示させるための購入フォームのデータが送信されると、サービスプロバイダ２は、その購入フォームを参照してユーザが入力した情報の受信待ちの状態とされる。そして、ステップＳ３０６において、購入フォームに対する情報を受信すると、ステップＳ３０７に処理が進められる。
【０２５５】
受信された情報には、少なくとも、ユーザＩＤ、パスワードの情報が含まれ、必要に応じ購入処理の対象とされるコンテンツデータは、プレゼントの対象とされていることを示す情報が含まれる。これらの情報のうち、購入処理の対象とされるコンテンツデータは、プレゼントの対象とされているか否かを示す情報が用いられて、ステップＳ３０７の処理が実行される。
【０２５６】
ステップＳ３０７において、購入されるコンテンツデータは、プレゼントの対象とされているものである（そのような情報を含む）と判断された場合、ステップＳ３０８に進み、購入されるコンテンツデータは、プレゼントの対象とされているものではない（そのような情報は含まれていない）と判断された場合、ステップＳ３０９に進む。
【０２５７】
処理がステップＳ３０９に進められた場合、すなわち、購入されるコンテンツデータは、プレゼントの対象とされているものではないので、図２４のフローチャートを参照して説明した状態と同様な状態であり、その処理も同様に行われる。
【０２５８】
一方、ステップＳ３０８に処理が進められた場合、プレゼントにかかわる処理が実行される。ステップＳ３０８における処理を説明する前に、ステップＳ３０６において受信された情報のうち、ユーザＩＤとパスワードの情報の取り扱いについて説明する。
【０２５９】
ステップＳ３０９に処理が進められた場合、図２４のフローチャートを参照して説明したように、ユーザＩＤとパスワードの情報は、購入されたコンテンツデータの送信先の装置を特定するための情報およびユーザ認証を行うための情報として用いられる。ステップＳ３０８に処理が進められた場合、後述するように、ユーザＩＤとパスワードの情報は、課金の対象とされるユーザを特定するための情報として用いられる。
【０２６０】
ステップ３０８におけるプレゼント処理について、図３０のフローチャートを参照して説明する。ステップＳ３２１において、プレゼントフォームのデータが送信される。このプレゼントフォームのデータに基づく処理が行われることによりユーザ側の装置、この場合、ユーザＡのＰＣ１２のディスプレイ２６１に表示される画面の一例を、図３２に示す。
【０２６１】
図３２に示した画面には、“プレゼント先のユーザのメールアドレス”を入力するための欄と、“プレゼントの希望日時”を入力するための欄が設けられている。プレゼント先のユーザのメールアドレスを入力させるのは、プレゼントされるコンテンツデータを送信する先のユーザ（装置）を特定する情報として用いるためである。
【０２６２】
また、プレゼントの希望日時を入力させるのは、例えば、誕生日などの特定の日にプレゼントとしてのコンテンツデータが供給されるようにしたいというユーザ側の要望に応えるためである。このプレゼントの希望日時は、必須の項目ではなく、ユーザは、入力しなくても、後の処理は実行されるようになっている。
【０２６３】
なお、ここでは、プレゼントされる側のユーザを特定するために、メールアドレスを用いるが、他の情報が用いられるようにしても良い。ここでは、図１８に示したような情報が、送信先テーブルに書き込まれているとして説明しているため、その中の情報としては、メールアドレスが最もプレゼント側のユーザを特定するのに適していると思われるので、ここでは、メールアドレスが用いられる場合を例に挙げて説明する。
【０２６４】
なお、本実施の形態のように、送信先テーブル内に、同一のユーザＩＤが存在しないように制御が行われているような場合には、ユーザＩＤにより一意に、プレゼントされる側のユーザを特定することが可能なので、そのユーザＩＤをプレゼントされる側のユーザを特定するための情報として用いるようにしても良い。そのようなしたときには、図３２に示したような画面において、メールアドレスの代わりにプレゼント先のユーザのユーザＩＤが入力されるようにしても良い。
【０２６５】
また、送信先テーブル内に（または、サービスプロバイダ２内の他のテーブルとして）、ユーザの本名、電話番号、住所などを含めて管理させるようにした場合、その本名、電話番号、住所などが、プレゼントされる側のユーザを特定するための情報として用いられるようにしても良い。また、これらの情報の組み合わせで、ユーザが特定されるようにしても良い。
【０２６６】
コンテンツデータをプレゼントする側のユーザが、図３２に示したような画面を参照して、入力した情報は、ステップＳ３２２において、サービスプロバイダ２に受信される。サービスプロバイダ２は、ステップＳ３２２において受信した情報に含まれるメールアドレスの情報を抽出する。ステップＳ３２３において、抽出したメールアドレスが、送信先テーブル（例えば、図１８に示した送信先テーブル）に記憶（登録）されているか否かが判断される。
【０２６７】
ステップＳ３２３において、抽出されたメールアドレスは、送信先テーブルに登録されていると判断された場合、ステップＳ３２４に処理が進められ、登録されていないと判断された場合、図３０に示したフローチャートに基づくプレゼント処理は終了される。抽出されたメールアドレスが、送信先テーブルに登録されていないと、プレゼントとしてのコンテンツデータを送信する先の装置（ユーザ）を特定することができないため、登録されていないと判断された場合には、プレゼント処理は終了される。
【０２６８】
なお、抽出されたメールアドレスが、送信先テーブルに登録されていないと判断された場合、再度、メールアドレスの入力をユーザ側に求めるような処理が行われるようにしても良い。また、このようにして、送信先が確定できないためにプレゼントの処理が終了された場合、ステップＳ３１４（図２９）の処理において、購入の処理が正常に行われなかったことを、購入を要求してきたユーザに認識させるようなメッセージが、ユーザ側の装置に対して送信される。
【０２６９】
一方、ステップＳ３２３において、抽出されたメールアドレスは、送信先テーブルに登録されていると判断され、ステップＳ３２４に処理が進められた場合、その抽出されたメールアドレスに対して、メールが送信される。ここでは、抽出されたメールアドレスが、“△×△＠ｘ．ｃｏ．ｊｐ”であるとする。このメールアドレスは、図１８に示した送信先テーブルを参照するに、ユーザＩＤが“カキク”のユーザのメールアドレスである。
【０２７０】
このように、抽出されたメールアドレスと、送信先テーブルに記載されているメールアドレスが一致した場合、ステップＳ３２３においては、ＹＥＳと判断され、ステップＳ３２４に処理が進められる。ＹＥＳと判断されたときには、そのメールアドレスの欄に書き込まれている情報も必要に応じ読み出される。この場合、少なくとも、端末名称の欄に書き込まれている“パソコン”、“ＳＴＢ”、および“ケイタイ”という情報が読み出される。読み出された情報は、メールの内容に含まれて送信される。
【０２７１】
このとき送信されるメールの内容としては、例えば、図３３に示すような内容である。ここでは、ユーザＢのＰＣ２２でメールが受信され、そのＰＣ２２のディスプレイ３０１上に、図３３に示したような内容（画面）が表示されるとして説明する。
【０２７２】
図３３に示した画面には、“ユーザＡさんからコンテンツのプレゼントがあります。プレゼントを受け取りますか？”といったメッセージが表示される。このメッセージ内の“ユーザＡ”のところには、ユーザＡのユーザＩＤや、ユーザＡが予め登録しておいた自己の名前（例えば、送信先テーブル内の１つの情報として、他の情報と関連付けられて管理される）などが表示される。サービスプロバイダ２側では、このような画面を表示させるためのメールを送信する際、プレゼントの申し出をしているユーザのユーザＩＤ（またはパスワード、若しくは、ユーザＩＤとパスワード）から、プレゼントの申し出をしたユーザを特定し、その特定されたユーザを示す文字列が、上述したメッセージ内の“ユーザＡ”のところに表示されるように、メールの内容を作成する。
【０２７３】
図３３に示した画面には、さらに、“プレゼントを受け取りますか？”というメッセージに対する答えを入力するためのラジオボタンが設けられている。ここでは、２つのラジオボタンが設けられており、一方が“ＹＥＳ”、他方が“ＮＯ”に対応するラジオボタンとされている。このうち“ＹＥＳ”に対応するラジオボタンがチェックされると、“受信先の装置を選択してください”というメッセージに対して答えを入力するためのラジオボタンが有効となるようにされている。
【０２７４】
図３３に示した例では、“パソコン”、“ＳＴＢ”、および“ケイタイ”といった３つの端末名称に対応するラジオボタンが、それぞれ設けられている。仮に、プレゼントを受けとる側のユーザが、１台の装置（端末）しか登録していないような場合、この端末名称が表示される部分には、１つの端末名称しか表示されないことになるが、そのような１つの端末名称しか表示されないときには、その端末名称に対応する装置をコンテンツデータの受信先として指定しなくてはならない。すなわち、装置の選択の余地がないため、表示させ、選択させる必要性がないので、１つの端末名称しか表示されないような際には、表示されないようにしても良い。
【０２７５】
図３３に示したような画面を参照して、プレゼントを受け取る側のユーザが入力した情報は、サービスプロバイダ２に対して送信される。サービスプロバイダ２は、ステップＳ３２５において、プレゼントを受け取る側のユーザからの情報を受信したか否かを判断し、受信したと判断すると、ステップＳ３２６に処理が進められる。
【０２７６】
ステップＳ３２６において、サービスプロバイダ２は、受信した情報に含まれる“プレゼントを受け取りますか？”という問いに対するユーザの答えを抽出し、その抽出された答えが“ＹＥＳ”であるか否かを判断する。すなわち、ステップＳ３２６においては、プレゼントを受ける側のユーザが、そのプレゼントを承諾すると決定したか否かが判断される。
【０２７７】
ステップＳ３２６において、プレゼントされる側のユーザが、そのプレゼントを受け取らないと決定したと判断された場合、プレゼントを実行する必要がないので、図３０に示したフローチャートに基づくプレゼント処理は終了される。なお、このようにして、プレゼントされる側のユーザ（この場合、ユーザＢ）が、そのプレゼントを拒絶したような場合、そのことを、プレゼントをする側のユーザ（この場合、ユーザＡ）に知らせるようなメッセージが、例えば、電子メールとして送信されるといった処理が行われるようにしても良い。
【０２７８】
一方、ステップＳ３２６において、プレゼントされる側のユーザが、そのプレゼントを受け取ると承諾したと判断されると、ステップＳ３２７に進み、そのプレゼントの対象とされているコンテンツデータを、プレゼント先に送信するためのスケジュールが作成される。このとき作成されるスケジュールも、基本的に、図２２に示したようなスケジュールと同様の情報からなるものである。
【０２７９】
図２２を参照してステップＳ３２７において作成されるスケジュールの内容について説明する。ここでは、ユーザＡからユーザＢに対してプレゼントがされるとして説明する。“コンテンツＩＤ”は、ユーザＡがユーザＢに対してプレゼントするとして指定したコンテンツに対応するＩＤが書き込まれる。“送信先機器ＩＤ”は、ステップＳ３２５で受信したユーザＢが指定した装置（端末名称）に対応する機器ＩＤが書き込まれる。
【０２８０】
“課金先ユーザＩＤ”は、プレゼントを行うユーザＡのユーザＩＤが書き込まれる。“送信時刻”は、ユーザＡが、コンテンツデータをユーザＢにプレゼントする時刻として指定した時刻が、基本的に書き込まれる。“基本的に”と記述したのは、後述するスケジューリングの処理で、サービスプロバイダ２が指定された時刻以外の時刻を書き込む（設定する）可能性があるからである。
【０２８１】
このようなスケジュールが作成されると、処理は、ステップＳ３１４（図２９）に進められる。ステップＳ３１４においては、購入受付完了の通知が行われる。その通知は、プレゼントの処理が実行され、プレゼントされる側のユーザがプレゼントを受けると承諾した場合、そのユーザと、プレゼントをする側のユーザに、それぞれ、通知される。
【０２８２】
また、プレゼントの処理が実行されたが、プレゼントされる側のユーザがプレゼントを受け取らないと決定した場合、そのユーザに対しては、プレゼントは中止されたことを示すことが通知され、プレゼントをする側のユーザに対しては、プレゼントが拒否されたことを示すことが通知される。
【０２８３】
プレゼントの処理が実行されなかった場合、すなわち、ステップ委Ｓ３０７において、プレゼントではないと判断され、それ以降の処理が行われた場合、図２４に示したフローチャートのステップＳ２１２で行われた処理と同様の処理が行われる。
【０２８４】
このようにしてプレゼントに関する処理も含んだ、購入にかかわる処理が、サービスプロバイダ２側で行われる。次に、サービスプロバイダ２側で行われるコンテンツデータの送信にかかわる処理について説明する。この、サービスプロバイダ２側で行われるコンテンツデータの送信にかかわる処理は、基本的に、図２７に示したフローチャートを参照して説明した場合と同様にして行われるので、その説明は省略する。ただしこの場合、サービスプロバイダ２とプレゼントを受けるユーザ側の装置である、例えばＳＴＢ２１との間で行われる処理である。
【０２８５】
また、プレゼントにかかわるコンテンツデータが送信される場合、ステップＳ２３９における送信終了の通知は、プレゼントをされた側のユーザだけでなく、プレゼントをした側のユーザに対しても通知されるようにした方が良い。プレゼントをした側のユーザにも通知を出すことにより、プレゼントが確実に行われ、終了したことを、また、そのことにより課金が発生することを、ユーザに確実に認識させることが可能となる。
【０２８６】
プレゼントを受ける側の装置（この場合、例えば、ユーザＢのＳＴＢ２１）は、図２８のフローチャートを参照して説明したような処理を実行する。すなわち、ユーザＢが自分のために購入したコンテンツデータが受信される場合であっても、ユーザＡからプレゼントされたコンテンツデータが受信される場合であっても、基本的に同様の処理が実行される。
【０２８７】
このように、本実施の形態においては、コンテンツデータ（ライセンスデータ）を、他のユーザにプレゼントすることができる。
【０２８８】
次に、サービスプロバイダ２が行うスケジューリングについて説明する。このスケジューリングは、例えば、ステップＳ３１３（図２９）で行われる処理であり、新たなコンテンツの購入が指示されたときに行われる処理である。
【０２８９】
ここで、スケジューリングが行われる状況について確認する。まず、ユーザＡが、ユーザＡの所有する機器で購入の処理を実行し、その購入の処理を実行した機器にコンテンツデータを記憶させる状況がある。また、ユーザＡが、ユーザＡの所有する機器で購入の処理を実行し、その購入の処理を実行した機器とは別の機器にコンテンツデータを記憶させる状況がある。
【０２９０】
さらに、ユーザＡが、ユーザＡの所有する機器で購入の処理を実行し、ユーザＡとは異なるユーザＢが所有する機器にコンテンツデータを記憶させる状況がある。
【０２９１】
このように、購入の処理を実行した機器と、その処理の結果購入されたコンテンツデータの記憶先の機器との関係も、さまざまある。また、コンテンツデータを送信するタイミングも、例えば、ユーザが指定した時刻に送信する場合と、サービスプロバイダ２側で設定した時刻に送信する場合とがある。
【０２９２】
また、送信されるコンテンツデータのデータ量も一定でなく、さまざまなデータ量であり、短時間で送信が完了されるものから、長時間送信にかかるものまでさまざまである。
【０２９３】
このようなさまざま状況を考慮して、コンテンツデータを送信するタイミングを決定する必要がある。このような送信するタイミングを決定する処理がスケジューリングである。
【０２９４】
図３５のフローチャートを参照して、サービスプロバイダ２のスケジュール作成部２０４（図７）が行うスケジューリングについて説明するが、その前に、図３４を参照して、スケジューリングが行われるときに参照されるテーブルについて説明する。図３４は、スケジュール作成部２０４が、スケジュールを作成する際に参照するテーブルであり、所定のコンテンツが送信される予約が入っている時刻が、参照することにより判別できるようなテーブルとされている。
【０２９５】
図３４に示した送信予約テーブル３２１は、１０分毎に予約が入れられるようになっている例であり、また、１時００分、１時１０分、１時２０分、１時３０分の部分を拡大した例である。図３４において、黒丸●は、予約が入っていることを示し、白丸○は、予約が入っていない（予約可能である）ことを示している。
【０２９６】
また、図３４においては、例えば、０乃至１０分の間に、Ｎ個の予約を入れることが可能であることを示している。このＮ個の具体的な数は、その時刻に送信されるコンテンツデータのデータ量と、サービスプロバイダ２が、１０分の間に送信可能なデータ量（送信能力）に基づいて決定される値である。しかしながら、送信能力（処理能力）は、一定であるので、基本的に、コンテンツデータのデータ量に基づいて、決定される値となる。
【０２９７】
従って、データ量が大きいコンテンツデータを多く送信するような場合には、Ｎの数は小さくなり、データ量が小さいコンテンツデータを多く送信するような場合には、Ｎの数は大きくなるといったように、各時刻により変動する値である。Ｎの値は、既に予約が入っているコンテンツデータ量を考慮して変動的に決定される値である。
【０２９８】
送信予約テーブル３２１には、確定部分３２２と未確定部分３２３とが設けられている。確定部分３２２には、スケジュールとして確定された予約数を示す部分である。未確定部分３２３は、プレゼントの要求があり、そのプレゼントを受けるか否かの判断が、プレゼントを受け取る側のユーザにおいて行われていないために、予約を入れる（確定）することができない予約数を示す部分である。
【０２９９】
スケジュール作成部２０４は、図３４に示したような送信予約テーブル３２１を参照して、図３５に示すフローチャートに基づくスケジューリングにかかわる処理を実行する。図３５に示したフローチャートを参照した説明においては、送信時刻の決定にかかわる処理について説明し、その他の情報の取得については説明しないが、その他の情報は、既に説明したようにして取得され、書き込まれる。
【０３００】
ステップＳ３５１において、スケジュール作成部２０４は、新たなコンテンツの購入の要求があり、そのコンテンツを送信するためのスケジュールを作成する必要があるか否かを判断する。
【０３０１】
上述したように、コンテンツの購入にかかわる処理は、コンテンツ配信予約部２０１において行われる。コンテンツ配信予約部２０１は、コンテンツの予約を受けたと判断した時点（例えば、図２４のステップＳ２１１が実行されるタイミング）で、スケジュール作成部２０４に新たなスケジュールの作成を行うように指示を出す。スケジュール作成部２０４は、このような指示があったか否かを判断することにより、ステップＳ３５１における判断を行う。
【０３０２】
ステップＳ３５１において、新たなスケジュールの作成を行うと判断されると、ステップＳ３５２に進み、その作成するスケジュールは、プレゼントにかかわるスケジュールであるか否かが判断される。ステップＳ３５２において、プレゼントにかかわるスケジュールであるか否かを判断するのは、そのプレゼンを受ける側のユーザが、そのプレゼントを受けると確定するまで、そのプレゼントにかかわるスケジュール（特に、コンテンツデータを送信する時刻）を確定することができないためである。
【０３０３】
ステップＳ３５２において、新たに作成するスケジュールは、プレゼントにかかわるスケジュールではないと判断された場合、ステップＳ３５３において、購入されるコンテンツのコンテンツデータを送信する時刻が、ユーザにより指定されているか否かが判断される。ステップＳ３５３において、送信する時刻は指定されていると判断された場合、ステップＳ３５４に進み、指定されている時刻に送信可能であるか否かが判断される。
【０３０４】
この判断は、図３４に示した送信予約テーブル３２１が参照されることにより行われる。例えば、時刻として１時００分の部分を参照するに、１時００分には、Ｎ個の予約が入れられる状態となっている。このうち、予約０−１乃至０−３は、予約が既に入っているが、予約０−４乃至０−Ｎは、予約を受け付けられる状態とされている。ユーザによるコンテンツデータの送信時刻が、１時００分と指定されていれば、この場合、予約０−４に予約を入れることが可能であると判断されるため、ユーザが指定した時刻に、コンテンツデータを送信することが可能であると判断される。
【０３０５】
例えば、時刻として１時１０分の部分を参照するに、１時１０分には、Ｎ個（１時００分とは異なる個数）の予約が入れられる状態となっている。このうち、予約１０−１乃至１０−Ｎは、予約が既に入っている状態とされている。すなわち、予約できる個数は、“ない”状態である。ユーザによるコンテンツデータの送信時刻が、１時１０分と指定されていると、既に予約は一杯であると判断されるため、ユーザが指定した時刻に、コンテンツデータを送信するは不可能であると判断される。
【０３０６】
このような判断方法により、ステップＳ３５４において、ユーザが指示した時刻にコンテンツデータを送信することは可能であると判断された場合、ステップＳ３５５に進み、その指定された時刻が、コンテンツデータの送信時刻として設定される。すなわち、図２２を参照するに、“送信時刻”にユーザが指定した時刻が書き込まれる。また、この際、“送信状態”には、まだ送信を行っていない“未送信”という情報が書き込まれる。
【０３０７】
このようにして、ユーザがコンテンツデータの送信時刻を指定しているとき、かつ、その時刻に送信できると判断されたときには、その時刻が書き込まれたスケジュールが作成される。
【０３０８】
一方、ステップ３５４において、ユーザが指定した時刻には、コンテンツデータを送信することはできないと判断された場合、ステップＳ３５６に進み、ユーザが指定した時刻に最も近く、送信可能な時刻が送信予約テーブル３２１が参照されることにより検索される。
【０３０９】
例えば、図３４を再度参照して説明するに、ユーザが指定した時刻が１時１０分だとすると、その時刻は、既に予約が一杯であるため、ユーザが指定した１時１０分という時刻には、コンテンツデータを送信することはできないと判断される。このような時には、その前後の時刻が参照される。指定された時刻の前の時刻を先に検索するか、または、指定された時刻の後の時刻を先に検索するかは、予め設定しておく必要があるが、どちらを先に検索しても基本的に良い。
【０３１０】
ただし、指定された時刻の前の時刻を先に検索するようにした場合、その検索対象の時刻（時刻Ａとする）と、その検索が実行されている時点での時刻（現時刻とする）を比較し、現時刻より時刻Ａが後の時刻でなければ、時刻Ａは、検索対象の時刻とはしないようにする。これは例えば、指定された時刻が１時１０分である場合、その前の時刻（すなわち時刻Ａ）は、１時００分になるが、検索が行われている時刻（すなわち現時刻）が、例えば１時０５分であるような場合には、時刻Ａに送信することはできない（予約を入れることはできない）からである。
【０３１１】
ステップＳ３５６において、送信予約テーブル３２１が参照されることにより、ユーザが指定した時刻に最も近く、送信可能な時刻が、送信時刻として設定される。そして、設定された時刻が、スケジュールの“送信時刻”（図２２）に書き込まれる。
【０３１２】
このようにして、ユーザがコンテンツデータの送信時刻を指定しているが、その時刻に送信できないと判断されたときには、その時刻にできるだけ近い時刻で送信可能な時刻が書き込まれたスケジュールが作成される。
【０３１３】
このような処理は、ユーザが時刻を指定しているときに行われる処理であるが、ステップＳ３５３において、ユーザがコンテンツデータの送信時刻を指定していないと判断された場合、ステップＳ３５７に処理が進められる。ステップＳ３５７において、そのスケジュールが作成されている時刻（現時刻）に近く（基本的に後の時刻）、送信可能な時刻が、送信時刻と設定される処理が実行される。
【０３１４】
このようにして、ユーザがコンテンツデータの送信時刻を指定していないときは、スケジュール作成部２０４側で、送信可能な時刻が書き込まれたスケジュールが作成される。
【０３１５】
一方、ステップＳ３５２において、新たに作成されるスケジュールは、プレゼントにかかわるスケジュールであると判断された場合、ステップＳ３５８に処理が進められる。ステップＳ３５８において、スケジュール作成部２０４は、図２２を再度参照して説明するに、“送信状態”という情報を、まだ、送信するか否かが確定されていない情報、例えば、未確定という情報にしたスケジュールを作成する。
【０３１６】
この際、ユーザがプレゼントを行う日時として指定した日時（時刻）は、図２２に示したスケジュールの“送信時刻”という情報に書き込まれる。このようなスケジュールは、送信予約テーブル３２１の未確定部分３２３の１つの予約としてカウントされる。
【０３１７】
このように、送信する時刻が指定されていてもスケジュールとして確定することができないのは、プレゼントを受ける側から、そのプレゼントを受けるという意志決定に関する情報を受信していないからである。そこで、ステップＳ３５９において、プレゼントを受ける側のユーザから、プレゼントを受け取るか否かの意志決定に関する情報を受信したか否かが判断される。この処理は、図３０に示したフローチャートのステップＳ３２５の処理として行わる処理と同様である。
【０３１８】
スケジュール作成部２０４としては、プレゼントを受け取る側からの返答に関する情報が供給されたか否かを判断することにより、ステップＳ３５９の処理が行われる。ステップＳ３５９において、情報が供給されたと判断された場合、ステップＳ３６０に処理が進められる。
【０３１９】
ステップＳ３６０において、その供給された情報は、プレゼントを受け取るという情報（プレゼントを許諾するという情報）であるか否かが判断される。供給された情報が、プレゼントを許諾するという情報であると判断された場合、ステップＳ３５３に進み、それ以降の処理が行われる。ステップＳ３５３以降の処理については、既に説明したので、その説明は省略するが、プレゼントにかかわるスケジュールの場合、異なる処理を含むので、その処理に関して説明を加える。
【０３２０】
ステップＳ３５３において、時刻が指定されているか否かを判断する際の情報は、既に、未確定のスケジュールとして書き込まれているスケジュールが参照されて行われる。すなわち、未確定のスケジュールも、図２２に示したような情報を含むスケジュールとして既に作成されているわけだが、そのうち、“送信時刻”の情報が参照されてステップＳ３５３における処理が行われる。
【０３２１】
“送信時刻”の情報として所定の時刻が書き込まれている場合、ステップＳ３５４に処理が進められる。ステップＳ３５４においては、その“送信時刻”の情報として書き込まれていた時刻と、現時刻が比較され、書き込まれていた時刻が、現時刻よりも後の時刻であれば、かつ、その書き込まれていた時刻に送信可能であれば、ステップＳ３５５に処理が進められる。
【０３２２】
一方、ステップＳ３５４において、書き込まれていた時刻と、現時刻を比較した結果、書き込まれていた時刻が、現時刻よりも前の時刻であると判断された場合、既に、その書き込まれていた時間が経過してしまっていることを示している。すなわち、プレゼントを提供する時間として指定されていた時刻が経過してしまっていると判断されたことになる。
【０３２３】
このような場合には、ステップＳ３５６に処理が進められ、指定されていた時刻に最も近い時刻で、送信可能な時刻が、送信時刻として設定されるよりも、その時点で、できるだけ早く送信できる時刻が、送信時刻として設定されるようにした方が良い。
【０３２４】
このようにして、スケジュール内の“送信時刻”が設定され、その設定された時刻が書き込まれる際、“送信状態”の情報も、“未確定”を示す情報から、“未送信”を示す情報に書き換えられる。さらに、送信先テーブル３２１の未確定部分３２３に書き込まれている予約数が、１だけ減算され、確定部分３２３の設定された時刻に対応する予約数が、１だけ加算される。
【０３２５】
このようにして、プレゼントにかかわるスケジュールが作成される。
【０３２６】
一方、ステップＳ３６０において、プレゼントをされる側のユーザからの情報が、プレゼントを受け取らないという情報であったと判断された場合、ステップＳ３６１に進む。ステップＳ３６１においては、そのプレゼントを拒絶されたコンテンツに対応する、未確定とされていたスケジュールが破棄される。この破棄の処理においては、送信先予約テーブル３２１の未確定部分３２３の部分の予約数が１だけ減算されるという処理も含む。
【０３２７】
このようにして作成されたスケジュールは、上述したように、例えば、ＳＴＢ１１が、自分宛のスケジュールが新たに作成されていないか否かを所定の時間間隔で問い合わせてきたときに提供される。ＳＴＢ１１は、その提供されたスケジュールに基づき、コンテンツデータの送信の要求をするわけだが、その要求は、スケジュールの提供を受けた時刻から後の時刻で出される。
【０３２８】
このようなタイムラグのために、ＳＴＢ１１の状況が、スケジュールの提供を受けた時刻から、実際にコンテンツデータの送信の要求を出すまでの間に変化している可能性があることを考慮する必要がある。
【０３２９】
具体的には、ＳＴＢ１１は、有限な容量を有する記憶部８５（図３）を備え、その記憶部８５に受信されたコンテンツデータを記憶するわけだが、スケジュールの提供を受けた時点で、そのスケジュールに基づき送信されてくる予定のコンテンツデータのデータ量を記憶するだけの容量が、記憶部８５にあったとしても、実際にコンテンツデータの送信を要求するまでの間に、他のコンテンツデータが受信され、記憶されたために、記憶部８５の容量が足りなくなるといった状況に変化しているような可能性がある。
【０３３０】
このように、ＳＴＢ１１が、スケジュールに基づき、コンテンツデータの送信を要求し、実際にコンテンツデータを受信したとしても、そのコンテンツデータを記憶するだけの容量が記憶部８５に存在せず、結果として、記憶できないといったことが発生する可能性がある。また、そのように記憶できないといった状況が、ＳＴＢ１１側で発生したような場合には、例えば、再度送信し直すといった処理を、サービスプロバイダ２側が行う必要がある。
【０３３１】
このようなことを考慮した、サービスプロバイダ２側で行う、コンテンツデータの送信にかかわる処理について、図３６のフローチャートを参照して説明する。
【０３３２】
図３６に示したフローチャートは、図２７に示したフローチャートに、ステップＳ３８５とステップＳ３８６の処理を追加した構成とされている。すなわち、図３６に示したフローチャートのステップＳ３８１乃至Ｓ３８４の処理と、ステップＳ３８７乃至Ｓ３９１の処理は、図２７に示したフローチャートを参照のステップＳ２３１乃至Ｓ２３４の処理と、ステップＳ２３５乃至Ｓ２３９の処理と、それぞれ同様の処理である。ここでは、その同様の処理についての説明は、既に説明したので、省略する。
【０３３３】
ステップＳ３８５に処理がくる場合は、ＳＴＢ１１（ここでは、ＳＴＢ１１を例に挙げて説明する）が、コンテンツデータの送信を要求してきたと判断されたときである。ステップＳ３８５において、送信が要求されたコンテンツデータを送信したときに、相手側の装置は、そのコンテンツデータを確実に記憶できるか否かが判断される。この判断を行うための情報は、ＳＴＢ１１側から送信されてくる必要がある。
【０３３４】
ＳＴＢ１１は、コンテンツデータの送信の要求を出す際、自己の記憶部８５の残りの容量に関する情報を、サービスプロバイダ２に送信するようにする。サービスプロバイダ２側で、受信された記憶部８５の残りの容量と、送信の要求があったコンテンツデータのデータサイズを比較し、受信された記憶部の残りの容量が、送信の要求があったコンテンツデータのデータサイズよりも大きいと判断された場合のみ、ステップＳ３８７に進み、それ以降の処理、すなわち、コンテンツデータの送信にかかわる処理が実行されるようにする。
【０３３５】
または、ＳＴＢ１１は、コンテンツデータの送信の要求を出す際、自己の記憶部８５の残りの容量と、送信を要求するコンテンツデータのデータサイズ（この情報は、ＳＴＢ１１側では、図２８のステップＳ２５３における処理で、受信されるスケジュールの情報内に含まれていることにより、取得することができる）を比較し、コンテンツデータを記憶するだけの容量が記憶部８５に残っているか否かを示す情報をサービスプロバイダ２側に送信するようにする。
【０３３６】
サービスプロバイダ２側では、コンテンツデータを受信可能であるという情報、または、受信不可能であるという情報のうちの、どちらか一方の情報を受信することになる。そのような情報を用いて、サービスプロバイダ２は、ステップＳ３８５の処理を行うようにしても良い。
【０３３７】
いずれにしても、サービスプロバイダ２は、ＳＴＢ１１側が受信したコンテンツデータを記憶することができる状態であると判断しない限り、ステップＳ３８７以降の処理を実行しない。従って、ＳＴＢ１１側で、送信されてきたコンテンツデータを記憶できないといった不都合が発生するようなことを防ぐことが可能となる。
【０３３８】
一方、ステップＳ３８５において、要求されたコンテンツデータを送信することは不可能であると判断された場合、ステップＳ３８６に処理が進められる。ステップＳ３８６において、スケジュールが変更される。すなわち、ステップＳ３８６に処理が来る場合、送信される予定だったコンテンツデータが送信できなかったことを示しており、再度、別の時点で、送信を実行する必要がある。
【０３３９】
そのために、スケジュールの“送信時刻”が書き直される（変更される）必要がある。この変更は、例えば、その時点で書き込まれている時刻より１時間後に設定するなど、所定の時間だけ経過した後に、再度送信が実行されるように書き換えられるようにしても良い。このようにした場合、送信予定テーブル３２１の内容も書き換えられ、新たに設定された時刻の部分の予約数が、１だけ加算された値に変更される。
【０３４０】
または、ユーザに、メールなどで、送信時刻を変更するように指示を出し、その指示に対する返答に基づいて変更されるようにしても良い。このようにした場合、メールの返答を受信するまで、対応するスケジュールの“送信状態”は、未確定を示す情報に変更される。この変更にともない、送信予約テーブル３２１の未確定部分３２２の予約数が１だけ加算された値に変更される。その後、返答を受信した時点で、その返答で指示されている時刻に、スケジュール内の“送信時刻”が変更され、対応する時刻の送信予約テーブル３２１の時刻の部分の予約数が１だけ加算された値に変更される。
【０３４１】
このように、スケジュールが書き直された場合、その書き直されたスケジュールが、再度、ＳＴＢ１１に提供され、その提供されたスケジュールに基づいて、ＳＴＢ１１が処理を実行することにより、コンテンツデータの送受信が行われる。
【０３４２】
または、ＳＴＢ１１が、記憶可能な状態になった時点で、再度、コンテンツデータの送信の要求を出すようにしても良い。このようにした場合、サービスプロバイダ２側では、対応するスケジュールの“送信状態”を未送信のままの状態を維持させるようにしておき、また、対応するスケジュールを削除するといったようなことをしないような処理が実行されれば良い。
【０３４３】
このように、ＳＴＢ１１側で、必要な情報を送信するようにし、サービスプロバイダ２側で対応する処理を実行するようにすることにより、ＳＴＢ１１側で受信したコンテンツデータを記憶できないといったような不都合が発生するようなことを防ぐことが可能となり、サービスプロバイダ２側で、コンテンツデータの送信にかかわる処理を無駄に行うような不都合を防ぐことが可能となる。
【０３４４】
上述した実施の形態においては、１つのコンテンツデータの購入などに関する処理を例に挙げて説明したが、複数のコンテンツデータを同時期に購入する処理を実行することも可能であるし、同時期に複数のコンテンツデータを送受信することも可能である。
【０３４５】
上述した一連の処理は、それぞれの機能を有するハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【０３４６】
記録媒体は、図２に示すように、サービスプロバイダ２などのパーソナルコンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク６１（フレキシブルディスクを含む）、光ディスク６２（ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ−Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ），ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）を含む）、光磁気ディスク６３（ＭＤ（Ｍｉｎｉ−Ｄｉｓｃ）（登録商標）を含む）、若しくは半導体メモリ６４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているＲＯＭ４２や記憶部４８が含まれるハードディスクなどで構成される。
【０３４７】
なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０３４８】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０３４９】
【発明の効果】
本発明によれば、コンテンツデータをユーザ側の装置に供給することができる。
【０３５０】
本発明によれば、コンテンツデータやそのコンテンツデータを再生する際に必要となるライセンスデータをプレゼントすることができるようになる。
【０３５１】
本発明によれば、コンテンツデータやそのコンテンツデータを再生する際に必要となるライセンスデータを、プレゼントする側のユーザが、プレゼントしたい時刻に、プレゼントすることが可能となる。
【図面の簡単な説明】
【図１】本発明を適用した情報処理システムの一実施の形態の構成を示す図である。
【図２】サービスプロバイダの構成例を示すブロック図である。
【図３】ＳＴＢの構成例を示すブロック図である。
【図４】ＰＣの構成例を示すブロック図である。
【図５】携帯電話機の外観の構成例を示す図である。
【図６】携帯電話の内部構成例を示す図である。
【図７】サービスプロバイダの機能を示すブロック図である。
【図８】ＳＴＢの機能を示すブロック図である。
【図９】装置の登録にかかわる処理について説明するためのフローチャートである。
【図１０】テレビジョン受像機に表示される画面の一例を示す図である。
【図１１】送信先テーブルのデータ構成を示す図である。
【図１２】装置の登録にかかわる他の処理について説明するためのフローチャートである。
【図１３】ディスプレイに表示される画面の一例を示す図である。
【図１４】送信先テーブルの他の構成を示す図である。
【図１５】登録した情報の変更にかかわる処理について説明するためのフローチャートである。
【図１６】ディスプレイに表示される画面の一例を示す図である。
【図１７】ディスプレイに表示される画面の一例を示す図である。
【図１８】送信先テーブルの他の構成を示す図である。
【図１９】購入に関する処理について説明するフローチャートである。
【図２０】コンテンツデータベースに記憶されているデータについて説明するための図である。
【図２１】ライセンス発行部に記憶されているデータについて説明するための図である。
【図２２】スケジュールのデータについて説明するための図である。
【図２３】購入に関する他の処理について説明するフローチャートである。
【図２４】サービスプロバイダが行う処理について説明するフローチャートである。
【図２５】ディスプレイ上に表示される画面の一例を示す図である。
【図２６】ディスプレイ上に表示される画面の一例を示す図である。
【図２７】サービスプロバイダが行う処理について説明するフローチャートである。
【図２８】ＳＴＢが行う処理について説明するフローチャートである。
【図２９】サービスプロバイダが行う処理について説明するフローチャートである。
【図３０】プレゼントにかかわる処理について説明するフローチャートである。
【図３１】ディスプレイ上に表示される画面の一例を示す図である。
【図３２】ディスプレイ上に表示される画面の一例を示す図である。
【図３３】ディスプレイ上に表示される画面の一例を示す図である。
【図３４】スケジュールの予約にかかわる送信予約テーブルについて説明するための図である。
【図３５】スケジューリングについて説明するためのフローチャートである。
【図３６】サービスプロバイダが行う処理について説明するフローチャートである。
【符号の説明】
１  ネットワーク，  ２  サービスプロバイダ，  １１  ＳＴＢ，  １２  ＰＣ，  １３  携帯電話機，  ２０１  コンテンツ配信予約部，  ２０２  コンテンツデータベース，  ２０３  送信先データベース，  ２０４  スケジュール作成部，  ２０５  コンテンツ配信部，  ２０６  ライセンス発行部，  ２０７  通信制御部，  ２２１  通信制御部，  ２２２  配信制御部，  ２２３  記憶部，  ２２４  ライセンス管理部，  ２２５  機器ＩＤ管理部，  ２２６  再生部
【図１】
2004265334.tif 000003
【図２】
2004265334.tif 000004
【図３】
2004265334.tif 000005
【図４】
2004265334.tif 000006
【図５】
2004265334.tif 000007
【図６】
2004265334.tif 000008
【図７】
2004265334.tif 000009
【図８】
2004265334.tif 000010
【図９】
2004265334.tif 000011
【図１０】
2004265334.tif 000012
【図１１】
2004265334.tif 000013
【図１２】
2004265334.tif 000014
【図１３】
2004265334.tif 000015
【図１４】
2004265334.tif 000016
【図１５】
2004265334.tif 000017
【図１６】
2004265334.tif 000018
【図１７】
2004265334.tif 000019
【図１８】
2004265334.tif 000020
【図１９】
2004265334.tif 000021
【図２０】
2004265334.tif 000022
【図２１】
2004265334.tif 000023
【図２２】
2004265334.tif 000024
【図２３】
2004265334.tif 000025
【図２４】
2004265334.tif 000026
【図２５】
2004265334.tif 000027
【図２６】
2004265334.tif 000028
【図２７】
2004265334.tif 000029
【図２８】
2004265334.tif 000030
【図２９】
2004265334.tif 000031
【図３０】
2004265334.tif 000032
【図３１】
2004265334.tif 000033
【図３２】
2004265334.tif 000034
【図３３】
2004265334.tif 000035
【図３４】
2004265334.tif 000036
【図３５】
2004265334.tif 000037
【図３６】
2004265334.tif 000038
【手続補正書】
【提出日】平成16年6月29日(2004.6.29)
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１の装置を識別するための第１のＩＤを管理する第１の管理手段と、
第２の装置を識別するための第２のＩＤを管理する第２の管理手段と、
コンテンツを識別するための第３のＩＤを管理する第３の管理手段と、
前記第１の装置から、前記コンテンツの配信の要求があった場合、前記第３の管理手段により管理されている前記第３のＩＤを、前記第１の装置に供給する供給手段と、
前記第１の装置から、前記第１のＩＤを特定するための情報、前記第２のＩＤを特定するための情報、および、前記第３のＩＤを、それぞれ受信した場合、その情報から、前記第１の管理手段により管理されている前記第１のＩＤと、前記第２の管理手段により管理されている前記第２のＩＤを、それぞれ特定する特定手段と、
前記特定手段により特定された前記第２のＩＤに対応する前記第２の装置に、前記第３のＩＤで識別される前記コンテンツを配信する配信手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記特定手段より特定された前記第１のＩＤで識別される前記第１の装置のユーザに、前記配信手段により配信される前記コンテンツの料金を課金する課金手段を
さらに備えることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記特定手段により前記第２のＩＤが特定された後、その第２のＩＤで識別される前記第２の装置のユーザに、前記コンテンツの配信を受けるか否かを問い合わせる問い合わせ手段と、
前記問い合わせ手段による問い合わせの返答として、前記第２の装置のユーザから、前記コンテンツの配信を受けるとの内容の返答を受信した場合、前記特定手段により特定された前記第２のＩＤに対応する前記第２の装置に、前記第３のＩＤで識別される前記コンテンツを配信するスケジュールを作成する作成手段と
をさらに備え、
前記配信手段は、前記作成手段により作成された前記スケジュールに基づき、前記コンテンツを配信する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記作成手段は、前記第１の装置のユーザまたは前記第２の装置のユーザが、前記コンテンツを配信する時刻を指定している場合、その指定された時刻に前記コンテンツを配信するスケジュールを作成する
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記第２の装置から、前記スケジュールの提供の要求があり、かつ、前記作成手段により前記第２の装置に対する前記スケジュールが作成されていた場合、そのスケジュールを前記第２の装置に提供する提供手段を
さらに備えることを特徴とする請求項３に記載の情報処理装置。
【請求項６】
前記第１の管理手段と前記第２の管理手段は、同一のテーブルを管理し、そのテーブルは、前記第１のＩＤと前記第２のＩＤを含むＩＤ、ユーザを識別するためのユーザＩＤ、パスワード、および、メールアドレスを、それぞれ関連づけたものであり、
前記特定手段は、前記第１のＩＤを特定するための情報とし、前記ユーザＩＤとパスワードの少なくとも一方の情報を用い、前記第２のＩＤを特定するための情報として、前記メールアドレスを用いる
ことを特徴とする請求項１に記載の情報処理装置。
【請求項７】
コンテンツ提供装置と、コンテンツ提供装置から指定されるコンテンツの提供先としてのコンテンツ受信装置と、接続される情報処理装置において、
前記コンテンツ提供装置から、前記コンテンツ提供装置の識別情報、前記コンテンツ提供装置がコンテンツ提供先として指定するコンテンツ受信装置の識別情報、および前記コンテンツ受信装置に提供するコンテンツの識別情報を受信する受信手段と、
前記コンテンツ受信装置に、前記コンテンツ提供装置によるコンテンツ提供を受けるか否かを確認する確認手段と、
前記コンテンツ受信装置が、前記コンテンツ提供装置による前記コンテンツ提供を受容した際に、前記コンテンツ受信装置への前記コンテンツ提供処理を行う配信手段と
を備えることを特徴とする情報処理装置。
【請求項８】
前記配信手段は、前記受信手段において指定された前記コンテンツと、前記コンテンツに対応するライセンスを、前記コンテンツ受信装置に提供する
ことを特徴とする請求項７に記載の情報処理装置。
【請求項９】
前記配信手段は、前記コンテンツ提供装置から、前記コンテンツ受信装置に前記コンテンツの配信時刻指定を受けている場合、前記コンテンツの配信スケジュールを管理する
ことを特徴とする請求項７に記載の情報処理装置。
【請求項１０】
コンテンツ提供装置と、前記コンテンツ提供装置から指定されるコンテンツの提供先としてのコンテンツ受信装置と、接続される情報処理装置の情報処理方法において、
前記コンテンツ提供装置から、前記コンテンツ提供装置の識別情報、前記コンテンツ提供装置がコンテンツ提供先として指定するコンテンツ受信装置の識別情報、および前記コンテンツ受信装置に提供するコンテンツの識別情報を受信する受信ステップと、
前記コンテンツ受信装置に、前記コンテンツ提供装置によるコンテンツ提供を受けるか否かを確認する確認ステップと、
前記コンテンツ受信装置が、前記コンテンツ提供装置による前記コンテンツ提供を受容した際に、前記コンテンツ受信装置への前記コンテンツ提供処理を行う配信ステップと
を含むことを特徴とする情報処理方法。
【請求項１１】
コンテンツ提供装置と、前記コンテンツ提供装置から指定されるコンテンツの提供先としてのコンテンツ受信装置と、接続される情報処理装置を制御するコンピュータのプログラムであって、
前記コンテンツ提供装置から、前記コンテンツ提供装置の識別情報、前記コンテンツ提供装置がコンテンツ提供先として指定するコンテンツ受信装置の識別情報、および前記コンテンツ受信装置に提供するコンテンツの識別情報を受信する受信ステップと、
前記コンテンツ受信装置に、前記コンテンツ提供装置によるコンテンツ提供を受けるか否かを確認する確認ステップと、
前記コンテンツ受信装置が、前記コンテンツ提供装置による前記コンテンツ提供を受容した際に、前記コンテンツ受信装置への前記コンテンツ提供処理を行う配信ステップと
を含むことを特徴とするプログラム。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
【発明の属する技術分野】
本発明は情報処理装置および方法、並びにプログラムに関し、コンテンツデータの購入に用いて好適な情報処理装置および方法、並びにプログラムに関する。


【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００２１
【補正方法】変更
【補正の内容】
【００２１】
本発明のプログラムは、第１の装置を識別するための第１のＩＤを管理する第１の管理ステップと、第２の装置を識別するための第２のＩＤを管理する第２の管理ステップと、コンテンツを識別するための第３のＩＤを管理する第３の管理ステップと、第１の装置から、コンテンツの配信の要求があった場合、第３の管理ステップの処理で管理されている第３のＩＤを、第１の装置に供給する供給ステップと、第１の装置から、第１のＩＤを特定するための情報、第２のＩＤを特定するための情報、および、第３のＩＤを、それぞれ受信した場合、その情報から、第１の管理ステップの処理で管理された第１のＩＤと、第２の管理ステップの処理で管理された第２のＩＤを、それぞれ特定する特定ステップと、特定ステップの処理で特定された第２のＩＤに対応する第２の装置への、第３のＩＤで識別されるコンテンツの配信を制御する配信制御ステップとを含む処理をコンピュータに実行させることを特徴とする。


【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００２２
【補正方法】変更
【補正の内容】
【００２２】
本発明の第２の情報処理装置は、コンテンツ提供装置と、コンテンツ提供装置から指定されるコンテンツの提供先としてのコンテンツ受信装置と、接続される情報処理装置であって、コンテンツ提供装置から、コンテンツ提供装置の識別情報、コンテンツ提供装置がコンテンツ提供先として指定するコンテンツ受信装置の識別情報、およびコンテンツ受信装置に提供するコンテンツの識別情報を受信する受信手段と、コンテンツ受信装置に、コンテンツ提供装置によるコンテンツ提供を受けるか否かを確認する確認手段と、コンテンツ受信装置が、コンテンツ提供装置によるコンテンツ提供を受容した際に、コンテンツ受信装置へのコンテンツ提供処理を行う配信手段とを備えることを特徴とする。
前記配信手段は、受信手段において指定されたコンテンツと、コンテンツに対応するライセンスを、コンテンツ受信装置に提供するようにすることができる。 前記配信手段は、コンテンツ提供装置から、コンテンツ受信装置にコンテンツの配信時刻指定を受けている場合、コンテンツの配信スケジュールを管理するようにすることができる。
本発明の第２の情報処理方法は、コンテンツ提供装置と、コンテンツ提供装置から指定されるコンテンツの提供先としてのコンテンツ受信装置と、接続される情報処理装置の情報処理方法であって、コンテンツ提供装置から、コンテンツ提供装置の識別情報、コンテンツ提供装置がコンテンツ提供先として指定するコンテンツ受信装置の識別情報、およびコンテンツ受信装置に提供するコンテンツの識別情報を受信する受信ステップと、コンテンツ受信装置に、コンテンツ提供装置によるコンテンツ提供を受けるか否かを確認する確認ステップと、コンテンツ受信装置が、コンテンツ提供装置によるコンテンツ提供を受容した際に、コンテンツ受信装置へのコンテンツ提供処理を行う配信ステップとを含むことを特徴とする。
本発明の第２のプログラムは、コンテンツ提供装置と、コンテンツ提供装置から指定されるコンテンツの提供先としてのコンテンツ受信装置と、接続される情報処理装置を制御するコンピュータのプログラムであって、コンテンツ提供装置から、コンテンツ提供装置の識別情報、コンテンツ提供装置がコンテンツ提供先として指定するコンテンツ受信装置の識別情報、およびコンテンツ受信装置に提供するコンテンツの識別情報を受信する受信ステップと、コンテンツ受信装置に、コンテンツ提供装置によるコンテンツ提供を受けるか否かを確認する確認ステップと、コンテンツ受信装置が、コンテンツ提供装置によるコンテンツ提供を受容した際に、コンテンツ受信装置へのコンテンツ提供処理を行う配信ステップとを含むことを特徴とする。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００２３
【補正方法】変更
【補正の内容】
【００２３】
本発明においては、コンテンツデータの送信先の装置を決定するためのＩＤが管理され、コンテンツを識別するためのＩＤが管理され、第１の装置から、コンテンツの配信の要求があった場合、管理されているコンテンツを識別するためのＩＤが、その第１の装置に供給される。そして、第１の装置からの情報を受信した場合、その情報から、コンテンツデータの送信先、コンテンツデータの購入にかかる料金の請求先が決定される。
また、本発明においては、コンテンツ提供装置から、コンテンツ提供装置の識別情報、コンテンツ提供装置がコンテンツ提供先として指定するコンテンツ受信装置の識別情報、およびコンテンツ受信装置に提供するコンテンツの識別情報が受信され、コンテンツ受信装置に、コンテンツ提供装置によるコンテンツ提供を受けるか否かが確認され、コンテンツ受信装置が、コンテンツ提供装置によるコンテンツ提供を受容した際に、コンテンツ受信装置へのコンテンツ提供処理が実行される。