JP6216076B2 - 企業にとって関連する情報を識別する、システム及び方法 - Google Patents

Description

本開示は、企業ソフトウェアに関し、特に、企業によって行われるプロセスに影響を与える、問題、機会、及び／又は予期しない又は興味の対象のイベントに関連する情報を発見することを支援する、ソフトウェアに関する。

企業（ある目的のための活動を実行する、任意の組織であっても良い）は、一般的に、ゴールと、これらゴールを達成するために設計されたプロセスを有する。一般的に、企業内の問題は、１又は２以上のプロセスの成功に影響するだろう。これらの問題はフォーカスされて、効率の良い方法で識別されなくてはならない。企業内の人々（企業システムのユーザ）は、彼らが責任を有するプロセスに対してリスクを起こし得る問題に対して、警告される必要がある。問題を解決する必要のあるユーザは、問題に関連する情報、特に、問題に関連する企業内での同時発生及び過去の経験についての情報を自由に使用したいと思うであろう。また、当該ユーザは、問題解決において、他のユーザと協力したいとも思うだろう。

そのため、プロセスに関連付けられた問題に関連する情報を識別し、検索し、当該問題に最も関心があるユーザに当該情報を案内するシステムを実装することが望まれる。

本開示によると、企業の問題、企業の機会、及び予期しない又は興味の対象のイベントに関連する、企業内の情報を発見及び検索するためのシステム及び方法が提供される。システムが企業情報を検索すると、問題、機会、又はイベントに関係するシステムの知識を豊富にするために、現在のアイテム（例えば、回覧中のｅ−ｍａｉｌ）、及び過去のアイテム（保管されたメモ）にインデックスを付す。

本開示の第１の視点によれば、企業によって実行されるプロセス、又は前記プロセスの企業重要点に関連する情報を発見するプロセスは、企業によって実行されたプロセスに関係するコンテンツを走査するように構成されたコンピューティングデバイスを含み、前記プロセスは、１又は２以上のプロセスステップを含み、前記コンピューティングデバイスは、前記プロセスステップに関連付けられた問題、又は機会（好機；opportunity）、又はイベント（企業重要点）を識別し、；前記企業重要点に関する走査されたコンテンツにインデックスを付与し、；前記走査されたコンテンツが、問題、機会又はイベントに関連する情報であるかを決定し、；ユーザに、関連する情報を提供する。当該関連する情報は、問題、機会又はイベントに関して、企業（又は関係する企業）の過去の経験に関する記載又は検討を含む。前記走査されたコンテンツは、企業へ又は企業からのｅ−ｍａｉｌによる通信；企業によって生成されたドキュメント；及び／又は企業がアクセス可能なＷｅｂコンテンツを含んでも良い。企業重要点は、問題、機会又は予期しない又は興味の対象のイベントであり、原因、結果、改善（救済）をさらに記載する他の重要点に関する。

情報が、問題、機会又はイベントに関連するかどうかを決定することは、プロセスステップを含むプロセスに関係するゴールの達成における、当該プロセスステップの完了の影響を決定することを含む。これを、プロセスステップのゴール近接度と称する。また、プロセスステップのゴール近接度は、関連性の重要な基準（important relevance criterion）であるリスクを決定するために使用されても良い。

また、ゴール近接度の決定は、プロセスの包括的観点における類似性及びゴールに対する近接度の類似性により、類似していると考えられる類似プロセスを発見するために使用されても良い。それらの類似プロセスに関係する経験は、ユーザの注意を引くために、システムから応答される。

プロセス間の類似性又は関連性の推論が、それらの包括的観点から引き出されるように、システム内で包括的なプロセスコンポーネントにより特徴付けられるプロセスを識別することによって、関連性の決定が容易化されても良い。さらに、プロセスに埋め込まれた固有な問題（endemic problem）又は機会は、プロセス間の更なる類似性及び関連性を確立する。

前記システムは、企業によって実行されたプロセスに関係するコンテンツを走査するためのスキャナーと、；前記走査されたコンテンツ内の概念を識別する言語構文解析装置（language parser）と、；プロセスノード（プロセスノードは、問題、機会又はイベントに関連付けられている）に関係する前記走査されたコンテンツにインデックスを付し、前記走査されたコンテンツが問題、機会又はイベントに関連するかどうかを決定する、インデックスエンジンを含む。言語構文解析装置及びインデックスエンジンは、走査されたコンテンツ内の概念に、重要点関連性（a stress point relevance）を割り当て、それにより、前記走査されたコンテンツのアイテムのための、重要点インデックスを生成する。

さらに、システムは以下を実現するために重要点インデックスを利用するユーザインタフェースを更に含んでも良い；関係するプロセスの集合に関連づけられた問題をユーザに警告する；協力関係にあるユーザ（利害関係者）に与える情報をプロセスに関する過去の同時発生的な情報に制限すること、及び、下位のプロセスに関する情報が協力関係にある集団（利害関係者）にとってのリスク（プロセスのリスク）を生じさせそうであれば、当該下位のプロセスに関する情報をユーザに与えることにより、プロセスに関連付けられた問題又は機会に対処するユーザ間の協力を実現する；プロセスに関連付けられた問題に関係する過去の経験の記載又は検討を含む情報を検索する。実施例では、インデックスエンジンはミドルウェアサービスである。

本開示の他の視点によれば、ユーザは、本書で記載される様々な使用のために用いられる、過去及び現在の経験を検索する認識構造を操作（ナビゲート）しても良い。

なお、本開示によれば、企業の問題を解決する時、企業の機会を利用する時、企業活動のなかで起こる、興味の対象又は予期しないイベントを説明する時、以下の決定がされても良い；当該コンテンツやデータを、関連する企業重要点（プロセスノード）やこれらのプロセスノードに最も近い関係がある認識構造の要素に関連付けることにより、企業に対するコンテンツ又はデータのアイテムの関連性が完全に決定される；プロセスの証明書（identification）及びそれらの包括的なプロセスコンポーネント、各プロセスにおける当該プロセスが従属するプロセスのゴール近接度、固有な問題、プロセスに関連付けられた機会やイベントを参照することにより、プロセス間の類似性が完全に決定される；１つのステップ（工程）に含まれるプロセスノードがリスクを示すと決定される際には、（ｉ）上記ステップの直接のゴールに対する、当該ステップのゴール近接度、（ｉｉ）当該ステップのゴール近接度と当該ステップの更なる従属ゴールに対する影響、（ｉｉｉ）失敗したゴール及びその改善のためのアクションに関する見積もられたコスト、（ｉｖ）当該ノードによる失敗の可能性、を参照することにより、リスクの重症度（重要度）が完全に決定される。

前述の事項は、本開示の好ましい特徴を、かなり広く概略化したので、当業者は、以下の開示の詳細な記載をより良く理解できるかもしれない。本開示の請求の範囲の対象を形成することで、本開示の追加の特徴は記載される。当業者は、彼らが、本開示と同一の目的を実行する他の構造を設計及び修正するための基礎として、本開示された概念及び明確に示された形態を容易に使用できることを認識すべきであり、そのような他の構造は、本開示の最も広い形式において、本開示の精神及び範囲から逸脱しないことを認識すべきである。

図１は、本開示の形態に関して、企業にリンクした関連する情報を発見するソフトウェアを用いて、ゴールとプロセスを有する企業を体系的に図示する。

図２は、企業プロセスのためのプロセスノードの一視点を体系的に示す。

図３は、プロセスノードの定義の根幹をなす、抽象化された活動を体系的に図示する。

図４は、企業のゴールと関連付けられたプロセスを図示する。

図５は、二つのプロセスのいくつかの詳細と、これらのプロセスに関連する問題を図示する。

図６Ａは、様々なプロセスステップのゴール近接度を図示する。

図６Ｂは、企業内のアクター間の相互作用と、所定のプロセスステップを図示する。

図７Ａは、包括的なプロセス、及びより特有なプロセスを体系的に図示する。

図７Ｂは、プロセスノード、又は企業重要点を含むプロセスを体系的に図示する。

図８は、複数のプロセスに関係するリスク、原因、結果、改善を示す、プロセスノードを体系的に図示する。

図９は、抽象化の様々なコンテクストに特有なレベルで、エキスパートユーザがノード属性を割り当てる工程を図示するフローチャートである。

図１０は、包括的なプロセス、及び所定の元のプロセスに類似するプロセスを識別する、本開示の形態に係る工程を図示するフローチャートである。

図１１は、エキスパートユーザが、事象又は再出現のストーリーのシステムを定着させる、本開示の形態に係る工程を図示するフローチャートである。

図１２は、ソフトウェアが企業重要点を構築及び統合する、本開示の形態に係る方法を図示するフローチャートである。

図１３Ａは、問題の解決、又は機会の利用のために、本開示の形態のシステムのユーザが行う工程を図示する一連のフローチャートである。 １３Ｂは、問題の解決、又は機会の利用のために、本開示の形態のシステムのユーザが行う工程を図示する一連のフローチャートである。

図１４は、情報を収集し、企業重要点に対する情報にインデックスを付する、本開示の形態に係るシステムを体系的に図示する。

図１５は、本開示の形態に係る、ゴールの収束を体系的に図示する。

図１６は、閲覧権限が制限されているユーザを含む、複数のユーザが使用するシステムを体系的に図示する。

図１７は、先行技術で既知である緊急管理システムを体系的に図示する。

図１８は、本開示の形態に係る緊急管理システムを体系的に図示する。

図１９は、選択ノードの表示を図示する図１８の緊急管理システムにおける、より多くの要素を示す図である。

本開示を具現化するソフトウェアは、本開示では、「オーバーレイ」と称する。オーバーレイは、企業内の情報を発見することを助けるものである。この情報源は、典型的には、企業内部コンテクスト（enterprise internal context）及び企業データであり、企業内の通信、及び企業と外部組織間の通信を含む。他の情報源は、企業が定期的にアクセスすることを望む、企業に関係した外部の情報である。オーバーレイの一視点によれば、オーバーレイは、サーチエンジンとは対照的な、関連エンジン（relevance engine）として機能する。オーバーレイは、企業の問題、企業の機会及び予期しない又は関心あるイベントに関連すると考えられる情報だけを検索する。

オーバーレイソフトウェアは、企業プロセス間の関連性、及び、そのようなプロセスの内の企業重要点（即ち、危険、予期される失敗、競合、リスク、共通の原因、注意と知識に関連するエリアといったビジネスのフォーカスポイント）間の関連性を使用する。オーバーレイソフトウェアは、下記事項が達成できるように、潜在的なデータ及びコンテントから適切なリターン（検索の結果）だけをユーザに提供するように、上記企業プロセス間の関連性、企業重要点間の関連性を使用する。

オーバーレイは、ユーザが責任を負う企業重要点を構成し得るいかなる企業ソフトウェア／ｅ−ｍａｉｌの基礎にある変化の概略を、オーバーレイのユーザに提供する。大規模な組織では、上席職員が、全ての申し込み（all applications）を手動でナビゲートし、監視するような方法は不可能である。また、当該上席職員が、潜在的に問題を構成し得る事象であって、全ての発生し得る事象に関する、変更が難しいワークフロー（hard wired workflows）をこなすことは不可能である。企業重要点は、複数のイベントの結合によって発生することが多いため、オーバーレイは、それらの企業重要点を識別することを支援する。また、オーバーレイは、頻繁な通知が望まれない場合にはそのような通知を差し控える。

オーバーレイは、オーバーレイのユーザが、携帯機器を用いて、遠隔地から、企業コンテンツ、及び／またはデータシステム（ｅ−ｍａｉｌシステムを含む）にアクセスできるようにする。さらに、オーバーレイは、企業重要点に影響するイベントが選別（フィルタリング）された描画を可能とする。

オーバーレイは、ユーザがメタデータに関連する知識を有するエンリッチコンテンツ（enrich content）だけでなく、イベントや同等の警告を、オーバーレイのユーザが処理できるようにする。

オーバーレイは、関連する過去のコンテンツ（relevant legacy content）によってサポートされる、望まないイベントを、オーバーレイのユーザが管理できるようにする。

用語集

原因：結果を引き起こす原因になるであろう、発生する出来事又は潜在的な出来事である。

原因源：原因が発生した理由になるであろう、発生する出来事又は潜在的な出来事である。

影響：プロセス、計画ゴール（plan goal）、条件付きゴールに影響するであろう、発生する出来事又は潜在的な出来事である。

リスク：潜在的な影響である。これは、機会に対応する時にはポジティブな意味になり、問題に対応する時には、ネガティブな意味になる。

診断：問題の原因を発見すること、及び興味の対象のイベント又は機会の原因を説明することである。

組織する：抽象化、一般化、グループにすることである。

ゴール近接度／近接度：ステップが属するプロセスのゴールに対する、プロセスステップの影響の割合である。

ゴール、又は条件付きゴール：企業プロセスで設計された、ゴール、又は条件付きゴールである。

認識構造：既知の認識原理に適合するような方法で、情報にインデックスを付する構造である。

問題又は機会をより深く理解する主な手段：問題、機会について、最も適切な関連性を決定する方法である。

事象／検討／記載／経験：これらは、原因、結果、リスク、改善のうちの全て又は一部を記載し得る、経験の事象である。これらは、物事が割り当てられたプロセス内で、当該物事がどのように動作するのかを記載するための一般化された説明、一般化されたモデルを含んでも良い。

モデル：原因と結果を説明する、一般化された事象である。

説明：問題、機会、予期しないイベントの説明である。

属性：本開示で述べるエンティティの特性である。ノード属性は、ノードの類似性を決定するために用いられる。つまり、類似性を決定するノードの特性である。ノード属性は、状態モデル内で表される。つまり、ノードの特性は、状態モデル内で表される。

責任を負う：プロセスの出力、又はプロセスステップの出力に対して、アクターの属性が非常に影響を与える状況である。

問題／失敗：本開示では、問題及び失敗とは、豊富な経験を積んだ実務家が合理的に予期する問題、及び／又は失敗のプロセス内で考慮されたノード、又は、説明されない現象、又は説明されない原因と結果の現象である。

機会／成功：本開示では、機会及び成功とは、豊富な経験を積んだ実務家が合理的に予期する問題、及び／又は失敗のプロセス内で考慮されたノードである。

イベント／予期しないイベント／興味の対象のイベント：本開示では、イベントとは、豊富な経験を積んだ実務家が、企業及びそれらのゴールにとって重要と考えた、発生する出来事である。

プロセスノード：豊富な経験を積んだ実務家が、問題及び機会を予期するプロセスの一部である。

豊富な経験を積んだ実務家：職歴の大部分において、豊富な経験を積んでいると決定されるプロセスに取り組んで、責任を負ったことがある人々であって、特定のプロセス、及びその主な特性を意識する人々であって、豊富な経験を積んでいると考えられるプロセスに従属するプロセス及び下位のプロセスを認識する人々である。

企業：１又は２以上の既知の目的のために活動する、任意の組織、又は組織の集合である。一回でのゴールの予測可能性と、それらのゴールを達成するための計画及びプロセスの予測可能性と、ゴールに関連して実質的に既知である、価値、スキル、情報、耐久性、感情を有するアクターとによって、一般的に特性づけられるものである。

企業活動構成；多くの分野での実務家によって認識される関連性の基準に関連するフレームワークである。

企業活動：各分野、又は一以上の分野の実務家によって認識される活動である。

外部プロセス：いくつかの企業プロセスが従属する、企業の外部で起こる外部プロセスであって、例えば、設計、建設、教育、及び任意のプロセスステップの一部になり得る準備活動である。既知のゴールに役立たせるためには設計されていないが、企業プロセス及びゴール（例えば、裁量での人の活動）に影響がある環境において発生することが発見されるプロセスである。又は、環境的な現象のような、人の活動に直接的に関係しないプロセスである。

実務家：企業で、平均的な経験を積んだ人々である。

オーバーレイ：本開示に係るシステム、及び／又は方法である。

固有な問題／機会／ノード：関連する様々なプロセスにおいて反復する、豊富な経験を積んだ実務家によって考えられる抽象化の様々なレベルにおける、問題、機会、又は予期しない／潜在的／時々、発生する出来事である。問題及び機会は、最初のゴールを定義せずには、定義できない。そのため、固有な問題／機会は、ゴールに関連付けられる。

オブジェクト：プロセスの一部の分野でのオブジェクトである。

コンテクスト：プロセスが起きる分野内での環境である。

抽象化されたオブジェクト：抽象化されても良いオブジェクトであって、且つその結果として、二以上の分野に適用されても良いオブジェクトである。

抽象化されたコンテクスト：抽象化されても良いコンテクストであって、且つその結果として、二以上の分野に適用されても良いコンテクストである。

分野：産業、会社の部門、又は任意の企業構造である。ここで、企業構造とは、プロセスステップ及び技術が特定されていて、さらに実務家が当該プロセスステップ及び当該技術を理解できるものである。

固定化：企業活動モデル内のエンティティの特性である。当該特性は十分に一定且つ予測可能である、と実務家は予期するので、当該特性は変化するけれども一定であると考えられる。

関連性の基準：企業活動モデル又は企業活動構成の構築の助けになる、任意のエンティティである。

環境：コンテクスト、実行時、又はそれらに類似するものである。

プロセス：ゴール及び条件付きゴールの組み合わせに役立つ、一連のアクションである。プロセスは、固定されたプロセスから、確立したプロセス、新たに確立したプロセス、さらに、実行されるべきプロセスの計画の範囲までにわたるものである。

スクリプト：固定されたことで、意識的かつ潜在的に実行されるプロセスである。

計画：計画とは、プロセス内のステップ（工程）が、現状の環境に合う方法で順序立てられている、あまり定義付けられていないプロセスである。計画のゴールの階層は、計画に結び付けられた基礎にあるプロセスとは異なることが多い。

無生プロセス（Inanimate process）：人の介入を含まないプロセス（例えば、化学的なプロセス）であって、プロセスの一部として人為的に設定されたプロセスのゴール以外には、ゴールを有しなくても良いものである。例えば、腐食は、予測可能なものであり、周知なものであるが、プロセスに基づいたゴールとして考慮されない、無生プロセスである。

ゴールに基づいていない生きているプロセス（animate processes）：音楽の特定の種類を大切にすること、又は特定の色を好むことのような、人々が経験するけれども明確なゴールに基づかないプロセスである。これに対する常用語は任意である。

条件：英語及びＡＩ（artificial Intelligence）において定義されている通りである。

企業ゴール、及びプロセス

図１において体系的に示す通り、企業１は、一般的に、ゴール１１、及びゴールを達成するために設計されたプロセス１２を有する。企業、及び企業の分野は、一般的に、ゴールに関して、次の属性を有する：価値の集合、スキルの集合、知識の集合、情報の集合、耐久性の集合、感情の集合を有する。１又は２以上の企業は、産業、会社の部門、又は任意の企業構造として定義された、一分野に属していても良い。ここで、企業構造とは、プロセスステップ及び技術が特定されているとともに、実務家が当該プロセスステップ及び当該技術を理解できる構造を指す。従って、所定の分野の実務家は、特有な知識を共有すると言えるかもしれない。

ゴール１１は、企業ゴール（高いレベルで表現されることが多いので、企業に特有なプロセスは当該企業ゴールに関連付けられない）、メインのゴール（１又は２以上の企業ゴールに直接的に影響する達成物）、及び条件付きゴール（つまり、プロセスを設計するための最優先の理由ではないゴールであって、達成されない時には、メインのゴールを達成することを妨げるかもしれないゴール、又は、メインのゴールを達成できるが、望まないようなことを達成するゴール）、プロセスは、ゴールに基づいても良い（一般的に、ゴールを達成するために行動する、企業のアクターによって実行される）。または、プロセスは、ゴールに基づかないが、大抵、人為的に規定されて設計されても良い。または、プロセスは、ゴールに基づかないとともに、人為的に規定されない又は人為的に設計されなくても良い。プロセスは、機械的な機能を含んでも良い。または、プロセスは、人が求めるゴールのために、人為的に設計されるが、必然的に人為的に規定されない、任意のプロセスを含んでも良い。企業内で様々なプロセスを実行する場合には、リスクがあり、問題及び機会が発生する。これらの問題には、原因、結果、リスク、潜在的な影響、改善を有する。

