JP5121280B2 - 情報処理装置、プロセス制御方法、及びプロセス制御プログラム - Google Patents

Description

本発明は、情報処理装置、プロセス制御方法、及びプロセス制御プログラムに関し、特にプログラムの起動制御又は終了化制御を行う情報処理装置、プロセス制御方法、及びプロセス制御プログラムに関する。

企業におけるオフィスには、プリンタ、コピー機、ファクシミリ、又はこれらの機能を一台の筐体において実現する複合機等といった複数の機器がネットワークを介して接続されている。

上記に挙げた機器は、いずれも装置の使用によって消耗される消耗品を備えており、当該消耗品が適切に交換されることによってその機能が維持される。例えば、プリンタであれば、トナー、定着ユニット、排トナーボトル、感光体、又は現像剤等が相当し、これらは一般的にサプライと呼ばれている。

サプライの消耗度を機器の外部から識別するのは困難であるため、ユーザは印刷を指示してエラーが通知されたときにトナー切れを認識し、トナーの交換を行っていた。こうしたユーザによる作業を軽減するため、機器内部でサプライの寿命を検知し、そのサプライに関する情報を操作パネルへの表示や用紙への印字を行う技術や、機器自身がサプライ交換の必要性を表す信号を外部に通知し、その機器が設置されているオフィスに保守作業要員を派遣するという技術、またサプライ残量に応じてプリンタドライバが発注コマンドを外部に送信するという技術が提案されている。
特開平１０−１９８２３６号公報 特開２００３−３４５５６０号公報 英国特許出願公開第ＧＢ２３４１６９８号明細書

しかしながら、サプライの寿命を検知したとしても、その後のサプライ発注やサプライ交換をユーザ自身が行う場合、交換対象のサプライの型番を正確に確認した上で発注手続きを行われなければならない。そのためサプライ発注までにユーザは煩雑な作業を強いられていた。また、発注自体は先に行っておきたいときでも、発注先の営業日や営業時間等によっては発注可能時期が発注先の営業所の業務時間に依存するという問題がある。また発注に関する人件費や配送費等のコストも増えるという問題もあった。

さらプリンタドライバから自動的に発注がされるような場合、そのプリンタをあまり使わない場合や今後そのプリンタの使用を止めたい場合でも、サプライ残量に応じて自動的に発注がされてしまうため、ユーザとしてはそのプリンタの利用の意図やそのプリンタのサプライ補充の必要性等が無いにもかかわらず、サプライの発注が一方的になされてしまうおそれがあるという問題があった。

本発明は、上記問題の少なくとも1つに鑑みなされたものであって、コンピュータプログラムの起動制御又は終了化制御を適切に行うことができる情報処理装置、プロセス制御方法、及びプロセス制御プログラムの提供を目的とする。

そこで上記課題を解決するため、本発明は、デーモンプロセスとして動作する情報処理手段と、前記デーモンプロセスとは異なるプロセスとして前記情報処理手段に関する画面を表示させる情報表示手段とを有し、前記情報表示手段は、起動されたときに前記情報処理手段を起動することを特徴とする。

また、本発明は、デーモンプロセスとして動作する情報処理手段と、前記デーモンプロセスとは異なるプロセスとして前記情報処理手段に関する画面を表示させる情報表示手段と、前記情報表示手段を終了させる第一の終了手段と、前記第一の終了手段とは異なる原因によって前記情報表示手段を終了させる第二の終了手段とを有し、前記情報表示手段は、前記第一の終了手段より終了を要求された場合は、前記情報処理手段も終了させ、前記第二の終了手段より終了を要求された場合は、前記情報処理手段は終了させないことを特徴とする。

このような情報処理装置では、コンピュータプログラムの起動制御又は終了化制御を適切に行うことができる。

本発明によれば、コンピュータプログラムの起動制御又は終了化制御を適切に行うことができる情報処理装置、プロセス制御方法、及びプロセス制御プログラムを提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における発注支援システムの構成例を示す図である。図１において、発注支援システム１は、発注支援サーバ１０と、クライアントＰＣ２０と、機器３０ａ、３０ｂ、３０ｃ、及び３０ｄ等（以下、総称する場合「機器３０」という。）とを構成要素として含む。発注支援サーバ１０は、発注サイト（機器３０の消耗品の供給者側、例えば、機器３０のメーカー）に設置されており、クライアントＰＣ及び機器３０はユーザサイト（機器３０のユーザ側、例えば、オフィス等）に設置されている。発注支援サーバ１０とクライアントＰＣ２０とは、インターネット等の広域ネットワークによって接続されている。また、クライアント２０と機器３０とは、ユーザサイトに施設されたＬＡＮ（Local Area Network）等のネットワーク（有線又は無線の別は問わない）を介して接続されている。

機器３０は、例えば、一般的なプリンタや複合機等、トナーやインク等を消耗して、画像を形成する機器（画像形成装置）である。本実施の形態において機器３０は、ＭＩＢ（Management Information Base）に対応しており、ＳＮＭＰ（Simple Network Management Protocol）に基づいてネットワークを介して受信されるＭＩＢ情報の取得要求に応答することが可能である。また、本実施の形態において機器３０は、消耗品の状態情報を検知することができる。当該状態情報は、定性的（正常／ニアエンド／エンド）なものであってもよいし、定量的（１００％、９０％、...．．１０％、０％）なものであってもよい。

クライアントＰＣ２０は、汎用的なコンピュータであり、監視プログラム２１がインストールされる。監視プログラム２１は、ＣＤ−ＲＯＭ等の記録媒体５０２よりインストールされてもよいし、ネットワークを介してダウンロードされてもよい。後述するように、本実施の形態ではネットワーク４０を介してダウンロードされる。

監視プログラム２１は、クライアントＰＣ２０のメモリにロードされＣＰＵによって処理されることにより、クライアントＰＣ２０に以下の機能を実行させる。図２は、監視プログラムがクライアントＰＣに実行させる処理の処理手順を説明するためのフローチャートである。

クライアントＰＣ２０は、監視プログラム２１に基づいて、各機器３０より機器情報（ＭＩＢ情報）を定期的に取得する（Ｓ２５１）。機器情報には、機器３０が使用する消耗品の状態を識別するための情報（状態情報）、例えば、トナーステータス及びトータルカウンタ値（総印刷枚数）等が含まれる。また、他の消耗品、具体的には、定着ユニット、排トナーボトル、感光体、又は現像剤等の状態を示す情報が含まれていてもよい。取得した結果、機器情報に含まれている消耗品の状態情報が定性的な情報（すなわち、正常／ニアエンド／エンド）である場合（Ｓ２５２で「定性情報」）、ニアエンド又はエンド情報（以下、「エンド」によって総称する）を取得すると（Ｓ２５３でＹｅｓ）、当該消耗品の不足であると判定し（Ｓ２５４）、機器３０の機器情報を発注支援サーバ１０へ送信する（Ｓ２５５）。一方、機器情報を取得した結果、状態情報が定量的な情報（すなわち、１００％、９０％、...．．１０％、０％）である場合（Ｓ２５２で「定量情報」）、所定の閾値（３０％以下）を下回っているかを調べ（Ｓ２５６）、下回っている場合（Ｓ２５６でＹｅｓ）、当該消耗品の不足であると判定し（Ｓ２５４）、機器３０の機器情報を発注支援サーバ１０へ送信する（Ｓ２５５）。

