JP6648556B2 - サーバ装置、通信システムおよびプログラム - Google Patents

Description

本明細書では、画像処理装置やサーバ装置などが接続されている通信システム等を開示する。

消費者向けのサービスとして、画像形成装置のトナー、インク等の消耗品が無くなりかけた時に、画像形成装置が、インターネット上のサーバ装置へ自動的に消耗品を発注する技術が知られている。また、関連する技術が、特許文献１に開示されている。

特開2001-347734号公報

画像処理装置に対して自動発注サービスを購入する場合、自動発注サービスを提供するサーバ装置を介さずに、別ルートで画像形成装置を購入する場合が考えられる。その場合に、購入済の画像形成装置を識別する情報が、自動発注サービスを提供するサーバ装置に登録されていない。従って、画像形成装置を自動発注サービスを提供する当該サーバ装置に登録する必要があるが、消耗品の購入申請のタイミングと異なるケースが発生する場合がある。

本明細書に記載されているサーバ装置は、複数の画像処理装置および情報処理装置とネットワークを介して通信可能な通信インターフェースと、第１記憶部と、を備えたサーバ装置であって、情報処理装置を使用している第１ユーザに固有の第１識別情報を情報処理装置から取得する第１取得手段と、複数の画像処理装置が有する複数の画像処理装置種類の各々で使用可能な部材を示す使用部材候補情報の要求を受信する第１受信手段と、使用部材候補情報を情報処理装置に送信する第１送信手段と、複数の画像処理装置種類のうちから第１ユーザによって指定された指定画像処理装置種類を有する画像処理装置で使用されることが指示された使用部材を示す使用部材情報を、情報処理装置から取得する第２取得手段と、第１取得手段で取得した第１識別情報および第２取得手段で取得した使用部材情報を、互いに対応付けて第１記憶部に記憶させる第１記憶制御手段と、第１記憶制御手段が記憶させた、第１識別情報および使用部材情報のデータセットに固有の第２識別情報を、情報処理装置へ送信する第２送信手段と、情報処理装置へパスワード情報を送信する第３送信手段と、第２送信手段が第２識別情報を情報処理装置へ送信した後に、特定画像処理装置に固有の第３識別情報と、第２送信手段で送信した第２識別情報を、画像処理装置から取得する第３取得手段と、ここで特定画像処理装置は、指定画像処理装置種類を有する画像処理装置であって第１ユーザによって指定された画像処理装置であり、第３取得手段は、第３送信手段で送信したパスワード情報と同一のパスワード情報とともに送信されてくる第３識別情報を、特定画像処理装置に固有の第３識別情報として取得し、取得した第３識別情報を、第２識別情報で識別されるデータセットに対応付けて第１記憶部にさらに記憶させる第２記憶制御手段と、第２記憶制御手段が第３識別情報を記憶させた後に特定の条件が成立することに応じて、第３識別情報で識別される特定画像処理装置にステータス情報取得要求を送信する第４送信手段と、ステータス情報取得要求を送信した後に、特定画像処理装置からステータス情報を取得する第４取得手段と、取得したステータス情報に基づいて、特定画像処理装置で使用される部材である使用部材の注文が必要か否かを判断する判断手段と、判断手段で使用部材の注文が必要であると判断された場合に、第１識別情報で識別される第１ユーザへ、使用部材情報で識別される種類の使用部材を送付する処理実行手段と、を備えることを特徴とする。

上記構成によると、第１ユーザは、送付してもらう使用部材の種類を、サーバ装置に最初に登録することができる。その後第１ユーザは、使用部材を必要とする特定画像処理装置を、サーバ装置に登録することができる。これにより、使用部材の種類を選択するタイミングと、特定画像処理装置を入手するタイミングとが互いに異なる場合においても、特定画像処理装置と使用部材とのデータセットを適切にサーバ装置に登録することが可能となる。

本明細書に実施形態として記載されているサーバ装置等によれば、第１ユーザが入力した第１の画像処理装置種類情報に間違いがあった場合に、間違いがあることを第１ユーザに報知することが可能となる。

本明細書に実施形態として記載されているサーバ装置等によれば、第１ユーザが複数の画像処理装置をサーバ装置に登録している場合に、複数の画像処理装置の一覧を情報処理装置に表示させることができる。そして、複数の画像処理装置のうちから、１の画像処理装置を指定することができる。

本明細書に実施形態として記載されているサーバ装置等によれば、第２識別情報をクエリ情報とすることができる。これにより、サーバ装置と情報処理装置との通信中の何れのタイミングにおいても、第２識別情報を参照しやすくすることが可能となる。

本明細書に実施形態として記載されているサーバ装置等によれば、画像を記録媒体に形成するために用いられる消耗部材の残量が減少したことに応じて、消耗部材を販売するサービスを提供する装置に、消耗部材を注文することができる。

本明細書に実施形態として記載されているサーバ装置等によれば、予め定められた期間が経過することに応じて、ステータス情報を特定画像処理装置から取得することができる。

通信システムの構成を示す。 通信システムの動作例を示すシーケンス図を示す。 通信システムの動作例を示すシーケンス図を示す。 通信システムの動作例を示すシーケンス図を示す。 通信システムの動作例を示すシーケンス図を示す。 通信システムの動作例を示すシーケンス図を示す。 ユーザアカウントテーブルＴ１の一例を示す図である。 オーダテーブルＴ３１の一例を示す図である。 ユーザアカウントテーブルＴ２１の一例を示す図である。 ユーザアカウントテーブルＴ２１の一例を示す図である。 自動発注サービス申請画面の一例を示す図である。 自動発注サービス申請画面の一例を示す図である。 通信システムの動作例を示すシーケンス図を示す。 通信システムの動作例を示すシーケンス図を示す。 通信システムの動作例を示すシーケンス図を示す。 通信システムの動作例を示すシーケンス図を示す。 ユーザアカウントテーブルＴ２１の一例を示す図である。 変形例における通信システムの動作例を示すシーケンス図を示す。

＜システムの構成＞
図１に示されるように、通信システム２は、ルータ７および８と、多機能機１０および１１と、装置情報収集サーバ６０と、第１サービスサーバ１００および第２サービスサーバ１１０と、ＰＣ（Personal Computerとも称する）４０と、オーダ決定サーバ５０を備えている。多機能機１０は、ＬＡＮ４およびルータ７を介してインターネット６に接続されている。多機能機１１は、ルータ８を介してインターネット６に接続されている。また、ＰＣ４０、オーダ決定サーバ５０、装置情報収集サーバ６０、第１サービスサーバ１００および第２サービスサーバ１１０も、インターネット６に接続されている。

＜多機能機１０の構成＞
多機能機１０は、印刷機能、ＦＡＸ機能、スキャン機能、コピー機能、等の多機能を実行可能である。多機能機１０は、操作部１２と、表示部１４と、ネットワークインターフェース１６と、ＵＳＢインターフェース１７と、印刷実行部１８と、スキャン実行部１９と、制御部２０と、を備える。操作部１２は、複数のキーを備える。ユーザは、操作部１２を操作することによって、様々な指示を多機能機１０に入力することができる。表示部１４は、様々な情報を表示するためのディスプレイである。ネットワークインターフェース１６は、ＬＡＮ４を介してルータ７に接続されている。ネットワークインターフェース１６は、第１サービスサーバ１００および第２サービスサーバ１１０の各々と通信することが可能である。ＵＳＢインターフェース１７は、ＵＳＢケーブル１５を介してＰＣ４０と通信を行うためのインターフェースである。印刷実行部１８は、インクジェット方式、レーザ方式等の印刷機構を備える。スキャン実行部１９は、ＣＣＤ、ＣＩＳ等のスキャン機構を備える。制御部２０は、ＣＰＵ２２と、メモリ２４と、を備える。メモリ２４は、コンピュータが読み取り可能なストレージ媒体であってよい。コンピュータが読み取り可能なストレージ媒体とは、ＲＯＭ、ＲＡＭ、フラッシュメモリ、ハードディスクなどのnon-transitoryな媒体である。ＲＯＭ、ＲＡＭ、フラッシュメモリ、ハードディスクなどはtangibleな媒体である。インターネット上のサーバなどからダウンロードされるプログラムを搬送する電気信号は、コンピュータが読み取り可能な媒体の一種である、コンピュータが読み取り可能な信号媒体であるが、non-transitoryなコンピュータが読み取り可能なストレージ媒体には含まれない。メモリ２４は、アプリケーションプログラム２５、プロトコルスタック２６、装置情報２７を記憶している。

装置情報２７は、デバイスＩＤ、型番、ノード名、ＭＡＣアドレス、などを含んでいる。デバイスＩＤは、多機能機１０に固有の情報である。デバイスＩＤの一例としては、製造シリアルナンバーが挙げられる。型番は、多機能機１０の装置の種類を示す情報である。ノード名は、多機能機１０をネットワーク上で識別するための情報である。ＭＡＣアドレスは、ネットワーク上で多機能機１０を識別するために付与されている、固有の物理アドレスである。

ＣＰＵ２２は、メモリ２４に格納されているアプリケーションプログラム２５に従って、第１サービスサーバ１００および第２サービスサーバ１１０が提供する、後述する各種のサービスを利用するための処理を実行する。ＣＰＵ２２は、メモリ２４に格納されているプロトコルスタック２６に従って、ＨＴＴＰ（Hyper Text Transfer Protocolの略）や、ＸＭＰＰ over ＢＯＳＨ（eXtensible Messaging and Presence Protocol over Bidirectional-streams Over Synchronous HTTPの略）、などのプロトコル処理を実行する。ＣＰＵ２２は、プロトコル処理によって、後述するＸＭＰＰ over ＢＯＳＨに従ったセッション確立や、ＨＴＴＰに従ったコネクション確立などを行う。なお、ＸＭＰＰ over ＢＯＳＨに従ったセッションのことを、ＸＭＰＰセッションとも記載する。また、ＸＭＰＰ over ＢＯＳＨは、セッション確立型プロトコルの例である。

