JP5410581B2 - 分散ネットワークの、特に通信ネットワークの、リソース上のオペレーションを管理するための方法とシステム、および対応するコンピュータプログラムプロダクト - Google Patents

Description

本発明は、通信ネットワークの機器上などの、分散ネットワーク上で、命令信号を生成することを、および、前記命令信号に基づいて介入（または、より一般的には、オペレーション）を実行することを、可能にする技術に関する。

本発明は、ワークフォースの、およびカスタマの、オペレーションを管理および支援するための、分散プラットフォームの状況におけるその可能な使用に、特に注意を払って開発された。

新しいサービスをカスタマに提供するためのコスト、または障害および機能不良を除去するためのコストなどの、オペレーショナルプロセスのコストは、通信事業会社が毎年直面する必要があるコストのうちの大きなパーセンテージを示す。したがって、オペレータワークフォースとカスタマとの両方のアクティビティを支援し、その結果、カスタマ構内の機器に関連するトラブルの除去に直接関与することが可能なツールを介して、前記コストを削減することを目的とした、方法／システムは重要である。

障害／機能不良の修復のアクションに直接関与する、ワークフォースへの、およびカスタマへの支援は、ナレッジマネジメントシステム（ＫＭ）、または、より正確に言えば、オペレーショナルナレッジマネジメントシステム（ＯＫＭ）と、高度な管理プラットフォームとの、２つの主要なツールを使用することによって提供されることが可能であり、これらの２つのツールは、別個のエンティティとして見られるのではなく、統合された完全なソリューションの構成要素として見られる。

「ナレッジマネジメント（ＫＭ）」は、組織の知識の作成、普及、および使用を可能にするアクティビティを意味する。ＫＭへのさまざまなアプローチの中で、企業が一般に好むのは、知識の一部の管理と、特定の目的（例えば、意志決定、問題解決など）とに焦点を合わせた、局所的なアプローチである。オペレーショナルナレッジマネジメント（ＯＫＭ）」は、オペレーション知識の管理に焦点を合わせた、知識管理への局所的なアプローチである。このタイプの知識は、特定のジョブまたは特定のアクティビティを実行するために必要な、方法および技術（オペレーショナルプラクティス）を含む。ＯＫＭＳの一般的なユーザは、企業のフィールドエンジニア、およびコールセンタアドバイザである。

これらの技術の現在の発展レベルを表すＫＭ／ＯＫＭシステムは、例えば、米国特許出願公開第２００４／００４４５４２号明細書、および、Ｇ．ＶａｌｅｎｔｅとＡ．Ｒｉｇａｌｌｏによる論文「Ｒｅｍｏｔｅｒ：ａｎ Ｏｐｅｒａｔｉｏｎａｌ Ｋｎｏｗｌｅｄｇｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ ｆｏｒ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｏｐｅｒａｔｏｒｓ」（Ｗｏｒｋｓｈｏｐ ｏｎ Ｋｎｏｗｌｅｄｇｅ Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｏｒｇａｎｉｚａｔｉｏｎａｌ Ｍｅｍｏｒｉｅｓ、１６ｔｈ Ｅｕｒｏｐｅａｎ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ（ＥＣＡＩ）、２００４年）に記載されている。

上記の文献に記載されているソリューションは、通信事業会社のワークフォースによって（カスタマ苦情に対処するために、または、新しいサービスのカスタマ要求を満足するために）、あるいは、さらには、カスタマの構内における機器に対するセルフケアのアクティビティに直接関与する、カスタマ自身によって、実行されてもよいアクティビティなどの、問題解決アクティビティを支援するためのツールとして提案されている。

特に、米国特許出願公開第２００４／００４４５４２号明細書には、所与の企業の技術スタッフ間での、前記スタッフとユーザとの間での、およびユーザと他の企業の技術スタッフとの間での、知識の収集および共有のための、方法およびシステムが記載されている。前記方法およびシステムは、さまざまな領域に適用可能であり、その中で、電気通信サービスの領域にも適用可能で、事例ベース推論およびモデルベース推論のアプローチを使用して、問題解決アクティビティへの支援を提供する。

ＶａｌｅｎｔｅとＲｉｇａｌｌｏによる論文では、代わりに、リモータ（Ｒｅｍｏｔｅｒ）と呼ばれるオペレーショナルナレッジマネジメント（ＯＫＭ）のシステムが定義されており、前記システムは、通信事業会社の技術者を、それらの技術者の日常のアクティビティの間に支援するために、電気通信の状況で使用される。特に、リモータ（Ｒｅｍｏｔｅｒ）は、技術者が短時間で対応し最良のソリューションを選択する必要がある、ＡＤＳＬサービスのプロビジョニングと保証のプロセスの状況において、使用およびテストされている。このシステムの目的は、技術者が、最適な決定をリアルタイムで行うために、それらの技術者のオペレーション知識を共有、収集、および適用することを可能にすることである。前記システムは、問題解決を支援するために、対話型事例ベース推論アプローチを使用する。

特許文献国際公開第２００５／０１８２４９号パンフレットには、電気通信ネットワークおよび支援されるサービスの、分散管理のための、エージェントパラダイムに基づく、高度の柔軟性と拡張性とを有するシステムアーキテクチャが記載されている。前記アーキテクチャのキーポイントは、次のとおりである。

−ワークフローエンジンとルールエンジンとに関連付けられ、３つの階層レベルに構成された、分散エージェントに基づく、ネットワークおよびサービス管理のためのプラットフォーム。

−（アプリケーションの）構成要素の調整に使用されるだけでなく、プラットフォームの機能と動作のすべての側面の柔軟な実装のためにも使用される、プロセスエンジン（ワークフローエンジンおよびルールエンジン）。

−プロセスエンジン内で使用するためにプラットフォーム全体にわたって分散される、すべてのプロセス記述およびネットワークリソース情報モデルの、定義、マスタストレージ（マスタデータベース）、および管理のための、集中型のモデルインベントリ（モデルデータベース−ＭＤＢ）。

−ネットワークをＯＳＳの管理機能から分離し、ネットワークとリアルタイムで整合させられたデータベースを提供する、分散型のネットワークインベントリレイヤ。
−負荷バランシングおよび耐故障性の側面を含む、アプリケーションの好都合な分散を可能にする、コードモビリティの技術の使用。

Ｓｔｅｐｈｅｎ Ｃｏｒｌｅｙらの論文「Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｃｅｓｓ Ｉｎｔｅｇｒａｔｉｏｎ Ｕｓｉｎｇ Ｓｏｆｔｗａｒｅ Ａｇｅｎｔｓ：Ａ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ ａ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ａｇｅｎｔ Ｏｒｉｅｎｔｅｄ Ｗｏｒｋｆｌｏｗ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍｓ」（ＥＵＲＥＳＣＯＭ ＰＲＯＪＥＣＴ Ｐ８１５、［オンライン］２００１年１月、１〜９２ページ、ＸＰ００２３４３３０７、インターネットから取得：ＵＲＬ：ｈｔｔｐ／／ｗｗｗ．ｅｕｒｅｓｃｏｍ．ｄｅ／〜ｐｕｂ−ｄｅｌｉｖｅｒａｂｌｅｓ／Ｐ８００−ｓｅｒｉｅｓ／Ｐ８１５／Ｄ１／ｐ８１５ｄ１ｖｏｌ２．ｐｄｆ）には、エージェント指向ワークフロー管理システムのフレームワークが記載されている。ドメイン内（すなわち、ローカルビジネス組織内の）調整アーキテクチャは、ビジネスプロセスリポジトリ（Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｒｅｐｏｓｉｔｏｒｙ）、ドメインレプリゼンタティブ（Ｄｏｍａｉｎ Ｒｅｐｒｅｓｅｎｔａｔｉｖｅ）、リソースプロバイダエージェント（Ｒｅｓｏｕｒｃｅ Ｐｒｏｖｉｄｅｒ Ａｇｅｎｔｓ）、パーソナルユーザエージェント（Ｐｅｒｓｏｎａｌ Ｕｓｅｒ Ａｇｅｎｔｓ）、およびワークフロープロバイドエージェント（Ｗｏｒｋｆｌｏｗ Ｐｒｏｖｉｄｅ Ａｇｅｎｔｓ）を含む。ワークフロープロバイダエージェント（Ｗｏｒｋｆｌｏｗ Ｐｒｏｖｉｄｅｒ Ａｇｅｎｔｓ）は、ワークフローエンジンを含み、ドメイン内ワークフローを担当する。パーソナルユーザエージェント（Ｐｅｒｓｏｎａｌ Ｕｓｅｒ Ａｇｅｎｔ（ＰＵＡ））は、ワークフロー管理システムのユーザに知的インタフェースを提供し、ＧＵＩ ＰＵＡまたは知的ＰＵＡであってもよい。前者の場合、ユーザがワークフロー制御オペレーションを要求すると、ＧＵＩは要求をＰＵＡエージェントに転送し、ＰＵＡは、実現に着手するために、ＷＰＡと通信を行う。後者の場合、ＰＵＡは、その環境内の変化を検知する機能を有し、何らかの目的を達成するためにそのＰＵＡが定義した計画に従って、それらの変化に対処する。このエージェントは、推論、計画、および学習機能を有する。アクションは、Ｊａｖａオブジェクトメソッドとして実装される。

米国特許第５，８２６，２３９号明細書は、複数のプロセスアクティビティを含むワークフロープロセスを実行するために、複数のリソースを管理する、ワークフロー管理ソフトウェアシステムの制御下で動作しているコンピュータネットワーク内での、分散リソース管理のためのシステムおよび方法に関する。ワークフロープロセス管理システムソフトウェア、リソースマネージャ、リソースデータ、イベントハンドラ、およびリソースプロキシを含む、リソース管理のための、米国連邦政府のＯｐｅｎＰＭシステムが記載されている（図１２を参照）。
米国特許出願公開第２００４／００４４５４２号明細書 国際公開第２００５／０１８２４９号パンフレット 米国特許第５，８２６，２３９号明細書 Ｇ．ＶａｌｅｎｔｅとＡ．Ｒｉｇａｌｌｏによる論文「Ｒｅｍｏｔｅｒ：ａｎ Ｏｐｅｒａｔｉｏｎａｌ Ｋｎｏｗｌｅｄｇｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ ｆｏｒ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｏｐｅｒａｔｏｒｓ」（Ｗｏｒｋｓｈｏｐ ｏｎ Ｋｎｏｗｌｅｄｇｅ Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｏｒｇａｎｉｚａｔｉｏｎａｌ Ｍｅｍｏｒｉｅｓ、１６ｔｈ Ｅｕｒｏｐｅａｎ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ（ＥＣＡＩ）、２００４年） Ｓｔｅｐｈｅｎ Ｃｏｒｌｅｙらの論文「Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｃｅｓｓ Ｉｎｔｅｇｒａｔｉｏｎ Ｕｓｉｎｇ Ｓｏｆｔｗａｒｅ Ａｇｅｎｔｓ：Ａ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｏｆ ａ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ａｇｅｎｔ Ｏｒｉｅｎｔｅｄ Ｗｏｒｋｆｌｏｗ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍｓ」（ＥＵＲＥＳＣＯＭ ＰＲＯＪＥＣＴ Ｐ８１５、［オンライン］２００１年１月、１〜９２ページ、ＸＰ００２３４３３０７、インターネットから取得：ＵＲＬ：ｈｔｔｐ／／ｗｗｗ．ｅｕｒｅｓｃｏｍ．ｄｅ／〜ｐｕｂ−ｄｅｌｉｖｅｒａｂｌｅｓ／Ｐ８００−ｓｅｒｉｅｓ／Ｐ８１５／Ｄ１／ｐ８１５ｄ１ｖｏｌ２．ｐｄｆ）

前に参照した最初の２つの文献（米国特許出願公開第２００４／００４４５４２号明細書、およびＶａｌｅｎｔｅとＲｉｇａｌｌｏの論文）に記載されたシステム内で使用される方法は、提供される機能に関して、３つの欠点に由来する制限を示すということを、本出願人は観察した。

まず第１に、それらは、ネットワークおよびサービス管理を担当するシステム／プラットフォームとの直接的な相互作用を提供しない。そのような直接的な相互作用は、例えば、技術スタッフによるジョブの正しい実行のリアルタイム検査、必要とされるネットワークデータのプロアクティブな供給、およびネットワーク上での標準コマンドの自動実行などに関連する利点を活用することにより、問題解決アクティビティの実行時間の大幅な削減を可能にする。

第２に、それらは、共有される知識を、（ワークフローなどの）形式的ツールを使用して表さない。形式的ツールは、実行されるアクティビティの、曖昧でない、容易に理解可能な記述を介して、技術者の労働時間の削減を可能にする。そのような形式的表現は、さらに、供給される指示の、技術者による、解釈の任意のあり得る困難、または任意の誤った解釈を防止する。そのような解釈の困難、または誤った解釈は、技術者によるオペレーションの対象となるネットワークにとって、役に立たない、または有害でさえあるアクティビティの実行をもたらす可能性がある。

最後に、当該のシステムは、技術スタッフを、問題解決アクティビティを実行するために従うべきすべてのステップを通して、完全な、統合された、網羅的な方法で導かない。そのような方法は、対話型事例ベース推論などの方法を使用して導き出された、実行されるべき個々のアクティビティの、または調べられるべき特定の文献の、時間通りの提案を提供する。完全なガイドは、技術者の労働時間の削減と、未経験の技術者のより速い組み入れとの、両方を可能にする。

Ｃｏｒｌｅｙらの論文、および米国特許第５，８２６，２３９号明細書に関して、本出願人は、これらの文献は、オペレーション知識を管理するためのソリューションではなく、ビジネスプロセスを管理するためのソリューションを記載しているということを指摘する。ワークフローは、したがって、ビジネスモデルを表現および実行するために使用されるものであり、特定のジョブまたは特定のアクティビティを実行するために必要とされるオペレーション知識を表現し、オペレータまたはユーザによる対話的な使用のためにそれを利用可能にすることのための専用のものではない。

同様に、ネットワーク／サービス管理のための、システム／プラットフォームのフレームワーク内で、エージェントベースの分散型アーキテクチャを想定する、高度なソリューションが利用可能である。

その点に関して、上記の国際公開第２００５／０１８２４９号パンフレットに記載されたアーキテクチャは、ネットワーク管理において非常に効果的かつ効率的であるが、通信事業会社のワークフォースのアクティビティを支援するためのいかなるＫＭ／ＯＫＭ機能も想定しない。

したがって、上に概説した固有の欠点を克服することによって、いくつかの重要な機能的特徴を示す、オペレーショナルアクティビティの管理のための、利用可能な革新的ソリューションを有する必要性が、明白に出現する。

これらの特徴のうちの、第１の特徴は、ネットワーク／サービス管理を担当するシステム／プラットフォームとの、自動的な、および支援された相互作用の可能性であり、そのような相互作用の目的は、以下を可能にすることである。

−供給された提案の正しい実行の、管理対象のネットワーク／サービス上での、リアルタイム検査により、システムのユーザに即時のフィードバックを返す。
−実行されるアクティビティと同期した、前記アクティビティを進めるために必要なデータ（設定データ、測定データなど）の自動供給。

−フィールドエンジニア／オペレータのアクティビティの、標準的と見なされるステップの自動実行。例えば、エラーのあらゆる可能性をなくし、必要とされる時間を減らすための、事前定義されたパラメータによる、ネットワークカードの設定。

第２の望ましい特徴は、ワークフォースに供給される提案が、以下の利点を有する、（ワークフローなどの）形式的ツールによって表されなければならないということである。 −所与の介入を正常に遂行するため、またはカスタマ要求に効果的に対処するために実行されるアクティビティの、曖昧でない、容易に理解可能な方法による記述。

−ベストプラクティスの、（例えば、適切なスコアによる）即時の強調。
−自動機構によっても支援されている可能性がある、アップグレードおよびアップデートのアクティビティに関する知識の、より単純な管理を可能にする。