なお、本実施の形態では、監視装置２０が消耗品の不足を検知する例について説明するが、当該検知を発注支援サーバ１０に行わせてもよい。この場合、監視装置２０は全ての機器３０の機器情報を発注支援サーバ１０に送信することになる。したがって、ネットワーク負荷の軽減という観点からは、本実施の形態のように、監視装置２０において不足が検知された機器の機器情報のみを発注支援サーバ１０に送信する方が好ましい。

クライアントＰＣ２０には、また、電子メールの送受信を行うためのメーラや、Ｗｅｂページを閲覧するためのＷｅｂブラウザ等もインストールされている。

発注支援サーバ１０は、汎用的なコンピュータであり、Ｗｅｂサーバとしての機能が実装されていると共に、発注支援プログラム１１がインストールされている。発注支援プログラム１１は、ＣＤ−ＲＯＭ等の記録媒体５０１よりインストールされてもよいし、ネットワークを介してダウンロードされてもよい。

発注支援プログラム１１は、発注支援サーバ１０のメモリにロードされＣＰＵによって処理されることにより、発注支援サーバ１０に以下の機能を実行させる。すなわち、発注支援プログラム１１に基づいて、発注支援サーバ１０の電子メール作成手段は、クライアントＰＣ２０より受信される機器情報に基づいて不足している消耗品（以下「サプライ」という。）の補給を促進する電子メールを作成し、予め登録されているユーザのメールアドレスに送信する。当該電子メールには、不足していると判定されたサプライの発注用のＷｅｂページ（以下「サプライ発注ページ」という。）に対するＵＲＬが記載される。発注支援サーバ１０は、また、当該ＵＲＬのクリックに基づいて送信されるＨＴＴＰリクエストに応じて、サプライ発注ページを返信し、更に、サプライ発注ページに基づくサプライの発注要求を受信する。発注支援サーバ１０は、サプライ発注要求に応じて、サプライの発注指示を非図示の物品発注管理システムに送信する。

以下、図１の発注支援システム１の処理手順について説明する。販売業者より機器３０を購入したユーザは、当該販売業者との間で発注支援システム１への登録契約を締結する。当該登録契約を結んだユーザは、図３に示されるようにまずユーザ登録を行う。なお、以下の説明から明らかになることであるが、ユーザは、発注支援システム１の利用によってサプライの補給作業にかかるコストを低減させることが期待できる。その期待が、ユーザにとって当該登録契約の締結に対するインセンティブとなる。

図３は、発注支援システムにおけるユーザ登録時の処理手順を説明するためのシーケンス図である。なお、図３において、Ｗｅｂブラウザ２２は、クライアントＰＣ２０にインストールされている汎用的なＷｅｂブラウザである。また、メーラ２３は、クライアントＰＣ２０にインストールされている汎用的なメーラである。

まず、ユーザは、登録契約の際に発注支援サーバ１０へアクセスするためのＩＤ（以下「アクセスＩＤ」という。）と、発注支援サーバ１０のＵＲＬとを販売業者より入手し、当該ＵＲＬをＷｅｂブラウザ２２に入力する。ＵＲＬの入力に応じてアクセスＩＤの入力が要求され、当該アクセスＩＤが正当に入力されると、ユーザ登録を行うためのＷｅｂページ（以下「ユーザ登録ページ」という。）が、発注支援サーバ１０よりＷｅｂブラウザ２２に送信される（Ｓ１１）。ユーザ登録ページを受信したＷｅｂブラウザ２２は、当該ユーザ登録ページを表示させる。

図４は、ユーザ登録ページの表示例を示す図である。図４の説明において（）内の数字は、図中における参照番号に対応する。図４に示されるように、ユーザ登録ページ２２０においては、ユーザの氏名（２２１）、郵便番号（２２２）、住所（２２３）、会社名（２２４）、部署名（２２５）、電話番号（２２６）、ＦＡＸ番号（２２７）、及び電子メールアドレス（２２８）等の基本情報の他、サプライを発注した際のサプライの配送先の郵便番号、住所、会社名、及び部署名等（２３１）と、販売業者ＩＤ（２３２）との入力が可能となっている。ここで、販売業者ＩＤは、当該ユーザが上記登録契約を締結した相手となる販売業者のＩＤであり、登録契約時に販売業者より通知される。

ユーザが、ユーザ登録ページ２２０において必要事項を入力し、登録ボタン２３３をクリックすると、Ｗｅｂブラウザ２２は、発注支援サーバ１０に対してユーザ登録を要求するＨＴＴＰリクエストを送信する（Ｓ１２）。当該ＨＴＴＰリクエストには、ユーザ登録ページ２２０への入力情報（以下、販売業者ＩＤも含めて「ユーザ情報」という。）が含まれている。

発注支援サーバ１０の発注支援プログラム１１は、ＨＴＴＰリクエストが受信されると、当該ＨＴＴＰリクエストに含まれているユーザ情報を所定のデータベース（以下「ユーザデータベース」という。）に登録する（Ｓ１３）。ユーザ情報の登録に際し、発注支援プログラム１１は、ユーザ情報に含まれている販売業者ＩＤが発注支援サーバ１０にエントリされているか否かを判定し、エントリされている場合は、当該ユーザに対するユーザＩＤ及びパスワードを生成又は採番する。更に、当該ユーザＩＤ及びパスワードをもユーザ情報に含めてユーザデータベースに登録する。

続いて、発注支援プログラム１１は、監視プログラム２１のダウンロードを実行させるためのＷｅｂページ（以下「ダウンロードページ」という。）へのＵＲＬや、生成されたユーザＩＤ及びパスワード等が本文に記載された電子メール（以下、「インストール情報通知メール」という。）をユーザのメールアドレスに送信する（Ｓ１４）。また、発注支援プログラム１１は、インストール情報通知メールを送信した旨のメッセージを表示させるＷｅｂページを、ステップＳ１２におけるＨＴＴＰリクエストに対するＨＴＴＰレスポンスに含めてＷｅｂブラウザ２２に対して送信する。ユーザは、当該Ｗｅｂページによって、インストール情報通知メールが自分宛に送信されたこと知ることができる。そして、メーラ２３によってインストール情報通知メールを閲覧することにより、ダウンロードページのＵＲＬや自分に対して割り有り当てられたユーザＩＤ及びパスワード等を確認することができる。

なお、ダウンロードページのＵＲＬ等の通知は、必ずしも電子メールによる必要はない。例えば、ステップＳ１４において、インストール情報通知メールを送信した旨のメッセージを表示させるＷｅｂページではなく、ダウンロードページが返信されるようにしてもよい。但し、ステップＳ１４のタイミングでダウンロードページが返信されてしまうと、そのままインストール作業を続行する必要があるのに対し、インストール情報通知メールによれば、当該メールの受信後ユーザの都合のいいときにインストール作業を行えるという点でユーザにとって便宜である。また、ＦＡＸや郵送によってこれらの情報が送付されるようにしてもよい。

