JP2021144398A - コントローラ、商品取引システムおよび自動注文プログラム - Google Patents

Abstract

【課題】状況に応じて自動的な取引を可能とするプラットフォームが提供される。
【解決手段】コントローラは、商品を消費する対象から当該商品の消費状態に関する情報を取得する状態情報取得部と、取得した情報に基づいて予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求を生成して外部へ送信する要求生成部とを含む。購入要求は、購入を希望する商品を特定する情報を含む。
【選択図】図１

Description

本開示は、電子的な商品の取引を実現できるコントローラ、商品取引システムおよび自動注文プログラムに関する。

従来の流通システムにおいては、生産者から小売りを介して買い手の元へ商品が届けられる。このような流通システムに対して、例えば、特開２０１９−１２８８１４号公報（特許文献１）は、マーケットを活性化できる電子売買システムを開示する。

特開２０１９−１２８８１４号公報

上述の特許文献１に開示される電子売買システムは、購入者と販売者との間の商品売買を支援するものであるが、このような従来の電子売買システムは、購入者と販売者との間の遣り取りを電子的に行うに過ぎず、取引の開始自体は人間の判断によって決定される。

本開示は、状況に応じて自動的な取引を可能とするプラットフォームを提供することを目的とする。

本開示のある形態に従うコントローラは、商品を消費する対象から当該商品の消費状態に関する情報を取得する状態情報取得部と、取得した情報に基づいて予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求を生成して外部へ送信する要求生成部とを含む。購入要求は、購入を希望する商品を特定する情報を含む。

要求生成部は、購入を希望する商品の数、および、商品を購入する際の希望価格の少なくとも一方を含んでいてもよい。

要求生成部は、取得した情報に基づいて決定される配送期限を含んでいてもよい。
状態情報取得部は、商品の残量をセンシングするセンシング部を含んでいてもよい。

状態情報取得部は、商品を消費する対象が管理している情報を取得するインターフェイスを含んでいてもよい。

要求生成部は、購入要求に電子署名を付与して外部へ送信するようにしてもよい。
要求生成部は、購入要求にコントローラの位置情報を含めて外部へ送信するようにしてもよい。

コントローラは、認証済みＩＰアドレスを用いて、購入要求の送信先との間でデータ通信を行う通信部をさらに含んでいてもよい。

本開示の別の形態に従う商品取引システムは、上記のコントローラと、商品を販売するための販売要求を生成して外部へ送信する第２の要求生成部と、互いの要求内容が合致する前記購入要求と前記販売要求との組を決定するマッチング処理部とを含む。

本開示のさらに別の形態に従うコンピュータで実行される自動注文プログラムは、コンピュータに、商品を消費する対象から当該商品の消費状態に関する情報を取得するステップと、取得した情報に基づいて予め定められた条件が満たされたか否かを判断するステップと、予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求を生成して外部へ送信するステップとを実行させる。購入要求は、購入を希望する商品を特定する情報を含む。

本開示によれば、状況に応じて自動的な取引を可能とするプラットフォームを実現できる。

本実施の形態に従う商品取引システムにおける処理の概要を説明するための図である。 本実施の形態に従う商品取引システムを構成する消費エンティティの構成例を示す模式図である。 本実施の形態に従う商品取引システムを構成する供給者において用いられる供給者端末の構成例を示す模式図である。 本実施の形態に従う商品取引システムを構成する運営サーバの構成例を示す模式図である。 本実施の形態に従う商品取引システムの自動注文機能の処理手順を示すフローチャートである。 本実施の形態に従う商品取引システムのコントローラによる状態値を取得するための構成例を示す模式図である。 本実施の形態に従う商品取引システムのコントローラによる状態値を取得するための別の構成例を示す模式図である。 本実施の形態に従う商品取引システムのコントローラが生成する購入要求の一例を示す模式図である。 本実施の形態に従う商品取引システムの供給者端末が提供するユーザインターフェイス画面の一例を示す模式図である。 本実施の形態に従う商品取引システムの運営サーバによるユーザ管理の一例を説明するための図である。 本実施の形態に従う商品取引システムの運営サーバにおけるマッチング処理の処理手順を示すフローチャートである。 本実施の形態に従う商品取引システムの運営サーバにおけるマッチング処理の処理手順を示すフローチャートである。 本実施の形態に従う商品取引システムにおいて利用される配送費定義の一例を示す図である。 本実施の形態に従う商品取引システムにおいて利用される配送費定義の別の一例を示す図である。 本実施の形態に従う別の商品取引システムにおける処理の概要を説明するための図である。 本実施の形態に従うさらに別の商品取引システムにおける処理の概要を説明するための図である。

本開示に係る実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。

＜Ａ．商品取引システム１＞
まず、本実施の形態に従う商品取引システム１について説明する。商品取引システム１は、任意の消費エンティティからの商品の購入要求に応じた取引を可能にするプラットフォームを提供する。

図１は、本実施の形態に従う商品取引システム１における処理の概要を説明するための図である。図１を参照して、商品取引システム１は、１または複数の商品を消費する１または複数の消費エンティティ１０と、当該１または複数の商品の少なくとも一部を提供する１または複数の供給者２０と、１または複数の消費エンティティ１０、ならびに、１または複数の供給者２０のいずれからもアクセス可能な運営サーバ３００とを含む。

商品取引システム１において取り扱われる商品としては、特に制限はないが、日用品や消耗品などの繰り返しの購入が想定されているものが好適である。

本明細書において、「消費エンティティ１０」は、任意の商品を消費するエンティティ（主体）を包含するものであり、典型的には、当該商品を消費することが想定されている、個人などの自然人、店舗や事業所などの非自然人（団体や法人を含む）、コンピュータや演算機能を備えたデバイスなどを含む。「消費エンティティ１０」は、商品の取引に関して何らかの意思決定が可能な任意のエンティティ（主体）を包含する概念である。

本明細書において、「供給者２０」は、任意の商品を提供するエンティティ（主体）を包含するものであり、典型的には、当該商品の生産者あるいは輸入者などが想定される。「供給者２０」は、任意の商品を保管または管理する物流会社であってもよいし、コンピュータや演算機能を備えたデバイスであってもよい。「供給者２０」は、「消費エンティティ１０」と同様に、商品の取引に関して何らかの意思決定が可能な任意のエンティティ（主体）を包含する概念である。

以下の説明においては、主として、消費エンティティ１０がコンピュータや演算機能を備えたデバイスである例について説明する。図１には、一例として、ユーザの操作などを介することなく、状況に応じて、洗濯機から洗剤や柔軟剤などが自動的に注文される構成を示す。

消費エンティティ１０の各々は、予め定められた条件（客観的および主観的の両方を含む）が満たされると、購入を希望する任意の商品および数を特定するための情報を含む購入要求１２を運営サーバ３００へ送信する。なお、購入要求１２には、購入を希望する価格を含んでいてもよい。

一方、供給者２０の各々は、販売を希望する任意の商品および当該商品を提供可能な数を特定するための情報を含む販売要求２２を運営サーバ３００へ送信する。なお、販売要求２２には、販売を希望する価格を含んでいてもよい。

運営サーバ３００は、１または複数の消費エンティティ１０からの購入要求１２と、１または複数の供給者２０からの販売要求２２とを比較して、購入要求１２の要求内容と販売要求２２の要求内容とが合致するか否かを判断する（以下、「マッチング処理」とも称す。）。すなわち、運営サーバ３００は、互いの要求内容が合致する購入要求１２と販売要求２２との組を決定するマッチング処理機能を有している。そして、購入要求１２と販売要求２２とが合致すると、取引成立と決定する。

運営サーバ３００は、取引成立と決定された販売要求２２に対応する供給者２０に対して、取引成立の旨を通知するとともに、取引の対象になった商品を消費エンティティ１０へ配送する。なお、商品の配送については、供給者２０自身が行ってもよいが、典型的には、任意の配送者３０が行ってもよい。

運営サーバ３００は、後述するように、消費エンティティ１０と供給者２０との間の決済処理も担当する。

以下、本実施の形態に従う商品取引システム１の構成、機能および処理の詳細について説明する。

