JP2008146242A - 発注支援システム、機器監視装置、機器監視方法及びプログラム - Google Patents

Abstract

【課題】機器の消耗品の補給作業を簡便化させることのできる発注支援システムの提供を目的とする。
【解決手段】ネットワークより検索された機器より機器情報を取得する機器情報取得手段と、機器情報を構成する所定の属性に基づいて、監視対象の候補とする機器を絞り込むための情報を設定させる手段と、該情報に基づいて検索された機器より監視対象の候補とする機器を抽出する手段と、抽出された機器の覧の中から監視対象とする機器を選択させる手段と、選択された機器の消耗品の状態情報を取得し、発注支援装置に送信する手段とを有する機器監視装置と、機器監視装置より受信される状態情報に基づいて不足が検知された消耗品の発注用のＷｅｂページを示すＵＲＬが記載された電子メールを作成し、当該消耗品に係る機器に予め関連付けられて登録されているメールアドレスに電子メールを送信する発注支援装置とを備えることにより上記課題を解決する。
【選択図】図３

Description

本発明は、発注支援システム、機器監視装置、機器監視方法及びプログラムに関し、特に機器の消耗品の発注を支援する発注支援システム、機器監視装置、機器監視方法及びプログラムに関する。

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

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

サプライの消耗度を機器の外部から識別するのは困難である。したがって、従来、ユーザは、例えば、印刷を指示してエラーが通知されたときにトナー切れを認識し、トナーの交換を行っていた。
特開２００３−３４５５６０号公報

しかしながら、サプライを交換するためには、当該サプライを改めて購入しなければならない。サプライの購入は、一般的に量販店や通信販売等を介して行われているが、オフィスには多数の機器が設置されており、また、それぞれの機器に応じて購入すべきサプライの型番が異なる。したがって、ユーザは、機器に応じて購入すべきサプライの型番を正確に確認し、その上で当該サプライの購入又は発注手続き等を行わなければならず、非常に煩雑な作業が要求されていたという問題があった。

本発明は、上記の点に鑑みてなされたものであって、機器の消耗品の補給作業を簡便化させることのできる発注支援システム、機器監視装置、機器監視方法及びプログラムの提供を目的とする。

そこで上記課題を解決するため、本発明の発注支援システムは、ネットワークに接続される機器を検索し、検索された機器より機器情報を取得する機器情報取得手段と、前記機器情報を構成する所定の属性に基づいて、監視対象の候補とする機器を絞り込むための情報を設定させる設定手段と、前記設定手段が設定させた情報に基づいて、前記検索された機器より前記監視対象の候補とする機器を抽出する抽出手段と、前記抽出手段によって抽出された機器の一覧を表示させ、前記一覧の中から前記監視対象とする機器を選択させる監視対象選択手段と、前記監視対象として選択された機器の消耗品の状態情報を取得し、前記状態情報を発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、前記機器監視装置より受信される前記状態情報に基づいて不足が検知された消耗品の発注用のＷｅｂページを示すＵＲＬが記載された電子メールを作成し、当該消耗品に係る機器に予め関連付けられて登録されているメールアドレスに前記電子メールを送信する前記発注支援装置とを備えることを特徴とする。

このような発注支援システムでは、機器の消耗品の補給作業を簡便化させることができる。

本発明によれば、機器の消耗品の補給作業を簡便化させることのできる発注支援システム、機器監視装置、機器監視方法及びプログラムを提供することができる。

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

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

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

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

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

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

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

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

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

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

ところで、本発明者は、発注支援システム１を利用した新たなビジネスモデルの構築を検討している。まず、当該ビジネスモデルを構築するに至った背景について説明する。

一般的に、画像形成装置の販売は、代理店や接点店等、様々な販売チャネルを介して行われる。以下、メーカーから製品（画像形成装置）を仕入れて顧客に対して直接販売を行う業者を「販売業者」という。当該販売業者には、ハードウェアとしての画像形成装置を単に販売するだけでなく、顧客に応じたソリューションを付加価値として提供し、そのソリューションの中で画像形成装置を機能させるためのＳＩ作業等の業務を行うものも含まれる。これらの、販売業者は、ハードウェアとしての画像形成装置の販売による利益や、ＳＩ作業等に基づくソフトウェアによる利益等を主な収益原とている。

他方において、画像形成装置は、一度販売された後でもサプライの継続的な販売によって、継続的に利益を得られるという特性があり、またその利益は、一般的に画像形成装置の販売による利益よりも大きい。しかしながら、従来、顧客（ユーザ）は、機器の購入後は販売業者を介することなく量販店や通信販売等によりサプライを購入するのが一般的であった。したがって、画像形成装置を販売した販売業者は、当該画像形成装置のサプライによる継続的な利益を得ることができなかった。

ここで、或る販売業者がメーカーＡ及びメーカーＢの画像形成装置の販売を行っている場合を想定する。仮に、メーカーＡの画像形成装置を販売した場合は、当該画像形成装置のサプライの販売による利益が当該販売業者に還元されるとすれば、販売業者には、メーカーＢの画像形成装置よりもメーカーＡの画像形成装置をより多く販売したいというインセンティブが働く。その結果、メーカーＡの製品を売り上げの増加を期待することができ、メーカーＡは、メーカーＢに対して競争上優位な差別化を図ることが期待できる。

そこで、本発明者は、新たなビジネスモデルとして、サプライの販売による利益が販売業者に還元される仕組みを考案した。本実施の形態では、発注支援システム１を当該ビジネスモデルに適用した例について説明する。

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

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

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

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

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

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

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

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

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

