JP2019016062A - 管理システム - Google Patents

Abstract

【課題】 交換品の在庫数を適切に管理することができる技術を提供する。【解決手段】 サーバが、演算した各交換品の各交換時期より前の所定の各時期に、各機器で使用されている前記各交換品が各交換時期に近付いたことをユーザに報知する交換情報を前記各機器および／または前記各機器に対応する各端末に送信し、および／または、前記各機器のユーザに交換用の新しい各交換品を発送するための発送情報を生成し、前記交換情報の送信および／または前記発送情報の生成に基づいて前記各交換時期より前の前記所定の各時期に前記各機器のユーザによって購入される前記新しい各交換品の購入数の合計を予測し、予測した前記新しい各交換品の購入数の合計と、前記所定の各時期の交換品の在庫数とに基づいて、前記所定の各時期の交換品の在庫の不足数を演算し、演算した前記在庫の不足数に応じて交換品の在庫を補充するための補充情報を生成する。【選択図】 図１０

Description

本明細書で開示する技術は、管理システムに関する。

特許文献１に開示されている管理システムは、サーバ（管理コンピュータ）と、サーバと通信可能な複数の機器（プリンタ）とを備えている。各機器（プリンタ）では、インクタンク等の各交換品が使用されている。各交換品（インクタンク等）は、使用による消耗によって交換を要する交換状態になる。サーバは、各機器で使用されている各交換品の交換時期を演算する。また、サーバは、交換品の在庫数に基づいて交換品の在庫を補充するための補充情報を生成する。

特開２００２‐０９２４３９号公報

特許文献１の管理システムでは、各機器（プリンタ）で各交換品（インクタンク等）が使用されており、各機器の運転状況によって各機器で使用されている各交換品の使用状況が異なってくる。そのため、各交換品が交換状態になる時期が各機器によって異なってくる。早い時期に交換状態になる交換品もあれば、遅い時期に交換状態になる交換品もある。これによって、各機器のユーザが使用している交換品を新しい交換品に交換する交換時期が異なってくる。また、各機器のユーザが交換用の新しい交換品を購入する時期も異なってくる。そのため、複数の機器のユーザによって購入される新しい交換品の購入数の合計が時期によって異なってくる。これらは各時期の交換品の在庫数に影響を与えるので、交換品の在庫数が時期によって変動する。万が一交換品の在庫数に不足が生じると、各機器のユーザが交換用の新しい交換品を購入するときに支障が生じる。そこで本明細書では、交換品の在庫数を適切に管理することができる技術を提供する。

本明細書が開示する管理システムは、サーバと、前記サーバと通信可能な複数の機器を備えている。前記各機器では、各交換品が使用される。前記各交換品は、使用による消耗によって交換を要する交換状態になると新しい各交換品に交換されるものである。前記各機器は、前記各交換品が前記各機器で使用されたことを特定できる情報を前記サーバに送信する。前記サーバは、前記各機器から前記情報を受信すると、前記各機器で使用されている前記各交換品の所定の消耗率に基づいて、前記各機器で使用されている前記各交換品が交換状態になる交換時期をそれぞれ演算する。また、前記サーバは、演算した前記各交換品の前記各交換時期より前の所定の各時期に、前記各機器で使用されている前記各交換品が前記各交換時期に近付いたことをユーザに報知する交換情報を前記各機器および／または前記各機器に対応する各端末に送信し、および／または、前記各機器のユーザに交換用の新しい各交換品を発送するための発送情報を生成し、前記交換情報の送信および／または前記発送情報の生成に基づいて前記各交換時期より前の前記所定の各時期に前記各機器のユーザによって購入される前記新しい各交換品の購入数の合計を予測する。また、前記サーバは、予測した前記新しい各交換品の購入数の合計と、前記所定の各時期の交換品の在庫数とに基づいて、前記所定の各時期の交換品の在庫の不足数を演算し、演算した前記在庫の不足数に応じて交換品の在庫を補充するための補充情報を生成する。

この構成によれば、サーバが各交換品の消耗率に基づいて各交換品の交換時期を演算するので交換時期を精度良く演算することができる。また、各交換品の交換時期より前の所定の各時期に、サーバが各機器および／または各端末に交換情報を送信する、および／または、サーバが新しい各交換品の発送情報を生成するので、各機器のユーザが新しい各交換品を購入するタイミングを、各交換時期より前の所定の各時期とすることができる。そして、サーバが、交換情報の送信および／または発送情報の生成に基づいて、所定の各時期に各機器のユーザによって購入される新しい各交換品の購入数の合計を予測する。すなわち、上記の管理システムでは、各機器のユーザが新しい各交換品を所定の各時期に購入することを前提として、サーバが新しい各交換品の購入数の合計を予測する。また、上記の管理システムでは、サーバが、予測した新しい各交換品の購入数の合計と、各交換時期より前の所定の各時期の交換品の在庫数とに基づいて、所定の各時期の交換品の在庫の不足数を演算するので、ユーザによる新しい交換品の購入を想定に入れておくことができ、交換品の在庫の不足数を精度良く演算することができる。また、サーバが、演算した在庫の不足数に応じて交換品の在庫を補充するための補充情報を生成するので、交換品の在庫数を適切に管理することができる。

また、上記の管理システムでは、前記各機器は、前記各機器のユーザによって操作された場合に操作された日時を特定できる日時情報を前記サーバに送信してもよい。また、前記サーバは、前記発送情報を生成する場合に、前記各機器から受信する前記日時情報に基づいて前記各機器のユーザが在宅している在宅日時を予測し、予測した前記在宅日時に応じた日時に前記新しい各交換品が前記各機器のユーザに配達されるように前記発送情報を生成してもよい。

この構成によれば、各機器がユーザによって操作された場合に日時情報をサーバに送信するので、ユーザが確実に在宅している日時の日時情報をサーバに送信することができる。また、サーバがその日時情報に基づいて在宅日時を予測するので、ユーザが確実に在宅している日時を精度良く予測することができる。また、サーバが予測した在宅日時に応じた日時に新しい各交換品が各機器のユーザに配達されるように発送情報を生成するので、各ユーザが在宅している日時に新しい各交換品が配達される確率を高めることができる。

実施例に係る管理システム１の構成を示す図である。 実施例に係る機器２０の斜視図である。 第１実施例に係る第１テーブル５０１の一例の図である。 第１実施例に係る第２テーブル５０２の一例の図である。 第１実施例に係る第３テーブル５０３の一例の図である。 第１実施例に係る第３テーブル５０３の他の一例の図である。 実施例に係る登録処理のフローチャートである。 実施例に係る初期設定処理のフローチャートである。 実施例に係る運転処理のフローチャートである。 実施例に係る演算処理のフローチャートである。 実施例に係る交換時期の演算の一例の図である。 実施例に係る不足数演算処理のフローチャートである。 実施例に係るサーバ側報知処理のフローチャートである。 実施例に係る機器側報知処理のフローチャートである。 第２実施例に係る発送処理のフローチャートである。 第３実施例に係る第１テーブル５０１の一例の図である。 第３実施例に係る第２テーブル５０２の一例の図である。 第４実施例に係る第２テーブル５０２の一例の図である。 第５実施例に係る第４テーブル５０４の一例の図である。 第５実施例に係る日時情報送信処理のフローチャートである。 第５実施例に係る日時情報記憶処理のフローチャートである。 第５実施例に係る発送処理のフローチャートである。

（第１実施例）
図面を参照して実施例に係る管理システム１について説明する。図１に示すように、実施例に係る管理システム１は、サーバ１００と、複数の機器２０（２０Ａ、２０Ｂ、２０Ｃ、２０Ｄ）を備えている。また、管理システム１は、第１ホストコンピュータ３０１と、第２ホストコンピュータ４０１を備えている。サーバ１００と、複数の機器２０と、第１ホストコンピュータ３０１と、第２ホストコンピュータ４０１は、インターネット２００を通じて通信可能に接続されている。各機器２０は、各ルータ４０を介してインターネット２００に接続されている。各機器２０は、例えば給湯器のリモコンを介して各ルータ４０に接続されていてもよい。以下の説明では、複数の機器２０Ａ、２０Ｂ、２０Ｃ、２０Ｄをまとめて機器２０と呼ぶ場合がある。なお、機器２０の数は特に限定されるものではない。

