JP2008217048A - コンテンツ提供サーバ及びそのプログラム - Google Patents

Abstract

【課題】ＣＧＭ（Consumer Generated Media）型のサービスにおいて、商用コンテンツがユーザ機器からアップロードされた場合であっても、著作権侵害とならないようにするとともに、権利者の利益につながるようにする技術を提供することを目的とする。。
【解決手段】コンテンツ提供サーバにおいて、ユーザ機器から該サーバへとコンテンツファイルがアップロードされたとき、自動的に当該コンテンツを認識し、認識結果に応じて、サーバ上でのコンテンツの提供の仕方を変える。例えば、自動認識されたコンテンツが著作権保護が必要なものである場合、コンテンツの一部分のみを試聴用に提供するものとし、さらに自動的にアフィリエイト情報を付与し、アフィリエイト情報が付与された状態でコンテンツを提供する。ユーザは試聴用コンテンツを再生でき、アフィリエイト情報を利用して、関連商品の販売サイトにアクセスすることができる。
【選択図】図１８

Description

この発明は、ユーザ装置からアップロードされたマルチメディアデータなどの各種のコンテンツを、例えば別のユーザ装置に提供する、コンテンツ提供サーバ及びそのプログラムに関する。

ソーシャルネットワーキングサービス（ＳＮＳ）や、音楽や映像のファイル共有サービスのような、消費者自身がインターネットを利用して内容物（コンテンツ）を生成していくＣＧＭ（Consumer Generated Media）型と呼ばれるサービスがある。これらのサービスにおいては、消費者からアップロードされるコンテンツが商用コンテンツである場合があり、アップロードが著作権侵害となることが問題となっている。

その対策として、アップロードされたコンテンツが商用コンテンツであるか否かを、人力（目視）による判定で行うことが行われている。アップロードされたコンテンツを人力で判定し、公開するか否かを決定する方法としては、例えば下記特許文献１に記載の技術などが知られている。
特開２００２−０４１０５８

しかし、上記従来技術のように人力でコンテンツの判定を行う場合、アップロードされるコンテンツの量が多くなると対応しきれなくなる。そのため、アップロードされるコンテンツ量を人力で判定可能な少量に制限するか、あるいは判定する人を増やすことにより膨大な費用をかけるか、などの対策をとらねばならない。前者はコンテンツの量が制限されるという点でＣＧＭ型サービスの魅力が減ってしまうし、後者は費用が膨大となるためサービスの維持が困難になるという問題がある。また、別の問題として、コンテンツがサーバに掲載されるまでに時間がかかる、人力による照合のため間違いなどが発生する、などの不都合も生じる。更に、商用コンテンツがアップロードできないことにより、サービス自体の人気低下にもつながってしまう。

この発明は、ＣＧＭ（Consumer Generated Media）型のサービスにおいて、商用コンテンツがユーザ機器からアップロードされた場合であっても、著作権侵害とならないようにする技術を提供することを目的とする。また、商用コンテンツがアップロードされた場合であっても、権利者の利益につながるようにする技術を提供することを目的とする。

上記目的を達成するため、請求項１に係る発明は、ユーザ機器からアップロードされたコンテンツデータを蓄積し、該コンテンツデータをユーザ機器へと提供するコンテンツ提供サーバであって、前記ユーザ機器からコンテンツデータがアップロードされたとき、自動的に当該コンテンツデータを認識する手段と、前記コンテンツデータの認識結果に応じて、他のユーザ機器への当該コンテンツデータの提供の仕方を変更する制御手段とを備えることを特徴とする。

請求項２に係る発明は、請求項１に記載のコンテンツ提供サーバにおいて、前記制御手段は、前記認識したコンテンツデータが商用コンテンツ（著作権保護が必要なもの）であるか否かに応じて、提供するコンテンツデータの時間長を変えるものであることを特徴とする。

請求項３に係る発明は、請求項１または２に記載のコンテンツ提供サーバにおいて、前記制御手段は、前記認識されたコンテンツデータが商用コンテンツである場合に、自動的に該商用コンテンツデータに関連する商品の購入サイトへのリンク情報であるアフィリエイト情報を付与し、該リンク情報が付与された状態でコンテンツデータを提供するものであることを特徴とする。

請求項４に係る発明は、コンピュータを、ユーザ機器からアップロードされたコンテンツデータを蓄積し該コンテンツデータをユーザ機器へと提供するコンテンツ提供サーバとして機能させるコンテンツ提供プログラムであって、前記コンピュータを、前記ユーザ機器からコンテンツデータがアップロードされたとき、自動的に当該コンテンツデータを認識する手段と、前記コンテンツデータの認識結果に応じて、他のユーザ機器への当該コンテンツデータの提供の仕方を変更する制御手段として、機能させることを特徴とするコンテンツ提供プログラムである。

本発明によれば、ユーザからコンテンツがサーバにアップロードされたとき、人力ではなく自動的に当該コンテンツを認識するので、コンテンツ量を制限したり、人を増やすことに費用をかけることなどの問題をクリアすることができる。また、サーバへの掲載までの時間も短縮でき、さらに間違い発生の確率も減らすことができる。また、商用コンテンツのアップロードを禁止するのではなく、積極的にビジネスに結びつけることにより、サービスの人気向上も期待できる。

以下、図面を用いてこの発明の実施の形態を説明する。

図１は、この発明の実施形態であるソーシャルネットワーキングシステムの全体システム構成を示す。インターネットなどのワイドエリアネットワーク１０１に、ＳＮＳサーバ１０２と、各ユーザのＰＣ１０３，１０４，１０５が接続されている。これらのＰＣ１０３〜１０５の各ユーザは、予め本ＳＮＳに登録してあるユーザとする。各ユーザは、それぞれ、携帯型メディアプレイヤー（以下「ＭＭＰ」と言う）１０６Ａ，１０７Ａ，１０８Ａを持っている。なお、ここでは３人のユーザを仮定したが、ユーザの数は任意である。また、コンテンツ提供サーバであるＳＮＳサーバ１０２は、ユーザからアップロードされたコンテンツが商用コンテンツか否かを判別し、商用コンテンツである場合は、当該コンテンツの他ユーザへの提供の仕方を変更する機能を備えているが、これについては図１７及び図１８で詳しく説明する。

