JP2022045248A - 対象機器利用申請承認システムおよび方法、コンピュータプログラム - Google Patents

Abstract

【課題】対象機器の利用申請を適切に処理できるようにした対象機器利用申請承認システムおよび方法、コンピュータプログラムを提供すること。【解決手段】対象機器２０の利用申請を承認する利用申請承認システム１４は、対象機器の利用申請Ｄ１を受け付ける受付部と、複数の優先度で利用時間を管理する利用時間管理部１２の情報に基づいて、利用申請を自動承認するか判定する判定部と、を備える。【選択図】図１

Description

本発明は、対象機器利用申請承認システムおよび方法、コンピュータプログラムに関する。

多くの者にとってパーソナルコンピュータ（以下、ＰＣ）は、仕事や作業を進めるために欠かせない電子機器である。一方、ユーザ（労働者）は、つい時間を忘れてＰＣ作業に集中してしまい、残業時間が長くなることがある。最近は、自宅または最寄りのサテライトオフィスなどでＰＣを操作するテレワークが広まっているが、テレワークの場合は勤務時間が長くなりやすいと言われている。しかし、法律、労使協定、勤務条件などで制限されている残業時間を超えて働くのは、通常、好ましくない。このためユーザは、事前申告せずに隠れて残業するという、いわゆるサービス残業をすることがある。または、ユーザは、上司の許可なく自分だけの判断で不要不急の残業をすることもある。

このように、個人判断による長時間残業の抑止、サービス残業の抑止、テレワーカの働き過ぎ抑止の観点から、残業時間の管理が求められている。一方、トラブル発生時など緊急事態では、営業時間外であってもＰＣを操作して対応せざるを得ない。

そこで、残業を適切に管理するための技術が提案されている（特許文献１，２）。特許文献１の労働時間管理システムは、組織の労働者の労働時間を管理する労働時間管理サーバを備え、労働時間管理サーバは、労働者の個人別の勤務状況を把握する勤休管理部と、労働者の個人別の勤務条件を判定する個人別勤務条件判定部と、労働者の個人別の勤務状況に基づいて、労働者の個人別の労働時間を把握し、労働者の個人別の労働時間が、勤務条件における許容労働時間に対応する上限閾値を越える状態かどうかを判定する労働時間判定部と、上限閾値を超える状態である労働者について、抑止対象者として、抑止対象者が設備またはエリアを利用して業務を行うことを不可能とするように、設備またはエリアの利用を不許可とする抑止制御を行う抑止制御部とを備える。

特許文献２では、時間外勤務申請の承認者として、複数の時間帯ごとに承認者の設定を受け付け、受け付けた設定に基づき受理される時間外勤務申請の履歴を記憶し、記憶される履歴に基づき労務管理を実行する。

特開２０１９－０４５９２１号公報 特開２０１９－０６１４７５号公報

従来技術では、ＰＣを利用する不要な残業を強制的に抑止したり、勤務状況に応じて管理態様を柔軟に設定したりしている。しかし、緊急事態の発生を予見するのは困難なため、残業を許可する権限を持つ上司が常時速やかに緊急時の残業申請を判断できる保証はなく、かつ、承認の手間がかかる。一方、深夜や早朝などの営業時間外に出された残業申請を無制限に認めるのでは、個人判断による勝手な残業を抑止することができない。

本発明は、上記問題に鑑みてなされたもので、その目的は、対象機器の利用申請を適切に処理できるようにした対象機器利用申請承認システムおよび方法、コンピュータプログラムを提供することにある。

上記課題を解決すべく、本発明の一つの観点に従う利用申請承認システムは、対象機器の利用申請を承認する利用申請承認システムであって、対象機器の利用申請を受け付ける受付部と、複数の優先度で利用時間を管理する利用時間管理部の情報に基づいて、利用申請を自動承認するか判定する判定部と、を備える。

利用時間管理部で管理される複数の優先度は、第１優先度と、第１優先度よりも低い値に設定される第２優先度とを含み、第１優先度の場合に第１時間の利用が自動承認され、利用申請が第２優先度の場合に第１時間よりも短い第２時間の利用が自動承認されてもよい。

第１優先度の場合に第１時間の利用が第１の上限回数まで自動承認され、利用申請が第２優先度の場合に第２時間の利用が第１の上限回数よりも多い第２の上限回数まで自動承認されてもよい。

利用時間管理部は、利用申請の発行者の属するグループに基づいて、複数の優先度を管理することができる。

グループは、職位、部署、組織、勤務地、勤務条件、プロジェクトのいずれか一つまたは複数の観点で生成されてもよい。

判定部は、利用申請を自動承認しない場合に、利用申請を承認者の端末へ送信し、承認者による手動承認を依頼することもできる。

利用時間管理部は、第１上限回数または第２上限回数をグループ単位で管理することもできる。

利用申請が自動承認された場合に、利用申請の発行元の端末に利用申請が自動承認された旨を通知する通知部をさらに備えてもよい。

通知部は、利用申請が自動承認された場合に、利用申請の発行元の端末と利用申請の発行者に対応する承認者の端末との両方に、利用申請が自動承認された旨を通知することもできる。

利用時間管理部は、ユーザが対象機器を利用可能な回数および時間を管理しており、通知部は、複数のユーザが共同作業する共同作業グループ内に、対象機器を利用可能な回数または時間が所定値以上異なる所定ユーザが含まれている場合に、所定ユーザに対応する承認者に対して、所定ユーザが対象機器を利用可能な回数または時間について通知することもできる。

利用申請が自動承認された場合に、対象機器の利用についての報告書の提出を要求する報告書提出要求部をさらに備えることもできる。

利用申請が承認されなかった場合に対象機器の利用を抑止する抑制制御部をさらに備えてもよい。

受付部は、管理サーバ内に設けられるサーバ側受付部と、クライアント端末内に設けられるクライアント側受付部とを備え、判定部は、管理サーバ内に設けられるサーバ側判定部と、クライアント端末内に設けられるクライアント側判定部とを備え、利用時間管理部は、管理サーバ内に設けられるサーバ側利用時間管理部と、クライアント端末内に設けられ、サーバ側利用時間管理部と連携するクライアント側利用時間管理部とを備え、クライアント端末内には、クライアント端末と管理サーバとが通信可能か判定する通信状態判定部が設けられており、利用申請がクライアント端末から発行された場合に、通信状態判定部が通信不能であると判定すると、利用申請はクライアント側受付部により受け付けられて、クライアント側判定部により自動承認するか判定され、判定結果に基づいてクライアント側利用時間管理部が更新され、クライアント側通知部から自動承認された旨が通知されるようになっており、通信状態判定部がクライアント端末と管理サーバとの通信が可能であると判定すると、クライアント側利用時間管理部の情報がサーバ側利用時間管理部へ送信されて、サーバ側利用時間管理部の情報が更新されてもよい。

本発明によれば、複数の優先度で利用時間を管理し、利用申請を自動承認するか判定することができるため、利用申請を適切に管理することができる。

