JP4531529B2 - 情報処理装置管理システム及び情報処理装置管理方法およびプログラムおよび記録媒体 - Google Patents

Description

本発明は、操作を行う際に承認手続きを必要とする情報処理装置に対する操作を管理する情報処理装置管理システム及び情報処理装置管理方法およびプログラムおよび記録媒体に関するものである。

ＩＳＭＳ（Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｃｕｒｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）承認取得部門では、サーバＰＣの設定変更等の操作を行う場合において、操作の承認取得・操作結果等をログとして残す等の定型的な申請プロセスが発生する。

そのため、従来では、承認申請毎に承認内容をドキュメント化し、申請承認者を選定していた。

なお、管理者の承認を受けたことを条件としてデータベースのデータ更新を許可するプロセスを自動化したデータ処理システムの文献に特許文献１がある。
特開２０００−２５９４７７号公報

しかしながら、従来では、上述したように、承認申請毎に承認内容をドキュメント化し、申請承認者を選定し、その後も書類の管理を行わなければならならず非常に煩雑であった。

また、申請書に記載された操作を操作対象ＰＣに適用する際には、操作対象ＰＣの管理者が承認申請書類に記載された操作内容を理解し、手動で操作を行って適用していたため、誤った操作（申請と異なる操作）を行ってしまうという事態が発生する可能性もあった。

さらに、申請の承認を行う申請承認者は、承認のために操作対象ＰＣの状態を把握する必要があるため、申請承認者全員に操作対象ＰＣの操作権限を与えなければならならず、操作対象ＰＣの保守性という観点では問題があった。

また、申請者は、他の設定変更申請との排他性を意識して申請しなければならず、非常に煩雑であった。ここで「排他」とは、例えば未承認の「ｃ：￥ｔｅｍｐ削除」という操作申請が先に提出されており、その後に「ｃ：￥ｔｅｍｐのアクセス権限変更」という操作申請が提出された場合、先の操作申請が承認されて実行されるか否かによって、後に提出した操作申請の実行に影響を与える（実行できなくなってしまう）等というケースを指す。なお、従来では、操作申請もドキュメント提出であるので、先にどのような操作申請が提出されているのか把握することすら困難であった。

さらに、先に申請された操作に関連した申請は、その申請の承認後でなければ行うことができず、非常に煩雑であった。

本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、操作を行う際に承認手続きを必要とする操作対象装置に対する操作依頼，承認申請，操作実行，操作結果報告，ログ保持管理までのワークフローとを自動化することができる仕組を提供することである。

本発明は、操作対象装置に対する操作依頼を申請する操作依頼装置と通信可能に接続され、当該申請された操作依頼の操作依頼情報を管理する操作情報管理装置おいて、前記操作依頼装置から申請された操作依頼の操作依頼情報を順次記憶管理する第１の記憶手段と、前記操作依頼装置から申請された新たな操作依頼情報より前に申請された他の実行待ちの操作依頼情報で指定された操作を前記操作対象装置で実行した後でも、前記新たな操作依頼情報で指定された操作を前記操作対象装置で実行することが可能であるか否かを判定する第１の判定手段と、前記第１の判定手段により、前記新たな操作依頼情報で指定された操作が前記操作対象装置で実行不可能であると判定された場合には、該新たな操作依頼情報の申請を行った操作依頼装置に対して警告を通知する警告手段と、前記第１の記憶手段に記憶される前記操作依頼情報で指定された操作の実行指示を前記操作対象装置に送信し、前記操作対象装置に実行させる実行手段とを有することを特徴とする。

本発明によれば、操作対象装置に対する操作依頼、操作実行等のワークフローを自動化することができ、諸手続きの簡略化や、申請書類作成・管理の負荷を軽減することができるとともに、人手を介さないため申請された操作内容を確実に操作対象装置に反映させ操作内容の不変性を保証することができる。

また、操作情報管理装置が、申請者ごとに割当てられた操作権限情報に基づいて、前記操作依頼情報が権限を有する申請者から申請されたものでないと判定した場合には、該操作依頼情報の申請を拒否するので、権限のないユーザからの申請は予め拒否して情報処理装置の保守性を向上することができる。

また、操作情報管理装置は、申請された操作依頼情報と該操作依頼情報より前に申請された他の操作依頼情報との関係が、先に実行される操作により後に実行される操作が実行不可能となってしまう排他関係であると判定された場合には、その旨を示す情報を前記操作依頼情報の送信元の操作依頼装置に通知するので、他の設定変更申請との排他性を意識することなく操作依頼申請を行うことができる。

さらに、操作情報管理装置は、権限情報と無承認で操作可能な操作権限情報とに基づいて、前記申請された操作依頼情報が無承認で操作可能な操作権限を有する申請者から申請されたものであるか否かを判定し、前記申請された操作依頼情報が無承認で操作可能な操作権限を有する申請者から申請されたものであると判定された場合には、該操作依頼情報に対する承認確認を省略するので、申請者の権限と操作内容によっては、承認者の承認を得ずに操作の適用ができ、承認処理の効率を格段に向上することができる。

また、操作情報管理装置は、操作内容ごとの承認種別に基づいて、前記申請された操作依頼情報に対する承認確認方法を変更制御するので、承認条件を自動で判定して承認処理を効率化することができる。

さらに、操作依頼装置は、操作対象装置のシステム構成情報を取得し、該取得したシステム構成情報に基づいて前記操作対象装置を仮想操作可能な仮想操作画面を表示し、該表示された前記仮想操作画面への仮想操作に基づいて前記操作対象装置に対する操作依頼情報を作成し、該作成された操作依頼情報を前記操作情報管理装置に送信して申請を行うので、操作依頼情報の生成を直接操作対象装置を操作するかの如き操作感の元で操作内容情報を容易に作成することができる。

従って、ＩＳＭＳ承認取得部門においてサーバ等の情報処理装置の設定変更等の操作を行う場合の操作の承認取得・操作結果等をログとして残す等の定型的な申請プロセスを自動化して、承認書類の作成，管理を大幅に簡略化して効率を上げるとともに、不整合発覚時の原因追跡、操作対象装置の自動監査等により情報処理装置の保守性を向上することができる等の効果を奏する。

〔第１実施形態〕
図１は、本発明の第１実施形態を示す情報処理装置管理システムの一例を示すシステム構成図である。

図１において、３００は操作対象ＰＣで、実際に操作の対象となる情報処理装置である。２００は個人端末で、操作希望者が操作依頼を行うための情報処理装置である。

１００は操作情報管理ＰＣで、個人端末２００からの操作依頼情報に基づいて操作対象ＰＣ３００に操作を実施させる。１５０は操作依頼申請書データベース（ＤＢ）で、操作情報管理ＰＣ１００からの制御により、個人端末２００から申請される操作依頼情報を保存管理する。１５００は後述する図１５に示す操作結果報告書ＤＢ１５００である。

４００は複数の承認者ＰＣで、操作情報管理ＰＣ１００からの承認要求に基づいて承認／否認の情報を操作情報管理ＰＣ１００に返送する。

なお、本実施形態で示す操作情報管理ＰＣ１００，操作対象ＰＣ３００は、ＰＣ，端末等の表現を用いているが、パーソナルコンピュータ等に限られるものではなく、ワークステーション又はその他の情報処理装置であってもよい。

また、個人端末２００も、パーソナルコンピュータ等に限られるものではなく、ＰＤＡ，ワークステーション又はその他の情報処理装置であってもよい。

なお、この情報処理装置管理システムは、操作を行う際に承認手続きが必要なＰＣ（操作対象ＰＣ３００）への操作を行う場合の、承認申請から操作実行，操作結果報告までのワークフローを自動化するためのシステムであり、ＩＳＭＳ承認取得部門等のサーバＰＣの設定変更等の操作を行う場合において発生する操作の承認取得・操作結果等のログを残す等の一連の定型的な申請プロセスを自動化することによって、諸手続きの簡略化や、申請書類作成・管理の負荷を軽減することができる。なお、本実施形態において、「操作」とは、ＰＣへのフォルダ、ファイルの作成、削除、アカウント追加、サービスの開始、シャットダウン等、本システムで制御可能な全ての操作を指す。

図２は、図１に示した操作情報管理ＰＣ１００の構成を示すブロック図である。

図２において、１０１はＣＰＵで、ハードディスク１０５又はその他の記録媒体（記憶媒体）に記憶されたプログラムに基づいて各デバイスを制御する。

また、１０２はメモリで、ＣＰＵ１の主メモリ，ワークエリア等として機能する。

１０３はＩ／Ｏ制御部で、キーボード１０７，マウス１０８等のポインティングデバイス，プリンタ１０９，ネットワーク５００との入出力を制御する。

１０４はビデオコントローラで、モニタ１０６の表示を制御する。なお、ハードディスク１０５上には、操作依頼申請書ＤＢ１５０，後述する図１５に示す操作結果報告書ＤＢ１５００が実装されている。また、このハードディスク１０５は、後述する図９に示す操作権限リスト９００，図１１に示す無承認操作可能権限リスト１１００，図１２に示す承認種別リスト１２００が予め格納されている。さらに、このハードディスク１０５には、後述する図６に示す承認待ち操作依頼情報格納エリア６００が確保されている。

なお、図１に示した操作情報管理ＰＣ１００においては、モニタ１０６，キーボード１０７，マウス１０８，プリンタ１０９は必ずしも備えている必要はない。

また、図１に示した個人端末２００，操作対象ＰＣ３００，承認者ＰＣ４００も、図２に示した操作情報管理ＰＣ１００のハードウェア構成と同様である。但し、ハードディスク１０５内に、上述した各ＤＢの実装，各データの格納はされていない。

図３は、図１に示した操作依頼申請書ＤＢ１５０のレコード構成を示す模式図である。

図３に示すように、操作依頼申請書ＤＢ１５０は、操作管理番号（ＩＤ）１５１，申請者１５２，申請内容１５３，申請日１５４，申請結果１５５，申請書ファイル名１５６等から構成される。

操作管理番号（ＩＤ）１５１は、操作情報管理ＰＣ１００において申請受け付け順に順次付与される番号を示す。申請者１５２は、申請者を特定可能な情報に対応する。申請内容１５３は、操作対象ＰＣをネットワーク上で識別可能な情報（例えば「Ｓｅｒｖｅ００１」）と該操作対象ＰＣに対する操作を特定可能な情報（例えば、依頼内容「新規共有作成」，対象物「ディレクトリ，￥￥Ｓｅｒｖｅ００１￥ｔｍｐ￥ｔｅｍｐｌａｔｅ」，付与するアクセス権「読み書き」）と操作依頼申請時に申請者により入力されるその他の情報（例えば、予定使用容量「１ＧＢｙｔｅ」，申請理由・付記「課員の勤務表を保管するため、上記ディレクトリの共有を申請します。」等）を含む。

申請日１５４は、操作情報管理ＰＣ１００において申請受け付けした日付に対応する。

申請結果１５５は、承認に関する情報と作業に関する情報を含む。承認に関する情報は、承認された日付を示す承認日，承認時に承認者により記入される承認記録等，承認された経路を示す承認経路を含む。また、作業に関する情報は、操作が反映された日付を示す作業日，実際に操作が行われた内容を示す作業記録（例えば、「指定ディレクトリの作成を行った。指定ディレクトリ作成後、アクセス可否の検証を行った。」），作業に関する特記事項等の情報を含む。

申請書ファイル名１５６は、図４に示す申請書１６０のファイル名を示す。

図４は、図３に示した申請書ファイル名１５６に対応する申請書の一例を示す模式図である。

図４に示す申請書１６０は、操作情報管理ＰＣ１００による操作依頼申請情報の操作依頼申請書ＤＢ１５０への登録時に、該登録する操作依頼申請情報及びハードディスク１０５内に格納される各種管理情報（ユーザ管理情報，ＰＣ管理情報等）に基づいて、操作情報管理ＰＣ１００により作成され、ハードディスク１０５内に格納されるものとする。

図４において、１６１は申請日で、図３に示した操作依頼申請書ＤＢ１５０内の申請日１５４から生成される。

また、１６２は申請者氏名，社員番号，所属部署ｏｒ会社名で、図３に示した操作依頼申請書ＤＢ１５０内の申請者１５２及びユーザ管理情報等に基づいて生成される。

さらに、１６３は対象部門，対象サーバ，依頼内容，対象物，対象組織，付与するアクセス権，予定使用容量，申請理由・付記等の情報で、図３に示した操作依頼申請書ＤＢ１５０内の申請内容１５３及びＰＣ管理情報等に基づいて生成される。また、１６６は申請書名で、図３に示した操作依頼申請書ＤＢ１５０内の申請内容１５３に基づいて生成される。

１６４は承認日，承認記録等の情報で、図３に示した操作依頼申請書ＤＢ１５０内の申請結果１５５等に基づいて生成される。１６７は承認経路情報で、図３に示した操作依頼申請書ＤＢ１５０内の申請結果１５５等に基づいて生成される。

