発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラム
【課題】機器の消耗品の補給作業を簡便化させることのできる発注支援システムの提供を目的とする。
【解決手段】ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することにより上記課題を解決する。
【解決手段】ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することにより上記課題を解決する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムに関し、特に機器の消耗品の発注を支援する発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムに関する。
【背景技術】
【０００２】
企業におけるオフィスには、プリンタ、コピー機、ファクシミリ、又はこれらの機能を一台の筐体において実現する複合機等といった複数の機器がネットワークを介して接続されている。
【０００３】
上記に挙げた機器は、いずれも装置の使用によって消耗される消耗品を備えており、当該消耗品が適切に交換されることによってその機能が維持される。例えば、プリンタであれば、トナー、定着ユニット、排トナーボトル、感光体、又は現像剤等が相当し、これらは一般的にサプライと呼ばれている。
【０００４】
サプライの消耗度を機器の外部から識別するのは困難であるため、ユーザは印刷を指示してエラーが通知されたときにトナー切れを認識し、トナーの交換を行っていた。こうしたユーザによる作業を軽減するため、機器内部でサプライの寿命を検知し、そのサプライに関する情報を操作パネルへの表示や用紙への印字を行う技術や、機器自身がサプライ交換の必要性を表す信号を外部に通知し、その機器が設置されているオフィスに保守作業要員を派遣するという技術が提案されている。
【特許文献１】特開平１０−１９８２３６号公報
【特許文献２】特開２００３−２４５５６０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、サプライの寿命を検知したとしても、その後のサプライ発注やサプライ交換をユーザ自身が行う場合、交換対象のサプライの型番を正確に確認した上で発注手続きを行われなければならない。そのためサプライ発注までにユーザは煩雑な作業を強いられていた。また、発注自体は先に行っておきたいときでも、発注先の営業日や営業時間等によっては発注可能時期が発注先の営業所の業務時間に依存するという問題もある。さらに、保守作業要員を派遣する発注システムの場合、その分人件費や配送費等のコストも増えるという問題があった。
【０００６】
本発明は、上記の点に鑑みてなされたものであって、機器の消耗品の補給作業を簡便化させることのできる発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムの提供を目的とする。
【課題を解決するための手段】
【０００７】
そこで上記課題を解決するため、本発明の発注支援システムは、ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することを特徴とする。
【０００８】
このような発注支援システムでは、機器の消耗品の補給作業を簡便化させることができる。
【発明の効果】
【０００９】
本発明によれば、機器の消耗品の補給作業を簡便化させることのできる発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムを提供することができる。
【発明を実施するための最良の形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における発注支援システムの構成例を示す図である。図１において、発注支援システム１は、発注支援サーバ１０と、クライアントＰＣ２０と、機器３０ａ、３０ｂ、３０ｃ、及び３０ｄ等（以下、総称する場合「機器３０」という。）とを構成要素として含む。発注支援サーバ１０は、発注サイト（機器３０の消耗品の供給者側、例えば、機器３０のメーカー）に設置されており、クライアントＰＣ及び機器３０はユーザサイト（機器３０のユーザ側、例えば、オフィス等）に設置されている。発注支援サーバ１０とクライアントＰＣ２０とは、インターネット等の広域ネットワークによって接続されている。また、クライアント２０と機器３０とは、ユーザサイトに施設されたＬＡＮ（Local Area Network）等のネットワーク（有線又は無線の別は問わない）を介して接続されている。
【００１１】
機器３０は、例えば、一般的なプリンタや複合機等、トナーやインク等を消耗して、画像を形成する機器（画像形成装置）である。本実施の形態において機器３０は、ＭＩＢ（Management Information Base）に対応しており、ＳＮＭＰ（Simple Network Management Protocol）に基づいてネットワークを介して受信されるＭＩＢ情報の取得要求に応答することが可能である。また、本実施の形態において機器３０は、消耗品の状態情報を検知することができる。当該状態情報は、定性的（正常／ニアエンド／エンド）なものであってもよいし、定量的（１００％、９０％、...．．１０％、０％）なものであってもよい。
【００１２】
クライアントＰＣ２０は、汎用的なコンピュータであり、監視プログラム２１がインストールされる。監視プログラム２１は、ＣＤ−ＲＯＭ等の記録媒体５０２よりインストールされてもよいし、ネットワークを介してダウンロードされてもよい。後述するように、本実施の形態ではネットワーク４０を介してダウンロードされる。
【００１３】
図１において、監視プログラム２１は、ＵＩアプリ２１１及び監視サービス２１２より構成される。ＵＩアプリ２１１は、監視サービス２１２とは別プロセスとして起動され、監視サービス２１２の機能に関してＧＵＩ（Graphical User Interface）を提供するアプリケーションである。ＵＩアプリ２１１は、例えば、監視サービス２１２に対する設定情報を設定させるための画面や、監視サービス２１２によって取得される機器情報を表示させるための画面等を表示させる。
【００１４】
監視サービス２１２は、デーモンプロセスとして起動されるプログラムであり、クライアントＰＣ２０のメモリにロードされＣＰＵによって処理されることにより、クライアントＰＣ２０に以下の機能を実行させる。図２は、監視サービスがクライアントＰＣに実行させる機能の概要を説明するためのフローチャートである。
【００１５】
クライアントＰＣ２０は、監視サービス２１２に基づいて、各機器３０より機器情報（ＭＩＢ情報）を定期的に取得する（Ｓ３０１）。機器情報には、機器３０が使用する消耗品の状態を識別するための情報（状態情報）、例えば、トナーステータス及びトータルカウンタ値（総印刷枚数）等が含まれる。また、他の消耗品、具体的には、定着ユニット、排トナーボトル、感光体、又は現像剤等の状態を示す情報が含まれていてもよい。取得した結果、機器情報に含まれている消耗品の状態情報が定性的な情報（すなわち、正常／ニアエンド／エンド）である場合（Ｓ３０２で「定性情報」）、ニアエンド又はエンド情報（以下、「エンド」によって総称する）を取得すると（Ｓ３０３でＹｅｓ）、当該消耗品の不足であると判定し（Ｓ３０４）、機器３０の機器情報を発注支援サーバ１０へ送信する（Ｓ３０５）。一方、機器情報を取得した結果、状態情報が定量的な情報（すなわち、１００％、９０％、...．．１０％、０％）である場合（Ｓ３０２で「定量情報」）、所定の閾値（３０％以下）を下回っているかを調べ（Ｓ３０６）、下回っている場合（Ｓ３０６でＹｅｓ）、当該消耗品の不足であると判定し（Ｓ３０４）、機器３０の機器情報を発注支援サーバ１０へ送信する（Ｓ３０５）。
【００１６】
なお、本実施の形態では、監視装置２０が消耗品の不足を検知する例について説明するが、当該検知を発注支援サーバ１０に行わせてもよい。この場合、監視装置２０は全ての機器３０の機器情報を発注支援サーバ１０に送信することになる。したがって、ネットワーク負荷の軽減という観点からは、本実施の形態のように、監視装置２０において不足が検知された機器の機器情報のみを発注支援サーバ１０に送信する方が好ましい。
【００１７】
クライアントＰＣ２０には、また、電子メールの送受信を行うためのメーラや、Ｗｅｂページを閲覧するためのＷｅｂブラウザ等もインストールされている。
【００１８】
発注支援サーバ１０は、汎用的なコンピュータであり、Ｗｅｂサーバとしての機能が実装されていると共に、発注支援プログラム１１がインストールされている。発注支援プログラム１１は、ＣＤ−ＲＯＭ等の記録媒体５０１よりインストールされてもよいし、ネットワークを介してダウンロードされてもよい。
【００１９】
発注支援プログラム１１は、発注支援サーバ１０のメモリにロードされＣＰＵによって処理されることにより、発注支援サーバ１０に以下の機能を実行させる。すなわち、発注支援プログラム１１に基づいて、発注支援サーバ１０の電子メール作成手段は、クライアントＰＣ２０より受信される機器情報に基づいて不足している消耗品（以下「サプライ」という。）の補給を促進する電子メールを作成し、予め登録されているユーザのメールアドレスに送信する。当該電子メールには、不足していると判定されたサプライの発注用のＷｅｂページ（以下「サプライ発注ページ」という。）に対するＵＲＬが記載される。発注支援サーバ１０は、また、当該ＵＲＬのクリックに基づいて送信されるＨＴＴＰリクエストに応じて、サプライ発注ページを返信し、更に、サプライ発注ページに基づくサプライの発注要求を受信する。発注支援サーバ１０は、サプライ発注要求に応じて、サプライの発注指示を非図示の物品発注管理システムに送信する。
【００２０】
ところで、本発明者は、発注支援システム１を利用した新たなビジネスモデルの構築を検討している。まず、当該ビジネスモデルを構築するに至った背景について説明する。
【００２１】
一般的に、画像形成装置の販売は、代理店や接点店等、様々な販売チャネルを介して行われる。以下、メーカーから製品（画像形成装置）を仕入れて顧客に対して直接販売を行う業者を「販売業者」という。当該販売業者には、ハードウェアとしての画像形成装置を単に販売するだけでなく、顧客に応じたソリューションを付加価値として提供し、そのソリューションの中で画像形成装置を機能させるためのＳＩ作業等の業務を行うものも含まれる。これらの、販売業者は、ハードウェアとしての画像形成装置の販売による利益や、ＳＩ作業等に基づくソフトウェアによる利益等を主な収益原とている。
【００２２】
他方において、画像形成装置は、一度販売された後でもサプライの継続的な販売によって、継続的に利益を得られるという特性があり、またその利益は、一般的に画像形成装置の販売による利益よりも大きい。しかしながら、従来、顧客（ユーザ）は、機器の購入後は販売業者を介することなく量販店や通信販売等によりサプライを購入するのが一般的であった。したがって、画像形成装置を販売した販売業者は、当該画像形成装置のサプライによる継続的な利益を得ることができなかった。
【００２３】
ここで、或る販売業者がメーカーＡ及びメーカーＢの画像形成装置の販売を行っている場合を想定する。仮に、メーカーＡの画像形成装置を販売した場合は、当該画像形成装置のサプライの販売による利益が当該販売業者に還元されるとすれば、販売業者には、メーカーＢの画像形成装置よりもメーカーＡの画像形成装置をより多く販売したいというインセンティブが働く。その結果、メーカーＡの製品を売り上げの増加を期待することができ、メーカーＡは、メーカーＢに対して競争上優位な差別化を図ることが期待できる。
【００２４】
そこで、本発明者は、新たなビジネスモデルとして、サプライの販売による利益が販売業者に還元される仕組みを考案した。本実施の形態では、発注支援システム１を当該ビジネスモデルに適用した例について説明する。
【００２５】
以下、図１の発注支援システム１の処理手順について説明する。販売業者より機器３０を購入したユーザは、当該販売業者との間で発注支援システム１への登録契約を締結する。当該登録契約を結んだユーザは、図３に示されるようにまずユーザ登録を行う。なお、以下の説明から明らかになることであるが、ユーザは、発注支援システム１の利用によってサプライの補給作業にかかるコストを低減させることが期待できる。その期待が、ユーザにとって当該登録契約の締結に対するインセンティブとなる。
【００２６】
図３は、発注支援システムにおけるユーザ登録時の処理手順を説明するためのシーケンス図である。なお、図３において、Ｗｅｂブラウザ２２は、クライアントＰＣ２０にインストールされている汎用的なＷｅｂブラウザである。また、メーラ２３は、クライアントＰＣ２０にインストールされている汎用的なメーラである。
【００２７】
まず、ユーザは、登録契約の際に発注支援サーバ１０へアクセスするためのＩＤ（以下「アクセスＩＤ」という。）と、発注支援サーバ１０のＵＲＬとを販売業者より入手し、当該ＵＲＬをＷｅｂブラウザ２２に入力する。ＵＲＬの入力に応じてアクセスＩＤの入力が要求され、当該アクセスＩＤが正当に入力されると、ユーザ登録を行うためのＷｅｂページ（以下「ユーザ登録ページ」という。）が、発注支援サーバ１０よりＷｅｂブラウザ２２に送信される（Ｓ１１）。ユーザ登録ページを受信したＷｅｂブラウザ２２は、当該ユーザ登録ページを表示させる。
【００２８】
図４は、ユーザ登録ページの表示例を示す図である。図４の説明において（）内の数字は、図中における参照番号に対応する。図４に示されるように、ユーザ登録ページ２２０においては、ユーザの氏名（２２１）、郵便番号（２２２）、住所（２２３）、会社名（２２４）、部署名（２２５）、電話番号（２２６）、ＦＡＸ番号（２２７）、及び電子メールアドレス（２２８）等の基本情報の他、サプライを発注した際のサプライの配送先の郵便番号、住所、会社名、及び部署名等（２３１）と、販売業者ＩＤ（２３２）との入力が可能となっている。ここで、販売業者ＩＤは、当該ユーザが上記登録契約を締結した相手となる販売業者のＩＤであり、登録契約時に販売業者より通知される。
【００２９】
ユーザが、ユーザ登録ページ２２０において必要事項を入力し、登録ボタン２３３をクリックすると、Ｗｅｂブラウザ２２は、発注支援サーバ１０に対してユーザ登録を要求するＨＴＴＰリクエストを送信する（Ｓ１２）。当該ＨＴＴＰリクエストには、ユーザ登録ページ２２０への入力情報（以下、販売業者ＩＤも含めて「ユーザ情報」という。）が含まれている。
【００３０】
発注支援サーバ１０の発注支援プログラム１１は、ＨＴＴＰリクエストが受信されると、当該ＨＴＴＰリクエストに含まれているユーザ情報を所定のデータベース（以下「ユーザデータベース」という。）に登録する（Ｓ１３）。ユーザ情報の登録に際し、発注支援プログラム１１は、ユーザ情報に含まれている販売業者ＩＤが発注支援サーバ１０にエントリされているか否かを判定し、エントリされている場合は、当該ユーザに対するユーザＩＤ及びパスワードを生成又は採番する。更に、当該ユーザＩＤ及びパスワードをもユーザ情報に含めてユーザデータベースに登録する。
【００３１】
続いて、発注支援プログラム１１は、監視プログラム２１のダウンロードを実行させるためのＷｅｂページ（以下「ダウンロードページ」という。）へのＵＲＬや、生成されたユーザＩＤ及びパスワード等が本文に記載された電子メール（以下、「インストール情報通知メール」という。）をユーザのメールアドレスに送信する（Ｓ１４）。また、発注支援プログラム１１は、インストール情報通知メールを送信した旨のメッセージを表示させるＷｅｂページを、ステップＳ１２におけるＨＴＴＰリクエストに対するＨＴＴＰレスポンスに含めてＷｅｂブラウザ２２に対して送信する。ユーザは、当該Ｗｅｂページによって、インストール情報通知メールが自分宛に送信されたこと知ることができる。そして、メーラ２３によってインストール情報通知メールを閲覧することにより、ダウンロードページのＵＲＬや自分に対して割り有り当てられたユーザＩＤ及びパスワード等を確認することができる。
【００３２】
なお、ダウンロードページのＵＲＬ等の通知は、必ずしも電子メールによる必要はない。例えば、ステップＳ１４において、インストール情報通知メールを送信した旨のメッセージを表示させるＷｅｂページではなく、ダウンロードページが返信されるようにしてもよい。但し、ステップＳ１４のタイミングでダウンロードページが返信されてしまうと、そのままインストール作業を続行する必要があるのに対し、インストール情報通知メールによれば、当該メールの受信後ユーザの都合のいいときにインストール作業を行えるという点でユーザにとって便宜である。また、ＦＡＸや郵送によってこれらの情報が送付されるようにしてもよい。
【００３３】
ユーザが、インストール情報通知メールに記載されているダウンロードページのＵＲＬをクリックすると、メーラ２３は、当該ＵＲＬを引数としてＷｅｂブラウザ２２を起動させる。Ｗｅｂブラウザ２２は、起動すると、当該ＵＲＬに基づいてダウンロードページを表示させる。ユーザが、ダウンロードページにおいてダウンロード先のＵＲＬをクリックすると、Ｗｅｂブラウザ２２は、発注支援サーバ１０に対して、監視プログラム２１のダウンロード要求を送信する（Ｓ１５）。発注支援プログラム１１は、当該要求に応じ、発注支援サーバ１０に保存されている監視プログラム２１のインストールパッケージをクライアントＰＣ２０に転送する（Ｓ１６）。
【００３４】
ユーザは、ダウンロードされたインストールパッケージに含まれているインストーラ２５を起動する（Ｓ１７）。インストーラ２５は、起動されるとユーザに対してインストール情報通知メールにおいて通知されたユーザＩＤ及びパスワード等の入力を要求する。ユーザがユーザＩＤ及びパスワード等を入力すると、インストーラ２５は、入力されたユーザＩＤ及びパスワードを発注支援サーバ１０に送信し、ユーザの認証を要求する（Ｓ１８）。なお、入力されたユーザＩＤ及びパスワードは、クライアントＰＣ２０においても保存され、管理される。
【００３５】
発注支援プログラム１１は、インストーラ２５より送信されたユーザＩＤ及びパスワードと、ユーザデータベースに登録されているユーザＩＤ及びパスワードとを照合することによりユーザの認証を行う（Ｓ１９）。発注支援プログラム１１は、認証結果を監視プログラム２１に返信する（Ｓ２０）。インストーラ２５は、認証が成功した場合のみ監視プログラム２１のインストールを実行し（Ｓ２１）、認証が失敗した場合はインストールを中止する。
【００３６】
ユーザが認証された場合のみインストールを実行することで、例えば、インストールパッケージを不正に入手したユーザによるインストールを防止することができる。監視プログラム２１は、ネットワークを介して発注支援プログラム１１と通信を行うものである。したがって、不正ユーザによる監視プログラム２１の利用を防止し、発注支援サーバ１０に対するネットワークを介した攻撃を抑止するためにも、インストール時のユーザ認証は効果的である。
【００３７】
インストールが正常に行われると、監視プログラム２１の監視サービス２１２は、クライアントＰＣ２０上で動作を開始する。まず、監視サービス２１２はネットワーク５０に接続されている機器３０を検索し（Ｓ２２）、検索された全ての機器３０の情報（例えば、機器のシリアル番号、ＭＡＣアドレス、機種（モデル）名、ベンダ名（機器メーカーの名前）等を含む情報。以下「検索機器情報」という。）を、発注支援サーバ１０に送信する（Ｓ２３）。なお、ネットワーク５０上における機器３０の検索及び検索機器情報の取得は、周知の技術を用いて行うことが可能である。
【００３８】
発注支援プログラム１１は、受信された検索機器情報を所定のデータベース（以下「機器データベース」という。）に登録する（Ｓ２４）。
【００３９】
図５は、機器データベースを構成する機器情報テーブルの構成例を示す図である。図５に示されるように機器情報テーブル１２は、検索された機器３０ごとにＭＡＣアドレス、ベンダ名、機種名、シリアル番号、監視フラグ、備考、サプライのステータス、及びメールフラグ等が登録され、管理されるテーブルである。ＭＡＣアドレス、ベンダ名、機種名、及びシリアル番号は、検索機器情報に含まれているものがそのまま登録される。その他ＩＰアドレス等も登録されるが、図中では便宜上省略されている。
【００４０】
監視フラグは、監視サービス２１２の監視対象とされているか否かを示すフラグ情報であり、監視対象の場合は「Ｙｅｓ」、監視対象でない場合は「Ｎｏ」が登録される。なお、初期値としては「Ｙｅｓ」が登録される。但し、初期値はＮＵＬＬ（空）値であってもよい。備考は、ユーザの任意によって機器に関連付けておきたい情報が登録される項目である。
【００４１】
サプライのステータスは、サプライのステータスを識別するための情報が登録される項目である。本実施の形態では、Ｎ（Ｎｏｒｍａｌ）、Ｎｅ（Ｎｅａｒ Ｅｎｄ）、又はＥ（Ｅｎｄ）が登録されることとする。初期値としては「Ｎ」であってもよいし、ＮＵＬＬ値であってもよい。メールフラグについては後述する。
【００４２】
続いて、発注支援プログラム１１は、検索機器情報の一覧を表示させるＷｅｂページ（以下「検索機器一覧ページ」という。）のＵＲＬを監視サービス２１２へ送信する（Ｓ２５）。監視サービス２１２は、受信したＵＲＬを引数としてＷｅｂブラウザ２２を起動させる（Ｓ２６）。Ｗｅｂブラウザ２２は、起動すると、引数に指定されたＵＲＬに基づいて検索機器一覧ページを要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（Ｓ２７）。発注支援プログラム１１は、受信されたＨＴＴＰリクエストに応じ、機器情報テーブル１２に登録されている情報に基づいて検索機器情報一覧ページを生成し、当該検索機器情報一覧ページをＷｅｂブラウザ２２に返信する（Ｓ２８）。
【００４３】
図６は、検索機器一覧ページの表示例を示す図である。図６の説明において（）内の数字は、図中における参照番号に対応する。図６に示されるように、検索機器一覧ページ２４０には、検索された機器３０ごとに、シリアル番号、ＭＡＣアドレス、ＩＰアドレス、モデル名、及びベンダ名等が表示される。検索機器一覧ページ２４０には更に、機器３０ごとに、備考を入力させるための欄（２４１）と、監視サービス２１２による監視対象とするか否か（監視の要否）を選択させるためのチェックボタン（２４２）とが設けられている。すなわち、ユーザは、検索機器一覧ページ２４０において、機器３０ごとに備考の入力と監視対象とするか否かの選択とを行う。本実施の形態では、チェックボタンがチェックされた場合に、監視対象として選択されたものとする。備考欄２４１には、ユーザの任意によって自由な情報の入力が可能であるが、例えば、機器３０の配置場所等、サプライの交換作業の補助となるような情報を入力しておくとよい。
【００４４】
ユーザが、検索機器一覧ページ２４０において、各機器３０について備考の入力と、監視の要否の選択とを行い、送信ボタン２４３をクリックすると、Ｗｅｂブラウザ２２は、各機器３０の備考と監視の要否との登録を要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（Ｓ２９）。発注支援プログラム１１は、受信されたＨＴＴＰリクエストに基づき、各機器３０の備考と監視の要否とを機器情報テーブル１２に追加登録する（Ｓ３０）。すなわち、機器情報テーブル１２の「監視フラグ」については、監視対象とされた機器については「Ｙｅｓ」が登録され、監視対象とされなかった機器については「Ｎｏ」が登録される。
【００４５】
図７は、監視の要否及び備考が登録された機器情報テーブルの例を示す図である。図７の機器情報テーブル１２では、１行目のエントリの備考に「大森４Ｆ」といったような配置情報が登録された例が示されている。また監視フラグについては、１〜４行目のエントリに係る機器が監視対象とされ、５〜７行目のエントリに係る機器が監視対象から除かれた例が示されている
以上で、ユーザ登録時の処理は終了する。なお、監視プログラム２１は、インストール時以外にも、例えばユーザのメニュー選択によって機器検索情報の登録、検索機器一覧ページの表示をさせ、監視対象機器を追加させるようにしてもよい。
【００４６】
監視サービス２１２は、その後もネットワーク５０に接続されている機器３０の検索を自動的かつ繰り返し（例えば、定期的に）行う（Ｓ３１）。監視サービス２１２は、検索された機器の検索機器情報を発注支援サーバ１０に送信する（Ｓ３２）。発注支援プログラム１１は、受信された検索機器情報に基づいて、機器情報テーブル１２を更新する（Ｓ３３）。ネットワーク５０の構成が定期的に検査され、その検査結果に基づいて機器情報テーブル１２が更新されることで、機器情報テーブル１２の内容とネットワーク５０の構成との間にずれが発生する可能性を低くすることができる。
【００４７】
ステップＳ３３において実行される機器情報テーブルの更新処理の詳細について説明する。図８は、発注支援プログラムによる機器情報テーブルの更新処理を説明するためのフローチャートである。検索機器情報を受信すると発注支援プログラム１１は、検索機器情報と共に監視サービス２１２より送信されるユーザＩＤ及びパスワードに基づいてユーザの認証を行う（Ｓ３３１）。ユーザが認証された場合（Ｓ３３１でＹｅｓ）、検索機器情報に含まれている機器ごとにステップＳ３３２以降の処理を行う。
【００４８】
まず、一つの機器を処理対象とし（以下、処理対象とされた機器を「カレント機器」という。）（Ｓ３３３）、カレント機器が新たに検索された機器（以下「新規機器」という。）であるか否かを判定する（Ｓ３３４）。この判定は、カレント機器のＭＡＣアドレスをキーとして、機器情報テーブル１２に当該ＭＡＣアドレスを有するエントリが有るか否かによって行う。当該エントリが無ければカレント機器は新規機器であると判定される。
【００４９】
カレント機器は新規機器であると判定した場合（Ｓ３３４でＹｅｓ）、カレント機器のエントリを機器情報テーブル１２に登録する（Ｓ３３５）。この際、カレント機器は監視対象とする。すなわち、新たに追加されたエントリの監視フラグに「Ｙｅｓ」を登録する。自動的な処理においては、新規機器を監視対象とするか否かについてユーザ問い合わせる適切なタイミングがないため、発注支援プログラム１１が自動的に監視フラグを「Ｙｅｓ」とするのである。ここで、「Ｎｏ」ではなく「Ｙｅｓ」とするのは、ユーザは、ネットワーク５０に接続されている機器３０のサプライを監視させたいからこそ監視プログラム２１をインストールしているのであり、かかるユーザの意図に基づけば、新規機器はデフォルトで監視対象とされるのが妥当であると考えられるからである。また、発注サイト側にとっても、できるだけ多くの機器を監視対象とすることで、サプライの販売促進等を期待できるからである。
【００５０】
一方、カレント機器のＭＡＣアドレスを有するエントリが既に存在した場合（Ｓ３３４でＮｏ）、当該エントリのベンダ名及び機種名が、カレント機器のベンダ名及び機種名と一致するか否かを判定する（Ｓ３３６）。この判定は、ＭＡＣアドレスの一致だけでは必ずしも機器の同一性は保証されないことに基づく。すなわち、ＭＡＣアドレスがネットワークカードから取得されるタイプの機器も存在し得るところ、当該ネットワークカードが他の機器に差し替えられてしまう可能性があるため、ＭＡＣアドレスによる機器の識別は必ずしも完全なものでないからである。
【００５１】
カレント機器のＭＡＣアドレスと一致するエントリについて、ベンダ名及び機種名の少なくともいずれか一方が一致しない場合、当該エントリの一致しない部分を更新し、更に、監視フラグを「Ｙｅｓ」とする。例えば、図９は、機種名が一致しないエントリが存在した場合の機器情報テーブルの更新例を示す図である。
【００５２】
図９では、５行目のエントリの機種名が一致しなかった場合の更新例が示されている。すなわち、５行目のエントリの機種名が、カレント機器の検索機器情報に含まれている機種名に変更され、更に、監視フラグが「Ｙｅｓ」とされている。監視フラグが「Ｙｅｓ」とされるのは、このような機器は新機器として扱うのが妥当であると考えるからである。
【００５３】
一方、カレント機器のＭＡＣアドレスに有するエントリが既に存在した場合であって（Ｓ３３４でＮｏ）、当該エントリのベンダ名及び機種名が、カレント機器のベンダ名及び機種名と一致する場合（Ｓ３３５でＮｏ）、カレント機器は既に当該エントリに登録されている機器であると判定する。但し、カレント機器の一部の属性（例えば、シリアル番号等）に変更がある場合は、当該エントリにおける当該一部の属性に対応する項目を更新する（Ｓ３３８）。但し、監視フラグは変更しない。すんわち、「Ｎｏ」であってもそのままとする。「Ｎｏ」とされている監視フラグを自動的に変更してしまうことは、意識的に当該機器を監視対象から除いたユーザの意図に反することになるからである。
【００５４】
ステップＳ３３３〜Ｓ３３８までの処理が検索機器情報に含まれる全ての機器について完了すると（Ｓ３３２でＹｅｓ）、検索機器情報の登録が成功した旨を監視サービス２１２に返信し（Ｓ３４０）、処理を終了する。なお、ユーザ認証に失敗した場合は（Ｓ３３１でＮｏ）、機器情報テーブル１２の更新は行わず、エラー情報を監視サービス２１２に返信する（Ｓ３３９）。
【００５５】
次に、クライアントＰＣ２０にインストールされた監視プログラム２１（監視サービス２１２）によって機器３０の状態の監視が行われる際の発注支援システム１の処理手順について説明する。図１０は、発注支援システムにおける機器監視時の処理手順を説明するためのシーケンス図である。
【００５６】
監視サービス２１２は、繰り返し（例えば、定期的に）訪れる機器状態監視時間になると、発注支援サーバ１１に監視対象となっている機器３０（以下、「監視機器」という。）のリストを問い合わせる（Ｓ１０１）。発注支援プログラム１１は、機器情報テーブル１２の監視フラグに基づいて監視機器をリストアップし、リストアップされた監視機器の登録情報の一覧（監視機器リスト）を監視サービス２１２に返信する（Ｓ１０２）。なお、監視サービス２１２は、機器状態監視時間以外にも、例えばユーザのメニュー選択によって機器監視を行うようにしてもよい。このように、監視サービス２１２側では、各機器が監視対象であるか否かについては自ら管理せず、発注支援サーバ１１側に問い合わせることで監視機器を識別する。かかる構成により監視サービス２１２の実装を簡便化させることができ、処理負荷を低減させることができる。
【００５７】
監視サービス２１２は、監視機器リストを受信すると、当該監視機器リストに基づいてキャッシュテーブルを更新する（Ｓ１０３）。ここでキャッシュテーブルとは、監視サービス２１２が監視機器のサプライのステータス等を管理するためのテーブルであり、例えば、クライアントＰＣ２０のメモリ上に構築される。
【００５８】
図１１は、キャッシュテーブルの構成例を示す図である。図１１に示されるように、キャッシュテーブル２７は、監視機器ごとにＭＡＣアドレス、ベンダ名、機種名、シリアル番号、備考、監視情報、サプライステータス、及び通知フラグ等が登録及び保持されるテーブルである。ステップＳ１０３では、受信された監視機器リストに基づいて、ＭＡＣアドレス、ベンダ名、機種名、シリアル番号、及び備考が登録又は更新される。例えば、受信された監視機器リストに含まれている監視機器と同一のＭＡＣアドレスに係るエントリがキャッシュテーブル２７に存在しない場合、監視サービス２１２は、当該監視機器に係るエントリをキャッシュテーブル２７に新たに追加する。また、同一のＭＡＣアドレスに係るエントリは存在するが、他の情報（ベンダ名、機種名、シリアル番号又は備考）が異なる場合、当該エントリについて当該異なる情報を更新する。また、監視機器リストに含まれていないＭＡＣアドレスを有するエントリがキャッシュテーブル２７に存在する場合、監視サービス２１２は、当該エントリを削除する。すなわち、キャッシュテーブル２７は、現時点において監視機器とされている機器についてのみエントリを保持する。なお、キャッシュテーブル２７において、監視情報、サプライステータス、及び通知フラグについては、後述の処理によって更新される項目であり、その内容についてはその都度説明する。
【００５９】
続いて、監視サービス２１２は、キャッシュテーブル２７にエントリされている機器３０（監視機器）に対して機器情報としてのＭＩＢ情報をＳＮＭＰに基づいて問い合わせる（Ｓ１０４）。問い合わせ対象となるＭＩＢ情報としては、少なくともトナーのステータス情報が含まれ、また、他のサプライのステータス情報が含まれていてもよい。各機器３０は、問い合わせ対象とされたＭＩＢ情報を監視サービス２１２に対して返信する（Ｓ１０５）。
【００６０】
なお、本発明の実施にあたり、機器情報は必ずしもＭＩＢ情報に限定されず、機器情報を問い合わせるためのプロトコルはＳＮＭＰに限定されないが、標準化された技術を用いることにより、各機器３０のベンダが異なっていても、同じ手順によって機器情報の取得が可能であるという観点より、ＭＩＢやＳＮＭＰ等の標準技術に基づくのが好適である。
【００６１】
全ての監視機器からの機器情報の取得（ポーリング）が完了すると、監視サービス２１２は、当該機器情報に基づいて、キャッシュテーブル２７の監視状態、サプライステータス、及び通知フラグを更新する（Ｓ１０６）。監視状態については、機器情報の取得に成功した機器に係るエントリについては「ＯＫ」を登録し、失敗した機器に係るエントリについては「ＮＧ」を登録する。また、サプライステータスについては、取得された機器情報に含まれているトナーステータス等、サプライの状態情報が登録される。通知フラグには、サプライステータスの値が変化した場合、「未通知」が登録される。すなわち、監視サービス２１２は、更新前のキャッシュテーブル２７に登録されているサプライステータスと、新たに取得された機器情報に含まれているサプライのステータス情報とを比較することによりサプライの状態の変化を検知し、状態の変化が検知されたサプライについて、キャッシュテーブル２７におけるエントリの通知フラグを「未通知」とする。なお、通知フラグは、サプライの状態変化が発注支援プログラム１１に通知済みか否かを判別するために用いられる。
【００６２】
図１２は、機器情報のポーリング結果に基づくキャッシュテーブルの更新例を示す図である。図１２は、図１１の状態からの更新例を示す。すなわち、一行目のエントリに関しては、サプライステータスが「ｎｏｒｍａｌ」（不足していない状態）から「ｎｅａｒ ｅｎｄ」（ニアエンド）に変化している。したがって、通知フラグの値は「未通知」に更新されている。同様に、四行目のエントリに関してもサプライステータスが「ｎｅａｒ ｅｎｄ」から「ｅｎｄ」（エンド）に変化しているため、通知フラグの値は「未通知」に更新されている。一方、三行目及び五行目のエントリは、サプライステータスは変化していないため、通知フラグの値も更新されていない。また、二行目のエントリは、監視状態が「ＮＧ」とされている。当該エントリに係る機器３０からの機器情報の取得に失敗したためである。この場合、サプライステータス及び通知フラグの値は更新されない。
【００６３】
続いて、監視サービス２１２は、更新されたキャッシュテーブル２７に基づいて、状態変化通知情報を生成する（Ｓ１０７）。監視サービス２１２は、キャッシュテーブル２７において通知フラグの値が「未通知」のエントリに係る機器に関して状態変化通知情報を生成する。したがって、図１２のキャッシュテーブル２７に基づけば、一行目、三行目及び四行目のエントリに係る機器に関して状態変化通知情報が生成される。
【００６４】
図１３は、状態変化通知情報の構成例を示す図である。図１３において、状態変化通知情報は、ヘッダ情報と機器情報とから構成される。
【００６５】
ヘッダ情報は、日時、ユーザＩＤ、及びパスワード等を含む。日時は、機器情報を転送する日時である。ユーザＩＤ及びパスワードは、監視プログラム２１のインストール時に入力され、保存されているユーザＩＤ及びパスワードである。すなわち、ヘッダ情報は、機器３０より取得された情報ではない。
【００６６】
機器情報は、上記における機器情報と同義である。すなわち、機器３０よりＭＩＢ情報として取得された情報であり、当該機器３０のベンダ名、機種名（モデル名）、シリアル番号、ＭＡＣアドレス、ＩＰアドレス、トナーＩＤ（トナーボトルを特定するための情報、カラーであれば、トナーＩＤは各色ごとに付与され、モノクロであれば１個付与される）、トナー名称、トナーステータス、トナーレベル、トナー名（文字列）、トナー名（Ｃｏｄｅ）、及びトータルカウンタ値等を含む。これらは、ｐｕｂｌｉｃ ＭＩＢ（標準ＭＩＢ）として定義されているものであり、ベンダを問わずいずれの機器からも取得可能な情報である。
【００６７】
トナーステータスは、トナーの状態を示す情報である。また、トータルカウンタ値は、総印刷枚数を示す情報である。したがって、監視サービス２１２は、トナーステータスによってトナーエンドを検知する。また、トータルカウント値によって、感光体、定着ユニット、及び現像剤等の消耗度を判定する。但し、標準ＭＩＢにおけるトナーステータスでは、エンドとなったトナーの色までは特定することはできない。
【００６８】
そこで、本実施の形態における機器情報は、更に、モノクロカウンタ値、カラーカウンタ値、シアンカウンタ値、マゼンタカウンタ値、ブラックカウンタ値、及びレッドカウンタ値等をも含む。これらは、ｐｒｉｖａｔｅ ＭＩＢ（拡張ＭＩＢ）としてベンダ独自に定義されているものである。
【００６９】
例えば、本実施の形態では、メーカーＡの機器３０のみがこれらの拡張ＭＩＢに対応しているとすれば、メーカーＡの機器３０についての機器情報にはこれらの値が格納されるが、メーカーＡ以外の機器３０についての機器情報ではこれらの値は空となる。
【００７０】
例えば、モノクロカウンタ値は、モノクロ印刷による印刷枚数である。カラーカウンタ値は、カラー印刷による印刷枚数である。また、シアンカウンタ値、マゼンタカウンタ値、ブラックカウンタ値、及びレッドカウンタ値は、それぞれの色のトナーを使用した印刷枚数である。したがって、メーカーＡの機器３０であれば、色ごとにそのエンドを検知することが可能となる。
【００７１】
なお、図１２等に示されるキャッシュテーブル２７では、便宜上監視機器ごとに一つのエントリが割り当てられているが、複数のサプライの状態について（例えば、ＣＭＹＫそれぞれのトナーステータスやトータルカウンタ値等について）管理する場合は、当該サプライごとにエントリを割り当てればよい。また、状態変化通知情報に含める情報は、図１３に示され得ものに限定されず、必要に応じて、適宜決定すればよい。
【００７２】
続いて、監視サービス２１２は、生成された状態変化通知情報を発注支援プログラム１１に送信する（Ｓ１０８）。なお、状態変化通知情報は、各機器のものが同時に（一つのメッセージにまとめられて）送信されるのが通信負荷の低減の観点より好ましい。機器ごとに別個のメッセージとして送信される場合に比べ、オーバーヘッドを低下させることができるからである。
【００７３】
状態変化通知情報を受信した発注支援プログラム１１は、状態変化通知情報に基づく機器情報テーブルの更新や、サプライが不足している機器の判定等の処理を行う（Ｓ１０９）。なお、当該ステップにおける処理の詳細については後述する。
【００７４】
続いて、発注支援プログラム１１は、不足しているサプライの発注用のＷｅｂページ（以下「発注ページ」という。）を生成し、当該サプライが不足していることを通知する電子メール（以下「不足通知メール」という。）を作成し、ユーザのメールアドレスに対して送信する（Ｓ１１０）。不足通知メールには、発注ページのＵＲＬが記載される。なお、各不足通知メールには、ＩＤが付与され（以下「メールＩＤ」という。）、メールＩＤと共に、当該不足通知メールの対象とされた機器３０のシリアル番号等の機器３０を識別するための情報と、ユーザＩＤ又はメールアドレス等ユーザを識別するための情報と、送信日時等とが不足通知メールの送信履歴として保存される。
【００７５】
図１４は、不足通知メールの例を示す図である。図１４に示される不足通知メール２５０において、＜＞で囲まれた文字列は具体的な値ではなく、当該個所に記述される情報の内容を示す。
【００７６】
図１４に示されるように、不足通知メール２５０の宛先には、状態変化通知情報に係るユーザのメールアドレスが指定される。当該該ユーザのメールアドレスの特定は、状態変化通知情報に含まれているユーザＩＤ及びパスワードをキーとして、ユーザデータベースより検索すればよい。ユーザデータベースには、ユーザ登録時において、ユーザＩＤ及びパスワードと共にメールアドレスが登録されているからである。
【００７７】
不足通知メール２５０のタイトルには、当該メールが不足通知メールであることを示すタイトルが記載される。不足通知メール２５０の本文には、状態変化通知情報に係る機器に関する情報、不足しているサプライに関する情報、発注ページのＵＲＬ等が記載される。
【００７８】
機器に関する情報は、当該機器のベンダ名、モデル名、及び備考等が含まれる。これらの情報は、状態変化通知情報に含まれているシリアル番号、ＭＡＣアドレス又はＩＰアドレス等をキーとして、機器データベースより取得すればよい。また、不足しているサプライに関する情報は、例えば、当該サプライがトナーである場合は、状態変化通知情報に含まれているトナーステータス、トナーＩＤ、トナー名称等が記載される。なお、一つの機器３０において複数のサプライが同時に不足した場合は、一つの不足通知メール２５０内に当該複数のサプライの不足を示す情報を含むメールを作成し、当該複数のサプライの不足が通知される。
【００７９】
不足通知メール２５０の送信後、発注支援プログラム１１は、状態変化通知情報の受信（Ｓ１０８）に応じた一連の処理（不足通知メール２５０の送信等）の処理結果を監視サービス２１２に返信する（Ｓ１１１）。監視サービス２１２は、当該処理結果が、処理の正常終了を示している場合（すなわち、状態変化通知情報が正常に処理された場合）は、キャッシュテーブル２７の通知フラグについて、「未通知」を「通知済み」に更新する（Ｓ１１２）。
【００８０】
図１５は、状態変化通知情報が正常に処理された際のキャッシュテーブルの更新例を示す図である。図１５は、図１２からの更新例を示す。図１５のキャッシュテーブル２７では、一行目、三行目及び四行目のエントリの通知フラグが、「未通知」から「通知済み」に更新されている。通知フラグの値がこのように更新されることにより、正常に処理されたサプライの状態変化について、二重に状態変化通知情報が送信されるのを抑止することができる。したがって、通信量を削減することができ、ひいては不足通知メール２５０の二重送信を抑止することもできる。
【００８１】
クライアントＰＣ２０におけるメーラ２３によって不足通知メール２５０を閲覧したユーザは、印刷等を実行していないときでも、サプライの不足を認識することができる。また、備考として機器３０の配置場所等を入力しておけば、当該情報によって機器３０の配置場所の特定等を容易に行うことができる。
【００８２】
ユーザが、不足通知メール２５０に記載されている発注ページのＵＲＬをクリックすると、メーラ２３は、クリックされたＵＲＬを引数としてＷｅｂブラウザ２２を起動させる。Ｗｅｂブラウザ２２は、起動すると、引数に指定されたＵＲＬに基づいて発注ページを要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（Ｓ１１３）。発注支援プログラム１１は、受信されたＨＴＴＰリクエストに応じ、発注ページをＷｅｂブラウザ２２に返信する（Ｓ１１４）。Ｗｅｂブラウザ２２は、受信した発注ページを表示させる。
【００８３】
図１６は、発注ページの表示例を示す図である。図１６において、発注ページ２６０には、領域２６１においてサプライが不足している機器に関する情報（メーカー（ベンダ）名、モデル名、シリアル番号、備考（配置位置）が表示されている。また、領域２６２において、不足しているサプライの名称が表示されている。また、領域２６２では、当該機器に対応した各種サプライの一覧が表示され、それぞれの発注が可能となっている。すなわち、サプライごとに、その商品名（名称）が表示され、購入する数量の入力が可能とされている。なお、参照番号２６２１に示されるように、不足しているサプライについては予め必要な数量が入力されて表示されている。また、各商品名には、当該商品の概要説明を表示するＷｅｂページへのリンクが張られている。更に、領域２６３では、当該ユーザの過去の購入履歴が表示される。これによって、ユーザが重複して購入してしまうことを防止することができる。
【００８４】
なお、購入履歴は、ユーザデータベースにユーザごとに登録されている。すなわち、発注ページ２６０を介して商品の発注が行われると、発注された商品の情報がユーザデータベースに追加登録される。
【００８５】
ところで、図１６の発注ページ２６０では、イエローのトナーが不足している旨が通知されている。上述したように、標準ＭＩＢだけでは、不足しているトナーの色は特定できない。したがって、図１６の発注ページ２６０には、拡張ＭＩＢに登録されている情報に基づいて判定された結果が示されている。このように、発注支援システム１を展開するメーカーは、自らが定義した拡張ＭＩＢによって、発注支援システム１上のサービスにおいて、他社と差別化を図ることができる。すなわち、仮に、他社の機器３０のトナーエンドが検知された場合は、発注ページ２６０にはその色までは特定されて通知されない。なお、他社の機器３０のサプライについては、そもそも発注支援システム１による発注対象から除外するということも考えられるが、ユーザの利便性を考慮し、本実施の形態では、他社の機器３０のサプライの発注も可能としている。
【００８６】
発注ページ２６０において、ユーザが注文ボタン２６２２をクリックすると、Ｗｅｂブラウザ２２は、商品の発注を要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（Ｓ１１５）。
【００８７】
ＨＴＴＰリクエストに応じ、発注支援プログラム１１は、当該ユーザと関連付いている販売業者に対して当該発注要求に基づく利益の一部を供与するための情報を記録する（Ｓ１１６）。具体的には、発注業者ごとに、発注支援システム１によるサプライの売り上げを管理するデータベース（以下「販売業者データベース」という。）が構築されており、当該販売業者データベースの売り上げに、今回の発注による注文の内容（例えば、注文金額）が記録される。なお、販売業者は、メーカーとの間で発注支援システム１への参加契約を締結することにより、販売業者データベースへのエントリが作成される。また、販売業者ＩＤが与えられ、当該販売業者は、発注支援システム１上において、当該販売業者ＩＤによって識別される。なお、ステップＳ１１６において、受信されるＨＴＴＰリクエストに係るユーザの識別は、例えば、Ｗｅｂブラウザ２２とのセッションＩＤとユーザＩＤとを関連付けておき、その関連付けに基づいて、セッションＩＤよりユーザＩＤを特定することにより行えばよい。
【００８８】
発注支援プログラム１１は、更に、当該発注の指示を物品発注管理システムに指示する。この指示には、ユーザデータベースに登録されている配送先の情報が含まれている。物品発注支援システムに発注が指示されることにより、発注された商品は、実際にユーザの元に配送される。更に、ユーザから購入代金支払われると、販売業者データベースに、今回の発注による売り上げが確定したことが記録される。売り上げか確定することにより、当該販売業者には、売り上げに応じて販売促進金などの手当をメーカーから供与してもよい。
【００８９】
続いて、図１０におけるステップＳ１０９の処理の詳細について説明する。図１７は、発注支援プログラムによる状態変化通知情報に基づく処理を説明するためのフローチャートである。
【００９０】
状態変化通知情報を受信すると、発注支援プログラム１１は、状態変化通知情報と共に監視サービス２１２より送信されるユーザＩＤ及びパスワードに基づいてユーザの認証を行う（Ｓ４０１）。ユーザが認証された場合（Ｓ４０１でＹｅｓ）、状態変化通知情報が受信された機器ごとにステップＳ４０２以降の処理を行う。
【００９１】
まず、一つの機器を処理対象とし（以下、処理対象とされた機器を「カレント機器」という。）（Ｓ４０３）、カレント機器は機器情報テーブル１２に登録されているか否かを判定する（Ｓ４０４）。この判定は、カレント機器のＭＡＣアドレスをキーとして、機器情報テーブル１２に当該ＭＡＣアドレスを有するエントリが有るか否かによって行えばよい。カレント機器が未登録である場合（Ｓ４０４でＮｏ）、カレント機器のエントリを機器情報テーブル１２に登録する（Ｓ４０５）。この際、カレント機器は監視対象とする。なお、ＭＡＣアドレスに基づいてカレント機器が登録されていると判断された場合、図８のＳ３３６〜Ｓ３３８において説明したような処理を行ってもよい。
【００９２】
続いて、状態変化通知情報に含まれているカレント機器のサプライのステータス情報を機器情報テーブル１２のステータスに反映（転記）する（Ｓ４０６）。続いて、機器情報テーブル１２に登録されているカレント機器のステータスに基づいて、カレント機器について不足していているサプライ（すなわち、ステータスが「Ｎｅ」（ニアエンド）又は「Ｅ」（エンド）のサプライ）の有無を判定する（Ｓ４０７）。不足しているサプライが存在する場合（Ｓ４０７でＹｅｓ）、機器情報テーブル１２においてカレント機器に係るエントリ（以下「カレントエントリ」という。）のメールフラグの値は「Ｙｅｓ」であるか否かを判定する（Ｓ４０８）。ここで、メールフラグは、不足通知メール２５０が送信された場合に「Ｙｅｓ」とされるフラグである。すなわち、メールフラグの値が「Ｙｅｓ」であるということは、過去にカレント機器について不足通知メール２５０が送信されたことがあることを意味する。
【００９３】
メールフラグが「Ｙｅｓ」の場合（Ｓ４０８でＹｅｓ）、不足通知メール２５０の重複送信チェックを行う（Ｓ４０９）。ここで、重複送信チェックとは、同じ内容の不足通知メール２５０が送信された可能性の有無を判定するための処理であり、その処理内容の詳細については後述する。重複送信チェックにおいて、重複送信の可能性は低く不足通知メール２５０は送信すると判定された場合（Ｓ４０９で「送信する」）、メールフラグを「Ｙｅｓ」とし（Ｓ４１０）、カレント機器に関する不足通知メール２５０を送信する（Ｓ４１１）。この処理は、図１０におけるステップＳ１１０に相当する。なお、ステップＳ４０７において、不足しているサプライが複数検知された場合は、当該複数のサプライについてまとめて一つの不足通知メール２５０が送信される。したがって、ユーザに送信される不足通知メール２５０の数を少なくすることができ、ユーザに与える煩雑さ等を低減させることができる。
【００９４】
また、重複送信チェックにおいて、重複送信の可能性が高く不足通知メール２５０は送信しないと判定された場合は（Ｓ４０９で「送信しない」）、不足通知メールは送信せずにカレント機器に関する処理を終了する。
【００９５】
一方、メールフラグが「Ｎｏ」の場合（Ｓ４０８でＹｅｓ）、不足通知メール２５０の重複のおそれはないため、重複送信チェックは行わず、メールフラグを「Ｙｅｓ」とし（Ｓ４１０）、不足通知メールを送信する（Ｓ４１１）。
【００９６】
また、Ｓ４０７において、カレント機器についていずれのサプライも不足していないと判定された場合、この場合は不足通知メールは送信する必要はないため、メールフラグを「Ｎｏ」とし、不足通知メールは送信せずにカレント機器に関する処理を終了する。
【００９７】
ステップＳ４０３〜Ｓ４１２までの処理が状態変化通知情報の受信された全ての機器について完了すると（Ｓ４０２でＹｅｓ）、状態変化通知情報が正常に処理されたことを監視サービス２１２に返信し（Ｓ４１４）、処理を終了する。この処理は、図１０におけるステップＳ１１１に相当する。なお、ユーザ認証に失敗した場合は（Ｓ４０１でＮｏ）、機器情報テーブル１２の更新は行わず、エラー情報を監視サービス２１２に返信する（Ｓ４１３）。
【００９８】
続いて、図１７におけるステップＳ４０９の不足通知メールの重複送信チェックの詳細について説明する。図１８は、不足通知メールの重複送信チェック処理を説明するための図である。当該処理の意義について説明する。
【００９９】
監視サービス２１２は、キャッシュテーブル２７の通知フラグに基づいて状態変化通知情報を送信するため、監視サービス２１２は、基本的には二重に同一の状態変化通知情報を送信することはない。しかしながら、例えば、トナーについては、トナーボトルの中にまだトナーが残っている場合にトナーエンドが検知される場合がある。このような場合、ユーザがトナーボトルを振った後に当該トナーボトルを取り付けると、しばらくしてから改めて同一のトナーについてトナーエンドが検知されてしまうことが考えられる。このような場合、通知フラグは、「ｅｎｄ」から「ｎｏｒｍａｌ」に変化し、再び「ｅｎｄ」に変化するため、同一のトナーボトルが交換されていないにもかかわらず、監視サービス２１２は、再度トナーエンドを通知するための状態変化通知情報を送信してしまうことが考えられる。そうすると、ユーザに対して不足通知が重複して送信されてしまい、ユーザが重複に気付かなければ、重複した発注を行ってしまうということが考えられる。そこで、かかる事態の発生を回避するため、発注支援プログラム１１は、以下の処理を行う。
【０１００】
まず、監視サービス２１２より受信した状態変化通知情報に含まれている、機器３０のシリアル番号に基づいて、不足通知メールの送信履歴より当該機器３０に関して最後（前回）に送信した不足通知メールの日時をチェックする（Ｓ２０１）。
【０１０１】
送信履歴の中に、当該機器３０に対する不足通知メールの送信記録が含まれていない場合（Ｓ２０２でＹｅｓ）、不足通知メールを送信すると判定する（Ｓ２０３）。当該機器３０に関しては、今までに不足通知メールを送信したことはなく、したがって、不足通知メールが重複するおそれはないからである。
【０１０２】
送信履歴の中に、当該機器３０に対する不足通知メールの送信記録が含まれている場合（Ｓ２０２でＮｏ）、最後に送信した不足通知メールの送信日時から所定期間が経過している否かを判定する（Ｓ２０４）。所定期間が経過していれば不足通知メールは送信すると判定し（Ｓ２０３）、経過していなければ重複のおそれがあるとして不足通知メールは送信しないと判定する（Ｓ２０５）。
【０１０３】
なお、図１８では、時間の経過に基づいて判定する例を示したが、例えば、送信履歴としてトータルカウンタを記録しておき、トータルカウンタの差分が所定の閾値以下の場合であれば、不足通知メールを送信しないようにしてもよい。また、送信履歴を一定時間ごとに全て削除するようにし、送信履歴の中に同一の機器３０に対する不足通知メールの送信記録が含まれている場合は、不足通知メールを送信しないようにしてもよい。
【０１０４】
次に、監視プログラム２１におけるＵＩアプリ２１１の機能について説明する。ＵＩアプリ２１１は、監視サービス２１２に対する設定情報（例えば、機器情報を取得する周期）を設定させるための画面（以下「設定画面」という。）や、監視サービス２１２による機器の監視情報を表示させるための画面（以下「監視画面」という。）等を表示させるプログラムである。
【０１０５】
ＵＩアプリ２１１は、ユーザからの指示に応じ、例えば次のような設定画面を表示させる。図１９は、設定画面の表示例を示す図である。図１９の設定画面２２０では、監視サービス２１２が監視機器より機器情報をポーリングする周期（参照番号２２１）と、ネットワーク５０上の機器を自動検索する周期（参照番号２２２）との設定を行うことができる。前者は、図１０のステップＳ１０４を実行する周期である。後者は、図３のステップＳ３１を実行する周期である。なお、後者については、チェックボックス２２３において、設定値を無効とすることもできる。すなわち、チェックボックス２２３のチェックがはずされると、機器３０の自動検索は行われない。
【０１０６】
また、ＵＩアプリ２１１は、ユーザからの指示に応じ、例えば次のような監視画面を表示させる。図２０は、監視画面の表示例を示す図である。図２０の監視画面２３０は、ＵＩアプリ２１１が、キャッシュテーブル２７より取得した情報を表示させる画面である。したがって、キャッシュテーブル２７において管理されている情報、すなわち、監視機器ごとに、ベンダ名、機種名、シリアル番号、サプライステータス、及び備考等を表示させる。監視画面２３０によって、ユーザは任意のタイミングで各監視機器のサプライの状態等を確認することができる。なお、参照番号２３１で示される「？」マークは、当該マークが付されている機器については機器情報のポーリングに失敗したことを示す。例えば、当該機器が起動されていないような場合や、ネットワーク５０から切断された場合等にかかる状態が発生し得る。
【０１０７】
上述したように、本発明の実施の形態における発注支援システム１によれば、機器３０のユーザ（顧客）、販売業者、及びメーカーの三者のそれぞれに対して、利便性又は有益性を提供することができる。
【０１０８】
すなわち、機器３０のサプライの不足が自動的に検知され、不足通知メールがユーザの端末に自動的に送信される。その結果、ユーザは、不足通知メールに記載されているＵＲＬをクリックすることで発注ページ２６０を表示させることができ、発注ページ２６０によって不足しているサプライを簡便に発注することができる。したがって、ユーザ自らが機器３０に対応したサプライを特定したり、量販店に買い出しに行ったりするための手間を省くことができ、サプライの調達コストを低減させることができる。
【０１０９】
また、販売業者については、サプライによる収益の一部を獲得することができ、その収益源を拡大することができる。
【０１１０】
また、メーカーについては、販売業者に当該メーカーの機器を他社の機器より優先させて販売したいというインセンティブや、ユーザに当該メーカーの機器を購入したいというインセンティブを与えることができる。すなわち、発注支援システム１を介して販売されたサプライが当該メーカー製のものである場合は他社のサプライが販売された場合よりも還元率を高くしたり、又は、他社のサプライの場合は還元率を０としたりすれば、販売業者にとっては、当該メーカーの製品を販売した方が、サプライの販売による利益を多く享受できるからである。また、ユーザにとっては、当該メーカーの機器を購入すれば、例えば、不足したトナーの色の特定まで可能であるといった、きめ細かいサービスを受けられるという期待を与えることができるからである。
【０１１１】
更に、メーカーは、ユーザの機器情報を蓄積することによって、各機器３０の使用期間等をある程度推測することができる。その結果、買い換えの促進等、新たな販売活動への連携を効果的に行うことができる。
【０１１２】
なお、上記実施の形態では、ユーザとの間で発注支援システム１の登録契約を締結するのは機器を販売する業者である場合を例として説明したが、必ずしも、ユーザと当該登録契約を締結する相手側は、機器を販売した者に限定されない。機器は販売していない業者であっても、メーカーから発注支援システム１における販売業者ＩＤが与えられるようにしてもよい。この場合、当該業者は、機器の販売とは関係なく、発注支援システム１を介したサプライの販売による利益の還元を受けることができる。
【０１１３】
以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【０１１４】
【図１】本発明の実施の形態における発注支援システムの構成例を示す図である。
【図２】監視サービスがクライアントＰＣに実行させる機能の概要を説明するためのフローチャートである。
【図３】発注支援システムにおけるユーザ登録時の処理手順を説明するためのシーケンス図である。
【図４】ユーザ登録ページの表示例を示す図である。
【図５】機器データベースを構成する機器情報テーブルの構成例を示す図である。
【図６】検索機器一覧ページの表示例を示す図である。
【図７】監視の要否及び備考が登録された機器情報テーブルの例を示す図である。
【図８】発注支援プログラムによる機器情報テーブルの更新処理を説明するためのフローチャートである。
【図９】機種名が一致しないエントリが存在した場合の機器情報テーブルの更新例を示す図である。
【図１０】発注支援システムにおける機器監視時の処理手順を説明するためのシーケンス図である。
【図１１】キャッシュテーブルの構成例を示す図である。
【図１２】機器情報のポーリング結果に基づくキャッシュテーブルの更新例を示す図である。
【図１３】状態変化通知情報の構成例を示す図である。
【図１４】不足通知メールの例を示す図である。
【図１５】状態変化通知情報が正常に処理された際のキャッシュテーブルの更新例を示す図である。
【図１６】発注ページの表示例を示す図である。
【図１７】発注支援プログラムによる状態変化通知情報に基づく処理を説明するためのフローチャートである。
【図１８】不足通知メールの重複送信チェック処理を説明するための図である。
【図１９】設定画面の表示例を示す図である。
【図２０】監視画面の表示例を示す図である。
【符号の説明】
【０１１５】
１ 発注支援システム
１０ 発注支援サーバ
１１ 発注支援プログラム
１２ 機器情報テーブル
２０ クライアントＰＣ
２１ 監視プログラム
３０、３０ａ、３０ｂ、３０ｃ、３０ｄ 機器
４０、５０ ネットワーク
２１１ ＵＩアプリ
２１２ 監視サービス
５０１、５０２ 記録媒体
【技術分野】
【０００１】
本発明は、発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムに関し、特に機器の消耗品の発注を支援する発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムに関する。
【背景技術】
【０００２】
企業におけるオフィスには、プリンタ、コピー機、ファクシミリ、又はこれらの機能を一台の筐体において実現する複合機等といった複数の機器がネットワークを介して接続されている。
【０００３】
上記に挙げた機器は、いずれも装置の使用によって消耗される消耗品を備えており、当該消耗品が適切に交換されることによってその機能が維持される。例えば、プリンタであれば、トナー、定着ユニット、排トナーボトル、感光体、又は現像剤等が相当し、これらは一般的にサプライと呼ばれている。
【０００４】
サプライの消耗度を機器の外部から識別するのは困難であるため、ユーザは印刷を指示してエラーが通知されたときにトナー切れを認識し、トナーの交換を行っていた。こうしたユーザによる作業を軽減するため、機器内部でサプライの寿命を検知し、そのサプライに関する情報を操作パネルへの表示や用紙への印字を行う技術や、機器自身がサプライ交換の必要性を表す信号を外部に通知し、その機器が設置されているオフィスに保守作業要員を派遣するという技術が提案されている。
【特許文献１】特開平１０−１９８２３６号公報
【特許文献２】特開２００３−２４５５６０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、サプライの寿命を検知したとしても、その後のサプライ発注やサプライ交換をユーザ自身が行う場合、交換対象のサプライの型番を正確に確認した上で発注手続きを行われなければならない。そのためサプライ発注までにユーザは煩雑な作業を強いられていた。また、発注自体は先に行っておきたいときでも、発注先の営業日や営業時間等によっては発注可能時期が発注先の営業所の業務時間に依存するという問題もある。さらに、保守作業要員を派遣する発注システムの場合、その分人件費や配送費等のコストも増えるという問題があった。
【０００６】
本発明は、上記の点に鑑みてなされたものであって、機器の消耗品の補給作業を簡便化させることのできる発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムの提供を目的とする。
【課題を解決するための手段】
【０００７】
そこで上記課題を解決するため、本発明の発注支援システムは、ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することを特徴とする。
【０００８】
このような発注支援システムでは、機器の消耗品の補給作業を簡便化させることができる。
【発明の効果】
【０００９】
本発明によれば、機器の消耗品の補給作業を簡便化させることのできる発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムを提供することができる。
【発明を実施するための最良の形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における発注支援システムの構成例を示す図である。図１において、発注支援システム１は、発注支援サーバ１０と、クライアントＰＣ２０と、機器３０ａ、３０ｂ、３０ｃ、及び３０ｄ等（以下、総称する場合「機器３０」という。）とを構成要素として含む。発注支援サーバ１０は、発注サイト（機器３０の消耗品の供給者側、例えば、機器３０のメーカー）に設置されており、クライアントＰＣ及び機器３０はユーザサイト（機器３０のユーザ側、例えば、オフィス等）に設置されている。発注支援サーバ１０とクライアントＰＣ２０とは、インターネット等の広域ネットワークによって接続されている。また、クライアント２０と機器３０とは、ユーザサイトに施設されたＬＡＮ（Local Area Network）等のネットワーク（有線又は無線の別は問わない）を介して接続されている。
【００１１】
機器３０は、例えば、一般的なプリンタや複合機等、トナーやインク等を消耗して、画像を形成する機器（画像形成装置）である。本実施の形態において機器３０は、ＭＩＢ（Management Information Base）に対応しており、ＳＮＭＰ（Simple Network Management Protocol）に基づいてネットワークを介して受信されるＭＩＢ情報の取得要求に応答することが可能である。また、本実施の形態において機器３０は、消耗品の状態情報を検知することができる。当該状態情報は、定性的（正常／ニアエンド／エンド）なものであってもよいし、定量的（１００％、９０％、...．．１０％、０％）なものであってもよい。
【００１２】
クライアントＰＣ２０は、汎用的なコンピュータであり、監視プログラム２１がインストールされる。監視プログラム２１は、ＣＤ−ＲＯＭ等の記録媒体５０２よりインストールされてもよいし、ネットワークを介してダウンロードされてもよい。後述するように、本実施の形態ではネットワーク４０を介してダウンロードされる。
【００１３】
図１において、監視プログラム２１は、ＵＩアプリ２１１及び監視サービス２１２より構成される。ＵＩアプリ２１１は、監視サービス２１２とは別プロセスとして起動され、監視サービス２１２の機能に関してＧＵＩ（Graphical User Interface）を提供するアプリケーションである。ＵＩアプリ２１１は、例えば、監視サービス２１２に対する設定情報を設定させるための画面や、監視サービス２１２によって取得される機器情報を表示させるための画面等を表示させる。
【００１４】
監視サービス２１２は、デーモンプロセスとして起動されるプログラムであり、クライアントＰＣ２０のメモリにロードされＣＰＵによって処理されることにより、クライアントＰＣ２０に以下の機能を実行させる。図２は、監視サービスがクライアントＰＣに実行させる機能の概要を説明するためのフローチャートである。
【００１５】
クライアントＰＣ２０は、監視サービス２１２に基づいて、各機器３０より機器情報（ＭＩＢ情報）を定期的に取得する（Ｓ３０１）。機器情報には、機器３０が使用する消耗品の状態を識別するための情報（状態情報）、例えば、トナーステータス及びトータルカウンタ値（総印刷枚数）等が含まれる。また、他の消耗品、具体的には、定着ユニット、排トナーボトル、感光体、又は現像剤等の状態を示す情報が含まれていてもよい。取得した結果、機器情報に含まれている消耗品の状態情報が定性的な情報（すなわち、正常／ニアエンド／エンド）である場合（Ｓ３０２で「定性情報」）、ニアエンド又はエンド情報（以下、「エンド」によって総称する）を取得すると（Ｓ３０３でＹｅｓ）、当該消耗品の不足であると判定し（Ｓ３０４）、機器３０の機器情報を発注支援サーバ１０へ送信する（Ｓ３０５）。一方、機器情報を取得した結果、状態情報が定量的な情報（すなわち、１００％、９０％、...．．１０％、０％）である場合（Ｓ３０２で「定量情報」）、所定の閾値（３０％以下）を下回っているかを調べ（Ｓ３０６）、下回っている場合（Ｓ３０６でＹｅｓ）、当該消耗品の不足であると判定し（Ｓ３０４）、機器３０の機器情報を発注支援サーバ１０へ送信する（Ｓ３０５）。
【００１６】
なお、本実施の形態では、監視装置２０が消耗品の不足を検知する例について説明するが、当該検知を発注支援サーバ１０に行わせてもよい。この場合、監視装置２０は全ての機器３０の機器情報を発注支援サーバ１０に送信することになる。したがって、ネットワーク負荷の軽減という観点からは、本実施の形態のように、監視装置２０において不足が検知された機器の機器情報のみを発注支援サーバ１０に送信する方が好ましい。
【００１７】
クライアントＰＣ２０には、また、電子メールの送受信を行うためのメーラや、Ｗｅｂページを閲覧するためのＷｅｂブラウザ等もインストールされている。
【００１８】
発注支援サーバ１０は、汎用的なコンピュータであり、Ｗｅｂサーバとしての機能が実装されていると共に、発注支援プログラム１１がインストールされている。発注支援プログラム１１は、ＣＤ−ＲＯＭ等の記録媒体５０１よりインストールされてもよいし、ネットワークを介してダウンロードされてもよい。
【００１９】
発注支援プログラム１１は、発注支援サーバ１０のメモリにロードされＣＰＵによって処理されることにより、発注支援サーバ１０に以下の機能を実行させる。すなわち、発注支援プログラム１１に基づいて、発注支援サーバ１０の電子メール作成手段は、クライアントＰＣ２０より受信される機器情報に基づいて不足している消耗品（以下「サプライ」という。）の補給を促進する電子メールを作成し、予め登録されているユーザのメールアドレスに送信する。当該電子メールには、不足していると判定されたサプライの発注用のＷｅｂページ（以下「サプライ発注ページ」という。）に対するＵＲＬが記載される。発注支援サーバ１０は、また、当該ＵＲＬのクリックに基づいて送信されるＨＴＴＰリクエストに応じて、サプライ発注ページを返信し、更に、サプライ発注ページに基づくサプライの発注要求を受信する。発注支援サーバ１０は、サプライ発注要求に応じて、サプライの発注指示を非図示の物品発注管理システムに送信する。
【００２０】
ところで、本発明者は、発注支援システム１を利用した新たなビジネスモデルの構築を検討している。まず、当該ビジネスモデルを構築するに至った背景について説明する。
【００２１】
一般的に、画像形成装置の販売は、代理店や接点店等、様々な販売チャネルを介して行われる。以下、メーカーから製品（画像形成装置）を仕入れて顧客に対して直接販売を行う業者を「販売業者」という。当該販売業者には、ハードウェアとしての画像形成装置を単に販売するだけでなく、顧客に応じたソリューションを付加価値として提供し、そのソリューションの中で画像形成装置を機能させるためのＳＩ作業等の業務を行うものも含まれる。これらの、販売業者は、ハードウェアとしての画像形成装置の販売による利益や、ＳＩ作業等に基づくソフトウェアによる利益等を主な収益原とている。
【００２２】
他方において、画像形成装置は、一度販売された後でもサプライの継続的な販売によって、継続的に利益を得られるという特性があり、またその利益は、一般的に画像形成装置の販売による利益よりも大きい。しかしながら、従来、顧客（ユーザ）は、機器の購入後は販売業者を介することなく量販店や通信販売等によりサプライを購入するのが一般的であった。したがって、画像形成装置を販売した販売業者は、当該画像形成装置のサプライによる継続的な利益を得ることができなかった。
【００２３】
ここで、或る販売業者がメーカーＡ及びメーカーＢの画像形成装置の販売を行っている場合を想定する。仮に、メーカーＡの画像形成装置を販売した場合は、当該画像形成装置のサプライの販売による利益が当該販売業者に還元されるとすれば、販売業者には、メーカーＢの画像形成装置よりもメーカーＡの画像形成装置をより多く販売したいというインセンティブが働く。その結果、メーカーＡの製品を売り上げの増加を期待することができ、メーカーＡは、メーカーＢに対して競争上優位な差別化を図ることが期待できる。
【００２４】
そこで、本発明者は、新たなビジネスモデルとして、サプライの販売による利益が販売業者に還元される仕組みを考案した。本実施の形態では、発注支援システム１を当該ビジネスモデルに適用した例について説明する。
【００２５】
以下、図１の発注支援システム１の処理手順について説明する。販売業者より機器３０を購入したユーザは、当該販売業者との間で発注支援システム１への登録契約を締結する。当該登録契約を結んだユーザは、図３に示されるようにまずユーザ登録を行う。なお、以下の説明から明らかになることであるが、ユーザは、発注支援システム１の利用によってサプライの補給作業にかかるコストを低減させることが期待できる。その期待が、ユーザにとって当該登録契約の締結に対するインセンティブとなる。
【００２６】
図３は、発注支援システムにおけるユーザ登録時の処理手順を説明するためのシーケンス図である。なお、図３において、Ｗｅｂブラウザ２２は、クライアントＰＣ２０にインストールされている汎用的なＷｅｂブラウザである。また、メーラ２３は、クライアントＰＣ２０にインストールされている汎用的なメーラである。
【００２７】
まず、ユーザは、登録契約の際に発注支援サーバ１０へアクセスするためのＩＤ（以下「アクセスＩＤ」という。）と、発注支援サーバ１０のＵＲＬとを販売業者より入手し、当該ＵＲＬをＷｅｂブラウザ２２に入力する。ＵＲＬの入力に応じてアクセスＩＤの入力が要求され、当該アクセスＩＤが正当に入力されると、ユーザ登録を行うためのＷｅｂページ（以下「ユーザ登録ページ」という。）が、発注支援サーバ１０よりＷｅｂブラウザ２２に送信される（Ｓ１１）。ユーザ登録ページを受信したＷｅｂブラウザ２２は、当該ユーザ登録ページを表示させる。
【００２８】
図４は、ユーザ登録ページの表示例を示す図である。図４の説明において（）内の数字は、図中における参照番号に対応する。図４に示されるように、ユーザ登録ページ２２０においては、ユーザの氏名（２２１）、郵便番号（２２２）、住所（２２３）、会社名（２２４）、部署名（２２５）、電話番号（２２６）、ＦＡＸ番号（２２７）、及び電子メールアドレス（２２８）等の基本情報の他、サプライを発注した際のサプライの配送先の郵便番号、住所、会社名、及び部署名等（２３１）と、販売業者ＩＤ（２３２）との入力が可能となっている。ここで、販売業者ＩＤは、当該ユーザが上記登録契約を締結した相手となる販売業者のＩＤであり、登録契約時に販売業者より通知される。
【００２９】
ユーザが、ユーザ登録ページ２２０において必要事項を入力し、登録ボタン２３３をクリックすると、Ｗｅｂブラウザ２２は、発注支援サーバ１０に対してユーザ登録を要求するＨＴＴＰリクエストを送信する（Ｓ１２）。当該ＨＴＴＰリクエストには、ユーザ登録ページ２２０への入力情報（以下、販売業者ＩＤも含めて「ユーザ情報」という。）が含まれている。
【００３０】
発注支援サーバ１０の発注支援プログラム１１は、ＨＴＴＰリクエストが受信されると、当該ＨＴＴＰリクエストに含まれているユーザ情報を所定のデータベース（以下「ユーザデータベース」という。）に登録する（Ｓ１３）。ユーザ情報の登録に際し、発注支援プログラム１１は、ユーザ情報に含まれている販売業者ＩＤが発注支援サーバ１０にエントリされているか否かを判定し、エントリされている場合は、当該ユーザに対するユーザＩＤ及びパスワードを生成又は採番する。更に、当該ユーザＩＤ及びパスワードをもユーザ情報に含めてユーザデータベースに登録する。
【００３１】
続いて、発注支援プログラム１１は、監視プログラム２１のダウンロードを実行させるためのＷｅｂページ（以下「ダウンロードページ」という。）へのＵＲＬや、生成されたユーザＩＤ及びパスワード等が本文に記載された電子メール（以下、「インストール情報通知メール」という。）をユーザのメールアドレスに送信する（Ｓ１４）。また、発注支援プログラム１１は、インストール情報通知メールを送信した旨のメッセージを表示させるＷｅｂページを、ステップＳ１２におけるＨＴＴＰリクエストに対するＨＴＴＰレスポンスに含めてＷｅｂブラウザ２２に対して送信する。ユーザは、当該Ｗｅｂページによって、インストール情報通知メールが自分宛に送信されたこと知ることができる。そして、メーラ２３によってインストール情報通知メールを閲覧することにより、ダウンロードページのＵＲＬや自分に対して割り有り当てられたユーザＩＤ及びパスワード等を確認することができる。
【００３２】
なお、ダウンロードページのＵＲＬ等の通知は、必ずしも電子メールによる必要はない。例えば、ステップＳ１４において、インストール情報通知メールを送信した旨のメッセージを表示させるＷｅｂページではなく、ダウンロードページが返信されるようにしてもよい。但し、ステップＳ１４のタイミングでダウンロードページが返信されてしまうと、そのままインストール作業を続行する必要があるのに対し、インストール情報通知メールによれば、当該メールの受信後ユーザの都合のいいときにインストール作業を行えるという点でユーザにとって便宜である。また、ＦＡＸや郵送によってこれらの情報が送付されるようにしてもよい。
【００３３】
ユーザが、インストール情報通知メールに記載されているダウンロードページのＵＲＬをクリックすると、メーラ２３は、当該ＵＲＬを引数としてＷｅｂブラウザ２２を起動させる。Ｗｅｂブラウザ２２は、起動すると、当該ＵＲＬに基づいてダウンロードページを表示させる。ユーザが、ダウンロードページにおいてダウンロード先のＵＲＬをクリックすると、Ｗｅｂブラウザ２２は、発注支援サーバ１０に対して、監視プログラム２１のダウンロード要求を送信する（Ｓ１５）。発注支援プログラム１１は、当該要求に応じ、発注支援サーバ１０に保存されている監視プログラム２１のインストールパッケージをクライアントＰＣ２０に転送する（Ｓ１６）。
【００３４】
ユーザは、ダウンロードされたインストールパッケージに含まれているインストーラ２５を起動する（Ｓ１７）。インストーラ２５は、起動されるとユーザに対してインストール情報通知メールにおいて通知されたユーザＩＤ及びパスワード等の入力を要求する。ユーザがユーザＩＤ及びパスワード等を入力すると、インストーラ２５は、入力されたユーザＩＤ及びパスワードを発注支援サーバ１０に送信し、ユーザの認証を要求する（Ｓ１８）。なお、入力されたユーザＩＤ及びパスワードは、クライアントＰＣ２０においても保存され、管理される。
【００３５】
発注支援プログラム１１は、インストーラ２５より送信されたユーザＩＤ及びパスワードと、ユーザデータベースに登録されているユーザＩＤ及びパスワードとを照合することによりユーザの認証を行う（Ｓ１９）。発注支援プログラム１１は、認証結果を監視プログラム２１に返信する（Ｓ２０）。インストーラ２５は、認証が成功した場合のみ監視プログラム２１のインストールを実行し（Ｓ２１）、認証が失敗した場合はインストールを中止する。
【００３６】
ユーザが認証された場合のみインストールを実行することで、例えば、インストールパッケージを不正に入手したユーザによるインストールを防止することができる。監視プログラム２１は、ネットワークを介して発注支援プログラム１１と通信を行うものである。したがって、不正ユーザによる監視プログラム２１の利用を防止し、発注支援サーバ１０に対するネットワークを介した攻撃を抑止するためにも、インストール時のユーザ認証は効果的である。
【００３７】
インストールが正常に行われると、監視プログラム２１の監視サービス２１２は、クライアントＰＣ２０上で動作を開始する。まず、監視サービス２１２はネットワーク５０に接続されている機器３０を検索し（Ｓ２２）、検索された全ての機器３０の情報（例えば、機器のシリアル番号、ＭＡＣアドレス、機種（モデル）名、ベンダ名（機器メーカーの名前）等を含む情報。以下「検索機器情報」という。）を、発注支援サーバ１０に送信する（Ｓ２３）。なお、ネットワーク５０上における機器３０の検索及び検索機器情報の取得は、周知の技術を用いて行うことが可能である。
【００３８】
発注支援プログラム１１は、受信された検索機器情報を所定のデータベース（以下「機器データベース」という。）に登録する（Ｓ２４）。
【００３９】
図５は、機器データベースを構成する機器情報テーブルの構成例を示す図である。図５に示されるように機器情報テーブル１２は、検索された機器３０ごとにＭＡＣアドレス、ベンダ名、機種名、シリアル番号、監視フラグ、備考、サプライのステータス、及びメールフラグ等が登録され、管理されるテーブルである。ＭＡＣアドレス、ベンダ名、機種名、及びシリアル番号は、検索機器情報に含まれているものがそのまま登録される。その他ＩＰアドレス等も登録されるが、図中では便宜上省略されている。
【００４０】
監視フラグは、監視サービス２１２の監視対象とされているか否かを示すフラグ情報であり、監視対象の場合は「Ｙｅｓ」、監視対象でない場合は「Ｎｏ」が登録される。なお、初期値としては「Ｙｅｓ」が登録される。但し、初期値はＮＵＬＬ（空）値であってもよい。備考は、ユーザの任意によって機器に関連付けておきたい情報が登録される項目である。
【００４１】
サプライのステータスは、サプライのステータスを識別するための情報が登録される項目である。本実施の形態では、Ｎ（Ｎｏｒｍａｌ）、Ｎｅ（Ｎｅａｒ Ｅｎｄ）、又はＥ（Ｅｎｄ）が登録されることとする。初期値としては「Ｎ」であってもよいし、ＮＵＬＬ値であってもよい。メールフラグについては後述する。
【００４２】
続いて、発注支援プログラム１１は、検索機器情報の一覧を表示させるＷｅｂページ（以下「検索機器一覧ページ」という。）のＵＲＬを監視サービス２１２へ送信する（Ｓ２５）。監視サービス２１２は、受信したＵＲＬを引数としてＷｅｂブラウザ２２を起動させる（Ｓ２６）。Ｗｅｂブラウザ２２は、起動すると、引数に指定されたＵＲＬに基づいて検索機器一覧ページを要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（Ｓ２７）。発注支援プログラム１１は、受信されたＨＴＴＰリクエストに応じ、機器情報テーブル１２に登録されている情報に基づいて検索機器情報一覧ページを生成し、当該検索機器情報一覧ページをＷｅｂブラウザ２２に返信する（Ｓ２８）。
【００４３】
図６は、検索機器一覧ページの表示例を示す図である。図６の説明において（）内の数字は、図中における参照番号に対応する。図６に示されるように、検索機器一覧ページ２４０には、検索された機器３０ごとに、シリアル番号、ＭＡＣアドレス、ＩＰアドレス、モデル名、及びベンダ名等が表示される。検索機器一覧ページ２４０には更に、機器３０ごとに、備考を入力させるための欄（２４１）と、監視サービス２１２による監視対象とするか否か（監視の要否）を選択させるためのチェックボタン（２４２）とが設けられている。すなわち、ユーザは、検索機器一覧ページ２４０において、機器３０ごとに備考の入力と監視対象とするか否かの選択とを行う。本実施の形態では、チェックボタンがチェックされた場合に、監視対象として選択されたものとする。備考欄２４１には、ユーザの任意によって自由な情報の入力が可能であるが、例えば、機器３０の配置場所等、サプライの交換作業の補助となるような情報を入力しておくとよい。
【００４４】
ユーザが、検索機器一覧ページ２４０において、各機器３０について備考の入力と、監視の要否の選択とを行い、送信ボタン２４３をクリックすると、Ｗｅｂブラウザ２２は、各機器３０の備考と監視の要否との登録を要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（Ｓ２９）。発注支援プログラム１１は、受信されたＨＴＴＰリクエストに基づき、各機器３０の備考と監視の要否とを機器情報テーブル１２に追加登録する（Ｓ３０）。すなわち、機器情報テーブル１２の「監視フラグ」については、監視対象とされた機器については「Ｙｅｓ」が登録され、監視対象とされなかった機器については「Ｎｏ」が登録される。
【００４５】
図７は、監視の要否及び備考が登録された機器情報テーブルの例を示す図である。図７の機器情報テーブル１２では、１行目のエントリの備考に「大森４Ｆ」といったような配置情報が登録された例が示されている。また監視フラグについては、１〜４行目のエントリに係る機器が監視対象とされ、５〜７行目のエントリに係る機器が監視対象から除かれた例が示されている
以上で、ユーザ登録時の処理は終了する。なお、監視プログラム２１は、インストール時以外にも、例えばユーザのメニュー選択によって機器検索情報の登録、検索機器一覧ページの表示をさせ、監視対象機器を追加させるようにしてもよい。
【００４６】
監視サービス２１２は、その後もネットワーク５０に接続されている機器３０の検索を自動的かつ繰り返し（例えば、定期的に）行う（Ｓ３１）。監視サービス２１２は、検索された機器の検索機器情報を発注支援サーバ１０に送信する（Ｓ３２）。発注支援プログラム１１は、受信された検索機器情報に基づいて、機器情報テーブル１２を更新する（Ｓ３３）。ネットワーク５０の構成が定期的に検査され、その検査結果に基づいて機器情報テーブル１２が更新されることで、機器情報テーブル１２の内容とネットワーク５０の構成との間にずれが発生する可能性を低くすることができる。
【００４７】
ステップＳ３３において実行される機器情報テーブルの更新処理の詳細について説明する。図８は、発注支援プログラムによる機器情報テーブルの更新処理を説明するためのフローチャートである。検索機器情報を受信すると発注支援プログラム１１は、検索機器情報と共に監視サービス２１２より送信されるユーザＩＤ及びパスワードに基づいてユーザの認証を行う（Ｓ３３１）。ユーザが認証された場合（Ｓ３３１でＹｅｓ）、検索機器情報に含まれている機器ごとにステップＳ３３２以降の処理を行う。
【００４８】
まず、一つの機器を処理対象とし（以下、処理対象とされた機器を「カレント機器」という。）（Ｓ３３３）、カレント機器が新たに検索された機器（以下「新規機器」という。）であるか否かを判定する（Ｓ３３４）。この判定は、カレント機器のＭＡＣアドレスをキーとして、機器情報テーブル１２に当該ＭＡＣアドレスを有するエントリが有るか否かによって行う。当該エントリが無ければカレント機器は新規機器であると判定される。
【００４９】
カレント機器は新規機器であると判定した場合（Ｓ３３４でＹｅｓ）、カレント機器のエントリを機器情報テーブル１２に登録する（Ｓ３３５）。この際、カレント機器は監視対象とする。すなわち、新たに追加されたエントリの監視フラグに「Ｙｅｓ」を登録する。自動的な処理においては、新規機器を監視対象とするか否かについてユーザ問い合わせる適切なタイミングがないため、発注支援プログラム１１が自動的に監視フラグを「Ｙｅｓ」とするのである。ここで、「Ｎｏ」ではなく「Ｙｅｓ」とするのは、ユーザは、ネットワーク５０に接続されている機器３０のサプライを監視させたいからこそ監視プログラム２１をインストールしているのであり、かかるユーザの意図に基づけば、新規機器はデフォルトで監視対象とされるのが妥当であると考えられるからである。また、発注サイト側にとっても、できるだけ多くの機器を監視対象とすることで、サプライの販売促進等を期待できるからである。
【００５０】
一方、カレント機器のＭＡＣアドレスを有するエントリが既に存在した場合（Ｓ３３４でＮｏ）、当該エントリのベンダ名及び機種名が、カレント機器のベンダ名及び機種名と一致するか否かを判定する（Ｓ３３６）。この判定は、ＭＡＣアドレスの一致だけでは必ずしも機器の同一性は保証されないことに基づく。すなわち、ＭＡＣアドレスがネットワークカードから取得されるタイプの機器も存在し得るところ、当該ネットワークカードが他の機器に差し替えられてしまう可能性があるため、ＭＡＣアドレスによる機器の識別は必ずしも完全なものでないからである。
【００５１】
カレント機器のＭＡＣアドレスと一致するエントリについて、ベンダ名及び機種名の少なくともいずれか一方が一致しない場合、当該エントリの一致しない部分を更新し、更に、監視フラグを「Ｙｅｓ」とする。例えば、図９は、機種名が一致しないエントリが存在した場合の機器情報テーブルの更新例を示す図である。
【００５２】
図９では、５行目のエントリの機種名が一致しなかった場合の更新例が示されている。すなわち、５行目のエントリの機種名が、カレント機器の検索機器情報に含まれている機種名に変更され、更に、監視フラグが「Ｙｅｓ」とされている。監視フラグが「Ｙｅｓ」とされるのは、このような機器は新機器として扱うのが妥当であると考えるからである。
【００５３】
一方、カレント機器のＭＡＣアドレスに有するエントリが既に存在した場合であって（Ｓ３３４でＮｏ）、当該エントリのベンダ名及び機種名が、カレント機器のベンダ名及び機種名と一致する場合（Ｓ３３５でＮｏ）、カレント機器は既に当該エントリに登録されている機器であると判定する。但し、カレント機器の一部の属性（例えば、シリアル番号等）に変更がある場合は、当該エントリにおける当該一部の属性に対応する項目を更新する（Ｓ３３８）。但し、監視フラグは変更しない。すんわち、「Ｎｏ」であってもそのままとする。「Ｎｏ」とされている監視フラグを自動的に変更してしまうことは、意識的に当該機器を監視対象から除いたユーザの意図に反することになるからである。
【００５４】
ステップＳ３３３〜Ｓ３３８までの処理が検索機器情報に含まれる全ての機器について完了すると（Ｓ３３２でＹｅｓ）、検索機器情報の登録が成功した旨を監視サービス２１２に返信し（Ｓ３４０）、処理を終了する。なお、ユーザ認証に失敗した場合は（Ｓ３３１でＮｏ）、機器情報テーブル１２の更新は行わず、エラー情報を監視サービス２１２に返信する（Ｓ３３９）。
【００５５】
次に、クライアントＰＣ２０にインストールされた監視プログラム２１（監視サービス２１２）によって機器３０の状態の監視が行われる際の発注支援システム１の処理手順について説明する。図１０は、発注支援システムにおける機器監視時の処理手順を説明するためのシーケンス図である。
【００５６】
監視サービス２１２は、繰り返し（例えば、定期的に）訪れる機器状態監視時間になると、発注支援サーバ１１に監視対象となっている機器３０（以下、「監視機器」という。）のリストを問い合わせる（Ｓ１０１）。発注支援プログラム１１は、機器情報テーブル１２の監視フラグに基づいて監視機器をリストアップし、リストアップされた監視機器の登録情報の一覧（監視機器リスト）を監視サービス２１２に返信する（Ｓ１０２）。なお、監視サービス２１２は、機器状態監視時間以外にも、例えばユーザのメニュー選択によって機器監視を行うようにしてもよい。このように、監視サービス２１２側では、各機器が監視対象であるか否かについては自ら管理せず、発注支援サーバ１１側に問い合わせることで監視機器を識別する。かかる構成により監視サービス２１２の実装を簡便化させることができ、処理負荷を低減させることができる。
【００５７】
監視サービス２１２は、監視機器リストを受信すると、当該監視機器リストに基づいてキャッシュテーブルを更新する（Ｓ１０３）。ここでキャッシュテーブルとは、監視サービス２１２が監視機器のサプライのステータス等を管理するためのテーブルであり、例えば、クライアントＰＣ２０のメモリ上に構築される。
【００５８】
図１１は、キャッシュテーブルの構成例を示す図である。図１１に示されるように、キャッシュテーブル２７は、監視機器ごとにＭＡＣアドレス、ベンダ名、機種名、シリアル番号、備考、監視情報、サプライステータス、及び通知フラグ等が登録及び保持されるテーブルである。ステップＳ１０３では、受信された監視機器リストに基づいて、ＭＡＣアドレス、ベンダ名、機種名、シリアル番号、及び備考が登録又は更新される。例えば、受信された監視機器リストに含まれている監視機器と同一のＭＡＣアドレスに係るエントリがキャッシュテーブル２７に存在しない場合、監視サービス２１２は、当該監視機器に係るエントリをキャッシュテーブル２７に新たに追加する。また、同一のＭＡＣアドレスに係るエントリは存在するが、他の情報（ベンダ名、機種名、シリアル番号又は備考）が異なる場合、当該エントリについて当該異なる情報を更新する。また、監視機器リストに含まれていないＭＡＣアドレスを有するエントリがキャッシュテーブル２７に存在する場合、監視サービス２１２は、当該エントリを削除する。すなわち、キャッシュテーブル２７は、現時点において監視機器とされている機器についてのみエントリを保持する。なお、キャッシュテーブル２７において、監視情報、サプライステータス、及び通知フラグについては、後述の処理によって更新される項目であり、その内容についてはその都度説明する。
【００５９】
続いて、監視サービス２１２は、キャッシュテーブル２７にエントリされている機器３０（監視機器）に対して機器情報としてのＭＩＢ情報をＳＮＭＰに基づいて問い合わせる（Ｓ１０４）。問い合わせ対象となるＭＩＢ情報としては、少なくともトナーのステータス情報が含まれ、また、他のサプライのステータス情報が含まれていてもよい。各機器３０は、問い合わせ対象とされたＭＩＢ情報を監視サービス２１２に対して返信する（Ｓ１０５）。
【００６０】
なお、本発明の実施にあたり、機器情報は必ずしもＭＩＢ情報に限定されず、機器情報を問い合わせるためのプロトコルはＳＮＭＰに限定されないが、標準化された技術を用いることにより、各機器３０のベンダが異なっていても、同じ手順によって機器情報の取得が可能であるという観点より、ＭＩＢやＳＮＭＰ等の標準技術に基づくのが好適である。
【００６１】
全ての監視機器からの機器情報の取得（ポーリング）が完了すると、監視サービス２１２は、当該機器情報に基づいて、キャッシュテーブル２７の監視状態、サプライステータス、及び通知フラグを更新する（Ｓ１０６）。監視状態については、機器情報の取得に成功した機器に係るエントリについては「ＯＫ」を登録し、失敗した機器に係るエントリについては「ＮＧ」を登録する。また、サプライステータスについては、取得された機器情報に含まれているトナーステータス等、サプライの状態情報が登録される。通知フラグには、サプライステータスの値が変化した場合、「未通知」が登録される。すなわち、監視サービス２１２は、更新前のキャッシュテーブル２７に登録されているサプライステータスと、新たに取得された機器情報に含まれているサプライのステータス情報とを比較することによりサプライの状態の変化を検知し、状態の変化が検知されたサプライについて、キャッシュテーブル２７におけるエントリの通知フラグを「未通知」とする。なお、通知フラグは、サプライの状態変化が発注支援プログラム１１に通知済みか否かを判別するために用いられる。
【００６２】
図１２は、機器情報のポーリング結果に基づくキャッシュテーブルの更新例を示す図である。図１２は、図１１の状態からの更新例を示す。すなわち、一行目のエントリに関しては、サプライステータスが「ｎｏｒｍａｌ」（不足していない状態）から「ｎｅａｒ ｅｎｄ」（ニアエンド）に変化している。したがって、通知フラグの値は「未通知」に更新されている。同様に、四行目のエントリに関してもサプライステータスが「ｎｅａｒ ｅｎｄ」から「ｅｎｄ」（エンド）に変化しているため、通知フラグの値は「未通知」に更新されている。一方、三行目及び五行目のエントリは、サプライステータスは変化していないため、通知フラグの値も更新されていない。また、二行目のエントリは、監視状態が「ＮＧ」とされている。当該エントリに係る機器３０からの機器情報の取得に失敗したためである。この場合、サプライステータス及び通知フラグの値は更新されない。
【００６３】
続いて、監視サービス２１２は、更新されたキャッシュテーブル２７に基づいて、状態変化通知情報を生成する（Ｓ１０７）。監視サービス２１２は、キャッシュテーブル２７において通知フラグの値が「未通知」のエントリに係る機器に関して状態変化通知情報を生成する。したがって、図１２のキャッシュテーブル２７に基づけば、一行目、三行目及び四行目のエントリに係る機器に関して状態変化通知情報が生成される。
【００６４】
図１３は、状態変化通知情報の構成例を示す図である。図１３において、状態変化通知情報は、ヘッダ情報と機器情報とから構成される。
【００６５】
ヘッダ情報は、日時、ユーザＩＤ、及びパスワード等を含む。日時は、機器情報を転送する日時である。ユーザＩＤ及びパスワードは、監視プログラム２１のインストール時に入力され、保存されているユーザＩＤ及びパスワードである。すなわち、ヘッダ情報は、機器３０より取得された情報ではない。
【００６６】
機器情報は、上記における機器情報と同義である。すなわち、機器３０よりＭＩＢ情報として取得された情報であり、当該機器３０のベンダ名、機種名（モデル名）、シリアル番号、ＭＡＣアドレス、ＩＰアドレス、トナーＩＤ（トナーボトルを特定するための情報、カラーであれば、トナーＩＤは各色ごとに付与され、モノクロであれば１個付与される）、トナー名称、トナーステータス、トナーレベル、トナー名（文字列）、トナー名（Ｃｏｄｅ）、及びトータルカウンタ値等を含む。これらは、ｐｕｂｌｉｃ ＭＩＢ（標準ＭＩＢ）として定義されているものであり、ベンダを問わずいずれの機器からも取得可能な情報である。
【００６７】
トナーステータスは、トナーの状態を示す情報である。また、トータルカウンタ値は、総印刷枚数を示す情報である。したがって、監視サービス２１２は、トナーステータスによってトナーエンドを検知する。また、トータルカウント値によって、感光体、定着ユニット、及び現像剤等の消耗度を判定する。但し、標準ＭＩＢにおけるトナーステータスでは、エンドとなったトナーの色までは特定することはできない。
【００６８】
そこで、本実施の形態における機器情報は、更に、モノクロカウンタ値、カラーカウンタ値、シアンカウンタ値、マゼンタカウンタ値、ブラックカウンタ値、及びレッドカウンタ値等をも含む。これらは、ｐｒｉｖａｔｅ ＭＩＢ（拡張ＭＩＢ）としてベンダ独自に定義されているものである。
【００６９】
例えば、本実施の形態では、メーカーＡの機器３０のみがこれらの拡張ＭＩＢに対応しているとすれば、メーカーＡの機器３０についての機器情報にはこれらの値が格納されるが、メーカーＡ以外の機器３０についての機器情報ではこれらの値は空となる。
【００７０】
例えば、モノクロカウンタ値は、モノクロ印刷による印刷枚数である。カラーカウンタ値は、カラー印刷による印刷枚数である。また、シアンカウンタ値、マゼンタカウンタ値、ブラックカウンタ値、及びレッドカウンタ値は、それぞれの色のトナーを使用した印刷枚数である。したがって、メーカーＡの機器３０であれば、色ごとにそのエンドを検知することが可能となる。
【００７１】
なお、図１２等に示されるキャッシュテーブル２７では、便宜上監視機器ごとに一つのエントリが割り当てられているが、複数のサプライの状態について（例えば、ＣＭＹＫそれぞれのトナーステータスやトータルカウンタ値等について）管理する場合は、当該サプライごとにエントリを割り当てればよい。また、状態変化通知情報に含める情報は、図１３に示され得ものに限定されず、必要に応じて、適宜決定すればよい。
【００７２】
続いて、監視サービス２１２は、生成された状態変化通知情報を発注支援プログラム１１に送信する（Ｓ１０８）。なお、状態変化通知情報は、各機器のものが同時に（一つのメッセージにまとめられて）送信されるのが通信負荷の低減の観点より好ましい。機器ごとに別個のメッセージとして送信される場合に比べ、オーバーヘッドを低下させることができるからである。
【００７３】
状態変化通知情報を受信した発注支援プログラム１１は、状態変化通知情報に基づく機器情報テーブルの更新や、サプライが不足している機器の判定等の処理を行う（Ｓ１０９）。なお、当該ステップにおける処理の詳細については後述する。
【００７４】
続いて、発注支援プログラム１１は、不足しているサプライの発注用のＷｅｂページ（以下「発注ページ」という。）を生成し、当該サプライが不足していることを通知する電子メール（以下「不足通知メール」という。）を作成し、ユーザのメールアドレスに対して送信する（Ｓ１１０）。不足通知メールには、発注ページのＵＲＬが記載される。なお、各不足通知メールには、ＩＤが付与され（以下「メールＩＤ」という。）、メールＩＤと共に、当該不足通知メールの対象とされた機器３０のシリアル番号等の機器３０を識別するための情報と、ユーザＩＤ又はメールアドレス等ユーザを識別するための情報と、送信日時等とが不足通知メールの送信履歴として保存される。
【００７５】
図１４は、不足通知メールの例を示す図である。図１４に示される不足通知メール２５０において、＜＞で囲まれた文字列は具体的な値ではなく、当該個所に記述される情報の内容を示す。
【００７６】
図１４に示されるように、不足通知メール２５０の宛先には、状態変化通知情報に係るユーザのメールアドレスが指定される。当該該ユーザのメールアドレスの特定は、状態変化通知情報に含まれているユーザＩＤ及びパスワードをキーとして、ユーザデータベースより検索すればよい。ユーザデータベースには、ユーザ登録時において、ユーザＩＤ及びパスワードと共にメールアドレスが登録されているからである。
【００７７】
不足通知メール２５０のタイトルには、当該メールが不足通知メールであることを示すタイトルが記載される。不足通知メール２５０の本文には、状態変化通知情報に係る機器に関する情報、不足しているサプライに関する情報、発注ページのＵＲＬ等が記載される。
【００７８】
機器に関する情報は、当該機器のベンダ名、モデル名、及び備考等が含まれる。これらの情報は、状態変化通知情報に含まれているシリアル番号、ＭＡＣアドレス又はＩＰアドレス等をキーとして、機器データベースより取得すればよい。また、不足しているサプライに関する情報は、例えば、当該サプライがトナーである場合は、状態変化通知情報に含まれているトナーステータス、トナーＩＤ、トナー名称等が記載される。なお、一つの機器３０において複数のサプライが同時に不足した場合は、一つの不足通知メール２５０内に当該複数のサプライの不足を示す情報を含むメールを作成し、当該複数のサプライの不足が通知される。
【００７９】
不足通知メール２５０の送信後、発注支援プログラム１１は、状態変化通知情報の受信（Ｓ１０８）に応じた一連の処理（不足通知メール２５０の送信等）の処理結果を監視サービス２１２に返信する（Ｓ１１１）。監視サービス２１２は、当該処理結果が、処理の正常終了を示している場合（すなわち、状態変化通知情報が正常に処理された場合）は、キャッシュテーブル２７の通知フラグについて、「未通知」を「通知済み」に更新する（Ｓ１１２）。
【００８０】
図１５は、状態変化通知情報が正常に処理された際のキャッシュテーブルの更新例を示す図である。図１５は、図１２からの更新例を示す。図１５のキャッシュテーブル２７では、一行目、三行目及び四行目のエントリの通知フラグが、「未通知」から「通知済み」に更新されている。通知フラグの値がこのように更新されることにより、正常に処理されたサプライの状態変化について、二重に状態変化通知情報が送信されるのを抑止することができる。したがって、通信量を削減することができ、ひいては不足通知メール２５０の二重送信を抑止することもできる。
【００８１】
クライアントＰＣ２０におけるメーラ２３によって不足通知メール２５０を閲覧したユーザは、印刷等を実行していないときでも、サプライの不足を認識することができる。また、備考として機器３０の配置場所等を入力しておけば、当該情報によって機器３０の配置場所の特定等を容易に行うことができる。
【００８２】
ユーザが、不足通知メール２５０に記載されている発注ページのＵＲＬをクリックすると、メーラ２３は、クリックされたＵＲＬを引数としてＷｅｂブラウザ２２を起動させる。Ｗｅｂブラウザ２２は、起動すると、引数に指定されたＵＲＬに基づいて発注ページを要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（Ｓ１１３）。発注支援プログラム１１は、受信されたＨＴＴＰリクエストに応じ、発注ページをＷｅｂブラウザ２２に返信する（Ｓ１１４）。Ｗｅｂブラウザ２２は、受信した発注ページを表示させる。
【００８３】
図１６は、発注ページの表示例を示す図である。図１６において、発注ページ２６０には、領域２６１においてサプライが不足している機器に関する情報（メーカー（ベンダ）名、モデル名、シリアル番号、備考（配置位置）が表示されている。また、領域２６２において、不足しているサプライの名称が表示されている。また、領域２６２では、当該機器に対応した各種サプライの一覧が表示され、それぞれの発注が可能となっている。すなわち、サプライごとに、その商品名（名称）が表示され、購入する数量の入力が可能とされている。なお、参照番号２６２１に示されるように、不足しているサプライについては予め必要な数量が入力されて表示されている。また、各商品名には、当該商品の概要説明を表示するＷｅｂページへのリンクが張られている。更に、領域２６３では、当該ユーザの過去の購入履歴が表示される。これによって、ユーザが重複して購入してしまうことを防止することができる。
【００８４】
なお、購入履歴は、ユーザデータベースにユーザごとに登録されている。すなわち、発注ページ２６０を介して商品の発注が行われると、発注された商品の情報がユーザデータベースに追加登録される。
【００８５】
ところで、図１６の発注ページ２６０では、イエローのトナーが不足している旨が通知されている。上述したように、標準ＭＩＢだけでは、不足しているトナーの色は特定できない。したがって、図１６の発注ページ２６０には、拡張ＭＩＢに登録されている情報に基づいて判定された結果が示されている。このように、発注支援システム１を展開するメーカーは、自らが定義した拡張ＭＩＢによって、発注支援システム１上のサービスにおいて、他社と差別化を図ることができる。すなわち、仮に、他社の機器３０のトナーエンドが検知された場合は、発注ページ２６０にはその色までは特定されて通知されない。なお、他社の機器３０のサプライについては、そもそも発注支援システム１による発注対象から除外するということも考えられるが、ユーザの利便性を考慮し、本実施の形態では、他社の機器３０のサプライの発注も可能としている。
【００８６】
発注ページ２６０において、ユーザが注文ボタン２６２２をクリックすると、Ｗｅｂブラウザ２２は、商品の発注を要求するＨＴＴＰリクエストを発注支援サーバ１０に送信する（Ｓ１１５）。
【００８７】
ＨＴＴＰリクエストに応じ、発注支援プログラム１１は、当該ユーザと関連付いている販売業者に対して当該発注要求に基づく利益の一部を供与するための情報を記録する（Ｓ１１６）。具体的には、発注業者ごとに、発注支援システム１によるサプライの売り上げを管理するデータベース（以下「販売業者データベース」という。）が構築されており、当該販売業者データベースの売り上げに、今回の発注による注文の内容（例えば、注文金額）が記録される。なお、販売業者は、メーカーとの間で発注支援システム１への参加契約を締結することにより、販売業者データベースへのエントリが作成される。また、販売業者ＩＤが与えられ、当該販売業者は、発注支援システム１上において、当該販売業者ＩＤによって識別される。なお、ステップＳ１１６において、受信されるＨＴＴＰリクエストに係るユーザの識別は、例えば、Ｗｅｂブラウザ２２とのセッションＩＤとユーザＩＤとを関連付けておき、その関連付けに基づいて、セッションＩＤよりユーザＩＤを特定することにより行えばよい。
【００８８】
発注支援プログラム１１は、更に、当該発注の指示を物品発注管理システムに指示する。この指示には、ユーザデータベースに登録されている配送先の情報が含まれている。物品発注支援システムに発注が指示されることにより、発注された商品は、実際にユーザの元に配送される。更に、ユーザから購入代金支払われると、販売業者データベースに、今回の発注による売り上げが確定したことが記録される。売り上げか確定することにより、当該販売業者には、売り上げに応じて販売促進金などの手当をメーカーから供与してもよい。
【００８９】
続いて、図１０におけるステップＳ１０９の処理の詳細について説明する。図１７は、発注支援プログラムによる状態変化通知情報に基づく処理を説明するためのフローチャートである。
【００９０】
状態変化通知情報を受信すると、発注支援プログラム１１は、状態変化通知情報と共に監視サービス２１２より送信されるユーザＩＤ及びパスワードに基づいてユーザの認証を行う（Ｓ４０１）。ユーザが認証された場合（Ｓ４０１でＹｅｓ）、状態変化通知情報が受信された機器ごとにステップＳ４０２以降の処理を行う。
【００９１】
まず、一つの機器を処理対象とし（以下、処理対象とされた機器を「カレント機器」という。）（Ｓ４０３）、カレント機器は機器情報テーブル１２に登録されているか否かを判定する（Ｓ４０４）。この判定は、カレント機器のＭＡＣアドレスをキーとして、機器情報テーブル１２に当該ＭＡＣアドレスを有するエントリが有るか否かによって行えばよい。カレント機器が未登録である場合（Ｓ４０４でＮｏ）、カレント機器のエントリを機器情報テーブル１２に登録する（Ｓ４０５）。この際、カレント機器は監視対象とする。なお、ＭＡＣアドレスに基づいてカレント機器が登録されていると判断された場合、図８のＳ３３６〜Ｓ３３８において説明したような処理を行ってもよい。
【００９２】
続いて、状態変化通知情報に含まれているカレント機器のサプライのステータス情報を機器情報テーブル１２のステータスに反映（転記）する（Ｓ４０６）。続いて、機器情報テーブル１２に登録されているカレント機器のステータスに基づいて、カレント機器について不足していているサプライ（すなわち、ステータスが「Ｎｅ」（ニアエンド）又は「Ｅ」（エンド）のサプライ）の有無を判定する（Ｓ４０７）。不足しているサプライが存在する場合（Ｓ４０７でＹｅｓ）、機器情報テーブル１２においてカレント機器に係るエントリ（以下「カレントエントリ」という。）のメールフラグの値は「Ｙｅｓ」であるか否かを判定する（Ｓ４０８）。ここで、メールフラグは、不足通知メール２５０が送信された場合に「Ｙｅｓ」とされるフラグである。すなわち、メールフラグの値が「Ｙｅｓ」であるということは、過去にカレント機器について不足通知メール２５０が送信されたことがあることを意味する。
【００９３】
メールフラグが「Ｙｅｓ」の場合（Ｓ４０８でＹｅｓ）、不足通知メール２５０の重複送信チェックを行う（Ｓ４０９）。ここで、重複送信チェックとは、同じ内容の不足通知メール２５０が送信された可能性の有無を判定するための処理であり、その処理内容の詳細については後述する。重複送信チェックにおいて、重複送信の可能性は低く不足通知メール２５０は送信すると判定された場合（Ｓ４０９で「送信する」）、メールフラグを「Ｙｅｓ」とし（Ｓ４１０）、カレント機器に関する不足通知メール２５０を送信する（Ｓ４１１）。この処理は、図１０におけるステップＳ１１０に相当する。なお、ステップＳ４０７において、不足しているサプライが複数検知された場合は、当該複数のサプライについてまとめて一つの不足通知メール２５０が送信される。したがって、ユーザに送信される不足通知メール２５０の数を少なくすることができ、ユーザに与える煩雑さ等を低減させることができる。
【００９４】
また、重複送信チェックにおいて、重複送信の可能性が高く不足通知メール２５０は送信しないと判定された場合は（Ｓ４０９で「送信しない」）、不足通知メールは送信せずにカレント機器に関する処理を終了する。
【００９５】
一方、メールフラグが「Ｎｏ」の場合（Ｓ４０８でＹｅｓ）、不足通知メール２５０の重複のおそれはないため、重複送信チェックは行わず、メールフラグを「Ｙｅｓ」とし（Ｓ４１０）、不足通知メールを送信する（Ｓ４１１）。
【００９６】
また、Ｓ４０７において、カレント機器についていずれのサプライも不足していないと判定された場合、この場合は不足通知メールは送信する必要はないため、メールフラグを「Ｎｏ」とし、不足通知メールは送信せずにカレント機器に関する処理を終了する。
【００９７】
ステップＳ４０３〜Ｓ４１２までの処理が状態変化通知情報の受信された全ての機器について完了すると（Ｓ４０２でＹｅｓ）、状態変化通知情報が正常に処理されたことを監視サービス２１２に返信し（Ｓ４１４）、処理を終了する。この処理は、図１０におけるステップＳ１１１に相当する。なお、ユーザ認証に失敗した場合は（Ｓ４０１でＮｏ）、機器情報テーブル１２の更新は行わず、エラー情報を監視サービス２１２に返信する（Ｓ４１３）。
【００９８】
続いて、図１７におけるステップＳ４０９の不足通知メールの重複送信チェックの詳細について説明する。図１８は、不足通知メールの重複送信チェック処理を説明するための図である。当該処理の意義について説明する。
【００９９】
監視サービス２１２は、キャッシュテーブル２７の通知フラグに基づいて状態変化通知情報を送信するため、監視サービス２１２は、基本的には二重に同一の状態変化通知情報を送信することはない。しかしながら、例えば、トナーについては、トナーボトルの中にまだトナーが残っている場合にトナーエンドが検知される場合がある。このような場合、ユーザがトナーボトルを振った後に当該トナーボトルを取り付けると、しばらくしてから改めて同一のトナーについてトナーエンドが検知されてしまうことが考えられる。このような場合、通知フラグは、「ｅｎｄ」から「ｎｏｒｍａｌ」に変化し、再び「ｅｎｄ」に変化するため、同一のトナーボトルが交換されていないにもかかわらず、監視サービス２１２は、再度トナーエンドを通知するための状態変化通知情報を送信してしまうことが考えられる。そうすると、ユーザに対して不足通知が重複して送信されてしまい、ユーザが重複に気付かなければ、重複した発注を行ってしまうということが考えられる。そこで、かかる事態の発生を回避するため、発注支援プログラム１１は、以下の処理を行う。
【０１００】
まず、監視サービス２１２より受信した状態変化通知情報に含まれている、機器３０のシリアル番号に基づいて、不足通知メールの送信履歴より当該機器３０に関して最後（前回）に送信した不足通知メールの日時をチェックする（Ｓ２０１）。
【０１０１】
送信履歴の中に、当該機器３０に対する不足通知メールの送信記録が含まれていない場合（Ｓ２０２でＹｅｓ）、不足通知メールを送信すると判定する（Ｓ２０３）。当該機器３０に関しては、今までに不足通知メールを送信したことはなく、したがって、不足通知メールが重複するおそれはないからである。
【０１０２】
送信履歴の中に、当該機器３０に対する不足通知メールの送信記録が含まれている場合（Ｓ２０２でＮｏ）、最後に送信した不足通知メールの送信日時から所定期間が経過している否かを判定する（Ｓ２０４）。所定期間が経過していれば不足通知メールは送信すると判定し（Ｓ２０３）、経過していなければ重複のおそれがあるとして不足通知メールは送信しないと判定する（Ｓ２０５）。
【０１０３】
なお、図１８では、時間の経過に基づいて判定する例を示したが、例えば、送信履歴としてトータルカウンタを記録しておき、トータルカウンタの差分が所定の閾値以下の場合であれば、不足通知メールを送信しないようにしてもよい。また、送信履歴を一定時間ごとに全て削除するようにし、送信履歴の中に同一の機器３０に対する不足通知メールの送信記録が含まれている場合は、不足通知メールを送信しないようにしてもよい。
【０１０４】
次に、監視プログラム２１におけるＵＩアプリ２１１の機能について説明する。ＵＩアプリ２１１は、監視サービス２１２に対する設定情報（例えば、機器情報を取得する周期）を設定させるための画面（以下「設定画面」という。）や、監視サービス２１２による機器の監視情報を表示させるための画面（以下「監視画面」という。）等を表示させるプログラムである。
【０１０５】
ＵＩアプリ２１１は、ユーザからの指示に応じ、例えば次のような設定画面を表示させる。図１９は、設定画面の表示例を示す図である。図１９の設定画面２２０では、監視サービス２１２が監視機器より機器情報をポーリングする周期（参照番号２２１）と、ネットワーク５０上の機器を自動検索する周期（参照番号２２２）との設定を行うことができる。前者は、図１０のステップＳ１０４を実行する周期である。後者は、図３のステップＳ３１を実行する周期である。なお、後者については、チェックボックス２２３において、設定値を無効とすることもできる。すなわち、チェックボックス２２３のチェックがはずされると、機器３０の自動検索は行われない。
【０１０６】
また、ＵＩアプリ２１１は、ユーザからの指示に応じ、例えば次のような監視画面を表示させる。図２０は、監視画面の表示例を示す図である。図２０の監視画面２３０は、ＵＩアプリ２１１が、キャッシュテーブル２７より取得した情報を表示させる画面である。したがって、キャッシュテーブル２７において管理されている情報、すなわち、監視機器ごとに、ベンダ名、機種名、シリアル番号、サプライステータス、及び備考等を表示させる。監視画面２３０によって、ユーザは任意のタイミングで各監視機器のサプライの状態等を確認することができる。なお、参照番号２３１で示される「？」マークは、当該マークが付されている機器については機器情報のポーリングに失敗したことを示す。例えば、当該機器が起動されていないような場合や、ネットワーク５０から切断された場合等にかかる状態が発生し得る。
【０１０７】
上述したように、本発明の実施の形態における発注支援システム１によれば、機器３０のユーザ（顧客）、販売業者、及びメーカーの三者のそれぞれに対して、利便性又は有益性を提供することができる。
【０１０８】
すなわち、機器３０のサプライの不足が自動的に検知され、不足通知メールがユーザの端末に自動的に送信される。その結果、ユーザは、不足通知メールに記載されているＵＲＬをクリックすることで発注ページ２６０を表示させることができ、発注ページ２６０によって不足しているサプライを簡便に発注することができる。したがって、ユーザ自らが機器３０に対応したサプライを特定したり、量販店に買い出しに行ったりするための手間を省くことができ、サプライの調達コストを低減させることができる。
【０１０９】
また、販売業者については、サプライによる収益の一部を獲得することができ、その収益源を拡大することができる。
【０１１０】
また、メーカーについては、販売業者に当該メーカーの機器を他社の機器より優先させて販売したいというインセンティブや、ユーザに当該メーカーの機器を購入したいというインセンティブを与えることができる。すなわち、発注支援システム１を介して販売されたサプライが当該メーカー製のものである場合は他社のサプライが販売された場合よりも還元率を高くしたり、又は、他社のサプライの場合は還元率を０としたりすれば、販売業者にとっては、当該メーカーの製品を販売した方が、サプライの販売による利益を多く享受できるからである。また、ユーザにとっては、当該メーカーの機器を購入すれば、例えば、不足したトナーの色の特定まで可能であるといった、きめ細かいサービスを受けられるという期待を与えることができるからである。
【０１１１】
更に、メーカーは、ユーザの機器情報を蓄積することによって、各機器３０の使用期間等をある程度推測することができる。その結果、買い換えの促進等、新たな販売活動への連携を効果的に行うことができる。
【０１１２】
なお、上記実施の形態では、ユーザとの間で発注支援システム１の登録契約を締結するのは機器を販売する業者である場合を例として説明したが、必ずしも、ユーザと当該登録契約を締結する相手側は、機器を販売した者に限定されない。機器は販売していない業者であっても、メーカーから発注支援システム１における販売業者ＩＤが与えられるようにしてもよい。この場合、当該業者は、機器の販売とは関係なく、発注支援システム１を介したサプライの販売による利益の還元を受けることができる。
【０１１３】
以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【０１１４】
【図１】本発明の実施の形態における発注支援システムの構成例を示す図である。
【図２】監視サービスがクライアントＰＣに実行させる機能の概要を説明するためのフローチャートである。
【図３】発注支援システムにおけるユーザ登録時の処理手順を説明するためのシーケンス図である。
【図４】ユーザ登録ページの表示例を示す図である。
【図５】機器データベースを構成する機器情報テーブルの構成例を示す図である。
【図６】検索機器一覧ページの表示例を示す図である。
【図７】監視の要否及び備考が登録された機器情報テーブルの例を示す図である。
【図８】発注支援プログラムによる機器情報テーブルの更新処理を説明するためのフローチャートである。
【図９】機種名が一致しないエントリが存在した場合の機器情報テーブルの更新例を示す図である。
【図１０】発注支援システムにおける機器監視時の処理手順を説明するためのシーケンス図である。
【図１１】キャッシュテーブルの構成例を示す図である。
【図１２】機器情報のポーリング結果に基づくキャッシュテーブルの更新例を示す図である。
【図１３】状態変化通知情報の構成例を示す図である。
【図１４】不足通知メールの例を示す図である。
【図１５】状態変化通知情報が正常に処理された際のキャッシュテーブルの更新例を示す図である。
【図１６】発注ページの表示例を示す図である。
【図１７】発注支援プログラムによる状態変化通知情報に基づく処理を説明するためのフローチャートである。
【図１８】不足通知メールの重複送信チェック処理を説明するための図である。
【図１９】設定画面の表示例を示す図である。
【図２０】監視画面の表示例を示す図である。
【符号の説明】
【０１１５】
１ 発注支援システム
１０ 発注支援サーバ
１１ 発注支援プログラム
１２ 機器情報テーブル
２０ クライアントＰＣ
２１ 監視プログラム
３０、３０ａ、３０ｂ、３０ｃ、３０ｄ 機器
４０、５０ ネットワーク
２１１ ＵＩアプリ
２１２ 監視サービス
５０１、５０２ 記録媒体
【特許請求の範囲】
【請求項１】
ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、
前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することを特徴とする発注支援システム。
【請求項２】
前記電子メールには、受信された前記状態情報に係る消耗品の発注用のＷｅｂページを示すＵＲＬが記載されていることを特徴とする請求項１記載の発注支援システム。
【請求項３】
前記状態情報保持手段は、前記機器又は前記消耗品ごとに前記消耗品の前記状態情報と、第一又は第二の値をとり得るフラグ情報とを保持し、
前記状態変化検知手段は、前記状態の変化が検知された前記消耗品に係る前記フラグ情報を前記第一の値とし、
前記状態情報送信手段は、前記フラグ情報が前記第一の値である前記消耗品に係る前記状態情報を送信することを特徴とする請求項１又は２記載の発注支援システム。
【請求項４】
前記機器監視装置は、前記状態情報を送信した前記消耗品に係る前記フラグ情報を前記第二の値とすることを特徴とする請求項３記載の発注支援システム。
【請求項５】
前記状態情報取得手段は、前記状態情報の取得のたびに前記状態情報の取得対象とする機器を前記発注支援装置に問い合わせ、前記発注支援装置からの応答において指定された機器より前記状態情報を取得することを特徴とする請求項１乃至４いずれか一項記載の発注支援システム。
【請求項６】
前記機器監視装置は、前記ネットワークに接続されている機器を検索する機器検索手段と、検索された機器の一覧情報を前記発注支援装置に送信する検索機器情報送信手段とを有し、
前記発注支援装置は、前記一覧情報を保持する機器一覧保持手段と、前記機器一覧保持手段に保持されている前記一覧情報に含まれる機器の中から前記状態情報の取得対象とする機器を選択する対象機器選択手段とを有することを特徴とする請求項５記載の発注支援システム。
【請求項７】
前記検索手段は、前記ネットワークに接続されている機器を繰り返し検索し、検索された機器の一覧情報を前記発注支援装置に送信し、
前記対象機器選択手段は、前記機器一覧保持手段に既に保持されている第一の前記機器一覧情報と、新たに受信された第二の前記一覧情報とを比較し、前記第二の一覧情報に含まれている機器の中で前記第一覧情報に含まれていない機器を前記状態情報の取得対象として選択することを特徴とする請求項６記載の発注支援システム。
【請求項８】
請求項１乃至７いずれか一項記載の発注支援システムにおける発注支援装置。
【請求項９】
請求項１乃至７いずれか一項記載の発注支援システムにおける機器監視装置。
【請求項１０】
第一のコンピュータが、ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手順と、取得された前記消耗品の状態情報を保持する状態情報保持手順と、前記状態情報保持手順において既に保持されている前記状態情報と前記状態情報取得手順において新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手順と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する第二のコンピュータに送信する状態情報送信手順と実行し、
前記第二のコンピュータが、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信することを特徴とする発注支援方法。
【請求項１１】
前記電子メールには、受信された前記状態情報に係る消耗品の発注用のＷｅｂページを示すＵＲＬが記載されていることを特徴とする請求項１０記載の発注支援方法。
【請求項１２】
前記状態情報保持手順は、前記機器又は前記消耗品ごとに前記消耗品の前記状態情報と、第一又は第二の値をとり得るフラグ情報とを保持し、
前記状態変化検知手順は、前記状態の変化が検知された前記消耗品に係る前記フラグ情報を前記第一の値とし、
前記状態情報送信手順は、前記フラグ情報が前記第一の値である前記消耗品に係る前記状態情報を送信することを特徴とする請求項１又は２記載の発注支援方法。
【請求項１３】
前記第一のコンピュータは、前記状態情報を送信した前記消耗品に係る前記フラグ情報を前記第二の値とすることを特徴とする請求項１２記載の発注支援方法。
【請求項１４】
前記状態情報取得手順は、前記状態情報の取得のたびに前記状態情報の取得対象とする機器を前記第二のコンピュータに問い合わせ、前記第二のコンピュータからの応答において指定された機器より前記状態情報を取得することを特徴とする請求項１０乃至１３いずれか一項記載の発注支援方法。
【請求項１５】
前記第一のコンピュータは、前記ネットワークに接続されている機器を検索する機器検索手順と、検索された機器の一覧情報を前記第二のコンピュータに送信する検索機器情報送信手順とを実行し、
前記第二のコンピュータは、前記一覧情報を保持する機器一覧保持手順と、前記機器一覧保持手順に保持されている前記一覧情報に含まれる機器の中から前記状態情報の取得対象とする機器を選択する対象機器選択手順とを実行することを特徴とする請求項１４記載の発注支援方法。
【請求項１６】
前記検索手順は、前記ネットワークに接続されている機器を繰り返し検索し、検索された機器の一覧情報を前記第二のコンピュータに送信し、
前記対象機器選択手順は、前記機器一覧保持手順において既に保持されている第一の前記機器一覧情報と、新たに受信された第二の前記一覧情報とを比較し、前記第二の一覧情報に含まれている機器の中で前記第一覧情報に含まれていない機器を前記状態情報の取得対象として選択することを特徴とする請求項１５記載の発注支援方法。
【請求項１７】
請求項１０乃至１６いずれか一項記載の発注支援方法において、前記第二のコンピュータが実行する手順を有する発注支援方法。
【請求項１８】
請求項１０乃至１６いずれか一項記載の発注支援方法において、前記第一のコンピュータが実行する手順を有する機器監視方法。
【請求項１９】
請求項１７記載の発注支援方法をコンピュータに実行させるための発注支援プログラム。
【請求項２０】
請求項１８記載の機器監視方法をコンピュータに実行させるための機器監視プログラム。
【請求項１】
ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、
前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することを特徴とする発注支援システム。
【請求項２】
前記電子メールには、受信された前記状態情報に係る消耗品の発注用のＷｅｂページを示すＵＲＬが記載されていることを特徴とする請求項１記載の発注支援システム。
【請求項３】
前記状態情報保持手段は、前記機器又は前記消耗品ごとに前記消耗品の前記状態情報と、第一又は第二の値をとり得るフラグ情報とを保持し、
前記状態変化検知手段は、前記状態の変化が検知された前記消耗品に係る前記フラグ情報を前記第一の値とし、
前記状態情報送信手段は、前記フラグ情報が前記第一の値である前記消耗品に係る前記状態情報を送信することを特徴とする請求項１又は２記載の発注支援システム。
【請求項４】
前記機器監視装置は、前記状態情報を送信した前記消耗品に係る前記フラグ情報を前記第二の値とすることを特徴とする請求項３記載の発注支援システム。
【請求項５】
前記状態情報取得手段は、前記状態情報の取得のたびに前記状態情報の取得対象とする機器を前記発注支援装置に問い合わせ、前記発注支援装置からの応答において指定された機器より前記状態情報を取得することを特徴とする請求項１乃至４いずれか一項記載の発注支援システム。
【請求項６】
前記機器監視装置は、前記ネットワークに接続されている機器を検索する機器検索手段と、検索された機器の一覧情報を前記発注支援装置に送信する検索機器情報送信手段とを有し、
前記発注支援装置は、前記一覧情報を保持する機器一覧保持手段と、前記機器一覧保持手段に保持されている前記一覧情報に含まれる機器の中から前記状態情報の取得対象とする機器を選択する対象機器選択手段とを有することを特徴とする請求項５記載の発注支援システム。
【請求項７】
前記検索手段は、前記ネットワークに接続されている機器を繰り返し検索し、検索された機器の一覧情報を前記発注支援装置に送信し、
前記対象機器選択手段は、前記機器一覧保持手段に既に保持されている第一の前記機器一覧情報と、新たに受信された第二の前記一覧情報とを比較し、前記第二の一覧情報に含まれている機器の中で前記第一覧情報に含まれていない機器を前記状態情報の取得対象として選択することを特徴とする請求項６記載の発注支援システム。
【請求項８】
請求項１乃至７いずれか一項記載の発注支援システムにおける発注支援装置。
【請求項９】
請求項１乃至７いずれか一項記載の発注支援システムにおける機器監視装置。
【請求項１０】
第一のコンピュータが、ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手順と、取得された前記消耗品の状態情報を保持する状態情報保持手順と、前記状態情報保持手順において既に保持されている前記状態情報と前記状態情報取得手順において新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手順と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する第二のコンピュータに送信する状態情報送信手順と実行し、
前記第二のコンピュータが、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信することを特徴とする発注支援方法。
【請求項１１】
前記電子メールには、受信された前記状態情報に係る消耗品の発注用のＷｅｂページを示すＵＲＬが記載されていることを特徴とする請求項１０記載の発注支援方法。
【請求項１２】
前記状態情報保持手順は、前記機器又は前記消耗品ごとに前記消耗品の前記状態情報と、第一又は第二の値をとり得るフラグ情報とを保持し、
前記状態変化検知手順は、前記状態の変化が検知された前記消耗品に係る前記フラグ情報を前記第一の値とし、
前記状態情報送信手順は、前記フラグ情報が前記第一の値である前記消耗品に係る前記状態情報を送信することを特徴とする請求項１又は２記載の発注支援方法。
【請求項１３】
前記第一のコンピュータは、前記状態情報を送信した前記消耗品に係る前記フラグ情報を前記第二の値とすることを特徴とする請求項１２記載の発注支援方法。
【請求項１４】
前記状態情報取得手順は、前記状態情報の取得のたびに前記状態情報の取得対象とする機器を前記第二のコンピュータに問い合わせ、前記第二のコンピュータからの応答において指定された機器より前記状態情報を取得することを特徴とする請求項１０乃至１３いずれか一項記載の発注支援方法。
【請求項１５】
前記第一のコンピュータは、前記ネットワークに接続されている機器を検索する機器検索手順と、検索された機器の一覧情報を前記第二のコンピュータに送信する検索機器情報送信手順とを実行し、
前記第二のコンピュータは、前記一覧情報を保持する機器一覧保持手順と、前記機器一覧保持手順に保持されている前記一覧情報に含まれる機器の中から前記状態情報の取得対象とする機器を選択する対象機器選択手順とを実行することを特徴とする請求項１４記載の発注支援方法。
【請求項１６】
前記検索手順は、前記ネットワークに接続されている機器を繰り返し検索し、検索された機器の一覧情報を前記第二のコンピュータに送信し、
前記対象機器選択手順は、前記機器一覧保持手順において既に保持されている第一の前記機器一覧情報と、新たに受信された第二の前記一覧情報とを比較し、前記第二の一覧情報に含まれている機器の中で前記第一覧情報に含まれていない機器を前記状態情報の取得対象として選択することを特徴とする請求項１５記載の発注支援方法。
【請求項１７】
請求項１０乃至１６いずれか一項記載の発注支援方法において、前記第二のコンピュータが実行する手順を有する発注支援方法。
【請求項１８】
請求項１０乃至１６いずれか一項記載の発注支援方法において、前記第一のコンピュータが実行する手順を有する機器監視方法。
【請求項１９】
請求項１７記載の発注支援方法をコンピュータに実行させるための発注支援プログラム。
【請求項２０】
請求項１８記載の機器監視方法をコンピュータに実行させるための機器監視プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２００８−９９６１（Ｐ２００８−９９６１Ａ）
【公開日】平成２０年１月１７日（２００８．１．１７）
【国際特許分類】
【出願番号】特願２００７−９３６３８（Ｐ２００７−９３６３８）
【出願日】平成１９年３月３０日（２００７．３．３０）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２０年１月１７日（２００８．１．１７）
【国際特許分類】
【出願日】平成１９年３月３０日（２００７．３．３０）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]