リスク、問題、機会が、それらを提示し得る経験であると示される、又は予期しないイベント又は興味の対象のイベントが起き得る経験として占められるプロセスの一部１３を、「企業重要点」、又は「プロセスノード」と称する。プロセスノードは、企業内で経験を積んだアクター１５により識別されることが多い。企業によって、Ｗｅｂ１００上のサービスとしてアクセスされる形態に係るオーバーレイソフトウェア１６は、企業内部コンテンツ及びデータ１４、及び、時には、外部データを検索し、識別された重要点にインデックスが付与された情報を生成する。そして、インデックスを付された情報は、それに割り当てられた重要点関連性を有する。オーバーレイは、企業内のプロセスノード、及び自然言語を記載するために使用される単語表現に基づいて、自然言語サーチを検索する。また、オーバーレイは、各プロセスノードに関連することが既知である、構造化されたデータも検索する。

より一般的には、プロセスは、内部のプロセス又は外部のプロセスいずれか一方でもよく、又は、その二つの組み合わせであっても良い。内部のプロセスとは、企業内部で規定されるものであり、外部のプロセスとは、企業の外部で起きるものであり、設計、建設、又は教育、及び任意のプロセスステップの一部となり得る準備活動である。プロセスは、既知のゴールに役立つように設計されてはいないが、企業プロセスとゴールに影響を与える環境（例えば、任意の人の活動）内で発生することを発見されるプロセスであっても良い。または、プロセスは、環境依存の現象のような、人の活動に直接的に関連しないプロセスであっても良い。

プロセスノード

図２に体系的に示すように、プロセスノード２１は、１又は２以上の問題、機会、及び／又はプロセス内、又はプロセスのプロセスステップ内での予期しない／興味の対象のイベントによって、特性付けられる。企業データ及び内部のコンテンツ（及び、他の情報源）２４の自然言語サーチ２３において、プロセスノードを記載する単語表現２２は使用される。

企業のプロセスノードは、認識構造のコンポーネントを表現する（下記で、詳述する）。認識構造の構成要素としてのプロセスノードは、企業内、又は時には企業の直接的な活動範囲以外の範囲において、ゴール及び／又はプロセスとの関連性を、実務家が発見する、問題及び／又は機会及び／又はイベントの検討又は記載を含む。そのような企業の直接的な活動範囲以外での活動には、他の企業、ビジネス界、政治環境、社会環境、物理学環境、生物学環境、又は、企業プロセスに大きく影響する、任意の環境であっても良いが、これらに限定されない。

プロセスノードは、以下の通り、潜在的な問題、機会、イベントの検討及び／又は記載に対する相違点を含んでも良い。
（ａ）以下のプロセス内で、１又は２以上のゴール、又は条件付きゴールを実行することにおける、問題又は機会又は予期しないイベントに関する、検討及び／又は記載又はデータである。
（１）検討される時点又は記載される時点、又はその後の時点において、影響されるプロセスと考えられるプロセス。
（２）上記影響されるプロセスに従属するプロセスの構成要素になるプロセス。
（３）下位のプロセスが失敗すると、アクティブになり得る問題又は機会を含むプロセス。
（４）上記影響されるプロセスに対する下位のプロセス内に、問題又は機会、及び／又は潜在的な問題又は機会を含むプロセス。
（ｂ）以下に関する検討及び／又は記載又はデータである。
（１）問題、機会又は予期しないイベントの説明に関する検討及び／又は記載又はデータ。
（２）問題、又は機会、又は予期しないイベントの原因の分析に関する検討及び／又は記載又はデータ。
（３）問題、又は機会、又は予期しないイベントの原因元（原因の原因）に関する検討及び／又は記載又はデータ。
（４）問題を改善するため、又は機会を利用するためのアクションとして考えられる計画に関する検討及び／又は記載又はデータ。
（５）どのようにして問題を回避するか、又はどのようにして機会を引き出せるかを記載する手順に関する検討及び／又は記載又はデータ。

プロセスノードに関係する検討又は記載は、文字又は図面により表現できるし、又は企業のソフトウェア又はコンテンツで使用される慣例表現を構成する、任意の組み合わせでも表現できる。これは、スプレッドシート、ｅ−ｍａｉｌ、ドキュメント、メタデータ、データベース内のデータ、電子メッセージ、音声通信等を含んでも良いが、これらに限定されない。

本開示で検討する認識構造は、既知の認識原理に適合する方法を用いてインデックスを付された情報を有する構造であって、当該認識原理は、情報の関連性を決定することを許容することで、互いに関係するように構成される。

図３に体系的に示すように、認識構造３３とは、日々の活動の抽象表現、及びそれらに関係するオブジェクトである。これらは、企業の対象分野以外での平均的な実務家にとって馴染みのある活動、及びオブジェクトである。なぜなら、それらは、日々、多くの分野での企業活動で使用されているからである。そのような企業活動及びオブジェクト３２は、ユーザ、ユーザの役割、タスク、タスクとプロセスとが発生するコンテクスト、企業オブジェクト、プロセス、ゴール、スキル、価値、プロセス内のアクター、任意のこれらを一般化したものを含むが、これらに限定されない。所定のプロセスノードは、認識構造のコンポーネントを示す。認識構造における、全てのノード及びエンティティは、抽象化されていても良いし、及び／又は、抽象化された他のエンティティであっても良い。

よって、認識構造３３は、以下を含んでいても良い。
ゴール；
ゴール、及び関連するプロセス、及び関連付けられた固有なノード（以下に、詳述する）；
企業、企業の部門、関連付けられた役割、アクター、及び属性（例えば、スキル、価値等）；
一般化されたプロセスノード；
特有なプロセスノード；
低いレベルのゴール、及び関連付けられたプロセスステップ；
タスク、及びタスクを規定するアクター又は役割；
コンテクスト、及びコンテクストが影響する、関連付けられたプロセス又はタスク；
オブジェクト、及びオブジェクトが影響する、関連付けられたプロセス又はタスク；
ワークフロー；
ユーザ

また、オーバーレイソフトウェアは、任意のプロセス又はプロセスノード、又は認識構造の任意の要素に関係する情報を発見するものである。オーバーレイソフトウェアによって使用される情報検索方法は、この関係する情報に適用される。また、これらの検索方法は、認識構造の多くの要素に適用される。

「関連する（relevant）」との単語は、リスクがある状態でプロセスとして関係すること、リスクがある状態で追加プロセスとして関係すること、原因プロセス、抽象化された原因プロセス、追加の原因プロセス、改善のためのアクションのプロセス、任意の他のプロセスに類似するプロセスとして関係すること、共通のコンテクスト又はオブジェクト又はこれらの抽象化によって関連付けられること、共通のノード又は抽象化によって関連付けられること、共通のゴール又は条件付きゴール、又はこれらの結合によって関連付けられることを含むが、これらに限定されない。

もし、情報が、問題、機会、又は予期しない／興味の対象のイベントに関して、より深く理解するための主な手段ではない場合には、当該情報は、オーバーレイの目的には無関係なものである。

以下で、詳細に説明するように、企業と、コンテンツのアイテム又はデータとの関連性は、企業重要点（プロセスノード）によって完全に決定されても良い。

プロセスの分析；プロセスの類似性

図４は、一の企業に対するいくつかのゴール、及びいくつかのプロセスを示す体系的な図である。この図は、企業全体に対するゴールの組４１は、これらのゴールを達成するために設計された、多数のプロセスを有する。一つのプロセス４２は、複数のステップ４３を有する。図示される企業は、物品輸送、特に、海上輸送を含む輸送を行う企業である。そのため、「航行（Navigation）」を扱う企業の分野では、他のゴールの組４４がある。この例では、一地点から他の地点に航行するためのプロセス４５は、次の複数のステップ４６を有する。；当該複数のステップとは、見ること（例えば、航行ゴールを発見すること）、移動すること（例えば、エンジンを操作すること）、及び要求された位置にコースを設定することである。図５において、より詳細に示す通り、「見ること」のプロセスステップは、眼鏡の必要性を有する。そのため、眼鏡を紛失することは、当該プロセスステップの問題の構成要素になる。

異なるゴール４７（例えば、地上で、銃を発射すること）を有する、異なる分野（例えば軍事訓練）の企業であっても、航行のプロセス４５に類似する、いくつかのプロセスステップを有していても良い。ゴール４７のグループは、メインのゴール（「銃を発射」、「対象に命中」）、及び条件付きゴール（「他の物体を回避」、「爆発を回避」）を含む。ゴール「銃を発射」が、望まれる方法で達成されるように、条件付きゴール「爆発を回避」が満たされる必要がある。ゴール「銃を発射」を達成するためのプロセス４８は、「対象を見る」ステップ４９を含む。活動「見ること」は、両方のプロセスに関連する包括的な活動として決定されても良い。さらに、プロセス４８は、「銃を調整する」ためのステップ５０を含む。「銃を調整する」ためのプロセスステップは、レンチの必要性を有し、レンチを紛失することは、当該プロセスステップの問題の構成要素になる。眼鏡を紛失すること、及びレンチを紛失することは、包括的な問題（即ち、包括的なノード）、即ち、「道具を紛失すること」として決定されても良い。

図５において、いくつかのノード、及びいくつかのプロセスは、コンテクストに特有、コンテクストにおいて包括的なものとしてラベル付けされる。異なる分野のプロセスであっても、包括的なプロセス、及び包括的なノードに関係することが分かる。より一般的には、一旦、コンテクスト特有ノードが識別された場合、コンテクストに特有なそれらのノードは、より包括的なノードを定義する。続いて、これらのより包括的なノードは、所定の分野でコンテクスト／分野に特有なプロセスにおける、包括的なコンポーネントを定義する。これらの包括的なプロセスコンポーネント、及びそれらの包括的なノードは、いくつかの包括性のレベルでは、他の分野にあるだろうし、且つその結果として、この異なるコンテクスト／分野に特有なノードを示すだろう。

プロセスノードは、他のプロセスノードに類似することがある。これは、以下で詳細に説明されるプロセスの類似性、又はプロセスステップの類似性によって決定される。図５に示すように、異なるプロセスのプロセスステップは、共通性を有することが多い。一つのプロセスステップが二つのプロセスに共通する時に、プロセスステップの属するメインのプロセスのゴールに、当該プロセスステップが同様に影響を与えることができる場合には、当該二つのプロセスは類似すると考えられる。プロセスステップが属するゴールに対する、当該プロセスステップの影響を、当該プロセスステップの「ゴール近接度」と称する。

オーバーレイソフトウェアは、類似のプロセスを発見し、プロセス及びプロセスノード及びゴール近接度が類似する、類似事象を示すことによって、所定のプロセスノードの問題及び／又は機会に類似する事象を発見する。これに関して、オーバーレイは、事象の類似性に関するプロセス条件の膨大な組み合わせには依存しないことに留意するべきである。オーバーレイは、ゴール近接度、及びノードの類似性、及び抽象化されたノード又は固有なノードから、プロセス類似性を評価する（抽象化されたノード又は固有なノードは、抽象化されたプロセスを定義するための代替の方法を提供する。なぜなら、最も抽象化されたレベルにおいて、非常に抽象化された固有なノードを扱うために、プロセスは考案されているからである）。所定のプロセスにおいて、プロセス条件が、当該プロセス内に含まれる。従って、類似プロセスの発見は、比較可能である条件を定義するだろう。これは、実際には、プロセスノード（プロセスの問題及び機会）には、突出した条件が繰り込まれるからである。そのため、もし、プロセスノードがプロセスの基準を定義していれば、当該プロセスノードはプロセス内の条件を定義するために十分でもあることになる。

オーバーレイは、プロセスとノードの両方に含まれる類似点を検索することに留意すべきである。一般的には、プロセスは、問題を示すノード（problem nodes）が回避されて、機会を示すノード（opportunity node）が引き出されるように開発される。所定のプロセスは、１つ以上のノードを有しても良い。その結果、ノード類似性は、プロセス類似性に含まれることになる。

さらに、プロセス内のゴールの階層は、類似性の決定に影響する。プロセス内のゴールの階層及び条件付きゴールの階層は、プロセス内のゴールのプロフィール（profile）を決定する。これは、プロセス類似性の特性を追加して決定することであると考えられる。類似のゴールの階層を有するプロセスは類似するだろう。従って、プロセス類似性は、共通のプロセス、又はそれらのプロセスステップに対する共通の一般化にのみ依存するものではない。

ゴール近接度；成功可能性

一般的に、プロセスのゴールの成功を達成する上で、全プロセスステップが、同等に不可欠なわけではない。上述したように、「ゴール近接度」という単語は、プロセスステップが属するゴールに対する、当該プロセスステップの影響を意味する。プロセスステップのゴール近接度は、１又は２以上のプロセスのゴール又は条件付きゴールに関する、成功又は失敗を達成することに、プロセスステップがどの程度近づくかということによって定量化されても良い。例えば、図６Ａに示すように、ゴール「銃を発射」の達成は、プロセスステップ「銃を調整」の完了に依存して、５０％と判定される。ゴール「対象に命中すること」を達成することは、プロセスステップ「対象を見ること」の完了に依存して、７０％と判定される。これらの関係は、図６Ａの矢印６１、及び６２によって、体系的に示される。その結果、高いゴール近接度のプロセスステップ内の問題は、そのプロセスの成功への影響を大きくすることになる。ゴール近接度は、プロセス類似性に追加の基準を提供する。従属するプロセスのゴールに類似した影響を有するプロセス、及び、共通の包括的又は特定の特性（例えば、共通のノード）も有するプロセスは、異なる分野で発生するプロセスであっても、類似すると考えられる。

リソースが豊富であること（又は、リソースが欠如していること）は、プロセス内のプロセスステップの属性であると考えられる。そのため、リソースが冗長であることは、プロセスのゴール近接度に影響する。さらに、プロセスの豊富さ、又は、プロセスの冗長さに応じて、プロセス内の問題又は機会は、ゴールへのプロセスステップの近接度に影響する。

また、アクター（プロセスを実行する人、又はプロセスを実行しないがプロセスに関係する人）は、プロセスの成功に影響を与える。図６Ｂに体系的に示すように、アクターは、主に自身が責任を負うプロセスステップに対して影響を与える。一般的に、アクターは、以下の属性、つまり、価値、スキル、専門知識、情報、耐久性、感情の属性を有する。プロセスステップに依存して、他のアクター属性が関連すると考えられても良い。そして、属性は、プロセスステップに関係する、予期する問題又は機会がある可能性に影響し、且つその結果として、プロセスのゴールに影響する。図６Ｂに例示するように、ステップ「対象を見る」ことに責任を負うアクター６３は、プロセスステップに伴われる１又は２以上のオブジェクト６５と、ステップが実行されるコンテクスト６６とに影響する、スキル、価値、知識６４を有する。もし「対象を見る」ステップにおいて使用されるオブジェクトが、見るためのスコープであり、コンテクストが霧である場合には、霧の中で、対象を見るために当該スコープを使用するアクターのスキルは、成功に大きく影響する。この例から、プロセスステップ自体も、ゴール（「スコープを使用して対象を見つけること」）を有することが分かると共に、アクターの属性は、当該ゴールに影響することが分かる。一般的に、アクターが実行又は影響を与えるプロセスステップは、ゴール、及び条件付きゴールを有する。そして、それは、アクターの属性が影響するこれらのステップ、又はこれらの構成要素のゴール、又は条件付きゴールである。

包括的なプロセス、及びノード

プロセスは、包括的なプロセスグループに抽象化できる。プロセスは、包括的なグループに属しても良いし、包括的なプロセスステップを有しても良い。例えば、船を航行することは、「車、又は船を制御して旅行する」との包括的なプロセスに属することがある。そして、それは、見ること、操舵すること、計画すること等のような包括的なコンポーネントを有する。包括的なプロセスは、分野に特有ではないプロセスであるとともに、他の分野において、平均的な専門知識を有する実務家が認識するプロセスである。一般的には、プロセスは、包括的なコンポーネントを有する、又は、より包括的なプロセスに属する。

包括的なプロセスは、所定の分野において、コンテクストに対する特有性が低いプロセスである。当該プロセスは、より高い抽象化レベルに達すると、特有性がより低くなり、より一般化されたノードを含むことになる。コンテクストに対する特有性が最低であるプロセスは、特有なステップを有しないように、非常に一般的になっても良く、且つその結果として、固有なノード（以下に、詳述する）以外から識別することが困難であっても良い。

包括的なプロセスは、図７Ａに体系的に図示するように表現されても良い。高いレベルのゴールの組７１は、子ゴールの組７２を有し、続いて、当該子ゴールの組７２は、子ゴールの組７３、７４を有する。プロセス７５、７６は、夫々、ゴール７３、７４を達成するように設計される。図中のプロセス７５、７６の実線の境界線は、これらのプロセスが分野に特有なプロセスであることを示す。そして、点線は、包括的なプロセス７７、又は、包括的なプロセスのサブステップ７８を表す。

包括的なプロセスは、実務家及び一般大衆によって、多くの分野のプロセスの一部分であるべきものと発見された、多くの分野のプロセスから一般化されたノード、コンテクスト、オブジェクトを有する。当該包括的なプロセスは、全ての分野を考慮した場合において、少ない属性を有する１又は２以上の特定の分野である時、当該特定の分野に偏ったものであっても良い。これは、コンテクスト、オブジェクト、一般化されたノード等（しかし、これらに限定されない）に適用される。

プロセスノードは、図７Ｂに図示されるように、体系的に表現されても良い。ノードは、プロセス７００内の三つの各プロセスステップ、及びプロセス７１０内の二つの各プロセスステップにみられる。ノード７０１―７０５の夫々は、当該プロセス、又は他の複数のプロセスに関連して起きる問題／機会／イベントに関係する、リスク、原因、結果、又は改善であっても良い。

図７Ｂに示されるプロセス７００において、プロセスステップ７１１―７３３の夫々は、ゴールＧ１に関するゴール近接度を有する。また、その他では、ノードがリスクを表現する場合には、プロセスステップ７１１―７３３の夫々は、プロセス失敗の可能性を有する。これらの概念は、プロセスに関連するリスクを分析するために使用される。他のリスク分析方法とは異なり、オーバーレイソフトウェアにおいては、リスクは、ゴール近接度によって指定されたり、その他では、可能性を評価することによって指定される。上記の通り、ゴール近接度は、プロセス内のゴール又は条件付きゴールが、下位のプロセスの成否によって影響される程度に対して指定された、割合である。下位の程度、又は従属の程度が同レベルのプロセスのゴール近接度は、１又は１００％の全体に対して追加されたものである。各従属プロセスは、下位の程度が同等に低いレベルのプロセスに依存する。例えば、航行するプロセスにおいて、船の方向を決めることは、推進力及び操舵１００％であることに依存する。推進力及び操舵が１００であることは、電力に依存する。船の方向性の決定のレベルのプロセスでは、見続けること、航行計画を立てること、及び船員を管理することのような、同程度に下位のプロセスステップがある。

リスクは、ゴール近接度の見地から評価される。ステップ内のプロセスが、リスクを有すると決定される時、そのリスクの重症度は、そのプロセスに対する直接のゴールに関して、当該ステップのゴール近接度、従属するゴールに関する当該ステップのゴール近接度、ゴール失敗について蓄積されたコスト、及びゴール失敗に対して改善するためのアクションについて蓄積されたコストを参照することによって、完全に決定されても良い。

ゴール近接度は、プロセスのコスト、及びプロセスを管理するためのソフトウェアのコストを評価するのに役立つ。失敗の可能性及び失敗のコストに結び付けられた原因と結果のリンクのゴール近接度、又は改善のためのアクションのプロセスのコストを加えた上で、影響するプロセスを成功することで得られる利益に結び付けられた、原因と結果のリンクのゴール近接度は、リスク又は機会の定量的指標である。そして、これは、リスクを管理するため又は機会を利用するために設計されたプロセスが、会社へのコストを有することを意味する。また、これは、リスクの緩和、又は機会の利用に関連する情報を管理するオーバーレイソフトウェアを販売することは、価値があることを意味する。オーバーレイは、プロセス又はそれらのノードの価値を評価して、リスクの緩和、及び機会の管理によってプロセスの管理を支援する、ソフトウェアの価値の評価するための正しい指標を構築する。

