JP5596833B2 - コンテンツ配信システム、配信サーバおよびコンテンツ配信方法 - Google Patents

Description

これは、ネットワーク経由で特定の受信端末に映像等のコンテンツを配信するコンテンツ配信システムおよびこれに用いる配信サーバおよび配信サーバからコンテンツを受信する時に、ユーザ機器認証する技術に関する。

特定の相手だけに情報を送る場合、一般に電子メール（以下、メール）が用いられる。この場合、当然のことながら、送信する装置と受信する装置はともにメールソフトを有していることが必要である。近年、ＰＣ（パーソナルコンピュータ）の購入者の多くはメールを利用するので、ＰＣには販売時にメールソフトがインストールされているのが一般的である。

一方、テレビにおいても、近年、ネットワーク接続できる製品が発売され始めた。しかし、ＰＣほどネットワークに接続されるとは限らない。また、家族全員で見る機会が多いテレビでメールを行うことは、ＰＣより頻度が低い。したがって、ネットワークに接続できるとはいえ、テレビにメールソフトをインストールすることは開発コストの点から見て非現実的である。

メールソフトがなくても、ネットワークに接続されたテレビがサーバにアクセスし、コンテンツの配信を要求することは可能である。特許文献１では、ダウンロードの予約方法が開示される。ここでは、テストファイルのダウンロード速度を計測し、完了するまでの時間を予測し、ユーザが所望する時刻にダウンロードを完了させるためのダウンロード開始日時を設定し、ユーザの了解を得て予約をすることが述べられている。ユーザが了解しない場合は、代替案のダウンロード開始日時を提示する。また、ダウンロード状況を監視し、約束した完了時刻までに終わりそうにない場合は、他のサーバに切替える等の方法も述べられている。特許文献２では、ダウンロード予約時間帯を分割して、端末に割り当てて負荷を分散させる方法が述べられている。

更に、今後前述のメールようなサービスが増えることが考えられる。これに対応するサービス受信機器とサービス配信サーバ間の認証を行う方法が特許文献３に述べられている。

特開２００３−６７２８０号公報 特開２００４−１８５１１４号公報 特開２００１−３５０７２４号公報

上記特許文献１，２によれば、メールソフトを有していない端末（テレビ）が配信サーバにアクセスし、所望のコンテンツを所望の日時にダウンロードすることができる。しかしながら、いずれの場合も、端末（テレビ）からサーバにアクセスする場合であり、特定の個人の所有するコンテンツを受信すること、或いはある送信者が特定の端末（テレビ）に自分の有するコンテンツを送信することは考慮されていない。そこで、メールソフトがインストールされていない特定の端末（テレビ）に、送信者の所有するコンテンツを送る技術が望まれる。

また、上記特許文献３によれば、機器が持つ固有のＩＤを用いて認証を行い、前述のサービスを提供する際の認証が行えるが、追加されるサービスが多様化した場合でも、より安全に認証することへの配慮がされていない。そこで、より使い勝手の良い認証技術が望まれる。

本発明の目的は、送信端末からメールソフトを有していない特定の受信端末に、あたかもメールを利用するような使い勝手で自分の所有するコンテンツを送信できるようなサービスを始めとする多様なサービス追加に対応し、ユーザの手を煩わせずに安全な認証を行い、前記サービスを提供できるようにすることである。

上記目的を解決するために、例えば特許請求の範囲に記載の構成を採用する。

送信者は、メールソフトを有しない受信端末に対して、あたかもメールを送るような使い勝手でコンテンツを送信することができる。また、受信者は送信者を確認した後にコンテンツを受信することができるので、不特定多数の人から不要なコンテンツを送信されることがない。
前記の様なサービスを安全に利用可能で、また、配信サーバに代表されるサービスサーバが認証サーバと独立している構成になるため、多様なサービスの追加に耐える認証サーバが実現できる。

コンテンツ配信システムの一実施例を示す全体構成図。 サーバ３０の内部構成の一例を示す図。 テレビ２０の内部構成の一例を示す図。 コンテンツ配信サービスの処理フローを示す図。 未読メールチェックテーブルの一例。 送信者ＤＢの一例。 受信者ＤＢの一例。 コンテンツ管理テーブルの一例。 送信側でのログイン／ユーザ登録画面の一例。 ユーザ登録画面の一例（規約の確認）。 ユーザ登録画面の一例（宛先指定）。 ユーザ登録画面の一例（会員情報の入力）。 ユーザ登録画面の一例（入力内容の確認）。 ユーザ登録画面の一例（仮登録完了）。 受信側でのサーバ接続初期画面の一例。 送信者の承認画面の一例。 ユーザ本登録画面の一例。 メール作成用画面の一例。 作成したメールの一例。 宛先の追加・編集画面の一例。 携帯電話の登録・編集画面の一例。 携帯電話からアクセスする画面の一例。 携帯電話からのメール送信する画面の一例。 受信メール一覧表示画面の一例。 静止画一覧表示画面の一例。 動画・静止画再生画面の一例。 ダウンロード選択画面の一例。 ダウンロード実行確認画面の一例。 ダウンロード実行中画面の一例。 ダウンロード終了画面の一例。 送信者一覧表示画面の一例。 送信者承認画面の一例。 受け取り承認／拒否画面の一例。 コンテンツ配信システムの一実施例を示す全体構成図。 認証サーバ７０の内部構成の一例を示す図。 テレビ機器ＤＢの一例。 ワンタイムＩＤ管理テーブルの一例。 認証の処理フローを示す図。 機器識別ＩＤ対応テレビ機器ＤＢの一例。 機器識別ＩＤ対応ワンタイムＩＤ管理テーブルの一例。 機器識別ＩＤに関わる処理フローを示す図。 機器識別ＩＤ取得、確認画面の一例。 機器識別ＩＤ未取得時の機器識別ＩＤ取得、確認画面の一例。 機器識別ＩＤ削除画面の一例。 機器識別ＩＤ対応未読メールチェックテーブルの一例。 機器識別ＩＤ対応送信者ＤＢの一例。 機器識別ＩＤ対応受信者ＤＢの一例。 機器識別ＩＤ対応コンテンツ管理テーブルの一例。 認証サーバ８０の内部構成の一例を示す図。 会員ＤＢの一例。 会員ＩＤ対応テレビ機器ＤＢの一例。 会員ＩＤ対応ワンタイムＩＤ管理テーブルの一例。 会員ＩＤに関わる処理フローを示す図。 会員ＩＤ登録、確認画面の一例。 会員ＩＤ新規登録画面の一例。 会員ＩＤ削除画面の一例。 ユーザ登録画面の一例（会員ＩＤ対応宛先指定）。 「お知らせサービス」の送信時の処理フローを示す図。 機器識別ＩＤと会員ＩＤを入力するメッセージ入力画面の一例。 メッセージ送信確認画面の一例。 会員ＩＤ対応テレビ機器ＤＢの一例。 「お知らせサービス」の受信時の処理フローを示す図。 「お知らせ」メッセージ一覧画面の一例。 「お知らせ」メッセージ表示画面の一例。 「お知らせ」メッセージ会員パスワード入力画面の一例。

以下の実施形態では、送信端末をＰＣ、または携帯電話、受信端末をテレビとする。コンテンツとして、例えばビデオカメラで撮影した動画や、デジタルカメラ（デジカメ）で撮影した静止画が含まれる。これらの動画と静止画を合わせて映像と呼ぶ。テレビはメールアドレスを有しないため、製造の際、各テレビを特定する機器ＩＤをテレビ内に記憶させ、ユーザはテレビのリモコン等を使ってその機器ＩＤを知ることができる。送信者はその機器ＩＤをキーとして映像を送る。映像の送信と受信を制御するため、センタにサーバを設置しネットワークで接続する。ＰＣはこのサーバに送信者として会員登録する。その際、自分が映像を送りたい相手のテレビの機器ＩＤをも合わせて登録する。

テレビがネットワークを介してサーバにアクセスすると、画面には登録された送信者を承認する確認メッセージが表示される。受信者がこれを承認すると送信者が登録した内容が有効となり、サーバは送信者からの映像の預かりサービスを開始する。サーバは映像を預かると、登録された受信者のテレビ画面に映像が届いていることを表示する。受信者は所望の映像を選択すると、サーバからこれを受信し視聴することができる。

図１は、本実施例によるコンテンツ配信システムのを示す全体構成図の例である。本システムは、送信側端末（ＰＣ１０）と、受信側端末（テレビ２０）と、両者間のコンテンツ配信を中継する配信サーバ（サーバ３０）とが、インターネット等のネットワーク４に接続されて構成される。そして、メールソフトを有するＰＣ１０からメールソフトを有しないテレビ２０へ、送信者所有の映像コンテンツをサーバ３０を介して送信するものである。

送信者宅１にいる送信者はビデオカメラ１１やデジカメ１２で撮影した映像コンテンツ（以下、映像ファイル、ビデオとも呼ぶ）をＰＣ１０にコピーする。ルータ（図示せず）を経由してネットワーク４に接続し、センタ３にあるサーバ３０に映像を預ける。サーバ３０は送信者（ＰＣ１０）からの映像を預り、送信者が指定した受信者宅２のテレビ２０からのアクセスを待つ。テレビ２０がルータ及びネットワーク４を経由してセンタ３にあるサーバ３０に接続してきた場合、サーバ３０は映像が届いていることを示すメッセージを送り、テレビ２０の画面に表示する。その後、受信者はその映像を選択して受信し、視聴することができる。テレビ２０に記録装置（例えばハードディスク）が内蔵されていれば、映像のダウンロードも可能である。

サーバ３０には、受信側端末であるテレビ２０を特定する機能が必要となる。よって、サーバ３０を用いてコンテンツ配信サービスを行うセンタ３は、テレビ２０を製造した同一メーカが立ち上げ、運営することが効率的である。また、受信端末であるテレビ２０を識別するために、各テレビ２０の機器ＩＤをアドレスとして用いる。なお、送信者は自宅のＰＣ１０だけでなく、事前に登録しておいた携帯電話５０で撮影した映像ファイルをネットワーク４を介してサーバ３０に送信することも可能であり、これは実施例２で説明する。以下、センタ３（サーバ３０）の行うコンテンツ配信サービスを「ビデオお届けサービス」と呼ぶことにする。

次に、サーバ３０およびテレビ２０の内部構成を詳細に説明する。
図２は、サーバ３０の内部構成の一例を示す図である。
ネットワーク送受信部３１は、外部のネットワーク４に接続され、該ネットワーク経由でＰＣ１０やテレビ２０と通信を行う。

会員情報管理部３２は、未読メールチェックテーブル３３、送信者ＤＢ３４、受信者ＤＢ３５、テレビ機器ＤＢ３６、およびコンテンツ管理テーブル３７の各データベースやテーブルを有し、送信者と受信者の情報、およびコンテンツの預かり情報を保存している。ＰＣ１０やテレビ２０からアクセスがあった際に、関連するデータベースやテーブルを参照して、会員情報の確認や登録などの処理を行う。

例えば、送信者のＰＣ１０から会員仮登録が実行された場合には、未読メールチェックテーブル３３に、機器ＩＤ，ユーザＩＤ等の情報を登録する。テレビ２０から送信者の承認処理が実行された場合には、その内容に従って送信者ＤＢ３４および受信者ＤＢ３５の内容を更新する。また、テレビ２０からアクセスがあった場合には、テレビ２０に対して機器ＩＤの送信を要求しこれを取得する。取得した機器ＩＤを、テレビ機器ＤＢ３６の情報と照合し、正規のＩＤであるかどうかを確認する。不正な機器ＩＤの場合はこの時点で検出し、以後の処理を拒否する。コンテンツ管理テーブル３７はユーザから預かっているコンテンツを管理し、各ユーザとのサービス契約事項を保持する。

コンテンツ送受信部３８は、ＰＣ１０から映像コンテンツを受信し、またテレビ２０に映像コンテンツを送信する。コンテンツ格納部３９は、送受信する映像コンテンツを格納する。すなわち、ＰＣ１０からアップロードされた映像コンテンツをコンテンツ格納部３９に格納し、テレビ２０から映像の受信・視聴の要求、もしくは映像のダウンロードの要求があった場合には、コンテンツ格納部３９から映像コンテンツを読み出し、テレビ２０へ送信する。

図３は、テレビ２０の内部構成の一例を示す図である。
ネットワーク送受信部２１は、外部のネットワーク４に接続され、該ネットワーク経由でサーバ３０と通信を行う。ブラウザ部２２は、サーバ３０から送信されたＨＴＭＬやＢＭＬなどの形式で記述された情報に従って、メール画面や承認画面等の画面情報を描画し、表示部２７に出力する。動画再生部２３は、サーバ３０から送信されるコンテンツに含まれる静止画や動画ファイルを復号化し、静止画や動画像として再生し、表示部２７に出力する。

機器ＩＤ通知処理部２４は、サーバ３０からの要求に基づいて、機器ＩＤ保持部２５から当該テレビ２０に割り当てられた機器ＩＤ情報を読み出し、サーバ３０に通知する。機器ＩＤ保持部２５には、当該テレビ２０固有の機器ＩＤ情報が格納保持されている。この機器ＩＤ情報はテレビ２０の製造時に各端末毎に割り当てられ、機器ＩＤ保持部２５に書き込まれている。ユーザがこの機器ＩＤを知りたいときは、例えばリモコン操作により読み出して、表示部２７に表示することができる。