さらに別の、確かに望ましい重要な特徴は、所与の介入を実行するために必要な（フィールドエンジニア）、または所与のカスタマ要求に応えるために必要な（コールセンタアドバイザ）、すべての具体的なステップを、システムは、自律的に、かつ完全に指示することが可能でなければならないということである。それらのステップは、対話型事例ベース推論などの方法を使用して導き出された、実行されるべき個々のアクティビティの、または調べられるべき特定の文献の、時間通りの提案を提供する。

現在の管理プラットフォームは、管理の側面に関して最先端ではあるが、企業のビジネスプロセスの重要なステップの実行を依然として任せられているワークフォースを支援するための適切なツールは提供せず、そしてＯＫＭシステムに統合されていないということを、特に注記することができる。

したがって、これらの制限を克服することが可能なソリューションを利用できるようにする必要がある。特に、柔軟で拡張性のある高度な管理アーキテクチャを根幹とし、革新的なＯＫＭ機能を導入し、オペレーショナルプラクティスの形式的表現に基づき、オペレーションとネットワーク／サービス管理との間の統合を保証する、ワークフォースを支援するための完全なソリューションを利用できるようにする必要がある。

本発明の目的は、したがって、上記の必要に対する、完全に満足のいく対応を提供することであり、特に、所与の領域上で分散された機器のネットワークなどの、分散システム上での人的介入サービスを支援するための効率的な技術を提供することである。

上記の目的は、それぞれのオペレータまたはユーザの端末装置に関連付けられた、複数の介入管理プロキシエージェントと（各介入管理プロキシエージェントは、介入を実行するための指示を定義するワークフローまたはルールの処理に適した、プロセスエンジンを含む）、それらの装置のプロキシエージェントに、介入のタイプにより異なるワークフローまたはルールを提供するのに適した集中型リソースを含む、端末装置のオペレーションの管理および制御のためのシステムとを含む、分散オペレーション管理アーキテクチャを提供することにより達成されるということを、本出願人は見いだした。

本発明の一態様によれば、それぞれのオペレータの、またはユーザの、端末装置に関連付けられた介入管理プロキシエージェントの、分散型アーキテクチャが提供される。前記介入管理プロキシエージェントは、（ネットワーク機器などの）さらなる装置に対する介入を実行するための（ワークフローまたはルールの形態の）命令信号を生成するために、それらの装置と関連付けられたマネージャ手段（好ましくは、リソースプロキシエージェントを含む）と相互作用するように構成され、それにより、命令信号は、介入を必要としている装置の状態に応じたものとなる。

本発明の別の態様によれば、好ましくは、セルラー電話、携帯情報端末（ＰＤＡ）、またはラップトップ型パソコンなどの、ポータブル装置である、端末装置が提案される。端末装置は、ワークフローまたはルールベースのプロセスエンジンを備えた介入マネージャプロキシエージェントと、オペレータまたはユーザとの相互作用を可能にするパーソナルインタフェース（ＰＩ）とを含み、好ましくは、ワークフローまたはルールを遠隔リソースからダウンロードするように構成される。プロキシエージェントは、さらに、別の機器、装置、または設備上のソフトウェアアプリケーションとの通信のためのインタフェースを、ワークフローまたはルールの実行中にそのアプリケーションと情報を交換するために備えることが好ましい。

上記のアーキテクチャおよび端末装置は、電気通信ネットワークまたは配電ネットワークなどの、分散型ネットワークの設備に対する介入を実行するために適用されてもよいということを、本出願人は見いだした。ただし、本発明は、系統立った方法で、事前定義されたプロセスを柔軟な、かつ、好ましくは対話型の方式で活用することによって、そして、オペレーションの集中型の制御および管理を維持することによって、事前定義された特性の設備、機器、または装置に対して（例えば障害を解決するための）オペレーションを行うことを要求される、すべてのシナリオにおいて広い用途がある。

「介入」という用語は、したがって、例えば、端末装置と、外部の装置、設備、または機器との間での、診断、ハードウェア／ソフトウェア変更、または検査オペレーションのための相互作用を含むように、広義に解釈されるべきである。

本発明は、さらに、少なくとも１つのコンピュータのメモリ内にロード可能な、対応するコンピュータプログラムプロダクトに関し、そのコンピュータプログラムプロダクトは、コンピュータ上でそのプロダクトが実行された場合に本発明の方法のステップを実行するための、ソフトウェアコード部分を含む。本明細書で使用される場合、そのようなコンピュータプログラムプロダクトへの言及は、本発明による方法の実行を調整する目的のためにコンピュータシステムを制御するための命令を含む、コンピュータ読み取り可能な媒体への言及と同等であるとして理解される。「少なくとも１つのコンピュータ」への言及は、本発明が、分散型の、および／または、モジュール式の方法で実施される可能性を強調することを意図するものである。特許請求の範囲は、本明細書で提供される本発明の開示の、不可欠の部分を形成する。

本明細書に記載するソリューションの特定の実施形態は、通信ネットワーク内に含まれるネットワーク機器への介入を実行するための、ワークフロー内に配置される命令信号を生成するための方法であり、前記機器は、前記ネットワーク内の１つの機器の管理をそれぞれが担当するリソースプロキシエージェントに関連付けられ、方法は、
−介入管理プロキシエージェントの分散型アーキテクチャを提供するステップと、
−前記介入管理プロキシエージェントを介して、前記リソースプロキシエージェントとの対話形式で、前記命令信号を生成するステップ（それにより、前記命令信号は、前記ネットワーク内の、前記介入の実行対象となる機器の状態に応じたものとなる）とを含む。

その第１の態様によれば、本発明は、したがって、以下を含む分散型オペレーションシステムに関する。
−複数の端末装置。各端末装置は、プロキシエージェントを含み、プロキシエージェントは、ワークフローまたはルールを処理するための、ワークフローベースまたはルールベースのプロセスエンジンと、前記ワークフローまたはルールの少なくとも部分を表すための、ユーザインタフェース（好ましくは、対話型インタフェース）とを含む。

−前記端末装置への、前記ワークフローまたはルールの伝送を管理するように構成された、少なくとも１つの遠隔マネージャリソース。
特に、プロセスエンジンは、ワークフローベースエンジン、ルールベースエンジン、またはその２つの組み合わせであってもよい。選択は、実行されるオペレーションのタイプに依存してもよい。例えば、オペレータの現場介入に関連する支援機能は、フローチャートとして、より良く表されるのに対して、コールセンタの状況で、苦情ベースで診断を支援するための機能は、ルールの組によって、より良く表される。ただし、可能であり、かつ妥当である場合はいつでも、ワークフローの使用が好ましく、その理由は、それにより、ルールの対立およびルールの管理への対処の複雑さが回避されるからである。

プロキシエージェントは、好ましくは、前記ワークフローまたはルールの処理中に、さらなる装置のソフトウェアアプリケーションと情報交換を行うための、相互接続インタフェースを含む。

前記さらなる装置の前記ソフトウェアアプリケーションは、好ましくは、ワークフローベースまたはルールベースのプロセスエンジンを含み、前記端末装置の前記プロセスエンジンは、前記相互接続インタフェースを介して、前記さらなる装置のプロセスエンジンと相互作用するように構成される。

好ましくは、システムは、前記プロキシエージェントのオペレーションを調整するように構成された、オペレーショナルエージェントをさらに含む。
その上、システムは、好ましくは、前記オペレーショナルエージェントを管理および制御する機能を有する、オペレーショナルマネージャをさらに含む。

システムは、したがって、端末装置によって形成される下位レイヤと、管理および制御機能を有するオペレーショナルマネージャを含む上位レイヤとを含む、階層アーキテクチャを備えてもよい。

階層アーキテクチャは、プロキシエージェントのオペレーションを調整するように構成されたオペレーショナルエージェントを含む、中間レイヤをさらに含んでもよい。
オペレーショナルエージェントおよび／またはオペレーショナルマネージャは、それぞれの、ワークフローベースまたはルールベースのプロセスエンジンを含んでもよい。

端末装置のプロキシエージェントは、相互動作関係で、直接相互作用するように構成されてもよい。
システムは、ワークフローまたはルールによって定義されるプロセスのリポジトリをさらに含んでもよい。その上、システムは、データモデルのリポジトリを含んでもよい。

システムは、ワークフローまたはルールを端末装置に分散するための、コントロールエージェントをさらに含んでもよい。
システムは、ワークフローまたはルールの処理に関連したパフォーマンスデータを記憶するための、パフォーマンスデータベースをさらに含んでもよい。

システムは、プロキシエージェントによって実行されたプロセスを記憶するための、オペレーショナルログをさらに含んでもよい。
システムは、ネットワーク機器への介入を管理するように構成されてもよい。この場合、ワークフローまたはルールは、介入の実行対象となるネットワーク機器の状態に応じたものであることが好ましい。

その第２の態様によれば、本発明は、ワークフローまたはルールを処理するための、ワークフローベースまたはルールベースのプロセスエンジンを備えた、プロキシエージェントと、前記ワークフローまたはルールの処理中にユーザと相互作用することを可能にする、ユーザインタフェースとを含む、端末装置に関する。

プロキシエージェントは、好ましくは、遠隔マネージャリソースから、ワークフローまたはルールをダウンロードするように構成される。
装置は、有利には、例えば、現場での介入を可能にするための、ポータブル装置であってもよい。

プロキシエージェントは、さらなる装置のソフトウェアアプリケーションとの通信を、その装置と情報を交換するために行うための、相互接続インタフェースを含んでもよい。 さらなる装置のソフトウェアアプリケーションは、ワークフローベースまたはルールベースのプロセスエンジンを含んでもよく、前記プロキシエージェントのプロセスエンジンは、前記ソフトウェアアプリケーションのプロセスエンジンと協働するように構成される。

前記ソフトウェアアプリケーションは、プロキシエージェントを含んでもよい。この場合、端末装置のプロキシエージェントは、前記さらなる装置のプロキシエージェントとの通信セッションを自動的に起動するように構成されてもよい。

装置は、前記プロキシエージェントを、遠隔位置からダウンロードするように構成されてもよい。
ユーザインタフェースは、好ましくは、グラフィカルインタフェースを管理する。

プロキシエージェントは、好ましくは、前記ワークフローまたはルールの処理中の情報を記録するように構成される。
装置は、ユーザによってプロキシエージェントが起動されるように構成されてもよい。

そのさらなる態様によれば、本発明は、ユーザまたはネットワーク機器への介入を管理する方法に関し、方法は、
−ネットワーク機器への介入を管理するための介入管理プロキシエージェントの、分散型アーキテクチャを提供するステップ（前記介入管理プロキシエージェントは、端末装置に関連付けられ、ワークフローまたはルールベースエンジンを含む）と、
−少なくともユーザまたはネットワーク機器への介入を、前記介入管理プロキシエージェントのうちの１つを介して、前記機器と関連付けられた少なくとも１つの管理リソースとの対話形式で実行するための、命令信号を生成するステップ（それにより、前記命令信号は前記機器の状態に応じたものとなる）と、を含む。

管理リソースは、前記機器と関連付けられた、そして、ワークフローベースまたはルールベースのプロセスエンジンを備えた、リソースプロキシエージェントを含んでもよい。 各介入管理プロキシエージェントは、１つの端末装置と関連付けられてもよく、そして、１つのワークフローまたはルールベースエンジンを含んでもよい。

方法は、好ましくは、前記命令の少なくとも部分を表すため、および実行されるワークフローまたはルールと相互作用するために、前記介入管理プロキシエージェントのパーソナルインタフェースと関係するステップを含む。

方法は、前記分散型アーキテクチャを、以下を含む階層レイヤに配置するステップをさらに含んでもよい。
−前記介入管理プロキシエージェントのオペレーションを調整する、オペレーショナルエージェントのレイヤ。

−管理および制御機能を有し、前記オペレーショナルエージェントのオペレーションを監視する、オペレーショナルマネージャを含むレイヤ。
その上、方法は、複数の前記介入管理プロキシエージェント上での介入の分散実行を、前記オペレーショナルエージェントに割り当てるステップを含んでもよい。

あるいは、方法は、前記分散型アーキテクチャを階層レイヤに配置するステップを含んでもよく、１つのレイヤは、管理および制御機能を有する、そして、前記介入管理プロキシエージェントのオペレーションを直接調整する、オペレーショナルマネージャを含んでもよい。

方法は、前記介入管理プロキシエージェントのそれぞれに、１人のオペレータまたはカスタマを支援するタスクを割り当てるステップを含んでもよく、それにより、前記介入の実行は、前記管理および制御機能から分離される。

好ましくは、方法は、前記介入管理プロキシエージェントに、プロセスエンジンを提供するステップをさらに含む。
方法は、前記分散型アーキテクチャ内のすべての前記レイヤに、プロセスエンジンを提供するステップをさらに含んでもよい。

前記プロセスエンジンは、好ましくは、ワークフローベースまたはルールベースである。
方法は、好ましくは、提供されるそれぞれの命令情報に基づいてそれぞれの機能を実行するように構成された構成要素を、前記レイヤ内に含めるステップを含む。

方法は、前記命令情報内に、以下のうちの少なくとも１つを提供するステップをさらに含んでもよい。
−ワークフローおよびルールのうちの少なくとも１つを含む、プロセス定義。

−データモデル定義。
好ましくは、方法は、前記介入管理プロキシエージェントを、相互動作関係で、直接相互作用するように構成するステップを含み、それにより、前記命令信号のうちの少なくとも１つは、介入管理プロキシエージェント間の相互作用により生成される。

方法は、前記介入管理プロキシエージェントを、前記リソースプロキシエージェントとのピアツーピア相互作用のために構成するステップをさらに含んでもよい。
方法は、以下からなる群から選択された少なくとも１つのステップを実行するために、前記分散型アーキテクチャの少なくとも１つのレイヤに関連付けられたコントロールエージェントを提供する、さらなるステップを含んでもよい。

−前記分散型アーキテクチャの前記レイヤに、プロセス定義を分散するステップ。
−前記分散型アーキテクチャの前記レイヤに、データモデル定義を分散するステップ。 −前記分散型アーキテクチャの前記レイヤの状態を監視するステップ。

方法は、以下からなる群から選択された少なくとも１つのステップを実行するための、マネージャモジュールを提供するステップをさらに含んでもよい。
−前記コントロールエージェントを介した、前記分散型アーキテクチャの前記レイヤへのプロセス定義の分散を管理するステップ。

−前記コントロールエージェントを介した、前記分散型アーキテクチャの前記レイヤへのデータモデル定義の分散を管理するステップ。
−前記コントロールエージェントを介して、前記分散型アーキテクチャの前記レイヤの状態を監視するステップ。

本発明は、さらに、少なくとも１つのコンピュータのメモリ内にロード可能であり、かつ、上記の方法を実行するためのソフトウェアコード部分を含む、コンピュータプログラムプロダクトに関する。

次に、本発明を、添付の図面を参照して、単に例として説明する。

本発明に記載するプラットフォームの、可能な実施形態を示す、機能ブロック図である。 図１のプラットフォーム内でのオペレーション管理を表す、別の機能ブロック図である。 本明細書に記載するソリューション内で実行される、第１の手順のフローチャートである。 本明細書に記載するソリューションによって生成される、ワークフローの例である。 本明細書に記載するソリューション内で実行される、さらなる手順のフローチャートである。 本明細書に記載するソリューション内で実行される、さらなる手順のフローチャートである。 本明細書に記載するソリューション内で実行される、さらなる手順のフローチャートである。 図１および図２のプラットフォーム内で使用されるポータブル装置を概略的に示す。

本発明の基礎となる原理の正しい理解を容易にするために、本開示の中で、および添付の特許請求の範囲の中で使用される、いくつかの用語／頭字語の説明を有する用語解説を、以下に記載する。

ＷＦＭ（ワークフォースマネジメント）：通信事業会社の文脈では、これは、前記事業会社のワークフォースの管理を担当するソフトウェアアプリケーションの、ソフトウェアアプリケーション／セットである。対象となる特定の文脈では、移動するワークフォース（フィールドエンジニア）と、コールセンタのワークフォースとの両方の管理に使用されるアプリケーションの、アプリケーション／セットであるとして理解される。