１６５は作業日，作業記録，特記事項等の情報で、図３に示した操作依頼申請書ＤＢ１５０内の申請結果１５５等に基づいて生成される。

図５は、図１に示した管理システムにおける操作依頼の申請から操作結果報告までの一連のプロセスを説明するフローチャートであり、Ｓ１〜Ｓ１３は各ステップを示す。

操作対象ＰＣ３００の操作を希望する場合、まず、図５のステップＳ１において、操作依頼情報を作成し、次に、図５のステップＳ２において、ステップＳ１で作成した操作依頼情報に基づいて操作申請を行う。以下、この操作依頼情報の作成及び申請手順を、図６〜図８を参照して詳細に説明する。

図６は、図５のステップＳ１，Ｓ２に示した操作依頼情報の作成及び申請手順を詳細に示す図であり、図５と同一のものには同一の符号を付してある。

図６に示すように、操作対象ＰＣ３００の操作を希望する場合、まずステップＳ１−１において、個人端末２００上で図７に示す操作依頼情報を作成画面（仮想ウィンドウ）を開く為に必要な情報（操作対象ＰＣ３００のディレクトリ構成，ファイル構成等のファイル管理情報を含むシステム構成情報）を個人端末２００が操作対象ＰＣ３００に要求して取得し、ステップＳ１−２において、個人端末２００が操作依頼情報の作成画面（仮想ウィンドウ）を個人端末２００のモニタ７００上に表示し（開き）、この仮想ウィンドウへの操作に基づいて操作依頼情報を作成する。この操作依頼情報の作成画面（仮想ウィンドウ）の一例を図７に示す。

この図７に示す操作依頼情報の作成画面（仮想ウィンドウ）７０１上でユーザは、操作対象ＰＣ３００上で実際に行うのと同様の操作を行うことができ、この仮想ウィンドウ７０１上で操作を行うことにより、操作対象ＰＣ３００への操作依頼の作成及び申請を行うことができる。また、この仮想ウィンドウ７０１で操作を行った際には、個人端末２００は、該操作に対する情報を入力するためのインタフェースを個人端末２００のモニタ７００上に表示するものとする。例えば、仮想ウィンドウ７０１上で操作対象ＰＣ３００上に新たにディレクトリを作成する操作を行った場合、該作成するディレクトリの「予定使用量」や「申請理由・付記」を入力するためのインタフェースを表示するものとする。

そして、ユーザが仮想ウィンドウ７０１のＧＵＩを用いて所望の操作を行い、該操作に対する情報を入力すると、個人端末２００が該操作及び操作に対応する情報に基づいた操作依頼情報を作成する。この操作依頼情報は、図３で示した操作依頼申請書ＤＢ１５０内のレコード構成と同様の構成を示す。但し、この時点では、申請者１５２内の申請者氏名，申請内容１５３内の対象サーバ，依頼内容，対象物，予定使用量，申請理由・付記等，申請日１５４が格納されている程度のものとし、その他の情報は、処理を進める毎に順次格納されていくものとする。

次に、ステップＳ２において、個人端末２００は、図６のステップＳ１−２で作成した操作依頼情報を操作情報管理ＰＣ１００に送信することにより操作依頼情報を申請（登録）し、操作情報管理ＰＣ１００は、該送信された操作依頼情報を受信し、該受信した承認待ちの操作依頼情報をハードディスク１０５又はメモリ１０２内の承認待ち操作依頼情報格納エリア６００にスプールする。

なお、この操作依頼情報の作成及び申請処理は、実行待ちの操作依頼が正しく実行されることを仮定して、前記実行待ちの操作依頼の実行に先行して行うことができる。以下、この操作依頼情報の作成（先行依頼）について図８を用いて説明する。

図８は、操作依頼情報の作成（先行依頼）を詳細に示す図である。

図８に示すように、操作管理ＩＤ１が処理されていないと操作出来ない操作依頼情報を、承認待ちの操作が実行されることを仮定して、登録することができる。

例えば、操作管理ＩＤ１のフォルダ作成「ｃ：￥ｔｅｍｐ￥ｔｅｍｐｌａｔｅ」が承認されると仮定して、操作管理ＩＤ１の承認及び実行に先立って、「ｃ：￥ｔｅｍｐ￥ｔｅｍｐｌａｔｅ」にファイル「ｒｅａｄｍｅ．ｔｘｔ」作成の操作依頼を発行することができる。

これにより、依頼した操作が無事承認されて実行されることを仮定して、順次複数の操作依頼を申請することができ、操作依頼処理を効率良く行うことができる。

以下、図５の説明に戻る。

次に、図５のステップＳ３において、ステップＳ２で行った操作申請が適切な権限を有するユーザから出されたか否かの判定処理を行う。以下、この操作依頼者の権限検証手順を、図９を参照して説明する。

図９は、図５のステップＳ３に示した操作依頼者の権限検証手順を詳細に示す図である。

図９に示すように、操作情報管理ＰＣ１００は、ハードディスク１０５に予め格納されている操作権限リスト９００に基づいて、ステップＳ２で登録された個人端末２００からの操作依頼情報が、適切な権限を有するユーザから出されたか否かの判定処理を行う。

この操作権限リスト９００は、ユーザの氏名を示す名前９０１，ユーザの権限を示す権限９０２から構成される。そして、この権限９０２には、権限の低い順に「拒否」，「一般権限」，「役職権限」，「管理者権限」等がある。なお、権限９０２が「拒否」の場合は、何の権限も与えられておらず、全ての操作要求は拒否されるものとする。また、権限９０２が「一般権限」，「役職権限」，「管理者権限」等の場合には、後述する図１１に示す無承認操作可能権限リスト１１００に基づく無承認操作権限が与えられているものとする。

よって、図９に示した例では、操作情報管理ＰＣ１００は、ユーザ「山田洋子」，「佐藤友美」，「伊藤健一」，「小泉雄二」から申請された操作依頼情報については、適切な権限を有するユーザの操作依頼と判定して受け入れて次のステップに移行させ、ユーザ「木村一郎」や未登録のユーザ「Ｊｏｈｎ」から申請された操作依頼情報については、適切な権限を有していないユーザの操作依頼と判定して操作依頼を拒否する。

以下、図５の説明に戻る。

そして、図５のステップＳ３で、ステップＳ２で行った操作申請が適切な権限を有するユーザから出されたものでないと判定した場合には、そのままステップＳ１３に進む。

一方、図５のステップＳ３で、ステップＳ２で行った操作申請が適切な権限を有するユーザから出されたものであると判定した場合には、図５のステップＳ４に進み、ステップＳ２で行った操作申請が他の申請内容と排他上の問題が無いかの判定処理を行う。

そして、図５のステップＳ４で、ステップＳ２で行った操作申請が他の申請内容と排他上の問題があると判定した場合には、ステップＳ５において、ステップＳ２で行った操作申請に対応する操作が排他対象操作であることをステップＳ２で行った操作申請者に通知し、図５のステップＳ６に進む。

一方、図５のステップＳ４で、ステップＳ２で行った操作申請が他の申請内容と排他上の問題がないと判定した場合には、そのまま図５のステップＳ６に進む。以下、上記この他の操作申請との排他検証及び通知手順を、図１０を参照して説明する。

図１０は、図５のステップＳ４，Ｓ５に示した他の操作申請との排他検証及び通知手順を詳細に示す図である。

図１０に示すように、操作情報管理ＰＣ１００は、ステップＳ４において、ステップＳ２で申請（登録）された個人端末２００からの操作依頼情報が、操作依頼申請書ＤＢ１５０に格納されている他の承認待ちの操作依頼情報と排他上問題が有るか否かの判定処理を行う。

この判定処理は、申請された操作依頼情報が、他の承認待ちの全操作依頼情報が承認されて全操作が実行された後でも問題無く行うことができる操作に関するものであれば「排他上問題無し」と判定し、一方、他の承認待ちのいずれかの操作依頼情報が承認されて該操作が実行された後では行うことができない操作に関するものであれば「排他上問題有り」と判定する。

例えば、操作依頼情報として、図１０に示す管理ＩＤ４のフォルダ作成「ｃ：￥ｉｍａｇｅ」が申請された場合、承認待ちの全操作依頼情報（管理ＩＤ１〜３）が承認されて全操作が実行された後でも、管理ＩＤ４のフォルダ作成「ｃ：￥ｉｍａｇｅ」は問題無く行うことができるため、管理ＩＤ４のフォルダ作成「ｃ：￥ｉｍａｇｅ」は、「排他上問題無し」と判定する。

また、操作依頼情報として、図１０に示す管理ＩＤ５のフォルダ作成「ｃ：￥ｈｔｍｌ￥ｔｏｐｐａｇｅ￥ｍｅｎｕ」が申請された場合、承認待ちの管理ＩＤ３のフォルダ削除「ｃ：￥ｈｔｍｌ￥ｔｏｐｐａｇｅ」が承認されて実行された後では、管理ＩＤ５のフォルダ作成「ｃ：￥ｈｔｍｌ￥ｔｏｐｐａｇｅ￥ｍｅｎｕ」の操作を行うことができないため、管理ＩＤ５のフォルダ作成「ｃ：￥ｈｔｍｌ￥ｔｏｐｐａｇｅ￥ｍｅｎｕ」は、「排他上問題有り」と判定する。

そして、ステップＳ５において、「排他上問題有り」と判定した場合には、申請された操作が他の承認待ちの操作と排他上問題がある操作であることを示す警告を申請者の個人端末２００に通知する。なお、この警告通知を受けた個人端末２００は、該警告通知をポップアップ表示するものとする。

以下、図５の説明に戻る。

次に、図５のステップＳ６において、ステップＳ２で行った操作申請が承認者の承認が必要な操作か否かを判定する。以下、この承認を要する操作の判定手順を、図１１を参照して説明する。

図１１は、図５のステップＳ６に示した承認を要する操作の判定手順を詳細に示す図である。

図１１に示すように、操作情報管理ＰＣ１００は、ステップＳ６において、ハードディスク１０５に格納されている操作権限リスト９００，無承認操作可能権限リスト１１００に基づいて、ステップＳ２で申請（登録）された個人端末２００からの操作依頼情報が承認を要する操作であるか否かの判定処理を行う。

上記無承認操作可能権限リスト１１００は、操作内容１１０１，操作内容１１０１を無承認操作可能な権限を示す権限１１０２から構成される。そして、この権限１１０２には、権限の低い順に「一般権限」，「役職権限」，「管理者権限」等がある。

即ち、この判定処理では、例えば、操作内容「フォルダ作成」は、「一般権限」以上の権限を有するユーザからの申請であれば承認無しで操作可能であると判断し、操作内容「フォルダ削除」は、「役職権限」以上の権限を有するユーザからの申請であれば承認無しで操作可能であると判断し、操作内容「シャットダウン」は、「管理者権限」を有するユーザからの申請であれば承認無しで操作可能であると判断する。

よって、図１１に示した例では、操作情報管理ＰＣ１００は、ユーザ「山田洋子」が操作内容「フォルダ作成」を依頼した場合、操作権限リスト９００からユーザ「山田洋子」の権限は「一般権限」と分かり、無承認操作可能権限リスト１１００から操作内容「フォルダ作成」を承認無しで操作可能である権限は「一般権限」以上であると分かるので、ユーザ「山田洋子」が依頼した操作内容「フォルダ作成」の操作依頼申請は、「承認無しで操作可能」と判定する。

また、ユーザ「伊藤健一」が操作内容「シャットダウン」を依頼した場合、操作権限リスト９００からユーザ「伊藤健一」の権限は「役職権限」と分かり、無承認操作可能権限リスト１１００から操作内容「シャットダウン」を承認無しで操作可能である権限は「管理者権限」であると分かるので、ユーザ「伊藤健一」が依頼した操作内容「シャットダウン」の操作依頼申請は、「操作に承認が必要」と判定する。

以下、図５の説明に戻る。

そして、図５のステップＳ６で、ステップＳ２で行った操作申請に対応する操作が承認を要する操作でない（承認不要である）と判定した場合には、そのまま図５のステップＳ１０に進む。

一方、図５のステップＳ６で、ステップＳ２で行った操作申請に対応する操作が承認を要する操作であると判定した場合には、ステップＳ７において、ステップＳ２で行った操作申請に対応する操作内容を承認者に送信し、図５のステップＳ８に進み、承認者から承認結果を受信し、図５のステップＳ９に進む。以下、この操作承認確認手順を、図１２を参照して説明する。

図１２は、図５のステップＳ７，Ｓ８に示した操作承認確認手順を詳細に示す図である。

図１２に示すように、操作情報管理ＰＣ１００は、ステップＳ７において、ハードディスク１０５に格納されている承認種別リスト１２００に基づいて、ステップＳ２で申請（登録）された個人端末２００からの操作依頼情報の承認確認する処理を行う。