管理システム１のサーバ１００は、演算部と記憶部と通信部（いずれも図示省略）を備えている。サーバ１００は、各種の情報処理を実行することができる。サーバ１００が実行する情報処理については後述する。

管理システム１の機器２０は、住宅１０に設置されている。各住宅１０Ａ、１０Ｂ、１０Ｃ、１０Ｄに各機器２０Ａ、２０Ｂ、２０Ｃ、２０Ｄが設置されている。各機器２０Ａ、２０Ｂ、２０Ｃ、２０Ｄは、各住宅１０Ａ、１０Ｂ、１０Ｃ、１０Ｄで使用される。住宅１０で使用される機器２０は特に限定されるものではないが、本実施例における機器２０は、住宅用の食器洗浄機である。住宅用の食器洗浄機（機器２０）は、食器洗浄機用の洗剤を使用して食器を洗浄する機器である。

図２に示すように、機器２０は、制御部２１と表示部２２を備えている。また、機器２０は、その他に記憶部と通信部（いずれも図示省略）を備えている。機器２０の制御部２１は、各種の情報処理を実行することができる。機器２０の制御部２１が実行する情報処理については後述する。また、機器２０の表示部２２は、各種の情報を表示することができる。この表示部２２は、例えば液晶ディスプレイである。

管理システム１の機器２０（食器洗浄機）では、交換品３０が使用される。機器２０で使用される交換品３０は特に限定されるものではないが、本実施例における交換品３０は、食器洗浄機用の洗剤である。食器洗浄機用の洗剤（交換品３０）は、食器洗浄機（機器２０）で食器を洗浄するために使用される。各機器（食器洗浄機）２０Ａ、２０Ｂ、２０Ｃ、２０Ｄで、各交換品（洗剤）３０Ａ、３０Ｂ、３０Ｃ、３０Ｄが使用される。各交換品（洗剤）３０Ａ、３０Ｂ、３０Ｃ、３０Ｄは、同一の商品であり、どの機器２０Ａ、２０Ｂ、２０Ｃ、２０Ｄでも使用できる。以下の説明では、複数の交換品３０Ａ、３０Ｂ、３０Ｃ、３０Ｄをまとめて交換品３０と呼ぶ場合がある。なお、交換品３０の数は特に限定されるものではない。また、交換品３０が使用されない機器は管理システム１から除外して考えることができる。

機器２０で使用される交換品３０は、交換可能な商品である。例えば機器２０のユーザが、機器２０で使用していた古い交換品３０を新しい交換品３０に交換する。使用された古い交換品３０は、順次、新しい交換品３０に交換される。例えば機器２０Ａでは、交換品３０Ａ１、３０Ａ２、３０Ａ３、３０Ａ４・・・が順次使用されて交換される。機器２０のユーザは、交換品３０を交換する際に新しい交換品３０を購入する。各交換品３０には各製品番号が付されている。

また、機器２０（食器洗浄機）で使用される交換品３０（洗剤）は、新品の状態では、満容量の状態である。交換品３０（洗剤）の満容量は、例えば５００ｇである。この交換品３０は、例えば容器に洗剤が収容された状態の商品である。交換品３０が新品の状態では、容器に満容量（５００ｇ）の洗剤が収容されている。図３に示すように、各製品番号の各交換品３０について各満容量が設定されている。

また、交換品３０（洗剤）は、機器２０（食器洗浄機）で使用されることによって消耗する商品である。機器２０（食器洗浄機）が使用される毎に交換品３０（洗剤）が使用されて消耗する。本実施例において交換品３０（洗剤）が消耗するとは、洗剤の量が減少してゆくことである。例えば、図４に示すように、機器２０（食器洗浄機）が１回使用される毎に交換品３０（洗剤）が１回使用され、それによって５ｇの洗剤が使用されて消耗する。また、機器２０（食器洗浄機）と交換品３０（洗剤）が１日で３回使用されるとすると、１日で１５ｇの洗剤が使用されて消耗する。機器２０Ａでは、１日で１５ｇの洗剤が使用されて消耗する。機器２０Ａ（食器洗浄機）における交換品３０Ａ（洗剤）の消耗率は、１５ｇ／日である。

また、交換品３０（洗剤）は、使用されてある程度消耗すると所定の交換状態になる。所定の交換状態は、交換品３０（洗剤）の交換を要する状態である。例えば、新品の状態では満容量の状態であった交換品３０（洗剤）がその後に使用されて容量が０（ゼロ）になった状態が交換状態である。使用されて消耗した交換品３０（洗剤）は、所定の交換状態になると新しい交換品３０に交換される。例えば、機器２０Ａでは、使用していた交換品３０Ａ１が所定の交換状態になると、新しい交換品３０Ａ２に交換され、その交換品３０Ａ２が所定の交換状態になると、更に新しい交換品３０Ａ３に交換される。各機器２０で使用されている各交換品３０が所定の交換状態になる毎に新しい各交換品３０に交換される。交換品３０（洗剤）はいわゆる消耗品である。

図１に示す管理システム１の第１ホストコンピュータ３０１は、管理システム１の管理者の倉庫３００に設置されている。第１ホストコンピュータ３０１は、演算部と記憶部と通信部（いずれも図示省略）を備えている。第１ホストコンピュータ３０１は、各種の情報処理を実行することができる。管理者の倉庫３００には、新しい交換品３０が保管されている。すなわち、管理者の倉庫３００には、交換品３０の在庫が存在している。倉庫３００に保管されている交換品３０の在庫は、まだ機器２０で使用されていない新しい交換品３０である。第１ホストコンピュータ３０１は、倉庫３００に保管されている交換品３０の在庫数の情報をサーバ１００に送信する。サーバ１００は、交換品３０の在庫数の情報を図５に示す第３テーブル５０３に記憶する。

また、管理システム１の第２ホストコンピュータ４０１は、仕入先の倉庫４００に設置されている。仕入先は、管理システム１の管理者が商品（交換品３０）を仕入れるときの発注先である。第２ホストコンピュータ４０１は、演算部と記憶部と通信部（いずれも図示省略）を備えている。第２ホストコンピュータ４０１は、各種の情報処理を実行することができる。仕入先の倉庫４００には、出荷用の複数の交換品３０が保管されている。第２ホストコンピュータ４０１は、交換品３０の在庫を管理者の倉庫３００に補充するための補充情報をサーバ１００から受信する。

次に、サーバ１００に記憶されている情報について説明する。サーバ１００には、第１テーブル５０１と第２テーブル５０２と第３テーブル５０３が記憶されている。

まず第１テーブル５０１について説明する。図３に示すように、第１テーブル５０１には、交換品３０の製品番号と満容量が記憶されている。製品番号は、様々な交換品３０の種類のうちから１個の交換品３０の種類を特定できる情報である。満容量は、交換品３０（洗剤）が新品の状態における洗剤の量である。第１テーブル５０１では、交換品３０の製品番号と満容量が対応している。

次に、第２テーブル５０２について説明する。図４に示すように、第２テーブル５０２には、機器２０で使用されている交換品３０に関する情報が記憶されている。第２テーブル５０２には、交換品３０に関する満容量、現在量、消耗量、消耗率が記憶されている。また、第２テーブル５０２には、交換品３０に関する交換時期、報知時期、購入時期が記憶されている。第２テーブル５０２は、機器２０で交換品３０が使用される毎に更新される。

第２テーブル５０２に記憶されている交換品３０の満容量は、上述したように、古い交換品３０から新しい交換品３０に交換されたときの初期の洗剤の量である。満容量は、例えば５００ｇである。

また、交換品３０の現在量は、所定の容器に残存している現在の洗剤の量である。古い交換品３０から新しい交換品３０に交換された初期では、上記の満容量が現在量となる。交換品３０の現在量は、機器２０で洗剤が使用される毎に減少してゆく。

