JP2009294779A - 情報処理システム、情報処理方法 - Google Patents

Abstract

【課題】二次的創作物としての副次コンテンツを端末装置側で提示するのにあたり、システム内でのその処理が効率的に行われるようにする。
【解決手段】副次コンテンツを推薦するのにあたっては、先ず、サーバにおいて推薦コンテンツを抽出し、推薦コンテンツ情報を端末装置に返す。そして、端末装置においては、推薦コンテンツ情報が示す推薦コンテンツについての推薦順位を設定したうえで、推薦コンテンツを提示する。つまり、推薦コンテンツの抽出処理と推薦順設定処理とをサーバ装置と端末装置とで分散させる。
【選択図】図２２

Description

本発明は、例えばコンテンツの作成と、作成したコンテンツのデータの共有などをネットワーク経由で行うことのできる情報処理システムと、この情報処理システムにおいて適用される情報処理方法とに関する。

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

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

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

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

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

そこで本発明は上記した課題を考慮して、情報処理システムとして次のように構成することとした。
つまり、端末装置とサーバ装置とから成り、サーバ装置において、コンテンツの少なくとも１つを編集素材として二次利用する編集処理により作成されるもので、コンテンツ内容を再現するための情報として、原編集素材となる一次コンテンツの実コンテンツデータについての再生を指示する内容を含んで形成される再生制御情報を有する副次コンテンツを記憶管理する記憶管理手段と、端末装置において、推薦対象ユーザが保有しているものとみなされる一次コンテンツである保有一次コンテンツについての再生処理を実行する再生手段と、端末装置において、再生手段により再生処理が実行されている一次コンテンツを特定するコンテンツ識別子とともに推薦コンテンツ情報要求をサーバ装置に対して送信する推薦コンテンツ情報要求手段と、サーバ装置において、受信したコンテンツ識別子が示す一次コンテンツを原編集素材に含む副次コンテンツを、記憶管理手段により管理される副次コンテンツのうちから抽出する副次コンテンツ抽出手段と、サーバ装置において、副次コンテンツ抽出手段により抽出した副次コンテンツを推薦コンテンツとし、これら推薦コンテンツごとに対応するメタデータにより形成される推薦コンテンツ情報を端末装置に対して送信する推薦コンテンツ情報送信手段と、端末装置において、受信した推薦コンテンツ情報により示される推薦コンテンツについての推薦順位を設定するもので、推薦コンテンツごとについての、原編集素材における保有一次コンテンツの利用状況に基づいて推薦順位を設定する推薦順位設定手段と、端末装置において、上記推薦順位が反映されるようにして推薦コンテンツ情報により示される推薦コンテンツを提示する提示手段とを備えることとした。

また、情報処理システムとして、次のようにも構成することとした。
つまり、端末装置とサーバ装置とから成り、サーバ装置において、コンテンツの少なくとも１つを編集素材として二次利用する編集処理により作成された副次コンテンツを記憶管理する記憶管理手段と、端末装置において、コンテンツについての再生処理を実行する再生手段と、端末装置において、再生手段により再生処理が実行されているコンテンツに付加されているメタデータとともに推薦コンテンツ情報要求をサーバ装置に対して送信する推薦コンテンツ情報要求手段と、サーバ装置において、受信したメタデータを抽出条件として、記憶管理手段により管理される副次コンテンツのうちから１以上の副次コンテンツを抽出する副次コンテンツ抽出手段と、サーバ装置において、副次コンテンツ抽出手段により抽出した副次コンテンツを推薦コンテンツとし、これら推薦コンテンツごとのメタデータにより形成される推薦コンテンツ情報を端末装置に対して送信する推薦コンテンツ情報送信手段と、端末装置において、受信した推薦コンテンツ情報により示される推薦コンテンツについての推薦順位を設定するもので、推薦コンテンツ情報に含まれる推薦コンテンツごとのメタデータ記述内容についての、推薦対象ユーザが保有しているものとみなされる保有コンテンツ全体のメタデータ記述内容における出現数に基づいて、推薦順位を設定する推薦順位設定手段と、端末装置において、推薦順位が反映されるようにして、推薦コンテンツ情報により示される推薦コンテンツを提示する提示手段とを備えることとした。

上記各構成において、推薦対象となるコンテンツは、副次コンテンツファイルとされている。副次コンテンツファイルは、１以上のコンテンツファイルを二次利用することにより作成されるもので、原編集素材として利用する一次コンテンツファイルが有する実コンテンツデータについての再生を指示する再生制御情報を有する構造のファイルである。
そして、この副次コンテンツを推薦するのにあたっては、先ず、サーバにおいて推薦コンテンツを抽出し、推薦コンテンツ情報を端末装置に返す。そして、端末装置においては、推薦コンテンツ情報が示す推薦コンテンツについての推薦順位を設定したうえで、推薦コンテンツを提示する。つまり、本願においては、最終的に、端末装置側にて、そのときに再生中とされる１つのコンテンツに関連した推薦コンテンツを推薦順とともに提示するのであるが、推薦コンテンツの抽出はサーバ装置にて行い、推薦順設定は端末装置で行う、というように処理を分散させている。

このように本願発明としては、推薦コンテンツの抽出処理と、推薦順設定処理とをサーバ装置と端末装置とで分散して行うので、一方の装置に多大な負荷が掛かることなく、システム全体として推薦コンテンツを推薦順とともに提示する動作を効率的に実現できる。
また、推薦コンテンツの抽出の起点としては、端末装置にて再生中のコンテンツのみに限定しているので、例えばリコメンド対象ユーザが保有するコンテンツの多くを対象として推薦コンテンツを抽出するような構成と比較すれば、顕著な負荷軽減効果が得られる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

制御部１１は、一次コンテンツサーバ１における各種制御処理を統括して実行する部位とされ、例えばＣＰＵ(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)を提供する。ユーザは、このＧＵＩを利用して副次コンテンツ作成のための編集操作を行うようにされ、この操作に応じて、ステップＳ２０１としての処理が実行される。
そして、上記のようにして編集処理を行っている過程において、ステップＳ２０２により、これまでの編集結果を保存するための操作の行われたことが判別されると、ステップＳ２０３に進む。ステップＳ２０３においては、これまでの編集結果により得られたコンテンツ内容に応じた副次コンテンツファイルを生成する。
副次コンテンツファイルの生成にあたっては、それまでの編集結果を反映したヘッダ情報と、再生制御情報とを生成し、これらを組み合わせるようにしてファイルを生成する。
ステップＳ２０４は、上記のようにして作成した副次コンテンツファイルを、例えばＨＤＤ４８におけるしかるべきディレクトリに保存するように制御を実行する。ステップＳ２０４の手順が終了したのであれば、ステップＳ２０１に戻るようにされる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ところで、本実施形態のようなコンテンツ作成・共有システムの場合、ユーザ間で共有可能となる副次コンテンツ、即ち副次コンテンツサーバ２が記憶管理する副次コンテンツファイルの数は膨大な数になり得る。
また、先に述べたように、本実施形態のコンテンツ作成・共有システムでは、前述のようにして、知人のユーザなどからの副次コンテンツの紹介などの通知がなくとも、副次コンテンツサーバのダウンロードサイトにアクセスして、任意の副次コンテンツをダウンロードできることとしている。
このようなことを考慮すると、本実施形態のコンテンツ作成・共有システムにあっては、膨大な数の副次コンテンツのなかから、ユーザが、自分に合った副次コンテンツをどれだけ効率良く見つけられるか、ということが重要になってくるといえる。

そこで、本実施形態のコンテンツ作成・共有システムとしては、ユーザごとに応じて適切、適当とされる副次コンテンツを効率よく選択して、各ユーザに提示できるようにすることを目指す。そのうえで、現状の技術レベルなどに照らし合わせて、現実においてできるだけ効率的な構成を提案する。