オペレータ：これは、移動するワークフォース（フィールドエンジニア）として、専門分野別のワークフォース（内勤スタッフ）として、およびコールセンタアドバイザとして理解される、ワークフォースの一部である、会社スタッフのメンバーである。

マネージャモジュール−ＭＭ：これは、ワークフロー記述の分散、オペレーションを起動するための分散エージェントの呼び出し、管理制御などの、さまざまな調整アクティビティのために分散エージェントと通信を行う、ホスト上で動作するソフトウェアアプリケーションである。これは、適切な専用のグラフィカルユーザインタフェース（ＧＵＩ）を含んでもよい。

エージェント：これは、可能な持続的状態を有し、そのタスクを遂行するために他のエージェントとの（例えば、協調的な、および／または競争的な方法での）通信を必要とする、自律プロセスである。この通信は、非同期メッセージ交換を介して、かつ、明確に定義され、一般に認められたセマンティクスを有する、よく知られた言語（例えば、エージェント間通信言語（Ａｇｅｎｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｌａｎｇｕａｇｅ）−ＡＣＬ）を使用することによって、実施されてもよい。

プロキシ：これを介して、別の管理対象オブジェクト（例えば、オペレーションの支援の文脈では、ネットワーク機器またはＧＵＩ）への制御または介入を行うことが可能な、構成要素（エージェント）である。

ルール：ルールは、有効な推論を構築するためのスキームである。これらのスキームは、「ｉｆ」部を形成する、前提と呼ばれる一組の式と、「ｔｈｅｎ」部を形成する、結論と呼ばれるアサーションとの間の、「ｉｆ ＜ｘ＞ ｔｈｅｎ ＜ｙ＞ ｅｌｓｅ ＜ｚ＞」という形式の構文関係を確立する。「ｅｌｓｅ」部は任意選択である。これらの構文関係は、推論のプロセスの中で使用され、それにより、他のすでに知られているアサーションから、新しい真（ｔｒｕｅ）のアサーションに到達する。

ルールエンジン（または、ルールベースエンジン）：これは、プロセスルールを制御論理から（論理的に、および／または物理的に）分離するため、そして、データストア、ユーザインタフェース、およびアプリケーション間で、それらを共有するためのシステムである。ルールエンジンは、基本的に、非常に高度な「ｉｆ／ｔｈｅｎ」文インタープリタである。ルールエンジンは、実行時に、いずれのルールを適用するか、およびそれらがどのように実行されるかを、決定するために使用される。

ワークフロー：これは、プロセスの、全体的な、または部分的な、自動化として定義されてもよく、そのプロセスの間に、手続きルールの組に従って、ドキュメント、情報、またはタスクが、１つの参加者から別の参加者に、アクションのために渡される（Ｔｅｒｍｉｎｏｌｏｇｙ ＆ Ｇｌｏｓｓａｒｙ、ＷＦＭＣ−ＴＣ−１０１１、１９９９年２月、３．０）。ワークフローは、一連のタスクと、タスク間の、並列または択一分岐を含む、時間的および論理的依存性とを有する、フローチャートによって表されてもよい。ワークフローの形式的記述を可能にする、ＸＰＤＬ（ＸＭＬプロセス記述言語）などの、アドホックな言語が存在する。

ワークフローエンジン（または、ワークフローベースエンジン）：これは、手続き（ワークフロー）、手続き内のステップ、および各ステップのためのルールに関連する、すべての情報を有する構成要素である。ワークフローエンジンは、プロセスが次のステップに進む準備ができているかどうかを判定する。言い換えると、ワークフローエンジンは、ワークフローを実行するための構成要素である。

図１のブロック図は、国際公開第２００５／０１８２４９号パンフレットに記載されている、電気通信ネットワークおよび関連するサービスの分散管理のためのプラットフォームと、分散オペレーション管理のためのプラットフォームとを含む、統合プラットフォームの好ましい実施形態を表す。

図示されているアーキテクチャ（これは、その上位レイヤにおいて、オペレーション支援システム（ＯＳＳ）を定義する）は、他の複数のオペレーション支援システム（ＯＳＳ）、複数のビジネス支援システム（ＢＳＳ）、および１つのワークフォースマネジメント（ＷＦＭ）システム（または、場合により、２つ以上のＷＦＭ）を含む、３種類の基本的なエンティティと相互作用する。管理の側面に関する限りでは、ＯＳＳとＢＳＳとは、バス（ＢＵＳ−例えば、ＴＩＢＣＯバス）を介して、ＭＡ１によって指定されているマスタアプリケーションと相互作用する。このアプリケーションは、モデルデータベース（ＭＤＢ）内に記憶されたプロセスおよび関連するデータモデルの、さまざまなエージェントアプリケーション（そのうちの１つはＡＡ１によって示され指定されている）およびリソースプロキシエージェントＲＰ１、．．．、ＲＰｎへの分散を管理する。各エージェントアプリケーションは、プロトコルアダプタＰＡを介して通信ネットワークＮとインタフェースをとる、１つ以上のリソースプロキシエージェントＲＰ１、．．．、ＲＰｎに依存する。ネットワークインベントリＮＩは、ネットワークインベントリ構成要素の通常の概念に一致し、ネットワークＮ内のリソースの、すべての仮想化（イメージ）の集まりであり、ＲＰから情報を取得して定期的に更新される。ネットワーク／サービス管理プラットフォームに関するさらなる詳細は、国際公開第２００５／０１８２４９号パンフレットから得ることができる。

図１で導入され、図２でさらに詳細に示されているように、オペレーション管理プラットフォームは、バスとインタフェースをとり、エキスパータイズインベントリＥＩおよびオペレーションログファイルＯＬと協働する、オペレーショナルマネージャＯＭを含む。オペレーショナルマネージャＯＭは、オペレーショナルエージェントＯＡ１、．．．、ＯＡｋのオペレーションを監視する。各オペレーショナルエージェントは、パーソナルインタフェースＰＩを介して複数の仮想チームＶＴ１、．．．、ＶＴｎとインタフェースをとる、１つ以上のパーソナルプロキシＰＰ１、．．．、ＰＰｎに依存する。各ＶＴは、例えば、フィールドエンジニア、内勤スタッフ、コールセンタアドバイザ、またはカスタマから構成される。

パーソナルプロキシ−ＰＰ１、ＰＰ２、．．．、ＰＰｎ（そのそれぞれがパーソナルインタフェースＰＩを備えている）は、オペレーショナルエージェントＯＡ１、ＯＡ２、．．．、ＯＡｋの組を含む、またはオペレーショナルマネージャＯＭを直接含む、アーキテクチャの上位階層レイヤに接続される。ＯＡが存在する場合、それらはさらに、ＯＭを含む上位階層レイヤに接続される。この階層化アーキテクチャにより、以下に記載するような、機能の柔軟性および拡張性が保証される。

好ましい実施形態では、ＰＰは、相互に通信を行い、有利には、さらに、図１で両方向の矢印ＰＴＰによって概略的に示されているように、リソースプロキシＲＰに（ＡＣＬ言語を使用して）接続される。これは、通常、パーソナルプロキシとリソースプロキシとの間のピアツーピアの関係を表す。この関係は、本明細書に記載するアーキテクチャが、介入管理プロキシ（すなわち、パーソナルプロキシ）を介して、リソースプロキシとの対話形式で命令信号を生成するという可能性を有効にし、それにより、それらの命令信号が、介入の実行対象となる機器の状態に依存するようになる。ｎ個のリソースプロキシＲＰ１〜ＲＰｎと、ｎ個のパーソナルプロキシＰＰ１〜ＰＰｎと、ｎ個の仮想チームとの、可能な存在への言及は、これらのエンティティのそれぞれが、あるいは任意数存在してもよいという点で、全く単に示唆するだけのものであるということを、当業者は容易に理解するであろう。

各ＲＰは、（ネットワーク内に、またはカスタマの構内に配置された）個々の機器の、いわゆる「イメージ」の作成、維持、および管理を担当する。イメージは、定義済みのデータモデルによる、機器のコンフィギュレーションの表現である。

各オペレーショナルエージェントＯＡ１、．．．、ＯＡｋは、パーソナルプロキシの組を調整する。オペレーショナルエージェントＯＡ１、．．．、ＯＡｋは、相互に作用することが可能であり、パーソナルプロキシおよびオペレーショナルマネージャＯＭと相互作用することも可能である。

各ホスト実行エージェント（すなわち、ネットワーク／サービス管理のための各エージェント、ならびに、パーソナルプロキシ、オペレーショナルエージェント、およびオペレーショナルマネージャなどの、それぞれの新しいエージェント）は、好ましくは、プラットフォームの制御および管理を担当するソフトウェアモジュールである、コントロールエージェントＣＡを１つ以上含む。

既に示したように、プラットフォームは、さまざまな構成要素によって実行されるアクティビティを支援する、データベース（ＤＢ）の組も含む。オペレーショナルデータベースＯＤＢは、プラットフォームに関連する、すべての機能的側面と、ワークフォースおよびカスタマの管理／支援の側面との、定義および記憶の単一の（論理的な）点である。ＯＤＢは、オペレーションの管理のためにプラットフォームの構成要素（ＰＰ、ＯＡ、およびＯＭ）によって使用される、プロセス記述（プロセス記述は、ワークフローまたはルールのいずれかである）の、およびデータモデル定義の、リポジトリである。

マネージャモジュールＭＭは、コントロールエージェントＣＡを介して、プロセス定義とデータモデル定義とを、オペレーション管理構成要素に分散する。まず、これにより、最も効率的かつ効果的なオペレーショナルプラクティス（ベストプラクティス）を、ワークフォース全体と、カスタマとが利用できるようになる。さらに、データモデル定義の拡散により、ワークフォースのメンバー間での調整が可能になり、したがって、特定の主題に関する支援を得るために照会されるべきエキスパートの、単純かつ高速な識別が可能になる。データベースＯＤＢには、その記入を可能にする、意図的に提供されるＧＵＩが関連付けられる。

モデルデータベースＭＤＢは、ネットワーク／サービス管理のためにプラットフォームの構成要素（図１に示す、ＲＰ、ＡＡ、およびＭＡ）によって使用される、すべてのプロセス記述（ワークフローおよびルール）と、処理されるデータのモデル（ネットワーク機器のモデルを含む）とを記憶する。

ＭＤＢは、ネットワーク／サービス管理の側面に関して、プラットフォームの機能を定義および管理するための、単一の点をユーザに提供する。
好ましい実施形態では、データベースＯＤＢおよびＭＤＢ内に記憶されるデータモデルを定義するために、ＳＩＤモデル（シェアード・インフォメーション・データ（Ｓｈａｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｄａｔａ）モデル、ＴｅｌｅＭａｎａｇｅｍｅｎｔＦｏｒｕｍ ＧＢ９２２リリース４．０（２００４年８月）、およびメンバー評価中のリリース４．５（２００４年１２月）のドキュメント一式）が使用される。

パフォーマンスデータベースＰＤＢは、プラットフォーム構成要素に関連するすべてのパフォーマンスデータの記憶の、単一の（論理的な）点であり、リソースの使用を最適化すること、およびベストプラクティスを識別することの、両方のために使用される。

最後に、プラットフォーム内にさらに存在するのは、オペレータによって、およびカスタマによって実行されるアクティビティのすべての記録の記憶の、単一の（論理的な）点である、オペレーショナルログ（ＯＬ）と、さまざまなＰＰによって管理される、オペレータプロファイルの、およびカスタマプロファイルのデータを含む、エキスパータイズインベントリＥＩである。

好ましい実施形態では、プラットフォームのオペレーショナルプロセスは、特定の機能を有する３つのレイヤに分割される。この選択は、レイヤの数を可能な限り少なく維持すること（したがって、従来のアーキテクチャの複雑さを回避すること）、および、分散型の様式と集中型の様式との間でのプロセスの自由な割り当てを可能にすること、という２つの必要を満足することを目的としている。これは、集中型のレイヤ１（または、オペレーショナルマネージャＯＭに対応する最上位レイヤ）と、完全な分散型のレイヤ２（または、オペレーショナルエージェントＯＡ１、．．．、ＯＡｋに対応する中間レイヤ）と、オペレーションを管理および制御機能から分離する、１つの独立したプロキシレイヤ３（または、パーソナルプロキシＰＰに対応する下位レイヤ）との存在を意味する。この分割は、さらに、例えば、レイヤ１における、エンドカスタマへの、製品のビューと、レイヤ２における、サービスのビューと、レイヤ３における、オペレーショナルビューなどの、異なるサービスビューも提供する。後で説明するように、構成要素ＰＰ、ＯＡ、ＯＭは、それらに提供されるそれぞれの命令情報に基づいて、それぞれの機能を実行するように構成され、命令情報は、ワークフローまたはルールなどのプロセス定義、またはデータモデル定義を含む。

各パーソナルプロキシＰＰ（以下では、簡略にするために、例えば、ＰＰ１、．．．、ＰＰｎにおけるように、添え字の列１〜Ｎを毎回繰り返すことは避け、図１および図２の図中に複数の形態で存在するその他のエンティティに関しても、同様のアプローチを採用する）は、さまざまなオペレーショナルアクティビティにおけるガイドと、（異なるオペレータ間の、またはオペレータとカスタマとの間の）協働の支援との、両方に関して、特定のオペレータの、または特定のカスタマの、アクティビティの支援を担当する。特に、協働の支援は、オペレータプロファイルとカスタマプロファイルとに基づき、これらのプロファイルは、データモデル内で表される。実際の更新されたデータを用いた、プロファイルのインスタンス化は、オペレーショナルマネージャＯＭによって、外部ＷＦＭシステムから来る情報（オペレータプロファイルの場合）、またはビジネス支援システムから来る情報（カスタマプロファイルの場合）を使用して実行され、パーソナルプロキシに伝えられる。

言い換えると、各パーソナルプロキシは、介入管理プロキシエージェントの役割を果たす。各パーソナルプロキシ（ＰＰ）は、対応するＰＰレベルに特有のプロセスを、プロセスエンジンＰＥを使用して実行する。これらのプロセスは、レイヤ３プロセスであると呼ばれ、（例えば、マクロオペレーションの定義のために）サブレイヤで構成されてもよい。レイヤ３の最上レイヤにおけるプロセスは、ＰＰが前記プロセスの呼び出しを介して上位レイヤ（通常は、オペレーショナルエージェントであり、場合により、その他の外部アプリケーション）に提供する、サービスを構成する。それらは、ＰＰが関連付けられたオペレータ／カスタマによって実行される、１つのアクティビティに対応するオペレーションを表す。既に以前に導入した、「介入管理」プロキシエージェントという用語は、これに由来する。パーソナルプロキシによって提供されるサービスの（したがって、介入の）例は、回線設定（ｃｒｏｓｓ−ｃｏｎｎｅｃｔｉｏｎ）の実行、モデムのインストールと設定、機器（ルータ、ＤＳＬＡＭなど）の障害の修復などであり、これらのそれぞれは、１つ以上の機器に対して実行されるアクティビティのシーケンスを含んでもよい。レイヤ３の最下レイヤにおけるプロセスは、パーソナルインタフェースＰＩによって提供されるサービスを使用する。

パーソナルプロキシＰＰによって管理されるオペレータプロファイルおよびカスタマプロファイルは、データモデル内で表される。このモデルは、意図的に提供されるＧＵＩを用いて定義され、データベースＯＤＢ内に記憶され、マネージャモジュールＭＭによって、コントロールエージェントＣＡを介して、パーソナルプロキシＰＰに分散され、パーソナルプロキシＰＰは、そのモデルをロードし、オペレーショナルマネージャＯＭによって送られた、外部システム（ＷＦＭおよびＢＳＳ）により取得された値を使用してインスタンス化する。再び、インスタンス化は、プロキシエンジンＰＥを使用することによって、柔軟な方法で実行される。このようにして、データモデルの変更および追加（オペレータ／カスタマプロファイルの更新、新しい種類のオペレータの導入など）には、プラットフォームの構成要素内での、いかなる明らかなソフトウェア変更も必要とされず、高度な柔軟性が達成される。