本実施例に係るコンピュータ利用申請承認システムを含むシステム全体の機能構成図。 利用管理サーバおよびクライアントＰＣとして使用可能な計算機のハードウェア構成図。 承認処理のフローチャート。 図３中の承認種別を判定するステップの詳細を示すフローチャート。 自動承認のための設定値を管理するテーブルの例。 利用申請を管理するテーブルの例。 図３中の手動承認処理の詳細を示すフローチャート。 手動承認の流れを示す機能構成図。 図３中の自動承認処理の詳細を示すフローチャート。 自動承認処の流れを示す機能構成図。 クライアントＰＣをシャットダウンさせる処理を示すフローチャート。 第２実施例に係るコンピュータ利用申請承認システムを含むシステム全体の機能構成図。 第３実施例に係り、自動承認のための設定値を管理するテーブルの例。 第４実施例に係り、共同作業グループ内で利用申請の設定調整を促進する処理を示すフローチャート。 第５実施例に係るコンピュータ利用申請承認システムを含むシステム全体の機能構成図。 クライアントＰＣ内で利用申請を承認する処理を示すフローチャート。

以下、図面に基づいて、本発明の実施の形態を説明する。本実施形態に係る利用申請承認システム１４は、対象機器２０を利用するための利用申請Ｄ１が自動承認可能か否か判定し、承認可能と判定した場合は自動承認する。緊急事態への対応など急な残業が必要になったユーザは、本システム１４に利用申請を送信することにより、ただちに対象機器２０を利用することができる。

本実施形態では、利用申請の対象となる機器２０として、ＰＣを例に挙げる。ＰＣの種類は問わない。例えば、デスクトップ型ＰＣ、ラップトップ型ＰＣ、タブレット型ＰＣ、ウェアラブル型ＰＣ、スマートフォン型ＰＣなどでもよい。対象機器２０は、ユーザが仕事（作業）に使用する機器であればよく、ＰＣに限らない。例えば、測定装置、実験装置、試作品製造装置、３Ｄプリンタ、３Ｄスキャナなどの、通信機能と制御機能を備える電子機器の利用申請も、本システム１４で管理することができる。

本実施形態では、利用申請承認システム１４をワークフローシステム１３およびＰＣ自動シャットダウンシステム１１と連携させることにより、利用管理システム１の一機能として利用しているが、これに限らず、利用申請承認システム１４単体で独立したサービスを提供することもできる。

すなわち、この場合は、クライアントＰＣ２０からの利用申請を自動承認できるか判定し、その結果をクライアントＰＣ２０へ返信するサービスを提供することができる。ユーザは、自動承認されなかった場合でも、それを無視してクライアントＰＣ２０を利用することはできる。

しかし、利用申請が承認されなかったことは利用時間管理部１２に記録されるため、図示せぬ勤怠管理システムで管理されている情報と照合することにより、所定時刻（例えば終業時刻）後に未承認の機器利用（残業）が行われたことは、客観的に明らかとなる。したがって、承認を得ずに機器を利用したユーザに対して、残業時間の適切な管理について意識付けすることができ、未承認の残業の発生を抑制する効果を期待できる。

本実施形態では、対象機器の一例としてのＰＣ２０の利用を管理することにより、ＰＣを用いて仕事をするユーザの残業を管理することができる。したがって、対象機器利用申請承認システムとしの利用申請承認システム１４は、残業申請承認システムと呼ぶこともできる。

図１～図１１を用いて第１実施例を説明する。図１は、利用申請承認システム１４を含む利用管理システム１の全体の機能構成図である。

利用管理システム１は、クライアントＰＣ（以下、ＰＣと略記する場合がある。）２０の利用を管理する情報処理システムであって、利用管理サーバ１０を含む。利用管理システム１は、利用管理サーバ１０と、クライアントＰＣ２０と、承認者ＰＣ３０とを備えている。図中では、クライアントＰＣ２０と承認者ＰＣ３０とをそれぞれ１つずつ示すが、実際には複数のクライアントＰＣ２０と承認者ＰＣ３０とが利用管理サーバ１０に接続されている。

利用管理サーバ１０は、クライアントＰＣ２０からの利用申請データＤ１（以下、利用申請Ｄ１）を受け付けてその可否を判定し、判定結果に基づいてクライアントＰＣ２０へ通知したり、クライアントＰＣ２０の動作を遠隔制御したりする。

利用管理サーバ１０は、例えば、ＰＣ自動シャットダウンシステム（以下、シャットダウンシステムと略記する場合がある。）１１と、利用時間管理データベース１２と、ワークフローシステム１３と、利用申請承認システム１４とを備える。以下、データベースをＤＢと略記する。

利用管理サーバ１０を、図２で後述する汎用計算機１００を用いて構築する場合、シャットダウンシステム１１、利用時間管理ＤＢ１２、ワークフローシステム１３および利用申請承認システム１４は、コンピュータプログラムおよびデータによって実現することができる。これら各機能１１,１２，１３，１４を実現するために、専用計算機または専用回路などを用いてもよい。さらに、一つの物理計算機または仮想計算機から利用管理サーバ１０を構成してもよいし、複数の物理計算機または仮想計算機を連携させることにより利用管理サーバ１０を構成してもよい。

シャットダウンシステム１１は、クライアントＰＣ２０をシャットダウンさせるスケジュールを管理し、クライアントＰＣ２０のクライアントアプリケーション２１からの問合せに応じてスケジュールを配信する。シャットダウンシステム１１とクライアントアプリケーション２１とによって「抑制制御部」が実現される。

クライアントＰＣ２０をシャットダウンさせる方法は幾つかある。第１の方法は、本実施例のように、クライアントアプリケーション２１が、シャットダウンシステム１１から通知されたスケジュールにしたがって、クライアントＰＣ２０をシャットダウンさせる方法である。第２の方法は、シャットダウンシステム１１がスケジュールにしたがって遠隔操作でクライアントＰＣをシャットダウンさせる方法である。いずれの方法を採用してもよい。

ＰＣ２０の利用を抑制する方法は、シャットダウンに限らない。例えば、モニタディスプレイの表示を停止させたり、キーボードスイッチからの入力の受付を禁止したりといったように、クライアントＰＣ２０の持つ複数の機能のうちの一つまたは複数の機能を止めたり、制限したりすることで、ＰＣ２０の利用を抑制してもよい。機能の制限としては、例えば、音声出力または音声入力のレベルを低くする、モニタディスプレイの解像度や色数を少なくする、ファイル保存など必要最低限の操作以外のキーボード入力を禁止する、といった方法がある。

「利用時間管理部」の例としての利用時間管理ＤＢ１２は、ユーザ毎のＰＣ利用時間および利用条件といった利用管理情報を管理する。利用管理情報の少なくとも一部は、承認者またはシステム管理者が手動で設定することができる。承認者とは、ユーザがクライアントＰＣ２０を利用することについての承認を与える権限を持つ者であり、一般的には上司が該当する。ただし本実施例では、承認者はユーザの上司に限らない。ユーザと同一の職位または下位の職位になる者であっても、承認権限を持つ者は承認者に該当する。さらには、ユーザとは別の企業または組織に属する者であっても、承認権限を持つ者は承認者に該当する。