＜Ｂ．ハードウェア構成＞
次に、本実施の形態に従う商品取引システム１のハードウェア構成の一例について説明する。

（ｂ１：消費エンティティ１０）
図２は、本実施の形態に従う商品取引システム１を構成する消費エンティティ１０の構成例を示す模式図である。消費エンティティ１０は、コンピュータの一種であるコントローラ１００を主たる構成として実現されてもよい。

図２を参照して、コントローラ１００は、主たるコンポーネントとして、処理回路（processing circuitry）である制御部１１０を含む。制御部１１０は、本実施の形態に従う機能の提供および処理の実行を実現するための演算主体である。

制御部１１０は、図２に示すようなプロセッサおよびメモリを用いて、メモリに格納されたコンピュータ可読命令（computer readable instructions）をプロセッサが実行するように構成されてもよい。あるいは、コンピュータ可読命令に相当する回路が組み込まれたＡＳＩＣ（Application Specific Integrated Circuit）などのハードワイヤード回路を用いて制御部１１０を実現してもよい。さらにあるいは、ＦＰＧＡ（Field-Programmable Gate Array）上にコンピュータ可読命令に相当する回路を実現することで制御部１１０を実現してもよい。また、プロセッサおよびメモリ、ＡＳＩＣ、ＦＰＧＡなどを適宜組み合わせて制御部１１０を実現してもよい。

図２に示すようなプロセッサおよびメモリを用いた構成において、制御部１１０は、プロセッサ１０２と、主メモリ１０４と、ストレージ１０６とを含む。

プロセッサ１０２は、コンピュータ可読命令を順次読出して実行する演算回路である。プロセッサ１０２は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）などで構成される。複数のプロセッサ１０２を用いて制御部１１０を実現してもよいし（マルチプロセッサの構成）、複数のコアを有するプロセッサを用いて制御部１１０を実現してもよい（マルチコアの構成）。

主メモリ１０４は、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）などの揮発性記憶装置である。プロセッサ１０２は、ストレージ１０６に格納された各種プログラムのうち、指定されたプログラムを主メモリ１０４上に展開し、主メモリ１０４と協働することで、本実施の形態に従う各種処理を実現する。

ストレージ１０６は、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなどの不揮発性記憶装置である。ストレージ１０６には、プロセッサ１０２で実行される各種プログラムや各種データが格納されている。典型的には、ストレージ１０６は、後述するような自動注文機能を実現するための自動注文プログラム１０８を格納している。

図２に示すようなプロセッサ１０２がメモリに格納されたコンピュータ可読命令を実行する構成において、メモリはストレージ１０６に相当する。

コントローラ１００は、さらに、ＧＰＳ（Global Positioning System）１１２と、ネットワークインターフェイス１２０と、内部インターフェイス１３０と、センシング部１４０と、出力部１５０とを含む。

ＧＰＳ１１２は、コントローラ１００の位置情報を取得する。なお、ＧＰＳ１１２としては、任意のＧＮＳＳ（Global Navigation Satellite System）を採用できる。

ネットワークインターフェイス１２０は、ネットワークを介して運営サーバ３００との間でデータ通信を行う。ネットワークインターフェイス１２０は、有線および無線のいずれで構成してもよい。ネットワークインターフェイス１２０を有線で構成する場合には、例えば、イーサネット（登録商標）ポート、ＵＳＢ（Universal Serial Bus）ポート、ＩＥＥＥ１３９４などのシリアルポート、レガシーなパラレルポートといった有線接続端子を含んでいてもよい。また、ネットワークインターフェイス１２０を無線で構成する場合には、デバイス、ルータ、移動体基地局などと無線通信するための処理回路およびアンテナなどを含んでもよい。ネットワークインターフェイス１２０が対応する無線通信は、例えば、Ｗｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）、ＬＰＷＡ（Low Power Wide Area）、ＧＳＭ（登録商標）、Ｗ−ＣＤＭＡ、ＣＤＭＡ２０００、ＬＴＥ（Long Term Evolution）、第５世代移動通信システム（５Ｇ）のいずれであってもよい。

内部インターフェイス１３０およびセンシング部１４０は、商品を消費する対象（この場合には、機器５０）から当該商品の消費状態に関する情報を取得する状態情報取得部に相当する。ここで、「商品の消費状態に関する情報」は、対象の商品の注文要否を判断するために必要な情報を包含する概念である。典型的には、「商品の消費状態に関する情報」は、対象に残っている商品の数もしくは量、対象における商品の消費総量もしくは消費速度、対象における商品の追加もしくは消費に係る履歴、対象における商品の追加もしくは消費に係る時間的変化といった、商品の消費に係る任意の情報を含む。

内部インターフェイス１３０は、例えば、洗濯機などの機器５０との間でデータ通信を行う。内部インターフェイス１３０は、機器５０に実装されている制御ロジックから必要な状態値を取得することができる。典型的には、内部インターフェイス１３０は、商品を消費する対象が管理している情報（例えば、在庫情報や動作の履歴情報など）を取得する。

センシング部１４０は、洗濯機などの機器５０あるいは機器５０に関連する部分から必要な情報をセンシングする。センシング部１４０としては、任意のセンサを用いることができる。典型的には、センシング部１４０は、商品の残量をセンシングするように構成されてもよい。

出力部１５０は、制御部１１０での処理結果などを外部へ提示するためのコンポーネントである。出力部１５０は、例えば、ＬＣＤ（Liquid Crystal Display）や有機ＥＬ（Electro-Luminescence）ディスプレイなどであってもよい。また、出力部１５０は、任意のインジケータやスピーカなどであってもよい。

コントローラ１００は、セキュアストレージ１５２をさらに含んでいてもよい。セキュアストレージ１５２は、セキュアな処理を実現するために必要な情報を保持する記憶部である。セキュアストレージ１５２は、ストレージ１０６と同様に、ハードディスク、ＳＳＤ、フラッシュメモリなどの不揮発性記憶装置で構成してもよい。この場合には、公知のアクセス制限機能を付加することで、格納されているデータの改変などを防止するようにしてもよい。また、ＴＰＭ（Trusted Platform Module）などのセキュリティチップを用いて構成してもよい。さらに、ＲＦＩＤ（Radio Frequency IDentifier）タグなどを用いて、必要な情報を保持するようにしてもよい。

セキュアストレージ１５２には、例えば、電子証明書１５４と、秘密鍵および公開鍵からなる鍵ペア１５６と、識別情報１５８とが格納される。電子証明書１５４は、任意の発行者（典型的には、認証局）により発行される。鍵ペア１５６は、情報の改ざんやなりすましなどを防止するために、コントローラ１００から出力される情報に電子署名を付加する処理などに利用される。識別情報１５８は、コントローラ１００を一意に特定するための情報（例えば、シリアル番号や製造番号など）を含む。

例えば、コントローラ１００は、運営サーバ３００へ送信する購入要求１２に、自身の秘密鍵を用いて生成した電子署名を付加することで、運営サーバ３００および供給者端末２００は、正規の購入要求１２であることを認証できる。このように、コントローラ１００は、生成した購入要求１２に電子署名を付与して外部へ送信するようにしてもよい。

さらに、購入要求１２に、コントローラの識別情報１５８を含めたデータセットに対して、コントローラ１００の秘密鍵を用いて生成した電子署名を付加することで、購入要求１２の要求元の正当性をより確実に認証することもできる。

（ｂ２：供給者２０）
図３は、本実施の形態に従う商品取引システム１を構成する供給者２０において用いられる供給者端末２００の構成例を示す模式図である。典型的には、供給者端末２００は、汎用コンピュータを用いて実現される。

図３を参照して、供給者端末２００は、主たるコンポーネントとして、１または複数のプロセッサ２０１と、メインメモリ２０２と、ネットワークインターフェイス２０３と、入力部２０４と、ディスプレイ２０５と、ストレージ２１０とを含む。これらのコンポーネントは、内部バス２０６を介して接続されている。

プロセッサ２０１は、例えば、ＣＰＵやＧＰＵなどで構成される。複数のプロセッサ２０１が配置されてもよいし、複数のコアを有するプロセッサ２０１を採用してもよい。

