JP2006244468A - 自動化されたデータ編成 - Google Patents

Abstract

【課題】データ処理を自動化するシステムおよび方法を提供する。
【解決手段】システムは、基礎をなすファイルシステムと統合され、コンピューティングシステムのイベントを、エンドユーザによって定義される少なくとも１つの自動アクションにマップするエンドユーザプログラミングモジュールを備える。また、システムは、イベントに応答して、少なくとも１つの自動アクションを実行させるイベントハンドラも含む。
【選択図】図１

Description

本発明は一般に、コンピューティングシステムに関し、より詳細には、ソフトウェアアプリケーションによるデータ処理に関する。

現代のコンピューティングシステムは、様々な実行状態において常にアクティブな多くのソフトウェアプロセスを含み得る。これらのプロセスは、オペレーティングシステムによって開始されることもでき、開始時に、またはユーザアプリケーションの起動時に初期設定されるプロセスを監視し、またはそれらのサービスを提供することもでき、ユーザアプリケーション自体とすることもできる。これらのプロセス、またはこれらのプロセスの機能の、大部分ではないにしろ、その多くは、ユーザが直接に制御できる範囲を超えるものである。したがって、これらのプロセスによって提供される機能がアクセスされる場合、そのようなアクセスは、通常は、別のソフトウェアプロセスによって成されなければならない。

ソフトウェアアプリケーションは、エンドユーザに代わって情報を管理する。コンピューティングシステム上で稼動するソフトウェアアプリケーションまたはプロセスの数は、一般に、システムが処理しなければならないデータの量とシステムが実行するよう要求されるタスクの数との関数である。これらの計算処理負荷のうちで最も効率の悪い部分は、人間との対話を必要とする部分である。コンピュータがますます強力になっているにもかかわらず、エンドユーザは、通常、大量のコンピュータ化された情報を手操作で処理しなければならない。

一般的なコンピューティングシステムの１つの主要なコンポーネントは、一般に、データファイルや実行可能プログラムなどの電子情報の永続的記憶に使用される、ハードディスクドライブなどの記憶装置である。電子情報を、使用可能な形で配置され、検索され得るように編成するために、ファイルシステムが用いられ得る。多くのファイルシステムが存在するが、それらは、一般にすべて、記憶装置上の情報の形式および場所のための概念的組織的な層を提供するものである。

ファイルシステムによって提供される概念的組織的な層は、オペレーティングシステムのプロセスのようなソフトウェアプロセスによって、記憶装置上に格納される情報の作成、アクセス、検索、削除、その他の管理に使用され得る。ファイルシステムの完全性を保護し、ファイルシステムの形式への準拠を保証するために、一般に、オペレーティングシステムの入出力プロセスのような、いくつかの特権的なソフトウェアプロセスだけがファイルシステムへの直接アクセスを許される。ファイルシステムにアクセスするアプリケーションおよびユーザは、一般に、オペレーティングシステムによって提供される機能を介してアクセスしなければならない。これらの機能は、普通、これらの機能の存在さえも知らないことがあるエンドユーザからは見えないように隠されている。一般に、この制限されたアクセスの結果として、ユーザは、例えば、ファイルシステムの属性を使ってファイル編成や位置指定といったタスクを自動化するなど、ファイルシステムの機能を十分に活用してコンピューティングタスクをより容易にすることができない。

一般に、エンドユーザは、情報のライフサイクルに従って自分のコンピュータ上の情報を管理する。そのライフサイクルの間、エンドユーザは、普通、情報を作成し、または何らかのソースから情報を獲得し、次いで、その情報が、ファイルシステムに格納される。ある時点において、エンドユーザは、その情報を検索し、その情報に基づいて操作を行う。このサイクルは、何度も繰り返され得る。現在のシステムは、エンドユーザが、このライフサイクルの一部を、効率のよい、そのエンドユーザの必要に合わせて独自のやり方で自動化することができない。

エンドユーザプログラミングモジュールは、コンピューティングシステムのエンドユーザが、１つまたは複数のユーザ定義アクションのトリガとして働き得るイベントを識別することができるようにする。エンドユーザは、このモジュールを使って、選択されたイベントの発生時に自動的に実行されるデータ処理タスクを定義することができる。これらのデータ処理タスクには、タスクの中でも特に、属性または内容についてのファイル編成およびファイルフィルタリングが含まれ得る。そのようなタスクの実行は、コンピュータシステムの１つまたは複数のコンポーネントによって実行され得る。ゆえに、エンドユーザプログラミングモジュールによって、ユーザは、データの記憶および編成を支援するカスタマイズされたエンドユーザプログラムを作成することができる。

エンドユーザプログラミングモジュールを用いて作成されるユーザプログラムは、タスクを実行するのに使用され得る複合エンティティを形成するように組み合わされ得る、１つまたは複数の基本型（basic types）から作成され得る。基本型は、さらに、他のコンポーネントと組み合わされて、より複雑なタスクを実行することができる。実行されるべきアクションは、エンドユーザがアクションを開始し、またはタスクが実行されている間にコンピュータシステムと対話することを必要とせずに、事前に選択されたイベントによって自動的にトリガされ得る。したがって、データを吟味し、そのようなデータをどこに格納すべきか決定するのではなく、ユーザは、前述の基本型を利用することによって、そのようなデータを自動的にフィルタにかけ、所望の場所に記憶させることができる。さらに、（データの受け取りなどの）イベントの発生時に、アクションは自動的に開始され得る。一例では、ユーザは、特定の個人から電子メールメッセージを受け取るたびに、インスタントメッセージングアプリケーションが呼び出され、インスタントメッセージが特定の連絡先に配信されると指定することができる。ゆえに、基本型（または基本型の組み合わせ）の利用によって、指定されたアクションが、異種のアプリケーションにまたがって行われ得ることが理解され得る。別の例では、ユーザによって定義されるアクションは、エンドユーザからのコマンドによって明示的に呼び出され得る。

使いやすさを助長するため、エンドユーザプログラミングシステムは、ファイルシステムと統合されて、コンピュータシステム上に格納された情報への一様なインターフェースを提供することができる。エンドユーザプログラミングモジュールとファイルシステムとの統合は、エンドユーザが、ユーザ対話の有無にかかわらずデータにルールが適用され、アクションが取られ得るように、格納されたデータに関してルールおよび取られるべきアクションを定義することができるようにする。この種のエンドユーザプログラミングシステムは、エンドユーザが、通常は隠され、エンドユーザがアクセスすることを禁じられるはずの、基礎をなすファイルシステムの機能を使ってデータを管理することを可能にし得る。

開示し、説明するコンポーネントおよび方法は、以下で説明し、特許請求の範囲において詳細に指し示す特徴を備える。以下の説明および添付の図面に、いくつかの例示的態様を詳細に示す。しかしながら、これらの態様は、開示するコンポーネントおよび方法が用いられ得る様々な方法のいくつかを示すにすぎない。開示し、説明するコンポーネントおよび方法の具体的実施形態は、そのようなコンポーネント、方法およびそれらの均等物の一部、多く、または全部を含み得る。本明細書に提示する具体的実施形態および例の変形形態は、以下の詳細な説明を図面と併せて考察すれば明らかになるであろう。

本願で使用する場合、「コンポーネント」、「システム」、「モジュール」などの用語は、ハードウェア、（例えば実行中の）ソフトウェア、および／またはファームウェアなど、コンピュータ関連のエンティティを指すものとする。例えば、コンポーネントは、プロセッサ上で稼動するプロセス、プロセッサ、オブジェクト、実行可能モジュール、プログラム、および／またはコンピュータなどとすることができる。また、サーバ上で稼動するアプリケーションとそのサーバの両方をコンポーネントとすることもできる。１つのプロセス内に１つまたは複数のコンポーネントが存在することができ、コンポーネントは、１つのコンピュータ上に集中させ、および／または２つ以上のコンピュータ間に分散させることができる。

開示するコンポーネントおよび方法を、図面を参照して説明する。図面全体を通して、類似の参照番号は類似の要素を指すのに使用する。以下の記述では、説明として、開示する内容の十分な理解を提供するための多数の具体的詳細を示す。しかしながら、具体的実施形態においては、これらの具体的詳細のいくつかが除外され、または他のものと組み合わされ得ることが明らかであると思われる。別の例では、説明を容易にするために、いくつかの構造および装置をブロック図の形で示す。さらに、開示する具体例は、クライアント／サーバアーキテクチャと整合性のある用語を使用し、またはクライアント／サーバ実施形態の例とすることさえもできるが、クライアントとサーバの役割は逆転され得ること、開示し、説明するコンポーネントおよび方法は、クライアント／サーバアーキテクチャに限定されず、開示し、説明するコンポーネントおよび方法の趣旨または範囲を逸脱することなく、具体的には、ピアツーピア（Ｐ２Ｐ）アーキテクチャを含む他のアーキテクチャにおける使用にも容易に適合され得ることを当分野の技術者は理解するであろう。さらに、本明細書で提示する具体例は特定のコンポーネントを含み、または参照するが、本明細書で開示し、説明するコンポーネントおよび方法の実施形態は、必ずしも、それらの特定のコンポーネントに限定されるものではなく、他の状況でも用いられ得ることに留意すべきである。

以下で説明する本発明の１つまたは複数の態様による推論および／または確率論的決定および／または統計ベースの決定との関連において、人工知能ベースのシステム（明示的に、および／または暗黙的に訓練される分類子など）が用いられ得る。本明細書で使用する場合、「推論（inference）」という用語は、一般に、イベントおよび／またはデータを介して取り込まれる１組の観測の集合から、システム、環境および／またはユーザの状態を推測し、または推論するプロセスを指す。推論は、特定の文脈またはアクションを識別するのに用いられ、または、例えば、状態の確率分布を生成することができる。推論は、確率論的とする、すなわち、データおよびイベントの考察に基づく当該の状態の確率分布の計算とすることができる。また、推論は、１組のイベントおよび／またはデータからより高いレベルのイベントを構成するのに用いられる技法も指し得る。そのような推論の結果として、１組の観測されたイベントおよび／または格納されたイベントデータから、それらのイベントが時間的に近接して相関しているか否か、それらのデータおよびイベントが１つのイベントまたはデータソースからのものか、それとも複数のイベントまたはデータソースからのものかを問わずに、新しいイベントまたはアクションが構築される。本明細書で開示し、説明するコンポーネントおよび方法に関連して自動の、および／または推論されたアクションを実行するのと関連して、様々な分類方式および／またはシステム、例えば、サポートベクトルマシン、ニューラルネットワーク、エキスパートシステム、ベイジアンネットワーク、ファジィ論理、データ融合エンジンなどが用いられ得る。