ユーザは、ダウンロードされたインストールパッケージに含まれているインストーラ２５を起動する（Ｓ１７）。インストーラ２５は、起動されるとユーザに対してインストール情報通知メールにおいて通知されたユーザＩＤ及びパスワード等の入力を要求する。ユーザがユーザＩＤ及びパスワード等を入力すると、インストーラ２５は、入力されたユーザＩＤ及びパスワードを発注支援サーバ１０に送信し、ユーザの認証を要求する（Ｓ１８）。なお、入力されたユーザＩＤ及びパスワードは、クライアントＰＣ２０においても保存され、管理される。

発注支援プログラム１１は、インストーラ２５より送信されたユーザＩＤ及びパスワードと、ユーザデータベースに登録されているユーザＩＤ及びパスワードとを照合することによりユーザの認証を行う（Ｓ１９）。発注支援プログラム１１は、認証結果をインストーラ２５に返信する（Ｓ２０）。インストーラ２５は、認証が成功した場合のみ監視プログラム２１のインストールを実行し（Ｓ２１）、認証が失敗した場合はインストールを中止する。

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

インストールが正常に行われると、監視プログラム２１の監視サービス２１２は、クライアントＰＣ２０上で動作を開始する。まず、監視サービス２１２はネットワーク５０に接続されている機器３０を検索し、各機器３０より当該機器の機器情報（例えば、機器のシリアル番号、ＭＡＣアドレス、機種（モデル）名、ベンダ名（機器メーカーの名前）等を含む情報。以下「検索機器情報」という。）を取得する（Ｓ２２）。なお、ネットワーク５０上における機器３０の検索及び検索機器情報の取得は、例えば、ＳＮＭＰ（Simple Network Management Protocol）に基づいてＭＩＢ（Management Information Base）情報を取得する等、周知の技術を用いて行えばよい。

続いて、監視プログラム２１は、検索された機器３０の中から、監視対象とする機器の候補を絞り込むための情報（監視対象絞り込み情報）を設定させ、設定された監視対象絞り込み情報に基づいて、監視対象の候補とする機器３０を抽出する（絞り込む）（Ｓ２３）。この処理は、図５を用いて説明する。

図５は、監視対象絞り込み情報の設定処理を説明するための図である。まず、監視サービス２１２は、検索された各機器３０のベンダ名を判別し、検索された全ての機器３０のベンダ名のリストを作成する（Ｓ２３１）。機器３０のベンダ名は、検索機器情報がＭＩＢ情報として取得されている場合は、当該ＭＩＢ情報のうちの「ｓｙｓＤｅｓｃｒ」に基づいて判別すればよい。

続いて、監視サービス２１２は、作成されたリスト内のベンダ名の論理和を生成することにより、リスト内におけるベンダ名の重複を排除する（Ｓ２３２）。この処理により、例えば、ベンダ名が、Ａ、Ｂ、Ｃ、Ａ、Ａ、Ｂとリストアップされた場合は、Ａ、Ｂ、Ｃというリストが作成される。以下、重複が排除されたベンダ名のリストを「ベンダ名リスト」という。続いて、ＵＩアプリ２１１は、監視対象絞り込み情報をユーザに設定させる画面（以下「監視対象絞り込み設定画面」という。）を、クライアントＰＣ２０の表示装置に表示させる（Ｓ２３３）。

図６は、監視対象絞り込み設定画面の表示例を示す図である。図６において、監視対象絞り込み設定画面２７０には、ベンダ名リストが表示されている。また、ベンダ名ごとにチェックボタンが配置されている。なお、キャンセルボタン２７２がクリックされると、チェックボタン２７１のチェック状態がクリアされる。

監視対象絞り込み設定画面２７０において、ユーザが、監視対象とするベンダ名のチェックボタン２７１をチェックし、ＯＫボタン２７３をクリックすると、ＵＩアプリ２１１は、チェックされた（選択された）ベンダ名（以下「監視対象ベンダ名」という。）をクライアントＰＣ２０の記憶装置に保存する（Ｓ２３４）。なお、監視対象ベンダ名は、複数選択されてもよい。続いて、監視サービス２１２は、検索された機器３０の中から、ベンダ名が監視対象ベンダ名に含まれる（又は一致する）機器を抽出する（Ｓ２３５）。なお、本実施の形態では、チェックボタン２７１がチェックされたベンダ名が監視対象とされる例が示されているが、チェックされたベンダ名が監視対象から除かれるようにしてもよい。また、本実施の形態では、監視対象絞り込み設定画面２７０には、検索された機器３０のベンダより作成されたベンダ名リスト表示されるように構成されているが、予め登録されているベンダ名のリストを監視対象絞り込み設定画面２７０に表示させるようにしてもよい。但し、本実施の形態のように、検索された機器３０のベンダ名に基づくベンダ名リストによれば、選択肢を適切に限定することができる。

図３に戻る。続いて、監視サービス２１２は、監視対象ベンダ名に基づいて抽出された機器３０の検索機器情報を、発注支援サーバ１０に送信する（Ｓ２４）。

発注支援プログラム１１は、受信された検索機器情報を所定のデータベース（以下「機器データベース」という。）に登録する（Ｓ２５）。