ＸＭＰＰセッションの内容について説明する。多機能機１０との間でセッション確立型のプロトコルに従う通信であれば、多機能機１０から装置情報収集サーバ６０へ、セッション確立を要求する情報が定期的に送信される。装置情報収集サーバ６０は、多機能機１０に送信すべき情報を、セッション確立を要求する情報のうち、いずれかによって確立されたセッションを用いて送信すればよい。セッションが確立していると、ルータ７は、インターネット６側から多機能機１０に送信された情報を通すことができる。よって、装置情報収集サーバ６０が情報をルータ７を介して多機能機１０に送信した場合、多機能機１０はその情報を受信することができる。すなわち、サーバプッシュを行うことができる。

なお、多機能機１１の構成も、多機能機１０の構成と同様であるため、ここでは説明を省略する。

本明細書における記載上の注意点を説明する。本明細書において、「多機能機１０のＣＰＵ２２が、各種の情報を送信または受信する」という記載は、「多機能機１０のＣＰＵ２２が、ネットワークインターフェース１６を介して各種の情報を出力または取得する」という技術内容を含んでいるものとする。なお、装置情報収集サーバ６０のＣＰＵ７２およびネットワークインターフェース６２についても、同様の注意点が存在する。また、第１サービスサーバ１００および第２サービスサーバ１１０の各々についても、同様の注意点が存在する。

ここで、「データ」および「情報」の文言の定義を説明する。本明細書では、「データ」と「情報」では「情報」を「データ」の上位概念として用いている。そのため、「Ａデータ」を「Ａ情報」と言い換えてもよい。また、「情報」は、「データ」としての形式（例えば、テキスト形式、バイナリ形式、フラグ形式等）が異なっていても、同一の意味内容と認識される限り、同一の情報として取り扱われる。例えば、印刷部数が２部であることを示す情報として装置が扱う限り、"COPY=2"というテキスト形式のデータと、"10"というバイナリ形式のデータとは、同じ情報である。但し、上記の「データ」および「情報」の区別は厳密なものではなく、例外的な取扱いも許容される。

＜装置情報収集サーバ６０の構成＞
装置情報収集サーバ６０は、オーダ決定サーバ５０、第１サービスサーバ１００および第２サービスサーバ１１０とは別体に構成されているサーバである。装置情報収集サーバ６０は、オーダ決定サーバ５０と多機能機１０および１１との間のアクセスを仲介するためのサーバである。装置情報収集サーバ６０は、多機能機１０および１１のベンダによって提供されるサーバであってもよい。装置情報収集サーバ６０は、ネットワークインターフェース６２と、制御部７０と、を備える。

制御部７０は、ＣＰＵ７２と、メモリ７４と、を備える。メモリ７４には、アプリケーションプログラム７５、プロトコルスタック７８、ユーザアカウントテーブルＴ１が記憶されている。メモリ７４は、メモリ２４と同様に、コンピュータが読み取り可能なストレージ媒体であってよい。ＣＰＵ７２は、アプリケーションプログラム７５に従って、後述する各種の処理を実行する。ＣＰＵ２２がプロトコルスタック７８に従って実行する処理の内容は、多機能機１０のプロトコルスタック２６について説明した内容に準ずる。

図７に、ユーザアカウントテーブルＴ１の一例を示す。装置番号１１１は、複数の装置を識別するための連続番号である。ユーザＩＤ１１２は、複数のユーザの各々を識別するための情報である。パスワード１１３は、ユーザがサインインする際に用いられる認証情報である。デバイスＩＤ１１４は、複数の多機能機の各々を識別するための情報である。型番１１５は、多機能機の種類を示す情報である。ノード名１１６は、複数の多機能機の各々をネットワーク上で識別するための情報である。

＜ＰＣ４０の構成＞
ＰＣ４０の構成を説明する。ＰＣ４０は、ＣＰＵ４１、メモリ４２、ＵＳＢインターフェース４６、ネットワークインターフェース４７、表示部４８、操作部４９、等を有する。表示部４８は、様々な情報を表示することができる。操作部４９は、キーボードやマウスによって構成される。ユーザは、操作部４９を操作することによって、様々な指示や情報をＰＣ４０に入力することができる。ネットワークインターフェース４７は、インターネット６に接続されている。ＵＳＢインターフェース４６は、ＵＳＢケーブル１５を介して多機能機１０と通信を行うためのインターフェースである。

＜第１および第２サービスサーバの構成＞
第１サービスサーバ１００および第２サービスサーバ１１０の各々は、電子商取引サービスを提供するサーバである。電子商取引サービスは、インターネット６を介してユーザから、商品の選択や各種のサービスの申請を受け付ける。そして、クレジットカード番号等を用いて決済を行うサービスである。購入された商品は、ユーザに郵送される。

第１サービスサーバ１００の構成を説明する。第１サービスサーバ１００は、ネットワークインターフェース１０１および制御部１０２を備えている。ネットワークインターフェース１０１は、インターネット６に接続している。制御部１０２は、ＣＰＵ１０３およびメモリ１０４を備えている。メモリ１０４には、ユーザアカウントテーブルＴ２１が記憶されている。

図１０に、ユーザアカウントテーブルＴ２１の一例を示す。ユーザＩＤ１３１は、複数のユーザの各々を識別するための情報である。パスワード１３２は、ユーザが第１サービスサーバ１００にサインインする際に用いられる認証情報である。ユーザＩＤ１３１およびパスワード１３２によって、ユーザアカウント１５０が構成される。住所／メールアドレス／氏名１３３は、ユーザの住所、メールアドレス、および氏名を示す情報である。クレジットカード番号１３４は、電子決済サービスの決済に用いられる情報である。デバイスＩＤ１３５は、自動発注サービスの対象となる多機能機に固有の情報である。多機能機型番１３６は、自動発注サービスの対象となる多機能機の種類を示す情報である。インク型番１３７〜１４０は、自動発注サービスで注文されるインクの種類を示す情報である。

なお、第２サービスサーバ１１０の内容は、第１サービスサーバ１００と同様であるため、ここでは説明を省略する。第２サービスサーバ１１０は、多機能機１０や１１を提供するベンダによって提供されるサーバであってもよい。

＜オーダ決定サーバ５０の構成＞
オーダ決定サーバ５０は、図６で説明する自動発注処理プロセスを実行するサーバである。オーダ決定サーバ５０は、ネットワークインターフェース５１および制御部５２を備えている。ネットワークインターフェース５１は、インターネット６に接続している。制御部５２は、ＣＰＵ５３およびメモリ５４を備えている。メモリ５４には、後述する申請完了フラグが記憶される。またメモリ５４には、オーダテーブルＴ３１が記憶されている。

図８に、オーダテーブルＴ３１の一例を示す。装置番号１４１は、複数の装置を識別するための連続番号である。デバイスＩＤ１４２は、複数の多機能機の各々を識別するための情報である。申請完了フラグ１４３は、消耗品宅配サービスの対象となる多機能機の第１サービスサーバ１００への登録（Ｓ２７０）と、消耗品宅配サービスの対象となる使用部材の種類の第１サービスサーバ１００への登録の両方が終わっている場合に「オン」になるフラグである。

＜通信システムの概要＞
通信システム２は、多機能機１０、１１で用いるトナー、インク等の消耗部材を、電子商取引サービスに自動的に発注することが可能なシステムである。具体的には通信システム２は、第１サービスサーバ１００、オーダ決定サーバ５０、装置情報収集サーバ６０と、を備えている。これらのサーバは、互いに独立している。第１サービスサーバ１００は、電子商取引サービスを提供するサーバである。装置情報収集サーバ６０は、多機能機１０、１１の装置状態のモニタのみを行う専用サーバである。オーダ決定サーバ５０は、多機能機１０、１１のトナー、インク等の消耗品の発注を第１サービスサーバ１００に対して行うサーバである。

通信システム２の具体的な動作を説明する。装置情報収集サーバ６０は、多機能機１０、１１の消耗品の残量を示すステータス情報を取得する。オーダ決定サーバ５０は、ステータス情報に基づき、消耗品の発注の可否を判断する。オーダ決定サーバ５０は、発注が必要であると判断した場合には、第１サービスサーバ１００に対して自動的に消耗品を発注する。第１サービスサーバ１００は消耗品の発注を受けると、決済を行うとともに、消耗品をユーザに郵送する。

＜ユーザアカウント登録プロセス＞
図２のシーケンス図を用いて、ユーザアカウント登録プロセスの内容について説明する。ユーザアカウント登録プロセスは、第１サービスサーバ１００が備えるユーザアカウントテーブルＴ２１に、ユーザアカウントを記憶させるプロセスである。

例として、ユーザＡが、第１サービスサーバ１００が提供する電子商取引サービスに、自己のユーザアカウントを登録する場合を説明する。またユーザＡが、ＰＣ４０を用いて登録処理を実行する場合を説明する。またユーザＡが、多機能機１０をまだ所有しておらず、第１サービスサーバ１００から電子商取引で多機能機１０を購入する場合を説明する。

Ｓ１０においてユーザＡは、ユーザＡのユーザアカウントを第１サービスサーバ１００に登録する登録指示を入力する。登録指示の入力は、例えば、第１サービスサーバ１００が提供するウェブページ上に、ユーザアカウントの登録を受け付けるボタン画像が表示されていてもよい。そして、当該ボタン画像がクリックされることにより、登録指示の入力が行われたと判断してもよい。

Ｓ１５において、第１サービスサーバ１００は、ユーザアカウントを構成する各種情報（ユーザＩＤ、パスワード、氏名、住所等）を、ＰＣ４０から受信する。Ｓ１６において第１サービスサーバ１００は、ユーザＡのユーザアカウントを、ユーザアカウントテーブルＴ２１に記憶する（図９、領域Ｒ１０参照）。これにより、ユーザＡは、第１サービスのユーザアカウントを取得することができる。またユーザＡが、第１サービスサーバ１００にサインインしている状態となる。

Ｓ１８において第１サービスサーバ１００は、購入画面情報をＰＣ４０へ送信する。購入画面情報は、第１サービスサーバ１００で多機能機を購入するための購入画面を、ＰＣ４０の表示部４８に表示させるための情報である。Ｓ１９においてＰＣ４０は、購入画面を表示部４８に表示する。Ｓ２０においてユーザＡは、多機能機１０を購入するための操作を、ＰＣ４０の操作部４９に入力する。Ｓ２２において第１サービスサーバ１００は、多機能機１０を購入するための各種情報を、ＰＣ４０から受信する。Ｓ２４において第１サービスサーバ１００は、多機能機１０の購入処理を実行する。具体的には、ユーザＡのクレジットカード番号１３４を用いて決済を行う処理や、多機能機１０をユーザＡに発送する処理を行う。Ｓ２５において第１サービスサーバ１００は、多機能機１０をユーザＡに郵送する。これにより、ユーザＡによる多機能機１０の購入が完了する。