ワークフローシステム１３は、ユーザの業務の一連の処理手続を管理する。本実施例では、クライアントＰＣ２０からの利用申請Ｄ１をワークフローシステム１３を介して利用申請承認システム１４に入力する。これにより、ユーザの業務との関係でＰＣ利用時間（残業時間とも呼ぶ。）を管理することができ、どの業務について誰の承認を得たかなどを記録することもでき、利便性が向上する。ただし、クライアントＰＣ２０からの利用申請Ｄ１を、ワークフローシステム１３を介さずに利用申請承認システム１４へ直接入力してもよい。本実施例で述べる種々の利点は、本実施例の利用申請承認システム１４の構成を何ら限定しない。

「対象機器利用申請承認システム」としての利用申請承認システム１４は、クライアントＰＣ２０からの利用申請Ｄ１を受け付けて、その利用申請Ｄ１を自動承認するか否か判定する。

利用申請承認システム１４は、手動承認部１４１と自動承認部１４２を備える。手動承認部１４１は、承認者の判断により利用申請Ｄ１を承認させる機能である。自動承認部１４２は、所定の条件を満たす場合に、利用申請Ｄ１を自動承認する機能である。各承認部１４１，１４２の詳細は、図７～図１０で後述する。

クライアントＰＣ２０は、上述の通り「対象機器」の一例である。クライアントＰＣ２０は、利用管理サーバ１０の提供するサービスを利用するためのクライアントアプリケーション２１がインストールされている。図中では、アプリケーションプログラムをＡｐｐと略記する。

クライアントアプリケーション２１は、シャットダウンシステム１１からシャットダウン時刻を定期的に取得し、シャットダウン時刻が到来するとクライアントＰＣ２０をシャットダウンさせる。なお、上述の通り、シャットダウンというＰＣ２０の完全な機能停止に代えて、ＰＣ２０の持つ各機能のうちの一部の機能の停止、または一部の機能の低下により、ユーザの作業を実質的に中断させることもできる。

クライアントアプリケーション２１は、複数のタイミングで、シャットダウンの予定時刻（シャットダウン時刻）をユーザに通知することができる。例えば、クライアントアプリケーション２１は、ＰＣ２０の起動時、シャットダウン時刻の所定時間前、シャットダウン時刻を過ぎた後などでメッセージをＰＣ２０の画面に表示させる。毎正時にシャットダウン時刻を画面表示させたり、カウントダウンタイマを画面の隅に表示させたりしてもよい。

シャットダウンの予定時刻を過ぎた後も作業を続けたいユーザは、クライアントアプリケーション２１から利用管理サーバ１０へ向けて利用申請Ｄ１を発行する。この利用申請Ｄ１が利用申請承認システム１４により承認されると、利用時間管理ＤＢ１２で管理されているシャットダウンを予定している時刻が更新される。後述の図１１では、シャットダウン時刻をＰＣ利用停止時刻と表記している。

クライアントアプリケーション２１は、更新されたシャットダウン時刻をシャットダウンシステム１１から取得するため、更新されたシャットダウン時刻になるまでＰＣ２０をシャットダウンさせない。

なお、いったんシャットダウンした後でも、ユーザはＰＣ２０を再起動させて所定の猶予時間（例えば数分間）だけＰＣ２０を操作することができる。ユーザは、猶予時間内にクライアントアプリケーション２１から利用管理サーバ１０へ利用申請Ｄ１を送信させることができる。

利用申請承認システム１４による利用申請の承認、利用時間管理ＤＢ１２の更新、シャットダウンシステム１１からのシャットダウン時刻の変更通知といった一連の承認処理が猶予時間の終了前に終了した場合、ユーザはＰＣ２０をそのまま使用できる。一連の承認処理が猶予時間の終了に間に合わなかった場合、ＰＣ２０は再びシャットダウンする。この場合、ユーザは、少し待ってからＰＣ２０を再起動させることにより、ＰＣ２０を使用することができる。

承認者ＰＣ３０は、承認者の使用するＰＣである。承認者ＰＣ３０は、利用申請承認システム１４からの利用申請承認通知を受信して承認者に知らせる機能を有していればよいため、必ずしもＰＣである必要はない。通信機能と表示機能（あるいは音声出力機能）を備える端末であればよい。したがって、承認者ＰＣ３０は、携帯情報端末、携帯電話（いわゆるスマートフォンを含む）のような装置でもよい。

他システム４０は、利用管理サーバ１０と連携するシステムである。他システム４０には、例えば、勤怠管理システム、経費管理システム、人事考課システムなどの、利用時間管理ＤＢ１２の情報を利用可能なシステムが含まれる。ただし、他システム４０との連携がない場合でも、本実施例は有効に機能する。

図２を用いて、利用管理サーバ１０またはクライアントＰＣ２０として使用可能な計算機１００の概略構成を説明する。

計算機１００は、例えば、プロセッサ１０１、主記憶装置１０２、補助記憶装置１０３、入力装置１０４、出力装置１０５および通信装置１０６を備える。プロセッサ１０１は、補助記憶装置１０３に記憶されたコンピュータプログラムを主記憶装置１０２へ読み出して実行することにより、所定の機能を実現させる。

所定の機能とは、計算機１００を利用管理サーバ１０として用いる場合は、図１で述べたシャットダウンシステム１１、利用時間管理ＤＢ１２、ワークフローシステム１３および利用申請承認システム１４である。計算機１００をクライアントＰＣ２０として用いる場合は、クライアントアプリケーション２１が所定の機能となる。なお、計算機１００を承認者ＰＣ３０として用いてもよい。

入力装置１０４は、オペレータ（またはユーザ）が計算機１００へ情報を入力するための装置であり、例えば、キーボードスイッチ、タッチパネル、音声入力装置などの全部または一部を含む。出力装置１０５は、計算機１００からオペレータ（またはユーザ）へ情報を提供するための装置であり、例えば、モニタディスプレイ、プリンタ、音声合成装置などの全部または一部を含む。

記憶媒体ＭＭは、計算機１００に接続され、計算機１００との間でコンピュータプログラム（またはデータを含む。）を送受信する。記憶媒体ＭＭに記憶されたコンピュータプログラムを補助記憶装置１０３に記憶させることもできるし、補助記憶装置１０３に記憶されたコンピュータプログラムを記憶媒体ＭＭへ転送して記憶させることもできる。

図３～図１１を用いて、承認処理を説明する。図３の説明に際して図８の機能構成図が適宜参照される。

まず最初に、シャットダウン予定時刻以降もＰＣ２０の使用を希望するユーザは、クライアントアプリケーション２１を用いて利用申請Ｄ１を作成し、この利用申請Ｄ１を利用管理サーバ１０のワークフローシステム１３へ送信する（Ｓ１１）。利用申請Ｄ１は、例えば、ユーザＩＤ、利用対象日（残業予定日）、利用時間、緊急度（ＥＡ，ＥＢ，ＥＣのいずれか一つ）、申請理由を含むことができる。これら以外の情報を利用申請Ｄ１は含んでもよい。