図１は、エンドユーザプログラミングシステム１００のシステムブロック図である。エンドユーザプログラミングシステム１００は、エンドユーザプログラミングシステム１００についての処理環境を提供し得るオペレーティングプラットフォーム１１０を含む。この文脈において、オペレーティングプラットフォーム１１０は、ハードウェアコンポーネントおよびソフトウェアコンポーネントの両方を含み得る。具体的には、オペレーティングプラットフォーム１１０は、パーソナルコンピュータ、ワークステーション、またはサーバのオペレーティングシステムとすることができる。イベント１２０は、オペレーティングプラットフォーム１１０によって作成されることができ、処理タスクが実行されている、または実行されたというインジケータとして働き得る。イベント１２０などのイベントは、他のコンピューティングコンポーネントによって検出することができ、事前定義されたコンピューティングタスクの実行を開始するためのトリガデバイスとして使用され得る。

エンドユーザプログラミング（「ＥＵＰ」）モジュール１３０は、エンドユーザによって、イベント１２０の発生時にとられる、ユーザ定義アクション１４０などのアクションを定義するために操作され得るコンポーネントを提供し得る。ユーザ定義アクション１４０は、単一のタスクとすることも、実行すべきタスクのグループとすることもできることに留意すべきである。ＥＵＰモジュール１３０は、手動で操作され得る、または、以前には、それだけに限らないが、オペレーティングシステムやサービスコンポーネントなど、他のソフトウェアコンポーネントによってのみアクセスされ得た、システム機能へのインターフェースを提供することができる。

動作に際して、エンドユーザは、ユーザ定義アクションをトリガするのに使用され得る、イベント１２０などのイベントを識別するためにＥＵＰモジュール１３０にアクセスする。また、エンドユーザは、エンドユーザが、識別されたイベントの発生時にシステムに自動的に実行させようとする、アクションまたはアクションのグループも定義する。次いで、イベントがユーザ定義アクションにバインドされる。すなわち、イベント１２０の発生時に、オペレーティングプラットフォームがユーザ定義アクションを実行する。

例えば、エンドユーザは、特定の人物からの電子メールメッセージの受信をトリガイベントとして識別することができる。その場合、エンドユーザは、そのような電子メールメッセージの受信時に、そのメッセージが定義されたメールボックスフォルダに転送され、メッセージの受信を確認する応答が送信者に送信され、文書がファイルサーバから検索され、適切なプログラムにおいて開かれ、コンピュータ上で文書が用意できていることをユーザに知らせる可聴警報が鳴るようなアクションを作成することができる。これらのステップは、システム１００の利用により、ユーザ介入なしで自動的に実行され得る。

図２は、エンドユーザプロセシングシステム２００のシステムブロック図である。エンドユーザプロセシングシステム２００は、人間ユーザのためにシステムへのアクセスを可能にするユーザインターフェース２１０を含む。ユーザインターフェース２１０は、特に、グラフィカルユーザインターフェース、コマンドラインインターフェース、Ｗｅｂベースのインターフェースなど、任意の適切な人間／コンピュータインターフェースとすることができ、ハードウェアコンポーネントおよびソフトウェアコンポーネントの両方を含み得るオペレーティングプラットフォーム２２０に結合され得る。また、ユーザインターフェース２１０は、イベントハンドラ２３０およびルールデータストア２４０にも接続することができ、イベントハンドラ２３０は、イベント２４５の発生を検出し、プロセシングサブシステム２５０にアクセスすることができる。

動作に際して、ユーザインターフェース２１０は、トリガイベントとして使用されるイベントを識別し、そのイベントのユーザ定義アクションへのバインディングを生じさせ得るエンドユーザに、イベントハンドラ２３０およびルールデータストア２４０へのアクセスを提供する。その場合、ユーザ定義アクションは、さらに、ルールデータストア２４０内に格納され得る。オペレーティングプラットフォーム２２０は、イベントハンドラ２３０によって検出されるイベント２４５を作成し、イベントハンドラ２３０は、ルールデータストア２４０にアクセスして、ユーザ定義アクションが、検出されたイベントにバインドされているかどうか判断することができる。バインドされている場合、イベントハンドラ２３０は、プロセシングサブシステム２５０にアクセスして、ユーザ定義アクションの実行を指示する。

エンドユーザ定義のタスクの作成または実行時に適用されるルールは、ルール代数（rules algebra）によるものとすることができる。使用され得る適切なルール代数の詳細は、ＥＵＰモジュールの具体的実施形態に従って大きく異なり得る。以下で、ルール代数の一例を提示し、より詳細に説明する。このルール代数の例は、ルールプラットフォームを形成するように統合され得る様々な論理コンポーネントを含み得る。それらのコンポーネントの中には、他の項および式のビルディングブロックとして働き得る基本項が含まれる。他の項または式から構築されている項および式自体も、より複雑な項または式を作成するためのビルディングブロックとして使用され得る。このようにして、エンドユーザ定義のタスクの実行時に適用されるますます複雑なルールが作成され得る。

Ｐｒｏｐｅｒｔｙ（Ｔ）は、エンドユーザ型Ｔの１つの特性を記述し得る。エンドユーザは、１つまたは複数の特性を使って、フィルタやアクションなど、別の論理コンポーネントを記述することができる。特性は、エンドユーザ型Ｔの何らかの一般的な記述子とすることができる。ＴやＴプライムなどの異なる型に適用されるときには、同じ記述子が使用され得る。このようにして、Ｐｒｏｐｅｒｔｙ（Ｔ）およびＰｒｏｐｅｒｔｙ（Ｔ−ｐｒｉｍｅ）は、両方とも、記述子として使用されることができ、異なるコンポーネントとすることができる。入力項目型Ｔおよび出力型Ｏを有するルールは、型Ｔに対する型Ｏの特性として定義され得る。

Ｆｉｌｔｅｒ（Ｔ）は、型Ｔの項目に対するフィルタとして使用され得るブール関数とすることができる。具体的には、Ｆｉｌｔｅｒ（Ｔ）は、そのルールの実行の処理結果としてブール型を返すルールとすることができる。項目の集合に適用されるＦｉｌｔｅｒ（Ｔ）ルールは、その集合の中の個々の項目に対するＦｉｌｔｅｒ（Ｔ）の実行後に返されるブール型の値を検査することによって、そのルールの条件を満たさない項目をフィルタリングすることができる。Ｆｉｌｔｅｒ（Ｔ）ルールの条件を満たす項目は、適用されるＦｉｌｔｅｒ（Ｔ）ルールに、返されるブール型として真の値を返すよう促すことができる。

同様にして、適用されるＦｉｌｔｅｒ（Ｔ）ルールの条件を満たさない項目は、Ｆｉｌｔｅｒ（Ｔ）ルールに、返されるブール型として偽の値を返すよう促すことができる。Ｆｉｌｔｅｒ（Ｔ）ルールは、適用されるＦｉｌｔｅｒ（Ｔ）ルールの条件を満たし、または満たさない項目のサブセットを獲得するために、集合の中の各項目に反復して適用され得る。このようにして、包含的または排他的サブセットが作成され得る。包含的サブセットは、適用されるＦｉｌｔｅｒ（Ｔ）ルールの条件を満たし、真の戻りブール値を促し、結果として包含されると記述される項目を生じる項目を持ち得る。排他的サブセットは、適用されるＦｉｌｔｅｒ（Ｔ）ルールの条件を満たさず、偽の戻りブール値を促し、結果として除外されると記述される項目を生じる項目を持ち得る。どちらのサブセットもその後の処理に使用され得る。

Ａｃｔｉｏｎ（Ｔ）は、結果を作成する何らかの所望の副次作用を持ち得る、型Ｔの項目のメソッドとして作成され得る。通常、Ａｃｔｉｏｎ（Ｔ）は、他のパラメータを使用し、または必要とし得る。入力型Ｔを持ち、閉集合を出力するルールは、型Ｔの項目に対するアクションを定義することができる。Ｓｅｔ（Ｔ）は、型Ｔの項目のグループ化である。

Ｅｖｅｎｔ（Ｔ）は、対象となる何らかの発生（occurrence）を定義するのに使用することができ、通常は、例えば、型Ｔのイベントデータなどのデータの項目に関連付けられる。Ｅｖｅｎｔ（Ｔ）は、単純なイベントを定義するのにも使用され、二項代数演算を使用するより複雑なイベントを作成するために、ビルディングブロックとしても使用され得る。Ｆｉｌｔｅｒ（Ｔ）と組み合わされると、Ｅｖｅｎｔ（Ｔ）は、派生Ｅｖｅｎｔ（Ｔ）を作成するために使用され得る。代数項としては、以下の通りである。

DerivedEvent(T)＝Event(T)＋Filter(T)

一般に、派生イベントは、イベントにフィルタを適用することによって作成され得る。また、他の構成も代数原理を使って形成され得る。例えば、相補的な項目型（例えば、両方とも同じ親型の副型である２つの型など）に対する２つのフィルタは、以下のように組み合わされ得る。

Filter(T)＝Filter1(T_subtype_1)∪Filter2(T_subtype_2)

バッチは、プログラムモジュールによって実行される集合指向の（set-oriented）タスクを定義することができる。バッチのセマンティクスは、結果として、集合中の各項目に対して何らかの事前定義のアクションを実行するように定義され得る。他のモジュールの場合と同様に、バッチは、手動コマンドに際して、または何らかのイベントの自動発生時に実行され得る。バッチは、以下のように、集合とアクションを組み合わせることによって作成され得る。

Batch＝Set(T)＋Action(T)

エージェントは、エージェントの実行およびそのエージェントに関連付けられたアクションの実行を始動させ得るトリガとして働くことのできる事前定義イベントの発生時に実行される何らかのアクションを定義することができる。代数項としては、以下の通りである。

Agent＝Event(T)＋Action(T)

ルールは、何らかの論理で接続され得る様々な条件を使って作成され得る。各ルール内において、条件が様々に構成され得る。例えば、指定された特性を持つ項目が、以下を使って記述され得る。

また、他の条件も可能であり、ルールを構成するのに使用され得る。

個々のＥＵＰ論理コンポーネントがアプリケーション内で評価され得る。そのような評価は、バックグラウンドタスクとして実行され、したがって、ユーザには不可視とすることができる。それに加えて、または代替として、これらのタスクは、ユーザによって入力されたコマンドに従って明示的に実行することもできる。一般に、いくつかの型のプログラムがコアプログラムグループとして使用され得る。例えば、派生集合などのコア型を完全なエンドユーザプログラムとすることができる。派生集合が起動され、または実行されると、その集合定義の論理に関連付けられたコマンドが実行され、その実行結果が表示され得る。さらに、派生集合は、代数演算でも使用され得る。例えば、２つの派生集合が以下のように組み合わされ得る。

