JP4596043B2 - 情報処理装置、情報処理方法、プログラム - Google Patents

Description

本発明は、例えばコンテンツの作成と、作成したコンテンツのデータの共有などをネットワーク経由で行うのに利用する情報処理装置と、その方法に関する。また、これらの情報処理装置が実行するプログラムに関する。

ネットワーク利用の１つの態様として、いわゆるオーディオ・ビデオなどのコンテンツの配信、共有などが広く行われるようになってきている。例えばコンテンツ配信システムの場合であれば、配信すべき多数のコンテンツとしてのデータファイルをサーバで保存管理しておくようにされる。そして、パーソナルコンピュータなどの情報処理端末装置を所有するユーザは、コンテンツ配信に対応したクライアント機能を有するアプリケーションソフトウェア（クライアントソフト）に対する操作により、サーバから、所望のコンテンツとしてのデータファイルをダウンロードするようにされる。このようにしてダウンロードされたコンテンツとしてのデータファイルは、通常、クライアントソフトにより情報処理端末装置内の記憶装置に記憶保存されて管理される。そしてこの後、ユーザは、情報処理端末装置に記憶されたコンテンツとしてのデータファイルを再生させる操作をクライアントソフトにより行うことで、音・映像などを視聴して楽しむことができる。

また、コンテンツの共有システムでは、例えば情報処理端末装置のユーザが、オーディオ・ビデオなどのコンテンツとしてのデータファイルをサーバにアップロードするようにされる。このような共有システムのサーバでは、アップロードされたコンテンツを公開するサイト（Ｗｅｂページ）を有するようにされる。一般の情報処理端末装置のユーザは、このサイトにアクセスして、例えば検索などを行って興味のあるコンテンツを探すようにされる。そして、この検索により探し出したコンテンツへのアクセスを行って再生し、視聴するようにされる。このようにしてコンテンツの共有が行われる。

また、一方で、オーディオデータやビデオデータなどを素材として取り込んで加工、編集し、新たなコンテンツを作成することのできるアプリケーションソフトウェア（編集ソフト）も知られており、特に近年では、操作が簡易なものから複雑なものまで、一般のユーザにも広く普及している状況にある。
このような編集ソフトは、上記もしているように、コンテンツとしての実データ（オーディオ・ビデオデータなど）を対象として編集のための変更を与えるようにして処理を実行できる。このために、例えばオーディオの場合であれば、サンプリング、マッシュアップなどといわれるように、既存の楽曲の一部分を素材として取り込んでの加工・編集なども容易に行える。実際に、例えばプロフェッショナルの音楽家などの間では、このような手法により作成した楽曲も多く発表されている。

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

上記のようなことを背景とすると、一般ユーザのなかにも、コンテンツ配信やコンテンツ共有などにより入手できるコンテンツのデータを単に再生して楽しむだけでなく、編集ソフトにより二次編集を行って新たな作品を創作して、これを公に発表（公開）してみたいと思う人たちが少なからずいるであろうと考えられる。
そこで、本願発明は、先ず、上記のような一般ユーザの要望に応えるものとして、ネットワーク上で構築されるコンテンツ共有システムとして、ユーザ端末側にて保有するコンテンツのデータを二次的に利用した編集を行って副次的なコンテンツ(副次コンテンツ)を作成して、これをサーバなどにより一般公開できるようにしたものを構築するものとされる。
すると、このコンテンツ共有システムでは、例えば膨大な数の副次コンテンツがサーバ上に存在し、共有化され得る。このような状況では、コンテンツ共有システムにおいては、ユーザへの便宜として、これらの副次コンテンツのうちから、ユーザごとに対応して推薦するのに適当とされる副次コンテンツをできるだけ効率よく探し出せるようにすることが求められる。

そこで本発明は上記した課題を考慮して、情報処理装置として次のように構成する。
つまり、コンテンツ内容を再現するための情報として、原編集素材となる一次コンテンツファイルの実コンテンツデータについての再生を指示する内容を含んで形成される再生制御情報を有するコンテンツファイルである副次コンテンツファイルを記憶管理する記憶管理手段と、推薦対象ユーザが保有しているものとみなされる一次コンテンツファイルについての情報である保有一次コンテンツ情報を取得する情報取得手段と、原編集素材となる一次コンテンツファイルの少なくとも一部において上記保有一次コンテンツファイルを利用している副次コンテンツファイルを、上記推薦対象ユーザに推薦すべき推薦副次コンテンツとして、記憶管理手段により管理される副次コンテンツファイルのうちから選択する副次コンテンツ選択手段とを備えることとした。

上記構成では、先ず、推薦対象となるコンテンツは、副次コンテンツファイルとされている。副次コンテンツファイルは、１以上のコンテンツファイルを二次利用することにより作成されるもので、原編集素材として利用する一次コンテンツファイルが有する実コンテンツデータについての再生を指示する再生制御情報を有する構造のファイルである。
そして、このような副次コンテンツファイルを推薦するのにあたっては、推薦対象ユーザが保有しているとされる保有一次コンテンツを原編集素材コンテンツの一部又は全てに利用しているものを選択するようにされる。
ここで、副次コンテンツファイルにおいて、推薦対象ユーザが保有している一次コンテンツファイルを原編集素材として利用しているということは、例えばその副次コンテンツファイルは、推薦対象ユーザの嗜好にあったコンテンツ内容を有しているということになる。

このようにして本発明は、二次的創作物という特徴を有する副次コンテンツファイルを対象として、ユーザごとの嗜好などに適合するようにして的確にユーザ側に推薦することができる。これにより、例えばユーザは、膨大な数の副次コンテンツファイルのなかからでも、自分の嗜好に合うものを、より手早く、効率よく探し出していくことが可能になる。

図１は、本願発明を実施するための最良の形態（以下、実施形態という）に対応する情報処理装置を有して成る、情報処理システムの構成例を示している。
なお、本実施形態の情報処理システムは、以降説明するようにして、コンテンツのファイルとして、一次コンテンツファイル、副次コンテンツファイルを扱う。以降において、例えば一次コンテンツファイルと副次コンテンツファイルとで特に区別して述べる必要の無いときは、コンテンツファイルともいう。また、例えば、コンテンツとしての抽象概念に従って説明するような場合に、一次コンテンツファイルについては、一次コンテンツともいい、副次コンテンツファイルについては副次コンテンツともいうことにする。また、一次コンテンツと副次コンテンツとについて特に区分して述べる必要の無いときには、単にコンテンツともいう。

この図に示すように、本実施の形態の情報処理システムとしては、先ず、一次コンテンツサーバ１、副次コンテンツサーバ２、コミュニケーションサーバ３、ユーザ情報サーバ８と、多数のユーザ端末装置４とをネットワーク５を経由して接続することで形成したものとしてみることができる。
本実施の形態の情報処理システムは、このような装置構成により、コンテンツ作成・共有システムを実現する。つまり、ネットワーク上での、いわゆるコンテンツ配信（一次コンテンツの配信）と、ユーザが作成したコンテンツ（副次コンテンツ）についてのユーザ間での共有が実現される。
なお、ここでのコンテンツとは、種別として、主に音楽、楽曲などに対応する音声（オーディオ）、また、動画としての映像(ビデオ)などをいう。さらに映像としてのコンテンツ種別においては、写真などに相当する静止画なども含めて考えることができる。またさらには、文書のデータであるとか、情報処理装置が実行するプログラムなどもコンテンツとして扱うことが可能である。

一次コンテンツサーバ１は、一次コンテンツとしての所定形式によるオーディオ・ビデオのコンテンツデータをデータベース化して管理するようにして多数記憶している。そして、ネットワーク経由でのユーザ端末装置４からのダウンロード要求に応じて、指定された一次コンテンツとしてのデータを要求元のユーザ端末装置４に対して送信出力するように構成される。
なお、ここでの一次コンテンツは、例えば提携するレーベル会社などから提供される、アーティスト等が制作した映像、楽曲などとしての内容を有するものとされる。

副次コンテンツサーバ２は、副次コンテンツとしてのデータである、副次コンテンツファイルのデータをデータベース化して管理するようにして多数記憶可能とされている。
後述もするようにして、副次コンテンツファイルは、ユーザ端末装置４から副次コンテンツサーバ２に対してネットワーク経由でアップロードされてくる。副次コンテンツサーバ２は、このようにしてアップロードされた副次コンテンツファイルを、副次コンテンツとして扱って記憶するようにされる。また、副次コンテンツサーバ２は、ネットワーク経由でのユーザ端末装置４からのダウンロード要求に応じて、指定された副次コンテンツファイルを要求元のユーザ端末装置４に対して送信出力するようにされる。

コミュニケーションサーバ３は、例えばＳＮＳ(Social Networking Service)であるとかブログなどの、CGM(Consumer Generated Media)などともいわれる、個人ユーザによる情報発信サービスであるとか、ユーザ間のコミュニケーションサービスを提供する機能を有するようにされたサーバである。

ユーザ情報サーバ８は、本実施形態のコンテンツ作成・共有システムに参加しているユーザ端末装置４のユーザに関連した所定内容の情報（ユーザプロファイル情報）を例えばデータベース化して記憶している。そして、後述するようにして、他のサーバなどと連携して、コンテンツリコメンドサービスのための所定の動作を実行する。なお、ユーザプロファイル情報の内容例については後述する。

ユーザ端末装置４は、一般のユーザが使用するネットワーク機器であり、その実際としては、例えばＬＡＮなどのネットワーク通信機能が与えられたパーソナルコンピュータなどとされる。
これらのユーザ端末装置４は、後述するようにしてコンテンツ作成・共有アプリケーション１００としてのアプリケーションプログラムがインストールされている。ユーザは、このコンテンツ作成・共有アプリケーション１００を操作することにより、一次コンテンツサーバ１からの一次コンテンツファイルのダウンロード、また、ダウンロードした一次コンテンツファイル(及び副次コンテンツファイル)を利用しての編集作業による新たな副次コンテンツの作成、また、作成した副次コンテンツファイルの副次コンテンツサーバ２へのアップロード、副次コンテンツサーバ２からの副次コンテンツファイルのダウンロード、コミュニケーションサーバ３を利用したＳＮＳサービスの利用、ブログの書き込み／閲覧利用などを行うことが可能となる。

次に、上記図１に示した構成を採る本実施の形態の情報処理システムについてのコンテンツの流通に関する基本的な動作例を、ユーザ端末装置４のユーザによる基本的な利用態様例に従って、図２を参照して説明する。なお、図２の説明にあたっては、図中において［ ］内に英数字により示した手順、動作の番号に従って行う。また、ここでは、ユーザ端末装置４として、二人のユーザＡ，Ｂのそれぞれが使用するとされるユーザ端末装置４Ａ、４Ｂが示される。また、この図では、一次コンテンツサーバ１、副次コンテンツサーバ２、コミュニケーションサーバ３、及びユーザ端末装置４の間に介在するとされるネットワーク５の図示は省略している。また、本実施形態において、この基本的なコンテンツの流通に際しては、ユーザ情報サーバ８は必須的に機能するものとして扱っていないことから、ユーザ情報サーバ８についても、ここでの図示は省略している。

手順１
先ず、ユーザＡは、ユーザ端末装置４Ａ（コンテンツ作成・共有アプリケーション１００）により、一次コンテンツサーバ１のコンテンツダウンロードサイトにアクセスする。そして、ユーザＡは、例えばこのコンテンツダウンロードサイト上で、自分がダウンロードしたいコンテンツを検索し、この検索した一次コンテンツをダウンロードさせるための操作を行う。この操作に応じて、ユーザ端末装置４Ａは、一次コンテンツサーバ１に対してダウンロード要求を送信する。

なお、本実施形態のコンテンツ作成・共有システムにおいては、一次コンテンツのダウンロードは、基本的には有料とされ、上記のようにして一次コンテンツサーバ１に対してダウンロード要求を送信させるのにあたっては、ユーザＡはしかるべき購入手続きを行うべきものとされる。この購入手続きに関しては、例えば、コンテンツ単位、アルバム単位などで個別に設定された料金についての支払い手続きであってもよいし、最近においてしばしば運用されるようになった、サブスクリプションといわれる予約購読的な手続きとされてもよい。なお、無料で一次コンテンツを提供することも考えられるものであり、この場合には、ユーザＡは、購入手続きを行っておく必要はない。

そして、一次コンテンツサーバ１は、上記のようにしてダウンロード要求を受信すると、例えば先ず要求元のユーザについての認証などを行って、正当なダウンロード要求であるか否かについての判定を行う。そして、正当なダウンロード要求であると判定したのであれば、自身が記憶している一次コンテンツのうちから、ダウンロード要求とともに指定された一次コンテンツ(一次コンテンツファイル)を検索し、この検索した一次コンテンツファイルのデータを、要求元のユーザ端末装置４に対して送信する。

なお、確認のために述べておくと、一次コンテンツサーバ１がデータベース管理を行いながら記憶している一次コンテンツファイルは、ここでは、実コンテンツデータとしての本体情報にヘッダ情報が付加された構造であるものとする。
実コンテンツデータとは、この場合には、コンテンツ内容としての所定形式のオーディオデータや動画データ、静止画データ（一次コンテンツとしての実質的コンテンツ内容を再現するためのデータである）をいう。即ち、本実施形態での一次コンテンツデータは、再生のためのオーディオ信号処理やビデオ信号処理などを行うことでそのコンテンツ内容が再現される。
また、ヘッダ情報には、例えばコンテンツとしてのファイルごとに固有となる識別子（コンテンツＩＤ）の他、各種のメタデータ（タイトル、アーティスト、属するアルバムのタイトル、ジャンル、データ形式、データサイズなど）を含む。

上記のようにして一次コンテンツサーバ１から送信された一次コンテンツデータは、ユーザ端末装置４Ａにて受信される。ユーザ端末装置４Ａ（コンテンツ作成・共有アプリケーション１００）は、この受信した一次コンテンツデータを、内部のＨＤＤなどの記憶媒体に記憶保存させる。コンテンツ作成・共有アプリケーション１００は、このようにして記憶保存された一次コンテンツデータを、例えばヘッダ情報の内容などに基づいて所定の態様により管理するとともに、ユーザ操作に応じた再生制御を実行する機能を有する。
このようにして、一次コンテンツサーバ１に記憶されている一次コンテンツデータは、原則はユーザが購入をするというかたちで、ユーザ端末装置４に対してダウンロードさせることができるようになっている。即ち、手順１としては、いわゆるコンテンツ配信に対応する。
なお、ユーザ端末装置４Ａにて記憶保存された一次コンテンツデータは、コンテンツ作成・共有アプリケーション１００により再生して、例えばユーザ端末装置４Ａに接続したＡＶ（Audio・Visual）機器などにより画像・音声などとして出力することもできる。

手順２
ところで、一般に、ネットワーク経由によるコンテンツ配信では、ダウンロード後のコンテンツの利用は、ある一定のデータコピー制限が与えられたうえでの再生などの利用に限られている。換言すれば、ダウンロードによりコンテンツを取得したユーザは、一定範囲での利用が許可されているのみであって、例えば取得したコンテンツを基として編集を行って二次的創作物としての新規なコンテンツを作成する権原は与えられてはいないことが通常である。
これに対して、本実施形態では、一次コンテンツは、原則として、予め設定された範囲内での二次的創作のための素材として利用すること（二次利用、二次編集）が許諾されたコンテンツであるものとされる。なお、確認のために述べておくと、本実施形態における一次コンテンツの二次利用は、その一次コンテンツの著作者が承諾した権限の範囲において設定されるものである。
そして、本実施形態のコンテンツ作成・共有アプリケーション１００は、自身が管理している（ローカルに記憶保存されている）一次コンテンツを編集素材として二次利用して、ユーザ操作に応じて編集処理を実行することで、新たなコンテンツを作成することが可能とされている。
また、例えばこのようなコンテンツの編集にあたっては、エフェクトデータベース６において提供される所定の特殊効果に応じたプラグインデータを取得して、これを利用した編集を行うことができる。また、同様にして、素材データベース７にて提供している音声、画像などの素材を取得して、これを加えるようにして編集を行うことも可能とされる。なお、エフェクトデータベース６や素材データベース７は、ネットワーク上において設置されるものであっても良いし、ユーザ端末装置４Ａのローカル上に存在するものであってもよい。
そして、本実施形態では、このようにして副次的に作成されるコンテンツのことを、副次コンテンツといい、一次コンテンツと区別している。手順２としては、ユーザ端末装置４Ａにて起動されているコンテンツ作成・共有アプリケーション１００に対する操作を行って、１つの副次コンテンツを作成するようにされる。

なお、この手順２により作成される副次コンテンツとしてのデータ本体の実体は、一次コンテンツのようにしてそのコンテンツ内容を有するオーディオデータやビデオデータなどではなく、再生制御情報とされる。つまり、二次利用した一次コンテンツ（編集素材コンテンツ）としてのデジタルオーディオデータやデジタルビデオデータのどの部分をどのタイミングで再生出力すべきかなどの指示をはじめとして、エフェクト（特殊効果）の指定などが記述された再生制御情報とされる。

ここで、コンテンツ作成・共有アプリケーション１００による副次コンテンツについての作成概念を図５に示しておく。
この図において模式的に例示するように、ユーザは、二次利用の対象となる一次コンテンツである編集素材コンテンツＡ，Ｂ，Ｃを利用して、コンテンツ作成・共有アプリケーション１００に対して、自身の編集意図を反映させた編集操作を行う。コンテンツ作成・共有アプリケーション１００は、この編集操作に応じた編集処理を行い、その結果として、副次コンテンツファイルを作成して出力することになる。
そして、このようにして作成される副次コンテンツファイルの構造においては、データ本体として、上記した再生制御情報を有するものとなる。

この再生制御情報としての副次コンテンツデータ（即ち副次コンテンツ再生制御情報）は、例えばビデオデータやオーディオデータなどと比較すれば、本体のデータサイズを大幅に少なくすることができる。これにより、副次コンテンツサーバ２において、副次コンテンツのデータを記憶すべきＨＤＤなどの記憶媒体の記憶容量を節約して有効に使用することができる。また、副次コンテンツのデータをネットワーク上で送受信するのにあたっても、伝送データ量は少なくて済むので、例えばトラフィックも圧迫しない。

本実施形態での二次編集のようにして、既存のコンテンツを素材として編集を行って新規なコンテンツとしての二次作品を作り上げることは、例えば音楽の分野であれば、サンプリング、マッシュアップなどといわれ、プロフェッショナルの音楽家などもしばしば行っている。このようなことを背景に、一般の人々の中にも、同じようにして二次作品としてのコンテンツを創り出したい、という欲求、要望があることは当然考えられる。しかしながら、一般の人々が、著作権の問題を適正にクリアしたうえで、二次作品としてのコンテンツを創作、作成することは非常に困難であるというのが現状である。

そこで、本実施形態のコンテンツ作成・共有システムとしては、先ず、一般のユーザが、配信されるコンテンツを利用した二次編集を合法的に行えるようにして、よりユーザにとっての娯楽性が高められるようにすることを目指した。
このために、本実施形態の一次コンテンツは、著作権者が承諾した権限の範囲において、ダウンロード（購入）を行ったユーザが二次利用することが許可されたコンテンツであるとして位置付けることとしたものである。即ち、本実施形態の一次コンテンツサーバ１によるコンテンツ配信サービスは、二次利用することが積極的に許諾されたコンテンツを配信するものである。ただし、本実施形態の場合には、一次コンテンツの二次利用としての編集作業は、少なくとも本実施形態のコンテンツ作成・共有システムに対応して開発したコンテンツ作成・共有アプリケーション１００上でのユーザ操作に限定されるべきものとされ、例えば、本実施形態のコンテンツ作成・共有システムとは無関係な他の編集ソフトなどによっては行うことができないようにされている。

手順３
上記手順２のようにしてユーザＡが作成した副次コンテンツファイルのデータは、ユーザＡのユーザ端末装置４Ａのみにおいて保存しておいて、図４により後述するようにしてコンテンツ作成・共有アプリケーション１００の再生機能による再生処理を行って、その副次コンテンツとしてのコンテンツ内容の画像・音声を再生させることが可能とされている。
そのうえで、さらに本実施形態では、ユーザが作成した副次コンテンツをネットワーク上で公開することで、本実施形態のコンテンツ作成・共有アプリケーション１００のサービスを受けているユーザが共有できるようにもする。