図７は、機器データベースを構成する機器情報テーブルの構成例を示す図である。図７に示されるように機器情報テーブル１２は、検索された機器３０ごとにＭＡＣアドレス、ベンダ名、機種名、シリアル番号、監視フラグ、備考、サプライのステータス、及びメールフラグ等が登録され、管理されるテーブルである。ＭＡＣアドレス、ベンダ名、機種名、及びシリアル番号は、検索機器情報に含まれているものがそのまま登録される。その他ＩＰアドレス等も登録されるが、図中では便宜上省略されている。なお、ステップＳ２４では、監視対象ベンダ名に基づいて抽出された機器３０の検索機器情報が、発注支援サーバ１０に送信される。したがって、機器情報テーブル１２には、検索された全ての機器３０ではなく、監視対象ベンダ名に係る機器３０の検索機器情報が登録される。

監視フラグは、監視サービス２１２の監視対象とされているか否かを示すフラグ情報であり、監視対象の場合は「Ｙｅｓ」、監視対象でない場合は「Ｎｏ」が登録される。なお、初期値としては「Ｙｅｓ」が登録される。但し、初期値はＮＵＬＬ（空）値であってもよい。備考は、ユーザの任意によって機器に関連付けておきたい情報が登録される項目である。

サプライのステータスは、サプライのステータスを識別するための情報が登録される項目である。本実施の形態では、Ｎ（Ｎｏｒｍａｌ）、Ｎｅ（Ｎｅａｒ Ｅｎｄ）、又はＥ（Ｅｎｄ）が登録されることとする。初期値としては「Ｎ」であってもよいし、ＮＵＬＬ値であってもよい。メールフラグについては後述する。

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

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

なお、検索機器一覧ページ２４０において表示対象となるのは、検索された全ての機器ではなく、監視対象ベンダ名に基づいて抽出された（絞り込まれた）機器である。したがって、監視対象ベンダ名が設定されることにより、オフィス等において複数のベンダの機器３０が多数配置されている場合に、検索機器一覧ページ２４０に表示される機器３０の数を削減することができる。よって、検索機器一覧ページ２４０に表示されている機器３０の中から、監視対象とする機器を探し出すための作業負担を軽減することができる。特に、近年では、複数のベンダの機器３０が混在している環境は珍しくないため、監視対象ベンダ名による監視対象の候補の絞り込みは効果的である。

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

図９は、監視の要否及び備考が登録された機器情報テーブルの例を示す図である。図９の機器情報テーブル１２では、１行目のエントリの備考に「大森４Ｆ」といったような配置情報が登録された例が示されている。また監視フラグについては、１〜４行目のエントリに係る機器が監視対象とされ、５〜７行目のエントリに係る機器が監視対象から除かれた例が示されている
以上で、ユーザ登録時の処理は終了する。なお、監視プログラム２１は、インストール時以外にも、例えばユーザのメニュー選択によって機器検索情報の登録、検索機器一覧ページの表示をさせ、監視対象機器を追加させるようにしてもよい。また、ユーザのメニュー選択に応じて、ＵＩアプリ２１１が監視対象絞り込み設定画面２７０を表示させ、改めて監視対象ベンダ名の選択を行わせるようにしてもよい。この場合、監視対象絞り込み設定画面２７０の編集結果に応じて、記憶装置に保存されている監視対象ベンダ名が更新される。なお、本実施の形態では、監視対象の候補を絞り込むための情報として、ベンダ名を用いているが、機器情報を構成する属性のうちベンダ名以外の属性の属性値を監視対象の候補を絞り込むための情報としてもよい。例えば、モデル名若しくは備考に登録されている情報、又はベンダ名、モデル名及び備考に登録されている情報の組み合わせに基づいて、監視対象の候補を絞り込むようにしてもよい。また、監視対象の候補の絞り込みは、発注支援サーバ１０において行われてもよい。この場合、監視対象ベンダ名等を発注支援サーバ１０に予め登録しておき、例えばステップＳ２４において検索機器情報が受信されたときに、発注支援プログラム１１が登録されている監視対象ベンダ名等に基づいて当該検索機器情報の中から監視対象の候補を抽出するようにすればよい。

ところで、監視サービス２１２は、その後もネットワーク５０に接続されている機器３０の検索を自動的に繰り返し（例えば、定期的に）行う（Ｓ３２）。監視サービス２１２は、検索された機器３０の中から、クライアントＰＣ２０の記憶装置に保存されている監視対象ベンダ名に係る機器３０を抽出し（Ｓ３３）、抽出された機器の検索機器情報を発注支援サーバ１０に送信する（Ｓ３４）。

発注支援プログラム１１は、受信された検索機器情報に基づいて、機器情報テーブル１２を更新する（Ｓ３５）。ネットワーク５０の構成が定期的に検査され、その検査結果に基づいて機器情報テーブル１２が更新されることで、機器情報テーブル１２の内容とネットワーク５０の構成との間にずれが発生する可能性を低くすることができる。

ステップＳ３５において実行される機器情報テーブルの更新処理の詳細について説明する。図１０は、発注支援プログラムによる機器情報テーブルの更新処理を説明するためのフローチャートである。検索機器情報を受信すると発注支援プログラム１１は、検索機器情報と共に監視サービス２１２より送信されるユーザＩＤ及びパスワードに基づいてユーザの認証を行う（Ｓ３５１）。ユーザが認証された場合（Ｓ３５１でＹｅｓ）、検索機器情報に含まれている機器ごとにステップＳ３５２以降の処理を行う。

まず、一つの機器を処理対象とし（以下、処理対象とされた機器を「カレント機器」という。）（Ｓ３５３）、カレント機器が新たに検索された機器（以下「新規機器」という。）であるか否かを判定する（Ｓ３５４）。この判定は、カレント機器のＭＡＣアドレスをキーとして、機器情報テーブル１２に当該ＭＡＣアドレスを有するエントリが有るか否かによって行う。当該エントリが無ければカレント機器は新規機器であると判定される。