コンテンツ記録部２６は、例えばハードディスク記録装置であり、サーバ３０から受信した映像コンテンツをダウンロードし保存する。ユーザは保存した映像を必要なときに読み出し、動画再生部２３を通じて視聴することができる。記録部２６は内蔵でも外付けでも構わない。表示部２７は、ブラウザ２２、動画再生部２３および機器ＩＤ通知処理部２４から出力された映像や情報を画面に表示する。

図４は、本実施例のコンテンツ配信サービス（ビデオお届けサービス）の処理フローを示す図である。まず処理の概要をステップ順に説明する。

ステップＳ１０１：送信者は映像の受信者から、相手の受信端末（テレビ２０）の機器ＩＤとそのテレビ２０が接続されているサーバ３０のＵＲＬを取得する。あるいは逆に、受信者は映像の送信者に、テレビ２０の機器ＩＤとサーバ３０のＵＲＬを電話やＦＡＸで知らせてもよい。そのためテレビ２０の機器ＩＤ保持部２５には、機器を特定するための機器ＩＤが記録されている。この機器ＩＤは、映像送信の際のアドレスとして用いる。なおこの機器ＩＤは、Ｂ−ＣＡＳカードの番号と同様に、テレビの所有者はリモコン等を使って容易に知ることができるようにしておく。

ステップＳ１０２：送信者は上記の情報（テレビ２０の機器ＩＤとサーバ３０のＵＲＬ）を基に、ＰＣ１０からサーバ３０にアクセスし、送信者と受信者の情報を入力する。これを会員仮登録と呼ぶ。具体的には送信者情報として、送信者のメールアドレスをユーザＩＤとし、住所、氏名、表示される名前、生年月日、電話番号等を登録する。また受信者情報として、テレビ２０の機器ＩＤ、表示される名前を登録する。これらの情報は、サーバ３０のデータベースに仮登録される。

ステップＳ１０３：センタ３のサーバ３０は、仮登録された受信者のテレビ２０に対して、機器ＩＤを基に、会員の仮登録があったことを知らせる。これに対し受信者は仮登録の内容を確認して承認を行う。その際テレビ２０にはメールソフトがインストールされていないので、次のようにして通知する。サーバ３０の未読メールチェックテーブル３３には、仮登録があった機器ＩＤのフラグを立てておく。サーバ３０はあるテレビ２０からアクセスがあるとこのテーブルを参照し、アクセスしたテレビの機器ＩＤのフラグが立っているかどうか調べる。フラグが立っていれば、送信者データベース３４から送信者のユーザＩＤと氏名を調べて、「○○さんが映像ファイルを送ろうとしている」ことをテレビ２０に表示する。受信者は、表示されている送信者（○○さん）が所望の相手であればその送信を承認する。

ステップＳ１０４：受信者がテレビ２０に表示された送信者を承認すると、サーバ３０は仮登録された会員情報を本登録に変更する。また、受信者が承認したか否かの結果を送信者にメールで知らせる。メールアドレスは会員仮登録の際に登録されたメールアドレスを用いればよい。本登録することで、サーバ３０は登録された送信者から送られる映像の預かりサービスを開始する。すなわち、受信者が送信者を承認してくれるまでは、送信者はサーバ３０に映像を預けることができない。よって、サーバ３０は無駄な預かりサービスを回避することができる。

ステップＳ１０５：送信者はＰＣ１０を操作して、送信を承認した受信者を指定し、ビデオカメラ１１やデジカメ１２で撮影した映像をサーバ３０に送信（アップロード）する。サーバ３０は、ＰＣ１０から送られた映像をコンテンツ格納部３９に格納する。そして、指定された受信者から受信要求があるまで預かる。

ステップＳ１０６：サーバ３０は、預かっている映像の形式（ファイル形式）を、必要に応じてテレビ２０で表示できる形式に変換する。例えば動画の場合、ＰＣ１０で格納したファイル形式はＰＣ上では再生可能であっても、テレビ２０ではそのまま再生することができない場合がある。サーバ３０にて映像の形式を変換することで、テレビ２０の負担を軽減することができる。

ステップＳ１０７：受信者がテレビ２０からサーバ３０にアクセスすると、サーバ３０は未読メールチェックテーブル３３を調べる。アクセスしたテレビ２０の機器ＩＤに対して未読メールのフラグが立っていれば、受信者はそのメール（映像コンテンツ）をまだ受信していないことを意味する。その場合サーバ３０はテレビ２０に対し、映像が届いていることを知らせる。受信者は所望の映像を選択してサーバ３０から受信し、これをテレビ２０で視聴する。

ステップＳ１０８：テレビ１０がハードディスク等の記録装置２６を内蔵していれば、受信した映像を格納して保存（ダウンロード）することが可能である。また、保存した映像で不要なものがあれば、テレビ２０を操作して消去することも可能である。なお、映像の消去に関しては、サーバ３０に預けた状態の映像を、送信者がＰＣ１０を操作して消去することも可能である。すなわち、送信者と受信者の少なくとも一方は、送受信する映像を消去する権限を有する。

ステップＳ１０９：送信者は、次に送信すべき映像があれば、ステップＳ１０５に戻り、次の映像をサーバ３０に送信する。すなわち、ステップＳ１０１〜Ｓ１０４までの会員登録は初回のみで完了する。２回目からは不要として、登録された送信者と受信者の間では随時映像を送信することができる。

本システムによるコンテンツ配信サービスによれば、次のようなメリットがある。
（ａ）受信端末がテレビという家電品では、ＰＣと異なり、メールソフトのような追加のソフトを組み込むことが難しい。その理由として、開発・検証にかかるコストが高いことや、バージョンアップ時の対応が、過去製品との互換性の確認も含めて困難であることが挙げられる。これに対し本システムでは、テレビに対してメールソフトを組み込むことなく映像コンテンツを送受信することができる。
（ｂ）テレビという家電品では、ＰＣと異なり、お年寄り等も含め多様なユーザが取り扱う機会が多い。また、リモコンを使用するため入力手段も限られる。したがって、誰でも簡単手軽に取り扱えること、および誤操作なく取り扱えることが要求される。これに関し本システムでは、テレビを識別するために各機器に割り当てられた固有の機器ＩＤを使用することで、自アカウントを識別するための個人のＩＤの入力をする手間がなく、また間違い操作を防止することができる。
（ｃ）受信者が送信者を確認し承認した後に、サーバはその送信者からのコンテンツを預かり、受信者へ送信するようにした。よって受信者は、不特定多数の人からスパムメールのような不要なコンテンツを送り付けられることがない。また配信サーバは無駄な預かりを回避することができる。

以下、図４のコンテンツ配信サービスの各処理について詳細な説明を行う。
（１）機器ＩＤとＵＲＬの告知（ステップＳ１０１）
「ビデオお届けサービス」を提供するベンダーは、例えばテレビメーカーであれば、自社のホームページ、テレビのパンフレット、テレビに同梱されるチラシ等に、本サービスを実施するサーバ３０のアドレス（ＵＲＬ）を記述しておく。また、テレビの機器ＩＤは機器ＩＤ保持部２５に記録しておき、Ｂ−ＣＡＳカードの番号などと同様に、ユーザがリモコンの操作で簡単に知ることができるようにしておく。

この機器ＩＤはメールアドレスのように使われるＩＤである。送信者が入力を間違えても第三者に送らないように工夫することが望ましい。そのため、機器ＩＤそのものをユーザに提示する代わりに、誤入力を防止する為の処理を施した変換機器ＩＤを提示することが望ましい。例えば、仮に本来の機器ＩＤが３２ビット長だとして、これを８ビットずつに区切った４つの数値を加算してチェックサムを求める。そしてこのチェックサムの末尾８ビットを取り出して元の機器ＩＤに連結し、合計４０ビットの変換機器ＩＤを生成する。ユーザにはこの変換機器ＩＤを提示する。

このようにして生成した変換機器ＩＤは、仮に送信者が入力の際にＩＤの一部を誤って入力したとしても、チェックサムまで含めて第三者の変換機器ＩＤと一致する可能性は低く、またサーバ側でチェックサムを照合した場合に不一致になる可能性が高いので、誤ってそのまま第三者のテレビに送信される可能性が低くなり、安全性を増すことができる。

上記の変換処理を実施する場合には、テレビ２０においては、先に説明した図３の機器ＩＤ通知処理部２４で機器ＩＤを読み出した際に変換処理を行うことができる。また、サーバ３０側においても、同様に、図２の会員情報管理部３２においてテレビ２０から機器ＩＤを取得した後に、テレビ２０の変換処理と逆の変換処理を施すことにより、テレビ２０の機器ＩＤ保持部２５が保持する変換前の機器ＩＤを復元することが可能である。
なお、以下の説明で、特に実施例１、実施例２、実施例３においては、機器ＩＤとは、本来の機器ＩＤもしくは上記の変換機器ＩＤを指すものとする。

テレビの所有者は、ビデオを送って欲しい相手（家族、友人、親戚等）に自分のテレビの機器ＩＤとサービス業者のポータル（サーバ）のＵＲＬを電話やＦＡＸで伝え、「ビデオお届けサービス」への会員登録を依頼する。

（２）会員仮登録（ステップＳ１０２）
送信者は、受信者から取得した機器ＩＤとサーバのＵＲＬに基づき、「ビデオお届けサービス」への会員登録（仮登録）を実行する。送信者のＰＣ１０にはブラウザ２２が搭載され、以下の作業はブラウザで動作するものとする。ＰＣ１０から上記ＵＲＬにアクセスし、会員登録する。図９〜図１４は、会員登録時の表示画面を示す。

図９は、ビデオお届けサービスのトップ画面である。まだユーザＩＤを所有していない場合は、「ユーザ登録」ボタンを押下してユーザ登録を実施する。図１０は、規約、個人情報取扱い条件を表示する画面である。図１１は、送信先のテレビの機器ＩＤを入力する画面である。なお、この表示画面では、機器ＩＤの代わりにユーザに分かりやすい用語「宛先ＩＤ」を用いている。以下「宛先ＩＤ」は「機器ＩＤ」と同じ意味である。図１２は、受信者、送信者の情報を入力する画面である。図１３は、入力内容を確認する画面である。図１４は、仮登録が完了したことを示す画面である。

仮登録が完了すると、サーバ３０は未読メールチェックテーブル３３にその内容を登録する。図５は、未読メールチェックテーブル３３の一例を示す。テーブルには、機器ＩＤ毎に送信者として承認を待っている人がいるか否か、承認済みの送信者から新たな映像ファイルが送られているか否かを示すフラグを設けておく。この例では、機器ＩＤが「１２３４５６７」のテレビに対して、承認を依頼している送信者が２人いて、そのユーザＩＤ（ＩＤ１、ＩＤ２）が示されている。また、承認済みのユーザ（ＩＤ１）からのメール（実際には映像）が届いており、このテレビの受信者はそのメールをまだ読んでいないことを示している。

（３）受信者の承認と会員本登録（ステップＳ１０３、Ｓ１０４）
図１５は、受信者がテレビ２０からセンタ３のサーバ３０にアクセスする初期画面を示す。これはＰＣ１０でインターネットに接続したときの初期画面に相当するもので、テレビ２０にはアクセス先のアドレスを記憶させてある。画面ではビデオお届けサービスのことを「ビデオお届け」と表示している。サーバ３０は図５の未読メールチェックテーブル３３を参照し、以下の画面に、送信者として承認を待っている人の状況と、承認済みの送信者から送られている映像ファイルの状況を表示する。

送信者が会員仮登録を行い、受信者からの承認を待っている場合は、図１５で「ビデオお届けサービス」を選択する。受信者は、リモコンでカーソルを上下左右に移動させた後で、決定キーを押下したり、各サービスをリモコンのキー番号に対応させて、数字キーにより「ビデオお届け」サービスメニューを選択する。

図１６は、送信者の承認画面である。この例では、「タローさんが送信者として仮登録したので、それを承認して欲しい」ことを意味している。受信者は承認するか否かを決め、テレビのリモコンで「○＝承認」か「×＝拒否」を選択する。「△＝今は決めない」を選択した場合は、後で承認するか否かを決めることも可能である（図３２）。

また、承認済みのユーザが新たな映像ファイルを送っている場合も、図１５のように「新着メール１件」と表示し、新着映像があることを知らせる。そして、受信者に「ビデオお届け」を選択し受信一覧を表示するように誘導する。なお、表示画面では「メール」という用語を用いている。テレビ２０にはメールソフトはインストールされていないので、技術的にはメールを受信するわけではないが、ユーザ（送信者、受信者）の理解しやすさを考えて「メール」という表現を使っている。

受信者が送信者を承認すると、送信者は会員仮登録から本登録を行い、サーバ３０はその内容を送信者ＤＢ３４と受信者ＤＢ３５に追加する。

図６は、送信者ＤＢの一例を示す。ユーザＩＤから生年月日までは仮登録の内容、本登録時は受信者数＝１で受信を承認（送信することを許可）してくれた受信者のテレビの機器ＩＤ（仮登録時に入力済み）を記録する。また、本登録時にユーザが入力したクレジットカードの番号、有効期限、入会年月日を追加登録する。携帯電話から送信する場合もあるので、欄だけを設けておいて、追加された場合に登録する。図６で受信者数＝３となっているのは、本登録の後、受信者が２人増加したためである。