ここで、ユーザＡは、先の手順２により作成した副次コンテンツが共有されるようにしたいと思ったとされる。そこで、ユーザＡは、コンテンツ作成・共有アプリケーション１００に対して所定操作を行って、手順２により作成した副次コンテンツファイルのデータを副次コンテンツサーバ２に対してアップロードする。これが手順３となる。

手順４
副次コンテンツサーバ２は、上記のようにしてアップロードとして送信されてきた副次コンテンツファイルを、データベースに新規に登録するようにして保存する。このときには、副次コンテンツサーバ２は、その保存場所（例えばＵＲＬ(Uniform Resource Locator)などのアドレスにより表現される）を設定したうえで、副次コンテンツファイルの保存処理と、データベースへの登録を行うようにされる。
なお、副次コンテンツサーバ２は、データベースに登録されている副次コンテンツについての公開機能を有しているものとされる。つまり、手順４により登録された副次コンテンツは、以降、副次コンテンツサーバ２にて公開され、ユーザ端末装置４（コンテンツ作成・共有アプリケーション１００）からのダウンロード要求に応じてダウンロードすることも可能になる。

手順５
副次コンテンツサーバ２は、上記のようにして副次コンテンツファイルを保存管理すると、アップロード要求元のユーザ端末装置４Ａに対して、アップロードされてきた副次コンテンツ（副次コンテンツファイル）の保存場所を通知するために、その保存場所を示すアドレス（保存場所アドレス）を送信する。
ユーザ端末装置４Ａのコンテンツ作成・共有アプリケーション１００は、上記の保存場所アドレスを受信して、これを所定の記憶媒体に記憶保存して管理するようにされる。ユーザＡは、コンテンツ作成・共有アプリケーション１００に対する所定操作により、いつでも、自分が手順２によりアップロードした副次コンテンツの保存場所アドレスを出力させることができる。

手順６
先に述べたように、副次コンテンツサーバ２は、データベースに登録されている副次コンテンツの公開機能を有している。このために、今回、ユーザＡが作成してアップロードした副次コンテンツは、原則、副次コンテンツサーバ２が提供するコンテンツ公開サイトにアクセスしてくる不特定多数のユーザ端末装置４（コンテンツ作成・共有アプリケーション１００）のユーザが閲覧できる。また、本実施形態では、原則、全てのユーザのユーザ端末装置４により、任意の副次コンテンツをダウンロードすることも可能とされている。
そのうえで、上記手順５により保存場所アドレスを取得したユーザＡは、いくつかの手段により、他のユーザを対象として、自分の副次コンテンツが副次コンテンツサーバ２にて公開されたことの告知を行うことができる。
手順６は、この公開告知の手段の１つに対応するもので、図示するようにして、コミュニケーションサーバ３にアクセスして、例えばＳＮＳにおける自身のページや、自分のブログなどに、自分の作成した副次コンテンツが公開された旨を書き込むようにされる。このときに、手順５によって取得した保存場所アドレスとしてのＵＲＬを、ともに書き込むようにして貼り付けておくようにされる。

手順７
上記手順６のようにしてユーザＡが書き込みを行った後において、例えばユーザＢが、ユーザ端末装置４Ｂにインストールされているコンテンツ作成・共有アプリケーション１００を操作して、ＳＮＳにおけるユーザＡのページや、ユーザＡのブログにアクセスして閲覧すると、ユーザＡの副次コンテンツが新たに公開されたことを知ることになる。つまり、この場合のユーザＢは、ユーザＡの作成した副次コンテンツの新規公開についての告知を、ＳＮＳやブログを通じて間接的に受けたことになる。手順７は、このような間接的な副次コンテンツ公開の告知が行われることを指す。

手順８
また、公開告知のもう１つの手段として、この手順８を挙げておく。この手順８としては、例えばＳＮＳに備えられるメール機能などを利用してメールを作成、送信することで、ユーザＢ側に対して、自分の作成した副次コンテンツが公開されたことを告知するようにされる。これは、上記手順６、手順７の流れによる告知に対して、より直接的な態様の告知となる。
また、このようにして、電子メールなどにより告知を行うときにも、例えば本文中に、その副次コンテンツの保存場所アドレスを記載するようにして貼り付けておくようにされる。

手順９
上記のようにして、ユーザＢは、ユーザＡの作成した副次コンテンツが新規公開されたことの告知を間接的、あるいは直接的に受け、このことを知ることができる。そして、ユーザＢが、この新規公開されたユーザＡの副次コンテンツを鑑賞したいとおもったときには、先ず、コンテンツ作成・共有アプリケーション１００により、副次コンテンツのダウンロードを行うようにされる。これが手順９となる。
この副次コンテンツのダウンロードにあたっては、例えばＳＮＳの日記のページ、若しくはブログの本文内にリンクとして示されている保存場所アドレスに対するクリック操作などを行うようにされる。確認のために述べておくと、ＳＮＳの日記のページやブログに対して書き込みを行う際に、ＵＲＬなどのアドレスの情報を書き込んだ場合には、この文字列部分がリンクとして公開されるようになっている。
上記のようにして保存場所アドレスに対するクリック操作を行ったことに応じて、コンテンツ作成・共有アプリケーション１００は、この保存場所アドレスに対してアクセスする。つまり、副次コンテンツサーバ２上のアドレスのうちで、ユーザＡが作成して公開中の副次コンテンツのファイル（副次コンテンツファイル）を保存している場所を示すアドレスにアクセスする。そして、この保存場所に保存されている副次コンテンツファイルを、ユーザ端末装置４Ｂに送出させるようにする。そして、このようにして送出されてくる副次コンテンツファイルをユーザ端末装置４Ｂ側で受信して、コンテンツ作成・共有アプリケーション１００の制御により保存管理するようにされる。このようにして副次コンテンツのダウンロードが行われる。

手順１０
上記のようにしてユーザＡの副次コンテンツが保存管理されると、ユーザ端末装置４Ｂのコンテンツ作成・共有アプリケーション１００による、この副次コンテンツの再生が可能になる。手順１０は、ユーザＢによるコンテンツ作成・共有アプリケーション１００に対する再生指示操作に応じて、この副次コンテンツのコンテンツ内容が映像や音などとして再生出力されるように、副次コンテンツファイルを再生するための手順となる。

図４は、編集・共有アプリケーション１００による副次コンテンツの再生概念を示している。
副次コンテンツファイルの再生にあたっては、先ず、コンテンツ作成・共有アプリケーション１００が、その実体データである副次コンテンツファイルの再生制御情報についての解釈処理を実行する。この解釈処理の結果、コンテンツ作成・共有アプリケーション１００は、例えば先ず、再生に必要な実コンテンツデータを有する一次コンテンツファイル（原編集素材コンテンツ）が何であり、また、再生のシーケンスにおいて、各原編集素材コンテンツにおける実コンテンツデータ（ビデオデータ、オーディオデータなど）のどの部分が、どの再生時間において、どのようにして利用されるのかなどを認識することができる。
この図では、原編集素材コンテンツＡ，Ｂ，Ｃを利用しているものとして認識されたとする結果例を示している。そして、この認識結果に従い、コンテンツ作成・共有アプリケーション１００は、原編集素材コンテンツＡ，Ｂ，Ｃとしての一次コンテンツファイルの実コンテンツデータを利用して、シーケンサとしての再生制御を実行するようにされる。この結果、副次コンテンツとしてのコンテンツ内容が画像や音として再生される。

なお、上記図４の説明によれば、副次コンテンツファイルの再生に際しては、その副次コンテンツの作成のために利用された原編集素材コンテンツの実コンテンツデータが必要であることになる。つまり、本実施形態では、副次コンテンツファイルの再生のためには、一時的にではあっても、コンテンツ作成・共有アプリケーション１００と同じローカル上に、原編集素材コンテンツのデータが存在していることが必要であるものとする。従って、副次コンテンツを再生しようとしたときに、その原編集素材コンテンツとしての一次コンテンツファイルがローカル上で保存されていなかった場合には、これらを取得してローカル上に存在させる必要があることになる。

手順１１
そこで、上記のような場合には、ローカル上に無い編集素材コンテンツをダウンロードして取得するための手順を行うことが必要となる。図２における手順１１は、手順１０によるコンテンツ再生の過程において、このために行うべき手順である。
これまでの説明から理解されるように、原編集素材コンテンツとしては実コンテンツデータであるので、原則、原編集素材コンテンツは一次コンテンツであることになる。そこで、手順１１としては、ユーザ端末装置４Ｂ（コンテンツ作成・共有アプリケーション１００）から一次コンテンツサーバ１にアクセスして、今回の手順１０による副次コンテンツ再生に必要で、ローカル上に存在していない一次コンテンツのダウンロードを行うようにされる。このダウンロードにより、副次コンテンツの再生に必要な原編集素材コンテンツがローカル上に全て存在することになり、図４による説明のようにして再生出力を正常に実行することが可能になる。

なお、手順１１のダウンロードによりローカル上に存在することとなる一次コンテンツのデータの状態としては、いくつか考えることができる。
先ず、１つには手順１による通常のダウンロードの場合と同様にしてＨＤＤなどの補助記憶装置に対して記憶保存された状態でローカル上に存在する態様を考えることができる。また、もう１つとしては、ＲＡＭなどの主記憶装置において一時的に保持され、例えばこの副次コンテンツの再生操作が可能なコンテンツ作成・共有アプリケーション１００の状態ではなくなったことに応じて、消去されるような態様も考えることができる。例えば一次コンテンツは原則有料であると述べたが、後者の場合には、無料とする、あるいは通常のダウンロードよりも安価な料金設定とするなどの運用が考えられる。

また、上記図２の説明によれば、本実施形態における副次コンテンツの作成は、編集素材のコンテンツ（編集素材コンテンツ）として一次コンテンツを直接的に二次利用するものとしている。つまり、この場合の編集素材コンテンツとしては、再生時においてその実コンテンツデータが必要になる一次コンテンツ（「原編集素材コンテンツ」ともいうことにする）である。
しかし、本実施形態において二次利用の対象となる編集素材コンテンツには、一次コンテンツだけではなく、副次コンテンツも含めることができる。図５を参照してこの点について補足しておく。図５（ａ）（ｂ）（ｃ）には、それぞれ、２つの編集素材コンテンツを二次利用して編集することで１つの副次コンテンツを作成する場合を示している。
まず、図５（ａ）は、図２により説明した副次コンテンツの作成例と同様に、編集素材コンテンツＡ，Ｂがそれぞれ一次コンテンツである場合を示している。つまり、一次コンテンツＡを編集素材コンテンツＡとし、これとは異なる一次コンテンツである一次コンテンツＢを編集素材コンテンツＢとして編集処理を実行して副次コンテンツを作成しているものである。この場合の副次コンテンツは、図示するようにして、内容的には一次コンテンツＡと一次コンテンツＢの少なくとも一部を有して成るものとされる。つまり大元の編集素材となるコンテンツ(即ち、原編集素材コンテンツである)として、一次コンテンツＡ、Ｂを使用しているものである。

図５（ｂ）は、図５（ａ）と同じ一次コンテンツとされる編集素材コンテンツＡと、一次コンテンツＣ、Ｄを二次利用して作成された副次コンテンツである編集素材コンテンツＣとを二次利用して編集することで、副次コンテンツを作成できることを示している。この場合の副次コンテンツは、編集素材コンテンツＡに含まれる一次コンテンツＡの少なくとも一部と、編集素材コンテンツＣに含まれる一次コンテンツＣ、Ｄのそれぞれの少なくとも一部とを有してコンテンツ内容を形成するものとなる。つまり、原編集素材コンテンツとしては、一次コンテンツＡ，Ｃ，Ｄとなるこものであり、従って、この図５（ｂ）に示される新規の副次コンテンツを再生する場合には、これら一次コンテンツＡ、Ｃ、Ｄをローカル上に置く必要がある、ということになる。
図５（ｃ）は、副次コンテンツである２つの編集素材コンテンツＣ、Ｄを二次利用して編集することで副次コンテンツを新規に作成できることを示している。この場合の新規作成される副次コンテンツは、編集素材コンテンツＣに含まれる一次コンテンツＣ、Ｄのそれぞれの少なくとも一部と、編集素材コンテンツＤに含まれる一次コンテンツＥ、Ｆのそれぞれの少なくとも一部とを有してコンテンツ内容を形成するものとなる。従って、図５（ｃ）に示される新規の副次コンテンツを再生する場合には、原編集素材である一次コンテンツＣ、Ｄ、Ｅ、Ｆをローカル上に置く必要があることになる。

また、上記図５（ｂ）（ｃ）のようにして副次コンテンツを作成するための編集素材コンテンツとして副次コンテンツを利用する場合には、先ず、ユーザは、一次コンテンツを編集素材コンテンツとして扱う場合と同様に、編集素材コンテンツとしての副次コンテンツをローカル上に置くために、例えばダウンロードを行ってユーザ端末装置４に記憶保存させるようにする。

また、図２の手順９により、副次コンテンツのダウンロード要求に応じて副次コンテンツサーバ２が副次コンテンツデータの送信を行うときには、副次コンテンツデータについて暗号化を施しておくようにされる。この暗号化は、正規ユーザのコンテンツ作成・共有アプリケーション１００であれば解読することができるが、コンテンツ作成・共有アプリケーション１００は、この暗号化処理を経て解読した副次コンテンツデータのみを再生し、例えば元から暗号化されていない副次コンテンツデータ、若しくは別の方式、アルゴリズムにより暗号化されている副次コンテンツデータについては再生を行わないように動作するようにされる。つまり、コンテンツ作成・共有アプリケーション１００は、外部から取得する副次コンテンツデータについては、副次コンテンツサーバ２からダウンロードして取得したもののみを再生する。
従って、例えばP2P(Pier to Pier)によるネットワーク通信であるとか、電子メールのファイル添付であるとかFTP(File Transport Protocol)などによるユーザ端末装置間での直接的な通信、若しくはリムーバブルメディアを利用したユーザ間でのやりとりなどで、ユーザ同士が直接的に副次コンテンツファイルをやりとりしたとしても、このようにしてユーザが入手したファイルは、副次コンテンツサーバ２により暗号化が施されていないので、適正に再生することができないようにされる。つまり、本実施形態では、他人の副次コンテンツについては、副次コンテンツサーバ２からダウンロードされたものでなければ適正に再生することができないようにされている。これにより、本実施形態のコンテンツ作成・共有システムでは、著作権に違反した非合法な副次コンテンツがネットワーク上で流通、増殖するのを避けるようにしている。これにより、例えば一次コンテンツ、副次コンテンツの著作権者の権利保護が図られるようにしている。

以上、図２〜図５の説明から理解されるように、本実施形態のコンテンツ作成・共有システムとしては、先ず、一次コンテンツのダウンロードが可能とされている。つまり、通常のコンテンツ配信によりユーザが好きなコンテンツをダウンロード（購入）し、これを鑑賞して楽しむことができる。そのうえで、この一次コンテンツについては編集素材とするための二次利用が可能なようにして利用権限が設定されていることで、ユーザは一次コンテンツを素材とする編集を行って自分の作品を創ることができるようになっている。さらに、このようにして作成した作品である副次コンテンツをＳＮＳやブログなどのコミュニケーション技術を利用して、一般に公開することができるものである。つまり、これまでにおいては著作権などの問題で合法的には困難であったとされる、一般ユーザが著作権のあるコンテンツを素材として編集を行って新規にコンテンツ（副次コンテンツ）を作成し、さらに、この副次コンテンツを一般に公開するということを適正に行えるようになるものである。

また、本実施形態では、副次コンテンツの実体は、その副次コンテンツが利用する原編集素材である一次コンテンツについての再生を指示する記述を少なくとも含んで形成される再生制御情報であるとしている。
コンテンツ作成・共有アプリケーション１００は、副次コンテンツの再生機能を有するわけであるが、副次コンテンツ作成のための編集機能も有している。このために、副次コンテンツの再生の態様のとして、単に音声再生のための処理を実行するのみではなく、例えば上記の編集機能のユーザインターフェースに、再生される副次コンテンツの編集内容を反映させることができる。つまり、副次コンテンツの実体が再生制御情報とされていることの恩恵として、ユーザは、コンテンツ作成・共有アプリケーション１００の編集機能を利用して、ダウンロードした副次コンテンツがどのようにして編集されているのかを詳細に知ることができる。

続いて、これまでに述べてきた実施の形態のコンテンツ作成・共有システムとしての動作が実現されるようにするための技術構成例について説明していく。
先ず、図６は、一次コンテンツサーバ１の内部構成例を示している。この図に示すようにして、一次コンテンツサーバ１は、制御部１１、記憶部１２、認証処理部１３、検索処理部１４、データベース管理部１５、決済処理部１６、暗号化処理部１７、ネットワークインターフェース１８を備える。

制御部１１は、一次コンテンツサーバ１における各種制御処理を統括して実行する部位とされ、例えばＣＰＵ(Central Processing Unit)、ＲＡＭ（主記憶装置）などから形成されるコンピュータシステムの中枢部に相当するハードウェア構成を有する。

記憶部１２は、例えばＨＤＤなどを備えて構成され、一次コンテンツデータベース１２ａを記憶している。一次コンテンツデータベース１２ａは、配信すべき一次コンテンツとしてのファイルをデータベース化した情報単位とされる。

認証処理部１３は、例えばダウンロード要求が行われた場合において、その要求に含まれるユーザＩＤやパスワードなどを利用して、正規のユーザであるか否かなどについての所要の認証処理を実行する。この認証処理結果がＯＫであった場合にのみ、要求に応答した一次コンテンツの送信が行われる。

検索処理部１４は、データベース管理部１５と協働して、一次コンテンツデータベース１２ａにアクセスして、目的の一次コンテンツを検索する処理を実行する部位とされる。

データベース管理部１５は、一次コンテンツデータベース１２ａについての管理を行う。例えば新規の一次コンテンツが供給された場合には、これに応じて、一次コンテンツデータベース１２ａに対してこの新規の一次コンテンツを登録するようにして更新する。また、同様にして一次コンテンツを削除すべき場合には、一次コンテンツデータの削除とこれに応じたデータベースの更新を行うようにされる。

決済処理部１６は、有料の一次コンテンツに関するユーザ側の代金支払いに対する決済などの処理を実行する。

暗号化処理部１７は、この一次コンテンツサーバ１からユーザ端末装置４に対して送信すべき一次コンテンツデータについて所定の暗号化を施すための処理を実行する部位とされる。

ネットワークインターフェース１８は、ネットワーク５経由での通信を行うための部位であり、例えばダウンロード要求の受信と、これに応じた一次コンテンツデータの送信は、このネットワークインターフェース１８が制御部１１の制御に応じて通信処理を実行することにより実現される。

図７は、副次コンテンツサーバ２の内部構成例を示している。この場合の副次コンテンツサーバ２は、制御部２１、記憶部２２、認証処理部２３、検索処理部２４、リコメンドコンテンツ抽出処理部２５、コンテンツデータベース管理部２６Ａ、プロファイルデータベース管理部２６Ｂ、保存場所設定処理部２７、暗号化処理部２８、ネットワークインターフェース２９を備える。

制御部２１は、副次コンテンツサーバ２における各種制御処理を統括して実行する部位とされる。これも、ハードウェア構成としては、例えばＣＰＵ、ＲＡＭ（主記憶装置）などから形成されるコンピュータシステムの中枢部に相当する部位を有して成る。

記憶部２２は、例えばＨＤＤなどを備えて構成され、副次コンテンツデータベース２２ａ、及びコンテンツプロファイルデータベース２２ｂを記憶している。
副次コンテンツデータベース２２ａは、副次コンテンツファイルのデータをデータベース化して構築した情報単位とされる。
コンテンツプロファイルデータベース２２ｂは、副次コンテンツデータベース２２ａとして記憶されている副次コンテンツごとに対応するコンテンツプロファイル情報を、例えばデータベース化して集合させることで形成した情報単位とされる。コンテンツプロファイル情報の内容例については後述するが、例えば、ダウンロード数などの履歴情報をはじめとした、メタデータとしての所定の情報項目から成る。

認証処理部２３は、例えば副次コンテンツのダウンロード要求が行われた場合において、その要求に含まれるユーザＩＤやパスワードなどを利用して、正規のユーザであるか否かなどについての所要の認証処理を実行する。

検索処理部２４は、コンテンツデータベース管理部２６Ａと協働して、副次コンテンツデータベース２２ａにアクセスして、目的の副次コンテンツを検索する処理を実行する。また、プロファイルデータベース管理部２６Ｂと協働して、コンテンツプロファイルデータベース２２ｂにアクセスして、必要なコンテンツプロファイルの情報を検索する処理を実行する。