交換品３０の消耗量（ｇ／回）は、１回あたりに使用されて消耗する洗剤の量である。各交換品３０の消耗量は、各機器２０や各交換品３０の種類に応じて予め設定されている。例えば、交換品３０の消耗量は５ｇ／回である。

交換品３０の消耗率（ｇ／日）は、１日あたりに使用されて消耗する洗剤の量である。各交換品３０の消耗率は、各機器２０における交換品３０の過去の使用実績に基づいて算出される。例えば、機器２０Ａで使用される交換品３０Ａの消耗率は１５ｇ／日である。この消耗率は、例えば、過去３０日間に機器２０Ａで交換品３０Ａが１日あたり３回使用され、１回使用される毎に５ｇの洗剤が使用されて消耗した実績により算出されている。

また、交換品３０の交換時期は、機器２０で交換品３０が使用されて消耗することによって交換状態になる時期である。交換時期は、古い交換品３０から新しい交換品３０に交換されると予測される時期である。交換時期は、交換品３０の現在量と消耗率に基づいて演算される。例えば、機器２０Ａで使用されている洗剤の現在量が１８０ｇであり、その消耗率が１５ｇ／日であるとすると、本日より１２日後に洗剤が無くなる。よって、この場合の交換時期は本日より１２日後である。

また、交換品３０の報知時期は、機器２０で使用されている古い交換品３０が交換時期に近付いたことを機器２０のユーザに報知する時期である。報知時期は、上記の交換時期より前の所定の時期である。報知時期は例えば交換時期より７日前の日である。報知時期に交換情報を機器２０のユーザに報知することによって、近日中にユーザが古い交換品３０を新しい交換品３０に交換すると予測される。交換情報は、機器２０で使用されている交換品３０が交換時期に近付いたことを示す情報である。また、機器２０のユーザが交換品３０を交換するために新しい交換品３０を購入すると予測される。すなわち、機器２０のユーザが報知時期に新しい交換品３０を購入すると予測される。例えば、交換時期より７日前（報知時期）に交換情報が報知された場合、その日（交換時期より７日前）に機器２０のユーザが新しい交換品３０を購入すると予測される。なお、報知時期は、ユーザが任意に設定してもよい。

また、交換品３０の購入時期は、機器２０のユーザが新しい交換品３０を購入すると予測される時期である。機器２０のユーザが上記の報知時期に新しい交換品３０を購入すると仮定する。したがって、購入時期と報知時期は同じ時期になる。例えば、交換時期が本日より１２日後であり、報知時期が交換時期より７日前であるとすると、本日より５日後が報知時期になる。その日（報知時期）に機器２０のユーザが交換品３０を購入すると仮定すると、購入時期は本日より５日後となる。

次に第３テーブル５０３について説明する。図５に示すように、第３テーブル５０３には、交換品３０の数に関する情報が記憶されている。第３テーブル５０３には、交換品３０の購入数の合計、合計購入数の累計、交換品３０の在庫数、在庫の不足数が記憶されている。第３テーブル５０３は、機器２０で交換品３０が使用される毎に更新される。

交換品３０の購入数の合計は、図４に示す第２テーブル５０２における購入時期に基づいて算出される、各機器２０のユーザによって購入されると予測される交換品３０の合計数である。例えば、機器２０Ｃのユーザが本日より１日後に新しい交換品３０Ｃを購入すると予測する。また、その日（本日より１日後）には、その他の機器２０のユーザが新しい交換品３０を購入しないと予測する。したがってこの場合は、本日より１日後における交換品３０の合計購入数が１個となる。また、合計購入数の累計は、上記の交換品３０の購入数の合計の累計である。例えば、本日より５日後における合計購入数の累計は３個である。

交換品３０の在庫数は、管理システム１の管理者の倉庫３００にストックされていると予測される交換品３０の在庫の数である。例えば、本日の交換品３０の在庫数は２個である。交換品３０の在庫数は、機器２０のユーザによって新しい交換品３０が購入されると減少する。例えば、本日より１日後に合計で１個の交換品３０が購入される。そうすると、交換品３０の在庫数が１個減少する。したがって、本日より１日後の交換品３０の在庫数が１個になる。また、交換品３０の在庫数は、倉庫３００に交換品３０が納入される、もしくは納入が予定されると増加する。なお、図５に示す例では、倉庫３００に交換品３０の在庫が納入されておらず、納入も予定されていない。そのため、交換品３０の在庫数が増加していない。交換品３０の在庫数のデータは、管理者の倉庫３００に設置されている第１ホストコンピュータ３０１からサーバ１００に送信される。

また、交換品３０の在庫の不足数は、交換品３０の在庫が不足している数である。在庫の不足数は、上記の交換品３０の合計購入数の累計と交換品３０の在庫数に基づいて算出される。例えば、本日の交換品３０の在庫数が２個であり、在庫数の増加がなく、本日より５日後の交換品３０の合計購入数の累計数が３個であるとする。そうすると、本日より５日後に交換品３０が１個不足する。したがって、本日より５日後の交換品３０の不足数は１個である。

図５に示す例では、管理システム１の機器２０と交換品３０の数が少ないので、第３テーブル５０３に示されている交換品３０に関する数が少ないが、機器２０と交換品３０の数が多い場合には、第３テーブル５０３に示されている交換品３０に関する数が多くなる。例えば、図６に示すように、機器２０と交換品３０の数が多い場合には、交換品３０の購入数の合計、合計購入数の累計、交換品３０の在庫数、在庫の不足数が図５に示す場合よりも多くなる。なお、図６に示す例では、管理システム１の管理者の倉庫３００に交換品３０の在庫の納入が予定され、それによって交換品３０の在庫数が増加している。

次に、上記の管理システム１で実行される処理について説明する。管理システム１では主に、登録処理、初期設定処理、運転処理、演算処理、不足数演算処理、サーバ側報知処理、機器側報知処理、発送処理が実行される。これらの処理について以下に説明する。

（登録処理）
上記の管理システム１では、まず登録処理が実行される。登録処理は、機器２０で使用される交換品３０に関する情報を登録する処理である。登録処理は、機器２０のユーザが、機器２０で使用していた古い交換品３０を新しい交換品３０に交換したときに実行される処理である。ここでは、複数の機器２０のうち機器２０Ａにおける登録処理について説明する。その他の機器２０Ｂ、２０Ｃ、２０Ｄにおいても同様の登録処理が実行される。

登録処理では、図７に示すように、ステップＳ１１で、機器２０Ａの制御部２１が、機器２０Ａで使用されている交換品３０Ａが交換されたか否かを監視する。交換品３０Ａが交換された場合は、ステップＳ１１で制御部２１がＹＥＳと判断してステップＳ１２に進む。交換品３０Ａが交換されたか否かの判断は、例えば交換品３０Ａを検出するセンサーの検出結果に基づいて行うことができる。センサーが新しい交換品３０Ａを検出した場合は、交換品３０Ａが交換されたと判断することができる。もしくは、交換品３０Ａが交換された場合、ユーザが交換したことを報知するスイッチを操作してもよい。一方、交換品３０Ａが交換されない場合は、ステップＳ１１で制御部２１がＮＯと判断して待機する。

続くステップＳ１２では、機器２０Ａの制御部２１が、新しい交換品３０Ａに関する交換品情報をサーバ１００に送信する。交換品情報は、新しい交換品３０Ａの種類を特定できる情報である。交換品情報は、例えば新しい交換品３０Ａの製品番号である。ステップＳ１２が終了した後、制御部２１は、ステップＳ１１に戻り監視を続ける。

（初期設定処理）
管理システム１では、登録処理に続いて初期設定処理が実行される。初期設定処理は、サーバ１００において交換品３０に関する情報を初期設定する処理である。ここでは、複数の機器２０のうち、機器２０Ａにおける初期設定処理について説明する。その他の機器２０B、２０C、２０Dについても同様の初期設定処理が行われる。初期設定処理では、図８に示すように、ステップＳ２１で、サーバ１００が、機器２０Ａの制御部２１が上記のステップＳ１２で送信した交換品情報を受信する。サーバ１００は、新しい交換品３０Ａに関する交換品情報（例えば製品番号）を受信する。