従属プロセスのゴール近接度によって決定されるように、問題によって影響されるだろうプロセス内の関連する経験の利用可能性によって、リスク又は潜在的な機会は、より定性的に決定されたものと推定されても良い。さらに、ゴール近接度と、下位のプロセス内の失敗及び機会の可能性の割合とを積算することで、影響、リスク、機会を定量的に評価できる。

接続されたプロセス

リスク、原因、結果、改善を表現するノードは、プロセスを結び付けることに役立つことに留意すべきである。これに関する簡単な一例は、図８に示される。

いくつかのコンテンツに記載されるように、又はいくつかのデータパターンによって表されるように、機会又は予期しないイベント８０は、関連付けられたリスク、原因、結果、改善（救済）を有する。一般的に、一つのプロセスにおいて、全てのリスク、原因、結果、改善は発見されないだろう。ゴールの組８２に関連するプロセス８１は、ゴールの組８３及び下位のゴールの組８１１、８１２に関連するプロセス８０１、８０２とは異なるものである。これらのプロセスは、全て、問題／機会／イベント８０に関連するノードを有する。示される例では、ノード８５は、リスクがあるプロセス８１内のプロセスステップを示す。プロセス８０１内のステップのノード８６は、問題／機会／イベントの原因を示す。しかし、ノード８７はプロセス８０２内のステップの当該ノード結果を示す。プロセス８０１の他のステップにおけるノード８８は、改善を表す。

固有な問題及び影響

上記の通り、包括的なプロセスは、コンテクストに対する特有性が低い分野のプロセスである。包括的なプロセスは、より高い抽象化のレベルに達するほどに、より特有性が低く、より一般化されたノードを含む。

包括的なプロセスは、複数の種類に抽象化できる。包括的なプロセスのうち、一つの種類は、分野レベルのプロセスに関連付けられても良く、類似分野での経験を積んだ実務家によって認識されるだろう。例えば、乗り物で遠方へ行くことは、人事管理とは異なる種類の包括的なプロセスである。様々な抽象化レベルでは、経験を積んだ実務家は、ある特定の問題又は機会が、様々な関連するプロセスで繰り返されると考える。そのような問題／機会を、固有と称する。問題及び機会は、最初のゴールを設定しないと定義できないので、固有な問題／機会は、ゴールに関連付けられる。

包括的なプロセスの種類は、固有な問題／機会の組み合わせによって定義される。例えば、人事管理の分野では、過去に遡ると、人事に関する多くの固有な問題及び機会がある。そして、プロセスの分野全体は、それらの問題及び機会を扱うために成長してきた。さらに、高い包括性レベルのプロセスは、それらの固有なノードによって定義される。また、オーバーレイでは、一般化されたノード、及び／又は更なる一般化を含む包括的なプロセスは、固有な問題、又は機会でグループ化される。このことが行われるのは、プロセスが非常に一般的になる時には、これらのプロセスステップも一般的になり、プロセス全体は、固有な問題又は機会（しばしば、テーマと称する）を参照しないで定義することが難しくなるからである。オーバーレイでは、包括的なプロセスに関連する抽象化された固有な問題又は機会の組み合わせによって、当該包括的なプロセスは定義される。

プロセス類似性を評価することにおいて、追加の類似性基準は、包括的なプロセス又は包括的なプロセスステップで発見された、１又は２以上の固有な問題である。もし、非常に高い類似性を有する、二つの明らかに異なるプロセスステップが、抽象化された同じ性質の予期された問題又は機会から悪影響を受ける場合には、当該二つの明らかに異なるプロセスステップは、類似であるべきであるものと分かる。

高いレベルの固有な問題又は機会（テーマ）は、分野への特有性が高く、低いレベルの固有な問題を組織することに役立ち、続いて、無制限な個数の分野で、固有な問題の無制限に多数のレベルを組織することに役立つ。また、固有な問題又は機会（テーマ）は、高いレベルの一般化されたプロセスを組織することに役立ち、続いて、分野への特有性が高く、低いレベルの無制限に多数の包括的なプロセスを組織することに役立つ。

包括的なプロセスを記載するために使用される単語は、一連のゴールのために簡略化されることが多いとともに、自然言語で表現するには長すぎる、固有な問題に関連することが多い。従って、抽象化の様々なレベルにおいて、固有な問題のグループは、様々な抽象化されたレベルで、包括的なプロセスに関連付けられた名前を有することができる。

オブジェクト及びコンテクスト

図６Ｂを参照して、上記で説明した通り、オブジェクト及びコンテクストは、プロセス完了及びゴールの達成度における、ノードの影響を変更する。ノードは、コンテクスト又はオブジェクトが相違することの結果として、プロセス及び当該プロセスのゴールに、多かれ少なかれ影響を与えることになっても良い。いくつかの場合には、プロセスが分野に非常に特有であり、非常に特有なコンテクスト及び特有なオブジェクトを有する時には、プロセスノードは相違する。続いて、コンテクスト及びオブジェクトは、アクター、及び当該アクターの属性（又は、企業、又は企業の部門及び属性）によって影響される。よって、一般的には、オブジェクト又はコンテクストが相違することで、相違するアクターは、同じプロセスに対して異なる影響を与えるだろう。コンテクスト又はオブジェクト自体は、１又は２以上のプロセスゴール、又は１又は２以上の従属プロセスゴールに、多かれ少なかれ影響する可能性をもたらしても良い。

オブジェクト及びコンテクストの変化は、プロセスとゴール近接度との両方に影響する。ゴール近接度は、プロセスに応じて変化する。しかし、プロセスが非常に類似する場合には、当該プロセスは、異なる分野では相違し得るオブジェクト及びコンテクストを有する。従って、分野を越えてのオーバーレイの採用を容易にするために、オーバーレイは、分野に応じて、オブジェクトコンテクストとそのプロセスとの関係性を組み込む。そのため、新しい分野では、システムは相違するオブジェクト及びコンテクストをハイライトし、特に、各プロセスステップが、オブジェクト又はコンテクストの相違点に影響を受けている時には、各プロセスステップに対するゴール近接度を再評価することを要求しても良い。また、分野又は企業を越えての採用を容易にするために、オーバーレイは、コンテクスト及びオブジェクト及びアクター、ユーザ、認識構造の他の要素との関係を含んでも良い。

オブジェクト及びコンテクストは、構成要素に一般化又は細分化することができ、それらの間の関係性を有することができる。企業に関連するオブジェクト及びコンテクストは、それらの関係性ととともに、一般化表現及び構成要素を有し、それは、当該オブジェクト及びコンテクストが果たすゴール、及び関連付けられたプロセス又は計画に応じて変化する。

システムが、互いに動的に関係するべき全て又は一部の属性を要求する程度は、各分野の経験及び要求、及び、システムのクライアントアプリケーションに基づく。全属性が動的にアクティブではない場合には、属性が、通常影響するであろうエンティティを有する、当該属性の動的な相互関係は、デフォルトの状態においては一定に保たれる。例えば、アクターの属性が、便宜上、平均的であると考えられる時、プロセスステップ内で問題及び機会が発生する可能性に対するアクター属性の影響は、偏りがない。他の例では、プロセスステップで使用されるリソースの冗長度が平均的である場合には、ゴールに影響する当該プロセスステップの近接度は平均的である。プロセスにおけるエキスパートが、その分野において、プロセスを平均的なものであると考える時には、属性の影響は平均的である。

同時発生的なイベントに関して時間に関する指定事項とともに、オブジェクト及び／又はコンテクストは、類似イベントの２つの事象が実際には同じイベントであるか否かを決定することに役立つ。これは、関連する情報に関する検索のゴールが、イベントと同時発生的なコンテンツ及びデータを発見することであるときに、重要である。

ゴールの階層、及びゴール競合

任意の環境において、どの下位プロセスステップがより重要であるかを決定するために、プロセス内のゴール間でのゴールの階層及びゴール競合を調査することが要求される。プロセスが一定に適用されるほどに、ゴールの階層が一定になるとともに、ゴール競合による問題を回避するために、プロセスの設計に対して一層の注意が払われる。プロセスが変化し、新しいプロセスのプロセスステップ、及び新しいゴール構造を有するアクションの計画のようになる場合には、ゴールの階層及びゴール競合は、再確立される必要がある。さらに、十分に維持管理されないゴールの階層の結果として、不適切な結果の良くない影響と、ゴール競合の良くない影響とを軽減するために、新しいプロセスステップが適用される必要がある。

オーバーレイ関連性モデル：ゴール、プロセス、ノード

ゴール、プロセス、ノード間で整合的関係（一貫した関係）があることは有益であるが、不可欠ではない（以下、関連性慣習（relevance convention）と呼ぶ）。オーバーレイのユーザにとって、ゴール、プロセス、及びノード間の関係性が、整合性があるように見えるけれども、慣習に従っていない場合には、関連性の結果（つまり、関連性エンジンが出力する経験の事象）は、十分に満足のいくもののままであっても良い。なぜなら、一般的に、現在の慣習は、任意の整合性のある慣例によって、ゴール、プロセス、ノードをグループにしないからである。本開示の形態に係る、使用される関連性の慣習は、以下に詳述する。

ノード属性

ノード属性はノードを定義することの助けになるので、ノードはプロセス間の類似性、及び経験の事象間での類似性を描画するために用いられても良い。通常、これは、システムのエキスパートユーザによってのみ行われる。ノード属性は、以下の様にグループ化されても良い。

（１）ゴール及びアクター：ゴール競合を克服するために設計されたプロセス間、及びプロセスの背後にいるアクター間で、ゴール競合が存在する。例えば：法的契約は、競合がどのようにして回避又は裁定されるかに同意させるためのプロセスとして設計される。機械の設計は、機械製品の利益とコストとの競合を克服するプロセスである。タクシーメータは、価格に関して、タクシーサービス業と、顧客との間の競合を克服するプロセスを自動化したものである。

相違するアクターのゴール間、及び／又はメインのゴールと条件付きゴールとの間で、ゴール競合が存在する。環境内で利用可能な資産によって、ゴールを達成することが助けられているうちは、ゴールと、環境内にある障害との間で、更なる種類のゴール競合が存在することがある。資産及び障害は、コンテクストに特有であり、特定のゴール競合によって影響されている。例えば、質とコストとの間の競合は、製造品の質及び効率性に影響する。各製品は、このゴール競合によって影響される、特定の資産及び障害を有する。製品によって決定される、製造プロセス及び機械機構の製造における、質とコストとの間での慣習的なゴール競合は、関連付けられるノードを有する。このゴール競合に対して、最も密接に関連付けられるノードは、任意の製品故障の原因ノードである。従って、ゴール競合は、原因プロセス内のノードに密接に関係する。

（２）資産及び障害：資産及び障害は、各ノードに最も関連付けられたコンテクスト及びプロセスに特有な要素である。それらは、コンテクストに従って変化するプロセス内の要素であるとともに、関連するコンテクストを一般化することでグループ化された場合には、より包括的な資産及び障害に一般化される。再び、製造品の例、及び質とコストとの間での本質的なゴール競合の例を参照すると、同じコンテクスト（例えば、制御油ポンプ）において、設計に共通性がある類似の製品のグループには、影響される資産及び障害によって特徴づけられる類似の問題があるだろう。さらに、同じコンテクストのグループ内の製品間での設計の多様性のために、当該製品間で相違する問題ノードに関連付けられた、資産及び障害もあるだろう。この場合には、コンテクストの構造は、個別の特定の問題、及び関連付けられた資産及び障害を有する更なる個別の製品に、当該製品を分ける必要がある。これは、この非常に特定のコンテクストでグループ化されたノードは、異なるコンテクスト間では一般化されないことを意味する。しかし、全てのノードは、質とコスト間のゴール競合の元でグループ化されることになるだろう。そのため、コンテクストのグループは、アクティブな問題又は機会のノードにおいてアクティブである、資産及び障害を管理する。いくつかのコンテクストは、より包括的ノードを伴い、より容易に一般化する。；いくつかのコンテクストは、非常に特有なコンテクストに特化したままになる。

ノードに対する資産と障害との関連性は、コンテクスト構造によって管理される。ノードは、プロセス内の問題及び機会を発生し得る障害に対峙する、資産を明示するものである。当該ノードが、プロセスのゴールと、プロセスが起きるコンテクストの資産及び障害間に替えて、アクター間のゴール競合の結果ではない時に、問題及び機会がアクティブである場合には、関連する資産及び障害はアクティブである。

（３）原因ノード及び影響されるノード：原因ノードは、影響されるノードを有するとともに、問題、機会、又はイベントとして、所定のノードが、なぜアクティブであるかを記載する。影響されるプロセスにおいてアクティブになり得るノードと同じく、原因プロセスにおいてアクティブになり得るノードは、ノード属性を識別するために使用される。

（４）ゴール競合と原因ノードとの関係性：影響されるノード属性は、特定された分野の知識なしのグループに、より変化しても良いとともに、あまり容易ではなくても良い状態において、類似の抽象化された属性を有するノードによって、同一の抽象化されたグループに属するゴール競合が発生する。原因ノードと影響されるノードとの間での、原因と結果の関係性は、一方のコンテクスト特有分野から、他方のコンテクスト特有分野へ、ノードを関連付けることに役立つ。

エキスパートユーザのプロセス

オーバーレイのエキスパートユーザがシステムの認識構造に慣れた場合には、当該オーバーレイのエキスパートユーザは、抽象化のコンテクストに特有な様々なレベルで、ノード属性を割り当てる。そして、オーバーレイのエキスパートユーザは、より高い抽象化のレベルに、ノード属性を割り当てる。また、エキスパートユーザを支援するために、モデルノード属性に対して、コンピュータ化された方法が使用されても良い。

ノードの識別

以下の手順（図９に図示）においては、抽象化の様々なレベルでノードを識別するために、本開示に従って、エキスパートユーザ９２０によって、次の手順に進んでも良い。
（１）ノードを識別：オーバーレイのエキスパートユーザは、他のプロセスとの類似性が探される、コンテクスト特有プロセス内で発見されたノードを識別する（工程９２１）。；
（２）抽象化の様々なレベルで、各ノードに関係するコンテクストを識別する（工程９２２）。これは、問題になっているプロセス、及び当該プロセスに依存するプロセスが、コンテクストの特有性を分析される企業に特化する、分野（コンテクストに特有）プロセスモデルを通じて達成される。
（３）より低いコンテクストレベルのノード属性を識別する（工程９２３）。：オーバーレイのエキスパートユーザは、上記で記載するように、ノード属性９３０として、ノード属性を識別する：属性９３１は、コンテクスト特有プロセスのゴール及び条件付きゴール；ゴール競合；コンテクストに特有な資産及び障害；プロセス（当該プロセスと、他のプロセスとの類似性が探される）のノードの、コンテクストに特有な原因と結果；を含む。
（４）抽象化された、より低いコンテクストレベルのノード属性の組から選択する（工程９２４）。つまり、上記ステップ１〜３でのコンテクスト抽象化の段階で、予め定着させたノード属性の組から選択する。オーバーレイシステム９４０は、ユーザに、より高いレベルのノード属性の選択を提示する。；エキスパートユーザは、ステップ３で識別された、より低いレベルのノードの属性に適合させるために、より高いレベルの属性を選択する。
（５）より高い又は最も高いレベルのコンテクストの、ノード属性の組を選択する（工程９２５）。：オーバーレイは、より高い又は最も高い、コンテクストのレベルの企業のノード属性の選択を表示する。エキスパートユーザは、ステップ３で識別された属性に適合する、最も高いレベルの属性を選択する。

上記の一連のステップは、ノードの選択に適用することができ、その結果、プロセス類似性を識別できる。又は、上記の一連のステップは、ノードに適用され、その結果、ノード類似性を識別できる。

プロセス、及びノードの関係性

プロセス類似性は、より高い抽象化レベルのノード属性と、コンテクスト特有なプロセスノードの属性とを比較することで識別される。例えば、軍事訓練演習において、対象を見ることのような、コンテクスト特有プロセスは、ノード（例えば、物理的な障害のために見ることができないこと、照明環境が悪いために、見ることができないこと、スコープが機能不全であるために、見ることができないこと等）を有する。続いて、これらは、オーバーレイのエキスパートユーザによって、より高い抽象化レベルのノード（例えば、障害のために見ることができないこと、環境のために見ることができないこと、視覚を向上させる装置がないために、見ることができないこと）に抽象化される。新しく抽象化されたノードのクラスタは、対象を見るとの特有なプロセスの抽象化である、より高いレベルの包括的なプロセスを発生させる。

しかし、ノード属性を介して、より高いレベルの包括的なプロセスを、より低いレベルのコンテクスト特有プロセスに照合するためには、抽象化とは逆の処理が行われても良く、それは、より包括的なノード及び、それらの属性を選出し、他の分野において、それらと、コンテクスト特有ノードとを照合することによって、逆順序に処理を行っても良い。このようにして、相違するコンテクストではあるけれども、相違する分野、又は類似する分野の二つのプロセスは、類似性に対して照合できる。続いて、この類似性は、コンテクストに特有な他の分野での問題及び機会を予測するために、コンテクストに特有な分野で、経験を役立てる能力を提供する。

類似プロセスの識別

以下の手順（図１０に図示）においては、コンテクストに特有な、元のプロセス１０７０に類似する、他の分野のプロセスを識別するために、エキスパートユーザによって次の手順に進んでも良い。

（１）この手順によると、以下の通り、包括的なプロセスは最初に識別される。：企業内のコンテクスト特有プロセスは、そのコンテクスト構造を有する。コンテクスト構造は識別されるとともに、比較されるプロセスの新しい分野に対して照合される（工程１０７１）。これは、選択されたコンテクストの抽象表現は、オーバーレイシステムで機能するべきと見積もられる個数と同等の多くの分野間で照合されることを意味する。そして、コンテクスト特有ノードは、コンテクストに最も特有なレベルで識別される（工程１０７２）。これらのコンテクスト特有ノードは、上記に示す特定の方法を使用するオーバーレイのエキスパートユーザによって、ノード属性１０８２を割り当てられた。当該ノード及び当該ノード属性は、オーバーレイのエキスパートユーザによって、より高いコンテクストレベルに抽象化され（工程１０７３）、新しい抽象化されたノードクラスタを取得する（工程１０７４）。当該新しいノードクラスタは、元のコンテクスト特有プロセスの抽象化である、より高い包括的なプロセスを発生させる（工程１０７５）。

より高いコンテクストに抽象化された元のノードを、最も多く有するプロセスは、元のプロセスに関係する、最も高いレベルの包括的なプロセスである。包括的なプロセスは、反復的に識別される（工程１０７６、１０７５）。；ａ）エキスパートユーザが、当該プロセスに名前を付けて、包括的なプロセスの組に、当該プロセスを割り当てることで、上記識別処理は行われる。；ｂ）また、プロセスが一意であることを確かめるため、及びプロセスが、同一ノード及び同一ノード属性を有することで、当該プロセスが予め包括的なプロセスの組にはないことを確かめるために、エキスパートユーザが、上記の方法でノード及びノード属性を照合することで、上記識別処理は行われる。；ｃ）エキスパートユーザが、予期される包括的なプロセスを包括的なプロセスステップに細分化し、これらのより小さい構成要素のステップにおけるノード属性の照合に関する上記プロセスを適用し、その構成要素のステップから、より大きな包括的なプロセスにまとめることで、上記識別処理は行われても良い。しかし、小さい構成要素のステップから、大きい包括的なプロセスにまとめることは、同じ構成要素のステップが必要であるだろうから、プロセスの一般性のレベルを制限する。機械的な機能において、及び他のより固定されたプロセスにおいて、容易にステップを変更できない場合には、より小さい構成要素のステップの一般性を評価する方法がより好ましい。プロセスステップがまだ定義されていない計画のためには、多くの構成要素のノードを有する、より複雑なプロセスから開始する方法がより好ましい。

つまり、エキスパートユーザが選択するもの、又は注目するものに応じて、（ノード属性、及びより高いプロセスレベルへのノード属性の抽象化に関する上記の方法が、適用される）プロセスの細分化のレベルは変化することがある。もし、より大きなプロセス内のより下位のレベルのプロセスステップ（細分化されているプロセスステップ）に、当該方法が適用される場合には、ゴール近接度と、下位のプロセスの個数の照合とによって、プロセス類似性はより高いレベルのプロセスへ向けられる。もし、適用された方法が、より高いレベルのプロセス（粗いプロセス）に適用される場合には、下位のステップの類似性については強調せずに、プロセス類似性はより高いレベルで表現される。各方法は、異なる利点を有する。細分化するほうの方法が、類似ステップ及び類似ゴールを有するプロセスを比較する上で良い方法であるほどに、より粗いほうの方法は、異なる方法ではあるが、類似ゴールのプロセスを比較する上で最適な方法であるだろう。

