IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立ソリューションズの特許一覧

特開2022-45248対象機器利用申請承認システムおよび方法、コンピュータプログラム
<>
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図1
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図2
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図3
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図4
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図5
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図6
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図7
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図8
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図9
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図10
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図11
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図12
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図13
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図14
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図15
  • 特開-対象機器利用申請承認システムおよび方法、コンピュータプログラム 図16
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022045248
(43)【公開日】2022-03-18
(54)【発明の名称】対象機器利用申請承認システムおよび方法、コンピュータプログラム
(51)【国際特許分類】
   G06Q 10/06 20120101AFI20220311BHJP
【FI】
G06Q10/06
【審査請求】未請求
【請求項の数】15
【出願形態】OL
(21)【出願番号】P 2020150832
(22)【出願日】2020-09-08
(71)【出願人】
【識別番号】000233055
【氏名又は名称】株式会社日立ソリューションズ
(74)【代理人】
【識別番号】110000279
【氏名又は名称】特許業務法人ウィルフォート国際特許事務所
(72)【発明者】
【氏名】当田 圭吾
(72)【発明者】
【氏名】大石 圭一
(72)【発明者】
【氏名】松下 慎
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049AA07
(57)【要約】
【課題】対象機器の利用申請を適切に処理できるようにした対象機器利用申請承認システムおよび方法、コンピュータプログラムを提供すること。
【解決手段】対象機器20の利用申請を承認する利用申請承認システム14は、対象機器の利用申請D1を受け付ける受付部と、複数の優先度で利用時間を管理する利用時間管理部12の情報に基づいて、利用申請を自動承認するか判定する判定部と、を備える。
【選択図】図1
【特許請求の範囲】
【請求項1】
対象機器の利用申請を承認する利用申請承認システムであって、
前記対象機器の利用申請を受け付ける受付部と、
複数の優先度で利用時間を管理する利用時間管理部の情報に基づいて、前記利用申請を自動承認するか判定する判定部と、
を備える対象機器利用申請承認システム。
【請求項2】
前記利用時間管理部で管理される前記複数の優先度は、第1優先度と、前記第1優先度よりも低い値に設定される第2優先度とを含み、
前記第1優先度の場合に第1時間の利用が自動承認され、前記利用申請が前記第2優先度の場合に前記第1時間よりも短い第2時間の利用が自動承認される、
請求項1に記載の対象機器利用申請承認システム。
【請求項3】
前記第1優先度の場合に前記第1時間の利用が第1の上限回数まで自動承認され、前記利用申請が前記第2優先度の場合に前記第2時間の利用が前記第1の上限回数よりも多い第2の上限回数まで自動承認される、
請求項2に記載の対象機器利用申請承認システム。
【請求項4】
前記利用時間管理部は、前記利用申請の発行者の属するグループに基づいて、前記複数の優先度を管理する、
請求項1~3のいずれか一項に記載の対象機器利用申請承認システム。
【請求項5】
前記グループは、職位、部署、組織、勤務地、勤務条件、プロジェクトのいずれか一つまたは複数の観点で生成される、
請求項4に記載の対象機器利用申請承認システム。
【請求項6】
前記判定部は、前記利用申請を自動承認しない場合に、前記利用申請を前記承認者の端末へ送信し、前記承認者による手動承認を依頼する、
請求項1~5のいずれか一項に記載の対象機器利用申請承認システム。
【請求項7】
前記利用時間管理部は、前記第1上限回数または前記第2上限回数を前記グループ単位で管理する、
請求項3に記載の対象機器利用申請承認システム。
【請求項8】
前記利用申請が自動承認された場合に、前記利用申請の発行元の端末に前記利用申請が自動承認された旨を通知する通知部をさらに備える、
請求項1~7のいずれか一項に記載の対象機器利用申請承認システム。
【請求項9】
前記通知部は、前記利用申請が自動承認された場合に、前記利用申請の発行元の端末と前記利用申請の発行者に対応する承認者の端末との両方に、前記利用申請が自動承認された旨を通知する、
請求項8に記載の対象機器利用申請承認システム。
【請求項10】
前記利用時間管理部は、ユーザが前記対象機器を利用可能な回数および時間を管理しており、
前記通知部は、複数のユーザが共同作業する共同作業グループ内に、前記対象機器を利用可能な回数または時間が所定値以上異なる所定ユーザが含まれている場合に、前記所定ユーザに対応する承認者に対して、前記所定ユーザが前記対象機器を利用可能な回数または時間について通知する、
請求項9に記載の対象機器利用申請承認システム。
【請求項11】
前記利用申請が自動承認された場合に、前記対象機器の利用についての報告書の提出を要求する報告書提出要求部をさらに備える、
請求項1~10のいずれか一項に記載の対象機器利用申請承認システム。
【請求項12】
前記利用申請が承認されなかった場合に前記対象機器の利用を抑制する抑制制御部をさらに備える請求項1~11のいずれか一項に記載の対象機器利用申請承認システム。
【請求項13】
前記受付部は、管理サーバ内に設けられるサーバ側受付部と、クライアント端末内に設けられるクライアント側受付部とを備え、
前記判定部は、前記管理サーバ内に設けられるサーバ側判定部と、前記クライアント端末内に設けられるクライアント側判定部とを備え、
前記利用時間管理部は、前記管理サーバ内に設けられるサーバ側利用時間管理部と、前記クライアント端末内に設けられ、前記サーバ側利用時間管理部と連携するクライアント側利用時間管理部とを備え、
前記クライアント端末内には、前記クライアント端末と前記管理サーバとが通信可能か判定する通信状態判定部が設けられており、
前記利用申請が前記クライアント端末から発行された場合に、前記通信状態判定部が通信不能であると判定すると、前記利用申請は前記クライアント側受付部により受け付けられて、前記クライアント側判定部により自動承認するか判定され、判定結果に基づいて前記クライアント側利用時間管理部が更新され、
前記クライアント側通知部から自動承認された旨が通知されるようになっており、
前記通信状態判定部が前記クライアント端末と前記管理サーバとの通信が可能であると判定すると、前記クライアント側利用時間管理部の情報が前記サーバ側利用時間管理部へ送信されて、前記サーバ側利用時間管理部の情報が更新される、
請求項1~7のいずれか一項に記載の対象機器利用申請承認システム。
【請求項14】
対象機器の利用申請を計算機を用いて承認する対象機器利用申請承認方法であって、
前記対象機器の利用申請を受け付ける受付ステップと、
複数の優先度で利用時間を管理する利用時間管理部の情報に基づいて、前記利用申請を自動承認するか判定する判定ステップと、
を計算機で実行する対象機器利用申請承認方法。
【請求項15】
計算機を、対象機器の利用申請を承認する対象機器利用申請承認システムとして機能させるコンピュータプログラムであって、
前記計算機に、
前記対象機器の利用申請を受け付ける受付部と、
複数の優先度で利用時間を管理する利用時間管理部の情報に基づいて、前記利用申請を自動承認するか判定する判定部と、
を実現させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、対象機器利用申請承認システムおよび方法、コンピュータプログラムに関する。
【背景技術】
【0002】
多くの者にとってパーソナルコンピュータ(以下、PC)は、仕事や作業を進めるために欠かせない電子機器である。一方、ユーザ(労働者)は、つい時間を忘れてPC作業に集中してしまい、残業時間が長くなることがある。最近は、自宅または最寄りのサテライトオフィスなどでPCを操作するテレワークが広まっているが、テレワークの場合は勤務時間が長くなりやすいと言われている。しかし、法律、労使協定、勤務条件などで制限されている残業時間を超えて働くのは、通常、好ましくない。このためユーザは、事前申告せずに隠れて残業するという、いわゆるサービス残業をすることがある。または、ユーザは、上司の許可なく自分だけの判断で不要不急の残業をすることもある。
【0003】
このように、個人判断による長時間残業の抑止、サービス残業の抑止、テレワーカの働き過ぎ抑止の観点から、残業時間の管理が求められている。一方、トラブル発生時など緊急事態では、営業時間外であってもPCを操作して対応せざるを得ない。
【0004】
そこで、残業を適切に管理するための技術が提案されている(特許文献1,2)。特許文献1の労働時間管理システムは、組織の労働者の労働時間を管理する労働時間管理サーバを備え、労働時間管理サーバは、労働者の個人別の勤務状況を把握する勤休管理部と、労働者の個人別の勤務条件を判定する個人別勤務条件判定部と、労働者の個人別の勤務状況に基づいて、労働者の個人別の労働時間を把握し、労働者の個人別の労働時間が、勤務条件における許容労働時間に対応する上限閾値を越える状態かどうかを判定する労働時間判定部と、上限閾値を超える状態である労働者について、抑止対象者として、抑止対象者が設備またはエリアを利用して業務を行うことを不可能とするように、設備またはエリアの利用を不許可とする抑止制御を行う抑止制御部とを備える。
【0005】
特許文献2では、時間外勤務申請の承認者として、複数の時間帯ごとに承認者の設定を受け付け、受け付けた設定に基づき受理される時間外勤務申請の履歴を記憶し、記憶される履歴に基づき労務管理を実行する。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2019-045921号公報
【特許文献2】特開2019-061475号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
従来技術では、PCを利用する不要な残業を強制的に抑止したり、勤務状況に応じて管理態様を柔軟に設定したりしている。しかし、緊急事態の発生を予見するのは困難なため、残業を許可する権限を持つ上司が常時速やかに緊急時の残業申請を判断できる保証はなく、かつ、承認の手間がかかる。一方、深夜や早朝などの営業時間外に出された残業申請を無制限に認めるのでは、個人判断による勝手な残業を抑止することができない。
【0008】
本発明は、上記問題に鑑みてなされたもので、その目的は、対象機器の利用申請を適切に処理できるようにした対象機器利用申請承認システムおよび方法、コンピュータプログラムを提供することにある。
【課題を解決するための手段】
【0009】
上記課題を解決すべく、本発明の一つの観点に従う利用申請承認システムは、対象機器の利用申請を承認する利用申請承認システムであって、対象機器の利用申請を受け付ける受付部と、複数の優先度で利用時間を管理する利用時間管理部の情報に基づいて、利用申請を自動承認するか判定する判定部と、を備える。
【0010】
利用時間管理部で管理される複数の優先度は、第1優先度と、第1優先度よりも低い値に設定される第2優先度とを含み、第1優先度の場合に第1時間の利用が自動承認され、利用申請が第2優先度の場合に第1時間よりも短い第2時間の利用が自動承認されてもよい。
【0011】
第1優先度の場合に第1時間の利用が第1の上限回数まで自動承認され、利用申請が第2優先度の場合に第2時間の利用が第1の上限回数よりも多い第2の上限回数まで自動承認されてもよい。
【0012】
利用時間管理部は、利用申請の発行者の属するグループに基づいて、複数の優先度を管理することができる。
【0013】
グループは、職位、部署、組織、勤務地、勤務条件、プロジェクトのいずれか一つまたは複数の観点で生成されてもよい。
【0014】
判定部は、利用申請を自動承認しない場合に、利用申請を承認者の端末へ送信し、承認者による手動承認を依頼することもできる。
【0015】
利用時間管理部は、第1上限回数または第2上限回数をグループ単位で管理することもできる。
【0016】
利用申請が自動承認された場合に、利用申請の発行元の端末に利用申請が自動承認された旨を通知する通知部をさらに備えてもよい。
【0017】
通知部は、利用申請が自動承認された場合に、利用申請の発行元の端末と利用申請の発行者に対応する承認者の端末との両方に、利用申請が自動承認された旨を通知することもできる。
【0018】
利用時間管理部は、ユーザが対象機器を利用可能な回数および時間を管理しており、通知部は、複数のユーザが共同作業する共同作業グループ内に、対象機器を利用可能な回数または時間が所定値以上異なる所定ユーザが含まれている場合に、所定ユーザに対応する承認者に対して、所定ユーザが対象機器を利用可能な回数または時間について通知することもできる。
【0019】
利用申請が自動承認された場合に、対象機器の利用についての報告書の提出を要求する報告書提出要求部をさらに備えることもできる。
【0020】
利用申請が承認されなかった場合に対象機器の利用を抑止する抑制制御部をさらに備えてもよい。
【0021】
受付部は、管理サーバ内に設けられるサーバ側受付部と、クライアント端末内に設けられるクライアント側受付部とを備え、判定部は、管理サーバ内に設けられるサーバ側判定部と、クライアント端末内に設けられるクライアント側判定部とを備え、利用時間管理部は、管理サーバ内に設けられるサーバ側利用時間管理部と、クライアント端末内に設けられ、サーバ側利用時間管理部と連携するクライアント側利用時間管理部とを備え、クライアント端末内には、クライアント端末と管理サーバとが通信可能か判定する通信状態判定部が設けられており、利用申請がクライアント端末から発行された場合に、通信状態判定部が通信不能であると判定すると、利用申請はクライアント側受付部により受け付けられて、クライアント側判定部により自動承認するか判定され、判定結果に基づいてクライアント側利用時間管理部が更新され、クライアント側通知部から自動承認された旨が通知されるようになっており、通信状態判定部がクライアント端末と管理サーバとの通信が可能であると判定すると、クライアント側利用時間管理部の情報がサーバ側利用時間管理部へ送信されて、サーバ側利用時間管理部の情報が更新されてもよい。
【発明の効果】
【0022】
本発明によれば、複数の優先度で利用時間を管理し、利用申請を自動承認するか判定することができるため、利用申請を適切に管理することができる。
【図面の簡単な説明】
【0023】
図1】本実施例に係るコンピュータ利用申請承認システムを含むシステム全体の機能構成図。
図2】利用管理サーバおよびクライアントPCとして使用可能な計算機のハードウェア構成図。
図3】承認処理のフローチャート。
図4図3中の承認種別を判定するステップの詳細を示すフローチャート。
図5】自動承認のための設定値を管理するテーブルの例。
図6】利用申請を管理するテーブルの例。
図7図3中の手動承認処理の詳細を示すフローチャート。
図8】手動承認の流れを示す機能構成図。
図9図3中の自動承認処理の詳細を示すフローチャート。
図10】自動承認処の流れを示す機能構成図。
図11】クライアントPCをシャットダウンさせる処理を示すフローチャート。
図12】第2実施例に係るコンピュータ利用申請承認システムを含むシステム全体の機能構成図。
図13】第3実施例に係り、自動承認のための設定値を管理するテーブルの例。
図14】第4実施例に係り、共同作業グループ内で利用申請の設定調整を促進する処理を示すフローチャート。
図15】第5実施例に係るコンピュータ利用申請承認システムを含むシステム全体の機能構成図。
図16】クライアントPC内で利用申請を承認する処理を示すフローチャート。
【発明を実施するための形態】
【0024】
以下、図面に基づいて、本発明の実施の形態を説明する。本実施形態に係る利用申請承認システム14は、対象機器20を利用するための利用申請D1が自動承認可能か否か判定し、承認可能と判定した場合は自動承認する。緊急事態への対応など急な残業が必要になったユーザは、本システム14に利用申請を送信することにより、ただちに対象機器20を利用することができる。
【0025】
本実施形態では、利用申請の対象となる機器20として、PCを例に挙げる。PCの種類は問わない。例えば、デスクトップ型PC、ラップトップ型PC、タブレット型PC、ウェアラブル型PC、スマートフォン型PCなどでもよい。対象機器20は、ユーザが仕事(作業)に使用する機器であればよく、PCに限らない。例えば、測定装置、実験装置、試作品製造装置、3Dプリンタ、3Dスキャナなどの、通信機能と制御機能を備える電子機器の利用申請も、本システム14で管理することができる。
【0026】
本実施形態では、利用申請承認システム14をワークフローシステム13およびPC自動シャットダウンシステム11と連携させることにより、利用管理システム1の一機能として利用しているが、これに限らず、利用申請承認システム14単体で独立したサービスを提供することもできる。
【0027】
すなわち、この場合は、クライアントPC20からの利用申請を自動承認できるか判定し、その結果をクライアントPC20へ返信するサービスを提供することができる。ユーザは、自動承認されなかった場合でも、それを無視してクライアントPC20を利用することはできる。
【0028】
しかし、利用申請が承認されなかったことは利用時間管理部12に記録されるため、図示せぬ勤怠管理システムで管理されている情報と照合することにより、所定時刻(例えば終業時刻)後に未承認の機器利用(残業)が行われたことは、客観的に明らかとなる。したがって、承認を得ずに機器を利用したユーザに対して、残業時間の適切な管理について意識付けすることができ、未承認の残業の発生を抑制する効果を期待できる。
【0029】
本実施形態では、対象機器の一例としてのPC20の利用を管理することにより、PCを用いて仕事をするユーザの残業を管理することができる。したがって、対象機器利用申請承認システムとしの利用申請承認システム14は、残業申請承認システムと呼ぶこともできる。
【実施例0030】
図1図11を用いて第1実施例を説明する。図1は、利用申請承認システム14を含む利用管理システム1の全体の機能構成図である。
【0031】
利用管理システム1は、クライアントPC(以下、PCと略記する場合がある。)20の利用を管理する情報処理システムであって、利用管理サーバ10を含む。利用管理システム1は、利用管理サーバ10と、クライアントPC20と、承認者PC30とを備えている。図中では、クライアントPC20と承認者PC30とをそれぞれ1つずつ示すが、実際には複数のクライアントPC20と承認者PC30とが利用管理サーバ10に接続されている。
【0032】
利用管理サーバ10は、クライアントPC20からの利用申請データD1(以下、利用申請D1)を受け付けてその可否を判定し、判定結果に基づいてクライアントPC20へ通知したり、クライアントPC20の動作を遠隔制御したりする。
【0033】
利用管理サーバ10は、例えば、PC自動シャットダウンシステム(以下、シャットダウンシステムと略記する場合がある。)11と、利用時間管理データベース12と、ワークフローシステム13と、利用申請承認システム14とを備える。以下、データベースをDBと略記する。
【0034】
利用管理サーバ10を、図2で後述する汎用計算機100を用いて構築する場合、シャットダウンシステム11、利用時間管理DB12、ワークフローシステム13および利用申請承認システム14は、コンピュータプログラムおよびデータによって実現することができる。これら各機能11,12,13,14を実現するために、専用計算機または専用回路などを用いてもよい。さらに、一つの物理計算機または仮想計算機から利用管理サーバ10を構成してもよいし、複数の物理計算機または仮想計算機を連携させることにより利用管理サーバ10を構成してもよい。
【0035】
シャットダウンシステム11は、クライアントPC20をシャットダウンさせるスケジュールを管理し、クライアントPC20のクライアントアプリケーション21からの問合せに応じてスケジュールを配信する。シャットダウンシステム11とクライアントアプリケーション21とによって「抑制制御部」が実現される。
【0036】
クライアントPC20をシャットダウンさせる方法は幾つかある。第1の方法は、本実施例のように、クライアントアプリケーション21が、シャットダウンシステム11から通知されたスケジュールにしたがって、クライアントPC20をシャットダウンさせる方法である。第2の方法は、シャットダウンシステム11がスケジュールにしたがって遠隔操作でクライアントPCをシャットダウンさせる方法である。いずれの方法を採用してもよい。
【0037】
PC20の利用を抑制する方法は、シャットダウンに限らない。例えば、モニタディスプレイの表示を停止させたり、キーボードスイッチからの入力の受付を禁止したりといったように、クライアントPC20の持つ複数の機能のうちの一つまたは複数の機能を止めたり、制限したりすることで、PC20の利用を抑制してもよい。機能の制限としては、例えば、音声出力または音声入力のレベルを低くする、モニタディスプレイの解像度や色数を少なくする、ファイル保存など必要最低限の操作以外のキーボード入力を禁止する、といった方法がある。
【0038】
「利用時間管理部」の例としての利用時間管理DB12は、ユーザ毎のPC利用時間および利用条件といった利用管理情報を管理する。利用管理情報の少なくとも一部は、承認者またはシステム管理者が手動で設定することができる。承認者とは、ユーザがクライアントPC20を利用することについての承認を与える権限を持つ者であり、一般的には上司が該当する。ただし本実施例では、承認者はユーザの上司に限らない。ユーザと同一の職位または下位の職位になる者であっても、承認権限を持つ者は承認者に該当する。さらには、ユーザとは別の企業または組織に属する者であっても、承認権限を持つ者は承認者に該当する。
【0039】
ワークフローシステム13は、ユーザの業務の一連の処理手続を管理する。本実施例では、クライアントPC20からの利用申請D1をワークフローシステム13を介して利用申請承認システム14に入力する。これにより、ユーザの業務との関係でPC利用時間(残業時間とも呼ぶ。)を管理することができ、どの業務について誰の承認を得たかなどを記録することもでき、利便性が向上する。ただし、クライアントPC20からの利用申請D1を、ワークフローシステム13を介さずに利用申請承認システム14へ直接入力してもよい。本実施例で述べる種々の利点は、本実施例の利用申請承認システム14の構成を何ら限定しない。
【0040】
「対象機器利用申請承認システム」としての利用申請承認システム14は、クライアントPC20からの利用申請D1を受け付けて、その利用申請D1を自動承認するか否か判定する。
【0041】
利用申請承認システム14は、手動承認部141と自動承認部142を備える。手動承認部141は、承認者の判断により利用申請D1を承認させる機能である。自動承認部142は、所定の条件を満たす場合に、利用申請D1を自動承認する機能である。各承認部141,142の詳細は、図7図10で後述する。
【0042】
クライアントPC20は、上述の通り「対象機器」の一例である。クライアントPC20は、利用管理サーバ10の提供するサービスを利用するためのクライアントアプリケーション21がインストールされている。図中では、アプリケーションプログラムをAppと略記する。
【0043】
クライアントアプリケーション21は、シャットダウンシステム11からシャットダウン時刻を定期的に取得し、シャットダウン時刻が到来するとクライアントPC20をシャットダウンさせる。なお、上述の通り、シャットダウンというPC20の完全な機能停止に代えて、PC20の持つ各機能のうちの一部の機能の停止、または一部の機能の低下により、ユーザの作業を実質的に中断させることもできる。
【0044】
クライアントアプリケーション21は、複数のタイミングで、シャットダウンの予定時刻(シャットダウン時刻)をユーザに通知することができる。例えば、クライアントアプリケーション21は、PC20の起動時、シャットダウン時刻の所定時間前、シャットダウン時刻を過ぎた後などでメッセージをPC20の画面に表示させる。毎正時にシャットダウン時刻を画面表示させたり、カウントダウンタイマを画面の隅に表示させたりしてもよい。
【0045】
シャットダウンの予定時刻を過ぎた後も作業を続けたいユーザは、クライアントアプリケーション21から利用管理サーバ10へ向けて利用申請D1を発行する。この利用申請D1が利用申請承認システム14により承認されると、利用時間管理DB12で管理されているシャットダウンを予定している時刻が更新される。後述の図11では、シャットダウン時刻をPC利用停止時刻と表記している。
【0046】
クライアントアプリケーション21は、更新されたシャットダウン時刻をシャットダウンシステム11から取得するため、更新されたシャットダウン時刻になるまでPC20をシャットダウンさせない。
【0047】
なお、いったんシャットダウンした後でも、ユーザはPC20を再起動させて所定の猶予時間(例えば数分間)だけPC20を操作することができる。ユーザは、猶予時間内にクライアントアプリケーション21から利用管理サーバ10へ利用申請D1を送信させることができる。
【0048】
利用申請承認システム14による利用申請の承認、利用時間管理DB12の更新、シャットダウンシステム11からのシャットダウン時刻の変更通知といった一連の承認処理が猶予時間の終了前に終了した場合、ユーザはPC20をそのまま使用できる。一連の承認処理が猶予時間の終了に間に合わなかった場合、PC20は再びシャットダウンする。この場合、ユーザは、少し待ってからPC20を再起動させることにより、PC20を使用することができる。
【0049】
承認者PC30は、承認者の使用するPCである。承認者PC30は、利用申請承認システム14からの利用申請承認通知を受信して承認者に知らせる機能を有していればよいため、必ずしもPCである必要はない。通信機能と表示機能(あるいは音声出力機能)を備える端末であればよい。したがって、承認者PC30は、携帯情報端末、携帯電話(いわゆるスマートフォンを含む)のような装置でもよい。
【0050】
他システム40は、利用管理サーバ10と連携するシステムである。他システム40には、例えば、勤怠管理システム、経費管理システム、人事考課システムなどの、利用時間管理DB12の情報を利用可能なシステムが含まれる。ただし、他システム40との連携がない場合でも、本実施例は有効に機能する。
【0051】
図2を用いて、利用管理サーバ10またはクライアントPC20として使用可能な計算機100の概略構成を説明する。
【0052】
計算機100は、例えば、プロセッサ101、主記憶装置102、補助記憶装置103、入力装置104、出力装置105および通信装置106を備える。プロセッサ101は、補助記憶装置103に記憶されたコンピュータプログラムを主記憶装置102へ読み出して実行することにより、所定の機能を実現させる。
【0053】
所定の機能とは、計算機100を利用管理サーバ10として用いる場合は、図1で述べたシャットダウンシステム11、利用時間管理DB12、ワークフローシステム13および利用申請承認システム14である。計算機100をクライアントPC20として用いる場合は、クライアントアプリケーション21が所定の機能となる。なお、計算機100を承認者PC30として用いてもよい。
【0054】
入力装置104は、オペレータ(またはユーザ)が計算機100へ情報を入力するための装置であり、例えば、キーボードスイッチ、タッチパネル、音声入力装置などの全部または一部を含む。出力装置105は、計算機100からオペレータ(またはユーザ)へ情報を提供するための装置であり、例えば、モニタディスプレイ、プリンタ、音声合成装置などの全部または一部を含む。
【0055】
記憶媒体MMは、計算機100に接続され、計算機100との間でコンピュータプログラム(またはデータを含む。)を送受信する。記憶媒体MMに記憶されたコンピュータプログラムを補助記憶装置103に記憶させることもできるし、補助記憶装置103に記憶されたコンピュータプログラムを記憶媒体MMへ転送して記憶させることもできる。
【0056】
図3図11を用いて、承認処理を説明する。図3の説明に際して図8の機能構成図が適宜参照される。
【0057】
まず最初に、シャットダウン予定時刻以降もPC20の使用を希望するユーザは、クライアントアプリケーション21を用いて利用申請D1を作成し、この利用申請D1を利用管理サーバ10のワークフローシステム13へ送信する(S11)。利用申請D1は、例えば、ユーザID、利用対象日(残業予定日)、利用時間、緊急度(EA,EB,ECのいずれか一つ)、申請理由を含むことができる。これら以外の情報を利用申請D1は含んでもよい。
【0058】
利用時間は、利用開始時刻と利用時間とにより定義してもよいし、利用開始時刻と利用終了時刻とにより定義してもよい。ユーザIDに代えて、あるいはユーザIDと共にユーザ氏名を利用申請D1に含めてもよい。
【0059】
緊急度は「優先度」に該当し、利用申請D1の緊急性または重要性を示すランク情報である。本実施例では、緊急度として、第1緊急度EA,第2緊急度EB,第3緊急度ECの3つを例に挙げる。
【0060】
第1緊急度EAは「第1優先度」に対応し、トラブルへの本格的対処などの緊急度が高く時間もかかる仕事のために使用される。第2緊急度EBは「第2優先度」に対応し、ちょっとした作業などの緊急性が高くなく短時間で完了しうる仕事のために使用される。第3緊急度ECは、緊急性のない作業のために使用される。第1緊急度EAおよび第2緊急度EBは、利用申請承認システム14による自動承認の判定対象となる。第3緊急度ECは、利用申請承認システム14による自動承認の判定対象とはならない。すなわち、第3緊急度ECを有する利用申請D1は、手動承認の対象として処理される。
【0061】
ワークフローシステム13は、クライアントPC20のクライアントアプリケーション21から発行された利用申請D1を受信すると、この利用申請D1の承認について利用申請承認システム14へ問い合わせる(S12)。
【0062】
ワークフローシステム13からの問合せを受領した利用申請承認システム14は、利用申請D1に含まれているユーザIDに基づいて利用時間管理DB12を参照し、自動承認条件を満たすか否か判定するための情報をDB12から取得する(S13)。自動承認条件を満たすか否か判定するための情報としては、例えば、ユーザの役職(ランク)、勤怠状況(例えば当月および前月の残業時間)を挙げることができる。
【0063】
利用申請承認システム14は、利用申請D1の承認種別を判定する(S14)。すなわち、利用申請承認システム14は、受け付けた利用申請D1を自動承認するか手動承認するか判定する(S14)。
【0064】
利用申請承認システム14が利用申請D1を手動承認すると判定すると(S14:手動)、後述の手動承認処理が実行される(S20)。利用申請承認システム14が利用申請D1を自動承認すると判定すると(S14:自動)、自動承認部142により後述の自動承認処理が実行される(S30)。
【0065】
図3中のステップS12は、「対象機器の利用申請を受け付ける受付部」または「受付ステップ」に対応する。図3中のステップS14は、「利用申請を自動承認するか判定する判定部」または「判定ステップ」に対応する。ステップS12は、判定用の情報を利用時間管理部12から取得する「情報取得部」または「情報取得ステップ」と呼ぶこともできる。なお、後述の図9中のステップS31,S32は「通知部」または「通知ステップ」に対応する。
【0066】
図4を用いて、承認種別を判定するステップS14の詳細を説明する。利用申請承認システム14は、利用申請D1からユーザIDと緊急度Eと利用対象日および利用時間SOTを取得する(S141)。以下、利用対象日については記載を省略する。
【0067】
利用申請承認システム14は、利用申請D1の緊急度Eが第1緊急度EAまたは第2緊急度EBであるか判定する(S142)。判断対象の利用申請D1が第1緊急度EAまたは第2緊急度EBを持つ場合(S142:YES)、利用申請承認システム14は、利用申請D1を提出したユーザIDに対応する自動承認残回数NEが1以上であるか判定する(S143)。自動承認残回数NEとは、自動承認される残り回数である。自動承認残回数NEが0になった場合は、緊急度EAの利用申請であっても自動承認されない。ただし、承認者が、利用申請承認システム14を介して、利用時間管理DB12内の自動承認残回数NEを1以上に書き換えた更新した場合は、自動承認される。
【0068】
自動承認残回数NEが1以上の場合(S143:YES)、利用申請D1に記載された利用時間SOTが所定範囲内であるか判定する(S144)。所定範囲とは、法律、労使協定、労働条件などで定められた時間内のことである。自動承認による過度な労働を未然に防止するために、ステップS144が設けられている。利用時間が所定範囲であることの例は、図5で後述する。
【0069】
利用申請D1に記載された利用時間が所定範囲内の場合(S144:YES)、その利用申請D1は自動承認すべきと判定され(S145)、図3のステップS14へ戻る。利用申請D1に記載された利用時間が所定範囲内ではない場合(S144:NO)、その利用申請D1は手動承認すべきと判定され(S146)、ステップS14へ戻る。
【0070】
図5は、利用時間管理DB12に記憶されている自動承認設定値管理テーブルT1の例である。このテーブルT1は、利用申請D1を自動承認するための条件を管理する。このテーブルT1は、例えば、緊急度付与回数C11、ランクC12~C15、利用時間の所定範囲C16を含む。
【0071】
緊急度付与回数C11とは、緊急度毎に付与されている、自動承認が認められる回数(自動承認付与回数とも呼ぶ。)である。付与回数は、緊急度ごとに、ユーザの属するランクC12~C15に応じて、設定される。ランク順序は、ランク1>ランク2>ランク3>ランク4であるとする。高いランクほど、緊急度ごとの自動承認付与回数は多い。付与回数の下に記載されたかっこ付きの数字は、繰り越し可能回数を示す。図5の例では、最大2ヶ月分の繰り越しが認められている。
【0072】
同一ランクの場合、第1緊急度EAの付与回数よりも第2緊急度EBの付与回数の方が少なくなるように設定されている。図示の例では、第1緊急度EAに付与される回数に対して第2緊急度EBに付与される回数は2倍である。ただし、図示された具体的数値は、説明の便宜上表示されているに過ぎず、他の数値であってもよい。
【0073】
所定範囲C16の例を説明する。第1緊急度EAを持つ利用申請D1(残業申請)は、無条件で自動承認されるが、残業時間が以下に述べる所定範囲内であることが条件になっている。所定範囲C16は、残業時間制限条件と呼ぶこともできる。
【0074】
例えば、第1緊急度EAの場合、当月の残業申請が自動承認されるためには、当月の残業時間が第1残業時間(例えば40時間)以下であることが必要である。当月の残業時間が第1残業時間を超えている場合、一日あたり第2残業時間(例えば5時間)以下の残業が自動承認される。当月の残業時間が第3残業時間(=第1残業時間+第2残業時間。例えば45時間)を超えた場合、翌月の残業は承認されない。なお、第4残業時間(例えば100時間)未満までの残業が特別に認められているユーザの場合、翌月に残業申請が自動承認されるためには、あらかじめ承認者(例えば上司)の承諾が必要となる。
【0075】
第2緊急度EBを持つ利用申請D1は、条件付きで自動承認される。条件とは一回の残業時間が第5残業時間(例えば4時間)以内であるか、もしくは第6残業時刻(例えば22時)まで、であることである。第2緊急度EBを持つ利用申請D1がこの条件を満たす場合、当月の残業時間が第1残業時間まで自動承認される。
【0076】
以下、第1緊急度の所定条件と同様に、前月の残業時間が第1残業時間を超えている場合、利用申請は、一日あたり第7残業時間(例えば2時間)まで自動承認される。当月の残業時間が第3残業時間を超えた場合、翌月の残業は承認されない。第4残業時間未満までの残業が特別に認められているユーザの場合、翌月に残業申請が自動承認されるためには、あらかじめ承認者の承諾が必要となる。
【0077】
図6は、利用時間管理DB12に格納されている、利用申請を管理するテーブルT2の例である。利用申請管理テーブルT2は、例えば、ユーザID C21と、ランクC22と、緊急度C23と、利用日C24と、申請された利用時間C25と、前月の利用時間C26と、当月の利用時間C27と、第1緊急度EAの自動承認残回数C28と、第2緊急度EBの自動承認残回数EBとを管理する。図中、一部の表記を簡略化している。
【0078】
ユーザID C21は、利用申請承認システム14で管理される各ユーザを識別する情報である。ランクC22は、ユーザの属するランク(役職、職位など)である。ランクC22の分類方法は、役職または職位に限らない。例えば、ユーザの部署、組織、勤務地、勤務条件、プロジェクトのいずれか一つまたは複数の観点でランク分けしてもよい。それら部署、組織、勤務地、勤務条件、プロジェクトなどによって、PC20を利用する回数および時間が相違する場合があるためである。
【0079】
緊急度C23は、利用申請の緊急度である。緊急度はユーザが指定する。利用日C24は、PC20の利用日、つまり本実施例では残業日である。申請利用時間C24は、所定時刻(終業時刻)を超えてユーザがPC20を利用した時間、つまり本実施例では残業時間である。前月利用時間C26は、前月に、ユーザが所定時刻を超えてPC20を利用した時間の合計、つまり本実施例では前月残業時間である。当月利用時間C27は、当月に、ユーザが所定時刻を越えてPC20を利用した時間の合計、つまり本実施例では当月残業時間である。
【0080】
第1緊急度の自動承認残回数C28は、ユーザが第1緊急度EAの利用申請D1を発行可能な残回数を示す。第2緊急度の自動承認残回数C29は、ユーザが第2緊急度EBの利用申請D1を発行可能な残回数を示す。
【0081】
図7は、手動承認処理(S20)の詳細を示すフローチャートである。処理の流れを図8に示す。
【0082】
利用申請承認システム14は、手動承認の場合に、例えば、承認者PC30へ利用申請D1を含む電子メールを送信し、承認を依頼する(S21)。依頼された承認者は、利用申請D1の内容を見て承認するか否か判断する。承認者PC30は、承認者の決定を取得すると、ワークフローシステム13にアクセスして承認処理する。
【0083】
ワークフローシステム13は、承認された利用申請D1に記載された利用時間をPC利用時間変更情報として利用時間管理DB12へ記録する(S23)。すなわち、DB12で管理されているPC利用停止時刻に利用申請D1に記載された利用時間を加えることにより、PC利用停止時刻(シャットダウン時刻)を更新させる。
【0084】
シャットダウンシステム11は、クライアントアプリケーション21からカレンダおよびPC利用時間変更情報の送信要求を受領すると(S24)、利用時間管理DB12からカレンダおよびPC利用時間変更情報を取得し(S25)、それらカレンダおよびPC利用時間変更情報をクライアントアプリケーション21へ送信する(S26)。
【0085】
図9は、自動承認処理(S30)の詳細を示すフローチャートである。処理の流れを図10に示す。
【0086】
利用申請承認システム14は、利用申請D1を自動承認した旨を承認者PC30へ通知する(S31)。同時に利用申請承認システム14は、利用申請D1を発行したクライアントPC20のクライアントアプリケーション21に対して、利用申請D1を自動承認した旨を通知する(S32)。承認者PC30に対する通知(承認者への通知)とクライアントPC20に対する通知(利用申請したユーザへの通知)とは、同一内容であってもよいし、異なってもよい。
【0087】
内容を異ならせる場合、例えば、クライアントPC20には「利用申請が承認されました」といったメッセージのみ送信し、承認者PC30には利用申請D1の記載内容(ユーザID、緊急度、利用時間など)だけでなく、申請者であるユーザの当月残業時間、前月残業時間、緊急度毎の残回数など利用申請管理テーブルT2の内容のうち申請者に対応する内容を加えてもよい。これにより、管理職である承認者は、申請者であるユーザの勤務状況を利用申請D1の処理を通じて適宜把握することができ、必要に応じてユーザに連絡を取り、コミュニケーションをはかることもできる。
【0088】
利用申請承認システム14は、自動承認した利用申請D1に記載れた利用時間に基づいて、PC利用時間変更情報を利用時間管理DB12に記憶させる(S33)。
【0089】
シャットダウンシステム11は、クライアントアプリケーション21からの要求に応じて、利用時間管理DB12からカレンダおよびPC利用時間変更情報を取得し(S35)、クライアントアプリケーション21へ送信する(S36)。
【0090】
図11は、クライアントアプリケーション21が実行するシャットダウン処理を示すフローチャートである。
【0091】
クライアントアプリケーション21は、シャットダウンシステム11から取得したカレンダおよびPC利用時間変更情報に基づいて、PC利用停止予定時刻を過ぎたか判定する(S41)。
【0092】
ここではPC利用停止時刻を過ぎていないため(S41:NO)、クライアントアプリケーション21は、シャットダウンシステム11からカレンダおよびPC利用時間変更情報を取得し(S44)、それら取得した情報からPC利用停止時刻(上述したシャットダウンを予定している時刻)を算出する(S45)。
【0093】
クライアントアプリケーション21は、所定の警告タイミングが到来したか判定し(S46)、警告タイミングであると判定すると(S46:YES)、クライアントPC20の画面にPC利用停止時刻についての警告を表示させる(S47)。クライアントアプリケーション21は、例えば「PCは18時にシャットダウンします」といったメッセージを画面に表示することにより警告する。所定の警告タイミングは、例えば、クライアントPC20の起動時、PC利用停止時刻(シャットダウン時刻)の30分前などの所定時間前、シャットダウン時刻を過ぎた後などである。
【0094】
そして、クライアントアプリケーション21は、PC利用停止時刻を過ぎたか判定し(S48)、過ぎた場合(S48:YES)、クライアントPC20の利用を停止させる(S49)。すなわち、この例では、クライアントPC20をシャットダウンさせる。
【0095】
警告タイミングではない場合(S46:NO)およびPC利用停止時刻ではない場合(S48:NO)、ステップS46へ戻る。
【0096】
PC利用停止時刻を過ぎてクライアントPC20がシャットダウンされた後に、ユーザがクライアントPC20を再起動させた場合を説明する。この場合、PC利用停止時刻を過ぎているため(S41:YES)、クライアントアプリケーション21は、例えば数分程度の猶予時間についてカウントダウンを開始し(S42)、猶予時間が経過すると(S43:YES)、クライアントPC20を再びシャットダウンさせる(S49)。
【0097】
ユーザは、クライアントPC20を起動させてから、ユーザ自身によりまたはクライアントアプリケーション21によりシャットダウンされるまでの間、クライアントPC20を利用できる。図11の例では、ステップS41~S48までの間、ユーザはクライアントPC20を利用できるため、その利用可能な時間内にクライアントアプリケーション21から利用申請D1を利用管理サーバ10へ送信することができる。
【0098】
このように構成される本実施例によれば、複数の緊急度EA,EBに基づいてクライアントPC20の利用時間を自動承認することができるため、ユーザは、承認者による承認を得にくい時間帯に利用申請の承認を得ることができ、緊急性の高い状況に即応することができ、ユーザにとっての使い勝手が向上する。
【0099】
本実施例によれば、第1緊急度EAの場合に長時間の利用が自動承認され、第2緊急度EBの場合に短時間の利用が自動承認されるため、ユーザは状況に応じて緊急度を使い分けることにより、PC20の利用時間を適切に選択できる。ユーザは、例えば、PC20を長時間使用しなければ解決できないトラブルに取り組む場合は第1緊急度EAを指定して利用申請D1を出す。ユーザは、例えば、PC20を短時間使用するだけで処理可能なトラブルに取り組む場合は第2緊急度EBを指定して利用申請D1を出す。したがって、本実施例によれば、ユーザの状況判断に応じた適切な時間でPC20を利用することができ、使い勝手がよい。
【0100】
本実施例によれば、第1緊急度EAの場合に長時間の利用が第1上限回数まで自動承認され、第2緊急度EBの場合に短時間の利用が第1上限回数よりも多い第2上限回数まで自動承認されるため、ユーザの働き過ぎの抑制とユーザにとっての利便性向上という相反する要求を両立させることができる。すなわち本実施例によれば、ユーザの長時間残業を制限しつつも、ユーザの短時間作業の自由度を確保するため、ユーザの健康を守りながらユーザにとっての作業性を維持することができる。
【0101】
本実施例では、自動承認の回数に制限を設けるため、ユーザの出した利用申請が全て自動承認されてしまうのを防止できる。これにより、ユーザの個人的判断のみで残業が行われるのを抑止できる。
【0102】
本実施例では、利用申請D1の持つ緊急度が自動承認可能な緊急度EA,EBであっても、残業時間制限条件(例えば図5の所定範囲C16)を満たさないときは、自動承認しないため、法律または労使協定などを守ることができる。そして、残業時間制限条件を満たさない場合であっても、承認者の承認を得られた場合には、ユーザはPC20を例外的に利用することができる。
【0103】
本実施例によれば、利用申請D1が自動承認の対象ではない場合、承認者による承認(手動承認)の対象となるため、承認者の判断で柔軟に対応することができる。
【0104】
本実施例によれば、利用申請D1が自動承認されると、利用申請元のPC20と承認者PC30との両方に利用申請D1が自動承認された旨が通知される。したがって、ユーザは利用申請D1が承認されたことを確認でき、承認者はユーザによるPC利用状況を把握することができる。この通知を契機に承認者はユーザとコミュニケーションを図ることができ、より細かく状況を把握することもできる。
【0105】
本実施例によれば、承認者PC30への自動承認完了通知には、利用申請管理テーブルT2のうち該当部分の情報も含まれるため、承認者はユーザの労働状況を適切に管理することもできる。
【実施例0106】
図12を用いて第2実施例を説明する。本実施例を含む以下の各実施例では、第1実施例との相違を中心に述べる。本実施例の利用管理サーバ1Aに含まれる利用申請承認システム14Aは、利用申請D1を自動承認した場合に、ユーザに対して報告書の提出を要求する。
【0107】
本実施例の利用申請承認システム14Aの自動承認部142Aは、報告書提出要求部1421を備える。報告書提出要求部1421は、自動承認された利用申請D1についての報告書提出をユーザへ要求する。報告書提出要求部1421は、例えば、クライアントPC20の画面に、報告書提出を求めるポップアップ画面を表示させる。ユーザが報告書を作成してワークフローシステム13に登録すると、報告書提出要求部1421は報告書の提出を確認し、ユーザへの要求を停止させる。
【0108】
このように構成される本実施例も第1実施例と同様の作用効果を奏する。さらに本実施例によれば、利用申請が自動承認された場合に報告書の提出を要求するため、ユーザは、気軽に利用申請を出しにくくなる。これにより、ユーザのPC利用を自然に抑制することができ、無駄な利用を防止できる。本実施例によれば、利用申請(残業申請)の発行前にユーザに心理的制限をかけつつ、いったん利用申請が発行された場合は自動承認するため、無駄な利用を防止しつつユーザにとっての利便性を向上できる。
【実施例0109】
図13を用いて第3実施例を説明する。本実施例では、クライアントPC20を利用可能な時間をグループ単位で管理しており、グループに属する複数ユーザがその時間を分け合って各自のPC20を使用する。
【0110】
図13は、本実施例で用いる自動承認設定値管理テーブルT1Bの例である。このテーブルT1Bは、第1実施例で述べたユーザのランクに代えて、ユーザの属するグループC12B~C15Bの単位で、自動承認を利用可能な回数を管理する。図13の例では、第1緊急度EAを利用可能な回数と第2緊急度EBを利用可能な回数とのいずれもグループ単位で管理している。したがって、或るグループに属する誰か一人のユーザが回数を使い切ってしまった場合、そのグループに属する他のユーザは利用申請D1を出すことができなくなる。逆に、同一グループ内の或るユーザのPC利用を他の各ユーザは支援することができる。
【0111】
このように構成される本実施例も第1実施例と同様の作用効果を奏する。さらに本実施例では、グループ単位でPC20の利用を管理できるため、より柔軟な管理運用を実現できる。本実施例は、第1、第2実施例のいずれとも結合させることができる。
【実施例0112】
図14を用いて第4実施例を説明する。本実施例では、複数のユーザが共同作業する共同作業グループ内に、各自のPC20を利用可能な回数または時間が所定値以上異なる所定ユーザが含まれている場合、所定ユーザに対応する承認者に対して、所定ユーザがPC20を利用可能な回数または時間について通知する。
【0113】
図14は、利用申請承認システム14により実行される利用申請設定調整処理S60の例である。利用申請承認システム14は、共同作業テーブルT3を参照し(S61)、協同作業グループ毎にそのグループに所属するユーザの利用申請の設定(回数、時間)を利用申請管理テーブルT2から取得する(S62)。共同作業テーブルT3は、各共同作業グループを識別する番号と、その共同グループに属するユーザを識別するユーザIDとを対応付けて管理する。利用申請承認システム14は、ユーザIDに基づいて、利用申請管理テーブルT2を参照することができる。
【0114】
利用申請承認システム14は、共同作業グループ毎に、利用申請の設定が所定値以上異なる所定ユーザがいるか判定する(S63)。例えば、自動承認残回数が同一共同作業グループ内の他のユーザよりも所定値以上少ないユーザ、自動承認可能な残業時間が他のユーザよりも所定値以上少ないユーザは、所定ユーザとして検出される。
【0115】
利用申請承認システム14は、所定ユーザを検出すると(S63:YES)、その所定ユーザに対応する承認者PC30に対して、所定ユーザについての利用申請の設定をあらかじめ調整した方が良い旨を通知する(S64)。
【0116】
このように構成される本実施例も第1~第3実施例と同様の作用効果を奏する。さらに本実施例によれば、共同で作業するグループ内に、自動承認についての設定が他のユーザと比べて所定値以上異なる所定ユーザが含まれている場合に、その所定ユーザの承認者に事前の設定調整について通知することができる。したがって、共同作業を円滑に進めることができ、共同作業中のトラブルにも対処することができ、ユーザにとっての使い勝手が向上する。本実施例は、第1~第3実施例のいずれとも結合させることができる。
【実施例0117】
図15および図16を用いて第5実施例を説明する。本実施例の利用管理システム1Cは、クライアントPC20C側にも利用申請承認機能システム213を設ける。
【0118】
図15の機能構成図に示すように、クライアントPC20Cのクライアントアプリケーション21Cは、利用時間管理DB211と、通信状態判定部212と、ローカル利用申請承認システム213と、ローカルシャットダウンシステム214を備える。
【0119】
利用時間管理DB211には、利用管理サーバ10内の利用時間管理12で管理されている情報のうち、クライアントPC20Cに対応する情報のコピーが記憶される。通信状態判定部212は、クライアントPC20Cと利用管理サーバ10との通信が正常に(安定して)行われているか判定する。
【0120】
ローカル利用申請承認システム213は、クライアント側の利用申請承認システムであり、クライアントPC20C内で発行された利用申請をクライアントPC20C内で自動承認可能か判断する。ローカルシャットダウンシステム214は、クライアント側のシャットダウンシステムであり、シャットダウン時刻(PC利用停止時刻)になるとクライアントPC20Cをシャットダウンさせる。
【0121】
図16は、クライアントPC20Cの実行するローカル利用申請承認処理S70のフローチャートである。
【0122】
クライアントPC20Cは、利用管理サーバ10内の利用時間管理DB12から当該クライアントPC20Cに対応する情報を取得し、取得した情報により利用時間管理DB211を更新する(S71)。これにより、クライアント側の利用時間管理DB211は最新内容になる。
【0123】
クライアントPC20Cは、クライアントアプリケーション21Cから利用申請が発行されたか判定し(S72)、利用申請が発行されると(S72:YES)、サーバ10との通信状態が正常であるか判定する(S73)。例えば、クライアントPC20Cから通信状態を確認するためのコマンドを送信し、そのコマンドに対する応答が所定時間内に帰ってきた場合に、通信状態が正常であると判断することができる。
【0124】
通信状態が異常な場合(S73:NO)、クライアントPC20Cは、クライアントPC20C内で発行された利用申請を自動承認し、利用時間管理DB211を更新させる(S74)。クライアントPC20Cと利用管理サーバ10との間の通信状態が正常ではない場合、シャットダウンシステム11からPC利用時間変更情報などを安定して受信できない恐れがあるため、クライアントPC20C内で利用申請を処理する。
【0125】
その後、定期的にクライアントPC20Cは、利用管理サーバ10との通信状態が正常であるか確認する(S75)。クライアントPC20Cは、利用管理サーバ10との通信状態が正常になったら(S75:YES)、利用時間管理DB211の情報を利用管理サーバ10へ送信し、利用時間管理DB12を更新させる(S76)。
【0126】
PC利用停止時刻になると、ローカルシャットダウンシステム214は、クライアントPC20Cを停止させることができる。
【0127】
このように構成される本実施例も第1~第4実施例と同様の作用効果を奏する。さらに、本実施例によれば、クライアントPC20C内にも利用申請を自動承認する機能を設けたため、クライアントPC20Cと利用管理サーバ10との通信状態が正常ではない場合でも、利用申請を自動承認することができ、ユーザにとっての使い勝手が向上する。
【0128】
本来は自動承認の対象とならない利用申請についても、ローカル利用申請承認システム213は、自動承認の対象として取り扱い、その可否を判断することができる。この場合は、例えば、自動承認の対象ではない利用申請に第2緊急度EBが割り当てられているものとみなして判断すればよい。本実施例は、第1~第4実施例のいずれとも結合させることができる。
【0129】
なお、本発明は、上述した実施形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。上述の実施形態において、添付図面に図示した構成例に限定されない。本発明の目的を達成する範囲内で、実施形態の構成や処理方法は適宜変更することが可能である。
【0130】
また、本発明の各構成要素は、任意に取捨選択することができ、取捨選択した構成を具備する発明も本発明に含まれる。さらに特許請求の範囲に記載された構成は、特許請求の範囲で明示している組合せ以外にも組合せることができる。
【符号の説明】
【0131】
1,1A,1C:利用管理システム1、10:利用管理サーバ、11:PC自動シャットダウンシステム、12:利用時間管理データベース、13:ワークフローシステム、14:利用申請承認システム、20,20C:クライアントPC、21,21C:クライアントアプリケーション、30:承認者PC、40:他システム、141:手動承認部、142,142A:自動承認部、211:利用時間管理データベース、212:通信状態判定部、213:ローカル利用申請承認システム、214:ローカルシャットダウンシステム、1421:報告書提出要求部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16