発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラム
【課題】機器の消耗品の補給作業を簡便化させることのできる発注支援システムの提供を目的とする。
【解決手段】ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することにより上記課題を解決する。
【解決手段】ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することにより上記課題を解決する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムに関し、特に機器の消耗品の発注を支援する発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムに関する。
【背景技術】
【0002】
企業におけるオフィスには、プリンタ、コピー機、ファクシミリ、又はこれらの機能を一台の筐体において実現する複合機等といった複数の機器がネットワークを介して接続されている。
【0003】
上記に挙げた機器は、いずれも装置の使用によって消耗される消耗品を備えており、当該消耗品が適切に交換されることによってその機能が維持される。例えば、プリンタであれば、トナー、定着ユニット、排トナーボトル、感光体、又は現像剤等が相当し、これらは一般的にサプライと呼ばれている。
【0004】
サプライの消耗度を機器の外部から識別するのは困難であるため、ユーザは印刷を指示してエラーが通知されたときにトナー切れを認識し、トナーの交換を行っていた。こうしたユーザによる作業を軽減するため、機器内部でサプライの寿命を検知し、そのサプライに関する情報を操作パネルへの表示や用紙への印字を行う技術や、機器自身がサプライ交換の必要性を表す信号を外部に通知し、その機器が設置されているオフィスに保守作業要員を派遣するという技術が提案されている。
【特許文献1】特開平10−198236号公報
【特許文献2】特開2003−245560号公報
【発明の開示】
【発明が解決しようとする課題】
【0005】
しかしながら、サプライの寿命を検知したとしても、その後のサプライ発注やサプライ交換をユーザ自身が行う場合、交換対象のサプライの型番を正確に確認した上で発注手続きを行われなければならない。そのためサプライ発注までにユーザは煩雑な作業を強いられていた。また、発注自体は先に行っておきたいときでも、発注先の営業日や営業時間等によっては発注可能時期が発注先の営業所の業務時間に依存するという問題もある。さらに、保守作業要員を派遣する発注システムの場合、その分人件費や配送費等のコストも増えるという問題があった。
【0006】
本発明は、上記の点に鑑みてなされたものであって、機器の消耗品の補給作業を簡便化させることのできる発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムの提供を目的とする。
【課題を解決するための手段】
【0007】
そこで上記課題を解決するため、本発明の発注支援システムは、ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することを特徴とする。
【0008】
このような発注支援システムでは、機器の消耗品の補給作業を簡便化させることができる。
【発明の効果】
【0009】
本発明によれば、機器の消耗品の補給作業を簡便化させることのできる発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムを提供することができる。
【発明を実施するための最良の形態】
【0010】
以下、図面に基づいて本発明の実施の形態を説明する。図1は、本発明の実施の形態における発注支援システムの構成例を示す図である。図1において、発注支援システム1は、発注支援サーバ10と、クライアントPC20と、機器30a、30b、30c、及び30d等(以下、総称する場合「機器30」という。)とを構成要素として含む。発注支援サーバ10は、発注サイト(機器30の消耗品の供給者側、例えば、機器30のメーカー)に設置されており、クライアントPC及び機器30はユーザサイト(機器30のユーザ側、例えば、オフィス等)に設置されている。発注支援サーバ10とクライアントPC20とは、インターネット等の広域ネットワークによって接続されている。また、クライアント20と機器30とは、ユーザサイトに施設されたLAN(Local Area Network)等のネットワーク(有線又は無線の別は問わない)を介して接続されている。
【0011】
機器30は、例えば、一般的なプリンタや複合機等、トナーやインク等を消耗して、画像を形成する機器(画像形成装置)である。本実施の形態において機器30は、MIB(Management Information Base)に対応しており、SNMP(Simple Network Management Protocol)に基づいてネットワークを介して受信されるMIB情報の取得要求に応答することが可能である。また、本実施の形態において機器30は、消耗品の状態情報を検知することができる。当該状態情報は、定性的(正常/ニアエンド/エンド)なものであってもよいし、定量的(100%、90%、.....10%、0%)なものであってもよい。
【0012】
クライアントPC20は、汎用的なコンピュータであり、監視プログラム21がインストールされる。監視プログラム21は、CD−ROM等の記録媒体502よりインストールされてもよいし、ネットワークを介してダウンロードされてもよい。後述するように、本実施の形態ではネットワーク40を介してダウンロードされる。
【0013】
図1において、監視プログラム21は、UIアプリ211及び監視サービス212より構成される。UIアプリ211は、監視サービス212とは別プロセスとして起動され、監視サービス212の機能に関してGUI(Graphical User Interface)を提供するアプリケーションである。UIアプリ211は、例えば、監視サービス212に対する設定情報を設定させるための画面や、監視サービス212によって取得される機器情報を表示させるための画面等を表示させる。
【0014】
監視サービス212は、デーモンプロセスとして起動されるプログラムであり、クライアントPC20のメモリにロードされCPUによって処理されることにより、クライアントPC20に以下の機能を実行させる。図2は、監視サービスがクライアントPCに実行させる機能の概要を説明するためのフローチャートである。
【0015】
クライアントPC20は、監視サービス212に基づいて、各機器30より機器情報(MIB情報)を定期的に取得する(S301)。機器情報には、機器30が使用する消耗品の状態を識別するための情報(状態情報)、例えば、トナーステータス及びトータルカウンタ値(総印刷枚数)等が含まれる。また、他の消耗品、具体的には、定着ユニット、排トナーボトル、感光体、又は現像剤等の状態を示す情報が含まれていてもよい。取得した結果、機器情報に含まれている消耗品の状態情報が定性的な情報(すなわち、正常/ニアエンド/エンド)である場合(S302で「定性情報」)、ニアエンド又はエンド情報(以下、「エンド」によって総称する)を取得すると(S303でYes)、当該消耗品の不足であると判定し(S304)、機器30の機器情報を発注支援サーバ10へ送信する(S305)。一方、機器情報を取得した結果、状態情報が定量的な情報(すなわち、100%、90%、.....10%、0%)である場合(S302で「定量情報」)、所定の閾値(30%以下)を下回っているかを調べ(S306)、下回っている場合(S306でYes)、当該消耗品の不足であると判定し(S304)、機器30の機器情報を発注支援サーバ10へ送信する(S305)。
【0016】
なお、本実施の形態では、監視装置20が消耗品の不足を検知する例について説明するが、当該検知を発注支援サーバ10に行わせてもよい。この場合、監視装置20は全ての機器30の機器情報を発注支援サーバ10に送信することになる。したがって、ネットワーク負荷の軽減という観点からは、本実施の形態のように、監視装置20において不足が検知された機器の機器情報のみを発注支援サーバ10に送信する方が好ましい。
【0017】
クライアントPC20には、また、電子メールの送受信を行うためのメーラや、Webページを閲覧するためのWebブラウザ等もインストールされている。
【0018】
発注支援サーバ10は、汎用的なコンピュータであり、Webサーバとしての機能が実装されていると共に、発注支援プログラム11がインストールされている。発注支援プログラム11は、CD−ROM等の記録媒体501よりインストールされてもよいし、ネットワークを介してダウンロードされてもよい。
【0019】
発注支援プログラム11は、発注支援サーバ10のメモリにロードされCPUによって処理されることにより、発注支援サーバ10に以下の機能を実行させる。すなわち、発注支援プログラム11に基づいて、発注支援サーバ10の電子メール作成手段は、クライアントPC20より受信される機器情報に基づいて不足している消耗品(以下「サプライ」という。)の補給を促進する電子メールを作成し、予め登録されているユーザのメールアドレスに送信する。当該電子メールには、不足していると判定されたサプライの発注用のWebページ(以下「サプライ発注ページ」という。)に対するURLが記載される。発注支援サーバ10は、また、当該URLのクリックに基づいて送信されるHTTPリクエストに応じて、サプライ発注ページを返信し、更に、サプライ発注ページに基づくサプライの発注要求を受信する。発注支援サーバ10は、サプライ発注要求に応じて、サプライの発注指示を非図示の物品発注管理システムに送信する。
【0020】
ところで、本発明者は、発注支援システム1を利用した新たなビジネスモデルの構築を検討している。まず、当該ビジネスモデルを構築するに至った背景について説明する。
【0021】
一般的に、画像形成装置の販売は、代理店や接点店等、様々な販売チャネルを介して行われる。以下、メーカーから製品(画像形成装置)を仕入れて顧客に対して直接販売を行う業者を「販売業者」という。当該販売業者には、ハードウェアとしての画像形成装置を単に販売するだけでなく、顧客に応じたソリューションを付加価値として提供し、そのソリューションの中で画像形成装置を機能させるためのSI作業等の業務を行うものも含まれる。これらの、販売業者は、ハードウェアとしての画像形成装置の販売による利益や、SI作業等に基づくソフトウェアによる利益等を主な収益原とている。
【0022】
他方において、画像形成装置は、一度販売された後でもサプライの継続的な販売によって、継続的に利益を得られるという特性があり、またその利益は、一般的に画像形成装置の販売による利益よりも大きい。しかしながら、従来、顧客(ユーザ)は、機器の購入後は販売業者を介することなく量販店や通信販売等によりサプライを購入するのが一般的であった。したがって、画像形成装置を販売した販売業者は、当該画像形成装置のサプライによる継続的な利益を得ることができなかった。
【0023】
ここで、或る販売業者がメーカーA及びメーカーBの画像形成装置の販売を行っている場合を想定する。仮に、メーカーAの画像形成装置を販売した場合は、当該画像形成装置のサプライの販売による利益が当該販売業者に還元されるとすれば、販売業者には、メーカーBの画像形成装置よりもメーカーAの画像形成装置をより多く販売したいというインセンティブが働く。その結果、メーカーAの製品を売り上げの増加を期待することができ、メーカーAは、メーカーBに対して競争上優位な差別化を図ることが期待できる。
【0024】
そこで、本発明者は、新たなビジネスモデルとして、サプライの販売による利益が販売業者に還元される仕組みを考案した。本実施の形態では、発注支援システム1を当該ビジネスモデルに適用した例について説明する。
【0025】
以下、図1の発注支援システム1の処理手順について説明する。販売業者より機器30を購入したユーザは、当該販売業者との間で発注支援システム1への登録契約を締結する。当該登録契約を結んだユーザは、図3に示されるようにまずユーザ登録を行う。なお、以下の説明から明らかになることであるが、ユーザは、発注支援システム1の利用によってサプライの補給作業にかかるコストを低減させることが期待できる。その期待が、ユーザにとって当該登録契約の締結に対するインセンティブとなる。
【0026】
図3は、発注支援システムにおけるユーザ登録時の処理手順を説明するためのシーケンス図である。なお、図3において、Webブラウザ22は、クライアントPC20にインストールされている汎用的なWebブラウザである。また、メーラ23は、クライアントPC20にインストールされている汎用的なメーラである。
【0027】
まず、ユーザは、登録契約の際に発注支援サーバ10へアクセスするためのID(以下「アクセスID」という。)と、発注支援サーバ10のURLとを販売業者より入手し、当該URLをWebブラウザ22に入力する。URLの入力に応じてアクセスIDの入力が要求され、当該アクセスIDが正当に入力されると、ユーザ登録を行うためのWebページ(以下「ユーザ登録ページ」という。)が、発注支援サーバ10よりWebブラウザ22に送信される(S11)。ユーザ登録ページを受信したWebブラウザ22は、当該ユーザ登録ページを表示させる。
【0028】
図4は、ユーザ登録ページの表示例を示す図である。図4の説明において()内の数字は、図中における参照番号に対応する。図4に示されるように、ユーザ登録ページ220においては、ユーザの氏名(221)、郵便番号(222)、住所(223)、会社名(224)、部署名(225)、電話番号(226)、FAX番号(227)、及び電子メールアドレス(228)等の基本情報の他、サプライを発注した際のサプライの配送先の郵便番号、住所、会社名、及び部署名等(231)と、販売業者ID(232)との入力が可能となっている。ここで、販売業者IDは、当該ユーザが上記登録契約を締結した相手となる販売業者のIDであり、登録契約時に販売業者より通知される。
【0029】
ユーザが、ユーザ登録ページ220において必要事項を入力し、登録ボタン233をクリックすると、Webブラウザ22は、発注支援サーバ10に対してユーザ登録を要求するHTTPリクエストを送信する(S12)。当該HTTPリクエストには、ユーザ登録ページ220への入力情報(以下、販売業者IDも含めて「ユーザ情報」という。)が含まれている。
【0030】
発注支援サーバ10の発注支援プログラム11は、HTTPリクエストが受信されると、当該HTTPリクエストに含まれているユーザ情報を所定のデータベース(以下「ユーザデータベース」という。)に登録する(S13)。ユーザ情報の登録に際し、発注支援プログラム11は、ユーザ情報に含まれている販売業者IDが発注支援サーバ10にエントリされているか否かを判定し、エントリされている場合は、当該ユーザに対するユーザID及びパスワードを生成又は採番する。更に、当該ユーザID及びパスワードをもユーザ情報に含めてユーザデータベースに登録する。
【0031】
続いて、発注支援プログラム11は、監視プログラム21のダウンロードを実行させるためのWebページ(以下「ダウンロードページ」という。)へのURLや、生成されたユーザID及びパスワード等が本文に記載された電子メール(以下、「インストール情報通知メール」という。)をユーザのメールアドレスに送信する(S14)。また、発注支援プログラム11は、インストール情報通知メールを送信した旨のメッセージを表示させるWebページを、ステップS12におけるHTTPリクエストに対するHTTPレスポンスに含めてWebブラウザ22に対して送信する。ユーザは、当該Webページによって、インストール情報通知メールが自分宛に送信されたこと知ることができる。そして、メーラ23によってインストール情報通知メールを閲覧することにより、ダウンロードページのURLや自分に対して割り有り当てられたユーザID及びパスワード等を確認することができる。
【0032】
なお、ダウンロードページのURL等の通知は、必ずしも電子メールによる必要はない。例えば、ステップS14において、インストール情報通知メールを送信した旨のメッセージを表示させるWebページではなく、ダウンロードページが返信されるようにしてもよい。但し、ステップS14のタイミングでダウンロードページが返信されてしまうと、そのままインストール作業を続行する必要があるのに対し、インストール情報通知メールによれば、当該メールの受信後ユーザの都合のいいときにインストール作業を行えるという点でユーザにとって便宜である。また、FAXや郵送によってこれらの情報が送付されるようにしてもよい。
【0033】
ユーザが、インストール情報通知メールに記載されているダウンロードページのURLをクリックすると、メーラ23は、当該URLを引数としてWebブラウザ22を起動させる。Webブラウザ22は、起動すると、当該URLに基づいてダウンロードページを表示させる。ユーザが、ダウンロードページにおいてダウンロード先のURLをクリックすると、Webブラウザ22は、発注支援サーバ10に対して、監視プログラム21のダウンロード要求を送信する(S15)。発注支援プログラム11は、当該要求に応じ、発注支援サーバ10に保存されている監視プログラム21のインストールパッケージをクライアントPC20に転送する(S16)。
【0034】
ユーザは、ダウンロードされたインストールパッケージに含まれているインストーラ25を起動する(S17)。インストーラ25は、起動されるとユーザに対してインストール情報通知メールにおいて通知されたユーザID及びパスワード等の入力を要求する。ユーザがユーザID及びパスワード等を入力すると、インストーラ25は、入力されたユーザID及びパスワードを発注支援サーバ10に送信し、ユーザの認証を要求する(S18)。なお、入力されたユーザID及びパスワードは、クライアントPC20においても保存され、管理される。
【0035】
発注支援プログラム11は、インストーラ25より送信されたユーザID及びパスワードと、ユーザデータベースに登録されているユーザID及びパスワードとを照合することによりユーザの認証を行う(S19)。発注支援プログラム11は、認証結果を監視プログラム21に返信する(S20)。インストーラ25は、認証が成功した場合のみ監視プログラム21のインストールを実行し(S21)、認証が失敗した場合はインストールを中止する。
【0036】
ユーザが認証された場合のみインストールを実行することで、例えば、インストールパッケージを不正に入手したユーザによるインストールを防止することができる。監視プログラム21は、ネットワークを介して発注支援プログラム11と通信を行うものである。したがって、不正ユーザによる監視プログラム21の利用を防止し、発注支援サーバ10に対するネットワークを介した攻撃を抑止するためにも、インストール時のユーザ認証は効果的である。
【0037】
インストールが正常に行われると、監視プログラム21の監視サービス212は、クライアントPC20上で動作を開始する。まず、監視サービス212はネットワーク50に接続されている機器30を検索し(S22)、検索された全ての機器30の情報(例えば、機器のシリアル番号、MACアドレス、機種(モデル)名、ベンダ名(機器メーカーの名前)等を含む情報。以下「検索機器情報」という。)を、発注支援サーバ10に送信する(S23)。なお、ネットワーク50上における機器30の検索及び検索機器情報の取得は、周知の技術を用いて行うことが可能である。
【0038】
発注支援プログラム11は、受信された検索機器情報を所定のデータベース(以下「機器データベース」という。)に登録する(S24)。
【0039】
図5は、機器データベースを構成する機器情報テーブルの構成例を示す図である。図5に示されるように機器情報テーブル12は、検索された機器30ごとにMACアドレス、ベンダ名、機種名、シリアル番号、監視フラグ、備考、サプライのステータス、及びメールフラグ等が登録され、管理されるテーブルである。MACアドレス、ベンダ名、機種名、及びシリアル番号は、検索機器情報に含まれているものがそのまま登録される。その他IPアドレス等も登録されるが、図中では便宜上省略されている。
【0040】
監視フラグは、監視サービス212の監視対象とされているか否かを示すフラグ情報であり、監視対象の場合は「Yes」、監視対象でない場合は「No」が登録される。なお、初期値としては「Yes」が登録される。但し、初期値はNULL(空)値であってもよい。備考は、ユーザの任意によって機器に関連付けておきたい情報が登録される項目である。
【0041】
サプライのステータスは、サプライのステータスを識別するための情報が登録される項目である。本実施の形態では、N(Normal)、Ne(Near End)、又はE(End)が登録されることとする。初期値としては「N」であってもよいし、NULL値であってもよい。メールフラグについては後述する。
【0042】
続いて、発注支援プログラム11は、検索機器情報の一覧を表示させるWebページ(以下「検索機器一覧ページ」という。)のURLを監視サービス212へ送信する(S25)。監視サービス212は、受信したURLを引数としてWebブラウザ22を起動させる(S26)。Webブラウザ22は、起動すると、引数に指定されたURLに基づいて検索機器一覧ページを要求するHTTPリクエストを発注支援サーバ10に送信する(S27)。発注支援プログラム11は、受信されたHTTPリクエストに応じ、機器情報テーブル12に登録されている情報に基づいて検索機器情報一覧ページを生成し、当該検索機器情報一覧ページをWebブラウザ22に返信する(S28)。
【0043】
図6は、検索機器一覧ページの表示例を示す図である。図6の説明において()内の数字は、図中における参照番号に対応する。図6に示されるように、検索機器一覧ページ240には、検索された機器30ごとに、シリアル番号、MACアドレス、IPアドレス、モデル名、及びベンダ名等が表示される。検索機器一覧ページ240には更に、機器30ごとに、備考を入力させるための欄(241)と、監視サービス212による監視対象とするか否か(監視の要否)を選択させるためのチェックボタン(242)とが設けられている。すなわち、ユーザは、検索機器一覧ページ240において、機器30ごとに備考の入力と監視対象とするか否かの選択とを行う。本実施の形態では、チェックボタンがチェックされた場合に、監視対象として選択されたものとする。備考欄241には、ユーザの任意によって自由な情報の入力が可能であるが、例えば、機器30の配置場所等、サプライの交換作業の補助となるような情報を入力しておくとよい。
【0044】
ユーザが、検索機器一覧ページ240において、各機器30について備考の入力と、監視の要否の選択とを行い、送信ボタン243をクリックすると、Webブラウザ22は、各機器30の備考と監視の要否との登録を要求するHTTPリクエストを発注支援サーバ10に送信する(S29)。発注支援プログラム11は、受信されたHTTPリクエストに基づき、各機器30の備考と監視の要否とを機器情報テーブル12に追加登録する(S30)。すなわち、機器情報テーブル12の「監視フラグ」については、監視対象とされた機器については「Yes」が登録され、監視対象とされなかった機器については「No」が登録される。
【0045】
図7は、監視の要否及び備考が登録された機器情報テーブルの例を示す図である。図7の機器情報テーブル12では、1行目のエントリの備考に「大森4F」といったような配置情報が登録された例が示されている。また監視フラグについては、1〜4行目のエントリに係る機器が監視対象とされ、5〜7行目のエントリに係る機器が監視対象から除かれた例が示されている
以上で、ユーザ登録時の処理は終了する。なお、監視プログラム21は、インストール時以外にも、例えばユーザのメニュー選択によって機器検索情報の登録、検索機器一覧ページの表示をさせ、監視対象機器を追加させるようにしてもよい。
【0046】
監視サービス212は、その後もネットワーク50に接続されている機器30の検索を自動的かつ繰り返し(例えば、定期的に)行う(S31)。監視サービス212は、検索された機器の検索機器情報を発注支援サーバ10に送信する(S32)。発注支援プログラム11は、受信された検索機器情報に基づいて、機器情報テーブル12を更新する(S33)。ネットワーク50の構成が定期的に検査され、その検査結果に基づいて機器情報テーブル12が更新されることで、機器情報テーブル12の内容とネットワーク50の構成との間にずれが発生する可能性を低くすることができる。
【0047】
ステップS33において実行される機器情報テーブルの更新処理の詳細について説明する。図8は、発注支援プログラムによる機器情報テーブルの更新処理を説明するためのフローチャートである。検索機器情報を受信すると発注支援プログラム11は、検索機器情報と共に監視サービス212より送信されるユーザID及びパスワードに基づいてユーザの認証を行う(S331)。ユーザが認証された場合(S331でYes)、検索機器情報に含まれている機器ごとにステップS332以降の処理を行う。
【0048】
まず、一つの機器を処理対象とし(以下、処理対象とされた機器を「カレント機器」という。)(S333)、カレント機器が新たに検索された機器(以下「新規機器」という。)であるか否かを判定する(S334)。この判定は、カレント機器のMACアドレスをキーとして、機器情報テーブル12に当該MACアドレスを有するエントリが有るか否かによって行う。当該エントリが無ければカレント機器は新規機器であると判定される。
【0049】
カレント機器は新規機器であると判定した場合(S334でYes)、カレント機器のエントリを機器情報テーブル12に登録する(S335)。この際、カレント機器は監視対象とする。すなわち、新たに追加されたエントリの監視フラグに「Yes」を登録する。自動的な処理においては、新規機器を監視対象とするか否かについてユーザ問い合わせる適切なタイミングがないため、発注支援プログラム11が自動的に監視フラグを「Yes」とするのである。ここで、「No」ではなく「Yes」とするのは、ユーザは、ネットワーク50に接続されている機器30のサプライを監視させたいからこそ監視プログラム21をインストールしているのであり、かかるユーザの意図に基づけば、新規機器はデフォルトで監視対象とされるのが妥当であると考えられるからである。また、発注サイト側にとっても、できるだけ多くの機器を監視対象とすることで、サプライの販売促進等を期待できるからである。
【0050】
一方、カレント機器のMACアドレスを有するエントリが既に存在した場合(S334でNo)、当該エントリのベンダ名及び機種名が、カレント機器のベンダ名及び機種名と一致するか否かを判定する(S336)。この判定は、MACアドレスの一致だけでは必ずしも機器の同一性は保証されないことに基づく。すなわち、MACアドレスがネットワークカードから取得されるタイプの機器も存在し得るところ、当該ネットワークカードが他の機器に差し替えられてしまう可能性があるため、MACアドレスによる機器の識別は必ずしも完全なものでないからである。
【0051】
カレント機器のMACアドレスと一致するエントリについて、ベンダ名及び機種名の少なくともいずれか一方が一致しない場合、当該エントリの一致しない部分を更新し、更に、監視フラグを「Yes」とする。例えば、図9は、機種名が一致しないエントリが存在した場合の機器情報テーブルの更新例を示す図である。
【0052】
図9では、5行目のエントリの機種名が一致しなかった場合の更新例が示されている。すなわち、5行目のエントリの機種名が、カレント機器の検索機器情報に含まれている機種名に変更され、更に、監視フラグが「Yes」とされている。監視フラグが「Yes」とされるのは、このような機器は新機器として扱うのが妥当であると考えるからである。
【0053】
一方、カレント機器のMACアドレスに有するエントリが既に存在した場合であって(S334でNo)、当該エントリのベンダ名及び機種名が、カレント機器のベンダ名及び機種名と一致する場合(S335でNo)、カレント機器は既に当該エントリに登録されている機器であると判定する。但し、カレント機器の一部の属性(例えば、シリアル番号等)に変更がある場合は、当該エントリにおける当該一部の属性に対応する項目を更新する(S338)。但し、監視フラグは変更しない。すんわち、「No」であってもそのままとする。「No」とされている監視フラグを自動的に変更してしまうことは、意識的に当該機器を監視対象から除いたユーザの意図に反することになるからである。
【0054】
ステップS333〜S338までの処理が検索機器情報に含まれる全ての機器について完了すると(S332でYes)、検索機器情報の登録が成功した旨を監視サービス212に返信し(S340)、処理を終了する。なお、ユーザ認証に失敗した場合は(S331でNo)、機器情報テーブル12の更新は行わず、エラー情報を監視サービス212に返信する(S339)。
【0055】
次に、クライアントPC20にインストールされた監視プログラム21(監視サービス212)によって機器30の状態の監視が行われる際の発注支援システム1の処理手順について説明する。図10は、発注支援システムにおける機器監視時の処理手順を説明するためのシーケンス図である。
【0056】
監視サービス212は、繰り返し(例えば、定期的に)訪れる機器状態監視時間になると、発注支援サーバ11に監視対象となっている機器30(以下、「監視機器」という。)のリストを問い合わせる(S101)。発注支援プログラム11は、機器情報テーブル12の監視フラグに基づいて監視機器をリストアップし、リストアップされた監視機器の登録情報の一覧(監視機器リスト)を監視サービス212に返信する(S102)。なお、監視サービス212は、機器状態監視時間以外にも、例えばユーザのメニュー選択によって機器監視を行うようにしてもよい。このように、監視サービス212側では、各機器が監視対象であるか否かについては自ら管理せず、発注支援サーバ11側に問い合わせることで監視機器を識別する。かかる構成により監視サービス212の実装を簡便化させることができ、処理負荷を低減させることができる。
【0057】
監視サービス212は、監視機器リストを受信すると、当該監視機器リストに基づいてキャッシュテーブルを更新する(S103)。ここでキャッシュテーブルとは、監視サービス212が監視機器のサプライのステータス等を管理するためのテーブルであり、例えば、クライアントPC20のメモリ上に構築される。
【0058】
図11は、キャッシュテーブルの構成例を示す図である。図11に示されるように、キャッシュテーブル27は、監視機器ごとにMACアドレス、ベンダ名、機種名、シリアル番号、備考、監視情報、サプライステータス、及び通知フラグ等が登録及び保持されるテーブルである。ステップS103では、受信された監視機器リストに基づいて、MACアドレス、ベンダ名、機種名、シリアル番号、及び備考が登録又は更新される。例えば、受信された監視機器リストに含まれている監視機器と同一のMACアドレスに係るエントリがキャッシュテーブル27に存在しない場合、監視サービス212は、当該監視機器に係るエントリをキャッシュテーブル27に新たに追加する。また、同一のMACアドレスに係るエントリは存在するが、他の情報(ベンダ名、機種名、シリアル番号又は備考)が異なる場合、当該エントリについて当該異なる情報を更新する。また、監視機器リストに含まれていないMACアドレスを有するエントリがキャッシュテーブル27に存在する場合、監視サービス212は、当該エントリを削除する。すなわち、キャッシュテーブル27は、現時点において監視機器とされている機器についてのみエントリを保持する。なお、キャッシュテーブル27において、監視情報、サプライステータス、及び通知フラグについては、後述の処理によって更新される項目であり、その内容についてはその都度説明する。
【0059】
続いて、監視サービス212は、キャッシュテーブル27にエントリされている機器30(監視機器)に対して機器情報としてのMIB情報をSNMPに基づいて問い合わせる(S104)。問い合わせ対象となるMIB情報としては、少なくともトナーのステータス情報が含まれ、また、他のサプライのステータス情報が含まれていてもよい。各機器30は、問い合わせ対象とされたMIB情報を監視サービス212に対して返信する(S105)。
【0060】
なお、本発明の実施にあたり、機器情報は必ずしもMIB情報に限定されず、機器情報を問い合わせるためのプロトコルはSNMPに限定されないが、標準化された技術を用いることにより、各機器30のベンダが異なっていても、同じ手順によって機器情報の取得が可能であるという観点より、MIBやSNMP等の標準技術に基づくのが好適である。
【0061】
全ての監視機器からの機器情報の取得(ポーリング)が完了すると、監視サービス212は、当該機器情報に基づいて、キャッシュテーブル27の監視状態、サプライステータス、及び通知フラグを更新する(S106)。監視状態については、機器情報の取得に成功した機器に係るエントリについては「OK」を登録し、失敗した機器に係るエントリについては「NG」を登録する。また、サプライステータスについては、取得された機器情報に含まれているトナーステータス等、サプライの状態情報が登録される。通知フラグには、サプライステータスの値が変化した場合、「未通知」が登録される。すなわち、監視サービス212は、更新前のキャッシュテーブル27に登録されているサプライステータスと、新たに取得された機器情報に含まれているサプライのステータス情報とを比較することによりサプライの状態の変化を検知し、状態の変化が検知されたサプライについて、キャッシュテーブル27におけるエントリの通知フラグを「未通知」とする。なお、通知フラグは、サプライの状態変化が発注支援プログラム11に通知済みか否かを判別するために用いられる。
【0062】
図12は、機器情報のポーリング結果に基づくキャッシュテーブルの更新例を示す図である。図12は、図11の状態からの更新例を示す。すなわち、一行目のエントリに関しては、サプライステータスが「normal」(不足していない状態)から「near end」(ニアエンド)に変化している。したがって、通知フラグの値は「未通知」に更新されている。同様に、四行目のエントリに関してもサプライステータスが「near end」から「end」(エンド)に変化しているため、通知フラグの値は「未通知」に更新されている。一方、三行目及び五行目のエントリは、サプライステータスは変化していないため、通知フラグの値も更新されていない。また、二行目のエントリは、監視状態が「NG」とされている。当該エントリに係る機器30からの機器情報の取得に失敗したためである。この場合、サプライステータス及び通知フラグの値は更新されない。
【0063】
続いて、監視サービス212は、更新されたキャッシュテーブル27に基づいて、状態変化通知情報を生成する(S107)。監視サービス212は、キャッシュテーブル27において通知フラグの値が「未通知」のエントリに係る機器に関して状態変化通知情報を生成する。したがって、図12のキャッシュテーブル27に基づけば、一行目、三行目及び四行目のエントリに係る機器に関して状態変化通知情報が生成される。
【0064】
図13は、状態変化通知情報の構成例を示す図である。図13において、状態変化通知情報は、ヘッダ情報と機器情報とから構成される。
【0065】
ヘッダ情報は、日時、ユーザID、及びパスワード等を含む。日時は、機器情報を転送する日時である。ユーザID及びパスワードは、監視プログラム21のインストール時に入力され、保存されているユーザID及びパスワードである。すなわち、ヘッダ情報は、機器30より取得された情報ではない。
【0066】
機器情報は、上記における機器情報と同義である。すなわち、機器30よりMIB情報として取得された情報であり、当該機器30のベンダ名、機種名(モデル名)、シリアル番号、MACアドレス、IPアドレス、トナーID(トナーボトルを特定するための情報、カラーであれば、トナーIDは各色ごとに付与され、モノクロであれば1個付与される)、トナー名称、トナーステータス、トナーレベル、トナー名(文字列)、トナー名(Code)、及びトータルカウンタ値等を含む。これらは、public MIB(標準MIB)として定義されているものであり、ベンダを問わずいずれの機器からも取得可能な情報である。
【0067】
トナーステータスは、トナーの状態を示す情報である。また、トータルカウンタ値は、総印刷枚数を示す情報である。したがって、監視サービス212は、トナーステータスによってトナーエンドを検知する。また、トータルカウント値によって、感光体、定着ユニット、及び現像剤等の消耗度を判定する。但し、標準MIBにおけるトナーステータスでは、エンドとなったトナーの色までは特定することはできない。
【0068】
そこで、本実施の形態における機器情報は、更に、モノクロカウンタ値、カラーカウンタ値、シアンカウンタ値、マゼンタカウンタ値、ブラックカウンタ値、及びレッドカウンタ値等をも含む。これらは、private MIB(拡張MIB)としてベンダ独自に定義されているものである。
【0069】
例えば、本実施の形態では、メーカーAの機器30のみがこれらの拡張MIBに対応しているとすれば、メーカーAの機器30についての機器情報にはこれらの値が格納されるが、メーカーA以外の機器30についての機器情報ではこれらの値は空となる。
【0070】
例えば、モノクロカウンタ値は、モノクロ印刷による印刷枚数である。カラーカウンタ値は、カラー印刷による印刷枚数である。また、シアンカウンタ値、マゼンタカウンタ値、ブラックカウンタ値、及びレッドカウンタ値は、それぞれの色のトナーを使用した印刷枚数である。したがって、メーカーAの機器30であれば、色ごとにそのエンドを検知することが可能となる。
【0071】
なお、図12等に示されるキャッシュテーブル27では、便宜上監視機器ごとに一つのエントリが割り当てられているが、複数のサプライの状態について(例えば、CMYKそれぞれのトナーステータスやトータルカウンタ値等について)管理する場合は、当該サプライごとにエントリを割り当てればよい。また、状態変化通知情報に含める情報は、図13に示され得ものに限定されず、必要に応じて、適宜決定すればよい。
【0072】
続いて、監視サービス212は、生成された状態変化通知情報を発注支援プログラム11に送信する(S108)。なお、状態変化通知情報は、各機器のものが同時に(一つのメッセージにまとめられて)送信されるのが通信負荷の低減の観点より好ましい。機器ごとに別個のメッセージとして送信される場合に比べ、オーバーヘッドを低下させることができるからである。
【0073】
状態変化通知情報を受信した発注支援プログラム11は、状態変化通知情報に基づく機器情報テーブルの更新や、サプライが不足している機器の判定等の処理を行う(S109)。なお、当該ステップにおける処理の詳細については後述する。
【0074】
続いて、発注支援プログラム11は、不足しているサプライの発注用のWebページ(以下「発注ページ」という。)を生成し、当該サプライが不足していることを通知する電子メール(以下「不足通知メール」という。)を作成し、ユーザのメールアドレスに対して送信する(S110)。不足通知メールには、発注ページのURLが記載される。なお、各不足通知メールには、IDが付与され(以下「メールID」という。)、メールIDと共に、当該不足通知メールの対象とされた機器30のシリアル番号等の機器30を識別するための情報と、ユーザID又はメールアドレス等ユーザを識別するための情報と、送信日時等とが不足通知メールの送信履歴として保存される。
【0075】
図14は、不足通知メールの例を示す図である。図14に示される不足通知メール250において、<>で囲まれた文字列は具体的な値ではなく、当該個所に記述される情報の内容を示す。
【0076】
図14に示されるように、不足通知メール250の宛先には、状態変化通知情報に係るユーザのメールアドレスが指定される。当該該ユーザのメールアドレスの特定は、状態変化通知情報に含まれているユーザID及びパスワードをキーとして、ユーザデータベースより検索すればよい。ユーザデータベースには、ユーザ登録時において、ユーザID及びパスワードと共にメールアドレスが登録されているからである。
【0077】
不足通知メール250のタイトルには、当該メールが不足通知メールであることを示すタイトルが記載される。不足通知メール250の本文には、状態変化通知情報に係る機器に関する情報、不足しているサプライに関する情報、発注ページのURL等が記載される。
【0078】
機器に関する情報は、当該機器のベンダ名、モデル名、及び備考等が含まれる。これらの情報は、状態変化通知情報に含まれているシリアル番号、MACアドレス又はIPアドレス等をキーとして、機器データベースより取得すればよい。また、不足しているサプライに関する情報は、例えば、当該サプライがトナーである場合は、状態変化通知情報に含まれているトナーステータス、トナーID、トナー名称等が記載される。なお、一つの機器30において複数のサプライが同時に不足した場合は、一つの不足通知メール250内に当該複数のサプライの不足を示す情報を含むメールを作成し、当該複数のサプライの不足が通知される。
【0079】
不足通知メール250の送信後、発注支援プログラム11は、状態変化通知情報の受信(S108)に応じた一連の処理(不足通知メール250の送信等)の処理結果を監視サービス212に返信する(S111)。監視サービス212は、当該処理結果が、処理の正常終了を示している場合(すなわち、状態変化通知情報が正常に処理された場合)は、キャッシュテーブル27の通知フラグについて、「未通知」を「通知済み」に更新する(S112)。
【0080】
図15は、状態変化通知情報が正常に処理された際のキャッシュテーブルの更新例を示す図である。図15は、図12からの更新例を示す。図15のキャッシュテーブル27では、一行目、三行目及び四行目のエントリの通知フラグが、「未通知」から「通知済み」に更新されている。通知フラグの値がこのように更新されることにより、正常に処理されたサプライの状態変化について、二重に状態変化通知情報が送信されるのを抑止することができる。したがって、通信量を削減することができ、ひいては不足通知メール250の二重送信を抑止することもできる。
【0081】
クライアントPC20におけるメーラ23によって不足通知メール250を閲覧したユーザは、印刷等を実行していないときでも、サプライの不足を認識することができる。また、備考として機器30の配置場所等を入力しておけば、当該情報によって機器30の配置場所の特定等を容易に行うことができる。
【0082】
ユーザが、不足通知メール250に記載されている発注ページのURLをクリックすると、メーラ23は、クリックされたURLを引数としてWebブラウザ22を起動させる。Webブラウザ22は、起動すると、引数に指定されたURLに基づいて発注ページを要求するHTTPリクエストを発注支援サーバ10に送信する(S113)。発注支援プログラム11は、受信されたHTTPリクエストに応じ、発注ページをWebブラウザ22に返信する(S114)。Webブラウザ22は、受信した発注ページを表示させる。
【0083】
図16は、発注ページの表示例を示す図である。図16において、発注ページ260には、領域261においてサプライが不足している機器に関する情報(メーカー(ベンダ)名、モデル名、シリアル番号、備考(配置位置)が表示されている。また、領域262において、不足しているサプライの名称が表示されている。また、領域262では、当該機器に対応した各種サプライの一覧が表示され、それぞれの発注が可能となっている。すなわち、サプライごとに、その商品名(名称)が表示され、購入する数量の入力が可能とされている。なお、参照番号2621に示されるように、不足しているサプライについては予め必要な数量が入力されて表示されている。また、各商品名には、当該商品の概要説明を表示するWebページへのリンクが張られている。更に、領域263では、当該ユーザの過去の購入履歴が表示される。これによって、ユーザが重複して購入してしまうことを防止することができる。
【0084】
なお、購入履歴は、ユーザデータベースにユーザごとに登録されている。すなわち、発注ページ260を介して商品の発注が行われると、発注された商品の情報がユーザデータベースに追加登録される。
【0085】
ところで、図16の発注ページ260では、イエローのトナーが不足している旨が通知されている。上述したように、標準MIBだけでは、不足しているトナーの色は特定できない。したがって、図16の発注ページ260には、拡張MIBに登録されている情報に基づいて判定された結果が示されている。このように、発注支援システム1を展開するメーカーは、自らが定義した拡張MIBによって、発注支援システム1上のサービスにおいて、他社と差別化を図ることができる。すなわち、仮に、他社の機器30のトナーエンドが検知された場合は、発注ページ260にはその色までは特定されて通知されない。なお、他社の機器30のサプライについては、そもそも発注支援システム1による発注対象から除外するということも考えられるが、ユーザの利便性を考慮し、本実施の形態では、他社の機器30のサプライの発注も可能としている。
【0086】
発注ページ260において、ユーザが注文ボタン2622をクリックすると、Webブラウザ22は、商品の発注を要求するHTTPリクエストを発注支援サーバ10に送信する(S115)。
【0087】
HTTPリクエストに応じ、発注支援プログラム11は、当該ユーザと関連付いている販売業者に対して当該発注要求に基づく利益の一部を供与するための情報を記録する(S116)。具体的には、発注業者ごとに、発注支援システム1によるサプライの売り上げを管理するデータベース(以下「販売業者データベース」という。)が構築されており、当該販売業者データベースの売り上げに、今回の発注による注文の内容(例えば、注文金額)が記録される。なお、販売業者は、メーカーとの間で発注支援システム1への参加契約を締結することにより、販売業者データベースへのエントリが作成される。また、販売業者IDが与えられ、当該販売業者は、発注支援システム1上において、当該販売業者IDによって識別される。なお、ステップS116において、受信されるHTTPリクエストに係るユーザの識別は、例えば、Webブラウザ22とのセッションIDとユーザIDとを関連付けておき、その関連付けに基づいて、セッションIDよりユーザIDを特定することにより行えばよい。
【0088】
発注支援プログラム11は、更に、当該発注の指示を物品発注管理システムに指示する。この指示には、ユーザデータベースに登録されている配送先の情報が含まれている。物品発注支援システムに発注が指示されることにより、発注された商品は、実際にユーザの元に配送される。更に、ユーザから購入代金支払われると、販売業者データベースに、今回の発注による売り上げが確定したことが記録される。売り上げか確定することにより、当該販売業者には、売り上げに応じて販売促進金などの手当をメーカーから供与してもよい。
【0089】
続いて、図10におけるステップS109の処理の詳細について説明する。図17は、発注支援プログラムによる状態変化通知情報に基づく処理を説明するためのフローチャートである。
【0090】
状態変化通知情報を受信すると、発注支援プログラム11は、状態変化通知情報と共に監視サービス212より送信されるユーザID及びパスワードに基づいてユーザの認証を行う(S401)。ユーザが認証された場合(S401でYes)、状態変化通知情報が受信された機器ごとにステップS402以降の処理を行う。
【0091】
まず、一つの機器を処理対象とし(以下、処理対象とされた機器を「カレント機器」という。)(S403)、カレント機器は機器情報テーブル12に登録されているか否かを判定する(S404)。この判定は、カレント機器のMACアドレスをキーとして、機器情報テーブル12に当該MACアドレスを有するエントリが有るか否かによって行えばよい。カレント機器が未登録である場合(S404でNo)、カレント機器のエントリを機器情報テーブル12に登録する(S405)。この際、カレント機器は監視対象とする。なお、MACアドレスに基づいてカレント機器が登録されていると判断された場合、図8のS336〜S338において説明したような処理を行ってもよい。
【0092】
続いて、状態変化通知情報に含まれているカレント機器のサプライのステータス情報を機器情報テーブル12のステータスに反映(転記)する(S406)。続いて、機器情報テーブル12に登録されているカレント機器のステータスに基づいて、カレント機器について不足していているサプライ(すなわち、ステータスが「Ne」(ニアエンド)又は「E」(エンド)のサプライ)の有無を判定する(S407)。不足しているサプライが存在する場合(S407でYes)、機器情報テーブル12においてカレント機器に係るエントリ(以下「カレントエントリ」という。)のメールフラグの値は「Yes」であるか否かを判定する(S408)。ここで、メールフラグは、不足通知メール250が送信された場合に「Yes」とされるフラグである。すなわち、メールフラグの値が「Yes」であるということは、過去にカレント機器について不足通知メール250が送信されたことがあることを意味する。
【0093】
メールフラグが「Yes」の場合(S408でYes)、不足通知メール250の重複送信チェックを行う(S409)。ここで、重複送信チェックとは、同じ内容の不足通知メール250が送信された可能性の有無を判定するための処理であり、その処理内容の詳細については後述する。重複送信チェックにおいて、重複送信の可能性は低く不足通知メール250は送信すると判定された場合(S409で「送信する」)、メールフラグを「Yes」とし(S410)、カレント機器に関する不足通知メール250を送信する(S411)。この処理は、図10におけるステップS110に相当する。なお、ステップS407において、不足しているサプライが複数検知された場合は、当該複数のサプライについてまとめて一つの不足通知メール250が送信される。したがって、ユーザに送信される不足通知メール250の数を少なくすることができ、ユーザに与える煩雑さ等を低減させることができる。
【0094】
また、重複送信チェックにおいて、重複送信の可能性が高く不足通知メール250は送信しないと判定された場合は(S409で「送信しない」)、不足通知メールは送信せずにカレント機器に関する処理を終了する。
【0095】
一方、メールフラグが「No」の場合(S408でYes)、不足通知メール250の重複のおそれはないため、重複送信チェックは行わず、メールフラグを「Yes」とし(S410)、不足通知メールを送信する(S411)。
【0096】
また、S407において、カレント機器についていずれのサプライも不足していないと判定された場合、この場合は不足通知メールは送信する必要はないため、メールフラグを「No」とし、不足通知メールは送信せずにカレント機器に関する処理を終了する。
【0097】
ステップS403〜S412までの処理が状態変化通知情報の受信された全ての機器について完了すると(S402でYes)、状態変化通知情報が正常に処理されたことを監視サービス212に返信し(S414)、処理を終了する。この処理は、図10におけるステップS111に相当する。なお、ユーザ認証に失敗した場合は(S401でNo)、機器情報テーブル12の更新は行わず、エラー情報を監視サービス212に返信する(S413)。
【0098】
続いて、図17におけるステップS409の不足通知メールの重複送信チェックの詳細について説明する。図18は、不足通知メールの重複送信チェック処理を説明するための図である。当該処理の意義について説明する。
【0099】
監視サービス212は、キャッシュテーブル27の通知フラグに基づいて状態変化通知情報を送信するため、監視サービス212は、基本的には二重に同一の状態変化通知情報を送信することはない。しかしながら、例えば、トナーについては、トナーボトルの中にまだトナーが残っている場合にトナーエンドが検知される場合がある。このような場合、ユーザがトナーボトルを振った後に当該トナーボトルを取り付けると、しばらくしてから改めて同一のトナーについてトナーエンドが検知されてしまうことが考えられる。このような場合、通知フラグは、「end」から「normal」に変化し、再び「end」に変化するため、同一のトナーボトルが交換されていないにもかかわらず、監視サービス212は、再度トナーエンドを通知するための状態変化通知情報を送信してしまうことが考えられる。そうすると、ユーザに対して不足通知が重複して送信されてしまい、ユーザが重複に気付かなければ、重複した発注を行ってしまうということが考えられる。そこで、かかる事態の発生を回避するため、発注支援プログラム11は、以下の処理を行う。
【0100】
まず、監視サービス212より受信した状態変化通知情報に含まれている、機器30のシリアル番号に基づいて、不足通知メールの送信履歴より当該機器30に関して最後(前回)に送信した不足通知メールの日時をチェックする(S201)。
【0101】
送信履歴の中に、当該機器30に対する不足通知メールの送信記録が含まれていない場合(S202でYes)、不足通知メールを送信すると判定する(S203)。当該機器30に関しては、今までに不足通知メールを送信したことはなく、したがって、不足通知メールが重複するおそれはないからである。
【0102】
送信履歴の中に、当該機器30に対する不足通知メールの送信記録が含まれている場合(S202でNo)、最後に送信した不足通知メールの送信日時から所定期間が経過している否かを判定する(S204)。所定期間が経過していれば不足通知メールは送信すると判定し(S203)、経過していなければ重複のおそれがあるとして不足通知メールは送信しないと判定する(S205)。
【0103】
なお、図18では、時間の経過に基づいて判定する例を示したが、例えば、送信履歴としてトータルカウンタを記録しておき、トータルカウンタの差分が所定の閾値以下の場合であれば、不足通知メールを送信しないようにしてもよい。また、送信履歴を一定時間ごとに全て削除するようにし、送信履歴の中に同一の機器30に対する不足通知メールの送信記録が含まれている場合は、不足通知メールを送信しないようにしてもよい。
【0104】
次に、監視プログラム21におけるUIアプリ211の機能について説明する。UIアプリ211は、監視サービス212に対する設定情報(例えば、機器情報を取得する周期)を設定させるための画面(以下「設定画面」という。)や、監視サービス212による機器の監視情報を表示させるための画面(以下「監視画面」という。)等を表示させるプログラムである。
【0105】
UIアプリ211は、ユーザからの指示に応じ、例えば次のような設定画面を表示させる。図19は、設定画面の表示例を示す図である。図19の設定画面220では、監視サービス212が監視機器より機器情報をポーリングする周期(参照番号221)と、ネットワーク50上の機器を自動検索する周期(参照番号222)との設定を行うことができる。前者は、図10のステップS104を実行する周期である。後者は、図3のステップS31を実行する周期である。なお、後者については、チェックボックス223において、設定値を無効とすることもできる。すなわち、チェックボックス223のチェックがはずされると、機器30の自動検索は行われない。
【0106】
また、UIアプリ211は、ユーザからの指示に応じ、例えば次のような監視画面を表示させる。図20は、監視画面の表示例を示す図である。図20の監視画面230は、UIアプリ211が、キャッシュテーブル27より取得した情報を表示させる画面である。したがって、キャッシュテーブル27において管理されている情報、すなわち、監視機器ごとに、ベンダ名、機種名、シリアル番号、サプライステータス、及び備考等を表示させる。監視画面230によって、ユーザは任意のタイミングで各監視機器のサプライの状態等を確認することができる。なお、参照番号231で示される「?」マークは、当該マークが付されている機器については機器情報のポーリングに失敗したことを示す。例えば、当該機器が起動されていないような場合や、ネットワーク50から切断された場合等にかかる状態が発生し得る。
【0107】
上述したように、本発明の実施の形態における発注支援システム1によれば、機器30のユーザ(顧客)、販売業者、及びメーカーの三者のそれぞれに対して、利便性又は有益性を提供することができる。
【0108】
すなわち、機器30のサプライの不足が自動的に検知され、不足通知メールがユーザの端末に自動的に送信される。その結果、ユーザは、不足通知メールに記載されているURLをクリックすることで発注ページ260を表示させることができ、発注ページ260によって不足しているサプライを簡便に発注することができる。したがって、ユーザ自らが機器30に対応したサプライを特定したり、量販店に買い出しに行ったりするための手間を省くことができ、サプライの調達コストを低減させることができる。
【0109】
また、販売業者については、サプライによる収益の一部を獲得することができ、その収益源を拡大することができる。
【0110】
また、メーカーについては、販売業者に当該メーカーの機器を他社の機器より優先させて販売したいというインセンティブや、ユーザに当該メーカーの機器を購入したいというインセンティブを与えることができる。すなわち、発注支援システム1を介して販売されたサプライが当該メーカー製のものである場合は他社のサプライが販売された場合よりも還元率を高くしたり、又は、他社のサプライの場合は還元率を0としたりすれば、販売業者にとっては、当該メーカーの製品を販売した方が、サプライの販売による利益を多く享受できるからである。また、ユーザにとっては、当該メーカーの機器を購入すれば、例えば、不足したトナーの色の特定まで可能であるといった、きめ細かいサービスを受けられるという期待を与えることができるからである。
【0111】
更に、メーカーは、ユーザの機器情報を蓄積することによって、各機器30の使用期間等をある程度推測することができる。その結果、買い換えの促進等、新たな販売活動への連携を効果的に行うことができる。
【0112】
なお、上記実施の形態では、ユーザとの間で発注支援システム1の登録契約を締結するのは機器を販売する業者である場合を例として説明したが、必ずしも、ユーザと当該登録契約を締結する相手側は、機器を販売した者に限定されない。機器は販売していない業者であっても、メーカーから発注支援システム1における販売業者IDが与えられるようにしてもよい。この場合、当該業者は、機器の販売とは関係なく、発注支援システム1を介したサプライの販売による利益の還元を受けることができる。
【0113】
以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【0114】
【図1】本発明の実施の形態における発注支援システムの構成例を示す図である。
【図2】監視サービスがクライアントPCに実行させる機能の概要を説明するためのフローチャートである。
【図3】発注支援システムにおけるユーザ登録時の処理手順を説明するためのシーケンス図である。
【図4】ユーザ登録ページの表示例を示す図である。
【図5】機器データベースを構成する機器情報テーブルの構成例を示す図である。
【図6】検索機器一覧ページの表示例を示す図である。
【図7】監視の要否及び備考が登録された機器情報テーブルの例を示す図である。
【図8】発注支援プログラムによる機器情報テーブルの更新処理を説明するためのフローチャートである。
【図9】機種名が一致しないエントリが存在した場合の機器情報テーブルの更新例を示す図である。
【図10】発注支援システムにおける機器監視時の処理手順を説明するためのシーケンス図である。
【図11】キャッシュテーブルの構成例を示す図である。
【図12】機器情報のポーリング結果に基づくキャッシュテーブルの更新例を示す図である。
【図13】状態変化通知情報の構成例を示す図である。
【図14】不足通知メールの例を示す図である。
【図15】状態変化通知情報が正常に処理された際のキャッシュテーブルの更新例を示す図である。
【図16】発注ページの表示例を示す図である。
【図17】発注支援プログラムによる状態変化通知情報に基づく処理を説明するためのフローチャートである。
【図18】不足通知メールの重複送信チェック処理を説明するための図である。
【図19】設定画面の表示例を示す図である。
【図20】監視画面の表示例を示す図である。
【符号の説明】
【0115】
1 発注支援システム
10 発注支援サーバ
11 発注支援プログラム
12 機器情報テーブル
20 クライアントPC
21 監視プログラム
30、30a、30b、30c、30d 機器
40、50 ネットワーク
211 UIアプリ
212 監視サービス
501、502 記録媒体
【技術分野】
【0001】
本発明は、発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムに関し、特に機器の消耗品の発注を支援する発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムに関する。
【背景技術】
【0002】
企業におけるオフィスには、プリンタ、コピー機、ファクシミリ、又はこれらの機能を一台の筐体において実現する複合機等といった複数の機器がネットワークを介して接続されている。
【0003】
上記に挙げた機器は、いずれも装置の使用によって消耗される消耗品を備えており、当該消耗品が適切に交換されることによってその機能が維持される。例えば、プリンタであれば、トナー、定着ユニット、排トナーボトル、感光体、又は現像剤等が相当し、これらは一般的にサプライと呼ばれている。
【0004】
サプライの消耗度を機器の外部から識別するのは困難であるため、ユーザは印刷を指示してエラーが通知されたときにトナー切れを認識し、トナーの交換を行っていた。こうしたユーザによる作業を軽減するため、機器内部でサプライの寿命を検知し、そのサプライに関する情報を操作パネルへの表示や用紙への印字を行う技術や、機器自身がサプライ交換の必要性を表す信号を外部に通知し、その機器が設置されているオフィスに保守作業要員を派遣するという技術が提案されている。
【特許文献1】特開平10−198236号公報
【特許文献2】特開2003−245560号公報
【発明の開示】
【発明が解決しようとする課題】
【0005】
しかしながら、サプライの寿命を検知したとしても、その後のサプライ発注やサプライ交換をユーザ自身が行う場合、交換対象のサプライの型番を正確に確認した上で発注手続きを行われなければならない。そのためサプライ発注までにユーザは煩雑な作業を強いられていた。また、発注自体は先に行っておきたいときでも、発注先の営業日や営業時間等によっては発注可能時期が発注先の営業所の業務時間に依存するという問題もある。さらに、保守作業要員を派遣する発注システムの場合、その分人件費や配送費等のコストも増えるという問題があった。
【0006】
本発明は、上記の点に鑑みてなされたものであって、機器の消耗品の補給作業を簡便化させることのできる発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムの提供を目的とする。
【課題を解決するための手段】
【0007】
そこで上記課題を解決するため、本発明の発注支援システムは、ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することを特徴とする。
【0008】
このような発注支援システムでは、機器の消耗品の補給作業を簡便化させることができる。
【発明の効果】
【0009】
本発明によれば、機器の消耗品の補給作業を簡便化させることのできる発注支援システム、発注支援装置、機器監視装置、発注支援方法、機器監視方法及びプログラムを提供することができる。
【発明を実施するための最良の形態】
【0010】
以下、図面に基づいて本発明の実施の形態を説明する。図1は、本発明の実施の形態における発注支援システムの構成例を示す図である。図1において、発注支援システム1は、発注支援サーバ10と、クライアントPC20と、機器30a、30b、30c、及び30d等(以下、総称する場合「機器30」という。)とを構成要素として含む。発注支援サーバ10は、発注サイト(機器30の消耗品の供給者側、例えば、機器30のメーカー)に設置されており、クライアントPC及び機器30はユーザサイト(機器30のユーザ側、例えば、オフィス等)に設置されている。発注支援サーバ10とクライアントPC20とは、インターネット等の広域ネットワークによって接続されている。また、クライアント20と機器30とは、ユーザサイトに施設されたLAN(Local Area Network)等のネットワーク(有線又は無線の別は問わない)を介して接続されている。
【0011】
機器30は、例えば、一般的なプリンタや複合機等、トナーやインク等を消耗して、画像を形成する機器(画像形成装置)である。本実施の形態において機器30は、MIB(Management Information Base)に対応しており、SNMP(Simple Network Management Protocol)に基づいてネットワークを介して受信されるMIB情報の取得要求に応答することが可能である。また、本実施の形態において機器30は、消耗品の状態情報を検知することができる。当該状態情報は、定性的(正常/ニアエンド/エンド)なものであってもよいし、定量的(100%、90%、.....10%、0%)なものであってもよい。
【0012】
クライアントPC20は、汎用的なコンピュータであり、監視プログラム21がインストールされる。監視プログラム21は、CD−ROM等の記録媒体502よりインストールされてもよいし、ネットワークを介してダウンロードされてもよい。後述するように、本実施の形態ではネットワーク40を介してダウンロードされる。
【0013】
図1において、監視プログラム21は、UIアプリ211及び監視サービス212より構成される。UIアプリ211は、監視サービス212とは別プロセスとして起動され、監視サービス212の機能に関してGUI(Graphical User Interface)を提供するアプリケーションである。UIアプリ211は、例えば、監視サービス212に対する設定情報を設定させるための画面や、監視サービス212によって取得される機器情報を表示させるための画面等を表示させる。
【0014】
監視サービス212は、デーモンプロセスとして起動されるプログラムであり、クライアントPC20のメモリにロードされCPUによって処理されることにより、クライアントPC20に以下の機能を実行させる。図2は、監視サービスがクライアントPCに実行させる機能の概要を説明するためのフローチャートである。
【0015】
クライアントPC20は、監視サービス212に基づいて、各機器30より機器情報(MIB情報)を定期的に取得する(S301)。機器情報には、機器30が使用する消耗品の状態を識別するための情報(状態情報)、例えば、トナーステータス及びトータルカウンタ値(総印刷枚数)等が含まれる。また、他の消耗品、具体的には、定着ユニット、排トナーボトル、感光体、又は現像剤等の状態を示す情報が含まれていてもよい。取得した結果、機器情報に含まれている消耗品の状態情報が定性的な情報(すなわち、正常/ニアエンド/エンド)である場合(S302で「定性情報」)、ニアエンド又はエンド情報(以下、「エンド」によって総称する)を取得すると(S303でYes)、当該消耗品の不足であると判定し(S304)、機器30の機器情報を発注支援サーバ10へ送信する(S305)。一方、機器情報を取得した結果、状態情報が定量的な情報(すなわち、100%、90%、.....10%、0%)である場合(S302で「定量情報」)、所定の閾値(30%以下)を下回っているかを調べ(S306)、下回っている場合(S306でYes)、当該消耗品の不足であると判定し(S304)、機器30の機器情報を発注支援サーバ10へ送信する(S305)。
【0016】
なお、本実施の形態では、監視装置20が消耗品の不足を検知する例について説明するが、当該検知を発注支援サーバ10に行わせてもよい。この場合、監視装置20は全ての機器30の機器情報を発注支援サーバ10に送信することになる。したがって、ネットワーク負荷の軽減という観点からは、本実施の形態のように、監視装置20において不足が検知された機器の機器情報のみを発注支援サーバ10に送信する方が好ましい。
【0017】
クライアントPC20には、また、電子メールの送受信を行うためのメーラや、Webページを閲覧するためのWebブラウザ等もインストールされている。
【0018】
発注支援サーバ10は、汎用的なコンピュータであり、Webサーバとしての機能が実装されていると共に、発注支援プログラム11がインストールされている。発注支援プログラム11は、CD−ROM等の記録媒体501よりインストールされてもよいし、ネットワークを介してダウンロードされてもよい。
【0019】
発注支援プログラム11は、発注支援サーバ10のメモリにロードされCPUによって処理されることにより、発注支援サーバ10に以下の機能を実行させる。すなわち、発注支援プログラム11に基づいて、発注支援サーバ10の電子メール作成手段は、クライアントPC20より受信される機器情報に基づいて不足している消耗品(以下「サプライ」という。)の補給を促進する電子メールを作成し、予め登録されているユーザのメールアドレスに送信する。当該電子メールには、不足していると判定されたサプライの発注用のWebページ(以下「サプライ発注ページ」という。)に対するURLが記載される。発注支援サーバ10は、また、当該URLのクリックに基づいて送信されるHTTPリクエストに応じて、サプライ発注ページを返信し、更に、サプライ発注ページに基づくサプライの発注要求を受信する。発注支援サーバ10は、サプライ発注要求に応じて、サプライの発注指示を非図示の物品発注管理システムに送信する。
【0020】
ところで、本発明者は、発注支援システム1を利用した新たなビジネスモデルの構築を検討している。まず、当該ビジネスモデルを構築するに至った背景について説明する。
【0021】
一般的に、画像形成装置の販売は、代理店や接点店等、様々な販売チャネルを介して行われる。以下、メーカーから製品(画像形成装置)を仕入れて顧客に対して直接販売を行う業者を「販売業者」という。当該販売業者には、ハードウェアとしての画像形成装置を単に販売するだけでなく、顧客に応じたソリューションを付加価値として提供し、そのソリューションの中で画像形成装置を機能させるためのSI作業等の業務を行うものも含まれる。これらの、販売業者は、ハードウェアとしての画像形成装置の販売による利益や、SI作業等に基づくソフトウェアによる利益等を主な収益原とている。
【0022】
他方において、画像形成装置は、一度販売された後でもサプライの継続的な販売によって、継続的に利益を得られるという特性があり、またその利益は、一般的に画像形成装置の販売による利益よりも大きい。しかしながら、従来、顧客(ユーザ)は、機器の購入後は販売業者を介することなく量販店や通信販売等によりサプライを購入するのが一般的であった。したがって、画像形成装置を販売した販売業者は、当該画像形成装置のサプライによる継続的な利益を得ることができなかった。
【0023】
ここで、或る販売業者がメーカーA及びメーカーBの画像形成装置の販売を行っている場合を想定する。仮に、メーカーAの画像形成装置を販売した場合は、当該画像形成装置のサプライの販売による利益が当該販売業者に還元されるとすれば、販売業者には、メーカーBの画像形成装置よりもメーカーAの画像形成装置をより多く販売したいというインセンティブが働く。その結果、メーカーAの製品を売り上げの増加を期待することができ、メーカーAは、メーカーBに対して競争上優位な差別化を図ることが期待できる。
【0024】
そこで、本発明者は、新たなビジネスモデルとして、サプライの販売による利益が販売業者に還元される仕組みを考案した。本実施の形態では、発注支援システム1を当該ビジネスモデルに適用した例について説明する。
【0025】
以下、図1の発注支援システム1の処理手順について説明する。販売業者より機器30を購入したユーザは、当該販売業者との間で発注支援システム1への登録契約を締結する。当該登録契約を結んだユーザは、図3に示されるようにまずユーザ登録を行う。なお、以下の説明から明らかになることであるが、ユーザは、発注支援システム1の利用によってサプライの補給作業にかかるコストを低減させることが期待できる。その期待が、ユーザにとって当該登録契約の締結に対するインセンティブとなる。
【0026】
図3は、発注支援システムにおけるユーザ登録時の処理手順を説明するためのシーケンス図である。なお、図3において、Webブラウザ22は、クライアントPC20にインストールされている汎用的なWebブラウザである。また、メーラ23は、クライアントPC20にインストールされている汎用的なメーラである。
【0027】
まず、ユーザは、登録契約の際に発注支援サーバ10へアクセスするためのID(以下「アクセスID」という。)と、発注支援サーバ10のURLとを販売業者より入手し、当該URLをWebブラウザ22に入力する。URLの入力に応じてアクセスIDの入力が要求され、当該アクセスIDが正当に入力されると、ユーザ登録を行うためのWebページ(以下「ユーザ登録ページ」という。)が、発注支援サーバ10よりWebブラウザ22に送信される(S11)。ユーザ登録ページを受信したWebブラウザ22は、当該ユーザ登録ページを表示させる。
【0028】
図4は、ユーザ登録ページの表示例を示す図である。図4の説明において()内の数字は、図中における参照番号に対応する。図4に示されるように、ユーザ登録ページ220においては、ユーザの氏名(221)、郵便番号(222)、住所(223)、会社名(224)、部署名(225)、電話番号(226)、FAX番号(227)、及び電子メールアドレス(228)等の基本情報の他、サプライを発注した際のサプライの配送先の郵便番号、住所、会社名、及び部署名等(231)と、販売業者ID(232)との入力が可能となっている。ここで、販売業者IDは、当該ユーザが上記登録契約を締結した相手となる販売業者のIDであり、登録契約時に販売業者より通知される。
【0029】
ユーザが、ユーザ登録ページ220において必要事項を入力し、登録ボタン233をクリックすると、Webブラウザ22は、発注支援サーバ10に対してユーザ登録を要求するHTTPリクエストを送信する(S12)。当該HTTPリクエストには、ユーザ登録ページ220への入力情報(以下、販売業者IDも含めて「ユーザ情報」という。)が含まれている。
【0030】
発注支援サーバ10の発注支援プログラム11は、HTTPリクエストが受信されると、当該HTTPリクエストに含まれているユーザ情報を所定のデータベース(以下「ユーザデータベース」という。)に登録する(S13)。ユーザ情報の登録に際し、発注支援プログラム11は、ユーザ情報に含まれている販売業者IDが発注支援サーバ10にエントリされているか否かを判定し、エントリされている場合は、当該ユーザに対するユーザID及びパスワードを生成又は採番する。更に、当該ユーザID及びパスワードをもユーザ情報に含めてユーザデータベースに登録する。
【0031】
続いて、発注支援プログラム11は、監視プログラム21のダウンロードを実行させるためのWebページ(以下「ダウンロードページ」という。)へのURLや、生成されたユーザID及びパスワード等が本文に記載された電子メール(以下、「インストール情報通知メール」という。)をユーザのメールアドレスに送信する(S14)。また、発注支援プログラム11は、インストール情報通知メールを送信した旨のメッセージを表示させるWebページを、ステップS12におけるHTTPリクエストに対するHTTPレスポンスに含めてWebブラウザ22に対して送信する。ユーザは、当該Webページによって、インストール情報通知メールが自分宛に送信されたこと知ることができる。そして、メーラ23によってインストール情報通知メールを閲覧することにより、ダウンロードページのURLや自分に対して割り有り当てられたユーザID及びパスワード等を確認することができる。
【0032】
なお、ダウンロードページのURL等の通知は、必ずしも電子メールによる必要はない。例えば、ステップS14において、インストール情報通知メールを送信した旨のメッセージを表示させるWebページではなく、ダウンロードページが返信されるようにしてもよい。但し、ステップS14のタイミングでダウンロードページが返信されてしまうと、そのままインストール作業を続行する必要があるのに対し、インストール情報通知メールによれば、当該メールの受信後ユーザの都合のいいときにインストール作業を行えるという点でユーザにとって便宜である。また、FAXや郵送によってこれらの情報が送付されるようにしてもよい。
【0033】
ユーザが、インストール情報通知メールに記載されているダウンロードページのURLをクリックすると、メーラ23は、当該URLを引数としてWebブラウザ22を起動させる。Webブラウザ22は、起動すると、当該URLに基づいてダウンロードページを表示させる。ユーザが、ダウンロードページにおいてダウンロード先のURLをクリックすると、Webブラウザ22は、発注支援サーバ10に対して、監視プログラム21のダウンロード要求を送信する(S15)。発注支援プログラム11は、当該要求に応じ、発注支援サーバ10に保存されている監視プログラム21のインストールパッケージをクライアントPC20に転送する(S16)。
【0034】
ユーザは、ダウンロードされたインストールパッケージに含まれているインストーラ25を起動する(S17)。インストーラ25は、起動されるとユーザに対してインストール情報通知メールにおいて通知されたユーザID及びパスワード等の入力を要求する。ユーザがユーザID及びパスワード等を入力すると、インストーラ25は、入力されたユーザID及びパスワードを発注支援サーバ10に送信し、ユーザの認証を要求する(S18)。なお、入力されたユーザID及びパスワードは、クライアントPC20においても保存され、管理される。
【0035】
発注支援プログラム11は、インストーラ25より送信されたユーザID及びパスワードと、ユーザデータベースに登録されているユーザID及びパスワードとを照合することによりユーザの認証を行う(S19)。発注支援プログラム11は、認証結果を監視プログラム21に返信する(S20)。インストーラ25は、認証が成功した場合のみ監視プログラム21のインストールを実行し(S21)、認証が失敗した場合はインストールを中止する。
【0036】
ユーザが認証された場合のみインストールを実行することで、例えば、インストールパッケージを不正に入手したユーザによるインストールを防止することができる。監視プログラム21は、ネットワークを介して発注支援プログラム11と通信を行うものである。したがって、不正ユーザによる監視プログラム21の利用を防止し、発注支援サーバ10に対するネットワークを介した攻撃を抑止するためにも、インストール時のユーザ認証は効果的である。
【0037】
インストールが正常に行われると、監視プログラム21の監視サービス212は、クライアントPC20上で動作を開始する。まず、監視サービス212はネットワーク50に接続されている機器30を検索し(S22)、検索された全ての機器30の情報(例えば、機器のシリアル番号、MACアドレス、機種(モデル)名、ベンダ名(機器メーカーの名前)等を含む情報。以下「検索機器情報」という。)を、発注支援サーバ10に送信する(S23)。なお、ネットワーク50上における機器30の検索及び検索機器情報の取得は、周知の技術を用いて行うことが可能である。
【0038】
発注支援プログラム11は、受信された検索機器情報を所定のデータベース(以下「機器データベース」という。)に登録する(S24)。
【0039】
図5は、機器データベースを構成する機器情報テーブルの構成例を示す図である。図5に示されるように機器情報テーブル12は、検索された機器30ごとにMACアドレス、ベンダ名、機種名、シリアル番号、監視フラグ、備考、サプライのステータス、及びメールフラグ等が登録され、管理されるテーブルである。MACアドレス、ベンダ名、機種名、及びシリアル番号は、検索機器情報に含まれているものがそのまま登録される。その他IPアドレス等も登録されるが、図中では便宜上省略されている。
【0040】
監視フラグは、監視サービス212の監視対象とされているか否かを示すフラグ情報であり、監視対象の場合は「Yes」、監視対象でない場合は「No」が登録される。なお、初期値としては「Yes」が登録される。但し、初期値はNULL(空)値であってもよい。備考は、ユーザの任意によって機器に関連付けておきたい情報が登録される項目である。
【0041】
サプライのステータスは、サプライのステータスを識別するための情報が登録される項目である。本実施の形態では、N(Normal)、Ne(Near End)、又はE(End)が登録されることとする。初期値としては「N」であってもよいし、NULL値であってもよい。メールフラグについては後述する。
【0042】
続いて、発注支援プログラム11は、検索機器情報の一覧を表示させるWebページ(以下「検索機器一覧ページ」という。)のURLを監視サービス212へ送信する(S25)。監視サービス212は、受信したURLを引数としてWebブラウザ22を起動させる(S26)。Webブラウザ22は、起動すると、引数に指定されたURLに基づいて検索機器一覧ページを要求するHTTPリクエストを発注支援サーバ10に送信する(S27)。発注支援プログラム11は、受信されたHTTPリクエストに応じ、機器情報テーブル12に登録されている情報に基づいて検索機器情報一覧ページを生成し、当該検索機器情報一覧ページをWebブラウザ22に返信する(S28)。
【0043】
図6は、検索機器一覧ページの表示例を示す図である。図6の説明において()内の数字は、図中における参照番号に対応する。図6に示されるように、検索機器一覧ページ240には、検索された機器30ごとに、シリアル番号、MACアドレス、IPアドレス、モデル名、及びベンダ名等が表示される。検索機器一覧ページ240には更に、機器30ごとに、備考を入力させるための欄(241)と、監視サービス212による監視対象とするか否か(監視の要否)を選択させるためのチェックボタン(242)とが設けられている。すなわち、ユーザは、検索機器一覧ページ240において、機器30ごとに備考の入力と監視対象とするか否かの選択とを行う。本実施の形態では、チェックボタンがチェックされた場合に、監視対象として選択されたものとする。備考欄241には、ユーザの任意によって自由な情報の入力が可能であるが、例えば、機器30の配置場所等、サプライの交換作業の補助となるような情報を入力しておくとよい。
【0044】
ユーザが、検索機器一覧ページ240において、各機器30について備考の入力と、監視の要否の選択とを行い、送信ボタン243をクリックすると、Webブラウザ22は、各機器30の備考と監視の要否との登録を要求するHTTPリクエストを発注支援サーバ10に送信する(S29)。発注支援プログラム11は、受信されたHTTPリクエストに基づき、各機器30の備考と監視の要否とを機器情報テーブル12に追加登録する(S30)。すなわち、機器情報テーブル12の「監視フラグ」については、監視対象とされた機器については「Yes」が登録され、監視対象とされなかった機器については「No」が登録される。
【0045】
図7は、監視の要否及び備考が登録された機器情報テーブルの例を示す図である。図7の機器情報テーブル12では、1行目のエントリの備考に「大森4F」といったような配置情報が登録された例が示されている。また監視フラグについては、1〜4行目のエントリに係る機器が監視対象とされ、5〜7行目のエントリに係る機器が監視対象から除かれた例が示されている
以上で、ユーザ登録時の処理は終了する。なお、監視プログラム21は、インストール時以外にも、例えばユーザのメニュー選択によって機器検索情報の登録、検索機器一覧ページの表示をさせ、監視対象機器を追加させるようにしてもよい。
【0046】
監視サービス212は、その後もネットワーク50に接続されている機器30の検索を自動的かつ繰り返し(例えば、定期的に)行う(S31)。監視サービス212は、検索された機器の検索機器情報を発注支援サーバ10に送信する(S32)。発注支援プログラム11は、受信された検索機器情報に基づいて、機器情報テーブル12を更新する(S33)。ネットワーク50の構成が定期的に検査され、その検査結果に基づいて機器情報テーブル12が更新されることで、機器情報テーブル12の内容とネットワーク50の構成との間にずれが発生する可能性を低くすることができる。
【0047】
ステップS33において実行される機器情報テーブルの更新処理の詳細について説明する。図8は、発注支援プログラムによる機器情報テーブルの更新処理を説明するためのフローチャートである。検索機器情報を受信すると発注支援プログラム11は、検索機器情報と共に監視サービス212より送信されるユーザID及びパスワードに基づいてユーザの認証を行う(S331)。ユーザが認証された場合(S331でYes)、検索機器情報に含まれている機器ごとにステップS332以降の処理を行う。
【0048】
まず、一つの機器を処理対象とし(以下、処理対象とされた機器を「カレント機器」という。)(S333)、カレント機器が新たに検索された機器(以下「新規機器」という。)であるか否かを判定する(S334)。この判定は、カレント機器のMACアドレスをキーとして、機器情報テーブル12に当該MACアドレスを有するエントリが有るか否かによって行う。当該エントリが無ければカレント機器は新規機器であると判定される。
【0049】
カレント機器は新規機器であると判定した場合(S334でYes)、カレント機器のエントリを機器情報テーブル12に登録する(S335)。この際、カレント機器は監視対象とする。すなわち、新たに追加されたエントリの監視フラグに「Yes」を登録する。自動的な処理においては、新規機器を監視対象とするか否かについてユーザ問い合わせる適切なタイミングがないため、発注支援プログラム11が自動的に監視フラグを「Yes」とするのである。ここで、「No」ではなく「Yes」とするのは、ユーザは、ネットワーク50に接続されている機器30のサプライを監視させたいからこそ監視プログラム21をインストールしているのであり、かかるユーザの意図に基づけば、新規機器はデフォルトで監視対象とされるのが妥当であると考えられるからである。また、発注サイト側にとっても、できるだけ多くの機器を監視対象とすることで、サプライの販売促進等を期待できるからである。
【0050】
一方、カレント機器のMACアドレスを有するエントリが既に存在した場合(S334でNo)、当該エントリのベンダ名及び機種名が、カレント機器のベンダ名及び機種名と一致するか否かを判定する(S336)。この判定は、MACアドレスの一致だけでは必ずしも機器の同一性は保証されないことに基づく。すなわち、MACアドレスがネットワークカードから取得されるタイプの機器も存在し得るところ、当該ネットワークカードが他の機器に差し替えられてしまう可能性があるため、MACアドレスによる機器の識別は必ずしも完全なものでないからである。
【0051】
カレント機器のMACアドレスと一致するエントリについて、ベンダ名及び機種名の少なくともいずれか一方が一致しない場合、当該エントリの一致しない部分を更新し、更に、監視フラグを「Yes」とする。例えば、図9は、機種名が一致しないエントリが存在した場合の機器情報テーブルの更新例を示す図である。
【0052】
図9では、5行目のエントリの機種名が一致しなかった場合の更新例が示されている。すなわち、5行目のエントリの機種名が、カレント機器の検索機器情報に含まれている機種名に変更され、更に、監視フラグが「Yes」とされている。監視フラグが「Yes」とされるのは、このような機器は新機器として扱うのが妥当であると考えるからである。
【0053】
一方、カレント機器のMACアドレスに有するエントリが既に存在した場合であって(S334でNo)、当該エントリのベンダ名及び機種名が、カレント機器のベンダ名及び機種名と一致する場合(S335でNo)、カレント機器は既に当該エントリに登録されている機器であると判定する。但し、カレント機器の一部の属性(例えば、シリアル番号等)に変更がある場合は、当該エントリにおける当該一部の属性に対応する項目を更新する(S338)。但し、監視フラグは変更しない。すんわち、「No」であってもそのままとする。「No」とされている監視フラグを自動的に変更してしまうことは、意識的に当該機器を監視対象から除いたユーザの意図に反することになるからである。
【0054】
ステップS333〜S338までの処理が検索機器情報に含まれる全ての機器について完了すると(S332でYes)、検索機器情報の登録が成功した旨を監視サービス212に返信し(S340)、処理を終了する。なお、ユーザ認証に失敗した場合は(S331でNo)、機器情報テーブル12の更新は行わず、エラー情報を監視サービス212に返信する(S339)。
【0055】
次に、クライアントPC20にインストールされた監視プログラム21(監視サービス212)によって機器30の状態の監視が行われる際の発注支援システム1の処理手順について説明する。図10は、発注支援システムにおける機器監視時の処理手順を説明するためのシーケンス図である。
【0056】
監視サービス212は、繰り返し(例えば、定期的に)訪れる機器状態監視時間になると、発注支援サーバ11に監視対象となっている機器30(以下、「監視機器」という。)のリストを問い合わせる(S101)。発注支援プログラム11は、機器情報テーブル12の監視フラグに基づいて監視機器をリストアップし、リストアップされた監視機器の登録情報の一覧(監視機器リスト)を監視サービス212に返信する(S102)。なお、監視サービス212は、機器状態監視時間以外にも、例えばユーザのメニュー選択によって機器監視を行うようにしてもよい。このように、監視サービス212側では、各機器が監視対象であるか否かについては自ら管理せず、発注支援サーバ11側に問い合わせることで監視機器を識別する。かかる構成により監視サービス212の実装を簡便化させることができ、処理負荷を低減させることができる。
【0057】
監視サービス212は、監視機器リストを受信すると、当該監視機器リストに基づいてキャッシュテーブルを更新する(S103)。ここでキャッシュテーブルとは、監視サービス212が監視機器のサプライのステータス等を管理するためのテーブルであり、例えば、クライアントPC20のメモリ上に構築される。
【0058】
図11は、キャッシュテーブルの構成例を示す図である。図11に示されるように、キャッシュテーブル27は、監視機器ごとにMACアドレス、ベンダ名、機種名、シリアル番号、備考、監視情報、サプライステータス、及び通知フラグ等が登録及び保持されるテーブルである。ステップS103では、受信された監視機器リストに基づいて、MACアドレス、ベンダ名、機種名、シリアル番号、及び備考が登録又は更新される。例えば、受信された監視機器リストに含まれている監視機器と同一のMACアドレスに係るエントリがキャッシュテーブル27に存在しない場合、監視サービス212は、当該監視機器に係るエントリをキャッシュテーブル27に新たに追加する。また、同一のMACアドレスに係るエントリは存在するが、他の情報(ベンダ名、機種名、シリアル番号又は備考)が異なる場合、当該エントリについて当該異なる情報を更新する。また、監視機器リストに含まれていないMACアドレスを有するエントリがキャッシュテーブル27に存在する場合、監視サービス212は、当該エントリを削除する。すなわち、キャッシュテーブル27は、現時点において監視機器とされている機器についてのみエントリを保持する。なお、キャッシュテーブル27において、監視情報、サプライステータス、及び通知フラグについては、後述の処理によって更新される項目であり、その内容についてはその都度説明する。
【0059】
続いて、監視サービス212は、キャッシュテーブル27にエントリされている機器30(監視機器)に対して機器情報としてのMIB情報をSNMPに基づいて問い合わせる(S104)。問い合わせ対象となるMIB情報としては、少なくともトナーのステータス情報が含まれ、また、他のサプライのステータス情報が含まれていてもよい。各機器30は、問い合わせ対象とされたMIB情報を監視サービス212に対して返信する(S105)。
【0060】
なお、本発明の実施にあたり、機器情報は必ずしもMIB情報に限定されず、機器情報を問い合わせるためのプロトコルはSNMPに限定されないが、標準化された技術を用いることにより、各機器30のベンダが異なっていても、同じ手順によって機器情報の取得が可能であるという観点より、MIBやSNMP等の標準技術に基づくのが好適である。
【0061】
全ての監視機器からの機器情報の取得(ポーリング)が完了すると、監視サービス212は、当該機器情報に基づいて、キャッシュテーブル27の監視状態、サプライステータス、及び通知フラグを更新する(S106)。監視状態については、機器情報の取得に成功した機器に係るエントリについては「OK」を登録し、失敗した機器に係るエントリについては「NG」を登録する。また、サプライステータスについては、取得された機器情報に含まれているトナーステータス等、サプライの状態情報が登録される。通知フラグには、サプライステータスの値が変化した場合、「未通知」が登録される。すなわち、監視サービス212は、更新前のキャッシュテーブル27に登録されているサプライステータスと、新たに取得された機器情報に含まれているサプライのステータス情報とを比較することによりサプライの状態の変化を検知し、状態の変化が検知されたサプライについて、キャッシュテーブル27におけるエントリの通知フラグを「未通知」とする。なお、通知フラグは、サプライの状態変化が発注支援プログラム11に通知済みか否かを判別するために用いられる。
【0062】
図12は、機器情報のポーリング結果に基づくキャッシュテーブルの更新例を示す図である。図12は、図11の状態からの更新例を示す。すなわち、一行目のエントリに関しては、サプライステータスが「normal」(不足していない状態)から「near end」(ニアエンド)に変化している。したがって、通知フラグの値は「未通知」に更新されている。同様に、四行目のエントリに関してもサプライステータスが「near end」から「end」(エンド)に変化しているため、通知フラグの値は「未通知」に更新されている。一方、三行目及び五行目のエントリは、サプライステータスは変化していないため、通知フラグの値も更新されていない。また、二行目のエントリは、監視状態が「NG」とされている。当該エントリに係る機器30からの機器情報の取得に失敗したためである。この場合、サプライステータス及び通知フラグの値は更新されない。
【0063】
続いて、監視サービス212は、更新されたキャッシュテーブル27に基づいて、状態変化通知情報を生成する(S107)。監視サービス212は、キャッシュテーブル27において通知フラグの値が「未通知」のエントリに係る機器に関して状態変化通知情報を生成する。したがって、図12のキャッシュテーブル27に基づけば、一行目、三行目及び四行目のエントリに係る機器に関して状態変化通知情報が生成される。
【0064】
図13は、状態変化通知情報の構成例を示す図である。図13において、状態変化通知情報は、ヘッダ情報と機器情報とから構成される。
【0065】
ヘッダ情報は、日時、ユーザID、及びパスワード等を含む。日時は、機器情報を転送する日時である。ユーザID及びパスワードは、監視プログラム21のインストール時に入力され、保存されているユーザID及びパスワードである。すなわち、ヘッダ情報は、機器30より取得された情報ではない。
【0066】
機器情報は、上記における機器情報と同義である。すなわち、機器30よりMIB情報として取得された情報であり、当該機器30のベンダ名、機種名(モデル名)、シリアル番号、MACアドレス、IPアドレス、トナーID(トナーボトルを特定するための情報、カラーであれば、トナーIDは各色ごとに付与され、モノクロであれば1個付与される)、トナー名称、トナーステータス、トナーレベル、トナー名(文字列)、トナー名(Code)、及びトータルカウンタ値等を含む。これらは、public MIB(標準MIB)として定義されているものであり、ベンダを問わずいずれの機器からも取得可能な情報である。
【0067】
トナーステータスは、トナーの状態を示す情報である。また、トータルカウンタ値は、総印刷枚数を示す情報である。したがって、監視サービス212は、トナーステータスによってトナーエンドを検知する。また、トータルカウント値によって、感光体、定着ユニット、及び現像剤等の消耗度を判定する。但し、標準MIBにおけるトナーステータスでは、エンドとなったトナーの色までは特定することはできない。
【0068】
そこで、本実施の形態における機器情報は、更に、モノクロカウンタ値、カラーカウンタ値、シアンカウンタ値、マゼンタカウンタ値、ブラックカウンタ値、及びレッドカウンタ値等をも含む。これらは、private MIB(拡張MIB)としてベンダ独自に定義されているものである。
【0069】
例えば、本実施の形態では、メーカーAの機器30のみがこれらの拡張MIBに対応しているとすれば、メーカーAの機器30についての機器情報にはこれらの値が格納されるが、メーカーA以外の機器30についての機器情報ではこれらの値は空となる。
【0070】
例えば、モノクロカウンタ値は、モノクロ印刷による印刷枚数である。カラーカウンタ値は、カラー印刷による印刷枚数である。また、シアンカウンタ値、マゼンタカウンタ値、ブラックカウンタ値、及びレッドカウンタ値は、それぞれの色のトナーを使用した印刷枚数である。したがって、メーカーAの機器30であれば、色ごとにそのエンドを検知することが可能となる。
【0071】
なお、図12等に示されるキャッシュテーブル27では、便宜上監視機器ごとに一つのエントリが割り当てられているが、複数のサプライの状態について(例えば、CMYKそれぞれのトナーステータスやトータルカウンタ値等について)管理する場合は、当該サプライごとにエントリを割り当てればよい。また、状態変化通知情報に含める情報は、図13に示され得ものに限定されず、必要に応じて、適宜決定すればよい。
【0072】
続いて、監視サービス212は、生成された状態変化通知情報を発注支援プログラム11に送信する(S108)。なお、状態変化通知情報は、各機器のものが同時に(一つのメッセージにまとめられて)送信されるのが通信負荷の低減の観点より好ましい。機器ごとに別個のメッセージとして送信される場合に比べ、オーバーヘッドを低下させることができるからである。
【0073】
状態変化通知情報を受信した発注支援プログラム11は、状態変化通知情報に基づく機器情報テーブルの更新や、サプライが不足している機器の判定等の処理を行う(S109)。なお、当該ステップにおける処理の詳細については後述する。
【0074】
続いて、発注支援プログラム11は、不足しているサプライの発注用のWebページ(以下「発注ページ」という。)を生成し、当該サプライが不足していることを通知する電子メール(以下「不足通知メール」という。)を作成し、ユーザのメールアドレスに対して送信する(S110)。不足通知メールには、発注ページのURLが記載される。なお、各不足通知メールには、IDが付与され(以下「メールID」という。)、メールIDと共に、当該不足通知メールの対象とされた機器30のシリアル番号等の機器30を識別するための情報と、ユーザID又はメールアドレス等ユーザを識別するための情報と、送信日時等とが不足通知メールの送信履歴として保存される。
【0075】
図14は、不足通知メールの例を示す図である。図14に示される不足通知メール250において、<>で囲まれた文字列は具体的な値ではなく、当該個所に記述される情報の内容を示す。
【0076】
図14に示されるように、不足通知メール250の宛先には、状態変化通知情報に係るユーザのメールアドレスが指定される。当該該ユーザのメールアドレスの特定は、状態変化通知情報に含まれているユーザID及びパスワードをキーとして、ユーザデータベースより検索すればよい。ユーザデータベースには、ユーザ登録時において、ユーザID及びパスワードと共にメールアドレスが登録されているからである。
【0077】
不足通知メール250のタイトルには、当該メールが不足通知メールであることを示すタイトルが記載される。不足通知メール250の本文には、状態変化通知情報に係る機器に関する情報、不足しているサプライに関する情報、発注ページのURL等が記載される。
【0078】
機器に関する情報は、当該機器のベンダ名、モデル名、及び備考等が含まれる。これらの情報は、状態変化通知情報に含まれているシリアル番号、MACアドレス又はIPアドレス等をキーとして、機器データベースより取得すればよい。また、不足しているサプライに関する情報は、例えば、当該サプライがトナーである場合は、状態変化通知情報に含まれているトナーステータス、トナーID、トナー名称等が記載される。なお、一つの機器30において複数のサプライが同時に不足した場合は、一つの不足通知メール250内に当該複数のサプライの不足を示す情報を含むメールを作成し、当該複数のサプライの不足が通知される。
【0079】
不足通知メール250の送信後、発注支援プログラム11は、状態変化通知情報の受信(S108)に応じた一連の処理(不足通知メール250の送信等)の処理結果を監視サービス212に返信する(S111)。監視サービス212は、当該処理結果が、処理の正常終了を示している場合(すなわち、状態変化通知情報が正常に処理された場合)は、キャッシュテーブル27の通知フラグについて、「未通知」を「通知済み」に更新する(S112)。
【0080】
図15は、状態変化通知情報が正常に処理された際のキャッシュテーブルの更新例を示す図である。図15は、図12からの更新例を示す。図15のキャッシュテーブル27では、一行目、三行目及び四行目のエントリの通知フラグが、「未通知」から「通知済み」に更新されている。通知フラグの値がこのように更新されることにより、正常に処理されたサプライの状態変化について、二重に状態変化通知情報が送信されるのを抑止することができる。したがって、通信量を削減することができ、ひいては不足通知メール250の二重送信を抑止することもできる。
【0081】
クライアントPC20におけるメーラ23によって不足通知メール250を閲覧したユーザは、印刷等を実行していないときでも、サプライの不足を認識することができる。また、備考として機器30の配置場所等を入力しておけば、当該情報によって機器30の配置場所の特定等を容易に行うことができる。
【0082】
ユーザが、不足通知メール250に記載されている発注ページのURLをクリックすると、メーラ23は、クリックされたURLを引数としてWebブラウザ22を起動させる。Webブラウザ22は、起動すると、引数に指定されたURLに基づいて発注ページを要求するHTTPリクエストを発注支援サーバ10に送信する(S113)。発注支援プログラム11は、受信されたHTTPリクエストに応じ、発注ページをWebブラウザ22に返信する(S114)。Webブラウザ22は、受信した発注ページを表示させる。
【0083】
図16は、発注ページの表示例を示す図である。図16において、発注ページ260には、領域261においてサプライが不足している機器に関する情報(メーカー(ベンダ)名、モデル名、シリアル番号、備考(配置位置)が表示されている。また、領域262において、不足しているサプライの名称が表示されている。また、領域262では、当該機器に対応した各種サプライの一覧が表示され、それぞれの発注が可能となっている。すなわち、サプライごとに、その商品名(名称)が表示され、購入する数量の入力が可能とされている。なお、参照番号2621に示されるように、不足しているサプライについては予め必要な数量が入力されて表示されている。また、各商品名には、当該商品の概要説明を表示するWebページへのリンクが張られている。更に、領域263では、当該ユーザの過去の購入履歴が表示される。これによって、ユーザが重複して購入してしまうことを防止することができる。
【0084】
なお、購入履歴は、ユーザデータベースにユーザごとに登録されている。すなわち、発注ページ260を介して商品の発注が行われると、発注された商品の情報がユーザデータベースに追加登録される。
【0085】
ところで、図16の発注ページ260では、イエローのトナーが不足している旨が通知されている。上述したように、標準MIBだけでは、不足しているトナーの色は特定できない。したがって、図16の発注ページ260には、拡張MIBに登録されている情報に基づいて判定された結果が示されている。このように、発注支援システム1を展開するメーカーは、自らが定義した拡張MIBによって、発注支援システム1上のサービスにおいて、他社と差別化を図ることができる。すなわち、仮に、他社の機器30のトナーエンドが検知された場合は、発注ページ260にはその色までは特定されて通知されない。なお、他社の機器30のサプライについては、そもそも発注支援システム1による発注対象から除外するということも考えられるが、ユーザの利便性を考慮し、本実施の形態では、他社の機器30のサプライの発注も可能としている。
【0086】
発注ページ260において、ユーザが注文ボタン2622をクリックすると、Webブラウザ22は、商品の発注を要求するHTTPリクエストを発注支援サーバ10に送信する(S115)。
【0087】
HTTPリクエストに応じ、発注支援プログラム11は、当該ユーザと関連付いている販売業者に対して当該発注要求に基づく利益の一部を供与するための情報を記録する(S116)。具体的には、発注業者ごとに、発注支援システム1によるサプライの売り上げを管理するデータベース(以下「販売業者データベース」という。)が構築されており、当該販売業者データベースの売り上げに、今回の発注による注文の内容(例えば、注文金額)が記録される。なお、販売業者は、メーカーとの間で発注支援システム1への参加契約を締結することにより、販売業者データベースへのエントリが作成される。また、販売業者IDが与えられ、当該販売業者は、発注支援システム1上において、当該販売業者IDによって識別される。なお、ステップS116において、受信されるHTTPリクエストに係るユーザの識別は、例えば、Webブラウザ22とのセッションIDとユーザIDとを関連付けておき、その関連付けに基づいて、セッションIDよりユーザIDを特定することにより行えばよい。
【0088】
発注支援プログラム11は、更に、当該発注の指示を物品発注管理システムに指示する。この指示には、ユーザデータベースに登録されている配送先の情報が含まれている。物品発注支援システムに発注が指示されることにより、発注された商品は、実際にユーザの元に配送される。更に、ユーザから購入代金支払われると、販売業者データベースに、今回の発注による売り上げが確定したことが記録される。売り上げか確定することにより、当該販売業者には、売り上げに応じて販売促進金などの手当をメーカーから供与してもよい。
【0089】
続いて、図10におけるステップS109の処理の詳細について説明する。図17は、発注支援プログラムによる状態変化通知情報に基づく処理を説明するためのフローチャートである。
【0090】
状態変化通知情報を受信すると、発注支援プログラム11は、状態変化通知情報と共に監視サービス212より送信されるユーザID及びパスワードに基づいてユーザの認証を行う(S401)。ユーザが認証された場合(S401でYes)、状態変化通知情報が受信された機器ごとにステップS402以降の処理を行う。
【0091】
まず、一つの機器を処理対象とし(以下、処理対象とされた機器を「カレント機器」という。)(S403)、カレント機器は機器情報テーブル12に登録されているか否かを判定する(S404)。この判定は、カレント機器のMACアドレスをキーとして、機器情報テーブル12に当該MACアドレスを有するエントリが有るか否かによって行えばよい。カレント機器が未登録である場合(S404でNo)、カレント機器のエントリを機器情報テーブル12に登録する(S405)。この際、カレント機器は監視対象とする。なお、MACアドレスに基づいてカレント機器が登録されていると判断された場合、図8のS336〜S338において説明したような処理を行ってもよい。
【0092】
続いて、状態変化通知情報に含まれているカレント機器のサプライのステータス情報を機器情報テーブル12のステータスに反映(転記)する(S406)。続いて、機器情報テーブル12に登録されているカレント機器のステータスに基づいて、カレント機器について不足していているサプライ(すなわち、ステータスが「Ne」(ニアエンド)又は「E」(エンド)のサプライ)の有無を判定する(S407)。不足しているサプライが存在する場合(S407でYes)、機器情報テーブル12においてカレント機器に係るエントリ(以下「カレントエントリ」という。)のメールフラグの値は「Yes」であるか否かを判定する(S408)。ここで、メールフラグは、不足通知メール250が送信された場合に「Yes」とされるフラグである。すなわち、メールフラグの値が「Yes」であるということは、過去にカレント機器について不足通知メール250が送信されたことがあることを意味する。
【0093】
メールフラグが「Yes」の場合(S408でYes)、不足通知メール250の重複送信チェックを行う(S409)。ここで、重複送信チェックとは、同じ内容の不足通知メール250が送信された可能性の有無を判定するための処理であり、その処理内容の詳細については後述する。重複送信チェックにおいて、重複送信の可能性は低く不足通知メール250は送信すると判定された場合(S409で「送信する」)、メールフラグを「Yes」とし(S410)、カレント機器に関する不足通知メール250を送信する(S411)。この処理は、図10におけるステップS110に相当する。なお、ステップS407において、不足しているサプライが複数検知された場合は、当該複数のサプライについてまとめて一つの不足通知メール250が送信される。したがって、ユーザに送信される不足通知メール250の数を少なくすることができ、ユーザに与える煩雑さ等を低減させることができる。
【0094】
また、重複送信チェックにおいて、重複送信の可能性が高く不足通知メール250は送信しないと判定された場合は(S409で「送信しない」)、不足通知メールは送信せずにカレント機器に関する処理を終了する。
【0095】
一方、メールフラグが「No」の場合(S408でYes)、不足通知メール250の重複のおそれはないため、重複送信チェックは行わず、メールフラグを「Yes」とし(S410)、不足通知メールを送信する(S411)。
【0096】
また、S407において、カレント機器についていずれのサプライも不足していないと判定された場合、この場合は不足通知メールは送信する必要はないため、メールフラグを「No」とし、不足通知メールは送信せずにカレント機器に関する処理を終了する。
【0097】
ステップS403〜S412までの処理が状態変化通知情報の受信された全ての機器について完了すると(S402でYes)、状態変化通知情報が正常に処理されたことを監視サービス212に返信し(S414)、処理を終了する。この処理は、図10におけるステップS111に相当する。なお、ユーザ認証に失敗した場合は(S401でNo)、機器情報テーブル12の更新は行わず、エラー情報を監視サービス212に返信する(S413)。
【0098】
続いて、図17におけるステップS409の不足通知メールの重複送信チェックの詳細について説明する。図18は、不足通知メールの重複送信チェック処理を説明するための図である。当該処理の意義について説明する。
【0099】
監視サービス212は、キャッシュテーブル27の通知フラグに基づいて状態変化通知情報を送信するため、監視サービス212は、基本的には二重に同一の状態変化通知情報を送信することはない。しかしながら、例えば、トナーについては、トナーボトルの中にまだトナーが残っている場合にトナーエンドが検知される場合がある。このような場合、ユーザがトナーボトルを振った後に当該トナーボトルを取り付けると、しばらくしてから改めて同一のトナーについてトナーエンドが検知されてしまうことが考えられる。このような場合、通知フラグは、「end」から「normal」に変化し、再び「end」に変化するため、同一のトナーボトルが交換されていないにもかかわらず、監視サービス212は、再度トナーエンドを通知するための状態変化通知情報を送信してしまうことが考えられる。そうすると、ユーザに対して不足通知が重複して送信されてしまい、ユーザが重複に気付かなければ、重複した発注を行ってしまうということが考えられる。そこで、かかる事態の発生を回避するため、発注支援プログラム11は、以下の処理を行う。
【0100】
まず、監視サービス212より受信した状態変化通知情報に含まれている、機器30のシリアル番号に基づいて、不足通知メールの送信履歴より当該機器30に関して最後(前回)に送信した不足通知メールの日時をチェックする(S201)。
【0101】
送信履歴の中に、当該機器30に対する不足通知メールの送信記録が含まれていない場合(S202でYes)、不足通知メールを送信すると判定する(S203)。当該機器30に関しては、今までに不足通知メールを送信したことはなく、したがって、不足通知メールが重複するおそれはないからである。
【0102】
送信履歴の中に、当該機器30に対する不足通知メールの送信記録が含まれている場合(S202でNo)、最後に送信した不足通知メールの送信日時から所定期間が経過している否かを判定する(S204)。所定期間が経過していれば不足通知メールは送信すると判定し(S203)、経過していなければ重複のおそれがあるとして不足通知メールは送信しないと判定する(S205)。
【0103】
なお、図18では、時間の経過に基づいて判定する例を示したが、例えば、送信履歴としてトータルカウンタを記録しておき、トータルカウンタの差分が所定の閾値以下の場合であれば、不足通知メールを送信しないようにしてもよい。また、送信履歴を一定時間ごとに全て削除するようにし、送信履歴の中に同一の機器30に対する不足通知メールの送信記録が含まれている場合は、不足通知メールを送信しないようにしてもよい。
【0104】
次に、監視プログラム21におけるUIアプリ211の機能について説明する。UIアプリ211は、監視サービス212に対する設定情報(例えば、機器情報を取得する周期)を設定させるための画面(以下「設定画面」という。)や、監視サービス212による機器の監視情報を表示させるための画面(以下「監視画面」という。)等を表示させるプログラムである。
【0105】
UIアプリ211は、ユーザからの指示に応じ、例えば次のような設定画面を表示させる。図19は、設定画面の表示例を示す図である。図19の設定画面220では、監視サービス212が監視機器より機器情報をポーリングする周期(参照番号221)と、ネットワーク50上の機器を自動検索する周期(参照番号222)との設定を行うことができる。前者は、図10のステップS104を実行する周期である。後者は、図3のステップS31を実行する周期である。なお、後者については、チェックボックス223において、設定値を無効とすることもできる。すなわち、チェックボックス223のチェックがはずされると、機器30の自動検索は行われない。
【0106】
また、UIアプリ211は、ユーザからの指示に応じ、例えば次のような監視画面を表示させる。図20は、監視画面の表示例を示す図である。図20の監視画面230は、UIアプリ211が、キャッシュテーブル27より取得した情報を表示させる画面である。したがって、キャッシュテーブル27において管理されている情報、すなわち、監視機器ごとに、ベンダ名、機種名、シリアル番号、サプライステータス、及び備考等を表示させる。監視画面230によって、ユーザは任意のタイミングで各監視機器のサプライの状態等を確認することができる。なお、参照番号231で示される「?」マークは、当該マークが付されている機器については機器情報のポーリングに失敗したことを示す。例えば、当該機器が起動されていないような場合や、ネットワーク50から切断された場合等にかかる状態が発生し得る。
【0107】
上述したように、本発明の実施の形態における発注支援システム1によれば、機器30のユーザ(顧客)、販売業者、及びメーカーの三者のそれぞれに対して、利便性又は有益性を提供することができる。
【0108】
すなわち、機器30のサプライの不足が自動的に検知され、不足通知メールがユーザの端末に自動的に送信される。その結果、ユーザは、不足通知メールに記載されているURLをクリックすることで発注ページ260を表示させることができ、発注ページ260によって不足しているサプライを簡便に発注することができる。したがって、ユーザ自らが機器30に対応したサプライを特定したり、量販店に買い出しに行ったりするための手間を省くことができ、サプライの調達コストを低減させることができる。
【0109】
また、販売業者については、サプライによる収益の一部を獲得することができ、その収益源を拡大することができる。
【0110】
また、メーカーについては、販売業者に当該メーカーの機器を他社の機器より優先させて販売したいというインセンティブや、ユーザに当該メーカーの機器を購入したいというインセンティブを与えることができる。すなわち、発注支援システム1を介して販売されたサプライが当該メーカー製のものである場合は他社のサプライが販売された場合よりも還元率を高くしたり、又は、他社のサプライの場合は還元率を0としたりすれば、販売業者にとっては、当該メーカーの製品を販売した方が、サプライの販売による利益を多く享受できるからである。また、ユーザにとっては、当該メーカーの機器を購入すれば、例えば、不足したトナーの色の特定まで可能であるといった、きめ細かいサービスを受けられるという期待を与えることができるからである。
【0111】
更に、メーカーは、ユーザの機器情報を蓄積することによって、各機器30の使用期間等をある程度推測することができる。その結果、買い換えの促進等、新たな販売活動への連携を効果的に行うことができる。
【0112】
なお、上記実施の形態では、ユーザとの間で発注支援システム1の登録契約を締結するのは機器を販売する業者である場合を例として説明したが、必ずしも、ユーザと当該登録契約を締結する相手側は、機器を販売した者に限定されない。機器は販売していない業者であっても、メーカーから発注支援システム1における販売業者IDが与えられるようにしてもよい。この場合、当該業者は、機器の販売とは関係なく、発注支援システム1を介したサプライの販売による利益の還元を受けることができる。
【0113】
以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【0114】
【図1】本発明の実施の形態における発注支援システムの構成例を示す図である。
【図2】監視サービスがクライアントPCに実行させる機能の概要を説明するためのフローチャートである。
【図3】発注支援システムにおけるユーザ登録時の処理手順を説明するためのシーケンス図である。
【図4】ユーザ登録ページの表示例を示す図である。
【図5】機器データベースを構成する機器情報テーブルの構成例を示す図である。
【図6】検索機器一覧ページの表示例を示す図である。
【図7】監視の要否及び備考が登録された機器情報テーブルの例を示す図である。
【図8】発注支援プログラムによる機器情報テーブルの更新処理を説明するためのフローチャートである。
【図9】機種名が一致しないエントリが存在した場合の機器情報テーブルの更新例を示す図である。
【図10】発注支援システムにおける機器監視時の処理手順を説明するためのシーケンス図である。
【図11】キャッシュテーブルの構成例を示す図である。
【図12】機器情報のポーリング結果に基づくキャッシュテーブルの更新例を示す図である。
【図13】状態変化通知情報の構成例を示す図である。
【図14】不足通知メールの例を示す図である。
【図15】状態変化通知情報が正常に処理された際のキャッシュテーブルの更新例を示す図である。
【図16】発注ページの表示例を示す図である。
【図17】発注支援プログラムによる状態変化通知情報に基づく処理を説明するためのフローチャートである。
【図18】不足通知メールの重複送信チェック処理を説明するための図である。
【図19】設定画面の表示例を示す図である。
【図20】監視画面の表示例を示す図である。
【符号の説明】
【0115】
1 発注支援システム
10 発注支援サーバ
11 発注支援プログラム
12 機器情報テーブル
20 クライアントPC
21 監視プログラム
30、30a、30b、30c、30d 機器
40、50 ネットワーク
211 UIアプリ
212 監視サービス
501、502 記録媒体
【特許請求の範囲】
【請求項1】
ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、
前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することを特徴とする発注支援システム。
【請求項2】
前記電子メールには、受信された前記状態情報に係る消耗品の発注用のWebページを示すURLが記載されていることを特徴とする請求項1記載の発注支援システム。
【請求項3】
前記状態情報保持手段は、前記機器又は前記消耗品ごとに前記消耗品の前記状態情報と、第一又は第二の値をとり得るフラグ情報とを保持し、
前記状態変化検知手段は、前記状態の変化が検知された前記消耗品に係る前記フラグ情報を前記第一の値とし、
前記状態情報送信手段は、前記フラグ情報が前記第一の値である前記消耗品に係る前記状態情報を送信することを特徴とする請求項1又は2記載の発注支援システム。
【請求項4】
前記機器監視装置は、前記状態情報を送信した前記消耗品に係る前記フラグ情報を前記第二の値とすることを特徴とする請求項3記載の発注支援システム。
【請求項5】
前記状態情報取得手段は、前記状態情報の取得のたびに前記状態情報の取得対象とする機器を前記発注支援装置に問い合わせ、前記発注支援装置からの応答において指定された機器より前記状態情報を取得することを特徴とする請求項1乃至4いずれか一項記載の発注支援システム。
【請求項6】
前記機器監視装置は、前記ネットワークに接続されている機器を検索する機器検索手段と、検索された機器の一覧情報を前記発注支援装置に送信する検索機器情報送信手段とを有し、
前記発注支援装置は、前記一覧情報を保持する機器一覧保持手段と、前記機器一覧保持手段に保持されている前記一覧情報に含まれる機器の中から前記状態情報の取得対象とする機器を選択する対象機器選択手段とを有することを特徴とする請求項5記載の発注支援システム。
【請求項7】
前記検索手段は、前記ネットワークに接続されている機器を繰り返し検索し、検索された機器の一覧情報を前記発注支援装置に送信し、
前記対象機器選択手段は、前記機器一覧保持手段に既に保持されている第一の前記機器一覧情報と、新たに受信された第二の前記一覧情報とを比較し、前記第二の一覧情報に含まれている機器の中で前記第一覧情報に含まれていない機器を前記状態情報の取得対象として選択することを特徴とする請求項6記載の発注支援システム。
【請求項8】
請求項1乃至7いずれか一項記載の発注支援システムにおける発注支援装置。
【請求項9】
請求項1乃至7いずれか一項記載の発注支援システムにおける機器監視装置。
【請求項10】
第一のコンピュータが、ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手順と、取得された前記消耗品の状態情報を保持する状態情報保持手順と、前記状態情報保持手順において既に保持されている前記状態情報と前記状態情報取得手順において新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手順と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する第二のコンピュータに送信する状態情報送信手順と実行し、
前記第二のコンピュータが、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信することを特徴とする発注支援方法。
【請求項11】
前記電子メールには、受信された前記状態情報に係る消耗品の発注用のWebページを示すURLが記載されていることを特徴とする請求項10記載の発注支援方法。
【請求項12】
前記状態情報保持手順は、前記機器又は前記消耗品ごとに前記消耗品の前記状態情報と、第一又は第二の値をとり得るフラグ情報とを保持し、
前記状態変化検知手順は、前記状態の変化が検知された前記消耗品に係る前記フラグ情報を前記第一の値とし、
前記状態情報送信手順は、前記フラグ情報が前記第一の値である前記消耗品に係る前記状態情報を送信することを特徴とする請求項1又は2記載の発注支援方法。
【請求項13】
前記第一のコンピュータは、前記状態情報を送信した前記消耗品に係る前記フラグ情報を前記第二の値とすることを特徴とする請求項12記載の発注支援方法。
【請求項14】
前記状態情報取得手順は、前記状態情報の取得のたびに前記状態情報の取得対象とする機器を前記第二のコンピュータに問い合わせ、前記第二のコンピュータからの応答において指定された機器より前記状態情報を取得することを特徴とする請求項10乃至13いずれか一項記載の発注支援方法。
【請求項15】
前記第一のコンピュータは、前記ネットワークに接続されている機器を検索する機器検索手順と、検索された機器の一覧情報を前記第二のコンピュータに送信する検索機器情報送信手順とを実行し、
前記第二のコンピュータは、前記一覧情報を保持する機器一覧保持手順と、前記機器一覧保持手順に保持されている前記一覧情報に含まれる機器の中から前記状態情報の取得対象とする機器を選択する対象機器選択手順とを実行することを特徴とする請求項14記載の発注支援方法。
【請求項16】
前記検索手順は、前記ネットワークに接続されている機器を繰り返し検索し、検索された機器の一覧情報を前記第二のコンピュータに送信し、
前記対象機器選択手順は、前記機器一覧保持手順において既に保持されている第一の前記機器一覧情報と、新たに受信された第二の前記一覧情報とを比較し、前記第二の一覧情報に含まれている機器の中で前記第一覧情報に含まれていない機器を前記状態情報の取得対象として選択することを特徴とする請求項15記載の発注支援方法。
【請求項17】
請求項10乃至16いずれか一項記載の発注支援方法において、前記第二のコンピュータが実行する手順を有する発注支援方法。
【請求項18】
請求項10乃至16いずれか一項記載の発注支援方法において、前記第一のコンピュータが実行する手順を有する機器監視方法。
【請求項19】
請求項17記載の発注支援方法をコンピュータに実行させるための発注支援プログラム。
【請求項20】
請求項18記載の機器監視方法をコンピュータに実行させるための機器監視プログラム。
【請求項1】
ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手段と、取得された前記消耗品の状態情報を保持する状態情報保持手段と、前記状態情報保持手段に既に保持されている前記状態情報と前記状態情報取得手段により新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手段と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する発注支援装置に送信する状態情報送信手段とを有する機器監視装置と、
前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信する前記発注支援装置とを有することを特徴とする発注支援システム。
【請求項2】
前記電子メールには、受信された前記状態情報に係る消耗品の発注用のWebページを示すURLが記載されていることを特徴とする請求項1記載の発注支援システム。
【請求項3】
前記状態情報保持手段は、前記機器又は前記消耗品ごとに前記消耗品の前記状態情報と、第一又は第二の値をとり得るフラグ情報とを保持し、
前記状態変化検知手段は、前記状態の変化が検知された前記消耗品に係る前記フラグ情報を前記第一の値とし、
前記状態情報送信手段は、前記フラグ情報が前記第一の値である前記消耗品に係る前記状態情報を送信することを特徴とする請求項1又は2記載の発注支援システム。
【請求項4】
前記機器監視装置は、前記状態情報を送信した前記消耗品に係る前記フラグ情報を前記第二の値とすることを特徴とする請求項3記載の発注支援システム。
【請求項5】
前記状態情報取得手段は、前記状態情報の取得のたびに前記状態情報の取得対象とする機器を前記発注支援装置に問い合わせ、前記発注支援装置からの応答において指定された機器より前記状態情報を取得することを特徴とする請求項1乃至4いずれか一項記載の発注支援システム。
【請求項6】
前記機器監視装置は、前記ネットワークに接続されている機器を検索する機器検索手段と、検索された機器の一覧情報を前記発注支援装置に送信する検索機器情報送信手段とを有し、
前記発注支援装置は、前記一覧情報を保持する機器一覧保持手段と、前記機器一覧保持手段に保持されている前記一覧情報に含まれる機器の中から前記状態情報の取得対象とする機器を選択する対象機器選択手段とを有することを特徴とする請求項5記載の発注支援システム。
【請求項7】
前記検索手段は、前記ネットワークに接続されている機器を繰り返し検索し、検索された機器の一覧情報を前記発注支援装置に送信し、
前記対象機器選択手段は、前記機器一覧保持手段に既に保持されている第一の前記機器一覧情報と、新たに受信された第二の前記一覧情報とを比較し、前記第二の一覧情報に含まれている機器の中で前記第一覧情報に含まれていない機器を前記状態情報の取得対象として選択することを特徴とする請求項6記載の発注支援システム。
【請求項8】
請求項1乃至7いずれか一項記載の発注支援システムにおける発注支援装置。
【請求項9】
請求項1乃至7いずれか一項記載の発注支援システムにおける機器監視装置。
【請求項10】
第一のコンピュータが、ネットワークに接続される機器の消耗品の状態情報を繰り返し取得する状態情報取得手順と、取得された前記消耗品の状態情報を保持する状態情報保持手順と、前記状態情報保持手順において既に保持されている前記状態情報と前記状態情報取得手順において新たに取得された前記状態情報とを比較することにより前記消耗品の状態の変化を検知する状態変化検知手順と、状態の変化が検知された前記消耗品の前記状態情報をネットワークを介して接続する第二のコンピュータに送信する状態情報送信手順と実行し、
前記第二のコンピュータが、前記状態情報の受信に応じ当該状態情報に係る機器に予め関連付けられているメールアドレスに前記消耗品の状態を通知する電子メールを送信することを特徴とする発注支援方法。
【請求項11】
前記電子メールには、受信された前記状態情報に係る消耗品の発注用のWebページを示すURLが記載されていることを特徴とする請求項10記載の発注支援方法。
【請求項12】
前記状態情報保持手順は、前記機器又は前記消耗品ごとに前記消耗品の前記状態情報と、第一又は第二の値をとり得るフラグ情報とを保持し、
前記状態変化検知手順は、前記状態の変化が検知された前記消耗品に係る前記フラグ情報を前記第一の値とし、
前記状態情報送信手順は、前記フラグ情報が前記第一の値である前記消耗品に係る前記状態情報を送信することを特徴とする請求項1又は2記載の発注支援方法。
【請求項13】
前記第一のコンピュータは、前記状態情報を送信した前記消耗品に係る前記フラグ情報を前記第二の値とすることを特徴とする請求項12記載の発注支援方法。
【請求項14】
前記状態情報取得手順は、前記状態情報の取得のたびに前記状態情報の取得対象とする機器を前記第二のコンピュータに問い合わせ、前記第二のコンピュータからの応答において指定された機器より前記状態情報を取得することを特徴とする請求項10乃至13いずれか一項記載の発注支援方法。
【請求項15】
前記第一のコンピュータは、前記ネットワークに接続されている機器を検索する機器検索手順と、検索された機器の一覧情報を前記第二のコンピュータに送信する検索機器情報送信手順とを実行し、
前記第二のコンピュータは、前記一覧情報を保持する機器一覧保持手順と、前記機器一覧保持手順に保持されている前記一覧情報に含まれる機器の中から前記状態情報の取得対象とする機器を選択する対象機器選択手順とを実行することを特徴とする請求項14記載の発注支援方法。
【請求項16】
前記検索手順は、前記ネットワークに接続されている機器を繰り返し検索し、検索された機器の一覧情報を前記第二のコンピュータに送信し、
前記対象機器選択手順は、前記機器一覧保持手順において既に保持されている第一の前記機器一覧情報と、新たに受信された第二の前記一覧情報とを比較し、前記第二の一覧情報に含まれている機器の中で前記第一覧情報に含まれていない機器を前記状態情報の取得対象として選択することを特徴とする請求項15記載の発注支援方法。
【請求項17】
請求項10乃至16いずれか一項記載の発注支援方法において、前記第二のコンピュータが実行する手順を有する発注支援方法。
【請求項18】
請求項10乃至16いずれか一項記載の発注支援方法において、前記第一のコンピュータが実行する手順を有する機器監視方法。
【請求項19】
請求項17記載の発注支援方法をコンピュータに実行させるための発注支援プログラム。
【請求項20】
請求項18記載の機器監視方法をコンピュータに実行させるための機器監視プログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【公開番号】特開2008−9961(P2008−9961A)
【公開日】平成20年1月17日(2008.1.17)
【国際特許分類】
【出願番号】特願2007−93638(P2007−93638)
【出願日】平成19年3月30日(2007.3.30)
【出願人】(000006747)株式会社リコー (37,907)
【Fターム(参考)】
【公開日】平成20年1月17日(2008.1.17)
【国際特許分類】
【出願日】平成19年3月30日(2007.3.30)
【出願人】(000006747)株式会社リコー (37,907)
【Fターム(参考)】
[ Back to top ]