リコメンドコンテンツ抽出処理部２５は、副次コンテンツデータベース２２ａにおいて記憶されているとする副次コンテンツのうちから、リコメンドコンテンツを抽出する処理と、抽出したリコメンドコンテンツが反映されたリコメンドコンテンツリスト情報を生成する処理を実行する。
リコメンドコンテンツとは、ユーザ（ユーザ端末装置４）ごとに対応して適当、適切であるとして、そのユーザに推薦すべき価値が有るとされる副次コンテンツをいう。

コンテンツデータベース管理部２６Ａは、記憶部２２における副次コンテンツデータベース２２ａについての管理を行う。例えば副次コンテンツ（副次コンテンツファイル）が新規にアップロードされた場合に応じては、副次コンテンツデータベース２２ａに対して、アップロードされてきた副次コンテンツを登録するようにして更新する。また、同様にして副次コンテンツ（副次コンテンツファイル）を削除することとなった場合には、このための削除処理と、削除結果に応じたデータベースの更新を行うようにされる。
プロファイルデータベース管理部２６Ｂは、記憶部２２におけるコンテンツプロファイルデータベース２２ｂについての管理を行う。例えばコンテンツプロファイルデータベース２２ｂについての、副次コンテンツ（副次コンテンツファイル）の新規アップロード、若しくは削除に応じた更新であるとか、副次コンテンツファイルのダウンロードに応じた所定の履歴情報の更新などを行う。

暗号化処理部２８は、この副次コンテンツサーバ２からユーザ端末装置４に対して送信すべき副次コンテンツデータについて所定の暗号化を施すための処理を実行する部位とされる。また、システムの運用によっては、副次コンテンツのアップロードのときに、ユーザ端末装置４から副次コンテンツデータを暗号化して送信してくる場合もあると考えられるが、この場合には、暗号化処理部２８は、その暗号化を解読する処理も実行するようにされる。

ネットワークインターフェース２９は、ネットワーク５経由での通信を行うための部位とされる。例えばアップロードされてくる副次コンテンツやダウンロード要求の受信と、ダウンロード要求に応じた副次コンテンツデータ（副次コンテンツファイル）の送信は、このネットワークインターフェース２９が制御部２１の制御に応じて通信処理を実行することにより実現される。

図８は、コミュニケーションサーバ３の内部構成例を示している。この図に示されるように、コミュニケーションサーバ３は、制御部３１、記憶部３２、認証処理部３３、ブログ稼働処理部３４、ＳＮＳ稼働処理部３５、及びネットワークインターフェース３６とを備える。なお、この場合のコミュニケーションサーバ３は、ブログとＳＮＳのコミュニケーションサービスを提供するものとされる。

制御部３１は、コミュニケーションサーバ３における各種制御処理を統括して実行する部位とされ、例えばＣＰＵ、ＲＡＭ（主記憶装置）などから形成されるコンピュータシステムの中枢部に相当する部位をハードウェアとして有して成る。

記憶部３２は、例えばＨＤＤなどを備えて構成され、ブログデータベース３２ａとＳＮＳデータベース３２ｂとを記憶している。例えばブログデータベース３２ａは、ユーザが開設したブログのデータがデータベース化された情報単位とされる。また、ＳＮＳデータベース３２ｂは、ＳＮＳのユーザごとのページ内容等がデータベース化された情報単位とされる。

この場合の認証処理部３３は、ブログの更新のためのログインや、ＳＮＳへのログインの要求などに応じて、その要求に含まれるユーザＩＤやパスワードなどを利用して認証処理を実行する。この認証処理結果がＯＫであれば、上記のログインが成功するようにされる。

ブログ稼働処理部３４は、ブログを適正に稼働させるための各種所要の処理を実行する。例えば、ユーザ端末装置４からのブログへのアクセス要求や、正規のブログの書き込み画面の要求などに応じて、ブログ画面のデータの送信であるとか、ブログ書き込み画面の送信などの処理を実行する。また、ブログに対する書き込みが反映されるようにしてブログデータベース３２ａを更新するなど、ブログデータベース３２ａを管理するための処理も実行する。

ＳＮＳ稼働処理部３５も同様にして、ＳＮＳのページへのアクセス要求に応じてそのページのデータを送信する処理であるとか、日記などの書き込みを反映させるためのＳＮＳデータベース３２ｂの更新などをはじめとするデータベース管理など、ＳＮＳを適正に稼働させるための処理を実行する。

ネットワークインターフェース３６は、ネットワーク５経由での通信を行うための部位とされる。これにより、ブログやＳＮＳへのアクセス要求に応じたページデータの送信などが可能となる。
なお、ここではコミュニケーションサーバ３は、ＳＮＳとブログに対応して設けられているものとしているが、例えばＳＮＳとブログとで、それぞれ異なるサーバが構築されてもよい。また、例えば、ＳＮＳ、ブログ以前からよく知られている、ホームページなどといわれる個人のサイト運営など、ＳＮＳ、ブログ以外で、個人ユーザが情報発信できるようなＣＧＭ関連のサービスを提供するように構成しても良い。

図９は、ユーザ情報サーバ８の内部構成例を示している。この場合のユーザ情報サーバ８は、制御部５１、記憶部５２、認証処理部５３、データベース管理部５４、検索処理部５５、暗号化処理部５６、ネットワークインターフェース５７を備える。

制御部５１は、ユーザ情報サーバ８における各種制御処理を統括して実行する部位であり、ハードウェア構成として、例えばＣＰＵ、ＲＡＭ（主記憶装置）などから形成されるコンピュータシステムの中枢部に相当する部位を有して成る。

記憶部５２は、例えばＨＤＤなどを備えて構成され、ここではユーザプロファイルデータベース５２ａを記憶している。
ユーザプロファイルデータベース５２ａは、コンテンツ作成・共有アプリケーション１００を利用して本実施形態のコンテンツ作成・共有システムに参加するユーザごとに個別のユーザプロファイル情報をデータベース化して集合させて形成した情報単位とされる。ユーザプロファイル情報の具体的な内容例、構造例については後述する。

認証処理部５３は、例えばユーザ端末装置４からユーザ情報サーバ８に対してユーザプロファイル情報を登録する場合などに、ユーザＩＤやパスワードなどを利用して、正規のユーザであるか否かなどについての所要の認証処理を実行する。

データベース管理部５４は、記憶部２２におけるユーザプロファイルデータベース５２ａについての管理を行う。例えばユーザプロファイル情報の新規登録、更新登録、削除に応じてユーザプロファイルデータベース５２ａの更新を行うようにされる。

検索処理部５５は、例えばデータベース管理部５４と協働して、ユーザプロファイルデータベース５２ａから必要な情報を検索する処理を実行する。

暗号化処理部５６は、例えばユーザ情報サーバ８から他のサーバやユーザ端末装置４に対して送信すべきデータの暗号化を実行する。また、他のサーバやユーザ端末装置４から送信されてくる暗号化されたデータについての復号処理を実行する。

ネットワークインターフェース２９は、ネットワーク５経由での他のサーバやユーザ端末装置４との間での通信を行うための部位とされる。

図１０は、ユーザ端末装置４の内部構成例を示している。なお、この場合には、ユーザ端末装置４としてのハードウェアは、パーソナルコンピュータであるものとする。
先ずユーザ端末装置４は、ネットワーク５経由での通信を行うために、ネットワークインターフェース４４を備えている。このネットワークインターフェース４４が備えられることにより、ネットワーク５を介して、例えば一次コンテンツサーバ１、副次コンテンツサーバ２、コミュニケーションサーバ３、ユーザ情報サーバ８、及び他のユーザ端末装置４などと通信することが可能となる。

ＣＰＵ(Central Processing Unit)４１は、例えばＨＤＤ（ハードディスクドライブ）４８にインストールされたＯＳ(Operating System)、及び各種のアプリケーションプログラム、また、ＲＯＭ４２に保持されているプログラムに従って各種の処理を実行可能とされる。本実施形態においては、コンテンツ作成・共有アプリケーション１００としてのアプリケーションプログラムがインストールされることになる。
ＲＡＭ４３はＣＰＵ４１のための作業領域であり、ＣＰＵ４１が各種処理を実行するのに必要なデータやプログラム等が適宜保持される。

この場合の入出力インターフェース４５には、例えば、キーボードやマウスなどとされる入力デバイス４６が接続されており、この入力デバイス４６から出力されてくる操作信号を、ＣＰＵ４１に適合させた信号に変換してＣＰＵ４１に出力するようにされている。
また、入出力インターフェース４５には、メディアドライブ４７が接続されている。このメディアドライブ４７は、所定フォーマットのリムーバブルメディアに対応してデータの記録再生が可能なように構成されたドライブ装置とされる。

また、入出力インターフェース４５には、記憶媒体としてハードディスクを備えたＨＤＤ４８が接続されている。ＣＰＵ４１は、入出力インターフェース４５を介して、ハードディスクドライブ４８のハードディスクに対してデータやプログラム等の記録又は読み出しを行うことができるようにされている。
また、入出力インターフェース４５には、画像表示のためのディスプレイモニタ４９も接続されている。

図１１には、本実施形態のコンテンツ作成・共有システムの利用に関連してＨＤＤ４８に記憶されるデータ内容例を示している。
この図に示すようにして、実施の形態のコンテンツ作成・共有システムに関連しては、先ず、アプリケーションプログラムのデータとしてコンテンツ作成・共有アプリケーション１００を記憶させることになる。なお、ＨＤＤ４８に対するコンテンツ作成・共有アプリケーション１００の記憶は、インストールの処理により行われる。また、アプリケーションファイルとして、１以上の一次コンテンツファイル（一次コンテンツファイル群１０３）と、１以上の副次コンテンツファイル（副次コンテンツファイル群１０４）がコンテンツ作成・共有アプリケーション１００の制御により記憶される。

この場合のコンテンツ作成・共有アプリケーション１００は、その機能面から、大別してコンテンツ管理・作成ツール１０１としてのプログラム部分と、コミュニケーションツール１０２としてのプログラム部分とから成るものとしてみることができる。コンテンツ管理・作成ツール１０１は、一次コンテンツファイルや副次コンテンツファイルのダウンロード、一次コンテンツファイル群１０３を成す一次コンテンツファイルと、副次コンテンツファイル群１０４を成す副次コンテンツファイルを対象とするファイル操作を実行するようにされる。また、編集操作に応じた編集処理や、編集結果に応じた副次コンテンツファイルの作成処理なども実行するようにされる。コミュニケーションツール１０２は、コミュニケーションサーバ３にアクセスしてブログやＳＮＳを操作するための処理を実行するようにされる。

図１２は、コンテンツ管理・作成ツール１０１についてのプログラム構成を、機能ブロック単位により模式的に示したものであり、図示するようにして、通信制御部１１１、一次コンテンツ取得処理部１１２、一次コンテンツ管理処理部１１３、副次コンテンツ取得処理部１１４、副次コンテンツ管理処理部１１５、コンテンツ転送処理部１１６、コンテンツ作成処理部１１７、副次コンテンツファイル生成・解釈処理部１１８、暗号・解読処理部１１９、再生出力処理部１２０、ユーザプロファイル管理処理部１２１から成るものとしてみることができる。

通信制御部１１１は、コンテンツ管理・編集に関連して主に一次コンテンツサーバ１や副次コンテンツサーバ３とネットワーク経由で通信を実行するために必要なプログラムから成る部位である。

一次コンテンツ取得処理部１１２は、一次コンテンツをダウンロードして取得するために必要なプログラムから成る部位である。この一次コンテンツ取得処理部１１２により、一次コンテンツをダウンロードするためのユーザインターフェースが提供される。また、ダウンロード要求としてのコマンドを発行して通信制御部１１１により送信させる制御や、通信制御部１１１にて受信した一次コンテンツのデータのパケットを受け渡してもらい、一次コンテンツとしてのデータ形式に復元する処理なども、この一次コンテンツ取得処理部１１２により実行される。

一次コンテンツ管理処理部１１３は、上記一次コンテンツ取得処理部１１２により取得された一次コンテンツファイルをＨＤＤ４８に保存する処理と、保存された一次コンテンツファイルを管理するための処理を実行する部位である。例えば、この一次コンテンツ管理処理部１１３により、アーティスト名、アルバム単位、ジャンルなどに応じたソートなどのコンテンツ管理も実現される。

副次コンテンツ取得処理部１１４は、副次コンテンツをダウンロードして取得するために必要なプログラムから成る部位である。
副次コンテンツ管理処理部１１５は、上記副次コンテンツ取得処理部１１４により取得された副次コンテンツファイルをＨＤＤ４８に保存する処理と、保存された副次コンテンツファイルを管理するための処理を実行する部位である。

コンテンツ転送処理部１１６は、例えば副次コンテンツファイルを副次コンテンツサーバ２に対してアップロードするときなど、コンテンツファイルのデータ転送が通信制御部１１１を経由して適正に実行されるようにするための制御、処理を実行する。

コンテンツ作成処理部１１７は、図３により示した編集素材コンテンツを利用した編集、即ち、ユーザが行う編集操作などに応じて、副次コンテンツとしてのコンテンツ内容の作成に関する処理を実行する部位である。従って、例えば編集操作のためのユーザインターフェースなども、このコンテンツ作成処理部１１７により実現される。
コンテンツファイル生成・解釈処理部１１８は、先ず、上記コンテンツ作成処理部１１７により作成したとするコンテンツ内容が反映された副次コンテンツファイルのデータを生成するための処理を実行する。また、副次コンテンツを再生する場合には、図４に示した副次コンテンツファイルにおける再生制御情報についての解釈処理を実行して再生処理のシーケンスを決定する。

本実施形態にあっては、一次コンテンツファイルは暗号化が施されて一次コンテンツサーバ１から伝送されるものとされる。また、副次コンテンツファイルも、ダウンロードに対応して副次コンテンツサーバ２からユーザ端末装置４に送信する際においても、暗号化を施すようにされる、また、ユーザ端末装置４から副次コンテンツサーバ２に対して副次コンテンツデータをアップロードする場合にも、暗号化を施して送出する場合がある。
暗号化・解読処理部１１９は、暗号化が施された一次コンテンツファイル、副次コンテンツファイルを再生、編集などのために操作する必要のあるときに、この暗号化を解読する処理を実行する。また、副次コンテンツファイルについて暗号化を施して伝送する必要のある場合に、暗号化を施す処理を実行するようにされる。

再生出力処理部１２０は、一次コンテンツファイル及び副次コンテンツファイルを再生して画像・音声などとして出力させるための信号処理過程のうちで、デジタル段階で施しておくべき所要の信号処理を実行するための部位とされる。
先ず、一次コンテンツファイルは、データ本体として、コンテンツ内容を再現する所定形式のビデオデータ・オーディオデータなどとしての実コンテンツデータを有する。従って、再生出力処理部１２０が一次コンテンツファイルを再生するときには、この実コンテンツデータとしてのビデオデータ・オーディオデータなどを再生するためのデジタル信号処理を実行する。この際、実コンテンツデータについて圧縮符号化が施されているのであれば、この圧縮符号化に対応する復号処理を施したうえでデジタルビデオ信号、デジタルオーディオ信号についての再生信号処理を実行する。
また、副次コンテンツを再生する場合には、上記副次コンテンツファイル生成・解釈処理部１１８により決定された再生処理のシーケンスに従って、原編集素材コンテンツである一次コンテンツファイルの必要データ部分を順次再生していくという、シーケンサとしての再生処理を実行するようにされる。

ユーザプロファイル管理処理部１２１は、ユーザプロファイル情報の生成、更新を実行するとともに、ＨＤＤ４８に記憶させたユーザプロファイル情報を管理する。なお、ユーザプロファイル情報については後述する。
なお、上記したコンテンツ転送処理部１１６は、コンテンツの転送だけではなく、ユーザ情報サーバ８に対してユーザプロファイル情報のデータを送信するための制御も実行可能とされている。

ところで、副次コンテンツを再生するのにあたり、副次コンテンツファイル生成・解釈処理部１１８により再生制御情報を解釈した結果は、コンテンツ作成処理部１１７が提供するとされるＧＵＩである編集作業画面に反映させることが可能であるものとされている。つまり、再生制御情報が示す再生指示の内容が、編集作業画面上でユーザが認識可能な態様で表示される。ユーザは、これを見ることで、その副次コンテンツがどのようにして作成されたのかを確認することができる。このことは、その副次コンテンツが作成者によってどのようにして作成されたのかということを、正確な情報として得られることを意味している。例えば、一般のコンテンツの場合、そのコンテンツがどのようにして作成されたのかを一般のユーザが知るためには、実際に再生して見ることのできる映像的な内容、若しくは聴き取ることのできる音響的な内容などから推測するしかない。
これに対して、本実施形態の場合には、副次コンテンツについて、より詳細、かつ具体的に、どのようにして作成されたものであるのかを把握できるものである。そして、このような副次コンテンツがユーザ間で共有されることにより、本実施形態のコンテンツ作成・共有システムを利用するユーザのコンテンツの創作に関する知識、技術が飛躍的に向上されることが期待される。このようにして、本実施形態のシステムは、コンテンツ作成に関心のあるユーザにとっては、非常に高い娯楽性と利用価値を持っているものである。

次に、本実施形態に対応するコンテンツファイル（一次コンテンツファイル、副次コンテンツファイル）の構造例について、図１３〜図１５を参照して説明する。
先ず、図１３（ａ）には、副次コンテンツファイルの構造例が示される。
この図に示すようにして、副次コンテンツファイルは、ヘッダとボディ（データ本体部）から成る。
ヘッダには、副次コンテンツファイルに関連した所定の情報項目（メタデータ）の集合から成るヘッダ情報を格納する。
ボディは、そのコンテンツファイルのコンテンツ内容に対応する実体データを格納する。従って、副次コンテンツファイルの場合には、再生制御情報を格納することになる。

図１３（ｂ）には、一次コンテンツファイルの構造例が示される。
一次コンテンツファイルもヘッダとボディから成り、ヘッダには、一次コンテンツに対応する所定の情報項目（メタデータ）の集合から成るヘッダ情報を格納する。また、ボディには、コンテンツ内容に対応する実体データとして、所定形式の実コンテンツデータを格納する。

ここで、副次コンテンツファイルのヘッダが格納するヘッダ情報の内容例を図１４に示す。
この図においては、ヘッダ情報を形成する情報項目（メタデータ）として、本コンテンツ関連基本情報、利用原編集素材コンテンツ情報、利用編集素材コンテンツ情報、本コンテンツ利用許諾情報、本コンテンツ世代情報を有するものとしている。

本コンテンツ関連基本情報は、現コンテンツファイルに関連した基本的な情報項目（メタデータ）から成る。
図１５は、本コンテンツ関連基本情報を形成する情報項目群の一例を示している。ここでは、コンテンツＩＤ、タイトル、クリエータ、コンテンツ種別、再生時間、作成日時、ジャケットデータ、ジャンル・・・などが示されている。
ここでのコンテンツＩＤは、現副次コンテンツファイルとしてのコンテンツごとに固有に与えられる識別子となる。なお、本実施形態では、これらのコンテンツＩＤは、例えば副次コンテンツサーバ２のコンテンツデータベース管理部２６Ａによりコンテンツファイルごとに付されるものとする。

タイトルは、現副次コンテンツファイルに与えられたタイトル名を示す情報である。
クリエータは、現副次コンテンツファイルの作成者（制作者、アーティストなどともいわれる）の名前を示す情報である。
コンテンツ種別は、例えば動画、楽曲、写真（静止画）などをはじめとして、現副次コンテンツファイルが有するコンテンツ内容の種類、範囲などがどのようなものであるのかを示す情報となる。
再生時間は、現副次コンテンツファイルとしてのコンテンツの総再生時間を示す情報である。
作成日時は、現副次コンテンツファイルの作成された日付、時刻を示す情報である。
また、コンテンツには、アルバムジャケットに相当する画像データが付されている場合がある。ジャケットデータは、このような画像データとなる。
ジャンルは、現副次コンテンツファイルのコンテンツ内容に与えられるジャンルが何であるのかを示す情報となる。
なお、本コンテンツ関連基本情報に含める情報項目としては、ここで挙げているもの以外にも考えることができる。

利用原編集素材コンテンツ情報は、現副次コンテンツファイルのコンテンツ内容を再生するのに必要とされる原編集素材コンテンツ（これが利用原編集素材コンテンツである）が何であるのかを示す情報である。換言すれば、現副次コンテンツの作成のために結果的にその実コンテンツデータを利用すべきこととなった一次コンテンツファイル、若しくは副次コンテンツファイルが何であるのかを示す情報である。