なお、本実施形態において「ユーザごとに応じて適切、適当とされる副次コンテンツを提示する」ということは、そのユーザにとって鑑賞する価値があるであろう副次コンテンツを推薦する、という意味合いを持つ。つまり、以降の説明は、ユーザごとに応じて、そのユーザに適合するとされる副次コンテンツを推薦（リコメンド）するための構成についてのものであるといえる。また、このことに因み、或るユーザに応じて適合するとして選択された副次コンテンツについては、「リコメンドコンテンツ」ともいうことにする。

図２２は、副次コンテンツの推薦に関連してコンテンツ作成・共有システムにおいて行われる処理の一例を示している。ここでは処理を実行する主体として、ユーザ端末装置４におけるプレーヤ部１２０（コンテンツ管理・作成ツール１０１）、コミュニケーションツール１０２、リコメンドコンテンツ関連処理部１２１（コンテンツ管理・作成ツール１０１）、副次コンテンツサーバ２が示されている。
なお、以降の説明の理解のために、この図に示される処理により得られる副次コンテンツ推薦の動作の概略を述べておく。先ず、ユーザ端末装置４における状態としては、プレーヤ部１２０を起動させて一次コンテンツを再生しているときに、コミュニケーションツール１０２も動作させておくようにする。この状態において、コミュニケーションツール１０２を主体とするユーザ端末装置４は、副次コンテンツサーバ２から、プレーヤ部１２０にて現在再生中の一次コンテンツに関連して抽出されたリコメンドコンテンツのリストを受け取り、このリストのデータを利用して、コミュニケーションツール１０２によるＧＵＩ画面上において、リコメンドコンテンツを表示して提示する。
また、プレーヤ部１２０にて再生中とされ、上記のようにしてリコメンドコンテンツ抽出（検索）のためのキー（抽出条件・検索条件）となる一次コンテンツについては「キー一次コンテンツ」ともいう。

先ず、図２２のステップＳ８０１においては、プレーヤ部１２０により、ユーザ端末装置４のユーザが保有しているものとしてみることのできる一次コンテンツのうちで、或る１つの一次コンテンツを再生出力する処理を実行しているものとする。
なお、ここでのユーザによるコンテンツの「保有」とは、例えば、１つにはそのユーザのコンテンツ作成・共有アプリケーション１００（ユーザ端末装置４）にとってローカルとしてみることのできる環境にて一次コンテンツファイルを記憶管理している状態をいう。また、例えばローカルにて存在しておらず、サーバなどに存在しているとしても、例えばコンテンツ作成・共有アプリケーション１００によりアクセスして再生できるようなものがあれば、このような一次コンテンツファイルもユーザが「保有」しているものとしてみることができる。このような一次コンテンツの例としては、例えば、サブスクリプションなどといわれる予約購読的なコンテンツ視聴契約によりサーバから任意にストリーミングによる再生若しくはダウンロードによるローカ保存ができるようなものを挙げることができる。これは、例えばその再生開始に際して改めて料金負担を強いられることなく、ユーザが再生できる権利を有しているコンテンツであるともいえる。

ここで、上記ステップＳ８０１によりプレーヤ部１２０にて一次コンテンツを再生中にあるとされる状態において、コミュニケーションツール１０２も立ち上がって動作中の状態にあるとする。この状態の下では、ステップＳ８０２として示すようにして、コミュニケーションツール１０２は、プレーヤ部１２０にて現在再生中の一次コンテンツ、即ちキー一次コンテンツが何であるのかを通知してもらうための通知要求を、プレーヤ部１２０に対して行う。

プレーヤ部１２０は、ステップＳ８０３により上記の通知要求を受信すると、その応答として、キー一次コンテンツを特定して示すものとして、例えばそのコンテンツＩＤをコミュニケーションツール１０２に対して返す。

ステップＳ８０３に応じてキー一次コンテンツのコンテンツＩＤを受け取ったコミュニケーションツール１０２は、ステップＳ８０４により、副次コンテンツサーバ２に対してリコメンドコンテンツリストを要求する処理を実行する。ここで要求するリコメンドコンテンツリストとは、ステップＳ８０１に対応して現在再生中とされる一次コンテンツに対応するリコメンドコンテンツが示される単位情報をいう。そして、このステップＳ８０４としての処理は、コミュニケーションツール１０２としてのプログラムにより、ユーザ端末装置４からネットワーク経由で、副次コンテンツサーバ２に対してリコメンドコンテンツリスト要求としてのデータを送信させるものとなる。また、このリコメンドコンテンツリスト要求の送信の際には、例えばそのオペランドに対して、ステップＳ８０３にて通知されたキー一次コンテンツを特定する情報として、そのコンテンツＩＤを埋め込む。
なお、上記のステップＳ８０３、Ｓ８０４の処理においてやりとりされるキー一次コンテンツのコンテンツＩＤについては「キーコンテンツＩＤ」ともいう。

ステップＳ８０４によりリコメンドコンテンツリスト要求を受信した副次コンテンツサーバ２は、ステップＳ８０５により、リコメンドコンテンツを抽出する処理を実行し、このリコメンドコンテンツの抽出結果が反映された内容のリコメンドコンテンツリスト（推薦コンテンツ情報）を作成する処理を実行する。なお、このステップＳ８０５の処理は、図７との対応では、主にリコメンドコンテンツ処理部２５が実行するものとしてみることができる。

ここで、上記ステップＳ８０５においてリコメンドコンテンツ関連処理部１２１が実行するリコメンドコンテンツ抽出処理の一例について説明する。
先ず、図２３を参照して、ここでのリコメンドコンテンツ抽出処理についての基本概念を説明する。
なお、以降の説明において、ユーザ端末装置４のユーザが「保有」しているものとされる一次コンテンツについては「保有一次コンテンツ」ということにする。また、図２２においてユーザ端末装置４（プレーヤ部１２０）により一次コンテンツを再生させているとされるユーザについては、副次コンテンツを推薦する対象のユーザとなる。そこで、このユーザについては「リコメンド対象ユーザ（推薦対象ユーザ）」ということにする。

図２３に示されるベン図において、集合Ａは、副次コンテンツサー２において副次コンテンツデータベース２２ａとして記憶されている全ての副次コンテンツを要素とする集合である。
集合Ｂは、集合Ａに属する副次コンテンツ（副次コンテンツサーバ２にて記憶される副次コンテンツ）のうちで、原編集素材として利用される一次コンテンツ（利用原編集素材コンテンツ）にキー一次コンテンツを含む副次コンテンツを要素とする集合である。

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

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

そして、図２２のステップＳ８０５において、上記図２３の集合Ｂに属する副次コンテンツをリコメンドコンテンツとして抽出するための処理の具体例としては、次のようになる。
つまり、リコメンドコンテンツ抽出処理部２５は、副次コンテンツデータベース２２ａに登録される副次コンテンツのうちから、利用原編集素材コンテンツ情報においてステップＳ８０４により取得したキーコンテンツＩＤを含むものを検索する。
利用原編集素材コンテンツ情報には、現副次コンテンツの原編集素材となる（即ち再生に必要となる）一次コンテンツのコンテンツＩＤが示されている。従って利用原編集素材コンテンツ情報にキーコンテンツＩＤを含むということは、その現副次コンテンツの原編集素材として、キー一次コンテンツ、つまりプレーヤ部１２０にて再生中の一次コンテンツを含んでいることになる。即ち、図２３における集合Ｂに属する副次コンテンツが抽出される結果となる。

