(57)【特許請求の範囲】
【請求項１】
ネットワークに接続されたＨＴＴＰサーバと、
コンテンツデータベースと、
前記コンテンツデータベースが提供可能なコンテンツ毎のアクセスレベルおよび前記コンテンツデータベースへのアクセスが許可されたユーザ毎のアクセスレベル、を含んだ管理情報を格納する管理情報データベースと、
前記コンテンツデータベースおよび前記管理情報データベースを管理するＣＧＩ処理部と、
を備え、
前記コンテンツデータベースおよび前記管理情報データベースは前記ＣＧＩ処理部を介して前記ＨＴＴＰサーバに接続されており、
前記コンテンツデータベースに格納されたコンテンツまたは当該コンテンツデータベースに格納された情報が示す格納先に格納されたコンテンツ、へのアクセス要求を前記ネットワーク経由で受信した場合、
前記ＨＴＴＰサーバは、受信したアクセス要求を前記ＣＧＩ処理部へ転送し、
前記ＣＧＩ処理部は、前記ＨＴＴＰサーバから受信したアクセス要求に含まれるコンテンツＩＤおよびユーザＩＤと、前記管理情報と、に基づいて、当該コンテンツＩＤに対応するコンテンツへのアクセスを許可するかどうかを判断し、
前記アクセス要求が、コンテンツデータベースへの、コンテンツの登録要求またはコンテンツ格納先情報の登録要求であるコンテンツ更新要求の場合、
前記ＣＧＩ処理部は、
前記コンテンツＩＤに対応するコンテンツ毎のアクセスレベルおよび前記ユーザＩＤに対応するユーザ毎のアクセスレベルに基づいて、前記コンテンツ更新要求に応じるかどうかを判断し、応じると判断した場合、当該ユーザＩＤのユーザから受け取った、コンテンツまたはコンテンツ格納先情報と、コンテンツに関する各種情報を含んだコンテンツ付帯データと、を前記コンテンツデータベースへ格納し、また、コンテンツ更新要求に含まれているコンテンツＩＤおよびコンテンツのバージョン情報に基づいて、ユーザから受け取ったコンテンツまたはコンテンツ格納先情報が示す格納先に格納されたコンテンツを一意に示すローカルコンテンツＩＤを生成し、当該ローカルコンテンツＩＤおよび前記コンテンツ更新要求に含まれているコンテンツＩＤを前記管理情報データベースへ格納し、
さらに、ユーザから受け取ったコンテンツまたはコンテンツ格納先情報が示す格納先に格納されたコンテンツが、既存のコンテンツである元コンテンツを改版して作成されたものである場合、前記元コンテンツと改定して作成されたコンテンツとの関係を示す依存関係情報、を当該改定して作成されたコンテンツのコンテンツ付帯データに基づいて生成し、さらに、当該生成した依存関係情報を、当該改定して作成されたコンテンツのローカルコンテンツＩＤと対応付けて前記管理情報データベースへ格納することを特徴とするコンテンツサーバシステム。
【請求項２】
前記ＣＧＩ処理部は、前記コンテンツＩＤに対応するコンテンツへのアクセスを許可する場合、さらに、当該コンテンツＩＤ、前記ユーザＩＤおよび前記管理情報に基づいて、その後に実行する処理を決定することを特徴とする請求項１に記載のコンテンツサーバシステム。
【請求項３】
前記ＣＧＩ処理部は、さらに、前記コンテンツ付帯データに基づいて前記管理情報データベースを更新することを特徴とする請求項１または２に記載のコンテンツサーバシステム。
【請求項４】
前記ＣＧＩ処理部は、前記コンテンツ付帯データに含まれるステータス情報および更新日時情報に基づいて前記依存関係情報を生成することを特徴とする請求項１、２または３に記載のコンテンツサーバシステム。
【請求項５】
前記アクセス要求が、コンテンツデータベースに格納されたコンテンツの読み出し要求を示す場合、
前記ＣＧＩ処理部は、前記コンテンツＩＤに基づいて特定されるコンテンツ毎のアクセスレベルおよび前記ユーザＩＤに基づいて特定されるユーザ毎のアクセスレベルに基づいて、前記コンテンツ読み出し要求に応じるかどうかを判断し、応じると判断した場合、前記ユーザＩＤのユーザに対して許可するアクセス許可範囲を当該コンテンツ毎のアクセスレベルおよび当該ユーザ毎のアクセスレベルに基づいて決定することを特徴とする請求項１〜４のいずれか一つに記載のコンテンツサーバシステム。
【請求項６】
前記管理情報データベースが、コンテンツデータベースに格納されたコンテンツおよびコンテンツデータベースに格納されたコンテンツ格納先情報が示す格納先に格納されたコンテンツ、に付与された各コンテンツが格納されたデータベースにおけるユニークなローカルコンテンツＩＤと、関連のあるコンテンツ同士の互いの依存関係を示す依存関係情報と、を格納し、
前記アクセス要求が、コンテンツデータベースに格納されたコンテンツの読み出し要求を示す場合、
前記ＣＧＩ処理部は、前記コンテンツ読み出し要求に含まれているコンテンツＩＤおよびコンテンツのバージョン情報により特定されるコンテンツに対応するローカルコンテンツＩＤを、前記依存関係情報とコンテンツの更新日時情報とに基づいて特定し、当該特定したローカルコンテンツＩＤに対応するコンテンツ毎のアクセスレベルおよび前記ユーザＩＤに対応するユーザ毎のアクセスレベルに基づいて、前記コンテンツ読み出し要求に応じるかどうかを判断することを特徴とする請求項５に記載のコンテンツサーバシステム。
【請求項７】
前記管理情報データベースが、さらに、各コンテンツのコンテンツＩＤを格納し、
前記ＣＧＩ処理部は、前記コンテンツ読み出し要求に応じる場合、当該コンテンツＩＤ、前記ローカルコンテンツＩＤおよび前記依存関係情報に基づいて、前記コンテンツ読み出し要求が示すコンテンツの検索および読み出しを行うことを特徴とする請求項６に記載のコンテンツサーバシステム。
【請求項８】
前記アクセス要求が、前記コンテンツデータベースに格納されたコンテンツまたは当該コンテンツデータベースに格納された情報が示す格納先に格納されたコンテンツのリスト表示要求を示す場合、
前記ＣＧＩ処理部は、前記ユーザＩＤに対応するユーザ毎のアクセスレベルに基づいて、前記コンテンツリスト表示要求に応じるかどうかを判断し、応じると判断した場合、さらに、前記コンテンツデータベースに格納されたコンテンツ付帯データの中から前記ユーザＩＤのユーザが有するアクセスレベルでアクセス可能なコンテンツのコンテンツ付帯データを取得し、当該取得したコンテンツ付帯データに基づいてコンテンツリストを生成して表示することを特徴とする請求項１〜７のいずれか一つに記載のコンテンツサーバシステム。
【請求項９】
前記コンテンツ付帯データが対応するコンテンツの検索処理で利用する検索キーワードを含み、
前記コンテンツリスト表示要求に検索キーワードが含まれている場合、
前記ＣＧＩ処理部は、前記コンテンツリスト表示要求に含まれている検索キーワードに基づいて前記取得したコンテンツ付帯データの選定を行い、当該選定したコンテンツ付帯データに基づいてコンテンツリストを生成することを特徴とする請求項８に記載のコンテンツサーバシステム。
【請求項１０】
各ユーザを所定のルールに従いグループ化し、
前記ユーザ毎のアクセスレベルとして、同じグループに属するユーザには同じアクセスレベルを付与して管理することを特徴とする請求項１〜９のいずれか一つに記載のコンテンツサーバシステム。
【請求項１１】
前記管理情報データベースおよび前記コンテンツデータベースが、前記ＣＧＩ処理部と直接接続されているか、または、信頼性の高いネットワークを介して前記ＣＧＩ処理部と接続されていることを特徴とする請求項１〜１０のいずれか一つに記載のコンテンツサーバシステム。
【請求項１２】
前記コンテンツデータベースを複数備え、コンテンツを分散管理することを特徴とする請求項１〜１１のいずれか一つに記載のコンテンツサーバシステム。
【請求項１３】
前記ＨＴＴＰサーバ、前記コンテンツデータベース、前記管理情報データベースおよび前記ＣＧＩ処理部により構成された基本構成ブロックを複数備えることを特徴とする請求項１〜１２のいずれか一つに記載のコンテンツサーバシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット等の外部ネットワークを介して接続されたユーザに対して提供するコンテンツ（データファイル）を安全に管理するコンテンツサーバシステムに関する。
【背景技術】
【０００２】
外部ネットワークを介してユーザへ提供するコンテンツをＷｅｂベースで管理する現在のシステムでは、ユーザがコンテンツ（ファイル）にアクセスする際に、サーバ内でのファイル位置としてＵＲＬ（Uniform  Resource  Locator）を使用している。
【０００３】
ここで、従来のシステムでは、セキュリティの確保のため、ファイルや情報の管理を集中させるか別サーバをたてて別々の認証およびファイルシステムを用意して独立させて運用している（たとえば下記特許文献１）。また、同一の管理主体により、同一インタフェースのサーバあるいは同種のサーバを集中して管理することによりセキュリティを確保しているケースもある。
【０００４】
【特許文献１】特開２００１−３０６５２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来の技術では、以下に示すような課題が存在する。
【０００６】
まず、Ｗｅｂベースシステム上の課題、すなわち、従来のＷｅｂベースのシステムではファイルにユーザがアクセスする際に、サーバ内でのファイル位置とＵＲＬとの関係が密接に関係しているので、
（１）実際のファイル位置を推定されやすくアクセスの安全性に問題がある。
（２）ファイル位置を変更すると、それに伴ってアクセスするＵＲＬも変更する必要があり管理が煩わしいという問題がある。
（３）ファイルのセキュリティレベルを変更するには登録した全てのユーザのアクセスレベル情報をＨＴＴＰ（Hypertext  Transfer  Protocol）サーバシステムレベルで管理する必要があり管理が煩わしいという問題がある。
【０００７】
また、知的財産管理上の課題、すなわち、ファイルコンテンツは知的財産としての側面も有し、公開性を制御する必要が生じるため、
（４）知的財産の所有者が認める（または信頼している）特定の場所にしかファイルコンテンツを保管できない場合が想定され、この場合には、一箇所に集中して保管することができない。
（５）セキュリティを確保したアクセスを実施する必要がある。
などの問題がある。
【０００８】
さらに、ファイルシステムの物理的課題、すなわち、一元的な管理の行う目的でファイルや情報の管理を集中させると、多くのデータが一箇所（単一のサーバ）に集中するため、
（６）サーバの記憶装置の容量に制約が生じる（大容量のサーバが必要となる）。
（７）サーバ性能として大きな処理性能が要求される。
（８）コンテンツ量が多くアクセス量が頻繁になるとネットワークの負荷（トラフィック）が大きくなるためＨＴＴＰサーバシステムにおけるセキュリティ管理などの機能に支障が生じる可能性がある。
などの問題がある。
【０００９】
本発明は、上記に鑑みてなされたものであって、コンテンツ格納場所を特定され難くしてセキュリティを高め、さらに、柔軟なアクセスレベル設定が実現可能なコンテンツサーバシステムを得ることを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するために、本発明は、ネットワークに接続されたＨＴＴＰサーバと、コンテンツデータベースと、前記コンテンツデータベースが提供可能なコンテンツ毎のアクセスレベルおよび前記コンテンツデータベースへのアクセスが許可されたユーザ毎のアクセスレベル、を含んだ管理情報を格納する管理情報データベースと、前記コンテンツデータベースおよび前記管理情報データベースを管理するＣＧＩ処理部と、を備え、前記コンテンツデータベースに格納されたコンテンツまたは当該コンテンツデータベースに格納された情報が示す格納先に格納されたコンテンツ、へのアクセス要求を前記ネットワーク経由で受信した場合、前記ＨＴＴＰサーバは、受信したアクセス要求を前記ＣＧＩ処理部へ転送し、前記ＣＧＩ処理部は、前記ＨＴＴＰサーバから受信したアクセス要求に含まれるコンテンツＩＤおよびユーザＩＤと、前記管理情報と、に基づいて、当該コンテンツＩＤに対応するコンテンツへのアクセスを許可するかどうかを判断することを特徴とする。
【発明の効果】
【００１１】
この発明によれば、システム内におけるコンテンツの格納場所を特定され難くすることができる、という効果を奏する。また、たとえば、システム内においてすべてのコンテンツの登録や編集が許可されたユーザに対して、他人が作成した著作性を有するコンテンツの編集を規制する、というようなアクセス管理が可能となる。すなわち、従来よりも柔軟にアクセスレベルを設定できる、という効果を奏する。
【発明を実施するための最良の形態】
【００１２】
以下に、本発明にかかるコンテンツサーバシステムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【００１３】
実施の形態１．
図１は、本発明にかかるコンテンツサーバシステムの実施の形態１の構成例を示す図である。本実施の形態のコンテンツサーバシステムは、ネットワーク（Network）に接続されたＨＰＰＴサーバ１と、ＣＧＩ処理部２と、管理情報ＤＢ（データベース）３と、コンテンツＤＢ４と、を備え、ネットワーク経由でユーザ端末と接続される。
【００１４】
ＨＴＴＰサーバ１は、ネットワークを介して接続されたユーザと通信を行い、ユーザから受け取った情報を必要に応じてＣＧＩ処理部２へ転送する。また、ＣＧＩ処理部２からユーザ宛の情報を受け取った場合、その情報を転送する。ＣＧＩ処理部２は、ＣＧＩ（Common  Gateway  Interface）処理を実行する構成であり、ＨＴＴＰサーバ１を介して受け取ったユーザからの各種要求に従った処理を実行する。たとえば、コンテンツＤＢ４に格納されたコンテンツを要求元ユーザへ提供する。管理情報ＤＢ３は、自システムへのアクセスを許可するユーザの情報などを管理情報データとして格納する。コンテンツＤＢ４は、コンテンツファイルデータなどを格納する。
【００１５】
図２は、実施の形態１の管理情報ＤＢ３およびコンテンツＤＢ４の構成例を示す図である。図２に示したように、本実施の形態の管理情報ＤＢ３には、コンテンツ識別情報（コンテンツＩＤ）およびコンテンツ毎のアクセスレベル情報を含んだアクセス管理データと、ユーザ識別情報（ユーザＩＤ）およびユーザ毎のアクセスレベル情報を含んだユーザ管理データと、アクセスを許可するユーザへのアクセス許可範囲を決定する際に使用する共通アクセスレベルデータと、が含まれている。また、コンテンツＤＢ４には、コンテンツの実データと、コンテンツの実データの格納先リンクデータ（以下、単に「格納先データ」と記載する）と、コンテンツの識別情報（コンテンツＩＤ）、登録（更新）日時、作成者、コンテンツのステータスやコンテンツ検索に利用する検索キーワードなどの情報を含んだコンテンツの管理情報であるコンテンツ付帯データと、が含まれている。
【００１６】
そして、上述した構成の本発明にかかるコンテンツサーバシステムは、ネットワークを介して接続しているユーザからのアクセス要求（コンテンツの登録要求、コンテンツの取得要求、など）に応じて、ユーザから受け取ったコンテンツのコンテンツＤＢ４への格納やコンテンツＤＢ４に格納された情報のユーザへの提供（読み出し＋送信）などを行う。なお、ユーザから受け取ったコンテンツをコンテンツＤＢ４とは異なる他のデータベースなどに格納するようにしてもよい。この場合、コンテンツＤＢ４には、コンテンツの格納先を示す情報を格納する。
【００１７】
ここでまず、ユーザからアクセス要求を受けた場合に本発明にかかるコンテンツサーバシステムがアクセス要求に応じるかどうかを判断する際に使用する情報について説明する。
【００１８】
本発明では、アクセス要求に応じるかどうかの判断を、コンテンツについてのアクセスレベル（コンテンツ毎のアクセスレベル情報、以下、コンテンツアクセスレベルと呼ぶ）およびユーザについてのアクセスレベル（ユーザ毎のアクセスレベル情報、以下、ユーザアクセスレベルと呼ぶ）に基づいて行うこととする。以下に、これらのアクセスレベルについて詳しく説明する。
【００１９】
（コンテンツアクセスレベル）
コンテンツアクセスレベルは、特定のコンテンツに対するアクセスの権利を表現するものとする。たとえば、コンテンツ＃１について、アクセスレベルａが別のアクセスレベルｂより等しいか高い場合、アクセスレベルが「ａ」であるユーザはアクセスレベルが「ｂ」であるユーザがコンテンツ＃１に対して実行可能な処理を全て実行可能である。
【００２０】
また、アクセスレベルは束集合で表現できる。たとえば、アクセスレベルａがアクセスレベルｂよりも高いか等しいかを「ａ≧ｂ」と表記する場合、この関係「≧」は記号が意味する通り（部分）順序の性質を満たしている。また、アクセスレベルａとｂの関係を以下のように表記する。
【００２１】
・アクセスレベルａ，ｂを丁度持っているアクセスレベルを「ａＶｂ」と表記する。
・アクセスレベルａとｂの共通のアクセスレベルを「ａΛｂ」と表記する。
・アクセスレベル０で何も権利が無い状態を示す。
【００２２】
また、以下に、アクセスレベルの基本的な関係を示す。
ａ≧０
ａΛ０＝０
ａＶ０＝ａ
ａＶａ＝ａ
ａΛａ＝ａ
ａ≧ｂならば（ａΛｃ）≧（ｂΛｃ）
ａ≧ｂならば（ａＶｃ）≧（ｂＶｃ）
（ａＶｂ）Ｖｃ＝ａＶ（ｂＶｃ）
（ａΛｂ）Λｃ＝ａΛ（ｂΛｃ）
なお、ａ≧ｂ，ａＶｂ＝ａ，ａΛｂ＝ｂは同値のため、Λの表があれば、関係「≧」が成立しているか否かの判断に使用できる。
【００２３】
（ユーザアクセスレベル）
各ユーザに与えられるユーザアクセスレベルは、一般的にはデータベース内に記録されている。なお、ユーザアクセスレベルは動的に変化することもあり得る。最も一般的なusrとadminの２つの権限を想定した場合、adminはシステム（グループ）内でのアクセスが全て可能であることを示し、usrはシステム（グループ）内で通常ユーザが出来るアクセス内容を示すといった形で表現されることが多い。もちろん「admin≧usr」である。usrのレベルを数種類に分けることやユーザ毎に異なるアクセスレベルを与えることも可能である。以下に、具体的な例を用いて説明する。
【００２４】
前提条件として、システム内のアクセスの権利として次式（１）が存在しているものとする。
ａ(ｉ)＝＜コンテンツｉの表紙表示の権利＞
ｂ(ｉ)＝＜コンテンツｉの表紙修正の権利＞
ｃ(ｉ)＝＜コンテンツｉの中身表示の権利＞
ｄ(ｉ)＝＜コンテンツｉの中身編集の権利＞
（ただし、ｉはシステム内のコンテンツＩＤ）                …（１）
【００２５】
たとえば、一般ユーザｕのアクセスレベルをusr1(u)として、このアクセスレベルでは自身が登録したコンテンツは全て編集可能であるが他人が登録したものは閲覧のみ可能とする。すなわち、コンテンツの登録および自身が登録したコンテンツの編集を行う権限と、すべてのコンテンツの閲覧（表紙および内容の閲覧）を行う権限と、を有するものとする。またアクセスレベルがusr2(u)の閲覧ユーザはコンテンツの表紙および内容の閲覧権限のみを有し、コンテンツの管理操作（登録および編集）権限は有しないものとする。また、アクセスレベルがusr3(u)の制限ユーザは各コンテンツの表紙の閲覧権限だけを有するものとする。この場合、それぞれのユーザのアクセスレベルは次式（２）のように表現できる。
【００２６】
usr1(u)＝Ｖ｛ｂ(ｉ)Ｖｄ(ｉ)：ｉはユーザｕが登録したコンテンツのＩＤ｝Ｖ
Ｖ｛ａ(ｉ)Ｖｃ(ｉ)：ｉはシステム内のコンテンツのＩＤ｝
usr2(u)＝Ｖ｛ａ(ｉ)Ｖｃ(ｉ)：ｉはシステム内のコンテンツのＩＤ｝
usr3(u)＝Ｖ｛ａ(ｉ)：ｉはシステム内のコンテンツのＩＤ｝
admin  ＝Ｖ｛ａ(ｉ)Ｖｂ(ｉ)Ｖｃ(ｉ)Ｖｄ(ｉ)：ｉはシステム内のコンテンツＩＤ｝                                                              …（２）
【００２７】
また、便宜的にグループgrpでアクセスレベルstatを持つことをgrp:statと表記する。特例として、adminという特別なグループがあり、このグループのadmin権限を有するユーザならばシステム全体での全てのアクセスが可能になる。
【００２８】
なお、
Ω  ＝｛ａ｜ａはシステム内のアクセスの権利｝
Ωgrp＝｛ａ｜ａはグループgrp内のアクセスの権利｝
とした場合、
admin:admin＝ＶΩ
grp:admin＝ＶΩgrp
admin:admin≧grp:admin≧grp:usr
の関係が成立する。
【００２９】
（コンテンツのアクセスレベルと確認）
たとえば、一般のユーザが有するアクセス権がｘ、コンテンツに設定されているアクセスレベルがｙの場合、このユーザがアクセスできるアクセスレベルをｘΛｙとする。さらに、通常はその時点で必要最小限のアクセスで制約を受けることになり、例えば、閲覧（コンテンツ取得）を要求する場合は「（ｘΛｙ）Λ＜閲覧の権利＞」，登録を要求する場合は「（ｘΛｙ）Λ＜登録の権利＞」が実際のアクセスレベルになる。この場合、便宜的に、「閲覧の権利に制約したアクセスレベル」や「登録の権利に制約したアクセスレベル」と呼ぶことにする。
【００３０】
また、「ｘΛｙ＝０」は、アクセスする権限を全く有しない場合を示し、「ｘΛｙ＝ｙ」は、コンテンツの全てアクセス権限を有している場合を示す。
【００３１】
そして、本発明にかかるコンテンツサーバシステムの管理情報ＤＢ３には、上記図２でも示したように、ユーザがコンテンツへアクセス可能かどうかを判断するために使用する情報として、ユーザ毎のアクセスレベル情報、コンテンツ毎のアクセスレベル情報および共通アクセスレベルデータが格納されている。
【００３２】
つづいて、本発明にかかるコンテンツサーバシステムの実施の形態１の詳細動作を図面に基づいて説明する。まず、コンテンツサーバシステムへコンテンツを登録する（新規登録および更新登録の双方を含む）場合の動作について、図３を参照しながら説明する。なお、図３は、実施の形態１のコンテンツサーバシステムへコンテンツを登録する場合の動作の一例を示すフローチャートである。
【００３３】
ＣＧＩ処理部２は、コンテンツの登録要求（メッセージ）をＨＴＴＰサーバ１経由で受信したかどうかを監視しており、コンテンツ登録要求を受信した場合（ステップＳ１１，Ｙｅｓ）、コンテンツ登録要求を送信したユーザ（以下、要求元ユーザと呼ぶ）の認証処理を行う（ステップＳ１２）。たとえば、要求元ユーザのユーザＩＤが管理情報ＤＢ３内のユーザ管理データに含まれるユーザ情報に登録されているかどうかを確認し、登録されている場合、アクセスが許可されたユーザであると判断して処理を継続する。なお、登録されていない場合には、処理を終了する。
【００３４】
そして、認証処理の結果、処理を継続すると判断した場合、ＣＧＩ処理部２は、アクセス管理データおよびユーザ管理データに基づいて、要求元ユーザが、登録要求が示すコンテンツの登録を許可されたユーザかどうかを判断する（ステップＳ１３）。具体的には、要求元ユーザのユーザＩＤと、受信したコンテンツ登録要求に含まれている、登録対象コンテンツ（ユーザが登録しようとしているコンテンツ）のコンテンツＩＤと、をキーとして管理情報ＤＢ３を検索し、ユーザＩＤに対応する（ユーザ管理データ内の）ユーザ毎のアクセスレベル情報と、コンテンツＩＤに対応する（アクセス管理データ内の）コンテンツ毎のアクセスレベル情報を取得する。そして、ユーザ毎のアクセスレベル情報およびコンテンツ毎のアクセスレベル情報に基づいて、ユーザにコンテンツを登録する権限が与えられているかどうかを確認する。
【００３５】
たとえば、コンテンツ毎のアクセスレベルが、すべてのユーザに対して登録処理を許可することを示す場合、ＣＧＩ処理部２は、ユーザ毎のアクセスレベルが登録処理を許可することを示していれば（要求元ユーザが登録を行う権限を有していれば）、要求元ユーザがコンテンツの登録権限を有すると判断する。また、コンテンツ毎のアクセスレベルが、一部のユーザに対して登録処理を許可することを示す場合、ＣＧＩ処理部２は、ユーザ毎のアクセスレベルが登録処理を許可することを示していても（要求元ユーザが登録を行う権限を有していても）、要求元ユーザが前記「コンテンツ毎のアクセスレベルが示す一部のユーザ」に含まれていなければ、要求元ユーザがコンテンツの登録権限を有しないと判断する。なお、コンテンツの新規登録を行う場合には、ユーザ毎のアクセスレベル情報のみに基づいて確認を行う。すなわち、ユーザ毎のアクセスレベルとしてコンテンツを登録する権限が与えられていれば、権限が与えられたユーザであると判断する。
【００３６】
そして、コンテンツを登録する権限が与えられていると判断した場合（ステップＳ１３，Ｙｅｓ）、ＣＧＩ処理部２は、処理を継続する。一方、権限が与えられていないと判断した場合は処理を終了する（ステップＳ１３，Ｎｏ）。
【００３７】
また、ステップＳ１３では、以下の処理を実行することにより要求元ユーザがコンテンツ登録を許可されているかどうかを判断するようにしてもよい。すなわち、コンテンツ登録を許可するかどうかを判断可能な承認者を予め決定し、その連絡先としてメールアドレスをアクセス管理データへ格納しておく。そして、コンテンツ登録要求を受信した場合、ＣＧＩ処理部２は、コンテンツＩＤに対応した承認者の連絡先を管理情報ＤＢ３から取得し、取得した連絡先へ要求元ユーザユーザＩＤおよびコンテンツＩＤを含んだ電子メールを送信する。承認者は、電子メールを受け取った場合、それに含まれているユーザＩＤによる認証処理を行った上でコンテンツ登録の可否を判断し、判断結果を含んだ電子メールをＣＧＩ処理部２へ返信する。ＣＧＩ処理部２は、返信されてきた電子メールの内容が登録を許可する旨を示す場合、処理を継続する。
【００３８】
ステップＳ１３で処理を継続すると判断した場合、ＣＧＩ処理部２は、管理情報ＤＢ３内のアクセス管理データに対して、登録しようとしているコンテンツのコンテンツＩＤおよびそのアクセス条件（コンテンツ毎のアクセスレベル）を格納する（ステップＳ１４）。なお、アクセス条件は、要求元ユーザにより予め決定され、コンテンツ登録要求またはそれに続いて送信するメッセージなどにより送信されてくる情報である。
【００３９】
最後に、ＣＧＩ処理部２は、ユーザから受け取った情報（コンテンツ（実データ）またはコンテンツの格納先データと、コンテンツ付帯データ）をコンテンツＤＢ４へ格納する（ステップＳ１５）。
【００４０】
以上がユーザから受け取った情報をコンテンツサーバシステムへ登録する場合の動作であるが、次に、コンテンツサーバシステムに登録されている情報をユーザへ提供する場合の動作について、図４を参照しながら説明する。なお、図４は、実施の形態１のコンテンツサーバシステムに登録された情報をユーザに提供する場合の動作の一例を示すフローチャートである。
【００４１】
ＣＧＩ処理部２は、コンテンツの取得要求（メッセージ）をＨＴＴＰサーバ１経由で受信したかどうかを監視しており、コンテンツ取得要求を受信した場合（ステップＳ２１，Ｙｅｓ）、コンテンツ取得要求を送信したユーザ（以下、要求元ユーザと呼ぶ）の認証処理を行う（ステップＳ２２）。なお、具体的な動作は、コンテンツを登録する場合の動作における認証処理（図３のステップＳ１２を参照）と同様である。
【００４２】
そして、認証処理の結果、処理を継続すると判断した場合、ＣＧＩ処理部２は、アクセス管理データおよびユーザ管理データに基づいて、要求元ユーザが、取得対象コンテンツ（ユーザが取得を望んでいるコンテンツ）の取得（閲覧）が許可されたユーザかどうかを判断する（ステップＳ２３）。具体的には、要求元ユーザのユーザＩＤと、受信したコンテンツ取得要求に含まれている、取得対象コンテンツのコンテンツＩＤと、をキーとして管理情報ＤＢ３を検索し、ユーザＩＤに対応する（ユーザ管理データ内の）ユーザ毎のアクセスレベル情報と、コンテンツＩＤに対応する（アクセス管理データ内の）コンテンツ毎のアクセスレベル情報を取得する。そして、ユーザ毎のアクセスレベル情報およびコンテンツ毎のアクセスレベル情報に基づいて、ユーザにコンテンツを取得する権限が与えられているかどうかを確認する。
【００４３】
コンテンツを取得する権限が与えられていると判断した場合（ステップＳ２３，Ｙｅｓ）、ＣＧＩ処理部２は、処理を継続する。一方、権限が与えられていないと判断した場合は処理を終了する（ステップＳ２３，Ｎｏ）。
【００４４】
また、ステップＳ２３では、以下の処理を実行することにより要求元ユーザがコンテンツへのアクセスを許可されているかどうかを判断するようにしてもよい。すなわち、コンテンツへのアクセスを許可するかどうかを判断可能な承認者を予め決定し、その連絡先としてメールアドレスをアクセス管理データへ格納しておく。そして、コンテンツ取得を受信した場合、ＣＧＩ処理部２は、コンテンツＩＤに対応した承認者の連絡先を管理情報ＤＢ３から取得し、取得した連絡先へ要求元ユーザユーザＩＤおよびコンテンツＩＤを含んだ電子メールを送信する。承認者は、電子メールを受け取った場合、それに含まれているユーザＩＤによる認証処理を行った上でコンテンツへのアクセスの可否を判断し、判断結果を含んだ電子メールをＣＧＩ処理部２へ返信する。ＣＧＩ処理部２は、返信されてきた電子メールの内容がアクセスを許可する旨を示す場合、処理を継続する。
【００４５】
ステップＳ２３で処理を継続すると判断した場合、ＣＧＩ処理部２は、上記ユーザ毎のアクセスレベル情報およびコンテンツ毎のアクセスレベル情報に基づいて、アクセス範囲を特定する（ステップＳ２４）。さらに、特定したアクセス範囲に含まれる情報（コンテンツの実データまたは格納先データ）をコンテンツＤＢ４から取得し、ＨＴＴＰサーバ１経由で要求元ユーザ宛に送信する（ステップＳ２５）。
【００４６】
以上のステップＳ２１〜Ｓ２５に示した処理がユーザからコンテンツの取得要求を受け取った場合に実行する動作（コンテンツサーバシステムに登録されている情報をユーザへ提供する場合の動作）である。
【００４７】
また、本発明にかかるコンテンツサーバシステムでは、ユーザからの要求に応じて、コンテンツＤＢ４に格納されているコンテンツのリストを表示する（コンテンツ付帯データをリスト化して表示する）機能を有している。そこで、ユーザからコンテンツリストの表示要求を受けた場合の動作を、図５に基づいて、以下に説明する。なお、図５は、コンテンツリストを表示する場合の動作の一例を示す図である。
【００４８】
ＣＧＩ処理部２は、コンテンツリストの表示要求（メッセージ）をＨＴＴＰサーバ１経由で受信したかどうかを監視しており、コンテンツリストの表示要求（以下、リスト表示要求と呼ぶ）を受信した場合（ステップＳ３１，Ｙｅｓ）、リスト表示要求を送信したユーザ（以下、要求元ユーザと呼ぶ）の認証処理を行う（ステップＳ３２）。なお、具体的な動作は、コンテンツを登録する場合の動作における認証処理（図３のステップＳ１２を参照）と同様である。
【００４９】
そして、認証処理の結果、処理を継続すると判断した場合、ＣＧＩ処理部２は、要求元ユーザのユーザＩＤをキーとして管理情報ＤＢ３の（ユーザ管理データ内の）ユーザ毎のアクセスレベル情報を検索することにより要求元ユーザが有するアクセス権限を認識し、認識結果に基づいてリスト表示が可能かどうかを判断する（ステップＳ３３）。表示不可能と判断した場合（ステップＳ３３，Ｎｏ）、処理を終了する。一方、表示可能と判断した場合（ステップＳ３３，Ｙｅｓ）、コンテンツ管理ＤＢ４内のコンテンツ付帯データを検索し、要求元ユーザが有するアクセス権限で閲覧可能なコンテンツの付帯データを取得する（ステップＳ３４）。そして、取得した付帯データをリスト化して表示する。または、取得した付帯データからさらに必要な情報を抽出し、リスト化して表示する（ステップＳ３５）。
【００５０】
なお、ユーザは、リスト表示要求を送信するにあたり、検索条件を指定することが可能である。たとえば、コンテンツの更新（登録）日時やコンテンツのカテゴリ、登録者、など、コンテンツ付帯データに含まれる情報について、条件を指定可能である。したがって、要求元ユーザから検索条件を受信した場合、上記ステップＳ３４では、取得した検索条件に合致したコンテンツ付帯データを抽出する。
【００５１】
このように、本実施の形態では、ＣＧＩ処理部がコンテンツの管理を行い、外部のユーザから受信したコンテンツ登録要求やコンテンツへのコンテンツ取得に応じた処理を行うこととし、ＨＴＴＰサーバはユーザとＣＧＩ処理部との間でやりとりされる情報を中継することとした。これにより、外部のユーザからコンテンツへ直接アクセスすることがなくなり、セキュリティを確保したコンテンツへのアクセスを実現できる。また、ＨＴＴＰサーバの負荷を軽減することができる。また、コンテンツ毎およびユーザ毎にアクセスレベルを設定し、これら二つのアクセスレベルに基づいて、各コンテンツへのアクセスを許可するかどうかを判断することとしたので、たとえば、システム内においてすべてのコンテンツの登録や編集が許可されたユーザに対して、他人が作成した著作性を有するコンテンツの編集を規制する、というようなアクセス管理が可能となる。すなわち、従来よりも柔軟なアクセスレベル管理を実現できる。
【００５２】
実施の形態２．
つづいて、実施の形態２のコンテンツサーバシステムについて説明する。一般的に、コンテンツは様々な要因により改版され、時間の経過とともに複数の版（バージョン）が存在するようになる。コンテンツサーバがバージョンの異なる複数のコンテンツを管理する方法としては、たとえば、コンテンツＩＤの他にバージョン情報を用いて管理する方法が存在する。一方で、バージョン情報を利用せずに、コンテンツＩＤだけで管理することも可能である。すなわち、同じコンテンツであってもバージョンが異なる場合には、異なるコンテンツＩＤを付与して管理する方法も存在する。
【００５３】
ここで、ユーザが所望のコンテンツにアクセスする場合について考えてみると、バージョンについて特に何も意識せずに手動で取り出そうとする場合、最新版を要求する場合が多い。また、バージョンについて特に意識せずに、かつて取り出そうとしてリンクを作成して放置しておき、その後改めて取り出そうとする場合は、元のままの版を要求する場合が多い。
【００５４】
これに対して、バージョンについて意識しつつ目的のコンテンツを取得する場合には、最新のバージョンを指定して取得する、一つ前のバージョンを指定して取得する、または、ある日時での最新版を指定して目的のコンテンツを取得する、という場合が多い。すなわち、ユーザは、以下に示すような条件を指定してコンテンツを取得すると考えられる。
（１）「コンテンツＩＤ＋＜バージョン番号＞」
（２）「コンテンツＩＤ＋最新版」
（３）「コンテンツＩＤ＋最新の一つ前の版」
（４）「コンテンツＩＤ＋＜日時＞以前の最新版」
【００５５】
これらは、バージョン情報を利用してコンテンツを管理している場合を想定した条件指定方法であるが、上述したように、バージョン情報を利用せずに管理する方法も存在する。そのため、コンテンツサーバでは、バージョン情報を利用せずにバージョン管理を行っている状態で、ユーザからバージョン情報を用いたコンテンツ指定を受けた場合に、指定されたバージョンを正しく特定して提供する必要がある。
【００５６】
そこで、本実施の形態では、システム内部においてバージョン情報を利用せずにコンテンツの管理を行うコンテンツサーバシステムについて説明する。なお、本実施の形態のコンテンツサーバシステムの構成は、実施の形態１のコンテンツサーバシステム（図１参照）と同様である。
【００５７】
また、コンテンツ間には、以下の様にバージョン依存関係が定められる。すなわち、依存関係は一般には複数存在し、改版を重ねるにつれて下記のようなバージョン依存関係の組合せの鎖（ステータスとタイムスタンプからなる情報）ができる。そのため、本実施の形態のコンテンツサーバシステムは、１つのバージョン依存関係を１つのレコードとしてテーブルに登録することによりコンテンツのバージョンを管理する。たとえば、改版により生成されたコンテンツの元となった（ベースとした）コンテンツのＩＤを版管理データとして、改版により生成されたコンテンツのＩＤと対応付けて管理情報ＤＢ２で管理する。
【００５８】
（例１）コンテンツ（ＩＤ２）がコンテンツ（ＩＤ１）を改版して作成された場合。
ＩＤ１  →（をベースにした）→  ＩＤ２
（日時１）                      （日時２）
（例２）コンテンツ（ＩＤ３）がコンテンツ（ＩＤ１）とコンテンツ（ＩＤ２）とを元に改版して作成された場合。
ＩＤ１  →（をベースにした）→  ＩＤ３
（日時１）                      （日時３）
ＩＤ２  →（をベースにした）→
（日時２）
（例３）コンテンツ（ＩＤ２）がコンテンツ（ＩＤ１）を元に改版して作成され、かつコンテンツ（ＩＤ３）がコンテンツ（ＩＤ１）を元に改版して作成された場合。
ＩＤ１  →（をベースにした）→  ＩＤ２
（日時１）                      （日時２）
→（をベースにした）→  ＩＤ３
（日時３）
【００５９】
つづいて、詳細動作を図面に基づいて説明する。ここで、詳細説明を開始する前に、本実施の形態のコンテンツサーバシステムが備える管理情報ＤＢ３が保持しているデータについて説明する。本実施の形態の管理情報ＤＢ３は、図６に示したように実施の形態１の管理情報ＤＢ３が保持しているアクセス管理データ，ユーザ管理データ，共通アクセスレベルデータに加えて、コンテンツのバージョンを管理するための版管理データを保持している。なお、コンテンツＤＢ４は、実施の形態１と同一種類のデータを保持している。
【００６０】
次に、本実施の形態のコンテンツサーバシステムへ情報を登録する場合の動作について、図７を参照しながら説明する。なお、図７は、実施の形態２のコンテンツサーバシステムへコンテンツを登録する場合の動作の一例を示すフローチャートであり、上述した実施の形態１のコンテンツ登録と同じ動作については同一のステップ番号を付与している。ここでは、実施の形態１と異なる処理についてのみ説明する。
【００６１】
実施の形態１とは異なる処理を実行するステップＳ１３ａでは、ＣＧＩ処理部２は、まず、受信したコンテンツ登録要求に含まれている、登録対象コンテンツのコンテンツＩＤおよびコンテンツのバージョン情報に基づいて、コンテンツサーバシステム内部で使用するローカルのコンテンツＩＤと、管理情報ＤＢ３へ版管理データとして登録するバージョン依存関係の情報と、を生成する。なお、コンテンツのバージョン情報が含まれていない（省略された）場合には、たとえば、最新バージョンであるとみなして処理を行う。そして、生成したローカルコンテンツＩＤおよびバージョン依存関係の情報から特定される、コンテンツ毎のアクセスレベル情報と、要求元ユーザのユーザＩＤに対応するユーザ毎のアクセスレベル情報と、に基づいて、ユーザにコンテンツを登録する権限が与えられているかどうかを確認する。
【００６２】
さらに、ステップＳ１４ａでは、管理情報ＤＢ３に対して、登録しようとしているコンテンツのコンテンツＩＤ、これに対応するローカルコンテンツＩＤ、アクセス条件（コンテンツ毎のアクセスレベル）および版管理データ（バージョン依存関係の情報）を格納する。
【００６３】
次に、本実施の形態のコンテンツサーバシステムに登録されている情報をユーザへ提供する場合の動作について、図８を参照しながら説明する。なお、図８は、実施の形態２のコンテンツサーバシステムに登録された情報をユーザに提供する場合の動作の一例を示すフローチャートであり、上述した実施の形態１のコンテンツアクセスと同じ動作については同一のステップ番号を付与している。ここでは、実施の形態１と異なる処理についてのみ説明する。また、ユーザからはバージョンを指定する情報（コンテンツのバージョン情報）が含まれたコンテンツ取得要求を受信するものとする。
【００６４】
実施の形態１とは異なる処理を実行するステップＳ２３ａでは、ＣＧＩ処理部２は、まず、受信したコンテンツ取得要求に含まれている、取得対象コンテンツのコンテンツＩＤおよびコンテンツのバージョン情報と、管理情報ＤＢ３内の版管理データに含まれる上記バージョン依存関係の情報と、コンテンツの作成（更新）日時情報と、に基づいて、ユーザが要求しているバージョンのコンテンツに対応するローカルコンテンツＩＤ（コンテンツサーバシステム内部で使用しているローカルのコンテンツＩＤ）を特定する。次に、上記受信したコンテンツ取得要求に含まれている要求元ユーザのユーザＩＤおよび当該特定したローカルコンテンツＩＤをキーとして管理情報ＤＢ３を検索し、ユーザＩＤに対応する（ユーザ管理データ内の）ユーザ毎のアクセスレベル情報と、ローカルコンテンツＩＤに対応する（アクセス管理データ内の）コンテンツ毎のアクセスレベル情報に基づいて、ユーザにコンテンツを取得する権限が与えられているかどうかを確認する。
【００６５】
このように、本実施の形態では、ユーザから受け取ったコンテンツのバージョンを指定する情報が自システムにおけるバージョン管理フォーマットに合致しない場合、受け取ったコンテンツＩＤおよびバージョンを指定する情報に基づいて、特定コンテンツの特定バージョンを一意に示すローカルコンテンツＩＤを特定し、特定したローカルコンテンツＩＤに基づいてコンテンツの検索を行うこととした。これにより、自システムにおける方式と異なる方式でバージョン指定を行うユーザに対しても正しくバージョンを認識して、要求されたコンテンツを提供することができる。
【００６６】
実施の形態３．
つづいて、実施の形態３について説明する。上述した実施の形態１および２では、ユーザ毎にアクセスレベルを付与してアクセス制限等を行うコンテンツサーバシステムについて説明したが、ユーザを複数のグループに予めグループ化し、グループ毎にアクセスレベルを付与するようにしてもよい。
【００６７】
本実施の形態においても、上述した実施の形態１と同様に、各ユーザは、コンテンツサーバシステムを利用して、コンテンツの登録、取得およびリスト表示（付帯データのリスト表示）を行うことが可能である。なお、アクセスレベルがグループ毎に付与される以外は上記実施の形態１または２と同様であるため、各動作（コンテンツ登録動作，コンテンツ取得動作，リスト表示動作）の説明は省略する。
【００６８】
実施の形態４．
つづいて、実施の形態４について説明する。上述した実施の形態のコンテンツサーバシステムでは、ユーザ管理データとアクセス管理データを同一のデータベースへ格納し、またＣＧＩ処理部が単一のコンテンツサーバを管理している場合の例について説明したが、たとえば、図９に示したように、ユーザ管理データとアクセス管理データを物理的に分けられた異なるデータベース（ユーザ管理ＤＢ，アクセス管理ＤＢ）へ格納し、また、物理的に分けられた複数のコンテンツＤＢにコンテンツを分散して格納するようにしてもよい。なお、複数のコンテンツＤＢにコンテンツを分散して格納する構成とする場合、コンテンツの実データを格納したコンテンツＤＢ以外のコンテンツＤＢには当該コンテンツの格納先情報を格納する。これにより、コンテンツの検索速度を高めることができる。また、ＣＧＩ処理部と各データベースとを、信頼性の高いネットワーク（ＳＳＬ：Secure  Sockets  Layerなど）で結合することによりセキュリティを確保する。
【００６９】
また、図１０に示したように、のＨＴＴＰサーバとＣＧＩ処理部、管理情報ＤＢおよびコンテンツＤＢの組合せを複数備えた構成にすることも可能である。
【００７０】
このように、データベースに格納する各種情報やコンテンツを物理的に異なる場所へ格納して管理することが可能であり、この場合も上述した実施の形態と同様の効果が得られる。また、管理可能なコンテンツ量（データ量）を増加させることができ、さらに、システムを構成する各装置の負荷を分散させることができる。
【産業上の利用可能性】
【００７１】
以上のように、本発明にかかるコンテンツサーバシステムは、外部ネットワークに属するユーザへ提供するコンテンツを管理するサーバシステムに有用であり、特に、コンテンツ毎にアクセスレベルを個別に設定してセキュリティ管理を行う場合に適している。
【図面の簡単な説明】
【００７２】
【図１】本発明にかかるコンテンツサーバシステムの実施の形態１の構成例を示す図である。
【図２】実施の形態１の管理情報ＤＢおよびコンテンツＤＢの構成例を示す図である。
【図３】実施の形態１のコンテンツサーバシステムへコンテンツを登録する場合の動作の一例を示すフローチャートである。
【図４】実施の形態１のコンテンツサーバシステムに登録された情報をユーザに提供する場合の動作の一例を示すフローチャートである。
【図５】コンテンツリストを表示する場合の動作の一例を示す図である。
【図６】実施の形態２の管理情報ＤＢおよびコンテンツＤＢの構成例を示す図である。
【図７】実施の形態２のコンテンツサーバシステムへコンテンツを登録する場合の動作の一例を示すフローチャートである。
【図８】実施の形態２のコンテンツサーバシステムに登録された情報をユーザに提供する場合の動作の一例を示すフローチャートである。
【図９】実施の形態４のコンテンツサーバシステムの構成例を示す図である。
【図１０】実施の形態４のコンテンツサーバシステムの別の構成例を示す図である。
【符号の説明】
【００７３】
１  ＨＴＴＰサーバ
２  ＣＧＩ処理部
３  管理情報ＤＢ（データベース）
４  コンテンツＤＢ（データベース）
【図１】
0004965420.tif 000002
【図２】
0004965420.tif 000003
【図３】
0004965420.tif 000004
【図４】
0004965420.tif 000005
【図５】
0004965420.tif 000006
【図６】
0004965420.tif 000007
【図７】
0004965420.tif 000008
【図８】
0004965420.tif 000009
【図９】
0004965420.tif 000010
【図１０】
0004965420.tif 000011