図５との対応であれば、編集処理により新規に作成される副次コンテンツを形成しているものとして示されている一次コンテンツファイルが、上記利用原編集素材コンテンツ情報となるものである。従って、利用原編集素材コンテンツ情報は、図５（ａ）の場合に対応しては一次コンテンツＡ、Ｂを示し、図５（ｂ）の場合に対応しては一次コンテンツＡ、Ｂ、Ｃを示し、図５（ｃ）の場合に対応しては一次コンテンツＣ、Ｄ、Ｅ、Ｆを示す内容となる。

なお、可能性として、編集素材コンテンツを編集して作成した副次コンテンツのコンテンツ内容の結果として、もともと編集素材コンテンツに含まれていた或る一次コンテンツを全く使用しなかった場合もあると考えられる。図５（ｂ）の場合を例に挙げれば、編集素材コンテンツＡ、Ｃを利用して編集を行って得た新規の副次コンテンツとして、例えば一次コンテンツＡ、Ｃは少なくともその一部を利用しているが、一次コンテンツＤについては全く利用していないというコンテンツ内容となる可能性を考えることができる。この場合、副次コンテンツの再生に必要な一次コンテンツの実コンテンツデータとしては、一次コンテンツＡ，Ｃのみであり、一次コンテンツＤは不要となる。
このような場合に対応した利用原編集素材コンテンツ情報の内容をどのようなものとするのかについてであるが、１つには、副次コンテンツ再生のために実際に必要となる一次コンテンツのみを反映させるべきであるとの考え方に基づき、一次コンテンツＡ，Ｃのみを示し、一次コンテンツＤは示さない内容とすることが考えられる。
また、もう１つには、一次コンテンツＡ，Ｃ，Ｄの全ての一次コンテンツを示す内容とすることが考えられる。つまり、この場合には、現には一次コンテンツＤを使用してはいないものの、この副次コンテンツを作成するまでの過程においては、一次コンテンツＤとしてのコンテンツ内容の影響を少なからず受けているのであるから、潜在的には使用していることと等価であるとの考え方に立つものである。この場合、結果的には、今回の副次コンテンツが作成される世代までにおいて、一度でも利用されたことのある一次コンテンツが全て、利用原編集素材コンテンツ情報に含められることになる。
なお、図１６により後述するように、利用原編集素材コンテンツ情報には、ここに示される一次コンテンツごとに関連した所定内容のメタデータも有するものとされる。

また、利用編集素材コンテンツ情報は、現副次コンテンツァイルを作成するために直接的に利用した編集素材コンテンツ（利用編集素材コンテンツ、直接利用コンテンツ）が何であるのかを示す情報とされる。
図５との対応であれば、図５（ａ）に示される新規の副次コンテンツの場合には、利用編集素材コンテンツ情報に編集素材コンテンツＡ，Ｂとしての実際の一次コンテンツファイルを示すデータを格納することになる。また、図５（ｂ）に示される新規の副次コンテンツの場合であれば、利用編集素材コンテンツ情報には、編集素材コンテンツＡとされる一次コンテンツファイルと、編集素材コンテンツＣとされる副次コンテンツファイルを示すデータを格納する。また、図５（ｃ）に示される新規の副次コンテンツの場合であれば、利用編集素材コンテンツ情報には、編集素材コンテンツＣ、Ｄとされる各副次コンテンツファイルを示すデータを格納する。
なお、図１６により後述するように、利用編集素材コンテンツ情報としても、ここに示される編集素材コンテンツごとに関連した所定内容の付随情報を有しているものとされる。

本コンテンツ利用許諾範囲情報は、現コンテンツファイルに設定した利用許諾範囲の情報とされる。この構造は、図１６により後述する利用コンテンツ情報の構造例における利用許諾範囲情報に準ずればよい。

本コンテンツ世代情報は、現副次コンテンツが、本実施形態のコンテンツ作成・共有システムの環境において作成されたコンテンツとして第何世代となるのかを示す情報である。

図１６は、利用原編集素材コンテンツ情報と、利用編集素材コンテンツ情報の各構造例を示している。なお、ここでは、利用原編集素材コンテンツ情報と利用編集素材コンテンツ情報は、共通の基本構造を有するものとしている。これに応じて、図１６の内容は、利用原編集素材コンテンツ情報と利用編集素材コンテンツ情報とについて、それぞれ共通に示したものとなっている。
この図に示すようにして、利用原編集素材コンテンツ情報／利用編集素材コンテンツ情報は、大きくは単位ファイル情報の連結により成るものとしている。単位ファイル情報のそれぞれが、１つの利用原編集素材コンテンツ、利用編集素材コンテンツに対応する。
なお、記載を簡略なものとする都合上、この図１６の説明にあたり利用原編集素材コンテンツと利用編集素材コンテンツとで特に区別しない場合には、「利用コンテンツ」ともいうことにする。

単位ファイル情報においては、例えばコンテンツＩＤ、クリエータ、タイトル、そして、利用許諾範囲情報の各情報項目が設けられる。
ここでのコンテンツＩＤには、対応する利用コンテンツとしてのコンテンツファイルのコンテンツＩＤを格納する。
クリエータは、対応する利用コンテンツの作成者を示すものとして、例えばその名称、及び、このクリエータとされるユーザのユーザＩＤを格納する。
タイトルは、対応する利用コンテンツのタイトルを例えばその名称などにより示す。

世代の情報項目には、世代情報が格納される。世代情報は、そのコンテンツが第何世代のコンテンツであるのかを示す情報とされる。本実施形態のコンテンツ作成・共有システムにおいて、一次コンテンツは、一義的に第１世代であるとして定義され、副次コンテンツは、編集素材コンテンツの世代に応じて、所定規則により第Ｎ世代となるようにして定義される。従って、この図１６に示す利用コンテンツ情報が、利用原編集素材コンテンツ情報である場合には、この世代情報の項目には、第１世代であることを示す情報が格納されることになる。また、この図１６に示す利用コンテンツ情報が編集素材コンテンツ情報である場合には、単位ファイル情報が対応する利用コンテンツ（一次コンテンツ、又は副次コンテンツ）ごとに応じて実際に設定されている世代を示す情報が格納されることになる。

利用許諾範囲の情報（利用許諾範囲情報）は、１以上の利用項目１〜ｎの集合により形成される。
利用項目１〜ｎには、それぞれ、対応する利用コンテンツの編集（二次利用）に関連した所定の利用内容が対応するようにして割り当てられている。利用項目に割り当てる利用内容の例としては多様に考えられるが、例えば、
・本コンテンツの二次利用の可否に関する内容
・編集素材とする他のコンテンツについて、本コンテンツとは違うクリエータのものを利用することに関する内容
・編集素材とする他のコンテンツについて、本コンテンツが属するとされるアルバムとは違うアルバムに属するものを利用することに関する内容
・特定のエフェクトや特殊効果の使用に関する内容
・特定のプラグインモジュールの使用に関する内容
・コンテンツ全体から一部分を抜き出して編集素材とすること、
・コンテンツ全体から一部分を抜き出して編集素材とする場合において、抜き出す実コンテンツデータ部分に関する許可内容
・利用可能な世代数（例えば一次コンテンツとして、孫の世代（第３世代）までの利用を許諾するとした場合には、この一次コンテンツを利用した子の副次コンテンツと、この副次コンテンツを利用した孫の副次コンテンツは作成できるが、この孫の副次コンテンツについては、対応の一次コンテンツを利用した部分について編集を行うことはできない）
・本コンテンツと組み合わせて二次利用が可能なコンテンツの数、種類などに関する内容
などを挙げることができる。
そして、これらの利用項目の各々について、例えば許可／不許可をはじめとして、その利用項目ごとに設定した利用許諾に関しての内容を示す情報が記述されるものである。利用許諾範囲の情報としては、これらの利用項目のそれぞれに記述される許諾設定内容を総合することで、対応する利用コンテンツについての利用許諾範囲を示すことになるものである。

なお、一次コンテンツファイルについてのヘッダ情報の内容に関しては、特に図示による説明は省略するが、一次コンテンツファイルに関連して必要であるとして定義した情報が格納されていればよい。
しかし、本実施形態に関すれば、例えば一次コンテンツファイルのヘッダ情報についても、副次コンテンツファイルと共通の構造を与えるようにすることが、妥当な仕様の１つとして考えられる。
このような一次コンテンツファイルのヘッダ情報の構造とすれば、一次コンテンツと副次コンテンツとでヘッダ構造が共通化されるので、本実施形態のコンテンツ作成・共有システムにおけるコンテンツファイル管理の効率化が期待される。一例としては、一次コンテンツファイルが本コンテンツ利用許諾範囲情報を有することになるので、第１世代となる一次コンテンツについて、その作成者の判断や考え方をより忠実に反映した利用許諾範囲を設定することが可能となる。
ただし、確認のために述べておくと、一次コンテンツファイルは、他のコンテンツを二次利用して作成するものではない。従って、例えば一次コンテンツファイルのヘッダにおいて、上記図１６に示した利用原編集素材コンテンツ情報と利用編集素材コンテンツ情報については特に有意な内容を格納する必要はない。

続いて、副次コンテンツファイルにおける再生制御情報について説明する。
再生制御情報は、実コンテンツデータとは異なり、所定の言語によって、現副次コンテンツとしてのコンテンツ内容を再生するための処理シーケンスを記述して成る単位情報である。この再生制御情報を形成する記述内容の要素としては、例えば先ず、再生に使用する実コンテンツデータとしての一次コンテンツを示す記述、この一次コンテンツとしての実コンテンツデータから実際に副次コンテンツ再生のために利用するデータ部分を示す記述、また、このデータ部分を再生すべき時間を示す記述などとなる。また、例えばフェードイン、フェードアウト、オーバーラップ、イコライジング（音質調整）、再生速度倍率、リバーブ、ディレイなどをはじめとした、いわゆるエフェクト、特殊効果が反映されるようにするための記述も行われる。

図１７は、再生制御情報の内容例を示している。この図においては、[ ]により括られる記述部分が、１つの利用コンテンツ（原編集素材コンテンツ）についての或る１つの再生制御内容を示しているものとされる。
この図１７に示される利用コンテンツ単位の再生制御内容の例について説明しておく。
先ず、図において先頭に示される利用コンテンツ単位の再生制御内容としては、
[
file_id=AAAAAA;
time=00:00-00:10;
position=vv-zz
]
と記述されている。これは、利用コンテンツがコンテンツＩＤ=AAAAAA(ここではfile_idの記述子がコンテンツＩＤを示すものとされる)により指定されるものであり、この利用コンテンツを利用する現副次コンテンツの再生時間は00:00（開始時点）〜00:10（再生時間１０秒）であり、この再生時間において利用する利用コンテンツのデータ区間（実コンテンツデータの区間）は、アドレスvvからアドレスzzまでに対応する範囲であることを指定している。
これに続く利用コンテンツ単位の再生制御内容は、
[
file_id=AAAAAA;
time=00:10-00:15;
position=ss-tt
]
と記述されている。これは、利用コンテンツがコンテンツＩＤ=AAAAAAにより指定されるものであり、この利用コンテンツを利用する現副次コンテンツの再生時間は00:10〜00:15であり、この再生時間において利用する利用コンテンツのデータ区間は、アドレスssからアドレスttまでに対応する範囲であることを指定している。
続く利用コンテンツ単位の再生制御内容は、
[
file_id=BBBBBB;
time=00:15-00:20;
position=ss-tt
]
と記述されている。これは、利用コンテンツがコンテンツＩＤ=BBBBBBにより指定されるものであり、この利用コンテンツを利用する現副次コンテンツの再生時間は00:15〜00:20であり、この再生時間において利用する利用コンテンツのデータ区間は、アドレスppからアドレスuuまでに対応する範囲であることを指定している。
例えば、本実施形態のコンテンツ作成・共有アプリケーション１００の再生出力処理部１２０は、このようにして［ ］により括られる利用コンテンツ単位の再生制御内容を逐次解釈していき、その解釈結果に応じて実際に再生制御を実行することで、副次コンテンツを、ビデオ信号やオーディオ信号などとして再生出力する。

次に、図１８、図１９のフローチャートを参照して、副次コンテンツの編集、作成に関する主要な処理に関する手順例について説明しておくこととする。なお、図１８、図１９に示す処理は、コンテンツ作成・共有アプリケーション１００におけるコンテンツ管理・作成ツール１０１としてのプログラムを実行することにより実現されるものである。

ここで例えばユーザ端末装置４のユーザが、コンテンツ作成・共有アプリケーション１００のコンテンツ管理・作成ツール１０１を起動させて副次コンテンツを編集しようとしているものとする。そして、副次コンテンツの作成のために素材として利用するコンテンツを検索し、これを編集素材コンテンツとして登録する（確定させる）操作を行ったとする。これに応じて、コンテンツ管理・作成ツール１０１におけるコンテンツ作成処理部１１７により、図１８に示す処理が実行される。
図１８においては、先ず、ステップＳ１０１により、編集素材コンテンツとして登録されたコンテンツのデータの取り込みを実行する。確認のために述べておくと、登録された編集素材コンテンツが一次コンテンツの場合には、これに対応する一次コンテンツファイルのデータを取り込み、副次コンテンツの場合には、これに対応する副次コンテンツファイルのデータを取り込むようにされる。

ステップＳ１０２では、上記ステップＳ１０１により取り込んだデータから利用許諾範囲の情報についての読み込みをさらに行うようにされる。これにより、今回編集素材コンテンツとして登録したコンテンツについて設定されている各種の利用許諾についての内容が、利用許諾範囲情報における利用項目１〜ｎの内容に基づいて認識されることになる。そこで、続くステップＳ１０３により、上記ステップＳ１０２に応じて認識した利用許諾の内容を、副次コンテンツ編集のためのユーザインターフェース（ＵＩ）に反映させるようにして設定を行う。この処理により、編集素材コンテンツに予め設定された利用許諾範囲を越える内容の編集操作を行うことができなくなるようにしてコンテンツ作成処理部１１７としての動作が得られる。

図１９は、副次コンテンツとしてのデータの実体である副次コンテンツファイルの生成に関する処理手順例を示している。この図に示す処理も、例えばＣＰＵ４１がコンテンツ管理・作成ツール１０１としてのプログラムを実行することにより実現されるものである
ここでは、先ずステップＳ２０１により、編集のための操作入力に応じた、しかるべき編集処理を実行するようにされている。例えばコンテンツ作成処理部１１７は、そのプログラムにより、ユーザが副次コンテンツ作成のための編集操作を行うＧＵＩ(Graphical User Interface)を提供する。ユーザは、このＧＵＩを利用して副次コンテンツ作成のための編集操作を行うようにされ、この操作に応じて、ステップＳ２０１としての処理が実行される。
そして、上記のようにして編集処理を行っている過程において、ステップＳ２０２により、これまでの編集結果を保存するための操作の行われたことが判別されると、ステップＳ２０３に進む。ステップＳ２０３においては、これまでの編集結果により得られたコンテンツ内容に応じた副次コンテンツファイルを生成する。
副次コンテンツファイルの生成にあたっては、それまでの編集結果を反映したヘッダ情報と、再生制御情報とを生成し、これらを組み合わせるようにしてファイルを生成する。
ステップＳ２０４は、上記のようにして作成した副次コンテンツファイルを、例えばＨＤＤ４８におけるしかるべきディレクトリに保存するように制御を実行する。ステップＳ２０４の手順が終了したのであれば、ステップＳ２０１に戻るようにされる。

なお、副次コンテンツファイルの作成にあたってはヘッダ情報における本コンテンツ利用許諾範囲情報の内容も生成することになる。
このときの本コンテンツ利用許諾範囲情報の生成にあたり、その内容をどのようにして設定するのかについては、例えば原編集素材である一次コンテンツそれぞれの利用許諾範囲情報を総合して決まる最小限を越えない範囲で、所定の規則に従って（利用項目ごとの内容を）自動設定することが考えられる。また、ユーザの意図が反映されるように、ユーザが行ったとされる本コンテンツ利用許諾範囲情報の内容に関する指定操作に応じて設定するようにすることが考えられる。ただし、このようにしてユーザ操作に応じて設定する場合においても、原編集素材である一次コンテンツそれぞれの利用許諾範囲情報を総合して決まる最小限は越えない範囲での設定が行われるようにして、これを越える利用許諾範囲（利用項目ごとの内容）の設定は行えないようにされる。

なお、ここでは図示していないが、例えば副次コンテンツ作成のためのＧＵＩ画面を閉じる操作が行われるなどしたことに応じては、この図に示される処理を抜けて他の所要の処理に移行するようにされる。

続いては、図２０のフローチャートを参照して、ユーザ端末装置４による副次コンテンツのアップロードに関する処理手順例と、このアップロードに応じた副次コンテンツサーバ２の処理手順例とについて説明する。この図におけるユーザ端末装置４側の処理は、主として副次コンテンツ管理処理部１１５、及びコンテンツ転送処理部１１６としてのプログラムにより実現される。副次コンテンツサーバ２の処理は、図７に示した各部が協働して実行するものとなるが、例えば実際にあっては、副次コンテンツサーバ２を構成するコンピュータシステム（ＣＰＵ）がプログラムを実行することにより実現されるものとしてみることができる。

ユーザ端末装置４側では、ステップＳ３０１により、副次コンテンツファイルのアップロードを指示するコマンドが得られるのを待機している。
ここで、例えばユーザが、コンテンツ管理・作成ツール１０１が提供するＧＵＩに対する操作として、アップロードしたいと思う１以上の副次コンテンツを選択し、アップロード実行の操作を行ったとする。このアップロード実行操作に応じて、ＧＵＩ上で選択された副次コンテンツに対応する副次コンテンツファイルのアップロードを指示するコマンドが発生し、ステップＳ３０２に進むことになる。
なお、ここでアップロードのために選択される副次コンテンツは、コンテンツ作成・共有アプリケーション１００により作成され、そのアプリケーションファイルとしてＨＤＤ４８に記憶されている副次コンテンツファイルである。

ステップＳ３０２においては、アップロードが指定された副次コンテンツ、即ち副次コンテンツファイルを、それが格納されるディレクトリから読み込むようにされる。そして、次のステップＳ３０３により、この読み込みを行った副次コンテンツファイルのデータを、ネットワーク経由で副次コンテンツサーバ２に対してアップロード要求とともに送信出力する制御を実行する。

副次コンテンツサーバ２では、ステップＳ４０１によりアップロード要求が受信されるのを待機しており、アップロード要求が受信されるとステップＳ４０２以降の手順を実行する。なお、アップロード要求を受信してから実際にステップＳ４０２に移行するためには、例えば認証処理などを経て正規のユーザからの要求であることを確認するようにされるのであるが、ここでは、このような処理手順については省略している。
ステップＳ４０２では、アップロード要求とともに受信した副次コンテンツファイルの保存場所（ＵＲＬ）を設定する。
ステップＳ４０３は、今回のアップロード要求の送信元となるユーザ端末装置４に対して、上記ステップＳ４０２により設定された副次コンテンツファイルの保存場所を通知するための通信処理を実行するようにされる。

ステップＳ３０３によりアップロード要求を行ったユーザ端末装置４側では、ステップＳ３０４により保存場所の情報が受信されるのを待機している。そして、保存場所の情報を受信すると、ステップＳ３０５により、受信した保存場所（ＵＲＬ）の情報をしかるべきディレクトリに保存するようにされる。これにより、以降においては、コンテンツ管理・作成ツール１０１に対する所定操作により、副次コンテンツの保存場所の情報を呼び出すことができる。保存場所がＵＲＬであれば、呼び出し操作に応じては、例えばＵＲＬとしての文字列を表示するようにされる。

図２１のフローチャートは、ユーザ端末装置４による副次コンテンツのダウンロードに関する処理手順例と、これに応じた副次コンテンツサーバ２の処理手順例とを示している。この図におけるユーザ端末装置４側の処理も、主として副次コンテンツ管理処理部１１５、及び副次コンテンツ転送処理部１１６としてのプログラムにより実現される。
先ずユーザ端末装置４側においては、ステップＳ５０１にて、副次コンテンツファイルのダウンロードを指示するコマンドが得られるのを待機している。ここで、例えばユーザが、コンテンツ管理・作成ツール１０１に対する操作として、副次コンテンツサーバ２が提供する副次コンテンツのダウンロードサイト（Ｗｅｂサイト）にアクセスして、ダウンロード（共有）可能な副次コンテンツリストを表示させたとする。さらにユーザは、このリストのなかからダウンロードしたいと思う１以上の副次コンテンツを選択し、ダウンロード実行の操作を行ったとする。これに応じて、ステップＳ５０１としては肯定の判別結果が得られることとなり、ステップＳ５０２に進むことになる。

