(57)【要約】【課題】  ファイルシステムのインタフェースを通して、DBiCであるか否かを容易に確認可能にし、タグのないように不測があれば、その訂正をファイルシステムのインタフェースで可能にする。【解決手段】  本発明は、任意のユーザ端末からDRAG&DROP操作されたファイルが前記センタサーバのストレージ上に蓄積されるものであるとき、ネットワークファイルシステムは、ユーザ端末からファイルを受け付け、ファイルがDBiCを持つか否かを判定し、該ファイルがDBiCを持つ場合には、該DBiCからタグ集合を検索取得し、ファイルのファイル名にタグ集合を追加した新たなファイル名を生成し、該ファイルを新たなファイル名に変更する。【選択図】  図１
2011086256.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザ端末とネットワークファイルシステムが動作するセンタサーバとがネットワークを介して接続されているシステムにおけるネットワークファイルシステムにおけるファイル管理方法であって、
任意のユーザ端末からDRAG&DROP操作されたファイルが前記センタサーバのストレージ上に蓄積されるものであるとき、
前記ネットワークファイルシステムは、
前記ユーザ端末からファイルを受け付け、
前記ファイルがDBiCを持つか否かを判定し、該ファイルがDBiCを持つ場合には、該DBiCからタグ集合を検索取得し、
前記ファイルのファイル名にタグ集合を追加した新たなファイル名を生成し、該ファイルを新たなファイル名に変更する
ことを特徴とするネットワークファイルシステムにおけるファイル管理方法。
【請求項２】
複数のユーザ端末とネットワークファイルシステムが動作するセンタサーバとがネットワークを介して接続されているシステムにおけるネットワークファイルシステムにおけるファイル管理方法であって、
任意のユーザ端末からDRAG&DROP操作されたファイルが前記センタサーバのストレージ上に蓄積されるものであるとき、
前記ファイルネットワークシステムは、
前記ユーザ端末からファイルを受け付け、
前記ファイルのファイル名中にタグ情報が含まれるか否かを判定し、該ファイルのファイル名中にタグ情報が含まれる場合には、該ファイル名からタグ集合を抽出し、
前記ファイルがDBiCを持つか否かを判定し、DBiCを既に持つ場合には、該DBiCに対して先に抽出したタグ集合の各タグを、重複を排除してDBiCに追加し、DBiCを持たない場合は、該ファイルにDBiCを作成し、作成された該DBiCに対して抽出された前記タグ集合の各タグを追加する
ことを特徴とするネットワークファイルシステムにおけるファイル管理方法。
【請求項３】
複数のユーザ端末とネットワークファイルシステムが動作するセンタサーバとがネットワークを介して接続されているシステムにおけるネットワークファイルシステムにおけるファイル管理装置であって、
任意のユーザ端末からDRAG&DROP操作されたファイルを蓄積するストレージと、
前記ユーザ端末からファイルを受け付ける受付手段と、
前記ファイルがDBiCを持つか否かを判定し、該ファイルがDBiCを持つ場合には、該DBiCからタグ集合を検索取得し、該ファイルのファイル名にタグ集合を追加した新たなファイル名を生成し、該ファイルを新たなファイル名に変更するファイル管理手段と、
を有することを特徴とするネットワークファイルシステムにおけるファイル管理装置。
【請求項４】
複数のユーザ端末とネットワークファイルシステムが動作するセンタサーバとがネットワークを介して接続されているシステムにおけるネットワークファイルシステムにおけるファイル管理装置であって、
任意のユーザ端末からDRAG&DROP操作されたファイルを蓄積するストレージと、
前記ユーザ端末からファイルを受け付ける受付手段と、
前記ファイルのファイル名中にタグ情報が含まれるか否かを判定し、該ファイルのファイル名中にタグ情報が含まれる場合には、該ファイル名からタグ集合を抽出し、該ファイルがDBiCを持つか否かを判定し、DBiCを既に持つ場合には、該DBiCに対して先に抽出したタグ集合の各タグを、重複を排除してDBiCに追加し、DBiCを持たない場合は、該ファイルにDBiCを作成し、作成された該DBiCに対して抽出された前記タグ集合の各タグを追加するファイル管理手段と、
を有することを特徴とするネットワークファイルシステムにおけるファイル管理装置。
【請求項５】
請求項３または４に記載のファイル管理装置を構成する各手段としてコンピュータを機能させるためのファイル管理プログラム。
【請求項６】
請求項５に記載のファイル管理プログラムを格納したことを特徴とするコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイル管理方法及び装置及びプログラム及びコンピュータ読み取り可能な記録媒体に係り、特に、画像やブックマークなどのコンテンツのコメント領域や拡張領域内にＤＢ領域を構成して、コンテンツと一緒にＤＢ情報の流通を可能にしたコンテンツ埋め込みＤＢ（DBiC: Database in the content）のタグ情報を管理するためのファイル管理方法及び装置及びプログラム及びコンピュータ読み取り可能な記録媒体に関する。
【背景技術】
【０００２】
従来、コンテンツ埋込ＤＢのタグ情報を管理するために、コンテンツ埋込ＤＢ専用ソフトウェアを立ち上げておき、タグ記入シートを利用してタグ情報の追記を行う方法がある（例えば、特許文献１参照）。
【０００３】
ここで、「タグ」とは、コンテンツに付随するメタデータの一種で、コンテンツの内容を表現するキーワードであり、「ラベル」ということもある。なお、本明細書でいうタグの型は文字列型のみで、日付や氏名といった属性は持たない。
【０００４】
なお、コンテンツはファイルとして生成されているものとする。コンテンツは、多様なメディアデータ、例えば、音声、音楽、画像、映像、フラッシュ、ドキュメント、ベクタ、ショートカットなどであり、一般にファイルと呼ばれるものを指す。
【０００５】
「コンテンツ埋め込みＤＢ」（本明細書では、「DBiC」と略記する）とは、画像やBookmarkなどのコンテンツのコメント領域や拡張領域内にＤＢ領域を構成して、コンテンツと一緒にＤＢ情報の流通（複写や移動）を可能にしたものである（例えば、非特許文献１参照）。
【０００６】
コンテンツ埋め込みＤＢは、ＤＢ領域内にＲＤＢ相当の構造を持つことができ、独自の木状ビューの管理ソフトウェアを使うことで、コンテンツの持つＤＢ情報が外観でき、また、概念上の上下関係のあるような情報の管理なども効率的にできるようになっている。以後、コンテンツ埋め込みＤＢをDBiC (Database in the content)と呼ぶ。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００７−１０４３２６号公報
【非特許文献】
【０００８】
【非特許文献１】情報処理学会論文誌：データベース：Vol. 42 No.SIG 8 (TOD 10)2001 pp. 171-184，赤間浩樹、三井一能、串間和彦：コンテンツ埋込ＤＢと木状ビューの対応を使ったメタデータ管理インタフェースの設計と実装
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、DBiCには、タグ管理に限定したものではないが、それをタグの管理に適用した場合に、以下のような問題があった。
【００１０】
流通してくる（外部から入手した）コンテンツにDBiCが含まれる率は、当初は少ない。そのような状況で、DBiC対応の専用の表示編集ソフトウェアを立ち上げておくことは、端末上のリソースの無駄が多いし、また、コンテンツを入手する都度、専用ソフトウェアを立ち上げて確認することは手間がかかる。
【００１１】
さらに、専用のソフトウェアをインストールすることに対する抵抗感が存在するケースや、専用ソフトウェアの利用方法を習得することに負担を感じるケースが存在する。
【００１２】
これらの理由から、DBiCが普及することに対しての専用ソフトウェアだけによるDBiCの管理はDBiCの普及と流通の阻害要因となっていた。
【００１３】
本発明は、上記の点に鑑みなされたもので、従来のファイルインタフェースを通して、DBiCであるか否かを容易に確認可能にし、DBiCのタグ内容に不足があれば、その訂正をファイルシステムのインタフェースで可能にする。また、ファイルシステムとして、従来のネットワークフォルダの仕組みを活用することで、その処理をネットワーク上で実行可能な仕組みとすることが可能なファイル管理方法及び装置及びプログラム及びコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【課題を解決するための手段】
【００１４】
図１は、本発明の原理を説明するための図である。
【００１５】
本発明（請求項１）は、複数のユーザ端末とネットワークファイルシステムが動作するセンタサーバとがネットワークを介して接続されているシステムにおけるネットワークファイルシステムにおけるファイル管理方法であって、
任意のユーザ端末からDRAG&DROP操作されたファイルがセンタサーバのストレージ上に蓄積されるものであるとき、
ネットワークファイルシステムは、
ユーザ端末からファイルを受け付け（ステップ１）、
ファイルがDBiCを持つか否かを判定し（ステップ２）、該ファイルがDBiCを持つ場合には（ステップ２、Yes）、該DBiCからタグ集合を検索取得し（ステップ３）、
ファイルのファイル名にタグ集合を追加した新たなファイル名を生成し（ステップ４）、該ファイルを新たなファイル名に変更する（ステップ５）。
【００１６】
本発明（請求項２）は、複数のユーザ端末とネットワークファイルシステムが動作するセンタサーバとがネットワークを介して接続されているシステムにおけるネットワークファイルシステムにおけるファイル管理方法であって、
任意のユーザ端末からDRAG&DROP操作されたファイルがセンタサーバのストレージ上に蓄積されるものであるとき、
ファイルネットワークシステムは、
ユーザ端末からファイルを受け付け、
ファイルのファイル名中にタグ情報が含まれるか否かを判定し、該ファイルのファイル名中にタグ情報が含まれる場合には、該ファイル名からタグ集合を抽出し、
ファイルがDBiCを持つか否かを判定し、DBiCを既に持つ場合には、該DBiCに対して先に抽出したタグ集合の各タグを、重複を排除してDBiCに追加し、DBiCを持たない場合は、該ファイルにDBiCを作成し、作成された該DBiCに対して抽出されたタグ集合の各タグを追加する。
【００１７】
図２は、本発明の原理構成図である。
【００１８】
本発明（請求項３）は、複数のユーザ端末とネットワークファイルシステムが動作するセンタサーバとがネットワークを介して接続されているシステムにおけるネットワークファイルシステムにおけるファイル管理装置であって、
任意のユーザ端末からDRAG&DROP操作されたファイルを蓄積するストレージ３１３と、
ユーザ端末からファイルを受け付ける受付手段３１１と、
ファイルがDBiCを持つか否かを判定し、該ファイルがDBiCを持つ場合には、該DBiCからタグ集合を検索取得し、該ファイルのファイル名にタグ集合を追加した新たなファイル名を生成し、ストレージ３１３上の該ファイルを新たなファイル名に変更するファイル管理手段３１２と、を有する。
【００１９】
本発明（請求項４）は、複数のユーザ端末とネットワークファイルシステムが動作するセンタサーバとがネットワークを介して接続されているシステムにおけるネットワークファイルシステムにおけるファイル管理装置であって、
任意のユーザ端末からDRAG&DROP操作されたファイルを蓄積するストレージと、
ユーザ端末からファイルを受け付ける受付手段と、
ファイルのファイル名中にタグ情報が含まれるか否かを判定し、該ファイルのファイル名中にタグ情報が含まれる場合には、該ファイル名からタグ集合を抽出し、該ファイルがDBiCを持つか否かを判定し、DBiCを既に持つ場合には、該DBiCに対して先に抽出したタグ集合の各タグを、重複を排除してDBiCに追加し、DBiCを持たない場合は、ストレージ上の該ファイルにDBiCを作成し、作成された該DBiCに対して抽出されたタグ集合の各タグを追加するファイル管理手段と、を有する。
【００２０】
本発明（請求項５）は、請求項３または４に記載のファイル管理装置を構成する各手段としてコンピュータを機能させるためのファイル管理プログラムである。
【００２１】
本発明（請求項６）は、請求項５に記載のファイル管理プログラムを格納したコンピュータ読み取り可能な記録媒体である。
【発明の効果】
【００２２】
上記のように本発明によれば、コンテンツの中にタグ情報を持つことで、コンテンツと一体で流通するタグ情報を管理する際に、
・DBiCのための専用ソフトウェアを端末にインストールする手間を無くし、セキュリティ上の不安を発生させない。
【００２３】
・DBiCであるか否かを確認するために専用のソフトウェアを事前にインストールして立ち上げておくことなく、端末上のリソースの無駄を無くすことができる。
【００２４】
・DBiCであるか否かを確認するために専用のソフトウェアを端末にて起動するための待ち時間を無くすことができる。
【００２５】
・従来のファイル管理インタフェースを通して、DBiCであるか否かを手軽に確認可能であるため、専用のソフトウェアについて利用方法を習熟する手間を削減することができる。
【００２６】
上記の効果により、DBiCを利用するための端末側利用者の抵抗を低減させ、DBiCによるコンテンツ管理の利便性を向上させることが可能となり、また、DBiCの普及と流通を促進させることができる。
【図面の簡単な説明】
【００２７】
【図１】本発明の原理を説明するための図である。
【図２】本発明の原理構成図である。
【図３】本発明の一実施の形態におけるシステム構成図である。
【図４】本発明の第１の実施の形態における動作を説明するため図である。
【図５】本発明の第１の実施の形態におけるセンタサーバがコンテンツに対する既存のタグ情報を確認する際の動作のフローチャートである。
【図６】本発明の第２の実施の形態におけるコンテンツに対してタグ情報を追加する際の動作のフローチャートである。
【図７】本発明の第２の実施の形態における動作を説明するための図である。
【図８】本発明の第３の実施の形態におけるフォルダ階層構造の例である。
【発明を実施するための形態】
【００２８】
以下、図面と共に本発明の実施の形態を説明する。
【００２９】
以下の説明において、「コンテンツ」とは、多様なメディアデータ、例えば、音声、音楽、画像、映像、フラッシュ、ドキュメント、ベクタ、ショートカットなどであってもかまわない。一般に言われるファイルと同等である。
【００３０】
また、コンテンツを構成する各コーディックやコンテナは、コメント領域や拡張領域などを持っており、その部分にＤＢを構成する。
【００３１】
図３は、本発明の一実施の形態におけるシステム構成図であり、後述する第１の実施の形態及び第２の実施の形態共に同様の構成である。
【００３２】
同図に示すシステムは、１つ以上のネットワーク・ファイルシステム３０２を有するセンタサーバ３０１がネットワーク３０３を介して複数のユーザ端末３９９と接続されている。
【００３３】
ここで、ネットワーク３０３は、インターネットやイントラネットなどである。
【００３４】
センタサーバ３０１のネットワーク・ファイルシステム３０２は、受付・応答部３１１、ファイル管理部３１２、ストレージ３１３から構成される。
【００３５】
受付・応答部３１１は、ユーザ端末３９９からファイルを受け付ける。
【００３６】
ファイル管理部３１２は、受付・応答３１１で受け付けたファイルについての判定を行い、その内容に基づいてストレージ３１３を管理する。
【００３７】
ストレージ３１３は、ハードディスク等の記憶媒体であり、DBiCを格納し、ファイル管理部３１２によって管理される。
【００３８】
[第１の実施の形態]
本実施の形態では、センタサーバ３０１がコンテンツに対する既存のタグ情報を確認する際の動作を説明する。
【００３９】
以下において、ネットワーク・フォルダとしては、例えば、文献（情報処理学会論文誌Vol. 50, No. 8, pp. 1798-1809,(Aug. 2009)赤間浩樹、内藤一兵衛、他：フォルダプログラミング環境「POLDER」）にも記載されているような、フォルダ名に対応した処理が実行されるものとし、例えば、図４に示すように、「DBiCshow」というフォルダ名を用いるものとする。
【００４０】
DBiCへの操作については、前述の非特許文献１に対応して、画像については例えば、以下のような操作ができるLinuxコマンド（jpegSQL）が存在している。
【００４１】
・実行コマンド例１：
jpegSQL    lena.jpg   select
―実行コマンド例１の意味：
select * where all records.
つまり、画像lena.jpg内のDBiCの全レコードを標準出力。
【００４２】
・実行コマンド例２：
jpegSQL   lena.jpg   select   FieldNum   'key'
―実行コマンド例2の意味：
select * where ColumnData[FieldNum]== 'key'.
つまり、画像lena.jpg内のDBiCのうちカラム番号FieldNumがkeyであるレコードを標準出力。
【００４３】
・実行コマンド例３：
【００４４】
【数１】
2011086256.tif 000003
―実行コマンド例３の意味：
update a record where ColumnData[FieldNum]== 'key'.
つまり、画像lena.jpg内のDBiCのうちカラム番号FieldNumがkeyであるレコードを
【００４５】
【数２】
2011086256.tif 000004
を上書き更新。
【００４６】
・実行コマンド例４：
【００４７】
【数３】
2011086256.tif 000005
―実行コマンド例４の意味：
insert a record.
つまり、画像lena.jpg内のDBiCにレコード
【００４８】
【数４】
2011086256.tif 000006
・実行コマンド例５：
jpegSQL    lena.jpg   delete
―実行コマンド例５の意味：
Drop all records.
つまり、画像lena.jpg内のDBiCを削除。
【００４９】
JPEG形式の画像には、非特許文献１で述べられているように、いくつかの領域が存在する。jpegSQLでは、コメント域にDB域（DBiC）を構成しているが、本発明は、その他の拡張域であっても、他の領域であっても、コンテンツと同一ファイル内であれば構わない。
【００５０】
本実施の形態では、図４に示すように、ユーザ端末３９９からDRAG&DROPされたファイルがセンタサーバ３０１上のストレージ３１３上に蓄積されるものであった場合に、ネットワーク（インターネット）３０３を介してダウンロードしたコンテンツにDBiCとしてタグ情報が存在するかを確認する場合について説明する。
【００５１】
図５は、本発明の第１の実施の形態におけるセンタサーバがコンテンツに対する既存のタグ情報を確認する際の動作のフローチャートである。
【００５２】
ステップ１０１）  受付・応答部３１１は、ユーザ端末３９９からファイルを受け付け、ストレージ３１３に蓄積する。
【００５３】
ステップ１０２）  ファイル管理部３１２は、ステップ１０１で受け付けたファイルのDBiC域を参照して、当該ファイルがDBiCを持つか否かを判定し、持つ場合にはステップ１０３に移行し、持たない場合は当該処理を終了する。図４の例では、ユーザ端末３９９から送出されたファイルはDBiC域を有している。
【００５４】
ステップ１０３）  ファイル管理部３１２は、当該ファイルがDBiCを持つ場合には、そのDBiCからタグ集合を検索取得する。図４の例では、タグとして[風景]，[横須賀]，[港]が抽出される。
【００５５】
ステップ１０４）  当該ファイルのファイル名に、ステップ１０３で抽出されたタグ集合を追加し、新たなファイル名を生成する。図４の例では、「sampleOK[風景][横須賀][港]．jpg」となる。
【００５６】
ステップ１０５）  ファイル管理部３１２は、当該ファイルをステップ１０４で生成されたファイル名に変更して、ストレージ３１３に格納する。
【００５７】
以下に、図４に基づいて詳細に説明する。
【００５８】
ネットワーク（インターネット）３０３を介してダウンロードしたコンテンツが「sampleOK.jpg」だったとする。
【００５９】
このＤＢ域に例えば、
：tag：[風景][横須賀][港]：
のようなタグ情報が定義されていたとする。
【００６０】
ここで、コロンがカラム区切り文字、[風景][横須賀][港]はタグ集合を表現する文字列で、各タグは大括弧［］で囲まれているとする（なお、本実施の形態では、この表現を用いるが、これに限定されない。非特許文献１に示されるようなカラム区切りは"／"等他の文字でも構わないし、タグ区切りは空白やカンマ等他の文字でも構わない）。
【００６１】
このとき、ユーザが、この「sampleOK.jpg」をユーザ端末３９９からストレージ３１３のネットワーク・フォルダの「DBiCshow」フォルダにDRAG&DROPすると、受付・応答部３１１はこれを受け付け（ステップ１０１）、ファイル管理部３１２は、「DBiCshow」から呼び出された処理の中で、「sampleOK．jpg」への検索を行う（ステップ１０２）、例えば、DBiCに対して１番目のカラム値が、"tag"であるレコードを選択する処理
jpegSQL   sampleOK.jpg   select  1  "tag"
が実行され、DBiCが存在すれば、
：tag： [風景][横須賀][港]：
が返却され、存在しなければ何も返却されない。
【００６２】
今回の「sampleOK.jpg」では、「：tag：[風景][横須賀][港]：」を取得し（ステップ１０３）、ファイル名「sampleOK．jpg」に上記タグ集合を付加した新たなファイル名として、
sampleOK[風景][横須賀][港].jpg
を生成し、「sampleOK．jpg」というファイル名を
sampleOK[風景][横須賀][港].jpg
に変更する（ステップ１０４，１０５）。
【００６３】
端末利用者は、その変更された名前がネットワーク・フォルダ内に表示されることで、DBiCを持つコンテンツであったこと、及び、その中身のタグ情報を確認することが可能になる。
【００６４】
なお、類似の対処方法として、「sampleOK．tag」というファイルを生成し、その中身のテキストとして、
：tag：[風景][横須賀][港]：
を書き出すことで、タグ情報を確認することも可能である。
【００６５】
この場合、タグの中身を確認するために、エディタ等を使わないといけないという手間が増えるが、タグ数が非常に多数で、ファイル名長制限を越える場合にも対応可能である。さらには、タグだけでなく、DBiCの他の項目の確認も可能である。
【００６６】
さて、そもそもコンテンツがDBiCを持たない場合（sampleNG.jpg）には、jpegSQLの結果もないため、DBiCshowにDRAG&DROPした場合、ファイル名の変更も発生せず、そのままネットワーク・フォルダ内にはsampleNG.jpgとして存在するため、端末利用者はDBiCが存在しなかったことを確認できる。
【００６７】
[第２の実施の形態]
本実施の形態では、インターネットでダウンロードした画像コンテンツにDBiCにタグ情報を追加して管理する方法について説明する。
【００６８】
図６は、本発明の第２の実施の形態におけるコンテンツに対してタグ情報を追加する場合の動作のフローチャートである。
【００６９】
ステップ２０１）  受付・応用部３１１は、ユーザ端末３９９からファイルを受け取り、ストレージ３１３に蓄積する。
【００７０】
ステップ２０２）  ファイル管理部３１２は、ステップ２０１で受け付けたファイルのファイル名中にタグ情報が含まれるか否かを判定し、含まれる場合はステップ２０３に移行し、含まれない場合は当該処理を終了する。
【００７１】
ステップ２０３）  ファイル管理部３１２は、ファイルのファイル名にタグ情報が含まれる場合は、当該ファイル名からタグ集合を抽出する。
【００７２】
ステップ２０４）  ファイル管理部３１２は、ストレージ３１３を参照し、当該ファイルがDBiCを有するか否かを判定し、有する場合はステップ２０５に移行し、持たない場合はステップ２０６に移行する。
【００７３】
ステップ２０５）  DBiCを有する場合は、そのDBiCに対してステップ２０３で抽出したタグ集合の各タグを、重複を排除して当該DBiCに追加する。
【００７４】
ステップ２０６）  DBiCを持たない場合は、そのDBiCに対してステップ２０３で抽出したタグ集合の各タグを追加する。
【００７５】
以下に、図７に基づいて詳細に説明する。
【００７６】
DBiCに新たなタグ情報を追加した場合、例えば、「sampleOK.jpg」に新たな３つのタグ群[夏休み][家族旅行][2009]を付け加えたい場合、まずは、ユーザが、「sampleOK.jpg」を「sampleOK[夏休み][家族旅行][2009].jpg」に利用者端末３９９内で変更し、ストレジ３１３のネットワークフォルダの「DBiCadd」にDRAG&DROPすると、ファイル管理部３１２は、ファイル名中からタグ情報の抽出を試み、[夏休み][家族旅行][2009]があるので、タグが含まれていると判定し（ステップ２０２）、タグ集合として[夏休み][家族旅行][2009]を抽出し（ステップ２０３）、また、ファイル「sampleOK.jpg」に対して、DBiCのタグ検索を行い、結果として、
：tag：[風景][横須賀][港]：
が返却され、DBiCを持つことが判定できるため（ステップ２０４）、その検索結果からタグ集合（[風景][横須賀][港]）を取得し、そのタグ集合に、先のタグ集合[夏休み][家族旅行][2009]を、重複を排除して合わせた[風景][横須賀][港][夏休み][家族旅行][2009]をDBiC内に生成する（ステップ２０５）。
【００７７】
例えば、先のコマンドjpegSQLを使う場合、以下のようになる。
【００７８】
jpegSQL  sampleOK. [夏休み][家族旅行][2009].jpg  delete
（もしくは、jpegSQL  sampleOK[夏休み][家族旅行][2009].jpg  delete  where  ColumnData[1]=='tag'）
jpegSQL  sampleOK[夏休み][家族旅行][2009].jpg  insert  ':tag:[風景][横須賀][港][夏休み][家族旅行][2009]:'
端末利用者は、これによって、DBiCのタグ情報の管理が可能になる。
【００７９】
内容を確認する場合には、第1の実施の形態と同様に行う。
【００８０】
なお、DBiCaddではなくDBiCsetのように、追加ではなく、上書きとして用意する方法も容易に想定できる。
【００８１】
また、各タグやタグ群毎に追加、削除を制御する方法も本発明の応用として想定できる。つまり、
sampleOK +[夏休み][家族旅行][2009]−[港].jpg
というファイル名から、DBiCに対して、[夏休み][家族旅行][2009]というタグを追加し、[港]というタグを削除する。
【００８２】
[第３の実施の形態]
本実施の形態では、DBiCを活用してコンテンツを分類する場合について説明する。
【００８３】
そもそも本発明の目的は、DBiCによるコンテンツ管理によるコンテンツ管理による流通の促進であった。
【００８４】
DBiCは手動で付与するだけではなく、例えば、ウェブ上の画像であれば、その周辺のテキスト情報からキーワードを抽出し、タグとして自動的に埋め込む処理を持ってもよい。
【００８５】
その場合には、第1の実施の形態に示したような内容の確認と、第２の実施の形態に示したような内容の編集が重要になる。
【００８６】
DBiCを整理に活用するケースとしては、検索や分類がある。
【００８７】
例えば、先のフォルダ・プログラミング環境の例で言えば、DBiCのタグ内容にマッチする場合に受け入れるフォルダ「DBiC-match」があったとすると、分類のフォルダ「pFoコンテンツ管理」に、図８に示すようなフォルダ階層構造を作っておいて、DBiCに[夏休み][家族旅行][2009]というタグを持つ画像（ファイル名任意）をDRAG&DROPすると、「DBiC-match 家族旅行」の下の「DBiC-match 夏休み」の中に、画像が自動的に格納されるようになる。
【００８８】
同様に、タグ情報を持った画像群を複数選択して「pFoコンテンツ管理」にDRAG&DROPすることで一気に分類することも可能である。
【００８９】
先のフォルダ階層を事前に用意するのが面倒な場合は、分類対象のフォルダ自体を自動生成することも可能である。
【００９０】
このように、DBiCでは、コンテンツの中にタグ情報を持つことで、流通するコンテンツについて、効果的に管理を可能にする。そして、本発明では、そのDBiCの管理を専用ソフトウェアなしで手軽に利用できる。
【００９１】
上記の第１及び第２の実施の形態におけるセットワークファイルシステム３０２内の処理をプログラムとして構築し、センタサーバとして利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【００９２】
また、構築されたプログラムをハードディスクや、フレキシブルディスク・ＣＤ−ＲＯＭ等の可搬記憶媒体に格納し、コンピュータにインストールする、または、配布することが可能である。
【００９３】
なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
【符号の説明】
【００９４】
３０１  ファイル管理装置、センタサーバ
３０２  ネットワーク・ファイルシステム
３０３  ネットワーク（インターネット、イントラネット）
３１１  受付手段、受付・応答部
３１２  ファイル管理手段、ファイル管理部
３１３  ストレージ
３９９  ユーザ端末
【図１】
2011086256.tif 000007
【図２】
2011086256.tif 000008
【図３】
2011086256.tif 000009
【図４】
2011086256.tif 000010
【図５】
2011086256.tif 000011
【図６】
2011086256.tif 000012
【図７】
2011086256.tif 000013
【図８】
2011086256.tif 000014