Set(T)＝Set1(T)∪Set2(T)

別の例として、事前定義のイベントの発生時に指定されたアクションを実行するようにエージェントが作成され得る。前述のように、エージェントは、Ａｃｔｉｏｎ（Ｔ）と組み合わされたＥｖｅｎｔ（Ｔ）である。エージェントのイベント部分の発生時に、エージェントのアクション部分の処理ステップが実行され得る。このようにして、エージェントの実行が、エンドユーザからの介入なしにトリガされ得る。

ＥＵＰ代数には、ルール代数によって規定されるオブジェクト型および操作にアクセスする手段を提供し得るアプリケーションプログラミングインターフェース（ＡＰＩ）を介してアクセスされ得る。さらに、ＡＰＩは、直接にアクセスされ得る、以前に構築されたＥＵＰ論理コンポーネントなど事前定義コンポーネントのグループも、基本項からそのようなコンポーネントを構築する代替手段として提供し得る。

図３は、ルール型階層（rule type hierarchy）３００のスキーマ図である。ルール型階層３００のスキーマは、型を、本明細書で説明するイベント、ルール、エンドユーザプログラムなどの、１つまたは複数の機能コンポーネントに編成するのに使用され得る。それに加えて、または代替として、特定の実施形態の詳細により他の何らかのコンポーネント、またはこれら前述のコンポーネントの１つまたは複数の変形も作成され得る。作成されたイベント、ルール、またはエンドユーザプログラムは、エンドユーザによって組み立てられ、または定義されるコンポーネントの詳細によって、何らかのデータ処理タスクを実行するのに、適宜、単独で、または組み合わせて使用され得る。この図３に提示する例では、イベントは、実行可能コンポーネントの実行をトリガし得るルールイベント３２０などのルールイベントとすることができる。ルールは、コンピューティングシナリオに適用される論理を定義し得るルール論理３３０などのルール論理とすることができる。ルールプログラム３４０などのルールプログラムは、エンドユーザプログラムまたは別の実行可能コンポーネントとすることができる。この具体例では、ルールイベント３２０、ルール論理３３０、およびルールプログラム３４０のそれぞれは、１つまたは複数のサブコンポーネントと関連付けられ得る。したがって、これらのサブコンポーネントのそれぞれは、例えば、イベントなどの単純な項目型とすることもでき、あるいはそうではなく、派生集合など、エンドユーザ作成の型または複合型とすることもできる。

ルールイベントコンポーネント３２０は、エンドユーザによって作成されるルールプラットフォームエージェントによって使用されるイベント型すべての基本型とすることができ、概念上抽象的であり、各エージェントによって参照され得る共通型を提供するように働くことができる。エージェントは、エージェントに、そのような実行をいつ実行し、またはトリガすべきか知らせることのできる、ルールイベントコンポーネント３２０などのルールイベントコンポーネントのインスタンスを参照することができる。ルールイベントコンポーネント３２０は、例えば、基本イベント３２２などの基本イベントやフィルタリングされたイベント３２４などの派生イベントとされ、またはそれに関連付けられ得る。一例では、基本イベント３２２は、ルールイベントコンポーネント３２０から派生させ得る。基本イベント３２２などの基本イベント型は、アプリケーションが、論理イベントの発動を表すためにルールシステムに入力項目を提示するフック点として動作することができる。例えば、基本イベントは、特に、項目がデータストアに付加されることや、データストアの項目が変更されることなどのイベントを表すことができる。イベント項目を介した入力項目の提示は、そのイベントが発生していることを伝達し、結果として別のイベントを発動し得るプロセスを開始させることができる。

また、フィルタリングされたイベント３２４は、ルールイベントコンポーネント３２０からも派生させ得る。フィルタリングされたイベント３２４は、別のルールイベントへの参照、およびそのイベントの発動をフィルタリングするのに使用するためのフィルタ論理型のインスタンスへの参照を含み得る。フィルタリングされたイベント３２４は、ルールイベントコンポーネント３２０など、そのソースルールイベントコンポーネントの発動に基づいて発動し得る。ソースイベントの発動時に、フィルタリングされたイベント３２４は、それに対してソースイベントが発動された入力項目を取り、その入力項目に対してそのフィルタ論理コンポーネントのインスタンスを評価することができる。フィルタリングされたイベント３２４は、フィルタ論理が真であると評価された場合に限り発動する。この例では、フィルタリングされたイベント３２４などのフィルタリングされたイベントは、直接ＡＰＩ関数呼び出しを使って生成することはできず、そのソースイベントが発動され、ソースイベントがそれに対して発動された入力項目について、そのフィルタ論理が真であると評価した場合に限り生成され得る。

ルール論理コンポーネント３３０は、ルール論理コンポーネントが、ルール論理コンポーネント３３０を使用し、または別の方法でルール論理コンポーネント３３０関連付けられたコンポーネントに１つまたは複数のコンピューティングタスクを実行させ得る処理ステップを定義していることができるという意味で、ルールとして記述され得る。ルール論理コンポーネント３３０は、フィルタ論理３３２、特性論理３３４、アクション論理３３６、および関連論理３３８とし、またはそれらに関連付けることができる。フィルタ論理３３２、特性論理３３４、アクション論理３３６、および関連論理３３８は、ルール論理を作成するのに使用され得る。フィルタ論理３３２は、入力型の所与の項目インスタンスをフィルタリングするルール論理を定義することができる。フィルタ論理３３２の出力型は、ブール値またはヌル値とすることができる。また、特性論理３３４もルールを定義することができる。定義されたルールは、特定の項目インスタンスが与えられたときに指定された型の値を計算することができ、したがって、計算された特性として働くことができる。この概念をサポートするために、特性論理３３４の出力型が特性型として表され得る。

アクション論理３３６は、指定された入力型の特定の項目インスタンスが与えられたときに実行すべきアクションのシーケンスを生成し得るルールを定義することができる。アクション論理３３６の出力は、列挙可能であり、実行されるアクションのシーケンスを符号化するオブジェクトとすることができる。関連論理３３８は、ルール定義から派生させることができ、ソース型の特定の項目インスタンスが与えられたときに指定されたターゲット型の項目集合を生成し得るルールを定義することができる。関連論理３３８の出力は、その項目集合を構成する列挙可能な項目のインスタンスとすることができる。

この例示的ルール代数によって記述される項目の１つのクラスは、実行可能コンポーネントを含む。これらの実行可能コンポーネント自体は論理記述を含まず、エンドユーザによって作成され、ルール論理定義を入力コレクションと一緒に結合するように働き得るラッパプログラム（wrapper programs）である。１つの実行可能コンポーネントは、ルールプログラム３４０とすることができる。ルールプログラム３４０は、エンドユーザプログラム型の共通基本型を形成し得る。ルールプログラム３４０の１次機能は、バッチやエージェントといったエンドユーザプログラム型のすべてのインスタンスを、持続させ、検索され得るようにし、そのような共通入力型に基づいてフィルタリングされ得るようにすることとし得る。

ルールプログラム３４０は、問い合わせ（query）３４２、エージェント３４４、バッチ３４６など他のコンポーネントとし、またはそれらに関連付けることができる。問い合わせ３４２は、問い合わせの制限に従って評価され得る、計算された結果項目集合を表し得る。エージェント３４４は、イベントの発動時または何らかの偶発事件の発生時に実行される１つまたは複数のアクションを表し得る。バッチ３４６は、項目のコレクションに対して実行される１つまたは複数のアクションを表し得る。エンドユーザは、これらのコンポーネントを様々な方法で組み合わせて実行可能なルールプログラムを作成することができる。

図４は、統合ファイルシステムを含むエンドユーザプログラミングシステム４００のシステムブロック図である。エンドユーザプログラミングシステム４００は、そのプログラミング機能のためのサポートを、この基礎をなすファイルシステムの特定の機能から導出することができる。具体的には、ＥＵＰシステムの適当な基礎をなすファイルシステムとの統合は、エンドユーザが対話するコンピューティングシステムのあらゆる態様がそれに基づいてプログラム可能とされ得る基礎を提供し得る。

エンドユーザプログラミングシステム４００は、特に、グラフィカルユーザインターフェース、Ｗｅｂベースのインターフェース、テキストベースのインターフェース、コマンドラインインターフェースなど、任意の適当なユーザインターフェースとすることのできる、ユーザインターフェース４１０を含む。ユーザインターフェース４１０は、ルール層４２０およびエンドユーザプログラミングモジュール４３０に結合される。ルール層４２０は、エンドユーザ作成のエージェント、バッチ、その他のコンポーネントを含むＥＵＰシステムのすべての事前定義コンポーネントを含み得る。

エンドユーザプログラミングモジュール４３０は、エンドユーザがエージェントなどのコンポーネントを定義するための機構を提供する。エンドユーザプログラミングモジュール４３０は、ユーザインターフェース４１０と共に、統合開発環境が従来のソフトウェア開発者に提供し得る機能の、全部ではないとしても、多くを提供し得る。そのような機能には、手法の中でも特に、グラフィカルウィジェット（widget）をドラッグアンドドロップすることにより、またはアクションをあらかじめスクリプトとして登録することにより、コンポーネントを再利用し、コンポーネントをバージョン管理し、コンポーネントを構築することのできる機能が含まれ得る。

ファイルシステム４４０は、データ項目が、特に、ハードディスクや光ディスクといった何らかの物理メディア上にどのようにして格納されるかの概念的表現を提供し得る。この具体例では、オブジェクト指向の設計概念を大いに活用するファイルシステムが提示される。より具体的には、ファイルシステム４４０は、項目が、ＡＰＩを介してアクセスされ、何らかの所望の結果を生成するために評価され得る全体式（overall expression）の一部としてその内部に格納されるフレームワークを提供し得る。また、ファイルシステム４４０は、永続性のためだけに使用することができ、メソッドのパラメータまたは結果としては使用されないインライン型の集合も含み得る。

ファイルシステム４４０は、「ＮＯＴ」、「ＡＮＤ」、「ＯＲ」などの論理演算子グループを含み得る。さらに、ファイルシステム４４０は、特に、条件演算子、算術演算子、集約演算子、日付、時刻、およびストリング演算子、型キャストなどの頑強なプログラミング構成体も提供し得る。また、メソッドおよびそのようなメソッドを呼び出す機能も提供される。例えば、ＡＰＩを介して様々なコンストラクタ、デストラクタ、値アクセサ（accessor）、および値セッタ（setter）がアクセスされ得る。