利用時間は、利用開始時刻と利用時間とにより定義してもよいし、利用開始時刻と利用終了時刻とにより定義してもよい。ユーザＩＤに代えて、あるいはユーザＩＤと共にユーザ氏名を利用申請Ｄ１に含めてもよい。

緊急度は「優先度」に該当し、利用申請Ｄ１の緊急性または重要性を示すランク情報である。本実施例では、緊急度として、第１緊急度ＥＡ，第２緊急度ＥＢ，第３緊急度ＥＣの３つを例に挙げる。

第１緊急度ＥＡは「第１優先度」に対応し、トラブルへの本格的対処などの緊急度が高く時間もかかる仕事のために使用される。第２緊急度ＥＢは「第２優先度」に対応し、ちょっとした作業などの緊急性が高くなく短時間で完了しうる仕事のために使用される。第３緊急度ＥＣは、緊急性のない作業のために使用される。第１緊急度ＥＡおよび第２緊急度ＥＢは、利用申請承認システム１４による自動承認の判定対象となる。第３緊急度ＥＣは、利用申請承認システム１４による自動承認の判定対象とはならない。すなわち、第３緊急度ＥＣを有する利用申請Ｄ１は、手動承認の対象として処理される。

ワークフローシステム１３は、クライアントＰＣ２０のクライアントアプリケーション２１から発行された利用申請Ｄ１を受信すると、この利用申請Ｄ１の承認について利用申請承認システム１４へ問い合わせる（Ｓ１２）。

ワークフローシステム１３からの問合せを受領した利用申請承認システム１４は、利用申請Ｄ１に含まれているユーザＩＤに基づいて利用時間管理ＤＢ１２を参照し、自動承認条件を満たすか否か判定するための情報をＤＢ１２から取得する（Ｓ１３）。自動承認条件を満たすか否か判定するための情報としては、例えば、ユーザの役職（ランク）、勤怠状況（例えば当月および前月の残業時間）を挙げることができる。

利用申請承認システム１４は、利用申請Ｄ１の承認種別を判定する（Ｓ１４）。すなわち、利用申請承認システム１４は、受け付けた利用申請Ｄ１を自動承認するか手動承認するか判定する（Ｓ１４）。

利用申請承認システム１４が利用申請Ｄ１を手動承認すると判定すると（Ｓ１４：手動）、後述の手動承認処理が実行される（Ｓ２０）。利用申請承認システム１４が利用申請Ｄ１を自動承認すると判定すると（Ｓ１４：自動）、自動承認部１４２により後述の自動承認処理が実行される（Ｓ３０）。

図３中のステップＳ１２は、「対象機器の利用申請を受け付ける受付部」または「受付ステップ」に対応する。図３中のステップＳ１４は、「利用申請を自動承認するか判定する判定部」または「判定ステップ」に対応する。ステップＳ１２は、判定用の情報を利用時間管理部１２から取得する「情報取得部」または「情報取得ステップ」と呼ぶこともできる。なお、後述の図９中のステップＳ３１，Ｓ３２は「通知部」または「通知ステップ」に対応する。

図４を用いて、承認種別を判定するステップＳ１４の詳細を説明する。利用申請承認システム１４は、利用申請Ｄ１からユーザＩＤと緊急度Ｅと利用対象日および利用時間ＳＯＴを取得する（Ｓ１４１）。以下、利用対象日については記載を省略する。

利用申請承認システム１４は、利用申請Ｄ１の緊急度Ｅが第１緊急度ＥＡまたは第２緊急度ＥＢであるか判定する（Ｓ１４２）。判断対象の利用申請Ｄ１が第１緊急度ＥＡまたは第２緊急度ＥＢを持つ場合（Ｓ１４２：ＹＥＳ）、利用申請承認システム１４は、利用申請Ｄ１を提出したユーザＩＤに対応する自動承認残回数ＮＥが１以上であるか判定する（Ｓ１４３）。自動承認残回数ＮＥとは、自動承認される残り回数である。自動承認残回数ＮＥが０になった場合は、緊急度ＥＡの利用申請であっても自動承認されない。ただし、承認者が、利用申請承認システム１４を介して、利用時間管理ＤＢ１２内の自動承認残回数ＮＥを１以上に書き換えた更新した場合は、自動承認される。

自動承認残回数ＮＥが１以上の場合（Ｓ１４３：ＹＥＳ）、利用申請Ｄ１に記載された利用時間ＳＯＴが所定範囲内であるか判定する（Ｓ１４４）。所定範囲とは、法律、労使協定、労働条件などで定められた時間内のことである。自動承認による過度な労働を未然に防止するために、ステップＳ１４４が設けられている。利用時間が所定範囲であることの例は、図５で後述する。

利用申請Ｄ１に記載された利用時間が所定範囲内の場合（Ｓ１４４：ＹＥＳ）、その利用申請Ｄ１は自動承認すべきと判定され（Ｓ１４５）、図３のステップＳ１４へ戻る。利用申請Ｄ１に記載された利用時間が所定範囲内ではない場合（Ｓ１４４：ＮＯ）、その利用申請Ｄ１は手動承認すべきと判定され（Ｓ１４６）、ステップＳ１４へ戻る。

図５は、利用時間管理ＤＢ１２に記憶されている自動承認設定値管理テーブルＴ１の例である。このテーブルＴ１は、利用申請Ｄ１を自動承認するための条件を管理する。このテーブルＴ１は、例えば、緊急度付与回数Ｃ１１、ランクＣ１２～Ｃ１５、利用時間の所定範囲Ｃ１６を含む。

緊急度付与回数Ｃ１１とは、緊急度毎に付与されている、自動承認が認められる回数（自動承認付与回数とも呼ぶ。）である。付与回数は、緊急度ごとに、ユーザの属するランクＣ１２～Ｃ１５に応じて、設定される。ランク順序は、ランク１＞ランク２＞ランク３＞ランク４であるとする。高いランクほど、緊急度ごとの自動承認付与回数は多い。付与回数の下に記載されたかっこ付きの数字は、繰り越し可能回数を示す。図５の例では、最大２ヶ月分の繰り越しが認められている。

同一ランクの場合、第１緊急度ＥＡの付与回数よりも第２緊急度ＥＢの付与回数の方が少なくなるように設定されている。図示の例では、第１緊急度ＥＡに付与される回数に対して第２緊急度ＥＢに付与される回数は２倍である。ただし、図示された具体的数値は、説明の便宜上表示されているに過ぎず、他の数値であってもよい。

所定範囲Ｃ１６の例を説明する。第１緊急度ＥＡを持つ利用申請Ｄ１（残業申請）は、無条件で自動承認されるが、残業時間が以下に述べる所定範囲内であることが条件になっている。所定範囲Ｃ１６は、残業時間制限条件と呼ぶこともできる。