ユーザＡは、自己のＰＣ１０３上に保持しているオーディオデータやビジュアルデータなどのマルチメディアデータファイル（以下「コンテンツ」と言う）を、ＳＮＳサーバ１０２上の当該ユーザに割り当てられている領域（ネットワークストレージ）にアップロードすることができる。また、ユーザＡは、ＰＣ１０３上のコンテンツをＭＭＰ１０６Ａに転送し、ＭＭＰ１０６Ａ内の記憶領域（ローカルストレージ）に記憶させることができる。ＭＭＰ１０６Ａは、ローカルストレージ内のコンテンツを、ユーザの指示に応じて再生することができる。ＳＮＳサーバ１０２のネットワークストレージにアップロードした自己のコンテンツについては、自己のＰＣ１０３によりストリーミング再生したりダウンロードすることができる。ユーザＢのＰＣ１０４及びＭＭＰ１０７Ａ、並びに、ユーザＣのＰＣ１０５及びＭＭＰ１０８Ａも同様である。各ユーザは自分の持っているＭＭＰ１０６Ａ，１０７Ａ，１０８Ａを持って外出することができる。１０６Ｂ，１０７Ｂ、１０８Ｂは、ユーザＡ，Ｂ，Ｃがそれぞれ外出時に持っていったＭＭＰを示す。各ＭＭＰは、それぞれ自ＭＭＰ内のローカルストレージに保持されているコンテンツを再生することができる。

本ＳＮＳでは、ユーザ間の関係として「友人」と「親友」を登録することができる。「親友」は、「友人」関係にあるユーザ同士がさらに親しい関係になったときに互いの同意のもとに登録するものであり、ここでは「親友」として登録できるのは１ユーザにつき５人までの制限があるものとする。ここでは、図１の各ユーザＡ，Ｂ，Ｃが互いに親友として登録されているものとする。そして、ＳＮＳサーバ１０２は、「友人」又は「親友」設定された各ユーザの間でオンラインコミュニティを形成するサービスを提供する。提供されるサービスとしては、日記サービスやメールサービスなどのコミュニケーション用のサービスがある。なお、これらのサービスについては公知であるので詳細な説明は省略する。また、本ＳＮＳは、「親友」設定されたごく限られたユーザ間でのみ音楽コンテンツを共有できる共有サービスも提供する。

ネットワーク１０１には、無線ＬＡＮ１０９の複数の基地局（以下「ホットスポット」と言う）が接続されている。各ＭＭＰは、Ｗｉ−Ｆｉ（商標）などの無線中距離通信機能とＢｌｕｅｔｏｏｔｈ（商標）などの無線近距離通信機能を備えている。例えば、ユーザＡのＭＭＰ１０６Ｂは、無線中距離通信機能を用いて、無線ＬＡＮ１０９及びネットワーク１０１経由でＳＮＳサーバ１０２にアクセスすることができる。これにより、ユーザＡのＭＭＰ１０６Ｂは、当該ユーザＡのネットワークストレージのコンテンツをストリーミング再生することができる。また、各ユーザは、自己と親友の関係にあるユーザのネットワークストレージコンテンツをストリーミング再生することができる。例えば、ユーザＢはユーザＡと親友関係にあるので、ユーザＢのＭＭＰ１０７Ｂは、無線ＬＡＮ１０９及びネットワーク１０１経由でＳＮＳサーバ１０２のユーザＡのネットワークストレージコンテンツにアクセスしストリーミング再生することができる。さらに、親友関係にあるユーザのＭＭＰ同士でコンテンツのストリーミング再生を行うことができる。例えば、ユーザＢとＣは親友関係にあるので、ユーザＢのＭＭＰ１０７Ｂは、無線近距離通信機能によりユーザＣのＭＭＰ１０８Ｂにアクセスし、ユーザＣのローカルストレージコンテンツをストリーミング再生することができる。ユーザＣのＭＭＰ１０８Ｂで、ユーザＢのＭＭＰ１０７Ｂ内のローカルストレージコンテンツをストリーミング再生することも可能である。

図２は、ＳＮＳサーバ１０２のハードウェア構成の概略を示すブロック図である。ＳＮＳサーバ１０２は、中央処理装置（ＣＰＵ）２０１、リードオンリメモリ（ＲＯＭ）２０２、ランダムアクセスメモリ（ＲＡＭ）２０３、記憶装置２０４、ネットワークインターフェース（Ｉ／Ｆ）２０５、操作子２０６、ディスプレイ２０７、及びバスライン２０８を備える。２０１〜２０７の各部はバスライン２０８により相互に接続され、各種のデータをやり取りすることができる。

ＣＰＵ２０１は、本サーバ全体の動作を制御する処理装置である。ＲＯＭ２０２は、ＣＰＵ２０１が実行する各種のプログラムや各種のデータなどを格納した不揮発性メモリである。ＲＡＭ２０３は、ＣＰＵ２０１が実行するプログラムのロード領域やワーク領域に使用する揮発性メモリである。記憶装置２０４は、例えばハードディスク装置などの外部記憶装置であり、ＣＰＵ２０１が実行する各種のプログラムや各ユーザのユーザデータが格納される。ネットワークＩ／Ｆ２０５は、本サーバをネットワーク１０１に接続するためのインターフェースである。操作子２０６は、キーボード及びマウスなどの入力装置である。ディスプレイ２０７は、各種の情報を表示するための表示装置である。

図３は、各ユーザが持つＭＭＰのハードウェア構成の概略を示すブロック図である。ＭＭＰは、ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、記憶装置３０４、無線近距離通信Ｉ／Ｆ３０５、無線中距離通信Ｉ／Ｆ３０６、有線通信Ｉ／Ｆ３０７、操作子３０８、ディスプレイ３０９、音源３１０、オーディオデコーダ３１１、サウンドシステム３１２、及びバスライン３１３を備える。