（２）コンテクストに特有な多くの相違する分野で、類似プロセスを発見する。：最も高いレベルの包括的なプロセスを識別（工程１０７７）後、エキスパートユーザは、抽象化である、より多くのコンテクスト特有プロセスを発見することに処理を進める。一般的に、高いレベルのプロセスは、相違する分野１０８１内の、コンテクスト特有プロセスに対して包括的であるだろう。

どのコンテクスト特有プロセスが、最も良く合うかをテストするために、包括的なプロセスノードの属性に最も近い、ノード属性の組を有する最も多くのノードを、どのコンテクスト特有プロセスが含むかを発見する（工程１０７８）。これは、最も高いレベルから開始し、様々な抽象化レベルでノード属性を比較することによって達成される。

（３）夫々の分野内で、共通のプロセスの重要性を比較するために、ゴール近接度を適用する（工程１０７９）。プロセスが役立つゴールにおける当該プロセスの影響が、より重要又は類似性基準をより明らかにする事例において、このステップは、以降のステップよりも重要である。別のコンテクストで元のプロセスを実行する場合には、新しいコンテクスト特有プロセスが、メインのゴール及び条件付きゴールに対して、類似のゴール近接度を有するか否かを、この類似性はテストする。これは、比較されるコンテクスト特有プロセス間で、共通の抽象化を有するノードによって潜在的に影響される従属プロセスを含む。プロセスの重要性が、比較されるプロセス間で類似であるべき必要がある場合には、これは、コンテクスト類似性を評価する前に行われる。

（４）選択されたノードに最も影響されやすいコンテクスト／オブジェクトクラスタを発見するために、ノード属性テスト（ステップ１０８０）を適用する。このステップにおいては、選択されたノードに対する影響の受けやすさを確かめるために、複数の分野（たいてい、非常に類似する分野）に関係する、そのようなコンテクスト及びオブジェクトの機能に関する知識が要求される。コンテクストに特有な障害及び資産が、関連するフォーカス対象としてより重要である場合、且つ、特定の事例の複数のノードのコンテクストに関係する類似性が、プロセスの類似性より重要である場合には、このステップは先行するステップよりも重要である。つまり、ノードの選択は、狭い範囲の選択であり、広い範囲のプロセスノードを完全には満たすものではなく、共通の興味のノードを有する、より多数のプロセス及びコンテクストをグループ化したものであっても良い。例えば、多くの機械故障は、同じ故障に影響されやすい設計、製造、操作の基準を有する、特定の機械に適用するケースノード（case nodes）を有する。これらの他の機械を発見するために、選択された包括的なプロセス内で選択されたノードは少ないことが必要であるとともに、エキスパートユーザは、当該他の機械の知識、及びそれらの影響の受けやすさに基づいて、ノード属性の照合を行わなければならない。

実際には、複数のコンテクスト／複数の分野に関係する、類似の単一ノードを発見することは、まさに、類似ノードのクラスタを発見することと同様に重要であることに留意すべきである。一形態においては、ノードに対する第１のコンテクスト及び第２のコンテクストを識別することによって、この問題は取り扱われても良い。当該ノードは、第１のコンテクストに特有である。そのため、当該ノードは、第１のコンテクスト特有ノードとして特徴づけられる。第２のコンテクストは、第１のコンテクストより高いレベルで抽象化したものである。そのため、当該ノードは、第２のコンテクストに特有ではない。そして、第１のコンテクスト、第２のコンテクストの夫々に従って、当該ノードに関連付けられた、二組のノード属性があるだろう。そして、包括的ノードが、高いコンテクストレベルの企業ノード属性に従った属性を有する状況においては、少なくとも一つの包括的ノードが識別されても良い。

複数の事象でのシステムの定着化

図１１は、システムに複数の事象を定着させるための手順１１８０を図示する（企業の経験を収集できるようにすることによって、問題を解決することを容易にする結果、又は、オーバーレイを用いて機会を利用する結果である）。ユーザは、プロセス、ノード、ゴール、及びゴール近接度を入力することによってシステムを定着させる（工程１１８１）。これらは、産業上の実務家の経験を用いて入力されても良い。インデックスエンジン１１８７からの助けを借りて、エキスパートによって詳述された及び／又は企業によって記録された、インデックスストーリー１１８５へ事象１１８６は入力される。ノードは、事象（詳述されたストーリー）で発見された原因、結果、改善、説明についての検討で明らかにされた、問題及び機会である。この事例では、コンテクスト特有プロセス、コンテクスト、ゴール、原因、結果、及びゴール近接度は確立されているものとする。

プロセスの抽象化：コンテクスト間の類似性

システムを定着させる第２の段階では、エキスパートではないユーザが、複数の分野及び複数のコンテクストに関係する類似プロセスを発見できるようにするために、オーバーレイのエキスパートユーザが、プロセスの一般化及びノードの一般化を適用する（工程１１８２）。オーバーレイからのインデックス付けの支援を使用するエキスパートは、プロセス一般性及びプロセス類似性を推論するために、ノード属性を介してノードを照合しても良い（工程１１８３）。

オーバーレイの方法ステップ

図１２は、オーバーレイシステムが企業内の問題を発見する方法、及びユーザに関連する過去の経験を提供、つまり、過去のリスク、原因、結果、改善から学んだ教訓（ストーリーとも呼ぶ）を提供する方法を図示するフローチャートである。

オーバーレイによって実行される方法は、企業重要点のフレームワークを構築することに関連する。企業のゴールは（上記の通り、企業ゴール及びメインのゴール）は、工程９０１において確立される。これらのゴールを達成するために設計された様々なプロセスは、工程９０２において確立される。プロセスの影響（ゴールの近接度）は、工程９０３において確立される。工程９０４においては、プロセスに関係する問題、機会、イベントが識別される。工程９０５においては、プロセスの記載；問題；機会；プロセスに影響するイベント；原因、結果、リスク、及び改善；プロセスが、互いに影響を与える方法に従って、企業重要点のフレームワークが構築される。

フレームワークの構築は、類似のプロセスを識別することを含むことに留意すべきである。上記の通り、これは、共通のプロセスステップを識別すること、及び／又は様々なプロセスに他の基準を適用することを伴う。

プロセス一般化を識別するために、且つその結果として、包括的なプロセスを識別するために、プロセスは分析される（工程９０６）。工程９０７において、包括的ノード、及び固有なテーマは、プロセスから識別される。企業内部コンテンツ及び企業データは走査され、走査されたコンテンツは、インデックスエンジンを使用して、企業重要点に対してインデックスを付される（工程９０８）。システムは、所定のプロセスで、所定の問題の影響を決定し、当該問題に最も関心があるユーザに、当該問題の説明を送信する（工程９０９−９１０）。システムは、問題、問題の原因、問題の改善に影響される重要な事項におけるユーザの協力にフォーカスして、重要点のフレームワークに従って、構造を協調させることへ処理を進める（工程９１１）。システムは、インデックスを付された情報から、関連する過去の経験を検索し、ユーザに対して、それら（問題、問題の原因、問題の改善）の関連するストーリーを出力する（工程９１２）。

オーバーレイを使用しての問題の解決

オーバーレイを使用して、ユーザの視点から問題を解決する（あるいは、機会を利用、決定、質問に回答する）方法は、図１３Ａ及び図１３Ｂに示す接続されたフローチャートで図示される。

本開示に記載される方法は反復的であることに留意すべきであるとともに、対象の問題又は機会が、過去の問題又は機会に対してどの程度類似するかに、ステップの順序は依存するとともに、対象の問題及び機会が、既知のプロセスでどの程度良く管理されているかに、ステップの順序は依存することに留意すべきである。もし、プロセス又は機会が周知ではなく、改善可能なプロセスが十分に確立されない場合には、ステップ及び強調の順序は本開示に記載されるものとは異なる。

問題（機会、決定、又は質問）１００１を取り扱うユーザは、まず、解決すべき問題に関して、ユーザ自身の頭の中にある、仮の計画の概略を作成する（工程１０１０）。；当該仮の計画は、システムの外部で考案される。対応するシステムアクション（工程１０２０）において、当該計画が組織する、数個の包括的なプロセスを、ユーザに選択させる。包括的なプロセス又はゴールにおける、予め設定された検索で検索された、マイナーな単語の検索の組み合わせを含むことによって、これらのプロセスは、様々な方法で出力される。；つまり、これは、認識構造の基本的な概念の検索を提供するためである。たいてい、狭い範囲内でのプロセスの選択は、ゴールの検索結果であるプロセスの選択より、プロセスに特有な選択になり、包括的なプロセスの検索結果であるプロセスの選択に比べ狭い範囲のものであり、特有なプロセスの検索結果である、プロセスの選択に比べて広い範囲のものである。

工程１０１１において、ユーザは、狭い範囲のプロセスの組み合わせを選択して、システムによって出力されるプロセスに対応するゴールを選択し、システムは、ゴールの初期状態の階層を生成する（工程１０２１）。プロセスを実行するアクター及び当該プロセスのゴールが、当該階層にどのように影響するか、及び選択されるゴールがどのように互いに競合するかを考慮して、ゴールの階層は修正される（工程１０１２；工程１０２２におけるシステムアクション）。選択されたプロセスが少ないほど、（さらに、問題及び機会がどの程度周知であるか、どの程度確立されているか、改善のためのアクションのプロセスがどの程度周知であるか、どの程度確立されているかに依存して）、選択されたプロセス内で、ゴール競合及び階層は同じになるだろう。

工程１０１３において、ユーザは、選択されたプロセス（つまり、概略化された計画内において、選択されたプロセス）から、固有なノードを検索する。対応するシステムアクション（工程１０２３）は、プロセスの組に対して、固有なプロセスを検索することである。ユーザは、当該固有なプロセスを用いて、関係するプロセスをハイライトする。システムは、識別された固有なノードに関係することが既知である、さらに多くのプロセスを選択する（工程１０１４−１０２４）。そして、ユーザは、プロセスの問題／機会、及び固有な問題／機会によって組織された、選択されたストーリー及び機会を選択する。ストーリーは、ノードの共通性、及びプロセスに関係するゴール近接度に応じて、プロセスに関連するグループを発見することによって検索される（工程１０１５−１０２５）。

ユーザが、過去の経験を集めるとともに、ストーリー（問題、機会、及び興味の対象／予期しないイベントに関係するコンテンツ及びデータ）によって、ユーザ自身の経験を思い出す場合には、システムは、結果として発生するゴールの階層、及びゴール競合に最も適合するプロセスを検索できるように、ユーザがゴール及びゴールの階層を再調整すること、及びゴール競合をハイライトすることを支援する（工程１０１６、１０２６）。

出力されたストーリーを用いて、ユーザは、仮の解決策を作成し、テストする（工程１０１７）。そして、ユーザは、更なるプロセスを選択し、概略化されていた計画を修正し、修正された計画をテストする（工程１０１８、１０１９）。オーバーレイによって管理される、共通の検討ドキュメントでは、同僚との検討で記載されるもの以外は、当該計画は、システムに保持される必要はない。もし、当該計画を保持することに利点がある場合には、当該計画は保持されても良い。；例えば、もし、経験が、将来、参照する上で役立つと考えられる場合には、特に、もし、当該計画が、ある環境において、置換される標準的なプロセスに比べ、良いゴールの階層を有する場合には、当該計画は保持されても良い。検索されたストーリーは、ユーザが実務家の経験を集めて、最も実現可能性の高い計画を考え出すことを支援する。オーバーレイは、ストーリーを介して、過去の経験を検索することを支援するとともに、検討する際に、正しい利害関係者が連携することを支援する。

オーバーレイシステム

オーバーレイを実行するシステムは、ノード間又は企業重要点間の関連性を達成する方法を定義する、インデックス構造（あるいは、インデックスエンジン）を含む。当該インデックス構造は、ノード又は企業重要点に関連するビジネスオブジェクトを含む、単語パターン及びデータパターンを含む。また、システムは、既存又は新規のコンテンツを走査するため、及び当該コンテンツをプロセスノードに割り当てるために使用される、言語構文解析装置及びスキャナーを含む。オーバーレイのインデックス構造は、慣用的なサーチエンジンを使用するよりも、効果的に、ユーザが企業重要点に関連する情報を発見することを支援する。

企業内のコンテンツの関連性は、プロセスノードをアドレッシング（addressing）することによって、排他的に決定されることに留意すべきである。ユーザは、インデックス付けを実行するために、認識構造を定義する。関連性のために不可欠な基準は、認識インデックス構造内で定義される。

本実施形態に係るオーバーレイの実装は、図１４に体系的に示される。オーバーレイは、企業コンテンツ、企業データ、ビジネスオブジェクトを含む外部関係データを走査するためのコンテンツスキャナー１１０１と、言語構文解析装置１１２０と、インデックスエンジン１１５０とを含む。当該スキャナーは、様々なソース、例えば、ｅ−ｍａｉｌ１１０２、ドキュメント１１０３、ビジネスオブジェクト１１０４を含むアプリケーションデータ、及びウェブコンテンツ１１０５から、コンテンツを取得する。言語構文解析装置１１２０は、走査されたコンテンツ１１１０内のコンセプトを識別し、それらのコンセプトに関連する重要点を割り当てるために、インデックスエンジン１１５０と連携する。アプリケーションデータの場合には、重要点の関連性は予め設定されるので、オーバーレイは、アプリケーション内の特定の場所の特定のデータを検索する。出力される重要点インデックス１１６０は、ユーザインタフェース１１７０の範囲をサポートする。ユーザインタフェースは、ユーザに問題を警告するために、重要点インデックスを利用し、ユーザ同士が協力できるようにし、利害関係者であるユーザのためのプロセスへと渡される情報を制限し（もし、今のところは、情報が、利害関係者ではないユーザのための下位のプロセスに、直接的に関係するのみの場合であっても）、関係する過去の経験を検索する。示される形態において、当該ユーザインタフェースは、ウェブベースのサーチインタフェース１１７１、ウェブベースの連携ツール１１７２、アプリケーション統合のためのポータルベースのインタフェース１１７３、問題に関連する警告、協力、検索のための携帯機器のインタフェース１１７４、及び重要点インデックスを、１又は２以上の望ましいオフィスアプリケーションに統合するためのインターフェース１１７５である。

インデックスエンジンは、インデックスモデル１１３０を用いて、企業重要点に対する情報にインデックスを付す。インデックスモデルは、事象の履歴（企業が過去に重要点をどのように扱ったかというストーリー）１１０６、及び企業内における、現在の問題解決の事象１１０７を用いて構築される。従って、現在及び過去の事象の両方が、システムを定着させるために使用される。現在の事象を分析することで、認識構造に対する事象にインデックスを付す。分離したプロセスが直接的には、企業の問題の解決方法の一部ではない場合には、過去の事象が経験として入力される。

さらに、システムを定着させるときには、インデックスエンジンは、コンテクストを相互に参照する。；これは、過去に定着させられた分野からのプロセスの包括的視点、及び包括的ノードを使用することによって、システムが、新しい分野で、経験とコンテンツに関係する単語概念とを伴って、定着するようにできる。コンテクスト特有ノードは、より包括的なノードを定義する。続いて、これらのより包括的なノードは、コンテンツ／分野に特有な包括的なプロセスコンポーネントを定義する。これらの包括的なプロセスコンポーネント、及びそれらの包括的ノードは、新しい分野において、いくつかの一般性レベルで存在することになるだろうし、且つその結果として、この異なるコンテクスト／分野に特有なノードを示すだろう。

コンテンツ管理システム、検索ソリューション製品、ＥＲＰ（Enterprise Resource Planning）システムのようなサードパーティー製品を含む他のソフトウェア製品に、又は、重要点関連性ソフトウェアの追加により有益であろう他のシステムに、インデックスを付与するサービスを、インデックスエンジンは提供しても良い。

一形態において、インデックスエンジン１１５０は、ウェブサービスを介して提供されるミドルウェアサービスである。

本開示に係るシステムは、次のことに使用されても良い。
ノードに関連するコンテンツを識別する；
認識構造において、互いにノードを関連させることによって、企業を理解する；
企業内の問題を解決する；
企業内で、はみ出た情報を発見する。

オーバーレイシステムを使用するいくつかの利点は、次の通りである。
比較される二つのプロセス間のプロセス類似性を評価する；
企業に関連するプロセス及び計画を説明する；
問題及び機会について、関連する情報を発見する；
問題及び機会について、はみ出た情報（未解決の通知）を発見する；
問題及び機会のリスク及び結果を評価する；
問題及び機会を予想する；
問題及び機会を診断する；
問題及び機会に対する改善のためのアクション計画を適用する；
問題及び機会について戦略的な計画を作る；
産業における原因と結果に対して、ユーザの洞察を与える；
問題及び機会を扱うことにおいて、ユーザに独創的であることを許す；
企業の業務に関する複雑な現象を説明する際に、又は、企業が活動する環境であって、企業に非常に大きく影響する環境を説明する際に、ユーザを助ける；
問題を解決する際に、又は会社のための機会を利用する際に、会社を助けるエキスパートを助ける；
企業活動に基づいて、認識構造の要素間の関係性を発見する。

例えば、工場の一つのフロアでは、典型的に、システムのユーザには、定義された機能、及び客に製品を届けるとの個々のゴール及び包括的ゴールを有する、マネージャー、販売者、管理補佐、エンジニア、メンテナンス従事者が含まれるだろう。これらのユーザの多くは、携帯電話、タブレット、又は他の個人電子機器（personal electric device（ＰＥＤ））のような携帯機器により、企業のモデルにアクセスする。しばしば、これらの携帯機器は、限定された領域があるユーザインタフェース（タッチスクリーンを含む表示スクリーン）を有する。企業の完全なノード構造が表示スクリーンに表示される、と仮定すると、ノードは、ユーザが見るには、又は、ユーザが興味の対象のノードを触ることでアクセスするには、小さすぎることがある。そのため、個々のユーザに、興味の対象のノードだけを、さらにオプションとして、興味の対象のノードの一方の側に、いくつかの追加ノードを加えて図示するために、システムは設計される。特定のユーザのゴールが変化すると、典型的に、ユーザの表示スクリーンに図示される興味の対象のノードも変化するだろう。

図１６を参照して、システム１２００は、稼働状態のイベント（live event）の各ユーザの関連する現在の状態を反映するために、複数のユーザインタフェース１２０４ａ―１２０４ｅを調整する機能１２０２を含む。これは、ユーザとユーザの現在の状態とを関連付けたコンテクストによって選別されたノードのうち、相互に関連付けられたノード１２０６の組の部分だけを、各ユーザに提示することを意味する。各ユーザインタフェース１２０４ａ―１２０４ｅは、制限された表示領域を有するディスプレイ１２０８ａ−１２０８ｅを有する。もし、全てのノード１２０６が、制限された表示領域１２０８ａ−１２０８ｅに表示されたら、表示されるノードは、表示、又はユーザによって相互作用させるには、小さすぎるだろう。また、ユーザの現在の状態は変化しても良く、現在の最新状態に関連する情報の表示空間が大きくなるように、システム１２００は、ユーザインタフェース１２０４の表示を変更することを要求されても良い。しかし、全てのノード１２０６は、原因、結果、及び類似性によって関連しているので、利害関係者に割り当てられた任意のノードを表示することが要求される場合には、ユーザは上記とは逆手順の処理を行っても良い。

機能（設備；facility）１２０２は、ユーザ／利害関係者に最も関連性のあるノードにフォーカス対象のユーザインタフェースを調整し、ユーザ／利害関係者に関連する状況の進展具合に応じて、ユーザ／利害関係者に最も関連するノードの組み合わせを変更しても良い。システムは、ユーザ／利害関係者に関連した、最新の状態に関連する情報の表示空間が大きくなるように、システムは、ユーザインタフェース１０２４ａ―１０２４ｅの表示を変更しても良い。しかし、スクリーンに示されている現在のフォーカス内容に関係なく、ユーザの裁量で、ユーザに関連する全てのノードはアクセス可能なものである。