続くステップＳ２２では、サーバ１００が、受信した交換品情報（例えば製品番号）に基づいて、新しい交換品３０Ａの満容量情報を取得する。満容量情報は、新しい交換品３０Ａの満容量を特定するための情報である。サーバ１００は、図３に示す第１テーブル５０１から満容量情報を取得する。サーバ１００は、第１テーブル５０１に記憶されている交換品３０Ａの製品番号に対応する満容量を取得する。新しい交換品３０Ａの満容量は、例えば５００ｇである。

続くステップＳ２３では、サーバ１００が、交換品３０Ａの満容量を交換品３０Ａの現在量として設定する。交換品３０Ａの初期の現在量が満容量に設定される。その後、サーバ１００が処理を終了する。

（運転処理）
管理システム１では、各機器２０のユーザが各機器２０を使用することによって各機器２０の運転が実行される。運転処理は、各機器２０の運転が実行されたときの処理である。ここでは、複数の機器２０のうち機器２０Ａにおける運転処理について説明する。その他の機器２０Ａ、２０Ｂ、２０Ｃにおいても同様の運転処理が実行される。

運転処理では、図９に示すように、ステップＳ３１で、機器２０Ａの制御部２１が、機器２０Ａの運転が開始されたか否かを監視する。機器２０Ａの運転が開始された場合は、ステップＳ３１で制御部２１がＹＥＳと判断してステップＳ３２に進む。一方、機器２０Ａの運転が開始されない場合は、ステップＳ３１で制御部２１がＮＯと判断して待機する。機器２０Ａの運転が開始されたか否かの判断は、機器２０Ａの動作信号に基づいて行うことができる。機器２０Ａの動作信号が検出された場合は、機器２０Ａの運転が開始されたと判断することができる。

続くステップＳ３２では、機器２０Ａの制御部２１が、機器２０Ａの運転が終了したか否かを監視する。機器２０Ａの運転が終了した場合は、ステップＳ３２で制御部２１がＹＥＳと判断してステップＳ３３に進む。一方、機器２０Ａの運転が終了していない場合は、ステップＳ３２で制御部２１がＮＯと判断して待機する。機器２０Ａの運転が終了したか否かの判断は、機器２０Ａの動作信号に基づいて行うことができる。機器２０Ａの動作信号が検出されなくなった場合は、機器２０Ａの運転が終了したと判断することができる。

続くステップＳ３３では、機器２０Ａの制御部２１が、機器２０Ａの運転に関する運転情報をサーバ１００に送信する。運転情報は、機器２０Ａの運転が実行されたことを特定できる情報である。よって、この運転情報は、機器２０Ａで交換品３０が使用されたことを特定できる情報である。運転情報は、例えば機器２０Ａの運転が実行されたときの運転モードの情報である。運転モードは、例えば通常モードや念入りモード等である。ステップＳ３３が終了した後、機器２０Ａの制御部２１は、ステップＳ３１に戻り監視を続ける。

（演算処理）
管理システム１では、機器２０で運転処理が実行されるとサーバ１００で演算処理が実行される。演算処理は、交換品３０に関する各種の演算を実行する処理である。

演算処理では、図１０に示すように、ステップＳ４１で、サーバ１００が、機器２０の制御部２１が上記のステップＳ３３で送信した運転情報を受信する。サーバ１００は、各機器２０Ａ、２０Ｂ、２０Ｃ、２０Ｄから運転情報を受信する。サーバ１００は、各機器２０Ａ、２０Ｂ、２０Ｃ、２０Ｄの運転が実行される毎に、各機器２０Ａ、２０Ｂ、２０Ｃ、２０Ｄの運転情報を受信する。

続くステップＳ４２では、サーバ１００が、機器２０から受信した運転情報に基づいて、交換品３０の現在量を演算する。サーバ１００は、受信した運転情報に係る各機器２０Ａ、２０Ｂ、２０Ｃ、２０Ｄで使用されている各交換品３０Ａ、３０Ｂ、３０Ｃ、３０Ｄの現在量を演算する。例えばサーバ１００は、機器２０Ａから運転情報を受信した場合は、その機器２０Ａで使用されている交換品３０Ａの現在量を演算する。このときサーバ１００は、図４に示す第２テーブル５０２に記憶されている交換品３０の所定の消耗量（例えば５ｇ／回）に基づいて交換品３０の現在量を演算する。サーバ１００は、機器２０の運転前の交換品３０の現在量から、運転情報を受信する毎に交換品３０の所定の消耗量を差し引くことによって、機器２０の運転後の交換品３０の現在量を演算する。すなわち、交換品３０の使用前の現在量から所定の消耗量を差し引くことによって、交換品３０の使用後の現在量を演算する。例えば、機器２０Ａの運転前（交換品３０Ａの使用前）の交換品３０Ａの現在量が１８５ｇであり、交換品３０Ａの所定の消耗量が５ｇ／回である場合、機器２０Ａの運転後（交換品３０Ａの使用後）の交換品３０Ａの現在量は、１８５ｇ−５ｇ＝１８０ｇとなる。

図１０に示すように、続くステップＳ４３では、サーバ１００が、交換品３０の交換時期を演算する。サーバ１００は、上記のステップＳ４１で受信した運転情報に係る各機器２０Ａ、２０Ｂ、２０Ｃ、２０Ｄで使用されている各交換品３０Ａ、３０Ｂ、３０Ｃ、３０Ｄの交換時期を演算する。例えばサーバ１００は、機器２０Ａから上記の運転情報を受信した場合は、その機器２０Ａで使用されている交換品３０Ａの交換時期を演算する。このときサーバ１００は、図４に示す第２テーブル５０２に記憶されている交換品３０の所定の消耗率（例えば１５ｇ／日）に基づいて交換品３０の交換時期を演算する。また、サーバ１００は、上記のステップＳ４２で演算した交換品３０の現在量に基づいて交換時期を演算する。具体的には、図１１に示すように、サーバ１００は、交換品３０（洗剤）が所定の消耗率で消耗すると仮定して、交換品３０（洗剤）の量が０（ゼロ）になる時期を演算し、その時期を交換時期とする。すなわち、サーバ１００は、交換品３０が交換を要する交換状態になる時期を交換時期とする。例えば、機器２０Ａで使用されている交換品３０Ａの現在量が１８０ｇであり、その交換品３０Ａの所定の消耗率が１５ｇ／日である場合、現在（本日）より１２日後に交換品３０の量が０（ゼロ）になる。よって、サーバ１００は、現在（本日）より１２日後の時期を交換時期とする。なお、消耗率は、各機器２０における交換品３０の過去の使用実績（１日の使用回数）に基づいて新しい消耗率にアップデートされる。

図１０に示すように、続くステップＳ４４では、サーバ１００が、上記のステップＳ４３で演算した交換時期に基づいて報知時期を特定する。図１１に示すように、報知時期は、交換時期より前の所定の時期である。例えば、報知時期は、交換時期より７日前の日である。報知時期は、機器２０のユーザに交換情報を報知する時期である。機器２０のユーザに交換情報を報知することによって、ユーザが機器２０で使用している古い交換品３０を近日中に新しい交換品３０に交換すると予測される。したがって、機器２０のユーザが報知時期に新しい交換品３０を購入すると予測される。そのため、報知時期は、機器２０のユーザが新しい交換品３０を購入する購入時期と同じ時期になる。すなわち、ステップＳ４４では、サーバ１００が、購入時期（＝報知時期）を特定する。なお、報知時期は、ユーザが任意に設定してもよい。