図７は、受信者ＤＢの一例を示し、これも本登録時に追加登録する。当初、送信者数＝１とし、送信することを許可した送信者のユーザＩＤ（この場合はユーザＩＤ５）を登録しておく。その後、別の送信者に送信を許可した場合はユーザ数をインクリメントし、及びそのユーザＩＤ（この場合はユーザＩＤ６）を追加する。受信者ＤＢの個人を特定する情報としては、機器ＩＤと表示される名前だけでも実現可能であるが、今後受信者課金に変更することを考慮した場合は、住所、氏名、電話番号、生年月日も入力した方が変更は容易である。図１２の登録画面でこれらの情報も入力してもらえばよい。図７にはこれらの情報も付加した内容を示す。送信者ＤＢ、受信者ＤＢが追加登録されれば、送信者は受信者に対して、メールを送ることができる。

受信者が送信者を承認すると、サーバ３０は送信者に「承認されました」というメールを送るとともに本登録できるＵＲＬを知らせる。送信者はＰＣ１０でこのＵＲＬを入力し、本登録画面にアクセスする。図１７は本登録画面を示す。パスワード、及びパスワードを忘れたときのための質問と答えを設定する。コースは定額基本コース、定額上級コース、従量コースの３通りを設定し、送信者に選択してもらう。定額コースは決まった容量のハードディスク容量が使えて、定額の費用が発生する。上級コースは利用できるハードディスク容量が大きい。一方、従量コースは１回につき、決まった容量までであれば、決まった料金が発生し、所定期間後に、サーバ３０が自動的に消去する。本実施例では送信者課金を想定しているため、本登録でクレジットカード番号、有効期限、セキュリティコードを入力してもらう。クレジットカードの情報は前記（２）の会員仮登録の際入力してもらうことも可能であるが、カードの認証が済んだにもかかわらず、受信者から承認されなければ、課金が発生するのを防止しなければならない。よって本実施例では、課金してもよい本登録時にクレジットカードの情報を入力してもらうことにする。

（４）ＰＣから映像ファイルのアップロード（ステップＳ１０５）
ＰＣ１０から図９の画面でログインすると、図１８のメール作成用画面が表示される。ここで「メールを作成」を選択して、受信者、添付ファイルを選択する。画面中央に、「宛先（必須）」の枠内に承認してくれた受信者の名前を表示する。送信者はこの中から受信者を選択する。チェックボックスを選択すると、チェックマークを表示する。

図１９は作成したメールの内容を示す。画面上方の「ファイル追加」ボタン２０１を押下すると、ＰＣ１０に格納されたファイルを選択する画面２０２がポップアップ表示される。図１９では表現の都合上、画面の下部にファイル選択画面２０２を示している。その中から送信したいファイルを選ぶ。そのファイルはサムネールとともにファイル名、作成日付とともにＰＣ１０の画面にファイルリスト２０３として表示される。図１９では添付ファイルを３個選択した例を示す。また、宛先リスト２０４は、リストの中から２人を送信先として選択している。なお、リスト２０４の中で「受取中止」のマークがついている受信者は、この送信者を過去に一旦承認したが、ユーザの意向により現在は受け取り拒否に設定していることを示している。

ここで、送信する映像ファイルの統合について説明する。ビデオカメラ１１で撮影を行うと、録画開始から一時停止までの１シーンで１つの動画ファイルになる場合がある。その場合、ビデオカメラ１１からＰＣ１０に映像ファイルをコピーする際に、複数ファイルが存在し、運動会や学芸会といった１つのイベントが複数のファイルで構成されることになる。１つのイベントについて関連性のあるファイルは纏めて取り扱うことが多いと考えられる。したがってこのような場合、一般には、送信者は１メールで複数ファイルをアップロードする必要がある。

一方、受信者の立場に立って考えると、１つのメールで上記のような細切れのファイルが複数本送信されてきた場合、それらを再生する際に、細切れのファイル１つ１つに対して、再生の操作をその都度行うより、一度の操作で全体を順番に再生できたほうが便利である。その点を考慮し、本実施例では、送信者が複数のファイルを一度にアップロードする場合、サーバ３０ではそれらのファイルを統合するものとする。本実施例では、送信者が図１９にてファイルを添付した順序にしたがって、サーバ３０はファイルを統合する。図１９のファイルリスト２０３にファイルを登録した後でも、ファイルを選択して、ファイルの順序を入れ替えることができるようにしておく。受信者の再生の際には、上記順番にしたがって、統合されたファイルを再生する。

また本実施例では、映像ファイルには動画と静止画とが含まれる。これらが混在してアップロードされることがあるので、以下のように扱う。
（ａ）送信するファイルが動画だけの場合は、サーバ３０で添付の順番通りにつなぎ、１つの動画ファイルにする。
（ｂ）送信するファイルが静止画だけの場合は、複数ファイルのまま扱い、統合はしない。１ファイル毎アイコンのようにテレビに表示する。
（ｃ）送信するファイルが動画と静止画が混在する場合は、動画は添付の順番通りにつなぎ、静止画ファイルがあるまで１つの動画ファイルにする。静止画は１ファイル毎に扱う。送信者が添付した順に表示する。動画なら１ファイル再生し、静止画になれば数秒間表示した後、次のファイルを表示する（静止画なら表示、動画なら再生）。

なお上記（ａ）〜（ｃ）では、動画はできる限り１ファイルにまとめる、と述べたが、統合せずに１ファイルずつのまま保持し、添付ファイル順に１つずつ再生を行ってもよいことは言うまでもない。

また、１つのメールで動画、静止画の混在を認めない、という制約を課すこともできる。その場合、動画、静止画のどちらを送るのかをあらかじめ選択してもらい、ファイル拡張子をチェックして、間違った形式のファイルを添付された場合は「そのファイルは動画（静止画）ではありません」と送信者に警告を発し、添付を受け付けないようにする。図１９には、「動画・静止画ファイルではありません」というエラーメッセージ２０５の例を示した。動画・静止画両方を扱う場合は、それ以外のファイルが添付されれば、その旨を送信者に通知し、動画（静止画）しか扱わない場合は、それ以外のファイルが添付された場合にエラーメッセージとして送信者に通知するようにする。

また、新たな受信者にビデオを送りたい場合は、図１８で「宛先の追加・編集」を選択すると、図２０の宛先の追加・編集画面が表示される。送信者は、新たな受信者の情報を入力し、承認を待つ。また、住所、氏名等、個人の情報まで入力してもらう場合は、図２０から図１２の画面に切替えて、これらの情報を入力する項目を設定すればよい。

（５）映像形式の変換（ステップＳ１０６）
動画の場合、ＰＣ１０で格納したファイル形式は、たとえＰＣ上では再生可能であっても、テレビ２０でそのままで再生できるファイル形式であるとは限らない。テレビで表示できるファイル形式に変換するために、サーバ３０は映像形式の変換を行う。

動画ファイルは一般的に次のような構成になっている。まず映像信号を圧縮符号化した映像エレメンタリーストリームと、音声信号を圧縮した音声エレメンタリーストリームが存在する。次にそれらをパケット化してマルチプレクス（多重化）し、システムストリームとする。このシステムストリームが動画ファイルである。なおこの際、映像や音声に関する権利情報その他の補助的な情報もシステムストリーム中に一緒に多重化することもある。

ＰＣ１０で格納したファイル形式を、テレビで表示できるファイル形式に変換する場合には、次のように行う。まずＰＣ１０で格納した形式のシステムストリームをデマルチプレクス（多重分離）し、映像と音声の各エレメンタリーストリームを得る。次に、映像のエレメンタリーストリームをデコードし、引き続き、テレビで対応できる符号形式のエレメンタリーストリームに再エンコードする。音声に関しても同様にデコードおよび再エンコードする。次に、再エンコードの結果得られた映像および音声のエレメンタリーストリームを、テレビで対応できる形式のシステムストリームとしてマルチプレクスし、作成する。このようにして、ＰＣ１０で格納したファイル形式を、テレビで表示できるファイル形式の動画ファイルに変換する。

（６）映像の受信と視聴（ステップＳ１０７）
受信者は図１５の画面でビデオお届けサービスを選択し、図１１の送信者承認画面を経由して、図２４の受信メール一覧表示画面を表示する。リモコンを使ってカーソルをアイコン＃１〜＃９のいずれかに移動して所望のメールを選択し、決定ボタンを押下すると、選択したメールが静止画の集合の場合は、図２５の画像一覧表示画面が表示される。アイコン＃１〜＃９のいずれかに移動して所望の画像を選択すると、図２６のように選択した画像が拡大表示される。また、図２４で選択した映像コンテンツが動画の場合は、画面全体に動画が再生される。もちろん、図２６のように画面の一部に動画を表示しても良い。

（７）映像のダウンロードと消去
テレビ２０がＨＤＤ等の記録装置２６を有していれば、サーバ３０にある映像コンテンツをダウンロードして記録することが可能である。図２４で「選んでダウンロード」を選択すると、図２７のダウンロード選択画面が表示される。受信者が所望するアイコンを選択して、実行ボタンを押下すれば、図２８の確認画面が表示され、「はい」を選択すれば、図２９のダウンロード実行画面が表示され、ＨＤＤに格納保存される。正常終了すると図３０のダウンロード終了画面を表示し、異常終了した場合は、ダウンロードに失敗したことを画面に表示する。

本実施例では、コンテンツを消去する権限を受信者に与えているので、図２４に「選んでゴミ箱へ」が表示されている。このボタンが押下されれば、ダウンロードと同様の手順で、アイコンを選択して、コンテンツを消去することが可能である。

コンテンツ消去の権限を送信者に与えることももちろん可能である。送信者がＰＣの操作履歴からサーバに預けた映像ファイルを消去すればよい。前記（５）でサーバ３０での映像変換処理を述べた。この変換処理に合わせ、消去はどのタイミングでどちらの形式のファイルを消去すべきかを考慮する。ある１つの映像ファイルに関して、ＰＣフォーマットをファイルＡからテレビフォーマットＢに変換する例を考える。サーバ３０はＡを預かり、Ｂに変換した後、図５の未読メールチェックテーブル、及び図８のコンテンツ管理テーブルを更新し受信者の視聴を可能にする。送信者が消去コマンドを発行するタイミングに従い、下記のように処理するのがよい。

（ａ）ファイルがまだＡのままの場合は、Ａを消去し、変換処理は実施しない。
（ｂ）ＡからＢへの変換途中の場合、変換処理は中止し、Ａ及び作成途中のＢも消去する。
（ｃ）Ｂへの変換終了後の場合、ＡもＢも消去し、未読メールチェックファイル、コンテンツ管理テーブルも更新する。

上記のようにファイルの消去は送信者、受信者のそれぞれ、あるいは両方に権限を与えることが可能である。

（８）受け取り（ステップＳ１０７）の一時拒否
前記図２４で「送信者一覧」を選択すると、図３１の送信者一覧画面が表示される。また、図１６で承認も拒否もしないで「今は決めない」を選択し、ビデオお届けサービスを選択し、図２４で「送信者一覧」を選択すると、承認待ちの送信者の情報も含まれて図３１に表示される。このテレビの所有者は送信者として五郎、花子の２人を承認した後、花子からの受信を一時拒否しているところに、タローから送信者として承認依頼を受けている状態である。タローにカーソルがある状態で決定ボタンを押下すると、図３２の送信者承認画面が表示され、「○＝承認」か「×＝拒否」を選択する。また、五郎にカーソルがある状態で決定ボタンを押下すると、図３３の受信停止画面が表示され、「ビデオを受け取る」という状態から「ビデオを受け取らない」という状態に変更することが可能である。逆に、図３１で花子にカーソルがある状態で決定ボタンを押下すると、図３２と同様、花子用の画面が表示され、「ビデオを受け取らない」状態から「ビデオを受け取る」状態に変更することが可能である。

本実施例ではテレビ画面でパスワードの入力を不要としたが、送信者をテレビ画面で承認するときに、受信者にパスワードを設定してもらうことも可能であることは言うまでもない。ビデオの受け取りの一時拒否や受け取り承認の際にパスワードを入力してもらう、という使い方がある。映像によってペアレンタルロックをかけたい、と送信者が判断した場合は、ペアレンタルロックをかけて送信し、受信者が設定したパスワードを入力しなければその映像を見ることができない、ということが可能となる。また、送信者がメールを送信するときに、パスワードを設定して送信すれば、受信者はそのパスワードを入力しなければ見ることができない、という運用することももちろん可能である。図１９にはパスワードを設定、ペアレンタルロックを設定する項目を加えた例を示した。

本実施例は、送信者は携帯電話５０を用いてサーバ３０へアップロードを行う場合である。
図１に示したコンテンツ配信システムにおいて、送信者は会員登録することで、携帯電話５０で撮影した映像を承認してくれた受信者のテレビ２０に送信することができる。この場合の映像のアップロードは、携帯電話にインストールされているメールソフトを使用する。その理由は、前記（４）と同じように実際はメールを使わずに、送り先を指定してサーバ３０に映像ファイルをアップロードする方法も可能であるが、キャリア、携帯電話のメーカ毎に仕様が異なる可能性が高いため、テスト工数が多数発生することが考えられる。そのため本実施例では独自仕様を避け、携帯電話にインストールされているメールソフトをできるだけ使って、サーバ３０に映像ファイルを送る方式とする。