この承認種別リスト１２００は、操作内容１２０１，操作内容１２０１の承認種別１２０２から構成される。そして、この承認種別１２０２には、「単一承認」，「指定承認（指定された承認者ＰＣ情報）」，「全員承認」等がある。

承認種別「単一承認」は、全承認者ＰＣに承認依頼を出し、いずれかの承認者ＰＣから承認が返送されれば承認されたものとして操作可能となるものである。

また、承認種別「指定承認」は、指定された承認者ＰＣに承認依頼を出し、この承認者ＰＣから承認が返送された場合に操作可能となるものである。

さらに、承認種別「全員承認」は、全承認者ＰＣに承認依頼を出し、全承認者ＰＣから承認が返送された場合に操作可能となるものである。

例えば、図１２に示した例では、操作情報管理ＰＣ１００は、操作内容「フォルダ作成」の操作依頼が申請された場合、承認種別リスト１２００から承認種別が「単一承認」であると分かるので、操作内容「フォルダ作成」の操作依頼申請の承認依頼を全承認者ＰＣに出し（Ｓ７）、いずれかの承認者ＰＣから承認を受信すれば、承認されたものと判定する（Ｓ８）。

また、操作情報管理ＰＣ１００は、操作内容「フォルダ削除」の操作依頼が申請された場合、承認種別リスト１２００から承認種別が「指定承認（承認者ＰＣ（２））」であると分かるので、操作内容「フォルダ削除」の操作依頼申請の承認依頼を承認者ＰＣ（２）に出し（Ｓ７）、承認者ＰＣ（２）から承認を受信すれば、承認されたものと判定する（Ｓ８）。

さらに、操作情報管理ＰＣ１００は、操作内容「シャットダウン」の操作依頼が申請された場合、承認種別リスト１２００から承認種別が「全員承認」であると分かるので、操作内容「シャットダウン」の操作依頼申請の承認依頼を全承認者ＰＣに出し（Ｓ７）、全承認者ＰＣから承認を受信すれば、承認されたものと判定する（Ｓ８）。

なお、各承認者ＰＣのＩＰアドレス等は、予め設定されてハードディスク１０５に格納されているものとする。また、この承認依頼を受けた承認者ＰＣ４００は、該承認依頼の画面をポップアップ表示するものとする。また、他の承認者ＰＣによる承認等により、承認の必要がなくなった場合、この承認依頼画面は、操作情報管理ＰＣ１００からの指示により閉じられるものとする。さらに、各承認者も、図７に示した仮想ウィンドウ７０１で、操作対象ＰＣ３００の状態を把握可能であるので、各承認者は、操作対象ＰＣ３００の操作権限が与えられていなくても、操作対象ＰＣ３００の状態を把握して承認処理を行うことができる。

また、フローチャートには図示していないが、操作情報管理ＰＣ１００は、承認待ち操作依頼情報格納エリア６００にスプールしておいた、操作依頼情報の承認結果が出ると（受信すると）該承認結果が出た操作依頼情報の申請結果１５５内に承認結果を示す情報を付加して該操作依頼情報を操作依頼申請書ＤＢ１５０に格納する。

さらに、操作情報管理ＰＣ１００は、このタイミングで、図４に示した申請書１６０を作成してハードディスク１０５内に格納するとともに、該作成した申請書のファイル名を操作依頼情報内の申請書ファイル名１５６に格納する。なお、操作依頼申請書ＤＢ１５０への格納処理及び申請書１６０の作成処理のタイミングは、このタイミングに限られるものではない。例えば、後述する図５のステップＳ１３のタイミングであってもよい。

なお、ステップＳ６で承認が不要であると判定された操作依頼情報についても同様に操作依頼申請書ＤＢ１５０への格納処理及び申請書１６０の作成処理を行う。

以下、図５の説明に戻る。

そして、図５のステップＳ９において、ステップＳ２で行った操作申請に対応する操作の実行が承認されたか否かを判定し、承認されなかったと判定した場合には、そのままステップＳ１３に進む。

一方、図５のステップＳ９で、ステップＳ２で行った操作申請に対応する操作の実行が承認されたと判定した場合には、テップＳ１０に進む。

そして、ステップＳ１０において、操作待ちの操作の中で、本操作（ステップＳ９で承認された操作依頼情報、又はステップＳ６で承認が必要ないと判定された操作依頼情報に対応する操作）が原因で排他操作となってしまう操作依頼情報があるか否かを判定する。以下、この承認操作の排他検証手順を、図１３を参照して説明する。

図１３は、図５のステップＳ１０に示した承認操作の排他検証手順を詳細に示す図である。

図１３に示すように、操作情報管理ＰＣ１００は、ステップＳ１０において、ステップＳ９で承認されたと判定した操作依頼情報（又は、ステップＳ６で承認が必要ないと判定された操作依頼情報に対応する操作、即ち、操作対象ＰＣ３００への反映を行う操作依頼情報）に対応する操作を行うことにより、承認待ち操作依頼情報格納エリア６００に格納されている他の承認待ちの操作依頼情報が排他対象となるか否かの判定処理を行う。

この判定処理は、承認された操作依頼情報に対応する操作を実行した後でも、他の承認待ちの全操作依頼情報を問題無く実行することができる場合には「本操作が原因で排他操作となる承認待ちの操作依頼情報はない」と判定し、一方、承認された操作依頼情報に対応する操作を実行した後では、他の承認待ちの全操作依頼情報を問題無く実行することができなくなってしまう場合には「本操作が原因で排他操作となる承認待ちの操作依頼情報がある」と判定する。

例えば、図１３に示した例では、管理ＩＤ１のフォルダ削除「ｃ：￥ｔｅｍｐ￥ｔｅｍｐｌａｔｅ」が承認された場合、管理ＩＤ１のフォルダ削除「ｃ：￥ｔｅｍｐ￥ｔｅｍｐｌａｔｅ」を実行した後では、管理ＩＤ３のフォルダ作成「ｃ：￥ｔｅｍｐ￥ｔｅｍｐｌａｔｅ￥ＤＢ」を問題無く実行することができなくなってしまうため、「本操作が原因で排他操作となる承認待ちの操作依頼情報がある」と判定する。

以下、図５の説明に戻る。

そして、図５のステップＳ１０で、操作待ちの操作の中で、本操作（ステップＳ９で承認された操作依頼情報、又はステップＳ６で承認が必要ないと判定された操作依頼情報に対応する操作）が原因で排他操作となってしまう操作があると判定した場合には、ステップＳ１１に進み、操作待ちの操作の中で、本操作（ステップＳ９で承認された操作、又はステップＳ６で承認が必要ないと判定された操作依頼情報に対応する操作）が原因で排他操作となってしまう操作を依頼した個人端末２００に対して警告通知を行い、ステップＳ１２に進む。なお、この通知を受けた個人端末２００は、該警告通知をポップアップ表示するものとする。

一方、図５のステップＳ１０で、操作待ちの操作の中で、本操作（ステップＳ９で承認された操作、又はステップＳ６で承認が必要ないと判定された操作依頼情報に対応する操作）が原因で排他操作となってしまう操作がないと判定した場合には、そのまま図５のステップＳ１２に進む。

そして、図５のステップＳ１２において、操作内容を操作対象ＰＣ３００に反映し、ステップＳ１３に進む。以下、この操作内容の反映手順を、図１４を参照して説明する。

図１４は、図５のステップＳ１２に示した操作内容の反映手順を詳細に示す図である。

図１４に示すように、操作情報管理ＰＣ１００は、ステップＳ１２において、ステップＳ９で承認されたと判定した操作依頼情報、又はステップＳ６で承認の必要がないと判定された操作依頼情報に対応する操作内容の操作実行指示を操作対象ＰＣ３００に送信する。そして、この操作実行指示を受信した操作対象ＰＣ上で常駐するアプリケーションは、該操作指示に基づいて操作を行う。この時、操作対象ＰＣ３００が操作結果を操作情報管理ＰＣ１００に返送し、操作情報管理ＰＣ１００が該操作結果を取得するものとする。

これらの処理により、操作依頼申請に対応する操作内容を操作対象ＰＣ３００に反映させることができる。

以下、図５の説明に戻る。

そして、図５のステップＳ１３において、操作結果報告書の生成とＤＢ登録を行い、処理を終了する。以下、この操作結果報告書作成手順を、図１５を参照して説明する。

図１５は、図５のステップＳ１３に示した操作結果報告書作成手順を詳細に示す図である。

図１５に示すように、操作情報管理ＰＣ１００は、ステップＳ１３において、ステップＳ１２で操作内容の反映処理を行った操作依頼情報に対応する操作結果報告書（操作結果報告情報）を作成し、操作結果報告情報ＩＤを付して、ハードディスク１０５内に構築される操作結果報告書ＤＢ１５００に登録するとともに、該操作結果報告書をセキュリティ／ネットワーク管理者等の個人端末２００に送信する。

なお、この操作結果報告書ＤＢ１５００に登録された操作結果報告書は、個人端末２００から閲覧可能である。

また、セキュリティ／ネットワーク管理者等の個人端末２００のＩＰアドレス等は、予め設定されてハードディスク１０５に格納されているものとする。

さらに、操作情報管理ＰＣ１００は、操作結果報告書の操作結果報告書ＤＢ１５００への登録のタイミングで、操作結果に基づく情報を、操作依頼申請書ＤＢ１５０に登録された操作依頼情報内の申請結果１５５及び申請書１６０内の情報１６５に格納する。

以上の処理により、ＩＳＭＳ承認取得部門における情報処理装置の設定変更等の操作を行う場合において、操作の承認取得・操作結果等をログとして残す機能を実現することができる。

以下、図１６，図１７を参照して、本発明の管理システムにおけるＰＣ操作ワークフローを従来のＰＣ操作ワークフローと比較して説明する。

図１６，図１７は、本発明の管理システムにおけるＰＣ操作ワークフローを説明する模式図であり、図１６の（ａ），図１７の（ａ）は従来のＰＣ操作ワークフローを示し、図１６の（ｂ），図１７の（ｂ）は本発明のＰＣ操作ワークフローを示す。

まず、従来のＰＣ操作ワークフローでは、図１６の（ａ），図１７の（ａ）に示すように、ＰＣの操作を要求している人１６０１が、ＰＣの操作承認者１６０２に承認を貰う。この承認処理は、書類ベースで行われるため、非常に煩雑となる。

次に、ＰＣの操作を要求している人１６０１が操作対象ＰＣ３００を直接操作することはできないため、ＰＣの操作を要求している人１６０１は、ＰＣ管理者１６０３に操作を依頼する。

そして、ＰＣ管理者１６０３が、操作対象ＰＣ３００に対して１６０１の代理で操作を行う。なお、この時、操作依頼も書類ベースで行われているため、ＰＣ管理者１６０３に操作内容が正確に伝わらず、操作ミスが発生する可能性がある。

そして、ＰＣの操作を要求している人１６０１が、セキュリティ／ネットワーク管理者１６０４に操作結果を報告する。この報告も書類ベースで行われるため、書類管理も非常に煩雑である。

これに対して、本実施形態のＰＣ操作ワークフローでは、図１６の（ｂ），図１７の（ｂ）に示すように、ＰＣの操作を要求している人１６０１が、操作したいＰＣへの操作データ（操作依頼情報）を個人端末２００上で作成し、該作成した操作データ（操作依頼情報）を該個人端末２００から操作情報管理ＰＣ１００へ送信する。

すると、操作情報管理ＰＣ１００が、ＰＣの操作承認者１６０２の個人端末に承認確認を行い、承認されると、操作データ（操作指示）を操作対象ＰＣ３００に送信し、操作内容を操作対象ＰＣ３００に反映させる。

最後に、操作情報管理ＰＣ１００は、セキュリティ／ネットワーク管理者１６０４の個人端末に操作結果報告情報を送信する。

このように、本実施形態のＰＣ操作ワークフローでは、操作承認から操作ＰＣへの操作適用まで全てオンラインで行われる。

このように、手動で行う作業を、ＰＣの操作を要求している人１６０１による操作依頼情報の作成作業のみとし、その後の操作承認申請から操作結果報告を発行するまでの全てのプロセスを、操作情報管理ＰＣ１００による制御で自動化して、ＰＣ操作のワークフローを簡略化することができる。

また、操作対象ＰＣへの操作も、ＰＣの操作を要求している人１６０１本人により作成された（仮想画面７０１上での仮想操作により作成された）操作依頼情報に基づいて、操作情報管理ＰＣ１００の制御により行われるため、従来のＰＣ管理者１６０３が代理で行う場合のように、操作内容の誤解等により申請された操作と異なる操作が実行されることを防止でき、申請された操作内容を確実にＰＣに反映することができる。即ち、操作を依頼するユーザの操作に基づいて作成された操作依頼情報が、電子情報のまま実際のＰＣ操作に反映するため、操作内容の不変性が保証される。