図１０に示すように、続くステップＳ４５では、サーバ１００が、交換品３０の在庫の不足数を演算する（不足数演算処理）。図１２を用いて不足数演算処理について説明する。不足数演算処理では、図１２に示すように、ステップＳ５１で、サーバ１００が、各時期（各日）における交換品３０の購入数の合計を演算する。上述したように、機器２０のユーザが、購入時期（＝報知時期）に新しい交換品３０を購入することが予測される。各機器２０Ａ、２０Ｂ、２０Ｃ、２０Ｄのユーザが、各購入時期（＝各報知時期）に新しい交換品３０Ａ、３０Ｂ、３０Ｃ、３０Ｄを購入することが予測される。それらの購入を全て集計すると、各時期（各日）における交換品３０の購入数の合計を演算することができる。例えば、図４に示すように、機器２０Ａのユーザが、本日より５日後に新しい交換品３０Ａを購入することが予測される。その他の機器２０Ｂ、２０Ｃ、２０Ｄのユーザは、本日より５日後に新しい交換品３０を購入しないことが予測される。そうすると、図５に示すように、本日より５日後における交換品３０の購入数の合計は１個となる。

図１２に示すように、続くステップＳ５２では、サーバ１００が、各時期（各日）における交換品３０の合計購入数の累計を演算する。現在（本日）から各時期（各日）までの交換品３０の購入数の合計を全て集計すると、各時期（各日）における交換品３０の合計購入数の累計を演算することができる。例えば、図５に示すように、本日から５日後までの交換品３０の購入数の合計（１日後：１個、２日後：１個、５日後：１個）を全て集計すると、本日より５日後における交換品３０の合計購入数の累計が３個となる。

図１２に示すように、続くステップＳ５３では、サーバ１００が、各時期（各日）における交換品３０の在庫の不足数を演算する。サーバ１００は、現在（本日）の交換品３０の在庫数から、上記のステップＳ５２で演算した各時期（各日）における交換品３０の合計購入数の累計を差し引くことによって、各時期（各日）における交換品３０の在庫の不足数を演算する。例えば、図５に示すように、本日の交換品３０の在庫数が２個であり、本日より５日後における交換品３０の合計購入数の累計が３個であるとすると、本日より５日後における交換品３０の在庫の不足数が１個となる。交換品３０の在庫数は、管理システム１の管理者の倉庫３００に設置されている第１ホストコンピュータ３０１からサーバ１００に送信されている。なお、図５に示す例では、交換品３０の在庫は追加されないものとする。サーバ１００は、在庫の不足数を演算した後、不足数演算処理を終了する。

サーバ１００は、不足数演算処理が終了した後、図１０に示す演算処理のステップＳ４６に進む。ステップＳ４６では、サーバ１００が、所定の時期における交換品３０の在庫の不足数が０（ゼロ）より多いか否かを判断する。すなわち、サーバ１００が、所定の時期における交換品３０の在庫が不足しているか否かを判断する。所定の時期は、例えば交換品３０が仕入先から管理システム１の管理者の倉庫３００に納入されるまでに要する日数であり、本日より５日後である。所定の時期における交換品３０の在庫の不足数が０（ゼロ）より多い場合は、ステップＳ４６でサーバ１００がＹＥＳと判断してステップＳ４７に進む。例えば、図５に示すように、本日より５日後における交換品３０の在庫の不足数が１個であるので、ステップＳ４６でサーバ１００が交換品３０の在庫が不足していると判断してステップＳ４７に進む。一方、所定の時期における交換品３０の在庫の不足数が０（ゼロ）以下である場合は、ステップＳ４６でサーバ１００がＮＯと判断して、ステップＳ４７、Ｓ４８をスキップして演算処理を終了する。

図１０に示すように、続くステップＳ４７では、サーバ１００が、交換品３０の在庫の補充情報を生成する。補充情報は、交換品３０の在庫の不足数に応じて交換品３０の在庫を補充するための情報である。例えば、図５に示すように、本日より５日後における交換品３０の在庫の不足数が１個であるので、サーバ１００は、１個の在庫を補充することを指示する補充情報を生成する。

図１０に示すように、続くステップＳ４８では、サーバ１００が、交換品３０の在庫の補充情報を第２ホストコンピュータ４０１（図１参照）に送信する。第２ホストコンピュータ４０１は、仕入先の倉庫４００に設置されている。第２ホストコンピュータ４０１がサーバ１００から補充情報を受信すると、仕入先の倉庫４００から管理システム１の管理者の倉庫３００へ交換品３０が発送される。補充情報に基づいて交換品３０が発送される。例えば、１個の交換品３０が本日より５日後までに管理者の倉庫３００に納入されるように、交換品３０が発送される。また、交換品３０の発送を指示したことにより、管理者の倉庫３００に交換品３０が納入される予定日（例えば５日後）の在庫数に「１」が加算される。

（サーバ側報知処理）
次に、サーバ側報知処理について説明する。サーバ側報知処理では、図１３に示すように、ステップＳ６１で、サーバ１００が、報知時期が到来したか否かを監視する。報知時期は、図１０に示す演算処理のステップＳ４４でサーバ１００が特定した時期である。例えば、図４に示すように、機器２０Ａで使用されている交換品３０Ａについての報知時期は、交換品３０Ａの交換時期より７日前（本日より５日後）である。サーバ１００は、この日が到来したか否かを監視する。報知時期が到来した場合は、ステップＳ６１でサーバ１００がＹＥＳと判断してステップＳ６２に進む。一方、報知時期が到来していない場合は、ステップＳ６１でサーバ１００がＮＯと判断して待機する。

図１３に示すように、続くステップＳ６２では、サーバ１００が、交換情報を機器２０へ送信する。交換情報は、機器２０で使用している古い交換品３０を新しい交換品３０に交換することを報知する情報である。サーバ１００は、報知時期が到来している機器２０に対して交換情報を送信する。例えば、機器２０Ａについて報知時期が到来している場合は、その機器２０Ａに交換情報を送信する。ステップＳ６２が終了した後、サーバ１００は、ステップＳ６１に戻り監視を続ける。

（機器側報知処理）
次に、機器側報知処理について説明する。ここでは、複数の機器２０のうち機器２０Ａにおける機器側報知処理について説明する。その他の機器２０Ｂ、２０Ｃ、２０Ｄにおいても同様の機器側報知処理が実行される。機器側報知処理では、図１４に示すように、ステップＳ７１で、機器２０Ａの制御部２１が、サーバ１００から交換情報を受信したか否かを監視する。交換情報を受信した場合は、ステップＳ７１で制御部２１がＹＥＳと判断してステップＳ７２に進む。一方、交換情報を受信していない場合は、ステップＳ７１で制御部２１がＮＯと判断して待機する。

続くステップＳ７２では、制御部２１が、交換情報を機器２０Ａの表示部２２に表示する。例えば、「機器２０Ａで使用している交換品３０Ａが無くなります。新しい交換品３０Ａを準備してください。」といった交換情報を表示部２２に表示する。これによって、交換情報が機器２０Ａのユーザに報知される。交換情報が機器２０Ａのユーザに報知されることによって、機器２０Ａのユーザが交換品３０Ａを交換するために新しい交換品３０Ａを購入すると予測される。ステップＳ７２が終了した後、サーバ１００は、ステップＳ７１に戻り監視を続ける。

以上、第１実施例に係る管理システム１について説明した。上記の管理システム１では、各機器２０が、各交換品３０が各機器２０で使用されたことを特定できる運転情報をサーバ１００に送信する（図９のステップＳ３３）。サーバ１００は、各機器２０から運転情報を受信すると（図１０のステップＳ４１）、各機器２０で使用されている各交換品３０の所定の消耗率に基づいて（図４参照）、各機器２０で使用されている各交換品３０が交換状態になる交換時期をそれぞれ演算する（図１０のステップＳ４３、図１１参照）。また、サーバ１００は、演算した各交換品３０の各交換時期より前の所定の各時期に（図４、図１１参照）、各機器２０で使用されている各交換品３０が各交換時期に近付いたことをユーザに報知する交換情報を各機器２０に送信する（図１３のステップＳ６２）。これによって、各機器２０のユーザが新しい各交換品３０を購入することが予測される。また、サーバ１００は、交換情報の送信に基づいて、各交換時期より前の所定の各時期に各機器２０のユーザによって購入される新しい各交換品３０の購入数の合計を予測する（図１２のステップＳ５１、図５参照）。また、サーバ１００は、予測した新しい各交換品３０の購入数の合計と、所定の各時期の交換品３０の在庫数とに基づいて、所定の各時期の交換品３０の在庫の不足数を演算する（図１２のステップＳ５３、図５参照）。また、サーバ１００は、演算した交換品３０の在庫の不足数に応じて交換品３０の在庫を補充するための補充情報を生成する（図１０のステップＳ４７）。