ＣＰＵ３０１は、本ＭＭＰ全体の動作を制御する処理装置である。ＲＯＭ３０２は、ＣＰＵ３０１が実行する各種のプログラムや各種のデータなどを格納した不揮発性メモリである。ＲＡＭ３０３は、ＣＰＵ３０１が実行するプログラムのロード領域やワーク領域に使用する揮発性メモリである。記憶装置３０４は、例えばフラッシュメモリなどの記憶装置であり、各ユーザのユーザデータが格納される。無線近距離通信Ｉ／Ｆ３０５は、近距離の無線通信機能を提供するインターフェースであり、例えばＢｌｕｅｔｏｏｔｈ（商標）などである。無線中距離通信Ｉ／Ｆ３０６は、中距離の無線通信機能を提供するインターフェースであり、例えばＷｉ−Ｆｉ（商標）などである。有線通信Ｉ／Ｆ３０７は、本ＭＭＰをＰＣと接続するための有線のインターフェースであり、例えばＵＳＢなどである。操作子３０８は、本ＭＭＰに各種の指示を与えるためのスイッチなどである。ディスプレイ３０９は、本ＭＭＰの外部パネル上に設けられた各種の情報を表示するための表示装置である。音源３１０は、ＣＰＵ３０１の指示に応じてデジタル楽音信号を生成する。オーディオデコーダ３１１は、ＣＰＵ３０１の指示に応じて、与えられたオーディオデータをデコードし、デジタル音響信号として出力する。サウンドシステム３１２は、音源３１０やオーディオデコーダ３１１から出力されるデジタル音響信号をアナログ音響信号に変換して放音する。

図４は、各ユーザ毎のユーザデータの構成例を示す。

図４（ａ）は、ＳＮＳサーバ１０２に保持される各ユーザのユーザデータを示す。ＳＮＳサーバ１０２内のユーザデータは、個人情報、親友リスト、友人リスト、音楽コンテンツ、メールデータ、及び日記データなどを備える。個人情報は、当該ユーザを特定するユーザＩＤ、プレイヤＩＤ１〜ＩＤ３、及びユーザ名称などである。プレイヤＩＤ１〜ＩＤ３は、当該ユーザが所持するＭＭＰを特定するＩＤである。ここではユーザ１人につき３台のＭＭＰまで登録できることとした。親友リストは、当該ユーザの親友のユーザＩＤ及びそのユーザが親友として追加された日時を示す追加日時データを備える。また、親友リストから一旦削除したユーザＩＤを再び親友として回復させることがあるので、削除した親友ユーザＩＤとその削除日時を記憶している。なお、親友関係にあるユーザは、互いの親友リストにそれぞれ親友として登録されているものであり、第１のユーザが第２のユーザを親友として登録しているが第２のユーザは第１のユーザを親友としていないということはあり得ない。また、本例では、親友として登録できるのは１ユーザに対して５人までとした。これは、その程度の少人数であれば、個人利用の範囲内として合法的にコンテンツを共有できると考えられるからである。友人リストは、当該ユーザの友人のユーザＩＤの一覧である。音楽コンテンツは、当該ユーザに与えられたネットワークストレージに記憶されたコンテンツデータを示す。メールデータや日記データは、当該ユーザがＳＮＳ内で利用しているメールや日記のデータである。

図４（ｂ）は、各ユーザが所持するＭＭＰ内のユーザデータの構成を示す。このユーザデータは、個人情報、親友リスト、及び音楽コンテンツを備える。個人情報は、当該ＭＭＰの持ち主であるユーザのユーザＩＤ、当該ＭＭＰを特定するプレイヤＩＤ、及びユーザ名称などの情報である。親友リストは、図４（ａ）で説明した当該ユーザのＳＮＳサーバ内の親友リストと同じものである。音楽コンテンツは、当該ＭＭＰ内のローカルストレージに記憶されたコンテンツデータを示し、当該ＭＭＰで単独で再生できる音楽コンテンツデータである。

図５は、各ユーザのＭＭＰで音楽コンテンツを再生する形態を示す。図５（ａ）は、ユーザが自己のローカルストレージから読み出した音楽コンテンツを再生する形態である。これは、ユーザが自己のＭＭＰで該ＭＭＰ内の記憶手段（ローカルストレージ）に記憶されている音楽コンテンツを再生する場合に相当する。図５（ｂ）は、ユーザが自己のネットワークストレージから読み出した音楽コンテンツを再生する形態である。これは、ユーザが自己のＭＭＰで、自己に割り当てられたＳＮＳサーバ１０２内の記憶領域（ネットワークストレージ）から読み出した音楽コンテンツを中距離無線通信機能を用いて受信し、ストリーミング再生する場合に相当する。図５（ｃ）は、ユーザが親友のネットワークストレージから読み出した音楽コンテンツを再生する形態である。これは、ユーザが自己のＭＭＰで、自己の親友に割り当てられたＳＮＳサーバ１０２内の記憶領域から読み出した音楽コンテンツを中距離無線通信機能を用いて受信し、ストリーミング再生する場合に相当する。図５（ｄ）は、ユーザが親友のローカルストレージから読み出した音楽コンテンツを再生する形態である。これは、ユーザが自己のＭＭＰで、自己の親友のＭＭＰ内の記憶領域から読み出した音楽コンテンツを近距離無線通信機能を用いて受信し、ストリーミング再生する場合に相当する。

図６は、ＰＣによる親友登録の手順を示すフローチャートである。ここでは、ユーザＡがユーザＢに対して親友になりたい旨の要求を出す場合を例として説明する。

ステップ６０１では、ユーザＡのＰＣ１０３において、ユーザＡがユーザＢと親友になりたい旨の要求を入力する。なお、このときユーザＡの親友リストに既に５人の親友が登録されていた場合は、ユーザＡに、５人の親友のうちの１人を削除予約ユーザとして指定させる。そして、ユーザＢが親友になることを承認した場合は、前記削除予約ユーザを親友リストから削除し、ユーザＢを親友リストに登録する。ユーザＢが親友になることを拒否した場合は、前記削除予約ユーザは親友のままである。もちろんユーザＡの親友リストに空きがある場合は、削除予約ユーザを指定させる必要はない。