また、操作依頼書等の承認書類を含めた全ての書類も、図７に示した仮想画面７０１上での仮想操作により自動作成されるため、書類作成の手間を大幅に簡略化することができる。また、操作依頼書等の管理も、操作情報管理ＰＣ１００の制御により操作依頼書ＤＢ１５０で管理されるので、書類管理の手間も大幅に簡略化することができる。

さらに、操作の承認条件も、操作情報管理ＰＣ１００の制御により操作内容に基づいて判定されるので、承認条件判定を簡略化できるとともに、承認効率を大幅に向上することができる。

また、操作依頼者に操作対象ＰＣ３００を直接操作させず、操作権限を付与するユーザを限定して、ＰＣの保守性を向上することができる。

また、図８に示したように先出の承認申請が許可されることを仮定して、個人端末２００より、関連した次の承認申請を受け付ける先行承認申請が可能となり、先出の承認申請の結果を待たずとも、次の承認申請を行うことができる。即ち、操作情報管理ＰＣ１００では、承認申請を複数受け付け可能であり、受け付けた承認申請をスプールする。

さらに、操作依頼者，承認者は、他の設定変更内容との排他関係を意識する必要なく操作申請，承認を行うことができる。なお、本実施形態において、排他とは、例えば先に未承認の「ｃ：￥ｔｅｍｐ削除」という操作申請が提出されており、その後に「ｃ：￥ｔｅｍｐのアクセス権限変更」という操作申請が提出された場合、先の操作申請が承認されるか否かによって、次の操作に影響を与える（実行不可能となってしまう）等というケースを指す。

また、申請者のユーザレベル（操作権限リスト９００）と操作内容（無承認操作可能権限リスト１１００）によっては、操作情報管理ＰＣ１００は、承認者の承認を得ずに操作の適用を行うため、承認条件判定が簡略化される。

さらに、個人端末２００において、操作依頼情報の生成を仮想ＯＳウインドウ７０１上で実行可能な為、実際に操作対象ＰＣを操作するのと同様の操作感の元で操作を行え、不慣れなユーザであっても、操作依頼情報の生成を容易に行うことができる。

以下、図１８〜図２０を参照して、本発明の情報処理装置管理システムにおける制御処理について説明する。

図１８は、本発明の情報処理装置管理システムにおける第１の制御処理手順の一例を示すフローチャートである。なお、このフローチャートの処理は、図１に示した操作対象ＰＣ３００上に常駐されるアプリケーションの処理に対応し、操作対象ＰＣ３００内の図示しないＣＰＵにより図示しない記録媒体（記憶媒体）に格納されるプログラムに基づいて実行される。また、Ｓ１０１〜Ｓ１０５は各ステップを示す。

まず、ステップＳ１０１において、個人端末２００からの操作対象ＰＣ情報取得要求を受信したか否かを判定し、個人端末２００からの操作対象ＰＣ情報取得要求を受信したと判定した場合には、ステップＳ１０２において、操作対象ＰＣ情報（操作対象ＰＣ３００自身のシステム構成情報）を要求した個人端末に送信し、ステップＳ１０３に進む。なお、このステップＳ１０２の処理の詳細は図６で示したのでここでは詳細な説明は省略する。

一方、ステップＳ１０１で、個人端末２００からの操作対象ＰＣ情報取得要求を受信していないと判定した場合には、そのままステップＳ１０３に進む。

次に、ステップＳ１０３において、操作情報管理ＰＣ１００からの操作実行指示を受信したか否かを判定し、操作情報管理ＰＣ１００からの操作実行指示を受信したと判定した場合には、ステップＳ１０４において、ステップＳ１０３で受信した操作実行指示に対応する操作を実行し、該実行結果を操作情報管理ＰＣ１００に送信し（Ｓ１０５）、ステップＳ１０１に戻る。なお、このステップＳ１０４の処理の詳細は図１４で示したのでここでは詳細な説明は省略する。

一方、ステップＳ１０３で、操作情報管理ＰＣ１００からの操作実行指示を受信していないと判定した場合には、そのままステップＳ１０１に戻る。

図１９は、本発明の情報処理装置管理システムにおける第２の制御処理手順の一例を示すフローチャートである。なお、このフローチャートの処理は、図１に示した個人端末２００上で実行されるアプリケーションの処理に対応し、個人端末２００内の図示しないＣＰＵにより図示しない記録媒体（記憶媒体）に格納されるプログラムに基づいて実行される。また、Ｓ２０１〜Ｓ２１２は各ステップを示す。

操作対象ＰＣが選択されると、処理を開始し、ステップＳ２０１において、選択された操作対象ＰＣ３００に操作対象ＰＣ情報取得要求を送信する。

そして、ステップＳ２０２において、操作対象ＰＣ３００からの操作対象ＰＣ情報を受信するまで待機し、受信したと判定した場合には、ステップＳ２０３において、操作依頼作成用の仮想ウィンドウ７０１（図７）を個人端末２００のモニタ７００上に表示する。

そして、ステップＳ２０４において、仮想ウィンドウ７０１への操作があったか否かを判定し、仮想ウィンドウ７０１への操作がなかったと判定した場合には、そのままステップＳ２１１に進む。

一方、ステップＳ２０４で、仮想ウィンドウ７０１への操作があったと判定した場合には、ステップＳ２０５において、該仮想ウィンドウ７０１への操作に基づいて操作依頼情報を作成し、ステップＳ２０６において、操作依頼情報を操作情報管理ＰＣ１００へ送信する。なお、このステップＳ２０１〜Ｓ２０６の処理の詳細は図６〜図８で示したのでここでは詳細な説明は省略する。

次に、ステップＳ２０７において、操作情報管理ＰＣ１００からの警告情報（図５のステップＳ５で通知される警告）を受信したか否かを判定し、警告情報を受信したと判定した場合には、ステップＳ２０８において、該受信した警告情報を個人端末２００のモニタ７００上に表示し、該当する操作依頼をキャンセルするか続行するかの入力を促す。

そして、ステップＳ２０９において、操作依頼をキャンセルする指示が入力されたか否かを判定し、操作依頼をキャンセルする指示が入力されたと判定した場合には、ステップＳ２１０において、ステップＳ２０４で行った仮想ウィンドウへの操作の解除処理を行い（ステップＳ２０４で行った操作前の状態に仮想ウィンドウを戻し）、ステップＳ２０４に移行する。

一方、ステップＳ２０９で、操作依頼をキャンセルする指示が入力されなかった（操作続行の指示が入力された）と判定した場合には、そのままステップＳ２０４に戻る。

一方、ステップＳ２０７で、操作情報管理ＰＣ１００からの警告情報を受信しなかったと判定した場合には、ステップＳ２１１において、ユーザからの終了操作があったか否かを判定し、終了操作がなかったと判定した場合には、ステップＳ２０４に戻る。

一方、ステップＳ２１１で、ユーザからの終了操作があったと判定した場合には、ステップＳ２１２において、操作依頼作成用の仮想ウィンドウ７０１を閉じ、処理を終了する。

図２０は、本発明の情報処理装置管理システムにおける第３の制御処理手順の一例を示すフローチャートである。なお、このフローチャートの処理は、図１に示した操作情報管理ＰＣ１００上に常駐されるアプリケーションの処理に対応し、図２に示した操作情報管理ＰＣ１００内のＣＰＵ１０１によりハードディスク１０５又は図示しない記録媒体（記憶媒体）に格納されるプログラムに基づいて実行される。また、Ｓ３０１〜Ｓ３１２は各ステップを示す。

まず、個人端末２００からの操作申請がある（操作依頼情報を受信する）と、ステップＳ３０１において、当該操作申請が適切な権限を有するユーザから出されたか否かの判定処理を行う。なお、このステップＳ３０１の処理の詳細は図９で示したのでここでは詳細な説明は省略する。

そして、ステップＳ３０１で、当該操作申請が適切な権限を有するユーザから出されたものでないと判定した場合には、そのままステップＳ３１２に進む。

一方、ステップＳ３０１で、当該操作申請が適切な権限を有するユーザから出されたものであると判定した場合には、ステップＳ３０２に進み、当該操作申請が他の申請内容と排他上の問題が無いかの判定処理を行う。

そして、ステップＳ３０２で、当該操作申請が他の申請内容と排他上の問題がないと判定した場合には、そのままステップＳ３０４に進む。

一方、ステップＳ３０２で、当該操作申請が他の申請内容と排他上の問題があると判定した場合には、ステップＳ３０３において、当該操作申請に対応する操作が排他対象操作であることを当該操作申請を行った個人端末２００に通知し、ステップＳ３０４に進む。なお、このステップＳ３０２，Ｓ３０３の処理の詳細は図１０で示したのでここでは詳細な説明は省略する。

次に、ステップＳ３０４において、当該操作申請が承認者の承認が必要な操作か否かを判定する。なお、このステップＳ３０４の処理の詳細は図１１で示したのでここでは詳細な説明は省略する。

そして、ステップＳ３０４で、当該操作申請に対応する操作が承認を要する操作でない（承認不要である）と判定した場合には、そのままステップＳ３０８に進む。

一方、ステップＳ３０４で、当該操作申請に対応する操作が承認を要する操作であると判定した場合には、ステップＳ３０５において、当該操作申請に対応する操作内容を承認者ＰＣ４００に送信し、ステップＳ３０６に進み、承認者ＰＣ４００から承認結果を受信するまで待機し、承認者ＰＣ４００から承認結果を受信したと判定した場合には、ステップＳ３０７に進む。なお、このステップＳ３０５，Ｓ３０６の処理の詳細は図１２で示したのでここでは詳細な説明は省略する。

そして、ステップＳ３０７において、当該操作申請に対応する操作の実行が承認されたか否かを判定し、承認されなかったと判定した場合には、そのままステップＳ３１２に進む。

一方、ステップＳ３０７で、当該操作申請に対応する操作の実行が承認されたと判定した場合には、テップＳ３０８に進み、操作待ちの操作の中で、当該操作申請に対応する操作が原因で排他操作となってしまう操作依頼情報があるか否かを判定する。なお、このステップＳ３０８の処理の詳細は図１３で示したのでここでは詳細な説明は省略する。

そして、ステップＳ３０８で、操作待ちの操作の中で、当該操作申請に対応する操作が原因で排他操作となってしまう操作があると判定した場合には、ステップＳ３０９に進み、操作待ちの操作の中で、当該操作申請に対応する操作が原因で排他操作となってしまう操作を依頼した個人端末２００に対して警告通知を行い、ステップＳ３１０に進む。

一方、ステップＳ３０８で、操作待ちの操作の中で、当該操作申請に対応する操作が原因で排他操作となってしまう操作がないと判定した場合には、そのままステップＳ３１０に進む。

そして、ステップＳ３１０において、操作内容の実行指示を操作対象ＰＣ３００に送信し、実行結果を操作対象ＰＣ３００から受信し（Ｓ３１１）、ステップＳ３１２に進む。なお、このステップＳ３１０，Ｓ３１１の処理の詳細は図１４で示したのでここでは詳細な説明は省略する。

そして、ステップＳ３１２において、操作結果報告書の生成とＤＢ登録を行い、処理を終了する。なお、このステップＳ３１２の処理の詳細は図１５で示したのでここでは詳細な説明は省略する。

なお、上記実施形態では、操作情報管理ＰＣ１００が、図４に示した申請書１６０を、操作依頼情報の操作依頼書ＤＢ１５０への登録時に生成する構成について説明したが、管理者等からの指示に応じて、操作情報管理ＰＣ１００が、操作依頼書ＤＢ１５０に基づいて図４に示した申請書１６０を作成するように構成してもよい。

また、図２では、操作情報管理ＰＣ１００のハードディスク１０５に、図３に示した操作依頼申請書ＤＢ１５０，図１５に示した操作結果報告書ＤＢ１５００が実装されている場合について示したが、図３に示した操作依頼申請書ＤＢ１５０，図１５に示した操作結果報告書ＤＢ１５００は、操作情報管理ＰＣ１００がネットワークを介して通信可能な他の情報処理装置上に実装されていてもよい。

さらに、図１では、１つの操作情報管理ＰＣ１００が１つの操作対象ＰＣ３００の操作情報を管理しているかのように示しているが、１つの操作情報管理ＰＣ１００が複数の操作対象ＰＣ３００の操作情報を管理するように構成してもよい。

また、本情報処理装置管理システム内に、操作情報管理ＰＣ１００が複数設けられていてもよい。

さらに、操作対象ＰＣ３００内に、操作情報管理ＰＣ１００の機能を実装するように構成してもよい。

また、操作対象ＰＣ３００内に、操作情報管理ＰＣ２００の機能を実装するように構成してもよい。

また、操作情報管理ＰＣ１００内に個人端末２００の操作依頼情報作成機能を実装するように構成してもよい。

また、個人端末２００は、操作対象ＰＣ３００から仮想ウィンドウ７０１を開くための情報を直接操作対象ＰＣ３００から取得する構成について説明したが、個人端末２００が、操作対象ＰＣ３００から仮想ウィンドウ７０１を開くための情報を操作情報管理ＰＣ１００から取得するように構成してもよい。この場合、操作情報管理ＰＣ１００は、操作対象ＰＣ３００のシステム構成情報を保持しており、操作実行指示する毎に更新している。