カレント機器は新規機器であると判定した場合（Ｓ３５４でＹｅｓ）、カレント機器のエントリを機器情報テーブル１２に登録する（Ｓ３５５）。この際、カレント機器は監視対象とする。すなわち、新たに追加されたエントリの監視フラグに「Ｙｅｓ」を登録する。自動的な処理においては、新規機器を監視対象とするか否かについてユーザ問い合わせる適切なタイミングがないため、発注支援プログラム１１が自動的に監視フラグを「Ｙｅｓ」とするのである。ここで、「Ｎｏ」ではなく「Ｙｅｓ」とするのは、ユーザは、ネットワーク５０に接続されている機器３０のサプライを監視させたいからこそ監視プログラム２１をインストールしているのであり、かかるユーザの意図に基づけば、新規機器はデフォルトで監視対象とされるのが妥当であると考えられるからである。また、発注サイト側にとっても、できるだけ多くの機器を監視対象とすることで、サプライの販売促進等を期待できる。

一方、カレント機器のＭＡＣアドレスを有するエントリが既に存在した場合（Ｓ３５４でＮｏ）、当該エントリのベンダ名及び機種名が、カレント機器のベンダ名及び機種名と一致するか否かを判定する（Ｓ３５６）。この判定は、ＭＡＣアドレスの一致だけでは必ずしも機器の同一性は保証されないことに基づく。すなわち、ＭＡＣアドレスがネットワークカードから取得されるタイプの機器も存在し得るところ、当該ネットワークカードが他の機器に差し替えられてしまう可能性があるため、ＭＡＣアドレスによる機器の識別は必ずしも完全なものでないからである。

カレント機器のＭＡＣアドレスと一致するエントリについて、ベンダ名及び機種名の少なくともいずれか一方が一致しない場合、当該エントリの一致しない部分を更新し、更に、監視フラグを「Ｙｅｓ」とする。例えば、図１１は、機種名が一致しないエントリが存在した場合の機器情報テーブルの更新例を示す図である。

図１１では、５行目のエントリの機種名が一致しなかった場合の更新例が示されている。すなわち、５行目のエントリの機種名が、カレント機器の検索機器情報に含まれている機種名に変更され、更に、監視フラグが「Ｙｅｓ」とされている。監視フラグが「Ｙｅｓ」とされるのは、このような機器は新機器として扱うのが妥当であると考えるからである。

一方、カレント機器のＭＡＣアドレスを有するエントリが既に存在した場合であって（Ｓ３５４でＮｏ）、当該エントリのベンダ名及び機種名が、カレント機器のベンダ名及び機種名と一致する場合（Ｓ３５５でＮｏ）、カレント機器は既に当該エントリに登録されている機器であると判定する。但し、カレント機器の一部の属性（例えば、シリアル番号等）に変更がある場合は、当該エントリにおける当該一部の属性に対応する項目を更新する（Ｓ３５８）。但し、監視フラグは変更しない。すなわち、「Ｎｏ」であってもそのままとする。「Ｎｏ」とされている監視フラグを自動的に変更してしまうことは、意識的に当該機器を監視対象から除いたユーザの意図に反することになるからである。

ステップＳ３５３〜Ｓ３５８までの処理が検索機器情報に含まれる全ての機器について完了すると（Ｓ３５２でＹｅｓ）、検索機器情報の登録が成功した旨を監視サービス２１２に返信し（Ｓ３６０）、処理を終了する。なお、ユーザ認証に失敗した場合は（Ｓ３５１でＮｏ）、機器情報テーブル１２の更新は行わず、エラー情報を監視サービス２１２に返信する（Ｓ３５９）。

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

監視サービス２１２は、繰り返し（例えば、定期的に）訪れる機器状態監視時間になると、発注支援サーバ１１に監視対象となっている機器３０（以下、「監視機器」という。）のリストを問い合わせる（Ｓ１０１）。発注支援プログラム１１は、機器情報テーブル１２の監視フラグに基づいて監視機器をリストアップし、リストアップされた監視機器の登録情報の一覧（監視機器リスト）を監視サービス２１２に返信する（Ｓ１０２）。なお、監視サービス２１２は、機器状態監視時間以外にも、例えばユーザのメニュー選択によって機器監視を行うようにしてもよい。このように、監視サービス２１２側では、各機器が監視対象であるか否かについては自ら管理せず、発注支援サーバ１１側に問い合わせることで監視機器を識別する。かかる構成により監視サービス２１２の実装を簡便化させることができ、処理負荷を低減させることができる。

監視サービス２１２は、監視機器リストを受信すると、当該監視機器リストに基づいてキャッシュテーブルを更新する（Ｓ１０３）。ここでキャッシュテーブルとは、監視サービス２１２が監視機器のサプライのステータス等を管理するためのテーブルであり、例えば、クライアントＰＣ２０のメモリ上に構築される。