ステップ６０１で、ユーザＡのＰＣ１０３は、ネットワーク１０１経由でＳＮＳサーバ１０２に前記要求を送信する。その要求を受信したＳＮＳサーバ１０２は、ステップ６０２で、ユーザＢのＰＣ１０４に対して、ユーザＡからユーザＢと親友になりたい旨の要求があったことを示すメッセージ（メール）を送信する。ユーザＢは自己のＰＣ１０４で、該メッセージを受信し、ステップ６０３で、該要求に対して承認または拒否の回答をＳＮＳサーバ１０２に送信する。ＳＮＳサーバ１０２は、該回答を受信し、ステップ６０４で、その回答が承認か拒否かを判定する。

承認の場合、ＳＮＳサーバ１０２は、ステップ６０５で、ユーザＡとユーザＢの親友リスト（図４（ａ））を更新する。これは、ユーザＡの親友リストにユーザＢを登録し、ユーザＢの親友リストにユーザＡを登録する処理である。またＳＮＳサーバ１０２は、ステップ６０６で、ユーザＡのＰＣ１０３に更新した旨を通知する。ユーザＡのＰＣ１０３は、ステップ６０９で、該通知を受信し表示する。ステップ６０４でユーザＢの回答が拒否であった場合、ＳＮＳサーバ１０２は、ステップ６０７で、削除予約したユーザＩＤを元の親友に回復し（削除予約ユーザがなかったときはステップ６０７はスキップする）、ステップ６０８で、ユーザＢから拒否の回答があった旨をユーザＡのＰＣ１０３に通知する。ユーザＡのＰＣ１０３は、ステップ６０９で該通知を受信し表示する。

図７は、図６のステップ６０１でユーザＡがユーザＢと親友になりたい旨の要求を出す際の画面例を示す。ユーザＡは、自己のＰＣ１０３を用いてネットワーク１０１経由でＳＮＳサーバ１０２に接続し、自己の友人や親友を登録・更新する画面を表示する。７０１がユーザＡのＰＣ１０３に表示された画面例を示す。７１１は全ユーザの一覧表示、７１４は当該ユーザＡの親友の一覧表示、７１５は当該ユーザＡの友人の一覧表示である。全ユーザ一覧表示７１１中の各ユーザに対応して、友人ボタン７１２と親友ボタン７１３が表示されている。ユーザＡは、友人としたいユーザの友人ボタン７１２をオンすることで、当該ユーザを友人として登録できる。また、友人として登録されているユーザの親友ボタン７１３をオンすることで、当該ユーザを友人として登録できる。

いまユーザＡが、全ユーザ一覧表示７１１中のユーザＢの親友ボタン７１３をオンしたとする。このとき、ユーザＡの親友リストの登録人数が５人未満であれば、親友リストに空きがあるということであるから、ユーザＡのＰＣ１０３は、メッセージ７０５を表示し、ユーザＡからのユーザＢに対する親友登録の要求をＳＮＳサーバ１０２に送信する。この要求の送信は、図６のステップ６０１における要求の送信に対応する。

ユーザＡの親友リストの登録人数が５人のときは、画面７０２のようにユーザＡの親友の一覧７０３を表示し、ユーザＡに削除予約するユーザを指定させる。７３１は親友毎の削除予約ボタンである。ユーザＡが親友であるユーザＸの削除予約ボタン７３１をオンすると、ユーザＡのＰＣ１０３は、画面７０４を表示し、ユーザＡからのユーザＢに対する親友登録の要求をＳＮＳサーバ１０２に送信する。この要求の送信は、図６のステップ６０１における要求の送信に対応する。

図８は、図６のステップ６０２でＳＮＳサーバ１０２が送信したメッセージを受信したユーザＢのＰＣ１０４が、ステップ６０３の回答を行う際の画面例を示す。ステップ６０２でＳＮＳサーバ１０２がユーザＢのＰＣ１０４に送信するメッセージは、図８の８０１に示すようなメールである。このメール８０１を受信したユーザＢは、自己のＰＣ１０４を用いて、当該メール８０１に記載されたＵＲＬ（ＳＮＳサーバ１０２）に接続する。ＳＮＳサーバ１０２は、このＵＲＬに対するアクセス要求があると、ユーザＡからの親友登録要求に対してユーザＢが回答するためにアクセスしてきたことを認識し、当該ユーザＢの親友リストの登録人数をチェックする。登録人数が５人未満のとき、ＳＮＳサーバ１０２は、画面８１１をユーザＢのＰＣ１０４に返す。ユーザＢは、ユーザＡの親友としての登録を拒否する場合はＮＯボタン８１３をオンする。この場合、ユーザＢのＰＣ１０４は、メッセージ８１５を表示するとともに、ＳＮＳサーバ１０２に「拒否」の回答を送信する。この回答は、図６のステップ６０３で拒否の回答を送信する部分に対応する。

画面８１１で、ユーザＢがユーザＡの親友としての登録を承認する場合はＹＥＳボタン８１２をオンする。この場合、ユーザＢのＰＣ１０４は、メッセージ８１４を表示するとともに、ＳＮＳサーバ１０２に「承認」の回答を送信する。この回答は、図６のステップ６０３で承認の回答を送信する部分に対応する。該承認の回答を受信したＳＮＳサーバ１０２は、上述の図６のステップ６０５，６０６の処理を行う。メッセージ８０９は、ＳＮＳサーバ１０２がステップ６０６でユーザＡに送信した通知であるメールの例を示し、特にユーザＡがユーザＸを削除予約してあった場合のメール例を示す。該メールにはＯＫボタン８１０が表示されており、ユーザＡが該ＯＫボタン８１０をオンすると、ユーザＡのＰＣ１０３からＳＮＳサーバ１０２にその旨が通知され、ＳＮＳサーバ１０２は該通知を受けてユーザＡの親友リストから削除予約してあったユーザＸを削除し、その旨を示すメールをユーザＸに送信する。

なお、図４（ａ）に示したユーザデータの親友リストのデータ構造で上記削除予約の処理を実現する方式は任意であるが、ここでは現親友リストの中から削除予約された親友ユーザＩＤを、削除分リストの先頭の削除親友ユーザＩＤ１の欄に移動しておき（この移動前の削除親友ユーザＩＤ１〜ＩＤ４はそれぞれ削除親友ユーザＩＤ２〜ＩＤ５の欄に写して削除親友ユーザＩＤ１の欄を空けるものとする）、削除が確定したら当該削除親友ユーザＩＤ１の削除日時を設定し、削除せずに復活させるときは当該削除親友ユーザＩＤ１のユーザＩＤを現親友リストに戻せばよい（削除親友ユーザＩＤ２〜ＩＤ５も削除親友ユーザＩＤ１〜ＩＤ４に戻す）。あるいは現親友リストの親友ユーザ毎に削除予約フラグを設け、削除予約されたときには該フラグをオンし、削除が確定したら該フラグがオンされている親友ユーザを削除し、削除せずに復活させるときは該フラグをオフに戻せばよい。