例えば、第１緊急度ＥＡの場合、当月の残業申請が自動承認されるためには、当月の残業時間が第１残業時間（例えば４０時間）以下であることが必要である。当月の残業時間が第１残業時間を超えている場合、一日あたり第２残業時間（例えば５時間）以下の残業が自動承認される。当月の残業時間が第３残業時間（＝第１残業時間＋第２残業時間。例えば４５時間）を超えた場合、翌月の残業は承認されない。なお、第４残業時間（例えば１００時間）未満までの残業が特別に認められているユーザの場合、翌月に残業申請が自動承認されるためには、あらかじめ承認者（例えば上司）の承諾が必要となる。

第２緊急度ＥＢを持つ利用申請Ｄ１は、条件付きで自動承認される。条件とは一回の残業時間が第５残業時間（例えば４時間）以内であるか、もしくは第６残業時刻（例えば２２時）まで、であることである。第２緊急度ＥＢを持つ利用申請Ｄ１がこの条件を満たす場合、当月の残業時間が第１残業時間まで自動承認される。

以下、第１緊急度の所定条件と同様に、前月の残業時間が第１残業時間を超えている場合、利用申請は、一日あたり第７残業時間（例えば２時間）まで自動承認される。当月の残業時間が第３残業時間を超えた場合、翌月の残業は承認されない。第４残業時間未満までの残業が特別に認められているユーザの場合、翌月に残業申請が自動承認されるためには、あらかじめ承認者の承諾が必要となる。

図６は、利用時間管理ＤＢ１２に格納されている、利用申請を管理するテーブルＴ２の例である。利用申請管理テーブルＴ２は、例えば、ユーザＩＤ Ｃ２１と、ランクＣ２２と、緊急度Ｃ２３と、利用日Ｃ２４と、申請された利用時間Ｃ２５と、前月の利用時間Ｃ２６と、当月の利用時間Ｃ２７と、第１緊急度ＥＡの自動承認残回数Ｃ２８と、第２緊急度ＥＢの自動承認残回数ＥＢとを管理する。図中、一部の表記を簡略化している。

ユーザＩＤ Ｃ２１は、利用申請承認システム１４で管理される各ユーザを識別する情報である。ランクＣ２２は、ユーザの属するランク（役職、職位など）である。ランクＣ２２の分類方法は、役職または職位に限らない。例えば、ユーザの部署、組織、勤務地、勤務条件、プロジェクトのいずれか一つまたは複数の観点でランク分けしてもよい。それら部署、組織、勤務地、勤務条件、プロジェクトなどによって、ＰＣ２０を利用する回数および時間が相違する場合があるためである。

緊急度Ｃ２３は、利用申請の緊急度である。緊急度はユーザが指定する。利用日Ｃ２４は、ＰＣ２０の利用日、つまり本実施例では残業日である。申請利用時間Ｃ２４は、所定時刻（終業時刻）を超えてユーザがＰＣ２０を利用した時間、つまり本実施例では残業時間である。前月利用時間Ｃ２６は、前月に、ユーザが所定時刻を超えてＰＣ２０を利用した時間の合計、つまり本実施例では前月残業時間である。当月利用時間Ｃ２７は、当月に、ユーザが所定時刻を越えてＰＣ２０を利用した時間の合計、つまり本実施例では当月残業時間である。

第１緊急度の自動承認残回数Ｃ２８は、ユーザが第１緊急度ＥＡの利用申請Ｄ１を発行可能な残回数を示す。第２緊急度の自動承認残回数Ｃ２９は、ユーザが第２緊急度ＥＢの利用申請Ｄ１を発行可能な残回数を示す。

図７は、手動承認処理（Ｓ２０）の詳細を示すフローチャートである。処理の流れを図８に示す。

利用申請承認システム１４は、手動承認の場合に、例えば、承認者ＰＣ３０へ利用申請Ｄ１を含む電子メールを送信し、承認を依頼する（Ｓ２１）。依頼された承認者は、利用申請Ｄ１の内容を見て承認するか否か判断する。承認者ＰＣ３０は、承認者の決定を取得すると、ワークフローシステム１３にアクセスして承認処理する。

ワークフローシステム１３は、承認された利用申請Ｄ１に記載された利用時間をＰＣ利用時間変更情報として利用時間管理ＤＢ１２へ記録する（Ｓ２３）。すなわち、ＤＢ１２で管理されているＰＣ利用停止時刻に利用申請Ｄ１に記載された利用時間を加えることにより、ＰＣ利用停止時刻（シャットダウン時刻）を更新させる。

シャットダウンシステム１１は、クライアントアプリケーション２１からカレンダおよびＰＣ利用時間変更情報の送信要求を受領すると（Ｓ２４）、利用時間管理ＤＢ１２からカレンダおよびＰＣ利用時間変更情報を取得し（Ｓ２５）、それらカレンダおよびＰＣ利用時間変更情報をクライアントアプリケーション２１へ送信する（Ｓ２６）。

図９は、自動承認処理（Ｓ３０）の詳細を示すフローチャートである。処理の流れを図１０に示す。

利用申請承認システム１４は、利用申請Ｄ１を自動承認した旨を承認者ＰＣ３０へ通知する（Ｓ３１）。同時に利用申請承認システム１４は、利用申請Ｄ１を発行したクライアントＰＣ２０のクライアントアプリケーション２１に対して、利用申請Ｄ１を自動承認した旨を通知する（Ｓ３２）。承認者ＰＣ３０に対する通知（承認者への通知）とクライアントＰＣ２０に対する通知（利用申請したユーザへの通知）とは、同一内容であってもよいし、異なってもよい。

内容を異ならせる場合、例えば、クライアントＰＣ２０には「利用申請が承認されました」といったメッセージのみ送信し、承認者ＰＣ３０には利用申請Ｄ１の記載内容（ユーザＩＤ、緊急度、利用時間など）だけでなく、申請者であるユーザの当月残業時間、前月残業時間、緊急度毎の残回数など利用申請管理テーブルＴ２の内容のうち申請者に対応する内容を加えてもよい。これにより、管理職である承認者は、申請者であるユーザの勤務状況を利用申請Ｄ１の処理を通じて適宜把握することができ、必要に応じてユーザに連絡を取り、コミュニケーションをはかることもできる。

利用申請承認システム１４は、自動承認した利用申請Ｄ１に記載れた利用時間に基づいて、ＰＣ利用時間変更情報を利用時間管理ＤＢ１２に記憶させる（Ｓ３３）。

シャットダウンシステム１１は、クライアントアプリケーション２１からの要求に応じて、利用時間管理ＤＢ１２からカレンダおよびＰＣ利用時間変更情報を取得し（Ｓ３５）、クライアントアプリケーション２１へ送信する（Ｓ３６）。

図１１は、クライアントアプリケーション２１が実行するシャットダウン処理を示すフローチャートである。