図１３は、キャッシュテーブルの構成例を示す図である。図１３に示されるように、キャッシュテーブル２７は、監視機器ごとにＭＡＣアドレス、ベンダ名、機種名、シリアル番号、備考、監視状態、サプライステータス、及び通知フラグ等が登録及び保持されるテーブルである。ステップＳ１０３では、受信された監視機器リストに基づいて、ＭＡＣアドレス、ベンダ名、機種名、シリアル番号、及び備考が登録又は更新される。例えば、受信された監視機器リストに含まれている監視機器と同一のＭＡＣアドレスに係るエントリがキャッシュテーブル２７に存在しない場合、監視サービス２１２は、当該監視機器に係るエントリをキャッシュテーブル２７に新たに追加する。また、同一のＭＡＣアドレスに係るエントリは存在するが、他の情報（ベンダ名、機種名、シリアル番号又は備考）が異なる場合、当該エントリについて当該異なる情報を更新する。また、監視機器リストに含まれていないＭＡＣアドレスを有するエントリがキャッシュテーブル２７に存在する場合、監視サービス２１２は、当該エントリを削除する。すなわち、キャッシュテーブル２７は、現時点において監視機器とされている機器についてのみエントリを保持する。なお、キャッシュテーブル２７において、監視状態、サプライステータス、及び通知フラグについては、後述の処理によって更新される項目であり、その内容についてはその都度説明する。

続いて、監視サービス２１２は、キャッシュテーブル２７にエントリされている機器３０（監視機器）に対して機器情報としてのＭＩＢ情報をＳＮＭＰに基づいて問い合わせる（Ｓ１０４）。問い合わせ対象となるＭＩＢ情報としては、少なくともトナーのステータス情報が含まれ、また、他のサプライのステータス情報が含まれていてもよい。各機器３０は、問い合わせ対象とされたＭＩＢ情報を監視サービス２１２に対して返信する（Ｓ１０５）。

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

全ての監視機器からの機器情報の取得（ポーリング）が完了すると、監視サービス２１２は、当該機器情報に基づいて、キャッシュテーブル２７の監視状態、サプライステータス、及び通知フラグを更新する（Ｓ１０６）。監視状態については、機器情報の取得に成功した機器に係るエントリについては「ＯＫ」を登録し、失敗した機器に係るエントリについては「ＮＧ」を登録する。また、サプライステータスについては、取得された機器情報に含まれているトナーステータス等、サプライの状態情報が登録される。通知フラグには、サプライステータスの値が変化した場合、「未通知」が登録される。すなわち、監視サービス２１２は、更新前のキャッシュテーブル２７に登録されているサプライステータスと、新たに取得された機器情報に含まれているサプライのステータス情報とを比較することによりサプライの状態の変化を検知し、状態の変化が検知されたサプライについて、キャッシュテーブル２７におけるエントリの通知フラグを「未通知」とする。なお、通知フラグは、サプライの状態変化が発注支援プログラム１１に通知済みか否かを判別するために用いられる。

図１４は、機器情報のポーリング結果に基づくキャッシュテーブルの更新例を示す図である。図１４は、図１３の状態からの更新例を示す。すなわち、一行目のエントリに関しては、サプライステータスが「ｎｏｒｍａｌ」（不足していない状態）から「ｎｅａｒ ｅｎｄ」（ニアエンド）に変化している。したがって、通知フラグの値は「未通知」に更新されている。同様に、四行目のエントリに関してもサプライステータスが「ｎｅａｒ ｅｎｄ」から「ｅｎｄ」（エンド）に変化しているため、通知フラグの値は「未通知」に更新されている。一方、三行目及び五行目のエントリは、サプライステータスは変化していないため、通知フラグの値も更新されていない。また、二行目のエントリは、監視状態が「ＮＧ」とされている。当該エントリに係る機器３０からの機器情報の取得に失敗したためである。この場合、サプライステータス及び通知フラグの値は更新されない。

続いて、監視サービス２１２は、更新されたキャッシュテーブル２７に基づいて、状態変化通知情報を生成する（Ｓ１０７）。監視サービス２１２は、キャッシュテーブル２７において通知フラグの値が「未通知」のエントリに係る機器に関して状態変化通知情報を生成する。したがって、図１４のキャッシュテーブル２７に基づけば、一行目、三行目及び四行目のエントリに係る機器に関して状態変化通知情報が生成される。

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

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

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

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

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

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

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

なお、図１４等に示されるキャッシュテーブル２７では、便宜上監視機器ごとに一つのエントリが割り当てられているが、複数のサプライの状態について（例えば、ＣＭＹＫそれぞれのトナーステータスやトータルカウンタ値等について）管理する場合は、当該サプライごとにエントリを割り当てればよい。また、状態変化通知情報に含める情報は、図１５に示され得ものに限定されず、必要に応じて、適宜決定すればよい。

続いて、監視サービス２１２は、生成された状態変化通知情報を発注支援プログラム１１に送信する（Ｓ１０８）。なお、状態変化通知情報は、各機器のものが同時に（一つのメッセージにまとめられて）送信されるのが通信負荷の低減の観点より好ましい。機器ごとに別個のメッセージとして送信される場合に比べ、オーバーヘッドを低下させることができるからである。

状態変化通知情報を受信した発注支援プログラム１１は、状態変化通知情報に基づく機器情報テーブルの更新や、サプライが不足している機器の判定等の処理を行う（Ｓ１０９）。なお、当該ステップにおける処理の詳細については後述する。

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

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

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

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

機器に関する情報は、当該機器のベンダ名、モデル名、及び備考等が含まれる。これらの情報は、状態変化通知情報に含まれているシリアル番号、ＭＡＣアドレス又はＩＰアドレス等をキーとして、機器データベースより取得すればよい。また、不足しているサプライに関する情報は、例えば、当該サプライがトナーである場合は、状態変化通知情報に含まれているトナーステータス、トナーＩＤ、トナー名称等が記載される。なお、一つの機器３０において複数のサプライが同時に不足した場合は、一つの不足通知メール２５０内に当該複数のサプライの不足を示す情報を含むメールを作成し、当該複数のサプライの不足が通知される。

