(57)【要約】  設備保守の作業管理のシステムおよび方法を示す。このシステムには、第１設備で実行されるタスクを含む情報の第１組を受け取り、第１設備で第１作業スケジュールを実行するために選択された第１ユーザに関する第１作業スケジュールを生成するように構成された中央管理サーバが含まれる。このシステムには、さらに、第１設備側の第１クライアント・デバイスが含まれ、この第１クライアント・デバイスは、中央管理サーバから第１作業スケジュールを受け取り、電子管理インターフェースを介して第１ユーザに第１作業スケジュールを表示するように構成される。電子インターフェースは、さらに、第１ユーザからタスク完了データを受け取り、そのデータを中央管理サーバに送るように構成される。中央管理サーバによってタスク完了データが受け取られる時に、中央管理サーバは、第１ユーザから受け取るタスク完了データに基づいて作業スケジュールの状況を更新するように構成される。（１１０、１３０、１２０、１１４、１３２、１２４、１２８）。
2005509220.tif 000002
【特許請求の範囲】
【請求項１】
ウェブベース作業管理システムであって、
広域ネットワークを介して通信するように構成された中央管理サーバであって、前記中央管理サーバは、スケジューリングされ第１設備で実行されるタスクの組を維持するように構成され、各タスクは、前記タスクを表すグラフィカル・アイコンを関連付けられ、前記中央管理サーバは、さらに、タスクの第１サブセットを前記タスクの実行のために第１ユーザに割り振るように構成され、前記中央管理サーバは、さらに、前記第１ユーザに対応する第１要求メッセージを受け取り、これに応答して、タスクの前記第１サブセットに対応する前記アイコンを含む第１作業スケジュール・メッセージを送る、中央管理サーバと、
前記第１設備に対応する第１クライアント・デバイスであって、前記第１クライアント・デバイスは、前記広域ネットワークを介して前記中央管理サーバと通信するように構成され、前記第１クライアント・デバイスは、ユーザ入力を受け取り、ユーザ・データを表示するユーザ・インターフェースを含み、前記第１クライアント・デバイスは、前記第１ユーザからログイン要求を受け取り、これに応答して、前記第１ユーザに対応する前記第１要求メッセージを送るように構成され、前記第１クライアント・デバイスは、さらに、前記第１作業スケジュール・メッセージを受け取り、これに応答して、前記第１作業スケジュール・メッセージで受け取られる前記アイコンを表示するように構成される、第１クライアント・デバイスと
を含む作業管理システム。
【請求項２】
タスクを表す各グラフィカル・アイコンが、前記タスクの状況を更新するために選択することができる状況ダイアログ・ボックスを含み、
前記第１クライアント・デバイスが、さらに、前記第１作業スケジュール・メッセージで受け取られる前記アイコンのそれぞれと共に前記状況ダイアログ・ボックスを表示するように構成され、前記第１クライアント・デバイスが、前記第１作業スケジュール・メッセージで受け取られる前記アイコンの選択された１つに関する前記状況ダイアログ・ボックスの選択を検出し、これに応答して、前記選択された状況ダイアログ・ボックスに関連する前記アイコンの前記選択された１つに対応するタスクおよび前記タスクの状況を識別するタスク更新メッセージを送るように構成され、
前記中央管理サーバが、さらに、前記タスク更新メッセージを受け取り、これに応答して、前記タスク更新メッセージで識別される前記タスクに対応するタスク・レコードを、前記タスク更新メッセージで供給される識別される前記タスクの前記状況を用いて更新するように構成される
請求項１に記載の作業管理システム。
【請求項３】
前記中央管理サーバが、さらに、タスクの前記第１サブセットの前記状況に関する状況要求を監督ユーザから受け取り、前記監督ユーザがタスクの前記第１サブセットの前記状況へのアクセスを許可されることを検証し、前記監督ユーザに状況応答メッセージを返すように構成される、請求項２に記載の作業管理システム。
【請求項４】
前記中央管理サーバが、さらに、タスクの前記第１サブセットの少なくとも１つの前記状況の変更を要求する状況更新要求を前記監督ユーザから受け取り、これに応答して、タスクの前記第１サブセットの前記少なくとも１つに対応する前記タスク・レコードを更新するように構成される、請求項３に記載の作業管理システム。
【請求項５】
前記中央管理サーバが、さらに、タスクの前記第１サブセットの前記少なくとも１つの前記状況の前記変更が完了したタスクの拒否であるかどうかを検出し、これに応答して、前記第１ユーザへの出力のためにアラート・メッセージを作成するように構成される、請求項４に記載の作業管理システム。
【請求項６】
前記中央管理サーバが、さらに、前記第１ユーザへの出力のための前記アラート・メッセージを、前記第１ユーザからの後続の要求メッセージに含めるように構成される、請求項５に記載の作業管理システム。
【請求項７】
前記中央管理サーバが、さらに、タスクの前記第１サブセット内で未完了タスクを検出し、これに応答して、前記未完了タスクを再スケジューリングするように構成される、請求項２に記載の作業管理システム。
【請求項８】
タスクを表す各グラフィカル・アイコンが、前記タスクに対応する指示を要求するために選択することができる指示ダイアログ・ボックスを含み、
前記第１クライアント・デバイスが、さらに、前記第１作業スケジュール・メッセージで受け取られる前記アイコンのそれぞれを用いて前記指示ダイアログ・ボックスを表示するように構成され、前記第１クライアント・デバイスが、前記第１作業スケジュール・メッセージで受け取られる前記アイコンの選択された１つに関する前記指示ダイアログ・ボックスの選択を検出し、これに応答して、前記選択された指示ダイアログ・ボックスに関連する前記アイコンの前記選択された１つに対応する前記タスクを識別する指示要求メッセージを前記中央管理サーバに送るように構成され、前記第１クライアント・デバイスが、さらに、前記中央管理サーバから指示ファイルを受け取り、前記指示ファイルを前記第１ユーザに表示するように構成され、
前記中央管理サーバが、さらに、前記指示要求メッセージを受け取り、これに応答して、前記指示要求メッセージで識別される前記タスクに対応する前記指示ファイルを入手し、前記指示ファイルを前記第１クライアント・デバイスに送るように構成される
請求項１に記載の作業管理システム。
【請求項９】
タスクを表す各グラフィカル・アイコンが、前記タスクに対応する指示を要求するために選択することができる指示ダイアログ・ボックスを含み、
前記第１クライアント・デバイスが、さらに、前記第１作業スケジュール・メッセージで受け取られる前記アイコンのそれぞれと共に前記指示ダイアログ・ボックスを表示するように構成され、前記第１クライアント・デバイスが、前記第１作業スケジュール・メッセージで受け取られる前記アイコンの選択された１つに関する前記指示ダイアログ・ボックスの選択を検出し、これに応答して、前記選択された指示ダイアログ・ボックスに関連する前記アイコンの前記選択された１つに対応する前記タスクを識別する指示要求メッセージを前記中央管理サーバに送るように構成され、前記第１クライアント・デバイスが、さらに、前記中央管理サーバから指示ファイルを受け取り、前記指示ファイルを前記第１ユーザに表示するように構成され、
前記中央管理サーバが、さらに、前記指示要求メッセージを受け取り、これに応答して、前記指示要求メッセージで識別される前記タスクに対応し、前記第１ユーザに関連する事前に選択された言語に対応する前記指示ファイルを入手し、前記指示ファイルを前記第１クライアント・デバイスに送るように構成される
請求項１に記載の作業管理システム。
【請求項１０】
タスクを表す各グラフィカル・アイコンが、前記タスクに対応する地図を要求するために選択することができる地図ダイアログ・ボックスを含み、
前記第１クライアント・デバイスが、さらに、前記第１作業スケジュール・メッセージで受け取られた前記アイコンのそれぞれと共に前記地図ダイアログ・ボックスを表示するように構成され、前記第１クライアント・デバイスが、前記第１作業スケジュール・メッセージで受け取られた前記アイコンの選択された１つに関する前記地図ダイアログ・ボックスの選択を検出し、これに応答して、前記選択された地図マップ・ダイアログ・ボックスに関連する前記アイコンの前記選択された１つに対応する前記タスクを識別する地図要求メッセージを前記中央管理サーバに送るように構成され、前記第１クライアント・デバイスが、さらに、前記中央管理サーバから地図ファイルを受け取り、前記地図ファイルを前記第１ユーザに表示するように構成され、
前記中央管理サーバが、さらに、前記地図要求メッセージを受け取り、これに応答して、前記地図要求メッセージで識別される前記タスクに対応する前記マップ・ファイルを入手し、前記マップ・ファイルを前記第１クライアント・デバイスに送るように構成される
請求項１に記載の作業管理システム。
【請求項１１】
前記中央管理サーバが、さらに、前記第１ユーザへの配布用のメッセージ・ファイルを受け取り、前記メッセージ・ファイルを前記第１クライアント・デバイスに送るように構成され、
前記第１クライアント・デバイスが、さらに、前記メッセージ・ファイルを受け取り、前記第１ユーザによるログイン要求に応答して、前記メッセージ・ファイルを表示するように構成される
請求項１に記載の作業管理システム。
【請求項１２】
前記中央管理サーバが、さらに、管理ユーザが前記第１ユーザへの配布用の前記メッセージ・ファイルを生成することを許可するように構成される、請求項１１に記載の作業管理システム。
【請求項１３】
前記中央管理サーバが、さらに、前記タスクの実行のために第２ユーザにタスクの第２サブセットを割り振るように構成され、前記中央管理サーバが、さらに、前記第２ユーザに対応する第２要求メッセージを受け取り、これに応答して、タスクの前記第２サブセットに対応する前記アイコンを含む第２スケジュール・メッセージを送るように構成され、
前記第１クライアント・デバイスが、さらに、前記第２ユーザからログイン要求を受け取り、これに応答して、前記第２ユーザに対応する第２要求メッセージを送るように構成され、前記第１クライアント・デバイスが、さらに、前記第２作業スケジュール・メッセージを受け取り、これに応答して、前記第２作業スケジュール・メッセージで受け取られる前記アイコンを表示するように構成される
請求項１に記載の作業管理システム。
【請求項１４】
前記中央管理サーバが、さらに、タスクの前記第２サブセットにアクセスしないように前記第１ユーザを制限し、タスクの前記第１サブセットのアクセスしないように前記第２ユーザを制限するように構成される、請求項１３に記載の作業管理システム。
【請求項１５】
前記中央管理サーバが、さらに、前記第１設備に関連する第１顧客に対応するポリシの第１組に従ってタスクの前記組を生成するように構成される、請求項１に記載の作業管理システム。
【請求項１６】
前記中央管理サーバが、さらに、第２顧客に対応するポリシの第２組に従ってタスクのもう１つの組を生成するように構成される、請求項１５に記載の作業管理システム。
【請求項１７】
前記第１クライアント・デバイスが、前記中央管理サーバからのメッセージからのデータを表示するブラウザ・アプリケーションを含み、前記中央管理サーバが、さらに、前記ブラウザ・アプリケーションと互換のメッセージを前記第１クライアント・デバイスに送るように構成される、請求項１に記載の作業管理システム。
【請求項１８】
前記第１クライアント・デバイスが、タッチ・スクリーン・インターフェース・デバイス、ペン・ベースの入力デバイス、キーパッド入力デバイス、およびカードスワイプ・デバイスの１つを含む、請求項１に記載の作業管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、設備管理に関する。具体的に言うと、本発明は、ネットワークを介して中央管理サーバと通信するクライアント・デバイスを各設備で使用する設備管理のシステムおよび方法に関する。
【背景技術】
【０００２】
本願は、２００１年１１月５日出願の米国仮出願第０９／９９２４０６号の優先権を主張する出願である。
【０００３】
設備保守は、もはや、単なる間接費とはみなされず、会社の成功において重要な役割を演ずる。企業がその資産を最適化でき、保守できればできるほど、コストおよび品質の領域で競争力が高まる。
【０００４】
成功裡に動作する設備を保守する際の重要な要因の１つが、作業スケジューリングである。コンピュータ化された作業スケジューリング・システムの導入の前に、作業のスケジューリングは、手作業で実行された。手作業のスケジューリング・プロセスには、どの作業を実行しなければならず、時刻、それを実行するのに必要な労働者およびツールなどの材料および資源、ならびに、作業順序に関連する優先順位などのスケジューリングに影響する情報を判定することが含まれた。スケジューリング・プロセスを実行しなければならない頻度は、多数の他の要因と共に、コンピュータ化されたスケジューリング・システムの開発に貢献した。
【０００５】
そのようなコンピュータ化されたスケジューリング・システムの１つが、フィールズ（Ｆｉｅｌｄｓ）他の米国特許第５１１１３９１号に記載されている。フィールズの特許は、リモート位置でのスタッフ・スケジュールの作成のシステムおよび方法に関し、位置固有の値およびヒストリカル・データを考慮に入れると同時に、スケジューリング標準および就業規則に関する会社ポリシに従うものである。もう１つのコンピュータ化されたスケジューリング・システムが、ホンマ（Ｈｏｎｍａ）他の米国特許第５３４３３８７号に記載されている。ホンマの特許は、ビルディング管理システムを対象とする。具体的には、ホンマの特許には、ビルディングの調査を行うための保守契約の下でクライアント・ビルディングを周期的に訪問するために労働者を派遣する前に周期的作業のスケジュール表を準備するのに有用な周期的ビルディング保守作業スケジュール準備システムが記載されている。
【０００６】
作業スケジューリングのほかに、保守分析および労働者トレーニングも、成功裡に動作する設備の保守の重要な要因である。そのようなシステムの１つが、リチャードソン（Ｒｉｃｈａｒｄｓｏｎ）の米国特許第５８６７８２３号に記載されている。リチャードソンの特許には、所与の作業を実行するための作業ガイダンスおよび指示を提供し、書面の記録を必要とせずに保守作業を記録する、労働者によって持ち運ばれるハンドヘルド・システムが記載されている。
【特許文献１】米国特許第５１１１３９１号
【特許文献２】米国特許第５３４３３８７号
【特許文献３】米国特許第５８６７８２３号
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明のシステムおよび方法には、作業管理のシステムおよび方法が含まれる。既存のシステムによって、電子作業スケジューリングが記述され、労働者に指示が提供されるが、システムとのユーザ対話を使用可能にする動的作業管理システムの必要がまだ残っている。
【課題を解決するための手段】
【０００８】
本発明の一態様によれば、作業管理のシステムに、第１設備でスケジューリングされる、実行すべきタスクを含む情報の第１組を受け取るように構成された中央管理サーバが含まれる。中央管理サーバが、情報の第１組を受け取る時に、中央管理サーバは、第１設備でスケジューリングされる第１作業を実行するために選択された第１ユーザに関する第１作業スケジュールを生成する。本発明の一態様によれば、中央管理サーバは、さらに、第１作業スケジュールに対応する第１タスク状況更新メッセージを受け取り、それに応答して、第１タスク状況更新メッセージで受け取られたタスク完了データに基づいて、作業スケジュールの各タスクの状況を更新するように構成される。本発明の例示的システムには、さらに、第１設備に対応する第１クライアント・デバイスが含まれる。第１クライアント・デバイスには、第１設備の第１ユーザに第１作業スケジュールを表示するように構成された電子管理インターフェースが含まれ、さらに、第１クライアント・デバイスは、第１作業スケジュールに含まれる各タスクに関するタスク完了データを第１ユーザから受け取る。クライアント・デバイスは、さらに、第１ユーザからのタスク完了データを第１タスク更新メッセージに組み込み、第１タスク更新メッセージを中央管理サーバに送信するように構成される。本発明の一実施形態による中央管理サーバには、さらに、第１作業スケジュールを保管するように構成されたデータベースが含まれ、このデータベースには、複数のタスク識別子が含まれ、各タスク識別子は、第１作業スケジュールで指定される複数のタスクの対応する１つに関連する。本発明の一実施形態によれば、中央管理サーバは、ウェブベース中央管理サーバであり、第１クライアント・デバイスの電子管理インターフェースは、ウェブベースの電子管理インターフェースである。
作業管理のシステムおよび方法の前述および他の特徴および長所は、添付図面に示されたシステムおよび方法の好ましい実施形態の以下のより具体的な説明から明白になる。
本発明の好ましい実施形態を、図面に関して説明する。
【発明を実施するための最良の形態】
【０００９】
本発明は、顧客設備の作業管理サービスを提供するシステムおよび方法を対象とする。
図１は、本発明の一実施形態による設備作業管理を提供するネットワーク・アーキテクチャ１００の一実施形態を示す機能ブロック図である。ネットワーク・アーキテクチャ１００には、ワールド・ワイド・ウェブまたは公衆ネットワークなど、一方では第１設備１１０および第２設備１２０と、他方では中央管理サーバ１３０との間の通信パスを提供する広域ネットワーク（ＷＡＮ）１０２が含まれる。
【００１０】
設備１１０には、通信リンク１１４を介してＷＡＮ１０２と通信する電子管理インターフェース（ＥＭＩ）１１２ユニットが含まれる。同様に、設備１２０には、それぞれ通信リンク１２４および１２８を介してＷＡＮ１０２と通信するＥＭＩユニット１２２および１２６が含まれる。ＥＭＩユニットは、めいめいの設備に位置決めされ、その設備で保守機能を実行するユーザを管理する情報インターフェースを提供する。設備のサイズ、ユーザの数、または便利さに基づく他の要因に応じて、各設備に１つまたは複数のＥＭＩを設けることができる。
【００１１】
中央管理サーバ１３０は、通信リンク１３２を介してＷＡＮ１０２と通信する。サーバ１３０は、設備で実行されるタスクのリスト、スタッフのリスト、タスクの実行のスケジュール、タスク・スケジュールおよび作業スケジュールの状況、ならびにタスクの実行に関する品質データなどの、施設の保守に関するデータを維持するために、データベース１４０に結合される。ＥＭＩは、たとえばクライアント−サーバ関係で、ＷＡＮ１０２を介してサーバ１３０と通信するクライアント・デバイスを表す。ＷＡＮ１０２を介する通信によって、設備１１０および１２０からサーバ１３０へのアクセスが提供されて、設備の保守に関する情報が入手され、完了状況が収集される。
【００１２】
ＥＭＩユニットによって、設備でタスクを実行するユーザのための、設備での使い易いインターフェースがもたらされる。ある手法では、ＥＭＩが、それによってサービスされる設備に添付され、その結果、ＥＭＩおよび設備が、直接の関係を有し、ＥＭＩを使用して設備を識別できるようになる。ＥＭＩ１１２は、設備１１０に配置される、機能を特殊化されたコンピュータである。ＥＭＩ１１２は、マイクロプロセッサ１５０を有し、マイクロプロセッサ１５０は、プロセッサ・バスを介してユーザ・インターフェース１５２、ローカル・データベース１５４、メモリ・ストア１５６、および通信インターフェース１５８に結合される。
【００１３】
ユーザ・インターフェース１５２は、さまざまな形をとることができる。たとえば、インターフェース１５２を、グラフィカル・ユーザ・インターフェース（ＧＵＩ）を有するタッチ・スクリーンとすることができ、これを用いて、ユーザが、画面に触れることによって制御入力およびデータ入力を行うことができ、また、これによって、画面に表示されるアイコンを介してグラフィカルな形でユーザにデータが出力される。ＥＭＩのディスプレイは、たとえば、液晶ディスプレイ（ＬＣＤ）画面または陰極線管（ＣＲＴ）画面を使用して構成することができる。ユーザ・インターフェース１５２で、たとえば、ペン・ベース入力システム、キーボード入力システム、またはマウス・ポインティング・デバイスを使用することができる。ユーザ・インターフェース１５２の設計では、さまざまなデータ入出力デバイスを使用することができる。
【００１４】
データベース１５４によって、ＥＭＩのローカル・マス・ストレージが提供される。データベース１５４を使用して、サーバ１３０との間でデータを通信するブラウザ・アプリケーションに関連する命令ならびにオペレーティング・システム命令および通信プロトコルを保管することができる。さらに、ＷＡＮ１０２を介するサーバ１３０との通信が使用不能である時に、ユーザ・インターフェースを介してアクセスできるデータを、ローカルに保管することができる。データを、後に、通信が使用可能になった時にサーバ１３０にアップロードするために保管することもできる。データベース１５４またはメモリ・ストア１５６のどちらも、ＥＭＩデバイスを識別し、拡張によってＥＭＩが配置された設備を識別する、デバイス識別子（ＩＤ）を保管するのに使用することができる。
【００１５】
通信インターフェース１５８によって、ＷＡＮ１０２との通信リンク１１４の一端が提供される。通信リンク１１４も、さまざまな形をとることができ、これには、ダイヤルアップ通信リンク、無線通信リンク、ブロードバンド通信リンク、ローカル・エリア・ネットワーク（ＬＡＮ）通信リンク、広域ネットワーク（ＷＡＮ）通信リンク、またはこれらの組合せが含まれる。
【００１６】
上で注記したように、ＥＭＩ１１２に、ブラウザ・アプリケーションを含めることができる。ＥＭＩ１１２に、たとえばＥＭＩのユーザからの識別情報および認証情報を受け取る、カード・リーダ、音声認識デバイス、またはビデオ認識デバイスなどの認証手段も含めることができる。ＥＭＩ１２２および１２６を、同様に構成することができ、あるいは、同一の機能を実行できるならば異なる形をとることができることに留意されたい。サーバ１３０との通信のほかに、ＥＭＩ１１２のユーザは、データベース１４０に保管されたレコードにアクセスできる複数のシステム管理者によって管理されるコール・センタとの通信セッションを確立することができる。ＥＭＩ１１２に、組み込みスピーカなど、ユーザがコール・センタのシステム管理者と会話できるようにする音声入出力手段を含めることができる。サーバ１３０には、プロセッサ・バスを介して一緒に結合される、マイクロプロセッサ１６０、ローカル・メモリ・ストア１６６、および通信インターフェース１６８が含まれる。データベース１４０は、サーバ１３０に一体化され、マイクロプロセッサ１６０のプロセッサ・バスに結合されたデバイスとすることができる。
【００１７】
図２は、図１のデータベース１４０などの中央サーバ・データベース２００に存在する可能性があるデータ構造の例を示すデータ図である。データベース２００に、ユーザ・レコード２０２を含めることができ、このユーザ・レコード２０２に、サーバ・データベースへのアクセスを有する可能性があり、サーバ１３０によって割り当てられたタスクを有する可能性があるユーザを識別するＵＳＥＲ  ＩＤが含まれる。タスクの割り当てについて、ユーザ・レコード２０２に、タスク識別子ＴＡＳＫ  ＩＤのリストＷＯＲＫ  ＳＣＨＥＤＵＬＥ（作業スケジュール）を含めることができる。各ＴＡＳＫ  ＩＤは、対応するタスク・レコード２０６を識別する数値である。しかし、ＴＡＳＫ  ＩＤは、当業者が簡単に認識するように、タスク・レコード２０６へのポインタなど、さまざまな形で実施することができる。ユーザ・レコード２０２に、ＵＳＥＲ  ＩＤによって識別されるユーザが、たとえば低い品質について拒否された割り当てられたタスクを有した回数のレコードを維持するのに使用することができるＥＲＲＯＲＣＯＵＮＴ（エラーカウント）属性も含めることができる。下で説明するように、ＥＲＲＯＲＣＯＵＮＴ属性またはその代わりにＩＮＳＴＲＵＣＴ（指示）属性を使用して、ユーザの仕事の品質を改善するために挑戦される、タスクを完了するための指示の表示をトリガすることができる。ユーザによるエラーの数も、タスク・レコードの状況から導出することができる。ＬＡＮＧＵＡＧＥ（言語）フィールドを使用して、指示をユーザに表示する言語を示すことができる。
【００１８】
本発明を用いると、ＥＭＩを使用するユーザに表示することができる、ユーザ・レコード２０２のＭＥＳＳＡＧＥ（メッセージ）フィールドにテキスト・ファイルを保管できるようにすることもできる。ＥＭＩに、ユーザのスケジュールの紙コピーを生成するプリンタまたはファクシミリ機も含めることができる。その代わりに、作業スケジュールなどの情報を受け取るいくつかの応用例で、プリンタまたはファクシミリ機によってＥＭＩを置換することができる。このシステムは、電子メールを介して情報を送信するように構成することもできる。ＭＥＳＳＡＧＥは、たとえばタスクが拒否され、そのタスクを繰り返す必要があることをユーザに警告するために、サーバ１３０によって定義することができる。ＭＥＳＳＡＧＥを、監督または管理者などの別のユーザによって、ＵＳＥＲ  ＩＤによって識別されるユーザにメッセージを送信するために定義することもできる。
【００１９】
一実施形態で、データベース１４０は、設備レコードを保管するように構成され、設備レコードは、設備レコード２０４の形をとることができる。図１を参照すると、データベース１４０に、第１の設備１１０および第２の設備１２０の設備レコードを保管することができる。図２の設備レコード２０４に、本発明による設備レコードの一実施形態が示されている。設備レコード２０４のこの実施形態は、識別子フィールドＦＡＣＩＬＩＴＹ  ＩＤによってキーイングされ、この実施形態には、ＷＯＲＫ  ＳＣＨＥＤＵＬＥにタスクのリストが含まれ、ＷＯＲＫ  ＳＣＨＥＤＵＬＥは、ＤＡＴＥ（日付）に基づくリストの組に含まれ、ＤＡＴＥの各リストは、ＷＯＲＫ  ＳＣＨＥＤＵＬＥ内のタスクのリストからなる。ＷＯＲＫ  ＳＣＨＥＤＵＬＥリストの各タスクに、タスクを識別するＴＡＳＫ  ＩＤと、タスクを実行するために割り当てられたユーザを示すＵＳＥＲ  ＩＤが含まれ、このＵＳＥＲ  ＩＤ値によって、ユーザ・レコード２０２のインスタンスがインデクシングされる。
【００２０】
ユーザ・レコード２０２または設備レコード２０４の各ＴＡＳＫ  ＩＤ値によって、タスク・レコード２０６のインスタンスがインデクシングされる。タスク・レコード２０６は、ＴＡＳＫ  ＩＤによってキーイングされ、タスク・レコード２０６には、グラフィカル・ファイルまたはグラフィカル・ファイルへのポインタのいずれかであるＴＡＳＫ  ＩＣＯＮ（タスク・アイコン）を含めることができる。あるタスクのＴＡＳＫ  ＩＣＯＮは、ユーザ・レコード２０２の自分自身のインスタンスのＷＯＲＫ  ＳＣＨＥＤＵＬＥを再検討するユーザに、または設備レコード２０４のＷＯＲＫ  ＳＣＨＥＤＵＬＥを再検討するユーザに、表示することができる。ＴＡＳＫ  ＩＣＯＮのグラフィックは、図１に示されたＥＭＩ１１２のユーザ・インターフェース１５２を介して表示される。
【００２１】
図２のタスク・レコード２０６に、タスクが実行される位置への地図を提供するグラフィカル・ファイルを含むかそれをポイントするＭＡＰ（地図）フィールドを含めることができる。タスク・レコード２０６には、タスクの状況を示すＳＴＡＴＵＳ（状況）フィールドも含まれる。ＳＴＡＴＵＳフィールドによって、タスクがスケジューリングされている、実行の期日である、再スケジューリングされた、取り消された、承認された、または拒否されたことを示すことができる。
【００２２】
図３に、設備レコード２０４、タスク・レコード２０６、およびユーザ・レコード２０２に含まれるデータの例を示す。この例では、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１の設備が、２００１年１０月７日について構成されたＷＯＲＫ  ＳＣＨＥＤＵＬＥリストを有する。このＷＯＲＫ  ＳＣＨＥＤＵＬＥリストの各要素によって、実行されるタスクのＴＡＳＫ  ＩＤと、そのタスクに割り当てられたユーザのＵＳＥＲ  ＩＤが識別される。この例では、ＵＳＥＲ  ＩＤ＝３４が、３つのタスクを割り当てられ、それらのタスクは、ＴＡＳＫ  ＩＤ＝（３２、２９、１２）によって識別される。同様に、ＵＳＥＲ  ＩＤ＝２８は、３つのタスクを割り当てられ、それらのタスクは、ＴＡＳＫ  ＩＤ＝（１７、９７、８２）によって識別される。
【００２３】
設備レコード２０４の各ＴＡＳＫ  ＩＤ値によって、タスク・レコード２０６の対応するインスタンスがインデクシングされる。この例では、タスク・レコード２０６のインスタンスは、ＴＡＳＫ  ＩＤ値１２、１７、２９、３２、８２、および９７のそれぞれについて存在する。各タスク・レコード２０６インスタンスに、タスクのＴＡＳＫ  ＩＣＯＮ、ＩＮＳＴＲＵＣＴＩＯＮリスト、ＭＡＰ、およびＳＴＡＴＵＳデータが含まれる。同様に、設備レコード２０４の各ＵＳＥＲ  ＩＤ値によって、ユーザ・レコード２０２の対応するインスタンスがインデクシングされる。ＵＳＥＲ  ＩＤ２８のＷＯＲＫ  ＳＣＨＥＤＵＬＥリストによって、このユーザが、ＴＡＳＫ  ＩＤ値１７、８２、および９７を有するタスクを割り当てられていることが示される。同様に、ＵＳＥＲ  ＩＤ＝３４のＷＯＲＫ  ＳＣＨＥＤＵＬＥリストによって、このユーザが、ＴＡＳＫ  ＩＤ値１２、２９、および３２を有するタスクを割り当てられていることが示される。しかし、ＵＳＥＲ  ＩＤ＝３４のＥＲＲＯＲＣＯＵＮＴ値は３であり、ＩＮＳＴＲＵＣＴフィールドに、イエスのＹがセットされている。これらのフィールドのどちらをも、ユーザ・レコードのＬＡＮＧＵＡＧＥフィールドによって示される言語での、リストされたタスクに関するＩＮＳＴＲＵＣＴＩＯＮからの指示の表示をトリガするのに使用することができる。
【００２４】
図２に戻って、顧客レコード２０８を設けることもでき、これによって、特定の顧客のためにまたは特定の顧客によって管理される設備のすべてに関するデータを維持できるようになる。顧客レコード２０８は、各顧客を識別するＣＵＳＴＯＭＥＲ  ＩＤフィールドによってキーイングされる。ＲＥＧＩＯＮ  ＩＤリストは、顧客の各地域のリストである。各ＲＥＧＩＯＮ  ＩＤリストに、その地域内の各設備のＦＡＣＩＬＩＴＹ  ＩＤが含まれ、顧客レコード２０８内のＦＡＣＩＬＩＴＹ  ＩＤによって、設備レコード２０４のインスタンス内がインデクシングされる。顧客レコード２０８には、顧客レコード・データにアクセスできるユーザを示すＡＣＣＥＳＳリストと、ユーザが顧客レコード・データにアクセスできるレベルを示すＬＥＶＥＬも含めることができる。ＡＣＣＥＳＳリストの各ＵＳＥＲ  ＩＤによって、ユーザ・レコード２０２のインスタンス内がインデクシングされる。たとえば、ユーザが、ユーザ・レコード２０２のインスタンス内で識別されるそのユーザ自身のＷＯＲＫ  ＳＣＨＥＤＵＬＥだけにアクセスするように、ユーザを制限することができる。
【００２５】
図４に、２つの顧客のデータを移植された顧客レコード２０８の例を示す。顧客レコード２０８の１つのインスタンスは、ＣＵＳＴＯＭＥＲ  ＩＤ＝３５５によってインデクシングされる。この顧客は、３つの地域、ＲＥＧＩＯＮ  ＩＤ＝（１１０、１１１、および１１２）を有する。ＲＥＧＩＯＮ  ＩＤ＝１１０によって識別される地域は、ＦＡＣＩＬＩＴＹ  ＩＤ＝（１３１、１３３、および１３４）によって識別される３つの設備を有する。他の地域は、それぞれ同様に３つの設備を有するが、設備の数および地域の数は、顧客の選択に基づいて任意に選択することができる。ＦＡＣＩＬＩＴＹ  ＩＤの各値によって、設備レコード２０４の対応するインスタンスがインデクシングされる。
【００２６】
この顧客のＡＣＣＥＳＳリストによって、この顧客のデータにアクセスできるユーザがリストされる。顧客レコード２０８の各ＵＳＥＲ  ＩＤ値によって、ユーザ・レコード２０２のインスタンスが参照され、ＬＥＶＥＬフィールドの値を介してアクセスのレベルが示されることが好ましい。ここで、ＬＥＶＥＬに、ＵＳＥＲ  ＩＤ＝５６のＲＥＧＩＯＮ  ＩＤ＝１１０に対応する１１０がセットされ、これによって、一実施形態で、そのユーザが、ＲＥＧＩＯＮ  ＩＤ値だけに対応するリスト内のすべての設備レコードからのデータにアクセスできる地域マネージャであることが示される。ＵＳＥＲ  ＩＤ＝８８について、ＬＥＶＥＬに、ＣＵＳＴＯＭＥＲ  ＩＤ＝３５５に対応する３５５がセットされ、これは、そのユーザが、リストされたＣＵＳＴＯＭＥＲ  ＩＤ値だけに関するすべてのデータにアクセスできる上級マネージャであることを意味する。ＵＳＥＲ  ＩＤ＝３４およびＵＳＥＲ  ＩＤ＝２８のＬＥＶＥＬ値に、ＵＳＥＲ  ＩＤと同一の値がセットされ、これによって、これらのユーザが、そのユーザ自身のＷＯＲＫ  ＳＣＨＥＤＵＬＥデータだけにアクセスできることが示される。ＵＳＥＲ  ＩＤ＝３０について、ＬＥＶＥＬに、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１に対応する１３１がセットされ、これによって、このユーザが、対応する設備に関するすべてのデータにアクセスできる設備マネージャであることが示される。これによって、アクセスの階層を異なるユーザに提供することが可能になる。
【００２７】
設備レコードに、各設備の作業スケジュールを生成するポリシの組も含めることができる。データベース１４０に、作業スケジュールの生成に関する異なるポリシを有する複数の設備の設備レコードを保管できることを理解されたい。設備管理サービスを受ける顧客が、国内全体に複数の設備を有する場合に、そのクライアントの設備レコードを、複数の設備階層レベルに従ってデータベース１４０内で配置することができる。設備階層レベルに、全世界設備レベル、国設備レベル、地域設備レベル、支点設備レベル、または位置設備レベルを含めることができる。そのような実施形態で、データベース１４０に保管される各設備レコードを、ユーザ・アクセスを設備レコードの所定の組に制限する所定のアクセス識別子に関連付けることができる。
【００２８】
第１設備１１０に関してデータベース・ユニット１４０に保管される設備情報レコードに、設備位置情報レコード、設備地図レコード、設備記述レコード、または設備安全要件レコードを含めることができる。第１設備１１０に関してデータベース・ユニット１４０に保管される各レコードに、第１設備識別子を用いてマークを付けることができる。そのような実施形態では、第１設備１１０レコードに、所定の都市識別子にマッピングされる第１設備識別子を用いてタグを付けることができる。所定の都市識別子を、所定の地域識別子にマッピングすることができ、この地域識別子が、所定の国識別子にマッピングされ、したがって、木様データベース構造が作成される。
【００２９】
サーバ１３０を、第１設備１１０などの複数の設備での作業を管理するように構成することができる。まず、サーバ１３０によって、第１設備１１０で実行される複数のタスクを含む作業注文要求を受け取る。サーバ１３０は、第１設備１１０に関する作業注文要求を受け取る時に、第１設備識別子にリンクされた作業注文レコードを作成する。
【００３０】
サーバ１３０でタスク・レコードをマークするのに使用されるタスク状況識別子によって、さまざまな状態を示すことができる。一実施形態では、サーバ１３０によって、第１設備１１０に関する作業注文要求の受取時に１つまたは複数のタスク・レコードが作成される時に、サーバ１３０によって、新たに作成されるタグ・レコードのそれぞれに、タスク非スケジューリング済み識別子（ｔａｓｋ  ｕｎｓｃｈｅｄｕｌｅｄ  ｉｄｅｎｔｉｆｉｅｒ）および／またはタスク承認保留識別子（ｔａｓｋ  ｐｅｎｄｉｎｇ  ａｐｐｒｏｖａｌ  ｉｄｅｎｔｉｆｉｅｒ）を用いてタグが付けられる。一実施形態によれば、タスクが、タスク承認保留識別子を用いてタグを付けられる場合に、より上位の階層ユーザが、そのタスクを承認しなければならない。サーバ１３０を構成して、タスク・レコードが作成される設備レコードに基づいて、タスク・レコードにタスク承認保留識別子を用いてタグを付けなければならないかどうかが判定される。たとえば、設備レコードに、どのタスクがサーバ１３０によって自動的に承認されなければならないかを定義する複数のテンプレートを含めることができる。
【００３１】
一実施形態で、サーバ１３０が、データベース１４０に保管された作業注文およびタスク・レコードを監視するように構成される。たとえば、サーバ１３０によって、１つまたは複数の選択されたユーザに関する作業スケジュールが作成されて、承認されたタスクが第１設備１１０で実行される。タスクが、スケジューリングされ、特定のユーザに割り当てられる時に、サーバ１３０によって、タスク・レコード内のタスク識別子が更新される。もう１つの実施形態では、タスクがスケジューリングされる時に、サーバ１３０によって、タスク非スケジューリング済み識別子がタスク・スケジューリング済み識別子（ｔａｓｋ  ｓｃｈｅｄｕｌｅｄ  ｉｄｅｎｔｉｆｉｅｒ）に更新される。
【００３２】
一実施形態では、サーバ１３０によって、第１設備１１０でＥＭＩ１１２を使用するユーザから作業スケジュール要求が受け取られる時に、プロセッサ１６０によって、そのユーザに関してスケジューリングされたタスクのタスク・アイコンと共に、要求された作業スケジュールがデータベース１４０から検索され、したがって、アイコンベースのスケジュールが作成され、これが、その後、第１設備１１０のＥＭＩ１１２に送られる。もう１つの実施形態では、タスク・アイコンを、ＥＭＩ１１２側のデータベース１５４に事前に保管することができる。
【００３３】
データベース１４０に、各タスクを実行するための基本的な指示を有するタスクトレーニング・レコードを含めることができる。一実施形態で、作業スケジュールが、第１設備１１０から要求される時に、中央処理装置１６０によって、要求された作業スケジュールおよびそのスケジュールで指定される各タスクのタスクトレーニング・レコードが、データベース１４０から検索され、第１設備１１０に送られる。第１設備１１０側のユーザが、作業スケジュールを要求する時に、サーバ１３０によって、要求された作業スケジュールおよび送られるスケジュールで指定される各タスクのタスクトレーニング・レコードが、ＥＭＩ１１２に送られる。
【００３４】
ＥＭＩ１１２を、データベース１４０に保管されたデータにアクセスするためにサーバ１３０と通信するほかに、データベース１５４からのデータにローカルにアクセスするように構成することができる。図５は、ＥＭＩ１１２で使用することができるソフトウェア・アーキテクチャ２１０の実施形態を示す単純化された図である。アーキテクチャ２１０には、ＥＭＩ１１２の動作を制御するオペレーティング・システム２１２が含まれる。ユーザは、ユーザ・インターフェース・モジュール１５２を介してデータを入力し、ユーザ・インターフェース・モジュール１５２は、ユーザ入力を受け取り、処理し、オペレーティング・システム２１２に供給する。
【００３５】
オペレーティング・システム２１２によって、ＥＭＩ１１２によって表示できる異なるグラフィカル・ユーザ・インターフェース・ビューに対応する、データベース１５４内の、図２に示されたテンプレート２１０などの複数のテンプレート・ファイルにアクセスすることができる。オペレーティング・システム２１２によって、言語選択画面のテンプレートまたは図９に示された画面などのユーザ識別番号入力画面のテンプレートを検索することができる。オペレーティング・システム２１２によって、たとえば言語選択またはユーザＩＤ入力など、処理のステージに適当なテンプレートが検索され、そのテンプレートが、処理のためにサーバ・プロセス２１６に渡される。各テンプレート・ファイルに、グラフィカル・データおよびテキスト・データならびにビューをレンダリングするためのフォーマッティング記述子が含まれる。さらに、各テンプレート・ファイルに、ユーザ・ビューを移植するのに必要なデータに、ローカル・データベース１５４内でまたはデータベース１４０からアクセスするためのリンクを提供するリソース・ファイル識別子が含まれる。
【００３６】
サーバ・プロセス２１６によって、まず、テンプレートを移植するのに必要なデータが、ローカルにデータベース１５４に保管されているかどうかが判定される。しかし、サーバ・プロセス２１６によって、要求されたデータがデータベース１５４にローカルに保管されていないと判定される場合に、サーバ・プロセス２１６によって、サーバ１３０を介してリモート・データベース１４０からデータを検索するようにオペレーティング・システム２１２に指示することができる。オペレーティング・システム２１２によって、通信インターフェース１５８を介してサーバ１３０との通信セッションを確立することができる。テンプレートに必要なすべてのデータが入手されたならば、検索されたデータを有するテンプレートが、ＥＭＩ１１２を介するユーザへの表示のためにレンダリングされる。たとえば、ユーザが、図９に示された画面を使用してＵＳＥＲ  ＩＤ＝２８を入力することに応答して、オペレーティング・システム２１２によって、図１０に示されたビューなど、ＵＳＥＲ  ＩＤ＝２８と共にサーバ・プロセス２１６に渡される、作業スケジュール・ビューに対応するテンプレートがローカル・データベース１５４から検索される。作業ビューのテンプレートには、サーバ・プロセス２１６に、ＵＳＥＲ  ＩＤ＝２８によってキーイングされるユーザ・レコード・インスタンスをローカル・データベース１５４から検索させたユーザ・レコードのファイル識別子が含まれる。ユーザ・レコードが検索される時に、サーバ・プロセス２１６によってユーザ・レコードが検索されて、存在するＴＡＳＫ  ＩＤ値が判定される。次に、サーバ・プロセス２１６によって、ユーザ・レコード・インスタンスからのＴＡＳＫ  ＩＤ値の一部またはすべてに関するタスク・レコード２０６についてローカル・データベース１５４が検索される。タスク・レコードが検索されたならば、ビューが、ユーザ・インターフェース１５２を介する出力のためにサーバ・プロセス２１６によってレンダリングされて、図１０の例がもたらされる。データをローカル・データベースに保管するために、オペレーティング・システム２１２によって、サーバ１３０からデータを受信する時にサーバ・プロセス２１６を実行することができ、その結果、サーバ・プロセス２１６によって、サーバ１３０から受信したレコードを解析し、ローカル・データベース１５４に保管することができるようになる。
【００３７】
ソフトウェア・アーキテクチャ２１０は、Ｅｘｔｅｎｄｅｄ  Ｍａｒｋｕｐ  Ｍｅｃｈａｎｉｓｍ（ＸＭＬ）を使用して、データをデータベース１５４に保管し、データベース１５４に保管されたデータを管理するように構成することができる。ＸＭＬは、国際標準化機構（ＩＳＯ）標準規格８８７９（１９８６年）によって定義された標準汎用印刷指定言語（ＳＧＭＬ）の制限付きの形態であり、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）によって定義されている。ハイパーテキスト・マークアップ言語（ＨＴＭＬ）が、やはり使用することができるＳＧＭＬのもう１つの派生形である。代替案では、ソフトウェア・アーキテクチャ２１０を、Ｊａｖａ（登録商標）実行可能命令を実行してデータベース１５４にデータを移植しデータベース１５４にローカルに保管されたデータを管理するように構成することができる。
【００３８】
ＥＭＩ１１２に、いくつかのユーザ・データをローカルに保管することができる。アーキテクチャ２１０で実行される処理を示すために、ユーザによる作業スケジュール要求に使用されるメッセージの交換２２０の例を、図６および７に示す。図６に、あるユーザの作業スケジュールがデータベース１５４に事前に保管される、メッセージおよびデータの交換の例の１つを示す。図６の例では、ＵＳＥＲ  ＩＤ＝２８について以前にダウンロードされた、ＴＡＳＫ  ＩＤ＝１７、ＴＡＳＫ  ＩＤ＝８２、およびＴＡＳＫ  ＩＤ＝９２のタスク・レコードが、データベース１５４でローカルに使用可能である。サーバ・プロセス２１６によって、ファイルで受け取られたステートメントまたは情報のそれぞれを識別し、テンプレートに組み込まなければならない他のデータ・オブジェクトまたはファイルへの参照を解決することによって、テンプレートが処理される。ＵＳＥＲ  ＩＤ＝２８のユーザ・レコードに示されたＴＡＳＫ  ＩＤに基づいて、サーバ・プロセス２１６によって、メッセージ２３２および２３４に示されているように、ＴＡＳＫ  ＩＤ１７、８２、および９２を使用して、データベース１５４からタスク・レコードが検索される。この例のこの点で、ＵＳＥＲ  ＩＤ＝２８の作業スケジュール・テンプレートに関するデータ参照が、解決され、テンプレートが完全に移植される。次に、サーバ・プロセス２１６によって、グラフィカル・ディレクティブがレンダリングされ、符号２３６に示されているように、それがオペレーティング・システム２１２に渡される。代替案では、サーバ・プロセス２１６によって、移植されたテンプレートを、レンダリングのために別々のブラウザ・アプリケーションに渡すことができる。また、サーバ・プロセス２１６は、ユーザ・レコードまたはタスク・レコードの一方または両方を、サーバ１３０を介してリモート・データベース１４０から入手することができる。サーバ１３０からのユーザ・レコードの受取の例を、図６に示す。ユーザ・レコードに関する照会２２９をデータベース１５４に送る代わりに、または、データベース１５４の照会に失敗する場合に、サーバ・プロセス２１６は、通信インターフェース１５８を介してサーバ１３０に照会２４０を送る。
【００３９】
図７は、作業スケジュールがサーバ１３０のデータベース１４０にリモートに保管される場合の、ユーザによる作業スケジュールの要求に含まれるメッセージの交換２５０の例である。図７では、ユーザ・インターフェース１５２によって、ＵＳＥＲ  ＩＤ＝２８などのユーザ認証データを含むユーザ入力２５２が受け取られる。ユーザ・インターフェース１５２によって、メッセージ２５４で示されるように、ＵＳＥＲ  ＩＤ＝２８がオペレーティング・システム２１２に供給される。サーバ・プロセス２１６によって、メッセージ２５６で示されるように、オペレーティング・システム２１２を介して、ＵＳＥＲ  ＩＤ＝２８が、ユーザ作業スケジュール・テンプレートと共に受け取られる。これに応答して、サーバ・プロセス２１６によって、２５８で表されるように、ＵＳＥＲ  ＩＤ＝２８に関するユーザ・レコードがローカル・データベースから検索される。図７の例によれば、ローカル・データベース１５４には、ＵＳＥＲ  ＩＤ＝２８に関連するユーザ・レコードが含まれず、したがって、サーバ・プロセス２１６にＦＡＩＬ（失敗）メッセージ２６０が返される。それに応答して、この実施形態では、サーバ・プロセス２１６によって、ユーザの作業スケジュールをサーバ１３０から検索しなければならないことを示す、ＵＳＥＲ  ＩＤ＝２８を含むメッセージ２６２がオペレーティング・システムに送られる。オペレーティング・システム２１２は、メッセージ２６２を受け取る時に、ストレージ１５６から設備識別子（ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１）を検索し、通信インターフェース１５８を介するサーバ１３０との通信リンクを確立する。オペレーティング・システム２１２によって、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１およびＵＳＥＲ  ＩＤ＝２８を含む第１メッセージＭ１  ２６４が、通信インターフェース１５８を介してサーバ１３０に送られる。
【００４０】
サーバ１３０によって、第１メッセージ２６６が受け取られる時に、サーバ１３０によって、ＵＳＥＲ  ＩＤ＝２８に関連するユーザ・レコードが、データベース１４０から検索される。上で図３に関して説明したように、ＵＳＥＲ  ＩＤ＝２８のユーザ・レコードに、そのユーザがＴＡＳＫ  ＩＤ値１７、８２、および９２を有するタスクを割り当てられていることを示す作業スケジュールが含まれる。さらに、このユーザ・レコードから、そのユーザに英語で指示を与えなければならないことと、そのユーザに、各タスクに関連する指示レコードを与えなければならないことが示される。結果の作業スケジュール・ビューは、図１０に似たものになる。
【００４１】
図１０に関して、作業スケジュール・ビューで識別されるタスクを完了したユーザ、または監督ユーザは、タスクの状況を更新することができる。図８は、タスクに関するタスク・レコードの更新のための、ＥＭＩ１１２とサーバ１３０の間のメッセージ交換２７０の例を示すメッセージ・フロー図である。
【００４２】
最初に、ＥＭＩ１１２によって、ＵＳＥＲ  ＩＤ＝２８などのユーザ認証データを含むユーザ入力２７２が、第１ユーザから受け取られる。その後、ＥＭＩ１１２によって、第１作業スケジュール要求を含む第１メッセージ（Ｍ１）２７４が、生成され、サーバ１３０に送られる。メッセージ２７４に、ユーザ識別子（ＵＳＥＲ  ＩＤ＝２８）および設備識別子（ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１）を含めることができる。サーバ１３０によってメッセージ２７４が受け取られる時に、サーバ１３０によって、２７６に示されているように、ＵＳＥＲ  ＩＤ＝２８に関連するユーザの作業スケジュールが、データベース１４０から検索される。サーバ１３０によって、ＥＭＩ１１２に作業スケジュールを供給する前に、ユーザを認証することができる。その代わりに、ＥＭＩ１１２によって、メッセージをサーバ１３０に送る前に、ローカル・データベース１５４に保管された認証データを使用して、ユーザを認証することができる。図３および８に示された例によれば、ユーザ・レコード２０２に、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１に関連する設備でユーザによって実行されるタスクに関連する複数のタスク識別子（１７、８２、９２）が含まれる。サーバ１３０は、ユーザの作業スケジュールで指定されたタスク識別子に基づいて、タスク・アイコンおよびタスク指示を含むタスク・レコード２０６をデータベース１３０から検索する。その後、サーバ１３０によって、第１ユーザの作業スケジュールを含む第２メッセージ（Ｍ２）２７８が生成され、ＥＭＩ１１２に送られる。第２メッセージ２７６には、この実施形態では、タスク１７、８２、および９２のタスク・アイコンならびにタスク指示が含まれる。ＥＭＩ１１２によって第２メッセージ２７８が受け取られる時に、ＥＭＩ１１２によって、２８０に示されているように、第１ユーザに作業スケジュールが表示される。
【００４３】
ユーザは、ユーザの作業スケジュールの各タスクの状況を更新することができる。第１ユーザによる後続ログイン・セッションを開始するために、ＥＭＩ１１２によって、第１ユーザから第２ユーザ入力２８２が受け取られる。このユーザ入力には、第１ユーザの認証データ（ＵＳＥＲ  ＩＤ＝２８）が含まれる。ＥＭＩ１１２によって、第１ユーザから第２入力２８２が受け取られる時に、ＥＭＩ１１２によって、タスク状況更新要求を含む第３メッセージ（Ｍ３）２８４が生成され、サーバ１３０に送られる。第３メッセージ２８４には、ユーザ認証データ（ＵＳＥＲ  ＩＤ＝２８）および設備識別子（ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１）が含まれる。サーバ１３０によってメッセージ２８４が受け取られる時に、サーバ１３０によって、ＵＳＥＲ  ＩＤ＝２８のユーザ・レコードによって示されるユーザの作業スケジュールのタスク・レコードが、データベース１４０から検索される。ユーザ・レコードからのタスク識別子を使用して、サーバ１３０によって、各タスクのタスク・アイコンならびにタスク更新アイコンがアクセスされるが、タスク更新アイコンについては下で詳細に説明する。
【００４４】
その後、サーバ１３０によって、タスク状況更新応答を含む第４メッセージ（Ｍ４）２８８が生成され、送られる。第４メッセージ２８８には、ユーザ作業スケジュールで指定された各タスクのタスク更新アイコンが含まれる。ＥＭＩ１１２によって、第４メッセージ２８８が受け取られる時に、ＥＭＩ１１２によって、２９０に示されているように、タスク更新アイコンがユーザに表示される。図１３に、タスク状況更新アイコンと共にユーザに表示することができる、タスク状況ビュー画面の例を示す。第１ユーザは、たとえば各タスクの完了状況に基づいて、ユーザに割り当てられた各タスクの状況を更新することができる。ＥＭＩ１１２によって、２９２に示されているように、ユーザからタスク状況更新入力が受け取られる。第１ユーザが、タスク状況更新を完了した時に、ＥＭＩ１１２によって、タスク状況更新要求メッセージを含む第５メッセージ（Ｍ５）２９４が生成され、サーバ１３０に送られる。第５メッセージ２９４には、ユーザの識別データ（ＵＳＥＲ  ＩＤ＝２８）、設備識別子（ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１）、およびタスク状況更新入力２９２を介して受け取られたタスク更新データが含まれる。サーバ１３０によって第５メッセージ２９４が受け取られる時に、サーバ１３０によって、２９６に示されているように、第５メッセージ２９４で指定された各タスクの状況が更新される。タスク・レコードの更新の処理は、下で詳細に説明する。代替案では、ユーザが、作業スケジュールを得るために固定位置のＥＭＩ１１２を使用してシステムのサーバ１３０にログ・インすることができるが、作業スケジュールおよび指示は、ユーザによる使用のためにポータブル・デバイスにダウンロードされる。ユーザは、ポータブル・デバイスと固定位置のＥＭＩ１１２を同期化し、固定位置のＥＭＩ１１２は、ＵＳＥＲ  ＩＤおよび更新された状況データをポータブル・デバイスから受け取り、上で説明した形で更新された状況データを送信する。
【００４５】
さらに、図８に示されているように、ＥＭＩ１１２によって、第２ユーザからユーザ入力２９８を受け取ることができる。第２ユーザに、図１４に示されたものなどのログイン画面を提示することができる。ユーザ入力２９８に、ＵＳＥＲ  ＩＤ＝３０などのユーザの識別データを含めることができる。ＥＭＩ１１２によってユーザの識別データが受け取られる時に、ＥＭＩ１１２によって、ＵＳＥＲ  ＩＤ＝３０および設備識別子ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１を含む第６メッセージ（Ｍ６）３００が生成され、サーバ１３０に送られる。サーバ１３０によって第６メッセージ３００が受け取られる時に、サーバ１３０によって、３０２に示されているように、ＵＳＥＲ  ＩＤ＝３０に関連するユーザの作業スケジュールが、データベース１４０から検索される。
【００４６】
図４の例によれば、ＵＳＥＲ  ＩＤ＝３０を有するユーザは、ＵＳＥＲ  ＩＤ＝２８を有する第１ユーザによって実行されるタスクを含む、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１に対応する設備のタスクを監督する監督ユーザである。図４の顧客レコードに基づいて、サーバ１３０によって、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１のすべてのタスクに関するタスク状況レポートを含む第７メッセージ（Ｍ７）３０４が生成され、ＥＭＩ１１２に送られる。タスク状況レポートに、検査タスクなどの、第２ユーザまたは監督ユーザによる完了についてスケジューリングされたタスクを含めることができる。タスクの状況の変更に関するアイコンを含む画面ビューの例については、図１８を参照されたい。
【００４７】
ＥＭＩ１１２によって第７メッセージ３０４が受け取られる時に、ＥＭＩ１１２によって、監督ユーザにタスク・アイコンが表示される。監督ユーザは、タスク・アイコンを使用して、ＥＭＩ１１２に表示される各タスクの状況を変更することができる。ユーザ入力３０８に示されているように、ＥＭＩ１１２によってユーザの入力が受け取られる時に、ＥＭＩ１１２によって、監督ユーザから受け取られたタスク状況更新データを含む第８メッセージ（Ｍ８）３１０が生成される。サーバ１３０によってＥＭＩ１１２から第８メッセージ３１０が受け取られる時に、サーバ１３０によって、ＥＭＩ１１２から受け取られたタスク状況更新データに基づいて、タスクの状況が更新される。第８メッセージは、図１８に示された状況入力ボックスなどの状況入力ボックスを第２ユーザが選択する時に送られるＣＧＩスクリプトの形とすることができる。
【００４８】
図９に、ＥＭＩ１１２でユーザに表示できるログイン・ダイアログ・ボックス４００を示す。「Ｃｈｅｃｋ−Ｉｎ（チェック−イン）」選択アイコン４０２を選択すると、サーバ１３０によって、ＥＭＩ１１２にアイコンベースのスケジュールを送り、ユーザにアイコンベースのスケジュールを表示することによる、ユーザ認証の処理が開始される。ユーザが、タッチ・スクリーン１１２を介して、ユーザ識別コードを入力し、「Ｃｈｅｃｋ−Ｉｎ」アイコン４０２を選択する時に、ユーザが認証される。ＥＭＩ１１２によって、ユーザ識別コードがサーバ１３０に送られ、サーバ１３０を、ユーザを認証するように構成することができる。代替案では、ＥＭＩ１１２に、カード・リーダが含まれ、ユーザが、ユーザの識別カードをカード・リーダに通すことによって、ログインを開始することができる。同様に、音声認識またはビデオ認識を、ログインおよび認証処理に統合することができる。ＥＭＩ１１２によって、ＥＭＩの位置を識別する値（たとえば、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１）を送って、ユーザの位置をサーバ１３０に伝えることもできる。サーバ１３０によってユーザが成功裡に認証される場合に、サーバ１３０によって、作業スケジュールを有するユーザ・レコード２０２が、データベース１４０から検索される。サーバ１３０では、ＵＳＥＲ  ＩＤまたはＵＳＥＲ  ＩＤおよびＦＡＣＩＬＩＴＹ  ＩＤのいずれかを使用して、そのユーザの作業スケジュールを検索することができる。その後、サーバ１３０によって、スケジュールがＥＭＩ１１２に送られ、そのスケジュールが、ＥＭＩ１１２を介してユーザに表示される。
【００４９】
図１０は、認証されたユーザにＥＭＩ１１２上で表示できる、アイコンベースのスケジュールを示す例示的な表示ページおよびダイアログ・ボックス５００である。各タスク・アイコンに、タスクのグラフィカル表現、タスクの短い文による記述、またはその両方を含めることができる。タスク位置アイコンによって、サーバ１３０から、タッチ・スクリーン１１２を介してユーザに表示される位置レコードが呼び出される。ＥＭＩ１１２に、内蔵プリンタまたはスタンバイ・プリンタが含まれる場合に、ダイアログ・ボックス５００に、ユーザが自分の作業スケジュールを印刷できるようにする「Ｐｒｉｎｔ（印刷）」アイコンを含めることができる。
【００５０】
図１１に、例示的な位置地図６０２を示すダイアログ・ボックス６００を示す。図１０に戻ると、ダイアログ・ボックス６００は、ユーザがタスク位置アイコン５１６を選択する際にＥＭＩ１１２に表示することができる。タスク位置アイコン５１６を選択することによって、そのタスクに対応するタスク・レコードが、ローカル・データベース１５４またはリモート・データベース１４０のいずれかでアクセスされる。図２および３に示されたタスク・レコード２０６に、地図または説明情報のいずれかを含むＭＡＰフィールドが含まれる。
【００５１】
図１０に戻って、ユーザが「Ｈｅｌｐ（ヘルプ）」アイコンを選択する時に、タスク指示レコードが、ＥＭＩ１１２に表示される。図１２は、例示的なタスク指示レコードを示す表示ページ７００の例である。図１０に戻ると、ユーザは、自分の作業スケジュールを見た後で、「Ｇｏｏｄｂｙｅ（さようなら）」アイコン５２８を選択することができ、これによって、ユーザがシステムから自動的にログ・アウトされる。
【００５２】
一実施形態によれば、ユーザは、ＥＭＩ１１２を介して、ユーザのスケジュールの各タスクの状況を更新する。それを行うために、ユーザは、まず、図９に関して説明したようにＥＭＩ１１２にアクセスすることができる。図９に戻って、タスク状況を更新するために、ユーザは、「Ｃｈｅｃｋ−Ｏｕｔ（チェック−アウト）」アイコン４０４を選択することができ、これによって、ＥＭＩ１１２でのダイアログ・ボックスを有するタスク状況ページの表示をトリガすることができる。図１３に、例示的なタスク状況更新状況ページ８００を示す。各タスクの２つの状況アイコンに、アイコン８０４、８１０、８１６、および８２２などの「Ｄｏｎｅ（終了）」状況アイコンと、アイコン８０６、８１２、８１８、および８２４などの「Ｎｏｔ  Ｄｏｎｅ（未了）」状況アイコンが含まれる。状況アイコンによって、各タスクの現在の状況を反映することができ、ユーザが、タスク・アイコン８０２の「Ｄｏｎｅ」アイコン８０４を選択するなど、各タスクの異なる状況に対応する状況アイコンを選択することによって状況を変更できるようになる。一実施形態では、ユーザが、各タスクの状況を更新する時に、ＥＭＩ１１２によって、ＣＧＩスクリプトなど、ユーザによって更新される各タスクのタスク完了データを含むタスク更新メッセージが生成される。次に、ＥＭＩ１１２によって、タスク更新メッセージがサーバ１３０に送られ、サーバ１３０によって、タスク更新メッセージで受け取られたタスク完了データに基づいて、リモート・データベース１４０内でユーザの作業スケジュールの各タスクの状況が更新される。
【００５３】
さらに、システム１００によって、監督ユーザがサーバ１３０に作業状況レポートを要求できるようにすることができる。監督ユーザは、図９に関して説明したように、ＥＭＩ１１２を介してログインすることができる。サーバ１３０によってユーザが監督ユーザとして認証されたならば、サーバ１３０によって、監督ユーザのために生成された作業スケジュールならびにその監督ユーザによって管理されるクルー・ユーザの作業スケジュールが送られる。監督ユーザは、ＥＭＩ１１２で作業スケジュールを見ることができる。自分の作業スケジュールを見るほかに、監督ユーザは、その監督ユーザの下で働くユーザの作業状況レポートをサーバ１３０に要求することができる。一実施形態では、監督ユーザに、自分の識別名を入力するために図１４の入力ページ９００を提示することができる。ログイン情報は、ＥＭＩ１１２によって受け取られ、サーバ１３０に送られる。図１５に示された、監督または管理ディスプレイおよびダイアログ・ぺージ１０００を、ＥＭＩ１１２で監督ユーザに提示することができる。監督ユーザは、図１６に示されたページに類似する表示ページを介して、作業状況レポートを見る。
【００５４】
監督ユーザは、状況レポートの各タスクの状況を「Ｄｏｎｅ」から「Ｎｏｔ  Ｄｏｎｅ」に変更することができ、これは、タスク承認の不承認または拒否を構成し、逆も同様である。タスク状況の変更の検出に応答して、ＥＭＩ１１２は、選択されたタスクの変更された状況を、サーバ１３０に送られるタスク更新メッセージに組み込むように構成される。サーバ１３０によって、ＥＭＩ１１２からのタスク更新メッセージが受け取られる時に、サーバ１３０によって、ＥＭＩ１１２から受け取った変更された状況データに基づいて、データベース１４０のタスクのそれぞれの状況が更新される。一実施形態によれば、サーバ１３０によって、第１設備１１０について生成された作業スケジュール・データおよびＥＭＩ１１２から受け取られるタスク更新メッセージを使用して、第１設備１１０でのタスク完了が追跡され、更新される。これは、図１７の例のデータに反映される。
【００５５】
上で注記したように、ユーザが、自分の識別番号を使用してログ・インする時に、サーバ１３０によって、図２および４に示された顧客レコード２０８に関連するデータの階層への、そのユーザのアクセスのレベルを判定することができる。ユーザの階層レベルに基づいて、ユーザに、設備レコードの所定の組へのアクセス権が与えられる。たとえば、ディスプレイ・アクセス・ボックス１００２によって、図４の顧客レコード・データに基づく顧客の設備の階層が反映される。顧客レコードのＡＣＣＥＳＳデータ構造によって、その顧客のデータにアクセスできるユーザのＵＳＥＲ  ＩＤ値が示される。ＬＥＶＥＬフィールドによって、対応するユーザに許可されるアクセスのレベルが示される。
【００５６】
図４の例では、ＵＳＥＲ  ＩＤ＝３０が、ＬＥＶＥＬ＝１３１に関連する。したがって、サーバ１３０によって、ＵＳＥＲ  ＩＤ＝３０のユーザがＦＡＣＩＬＩＴＹ  ＩＤ＝１３１を有する設備に関するデータへのアクセスを有することが許可され、これには、その設備の設備レコード２０４で示される作業スケジュールが含まれる。しかし、ＵＳＥＲ  ＩＤ＝３０のユーザは、データ階層の同一レベルにある他のエンティティ、たとえば他の設備に関するデータ、または階層の上位のエンティティ、たとえば地域全体または顧客全体のデータへのアクセスを制限される。この例を続けると、ＵＳＥＲ  ＩＤ＝５６はＬＥＶＥＬ＝１１０に関連し、これは、ＲＥＧＩＯＮ  ＩＤ＝１１０に対応する。したがって、サーバ１３０によって、ＵＳＥＲ  ＩＤ＝５６のユーザが、ＲＥＧＩＯＮ  ＩＤ＝１１０に対応する地域のデータへのアクセスを有することが許可され、これには、ＦＡＣＩＬＩＴＹ  ＩＤ値１３１、１３３、および１３４が含まれるが、このユーザは、ＲＥＧＩＯＮ  ＩＤ＝１１１または１１２などの他の地域に関するデータおよび顧客全体のデータへのアクセスは許可されない。同様に、ＵＳＥＲ  ＩＤ＝８８は、ＬＥＶＥＬ＝３５５に関連し、これは、ＣＵＳＴＯＭＥＲ  ＩＤ＝３５５に対応し、これによって、このユーザが、その顧客のすべてのデータにアクセスすることを許可されるが、他の顧客のデータへのアクセスは許可されない。データの階層は、図１５のディスプレイ・ボックス１００２に示されており、ここで、さまざまなレベルのアクセス権を有するユーザに、階層全体を見ることを許可することができ、あるいは、階層のうちでアクセス権を有する部分だけを見られるように制限することができる。この特徴の態様の１つでは、サーバ１３０によって複数の顧客をサポートできるようにしながら、各顧客のデータのセキュリティが維持される。図１６に、設備レベル・アクセスを有するユーザの例示的な作業カレンダ１１００を示す。
【００５７】
検査アイコン１００８が選択された時に、検査データ入力レコードなどの検査レコードが呼び出される。図１８は、検査レコードを示す例示的なダイアログ・ボックス１２５０である。検査レコードによって、設備に関してスケジューリングされた各タスクのタスク／作業注文検査情報が示される。図１８からわかるように、このダイアログ・ボックスには、所定のタスクまたはタスクのグループに対して検査が実行されたかどうかの情報、ならびに合格または失格などの検査状況およびコメントが含まれる。コメントは、図１８に示された「ｃｏｍｍｅｎｔｓ」アイコンを選択することによってアクセスすることができる。検査レコードを、統計的な基礎で検査のために選択することができる。
【００５８】
さらに、一実施形態によれば、設備の運用を最適化するようにサーバ１３０を構成することができる。サーバ１３０によって、サーバ１３０によって管理される１つまたは複数の設備を有する顧客に、予防的保守サービスを提供することができる。一実施形態では、予防的保守に、問題が発生する前にその問題の位置を正確に指摘するための設備の定期的検査をスケジューリングすることができる。たとえば、管理サーバサーバ１３０によって、予期されない故障を防ぐために、計画された基礎で修理を行うスケジュールを立てることができる。
【００５９】
図１９は、本発明の一実施形態による、中央管理サーバから第１設備に配置されたクライアント・デバイスへの作業スケジュールの供給の例示的な方法１３００を示す流れ図である。方法１３００を、図１に示されたネットワーク・アーキテクチャ１００に関して説明する。しかし、例示的な方法１３００は、図１に示されたデバイスに制限されず、より多数、より少数、異なる、または同等のデバイスを使用して実施することができる。
【００６０】
図１９を参照すると、ステップ１３０２で、サーバ１３０によって、第１設備１１０で実行される、スケジューリングされるタスクを定義する情報の第１組を受け取る。監督ユーザなどのユーザが、サーバ１３０に関連するウェブ・ページにアクセスすることによって、情報の第１組を含む作業注文を行うことができる。代替案では、ユーザが、コール・センタで作業注文を行うことができる。その後、コール・センタのスタッフ・メンバが、サーバ１３０にアクセスして、図１５に関して示したものなどのウェブベース・インターフェースを使用して作業注文要求を行うことができる。本発明を、設備に関する電子作業チケットを生成する外部アプリケーション・システムにもリンクすることができ、この電子作業チケットは、方法１３００による割り当ておよび分配のためにサーバ１３０に入力される。
【００６１】
サーバ１３０に、所定のスケジュールに従って、または設備に対応する顧客または地域に関する作業ルールの組に従って、タスクを生成する処理を含めることもできる。作業スケジュールの生成に使用される作業ルールは、各顧客、地域、または設備に合わせてカスタマイズすることができる。エキスパート・システムによって供給されるものなどの作業ルールを使用して、顧客設備に関する有効な作業スケジュール・プロファイルを提供することができる。サーバ１３０によって、ステップ１３０２で、所与の日付に各設備について実行されるタスクを判定し、設備で実行されるタスクのそれぞれのＴＡＳＫ  ＩＤを含めるために、各設備の、図２および３に示された設備レコード２０４を更新することができる。サーバ１３０は、実行されるタスクごとにタスク・レコード２０６を生成することもできる。ステップ１３０４で、サーバ１３０によって、第１設備１１０でスケジューリングされた第１作業を実行するために選択された第１ユーザの第１作業スケジュールを生成する。サーバ１３０によって、第１ユーザのタスクの組を選択することができる。その後、サーバによって、タスクの組のそれぞれにＴＡＳＫ  ＩＤを含めるために、第１ユーザのユーザ・レコード２０２を更新する。サーバによって、タスクを完了するために選択されたユーザのＵＳＥＲ  ＩＤと設備レコードのＴＡＳＫ  ＩＤを関連付けるために、設備の設備レコード２０４も更新される。
【００６２】
第１ユーザの第１作業スケジュールを生成する前に、サーバ１３０によって、所定の階層レベルに関連する設備ユーザによる承認のために、第１設備で実行されるタスクのリストを生成することができる。設備ユーザが、第１設備１１０で実行されるタスクの一部またはすべてを承認する時に、サーバ１３０によって、第１ユーザの第１スケジュールが生成される。したがって、上位ユーザが、設備およびこれらの設備でタスクを実行するユーザの作業スケジュールを制御し、配布することができる。
【００６３】
ステップ１３０６で、サーバ１３０によって、第１設備１１０のクライアント・デバイスから第１ユーザに関する作業スケジュール要求を受け取る。このクライアント・デバイスは、ＥＭＩ１１２とすることができる。さらに、作業スケジュール要求に、上で説明したように、ユーザ識別子などのユーザ識別データおよびＥＭＩ対識別子、たとえばＦＡＣＩＬＩＴＹ  ＩＤが含まれる。ユーザのユーザ・レコードで割り当てられた作業スケジュールを、ユーザへの表示のためにクライアント・デバイスに送ることができ、あるいは、ステップ１３０４で生成された作業スケジュールを、ユーザ・ログインによってトリガすることができる。ステップ１３０８で、サーバ１３０によって、第１ユーザが認証される。ユーザが、作業スケジュールの要求を許可されるかどうか判定するほかに、サーバ１３０によって、ユーザがそこから作業スケジュールを要求した設備位置へのアクセスをユーザに与えなければならないかどうかを判定することができる。ステップ１３１０で、サーバ１３０によって、第１ユーザが成功裡に認証されたかどうかを判定する。ユーザの認証に成功した場合には、ステップ１３１２で、サーバ１３０によって、第１作業スケジュールが第１設備１１０のクライアント・デバイス（ＥＭＩ１１２）に送られる。ステップ１３０８に関して説明したように、第１ユーザが、異なる設備でタスクを実行するようにスケジューリングされている場合には、第１設備に送られる第１作業スケジュールを、第１設備１１０で第１ユーザによって実行されるようにスケジューリングされたタスクを含む部分的な作業スケジュールとすることができる。
【００６４】
ステップ１３０４、１３０８、または１３１２のいずれかで、サーバ１３０に、ＭＥＳＳＡＧＥテキスト・フィールドにユーザへの出力に関するメッセージが移植されるかどうかと、ユーザが、割り当てられたタスクの完了のために関連する指示を受け取らなければならないかどうかを判定するために、そのユーザのユーザ・レコード２０２を検査することも含めることができる。たとえば、監督ユーザによって、ユーザ・レコードのＩＮＳＴＲＵＣＴフィールドにｙｅｓをセットすることができ、これによって、各タスクの指示が、ＥＭＩ１１２のユーザのために生成される。代替案で、ＥＲＲＯＲＣＯＵＮＴフィールドを検査することができ、ＥＲＲＯＲＣＯＵＮＴの値が所定の閾値より大きい場合に、指示がユーザに出力される。ＭＥＳＳＡＧＥまたは指示データは、作業スケジュールと共に第１設備のクライアント・デバイスに送ることができる。
【００６５】
図２０は、クライアント・デバイスでの作業スケジュールの要求および受取の方法１４００を示す流れ図である。ステップ１４０２で、ＥＭＩ１１２などのクライアント・デバイスによって、サーバ１３０などの中央管理サーバとの通信リンクを確立する。ステップ１４０４で、ＥＭＩ１１２によって、ユーザからＵＳＥＲ  ＩＤ番号などの認証データを受け取る。一実施形態では、図９に関して示したように、ユーザが、ＥＭＩ１１２のタッチスクリーン・インターフェースを介して識別番号を入力することができる。代替案では、ＥＭＩ１１２に、カード・リーダ、音声認識デバイス、キーパッド、ペン・ベースの入力デバイス、またはユーザから認証データを受け取る他の手段を含めることができる。
【００６６】
ステップ１４０６で、クライアント・デバイスによって、作業スケジュール要求が中央管理サーバに送られる。図１に示された実施形態では、ＥＭＩ１１２によって、サーバ１３０に要求が送られ、作業要求に、ＥＭＩ識別子（ＦＡＣＩＬＩＴＹ  ＩＤに付加されたユーザの認証データ（ＵＳＥＲ  ＩＤ）が含まれる。ステップ１４０８で、ＥＭＩ１１２によって、サーバ１３０から第１作業スケジュールが受け取られる。一実施形態によれば、作業スケジュールに、第１ユーザによって第１設備１１０で実行される作業スケジュールの少なくとも１つのタスクを示すアイコンベースのグラフィカル・ユーザ・インターフェースが含まれる。ステップ１４１０で、ＥＭＩ１１２によって、第１ユーザに作業スケジュールのアイコンが表示され、方法１４００が終了する。
【００６７】
図２１は、サーバ１３０などの中央管理サーバでのタスク状況レコードの管理の方法１５００を示す流れ図である。ステップ１５０２で、サーバ１３０によって、ＥＭＩ１１２などのクライアント・デバイスから、第１ユーザに関連する第１作業スケジュールに対応する第１タスク状況更新メッセージを受け取る。図２０に関して述べた方法と同様に、第１ユーザは、自分の識別データを入力することによってＥＭＩ１１２にアクセスすることができる。その後、成功裡の認証時に、ＥＭＩ１１２によって、各タスクの複数のタスク状況アイコンと共に第１ユーザについてスケジューリングされたタスクのアイコンベース表現を第１ユーザに表示することができる。第１ユーザは、タッチ・スクリーン１１２または他のデータ入力デバイスを介して、ＥＭＩ１１２に表示される各タスクの状況を更新することができる。ユーザが、タスクのすべてまたは一部の状況を更新する時に、ＥＭＩ１１２によって、タスク状況更新メッセージがサーバ１３０に送られる。
【００６８】
ステップ１５０４で、サーバ１３０によって、ＥＭＩ１１２から受け取った第１タスク状況更新メッセージで指定された各タスクの状況を更新する。サーバ１３０によって、第１更新メッセージで指定された各タスクのタスク・レコード２０６をデータベース１４０から検索することができる。さらに、第１ユーザが、タスクを完了した場合に、サーバ１３０によって、タスク・レコードのＳＴＡＴＵＳフィールドをスケジューリング済み識別子から完了識別子に修正する。同様に、第１ユーザが、タスクを完了していない場合には、サーバ１３０によって、タスク・レコードのＳＴＡＴＵＳフィールドをタスク未完了識別子に修正する。ＳＴＡＴＵＳフィールドを更新するユーザのＵＳＥＲ  ＩＤを識別するようにサーバ１３０を構成することもできる。
【００６９】
ステップ１５０６で、サーバ１３０によって、作業状況更新レポートに関する要求を第２ユーザからＥＭＩ１１２を介して受け取ったかどうかが判定され、ステップ１５０８で、第２ユーザに関連する階層レベルに基づいて、第２ユーザに関する作業状況レポートを生成する。ステップ１５１０で、サーバ１３０によって、ＥＭＩ１１２に作業状況レポートを送り、ＥＭＩ１１２によって、このレポートが表示され、第２ユーザが、作業状況レポートの各タスクの状況を変更することができる。ステップ１５１２で、サーバ１３０によって、タスク更新データを含む第２更新メッセージが第２ユーザから受け取られたかどうかを判定する。第２ユーザによって更新された各タスクの更新された状況を、第２更新メッセージに組み込み、そのメッセージをサーバ１３０に送るようにＥＭＩ１１２を構成することができる。サーバ１３０によって、ＥＭＩ１１２から第２更新メッセージが受け取られる時に、ステップ１５１４で、サーバ１３０によって、第２更新メッセージで指定される各タスクの状況が更新される。
【００７０】
各ＳＴＡＴＵＳ変更、ユーザのＵＳＥＲ  ＩＤ、および状況変更の日時を示すデータ構造をリンクすることによって、タスクのヒストリを維持するために、ＳＴＡＴＵＳフィールドを更新する監督ユーザのＵＳＥＲ  ＩＤを保管するように、サーバ１３０を構成することもできる。図１７に、タスクの結果の更新ヒストリの例を示す。
【００７１】
図２２は、ＥＭＩ１１２などのクライアント・デバイスでタスク状況データを受け取る方法１６００を示す流れ図である。ステップ１６０２で、ＥＭＩユニット１６０２が、ユーザのスケジュール内の各タスクの状況を更新するために第１ユーザに照会する。ステップ１６０４で、ＥＭＩ１１２によって、第１ユーザからタスク完了データを受け取る。ユーザが、タスクのすべてまたは一部の状況を更新する時に、ステップ１６０６で、ＥＭＩ１１２によって、第１状況更新メッセージがサーバ１３０に送られる。ステップ１６０６で、ＥＭＩ１１２によって、第１状況更新メッセージがサーバ１３０に送られ、サーバ１３０は、更新メッセージからのタスク完了データを使用して、リモート・データベース１４０の対応するタスク・レコードを更新する。一実施形態では、監督ユーザなどの第２ユーザが、検査ステージを実行するために、第１ユーザのタスクを含む作業状況レポートに関する要求を送ることができる。
【００７２】
図２２に戻って、ＥＭＩ１１２によって、ステップ１６０８でサーバ１３０から作業状況レポートが受け取られ、作業状況レポートが返される場合に、ステップ１６１０で、ＥＭＩ１１２によって、作業状況レポートが、タッチ・スクリーン１１２で第２ユーザに表示され、第２ユーザは、作業状況レポートの各タスクの状況を変更することができる。ステップ１６１２で、ＥＭＩ１１２によって、第２ユーザがタスク状況レポートで指定されるタスクのいずれかの状況を変更したかどうかを判定する。ＥＭＩ１１２によって、タスクのいずれかの状況変更が検出される場合には、ステップ１６１８で、ＥＭＩ１１２によって、第２更新メッセージをサーバ１３０に送る。第２更新メッセージには、更新されたタスクの変更された状況が含まれる。図２１および２２に関して説明した例示的方法１５００および１６００によれば、所定のヒストリ・レベルに関連するユーザが、他のユーザによって実行されるタスクを承認または拒否することができ、したがって、サーバ１３０でのタスク状況変更プロセスをトリガする。さらに、承認されたタスクをクローズするようにサーバ１３０を構成することができる。
【００７３】
第２ユーザ、たとえば監督ユーザが、タスク・レコードのＳＴＡＴＵＳフィールドを完了状態から未完了状態または拒否状態に更新する場合に、第１ユーザのユーザ・レコード２０２のＥＲＲＯＲ  ＣＯＵＮＴフィールドを増分するようにサーバ１３０を構成できることに留意されたい。また、第２ユーザは、第１ユーザのユーザ・レコードにアクセスし、ＩＮＳＴＲＵＣＴフィールドをセットすることができ、その結果、タスク完了のための指示が、ＥＭＩ１１２を使用する後続の作業スケジュール・アクセスについて第１ユーザに自動的に表示されるようになる。
【００７４】
図２３は、サーバ１３０での「スケジューリング済み」から「期日」にタスクの状況を更新する方法１７００を示す流れ図である。タスクは、タスクの状況が「期日」になるまで、完了についてユーザに出力されないようにすることができる。ステップ１７０２で、サーバ１３０によって、「タスク・スケジューリング済み」識別子に関連する最初のタスク・レコードがデータベース１４０から検索される。ステップ１７０４で、サーバ１３０によって、検索されたタスク・レコードのタスクを「期日」識別子を用いて更新しなければならないかどうかを判定する。サーバ１３０は、検索されたタスク・レコードに複数のタスク期日条件を適用することによってこの判定を行うことができる。サーバ１３０によって、期日日付状況状態が満足されると判定される場合に、ステップ１７０６で、サーバ１３０によって、検索されたタスク・レコードの状況が、「スケジューリング済み」識別子から「期日」識別子に更新される。ステップ１７０８で、サーバ１３０によって、データベース１４０に、タスク・スケジューリング済み状況識別子を含むタスク・レコードが複数あるかどうかが判定される。そうである場合には、この方法はステップ１７１０に進み、そこで、サーバ１３０によって次のレコードが検索され、この方法は、ステップ１７０４で継続される。周期的に方法１７００を実行するように、サーバ１３０を構成することができる。たとえば、４５分ごとに方法１７００を実行するためにシステム・デーモンをスケジューリングするように、サーバ１３０を構成することができる。さらに、タスク「期日」識別子をタスク「遅れ」識別子に更新するようにサーバ１３０を構成することができる。図２４は、タスクの状況の期日から遅れへの更新の例示的な方法１８００を示す流れ図である。タスクが遅れているとの判定の際にアラート・メッセージを送るようにサーバ１３０を構成できることに留意されたい。
【００７５】
図２５は、タスク「承認」識別子からタスク「クローズド」識別子への更新の方法１９００を示す流れ図である。ステップ１９０２で、サーバ１３０によって、タスク「承認」識別子を用いてマークされたタスクを含む最初のタスク・レコードをデータベース１４０から検索する。サーバ１３０は、現在のシステム時刻をタスク・レコードでセットされたタスク完了時刻と比較することによって、タスク・レコードをクローズしなければならないかどうかを判定することができる。現在システム時刻が、最初のタスク・レコードで指定されるタスク完了時刻より大きい場合に、ステップ１９０６で、サーバ１３０によって、最初のタスク・レコードのタスク「承認」識別子をタスク「クローズド」識別子に更新する。サーバ１３０が、監督ユーザからタスク承認データまたはタスク拒否データを受け取らない場合に、そのようなタスクをシステム承認し、クローズするようにサーバ１３０を構成することができる。図２６は、サーバによってタスクを自動的に承認する方法２０００を示す流れ図である。一実施形態によれば、サーバ１３０によって、タスク完了時刻と現在時刻の間の差を計算することができる。さらに、サーバ１３０によって、サーバ１３０によるタスクの自動的な承認に関するデータベース１４０内で供給される所定のクローズ時間期間と、計算された時間差を比較することができる。
【００７６】
ユーザがタスク状況を更新するか、システムが状況を自動的に更新するかタスクを再スケジューリングする時に、いくつかの実施形態で、本発明によるシステムを、更新された状況を外部システムに供給するように構成することが有利になる場合がある。さらに、一実施形態によれば、未完了タスクを再スケジューリングするかクローズするように、サーバ１３０を構成することができる。未完了タスクは、タスク「未了」識別子を用いてタスク・レコード内で識別することができる。図２７は、未完了タスクに関連するタスク・レコードの更新の方法２１００を示す流れ図である。未完了タスクには、タスク「取消」識別子、「オープン」識別子、または「未了」識別子に関連するタスクを含めることができる。再スケジューリング・ルールに、現在時刻とレコードで指定されるタスク完了時刻の間の差が、０を超え、データベース１４０で供給される作業完了リード・タイム値以下であるかどうかをサーバ１３０によって判定するための指示を含めることができる。
【００７７】
図２８は、タスク「再スケジュール」識別子に関連するタスク・レコードの更新の方法２２００を示す流れ図である。一実施形態によれば、サーバ１３０は、タスク・クローズド条件を第１タスク・レコードに保管されたタスク・データに適用することによって、この判定を行う。サーバ１３０は、タスクがそれについてスケジューリングされた所定の設備での同一のタスクの次の出現が、現在のタスク日時より大きいタスク日時を有するかどうかと、次の出現の状況が、スケジューリング済み、期日、または進行中でないかどうかを判定することによって、タスクを取り消し、後にクローズしなければならないかどうかを判定することができる。条件が満足される場合に、ステップ２２０８で、サーバ１３０によって、タスク「再スケジューリング」識別子をタスク「取消」に更新し、その後、タスク「クローズド」識別子に更新する。そうでない場合には、ステップ２２０６で、サーバ１３０によって、別の日に対応する、その設備の設備レコードおよびユーザのユーザ・レコードの作業スケジュールにこのタスクを追加することによって、タスクを再スケジューリングする。
【００７８】
上で注記したように、本発明の一態様は、作業スケジュールおよび状況データの階層内のユーザのアクセス・レベルの制御に関する。図２９は、本発明による、作業要求をサブミットするユーザのアクセスを制御するプロセス２２３０の一実施形態を示す流れ図である。
【００７９】
エンド・ユーザを、そのユーザ自身の作業スケジュール・データへのアクセスに制限することができる。図４の例のデータでは、ＵＳＥＲ  ＩＤ＝３４およびＵＳＥＲ  ＩＤ＝２８のユーザが、ＣＵＳＴＯＭＥＲ  ＩＤ  ＝３５５の顧客レコード内の対応するＡＣＣＥＳＳフィールドに自分のＵＳＥＲ  ＩＤ値をセットされている。したがって、ステップ２２３４で、サーバ１３０によって、その検索中にＣＵＳＴＯＭＥＲ  ＩＤ＝３５５の顧客レコードが発見され、ステップ２２４０で、サーバ１３０によって、ＵＳＥＲ  ＩＤ＝３４およびＵＳＥＲ  ＩＤ＝２８のユーザのアクセスが、そのユーザ自身の作業スケジュールに制限され、この作業スケジュールは、ユーザが正しい設備からログインしていることを保証するために作業スケジュール要求と共に送られたＦＡＣＩＬＩＴＹ  ＩＤの検査と共に、要求された設備の設備レコードまたは各ユーザのユーザ・レコードのいずれかから入手することができる。
【００８０】
しかし、ＵＳＥＲ  ＩＤ値３０、５６、および８８を有するユーザなどの上位ユーザがログインする場合に、これらのユーザは、ＣＵＳＴＯＭＥＲ  ＩＤ＝３５５の顧客レコード２０８のＡＣＣＥＳＳフィールドに示されているように、より高いレベルのアクセスの資格を与えられる。ステップ２２３４での顧客レコードの検索によって、ＣＵＳＴＯＭＥＲ  ＩＤ＝３５５の顧客レコードの発見および検索がもたらされる。ＵＳＥＲ  ＩＤ＝３０の顧客レコードのＬＥＶＥＬ値は、１３１であり、これは、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１に対応する。したがって、ステップ２２４０で、ＵＳＥＲ  ＩＤ＝３０のユーザは、その設備の作業スケジュールおよび状況データへのアクセスを許可され、これらのデータは、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１の設備レコードから入手することができる。ＵＳＥＲ  ＩＤ＝３０の顧客レコードのＬＥＶＥＬ値は１３１であり、これは、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１に対応する。したがって、ステップ２２４０で、ＵＳＥＲ  ＩＤ＝３０のユーザは、その設備の作業スケジュールおよび状況データへのアクセスを許可され、これらのデータは、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１の設備レコードから入手することができる。同様に、ＵＳＥＲ  ＩＤ＝５６の顧客レコードのＬＥＶＥＬ値は１１０であり、これはＲＥＧＩＯＮ  ＩＤ＝１１０に対応し、これによって、顧客レコードにＦＡＣＩＬＩＴＹ  ＩＤ値１３１、１３３、および１３４が含まることが示される。したがって、ステップ２２４０で、ＵＳＥＲ  ＩＤ＝５６のユーザは、これらの設備の作業スケジュールおよび状況データにアクセスすることを許可され、これらのデータは、ＦＡＣＩＬＩＴＹ  ＩＤ＝１３１、１３３、および１３４の設備レコードから入手することができる。ＵＳＥＲ  ＩＤ＝８８の顧客レコードのＬＥＶＥＬ値は、３５５であり、これはＣＵＳＴＯＭＥＲ  ＩＤ＝３５５に対応する。したがって、ステップ２２４０で、ＵＳＥＲ  ＩＤ＝８８のユーザは、顧客レコードで示されるすべての地域のすべての設備の作業スケジュールおよび状況データにアクセスすることを許可される。あるユーザが使用可能なデータの階層を、そのユーザにグラフィカルに示すことができる。たとえば、ＵＳＥＲ  ＩＤ＝８８のユーザによるログインによって、図１５のダイアログ・ボックス１００２に示されたものなどの表示のサーバ１３０による提供をもたらすことができ、ここで、ユーザは、顧客レベル、地域レベル、および設備レベルを表すフォルダ・アイコンを見ることができる。
【００８１】
上で説明した本発明を、時刻およびユーザのアテンダンス・データを追跡するように適合させることもできる。サーバ１３０を、ユーザがシステムにログ・インする時刻またはログ・アウトする時刻を保管するように適合させることができる。このデータを使用して、従業員アテンダンス・レコードを維持することができ、時給従業員のために時間を測定することもできる。また、本発明を、自動在庫管理を実行するように適合できることに留意されたい。同様に、本発明は、特定の設備で作業を実行するユーザに制限されない。上の教示を、そのユーザによって実行される役割または機能に基づいてユーザを識別するように適合することができる。
【００８２】
上で説明した本発明の一態様に基づいて構築して、アラート・メッセージ自体を、タスクとして扱うことができる。アラート・メッセージは、ユーザに割り当てられたタスクとして構成される。上で簡単に触れた本発明のもう１つの態様は、本発明によって、上で説明したデータ階層の特定のレベルのすべてのメンバのためにタスクを生成できるようになることである。
【００８３】
本明細書に記載のプログラム、プロセス、方法、およびシステムが、特に示されない限り、特定のタイプのコンピュータまたはネットワーク・システム（ハードウェアまたはソフトウェア）に関連せず、これらに制限されないことを理解されたい。さまざまなタイプの汎用または特殊化されたコンピュータ・システムが、本明細書に記載の教示による動作と共に使用することができ、これを実行することができる。
【００８４】
本発明の原理を適用できるさまざまな実施形態に鑑みて、示された実施形態が例示のみであって、本発明の範囲に関する制限と解釈されてはならないことを理解されたい。当業者には、作業の管理のシステムおよび方法に用いられる方法を、コンピュータ使用可能媒体を含むコンピュータ・プログラム製品で実施することができる。コンピュータ可読媒体に、バスまたは通信リンクなど、ディジタル・データ信号またはアナログ・データ信号としてその上で搬送されるプログラム・コード・セグメントを有する光学、有線、または無線の、通信媒体または伝送媒体を含めることができる。
請求項を、そのように記述されない限り、記述された順序または要素に制限されると解釈してはならない。
【図面の簡単な説明】
【００８５】
【図１】本発明による電子管理インターフェースの実施形態の一例を示す機能ブロック図である。
【図２】本発明による中央サーバ・データベースに存在する可能性があるデータ構造の例を示すデータ図である。
【図３】本発明による、設備レコード、タスク・レコード、およびユーザ・レコードに含まれるデータの例を示すデータ図である。
【図４】本発明による、２つの顧客のデータを移植された顧客レコードの例を示すデータ図である。
【図５】本発明による、電子管理インターフェースで使用することができるソフトウェア・アーキテクチャの実施形態を示す単純化された図である。
【図６】本発明による、一実施形態に従って作業スケジュールを要求するメッセージの交換を示すブロック図である。
【図７】本発明による、第２の実施形態に従って作業スケジュールを要求するメッセージの交換を示すブロック図である。
【図８】本発明による、電子管理インターフェース中央管理サーバ通信のメッセージ・フローを示すブロック図である。
【図９】本発明の好ましい実施形態による、例示的なログイン・ダイアログ・ボックスを示す図である。
【図１０】本発明の好ましい実施形態による、例示的なアイコンベースのスケジュール・ダイアログ・ボックスを示す図である。
【図１１】本発明の好ましい実施形態による、例示的なタスク位置ダイアログ・ボックスを示す図である。
【図１２】本発明の好ましい実施形態による、例示的なタスク指示ダイアログ・ボックスを示す図である。
【図１３】本発明の好ましい実施形態による、例示的なタスク状況更新ダイアログ・ボックスを示す図である。
【図１４】本発明の好ましい実施形態による、ウェブ・サイト・ユーザ用の例示的なウェブ・サイト・ダイアログ・ボックスを示す図である。
【図１５】本発明の好ましい実施形態による、ユーザ認証の際にユーザに表示することができる例示的なウェブ・サイト・ダイアログ・ボックスを示す図である。
【図１６】本発明の好ましい実施形態による、例示的なウェブ・サイト作業カレンダ・ダイアログ・ボックスを示す図である。
【図１７】本発明の好ましい実施形態による、作業注文レコードを示す例示的なダイアログ・ボックスを示す図である。
【図１８】本発明の好ましい実施形態による、検査レコードを示す例示的なダイアログ・ボックスを示す図である。
【図１９】本発明の好ましい実施形態による、中央管理サーバからクライアント・デバイスへの作業スケジュールの供給の方法を示す流れ図である。
【図２０】本発明の好ましい実施形態による、クライアント・デバイスでの作業スケジュールの要求および受取の方法を示す流れ図である。
【図２１】本発明の好ましい実施形態による、クライアント・デバイスに対する中央管理サーバでのタスク状況レコードの管理の方法を示す流れ図である。
【図２２】本発明の好ましい実施形態による、クライアント・デバイスでタスク状況データを受け取る方法を示す流れ図である。
【図２３】本発明の好ましい実施形態による、中央管理サーバでの「スケジューリング済み」から「期日」へのタスク状況の更新の方法を示す流れ図である。
【図２４】本発明の好ましい実施形態による、中央管理サーバでの「期日」から「遅れ」へのタスク状況の更新の方法を示す流れ図である。
【図２５】本発明の好ましい実施形態による、中央管理サーバでの「承認」から「クローズド」へのタスク状況の更新の方法を示す流れ図である。
【図２６】本発明の好ましい実施形態による、中央管理サーバによるタスク状況の強制承認の方法を示す流れ図である。
【図２７】本発明の好ましい実施形態による、中央管理サーバでの未完了タスクの取消およびクローズの方法を示す流れ図である。
【図２８】本発明の好ましい実施形態による、中央管理サーバでの、タスク「再スケジュール」識別子に関連するタスク・レコードの更新の方法を示す流れ図である。
【図２９】本発明の好ましい実施形態による、顧客データの階層に対するユーザの許可されるアクセス・レベルに基づいて顧客データへのアクセスを制御する方法を示す流れ図である。
【図３０】本発明の好ましい実施形態による、顧客データの階層に対するユーザの許可されるアクセス・レベルに基づいてユーザの組にブロードキャスト・メッセージを送信する方法を示す流れ図である。
【図１】
2005509220.tif 000003
【図２】
2005509220.tif 000004
【図３】
2005509220.tif 000005
【図４】
2005509220.tif 000006
【図５】
2005509220.tif 000007
【図６】
2005509220.tif 000008
【図７】
2005509220.tif 000009
【図８】
2005509220.tif 000010
【図９】
2005509220.tif 000011
【図１０】
2005509220.tif 000012
【図１１】
2005509220.tif 000013
【図１２】
2005509220.tif 000014
【図１３】
2005509220.tif 000015
【図１４】
2005509220.tif 000016
【図１５】
2005509220.tif 000017
【図１６】
2005509220.tif 000018
【図１７】
2005509220.tif 000019
【図１８】
2005509220.tif 000020
【図１９】
2005509220.tif 000021
【図２０】
2005509220.tif 000022
【図２１】
2005509220.tif 000023
【図２２】
2005509220.tif 000024
【図２３】
2005509220.tif 000025
【図２４】
2005509220.tif 000026
【図２５】
2005509220.tif 000027
【図２６】
2005509220.tif 000028
【図２７】
2005509220.tif 000029
【図２８】
2005509220.tif 000030
【図２９】
2005509220.tif 000031
【図３０】
2005509220.tif 000032
【国際調査報告】
2005509220.tif 000033
2005509220.tif 000034