クライアントアプリケーション２１は、シャットダウンシステム１１から取得したカレンダおよびＰＣ利用時間変更情報に基づいて、ＰＣ利用停止予定時刻を過ぎたか判定する（Ｓ４１）。

ここではＰＣ利用停止時刻を過ぎていないため（Ｓ４１：ＮＯ）、クライアントアプリケーション２１は、シャットダウンシステム１１からカレンダおよびＰＣ利用時間変更情報を取得し（Ｓ４４）、それら取得した情報からＰＣ利用停止時刻（上述したシャットダウンを予定している時刻）を算出する（Ｓ４５）。

クライアントアプリケーション２１は、所定の警告タイミングが到来したか判定し（Ｓ４６）、警告タイミングであると判定すると（Ｓ４６：ＹＥＳ）、クライアントＰＣ２０の画面にＰＣ利用停止時刻についての警告を表示させる（Ｓ４７）。クライアントアプリケーション２１は、例えば「ＰＣは１８時にシャットダウンします」といったメッセージを画面に表示することにより警告する。所定の警告タイミングは、例えば、クライアントＰＣ２０の起動時、ＰＣ利用停止時刻（シャットダウン時刻）の３０分前などの所定時間前、シャットダウン時刻を過ぎた後などである。

そして、クライアントアプリケーション２１は、ＰＣ利用停止時刻を過ぎたか判定し（Ｓ４８）、過ぎた場合（Ｓ４８：ＹＥＳ）、クライアントＰＣ２０の利用を停止させる（Ｓ４９）。すなわち、この例では、クライアントＰＣ２０をシャットダウンさせる。

警告タイミングではない場合（Ｓ４６：ＮＯ）およびＰＣ利用停止時刻ではない場合（Ｓ４８：ＮＯ）、ステップＳ４６へ戻る。

ＰＣ利用停止時刻を過ぎてクライアントＰＣ２０がシャットダウンされた後に、ユーザがクライアントＰＣ２０を再起動させた場合を説明する。この場合、ＰＣ利用停止時刻を過ぎているため（Ｓ４１：ＹＥＳ）、クライアントアプリケーション２１は、例えば数分程度の猶予時間についてカウントダウンを開始し（Ｓ４２）、猶予時間が経過すると（Ｓ４３：ＹＥＳ）、クライアントＰＣ２０を再びシャットダウンさせる（Ｓ４９）。

ユーザは、クライアントＰＣ２０を起動させてから、ユーザ自身によりまたはクライアントアプリケーション２１によりシャットダウンされるまでの間、クライアントＰＣ２０を利用できる。図１１の例では、ステップＳ４１～Ｓ４８までの間、ユーザはクライアントＰＣ２０を利用できるため、その利用可能な時間内にクライアントアプリケーション２１から利用申請Ｄ１を利用管理サーバ１０へ送信することができる。

このように構成される本実施例によれば、複数の緊急度ＥＡ，ＥＢに基づいてクライアントＰＣ２０の利用時間を自動承認することができるため、ユーザは、承認者による承認を得にくい時間帯に利用申請の承認を得ることができ、緊急性の高い状況に即応することができ、ユーザにとっての使い勝手が向上する。

本実施例によれば、第１緊急度ＥＡの場合に長時間の利用が自動承認され、第２緊急度ＥＢの場合に短時間の利用が自動承認されるため、ユーザは状況に応じて緊急度を使い分けることにより、ＰＣ２０の利用時間を適切に選択できる。ユーザは、例えば、ＰＣ２０を長時間使用しなければ解決できないトラブルに取り組む場合は第１緊急度ＥＡを指定して利用申請Ｄ１を出す。ユーザは、例えば、ＰＣ２０を短時間使用するだけで処理可能なトラブルに取り組む場合は第２緊急度ＥＢを指定して利用申請Ｄ１を出す。したがって、本実施例によれば、ユーザの状況判断に応じた適切な時間でＰＣ２０を利用することができ、使い勝手がよい。

本実施例によれば、第１緊急度ＥＡの場合に長時間の利用が第１上限回数まで自動承認され、第２緊急度ＥＢの場合に短時間の利用が第１上限回数よりも多い第２上限回数まで自動承認されるため、ユーザの働き過ぎの抑制とユーザにとっての利便性向上という相反する要求を両立させることができる。すなわち本実施例によれば、ユーザの長時間残業を制限しつつも、ユーザの短時間作業の自由度を確保するため、ユーザの健康を守りながらユーザにとっての作業性を維持することができる。

本実施例では、自動承認の回数に制限を設けるため、ユーザの出した利用申請が全て自動承認されてしまうのを防止できる。これにより、ユーザの個人的判断のみで残業が行われるのを抑止できる。

本実施例では、利用申請Ｄ１の持つ緊急度が自動承認可能な緊急度ＥＡ，ＥＢであっても、残業時間制限条件（例えば図５の所定範囲Ｃ１６）を満たさないときは、自動承認しないため、法律または労使協定などを守ることができる。そして、残業時間制限条件を満たさない場合であっても、承認者の承認を得られた場合には、ユーザはＰＣ２０を例外的に利用することができる。

本実施例によれば、利用申請Ｄ１が自動承認の対象ではない場合、承認者による承認（手動承認）の対象となるため、承認者の判断で柔軟に対応することができる。

本実施例によれば、利用申請Ｄ１が自動承認されると、利用申請元のＰＣ２０と承認者ＰＣ３０との両方に利用申請Ｄ１が自動承認された旨が通知される。したがって、ユーザは利用申請Ｄ１が承認されたことを確認でき、承認者はユーザによるＰＣ利用状況を把握することができる。この通知を契機に承認者はユーザとコミュニケーションを図ることができ、より細かく状況を把握することもできる。

本実施例によれば、承認者ＰＣ３０への自動承認完了通知には、利用申請管理テーブルＴ２のうち該当部分の情報も含まれるため、承認者はユーザの労働状況を適切に管理することもできる。

図１２を用いて第２実施例を説明する。本実施例を含む以下の各実施例では、第１実施例との相違を中心に述べる。本実施例の利用管理サーバ１Ａに含まれる利用申請承認システム１４Ａは、利用申請Ｄ１を自動承認した場合に、ユーザに対して報告書の提出を要求する。

本実施例の利用申請承認システム１４Ａの自動承認部１４２Ａは、報告書提出要求部１４２１を備える。報告書提出要求部１４２１は、自動承認された利用申請Ｄ１についての報告書提出をユーザへ要求する。報告書提出要求部１４２１は、例えば、クライアントＰＣ２０の画面に、報告書提出を求めるポップアップ画面を表示させる。ユーザが報告書を作成してワークフローシステム１３に登録すると、報告書提出要求部１４２１は報告書の提出を確認し、ユーザへの要求を停止させる。

このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施例によれば、利用申請が自動承認された場合に報告書の提出を要求するため、ユーザは、気軽に利用申請を出しにくくなる。これにより、ユーザのＰＣ利用を自然に抑制することができ、無駄な利用を防止できる。本実施例によれば、利用申請（残業申請）の発行前にユーザに心理的制限をかけつつ、いったん利用申請が発行された場合は自動承認するため、無駄な利用を防止しつつユーザにとっての利便性を向上できる。