オペレータプロファイルの、およびカスタマプロファイルのデータは、エキスパータイズインベントリＥＩ内に記憶され、外部システム（オペレータプロファイルについてはＷＦＭシステム、カスタマプロファイルについてはビジネス支援システム）から取得された情報を使用することによって、ＯＭによって定期的に更新される。前述したように、プロファイルデータ内の変更も、関連するパーソナルプロキシＰＰに伝えられる。

オペレータは、したがって、仮想チームＶＴ１、．．．、ＶＴｎに、論理的にグループ分けされてもよい。仮想チームは、所与の知識を共有する、および／または、共通の問題に取り組む、オペレータの組を含む。仮想チームは、一般に、問題解決の効率を向上するため、および現場介入を最適化するために、ワークフォースの地理的区画に基づいて編成される場合がある。

パーソナルプロキシＰＰは、例えば、複雑な障害を修復するための、オペレータ間またはオペレータとカスタマとの間の協働への支援を提供するために、直接相互作用してもよい。好ましくは、パーソナルプロキシＰＰは、さまざまなネットワークリソースに関連付けられたリソースプロキシＲＰとの通信も行う。したがって、ＰＰは、コマンドを発行するため、構成データを、測定結果を、または、オペレータ／カスタマによる何らかの所与のアクションの、機器上での正常な実行の検査結果を収集するため、および、可能なコマンドラインインタフェースへの、リモートアクセスを利用可能にするために、ＲＰと相互作用してもよい。パーソナルインタフェースＰＩは、代わりに、パーソナルプロキシと、オペレータ（ワークフォースのメンバー）またはカスタマとの間の相互作用を、それらのオペレータまたはカスタマが作業中のアクティビティを支援するためにどのようなタイプの端末装置を使用する場合でも、管理することを担当する。

端末装置は、目的とする特定の用途に応じて、さまざまなタイプであってもよい。図８は、パーソナルプロキシＰＰを含む、本発明による端末装置ＴＤを概略的に示し、パーソナルプロキシＰＰは、さらに、ワークフローベースまたはルールベースのプロセスエンジンＰＥを含む。さらに、ユーザまたはオペレータと、プロセスエンジンＰＥによって実行されるワークフローまたはルールとの間の相互作用を可能にする、複数のウィジェットＷＩ（ユーザが相互作用するグラフィカル構成要素）によって構成されるパーソナルインタフェースＰＩも概略的に示す。プロセスエンジン（ＰＥ）によって実行されるワークフローまたはルールは、正しいデータを使用してウィジェットを表示することを担当する。このようにして、ユーザとの相互作用は、端末装置上で実行されるワークフローまたはルールによって完全に駆動される。

端末装置は、さらに、ネットワーク設備ＮＡのソフトウェアアプリケーションとの情報交換のために、そのソフトウェアアプリケーションと相互接続するための、パーソナルプロキシＰＰによって提供される相互接続インタフェースＩＮも含む。好ましくは、ソフトウェアアプリケーションは、ワークフローベースまたはルールベースのプロセスエンジンＰＥを備えた、リソースプロキシＲＰである。本発明の一態様によれば、端末装置は、フィールドエンジニアによる現場での介入に特に好適であるように、ＰＤＡ、ラップトップ型パソコン、またはセルラー電話などのポータブル装置である。あるいは、端末装置は、コールセンタワークフォースによって一般に使用されるような、デスクトップなどの固定装置であってもよい。

各ＰＩは、利用可能な装置タイプに基づいたＧＵＩの自動設定を含む、オペレータ／カスタマに向けたＧＵＩの管理を、パーソナルプロキシのためのサービスとして提供する。 各オペレーショナルエージェントＯＡは、ＰＰの組の調整と、レイヤ２に特有なプロセスの実行とを、プロキシエンジンを使用することによって担当する。これらのプロセスは、オペレーショナル介入の分散実行に関連し、サブレイヤで構成されてもよい。レイヤ２の最上レイヤにおけるプロセスは、外部から呼び出されてもよく、したがって、これらは、オペレーショナルエージェントＯＡによって、オペレーショナルマネージャＯＭまたはその他の外部システムに提供されるサービスである。レイヤ２の最下レイヤにおけるプロセスは、パーソナルプロキシＰＰによって提供されるサービス（すなわち、それらはプロセスを呼び出す）を使用する。

オペレーショナルエージェントＯＡは、新しいオペレーショナルプラクティスを支援するために、ソフトウェアのアップデートを必要としない。これは、マネジメントモジュールＭＭから、ＣＡを介して受信され、ＯＡレイヤによってロードおよび実行される、プロセス（ワークフローベースまたはルールベース）の柔軟性による。オペレーショナルエージェントＯＡは、例えば、地理的に分散したサイトに配置された機器を含む回路の作成などの、相互に関連しているオペレーショナルアクティビティの分散実行を支援するために、コミュニティプロトコル（メッセージの交換に基づく相互動作機構）を介して相互作用してもよい。

オペレーショナルマネージャＯＭは、管理レベルに特有なプロセスの実行の、第１レベルの調整を担当する。レイヤ１プロセスは、サブレイヤで構成されてもよく、プラットフォームの外部のエンティティ（例えば、ＷＦＭシステムまたはビジネス支援システム）との相互作用を必要とする機能、および／または、オペレーショナルエージェントＯＡのみによっては、容易なまたは効果的な方法で達成することができない、オペレーショナルエージェントＯＡ間の調整を必要とする機能を提供するために特徴付けられる。アーキテクチャの大きな柔軟性は、さらに、円滑な発展も可能にし、例えば、コミュニティプロトコルの拡張により、レイヤ１からレイヤ２へのプロセスの移行が可能になってもよい。

任意のレイヤのためのプロセスエンジンＰＥは、ワークフロー（すなわち、フローチャート）エンジン、ルールエンジン、またはその２つの組み合わせであることを目的としている。例えば、オペレータの現場介入に関連する支援機能は、フローチャートとして、より良く表されるのに対して、コールセンタの状況で、苦情ベースで診断を支援するための機能は、ルールの組によって、より良く表される。可能であり、かつ妥当である場合はいつでも、ワークフローの使用が好ましく、その理由は、それにより、ルールの対立およびルールの管理への対処の複雑さが回避されるからである。

本発明によれば、各パーソナルプロキシＰＰは、プロセスエンジンを含む。好ましくは、オペレーショナルエージェントＯＡも、プロセスエンジンを含む。さらに好ましくは、オペレーショナルマネージャＯＭも、プロセスエンジンを含む。プロセスエンジンは、したがって、プラットフォームの階層レイヤの各構成要素によって使用されることが好ましく、そして、可能な場合、それらは、パフォーマンスレベルを向上するために、構成要素自体が存在するのと同じホスト上に割り当てられる。オペレーショナルマネージャＯＭ、オペレーショナルエージェントＯＡ、およびパーソナルプロキシＰＰは、リアクティブおよびプロアクティブの両方である動作を示し、イベントに反応するが、プロセスを自発的に開始することも行う。

コントロールエージェントＣＡは、プラットフォームのさまざまなエージェント上への、ワークフローの分散およびデータモデルの分散と、リソースの使用の測定およびローカルエージェント（すなわち、ホスト上で実行されるエージェント）のパフォーマンスの測定と、そして最後に、リソース管理の局所的最適化とを担当する。測定結果は、マネージャモジュールＭＭに、および他のコントロールエージェントＣＡに送られる。

マネージャモジュールＭＭによって管理される、または、オペレーショナルエージェントＯＡの、およびパーソナルプロキシＰＰの、コントロールエージェントＣＡによって管理される、ホスト間のモビリティは、配備、負荷バランシング、および耐故障性の手順を、より効率的かつ自動的なものにする。エージェントが何らかの理由で「ダウン」した場合、解決方法は、別の実行中のホスト上にエージェントのクローンを作るか、またはそのホストにエージェントを移動することであってもよい。マネージャモジュールＭＭは、前記目的のために、コントロールエージェントＣＡを介して、オペレーショナルエージェントＯＡおよびパーソナルプロキシＰＰの動作状態を定期的に制御する。パフォーマンスを監視するためには、プラットフォームの構成要素は、さまざまなプロセスの実行の監視も行うことが可能でなければならない。パーソナルプロキシＰＰの場合、さまざまなプロセスの実行の監視は、ベストプラクティスの識別との関連においても有用である。

上述したように、本明細書に記載するソリューションは、ワークフォースの、およびカスタマの、オペレーションを管理および支援することを目的としている。これは、オペレータ／カスタマにとって利用可能にされた、サービスの組を介して得られる。

ｅＴｏｍフレームワーク（文献：ＴｅｌｅＭａｎａｇｅｍｅｎｔＦｏｒｕｍ ＧＢ９２１およびＧＢ９２１Ｄ、リリース４．０（２００４年３月）およびメンバー評価中のリリース５．０（２００５年４月））に準拠して、本発明に記載するソリューションの第１の実施形態は、以下のレベル１縦方向エンド−エンドプロセスグルーピングに関するアクティビティを実行するオペレータおよびカスタマへの支援を提供する。
−インフラストラクチャのライフサイクル管理（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ）（プロセス領域：戦略、インフラストラクチャと製品（Ｓｔｒａｔｅｇｙ，Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ＆ Ｐｒｏｄｕｃｔ））、
−オペレーションの支援と準備（Ｏｐｅｒａｔｉｏｎｓ Ｓｕｐｐｏｒｔ ＆ Ｒｅａｄｉｎｅｓｓ）（プロセス領域：オペレーション（Ｏｐｅｒａｔｉｏｎ））、
−要求実現（Ｆｕｌｆｉｌｍｅｎｔ）（プロセス領域：オペレーション（Ｏｐｅｒａｔｉｏｎ））、
−品質保証（Ａｓｓｕｒａｎｃｅ）（プロセス領域：オペレーション（Ｏｐｅｒａｔｉｏｎ））。

次に、ｅＴＯＭフレームワークの横方向次元を考慮すると、オペレータおよびカスタマのアクティビティが入るレベル１横方向機能プロセスグルーピングは、次のとおりである。
−リソースの開発と管理（Ｒｅｓｏｕｒｃｅ Ｄｅｖｅｌｏｐｍｅｎｔ ＆ Ｍａｎａｇｅｍｅｎｔ）（プロセス領域：戦略、インフラストラクチャと製品（Ｓｔｒａｔｅｇｙ，Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ＆ Ｐｒｏｄｕｃｔ））、
−カスタマ関係管理（Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ）（プロセス領域：オペレーション（Ｏｐｅｒａｔｉｏｎ））、
−サービスの管理とオペレーション（Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ ＆ Ｏｐｅｒａｔｏｉｎｓ）（プロセス領域：オペレーション（Ｏｐｅｒａｔｉｏｎ））、
−リソースの管理とオペレーション（Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ ＆ Ｏｐｅｒａｔｉｏｎｓ）（プロセス領域：オペレーション（Ｏｐｅｒａｔｉｏｎ））。

オペレータおよびカスタマに向けたオペレーション知識の、管理および共有は、さらに、企業体管理（Ｅｎｔｅｒｐｒｉｓｅ Ｍａｎａｇｅｍｅｎｔ）というプロセス領域に入ってもよく、特に、知識と研究の管理（Ｋｎｏｗｌｅｄｇｅ ＆ Ｒｅｓｅａｒｃｈ Ｍａｎａｇｅｍｅｎｔ）として知られるレベル１プロセスグルーピングに入ってもよい。

図３のフローチャートは、フィールドエンジニアを支援するための手順を、例として示す。
まず第１に、上記で説明したプラットフォームは、所与のアクティビティの実行を任せられたオペレータを、時間通りのアクティビティが実行されるべきであることをそのオペレータに示しながら導く。プラットフォームが、フィールドエンジニアに関する前記サービスを提供するために使用するオペレーション方法を、図３に示し、以下で説明する。

フィールドエンジニアによる、実行されるべき介入の選択（ステップ１００）の後、そのフィールドエンジニアに関連付けられたパーソナルプロキシは、フィールドエンジニアの端末装置上に、対応するインタフェースＰＩを使用して、障害を修復することを目的とする、または、例えば、（データベースの更新などの）プロビジョニングまたはオペレーションのアクティビティに関連した、作業命令（Ｗｏｒｋ Ｏｒｄｅｒ）を実行することを目的とする、ワークフローとして編成された命令信号を表示する（ステップ１１０）。フィールドエンジニアの装置上に表示されるのは、ワークフローの特定の選択肢であり、それらの選択肢は、介入の実行において、お互いに代替となる手法に従ってそのフィールドエンジニアを導くものである。個々のワークフローは、特定の介入を実行するためにフィールドエンジニアに必要なすべての情報を含み、そのような情報としては、オペレーションの対象となる機器の構成要素を識別するために必要とされるデータなどの、介入そのものに関する、可能な特定のデータなどがある。例えば、ワークフローのステップが、機器のカードを変更するアクティビティにおいてフィールドエンジニアを導く場合、前記ステップは、変更されるべきカードを、フィールドエンジニアが容易かつ一意的な方法で識別することを可能にする指示も含む。各ワークフローが提示され、そのワークフローに割り当てられた、ワークフロー自体の効果と効率の確認された評価を反映するスコアも、介入の目的をより良く達成するために示される。前記スコアは、さらに、ワークフローの提示順序を決定する（最高のスコアを有するワークフローから示される）。

示されたワークフローのうちの１つを選択するかどうかを決定する前に、フィールドエンジニアは、パーソナルプロキシＰＰに、測定データの収集、または、機器の構成に関する情報の提供を要求してもよい。要求は、パーソナルプロキシＰＰとリソースプロキシＲＰとの間の情報交換を伴い、フィールドエンジニアの要求は、パーソナルプロキシＰＰからリソースプロキシＲＰに転送され、対応する応答が、リソースプロキシＲＰによってパーソナルプロキシＰＰに送信され、フィールドエンジニアの端末装置上に、インタフェースＰＩを使用することによって提示される（アクティビティ全体が、ステップ１２０に対応する）。

さらに、フィールドエンジニアは、どのように進むかを決定する前にさらなる情報を得るために、提示されたワークフローのうちの１つ以上が表示されるべきであることを要求してもよい（ステップ１３０）。フィールドエンジニアは、次に、提示されたワークフローのうちの１つを選択すること、またはいずれも選択しないことを決定してもよい（ステップ１４０）。選択した場合は、選択されたワークフローの、ＰＰ上での起動が行われる（ステップ１５０）。

ワークフローの起動の後、フィールドエンジニアによって実行されるすべてのアクティビティを記録するプロセスが開始される（ステップ１６０）。収集された情報は、オペレーショナルログＯＬ内に記憶され、そして、その後、既存のワークフローを改良するために、または新しいワークフローを生成して検証する目的のために、処理されてもよい。

パーソナルプロキシＰＰ上でのワークフローの起動に並行して、フィールドエンジニアによるオペレーションの対象となるべき機器を管理するリソースプロキシＲＰ上で、パーソナルプロキシ上のワークフローと協働する、協働ワークフローの起動が行われてもよい（ステップ１７０）。リソースプロキシＲＰ上での、特定の「協働」ワークフローを、最初のステップとして起動するのは、パーソナルプロキシＰＰ上のワークフロー自体である。２つのワークフローは、処理結果を交換するために相互待機の機構を使用してもよい、いくつかの点における調整を除いて、独立した方法で実行される。情報の交換のいくつかの例は、以下に示す。

次に、リソースプロキシＲＰからパーソナルプロキシＰＰに以下を送信するために、パーソナルプロキシＰＰとリソースプロキシＲＰとの間で情報の交換が行われてもよい（ステップ１８０）。
−ワークフローの後続のステップを実行するために必要な、フィールドエンジニアの介入対象となる機器の構成に関する可能なデータ、または、その機器上での測定結果。これらのデータは、フィールドエンジニアによるいかなる要求もなしに自動的に送信される。なぜなら、リソースプロキシＲＰは、実行されているアクティビティと同期しており、関連する時間と、必要とされる情報のタイプとの、両方を知っているからである。
−ワークフローの適切な点においてリソースプロキシＲＰによって自律的に実行される設定アクティビティが、実際に実行されたことの指示。
−フィールドエンジニアによる介入の正常な実行の、リソースプロキシＲＰによって自律的に実行される検査の結果（失敗の場合は、その修復の検査、プロビジョニング作業命令の場合は、要求された設定アクティビティの正しい実行の検査）。