メインメモリ２０２は、ＤＲＡＭやＳＲＡＭなどの揮発性記憶装置で構成される。ストレージ２１０は、ハードディスクやＳＳＤなどの不揮発性記憶装置で構成され、プロセッサ２０１で実行される各種プログラムや各種データを保持する。ストレージ２１０に格納されたプログラムのうち、指定されたプログラムコードがメインメモリ２０２上に展開され、プロセッサ２０１は、メインメモリ２０２上に展開されたプログラムコードに含まれるコンピュータ可読命令を順次実行することで、後述するような各種機能を実現する。

典型的には、ストレージ２１０は、供給可能な商品の在庫を管理するための在庫管理プログラム２１２と、在庫管理の対象となる各商品の状態を示す在庫情報２１８とを格納している。

ネットワークインターフェイス２０３は、ネットワークを介して運営サーバ３００との間でデータ通信を行う。ネットワークインターフェイス２０３は、例えば、インターネットを介した通信ができるように、イーサネット（登録商標）ポートを含んでいてもよい。

入力部２０４は、任意の入力指示を受け付ける。ディスプレイ２０５は、プロセッサ２０１での処理結果などを表示する。

供給者端末２００の全部または一部は、コンピュータ可読命令に相当する回路が組み込まれたＡＳＩＣなどのハードワイヤード回路を用いて実現してもよい。さらにあるいは、ＦＰＧＡ上にコンピュータ可読命令に相当する回路を用いて実現してもよい。また、プロセッサ２０１およびメインメモリ、ＡＳＩＣ、ＦＰＧＡなどを適宜組み合わせて実現してもよい。

供給者端末２００は、コンピュータ可読命令からなる在庫管理プログラム２１２を格納する非一過性（non-transitory）のメディアから、当該格納しているプログラムなどを読み出すためのコンポーネントをさらに有していてもよい。メディアは、例えば、ＤＶＤ（Digital Versatile Disc）などの光学メディア、ＵＳＢメモリなどの半導体メディアなどであってもよい。在庫管理プログラム２１２は、メディアを介して供給者端末２００にインストールされるだけではなく、ネットワーク上の配信サーバから提供されるようにしてもよい。

（ｂ３：運営サーバ３００）
図４は、本実施の形態に従う商品取引システム１を構成する運営サーバ３００の構成例を示す模式図である。典型的には、運営サーバ３００は、１または複数の汎用コンピュータを用いて実現される。

図４を参照して、運営サーバ３００は、主たるコンポーネントとして、１または複数のプロセッサ３０１と、メインメモリ３０２と、ネットワークインターフェイス３０３と、入力部３０４と、ディスプレイ３０５と、ストレージ３１０とを含む。これらのコンポーネントは、内部バス３０６を介して接続されている。

プロセッサ３０１は、例えば、ＣＰＵやＧＰＵ（Graphics Processing Unit）などで構成される。複数のプロセッサ３０１が配置されてもよいし、複数のコアを有するプロセッサ３０１を採用してもよい。

メインメモリ３０２は、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）などの揮発性記憶装置で構成される。ストレージ３１０は、ハードディスクやＳＳＤ（Solid State Drive）などの不揮発性記憶装置で構成され、プロセッサ３０１で実行される各種プログラムや各種データを保持する。ストレージ３１０に格納されたプログラムのうち、指定されたプログラムコードがメインメモリ３０２上に展開され、プロセッサ３０１は、メインメモリ３０２上に展開されたプログラムコードに含まれるコンピュータ可読命令を順次実行することで、後述するような各種機能を実現する。

典型的には、ストレージ３１０は、マッチング処理を実現するためのマッチングプログラム３１２と、決済処理を実現するための決済プログラム３１４と、要求キュー３１６と、消費エンティティ１０および供給者２０に関する各種情報を含むユーザ情報３１８とを格納している。要求キュー３１６は、１または複数の消費エンティティ１０からの１または複数の購入要求１２、および、１または複数の供給者２０からの１または複数の販売要求２２を一時的に保持する。

マッチングプログラム３１２および決済プログラム３１４は、コンピュータに消費エンティティ１０と供給者２０との間の商品取引を実行させるための商品取引プログラムに相当する。

ネットワークインターフェイス３０３は、消費エンティティ１０および供給者２０の端末などとデータ交換を担当する。ネットワークインターフェイス３０３は、例えば、インターネットを介した通信ができるように、イーサネット（登録商標）ポートを含んでいてもよい。

入力部３０４は、任意の入力指示を受け付ける。ディスプレイ３０５は、プロセッサ３０１での処理結果などを表示する。

運営サーバ３００の全部または一部は、コンピュータ可読命令に相当する回路が組み込まれたＡＳＩＣなどのハードワイヤード回路を用いて実現してもよい。さらにあるいは、ＦＰＧＡ上にコンピュータ可読命令に相当する回路を用いて実現してもよい。また、プロセッサ３０１およびメインメモリ、ＡＳＩＣ、ＦＰＧＡなどを適宜組み合わせて実現してもよい。

運営サーバ３００は、コンピュータ可読命令からなるマッチングプログラム３１２および決済プログラム３１４を格納する非一過性のメディアから、当該格納しているプログラムなどを読み出すためのコンポーネントをさらに有していてもよい。メディアは、例えば、ＤＶＤなどの光学メディア、ＵＳＢメモリなどの半導体メディアなどであってもよい。

マッチングプログラム３１２および決済プログラム３１４は、メディアを介して運営サーバ３００にインストールされるだけではなく、ネットワーク上の配信サーバから提供されるようにしてもよい。

＜Ｃ．消費エンティティ１０およびコントローラ１００＞
本実施の形態に従う商品取引システム１において、消費エンティティ１０は、必要に応じて、必要な商品を自動的に注文することができる機能（以下、「自動注文機能」とも称す。）を有している。

消費エンティティ１０は、洗濯機などの機器５０の状態を監視し、機器５０の状態が予め定められた条件を満たすと、当該条件に応じた商品を自動的に注文する（すなわち、購入要求１２を生成および送信する）。

以下の説明においては、機器５０の典型例として洗濯機を示すが、これに限らず、任意の装置を対象とすることができる。家電製品としては、例えば、複写機・複合機・プリンタ（商品：トナー、インク、紙など）、掃除機（商品：紙パック）、洗浄機能付シェーバー（商品：洗浄液）、コーヒーメーカ（商品：コーヒー）、冷蔵庫（商品：飲料、食料など）、エアコン（商品：フィルタ）、照明器具（商品：蛍光灯、ＬＥＤ電球など）などが挙げられる。

（ｃ１：処理手順）
まず、本実施の形態に従う商品取引システム１の自動注文機能の処理手順について説明する。

図５は、本実施の形態に従う商品取引システム１の自動注文機能の処理手順を示すフローチャートである。図５に示す各ステップは、コントローラ１００のプロセッサ１０２が自動注文プログラム１０８を実行することで実現される。

図５を参照して、コントローラ１００は、対象の機器５０の状態値を取得する（ステップＳ１００）。すなわち、コントローラ１００は、商品を消費する対象から当該商品の消費状態に関する情報を取得する。機器５０が洗濯機であれば、機器５０の状態値としては、例えば、洗剤、柔軟剤、漂白剤の残量といった値が想定される。

コントローラ１００は、取得した機器５０の状態値が予め定められた条件を満たすか否かを判断する（ステップＳ１０２）。すなわち、コントローラ１００は、取得した情報に基づいて予め定められた条件が満たされたか否かを判断する。

取得した機器５０の状態値が予め定められた条件を満たさなければ（ステップＳ１０２においてＮＯ）、以後の処理はスキップされる。

取得した機器５０の状態値が予め定められた条件を満たしていれば（ステップＳ１０２においてＹＥＳ）、コントローラ１００は、取得した機器５０の状態値に応じて、購入要求１２を生成し（ステップＳ１０４）、生成した購入要求１２を運営サーバ３００へ送信する（ステップＳ１０６）。すなわち、コントローラ１００は、予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求１２を生成して外部へ送信する。そして、処理は終了する。

このように、本実施の形態に従う商品取引システム１の自動注文機能においては、任意の対象の状態に応じて、自動的に必要な商品を購入するための購入要求１２を生成および送信できる。すなわち、コントローラ１００は、取得した情報（対象の機器５０の状態値）に基づいて予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求１２を生成して外部（運営サーバ３００）へ送信する要求生成機能を有している。