＜多機能機登録プロセス（その１）＞
図３〜図５のシーケンス図を用いて、多機能機登録プロセスの内容について説明する。多機能機登録プロセスは、多機能機を、第１サービスサーバ１００が備えるユーザアカウントテーブルＴ２１、および、装置情報収集サーバ６０が備えるユーザアカウントテーブルＴ１に記憶させるプロセスである。

Ｓ１１０においてＰＣ４０は、多機能機登録指示の入力が行われたか否かを判断する。多機能機登録指示は、ユーザＡが購入した多機能機１０を第１サービスサーバ１００に登録することを、第１サービスサーバ１００に指示する情報である。例えば、Ｓ２４で多機能機１０を購入した際に、第１サービスサーバ１００から電子メールがＰＣ４０に送信されてきてもよい。電子メールの文面に、多機能機の登録を受け付けるボタン画像が表示されていてもよい。そして、当該ボタン画像がクリックされることにより、多機能機登録指示の入力が行われたと判断してもよい。Ｓ１１０において否定判断される場合（Ｓ１１０：ＮＯ）にはＳ１１０へ戻り、肯定判断される場合（Ｓ１１０：ＹＥＳ）にはＳ１１５へ進む。

Ｓ１１５においてＰＣ４０は、多機能機登録要求を第１サービスサーバ１００へ送信する。Ｓ１２０において第１サービスサーバ１００は、ユーザ登録要求と、ユーザＡのユーザアカウント１５０を、装置情報収集サーバ６０へ送信する。 ユーザ登録要求は、第１サービスサーバ１００が記憶しているユーザＡのユーザアカウント１５０を、装置情報収集サーバ６０にも記憶させることを指示する情報である。

Ｓ１３０において装置情報収集サーバ６０は、ユーザＡのユーザアカウント１５０を、ユーザアカウントテーブルＴ１に記憶させる（図７、領域Ｒ０参照）。これにより、装置情報収集サーバ６０においても、ユーザＡのユーザアカウントを登録することができる。

Ｓ１５０において第１サービスサーバ１００は、ＰＩＮコード要求を装置情報収集サーバ６０へ送信する。ＰＩＮコードは、後述するＳ１７５で、多機能機１０のユーザに紐付けられたワンタイムパスワードとして機能する。

Ｓ１５３において装置情報収集サーバ６０は、ＰＩＮコードを生成してメモリ７４に一時的に記憶させる。ＰＩＮコードは、ランダムに生成される英数字の文字列であってもよい。Ｓ１５５において装置情報収集サーバ６０は、ＰＩＮコードを第１サービスサーバ１００へ送信する。Ｓ１６０において第１サービスサーバ１００は、受信したＰＩＮコードを、Ｓ１１５で多機能機登録要求を送信してきた装置（すなわちＰＣ４０）へ送信する。Ｓ１６５においてＰＣ４０は、受信したＰＩＮコードを表示部４８に表示する。

Ｓ１７０において多機能機１０は、ＰＩＮコードの入力を受け付けたか否かを判断する。ＰＩＮコードの入力態様の一例を説明する。ユーザＡは、ＰＣ４０の表示部４８に表示されたＰＩＮコードを暗記する。そしてユーザＡは、多機能機１０の操作部１２を操作して、暗記していたＰＩＮコードを多機能機１０に入力する。これにより、ＰＩＮコードが入力された多機能機１０は、ユーザＡによって登録対象として指定されたことになる。Ｓ１７０において否定判断される場合（Ｓ１７０：ＮＯ）にはＳ１７０へ戻り、肯定判断される場合（Ｓ１７０：ＹＥＳ）にはＳ１７５へ進む。

Ｓ１７５において多機能機１０は、Ｓ１７０で入力されたＰＩＮコードと、多機能機１０のメモリ２４に記憶されている装置情報２７（すなわち、デバイスＩＤ、型番、ノード名）とを、装置情報収集サーバ６０へ送信する。

Ｓ１７７において装置情報収集サーバ６０は、受信したＰＩＮコードと同一のＰＩＮコードが、メモリ７４に記憶されているか否かを判断する。否定判断される場合（Ｓ１７７：ＮＯ）にはフローを終了する。一方、肯定判断される場合（Ｓ１７７：ＹＥＳ）には、Ｓ１６０でユーザＡに送付したＰＩＮコードが、多機能機１０の装置情報２７とともに送付されてきた場合である。この場合、受信した装置情報２７が、ユーザＡによって登録が指示された情報であると識別することができる。そしてＳ１８０へ進む。

Ｓ１８０において装置情報収集サーバ６０は、多機能機１０の装置情報２７（すなわちデバイスＩＤ、型番、ノード名）を、ユーザＡに対応付けて、ユーザアカウントテーブルＴ１に記憶させる。図７を用いて、ユーザアカウントテーブルＴ１の具体的な記憶例を示す。領域Ｒ１に示すように、Ｓ１３０で記憶されたユーザＡのユーザアカウント（領域Ｒ０）に対応付けて、多機能機１０のデバイスＩＤ１１４、型番１１５、ノード名１１６を記憶させる。なお、装置情報２７のユーザアカウントテーブルＴ１への登録が完了した後においては、ＰＩＮコードはもはや不要である。よって、Ｓ１５３でメモリ７４に記憶させたＰＩＮコードを消去してもよい。

Ｓ２００においてＰＣ４０は、消耗品宅配サービス登録の指示入力が行われたか否かを判断する。例えば、Ｓ１９で表示した購入画面に、消耗品宅配サービス登録を受け付けるボタン画像が表示されていてもよい。そして、当該ボタン画像がクリックされることにより、消耗品宅配サービス登録の指示入力が行われたと判断してもよい。否定判断される場合（Ｓ２００：ＮＯ）にはＳ２００へ戻り、肯定判断される場合（Ｓ２００：ＹＥＳ）にはＳ２１０へ進む。

Ｓ２１０においてＰＣ４０は、装置一覧要求を第１サービスサーバ１００へ送信する。装置一覧要求は、ユーザＡがユーザアカウントテーブルＴ１に登録している全ての装置を、一覧表示することを要求するための情報である。

Ｓ２１３において第１サービスサーバ１００は、装置一覧要求を装置情報収集サーバ６０へ送信する。Ｓ２１６において装置情報収集サーバ６０は、装置一覧情報を第１サービスサーバ１００へ送信する。具体的には、ユーザアカウントテーブルＴ１（図７）の内容を送信する。Ｓ２１８において第１サービスサーバ１００は、装置一覧情報（図７）の内容をメモリ１０４に一時的に記憶させる。Ｓ２２０において第１サービスサーバ１００は、装置一覧情報をＰＣ４０へ送信する。

Ｓ２３０においてＰＣ４０は、自動発注サービス申請画面Ｐ１を表示部４８に表示する。図１１に、自動発注サービス申請画面Ｐ１の表示例を示す。自動発注サービス申請画面Ｐ１には、型番１６６を入力する欄が表示されている。また、プルダウンメニューＰ１１によって、選択可能な装置の装置番号と型番が表示される。プルダウンメニューＰ１１に表示される装置番号および型番は、ユーザアカウントテーブルＴ１（図７）の装置番号１１１および型番１１５に対応している。

Ｓ２３５においてＰＣ４０は、装置選択の入力が行われたか否かを判断する。具体的には、プルダウンメニューＰ１１の中から何れかの型番が選択されたかを判断する。否定判断される場合（Ｓ２３５：ＮＯ）にはＳ２３５へ戻り、肯定判断される場合（Ｓ２３５：ＹＥＳ）にはＳ２４０へ進む。本実施形態の説明例では、装置番号が「３」であり、型番が「ＭＦＰ−３」である装置が選択される場合（すなわち、多機能機１０が選択される場合）を説明する。

Ｓ２４０においてＰＣ４０は、装置選択情報を第１サービスサーバ１００へ送信する。装置選択情報は、例えば、図１１のプルダウンメニューＰ１１において、装置番号の何番目が選択されたかを示す情報であってもよい。本実施形態の説明例では、装置番号の「３」が選択されたことを示す情報が、第１サービスサーバ１００へ送信される。

Ｓ２７０において第１サービスサーバ１００は、デバイスＩＤ、装置情報２７（型番など）をユーザアカウントテーブルＴ２１に記憶させる。具体例を説明する。Ｓ２４０において、装置番号の「３」が選択されたことが第１サービスサーバ１００に報知される。第１サービスサーバ１００は、Ｓ２１８で記憶させた装置一覧情報（図７）において、装置番号１１１の「３」の欄を参照する。これにより第１サービスサーバ１００は、デバイスＩＤが「ｇｈｉ７８９」の装置（すなわち多機能機１０）が選択されたことを認識することができる。よって、図９のユーザアカウントテーブルＴ２１において、デバイスＩＤ１３５および多機能機型番１３６を記憶することができる（図９、領域Ｒ１１）。

Ｓ２７５において第１サービスサーバ１００は、選択されたデバイスＩＤをオーダ決定サーバ５０に送信する。Ｓ２８０においてオーダ決定サーバ５０は、受信したデバイスＩＤをオーダテーブルＴ３１に記憶させる。本実施形態の説明例では、図８のオーダテーブルＴ３１において、デバイスＩＤの「ｇｈｉ７８９」を記憶する（領域Ｒ２１）。なお、申請完了フラグ１４３は、この時点では「オフ」である（領域Ｒ２２）。