この構成によれば、サーバ１００が各交換品３０の消耗率に基づいて各交換品３０の交換時期を演算するので各交換時期を精度良く演算することができる。また、各交換品３０の交換時期より前の所定の各報知時期に、サーバ１００が各機器２０に交換情報を送信するので、各機器２０のユーザが新しい各交換品３０を各交換時期より前の所定の各購入時期（＝報知時期）に購入することができる。そして、サーバ１００が、交換情報の送信に基づいて、所定の各購入時期（＝報知時期）に各機器２０のユーザによって購入される新しい各交換品３０の購入数の合計を予測する。すなわち、上記の管理システム１では、各機器２０のユーザが新しい各交換品３０を所定の各購入時期（＝報知時期）に購入することを前提として、サーバ１００が、新しい各交換品３０の購入数の合計を予測する。また、上記の管理システム１では、サーバ１００が、予測した新しい交換品３０の購入数の合計と、各交換時期より前の所定の各購入時期（＝報知時期）の交換品の在庫数とに基づいて、所定の各購入時期（＝報知時期）の交換品３０の在庫の不足数を演算するので、ユーザによる新しい交換品３０の購入を想定に入れておくことができ、交換品３０の在庫の不足数を精度良く演算することができる。また、サーバ１００が、演算した在庫の不足数に応じて交換品３０の在庫を補充するための補充情報を生成するので、交換品３０の在庫数を適切に管理することができる。管理システム１の管理者の倉庫３００に交換品３０の在庫を適切に補充することができる。

以上、実施例について詳細に説明したが、これらは例示に過ぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。以下の説明において、上述の説明における構成と同様の構成については、同一の符号を付して説明を省略する。

上記の実施例では、交換品３０（洗剤）が一種類だけであったが、複数種類の洗剤の在庫数を管理してもよい。複数の交換品３０（洗剤）の満容量が異なっていてもよい。

また、上記の実施例では、登録処理（図７参照）において、機器２０の制御部２１が交換品情報をサーバ１００に送信していたが、この構成に限定されるものではない。他の実施例では、機器２０のユーザが例えばスマートフォン等の携帯端末に交換品情報を入力し、入力された交換品情報を携帯端末がサーバ１００に送信する構成であってもよい。また、例えば交換品３０に付されているバーコードを利用して交換品情報を特定してもよい。

また、上記の実施例では、サーバ側報知処理（図１３参照）において、サーバ１００が、交換情報を機器２０へ送信していたが、この構成に限定されるものではない。他の実施例では、サーバ側報知処理（図１３参照）において、サーバ１００が、機器２０に代えて、スマートフォンやパソコン等の端末（図示省略）へ交換情報を送信してもよい。サーバ１００には、各機器２０に対応付けられた各端末の情報が記憶されている。サーバ１００は、各機器２０に対応する各端末へ交換情報を送信する。そして、機器側報知処理（図１４参照）において、機器２０の代わりに、前記端末が交換情報を受信し、端末の表示部に交換情報を表示させてもよい。より具体的には、メールやアプリ等による受信および表示が考えられる。また、更に他の実施例では、サーバ１００が、各機器２０および各端末へ交換情報を送信してもよい。

（第２実施例）
上記の実施例では、図１３および図１４に示すように、報知処理（サーバ側報知処理および機器側報知処理）が実行される構成であったが、この構成に限定されるものではない。すなわち、報知処理では、サーバ１００が、報知時期が到来すると（ステップＳ６１でＹＥＳ）、交換情報を機器２０に送信する（ステップＳ６２）構成であったが、この構成に限定されるものではない。他の実施例では、発送処理が実行される構成であってもよい。発送処理では、図１５に示すように、サーバ１００が、報知時期が到来すると（ステップＳ６１でＹＥＳ）、続くステップＳ８２では、発送情報を生成する。発送情報は、各機器２０のユーザに交換用の新しい各交換品３０を発送するための情報である。サーバ１００は、報知時期が到来している機器２０のユーザに交換用の新しい交換品３０を発送するための発送情報を生成する。例えば、機器２０Ａについて報知時期が到来している場合は、その機器２０Ａのユーザに交換用の新しい交換品３０Ａを発送するための発送情報を生成する。

続くステップＳ８３では、サーバ１００が、発送情報を第１ホストコンピュータ３０１（図１参照）に送信する。第１ホストコンピュータ３０１は、管理システム１の管理者の倉庫３００に設置されている。第１ホストコンピュータ３０１がサーバ１００から発送情報を受信すると、管理者の倉庫３００から機器２０のユーザへ新しい交換品３０が発送される。補充情報に基づいて新しい交換品３０が発送される。例えば、報知時期（＝購入時期）が到来している機器２０Ａのユーザに新しい交換品３０Ａが発送される。これによって、機器２０Ａのユーザが新しい交換品３０Ａを自動的に購入することができる。ステップＳ８３が終了した後、サーバ１００は、ステップＳ６１に戻り監視を続ける。

この構成では、サーバ１００が、発送情報の生成に基づいて、各報知時期（＝購入時期）に各機器２０のユーザによって購入される新しい各交換品３０の購入数の合計を予測する。すなわち、各機器２０のユーザが新しい各交換品３０を各報知時期（＝購入時期）に購入することを前提として、サーバ１００が、新しい各交換品３０の購入数の合計を予測する。また、サーバ１００が、予測した新しい交換品３０の購入数の合計と、各報知時期（＝購入時期）の交換品の在庫数とに基づいて、各報知時期（＝購入時期）の交換品の在庫の不足数を演算するので、ユーザによる新しい交換品３０の購入を想定に入れておくことができ、交換品３０の在庫の不足数を精度良く演算することができる。また、サーバ１００が、演算した在庫の不足数に応じて交換品３０の在庫を補充するための補充情報を生成するので、交換品３０の在庫数を適切に管理することができる。

また、第２実施例では、図１３および図１４に示す報知処理（サーバ側報知処理および機器側報知処理）と、図１５に示す発送処理の両方が実行されてもよい。

（第３実施例）
また、上記の実施例では、機器２０が食器洗浄機であったが、この構成に限定されるものではない。他の実施例では、機器２０がガスコンロであってもよい。また、上記の実施例では、交換品３０が洗剤であったが、この構成に限定されるものではない。他の実施例では、交換品３０が五徳であってもよい。または、交換品３０がバーナーヘッドであってもよい。

第３実施例における第１テーブル５０１について説明する。図１６に示すように、第１テーブル５０１には、交換品３０の製品番号と使用限度回数が記憶されている。製品番号は、複数の交換品３０のうちから１個の交換品３０を特定できる情報である。使用限度回数は、交換品３０（五徳またはバーナーヘッド）が新品の状態における使用限度の回数である。使用限度回数まで交換品３０（五徳またはバーナーヘッド）を使用することができる。第１テーブル５０１では、交換品３０の製品番号と使用限度回数が対応している。

次に、第３実施例における第２テーブル５０２について説明する。図１７に示すように、第２テーブル５０２には、機器２０で使用されている交換品３０に関する情報が記憶されている。第２テーブル５０２には、交換品３０に関する使用限度回数、現在回数、消耗率が記憶されている。また、第２テーブル５０２には、交換品３０に関する交換時期、報知時期、購入時期が記憶されている。

第２テーブル５０２に記憶されている交換品３０の使用限度回数は、古い交換品３０から新しい交換品３０に交換されたときの初期の五徳またはバーナーヘッドを使用できる限度の回数である。使用限度回数は、例えば１００００回である。