不足通知メール２５０の送信後、発注支援プログラム１１は、状態変化通知情報の受信（Ｓ１０８）に応じた一連の処理（不足通知メール２５０の送信等）の処理結果を監視サービス２１２に返信する（Ｓ１１１）。監視サービス２１２は、当該処理結果が、処理の正常終了を示している場合（すなわち、状態変化通知情報が正常に処理された場合）は、キャッシュテーブル２７の通知フラグについて、「未通知」を「通知済み」に更新する（Ｓ１１２）。

図１７は、状態変化通知情報が正常に処理された際のキャッシュテーブルの更新例を示す図である。図１７は、図１４からの更新例を示す。図１７のキャッシュテーブル２７では、一行目、三行目及び四行目のエントリの通知フラグが、「未通知」から「通知済み」に更新されている。通知フラグの値がこのように更新されることにより、正常に処理されたサプライの状態変化について、二重に状態変化通知情報が送信されるのを抑止することができる。したがって、通信量を削減することができ、ひいては不足通知メール２５０の二重送信を抑止することもできる。

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

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

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

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

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

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

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

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

続いて、図１２におけるステップＳ１０９の処理の詳細について説明する。図１９は、発注支援プログラムによる状態変化通知情報に基づく処理を説明するためのフローチャートである。

状態変化通知情報を受信すると、発注支援プログラム１１は、状態変化通知情報と共に監視サービス２１２より送信されるユーザＩＤ及びパスワードに基づいてユーザの認証を行う（Ｓ４０１）。ユーザが認証された場合（Ｓ４０１でＹｅｓ）、状態変化通知情報が受信された機器ごとにステップＳ４０２以降の処理を行う。

まず、一つの機器を処理対象とし（以下、処理対象とされた機器を「カレント機器」という。）（Ｓ４０３）、カレント機器は機器情報テーブル１２に登録されているか否かを判定する（Ｓ４０４）。この判定は、カレント機器のＭＡＣアドレスをキーとして、機器情報テーブル１２に当該ＭＡＣアドレスを有するエントリが有るか否かによって行えばよい。カレント機器が未登録である場合（Ｓ４０４でＮｏ）、カレント機器のエントリを機器情報テーブル１２に登録する（Ｓ４０５）。この際、カレント機器は監視対象とする。なお、ＭＡＣアドレスに基づいてカレント機器が登録されていると判断された場合、図１０のＳ３５６〜Ｓ３５８において説明したような処理を行ってもよい。

続いて、状態変化通知情報に含まれているカレント機器のサプライのステータス情報を機器情報テーブル１２のステータスに反映（転記）する（Ｓ４０６）。続いて、機器情報テーブル１２に登録されているカレント機器のステータスに基づいて、カレント機器について不足していているサプライ（すなわち、ステータスが「Ｎｅ」（ニアエンド）又は「Ｅ」（エンド）のサプライ）の有無を判定する（Ｓ４０７）。不足しているサプライが存在する場合（Ｓ４０７でＹｅｓ）、機器情報テーブル１２においてカレント機器に係るエントリ（以下「カレントエントリ」という。）のメールフラグの値は「Ｙｅｓ」であるか否かを判定する（Ｓ４０８）。ここで、メールフラグは、不足通知メール２５０が送信された場合に「Ｙｅｓ」とされるフラグである。すなわち、メールフラグの値が「Ｙｅｓ」であるということは、過去にカレント機器について不足通知メール２５０が送信されたことがあることを意味する。

メールフラグが「Ｙｅｓ」の場合（Ｓ４０８でＹｅｓ）、不足通知メール２５０の重複送信チェックを行う（Ｓ４０９）。ここで、重複送信チェックとは、過去に同じ内容の不足通知メール２５０が送信されている可能性の有無を判定するための処理であり、その処理内容の詳細については後述する。重複送信チェックにおいて、重複送信の可能性は低く不足通知メール２５０は送信すると判定された場合（Ｓ４０９で「送信する」）、メールフラグを「Ｙｅｓ」とし（Ｓ４１０）、カレント機器に関する不足通知メール２５０を送信する（Ｓ４１１）。この処理は、図１２におけるステップＳ１１０に相当する。なお、ステップＳ４０７において、不足しているサプライが複数検知された場合は、当該複数のサプライについてまとめて一つの不足通知メール２５０が送信される。したがって、ユーザに送信される不足通知メール２５０の数を少なくすることができ、ユーザに与える煩雑さ等を低減させることができる。

また、重複送信チェックにおいて、重複送信の可能性が高く不足通知メール２５０は送信しないと判定された場合は（Ｓ４０９で「送信しない」）、不足通知メールは送信せずにカレント機器に関する処理を終了する。

一方、メールフラグが「Ｎｏ」の場合（Ｓ４０８でＹｅｓ）、不足通知メール２５０の重複のおそれはないため、重複送信チェックは行わず、メールフラグを「Ｙｅｓ」とし（Ｓ４１０）、不足通知メールを送信する（Ｓ４１１）。

また、Ｓ４０７において、カレント機器についていずれのサプライも不足していないと判定された場合、不足通知メールは送信する必要はないため、メールフラグを「Ｎｏ」とし、不足通知メールは送信せずにカレント機器に関する処理を終了する。

ステップＳ４０３〜Ｓ４１２までの処理が状態変化通知情報の受信された全ての機器について完了すると（Ｓ４０２でＹｅｓ）、状態変化通知情報が正常に処理されたことを監視サービス２１２に返信し（Ｓ４１４）、処理を終了する。この処理は、図１２におけるステップＳ１１１に相当する。なお、ユーザ認証に失敗した場合は（Ｓ４０１でＮｏ）、機器情報テーブル１２の更新は行わず、エラー情報を監視サービス２１２に返信する（Ｓ４１３）。