さらに、個人端末２００は、図７に示した仮想ウィンドウ７０１を表示して、該仮想ウィンドウ７０１をユーザに操作させることで、操作依頼情報を作成する構成について説明したが、操作対象ＰＣへの操作コマンドをコマンドラインで入力させて、操作依頼情報を作成するように構成してもよい。

また、本実施形態では、操作情報管理ＰＣ１００は、承認され実行可能な操作依頼を順次操作対象ＰＣ３００に実行指示するように構成されているが、フォルダ作成「ｃ：￥ａｂｃ」，フォルダ削除「ｃ：￥ａｂｃ」のような操作を行わなかった状態と同様の打ち消し合う操作内容の複数の操作依頼がスプールされており、且つ他の操作待ちの操作依頼に影響がない場合には、上記打ち消し合う複数の操作依頼を相殺して、操作対象ＰＣ３００に実行指示しないように制御するように構成してもよい。

さらに、操作情報管理ＰＣ１００は、フォルダ削除「ｃ：￥ａｂｃ」，ファイル削除「ｃ：￥ａｂｃ￥ｅｆｇ．ｘｙｚ」等の削除操作を実行指示する前に、該フォルダ，ファイルを作成指示したユーザの個人端末２００に、該フォルダ，ファイルの削除操作が依頼されている旨のメッセージを送信するように構成してもよい。この場合、単なる警告メッセージでもよいし、削除の可否を入力させ、該削除の可否の応答に基づいて、削除操作の実行の有無を制御するように構成してもよい。

また、ユーザは、フォルダ，ファイル等の作成操作を依頼する場合に、削除操作依頼がなされた場合の通知の有無の属性を入力し、該属性を操作依頼に含ませるように構成してもよい。なお、操作情報管理ＰＣ１００は、この属性に基づいて上記削除通知の送信の有無を制御する。

さらに、個人端末２００は、操作依頼情報の送信（申請）を、１つの操作毎に行うように構成してもよいし、複数の操作依頼情報をまとめて申請可能に構成してもよい。

また、個人端末２００は、操作依頼情報を作成するために、仮想ウィンドウ７０１上で操作を行った直後に、該仮想ウィンドウ７０１上での操作をＵｎｄｏ（取り消す）機能を備えていてもよい。なお、既に操作依頼情報が操作情報管理ＰＣ１００に送信（申請）された後は、該操作依頼情報を取り消す依頼を個人端末２００から操作情報管理ＰＣ１００に送信するものとする。

さらに、個人端末２００は、操作依頼情報の送信処理を、ユーザによる確認処理の後に行うように構成してもよい。

また、操作情報管理ＰＣ１００は、申請順に順次操作依頼を処理するようにしてもよいし、特定の権限以上のユーザからの操作依頼については、ユーザからの要求に基づいて割り込み処理可能に構成してもよい。

さらに、操作情報管理ＰＣ１００は、操作依頼をおこなったユーザ又は管理者権限を有するユーザからの要求に応じて、操作待ちの操作依頼をキャンセルするように構成してもよい。

なお、本発明の情報処理装置管理システムは、以下のような用途に利用可能である。

例えば、研修等を行う場合において、研修を受講する者達に、一時的にＰＣを貸与したとする。このような状況において、研修受講者達に管理者権限を付与するのは好ましくない。そのため、付与したＰＣに設定変更等を行う場合、本発明の情報処理装置管理システムを用いて、管理者がリモート経由で研修受講者達のＰＣの設定を更新して、研修受講者に一時的に貸与したＰＣの操作を管理するという用途である。

この場合、研修受講者達に付与されたＰＣは、本実施形態における操作対象ＰＣ３００となる。そして、管理者が「操作依頼者」となり、該管理者が使用するＰＣが個人端末２００となる。

また、研修受講者達自身が付与されたＰＣを使って、該ＰＣの設定変更を申請することも可能となる。この場合、研修受講者達のＰＣは、本実施形態における個人端末２００＋操作対象ＰＣ３００となる。そして、管理者が「承認者」となり、管理者の使用するＰＣが承認者ＰＣ４００となる。

これにより、新人研修等で研修受講者にＰＣを貸与する場合のよいうに、一時的にＰＣを貸与する場合、貸与を受ける側に管理者権限を与えることなく、管理者の管理下で操作を可能とする。

以上説明したように、本実施形態で示したシステムは、操作を行う際に承認手続きが必要なＰＣ（操作対象ＰＣ３００）への操作を行う場合の、承認申請から操作実行，操作結果報告までのワークフローを自動化する情報処理装置管理システムであり、ＩＳＭＳ承認取得部門等のサーバＰＣの設定変更等の操作を行う場合において発生する操作の承認取得・操作結果等のログを残す等の一連の定型的な申請プロセスを自動化することによって、諸手続きの簡略化や、申請書類作成・管理の負荷を軽減することができる。

〔第２実施形態〕
上記第１実施形態では、新たな申請内容が該新たな申請より前に申請された他の申請内容と排他上問題があると判定した場合には、前記新たな申請者に対して一様に警告を行う構成について説明したが、新たな申請内容が該新たな申請より前に申請された他の申請内容と排他上問題があると判定した場合でも、前記新たな申請者が第三者の操作申請を破棄することの出来る権限（一般権限より上の権限）を有する申請者である場合には、前記新たな申請内容を前記他の申請内容より優先可能となるように構成してもよい。以下、この実施形態について図２１，図２２を参照して説明する。

なお、本実施形態では、上記新たな申請者が第三者の操作申請を破棄することの出来る権限を、図９に示した操作権限リスト９００で特定される一般権限より上の権限とする。

図２１，図２２は、本発明の情報処理装置管理システムにおける第４の制御処理手順の一例を示すフローチャートである。なお、このフローチャートの処理は、本発明の第２実施形態において操作情報管理ＰＣ１００上に常駐されるアプリケーションの処理に対応し、図２に示した操作情報管理ＰＣ１００内のＣＰＵ１０１によりハードディスク１０５又は図示しない記録媒体（記憶媒体）に格納されるプログラムに基づいて実行される。また、Ｓ３０１〜Ｓ３２２は各ステップを示す。さらに、図２０と同一のステップには同一のステップ番号を付してある。

ステップＳ３０２において、ＣＰＵ１０１は、当該操作申請が当該操作申請より前に申請された他の申請内容と排他上の問題があると判定した場合には、ステップＳ３１３において、当該操作申請の申請者の権限を図９に示した操作権限リスト９００に基づいて判定する。

ステップＳ３１３で、ＣＰＵ１０１が、当該操作申請の申請者の権限が一般権限であると判定した場合には、ステップＳ３０３に進み、当該操作申請に対応する操作が排他対象操作である旨を当該操作申請を行った個人端末２００に通知する。

一方、ステップＳ３１３において、ＣＰＵ１０１が、当該操作申請の申請者の権限が一般権限より上であると判定した場合には、ステップＳ３１４（図２２）に進む。

次に、ステップＳ３１４において、ＣＰＵ１０１は、取り消し対象操作となる前記他の申請の申請元に、操作申請の取り消し依頼通知を発行し、ステップＳ３１５において、依頼した操作申請取り消しの返答を一定時間待機する。

ステップＳ３１５で、ＣＰＵ１０１が、一定時間が経過したと判定した場合には、返答があるか否かに関わらずステップＳ３１６に進み、取り消し依頼結果を判定する。

ステップＳ３１６で、ＣＰＵ１０１が、取り消し対象操作の申請元で操作申請取り消し依頼が受諾されなかったと判定した場合には、ステップＳ３１７において、申請取り消し付加の為、当該操作が排他対象操作である旨を当該操作申請を行った個人端末２００に通知し、ステップＳ３０４に処理を進める。

また、ステップＳ３１６で、ＣＰＵ１０１が、取り消し対象操作の申請元で操作申請取り消し依頼が受諾されたと判定した場合には、ステップＳ３２２において、取り消し対象操作の申請の取り消しを行い、ステップＳ３０４に処理を進める。

さらに、ステップＳ３１６で、ＣＰＵ１０１が、取り消し対象操作の申請元から回答がなかったと判定した場合には、当人に代わって操作承認者に操作取り消し判定を行わせるために、ステップＳ３１８に処理を進める。

そして、ステップＳ３１８において、ＣＰＵ１０１は、取り消し対象操作の取り消し判定の依頼を承認者ＰＣ４００に送信し、ステップＳ３１９に進み、承認者ＰＣ４００から承認結果を受信するまで待機し、承認者ＰＣ４００から承認結果を受信したと判定した場合には、ステップＳ３２０に進む。

ステップＳ３２０において、ＣＰＵ１０１は、取り消し対象操作の取り消し判定依頼の結果を判定し、承認者ＰＣ４００により取り消し依頼が受託されなかったと判定した場合には、ステップＳ３１７に進む。

一方、ステップＳ３２０で、ＣＰＵ１０１が、承認者ＰＣ４００により取り消し依頼が受託されたと判定した場合には、ステップＳ３２１に進み、取り消し対象操作の申請者に取り消しの旨の通知を発行すると共に、ステップＳ３２２において、取り消し対象操作の申請の取り消しを行い、ステップＳ３０４に処理を進める。

以上の処理により、新たな申請内容が該新たな申請より前に申請された他の申請内容と排他上問題がある場合でも、前記新たな申請内容の申請者が第三者の操作申請を破棄することの出来る権限（一般権限より上の権限）を有する申請者である場合には、前記新たな申請内容を前記他の申請内容より優先させることができ、申請者の権限に応じたフレキシブルな申請処理を行うことができる。

なお、本実施形態では、申請された操作依頼情報と該操作依頼情報より前に申請された他の操作依頼情報との関係が排他関係であると判定された場合、該申請者の操作権限が一般権限より上の場合には、前記他の申請情報の取り消しを依頼し、取り消し依頼結果に応じて、前記他の申請情報を取り消す（前記他の申請情報を拒否する）構成について説明したが、申請された操作依頼情報と該操作依頼情報より前に申請された他の操作依頼情報との関係が排他関係であると判定された場合、該申請者の操作権限が前記他の申請情報の申請者の操作権限より上の場合には、前記他の申請情報を強制的に取り消し（前記他の申請情報を強制的に拒否し）、該取り消した旨の通知を前記他の申請情報の申請者に行うように構成してもよい。

〔第３実施形態〕
上記第１実施形態では、操作依頼を管理・制御する構成について説明したが、操作依頼申請書ＤＢ１５０に格納される操作依頼と操作結果報告書ＤＢ１５００に格納される操作結果を元に操作対象ＰＣ３００の監査を行う機能（自動監査機能）を設けるように構成してもよい。以下、その実施形態について説明する。

まず、上記自動監査機能を実行する前に、管理者は操作対象ＰＣ３００の監査を開始する準備として、該操作対象ＰＣ３００の監査開始状態を保存しておく必要がある。

以下、図２３を参照して、操作対象ＰＣ３００の監査開始状態を保存する処理（監査ステータス保存処理）について説明する。

図２３は、本発明の情報処理装置管理システムにおける第５の制御処理手順の一例を示すフローチャートである。なお、このフローチャートの処理は、本発明の第３実施形態において操作情報管理ＰＣ１００上に常駐されるアプリケーションの処理に対応し、図２に示した操作情報管理ＰＣ１００内のＣＰＵ１０１によりハードディスク１０５又は図示しない記録媒体（記憶媒体）に格納されるプログラムに基づいて実行される。また、Ｓ４０１，Ｓ４０２は各ステップを示す。

図示しない認証処理により管理者等が操作していることが認証された個人端末２００より操作対象ＰＣ３００が選択され、監査の開始が指示されたことが通知されると、処理を開始し、ステップＳ４０１において、ＣＰＵ１０１は、選択された操作対象ＰＣ３００に操作対象ＰＣの状態情報の取得要求を送信し、操作対象ＰＣ３００から送信される操作対象ＰＣの状態情報（操作対象ＰＣ３００のディレクトリ構成，ファイル構成等のファイル管理情報を含むこの時点での操作対象ＰＣ３００の全ての状態情報）を監査開始状態として受信する。

次に、ステップＳ４０２において、ＣＰＵ１０１は、ステップＳ４０１で受信した操作対象ＰＣ３００の監査開始状態から操作対象ＰＣの状態を仮想的に構築したオブジェクトである「監査ステータス」を生成し、ハードディスク１０５に保存し、処理を終了する。

以下、図２４のフローチャートを参照して、操作依頼情報と操作結果情報を元に操作対象ＰＣの監査を行う機能（自動監査処理）について説明する。