Ｓ３００においてＰＣ４０は、消耗品選択の入力が行われたか否かを判断する。図１２に、自動発注サービス申請画面Ｐ１の表示例を示す。自動発注サービス申請画面Ｐ１には、インク型番１６７〜１７０を入力する欄が表示されている。図１２では、インク型番１６７を選択するためのプルダウンメニューＰ１２が表示されている例を示している。プルダウンメニューＰ１２には、選択可能なインク型番が表示されている。そしてＰＣ４０は、プルダウンメニューＰ１２の中から何れかの型番が選択されたかを判断する。否定判断される場合（Ｓ３００：ＮＯ）にはＳ３００へ戻り、肯定判断される場合（Ｓ３００：ＹＥＳ）にはＳ３０５へ進む。

Ｓ３０５においてＰＣ４０は、消耗品選択情報およびデバイスＩＤを、第１サービスサーバ１００へ送信する。消耗品選択情報は、ユーザに選択されたインク型番１６７〜１７０の各々を示す情報である。

Ｓ３１０において第１サービスサーバ１００は、消耗品選択情報をユーザアカウントテーブルＴ２１に記憶させる。具体例を説明する。第１サービスサーバ１００は、Ｓ３０５で受信した消耗品選択情報に基づいて、ユーザＡによって選択されたインクの型番を認識する。そして、図１０のユーザアカウントテーブルＴ２１において、インクの型番情報を記憶させる（領域Ｒ１２）。

Ｓ３２０において第１サービスサーバ１００は、申請完了通知情報、および、デバイスＩＤをオーダ決定サーバ５０に送信する。申請完了通知情報は、消耗品選択情報を第１サービスサーバ１００が取得したことを示す情報である。換言すると申請完了通知情報は、多機能機１０で使用するインク型番の第１サービスサーバ１００への登録が、完了したことを示す情報である。

Ｓ３２３においてオーダ決定サーバ５０は、Ｓ３２０で受信したデバイスＩＤと一致するデバイスＩＤが、オーダテーブルＴ３１に記憶されているか否かを判断する。否定判断される場合（Ｓ３２３：ＮＯ）にはフローを終了し、肯定判断される場合（Ｓ３２３：ＹＥＳ）にはＳ３２５へ進む。Ｓ３２５においてオーダ決定サーバ５０は、オーダテーブルＴ３１において、Ｓ３２０で受信したデバイスＩＤに対応する申請完了フラグ１４３を「オン」にする。そしてフローを終了する。

本実施形態の説明例では、Ｓ３２０で「ｇｈｉ７８９」のデバイスＩＤを受信する。よって、Ｓ３２３では肯定判断される。そしてＳ３２５において、オーダテーブルＴ３１の申請完了フラグ１４３が「オン」にされる（図８、領域Ｒ２２参照）。

＜自動発注処理プロセス（その１）＞
図６のシーケンス図を用いて、自動発注処理プロセスの内容について説明する。自動発注処理プロセスは、オーダ決定サーバ５０が第１サービスサーバ１００に対して、自動的に消耗品を発注するためのプロセスである。

Ｓ６１０においてオーダ決定サーバ５０は、ステータス情報通知要求を出す特定条件が成立したか否かを判断する。特定条件の一例としては、予め定められた期間（例：１日）が経過したことが挙げられる。否定判断される場合（Ｓ６１０：ＮＯ）にはＳ６１０へ戻り、肯定判断される場合（Ｓ６１０：ＹＥＳ）にはＳ６１５へ進む。

Ｓ６１５においてオーダ決定サーバ５０は、オーダテーブルＴ３１において、「オン」の申請完了フラグが対応付けられたデバイスＩＤが存在するか否かを判断する。否定判断される場合（Ｓ６１５：ＮＯ）にはフローを終了し、肯定判断される場合（Ｓ６１５：ＹＥＳ）にはＳ６２０へ進む。本実施形態の説明例では、図８に示すように、「オン」の申請完了フラグ１４３が、デバイスＩＤ「ｇｈｉ７８９」（すなわち多機能機１０のデバイスＩＤ）に対応付けられている場合を説明する。

Ｓ６２０においてオーダ決定サーバ５０は、ステータス情報通知要求、および、デバイスＩＤ「ｇｈｉ７８９」を、装置情報収集サーバ６０へ送信する。ステータス情報通知要求は、デバイスＩＤ「ｇｈｉ７８９」で識別される多機能機１０に対して、ステータス情報の取得を要求するための情報である。ステータス情報は、インク残量など、多機能機の各種の状態を示す情報である。

Ｓ６２５において装置情報収集サーバ６０は、ステータス情報通知要求を多機能機１０に送信する。ステータス情報通知要求は、ＸＭＰＰメッセージ情報として多機能機１０に送信される。またステータス情報通知要求は、装置情報収集サーバ６０と多機能機１０との間で確立しているＸＭＰＰコネクションを用いて、多機能機１０へ送信される。ＸＭＰＰコネクションを確立する処理については、周知であるため、ここでは詳細な説明を省略する。

Ｓ６３０において装置情報収集サーバ６０は、ステータス情報を多機能機１０から受信する。Ｓ６３５において装置情報収集サーバ６０は、ステータス情報、および、デバイスＩＤ「ｇｈｉ７８９」を、オーダ決定サーバ５０へ送信する。

Ｓ６４０においてオーダ決定サーバ５０は、デバイスＩＤ「ｇｈｉ７８９」で識別される多機能機１０に関して、インクの注文が必要か否かを判断する。当該判断は、受信したステータス情報に基づいて行われる。具体的には、ステータス情報に基づいて、シアン、マジェンタ、イエロー、ブラックの各色のインク残量を認識する。そして各色のインク残量が、予め定められた特定値よりも少ないか否かを判断する。特定値よりも残量が少ない色のインクが存在する場合には、当該インクについて、新しいインクカートリッジの注文が必要であると判断する。否定判断される場合（Ｓ６４０：ＮＯ）にはフローを終了し、肯定判断される場合（Ｓ６４０：ＹＥＳ）にはＳ６５０へ進む。本実施形態の例では、ブラックのインクの残量が、特定値よりも少ない場合について説明を続ける。

Ｓ６５０においてオーダ決定サーバ５０は、注文指示、および、デバイスＩＤ「ｇｈｉ７８９」を、第１サービスサーバ１００へ送信する。注文指示は、ブラックのインクカートリッジを、ユーザＡに郵送することを、第１サービスサーバ１００に指示する情報である。また注文指示は、ブラックのインクカートリッジについて、通常品と大容量品との何れの種類をユーザＡが指定したかを特定することを、第１サービスサーバ１００に指示する情報でもある。

Ｓ６６０において第１サービスサーバ１００は、インクの購入処理を実行する。具体的には、デバイスＩＤ「ｇｈｉ７８９」に基づいて、ユーザＡのユーザアカウントテーブルＴ２１（図１０）を読み出す。また、ブラックのインクカートリッジの型番が「大容量品」の型番であることを特定する。そして、クレジットカード番号１３４等を用いて、ブラックの大容量インクカートリッジの購入手続きを行う。

Ｓ６７０において第１サービスサーバ１００は、ユーザアカウントテーブルＴ２１の住所／メールアドレス／氏名１３３を用いて、郵送先を特定する。そして、ブラックの大容量インクカートリッジをユーザＡへ郵送する。そしてフローが終了する。

＜実施例１の効果＞
通信システム２では、装置情報収集サーバ６０およびオーダ決定サーバ５０を、第１サービスサーバ１００と独立させている。これは、装置情報を用いたサービスは、本明細書で説明した消耗品宅配サービス以外にも多数存在しうるために、これらの多数のサービスで、装置情報収集サーバ６０やオーダ決定サーバ５０を共用するためである。これにより、サーバの利用効率を高めることができる。しかし、第１サービスサーバ１００、装置情報収集サーバ６０、オーダ決定サーバ５０間の独立性が高い場合には、サーバ間での情報の共有が困難になる。例えば、本明細書で説明した消耗品宅配サービスを実施するためには、ユーザの住所、クレジットカード番号、トナーやインクの種類（例：通常品か大容量品か）、などの各種の情報を、第１サービスサーバ１００に登録する必要がある。しかし、各種の情報の全てを第１サービスサーバ１００に登録完了する前に、オーダ決定サーバ５０がステータス情報通知要求を送信し（Ｓ６２０）、装置情報収集サーバ６０がステータス情報を取得（Ｓ６３０）してしまい、注文指示が第１サービスサーバ１００に送信（Ｓ６５０）されてしまう、といった事態が発生してしまう場合がある。この場合、例えば、インクの種類の登録が完了していない場合には、ユーザが意図していない種類のインクがユーザに送付（Ｓ６７０）されてしまうなどの不具合が発生してしまう恐れがある。

実施例１の構成によれば、消耗品宅配サービスの対象となる多機能機（すなわち多機能機１０）の第１サービスサーバ１００への登録（Ｓ２７０）と、その多機能機で使用する使用部材の第１サービスサーバ１００への登録（Ｓ３１０）の両方が終わったことを、申請完了フラグ（Ｓ３２５）を用いることで、オーダ決定サーバ５０に認識させることが可能となる。これにより、オーダ決定サーバ５０は、消耗品宅配サービスを実行するために必要な全ての情報が第１サービスサーバ１００に登録完了したことを確認（Ｓ６１５：ＹＥＳ）した上で、多機能機１０から、ステータス情報を取得（Ｓ６３５）することが可能となる。これにより、多機能機１０で使用するインクの種類などが第１サービスサーバ１００に登録される前（すなわち、正しい種類のインクをユーザに送付することができる状態になる前）においては、多機能機１０からステータス情報を取得することがない。よって、不要な通信処理や不適切な注文処理が行われないように、オーダ決定サーバ５０を制御することが可能となる。

また第１サービスサーバ１００は、申請完了通知情報とともにデバイスＩＤを、オーダ決定サーバ５０に送信する（Ｓ３２０）。これによりオーダ決定サーバ５０は、消耗品宅配サービスを実行するために必要な全ての情報の登録が完了した多機能機を、送信されてきたデバイスＩＤに基づいて認識することができる。よって、多数の多機能機が存在する場合においても、オーダ決定サーバ５０は、消耗品宅配サービスの対象となる多機能機を確実に認識した上で消耗品宅配サービスを実行することができる。

オーダ決定サーバ５０は、注文指示を第１サービスサーバ１００へ送信する（Ｓ６５０）。これにより、インクカートリッジの種類（例：通常品か大容量品か）を特定することを、第１サービスサーバ１００へ実行させることができる。インクカートリッジの種類の特定を、オーダ決定サーバ５０で行う必要がないため、オーダ決定サーバ５０の処理負担を低減することができる。