機能１２０２は、ノード１２０６を通じてアクセス可能であって、内部に保持される情報が現在のものであることを確認するための、及び各ユーザの状況が現在のものであることを確認するための、多数の外部の機器と通信する。一つ目の外部の機器は、キーボード１２１０であっても良い。二つ目の外部の機器は、パイプの漏れ、又はパイプの破裂を認識するために、火気検出器、又は湿気検出器を認識するための、温度検出器又は光検出器のような、リモートセンサ１２１２であっても良い。また、機能１２０２は、インターネット１２１６を介して、リモートサイト１２１４に接続したままであっても良い。そのようなリモートサイトは、企業の他の部門、外部のデータベース（例えば、計画の構築又は配線図にアクセスするための管理のサイト）、公的なデータベース（例えば、検索エンジン）、及び私的なデータベース（例えば、構築者又は製造者から利用可能な装置の部品のため、又は船のための結線図）を含んでも良く、これらに限定されない。

機能１２０２は、非トランジェント（non-transient）なデジタル記憶媒体、また企業のモデル、企業のコンテンツ、及び企業のデータを格納するデジタル記憶媒体でエンコードされた命令を実行可能なコンピュータが読み取り可能な媒体を有するコンピューティングデバイス１２１８を含む。ここで、当該モデルに関連付けられたプロセスは、ノード、ノード間の関連性のコンピュータが読み取り可能な記載、及びコンテンツ及びデータ及び異なるノード間の関連性に関する、コンピュータが読み取り可能な記載を含む。

機能１２０２は、伝送機器１２２０を介して、各ユーザと通信できる。当該伝送機器は、ユーザインタフェース１２０４ａ―１２０４ｅを通じて、各ユーザに情報を送信、及びユーザから情報を受信する。任意の通信形式、例えば、携帯電話ネットワーク１２２２、無線ローカルネットワーク、又はインターネット１２１６が利用されても良い。データベースの基礎にある情報の変化からだけではなく、オーバーレイによって制御されるユーザインタフェース１２０４ａ―１２０４ｅへのユーザの直接入力を介して、ノード１２０６をインスタンス化することは有益である。これは、データベース内、又はスキャナー等によって処理されるべき、コンピュータ化された他の機能内の情報として扱われるが、オーバーレイによって、制御されるユーザインタフェースを介して、当該情報は入力されるだろう。この情報は、ユーザインタフェースによって形成されたノード１２０６の単純な選択、又は、ノード１２０６及び／又はユーザによって入力されたコンテンツに関係する、ユーザのインスタンス化アクションの選択肢であっても良い。画像や映像のような情報は、携帯機器のディスプレイ１２０８ａ―１２０８ｅに表示される機能１２０２によって、又は携帯機器を介して、利用可能になる。ユーザインスタンス化アクションは、伝送機能１２２０、１２１６、及びコンピューティングデバイス２０１８を介して、ユーザによって、機能１２０２に入力される。

ユーザインタフェース１２０４、相互関係ノード１２０６の構造、及びデータベース１２２４内のデータは、ミドルウェアサービスとして存在する。このミドルウェアサービスは、ユーザインタフェース１２０４に何らのプログラム上の変化を要求することなく、ロジック／コードの修正、及びデータベース１２２４の修正、及びノード１２０６の修正をできるようにする。

オーバーレイは、原因、結果、類似性によって接続される、相互関係ノードの組み合わせを繰り込む。また、当該原因と結果は、定式によって、及びノードに関係する特性間の関係性によって決定できる。慣用的なプログラミングでは、関係性に対して変更が行われるとともに、問題及び機会を表すデータに対して変更が行われる。これらの変更が行われた後、ユーザに対してこれらの新しい関係を提示するために、新しいユーザインタフェースが設計されることが必要になる。本実施形態は、２番目のプログラミングを行うことを回避する。

ノード１２０６間のコード化された関係性１２２６を、明白にすることができる。そして、もし、原因と結果を描画、及び影響及び原因から派生するものを描画して、当該ノード内、及びそれらが接続する定式内で変化するコード／ロジックをプログラミングすることによって、全てのノードが他のノードに接続される場合には、別の例におけるユーザインタフェースで与えられる情報の関係性も変化させることなく、コード／ロジックがプログラミングされる。システム１２００は、データベース１２２４を構築する。当該データベース１２２４は、データの各インクリメントが、少なくともノード１２０６に関係するとともに、一のノード１２０６から他のノード１２０６´への関係性が、一のノードから他のノードに関係するコード／ロジックによって記載される。当該ノードは、原因と結果を描画、及び原因と結果から派生するものを描画する、アプリケーションのコード／ロジックによって互いに関係する。制限された表示領域のディスプレイ１２０８のユーザインタフェース１２０４上に、互いに直接にリンクされたノードに対応してまとめられた、各ノード１２０６、１２０６’に関連するデータベース１２２４からのデータが表示される。これらのノードは、原因と結果によって、及び原因と結果から派生するものによって、互いに関係する。

当該ユーザインタフェースは、現在起きているユースケースのためのプログラムとして設計されていない一連のものである。先行技術のユーザインタフェースは、固定された所定のユースケースに合わせるために設計されている。例えば、ナビゲーションのオプションの既定の選択肢を提供することによって、火災が発生したビル内での出口への経路を決定するユーザインタフェースがあるだろう。異なるユーザインタフェースは、ビルからの脱出と、脱出に内在する、足の骨折のような緊急事態とのために必要とされるだろう。異なるユーザインタフェースは、避難者の位置状態を監督する調整者のために必要になるだろう。オーバーレイのユーザインタフェースは、将来の予期しないユースケースを含む、全てのユースケースに適合する。なぜなら、オーバーレイのユーザインタフェースは、システムのロジックを含み、将来のロジックを入れた連続的なノード構造から引き出されるからである。さらに、システムのロジック及び当該システムの各属性の状態は、ノードと、当該ノードの夫々のノードとの間の、原因と結果のリンクによって描画されるので、記載するために二つの変数がある。；それは、ノードと、他のノードとのリンクである。これは、ベクターマップに類似するトポグラフィカルマップ内で、グラフィカルに描画できる。しかし、他のノードへのリンクを加えたノードと、親ノードから子ノードを展開又は折り畳む能力との二つの変数を有するだけで、このトポグラフィカルな描画を可能にして、ノードの数を増減することは、状況を理解するためのズームアウトと、特定のノード及び関係する情報にフォーカスするためのズームインとをユーザが、結び付けられるユーザインタフェース上で表示される。現在、プロセスが順次的であるか否かに関わらずに、及びそれらが互いにどの程度関係するかに関わらずに、及びどの程度の数のプロセスが描画されているかに関わらずに、プロセスのグループを描くユーザインタフェースは、現時点では全く存在しない。つまり、数千のノードの選択肢から、下位の最も低いノードのうちのいずれか一つへフォーカスするように誘導（ナビゲーション；navigation）できて、且つ、これらの外部のものの間のノードで任意の選択からナビゲーションできて、そして連続的な描画でそのようにできて、グラフィカルであるユーザインタフェースは、現時点では全く存在しない。

ユーザがズームインモードにおいて見たくなる表示は、ノード及び当該ノード間のリンクよりも、むしろ、ノード及びリンクの属性の表示（ビュー；view）かもしれないが、これらの属性は、フォーカス対象の当該ノード及びリンクによって、動的に生成された基礎にあるものである。プログラム的には、表示される属性は生成されない。詳細なインタフェースにおいて、動的に、ノード属性が生成される。

これは、詳細化又は予め定められてプログラム的に生成された各ユーザインタフェースを要求する、先行技術の企業プロセス描画ユーザインタフェースソフトウェアとは対照的である。企業プロセスを描画するものではないけれども、既存の連続的な描画ソフトウェアシステムの例の一つが、電子マップである。電子マップは、ズームイン、及びズームアウトすることによって、見る範囲を拡大、又は縮小できる。しかし、この方法では、プロセスを提示する能力はない。なぜなら、電子マップにおいて表示とは、プロセス、及びプロセス間の関係性を描画するために使用されるものではなく、二次元で、位置及び距離を描画するために使用されるものであるからである。一方、オーバーレイにおいては、空いた部分（スペース；space）が、原因と結果のリンク、及びプロセスを描画するために使用される。つまり、ノードは問題及び機会を描画し、リンクは、ノードをリンクさせている原因と結果を描画し、空いた部分は、下位又は従属を示すために使用される。これを実現する顕著な特徴は、プロセス及び代表的なノードは収束するということである。つまり、子ノードは親ノードへ折り畳まれ、その結果、ズームアウトした時に、子ノードは互いに適合する。フローチャート及び類似のプロセスブロック図は、細かいものから大きな企業システムまでのプロセスを描画するために用いられる。しかし、フローチャートは、ズームアウトできるように互いに適合しない、順次的なプロセス及び分岐を描画する。

プロセスのシークエンスは、実践的な方法で全てのプロセス関係性を定義するには、小さすぎることが多い。例えば、順次的なステップにおいて、監査の失敗が会社の評判にどのように影響するかを、どのように定義できるか？そして、その際に、当該シークエンスは重要であるか、又は原因と結果は重要であるか？ボールベアリングの誤った配列は、機械の構造の整合性にどのように影響するだろうか？順次的なステップのフローチャートは、これを描画するのをどのように助けるだろうか？シークエンス上、リンクしていない二つのプロセス間のリンクは、フローチャート上では結線できるが、当該リンクは、もはやプロセスフローを描画するものではなく、フローチャートのコンポーネントとしては描画できない。

他の複合的なプロセス描画は、二次元的なＵＩフォーマットで作成されても良い。しかし、それらは、コンピュータが読み取り可能でもあるノードと、収束もするプロセスノードとの間において、明白な原因と結果の関係性を含むものである。また、グラフィカルな描画において、ズームアウトを可能にするために、それらは互いに適合する。また、それらが設計された描画システムの対象範囲によって要求される時、それらは、プロセスの問題又は機会と、他のプロセス問題又は機会との関係性を完全に描画する。

つまり、先行技術の複合的なフローチャートは、単なるプロセスフローではなく、プロセス関係性を描画しようとはするが、収束するノードを提供できない。そのため、詳細なプロセスは、明白な親プロセスに収束すると共に、コンピュータが読み取り可能であって、その結果として、コンピュータが処理可能なノード間での、完全な原因と結果の関連性に収束できる。従って、ユーザインタフェースにおいて、相互に関係する企業プロセスを描画する場合に、これらの先行技術の複合的なフローチャートは、プロセスを示すが、収束するのに十分であるプロセス間の関連度を示さない。これは、ノードが収束しないからであると共に、関連性は未定義であることが多いから、又は、いくつかの場合においては、ユーザの属するコミュニティによって統計的に定義されるからである。一方、本開示で述べるように、オーバーレイにおいては、原因と結果の関連性は、定量的に明白な関連性がある場合には、ゴール近接度、又はアルゴリズムのいずれかによって、経験的に描画される。ゴール近接度と、原因と結果を描画する関連性アルゴリズムとの両方は、コンピュータが読み取り可能であり、関係性の重要性を描画できる。統計的に、描画された関連性はコンピュータが読み取り可能である。しかし、結果が、完全に独立ではない原因と結果の従属性の集計結果である場合には、統計的なサンプルは、完全に異なる原因を有する結果の集計結果になる。そのため、原因と結果が曖昧である場合には、又は、統計的なサンプルが統計的に引き出された重要な関連性に対して、不十分なものである場合には、描画された関連性は、必然的に正確ではない。

例えば、統計的に解析されて、ヒューマンエラーのような人為的な要素に割り当てられた船の衝突は、十分に意味があるものではない。なぜなら、操舵機構の故障のような、衝突の原因になるだろう海洋輸送の全ての技術的な視点は、例えば、機械の設計、製造、メンテナンス、操作上の複雑さ等、人為的な要素も伴っているからである。未定義の関係性、又は先行技術で示すような統計的に関係するノードにおいては、ユーザインタフェースは、未定義又は統計的に引き出されたノード間の関係性で煩雑になるだろう。例えば、緊急事態においては、当該関係性は混乱を引き起こすとともに、最小限の被害に関連する情報を提供すべき緊急事態における応答のために、全体がコンピュータ化されたアプリケーションの目的を、当該関係性は、実質上、駄目にするだろう。

「ボウタイ」ブロック図と通常呼ばれる、正式のリスク評価のために使用される、グラフィカルな二次元描画である先行技術の他の方法において、「失敗モードまたは危険」とプロセスとの関連性は、ノード間の統計的な可能性と「重症度」とを接続することで描画される。しかし、「失敗モード又は危険」、及び「プロセス」、「ゴール」、及びそれらのリンクがあるとともに、「条件」及び他の変数も多いので、要素は収束しない。オーバーレイにおいては、プロセスノードが収束するように、「リスク」、「危険」、「障害」、「結果」は収束しない。例えば、緊急事態においては、そのような慣用的な「ボウタイ」描画は状況全体を示さないだろう。それは、失敗ノード及び危険を表現するだろうけれども、ユーザが、ボウタイブロック図で描画される危険によって影響される他のプロセス、又はボウタイブロック図に示される結果に対して、貢献している他のこと、又は他のプロセスにフォーカスして見たかったらどうなるだろう。それらはどのように接続されるのだろう？ボウタイブロック図は、最良の状態だけにおいて、影響されるプロセス及び原因のリスクの組み合わせとフォーカス対象のプロセス、又はリスクに関係して論理的に引き出されるものを示す。企業内の全てのプロセスがどのように接続されるかを示すとの発想はない。そのため、緊急事態においては、ユーザが、利害関係者に対応する他のプロセスを表示することを必要とする場合、又は、システムが最新のイベントにフォーカスすることを支援する場合には、不連続な過去のグラフィカルな描画とは相違する、他のグラフィカルな描画を行わなくてはならない。従って、グラフィカルな描画は、不連続であって、（連続性を必要とする）ズームイン及びズームアウトのために使用できない。続いて、このことは、各プロセス、又はユースケース、又はユーザ／システムの相互作用点（interaction point）のためのユーザインタフェースを予め設計しないことには、システム内の任意のプロセス、及び将来の任意のプロセスを描画できないことに繋がる。

従って、先行技術システムは、任意のプロセス、システムでエミュレートされたプロセスのグループ、また、現在のプロセス、グループ、将来のプロセス又はグループのいずれかのためのユーザインタフェース描画を生成する。

部分的には、上記は、下記を説明するために役立つ。

オーバーレイの主要な点を使用して、基礎にある企業アプリケーションを強化する、又は置換する。：

問題及び機会及び興味の対象又は予期しないイベント、又は、喪失した重要な監視要素、及びユーザの決定を向上させる関連情報に関して、イベントのトリガーを管理するための情報源としての役割においては、企業の業務の理解を強化させる方法の一つは、基礎にある企業システムを強化する時間を短縮し、時には、当該企業システムを置換することである。

これらの基礎にある企業アプリケーションを強化又は置換する理由は、これらのシステムが古くて過去のものであるので、人間工学的に未熟に設計されていて、そのため、効率的にオーバーレイを機能させるための、正しいトリガー、及び関連する情報を提供するために、時代に合わせてほとんど更新されないことが理由である。

過去のコードを理解すること、過去のコードを維持すること、又は過去のコードを改良することのような、アプリケーション構築における多大な努力をすることなく、オーバーレイのために、これらの企業アプリケーションを置換するためには、過去のシステムの強化又は置換のためのオーバーレイの核なる革新部分を利用することが必要である。つまり、これは、要求された時に、補足的な企業情報システムの作成を容易にするためである。

重要な目的は、伝統的なソフトウェア開発方法に依存せずに、且つその結果として、ビジネス分野のエキスパート、所謂、当該分野の利害関係者及びエキスパートが、伝統的なアプリケーション構築方法をあまり求めることなく構築できるようにして、これらのシステムの補足追加又は作成できるようにすることである。これは、結果的に構築されるシステムが有益なものになる可能性を高めると共に、システムが構築されて、新規かつ緊急の要求に適応する速度向上の可能性を高める。

システムに基づいたオーバーレイの動作は、一部が、ノード構造によって動作すると共に、一部が、基礎にある企業アプリケーション内の伝統的なデータ構造によって動作する。システムのナビゲーション及びノード間の関係性、即ち、企業内のユーザに対する関連性の情報の発見に、一般的に関係するノード構造によって動作する、システムのそれら側面は、非常に柔軟性がある。一般的に、基礎にあるアプリケーション内の伝統的なコードによって動作する、ビジネスオブジェクトの作成及び相互作用を要求する、システムのそれらの側面は、分野のエキスパートによって定義された、ビジネスモデルの評価を変更することが困難かつ高額なままであり、容易に拡張することができない。この後者の状況とは、オーバーレイシステムが、基礎にある過去のアプリケーションの目的の質、及び適合性に対して、未熟なままであることを意味する。

以下の節では、伝統的なコードの必要性を除去することで、新規に拡張されたノード構造によって動作させられる、システムの全ての動作を理解する、オーバーレイの概念の形態を開示する。従って、概念的に言うと、ビジネスモデルは、アプリケーションのコードになる。これにより、オーバーレイシステムにおいて、上記の概略の目的を果たすことが可能になる。

先行技術、及び過去のシステムにおいて、ビジネスモデルは、当該ビジネスモデルによって動作するようにされて良いもの、即ち、トランザクションタスク間で移動されて良いもの、ナビゲーションのフィルターを介してアクセスされて良いもの等として、機能する。一般的に、これらのビジネスモデルは、簡便なデータをパッケージ化したもの、即ち、人又はドキュメントのような、現実世界の物や概念をモデル化する、関係する属性の組を表す。それは、伝統的なコードを使用して現在実装された、これらのビジネスモデルに相当する。これらのビジネスモデルは、属性を含むと共に、多くのユースケースから引き出された他のオブジェクトとの関係性を含む。家の多数の修繕作業に適合するために、付属品を伴う家の修繕道具のようである。しかし、当該関係性は、家の修繕道具よりもオーダーは大きい。そして、近代的なスマートフォン及び近代的なコンピュータを使用するとする場合の多様性の多さとほとんど同等である、ビジネスモデルのユーザの多様性を対象として、属性、及び他のビジネスオブジェクトへの関係性を記載することは、設計者によって、把握及び管理することが、厄介かつ困難である。

例えば、属性をビジネスオブジェクトにパッケージ化することは、これらの属性及びそれらの値が、複雑な基礎にあるプロセスによって決定される傾向があることが事実であるとともに、システム開発中、ソフトウェアエンジニアが一般的に気付かない、企業間に及ぶ（そして、実際に、他の企業内に）規則及び制約の対象である。

例えば、スペア購入注文においては、単一の項目を選択する。

部品番号：当該部品が記載される方法は、おそらく、もとの製造プロセスへの経路を辿って戻るという、複雑なプロセスに起因して決定される。

要求される量：これは、当該注文品のための機械的な状態、来たるべきメンテナンス、時間、労働力、お金、他のリソースの入手可能性を含む、条件の複雑な組み合わせによって、決定できる。

日付に応じて要求されるもの：これも、リソースの入手可能性、機器のアクセス可能性、及び機器の使用方法及び使用時期に関係する。

計画された配達の日付：これは、配達のための当該注文品を準備するために、対象の職員の個人的及び職業上の要求に関係する、供給側の職員の利用可能性に関係する。

要するに、購入注文における項目の単純なビジネスオブジェクトは、伝統的には、上記のうちの一部だけを取得するだろう。しかし、複雑な原因と結果のノード構造に、上記の事項をマッピングすることは、効果的なビジネスプロセスサポートシステムを実現するために不可欠である。このことは、有益な決定を支援すること、及びノード構造を拡張することによって、容易に拡張可能になる。

「理想的な」ビジネスプロセスが続いて行われない場合には、即ち、どのように例外が取り扱われるかということにおいては、課題になることは特に重要である。例えば、もし、部品が時間通りに届けられない場合には、次に行われるべきアクションは、リスクの評価、及び選択されるアクションの低減を可能にする、機器の予想された信頼性のような、非常に複雑な情報に依存しても良い。

