(57)【要約】【課題】  セキュリティ対象情報を抽出する。  【解決手段】  主として患者データのための医療システム内の１セットの機密データから選択基準及びセキュリティ・ルールに基づいてセキュリティ対象情報にアクセスするためのシステムと方法が示されている。セキュリティ・ルールを最初にを適用して、その後に選択基準を置く時、パーフォーマンスの問題を生じる。解決策は選択ステップを第一に実行し、その後にセキュリティ・ルールを適用することである。その方法はコンピューター又はサーバー・システム内で、例えば、放射線科で患者の検査の日程作成又はこれらの検査の記録管理のために使用しうる。【選択図】   図１
2005174331.tif 000002
【特許請求の範囲】
【請求項１】
１セットの電子的に記憶された機密データからセキュリティ対象情報に選択基準に基づいてアクセスするための方法で、
−第一ステップで１セットのセキュリティ・ルールを定義すること、
−第二ステップで前記選択基準に基づき前記機密データから情報を選択すること、
−第三ステップで前記セキュリティ・ルールに基づいて、前記の選択された情報から前記セキュリティ対象情報にアクセスすること、
のステップから成る方法。
【請求項２】
そのセキュリティ・ルールが、
−その方法のオペレーターとセキュリティ対象情報の間の関係、又は、
−前記オペレーターの属性、
に基づいていることを特徴とする請求項１に基づく方法。
【請求項３】
好ましくはオペレーター、又は、部門ないし前記オペレーターのためのワークステーションのような属性により、セキュリティ・ルールの前記セットの少なくともひとつを無視すること、及び、前記セキュリティ対象情報にアクセスするステップを記録すること、
のステップから成ることを特徴とする請求項１に基づく方法。
【請求項４】
１セットの電子的に記憶された機密データからセキュリティ対象情報に選択基準に基づいてアクセスするためのセキュリティ・システムで、
−１セットのセキュリティ・ルールを定義するための手段、
−前記選択基準に基づき前記機密データから情報を選択する手段、
−前記セキュリティ・ルールに基づいて、前記の選択された情報から前記セキュリティ対象情報にアクセスする手段、
から成るシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は選択基準に基づいて１セットの機密データから「セキュリティ対象情報（ｓｅｃｕｒｅ  ｉｎｆｏｒｍａｔｉｏｎ）」を抽出するための方法に関する。
【背景技術】
【０００２】
特許文献１はコンピューター・システム内に認可に関連したキャッシング（ｃａｃｈｉｎｇ）のためのシステムと方法を示している。このシステムはダイナミック認可ポリシーを用いるときに生じるパーフォーマンス問題の解決策を示している。
【０００３】
特許文献２はアクセス管理情報を文書管理システムに登録する前にある文書に加える文書管理システムを示している。登録時点でこの追加情報を用いて、アクセス管理情報をセットする。その後、その文書が請求されたときに、このアクセス管理情報を用いてアクセス権を判定する。
【０００４】
医療環境では、患者データのアクセス管理は重要な側面である。さらに、詳細なプライバシー要件が複雑で、地域と顧客により、又、時間と共に変化することがある。それゆえ、医療行為を経済的に実施するために明白なセキュリティ・サブシステムを必要とする。
【特許文献１】米国特許第ＵＳ２００２／０１６６０５２号明細書
【特許文献２】米国特許第ＵＳ２００２／００９５４３２号明細書
【発明の開示】
【０００５】
上記側面は請求項１に示す特定機能を有する方法により又請求項に示す特定機能を有するシステムにより実現される。本発明の好ましい実施例の特定機能は従属する請求項に示されている。
【０００６】
アクセスの方法は、機密データのアクセス管理のための方法と同等であると見られる。さらに、セキュリティ・ルールは認可ルールとも呼ばれる。本発明に基づくと、選択基準に基づいて１セットの患者を選択しうる。しかしながら、このセットの患者はオペレーターがアクセスできない部分グループを含むことがある。そして、この部分グループはセキュリティないし認可のルールによりそのセットから除外しうる。
【０００７】
好ましくはこれらの作業は全て１以上のサーバー及び（又は）１以上のクライアントを含むコンピューター・システムで行なわれる。さらに、本発明に基づく方法はウエッブ・アクセスによっても行える。ユーザーはワークステーションで作業をし、ＬＡＮ又はＷＡＮネットワークを介して又はインターネットを介して１以上のデータベース内の患者データにアクセスしうる。
【０００８】
選択基準、セキュリティ対象情報、機密データ及び（又は）セキュリティ・ルールは例えば情報を電子的に記憶させるために、コンピューターのメモリーＲＡＭ又はＲＯＭ、ハードディスク、コンパクト・ディスク又は他の適当な媒体に記憶させられる。本発明に基づく方法の各ステップは１台のコンピューターで全て実行しうる、又は、一部のステップはサーバーにより実行され、かつ、他のステップがサーバーから離れたクライアントにより実行される。
【０００９】
選択基準の例は「今日、この科を訪れた全ての患者」であり、他の例は「医師Ｘが扱った全ての患者」である。
【００１０】
本発明に基づく方法の適用後又は適用により、セキュリティ対象情報が通常ユーザー用のコンピューター・スクリーンに表示される。代わりに、セキュリティ対象情報をプリンターに送り、又はＥメールにより、又は、ウエッブ・リンクを介して患者を担当する一般開業医に送る。このセキュリティ対象情報は特定の病院の科の全ての患者に適当なテンプレート（ｔｅｍｐｌａｔｅ）内に示されている。
【００１１】
機密データには患者に関連したデータが含まれている。これらのデータの一部は高度に機密であり、１人だけに又は限定したグループの人のみに開示しうる。時として、患者自身が除外される場合がある。例えば、１００％未満の確率を持つ致死性の診断の場合である。
【００１２】
セキュリティ・ルールはどの作業をどのデータについて、どの人が行えるかを定義する原則的ルールである。作業又は「アクセス」には、作成、選択、抽出、抹消、修正、更新及び閲覧が含まれる。このリストは網羅してはいない。作業が病院内のアプリケーション・プログラマー（ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｇｒａｍｍｅｒ）又はインフォメーション・テクノロジー・デパートメント（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ  Ｄｅｐａｒｔｍｅｎ）により追加できる。例えば、そのような作業には、印刷、走査、Ｅメール受発信、ウエッブを経由したアクセス、インターネット又はイントラネット、ヒト又は機械が話した報告の聞き取り、話された報告の入力等である。データは、誕生日、性別、名前及び１件の報告のように単一のデータ要素である場合もある。さらに、これらのデータは例えば管理データ、医療データ、介護データ、社会心理学的及び家族のデータのように１セットにまとめられる。各セットが、単一データ要素をまとめたいくつかの部分グループを含むことがある。データに特定タイプのアクセスができる人物は医師、看護師、管理スタッフ等としうる。それぞれの特定ユーザー、例えば、医師又は看護師に対して、その医師が特定の単一データ要素、特定のセット、又は、特定の部分グループにアクセスするかどうかをシステムが定義できる。しかしながら、好ましくは、ユーザーはグループにまとめられる。例えば、「放射線科の医師」又は「婦人科の看護師」であり、又は、特定ユーザーが例えば「放射線科長」のように「参照」を付けられることがある。この方式には特定のユーザー名がそのグループ内に入力されるという利点がある。そして、もし、グループの構成が変化した場合、そのグループ内で名前を変更することで十分で、セキュリティ・システムの一貫性が維持される。「グループ」はユーザーの属性として見ることができ、例えば、特定の医師を放射線科長、心臓科スタッフの一員、及び、集中治療科の看護師と見なすことができる。特定の患者例えば非常に重要な人物、又は、病院又は科の従業員を特定のセキュリティ扱いとする必要がある場合も可能である。それにより、例えば、科長のみ、又は、病院のひとりの医師がその特定患者のデータにアクセスする。
【００１３】
好ましい実施例では、コンピューター・システムがまず選択基準を機密データ例えば通常巨大なデータベースに適用する。そして、この選択が行なわれると、通常、限定されたデータのセットが得られる。選択された情報にセキュリティ・ルールが適用され、ユーザー又は本発明に基づく方法のオペレーターによるアクセスが実際に許されている範囲内に限定される。
【００１４】
患者の生命にとって危機的な状態でルール無視が行なわれることがある。そのような場合、システムのオペレーター又はユーザーは病院のデータベース・システムの全ての又はほぼ全てのデータに、又は、（ほぼ）全てのデータベース・システムに対してさえ、アクセスすることがあり、それを病院全体に、又は、協力病院グループ内の病院に対してさえ配布することがある。しかしながら、そのユーザーがセキュリティ又は認可のルールを無視した場合、この事実を追跡し続けること、及び、その特定の人又はシステムのユーザー又はオペレーターがルールを無視しなければならなかった理由を保存することが重要である。これはこの無視による作業を記録することにより行なわれる。記録は全ての作業又はアクセス・モードについて、又は、「危機的な状態」でのアクセスの選択についても行なわれる。
【００１５】
好ましくは、オペレーターはセキュリティ又は認可のルールを個々のユーザー、ユーザー・グループ、個々の患者、患者グループ、特定作業又はアクセス・モード又はアクセス・モードのセットについて設定し、又、変更する権利を持つ。患者グループの作成はその患者を１グループに入力することにより、又は、その患者がその特定グループに属す理由となる属性に各患者又は一部の患者を配置することによる。
【００１６】
本発明の利点と実施例は以下の説明と図面から明らかになる。
【実施例】
【００１７】
本発明はその好ましい実施例と関連させて以後に説明しているけれども、本発明をその実施例に限定する意図ではないことを了解されたい。本発明に基づくと、認可又はセキュリティのルールは好ましくは特定の個人情報に対する認可された者の関連性（ａｆｆｉｌｉａｔｉｏｎ）に基づいている。この場合、その個人は好ましくは患者である。好ましい実施例では、「関連性」は以下のコンセプト（ｃｏｎｃｅｐｔ）に関連している。
１．システムの個々のユーザー（又はユーザーのグループ）は好ましくはログイン（ｌｏｇｉｎ）名で識別され、かつ、好ましくはパスワードにより認可される。
２．そのユーザーが果す役割、その役割とは：
−オペレーター；
−ドクター、医師・・・；
−看護師；
−管理者；
３．そのユーザーがその役割を果す科、例えば：
−放射線；
−心臓学；
−薬理学。
【００１８】
医療環境では、個人情報は患者に関連している。一方、認可された人は以下であろう：
１．患者に関連又は担当する医師；
２．患者が入院している科で働く看護師という理由で、患者と関連している看護師；
３．患者に関連する医師を訪問するようにアドバイスしたメディカル・ドクター（ｍｅｄｉｃａｌ  ｄｏｃｔｏｒ）。
【００１９】
医療環境では、個人情報を患者情報と呼ぶ。患者情報には以下が含まれる：
１．名前、誕生日、社会保障番号等のような識別情報。
２．性別、身長、体重等のような健康情報。
３．血圧、脈拍等のような医療パラメーター。
４．病理又は外傷に関する情報のような疾患情報。
【００２０】
さらに、患者情報は、以下の分類に分類されよう：
１．誕生日及び名前のような人口統計的データ；
２．報告データ、例えば、医療画像について報告する放射線医が作成したデータ；
３．血圧サンプルの組成のような臨床検査結果；
４．ＣＴスキャンのような画像データ。
【００２１】
情報要素とは独立した情報の最小部分である。独立した情報の例には以下がある：
１．社会保障番号；
２．患者の名前と姓；
３．患者の街路、番地、町名、郡から成る住所；
４．病気のタイプ、例えば、右手小指関節の骨の打撃による破損；
５．口述、例えば、放射線医による口頭報告；
６．予約；
７．医療報告；
８．検査命令；
９．臨床検査結果；
１０．時間的制約、例えば、患者が利用できる時間枠。
【００２２】
一部の要素は時間と関連している。患者の血圧、体温、身長と体重、病歴又は外科的事象、ワクチン投与は例えば１ヶ月単位ないし１秒単位の精度で関連した時刻又は期間を必要とするパラメーターである。
【００２３】
原則として、個人情報の各部分は情報要素と呼ばれ、その認可された者がその情報要素にアクセスする前に、それぞれの特定認可対象者と関連していなければならない。そのような情報要素が機密情報であるだけでなく、他の情報要素との関連性も機密である場合がある。例えば、特定タイプの肺炎を持つ患者が特定の病院の科にいるという情報は機密である場合がある。このタイプの肺炎と患者独自の識別要素との間の関係は前記の情報よりもさらに高度の機密になる。
【００２４】
本発明に基づく認可又はセキュリティのシステムの有効性を高めるために、患者を特定の病院の科又は病院のサービスを基準にしたグループにまとめられる。例えば、ベルギーのアントワープにあるエラスムス病院の婦人科に入院している患者としてである。
【００２５】
さらに、認可された者はその共通の認可に基づいてグループ化される。例えば、婦人科に関連する全ての医師が「婦人科医」のグループにまとめられる。
【００２６】
そこで、婦人科の特定の患者とこの科での特定の医師との関連性は、以下の、より一般的な組合わせから得られる：
１．婦人科
２．医師
それゆえ、認可のルールは好ましくはその関連性に基づく。
【００２７】
本発明に基づくシステムは以下のプロパティ（ｐｒｏｐｅｒｔｙ）を有している。
【００２８】
セキュリティのルールは好ましくはデータベースのレベルの代わりにコンセプトのレベルで特定される。オブジェクト（ｏｂｊｅｃｔ）又は「ビジネス」オブジェクトは例えば医師、移送、サービス請求、報告である。コンセプトのレベルで特定されたルールは「オブジェクト」を用いて、認められることと認められないことを定義する。データベースのレベルでの指定とはユーザーがデータベース内の特定の欄にアクセスし、データベースの他の特定の欄にはアクセスしないことを意味する。もし、データベース又はデータベース・モデルが「報告」のオブジェクトを持つが、その報告が「認可済」（ｖａｌｉｄａｔｅｄ）の属性を持たず、他の属性である場合、システムは特定のユーザーが報告にアクセスし、他の特定ユーザーは報告にアクセスしないことを示すに過ぎない。あるシステムで、「報告」のオブジェクトが「認可済」の属性である場合、そのシステムは特定ユーザーに対して「全ての報告」にアクセスを認め、他の特定ユーザーに対しては「認可済の報告」のみにアクセスを認める。報告に対する他の典型的属性は「作成日」である。さらに、この属性も選択基準として、又は、認可基準として使用しうる。例えば、看護師はその日に作成された報告にのみアクセスできる。放射線科の従業員は１週間より以前の放射線検査報告にアクセスするのを拒否される。属性に基づいて認可又はセキュリティのルールを指定することには利点がある。このことは、表内の全ての報告に対してのみ、患者のデータベース内の特定の欄又は表にユーザーがアクセスを拒否される場合と比較して、柔軟なシステムを提供する。例えば、以下のようなルールをサポート（ｓｕｐｐｏｒｔ）するシステムと比較してみよう：
ルールＡ：「看護師は自身の科の認可済報告のみにアクセスできる」
これを以下のようにしか言えないシステムと比較する：
ルールＢ：「看護師は報告にアクセスしない」
ルールＢのみの機能を持つシステムは、ルールＡを定義する選択肢を持つシステムと比較して、より強い制約があり、機能が低い。属性の”Ｒｅｐｏｒｔ．ｄｅｐａｒｔｍｅｎｔ”（報告の部門）及び”Ｎｕｒｓｅ．ｄｅｐａｒｔｍｅｎｔ”（看護師の部門）又は”ＭＹ＿ＤＥＰＡＲＴＭＥＮＴ”（私の部門）の認識のような、テストをする場合：Ｒｅｐｏｒｔ．ｄｅｐａｒｔｍｅｎｔ  ＝  ＭＹ＿ＤＥＰＡＲＴＭＥＮＴのような属性にルールがアクセスできるという事実により、ルールＡの選択肢が可能になる。
【００２９】
”ＭＹ＿ＤＥＰＡＲＴＭＥＮＴ”の値はシステム内でログインをする人又はユーザー又はオペレーターによる。例えば、コンピューター・システムへのログインの間に、ユーザーはその身分、そのパスワード、ログインする部門を指定しうる。それにより、例えば、”ＭＹ＿ＤＥＰＡＲＴＭＥＮＴ”とその部門内でユーザーが持つ役割を定義しうる。例えば、”ｎｕｅｓｅ”（看護師）、”ｐｈｙｓｉｃｉａｎ”（医師）、”ｈｅａｄ  ｏｆ  ｔｈｅ  ｄｅｐａｒｔｍｅｎｔ”（科長）等の定義をする。
【００３０】
機密データにはオブジェクトについての情報が含まれる。あるオブジェクトは現実のオブジェクト又は人物に対応していて、属性と呼ばれるその状態についての情報が含まれる。
【００３１】
オブジェクトの例として：患者（ａ  ｐａｔｉｅｎｔ）、医師（ａ  ｐｈｙｓｉｃｉａｎ）、病院（ａ  ｈｏｓｐｉｔａｌ）、部門（ａ  ｄｅｐａｒｔｍｅｎｔ）、報告（ａ  ｒｅｐｏｒｔ）、予約（ａｎ  ａｐｐｏｉｎｔｍｅｎｔ）がある。”ｐａｔｉｅｎｔ”のオブジェクトに対する属性は：性別、名前、誕生日であろう。オブジェクト間の関連性が存在する。例えば、”ｐａｔｉｅｎｔ”のオブジェクトは彼の”ｐｈｙｓｉｃｉａｎ”と関連性を持つだろう。
【００３２】
アクセス管理を必要とするオブジェクト間の関連性及びユーザー又はグループ又は機能のサブジェクト（ｓｕｂｊｅｃｔｓ）は明確に指定しうる。セキュリティのルールはオブジェクトの属性及びそれが他のオブジェクトと持つ関係を用いて追加できる。例：”ｒｅｐｏｒｔ”のオブジェクトは「認可済」（”ｖａｌｉｄａｔｅｄ”）の属性を持ち、それが真（”ｔｒｕｅ”）にも、又、偽（”ｆａｌｓｅ”）にもなる。
Ｒｅｐｏｒｔ．ｖａｌｉｄａｔｅｄ  ：＝  ＴＲＵＥ
Ｒｅｐｏｒｔ．ｖａｌｉｄａｔｅｄ  ：＝ＦＡＬＳＥ
特定のルールがこのオブジェクトのこの属性を以下のようにチェックする：
Ｒｅｐｏｒｔ．ｖａｌｉｄａｔｅｄ  ＝  ＴＲＵＥ
セキュリティのルールは瞬間ごとに指定しうる。例えば、全ての報告に適用する制約の代わりに行なう単一報告に対する個別の保護である。
【００３３】
セキュリティのルールは生命にとって危機的な状態で無視されることがある。この場合、全ての作業が好ましく記録され、監査での追跡が行える。以下の項目が記録される：
１．ユーザーの識別、例えば、”ｕｓｅｒ＿ｉｄ”；
２．アクセスされたオブジェクト；
３．そのオブジェクトに行なわれた行為（以下のリスト参照）；
４．その行為が行なわれた時（例えば、日付、時・分・秒）；
セキュリティは１セットの「アクセス管理ルール」として指定しうる。これは「セキュリティー・ルール」又は「ルール」とも言う。ルールは一定の論理的行為を一定のオブジェクトについて実行できるかどうかを指定する。
【００３４】
システムは以下のような１セットの事前指定した行為を提供しうる：
１．全ての行為、
２．作成、
３．選択、
４．抹消、
５．修正
６．閲覧
アプリケーション・デベロッパー（ａｐｐｌｉｃａｔｉｏｎ  ｄｅｖｅｌｏｐｅｒ）は必要に応じて追加の行為を定義できる。
【００３５】
オブジェクト問い合せ言語（”ＯＱＬ”）を用いて、オブジェクトのどの部分集合に対してルールがアクセス管理を行なうかを指定する。ＯＱＬは問い合せ言語で、高レベルのコンセプト用オブジェクト・モデルを扱える表現で問い合せを行える。これらの問い合せは以下のような事前に定義した変数を用いることにより非常に特殊な状況をターゲットにできる：
１．ＭＹ＿ＡＦＦＩＬＩＡＴＩＯＮ（私の関連性）
２．ＭＹ＿ＤＥＰＡＲＴＭＥＮＴ（私の部門）
３．ＭＥ＿ＡＳ＿ＤＯＣＴＯＲ（医師としての私）
４．ＭＹ＿ＷＯＲＫＳＴＡＴＩＯＮ（私のワークステーション）
別の事前定義された変数も定義できる。ルールはユーザー、現在のユーザーが果す役割、そのユーザーの部門、及び、その行為が求められているワークステーションにより無視できる。さらに、ルールはそれらの優先度を定義することに対して優先権を持つ。
【００３６】
好ましい実施例に基づくと、ルールはデータベースに記憶され、管理者により変更できる。例えば、Ｑｍａｎａｇｅｒ（Ｑｕａｄｒａｔ  Ｍｅｄｉｃａｌ  Ｓｏｆｔｗａｒｅ  Ｎ．  Ｖ．  ｉｎ  Ｂｅｌｇｉｕｍが開発し、配布している製品）を用いることにより行える。好ましくは、Ｑｍａｎａｇｅｒは、Ｑｕａｄｒａｔ  Ｍｅｄｉｃａｌ  Ｓｏｆｔｗａｒｅ  Ｎ．  Ｖ．  ｉｎ  Ｂｅｌｇｉｕｍが開発した特殊コンポーネント（ｃｏｍｐｏｎｅｎｔ）であるＥＣｏｍｐａｓを用いて、認可ルールの正しい適用を行なっている。
【００３７】
ルールの例：
”Ｐｈｙｓｉｃｉａｎｓ  ｃａｎ  ｏｎｌｙ  ｓｅｅ  ｔｈｅｉｒ  ｏｗｎ  ｐａｔｉｅｎｔｓ”（医師は自身の患者のみを見ることができる）
それによる結果：
行為（Ａｃｔｉｏｎ）                                                            ：閲覧（”Ｖｉｅｗ”）、ＯＱＬ：”Ｐａｔｉｅｎｔ．ＭｙＰｈｙｓｉｃｉａｎ  ｉｓ  ＭＥ＿ＡＳ＿ＤＯＣＴＯＲ”（「患者にとっての私の医師」は「医師としての私」である）。
あるＯＱＬを指定するセキュリティ・ルール又は認可ルールのようなルールは非常に多くの場合、オブジェクトと関連している。
【００３８】
上記の例では、ターゲットとなるオブジェクトが患者であるので、患者（”ｐａｔｉｅｎｔ）を暗示的にして、ルールは以下のように簡略化できる。
ＯＱＬ：  ”ＭｙＰｈｙｓｉｃｉａｎ  ｉｓ  ＭＥ＿ＡＳ＿ＤＯＣＴＯＲ”
認可アーキテクチャーの実施例は図１に示されている。認可サブシステム１０はデータベース２０から認可ルールを検索し、ＯＱＬ  ｐａｒｓｅｒ  （ＯＱＬ構文解析ツール）３０を用いて、それらを処理する。認可サブシステム１０はパーフォーマンスを改善するために種々のレベルのキャッシング（ｃａｃｈｉｎｇ）を用いている。現在の状況で一定のオブジェクト、即ち、ユーザー、部門等にどの行為が許されるかを問い合わせるためにＡＰＩ（図示せず）を設けている。
【００３９】
ＥＣｏｍｐａｓ４０、５０に基づかないアプリケーション６０はＥＣｏｍｐａｓ４０、５０無しに認可サブシステム１０を直接使用できる。認可のチェックはコード（ｃｏｄｅ）内の適当な場所で、認可サブシステム１０にコール（ｃａｌｌ）を挿入することにより実行できる。これらのアプリケーション６０もＭＹ＿ＡＦＦＩＬＩＡＴＩＯＮ等に対して正しい値を供給しなければならない。非常事態の場合に、アプリケーション６０はアクセス制限を無視できるが、それ自体で全ての監査用記録を行なわなければならない。
【００４０】
ＥＣｏｍｐａｓプラットフォーム４０の上で開発されたアプリケーション５０もこれらのチェックを明示して挿入できるが、認可事例の大部分例えば、選択、作成、更新、抹消の行為に対してビジネス・オブジェクト層（ｂｕｓｉｎｅｓｓ  ｏｂｊｅｃｔ  ｌａｙｅｒ）４０に依存できる。
【００４１】
アプリケーション５０がオブジェクト又は「ビジネス」オブジェクトに対して行為をするとき、現在のユーザーの状況でその行為が許されるかどうかチェックするために対応するＯＱＬルール３０を評価する。許されない場合、作業は中断し、異議が申し立てられる。ＥＣｏｍｐａｓのアプリケーション５０が問い合せ例えばＯＱＬにより書込みを行なうとき、その結果はオブジェクトのリストとして戻される。このリストを検索した後で、ＥＣｏｍｐａｓ５０はアクセス管理のためにリストの各要素をチェックする。アクセスが許されているオブジェクトのみが含められる。他のオブジェクトは除かれる。そのようにしてアプリケーション５０には見えなくなり、ユーザーがアクセスできなくなる。
【００４２】
さらに、ＥＣｏｍｐａｓはオブジェクト・グラフのＸＭＬでの閲覧を行える。アクセスの「選択」になっていないオブジェクトはこのＸＭＬ文書に出力される詳細情報ないし属性を有しない。これらの属性はアクセスが拒否されていると説明したセキュリティ・メッセージが書かれた標識を付けられる。
【００４３】
危機的な状況の場合に、監査用追跡のための自動記録と組合わせて、アクセス管理の無視も可能である。
【００４４】
本発明の好ましい実施例を詳細に述べてきたが、添付した請求項に定義されている本発明の範囲を逸脱せずに多くの変更を行えることは当該分野の技術者であれば明らかであろう。
【図面の簡単な説明】
【００４５】
【図１】本発明に基づく方法を実施するためのシステム即ち認可アーキテクチャーを示す。
【符号の説明】
【００４６】
１０  認可サブシステム
２０  データベース
３０  ＯＱＬ  ｐａｒｓｅｒ  （ＯＱＬ構文解析ツール）
４０  Ｅｃｏｍｐａｓプラットフォーム、ビジネス・オブジェクト層
５０  ＥＣｏｍｐａｓに基づくアプリケーション
６０  ＥＣｏｍｐａｓに基づかないアプリケーション
【図１】
2005174331.tif 000003