ユーザが、インストール情報通知メールに記載されているダウンロードページのＵＲＬをクリックすると、メーラ２３は、当該ＵＲＬを引数としてＷｅｂブラウザ２２を起動させる。Ｗｅｂブラウザ２２は、起動すると、当該ＵＲＬに基づいてダウンロードページを表示させる。ユーザが、ダウンロードページにおいてダウンロード先のＵＲＬをクリックすると、Ｗｅｂブラウザ２２は、発注支援サーバ１０に対して、監視プログラム２１のダウンロード要求を送信する（Ｓ１５）。発注支援プログラム１１は、当該要求に応じ、発注支援サーバ１０に保存されている監視プログラム２１のインストールパッケージをクライアントＰＣ２０に転送する（Ｓ１６）。

ユーザは、ダウンロードされたインストールパッケージに含まれているインストーラ２５を起動する（Ｓ１７）。インストーラ２５は、起動されるとユーザに対してインストール情報通知メールにおいて通知されたユーザＩＤ及びパスワード等の入力を要求する。ユーザがユーザＩＤ及びパスワード等を入力すると、インストーラ２５は、入力されたユーザＩＤ及びパスワードを発注支援サーバ１０に送信し、ユーザの認証を要求する（Ｓ１８）。発注支援プログラム１１は、インストーラ２５より送信されたユーザＩＤ及びパスワードと、ユーザデータベースに登録されているユーザＩＤ及びパスワードとを照合することによりユーザの認証を行う（Ｓ１９）。発注支援プログラム１１は、認証結果を監視プログラム２１に返信する（Ｓ２０）。インストーラ２５は、認証が成功した場合のみ監視プログラム２１のインストールを実行し（Ｓ２１）、認証が失敗した場合はインストールを中止する。

ユーザが認証された場合のみインストールを実行することで、例えば、インストールパッケージを不正に入手したユーザによるインストールを防止することができる。監視プログラム２１は、ネットワークを介して発注支援プログラム１１と通信を行うものである。したがって、不正ユーザによる監視プログラム２１の利用を防止し、発注支援サーバ１０に対するネットワークを介した攻撃を抑止するためにも、インストール時のユーザ認証は効果的である。なお、インストーラ２５によるインストール処理の詳細については後述する。

インストールが正常に行われると、監視プログラム２１は、クライアントＰＣ２０上で動作を開始する。まず、監視プログラム２１はネットワーク５０に接続されている機器３０を検索し（Ｓ２２）、検索された全ての機器３０の情報（例えば、機器のシリアル番号、ＭＡＣアドレス、機種名、ベンダ名（機器メーカーの名前）等を含む情報。以下「検索機器情報」という。）を、発注支援サーバ１０に送信する（Ｓ２３）。なお、ネットワーク５０上における機器３０の検索及び検索機器情報の取得は、周知の技術を用いて行うことが可能である。

発注支援プログラム１１は、受信された検索機器情報を所定のデータベース（以下「機器データベース」という。）に登録し（Ｓ２４）、検索機器情報の一覧を表示させるＷｅｂページ（以下「検索機器一覧ページ」という。）のＵＲＬを監視プログラム２１へ送信する（Ｓ２５）。監視プログラム２１は、受信したＵＲＬを引数としてＷｅｂブラウザ２２を起動させる（Ｓ２６）。Ｗｅｂブラウザ２２は、起動すると、引数に指定されたＵＲＬに基づいて検索機器一覧ページを要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（Ｓ２７）。発注支援プログラム１１は、受信されたＨＴＴＰリクエストに応じ、ステップＳ２４において登録されている検索機器情報に基づいて検索機器情報一覧ページを生成し、当該検索機器情報一覧ページをＷｅｂブラウザ２２に返信する（Ｓ２８）。

図５は、検索機器一覧ページの表示例を示す図である。図５の説明において（）内の数字は、図中における参照番号に対応する。図５に示されるように、検索機器一覧ページ２４０には、検索された機器３０ごとに、シリアル番号、ＭＡＣアドレス、ＩＰアドレス、モデル名、及びベンダ名等が表示される。検索機器一覧ページ２４０には更に、機器３０ごとに、備考を入力させるための欄（２４１）と、監視プログラム２１による監視対象とするか否か（監視の要否）を選択させるためのチェックボタン（２４２）とが設けられている。すなわち、ユーザは、検索機器一覧ページ２４０において、機器３０ごとに備考の入力と監視の要否の選択とを行う。本実施の形態では、チェックボタンがチェックされた場合に、監視対象として選択されたものとする。備考欄２４１には、ユーザの任意によって自由な情報の入力が可能であるが、例えば、機器３０の配置場所等、消耗品の交換作業の補助となるような情報を入力しておくとよい。

ユーザが、検索機器一覧ページ２４０において、各機器３０について備考の入力と、監視の要否の選択とを行い、送信ボタン２４３をクリックすると、Ｗｅｂブラウザ２２は、各機器３０の備考と監視の要否との登録を要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（Ｓ２９）。発注支援プログラム１１は、受信されたＨＴＴＰリクエストに基づき、各機器３０の備考と監視の要否とを機器データベースに追加登録する（Ｓ３０）。

以上で、ユーザ登録時の処理は終了する。なお、監視プログラム２１は、インストール時以外にも、例えばユーザのメニュー選択によって機器検索情報の登録、検索機器一覧ページの表示をさせ、監視対象機器を追加させるようにしてもよい。

続いて、インストーラ２５による監視プログラム２１のインストール処理の詳細について説明する。図６は、監視プログラムのインストール処理を説明するためのフローチャートである。

ユーザがインストーラ２５を起動すると、インストーラ２５は、インストール先（フォルダ又はディレクトリ）を選択させる画面（以下「インストールフォルダ選択画面」という。）を表示させる（Ｓ５１）。インストールフォルダ選択画面では、ユーザの便宜を図るためデフォルトのインストールフォルダが表示されるようにしてもよい。ユーザが、インストールフォルダを選択すると、インストーラ２５は、監視プログラム２１がクライアントＰＣ２０に過去にインストールされたことがあるか否かを判定する（Ｓ５２）。過去にインストールされたことがある場合とは、現在インストールされている場合だけでなく、過去にインストールされ、その後アンインストールされた場合も含む。この判定は、インストールされる際にクライアントＰＣ２０内に記録される情報の有無に基づいて行われる。本実施の形態では、設定情報ファイルの有無によって判定される。設定情報ファイルは、インストール時に設定される情報（以下「インストール設定情報」という。）が格納されるファイルであり、後述のステップＳ５６において生成される。したがって、ここでは、前回のインストール時にインストールフォルダ下に生成された設定情報ファイルの有無が確認される。

図７は、設定情報ファイルに保存されるインストール設定情報の構成例を示す図である。図７に示されるように、設定情報ファイルにはインストール設定情報として、発注支援サーバ１０のＵＲＬ、ユーザＩＤ、パスワード、ユーザサイトにおけるプロキシサーバのＩＰアドレス、ポート番号、当該プロキシサーバに対する認証情報としてユーザ名及びパスワード等が格納される。