次に、リコメンドコンテンツ抽出処理部２５は、同じステップＳ８０５として、上記のようにしてリコメンドコンテンツとして抽出した副次コンテンツを示す内容の情報である、リコメンドコンテンツリストを作成する。
なお、このリコメンドコンテンツリストとしては、例えば抽出した副次コンテンツごとの所定の定義内容のメタデータから成るものとして作成することができる。この際、副次コンテンツごとのメタデータは、例えば副次コンテンツファイルにおけるヘッダ情報を基にして得ることができる。

リコメンドコンテンツリストの模式的な構造例を図２４に示す。
この場合のリコメンドコンテンツリストは、抽出されたリコメンドコンテンツ１〜ｎごとに、その副次コンテンツファイルにおけるヘッダ情報を抜き出し、これらを配列させた構造となっている。ヘッダ情報は対応する副次コンテンツについてのメタデータの集合としてみることができるので、このリコメンドコンテンツリストとしても、抽出されたリコメンドコンテンツごとについてのメタデータ群としての構造を有しているといえる。

上記のようにして作成されたリコメンドコンテンツリストは、例えば制御部２１の制御により、ステップＳ８０６により、ネットワーク５を経由して、要求元のユーザ端末装置４に送信される。この場合のユーザ端末装置４では、受信したリコメンドコンテンツリストのデータを、コミュニケーションツール１０２が受け取る。

ところで、コミュニケーションツール１０２がステップＳ８０６により受け取った段階のリコメンドコンテンツリストは、単にリコメンドコンテンツに該当するとされた副次コンテンツが示されているのみであり、推薦にあたっての優先順位、即ち推薦順位についてはなにも示されていない。
例えば、適切に設定された推薦順位とともにリコメンドコンテンツをユーザに提示できるようにすれば、推薦順位を設定することなくリコメンドコンテンツを提示する場合と比較して、ユーザは、提示されたリコメンドコンテンツの中からの絞り込みを効率的に行えることになり、より使い易くなる。

そこで、コミュニケーションツール１０２は、リコメンドコンテンツリストのデータを受け取ったことに応じて、ステップＳ８０７として示すように、リコメンドコンテンツ関連処理部１２１に対して、推薦順位設定要求を行う。この推薦順位設定要求に際しては、例えばコミュニケーションツール１０２は、ステップＳ８０６にて取得したリコメンドコンテンツリストのデータを、リコメンドコンテンツ管理処理部１２１に渡すものとされる。

ステップＳ８０８においてリコメンドコンテンツ関連処理部１２１は、上記推薦順位設定要求に対する応答として、先ず、リコメンドコンテンツリストに登録されている副次コンテンツについての推薦順位を設定し、次に、設定した推薦順位をリコメンドコンテンツリストに反映させる。

上記ステップＳ８０８における推薦順位設定のためのアルゴリズムとしては、多様に考えることができるが、ここでは、リコメンドコンテンツ（副次コンテンツ）におけるリコメンド対象ユーザの保有一次コンテンツの利用状況（含有状況）に基づいて推薦順位を設定するものとする。
先に図２３により述べたように、二次的創作物としての特徴を有する副次コンテンツにあっては、「リコメンド対象ユーザの保有一次コンテンツを原編集素材として利用しているものが、そのリコメンド対象ユーザに対して推薦する価値が高い」という考え方を採ることができる。そして、この考え方に基づけば、リコメンド対象ユーザの保有一次コンテンツを原編集素材として多く利用しているものほど、そのリコメンド対象ユーザに対して推薦する価値が高くなっていく」ということがいえる。

上記の考え方に従い、ステップＳ８０８として、リコメンド対象ユーザの保有一次コンテンツの利用状況（含有状況）に基づいて推薦順位を設定するための処理手順例を、図２５のフローチャートに示す。

図２５において、先ず、リコメンドコンテンツ関連処理部１２１は、ステップＳ９０１により、リコメンドコンテンツの番号を示す変数ｎについて１を代入して初期化を行う。なお、この変数ｎとして付される番号は、リコメンドコンテンツリストに登録されている副次コンテンツに対して便宜的に与えられるものであって、推薦順位との関係は特にない。

ステップＳ９０２においてリコメンドコンテンツ関連処理部１２１は、リコメンドコンテンツリストから、ｎ番目のリコメンドコンテンツ（リコメンドコンテンツｎ）のメタデータの１つである、利用原編集素材コンテンツ情報を読み込む。確認のために述べておくと、利用原編集素材コンテンツ情報は、元々は副次コンテンツのヘッダ情報に含まれる情報であって、例えば図１５により説明した内容を有している。つまり、この場合のリコメンドコンテンツリストは、副次コンテンツごとのメタデータとして、利用原編集素材コンテンツ情報を含むものとしている。

ステップＳ９０３においては、リコメンドコンテンツ関連処理部１２１は、上記ステップＳ９０２により読み込んだ利用原編集素材コンテンツ情報を参照することにより、このリコメンドコンテンツｎにおいて利用されている原編集素材コンテンツ（一次コンテンツ）を特定する。なお、ここでも、特定したｍ個の原編集素材コンテンツには、所定の規則に従って１〜ｍの番号を付している。

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

なお、ここでの不足コンテンツとは、リコメンドコンテンツとしての副次コンテンツを再生するのに必要とされる一次コンテンツ（原編集素材コンテンツ）のうちで、リコメンド対象ユーザの保有一次コンテンツではない一次コンテンツをいう。また、不足コンテンツ数は、原編集素材となる一次コンテンツにおいて上記保有一次コンテンツがどれだけ利用されているのか（含まれているのか）という事象（利用状況・含有状況）を表しているということがいえる。

ここで、例えばコンテンツ管理・作成ツール１０１では、対応するユーザの保有一次コンテンツを管理するようにされている。この管理により、保有一次コンテンツごとのコンテンツＩＤを知ることができる。また、この管理は、図１１との対応では、例えば一次コンテンツ管理処理部１１３が実行するものとされればよい。あるいは、プレーヤ部１２０により、自身が再生可能な一次コンテンツとして管理するように構成することも考えられる。

そして、ステップＳ９０６では、リコメンドコンテンツ関連処理部１２１は、原編集素材コンテンツｍとしての一次コンテンツが、上記保有一次コンテンツに含まれているか否かについて判別する。このためには、保有一次コンテンツのコンテンツＩＤのなかで、原編集素材コンテンツｍを示すコンテンツＩＤと一致するものを検索すればよい。ステップＳ９０６としては、原編集素材コンテンツｍを示すコンテンツＩＤと一致する保有一次コンテンツのコンテンツＩＤが検索されれば肯定の判別結果が得られ、検索されなければ否定の判別結果が得られることになる。

ステップＳ９０６において肯定の判別結果が得られた場合にはステップＳ９０７をスキップしてステップＳ９０８に進む。これに対して否定の判別結果が得られた場合には、ステップＳ９０７により、変数ＦnをインクリメントしてからステップＳ９０８に進む。

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

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

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

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

説明を図２２に戻す。
ステップＳ８０８として、例えば上記図２５による推薦順位を設定したとされると、リコメンドコンテンツ関連処理部１２１は、同じステップＳ８０８において、この推薦順位の設定結果が反映されるようにしてリコメンドコンテンツリストを作成し直す。この処理としては、リコメンドコンテンツリストにおいてこれまで設定されていた副次コンテンツの配列順を、推薦順位に従ってソートし直すというものが考えられる。また、リコメンドコンテンツリストにおける副次コンテンツごとのメタデータに、新たに、推薦順位を示すデータを埋め込むようにすることも考えられる。

そして、ステップＳ８０９において、リコメンドコンテンツ関連処理部１２１は、推薦順位を反映させた内容に作成し直したリコメンドコンテンツリストを、推薦順位設定要求に対する応答としてコミュニケーションツール１０２に返す。

コミュニケーションツール１０２は、ステップＳ８１０の処理として、上記ステップＳ８０９により受け渡されたリコメンドコンテンツリストを利用して、リコメンドコンテンツを提示する画像を所定の態様により表示出力（提示）させるための処理を実行する。そして、この際には、設定された推薦順位が反映されるようにしてリコメンドコンテンツの提示を行うようにされる。