これに加えて、異なる企業の要求を容易には満たさない、ビジネスオブジェクトの実装においては、非常に共通するシナリオがある。ここで、当該異なる企業は、本質的に、当該ビジネスオブジェクトに関して、異なる解釈及び利用パターンを有する傾向がある。実際には、ビジネスオブジェクトの実装は、ビジネスロジックをカプセル化し、当該ビジネスロジックは、コード内ではなく、モデル内にあるべきである。かつ、ビジネスオブジェクトがどのように動作するかを、ビジネスモデルが制御できることにおいては、当該ビジネスロジックは、当該ビジネスモデルから見えるような方法で、ほとんど開発されない。

従って、基準になる考え方は、固定概念としてのビジネスオブジェクトの考えを除去することであり、非常に小さな原始的な概念としての属性を採用することではない。事実上、これは、明らかに記載されたコンピュータ読み取り可能な原因と結果によって、又は原因と結果からの派生又は変形により相互に関係する、ノードのノード構造に基づいて、ビジネスオブジェクトの概念を置換するコンピュータ読み取り可能なロジック内、別の変形ロジック内、及び、既知の先行技術システムの保証になった別のユーザインタフェースロジック内で、新しく非常に動的な種類のデータ表示が明らかになることを可能にするだろう。

相互に関係するノード構造によって明らかであるように、更なるオーバーレイ／ＴＡシステムのこの改良の考え方は、属性として定義されるデータモデルを伴うプロセスモデルを明らかに結合したものである。原因及び結果によって接続される、相互に関係するノードを有するデータ、即ち、データが何のためのものであるか、及びどのようにデータが変換されるかを明白に示すノードを有するデータのこの結合は、ホストコンピュータが読み取り可能な重要な変換ロジックに対する、及び特別なプログラミングのスキルなしでの重要なユーザインタフェース属性に対する、システムの機能において、中心になるものである。これは、リレーショナルデータベース（relational database）のような伝統的なデータ構造に対して対照的である。ここで、当該伝統的なデータ構造とは、データが何のためのものであるか（即ち、それがサポートするゴール）が明白に表現されていないものであると共に、好ましいユーザインタフェースを引き出すために要求されることが決定されていないものを指す。伝統的に、それは、コードに埋め込まれた結果、隠されて固定された情報である。さらに、それは、実世界のプロセス、及びコンピュータ化されたトランザクションプロセスにおけるエキスパートが、企業のアプリケーション内の全てのコンピュータ化されたプロセスを理解できるようにするため、及び必要とされた時に、それらを拡張できるようにするために、モデル内で明らかにする必要がある情報である。

ＳＱＬノードがない構造のような他のデータベースとは異なり、企業アプリケーションを構築又は拡張することにおいて、オーバーレイ独特の概念とは、全ての変換ロジックが、ノード間の原因と結果のリンク内にあることである。そして、当該オーバーレイ独特の概念は、アプリケーション変換又はユーザインタフェース属性のいずれかに影響を与えるために、他のロジックを必要としない。補助的なサービスのために必要なノード構造の外部のロジックがあっても良いが、ノード構造の外部には、企業のビジネスロジック、又はユーザインタフェースの属性表示は全く必要ではない。

一般的に、近代的な情報システムは多数の層として理解されて、各層は、特定の種類の関数を実行し、隣接する層にサービスを提供する。そして、オーバーレイ／ＴＡ概念も、例外ではない。次世代のオーバーレイ／ＴＡ概念は、以下に概要を記載する、三つの層を有する。

ユーザインタフェース層。この層は、システムのユーザに提示するインタフェースを形成し、層全体がビジネスモデルから派生される層である。

ビジネスロジック層、又は「中間」層。この層は、ユーザ及び組織のゴールを満たすために、当該ユーザ及び当該組織が要求する範囲内で、どのように当該ユーザ及び当該組織をサポートすべきかの表現を定義する層である。それは、オーバーレイである実装フレームワークにおいて動作する、ビジネスモデルから構成される。

データ管理層；この層は状態情報の格納を容易にし、これも、層全体が、ビジネスモデルから派生される層である。
ビジネスロジック層

上記の通り、この層は、ビジネスモデル、及びビジネスモデルが実行される実装フレームワークである、二つの基本要素から構成される。ビジネスモデルは、ソフトウェアエンジニアではない者によって作成され、管理され、伝統的なプログラミング言語、及びデータベースの知識は要求されないだろう。従って、ビジネスモデルは、重要な情報システム、即ち、目的を満たす際に組織をサポートするものを引き出すために要求される、全てのものを定義するだろう。よって、困難なことのうち重要なことは、基礎にある実装フレームワークで処理するには曖昧すぎる状態のままであると共に、予測可能で有益で利用可能な最終結果を提供するには曖昧すぎる状態のままである時に、技術者ではない者にとって容易に理解可能であるモデルの定義をサポートすることである。

オーバーレイのビジネスモデルの心臓部になるものは、ノードである。それは、オペレータの者、或いは、センサ又は他のシステムエージェントが、入力、即ち、状態変化を決定及び提供する必要がある場合の企業重要点である。または、それは、ユーザがシステムによって何かに気付く必要がある場合の企業重要点である。高いレベルでは、これらのノードの集合は、組織のプロセスモデルを定義し、当該組織のプロセスモデルは、基礎にある状態モデルと結合される時、各企業重要点をサポートするために要求されるユーザインタフェースを引き出すための十分な情報を提供すべきである。プロセスモデルの要素は、親プロセスモデル（マスタープロセスモデル；master process model）内で、より高い包括的なプロセス抽象化にマッピングできる。さて、出願人は、より詳細に各コンポーネントを説明する。
ビジネスロジック層：プロセスモデル

プロセスモデルは、相互接続されたノードの集合として定義される。各ノードは、ノードに入力又はノードから出力される、属性の集合を有する。他の種類の関係性も存在して、以下に概要を記載の通りであるが、基本的には、ノードは、原因と結果として他のノードに関係する。

ノード間の原因と結果の関係性は、データの入力又は存在の結果として、アクションがユーザ又は他のエージェントによって、原因ノードの一部として、明示的に、又は暗示的に発生し得ることを暗示する。ここで、当該原因ノードは、状態変化のトリガーであって、そして、「興味の対象（of interest）」として、影響されるノードを提示するものである。従って、当該アクションにリンクされて、原因と結果ノードにリンクされるシステムの「コード」は、アクションの呼び出しの結果として状態変化に影響を与えることにフォーカスできる。

ノードは、当該ノードの「ノードクラスタ」内の、ノードにリンクされた属性の集合に関係する。ノードクラスタは、典型的に、プロセス及び他の理由に関係する、関係ノードの集合である。かつ、当該ノードクラスタは、モデルを作成する分野のエキスパートによって明確に定義される。各ノードにおいて、入力（リードオンリー）、又は出力（リード―ライト）のいずれかとして指定される。ノードに対する属性の集合は、当該ノードに対する「叙述パターン」と称する。

基本的に、ノードは、属性のクラスを消費又は生成する点において、状態なしである。つまり、ノードのインスタンス化という考え方はない。代わりに、ノードは、当該ノードに対する属性入力の状態の結果として、興味の対象になる。例えば、「部品調達及び輸送のオプションを評価する」ノードは、実行対象の船から顕著な要求がある時には、興味の対象になる。典型的に、この状態変化は、原因ノードに関連付けられたアクションからの要求の結果である。

また、ノードは、関係する同じ領域に属するものとして、即ち、組織的なタスクグルーピングにおけるタスクとして、他のノードに関係する。当該組織的な関係は、直接的な原因と結果によって同じノードクラスタのメンバであることを、必然的には暗示しない。むしろ、当該組織的な関係は、複雑なノード構造になり得るものをナビゲーションする時に、ユーザを助けるために使用される。例えば、多くの「獲得」プロセスを組織する「獲得」ノードは、当該ノードが組織するプロセス、又は他のプロセスに対する原因と結果のリンクを有しない。これは、そのような組織的なノードが、当該組織的なノードが組織するノードによって、どのように影響を受けるか、又は、当該組織的なノードが、他のノードにどのように影響するかが不明確であるからである。つまり、もし、人が、「獲得」することはどのようにして失敗するのか、リスクのある時に、いつ「獲得」するのかとの質問をするならば、答えは不明確である。同様に、もし、人が、「獲得」することが失敗した時に、どのプロセスが失敗するのかとの質問をするならば、答えは不明確である。しかし、予備部品に関する「船の在庫品の状態」のようなグルーピング内の小さいノードは、船上の修繕を実行できるとの非常に明確な影響を有する。そのため、それらのノードによって組織化されたノードが、他のノードに対しては、通常の原因と結果のリンクを有する一方で、「獲得」のような組織的なノードは、ナビゲーション目的のためのものである。
ビジネスロジック層：状態モデル

これは、ユーザが情報を共有できるようにするため、及びシステムがユーザセッション間の物事を「覚えておく」ことができるようにするために、データが格納される場所である。

属性がプロセスモデルの一部として識別される時、当該属性のための値を容易に格納するために、自動的に、状態モデルは拡大される。

状態モデルの属性値は、関係性を示すために、ノードを介して、当該モデル内に更なる属性値へのリンクを含んでも良い。例えば、年齢及び氏名の属性は、従業員を集合的に表すために、従業員ＩＤの属性にリンクされても良い。且つ、これは、ノードクラスタ内で表されても良い。クラスレベルでは、存在する関係性の種類は、典型的に、より大きなエミュレートされたプロセス又は親ノードに役立つ同じクラスタの一部である、属性の結果として、プロセスモデル（ノードクラスタ）から引き出される。

ここで、重要な仕組みは、オーバーレイインタフェースのコンテクストコンポーネントである。コンテクストのフィルタリングに使用される属性、つまり、キー識別子を使用したシステムのナビゲーションは、「キー」属性になる。キー識別子によって、多くの類似のプロセスがそれらの原因と結果で区別される時であって、関係するが相違する多くのプロセスステップが、同じキー識別を使用する時、キー属性は、主たるナビゲーション方法を形成する。例えば、もし、従業員の名前がキー属性として定義される場合に、一人の従業員を識別する大きなクラスタで、従業員の年齢の属性の夫々が二つのノードを形成すれば、システムは、当該名前と従業員の年齢属性をリンクさせることができるようになる。二人以上の従業員がいる場合に、プロセスステップが全ての従業員に対して同一である状態で、従業員に関する詳細なことについて処理する時には、キー属性、及びシステムのナビゲーションを支援するためのキー属性の使用は、正しい従業員にフォーカスしていることを明確にすることを支援する。

状態管理のこの方法は、慣用的なシステムからの大きな分岐点であることを表す。ここで、慣用的なシステムとは、分野に特有な全ての知識を除去すること、及びプロセスモデルから引き出された当該知識を有することによって、データモデルから、現在起きているプロセス完了に必要なものを正確に提示する上で、システムの能力に影響する新しい設計において、情報システム設計で仮定したことが優勢になるとの、潜在的な変換がおこなわれることを回避することを、我々が助けるシステムである。
ビジネスロジック層：マスタープロセスモデル

実行可能性のあるノードは、親プロセスモデルによって定義されるノードクラス（抽象化されたプロセスを描画する、抽象化されたノードクラスタ）をインスタンス化するものとして、当該ノードクラス（抽象化されたプロセスを描画する、抽象化されたノードクラスタ）に関係する。分野に特有なノードの抽象バージョンとして、ノードクラスは、当該分野に特有なノードにおいて共通の要素を取得する。例えば、ノードクラスは、計画、チェック、賛成、警告等のような概念をカバーしても良い。抽象化されたノードクラスは、人として我々が理解できる最初の抽象化における、「原始人（cave man）」にも分かる概念を表す。

抽象化されたノードクラスは、二つの主な目的に役立つ。第一に、分野に特有な事象をどのようにモデル化するかを考える時に、例えば、ビジネス分野のエキスパートに、何の事象を考える必要があるかを思い出させることによって、又は、分野のエキスパートの仕事を、個々に理解させることを助けることによって、抽象化されたノードクラスは、当該ビジネス分野のエキスパートに対して、ガイダンスとして役立つ。第二に、抽象化されたノードクラスは、再利用を容易にすることによって、及び複数の分野のモデルに関係する類似のプロセスを迅速に識別できるようにすることによって、モデリングの処理を加速する。しかし、再利用は、包括的コードのコンポーネントのコピー・アンド・ペーストではなくても良く、むしろ、全てのインスタンス／ユースケースに対するノードクラス（抽象化されたクラスタ）に適用されることもあるだろう。これは、分野／ユースケースレベルを採用せずに変換可能な適切なコーディング言語を用いて、抽象化又はクラスレベルのクラスタを記載することが、如何なる場合においても、容易ではないからである。しかし、分野クラスタをノードクラス（抽象化されたクラスタ）にリンクさせることは、非常に明らかであり、且つその結果として、カスケードクラスレベルに対して、分野／ユースケースレベルへのロジックの改善することを、非常に明らかにする。
ユーザインタフェース層

ユーザインタフェース層は、ユーザに、グラフィカルユーザインタフェースを提示するために、ビジネスモデルに含まれる情報と、最も実践的なユーザインタフェース設計の基本をエンコードしたものとを結合する。

既存の先行技術は、ＵＩを伴う概念のうち、基本的な概念の一つとして、ビジネスオブジェクトを使用する。つまり、ユーザは、コンテンツを表示、及び必要な時にコンテンツを変化させるために、ビジネスオブジェクトを作成し、ビジネスオブジェクトの表示を出力する。本開示での方法において、オーバーレイは、基本的な相互作用のＵＩの概念が、ノード自体になるという方法における、根本的な変化を理解する。ユーザは、プロセスを実行すること、及び、状態モデル更新のために情報を取得することのために、要求される情報を表示するために、ノードＵＩを展開する。

基本的に、ノードＵＩは、対象のノード、及び周辺のノード、即ち、ノードクラスタの入力属性及び出力属性を提示する。出力される属性はリードライト（読み書き可能）であるが、入力として識別される属性は、リードオンリー（読み込みのみ）である。属性値は必要なところでグループ化され、上記の通り、プロセスモデルによって規定される。

存在する属性値の個数は、表示のフォーマット及びサポートするナビゲーションツール（ソート、フィルター、サーチ）の利用可能性を規定する。もし、多くのデータがある場合には、結果として、ＵＩは、動的に適切に採用されるだろう。属性は、ノードのためのキー属性としてハイライトされても良く、さらに、当該ノードは、ノードの表示画面において、当該属性が提示される方法に影響を与えても良い。

多数の出力属性を有するノードに対して、初期のキー属性リスト、及び属性セットエディタに基づいて、システムは二つのステップのＵＩモデルに依存しても良いが、両方の場合において、ＵＩは、動的に生成されなくてはならない。これの一例は、購入注文だろう。購入注文は、第１のステップは、関連するキー属性（日付、供給者の名前、注文を識別するもの、受取人）のサマリーを提供し、第２のステップは、完全な購入注文ヘッダ、及び全ての項目を調達する、より複雑なＵＩであるだろう。

どの属性が関連があるかを決定するのと同様に、ノード間の原因と結果の関連性も、それらの属性がどのように提示されるかに影響する。例えば、原因と結果との関連性によって影響される属性に応じて、視覚的に強調されても良い。当該関連性は、問題になるノードに直接的に関係するもの、又は複数の原因と結果との関連性を取得する単一のＵＩを提供する、ノードクラスタの表示に直接的に関係するものである。プラットフォームは、決定、又はなされるべき決定又はトランザクションに適した、ＵＩアプローチを構築する。

また、複数の属性が、ノード構造によって関連があると思われる他の属性に、コンテクストを渡すために必要と思われる場合には、当該複数の属性は関連があるものとして決定される。例えば、もし、機械のコンポーネントの名前が、入力属性として識別される場合には、システムも関連ある船の名前であると思われても良い。グリッド表示に好ましいデータ構造内に表示範囲を定めるために、これらのキー属性は使用される。この例においては、「データ定着マスターセットアップ（data population master setup）」と名付けられた処理内で、船の名前のノードには、識別ノードに対する姉妹ノードとしての機械のコンポーネントが追従するだろう。
データ管理層

データ管理層は、ビジネスモデル内で、状態モデルを、既存のデータベース管理システムによって提供される実装フレームワークに変換する層である。必要があれば、基礎にある方式は、現在発生している（オンザフライ；on the fly）拡張性をサポートするためにメタモデルになるだろうから、スケーラビリティの必要性、及び正式な相関的データベース構造の必要性の欠如は、キーになる値のペアとして、データが存続しそうであることを意味する。続いて、このことは、ＣＡＳＳＡＮＤＲＡ（アパッチソフトウェア財団（The Apache Software Foundation）、Los Angeles、CA）のようなＮｏＳＱＬデータベースシステムを使用することに、自然と繋がる。この方法は、基礎にあるデータ管理方式が、システムのパフォーマンスの支障になる可能性を低減する。

単にデータを提示すること、及び入力を取得すること以上に、情報システムに入り込む他の種類の計算ロジックは多くある。以下では、いくつかの更なる計算が、どのようにカバーされるかについて簡単に考察する。
属性の作成及び削除

状態モデルの説明において述べた通り、新しい属性の作成に繋がるアクションは、当該属性、及び他の関係する属性を作成及び定着させるコンストラクタ関数を実行することのきっかけ（トリガ；trigger）になるだろう。属性の削除は、パラメータとして、ノードＵＩから属性を取得する特別のハードコードされた、アクションの種類によってサポートされる必要がある。また、削除することの妥当性をチェックするロジックを含む、デストラクタ関数を定義できるべきである。
イベントハンドリング

コンストラクタイベント、及びデストラクタイベントと同様に、システム及びカスタムイベントのために、アクションコードを定義できるべきである。例えば、ノードの表示画面が開かれ、表示、編集等がされた時である。状態変化が起こる時、アクションコードに関係するカスタムイベントが開始する。これは、データベースのトリガと同じに見えるけれども、トランザクションタイプのプロセスに関連付けられた非常に詳細なレベルであっても、再利用可能な抽象化されたプロセスとしてのノード構造で表現される。
アクセス制御及びセキュリティ

本質的には、アクセス制御は、役割ノードユーザコンテクスト（role-node-user-context）構造の一部として提供される。追加のアクセス制御層で、この構造を包含する必要があるべきでない。
原因と結果のコンピュータ読み取り可能である、計算される属性

これは、ユーザに対して、計算のサポートを提供する中核的な概念である。計算されるフィールドは、スクリプトの生成物として定義され、当該スクリプトの生成物は、数学オペレータ、論理オペレータ、条件／選択ループ等のようなプログラム構造物を含むが、それらに限定されない。典型的に、原因のノードから、影響されるノードへ遷移させるアクションの結果として、計算されるフィールドは更新される。
システム統合

オーバーレイモデルにおいて心臓部になるノード構造概念は、異なる種類の情報システムの統合（プロセス（又はユーザ）を統合する見地に起因する統合、及び、より単純なデータ統合の見地の両方の立場に起因する統合）の事象に関して、有用なフレームワークを提供することである。以下の説明では、これらの夫々に目を向けて説明する。

プロセス統合は、プロセス間で情報を遷移することとして理解される。当該プロセスは、同じシステムによってエミュレートされないが、プロセスを効率的に実行するためには、当該プロセスが統合されるべきであることが望まれる。統合されるべき両方のシステムが、同じ基礎にあるエンティティの表現における競合を表している時には、つまり、当該両方のシステムが同じビジネスオブジェクトの実装を提供せず、どちらのシステムも、ビジネスオブジェクトの属性に関連する、全シナリオの好ましい表現ではない時には、この種の統合に関連付けられた問題は、最も困難なものになる。それらの基礎にある属性に、ビジネスオブジェクトを細分化すること、ノードをそれらに割り当てること、及びノード間の関係性にロジックを適用することで、属性の照合が可能になる。なぜなら、統合のために適切である、両方のシステム内の同じビジネスロジックを描画するノードに対して、当該属性が割り当てられるからである。

