(57)【要約】  リソースイベントエージェント（ＲＥＡ）モデルを利用したセキュリティを提供する方法（９００）は、第１のオブジェクト（５０５）と第２のオブジェクト（５１０）の間の関連付け（５１５）を識別する（９０５）ことを含み、第１のオブジェクトは、エージェントタイプであり、第２のオブジェクトは、ＲＥＡオブジェクトである。次いで、第１のオブジェクト（５０５）と第２のオブジェクト（５１０）間の関連付けに関連付けのクラス（５２０）が作成される（９１０）。例えばセキュリティポリシーの関連付けクラスと呼ばれるこの関連付けクラスは、第１のオブジェクトと第２のオブジェクトの間にセキュリティを定義する。【特許請求の範囲】
【請求項１】
リソースイベントエージェント（ＲＥＡ）モデルを利用したセキュリティを提供する方法であって、
ＲＥＡモデル中の第１のオブジェクトと第２のオブジェクトの間の関連付けを識別するステップと、
前記第１のオブジェクトと前記第２のオブジェクト間の前記関連付けに関連付けのクラスを作成するステップであり、前記関連付けのクラスは、前記第１のオブジェクトと前記第２のオブジェクトの間のセキュリティを定義するステップと
を備えることを特徴とする方法。
【請求項２】
前記第１のオブジェクトと前記第２のオブジェクト間の前記関連付けの前記関連付けクラスを作成するステップはさらに、プロパティを有する関連付けクラスのオブジェクトを作成するステップを備え、前記関連付けクラスのオブジェクトのプロパティは、前記第１のオブジェクトと前記第２のオブジェクト間のセキュリティを定義することを特徴とする請求項１に記載の方法。
【請求項３】
前記関連付けクラスのオブジェクトを作成するステップはさらに、プロパティを有する１つまたは複数の関連付けクラスのオブジェクトを作成するステップを備え、前記１つまたは複数の関連付けクラスのオブジェクトのプロパティは、前記第１のオブジェクトがメンバである第１のオブジェクトクラスと、前記第２のオブジェクトがメンバである第２のオブジェクトクラスの間にセキュリティを定義することを特徴とする請求項２に記載の方法。
【請求項４】
前記第２のオブジェクトは、セキュラブルオブジェクトであることを特徴とする請求項２に記載の方法。
【請求項５】
前記第１のオブジェクトは、特定のエージェントタイプであり、前記第１のオブジェクトの前記特定のエージェントタイプによってユーザのロールが定義されることを特徴とする請求項４に記載の方法。
【請求項６】
前記第２のオブジェクトは、契約または協定タイプのオブジェクトであることを特徴とする請求項５に記載の方法。
【請求項７】
前記第２のオブジェクトは、委託タイプのオブジェクトであることを特徴とする請求項５に記載の方法。
【請求項８】
前記第２のオブジェクトは、イベントタイプのオブジェクトであることを特徴とする請求項５に記載の方法。
【請求項９】
前記第２のオブジェクトは、リソースタイプのオブジェクトであることを特徴とする請求項５に記載の方法。
【請求項１０】
前記第２のオブジェクトは、エージェントタイプのオブジェクトであることを特徴とする請求項５に記載の方法。
【請求項１１】
前記第１のオブジェクトと前記第２のオブジェクト間の関連付けを識別するステップはさらに、前記第１のオブジェクトと前記第２のオブジェクトの間にコントロールタイプの関連付けを識別するステップを備えることを特徴とする請求項５に記載の方法。
【請求項１２】
前記第１のオブジェクトと前記第２のオブジェクト間の関連付けを識別するステップはさらに、前記第１のオブジェクトと前記第２のオブジェクトの間に保護管理タイプの関連付けを識別するステップを備えることを特徴とする請求項５に記載の方法。
【請求項１３】
前記第１のオブジェクトと前記第２のオブジェクトの間の前記関連付けの前記関連付けクラスを作成するステップはさらに、セキュリティモデル中に前記関連付けクラスを作成するステップを備えることを特徴とする請求項５に記載の方法。
【請求項１４】
前記セキュリティモデル中に前記関連付けクラスを作成するステップはさらに、前記ＲＥＡモデルと別個の前記セキュリティモデル中に前記関連付けクラスを作成するステップを備えることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記セキュリティモデル中に前記関連付けクラスを作成するステップはさらに、前記ＲＥＡモデルの一部である前記セキュリティモデル中に前記関連付けクラスを作成するステップを備えることを特徴とする請求項１３に記載の方法。
【請求項１６】
前記第１のオブジェクトと前記第２のオブジェクトの間にセキュリティを定義するステップはさらに、前記第２のオブジェクトに対する前記第１のオブジェクトの権限および権利を定義するステップを備えることを特徴とする請求項１３に記載の方法。
【請求項１７】
前記第２のオブジェクトに対する前記第１のオブジェクトの権限および権利を定義するステップはさらに、前記セキュリティモデルの外部にあるセキュリティポリシーロジックモジュール中で前記権限および権利を動的に決定するステップを備えることを特徴とする請求項１６に記載の方法。
【請求項１８】
請求項１から１７のいずれかに記載の方法のステップを行うコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
【請求項１９】
請求項１から１７のいずれかに記載の方法を実施するように構成されることを特徴とするシステム。
【請求項２０】
セキュリティを提供するシステムであって、
第１のオブジェクト、第２のオブジェクト、および前記第１のオブジェクトと前記第２のオブジェクト間の関連付けを実施するように構成されたリソースイベントエージェント（ＲＥＡ）モデルと、
前記第１のオブジェクトと前記第２のオブジェクトの間にセキュリティを定義するように、前記ＲＥＡモデル中の前記第１のオブジェクトと前記第２のオブジェクト間の前記関連付けに関連付けのクラスを実施するように構成されたセキュリティモデルと
を備えることを特徴とするシステム。
【請求項２１】
前記第１のオブジェクトと前記第２のオブジェクト間の前記関連付けの前記関連付けクラスはさらに、プロパティを有する関連付けクラスのオブジェクトを備え、前記関連付けクラスのオブジェクトのプロパティは、前記第１のオブジェクトと前記第２のオブジェクトの間のセキュリティを定義することを特徴とする請求項２０に記載のシステム。
【請求項２２】
前記関連付けクラスのオブジェクトはさらに、プロパティを有する１つまたは複数の関連付けクラスのオブジェクトを備え、前記１つまたは複数の関連付けクラスのオブジェクトのプロパティは、前記第１のオブジェクトがメンバである第１のオブジェクトクラスと、前記第２のオブジェクトがメンバである第２のオブジェクトクラスの間にセキュリティを定義することを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記セキュリティモデルは、前記ＲＥＡモデルと別個であることを特徴とする請求項２１に記載のシステム。
【請求項２４】
前記セキュリティモデルは、前記ＲＥＡモデルの一部であることを特徴とする請求項２１に記載のシステム。
【請求項２５】
前記セキュリティモデルに結合され、前記第２のオブジェクトに対する前記第１のオブジェクトの権限および権利を動的に決定するように構成されたセキュリティポリシーロジックモジュールをさらに備えることを特徴とする請求項２１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソースイベントエージェント（ＲＥＡ）モデルと、ＲＥＡモデルを使用したシステムおよび方法に関する。より詳細には、本発明は、ＲＥＡモデルにセキュリティを提供する方法に関する。
【背景技術】
【０００２】
ビジネスユーザとアプリケーション開発者は、主要な抽象化が、業務人が各自の仕事を記述するために使用する概念となっているソフトウェアアプリケーションを好む。例えば、経済資源、提携先、契約、協定といった概念は、ビジネスユーザにとって自然であり、一方、クラス、メソッド、仮想の集まり、フィールドといった概念は、プログラマにとって自然であるが、ビジネスユーザにとってはそうではない。
【０００３】
モデル駆動型の開発へと向かう現在の傾向は、低レベルのプログラミングから、ドメインエキスパートの概念に基づくモデル化に移行することを試みるものである。モデル化を行うことができる前に、そのモデルがコードで表されるのか、図で表されるのかに関係なく、そのモデルを扱うすべての者のための言語として機能することができる、広く普及した言語(ubiquitous language)を選ぶことが望ましい。その言語は、ソフトウェアの開発時と使用時の長期間の使用に耐えなければならない。その言語が、そうした要件を満たすだけの信頼性と包括性を備えることを保証する重要な側面の１つは、その言語を堅固な土台に基づかせることである。そうした必要性に対処する堅固な土台を提供するモデル化言語の１つが、ＲＥＡである。
【０００４】
ＲＥＡは、１９８２年にＷｉｌｌｉａｍ  Ｅ．ＭａＣａｒｔｈｙによって導入された規範的な会計モデルである（例えば非特許文献１参照）。ＲＥＡは、しばしば、モデル、フレームワーク、オントロジー、企業情報システムアーキテクチャ、あるいは他の一般的に使用される名前で呼ばれる。ＲＥＡモデルの基本的な利点は、業務のプロセスを記述する、規範となるモデルを提供することである。基本的な規範的モデルを中心として、近年、モデル化の方法論自体のより多くの細目や、世間一般の標準へのＲＥＡの採用などの形で、追加事項からなる全体的インフラストラクチャが追加されている。
【０００５】
【非特許文献１】William E. McCarthy, The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment, The Accounting Review, Vol. LVII, No. 3, July 1982
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ＲＥＡは、「所有権」や「関与」のモデル化を可能にするが、通例は、ビジネスモデルのセキュリティ面は扱わない。従来のビジネスアプリケーションは、セキュリティの細目を、ドメインあるいはビジネスアプリケーションのモデル化から切り離している。そのために、セキュリティの設定やメタデータに関してはほとんど見出すものがなく、セキュリティサブシステムは、多くの場合、欠落しているか、アプリケーションのソリューションと並行して実装される。
【０００７】
従来のセキュリティのソリューションは、通例、開発者に、そのシステムの様々なロール(role)によって閲覧することができるプロパティと、閲覧できないプロパティのリストを設定させるものであった。この手法は、間違いが発生しやすい。さらに、この手法は、非常に複雑な実装を伴い、しばしば１回のインストールに数日を要する。時に、この手法は、開発者がソリューションをコーディングすることによってソフトウェアとして実装される。その結果、ユーザ（システム管理者など）が設定を変更し、独自のロール／セキュリティアクセス権を定義することができないため、正しいセキュリティ設定を得ることがさらに難しくなる。
【課題を解決するための手段】
【０００８】
リソースイベントエージェント（ＲＥＡ）モデルを利用したセキュリティを提供する方法は、ＲＥＡモデル中の第１のオブジェクトと第２のオブジェクト間の関連付け(association)を識別することを含む。次いで、第１のオブジェクトと第２のオブジェクト間の関連付けに関連付けのクラスが作成される。例えばセキュリティポリシーの関連付けクラスと呼ばれるこの関連付けクラスは、第１のオブジェクトと第２のオブジェクトの間にセキュリティを定義する。
【０００９】
第１のオブジェクトと第２のオブジェクトの間に定義される関連付けクラスは、プロパティを有するオブジェクトである。関連付けクラスのオブジェクトのプロパティは、第１のオブジェクトと第２のオブジェクトの間のセキュリティを定義する。関連付けのクラスを作成するステップはさらに、プロパティを有する１つまたは複数の関連付けクラスのオブジェクトを作成するステップを備えることができ、その１つまたは複数の関連付けクラスのオブジェクトのプロパティが、第１のオブジェクトがメンバである第１のオブジェクトクラスと、第２のオブジェクトがメンバである第２のオブジェクトクラスの間にセキュリティを定義する。第２のオブジェクトは、契約または協定タイプのオブジェクト、委託(commitment)タイプのオブジェクト、イベントタイプのオブジェクト、あるいはリソースタイプのオブジェクトなど、セキュリティ確保が可能なセキュラブル(securable)オブジェクトである。第１のオブジェクトは、特定のエージェントタイプである。第１のオブジェクトの特定のエージェントタイプにより、ユーザのロールが定義される。
【００１０】
第１のオブジェクトと第２のオブジェクトの間に作成される関連付けクラスは、ＲＥＡモデルと別個のセキュリティモデル中に、またはＲＥＡモデルの一部であるセキュリティモデル中に作成することができる。第１のオブジェクトと第２のオブジェクトの間に定義されるセキュリティは、第２のオブジェクトに対する第１のオブジェクトの権限と権利を定義することを含む。それらの権限と許可は、セキュリティモデルの外側のセキュリティポリシーロジックモジュール中で動的に決定することができる。これは、特に、日付、時刻、イベントのステータスなどに依存する、推移的な性質の権限と許可に有用である。
【００１１】
本発明の実施形態を特徴付けるこの他の特徴と利点は、以下の詳細な説明を読み、関連する図面を検討すると明らかになろう。
【発明を実施するための最良の形態】
【００１２】
リソースイベントエージェント（ＲＥＡ）モデルは、「所有権」や「関与」のモデル化を可能にするが、ＲＥＡモデル化のセマンティックは、セキュリティ設定を推進するためには使用されてこなかった。本発明は、部分的には、ＲＥＡモデル化のセマンティックを使用してそのようなセキュリティを提供することができるという認識に基づく。開示されるのは、そうしたセマンティックを取り込んだＲＥＡモデルから、デフォルトのセキュリティ設定を促進する際にＲＥＡセマンティックを使用するストラテジである。このストラテジは、本発明の方法および装置で使用される。
【００１３】
従来の業務アプリケーションは、セキュリティの細目を、ドメインあるいはビジネスアプリケーションのモデル化と切り離している。そうした従来の業務アプリケーションで使用されるセキュリティを実装するメソッドと異なり、ここに開示されるストラテジを使用すると、ＲＥＡモデル化の技術を使用して、ドメインあるいはビジネスソリューションにセキュリティ情報を構築することができる。本発明で使用される用語「セマンティックモデル」とは、例えば供給チェーンの活動など、実世界の活動のコンピュータソフトウェアモデルを意味する。セマンティックモデルは、内容が豊富であり、それがモデル化する実世界に関連するオブジェクト、関係、および機能のクラスを記述する。ＲＥＡセマンティックモデルは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）、ＵＭＬ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）、リレーショナルデータベース、および／またはオブジェクト指向のプログラミング言語など、多種のフォーマットで表現することができる。以下の説明では、ＲＥＡモデルにセキュリティを実装する改良点について、主としてＵＭＬの観点から説明するが、本発明は、ＵＭＬによる実装に限定されない。
【００１４】
図１に、本発明を実施することが可能な適切なコンピューティングシステム環境１００の例を表す。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲について限定を示唆するものではない。また、コンピューティング環境１００は、例示的動作環境１００に図示される構成要素の１つまたは組み合わせに関連する依存性あるいは必要性を有するものとも解釈すべきでない。
【００１５】
本発明は、他の多数の汎用または特殊目的のコンピューティングシステムあるいは構成で動作することができる。本発明に使用するのに適する可能性があるよく知られるコンピューティングシステム、環境、および／または構成の例には、これらに限定しないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドあるいはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサを利用したシステム、セットトップボックス、設定可能な家庭電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムおよびデバイスを含む分散コンピューティング環境などがある。
【００１６】
本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで説明することができる。一般に、プログラムモジュールには、特定のタスクを行うか、特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などがある。本発明は、通信ネットワークを通じてつながれた遠隔の処理デバイスによってタスクが行われる分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルおよびリモート両方のコンピュータ記憶媒体に置くことができる。
【００１７】
図１を参照すると、本発明を実施する例示的システムは、コンピュータ１１０の形態の汎用コンピューティングデバイスを含む。コンピュータ１１０の構成要素には、これらに限定しないが、処理装置１２０、システムメモリ１３０、およびシステムメモリを含む各種のシステム構成要素を処理装置１２０に結合するシステムバス１２１が含まれる。システムバス１２１は、各種のバスアーキテクチャを使用した、メモリバスあるいはメモリコントローラ、ペリフェラルバス、およびローカルバスを含む数種のバス構造のいずれでもよい。限定ではなく例として、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも称されるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスがある。
【００１８】
コンピュータ１１０は、通例、各種のコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によるアクセスが可能な任意の利用可能媒体でよく、揮発性および不揮発性の媒体、取り外し式および固定式の媒体が含まれる。限定ではなく例として、コンピュータ可読媒体は、コンピュータ記憶媒体と通信媒体からなることができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータなどの情報を記憶するための方式または技術として実施された、揮発性および不揮発性、取り外し式および固定式の媒体が含まれる。コンピュータ記憶媒体には、これらに限定しないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶、または他の磁気記憶装置、または、所望の情報を記憶するために使用することができ、コンピュータ１１０によるアクセスが可能な他の媒体が含まれる。通信媒体は、通例、コンピュータ可読命令、データ構造、プログラムモジュール、あるいは他のデータを、搬送波や他の移送機構などの変調データ信号として実施し、任意の情報伝達媒体を含む。用語「変調データ信号」とは、信号中に情報を符号化するような方式でその特性の１つまたは複数を設定または変化させた信号を意味する。限定ではなく例として、通信媒体には、有線ネットワークや直接配線接続などの有線媒体と、音波、ＲＦ、赤外線、他の無線媒体などの無線媒体が含まれる。上記の媒体の組み合わせも、コンピュータ可読媒体の範囲に含める。
【００１９】
システムメモリ１３０には、読み取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性メモリおよび／または不揮発性メモリの形態のコンピュータ記憶媒体が含まれる。起動時などにコンピュータ１１０内の要素間の情報転送を助ける基本ルーチンを含む基本入出システム１３３（ＢＩＯＳ）は、通例、ＲＯＭ１３１に記憶される。ＲＡＭ１３２は、通例、処理装置１２０から即座にアクセスできる、かつ／または処理装置１２０によって現在操作されているデータおよび／またはプログラムモジュールを保持する。限定ではなく例として、図１には、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。
【００２０】
コンピュータ１１０は、他の取り外し式／固定式、揮発性／不揮発性のコンピュータ記憶媒体も含むことができる。単なる例として、図１には、固定式、不揮発性の磁気媒体の読み書きを行うハードディスクドライブ１４１、取り外し式、不揮発性の磁気ディスク１５２の読み書きを行う磁気ディスクドライブ１５１、および、ＣＤ−ＲＯＭや他の光学媒体などの取り外し式、不揮発性の光ディスク１５６の読み書きを行う光ディスクドライブ１５５を示す。例示的動作環境で使用することができる他の取り外し式／固定式、揮発性／不揮発性のコンピュータ記憶媒体には、これらに限定しないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体素子ＲＡＭ、固体素子ＲＯＭなどがある。ハードディスクドライブ１４１は、通例、インタフェース１４０などの固定式メモリインタフェースを通じてシステムバス１２１に接続され、磁気ディスクドライブ１５１と光ディスクドライブ１５５は、通例、インタフェース１５０などの取り外し式メモリインタフェースでシステムバス１２１に接続される。
【００２１】
上記で述べ、図１に示す、これらのドライブとそれに関連付けられたコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの記憶をコンピュータ１１０に提供する。図１では、例えば、ハードディスクドライブ１４１に、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７が記憶されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じものでも、異なってもよいことに留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、それらが少なくとも異なるコピーであることを表すために、異なる参照符合を付している。
【００２２】
ユーザは、キーボード１６２、マイクロフォン１６３、およびマウス、トラックボール、タッチパッドなどのポインティングデバイス１６１などの入力装置を通じてコンピュータ１１０にコマンドと情報を入力することができる。他の入力装置（図示せず）としては、ジョイスティック、ゲームパッド、衛星受信アンテナ、スキャナなどが可能である。上記および他の入力装置は、多くの場合、システムバスに結合されたユーザ入力インタフェース１６０を通じて処理装置１２０に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など、他のインタフェースおよびバス構造で接続してもよい。モニタ１９１または他の種類の表示装置も、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは、スピーカ１９７、プリンタ１９６などの他の周辺出力装置も含むことができ、それらは、出力周辺インタフェース１９５を通じて接続することができる。
【００２３】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のコンピュータとの論理接続を使用するネットワーク環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、あるいは他の一般的なネットワークノードであり、通例は、コンピュータ１１０との関連で上述した要素の多くまたはすべてを含む。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１とワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むことも可能である。このようなネットワーキング環境は、オフィス、企業内のコンピュータネットワーク、イントラネット、およびインターネットに一般的に見られる。
【００２４】
ＬＡＮネットワーキング環境で使用される場合、コンピュータ１１０は、ネットワークインタフェースあるいはアダプタ１７０を通じてＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１１０は、通例、インターネットなどのＷＡＮ１７３を通じて通信を確立するためのモデム１７２あるいは他の手段を含む。モデム１７２は、内蔵型でも外付け型でもよく、ユーザ入力インタフェース１６０あるいは他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０との関連で図示するプログラムモジュールあるいはその一部は、遠隔のメモリ記憶装置に記憶してよい。限定ではなく、例として、図１では、リモートアプリケーションプログラム１８５がリモートコンピュータ１８０にある。図のネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段を使用してよいことは理解されよう。
【００２５】
図２は、代替の例示的コンピューティング環境であるモバイルデバイス２００のブロック図である。モバイルデバイス２００は、マイクロプロセッサ２０２、メモリ２０４、入出力（Ｉ／Ｏ）コンポーネント２０６、および、リモートコンピュータや他のモバイルデバイスと通信する通信インタフェース２０８を含む。一実施形態では、上述のコンポーネントは、適切なバス２１０を通じて相互と通信するように結合される。
【００２６】
メモリ２０４は、バッテリバックアップモジュール（図示せず）を備えるランダムアクセスメモリ（ＲＡＭ）などの不揮発性の電子メモリとして実装され、メモリ２０４に記憶された情報は、モバイルデバイス２００への全体的な電力が切断されたときに失われない。メモリ２０４の一部は、プログラム実行のためのアドレス指定可能なメモリとして割り振られることが好ましく、メモリ２０４の別の部分は、ディスクドライブへの記憶を擬似するなど、記憶のために使用されることが好ましい。
【００２７】
メモリ２０４は、オペレーティングシステム２１２、アプリケーションプログラム２１４、ならびにオブジェクトストア２１６を含む。動作の際、オペレーティングシステム２１２は、プロセッサ２０２によってメモリ２０４から実行されることが好ましい。好ましい一実施形態で、オペレーティングシステム２１２は、マイクロソフト社から市販されるＷＩＮＤＯＷＳ（登録商標）（Ｒ）ＣＥブランドのオペレーティングシステムである。オペレーティングシステム２１２は、モバイルデバイス向けであることが好ましく、公開されたアプリケーションプログラムインタフェースおよびメソッドのセットを通じてアプリケーション２１４が利用することができるデータベース機能を実施する。オブジェクトストア２１６のオブジェクトは、少なくとも部分的には、公開されたアプリケーションプログラムインタフェースおよびメソッドに対する呼び出しに応答して、アプリケーション２１４およびオペレーティングシステム２１２によって保持される。
【００２８】
通信インタフェース２０８は、モバイルデバイス２００が情報を送受信することを可能にする多数のデバイスと技術に相当する。そうしたデバイスの数例には、有線モデムおよび無線モデム、衛星受信機、および放送チューナなどがある。モバイルデバイス２００は、コンピュータに直接接続して、そのコンピュータとデータを交換することもできる。そのような場合、通信インタフェース２０８は、赤外線トランシーバ、またはシリアルあるいはパラレルの通信接続とすることができ、それらはいずれもストリーミング情報を送信することができる。
【００２９】
入出力コンポーネント２０６には、タッチセンシティブ画面、ボタン、ローラ、マイクロフォンなどの各種の入力装置と、オーディオ生成器、振動装置、ディスプレイを含む各種の他の出力装置が含まれる。上述の装置は、例であり、モバイルデバイス２００にすべてが存在する必要はない。また、他の入力／出力装置をモバイルデバイス２００に取り付ける、あるいはモバイルデバイス２００に組み込むことが可能である。
【００３０】
（ＲＥＡモデル化の概説）
ＲＥＡは、経済システムおよびビジネスシステムを記述するための、確立されたモデル化技術、オントロジー、およびセマンティックモデルである。ＲＥＡは、ビジネスシステムを、経済リソース、経済イベント、および経済エージェントのセットとして、またそれらの間の関係として記述する。経済イベントは、経済エージェント間の経済リソースの所有権の変化を捉える。図３に、リソース３０５、イベント３１０、およびエージェント３１５を有する、基本的なＲＥＡのメタモデル３００を示す。
【００３１】
ＲＥＡモデルでは、経済リソースの交換が、企業に関する主要な経済データとなる。借方、掛け売り、仕訳、元帳、受け取勘定、および収支などの経理の人為的結果(artifact)が、経済リソースの交換を記述するデータから得られる。例えば、ある在庫商品の手持ちの数量は、その在庫商品の購入イベントと販売イベントとの不均衡として計算することができる。これと比較して、現在のエンタープライズリソースプランニング（ＥＲＰ）システムの大半では、これは逆であり、すなわち、経理の人為的結果から経済データが得られる。これは、ある意味では、原因の前に結果を置くことになり、モデルをより複雑にする。
【００３２】
加えて、ＲＥＡは、経済的観点からモデルの整合性を保証する規則（公理）を含んでいる。その結果、（１）ＲＥＡモデルは、簡潔で、容易に理解することができ、（２）異なるビジネスドメインにわたって同じモデルが使用され、（３）経理の人為的結果は、同じデータから導き出されるので、常に一貫性があり（例えば、販売のイベントを記述する同一のデータが、倉庫管理、給与の支払い、流通、財務、および他のモジュールで使用される）、（４）ＲＥＡモデルは、経理の人為的結果に基づく報告に比べて完全な報告を提供する。ビジネスオブジェクトは、図３に示し、下記で説明する一般的なタイプのパターンを使用して、常に互いに関連付けられる。
【００３３】
「経済リソース」は、取引の対象を表す。経済リソースは、「経済エージェント」の支配下にある、価値のある何らかのものである。経済リソースの例は、製品、金銭、固定資産、原材料、および従業員の技能である。リソースの他の多くの例も可能である。経済リソースは、管理によってコントロールしようとする価値を表す。「経済イベント」は、経済リソースの所有権の変化を表す。商品の販売などの一部の経済イベントは、瞬時に発生する。しかし、賃貸、サービス、および雇用など、経済イベントの中にはある期間にわたって発生するものがある。経済イベントの例には、これらに限定しないが、発送（配送）、支払い、商品の返品、雇用期間の使用状況などが含まれる。
【００３４】
「経済エージェント」は、他の経済エージェント（あるいは単に「エージェント」）と経済リソース（あるいは単に「リソース」）の交換をすることができる経済単位、あるいは法的実体を表す。経済エージェントの例には、顧客、売り手、および従業員が含まれる。エージェントについては、図４を参照してさらに詳細に説明する。
【００３５】
「双対」(duality)は、経済イベント間の関係である。ＲＥＡでは、リソースの流入を表すすべての経済イベントは、最終的には、リソースの流出を表す経済イベントに関連しなければならず、その逆も同様である。
【００３６】
次いで図４を参照すると、主要なオブジェクトタイプと関連付けタイプを有するセマンティックＲＥＡモデル４００を概略的に表すブロック図が示される。図４の説明は、ＲＥＡのモデル化に共通の用語をさらに理解するのに役立つ。ただし、本発明は、図４に示す特定のＲＥＡモデル化の要素を有するシステムに限定されない。
【００３７】
図４に示し、図３を参照して述べたように、典型的なＲＥＡモデルは、リソース、エージェント、およびイベントを含む。ＵＭＬの用語を使用して上記の定義をさらに詳しく述べると、「エージェント」は、イベントに関係する者と定義することができる。「エージェント」は、より大きな「クラス」あるいは「オブジェクトクラス」のステレオタイプあるいはカテゴリゼーションと定義することもできる。「オブジェクト」は、クラスの「インスタンス」である。例えば、従業員を表すオブジェクトのクラスの場合、エンジニアは、従業員クラスの１つのエージェントとすることができる。従業員クラスのエンジニアエージェントにある特定のエンジニアを表すオブジェクトは、従業員クラスの「インスタンス」になる。一般に、ＲＥＡモデルは、オブジェクトはモデル化される対象の人、ビジネス、出来事などを表すという概念を支援する。
【００３８】
図４には、外部エージェント４０５と内部エージェント４１０の２種類のエージェントを示す。一般的なシナリオでは、１つのイベントに対して２つのエージェントが識別されなければならない。イベントで何か（「リソース」）を手放すエージェントが、外部エージェントであり、何かを受け取るエージェントが内部エージェントになる。外部エージェントのイベントへの関与は、外部関与(external participation)と称され、一方、内部エージェントのイベントへの関与は、内部関与(internal participation)と称される。
【００３９】
一例として、組織のＲＥＡモデルでは、外部エージェントは、顧客や売り手など、モデル化される組織の外側にあることが多い。内部エージェントは、多くの場合、組織の従業員である。内部エージェントと外部エージェントのどちらが外部エージェントになり、どちらが内部エージェントになるかは、そのイベントでリソースを手放すのがどちらであるかによって決まる。さらなる例として、業務処理が、モデル化される組織内の２つのビジネス単位間でのリソースの移動である場合、内部エージェントは、そのリソースを手放す側であり、外部エージェントは、リソースを受け取る側になる。本発明のコンテキストでは、外部エージェントと内部エージェントを使用してアプリケーションのロールを解釈し、一意の外部エージェントまたは内部エージェントそれぞれが、新しいアプリケーションロールに変換される。
【００４０】
ＲＥＡモデルは、異なる種類の関係という概念を支援する。第１のタイプの関係が、異なるタイプのオブジェクトを関係付けて新しいオブジェクトを形成する。このタイプの関係を「関連付け」と称する。図４では、関連付けを、オブジェクト同士を結ぶ先端が矢印の線で表す。関連付けの一例を参照符号４１２で表して図示する。
【００４１】
「コントロール関係」は、一方の側のエージェントと、もう一方の側の経済イベントあるいは他のタイプのオブジェクト間の関連付けである。例えば、図４では、内部エージェント４１０と委託開始４１２間に参照符号４２０で「コントロールの関連付け」タイプが表される。「コントロールの関連付け」の別の例は、外部エージェント４０５と委託開始４１２の間である。この例は、内部エージェント４１０が、委託開始４１２と、それに対応する経済リソース４４０の確保の責任を負う（コントロールする）ことを表す。本発明のコンテキストでは、「コントロールの関連付け」のタイプは、エージェントに関連する「所有権」と解釈される。エージェントが、「コントロール」タイプの関連付けの一端にある場合、本発明の実施形態では、そのエージェントに、もう一端にあるオブジェクトクラスに対する権利が与えられる。図４では、エージェントがコントロールタイプの関連付けを持つことが可能なオブジェクトのタイプには、契約／協定４２５、委託４３０、イベント４３５、およびリソース４４０が含まれる。コントロールタイプの関連付けは、他のタイプのオブジェクトとの間にも有することができる。
【００４２】
保護管理(custody)は、別の関連付けタイプである。本願のコンテキストでは、この関連付けタイプは、「責任」と解釈される。リソースと（内部または外部）エージェント間の関連付けが「保護管理」のタイプである場合、本発明の実施形態では、そのエージェントに、そのリソースに対するいくらかのデフォルトの権限が与えられる。保護管理のタイプの関連付けの一例を図４のリソース４４０と内部エージェント４１０の間に参照符号４１５で表す。図４では、エージェントが保護管理を持つことが可能なオブジェクトのタイプには、契約／協定４２５、委託４３０、およびイベント４３５が含まれる。保護管理タイプの関連付けは、他のタイプのオブジェクトとの間にも有することができる。
【００４３】
（ＲＥＡモデル化におけるセキュリティ）
本発明の実施形態によれば、エージェントとそれに対応するセキュラブルクラスの間の関連付けに関連付けのクラスが追加される。この関連付けクラスは、それ自体が１つまたは複数の新しいオブジェクトである。各セキュラブルクラスは、そのクラスのインスタンスに行うことができる操作のセットを有する。例えば、それらの操作は、「読み取り」、「更新」、「削除」、「転送」、「印刷」、あるいは、当該のクラスに適切な他の任意数の操作とすることができる。
【００４４】
特定の関係、アプリケーション、またはシステムを支配するセキュリティは、しばしば、「セキュリティポリシー」と称される。セキュリティポリシーは、すべてのロールとセキュラブルオブジェクト、およびそれらの関係を記述するモデルを定義する。セキュリティポリシーは、さらに、各セキュラブルオブジェクトに行うことができるすべての操作を定義する。この情報は、非汎用的なオブジェクトモデルのモデルの静的な部分を構成する。ユーザ、権限、および権限の付与を決定する他の要素などの他のコンポーネントは、動的であり、設定することができる。典型的なアプリケーションのセキュリティコンポーネントの残りの部分は、ポリシーを管理し、施行するツールとインフラストラクチャからなる。
【００４５】
ＲＥＡのセキュリティストラテジは、セキュリティポリシーの静的な部分の生成を可能にする。ポリシーテンプレートに表現されるデフォルトの設定などの何らかの追加的なポリシー機能により、セキュリティポリシーのデフォルトの動的な設定も生成することができる。セキュリティポリシーのそうした静的な部分と動的な部分を生成すると、典型的なアプリケーションでは、後は、アプリケーションが配置された後にセキュリティポリシーを管理するためのいくつかのツールをシステム管理者に提供するだけでよい。
【００４６】
本発明の方法および装置の概念を具体的に説明するために、単純な受注アプリケーションのＲＥＡモデルの一部を図示し、説明する。初めにセキュリティのロール面を考えたい。ＲＢＡＣ（Ｒｏｌｅ  Ｂａｓｅｄ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）は、ビジネスアプリケーションで一般に使用される技術／ストラテジである。そのようなモデルでは、ユーザは、ロールを有し、ロールは権限を有する。ロールは、組織における職務権限(job function)に対応する。概念的に、また実際的に、職務権限に関連しない他のグループ化のメカニズムを使用するよりも、ある者の職務権限が分かっているときにその者のセキュリティ権限を管理する方が容易である。
【００４７】
本発明の態様によれば、ＲＥＡモデルでは、ＲＥＡのセキュリティストラテジにおける最初のステップは、以下を実装することである。＜＜エージェント＞＞の名でステレオタイプ化されたすべての一意のクラスに、新しいセキュリティロールが作成される。このロールには、モデル中でそのロールの代表的なエージェントクラスとの関係をもって表されるオブジェクトに対する操作を行う権限を与えることができる。この一例を図５−１および５−２に図示する。
【００４８】
図５−１に示すのは、エージェントのステレオタイプでマークされた「ＳａｌｅｓＰｅｒｓｏｎ」を表すオブジェクト５０５である。また、「ＳａｌｅｓＯｒｄｅｒＨｅａｄｅｒ」タイプの委託を表す第２のオブジェクト５１０も示される。参照符号５１５で示すように、ＳａｌｅｓＰｅｒｓｏｎのエージェントとＳａｌｅｓＯｒｄｅｒＨｅａｄｅｒの委託の間には、内部関与タイプの関連付けが存在する。
【００４９】
この例では、＜＜エージェント＞＞のステレオタイプでマークされた「ＳａｌｅｓＰｅｒｓｏｎ」が、セキュリティロールになる。このモデル中のすべての他の一意のエージェントも、ＲＢＡＣの実装で使用されるセキュリティロールになる。そして、これらの各ロールを分析して、それらのロールがモデル中で他のクラスとの間に有する関係と、それらのクラスに対して有する関係の種類を確定する。
【００５０】
図５−２に示すのは、図５−１に示す図と同じ図であるが、本発明による関連付けクラス５２０を含んでいる。関連付けクラス５２０は、セキュリティポリシーを実装するために使用されるオブジェクトである。「ＳｅｃｕｒｉｔｙＰｏｌｉｃｙＡｓｓｏｃｉａｔｉｏｎ」という名前のオブジェクト５２０は、委託（ＳａｌｅｓＯｒｄｅｒＨｅａｄｅｒ）５１０とエージェント（ＳａｌｅｓＰｅｒｓｏｎ）５０５間の関連付け５１５の関連付けクラスである。関連付けクラス５２０は、エージェント５０５が委託５１０に対して行うことができる操作を表す情報をプロパティあるいはデータフィールドとして含んでおり、したがって、ＲＥＡモデルにセキュリティを提供する。この操作のリストは、無論、委託のタイプに応じて異なってよい。一般に、操作のセットには、「作成」、「読み取り」、「更新」、「削除」（ＣＲＵＤ）などの操作が含まれる。
【００５１】
販売注文が作成されるとき、ＳｅｃｕｒｉｔｙＰｏｌｉｃｙＡｓｓｏｃｉａｔｉｏｎクラスは、エージェントにデフォルトで与えられる操作を指定するテンプレートポリシーを含むことができる。これは、内部関与の関連付けのタイプのコントロールなので、当該の販売員（オブジェクト５０５で表される）には、完全なアクセス権（ＣＲＵ）を与えることができるが、「削除」は除外される可能性がある。ＳａｌｅｓＯｒｄｅｒオブジェクト５１０を「削除」する権利は、別のエージェントに確保された操作である可能性がある。いずれにせよ、エージェント５０５が委託５１０に行うことができる操作を定義する関連付けのクラスを追加するという形の本発明の改良により、ＲＥＡモデルを使用して、既存のＲＥＡセマンティックに基づいて自動的なセキュリティ設定を得ることができる。
【００５２】
図６−１は、ＳａｌｅｓＯｒｄｅｒＨｅａｄｅｒクラスのオブジェクトとの関係を有する別のエージェントを示す図である。図６−１には、エージェントのステレオタイプでマークされた「顧客」を表すオブジェクト６０５が示される。参照符号６１５で示すように、顧客のエージェント６０５とＳａｌｅｓＯｒｄｅｒＨｅａｄｅｒの委託５１０の間には外部関与タイプの関連付が存在する。この例では、顧客が、コントロールタイプを有する外部関与の関連付けを有するエージェントである。「顧客」のエージェントクラスは、このＲＥＡモデルでは別のロールのインスタンスである。図５−１および５−２に提供した例と同様に、２つのオブジェクト（あるいはオブジェクトクラス）５１０と６０５の間の関連付け６１５に別の関連付けクラスのオブジェクトを作成することにより、ＲＥＡモデルにセキュリティが提供される。
【００５３】
次いで図６−２を参照すると、オブジェクト６０５と５１０の間の関連付け６１５の関連付けクラス６２０を示す。この場合も、同じストラテジを使用してＲＥＡモデルにセキュリティを提供し、セキュリティは、「ＳｅｃｕｒｉｔｙＰｏｌｉｃｙＡｓｓｏｃｉａｔｉｏｎ」とマークされた関連付けクラスのオブジェクトによって定義あるいはコントロールされるが、外部関与とマークされた関連付けを有する顧客エージェントのデフォルトの権利にわずかな違いがある。ＲＥＡでは、外部側のエージェントは、その関係における権限がより少ない側である。実際には、ビジネス環境では、普通は顧客がすべての権限を有し、そのため、「お客様は常に正しい（ｔｈｅ  ｃｕｓｔｏｍｅｒ  ｉｓ  ａｌｗａｙｓ  ｒｉｇｈｔ）」というよく使われる表現がある。言うまでもなく、このタイプの権限は、顧客エージェントの「権限がより少ない」と言うときに指すものではない。そうではなく、要点は、販売員が販売注文を作成し、情報を入力し、その注文が何者かにより顧客に確実に発送されるようにするということである。この過程で、販売員は、販売注文を過程で扱うための大幅な権限を受け取る。この事例における顧客は、注文の状況を確認する目的でＳａｌｅｓＯｒｄｅｒＨｅａｄｅｒを読む許可だけを必要とする。このような一般化がなされた場合、外部関与を有するエージェントは常に、内部で関与するエージェントと対照的に、より少ない特権を有するエージェントになると結論付けることができる。
【００５４】
次いで、モデルのより多くの部分が表された図７の図を検討されたい。このより大きなモデルの小さな例では、イベントと製品のオブジェクトが関わる（例えばオブジェクト７０５、７１０、７１５参照）ことに注目されたい。また、エージェントのステレオタイプでマークされた「銀行」を表すオブジェクト７２５と、「ＢａｎｋＡｃｃｏｕｎｔ（銀行口座）」のタイプのリソースを表すオブジェクト７３０との間に「保護管理」の関連付けタイプ７２０が示される。
【００５５】
また図７には、エージェントのステレオタイプでマークされた「ＷａｒｅＨｏｕｓｅＣｌｅｒｋ（倉庫係）」を表すオブジェクト７３５が追加されている。ＷａｒｅＨｏｕｓｅＣｌｅｒｋオブジェクト７３５は、「ＤｅｌｉｖｅｒｙＤｅｔａｉｌ」イベントを表すオブジェクト７０５との関連付け７３６を有する。この場合、ＷａｒｅｈｏｕｓｅＣｌｅｒｋ７３５は、イベント７０５が開始されてから停止するまでの注文遂行プロセスで機能する。この例では商品（製品リソース７１５）を受け取る顧客（顧客エージェント６０５）が関与するので、その顧客が自分の注文に有する権利は、支払いが行われた後に「重要度が高まる」。この「推移的」な効果は、イベントのためにあり、あるイベントが開始される前にはエージェントがオブジェクトに全く権利を持たず、そのオブジェクトが特定の状態にある間は制限されたアクセス権を持ち、そして最終的にイベントが経過してしまうと全く権利を持たない状態に戻るというオブジェクトとエージェントを構想することができる。このタイプの動的な権限の付与が可能になるのは、ＲＥＡモデルの豊富なセマンティックに加えて、本発明により追加されるセキュリティポリシーの関連付けクラス（図５−２および６−２に示す）のためである。
【００５６】
エージェントは他のエージェントの代わりに動作することができることに留意されたい。この関係は、しばしば成りすまし(impersonation)と呼ばれ、成りすまし側に、成りすまされるエージェントの権利を与える。例えば、大使が外国の国家元首に成りすまし、大使（成りすまし側）に関連するオブジェクトへの国家元首のアクセス権を大使に与える。
【００５７】
「保護管理」の関連付けクラスは「責任」を表すので、関連付けのクラスに上述の本発明の態様を適用し、関連付けクラスのオブジェクトに操作の権限を追加することにより、同様のセキュリティストラテジを作り出すことができる。
【００５８】
これらの例から、このＲＥＡセキュリティストラテジを使用して非常に重要なメタデータをモデル化すると、管理時と実行時の両方に使用することができるセキュリティサブシステムを得られることが理解できよう。ＲＥＡイベントのセキュリティを管理し、施行することの動的な面と同様に、一部の事例では、意思決定の一部を、別個のモデルとビジネスロジックのセットに抽象化することが利益となる。これは、ポリシーのオブジェクトあるいはサブシステムを使用して実現することができる。
【００５９】
一部の実施形態では、セキュリティポリシーは、ＲＥＡモデルに平行した別個のモデルであり、一方、ＲＥＡモデルは、動作主（ロール）や対象物（セキュラブルオブジェクトと、それらのオブジェクトに対する可能な操作）のような開発者が設計時に知ることができるすべての情報を含んでいる。そのようなシステムの一例を図８−１に示し、ここでは、本発明による関連付けクラスを有するセキュリティモデル８１０が、ＲＥＡモデル８０５と切り離されている。セキュリティモデル８１０によって実装されるセキュリティポリシーは、開発時または開発後にしか知ることができない、あるいは変更することができない情報を含んでいる。「ユーザ」は、本発明のセキュリティポリシーの関連付けクラスを含む別個のセキュリティポリシーモデル８１０の開発時に加えることができる情報の例である。また、図には、意思決定の一部を別個のモデルとビジネスロジックのセットに抽象化するオプションのセキュリティポリシーロジックモデル８１５も示す。例えば、セキュリティモデル８１０が、特定のユーザに特定リソースについての権利を付与する関連付けクラスを含む場合、それらの権利の性質が動的（すなわち、日付または時刻、イベントのステータスなどに依存する）であれば、セキュリティポリシーロジックモジュール８１５を使用して、それらの権利を定義することができる。モデルあるいはモジュールの言及は、適切にプログラミングされた処理コンポーネントおよび／またはシステム、ならびに図１および２に示すような関連付けられたメモリを含むものと意図される。
【００６０】
代替実施形態では、ＲＥＡモデル自体に「ユーザ」を追加することができるが、これは好ましくない場合がある。しかし、そのような実施形態は本発明の範囲内にあり、図８−２に図示される。図８−２では、本発明による関連付けクラスを有するセキュリティモデル８１０がＲＥＡモデル８０５と一体化される。したがって、セキュリティポリシーを定義する関連付けクラスのオブジェクトが、ＲＥＡモデル自体に追加される。
【００６１】
この場合も、セキュリティポリシーロジックモジュール８１５により、時間のカテゴリに入る、セキュリティポリシーによって提供される答え（例えばその権限がいつ適用されるかなど）は、モデル８０５／８１０から別個に生成されることができる。特定の権限のセットを定時の業務時間にアクティブにし、別の許可のセットを業務時間後または週末にアクティブにする要件が存在する場合は、セキュリティポリシーの関連付けクラスを有するセキュリティポリシーモデル８１０と併せて、別個のポリシーロジックシステムあるいはモジュール８１５を使用することができ、この場合、アクティブなポリシーの決定は、異なる根拠のタイプに基づいて行われる。根拠のタイプの例には、時間、場所などがある。
【００６２】
展開の柔軟性について別の重要な領域は、様々な形態のプライバシーの制定(legislation)の扱い方である。多くの会社では、しばしば、アプリケーションがどこに配置されたかに応じて異なるプライバシーポリシーを使用するように各自のアプリケーションを採用する際に困惑する。ＲＥＡのセキュリティストラテジと外部ポリシーの概念が、これを助ける。
【００６３】
図９は、リソースイベントエージェント（ＲＥＡ）モデルに基づくセキュリティを提供する方法を説明するブロック図９００である。図９に示す方法は、上述した方法論を要約するものであるが、本発明をこの特定の方法に限定するものではない。ブロック９０５に示すように、この方法は、ＲＥＡモデル中の第１のオブジェクトと第２のオブジェクト間の関連付けを識別することを含む。次いで、ブロック９１０に示すように、第１のオブジェクトと第２のオブジェクトの間の関連付けに関連付けのクラスが作成される。例えばセキュリティポリシーの関連付けクラスと呼ばれるこの関連付けのクラスは、第１のオブジェクトと第２のオブジェクトの間にセキュリティを定義する。
【００６４】
第１のオブジェクトと第２のオブジェクトの間に定義される関連付けのクラスは、プロパティを有するオブジェクトである。関連付けクラスオブジェクトのプロパティは、第１のオブジェクトと第２のオブジェクトの間のセキュリティを定義する。関連付けのクラスを作成するステップはさらに、プロパティを有する１つまたは複数の関連付けクラスのオブジェクトを作成するステップを備えることができ、その１つまたは複数の関連付けクラスのオブジェクトのプロパティは、第１のオブジェクトがメンバである第１のオブジェクトクラスと、第２のオブジェクトがメンバである第２のオブジェクトクラスの間のセキュリティを定義する。第２のオブジェクトは、契約または協定タイプのオブジェクト、委託タイプのオブジェクト、イベントタイプのオブジェクト、あるいはリソースタイプのオブジェクトなど、セキュラブルオブジェクトである。第１のオブジェクトは、特定のエージェントタイプである。ユーザのロールは、第１のオブジェクトの特定のエージェントタイプによって定義される。
【００６５】
第１のオブジェクトと第２のオブジェクトの間に作成される関連付けクラスは、ＲＥＡモデルとは別個に、またはＲＥＡモデルの一部として、セキュリティモデル中に作成することができる。第１のオブジェクトと第２のオブジェクトの間に定義されたセキュリティは、第２のオブジェクトに対する第１のオブジェクトの許可と権利を定義することを含む。これらの許可と権利は、セキュリティモデルの外側で、セキュリティポリシーロジックモジュール中に動的に決定することができる。これは、例えば日付、時刻、イベントのステータスなどに依存する、推移的な性質の権限と権利に特に有用である。
【００６６】
本発明について特定の実施形態を参照して説明したが、当業者は、本発明の主旨および範囲から逸脱せずに、形態と詳細に変更を加えてよいことを認識されよう。
【図面の簡単な説明】
【００６７】
【図１】本発明を実施することが可能な例示的環境のブロック図である。
【図２】本発明を実施することが可能な一般的なモバイルコンピューティング環境のブロック図である。
【図３】基本的なＲＥＡの交換パターンを示すブロック図である。
【図４】主要なオブジェクトタイプと関連付けタイプを有するセマンティックＲＥＡモデルを概略的に示すブロック図である。
【図５−１】従来のＲＥＡモデルによる２つのオブジェクトクラス間の内部関与の関連付けを表すブロック図である。
【図５−２】モデルにセキュリティ面を提供するために本発明により関連付けのクラスが追加された、図５−１に示す２つのオブジェクトクラス間の内部関与の関連付けを示すブロック図である。
【図６−１】従来のＲＥＡモデルによる２つのオブジェクトクラス間の外部関与の関連付けを表すブロック図である。
【図６−２】モデルにセキュリティ面を提供するために本発明により関連付けのクラスが追加された、図６−１に示す２つのオブジェクトクラス間の外部関与の関連付けを示すブロック図である。
【図７】本発明のさらなる態様を示すブロック図である。
【図８−１】関連付けのクラスを有するセキュリティモデルがＲＥＡモデルのセマンティック情報を使用するが、ＲＥＡモデル自体の外側に存在する、ＲＥＡを利用したセキュリティシステムを示すブロック図である。
【図８−２】関連付けクラスを有するセキュリティモデルがＲＥＡモデルに組み込まれた、ＲＥＡを利用したセキュリティシステムを示すブロック図である。
【図９】本発明の方法を説明するブロック図である。
【図１】
2007531153.tif 000002
【図２】
2007531153.tif 000003
【図３】
2007531153.tif 000004
【図４】
2007531153.tif 000005
【図５−１】
2007531153.tif 000006
【図５−２】
2007531153.tif 000007
【図６−１】
2007531153.tif 000008
【図６−２】
2007531153.tif 000009
【図７】
2007531153.tif 000010
【図８−１】
2007531153.tif 000011
【図８−２】
2007531153.tif 000012
【図９】
2007531153.tif 000013
【手続補正書】
【提出日】平成19年7月23日(2007.7.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
リソース・イベント・エージェント（ＲＥＡ）モデルベースのセキュリティを提供する方法であって、
ＲＥＡモデル内において第１のオブジェクトと第２のオブジェクトの間の所有権を指示するＲＥＡ定義アソシエーションを識別するステップと、
前記第１のオブジェクトと前記第２のオブジェクトの間の前記ＲＥＡ定義アソシエーションに対してアソシエーション・クラス・オブジェクトを作成するステップであって、前記アソシエーション・クラス・オブジェクトは、前記第１のオブジェクトと前記第２のオブジェクトの間のセキュリティを定義するプロパティを有するステップ
を含むことを特徴とする方法。
【請求項２】
前記アソシエーション・クラス・オブジェクトを作成するステップは、プロパティを有する１又は複数のアソシエーション・クラス・オブジェクトを作成するステップを更に含み、前記１又は複数のアソシエーション・クラス・オブジェクトの前記プロパティは、前記第１のオブジェクトがメンバである第１のオブジェクト・クラスと、前記第２のオブジェクトがメンバである第２のオブジェクト・クラスの間のセキュリティを定義することを特徴とする請求項１記載の方法。
【請求項３】
前記第２のオブジェクトは、セキュラブル・オブジェクトであることを特徴とする請求項１記載の方法。
【請求項４】
前記第１のオブジェクトは、特定のエージェントタイプであり、ユーザの役割が、前記第１のオブジェクトの前記特定のエージェントタイプによって定義されることを特徴とする請求項３記載の方法。
【請求項５】
前記第２のオブジェクトは、契約又は協定タイプ・オブジェクトであることを特徴とする請求項４記載の方法。
【請求項６】
前記第２のオブジェクトは、委託タイプ・オブジェクトであることを特徴とする請求項４記載の方法。
【請求項７】
前記第２のオブジェクトは、イベントタイプ・オブジェクトであることを特徴とする請求項４記載の方法。
【請求項８】
前記第２のオブジェクトは、リソースタイプ・オブジェクトであることを特徴とする請求項４記載の方法。
【請求項９】
前記第２のオブジェクトは、エージェントタイプ・オブジェクトであることを特徴とする請求項４記載の方法。
【請求項１０】
第１のオブジェクトと第２のオブジェクトの間の所有権を指示するＲＥＡ定義アソシエーションを識別するステップは、前記第１のオブジェクトと前記第２のオブジェクトの間のＲＥＡ定義コントロールタイプ・アソシエーションを識別するステップを更に含むことを特徴とする請求項４記載の方法。
【請求項１１】
第１のオブジェクトと第２のオブジェクトの間の所有権を指示するＲＥＡ定義アソシエーションを識別するステップは、前記第１のオブジェクトと前記第２のオブジェクトの間のＲＥＡ定義保護管理タイプ・アソシエーションを識別するステップを更に含むことを特徴とする請求項４記載の方法。
【請求項１２】
前記第１のオブジェクトと前記第２のオブジェクトの間の前記ＲＥＡ定義アソシエーションに対して前記アソシエーション・クラスを作成するステップは、セキュリティモデル内に前記アソシエーション・クラス・オブジェクトを作成するステップを更に含むことを特徴とする請求項４記載の方法。
【請求項１３】
前記セキュリティモデル内に前記アソシエーション・クラス・オブジェクトを作成するステップは、前記ＲＥＡモデルと別個の前記セキュリティモデル内に前記アソシエーション・クラス・オブジェクトを作成するステップを更に含むことを特徴とする請求項１２記載の方法。
【請求項１４】
前記セキュリティモデル内に前記アソシエーション・クラス・オブジェクトを作成するステップは、前記ＲＥＡモデルの一部である前記セキュリティモデル内に前記アソシエーション・クラス・オブジェクトを作成するステップを更に含むことを特徴とする請求項１２記載の方法。
【請求項１５】
前記第１のオブジェクトと前記第２のオブジェクトの間のセキュリティを定義するステップは、前記第２のオブジェクトに対する前記第１のオブジェクトの権限および権利を定義するステップを更に含むことを特徴とする請求項１２記載の方法。
【請求項１６】
前記第２のオブジェクトに対する前記第１のオブジェクトの権限および権利を定義するステップは、前記セキュリティモデルの外部にあるセキュリティポリシー・ロジックモジュール内で前記権限および権利を動的に決定するステップを更に含むことを特徴とする請求項１５記載の方法。
【請求項１７】
請求項１から１６のいずれか１項に記載の方法を行うコンピュータ実行可能命令を記録することを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項１８】
請求項１から１６のいずれか１項に記載の方法を実施するように構成されることを特徴とするシステム。
【請求項１９】
セキュリティを提供するシステムであって、
第１のオブジェクト、第２のオブジェクト、および前記第１のオブジェクトと前記第２のオブジェクト間の所有権を指示するＲＥＡ定義アソシエーションを実施するように構成されたリソース・イベント・エージェント（ＲＥＡ）モデルと、
前記アソシエーション・クラス・オブジェクトのプロパティが前記第１のオブジェクトと前記第２のオブジェクトの間のセキュリティを定義するように、前記ＲＥＡモデル内の前記第１のオブジェクトと前記第２のオブジェクトの間の前記ＲＥＡ定義アソシエーションに対してアソシエーション・クラス・オブジェクトを実施するように構成されたセキュリティモデル
を備えることを特徴とするシステム。
【請求項２０】
前記アソシエーション・クラス・オブジェクトは、プロパティを有する１又は複数のアソシエーション・クラス・オブジェクトを備え、前記１又は複数のアソシエーション・クラス・オブジェクトの前記プロパティは、前記第１のオブジェクトがメンバである第１のオブジェクト・クラスと、前記第２のオブジェクトがメンバである第２のオブジェクト・クラスの間のセキュリティを定義することを特徴とする請求項１９記載のシステム。
【請求項２１】
前記セキュリティモデルは、前記ＲＥＡモデルと別個であることを特徴とする請求項１９記載のシステム。
【請求項２２】
前記セキュリティモデルは、前記ＲＥＡモデルの一部であることを特徴とする請求項１９記載のシステム。
【請求項２３】
前記セキュリティモデルに結合され、前記第２のオブジェクトに対する前記第１のオブジェクトの権限および権利を動的に決定するように構成されたセキュリティポリシーロジックモジュールを更に備えることを特徴とする請求項１９記載のシステム。
【国際調査報告】
2007531153.tif 000014