なお、例えば図２２においては、推薦順位についてはユーザ端末装置４側にて設定することとしているが、このような処理についてもサーバ（副次コンテンツサーバ２）側にて行うようにすることが考えられる。この構成を採れば、サーバ側において推薦順位の反映されたリコメンドコンテンツリストを作成することが可能になる。
しかし、例えば推薦順位についてもサーバ側にて設定しようとすると、不足コンテンツ数を求めるためには、ユーザごとの保有一次コンテンツの内訳が示される情報（保有一次コンテンツ情報）をサーバ側で記憶する必要があることになる。若しくは、サーバ側にて推薦順位設定を行おうとする都度、ユーザ端末装置４から保有一次コンテンツの内訳を示す情報を送信してもらうことが必要になる。
現実的なことを考慮すると、前者の場合には、膨大な数のユーザごとの保有一次コンテンツ情報をサーバ側で記憶管理することになるので、サーバ側での処理が重くなる可能性がある。また、後者の場合には、リコメンドコンテンツリストを作成する必要のある度に保有一次コンテンツ情報がネットワーク経由でやりとりされるが、例えば千単位、万単位で一次コンテンツを保有するユーザも少なからず存在すると考えられる。このようなユーザの保有一次コンテンツ情報のサイズは相当に大きなものとなるから、トラフィックの圧迫なども招きやすい。また、いずれの場合においても、保有一次コンテンツの内訳がサーバ側（即ち第三者）に知られることになるので、ユーザによっては、それを好まないことも多いと考えられる。

これに対して、本実施形態の場合であれば、副次コンテンツサーバ２側では、再生中の一次コンテンツのコンテンツＩＤに基づいてリコメンドコンテンツを抽出してリコメンドコンテンツリストを作成するだけであり、推薦順位設定はローカル（ユーザ端末装置４）側にて実行される。
このため、サーバ側において保有一次コンテンツ情報は不要となるので、上記したサーバ側の処理負担は軽減され、トラフィックの圧迫も考慮しなくてよい。また、保有一次コンテンツの内訳がサーバ側にて把握されることもない。

また、図２２の場合とは逆に、例えば、ユーザ端末装置４側から、全ての保有一次コンテンツのコンテンツＩＤを送信し、副次コンテンツサーバ２では、全ての保有一次コンテンツについて抽出した副次コンテンツによりリコメンドコンテンツリストを作成するように構成することも考えられる。
しかし、この場合には、リコメンドコンテンツとして提示されることになる副次コンテンツの数も非常に多くなると考えられる。また、保有一次コンテンツの全てをユーザが均等に気に入っているということも考えにくいために、実は推薦する価値のない副次コンテンツまでもがリコメンドコンテンツとして抽出される可能性が高くなる。
また、全ての保有一次コンテンツに対応してリコメンドコンテンツを抽出する処理も、特に保有一次コンテンツの総数が膨大である場合には、非常に重い処理となってしまう。
そこで、本実施形態としては、図２２において示したように、リコメンドコンテンツを抽出するためのキーとしては、ユーザ端末装置４にて再生中の１つの一次コンテンツに限定することで、上記の不都合を回避している。
このように本実施形態は、現状におけるコンピュータシステムの処理能力であるとか、ユーザのプライベートに関する意向などの現実的な事柄に対応したうえで、できるだけ効率良くコンテンツ推薦に関する動作が得られるように構成しているということがいえる。

また、推薦順位に関しては、例えば、不足コンテンツ数以外の条件に基づいて設定することも可能であり、また、不足コンテンツ数とこれ以外の１以上の条件に基づいて設定することも可能である。
不足コンテンツ数以外の条件としては、特に限定されるものではないが、例えば、リコメンドコンテンツの原編集素材に含まれる保有一次コンテンツについての、リコメンド対象ユーザによる再生履歴であるとかレーティング（お気に入り度）の設定などを用いることが考えられる。
その理由であるが、例えば再生履歴であるとかレーティングなどの情報を利用すれば、ユーザがそのコンテンツをどのくらい気に入っているのかを数量で表すことが可能である。そして、或る保有一次コンテンツをユーザが気に入っている度合いが高いほど、その保有一次コンテンツを原編集素材として含むリコメンドコンテンツは推薦すべき価値が高くなる、ということがいえるからである。
また、このようにして複数の条件により推薦順位を設定することした場合において、或る特定の条件に基づく推薦順位設定については、副次コンテンツサーバ２側にて行うようにしてもよい。つまり、推薦順位設定を、ユーザ端末装置４とサーバ側とで分散して行うことができる。この場合においては、例えばユーザ端末装置４にて、条件ごとに設定された推薦順位を総合して、最終的な推薦順位を求めるようにすればよい。

ところで、上記図２２に示した副次コンテンツ推薦のための処理にあっては、ユーザ端末装置４側から副次コンテンツサーバ２に対して、リコメンドコンテンツ抽出のためのキーとして、再生中の一次コンテンツ（キー一次コンテンツ）のコンテンツＩＤを送信している。そして、これに対する応答として、副次コンテンツサーバ２からユーザ端末装置４に対しては、リコメンドコンテンツのメタデータ群から成るリコメンドコンテンツリストを返すようにしている。
コンテンツＩＤは、コンテンツを特定する識別子であり、このことからすれば、広義ではコンテンツＩＤもコンテンツについての１つのメタデータであるとみることができる。すると、図２２に示した処理では、メタデータであるコンテンツＩＤを副次コンテンツサーバ２に渡したことに応じて、同じメタデータであるリコメンドコンテンツリストのデータが返されている、ということがいえる。つまり、図２２の処理にあっては、ユーザ端末装置４と副次コンテンツサーバ２との間では、コンテンツの実体的なデータのやりとりはされておらず、メタデータのみがやりとりされているものとしてみることができる。

そこで続いては、変形例として、メタデータによるやりとりをさらに積極的に採り入れた副次コンテンツ推薦の態様例について説明する。
例えば、先に図２２により説明した副次コンテンツ推薦のための構成では、ユーザ端末装置４側（プレーヤ部１２０）にて再生中とされる一次コンテンツが何であるのかを特定する識別情報、即ちコンテンツＩＤをキーとしてリコメンドコンテンツを抽出するシステム構成とされていた。

これに対して本変形例では、リコメンドコンテンツ抽出ためのキーとしては、ユーザ端末装置４側（プレーヤ部１２０）にて再生中とされるコンテンツのメタデータとなる。つまり、メタデータとして定義された項目（メタデータ項目）において記述される内容をキーとする。 一具体例として、「アーティスト（クリエータ）名」として定義されたメタデータ項目があるとして、このメタデータ項目において、「特許太郎」という内容が記述されているとすると、この「特許太郎」をキーとすることができる。

なお、この変形例でいうところのメタデータは、例えば先の実施形態におけるキーであるコンテンツＩＤとの対比では、狭義のメタデータといえる。
また、この変形例では、キーとなるメタデータが対応付けられるコンテンツについては、一次コンテンツと副次コンテンツとを問わない。

図２６は、変形例としての副次コンテンツ推薦のためにコンテンツ作成・共有システムにおいて実行される処理を示している。この図における処理の主体としても、ユーザ端末装置４におけるプレーヤ部１２０（コンテンツ管理・作成ツール１０１）、コミュニケーションツール１０２、リコメンドコンテンツ関連処理部１２１（コンテンツ管理・作成ツール１０１）、副次コンテンツサーバ２が示される。
なお、この説明にあたり、以降において、ユーザが保有しているとされる一次コンテンツについては、これまで同様、保有一次コンテンツということとしたうえで、ユーザが保有しているとされる副次コンテンツについては保有副次コンテンツということにする。また、保有一次コンテンツと保有副次コンテンツについて特に区別しない場合には保有コンテンツという。
また、ここでは前提を簡単で分かりやすいものとするために、一次コンテンツファイルのヘッダ情報の構造は、副次コンテンツファイルと同じく、図１３、図１４などに示したものであるとする。