図２４は、本発明の情報処理装置管理システムにおける第６の制御処理手順の一例を示すフローチャートである。なお、このフローチャートの処理は、本発明の第３実施形態において操作情報管理ＰＣ１００上に常駐されるアプリケーションの処理に対応し、図２に示した操作情報管理ＰＣ１００内のＣＰＵ１０１によりハードディスク１０５又は図示しない記録媒体（記憶媒体）に格納されるプログラムに基づいて実行される。また、Ｓ２−１〜Ｓ２−１２は各ステップを示す。

図示しない認証処理により管理者等が操作していることが認証された個人端末２００より操作対象ＰＣ３００が選択され、監査処理の実行が指示されたことが通知されると、処理を開始し、ステップＳ２−１において、ＣＰＵ１０１は、選択された操作対象ＰＣ３００の監査ステータスをハードディスク１０５から取得し、メモリ１０２上に保持する。

次に、ステップＳ２−２において、ＣＰＵ１０１は、操作依頼申請書ＤＢから操作対象ＰＣ３００の操作依頼情報を取得し、ステップＳ２−３において、操作結果報告書ＤＢ１５００から、操作対象ＰＣ３００の操作結果報告情報を取得し、それぞれメモリ１０２上に保持する。なお、ステップＳ２−２では、初回処理時（ループの１周目の処理時）は監査開始後初めて発行された操作依頼情報（監査開始後で発行年月日が最も古い操作依頼情報）を、２回目以降の処理時（ループの２周目以降の処理時）は、監査開始後２回目以降に発行された操作依頼情報を発行年月日の古い順に取得する。また、同様にステップＳ２−３で操作結果報告情報を取得する。

以下、操作結果報告書ＤＢ１５００の構成を示す。

図２５は、図１に示した操作結果報告書ＤＢ１５００のレコード構成を示す模式図である。

図２５に示すように、操作結果報告書ＤＢ１５００は、操作結果報告情報ＩＤ（ＩＤ）１５０１、操作依頼申請申請書１５０２、操作実行日１５０３、捜査結果１５０４等から構成される。

操作結果報告情報ＩＤ（ＩＤ）１５０１は、操作情報管理ＰＣ１００において申請内容の実行順に順次付与される番号を示す。操作依頼申請書ＩＤ１５０２は、本操作を行う為の操作依頼申請書ＤＢの操作依頼申請ＩＤ（ＩＤ）１５１の番号を示す。操作実行日１５０２は、操作対象ＰＣ３００において操作が実行された日付に対応する。操作結果１５０４は、実際に操作が行われた内容を示す作業記録（例えば、「指定ディレクトリの作成を行った。指定ディレクトリ作成後、アクセス可否の検証を行った。」），実際に操作を行った後の操作対象ＰＣ３００の状態、作業の終了ステータス（正常/異常）の情報を含む。

以下、図２４のフローチャートの説明に戻る。

次に、ステップＳ２−４において、ＣＰＵ１０１は、ステップＳ２−２で取得した操作依頼情報とステップＳ２−３で取得した操作結果報告情報の内容を比較し、操作依頼と操作結果の整合性を検証する。

そして、ステップＳ２−４で、ＣＰＵ１０１が、検証結果が「整合」であると判定した場合には、そのままステップＳ２−６に処理を進める。

一方、ステップＳ２−４で、ＣＰＵ１０１が、検証結果が「不整合」であると判定した場合には、ステップＳ２−５において、ＣＰＵ１０１は、ステップＳ２−２で取得した操作依頼情報とステップＳ２−３で取得した操作結果報告情報の内容に不整合がある旨を監査結果ＤＢ（図２６に示す）に登録し（図２６の２６０１）、ステップＳ２−６に処理を進める。

上記監査結果ＤＢとは、操作依頼情報と操作結果情報を元に操作対象ＰＣの監査を行った結果に露見した不具合情報を一時的に保持しておく領域であり、メモリ１０２又はハードディスク１０５内に確保され、後述する図２７に示す監査結果報告書を作成する時に参照される。なお、テーブル内容については、以下、図２６に示す。

図２６は、図１に示したメモリ１０２又はハードディスク１０５内に保持される監査結果ＤＢの監査結果テーブル及び整合種別テーブルの構成を示す模式図である。

図２６に示すように、監査結果ＤＢの監査結果テーブルは、操作依頼情報ＩＤ（図３に示した操作管理番号１５１に対応する），操作結果報告情報ＩＤ，整合ＩＤ等から構成される。

なお、整合ＩＤが「−１」の場合は、操作依頼と操作結果が不整合であることを示し、整合ＩＤが「−２」の場合は、監査ステータス状態と操作結果が不整合であることを示し、整合ＩＤが「−３」の場合は、監査ステータス状態と操作対象ＰＣの状態が不整合であることを示す。

以下、図２４のフローチャートの説明に戻る。

次に、ステップＳ２−６において、ＣＰＵ１０１は、監査ステータスに対して、ステップＳ２−２で取得した操作依頼情報の内容を反映し、ステップＳ２−７において、ＣＰＵ１０１は、ステップＳ２−６での反映結果とステップＳ２−３で取得した操作結果報告情報の内容を比較し、反映結果と操作結果の整合性を検証する。

そして、ステップＳ２−７で、ＣＰＵ１０１が、検証結果が「整合」であると判定した場合には、そのままステップＳ２−９に処理を進める。

一方、ステップＳ２−７で、ＣＰＵ１０１が、検証結果が「不整合」であると判定した場合には、ステップＳ２−８において、ＣＰＵ１０１は、ステップＳ２−６での反映結果（即ち、ステップＳ２−２で取得した操作依頼情報により更新された「監査ステータス」）とステップＳ２−３で取得した操作結果報告情報の内容に不整合がある旨を監査結果ＤＢに登録し（図２６の２６０２）、ステップＳ２−９に処理を進める。

次に、ステップＳ２−９において、ＣＰＵ１０１は、ステップＳ２−２で取得する操作依頼情報とステップＳ２−３で取得する操作結果報告情報が双方共に残件数があるか否かを判定し、残件があると判定した場合には、処理をステップＳ２−２へ戻し、ステップＳ２−２以降の処理を繰り返す。

一方、ステップＳ２−９で、ＣＰＵ１０１が、ステップＳ２−２で取得する操作依頼情報とステップＳ２−３で取得する操作結果報告情報が双方共に残件数がないと判定した場合には、ステップＳ２−１０に処理を進める。

次に、ステップＳ２−１０において、ＣＰＵ１０１は、操作対象ＰＣに操作対象ＰＣの状態情報の取得要求を送信して、操作対象ＰＣ３００から返信される操作対象ＰＣの状態情報（操作対象ＰＣ３００のディレクトリ構成，ファイル構成等のファイル管理情報を含むこの時点での操作対象ＰＣの全ての状態情報）を取得し、該取得した操作対象ＰＣ３００とステップＳ２−２〜Ｓ２−９の処理により最終的に更新された操作対象ＰＣ３００の監査ステータスとのを比較し、整合性を検証する。

そして、ステップＳ２−１０で、ＣＰＵ１０１が、検証結果が「整合」であると判定した場合には、そのままステップＳ２−１２に処理を進める。

一方、ステップＳ２−１０で、ＣＰＵ１０１が、検証結果が「不整合」であると判定した場合には、ステップＳ２−１１において、ＣＰＵ１０１は、ステップＳ２−１０で検証した監査ステータスと操作対象ＰＣ３００の状態の差異を監査結果ＤＢに登録し（図２６の２６０３）、ステップＳ２−１２に処理を進める。

次に、ステップＳ２−１２において、ＣＰＵ１０１は、監査結果ＤＢの内容を元に図２７に示す監査結果報告書を作成し、ハードディスク１０５に格納するとともに、当該監査処理を指示した個人端末２００に送信して個人端末２００のモニタ７００に表示させ、処理を終了する。

図２７は、図２４のステップＳ２−１２で作成される監査結果報告書の一例を示す模式図である。

図２７に示す報告書１６００は、操作情報管理ＰＣ１００による操作依頼申請情報の操作依頼申請書ＤＢ１５０への登録内容と、操作対象ＰＣ３００による捜査結果情報の捜査結果報告書ＤＢ１５００への登録内容や、現在の操作対象ＰＣ３００の状態を比較した結果に基づいて、操作情報管理ＰＣ１００により作成され、ハードディスク１０５内に格納されるものとする。

図２７において、１６０１は監査日で、図２５に示した操作結果報告書ＤＢ１５００内の操作実行日１５０４から生成される。

また、１６０２は監査責任者，社員番号，所属部署ｏｒ会社名で、個人端末２００から監査実行を指示した時のユーザ情報に基づいて生成される。

さらに、１６０３は対象部門，対象サーバ，監査理由，監査対象資源，監査対象期間，備考等の情報で、個人端末２００から監査実行を指示すると共に入力される。

１６０４は監査開始日付，監査終了日付，監査所要時間で、操作情報管理ＰＣ１００が、監査を開始した時間,監査を終了した時間、監査に要した時間に基づいて生成される。１６０５は監査結果で、図３に示した操作依頼申請書ＤＢ１５０と図２５に示した操作結果報告書ＤＢ１５００内の差異等に基づいて生成される。

以上の処理により、管理者等が監査の指示を行うだけで、操作依頼申請書ＤＢ１５０に格納される操作依頼と操作結果報告書ＤＢ１５００に格納される操作結果を元に操作対象ＰＣ３００の監査を人手を介することなく行うことができ、監査作業を効率化することができる。

なお、本実施形態では、監査処理の際に、不整合の場合のみ、監査結果ＤＢに登録する構成について説明したが、整合，不整合の双方の場合を、監査結果ＤＢに登録するように構成してもよい。以下、整合，不整合の双方の場合が登録された監査結果ＤＢを図２８に示す。

図２８は、図１に示したメモリ１０２又はハードディスク１０５内に保持される監査結果ＤＢの監査結果テーブル及び整合種別テーブルの構成を示す模式図であり、整合，不整合の双方の場合が登録された場合に対応する。

図２８に示すように、整合ＩＤが「０」の場合は、操作依頼と操作結果が整合であることを示し、整合ＩＤが「１」の場合は、監査ステータス状態と操作結果が整合であることを示し、整合ＩＤが「２」の場合は、監査ステータス状態と操作対象ＰＣの状態が整合であることを示す。

また、整合ＩＤが「−１」の場合は、操作依頼と操作結果が不整合であることを示し、整合ＩＤが「−２」の場合は、監査ステータス状態と操作結果が不整合であることを示し、整合ＩＤが「−３」の場合は、監査ステータス状態と操作対象ＰＣの状態が不整合であることを示す。

〔第４実施形態〕
上記第１実施形態では、操作依頼を管理・制御する構成について説明したが、操作依頼申請書ＤＢ１５０に格納される操作依頼と操作結果報告書ＤＢ１５００に格納される操作結果を元に操作対象ＰＣ３００の過去の状況を参照する機能（過去状況参照機能）を設けるように構成してもよい。以下、その実施形態について説明する。

まず、上記過去状況参照機能を実行する前に、管理者は操作対象ＰＣの操作開始準備として、該操作対象ＰＣの操作開始状態を保存しておく必要がある。

以下、図２９を参照して、操作対象ＰＣ３００の操作開始状態を保存する処理（操作ステータス保存処理）について説明する。

図２９は、本発明の情報処理装置管理システムにおける第７の制御処理手順の一例を示すフローチャートである。なお、このフローチャートの処理は、本発明の第４実施形態において操作情報管理ＰＣ１００上に常駐されるアプリケーションの処理に対応し、図２に示した操作情報管理ＰＣ１００内のＣＰＵ１０１によりハードディスク１０５又は図示しない記録媒体（記憶媒体）に格納されるプログラムに基づいて実行される。また、Ｓ５０１，Ｓ５０２は各ステップを示す。

図示しない認証処理により管理者等が操作していることが認証された個人端末２００より操作対象ＰＣが選択され、操作の開始が指示されたことが通知されると、処理を開始し、ステップＳ５０１において、ＣＰＵ１０１は、選択された操作対象ＰＣ３００に操作対象ＰＣ３００の状態情報の取得要求を送信し、操作対象ＰＣ３００から送信される操作対象ＰＣ３００の状態情報（操作対象ＰＣ３００のディレクトリ構成，ファイル構成等のファイル管理情報を含むこの時点での操作対象ＰＣ３００の全ての状態情報）を操作開始状態として受信する。

次に、ステップＳ５０２において、ＣＰＵ１０１は、ステップＳ５０１で受信した操作対象ＰＣ３００の操作開始状態から操作対象ＰＣの状態を仮想的に構築したオブジェクトである「操作ステータス」を生成し、ハードディスク１０５に保存し、処理を終了する。

以下、図３０のフローチャートを参照して、操作依頼情報と操作結果情報を元に操作対象ＰＣの過去の状況を参照する機能（過去状況参照処理）について説明する。