介入の正常な終結の、ＲＰから来る指示の、パーソナルプロキシＰＰを介した、フィールドエンジニアによる受け取りに続いて（ステップ１９０）、介入は終了したと見なされ（ステップ２００）、フィールドエンジニアは後続の介入を選択してもよい。

フィールドエンジニアに提示されたワークフローのうちの、いずれも選択しないことをフィールドエンジニアが決定した場合、または、さもなければ、実行されるべき介入に関連付けられたワークフローが存在しない場合、フィールドエンジニアは、いずれにせよ、パーソナルプロキシＰＰ（これは、さらに、適切なリソースプロキシＲＰとインタフェースをとる）を介して、フィールドエンジニアのオペレーションの対象となるべき機器上の、情報、測定結果、またはコマンド実行を、さらに、機器のコミュニケーションラインインタフェース（ＣＬＩ）へのリモートアクセスを提供することによって、要求してもよい。これは、介入の実行（ステップ２２０）への支援として、および／または、その正しい実行の検査（ステップ２３０）として、介入の終了（ステップ２００）の前に行われる。その上、フィールドエンジニアによって実行されたすべてのアクティビティは記録され（ステップ２１０）、収集された情報は、オペレーショナルログ内に記憶され、そして、その後、新しいワークフローを生成して検証する目的のために、または既存のワークフローを改良するために、処理されてもよい。

１つの特定のワークフローによって示されるステップに従うことを選択した技術者は、ワークフローの実行そのものを、任意の一点において中止してもよく、そして、それ以上導かれることなしに、情報を取得するため、および／または、機器自体へのアクションを実行するために、（パーソナルプロキシＰＰとリソースプロキシＲＰとの間の連鎖を介して）機器と相互作用しながら進んでもよい。

図４は、機器カードの交換のための協働ワークフローの例を示す。特に、当該の図４は、機器上のカードの交換のアクティビティにおいて、フィールドエンジニアを導くことを目的とした、協働ワークフローの例を示す。

フィールドエンジニアは、前述した基準による、起動されるべきワークフローの選択の後、パーソナルプロキシＰＰ上での、選択されたワークフローの始動を、インタフェースＰＩを介して要求する（ステップ１１００）。

パーソナルプロキシＰＰ端におけるワークフローが始動し（ステップ３００）、そのワークフローは、最初のアクションとして、リソースプロキシＲＰ上の関連する協働ワークフローを始動させる（ステップ３１０および５００）。フィールドエンジニアには、ＲＰワークフローの始動を待つためのメッセージが、ＰＩを使用することによって、そのフィールドエンジニアの端末装置上に送られる（ステップ１１１０）。

パーソナルプロキシＰＰワークフローは、カードの交換に先立つアクティビティに進み、フィールドエンジニアに、機器を開けるための指示（ステップ３２０）を、インタフェースＰＩを使用することによって、フィールドエンジニアの端末装置上の、実行されるべき手動オペレーションの説明を介して示し（ステップ１１２０）、そして、機器内のカードを識別するための指示（ステップ３３０）を、インタフェースＰＩを使用することによって、再びフィールドエンジニアの端末装置上の、カードの識別を容易にする図解も用いた表示を介して示す（ステップ１１３０）。

同時に、リソースプロキシＲＰワークフローは、例えば、カード上の依然としてアクティブなサービスを機能停止させるかまたは移行すること、あるいは、カードを非動作状態に設定することなどの、カードの交換のための予備的な管理アクティビティに進む（ステップ５１０）。前記アクティビティが完了したら、リソースプロキシＲＰワークフローは、パーソナルプロキシＰＰワークフローに、次に進むことが可能であることを通知する（ステップ５２０）。

パーソナルプロキシＰＰワークフローは、フィールドエンジニアに、交換されるカードへの配線を切り離すように通知し（ステップ３４０）、インタフェースＰＩを使用することによって、フィールドエンジニアの端末装置上に、手動アクティビティのための有用な情報を提示し（ステップ１１４０）、一方で、リソースプロキシＲＰワークフローに、例えば、関連する物理ポートが、配線が切り離された状態を示すかどうかの検査などの、アクティビティの監視という次のステップ（ステップ５３０）に進むように通知する。交換されるカードのすべての配線が切り離されたら、リソースプロキシＲＰワークフローは、ＰＰワークフローに通知する（ステップ５３０）。

パーソナルプロキシＰＰワークフローは、カードを機器から取り外す準備ができているかどうかの検査に進み（ステップ３５０）、リソースプロキシＲＰワークフローを、カード解除のアクティビティに進めさせ（ステップ５４０）、フィールドエンジニアに、カード解除済み信号を確認するように指示する（ステップ１１５０）。

リソースプロキシＲＰワークフローは、例えば、カードを電源切断状態に設定することなどの、カード解除のアクティビティを完了したら、パーソナルプロキシＰＰワークフローに通知し（ステップ５４０）、パーソナルプロキシＰＰワークフローは、カードの実際の物理的取り外しのアクションに進んで（ステップ３６０）、フィールドエンジニアに、作動させられるべきリリースレバー、および、カードを取り外すプラクティスの指示などの、実行されるべき手動アクティビティを指示する（ステップ１１６０）。

リソースプロキシＲＰワークフローは、手動アクティビティを監視して、例えば、スロットが空いている状態などの、機器から来る状態および信号を検査し（ステップ５５０）、カードがもはや存在しなくなったら、パーソナルプロキシＰＰワークフローに通知する。

パーソナルプロキシＰＰワークフローは、パーソナルプロキシＰＰワークフローからの、およびインタフェースＰＩを介したフィールドエンジニアからの、アクティビティの完了のメッセージを、両方とも受け取ったら、新しいカードの挿入のアクションに進み（ステップ３７０）、必要な情報をインタフェースＰＩに送り（ステップ１１７０）、リソースプロキシＲＰワークフローに通知する。後者は、例えば、スロットが空き状態から占有状態に移ったかどうかを検査することによって、新しいカードの挿入を監視し（ステップ５６０）、挿入されたら、パーソナルプロキシＰＰワークフローに、新しいカードの正しい挿入を通知する（ステップ５７０）。

リソースプロキシＲＰワークフローは、新しいカードの検査および設定に進み（ステップ５８０）、一方、パーソナルプロキシＰＰワークフローは、後者のアクティビティの完了を待ち（ステップ３８０）、フィールドエンジニアに、インタフェースＰＩを介して、検査が進行中であることを通知する（ステップ１１８０）。

新しいカードの設定の最後に、リソースプロキシＲＰワークフローは、パーソナルプロキシＰＰワークフローに通知し（ステップ５８０）、パーソナルプロキシＰＰワークフローは、配線の接続に進んで（ステップ３９０）、インタフェースＰＩを使用することによって、フィールドエンジニアの端末装置上に、実行されるべき手動アクティビティを、カードのタイプおよび配線に関する図解を用いて提示する（ステップ１１９０）。

配線の接続中に、リソースプロキシＲＰワークフローは、カードのポートを監視し（ステップ５９０）、例えば、配線が接続されたことを示すポートの状態を制御する。想定されるすべての配線が再接続された場合のみ、リソースプロキシＲＰワークフローは、パーソナルプロキシＰＰワークフローに通知して（ステップ５９０）、ポートの検査および設定に進み（ステップ６００）、例えば、サービスの再活動化、またはそれらのサービスの、以前に実行された一時的設定（ステップ５１０）からの移行などを行う。

パーソナルプロキシＰＰワークフローは、新しいカードのポートの設定が完了するのを待ち（ステップ４００）、前記アクティビティが進行中であることを、インタフェースＰＩを介して、フィールドエンジニアに通知する（ステップ１２００）。ポートの設定が完了したら（ステップ６００）、リソースプロキシＲＰワークフローは、パーソナルプロキシＰＰワークフローに通知して、終了し（ステップ６１０）、一方、パーソナルプロキシＰＰワークフローは、機器のキャビネットの閉鎖を実行するようにフィールドエンジニアを導くために（ステップ４１０）、インタフェースＰＩを使用することによって、フィールドエンジニアの端末装置上に適切な情報を提供する（ステップ１２１０）。

最後に、パーソナルプロキシＰＰワークフローは、その実行を完了し（ステップ４２０）、フィールドエンジニアに、ワークフローの終了が待たれていることを通知して（ステップ１２２０）、リソースプロキシＲＰワークフローの完了を待つ。ワークフローは、ＰＰワークフローの最後のアクションと同期して（ステップ４３０）、介入が正常に終了したことのフィールドエンジニアへの情報（ステップ１２３０）で終わる。

図５は、代わりに、コールセンタアドバイザを支援するための手順の例を示す。本明細書に記載するソリューションは、実際に、ガイドサービスを、コールセンタアドバイザにも適用することを可能にする。

コールセンタアドバイザによる、カスタマ苦情（以下、トラブルレポート（ＴＲ）と記載する）または新しいサービスの要求（以下、カスタマオーダー（ＣＯ）と記載する）の受け取りに続いて（ステップ１３００）、コールセンタアドバイザに関連付けられたパーソナルプロキシＰＰは、カスタマ要求のための、対象となるネットワーク機器に関連付けられた、１つまたは複数のリソースプロキシＲＰとのセッションを開き、カスタマとの相互作用のために必要な情報を収集する（トラブルレポートの場合は、カスタマサービスの提供に関与する機器上に障害がないか検査される）（ステップ１３１０）。

ネットワークからのデータの収集に続いて、パーソナルプロキシＰＰが、さらなる情報を何も必要とせず（ステップ１３２０で行われる検査）、かつ、カスタマ苦情を処理している場合（ステップ１３３０で行われる検査）、収集されたデータが、第１の診断を実行するために処理される（ステップ１３８０）。代わりに、パーソナルプロキシＰＰが、さらなる情報を必要とせず（ステップ１３２０で行われる検査）、かつ、新しいサービスのための要求を処理している場合（ステップ１３３０で行われる検査）、次のステップは、作業命令（ＷＯ）の作成である（ステップ１４２０）。

ネットワークからのデータの収集に続いて、パーソナルプロキシＰＰがさらなる情報を必要とする場合（ステップ１３２０で行われる検査）、パーソナルプロキシＰＰは、カスタマのＴＲ／ＣＯのさらなる詳細を取得することを目的とした一連の質問を、対応するインタフェースＰＩを使用することによって、コールセンタアドバイザの装置上に表示する（ステップ１３４０）。トラブルレポートの場合、前記質問は、さらに、トラブルレポートの原因である問題の解決につながる可能性がある、時間通りの検査／アクションを実行することの、カスタマへの要求であってもよく、例えば、カスタマ構内機器（ＣＰＥ）のすべての配線が正しく接続されているかどうかの確認と、接続障害が検出された配線を正しく接続する措置との要求であってもよい。

コールセンタアドバイザは、カスタマと相互作用することによって、コールセンタアドバイザに提出された質問への適切な回答を、パーソナルプロキシＰＰに供給する（ステップ１３５０）。要求されたデータをカスタマが提供することができない場合、または、カスタマによって提供されたデータを統合するために、コールセンタアドバイザは、パーソナルプロキシＰＰに、測定データを収集するように、または、特定のカスタマについての、対象となるネットワーク部分に関連する、コンフィギュレーション情報を供給するように求めてもよい。これは、パーソナルプロキシＰＰと、前記ネットワーク部分を制御するリソースプロキシＲＰとの間の情報交換を伴い、コールセンタアドバイザの要求は、パーソナルプロキシＰＰによってリソースプロキシＲＰに転送され、対応する応答が、リソースプロキシＲＰによってパーソナルプロキシＰＰに送られ、後者によって、インタフェースＰＩを介して、オペレータに示される（アクティビティ全体が、ステップ１３６０に対応する）。

一連の質問の終わりにおける、または、トラブルレポートの場合は、カスタマの検査／アクションに基づくトラブルレポート自体の解決の後における（ステップ１３７０で行われる検査）、次のステップは、ステップ１４２０である。

カスタマによるトラブルレポートの場合（ステップ１３７０で行われる検査）、（カスタマからの、および／またはネットワークからの）データの、導かれた収集のステップの終わりにおいて、パーソナルプロキシＰＰは、ルールベースシステムを使用することによって、トラブルレポートの根本的原因についての、第１の仮説を立てる（ステップ１３８０）。

障害が、カスタマによって修復されることが可能な場合（ステップ１３９０で行われる検査）、コールセンタアドバイザのパーソナルプロキシＰＰは、カスタマのパーソナルプロキシＰＰとのセッションを開き、カスタマのパーソナルプロキシＰＰに、トラブルレポートを解決するための特定のワークフローを実行するように要求する（ステップ１４００）。コールセンタアドバイザは、次に、その他のアクティビティの実行に移ってもよく、同時に、カスタマによるワークフローの実行の結果について知らされてもよい。

ワークフローの結果を受け取り次第（ステップ１４１０）、ワークフローの結果を考慮に入れた、適切なトラブルチケット（ＴＴ）が作成される（ワークフローが正常に実行された場合、ＴＴは、トラブルレポートの解決方法を記録する。それ以外の場合、ＴＴは、フィールドエンジニアに向けての１つ以上の作業要求ＷＲを作成するための、有用な情報を含む）。

障害が、カスタマによって解決されることができない場合（ステップ１３９０で行われる検査）、次のステップは、トラブルチケットの作成である（ステップ１４２０）。トラブルレポート／カスタマオーダーについてのデータの収集に続いて、かつ、トラブルレポートの場合は、第１レベルの診断の後、および／または、トラブルレポートの解決の後で、パーソナルプロキシＰＰは、コールセンタアドバイザに、トラブルチケットまたは作業命令を作成するために必要なすべてのデータを提供し、まだ満たされていないカスタマ要求の場合、トラブルチケットまたは作業命令は、フィールドエンジニアに向けての１つ以上の作業要求ＷＲを生成する（ステップ１４２０）。ＴＴ／ＷＯの作成の後、コールセンタアドバイザのアクティビティは終了する（ステップ１４３０）。

図６のフローチャートは、代わりに、カスタマを支援する手順を示す。ここで説明するオペレーショナルアクティビティの実行への支援は、カスタマにも適用される。
任意の機能不良の、カスタマによる検出に続いて（ステップ７００）、カスタマ自身が、カスタマの装置（通常は、ＰＣまたはＰＤＡ）上で、カスタマに関連付けられたパーソナルプロキシＰＰを起動する（ステップ７１０）。

パーソナルプロキシＰＰは、カスタマの構内に配置された機器と関連付けられた１つまたは複数のリソースプロキシＲＰとのセッションを、前記機器上の任意の可能な障害を識別するために開く（ステップ７２０）。カスタマの構内における機器上に障害が存在しない場合（ステップ７３０で行われる検査）、パーソナルプロキシＰＰは、検出された機能不良についてのさらなる詳細を取得することを目的とした一連の質問を、カスタマの装置上に、対応するＰＩインタフェースを使用して表示する（ステップ７４０）。カスタマは、カスタマに提出された質問への適切な回答を、パーソナルプロキシＰＰに提供する（ステップ７５０）。

一連の質問の終わりにおいて、パーソナルプロキシＰＰは、機能不良の原因が識別されたかどうか、および前記原因がカスタマによって除去されることが可能かどうかを検査し（ステップ７６０で行われる検査）、そして、そうである場合、問題の解決においてカスタマを導く、適切なワークフローを起動する（ステップ７７０）。パーソナルプロキシＰＰは、さらに、カスタマアクティビティを記録するプロセスを起動する（ステップ７８０）。収集された情報は、オペレーショナルログ内に記憶され、そして、その後、既存のワークフローを改良するために、または新しいワークフローを生成して検証するために、処理されてもよい。