先ずここでは、ステップＳ１００１として、プレーヤ部１２０によりコンテンツを再生出力するための処理を実行しているものとする。なお、ここで再生出力しているコンテンツは、一次コンテンツと副次コンテンツのいずれとされてもよい。

続くステップＳ１００２においては、コミュニケーションツール１０２からプレーヤ部１２０に対して、現在再生中のコンテンツに付加されたメタデータ項目のうちから指定された、１以上のメタデータ項目のデータを要求する。
ここで、ステップＳ１００２の処理を開始するきっかけ（トリガ）としては、例えば、コミュニケーションツール１０２のＧＵＩに対する操作として、プレーヤ部１２０により再生中のコンテンツに関連したリコメンドコンテンツの提供を指示する操作が行われた場合を挙げることができる。また、ステップＳ１００２のメタデータ要求に際して指定するメタデータ項目についても、ユーザ操作に応じて指定できるものとすればよい。例えばユーザが要求すべきメタデータ項目として「クリエータ名」を指定したとすれば、ステップＳ１００２においては、「クリエータ名」のメタデータ項目を指定して要求を行うことになる。

上記メタデータ要求を受け取ったプレーヤ部１２０は、ステップＳ１００３により要求されたメタデータを返す。つまり、メタデータ要求とともに指定されたメタデータ項目に記述された内容を返す。
ここで、プレーヤ部１２０がメタデータ項目に記述される内容を取得するのにあたっては、現在再生中のコンテンツのヘッダ情報におけるメタデータ項目のうちから、指定されたメタデータ項目に格納されているデータを読み出すこととすればよい。
例えば、メタデータ要求により指定されたメタデータ項目が「クリエータ名」であるとすると、プレーヤ部１２０は、現在再生中のコンテンツのヘッダ情報におけるクリエータ名のメタデータ項目に記述されるデータを読み出して取得することになる。
そして、プレーヤ部１２０は、上記のようにして取得したメタデータ項目のデータをコミュニケーションツール１０２に渡すことになる。

なお、ステップＳ１００２については、例えばユーザ指定操作などに応じて、２以上のメタデータ項目を指定してメタデータ要求を発行できるように構成することも可能である。この場合、ステップＳ１００３においては、指定された複数のメタデータ項目ごとの内容のデータを返すことになる。

コミュニケーションツール１０２は、ステップＳ１００３に応じてメタデータを受け取ると、ステップＳ１００４により、副次コンテンツサーバ２に対してリコメンドコンテンツリスト要求を送信する。このリコメンドコンテンツリスト要求にあたっては、例えばそのオペランドに、ステップＳ１００３にて受け取ったメタデータ（指定のメタデータ項目に記述されるデータ）を格納する。このメタデータが、後述するリコメンドコンテンツ抽出のためのキー（抽出条件・検索条件）として利用される。
なお、ステップＳ１００３にて受け取ったメタデータが複数の場合には、このステップＳ１００４によるリコメンドコンテンツリスト要求に際して、これらのメタデータを、抽出（検索）のための条件式とともに送信するようにすればよい。条件式についても、例えばステップＳ１００２に応じたメタデータ項目の指定の際に、ユーザ操作により指定できるようにすればよい。

上記ステップＳ１００４によるリコメンドコンテンツリスト要求を受信した副次コンテンツサーバ２のリコメンドコンテンツ抽出処理部２５は、ステップＳ１００５により、リコメンドコンテンツの抽出、及び抽出結果に基づくリコメンドコンテンツリストの作成を実行する。
先ず、この場合におけるリコメンドコンテンツの抽出は、ステップＳ１００４に応じてリコメンドコンテンツリスト要求とともに受信取得したメタデータをキー（抽出条件・検索条件）として行うようにされる。
例えば、取得したメタデータの内容がクリエータ名の１つである「特許太郎」であるとする。この場合、リコメンドコンテンツ抽出処理部２５は、副次コンテンツデータベース２２ａから、メタデータとして「特許太郎」の内容が付加されている副次コンテンツを検索する。本実施形態では、コンテンツに付加されるメタデータはヘッダ情報に格納することとしているので、この場合のリコメンドコンテンツ抽出処理部２５は、「特許太郎」の文字列としてのデータをヘッダ情報内に有する副次コンテンツを検索することになる。
なお、上記のようにして例えば「特許太郎」のデータをキーとして検索するのにあたっては、ヘッダ情報における「クリエータ名」のメタデータ項目のみを検索していくこととしてもよいが、ヘッダ情報全体、即ち、副次コンテンツに付加されるメタデータ全体を対象として検索を行ってもよい。後者の検索であれば、例えばコンテンツタイトルであるとか、作成者コメントなどのメタデータ項目において「特許太郎」の文字列が使用されているものがあったときには、これらの副次コンテンツも抽出されることになり、よりユーザの期待に応えられる検索結果を得られる可能性がある。
また、先にも述べたようにして、キーとして複数のメタデータを受け取った場合には、リコメンドコンテンツ抽出処理部２５は、これらのメタデータについて設定された条件式に従って副次コンテンツの検索を行うことになる。

そして、上記のリコメンドコンテンツとしての副次コンテンツの検索・抽出が完了したとされると、リコメンドコンテンツ抽出処理部２５は、同じステップＳ１００５によりリコメンドコンテンツリストを作成する。
ここで作成されるリコメンドコンテンツリストは、例えば図２２の場合と同様にして、抽出されたｎ個のリコメンドコンテンツ１〜ｎごとのメタデータ（例えばヘッダ情報）から成るものとされ、その構造としても、図２４と同様とされればよい。
また、確認のために述べておくと、この変形例にあっても、リコメンドコンテンツリストにおいて、ここに登録されている副次コンテンツの間での推薦順位は設定されてはいない。

リコメンドコンテンツ抽出処理部２５は、上記のようにして作成したリコメンドコンテンツリストをステップＳ１００６により、ユーザ端末装置４に対して返す。ユーザ端末装置４では、このリコメンドコンテンツリストをコミュニケーションツール１０２が受け取る。

この変形例においても、ステップＳ１００６によりコミュニケーションツール１０２が受け取ったリコメンドコンテンツリストにおいては、推薦順位は設定されていない。そこで、推薦順位を設定するために、コミュニケーションツール１０２は、ステップＳ１００７により、リコメンドコンテンツ関連処理部１２１に対して、リコメンドコンテンツリストのデータを渡すと共に、推薦順位設定要求を行う。

リコメンドコンテンツ関連処理部１２１においては、推薦順位設定要求に応答して、ステップＳ１００８により推薦順位を設定し、設定した推薦順位をリコメンドコンテンツリストに反映させる処理を実行する。

図２２のステップＳ８０８においては、リコメンドコンテンツごとの不足コンテンツ数に基づいて推薦順位を設定したが、上記ステップＳ１００８における推薦順位の設定は、次に説明するようにして、ユーザ端末装置４にて管理する保有コンテンツのメタデータの統計と、リコメンドコンテンツごとのメタデータとの関係に基づいたものとなる。