ファイルシステム４４０が提供し得るサポート機能の中には、データを管理し、命名し、共有し、格納し、同期し、および検索するインフラストラクチャ機能がある。ファイルシステム４４０は、エンドユーザが、エンドユーザプログラムを構築することの一部として、ファイルシステム４４０が提供し得る機能すべてにアクセスできるように、ルール層４２０およびエンドユーザプログラミングモジュール４３０にこれらの機能すべてを提供し得る。本明細書で提示する例では、ルールのスキーマは、ファイルシステムによってサポートされる型システムに適合しなければならない。また、エンドユーザプログラミング概念についてのＡＰＩ面全体も、ファイルシステムＡＰＩの標準モデルに従う。これらの設計選択の１つの副次作用は、ファイルシステム項目に不利に働く汎用ユーザインターフェースアプリケーションが、エンドユーザプログラミング項目にも同様に不利に働くことである。

論理的には、ファイルシステム４４０には、２つのスキーマレベルがあり得る。第１のレベルには、開発者コード用のスキーマがあり得る。この開発者コードスキーマは、項目タイプおよびそれらの項目の挙動態様を定義し得る。このレベルのスキーマを使用することによって、開発者は、共通の参照フレームを用いてデータ抽象化を共有する。第２のレベルには、エンドユーザ論理用のスキーマがあり得る。このエンドユーザ論理レベルは、エンドユーザルールのフレームワークを提供するのに使用され得る。

また、エンドユーザとファイルシステム４４０両方の型システムも厳密に整合され得る。具体的には、この例では、エンドユーザ型の型階層は、ファイルシステム型の型階層の簡略化とすることができる。ファイルシステム階層中のいくつかの型は、おそらく、それらがエンドユーザに無関係であるために省略され得る。さらに、あらゆるエンドユーザ型から基礎をなすファイルシステム型へのマッピングまたはバインディングも作成され得る。マッピングまたはバインディングは、エンドユーザレベルとファイルシステムレベルの間のギャップを埋めるために使用され得る。バインディングは、エンドユーザスキーマ要素の名前をローカライズする機能を含めて、多目的に使用され得る。具体的には、この例では、バインディングはルールとすることができる。ありふれた事例では、バインディングは、その条件が常に真であり、その結果が開発者型に関する特定の基礎をなす特性である単一のステートメントを有するルールとすることができる。

また、バインディングは、開発者レベルスキーマとエンドユーザレベルスキーマの間の間接化（indirection）のレベルも提供し得る。ここでは、様々なアクセス制御ポリシが、特定の実施形態に応じて適用され得る。例えば、ファイルシステム開発者は、開発者が作成する型のどの特性がエンドユーザにとってアクセス可能になるか定義することを許され得る。代替として、エンドユーザに、エンドユーザが開発者作成型のどの特性にアクセスしようとするか決定する能力を与えることもできる。また、これら２つの手法の何らかの組み合わせも可能である。

図５は、統合ファイルシステムを含むエンドユーザプログラミングシステム５００のシステムブロック図である。エンドユーザプログラミングシステム５００は、エンドユーザによって制御され、または所有される空間で実行され得るアプリケーションをカスタマイズするのに使用され得る。それに加えて、または代替として、エンドユーザプログラミングシステム５００は、特に、システムプロセスやデーモンなど他の空間で動作するアプリケーションの挙動を変更するコンポーネントを作成するのにも使用され得る。

エンドユーザプログラミングシステム５００は、特に、グラフィカルユーザインターフェース、Ｗｅｂベースのインターフェース、テキストベースのインターフェース、コマンドラインインターフェースなど、任意の適当なユーザインターフェースとすることのできるユーザインターフェース５１０を含む。また、特に、視覚障害者用の点字インターフェースや音声インターフェースなどの特殊なインターフェースも可能である。ユーザインターフェース５１０は、特に、電子メールクライアント、ワードプロセッサ、スプレッドシートプログラム、Ｗｅｂブラウザなどのエンドユーザ制御のアプリケーションを含み得るアプリケーション層５２０に結合される。それに加えて、または代替として、アプリケーション層５２０は、特に、ドメインネームシステム（ＤＮＳ）検索やネットワーク接続機能など、他の実行コンピュータプログラムにサービスを提供する、いわゆるシステムプロセスも含み得る。

ルール層５３０は、アプリケーション層５２０に結合される。ルール層５３０は、アプリケーション層５２０にエンドユーザプログラミングコンポーネントおよびサポートを提供し、図４のルール層４２０と同様に実装され得る。また、エンドユーザプログラミングモジュール５４０は、ルール層５３０とユーザインターフェース５４０の両方に結合される。エンドユーザプログラミングモジュール５４０は、図４のエンドユーザプログラミングモジュール４３０とほとんど同じく、ルール層５３０へのアクセスおよび新しいルールを作成する機能を提供し得る。

ファイルシステム５５０は、ルール層５３０のルール、およびエンドユーザプログラミングモジュール５４０によって作成され得る他のエンドユーザプログラムが、それに基づいて、アプリケーション層５２０によってアクセスされ、または別の方法で使用され得るストレージフレームワークを提供し得る。この状況で使用するために、任意の適当なファイルシステムが使用され、または適合され得る。エンドユーザプログラミング機能用のＡＰＩと統合され、またはそれにマップされ得るＡＰＩを備えるファイルシステムは、この用途に特に適する。

動作に際して、エンドユーザは、ユーザインターフェース５１０を介してエンドユーザプログラミングシステム５００と対話することができる。エンドユーザは、エンドユーザプログラミングモジュール５４０を使って、ルール層５３０に付加され得る、特に、ルール、エージェント、またはバッチを作成することができる。また、エンドユーザは、ユーザインターフェース５１０を介してアプリケーション層５２０のアプリケーションにアクセスすることもできる。

イベントまたは他の何らかのトリガオブジェクトがルールを起動させると、アプリケーション層５２０とルール層５３０の間でメッセージが受け渡しされ得る。ルール起動の詳細に応じて、これらのメッセージは、同期または非同期とすることができる。次いで、起動された１つまたは複数のルールが、どれであれ、その設計に従って実行され、ファイルシステムＡＰＩの、マップされ、またはバインドされた部分を使って、ファイルシステムレベル５５０において適当な変更を行うことができる。

図６は、ファイルシステム上に格納された電子情報を管理するエンドユーザ定義のプログラムモジュールを作成するのに使用され得るエンドユーザプログラミングシステム６００のシステムブロック図である。これらのプログラムモジュールは、エンドユーザからの特定の命令に従って、ファイルシステム上に格納された情報を操作するためにエンドユーザによって作成されたルールを自動的に適用することができる。そのような命令は、情報をグループ化し、または何らかの事前定義のイベント発生時に編成タスクなど特定の情報管理タスクを実行するためのフィルタを適用することを含み得る。

エンドユーザプログラミングシステム６００は、ルール作成または変更、イベント定義などのエンドユーザプログラミングサポート機能へのアクセスを提供し得るエンドユーザプログラミングモジュール６１０を含む。エンドユーザプログラミングモジュール６１０は、具体的には、他の図との関連で前述したエンドユーザプログラミングモジュールのいずれかとして実装され得る。エンドユーザプログラミングモジュール６１０を使って作成されるエンドユーザプログラムは、イベント駆動プログラムの場合と同様に、自動的に実行され、またはエンドユーザから特定のコマンドによって呼び出され得る。

人間／コンピュータインターフェース６２０は、エンドユーザプログラミングモジュール６１０の機能および機構へのアクセスを提供し得る。特定の実施形態の必要および要求に応じて、様々なコンポーネントを使って人間／コンピュータインターフェース６２０が実装され得る。例えば、人間／コンピュータインターフェース６２０は、オペレーティングシステムのグラフィカルユーザインターフェースなど、グラフィカルユーザインターフェースとして実装され得る。代替として、人間／コンピュータインターフェース６２０は、特に、Ｗｅｂブラウザに基づくものとすることもでき、コマンドラインなどテキストベースのインターフェースとすることもでき、点字タッチベースのインターフェースとすることもでき、音声ベースのインターフェースとすることもできる。

ルールプラットフォーム６３０は、エンドユーザプログラミングモジュール６１０を使って作成されるエンドユーザ定義のプログラムを含み得る。さらに、ルールプラットフォーム６３０には、エンドユーザプログラムを作成するのに使用され得るビルディングブロックコンポーネントも含まれ得る。エンドユーザプログラミングモジュール６１０および人間／コンピュータインターフェース６２０は、両方とも、エンドユーザに、ルールプラットフォーム６３０中のエンドユーザプログラムを作成させ、変更させ、削除させ、その実行を呼び出させるために、ルールプラットフォーム６３０にアクセスし得る。

ルールプラットフォーム６３０は、ファイルシステム６４０に結合される。ファイルシステム６４０は、データ編成および検索タスクをサポートし得る任意の適当なファイルシステムとして実装され得る。具体的には、ファイルシステム６４０は、ファイルシステム６４０の機能へのアクセスを提供するＡＰＩと共に、ルールプラットフォーム６３０の機能がファイルシステム６４０の機能にマップされ、またはバインドされ得るように、ルールプラットフォーム６３０のＡＰＩと結合され得る。このようなルールプラットフォーム６３０のファイルシステム６４０との統合は、エンドユーザが、ファイルシステム機能を、特に、情報編成および自動化処理タスクを含む様々なコンピューティングタスクに使用し得るように、ファイルシステム６４０の機能をエンドユーザに事実上公開する。エンドユーザによるファイルシステム６４０の機能へのアクセスは、ルールプラットフォーム６３０を介したものであり、ファイルシステムを破損し、または別のやり方で損傷し得る、意図しない、または悪質なアクションからファイルシステム６４０を保護する層が提供される。例えば、ファイルの論理的場所を変更せずに、ファイルを、記憶装置上の１つの物理的場所から別の場所に移動させるなどの特定の機能は、エンドユーザプログラミングモジュール６１０またはルールプラットフォーム６３０の機能にはマップされず、バインドされないままとし、エンドユーザがその機能にアクセスするのを防ぐことができる。