ワークフローの終わりにおいて、カスタマによって、機能不良の除去についての検査が行われる（ステップ７９０）。前記検査が肯定的な結果を有する場合、カスタマのアクティビティは終了する（ステップ８１０）。代わりに、検査が、否定的な結果を有する場合、パーソナルプロキシＰＰは、カスタマに、コールセンタに連絡するように通知する（ステップ８００）。パーソナルプロキシＰＰによる通知の後、カスタマのアクティビティは終了する（ステップ８１０）。機能不良の原因が識別されていない場合、または、さもなければ、機能不良がカスタマによって除去されることができない場合（ステップ７６０で行われる検査）、パーソナルプロキシＰＰは、カスタマに、コールセンタに連絡するように通知する（ステップ８００）。パーソナルプロキシＰＰによる前記通知に続いて、カスタマのアクティビティは終了する（ステップ８１０）。

カスタマの構内における機器上に障害がある場合（ステップ７３０で行われる検査）、パーソナルプロキシＰＰは、前記障害がカスタマによって修復されることが可能かどうかを確認するための、さらなる検査を実行する（ステップ８２０で行われる検査）。否定的な結果の場合、パーソナルプロキシＰＰは、カスタマに、コールセンタに連絡するように通知する（ステップ８００）。肯定的な結果の場合、パーソナルプロキシＰＰは、問題の解決においてカスタマを導く、適切なワークフローを起動する（ステップ７７０）。

適切なワークフローの起動後に、パーソナルプロキシＰＰは、さらに、カスタマアクティビティを記録するプロセスを起動する（ステップ７８０）。収集された情報は、オペレーショナルログ内に記憶され、そして、上述したように、既存のワークフローを改良するために、または新しいワークフローを生成して検証するために、処理されてもよい。ワークフローの終わりにおいて、カスタマによって、機能不良の除去についての検査が行われる（ステップ７９０）。前記検査が肯定的な結果を有する場合、カスタマのアクティビティは終了する（ステップ８１０）。代わりに、検査が、否定的な結果を有する場合、パーソナルプロキシＰＰは、カスタマに、コールセンタに連絡するように通知する（ステップ８００）。パーソナルプロキシＰＰによる通知の後、カスタマのアクティビティは終了する（ステップ８１０）。

カスタマは、リソースプロキシＲＰによって自動的に実行される、可能なアクションについても知らされるということ、および、カスタマは、それらの実行への明示的な承諾を与えることができるということを、カスタマのパーソナルプロキシＰＰ上で実行されるワークフローは、通常、想定する。

図７のフローチャートは、オペレータ間の協働のための手順を示す。本明細書に記載したプラットフォームは、実際に、所与のアクティビティ（例えば、現場での介入、またはカスタマ要求の処理）の実行を、可能な他のオペレータとの、またはオペレータとカスタマとの間の相互作用を管理しながら行うことを任せられたオペレータを、支援するためのさらなるサービスを提供する。

オペレータ間の相互作用のために採用されるオペレーショナルプラクティスを、以下に説明する。
パーソナルプロキシＰＰは、（例えば、フィールドエンジニアの場合に、成功しなかった介入の検出の後で）自律的に、または、オペレータによる通知があり次第、他のオペレータのパーソナルプロキシＰＰに向けてのセッションを起動することを決定する（ステップ１５００）。

自動的な起動の場合（ステップ１５１０で行われる検査）、パーソナルプロキシＰＰは、（利用可能なデータから推論された、またはオペレータの明示的な指示に由来する）オペレータが実行しているアクティビティのタイプの知識と、そのアクティビティを実行するために必要とされるマクロ技能の知識とに基づいて、セッションの起動を、マクロ技能に従って編成された、連絡されるべきオペレータの名前の順序立ったリストを使用して試みる（ステップ１６００）。

起動が成功していない場合（ステップ１６１０で行われる検査）、パーソナルプロキシＰＰは、セッションを起動する試みを続行するか、または停止するかを、オペレータに問い合わせる（ステップ１６４０）。継続することをオペレータが決定した場合、パーソナルプロキシＰＰは、リスト内の次の名前を使用してセッションの起動をさらに試み（ステップ１６００）、セッションを首尾よく起動するまで、またはオペレータが手順の中止を決定するまで、繰り返し続行する。後者の場合、パーソナルプロキシＰＰは、セッション起動手順を終了する（ステップ１５９０）。

起動が成功した場合（ステップ１６１０で行われる検査）、オペレータ間のセッションが開始され、その中で、パーソナルプロキシＰＰは、実行されるべきアクティビティに関する、およびすでに実行されたステップに関する、すべてのデータを両方のオペレータに見えるようにするツール、または、支援を要求したオペレータがすでに取得した、可能なネットワークデータを共有するためのツールなどの、協働作業のためのツールの組を利用可能にする（ステップ１６２０）。

オペレータの通知があり次第、パーソナルプロキシＰＰは、セッションの終了に進む（ステップ１５７０）。
オペレータによる要求があり次第の起動の場合（ステップ１５１０で行われる検査）、パーソナルプロキシＰＰは、（利用可能なデータから推論された、またはオペレータの明示的な指示に由来する）オペレータが実行しているアクティビティのタイプの知識と、そのアクティビティを実行するために必要とされるマクロ技能の知識とに基づいて、名前の順序立ったリストを提示し（ステップ１５２０）（順序は、パーソナルプロキシＰＰが、セッションを自律的に起動しなければならない場合に従う順序である）、そのリストの中で、オペレータは、所望の名前を選択する（ステップ１５３０）。

オペレータによる、名前の選択の後、パーソナルプロキシＰＰは、前記名前に関連付けられたパーソナルプロキシＰＰに向けたセッションのセットアップを試みる（ステップ１５４０）。起動が不成功の場合（ステップ１５５０で行われる検査）、パーソナルプロキシＰＰは、セッションを起動する試みを続行するか、または停止するかを、オペレータに問い合わせる（ステップ１５８０）。継続することをオペレータが決定した場合、パーソナルプロキシＰＰは、１つまたは複数の不成功の試みを考慮に入れるために適切に更新された、名前のリストを再び表示し（ステップ１５２０）、セッションを首尾よく起動するまで、または、オペレータが手順の中止を決定するまで、繰り返し続行する。後者の場合、パーソナルプロキシＰＰは、セッション起動手順を終了する（ステップ５９０）。

起動が成功した場合（ステップ１５５０で行われる検査）、オペレータ間のセッションが開始され、その中で、パーソナルプロキシＰＰは、既に以前に考慮したタイプの、協働作業のためのツールの組を利用可能にする（ステップ１５６０）。オペレータの通知があり次第、パーソナルプロキシＰＰは、セッションの終了に進む（ステップ１５７０）。

カスタマとオペレータとの間の相互作用は、オペレータ間の相互作用について上述した機構に類似した機構を使用し、この場合、協働はカスタマとコールセンタアドバイザとを通常は含むということ、そして、セッションのセットアップは、カスタマのパーソナルプロキシＰＰが、カスタマ自身の要求があり次第、または自律的に行うということを、仮定することが可能である。さらに、この場合、カスタマは、任意の瞬間において、オペレータとのセッションをセットアップする試みを中止することを決定してもよい。カスタマの要求の場合、パーソナルプロキシＰＰは、カスタマ自身に、コールセンタアドバイザの名前の順序立ったリストを提示して、連絡されるべきアドバイザをカスタマが選択することを可能にする。

上に例示したサービスを提供するために、説明したプラットフォームは、オペレータに関するデータ、カスタマに関するデータ、およびワークフローに関するデータの組を維持し、オペレーションの変更（新しい機器の導入に続く新しいワークフローの導入、ネットワーク上にもはや存在しない機器上のアクティビティを参照するワークフローの削除など）と、ワークフォースのメンバーの特性および数の変更（新しいオペレータの導入、オペレータプロファイルのデータの更新など）と、カスタマの特性および数の変更（新しいカスタマの導入、カスタマプロファイルのデータの更新など）との、いずれにも適合するように、プロセスの動的管理を実行する。

オペレータプロファイルは、少数の標準的な基本プロファイルに基づいて定義される。前記プロファイルは、オペレータのマクロ技能（例えば、オペレータがアクティビティを実行可能なネットワーク／サービス領域（スイッチング、転送、ＡＤＳＬアクセスなど））と、各マクロ技能についての、対応する等級（これは、所与の分野において、オペレータがどれだけ熟練しているかを示す）とを指定する。プロファイルは、さらに、オペレータが、フィールドエンジニアか、内勤オペレータか、コールセンタアドバイザかを明らかにし、そのオペレータが属する仮想チームを指摘し、そのオペレータの認証信任状を提供する。前記プロファイルのデータは、例えば、新しいマクロ技能、または等級の変化を考慮に入れるために動的に更新され、プロファイルのモデルは、データベースＯＤＢ内に記憶される。マクロ技能の動的更新は、すべてのプラットフォームサービス（例えば、オペレータ間の相互作用のサービス）が最新のデータを使用することを可能にするために、タイムリーな方法で実行される。オペレータプロファイルのデータをロードすることに関しては、各パーソナルプロキシＰＰは、そのパーソナルプロキシＰＰが関連付けられたオペレータのプロファイルのみを維持する（各パーソナルプロキシＰＰは、特定のオペレータに関連付けられる）。前記プロファイルのデータは、適切な外部システム（ＷＦＭシステム）と相互作用しているＯＭによって取得される。プラットフォームは、次に、（ＷＦＭからダウンロードされた）すべてのオペレータのプロファイルのデータが記憶される、集中型のインベントリ（エキスパータイズインベントリＥＩ）を想定する。各パーソナルプロキシＰＰが起動され次第、前記パーソナルプロキシＰＰに関連付けられたオペレータプロファイルデータが、エキスパータイズインベントリＥＩから、オペレーショナルマネージャＯＭを介して、パーソナルプロキシＰＰ自体に、自動的にダウンロードされる。インベントリＥＩは定期的に更新され、インベントリ自体の上のデータの各更新において、対応するパーソナルプロキシＰＰにデータが送信される。

カスタマプロファイルは、少数の標準的な基本プロファイルに基づいて定義される。前記プロファイルは、カスタマが自己修復アクティビティを実行可能な、１つまたは複数のサービス（例えば、ＡＤＳＬサービス、ＩＳＤＮサービスなど）と、そのカスタマの認証信任状とを指定する。プロファイルのデータは、例えば、署名された新しいサービスを考慮に入れるために動的に更新され、プロファイルのモデルは、データベースＯＤＢ内に記憶される。カスタマプロファイルのデータの動的更新は、すべてのプラットフォームサービスが最新のデータを使用することを可能にするために、タイムリーな方法で実行される。カスタマプロファイルのデータをロードすることに関しては、各パーソナルプロキシＰＰは、そのパーソナルプロキシＰＰが関連付けられたカスタマのプロファイルのみを維持する（各パーソナルプロキシＰＰは、特定のカスタマに関連付けられる）。前記プロファイルのデータは、オペレーショナルマネージャＯＭによって、適切な外部システム（ビジネス支援システム）と相互作用することによって取得される。プラットフォームは、次に、（ビジネス支援システムからダウンロードされた）すべてのカスタマのプロファイルのデータが記憶される、集中型のインベントリ（エキスパータイズインベントリＥＩ）を想定する。各パーソナルプロキシＰＰが起動され次第、前記パーソナルプロキシＰＰに関連付けられたカスタマプロファイルのデータが、インベントリＥＩから、オペレーショナルマネージャＯＭを介して、パーソナルプロキシＰＰ自体に、自動的にダウンロードされる。インベントリＥＩは定期的に更新され、インベントリ自体の上のデータの各更新において、対応するパーソナルプロキシＰＰにデータが送信される。

フィールドエンジニアのオペレーションを支援するワークフローに関しては、データベースＯＤＢが、各ワークフローについて、ワークフロー識別子（これは、プラットフォームによって自動的に生成される漸進的数値識別子であってもよい）、ワークフローのバージョン、ワークフローのスコア、ワークフローが該当する介入のタイプ（例えば、障害、プロビジョニングのアクティビティ、オペレーションアクティビティなど）、実行される特定の介入の識別子（例えば、障害の場合、リンク障害、ユーザカード障害などを指示することが可能）、該当する場合は、介入を実行するために必要とされるマクロ技能の等級（例えば、エキスパートフィールドエンジニア、および新規フィールドエンジニア）などの、特徴の組を維持する。前記特徴は、ワークフローが作成／修正される場合に提供される。スコアは、後述するものに従って、動的に更新される。データベースＯＤＢ内に記憶された、オペレーションを支援するワークフローの作成／修正と、データベースＭＤＢ内に記憶された、対応する協働ワークフローの作成／修正とは、何が処理されたかについての一致検査を容易にするために２つの相関性があるワークフローの並行編集を可能にする、適切なグラフィカルインタフェースを介して行われる。

同様の考察が、カスタマオペレーションを支援するワークフローに関して適用される。データベースＯＤＢは、カスタマを支援する各ワークフローについて、フィールドエンジニアのためのワークフローのものと同様の、カスタマの場合にも適用可能な、特徴の組を維持する。

フィールドエンジニアを支援するワークフローについては、２つの管理機能が想定される。
ワークフローのロードに関して、パーソナルプロキシＰＰ上へのワークフローのダウンロードは、それに関連付けられたコントロールエージェントＣＡによって実行される。パーソナルプロキシＰＰが起動され次第、ワークフローがダウンロードされるのではなく、ワークフローは、パーソナルプロキシＰＰ自体による明示的な要求があり次第、パーソナルプロキシＰＰ上にダウンロードされるのみである。フィールドエンジニアによる、所与のアクティビティの仮定の後に、かつ、実行されるべき、またはそのフィールドエンジニアの装置上に表示されるべきワークフローの、そのフィールドエンジニアによる選択の後に、パーソナルプロキシＰＰは、前記ワークフローが、ローカルメモリ領域内に既に存在しているという限りにおいて、直接アクセス可能であるかどうかを検査し、さらに、（ワークフローに関連付けられたバージョンインジケータを介して）そのワークフローが更新済みであるかどうかを確認する。ワークフローが存在していないか、または、更新されていない場合、コントロールエージェントＣＡを介して、ワークフローは、データベースＯＤＢからダウンロードされる。ワークフローは、任意の可能な将来の使用のために、パーソナルプロキシＰＰ内に記憶されたままになる。

同様の方法により、リソースプロキシＲＰが起動され次第、ワークフローがダウンロードされるのではなく、ワークフローは、リソースプロキシＲＰ自体による明示的な要求があり次第、リソースプロキシＲＰ上にダウンロードされるのみである。リソースプロキシＲＰがパーソナルプロキシＰＰから、オペレーションを支援する所与のワークフローを起動するための要求を受け取ったときに、パーソナルプロキシＰＰは、このワークフローが、ローカルメモリ領域内に既に存在しているという限りにおいて、直接アクセス可能であるかどうかを検査し、さらに、（ワークフローに関連付けられたバージョンインジケータを介して）このワークフローが更新済みであるかどうかを検査する。ワークフローが存在していないか、または、更新されていない場合、リソースプロキシＲＰは、そのワークフローを、データベースＭＤＢからダウンロードする。ワークフローは、可能な将来の使用のために、リソースプロキシＲＰ内に記憶されたままになる。

ワークフローの「スコア」を動的に管理するための手順が、次に想定される。ワークフローのスコアは、（フィールドエンジニアによって実行されるアクティビティと、それらのアクティビティを実行するために使用される材料のコストとに結び付いた）時間／コストデータと、所与のワークフローについてのフィールドエンジニアの嗜好との、両方に基づく。これらのデータを取得するために、ワークフローの各実行において、前記実行に結び付いたパラメータの組が収集され（ワークフローパラメータの収集は、パーソナルプロキシＰＰによって実行される）、そして更新される。そのようなパラメータの例は、パーソナルプロキシＰＰ上でのワークフローの総実行時間、ＣＰＵ使用率、そのワークフローを選択したオペレータの数などである。収集／更新されたデータは、パフォーマンスデータベースＰＤＢ内に記憶される。各ワークフローについてのスコアの新しい値を取得するために、定期的に（例えば、一定の時間間隔で）、前記パラメータを解析および処理する必要がある。ワークフローの新しいスコアは、次に、さまざまなパーソナルプロキシＰＰに伝えられる。