監視プログラム２１がインストールされたことがあると判定した場合（設定情報ファイルが存在した場合）、インストーラ２５は、設定情報ファイルよりインストール設定情報を取得し、当該インストール設定情報が設定された状態で設定画面を表示させる（Ｓ５３）。設定画面とは、インストール設定情報をユーザに入力させるための画面である。

図８は、インストール設定情報が設定された状態で表示される設定画面の表示例を示す図である。

図８において、設定画面５０１は、最初に表示される設定画面である。設定画面５０１では、発注支援サーバ１０のＵＲＬ、ユーザＩＤ、及びパスワードの入力が要求される。ユーザＩＤ及びパスワードは、インストール情報通知メールによって通知されたものである。設定画面５０２は、設定画面５０１においてＮｅｘｔボタン３０１１が押下された際に表示される設定画面である。設定画面５０２では、ユーザサイトにおけるプロキシサーバのＩＰアドレス及びポート番号と、当該プロキシサーバに対する認証情報としてユーザ名及びパスワードとの入力が要求される。

但し、図８の設定画面５０１及び５０２では、前回のインストールの際に入力されたインストール設定情報が設定されている。したがって、インストール設定情報に変更が無い場合、ユーザはインストール設定情報を改めて入力する必要はない。一方、監視プログラム２１がインストールされたことは無いと判定した場合（設定情報ファイルが無い場合）、インストーラ２５は、設定画面５０１及び５０２を、入力欄が空の状態で表示させる。したがって、この場合、ユーザは各項目を入力しなければならない。

ユーザが、設定画面５０２においてＣｏｍｐｌｅｔｅボタン３０２１を押下すると、イストーラ２５は、監視プログラム２１のインストールを実行する（Ｓ５５）。この際、インストーラ２５は、設定画面５０１に入力されたユーザＩＤ及びパスワードを発注支援プログラム１１に送信し、当該ユーザＩＤ及びパスワードが認証された場合に限ってインストールを実行する。この点については、図３のステップＳ１８〜Ｓ２０において説明した通りである。

インストールが成功すると、インストーラ２５は、インストールフォルダ下に設定情報ファイルを生成し、インストール設定情報を図７に示される形式で当該設定情報ファイルに保存する（Ｓ５６）。但し、前回のインストール設定情報によってそのままインストールが実行された場合は、必ずしもこの処理は必要ではない。

また、監視プログラム２１のアンインストールは、インストールパッケージに含まれているアンインストーラによって実行される。図９は、監視プログラムのアンインストール処理を説明するためのフローチャートである。

ユーザより監視プログラム２１のアンインストールが指示されると、アンインストーラは、設定情報ファイルのコピーを作成し、当該コピーをインストールフォルダ以外の所定のフォルダに待避しておく（Ｓ６１）。続いて、アンインストーラはアンインストールを実行し、インストールフォルダ以下のファイルを削除する（Ｓ６２）。続いて、アンインストーラは待避しておいた設定情報ファイルをインストールフォルダ下に移動する（Ｓ６３）。

このように、アンインストール時には、設定情報ファイルは、インストールフォルダ下に残される。したがって、インストール時のステップＳ５２では、当該設定情報ファイルが存在すれば、監視プログラム２０が過去にインストールされたことを判断することができる。なお、設定情報ファイルのバックアップの要否をユーザによって選択可能としてもよい。

次に、クライアントＰＣ２０にインストールされた監視プログラム２１によって機器３０の状態の監視が定期的に行われる際の発注支援システム１の処理手順について説明する。図１０は、発注支援システムにおける機器監視時の処理手順を説明するためのシーケンス図である。

監視プログラム２１は、機器状態監視時間になると、発注支援サーバ１１に監視対象となっている機器３０（以下、「監視機器」という。）のリストを問い合わせる（Ｓ１０１）。発注支援プログラム１１は、機器データベースに登録されている監視の要否に基づいて監視機器をリストアップし、当該リスト（監視機器リスト）を監視プログラム２１に返信する（１０２）。なお、監視プログラム２１は、機器状態監視時間以外にも、例えばユーザのメニュー選択によって機器監視を行うようにしてもよい。

監視プログラム２１は、監視機器リストを受信し、当該監視機器リストに含まれている機器３０に対して機器情報としてのＭＩＢ情報をＳＮＭＰに基づいて問い合わせる（Ｓ１０３）。問い合わせ対象となるＭＩＢ情報としては、少なくともトナーのステータス情報が含まれ、また、他のサプライのステータス情報が含まれていてもよい。各機器３０は、問い合わせ対象とされたＭＩＢ情報を監視プログラム２１に対して返信する（Ｓ１０４）。

なお、本発明の実施にあたり、機器情報は必ずしもＭＩＢ情報に限定されず、機器情報を問い合わせるためのプロトコルはＳＮＭＰに限定されないが、標準化された技術を用いることにより、各機器３０のベンダが異なっていても、同じ手順によって機器情報の取得が可能であるという観点より、ＭＩＢやＳＮＭＰ等の標準技術に基づくのが好適である。

全ての監視機器からの機器情報の取得（ポーリング）が完了すると、監視プログラム２１は、当該機器情報に基づいて、不足通知を行うかどうか判定を行う（Ｓ１０５）。すなわち、図２において説明したとおり、取得した結果、消耗品の状態情報が定性的な情報（すなわち、正常／ニアエンド／エンド）である場合、ニアエンド又はエンド情報（以下、「エンド」によって総称する）を取得すると、当該消耗品の不足であると判定し、機器３０の機器情報を発注支援サーバ１０へ送信する（Ｓ１０６）。取得した結果、状態情報が定量的な情報（すなわち、１００％、９０％、...．．１０％、０％）である場合、所定の閾値（３０％以下）を下回っているかを調べ、下回っている場合、当該消耗品の不足であると判定し、機器３０の機器情報を発注支援サーバ１０へ送信する（Ｓ１０６）。また、サプライの不足には、当該サプライの継続的な使用による機能の低下も含まれる。なお、ここで送信される情報を以下、「不足通知情報」という。

図１１は、不足通知情報の構成例を示す図である。図１１において、不足通知情報は、ヘッダ情報と機器情報とから構成される。

ヘッダ情報は、日時、ユーザＩＤ、及びパスワード等を含む。日時は、機器情報を転送する日時である。ユーザＩＤ及びパスワードは、監視プログラム２１のインストール時に入力され、保存されているユーザＩＤ及びパスワードである。すなわち、ヘッダ情報は、機器３０より取得された情報ではない。

機器情報は、上記における機器情報と同義である。すなわち、機器３０よりＭＩＢ情報として取得された情報であり、当該機器３０のベンダ名、モデル名（機器３０を特定するための情報）、シリアル番号、ＭＡＣアドレス、ＩＰアドレス、トナーＩＤ（トナーボトルを特定するための情報、カラーであれば、トナーＩＤは各色ごとに付与され、モノクロであれば１個付与される）、トナー名称、トナーステータス、トナーレベル、トナー名（文字列）、トナー名（Ｃｏｄｅ）、及びトータルカウンタ値等を含む。これらは、ｐｕｂｌｉｃ ＭＩＢ（標準ＭＩＢ）として定義されているものであり、ベンダを問わずいずれの機器からも取得可能な情報である。