ユーザＢの親友リストの登録人数が５人であった場合、ＳＮＳサーバ１０２は、画面８０２をユーザＢのＰＣ１０４に返す。８０３はユーザＢの親友の一覧表示であり、各親友毎に削除ボタン８３１が表示されている。ユーザＢは、削除する親友の削除ボタン８３１をオンしてＹＥＳボタン８０４をオンする。いまユーザＹの削除ボタン８３１がオンされたとする。ユーザＢのＰＣ１０４は、その旨をＳＮＳサーバ１０２に通知する。ＳＮＳサーバ１０２は、該通知に応じてユーザＢの親友リストからユーザＹを削除し、新たにユーザＡを登録するとともに、ユーザＹにユーザＢの親友リストから削除した旨を示すメールを送信する。なお、この場合、ＳＮＳサーバ１０２は、ユーザＹの親友リストからユーザＢを削除する処理も行うものとする。ユーザＢのＰＣ１０４は、メッセージ８０７を表示するとともに、ＳＮＳサーバ１０２に「承認」の回答を送信する。この回答は、図６のステップ６０３で承認の回答を送信する部分に対応する。これ以降の処理手順は、メッセージ８１４以降で説明したのと同様である。

画面８０２で、ユーザＢがキャンセルボタン８０５をオンした場合は、画面８０２を消去して親友登録の処理をキャンセルする。この場合は、再び受信メール８０１からの処理をやり直す必要がある。画面８０２で、ユーザＢがＮＯボタン８０６をオンすると、ユーザＢのＰＣ１０４は、メッセージ８０８を表示するとともに、ＳＮＳサーバ１０２に「拒否」の回答を送信する。この回答は、図６のステップ６０３で拒否の回答を送信する部分に対応する。

図９は、ＭＭＰでの親友登録の処理を示す。ユーザＡとＢが外出先で互いに親友登録したい場合、まずステップ９０１，９１１で近距離通信機能を利用してＭＭＰ同士の接続処理を行い、ステップ９０２，９１２で個人情報（図４（ｂ）に示したＭＭＰ内の個人情報のうち他者への公開が許可されている情報）の交換を行う。ステップ９０３で、ユーザＡのＭＭＰからユーザＢのＭＭＰへ、近距離通信機能を利用して、ユーザＢと親友になりたい旨の要求を送信する。該要求を受信したユーザＢのＭＭＰは、ステップ９１３で、承認または拒否の回答を返信する。該返信を受信したユーザＡのＭＭＰは、ステップ９０４で、その回答が承認か拒否かをチェックする。承認であった場合、ステップ９０５で、ユーザＡのＭＭＰ内の親友リスト（図４（ｂ））にユーザＢを追加し、ステップ９０６で、更新した旨をメッセージ表示して、処理を終了する。ステップ９０４で拒否されたときは、ステップ９０７で、その旨を表示して、処理を終了する。ユーザＢのＭＭＰでは、ステップ９１４で、返信した回答が承認か拒否かをチェックする。承認であるときは、ステップ９１５で、ユーザＢのＭＭＰ内の親友リスト（図４（ｂ））にユーザＡを追加し、処理を終了する。回答が拒否であるときは、そのまま処理を終了する。なお、ＭＭＰ内の親友リストに親友を登録する際、既に５人の親友が登録されていた場合は、ユーザに削除する親友を選択させ、親友リストに空きを作ってから登録するものとする。

図１０は、親友リストの同期の処理を示す。図６のＰＣによる親友の登録と図９のＭＭＰによる親友の登録とは全く独立して行われるので、あるユーザについて、ＳＮＳサーバ１０２内の親友リストの内容とＭＭＰ内の親友リストの内容とが異なるようになる場合がある。そこで、ＭＭＰがＳＮＳサーバと通信可能になった場合（例えば、ユーザが自己のＰＣに自己のＭＭＰを接続した場合、またはＭＭＰが無線ＬＡＮ１０９のホットスポットに接続した場合など）、図１０の同期処理により親友リストを同期させる。この同期処理は、ＭＭＰ側からユーザが指示したときに実行してもよいし、ＭＭＰとＳＮＳサーバ１０２が接続されたとき自動で実行してもよい。

ＭＭＰは、ステップ１００１で、同期要求と自ＭＭＰ内の親友リストをＳＮＳサーバ１０２に送信する。ＳＮＳサーバ１０２は、ステップ１０１１で、受信した親友リストと、ＳＮＳサーバ１０２内の当該ユーザの親友リストとを比較し、更新する。この処理は、ＭＭＰ内の親友リストに登録されている親友ユーザＩＤとＳＮＳサーバ１０２の親友リストに登録されている親友ユーザＩＤとをマージし、マージした結果、親友の人数が５人を超える場合は、追加日時が新しい５人分の親友ユーザＩＤを親友リストとし、それ以外の親友ユーザＩＤは削除する処理である。ステップ１０１１で親友リストが更新された場合、更新された親友側の親友リストの更新が必要になる場合があるので、ステップ１０１２ではその処理を行う。ステップ１０１３で、更新後の親友リストをＭＭＰに送信する。ＭＭＰは、ステップ１００２で、該親友リストを受信し、ＭＭＰ内に保存して、終了する。

図１１は、ＰＣにおける親友リストの更新及び同期時の親友リストの更新の処理を示す。本処理は、図６のステップ６０５で親友リストが更新されたとき、その更新された親友の親友リストも更新する必要がある場合にＳＮＳサーバ１０２で実行される。例えば、ユーザＡの親友リストからユーザＢが削除されたとき、そのユーザＢの親友リストからユーザＡを削除する必要があるが、そのような処理を行うのが図１１の処理である。また、図１０の同期処理のステップ１０１１で親友リストを更新した場合も、その更新したユーザ側の親友リストを更新する必要が生じる場合がある。その場合、ステップ１０１２で図１１の処理を行う。