ファイルシステム６４０は、１つまたは複数の永続的記憶装置（ＰＳ：persistent storage devices）６５０、６６０、６７０（ＰＳ）に論理ファイル編成を強制することができる。永続的記憶装置６５０、６６０、６７０は、ハードディスクドライブ、光ドライブ、フラッシュメモリ装置、またはその他適当な記憶装置とすることができ、それぞれファイルシステムを使用する別個のディスクとして独立に動作し得る。それに加えて、または代替として、永続記憶装置６５０、６６０、６７０は、１つまたは複数の物理ディスクドライブ上の論理パーティションとすることもできる。この構成では、エンドユーザは、記憶領域を提供する複数のディスクまたはパーティションがあることを知ることができる。また、永続的記憶装置６５０、６６０、６７０は、ＲＡＩＤ（redundant array of independent disks）の場合と同様に、単一の論理記憶ボリュームの一部としても統合され得る。ＲＡＩＤアレイとして構成されると、永続的記憶装置６５０、６６０、６７０は、単一ファイルシステムを使用する単一エンティティとしてアクセスされ得る。また、永続的記憶装置６５０、６６０、６７０は、ストレージエリアネットワーク（ＳＡＮ）または他の何らかの記憶システムの一部とすることもできる。

動作に際して、エンドユーザプログラミングシステム６００は、以下のように機能し得る。エンドユーザは、エンドユーザプログラムを作成するために、人間／コンピュータインターフェース６２０を介してエンドユーザプログラミングモジュール６１０にアクセスすることができる。エンドユーザプログラムは、エンドユーザからのコマンドによって、あるいは特定の、または事前定義のイベントの発生時に実行が呼び出されるまで、ルールプラットフォーム６３０上にある。ルールプラットフォーム６３０は、ファイルシステム６４０に、ファイルシステム６４０が、永続的記憶装置６５０、６６０、６７０上で何らかの情報操作タスクを実行するよう要求するメッセージを送る。要求されたタスクが正常に完了し、または失敗すると、同期メッセージ環境において、ファイルシステム６４０は、エンドユーザプログラムに要求されたタスクの結果を知らせるメッセージをルールプラットフォーム６３０に送る。代替として、非同期メッセージングシステムの場合と同様に、ファイルシステム６４０は、ルールプラットフォーム６３０に応答メッセージを送らずに、要求されたタスクを実行し、または実行しようとすることもできる。要求されたアクションに関する情報は、エンドユーザに見えるように人間／コンピュータインターフェース６２０上に表示される。

図７は、ネットワークを介してアクセスされ得る、リモートファイルシステム上に格納された電子情報を管理するエンドユーザ定義のプログラムモジュールを作成するのに使用され得る、ネットワークを介して接続されたエンドユーザプログラミングシステム７００のシステムブロック図である。ネットワークを介して接続されたエンドユーザプログラムモジュールは、リモートファイルシステム上に格納された情報にアクセスし、またはそれを操作するために、エンドユーザによって作成されたルールを自動的に適用することができる。ネットワークを介して接続されたエンドユーザプログラミングシステム７００は、ルール作成、ルール変更および定義や、トリガイベントの識別のようなエンドユーザプログラミングサポート機能へのアクセスを提供するエンドユーザプログラミングモジュール７１０を含む。エンドユーザプログラミングモジュール７１０は、具体的には、他の図との関連で前述したエンドユーザプログラミングモジュールのいずれかとして実装され得る。そのような実施形態と一致する、エンドユーザプログラミングモジュール７１０を使って作成されるエンドユーザプログラムは、イベント駆動プログラムの場合と同様に、自動的に実行され、あるいは、エンドユーザからの特定のコマンドによって呼び出され得る。

ルールプラットフォーム７２０は、エンドユーザプログラミングモジュール７１０を使って作成されたエンドユーザ定義のプログラムを含み得る。さらに、ルールプラットフォーム７２０には、エンドユーザプログラムを作成するのに使用され得るビルディングブロックコンポーネントも含まれ得る。エンドユーザプログラミングモジュール７１０およびユーザインターフェース７３０は、両方とも、エンドユーザに、ルールプラットフォーム７２０中のエンドユーザプログラムを作成させ、変更させ、削除させ、およびその実行を呼び出させるために、ルールプラットフォーム７２０にアクセスすることができる。また、ルールプラットフォーム７２０は、ルールプラットフォーム７２０のエンドユーザプログラムまたはその他のコンポーネントとファイルシステム７４０との間のネットワーク接続または、メッセージ受け渡しなどのその他の通信機能も提供し得る。そのために、ルールプラットフォームはネットワーク７５０を使用し得る。ネットワーク７５０は、任意の適当な有線または無線ネットワークとすることができ、特に、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、イントラネット、またはインターネットとすることができる。この実施形態と合致するルールプラットフォーム７２０は、特に、転送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）スタックのような通信スタックなどのネットワーク接続コンポーネントを含み得る。代替として、ルールプラットフォーム７２０は、単に、オペレーティングシステムやネットワーク接続アプリケーションなど別のコンポーネントによって提供される機能にアクセスすることもできる。

ファイルシステム７４０は、リモート記憶装置７６０に組織階層を強制することができる。リモート記憶装置は、ディスクドライブなどの永続的記憶装置、または、具体的には、他の図との関連で開示し、説明した種類を含む、他の任意の種類の永続的記憶装置とすることができる。それに加えて、または代替として、リモート記憶装置は、データベース、またはファイルシステムと同様の方式でアクセスおよび操作機能を提供し得る別の種類のデータストアとすることができる。

動作に際して、ネットワークで接続されたエンドユーザプログラミングシステム７００は以下のように機能し得る。エンドユーザは、１つまたは複数のエンドユーザプログラムを作成するために、ユーザインターフェース７３０を介してエンドユーザプログラミングモジュール７１０にアクセスすることができる。これらのエンドユーザプログラムは、エンドユーザからのコマンドによって、あるいは特定の、または事前定義されたイベントの発生時に実行が呼び出されるまでルールプラットフォーム７２０上にある。ルールプラットフォーム７２０はネットワーク７５０を使って、ファイルシステム７４０にリモート記憶装置７６０に関連した何らかの情報関連のタスクを実行するよう要求するメッセージをファイルシステム７４０に渡す。要求されたタスクが正常に完了し、または失敗すると、ファイルシステム７４０はネットワーク７５０を使って、エンドユーザプログラムに要求されたタスクの結果を知らせるために、ルールプラットフォーム７２０にメッセージを渡す。結果に関する情報は、エンドユーザに見えるようにユーザインターフェース７３０に表示される。

図８〜９を参照すると、様々な方法または手順による流れ図が提示されている。説明を簡単にするために、例えば、流れ図の形などで本明細書に示す１つまたは複数の方法を、一連の動作として図示し、説明するが、いくつかの動作は、本明細書で図示し、説明する順序と異なる順序で、かつ／またはその他の動作と同時に行われ得るため、図示し、説明する方法および手順も、そのような方法または手順に使用され得るどんなコンポーネントも、必ずしもその動作順序に限定されないことを理解し、認めるべきである。例えば、方法は、代替として、状態図などの場合のように、一連の相互に関連する状態またはイベントとしても表され得ることを当分野の技術者は理解し、認めるであろう。さらに、方法または手順を実施するのに、図示する動作すべてが必要とされ得るとも限らない。

図８は、本明細書で他の図を参照して開示され、説明されているコンポーネントと関連して使用され得るプロセス８００の流れ図である。開始ブロック８１０において、プロセス８００の実行が開始し、プロセスブロック８２０に進み、そこで、エンドユーザはＥＵＰインターフェースにアクセスする。次いで、プロセスブロック８３０において、エンドユーザはトリガイベントを選択する。例えば、トリガイベントは、電子メールメッセージの到着、文書の作成、または他の何らかのイベントとすることができる。プロセスブロック８４０において、複数のアクションを含んでも、単一のアクションを含んでも、アクションを含まなくてもよい、一組のアクションが定義される。これらのアクションは、特に、ファイルを指定された場所に移動すること、電子メールメッセージに自動的に応答すること、ファイルをある形式から別の形式に変換することなどとすることができる。プロセスブロック８５０において、この一組のアクションがイベントにバインドされる。プロセスブロック８６０において、この新しいバインディングを用いてルールベースが更新される。終了ブロック８７０において処理が終了する。

図９は、本明細書で他の図を参照して開示し、説明しているコンポーネントと関連して使用され得るプロセス９００の流れ図である。開始ブロック９０５において処理が開始し、プロセスブロック９１０に進み、そこで、コンピューティングプラットフォームがイベントを発動する。プロセスブロック９１５において、ＥＵＰコンポーネントがイベントを検出する。処理はプロセスブロック９２０に進み、そこでＥＵＰがルールデータストアにアクセスする。判定ブロック９２５において、検出されたイベントに関するルールバインディングが存在するかどうかの判定がなされる。ＹＥＳの場合、処理はプロセスブロック９３０に進み、そこでエンドユーザ定義アクションが獲得される。プロセスブロック９３５において、エンドユーザ定義アクションを実行するためにプロセスが開始されるか、またはアクティブにされる。プロセスブロック９４０において、それらのプロセスから完了メッセージが受け取られる。

判定ブロック９４５において、すべてのプロセスが正常に完了したかどうかの判定がなされる。ＹＥＳである場合、プロセスブロック９５５において、一般的な成功のメッセージが作成される。ＮＯである場合、プロセスブロック９５０において、一般的なエラーメッセージが作成される。終了ブロック９６０において、プロセスブロック９５０とプロセスブロック９５５の両方からの処理が終了する。同様に、判定ブロック９２５においてなされた判定がＮＯである場合、終了ブロック９６０において処理が終了する。

図１０は、情報のライフサイクル１０００の流れ図である。情報のライフサイクルは、一般に、コンピューティングシステム上のデータ項目の存在を記述することができる。そのような存在は、ユーザが最初に特定のデータ項目を作成し、または獲得するときに開始し、ユーザがその項目を削除し、または別の方法でデータを廃棄するときに終了し得る。情報のライフサイクル１０００は、エンドユーザが情報項目を作成し、または獲得しており、その情報項目を持続させ、ユーザにとって利用可能な状態のままにしようとする時点を表す、編成フェーズ１０１０を含む。データを編成するために使用され得る少なくとも２つの技法がある。第１の技法では、項目の特性に値が割り当てられ得る。例えば、項目に、特に、名前、あるいはメタデータまたは属性として格納され得る他の何らかの記述が付与され得る。第２の技法では、項目の関係が割り当てられ得る。関係の割り当ては、手動操作による、または検索による項目の位置指定を支援し得る。特に、いくつかの関係は、アプリケーションにおいて特別な編成セマンティクスに関連付けられ得る。例えば、フォルダ包含関係は、それを用い、共通トピックに従って情報を編成すべき共通の階層的方式とすることができる。