同様の管理機能が、カスタマを支援するワークフローのために提供される。前記ワークフローを使用して処理されるべき障害／問題の識別の後に、パーソナルプロキシＰＰ自体によって要求され次第、または、コールセンタアドバイザのパーソナルプロキシＰＰから来る、特定のワークフローを起動するための要求を受け取り次第、ワークフローは、パーソナルプロキシＰＰ上にダウンロードされる。特に、カスタマを導くために使用されることが可能なワークフローが複数ある場合、その時点で最も高いスコアを有するワークフローのみが、パーソナルプロキシＰＰ上にダウンロードされる。さらに、カスタマのためのワークフローについては、カスタマ端において識別されることが可能なパラメータに関して適切に調整される、スコアの動的管理の機構が提供される。

既に示したように、パーソナルプロキシＰＰと、オペレータまたはカスタマとの間の相互作用は、適切なパーソナルインタフェースＰＩを使用することによって実現される。インタフェースＰＩは、オペレータ／カスタマによって使用される装置（セルラー電話、ＰＤＡ、ラップトップ型パソコン、デスクトップなど）のタイプおよび計算能力に依存する技術、例えば、Ｗｅｂベースのクライアント−サーバ技術（ＨＴＭＬページ、Ｊａｖａアプレット、スタンドアロンＪａｖａアプリケーション）、または自律エージェント技術など、を使用して作成される。インタフェースＰＩは、オペレータ／カスタマが、すべての特定の使用状況において、最高の効果、効率、および満足とともに目的の組を達成することを可能にするために、使いやすさの原則に適合するように設計される。インタフェースＰＩの開発においては、パーソナルプロキシＰＰがリソースプロキシＲＰとの協働において実行しなければならない相互作用およびアクティビティをより効果的にするための、コードの最適化と、オペレータ／カスタマの、割り当てられたタスクを遂行するための能力を大幅に向上するための、ＧＵＩの使いやすさおよび操作性の良さの側面との両方に、多大の注意が払われた。

オペレータの場合、アクティビティ要求（現場での介入、またはトラブルレポート／カスタマオーダー）があり次第、ＷＦＭはオペレーショナルマネージャＯＭに、選択されたオペレータの名前と、実行されるべきアクティビティの詳細とを送る。オペレーショナルマネージャＯＭは、前記データを、選択されたオペレータに関連付けられたパーソナルプロキシＰＰに、前記パーソナルプロキシＰＰを調整するオペレーショナルエージェントＯＡを介して転送する。パーソナルプロキシＰＰは、次に、対応するインタフェースＰＩ上で、実行されるべきアクティビティがあるということを通知する。

オペレータは、実行されるべきアクティビティがあるということの情報を、そのオペレータのインタフェースＰＩ上で受け取ったら、以下のように続行する。
−オペレータは、インタフェースＰＩのホームページから、ログインおよび認証の手順を開始する。オペレータプロファイルに基づいて、「特権」機能専用のセクションは、表示されてもされなくてもよい。認証データは、前記パーソナルプロキシＰＰに関連付けられたオペレータについての、エキスパータイズインベントリＥＩ内に記憶された認証データと照会される。

−オペレータは、そのオペレータに割り当てられたアクティビティに関するデータを表示し、前記アクティビティ（例えば、現場での介入、またはトラブルレポート／カスタマオーダー）の引き受けの手順を実行する。この時点において、オペレータは、インタフェースＰＩを介して、オペレーションの補助としての、グラフィカルおよびナビゲーション環境にアクセスすることが可能である。これらの環境によって提供される機能は、一部は、すべてのタイプのオペレータ（例えば、フィールドエンジニアおよびコールセンタアドバイザ）によって入手され、使用されることが可能であり、一部は、特定のタイプのオペレータ専用である。

それらの機能は、以下を可能にする。
−介入の実行対象となる（例えば、交換局内の）機器の位置の表示（フィールドエンジニア）。

−機器のインタフェースの表示と、介入する必要がある対象のハードウェア構成要素（ラック、カード、ポート、デバイスなど）のグラフィカルな識別（フィールドエンジニア）。

−エンジニアのオペレーションを段階的に導くための、対話型モードでの、ワークフロー（および、可能な事前の、さまざまなワークフロー間での選択の選択肢）の提示（フィールドエンジニア）。

−カスタマの要求を詳述するために必要な情報を段階的に取得するための、対話方式での、一連の質問の提示（コールセンタアドバイザ）。
−カスタマ自身によって提示されたトラブルレポートを解決するために、カスタマが実行しなければならない、アクションの提案（コールセンタアドバイザ）。

−カスタマのトラブルレポートの原因に関して立てられた仮説の提示（コールセンタアドバイザ）。
−パーソナルプロキシＰＰとリソースプロキシＲＰとの間の接続のセットアップの表示、および、ＲＰによって、自律的に、またはパーソナルプロキシＰＰからの要求があり次第実行される、構成、設定、測定、テストなどのアクションへの、リソースプロキシＲＰからの「応答」の提示（すべてのオペレータ）。

−介入が実行されている、対象の機器上のＣＬＩ（コマンドラインインタフェース）への、ＲＰを介した、リモートアクセス（フィールドエンジニア）。
−アクティビティへの可能な支援としての、オンライン文書の表示（すべてのオペレータ）。

−他のオペレータ（仮想チームオペレータ、マネジメントスタッフ、内勤オペレータ、コールセンタアドバイザ）との通信の、「従来の」機能（音声電話、電子メール、チャット、共有ホワイトボードなど）へのアクセス（すべてのオペレータ）。

カスタマの場合、そのカスタマのパーソナルプロキシＰＰの起動に続いて、カスタマ自身が、ログインおよび認証の手順を実行し、そのカスタマによって検出された機能不良を解決するために必要なすべてのデータ（質問、ガイドワークフローなど）を、そのカスタマの装置上で受け取る。

提供される機能は、以下を可能にする。
−カスタマのオペレーショナリティを段階的に導くための、対話型モードでの、ワークフローの提示。

−カスタマによって検出された機能不良の原因を識別するために必要な情報を段階的に取得するための、対話型モードでの、一連の質問の提示。
−機能不良の根本的原因に関する仮説の提示。

−パーソナルプロキシＰＰとリソースプロキシＲＰとの間の接続のセットアップの表示、および、リソースプロキシＲＰからの「応答」の提示。
−機能不良を解決するための、オペレータへの連絡の必要の通知。

−オペレータとの通信の機能へのアクセス。
上記のオペレーションを支援する構成要素は、より伝統的な技術的アプローチ（クライアント−サーバパラダイム）に基づく管理の状況においても用途がある。

（例えば、米国特許出願公開第２００４／０１９６７９４号明細書によって例示されるような）クライアント−サーバ技術に基づく階層的アプローチを採用する管理ソリューションを、例として調べると、前述した（オペレータおよびカスタマの）オペレーションを支援するための機能は依然として効果的である。そして、それらの機能は、運用の部分については本明細書の図２に提示したものと比較して変わりなく、一方、ネットワークおよびサービス管理の部分については米国特許出願公開第２００４／０１９６７９４号明細書の図２に記載されているアーキテクチャなどの異なるアーキテクチャに依存する、プラットフォームを使用することによって提供されてもよい。特に、この場合、目的が、ネットワーク内の装置を直接管理する管理リソース（下位レイヤのネットワーク管理ステーション／ユニット）の変更を想定しない、保守的なアプローチを採用することであるならば、パーソナルプロキシＰＰは、上位レイヤと下位レイヤとのネットワーク管理ステーション間で採用されたものに類似した通信様式を使用して、ネットワークとの間のすべての相互作用を実行するために、対応する下位レイヤネットワーク管理ステーションと直接インタフェースをとる（これは、上記の実施形態では、リソースプロキシＲＰを介して実行された）。あるいは、パーソナルプロキシＰＰは、下位レイヤネットワーク管理ステーションについてのトポロジ情報を所有する上位レイヤネットワーク管理ステーションと相互作用し、したがって、前記情報を直接処理する必要を回避してもよい。いずれの場合も、管理構成要素への変更がなければ、関係しているネットワーク管理ステーション上での協働ワークフローは存在しない。ただし、これが本発明の好ましい実施形態の唯一の可能な代替を表す限りにおいて、これは、オペレーションを支援する機能の有効性と効果とを何ら損なうものではない。

図３に関連して説明したような、所与の介入の実行においてフィールドエンジニアを導く手順は、フィールドエンジニアによって実行されるべき介入の選択肢を参照するが、前記選択が行われる様式は、さまざまであり、採用されるオペレーションパラダイムと、ＷＦＭシステムによって実行される機能とに依存するということが理解されるであろう。本発明の一実施形態では、フィールドエンジニアが担当する介入は、そのフィールドエンジニアのインタフェースＰＩ上で、パーソナルプロキシＰＰによってそのフィールドエンジニアに提示され、ＷＦＭ−ＯＭ連鎖を介してパーソナルプロキシＰＰ自体にダウンロードされた介入のみである。

代替の実施形態では、フィールドエンジニアは、所与のサイトにおける機器に対して実行されるべき複数のアクティビティから、１つのアクティビティを選択する。この場合、フィールドエンジニアによって、パーソナルプロキシＰＰを介して受け取られる唯一の指示（パーソナルプロキシＰＰは、さらに、ＷＦＭ−ＯＭ連鎖からその指示を受け取った）は、そのフィールドエンジニアが行く必要のあるサイトに関する指示である（ＷＦＭは、さまざまなサイト間でのフィールドエンジニアの周期的巡回のみを管理し、行うべきことをフィールドエンジニアに指示することはしない）。

図３に関連して前述した手順は、適切なワークフローがフィールドエンジニアに提案されることを示す。これは、パーソナルプロキシＰＰとオペレーショナルマネージャＯＭとの間の相互作用によって行われる。フィールドエンジニアによって介入が選択されると、パーソナルプロキシＰＰは、オペレーショナルマネージャＯＭに、前記介入を支援するためのすべてのワークフローのリストを要求する。オペレーショナルマネージャＯＭは、データベースＯＤＢ内で利用可能なワークフロー情報に基づいて、このリストを動的に作成して、パーソナルプロキシＰＰに送り、パーソナルプロキシＰＰは、フィールドエンジニアにそのリストを提示する。

本発明の第１の可能な実施形態では、所与の特定の介入について、すべてのフィールドエンジニアが、それらのフィールドエンジニアの特定の技能等級に関係なく、同じワークフローを提示される。

代替の実施形態では、所与の特定の介入について、フィールドエンジニアに提示されるワークフローは、そのフィールドエンジニアの独自の技能等級に依存する。フィールドエンジニアがエキスパートである場合、そのフィールドエンジニアには、より高いレベルのワークフローが提示される。それ以外の場合、提示されるワークフローは、より詳細なものであるか、または、フィールドエンジニアにとって役立つ文書および技術基準へのアクセスをどのような場合でも可能にするものである。第１の場合は、オペレーショナルマネージャＯＭによる、リストに入れられるべきワークフローの選択は、したがって、実行されるべき介入のタイプのみを考慮して行われるのに対して、第２の場合は、フィールドエンジニアのプロファイル、特に、当該の介入を実行するために必要とされる技能を基準とした、そのフィールドエンジニアの技能等級が、考慮に入れられる。

再び、本発明の代替の実施形態では、パーソナルプロキシＰＰ上のワークフローの起動は、リソースプロキシＲＰ上の協働ワークフローの起動を含まない。パーソナルプロキシＰＰ上のワークフローは、何らかの所与のデータ／測定結果を収集するため、機器上での所与のアクティビティの実行を要求するため、または、可能なコマンドラインインタフェースへのリモートアクセスを利用可能にするために、リソースプロキシＲＰ上の特定のワークフローを、対話方式で起動するのみである。そのワークフローは、要求されたものを実行し、パーソナルプロキシＰＰに結果を返す。この場合、リソースプロキシＲＰは、パーソナルプロキシＰＰによって導かれるオペレータが何を行っているかを知らない。これは、最後のステップにおいて、パーソナルプロキシＰＰ上のワークフローは、フィールドエンジニアによって実行された介入の結果を確認するようにリソースプロキシＲＰに要求することを、前記介入が正常に実行されたと見なす前に行わなければならないということを含意する。

既に示したように、コールセンタアドバイザを支援する手順は、カスタマのパーソナルプロキシＰＰ上のワークフローを、必要な場合にいつでも起動することを可能にする。これは、パーソナルプロキシがアクティブであることを必要とする。パーソナルプロキシＰＰの起動は、オペレータのパーソナルプロキシＰＰからの起動の要求により、自動的に発生するか、または、さもなければ、カスタマによるパーソナルプロキシＰＰの起動により、手動モードで発生してもよい。この後者の場合、パーソナルプロキシＰＰ自体は、カスタマの装置上にすでに存在し、起動される必要があるのみであってもよく、または、さもなければ、遠隔位置から、特に、意図的に提供されるインターネットサイトから、カスタマがそれをダウンロードしてもよい。代替の実施形態では、前記手順は、カスタマのパーソナルプロキシＰＰ上のワークフローの起動を想定しない。コールセンタアドバイザは、質問−応答パラダイムによってカスタマと相互作用し、多くても、何らかの特定のアクションの実行をカスタマに要求するのみである。

さらに、カスタマを支援する手順は、パーソナルプロキシＰＰが、カスタマによって報告された機能不良を解決するためにコールセンタアドバイザに連絡する必要を検出したら、コールセンタに連絡するようにカスタマに提案する代わりに、コールセンタアドバイザのパーソナルプロキシＰＰとのセッションを直接起動する、代替の実施形態も想定する。

オペレータ間の協働に関しては、以下に記載することを再び注記することができる。図７を参照して説明した手順は、オペレータ間のセッションを開くためにＰＰによって使用される、または、さもなければ、オペレータに提示される、連絡されるべきオペレータの名前の順序立ったリストを準備することを想定する。前記リストは、動的な方法で作成される。パーソナルプロキシＰＰは、協働セッションを開く必要があるときに、オペレーショナルマネージャＯＭに、連絡されるべきオペレータのリストを作成するように要求し、必要とされる指示（例えば、オペレータによって実行されるアクティビティの、および前記アクティビティのために要求される技能の指示）をオペレーショナルマネージャＯＭに提供する。オペレーショナルマネージャＯＭは、エキスパータイズインベントリＥＩに問い合わせ、得られた情報に基づいて、要求されたリストを（同じ仮想チームのオペレータを入れて、または、他のチームのオペレータさえも入れて）作成する。リストは、オペレータの技能に従って、そして、異なるチームの場合は、チームに従って順序付けられる（最初に、同じ仮想チームのオペレータが、技能の等級の高い順に入れられ、次に、その他のチームのオペレータが、再び、技能の等級の高い順に入れられる）。最後に、オペレーショナルマネージャＯＭは、作成されたリストを、パーソナルプロキシＰＰに送る。

前に提示された実施形態の代替の実施形態では、パーソナルプロキシＰＰは、１人のオペレータと、２人以上のその他のオペレータとの間のセッションを開いてもよく、それらのオペレータは、協働作業を支援するためのツールを含むさまざまなツールを介して相互に作用してもよい。

さらに、カスタマとオペレータとの間の協働の場合、カスタマとオペレータとの間のセッションを開くためにパーソナルプロキシＰＰによって使用される、または、さもなければ、カスタマに提示される、連絡されるべきオペレータのリストの、オペレーショナルマネージャＯＭによる動的作成の、同じ様式が適用される。