（ｃ２：状態値の取得）
次に、状態値を取得する方法の一例について説明する。

図６は、本実施の形態に従う商品取引システム１のコントローラ１００による状態値を取得するための構成例を示す模式図である。図６には、洗濯機に装着される洗剤トレイ５２を示す。洗剤トレイ５２の内部には洗剤５４が装填されており、洗濯機で洗濯が実行されるたびに、必要な量が洗濯槽に供給される。

コントローラ１００のセンシング部１４０は、洗剤トレイ５２に関連付けて配置されており、洗剤トレイ５２内の洗剤５４の量に応じて、センシング部１４０の回転角度が変化するようになっている。センシング部１４０は、回転角度に応じて、洗剤トレイ５２内の洗剤５４の残量を示す信号を出力する。この出力される信号に基づいて、洗剤トレイ５２内の洗剤５４の残量が算出される。コントローラ１００は、算出された洗剤５４の残量に基づいて、予め定められた条件が満たされるか否かを判断する。

図７は、本実施の形態に従う商品取引システム１のコントローラ１００による状態値を取得するための別の構成例を示す模式図である。図７には、コントローラ１００の内部インターフェイス１３０が機器５０と接続されている例を示す。

図７（Ａ）には、洗濯機である機器５０が保持している履歴情報５６の一例を示す。コントローラ１００は、内部インターフェイス１３０を介して、機器５０が保持している履歴情報５６などにアクセスし、機器５０における洗濯の実行履歴を取得する。そして、コントローラ１００は、取得した洗濯の実行履歴に基づいて、洗剤の消費量および残量などを算出する。

図７（Ｂ）には、コントローラ１００により算出される洗剤の残量の推定結果１６０の一例を示す。コントローラ１００は、図７（Ｂ）に示すような推定結果１６０に基づいて、予め定められた条件が満たされるか否かを判断する。例えば、推定結果１６０に対して、所定のしきい値１６２を設定しておき、そのしきい値１６２を下回ったとき、あるいは、そのしきい値１６２を下回る時期を予測して、購入要求１２を生成するようにしてもよい。

なお、状態値を取得する方法は、図６および図７に示す構成に限られず、対象の機器５０および対象の商品に応じた任意の取得方法を採用できる。さらに、状態値を取得する処理および構成の一部または全部をユーザが担当するようにしてもよい。例えば、ユーザが残量を目視し、その目視によって得られた残量をコントローラ１００に入力するような形態を採用してもよい。

（ｃ３：条件および購入要求）
次に、自動注文機能に係る条件および生成される購入要求１２の一例について説明する。

図６および図７に示すように、コントローラ１００は、対象の機器５０における洗剤５４の残量などを取得できるので、例えば、購入要求１２を生成するための条件としては、取得された洗剤５４の残量が所定の下限以下になっている、などと設定できる。このような条件が満たされると、コントローラ１００は、購入要求１２を生成する。

図８は、本実施の形態に従う商品取引システム１のコントローラ１００が生成する購入要求１２の一例を示す模式図である。

図８（Ａ）を参照して、コントローラ１００（消費エンティティ１０）が生成する購入要求１２は、商品情報１２１と、個数情報１２２と、希望価格１２３とを含む。

商品情報１２１には、購入対象の商品を特定するための特定情報（後述するような、商品コード）が格納される。

個数情報１２２は、オプショナルな情報であり、購入対象の商品の個数を特定するための情報が任意に設定される。例えば、商品の購入数が常に１個であれば、個数情報１２２を省略してもよい。

希望価格１２３は、オプショナルな情報であり、商品の特性や市場の特性などに応じて任意に設定される。例えば、希望価格１２３には、具体的な購入希望価格に代えて、「最安値」などと設定することもできる。この場合には、後述する運営サーバ３００において最安値を提示する供給者２０との間で、取引が成立することになる。

このように、購入要求１２は、購入を希望する商品を特定する情報の一例である商品情報１２１を含む。また、購入要求１２は、購入を希望する商品の数（個数情報１２２）、および、商品を購入する際の希望価格（希望価格１２３）の少なくとも一方を含んでいてもよい。

さらに、上述の図７（Ｂ）に示すような洗剤の残量の推定結果１６０を利用できる場合には、どのタイミングで洗剤が消費尽くされるかを予測することができる。このような場合には、購入対象の商品が対象の機器５０まで配送される期限を概ね決定できる。

そこで、図８（Ｂ）に示すように、コントローラ１００（消費エンティティ１０）が生成する購入要求１２には、配送期限１２４をさらに含めるようにしてもよい。運営サーバ３００は、購入要求１２に配送期限１２４が含まれている場合には、指定されている配送期限１２４に間に合うように、供給者２０とのマッチング処理を実行する。

このように、購入要求１２は、取得した情報に基づいて決定される配送期限（配送期限１２４）を含んでいてもよい。

図８には、購入要求１２の一例を示すが、これに限られず任意のデータ構造を採用してもよい。

また、図８に示す購入要求１２に、送信元の消費エンティティ１０（コントローラ１００）を特定するための情報を含めるようにしてもよい。一方で、コントローラ１００と運営サーバ３００との間において、セキュアなデータ交換が実行される場合には、そのデータ交換の手続きにおいて、コントローラ１００を一意に特定するための情報を事前に運営サーバ３００へ提供してもよい。このような方法を採用することで、購入要求１２に秘匿することが好ましい情報を含める必要がなくなり、セキュリティ上のリスクを低減できる。

＜Ｄ．供給者２０および供給者端末２００＞
次に、本実施の形態に従う商品取引システム１の供給者２０（供給者端末２００）における処理の一例について説明する。

供給者２０は、供給者端末２００を操作して、消費エンティティ１０に提供できる商品の在庫管理を行うととともに、販売要求２２を生成して、運営サーバ３００へ送信する。すなわち、供給者端末２００は、商品を販売するための販売要求２２を生成して外部（運営サーバ３００）へ送信する要求生成機能を有している。

図９は、本実施の形態に従う商品取引システム１の供給者端末２００が提供するユーザインターフェイス画面の一例を示す模式図である。図９を参照して、ユーザインターフェイス画面２５０は、販売要求２２を生成するための供給者２０からの指示を受け付ける。

より具体的には、ユーザインターフェイス画面２５０は、供給者２０が販売可能な商品の一覧を示すリスト２５２を含む。リスト２５２は、供給者２０が販売可能な各商品を特定するための商品コードを示す商品コード欄２５４と、各商品の商品名を示す商品名欄２５６と、各商品の販売希望価格を示す販売価格欄２５８と、各商品の販売希望個数を示す販売個数欄２６０と、各商品の販売希望個数のうち取引が未だ成立していない個数を示す残り個数欄２６２と、購入希望販売の一部の個数についてのみ要求内容が合致した場合に、当該要求内容が合致した個数についてのみ取引成立として処理するか否かを設定する一部取引欄２６４とを含む。

供給者２０は、販売可能な商品をリスト２５２に登録するとともに、各商品について、販売希望価格（販売価格欄２５８）および販売希望価格（販売個数欄２６０）を入力する。

供給者２０は、検索ボタン２６６を選択して、商品名または商品を特定するコードなどを入力することで、販売可能な商品を検索してリスト２５０２に登録できる。あるいは、供給者２０は、コード読取ボタン２６８を選択して、端末に実装されているカメラなどで購入を希望する商品に付されているバーコードやＱＲコード（登録商標）を読み取ることで、販売可能な商品をリスト２５２に登録できる。

供給者２０は、内容変更ボタン２７０を選択して、リスト２５２に登録されている販売希望価格（販売価格欄２５８）および販売希望価格（販売個数欄２６０）を任意に変更できる。供給者２０が変更した内容は、更新ボタン２７２が選択されることで反映される。

図６に示すようなユーザインターフェイス画面２５０を介して、供給者端末２００が販売要求２２を生成し、運営サーバ３００へ送信する。