ステップＳ５０２では、ダウンロード指示の得られたことに応じて副次コンテンツサーバ２に対してダウンロード要求を送信する。なお、このダウンロード要求としては、例えばダウンロード実行指示の操作時において選択されていた副次コンテンツのディレクトリ(保存場所)の指定に相当する情報も含まれているものとされる。なお、保存場所ではなく、例えば副次コンテンツの実体である副次コンテンツファイルのコンテンツＩＤなどを指定してダウンロード要求を行うような仕組みとして構成することも考えられる。

副次コンテンツサーバ２では、ステップＳ６０１によりダウンロード要求が受信されるのを待機しており、アップロード要求が受信されるとステップＳ６０２の手順を実行する。なお、ダウンロード要求を受信して実際にステップＳ６０２に移行するのにあたっても、認証処理などを経るのであるが、ここでも、このような処理手順については省略している。
ステップＳ６０２では、記憶部２２の副次コンテンツデータベース２２ａにアクセスして指定された副次コンテンツ副次コンテンツファイルを検索し、この検索した副次コンテンツファイルを、要求元のユーザ端末装置４に対して送信するようにされる。

ステップ５０２によりダウンロード要求を送信したユーザ端末装置４は、ステップＳ５０３により、ダウンロード要求に応じた副次コンテンツファイルが受信されるのを待機するようにされる。そして、副次コンテンツファイルが受信されたことを判別すると、ステップＳ５０４により、この受信した副次コンテンツファイルをしかるべきディレクトリに対して保存して管理するようにされる。

図２２のフローチャートは、ユーザ端末装置４が、ダウンロードにより取得（ＨＤＤ４８に保存）した副次コンテンツを再生するための処理手順例を示している、この図におけるユーザ端末装置４側の処理は、主として副次コンテンツ管理処理部１１５、暗号化・解読処理部１１９、再生出力処理部１２０としてのプログラムにより実現される。

先ず、ステップＳ７０１においては、ＨＤＤ４８に保存してある副次コンテンツファイルについての再生開始指示が得られるのを待機している。ここで、例えば副次コンテンツ管理処理部１１５が提供するＧＵＩに対する操作として、ＨＤＤ４８に保存されている副次コンテンツのうちから１つの副次コンテンツを選択して再生を開始させるための指示が行われたとする。これに応じて、ステップＳ７０１にて肯定の判別結果が得られることとなり、ステップＳ７０２に進むようにされる。

ステップＳ７０２においては、指定された副次コンテンツに対応する副次コンテンツファイルをＨＤＤ４８から読み込むようにされる。
ここでは、ダウンロードにより取得した副次コンテンツデータは、転送時の暗号化が施されたままでＨＤＤ４８に保存されているものとしている。そこで、次のステップＳ７０３では、暗号化・解読処理部１１９により、読み込んだ副次コンテンツデータについての暗号化を解読するための処理を実行するようにされる。

ステップＳ７０４では、上記ステップＳ７０３による暗号解読処理が成功したか否かについて判別するようにされる。
例えば、今回のステップＳ７０１により再生開始すべきことが指定された副次コンテンツデータが、正規にコンテンツサーバ２からダウンロードしたものであれば、ステップＳ７０３による解読処理は成功して適正な副次コンテンツデータが復元されることになる。
これに対して、例えば副次コンテンツサーバ２からのダウンロード以外の手段により取得した副次コンテンツデータの場合には、他の方式、アルゴリズムによる暗号化が施されている、あるいは暗号化が施されていない。この場合、ステップＳ７０３の解読処理によっては、正常な副次コンテンツデータを復元することができない、あるいは、解読処理を実行する必要はないということになる。つまりステップＳ７０３による解読処理の結果としては、解読処理不要の場合を含めて、失敗したものとしてみることができる。

ステップＳ７０４にて解読処理が成功したとして肯定の判別結果が得られた場合には、ステップＳ７０５に進んで、この副次コンテンツについての再生を開始する。つまり、副次コンテンツファイル生成・解釈処理部１１８は、再生対象の再生制御情報を解釈して再生シーケンスを決定し、この再生シーケンスに従って一次コンテンツの実コンテンツデータ部分が順次再生されていくようにして再生出力処理部１２０の再生信号処理を制御するものである。

これに対して、ステップＳ７０５にて解読処理が失敗したとして否定の判別結果が得られた場合には、ステップＳ７０６に進んで、エラー対応処理を実行するようにされる。このエラー対応処理としては、先ず、今回再生が指定された副次コンテンツについての再生制御処理は開始しないようにしたうえで、例えば、今回再生が指定された副次コンテンツは不正なものであって再生不可であることをＧＵＩ上で通知するための制御処理などを実行するようにされる。
例えばこのような処理が実行されることで、本実施形態としては、ユーザ端末装置４において、外部から取得した副次コンテンツ情報については、副次コンテンツサーバ２から正当にダウンロードして取得したもののみが再生されるようにして、一次コンテンツ、あるいは副次コンテンツの著作権の保護がより万全に図られるようにしているものである。
なお、副次コンテンツサーバ２から正当にダウンロードした副次コンテンツのみが再生出力されるようにするための仕組みとしては、他にも考えられる。例えばダウンロードとしてユーザ端末装置６が受信取得した段階で予め暗号化を解読して、その解読結果の情報付随させたうえで、ＨＤＤ４８に記憶させておき、再生時においては、この解読結果の付随情報を参照して、その副次コンテンツを再生すべきか否かについての判断を行うように構成することも考えられる。また、副次コンテンツサーバ２からの送信時において、ダウンロードのために送信したことを示す特別なコードを、副次コンテンツサーバ２側の処理として副次コンテンツに埋め込んでおくようにして、再生時においては、ユーザ端末装置４側で、このコードの有無、内容などを確認したうえで、再生開始すべきか否かについての判断を行うようにしてもよい。

これまでに説明してきたようにして、本実施形態のコンテンツ作成・共有システムでは、例えば図２により説明した基本的な利用態様を実現するようにされている。
しかし、本実施形態のようなコンテンツ作成・共有システムの場合、ユーザ間で共有可能となる副次コンテンツ、即ち副次コンテンツサーバ２が記憶管理する副次コンテンツファイルの数は膨大な数になり得る。
また、本実施形態のコンテンツ作成・共有システムでは、前述のようにして、知人のユーザなどからの副次コンテンツの紹介などの通知がなくとも、副次コンテンツサーバのダウンロードサイトにアクセスして、任意の副次コンテンツをダウンロードすることもできる。
このようなことを考慮すると、本実施形態のコンテンツ作成・共有システムにあっては、膨大な数の副次コンテンツのなかから、ユーザが、自分に合った副次コンテンツをどれだけ効率良く見つけられるか、ということが重要になってくるといえる。
そこで、本実施形態のコンテンツ作成・共有システムとしては、ユーザごとに応じて適切、適当とされる副次コンテンツを効率よく選択して、各ユーザに提示できるようにした構成を提案する。以降、この点について説明を行っていく。
なお、「ユーザごとに応じて適切、適当とされる副次コンテンツを提示する」ということは、そのユーザにとって鑑賞する価値があるであろう副次コンテンツを推薦する、という意味合いを持つ。つまり、以降の説明は、ユーザごとに応じて、そのユーザに適合するとされる副次コンテンツを推薦（リコメンド）するための構成についてのものであるといえる。また、このことに因み、或るユーザに応じて適合するとして選択された副次コンテンツについては、「リコメンドコンテンツ」ともいうことにする。

図２３は、副次コンテンツ推薦に関連してコンテンツ作成・共有システムにおいて行われる動作、処理の一例を示している。
先ず、ステップＳ８０１は、副次コンテンツ推薦に関連して、適宜のタイミングで、逐次、ユーザ端末装置４とユーザ情報サーバ８とが実行する処理となる。
このステップＳ８０１は、例えばユーザ端末装置４におけるコンテンツ作成・共有アプリケーション１００のコンテンツ管理・作成ツール１０１により、ＨＤＤ４８に対して記憶させて管理しているユーザプロファイル情報を、ユーザ情報サーバ８に対してアップロードするものとなる。ユーザ情報サーバ８は、受信したユーザプロファイル情報が新規のものであれは、これをユーザプロファイルデータベース２２ｂに対して新規に登録する。また、同じユーザ（ユーザＩＤ）のユーザプロファイル情報が既に登録されていたのであれば、その登録済みのユーザプロファイル情報を、受信したユーザプロファイル情報により書き換え（更新）する。

ユーザプロファイル情報は、コンテンツ作成・共有アプリケーション１００を利用するユーザ個人に関連した所定内容の情報から成る。このユーザプロファイル情報の集合が、ユーザ情報サーバ８におけるユーザプロファイルデータベース５２ａとなる。

１ユーザに対応するユーザプロファイル情報の内容例を図２４に示す。
先ず、図２４（ａ）に示すように、ユーザプロファイル情報は、基本ユーザ情報、保有コンテンツリスト情報、コンテンツ個別情報リストから成るものとしている。

基本ユーザ情報は、例えばユーザＩＤをはじめとして、氏名、年齢など、ユーザについての基本的なことを示す所定の情報項目を有して成る。

保有コンテンツリスト情報（保有一次コンテンツ情報）は、そのユーザが保有しているとされる一次コンテンツ、つまり、そのユーザに対応するコンテンツ作成・共有アプリケーション１００の管理の下で保有しているものとしてみなされる一次コンテンツファイル（保有一次コンテンツ）を、リストとして示す情報とされる。
なお、ここでの「保有」とは、例えば先ず、コンテンツ作成・共有アプリケーション１００（ユーザ端末装置４）にとってローカルとしてみることのできる環境にて一次コンテンツファイルを記憶管理している状態をいう。また、例えばローカルにて存在しておらず、サーバなどに存在しているとしても、例えばコンテンツ作成・共有アプリケーション１００によりアクセスしてストリーミングなどにより再生できるようなコンテンツファイルがあれば、このような一次コンテンツファイルも保有一次コンテンツに含めることができる。このような一次コンテンツの例としては、例えば、サブスクリプションなどといわれる予約購読的なコンテンツ視聴契約によりサーバから任意にストリーミングによる再生若しくはダウンロードによるローカ保存ができるようなものを挙げることができる。これは、例えばその再生開始に際して改めて料金負担を強いられることなく、ユーザが再生できる権利を有しているコンテンツであるともいえる。
例えばこの保有コンテンツリスト情報は、図２４（ｂ）に示すようにして、該当する一次コンテンツファイルのコンテンツＩＤをリスト化して形成される。なお、コンテンツＩＤは、コンテンツファイルごとに固有となる識別子である。
保有コンテンツリスト情報に格納されるコンテンツＩＤの数が、そのユーザが保有しているとされる一次コンテンツファイルの数に対応することになる。また、コンテンツＩＤ自体により、そのユーザが保有しているとされる一次コンテンツファイルが何であるのかが特定できる。

コンテンツ個別情報リストは、例えばこの場合には、図２４（ｃ）に示すようにして個別のコンテンツに対応するコンテンツ個別情報の集合をリスト化して形成することとしている。そして、コンテンツ個別情報は、保有コンテンツリスト情報により示される一次コンテンツファイル（保有一次コンテンツ）ごとについての所定の定義内容によるメタデータから成るものとされる。ここでは、コンテンツＩＤ、通算再生回数、期限内再生回数、レートなどのメタデータから成るものとしている。

コンテンツ個別情報において、コンテンツＩＤには、そのコンテンツ個別情報が対応する一次コンテンツファイルのコンテンツＩＤとしての値が格納される。このコンテンツ個別情報内のコンテンツＩＤと、保有コンテンツリスト情報において保有一次コンテンツを示すコンテンツＩＤとは一対一で対応していることになる。

通算再生回数は、例えばコンテンツ管理・作成ツール１０１の管理の下で、これまでにおいて再生された通算回数を示す。

期限内再生回数は、例えば現時点から或る一定期間までの過去において、コンテンツ管理・作成ツール１０１の管理の下で再生された回数を示す。例えば、この期限内再生回数は、保有一次コンテンツ全体においては、最近においてどの保有一次コンテンツが高い頻度で再生されるのかを示す。換言すれば、最近ユーザが再生する保有一次コンテンツの傾向を示し得る情報といえる。

レートは、対応するコンテンツに対してユーザが付したとされるレート（例えばお気に入り度などとして扱われる）の値が格納される。
例えば、本実施形態のコンテンツ管理・作成ツール１０１によっては、ユーザ操作に応じて、保有一次コンテンツファイル、及び副次コンテンツファイルごとに、所定段階によるレートを設定することが可能とされている。

例えばコンテンツ管理・作成ツール１０１は、ユーザプロファイル管理処理部１２１により、ユーザプロファイル情報を記憶管理しており、保有一次コンテンツの追加、削除などに応じては、保有コンテンツリスト情報を更新する。また、保有一次コンテンツの再生やレート設定などに応じて、コンテンツ個別情報リストにおける通算再生回数、期限内再生回数、レートなどの更新を行う。
コンテンツ管理・作成ツール１０１は、ステップＳ８０１に応じたユーザプロファイル情報のアップロード（ユーザ情報サーバ８への送信）を、先ず、ユーザプロファイル情報の新規登録の場合に行うようにされる。また、新規登録を行った後も、適宜、所定のタイミングでユーザプロファイル情報をアップロードするようにされる。これにより、ユーザ端末装置４側で記憶しているユーザプロファイル情報と、ユーザ情報サーバ８側で記憶するユーザプロファイル情報との内容の整合が図られる。

また、ステップＳ８０２として示す処理は、副次コンテンツの推薦に関連して、下記のようにして副次コンテンツサーバ２が独立的に実行する処理であり、以降説明するようにしてコンテンツプロファイル情報の更新を逐次実行するものとなる。
副次コンテンツサーバ２は、記憶部２２においてコンテンツプロファイルデータベース２２ｂを記憶して管理している。このコンテンツプロファイルデータベース２２ｂは、副次コンテンツごとに対応するコンテンツプロファイル情報の集合をデータベース化したものとされる。図２５にコンテンツプロファイル情報の例を示す。

図２５に示されるコンテンツプロファイル情報は、コンテンツＩＤ、総合ダウンロード数、総合レート、総合再生回数、アップロード日時の情報項目から成るものとしている。
コンテンツＩＤは、現コンテンツプロファイル情報に対応する副次コンテンツに与えられたコンテンツＩＤの値を示す。

総合ダウンロード数は、現コンテンツプロファイル情報に対応する副次コンテンツが、これまでにおいてダウンロードされた回数（若しくはユーザ数であってもよい）を示す。

先にも述べたように、ユーザは、コンテンツ管理・作成ツール１０１に対する操作により、例えばローカルに保存されているなどして自身が保有しているとされる副次コンテンツファイルごとにレートを設定することができる。
総合レートは、現コンテンツプロファイル情報に対応する副次コンテンツを保有しているユーザがこの副次コンテンツに設定したレートを総合的に反映させた値とされる。例えば、この総合レートの求め方として、最も簡単なものの１つには、現コンテンツプロファイル情報に対応する副次コンテンツについてユーザが設定したレートの全てを総計することが考えられる。あるいは平均値を求めるようにすることも考えられる。また、ユーザごとのレートについての分布などを考慮したうえで、所定の演算式などにより求めるようにすることも可能である。
また、上記の総合レートを求めるためには、副次コンテンツサーバ２が、ユーザの設定したレートの情報を取得する必要がある。このためには、例えばコンテンツ管理・作成ツール１０１が、所定のタイミング、機会でもって、そのときにローカルにて設定されているレートの値の情報を副次コンテンツ（コンテンツＩＤ）と対応付けて副次コンテンツサーバ２に送信するように構成することが考えられる。
また、次のような手法も考えられる。
つまり、図２４に示したユーザプロファイル情報における保有コンテンツリスト情報とコンテンツ個別リストについて、一次コンテンツファイルに対応する内容だけでなく、副次コンテンツファイルに対応させた内容を含めたものを、ユーザ端末装置４（コンテンツ管理・作成ツール１０１）にて作成し、また、ユーザ情報サーバ８にてユーザプロファイルデータベース５２ａとして管理できるようにする。そのうえで、副次コンテンツサーバ２が、所定のタイミング、機会でもって、ユーザ情報サーバ８から、ユーザプロファイル情報から抜き出した副次コンテンツのレートの情報（副次コンテンツＩＤとレートとを対応付けた情報）を転送してもらうようにすることも考えられる。

副次コンテンツサーバ２は、例えばダウンロード方式で副次コンテンツファイルのデータを送信することに代えて、ストリーミング方式により副次コンテンツファイルのデータを送信してクライアント（ユーザ端末装置４）側にて再生させるようにすることも可能とされる。
総合再生回数は、例えばクライアント側でのコンテンツ再生のために、現コンテンツプロファイル情報に対応する副次コンテンツのデータを、上記のようにしてストリーミングにより送信した回数を示す。

なお、コンテンツプロファイル情報における、上記３つの総合ダウンロード数、総合レート、総合再生回数については、ユーザによる副次コンテンツの利用に関連した総合的な情報であるといえるので、一括して、「総合利用情報」ともいうことにする。

アップロード日時は、現コンテンツリスト情報に対応する副次コンテンツファイルが、副次コンテンツサーバ２にアップロードされた日時（年月日、時刻）を示す。

そして、副次コンテンツサーバ２は、ステップＳ８０２として、例えば副次コンテンツのダウンロード、ストリーミング送信、レート情報の取得などが行われる都度、その結果に応じて、コンテンツプロファイルデータベース２２ｂにおける所要のコンテンツプロファイル情報について、逐次、更新を実行する。

続く、図２３のステップＳ８０３〜Ｓ８１１までの動作、処理が、ユーザ端末装置４のユーザ側にリコメンドコンテンツを提示（推薦）するためのものとなる。
先ず、概要として、本実施形態では、コミュニケーションサーバ３において、リコメンドコンテンツを提示するためのＷｅｂサイトである、リコメンドコンテンツサービスサイト（以降、リコメンドサイトとも略す）を用意しているものとする。そして、ユーザ端末装置４におけるコンテンツ作成・共有アプリケーション１００のコミュニケーションツール１０２により、上記リコメンドサイトにアクセスしてリコメンドコンテンツについての情報を取得し、例えばユーザが視覚的に把握できる所定の態様により、リコメンドコンテンツの情報を表示するものである。

ステップＳ８０３においては、ユーザ端末装置４のコミュニケーションツール１０２により、コミュニケーションサーバ３のリコメンドサイトにアクセスする。このアクセスに際しては、ユーザＩＤを通知する。なお、以降において、このステップＳ８０３により通知するユーザＩＤに対応するユーザ、即ちリコメンドコンテンツにアクセスしたものとしてみることができるユーザについては、「リコメンド対象ユーザ（推薦対象ユーザ）」ということにする。

コミュニケーションサーバ３では、上記ステップＳ８０３に応じてユーザ端末装置４から送信されてきたユーザＩＤを受信すると、ステップＳ８０４により、副次コンテンツサーバ２に対して、リコメンドコンテンツリスト情報要求を送信する。また、このリコメンドコンテンツリスト情報要求の送信に際しては、ステップＳ８０３に応じてユーザ端末装置４から受信したユーザＩＤをともに通知（送信）する。

上記リコメンドコンテンツリスト情報要求を受信した副次コンテンツサーバ２では、ステップＳ８０５として、上記ステップＳ８０４に対応して受信したユーザＩＤの通知（送信）とともに、ユーザプロファイル情報要求をユーザ情報サーバ８に対して送信する。なお、このような送信処理は、例えば制御部２１がネットワークインターフェース２９を制御することで実現されるものとしてみることができる。

上記ユーザプロファイル情報要求を受信したユーザ情報サーバ８は、ステップＳ８０６により、先ず、このユーザプロファイル情報要求とともに通知されてきたユーザＩＤに対応するユーザプロファイル情報を、ユーザプロファイルデータベース２２ｂから検索する。図３６に示したように、ユーザプロファイル情報には、例えばその基本ユーザ情報内にユーザＩＤを含んでいる。そして、この検索したユーザプロファイル情報を、ユーザプロファイル情報要求に対するレスポンスとして、副次コンテンツサーバ２に対して返送する。