実施例１の構成によれば、ユーザＡが使用する情報処理装置（すなわちＰＣ４０）へ、ＰＩＮコードを送信することができる（Ｓ１６０）。そして、送信したＰＩＮコードと同一のＰＩＮコードとともに送信されてきたデバイスＩＤを、ユーザＡが使用する多機能機のデバイスＩＤであると認識することができる（Ｓ１７７）。すなわち、ＰＩＮコードを、ユーザＡの承認情報として用いることができる。これにより、ユーザＡによって指定された多機能機のデバイスＩＤを、オーダ決定サーバ５０に取得させることができる。また、ＰＩＮコードは、ランダムに生成することができる（Ｓ１５３）。よって、多機能機登録プロセスのセキュリティ性を向上させることができる。

オーダ決定サーバ５０は、ステータス情報が示しているインクの残量が特定値よりも少ない場合（Ｓ６４０：ＹＥＳ）に、新しいインクカートリッジの注文が必要であると判断する。これにより、適切なタイミングで、インクを販売するサービスを提供する第１サービスサーバ１００にインクを注文することが可能となる（Ｓ６５０）。

オーダ決定サーバ５０は、予め定められた期間（例：１日）が経過したことに応じて（Ｓ６１０：ＹＥＳ）、ステータス情報を多機能機１０から取得することができる（Ｓ６３５）。これにより、ステータス情報を自動で多機能機１０から取得することが可能となる。

＜自動発注処理プロセス（その２）＞
図１３を用いて、実施例２に係る自動発注処理プロセスを説明する。実施例２に係る自動発注処理プロセスは、実施例１に係る自動発注処理プロセス（図６）の一部が変更されたプロセスである。図１３のＳ８１０〜Ｓ８４０の各ステップの内容は、図６のＳ６１０〜Ｓ６４０の各ステップの内容と同様である。従って、ここでは説明を省略する。

Ｓ８４２においてオーダ決定サーバ５０は、Ｓ８３５で受信したデバイスＩＤ「ｇｈｉ７８９」（すなわち多機能機１０のデバイスＩＤ）の申請完了フラグが「オン」であるか否かを判断する。当該判断は、オーダテーブルＴ３１（図８）を用いて行われる。否定判断される場合（Ｓ８４２：ＮＯ）にはＳ８４４へ進む。本実施形態の説明例では、ブラックのインクの残量が、特定値よりも少ない場合について説明を続ける。

Ｓ８４４においてオーダ決定サーバ５０は、警告画面情報を装置情報収集サーバ６０へ送信する。警告画面情報は、ブラックのインク残量が少なくなっていることを示す警告画面を、多機能機１０の表示部１４に表示させるための情報である。Ｓ８４６において装置情報収集サーバ６０は、警告画面情報を多機能機１０へ送信する。Ｓ８４８において多機能機１０は、警告画面を表示部１４に表示する。警告画面には、例えば、「ブラックのインク残量が僅かです。購入の手続きをしてください。」などの文字列が表示されていてもよい。

一方、Ｓ８４２において肯定判断される場合（Ｓ８４２：ＹＥＳ）には、Ｓ８５０へ進む。図１３のＳ８５０〜Ｓ８７０の各ステップの内容は、図６のＳ６５０〜Ｓ６７０の各ステップの内容と同様である。従って、ここでは説明を省略する。

＜実施例２の効果＞
実施例２の構成によれば、多機能機１０でインクの注文が必要であると判断された場合（Ｓ８４０：Ｙ）には、多機能機１０の申請完了フラグが「オン」であるか否かを判断することができる（Ｓ８４２）。多機能機１０の申請完了フラグが「オン」である場合（Ｓ８４２：ＹＥＳ）には、多機能機１０の第１サービスサーバ１００への登録（Ｓ２７０）と、多機能機１０で使用するインクの種類の第１サービスサーバ１００への登録（Ｓ３１０）の両方が終わっていると判断することができる。これにより、オーダ決定サーバ５０は、消耗品宅配サービスを実行するために必要な全ての情報が第１サービスサーバ１００に登録完了したことを確認（Ｓ８４２：ＹＥＳ）した上で、注文指示を第１サービスサーバ１００へ送信（Ｓ８５０）することが可能となる。よって、不要な通信処理や不適切な注文処理が行われないように、オーダ決定サーバ５０を制御することが可能となる。

＜多機能機登録プロセス（その２）＞
図１４〜図１６のシーケンス図を用いて、実施例３に係る多機能機登録プロセスを説明する。実施例３に係る多機能機登録プロセスは、自動発注するインクの種類を先に第１サービスサーバ１００へ登録し、自動発注の対象となる多機能機を後で第１サービスサーバ１００へ登録する形態である。なお、実施例３で使用する通信システム２の構成は、実施例１と同様であるため、説明を省略する。

例として、ユーザＡが自己のユーザアカウントを第１サービスサーバ１００に登録する処理（Ｓ１０〜Ｓ１８）が、実行済みである場合を説明する。またユーザＡが、多機能機１０をリアル店舗で既に購入済である場合を説明する。

Ｓ２７においてＰＣ４０は、消耗品宅配サービス登録の指示入力が行われたか否かを判断する。例えば、多機能機１０の説明書に消耗品宅配サービス登録のためのＵＲＬが記載されていてもよい。そして、当該ＵＲＬにアクセスすることによって、消耗品宅配サービス登録の指示入力が行われたと判断してもよい。

Ｓ３０においてＰＣ４０は、消耗品一覧要求を、第１サービスサーバ１００へ送信する。消耗品一覧要求は、消耗品候補情報を第１サービスサーバ１００に要求する情報である。消耗品候補情報は、複数種類の多機能機の各々で使用可能なインクカートリッジ種類を示す情報である。

Ｓ３５において第１サービスサーバ１００は、消耗品一覧情報をＰＣ４０へ送信する。消耗品一覧情報は、複数種類の多機能機の各々について、適合するインクカートリッジの型番を示す情報である。Ｓ４０においてＰＣ４０は、自動発注サービス申請画面Ｐ１（図１１および図１２参照）を表示部４８に表示する。

Ｓ４５においてＰＣ４０は、多機能機の型番の入力および消耗品種類の入力が行われたか否かを判断する。多機能機の型番の入力では、ユーザＡは、自己がリアル店舗で購入してきた多機能機１０の型番を入力する。なお、型番を入力する方法の具体例は、Ｓ２３５および図１１を用いて説明済みであるため、ここでは説明を省略する。また消耗品種類の入力では、ユーザＡは、インク種類（例：通常品か大容量品か）を入力する。なお、インク種類を入力する方法の具体例は、Ｓ３００および図１２を用いて説明済みであるため、ここでは説明を省略する。

Ｓ５０においてＰＣ４０は、ユーザ入力型番および消耗品選択情報を、第１サービスサーバ１００へ送信する。ユーザ入力型番は、ユーザＡによって入力された、多機能機１０の種類を示す型番である。消耗品選択情報は、ユーザ入力型番で指定された種類の多機能機において使用可能なインク種類のうち、ユーザＡが選択したインク種類（例：通常品、大容量品）を示す情報である。

Ｓ５３において第１サービスサーバ１００は、レコードＩＤを生成する。レコードＩＤは、ユーザＡのユーザアカウント（図１７、領域Ｒ３３）と消耗品選択情報（領域Ｒ３２）とを含んだデータセットに固有の識別情報である。レコードＩＤは、ランダムに生成される英数字であってもよい。換言するとレコードＩＤは、今回実行された消耗品宅配サービス登録の申請処理（Ｓ２７〜Ｓ５０）を識別する情報である。

Ｓ５５において第１サービスサーバ１００は、レコードＩＤ、ユーザ入力型番、消耗品選択情報、をユーザアカウントテーブルＴ２１に記憶させる。具体例を説明する。図１７のユーザアカウントテーブルＴ２１において、レコードＩＤ１５１およびユーザ入力型番１５２が記憶される（領域Ｒ３１）。また、消耗品選択情報に基づいて、インク型番１３７〜１４０が記憶される（領域Ｒ３２）。なお、デバイスＩＤ１３５および多機能機型番１３６は、この時点では空白である（領域Ｒ３４）。

Ｓ６０において１００は、レコードＩＤを含んだ多機能機登録ＵＲＬを、ＰＣ４０へ送信する。多機能機登録ＵＲＬは、後述する多機能機登録プロセス（図１５および図１６参照）を開始するためのウェブページにアクセスするための情報である。多機能機登録ＵＲＬは、例えば、電子メールによってＰＣ４０へ送信されてもよい。多機能機登録ＵＲＬは、レコードＩＤを、クエリ文字列として含んでいる。これにより、後述するＳ７１０〜Ｓ９４０ａの各ステップで通信されるＨＴＴＰリクエストおよびＨＴＴＰレスポンスの各々に、レコードＩＤをクエリ文字列として含ませることができる。Ｓ６５においてＰＣ４０は、受信した多機能機登録ＵＲＬをメモリ４２に記憶する。そしてフローが終了する。これにより、自動発注サービスの申請を一旦中断することができる。

図１５のＳ７１０においてＰＣ４０は、多機能機登録指示の入力が行われたか否かを判断する。多機能機登録指示は、ユーザＡが購入した多機能機１０を第１サービスサーバ１００に登録することを、第１サービスサーバ１００に指示する情報である。具体的には、Ｓ６５で記憶された多機能機登録ＵＲＬで示されるウェブページにアクセスしたか否かが判断される。ウェブページへのアクセスは、例えば、Ｓ６０で受信したメールに記載してある多機能機登録ＵＲＬをクリックすることによって行われてもよい。否定判断される場合（Ｓ７１０：ＮＯ）にはＳ７１０へ戻る。一方、肯定判断される場合（Ｓ７１０：ＹＥＳ）にはＳ７１５へ進む。これにより、中断されていた自動発注サービスの申請を再開することができる。