なお、商品取引システム１において取り扱われる商品は、パッケージなどに付される識別情報を用いて特定されてもよい。このような識別情報としては、例えば、ＪＡＮ（Japanese Article Number）コード、ＥＡＮ（European Article Number）コード、ＧＴＩＮ−１３、ＧＴＩＮ−８などの商品識別番号を用いてもよい。このような商品識別番号を用いることで、複数の国の間で流通する商品についても取り扱いを容易化できる。

さらに、集合包装用の識別情報を用いるようにしてもよい。集合包装用の識別情報は、企業間の取引単位である集合包装（ケース、ボール、パレットなど）に対し設定される商品識別番号を包含する。このような集合包装用の識別情報としては、ＧＴＩＮ−１４などの集合包装用商品コードが知られている。集合包装用商品コードは、集合包装された個々の商品についての商品識別番号を含むので、商品取引システム１においては、個々の商品を取り扱うこともできるとともに、それらを集合させた状態で取り扱うこともできる。

なお、集合包装用商品コードは、ＩＴＦ（Inter-Leaved two of Five）シンボルなどのバーコードシンボルとして具現化できる。

上述したような個別の商品を示す識別情報および集合包装用の識別情報を併用することで、商品の特性や供給者２０の事情に応じたより柔軟な取引を実現できる。

＜Ｅ．運営サーバ３００＞
次に、本実施の形態に従う商品取引システム１の運営サーバ３００における処理の一例について説明する。

（ｅ１：ユーザ管理）
商品取引システム１の運営サーバ３００は、マッチング処理に必要なユーザ情報を管理する。

図１０は、本実施の形態に従う商品取引システム１の運営サーバ３００によるユーザ管理の一例を説明するための図である。図１０（Ａ）には、消費エンティティ１０の各々を管理するための管理情報３５０の一例を示し、図１０（Ｂ）には、供給者２０の各々を管理するための管理情報３６０の一例を示す。

図１０（Ａ）を参照して、消費エンティティ１０の各々を管理するための管理情報３５０は、消費エンティティ１０の配送先（住所あるいは緯度経度）を示す配送先情報３５２を含む。管理情報３５０に含まれる配送先情報３５２は、消費エンティティ１０から受信した購入要求１２の配送先情報として利用されてもよい。但し、消費エンティティ１０のコントローラ１００にＧＰＳ１１２が実装される場合には、ＧＰＳ１１２からのコントローラ１００の位置情報を購入要求１２に含めるようにすれば、配送先情報３５２を省略してもよい。

管理情報３５０は、消費エンティティ１０の口座の残高を示す残高情報３５４を含む。残高情報３５４は、消費エンティティ１０および供給者２０の各々が保有する経済的価値を管理する口座を具現化したものである。経済的価値としては、特定の通貨での金額が想定されているが、仮想通貨のようなものであってもよいし、商品取引システム１において利用される独自ポイントであってもよい。

運営サーバ３００は、消費エンティティ１０が購入要求１２を生成すると、対応する残高情報３５４から、購入要求１２に基づいて決定される購入予定額をリザーブ（予約）する。すなわち、運営サーバ３００は、購入要求１２に応じて決定される価値を対応する消費エンティティ１０の口座から予約する。

管理情報３５０は、消費エンティティ１０の取引情報を示す購入履歴３５６を含む。運営サーバ３００は、取引が成立するたびに購入履歴３５６の内容を更新する。なお、運営サーバ３００は、取引が成立する場合に加えて、消費エンティティ１０が購入要求１２を生成するたびに、その内容を残高情報３５４に反映するようにしてもよい。

図１０（Ｂ）を参照して、供給者２０の各々を管理するための管理情報３６０は、供給者２０の口座の残高を示す残高情報３６４を含む。運営サーバ３００は、いずれかの消費エンティティ１０と供給者２０との間で取引が成立すると、当該取引によって遣り取りされる金額が対応する残高情報３６４に加算される。

管理情報３６０は、供給者２０の取引情報を示す販売履歴３６６を含む。運営サーバ３００は、取引が成立するたびに販売履歴３６６の内容を更新する。

上述したように、運営サーバ３００は、図１０に示される管理情報３５０および管理情報３６０を用いて、消費エンティティ１０と供給者２０との間の取引に関する情報を管理する。

（ｅ２：マッチング処理）
次に、商品取引システム１の運営サーバ３００におけるマッチング処理の一例について説明する。図１１および図１２は、本実施の形態に従う商品取引システム１の運営サーバ３００におけるマッチング処理の処理手順を示すフローチャートである。図１１および図１２には、消費エンティティ１０と供給者２０との間の商品取引をコンピュータが実行する商品取引方法が示される。

図１１および図１２に示す各ステップは、典型的には、運営サーバ３００のプロセッサ３０１がマッチングプログラム３１２および決済プログラム３１４（商品取引プログラムに相当）を実行することで実現される。

図１１および図１２を参照して、運営サーバ３００は、消費エンティティ１０のコントローラ１００からの購入要求１２または供給者２０の供給者端末２００からの販売要求２２を受信したか否かを判断する（ステップＳ３００）。コントローラ１００からの購入要求１２または供給者端末２００からの販売要求２２を受信していれば（ステップＳ３００においてＹＥＳ）、運営サーバ３００は、受信した購入要求１２または販売要求２２を要求キュー３１６に格納する（ステップＳ３０２）。

続いて、運営サーバ３００は、受信した要求が購入要求１２であるか否かを判断する（ステップＳ３０４）。受信した要求が購入要求１２であれば（ステップＳ３０４においてＹＥＳ）、運営サーバ３００は、当該受信した購入要求１２の内容に基づいて決定される購入予定額が、購入要求１２を送信した消費エンティティ１０の口座に存在するか否かを判断する（ステップＳ３０６）。

購入予定額が消費エンティティ１０の口座に存在していれば（ステップＳ３０６においてＹＥＳ）、運営サーバ３００は、消費エンティティ１０の口座から購入予定額をリザーブ（予約）する（ステップＳ３０８）。そして、ステップＳ３１０以下のマッチング処理が実行される。

購入予定額が消費エンティティ１０の口座に存在していなければ（ステップＳ３０６においてＮＯ）、運営サーバ３００は、ステップＳ３１０以下のマッチング処理を実行しない。この際、運営サーバ３００は、購入要求１２を生成できない旨を消費エンティティ１０のコントローラ１００に通知してもよい。

受信した要求が販売要求２２であれば（ステップＳ３０４においてＮＯ）、ステップＳ３０６およびＳ１０８の処理はスキップされる。

消費エンティティ１０のコントローラ１００からの購入要求１２または供給者２０の供給者端末２００からの販売要求２２を受信していなければ（ステップＳ３００においてＮＯ）、運営サーバ３００は、消費エンティティ１０のコントローラ１００から購入要求１２の変更または供給者２０の供給者端末２００から販売要求２２の変更を受信したか否かを判断する（ステップＳ３０９）。消費エンティティ１０のコントローラ１００から購入要求１２の変更または供給者２０の供給者端末２００から販売要求２２の変更を受信していれば（ステップＳ３００においてＹＥＳ）、ステップＳ３１０以下のマッチング処理が実行される。

消費エンティティ１０のコントローラ１００から購入要求１２の変更および供給者２０の供給者端末２００から販売要求２２の変更のいずれも受信していなければ（ステップＳ３００においてＮＯ）、ステップＳ３００以下の処理が繰り返される。

消費エンティティ１０のコントローラ１００から購入要求１２の変更および供給者２０の供給者端末２００から販売要求２２の変更を受信していなければ（ステップＳ３００においてＮＯ）、ステップＳ３００以下の処理が繰り返される。

運営サーバ３００は、新たに受信または更新された要求が購入要求１２および販売要求２２のいずれであるかを判断する（ステップＳ３１０）。

新たに受信または更新された要求が購入要求１２であれば（ステップＳ３１０において「購入要求」）、運営サーバ３００は、当該新たに受信または更新された購入要求１２をマッチング対象の購入要求１２に設定し（ステップＳ３１２）、要求キュー３１６に格納されている販売要求２２のうち１つをマッチング候補として選択する（ステップＳ３１４）。そして、運営サーバ３００は、マッチング対象の購入要求１２とマッチング候補の販売要求２２とを比較して、互いの要求内容が合致するか否かを判断する（ステップＳ３１６）。