図２７のフローチャートは、ステップＳ１００８における推薦順位設定のための処理手順例を示している。
先ず、リコメンドコンテンツ関連処理部１２１は、ステップＳ１１０１において、リコメンドコンテンツリストに含まれるリコメンドコンテンツに付す番号に対応する変数ｎについて１を代入することで初期化を行う。
また、ステップＳ１１０２においては、リコメンドコンテンツｎに対応するメタデータ項目に付した番号に対応する変数ｑについても、１を代入して初期化を行う。図２４に示したように、リコメンドコンテンツリストは、リコメンドコンテンツごとのヘッダ情報から成るメタデータが配列されて成る。また、個々のリコメンドコンテンツごとのメタデータであるヘッダ情報は、図１３、図１４にて述べたように、所定の定義内容に対応する複数のメタデータ項目から成る。上記変数ｑは、これらのメタデータ項目に便宜上付した番号に対応する。

ステップＳ１１０３において、リコメンドコンテンツ関連処理部１２１は、リコメンドコンテンツｎごとに対応する重要度ポイントＰＴnとしての値を求めるための初期化処理として、この重要度ポイントとしての変数ＰＴnの値に０を代入する。

ステップＳ１１０４においては、リコメンドコンテンツ関連処理部１２１は、リコメンドコンテンツリストにおけるｎ番目のリコメンドコンテンツ（リコメンドコンテンツｎ）に対応するメタデータ（ヘッダ情報）のうちから、ｑ番目とされるメタデータ項目（メタデータ項目ｑ）を読み込んで、ここに記述されている内容(データ)を取得する。なお、メタデータ項目に記述される内容については、ここでは「キーワード（メタデータ記述内容）」ということにする。例えば、メタデータ項目としては、図１４に例示するようにして、「クリエータ」、「タイトル」「ジャンル」などを挙げることができるが、これらのメタデータ項目にそれぞれ記述される「特許太郎」「特許の気持ち」「エスニック」などの内容がキーワードとなるものである。

ここで、リコメンドコンテンツ関連処理部１２１は、例えば、図２８に示す構造のキーワード統計情報を作成・管理しているものとする。
このキーワード統計情報は、図２６に示すユーザ端末装置４（コンテンツ作成・共有アプリケーション１００）のユーザ（リコメンド対象ユーザ）が保有しているとされる保有コンテンツについてのメタデータについて、その記述内容とされるキーワードの出現数を統計化したものとされる。
つまり、キーワード統計情報のキーワードの欄には、保有コンテンツごとのメタデータ群（ヘッダ情報）から抽出した全てのキーワード（ここではkeyword 1, keyword 2,・・・keyword Xと示されている）が格納され、これらのキーワードごとに、ポイントとして、保有コンテンツ全体における出現数に基づいた値が対応付けられている。なお、このポイントについての求め方としては、出現数に基づく限り特に限定されるものではない。また、出現数をそのままポイントとしてもよい。
そして、このキーワード統計情報においてポイントが高いキーワードは、それだけ出現数が高いのであるから、そのキーワードに対するユーザの関心、興味などの嗜好が高いということがいえる。具体的に、例えばキーワード統計情報内において「特許太郎」のキーワードがあり、このキーワードに対応付けられているポイントが相応に高ければ、このユーザは、「特許太郎」に関連したコンテンツについて高い関心、興味を持っていることが推定できる。
このようにして、キーワード統計情報は、メタデータにおけるキーワードの観点から、コンテンツについてのユーザ個人の嗜好度を表した情報であるといえる。

そして、リコメンドコンテンツ関連処理部１２１は、ステップＳ１１０５おいて、キーワード統計情報から、上記ステップＳ１１０４により取得したデータ項目ｑのキーワードと一致するキーワードを検索する。そして、ここで一致するキーワードがあれば、このキーワードに対応付けられているポイントの値をポイントＭＰとして設定する。つまり、変数ＭＰに対してキーワードに対応付けられているポイントの値を代入する。なお、一致するキーワードがなければ、ポイントＭＰについては０を設定する。

続くステップＳ１１０６においてリコメンドコンテンツ関連処理部１２１は、リコメンドコンテンツｎの重要度ポイントＰＴnについて、これまでの重要度ポイントＰＴnに対して上記ステップＳ１１０５にて取得したポイントＭＰを加算して更新する。

リコメンドコンテンツ関連処理部１２１は、ステップＳ１１０７により、変数ｑについて最大値以上になったか否かについて判別する。ここで否定の判別結果が得られたのであれば、未だキーワードを取得していないメタデータ項目が残っていることになるので、ステップＳ１１０８により変数ｑをインクリメントしてステップＳ１１０４に戻る。
そして、リコメンドコンテンツ関連処理部１２１は、ステップＳ１１０４〜Ｓ１１０６までの手順を、メタデータ項目１〜ｑまでの全てに対応して行ったとされると、ステップＳ１１０７にて肯定の判別結果が得られることとなってステップＳ１１０９に進む。

リコメンドコンテンツ関連処理部１２１は、ステップＳ１１０９においては、変数ｎについて最大値に至ったか否かについて判別する。ここで否定の判別結果が得られたのであれば、未だ重要度ポイントを求めていないリコメンドコンテンツが残っていることになるので、ステップＳ１１１０により変数ｎをインクリメントしてからステップＳ１１０３に戻るようにされる。つまり、次のリコメンドコンテンツｎについての重要度ポイントＰＴnを求める処理に移行する。
そして、全てのリコメンドコンテンツ１〜ｎについて重要度ポイントＰＴnが求められると、ステップＳ１１０９において肯定の判別結果が得られることとなって、ステップＳ１１１１に進む。

これまでの説明によると、ステップＳ１１１０までの処理は、リコメンドコンテンツ１〜ｎごとに重要度ポイントＰＴ1〜ＰＴnを求める処理であるといえる。
また、リコメンドコンテンツごとの重要度ポイントは、そのリコメンドコンテンツのメタデータに含まれるキーワードについて、キーワード統計情報に登録されているものが多いほどその値が高くなるといえる。かつ、キーワード統計情報に登録されているキーワードのなかでも、ポイントの高いものと一致するほど、重要度ポイントは高くなる。
従って、リコメンドコンテンツについては、重要度ポイントが高いほどユーザの関心、興味も高く、嗜好に適ったものであるということがいえる。換言すると、重要度ポイントが高いリコメンドコンテンツほどユーザに推薦する価値が高い、即ち、より高い推薦順位を設定すべきであるということがいえる。

そこで、ステップＳ１１１１においては、これまでに得られたリコメンドコンテンツ１〜ｎごとに重要度ポイントＰＴ1〜ＰＴnに基づいて、リコメンドコンテンツ１〜ｎについての推薦順位を設定するようにされる。つまり、最も単純な設定の仕方としては、リコメンドコンテンツ１〜ｎに対して、重要度ポイントが高い順から低い順に１位からｎ位までの推薦順位を割り当てていく。

説明を図２６に戻す。
ステップＳ１００８において、上記図２７により推薦順位を設定したとされると、リコメンドコンテンツ関連処理部１２１は、同じステップＳ１００８において、この推薦順位の設定結果が反映されるようにしてリコメンドコンテンツリストを作成し直す。
次に、リコメンドコンテンツ関連処理部１２１は、上記のようにして推薦順位を反映させるようにして作成し直したリコメンドコンテンツリストを、ステップＳ１００９によりコミュニケーションツール１０２に返す。

コミュニケーションツール１０２は、ステップＳ１０１０により、上記ステップ１００９により受け渡されたリコメンドコンテンツリストを利用して、リコメンドコンテンツを提示する画像を所定の態様により表示出力させるための処理を実行する。