まず送信者は、送信端末である携帯電話５０をＰＣ１０から登録する。図１８、図１９の画面左側の「携帯電話の登録、編集」を選択すると、図２１の携帯電話の登録画面が表示される。ここでは１つの送信者ＩＤに対して、９台の携帯電話のメールアドレスが登録されていることを示す。家族の人数、１人で複数台の携帯電話を所有することを考えて最大１０個のアドレスの登録を許可している。空欄に携帯電話のＥメールアドレスとその所有者の名前を入力し、送信ボタンを押下する。

携帯電話を用いた送信方法として案１，案２，案３が可能である。
＜案１＞すべての受信者にメールアドレスを割り当てる方法。
図２２は、携帯電話５０からサーバ３０にアクセスするためのＵＲＬを得るためのＰＣ画面である。実施方法は下記３通り考えられる。

（ａ）携帯電話３０にＵＲＬをメールで送信する。図２２でＵＲＬを送って欲しい携帯電話５０のチェックボックスを選択すると、サーバ３０はログインできるためのＵＲＬをその携帯電話５０に送信する。
（ｂ）ＱＲコード（登録商標）をＰＣ画面に表示し、携帯電話５０でこのコードを読み込みＵＲＬを入手する。
（ｃ）携帯電話５０からＵＲＬを手入力する。

（ａ）〜（ｃ）で携帯電話３０はＵＲＬを入手、入力できる。サーバ３０に携帯電話５０からのアクセスを受け付けるＷｅｂ画面を準備しておき、携帯電話３０はこのＵＲＬにアクセスし、ログインする。

図２３は、携帯電話５０を使ってログインする画面を表示する。ビデオお届けサービス用に取得したユーザＩＤとパスワードでログインする。サーバ３０は送信者ＤＢ３４からこの送信者が送信できる受信者の一覧を表示する。ここには機器ＩＤを表示するのではなく、送信者が登録した受信者の名称（図１２「この宛先の名前」）を表示する。サーバ３０はあらかじめ受信者一人ずつに対応したＥメールアドレスを割り当てて送信者ＤＢ３４、受信者ＤＢ３５に記憶しておく。送信者は携帯電話５０の画面に表示された中から送り先を選択するとメーラーが起動し、ＴＯ（宛先）にこの人のメールアドレスが入力される。以下はメールを送る方法で、映像ファイルを添付して、メールを送信する。テレビにはメールソフトが存在しないため、映像ファイルは実際にはサーバ３０に送られる。サーバ３０は受信者のＥメールアドレスと受信者ＤＢからどの機器ＩＤに送られたものか判断する。以下、サーバ３０は映像ファイルを預かっておく。

＜案２＞メールアドレスはサーバ３０の１つだけでの実現方法。
案１はすべての受信者にメールアドレスを割り当てるものであるが、案２はメールアドレスはサーバ３０が有する１つだけとする。図６、図７に受信者Ｅメールアドレスを記述したが、案２では存在しない。図２３で受信者Ｐ１〜Ｐ９の中から選択した場合、誰を選んでも、サーバ３０のメールアドレスを宛先に指定して携帯電話のメーラーを起動させる。サーバ３０は受信者Ｐ１〜Ｐ９を認識し、受信者ＤＢから送信者が送りたい相手の機器ＩＤを調査し、メール本文にその受信者の機器ＩＤを記述する。メールがサーバ３０に到着すると、メール本文に書いてある機器ＩＤを認識し、映像ファイルを預かっておく。

＜案３＞携帯電話に受信者のメールアドレスを送ってもらう方法。
案１と同様にすべての受信者にメールアドレスを割り当てておくが、案３ではサーバ３０に携帯電話３０からのアクセスを受け付けるＷｅｂ画面を準備せず、携帯電話３０が有するメールソフトのみで映像ファイルを送信する。図２２のように送信に使いたい携帯電話のチェックボックスにチェックを入れ、「携帯電話からの送信に使用する宛先メールアドレスを携帯電話に送る」というボタンを用意する（図２２では図示せず）。送信者がこのボタンを押下すると、サーバ３０は送信者ＤＢからその送信者が送ることができる受信者を調査し、選択した携帯電話にサーバ３０が割り当てた受信者のメールアドレス及びその受信者の名称が送られる。送信者は携帯電話でこの中からメールアドレスを選択し、メーラーを起動させる。

案１、案３ではテレビはメールソフトを有していないにもかかわらず、送信者はメールを送るのと同様の手順でメールを送るが、実際はサーバ３０に送る。これらテレビに割り当てられたメールアドレスはセキュリティ保護のため、送信者が容易に変更できることが望ましい。図２１、図２２で画面左側に表示されている「宛先の追加・編集」を選択すると、図２０が表示され、この画面で宛先ＩＤ、宛先名称の変更、削除、及び（サーバ３０から割り当てられた）メールアドレスを変更することができる。案２の場合もメーラーを起動する場合、サーバ３０のアドレスを定期的に変更して送信者に伝えることが望ましい。

携帯電話３０からの送信はテスト工数の観点から標準のメールソフトを使う例を述べた。一方ＰＣからアップロードする場合は、サーバ３０にＰＣからのアクセスを受け付けるＷｅｂ画面を用意して、その画面で映像ファイルを送信する例を述べた。この方が、映像ファイルの順序を変更できたり、各ファイルでの代表的な場面をサムネール表示したり、使い勝手がよい。ＰＣ１０で送る場合も携帯電話３０と同様、ＰＣ１０にインストールされているメールソフトを使ってもよいことは言うまでもない。

本実施例では、「ビデオお届けサービス」に対する課金方法について説明する。料金のプランとして定額制と従量制の両方がある。定額制の場合は一定容量までが一定の価格であり、１ケ月所定の料金を払えば、所定の容量のハードディスクを割り当てられる。一方、従量制の場合は１回いくらである。例えば、１回５ＧＢまで５００円とし、受信者が見ようが見まいが、２週間でサーバ３０が強制的に消去する、という運用方法が考えられる。運営者はハードディスク容量を効率的に利用したいので、預かったコンテンツは早く受信者に届け、受信者が消去してくれればサーバ３０を効率的に運用できる、というメリットがある。そのため、従量制の場合は、図２４の画面を表示する前に図８のコンテンツ管理テーブルを確認し、従量性で預けられた映像ファイルを特定し、そのファイルの上に「○月○日までに消去されれば、お預かり費用を半額にします」というメッセージを表示することもできる。ハードディスク内蔵テレビを有する受信者は早くダウンロードし、消去すれば送信者は料金が軽減され、運営者はハードディスクの効率的な運用ができる、という効果がある。

本実施例では送信者課金を前提にしたが、受信者課金も可能である。その場合、ユーザ仮登録の場合、（１）送信者課金、（２）受信者課金、（３）基本は送信者であるが期間延長した場合は受信者課金、の３通りの中からどれかを選んでもらえばよい。（２）、（３）の場合は本登録の前に、受信者に書類を郵送し、口座引き落としの手続きやクレジットカード番号、有効期限を登録してもらう、等の手続きを行えばよい。図２４を表示する際に、図８で有効期限の迫った映像ファイルの上には、「有効期限○月○日まで」と表示し、受信者が再生した後や、その映像ファイルにカーソルがある状態で「受信者課金に変更しますか？１ケ月○○円で○ギガバイトまでお預かりできます」と表示して、受信者課金に誘導することも可能である。仮登録時に、（２）受信者課金、（３）期間延長した場合は受信者課金、と選択してあれば、課金手続きは済んでいるのでそのまま実行し、（１）送信者課金、の場合のみ上記の手続きをすれば受信者課金に切替えることが可能である。受信者のテレビがハードディスクを有していないがもう少し見たい映像があれば、受信者が負担して見たい、という場合に有効な方法である。

ＰＣ１０の操作でコースの変更（定額制、従量制）や会員の退会、等、可能なことは言うまでもない。

前記課金方法は、後述のサーバ構成による実施例においても同様に適用可能である。

図３４は、本実施例によるコンテンツ配信システムを示す全体構成図の例である。本システムは、送信側端末（ＰＣ１０）と、受信側端末（テレビ２０）と、両者間のコンテンツ配信を中継する配信サーバ（配信サーバ３０）と、認証サーバ（認証サーバ７０）が、インターネット等のネットワーク４に接続されて構成される。そして、メールソフトを有するＰＣ１０からメールソフトを有しないテレビ２０へ、送信者所有の映像コンテンツを配信サーバ３０を介して送信するものである。以下、センタ３（配信サーバ３０）の行うコンテンツ配信サービスを「ビデオお届けサービス」と呼ぶことにする。

送信者宅１にいる送信者はビデオカメラ１１やデジカメ１２で撮影した映像コンテンツ（以下、映像ファイル、ビデオとも呼ぶ）をＰＣ１０にコピーする。ルータ（図示せず）を経由してネットワーク４に接続し、センタ３にある配信サーバ３０に映像を預ける。配信サーバ３０は送信者（ＰＣ１０）からの映像を預かり、送信者が指定した受信者宅２のテレビ２０からのアクセスを待つ。テレビ２０がルータ及びネットワーク４を経由してセンタ３にある認証サーバ７０（ここでは全てのサービスの入り口として稼動するものとして説明するが他に専用の入り口サーバがあっても良い）に接続し、受信者が「ビデオお届けサービス」を選択すると、テレビ２０が認証サーバ７０から該サービスのＵＲＬと同時にワンタイムＩＤを受け取り、「ビデオお届けサービス」の配信サーバ３０に接続し、ワンタイムＩＤを渡す。配信サーバ３０は、テレビ２０より受け取ったワンタイムＩＤを認証サーバ７０へ渡し、当該の受信者の機器ＩＤを受け取り、送信者から預かった受信者の機器ＩＤと整合が取れれば配信サーバ３０は映像が届いていることを示すメッセージを送り、テレビ２０の画面に表示する。その後、受信者はその映像を選択して受信し、視聴することができる。テレビ２０に記録装置（例えばハードディスク）が内蔵されていれば、映像のダウンロードも可能である。

本実施例のシステムでは、受信端末であるテレビ２０を識別するために、各テレビ２０の機器ＩＤをアドレスとして用いる。なお、送信者は自宅のＰＣ１０だけでなく、事前に登録しておいた携帯電話５０で撮影した映像ファイルをネットワーク４を介して配信サーバ３０に送信することも可能であり、これは実施例５で説明する。

次に、配信サーバ３０、認証サーバ７０およびテレビ２０の内部構成を詳細に説明する。配信サーバ３０の内部構成は、図２のサーバ３０同じである。 ネットワーク送受信部３１は、外部のネットワーク４に接続され、該ネットワーク経由で認証サーバ７０やＰＣ１０やテレビ２０と通信を行う。

会員情報管理部３２は、未読メールチェックテーブル３３、送信者ＤＢ３４、受信者ＤＢ３５、テレビ機器ＤＢ３６、およびコンテンツ管理テーブル３７の各データベースやテーブルを有し、送信者と受信者の情報、およびコンテンツの預かり情報を保存している。ＰＣ１０やテレビ２０からアクセスがあった際に、関連するデータベースやテーブルを参照して、会員情報の確認や登録などの処理を行う。

図３５は、認証サーバ７０の内部構成の一例を示す図である。

ネットワーク送受信部７１は、外部のネットワーク４に接続され、該ネットワーク経由で配信サーバ３０やＰＣ１０やテレビ２０と通信を行う。

会員情報管理部７２は、テレビ機器ＤＢ７６、ワンタイムＩＤ管理テーブル７７の、データベースやテーブルを有し、テレビ機器の情報、および加入しているサービス情報を保存している。テレビ２０や、サービスサーバ（例えば、配信サーバ３０）からアクセスがあった際に、関連するデータベースやテーブルを参照して、機器情報の確認や登録などの処理を行う。

テレビ２０から初回のアクセス時に、機器ＩＤを登録する。サービスを選択した際に、該機器ＩＤと選択したサービスＩＤをリンクしてテレビ機器ＤＢへ登録する。

例えば、送信者のＰＣ１０から配信サーバ３０へ会員仮登録が実行された場合には、未読メールチェックテーブル３３に、機器ＩＤ，ユーザＩＤ等の情報を登録する。テレビ２０から送信者の承認処理が実行された場合には、その内容に従って送信者ＤＢ３４および受信者ＤＢ３５の内容を更新する。また、テレビ２０からアクセスがあった場合には、認証サーバ７０から発行されたワンタイムＩＤをテレビ２０から取得して、認証サーバ７０へワンタイムＩＤを照会し、テレビ２０に対して機器ＩＤを取得する。この手続きで同時にワンタイムＩＤが不正か否かも確認できる。取得した機器ＩＤを、テレビ機器ＤＢ３６の情報と照合し、正規のＩＤであるかどうかを確認する。不正な機器ＩＤの場合はこの時点で検出し、以後の処理を拒否する。コンテンツ管理テーブル３７はユーザから預かっているコンテンツを管理し、各ユーザとのサービス契約事項を保持する。

コンテンツ送受信部３８は、ＰＣ１０から映像コンテンツを受信し、またテレビ２０に映像コンテンツを送信する。コンテンツ格納部３９は、送受信する映像コンテンツを格納する。すなわち、ＰＣ１０からアップロードされた映像コンテンツをコンテンツ格納部３９に格納し、テレビ２０から映像の受信・視聴の要求、もしくは映像のダウンロードの要求があった場合には、コンテンツ格納部３９から映像コンテンツを読み出し、テレビ２０へ送信する。