プロセス統合の方法論は、ビジネスモデルオブジェクトを使用する慣用的なコードが、オーバーレイのノードモデル構造でホストされたコードに変換する、次の方法に同種のように見えるかもしれない。：
状態モデルを、統合されるべき２つのシステムの状態モデルにマッピングする。
統合されるべき各アプリケーションによって提供される、問題及び解決策を抽象化する。
統合されるべきプロセスを包含する、抽象化されたノードのクラスタを作成する。
統合されるべき各アプリケーションで、抽象化されたノードを属性に接続する。
もし、正しく行われた場合には、属性の二つの組（即ち、抽象化された組と、アプリケーションからの組）は、同一であるだろう。つまり、各分野内の各ノードに対して、予想パターンを作成し、上述のテーブル内にデータを配置し、抽象化されたノードに接続する。
最終的に、統合されるべき二つのアプリケーションの夫々において、テーブルの関係性及びグルーピングは相違するけれども、予想パターン内のデータは等価であるだろう。従って、アプリケーションによって実装される関係性に基づく任意のゴールは、ノード構造によって置換される。
予想パターンは、各データベースから、正確に照合データを抽出する。なぜなら、ノードは、厳密に同一のデータを記載するとともに、夫々のデータベースが異なる関係性を提供するからである。

データ統合のより単純なタスクに関して、ノードを「実行する」アクターとして、出願人は、外部のシステムに目を向けてみる。この結果として、ノード構造の一部として、データを外部に渡すため、及びデータを受け入れる（そして、データを処理する）ために要求されるデータ変換を定義する。つまり、人々が行うのと全く同じ、ある（特定の）方法で、データを望む外部のデータシステムをみることができる。システムの能力に対して、正確なルールに従わない入力を受け入れる（これが、入力され得ない理由はない）ようになる場合には、システムの耐久性は低い傾向があることは勿論である。しかし、異なるサービスの種類、プラットフォーム等がセキュリティ考慮できるようになることをサポートするために、いくつかのプラットフォーム要素を構築することが要求されるだろうが、これは、完全に包括的になされる。

図１５を参照して、前述の内容は図示されても良い。学校における避難及び学校の封鎖を要求する緊急事態では、共通のゴール１５００は、１００％の生徒が避難すること、及びドアが１００％閉められることである。そのようなものとして、統合されるべき二つのプロセスは、学校内における、ドアの状態、及び生徒の数である。マップされるべき二つの状態モデルは、「ドアの状態」（開又は閉）及び「現在いる生徒の数」である（入った場合には１を足して（＋１）、出た場合には１を引いて（−１）、ドアを通過する生徒を数える）。そして、ドアの状態を監視するため、及びドアが開いている時に、何人の生徒が通過するかを数えるためには、問題及び解決策は抽象化される。

そして、ノードＡ１５０２、ノードＢ１５０４、ノードＣ１５０６、ノードＤ１５０８は、統合されるべきプロセスを包含するノードのクラスタを表す。そして、抽象化されたノード１５０２−１５０８は、ドアの状態の属性、及び生徒の属性に接続する。各ノードは、中間ゴールに関連する、原因と結果の関係性を有する。例えば、中間ゴールＥ１５１０は、数えられた閉鎖されたドアの枚数であり、中間ゴールＦ１５１２は、避難集合場所にいる生徒の数である。そして、これらのゴールは、避難集合場所にいる人（生徒）の割合、及び閉鎖されたドアの割合を決定する、共通ゴールに収束する。両方が１００％である時、共通ゴール１５００は達成される。

属性がプロセスモデルの一部として識別される時には、状態モデルは、自動的に、当該属性に対する値の格納を容易にするために拡張される。つまり、ノードの予想パターンによって表現されるプロセスモデルの一部として、属性が新たに定義される時、状態モデルは、プログラム的に、状態支援モデルを拡張することなく、当該属性に対する値の格納を容易にするために拡張される。図１５の例においては、他の属性は、明りを消すことであっても良く、状態モデルは、明りの状態（オン、オフ）を含むために、拡張されても良い。

リソース割り当て、及びスケジューリング。これらは、プラットフォームにシステムを構築しようとするときに直面し得る、共通のプログラム上の困難なことの二つの例である。サービスの組は、確立された最良の実践的なことに基づいて、計算のサポートを提供することを構築できる。つまり、プラットフォームは、様々な状況で使用できる、包括的なリソース割り当て及びスケジューリングエンジンを提供できる。

高度なデータ可視化。プラットフォームは、データを取得すること、及び表、グラフ、他の可視化をすることで、データを表示する、サービスの組を提供する。データの出力及び関連する表示は、ノードの出力へと繋がる。上記の高度なデータ表示、つまり、この可視化の最上位の相互作用において挿入されるデータ入力は、相互関係のあるノード構造上の全表示に基づいて、再度達成される。当該ノード構造は、ユーザの相互作用（インタラクション；interaction）が必要であると思われるものである。そのため、任意の表示により、システムの情報処理からの結果となる、慣用的な出力表示、又は、当該表示の出力に、ユーザの反応を繰り込むための入力ダイアログのどちらかが明示される。

緊急事態の応答。利害関係者のゴールの優先度、及びその結果として、入力及び出力の関連性のノード間での接続が、突然変化する状況が時々起きる。例えば、もし、緊急事態（例えば、火災で工場の床が破壊されること）が起きる時、ゴールの階層は変化し、新しい緊急事態オーバーレイノードネットワーク（emergency overlay node network）が適用する。通常の企業ゴールを強調する緊急事態前と比較して、ダメージを最小限にするとともに、人員（職員；personnel）が安全に避難することができるようにする、最も高いレベルのゴールが実行されると、後に続くべきプロセス間の関連性と、及び利害関係者との全てが変化する。一つ目の例として、管理補佐者の役割は、データを入力することから、会社のデータベースに含まれるデータを保存することに変化しても良い。二つ目の例として、メンテナンス従事者の役割は、良い操作条件で、装置をメンテナンスすることから、装置から電力を取り除くことに変化しても良い。三つめの例として、販売者の役割は、潜在的な顧客に電話で連絡を取ることから、危機管理担当者に通知し、設備の安全な退避を管理することに変化しても良い。

また、緊急事態が進行している間は、物理オブジェクト及び環境は変換しても良いと認識される。例えば、避難経路がブロックされるかもしれず、代わりの経路が決定されるかもしれない。または、識別された最初の反応者が他の呼び出しに忙しいと、代わりのチームが、識別されて連絡を取られなければならない。

緊急事態の応答は、当事者から見た、緊急事態の進行状態に関する情報を入力する、最初のユーザである企業参加者ではない者を要求する。また、緊急事態の応答は、緊急事態に応答して企業の職員として働く（機能する）だろう、臨時のユーザを要求する。

緊急事態は、連携管理を要求する。図１７を参照して、中核部分で連携させる緊急事態管理の先行技術においては、企業参加者ではない者の情報を利用したが、電話着信を取る人を介して、当該情報を取り扱った。組織のメンバ１２３０（安全のエキスパートである者が好ましいが、緊急事態の範囲及びタイミングにより、そのような者でなくても良い）は、消防署１２３２、警察署１２３４、医療従事者１２３６、環境保護局１２３８のような、１又は２以上の企業参加者ではない者と連絡を取り合う。そして、当該メンバ１２３０は、組織の他のメンバ１２４０ａ―１２４０ｅに、この情報を配信する責任を負う。

先行技術のモデルは、多くの不足点を有する。緊急事態において、電話を受け付ける待機状態のコールセンター、及び経験豊富なレベルのユーザがいるような余裕は、多くの企業にはない。ここで、経験豊富なレベルの人々とは、情報を解釈でき、かつ活動及び決定するために、情報を利用する企業内のユーザに、情報を配信できる人々を指す。メンバ１２３０は、複数の企業参加者ではない者１２３２、１２３４、１２３６、１２３８から情報を受け取っており、当該複数の企業参加者ではない者は、互いに連絡を取らないかもしれず、矛盾する助言を与えるかもしれない人々である。当該メンバは、企業１２４０ａ―１２４０ｅの複数のメンバに適切な情報を広める責任を負い、当該複数のメンバのうちの各メンバは、緊急事態の間、異なることに興味を持つかもしれないと共に、経時的に、環境内で変化するかもしれない。さらに、企業１２４０ｄ、１２４０ｅのメンバは、互いに連絡１２４２を取るかもしれず、結果として、メンバ１２３０からの命令に対して注意を払うことがおろそかになるかもしれない。メンバ１２３０は、緊急事態のため、又は携帯電話の電池不足のために、通信を終了する必要があるかもしれない。先行技術のシステムは、大きな企業での重大な緊急事態には適していないことは明らかである。さらに、情報を取得するため、情報を解釈するため、及び当該情報を必要とする決定者及び参加者に当該情報を再配信するために、システムが必要であることは明らかである。

図１８を参照して、企業の応答者１２０４ａ、１２０４ｂ、１２０４ｃ、１２０４ｄ、１２０４ｅとともに、傍観者又は企業職員ではない者１２３２、１２３４，１２３６、１２３８が、ローカル電話通信網、ローカル無線通信網を介してインターネットにアクセスするために携帯機器を使用できる、携帯電話が追加されることで、最初のユーザ又は臨時のユーザは、緊急事態の応答で参加できるようになる。彼らは、予期しない選択の組から、情報を入力できる。そして、コンピュータプロセッサは、興味を持つ集団に、自動的に情報を配信する方法を決めることができる。緊急事態は、たいてい、少数の改善のためのアクションの組み合わせを要求する状況であり、そのため、一度に、多数の選択の組み合わせは必要ではない。

緊急事態において、夫々の企業参加者、又は夫々の企業参加者ではない者には、他者と通信することが必要になる活動と、経験との少数の組み合わせを有する。従って、初心者のユーザには、システムを介して数個の選択肢になるので、初心者のユーザは、システムのアクションの選択が容易である。もし、未経験のユーザと連携する携帯機器が、情報又は応答に関して、当該ユーザに対して多くの選択を提供する場合には、当該携帯機器は有用なものではない。少数の選択肢の組み合わせを提供するためには、システムは、状況を認識していることが必要である。

制限された選択肢のシステムを設計するために、現在起きている状況を正確にエミュレートする必要がある。例えば、火災、嵐、侵入者、及び物理的な環境の様々な種類のようなことに関係する様々な危険において、共通の緊急事態の行動は、避難である。多くの緊急事態の応答の計画において、全ての企業に対して、これらのうちの一つ以上はカバーされる。

携帯機器用の緊急事態の応答アプリケーションを構築するために、次の特徴が要求される。
機能の制御のための中心的なアプリケーション。
当該中心的な制御処理においては、緊急事態の種類を指定しなくてはならない。
企業内のユーザは、現在起きている緊急事態に対する適切なインタフェースを与えられなくてはならない。企業内のユーザは、任意の緊急事態で、異なる活動を実行するので、彼らは、各緊急事態における夫々特殊なことに対して、異なる組み合わせのアプリケーションインタフェースにアクセスできなくてはならない。緊急事態が、段階的に拡大する、又は枝分かれする、さもなければ、変化する場合には、企業内のユーザは、あまり相違しないがフォーカスされたアプリケーションインタフェースを与えられなくてはならない。不在、又は機能喪失、又は状況変化のために、企業内のユーザが交代する時、他の企業内のユーザは、彼らのタスク及び適切なユーザインタフェースを引き継がなければならない。
企業内のユーザではない者は、彼らの状況、及びたいていは彼らの居場所に応じて、適切なユーザインタフェースを与えられなくてはならない。
企業内のユーザ又は企業内のユーザではない者が、テキストメッセージで応答することに頼らなくてはならないとき、それらはシステムの中核で構文解析され、決定又は活動のために、正しい利害関係者に配信されなくてはならない。システムは、企業重要点に、ＳＭＳ（Short Message Service）メッセージを割り当てる必要があるだろう。

上記を達成するために、アプリケーションは、緊急事態のシナリオでの参加者の全ての活動及び決定、それらの結合、及びそれらの変形を予期する必要があるだろう。緊急事態の応答に適するシステムは、緊急事態の種類又は性質、又は情報の種類、又は、情報からなされる決定の種類に関係なく、適切に構成されることが好ましい。

ユーザインタフェースには、ユーザプロファイリングが必要であり、そのため、各ユーザは、緊急事態を通じて、適切なユーザインタフェースを取得する。

ユーザインタフェースを変更する状況の変化は、緊急事態の間、状況が枝分かれすると直ちに、又はユーザが変わると直ちに、ユーザインタフェースを変更しなくてはならない。指定されたユーザによって、状況の変化は自動化されても良く、又は引き起こされても良い。

図１９を参照して、機能１２０２の一部が図示される。ノード１２０６は緊急事態に対する重要点であり、火災１２５２、洪水１２５４、及び侵入者１２５６のような異なる種類の緊急事態を識別するノードにリンクされる。これらの異なる種類の緊急事態は、問題の現場１２５８、安全な場所に到着した人の数１２６０、数えられていない人の数１２６２、現地での緊急事態の装置１２６４、出口の場所１２６６のような共通のノードを有する。いくつかのノードは、サブノードを有しても良く、例えば、安全な場所に到着した人の数は、夫々の人の医療の状態のサブノード、ノード１２６８、及び夫々の人の医療の状態に対応する、状態モデル内の対応するサブ属性を有しても良い。

消防署１２３２、医療機関１２３６のような企業職員ではない者の表示スクリーン１２０８は、当該職員に対して、異なる使用する情報を表示する。例えば、消防署は、緊急事態の種類（火災１２５２）及び、場所１２５８及び、数えられていない人の数１２６２のような属性を表示する。小さいスクリーンで有益に表示するために、消防署に関連する情報が十分に大きくできるように、他の情報は表示されない。他の情報、例えば、場所又は出口１２６６が、ディスプレイ１２０８の中央になるように、ディスプレイはスクロールされても良い。また、「特殊化された装置は要求されますか？」のような、限定された個数のユーザ入力ノード１２７０が表示される。図１８、１９を参照して、もし、ユーザの入力クエリーに対する当該答えが、「ｙｅｓ」である場合には、火災は、本質的には、化学的なものであるとの考えがシステムに送信される。その後、当該システムは、何の化学物質が燃えているかを決定するための企業内のデータベース、及び当該火災を消火する方法の指示のためのリモートデータベース１２１４にアクセスしても良いと共に、即座に、消防署の職員１２３２に戻して、その情報を直ちに中継しても良い。

また、医療従事者１２３６は、緊急事態が火災１２５２であるが、安全な場所にいる人の数１２６０、及びそれらの人の医療状況１２６８より、場所１２５８は関連性が低いかもしれないことを理解しても良い。また、医療従事者は、他のノード及び属性にスクロールしても良く、例えば、数えられていない人の数１２６２を知ることは、追加の医療機器が現地で必要とされ得るかどうかとのクエリー１２７０´に答えることの助けになっても良い。

緊急事態は、ユーザが強く興味を持つこと、及びおそらく制限された範囲内での機敏さをもたらす。

スクリーンのサイズは、とても小さく、英数字、及びタッチスクリーンのキーボードは物理的に非常に小さい。

緊急事態において、情報を送信するため、及び情報を受信するために、状況に特有な必要なことを達成するために、システムにとっては、ユーザと通信することが必要であり、かつ、ユーザにとっては、システム、及び互いのユーザと通信することは必要である。受信されるべき、又は送信されるべき情報は、状況に特有なもの、及び／又は必要性を認められるユーザに特有なものである。

状況に特有なノードは、緊急事態において必要性を認められるユーザに関係する。その関係性は、原因と結果を介したものであり、順次的なプロセスである。原因と結果は、関係付けられたノードに集中する。他の利害関係者、又はセンサによる状況をインスタンス化することで、ユーザの注意が進行している状況における新しい警告に向けられることができるようになる。必要な時に、順次的なノードは、トランザクション（即ち、ユーザの入力）が、シークエンスの後に続くことができるようにする。また、トランザクションではないシークエンス、順次的な状態を示すことを報告することは必要になっても良い。例えば、生徒数を数えることであり、他の例としては、段階的に拡大、又は段階的に縮小する状況を公表することを承認するシークエンスに従う、管理者である。

そのため、システムは、Ａ）原因と結果を介して、ユーザに関連するノードをインスタンス化する新しい状況、Ｂ）ノードを選択した最近のユーザ、及びそれらのノードに関係する順次的なノード、原因と結果によってそれらの関係付けられたノード、Ｃ）利害関係者に対する最大のリスク及び重症度を描画するノードを示さなくてはならない。

かなり多くのノードに関連付けられた各役割を伴う、制限された表示スクリーン内。明確に見えないほどに、且つ、特に緊急事態においてナビゲーションできないほどに、小さいノードを表示しないと、スクリーンで全てのノードを表示できないことがあり得る。従って、フォーカスすべき三つの選択肢は、Ａ）現在のノードに関係する最近の状況、Ｂ）ユーザが現在役割を果たしている、又はユーザが出力して欲しい可能性のあるノード、Ｃ）利害関係者に対して最大のリスク及び重症度を描画するノードである。

ユーザは、必要性を認められる別のユーザに従って、他の離れたノードをナビゲーションできる。

航空機の制御パネルを同期させるためには、当該制御パネルは、役割／ユーザに対する最新の潜在的な緊急事態のリスク、最新の潜在的な緊急事態のリスクノードに対する原因、及び結果に関係する全てのノード、ユーザ／役割に対する注意の最後のノード、利害関係者に対する最も高いリスク及び重症度のノードを表示するだろう。

携帯機器に対する類似の実例としては、音を伝えることが困難な状況で、緊急事態が発生している時の会話である。もし、会話が、現在発生している緊急事態には関係ない場合には、又は当該緊急事態に関する新しいリスク、又は、当該緊急事態及び特定の参加者に関する最も重要なことに関する新しい会話に関係しない場合には、その会話の聞き手になる者は、緊急事態によりパニックになっている間は、会話には加わらないだろう。

柔軟にするために、そのようなシステムは、以下の要素の使用を要求する。：
企業重要点；
企業重要点間の関係性；
企業重要点の利害関係者；
ユーザからの入力；
ノードに関連する情報を発見するために、企業システムを走査すること；
ノードに関連する情報を発見するために、企業システムの言語構文解析を実行すること；
緊急事態において選択困難なコンテクストのために、ユーザの選択肢を選別できるようにするコンテクスト。

企業重要点同士の関係性を考慮しないで、システムは、予め指定された役割タスク関係性、及び予め指定されたタスクツリーを保持する必要があるだろう。現在のシナリオの分岐に変化させるために、中心的な制御処理としては、各プロファイルされたユーザに対して、変形タスクツリーを提供する必要があるだろう。

あるいは、オブジェクトの方向性を決定することは、関連付けられた、ナビゲーションする上で困難である、残りのオプションである。

タスク間の関係性が無い状態では、ユーザのためにプロファイルされる多数のタスクツリー／ユーザインタフェースがあるだろう。タスクを追加すること及び削減することは、それらを減らすための唯一の方法であるかもしれない。しかし、もし、それらの間に関係性が無い場合には、緊急事態が発生している間は、タスクが選択されること、及びユーザインタフェースにタスクが適用されることは困難になる。

プロセスの重要点間のオーバーレイ関係性において、ユーザインタフェースの数は、任意のインスタンス化された重要点にフォーカス可能である、大規模な連結したユーザインタフェース一つまで低減するだろう。その結果、ユーザは、インスタンス化された重要点であって、及びそれらに適用するコンテクストによって選別された、重要点周辺のノードを見ることになる。つまり、システムは、状態及びコンテクスト、及びプロファイリングするユーザの利害関係者に応じて、インタフェースにおいて、各ユーザの（存在が）露出することを低減する。状態のインスタンス化は、指定されたユーザによって、又は自動的にシステムによって選択される。

現場のための情報を取り出すため、及び、活動と決定とを目的として正しいユーザにそれを配信するために、システムは、当該情報を予期しなくてはならないと共に、ユーザにそれを提示する予め計画された方法を有している必要がある。これは、先行技術のソフトウェア及びハードウェアアプリケーションを使って可能である。

設計において障害になることは、各ユーザ及び環境に対する、正しいユーザインタフェースを獲得していくことである。以下の段落では、先行技術における、いくつかの代替案を記載する。