図１３を用いて第３実施例を説明する。本実施例では、クライアントＰＣ２０を利用可能な時間をグループ単位で管理しており、グループに属する複数ユーザがその時間を分け合って各自のＰＣ２０を使用する。

図１３は、本実施例で用いる自動承認設定値管理テーブルＴ１Ｂの例である。このテーブルＴ１Ｂは、第１実施例で述べたユーザのランクに代えて、ユーザの属するグループＣ１２Ｂ～Ｃ１５Ｂの単位で、自動承認を利用可能な回数を管理する。図１３の例では、第１緊急度ＥＡを利用可能な回数と第２緊急度ＥＢを利用可能な回数とのいずれもグループ単位で管理している。したがって、或るグループに属する誰か一人のユーザが回数を使い切ってしまった場合、そのグループに属する他のユーザは利用申請Ｄ１を出すことができなくなる。逆に、同一グループ内の或るユーザのＰＣ利用を他の各ユーザは支援することができる。

このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施例では、グループ単位でＰＣ２０の利用を管理できるため、より柔軟な管理運用を実現できる。本実施例は、第１、第２実施例のいずれとも結合させることができる。

図１４を用いて第４実施例を説明する。本実施例では、複数のユーザが共同作業する共同作業グループ内に、各自のＰＣ２０を利用可能な回数または時間が所定値以上異なる所定ユーザが含まれている場合、所定ユーザに対応する承認者に対して、所定ユーザがＰＣ２０を利用可能な回数または時間について通知する。

図１４は、利用申請承認システム１４により実行される利用申請設定調整処理Ｓ６０の例である。利用申請承認システム１４は、共同作業テーブルＴ３を参照し（Ｓ６１）、協同作業グループ毎にそのグループに所属するユーザの利用申請の設定（回数、時間）を利用申請管理テーブルＴ２から取得する（Ｓ６２）。共同作業テーブルＴ３は、各共同作業グループを識別する番号と、その共同グループに属するユーザを識別するユーザＩＤとを対応付けて管理する。利用申請承認システム１４は、ユーザＩＤに基づいて、利用申請管理テーブルＴ２を参照することができる。

利用申請承認システム１４は、共同作業グループ毎に、利用申請の設定が所定値以上異なる所定ユーザがいるか判定する（Ｓ６３）。例えば、自動承認残回数が同一共同作業グループ内の他のユーザよりも所定値以上少ないユーザ、自動承認可能な残業時間が他のユーザよりも所定値以上少ないユーザは、所定ユーザとして検出される。

利用申請承認システム１４は、所定ユーザを検出すると（Ｓ６３：ＹＥＳ）、その所定ユーザに対応する承認者ＰＣ３０に対して、所定ユーザについての利用申請の設定をあらかじめ調整した方が良い旨を通知する（Ｓ６４）。

このように構成される本実施例も第１～第３実施例と同様の作用効果を奏する。さらに本実施例によれば、共同で作業するグループ内に、自動承認についての設定が他のユーザと比べて所定値以上異なる所定ユーザが含まれている場合に、その所定ユーザの承認者に事前の設定調整について通知することができる。したがって、共同作業を円滑に進めることができ、共同作業中のトラブルにも対処することができ、ユーザにとっての使い勝手が向上する。本実施例は、第１～第３実施例のいずれとも結合させることができる。

図１５および図１６を用いて第５実施例を説明する。本実施例の利用管理システム１Ｃは、クライアントＰＣ２０Ｃ側にも利用申請承認機能システム２１３を設ける。

図１５の機能構成図に示すように、クライアントＰＣ２０Ｃのクライアントアプリケーション２１Ｃは、利用時間管理ＤＢ２１１と、通信状態判定部２１２と、ローカル利用申請承認システム２１３と、ローカルシャットダウンシステム２１４を備える。

利用時間管理ＤＢ２１１には、利用管理サーバ１０内の利用時間管理１２で管理されている情報のうち、クライアントＰＣ２０Ｃに対応する情報のコピーが記憶される。通信状態判定部２１２は、クライアントＰＣ２０Ｃと利用管理サーバ１０との通信が正常に（安定して）行われているか判定する。

ローカル利用申請承認システム２１３は、クライアント側の利用申請承認システムであり、クライアントＰＣ２０Ｃ内で発行された利用申請をクライアントＰＣ２０Ｃ内で自動承認可能か判断する。ローカルシャットダウンシステム２１４は、クライアント側のシャットダウンシステムであり、シャットダウン時刻（ＰＣ利用停止時刻）になるとクライアントＰＣ２０Ｃをシャットダウンさせる。

図１６は、クライアントＰＣ２０Ｃの実行するローカル利用申請承認処理Ｓ７０のフローチャートである。

クライアントＰＣ２０Ｃは、利用管理サーバ１０内の利用時間管理ＤＢ１２から当該クライアントＰＣ２０Ｃに対応する情報を取得し、取得した情報により利用時間管理ＤＢ２１１を更新する（Ｓ７１）。これにより、クライアント側の利用時間管理ＤＢ２１１は最新内容になる。

クライアントＰＣ２０Ｃは、クライアントアプリケーション２１Ｃから利用申請が発行されたか判定し（Ｓ７２）、利用申請が発行されると（Ｓ７２：ＹＥＳ）、サーバ１０との通信状態が正常であるか判定する（Ｓ７３）。例えば、クライアントＰＣ２０Ｃから通信状態を確認するためのコマンドを送信し、そのコマンドに対する応答が所定時間内に帰ってきた場合に、通信状態が正常であると判断することができる。

通信状態が異常な場合（Ｓ７３：ＮＯ）、クライアントＰＣ２０Ｃは、クライアントＰＣ２０Ｃ内で発行された利用申請を自動承認し、利用時間管理ＤＢ２１１を更新させる（Ｓ７４）。クライアントＰＣ２０Ｃと利用管理サーバ１０との間の通信状態が正常ではない場合、シャットダウンシステム１１からＰＣ利用時間変更情報などを安定して受信できない恐れがあるため、クライアントＰＣ２０Ｃ内で利用申請を処理する。

その後、定期的にクライアントＰＣ２０Ｃは、利用管理サーバ１０との通信状態が正常であるか確認する（Ｓ７５）。クライアントＰＣ２０Ｃは、利用管理サーバ１０との通信状態が正常になったら（Ｓ７５：ＹＥＳ）、利用時間管理ＤＢ２１１の情報を利用管理サーバ１０へ送信し、利用時間管理ＤＢ１２を更新させる（Ｓ７６）。

ＰＣ利用停止時刻になると、ローカルシャットダウンシステム２１４は、クライアントＰＣ２０Ｃを停止させることができる。