また、交換品３０の現在回数は、五徳またはバーナーヘッドが新品の初期状態から現在までの間に使用された回数である。古い交換品３０から新しい交換品３０に交換された初期では、上記の使用限度回数が現在回数となる。交換品３０の現在回数は、機器２０で五徳またはバーナーヘッドが使用される毎に増加してゆく。

交換品３０の消耗率（回／日）は、五徳またはバーナーヘッドが１日あたりに使用される回数である。五徳またはバーナーヘッドは、使用されて消耗する。本実施例において交換品３０（五徳またはバーナーヘッド）が消耗するとは、五徳またはバーナーヘッドが使用されて、その使用回数（現在回数）が使用限度回数に近付いてゆくことである。各交換品３０の消耗率は、各機器２０における交換品３０の過去の使用実績に基づいて算出される。例えば、機器２０Ａで使用される交換品３０Ａの消耗率は１０回／日である。

また、交換品３０の交換時期は、機器２０で交換品３０が使用されて消耗することによって交換状態になる時期である。交換時期は、古い交換品３０から新しい交換品３０に交換されると予測される時期である。交換時期は、交換品３０の現在量と消耗率に基づいて演算される。例えば、機器２０Ａで使用されている五徳またはバーナーヘッドの現在回数が８０００回であり、その消耗率が１０回／日であるとすると、本日より２００日後に使用回数（現在回数）が使用限度回数に到達する。よって、この場合の交換時期は本日より２００日後である。

第３実施例の第２テーブル５０２における報知時期と購入時期については、第１実施例の第２テーブル５０２における報知時期と購入時期と同様であるので、詳細な説明を省略する。この第３実施例でも上記の第１実施例と同様の処理が実行される。第１実施例における交換品３０の満容量を、第３実施例における交換品３０の使用限度回数に置き換えることができ、第１実施例における交換品３０の現在量を、第３実施例における交換品３０の現在回数に置き換えることができる。

なお、第３実施例では、使用限度回数と現在回数を回数ではなく時間で管理してもよい。また、回数と時間の双方で管理してもよい。また、回数と時間のうち、限度に到達する時期が早い方で管理してもよい。

（第４実施例）
交換品３０の具体例は、上記の実施例に限定されるものではない。他の実施例では、交換品３０が電池であってもよい。

第４実施例における第２テーブル５０２について説明する。図１８に示すように、第２テーブル５０２には、機器２０で使用されている交換品３０に関する情報が記憶されている。第２テーブル５０２には、交換品３０に関する初期電圧、現在電圧、消耗率、最低限度電圧が記憶されている。また、第２テーブル５０２には、交換品３０に関する交換時期、報知時期、購入時期が記憶されている。

第２テーブル５０２記憶されている交換品３０の初期電圧は、古い交換品３０から新しい交換品３０に交換されたときの初期の電池の電圧である。初期電圧は、例えば３．０Ｖである。

また、交換品３０の現在電圧は、電池の現在の電圧である。古い交換品３０から新しい交換品３０に交換された初期では、上記の初期電圧が現在電圧となる。交換品３０の現在電圧は、機器２０で電池が使用される毎に低下してゆく。

交換品３０の消耗率（Ｖ／日）は、機器２０で電池が使用される毎に低下する電池の電圧である。電池が使用されると電池が消耗して、電池の電圧が低下する。本実施例において交換品３０（電池）が消耗するとは、電池が使用されてその電圧が低下してゆくことである。各交換品３０の消耗率は、各機器２０における交換品３０の過去の使用実績に基づいて算出される。例えば、機器２０Ａで使用される交換品３０Ａの消耗率は０．０１Ｖ／日である。

交換品３０の最低限度電圧は、交換品３０の交換を要する電圧である。電池の電圧が最低限度電圧になると交換を要する。すなわち、最低限度電圧は、交換品３０が交換状態になるときの電圧である。最低限度電圧は、例えば２．５Ｖである。

また、交換品３０の交換時期は、機器２０で交換品３０が使用されて消耗することによって交換状態になる時期である。交換時期は、古い交換品３０から新しい交換品３０に交換されると予測される時期である。交換時期は、交換品３０の現在量と消耗率に基づいて演算される。例えば、機器２０Ａで使用されている電池の現在電圧が２．７Ｖであり、その消耗率が０．０１Ｖ／日であるとすると、本日より２０日後に現在電圧が最低限度電圧に到達する。よって、この場合の交換時期は本日より２０日後である。

第４実施例の第２テーブル５０２における報知時期と購入時期については、第１実施例の第２テーブル５０２における報知時期と購入時期と同様であるので、詳細な説明を省略する。この第４実施例でも上記の第１実施例と同様の処理が実行される。第１実施例における交換品３０の現在量を、第４実施例における交換品３０の現在電圧に置き換えることができる。

第４実施例では、図９に示す運転処理のステップＳ３３において、機器２０の制御部２１が、運転情報として交換品３０（電池）の現在電圧を送信してもよい。そうすると、図１０に示す演算処理のステップＳ４２を省略することができる。すなわち、サーバ１００が交換品３０（電池）の現在電圧を演算するステップＳ４２を省略することができる。

なお、第４実施例における報知時期の代わりに、予め報知時期に相当する電圧を設定し、その電圧に到達する日を消耗率に基づいて算出し、その日を購入時期としてもよい。例えば、報知時期に相当する電圧を２．６Ｖとし、消耗率を０．０１Ｖ／日としたときに、現在電圧が２．７Ｖであるとすると、２．６Ｖに到達するのは、本日より１０日後となり、購入時期は１０日後となる。

（第５実施例）
第５実施例に係る管理システム１では、サーバ１００に第４テーブル５０４が記憶されている。図１９に示すように、第４テーブル５０４には、日時情報が記憶されている。具体的には、第４テーブル５０４には、曜日（月〜金）と時間帯（０時−１時〜２３時−２４時）を特定できる情報が記憶されている。この第４テーブル５０４は、後述する日時情報をサーバ１００が受信すると更新される。第４テーブル５０４は、各機器２０Ａ、２０Ｂ、２０Ｃ、２０Ｄ毎に準備されている。図１９には、機器２０Ａに関する第４テーブル５０４が示されている。

第５実施例に係る管理システム１では、日時情報送信処理、日時情報記憶処理、発送処理が実行される。これらの処理について以下に説明する。

（日時情報送信処理）
日時情報送信処理は、機器２０のユーザによって機器２０が操作されたときに実行される処理である。ここでは、複数の機器２０のうち機器２０Ａにおける日時情報送信処理について説明する。その他の機器２０Ｂ、２０Ｃ、２０Ｄにおいても同様の日時情報送信処理が実行される。日時情報送信処理では、図２０に示すように、ステップＳ９１で、機器２０Ａの制御部２１が、機器２０Ａが操作されたか否かを監視する。機器２０Ａが操作された場合は、ステップＳ９１で制御部２１がＹＥＳと判断してステップＳ９２に進む。機器２０Ａが操作されたか否かの判断は、例えば機器２０Ａの操作スイッチが押されたことを検出することによって行うことができる。機器２０Ａの操作スイッチは、例えば機器２０Ａが食器洗浄機である場合は、食器の洗浄を開始するためのスイッチ等である。機器２０Ａの操作スイッチが押された場合は、機器２０Ａが操作されたと判断することができる。一方、機器２０Ａが操作されていない場合は、ステップＳ９１で制御部２１がＮＯと判断して待機する。

続くステップＳ９２では、機器２０Ａの制御部２１が、日時情報をサーバ１００に送信する。日時情報は、ユーザによって機器２０Ａが操作された日時を特定できる情報である。例えば、日曜日の１７時〜１８時の時間帯に機器２０Ａが操作された場合は、日時情報は、日曜日の１７時〜１８時の時間帯を特定する情報である。ステップＳ９２が終了した後、制御部２１は、ステップＳ９１に戻り監視を続ける。

（日時情報記憶処理）
次に、日時情報記憶処理について説明する。日時情報記憶処理では、図２１に示すように、ステップＳ１０１で、サーバ１００が、機器２０Ａの制御部２１から日時情報を受信したか否かを監視する。日時情報を受信した場合は、ステップＳ１０１でサーバ１００がＹＥＳと判断してステップＳ１０２に進む。一方、日時情報を受信していない場合は、ステップＳ１０１でサーバ１００がＮＯと判断して待機する。

