(57)【要約】【課題】複数のプラットフォーム要素のサーバを利用してコンテンツを流通させるシステムにおいて，各サービス事業者に必要な項目の作成，実行を共通の性質を持つグループに分け，まとめて取り扱うことが簡単に実現でき，拡張性のあるコンテンツ流通システム基盤を実現できるようにする。【解決手段】コンテンツ流通システム２のアプリケーション（ＡＰ）サーバ２１をＡＰシナリオ部３０とＡＰ共通機能部３１とに分け，さらにＡＰ共通機能部３１をサービス系レイヤ３１０と機能系レイヤ３１１に分けた構成とし，これらのサービス系レイヤ３１０と機能系レイヤ３１１のもとで動作するコマンドカプセル実行エンジンを設ける。また，コマンドカブセル実行エンジンは，事業者毎に用意したスキーマによりデータ操作を行い，パターンを組み合わせることでデータ項目操作を自由に実行可能にする。【選択図】　　図２
2004110291.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツ流通のために用意されたプラットフォーム要素のサーバを利用してコンテンツを流通させる処理を行うアプリケーションサーバと，アプリケーションがコンテンツの流通のために用いる共通のデータベースを格納する共通データベースサーバとを備えたコンテンツ流通装置において，
前記アプリケーションサーバは，
実現するコンテンツ流通サービスモデルのアプリケーションに対応したアプリケーションシナリオ部と，
前記アプリケーションシナリオ部に対して共通機能を提供するアプリケーションによって変化しない部分からなるアプリケーション共通機能部とを備え，
前記アプリケーション共通機能部は，
サービス事業者毎に用意された項目の関連付けを行ったスキーマで操作されて，関連するデータ操作，ロジックおよびパラメータとなる属性をカプセル化したコマンドカプセルで動作する実行エンジンを備える
ことを特徴とするコンテンツ流通装置。
【請求項２】
前記アプリケーション共通機能部は，
前記プラットフォーム要素の操作インタフェースを機能ごとに統合したインタフェースを提供する機能系レイヤと，
前記アプリケーションシナリオ部に対し，コンテンツ流通サービスモデルごとに前記機能系レイヤのインタフェースをサービスの観点から統合したインタフェースを提供するサービス系レイヤとに分かれて構成される
ことを特徴とする請求項１記載のコンテンツ流通装置。
【請求項３】
前記共通データベースサーバは，汎用のデータベースの操作項目部とサービス事業者ごとの操作項目部とを分離して有する
ことを特徴とする請求項１または請求項２記載のコンテンツ流通装置。
【請求項４】
前記実行エンジンは，前記機能系レイヤからコマンドカプセルを渡されて実行指示を受ける実行仲介部と，前記実行仲介部が受けたコマンドカプセルに含まれるコマンドに従って前記共通データベースサーバへのアクセスを実行する実行部と，サービス事業者毎に項目を関連付けた構造を有し，木構造を実現するコンポジット・パターンを利用してさらに項目の関連付けを行うデータベースアクセス設定部とを有し，
前記実行部は，前記データベースアクセス設定部によって設定されたサービス事業者毎の項目の関連付けに従って前記共通データベースサーバへのアクセスを行う
ことを特徴とする請求項１，請求項２または請求項３記載のコンテンツ流通装置。
【請求項５】
コンテンツ流通のために用意されたプラットフォーム要素のサーバを利用してコンテンツを流通させるアプリケーションサーバと，
アプリケーションがコンテンツの流通のために用いる共通のデータベースを格納する共通データベースサーバとを備え，
前記アプリケーションサーバは，実現するコンテンツ流通サービスモデルのアプリケーションに対応したアプリケーションシナリオ部と，アプリケーションによって変化しない部分からなるアプリケーション共通機能部の２階層を含み，
前記アプリケーション共通機能部は，サービス事業者毎に用意された項目の関連付けを行ったスキーマで操作されて，関連するデータ操作，ロジックおよびパラメータとなる属性をカプセル化したコマンドカプセルで動作する実行エンジンを備える，
コンテンツ流通装置を用いてコンテンツを流通させるコンテンツ流通処理方法であって，
前記アプリケーションシナリオ部から前記アプリケーション共通機能部へ，当該アプリケーション共通機能部が提供するインタフェースを用いて，コンテンツ流通のための処理を依頼するステップと，
前記アプリケーション共通機能部において，前記アプリケーションシナリオ部からの処理依頼に対し，前記実行エンジンに依頼された処理に係るコマンドカプセルを引き渡すことにより前記共通データベースサーバへのアクセスを実行するステップとを有する
ことを特徴とするコンテンツ流通処理方法。
【請求項６】
請求項１，請求項２，請求項３または請求項４記載のコンテンツ流通装置を，コンピュータによって実現するためのコンテンツ流通システムプログラム。
【請求項７】
請求項１，請求項２，請求項３または請求項４記載のコンテンツ流通装置を，コンピュータによって実現するためのコンテンツ流通システムプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は，コンテンツ流通システムのアプリケーションに関するもので，画像や映像等にＩＤを付して，著作権を保護しながら，コンテンツを流通させるシステムの基盤技術に関する。
【０００２】
特に，本発明は，コンテンツ流通システムにおける映像コンテンツ配信サービス用プラットフォーム連携・運用ソフトウェアの共通コンポーネントに関するものである。共通コンポーネントは，映像コンテンツ配信サービス構築を対象として適用する汎用コンポーネント群であり，映像コンテンツ配信サービスＡＳＰ事業へ導入し，そのＡＳＰ上の個別サービス構築を，第１にフレームワークの提供と，第２に汎用コンポーネント群の提供という点からコンテンツ流通システムの構築を支援するものである。
【０００３】
【従来の技術】
従来のコンテンツ流通システムでは，サービス内容や提供対象によって，個々のシステムが作られている。つまり，従来の技術では，システムが共通的な部分と利用シーンに応じて変える部分に別れておらず，共通的なソフトウェアの部品であっても，サービスに依存する部分と，プラットフォーム（以下，ＰＦとも記す）要素に依存する部分が一体化されているシステム構成が一般的であった。また，様々なコンテンツ流通サービスに適したプログラムレベルでのインタフェースの切り出しが行われていない。ここで言っているインタフェースとは，ハード的，電気的なインタフェースではなく，ソフトウェア上の命令文や伝達文等のやり取りを行う特定のまとまりを切り出したものを指す。
【０００４】
従来技術の代表的なものとして，オペレーティング・システム（ＯＳ）やハードウェア等の異なるプラットフォーム上で開発されたアプリケーションプログラムを移植あるいは作り変えることなくシステムの構築をしようとする情報処理装置がある（例えば，特許文献１参照）。特許文献１に記載の従来技術は，情報処理装置内に，オープンビジネス共通基盤装置を有し，オープンビジネス基盤装置は，ＡＰＩ整合制御装置が複数のＡＰＩ制御装置に接続された構成になっている。多様なインタフェースを内蔵することで，異なるプラットフォーム上で記述されたＡＰを統合しようとするものである。
【０００５】
なお，本発明の実施の形態においてコマンドの実行機構の実現に用いているデザイン・パターンに関する技術を記載している文献として，下記の非特許文献１がある。
【特許文献１】
特開平１０−４００８０号公報（第１−２頁）
【非特許文献１】
Ｅｒｉｃｈ　Ｇａｍｍａ，　Ｒｉｃｈａｒｄ　Ｈｅｌｍ，　Ｒａｌｐｈ　Ｊｏｈｎｓｏｎ，　Ｊｏｈｎ　Ｖｌｉｓｓｉｄｅｓ著，　”Ｄｅｓｉｇｎ　Ｐａｔｔｅｒｎｓ”　，　Ａｄｄｉｓｏｎ　Ｗｅｓｌｅｙ　Ｐｕｂｌｉｓｈｉｎｇ　Ｃｏｍｐａｎｙ　出版；　１ｓｔ版　（１９９５／０１／１５）
【０００６】
【発明が解決しようとする課題】
ここで，上記従来技術において定義しているインタフェースは，選択されたＯＳやハードウェア等のプラットフォームと複数のアプリケーションプログラムを透過的につなぐために，種類を豊富に持つことでＡＰ統合の問題を解決しており，具体的なインタフェースとしてどのようなものが良いのか，特に，コンテンツ流通事業者がサービスするアプリケーションを想定して，検討したものではない。また，プラットフォームサーバに搭載するソフトウェアをレイヤに分割してそれぞれのインタフェースを決めて汎用性を高めるというような記載は，上記特許文献１にはない。このため，このような従来の技術では，ネットワーク管理者，最終購入者であるユーザ（消費者）やサービス事業者の３者の立場で拡張性の期待できるコンテンツ流通基盤が実現できない。
【０００７】
すなわち，従来の技術では以下のような問題点があった。
（１）コンテンツ流通における様々なビジネスモデルに応じて，利用しているシステムを，その都度，システムを全面的に作り替えなくてはならない。
（２）システム開発においてプラットフォーム（ＰＦ）要素のインタフェースを直接利用する場合，利用するＰＦ要素の仕組み，使い方を熟知しないと，システム構築できない。
（３）複数サービス事業者を同一システムで動作させる場合，サービス事業者によって，ＤＢの項目の違いを生じたとき，従来では，様々なサービスモデルへの対応性が少なく，ＤＢアクセスシステムの処理を変更するか，ＤＢアクセスシステムを利用するアプリケーションを変更する必要があるが，動作中のシステムへの項目が違うサービス事業者の追加などはできない場合がある。
【０００８】
本発明は上記の点に鑑みてなされたもので，
Ａ）映像コンテンツ配信サービスのための関連プラットフォームを統合する操作を実現すること，
Ｂ）映像コンテンツ配信システム開発での拡張性を確保すること，
Ｃ）映像コンテンツ配信システム開発で再利用可能なコンポーネント（ソフトウェアの構成上のひとかたまり）を整備すること，
を満たしたコンテンツ流通システム基盤を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明は，上記課題を解決するため，以下を特徴とする。
【００１０】
市販ソフトウェア及びパッケージなどのプラットフォーム（ＰＦ）要素を利用して動作するコンテンツ流通におけるコンテンツ流通システムにおいて，様々なコンテンツ流通のモデルに対応したアプリケーション（ＡＰ）シナリオの部分（ＡＰシナリオ部）とアプリケーションによって変化しない部分（ＡＰ共通機能部）の２階層に分け，さらに，拡張性を確保するためにＡＰ共通機能部を，サービスモデルに依存しやすい部分としてサービス系レイヤ（ＡＰシナリオ部とのインタフェースを有する）とＰＦ要素のコマンドに依存しやすい部分として機能系レイヤ（ＰＦ要素とのインタフェースを有する）に分けて構成した。
【００１１】
すなわち，ＡＰシナリオ部とＡＰ共通機能部にソフトウェアアーキテクチャでレイヤを分けて，それぞれのインタフェース（ＩＦ）を設け，アプリケーション部分とプラットフォーム部分とを連携および独立させるための仕組みとして実行エンジンを構築した。
【００１２】
この実行エンジンは，ＡＰ共通機能部における機能系レイヤとサーバ系レイヤの仲介と各サービス事業者毎に設定された操作項目を，クラスの承継や組み合わせによって効率的に設定するデータベース設定部と，この設定部と連携して命令実行を各データベースに伝える実行仲介部を有する構造とした。
【００１３】
本発明では，何らかの情報テーブルを関連付けることをスキーマといっており，データベース設定部で，クラスの継承等を行わせるために，共通で管理するスキーマと各サービス事業者毎に特化したスキーマを用意した。クラスとは，内部にオブジェクトを構成するのに必要となる要素の情報をいう。このようなクラスを組み合わせて，複雑なクラスを作る場合にクラスの継承を行うという。
【００１４】
このようなＡＰ共通機能部の階層（レイヤ）において，お互いのコンポーネントを操作するインタフェースは，下位の連携するインタフェースを隠蔽する構成（上位のＩＦに下位のＩＦが含まれる構成）となるように，例えば関連する操作，パラメータなどを含んだコマンドカプセルを実装した。このコマンドカプセルを実行させるための実行エンジンをアプリケーションサーバのアプリケーション共通部分のもとで起動させることで，各サービス事業者に必要な項目の作成，実行を共通の性質を持つグループに分けること，まとめて取り扱うことが簡単に実現でき，拡張性のあるコンテンツ流通システム基盤が実現できる。
【００１５】
【発明の実施の形態】
図１は，基盤となるデータセンタを含めたコンテンツ流通ネットワークシステムの全体概念構成図である。
【００１６】
図１において，１は本発明に係るコンテンツ流通システムに各ＰＦ要素を加えた広義のコンテンツ流通システム，３はデータセンタ，４はインターネット，５はインターネットへの接続サービスを行うプロバイダ（ＩＳＰ），６はエンドユーザ（端末），７は専用線，８はサービス事業者（端末），９は決済代行業者（端末），１０はＰＦ事業者（端末）である。
【００１７】
図２は，図１に示すコンテンツ流通システム１の詳細構成図である。図２において，２は本発明に係る狭義のコンテンツ流通システム，２１はＡＰサーバ，２２はＡＰ共通ＤＢサーバ，２３はＡＰ共通ＤＢ，１１は各ＰＦ要素，３０はＡＰシナリオ部，３１はＡＰ共通機能部，１１０は各ＰＦ要素のサーバである。また，３１０はサービス系レイヤ，３１１は機能系レイヤ，３１２はコマンドカプセル実行エンジン，２２０は共通サーバ系レイヤである。
【００１８】
本実施の形態では，ＡＰシナリオ部３０，ＡＰ共通機能部３１をＪａｖａ（登録商標）開発環境を用いて実装した。ＡＰシナリオ部３０は，実現するコンテンツ流通サービスモデルのアプリケーションごとに用意されるプログラム部分である。ＡＰ共通機能部３１は，種々のアプリケーションに対して，あらかじめ共通に用意される共通コンポーネントである。また，ＡＰ共通ＤＢサーバ２２における共通サーバ系レイヤ２２０も，種々のアプリケーションに対して，あらかじめ共通に用意される共通コンポーネントである。共通サーバ系レイヤ２２０は，各種アプリケーションに対してコンテンツ流通システム２で用いる各種テーブルが格納されたＡＰ共通ＤＢ２３に対してのアクセスインタフェースを提供する。
【００１９】
ＡＰ共通機能部３１は，ＡＰシナリオ部３０とのインタフェースを有するサービス系レイヤ３１０と，各ＰＦ要素のサーバ１１０およびＡＰ共通ＤＢサーバ２２とのインタフェースを有する機能系レイヤ３１１とに分かれて構成される。
【００２０】
サービス系レイヤ３１０は，ＡＰシナリオ部３０に対し，コンテンツ流通サービスモデルごとに機能系レイヤ３１１のインタフェースをサービスの観点から統合したインタフェースを提供し，機能系レイヤ３１１は，関連する各ＰＦ要素のサーバ１１０とＡＰ共通ＤＢサーバ２２の操作インタフェースを機能ごとに統合した関連インタフェースを提供する。
【００２１】
本発明によるシステムを実現するにあたり，サービス事業者によりコンテンツ流通サービスモデルが異なり，アプリケーションが異なっても，各アプリケーションが共通に必要とする機能を，コンテンツ流通ビジネスの代表例として，映像コンテンツ配信サービスを行う場合を例にして抽出した。
【００２２】
図３は，コンテンツ流通のシナリオモデルの例を示す。ＡＰ共通機能部３１として必要なＡＰ共通機能の抽出をするために，図３に示すコンテンツ流通のシナリオモデルを設定し，どのような情報管理と情報の使用が想定されるかを検討した。
【００２３】
図３に示されるように，ユーザ属性管理は，プラットフォーム管理者，最終購入者であるユーザ，サービス事業者がそれぞれの立場でユーザ属性の登録，検索，更新，削除，を行う場合に使われるものである。商品属性管理は，サービス事業者が商品に関する属性を操作するものである。
【００２４】
また，コンテンツ属性管理は，プラットフォーム事業者，サービス事業者がコンテンツの登録，検索，更新，削除を行うものである。コンテンツファイル管理は，プラットフォーム事業者，サービス事業者がコンテンツファイルの登録，検索，更新，削除を行うものである。商品販売属性管理は，プラットフォーム事業者，サービス事業者，一部ユーザが行うものである。また，コンテンツ配信管理は，ユーザ，サービス事業者が行うものである。
【００２５】
このようなシナリオモデルに基づいて，個別のアプリケーションが異なってもＡＰサーバ２１上で動作するように，ＡＰ共通機能を抽出した。ＡＰ共通機能の抽出にあたっては，以下の要求条件をもとに決定した。
（１）映像コンテンツ配信サービス構築のためのフレームワークを提供することによる複数の個別サービスのコンポーネント開発／導入ポリシーを統一したい（開発設計支援のため）。
（２）フレームワークを遵守することにより個別サービス群の管理を容易にしたい（開発設計支援，ＰＦ管理者のため）。
（３）また，汎用コンポーネント群は映像コンテンツ配信システムでの主要な操作インタフェースで，関連プラットフォームの連携を隠蔽して提供したい（開発設計支援のため）。
（４）共通コンポーネントを適用して構築する配信サービスの汎用コンポーネント群の適用範囲内において，独自ビジネスモデルの実装，独自ＧＵＩの実装および独自シナリオの実装に集中したい（開発設計支援のため）。
（５）また，汎用コンポーネント群の適用範囲外である場合においても，フレームワークにしたがって独自コンポーネントを開発する手段がほしい（開発設計支援のため）。
【００２６】
このような要求条件を満たす共通機能部分（共通コンポーネント）を多層レイヤ構造とすることとした。すなわち，ＡＰサーバ２１のＡＰ共通機能部３１に，ＡＰシナリオ部３０とのインタフェースを有するサービス系レイヤ３１０と各ＰＦ要素１１とのインタフェースを有する機能系レイヤ３１１を実装し，ＡＰ共通ＤＢサーバ２２に共通サーバ系レイヤ２２０を実装している。
【００２７】
各レイヤの概要を図４に示す。これにより，サービス事業者が異なり，サービス系レイヤ３１０が異なっても，共通の機能系レイヤ３１１を使用できる。
【００２８】
図１のシステムによってコンテンツ流通ビジネスを行うためには，各種のプラットフォーム要素が必要である。プラットフォームを含めた共通コンポーネントをもつシステム全体の構成図を，図５に示す。図５において，１２は課金決済ＰＦ，１３は著作権管理ＰＦ，１４はライセンスサーバ，１５はＶＯＤ配信サーバ，１６はダウンロードサーバ，１７はアーカイブサーバ，３００は個別ＡＰである。
【００２９】
課金決済ＰＦ１２は，提供サービスに対する課金および決済処理を行う統合的なプラットフォームである。著作権管理ＰＦ１３は，提供コンテンツに対する著作権の管理を行う統合的なプラットフォームである。ライセンスサーバ１４は，コンテンツのライセンス管理機能を持つアプリケーションサーバである。ＶＯＤ配信サーバ１５は，ストリーミングコンテンツが配置され，視聴時に配信するサーバである。ダウンロードサーバ１６は，ダウンロードして視聴するコンテンツが配置されるサーバである。アーカイブサーバ１７は，コンテンツ原本を保存したり，一時的に生じるファイルを格納したりするサーバである。コマンドカプセル実行エンジン３１２については後述する。
【００３０】
図６は，図５に示したＡＰサーバに搭載したコンポーネントの関連を示す構成図である。図６において，２４はブラウザ，１００はＨＴＴＰサーバ，１０１はＰＦ連携システム，１０２乃至１０７は各ＰＦのプラットフォーム・インタフェース（ＰＦＩＦ），１０８はコマンドカプセル，１３０はサービス系レイヤインタフェース，１３１は機能系レイヤインタフェース，１３２は個別ＰＦのアダプタインタフェース，３０１はＡＰシナリオ部３０におけるサービス画面（ＪＳＰ），３０２はＡＰシナリオ部３０におけるＡＰ制御コンポーネント（サーブレット）である。
【００３１】
アプリケーションに共通のコンポーネントとして，サービス系レイヤ３１０，機能系レイヤ３１１，コマンドカプセル実行エンジン３１２，共通サーバ系レイヤ２２０が用意されている。サービス画面３０１，ＡＰ制御コンポーネント３０２は，ＡＰシナリオ部３０に存在する。
【００３２】
ＰＦ連携システム１０１は，個別プラットフォームが提供するサービスを組み合わせたプロダクトを迅速に提供することを目的とした連携機構である。本システムでは，ユーザ管理および認証処理をＰＦ連携システム１０１を用いて実現する。すなわち，課金決済ＰＦ１２および著作権管理ＰＦ１３に対して共通のユーザ管理，ユーザ認証を行うために設けられており，これは省略することも可能である。
【００３３】
本実施の形態では，前述のようにＡＰシナリオ部３０，ＡＰ共通機能部３１をＪａｖａ（登録商標）開発環境を用いて実装している。Ｊａｖａのクラスライブラリは，周知のように，階層化されたパッケージ群によって構成される。パッケージは，クラスとインタフェースの集まりであり，複数のクラスをグループ化し，名前空間の分離によってクラス名の衝突を回避している。クラスは，「もの」の特徴となる属性と動作を定義したものであり，インタフェースは，備えるべきメソッドを定義しておくものであり，中身を持たないクラスのようなものである。
【００３４】
ＡＰ共通機能部３１におけるサービス系レイヤ３１０の共通コンポーネントおよび機能系レイヤ３１１の共通コンポーネントは，図７に示すパッケージで構成される。機能系レイヤ３１１の共通コンポーネントのインタフェースを統合することで，よリアプリケーションサービス向けの操作インタフェースを提供できる。
【００３５】
コンテンツ管理サービスパッケージＰ１１は，図３のコンテンツ属性管理，コンテンツファイル管理を行うときに用いる。商品／コース菅理サービスパッケージＰ１２は，図３の商品属性管理，商品販売属性管理を行うときに用いる。商品販売／配信サービスパッケージＰ１３は，図３の商品属性管理，商品販売属性管理，コンテンツ配信管理を行うときに用いる。商品消費サービスパッケージＰ１４は，図３のユーザ属性管理，商品販売属性管理，コンテンツ配信管理を行うときに用いる。ユーザ管理サービスパッケージＰ１５は，図３のユーザ属性管理を行うときに用いる。
【００３６】
図７に示すサービス系レイヤインタフェース１３０として，コンテンツ管理サービスパッケージＰ１１は，コンテンツ権利属性登録受付／登録完了通知インタフェース，コンテンツ検索／一覧／詳細参照／変更／削除インタフェース，コンテンツ削除可否問合せインタフェース，コンテンツ登録手続き状況検索インタフェースを持つ。
【００３７】
商品／コース管理サービスパッケージＰ１２は，商品／コース属性登録／登録完了通知インタフェース，商品／コース検索／一覧／詳細参照／変更／削除インタフェース，商品／コース削除可否問合せインタフェース，商品／コースに関連付けられたコンテンツ一覧／詳細インタフェースを持つ。
【００３８】
商品販売／配信サービスパッケージＰ１３は，コンテンツ配信手続き状況検索インタフェース，配信サーバデプロイメントサイズ管理インタフェース，販売履歴登録インタフェース，販売履歴検索／一覧／詳細参照インタフェース，ライセンス発行依頼インタフェース，商品／コース照会インタフェース，商品／コース検索／一覧／詳細参照インタフェースを持つ。
【００３９】
商品消費サービスパッケージＰ１４は，商品／コース購入済み問合せインタフェース，商品／コース購入インタフェース，コンテンツ視聴（オンデマンド／ダウンロード）インタフェース，利用明細データ格納／検索インタフェースを持つ。
【００４０】
ユーザ管理サービスパッケージＰ１５は，ユーザ属性登録／登録完了通知インタフェース，ユーザ属性検索／一覧／詳細参照／変更／削除インタフェース，ユーザ属性重複チェックインタフェース，ユーザログインインタフェース，ユーザパスワード変更インタフェース，ユーザパスワード問合せインタフェース，ユーザアカウントの一時停止／再開インタフェースを持つ。
【００４１】
機能系レイヤ３１１の各パッケージＰ２１〜Ｐ２６もＡＰサーバ２１上に配置するパッケージ群である。機能を単位とし，関連するプラットフォーム群およびローカルデータベースへの操作を一元化する。これも，前述の図３に示したシナリオモデルに対応するものである。
【００４２】
ユーザ管理機能パッケージＰ２１は，図３のユーザ属性管理を行うときに用いる。コンテンツ管理機能パッケージＰ２２は，図３のコンテンツ属性管理，コンテンツファイル管理を行うときに用いる。商品管理機能パッケージＰ２３は，図３の商品属性管理を行うときに用いる。販売管理機能パッケージＰ２４は，図３の商品販売属性管理を行うときに用いる。課金決済機能パッケージＰ２５は，図３の商品販売属性管理を行うときに用いる。商品配信機能パッケージＰ２６は，図３のコンテンツ配信管理を行うときに用いる。
【００４３】
各パッケージＰ２１〜Ｐ２６は，機能系レイヤインタフェース１３１として，次のようなインタフェースを持つ。ユーザ管理機能パッケージＰ２１は，利用者情報操作機能の汎用インタフェースである利用者属性操作インタフェース，利用者の認証を行い，認証オブジェクトを返すユーザ認証インタフェースを持つ。
【００４４】
コンテンツ管理機能パッケージＰ２２は，権利属性操作機能の汎用インタフェースである権利属性操作インタフェース，コンテンツファイル操作機能の汎用インタフェースであるマスタコンテンツ操作インタフェースを持つ。
【００４５】
商品管理機能パッケージＰ２３は，商品属性操作機能の汎用インタフェースである商品属性操作インタフェースを持つ。
【００４６】
販売管理機能パッケージＰ２４は，取引履歴属性操作機能の汎用インタフェースである取引履歴属性操作インタフェースを持つ。
【００４７】
課金決済機能パッケージＰ２５は，課金決済属性操作機能の汎用インタフェースである課金決済属性操作インタフェースを持つ。
【００４８】
商品配信機能パッケージＰ２６は，配信コンテンツ操作機能の汎用インタフェースである配信コンテンツ操作インタフェース，ライセンス操作機能の汎用インタフェースであるライセンス操作インタフェースを持つ。
【００４９】
以上のようなことから，機能系レイヤインタフェース１３１は，
・利用者属性操作インタフェース
・ユーザ認証インタフェース
・権利属性操作インタフェース
・マスタコンテンツ操作インタフェース
・商品属性操作インタフェース
・取引履歴属性操作インタフェース
・課金決済属性操作インタフェース
・配信コンテンツ操作インタフェース
・ライセンス操作インタフェース
である。
【００５０】
本実施の形態では，アプリケーションに対する共通コンポーネントとして，ＡＰ共通ＤＢサーバ２２内にも共通サーバ系レイヤ２２０を有しており，図示省略するが，共通サーバ系レイヤ２２０は，次のようなパッケージを備えている。
・ＲＤＢＭＳアクセスパッケージ
・トランザクション制御パッケージ
・共通コンポーネント管理パッケージ
・共通サーバアクセスラッパ
・共通サーバアクセスアダプタ
ＲＤＢＭＳアクセスパッケージは，Ｏｒａｃｌｅ（登録商標）　ＤＢＭＳ／Ｓｔｏｒｅｄ　Ｐｒｏｃｅｄｕｒｅ／Ｓｔｏｒｅｄ　Ｆｕｎｃｔｉｏｎへのブリッジである。また，トランザクション制御パッケージは，複数の“共通コンポーネント”からのリクエストを矛盾なく制御する。共通コンポーネント管理パッケージは，“共通コンポーネント”のマルチサーバ・デプロイメント，マルチサービス対応のための追加／削除などを矛盾なく動作するアーキテクチャを提供する。共通サーバアクセスラッパは，共通サーバへのリクエストの受け口を提供する。共通サーバアクセスアダプタは，ＡＰサーバ２１へデプロイする共通サーバアクセスラッパへのインタフェースである。ＡＰ共通ＤＢサーバ２２へのアクセスは，このアダプタを経由して行う。
【００５１】
これらのパッケージは，図３のすべてのシナリオモデルで用いるものである。ＡＰ共通ＤＢサーバ２２上に配置し，ＡＰ共通ＤＢ２３へのアクセスを管理する。
【００５２】
以上述べてきたインタフェースをサービス系レイヤ３１０，機能系レイヤ３１１，共通サーバ系レイヤ２２０がそれぞれ有することで，サービス事業者のオペレータ登録，サービス事業者登録，コンテンツ登録，商品／コース登録，商品／コース参照・変更，エンドユーザ一覧取得，エンドユーザ脱会予約，プラットフォーム事業者オペレータ登録，契約一覧取得，商品購入・コース契約などを実現する。
【００５３】
図６および図７に記載されたアーキテクチャの項目は，図８に示されるように定義した。動作内容を上位の概念でまとめたコマンドカプセル１０８によって，操作者の意図した内容を実行するためには，インタフェース，メソッド，コマンドカプセル１０８およびコマンドカプセル実行エンジン３１２を使用する。コマンドカプセル実行エンジン３１２は，ＡＰサーバ２１に搭載されるサービス系レイヤ３１０または機能系レイヤ３１１から，コマンドカプセル１０８による指示により実行するように実装されている。
【００５４】
コマンドカプセル１０８は，関連するデータ操作，ロジックおよびパラメータとなる属性などをカプセル化したコンポーネントである。コマンドカプセル実行エンジン３１２は，コマンドカプセル１０８で動作し，関連プラットフォームおよびＡＰ共通ＤＢサーバ２２へ操作を振り分ける。
【００５５】
図９に従って，コマンドカプセルの簡単なイメージを説明する。ソフトウェアとして複数の処理・実行が行われる場合，その複数の個々の処理に対して，それぞれ動作・属性などをプログラム実行の情報として命令指示する必要がある。そのため，ＡＰ要素からＰＦ要素へ，例えばＡ命令，Ｂ命令という命令を出す場合に，通常，図９（Ａ）に示されるように複数のＰＦ要素での処理ごとに流れも考慮して記述する必要がある。そこで，コマンドカプセル１０８の概念を導入し，個々の複数の処理でまとめられるものをまとめて，あたかも一つの処理・実行で済むようしている。
【００５６】
すなわち，図９（Ｂ）のように，コマンドカプセル１０８は，一つの処理・実行のため，コマンドカプセル実行エンジン３１２を介して，複数の命令指示を含んだ情報及びその情報を解析して複数処理を起動できるようにした仕組みになっている。
【００５７】
アプリケーションからの共通コンポーネント呼び出しに対する共通コンポーネントの動作概要を図６および図１０を用いて説明する。図１０は上記共通コンポーネントの動作処理フローを示す図である。
【００５８】
（１）ＡＰシナリオ部３０のアプリケーションは，共通コンポーネント（サービス系レイヤ３１０）のインタフェースのサービス系レイヤ３１０のメソッドに対して，サービス系レイヤ３１０で用意したコマンドカプセル１０８を渡す（ステップＳ１）。
【００５９】
（２）直接，サービス系レイヤ３１０からコマンドカプセル実行エンジン３１２を動作させる場合（ステップＳ２），サービス系レイヤ３１０のメソッドは，サービス系レイヤ３１０のコマンドカプセル１０８をコマンドカプセル実行エンジン３１２に渡し（ステップＳ４），実行を依頼する。
【００６０】
（３）機能系レイヤ３１１を使用する場合は，サービス系レイヤ３１０のコマンドカプセル１０８は共通コンポーネント（機能系レイヤ３１１）のメソッド実行ロジックを持っているので，ここから共通コンポーネント（機能系レイヤ３１１）のメソッドに対してコマンドカプセル１０８を渡す（ステップＳ３）。
【００６１】
（４）機能系レイヤ３１１のメソッドは渡されたコマンドカプセル１０８をコマンドカプセル実行エンジン３１２に転送する（ステップＳ４）。
【００６２】
（５）コマンドカプセル実行エンジン３１２はコマンドカプセル１０８を実行し，関連処理を各プラットフォーム（ＰＦ）およびＡＰ共通ＤＢサーバ２２へ分配する（ステップＳ５）。ここでコマンドカプセル１０８の実行とは，コマンドカプセル１０８の中に入っているコマンド群をそれぞれの各コマンドを実行するＰＦやＡＰ共通ＤＢサーバ２２へ振り分ける動作を行うことである。
【００６３】
（６）コマンドカプセル実行エンジン３１２は関連プラットフォームおよびＡＰ共通ＤＢサーバ２２の実行状況を監視しており，処理結果を呼び出し元へ返す（ステップＳ６）。
【００６４】
（７）以降，処理結果を呼び出し元へ順に返す。
【００６５】
このようなサービス系レイヤ３１０，機能系レイヤ３１１，コマンドカプセル実行エンジン３１２を実装するために，デザイン・パターン（非特許文献１参照）として知られたコンポジットおよびコマンドのパターン（雛形）を利用し，さらに汎用的なソフトウェアの構造とした。
【００６６】
コンポジットとは，木構造を実現するもので，ディレクトリのようなものである。コマンドカプセル１０８を様々な組み合わせで利用できるように属性構造を作り上げることができる。すなわち，データ操作コマンドカプセルでのＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ　ｍａｒｋｕｐ　ｌａｎｇｕａｇｅ）のマッピング可能な属性構造を実現する。既存のコマンドカプセル１０８を再利用可能とし，再利用による開発工数削減に貢献する。
【００６７】
コマンドとは，命令を実行する操作を集めた雛形である。同時に開発するデータ操作に関する操作をカプセル化するテンプレートを提供する。命令を複数集めてコマンドを形成し，コマンドを複数集めて形成したものがコマンドカプセル１０８である。コマンドカプセル実行エンジン３１２は，コマンドカプセル１０８によって起動させるもので，例えば，一つのコマンドカプセル１０８により複数のコマンドが実行され，コマンドによりさらに複数の操作が実行できるため，手間がかからずに簡単な操作でサービスが実現できる。
【００６８】
ＡＰ共通ＤＢサーバ２２へのＤＢアクセスは，将来の新規サービス事業者の新たな要望に対応するための拡張性を確保する必要がある。アプリケーション開発者は，サービス事業者の要望に応じて，独自のテーブル定義／実装とそのテーブル操作クラスを実装する。共通コンポーネントでは，このような独自実装によるＤＢアクセスをサポートするため，次のような対策を立てている。
【００６９】
ＡＰ共通ＤＢ２３は，サービス事業者ごとにスキーマを用意する。サービス事業者は，このスキーマ上でデータ管理を独自に定義して行うことができる。また，ＡＰ共通ＤＢサーバ２２のデータ操作において，サービス事業者が定めるスキーマに対する操作を，Ｃｏｍｍａｎｄパターン（ＧｏＦ；非特許文献１参照）により実現する。さらに，それらのスキーマ操作の順序付け，組み合わせをサポートするためＣｏｍｐｏｓｉｔｅパターン（ＧｏＦ）を組み合わせて採用する。
【００７０】
このような機能系レイヤ３１１とコマンドカプセル実行エンジン３１２を機能ブロック図で示したものが図１１である。図１１において，４００は管理部（インボーカー），４０１は実行仲介部（コマンド），４０２はサービス事業者毎に項目を関連付けた構造を有し，該構造を組み合わせて内部に必要となる要素の情報を含んだ情報でさらに項目の関連付けを行うデータベースアクセス設定部，４０５はＤＢアクセス実行部（コンクリートコマンド）である。
【００７１】
図１１に示す，ＡＰサーバ２１の２階層の下位レイヤに位置するコマンドカプセル実行エンジン３１２の動き，特にＡＰ共通ＤＢサーバ２２へのＤＢベースアクセスについて説明する。
【００７２】
機能系レイヤ３１１は管理部４００を有し，管理部４００は，サービス系レイヤ３１０からコマンドカプセル１０８を受けて，コマンドカプセル実行エンジン３１２に実行指示を行い動作状況の監視を行う。
【００７３】
事前準備として，ＡＰ共通ＤＢ２３に，サービス事業者毎に必要なデータ項目（スキーマ）を設定する。また，サービス事業者によって違う実行仲介部４０１とＤＢアクセス実行部４０５の関連を記述したＤＢアクセス設定部４０２を作成する。
【００７４】
このような設定のもとに，各機能ブロックの動きは以下のようになる。
（１）上位ＡＰから命令を受けた管理部４００が実行仲介部４０３へ実行指示を出す。このときＤＢアクセス設定部４０２で設定された実行仲介部４０１とＤＢアクセス実行部４０５との関連を，実行仲介部４０１に指示する。
（２）実行仲介部４０１は，ＤＢアクセス設定部４０２と関連づけたＤＢアクセス実行部４０５に実際の実行を仲介する。
（３）ＤＢアクセス実行部４０５が共通サーバ系レイヤ２２０のインタフェースを実行する（共通サーバ系レイヤ２２０のインタフェースによりＡＰ共通ＤＢ２３のアクセスが行われる）。
（４）共通サーバ系レイヤ２２０より，結果・状況を，ＤＢアクセス実行部４０５を通じて，管理部４００へ返す。
【００７５】
さらに，デザイン・パターンの観点から，以上の動作の流れを説明する。図１１のコマンド（実行仲介部）３１４はインボーカー（管理部）４００の操作対象であり汎用データベースを操作するクラス（属性のグループ）である。コマンド（実行仲介部）３１４はインボーカー（管理部）４００がレシーバ３１５への実行指示仲介を行う仕組みを持っている（具体的なスキーマ操作は持っていない）。この具体的なスキーマ操作は，サービス事業者がコマンド（実行仲介部）４０１を継承したコンクリートコマンド３１３で実装する。
【００７６】
サービス事業者は，インボーカー（管理部）４００にコンクリートコマンド３１３を渡し，レシーバ３１５へスキーマ操作を実行させる。このとき，コマンド（実行仲介部）３１４に混在させたパターンを適用することで，コンクリートコマンド３１３が木構造で管理可能になる。これにより，既存のコンクリートコマンド３１３の再利用も可能にするコンクリートコマンド（木構造的命令部）３１３の順序付け，組み合わせを行う。なお，コンクリートコマンド３１３は，命令を包括して実行依頼するコマンドカプセル１０８である。
【００７７】
このようにすることで，以下のような特徴がある。
（１）データベースシステムの項目と項目操作の制御を，他のサービスに依存しないように設定して行える。
（２）汎用のデータベース操作命令と，具体的な項目操作の設定を分離し，相互に依存しないようにした。それにより，改造が容易になる。
（３）上記の具体的な項目操作の設定を，項目設定を木構造的に組み合わせて設定することができる。
【００７８】
それによって，設定が容易（流用が容易）になる。なお，クラスの承継とは，「クラスの内部にオブジェクトを構成するのに必要な要素の情報を持って」引き継がれることを言う。このような構成は，新しいクラスを設計するときに既存のクラスがもっている情報を利用できる。
【００７９】
以上説明した一連の処理は，ＣＰＵ等の演算制御手段で制御され，処理に必要なデータやその組が蓄積手段に格納され，処理の過程でデータの読み出し，書き込みが行われる。また，上記演算制御手段に通信回線や外部記憶媒体からのプログラムのインストールにより上記一連の処理が実行される。
【００８０】
以上のＡＰ共通機能部３１の共通コンポーネントが提供するインタフェースをアプリケーションが利用する方法について説明する。アプリケーション（ＡＰシナリオ部３０）は，サービス系レイヤ３１０が提供するインタフェース／メソッドとコマンドカプセル１０８を操作する。
【００８１】
まず，アプリケーションは，操作するインタフェース／メソッドを選択し，そのインタフェースを実行するためのコマンドカプセル１０８に対して所定のパラメータを設定する。パラメータを設定したコマンドカプセル１０８を，選択したインタフェース／メソッドに渡す。インタフェース／メソッドは，コマンドカプセル１０８でコマンドカプセル実行エンジン３１２に処理依頼を行う。処理結果は，選択したインタフェース／メソッドの戻り値および例外として呼び出し元のアプリケーションへ通知する。
【００８２】
上記コマンドカプセル１０８に設定するパラメータは，木構造で保持できるようになっている。パラメータ構造はそれぞれのコマンドカプセル１０８に依存する。なお，本実施の形態では，コマンドカプセル１０８のパラメータ構造は，ＸＭＬに対応するためのオブジェクト構造を適用している。
【００８３】
図１２は，コマンドカプセルとパラメータ仕様を説明する図であり，図１３は，アプリケーションのプログラミング例を説明する図である。
【００８４】
図１２に示すように，コンポジットのメソッド（サンプルメソッド）で，コマンドカプセルを指定する。コマンドカプセルは，コンポジットの下位クラスとして定義される。図１２のサンプルパラメータ仕様の例に示されるように，パラメータ仕様は，ＸＭＬで記述される。
【００８５】
アプリケーションは，まず図１３（Ａ）に示すように，コマンドカプセル１０８のオブジェクトを用意する。入力パラメータとなるコマンドカプセルオブジェクトと，戻り値となるコマンドカプセルオブジェクトを宣言する。
【００８６】
次に，パラメータの設定を行う。入力パラメータとなるコマンドカプセル１０８に対して，パラメータ仕様に従ってパラメータを設定する。図１３に示す例では，パラメータ仕様の項目“ＲｏｏｔＣｍｄＰａｒａｍ１”に値“ＡＢＣ”，項目“ＲｏｏｔＣｍｄＰａｒａｍ２”に値“１２３”，ノード“ＮｅｓｔｅｄＣｍｄ”の項目“ＮｅｓｔｅｄＣｍｄＰａｒａｍ１”に値“ＸＹＺ”，ノード“ＮｅｓｔｅｄＣｍｄ”の項目“ＮｅｓｔｅｄＣｍｄＰａｒａｍ２”に値“９８７”を設定している。
【００８７】
次に，コマンドカプセル１０８を実行する。図１３（Ｃ）に示すように，コマンドカプセル１０８をメソッドのパラメータにし，戻り値の受け先を指定してメソッドに渡す。
【００８８】
コマンドカプセル１０８のパラメータ取り出しは，コマンドカプセル１０８のＧｅｔメソッドで取り出す。図１３（Ｄ）は，サンプルのコマンドカプセル１０８からの取り出しの例を示している。
【００８９】
本実施の形態で共通コンポーネントとして用意されたパッケージの代表的な実現例を以下に示す。
【００９０】
サービス系共通コンポーネントパッケージのユーザ管理サービスパッケージＰ１５が提供するユーザ属性登録／登録完了通知インタフェースは，以下に示す利用者登録メソッド「ｒｅｓｉｓｔ」の処理を定義している。
2004110291.tif 000003
上記利用者登録メソッドの機能概要は，以下の通りである。
・サービス事業者ＩＤと認証オブジェクトを指定して，利用者コマンドに設定した利用者属性（プロパティ）を登録する。
・手続きが正常に終了した場合，設定した利用者属性をＣＵｓｅｒＩｎｆｏＳｅｒｖｉｃｅｓＣｍｄに格納したものを呼び出し元に返す。
・サービス事業者ＩＤは，共通コンポーネント（ストレージサーバ）のスキーマ指定などサービス事業者情報の管理に使用する。
・認証オブジェクトは，各プラットフォームに対して登録依頼を行うときの認証に使用する。
【００９１】
上記利用者コマンド「ＣＵｓｅｒＩｎｆｏＳｅｒｖｉｃｅｓＣｍｄ」を継承したコマンドカプセルの一例として，エンドユーザコマンドカプセル，ＰＦ事業者オペレータコマンドカプセル，ＰＦ事業者システムオペレータコマンドカプセル，サービス事業者オペレータコマンドカプセル，サービス事業者コマンドカプセルがある。
【００９２】
ユーザ管理サービスパッケージＰ１５が提供するユーザ属性検索／一覧／詳細参照／変更／削除インタフェースが定義している利用者一覧取得メソッド「ｇｅｔＬｉｓｔ　」，利用者詳細取得メソッド「ｇｅｔＤｅｔａｉｌ　」，利用者属性変更メソッド「ｃｈａｎｇｅ」，利用者削除メソッド「ｄｅｌｅｔｅ」の処理について以下に示す。
2004110291.tif 000004
上記利用者一覧取得メソッドの機能概要は，以下の通りである。
・サービス事業者ＩＤと認証オブジェクトを指定して，利用者コマンドに設定した検索条件に合致する利用者属性（プロパティ）を検索する。
・手続きが正常に終了した場合，取得した利用者属性をＣＵｓｅｒＩｎｆｏＳｅｒｖｉｃｅｓＣｍｄに格納したものをＬｉｓｔに追加して呼び出し元へ返す。
・サービス事業者ＩＤは，共通コンポーネント（ストレージサーバ）のスキーマ指定などサービス事業者情報の管理に使用する。
・認証オブジェクトは，各プラットフォームに対して登録依頼を行うときの認証に使用する。
2004110291.tif 000005
上記利用者詳細取得メソッドの機能概要は，以下の通りである。
・サービス事業者ＩＤと認証オブジェクトを指定して，利用者コマンドに設定した検索条件に合致する利用者属性（プロパティ）を検索する。
・手続きが正常に終了した場合，設定した利用者属性をＣＵｓｅｒＩｎｆｏＳｅｒｖｉｃｅｓＣｍｄに格納したものを呼び出し元に返す。
・サービス事業者ＩＤは，共通コンポーネント（ストレージサーバ）のスキーマ指定などサービス事業者情報の管理に使用する。
・認証オブジェクトは，各プラットフォームに対して登録依頼を行うときの認証に使用する。
【００９３】
また，例えばサービス系共通コンポーネントパッケージのコンテンツ管理サービスパッケージＰ１１が提供するコンテンツ権利属性登録受付／登録完了通知インタフェースは，以下に示す権利登録予約メソッド「ｒｅｓｉｓｔ」の処理を定義している。
2004110291.tif 000006
上記権利登録予約メソッドの機能概要は，以下の通りである。
・サービス事業者ＩＤと認証オブジェクトを指定して，権利コマンドに設定した権利属性（プロパティ）の登録予約をする。
・手続きが正常に終了した場合，設定した権利属性をＣＲｉｇｈｔＳｅｒｖｉｃｅｓＣｍｄ　に格納したものを呼び出し元に返す。
・サービス事業者ＩＤは，共通コンポーネント（ストレージサーバ）のスキーマ指定などサービス事業者情報の管理に使用する。
・認証オブジェクトは，各プラットフォームに対して登録依頼を行うときの認証に使用する。
【００９４】
上記権利コマンド「ＣＲｉｇｈｔＳｅｒｖｉｃｅｓＣｍｄ　」を継承したコマンドカプセルの一例として，権利コマンドカプセルがある。
【００９５】
コンテンツ管理サービスパッケージＰ１１が提供するコンテンツ検索／一覧／詳細参照／変更／削除インタフェースは，以下に示す権利一覧取得メソッド「　ｇｅｔＬｉｓｔ」，権利詳細取得メソッド「ｇｅｔＤｅｔａｉｌ　」，権利属性変更メソッド「ｃｈａｎｇｅ」，権利属性削除メソッド「ｄｅｌｅｔｅ」の処理を定義している。
2004110291.tif 000007
上記権利一覧取得メソッドの機能概要は，以下の通りである。
・サービス事業者ＩＤと認証オブジェクトを指定して，権利コマンドに設定した権利属性（プロパティ）を検索する。
・手続きが正常に終了した場合，取得した権利属性をＣＲｉｇｈｔＳｅｒｖｉｃｅｓＣｍｄ　に格納したものをＬｉｓｔに追加して呼び出し元へ返す。
・サービス事業者ＩＤは，共通コンポーネント（ストレージサーバ）のスキーマ指定などサービス事業者情報の管理に使用する。
・認証オブジェクトは，各プラットフォームに対して登録依頼を行うときの認証に使用する。
【００９６】
上記メソッドにおける権利コマンド「ＣＲｉｇｈｔＳｅｒｖｉｃｅｓＣｍｄ　」を継承したコマンドカプセルの一例として，権利コマンドカプセル「ＣＲｉｇｈｔｓＣｍｄ」がある。
【００９７】
また，サービス系共通コンポーネントパッケージの商品／コース管理サービスパッケージＰ１２が提供する商品／コース属性登録／登録完了通知インタフェースは，以下に示す商品／コース属性登録メソッド「ｒｅｓｉｓｔ」の処理を定義している。
2004110291.tif 000008
上記商品／コース属性登録メソッドの機能概要は，以下の通りである。
・サービス事業者ＩＤと認証オブジェクトを指定して，商品／コースコマンドに設定した商品／コース属性属性（プロパティ）を登録する。
・手続きが正常に終了した場合，設定した商品／コース属性を　ＣＣｏｍｍｏｄｉｔｙＳｅｒｖｉｃｅｓＣｍｄに格納したものを呼び出し元に返す。
・サービス事業者ＩＤは，共通コンポーネント（ストレージサーバ）のスキーマ指定などサービス事業者情報の管理に使用する。
・認証オブジェクトは，各プラットフォームに対して登録依頼を行うときの認証に使用する。
【００９８】
上記商品／コースコマンド「　ＣＣｏｍｍｏｄｉｔｙＳｅｒｖｉｃｅｓＣｍｄ」を継承したコマンドカプセルの一例として，商品コマンドカプセルとコースコマンドカプセルがある。
【００９９】
商品／コース管理サービスパッケージＰ１２が提供する商品／コース検索／一覧／詳細参照／変更／削除インタフェースは，例えば，以下に示す商品／コース一覧取得メソッド「ｇｅｔＣｏｍｍｏｄｉｔｙＬｉｓｔ」，商品／コース詳細取得メソッド「ｇｅｔＣｏｍｍｏｄｉｔｙＤｅｔａｉｌ」の処理を定義している。
【０１００】
上記インタフェースを使用したサービス系レイヤ３１０および機能系レイヤ３１１の動作例を，サービス系レイヤ３１０が「コンテンツ権利情報登録」の依頼をＡＰシナリオ部３０から受けた場合の例に従って説明する。
【０１０１】
ＡＰシナリオ部３０は，上記コンテンツ管理サービスパッケージにおける権利サービスインタフェースの権利登録予約メソッド（　ＣＲｉｇｈｔｓＳｅｒｖｉｃｅｓＣｍｄ．ｒｅｓｉｓｔ（サービス事業者ＩＤ，認証オブジェクト，権利コマンド））を呼び出し，これをサービス系レイヤ３１０が実行する。
【０１０２】
サービス系レイヤ３１０では，パラメータは正常であるかどうか，また認証されているかどうかを調べ，パラメータが正常でない場合，またはこのサービス事業者ＩＤが認証されていない場合には，ＡＰシナリオ部３０へ「不可」の回答を返却する。
【０１０３】
パラメータが正常であり，認証されている場合，コンテンツ権利情報登録を機能系レイヤ３１１に依頼する。このとき，サービス系レイヤ３１０は，コンテンツ管理機能パッケージにおける権利属性操作インタフェースの権利属性登録メソッド（　ＣＡｃｃｅｓｓＣｏｎｔｃｎｔＲｉｇｈｔｓＩｎｆｏ．ｅｎｔｒｙ　（サービス事業者ＩＤ，認証オブジェクト，権利アクセスコマンド））を呼び出し，これを機能系レイヤ３１１が実行する。
【０１０４】
サービス系レイヤ３１０は，呼び出したコンテンツ管理機能パッケージにおける権利属性操作インタフェースの権利属性登録メソッドの戻り値として，コンテンツ権利情報登録の結果を受ける。この戻り値として受け取ったコンテンツ権利情報登録の結果をＡＰシナリオ部３０へ返却する。
【０１０５】
以上は一例であるが，以上の説明から他のパッケージのインタフェース，メソッドについても，同様に容易に構成できることは明らかである。
【０１０６】
次に，ＡＰ共通ＤＢサーバ２２が管理するＡＰ共通ＤＢ２３の例について説明する。映像コンテンツ配信システムなどのコンテンツ流通システム開発におけるデータベースの拡張性，カスタマイズ手段を確保するため，構築するサービス独自のスキーマ定義を行う手段を提供する。
【０１０７】
図１４は，本実施の形態におけるスキーマ定義の例を示している。個々のサービス事業者のサービスに依存しないで共通に用意される共通スキーマと，サービス事業者別スキーマとがある。すなわち，汎用のデータベースの操作項目部とサービス事業者ごとの操作項目部とが分離して構成されている。
【０１０８】
共通スキーマは，共通コンポーネントで予約されているスキーマであり，ＰＦ事業者が管理する。ＡＰ共通ＤＢサーバ２２が共通サーバとして共通で管理するデータを格納する。共通スキーマは，共通サーバを所有／運用する管理者に関するデータ，著作権管理ＰＦ１３の動作状況に関するデータおよびＶＯＤ配信サーバ１５，ダウンロードサーバ１６などの配信サーバとの連携に関するデータなど，サービスに特化しないデータを対象とする。
【０１０９】
一方，サービス事業者別スキーマは，各サービス事業者別のスキーマであり，サービスに特化するデータを対象とする。このサービス事業別スキーマは，共通コンポーネントで提供するインタフェース／メソッドで指定するサービス事業者ＩＤで作成され，スキーマ名にサービス事業者ＩＤを用いることにより，個々のスキーマが区別されるようになっている。
【０１１０】
例えば，サービス事業者スキーマ名は“ＣＰＦ”＋“サービス事業者ＩＤ”と定義され，サービス事業者ＩＤが“２００２０１”の場合，スキーマ名は“ＣＰＦ２００２０１”となる。
【０１１１】
図１５に，共通スキーマのテーブル構成例を示す。ライセンステーブルＴ１は，グループＩＤ，ライセンス開始日，満了日など，ライセンスに関するデータを格納する。ユーザ管理テーブルＴ２は，ユーザＩＤ，パスワード，氏名，氏名の読み仮名，生年月日，電話番号など，ユーザ管理に関するデータを格納する。プラットフォーム事業者テーブルＴ３は，プラットフォーム事業者ＩＤ，ユーザＩＤ，登録日など，プラットフォーム事業者に関するデータを格納する。サービス事業者テーブルＴ４は，サービス事業者ＩＤ，ユーザＩＤ，ポータルサイト，業種，サービス名など，サービス事業者に関するデータを格納する。
【０１１２】
また，著作権管理プラットフォームテーブルＴ５は，ユーザＩＤ，立場，通称，問い合わせ先種別，登録日など，著作権管理ＰＦ１３に関するデータを格納する。課金決済プラットフォームテーブルＴ６は，ユーザＩＤ，カード番号，カード契約者，カード有効期限など，課金決済ＰＦ１２に関するデータを格納する。以上のテーブルは，リレーショナルデータベースで管理されている。
【０１１３】
図１６に，サービス事業者別スキーマのテーブル構成例を示す。エンドユーザ管理テーブルＴ１１は，エンドユーザＩＤ，職業など，エンドユーザに関連するデータを格納する。ユーザ管理テーブルＴ１２は，ユーザＩＤ，氏名，性別，生年月日，電話番号，登録日など，ユーザ管理に関するデータを格納する。サービス事業者テーブルＴ１３は，サービス事業者ＩＤ，業種，登録日など，サービス事業者に関するデータを格納する。
【０１１４】
また，課金決済プラットフォームテーブルＴ１４は，ユーザＩＤ，カード番号，カード契約者，カード有効期限など，課金決済ＰＦ１２に関するデータを格納する。コンテンツＩＤテーブルＴ１５は，コンテンツＩＤ，ユーザＩＤなど，コンテンツ識別情報に関するデータを格納する。商品詳細テーブルＴ１６は，商品ＩＤ，購入日など，商品に関する詳細データを格納する。取引テーブルＴ１７は，取引ＩＤ，商品／コースＩＤ，登録日など，取引に関するデータを格納する。課金・決済テーブルＴ１８は，課金・決済日，購入日など，課金・決済に関するデータを格納する。
【０１１５】
また，コーステーブルＴ１９は，コースＩＤ，契約開始日など，コースに関するデータを格納する。商品テーブルＴ２０は，商品ＩＤ，商品区分，価格，内容など，商品に関するデータを格納する。商品／コース関連付けテーブルＴ２１は，商品／コース関連付けＩＤ，商品ＩＤ，状態，登録日など，商品／コースとコンテンツの関連付けに関するデータを格納する。コンテンツテーブルＴ２２は，コンテンツ実体ＩＤ，フォーマット，試聴時間，配信方式，内容，サービス利用状態，登録日など，コンテンツに関するデータを格納する。これらのテーブルも所定のリレーショナルデータベースで管理される。
【０１１６】
サービス事業者は，それぞれ独自のサービス事業者別スキーマによってデータを管理することが可能であり，ＡＰ共通ＤＢ２３のデータ操作においてサービス事業者別スキーマに対する操作を，前述したようにＣｏｍｍａｎｄパターン（ＧｏＦ）により実現する。
【０１１７】
具体的には，図１１で示したコンクートコマンド３１３（ＤＢアクセス実行部４０５）の部分を，アプリケーション開発者が既存のものを流用して作成する。すなわち，アプリケーションが独自に定義したサービス事業者別スキーマに対するデータ操作ロジックを，コンクートコマンド３１３で記述する。コマンドカプセル実行エンジン３１２は，新たに開発されたコンクリートコマンド３１３を認証して実行するための仕組みを用意する。コンクリートコマンド３１３のテンプレートとなるコマンド３１４と，その実行依頼先となるレシーバ３１５およびアプリケーションからの実行指示を受け付けて，コンクリートコマンド３１３を実行し，アプリケーションの独自ロジックを実行するフレームワークを形成する。
【０１１８】
以下では，コンテンツ流通サービスにおける各種の要求処理に対する処理の流れの例について，代表的な例を用いて説明する。
【０１１９】
図１７および図１８は，本発明を用いたサービス事業者オペレータ（ＯＰ）パスワード問合わせ情報チェック処理フローの一例を示す図である。まず，前処理として，ＡＰシナリオ部３０で，ロジック以外の画面遷移，見栄えなどに関する処理が行われる（ステップＳ２１）。例えば，入力画面表示や入力画面チェックや確認画面表示などの処理を行う。
【０１２０】
そして，ＡＰシナリオ部３０からサービス系レイヤ３１０にサービス事業者ＯＰ検索処理実行を依頼する（ステップＳ２２）。この場合，引数として事業者，認証情報，検索条件などをコマンドカプセルとして渡す。次に，サービス系レイヤ３１０は，機能系レイヤ３１１に処理依頼を出すためのコマンドを作成する（ステップＳ２３）。また，機能系レイヤ３１１に汎用検索処理実行を依頼する（ステップＳ２４）。この場合，サービス事業者ＯＰの検索を汎用検索処理機能に処理実行依頼をする。
【０１２１】
機能系レイヤ３１１は，サービス事業者ＯＰ検索ロジック構築を行う（ステップＳ２５）。また，共通サーバ系レイヤ２２０に検索処理実行を依頼する（ステップＳ２６）。共通サーバ系レイヤ２２０は，最適化した検索コマンドを発行することによりサービス事業者ＯＰ検索を実行する（ステップＳ２７）。ＡＰ共通ＤＢ２３から検索結果を受信し，機能系レイヤ３１１に結果を返却する（ステップＳ２８）。
【０１２２】
次に，機能系レイヤ３１１は，検索結果を受信し，返却用検索結果組み立てを行う（ステップＳ２９）。そして，サービス系レイヤ３１０に結果を返却する（ステップＳ３０）。
【０１２３】
サービス系レイヤ３１０は，検索結果を受信し，返却用検索結果組み立てを行う（ステップＳ３１）。また，ＡＰシナリオ部３０に結果を返却する（ステップＳ３２）。ＡＰシナリオ部３０でサービス事業者ＯＰ検索処理の結果を受信する（ステップＳ３３）。そして，ＡＰシナリオ部３０で，ロジック以外の画面遷移，見栄えなどに関する処理が行われる（ステップＳ３４）。例えば，確認結果画面表示などを行う。
【０１２４】
図１９乃至図２２は，本発明を用いたサービス事業者ＯＰパスワード問合わせ情報チェックにおけるシーケンス図の一例である。図中，１８はメールサーバである。
【０１２５】
Ａ）まず，クライアントＰＣ８’のサービス事業者トップメニュー画面において，「サービス事業者オペレータパスワード問い合わせ」のリンクをクリックして，ＡＰサーバ２１のＡＰシナリオ部３０に問い合わせると，ＡＰシナリオ部３０は，クライアントＰＣ８’にパスワード問い合わせ情報入力画面を表示させる。当該入力画面において「送信」のリンクがクリックされると，問い合わせ情報がＡＰシナリオ部３０に送信される。
【０１２６】
Ｂ）次に，ＡＰシナリオ部３０は，パスワード問い合わせ情報チェックアクションを行い，問い合わせ情報を基に必須項目をチェックした後，サービス系レイヤ３１０に引数として検索条件をコマンドカプセル１０８として渡してサービス事業者ＯＰ一覧の取得依頼を行う。
【０１２７】
Ｃ−Ｄ）次に，サービス系レイヤ３１０は，機能系レイヤ３１１に処理依頼を出すためのコマンドを作成し，機能系レイヤ３１１に検索条件をコマンドカプセル１０８として渡してサービス事業者ＯＰ検索処理実行を依頼する。
【０１２８】
Ｅ−Ｆ）機能系レイヤ３１１は，サービス事業者ＯＰ検索ロジック構築を行い，コマンドカプセル実行エンジン３１２に検索条件を渡す。コマンドカプセル実行エンジン３１２は，共通サーバ系レイヤ２２０に検索実行文を渡してサービス事業者ＯＰ検索実行を依頼する。
【０１２９】
Ｇ−Ｍ）ＡＰ共通ＤＢサーバ２２は，サービス事業者ＯＰ情報を検索し，機能系レイヤ３１１に検索結果を返却する。この検索結果は，コマンドカプセル実行エンジン３１２，機能系レイ３１１を経由してサービス系レイヤ３１０に返却される。検索結果を受け取ったサービス系レイヤ３１０は，ＡＰシナリオ部３０に検索結果を返却する。
【０１３０】
Ｎ）ＡＰシナリオ部３０はサービス事業者ＯＰ検索結果を受信すると，サービス事業者存在チェック，サービス事業者オペレータメールアドレス一致チェックを行い，サービス系レイヤ３１０に検索条件を渡してサービス事業者ＯＰパスワードを問い合わせる。
【０１３１】
Ｏ−Ｐ）サービス系レイヤ３１０は，検索条件を機能系レイヤ３１１に渡す。機能系レイヤ３１１は，通知メールをメールサーバ１８に送信するとともに，サービス事業者ＯＰ検索ロジック（ＳＥＬＥＣＴ文等）を構築し，コマンドカプセル実行エンジン３１２に検索条件を渡す。コマンドカプセル実行エンジン３１２は，ＡＰ共通ＤＢサーバ２２に検索実行文を渡して，サービス事業者ＯＰ検索実行を依頼する。
【０１３２】
Ｑ−Ｒ）ＡＰ共通ＤＢサーバ２２は，サービス事業者ＯＰ情報を検索し，検索結果をコマンドカプセル実行エンジン３１２に返却する。この検索結果は，コマンドカプセル実行エンジン３１２，機能系レイヤ３１１を経由してサービス系レイヤ３１０に返却される。
【０１３３】
Ｓ−Ｕ）サービス系レイヤ３１０は，ＡＰシナリオ部３０に検索結果を返却し，検索結果を受け取ったＡＰシナリオ部３０は，確認結果画面表示などに関する処理を行い，問い合わせ結果をクライアントＰＣ８’に送信し，パスワード送信完了画面を表示させる。また，メールサーバ１８からクライアントＰＣ８’には通知メールが送信される。
【０１３４】
以上の処理は，各サーバのコンピュータと各サーバに搭載したソフトウェアプログラムとによって実現することができ，そのプログラムは，コンピュータが読み取り可能な可搬媒体メモリ，半導体メモリ，ハードディスク等の適当な記録媒体に格納して，そこから読み出すことによりコンピュータに実行させることができる。
【０１３５】
以上説明したように，本発明は，アプリケーションをＡＰシナリオ部３０とＡＰ共通機能部３１とに分け，さらにＡＰ共通機能部３１をサービス系レイヤ３１０と機能系レイヤ３１１とに階層化することにより，例えば，上位のアプリケーションで修正が必要な場合，一番上のレイヤのインタフェースの修正で吸収して，下位のＰＦ要素に影響を与えないようにすることができる。すなわち，下位のインタフェースおよびプラットフォームはそのままでよい。
【０１３６】
また，逆に，下位のＰＦ要素が変わる場合，下位のインタフェースの修正で吸収し，上のアプリケーションには影響を与えず，そのままとするようなことが可能であり，カスタマイズ，拡張性が広がる。
【０１３７】
特に，既存のパターンの利用および組み合わせによって，サービス事業者独自のシステムを作成することができるため，システムの開発がきわめて容易になる。また，本システムは，全体として唯一のサービス事業者が使用するだけでなく，異なるコンテンツ流通サービスモデルを実現する複数のサービス事業者が，各種ＰＦその他のリソースを可能な範囲で共有できる構成になっているため，リソースの有効活用が可能なシステムとなっている。
【０１３８】
【発明の効果】
上述のように，本発明によれば以下の特長を有する。
・様々なビジネスモデルに対応するためのシステム開発が容易になる。
・共通的に利用できる部品の共通利用，及び再利用できる部品を再利用することで，開発リソースの有効利用が図れ，開発効率が高まる。
・システムで利用する各種ＰＦ要素の利用方法を熟知していなくても，それを利用したアプリケーションを開発できるようになる。
【０１３９】
特に本発明は，コマンドカプセルの実行エンジンをアプリケーションサーバのアプリケーション共通部分のもとで起動させることで，各サービス事業者に必要な項目の作成，実行を共通の性質を持つグループに分けること，まとめて取り扱うことが簡単に実現でき，拡張性のあるコンテンツ流通システム基盤を実現できるという効果がある。
【図面の簡単な説明】
【図１】コンテンツ流通ネットワークシステムの全体概念構成図である。
【図２】コンテンツ流通システムの詳細構成図である。
【図３】コンテンツ流通のシナリオモデルを示す図である。
【図４】サービス系レイヤ，機能系レイヤ，共通サーバ系レイヤの概要を示す図である。
【図５】プラットフォームを含めたシステム全体の構成例を示す図である。
【図６】ＡＰサーバに搭載したコンポーネントの関連を示す構成図である。
【図７】ＡＰ共通機能部におけるパッケージおよびインタフェースを示す図である。
【図８】インタフェース，メソッド，コマンドカプセル，コマンドカプセル実行エンジンの説明図である。
【図９】コマンドカプセルの説明図である。
【図１０】共通コンポーネントの動作処理フローを示す図である。
【図９】コンポジット，コマンド，メディエータの説明を示す図である。
【図１１】機能系レイヤとコマンドカプセル実行エンジンの機能ブロック図である。
【図１２】コマンドカプセルとパラメータ仕様の例を説明する図である。
【図１３】アプリケーションのプログラミング例を説明する図である。
【図１４】スキーマ定義の例を示す図である。
【図１５】共通スキーマのテーブル構成例を示す図である。
【図１６】サービス事業者別スキーマのテーブル構成例を示す図である。
【図１７】サービス事業者ＯＰパスワード問合わせ情報チェック処理フローの一例を示す図である。
【図１８】サービス事業者ＯＰパスワード問合わせ情報チェック処理フローの一例を示す図である。
【図１９】本発明を用いたサービス事業者ＯＰパスワード問合わせ情報チェックにおけるシーケンス図の一例を示す図である。
【図２０】本発明を用いたサービス事業者ＯＰパスワード問合わせ情報チェックにおけるシーケンス図の一例を示す図である。
【図２１】本発明を用いたサービス事業者ＯＰパスワード問合わせ情報チェックにおけるシーケンス図の一例を示す図である。
【図２２】本発明を用いたサービス事業者ＯＰパスワード問合わせ情報チェックにおけるシーケンス図の一例を示す図である。
【符号の説明】
１　広義のコンテンツ流通システム
２　狭義のコンテンツ流通システム
３　データセンタ
４　インターネット
５　ＩＳＰ
６　エンドユーザ
７　専用線
８　サービス事業者
９　決済代行業者
１０　ＰＦ事業者
１１　各ＰＦ要素
１２　課金決済ＰＦ
１３　著作権管理ＰＦ
１４　ライセンスサーバ
１５　ＶＯＤ配信サーバ
１６　ダウンロードサーバ
１７　アーカイブサーバ
２１　ＡＰサーバ
２２　ＡＰ共通ＤＢサーバ
２３　ＡＰ共通ＤＢ
２４　ブラウザ
３０　ＡＰシナリオ部
３１　ＡＰ共通機能部
１００　ＨＴＴＰサーバ
１０１　ＰＦ連携システム
１０２，１０３，１０４，１０５，１０６，１０７　プラットフォームインタフェース（ＰＦＩＦ）
１０８　コマンドカプセル
１１０　各ＰＦ要素のサーバ
１３０　サービス系レイヤインタフェース
１３１　機能系レイヤインタフェース
１３２　個別ＰＦのアダプタインタフェース
２２０　共通サーバ系レイヤ
３００　個別ＡＰ
３０１　ＡＰシナリオ部におけるサービス画面
３０２　ＡＰシナリオ部におけるＡＰ制御コンポーネント
３１０　サービス系レイヤ
３１１　機能系レイヤ
３１２　コマンドカプセル実行エンジン
【図１】
2004110291.tif 000009
【図２】
2004110291.tif 000010
【図３】
2004110291.tif 000011
【図４】
2004110291.tif 000012
【図５】
2004110291.tif 000013
【図６】
2004110291.tif 000014
【図７】
2004110291.tif 000015
【図８】
2004110291.tif 000016
【図９】
2004110291.tif 000017
【図１０】
2004110291.tif 000018
【図１１】
2004110291.tif 000019
【図１２】
2004110291.tif 000020
【図１３】
2004110291.tif 000021
【図１４】
2004110291.tif 000022
【図１５】
2004110291.tif 000023
【図１６】
2004110291.tif 000024
【図１７】
2004110291.tif 000025
【図１８】
2004110291.tif 000026
【図１９】
2004110291.tif 000027
【図２０】
2004110291.tif 000028
【図２１】
2004110291.tif 000029
【図２２】
2004110291.tif 000030
【手続補正書】
【提出日】平成14年10月10日(2002.10.10)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】図面の簡単な説明
【補正方法】変更
【補正の内容】
【図面の簡単な説明】
【図１】コンテンツ流通ネットワークシステムの全体概念構成図である。
【図２】コンテンツ流通システムの詳細構成図である。
【図３】コンテンツ流通のシナリオモデルを示す図である。
【図４】サービス系レイヤ，機能系レイヤ，共通サーバ系レイヤの概要を示す図である。
【図５】プラットフォームを含めたシステム全体の構成例を示す図である。
【図６】ＡＰサーバに搭載したコンポーネントの関連を示す構成図である。
【図７】ＡＰ共通機能部におけるパッケージおよびインタフェースを示す図である。
【図８】インタフェース，メソッド，コマンドカプセル，コマンドカプセル実行エンジンの説明図である。
【図９】コマンドカプセルの説明図である。
【図１０】共通コンポーネントの動作処理フローを示す図である。
【図１１】機能系レイヤとコマンドカプセル実行エンジンの機能ブロック図である。
【図１２】コマンドカプセルとパラメータ仕様の例を説明する図である。
【図１３】アプリケーションのプログラミング例を説明する図である。
【図１４】スキーマ定義の例を示す図である。
【図１５】共通スキーマのテーブル構成例を示す図である。
【図１６】サービス事業者別スキーマのテーブル構成例を示す図である。
【図１７】サービス事業者ＯＰパスワード問合わせ情報チェック処理フローの一例を示す図である。
【図１８】サービス事業者ＯＰパスワード問合わせ情報チェック処理フローの一例を示す図である。
【図１９】本発明を用いたサービス事業者ＯＰパスワード問合わせ情報チェックにおけるシーケンス図の一例を示す図である。
【図２０】本発明を用いたサービス事業者ＯＰパスワード問合わせ情報チェックにおけるシーケンス図の一例を示す図である。
【図２１】本発明を用いたサービス事業者ＯＰパスワード問合わせ情報チェックにおけるシーケンス図の一例を示す図である。
【図２２】本発明を用いたサービス事業者ＯＰパスワード問合わせ情報チェックにおけるシーケンス図の一例を示す図である。
【符号の説明】
１　広義のコンテンツ流通システム
２　狭義のコンテンツ流通システム
３　データセンタ
４　インターネット
５　ＩＳＰ
６　エンドユーザ
７　専用線
８　サービス事業者
９　決済代行業者
１０　ＰＦ事業者
１１　各ＰＦ要素
１２　課金決済ＰＦ
１３　著作権管理ＰＦ
１４　ライセンスサーバ
１５　ＶＯＤ配信サーバ
１６　ダウンロードサーバ
１７　アーカイブサーバ
２１　ＡＰサーバ
２２　ＡＰ共通ＤＢサーバ
２３　ＡＰ共通ＤＢ
２４　ブラウザ
３０　ＡＰシナリオ部
３１　ＡＰ共通機能部
１００　ＨＴＴＰサーバ
１０１　ＰＦ連携システム
１０２，１０３，１０４，１０５，１０６，１０７　プラットフォームインタフェース（ＰＦＩＦ）
１０８　コマンドカプセル
１１０　各ＰＦ要素のサーバ
１３０　サービス系レイヤインタフェース
１３１　機能系レイヤインタフェース
１３２　個別ＰＦのアダプタインタフェース
２２０　共通サーバ系レイヤ
３００　個別ＡＰ
３０１　ＡＰシナリオ部におけるサービス画面
３０２　ＡＰシナリオ部におけるＡＰ制御コンポーネント
３１０　サービス系レイヤ
３１１　機能系レイヤ
３１２　コマンドカプセル実行エンジン