図３は、テレビ２０の内部構成の一例を示す図である。ネットワーク送受信部２１は、外部のネットワーク４に接続され、該ネットワーク経由で認証サーバ７０や配信サーバ３０と通信を行う。ブラウザ部２２は、認証サーバ７０や配信サーバ３０から送信されたＨＴＭＬやＢＭＬなどの形式で記述された情報に従って、メール画面や承認画面等の画面情報を描画し、表示部２７に出力する。動画再生部２３は、配信サーバ３０から送信されるコンテンツに含まれる静止画や動画ファイルを復号化し、静止画や動画像として再生し、表示部２７に出力する。

機器ＩＤ通知処理部２４は、機器ＩＤ保持部２５から当該テレビ２０に割り当てられた機器ＩＤ情報を読み出し、認証サーバ７０に通知する。機器ＩＤ保持部２５には、当該テレビ２０固有の機器ＩＤ情報が格納保持されている。この機器ＩＤ情報はテレビ２０の製造時に各端末毎に割り当てられ、機器ＩＤ保持部２５に書き込まれている。ユーザがこの機器ＩＤを知りたいときは、例えばリモコン操作により読み出して、表示部２７に表示することができる。

コンテンツ記録部２６は、例えばハードディスク記録装置であり、配信サーバ３０から受信した映像コンテンツをダウンロードし保存する。ユーザは保存した映像を必要なときに読み出し、動画再生部２３を通じて視聴することができる。記録部２６は内蔵でも外付けでも構わない。表示部２７は、ブラウザ２２、動画再生部２３および機器ＩＤ通知処理部２４から出力された映像や情報を画面に表示する。

本実施例のコンテンツ配信サービス（ビデオお届けサービス）の処理フローを図４を用いて説明する。本実施例の処理は実施例１の処理とほぼ同じであり、本実施例と実施例１との差分のみ説明する。なお、図４のフローの中で、実施例１でいうサーバ３０は配信サーバ３０と読み替える。

ステップＳ１０１〜ステップ１０６は実施例１と同じである。

ステップＳ１０７：受信者がテレビ２０から認証サーバ７０にアクセスすると、認証サーバ７０からワンタイムＩＤが発行されるので、それを配信サーバ３０へアクセス時に送信し、配信サーバ３０は、認証サーバ７０へテレビ２０から受け取ったワンタイムＩＤを送信し、機器ＩＤを照会してこの機器ＩＤを受け取る。配信サーバ３０は、この機器ＩＤから未読メールチェックテーブル３３を調べる。アクセスしたテレビ２０の機器ＩＤに対して未読メールのフラグが立っていれば、受信者はそのメール（映像コンテンツ）をまだ受信していないことを意味する。その場合配信サーバ３０はテレビ２０に対し、映像が届いていることを知らせる。受信者は所望の映像を選択してその映像を配信サーバ３０から受信し、これをテレビ２０で視聴する。

ステップＳ１０８〜ステップＳ１０９は実施例１と同じである。 本実施例によるサーバ構成によるサービス構築においては、実施例１のサーバ構成でのメリットに加えて、さらに以下のメリットがある。
（ｄ）テレビ機器専用の管理サーバとして認証サーバを立てることにより、追加されるサービス用サーバへ高負荷な処理を任せることができ、多様なサービスの追加が可能となる。
（ｅ）機器ＩＤを認証サーバにて管理することで、認証サーバが管理する情報もシンプルで無駄がなくなり、また、配信サーバも当該のサービス専用の情報を管理することに専念でき、こちらも無駄がなくなる。これによりサービスの管理が容易となる。
（ｆ）テレビ機器からのアクセスを一本化（本実施例では認証サーバを入り口として扱っている）することで、不正なサービスを抑止することができるばかりでなく、サービスが必ず認証サーバにて機器ＩＤを照会することで二重のチェックによる安全なサービス提供が可能となる。

以下、図４のコンテンツ配信サービスの各処理について詳細な説明を行う。本実施例の処理は実施例１の処理とほぼ同じであり、本実施例と実施例１との差分のみ説明する。

（１）機器ＩＤとＵＲＬの告知（ステップＳ１０１）
実施例１に加え、本実施例の認証サーバ７０では、図３５の会員情報管理部７２においてテレビ２０から変換機器ＩＤを取得した後に、テレビ２０の変換処理と逆の変換処理を施すことにより、テレビ２０の機器ＩＤ保持部２５が保持する変換前の機器ＩＤを復元することが可能である。会員情報管理部７２は初回アクセス時に、復元した機器ＩＤをデータベースへ登録する。図３６に前記テレビ機器ＤＢの一例を示す。テレビ機器ＤＢでは、各機器ＩＤと利用しているサービスＩＤを管理している。また、配信サーバ３０から機器ＩＤ照会のために利用されるワンタイムＩＤは、会員情報管理部７２が機器ＩＤと、サービスＩＤとリンクしてユニークなＩＤとして発行、削除管理する。図３７は、このワンタイムＩＤの管理テーブルを示す。

テレビの所有者は、ビデオを送って欲しい相手（家族、友人、親戚等）に自分のテレビの変換機器ＩＤとサービス業者のポータル（サーバ）のＵＲＬを電話やＦＡＸで伝え、「ビデオお届けサービス」への会員登録を依頼する。

（２）会員仮登録（ステップＳ１０２）
送信者は、受信者から取得した変換機器ＩＤとサーバのＵＲＬに基づき、「ビデオお届けサービス」への会員登録（仮登録）を実行する。送信者のＰＣ１０にはブラウザ２２が搭載され、以下の作業はブラウザで動作するものとする。ＰＣ１０から上記ＵＲＬにアクセスし、会員登録する。なお、配信サーバ６０は、送信者の入力した変換機器ＩＤを機器ＩＤへ復元した後これを登録する。図９〜図１４は、会員登録時の表示画面を示す。この表示画面では、変換機器ＩＤの代わりにユーザに分かりやすい用語「宛先ＩＤ」を用いている。以下「宛先ＩＤ」は「変換機器ＩＤ」と同じ意味である。その他会員登録についての説明は実施例１と同様のため割愛する。

（３）受信者の承認と会員本登録（ステップＳ１０３、Ｓ１０４）
受信者が送信者を承認すると、送信者は会員仮登録から本登録を行い、配信サーバ３０はその内容を送信者ＤＢ３４と受信者ＤＢ３５に追加する。

図６は、送信者ＤＢの一例を示す。ユーザＩＤから生年月日までは仮登録の内容、本登録時は受信者数＝１で受信を承認（送信することを許可）してくれた受信者のテレビの機器ＩＤ（仮登録時に入力された変換機器ＩＤを機器ＩＤへ変換済み）を記録する。その他は実施例１と同じである。
（４）ＰＣから映像ファイルのアップロード（ステップＳ１０５）
アップロードについては、実施例１と同様である。

（５）映像形式の変換（ステップＳ１０６）
+映像の変換については実施例１と同様である。

（６）映像の受信と視聴（ステップＳ１０７）
受信者はテレビ２０で認証サーバ７０（ここではポータルサイトを兼ねている）へ接続する。テレビ２０は認証サーバ７０へ機器ＩＤと認証データを結合したデータを暗号化して送信する。ここでいう認証データとは、例えばテレビ２０のメーカー名、型番等の、機器の種別を表す情報などであり、本実施例ではこの機器の種別を表す情報をモデルＩＤと呼ぶ。認証サーバ７０がこの暗号化されたデータより、認証データと機器ＩＤを取り出し、接続のための条件を満たしているか（接続可能な機種か否か、また、登録済みの機器ＩＤか否か）チェックする。接続拒否する場合はテレビ２０へエラーを返し、接続許可する場合は、トップページ（図１５の画面）を送信しテレビ２０で表示する。

受信者は、この画面でビデオお届けサービスを選択すると、テレビ２０が認証サーバ７０より該サービスに接続するために必要な配信サーバ３０のＵＲＬと、認証サーバ７０が発行するワンタイムＩＤ（これは、テレビ２０などから要求があった際に、認証サーバ７０の会員情報管理７２にてユニークなＩＤを発行して、ワンタイムＩＤ管理テーブル７７へも登録され、ネットワーク送受信部７１からテレビ２０などの要求元機器へ送信される。）を受信し、この情報を基にテレビ２０が配信サーバ３０へ接続し、ワンタイムＩＤを送信する。

配信サーバ３０は、このワンタイムＩＤを認証サーバ７０へ送信し、認証サーバがこのワンタイムＩＤについてワンタイムＩＤ管理テーブル７７にて確認する。認証サーバ７０は、更に、ワンタイムＩＤ管理テーブル７７にて取得できる機器識別ＩＤからテレビ機器ＤＢ７６を確認して、当該の機器が配信サーバ３０のサービスに相当するサービスＩＤか確認して未登録であればエラーを返しても良い。

認証サーバ７０よりエラーが返されれば接続できない旨を伝える情報をテレビ２０へ返す。認証サーバ７０より正常に機器ＩＤを取得できた場合は、その機器ＩＤをテレビ機器ＤＢ３６で参照し、整合が取れれば、テレビへ送信者承認画面図１１表示のための情報を送信する。

前記の認証については、より詳細に後述する。テレビ２０は、図１１の送信者承認画面を経由して、図２４の受信メール一覧表示画面を表示する。リモコンを使ってカーソルをアイコン＃１〜＃９のいずれかに移動して所望のメールを選択し、決定ボタンを押下すると、選択したメールが静止画の集合の場合は、図２５の画像一覧表示画面が表示される。

アイコン＃１〜＃９のいずれかに移動して所望の画像を選択すると、図２６のように選択した画像が拡大表示される。また、図２４で選択した映像コンテンツが動画の場合は、画面全体に動画が再生される。もちろん、図２６のように画面の一部に動画を表示しても良い。

（７）映像のダウンロードと消去
映像のダウンロードと消去については実施例１と同様である。

本実施例においても、実施例２と同様に送信者が携帯電話５０を用いて配信サーバ３０へアップロードを行うことができる。

本実施例により、サーバは機器ＩＤにて機器を管理するが、ユーザへは変換機器ＩＤを通知して利用することで、送信者がＩＤを誤入力して予期せぬユーザあるいは機器へコンテンツを送信する事故がなくなるメリットがある。

ここで、本実施例４の認証処理について以下説明する。
図３８は、本実施例のコンテンツ配信サービスの認証フローを示す図である。まず処理の概要をステップ順に説明する。

ステップＳ２０１：受信者がポータルサイトにアクセスする際に、受信端末（テレビ２０）が認証データ（例えば、機器の種別を表すモデルＩＤ）と機器ＩＤ（機器固有のＩＤで例えば、製造番号）を併せて、安全な伝送路（例えば、ＳＳＬ通信路）を通して認証サーバ７０へ送信する。受信機器のブラウザの持つＣＯＯＫＩＥの機能を用いても良い。

ステップＳ２０２：認証サーバ７０では会員情報管理部７２が各種処理を担う。認証サーバ７０では、認証データを取り出し、アクセス機器がサービスを利用可能かどうかの検証を行い（ＣＯＯＫＩＥの正当性検証を実施しても良い）、また、機器ＩＤが登録されているかテレビ機器ＤＢ７６にて照会する。ここで、不正あるいは未対応機器と判断されれば、その旨受信端末へ伝える。

例えば認証データが機器の種別を表すモデルＩＤであった場合に、モデルＩＤが自社の製品を示すものであれば、サービスを利用可能であると判定する。サービスを利用可能な機器のモデルＩＤは認証サーバ７０の図示しないモデルＩＤ情報ＤＢに格納されている。

また、テレビ機器ＤＢ７６には、機器ＩＤとサービスＩＤが対応付けて登録されており、アクセスしてきたユーザが希望するサービスが、ユーザの使用しているテレビ２０の機器ＩＤに対応しているか照会する。

受信端末は認証結果についてユーザへ表示等を行う。正常に確認が通れば、認証サーバ７０は配信サーバ３０から問い合わせる際に利用するワンタイムＩＤを発行する。これにより万が一受信端末の一部の情報を詐称してアクセスする端末があってもこれを拒否することができ、不正利用を防止できる。

ステップ２０３：認証サーバ７０はこれを、ワンタイムＩＤ管理テーブル７７に保持し、受信端末へユーザが選択したサービスサーバ（例えば、配信サーバ３０）のＵＲＬ情報と共にこのワンタイムＩＤを送信する。一定時間アクセスがない場合はテーブルから当該のワンタイムＩＤを削除しても良い。

ステップ２０４：受信端末は認証サーバ７０から受信したワンタイムＩＤをサービスサーバアクセス時に送信する。
ステップ２０５：配信サーバ３０では、各種処理を会員情報処理部３２が担う。配信サーバ３０は、このワンタイムＩＤを認証サーバ７０へ送信する。

ステップ２０６：認証サーバ７０は、配信サーバ３０から受信したワンタイムＩＤをテーブルで照会し、登録されたものがなければエラーとして返信し、あれば当該の機器ＩＤを返信する。２回目以降のアクセスでは無効化するため、テーブルから先に照会したワンタイムＩＤに関する項目を削除する。これにより詐称を回避する安全な認証を可能とする。

ステップ２０７：配信サーバ３０は、認証サーバ７０より受信した機器ＩＤをデータベースと照会し、サービスに加入したユーザのものであることが確認できれば、受信端末へサービス提供を開始する。すなわちコンテンツの配信を開始する。
ステップ２０８：受信端末は、配信サーバ３０からのコンテンツを受信し、保存あるいは再生を開始する。