ステップ１１０１で、更新対象の親友リストからの削除が発生しているか判定する。これはステップ６０５やステップ１０１１で親友リストからの削除が実行されているかを判定するものである。削除が発生しているときは、ステップ１１０２で、削除されたユーザの親友リストから削除原因ユーザ（すなわち、ステップ６０５やステップ１０１１で削除が実行された親友リストをユーザデータとして持つユーザ）を削除する。また、ステップ１１０３で、削除されたユーザに対し、削除原因ユーザの都合により削除された旨をメールで通知する。ステップ１１０１で削除が発生していない場合は、ステップ１１０４に進む。

ステップ１１０４で、更新対象の親友リストへの追加が発生しているか判定する。これはステップ６０５やステップ１０１１で親友リストへの追加が実行されているかを判定するものである。追加が発生しているときは、ステップ１１０５で、追加されたユーザの親友リストに追加原因ユーザ（すなわち、ステップ６０５やステップ１０１１で追加が実行された親友リストをユーザデータとして持つユーザ）を追加する。また、ステップ１１０６で、追加されたユーザに対し、追加原因ユーザの親友として追加された旨をメールで通知する。ステップ１１０４で削除が発生していない場合は、そのまま終了する。

図１２は、ＭＭＰによる再生処理を示す。ユーザがＭＭＰに対して再生を指示すると、ＭＭＰは、ステップ１２０１で無線ＬＡＮによる通信が可能かをチェックする。可能であれば、ステップ１２０２で、その通信（中距離無線通信）によりＳＮＳサーバ１０２から音楽コンテンツ（当該ユーザのネットワークストレージに格納されたもの、及び、当該ユーザの親友のネットワークストレージに格納されたもの）のリストを取得する。ステップ１２０３で近距離無線通信による通信が可能かをチェックする。可能であれば、ステップ１２０４で、その近距離無線通信により、近くにいる全ての親友のＭＭＰから音楽コンテンツ（当該親友のＭＭＰ内のローカルストレージに格納されたもの）のリストを取得する。

次に、ステップ１２０５で、コンテンツリストを表示する。これは、自ＭＭＰ内のローカルストレージに格納された音楽コンテンツと、ステップ１２０２，１２０４で取得した音楽コンテンツのリストを合わせて、表示する処理である。ステップ１２０６で、表示されたリストからユーザが再生したい曲を選曲すると、ステップ１２０７で、再生を開始する。この再生は、自ＭＭＰ内のローカルストレージに格納された音楽コンテンツの再生であればそのままそのコンテンツを読み出して再生する処理であり、ＳＮＳサーバ１０２や他ユーザのＭＭＰ内のローカルストレージに格納された音楽コンテンツの再生であれば図１６で後述するストリーミング再生処理で再生する処理である。

図１３は、ステップ１２０５で音楽コンテンツのリストを表示する際の表示例を示す。ストレージ別に表示する場合は、まず図１３（ａ）のように、自ＭＭＰのほかにステップ１２０２や１２０４でリストを取得したストレージを特定する情報をメニュー表示する。ユーザがこれらのストレージから１つを選択すると、そのストレージ内の音楽コンテンツのリストを表示する。図１３（ｂ）は、曲別の音楽コンテンツのリスト表示例である。各曲毎にその曲が格納されているストレージを表示している。

図１４は、図１２のステップ１２０２で実行される中距離通信機能を利用したＳＮＳサーバ１０２からの音楽コンテンツリストの取得処理を示す。ステップ１４１１で、ＭＭＰがユーザＩＤとプレイヤＩＤをＳＮＳサーバ１０２に送信する。ＳＮＳサーバ１０２は、ステップ１４０１で、それらを受信し、当該ユーザＩＤが登録されているユーザ個人情報を検索する。ステップ１４０２では、検索された当該ユーザＩＤの個人情報に当該プレイヤＩＤが登録されているかチェックする。登録されていない場合は、ステップ１４０３から１４０８に進み、当該ユーザまたはＭＭＰが登録されていない旨の警告をＭＭＰに送信する。ＭＭＰは、その警告を受信し、ステップ１４１２から１４１４に進み、警告表示を行う。

ステップ１４０３で登録されていた場合は、ステップ１４０４で、親友リストの同期処理（図１０）を行い、ＭＭＰ内の親友リストの内容とＳＮＳサーバ内の当該ユーザの親友リストの内容とを一致させる。次にステップ１４０５で、当該ユーザのユーザデータ中の音楽コンテンツのリストを作成し、さらにステップ１４０６で、当該ユーザの親友リストに登録されているユーザのユーザデータ中の音楽コンテンツのリストを作成する。ステップ１４０７で、作成した音楽コンテンツのリストをＭＭＰに送信する。ＭＭＰは、ステップ１４１３でそのリストを受信する。

図１５は、図１２のステップ１２０４で実行される近距離通信機能を利用した親友のＭＭＰからの音楽コンテンツリストの取得処理を示す。ステップ１５１１で、自ＭＭＰがユーザＩＤを他ＭＭＰに送信する。他ＭＭＰは、ステップ１５０１で、受信したユーザＩＤが当該他ＭＭＰ内の親友リストに登録されているか判定する。登録されていない場合は、ステップ１５０４で、当該他ＭＭＰから警告を送信する。自ＭＭＰは、その警告を受信し、ステップ１５１２から１５１４に進み、警告表示を行う。ステップ１５０１で登録されていた場合は、ステップ１５０２で、当該他ＭＭＰ内に記憶されている音楽コンテンツのリストを作成し、ステップ１５０３で、そのリストを自ＭＭＰに送信する。自ＭＭＰは、ステップ１５１３でそのリストを受信する。

図１６は、図１２のステップ１２０７で実行する再生処理のうち、ＳＮＳサーバ１０２の曲データをストリーミング再生する処理を示す。ＭＭＰは、ステップ１６０１で、選曲された曲のストリーミングをＳＮＳサーバ１０２に要求する。該要求を受信したＳＮＳサーバ１０２は、ステップ１６１１で、その曲データをストリーミング配信する。ＭＭＰは、ステップ１６０２で、配信された曲データを受信しストリーミング再生を行う。自ＭＭＰで、親友ユーザの持つ他ＭＭＰ内の曲データを受信してストリーミング再生する場合も同様である。