次に、上に提示した実施形態の代替の実施形態における、パーソナルプロキシＰＰ上でのオペレータプロファイルの管理を考慮すると、各ＰＰは、関連付けられたオペレータのプロファイルに加えて、その他のオペレータプロファイルも維持する（これは、パフォーマンスの理由のために行われる。このようにして、連絡されるべき他のオペレータのデータにアクセスするための時間が減少する）。特に、第１の代替案は、前記データが、パーソナルプロキシＰＰが関連付けられたオペレータの仮想チームと同じ仮想チーム内の、すべてのオペレータに言及しなければならないということを想定する。第２の代替案も可能であり、それによれば、パーソナルプロキシＰＰ上に記憶されるオペレータプロファイルに関するデータは、対象となる仮想チーム内のオペレータのサブセットに言及し、特に、チームに要求されるマクロ技能を高度に備えたオペレータに関係する。各マクロ技能について、１つ以上のプロファイルが選択される。これらのプロファイルは、特定のマクロ技能に関するエキスパート（すなわち、そのオペレータの技能は、所与の仮想チームのオペレータのうちで最高である）のオペレータのプロファイルである。前記データが最初にダウンロードされる方法、および、その後更新される方法は、パーソナルプロキシＰＰに関連付けられたオペレータのプロファイルについて説明したものと比較して変わりはない。ただし、この場合、パーソナルプロキシＰＰに転送されるデータの中に、いずれのデータが、パーソナルプロキシＰＰ自体に関連付けられたオペレータのプロファイルに言及するかの指示も存在する。

さらなる実施形態における、オペレータプロファイルの管理は、パーソナルプロキシＰＰがいかなる特定のオペレータにも、事前に関連付けられていないという意味で、完全に動的である。所与のオペレータとの関連付けは、オペレータが認証した場合に行われる。この場合、オペレータによる認証に続いて、プロキシＰＰは、オペレーショナルマネージャＯＭに、オペレータによって供給された認証データを転送し、前記オペレータに関するプロファイルデータをダウンロードするようにオペレーショナルマネージャＯＭに要求する。オペレーショナルマネージャＯＭは、供給された信任状の正しさの事前検査の後で、当該のプロファイルのデータをＰＰ上にダウンロードする。さらに、この場合、オペレーショナルマネージャＯＭがパーソナルプロキシＰＰに、パーソナルプロキシＰＰに関連付けられたオペレータのプロファイルのデータのみでなく、その他のオペレータのプロファイルのデータも、上に示したのと同じ選択肢（オペレータの仮想チームのすべてのオペレータに言及するデータ、または、仮想チームのオペレータのサブセットに言及するデータ）を使用して送る、代替の実施形態を想定することが可能である。

オペレータを支援するためのワークフローの管理の手順に関しては、前述したものを基準にして、ワークフローをダウンロードするために採用される様式の、代替の実施形態を想定することが可能である。

第１の実施形態は、パーソナルプロキシＰＰの起動時に、オペレータを導くためのすべてのワークフローが、そのパーソナルプロキシＰＰ上にダウンロードされることを想定する。

第２の実施形態によれば、代わりに、（パーソナルプロキシＰＰがオペレータに、静的な方法で関連付けられるか、または動的な方法で関連付けられるかにより）パーソナルプロキシＰＰの起動時に、またはオペレータの認証の後で、オペレータを導くためのすべてのワークフローが、特定の仮想チームのみに適用できる、可能なワークフローを除いて、パーソナルワークフローＰＰ上にダウンロードされる。特定の仮想チームのみに適用されるワークフローは、それらのチームによって管理される機器の特性に基づいて、および／または、チームのメンバーの特定の技能に基づいて、定義することが可能である。

最後に、第３の実施形態によれば、パーソナルプロキシＰＰの起動時に、またはオペレータ認証の後で、ＰＰが関連付けられたオペレータの技能と適合するワークフローのみが、パーソナルワークフローＰＰ上にダウンロードされる。

採用される、可能な代替の実施形態に基づいて、インタフェースＰＩの機能も変化してもよい。特に、インタフェースＰＩ上でフィールドエンジニアによって受け取られる唯一の指示が、そのフィールドエンジニアが行く必要のあるサイトに関する指示である場合、インタフェースＰＩは、フィールドエンジニアに、所与のサイトにおいて行われるべき（フィールドエンジニアのプロファイルと適合する）介入の組を提示し、そして、実行される介入を選択し、その介入を担当するのは、フィールドエンジニア自身である。

したがって、本発明の基礎となる原理を損なうことなく、詳細および実施形態は、単に例として本明細書に記載されたものを基準として、添付の特許請求の範囲によって規定される本発明の範囲を逸脱することなく、かなりであっても変化してもよい。

Claims (37)

1. −プロキシエージェント（ＰＰ）が実行された複数の端末装置（ＴＤ）であって、前記プロキシエージェントは、前記端末装置を、ワークフローまたはルールを処理するための、ワークフローベースまたはルールベースのプロセスエンジン（ＰＥ）と、前記ワークフローまたはルールの少なくとも部分を表すための、ユーザインタフェース（ＰＩ）ととして機能させる、複数の端末装置（ＴＤ）と、
   −前記端末装置への、前記ワークフローまたはルールの伝送を管理するように構成された、少なくとも１つの遠隔マネージャリソース（ＭＭ）と
   −オペレーショナルエージェント（ＯＡ）が実行された複数のホストであって、前記オペレーショナルエージェント（ＯＡ）は、前記ホストに、相互に作用することによって、前記プロキシエージェントが実行された前記端末装置のオペレーションを調整させ、前記オペレーションは、前記プロセスエンジン（ＰＥ）によるワークフロー又はルールの処理を含む、複数のホストと
   を含む、分散型オペレーションシステム。
2. 前記プロキシエージェントは、前記ワークフローまたはルールの処理中に、前記端末装置を、あるソフトウェアアプリケーション（ＲＰ）が実行されたさらなる装置（ＮＡ）と情報交換を行うための、相互接続インタフェースとして機能させる、請求項１に記載のシステム。
3. 前記ソフトウェアアプリケーションは、前記さらなる装置を、ワークフローベースまたはルールベースのプロセスエンジン（ＰＥ）として機能させ、前記プロセスエンジンとして機能した前記端末装置は、前記相互接続インタフェースを介して、前記プロセスエンジンとして機能した前記前記さらなる装置と相互作用するように構成される、請求項２に記載のシステム。
4. 前記ユーザインタフェースは、対話型インタフェースである、請求項１に記載のシステム。
5. オペレーショナルマネージャ（ＯＭ）が実行されたホストをさらに含み、該オペレーショナルマネージャ（ＯＭ）が実行された該ホストは、前記オペレーショナルエージェントが実行された前記ホストを管理および制御する機能を有する、請求項１に記載のシステム。
6. 前記オペレーショナルエージェントは、ホストを、それぞれのワークフローベースまたはルールベースのプロセスエンジン（ＰＥ）として機能させる、請求項１に記載のシステム。
7. 前記オペレーショナルマネージャは、ホストを、ワークフローベースまたはルールベースのプロセスエンジン（ＰＥ）として機能させる、請求項５に記載のシステム。
8. 前記プロキシエージェントが実行された前記端末装置は、相互動作関係で、直接相互作用するように構成される、請求項１に記載のシステム。
9. ワークフローまたはルールによって定められたプロセスのリポジトリ（ＯＤＢ）をさらに含む、請求項１に記載のシステム。
10. データモデルのリポジトリ（ＯＤＢ）をさらに含む、請求項１に記載のシステム。
11. 前記ワークフローまたはルールを前記端末装置に分散するための、コントロールエージェント（ＣＡ）をさらに含む、請求項１に記載のシステム。
12. 前記ワークフローまたはルールの処理に関連したパフォーマンスデータを記憶するための、パフォーマンスデータベース（ＰＤＢ）をさらに含む、請求項１に記載のシステム。
13. 前記プロキシエージェントが実行された前記端末装置によって実行されたプロセスを記憶するための、オペレーショナルログ（ＯＬ）をさらに含む、請求項１に記載のシステム。
14. ユーザまたはネットワーク機器への介入を管理するように構成された、請求項１〜１３のいずれか一項に記載のシステム。
15. 前記ワークフローまたはルールは、前記介入の実行対象となる前記ユーザまたはネットワーク機器の状態に応じたものである、請求項１４に記載のシステム。
16. 前記複数の端末装置のうちの少なくとも１つはポータブル装置である、請求項１に記載のシステム。
17. 前記ソフトウェアアプリケーションは、プロキシエージェント（ＲＰ）を含む、請求項２または３に記載のシステム。
18. 前記プロキシエージェントが実行された前記端末装置の各々は、前記ソフトウェアアプリケーションのうちの前記プロキシエージェントが実行された前記さらなる装置のとの通信セッションを自動的に起動するように構成される、請求項１７に記載のシステム。
19. 前記ユーザインタフェースはグラフィカルインタフェース（ＧＵＩ）を管理する、請求項１に記載のシステム。
20. 前記端末装置の各々は、前記ユーザが前記プロキシエージェントを起動するように構成された、請求項１に記載のシステム。
21. ユーザまたはネットワーク機器への介入を管理する方法であって、
    −端末装置が、前記ユーザまたはネットワーク機器への介入を管理するための第１のプロキシエージェント（ＰＰ）を実行するステップであって、前記第１のプロキシエージェントは、前記端末装置を、ワークフローまたはルールを処理するワークフローまたはルールベースエンジンとして機能させ、前記第１のプロキシエージェントは、分散型アーキテクチャが含む階層レイヤのうちのあるレイヤに関連付けられた、ステップと、
    複数のホストが、オペレーショナルエージェント（ＯＡ）を実行するステップであって、前記オペレーショナルエージェント（ＯＡ）は、前記複数のホストに、相互に作用することによって、前記第１のプロキシエージェント（ＰＰ）が実行された前記端末装置のオペレーションを調整させ、前記オペレーションは、前記プロセスエンジンによるワークフローまたはルールの処理を含み、前記オペレーショナルエージェント（ＯＡ）は、前記分散型アーキテクチャが含む階層レイヤのうちのあるレイヤに関連付けられた、ステップと、
    −少なくともユーザまたはネットワーク機器への介入を、前記第１のプロキシエージェントが実行された前記端末装置のうちの１つを介して、前記ユーザまたはネットワーク機器と関連付けられた少なくとも１つの管理リソースとの対話形式（ＰＴＰ）で実行するための命令信号を、前記第１のプロキシエージェントが実行された前記端末装置のうちの１つが生成するステップであって、それにより、前記命令信号は前記ユーザまたはネットワーク機器の状態に応じたものとなる、ステップと
    を含む方法。
22. 前記管理リソースは、前記ユーザまたはネットワーク機器と関連付けられた第２のプロキシエージェント（ＲＰ）を実行し、該第２のプロキシエージェントは、前記管理リソースを、ワークフローベースまたはルールベースのプロセスエンジンとして機能させる、請求項２１に記載の方法。
23. 前記第１のプロキシエージェントのそれぞれは、１つの端末装置を、１つのワークフローまたはルールベースエンジンとして機能させる、請求項２１または２２に記載の方法。
24. 前記第１のプロキシエージェント（ＰＰ）は、前記端末装置を、前記命令信号の少なくとも部分を表すため、および実行されるワークフローまたはルールと相互作用するための、パーソナルインタフェース（ＰＩ）として機能させる、請求項２３に記載の方法。
25. 前記分散型アーキテクチャの前記階層レイヤは、
    −管理および制御機能を有し、前記オペレーショナルエージェント（ＯＡ）が実行された前記ホストのオペレーションを監視する、オペレーショナルマネージャ（ＯＭ）が実行されたホストを含むレイヤ
    を含むことを特徴とする、請求項２１に記載の方法。
26. 前記第１のプロキシエージェント（ＰＰ）が実行された複数の前記端末装置を介した介入の分散実行が、前記オペレーショナルエージェント（ＯＡ）が実行された前記ホストに割り当てられたことを特徴とする、請求項２５に記載の方法。
27. 前記第１のプロキシエージェント（ＰＰ）のそれぞれに、１人のオペレータまたはカスタマを支援するタスクが割り当てられ、それにより、前記介入の実行は、前記管理および制御機能から分離されることを特徴とする、請求項２５に記載の方法。
28. 前記ワークフローまたはルールベースエンジンは、プロセスエンジン（ＰＥ）を含むことを特徴とする、請求項２１に記載の方法。
29. 前記分散型アーキテクチャ内のすべての前記レイヤに、プロセスエンジン（ＰＥ）が提供されたことを特徴とする、請求項２５に記載の方法。
30. 前記プロセスエンジン（ＰＥ）は、ワークフローベースまたはルールベースであることを特徴とする、請求項２８または２９に記載の方法。
31. 提供されるそれぞれの命令情報に基づいてそれぞれの機能を実行するように構成された構成要素（ＰＰ、ＯＡ、ＯＭ）を、前記レイヤは含むことを特徴とする、請求項２５に記載の方法。
32. 前記命令情報は、
    −ワークフローおよびルールのうちの少なくとも１つを含むプロセス定義と、
    −データモデル定義と
    のうちの少なくとも１つを含む、請求項３１に記載の方法。
33. 前記第１のプロキシエージェント（ＰＰ）は、前記端末装置を、相互動作関係で、直接相互作用させ、それにより、前記命令信号のうちの少なくとも１つは、第１のプロキシエージェント（ＰＰ）が実行された端末装置間の相互作用により生成されることを特徴とする、請求項２１に記載の方法。
34. 前記第１のプロキシエージェント（ＰＰ）は、前記端末装置に、前記リソースプロキシエージェント（ＲＰ）が実行された前記管理リソースとピアツーピア（ＰＴＰ）相互作用させる、請求項２１に記載の方法。
35. 前記分散型アーキテクチャの少なくとも１つのレイヤに関連付けられたコントロールエージェント（ＣＡ）によって、ホストに、
    −前記分散型アーキテクチャの前記レイヤに、プロセス定義を分散するステップと、
    −前記分散型アーキテクチャの前記レイヤに、データモデル定義を分散するステップと、
    −前記分散型アーキテクチャの前記レイヤの状態を監視するステップと
    からなる群から選択された少なくとも１つのステップを実行させるステップを含むことを特徴とする、請求項２５に記載の方法。
36. 遠隔マネージャリソース（ＭＭ）が、
    −前記コントロールエージェント（ＣＡ）が実行された前記ホストを介した、前記分散型アーキテクチャの前記レイヤへのプロセス定義の前記分散を管理するステップと、
    −前記コントロールエージェント（ＣＡ）が実行された前記ホストを介した、前記分散型アーキテクチャの前記レイヤへのデータモデル定義の前記分散を管理するステップと、
    −前記コントロールエージェント（ＣＡ）が実行されたホストを介して、前記分散型アーキテクチャの前記レイヤの前記状態を監視するステップと
    からなる群から選択された少なくとも１つのステップを実行するステップを含むことを特徴とする、請求項３５に記載の方法。
37. 少なくとも１つのコンピュータのメモリ内にロード可能であり、プロキシエージェント（ＰＰ）とオペレーショナルエージェント（ＯＡ）とを含むコンピュータプログラムであって、
    前記プロキシエージェントは、前記ユーザまたはネットワーク機器への介入を管理するためのプログラムであり、前記プロキシエージェントは、第１のコンピュータを、ワークフローまたはルールを処理するワークフローまたはルールベースエンジンとして機能させ、前記プロキシエージェントは、分散型アーキテクチャが含む階層レイヤのうちのあるレイヤに関連付けられ、
    前記オペレーショナルエージェント（ＯＡ）は、複数の第２のコンピュータに、相互に作用することによって、前記プロキシエージェント（ＰＰ）が実行された前記第１のコンピュータのオペレーションを調整させ、前記オペレーションは、前記プロセスエンジンによるワークフローまたはルールの処理を含み、前記オペレーショナルエージェント（ＯＡ）は、前記分散型アーキテクチャが含む階層レイヤのうちのあるレイヤに関連付けられ、
    少なくともユーザまたはネットワーク機器への介入を、前記プロキシエージェントが実行された前記第１のコンピュータのうちの１つを介して、前記ユーザまたはネットワーク機器と関連付けられた少なくとも１つの管理リソースとの対話形式（ＰＴＰ）で実行するための命令信号を、前記プロキシエージェントは前記第１のコンピュータにさらに生成させ、それにより、前記命令信号は前記ユーザまたはネットワーク機器の状態に応じたものとなる、コンピュータプログラム。

Images