先に説明した実施例では、認証サーバ７０が管理するＩＤは機器ＩＤを用いることで機器あるいはユーザを認証したが、本実施例ではユーザが使用する機器を買い替えた場合等に対応するため、機器ＩＤを利用して生成されるユニークなＩＤ（以下機器識別ＩＤ）を利用する。これにより以下のメリットがある。
（１）買い替えなどで手放した機器を第三者に不正に利用されることを防ぐ。
（２）サーバで不要なＩＤを管理する必要がなくなりデータベースの肥大化を防ぐ。
以上のように更にシステムの運用性を向上できる。そこで、以下この機器識別ＩＤを利用する場合の実施例について説明する。

認証サーバ７０では、会員情報管理部７２は適宜発行した他のＩＤと重なることのないユニークな機器識別ＩＤを発行し、データベース（テレビ機器ＤＢ７６）へ登録する。図３９にテレビ機器ＤＢの一例を示す。また、図４０にワンタイムＩＤ管理テーブルの一例を示す。テレビ機器ＤＢ７６では、機器識別ＩＤと各機器ＩＤとユーザが利用しているサービスのサービスＩＤを夫々管理している。ワンタイムＩＤ管理テーブルでは、機器識別ＩＤとワンタイムＩＤとサービスＩＤを夫々管理している。

図４１は、本実施例の機器識別ＩＤに関する処理フローを示す図である。各処理についてステップ順に以下説明する。

ステップＳ３０１：ユーザは受信端末（テレビ２０）が接続されている認証サーバ７０（ここではポータルサーバを兼ねる）へ、各種サービスを利用するための初期画面（図１５）を表示するためアクセスする。テレビ２０は認証データと機器ＩＤを認証サーバ７０へ送信する。

ステップＳ３０２：認証サーバ７０は、上記の情報（テレビ２０の認証データと機器ＩＤ）を基にテレビ機器ＤＢ７６の内容を参照し、既に登録済みか否か確認し受信端末に適した初期画面情報を用意する。

ステップＳ３０３：認証サーバ７０は、この初期画面情報をネットワーク送受信部７１経由で、ここではテレビ２０へ送信する。テレビ２０はこれをネットワーク受信部２１にて受信し、ブラウザ２２を経由して表示部２７へ表示する。
ステップＳ３０４：ユーザが、初期画面から、直接あるいはメニュー等を経由して機器識別ＩＤ発行あるいは機器識別ＩＤ削除を選択する。

ステップＳ３０５：ユーザが、機器識別ＩＤ発行を選択した場合、認証サーバ７０は会員情報管理７２にて他の機器識別ＩＤと重ならないユニークなＩＤを発行し、テレビ２０から受信している機器ＩＤと関連付けてテレビ機器ＤＢ７６へ登録する。認証サーバ７０は、ネットワーク送受信部７１経由で発行した機器識別ＩＤを通知するための画面情報をテレビ２０へ送信する。テレビ２０に表示される画面例を図４２に示す。図中トップページは初期画面を意味する。

図示はしないが、もし初めての利用時等、ユーザが未だ機器識別ＩＤを取得していない場合は、図４３に示した画面を表示して機器識別ＩＤの取得を促すようにすると、更に使い勝手が良い。ユーザが、図中の「機器識別ＩＤ取得」を選択することで前述のように認証サーバ７０が機器識別ＩＤ発行を行う。なお、ユーザが、送信者へ通知する等の都合で機器識別ＩＤを確認する場合もここで行うことができる。

ステップＳ３０６：ユーザが、機器識別ＩＤ削除を選択した場合、認証サーバ７０は、ネットワーク送受信部７１経由で削除を確認するための画面情報をテレビ２０へ送信する。テレビ２０に表示される画面例を図４４に示す。図中の初期化は削除に相当する。ここでユーザが「初期化する」を選択すると、認証サーバ７０は会員情報管理７２にて登録済みの機器識別ＩＤについてテレビ機器ＤＢ７６から関連情報を削除する。図示しないが削除後は、削除した旨の画面をテレビ２０へ表示しても良いし、初期画面へ戻っても良い。図４４に示した画面で、ユーザが「初期化しない」を選んだ場合も、初期画面へ戻る。

続いて、機器識別ＩＤを採用した場合のサービスについて説明する。本実施例によるコンテンツ配信システムの全体構成は図３４と同様である。

本実施例のシステムでは、受信端末であるテレビ２０を識別するために、各テレビ２０の機器識別ＩＤをアドレスとして用いる。また、認証サーバ７０、配信サーバ３０と、送信者へ伝えるＩＤも機器識別ＩＤに統一する。これにより、先に述べたユーザ利用機器が置き換わった場合等への対応が容易で、高い運用性が保たれる。なお、送信者は自宅のＰＣ１０だけでなく、事前に登録しておいた携帯電話５０で撮影した映像ファイルをネットワーク４を介して配信サーバ３０に送信することも可能であり、これは実施例４で説明したシステムの機器ＩＤを機器識別ＩＤと置き換わったものであり説明は割愛する。

次に、配信サーバ３０、認証サーバ７０の内部のデータベース等について構成を説明する。
図４５は、未読メールチェックテーブル３３の一例を示す。テーブルには、機器ＩＤ毎に送信者として承認を待っている人がいるか否か、承認済みの送信者から新たな映像ファイルが送られているか否かを示すフラグを設けておく。この例では、機器識別ＩＤが「１２３４５６７」のテレビに対して、承認を依頼している送信者が２人いて、そのユーザＩＤ（ＩＤ１、ＩＤ２）が示されている。また、承認済みのユーザ（ＩＤ１）からのメール（実際には映像）が届いており、このテレビの受信者はそのメールをまだ読んでいないことを示している。

図４６は、送信者ＤＢの一例を示す。ユーザＩＤから生年月日までは仮登録の内容、本登録時は受信者数＝１で受信を承認（送信することを許可）してくれた受信者のテレビの機器識別ＩＤ（仮登録時に入力済み）を記録する。また、本登録時にユーザが入力したクレジットカードの番号、有効期限、入会年月日を追加登録する。携帯電話から送信する場合もあるので、欄だけを設けておいて、追加された場合に登録する。図４６で受信者数＝３となっているのは、本登録の後、受信者が２人増加したためである。

図４７は、受信者ＤＢの一例を示し、これも本登録時に追加登録する。当初、送信者数＝１とし、送信することを許可した送信者のユーザＩＤ（この場合はユーザＩＤ５）を登録しておく。その後、別の送信者に送信を許可した場合はユーザ数をインクリメントし、及びそのユーザＩＤ（この場合はユーザＩＤ６）を追加する。受信者ＤＢの個人を特定する情報としては、機器識別ＩＤと表示される名前だけでも実現可能であるが、今後受信者課金に変更することを考慮した場合は、住所、氏名、電話番号、生年月日も入力した方が変更は容易である。図１２の登録画面でこれらの情報も入力してもらえばよい。図４７にはこれらの情報も付加した内容を示す。送信者ＤＢ、受信者ＤＢが追加登録されれば、送信者は受信者に対して、メールを送ることができる。

図４８は、コンテンツ管理テーブルを示し、機器識別ＩＤと、該機器識別ＩＤの受信者向けに受信している受信ファイル数と、そのファイル名、該ファイルの送信者ユーザＩＤと、該送信者の加入している料金プランと、その有効期限が管理されている。

その他のサービス利用方法については前述の実施例に対して、機器ＩＤが機器識別ＩＤとなる点以外は同様なので割愛する。
上記により、利用者、認証サーバ、配信サーバは機器識別ＩＤのみで運用でき、利用者の使い勝手が向上し、サービス提供者の管理が容易となる。

前述のシステムでは認証サーバの管理が簡単にできるメリットがあるが、１ユーザが複数の機器を所有する場合や、一つの機器を複数のユーザ（例えば家族で共有）での利用についての利便性が考えられていない。そこで、本実施例のシステムにおいて、前記の課題に対応するため、機器識別ＩＤだけでなく、会員ＩＤも併せて管理するシステムについて以下説明する。

本実施例によるコンテンツ配信システムの全体構成図は、認証サーバ７０が認証サーバ８０に変わった以外は、図３４と同様である。本システムは、送信側端末（ＰＣ１０）と、１又は複数の受信側端末（テレビ２０）と、両者間のコンテンツ配信を中継する配信サーバ（配信サーバ３０）と、認証サーバ（認証サーバ８０）が、インターネット等のネットワーク４に接続されて構成される。前述の「ビデオお届けサービス」では、メールソフトを有するＰＣ１０からメールソフトを有しないテレビ２０へ、送信者所有の映像コンテンツを配信サーバ３０を介して送信する。

次に、認証サーバ８０の内部構成を詳細に説明する。
図４９は、認証サーバ８０の内部構成の一例を示す図である。
ネットワーク送受信部８１は、外部のネットワーク４に接続され、該ネットワーク経由で配信サーバ３０やＰＣ１０やテレビ２０と通信を行う。

会員情報管理部８２は、会員ＤＢ８５、テレビ機器ＤＢ８６、ワンタイムＩＤ管理テーブル８７の、データベースやテーブルを有し、会員の情やテレビ機器の情報、および加入しているサービス情報を保存している。テレビ２０や、サービスサーバ（例えば、配信サーバ３０）からアクセスがあった際に、関連するデータベースやテーブルを参照して、機器情報の確認や登録などの処理を行う。

図５０は会員ＤＢ８５について管理する内容を示した図である。
主会員は主に利用するユーザを示し、機器の所有者を想定している。主会員ＩＤとパスワード、機器識別ＩＤを管理する。管理ＤＢとしては、将来の拡張を考え、表示される名前、住所、氏名、電話、生年月日、統合課金サービスに備えて、クレジットカード番号と有効期限等も管理しても良い。

図５１は、テレビ機器ＤＢ８６について管理する内容を示した図である。
機器識別ＩＤ、機器ＩＤ、主会員ＩＤと、子会員ＩＤを管理する。

図５２は、ワンタイムＩＤ管理テーブル８７について管理する内容を示した図である。
機器識別ＩＤ、サービスＩＤ、ワンタイムＩＤを管理する。

会員情報管理部８２は、上記ＤＢやテーブルを相互参照する機能を有する。
例えば、配信サービス等で利用されるメールアドレスは、会員登録時に会員情報管理部８２が機器識別ＩＤと会員ＩＤを組み合わせたアドレスを生成して他の情報と併せてＤＢへ登録する。これにより、例えば「ビデオお届けサービス」等で、機器識別ＩＤと、会員ＩＤを指定することで、機器を共有している会員のうち特定の会員へ指定してビデオを送信すると言ったサービスを実現することが可能となる。

会員の登録手順について以下説明する。
前述の実施例に示したように、テレビ２０にてユーザが機器識別ＩＤを登録する。なお、サービスＩＤについては、サービスを選択した際に、該機器識別ＩＤと選択したサービスのサービスＩＤをリンクしてテレビ機器ＤＢへ登録する。ここまでの操作でテレビ機器ＤＢ８６へ機器識別ＩＤが登録される。

図５３は、本実施例の会員ＩＤ登録に関する処理フローを示す図である。各処理についてステップ順に以下説明する。

ステップＳ４０１：ユーザは受信端末（テレビ２０）が接続されている認証サーバ８０（ここではポータルサーバを兼ねる）へ、各種サービスを利用するための初期画面（図１５）を表示するためアクセスする。テレビ２０は認証データと機器ＩＤを認証サーバ８０へ送信する。

ステップＳ４０２：認証サーバ８０は、上記の情報（テレビ２０の認証データと機器ＩＤ）を基にテレビ機器ＤＢ８６の内容を参照し、既に登録済みか否か確認し受信端末に適した初期画面情報を用意する。

ステップＳ４０３：認証サーバ８０は、この初期画面情報をネットワーク送受信部８１経由で、ここではテレビ２０へ送信する。テレビ２０はこれをネットワーク受信部２１にて受信し、ブラウザ２２を経由して表示部２７へ表示する。
ステップＳ４０４：ユーザが、初期画面から、直接あるいはメニュー等を経由して会員ＩＤ登録あるいは会員ＩＤ削除を選択する。

ステップＳ４０５：ユーザが、会員ＩＤ登録を選択した場合、認証サーバ８０は会員情報管理８２にて会員ＩＤ登録画面情報をテレビ２０へ送信する。テレビ２０に表示される画面例を図５４に示す。図中トップページは初期画面を意味する。

ステップＳ４０６：ユーザが、画面に従い必要な項目を入力し、画面中の「登録」を選択することで認証サーバ８０が会員情報管理８２にて会員ＤＢ８５、テレビ機器ＤＢ８６へ会員ＩＤ登録を行う。この入力画面例を図５５に示す。なお、ユーザが、送信者へ通知する等の都合で会員ＩＤを確認する場合もここで行うことができる。初回の登録の場合、認証サーバ８０がユニークなＩＤを提示しても良い。既に登録済みの会員の場合は、手動で入力して登録しても良い。

図示しないが、その他の個人情報を入力した場合、既に登録済みの情報と照合された場合、認証サーバ８０が、登録済み会員ＩＤを提示する図５２相当の画面を送信してユーザへ提示しても良い。主会員登録が済んでいない場合は、認証サーバ８０が子会員登録できない旨を示すマスク表示や、メッセージ表示を入れた画面を送信しテレビ２０で表示し、登録不可能とする。