マッチング対象の購入要求１２とマッチング候補の販売要求２２との間で、互いの要求内容が合致すれば（ステップＳ３１６においてＹＥＳ）、運営サーバ３００は、取引成立と決定し、対象の購入要求１２および販売要求２２にそれぞれ対応する消費エンティティ１０および供給者２０に通知し（ステップＳ３１８）、対象の購入要求１２および販売要求２２を、対象の商品の配送完了待ちのステータスに変更する（ステップＳ３２０）。そして、マッチング処理は終了する。

マッチング対象の購入要求１２とマッチング候補の販売要求２２との間で、互いの要求内容が合致しなければ（ステップＳ３１６においてＮＯ）、運営サーバ３００は、要求キュー３１６に格納されているすべての販売要求２２についてマッチング処理が完了したか否かを判断する（ステップＳ３２２）。要求キュー３１６に格納されている販売要求２２のうちマッチング処理が行われていないものがあれば（ステップＳ３２２においてＮＯ）、運営サーバ３００は、未だマッチング処理が行われていない１つの販売要求２２をマッチング候補として選択し（ステップＳ３２４）、ステップＳ３１６以下の処理を繰り返す。

一方、要求キュー３１６に格納されているすべての販売要求２２についてマッチング処理が完了していれば（ステップＳ３２２においてＹＥＳ）、運営サーバ３００は、互いの要求内容が合致する購入要求１２と販売要求２２とが見つからなかった判断し、マッチング処理を終了する。

新たに受信または更新された要求が販売要求２２であれば（ステップＳ３１０において「販売要求」）、運営サーバ３００は、当該新たに受信または更新された販売要求２２をマッチング対象の販売要求２２に設定し（ステップＳ３３２）、要求キュー３１６に格納されている購入要求１２のうち１つをマッチング候補として選択する（ステップＳ３３４）。そして、運営サーバ３００は、マッチング対象の販売要求２２とマッチング候補の購入要求１２とを比較して、互いの要求内容が合致するか否かを判断する（ステップＳ３３６）。

マッチング対象の販売要求２２とマッチング候補の購入要求１２との間で、互いの要求内容が合致すれば（ステップＳ３３６においてＹＥＳ）、運営サーバ３００は、取引成立と決定し、対象の販売要求２２および購入要求１２にそれぞれ対応する供給者２０および消費エンティティ１０に通知し（ステップＳ３３８）、対象の販売要求２２および購入要求１２を、対象の商品の配送完了待ちのステータスに変更する（ステップＳ３４０）。そして、マッチング処理は終了する。

マッチング対象の販売要求２２とマッチング候補の購入要求１２との間で、互いの要求内容が合致しなければ（ステップＳ３３６においてＮＯ）、運営サーバ３００は、要求キュー３１６に格納されているすべての購入要求１２についてマッチング処理が完了したか否かを判断する（ステップＳ３４２）。要求キュー３１６に格納されている購入要求１２のうちマッチング処理が行われていないものがあれば（ステップＳ３４２においてＮＯ）、運営サーバ３００は、未だマッチング処理が行われていない１つの購入要求１２をマッチング候補として選択し（ステップＳ３４４）、ステップＳ３３６以下の処理を繰り返す。

一方、要求キュー３１６に格納されているすべての購入要求１２についてマッチング処理が完了していれば（ステップＳ３４２においてＹＥＳ）、運営サーバ３００は、互いの要求内容が合致する販売要求２２と購入要求１２とが見つからなかった判断し、マッチング処理を終了する。

＜Ｆ．変形例＞
上述の説明においては、本実施の形態に従う商品取引システム１の典型例について説明したが、以下のような各種の変形例の適用が可能である。なお、以下に説明する変形例は、任意に組み合わせて適宜適用できる。

（ｆ１：ＥＶＥＲ／ＩＰ（登録商標））
本実施の形態に従う商品取引システム１を構成する各デバイスの通信プロトコルとして、コネクトフリー株式会社が提供するＥＶＥＲ／ＩＰ（登録商標）を採用してもよい。ＥＶＥＲ／ＩＰを採用した場合において、コントローラ１００、供給者端末２００および運営サーバ３００の各デバイスは、認証済みＩＰアドレスを有することになる。すなわち、コントローラ１００、供給者端末２００および運営サーバ３００の各デバイスは、認証済みＩＰアドレスを用いて、送信先との間でデータ通信を行うネットワークインターフェイス（通信部）を有することになる。

ここで、「認証済みＩＰアドレス」は、通信先あるいは第三者に対して、各デバイスが保持しているＩＰアドレスの正当性が保証されている状態を意味する。ＥＶＥＲ／ＩＰにおいては、「認証済みＩＰアドレス」は、不可逆な暗号学的ハッシュ関数によって生成されるとともに、認証局によって直接的または間接的に認証されたＩＰアドレスであることを意味する。このような認証済みＩＰアドレスを用いることで、各デバイスがデータ通信に利用するＩＰアドレスが偽装されていないことを保証できる。

より具体的には、認証済みＩＰアドレスは、各デバイスが保持する秘密鍵および公開鍵からなる鍵ペアと、予め定められたハッシュ関数とを用いて生成される。予め定められたハッシュ関数に公開鍵を入力することでハッシュ値を算出し、その算出されたハッシュ値の全部または一部が各デバイスの認証済みＩＰアドレスとなる。デバイス間で予め定められたハッシュ関数を共有しておくことで、他のデバイスから取得した公開鍵に基づいて、当該公開鍵の送信元であるデバイスのＩＰアドレスを決定できるとともに、その正当性を認証できる。

例えば、コントローラ１００は、生成した購入要求１２の送信先である運営サーバ３００との間で認証済みＩＰアドレスを用いてデータ通信を行う。また、供給者端末２００は、生成した販売要求２２の送信先である運営サーバ３００との間で認証済みＩＰアドレスを用いてデータ通信を行う。認証済みＩＰアドレスを用いることで、購入要求１２および販売要求２２を送信したデバイス自体を認証でき、なりすましなどによる不正な売買を防止できる。

（ｆ２：マッチング処理の簡素化）
上述の説明においては、同一の商品が複数の供給者２０から提供される場合を想定したマッチング処理を例示したが、特定の商品を提供する供給者２０が一つであった場合には、マッチング処理を簡素化してもよい。

この場合には、運営サーバ３００が消費エンティティ１０（コントローラ１００）からの購入要求１２を受信すると、受信した購入要求１２の内容に従って、取引を成立させるようにしてもよい。

この場合、消費エンティティ１０と供給者２０との間で予め取り決めた価格を採用してもよい。

（ｆ３：配送費）
購入要求１２と販売要求２２とのマッチング処理においては、配送費を考慮するようにしてもよい。すなわち、運営サーバ３００は、供給者２０から消費エンティティ１０までの特定の商品を配送するための配送費を反映した上で、購入要求１２と販売要求２２とがマッチングするか否かを判断する。この配送費の考慮にあたっては、消費エンティティ１０と供給者２０との間の距離を考慮してもよい。以下、配送費の算出方法の一例について説明する。

図１３は、本実施の形態に従う商品取引システム１において利用される配送費定義３２６の一例を示す図である。図１３に示す配送費定義３２６は、商品ごと（図１３の例では「商品Ａ」）に配送費を定義する。配送費定義３２６においては、消費エンティティ１０と供給者２０との間の距離を区分（区分１〜５）して、区分ごとに配送費が定義される。購入要求１２または販売要求２２において配送費の算出が必要な場合には、消費エンティティ１０の配送先情報３５２および配送費定義３２６を参照して、配送費が決定される。

図１３に示される配送費定義３２６は、販売要求２２の配送費定義として利用されてもよい。

図１４は、本実施の形態に従う商品取引システム１において利用される配送費定義３２７の別の一例を示す図である。図１４に示す配送費定義３２７は、基本的にはすべての商品に対して配送費を定義する。配送費定義３２７においては、消費エンティティ１０と供給者２０との間の距離を区分（区分１〜５）して、区分ごとに配送費が定義される。

いずれかの商品について配送費の算出が必要な場合には、商品ごとの重量を示す重量テーブル３２８を参照して、各商品についての重量が決定され、当該決定された重量を配送費定義３２７に適用することで、配送費が決定される。