続くステップＳ１０２では、サーバ１００が、受信した日時情報を図１９に示す第４テーブル５０４に記憶する。具体的には、サーバ１００が、受信した日時情報で特定される曜日と時間帯に「＋１」を加点する。例えば、サーバ１００が、第４テーブル５０４における日曜日の１７時〜１８時の時間帯に「＋１」を加点する。加点される毎にその日時における点数が増加してゆく。このようにして、日時情報が第４テーブル５０４に記憶される。なお、同日中の同一の時間帯に複数の日時情報が送信されたとしても、加点は初回のみ行い、それ以降の日時情報については加点を行わない。

図２１に示すように、続くステップＳ１０３では、サーバ１００が、所定の時期より前の日時情報を第４テーブル５０４から削除する。例えば、サーバ１００が、本日より６０日前の日以前の日時情報を削除する。これによって、本日より例えば６０日前までの日時情報が第４テーブル５０４に残される。ステップＳ１０３が終了した後、サーバ１００は、ステップＳ１０１に戻り監視を続ける。サーバ１００は、その他の機器２０Ｂ、２０Ｃ、２０Ｄについても同様の日時情報記憶処理を実行する。

（発送処理）
次に、発送処理について説明する。上記の第２実施例では、発送処理（図１５参照）において日時が考慮されていなかったが、この構成に限定されるものではない。第５実施例では、発送処理において日時が考慮される。第５実施例に係る発送処理では、図２２に示すように、報知時期が到来すると（ステップＳ６１でＹＥＳ）、ステップＳ１１１に進む。

ステップＳ１１１では、サーバ１００が、機器２０Ａのユーザの在宅日時を予測する。サーバ１００は、図１９に示す第４テーブル５０４に基づいて、機器２０Ａのユーザの在宅日時を予測する。具体的には、サーバ１００は、第４テーブル５０４において所定の点数（例えば４点）以上の点数を有する日時に機器２０Ａのユーザが在宅していると予測する。第４テーブル５０４における点数が高い日時には、機器２０Ａのユーザが在宅している可能性が高い。したがって、サーバ１００は、第４テーブル５０４における点数が高い日時には機器２０Ａのユーザが在宅していると予測する。例えば、サーバ１００は、水曜日の１８時−１９時、土曜日の１７時−１８時、日曜日の１７時−１８時には機器２０Ａのユーザが在宅していると予測する。

図２２に示すように、続くステップＳ８２では、サーバ１００が、発送情報を生成する。この場合に、サーバ１００は、上記のステップＳ１１１で予測した機器２０Ａのユーザの在宅日時に応じて発送情報を生成する。サーバ１００は、機器２０Ａのユーザの在宅日時に応じた日時に新しい交換品３０Ａが配達されるように発送情報を生成する。例えば、サーバ１００は、日曜日の１７時−１８時に機器２０Ａのユーザに新しい交換品３０Ａが配達されるように発送情報を生成する。

続くステップＳ８３では、サーバ１００が、発送情報を第１ホストコンピュータ３０１（図１参照）に送信する。第１ホストコンピュータ３０１は、管理システム１の管理者の倉庫３００に設置されている。第１ホストコンピュータ３０１がサーバ１００から発送情報を受信すると、管理者の倉庫３００から機器２０のユーザへ新しい交換品３０が発送される。発送情報に基づいて新しい交換品３０が発送される。これによって、機器２０Ａのユーザの在宅日時に応じた日時に新しい交換品３０Ａが配達される。ステップＳ８３が終了した後、サーバ１００は、ステップＳ６１に戻り監視を続ける。サーバ１００は、その他の機器２０Ｂ、２０Ｃ、２０Ｄについても同様の発送処理を実行する。

以上、第５実施例に係る管理システム１について説明した。第５実施例では、各機器２０が、各機器２０のユーザによって操作された場合に操作された日時を特定できる日時情報をサーバ１００に送信する（図２０のステップＳ９２）。また、サーバ１００が、発送情報を生成する場合に、各機器２０から受信する日時情報に基づいて各機器２０のユーザが在宅している在宅日時を予測する（図２２のステップＳ１１１）。また、サーバ１００は、予測した在宅日時に応じた日時に新しい各交換品３０が各機器２０のユーザに配達されるように発送情報を生成する（図２２のステップＳ８２、図１９参照）。

この構成によれば、日時情報に基づいてユーザが在宅日時を予測するので、ユーザが在宅している日時を精度良く予測することができる。また、サーバ１００が予測した在宅日時に応じた日時に新しい各交換品３０が各機器２０のユーザに配達されるように発送情報を生成するので、各ユーザが在宅している日時に新しい交換品３０が届く確率を高めることができる。

上記の実施例では、機器２０が操作された場合に日時情報がサーバ１００に送信される構成であったが、この構成に限定されるものではない。他の実施例では、機器２０の操作によらず、機器２０の運転が実行された場合に日時情報がサーバ１００に送信される構成であってもよい。そのような構成においては、予約運転により機器２０の運転が実行された場合には不在の可能性があるため、日時情報をサーバ１００に送信しない構成が望ましい。この構成の場合は、機器２０の操作毎に日時情報をサーバ１００に送信する構成と比較し、通信量を抑制できる。

本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成し得るものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。

１ ：管理システム
１０ ：住宅
２０ ：機器
２１ ：制御部
２２ ：表示部
３０ ：交換品
４０ ：ルータ
１００ ：サーバ
２００ ：インターネット
３００ ：倉庫
３０１ ：第１ホストコンピュータ
４００ ：倉庫
４０１ ：第２ホストコンピュータ
５０１ ：第１テーブル
５０２ ：第２テーブル
５０３ ：第３テーブル
５０４ ：第４テーブル

また、交換品３０の現在回数は、五徳またはバーナーヘッドが新品の初期状態から現在までの間に使用された回数である。古い交換品３０から新しい交換品３０に交換された初期では、現在回数が０回となる。交換品３０の現在回数は、機器２０で五徳またはバーナーヘッドが使用される毎に増加してゆく。

Claims (2)

1. サーバと、
   前記サーバと通信可能な複数の機器を備えている管理システムであって、
   前記各機器では、各交換品が使用され、
   前記各交換品は、使用による消耗によって交換を要する交換状態になると新しい各交換品に交換されるものであって、
   前記各機器は、前記各交換品が前記各機器で使用されたことを特定できる情報を前記サーバに送信し、
   前記サーバは、
   前記各機器から前記情報を受信すると、前記各機器で使用されている前記各交換品の所定の消耗率に基づいて、前記各機器で使用されている前記各交換品が交換状態になる交換時期をそれぞれ演算し、
   演算した前記各交換品の前記各交換時期より前の所定の各時期に、前記各機器で使用されている前記各交換品が前記各交換時期に近付いたことをユーザに報知する交換情報を前記各機器および／または前記各機器に対応する各端末に送信し、および／または、前記各機器のユーザに交換用の新しい各交換品を発送するための発送情報を生成し、前記交換情報の送信および／または前記発送情報の生成に基づいて前記各交換時期より前の前記所定の各時期に前記各機器のユーザによって購入される前記新しい各交換品の購入数の合計を予測し、
   予測した前記新しい各交換品の購入数の合計と、前記所定の各時期の交換品の在庫数とに基づいて、前記所定の各時期の交換品の在庫の不足数を演算し、演算した前記在庫の不足数に応じて交換品の在庫を補充するための補充情報を生成する、管理システム。
2. 前記各機器は、前記各機器のユーザによって操作された場合に操作された日時を特定できる日時情報を前記サーバに送信し、
   前記サーバは、前記発送情報を生成する場合に、前記各機器から受信する前記日時情報に基づいて前記各機器のユーザが在宅している在宅日時を予測し、予測した前記在宅日時に応じた日時に前記新しい各交換品が前記各機器のユーザに配達されるように前記発送情報を生成する、請求項１に記載の管理システム。