副次コンテンツサーバ２においては、上記のようにして送信されてくるユーザプロファイル情報をネットワークインターフェース２９により受信し、例えば制御部２１が取得する。このようにしてユーザプロファイル情報を受信取得した副次コンテンツサーバ２は、ステップＳ８０７により、副次コンテンツデータベース２２ａとして記憶されている副次コンテンツのうちからリコメンドコンテンツとしての副次コンテンツを抽出（選択）する処理を実行する。そして、その抽出結果に従って、リコメンドコンテンツについての所定の情報から成るリコメンドコンテンツリスト情報を作成する。
なお、このリコメンドコンテンツ抽出処理については、後述する。

リコメンドコンテンツリスト情報を作成した副次コンテンツサーバ２は、ステップＳ８０８により、先のステップＳ８０４に応じたリコメンドコンテンツリスト情報要求に対するレスポンスとして、リコメンドコンテンツリスト情報を送信する。

コミュニケーションサーバ３は、ステップＳ８０９により、上記ステップＳ８０８に応じて受信したリコメンドコンテンツリスト情報を利用して、リコメンドコンテンツリストページを作成する。このリコメンドコンテンツページとしてのコンテンツは、リコメンドサイト上のページコンテンツとされ、ユーザにリコメンドコンテンツを提示して見せるのに都合の良いページのデザインが為されている。このリコメンドコンテンツリストページの実体は、例えば、ＨＴＭＬ(Hyper Text Markup Language)やＸＭＬ(eXtensible Markup Language)などに代表される所定のマークアップ言語により記述されるファイル、データなどとなる。

そして、コミュニケーションサーバ３は、ステップＳ８１０により、例えばステップＳ８０３でのアクセスに対する応答として、作成したリコメンドコンテンツリストページのデータをユーザ端末装置４に対して送信する。

このようにリコメンドコンテンツリストページのデータを受信したユーザ端末装置４（コミュニケーションツール１０２）は、ステップＳ８１１の処理として、受信したリコメンドコンテンツリストページのデータを利用してＷｅｂページの表示を実行する。つまり、リコメンドコンテンツリストページの表示を行う。

ここで、上記図２３のステップＳ８０７としてのリコメンドコンテンツ抽出処理について、より詳細な説明を行っておく。
先ず、図２６により、本実施形態におけるリコメンドコンテンツの抽出についての基本的な概念について説明しておく。
ここで示されるベン図において、集合Ａは、副次コンテンツサー２において副次コンテンツデータベース２２ａとして記憶されている全ての副次コンテンツを要素とする集合である。
集合Ｂは、集合Ａに属する副次コンテンツ（副次コンテンツサーバ２にて記憶される副次コンテンツ）のうちで、原編集素材として利用される一次コンテンツ（利用原編集素材コンテンツ）の少なくとも１つがリコメンド対象ユーザの保有一次コンテンツである副次コンテンツを要素とする集合である。
さらに集合Ｃは、集合Ｂに属する副次コンテンツのうちで、利用原編集素材コンテンツとしての一次コンテンツの全てが上記リコメンド対象ユーザの保有一次コンテンツとされる副次コンテンツを要素とする集合となる。

本実施形態としては、副次コンテンツサーバ２が記憶する副次コンテンツのうちで、できるだけ多くの保有一次コンテンツを原編集素材として利用しているものが、その保有一次コンテンツのユーザに対して推薦する価値の高いものである、との考え方をとる。
その根拠としては、例えば下記のようになる。
先ず、リコメンド対象ユーザの保有一次コンテンツは、そのユーザ自身の好み、嗜好などに応じて集められたものであると考えることができる。すると、原編集素材コンテンツとして保有一次コンテンツの数が多い副次コンテンツほど、リコメンド対象ユーザにとっても関心が高く、嗜好に合うものであるということが推定できる。
また、本実施形態では、ダウンロードなどによりユーザが一次コンテンツを入手するのにあたっては、例えば原則、有料とされている。保有一次コンテンツは、ユーザが既に入手しているコンテンツである。すると、原編集素材コンテンツとして利用している保有一次コンテンツの数が多い副次コンテンツほど、これを再生出力するのに際して、新たに入手すべき一次コンテンツの数は少なくなり、ユーザのコスト負担が軽くなる、ということがいえる。

そこで、本実施形態としては、１以上の保有一次コンテンツを原編集素材コンテンツとして利用する副次コンテンツを、リコメンドコンテンツとして抽出（選択）するものとする。図２６との対応では、集合Ｂ（集合Ｃを含む）に属するとされる副次コンテンツをリコメンドコンテンツとして抽出することになる。
一方、全体集合Ａにおける集合Ｂの補集合となる副次コンテンツ、つまり、保有一次コンテンツを１つも原編集素材コンテンツとして利用していない副次コンテンツについては、原則、リコメンドコンテンツからは除外する。これは、上記したリコメンドコンテンツの根拠に倣えば、このような副次コンテンツは、ユーザにとってはほとんど関心がなく、また、嗜好にも合わないということが推定され、かつ、ユーザにもコスト負担を与えることになる、ということがいえるからである。

なお、上記したリコメンドコンテンツとして抽出すべき副次コンテンツの基準はあくまでも一例である。例えば原編集素材コンテンツの全てが保有一次コンテンツである副次コンテンツ、つまり図２６の集合Ｃに属する副次コンテンツをリコメンドコンテンツとして抽出させるように構成することも考えられる。さらには、２以上の所定数の保有一次コンテンツを原編集素材コンテンツとして利用する副次コンテンツをリコメンドコンテンツとして抽出させるように構成することも考えられる。

図２７、図２８のフローチャートを参照して、副次コンテンツサーバ２が実行するものとされる、図２３のステップＳ８０７としてのリコメンドコンテンツ抽出処理の手順例について説明する。この処理は、図７との対応では、リコメンドコンテンツ抽出処理部２５が実行するものとしてみることができる。
また、これら図２７、図２８に示されるリコメンドコンテンツ抽出処理は、以降の説明から理解されるように、先ずは、上記図２６により述べたリコメンドコンテンツについての基本的な選択基準に従ってリコメンドコンテンツを抽出する。そのうえで、いくつかの要素に基づいて、抽出したリコメンドコンテンツについて、推薦価値についての順位（推薦順位）を決定するようにされる。

図２７においては、先ず、ステップＳ９０１により、図２３のステップＳ８０６に対応して受信取得したユーザプロファイル情報（以降、リコメンド対応ユーザプロファイル情報という）から保有コンテンツリスト情報（保有一次コンテンツ情報）を取得する。

ここで、確認のために述べておくと、上記ステップＳ９０１における保有コンテンツリスト情報の取得元となるユーザプロファイル情報は、図２３のステップＳ８０３によりコミュニケーションサーバ３のリコメンドサイトにアクセスしてきたユーザ端末装置４（コンテンツ作成・共有アプリケーション１００）のユーザ（リコメンド対象ユーザ）に対応するものである。従ってステップＳ９０１にて取得される保有コンテンツリスト情報としては、リコメンド対象ユーザが保有しているとされる一次コンテンツファイル（保有一次コンテンツファイル）をリストとして示した内容を有していることになる。

次のステップＳ９０２においては、副次コンテンツデータベース２２ａから、上記ステップＳ９０１により取得した保有コンテンツリスト情報が示す一次コンテンツを原編集素材として含む副次コンテンツを検索する。この検索にあたっては、副次コンテンツデータベース２２ａにおける副次コンテンツごとの利用原編集素材コンテンツ情報（図１６）を参照すればよい。利用原編集素材コンテンツ情報において示される一次コンテンツ（コンテンツＩＤ）のなかに、保有コンテンツリスト情報が示す一次コンテンツ（コンテンツＩＤ）が１以上含まれるものが検索条件に該当する副次コンテンツとなる。そして、この検索条件に該当するものとして検索された一次コンテンツが、本実施形態におけるリコメンドコンテンツとなる。つまり、ステップＳ９０２は、副次コンテンツサーバ２にて記憶管理する全副次コンテンツファイルのうちから、リコメンドコンテンツを抽出する処理となる。
なお、ここでは検索（抽出）されたｎ個のリコメンドコンテンツについて、予め定めた所定の規則に従って、１〜ｎの番号を付すこととしている。

ステップＳ９０３においては、上記ステップＳ９０２により抽出されたリコメンドコンテンツ１〜ｎごとについて、不足コンテンツ数に基づいた基本的な推薦順位（基本推薦順位）を設定するための処理を実行する。
なお、ここでの不足コンテンツとは、リコメンドコンテンツとしての副次コンテンツを再生するのに必要とされる一次コンテンツ（原編集素材コンテンツ）のうちで、ステップＳ９０１にて取得した保有コンテンツリスト情報に示されていない一次コンテンツ、即ち、リコメンド対象ユーザの保有一次コンテンツではない一次コンテンツをいう。
また、この不足コンテンツ数は、原編集素材となる一次コンテンツにおいて保有一次コンテンツがどれだけ利用されているのかという事象（利用状況）を表しているということがいえる。本実施形態では、リコメンドコンテンツの推薦順位の設定にあたっては、かかる原編集素材における保有一次コンテンツの利用状況を最も重視すべき要素としている。保有一次コンテンツの利用状況は、図２６により説明した本実施形態のリコメンドコンテンツの抽出概念と密接な関係にあるからである。従って、不足コンテンツ数に基づいて設定される推薦順位としては、もっとも重視されるべき基本的なものとなる。つまり、基本推薦順位として扱われるべきものとなる。

図２８は、上記ステップＳ９０３としての不足コンテンツ数に応じた基本推薦順位設定についての手順例を示している。
この図においては、先ず、ステップＳ１００１により、リコメンドコンテンツの番号を示す変数ｎについて１を代入して初期化を行う。

ステップＳ１００２においては、副次コンテンツデータベース２２ａにアクセスして、リコメンドコンテンツｎとしての副次コンテンツファイルをオープンするファイル操作を実行する。
ここでのファイルオープンの操作は、ヘッダ情報における利用原編集素材コンテンツ情報を読み出すためのものである。従って、例えばファイルをオープンしなくとも副次コンテンツごとの利用原編集素材コンテンツ情報が参照できるような副次コンテンツデータベース２２ａの構造となっている場合には、ファイルオープンの処理に代えて、このリコメンドコンテンツｎとしての副次コンテンツの利用原編集素材コンテンツ情報を読み出すような処理として良い。

ステップＳ１００３においては、リコメンドコンテンツｎに対応する利用原編集素材コンテンツ情報を参照することにより、このリコメンドコンテンツｎにおいて利用されている一次コンテンツである原編集素材コンテンツを特定する。なお、ここでも、特定したｍ個の原編集素材コンテンツには、所定の規則に従って１〜ｍの番号を付している。

ステップＳ１００４、ステップＳ１００５は、ステップＳ１００６〜Ｓ１００９のための初期化処理となる。ステップＳ１００４においては、上記ステップＳ１００３において特定した原編集素材コンテンツの番号を示す変数ｍについて１を代入する。ステップＳ１００５において、リコメンドコンテンツｎの不足コンテンツ数を示す変数Ｆnに０を代入する。

ステップＳ１００６においては、図２７のステップＳ９０１にて取得した保有コンテンツリスト情報が示す一次コンテンツのなかに原編集素材コンテンツｍが含まれているか否かについて判別する。
ここで肯定の判別結果が得られた場合には、ステップＳ１００７をスキップしてステップＳ１００８に進む。
これに対して否定の判別結果が得られた場合には、ステップＳ１００７により、変数ＦnをインクリメントしてからステップＳ１００８に進む。

ステップＳ１００８においては、現在の変数ｍについて最大値以上となったか否かについて判別する。変数ｍの最大値は、ステップＳ１００３にて特定された原編集素材コンテンツの数となる。
ステップＳ１００８において否定の判別結果が得られた場合には、未だ保有コンテンツリスト情報（保有一次コンテンツ）に含まれているか否かを判別すべき原編集素材コンテンツが残っていることになるので、ステップＳ１００９により変数ｍについてインクリメントしてからステップＳ１００６に戻る。これにより、原編集素材コンテンツ１〜ｍごとにステップＳ１００６での判別が行われ、ここで否定の判別結果が得られた場合には、変数Ｆｎについてインクリメントが行われていくことになる。
そして、全ての原編集素材コンテンツ１〜ｍについてステップＳ１００６での判別が行われる結果、ステップＳ１００８にて肯定の判別結果が得られることとなって、ステップＳ１０１０に進む。
このステップＳ１００８にて肯定の判別結果が得られた場合には、リコメンドコンテンツｎについての不足コンテンツ数Ｆnが確定されたことになる。

ステップＳ１０１０においては、変数ｎが最大値以上になったか否かについての判別を行う。ここで否定の判別結果が得られた場合には、未だ不足コンテンツ数を取得していないリコメンドコンテンツが残っていることになる。そこで、この場合にはステップＳ１０１１により変数ｎについてインクリメントしたうえでステップＳ１００２に戻る。
これにより、リコメンドコンテンツ１〜ｎごとに不足コンテンツ数が求められることになる。そして、全てのリコメンドコンテンツ１〜ｎについての不足コンテンツ数を求めたとされると、ステップＳ１０１０において肯定の判別結果が得られることとなって、ステップＳ１０１２に進むことになる。

ステップＳ１０１２に至った段階では、リコメンドコンテンツ１〜ｎごとの不足コンテンツ数Ｆ1〜Ｆｎが求められていることになる。そこで、ステップＳ１０１２においては、不足コンテンツ数Ｆ1〜Ｆｎに基づいて、リコメンドコンテンツ１〜ｎの間での基本推薦順位を設定する。この基本推薦順位の設定の仕方については多様に考えられるので、ここでの具体例についての説明は省略する。原則としては、不足コンテンツ数が少ないものほど、高い推薦順位を与えるようにして設定するようにされる。

なお、上記ステップＳ９０３としての処理では、単純に不足コンテンツの数に基づいて基本推薦順位を設定することとしているが、例えば副次コンテンツにおいて原編集素材として利用される一次コンテンツのうちで不足コンテンツが占める割合、比率に基づいて基本推薦順位を設定することも考えられる。つまり、本実施形態としては、先にも述べた、原編集素材における保有一次コンテンツの利用状況に基づいて基本推薦順位が設定されればよいものであり、そのための具体的なアルゴリズムとしては、図２８に限定されるものではない。

説明を図２７に戻す。
先にも述べたように、本実施形態では、推薦順位の設定にあたり、原編集素材コンテンツにおける不足コンテンツの利用状況を最も重視すべき設定要素として捉えるものであり、このようにして設定された推薦順位が基本推薦順位となるものである。
ただし、本実施形態としては、基本推薦順位を設定したうえで、次に述べるステップＳ９０４以降によっては、上記利用状況以外の順位設定要素に基づいて係数（重み付け係数）を設定し、これらの係数を用いて、最終的には、上記他の順位設定要素も反映させた総合的な推薦順位（総合推薦順位）を得るようにされる。

ステップＳ９０３としての上記図２８による処理を実行した後は、図２７におけるステップＳ９０４の処理を実行する。
リコメンドコンテンツには、リコメンド対象ユーザの保有一次コンテンツが原編集素材コンテンツとして含まれている。そこで、ステップＳ９０４においては、リコメンド対応ユーザプロファイル情報から、リコメンドコンテンツ１〜ｎごとに、原編集素材コンテンツとして利用しているリコメンド対象ユーザの保有一次コンテンツについてのコンテンツ個別情報を取得する処理を実行する。
そして、ステップＳ９０５においては、上記ステップＳ９０４により取得したコンテンツ個別情報の内容に基づいて、総合推薦順位設定のための要素としてリコメンドコンテンツ１〜ｎごとに対応する係数Ｂ1〜Ｂn（第１の重み付け係数）を求めて設定する。

コンテンツ個別情報には、図２４（ｃ）に示すようにして、対応する一次コンテンツについての、ローカルでの通算再生回数、期限内再生回数、レートなどが示されているが、これらの情報は、その一次コンテンツに対するリコメンド対象ユーザの評価が示されているものとしてみるこができる。
つまり、例えば通算再生回数が多いほど、ユーザはその一次コンテンツを気に入っており、それだけ評価が高いということがいえる。また、期限内再生回数が多ければ、ここ最近において特に評価が高いコンテンツであるということがいえる。また、レートも、その値が高いほど、ユーザはその一次コンテンツを高く評価しているといえる。
そして、このようにして、リコメンドコンテンツにおける原編集素材コンテンツについて、ユーザの評価が高いということは、そのリコメンドコンテンツとしても、それだけユーザに推薦する順位としては高くなるべきである、ということがいえる。
ステップＳ９０５においては、上記した根拠に基づいて、所定の規則に従ったアルゴリズム、演算などにより、リコメンドコンテンツ１〜ｎについての係数Ｂ1〜Ｂnを求めるようにされる。

続くステップＳ９０６、Ｓ９０７は、リコメンドコンテンツの新しさに応じて、リコメンドコンテンツ1〜ｎについての推薦順位設定要素となる、係数Ｃ1〜Ｃｎを求める処理となる。例えば、リコメンドコンテンツとして新しいものほど、リコメンド対象ユーザに推薦する価値は高いという考え方を採ることができるが、ステップＳ９０６、Ｓ９０７は、この考え方に従ったものとなる。

ステップＳ９０６では、コンテンツプロファイルデータベース２２ｂにアクセスして、個々に登録されるリコメンドコンテンツ１〜ｎごとに対応したコンテンツプロファイル情報から、アップロード日時の情報を取得する。つまり、リコメンドコンテンツ１〜ｎとしての副次コンテンツごとに対応するアップロード日時を認識するものである。
そして、ステップＳ９０７により、上記のアップロード日時の情報に基づいて、リコメンドコンテンツ１〜ｎごとの係数Ｃ1〜Ｃn（第３の重み付け係数）を設定する。
アップロード日時が現在日時に近いほど、その副次コンテンツは新しいものであることになる。そこで、例えば基本的には、アップロード日時が遅いもののほうがより高い値となるようにして係数Ｃ1〜Ｃnを設定するようにされる。

ステップＳ９０８、Ｓ９０９は、本実施形態のコンテンツ作成・共有システムのユーザについての総合的な副次コンテンツの評価に応じて、推薦順位設定要素の係数Ｄ1〜Ｄnを設定する処理となる。
リコメンドコンテンツとしての副次コンテンツの推薦順位を設定するのにあたっては、リコメンド対象ユーザ以外にも多数存在するユーザ全般の副次コンテンツに対する評価を要素に入れることも有効であると考えられる。例えば、ユーザ全般の総合的な評価などは、リコメンド対象ユーザから見れば、他者の客観的な評価となる。このような第三者の評価も考慮することで、例えば、より的確な推薦順位が得られるとの考え方をとることもできる。ステップＳ９０６、Ｓ９０７は、この考え方に従ったものとなる。
ちなみに、これに対して、ステップＳ９０４、Ｓ９０５により設定される係数Ｂ1〜Ｂnは、リコメンド対象ユーザ個人に対応したコンテンツの評価に基づいたものであるといえるが、いずれも、考え方次第で、推薦順位設定に有効な要素となるものである。

ステップＳ９０８においては、コンテンツプロファイルデータベース２２ｂにアクセスして、個々に登録されるリコメンドコンテンツ１〜ｎごとに対応したコンテンツプロファイル情報から、総合利用情報を取得する。総合利用情報とは、図２５においても述べたように、コンテンツプロファイル情報における総合ダウンロード数、総合レート、総合再生回数の情報となる。これらの情報は、いずれも、対応する副次コンテンツについてのユーザ全般を対象とした総合的な評価の結果が示されている情報であるとしてみることができる。
そこで、ステップＳ９０９においては、上記ステップＳ９０８により取得したリコメンドコンテンツ１〜ｎごとの総合利用情報の内容に基づき、所定の規則、アルゴリズムに従って、係数Ｄ1〜Ｄn（第２の重み付け係数）を設定する。この場合にも、例えば総合ダウンロード数、総合レート、総合再生回数が多いほど、その副次コンテンツについてのユーザ間での評価は高いということがいえるので、基本的には、総合ダウンロード数、総合レート、総合再生回数が多いものほど、高い係数値となるように設定することになる。また、この場合には、総合利用情報として総合ダウンロード数、総合レート、総合再生回数の３つの情報項目が存在するが、これらの３つの情報項目間でその重要度などに応じて重み付けを与えたうえで、係数Ｄ1〜Ｄnを設定することが考えられる。また、あるいは、総合ダウンロード数、総合レート、総合再生回数ごとに、それぞれ独立した係数を設定することとしてもよい。