なお、メタデータ項目としては、図１３、図１４においてヘッダ情報のメタデータ項目として挙げたもの以外にも多様に考えられる。
例えば、楽曲としてのコンテンツであれば、曲調（例えば「楽しい」、「悲しい」などに対応する意味のデータがキーワードとなる）を示すものであるとか、コンテンツを鑑賞するのに適したシチュエーション（例えばドライブ、海などを示すデータがキーワードとなる）を示すものなどを挙げることができる。
また、例えば楽曲としてのコンテンツであれば、例えばＢＰＭ（Beat Per Minute）など検出して得られる楽曲の特徴量として捉えられるものをメタデータ項目とすることも考えられる。
また、このようなメタデータは、必ずしもコンテンツファイルのヘッダ情報に格納されるべきものではなく、例えば本実施形態の場合であれば、コンテンツ作成・共有アプリケーション１００により、保有コンテンツと対応付ける態様で、独自で管理するようにしてもよい。
また、上記のようにして、メタデータ項目についての定義が多様性を有してくるほど、全体としてみた場合に、そこに記述されるキーワードの意義については近似したものが出現してくると考えられる。例えば曲調を表し得るメタデータ項目において、そのキーワードとして「悲しい」「暗い」は似ているといえる。また、「明るい」「アップテンポ」も似ているといえる。
例えば、このような状況に対応しては、一定の基準に照らし合わせてキーワードの似たものについては、１つのキーワードに統一することとしたうえで、例えば図２６に示した変形例での副次コンテンツ推薦のための処理を実行する構成を考えることができる。この際には、ステップＳステップＳ１００３、Ｓ１００４などでやりとりするメタデータであるとか、キーワード統計情報などにおいて、意義の近似するキーワードの統一を図ることになる。これにより、近似する意義のキーワードの増加に対応して、的確なリコメンドコンテンツの抽出、及び推薦順位の設定が行えることになる。

なお、上記図２２、図２６により説明した副次コンテンツ推薦の構成では、いずれも、プレーヤ部１２０により再生中のコンテンツを起点として、これに関連した副次コンテンツを推薦する構成となっている。この構成では、例えば通常にユーザがコンテンツを再生して楽しんでいると、その再生中のコンテンツに関連して抽出されたリコメンドコンテンツが自動的に提示されるようなＧＵＩとなるので、ユーザにとっては手軽であり、また、単に再生したコンテンツを鑑賞するだけではなく、リコメンドコンテンツの情報が得られるという高い娯楽性、利便性も得られる。
また、副次コンテンツサーバ２とユーザ端末装置４に関すれば、例えばそれぞれが、再生中とされる１つのコンテンツのみに関連したリコメンドコンテンツの抽出、推薦順位設定の処理を行えばよい。従って、この点でも、副次コンテンツサーバ２とユーザ端末装置４の処理負担は軽減されて効率的なものとなっている。

しかし、例えばコンテンツ作成・共有アプリケーション１００のユーザにより、例えば副次コンテンツ推薦のための起点となるコンテンツを直接指定する操作が行えるようにすることも考えられる。そして、この操作により指定されたコンテンツのコンテンツＩＤ（図２２の場合）、若しくはメタデータ（図２６の場合）を副次コンテンツサーバ２に対してリコメンドコンテンツリスト要求とともに送信するように構成するものである。
このような構成では、ユーザは、リコメンドコンテンツの情報を得ようとしたときに、起点とするコンテンツを再生させる必要がない。状況によっては、リコメンドコンテンツの情報をルためにコンテンツを再生することがユーザにとって煩わしい場合もあると考えられるが、上記の構成は、このような場合に有用となる。

また、図２６〜図２８により説明した変形例は、一次コンテンツの推薦にも拡張して適用することができる。この一次コンテンツの推薦のためにコンテンツ作成・共有システムにおいて実行される処理を、図２９に示す。この図における処理の主体としては、図２６と同様に、ユーザ端末装置４におけるプレーヤ部１２０（コンテンツ管理・作成ツール１０１）、コミュニケーションツール１０２、リコメンドコンテンツ関連処理部１２１（コンテンツ管理・作成ツール１０１）、が示される。ただし、副次コンテンツサーバ２に代えて、一次コンテンツサーバ１が示される。

図２９において、ステップＳ１２０１〜Ｓ１２０３は、図２６のステップＳ１００１〜Ｓ１００３と同様となる。

次に、コミュニケーションツール１０２は、ステップＳ１２０３に応じてメタデータを受け取ると、ステップＳ１２０４により、一次コンテンツサーバ１に対して、上記ステップＳ１２０３により取得したメタデータとともにリコメンドコンテンツリスト要求を送信する。

上記ステップＳ１２０４によるリコメンドコンテンツリスト要求を受信した一次コンテンツサーバ１は、ステップＳ１２０５により、リコメンドコンテンツの抽出、及び抽出結果に基づくリコメンドコンテンツリストの作成を実行する。この場合におけるリコメンドコンテンツの抽出は、ステップＳ１２０４に応じてリコメンドコンテンツリスト要求とともに受信取得したメタデータをキー（抽出条件・検索条件）として、一次コンテンツデータベース１２ａからの一次コンテンツの検索を行うようにされる。
そして、上記のリコメンドコンテンツとしての副次コンテンツの検索・抽出が完了したとされると、一次コンテンツサーバ１は、リコメンドコンテンツリストを作成する。
このステップＳ１２０５により作成されるリコメンドコンテンツリストとしても、先の実施の形態に準じて、抽出されたリコメンドコンテンツとしての一次コンテンツごとのメタデータ（例えばヘッダ情報）から成るものとされればよい。
そして、一次コンテンツサーバ１は、上記のようにして作成したリコメンドコンテンツリストを、ステップＳ１２０６により、ユーザ端末装置４に対して返す。この場合も、ユーザ端末装置４では、このリコメンドコンテンツリストをコミュニケーションツール１０２が受け取ることとすればよい。

この場合においても、ステップＳ１２０６によりコミュニケーションツール１０２が受け取ったリコメンドコンテンツリストにおいては、推薦順位は設定されていない。そこで、コミュニケーションツール１０２は、ステップＳ１２０７により、リコメンドコンテンツ関連処理部１２１に対して、リコメンドコンテンツリストのデータを渡すと共に、推薦順位設定要求を行う。

リコメンドコンテンツ関連処理部１２１においては、推薦順位設定要求に応答して、ステップＳ１２０８により推薦順位を設定し、設定した推薦順位をリコメンドコンテンツリストに反映させる処理を実行する。
このステップＳ１２０８としての推薦順位設定の処理は、例えば図２７により説明したアルゴリズムに準ずればよい。そして、ステップＳ１２０９により、リコメンドコンテンツ関連処理部１２１は、推薦順位を反映させて作成し直したリコメンドコンテンツリストをコミュニケーションツール１０２に返す。
コミュニケーションツール１０２は、ステップＳ１２１０により、上記ステップ１１０９により受け渡されたリコメンドコンテンツリストを利用して、リコメンドコンテンツを提示する画像を所定の態様により表示出力させるための処理を実行する。

上記図２９による構成と、先の図２６〜図２８による構成とを併せた場合には、同じ手法により、一次コンテンツと副次コンテンツとを対象にしてリコメンドコンテンツを得ることが可能になる。

なお、一次コンテンツサーバ１、副次コンテンツサーバ２、コミュニケーションサーバ３、及びユーザ端末装置４の構成は一例であって、実際には適宜変更されて構わない。また、上記３つのサーバの少なくとも１つが、複数のサーバに分散されるような形態を採っても構わない。あるいは逆に、これらのサーバのうちの少なくとも２つが統合されるようにして構成されてもよいものである。

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

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

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

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

符号の説明

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

Claims (5)