続いて、図１９におけるステップＳ４０９の不足通知メールの重複送信チェックの詳細について説明する。図２０は、不足通知メールの重複送信チェック処理を説明するための図である。当該処理の意義について説明する。

監視サービス２１２は、キャッシュテーブル２７の通知フラグに基づいて状態変化通知情報を送信するため、監視サービス２１２は、基本的には二重に同一の状態変化通知情報を送信することはない。しかしながら、例えば、トナーについては、トナーボトルの中にまだトナーが残っている場合にトナーエンドが検知される場合がある。このような場合、ユーザがトナーボトルを振った後に当該トナーボトルを取り付けると、しばらくしてから改めて同一のトナーについてトナーエンドが検知されてしまうことが考えられる。このような場合、通知フラグは、「ｅｎｄ」から「ｎｏｒｍａｌ」に変化し、再び「ｅｎｄ」に変化するため、トナーボトルが交換されていないにもかかわらず、監視サービス２１２は、再度トナーエンドを通知するための状態変化通知情報を送信してしまうことが考えられる。そうすると、ユーザに対して不足通知が重複して送信されてしまい、ユーザが重複に気付かなければ、重複した発注を行ってしまうということが考えられる。そこで、かかる事態の発生を回避するため、発注支援プログラム１１は、以下の処理を行う。

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

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

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

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

次に、監視プログラム２１におけるＵＩアプリ２１１の機能について説明する。ＵＩアプリ２１１は、監視サービス２１２に対する設定情報（例えば、機器情報を取得する周期）を設定させるための画面（以下「設定画面」という。）や、監視サービス２１２による機器の監視情報を表示させるための画面（以下「監視画面」という。）等を表示させるプログラムである。

ＵＩアプリ２１１は、ユーザからの指示に応じ、例えば次のような設定画面を表示させる。図２１は、設定画面の表示例を示す図である。図２１の設定画面２２０では、監視サービス２１２が監視機器より機器情報をポーリングする周期（参照番号２２１）と、ネットワーク５０上の機器を自動検索する周期（参照番号２２２）との設定を行うことができる。前者は、図１２のステップＳ１０４を実行する周期である。後者は、図３のステップＳ３２を実行する周期である。なお、後者については、チェックボックス２２３において、設定値を無効とすることもできる。すなわち、チェックボックス２２３のチェックがはずされると、機器３０の自動検索は行われない。

また、ＵＩアプリ２１１は、ユーザからの指示に応じ、例えば次のような監視画面を表示させる。図２２は、監視画面の表示例を示す図である。図２２の監視画面２３０は、ＵＩアプリ２１１が、キャッシュテーブル２７より取得した情報を表示させる画面である。したがって、監視画面２３０は、キャッシュテーブル２７において管理されている情報、すなわち、監視機器ごとに、ベンダ名、機種名、シリアル番号、サプライステータス、及び備考等を表示させる。監視画面２３０によって、ユーザは任意のタイミングで各監視機器のサプライの状態等を確認することができる。なお、参照番号２３１で示される「？」マークは、当該マークが付されている機器については機器情報のポーリングに失敗したことを示す。例えば、当該機器が起動されていないような場合や、ネットワーク５０から切断された場合等にかかる状態が発生し得る。

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

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

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

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

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

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

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

本発明の実施の形態における発注支援システムの構成例を示す図である。 監視サービスがクライアントＰＣに実行させる機能の概要を説明するためのフローチャートである。 発注支援システムにおけるユーザ登録時の処理手順を説明するためのシーケンス図である。 ユーザ登録ページの表示例を示す図である。 監視対象絞り込み情報の設定処理を説明するための図である。 監視対象絞り込み設定画面の表示例を示す図である。 機器データベースを構成する機器情報テーブルの構成例を示す図である。 検索機器一覧ページの表示例を示す図である。 監視の要否及び備考が登録された機器情報テーブルの例を示す図である。 発注支援プログラムによる機器情報テーブルの更新処理を説明するためのフローチャートである。 機種名が一致しないエントリが存在した場合の機器情報テーブルの更新例を示す図である。 発注支援システムにおける機器監視時の処理手順を説明するためのシーケンス図である。 キャッシュテーブルの構成例を示す図である。 機器情報のポーリング結果に基づくキャッシュテーブルの更新例を示す図である。 状態変化通知情報の構成例を示す図である。 不足通知メールの例を示す図である。 状態変化通知情報が正常に処理された際のキャッシュテーブルの更新例を示す図である。 発注ページの表示例を示す図である。 発注支援プログラムによる状態変化通知情報に基づく処理を説明するためのフローチャートである。 不足通知メールの重複送信チェック処理を説明するための図である。 設定画面の表示例を示す図である。 監視画面の表示例を示す図である。

符号の説明

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

Claims (16)

1. ネットワークに接続される機器を検索し、検索された機器より機器情報を取得する機器情報取得手段と、
   前記機器情報を構成する所定の属性に基づいて、監視対象の候補とする機器を絞り込むための情報を設定させる設定手段と、
   前記設定手段が設定させた情報に基づいて、前記検索された機器より前記監視対象の候補とする機器を抽出する抽出手段と、
   前記抽出手段によって抽出された機器の一覧を表示させ、前記一覧の中から前記監視対象とする機器を選択させる監視対象選択手段と、
   前記監視対象として選択された機器の消耗品の状態情報を取得し、前記状態情報を発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、
   前記機器監視装置より受信される前記状態情報に基づいて不足が検知された消耗品の発注用のＷｅｂページを示すＵＲＬが記載された電子メールを作成し、当該消耗品に係る機器に予め関連付けられて登録されているメールアドレスに前記電子メールを送信する前記発注支援装置とを備えることを特徴とする発注支援システム。