なお、図１３および図１４には、消費エンティティ１０と供給者２０との間の距離を区分して、各区分について配送費が定義されている例を示したが、これに限らず、単位距離（例えば、１ｋｍ）あたりに配送費を定義するようにしてもよい。さらに、国内用および海外用の配送費定義をそれぞれ規定してもよい。

以上のように、本実施の形態に従う商品取引システム１においては、上述したような配送費定義を利用することで、必要な配送費を算出できる。このように算出される配送費を考慮して、マッチング処理を行うようにしてもよい。

（ｆ４：利用料）
本実施の形態に従う商品取引システム１を利用する費用については、消費エンティティ１０および供給者２０のいずれが負担するようにしてもよい。例えば、消費エンティティ１０が消費を購入するたびに、商品の価格に所定率（例えば、１．０％）を乗じた額が自動的に利用料として口座から引き落とされるようにしてもよい。

あるいは、商品を供給する供給者２０が販売した商品の数あるいは販売額に応じた利用料を負担するようにしてもよい。さらに、商品を供給する供給者２０は、供給する商品の数などに応じて定まる一定額を利用料として負担するようにしてもよい。このような利用料の負担については、任意に設計できる。

但し、利用料を自動的に算出および徴収できるように、消費エンティティ１０および供給者２０の口座に関連付けた処理の実装が好ましい。

（ｆ５：メタ商品）
本実施の形態に従う商品取引システム１においては、同一種類の複数の商品をまとめて１つの商品として取り扱うようにしてもよい。このような商品を「メタ商品」とも称す。

例えば、「洗剤」については、様々な商品が提供されているが、消費エンティティ１０の一部は、特定の生産者および商品を特定することまでは行わず、単に「洗剤」を購入したいと希望するものも存在する。

そこで、例えば、「Ａ社製の洗剤ＡＡＡ」といった商品を特定せず、包括的な商品種別を規定するメタ商品を規定してもよい。

このようなメタ商品にいずれの商品が含まれるのかという対応付け情報を運営サーバ３００に保持しておくことで、消費エンティティ１０は、「洗剤」（いずれの商品かは問わない）を注文できる。

一方、供給者２０は、メタ商品が要求する商品種別に該当さえすれば、任意の商品を提供できるので、在庫処分などをより容易に行うことができる。

なお、各メタ商品にどのような商品を含めるのかについては、運営サーバ３００側で管理してもよいし、各メタ商品に含ませることのできる条件を明示して、当該条件に従って供給者２０側でメタ商品として販売するようにしてもよい。運営サーバ３００側でメタ商品を管理する場合には、メタ商品を示す商品識別番号と、当該メタ商品に含まれる特定の１または複数の商品の各々を示す商品識別番号とを対応付けるテーブルを保持するようにしてもよい。

このように、メタ商品を利用可能にすることで、より柔軟な商品の取引を実現できる。
（ｆ６：有効期限オプション）
消費エンティティ１０および供給者２０は、取引が成立するまでは、購入要求１２および販売要求２２をそれぞれ任意に取り消しあるいは撤回できるようにしてもよい。さらに、商品の特性によっては、特定に期限までに購入または販売しなければならない場合もある。

このようなニーズを考慮して、購入要求１２および販売要求２２について有効期限を設定するようにしてもよい。より具体的には、消費エンティティ１０および供給者２０は、任意の購入要求１２および販売要求２２を生成したときに、取引が成立しなければ、要求を取り消しあるいは撤回する期限（有効期限の条件）を付加できるようにしてもよい。

運営サーバ３００は、有効期限が指定された購入要求１２および販売要求２２については、指定された有効期限が到来しても取引が成立していなければ、対応する購入要求１２または販売要求２２を強制的に取り消す。このような有効期限の条件を購入要求１２または販売要求２２に付加することで、時期に遅れて取引が成立してしまうような事態を回避できる。

有効期限の指定方法としては、特定の日付、特定の日時、今日中、今週中、今月中などの任意の方法を採用してもよい。

（ｆ７：在庫有無オプション）
供給者２０は特定の商品を常時供給することが予定されているが、何からの事情で一時的に商品を供給できない状況になっている可能性もある。このような場合、商品が入荷次第、商品は消費エンティティ１０へ配送されることになるが、商品入荷まで待たされることになる。

そこで、消費エンティティ１０が購入要求１２を生成する際に、指定した商品の在庫の有無を条件として追加するようにしてもよい。より具体的には、供給者２０が在庫を有している場合に限って取引を成立させるのか、あるいは、供給者２０が在庫を有していなくても取引を成立させるのかを消費エンティティ１０が選択できるようにしてもよい。

供給者２０が在庫を有している場合に限って取引を成立させることが条件とされている場合には、指定された商品が供給者２０の在庫として存在している場合に限って、取引が成立することになる。

一方、供給者２０が在庫を有していなくても取引を成立させることが指定されている場合には、供給者２０に対象の商品が入荷するまでの時間などを消費エンティティ１０に提示するようにしてもよい。

（ｆ８：配送開始期限オプション）
消費エンティティ１０は何らかの商品をなるべく早く手に入れたいと考えている場合もある。そこで、消費エンティティ１０が購入要求１２を生成する際に、指定した商品が供給者２０から配送されるまでの期限を条件として追加するようにしてもよい。より具体的には、消費エンティティ１０は、取引が成立してから商品が配送されるまでの時間（例えば、取引成立から６時間以内など）、あるいは、商品を配送すべき期限（例えば、１０月１日１５時など）を指定できるようにしてもよい。

このような条件が付加された購入要求１２が生成された場合には、運営サーバ３００は、供給者２０からの配送可能時刻などの情報の提供を受けて、購入要求１２と販売要求２２との間で要求内容が合致するか否かを判断する。

（ｆ９：配送可能範囲オプション）
供給者２０の事業規模によっては、商品を配送できる範囲が制限される場合がある。このような配送範囲の制限を考慮して、供給者２０が販売要求２２を生成する際に、商品を配送可能な範囲を予め指定するようにしてもよい。より具体的には、供給者２０は、商品を配送可能な範囲（例えば、日本国内のみ、５００ｋｍ否かなど）を指定できるようにしてもよい。

このような条件が付加された販売要求２２が生成された場合には、運営サーバ３００は、消費エンティティ１０の配送先情報（消費エンティティ１０の位置を示す情報）を参照して、購入要求１２と販売要求２２との間で要求内容が合致するか否かを判断する。

＜Ｇ．商品取引システム１の別形態＞
上述の説明においては、運営サーバ３００を中心とする商品取引システム１を例示するが、このような運営サーバ３００を用いない構成を採用してもよい。すなわち、一種のピアトゥピアに類似した構成を採用してもよい。

（ｇ１：供給者２０主導のシステム）
図１５は、本実施の形態に従う別の商品取引システム１Ａにおける処理の概要を説明するための図である。図１５を参照して、商品取引システム１Ａは、１または複数の消費エンティティ１０と、供給者２０とを含む。図１５に示す商品取引システム１Ａにおいては、運営サーバ３００が存在しない代わりに、供給者２０（供給者端末２００）が消費エンティティ１０（コントローラ１００）からの購入要求１２を処理する。

すなわち、供給者２０に配置された供給者端末２００がマッチング処理を実行する。但し、供給者端末２００で実行されるマッチング処理においては、単一の供給者２０が販売要求２２を生成するのみであるので、処理内容は簡素化されたものとなっている。

このように、運営サーバ３００を配置せず、供給者２０（供給者端末２００）と、１または複数の消費エンティティ１０（コントローラ１００）との間で通信を行って、必要に応じて購入要求１２を処理するようにしてもよい。

図１５に示す商品取引システム１Ａにおいて、供給者２０に配置された供給者端末２００は、図３に示す構成に加えて、運営サーバ３００が有している機能（例えば、図４に示されるマッチングプログラム３１２、決済プログラム３１４、要求キュー３１６、およびユーザ情報３１８など）を含むようにしてもよい。