1. 端末装置とサーバ装置とから成り、
   上記サーバ装置において、コンテンツの少なくとも１つを編集素材として二次利用する編集処理により作成されるもので、コンテンツ内容を再現するための情報として、原編集素材となる一次コンテンツの実コンテンツデータについての再生を指示する内容を含んで形成される再生制御情報を有する副次コンテンツを記憶管理する記憶管理手段と、
   上記端末装置において、推薦対象ユーザが保有しているものとみなされる一次コンテンツである保有一次コンテンツについての再生処理を実行する再生手段と、
   上記端末装置において、上記再生手段により再生処理が実行されている一次コンテンツを特定するコンテンツ識別子とともに推薦コンテンツ情報要求を上記サーバ装置に対して送信する推薦コンテンツ情報要求手段と、
   上記サーバ装置において、受信した上記コンテンツ識別子が示す一次コンテンツを上記原編集素材に含む副次コンテンツを、上記記憶管理手段により管理される副次コンテンツのうちから抽出する副次コンテンツ抽出手段と、
   上記サーバ装置において、上記副次コンテンツ抽出手段により抽出した副次コンテンツを推薦コンテンツとし、これら推薦コンテンツごとに対応するメタデータにより形成される推薦コンテンツ情報を上記端末装置に対して送信する推薦コンテンツ情報送信手段と、
   上記端末装置において、受信した上記推薦コンテンツ情報により示される推薦コンテンツについての推薦順位を設定するもので、推薦コンテンツごとについての、上記原編集素材における上記保有一次コンテンツの利用状況に基づいて上記推薦順位を設定する推薦順位設定手段と、
   上記端末装置において、上記推薦順位が反映されるようにして、上記推薦コンテンツ情報により示される推薦コンテンツを提示する提示手段と、
   を備える情報処理システム。
2. 端末装置とサーバ装置とから成り、
   上記サーバ装置において、コンテンツの少なくとも１つを編集素材として二次利用する編集処理により作成された副次コンテンツを記憶管理する記憶管理手段と、
   上記端末装置において、コンテンツについての再生処理を実行する再生手段と、
   上記端末装置において、上記再生手段により再生処理が実行されているコンテンツに付加されているメタデータとともに推薦コンテンツ情報要求を上記サーバ装置に対して送信する推薦コンテンツ情報要求手段と、
   上記サーバ装置において、受信した上記メタデータを抽出条件として、上記記憶管理手段により管理される副次コンテンツのうちから１以上の副次コンテンツを抽出する副次コンテンツ抽出手段と、
   上記サーバ装置において、上記副次コンテンツ抽出手段により抽出した副次コンテンツを推薦コンテンツとし、これら推薦コンテンツごとのメタデータにより形成される推薦コンテンツ情報を上記端末装置に対して送信する推薦コンテンツ情報送信手段と、
   上記端末装置において、受信した上記推薦コンテンツ情報により示される推薦コンテンツについての推薦順位を設定するもので、上記推薦コンテンツ情報に含まれる推薦コンテンツごとのメタデータ記述内容についての、推薦対象ユーザが保有しているものとみなされる保有コンテンツ全体のメタデータ記述内容における出現数に基づいて、上記推薦順位を設定する推薦順位設定手段と、
   上記端末装置において、上記推薦順位が反映されるようにして、上記推薦コンテンツ情報により示される推薦コンテンツを提示する提示手段と、
   を備える情報処理システム。
3. 端末装置とサーバ装置とから成る情報処理システムにおける情報処理方法であり、
   上記サーバ装置において、コンテンツの少なくとも１つを編集素材として二次利用する編集処理により作成されるもので、コンテンツ内容を再現するための情報として、原編集素材となる一次コンテンツの実コンテンツデータについての再生を指示する内容を含んで形成される再生制御情報を有する副次コンテンツを記憶管理する記憶管理手順と、
   上記端末装置において、推薦対象ユーザが保有しているものとみなされる一次コンテンツである保有一次コンテンツについての再生処理を実行する再生手順と、
   上記端末装置において、上記再生手順により再生処理が実行されている一次コンテンツを特定するコンテンツ識別子とともに推薦コンテンツ情報要求を上記サーバ装置に対して送信する推薦コンテンツ情報要求手順と、
   上記サーバ装置において、受信した上記コンテンツ識別子が示す一次コンテンツを上記原編集素材に含む副次コンテンツを、上記記憶管理手順により管理される副次コンテンツのうちから抽出する副次コンテンツ抽出手順と、
   上記サーバ装置において、上記副次コンテンツ抽出手順により抽出した副次コンテンツを推薦コンテンツとし、これら推薦コンテンツごとに対応するメタデータにより形成される推薦コンテンツ情報を上記端末装置に対して送信する推薦コンテンツ情報送信手順と、
   上記端末装置において、受信した上記推薦コンテンツ情報により示される推薦コンテンツについての推薦順位を設定するもので、推薦コンテンツごとについての、上記原編集素材における上記保有一次コンテンツの利用状況に基づいて上記推薦順位を設定する推薦順位設定手順と、
   上記端末装置において、上記推薦順位が反映されるようにして、上記推薦コンテンツ情報により示される推薦コンテンツを提示する提示手順と、
   を実行する情報処理方法。
4. 端末装置とサーバ装置とから成る情報処理システムにおける情報処理方法であり、
   上記サーバ装置において、コンテンツの少なくとも１つを編集素材として二次利用する編集処理により作成された副次コンテンツを記憶管理する記憶管理手順と、
   上記端末装置において、コンテンツについての再生処理を実行する再生手順と、
   上記端末装置において、上記再生手順により再生処理が実行されているコンテンツに付加されているメタデータとともに推薦コンテンツ情報要求を上記サーバ装置に対して送信する推薦コンテンツ情報要求手順と、
   上記サーバ装置において、受信した上記メタデータを抽出条件として、上記記憶管理手順により管理される副次コンテンツのうちから１以上の副次コンテンツを抽出する副次コンテンツ抽出手順と、
   上記サーバ装置において、上記副次コンテンツ抽出手順により抽出した副次コンテンツを推薦コンテンツとし、これら推薦コンテンツごとのメタデータにより形成される推薦コンテンツ情報を上記端末装置に対して送信する推薦コンテンツ情報送信手順と、
   上記端末装置において、受信した上記推薦コンテンツ情報により示される推薦コンテンツについての推薦順位を設定するもので、上記推薦コンテンツ情報に含まれる推薦コンテンツごとのメタデータ記述内容についての、推薦対象ユーザが保有しているものとみなされる保有コンテンツ全体のメタデータ記述内容における出現数に基づいて、上記推薦順位を設定する推薦順位設定手順と、
   上記端末装置において、上記推薦順位が反映されるようにして、上記推薦コンテンツ情報により示される推薦コンテンツを提示する提示手順と、
   を実行する情報処理方法。
5. 端末装置とサーバ装置とから成り、
   上記サーバ装置において、コンテンツを記憶管理する記憶管理手段と、
   上記端末装置において、コンテンツについての再生処理を実行する再生手段と、
   上記端末装置において、上記再生手段により再生処理が実行されているコンテンツに付加されているメタデータとともに推薦コンテンツ情報要求を上記サーバ装置に対して送信する推薦コンテンツ情報要求手段と、
   上記サーバ装置において、受信した上記メタデータを抽出条件として、上記記憶管理手段により管理されるコンテンツのうちから１以上のコンテンツを抽出するコンテンツ抽出手段と、
   上記サーバ装置において、上記コンテンツ抽出手段により抽出したコンテンツを推薦コンテンツとし、これら推薦コンテンツごとのメタデータにより形成される推薦コンテンツ情報を上記端末装置に対して送信する推薦コンテンツ情報送信手段と、
   上記端末装置において、受信した上記推薦コンテンツ情報により示される推薦コンテンツについての推薦順位を設定するもので、上記推薦コンテンツ情報に含まれる推薦コンテンツごとのメタデータ記述内容についての、推薦対象ユーザが保有しているものとみなされる保有コンテンツ全体のメタデータ記述内容における出現数に基づいて、上記推薦順位を設定する推薦順位設定手段と、
   上記端末装置において、上記推薦順位が反映されるようにして、上記推薦コンテンツ情報により示される推薦コンテンツを提示する提示手段と、
   を備える情報処理システム。

Images