図３０は、本発明の情報処理装置管理システムにおける第８の制御処理手順の一例を示すフローチャートである。なお、このフローチャートの処理は、本発明の第４実施形態において操作情報管理ＰＣ１００上に常駐されるアプリケーションの処理に対応し、図２に示した操作情報管理ＰＣ１００内のＣＰＵ１０１によりハードディスク１０５又は図示しない記録媒体（記憶媒体）に格納されるプログラムに基づいて実行される。また、Ｓ３−１〜Ｓ３−９は各ステップを示す。

個人端末２００より操作対象ＰＣ３００が選択され、操作状況参照処理の実行が指示されたことが通知されると、処理を開始し、ステップＳ３−１において、ＣＰＵ１０１は、選択された操作対象ＰＣ３００の操作ステータスをハードディスク１０５から取得し、メモリ１０２上に保持する。

次に、ステップＳ３−２において、ＣＰＵ１０１は、操作対象ＰＣ３００の状態参照日時を過去状況参照処理を指示した個人端末２００より取得する。

次に、ステップＳ３−３において、ＣＰＵ１０１は、操作依頼申請書ＤＢから操作対象ＰＣ３００の操作依頼情報を取得し、ステップＳ３−４において、操作結果報告書ＤＢ１５００から、操作対象ＰＣ３００の操作結果報告情報を取得し、それぞれメモリ１０２上に保持する。なお、ステップＳ３−３では、初回処理時（ループの１周目の処理時）は操作開始後初めて発行された操作依頼情報（操作開始後で発行年月日が最も古い操作依頼情報）を、２回目以降の処理時（ループの２周目以降の処理時）は、操作開始後２回目以降に発行された操作依頼情報を発行年月日の古い順に取得する。また、同様にステップＳ３−４で操作結果報告情報を取得する。

次に、ステップＳ３−５において、ＣＰＵ１０１は、ステップＳ３−４で取得した操作結果報告情報を参照し、ステップＳ３−３で取得した操作依頼情報が操作対象ＰＣ３００に操作適用されたかどうかを判断する。なお、この判断は、操作が承認者によって否認されている場合等がある為に行われる。

ステップＳ３―５で、ＣＰＵ１０１が、ステップＳ３−３で取得した操作依頼が操作対象ＰＣ３００に操作適用されていると判定した場合には、ステップＳ３−６において、ＣＰＵ１０１は、操作ステータスに操作依頼内容を反映し、ステップＳ３−７に処理を移行させる。

一方、ステップＳ３―５で、ＣＰＵ１０１が、ステップＳ３−３で取得した操作依頼が操作対象ＰＣ３００に操作適用されていないと判定した場合には、そのままステップＳ３−７に処理を移行させる。

次に、ステップＳ３−７において、ＣＰＵ１０１は、ステップＳ３−３で取得する操作依頼情報とステップＳ３−４で取得する操作結果報告情報が双方共に残件数が有るか否かを判定し、残件があると判定した場合には、ステップＳ３−３に処理を戻し、ステップＳ３−３以降の処理を繰り返す。

一方、ステップＳ３−７で、ＣＰＵ１０１が、ステップＳ３−３で取得する操作依頼情報とステップＳ３−４で取得する操作結果報告情報が双方共に残件数が無いと判定した場合には、ステップＳ３−８に処理を進める。

そして、ステップＳ３−８において、ＣＰＵ１０１は、ステップＳ３−３〜Ｓ３−７の処理により最終的に更新された操作対象ＰＣの操作ステータスに基づいて、操作対象ＰＣ３００の仮想ＵＩを構築するとともに、該仮想ＵＩの状態参照日時を「表示ステータスの状態日時」としてメモリ１０２又はハードディスク１０５に格納する。

そして、ステップＳ３−９において、ＣＰＵ１０１は、ステップＳ３−８で構築された操作対象ＰＣ３００の仮想ＵＩ画面（図３１に示す）を当該過去状況参照処理を指示した個人端末２００に送信して個人端末２００のモニタ７００に表示させ、処理を終了する。

図３１は、図３０のステップＳ３−９で個人端末２００のモニタ７００に表示される操作対象ＰＣ３００の仮想ＵＩ画面の一例を示す模式図である。

図３１に示す仮想ＵＩ画面３１０１上でユーザは、操作対象ＰＣ３００上で実際に行うのと同様の操作を行うことができ、この仮想ＵＩ画面３１０１上で操作を行うことにより、操作対象ＰＣ３００の過去状況を参照することができる。

また、この仮想ＵＩ３１０１において、３１０２は表示デスクトップ日時で、「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」を示す。この表示デスクトップ日時３１０２は、個人端末２００の図示しないポインティングデバイス及びキーボード等により直接、所望の日時を入力することにより変更可能である。また、表示デスクトップ日時３１０２は、個人端末２００の図示しないポインティングデバイスにより、３１０３，３１０４を指示することによっても変更可能である。この表示デスクトップ日時３１０２の変更が行われると、該変更された表示デスクトップ日時３１０２は、「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」として個人端末２００から操作情報管理ＰＣ１００に送信され、該送信された「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」に対応する新たな仮想ＵＩ画面が操作情報管理ＰＣ１００で生成され個人端末２００に返信される（仮想ＵＩ表示日時切り替え処理）。以下、この仮想ＵＩ表示日時切り替え処理を図３２に示す。

図３２は、本発明の情報処理装置管理システムにおける第９の制御処理手順の一例を示すフローチャートである。なお、このフローチャートの処理は、本発明の第４実施形態において操作情報管理ＰＣ１００上に常駐されるアプリケーションの処理に対応し、図２に示した操作情報管理ＰＣ１００内のＣＰＵ１０１によりハードディスク１０５又は図示しない記録媒体（記憶媒体）に格納されるプログラムに基づいて実行される。また、Ｓ６０１〜Ｓ６１１は各ステップを示す。

まず、個人端末２００より送信された「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」を受信すると、処理を開始し、ステップＳ６０１において、ＣＰＵ１０１は、受信した「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」を取得する。

次に、ステップＳ６０２において、ＣＰＵ１０１は，「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」と「表示ステータスの状態日時」とを比較し、「表示ステータスの状態日時」のほうが「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」より新しいと判定した場合には、ステップＳ６０３に進む。

ステップＳ６０３，Ｓ６０４において、ＣＰＵ１０１は、「表示ステータスの状態日時」以前で、且つ、「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」以後の最も新しい操作依頼情報，操作結果報告情報を取得し、ステップＳ６０５に処理を進める。なお、フローチャート中には示していないが、ステップＳ６０３，Ｓ６０４で、「表示ステータスの状態日時」以前で、且つ、「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」以後の最も新しい操作依頼情報，操作結果報告情報が存在しなかった場合には、「表示ステータスの状態日時」を「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」に更新し、ステップＳ６０２の処理に戻すものとする。

次に、ステップＳ６０５において、ＣＰＵ１０１は、ステップＳ６０４で取得した操作結果報告情報を参照し、ステップＳ６０３で取得した操作依頼情報が操作対象ＰＣに操作適用されたかどうかを判断し、操作適用されたと判定した場合には、ステップＳ６０６において、ＣＰＵ１０１は、操作ステータスから操作依頼内容の反映を削除するとともに、「表示ステータスの状態日時」をステップＳ６０３で取得した操作依頼情報の日時に更新し、ステップＳ６０２に処理を戻し、「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」と「表示ステータスの状態日時」との日時が等しくなるまで、ステップＳ６０３〜Ｓ６０６の処理を繰り返す。

一方、ステップＳ６０５で、ＣＰＵ１０１が、ステップＳ６０３で取得した操作依頼情報が操作対象ＰＣに操作適用されなかったと判定した場合には、「表示ステータスの状態日時」をステップＳ６０３で取得した操作依頼情報の日時に更新し、ステップＳ６０２に処理を戻す。

また、ステップＳ６０２で、ＣＰＵ１０１が，「表示ステータスの状態日時」のほうが「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」より古いと判定した場合には、ステップＳ６０７に処理を進める。

ステップＳ６０７，Ｓ６０８において、ＣＰＵ１０１は、「表示ステータスの状態日時」以後で、且つ、「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」以前の最も古い操作依頼情報，操作結果報告情報を取得し、ステップＳ６０９に処理を進める。なお、フローチャート中には示していないが、ステップＳ６０７，Ｓ６０８で、「表示ステータスの状態日時」以後で、且つ、「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」以前の最も古い操作依頼情報，操作結果報告情報が存在しなかった場合には、「表示ステータスの状態日時」を「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」に更新し、ステップＳ６０２の処理に戻すものとする。

次に、ステップＳ６０９において、ＣＰＵ１０１は、ステップＳ６０８で取得した操作結果報告情報を参照し、ステップＳ６０７で取得した操作依頼情報が操作対象ＰＣに操作適用されたかどうかを判断し、操作適用されたと判定した場合には、ステップＳ６１０において、ＣＰＵ１０１は、操作ステータスに操作依頼内容を反映させるとともに、「表示ステータスの状態日時」をステップＳ６０７で取得した操作依頼情報の日時に更新し、ステップＳ６０２に処理を戻し、「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」と「表示ステータスの状態日時」とが等しくなるまで、ステップＳ６０７〜Ｓ６１０の処理を繰り返す。

一方、ステップＳ６０９で、ＣＰＵ１０１が、ステップＳ６０７で取得した操作依頼情報が操作対象ＰＣに操作適用されなかったと判定した場合には、「表示ステータスの状態日時」をステップＳ６０７で取得した操作依頼情報の日時に更新し、ステップＳ６０２に処理を戻す。

また、ステップＳ６０２で、ＣＰＵ１０１が，「表示ステータスの状態日時」と「仮想ＵＩ画面に表示する操作対象ＰＣの状態日時」とが等しいと判定した場合には、ステップＳ６１１において、ＣＰＵ１０１は、操作ステータスに基づいて、操作対象ＰＣの仮想ＵＩを構築するとともに、該構築した操作対象ＰＣの仮想ＵＩ画面を個人端末２００に送信して個人端末２００のモニタ７００に表示させ、処理を終了する。

以上の処理により、操作対象ＰＣの状態参照日時の指示を行うだけで、操作依頼申請書ＤＢ１５０に格納される操作依頼と操作結果報告情報書ＤＢ１５００に格納される操作結果を元に操作対象ＰＣの過去の状態を容易に参照することができる。

なお、本実施形態では、所定の時点での操作ステータスを保存しておき、該保存された所定の時点での操作ステータスに対して、操作依頼情報と該操作結果報告情報に基づく操作を反映させて、操作対象ＰＣの過去の状態を仮想的操作可能に再現する構成について説明したが、過去状況参照時点での操作対象ＰＣの状態から操作ステータスを生成し、該生成された操作ステータスから、操作依頼情報と該操作結果報告情報に基づく操作の反映を削除して、操作対象ＰＣの過去の状態を仮想的操作可能に再現するように構成してもよい。

また、図７に示した操作依頼情報の作成画面（仮想ウィンドウ）７０１上での操作では、操作対象ＰＣ内に保存される各ファイル内の変更操作も可能であり、そして、この仮想ウィンドウ７０１上でのファイル内の変更操作により生成される操作依頼情報には、前記操作対象ＰＣ内に保存される各ファイル内の変更の依頼も含まれるものであり（即ち、操作結果報告情報にも操作対象ＰＣ内に保存される各ファイル内の変更の操作結果が含まれ）、該操作依頼情報と該操作結果報告情報に基づく操作を反映させて、操作対象ＰＣの過去のファイルの内容をも全て復元することができる。

なお、各実施形態の各変形例の全て又はいずれか複数を組み合わせた構成も全て本発明に含まれるものである。

また、図示した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

以下、背景技術の欄で示した特許文献１と、本実施形態で示した情報処理装置管理システムとの相違について説明する。

特許文献１は、管理者の承認を必要とするデータを更新する為の承認プロセスを自動化したものであり、管理者の承認を受けたことを条件としてデータ更新を許可する監視条件付きのデータ更新を実現することができると共に、承認要請の自動化を実現することが記載されている。

これに対して、本実施形態に示す情報処理装置管理システムでは、ＩＳＭＳ承認取得部門においてサーバ等の情報処理装置の設定変更等の操作を行う場合の操作の承認取得・操作結果等をログとして残す等の定型的な申請プロセスを自動化したものであり、まずこの点において、単にデータの更新の承認を管理するものとは大きく異なる。

即ち、上記特許文献１の目的は、単にデータの更新の際の承認と承認を受けた際の更新処理を自動化するだけで、その承認取得・処理結果等をログとして記憶管理するものではなく、このようなログ管理構成については何ら記載されていない。よって、上記特許文献１のデータ更新を情報処理装置への操作と置き換えても、本実施形態の情報処理装置管理システムを構成することはできない。

本実施形態の情報処理装置管理システムでは、上記ログ管理構成を備えているため、ＩＳＭＳ承認取得部門においてサーバ等の情報処理装置の設定変更等の操作を行う場合の操作の承認取得・操作結果等をログとして残す等の定型的な申請プロセスを自動化するだけでなく、ＩＳＭＳ承認取得部門において定められた承認書類の作成，管理を行うことができる。