ステップＳ４０７：ユーザが、会員削除を選択した場合、認証サーバ８０は、会員情報管理８２にてテレビ２０の機器識別ＩＤを照合し、ネットワーク送受信部８１経由で削除可能な会員情報の載った削除を確認するための画面情報をテレビ２０へ送信する。

ステップＳ４０８：テレビ２０に表示される画面例を図５６に示す。図中トップページは初期画面を意味する。ここでユーザが「削除」を選択すると、認証サーバ８０は会員情報管理８２にて登録済みの会員ＩＤについて会員ＤＢ８５、テレビ機器ＤＢ８６から関連情報を削除する。図示しないが、削除実行前にパスワード入力画面を提示して削除の再確認を行っても良い。削除後は、削除した旨の画面をテレビ２０へ表示しても良いし、初期画面へ戻っても良い。

上記のより、認証サーバ８０にて会員情報と機器識別ＩＤをリンクして管理し、機器を共有しながらユーザ毎に細やかなサービスに対応することができる。また、一人のユーザが複数の機器を所有する場合、機器に跨って利用するようなサービスにも対応することができる。

なお、本実施例では、機器識別ＩＤを使用した処理を記載したが、機器識別ＩＤを使用せず、機器ＩＤのみの処理であっても、実現可能である。機器識別ＩＤを使用しない場合には、テレビ２０と認証サーバ、配信サーバとの間の処理には機器ＩＤを使用する。

続いて、会員ＩＤ、機器識別ＩＤを採用した場合のサービスについて以下説明する。送信者が会員を特定して送信した場合は、受信機器にて会員ＩＤとパスワードを入力することでメッセージを受信することができる。

本実施例のシステムでは、受信端末であるテレビ２０を識別するために、各テレビ２０の機器識別ＩＤをアドレスとして用いる。送信先情報として、機器識別ＩＤと会員ＩＤを組み合わせた情報をアドレスとして指定することで、機器の特定と、会員の特定を行った送信が可能となる。また、認証サーバ８０、配信サーバ３０と、送信者へ伝えるＩＤも機器識別ＩＤに統一する。これにより、先に述べたユーザ利用機器が置き換わった場合等への対応が容易で、高い運用性が保たれる。なお、送信者は自宅のＰＣ１０だけでなく、事前に登録しておいた携帯電話５０で撮影した映像ファイルをネットワーク４を介して配信サーバ３０に送信することも可能であり、これは実施例５で説明したシステムの機器ＩＤを機器識別ＩＤと置き換わったものであり説明は割愛する。

次に、「ビデオお届けサービス」において、送信者の操作について以下説明する。
基本的な流れは前述の通りだが、特に会員宛に送信したい場合は、機器識別ＩＤだけでなく会員ＩＤを入力する必要がある。（会員ＩＤ未入力時の動作は前述と同様の動作となる。）
図４のコンテンツ配信サービスの処理における、会員仮登録（ステップＳ１０２）において、図５７に示した画面が、本実施例における会員ＩＤに対応したサービスでの、送信先のテレビの機器識別ＩＤと会員ＩＤを入力する画面である。なお、この表示画面では、機器識別ＩＤの代わりにユーザに分かりやすい用語「宛先ＩＤ」を用いている。「宛先ＩＤ」は「機器識別ＩＤ」と同じ意味である。他の画面においても、会員ＩＤが入力された場合は以降宛先ＩＤと共に会員ＩＤが表示される。操作手順等は前述と同様なので説明は割愛する。

なお、機器ＩＤとコンテンツ（ファイル名）と会員ＩＤとは、それぞれ対応付けられて、コンテンツ管理テーブルで管理されている。送信先情報として、機器識別ＩＤと会員ＩＤを組み合わせた情報をアドレスとして指定することで、コンテンツ送信者は、特定の会員ＩＤをもつ会員を指定してコンテンツを送信することができる。これらの情報は、コンテンツ管理テーブルで管理される。

配信サーバ３０は、テレビ２０から送信された、会員ＩＤとパスワードを受信し、この会員ＩＤと機器ＩＤに対応するコンテンツを、テレビ２０に送信する。

なお、コンテンツの配信を行うときに配信サーバ３０に会員ＩＤを通知することもできるが、最初にアクセスしたときに会員ＩＤを認証サーバ８０に通知し、認証サーバ８０は会員ＩＤ毎にワンタイムＩＤを発行するようにしてもよい。機器ＩＤ毎ではなく会員ＩＤ毎にワンタイムＩＤを発行すれば、テレビ２０が配信サーバに配信要求を行うときにはワンタイムＩＤの通知のみでよい。

更に、会員ＩＤ、機器識別ＩＤを採用した場合に、ポータルサーバによる、文字情報からなるコンテンツ（以下、文字情報からなるコンテンツをメッセージと呼ぶ。）の配信サービス（以下、本実施例中はメッセージ配信サービスと呼ぶ。）について説明する。本実施例の全体構成図は、認証サーバ７０が認証サーバ８０に変わった以外は、図３４と同様である。本システムは、送信側端末（ＰＣ１０）と、受信側端末（テレビ２０）と、両者間のメッセージ配信を中継するセンタ３（認証サーバ８０からなるポータルサーバ）が、インターネット等のネットワーク４に接続されて構成される。そして、メールソフトや、Ｗｅｂブラウザソフトを有するＰＣ１０からテレビ２０へ、センタ３を介して送信するものである。以下、センタ３の行うメッセージ配信サービスを「お知らせサービス」と呼ぶことにする。

なお、前述の機器識別ＩＤや、会員ＩＤは、前述の実施例にて登録されているものとして説明する。

送信者宅１にいる送信者は、ルータ（図示せず）を経由してネットワーク４に接続したＰＣ１０を操作し、メールソフトあるいは認証サーバ８０が用意したページにアクセスしてメッセージを認証サーバ８０へ送信する。認証サーバ８０は送信者（ＰＣ１０）からのメッセージを預かり、送信者が指定した受信者宅２のテレビ２０からのアクセスを待つ。

テレビ２０がルータ及びネットワーク４を経由してセンタ３にある認証サーバ８０（ここでは全てのサービスの入り口として稼動するものとして説明するが他に専用の入り口サーバがあっても良い）に接続し、受信者が「お知らせサービス」を選択すると、認証サーバ８０は「お知らせ」が届いていることを示すメッセージを送り、テレビ２０の画面に表示する。

その後、受信者はその「お知らせ」を選択して受信し、内容を確認することができる。テレビ２０に記録装置（例えばハードディスク）が内蔵されていれば、メッセージのダウンロードも可能である。特に送信者が会員を特定して送信した場合は、受信機器にて当該の会員ＩＤに対応するパスワードを入力することでメッセージを受信することができる。

本実施例のシステムでは、受信端末であるテレビ２０を識別するために、各テレビ２０の機器識別ＩＤをアドレスとして用いる。送信先情報として、機器識別ＩＤと会員ＩＤを組み合わせた情報をアドレスとして指定することで、機器の特定と、会員の特定を行った送信が可能となる。また、認証サーバ８０、送信者へ伝えるＩＤも機器識別ＩＤに統一する。

これにより、受信者が使用する機器が、認証サーバ８０にその機器識別ＩＤが登録されていれば、認証サーバ８０がデータベースを参照し、受信者が直接機器識別ＩＤとリンクして登録されていない場合でも、属する機器識別を検索してメッセージを送信し、受信者がこれを受信することができ、使い勝手の良いメッセージ配信サービスを提供できる。

なお、送信者は自宅のＰＣ１０だけでなく、携帯電話５０からでもネットワーク４を介して認証サーバ８０に送信することも可能である。

また、本サービスは、前述の実施例に示したように専用のサービスサーバを用意して実現しても良い。その場合の操作手順や、サーバ間のフローは前述の「ビデオお届けサービス」と同様で、利用者の限定が可能となり、より安全で、更に多種多様なデータを扱うようなサービスを提供できる。ここでは、お知らせとして簡単な文字情報を使用するものとして、認証サーバで管理するデータベースにメッセージや送信者の管理機能を追加した構成で説明する。

もっとも簡単な構成としては、認証サーバ８０がポータルサーバとして初期画面等を送信する際に利用する機能（例えば、ＨＴＴＰサーバ機能）を活用して、送信者が利用する機器に対して操作画面を送信する方法である。通常の受信者の入り口は機器認証を兼ねるので、ＰＣ１０や携帯電話５０向けに、専用の入り口を用意する。

図５８は、本実施例の「お知らせサービス」の送信時の処理フローを示した図である。各処理についてステップ順に以下説明する。
ステップＳ５０１：送信者はＰＣ１０で認証サーバ８０の「お知らせサービス」送信ページへアクセスする。
ステップＳ５０２：認証サーバ８０は「お知らせ」入力ページ情報を送信者の端末ＰＣ１０へ送信する。

ステップＳ５０３：ＰＣ１０は認証サーバ８０から受信した「お知らせサービス」送信ページを表示し、送信者がこれにメッセージと送信先（機器識別ＩＤと会員ＩＤ）を入力する。図５９に示した画面が、本実施例における会員ＩＤに対応したサービスでの、送信先のテレビの機器識別ＩＤと会員ＩＤを入力するメッセージ入力画面である。

なお、この表示画面では、機器識別ＩＤの代わりにユーザに分かりやすい用語「宛先ＩＤ」を用いている。「宛先ＩＤ」は「機器識別ＩＤ」と同じ意味である。送信者が入力後、送信ボタンを選択してＰＣ１０がメッセージを認証サーバ８０へ送信する。ここで、図６０に示すような確認画面を表示して送信者の確認をとってから送信しても良い。

ステップＳ５０４：認証サーバ８０は、送信者の端末（ＰＣ１０）から受信したメッセージを登録する。

図４９は、認証サーバ８０の内部構成の一例を示す図である。但し図のテレビ機器ＤＢ８６は本実施例においてはテレビ機器ＤＢ９６と読み替える。
ネットワーク送受信部３１は、外部のネットワーク４に接続され、該ネットワーク経由でＰＣ１０やテレビ２０と通信を行う。

会員情報管理部９２は、会員ＤＢ８５、テレビ機器ＤＢ９６、ワンタイムＩＤ管理テーブル８７の、データベースやテーブルを有し、会員の情やテレビ機器の情報、および加入しているサービス情報を保存している。ＰＣ１０やテレビ２０からアクセスがあった際に、関連するデータベースやテーブルを参照して、機器情報の確認や登録などの処理を行う。

図６１は、テレビ機器ＤＢ９６について管理する内容を示した図である。
機器識別ＩＤ、機器ＩＤ、主会員ＩＤと、子会員ＩＤ、ならびに、「お知らせサービス」で登録されるメッセージとその送信者情報（例えばメールアドレス）を管理する。
以上により、「お知らせサービス」利用の送信者からのメッセージを認証サーバ８０が登録完了する。

図６２は、本実施例の「お知らせサービス」の受信時の処理フローを示した図である。各処理についてステップ順に以下説明する。
ステップＳ６０１：ユーザは受信端末（テレビ２０）にてこれが接続されている認証サーバ８０へアクセスする。テレビ２０は認証データと機器ＩＤを認証サーバ８０へ送信する。

ステップＳ６０２：認証サーバ８０は、上記の情報（テレビ２０の認証データと機器ＩＤ）を基にテレビ機器ＤＢ９６の内容を参照し、既に登録済みか否か確認し受信端末に適した初期画面情報を用意する。

ステップＳ６０３：認証サーバ８０は、上記ステップにて受信した機器ＩＤについて、テレビ機器ＤＢ９６を検索し、機器ＩＤと関連のある主会員ＩＤを取得する。この主会員ＩＤより会員ＤＢ８５を検索し、関連する機器識別ＩＤを全て取得する。再度、テレビ機器ＤＢ９６を検索し、取得した機器識別ＩＤ全てに関するメッセージと送信者の情報を取得する。

ここで、当該のメッセージがない場合は、ステップＳ６０４へ遷移する。当該のメッセージがある場合は、ステップＳ６０５へ遷移する。

ステップＳ６０４：通常の初期画面（図１５）情報をネットワーク送受信部３１経由で、ここではテレビ２０へ送信する。テレビ２０はこれをネットワーク受信部２１にて受信し、ブラウザ２２を経由して表示部２７へ表示する。

ステップＳ６０５：もし当該のメッセージが複数ある場合は、図６３に示す「お知らせ」メッセージ一覧画面情報をネットワーク送受信部３１経由で、テレビ２０へ送信する。テレビ２０はこれをネットワーク受信部２１にて受信し、ブラウザ２２を経由して表示部２７へ表示する。受信者が所望のメッセージを選択すると、図６４に示した「お知らせ」メッセージ表示画面が表示される。

もし当該のメッセージが一件の場合は、図６３の一覧画面を経由せずに図６４の「お知らせ」メッセージ表示画面を表示しても良い。
また、メッセージが特定の会員向けのものであった場合、図６５のパスワード入力画面を経由して、ユーザが自分の会員ＩＤに対応した正しいパスワードを入力した場合のみ図６４の「お知らせ」メッセージ表示画面を表示しても良い。

なお、当該のメッセージがある場合でも通常の初期画面（図１５）経由で、メッセージ一覧あるいはメッセージ表示画面を表示するようにしても良い。

上記により、以下に示すような効果が得られる。
例えば、テレビ２０が受信者であるユーザ（もちろん送信者と受信者が同一でも良い）の自宅に複数ある場合に、居間にあるテレビ２０をテレビＡとし、書斎にあるテレビ２０をテレビＢとする。送信者がテレビＢの機器識別ＩＤ宛に「お知らせ」メッセージを送信した場合でも、ユーザが居間にあるテレビＡでポータルサーバへアクセスすれば、このメッセージを受信することが出来る。