Ｓ７１５においてＰＣ４０は、多機能機登録要求を第１サービスサーバ１００へ送信する。Ｓ７１５では、多機能機登録要求は、ＨＴＴＰリクエストとして送信される。このＨＴＴＰリクエストには、前述したレコードＩＤが、クエリ文字列として付加されている。なお、Ｓ７１５からＳ９４０ａまでの通信の内容は、レコードＩＤを表わすクエリ文字例を常に含むが、その旨の記載を省略することがある。

図１５のＳ７２０〜Ｓ７７５の各ステップの内容は、図３のＳ１２０〜Ｓ１７５の各ステップの内容と同様である。同様に、図１６のＳ７７７およびＳ７８０、Ｓ９００〜Ｓ９３５の各ステップの内容は、図４のＳ１７７およびＳ１８０、Ｓ２００〜Ｓ２３５の各ステップの内容と同様である。従って、ここでは説明を省略する。

Ｓ９４０ａにおいてＰＣ４０は、装置選択情報を第１サービスサーバ１００へ送信する。Ｓ９４０ａで送信される装置選択情報には、Ｓ７１５で前述したレコードＩＤが、クエリ文字列として付加されている。

Ｓ９５０ａにおいて第１サービスサーバ１００は、Ｓ９４０ａで取得した装置選択情報に基づいて、多機能機１０が記憶していた装置情報２７に含まれていた型番を取得する。装置情報２７に含まれていた型番は、正確な型番である。また第１サービスサーバ１００は、Ｓ９４０ａで受信したＨＴＴＰレスポンスにクエリとして含まれているレコードＩＤを取得する。取得したレコードＩＤを用いて、ユーザＡのユーザアカウントテーブルＴ２１を特定する。そして、ユーザアカウントテーブルＴ２１に記憶されているユーザ入力型番１５２（図１７、領域Ｒ３１参照）と、装置情報２７に含まれていた正確な型番と、が一致するか否かを判断する。否定判断される場合（Ｓ９５０ａ：ＮＯ）には、Ｓ４５でユーザＡが入力した型番が間違っていた場合であると判断され、Ｓ９５５ａへ進む。

Ｓ９５５ａにおいて第１サービスサーバ１００は、報知画面情報をＰＣ４０へ送信する。報知画面情報は、ユーザＡがＳ４５で入力した多機能機型番が間違っていたことを示す報知画面を、多機能機１０の表示部１４に表示させるための情報である。Ｓ９６０ａにおいて多機能機１０は、報知画面を表示部１４に表示する。そしてフローを終了する。

一方、Ｓ９５０ａにおいて肯定判断される場合（Ｓ９５０ａ：ＹＥＳ）には、Ｓ９７０ａへ進む。Ｓ９７０ａにおいて第１サービスサーバ１００は、デバイスＩＤ１３５および多機能機型番１３６を、ユーザアカウントテーブルＴ２１に記憶させる（領域Ｒ３４参照）。これにより、ユーザＡのユーザアカウント（領域Ｒ３３）と消耗品選択情報（領域Ｒ３２）とを含んだデータセットに対応付けて、デバイスＩＤ１３５を記憶させることができる。

Ｓ９７５ａにおいて第１サービスサーバ１００は、選択されたデバイスＩＤをオーダ決定サーバ５０に送信する。Ｓ９８０においてオーダ決定サーバ５０は、受信したデバイスＩＤをオーダテーブルＴ３１に記憶させる。Ｓ９９０においてオーダ決定サーバ５０は、オーダテーブルＴ３１において、Ｓ３２０で受信したデバイスＩＤに対応する申請完了フラグ１４３を「オン」にする。そしてフローを終了する。

＜実施例３の効果＞
自動発注サービスの対象となる多機能機１０を、自動発注サービスを提供する第１サービスサーバ１００を介して購入する第１の場合がある。第１の場合では、多機能機１０を識別する情報（例：デバイスＩＤ）を、第１サービスサーバ１００が認識している状態で、多機能機１０で使用する部材の種類の登録を受け付けることができる。よって、自動発注サービスの申請受け付けをスムーズに行うことができる。一方、自動発注サービスの対象となる多機能機１０を、自動発注サービスを提供する第１サービスサーバ１００を介さずに購入する第２の場合がある。例えば、多機能機１０をリアル店舗で購入する場合である。第２の場合では、多機能機１０を識別する情報が、自動発注サービスを提供する第１サービスサーバ１００に登録されていない。従って、多機能機１０を識別する情報（例：デバイスＩＤ）を第１サービスサーバ１００が認識していない状態で、多機能機１０で使用する部材の種類の登録を第１サービスサーバ１００が受け付けなければならない場合が発生する。この場合、自動発注サービスの申請受け付けが困難である。

実施例３の構成によれば、ユーザは、自動発注サービスで送付してもらう使用部材の種類を第１サービスサーバ１００に登録する第１の申請処理（Ｓ２７〜Ｓ５５）を、先行して行うことができる。第１サービスサーバ１００は、先行して実施された第１の申請処理（Ｓ２７〜Ｓ５０）を識別する情報として、レコードＩＤを生成（Ｓ５３）し、ＰＣ４０へ送信（Ｓ６０）する。その後ユーザは、自動発注サービスの対象となる多機能機１０を識別する情報（例：デバイスＩＤ）を第１サービスサーバ１００に登録する、第２の申請処理を行うことができる。第２の申請処理では、レコードＩＤが、多機能機１０を識別する情報とともに第１サービスサーバ１００へ送信される（Ｓ９４０ａ）。レコードＩＤを用いることにより、第１の申請処理で先行して登録（Ｓ５５）されていた使用部材の種類と関連付けて、多機能機１０を識別する情報（例：デバイスＩＤ）を登録することができる（Ｓ９７０ａ）。これにより、使用部材の種類を第１サービスサーバ１００に登録するタイミングと、多機能機１０を識別する情報（例：デバイスＩＤ）を第１サービスサーバ１００に登録するタイミングとが互いに異なる場合においても、使用部材の種類と多機能機１０を識別する情報とを互いに関連付けて第１サービスサーバ１００に登録することが可能となる。従って、第１サービスサーバ１００が多機能機１０を識別する情報（例：デバイスＩＤ）を認識していない状態であっても、多機能機１０で使用する部材の種類の登録を第１サービスサーバ１００が受け付けることが可能となる。自動発注サービスの申請受け付けの自由度を高くすることが可能となる。

また、レコードＩＤを用いることにより、使用部材の種類を第１サービスサーバ１００に登録（Ｓ５５）した段階で、自動発注サービスの申請を一旦中断（Ｓ６５）することと、自動発注サービスの申請をユーザの任意のタイミングで再開（Ｓ７１０：ＹＥＳ）することが可能になる。自動発注サービスの申請受け付けの自由度を高くすることが可能となる。

実施例３の構成によれば、ユーザアカウントテーブルＴ２１に記憶されているユーザ入力型番１５２と、装置情報２７に含まれていた正確な型番と、が一致するか否かを判断することができる（Ｓ９５０ａ）。そして否定判断される場合（Ｓ９５０ａ：ＮＯ）には、報知画面を多機能機１０の表示部１４に表示させることができる（Ｓ９６０ａ）。これにより、ユーザが入力（Ｓ４５）した多機能機の型番に間違いがあった場合に、間違であることをユーザに報知することが可能となる。

実施例３の構成によれば、ユーザがユーザアカウントテーブルＴ１に登録している全ての多機能機を示す情報をＰＣ４０へ送信し（Ｓ９２０）、表示部４８に表示させることができる（Ｓ９３０）。そして、ユーザに選択された多機能機のデバイスＩＤを取得することができる（Ｓ９４０ａ）。これによりユーザは、自動発注サービスの対象となる多機能機を自由に選択することが可能となる。

実施例３の構成によれば、レコードＩＤにクエリ文字列を用いている。これにより、多機能機登録プロセスにおいて、通信システム２内で通信されるＨＴＴＰリクエストおよびＨＴＴＰレスポンスの各々に、レコードＩＤをクエリ文字列として含ませることができる。これにより、多機能機登録プロセスの実行中の何れのタイミングにおいても、レコードＩＤを参照することが可能となる。

オーダ決定サーバ５０は、ステータス情報が示しているインクの残量が特定値よりも少ない場合（Ｓ６４０：ＹＥＳ）に、新しいインクカートリッジの注文が必要であると判断する。これにより、適切なタイミングで、インクを販売するサービスを提供する第１サービスサーバ１００にインクを注文することが可能となる（Ｓ６５０）。

以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。例えば、以下の変形例が含まれる。

＜変形例１＞
ＰＩＮコードと、多機能機１０のメモリ２４に記憶されている装置情報２７とを、装置情報収集サーバ６０へ送信する形態は、様々であってよい。例えば、ＵＳＢケーブル１５を介して行う形態であってもよい。図１８を用いて、変形例を説明する。ＰＣ４０は、第１サービスサーバ１００からＰＩＮコードを受信（Ｓ１６０）すると、受信したＰＩＮコードおよびＰＩＮコード入力画面を表示部４８に表示する（Ｓ１６５ｂ）。Ｓ１６８ｂにおいてＰＣ４０は、ＰＩＮコードの入力を受け付けたか否かを判断する。ＰＩＮコードの入力態様の一例を説明する。ユーザＡは、ＰＣ４０の表示部４８に表示されたＰＩＮコードを暗記する。そしてユーザＡは、ＰＣ４０の操作部４９を操作して、ＰＩＮコードをＰＩＮコード入力画面に入力する。Ｓ１６８ｂにおいて否定判断される場合（Ｓ１６８ｂ：ＮＯ）にはＳ１６８ｂへ戻り、肯定判断される場合（Ｓ１６８ｂ：ＹＥＳ）にはＳ１７２ｂへ進む。Ｓ１７２ｂにおいてＰＣ４０は、装置情報要求を多機能機１０へ送信する。装置情報要求は、装置情報２７の送信を多機能機１０へ要求するための情報である。Ｓ１７４ｂにおいて多機能機１０は、メモリ２４に記憶されている装置情報２７（すなわち、デバイスＩＤ、型番、ノード名）を、ＰＣ４０へ送信する。Ｓ１７６ｂにおいてＰＣ４０は、Ｓ１６８ｂで入力されたＰＩＮコードと装置情報２７とを、装置情報収集サーバ６０へ送信する。Ｓ１７７以降の内容は説明済みであるため、ここでは説明を省略する。