ステップＳ９１０においては、上記ステップＳ９０３により設定された基本推薦順位を基としたうえで、さらに、ステップＳ９０４〜Ｓ９０９までの手順により設定された係数Ｂ1〜Ｂｎ,Ｃ1〜Ｃｎ,Ｄ1〜Ｄｎに基づいて、リコメンドコンテンツ1〜n間での総合推薦順位を設定するようにされる。
つまり、リコメンドコンテンツ１〜ｎごとに、先のステップＳ９０２にて設定された基本推薦順位ごとに対応して、例えば点数（ポイント）を設定する。このときには、基本推薦順位が高いものから低いものとなるにつれ、ポイントも所定の規則に従って少なくなっていくようにする。そして、例えばリコメンドコンテンツ１については、上記の基本推薦順位に応じてリコメンドコンテンツ１に与えられたポイントと、係数Ｂ1、Ｃ1、Ｄ1とを利用した所定の演算を行って評価値Ｖ1を得るようにされる。残るリコメンドコンテンツ２〜ｎについても同様にして、それぞれ、リコメンドコンテンツ１〜ｎに与えられたポイントと、係数Ｂ2〜Ｂn、Ｃ2〜Ｃn、Ｄ2〜Ｄnを利用して評価値Ｖ2〜Ｖnを得る。そして、例えばこれらの評価値Ｖ1〜Ｖnの大小関係に基づいて、リコメンドコンテンツ１〜ｎ間での総合推薦順位を設定するようにされる。
例えばこのときに、基本推薦順位を基とするポイントについて、各係数の値よりも大きな重み値を与えるようにすう。そのうえで、各係数ついては、例えばこれらの各係数を設定する基となった順位設定要素（原編集素材とされる一次コンテンツについてのリコメンド対象ユーザの評価、副次コンテンツファイルの新しさ、副次コンテンツファイルについてのユーザ全般による評価）ごとの重要性などに応じて重み付けを行うようにされる。そして、これらのポイント、係数を用いて評価値を求めることで、基本推薦順位が最も重視されたうえでの、他の順位設定要素を加味した推薦順位の修正が行われるようにして総合推薦順位を設定することができる。
なお、ステップＳ９０３において基本推薦順位を設定する代わりに、この基本推薦順位に相当するものとして、ポイントであるとか係数を求めるようにしてもよい。そのうえで、最終的には、係数Ｂ2〜Ｂn、Ｃ2〜Ｃn、Ｄ2〜Ｄnも併用して総合推薦順位を設定する。

そして、ステップＳ９１１においては、上記ステップＳ９１０により設定された総合推薦順位が反映されるようにして、リコメンドコンテンツ１〜ｎを示したリコメンドコンテンツリスト情報を作成する。
なお、リコメンドコンテンツリスト情報の構造としては、例えばリコメンドコンテンツごとに付随する所定のメタデータを格納したものを考えることができる。このメタデータは、例えばリコメンドコンテンツとしての副次コンテンツファイルのヘッダ情報から得ることができる。また、コンテンツ作成・共有アプリケーション１００が独自で副次コンテンツごとに付加して管理しているメタデータを利用することもできる。
このようにして作成されたリコメンドコンテンツリスト情報が、図２３のステップＳ８０８によって、副次コンテンツサーバ２からコミュニケーションサーバ３に対して送信される。そして、このリコメンドコンテンツリスト情報が、最終的には、図２３のステップＳ８１１により、リコメンド対象ユーザのユーザ端末装置４にて表示される。つまり、リコメンド対象ユーザは、自身に適合して選択されたリコメンドコンテンツについて、その推薦順も把握できるようにして見て確認することができる。

上記図２７、図２８によると、本実施形態のリコメンドコンテンツの抽出処理としては、先ず、大前提として、リコメンド対象ユーザの保有一次コンテンツを原編集素材コンテンツとして含む副次コンテンツをリコメンドコンテンツとして選択するようにされる。
コンテンツの推薦の手法として、例えば１つには、ユーザ全般によるコンテンツの評価（例えばヒットチャートなど）を基にしたものなどがよく知られている。また、特許文献２においては、タイトル、キーワード、ジャンルなどに応じてコンテンツを推薦することのできる技術が開示されている。
しかし、ユーザに副次コンテンツを推薦するのにあたっては、上記したようなこれまでの手法では、ユーザに適合するコンテンツを的確に抽出することが難しい場合がある。例えば、ヒットチャートに相当するユーザ全般の評価を主たる抽出条件にした場合、その抽出した副次コンテンツに、必ずしも、リコメンド対象のユーザが保有する一次コンテンツが含まれているとは限らない。副次コンテンツと一次コンテンツとの関係性においては、リコメンド対象ユーザが保有している一次コンテンツが原編集素材として利用されていなければ、その副次コンテンツは、リコメンド対象ユーザに全く興味がない副次コンテンツとなる可能性が高いからである。また、同様にして、副次コンテンツが一次コンテンツを原編集素材とする二次創作物であるという特徴上、タイトル、キーワード、ジャンルなどを抽出条件にしたとしても、同様にして、抽出された副次コンテンツにおいて、リコメンド対象ユーザの保有一次コンテンツが含まれていない可能性は避けられない。
これに対して、本実施形態のようにして、リコメンド対象ユーザの保有する一次コンテンツを含む副次コンテンツを先ずリコメンドコンテンツとして選択する、というようにすれば、一次コンテンツが副次的に利用して創作されるものであるという副次コンテンツの特質に対応して、適切に推薦すべきコンテンツを抽出、選択できることになる。また、ユーザが保有する一次コンテンツに基づくのであるから、ユーザごとの嗜好などにも適合した選択が行われる結果となるものである。

そのうえで、本実施形態では、先ず、不足コンテンツ数（Ｓ９０２、Ｓ９０３）により基本的な推薦順位を設定する。これにより、単に推薦順位を設定することなくリコメンドコンテンツを提示する場合と比較して、ユーザは、提示されたリコメンドコンテンツの中からの絞り込みを効率的に行える。

またさらに、本実施形態では、上記基本推薦順位を修正して総合推薦順位を最終的に求めることとしている。これによって、最終的に得られる推薦順位（総合推薦順位）としては、より信頼性の高いものとなって、例えばリコメンドコンテンツのなかからの絞り込みをさらに効率よく行えることになる。
また、基本推薦順位を修正するのにあたっては、原編集素材として利用される保有一次コンテンツについてのリコメンド対象ユーザによる評価（ステップＳ９０４、Ｓ９０５）、リコメンドコンテンツの新しさ（Ｓ９０６、Ｓ９０７）、鑑賞者としてのユーザ全般による副次コンテンツの評価（Ｓ９０８、Ｓ９０９）を用いることとしている。つまり、推薦順位について多様な側面の要素により修正しようとしている。これにより、例えば或る側面の要素に偏って推薦順位を修正しようとする場合よりも、的確な推薦順位が得られることが期待される。
ただし、本実施形態においては、基本推薦順位の修正は必ずしも必須ではない。つまり、ステップＳ９０３により設定された基本推薦順位を修正することなく、そのまま総合推薦順位として扱うこととしても良い。この場合には、ステップＳ９０４〜Ｓ９１０の手順は省略される。
また、基本推薦順位を修正して総合推薦順位を得るにあたっても、必ずしも、係数Ｂ1〜Ｂn、係数Ｃ1〜Ｃn、係数Ｄ1〜Ｄnの全種を利用する必要はない。本実施形態のもとでは、これらの係数種別のうちの少なくとも1種を利用すればよい。また、係数Ｂ1〜Ｂn、係数Ｃ1〜Ｃn、係数Ｄ1〜Ｄn以外にも、推薦順位の修正に用いることのできる条件を利用して求めた他の係数を利用できる。

なお、上記図２３〜図２８により説明した例によれば、副次コンテンツサーバ２によりリコメンドコンテンツリストを抽出してリコメンドコンテンツリスト情報を作成するのにあたっては、リコメンド対象ユーザのユーザプロファイル情報を利用している。そのうえで、副次コンテンツサーバ２は、ユーザプロファイル情報をユーザ情報サーバ８から取得することとしている。
しかしながら、例えば、ユーザ端末装置４のコンテンツ作成・共有アプリケーション１００から、対応するユーザのユーザプロファイル情報の送信とともにリコメンドコンテンツリスト情報を要求するようなシステム動作とすることも可能である。
このような構成の場合、ユーザ端末装置４のコンテンツ作成・共有アプリケーション１００は、上記の例と同様にして、コミュニケーションサーバ３のリコメンドサイトにアクセスし、この際においてユーザＩＤに代えてユーザプロファイル情報を送信するようにしてもよい。この場合には、副次コンテンツサーバ２は、コミュニケーションサーバ３から転送されたユーザプロファイル情報を利用してリコメンドコンテンツの抽出、リコメンドコンテンツリスト情報の作成を行えばよい。あるいは、ユーザ端末装置４のコンテンツ作成・共有アプリケーション１００は、副次コンテンツサーバ２に対して、直接的にユーザプロファイル情報を送信するようにしてリコメンドコンテンツリスト情報の要求を行うようにしてもよい。いずれにせよ、リコメンドコンテンツリスト情報の取得のために、ユーザ端末装置４からユーザプロファイル情報を送信する場合には、ユーザ情報サーバ８からユーザプロファイル情報を送信してもらって取得する必要性は無くなる。ただし、実際においては、ユーザ情報サーバ８を設けてここで全ユーザのユーザプロファイル情報を一元管理していることで、例えばコンテンツのリコメンド以外の面でも、ユーザにとって価値のあるサービスを提供でき、また、システム運営側でのユーザ管理が効率的なものとなるので、その有用性は失われるものではない。

また、上記図２３〜図２８により説明した副次コンテンツ推薦のための処理にあっては、リコメンド対象ユーザのユーザプロファイル情報により、リコメンドコンテンツの抽出と推薦順位を設定し、リコメンドコンテンツリストの作成を行っている。ユーザプロファイル情報は、例えば保有一次コンテンツごとについてのメタデータであると見ることができる。また、リコメンドコンテンツリストの内容としては、先に述べたように、リコメンドコンテンツのメタデータから成るものとしている。つまり、本実施形態の副次コンテンツ推薦のための処理は、メタデータをリコメンドコンテンツ抽出のためのキーとして用いるとともに、その抽出結果についてもリコメンドコンテンツに関連したメタデータで返している、ということがいえる。

ところで、上記したリコメンドコンテンツ抽出の根拠となる考え方は、「リコメンド対象ユーザが保有している一次コンテンツが含まれる数であるとか割合、比率が多い副次コンテンツほど、そのリコメンド対象ユーザにとって鑑賞する価値が高い」というものである。この考え方を応用して、本実施形態のコンテンツ作成・共有システムでは、副次コンテンツを作成したユーザ（クリエータ）が、その副次コンテンツをアップロードして供給可能な状態としたときに、例えばどれくらいの数のユーザが鑑賞してくれるのかを知ることもできるようにされている。このための構成について、次に説明する。なお、以降において、作成した副次コンテンツを鑑賞してくれる可能性のあるユーザについては、「鑑賞可能ユーザ」ということにする。

図２９は、副次コンテンツのクリエータが鑑賞可能ユーザについての情報を得られるようにするためのシステムの動作例を示している。
このためには、先ず、クリエータは、コンテンツ管理・作成ツール１０１に対する操作として、自身が作成してユーザ端末装置４（ローカル）に保存しているとされる副次コンテンツのうちで、クリエータが得たいとする鑑賞可能ユーザの情報に対応する副次コンテンツを指定する。そして、この指定した副次コンテンツについての鑑賞可能ユーザについての情報を要求するための操作を実行する。この操作に応じて、図のステップＳ１１０１として示すように、ユーザ端末装置４（コンテンツ管理・作成ツール１０１）から、ユーザ情報サーバ８に対して、鑑賞可能ユーザ情報要求を送信するようにされる。この要求の送信に際しては、指定した副次コンテンツのヘッダ情報を送信するようにされる。

鑑賞可能ユーザ情報要求を受信したユーザ情報サーバ８では、ステップＳ１１０２により鑑賞可能ユーザ情報を作成する。このステップＳ１１０２としての鑑賞可能ユーザ情報作成処理の手順例を、図３０に示す。

図３０においては、先ず、ステップＳ１２０１により、鑑賞可能ユーザ情報要求とともに受信したヘッダ情報に格納される利用原編集素材コンテンツ情報から、ここに示されている原編集素材コンテンツ１〜ｎを特定する。この特定処理の実際としては、例えば利用原編集素材コンテンツ情報から、原編集素材コンテンツとしての一次コンテンツのコンテンツＩＤを取得すればよい。
次のステップＳ１２０２では、上記ステップＳ１２０１により特定した原編集素材コンテンツについての番号（及びユーザグループＧの番号）を示す変数ｎについて１を代入する初期化を行う。

ステップＳ１２０３においては、ユーザグループＧn-1から、原編集素材コンテンツ１を保有するユーザを検索する。このようにして検索されたユーザの集合をここではユーザグループＧnとしている。
なお、変数ｎ==１である場合、ユーザグループＧn-1はＧ0となる。ここでは、ユーザグループＧ0は、ユーザ情報サーバ８のユーザプロファイルデータベース５２ａに登録されている全てのユーザから成るグループであるとして規定されているものとする。従って、ステップＳ１２０１に続いて最初に実行するステップＳ１２０３によっては、登録されている全てのユーザのうちから、原編集素材コンテンツ１を保有するユーザを検索して、これらの検索されたユーザ群をユーザグループＧ1とすることになる。
また、このステップＳ１２０３による検索は、ユーザプロファイルデータベース５２ａを形成するユーザごとのユーザプロファイル情報のうちで、保有一次コンテンツ情報において、原編集素材コンテンツｎと同じコンテンツＩＤを含むものを検索するようにされる。このようにして検索されたユーザプロファイル情報が、即ち、原編集素材コンテンツ１を保有するユーザに対応する。

ステップＳ１２０３によるユーザグループＧnの検索処理を実行すると、ステップＳ１２０４にて現在の変数ｎは最大値以上であるか否かについて判別する。ここで否定の判別結果が得られた場合には、ユーザグループＧnの検索に利用する原編集素材コンテンツが未だ残っていることになる。そこで、この場合にはステップＳ１２０５により変数ｎについてインクリメントしてからステップＳ１２０３に戻るようにされる。

このようにして、ステップＳ１２０１にて特定された原編集素材コンテンツ１〜ｎごとに、順次、ステップＳ１２０３によるユーザグループＧnの検索が行われるが、これは、原編集素材コンテンツ１〜ｎを全て保有するユーザグループを絞り込んでいく処理シーケンスであるとみることができる。

原編集素材コンテンツ１〜ｎの全てについて、ステップＳ１２０３によるユーザグループＧnの検索が終了したとされると、ステップＳ１２０４にて肯定の判別結果が得られることとなって、ステップＳ１２０６に進むことになる。
ステップＳ１２０６に至った段階は、ステップＳ１２０１にて特定された原編集素材コンテンツ１〜ｎとしての一次コンテンツを全て保有しているユーザのみからなるユーザグループＧｎが得られていることになる。
このようにして、その副次コンテンツが原編集素材として利用する一次コンテンツを全て保有しているユーザは、その副次コンテンツが自分の嗜好に合う可能性が高いことになる。従って、この副次コンテンツをアップロードした際には、これをダウンロードして鑑賞する可能性が非常に高いといえる。このことに基づき、本実施形態では、原編集素材コンテンツ１〜ｎとしての一次コンテンツを全て保有しているユーザを、鑑賞可能ユーザとして扱うものである。即ち、最終的に検索されたユーザグループＧnは、全員が鑑賞可能ユーザであることになる。換言すれば、ステップＳ１２０１〜Ｓ１２０４の処理は、ユーザプロファイルデータベース５２ａに登録されるユーザの内から鑑賞可能ユーザを検索する処理となるものである。

そして、ステップＳ１２０６においては、最終的なユーザグループＧnの検索結果を利用して、鑑賞可能ユーザ情報を作成する。
この鑑賞可能ユーザ情報の内容として、最も簡単なものの１つとしては、鑑賞可能ユーザの数を示すものとすることが考えられる。また、これに加えて、ユーザプロファイル情報において示される通算再生回数、期限内再生回数、レートなどの情報を反映させることも考えられる。つまり、原編集素材コンテンツ１〜ｎについて、鑑賞可能ユーザがどのくらい再生しているのか、また、どのようなレートを設定しているのかという情報を付加できる。

説明を図２９に戻す。
上記図３０に示す処理の結果により作成された鑑賞可能ユーザ情報は、ステップＳ１１０３により、ユーザ情報サーバ８から、要求元のユーザ端末装置４に対して送信する。
ユーザ端末装置４では、ステップＳ１１０４により、例えばコンテンツ管理・作成ツール１０１が、受信した鑑賞可能ユーザ情報を利用して、鑑賞可能ユーザについての情報を提示する表示が行われるように制御を実行する。

クリエータであるユーザは、上記のようにして表示される鑑賞可能ユーザについての情報を見て、副次コンテンツ作成の参考にすることができる。一例として、鑑賞可能ユーザの数が非常に少なかったとする。クリエータとしては、できるだけ多くのユーザに鑑賞してもらいたいので、例えば、副次コンテンツの原編集素材として利用する一次コンテンツのうち、保有しているユーザが少なそうなものを使わないようにして、副次コンテンツを作り直すことができる。

なお、図３０に例示した処理では、ユーザ情報サーバ８が受信したヘッダ情報において利用するのは、利用原編集素材コンテンツ情報のみとされている。従って、この場合に関しては、図２９のステップＳ１１０１において、メタデータとしてヘッダ情報の全体を送信するのではなく、その一部となる利用原編集素材コンテンツ情報のみから成るメタデータを送信することとしてもよい。

また、先にも述べたように、例えば図２３〜図２８により説明した副次コンテンツ推薦のための処理は、「一次コンテンツ（保有一次コンテンツ）のメタデータをリコメンドコンテンツ抽出のためのキーとして用い、その抽出結果も、リコメンドコンテンツとしての副次コンテンツに関するメタデータで返している」ものとして捉えられる。
そして、このことに基づけば、本実施形態の下で、ユーザプロファイルに限定されないメタデータをリコメンドコンテンツ抽出のキーとして利用し、抽出されるべきリコメンドコンテンツとしても副次コンテンツに限定されることなく一次コンテンツも含むことのできるシステム構成を考えることができる。
参考として、本実施形態における拡張されたコンテンツ推薦のための構成を、図３１のシーケンス図により説明しておく。
なお、この図についての説明にあたっては、コミュニケーションサーバ３は、一次コンテンツと副次コンテンツ両者についてのリコメンドサイトを提供しているものとする。

この図において、先ず、ステップＳ１３０１、Ｓ１３０２は、図２３のステップＳ８０１、Ｓ８０２と同様となることから、ここでの説明を省略する。

ステップＳ１３０３は、ユーザ端末装置４のコミュニケーションツール１０２により、コミュニケーションサーバ３のリコメンドサイトにアクセスする手順となる。このリコメンドサイトへのアクセスに際しては、図２３のステップＳ８０３と同様にして、リコメンド対象ユーザのユーザＩＤを通知することとしている。

なお、拡張例におけるリコメンドサイトとしては、例えば一次コンテンツに対応したサイトと副次コンテンツに対応したサイトとで、それぞれが異なるＵＲＬによりアクセスすべき独立したものとされてもよいし、一次コンテンツと副次コンテンツとの両者に対応した統合的なサイトとして構築されたものであってもよい。
この拡張例の場合において、リコメンド対象ユーザは、上記ステップＳ１３０３によりアクセスしたリコメンドサイト上において、そこに提示されているコンテンツを任意に選ぶことができる。そして、例えば１つのコンテンツを選んだうえで、この選んだコンテンツ（リコメンド元コンテンツ）に関連したリコメンドコンテンツを提示してもらうための操作、つまり、リコメンドコンテンツ要求のための操作を行うことができる。
このリコメンドコンテンツ要求の操作に応じては、ステップＳ１３０４として示すように、コミュニケーションサーバ３が、一次コンテンツサーバ１若しくは副次コンテンツサーバ２に対して、リコメンドコンテンツリスト情報要求を送信する。
なお、このステップＳ１３０４の処理に際して、コミュニケーションサーバ３は、リコメンド元コンテンツが一次コンテンツである場合においては、一次コンテンツサーバ１に対してリコメンドコンテンツリスト情報要求を送信する。一方、リコメンド元コンテンツが副次コンテンツであれば、副次コンテンツサーバ２に対してリコメンドコンテンツリスト情報要求を送信する。