上記実施形態では、親友として登録できる人数を５人までとしたが、個人使用の範囲内と解釈できる数であればその数は任意である。また、親友リストに登録可能な人数分の登録がある状態で新たに親友登録するとき、ユーザに削除する親友を指定させるようにしているが、ユーザに指定させる代りに、所定条件により自動的に削除する親友を決定してもよい。例えば、メールなどのやり取りが少ない親友を削除する、などである。親友リストから削除した場合、友人としては残しておくのが好ましい。

上記実施形態では、ＭＭＰ同士で曲のストリーミング再生を行う際に、曲を聴きたい側のユーザのＭＭＰから曲を提供する側のユーザのＭＭＰに対して要求を発行しているが、そのような形態でなくても良い。例えば、ＭＭＰ同士で接続し互いに親友であることが確認されたら、一方のＭＭＰが曲を選択してストリーミング配信で他方のＭＭＰに送信し再生させるようにしても良い。

また、上記実施形態では音楽コンテンツを共有する例で説明したが、音楽コンテンツに限らず、本発明は種々のマルチメディアデータに適用可能である。

上記の説明では、ユーザがアップロードしたコンテンツファイルの全体を他のユーザが再生できるかのように説明した。もちろん当該コンテンツファイルが著作権上何ら問題のないデータである場合は、そのコンテンツを複数ユーザで共有してもよい。しかし、当該コンテンツファイルが商用のデータである場合は、複数ユーザで共有させてしまうように取り扱うのは著作権上問題がある。そこで、本実施形態のＳＮＳサーバ１０２では、コンテンツ提供サーバであるＳＮＳサーバ１０２に対してユーザがコンテンツファイルをアップロードする場合に、そのコンテンツが例えば商用コンテンツであっても、著作権侵害とならず、権利者の利益が損なわれないようにする機能を備えるようにした。

図１７は、上述したＳＮＳサーバ１０２に接続されている、コンテンツ認識サーバ１７０１、アフィリエイト提供サーバ１７０２、及び関連商品販売サーバ１７０３を示す。これらのサーバ１７０１〜１７０３は、図１７では別体のハードウェアで構成し、ネットワーク経由で相互にアクセスするものとしたが、ＳＮＳサーバ１０２と共通のハードウェアで実現してもよい。図１８は、図１７の構成のシステムにおける処理の手順を示す。

いま図１７のユーザＡのＰＣ１０３からＳＮＳサーバ１０２へとコンテンツがアップロードされたとする。図１８のステップ１８０１がそのアップロードの処理である。ＳＮＳサーバ１０２は、ステップ１８１１でそのコンテンツを受信し、ステップ１８１２でそのコンテンツのフィンガープリントを抽出する。フィンガープリントとは、コンテンツの指紋のようなデータであり、そのコンテンツの特徴部分を抜き出してデータ化したもので、コンテンツ毎に特有の値をもつデータである。ＳＮＳサーバ１０２は、ステップ１８１３で、抽出したフィンガープリントをコンテンツ認識サーバ１７０１に送信し、照会を行う。

コンテンツ認識サーバ１７０１は、商用コンテンツに関するフィンガープリントを格納したフィンガープリントデータベースを備えているものとし、ステップ１８３１で、送られてきたフィンガープリントをフィンガープリントデータベースと照合する。ステップ１８３２で、照合の結果、一致度が所定値以上なら、当該フィンガープリントと対応付けて予め蓄積されているコンテンツメタデータ（曲名、アーティスト名、作詞者名、及び作曲者名などの、当該コンテンツを特定するための各種データであり、商用コンテンツであるか否かのデータを含む）をＳＮＳサーバ１０２に応答する。照合の結果、一致度が所定値未満なら、認識できなかった旨を応答する。

ＳＮＳサーバ１０２は、コンテンツ認識サーバ１７０１からの応答を受信し、ステップ１８１４で、その照会結果を当該コンテンツに対応付けて保存する。これにより、当該コンテンツのメタデータが取得できた場合は、該メタデータを保存し、取得できなかった場合（コンテンツが認識できなかった場合）は、その旨が当該コンテンツと対応付けられて保存されることになる。従って、ユーザによりアップロードされたコンテンツの素性が明らかとなる。なお、コンテンツのフィンガープリントの抽出とコンテンツ認識の技術については、例えば米国特許２００３／００８６３４１などに開示されている。

次に、ＳＮＳサーバ１０２は、ステップ１８１５で、当該コンテンツが商用コンテンツか判定する。商用コンテンツ（著作権保護が必要なコンテンツ）のときは、ステップ１８１６で、試聴用として、当該コンテンツを先頭から所定時間長（例えば３０秒程度）にカットしたデータを作成する。またステップ１８１７で、当該コンテンツのメタデータを検索条件として、当該コンテンツに対応した関連商品のアフィリエイトデータを、アフィリエイト提供サーバ１７０２から検索する。アフィリエイト提供サーバ１７０２は、ステップ１８４１で、当該コンテンツに対応するアフィリエイトデータを提供する。アフィリエイトデータとは、当該コンテンツに係る関連商品（当該コンテンツのオリジナル作品が収録されている音楽ＣＤやＤＶＤビデオ、正規ダウンロード販売用のオーディオデータやビデオデータ、ＭＩＤＩデータなど）の販売サーバ１７０３へのリンク情報である。

ＳＮＳサーバ１０２は、ステップ１８１８で、当該コンテンツ提供ページ（ステップ１８１６で所定時間長にカットしたデータをユーザに提供するためのページ）にアフィリエイト提供サーバ１７０２から提供されたアフィリエイトデータを付与する。なお、当該コンテンツに対応するアフィリエイトデータが見つからないこともある。その場合、ステップ１８１８における試聴コンテンツをユーザに提供するページへのアフィリエイトデータの付与は行わず、試聴コンテンツを提供するのみとする。また、ステップ１８１５で商用コンテンツでなかった場合は、当該コンテンツの全体を提供するページを準備してステップ１８１９に進むものとする。