特性および関係には、少なくとも２つの異なる方法で値が割り当てられ得る。実際の値は、項目データを用いて具体化され、維持され得る。それに加えて、または代替として、値は、要求に応じて他のデータからも算出され得る。この場合、データを獲得するために行われる計算の定義は、メタデータとして格納され得る。データ編成のための算出機構は、データ編成のルールが、明確に定義され、容易に表現でき、利用可能な情報に完全に基づくものである場合に適当である。また、算出機構は、大量のデータを処理するために十分にスケーリングする。具体化される機構は、データ編成論理が、容易に表現され得ず、または内容やコンテキスト情報など、容易に取り込まれ得ない情報に基づくものであるときに適当である。エンドユーザプログラムは、算出された特性および関係を定義することができる。また、そのようなプログラムは、具体化された特性および関係を自動的に維持するためにも使用され得る。

格納フェーズ１０２０は、ユーザが、後でアクセスされ得る永続的形式で情報項目を保存していることを示し得る。使用され得る永続的形式には、特に、ファイルおよびオブジェクトが含まれる。そのような永続的形式の詳細は、永続的形式がその内部に格納されるファイルシステムの特定の詳細によって異なり得る。例えば、ハードディスクドライブと光ディスクの両方が永続的記憶装置として使用され得る。しかしながら、ハードディスクドライブ用のファイルシステム形式は、光ディスクで使用され得るＩＳＯ９６６０などのファイルシステム形式と大きく異なる。

検索フェーズ１０３０は、エンドユーザが、何らかの永続的形式で格納された情報を検索しようとする期間を示し得る。検索という用語は、ある項目を、エンドユーザがアクションをとるために利用可能であると識別させることのできる任意のアクティビティを含み得る。エンドユーザがデータを検索し得る、少なくとも３つの方法がある。第１の方法では、エンドユーザは、データにブラウズし、またはナビゲートすることができる。この方法では、エンドユーザは、ホームまたは参照ディレクトリなど、何らかの開始点から開始する。データ項目間の関係は、データストア中の項目をブラウズし、またはトラバースするためのパスを提供する。１つの具体例が、階層ディレクトリツリーを介してナビゲートすることである。

第２の方法では、エンドユーザは、問い合わせを実行することができる。エンドユーザによって定義される問い合わせは、何らかの宣言記述にマッチし得るデータストア中の項目サブセットを記述することができる。第３の方法を使用すると、イベントが、エンドユーザによって項目を検索するために使用され得る。この種のイベントは、何らかの特定の項目に注目するために使用され得る。例えば、ディレクトリへのファイルの追加は、追加されるファイルに注目するイベントとすることができる。

これらの方法のそれぞれは、長所と短所を有する。問い合わせベースの機構は、項目を検索するのに使用される論理が明確に定義され、データストア中でモデル化される概念の点で容易に表されるときに使用され得る。問い合わせの実行は、拡張可能であり、効率的であり得るが、問い合わせ実行は、比較的効率のよい問い合わせ機構が使用される場合でさえも、計算集約的であり得る。ナビゲーション機構は、柔軟性を提供するのに使用され得るが、問い合わせより多くのユーザの関与を必要とする。さらに、ナビゲーション機構は、大規模なデータ集合を処理するために、必ずしも、問い合わせ機構ほど十分にスケーリングするとは限らない。

イベント駆動の機構は、直接のユーザ関与なしで、適当な時点において適当なデータを検索することが目標である場合に適する。少なくとも２種類の基本的なイベントがある。第１に、アプリケーションイベントは、特定のアプリケーションまたは１組のアプリケーションの実行によって引き起こされ得る。第２に、データ変更イベントは、データに変更を生じさせたアプリケーションとは独立に、データを変更する任意のアクティビティによって引き起こされ得る。データ変更イベントは、データ管理システムによって生成され得る。個々の種類のイベントは、同期的に、または非同期的に生成され得る。同期イベントでは、アプリケーションまたはシステムは、続行する前にイベントへの応答を期待する。非同期イベントでは、そのような応答を必要とせずに、生成するアプリケーションはそのタスクの処理を続行することができる。

使用フェーズ１０４０は、エンドユーザがデータを発見し、取り出しており、それを使用し、または別の方法でデータに対してアクションをとる用意ができていることを示し得る。項目に対する基本的なアクションは、それらの項目をエンドユーザに公開するアプリケーションによって提供され得る。いくつかのアクションは、項目型に固有のものとすることができる。例えば、あるアクションを使ってある項目の特性が設定され得る。他のアクションは、その項目を使用し得るアプリケーションに固有のものとすることができる。この場合の一例は、特定の色でメッセージ項目のテキストを表示するアクションである。

計算される（computed）アクションは、以下の機構の少なくとも１つを使って他のアクションから構築され得る。まず、関係に対するアクションが使用され得る。この方式では、項目に対するアクションは、ターゲットまたは項目の関係に対するアクションを含むと定義され得る。例えば、関係がフォルダグループなどの項目の集合を定義するのに使用される場合、計算されるアクションは、その集合のすべてのメンバに対して一様なアクションを指定し得る。このプロセスをバッチと呼ぶことができる。また、条件付きのアクションも使用され得る。条件付きの計算されるアクションを定義するために、既存のアクションが条件付き論理と組み合わされ得る。例えば、文書が機密とマークされる場合、優先度フラグは高優先度を示すように設定され得る。文書が機密とマークされない場合、優先度フラグは、その文書が通常の優先度を持つことを示すように設定され得る。さらに、複数のアクションが順次に実行されなければならないリスト上に記載されるようなアクションシーケンスも作成され得る。例えば、アクションシーケンスは、文書を印刷し、次いで、その文書を削除するのに使用され得る。このようなアクションは、定義された挙動が感知し得るようにアクションの順序が決定的でなければならない状況を生み出し得る副次作用を持つことがある。

本発明の様々な態様を実施するさらなるコンテキストを提供するために、図１１〜１２および以下の考察は、本発明の様々な態様がその内部で実施され得る適当なコンピューティング環境の簡単で、一般的な説明を提供するものである。以上では、本発明を、ローカルコンピュータおよび／またはリモートコンピュータ上で稼動するコンピュータプログラムのコンピュータ実行可能命令の一般的文脈で説明しているが、本発明が、他のプログラムモジュールとの組み合わせでも実施され得ることを、当分野の技術者は理解するであろう。一般に、プログラムモジュールには、個々のタスクを実行し、かつ／または個々の抽象データ型を実施する、ルーチン、プログラム、コンポーネント、データ構造などが含まれる。

本発明の方法が、そのそれぞれが、１つまたは複数の関連する装置と動作可能にやり取りし得る、シングルプロセッサまたはマルチプロセッサコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピュータ装置、マイクロプロセッサベースの、かつ／またはプログラム可能な家庭用電化製品などを含む、他のコンピュータシステム構成を用いても実施され得ることを、当分野の技術者は理解するであろう。また、図示する本発明の態様は、いくつかのタスクが通信ネットワークを介してリンクされたリモート処理装置によって実行される、分散コンピューティング環境でも実施され得る。しかしながら、全部ではないとしても、本発明のいくつかの態様は、スタンドアロンコンピュータ上で実施され得る。分散コンピューティング環境では、プログラムモジュールは、ローカルおよび／またはリモートメモリ記憶装置内に配置され得る。

さらに、開示し、説明するコンポーネントまたはプロセスは、標準的プログラミングおよび／または工学技術を使って、開示し、説明するコンポーネントまたはプロセスを実施するコンピュータを制御するためのソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせを生み出す方法、装置、または製造品としても実施され得る。本明細書で使用する場合の「製造品」という用語は、任意のコンピュータ読取り可能記憶装置、搬送波、または媒体からアクセス可能なコンピュータプログラムを包含するためのものである。例えば、コンピュータ読取り可能記憶媒体には、それだけに限らないが、特に、ハードディスク、フロッピー（登録商標）ディスク、磁気ストリップなどの磁気記憶装置、特に、コンパクトディスク（ＣＤ）やデジタル多用途ディスク（ＤＶＤ）などの光ディスク、スマートカード、および、特に、カード、スティック、キードライブなどのフラッシュメモリデバイスが含まれ得る。さらに、搬送波を用いて、電子メールを送受信し、またはインターネットやローカルエリアネットワーク（ＬＡＮ）などのネットワークにアクセスする際に使用されるコンピュータ読取り可能記憶電子データを搬送することもできることを理解すべきである。当然ながら、この構成に多くの小さな変更が加えられ得ることを、当分野の技術者は理解するであろう。

また、提示する具体例は、パーソナルコンピュータ上のファイルシステムの内容の検索に基づくシステムまたは方法を説明し、図示し得るが、適用はその領域だけに限定されないことも理解すべきである。例えば、開示し、説明するコンポーネントおよび方法は、イントラネット、プライベートネットワーク、インターネット上でも用いられ得る。それに加えて、または代替として、開示し、説明するコンポーネントおよび方法は、ストレージエリアネットワーク（ＳＡＮ）の一部としても使用され得る。開示し、説明するコンポーネントおよび方法は、特に、Ｗｅｂページ、データベース問い合わせ、写真情報、音声またはビデオ情報を含む、他の種類の情報を検索し、操作するためにも使用され得ることを、当分野の技術者は容易に理解するであろう。

エンドユーザプログラミング（ＥＵＰ）は、エンドユーザが、情報中心のソフトウェアアプリケーションのあらゆる挙動をもれなく制御できることとして説明され得る。ＥＵＰ原理およびコンポーネントは、エンドユーザの制御下で１つまたは複数のソフトウェアアプリケーションによって実行される自動化された情報処理タスクをカスタマイズし、パーソナル化するのに使用され得る。ＥＵＰ原理およびコンポーネントがユーザを支援するための、少なくとも３つの相互に関連する方法が存在する。

第１の方法では、エンドユーザが、通常、手動で実行する必要があるはずの潜在的に多数の処理ステップが、エンドユーザの特定の必要または要求に従って自動化され得る。例えば、非常に高い解像度で格納されたデジタル画像の大きなコレクションを処理するエンドユーザは、Ｗｅｂページで使用するためにこれらの画像の低解像度バージョンを作成しようとすることができる。それを手動で行うには、エンドユーザは、通常、編集プログラムで個々の画像を開き、様々なプログラム設定に従って低解像度コピーを作成し、新しいファイル名で、または新しい場所にその低解像度バージョンを保存する必要があるはずである。新しい画像の指定されたディレクトリへの追加時にこれらのタスクを自動的に実行するために、ＥＵＰモジュールが作成され得る。