これにより、ＰＣ４０の表示部４８に表示（Ｓ１６５）されたＰＩＮコードを多機能機１０に入力（Ｓ１７０）する、という手間をユーザにかけさせることがない。ユーザの利便性を高めることができる。

＜その他の変形例＞
ＰＩＮコードと装置情報２７とを装置情報収集サーバ６０へ送信する形態は、Ｓ１７５の形態に限られず、様々な形態であってよい。例えば、Ｓ１７０においてＰＩＮコードが多機能機１０に入力された場合（Ｓ１７０：ＹＥＳ）に、多機能機１０は、入力されたＰＩＮコードと装置情報２７を、ＰＣ４０へ送信してもよい。この送信処理には、ＵＳＢケーブル１５を用いてもよいし、不図示の無線通信を用いてもよい。ＰＣ４０は、多機能機１０から受信したＰＩＮコードおよび装置情報２７を、装置情報収集サーバ６０へ送信してもよい。

装置情報収集サーバ６０が多機能機１０からデバイスＩＤを「取得」する、という形態は、様々な形態が存在する。Ｓ１５５からＳ１８０において説明した形態に限られない。例えば、ＰＩＮコードを多機能機１０が装置情報収集サーバ６０に渡してもよい。そして装置情報収集サーバ６０がデバイスＩＤを作成して、ＰＩＮコードとともに多機能機１０に渡すとしてもよい。これによっても、装置情報収集サーバ６０は、多機能機１０からデバイスＩＤを「取得」することができる。

第１サービスサーバ１００が単体で各種処理を実行する形態を説明したが、この形態に限られない。第１サービスサーバ１００と第２サービスサーバ１１０とが協業し、１つのサーバとして機能することで、各種処理を実行してもよい。例えば、実施例１の図２〜図５のプロセスを実行する場合には、Ｓ１８〜Ｓ２７５を第２サービスサーバ１１０が実行し、Ｓ３１０以降は第１サービスサーバ１００が行うとしてもよい。このような場合においても、申請完了フラグ（Ｓ３２５）を用いることで、消耗品宅配サービスの対象となる多機能機（すなわち多機能機１０）の第２サービスサーバ１１０への登録と、その多機能機で使用する使用部材の第１サービスサーバ１００への登録の両方が終わったことを、オーダ決定サーバ５０に認識させることが可能となる。よって、不要な通信処理や不適切な注文処理が行われないように、オーダ決定サーバ５０を制御することが可能となる。また例えば、実施例３の図１４〜図１６のプロセスを実行する場合には、Ｓ３０〜Ｓ６０を第１サービスサーバ１００が実行し、Ｓ７１５以降は第１サービスサーバ１００が行うとしてもよい。このような場合においても、レコードＩＤを用いることで、使用部材の第１サービスサーバ１００への登録と、消耗品宅配サービスの対象となる多機能機（すなわち多機能機１０）の第２サービスサーバ１１０への登録と、の両方が終わったことを、オーダ決定サーバ５０に認識させることが可能となる。よって、不要な通信処理や不適切な注文処理が行われないように、オーダ決定サーバ５０を制御することが可能となる。

Ｓ３２０において、申請完了通知情報を第１サービスサーバ１００からオーダ決定サーバ５０へ通知する経路は様々であってよい。例えば、申請完了通知情報を第１サービスサーバ１００からＰＣ４０へ送信し、リダイレクトによってＰＣ４０からオーダ決定サーバ５０へ送信してもよい。

ユーザＡがユーザアカウントを第１サービスサーバ１００に登録済みである場合には、ユーザアカウントの登録処理（Ｓ１０〜Ｓ１８）は省略可能である。この場合ユーザＡは、自己のユーザアカウントを用いて、第１サービスサーバ１００にサインインすればよい。そして、Ｓ２０から処理を進めればよい。

Ｓ１７０において、多機能機１０がＰＩＮコードの入力を受け付ける形態は、様々であってよい。例えば、Ｓ１６５においてＰＣ４０は、受信したＰＩＮコードを示す２次元バーコードを、表示部４８に表示するか、印刷してもよい。Ｓ１７０において多機能機１０は、表示部４８に表示された２次元バーコード、または印刷された２次元バーコードを読み取ることで、ＰＩＮコードの入力を受け付けてもよい。

Ｓ２７の消耗品宅配サービス登録の指示入力を受け付けるタイミングは、多機能機１０の購入のタイミングに制限されない。例えば、多機能機を未購入であるタイミングであっても、購入予定の多機能機の型番が判明している場合には、消耗品宅配サービス登録の指示入力（Ｓ２７）を行うことが可能である。

Ｓ６２５において、装置情報収集サーバ６０から多機能機１０へステータス情報通知要求を送信する方法は、ＸＭＰＰコネクションを用いた方法に限られない。ファイアウォールを越えることができる方法であれば、何れの方法を用いてもよい。

装置情報収集サーバ６０と通信可能に接続される多機能機は、多機能機１０および１１に限られず、３台以上存在してもよい。インターネット６に接続されるサービスサーバは、第１サービスサーバ１００および第２サービスサーバ１１０に限られず、３台以上存在してもよい。通信システム２に含まれる機器として、多機能機１０および１１を例に挙げたが、これに限らない。指示データなどに基づいて、所定の画像を刺繍、キルティングするミシンでもよい。画像データに基づいた作品、製品を形成するために、飾り縫い、縫製などをおこなうミシンでもよい。指示データなどに基づいて、吹き付け、削りだしなどで、３Ｄ画像を生成する３Ｄプリンタでもよい。何らかの情報を定期的に取得するセンサ装置でも良い。

図７のユーザアカウントテーブルＴ１、図８のオーダテーブルＴ３１、図９および図１０のユーザアカウントテーブルＴ２１、図１１および図１２の自動発注サービス申請画面Ｐ１、の各々は、一例である。様々な記憶態様や表示態様を用いることが可能である。

多機能機１０は、画像処理装置の一例である。ＰＣ４０は、情報処理装置の一例である。インターネット６は、ネットワークの一例である。ネットワークインターフェース１０１および５１は、通信インターフェースの一例である。メモリ１０４は、第１記憶部の一例である。第１サービスサーバ１００、オーダ決定サーバ５０および装置情報収集サーバ６０は、サーバ装置の一例である。ユーザアカウントは、第１識別情報の一例である。Ｓ１５を実行するＣＰＵは、第１取得手段の一例である。消耗品候補情報は、使用部材候補情報の一例である。Ｓ３０を実行するＣＰＵは、第１受信手段の一例である。Ｓ３５を実行するＣＰＵは、第１送信手段の一例である。消耗品選択情報は、使用部材情報の一例である。Ｓ５０を実行するＣＰＵは、第２取得手段の一例である。Ｓ５５を実行するＣＰＵは、第１記憶制御手段の一例である。レコードＩＤは、第２識別情報の一例である。Ｓ６０を実行するＣＰＵは、第２送信手段の一例である。ＰＩＮコードは、パスワード情報の一例である。Ｓ７６０を実行するＣＰＵは、第３送信手段の一例である。デバイスＩＤは、第３識別情報の一例である。Ｓ９４０ａを実行するＣＰＵは、第３取得手段の一例である。Ｓ９７０ａを実行するＣＰＵは、第２記憶制御手段の一例である。Ｓ６２５を実行するＣＰＵは、第４送信手段の一例である。Ｓ６３０を実行するＣＰＵは、第４取得手段の一例である。Ｓ６４０を実行するＣＰＵは、判断手段の一例である。Ｓ６６０を実行するＣＰＵは、処理実行手段の一例である。ユーザ入力型番は、第１の画像処理装置種類情報の一例である。特定画像処理装置が送信してきた型番は、第２の画像処理装置種類情報の一例である。Ｓ９４０ａを実行するＣＰＵは、第５取得手段の一例である。Ｓ９５５ａを実行するＣＰＵは、第５送信手段の一例である。装置一覧要求は、画像情報の取得要求の一例である。Ｓ９１０を実行するＣＰＵは、第２受信手段の一例である。Ｓ９２０を実行するＣＰＵは、第６送信手段の一例である。インクは、消耗部材の一例である。

６：インターネット、１０および１１：多機能機、４０：ＰＣ、５０：オーダ決定サーバ、６０：装置情報収集サーバ、１００：第１サービスサーバ

Claims (10)

1. 複数の画像処理装置および情報処理装置とネットワークを介して通信可能な通信インターフェースと、
   第１記憶部と、
   を備えたサーバ装置であって、
   前記情報処理装置を使用している第１ユーザに固有の第１識別情報を前記情報処理装置から取得する第１取得手段と、
   複数の画像処理装置が有する複数の画像処理装置種類の各々で使用可能な部材を示す使用部材候補情報の要求を受信する第１受信手段と、
   前記使用部材候補情報を前記情報処理装置に送信する第１送信手段と、
   前記複数の画像処理装置種類のうちから前記第１ユーザによって指定された指定画像処理装置種類を有する画像処理装置で使用されることが指示された使用部材を示す使用部材情報を、前記情報処理装置から取得する第２取得手段と、
   前記第１取得手段で取得した前記第１識別情報および前記第２取得手段で取得した前記使用部材情報を、互いに対応付けて前記第１記憶部に記憶させる第１記憶制御手段と、
   前記第１記憶制御手段が記憶させた、前記第１識別情報および前記使用部材情報のデータセットに固有の第２識別情報を、前記情報処理装置へ送信する第２送信手段と、
   前記情報処理装置へパスワード情報を送信する第３送信手段と、
   前記第２送信手段が前記第２識別情報を前記情報処理装置へ送信した後に、特定画像処理装置に固有の第３識別情報と、前記第２送信手段で送信した前記第２識別情報を、前記画像処理装置から取得する第３取得手段と、
   ここで前記特定画像処理装置は、前記指定画像処理装置種類を有する画像処理装置であって前記第１ユーザによって指定された画像処理装置であり、
   前記第３取得手段は、前記第３送信手段で送信した前記パスワード情報と同一のパスワード情報とともに送信されてくる前記第３識別情報を、前記特定画像処理装置に固有の第３識別情報として取得し、
   取得した前記第３識別情報を、前記第２識別情報で識別される前記データセットに対応付けて前記第１記憶部にさらに記憶させる第２記憶制御手段と、
   前記第２記憶制御手段が前記第３識別情報を記憶させた後に特定の条件が成立することに応じて、前記第３識別情報で識別される前記特定画像処理装置にステータス情報取得要求を送信する第４送信手段と、
   前記ステータス情報取得要求を送信した後に、前記特定画像処理装置からステータス情報を取得する第４取得手段と、
   取得した前記ステータス情報に基づいて、前記特定画像処理装置で使用される部材である使用部材の注文が必要か否かを判断する判断手段と、
   前記判断手段で前記使用部材の注文が必要であると判断された場合に、前記第１識別情報で識別される前記第１ユーザへ、前記使用部材情報で識別される種類の前記使用部材を送付する処理実行手段と、
   を備えることを特徴とするサーバ装置。