次にＳＮＳサーバ１０２は、ステップ１８１９で、コンテンツをストリーミング形式のファイルで保存し、ステップ１８２０で、上述のコンテンツ提供ページを公開する。

例えば、ユーザＡがアップロードしたコンテンツが商用コンテンツであった場合は、自動的に、試聴用に所定時間長にカットされたコンテンツを提供するページが公開されるので、図１７のユーザＢは当該試聴用のコンテンツをストリーミング再生することができる。従って、商用コンテンツである場合でも、著作権侵害とならずにアップロードすることができる。もちろん商用コンテンツでないもの（著作権が切れているコンテンツ、あるいはユーザＡが独自に制作したオリジナルコンテンツなど）は、カットされていないフル再生可能なデータとして他のユーザにストリーミングで提供することができる。なお、この場合はダウンロード提供でも良い。

また、上述したように、試聴用に所定時間長にカットされたコンテンツを提供するページには、当該コンテンツに係る関連商品の販売サーバ１７０３へのリンク情報であるアフィリエイトデータが埋め込まれている。これにより、試聴したユーザは、当該アフィリエイトデータを利用して関連商品販売サーバ１７０３にアクセスし、関連商品を購入することができる。なお、このページから関連商品が購入された場合には、販売サーバ１７０３の管理者からコンテンツをアップロードしたユーザへと所定の報酬（例えば売り上げの所定％）が支払われるようにするとよい。そのような報酬を支払うことにより、このＳＮＳサーバの活性化や人気上昇が期待できるとともに、コンテンツの権利者にとってもコンテンツが広く知られ、商品が購入されるといったメリットが生じる。

なお、関連商品販売サーバ１７０３とアフィリエイト提供サーバ１７０２は、共通のサーバであってもよい。コンテンツ認識サーバ１７０１は、ＳＮＳサーバ１０２の運営者とは別の者により運営されることにしてもよい。また、アフィリエイト技術については、特開２００６−０４８４３０などに開示されている。

また、１つの販売サーバのアフィリエイトデータのみを扱うのではなく、複数の販売サーバのアフィリエイトデータを扱うようにしてもよい。１つのコンテンツに対して、複数の販売サーバが見つかった場合、どれか１つのサーバのアフィリエイトデータを付与してもよいし、見つかった全販売サーバのアフィリエイトデータを付与してもよい。

上記ステップ１８１６でコンテンツから所定時間長にカットしたデータを作成した場合でも、アップロードしたユーザ自身が利用するためのデータとしては所定時間長にカットしていないデータを当該ユーザのネットワークストレージに保存しておくものとする。また、上記の説明では、商用コンテンツをアップロードしたユーザのみが当該商用コンテンツの全体を利用でき、他のユーザは試聴用のコンテンツのみ再生可能としたが、他のユーザであっても親友登録されたユーザの場合は、試聴用コンテンツデータではなく、アップロードした全体をフル再生可能としてもよい。

実施形態のソーシャルネットワーキングシステムの全体システム構成図 ＳＮＳサーバのハードウェア構成の概略を示すブロック図 ＭＭＰのハードウェア構成の概略を示すブロック図 各ユーザ毎のユーザデータの構成例を示す図 ＭＭＰで音楽コンテンツを再生する形態を示す図 親友登録の手順を示すフローチャート ユーザＡがユーザＢと親友になりたい旨の要求を出す際の画面例を示す図 要求を受けたユーザが回答を行う際の画面例を示す図 ＭＭＰでの親友登録の処理のフローチャート 親友リストの同期の処理のフローチャート 親友リストの更新及び同期時の親友リストの更新の処理を示すフローチャート ＭＭＰによる再生処理を示すフローチャート 音楽コンテンツのリストを表示する際の表示例を示す図 ＳＮＳサーバからの音楽コンテンツリストの取得処理のフローチャート ＭＭＰからの音楽コンテンツリストの取得処理のフローチャート ストリーミング再生する処理のフローチャート ＳＮＳサーバに接続されている他のサーバの構成を示す図 図１７の構成のシステムにおける処理の手順を示すフローチャート

符号の説明

１０１…ワイドエリアネットワーク、１０２…ＳＮＳサーバ、１０３，１０４，１０５…各ユーザのＰＣ、１０６Ａ，１０７Ａ，１０８Ａ，１０６Ｂ，１０７Ｂ，１０８Ｂ…携帯型メディアプレイヤー（ＭＭＰ）。

Claims (4)

1. ユーザ機器からアップロードされたコンテンツデータを蓄積し、該コンテンツデータをユーザ機器へと提供するコンテンツ提供サーバであって、
   前記ユーザ機器からコンテンツデータがアップロードされたとき、自動的に当該コンテンツデータを認識する手段と、
   前記コンテンツデータの認識結果に応じて、他のユーザ機器への当該コンテンツデータの提供の仕方を変更する制御手段と
   を備えることを特徴とするコンテンツ提供サーバ。
2. 請求項１に記載のコンテンツ提供サーバにおいて、
   前記制御手段は、前記認識したコンテンツデータが商用コンテンツであるか否かに応じて、提供するコンテンツデータの時間長を変えるものであることを特徴とするコンテンツ提供サーバ。
3. 請求項１または２に記載のコンテンツ提供サーバにおいて、
   前記制御手段は、前記認識されたコンテンツデータが商用コンテンツである場合に、自動的に該商用コンテンツデータに関連する商品の購入サイトへのリンク情報であるアフィリエイト情報を付与し、該リンク情報が付与された状態でコンテンツデータを提供するものであることを特徴とするコンテンツ提供サーバ。
4. コンピュータを、ユーザ機器からアップロードされたコンテンツデータを蓄積し該コンテンツデータをユーザ機器へと提供するコンテンツ提供サーバとして機能させるコンテンツ提供プログラムであって、
   前記コンピュータを、
   前記ユーザ機器からコンテンツデータがアップロードされたとき、自動的に当該コンテンツデータを認識する手段と、
   前記コンテンツデータの認識結果に応じて、他のユーザ機器への当該コンテンツデータの提供の仕方を変更する制御手段として、
   機能させることを特徴とするコンテンツ提供プログラム。

Images