ＥＵＰ原理を用いる第２の方法では、ＥＵＰモジュールは、エンドユーザのために相当量の計算を実行し得る。例えば、多くの検索タスクは非常に計算集約的であり、ＥＵＰモジュールは、検索（およびその他の計算上高くつくタスク）を自動的に実行し、検索結果をエンドユーザに報告することができきる。それに加えて、または代替として、ＥＵＰモジュールは、エンドユーザによって特に呼び出され、または実行される場合にそのようなタスクを実行することもできる。第３の方法では、ＥＵＰモジュールは、エンドユーザからの介入なしで自動的に機能して、エンドユーザが、特定のコンピューティングタスクではなく他のタスクに注意を集中できるようにし得る。この自動機能は、エンドユーザを、電子ファイルのソートや、そのようなファイルの論理コレクションへのグループ化など、手動で実行される時間集約的タスクから解放することによって、エンドユーザの生産性を向上させることができる。

本明細書で提示するＥＵＰ概念およびコンポーネントは、多種多様な実施形態がそれに基づいて作成され得る、一般化された、柔軟なプラットフォームを提供する。いくつかの可能な実施形態は、あらゆるユーザアプリケーションがエンドユーザプログラミング機能にアクセスし、その恩恵を受けることができるように、プラットフォーム全体にわたってエンドユーザプログラミングタスクをサポートするために使用され得る頑強なプラットフォームを提供することができる。別の可能な実施形態は、単一のアプリケーションだけのためにそのような機能をサポートすることができ、また別の実施形態は、これらの両極端の間のどこかに該当する。この開示を読めば、当分野の技術者は多くの変更および変形が可能であることを容易に理解するであろう。

エンドユーザプログラムは、本明細書の例ならびにその他の例で提示されるあらゆる形の計算されるアクションを定義し得る。１つの注目すべき形は、アクションのイベントとの関連を含み、エージェントと呼ばれ得る。同期イベントが関与するエージェントは、２つの特殊な該当事例を含み得る。第１の事例では、そのようなエージェントは、そのアプリケーションに固有のものとし得るアクションを実行することによって、アプリケーションカスタマイズを提供することができる。例えば、メールアプリケーションは、メールメッセージを送信する前に同期イベントを生成し得る。結果として生じるエージェントアクションは、メッセージに署名ファイルを添付することとすることができる。エージェントのアクションが条件付きアクションである場合、エージェントは、メッセージの特性に基づいて署名ファイルを選択することができる。第２の事例では、データに対する制約条件が伴う。データ制約エージェントは、イベントを生成させたデータへの変更を受け入れ、または拒否するように動作し得る。例えば、ファイルの所有権の変更は、イベントを生成させ得る。生成されたイベントは、所有権変更を評価するエージェントのアクションをトリガし得る。ファイルの現在の所有者、ファイルの新しい所有者、および変更を行うユーザの識別情報などの基準に基づいて、データ制約エージェントは、所有者情報の変更を受け入れ、または拒否することができる。

より洗練されたコンポーネントを使用して、より複雑な評価が可能である。そのようなコンポーネントは、パターンを識別またはマッチさせ、あるいは様々な分類タスクを実行し得る様々な人工知能コンポーネントを含み得る。使用され得る適当な人工知能コンポーネントには、特に、ニューラルネットワークおよびサポートベクトルマシンが含まれる。開示し、説明するコンポーネント（フィルタリングまたは管理タスクを実行するために作成されるエージェントなど）は、これら様々な人工知能ベースの方式を用いて、プログラムされたタスクを実行することができる。例えば、複雑なデータパターンの識別、および新しいデータの、その複雑なデータパターンを持つデータ集合に属するものとしての分類が、ニューラルネットワーク、ルールベースの処理コンポーネント、またはサポートベクトルマシンによって実行され得る。

分類子は、入力属性ベクトル、Ｘ＝（ｘ₁，ｘ₂，ｘ₃，ｘ₄，．．．ｘ_n）を、その入力があるクラス、すなわち、ｆ（Ｘ）＝ｃｏｎｆｉｄｅｎｃｅ（ｃｌａｓｓ）に属する信頼度にマップする関数である。そのような分類は、確率論的な、かつ／または統計ベースの分析（例えば、分析ユーティリティおよびコストを考慮に入れるなど）を用いて、ユーザが自動的に実行されることを望むアクションを予測し、または推定することができる。エンドユーザプログラミングシステムの事例では、データ項目は、それらのデータ項目の属性を検査することによって分類され得る。サポートベクトルマシン（ＳＶＭ）は、用いられ得る分類子の一例である。ＳＶＭは、トリガ基準を非トリガイベントから分割しようとする、可能な入力の空間における超曲面を見つけ出すことにより動作する。直観的には、これは、訓練データに近いが、それと同一ではない試験データを正しいと分類する。他の有向および無向モデル分類手法には、例えば、ナイーブベイズ、ベイジアンネットワーク、決定木が含まれ、異なる独立パターンを提供する確率論的分類モデルが用いられ得る。また、本明細書で使用する場合の分類には、優先順位のモデルを作成するのに利用される統計的回帰も含まれる。

本明細書から容易に理解されるように、本明細書で開示し、説明するコンポーネントは、（例えば、ユーザの挙動を観測すること、外部からの情報を受け取るなどによって）暗黙的に訓練されるのみならず、（例えば、汎用訓練データによって）明示的に訓練される分類子を用いることができる。例えば、ＳＶＭは、分類子コンストラクタおよび機能選択モジュール内の学習または訓練フェーズによって構成される。ゆえに、（１つまたは複数の）分類子は、それだけに限らないが、装置にデータが送られるべきかどうか決定することを含むいくつかの機能を自動的に実行するのに使用され得る。

図１１は、開示し、説明するコンポーネントおよびプロセスがそれと対話することのできる、コンピューティング環境の例１１００の概略的ブロック図である。システム１１００は、１つまたは複数のクライアント１１１０を含む。クライアント１１１０は、ハードウェアおよび／またはソフトウェア（スレッド、プロセス、コンピュータ装置など）とすることができる。また、システム１１００は、１つまたは複数のサーバ１１２０も含む。サーバ１１２０は、ハードウェアおよび／またはソフトウェア（スレッド、プロセス、コンピュータ装置など）とすることができる。サーバ１１２０は、例えば、開示し、説明するコンポーネントおよびプロセスを用いることによって変換を行うスレッドまたはプロセスを収容し得る。

クライアント１１１０とサーバ１１２０との間の１つの可能な通信手段は、２つ以上のコンピュータプロセス間で送信されるように適合されたデータパケットの形とすることができる。システム１１００は、クライアント１１１０とサーバ１１２０との間の通信を円滑化するために用いられ得る通信フレームワーク１１４０を含む。クライアント１１１０は、クライアント１１１０にとってローカルの情報を格納するのに用いられ得る１つまたは複数のクライアントデータストア１１５０に動作可能に接続される。同様に、サーバ１１２０は、サーバ１１４０にとってローカルの情報を格納するのに用いられ得る１つまたは複数のサーバデータストア１１３０に動作可能に接続される。

図１２を参照すると、本発明の様々な態様を実施する例示的環境１２００は、コンピュータ１２１２を含む。コンピュータ１２１２は、処理装置１２１４、システムメモリ１２１６、およびシステムバス１２１８を含む。システムバス１２１８は、それだけに限らないが、システムメモリ１２１６を含むシステムコンポーネントを処理装置１２１４に結合する。処理装置１２１４は、様々な利用可能なプロセッサのいずれでもよい。また、デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャも処理装置１２１４として用いられ得る。

システムバス１２１８は、それだけに限らないが、業界標準アーキテクチャ（ＩＳＡ）、マイクロチャネルアーキテクチャ（ＭＣＡ）、拡張ＩＳＡ（ＥＩＳＡ）、インテリジェントドライブエレクトロニクス（ＩＤＥ）、ＶＥＳＡローカルバス（ＶＬＢ）、周辺装置相互接続（ＰＣＩ）、カードバス、ユニバーサルシリアルバス（ＵＳＢ）、アドバンストグラフィックスポート（ＡＧＰ）、パーソナルコンピュータメモリカード国際協会バス（ＰＣＭＣＩＡ）、ファイヤワイヤ（ＩＥＥＥ１３９４）、小型コンピュータシステムインターフェイス（ＳＣＳＩ）を含む任意の様々な利用可能なバスアーキテクチャを使用する、数種類のメモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／またはローカルバスのいずれでもよい。

システムメモリ１２１６は、揮発性メモリ１２２０および不揮発性メモリ１２２２を含む。基本入出力システム（ＢＩＯＳ）は、起動時などに、コンピュータ１２１２内の諸要素間で情報を転送する基本ルーチンを含み、不揮発性メモリ１２２２に格納される。例としてあげるにすぎないが、不揮発性メモリ１２２２には、読取り専用メモリ（ＲＯＭ）、プログラム可能ＲＯＭ（ＰＲＯＭ）、電気的プログラム可能ＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリが含まれ得る。揮発性メモリ１２２０は、外部キャッシュメモリとして働く、ランダムアクセスメモリ（ＲＡＭ）を含む。例としてあげるにすぎないが、ＲＡＭは、同期ＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、同期ＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、拡張ＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンクＤＲＡＭ（ＳＬＤＲＡＭ）、ダイレクトランバスＲＡＭ（ＤＲＲＡＭ）など、多くの形で利用可能である。

また、コンピュータ１２１２は、取外し可能／取外し不能、揮発性／不揮発性コンピュータ記憶媒体も含む。例えば、図１２には、ディスク記憶装置１２２４が示されている。ディスク記憶装置１２２４には、それだけに限らないが、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、メモリスティックなどのデバイスが含まれる。また、ディスク記憶装置１２２４は記憶媒体を、別々に、または、それだけに限らないが、コンパクトディスクＲＯＭドライブ（ＣＤ−ＲＯＭ）、書込み可能なＣＤドライブ（ＣＤ−Ｒドライブ）、書き換え可能なＣＤドライブ（ＣＤ−ＲＷドライブ）、デジタル多用途ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）などの光ディスクドライブを含む他の記憶媒体と組み合わせて含むこともできる。ディスク記憶装置１２２４のシステムバス１２１８への接続を円滑化するために、通常は、インターフェース１２２６などの取外し可能または取外し不可能なインターフェースが使用される。