また、本実施形態の情報処理装置管理システムでは、申請された操作依頼と該操作依頼より前に申請された他の操作依頼との関係が、排他関係であると判定された場合には、その旨を示す情報を前記操作依頼情報の送信元の操作依頼装置に通知するものであり、このような構成は、上記特許文献１には何ら開示も示唆もされていない。

このように、上記特許文献１と本実施形態の情報処理装置管理システムとは、目的、構成、効果全てにおいてことなるものである。

以上示した点は、本実施形態で示した情報処理装置管理システムと、上記特許文献１との相違を考察する上で、特に留意すべき事項と考える。

以下、図３３に示すメモリマップを参照して本発明に係る情報処理装置管理システムを構成する装置で読み取り可能なデータ処理プログラムの構成について説明する。

図３３は、本発明に係る情報処理装置管理システムを構成する装置で読み取り（読み出し）可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。

なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図１８，図１９，図２０，図２１，図２２，図２３，図２４，図２９，図３０，図３２に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。

プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

操作対象ＰＣ３００をＩＳＭＳ承認取得部門における情報処理装置とすることにより、本実施形態の情報処理装置管理システムをＩＳＭＳ承認取得部門における情報処理装置の操作の承認取得・操作結果等をログとして残す等の定型的な申請プロセスの自動化に適用可能できる。

本発明の第１実施形態を示す情報処理装置管理システムの一例を示すシステム構成図である。 図１に示した操作情報管理ＰＣの構成を示すブロック図である。 図１に示した操作依頼申請書ＤＢのレコード構成を示す模式図である。 図４に示した申請書ファイル名に対応する申請書の一例を示す模式図である。 図１に示した管理システムにおける操作依頼の申請から操作結果報告までの一連のプロセスを説明するフローチャートである。 図５のステップＳ１に示した操作依頼情報の作成及び申請手順を詳細に示す図である。 操作依頼情報の作成画面（仮想ウィンドウ）の一例を示す模式図である。 操作依頼情報の作成（先行依頼）を詳細に示す図である。 図５のステップＳ３に示した操作依頼者の権限検証手順を詳細に示す図である。 図５のステップＳ４，Ｓ５に示した他の操作申請との排他検証及び通知手順を詳細に示す図である。 図５のステップＳ６に示した承認を要する操作の判定手順を詳細に示す図である。 図５のステップＳ７，Ｓ８に示した操作承認確認手順を詳細に示す図である。 図５のステップＳ１０に示した承認操作の排他検証手順を詳細に示す図である。 図５のステップＳ１２に示した操作内容の反映手順を詳細に示す図である。 図５のステップＳ１３に示した操作結果報告書作成手順を詳細に示す図である。 本発明の管理システムにおけるＰＣ操作ワークフローを説明する模式図である。 本発明の管理システムにおけるＰＣ操作ワークフローを説明する模式図である。 本発明の情報処理装置管理システムにおける第１の制御処理手順の一例を示すフローチャートである。 本発明の情報処理装置管理システムにおける第２の制御処理手順の一例を示すフローチャートである。 本発明の情報処理装置管理システムにおける第３の制御処理手順の一例を示すフローチャートである。 本発明の情報処理装置管理システムにおける第４の制御処理手順の一例を示すフローチャートである。 本発明の情報処理装置管理システムにおける第４の制御処理手順の一例を示すフローチャートである。 本発明の情報処理装置管理システムにおける第５の制御処理手順の一例を示すフローチャートである。 本発明の情報処理装置管理システムにおける第６の制御処理手順の一例を示すフローチャートである。 図１に示した操作結果報告書ＤＢのレコード構成を示す模式図である。 図１に示したメモリ又はハードディスク内に保持される監査結果ＤＢの監査結果テーブル及び整合種別テーブルの構成を示す模式図である。 図２４のステップＳ２−１２で作成される監査結果報告書の一例を示す模式図である。 図１に示したメモリ又はハードディスク内に保持される監査結果ＤＢの監査結果テーブル及び整合種別テーブルの構成を示す模式図である。 本発明の情報処理装置管理システムにおける第７の制御処理手順の一例を示すフローチャートである。 本発明の情報処理装置管理システムにおける第８の制御処理手順の一例を示すフローチャートである。 図３０のステップＳ３−９で個人端末のモニタに表示される操作対象ＰＣの仮想ＵＩ画面の一例を示す模式図である。 本発明の情報処理装置管理システムにおける第９の制御処理手順の一例を示すフローチャートである。 本発明に係る情報処理装置管理システムを構成する装置で読み取り（読み出し）可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。

符号の説明

１００ 操作情報管理ＰＣ
１５０ 操作依頼申請書ＤＢ
２００ 個人端末
３００ 操作対象ＰＣ
４００ 承認ＰＣ

Claims (16)

1. 操作対象装置に対する操作依頼を申請する操作依頼装置と通信可能に接続され、当該申請された操作依頼の操作依頼情報を管理する操作情報管理装置おいて、
   前記操作依頼装置から申請された操作依頼の操作依頼情報を順次記憶管理する第１の記憶手段と、
   前記操作依頼装置から申請された新たな操作依頼情報より前に申請された他の実行待ちの操作依頼情報で指定された操作を前記操作対象装置で実行した後でも、前記新たな操作依頼情報で指定された操作を前記操作対象装置で実行することが可能であるか否かを判定する第１の判定手段と、
   前記第１の判定手段により、前記新たな操作依頼情報で指定された操作が前記操作対象装置で実行不可能であると判定された場合には、該新たな操作依頼情報の申請を行った操作依頼装置に対して警告を通知する警告手段と、
   前記第１の記憶手段に記憶される前記操作依頼情報で指定された操作の実行指示を前記操作対象装置に送信し、前記操作対象装置に実行させる実行手段と、
   を有することを特徴とする操作情報管理装置。
2. 前記操作依頼装置は、
   前記操作対象装置のシステム構成情報を取得する取得手段と、
   前記取得手段が取得したシステム構成情報に基づいて前記操作対象装置を仮想操作可能な仮想操作画面を表示する表示手段と、
   前記表示手段により表示された前記仮想操作画面への仮想操作に基づいて前記操作対象装置に対する操作依頼情報を作成する作成手段と、
   前記作成手段により作成された操作依頼情報を前記操作情報管理装置に送信して申請を行う申請手段と、を有することを特徴とする請求項１に記載の操作情報管理装置。
3. 前記操作依頼装置は、実行待ちの操作依頼情報に指定される操作が前記操作対象装置で実行されることを仮定して、前記実行待ちの操作依頼情報で指定された操作が前記操作対象装置で実行されないと実行することができない操作を指定した操作依頼情報を申請可能なことを特徴とする請求項１または請求項２に記載の操作情報管理装置。
4. 前記操作情報管理装置は、前記申請された操作依頼の承認を行う承認装置と通信可能に接続され、
   前記操作情報管理装置は、更に、
   前記申請された操作依頼情報に対する承認の可否を前記承認装置に要求して確認する承認確認手段を備え、
   前記第１の記憶手段は、前記承認確認手段により承認された場合に前記申請された操作依頼情報が承認されたことを記憶することを特徴とする請求項１乃至請求項３のいずれかに記載の操作情報管理装置。
5. 前記操作依頼情報は、申請者の情報を含むものであり、
   申請者ごとに割当てられた操作権限情報を記憶した第２の記憶手段と、
   前記第２の記憶手段に記憶された操作権限情報に基づいて、前記申請された操作依頼情報が権限を有する申請者から申請されたものであるか否かを判定する第２の判定手段と、
   前記第２の判定手段により前記操作依頼情報が権限を有する申請者から申請されたものでないと判定した場合には、前記操作依頼情報の申請を拒否する第１の拒否手段と、
   を有することを特徴とする請求項１乃至請求項４のいずれかに記載の操作情報管理装置。
6. 操作内容ごとに無承認で操作可能な権限情報を記憶した第３の記憶手段と、
   前記第２の記憶手段に記憶された権限情報と前記第３の記憶手段に記憶された無承認で操作可能な操作権限情報とに基づいて、前記申請された操作依頼情報が無承認で操作可能な操作権限を有する申請者から申請されたものであるか否かを判定する第３の判定手段とを有するものであり、
   前記承認確認手段は、前記第３の判定手段により前記申請された操作依頼情報が無承認で操作可能な操作権限を有する申請者から申請されたものであると判定された場合には、該操作依頼情報に対する承認確認を省略することを特徴とする請求項５に記載の操作情報管理装置。
7. 前記第１の判定手段により、前記操作依頼情報で指定された操作が前記操作対象装置で実行不可能であると判定された場合、前記第２の記憶手段に記憶される申請者の操作権限に応じて、前記他の操作依頼情報を拒否する第２の拒否手段を有することを特徴とする請求項５又は６に記載の操作情報管理装置。
8. 前記操作依頼情報で指定された操作を前記実行手段により前記操作対象装置に実行させる際に、前記操作依頼情報で指定された操作を前記操作対象装置で実行することにより後に実行される実行待ちの他の操作依頼情報で指定された操作が前記操作対象装置で実行可能であるか否かを判定する第４の判定手段と、
   前記第４の判定手段により、前記操作依頼情報で指定された操作を実行することにより後に実行される他の操作依頼情報で指定された操作が前記操作対象装置で実行不可能であると判定された場合には、その旨を示す情報を前記他の操作依頼情報の送信元の操作依頼装置に通知する通知手段と、
   を有することを特徴とする請求項１乃至請求項７のいずれかに記載の操作情報管理装置。
9. 操作内容ごとに承認種別を記憶した第４の記憶手段を有するものであり、
   前記承認確認手段は、前記第４の記憶手段に記憶された承認種別に基づいて、前記申請された操作依頼情報に対する承認確認方法を変更制御することを特徴とする請求項４乃至請求項８のいずれかに記載の操作情報管理装置。
10. 前記第１の記憶手段は、前記操作依頼情報で指定された操作を前記実行手段により前記操作対象装置に実行させた際の実行結果を記憶するものであり、
    前記操作対象装置の所定時点でのシステム構成情報と前記第１の記憶手段に記憶される前記操作依頼情報と前記操作依頼情報で指定された操作の前記操作対象装置での実行結果に基づいて、前記操作対象装置の整合性が保たれているか否かを確認する確認手段を有することを特徴とする請求項１乃至請求項９のいずれかに記載の操作情報管理装置。
11. 前記第１の記憶手段は、前記操作依頼情報で指定された操作を前記実行手段により前記操作対象装置に実行させた際の実行結果を記憶するものであり、
    前記操作対象装置の所定時点でのシステム構成情報と前記第１の記憶手段に記憶される前記操作依頼情報と該操作依頼情報で指定された操作の前記操作対象装置での実行結果に基づいて、前記操作対象装置の過去の状態を仮想的操作可能に再現する再現手段を有することを特徴とする請求項１乃至請求項９のいずれかに記載の操作情報管理装置。
12. 前記操作依頼情報で指定された操作の前記操作対象装置での実行結果を所定の管理者の情報処理装置に送信する結果報告手段を有することを特徴とする請求項１乃至請求項１１のいずれかに記載の操作情報管理装置。
13. 前記第１の判定手段は、前記新たな操作依頼情報が所定のフォルダの下位にサブフォルダを作成することを示し、前記他の実行待ちの操作依頼情報が前記所定のフォルダを削除することを示している場合には、前記新たな操作依頼情報により指定された操作が前記操作対象装置で実行不可能であると判定することを特徴とする請求項１乃至１２のいずれかに記載の操作情報管理装置。
14. 操作対象装置に対する操作依頼を申請する操作依頼装置と通信可能に接続され、当該申請された操作依頼の操作依頼情報を管理する操作情報管理装置おける操作情報管理方法おいて、
    登録手段が、前記操作依頼装置から申請された操作依頼の操作依頼情報を第１の記憶手段に順次登録する登録ステップと、
    第１の判定手段が、前記操作依頼装置から申請された新たな操作依頼情報より前に申請された他の実行待ちの操作依頼情報で指定された操作を前記操作対象装置で実行した後でも、前記新たな操作依頼情報で指定された操作を前記操作対象装置で実行することが可能であるか否かを判定する第１の判定ステップと、
    警告手段が、前記第１の判定ステップで、前記新たな操作依頼情報で指定された操作が前記操作対象装置で実行不可能であると判定された場合には、該新たな操作依頼情報の申請を行った操作依頼装置に対して警告を通知する警告ステップと、
    実行手段が、前記第１の記憶手段に記憶される前記操作依頼情報で指定された操作の実行指示を前記操作対象装置に送信し、前記操作対象装置に実行させる実行ステップと、
    を有することを特徴とする操作情報管理方法。
15. 請求項１４に記載された操作情報管理方法を実行するためのプログラム。
16. 請求項１４に記載された操作情報管理方法を実行するためのプログラムをコンピュータが読み取り可能に記憶した記録媒体。