トナーステータスは、トナーの状態を示す情報である。また、トータルカウンタ値は、総印刷枚数を示す情報である。したがって、監視プログラム２１は、トナーステータスによってトナーエンドを検出する。また、トータルカウント値によって、感光体、定着ユニット、及び現像剤等の消耗度を判定する。但し、標準ＭＩＢにおけるトナーステータスでは、エンドとなったトナーの色までは特定することはできない。

そこで、本実施の形態における機器情報は、更に、モノクロカウンタ値、カラーカウンタ値、シアンカウンタ値、マゼンタカウンタ値、ブラックカウンタ値、及びレッドカウンタ値等をも含む。これらは、ｐｒｉｖａｔｅ ＭＩＢ（拡張ＭＩＢ）としてベンダ独自に定義されているものである。

例えば、本実施の形態では、メーカーＡの機器３０のみがこれらの拡張ＭＩＢに対応しているとすれば、メーカーＡの機器３０についての機器情報にはこれらの値が格納されるが、メーカーＡ以外の機器３０についての機器情報ではこれらの値は空となる。

例えば、モノクロカウンタ値は、モノクロ印刷による印刷枚数である。カラーカウンタ値は、カラー印刷による印刷枚数である。また、シアンカウンタ値、マゼンタカウンタ値、ブラックカウンタ値、及びレッドカウンタ値は、それぞれの色のトナーを使用した印刷枚数である。したがって、メーカーＡの機器３０であれば、色ごとにそのエンドを検知することが可能となる。

なお、本実施例においては、不足通知情報として図１１に記載されている情報を通知するが、本発明はこれに限定されない。通知する情報は、必要に応じて、適宜決定される。

なお、図１１に示した不足通知情報は、いずれかのサプライの不足が検知された機器３０のそれぞれについて発注支援プログラム１１に送信される。

不足通知情報を受信した発注支援プログラム１１は、不足通知情報に基づいて、不足しているサプライを識別し、当該不足の通知をユーザに対して行うか否かを判定する（Ｓ１０７）。この判定処理の詳細については後述するが、不足通知情報が重複して送信されてくることが考えられるため、ユーザに対して当該不足の通知を重複して行わないようにするための処理である。

不足通知情報が重複したものではないと判定されると、発注支援プログラム１１は、不足しているサプライの発注用のＷｅｂページ（以下「発注ページ」という。）を生成し、当該サプライが不足していることを通知する電子メール（以下「不足通知メール」という。）を作成し、ユーザのメールアドレスに対して送信する（Ｓ１０８）。不足通知メールには、発注ページのＵＲＬが記載される。なお、各不足通知メールには、ＩＤが付与され（以下「メールＩＤ」という。）、メールＩＤと共に、当該不足通知メールの対象とされた機器３０のシリアル番号等の機器３０を識別するための情報と、ユーザＩＤ又はメールアドレス等ユーザを識別するための情報と、送信日時等とが不足通知メールの送信履歴として保存される。

図１２は、不足通知メールの例を示す図である。図１２に示される不足通知メール２５０において、＜＞で囲まれた文字列は具体的な値ではなく、当該個所に記述される情報の内容を示す。

図１２に示されるように、不足通知メール２５０の宛先には、不足通知情報に係るユーザのメールアドレスが指定される。当該該ユーザのメールアドレスの特定は、不足通知情報に含まれているユーザＩＤ及びパスワードをキーとして、ユーザデータベースより検索すればよい。ユーザデータベースには、ユーザ登録時において、ユーザＩＤ及びパスワードと共にメールアドレスが登録されているからである。

不足通知メール２５０のタイトルには、当該メールが不足通知メールであることを示すタイトルが記載される。不足通知メール２５０の本文には、不足通知情報に係る機器に関する情報、不足しているサプライに関する情報、発注ページのＵＲＬ等が記載される。

機器に関する情報は、当該機器のベンダ名、モデル名、及び備考等が含まれる。これらの情報は、不足通知情報に含まれているシリアル番号、ＭＡＣアドレス又はＩＰアドレス等をキーとして、機器データベースより取得すればよい。また、不足しているサプライに関する情報は、例えば、当該サプライがトナーである場合は、不足通知情報に含まれているトナーステータス、トナーＩＤ、トナー名称等が記載される。

なお、一つの機器３０において複数のサプライが同時に不足した場合は、一つの不足通知メール２５０内に当該複数のサプライの不足を示す情報を含むメールを作成し、当該複数のサプライの不足が通知される。

クライアントＰＣ２０におけるメーラ２３によって不足通知メール２５０を閲覧したユーザは、印刷等を実行していないときでも、サプライの不足を認識することができる。また、備考として機器３０の配置場所等を入力しておけば、当該情報によって機器３０の配置場所の特定等を容易に行うことができる。

ユーザが、不足通知メール２５０に記載されている発注ページのＵＲＬをクリックすると、メーラ２３はクリックされたＵＲＬを引数としてＷｅｂブラウザ２２を起動させる。Ｗｅｂブラウザ２２は、起動すると、引数に指定されたＵＲＬに基づいて発注ページを要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（Ｓ１０９）。発注支援プログラム１１は、受信されたＨＴＴＰリクエストに応じ、発注ページをＷｅｂブラウザ２２に返信する（Ｓ１１０）。Ｗｅｂブラウザ２２は、受信した発注ページを表示させる。

図１３は、発注ページの表示例を示す図である。図１３において、発注ページ２６０には、領域２６１においてサプライが不足している機器に関する情報（メーカー（ベンダ）名、モデル名、シリアル番号、備考（配置位置）が表示されている。また、領域２６２において、不足しているサプライの名称が表示されている。また、領域２６２では、当該機器に対応した各種サプライの一覧が表示され、それぞれの発注が可能となっている。すなわち、サプライごとに、その商品名（名称）が表示され、購入する数量の入力が可能とされている。なお、参照番号２６２１に示されるように、不足しているサプライについては予め必要な数量が入力されて表示されている。また、各商品名には、当該商品の概要説明を表示するＷｅｂページへのリンクが張られている。更に、領域２６３では、当該ユーザの過去の購入履歴が表示される。これによって、ユーザが重複して購入してしまうことを防止することができる。

なお、購入履歴は、ユーザデータベースにユーザごとに登録されている。すなわち、発注ページ２６０を介して商品の発注が行われると、発注された商品の情報がユーザデータベースに追加登録される。

ところで、図１３の発注ページ２６０では、イエローのトナーが不足している旨が通知されている。上述したように、標準ＭＩＢだけでは、不足しているトナーの色は特定できない。したがって、図１３の発注ページ２６０には、拡張ＭＩＢに登録されている情報に基づいて判定された結果が示されている。このように、発注支援システム１を展開するメーカーは、自らが定義した拡張ＭＩＢによって、発注支援システム１上のサービスにおいて、他社と差別化を図ることができる。すなわち、仮に、他社の機器３０のトナーエンドが検知された場合は、発注ページ２６０にはその色までは特定されて通知されない。なお、他社の機器３０のサプライについては、そもそも発注支援システム１による発注対象から除外するということも考えられるが、ユーザの利便性を考慮し、本実施の形態では、他社の機器３０のサプライの発注も可能としている。