2. 前記第２取得手段は、前記指定画像処理装置種類を示す第１の画像処理装置種類情報であって前記第１ユーザによって入力された前記第１の画像処理装置種類情報を前記情報処理装置からさらに取得し、
   前記第１記憶制御手段は、前記第１識別情報および前記使用部材情報に対応付けて、前記第１の画像処理装置種類情報をさらに前記第１記憶部に記憶させ、
   前記第２送信手段が前記第２識別情報を送信した後に、前記特定画像処理装置の種類を示す第２の画像処理装置種類情報であって前記特定画像処理装置が自ら備えている前記第２の画像処理装置種類情報を前記特定画像処理装置から取得する第５取得手段と、
   前記第１記憶部に記憶されている前記第１の画像処理装置種類情報と、前記第５取得手段が取得した前記第２の画像処理装置種類情報とが異なる場合に、前記第１の画像処理装置種類情報が正しくないことを示す画像を前記情報処理装置の表示部に表示させる表示情報を、前記情報処理装置へ送信する第５送信手段と、
   をさらに備えることを特徴とする請求項１に記載のサーバ装置。
3. 前記第１記憶部は、複数の前記第３識別情報を記憶しており、
   前記サーバ装置は、
   前記第１記憶部に記憶されている複数の前記第３識別情報の各々を表す画像情報の取得要求を、前記情報処理装置から受信する第２受信手段と、
   前記画像情報を前記情報処理装置へ送信する第６送信手段と、
   をさらに備え、
   前記第５取得手段は、前記第６送信手段が前記画像情報を送信した後に、前記第２の画像処理装置種類情報を前記特定画像処理装置から取得することを特徴とする請求項２に記載のサーバ装置。
4. 前記第２送信手段が送信する前記第２識別情報は、前記ネットワーク上の前記サーバ装置の位置を示すUniform Resource Identifier形式のデータにクエリ文字列として含まれている情報であることを特徴とする請求項１〜３の何れか１項に記載のサーバ装置。
5. 前記使用部材は、前記画像処理装置で画像を記録媒体に形成するために用いられる消耗部材であり、
   前記サーバ装置は、前記消耗部材を販売するサービスを提供することが可能な装置であり、
   前記ステータス情報は、前記消耗部材の残量を示す情報であり、
   前記判断手段は、前記消耗部材の残量が予め定められた特定値よりも少ないことを示す場合に、前記使用部材の注文が必要であると判断することを特徴とする請求項１〜４の何れか１項に記載のサーバ装置。
6. 前記特定の条件は、予め定められた期間が経過したことであることを特徴とする請求項１〜５の何れか１項に記載のサーバ装置。
7. 前記第３取得手段は、前記特定画像処理装置から出力された前記第３識別情報を、前記情報処理装置を介して取得することを特徴とする請求項１〜６の何れか１項に記載のサーバ装置。
8. 複数の画像処理装置、情報処理装置、サーバ装置が互いにネットワークを介して通信可能に構成されている通信システムであって、
   前記サーバ装置は、
   前記情報処理装置を使用している第１ユーザに固有の第１識別情報を前記情報処理装置から取得する第１取得手段と、
   複数の画像処理装置が有する複数の画像処理装置種類の各々で使用可能な部材を示す使用部材候補情報の要求を受信する第１受信手段と、
   前記使用部材候補情報を前記情報処理装置に送信する第１送信手段と、
   前記複数の画像処理装置種類のうちから前記第１ユーザによって指定された指定画像処理装置種類を有する画像処理装置で使用されることが指示された使用部材を示す使用部材情報を、前記情報処理装置から取得する第２取得手段と、
   前記第１取得手段で取得した前記第１識別情報および前記第２取得手段で取得した前記使用部材情報を、互いに対応付けて第１記憶部に記憶させる第１記憶制御手段と、
   前記第１記憶制御手段が記憶させた、前記第１識別情報および前記使用部材情報のデータセットに固有の第２識別情報を、前記情報処理装置へ送信する第２送信手段と、
   前記情報処理装置へパスワード情報を送信する第３送信手段と、
   前記第２送信手段が前記第２識別情報を前記情報処理装置へ送信した後に、特定画像処理装置に固有の第３識別情報と、前記第２送信手段で送信した前記第２識別情報を、前記画像処理装置から取得する第３取得手段と、
   ここで前記特定画像処理装置は、前記指定画像処理装置種類を有する画像処理装置であって前記第１ユーザによって指定された画像処理装置であり、
   前記第３取得手段は、前記第３送信手段で送信した前記パスワード情報と同一のパスワード情報とともに送信されてくる前記第３識別情報を、前記特定画像処理装置に固有の第３識別情報として取得し、
   取得した前記第３識別情報を、前記第２識別情報で識別される前記データセットに対応付けて前記第１記憶部にさらに記憶させる第２記憶制御手段と、
   前記第２記憶制御手段が前記第３識別情報を記憶させた後に特定の条件が成立することに応じて、前記第３識別情報で識別される前記特定画像処理装置にステータス情報取得要求を送信する第４送信手段と、
   前記ステータス情報取得要求を送信した後に、前記特定画像処理装置からステータス情報を取得する第４取得手段と、
   取得した前記ステータス情報に基づいて、前記特定画像処理装置で使用される部材である使用部材の注文が必要か否かを判断する判断手段と、
   前記判断手段で前記使用部材の注文が必要であると判断された場合に、前記第１識別情報で識別される前記第１ユーザへ、前記使用部材情報で識別される種類の前記使用部材を送付する処理実行手段と、
   を備えることを特徴とする通信システム。
9. 前記サーバ装置は、前記特定画像処理装置の候補となる候補装置の各々を識別する候補装置識別情報を前記第１記憶部に記憶させる第３記憶制御手段をさらに備えており、
   前記情報処理装置は、
   前記サーバ装置から前記第２識別情報を受信し、前記情報処理装置が備える第２記憶部に記憶させる第４記憶制御手段と、
   前記第４記憶制御手段が前記第２識別情報を記憶させた後に、前記候補装置識別情報を前記サーバ装置から受信する第３受信手段と、
   前記候補装置識別情報に基づいて、前記情報処理装置が備える表示部に前記候補装置の各々を示す複数の装置画像を表示する表示手段と、
   前記複数の装置画像のうちから、前記特定画像処理装置に対応する装置画像を選択する操作の入力を受け付けることに応じて、選択された特定画像処理装置を識別する前記第３識別情報を、前記第２記憶部に記憶されている前記第２識別情報と対応付けて前記サーバ装置へ送信する第５送信手段と、
   を備えることを特徴とする請求項８に記載の通信システム。
10. 複数の画像処理装置および情報処理装置とネットワークを介して通信可能な通信インターフェースと、
    第１記憶部と、
    を備えたサーバ装置のコンピュータにおいて実行されるプログラムであって、
    であって、
    前記コンピュータを、
    前記情報処理装置を使用している第１ユーザに固有の第１識別情報を前記情報処理装置から取得する第１取得手段と、
    複数の画像処理装置が有する複数の画像処理装置種類の各々で使用可能な部材を示す使用部材候補情報の要求を受信する第１受信手段と、
    前記使用部材候補情報を前記情報処理装置に送信する第１送信手段と、
    前記複数の画像処理装置種類のうちから前記第１ユーザによって指定された指定画像処理装置種類を有する画像処理装置で使用されることが指示された使用部材を示す使用部材情報を、前記情報処理装置から取得する第２取得手段と、
    前記第１取得手段で取得した前記第１識別情報および前記第２取得手段で取得した前記使用部材情報を、互いに対応付けて前記第１記憶部に記憶させる第１記憶制御手段と、
    前記第１記憶制御手段が記憶させた、前記第１識別情報および前記使用部材情報のデータセットに固有の第２識別情報を、前記情報処理装置へ送信する第２送信手段と、
    前記情報処理装置へパスワード情報を送信する第３送信手段と、
    前記第２送信手段が前記第２識別情報を前記情報処理装置へ送信した後に、特定画像処理装置に固有の第３識別情報と、前記第２送信手段で送信した前記第２識別情報を、前記画像処理装置から取得する第３取得手段と、
    ここで前記特定画像処理装置は、前記指定画像処理装置種類を有する画像処理装置であって前記第１ユーザによって指定された画像処理装置であり、
    前記第３取得手段は、前記第３送信手段で送信した前記パスワード情報と同一のパスワード情報とともに送信されてくる前記第３識別情報を、前記特定画像処理装置に固有の第３識別情報として取得し、
    取得した前記第３識別情報を、前記第２識別情報で識別される前記データセットに対応付けて前記第１記憶部にさらに記憶させる第２記憶制御手段と、
    前記第２記憶制御手段が前記第３識別情報を記憶させた後に特定の条件が成立することに応じて、前記第３識別情報で識別される前記特定画像処理装置にステータス情報取得要求を送信する第４送信手段と、
    前記ステータス情報取得要求を送信した後に、前記特定画像処理装置からステータス情報を取得する第４取得手段と、
    取得した前記ステータス情報に基づいて、前記特定画像処理装置で使用される部材である使用部材の注文が必要か否かを判断する判断手段と、
    前記判断手段で前記使用部材の注文が必要であると判断された場合に、前記第１識別情報で識別される前記第１ユーザへ、前記使用部材情報で識別される種類の前記使用部材を送付する処理実行手段と、
    して機能させることを特徴とするプログラム。