そして、この拡張例の場合においては、リコメンドコンテンツリスト情報要求の送信に際しては、例えば、リコメンド対象ユーザのユーザＩＤとともに、リコメンド元コンテンツに付加されたメタデータ（キーワード）のうちから、例えば１つのメタデータを選択してリコメンドコンテンツ抽出のためのキーとして送信する。
上記リコメンドコンテンツ抽出のためのキーとしてのメタデータをどのようにして選択するのかについては、いくつか考えることができるが、例えば１つには、リコメンドサイト上でコンテンツを提示する際に、そのコンテンツに付加されているメタデータ（キーワード）をリスト表示させるようにしたうえで、このリスト表示されるメタデータから、リコメンド対象ユーザの操作に応じて任意のメタデータを、上記リコメンドコンテンツ抽出のためのキーとして選択できるようにすることが考えられる。

上記ステップＳ１３０４によるリコメンドコンテンツリスト情報要求を受信した一次コンテンツサーバ１若しくは副次コンテンツサーバ２は、ステップＳ１３０５によりユーザ情報サーバ８に対してユーザプロファイル情報要求を送信する。このステップＳ１３０５は、図２３におけるステップＳ８０５に準じたものとなる。そして、ユーザ情報サーバ８は、ユーザプロファイル情報要求の受信に応答して、ステップＳ１３０６によりユーザプロファイル情報を検索し、これを要求元の一次コンテンツサーバ１若しくは副次コンテンツサーバ２に返す。

上記のようにしてユーザプロファイル情報を受け取った一次コンテンツサーバ１若しくは副次コンテンツサーバ２は、ステップＳ１３０７により、リコメンドコンテンツ抽出のための処理を実行する。
このための処理としては、例えば先ず、一次コンテンツサーバ１の場合であれば、一次コンテンツデータベース１２ａとして記憶されている一次コンテンツのうちから、上記ステップＳ１３０２により受信したメタデータに一致、若しくは一定の類似度の範囲で類似するメタデータを有する一次コンテンツを検索（抽出）する。
例えば、メタデータとしてのキーワードが「海」であったとすると、同じく「海」をメタデータとして有する一次コンテンツが抽出されることになる。さらには、「海」から連想される類似した語（例えば「シーサイド「マリン」など」をメタデータとして有する一次コンテンツも抽出できる。

そのうえで、さらに一次コンテンツサーバ１は、上記のようにしてメタデータを検索キーとして検索した一次コンテンツについて、推薦順位を設定する処理を実行する。このための処理としては、いくつか考えることができるが、例えばステップＳ１３０６により取得したユーザプロファイル情報を利用することが考えられる。

ユーザプロファイル情報を利用した一次コンテンツの推薦順位設定例を挙げておく。
ユーザプロファイル情報によっては、リコメンド対象ユーザの保有一次コンテンツが示される。そこで、一次コンテンツサーバ１は、一次コンテンツデータベース１２ａから、これらの保有一次コンテンツに付随されるメタデータを抽出して解析を行い、リコメンド対象ユーザの好みを認識する。
一例として、ジャンルのメタデータを利用した例を挙げる。保有一次コンテンツごとのジャンルを解析した結果として、保有一次コンテンツにおけジャンルの順位を求めるようにする。
先のメタデータを検索キーとする抽出処理によっては、多様なジャンルのうちから「海」に関連したメタデータを有する一次コンテンツが抽出されたのであるが、例えばこれらのコンテンツとしてはジャンルには関係なく抽出されたものである。そこで、「海」に関連したメタデータを有するものとして抽出された一次コンテンツについて、上記した保有一次コンテンツにおけるジャンルの順位を反映させることで、推薦順位を設定することができる。

また、ステップＳ１３０７として、副次コンテンツサーバ２がリコメンドコンテンツの抽出処理を実行する場合には、例えば、図２３により説明したステップＳ８０７に準ずればよい。また、上記の一次コンテンツの場合のようにして、副次コンテンツに付加されたキーワードやジャンルなどのメタデータを積極的に利用してもよい。

以降のステップＳ１３０８〜Ｓ１３１１については、図２３のステップＳ８０８〜Ｓ８１１と同様となることから、ここでの説明は省略する。
なお、上記ステップＳ１３０４におけるリコメンドコンテンツリスト要求に際して送信するメタデータとしてのキーワード（検索キー）は複数とされても構わない。この場合、ステップＳ１３０７としては、これら複数のメタデータをしかるべき条件式に当て嵌めたうえで、リコメンドコンテンツ抽出のためのコンテンツ検索処理を実行すればよい。

なお、一次コンテンツサーバ１、副次コンテンツサーバ２、コミュニケーションサーバ３、ユーザ情報サーバ８、及びユーザ端末装置４の構成は一例であって、実際には適宜変更されて構わない。また、上記各サーバの少なくとも１つが、複数のサーバに分散されるような形態を採っても構わない。あるいは逆に、これらのサーバのうちの少なくとも２つが統合されるようにして構成されてもよいものである。
例えば本願発明の構成要件は、本実施形態との対応では、副次コンテンツサーバ２に含めることができるが、これらの構成要件に対応する構成部を、しかるべきサーバに分散させたうえで、これらのサーバが協働することにより、本願発明としての情報処理装置の構成を実現することも可能である。

また、これまでの説明にあっては、コンテンツ作成・共有アプリケーション１００としてのＧＵＩ画面などの具体例は示していないが、コンテンツ作成・共有アプリケーション１００のＧＵＩ構成は多様に考えられるものである。

また、コンテンツ作成・共有アプリケーション１００の機能構成としても、図１１、図１２などにより説明した内容に限定されるものではなく多様に考えられる。
また、図１３、図１４〜図１７などに示した副次コンテンツファイルの構造はあくまでも一例であり、また、概念的なものであるので、これを基にして適宜変更、拡張されて良い。
また、各図においてフローチャートとして示した処理手順、つまりプログラム構成もあくまで一例であり、実際のものとしては適宜変更されて良い。

また、一次コンテンツサーバ１、コンテンツサーバ２、コミュニケーションサーバ３、ユーザ情報サーバ８、ユーザ端末装置４などが実行するプログラムは、上記のようにして、例えば内部のＨＤＤ、記憶部などの記憶領域に対して書き込んで記憶させるほか、リムーバブルの記憶媒体に記憶させておいたうえで、この記憶媒体からインストール(アップデートも含む)させるようにして上記の記憶領域に記憶させることが考えられる。また、所定のデータインターフェース経由により、他のホストとなる機器からの制御によってプログラムのインストールを行えるようにすることも考えられる。さらに、ネットワーク上の記憶装置に記憶させておいたうえで、一次コンテンツサーバ１、コンテンツサーバ２、コミュニケーションサーバ３、ユーザ情報サーバ８、ユーザ端末装置４が有するネットワーク機能により、上記記憶装置からダウンロードして取得できるように構成することも考えられる。

本発明の実施の形態が対応するコンテンツ作成・共有システムの構成例を示す図である。 実施の形態のコンテンツ作成・共有システムの基本的な利用態様と、これに対応したシステム動作の手順例を示す図である。 実施の形態における副次コンテンツの作成の流れを模式的に示す図である。 実施の形態における副次コンテンツの再生の流れを模式的に示す図である。 副次コンテンツを作成するにあたっての、編集素材コンテンツの利用態様例を示す図である。 一次コンテンツサーバの内部構成例を示す図である。 副次コンテンツサーバの内部構成例を示す図である。 コミュニケーションサーバの内部構成例を示す図である。 ユーザ情報サーバの内部構成例を示す図である。 ユーザ端末装置の内部構成例を示す図である。 ユーザ端末装置のＨＤＤ内に記憶されるべきデータ内容例を示す図である。 コンテンツ作成・共有アプリケーションのコンテンツ管理・作成ツールとしてのプログラム構成例を機能ブロックにより示す図である。 副次コンテンツファイル及び一次コンテンツファイルの構造例を示す模式的に示す図である。 コンテンツファイルのヘッダ情報を形成する情報項目例を示す図である。 ヘッダ情報を形成する情報項目の１つである本コンテンツ関連基本情報を形成する情報項目例を示す図である。 副次コンテンツ再生制御ファイルにおける、利用原編集素材コンテンツ情報、利用編集素材コンテンツ情報の構造例を示す図である。 副次コンテンツファイルにおける、再生制御情報の内容例を示す図である。 コンテンツ作成・共有アプリケーションが、副次コンテンツ編集処理にあたって、編集素材コンテンツの利用許諾範囲設定を、ＵＩに反映させるための処理手順例を示すフローチャートである。 コンテンツ作成・共有アプリケーションが、副次コンテンツ編集処理として副次コンテンツファイルを作成するまでの処理手順例を示すフローチャートである。 ユーザ端末装置による副次コンテンツのアップロードと、これに応じた副次コンテンツサーバの処理手順例を示すフローチャートである。 ユーザ端末装置による副次コンテンツのダウンロードと、これに応じた副次コンテンツサーバの処理手順例を示すフローチャートである。 ユーザ端末装置による副次コンテンツの再生処理手順例を示すフローチャートである。 副次コンテンツ推薦に関連してコンテンツ作成・共有システムにおいて行われるる動作、処理を示すシーケンス図である。 ユーザプロフィル情報の構造例を示す図である。 コンテンツプロファイル情報の構造例を示す図である。 実施の形態におけるリコメンドコンテンツ抽出についての基本概念を模式的に示す図である。 副次コンテンツサーバが実行する、リコメンドコンテンツ抽出の処理手順例を示すフローチャートである。 抽出したリコメンドコンテンツについての不足コンテンツ数に応じた基本推薦順位を設定するための処理手順例を示すフローチャートである。 ユーザ端末装置とユーザ情報サーバとの間で実行される、鑑賞可能ユーザについての情報を得るためのシステムの動作例を示すシーケンス図である。 ユーザ情報サーバにて実行する鑑賞可能ユーザ情報を作成するための処理手順例を示すフローチャートである。 実施の形態の下での拡張例としてのコンテンツ推薦に関連した動作、処理例を示すシーケンス図である。

符号の説明

１ 一次コンテンツサーバ、２ 副次コンテンツサーバ、３ コミュニケーションサーバ、４（４Ａ、４Ｂ） ユーザ端末装置、５ ネットワーク、６ エフェクトデータベース、７ 素材データベース、８ ユーザ情報サーバ、１１・２１・３１ 制御部、１２・２２・３２ 記憶部、１３・２３・３３・５３ 認証処理部、１４・２４・５５ 検索処理部、１５・５４ データベース管理部、１６ 決済処理部、１７・２８・５６ 暗号化処理部、１８・２９・３６・４４・５７ ネットワークインターフェース、２６Ａ コンテンツデータベース管理部、２６Ｂ プロファイルデータベース管理部、２７ 保存場所設定処理部、３４ ブログ稼働処理部、３５ ＳＮＳ稼働処理部、１２ａ 一次コンテンツデータベース、２２ａ 副次コンテンツデータベース、２２ｂ コンテンツプロファイルデータベース、３２ａ ブログデータベース、３２ｂ ＳＮＳデータベース、４１ ＣＰＵ、４２ ＲＯＭ、４３ ＲＡＭ、４５ 入出力インターフェース、４６ 入力デバイス、４７ メディアドライブ、４８ ＨＤＤ、４９ ディスプレイモニタ、１００ コンテンツ作成・共有アプリケーション、１０１ コンテンツ管理・作成ツール、１０２ コミュニケーションツール、１０３ 一次コンテンツファイル群、１０４ 副次コンテンツファイル群、 １１１ 通信制御部、１１２ 一次コンテンツ取得処理部、１１３ 一次コンテンツ管理処理部、１１４ 副次コンテンツ取得処理部、１１５ 副次コンテンツ管理処理部、１１６ コンテンツ転送処理部、１１７ コンテンツ作成処理部、１１８ 副次コンテンツファイル生成、解釈処理部、１１９ 暗号化・解読処理部、１２０ 再生出力処理部、１２１ ユーザプロファイル管理処理部

Claims (6)

1. 一次コンテンツとしてのオーディオ・ビデオのコンテンツデータをデータベース化して管理する一次コンテンツサーバと、
   上記一次コンテンツを利用して製作される副次コンテンツをデータベース化して管理する副次コンテンツサーバと、
   上記副次コンテンツを利用するユーザが使用する、複数個からなるネットワーク機器であるユーザ端末装置と、
   上記ユーザ端末装置ごとに関連したユーザプロファイル情報を記憶するユーザ情報サーバと、
   上記一次コンテンツサーバと、上記副次コンテンツサーバと、上記ユーザ端末装置と、上記ユーザ情報サーバと、を相互に接続するネットワークと、を備え、
   上記副次コンテンツサーバは、
   上記一次コンテンツの再生を指示する情報を含む上記副次コンテンツを、データベース化して記憶部に記憶して構築される副次コンテンツデータベースと、
   上記副次コンテンツデータベースの管理を行うコンテンツデータベース管理部と、を有して形成される記憶管理手段と、
   上記ユーザプロファイル情報の一つである、上記ユーザ端末装置ごとに保有している上記一次コンテンツについての情報である保有一次コンテンツ情報を、上記ネットワークを介して受信するネットワークインターフェースを有して形成される情報取得手段と、
   上記副次コンテンツデータベースに記憶されている上記副次コンテンツのうちから、上記ユーザ端末装置ごとに利用の優先度が高い副次コンテンツであるリコメンドコンテンツを抽出する処理と、抽出されたリコメンドコンテンツのリストであるリコメンドコンテンツリスト情報を生成する処理と、を実行するリコメンドコンテンツ抽出処理部を有して形成される副次コンテンツ選択手段と、
   該副次コンテンツサーバにおける制御処理を統括して実行する制御部と、を具備し、
   上記制御部は、
   上記保有一次コンテンツ情報によって指定される、少なくとも１つの一次コンテンツを利用している上記副次コンテンツを、上記リコメンドコンテンツとして抽出するように制御をするとともに、
   上記リコメンドコンテンツとして抽出された上記副次コンテンツに優先順位を付して、上記ユーザ端末装置ごとに通知をするに際して、上記保有一次コンテンツ情報によって指定されない一次コンテンツの数がより少ない副次コンテンツに、より高い優先順位を付して上記ユーザ端末装置ごとに通知をするように制御をする、
   情報処理装置。
2. 上記制御部は、
   上記優先順位に対して、さらに、該副次コンテンツの上記ユーザ端末装置ごとにおける、通算再生回数が多いほど、重みが高くなるように設定される第１の係数を加重して、該優先順位を修正し、該第１の係数によって修正された優先順位を上記ユーザ端末装置ごとに通知をするように制御をする、
   請求項１に記載の情報処理装置。
3. 上記制御部は、
   上記優先順位、又は、上記第１の係数によって修正された優先順位に対して、さらに、該副次コンテンツの、すべての上記ユーザ端末装置における、通算再生回数が多いほど、重みが高くなるように設定される第２の係数を加重して、該優先順位、又は、該第１の係数によって修正された優先順位を修正する制御を行い、該第２の係数によって修正された優先順位を上記ユーザ端末装置ごとに通知をするように制御をする、
   請求項１、又は、請求項２のいずれかに記載の情報処理装置。
4. 上記制御部は、
   上記優先順位、又は、上記第１の係数及び上記第２の係数によって修正された優先順位に対して、さらに、該副次コンテンツが、上記副次コンテンツサーバにアップロードされた日時が現在日時に近いほど、重みが高くなるように設定される第３の係数を加重して、該優先順位、又は、該第１の係数及び該第２の係数によって修正された優先順位を修正する制御を行い、該第３の係数によって修正された優先順位を上記ユーザ端末装置ごとに通知をするように制御をする、
   請求項１、又は、請求項３のいずれかに記載の情報処理装置。
5. 情報処理装置の情報処理方法であって、
   上記情報処理装置は、
   一次コンテンツとしてのオーディオ・ビデオのコンテンツデータをデータベース化して管理する一次コンテンツサーバと、
   上記一次コンテンツを利用して製作される副次コンテンツをデータベース化して管理する副次コンテンツサーバと、
   上記副次コンテンツを利用するユーザが使用する、複数個からなるネットワーク機器であるユーザ端末装置と、
   上記ユーザ端末装置ごとに関連したユーザプロファイル情報を記憶するユーザ情報サーバと、
   上記一次コンテンツサーバと、上記副次コンテンツサーバと、上記ユーザ端末装置と、上記ユーザ情報サーバと、を相互に接続するネットワークと、を備え、
   上記副次コンテンツサーバの副次コンテンツデータベースは、上記一次コンテンツの再生を指示する情報を含む上記副次コンテンツを、データベース化して記憶部に記憶し、
   上記副次コンテンツサーバのコンテンツデータベース管理部は、上記副次コンテンツデータベースの管理を行い、
   上記副次コンテンツサーバのネットワークインターフェースは、上記ユーザプロファイル情報の一つである、上記ユーザ端末装置ごとに保有している上記一次コンテンツについての情報である保有一次コンテンツ情報を、上記ネットワークを介して受信し、
   上記副次コンテンツサーバのリコメンドコンテンツ抽出処理部は、上記副次コンテンツデータベースに記憶されている上記副次コンテンツのうちから、上記ユーザ端末装置ごとに利用の優先度が高い副次コンテンツであるリコメンドコンテンツを抽出する処理と、抽出されたリコメンドコンテンツのリストであるリコメンドコンテンツリスト情報を生成する処理と、を実行し、
   上記副次コンテンツサーバにおける制御処理を統括して実行する制御部は、上記保有一次コンテンツ情報によって指定される、少なくとも１つの一次コンテンツを利用している上記副次コンテンツを、上記リコメンドコンテンツとして抽出する制御を行うとともに、
   上記リコメンドコンテンツとして抽出された上記副次コンテンツに優先順位を付して、上記ユーザ端末装置ごとに通知をするに際して、上記保有一次コンテンツ情報によって指定されない一次コンテンツの数がより少ない副次コンテンツに、より高い優先順位を付して上記ユーザ端末装置ごとに通知をするように制御をする、
   情報処理方法。
6. 情報処理装置の副次コンテンツサーバの制御部で実行されるプログラムであって、
   上記情報処理装置は、
   一次コンテンツとしてのオーディオ・ビデオのコンテンツデータをデータベース化して管理する一次コンテンツサーバと、
   上記一次コンテンツを利用して製作される副次コンテンツをデータベース化して管理する上記副次コンテンツサーバと、
   上記副次コンテンツを利用するユーザが使用する、複数個からなるネットワーク機器であるユーザ端末装置と、
   上記ユーザ端末装置ごとに関連したユーザプロファイル情報を記憶するユーザ情報サーバと、
   上記一次コンテンツサーバと、上記副次コンテンツサーバと、上記ユーザ端末装置と、上記ユーザ情報サーバと、を相互に接続するネットワークと、を備え、
   上記副次コンテンツサーバの制御部は、
   副次コンテンツデータベースが、上記一次コンテンツの再生を指示する情報を含む上記副次コンテンツを、データベース化して記憶部に記憶して構築される処理と、
   コンテンツデータベース管理部が上記副次コンテンツデータベースの管理を行う処理と、
   ネットワークインターフェースが、上記ユーザプロファイル情報の一つである、上記ユーザ端末装置ごとに保有している上記一次コンテンツについての情報である保有一次コンテンツ情報を、上記ネットワークを介して受信する処理と、
   リコメンドコンテンツ抽出処理部が、上記副次コンテンツデータベースに記憶されている上記副次コンテンツのうちから、上記ユーザ端末装置ごとに利用の優先度が高い副次コンテンツであるリコメンドコンテンツを抽出する処理と、抽出されたリコメンドコンテンツのリストであるリコメンドコンテンツリスト情報を生成する処理と、
   上記保有一次コンテンツ情報によって指定される、少なくとも１つの一次コンテンツを利用している上記副次コンテンツを、上記リコメンドコンテンツとして抽出する処理と、
   上記リコメンドコンテンツとして抽出された上記副次コンテンツに優先順位を付して、上記ユーザ端末装置ごとに通知をするに際して、上記保有一次コンテンツ情報によって指定されない一次コンテンツの数がより少ない副次コンテンツに、より高い優先順位を付して上記ユーザ端末装置ごとに通知をする処理と、
   を実行するためのプログラム。

Images