発注ページ２６０において、ユーザが注文ボタン２６２２をクリックすると、Ｗｅｂブラウザ２２は、商品の発注を要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（S１１１）。

ＨＴＴＰリクエストに応じ、発注支援プログラム１１は、当該ユーザと関連付いている販売業者に対して当該発注要求に基づく利益の一部を供与するための情報を記録する（Ｓ１１２）。具体的には、発注業者ごとに、発注支援システム１によるサプライの売り上げを管理するデータベース（以下「販売業者データベース」という。）が構築されており、当該販売業者データベースの売り上げに、今回の発注による注文の内容（例えば、注文金額）が記録される。なお、販売業者は、メーカーとの間で発注支援システム１への参加契約を締結することにより、販売業者データベースへのエントリが作成される。また、販売業者ＩＤが与えられ、当該販売業者は、発注支援システム１上において、当該販売業者ＩＤによって識別される。なお、ステップＳ１１２において、受信されるＨＴＴＰリクエストに係るユーザの識別は、例えば、Ｗｅｂブラウザ２２とのセッションＩＤとユーザＩＤとを関連付けておき、その関連付けに基づいて、セッションＩＤよりユーザＩＤを特定することにより行えばよい。

発注支援プログラム１１は、更に、当該発注の指示を物品発注管理システムに指示する。この指示には、ユーザデータベースに登録されている配送先の情報が含まれている。物品発注支援システムに発注が指示されることにより、発注された商品は、実際にユーザの元に配送される。更に、ユーザから購入代金支払われると、販売業者データベースに、今回の発注による売り上げが確定したことが記録される。売り上げか確定することにより、当該販売業者には、売り上げに応じて販売促進金などの手当をメーカーから供与してもよい。

続いて、図１０におけるステップＳ１０７の処理の詳細について説明する。図１４は、不足通知メールの送信の是非の判定処理を説明するための図である。改めて、当該処理の意義について説明する。

監視プログラム２１は、各機器３０より定期的に機器情報を問い合わせ、当該機器情報に基づいてサプライの不足を判定している。判定の結果、サプライの不足が検知されると、監視プログラム２１は、発注支援プログラム１１に不足通知情報を送信する。このような仕組みにおいて、例えば、監視プログラム２１による問い合わせの周期内に、既に不足が検知されたサプライの交換が行われなかった場合、監視プログラム２１は改めて同一の機器３０について当該サプライの不足を検知してしまう。また、例えば、トナーについては、トナーボトルの中にまだトナーが残っている場合にトナーエンドが検知される場合がある。このような場合、ユーザがトナーボトルを振った後に当該トナーボトルを取り付けると、しばらくしてから改めて同一のトナーについてトナーエンドが検知されてしまうことが考えられる。このような場合、ユーザに対して不足通知が重複して送信されてしまい、ユーザが重複に気付かなければ、重複した発注を行ってしまうということが考えられる。そこで、かかる事態の発生を回避するため、発注支援プログラム１１は、以下の処理を行う。

まず、監視プログラム２１より受信した不足通知情報に含まれている、機器３０のシリアル番号に基づいて、不足通知メールの送信履歴より当該機器３０に関して最後（前回）に送信した不足通知メールの日時をチェックする（Ｓ２０１）。

送信履歴の中に、当該機器３０に対する不足通知メールの送信記録が含まれていない場合（Ｓ２０２でＹｅｓ）、不足通知メールを送信すると判定する（Ｓ２０３）。当該機器３０に関しては、今までに不足通知メールを送信したことはなく、したがって、不足通知メールが重複する恐れはないからである。

送信履歴の中に、当該機器３０に対する不足通知メールの送信記録が含まれている場合（Ｓ２０２でＮｏ）、最後に送信した不足通知メールの送信日時から所定期間が経過している否かを判定する（Ｓ２０４）。所定期間が経過していれば不足通知メールは送信すると判定し（Ｓ２０３）、経過していなければ重複の恐れがあるとして不足通知メールは送信しないと判定する（Ｓ２０５）。

なお、図１４では、時間の経過に基づいて判定する例を示したが、例えば、送信履歴としてトータルカウンタを記録しておき、トータルカウンタの差分が所定の閾値以下の場合であれば、不足通知メールを送信しないようにしてもよい。また、送信履歴を一定時間ごとに全て削除するようにし、送信履歴の中に同一の機器３０に対する不足通知メールの送信記録が含まれている場合は、不足通知メールを送信しないようにしてもよい。

上述したように、本発明の実施の形態における発注支援システム１によれば、機器３０のユーザ（顧客）、販売業者、及びメーカーの三者のそれぞれに対して、利便性又は有益性を提供することができる。

すなわち、機器３０のサプライの不足が自動的に検知され、不足通知メールがユーザの端末に自動的に送信される。その結果、ユーザは、不足通知メールに記載されているＵＲＬをクリックすることで発注ページ２６０を表示させることができ、発注ページ２６０によって不足しているサプライを簡便に発注することができる。したがって、ユーザ自らが機器３０に対応したサプライを特定したり、量販店に買い出しに行ったりするための手間を省くことができ、サプライの調達コストを低減させることができる。

また、販売業者については、サプライによる収益の一部を獲得することができ、その収益源を拡大することができる。

また、メーカーについては、販売業者に当該メーカーの機器を他社の機器より優先させて販売したいというインセンティブや、ユーザに当該メーカーの機器を購入したいというインセンティブを与えることができる。すなわち、発注支援システム１を介して販売されたサプライが当該メーカー製のものである場合は他社のサプライが販売された場合よりも還元率を高くしたり、又は、他社のサプライの場合は還元率を０としたりすれば、販売業者にとっては、当該メーカーの製品を販売した方が、サプライの販売による利益を多く享受できるからである。また、ユーザにとっては、当該メーカーの機器を購入すれば、例えば、不足したトナーの色の特定まで可能であるといった、きめ細かいサービスを受けられるという期待を与えることができるからである。

更に、メーカーは、ユーザの機器情報を蓄積することによって、各機器３０の使用期間等をある程度推測することができる。その結果、買い換えの促進等、新たな販売活動への連携を効果的に行うことができる。

なお、上記実施の形態では、ユーザとの間で発注支援システム１の登録契約を締結するのは機器を販売する業者である場合を例として説明したが、必ずしも、ユーザと当該登録契約を締結する相手側は、機器を販売した者に限定されない。機器は販売していない業者であっても、メーカーから発注支援システム１における販売業者ＩＤが与えられるようにしてもよい。この場合、当該業者は、機器の販売とは関係なく、発注支援システム１を介したサプライの販売による利益の還元を受けることができる。

ところで、上述した監視プログラム２１は、二つ以上のプログラムによって構成されていてもよい。図１５は、監視プログラムの構成例を示す図である。図１５において、監視プログラム２１は、ＵＩアプリ２１１と監視サービス２１２とより構成されている。

監視サービス２１２は、デーモンプロセスとして起動されるプログラムであり、機器情報の取得、機器情報に基づく消耗品の不足の判定、不足が判定された消耗品に係る機器情報の発注支援プログラム１１への送信等を実行する。すなわち、監視サービス２１２は、上述において監視プログラム２１の機能として説明した機能を実現する。