このように構成される本実施例も第１～第４実施例と同様の作用効果を奏する。さらに、本実施例によれば、クライアントＰＣ２０Ｃ内にも利用申請を自動承認する機能を設けたため、クライアントＰＣ２０Ｃと利用管理サーバ１０との通信状態が正常ではない場合でも、利用申請を自動承認することができ、ユーザにとっての使い勝手が向上する。

本来は自動承認の対象とならない利用申請についても、ローカル利用申請承認システム２１３は、自動承認の対象として取り扱い、その可否を判断することができる。この場合は、例えば、自動承認の対象ではない利用申請に第２緊急度ＥＢが割り当てられているものとみなして判断すればよい。本実施例は、第１～第４実施例のいずれとも結合させることができる。

なお、本発明は、上述した実施形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。上述の実施形態において、添付図面に図示した構成例に限定されない。本発明の目的を達成する範囲内で、実施形態の構成や処理方法は適宜変更することが可能である。

また、本発明の各構成要素は、任意に取捨選択することができ、取捨選択した構成を具備する発明も本発明に含まれる。さらに特許請求の範囲に記載された構成は、特許請求の範囲で明示している組合せ以外にも組合せることができる。

１，１Ａ，１Ｃ：利用管理システム１、１０：利用管理サーバ、１１：ＰＣ自動シャットダウンシステム、１２：利用時間管理データベース、１３：ワークフローシステム、１４：利用申請承認システム、２０，２０Ｃ：クライアントＰＣ、２１，２１Ｃ：クライアントアプリケーション、３０：承認者ＰＣ、４０：他システム、１４１：手動承認部、１４２，１４２Ａ：自動承認部、２１１：利用時間管理データベース、２１２：通信状態判定部、２１３：ローカル利用申請承認システム、２１４：ローカルシャットダウンシステム、１４２１：報告書提出要求部

Claims (15)

1. 対象機器の利用申請を承認する利用申請承認システムであって、
   前記対象機器の利用申請を受け付ける受付部と、
   複数の優先度で利用時間を管理する利用時間管理部の情報に基づいて、前記利用申請を自動承認するか判定する判定部と、
   を備える対象機器利用申請承認システム。
2. 前記利用時間管理部で管理される前記複数の優先度は、第１優先度と、前記第１優先度よりも低い値に設定される第２優先度とを含み、
   前記第１優先度の場合に第１時間の利用が自動承認され、前記利用申請が前記第２優先度の場合に前記第１時間よりも短い第２時間の利用が自動承認される、
   請求項１に記載の対象機器利用申請承認システム。
3. 前記第１優先度の場合に前記第１時間の利用が第１の上限回数まで自動承認され、前記利用申請が前記第２優先度の場合に前記第２時間の利用が前記第１の上限回数よりも多い第２の上限回数まで自動承認される、
   請求項２に記載の対象機器利用申請承認システム。
4. 前記利用時間管理部は、前記利用申請の発行者の属するグループに基づいて、前記複数の優先度を管理する、
   請求項１～３のいずれか一項に記載の対象機器利用申請承認システム。
5. 前記グループは、職位、部署、組織、勤務地、勤務条件、プロジェクトのいずれか一つまたは複数の観点で生成される、
   請求項４に記載の対象機器利用申請承認システム。
6. 前記判定部は、前記利用申請を自動承認しない場合に、前記利用申請を前記承認者の端末へ送信し、前記承認者による手動承認を依頼する、
   請求項１～５のいずれか一項に記載の対象機器利用申請承認システム。
7. 前記利用時間管理部は、前記第１上限回数または前記第２上限回数を前記グループ単位で管理する、
   請求項３に記載の対象機器利用申請承認システム。
8. 前記利用申請が自動承認された場合に、前記利用申請の発行元の端末に前記利用申請が自動承認された旨を通知する通知部をさらに備える、
   請求項１～７のいずれか一項に記載の対象機器利用申請承認システム。
9. 前記通知部は、前記利用申請が自動承認された場合に、前記利用申請の発行元の端末と前記利用申請の発行者に対応する承認者の端末との両方に、前記利用申請が自動承認された旨を通知する、
   請求項８に記載の対象機器利用申請承認システム。
10. 前記利用時間管理部は、ユーザが前記対象機器を利用可能な回数および時間を管理しており、
    前記通知部は、複数のユーザが共同作業する共同作業グループ内に、前記対象機器を利用可能な回数または時間が所定値以上異なる所定ユーザが含まれている場合に、前記所定ユーザに対応する承認者に対して、前記所定ユーザが前記対象機器を利用可能な回数または時間について通知する、
    請求項９に記載の対象機器利用申請承認システム。
11. 前記利用申請が自動承認された場合に、前記対象機器の利用についての報告書の提出を要求する報告書提出要求部をさらに備える、
    請求項１～１０のいずれか一項に記載の対象機器利用申請承認システム。
12. 前記利用申請が承認されなかった場合に前記対象機器の利用を抑制する抑制制御部をさらに備える請求項１～１１のいずれか一項に記載の対象機器利用申請承認システム。
13. 前記受付部は、管理サーバ内に設けられるサーバ側受付部と、クライアント端末内に設けられるクライアント側受付部とを備え、
    前記判定部は、前記管理サーバ内に設けられるサーバ側判定部と、前記クライアント端末内に設けられるクライアント側判定部とを備え、
    前記利用時間管理部は、前記管理サーバ内に設けられるサーバ側利用時間管理部と、前記クライアント端末内に設けられ、前記サーバ側利用時間管理部と連携するクライアント側利用時間管理部とを備え、
    前記クライアント端末内には、前記クライアント端末と前記管理サーバとが通信可能か判定する通信状態判定部が設けられており、
    前記利用申請が前記クライアント端末から発行された場合に、前記通信状態判定部が通信不能であると判定すると、前記利用申請は前記クライアント側受付部により受け付けられて、前記クライアント側判定部により自動承認するか判定され、判定結果に基づいて前記クライアント側利用時間管理部が更新され、
    前記クライアント側通知部から自動承認された旨が通知されるようになっており、
    前記通信状態判定部が前記クライアント端末と前記管理サーバとの通信が可能であると判定すると、前記クライアント側利用時間管理部の情報が前記サーバ側利用時間管理部へ送信されて、前記サーバ側利用時間管理部の情報が更新される、
    請求項１～７のいずれか一項に記載の対象機器利用申請承認システム。
14. 対象機器の利用申請を計算機を用いて承認する対象機器利用申請承認方法であって、
    前記対象機器の利用申請を受け付ける受付ステップと、
    複数の優先度で利用時間を管理する利用時間管理部の情報に基づいて、前記利用申請を自動承認するか判定する判定ステップと、
    を計算機で実行する対象機器利用申請承認方法。
15. 計算機を、対象機器の利用申請を承認する対象機器利用申請承認システムとして機能させるコンピュータプログラムであって、
    前記計算機に、
    前記対象機器の利用申請を受け付ける受付部と、
    複数の優先度で利用時間を管理する利用時間管理部の情報に基づいて、前記利用申請を自動承認するか判定する判定部と、
    を実現させるコンピュータプログラム。

Images