図１２には、ユーザと、適当な動作環境１２００に示す基本コンピュータリソースとの間の仲介として働くソフトウェアが示されていることを理解すべきである。そのようなソフトウェアには、オペレーティングシステム１２２８が含まれる。オペレーティングシステム１２２８は、ディスク記憶装置１２２４に格納することができ、コンピュータシステム１２１２のリソースを制御し、それを割り振るように動作する。システムアプリケーション１２３０は、システムメモリ１２１６またはディスク記憶装置１２２４に格納されたプログラムモジュール１２３２およびプログラムデータ１２３４を介して、オペレーティングシステム１２２８によるリソース管理を利用する。本発明は、様々なオペレーティングシステムまたはオペレーティングシステムの組み合わせを用いて実施され得ることを理解すべきである。

ユーザは、（１つまたは複数の）入力装置１２３６を介してコンピュータ１２１２にコマンドまたは情報を入力する。入力装置１２３６には、それだけに限らないが、マウス、トラックボール、スタイラス、タッチパッドなどのポインティングデバイス、キーボード、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、Ｗｅｂカメラなどが含まれる。上記およびその他の入力装置は、（１つまたは複数の）インターフェースポート１２３８を介し、システムバス１２１８によって処理装置１２１４に接続される。インターフェースポート１２３８には、例えば、シリアルポート、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）などが含まれる。（１つまたは複数の）出力装置１２４０は、いくつかの、入力装置１２３６と同じ種類のポートを使用する。ゆえに、例えば、ＵＳＢポートは、コンピュータ１２１２への入力を提供すると共に、コンピュータ１２１２から出力装置１２４０に情報を出力するためにも使用され得る。出力アダプタ１２４２は、出力装置１２４０の中でも特に、特殊なアダプタを必要とする、モニタ、スピーカ、プリンタのようないくつかの出力装置１２４０があることを示すために設けられている。出力アダプタ１２４２には、例としてあげるにすぎないが、出力装置１２４０とシステムバス１２１８の間の接続手段を提供するビデオおよびサウンドカードが含まれる。リモートコンピュータ１２４４など他の装置および／または装置システムも、入力と出力の両方の機能を提供することに留意すべきである。

コンピュータ１２１２は、リモートコンピュータ１２４４など、１つまたは複数のリモートコンピュータへの論理接続を使用するネットワークを介して接続された環境で動作し得る。リモートコンピュータ１２４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの電気器具、ピアデバイスまたはその他一般的なネットワークノードなどとすることができ、通常は、コンピュータ１２１２に関連して説明した要素の多くまたは全部を含む。簡略にするために、メモリ記憶装置１２４６だけが、リモートコンピュータ１２４４と共に示されている。リモートコンピュータ１２４４は、ネットワークインターフェース１２４８を介してコンピュータ１２１２に論理的に接続され、次いで、通信接続１２５０を介して物理的に接続される。ネットワークインターフェース１２４８は、ローカルエリアネットワーク（ＬＡＮ）や広域ネットワーク（ＷＡＮ）などの有線および／または無線通信ネットワークを包含する。ＬＡＮ技術には、光ファイバ分散データインターフェース（ＦＤＤＩ）、より対線ＦＤＤＩ（ＣＤＤＩ）、イーサネット（登録商標）、トークンリングなどが含まれる。ＷＡＮ技術には、それだけに限らないが、ポイントツーポイント（point-to-point）リンク、統合サービスデジタルネットワーク（ＩＳＤＮ）およびその変形などの回路交換ネットワーク、パケット交換ネットワーク、およびデジタル加入者線（ＤＳＬ）が含まれる。

通信接続１２５０は、ネットワークインターフェース１２４８をバス１２１８に接続するために用いられるハードウェア／ソフトウェアを指す。通信接続１２５０は、図を明確にするためにコンピュータ１２１２の内部に示されているが、コンピュータ１２１２の外部とすることもできる。ネットワークインターフェース１２４８への接続に必要なハードウェア／ソフトウェアには、例にすぎないが、通常の電話グレードのモデム、ケーブルモデムおよびＤＳＬモデム、ＩＳＤＮアダプタ、イーサネット（登録商標）カードなどの内部および外部技術が含まれる。

以上の説明には、いくつかのコンポーネントおよび方法の実例が含まれている。当然ながら、コンポーネントまたは方法の考え得るあらゆる組み合わせを記述することは不可能であるが、多くの別の組み合わせおよび置換が可能であることを当分野の技術者は理解するであろう。したがって、そのようなすべての変更、改変、および変形は、添付の特許請求の範囲の趣旨および範囲内に含まれるものである。

特に、前述のコンポーネント、装置、回路、システムなどによって実行される様々な機能に関して、そのようなコンポーネントを記述するのに使用される（「手段」への言及を含む）用語は、特に指示しない限り、本明細書で示す例における機能を実行する開示の構造と構造的に同等でなくとも、前述のコンポーネントの指定された機能を実行する任意のコンポーネント（例えば、機能的均等物など）に対応することが意図されている。この点に関して、開示し、説明するコンポーネントおよび方法は、様々な開示し、説明する方法の動作および／またはイベントを実行するコンピュータ実行可能命令を有するシステム、ならびにコンピュータ読取り可能記憶媒体を含み得ることも理解されるであろう。

さらに、特定の機能を、いくつかの実施形態のただ１つに関連して開示しているが、そのような機能は、任意の所与の、または特定の用途のために求められ、有利とされ得るように、その他の実施形態の他の１つまたは複数の機能と組み合わされ得る。さらに、「含む（ｉｎｃｌｕｄｅｓ）」および「含んでいる（ｉｎｃｌｕｄｉｎｇ）」という語、ならびにそれらの変形が詳細な説明または特許請求の範囲で使用される限りにおいて、これらの用語は、「備える（ｃｏｍｐｒｉｓｉｎｇ）」という語と同様に包含的であることが意図されている。

エンドユーザプログラミングシステムを示すシステムブロック図である。 エンドユーザプロセシングシステムを示すシステムブロック図である。 ルールスキーマを示すスキーマ図である。 統合ファイルシステムを有するエンドユーザプログラミングシステムを示すシステムブロック図である。 統合ファイルシステムを有するエンドユーザプログラミングシステムを示すシステムブロック図である。 統合ファイルシステムを有するエンドユーザプログラミングシステムを示すシステムブロック図である。 統合ファイルシステムを有するエンドユーザプログラミングシステムを示すシステムブロック図である。 本明細書で開示し、説明するコンポーネントと一緒に使用され得る一般的な処理方法を示す流れ図である。 本明細書で開示し、説明するコンポーネントと一緒に使用され得る一般的な処理方法を示す流れ図である。 情報のライフサイクルを示す流れ図である。 例示的ネットワーク環境を示すシステムブロック図である。 例示的動作環境を示すシステムブロック図である。

Claims (20)

1. データ処理を自動化するシステムであって、
   基礎をなすファイルシステムと統合され、コンピューティングシステムのイベントを、エンドユーザによって定義される少なくとも１つの自動化されたアクションにマップするエンドユーザプログラミングモジュールと、
   前記イベントに応答し、前記イベントの発生に応答して前記少なくとも１つの自動アクションを実行させるイベントハンドラと
   を備えることを特徴とするシステム。
2. 前記イベントはオペレーティングシステムによって作成されることを特徴とする請求項１に記載のシステム。
3. 前記イベントはモニタアプリケーションによって作成されることを特徴とする請求項１に記載のシステム。
4. 前記イベントはユーザアプリケーションによって作成されることを特徴とする請求項１に記載のシステム。
5. 前記自動アクションは、前記イベントを作成した前記ユーザアプリケーションと異なる第２のユーザアプリケーションによって実行されることを特徴とする請求項４に記載のシステム。
6. 格納されたデータへのアクセスを提供するために前記エンドユーザプログラミングモジュールと統合されるファイルシステムをさらに備えることを特徴とする請求項４に記載のシステム。
7. 前記ファイルシステムは分散ファイルシステムであることを特徴とする請求項６に記載のシステム。
8. 前記分散ファイルシステムは、ネットワークで接続された複数の協働する記憶装置にまたがって分散されることを特徴とする請求項７に記載のシステム。
9. データを自動的に処理する方法であって、
   統合ファイルシステムにおいてデータに対するユーザ定義アクションを開始するのに使用され得るコンピューティングシステム上のトリガイベントを識別すること、
   前記識別されたイベントの検出時にとられるエンドユーザ定義アクションを指定すること、および
   前記識別されたイベントの前記発生を検出すると、前記エンドユーザ定義アクションを自動的に実行すること
   を含むことを特徴とする方法。
10. 前記トリガイベントは、オペレーティングシステム、モニタアプリケーション、およびユーザアプリケーションの少なくとも１つによって作成されるイベントであることを特徴とする請求項９に記載の方法。
11. 前記エンドユーザ定義アクションを自動的に実行することは、オペレーティングシステム、モニタアプリケーション、およびユーザアプリケーションの少なくとも１つによって実行されることを特徴とする請求項９に記載の方法。
12. 前記エンドユーザ定義アクションに関する処理命令を獲得するためにデータストアにアクセスすること
    をさらに含むことを特徴とする請求項９に記載の方法。
13. データストアにアクセスすることは統合ファイルシステムにアクセスすることを含むことを特徴とする請求項１２に記載の方法。
14. 統合ファイルシステムにアクセスすることは分散ファイルシステムにアクセスすることを含むことを特徴とする請求項１３に記載の方法。
15. データを自動的に処理するシステムであって、
    統合ファイルシステムにおいてデータに対するユーザ定義アクションを開始するのに使用され得るコンピューティングシステム上のトリガイベントを識別する手段と、
    前記識別されたイベントの検出時にとられるエンドユーザ定義アクションを指定する手段と、
    前記識別されたイベントの前記発生を検出すると、前記エンドユーザ定義アクションを自動的に実行する手段と
    を備えることを特徴とするシステム。
16. 前記トリガイベントは、オペレーティングシステム、モニタアプリケーション、およびユーザアプリケーションの少なくとも１つによって作成されるイベントであることを特徴とする請求項１５に記載のシステム。
17. 前記エンドユーザ定義アクションを自動的に実行する前記手段は、オペレーティングシステム、モニタアプリケーション、およびユーザアプリケーションの少なくとも１つを含むことを特徴とする請求項１５に記載のシステム。
18. 前記エンドユーザ定義アクションに関する処理命令を獲得するためにデータストアにアクセスする手段
    をさらに備えることを特徴とする請求項１５に記載のシステム。
19. データストアにアクセスする前記手段は統合ファイルシステムにアクセスする手段を含むことを特徴とする請求項１８に記載のシステム。
20. 統合ファイルシステムにアクセスする前記手段はリモートファイルシステムに接続する手段を含むことを特徴とする請求項１９に記載のシステム。
    

Images