ＵＩアプリ２１１は、監視サービス２１２とは別プロセスとして起動され、監視サービス２１２の機能に関してＧＵＩ（Graphical User Interface）を提供するアプリケーションである。ＵＩアプリ２１１は、例えば、監視サービス２１２に対する設定情報（例えば、機器情報を取得する周期）を設定させるための画面や、監視サービス２１２によって取得される機器情報を表示させるための画面等を表示させる。

図１６は、個人環境とＵＩアプリ及び監視サービスとの関係例を示す図である。図１６に示されるように、ＵＩアプリ２１１は、個人環境（ログオン）ごとに起動される。一方、監視サービス２１２は、複数の個人環境から共通的に利用される。ここで個人環境とは、ユーザがソフトウェア資源にアクセスするための環境であり、ログオン（又はログイン）によって開設される。

以下、これら二つのプログラムの起動処理、終了処理について説明する。図１７は、クライアントＰＣの起動時に監視サービスが起動する場合の起動処理を説明するためのシーケンス図である。

クライアントＰＣ２０が起動され、Ｗｉｎｄｏｗｓ（登録商標）等のＯＳ２６が起動されると、ＯＳ２６はその起動処理の中で監視サービス２１２をプロセス（デーモンプロセス）として起動させる（Ｓ３０１）。ユーザが、ログオンを行うと（Ｓ３０２）、ＯＳ２６は、スタートアップを実行し、当該スタートアップにおいてＵＩアプリ２１１をプロセスとして起動させる（Ｓ３０３）。ＵＩアプリ２１１は、初期状態としてタスクバー上に自らのアイコンを表示させる（Ｓ３０４）。

図１８は、タスクバー上におけるＵＩアプリのアイコンの表示例を示す図である。図１８において、アイコン２１１ｉは、ＵＩアプリ２１１のアイコンである。このように、ＵＩアプリ２１１は、スタートアップによる起動時にはタスクバー上のアイコンとして起動される。なお、アイコン２１１ｉをマウスの左ボタンでダブルクリックするとＵＩアプリ２１１のＧＵＩが表示される。また、アイコン２１１ｉを右クリックすると、コンテキストメニュー２１１ｍが表示される。

次に、図１９は、クライアントＰＣの起動時に監視サービスが起動されない場合の起動処理を説明するためのシーケンス図である。

クライアントＰＣ２０が起動されＯＳ２６がログオン待ちの状態において、ユーザがログオンを行うと（Ｓ３１１）、ＯＳ２６はスタートアップを実行し、当該スタートアップにおいてＵＩアプリ２１１をプロセスとして起動させる（Ｓ３１２）。ログオンが行われることにより、当該ユーザがソフトウェア資源にアクセスするための個人環境が開設される。したがって、ユーザはクライアントＰＣ２０のソフトウェア資源にアクセス可能となる。ＵＩアプリ２１１は、監視サービス２１２が起動されていないことを確認すると、監視サービス２１２を起動させる（Ｓ３１３）。ＵＩアプリ２１１の動作には、監視サービス２１２が起動されている必要があるからである。続いて、ＵＩアプリ２１１は、タスクバー上に自らのアイコン２１１ｉ（図１８参照）を表示させる（Ｓ３１４）。

すなわち、ＵＩアプリ２１１は、ＯＳ２６から起動されると以下のような処理を実行する。図２０は、ＵＩアプリの起動処理を説明するためのフローチャートである。

ＯＳ２６より起動されると、ＵＩアプリ２１１は、監視サービス２１２のステータス情報を取得し（Ｓ３５１）、ステータス情報に基づいて、監視サービス２１２は起動中か否かを判定する（Ｓ３５２）。起動中でない場合（Ｓ３５２でＮｏ）、ＵＩアプリ２１１は監視サービス２１２を起動させる（Ｓ３５３）。既に起動されている場合（Ｓ３５２でＹｅｓ）、ＵＩアプリ２１１は、監視サービス２１２の起動は行わない。なお、ステータス情報は、Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒに対して監視サービスのサービス名に基づいて問い合わせることができる。また、監視サービス２１２のプログラム名に基づいて、監視サービス２１２のプロセスＩＤを取得し、その取得に失敗した場合に監視サービス２１２は起動していないと判断してもよい。

次に、監視プログラム２１の終了処理について説明する。図２１は、ログオフが実行された際の監視プログラムの終了処理を説明するためのシーケンス図である。

ユーザがログオフを行うと（Ｓ４０１）、ＵＩアプリ２１１は、ＯＳ２６より終了要求を受け付ける（Ｓ４０２）。ＵＩアプリ２１１は、終了要求を受け、自らのプロセスを終了させる。これによって、タスクバー上のアイコン２１１ｉは非表示とされ、ユーザがソフトウェア資源にアクセスするための個人環境は終了する（ログオフ）。

ところで、図１８に示されるように、アイコン２１１ｉを右クリックするとコンテキストメニュー２１１ｍが表示される。コンテキストメニュー２１１ｍには、メニュー項目として「Ｅｘｉｔ」項目が含まれている。「Ｅｘｉｔ」項目は、当該アイコンを表示させているプログラム、すなわちＵＩアプリ２１１を終了させるためのメニュー項目である。次に、「Ｅｘｉｔ」項目が選択された際の監視プログラム２１の終了処理について説明する。

図２２は、コンテキストメニューからＵＩアプリの終了が指示された場合の監視プログラムの終了処理を説明するためのシーケンス図である。

ユーザがアイコン２１１ｉを右クリックし、コンテキストメニュー２１１ｍに含まれている「Ｅｘｉｔ」項目を選択すると、ＵＩアプリ２１１は、終了要求を受け付ける（Ｓ４１１）。ＵＩアプリ２１１は、監視サービス２１２を終了させ（Ｓ４１２）、その後、自らも終了する。

すなわち、ＵＩアプリ２１１は、終了要求を受け付けた際、以下のような処理を実行する。図２３は、ＵＩアプリの終了処理を説明するためのフローチャートである。

ＵＩアプリ２１１は、終了要求を受け付けると（Ｓ４５１）、当該終了要求がログオフに基づくものであるか否かを判定する（Ｓ４５２）。Ｗｉｎｄｏｗｓ（登録商標）の場合、ログオフが実行されるとメッセージプロシージャ内でＬＯＧ＿ＯＦＦメッセージが発生する。したがって、ＵＩアプリ２１１は、このＬＯＧ＿ＯＦＦメッセージを取得した場合にフラグをＯＮにしておく。その後、終了要求を受け付けた際、ＵＩアプリ２１１は、当該フラグがＯＮであれば、当該終了要求はログオフに基づくものであると判定し、当該フラグがＯＦＦであれば、それ以外の原因（例えば、「Ｅｘｉｔ」項目の選択）に基づくものであると判定すればよい。

終了要求がログオフに基づくものでない場合（Ｓ４５２でＮｏ）、ＵＩアプリ２１１は、監視サービス２１２を終了させ、自らも終了する（Ｓ４５３）。一方、終了要求がログオフに基づくものである場合（Ｓ４５２でＹｅｓ）、ＵＩアプリ２１１は、監視サービス２１２を終了させることなく終了する（Ｓ４５３）。

