(57)【要約】      （修正有）【課題】動的階層的データシステムを提供する。【解決手段】通常の動作では、ファイルシステムがアプリケーションに提供する記憶機能は受動的、かつ、アドホックであり制約はない。アプリケーションロジックは、上位のアーキテクチャレイヤからファイルシステムの構造を管理する。本発明は、ファイルシステムに、より動的に、プロアクティブにかつドメイン固有の方法で作用する能力を付加することにより、ファイルシステムの通常の期待を拡張する。これには、ドメイン特有の要件をサポートする新しいコンテンツと構造を自律的に作成することを含む。ソフトウェアエージェントは、ファイルシステムへの構造変更を監視しＳ１２、一定の構造変更と一致する構成ファイルを探しＳ１４、追加的サブディレクトリを作成することにより、ディレクトリ作成コマンドに応じることにより、ファイルシステムを修正するＳ１６。【選択図】図３
2018120580.tif 000002
【特許請求の範囲】
【請求項１】
階層的データシステムへの構造変更を監視し、少なくとも１つの特定構造変更を認識し、前記特定構造変更に応じて、前記構造変更により指示されていない前記階層的データシステムの一以上の操作を適用するように構成された一以上のエージェントを有する階層的データシステム。
【請求項２】
前記階層的データシステムはパスを定義し、エージェントは構造変更を少なくとも１つのパステンプレートと比較し、前記構造変更の、テンプレートの一部との一致を見つけると、前記テンプレートの残りに従って前記一以上の操作を適用する、
請求項１に記載の階層的データシステム。
【請求項３】
前記テンプレートは前記階層的データシステムの設定ファイルに含まれる、
請求項２に記載の階層的データシステム。
【請求項４】
前記一以上の操作はファイルシステムにおいてドメイン特有の構造を強制する、
請求項１ないし３いずれか一項に記載の階層的データシステム。
【請求項５】
前記一以上の操作はファイルシステムへのデータエントリーを制約する、
請求項１ないし４いずれか一項に記載の階層的データシステム。
【請求項６】
階層的データシステムを管理する方法であって、
少なくとも１つの特定構造変更を認識するために前記階層的データシステムへの構造変更を監視すること、
前記特定構造変更の認識に応じて、前記構造変更により特定されていない前記階層的データシステムの一以上の操作を適用することとを含む、
方法。
【請求項７】
計算装置により実行されると、前記計算装置に請求項６に記載の方法を実行させるコンピュータ可読命令を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムにおける、排他的ではないが特に大規模コンピュータシステムにおけるデータ管理に用いられるファイルシステムのような階層的データシステムの分野に関する。
【背景技術】
【０００２】
「データ層（ｄａｔａ  ｔｉｅｒｓ）」という概念はソフトウェアエンジニアリングにおいて広く用いられている。多層アーキテクチャは、プレゼンテーション、アプリケーション、処理、及びデータ管理の機能が物理的に分離されたクライアントサーバアーキテクチャである。一般的にはｎ層アーキテクチャが考えられるが、最も一般的なアーキテクチャは３層アーキテクチャである。３層アーキテクチャは一般的にプレゼンテーション層、論理または処理層、及びデータ記憶層により構成される。
【０００３】
図１はかかる３層アーキテクチャを単純化して示している。（図１に示すように）各層が異なるハードウェアに実装されていると考えることも役に立つが、これは本質的なことではない。
【０００４】
この例では、第１層は最上位のクライアント層であり、アプリケーションのユーザインターフェースを含む。これは、図１のクライアント１００により示されるデスクトップＰＣまたはワークステーション上で実行され、標準的なグラフィカルユーザインターフェースを用いるものであってもよい。この層は中間層である第２層（論理層とも言う）に（クエリなどの）データを供給する。これは、アプリケーションの機能性を提供するために、（図１ではサーバ２００により示す）ワークステーションまたはアプリケーションサーバにおいて実行される一以上のモジュールにより構成されてもよい。
【０００５】
第３層は、上位層からクエリを受け取るデータ層である。これは、図１のデータベースにより模式的に示されたコンピュータデータ記憶論理を含むデータベースサーバまたはメインフレームに実装されてもよい。データ層は、アプリケーションにより参照されるデータのための物理的記憶装置と、データへのアクセスを管理及び提供するデータベース管理システムソフトウェアとを含む。
【０００６】
第２層と第３層は、「ファイルシステム」３００として知られる物理的記憶装置の抽象概念を用いて管理される。ファイルシステム３００は、実際のファイルのいわゆる「メタデータ」を記憶する。メタデータは、ファイル名、長さ、作成日など、及び（後述する）階層におけるそのファイルの位置を含む。メタデータはファイルの実データとは別に記憶される。このように、（人間ユーザを含む）上位層は、データが実際にどう記憶されるかという細かいことにとらわれずに、ファイルシステムを取り扱うだけでよい。かかるファイルシステムは、以下に述べる階層的データシステムの一例である。
【０００７】
データの物理的記憶は、上位層とは離れたネットワークの一以上のノードに分散されてもよく、その場合、ファイルシステムはネットワークファイルシステムまたは分散ファイルシステムと呼ばれる。かかるシステムは、同じアプリケーションプログラムインターフェース（ＡＰＩ）とセマンティクスとを用いて、ローカルファイルとまったく同じ方法でファイルにアクセスできる点で、クライアント（アプリケーションまたは人間ユーザ）に対して透過的であり得る。上記のように、ファイルシステムは、物理的データ記憶装置の抽象概念（ａｂｓｔｒａｃｔｉｏｎ）と考えられるが、「仮想ファイルシステム」は、例えばローカルファイルシステムとネットワークファイルシステムを１つに統合することにより、この概念をもう１段階先に進めるものである。これ以降、「ファイルシステム」とはこの種のファイルシステムをすべて含む。
【０００８】
各層の間にＡＰＩがあり、各ＡＰＩは異なる層のソフトウェアが互いに作用する仕様である。このように、第１層から発せられた要求すなわちデータ操作は、その要求を第３層ファイルシステムが理解できるクエリのフォーマットに変換するＡＰＩラッパーを与えられる。
【０００９】
ファイルシステム３００は、ファイルとフォルダ（ディレクトリとしても知られており、２つの用語は以後同意語として用いる）よりなる。フォルダは、ファイル及び／又は他のディレクトリへの参照を有するファイルシステムカタログ化構造として定義される。一般的に、関連ファイルは同じディレクトリに記憶され、ディレクトリはツリー状構造を用いて複数レベルで構成される。このようなファイルシステムは階層的ファイルシステムと呼ばれる。より正確に言うと、構造は逆さツリー状構造である。かかるファイルシステムの最上位レベルのディレクトリがルートディレクトリと呼ばれるからである。第１のディレクトリ内の第２のディレクトリはサブディレクトリと呼ばれ、このサブディレクトリは第１のディレクトリの、又はそれを含むその他の任意の上位ディレクトリの子孫であると言われる。逆に、第１のディレクトリは第２のディレクトリ、すなわちサブディレクトリの「親」と呼ばれることもあり、第１の、及び上位の任意のディレクトリは第２のディレクトリの「先祖」とも呼ばれる。「兄弟」ノードは同じ親ノードを有する。ユーザ（またはアプリケーション）は、ファイルシステムにコマンドを入力して、特定のディレクトリにナビゲーションする。現在考慮しているディレクトリ（すなわち、データ操作のためにユーザまたはアプリケーションが「位置している（ｌｏｃａｔｅｄ）」ディレクトリ）は、「コンテキストディレクトリ」または「ワーキングディレクトリ」と呼ばれる。
【００１０】
ファイルシステム３００への入力はいわゆる「セマンティクス」に従う。これは命令され得る操作（ｔｈｅ  ｋｉｎｄｓ  ｏｆ  ｏｐｅｒａｔｉｏｎ）と、その結果とを定義するものである。「ファイルシステムセマンティクス」は、ファイルシステムにより理解されるディレクトリ変更、作成、記憶、読み出しなどのコマンドセットを含む。かかるコマンド（「命令」としても知られている）は、ファイルシステムを管理するのに用いられるＬｉｎｕｘ（登録商標）などのオペレーティングシステムの一部として規定されている。ファイルシステムにより認識され、ファイルまたはフォルダに記憶できるデータタイプ（すなわち「ドメイン」）は、「ドメイン制約」により規定され得る。
【００１１】
ファイルシステムの一例はＬｉｎｕｘファイルシステムであり、これは上記のツリー状構造（ｔｒｅｅ−ｌｉｋｅ  ｓｔｒｕｃｔｕｒｅ）に従う。Ｌｉｎｕｘにおける関連コマンドには、新しいディレクトリを作成するｍｋｄｉｒ、コンテキストディレクトリを変更するｃｄ、ツリー状フォーマットでディレクトリのリスト内容を列挙するｔｒｅｅが含まれる。Ｌｉｎｕｘで提供される他のコマンドｃｈｒｏｏｔは、アパレントルートディレクトリを変更して、ディレクトリツリーの他の部分へのアクセスを防止する。Ｌｉｎｕｘファイルシステムにおける隠しファイル（ｈｉｄｄｅｎ  ｆｉｌｅｓ）はイニシャルピリオド（．）により示される。Ｌｉｎｕｘは、ファイルシステムへの変更を監視し、変更をアプリケーションに報告するｉｎｏｔｉｆｙと呼ばれるツールを提供する。ｉｎｏｔｉｆｙを用いて、指定されたディレクトリまたはファイルをウォッチして、オープン、クローズ、移動／名前変更、削除、作成または属性変更を含む指定イベントを報告することができる。Ｌｉｎｕｘで利用できる他のメカニズム「Ｆｉｌｅｓｙｓｔｅｍ  ｉｎ  Ｕｓｅｒｓｐａｃｅ」またはＦＵＳＥにより、アプリケーションコードは仮想ファイルシステムを構成しインターフェースすることができる。例えば、ＦＵＳＥは、Ｇｍａｉｌアカウントを記憶に用いる仮想ファイルシステムＧｍａｉｌＦＳの開発に用いられてきた。
【００１２】
図１を再び参照して、クライアント層はＨＴＭＬ、ＣＳＳ及びＪａｖａ  Ｓｃｒｉｐｔ（登録商標）などのウェブ開発ツールを利用して、ウェブベースインターフェース及びモバイルインターフェースのためのｉＯＳやＡｎｄｒｏｉｄなどのモバイルプラットフォームを提供してもよい。論理層はＲｕｂｙ  ｏｎ  Ｒａｉｌｓ、Ｊａｖａ（登録商標）、．ＮＥＴ、またはその他の利用可能な多数のプラットフォームのうちの１つを利用できる。ファイルシステムは、リレーショナルデータベース、オペレーショナルデータベース、エンドユーザデータベース、分散データベース及び分析データベースなどの異なる種類のデータベースを含み得る。
【００１３】
Ｒｕｂｙ−ｏｎ−Ｒａｉｌｓ（及び同様の）ウェブアプリケーションフレームワークは、ウェブアプリケーションにおける過剰なボイラープレートのオーバーヘッドへの反応である。これらは、リレーショナルデータベースバックエンドがあるアーキテクチャにおける「設定より規約（ｃｏｎｖｅｎｔｉｏｎ−ｏｖｅｒ−ｃｏｎｆｉｇｕｒａｔｉｏｎ）」が好ましい高速アプリケーション開発環境である。設定より規約とは、開発者が設定を詳細に指定することを期待するより、規約のセットの不履行により、開発者が記述しなければならないコード量を低減することを意味する。同様のモチベーションは説明する発明の背景にもある。現代の企業は多岐にわたる。大きな変化があるこの環境において、ファイルシステムメカニズムは相互運用的かつ柔軟な一貫した層を提供する。ファイルシステムが提供するアクセスの普遍性をレバレッジし、その受動性を変えることが望ましい。
【００１４】
より一般的に、既存のファイルシステムは次のような欠点を有している：
ファイルシステムが受動的である−幾つかのアプリケーションではダイナミズムを導入することが有利である。
アドホック構造−構造変化は、特にファイルシステムを共有するときに、すぐに乱雑さにつながる。
ファイルシステムは「処理能力なし（ｄｕｍｂ）」である。ファイルシステムは単に何も描かれていないキャンバスを提供するだけであり、将来の発展に対する助言（道しるべ）を与えるものではない。
【発明の概要】
【００１５】
上記の通り、ファイルシステムメカニズムは相互運用性と柔軟性のある一貫したレイヤを提供する。本発明の実施形態は、ファイルシステムが提供するアクセスの普遍性をレバレッジするが、その受動的特性を変更して、ファイルシステムが一定の入力に対して、より具体的にはディレクトリやファイルの作成など構造変更に対して先回りして反応するという意味で動的なファイルシステムが得られる。ファイルシステムは、例えば、少なくとも１つの追加的ディレクトリ又はファイルを作成することにより、及び／又は一定のディレクトリ（１つ又は複数）へのアクセスを制約することにより、反応し得る。かかる効果は以下、「操作（ｍａｎｉｐｕｌａｔｉｏｎｓ）」と呼ぶ。換言すると、ファイルシステムのセマンティクスは、「処理能力のない（ｄｕｍｂ）」記憶及び読み出しメカニズムから、構造的制約及び動的応答を含むように拡張する。これにより、アプリケーション開発者達の生産性が向上する。さらに、同じ原理は、ファイルシステムとは別の、他種の階層的データシステムに適用可能である。
【００１６】
本発明の第１の態様による階層的データシステムは、階層的データシステムへの構造変更を監視し、少なくとも１つの特定構造変更を認識し、前記特定構造変更に応じて、前記構造変更により指示されていない前記階層的データシステムの一以上の操作を適用するように構成された一以上のエージェントを有する階層的データシステムである。
【００１７】
ここで、「エージェント」は、階層的データシステムの一部として、又は階層的データシステムにアクセス可能なソフトウェア形式で実装してもよい。「構造変更」は、以下に説明するように、階層的データシステムの構造に何らかの変更を引き起こす（「ユーザ」がアプリケーションプログラムを含み得る）ユーザ入力の結果として、階層的データシステムで発生する一定のイベントを指す。「操作（ｍａｎｉｐｕｌａｔｉｏｎｓ）」とは、ユーザによる、アクションの具体的なコマンドが無くても、構造変更に応じて自律的に実行されるアクションを指す。
【００１８】
好ましくは、前記階層的データシステムはパスを定義し、一以上のエージェントは構造変更を少なくとも１つのパステンプレートと比較し、前記構造変更の、テンプレートの一部との一致を見つけると、前記テンプレートの残りに従って前記一以上の操作を適用する。
【００１９】
ここで、前記テンプレートは前記階層的データシステムの設定ファイルに含まれてもよい。
【００２０】
一実施形態では、前記階層的データシステムは階層構造のディレクトリを含む。この実施形態において、前記エージェントは、構造変更に応じて、コンテキストディレクトリと、前記構造変更と一致する前記設定ファイルの上位ディレクトリとを検索する。
【００２１】
かかる検索では、好ましくは、前記エージェントは最初に前記コンテキストディレクトリを検索し、前記設定ファイルが見つからない場合、前記階層構造の上位レベルを漸進的に検索する。このようにして、設定ファイルが階層的データシステム内のあるレベルに設けられ、一以上の操作に対して所望の一般性を提供する。
【００２２】
エージェントが応じる特定の構造変更は、ディレクトリ作成コマンドを含み得る。
【００２３】
エージェントにより適用される前記一以上の操作は、前記ディレクトリの少なくとも１つのサブディレクトリの作成を含む。その他の可能性のある操作には、前記ディレクトリ内に少なくとも１つのファイルを作成することを含む。これにより、変更により生じるユーザ（又はアプリケーション）の作業が節約され、すべてのユーザに対して一貫した構造を強制する。
【００２４】
上記のどの階層的データシステムにおいても、好ましくは、一以上の操作はファイルシステムにおいてドメイン特有の構造（ｄｏｍａｉｎ−ｓｐｅｃｉｆｉｃ  ｓｔｒｕｃｔｕｒｅｓ）を強制する。例えば、後続のデータ入力は、特定タイプのデータと、特定サブディレクトリとに制約される。
【００２５】
前記一以上の操作はファイルシステムへのデータエントリーを制約してもよい。例えば、一以上のディレクトリに対するアクセスが制約されてもよい。
【００２６】
本発明の第２の態様による方法は、階層的データシステムを管理する方法であって、少なくとも１つの特定構造変更を認識するために前記階層的データシステムへの構造変更を監視することと、前記特定構造変更の認識に応じて、前記構造変更により特定されていない前記階層的データシステムの一以上の操作を適用することとを含む。
【００２７】
本発明の第３の態様によるコンピュータプログラムは、計算装置により実行されると、前記計算装置に上記の方法を実行させる。かかるプログラムは、一以上の非一時的コンピュータ可読記録媒体に記憶されてもよい。
【００２８】
上記の方法とプログラムとは、本発明の階層的データシステムに関して規定された任意の特徴を有していてもよい。
【００２９】
このように、本発明の実施形態は、階層的データシステムに命令／設定としてエンコードされた反応メカニズムを提供し、動作中に、ユーザ及び／又はアプリケーションにより開始される構造変更に応じてエージェントにより利用され、そのユーザ及び／又は管理者に代わって自律的に階層的データシステムを操作することができる。換言すると、階層的データシステムは、ユーザ／管理者により明示的に命令された構造変更に対して、反射的又は先を見越した（ｐｒｏａｃｔｉｖｅ）操作を実行する。この、階層的データシステムの特質に対する連続的な調整により、階層的データシステムがアプリケーション自体のセマンティクスを組み込むので、ユーザへのサポートを強化できる。
【００３０】
通常の動作では、階層的データシステムがアプリケーションに提供する記憶機能は受動的かつアドホックであり制約はない。アプリケーションロジックは上位のアーキテクチャレイヤから階層的データシステムの構造を管理する。本発明は、階層的データシステムに、より動的に、プロアクティブにかつドメイン固有の方法で作用する能力を付加することにより、階層的データシステムの通常の期待を拡張する。これは、階層的データシステムを操作して、新しいコンテンツ及び構造を自律的に作成して、ドメイン特有の要件をサポートすることを含む。この発明は、完成システム内のコンポーネントとして実現されることを意図している。
【図面の簡単な説明】
【００３１】
【図１】多層アーキテクチャを示す模式図である。
【図２】本発明の実施形態の動作原理を示す図である。
【図３】一実施形態で利用される「エージェント」の動作を示すフローチャートである。
【図４】本発明の一実施形態の実装に適したコンピュータシステムを示す図である。
【発明を実施するための形態】
【００３２】
本発明は、ファイルシステムであり得るがこれに限定されない階層的データシステムの動作にダイナミズムを導入するメカニズムを提供する。すなわち、ファイルシステムはほぼ永続的に存在するデータを記憶するのに使われるが、これは本発明にとって本質的なことではなく、本発明は一時的データにも適用可能である。以下、用語「ファイルシステム」を便宜的に用い、Ｌｉｎｕｘファイルシステムを例として説明する。
【００３３】
既述の通り、既存のファイルシステムには限界があり、動的発展性を加えることが有用であり、それによりファイルシステムが、一定の入力に対して、その入力により直接的に示唆されない方法で自動的に反応するシナリオがある。関心のある入力の種類は、ファイルシステムの構造に影響を与え、「構造変化」と呼ばれる種類である。例えば、ファイルシステムのユーザが「ファイルエクスプローラ」アプリケーション（またはコマンドライン）を用いてディレクトリを追加するとき、あるドメインモデルと知識構造に従って追加的構造アーティファクトを作成することにより、ユーザ体験を前向きに向上することが可能である。これらの追加的構造的アーティファクトはフォルダとファイルを含むが、これらに限定されない。このような構造的アーティファクトの作成はファイルシステムの「操作」の一例である。説明する実施形態において、作成されるフォルダ／ファイルは、ユーザ入力により作成された構造の子孫フォルダ／ファイルであるが、本発明はこれに限定されない。より複雑な結果が生じ得る他の命令を導入することも可能である。例えば、本発明は、ツリーの他のポイント（例えば、兄弟ノード）を変更してもよい。
【００３４】
このイノベーションは、ファイルシステムベースのダイナミック知識管理アプリケーションを高速に構築するのに用い得る特徴のあるアーキテクチャの要素である。これは、重要なユースケースに対して追加的利益と効率改善を得ることができる３層アーキテクチャの再調整に基づく。この再調整において、アプリケーション開発者の視点は、アプリケーションとインターフェースの従来の概念から、アプリケーション開発者がドメイン特有の処理に対処するだけでよいように、再発する相互作用パターンがミドルウェアとＡＰＩにエンコードされる中間層のデータ指向ビューにシフトし得る。このメカニズムは、スケーラブルかつ弾力的なアプリケーションにとって都合のよい（どのように、かつどこに状態を維持するかを含む）一定スタイルの開発も強制する。
【００３５】
ここに提示する具体的なイノベーションは、イベントベースプログラミング（ｅｖｅｎｔ  ｂａｓｅｄ  ｐｒｏｇｒａｍｍｉｎｇ）やもちろんファイルシステムデザインなどの多くのものからの影響を受ける。オペレーティングシステムやファイルシステムに対して様々なツール（及び「ハック（ｈａｃｋｓ）」が利用可能である。これには、仮想ファイルシステム（すなわち、ＦＵＳＥ）、ファイルシステムイベント（すなわち、ｉｎｏｔｉｆｙ）、分散ファイルシステムなどが含まれる。仮想ファイルシステムが様々な基盤システムに対するファイルシステムインターフェースを提供するように展開されている。例えば、ＧｍａｉｌＦＳはｇｍａｉｌリソースを仮想ファイルシステムとして提供（ｅｘｐｏｓｅ）している。ファイルシステムイベント（Ｌｉｎｕｘのｉｎｏｔｉｆｙなど）は、コンパイルタスクの自動化などのために、開発者達により一般的に使われている。
【００３６】
ここに提示するイノベーションは通常のファイルシステムセマンティクスを拡張して、ファイルシステム相互作用によりトリガーされた時に、複数のメカニズムを使ってファイルシステムを動的に操作するユニークな機能である。
【００３７】
本発明の原理を図２に示す。階層データシステムは、この場合にはファイルシステム３００であるが、管理者によって事前にファイルシステムに対して出された命令／設定を有する。ファイルシステム３００は、一以上のプロセッサにより実行されるソフトウェアの形式の監視・反応エージェント４００（以下、単に「エージェント」と呼ぶ）により監視される。複数のエージェント（複数のソフトウェアモジュール）がファイルシステムの各パーツや階層レベルを監視するために設けられても良く、システム全体を監視する１つのマルチスレッドエージェントがあってもよい。図中、「監視」と示したように、エージェント４００はファイルシステム３００におけるアクティビティを監視する。監視により所定テンプレートに一致するイベントが検出されたとき、エージェントは設定ファイル（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｆｉｌｅ）（図２において「設定」と示した）を抽出する。これにより、（図中、「実行」と示したように）エージェント４００により幾つかの付加的振る舞いが実行される。
【００３８】
よって、エージェント（複数の場合を含む）はファイルシステムから複数の命令を読み出すことができることを要する。具体的なインスタンスにより用いられる選択される命名規約（ｎａｍｉｎｇ  ｃｏｎｖｅｎｔｉｏｎ）が明確に特定されなければならないが、この例示的実施形態では「．ｃｏｎｆｉｇ」と名付けられた隠しファイルを用いる。
【００３９】
図３は、エージェント４００により実行される動作を示すフローチャートである。プロセスはステップＳ１０で始まる。ステップＳ１２において、エージェント４００はファイルシステム３００中のアクティビティ（ファイルシステムイベント）を監視する。エージェントはファイルシステムへの構造的変更（ｓｔｒｕｃｔｕｒａｌ  ｃｈａｎｇｅｓ）を監視する。特に、エージェントは、ユーザがディレクトリに新しいコンテンツを入れる（ｐｌａｃｅ）場合を含む（がこれに限定されない）作成イベントを探している。例えば、Ｌｉｎｕｘファイルシステムの場合、ステップＳ１２では、上記のｉｎｏｔｉｆｙ関数が利用され得る。これは、複数のファイルシステムイベントのストリームを提供する。このストリームを（例えば、「ディレクトリ作成」イベントに限定することにより）フィルタして、プロセスの次のステップを開始するのに用いることができる。代替案として、将来のメカニズムでは、監視機能を直接組み込むことができる新しいファイルシステムソフトウェアを作成することができる。
【００４０】
ファイル作成イベントを検出すると、エージェントは上記の．ｃｏｎｆｉｇファイルのコンテキストディレクトリを調べる。エージェントにエンコードされたディスカバリアルゴリズムがどこで設定を探すか決定する。第１に、ステップＳ１４において、エージェントはコンテキストディレクトリ、すなわち設定ファイル（デフォルトでは「．ｃｏｎｆｉｇ」）に対するアクティビティが発生したディレクトリを調べる。最終的に見つかった設定ファイル（Ｓ１４、「Ｙ」）は、後処理を行うのに用いられる命令を含む。ステップＳ１６において、エージェントはその設定を用いて、別のファイルシステム操作を確立する。その後、監視がＳ１２で再開される。
【００４１】
このファイルが無ければ（Ｓ１４、「Ｎ」）、ステップＳ１８に進み、コンテキストディレクトリがファイルシステム３００のルートにあるかどうかエージェントがチェックする。そうであれば（Ｓ１８、「Ｙ」）、ツリーには調べるべき上位レベルはなく、ステップＳ１２に戻る。一方、コンテキストディレクトリがルートレベルにまだなければ（Ｓ１８、「Ｎ」）、エージェントがコンテキストを親ディレクトリに変更し、ステップＳ１４を繰り返す。このように、エージェントツリー中の上位をナビゲートし、同ファイルを探す。
【００４２】
このように、ファイルシステムエージェントは、ディスカバーされた設定からの命令（使用しているＯＳにおいてすでに利用可能なコマンドである命令）を用いて、管理者に代わってファイルシステムを操作する。これは最初に別のフィルタリングやマッチングプロセスを含む。例えば、これはもう少し細かい粒度のフィルタリングをするワイルドカードを使用する能力を含む。
【００４３】
ここで、具体例を説明してプロセスをより具体的に例示する。しかし、言うまでもなく、本発明は以下の例に限定されるものではない。
【００４４】
病院における患者の情報管理のシナリオを一例として用いる。病院においてファイルシステムを患者の簡単な管理ツールとして用いたいものとする。患者ディレクトリは、空のとき、次のように見える：
．
└──患者
ファイルシステムは各患者のディレクトリを含み、要求された情報を追加するため、ウェブアプリケーション（ウェブまたはｈｔｔｐベースのＡＰＩ）を用いて病院データベースにアクセスすることが期待される。典型的な構成は、  ／患者  内の新しい各ディレクトを用いて、システムにおける新しい患者を表す。例えば、「ジョン・スミス」というディレクトリは次の構造となる：
．
└──患者
└──ジョン・スミス
しかし、この実施形態が起動されると、別の構造（例えば、一以上のディレクトリ）が作成され、将来、追加コンテンツのプレースホルダーとして働く。例えば、結果は次の通りである：
．
└──患者
└──ジョン・スミス
├──予約
└──スキャン
よって、本実施形態のエージェントは、「ジョン・スミス」に関するｍｋｄｉｒコマンドの入力を検出し、自動的に「予約」ディレクトリと「スキャン」ディレクトリを作成している。これらは、新しい標識として働き、ユーザがどのようにファイルシステムと相互作用するか導く役に立つ。すなわち、ユーザが新たな情報をデータベースに追加するとき、ファイルシステムは、適切な支持構造（ｓｕｐｐｏｒｔｉｎｇ  ｓｔｒｕｃｔｕｒｅ）を自動的に作成することにより、このプロセスを支援する。
【００４５】
このように、ファイルシステムは、患者のディレクトリの作成が自動的に新しい２つのサブディレクトリの作成をトリガーするという点で「動的」になる。２つのサブディレクトリは、患者に関する追加情報が入れられるコンテナである。
【００４６】
これは、管理者が事前に命令を、ファイルシステムエージェントが使うファイルシステムにエンコードすることにより実現される。この例では、隠しファイルが、新しい挿入を受け取るディレクトリに挿入される。特に、ファイル名はエージェントソフトウェアで設定可能でなければならないが、この例の場合、それは「．ｃｏｎｆｉｇ」と呼ばれる。
．
└──患者
├──．ｃｏｎｆｉｇ
└──ジョン・スミス
├──予約
└──スキャン
上記に対応して、Ｕｎｉｘ端末におけるコマンドラインのセッションは、下記をユーザに提示する。ここで、＄はＵｎｉｘ端末のプロンプトである：
＄ツリー
．
└──患者
＄ｍｋｄｉｒ  患者／ジョン・スミス
＄ツリー
．
└──患者
└──ジョン・スミス
├──  予約
└──  スキャン
．ｃｏｎｆｉｇファイルのコンテンツは：
｛｝
予約
スキャン
このように、．ｃｏｎｆｉｇファイルは、新しいサブディレクトリである「予約」と「スキャン」がどう作成されるべきか命令する。この単純なフォーマットは、挿入され得る構造エンティティ（ｓｔｒｕｃｔｕｒａｌ  ｅｎｔｉｔｉｅｓ）のタイプ（ｎａｔｕｒｅ）について、処理エージェントに命令する。これら２つのディレクトリ名は、作成されたエンティティのコンテキストで、すなわちディレクトリツリーにおける現在レベルにおいて評価される。
【００４７】
代替的に、ファイルシステムの先頭の一箇所でアプリケーションを確定してもよい：
．
├──．ｃｏｎｆｉｇ
└──Ａ病院
└──患者
└──ジョン・スミス
├──予約
└──スキャン
この場合、新しい患者が／患者ディレクトリに作成されると、ローカル設定が無ければ、ディレクトリツリーを上って、適切な設定を見いだす。この例では、設定はファイルシステムのルートで見つかる。
．ｃｏｎｆｉｇファイルのコンテンツは：
＄
｛｝
患者
｛｝
予約
スキャン
これは一実施形態における設定の一例である。インデントは重要であり、ファイルシステムの階層を表す。＄はファイルシステムのルートを表す。記号｛｝はストリング一致（ｍａｔｃｈｉｎｇ  ｓｔｒｉｎｇ）を示すワイルドカードである。
【００４８】
コンテキストパス：
＄
Ａ病院
患者
ジョン・スミス
が、パステンプレートの１つの茎（ｓｔｅｍ）と一致する場合、残りのテンプレートを調べて、ファイルシステムにすべき必要な変更（この場合、「約束」及び「スキャン」）を導出する。言い換えると、エージェントは、ｃｏｎｆｉｇファイルがたった今作成されたばかりのディレクトに適用可能であるか、チェックする。ｃｏｎｆｉｇファイルは複数のパステンプレート（ｐａｔｈ  ｔｅｍｐｌａｔｅｓ）よりなる。新たに作成されたエンティティがパステンプレートの１つと一致するとき、その次に残りのテンプレートを見てもよい。
【００４９】
図４は、データストレージサーバなどの計算デバイス９００を示すブロック図である。この計算デバイスは本発明を具現化し、本発明の方法を実装するのに用いることができる。計算デバイスはプロセッサ９９３とメモリ９９４を有する。任意的に、計算デバイスは、他の計算デバイスと、例えば本発明の実施形態の計算デバイスと通信するネットワークインターフェース９９７も含む。
【００５０】
例えば、一実施形態は、かかる計算デバイスのネットワークより構成されていてもよい。任意的に、計算デバイスは、キーボードとマウス９９６などの一以上の入力メカニズムと、一以上のモニタ９９５などのディスプレイユニットとも含む。コンポーネントはバス９９２を介して互いに接続可能である。
【００５１】
メモリ９９４はコンピュータ読み取り可能媒体を含む。この用語は、例えば、コンピュータ実行可能命令を担い、又はその中にデータ構造を格納するように構成された１つの媒体又は複数の媒体（例えば、集中型または分散型データベース及び／又は関連するキャッシュ及びサーバ）を指す。コンピュータ実行可能命令は、例えば、命令とデータであって、汎用コンピュータ、特殊用途コンピュータ、又は特殊用途プロセッサデバイス（例えば、一以上のプロセッサ）によりアクセス可能であり、これらに、上記の「エージェント」を含む上記の一以上の機能又は動作を実行させるものを含んでもよい。このように、「コンピュータ読み取り可能記憶媒体」との用語は、そのマシンにより実行される一組の命令を記憶、エンコード、または担うことができ、そのマシンに、本開示の方法のいずれかを実行させる任意の媒体を含む。したがって、「コンピュータ可読記憶媒体」との用語は、固体メモリ、光媒体及び磁気媒体を含むが、これらに限定されない。限定ではなく例として、かかるコンピュータ読み取り可能媒体は、非一時的コンピュータ読み取り可能記憶媒体を含む、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、電気的消去可能プログラマブルリードオンリーメモリ（ＥＥＰＲＯＭ）、コンパクトディスクリードオンリーメモリ（ＣＤＲＯＭ）又はその他の光ディスク記憶媒体、磁気ディスク記憶媒体又はその他の磁気記憶デバイス、フラッシュメモリデバイス（例えば、固体メモリデバイス）を含む。
【００５２】
プロセッサ９９３は、計算デバイスを制御し、処理動作を実行し、例えば、本明細書及び特許請求の範囲に記載した「エージェント」の動作を実装する、メモリに格納されたコードを実行するように構成されている。メモリ９９４はプロセッサ９９３により読み書きされるデータを格納する。本明細書に説明するように、プロセッサは、マイクロプロセッサ、中央処理装置などの一以上の汎用処理デバイスを含んでも良い。プロセッサは、例えば、ＣＩＳＣ（ｃｏｍｐｌｅｘ  ｉｎｓｔｒｕｃｔｉｏｎ  ｓｅｔ  ｃｏｍｐｕｔｉｎｇ）マイクロプロセッサ、ＲＩＳＣ（ｒｅｄｕｃｅｄ  ｉｎｓｔｒｕｃｔｉｏｎ  ｓｅｔ  ｃｏｍｐｕｔｉｎｇ）マイクロプロセッサ、ＶＬＩＷ（ｖｅｒｙ  ｌｏｎｇ  ｉｎｓｔｒｕｃｔｉｏｎ  ｗｏｒｄ）マイクロプロセッサ、他の命令セットを実装したプロセッサ、又は複数の命令セットの組み合わせを実装したプロセッサを含む。プロセッサは、例えば、一以上の特殊用途処理デバイス、例えば特定用途集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサなどを含む。一以上の実施形態では、プロセッサは、本明細書で説明される動作及びステップを実行する命令を実行するように構成されている。
【００５３】
ディスプレイユニット９９７は、計算デバイスにより格納されたデータを表示してもよく、ユーザと、計算デバイスに格納されたプログラム及びデータとの間の相互作用を可能にするカーソル、ダイアローグボックス及びスクリーンを表示してもよい。入力メカニズム９９６は、例えば、ユーザが計算デバイスにデータ及び命令、例えば、ファイルシステムに向けたコマンドを入力できるようにする。
【００５４】
ネットワークインターフェース（ネットワークＩ／Ｆ）９９７は、インターネットなどのネットワークに接続されてもよく、そのネットワークを介して他の計算デバイスに接続可能である。ネットワークＩ／Ｆ９９７は、例えば、ネットワークを介して他の装置との間でのデータ入出力を制御する。マイクロホン、スピーカ、プリンタ、パワーサプライ、ファン、ケース、スキャナー、トラッカーボールなどの他の周辺デバイスが計算デバイスに含まれても良い。
【００５５】
このように、本発明を具体化する方法は、図４に示したような計算デバイスで実行されてもよい。かかる計算デバイスは、図４に示したすべてのコンポーネントを有する必要はなく、それらのコンポーネントの一部により構成されてもよい。本発明を実施する方法は、ネットワークを介してファイルシステムと通信する１つの計算デバイスにより実行されてもよい。計算デバイスはファイルシステム自体の一部（より一般的には、階層的データシステムの一部）であってもよい。
【００５６】
よって、要約すると、本発明の実施形態は、動作中に、ソフトウェアエージェントが外部からの構造変更入力に応答するために利用できるように、命令／設定をファイルシステムにエンコードし、さらにユーザ及び／又は管理者の代わりに自動的にファイルシステムを操作する。この、ファイルシステムの特質に対する連続的な調整により、ファイルシステムがアプリケーション自体のセマンティクスを組み込むので、ユーザへのサポートを強化できる。
【００５７】
本発明の範囲において様々な修正が可能である。
【００５８】
上記の実施形態において、エージェントは追加のディレクトリを作成する。しかし、エージェントの振る舞いはこれに限定されず、（一以上のディレクトリの作成に加え、又はその作成に関わらず）ファイルなどの新しいコンテンツ及び／又は構造の作成、及び特別な解釈または振る舞いを有するディレクトリ又はファイルの作成を含むことができる。エージェントの振る舞いには、例えば、ｃｈｒｏｏｔや同様の関数を用いた、一定ディレクトリへのアクセス制限も含まれ得る。
【００５９】
上記ではＬｉｎｕｘを参照した。しかし、本発明の実施形態はどんな種類のオペレーティングシステムにも、オペレーティングシステムに関連するどんなファイルシステムにも適用できる。例としては、Ｈｉｅｒａｒｃｈｉｃａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ  （ＨＦＳ）を含むＡｐｐｌｅ  Ｍａｃ  ＯＳ、Ｎｅｗ  Ｔｅｃｈｎｏｌｏｇｙ  Ｆｉｌｅ  Ｓｙｓｔｅｍ  （ＮＴＦＳ）を有するＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ、Ｆｉｌｅｓ−１１  ｖｉｒｔｕａｌ  ｆｉｌｅｓｙｓｔｅｍを有するＯｐｅｎＶＭＳがある。より一般的に、本発明は、ファイルやフォルダなどの階層的構造を利用するどんな階層的データシステムにも、Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒｓ  （ＵＲＩｓ）に基づく構造にも適用できる。
【００６０】
これに関して、かかるシステムはデータを記憶する必要はなく、例えば、検索メカニズムであってもよい。例えば、階層的データシステムは、ローカルソースから、記憶装置にリモートアクセス可能なクラウドへの移行を管理し易くするのに用いられ得る。階層的データシステムの動作は、相互作用の周りのすべての点においてトリガーされ得るプロセスに囲まれていてもよく、継続か中止かのプリチェックも有していてもよい。これは、新しいエンティティが作成された場合に起きるが、削除、付加などの場合にも起きる。
【００６１】
本発明は、ファイルシステムがアプリケーション自体になるより大きなアーキテクチャの一部を構成してもよく、プロトタイプ開発の鞘左を加速するために用いられてもよい。特に、上記のメカニズムは、Ｗｅｂ  ＡＰＩの基盤メカニズムの一部として用いられてもよい。
【００６２】
上記のどの態様においても、様々な特徴（ｆｅａｔｕｒｅｓ）をハードウェアで実現しても、プロセッサ上で動作するソフトウェアモジュールとして実現してもよい。一態様の特徴を他の態様の特徴に適用することもできる。
【００６３】
実施形態について、次の付記を記す。
（付記１）  階層的データシステムへの構造変更を監視し、少なくとも１つの特定構造変更を認識し、前記特定構造変更に応じて、前記構造変更により指示されていない前記階層的データシステムの一以上の操作を適用するように構成された一以上のエージェントを有する階層的データシステム。
（付記２）  前記階層的データシステムはパスを定義し、エージェントは構造変更を少なくとも１つのパステンプレートと比較し、前記構造変更の、テンプレートの一部との一致を見つけると、前記テンプレートの残りに従って前記一以上の操作を適用する、付記１に記載の階層的データシステム。
（付記３）  前記テンプレートは前記階層的データシステムの設定ファイルに含まれる、付記２に記載の階層的データシステム。
（付記４）  前記階層的データシステムは階層構造のディレクトリを含む、付記３に記載の階層的データシステム。
（付記５）  前記エージェントは、構造変更に応じて、コンテキストディレクトリと、前記構造変更と一致する前記設定ファイルの上位ディレクトリとを検索する、付記４に記載の階層的データシステム。
（付記６）  前記エージェントは最初に前記コンテキストディレクトリを検索し、前記設定ファイルが見つからない場合、前記階層構造の上位レベルを漸進的に検索する、付記５に記載の階層的データシステム。
（付記７）  前記特定構造変更はディレクトリ作成コマンドを含む、付記４ないし６いずれか一項に記載の階層的データシステム。
（付記８）  前記一以上の操作は前記ディレクトリの少なくとも１つのサブディレクトリの作成を含む、付記７に記載の階層的データシステム。
（付記９）  前記一以上の操作は前記ディレクトリ内の少なくとも１つのファイルの作成を含む、付記７または８に記載の階層的データシステム。
（付記１０）  前記一以上の操作はファイルシステムにおいてドメイン特有の構造を強制する、付記１ないし９いずれか一項に記載の階層的データシステム。
（付記１１）  前記一以上の操作はファイルシステムへのデータエントリーを制約する、付記１ないし１０いずれか一項に記載の階層的データシステム。
（付記１２）  階層的データシステムを管理する方法であって、
少なくとも１つの特定構造変更を認識するために前記階層的データシステムへの構造変更を監視すること、
前記特定構造変更の認識に応じて、前記構造変更により特定されていない前記階層的データシステムの一以上の操作を適用することとを含む、方法。
（付記１３）  計算装置により実行されると、前記計算装置に付記１２に記載の方法を実行させるコンピュータ可読命令を含むコンピュータプログラム。
（付記１４）  付記１３に記載のコンピュータプログラムを記憶したコンピュータ可読媒体。
【産業上の利用可能性】
【００６４】
本発明は例えばウェブベースアプリケーションのプロトタイプ開発において有用である。より幅広く、本発明は、ファイルシステムに基づいた知識管理アプリケーションのプロトタイピングのための動的なフェデレーテッドシステムの形で知識管理システムに貢献し、ファイルシステムの期待される動作を補完することができる。実施形態では、ファイルシステムにおける新しいデータリソースの作成に反応し、結果として、ファイルシステム操作の形式で適用されなければならないドメイン制約を決定する。
【図１】
2018120580.tif 000003
【図２】
2018120580.tif 000004
【図３】
2018120580.tif 000005
【図４】
2018120580.tif 000006
【外国語明細書】
2018120580000001.pdf