入力事項に対する物理的なオブジェクトの方向性を決定。例えば、物理的なオブジェクトの方向性を決定することは、物理的な場所の選択肢、又は、避難が必要な人々の選択肢からの最初に選択によって、システムを誘導（ナビゲーション）することである。ほんの数個の物理的なオブジェクトの選択肢がある場合であって、当該物理的なオブジェクトが、関連する情報を示す重要なものである場合には、ナビゲーションのユーザインタフェースにおいて物理的なオブジェクトの方向性を決定することが可能である。しかし、もし、各ユーザによるものから選択するために、多くのオブジェクトがある場合には、複雑なナビゲーションをすることがさらに要求されるだろう。例えば、もし、学校での避難において、五棟の建物と、当該建物内に様々な場所があるとする。避難とは、場所（に関すること）であり、且つその結果として、オブジェクトが関係するので、オブジェクトの方向性を決定することとして、建物に基づく避難情報はあり得る。また、校内の生徒のような緊急事態に関連する他のオブジェクトがある。しかし、日中の時刻に依存して、学級毎に、多くの異なる生徒がいる。怪我の種類の情報、及び天気又は呼吸の問題のような状況に関係する情報のような、多くの情報はこれら二つの物理的なオブジェクトに容易に関係しないので、生徒又は建物に基づく情報を発見するためにシステムをナビゲーションすることは、困難であるだろう。

関連するオブジェクトを表示するためのビジネスオブジェクトの方向性を決定。ビジネスオブジェクトのナビゲーションの方向性を決定することは、例えば、安全指示ドキュメントを介することであるだろう。多くのプロセスの多くのプロセス段階があることにより、ユーザ毎の選択肢は多すぎるであろうから、関連する指示ドキュメントのようなビジネスオブジェクトの描画をユーザに表示することは、一つの問題である。パニックの場合における指示、怪我の場合における指示、人員の医療記録、場所に基づく代替の出口の経路等の情報が存在するので、ビジネスオブジェクトの方向性を決定することは困難である。ユーザの注意に対して正しいオブジェクトを提示するために、現在のプロセスのインスタンス化と、いくつかのオブジェクトの選別とが必要とされる。これは、オブジェクトに関係するプロセスを要求する。モデル無しでこれを行うことは、ソフトウェアの開発及びメンテナンスにおいて、非常に一貫性を欠くとともに困難なことである。正しいユーザに対して正しいタイミングで出力されるように、各オブジェクトは、そのために書かれたコードを有しなければならない。さらに、緊急事態の応答アプリケーションを定期的にアップグレードするには、新しいソフトウェアのリリースが必要であるととともに、そのようなアップグレードは、システムをより複雑にするとともに、システムをナビゲーションすることをより複雑にするだろう。

ノード及びコンテクストの組に割り当てられたユーザを代理。緊急事態において利用可能な人員は、通常の企業ソフトウェアシステムのユーザの場合として、システムのデフォルトでの期待（予期；expectation）に応じたユーザでなくても良さそうである。そのため、開始時と、緊急事態が起きている時とでは、ユーザのアクセスに対する変更が必要になり得る。状況が進行している時、その場でこれを行うことは、本開示のオーバーレイモデルを伴う場合、又はプログラム的に予め設計された多数のインタフェースを伴う場合でのみ可能である。拡張を伴う多くのことがあるだろうから、プログラム的に予め定義された複数のインタフェースは、正しい使用のために、及び現在進行中の状況のために、割り当てられなくてなくてはならない。これは、緊急事態の応答のアプリケーションのための、方向性が決定されたモデルのタスクの設計及び実装段階で、巨大なリソースが必要とされるとともに、緊急事態中には、かなり困難な作業であるだろう。そして、現在起きている状況のためにプログラム的に予め設計された複数のインタフェースと、緊急事態での開発に応じたインスタンス化とが無いと、携帯機器においては、正しいオブジェクトにナビゲーションすることは非常に親和性が低いことであるだろう。

緊急事態を協調させるために使用されるＳＭＳメッセージ。ＳＭＳメッセージが現場から送信される場合には、それらは、解釈される必要があり、ノードに単語を割り当てる中心的なシステムが必要になるだろう。ＳＭＳメッセージを解釈することは、ノードに対して言語学的に適切な予想パターンを割り当てることが必要になるだろう。代替の案は、送信元から必要性を決定するところへＳＭＳメッセージの通信路を調整する、人々のチームを有することである。

従って、緊急事態応答アプリケーションは、オーバーレイの連続的なユーザインタフェースを利用することが望ましい。当該ユーザインタフェースは、原因と結果によって接続されたノードで明らかにされる企業のモデルによって実現できる。さらに、当該ユーザインタフェースは、新たな警告のために当該ユーザインタフェースの一部をインスタンス化できることによって実現できる。さらに、フォーカス対象の過去のノードを、ユーザが出力できるようにすること、又はユーザ／利害関係者に関連する、フォーカス対象の新しい領域を、ユーザが出力ができるようにすることによって、当該ユーザインタフェースは実現できる。

本開示は、特有な形態の見地から記載されたが、多数の代替、多数の修正、多数の変形が、当業者にとって明らかであるだろうことは、上述の記載の視点において明らかである。そのため、本開示は、本開示の範囲及び精神、及び請求項の範囲及び精神から逸脱しない、そのような全ての代替、全ての修正、全ての変形を包含することを意図するものである。

１ 企業
１１ 企業のゴール
１２、４２、４８、７５、７６、８１、７００、７１０、８０１、８０２ プロセス
１３ プロセスの一部；プロセスノード
１４ 企業内部コンテンツ及びデータ；内部／外部コンテンツデータ
１５、６３ アクター
１６ オーバーレイソフトウェア
１７ プロセスノードについての検討
２１ プロセスノード；プロセスノード及び関係する検討
２２ 単語表現；プロセスノードを記載する単語表現
２３ 自然言語サーチ；オーバーレイ自然言語サーチ
２４ 企業のデータ及び内部コンテンツ；企業のデータ／コンテンツ
３２ 企業活動及びオブジェクト
３３ 認識構造
４１、４４、８２、８３ ゴールの組
４３、４３−１、４３−２、４３−３、４６、４９、５０ ステップ
４５ プロセス；航行プロセス
４７ ゴール
６１、６２ 矢印
６４ スキル、価値、知識
６５ オブジェクト
６６ コンテクスト
７１ 高いレベルのゴールの組
７２、７３、７４ 子ゴールの組
７７ 包括的なプロセス
７８ 包括的なプロセスのサブステップ
８０ 機会又は予期しないイベント；問題／機会／イベント；問題、機会又は予期しないイベント
８５―８８、７０１―７０５、１２０６、１２０６´ ノード
１００ ウェブ（Ｗｅｂ）
７１１―７３３ プロセスステップ
８１１、８１２ 下位のゴールの組
９０１−９１２、９２１−９２５、１０７１−１０８０、１１８１−１１８３、１０１０−１０２６ 工程
９２０ エキスパートユーザ
９３０ ノード属性；属性
９３１ 属性
９３２ 高いレベルの属性；属性
９４０ オーバーレイシステム；システム
１００１問題、機会、決定、又は質問
１０２４ａ―１０２４ｅ、１１７０、１２０４、１２０４ａ―１２０４ｅ ユーザインタフェース
１０７０ コンテクスト特有プロセス；元のプロセス
１０８１ 分野
１０８２ ノード属性
１１０１ コンテンツスキャナー；スキャナー
１１０２ ｅ−ｍａｉｌ
１１０３ ドキュメント
１１０４ ビジネスオブジェクト；アプリケーションデータ
１１０５ ウェブコンテンツ
１１０６ 事象の履歴
１１０７ 企業内における問題解決の事象；企業内における問題解決
１１１０ 走査されたコンテンツ
１１２０ 言語構文解析装置
１１３０ インデックスモデル
１１５０ インデックスエンジン
１１６０ 重要点インデックス
１１７１ ウェブベースのサーチインタフェース；ウェブベースのサーチ
１１７２ ウェブベースの連携ツール；ウェブベースの連携
１１７３ アプリケーション統合のためのポータルベースのインタフェース；アプリケーション統合
１１７４ 携帯機器のインタフェース；携帯機器
１１７５ インタフェース；オフィス／ｅ−ｍａｉｌアプリケーション
１１８０ システムに複数の事象を定着されるための手順；システムに定着させる
１１８５ インデックスストーリー；ストーリー
１１８６ 事象
１１８７ インデックスエンジン；インデックス
１２００ システム
１２０２ 機能
１２０８ 制限された領域のディスプレイ；表示スクリーン
１２０８ａ―１２０８ｅ 表示領域；ディスプレイ
１２１０ キーボード
１２１２ リモートセンサ
１２１４ リモートサイト；リモートデータベース
１２１６ インターネット；伝送機能
１２１６ａ インターネット
１２１８ コンピューティングデバイス
１２２０ 伝送機能；伝送機器
１２２２ 携帯電話ネットワーク；ローカル無線ネットワーク
１２２４ データベース
１２２６ コード化された関係性
１２３０ メンバ
１２３２ 消防署の職員；企業参加者ではない者
１２３４ 警察署；企業参加者ではない者
１２３６ 医療従事者；企業参加者ではない者
１２３８ 環境保護局；企業参加者ではない者
１２４０ａ―１２４０ｅ 企業のメンバ
１２４２ 連絡
１２５２ ノード（火災）
１２５４ ノード（洪水）
１２５６ ノード（侵入者）
１２５８ ノード（問題の現場）
１２６０ ノード（安全な場所に到着した人の数）
１２６２ ノード（数えられていない人の数）
１２６４ ノード（現地での緊急事態の装置）
１２６６ ノード（出口の場所）
１２６８ ノード（安全な場所にいる人の医療状況）
１２７０ ユーザ入力ノード；クエリー
１５００ 共通のゴール
１５０２ ノードＡ；抽象化されたノード
１５０４ ノードＢ；抽象化されたノード
１５０６ ノードＣ；抽象化されたノード
１５０８ ノードＤ；抽象化されたノード
１５１０ 中間ゴールＥ
１５１２ 中間ゴールＦ

Claims (35)

1. 複数の携帯端末とセントラルアプリケーション制御機能を含むシステムであって、前記携帯端末は、通信リンク、ディスプレイ及び電源を備え、
   前記複数の携帯端末は、前記セントラルアプリケーション制御機能と通信し、前記セントラルアプリケーション制御機能は、非一時的なデジタル記憶媒体上にエンコードされた実行可能な命令を有する、コンピュータ読み取り可能媒体を備え、前記非一時的なデジタル記憶媒体は、企業のモデル、企業のコンテンツ及び企業のデータをも格納する、コンピューティングデバイスを含み、
   前記モデルに関連付けられたプロセスは、複数のノードと、コンピュータが読み取り可能な、異なるノード間の関連性の記述と、コンピュータが読み取り可能な、コンテンツ、データ及び異なるノード間の関連性の記述と、を含み、
   前記ディスプレイは、
   第１の所定の瞬間にて全てのノードよりも少ないノードが視認可能となるような限られた領域と、前記コンピューティングデバイスと通信して、第１の所定の瞬間に表示される相互に関係するノードを特定する機能と、を備え、
   前記コンピューティングデバイスは前記複数の携帯端末と通信し、
   前記コンピューティングデバイスは、異なる情報パケットをそれぞれの携帯端末に向けて送信し、及びそれぞれの携帯端末から異なる情報パケットを受信し、前記情報パケットのそれぞれは、各ユーザに割り当てられたノードに依存し、
   前記送信される各パッケージは、ユーザにより引き起こされた相互作用に対する設計された応答と、原因と結果からユーザに割り当てられたノードの状態を変更する前記コンピューティングデバイスにより検出された、システムの任意のノードの状態の変化と、に依存する、ことを特徴とする、システム。
2. 相互に関係するノードの状態は、前記非一時的なデジタル記憶媒体にエンコードされたコンピュータコードにより定まり、相互に関係するノード間の関係は動的である、請求項１のシステム。
3. 前記相互に関係するノードの状態は、前記コンピューティングデバイスと前記複数の携帯端末間の通信に基づき変化する、請求項２のシステム。
4. 利害関係者のゴール階層が変化する状況に応じて、後に続くプロセス間の関連性を変更する、新たな緊急事態オーバーレイノードネットワークが適用される、請求項２のシステム。
5. 前記携帯端末のそれぞれは、
   前記携帯端末と一体、且つ、前記携帯端末と通信するディスプレイを備える、請求項１のシステム。
6. 前記第１の所定の瞬間にて視認可能なノードは、相互に関係するノードであって、ユーザに関する情報にアクセスすることを許可するノードである、請求項５のシステム。
7. 前記コンピューティングデバイスは、前記第１の所定の瞬間にて表示されている、前記相互に関係するノードを特定するために、前記携帯端末と通信する、請求項６のシステム。
8. 前記コンピューティングデバイスは、進行中のイベントの状況状態にアクセスし、時間と状況状態の関数として前記相互に関係するノードの組み合わせを変更する、請求項７のシステム。
9. 前記携帯端末のそれぞれは、前記機能により特定された前記相互に関係するノードの前段及び／又は後段に連続するノードを表示することができる、請求項７のシステム。
10. ユーザインターフェイスは、（i）子ノードを親ノードに折り畳む、（ii）子ノードを親ノードの下に展開する、（iii）拡大、縮小する、のうち１つ以上の予め定めた任意の瞬間にて、前記ディスプレイにて視認可能な相互に関係するノード数をユーザが変更することを可能とする、請求項９のシステム。
11. 前記ユーザインターフェイスは、予め定めた任意の瞬間にて、前記ディスプレイにて視認可能な相互に関係するノードの数をユーザが増やすことを可能とする、請求項１０のシステム。
12. 前記ユーザインターフェイスは、予め定めた任意の瞬間にて、前記ディスプレイにて視認可能な相互に関係するノードの数をユーザが減らすことを可能とする、請求項１０のシステム。
13. 予め定めた任意の瞬間にて、全てのノードが前記ディスプレイにて視認可能となり得る請求項１０のシステム。
14. 企業に関するプロセスに関連する情報を発見し、変換するシステムであって、
    前記システムは、
    非一時的なデジタル記憶媒体上にエンコードされた実行可能な命令を有する、コンピュータ読み取り可能媒体を備え、前記非一時的なデジタル記憶媒体は、企業のモデル、企業のコンテンツ及び企業のデータをも格納する、コンピューティングデバイスを備え、
    前記モデルに関連付けられたプロセスは、複数のノードと、コンピュータが読み取り可能な関連性であって、コンピュータが読み取り可能な原因と結果として表現される、異なるノード間の関連性の記述と、コンピュータが読み取り可能な、コンテンツ、データ及び異なるノード間の関連性の記述と、を含み、
    変換値がソフトウェアコードにより１以上の隣接ノードに割り当てられ、前記ソフトウェアコードは、当該ノードと隣接ノードを接続する際の、コンピュータが読み取り可能な原因と結果を定め、
    前記システムは、
    前記コンピューティングデバイスと通信し、企業重要点に関するデータの入出力ができるデバイスと、
    携帯端末に関連付けられたインターフェイスであって、問題を解決する、機会を利用する、イベントを理解する、の少なくともいずれかにおいてユーザを支援可能な、コンテンツ及びデータをユーザに提供し、ノードが第１の所定の瞬間で視認可能なディスプレイを備える、ユーザインターフェイスと、
    を含む、システム。
15. 前記ディスプレイは、携帯端末と一体、且つ、携帯端末と通信し、前記第１の所定の瞬間にて全てのノードよりも少ないノードが視認可能となるような限られた領域を有する、請求項１４のシステム。
16. 前記第１の所定の瞬間にて視認可能なノードは、相互に関係するノードであって、ユーザに関する情報にアクセスすることを許可するノードである、請求項１５のシステム。
17. 前記コンピューティングデバイスは、前記第１の所定の瞬間にて表示されている、前記相互に関係するノードを特定するために、前記携帯端末と通信する、請求項１６のシステム。
18. 前記コンピューティングデバイスは、進行中のイベントの状況状態にアクセスし、時間と状況状態の関数として前記相互に関係するノードの組み合わせを変更する、請求項１７のシステム。
19. 前記携帯端末は、前記機能により特定された前記相互に関係するノードの前段及び／又は後段に連続するノードも表示する、請求項１７のシステム。
20. 前記ユーザインターフェイスは、（i）子ノードを親ノードに折り畳む、（ii）子ノードを親ノードの下に展開する、（iii）拡大、縮小する、のうち１つ以上の予め定めた任意の瞬間にて、前記ディスプレイにて視認可能な相互に関係するノード数をユーザが変更することを可能とする、請求項１８のシステム。
21. 前記ユーザインターフェイスは、予め定めた任意の瞬間にて、前記ディスプレイにて視認可能な相互に関係するノードの数をユーザが増やすことを可能とする、請求項２０のシステム。
22. 前記携帯端末は、企業にとって最大のリスクを示すようなノードを表示する、請求項１８のシステム。
23. 予め定めた任意の瞬間にて、全てのノードが視認可能となり得る請求項２０のシステム。
24. 前記隣接するノード間の関連性は、コンピュータが読み取り可能な原因と結果から導出される、請求項１４のシステム。
25. ノードに関連付けられた状態モデルにおける値の変更は、コンピュータが読み取り可能であって、ノードと隣接ノード間のコンテンツ及びデータの関連性の記述の変更を必要としない、請求項１４のシステム。
26. オーバーレイシステムにおいて現実世界のプロセスをエミュレートする方法であって、
    前記方法は、
    複数のシステムプロセスステップを識別し、現実世界の基礎にあるプロセスの状態属性である属性を割り当て、
    ノードに関連する属性を当該ノードに関連付け、
    前記システムプロセスステップをノードによる複数のクラスタに構築し、
    コンピュータが読み取り可能な、ノード間の関係による原因と結果を確立し、
    根本的な、現実世界のプロセスの状態値と、状態モデルにおけるそれらの一意に定まる場所と、を識別するためにトランザクションなプロセスノードを使用し、
    各ノードに関する前記属性を各状態モデルに設定し、
    現実世界の基礎にあるプロセスの状態要素間の関係を決定するために、ノード間のコンピュータが読み取り可能な原因及び影響リンクを使用する、
    ステップを含む。
27. 各プロセスノードは、状態モデルの属性により特徴付けられる、請求項２６の方法。
28. 新たなノード又は新たな属性が特定された際、前記状態モデルは、当該ノード又は属性に対する値の記憶を可能とするように、自動的に拡張される請求項２７の方法。
29. 新たなノード又は新たな属性が特定された際、当該ノード又は属性はノードクラスタに追加され、前記ユーザインターフェイスは、前記新たなノードとその属性を収容するように自動的に拡張される、請求項２７の方法。
30. 既存のノード又は既存の属性が不活性である際、当該ノード又は属性はノードクラスタから取り除かれ、前記ユーザインターフェイスは、当該ノードとその属性を削除するように自動的に縮減される、請求項２７の方法。
31. 共通するゴールを達成するように必ずしも協力するように設計されていない２つの異なるシステム又はプロセスにおいて、少なくとも２つのプロセスを統合する方法であって、
    前記方法は、
    第１プロセスと第２プロセスの両方において有効であり十分に抽象的であるノードによる複数のクラスタノードの中から１つのノードクラスタを特定することを含み、
    前記ノードクラスタにおける各ノードは、１以上の中間ゴールを有する企業重要点を記述すると共に、前記各ノードは、当該企業重要点に関連するデータ及び／又はコンテンツを含み、
    前記ノードクラスタにおける各ノードは、前記ノードクラスタ内の他のノードとの間の原因及び影響の関係を備え、前記原因及び影響の関係は、コンピュータが読み取り可能な数学的なアルゴリズムにより表現可能であり、
    前記中間ゴールは、前記共通のゴールに収束する、方法。
32. 各プロセスノードは、状態モデルの属性により特徴付けられる、請求項３１の方法。
33. 新たなノード又は新たな属性が特定された際、前記状態モデルは、当該ノード又は属性に対する値の記憶を可能とするように、自動的に拡張される請求項３２の方法。
34. 新たなノード又は新たな属性が特定された際、当該ノード又は属性はノードクラスタに追加され、前記ユーザインターフェイスは、前記新たなノードとその属性を収容するように自動的に拡張される、請求項３２の方法。
35. 既存のノード又は既存の属性が不活性である際、当該ノード又は属性はノードクラスタから取り除かれ、前記ユーザインターフェイスは、当該ノードとその属性を削除するように自動的に縮減される、請求項３２の方法。

Images