上述したように、ログオフが実行された場合、ＵＩアプリ２１１は終了するが監視サービス２１２は終了しない。監視サービス２１２は、継続的に機器情報を取得し、消耗品の不足を監視するという機能を実現するものである。したがって、一ユーザのログオフによって当該機能が終了してしまうのは適切でないと考えられるからである。すなわち、ログオフを行うユーザは、ログオフによって監視サービス２１２の終了までは意図していないものと考えられるからである。

一方、ログオフ以外の原因でＵＩアプリ２１１が終了する場合は、監視サービス２１２も終了する。この場合の典型例は、アイコン２１１ｉのコンテキストメニュー２１１ｍからＵＩアプリ２１１の終了が指示された場合である。厳密に言えば、アイコン２１１ｉはＵＩアプリ２１１のアイコンであるが、ユーザからは、ＵＩアプリ２１１及び監視サービス２１２が一体となった監視プログラム２１のアイコンとして見えるものと考えられる。すなわち、一般的なユーザは、ＵＩアプリ２１１と監視サービス２１２とのプロセスの異同は認識又は意識しておらず、両者を一つのアプリケーションとして捉えるものと考えられる。かかる考えに基づけば、ユーザがコンテキストメニュー２１１ｍより終了を指示したということは、ユーザは、監視プログラム２１全体の機能、すなわち、機器３０の消耗品の不足の監視機能をも終了させたい意図を持っているものと推測される。したがって、仮に、監視プログラム２１を終了させなければ、ユーザの認識とクライアントＰＣ２０との状態にずれが生じ、ユーザは機器３０の監視を中止しているつもりなのに不足通知メールが送信されてくるといった事態を招く。そこで、本実施の形態では、ログオフの場合は監視サービス２１２は終了せず、それ以外の場合は監視サービス２１２を終了させるのである。

以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

本発明の実施の形態における発注支援システムの構成例を示す図である。 監視プログラムがクライアントＰＣに実行させる処理の処理手順を説明するためのフローチャートである。 発注支援システムにおけるユーザ登録時の処理手順を説明するためのシーケンス図である。 ユーザ登録ページの表示例を示す図である。 検索機器一覧ページの表示例を示す図である。 監視プログラムのインストール処理を説明するためのフローチャートである。 設定情報ファイルに保存されるインストール設定情報の構成例を示す図である。 インストール設定情報が設定された状態で表示される設定画面の表示例を示す図である。 監視プログラムのアンインストール処理を説明するためのフローチャートである。 発注支援システムにおける機器監視時の処理手順を説明するためのシーケンス図である。 不足通知情報の構成例を示す図である。 不足通知メールの例を示す図である。 発注ページの表示例を示す図である。 不足通知メールの送信の是非の判定処理を説明するための図である。 監視プログラムの構成例を示す図である。 個人環境とＵＩアプリ及び監視サービスとの関係例を示す図である。 クライアントＰＣの起動時に監視サービスが起動する場合の起動処理を説明するためのシーケンス図である。 タスクバー上におけるＵＩアプリのアイコンの表示例を示す図である。 クライアントＰＣの起動時に監視サービスが起動されない場合の起動処理を説明するためのシーケンス図である。 ＵＩアプリの起動処理を説明するためのフローチャートである。 ログオフが実行された際の監視プログラムの終了処理を説明するためのシーケンス図である。 コンテキストメニューからＵＩアプリの終了が指示された場合の監視プログラムの終了処理を説明するためのシーケンス図である。 ＵＩアプリの終了処理を説明するためのフローチャートである。

符号の説明

１ 発注支援システム
１０ 発注支援サーバ
１１ 発注支援プログラム
２０ クライアントＰＣ
２１ 監視プログラム
２５ インストーラ
２６ ＯＳ
３０、３０ａ、３０ｂ、３０ｃ、３０ｄ 機器
４０、５０ ネットワーク
２１１ ＵＩアプリ
２１２ 監視サービス
５０１、５０２ 記録媒体

Claims (7)

1. 当該情報処理装置とネットワークを介して接続される機器の機器情報および消耗品の状態情報を取得し、該消耗品の状態情報から消耗品の不足を判定し、不足と判定された消耗品に関する機器情報および消耗品の状態情報とを発注支援装置に送信するデーモンプロセスとして動作する情報処理手段と、
   前記デーモンプロセスとは異なるプロセスとして前記情報処理手段に関する画面を表示させる情報表示手段とを有し、
   前記情報表示手段は、起動されたときに前記情報処理手段が起動されているかを判定し、前記情報処理手段が起動されていない場合に前記情報処理手段を起動し、
   前記情報表示手段は、前記情報表示手段の終了を指示させるためのメニュー項目の選択によって前記情報表示手段の終了が指示された場合は、前記デーモンプロセスを終了させると共に当該情報表示手段のプロセスを終了させ、当該情報処理装置のソフトウェア資源をユーザに操作させるための個人環境が終了した場合は、前記デーモンプロセスを終了させずに、当該情報表示手段のプロセスを終了させることを特徴とする情報処理装置。
2. 前記メニュー項目は、前記情報表示手段がプロセスとして動作中であることを示すアイコンをクリックすることにより表示されることを特徴とする請求項１記載の情報処理装置
3. 前記個人環境の終了は、前記個人環境からのログオフであることを特徴とする請求項１又は２記載の情報処理装置。
4. コンピュータが実行するプロセス制御方法であって、
   当該コンピュータとネットワークを介して接続される機器の機器情報および消耗品の状態情報を取得し、該消耗品の状態情報から消耗品の不足を判定し、不足と判定された消耗品に関する機器情報および消耗品の状態情報とを発注支援装置に送信するデーモンプロセスとして動作する情報処理プログラムを起動する第一の起動手順と、
   前記デーモンプロセスとは異なるプロセスとして前記情報処理プログラムに関する画面を表示させる情報表示プログラムを起動する第二の起動手順とを有し、
   前記情報表示プログラムは、起動されたときに前記情報処理プログラムが起動されているかを判定し、前記情報処理プログラムが起動されていない場合に前記情報処理プログラムを起動し、
   前記情報表示プログラムは、前記情報表示プログラムの終了を指示させるためのメニュー項目の選択によって前記情報表示プログラムの終了が指示された場合は、前記デーモンプロセスを終了させると共に当該情報表示プログラムのプロセスを終了させ、当該コンピュータのソフトウェア資源をユーザに操作させるための個人環境が終了した場合は、前記デーモンプロセスを終了させずに、当該情報表示プログラムのプロセスを終了させることを特徴とするプロセス制御方法。
5. 前記メニュー項目は、前記情報表示プログラムがプロセスとして動作中であることを示すアイコンをクリックすることにより表示されることを特徴とする請求項４記載のプロセス制御方法。
6. 前記個人環境の終了は、前記個人環境からのログオフであることを特徴とする請求項４又は５記載のプロセス制御方法。
7. 請求項４乃至６いずれか一項記載のプロセス制御方法をコンピュータに実行させるためのプロセス制御プログラム。

Images