2. 前記状態情報送信手段は、前記状態情報に基づいて消耗品の不足を判定し、不足と判定された消耗品に係る前記状態情報を前記発注支援装置に送信することを特徴とする請求項１記載の発注支援システム。
3. 前記設定手段は、
   前記検索された機器の前記所定の属性の属性値の一覧を作成する属性値一覧作成手段と、
   前記属性値の一覧の中から前記監視対象の候補とする機器を絞り込むための属性値を選択させる属性値選択手段とを有し、
   前記抽出手段は、前記属性値選択手段が選択させた属性値を前記所定の属性の属性値とする機器を前記検索された機器より抽出することを特徴とする請求項１又は２記載の発注支援システム。
4. 前記属性値一覧作成手段は、前記属性値の重複を排除して前記属性値の一覧を作成することを特徴とする請求項３記載の発注支援システム。
5. 前記所定の属性は、前記機器のベンダ名であることを特徴とする請求項１乃至４いずれか一項記載の発注支援システム。
6. 請求項１乃至５いずれか一項記載の機器監視装置。
7. コンピュータが実行する機器監視方法であって、
   ネットワークに接続される機器を検索し、検索された機器より機器情報を取得する機器情報取得手順と、
   前記機器情報を構成する所定の属性に基づいて、監視対象の候補とする機器を絞り込むための情報を設定させる設定手順と、
   前記設定手順において設定された情報に基づいて、前記検索された機器より前記監視対象の候補とする機器を抽出する抽出手順と、
   前記抽出手順において抽出された機器の一覧を表示させ、前記一覧の中から前記監視対象とする機器を選択させる監視対象選択手順と、
   前記監視対象として選択された機器の消耗品の状態情報を取得し、前記状態情報を発注支援装置に送信する状態情報送信手順とを有し、
   前記発注支援装置は、受信される前記状態情報に基づいて不足が検知された消耗品の発注用のＷｅｂページを示すＵＲＬが記載された電子メールを作成し、当該消耗品に係る機器に予め関連付けられて登録されているメールアドレスに前記電子メールを送信することを特徴とする機器監視方法。
8. 前記状態情報送信手順は、前記状態情報に基づいて消耗品の不足を判定し、不足と判定された消耗品に係る前記状態情報を前記発注支援装置に送信することを特徴とする請求項７記載の機器監視方法。
9. 前記設定手順は、
   前記検索された機器の前記所定の属性の属性値の一覧を作成する属性値一覧作成手順と、
   前記属性値の一覧の中から前記監視対象の候補とする機器を絞り込むための属性値を選択させる属性値選択手順とを有し、
   前記抽出手順は、前記属性値選択手順において選択された属性値を前記所定の属性の属性値とする機器を前記検索された機器より抽出することを特徴とする請求項７又は８記載の機器監視方法。
10. 前記属性値一覧作成手順は、前記属性値の重複を排除して前記属性値の一覧を作成することを特徴とする請求項９記載の機器監視方法。
11. 前記所定の属性は、前記機器のベンダ名であることを特徴とする請求項７乃至１０いずれか一項記載の機器監視方法。
12. コンピュータに、
    ネットワークに接続される機器を検索し、検索された機器より機器情報を取得する機器情報取得手順と、
    前記機器情報を構成する所定の属性に基づいて、監視対象の候補とする機器を絞り込むための情報を設定させる設定手順と、
    前記設定手順において設定された情報に基づいて、前記検索された機器より前記監視対象の候補とする機器を抽出する抽出手順と、
    前記抽出手順において抽出された機器の一覧を表示させ、前記一覧の中から前記監視対象とする機器を選択させる監視対象選択手順と、
    前記監視対象として選択された機器の消耗品の状態情報を取得し、前記状態情報を発注支援装置に送信する状態情報送信手順とを実行させ、
    前記発注支援装置は、受信される前記状態情報に基づいて不足が検知された消耗品の発注用のＷｅｂページを示すＵＲＬが記載された電子メールを作成し、当該消耗品に係る機器に予め関連付けられて登録されているメールアドレスに前記電子メールを送信することを特徴とする機器監視プログラム。
13. 前記状態情報送信手順は、前記状態情報に基づいて消耗品の不足を判定し、不足と判定された消耗品に係る前記状態情報を前記発注支援装置に送信することを特徴とする請求項１２記載の機器監視プログラム。
14. 前記設定手順は、
    前記検索された機器の前記所定の属性の属性値の一覧を作成する属性値一覧作成手順と、
    前記属性値の一覧の中から前記監視対象の候補とする機器を絞り込むための属性値を選択させる属性値選択手順とを有し、
    前記抽出手順は、前記属性値選択手順において選択された属性値を前記所定の属性の属性値とする機器を前記検索された機器より抽出することを特徴とする請求項１２又は１３記載の機器監視プログラム。
15. 前記属性値一覧作成手順は、前記属性値の重複を排除して前記属性値の一覧を作成することを特徴とする請求項１４記載の機器監視プログラム。
16. 前記所定の属性は、前記機器のベンダ名であることを特徴とする請求項１２乃至１５いずれか一項記載の機器監視プログラム。

Images