（ｇ２：配送管理サーバ４００を付加したシステム）
図１５に示す商品取引システム１Ａにおいては、図１に示す商品取引システム１の運営サーバ３００と同様の機能を有する供給者２０（供給者端末２００）を用いる構成例を示すが、配送に関する処理については、別のサーバを配置してもよい。

図１６は、本実施の形態に従うさらに別の商品取引システム１Ｂにおける処理の概要を説明するための図である。図１６を参照して、商品取引システム１Ｂは、図１５に示す商品取引システム１Ａに対して配送管理サーバ４００をさらに追加した構成に相当する。

配送管理サーバ４００は、供給者２０（供給者端末２００）と通信を行って、配送費および配送者を管理する処理を実行する。すなわち、配送管理サーバ４００は、図１３および図１４に示すような配送費定義３２６，３２７を有しており、配送費を決定する処理や、複数の配送者から適切な配送者を決定する処理などを実行するようにしてもよい。

このように、配送に関する処理を担当する配送管理サーバ４００を配置することで、複数の供給者２０（供給者端末２００）からの依頼を統括して、適切な配送者３０を決定できるので、効率的な配送を実現できる。また、利用可能な配送者が更新されても、配送管理サーバ４００が保持する情報のみを更新すればよいので、柔軟なシステムを実現できる。

＜Ｈ．その他の形態＞
（ｈ１：自動注文機能の応用例）
本実施の形態に従う商品取引システム１に係る自動注文機能は、様々な施設および業種に応用が可能である。

例えば、ホテルの備品（歯ブラシ、タオル、スリッパ、シャンプー、トイレットペーパなど）を自動的に注文するようなシステムに応用が可能である。この場合には、コントローラ１００とホテルの予約システムとを接続し、あるいは、ホテルの予約システムの一部に自動注文プログラム１０８（図２）を組み込むことで、宿泊者延べ数などを取得でき、その取得された宿泊者延べ数などの情報に基づいて、必要な備品を必要な数だけ自動的に注文できるようにしてもよい。

また、例えば、フレッシュジュースショップにおいて、必要な原材料（牛乳、フルーツ、コップ、ストローなど）を自動的に注文するようなシステムに応用が可能である。この場合には、コントローラ１００とレジスターとを接続し、あるいは、レジスターの一部に自動注文プログラム１０８（図２）を組み込むことで、販売されたジュースの数および種類などを取得でき、その取得されたジュースの数および種類に基づいて、必要な原材料を必要な数だけ自動的に注文できるようにしてもよい。

この場合、ジュースの種類ごとに消費される原材料の量が異なるので、ジュースの種類ごとに消費される原材料の種類および量などの成分情報を予め規定しておき、その規定された成分情報に各ジュースの販売数を乗じることで、必要な原材料の種類および量を決定できる。

このように、本実施の形態に従う商品取引システム１は、様々な分野のビジネスに応用が可能である。

（ｈ２：口座）
商品取引システム１においては、国際的な商品の取引も可能であり、このような場合には、ユーザの口座は、特定の通貨（例えば、日本円や米国ドルなど）で統一してもよいし、複数の通貨からユーザが特定の通貨を選択するようにしてもよい。異なる通貨の口座間で取引が行われる場合には、取引時の為替レートを考慮して、口座間で代金が遣り取りされてもよい。

あるいは、任意の仮想通貨を用いて各ユーザの口座を管理するようにしてもよい。共通の仮想通貨を用いることで、為替レートに基づく変換処理などを省略できる。

（ｈ３：分散配置）
上述の説明においては、運営サーバ３００がマッチング処理および決済処理を実行する例を示すが、それぞれの処理を異なるサーバに実装してもよいし、複数の運営サーバ３００を用いて実装してもよい。例えば、国ごとまたは地域ごとに運営サーバ３００を用意するとともに、運営サーバ３００同士を連携することで、国際的な商品の取引を実現できる。

＜Ｉ．利点＞
本実施の形態に従う商品取引システム１によれば、コントローラ１００が商品を消費する対象から当該商品の消費状態に関する情報を取得し、当該取得した情報に基づいて予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求１２を自動的に生成して、運営サーバ３００などへ送信する。そして、運営サーバ３００を介して商品の取引が実行される。このように、本実施の形態に従う商品取引システム１によれば、状況に応じて自動的な取引を可能とするプラットフォームを提供できる。

今回開示された実施の形態はすべての点で例示であって制限的なものでないと考えられるべきである。本発明の範囲は上記した説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１，１Ａ，１Ｂ 商品取引システム、１０ 消費エンティティ、１２ 購入要求、２０ 供給者、２２ 販売要求、３０ 配送者、５０ 機器、５２ 洗剤トレイ、５４ 洗剤、５６ 履歴情報、１００ コントローラ、１０２，２０１，３０１ プロセッサ、１０４ 主メモリ、１０６，２１０，３１０ ストレージ、１０８ 自動注文プログラム、１１０ 制御部、１２０，２０３，３０３ ネットワークインターフェイス、１２１ 商品情報、１２２ 個数情報、１２３ 希望価格、１２４ 配送期限、１３０ 内部インターフェイス、１４０ センシング部、１５０ 出力部、１６０ 推定結果、１６２ しきい値、２００ 供給者端末、２０２，３０２ メインメモリ、２０４，３０４ 入力部、２０５，３０５ ディスプレイ、２０６，３０６ 内部バス、２１２ 在庫管理プログラム、２１８ 在庫情報、２５０ ユーザインターフェイス画面、２５２，２５０２ リスト、２５４ 商品コード欄、２５６ 商品名欄、２５８ 販売価格欄、２６０ 販売個数欄、２６２ 残り個数欄、２６４ 一部取引欄、２６６ 検索ボタン、２６８ コード読取ボタン、２７０ 内容変更ボタン、２７２ 更新ボタン、３００ 運営サーバ、３１２ マッチングプログラム、３１４ 決済プログラム、３１６ 要求キュー、３１８ ユーザ情報、３２６，３２７ 配送費定義、３２８ 重量テーブル、３５０，３６０ 管理情報、３５２ 配送先情報、３５４，３６４ 残高情報、３５６ 購入履歴、３６６ 販売履歴、４００ 配送管理サーバ。

Claims (10)

1. 商品を消費する対象から当該商品の消費状態に関する情報を取得する状態情報取得部と、
   前記取得した情報に基づいて予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求を生成して外部へ送信する要求生成部とを備え、
   前記購入要求は、購入を希望する商品を特定する情報を含む、コントローラ。
2. 前記要求生成部は、購入を希望する商品の数、および、商品を購入する際の希望価格の少なくとも一方を含む、請求項１に記載のコントローラ。
3. 前記要求生成部は、前記取得した情報に基づいて決定される配送期限を含む、請求項１または２に記載のコントローラ。
4. 前記状態情報取得部は、前記商品の残量をセンシングするセンシング部を含む、請求項１〜３のいずれか１項に記載のコントローラ。
5. 前記状態情報取得部は、前記商品を消費する対象が管理している情報を取得するインターフェイスを含む、請求項１〜４のいずれか１項に記載のコントローラ。
6. 前記要求生成部は、前記購入要求に電子署名を付与して外部へ送信する、請求項１〜５のいずれか１項に記載のコントローラ。
7. 前記要求生成部は、前記購入要求に前記コントローラの位置情報を含めて外部へ送信する、請求項１〜６のいずれか１項に記載のコントローラ。
8. 認証済みＩＰアドレスを用いて、前記購入要求の送信先との間でデータ通信を行う通信部をさらに備える、請求項１〜７のいずれか１項に記載のコントローラ。
9. 請求項１〜８のいずれか１項に記載のコントローラと、
   商品を販売するための販売要求を生成して外部へ送信する第２の要求生成部と、
   互いの要求内容が合致する前記購入要求と前記販売要求との組を決定するマッチング処理部とを備える、商品取引システム。
10. コンピュータで実行される自動注文プログラムであって、前記コンピュータに
    商品を消費する対象から当該商品の消費状態に関する情報を取得するステップと、
    前記取得した情報に基づいて予め定められた条件が満たされたか否かを判断するステップと、
    前記予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求を生成して外部へ送信するステップとを実行させ、
    前記購入要求は、購入を希望する商品を特定する情報を含む、自動注文プログラム。

Images