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