認証サーバ８０が本実施例の「お知らせサービス」に対応しているテレビ向けに専用の入り口を設ければ、ユーザがテレビ視聴中でも、テレビがバックグラウンドでこの専用の入り口へアクセスすることでメッセージを受信して、それをテレビ画面へ重畳して表示する等の機能が実現可能となる。

更に、会員ＩＤ、機器識別ＩＤを採用した場合の「お知らせサービス」を「ビデオお届けサービス」へ適用した実施例を以下に示す。

コンテンツ配信システムの全体構成図は、認証サーバ７０が認証サーバ８０に変わった以外は、図３４と同様である。本システムは、送信側端末（ＰＣ１０）や送信側端末（携帯電話５０）と、受信側端末（テレビ２０）と、両者間のコンテンツ配信を中継する配信サーバ（配信サーバ３０）と、認証サーバ（認証サーバ８０）が、インターネット等のネットワーク４に接続されて構成される。前述の「ビデオお届けサービス」では、メールソフトを有するＰＣ１０あるいは携帯電話５０からメールソフトを有しないテレビ２０へ、送信者所有の映像コンテンツを配信サーバ３０を介して送信する。

図４に示した、コンテンツ配信サービス（ビデオお届けサービス）の処理フローのステップＳ１０５において、以下の処理を施すことによって実現が可能となる。

送信者はＰＣ１０を操作して、送信を承認した受信者を指定し、ビデオカメラ１１やデジカメ１２で撮影した映像を配信サーバ３０に送信（アップロード）する。配信サーバ３０は、ＰＣ１０から送られた映像をコンテンツ格納部３９に格納する。そして、指定された受信者から受信要求があるまで預かる。これと同時に、認証サーバ８０に対して、当該の機器識別ＩＤ宛にコンテンツを預けた旨の「お知らせ」メッセージを送信する。

上記により、ユーザは受信端末でポータルサーバにアクセスし、「お知らせサービス」利用時に「ビデオお届けサービス」で受信したコンテンツがあることを知ることができる。

更に、図６２に示した本実施例の「お知らせサービス」の受信時の処理フローのステップＳ６０３において、以下の処理を施すことで、受信者が本サービスを利用している場合のみメッセージを伝えることもできる。

認証サーバ８０は、上記ステップにて受信した機器ＩＤについて、テレビ機器ＤＢ９６を検索し、機器ＩＤと関連のある主会員ＩＤを取得する。この主会員ＩＤより会員ＤＢ８５を検索し、関連する機器識別ＩＤを全て取得する。再度、テレビ機器ＤＢ９６を検索し、取得した機器識別ＩＤ全てに対して本サービスのサービスＩＤによる抽出を行い関連するメッセージと送信者の情報を取得する。

上記により、ユーザは受信端末でポータルサーバにアクセスし、「お知らせサービス」利用時に受信端末利用者に関連する会員ＩＤの中に「ビデオお届けサービス」を利用している会員ＩＤがある場合のみ「ビデオお届けサービス」で受信したコンテンツがあることを知ることができる。

送信端末と受信端末と配信サーバとがネットワークを介して接続され、送信端末から受信端末へ配信サーバを経由してコンテンツを送信するコンテンツ配信システムであって、配信サーバは、受信端末を特定する機器ＩＤを登録したデータベースと、送信端末から送信されたコンテンツを一旦格納するコンテンツ格納部と、コンテンツを受信端末の機器ＩＤおよび送信者毎に区別して管理するテーブルを有する。配信サーバは受信端末から要求があったとき、テーブルを参照し、その受信端末の機器ＩＤが送信先とされるコンテンツをその受信端末に送信する。

前記これらの実施例１〜７によれば、送信端末から送信されたコンテンツを配信サーバを経由して受信端末へ送信するコンテンツ配信方法であって、受信端末を特定する機器ＩＤを配信サーバに登録し、配信サーバは、送信端末から送信されたコンテンツを送信先の受信端末の機器ＩＤ毎に区別して格納し、配信サーバは受信端末から要求があったとき、その受信端末の機器ＩＤが送信先とされるコンテンツをその受信端末に送信する。

また、送信端末から送信されたコンテンツを格納し受信端末へ送信する配信サーバであって、受信端末を特定する機器ＩＤを登録したデータベースと、送信端末から送信されたコンテンツを一旦格納するコンテンツ格納部と、コンテンツを受信端末の機器ＩＤおよび送信者毎に区別して管理するテーブルを有し、受信端末から要求があったとき、テーブルを参照し、その受信端末の機器ＩＤが送信先とされるコンテンツをその受信端末に送信する。

また、送信端末から送信されたコンテンツを配信サーバを経由して受信する受信端末であって、当該受信端末を特定する機器ＩＤを保持する機器ＩＤ保持部と、受信するコンテンツまたはコンテンツの送信者を選択する選択部と、受信したコンテンツを表示する表示部とを有し、配信サーバへ当該受信端末の機器ＩＤを通知することで、配信サーバが格納している当該受信端末宛のコンテンツ一覧または送信者一覧を取得して表示する。

また、送信端末と受信端末と配信サーバと認証サーバとがネットワークを介して接続され、送信端末から受信端末へ配信サーバを経由してコンテンツを送信するコンテンツ配信システムであって、配信サーバは、受信端末を特定する機器ＩＤを登録したデータベースと、送信端末から送信されたコンテンツを一旦格納するコンテンツ格納部と、コンテンツを受信端末の機器ＩＤおよび送信者毎に区別して管理するテーブルを有する。認証サーバは、ユーザが所有する機器ＩＤと言ったユーザ情報とサービスＩＤとを格納し、また、ワンタイムＩＤを一時的に発行ならびに格納し、これとユーザ情報を結び付けるためのテーブルを有する。配信サーバは受信端末から要求があったとき、テーブルを参照し、その受信端末の機器ＩＤが正当なＩＤか否かを認証サーバにて認証を得た後、送信先とされるコンテンツをその受信端末に送信する。

また、送信端末から送信されたコンテンツを、配信サーバを経由して受信端末へコンテンツを送信するには、受信端末を特定する機器ＩＤを配信サーバに登録し、配信サーバは、送信端末から送信されたコンテンツを送信先の受信端末の機器ＩＤ毎に区別して格納し、配信サーバは受信端末から要求があったとき、その受信端末の機器ＩＤが送信先とされるコンテンツを、認証サーバが発行したワンタイムＩＤを受信機器から受け取り、そのワンタイムＩＤを用いて認証サーバにて認証を受けた後、その受信端末に送信される。

また、認証方法であって、送信端末から送信されたコンテンツを格納し受信端末へ送信する配信サーバが、受信端末を特定する機器ＩＤを登録したデータベースと、送信端末から送信されたコンテンツを一旦格納するコンテンツ格納部と、コンテンツを受信端末の機器ＩＤおよび送信者毎に区別して管理するテーブルを有し、受信端末から要求があったとき、認証サーバが発行したワンタイムＩＤを利用して認証サーバにて認証を受けた後、受け取った機器ＩＤについて機器ＩＤテーブルを参照して、その受信端末の機器ＩＤが送信先とされるコンテンツをその受信端末に送信する。

また、認証サーバであって、機器からの受信した認証データと機器ＩＤからなる情報からユーザ情報と対応するサービスを確認するテーブルを有し、配信サーバが認証するためのワンタイムのＩＤを発行ならびに受信機器との関連を一時的に格納し、受信端末が送信端末から送信されたコンテンツを配信サーバ経由で受信する受信する際に認証する。

また、配信サーバが当該受信端末を特定する機器ＩＤを保持する機器ＩＤ保持部と、受信するコンテンツまたはコンテンツの送信者を選択する選択部と、受信したコンテンツを表示する表示部とを有し、受信機器は認証サーバへ当該受信端末の認証データと機器ＩＤを通知することで、ワンタイムＩＤを受け取り、それを配信サーバへ送信することで、配信サーバがそのワンタイムＩＤを認証サーバへ送信し当該の受信機器ＩＤを受け取る。受信機器は、配信サーバが格納している当該受信端末宛のコンテンツ一覧または送信者一覧を取得して表示する。

４…ネットワーク、
１０…送信端末（ＰＣ）、
２０…受信端末（テレビ）、
２１…ネットワーク送受信部、
２２…ブラウザ部、
２３…動画再生部、
２７…表示部、
２４…機器ＩＤ通知処理部、
２５…機器ＩＤ保持部、
２６…コンテンツ記録部、
３０…配信サーバ、
３１…ネットワーク送受信部、
３２…会員情報管理部、
３３…未読メールチェックテーブル、
３４…送信者ＤＢ、
３５…受信者ＤＢ、
３６…テレビ機器ＤＢ、
３７…コンテンツ管理テーブル、
３８…コンテンツ送受信部、
３９…コンテンツ格納部、
５０…携帯電話
７０…認証サーバ、
７２…会員情報管理部、
７６…テレビ機器ＤＢ、
７７…ワンタイムＩＤ管理テーブル、
８０…認証サーバ、
８２…会員情報管理部、
８５…会員ＤＢ、
８６…テレビ機器ＤＢ、
８７…ワンタイムＩＤ管理テーブル、

Claims (6)

1. 送信端末と受信端末がネットワークを介して配信サーバに接続され、該送信端末から該受信端末へ該配信サーバを経由して映像コンテンツを送信するコンテンツ配信システムにおいて、
   上記配信サーバは、
   上記受信端末を特定する情報を登録したデータベースと、上記送信端末から送信された映像コンテンツと、を格納する格納部と、
   上記送信端末および上記受信端末と情報の送受信を行う送受信部と、を有し、
   上記送信端末は、上記配信サーバに映像コンテンツと、該映像コンテンツの受信端末を特定する情報と、を送信する送信部を有し、
   上記配信サーバは、上記送信端末が送信した上記映像コンテンツの受信端末を特定する情報に基づき、上記受信端末に上記送信装置が送信した映像コンテンツを受信するか否かの問い合わせを通知し、
   上記受信端末が映像コンテンツの受信を承認した場合に、上記配信サーバは上記データベースに上記映像コンテンツの受信端末を特定する情報を登録し、上記映像コンテンツを上記格納部に格納し、
   上記配信サーバは上記受信端末から要求があった場合に、上記映像コンテンツを上記受信端末に送信することを特徴とするコンテンツ配信システム。
2. 請求項１において、前記送信端末が前記配信サーバの前記データベースに既に登録された受信端末に送信するための新たな映像コンテンツを前記配信サーバに送信した場合に、
   前記配信サーバは上記受信端末に新たな映像コンテンツを受信可能である旨の通知を送信することを特徴とするコンテンツ配信システム。
3. 送信端末と受信端末がネットワークを介して配信サーバに接続され、該送信端末から該受信端末へ該配信サーバを経由して映像コンテンツを送信するコンテンツ配信システムにおける配信サーバであって、
   上記受信端末を特定する情報を登録したデータベースと、上記送信端末から送信された映像コンテンツと、を格納する格納部と、
   上記送信端末および上記受信端末と情報の送受信を行う送受信部と、を有し、
   上記送受信部は、上記送信端末が送信した映像コンテンツと、該映像コンテンツの受信端末を特定する情報と、を受信し、
   上記配信サーバは、上記送信端末が送信した上記映像コンテンツの受信端末を特定する情報に基づき、上記受信端末に上記送信装置が送信した映像コンテンツを受信するか否かの問い合わせを通知し、
   上記受信端末が映像コンテンツの受信を承認した場合に、上記配信サーバは上記データベースに上記映像コンテンツの受信端末を特定する情報を登録し、上記映像コンテンツを上記格納部に格納し、
   上記配信サーバは上記受信端末から要求があった場合に、上記映像コンテンツを上記受信端末に送信することを特徴とする配信サーバ。
4. 請求項３において、前記送信端末が前記配信サーバの前記データベースに既に登録された受信端末に送信するための新たな映像コンテンツを前記配信サーバに送信した場合に、
   上記受信端末に新たな映像コンテンツを受信可能である旨の通知を送信することを特徴とする配信サーバ。
5. 送信端末と受信端末がネットワークを介して配信サーバに接続され、該送信端末から該受信端末へ該配信サーバを経由して映像コンテンツを送信するコンテンツ配信システムにおけるコンテンツ配信方法であって、
   上記送信端末は、上記配信サーバに映像コンテンツと、該映像コンテンツの受信端末を特定する情報と、を送信し、
   上記配信サーバは、上記送信端末が送信した上記映像コンテンツの受信端末を特定する情報に基づき、上記受信端末に上記送信装置が送信した映像コンテンツを受信するか否かの問い合わせを通知し、
   上記受信端末が映像コンテンツの受信を承認した場合に、上記配信サーバは上記データベースに上記映像コンテンツの受信端末を特定する情報を登録し、上記映像コンテンツを格納し、
   上記配信サーバは上記受信端末から要求があった場合に、上記映像コンテンツを上記受信端末に送信することを特徴とするコンテンツ配信方法。
6. 請求項５において、前記送信端末が前記配信サーバの前記データベースに既に登録された受信端末に送信するための新たな映像コンテンツを前記配信サーバに送信した場合に、
   上記受信端末に新たな映像コンテンツを受信可能である旨の通知を送信することを特徴とするコンテンツ配信方法。

Images