(57)【特許請求の範囲】
【請求項１】
メタデータを処理するための、コンピュータで実施される方法において、
第１のユーザから受け取られたファイルを記憶装置に記憶する段階であって、前記ファイルは、第２のユーザに関連したシークレットキーにより暗号化されたプライベートメタデータを有するものである段階と、
前記ファイルのプライベートメタデータが解読及びインデックスされていないことを指示するプライベートメタデータ識別子を所定の記憶位置に記憶する段階と、
前記第２のユーザからその後に受け取られる問合せに応答して、前記所定の記憶位置をスキャンして、前記問合せに基づいて前記プライベートメタデータ識別子を識別する段階と、
前記プライベートメタデータ識別子により識別される前記暗号化されたメタデータを解読のために前記第２のユーザへ送信する段階と、
前記メタデータが前記第２のユーザによって解読されるのに応答して、前記メタデータ及びファイルの少なくとも一方をその後にサーチするために前記解読されたメタデータをインデックスする段階と、
を備えた方法。
【請求項２】
前記解読されたメタデータを前記所定の記憶位置にプレーンテキストで記憶して、前記解読されたメタデータをサーチできるように前記プライベートメタデータ識別子に置き換える段階を更に備え、前記所定の記憶位置は、サーチインデックスの一部分である、請求項１に記載の方法。
【請求項３】
前記第２のユーザに関連付けられて暗号化された暗号化メタデータに関して問合せするために前記第２のユーザが前記記憶装置にログイン及びマウントするときに前記問合せが前記第２のユーザから受け取られる、請求項１に記載の方法。
【請求項４】
前記問合せは、前記第２のユーザに関連したユーザ識別子を含み、そして前記第２のユーザに関連した暗号化メタデータは、前記第２のユーザのユーザ識別子に基づいて識別される、請求項３に記載の方法。
【請求項５】
前記問合せは、前記第２のユーザが前記記憶装置にログイン及びマウントするときに、前記第２のユーザに関連したユーザデーモンにより自動的に発生される、請求項４に記載の方法。
【請求項６】
前記メタデータは、ユーザの介在なく前記第２のユーザに関連したシークレットキーを使用して前記ユーザデーモンにより解読される、請求項５に記載の方法。
【請求項７】
コンピュータにより実行されるときに、そのコンピュータがメタデータ処理方法を遂行するようにさせるインストラクションが記憶されたコンピュータ読み取り可能な媒体において、前記方法は、
第１のユーザから受け取られたファイルを記憶装置に記憶し、前記ファイルは、第２のユーザに関連したシークレットキーにより暗号化されたプライベートメタデータを有するものであり、
前記ファイルのプライベートメタデータが解読及びインデックスされていないことを指示するプライベートメタデータ識別子を所定の記憶位置に記憶し、
前記第２のユーザからその後に受け取られる問合せに応答して、前記所定の記憶位置をスキャンして、前記問合せに基づいて前記プライベートメタデータ識別子を識別し、
前記プライベートメタデータ識別子により識別される前記暗号化されたメタデータを解読のために前記第２のユーザへ送信し、
前記メタデータが前記第２のユーザによって解読されるのに応答して、前記メタデータ及びファイルの少なくとも一方をその後にサーチするために前記解読されたメタデータをインデックスする、
ことを含むものである、コンピュータ読み取り可能な媒体。
【請求項８】
前記方法は、更に、前記解読されたメタデータを前記所定の記憶位置にプレーンテキストで記憶して、前記解読されたメタデータをサーチできるように前記プライベートメタデータ識別子に置き換えることを含み、前記所定の記憶位置は、サーチインデックスの一部分である、請求項７に記載のコンピュータ読み取り可能な媒体。
【請求項９】
前記第２のユーザに関連付けられて暗号化された暗号化メタデータに関して問合せするために前記第２のユーザが前記記憶装置にログイン及びマウントするときに前記問合せが前記第２のユーザから受け取られる、請求項７に記載のコンピュータ読み取り可能な媒体。
【請求項１０】
前記問合せは、前記第２のユーザに関連したユーザ識別子を含み、そして前記第２のユーザに関連した暗号化メタデータは、前記第２のユーザのユーザ識別子に基づいて識別される、請求項９に記載のコンピュータ読み取り可能な媒体。
【請求項１１】
前記問合せは、前記第２のユーザが前記記憶装置にログイン及びマウントするときに、前記第２のユーザに関連したユーザデーモンにより自動的に発生される、請求項１０に記載のコンピュータ読み取り可能な媒体。
【請求項１２】
前記メタデータは、ユーザの介在なく前記第２のユーザに関連したシークレットキーを使用して前記ユーザデーモンにより解読される、請求項１１に記載のコンピュータ読み取り可能な媒体。
【請求項１３】
メタデータを処理するための、コンピュータで実施される方法において、
ユーザがデータ処理システムのオペレーティング環境にログインしたことを検出する段階と、
ユーザに関連した暗号化メタデータに問合せするためにオペレーティング環境のファイルシステムに問合せを送信する段階と、
前記ファイルシステムから暗号化メタデータを受け取る段階と、
ユーザに関連したシークレットキーを使用してメタデータを解読する段階と、
前記解読したメタデータを、インデックスされるべく前記ファイルシステムへ送信する段階と、
を備えた方法。
【請求項１４】
ユーザがログインしたことを検出するのに応答してユーザに関連したユーザデーモンを起動する段階を更に備え、前記問合せは、ユーザからの介在なしに前記ユーザデーモンにより送信される、請求項１３に記載の方法。
【請求項１５】
前記ユーザデーモンは、ユーザに関連したシークレットキーを検索してメタデータを解読するために前記データ処理システムのセキュリティマネージャーと通信する、請求項１４に記載の方法。
【請求項１６】
前記ファイルシステムは、ネットワークを経てのファイルサーバーのリモートファイルシステムである、請求項１３に記載の方法。
【請求項１７】
前記暗号化メタデータは、別のユーザによりファイルサーバーに記憶されたファイルに関連付けられる、請求項１６に記載の方法。
【請求項１８】
コンピュータにより実行されるときに、そのコンピュータがメタデータ処理方法を遂行するようにさせるインストラクションが記憶されたコンピュータ読み取り可能な記憶媒体において、前記方法は、
ユーザがデータ処理システムのオペレーティング環境にログインしたことを検出し、
ユーザに関連した暗号化メタデータに問合せするためにオペレーティング環境のファイルシステムに問合せを送信し、
前記ファイルシステムから暗号化メタデータを受け取り、
ユーザに関連したシークレットキーを使用してメタデータを解読し、
前記解読したメタデータを、インデックスされるべくファイルシステムへ送信する、
ことを含むものである、コンピュータ読み取り可能な記憶媒体。
【請求項１９】
前記方法は、ユーザがログインしたことを検出するのに応答してユーザに関連したユーザデーモンを起動することを更に備え、前記問合せは、ユーザからの介在なしに前記ユーザデーモンにより送信される、請求項１８に記載のコンピュータ読み取り可能な記憶媒体。
【請求項２０】
前記ユーザデーモンは、ユーザに関連したシークレットキーを検索してメタデータを解読するために前記データ処理システムのセキュリティマネージャーと通信する、請求項１９に記載のコンピュータ読み取り可能な記憶媒体。
【請求項２１】
前記ファイルシステムは、ネットワークを経てのファイルサーバーのリモートファイルシステムである、請求項１８に記載のコンピュータ読み取り可能な記憶媒体。
【請求項２２】
前記暗号化メタデータは、別のユーザによりファイルサーバーに記憶されたファイルに関連付けられる、請求項２１に記載のコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、メタデータ処理の分野に関するもので、より詳細には、プライベートメタデータの処理に関する。
【背景技術】
【０００２】
汎用コンピュータシステムのような近代的なデータ処理システムは、そのようなシステムのユーザが種々の異なる形式のデータファイルを生成できるようにする。例えば、データ処理システムの典型的なユーザは、マイクロソフトワードのようなワード処理プログラムでテキストファイルを生成するか、又はアドベのフォトショップのような画像処理プログラムで画像ファイルを生成することができる。典型的なデータ処理システムに対して、多数の他の形式のファイルを生成又は変更し、編集し、さもなければ、１人以上のユーザにより利用することができる。生成又は変更できるファイルのワイドアレイは、生成された特定のファイルを見出すことを求める典型的なユーザに対して課題を提起する。
【０００３】
近代的なデータ処理システムは、多くの場合に、ユーザが種々のディレクトリ又はサブディレクトリ（例えば、フォルダ）にファイルを入れることができるようにすると共に、ユーザがファイルに名前を付けられるようにするファイルマネージメントシステムを備えている。更に、これらのファイルマネージメントシステムは、多くの場合に、ユーザが、ファイルの名前、又は生成の日付、又は変更の日付、又はファイルの形式をサーチすることにより、ファイルを見出すことができるようにする。そのようなファイルマネージメントシステムの一例は、カリフォルニア州、クパチーノのアップル・インクから入手できるマッキントッシュコンピュータで動作する「ファインダー(Finder)」プログラムである。ファイルマネージメントシステムプログラムの別の例は、ワシントン州レドモンドのマイクロソフト・コーポレーションから入手できるウインドウズオペレーティングシステムで動作する「ウインドウズ・エクスプローラ」プログラムである。
【０００４】
「ファインダー」プログラム及び「ウインドウズ・エクスプローラ」プログラムは、両方とも、ファイル名、又は生成の日付、又は変更の日付、又はファイルの形式を含む種々の基準によりユーザがファイルをサーチできるようにする見出しコマンドを含む。しかしながら、このサーチ能力は、ファイルの形式に関わらず、ファイルごとに同じ情報を通してサーチを行う。従って、例えば、「マイクロソフトワード」ファイルのサーチ可能なデータは、「アドベフォトショップ」ファイルのサーチ可能なデータと同じであり、このデータは、典型的に、ファイルマネージメントシステムによりファイルに対して維持されるファイル名、ファイルの形式、生成の日付、最後の変更の日付、ファイルのサイズ、及び他の幾つかのパラメータを含む。
【０００５】
幾つかの既存のアプリケーションプログラムは、ユーザが特定のファイルに関するデータを維持できるようにする。特定のファイルに関するこのデータは、他のデータに関するデータであるから、メタデータと考えられる。特定ファイルに対するこのメタデータは、ファイルの著者に関する情報、ドキュメントの概要、及び種々の他の形式の情報を含む。「マイクロソフトワード」のようなプログラムは、ユーザがファイルを生成するときに、自動的にこのデータをある程度生成し、そしてユーザは、「マイクロソフトワード」におけるメニュー選択から「プロパティシート」を選択することにより付加的なデータを追加し又はデータを編集する。「マイクロソフトワード」におけるプロパティシートは、ユーザが特定ファイル又はドキュメントに対するメタデータを生成できるようにする。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
最近、データベースに記憶されたメタデータは、メタデータサーチエンジンを使用してサーチされる。あるメタデータ（例えば、音楽ファイルの星印格付け）は、メタデータの発信者がパブリックドメインにおける開示を望まないプライベートメタデータである。プライベートメタデータを有するファイルがパブリックドメインに記憶されるときに、プライベートメタデータをプライベートに保持するために、１つの解決策は、公衆がアクセスできる記憶装置（例えば、ファイルサーバー）にファイルを記憶する前にファイルからプライベートメタデータを剥離することである。しかしながら、公衆がアクセスできる記憶装置から発信者がファイルを検索するとき、発信者は、プライベートメタデータを回復できないことがある。
【課題を解決するための手段】
【０００７】
本発明の１つの態様によれば、第１のユーザから受け取られたファイルは、記憶装置に記憶され、そのファイルは、第２のユーザに関連した暗号キーにより暗号化されたメタデータを含む。暗号化されたメタデータは、ファイルの拡張属性としてファイルにアタッチされる。暗号化されたメタデータを有するファイルは、ファイルシステムのコンテンツファイルディレクトリに記憶される。更に、解読又はインデックスされないプライベートメタデータ（例えば、暗号化されたメタデータ）が存在することを指示するプライベートメタデータ識別子又はマーカーがサーチインデックスに記憶される。第２のユーザからその後に受け取られる問合せに応答して、サーチインデックスがスキャンされて、インデックスにおけるプライベートメタデータ識別子のいずれかを識別する。プライベートメタデータ識別子に基づき、暗号化されたメタデータは、ファイルシステムのコンテンツファイルディレクトリにおける対応するコンテンツファイルから探索されて得られ、次いで、暗号化されたメタデータが解読のために第２のユーザへ送信される。第２のユーザにより解読されたメタデータに応答して、メタデータは、メタデータ及びファイルの少なくとも一方のその後のサーチのためにインデックスされる。更に、インデックスにおけるプライベートメタデータ識別子又はマーカーは、プレーンテキスト形態の解読されたメタデータと置き換えられる。
【０００８】
本発明の別の態様によれば、ユーザがデータ処理システムの動作環境にログインしたことが検出される。その検出に応答して、ユーザに関連した暗号化されたメタデータに問合せするために動作環境のファイルシステムに問合せが送信される。暗号化されたメタデータは、ファイルシステムから受け取られ、ユーザに関連したシークレットキーを使用して解読される。解読されたメタデータは、次いで、インデックスされるべきファイルシステムへ送信される。
【０００９】
本発明の他の特徴は、添付図面及び以下の詳細な説明から明らかとなろう。
【００１０】
本発明の実施形態は、同様の要素が同じ参照番号で示された添付図面に一例として示すが、これに限定されない。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態によるメタデータを処理するアーキテクチャーの一例を示すブロック図である。
【図２】本発明の別の実施形態によるメタデータ処理システムを示すブロック図である。
【図３】本発明の一実施形態によるネットワークシステムを示すブロック図である。
【図４】本発明の一実施形態によるメタデータ処理方法を示すフローチャートである。
【図５】本発明の別の実施形態によるメタデータ処理方法を示すフローチャートである。
【図６】本発明の別の実施形態によるメタデータ処理方法を示すフローチャートである。
【図７】本発明の一実施形態に使用されるデータ処理システムのブロック図である。
【発明を実施するための形態】
【００１２】
本発明の種々の実施形態及び態様が以下に詳細に説明され、添付図面は種々の実施形態を示す。以下の説明及び添付図面は、本発明を例示するもので、本発明を限定するものではない。本発明の種々の実施形態を完全に理解するために多数の特定の細部について述べる。しかしながら、ある場合には、本発明の実施形態の説明を簡略にするため、良く知られた又は従来の細部は、述べない。
【００１３】
本明細書において「１つの実施形態」又は「一実施形態」とは、実施形態に関連して述べる特定の特徴、構造又は特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。本明細書の種々の場所で「１つの実施形態において」という句が現れたときには、必ずしも、全てが同じ実施形態を指していない。
【００１４】
本発明の幾つかの実施形態によれば、ファイルのプライベートメタデータは、プライベートメタデータの発信者に関連した暗号キーを使用して暗号化され、そしてその暗号化されたメタデータは、ファイルの拡張属性の一部分としてファイルにアタッチされる。そのような暗号化されたメタデータは、発信者でなければ解読できない。公衆がアクセスできる記憶装置にファイルが記憶されるときには、コンテンツファイルデータベースにファイルを記憶するのに加えて、特定キーで暗号化されたプライベートメタデータを有する少なくとも１つのファイルがあることを指示するプライベートメタデータ識別子又はマーカーがサーチインデックスに記憶される。
【００１５】
その後に、公衆がアクセスできる記憶装置に発信者がアクセスする（例えば、ログイン又はマウントする）とき、プライベートメタデータ識別子又はマーカーを識別するためにサーチインデックスがスキャンされる。プライベートメタデータ識別子又はマーカーに基づいて、ファイルディレクトリに記憶された対応するファイル（１つ又は複数）から暗号化されたメタデータが探索され得られる。プライベートメタデータは、発信者により解読されて、オリジナルメタデータをプレーンテキスト形態で回復する。その後、オリジナルメタデータは、公衆がアクセスできる記憶装置においてインデックスされ及び／又は記憶される。プライベートメタデータは、発信者によりファイルにタグ付けされるプライベートラベルである。プライベートラベルを有するファイルが記憶装置に記憶されて、アップル・インクのＦｉｎｄｅｒTM又はマイクロソフト・コーポレーションのＷｉｎｄｏｗｓ（登録商標）  ＥｘｐｌｏｒｅｒTMのようなブラウザプログラムでブラウズされるときに、プライベートラベルの発信者以外の通常のユーザがプライベートラベルの詳細を見ることができなくても、プライベートラベルが特別の仕方で表示されて、関連ファイルがプライベートラベルでタグ付けされたことを指示する。
【００１６】
メタデータの「発信者(originator)」という語は、ここでは、メタデータを生成し、更新し、及び／又はファイルにアタッチするユーザ又はユーザのエージェント（例えば、ユーザデーモンプロセス）を指すことに注意されたい。又、「公衆がアクセスできる(publically accessible)」記憶装置という語は、ここでは、メタデータの発信者以外のエンティティによりアクセスできる任意の記憶装置（例えば、ファイルサーバー）を指す。
【００１７】
図１は、本発明の１つの実施形態によるメタデータを処理するアーキテクチャーの一例を示すブロック図である。ここに述べる機能及び動作を具現化するのに種々の異なるソフトウェアアーキテクチャーを使用できることに注意されたい。以下の説明は、そのようなアーキテクチャーの一例であるが、別のアーキテクチャーを使用しても、同じ又は同様の結果が得られることを理解されたい。図１に示すソフトウェアアーキテクチャーは、「マッキントッシュ」オペレーティングシステムに基づく一例である。例えば、システム１００は、クライアント（例えば、ファイルシステム）のオペレーティングシステム（ＯＳ）の一部分として具現化されてもよく、或いはシステム１００は、ネットワーク（例えば、ローカルエリアネットワーク、又はインターネットのようなワイドエリアネットワーク）を経て１つ以上のクライアントへコンテンツサービスを提供するファイルサーバーのようなサーバーの一部分として具現化されてもよい。
【００１８】
図１を参照すれば、１つの実施形態により、アーキテクチャー１００は、メタデータ処理ソフトウェア１０１と、通知メカニズムのためにそのメタデータ処理ソフトウェア１０１に作動的に結合されたオペレーティングシステム（ＯＳ）カーネル１０３とを備えている。メタデータ処理ソフトウェア１０１は、ファイルシステムグラフィックユーザインターフェイスソフトウェア１０５（「ファインダー」でもよい）、ｅ−メールソフトウェア１０７、及び他のアプリケーション１０９のような他のソフトウェアプログラムにも結合される。これらのアプリケーションは、クライアントアプリケーションプログラムインターフェイス１１１を通してメタデータ処理ソフトウェア１０１に結合され、そのプログラムインターフェイスは、メタデータ処理ソフトウェア１０１とソフトウェア１０５、１０７及び１０９との間でデータ及びコマンドを転送する方法を提供するものである。それらのコマンド及びデータは、ユーザにより指定されたサーチパラメータ、及びユーザからのサーチ遂行コマンドを含み、それらのパラメータ及びコマンド（例えば、サーチ用語又はサーチ範囲）は、インターフェイス１１１を通してメタデータ処理ソフトウェア１０１へ通される。
【００１９】
又、メタデータ処理ソフトウェア１０１は、種々のアプリケーションからデータを抽出するインポーター１１３の集合体にも結合される。１つの実施形態では、「マイクロソフトワード」等のワード処理プログラムにより生成されるワード処理又はテキスト処理ファイルからテキスト及び他の情報を抽出するためにテキストインポーターが使用される。これらの抽出された情報は、特定ファイルのメタデータである。他の形式のインポーターは、他の形式のファイル、例えば、画像ファイル又は音楽ファイルからメタデータを抽出する。１つの実施形態において、アプリケーションプログラムにより生成され変更されるファイルの形式に基づいて特定のインポーターが選択される。
【００２０】
例えば、データファイルが「フォトショップ」により生成された場合には、「フォトショップ」の画像インポーターを使用して、「フォトショップ」データファイルからメタデータ処理ソフトウェア１０１を通してメタデータデータベース１１５へメタデータを入力することができる。他方、データファイルがワード処理ドキュメントである場合には、ワード処理ドキュメントからメタデータを抽出するように設計されたインポーターが呼び出され又はコールされて、ワード処理データファイルからメタデータを抽出し、そしてメタデータ処理ソフトウェア１０１を通してメタデータデータベース１１５へ入れる。典型的に、典型的なコンピュータシステムに使用される複数の異なるアプリケーションプログラムを取り扱うためには、異なるインポーターが要求される。インポーター１１３は、特定形式のデータファイルに対して抽出されたメタデータを、あるアプリケーションプログラムにより維持されるプロパティシート又は他のデータコンポーネントへエクスポートして戻すことのできる複数のエクスポーターを含むのも任意である。例えば、あるアプリケーションプログラムは、プログラムにより生成された各データファイルに対してあるメタデータを維持するが、このメタデータは、この形式のデータファイルからインポーターにより抽出されるメタデータのサブセットに過ぎない。この例では、エクスポーターは、付加的なメタデータをエクスポートして戻してもよいし、或いはアプリケーションプログラムにより維持されるメタデータのブランクフィールドにメタデータを単に挿入するだけでもよい。
【００２１】
ソフトウェアアーキテクチャー１００は、メタデータのためのファイルシステムディレクトリ１１７も備えている。このファイルシステムディレクトリは、データファイルとそれらのメタデータとの間の関係を追跡すると共に、各インポーターにより生成されるメタデータオブジェクト（例えば、抽出されたところのデータファイルに対応するメタデータファイル）の位置を追跡する。１つの実施形態において、メタデータデータベース１１５は、フラットなファイルフォーマットとして維持され、そしてファイルシステムディレクトリ１１７は、このフラットなファイルフォーマットを維持する。フラットなファイルフォーマットの１つの効果は、あるメタデータファイル（特定のデータファイルに対応する）からのフィールドと別のメタデータファイル（別のデータファイルに対応する）へのフィールドとの間の参照を伴わないデータのストリングとしてデータが記憶装置にレイアウトされることである。このデータの配列は、多くの場合に、メタデータデータベース１１５からの迅速な情報検索を生じる。
【００２２】
又、図１のソフトウェアアーキテクチャー１００は、コンテンツで見出すソフトウェア(find by content software)１１９も備え、これは、データベース１２１に作動的に結合され、ファイルのインデックスを含む。ファイルのインデックスは、各ドキュメントのコンテンツの従来のインデックス型表現である。コンテンツで見出すソフトウェア１１９は、データベース１２１をサーチすることによりそのコンテンツにおいてワードをサーチして、インデックスされたデータファイルのいずれかに特定のワードが存在するかどうか調べる。コンテンツで見出すソフトウェアの機能は、メタデータ処理ソフトウェア１０１を通して利用され、これは、ユーザがデータベース１２１におけるファイルのインデックス（ファイル内のコンテンツに対する）と、サーチされている種々のデータファイルに対するメタデータとの両方を同時にサーチできるという効果をユーザに与える。
【００２３】
１つの実施形態において、インデックス１２１は、反転型インデックスの一部分として具現化される。反転型インデックス（ポスティングファイル又は反転型ファイルとも称される）は、ワード又は番号のようなコンテンツから、データファイル或いはドキュメント又はドキュメントセットにおけるその位置へのマッピングを記憶するインデックスデータ構造である。反転型インデックスの目的は、ドキュメントがデータベースに追加されたときに増加される処理のコストで高速の全テキストサーチを行えるようにすることである。反転型ファイルは、データベースファイル自身であり、そのインデックスではない。それは、情報検索システムに使用される最も普及したデータ構造の１つである。反転型インデックスには２つの主たる変形形態がある：１）レコードレベルの反転型インデックス（又は反転型ファイルインデックス又はジャスト(just)反転型ファイル）は、ワードごとのドキュメントの参照のリストを含み；そして２）ワードレベルの反転型インデックス（又は全反転型インデックス又は反転型リスト）は、ドキュメント内の各ワードの位置を更に含む。後者の形態は、より多くの機能（フレーズサーチのような）を与えるが、より長い時間及びより多くのスペースの生成を必要とする。
【００２４】
反転型インデックスのデータ構造は、典型的なサーチエンジンインデックスアルゴリズムの中央コンポーネントである。サーチエンジン具現化の目標は、問合せの速度を最適化し、特定事項が生じるドキュメントを見出すことである。ドキュメント当たりのワードのリストを記憶する順方向インデックスが開発されると、それが次いで反転されて、反転型インデックスを発生する。順方向インデックスを問合せるには、各ドキュメントを通して各ワードに至り、マッチングするドキュメントを検証する順次の反復を必要とする。そのような問合せを遂行するための時間、メモリ及び処理リソースは、常に技術的に現実的というのではない。順方向インデックスにおいてドキュメント当たりのワードをリストするのではなく、ワード当たりのドキュメントをリストする反転型インデックスデータ構造が発生される。反転型インデックスが生成された状態で、反転型インデックスにおいて関連ワード識別子（アイテム識別子とも称される）へジャンプすることにより、問合せをここで解明することができる。
【００２５】
インデックスとのマッチングは、トライ(trie)と称されるデータ構造を使用する。このトライは、ツリーの各ノードが、マッチングされるストリングの各キャラクタを解明するツリー構造である。各内部ノードは、キャラクタのリストより成る。各キャラクタには、別の内部ノード又はリーフノードへの出リンク(outgoing link)が関連付けられる。各リーフノードは、そのリーフノードへ通じるプレフィックスに関連した結果データを保持する。トライをサーチするために、ルートノードでスタートし、そしてマッチングされるストリングの次のキャラクタに対応する各ノードにおいて出リンクをたどることによりツリーを横断する。マッチングする出リンクを見出せないときには、マッチングが見出されている。
【００２６】
１つの実施形態において、図１へ戻ると、ファイル（例えば、ドキュメント又は音楽ファイル）が受け取られると、そのファイルは、ファイルシステムのコンテンツファイルディレクトリのような記憶装置に記憶される。更に、ファイルに関連したメタデータがメタデータインポーター１１３により抽出され、そしてインデックスソフトウェア１２２によりインデックス１２１の部分としてインデックスされる。メタデータは、メタデータデータベース１１５に記憶される。メタデータは、プレーンテキスト形態であるか或いは暗号化又はハッシュ形態である（プライベートメタデータとも称される）。メタデータがプライベートメタデータでない場合には、インデックスソフトウェア１１２によりインデックス１２１の一部分であるようにインデックスされ、これは、例えば、メタデータで見出すソフトウェア(find by metadata software)１２０を経て、メタデータに基づきその後にサーチを行うのに使用される。
【００２７】
しかしながら、メタデータがプライベートメタデータである場合には、それがインデックスソフトウェア１２２によりインデックスされない。というのは、メタデータのコンテンツを決定できないからである。この状況では、プライベートメタデータを解読するために暗号／解読キー又はハッシュ方法のような必要なクレデンシャルを有するのは、メタデータの発信者だけである。１つの実施形態では、ファイルシステムのどこかにプライベートメタデータが記憶された少なくとも１つのファイルがあることを指示するプライベートメタデータ識別子又はマーカーが記憶され、このプライベートメタデータ識別子を使用して、ファイル及びそのプライベートメタデータを探索することができる。その後、プライベートメタデータの発信者がシステム１００にアクセスすると、プライベートメタデータは、プライベートメタデータ識別子を経て識別されそして発信者により解読され（例えば、発信者の同意で）、次いで、その解読されたメタデータは、インデックスソフトウェア１１２によりインデックスされ及び／又はメタデータデータベース１１５に記憶される。その結果、プライベートメタデータは、インデックスできないが、プライベートメタデータは、ファイルシステムに記憶されている間にプライベートなままであり、メタデータは、ファイルと共に留まることができる。
【００２８】
図２は、本発明の別の実施形態によるメタデータ処理システムを示すブロック図である。例えば、システム２００は、図１のシステム１００の一部分として具現化されるか又はそれに通信結合される。図２を参照すれば、システム２００は、コンテンツファイルデータベース２０２及び／又はメタデータデータベース１１５を管理するためのファイルシステム２０１を備え、コンテンツデータベース２０２及び／又はメタデータデータベース１１５は、記憶装置にローカル記憶されるか、又はネットワークを経てリモート記憶される。１つの実施形態において、プライベートメタデータ２０９がアタッチされたファイル２０８がソース（例えば、ローカルユーザ又はリモートユーザ）から受け取られると、ファイル２０８がコンテンツデータベース２０２にファイル２１２の一部分として記憶されるのに加えて、プライベートメタデータ２０９を抽出するためにメタデータインポーター１１３が呼び出される。メタデータの発信者が現在ログインしている同じユーザである場合には、シークレットキーがセキュリティプロフィール２０６からセキュリティマネージャー２０５を経て得られる。プライベートメタデータ２０９は、シークレットキーを使用して解読される。解読されたメタデータは、インデックスソフトウェア１２２によりインデックスされ、そしてインデックス１２１にプレーンテキストとして記憶される。
【００２９】
プライベートメタデータ２０９の発信者が現在ログインしている同じユーザでない場合には、メタデータインポーター１１３は、プライベートメタデータを解読することができない。１つの実施形態において、解読又はインデックスされていないプライベートメタデータを有する少なくとも１つのファイル（例えば、ファイル２１２）がファイルシステムのどこか（例えば、コンテンツファイルディレクトリ２０２）に記憶されていることを指示するプライベートメタデータ識別子又はマーカーがインデックス１２１に記憶される。このプライベートメタデータ識別子を使用して、関連プライベートメタデータを有する対応するファイル（例えば、ファイル２１２）を探索することができる。
【００３０】
１つの実施形態において、ファイル２０８は、第１のユーザから受け取られ、又、プライベートメタデータは、第２のユーザにより発信されて、第２のユーザに関連したシークレットキーにより暗号化される。例えば、ファイル２０８は、第１のユーザにより発生される音楽ファイルであり、そしてプライベートメタデータ２０９は、第２のユーザにより発生される音楽ファイル２０８の格付けである。プライベートメタデータ２０９は、第２のユーザでなければ解読できない暗号化形態であるから、プライベートメタデータ２０９は、第２のユーザが現在ログインしているユーザでない場合には、インデックスソフトウェア１２２によりインデックスすることができない。
【００３１】
その後、１つの実施形態によれば、第２のユーザがシステム２００にアクセスするときに、第２のユーザに関連したユーザデーモン２０４は、第２のユーザに関連したプライベートメタデータのリストを得るためにファイルシステム２０１へ問合せを送信するように構成される。その問合せに応答して、ファイルシステム２０１は、例えば、第２のユーザのユーザ識別子（ＩＤ）に基づいて、第２のユーザに関連したプライベートメタデータを識別し、そのユーザ識別子は、問合せから抽出されるか、或いはユーザデーモン２０４との通信又は関連ログインプロセスから抽出される。１つの実施形態において、そのユーザＩＤに基づき、ファイルシステム２０１は、インデックス１２１をスキャンして、ユーザＩＤに関連したプライベートメタデータ識別子（例えば、プライベートメタデータ識別子２１０）を識別する。次いで、プライベートメタデータが識別され、コンテンツファイルディレクトリ２０２（１つ又は複数）内の対応するファイル（１つ又は複数）（例えば、ファイル２１２）において探索される。識別されたプライベートメタデータは、次いで、ユーザデーモン２０４へ返送される。
【００３２】
ユーザデーモン２０４は、次いで、セキュリティマネージャー２０５と通信して、第２ユーザのセキュリティプロフィール２０６からシークレットキー２０７を得、そしてファイルシステム２０１から得たプライベートメタデータのリストを解読する。セキュリティマネージャー２０５及び／又はセキュリティプロフィール２０６は、アップル・インクから入手できるＭａｃ  ＯＳのログインキーチェーンサービスの一部分である。解読されたメタデータは、次いで、ファイルシステム２０１へ返送されてインデックス１２１に記憶され、対応するプライベートメタデータ識別子（１つ又は複数）に置き換わる。更に、解読されたメタデータは、その後の高速サーチのためにインデックスソフトウェア１２２によりインデックスされる。
【００３３】
ユーザデーモン２０４により遂行される前記動作は、ユーザの介在なしに自動的に遂行されてもよく、或いは又、第２ユーザからの至急同意（例えば、ユーザプロンプト）のみで遂行されてもよいことに注意されたい。更に、シークレットキーが更新されると、その後のプライベートメタデータは、新たなキーを使用して暗号化される。古いキーを使用して暗号化されたプライベートメタデータを解読できるようにするために、１つの実施形態によれば、古いデータが全て維持される。異なるプライベートメタデータは、異なるシークレットキーにより暗号化され、各シークレットキーは、普遍的に独特のＩＤ（ＵＵＩＤ）により識別されることに注意されたい。複数のＵＵＩＤが同じユーザに関連付けられてもよい。ユーザは、メタデータプライバシーパスワードを変更することによりそのキーを変更することができる。
【００３４】
システム２００は、マルチユーザアクセス可能なシステム又はワークステーションとして具現化される。又、上述した技術は、クライアント及びサーバー構成にも適用できる。図３は、本発明の１つの実施形態によるネットワークシステムを示すブロック図である。図３を参照すれば、システム３００は、ローカルエリアネットワーク（ＬＡＮ）であるか又はインターネットのようなワイドエリアネットワーク（ＷＡＮ）であるネットワーク３０４を経てサーバー３０３に通信結合された１つ以上のクライアント３０１−３０２を備えている。サーバー３０３は、これに限定されないが、メタデータデータベース１１５に記憶されたメタデータを管理するためのファイルシステム２０１を備え、メタデータは、サーチのためにインデックスソフトウェア１１２によりインデックスされてもよい。
【００３５】
図２に示す構成と同様に、プライベートメタデータを有するファイルがサーバー３０３に受け取られると（例えば、クライアント３０１の第１ユーザから）、プライベートメタデータを伴うファイルをファイル２１２の一部分としてコンテンツファイルディレクトリ２０２に記憶するのに加えて、プライベートメタデータ識別子又はマーカーも、プライベートメタデータ識別子２１０の一部分としてインデックス１２１に記憶される。その後、第２のユーザが、この例ではクライアント３０２からサーバー３０３へログインすると、第２のユーザに関連したユーザデーモン２０４が、第２のユーザに関連したプライベートメタデータのリストに質問するためにサーバー３０３に問合わせを送信する。その問合せに基づいて、ファイルシステム２０１は、インデックス１２１をスキャンして、１つ以上のプライベートメタデータ識別子２１０のリストを得る。プライベートメタデータ識別子２１０に基づいて、ファイルシステム２０１は、コンテンツファイルディレクトリ２０２においてプライベートメタデータ識別子により識別されたプライベートメタデータを有する対応するファイル２１２を探索する。その後、ファイル２１２からプライベートメタデータのリストがクライアント３０２の第２ユーザへ返送される。
【００３６】
第２のユーザに関連したプライベートメタデータ及び／又はプライベートブロブは、第２のユーザ又はユーザのグループに関連したユーザＩＤ、例えば、第２のユーザ又はユーザのグループのＵＵＩＤに基づいて識別され、それは、第２のユーザに関連した問合せ又はログインプロセスから（例えば、認証、許可のユーザデータベース、及び／又はアカウンティングエンティティ又はサーバーから）得られる。１つの実施形態において、クライアント３０２のユーザデーモン２０４は、セキュリティマネージャー２０５を経てシークレットキー２０７を得、そしてプライベートメタデータを解読するように構成される。その解読されたメタデータは、次いで、インデックス１２１に記憶されそしてインデックスソフトウェア１２２によりインデックスされるべく、クライアント３０２からサーバー３０３へ送信される。
【００３７】
ある実施形態によれば、ファイルのメタデータは、ファイルの拡張属性の一部分として具現化される。即ち、メタデータは、ファイルシステムによりファイルの拡張属性として考えられる。１つの実施形態において、暗号形態又はプレーンテキスト形態のメタデータは、所定のハッシュアルゴリズム又はメソッド（例えば、ＳＨＡ−１又はＭＤ−５）を使用してメタデータの発信者のＵＵＩＤでハッシュされ、そしてそのハッシュされたメタデータは、ファイルと共に、拡張属性として記憶される。このように、ファイルシステム又はオペレーティングシステムは、それがハッシュアルゴリズムを知っているので、システムにおける特定のハッシュされたメタデータのユーザを決定することができるが、普通のユーザは、ハッシュアルゴリズムを知らないので、言うことができないか又は言うための著しい努力が要求されない。
【００３８】
その結果、アップル・インクのＦｉｎｄｅｒTM又はマイクロソフト・コーポレーションのＷｉｎｄｏｗｓ（登録商標）  ＥｘｐｌｏｒｅｒTMのようなブラウザプログラムは、あるメタデータが、プライベートメタデータ（例えば、ハッシュされた暗号メタデータ）、半プライベートメタデータ（例えば、ハッシュされたプレーンテキストメタデータ）、及びパブリックメタデータ（例えば、プレーンテキストメタデータ）であることを適切に識別することができる。加えて、この情報に基づいて、ブラウザプログラムは、異なる形式のメタデータに対するアイコン（例えば、ユーザ又はシステムによりタグ付けされた）のような異なるラベル又はマーカー或いはグラフィック表現も表示することができる。更に、そのようなラベル又はマーカーは、発信者の関連ＵＵＩＤ及び既知のハッシュアルゴリズムに基づいてシステムにより決定される特定メタデータの発信者を識別する情報を含む。従って、ブラウザプログラムのグラフィックユーザインターフェイス（ＧＵＩ）から、普通のユーザは、どのファイルがプライベートメタデータ、半プライベートメタデータ、及び／又はパブリックメタデータ、等であるか言うことはできるが、ユーザは、プライベート又は半プライベートメタデータの詳細情報を見ることはできない。
【００３９】
図４は、本発明の１つの実施形態によるメタデータ処理方法を示すフローチャートである。例えば、この方法４００は、図２のシステム２００又は図３のシステム３００により遂行される。図４を参照すれば、ブロック４０１において、プライベートメタデータを有するファイルが受け取られたときに、そのファイルは、プライベートメタデータと共に、ファイルシステムに記憶され、プライベートメタデータは、メタデータの発信者の暗号キーにより暗号化されている。ブロック４０２において、プライベートメタデータがシステムに現在ログインしているユーザにより発信されたものであるかどうか決定される。例えば、上述したように、プライベートメタデータは、メタデータの発信者のＵＵＩＤでハッシュされる。システムは、プライベートメタデータのＵＵＩＤを、現在ログインしているユーザのＵＵＩＤと比較して、プライベートメタデータが現在ログインしているユーザにより発信されたものであるかどうか決定することができる。もしそうであれば、ブロック４０３において、メタデータインポーター又は現在ユーザのユーザデーモンは、セキュリティコンポーネント（例えば、ログインキーチェーンサービス）と通信して、暗号化されたプライベートメタデータに関連した現在ユーザのシークレットキーを検索することができる。上述したように、ユーザは、複数のＵＵＩＤを有し、そして各ＵＵＩＤは、シークレットキーに関連している。この実施形態では、プライベートメタデータに関連したＵＵＩＤは、プライベートメタデータを解読するための対応するシークレットキーを識別するのに使用される。ブロック４０４において、プライベートメタデータは、シークレットキーを使用して解読され、そして解読されたメタデータは、インデックス及び／又は記憶の目的で使用される。メタデータの発信者が現在ログインしているユーザでない場合には、ブロック４０５において、対応するプライベートメタデータが解読又はインデックスされていないことを指示するプライベートメタデータ識別子又はマーカーがインデックスに記憶される。その後、メタデータの発信者がシステムにログインするときに、プライベートメタデータは、その発信者に関連したシークレットキーを使用して識別及び解読することができる。
【００４０】
図５は、本発明の別の実施形態によるメタデータ処理方法を示すフローチャートである。例えば、この方法５００は、図２のシステム２００又は図３のシステム３００により遂行される。図５を参照すれば、ユーザがログインしたとの検出に応答して、ブロック５０１において、ユーザに関連したユーザデーモンが起動される。ブロック５０２において、ユーザデーモンは、ユーザに関連して記憶されたプライベートメタデータに質問するためにファイルシステムに問合せを送信する。ファイルシステムは、ローカルファイルシステム、及び／又はネットワークを経てのリモートファイルシステムである。ブロック５０３において、現在ログインしているユーザに関連したプライベートメタデータのリストがファイルシステムから受け取られる。ブロック５０４において、現在ログインしているユーザに関連したシークレットキーを使用してプライベートメタデータのリストが解読される。１つの実施形態において、ユーザデーモンは、システムのセキュリティコンポーネント（例えば、ログインキーチェーンサービス）と通信して、メタデータの解読に使用されるユーザに関連したシークレットキーを検索する。その後、ブロック５０５において、解読されたメタデータがインデックス及び／又は記憶のためにファイルシステムに送信される。
【００４１】
図６は、本発明の別の実施形態によるメタデータ処理方法を示すフローチャートである。例えば、この方法６００は、図２のシステム２００又は図３のシステム３００により遂行される。特に、この方法６００は、図３のサーバー３０３により遂行される。図６を参照すれば、ブロック６０１において、クライアント（例えば、ユーザデーモン）から問合せが受け取られ、その問合せは、クライアントのユーザを識別するユーザ識別子（例えば、ＵＵＩＤ）に関連している。問合せに応答して、ブロック６０２において、処理ロジックは、ファイルシステムに現在記憶され且つユーザに関連したプライベートメタデータをユーザ識別子に基づいてスキャンし識別するように構成される。１つの実施形態において、サーチインデックスがスキャンされ、そこに記憶されたプライベートメタデータ識別子をユーザ識別子に基づいて識別する。プライベートメタデータを有するファイルが、次いで、プライベートメタデータ識別子に基づいてコンテンツファイルディレクトリにおいて探索され、プライベートメタデータをファイルから抽出することができる。ブロック６０３において、プライベートメタデータのリストが、クライアントによって解読されるべくクライアントへ送信される。ブロック６０４において、解読されたメタデータがクライアントから受け取られ、ブロック６０５において、解読されたメタデータがファイルシステムにおいてインデックスされて記憶される。
【００４２】
図７は、本発明の一実施形態に使用できるデータ処理システムのブロック図である。例えば、このシステム７００は、図１のシステム１００として使用されてもよい。図７は、コンピュータシステムの種々のコンポーネントを示すが、コンポーネントを相互接続する特定のアーキテクチャー又は方法を表わすものではないことに注意されたい。というのは、そのような細部は、本発明にとって関係がないからである。又、より少ないコンポーネント又はおそらくより多くのコンポーネントを有するネットワークコンピュータ、ハンドヘルドコンピュータ、セルラーホン及び他のデータ処理システムも、本発明に使用できることが明らかであろう。図７のコンピュータシステムは、例えば、アップル・マッキントッシュコンピュータ、又はＩＢＭ適合のＰＣでよい。
【００４３】
図７に示したように、一形式のデータ処理システムであるコンピュータシステム７００は、バス又は相互接続部７０２を備え、これは、１つ以上のマイクロプロセッサ７０３、ＲＯＭ７０７、揮発性ＲＡＭ７０５、及び不揮発性メモリ７０６に結合される。マイクロプロセッサ７０３は、キャッシュメモリ７０４に結合される。バス７０２は、これら種々のコンポーネントを一緒に相互接続すると共に、これらコンポーネント７０３、７０７、７０５及び７０６を、ディスプレイコントローラ・ディスプレイ装置７０８、並びに入力／出力（Ｉ／Ｏ）装置７１０に相互接続し、そのＩ／Ｏ装置は、マウス、キーボード、モデム、ネットワークインターフェイス、プリンタ、及びこの分野で良く知られた他の装置である。
【００４４】
典型的に、入力／出力装置７１０は、入力／出力コントローラ７０９を通してシステムに結合される。揮発性ＲＡＭ７０５は、典型的に、メモリ内のデータをリフレッシュ又は維持するために常時電力を必要とするダイナミックＲＡＭ（ＤＲＡＭ）として具現化される。不揮発性メモリ７０６は、典型的に、システムから電力が取り去られた後もデータを維持する磁気ハードディスク、磁気光学ドライブ、光学ドライブ、又はＤＶＤ  ＲＡＭ、或いは他の形式のメモリシステムである。典型的に、不揮発性メモリは、ランダムアクセスメモリであるが、これは、必要なことではない。
【００４５】
図７は、不揮発性メモリが、データ処理システム内の残りのコンポーネントに直結されたローカル装置であることを示しているが、本発明は、システムから遠隔にある不揮発性メモリ、例えば、モデム又はイーサネット（登録商標）インターフェイスのようなネットワークインターフェイスを通してデータ処理システムに結合されたネットワーク記憶装置を使用してもよい。バス７０２は、この分野で良く知られたように、種々のブリッジ、コントローラ、及び／又はアダプタを通して互いに接続される１つ以上のバスを含む。１つの実施形態において、Ｉ／Ｏコントローラ７０９は、ＵＳＢ周辺装置をコントロールするためのＵＳＢ（ユニバーサルシリアルバス）アダプタを含む。或いは又、Ｉ／Ｏコントローラ７０９は、ＦｉｒｅＷｉｒｅ装置をコントロールするためのＦｉｒｅＷｉｒｅアダプタとしても知られたＩＥＥＥ−１３９４を含んでもよい。
【００４６】
以上の詳細な説明のある部分は、コンピュータメモリ内のデータビットに対するオペレーションのアルゴリズム及び記号表示に関して表現されている。これらのアルゴリズム記述及び表示は、データ処理分野の当業者が、彼等の仕事の実質を他の当業者に最も効率的に伝えるために使用される方法である。アルゴリズムとは、ここでは、一般的に、望ましい結果を導く自己矛盾のないオペレーションシーケンスであると考えられる。オペレーションは、物理量の物理的操作を要求するものである。
【００４７】
しかしながら、これら及び同様の用語は、全て、適当な物理量に関連付けられ、そしてそれらの量に適用される便宜的表示に過ぎないことを銘記されたい。特に指示のない限り、以上の説明から明らかなように、この説明全体を通して、特許請求の範囲に示すような用語を使用する説明は、コンピュータシステムのレジスタ及びメモリ内で物理的（電子的）量として表されたデータを操作し、そしてコンピュータシステムのメモリ又はレジスタ或いは他のそのような情報記憶、伝達又は表示装置内で物理的量として同様に表される他のデータへと変換するコンピュータシステム又は同様の電子的コンピューティング装置のアクション及び処理を指すものである。
【００４８】
又、本発明の実施形態は、ここに示すオペレーションを遂行するための装置にも係る。そのようなコンピュータプログラムは、非一時的なコンピュータ読み取り可能な媒体に記憶される。マシン読み取り可能な媒体は、マシン（例えば、コンピュータ）により読み取りできる形態で情報を記憶するためのメカニズムを含む。例えば、マシン読み取り可能な（例えば、コンピュータ読み取り可能な）媒体は、マシン（例えば、コンピュータ）読み取り可能な記憶媒体（例えば、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学的記憶媒体、フラッシュメモリ装置、等）を含む。
【００４９】
添付図面に示すプロセス及び方法は、ハードウェア（例えば、回路、専用ロジック、等）、ソフトウェア（例えば、非一時的なコンピュータ読み取り可能な媒体で実施される）、又は両方の組み合わせを含む処理ロジックによって遂行される。プロセス又は方法は、順次のオペレーションに関して上述したが、上述したオペレーションの幾つかは、異なる順序で遂行されてもよいことが明らかであろう。更に、幾つかのオペレーションは、順次ではなく、並列に遂行されてもよい。
【００５０】
本発明の実施形態は、特定のプログラミング言語を参照して説明しなかった。ここに述べた本発明の実施形態の教示を具現化するのに、種々のプログラミング言語を使用できることが明らかである。
【００５１】
以上、特定の規範的な実施形態を参照して本発明の実施形態を説明した。特許請求の範囲に述べた本発明の広い精神及び範囲から逸脱せずに種々の変更がなされ得ることが明らかであろう。従って、以上の説明及び添付図面は、単なる例示に過ぎず、それに限定されるものではないと考えられる。
【符号の説明】
【００５２】
１００：アーキテクチャー
１０１：メタデータ処理ソフトウェア
１０３：オペレーティングシステム（ＯＳ）カーネル
１０５：グラフィックユーザインターフェイスソフトウェア
１０７：ｅ−メールソフトウェア
１０９：他のアプリケーション
１１１：インターフェイス
１１３：インポーター
１１５：メタデータデータベース
１１７：ファイルシステムディレクトリ
１１９：コンテンツで見出すソフトウェア
１２０：メタデータで見出すソフトウェア
１２１：インデックスファイル
１２２：インデックスソフトウェア
２００：システム
２０１：ファイルシステム
２０２：コンテンツファイルデータベース
２０４：ユーザデーモン
２０５：セキュリティマネージャー
２０６：セキュリティプロフィール
２０７：シークレットキー
２０８：ファイル
２０９：プライベートメタデータ
２１０：プライベートメタデータ識別子
２１２：ファイル
３０１、３０２：クライアント
３０３：サーバー
３０４：ネットワーク
【図１】
0005576569.tif 000002
【図２】
0005576569.tif 000003
【図３】
0005576569.tif 000004
【図４】
0005576569.tif 000005
【図５】
0005576569.tif 000006
【図６】
0005576569.tif 000007
【図７】
0005576569.tif 000008