(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023086937
(43)【公開日】2023-06-22
(54)【発明の名称】コントローラ、商品取引システムおよび自動注文プログラム
(51)【国際特許分類】
G06Q 30/0601 20230101AFI20230615BHJP
【FI】
G06Q30/0601 310
【審査請求】有
【請求項の数】10
【出願形態】OL
(21)【出願番号】P 2023073922
(22)【出願日】2023-04-28
(62)【分割の表示】P 2020041761の分割
【原出願日】2020-03-11
(71)【出願人】
【識別番号】521314116
【氏名又は名称】ネライ株式会社
(71)【出願人】
【識別番号】514318600
【氏名又は名称】コネクトフリー株式会社
(71)【出願人】
【識別番号】521314127
【氏名又は名称】帝都 久利寿
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】帝都 久利寿
(57)【要約】
【課題】状況に応じて自動的な取引を可能とするプラットフォームが提供される。
【解決手段】コントローラは、商品を消費する対象から当該商品の消費状態に関する情報を取得する状態情報取得部と、取得した情報に基づいて予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求を生成して外部へ送信する要求生成部とを含む。購入要求は、購入を希望する商品を特定する情報を含む。
【選択図】
図1
【特許請求の範囲】
【請求項1】
商品を消費する対象から当該商品の消費状態に関する情報を取得する状態情報取得部と、
前記取得した情報に基づいて予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求を生成して外部へ送信する要求生成部とを備え、
前記購入要求は、購入を希望する商品を特定する情報を含む、コントローラ。
【請求項2】
前記要求生成部は、購入を希望する商品の数、および、商品を購入する際の希望価格の少なくとも一方を含む、請求項1に記載のコントローラ。
【請求項3】
前記要求生成部は、前記取得した情報に基づいて決定される配送期限を含む、請求項1または2に記載のコントローラ。
【請求項4】
前記状態情報取得部は、前記商品の残量をセンシングするセンシング部を含む、請求項1~3のいずれか1項に記載のコントローラ。
【請求項5】
前記状態情報取得部は、前記商品を消費する対象が管理している情報を取得するインターフェイスを含む、請求項1~4のいずれか1項に記載のコントローラ。
【請求項6】
前記要求生成部は、前記購入要求に電子署名を付与して外部へ送信する、請求項1~5のいずれか1項に記載のコントローラ。
【請求項7】
前記要求生成部は、前記購入要求に前記コントローラの位置情報を含めて外部へ送信する、請求項1~6のいずれか1項に記載のコントローラ。
【請求項8】
認証済みIPアドレスを用いて、前記購入要求の送信先との間でデータ通信を行う通信部をさらに備える、請求項1~7のいずれか1項に記載のコントローラ。
【請求項9】
請求項1~8のいずれか1項に記載のコントローラと、
商品を販売するための販売要求を生成して外部へ送信する第2の要求生成部と、
互いの要求内容が合致する前記購入要求と前記販売要求との組を決定するマッチング処理部とを備える、商品取引システム。
【請求項10】
コンピュータで実行される自動注文プログラムであって、前記コンピュータに
商品を消費する対象から当該商品の消費状態に関する情報を取得するステップと、
前記取得した情報に基づいて予め定められた条件が満たされたか否かを判断するステップと、
前記予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求を生成して外部へ送信するステップとを実行させ、
前記購入要求は、購入を希望する商品を特定する情報を含む、自動注文プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、電子的な商品の取引を実現できるコントローラ、商品取引システムおよび自動注文プログラムに関する。
【背景技術】
【0002】
従来の流通システムにおいては、生産者から小売りを介して買い手の元へ商品が届けられる。このような流通システムに対して、例えば、特開2019-128814号公報(特許文献1)は、マーケットを活性化できる電子売買システムを開示する。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
上述の特許文献1に開示される電子売買システムは、購入者と販売者との間の商品売買を支援するものであるが、このような従来の電子売買システムは、購入者と販売者との間の遣り取りを電子的に行うに過ぎず、取引の開始自体は人間の判断によって決定される。
【0005】
本開示は、状況に応じて自動的な取引を可能とするプラットフォームを提供することを目的とする。
【課題を解決するための手段】
【0006】
本開示のある形態に従うコントローラは、商品を消費する対象から当該商品の消費状態に関する情報を取得する状態情報取得部と、取得した情報に基づいて予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求を生成して外部へ送信する要求生成部とを含む。購入要求は、購入を希望する商品を特定する情報を含む。
【0007】
要求生成部は、購入を希望する商品の数、および、商品を購入する際の希望価格の少なくとも一方を含んでいてもよい。
【0008】
要求生成部は、取得した情報に基づいて決定される配送期限を含んでいてもよい。
状態情報取得部は、商品の残量をセンシングするセンシング部を含んでいてもよい。
【0009】
状態情報取得部は、商品を消費する対象が管理している情報を取得するインターフェイスを含んでいてもよい。
【0010】
要求生成部は、購入要求に電子署名を付与して外部へ送信するようにしてもよい。
要求生成部は、購入要求にコントローラの位置情報を含めて外部へ送信するようにしてもよい。
【0011】
コントローラは、認証済みIPアドレスを用いて、購入要求の送信先との間でデータ通信を行う通信部をさらに含んでいてもよい。
【0012】
本開示の別の形態に従う商品取引システムは、上記のコントローラと、商品を販売するための販売要求を生成して外部へ送信する第2の要求生成部と、互いの要求内容が合致する前記購入要求と前記販売要求との組を決定するマッチング処理部とを含む。
【0013】
本開示のさらに別の形態に従うコンピュータで実行される自動注文プログラムは、コンピュータに、商品を消費する対象から当該商品の消費状態に関する情報を取得するステップと、取得した情報に基づいて予め定められた条件が満たされたか否かを判断するステップと、予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求を生成して外部へ送信するステップとを実行させる。購入要求は、購入を希望する商品を特定する情報を含む。
【発明の効果】
【0014】
本開示によれば、状況に応じて自動的な取引を可能とするプラットフォームを実現できる。
【図面の簡単な説明】
【0015】
【
図1】本実施の形態に従う商品取引システムにおける処理の概要を説明するための図である。
【
図2】本実施の形態に従う商品取引システムを構成する消費エンティティの構成例を示す模式図である。
【
図3】本実施の形態に従う商品取引システムを構成する供給者において用いられる供給者端末の構成例を示す模式図である。
【
図4】本実施の形態に従う商品取引システムを構成する運営サーバの構成例を示す模式図である。
【
図5】本実施の形態に従う商品取引システムの自動注文機能の処理手順を示すフローチャートである。
【
図6】本実施の形態に従う商品取引システムのコントローラによる状態値を取得するための構成例を示す模式図である。
【
図7】本実施の形態に従う商品取引システムのコントローラによる状態値を取得するための別の構成例を示す模式図である。
【
図8】本実施の形態に従う商品取引システムのコントローラが生成する購入要求の一例を示す模式図である。
【
図9】本実施の形態に従う商品取引システムの供給者端末が提供するユーザインターフェイス画面の一例を示す模式図である。
【
図10】本実施の形態に従う商品取引システムの運営サーバによるユーザ管理の一例を説明するための図である。
【
図11】本実施の形態に従う商品取引システムの運営サーバにおけるマッチング処理の処理手順を示すフローチャートである。
【
図12】本実施の形態に従う商品取引システムの運営サーバにおけるマッチング処理の処理手順を示すフローチャートである。
【
図13】本実施の形態に従う商品取引システムにおいて利用される配送費定義の一例を示す図である。
【
図14】本実施の形態に従う商品取引システムにおいて利用される配送費定義の別の一例を示す図である。
【
図15】本実施の形態に従う別の商品取引システムにおける処理の概要を説明するための図である。
【
図16】本実施の形態に従うさらに別の商品取引システムにおける処理の概要を説明するための図である。
【発明を実施するための形態】
【0016】
本開示に係る実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。
【0017】
<A.商品取引システム1>
まず、本実施の形態に従う商品取引システム1について説明する。商品取引システム1は、任意の消費エンティティからの商品の購入要求に応じた取引を可能にするプラットフォームを提供する。
【0018】
図1は、本実施の形態に従う商品取引システム1における処理の概要を説明するための図である。
図1を参照して、商品取引システム1は、1または複数の商品を消費する1または複数の消費エンティティ10と、当該1または複数の商品の少なくとも一部を提供する1または複数の供給者20と、1または複数の消費エンティティ10、ならびに、1または複数の供給者20のいずれからもアクセス可能な運営サーバ300とを含む。
【0019】
商品取引システム1において取り扱われる商品としては、特に制限はないが、日用品や消耗品などの繰り返しの購入が想定されているものが好適である。
【0020】
本明細書において、「消費エンティティ10」は、任意の商品を消費するエンティティ(主体)を包含するものであり、典型的には、当該商品を消費することが想定されている、個人などの自然人、店舗や事業所などの非自然人(団体や法人を含む)、コンピュータや演算機能を備えたデバイスなどを含む。「消費エンティティ10」は、商品の取引に関して何らかの意思決定が可能な任意のエンティティ(主体)を包含する概念である。
【0021】
本明細書において、「供給者20」は、任意の商品を提供するエンティティ(主体)を包含するものであり、典型的には、当該商品の生産者あるいは輸入者などが想定される。「供給者20」は、任意の商品を保管または管理する物流会社であってもよいし、コンピュータや演算機能を備えたデバイスであってもよい。「供給者20」は、「消費エンティティ10」と同様に、商品の取引に関して何らかの意思決定が可能な任意のエンティティ(主体)を包含する概念である。
【0022】
以下の説明においては、主として、消費エンティティ10がコンピュータや演算機能を備えたデバイスである例について説明する。
図1には、一例として、ユーザの操作などを介することなく、状況に応じて、洗濯機から洗剤や柔軟剤などが自動的に注文される構成を示す。
【0023】
消費エンティティ10の各々は、予め定められた条件(客観的および主観的の両方を含む)が満たされると、購入を希望する任意の商品および数を特定するための情報を含む購入要求12を運営サーバ300へ送信する。なお、購入要求12には、購入を希望する価格を含んでいてもよい。
【0024】
一方、供給者20の各々は、販売を希望する任意の商品および当該商品を提供可能な数を特定するための情報を含む販売要求22を運営サーバ300へ送信する。なお、販売要求22には、販売を希望する価格を含んでいてもよい。
【0025】
運営サーバ300は、1または複数の消費エンティティ10からの購入要求12と、1または複数の供給者20からの販売要求22とを比較して、購入要求12の要求内容と販売要求22の要求内容とが合致するか否かを判断する(以下、「マッチング処理」とも称す。)。すなわち、運営サーバ300は、互いの要求内容が合致する購入要求12と販売要求22との組を決定するマッチング処理機能を有している。そして、購入要求12と販売要求22とが合致すると、取引成立と決定する。
【0026】
運営サーバ300は、取引成立と決定された販売要求22に対応する供給者20に対して、取引成立の旨を通知するとともに、取引の対象になった商品を消費エンティティ10
へ配送する。なお、商品の配送については、供給者20自身が行ってもよいが、典型的には、任意の配送者30が行ってもよい。
【0027】
運営サーバ300は、後述するように、消費エンティティ10と供給者20との間の決済処理も担当する。
【0028】
以下、本実施の形態に従う商品取引システム1の構成、機能および処理の詳細について説明する。
【0029】
<B.ハードウェア構成>
次に、本実施の形態に従う商品取引システム1のハードウェア構成の一例について説明する。
【0030】
(b1:消費エンティティ10)
図2は、本実施の形態に従う商品取引システム1を構成する消費エンティティ10の構成例を示す模式図である。消費エンティティ10は、コンピュータの一種であるコントローラ100を主たる構成として実現されてもよい。
【0031】
図2を参照して、コントローラ100は、主たるコンポーネントとして、処理回路(processing circuitry)である制御部110を含む。制御部110は、本実施の形態に従う機能の提供および処理の実行を実現するための演算主体である。
【0032】
制御部110は、
図2に示すようなプロセッサおよびメモリを用いて、メモリに格納されたコンピュータ可読命令(computer readable instructions)をプロセッサが実行するように構成されてもよい。あるいは、コンピュータ可読命令に相当する回路が組み込まれたASIC(Application Specific Integrated Circuit)などのハードワイヤード回路
を用いて制御部110を実現してもよい。さらにあるいは、FPGA(Field-Programmable Gate Array)上にコンピュータ可読命令に相当する回路を実現することで制御部11
0を実現してもよい。また、プロセッサおよびメモリ、ASIC、FPGAなどを適宜組み合わせて制御部110を実現してもよい。
【0033】
図2に示すようなプロセッサおよびメモリを用いた構成において、制御部110は、プロセッサ102と、主メモリ104と、ストレージ106とを含む。
【0034】
プロセッサ102は、コンピュータ可読命令を順次読出して実行する演算回路である。プロセッサ102は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、GPU(Graphics Processing Unit)などで構成される。複数のプロセッサ102を用いて制御部110を実現してもよいし(マルチプロセッサの構成)、複数のコアを有するプロセッサを用いて制御部110を実現してもよい(マルチコアの構成)。
【0035】
主メモリ104は、DRAM(Dynamic Random Access Memory)やSRAM(Static Random Access Memory)などの揮発性記憶装置である。プロセッサ102は、ストレージ
106に格納された各種プログラムのうち、指定されたプログラムを主メモリ104上に展開し、主メモリ104と協働することで、本実施の形態に従う各種処理を実現する。
【0036】
ストレージ106は、例えば、HDD(Hard Disk Drive)、SSD(Solid State Drive)、フラッシュメモリなどの不揮発性記憶装置である。ストレージ106には、プロセッサ102で実行される各種プログラムや各種データが格納されている。典型的には、ストレージ106は、後述するような自動注文機能を実現するための自動注文プログラム1
08を格納している。
【0037】
図2に示すようなプロセッサ102がメモリに格納されたコンピュータ可読命令を実行する構成において、メモリはストレージ106に相当する。
【0038】
コントローラ100は、さらに、GPS(Global Positioning System)112と、ネ
ットワークインターフェイス120と、内部インターフェイス130と、センシング部140と、出力部150とを含む。
【0039】
GPS112は、コントローラ100の位置情報を取得する。なお、GPS112としては、任意のGNSS(Global Navigation Satellite System)を採用できる。
【0040】
ネットワークインターフェイス120は、ネットワークを介して運営サーバ300との間でデータ通信を行う。ネットワークインターフェイス120は、有線および無線のいずれで構成してもよい。ネットワークインターフェイス120を有線で構成する場合には、例えば、イーサネット(登録商標)ポート、USB(Universal Serial Bus)ポート、IEEE1394などのシリアルポート、レガシーなパラレルポートといった有線接続端子を含んでいてもよい。また、ネットワークインターフェイス120を無線で構成する場合には、デバイス、ルータ、移動体基地局などと無線通信するための処理回路およびアンテナなどを含んでもよい。ネットワークインターフェイス120が対応する無線通信は、例えば、Wi-Fi(登録商標)、Bluetooth(登録商標)、ZigBee(登録商標)、LPWA(Low Power Wide Area)、GSM(登録商標)、W-CDMA、CD
MA2000、LTE(Long Term Evolution)、第5世代移動通信システム(5G)の
いずれであってもよい。
【0041】
内部インターフェイス130およびセンシング部140は、商品を消費する対象(この場合には、機器50)から当該商品の消費状態に関する情報を取得する状態情報取得部に相当する。ここで、「商品の消費状態に関する情報」は、対象の商品の注文要否を判断するために必要な情報を包含する概念である。典型的には、「商品の消費状態に関する情報」は、対象に残っている商品の数もしくは量、対象における商品の消費総量もしくは消費速度、対象における商品の追加もしくは消費に係る履歴、対象における商品の追加もしくは消費に係る時間的変化といった、商品の消費に係る任意の情報を含む。
【0042】
内部インターフェイス130は、例えば、洗濯機などの機器50との間でデータ通信を行う。内部インターフェイス130は、機器50に実装されている制御ロジックから必要な状態値を取得することができる。典型的には、内部インターフェイス130は、商品を消費する対象が管理している情報(例えば、在庫情報や動作の履歴情報など)を取得する。
【0043】
センシング部140は、洗濯機などの機器50あるいは機器50に関連する部分から必要な情報をセンシングする。センシング部140としては、任意のセンサを用いることができる。典型的には、センシング部140は、商品の残量をセンシングするように構成されてもよい。
【0044】
出力部150は、制御部110での処理結果などを外部へ提示するためのコンポーネントである。出力部150は、例えば、LCD(Liquid Crystal Display)や有機EL(Electro-Luminescence)ディスプレイなどであってもよい。また、出力部150は、任意のインジケータやスピーカなどであってもよい。
【0045】
コントローラ100は、セキュアストレージ152をさらに含んでいてもよい。セキュ
アストレージ152は、セキュアな処理を実現するために必要な情報を保持する記憶部である。セキュアストレージ152は、ストレージ106と同様に、ハードディスク、SSD、フラッシュメモリなどの不揮発性記憶装置で構成してもよい。この場合には、公知のアクセス制限機能を付加することで、格納されているデータの改変などを防止するようにしてもよい。また、TPM(Trusted Platform Module)などのセキュリティチップを用
いて構成してもよい。さらに、RFID(Radio Frequency IDentifier)タグなどを用いて、必要な情報を保持するようにしてもよい。
【0046】
セキュアストレージ152には、例えば、電子証明書154と、秘密鍵および公開鍵からなる鍵ペア156と、識別情報158とが格納される。電子証明書154は、任意の発行者(典型的には、認証局)により発行される。鍵ペア156は、情報の改ざんやなりすましなどを防止するために、コントローラ100から出力される情報に電子署名を付加する処理などに利用される。識別情報158は、コントローラ100を一意に特定するための情報(例えば、シリアル番号や製造番号など)を含む。
【0047】
例えば、コントローラ100は、運営サーバ300へ送信する購入要求12に、自身の秘密鍵を用いて生成した電子署名を付加することで、運営サーバ300および供給者端末200は、正規の購入要求12であることを認証できる。このように、コントローラ100は、生成した購入要求12に電子署名を付与して外部へ送信するようにしてもよい。
【0048】
さらに、購入要求12に、コントローラの識別情報158を含めたデータセットに対して、コントローラ100の秘密鍵を用いて生成した電子署名を付加することで、購入要求12の要求元の正当性をより確実に認証することもできる。
【0049】
(b2:供給者20)
図3は、本実施の形態に従う商品取引システム1を構成する供給者20において用いられる供給者端末200の構成例を示す模式図である。典型的には、供給者端末200は、汎用コンピュータを用いて実現される。
【0050】
図3を参照して、供給者端末200は、主たるコンポーネントとして、1または複数のプロセッサ201と、メインメモリ202と、ネットワークインターフェイス203と、入力部204と、ディスプレイ205と、ストレージ210とを含む。これらのコンポーネントは、内部バス206を介して接続されている。
【0051】
プロセッサ201は、例えば、CPUやGPUなどで構成される。複数のプロセッサ201が配置されてもよいし、複数のコアを有するプロセッサ201を採用してもよい。
【0052】
メインメモリ202は、DRAMやSRAMなどの揮発性記憶装置で構成される。ストレージ210は、ハードディスクやSSDなどの不揮発性記憶装置で構成され、プロセッサ201で実行される各種プログラムや各種データを保持する。ストレージ210に格納されたプログラムのうち、指定されたプログラムコードがメインメモリ202上に展開され、プロセッサ201は、メインメモリ202上に展開されたプログラムコードに含まれるコンピュータ可読命令を順次実行することで、後述するような各種機能を実現する。
【0053】
典型的には、ストレージ210は、供給可能な商品の在庫を管理するための在庫管理プログラム212と、在庫管理の対象となる各商品の状態を示す在庫情報218とを格納している。
【0054】
ネットワークインターフェイス203は、ネットワークを介して運営サーバ300との間でデータ通信を行う。ネットワークインターフェイス203は、例えば、インターネッ
トを介した通信ができるように、イーサネット(登録商標)ポートを含んでいてもよい。
【0055】
入力部204は、任意の入力指示を受け付ける。ディスプレイ205は、プロセッサ201での処理結果などを表示する。
【0056】
供給者端末200の全部または一部は、コンピュータ可読命令に相当する回路が組み込まれたASICなどのハードワイヤード回路を用いて実現してもよい。さらにあるいは、FPGA上にコンピュータ可読命令に相当する回路を用いて実現してもよい。また、プロセッサ201およびメインメモリ、ASIC、FPGAなどを適宜組み合わせて実現してもよい。
【0057】
供給者端末200は、コンピュータ可読命令からなる在庫管理プログラム212を格納する非一過性(non-transitory)のメディアから、当該格納しているプログラムなどを読み出すためのコンポーネントをさらに有していてもよい。メディアは、例えば、DVD(Digital Versatile Disc)などの光学メディア、USBメモリなどの半導体メディアなどであってもよい。在庫管理プログラム212は、メディアを介して供給者端末200にインストールされるだけではなく、ネットワーク上の配信サーバから提供されるようにしてもよい。
【0058】
(b3:運営サーバ300)
図4は、本実施の形態に従う商品取引システム1を構成する運営サーバ300の構成例を示す模式図である。典型的には、運営サーバ300は、1または複数の汎用コンピュータを用いて実現される。
【0059】
図4を参照して、運営サーバ300は、主たるコンポーネントとして、1または複数のプロセッサ301と、メインメモリ302と、ネットワークインターフェイス303と、入力部304と、ディスプレイ305と、ストレージ310とを含む。これらのコンポーネントは、内部バス306を介して接続されている。
【0060】
プロセッサ301は、例えば、CPUやGPU(Graphics Processing Unit)などで構成される。複数のプロセッサ301が配置されてもよいし、複数のコアを有するプロセッサ301を採用してもよい。
【0061】
メインメモリ302は、DRAM(Dynamic Random Access Memory)やSRAM(Static Random Access Memory)などの揮発性記憶装置で構成される。ストレージ310は、
ハードディスクやSSD(Solid State Drive)などの不揮発性記憶装置で構成され、プ
ロセッサ301で実行される各種プログラムや各種データを保持する。ストレージ310に格納されたプログラムのうち、指定されたプログラムコードがメインメモリ302上に展開され、プロセッサ301は、メインメモリ302上に展開されたプログラムコードに含まれるコンピュータ可読命令を順次実行することで、後述するような各種機能を実現する。
【0062】
典型的には、ストレージ310は、マッチング処理を実現するためのマッチングプログラム312と、決済処理を実現するための決済プログラム314と、要求キュー316と、消費エンティティ10および供給者20に関する各種情報を含むユーザ情報318とを格納している。要求キュー316は、1または複数の消費エンティティ10からの1または複数の購入要求12、および、1または複数の供給者20からの1または複数の販売要求22を一時的に保持する。
【0063】
マッチングプログラム312および決済プログラム314は、コンピュータに消費エン
ティティ10と供給者20との間の商品取引を実行させるための商品取引プログラムに相当する。
【0064】
ネットワークインターフェイス303は、消費エンティティ10および供給者20の端末などとデータ交換を担当する。ネットワークインターフェイス303は、例えば、インターネットを介した通信ができるように、イーサネット(登録商標)ポートを含んでいてもよい。
【0065】
入力部304は、任意の入力指示を受け付ける。ディスプレイ305は、プロセッサ301での処理結果などを表示する。
【0066】
運営サーバ300の全部または一部は、コンピュータ可読命令に相当する回路が組み込まれたASICなどのハードワイヤード回路を用いて実現してもよい。さらにあるいは、FPGA上にコンピュータ可読命令に相当する回路を用いて実現してもよい。また、プロセッサ301およびメインメモリ、ASIC、FPGAなどを適宜組み合わせて実現してもよい。
【0067】
運営サーバ300は、コンピュータ可読命令からなるマッチングプログラム312および決済プログラム314を格納する非一過性のメディアから、当該格納しているプログラムなどを読み出すためのコンポーネントをさらに有していてもよい。メディアは、例えば、DVDなどの光学メディア、USBメモリなどの半導体メディアなどであってもよい。
【0068】
マッチングプログラム312および決済プログラム314は、メディアを介して運営サーバ300にインストールされるだけではなく、ネットワーク上の配信サーバから提供されるようにしてもよい。
【0069】
<C.消費エンティティ10およびコントローラ100>
本実施の形態に従う商品取引システム1において、消費エンティティ10は、必要に応じて、必要な商品を自動的に注文することができる機能(以下、「自動注文機能」とも称す。)を有している。
【0070】
消費エンティティ10は、洗濯機などの機器50の状態を監視し、機器50の状態が予め定められた条件を満たすと、当該条件に応じた商品を自動的に注文する(すなわち、購入要求12を生成および送信する)。
【0071】
以下の説明においては、機器50の典型例として洗濯機を示すが、これに限らず、任意の装置を対象とすることができる。家電製品としては、例えば、複写機・複合機・プリンタ(商品:トナー、インク、紙など)、掃除機(商品:紙パック)、洗浄機能付シェーバー(商品:洗浄液)、コーヒーメーカ(商品:コーヒー)、冷蔵庫(商品:飲料、食料など)、エアコン(商品:フィルタ)、照明器具(商品:蛍光灯、LED電球など)などが挙げられる。
【0072】
(c1:処理手順)
まず、本実施の形態に従う商品取引システム1の自動注文機能の処理手順について説明する。
【0073】
図5は、本実施の形態に従う商品取引システム1の自動注文機能の処理手順を示すフローチャートである。
図5に示す各ステップは、コントローラ100のプロセッサ102が自動注文プログラム108を実行することで実現される。
【0074】
図5を参照して、コントローラ100は、対象の機器50の状態値を取得する(ステップS100)。すなわち、コントローラ100は、商品を消費する対象から当該商品の消費状態に関する情報を取得する。機器50が洗濯機であれば、機器50の状態値としては、例えば、洗剤、柔軟剤、漂白剤の残量といった値が想定される。
【0075】
コントローラ100は、取得した機器50の状態値が予め定められた条件を満たすか否かを判断する(ステップS102)。すなわち、コントローラ100は、取得した情報に基づいて予め定められた条件が満たされたか否かを判断する。
【0076】
取得した機器50の状態値が予め定められた条件を満たさなければ(ステップS102においてNO)、以後の処理はスキップされる。
【0077】
取得した機器50の状態値が予め定められた条件を満たしていれば(ステップS102においてYES)、コントローラ100は、取得した機器50の状態値に応じて、購入要求12を生成し(ステップS104)、生成した購入要求12を運営サーバ300へ送信する(ステップS106)。すなわち、コントローラ100は、予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求12を生成して外部へ送信する。そして、処理は終了する。
【0078】
このように、本実施の形態に従う商品取引システム1の自動注文機能においては、任意の対象の状態に応じて、自動的に必要な商品を購入するための購入要求12を生成および送信できる。すなわち、コントローラ100は、取得した情報(対象の機器50の状態値)に基づいて予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求12を生成して外部(運営サーバ300)へ送信する要求生成機能を有している。
【0079】
(c2:状態値の取得)
次に、状態値を取得する方法の一例について説明する。
【0080】
図6は、本実施の形態に従う商品取引システム1のコントローラ100による状態値を取得するための構成例を示す模式図である。
図6には、洗濯機に装着される洗剤トレイ52を示す。洗剤トレイ52の内部には洗剤54が装填されており、洗濯機で洗濯が実行されるたびに、必要な量が洗濯槽に供給される。
【0081】
コントローラ100のセンシング部140は、洗剤トレイ52に関連付けて配置されており、洗剤トレイ52内の洗剤54の量に応じて、センシング部140の回転角度が変化するようになっている。センシング部140は、回転角度に応じて、洗剤トレイ52内の洗剤54の残量を示す信号を出力する。この出力される信号に基づいて、洗剤トレイ52内の洗剤54の残量が算出される。コントローラ100は、算出された洗剤54の残量に基づいて、予め定められた条件が満たされるか否かを判断する。
【0082】
図7は、本実施の形態に従う商品取引システム1のコントローラ100による状態値を取得するための別の構成例を示す模式図である。
図7には、コントローラ100の内部インターフェイス130が機器50と接続されている例を示す。
【0083】
図7(A)には、洗濯機である機器50が保持している履歴情報56の一例を示す。コントローラ100は、内部インターフェイス130を介して、機器50が保持している履歴情報56などにアクセスし、機器50における洗濯の実行履歴を取得する。そして、コントローラ100は、取得した洗濯の実行履歴に基づいて、洗剤の消費量および残量などを算出する。
【0084】
図7(B)には、コントローラ100により算出される洗剤の残量の推定結果160の一例を示す。コントローラ100は、
図7(B)に示すような推定結果160に基づいて、予め定められた条件が満たされるか否かを判断する。例えば、推定結果160に対して、所定のしきい値162を設定しておき、そのしきい値162を下回ったとき、あるいは、そのしきい値162を下回る時期を予測して、購入要求12を生成するようにしてもよい。
【0085】
なお、状態値を取得する方法は、
図6および
図7に示す構成に限られず、対象の機器50および対象の商品に応じた任意の取得方法を採用できる。さらに、状態値を取得する処理および構成の一部または全部をユーザが担当するようにしてもよい。例えば、ユーザが残量を目視し、その目視によって得られた残量をコントローラ100に入力するような形態を採用してもよい。
【0086】
(c3:条件および購入要求)
次に、自動注文機能に係る条件および生成される購入要求12の一例について説明する。
【0087】
図6および
図7に示すように、コントローラ100は、対象の機器50における洗剤54の残量などを取得できるので、例えば、購入要求12を生成するための条件としては、取得された洗剤54の残量が所定の下限以下になっている、などと設定できる。このような条件が満たされると、コントローラ100は、購入要求12を生成する。
【0088】
図8は、本実施の形態に従う商品取引システム1のコントローラ100が生成する購入要求12の一例を示す模式図である。
【0089】
図8(A)を参照して、コントローラ100(消費エンティティ10)が生成する購入要求12は、商品情報121と、個数情報122と、希望価格123とを含む。
【0090】
商品情報121には、購入対象の商品を特定するための特定情報(後述するような、商品コード)が格納される。
【0091】
個数情報122は、オプショナルな情報であり、購入対象の商品の個数を特定するための情報が任意に設定される。例えば、商品の購入数が常に1個であれば、個数情報122を省略してもよい。
【0092】
希望価格123は、オプショナルな情報であり、商品の特性や市場の特性などに応じて任意に設定される。例えば、希望価格123には、具体的な購入希望価格に代えて、「最安値」などと設定することもできる。この場合には、後述する運営サーバ300において最安値を提示する供給者20との間で、取引が成立することになる。
【0093】
このように、購入要求12は、購入を希望する商品を特定する情報の一例である商品情報121を含む。また、購入要求12は、購入を希望する商品の数(個数情報122)、および、商品を購入する際の希望価格(希望価格123)の少なくとも一方を含んでいてもよい。
【0094】
さらに、上述の
図7(B)に示すような洗剤の残量の推定結果160を利用できる場合には、どのタイミングで洗剤が消費尽くされるかを予測することができる。このような場合には、購入対象の商品が対象の機器50まで配送される期限を概ね決定できる。
【0095】
そこで、
図8(B)に示すように、コントローラ100(消費エンティティ10)が生成する購入要求12には、配送期限124をさらに含めるようにしてもよい。運営サーバ300は、購入要求12に配送期限124が含まれている場合には、指定されている配送期限124に間に合うように、供給者20とのマッチング処理を実行する。
【0096】
このように、購入要求12は、取得した情報に基づいて決定される配送期限(配送期限124)を含んでいてもよい。
【0097】
図8には、購入要求12の一例を示すが、これに限られず任意のデータ構造を採用してもよい。
【0098】
また、
図8に示す購入要求12に、送信元の消費エンティティ10(コントローラ100)を特定するための情報を含めるようにしてもよい。一方で、コントローラ100と運営サーバ300との間において、セキュアなデータ交換が実行される場合には、そのデータ交換の手続きにおいて、コントローラ100を一意に特定するための情報を事前に運営サーバ300へ提供してもよい。このような方法を採用することで、購入要求12に秘匿することが好ましい情報を含める必要がなくなり、セキュリティ上のリスクを低減できる。
【0099】
<D.供給者20および供給者端末200>
次に、本実施の形態に従う商品取引システム1の供給者20(供給者端末200)における処理の一例について説明する。
【0100】
供給者20は、供給者端末200を操作して、消費エンティティ10に提供できる商品の在庫管理を行うととともに、販売要求22を生成して、運営サーバ300へ送信する。すなわち、供給者端末200は、商品を販売するための販売要求22を生成して外部(運営サーバ300)へ送信する要求生成機能を有している。
【0101】
図9は、本実施の形態に従う商品取引システム1の供給者端末200が提供するユーザインターフェイス画面の一例を示す模式図である。
図9を参照して、ユーザインターフェイス画面250は、販売要求22を生成するための供給者20からの指示を受け付ける。
【0102】
より具体的には、ユーザインターフェイス画面250は、供給者20が販売可能な商品の一覧を示すリスト252を含む。リスト252は、供給者20が販売可能な各商品を特定するための商品コードを示す商品コード欄254と、各商品の商品名を示す商品名欄256と、各商品の販売希望価格を示す販売価格欄258と、各商品の販売希望個数を示す販売個数欄260と、各商品の販売希望個数のうち取引が未だ成立していない個数を示す残り個数欄262と、購入希望販売の一部の個数についてのみ要求内容が合致した場合に、当該要求内容が合致した個数についてのみ取引成立として処理するか否かを設定する一部取引欄264とを含む。
【0103】
供給者20は、販売可能な商品をリスト252に登録するとともに、各商品について、販売希望価格(販売価格欄258)および販売希望価格(販売個数欄260)を入力する。
【0104】
供給者20は、検索ボタン266を選択して、商品名または商品を特定するコードなどを入力することで、販売可能な商品を検索してリスト2502に登録できる。あるいは、供給者20は、コード読取ボタン268を選択して、端末に実装されているカメラなどで購入を希望する商品に付されているバーコードやQRコード(登録商標)を読み取ることで、販売可能な商品をリスト252に登録できる。
【0105】
供給者20は、内容変更ボタン270を選択して、リスト252に登録されている販売希望価格(販売価格欄258)および販売希望価格(販売個数欄260)を任意に変更できる。供給者20が変更した内容は、更新ボタン272が選択されることで反映される。
【0106】
図6に示すようなユーザインターフェイス画面250を介して、供給者端末200が販売要求22を生成し、運営サーバ300へ送信する。
【0107】
なお、商品取引システム1において取り扱われる商品は、パッケージなどに付される識別情報を用いて特定されてもよい。このような識別情報としては、例えば、JAN(Japanese Article Number)コード、EAN(European Article Number)コード、GTIN-13、GTIN-8などの商品識別番号を用いてもよい。このような商品識別番号を用いることで、複数の国の間で流通する商品についても取り扱いを容易化できる。
【0108】
さらに、集合包装用の識別情報を用いるようにしてもよい。集合包装用の識別情報は、企業間の取引単位である集合包装(ケース、ボール、パレットなど)に対し設定される商品識別番号を包含する。このような集合包装用の識別情報としては、GTIN-14などの集合包装用商品コードが知られている。集合包装用商品コードは、集合包装された個々の商品についての商品識別番号を含むので、商品取引システム1においては、個々の商品を取り扱うこともできるとともに、それらを集合させた状態で取り扱うこともできる。
【0109】
なお、集合包装用商品コードは、ITF(Inter-Leaved two of Five)シンボルなどのバーコードシンボルとして具現化できる。
【0110】
上述したような個別の商品を示す識別情報および集合包装用の識別情報を併用することで、商品の特性や供給者20の事情に応じたより柔軟な取引を実現できる。
【0111】
<E.運営サーバ300>
次に、本実施の形態に従う商品取引システム1の運営サーバ300における処理の一例について説明する。
【0112】
(e1:ユーザ管理)
商品取引システム1の運営サーバ300は、マッチング処理に必要なユーザ情報を管理する。
【0113】
図10は、本実施の形態に従う商品取引システム1の運営サーバ300によるユーザ管理の一例を説明するための図である。
図10(A)には、消費エンティティ10の各々を管理するための管理情報350の一例を示し、
図10(B)には、供給者20の各々を管理するための管理情報360の一例を示す。
【0114】
図10(A)を参照して、消費エンティティ10の各々を管理するための管理情報350は、消費エンティティ10の配送先(住所あるいは緯度経度)を示す配送先情報352を含む。管理情報350に含まれる配送先情報352は、消費エンティティ10から受信した購入要求12の配送先情報として利用されてもよい。但し、消費エンティティ10のコントローラ100にGPS112が実装される場合には、GPS112からのコントローラ100の位置情報を購入要求12に含めるようにすれば、配送先情報352を省略してもよい。
【0115】
管理情報350は、消費エンティティ10の口座の残高を示す残高情報354を含む。残高情報354は、消費エンティティ10および供給者20の各々が保有する経済的価値
を管理する口座を具現化したものである。経済的価値としては、特定の通貨での金額が想定されているが、仮想通貨のようなものであってもよいし、商品取引システム1において利用される独自ポイントであってもよい。
【0116】
運営サーバ300は、消費エンティティ10が購入要求12を生成すると、対応する残高情報354から、購入要求12に基づいて決定される購入予定額をリザーブ(予約)する。すなわち、運営サーバ300は、購入要求12に応じて決定される価値を対応する消費エンティティ10の口座から予約する。
【0117】
管理情報350は、消費エンティティ10の取引情報を示す購入履歴356を含む。運営サーバ300は、取引が成立するたびに購入履歴356の内容を更新する。なお、運営サーバ300は、取引が成立する場合に加えて、消費エンティティ10が購入要求12を生成するたびに、その内容を残高情報354に反映するようにしてもよい。
【0118】
図10(B)を参照して、供給者20の各々を管理するための管理情報360は、供給者20の口座の残高を示す残高情報364を含む。運営サーバ300は、いずれかの消費エンティティ10と供給者20との間で取引が成立すると、当該取引によって遣り取りされる金額が対応する残高情報364に加算される。
【0119】
管理情報360は、供給者20の取引情報を示す販売履歴366を含む。運営サーバ300は、取引が成立するたびに販売履歴366の内容を更新する。
【0120】
上述したように、運営サーバ300は、
図10に示される管理情報350および管理情報360を用いて、消費エンティティ10と供給者20との間の取引に関する情報を管理する。
【0121】
(e2:マッチング処理)
次に、商品取引システム1の運営サーバ300におけるマッチング処理の一例について説明する。
図11および
図12は、本実施の形態に従う商品取引システム1の運営サーバ300におけるマッチング処理の処理手順を示すフローチャートである。
図11および
図12には、消費エンティティ10と供給者20との間の商品取引をコンピュータが実行する商品取引方法が示される。
【0122】
図11および
図12に示す各ステップは、典型的には、運営サーバ300のプロセッサ301がマッチングプログラム312および決済プログラム314(商品取引プログラムに相当)を実行することで実現される。
【0123】
図11および
図12を参照して、運営サーバ300は、消費エンティティ10のコントローラ100からの購入要求12または供給者20の供給者端末200からの販売要求22を受信したか否かを判断する(ステップS300)。コントローラ100からの購入要求12または供給者端末200からの販売要求22を受信していれば(ステップS300においてYES)、運営サーバ300は、受信した購入要求12または販売要求22を要求キュー316に格納する(ステップS302)。
【0124】
続いて、運営サーバ300は、受信した要求が購入要求12であるか否かを判断する(ステップS304)。受信した要求が購入要求12であれば(ステップS304においてYES)、運営サーバ300は、当該受信した購入要求12の内容に基づいて決定される購入予定額が、購入要求12を送信した消費エンティティ10の口座に存在するか否かを判断する(ステップS306)。
【0125】
購入予定額が消費エンティティ10の口座に存在していれば(ステップS306においてYES)、運営サーバ300は、消費エンティティ10の口座から購入予定額をリザーブ(予約)する(ステップS308)。そして、ステップS310以下のマッチング処理が実行される。
【0126】
購入予定額が消費エンティティ10の口座に存在していなければ(ステップS306においてNO)、運営サーバ300は、ステップS310以下のマッチング処理を実行しない。この際、運営サーバ300は、購入要求12を生成できない旨を消費エンティティ10のコントローラ100に通知してもよい。
【0127】
受信した要求が販売要求22であれば(ステップS304においてNO)、ステップS306およびS108の処理はスキップされる。
【0128】
消費エンティティ10のコントローラ100からの購入要求12または供給者20の供給者端末200からの販売要求22を受信していなければ(ステップS300においてNO)、運営サーバ300は、消費エンティティ10のコントローラ100から購入要求12の変更または供給者20の供給者端末200から販売要求22の変更を受信したか否かを判断する(ステップS309)。消費エンティティ10のコントローラ100から購入要求12の変更または供給者20の供給者端末200から販売要求22の変更を受信していれば(ステップS300においてYES)、ステップS310以下のマッチング処理が実行される。
【0129】
消費エンティティ10のコントローラ100から購入要求12の変更および供給者20の供給者端末200から販売要求22の変更のいずれも受信していなければ(ステップS300においてNO)、ステップS300以下の処理が繰り返される。
【0130】
消費エンティティ10のコントローラ100から購入要求12の変更および供給者20の供給者端末200から販売要求22の変更を受信していなければ(ステップS300においてNO)、ステップS300以下の処理が繰り返される。
【0131】
運営サーバ300は、新たに受信または更新された要求が購入要求12および販売要求22のいずれであるかを判断する(ステップS310)。
【0132】
新たに受信または更新された要求が購入要求12であれば(ステップS310において「購入要求」)、運営サーバ300は、当該新たに受信または更新された購入要求12をマッチング対象の購入要求12に設定し(ステップS312)、要求キュー316に格納されている販売要求22のうち1つをマッチング候補として選択する(ステップS314)。そして、運営サーバ300は、マッチング対象の購入要求12とマッチング候補の販売要求22とを比較して、互いの要求内容が合致するか否かを判断する(ステップS316)。
【0133】
マッチング対象の購入要求12とマッチング候補の販売要求22との間で、互いの要求内容が合致すれば(ステップS316においてYES)、運営サーバ300は、取引成立と決定し、対象の購入要求12および販売要求22にそれぞれ対応する消費エンティティ10および供給者20に通知し(ステップS318)、対象の購入要求12および販売要求22を、対象の商品の配送完了待ちのステータスに変更する(ステップS320)。そして、マッチング処理は終了する。
【0134】
マッチング対象の購入要求12とマッチング候補の販売要求22との間で、互いの要求内容が合致しなければ(ステップS316においてNO)、運営サーバ300は、要求キ
ュー316に格納されているすべての販売要求22についてマッチング処理が完了したか否かを判断する(ステップS322)。要求キュー316に格納されている販売要求22のうちマッチング処理が行われていないものがあれば(ステップS322においてNO)、運営サーバ300は、未だマッチング処理が行われていない1つの販売要求22をマッチング候補として選択し(ステップS324)、ステップS316以下の処理を繰り返す。
【0135】
一方、要求キュー316に格納されているすべての販売要求22についてマッチング処理が完了していれば(ステップS322においてYES)、運営サーバ300は、互いの要求内容が合致する購入要求12と販売要求22とが見つからなかった判断し、マッチング処理を終了する。
【0136】
新たに受信または更新された要求が販売要求22であれば(ステップS310において「販売要求」)、運営サーバ300は、当該新たに受信または更新された販売要求22をマッチング対象の販売要求22に設定し(ステップS332)、要求キュー316に格納されている購入要求12のうち1つをマッチング候補として選択する(ステップS334)。そして、運営サーバ300は、マッチング対象の販売要求22とマッチング候補の購入要求12とを比較して、互いの要求内容が合致するか否かを判断する(ステップS336)。
【0137】
マッチング対象の販売要求22とマッチング候補の購入要求12との間で、互いの要求内容が合致すれば(ステップS336においてYES)、運営サーバ300は、取引成立と決定し、対象の販売要求22および購入要求12にそれぞれ対応する供給者20および消費エンティティ10に通知し(ステップS338)、対象の販売要求22および購入要求12を、対象の商品の配送完了待ちのステータスに変更する(ステップS340)。そして、マッチング処理は終了する。
【0138】
マッチング対象の販売要求22とマッチング候補の購入要求12との間で、互いの要求内容が合致しなければ(ステップS336においてNO)、運営サーバ300は、要求キュー316に格納されているすべての購入要求12についてマッチング処理が完了したか否かを判断する(ステップS342)。要求キュー316に格納されている購入要求12のうちマッチング処理が行われていないものがあれば(ステップS342においてNO)、運営サーバ300は、未だマッチング処理が行われていない1つの購入要求12をマッチング候補として選択し(ステップS344)、ステップS336以下の処理を繰り返す。
【0139】
一方、要求キュー316に格納されているすべての購入要求12についてマッチング処理が完了していれば(ステップS342においてYES)、運営サーバ300は、互いの要求内容が合致する販売要求22と購入要求12とが見つからなかった判断し、マッチング処理を終了する。
【0140】
<F.変形例>
上述の説明においては、本実施の形態に従う商品取引システム1の典型例について説明したが、以下のような各種の変形例の適用が可能である。なお、以下に説明する変形例は、任意に組み合わせて適宜適用できる。
【0141】
(f1:EVER/IP(登録商標))
本実施の形態に従う商品取引システム1を構成する各デバイスの通信プロトコルとして、コネクトフリー株式会社が提供するEVER/IP(登録商標)を採用してもよい。EVER/IPを採用した場合において、コントローラ100、供給者端末200および運
営サーバ300の各デバイスは、認証済みIPアドレスを有することになる。すなわち、コントローラ100、供給者端末200および運営サーバ300の各デバイスは、認証済みIPアドレスを用いて、送信先との間でデータ通信を行うネットワークインターフェイス(通信部)を有することになる。
【0142】
ここで、「認証済みIPアドレス」は、通信先あるいは第三者に対して、各デバイスが保持しているIPアドレスの正当性が保証されている状態を意味する。EVER/IPにおいては、「認証済みIPアドレス」は、不可逆な暗号学的ハッシュ関数によって生成されるとともに、認証局によって直接的または間接的に認証されたIPアドレスであることを意味する。このような認証済みIPアドレスを用いることで、各デバイスがデータ通信に利用するIPアドレスが偽装されていないことを保証できる。
【0143】
より具体的には、認証済みIPアドレスは、各デバイスが保持する秘密鍵および公開鍵からなる鍵ペアと、予め定められたハッシュ関数とを用いて生成される。予め定められたハッシュ関数に公開鍵を入力することでハッシュ値を算出し、その算出されたハッシュ値の全部または一部が各デバイスの認証済みIPアドレスとなる。デバイス間で予め定められたハッシュ関数を共有しておくことで、他のデバイスから取得した公開鍵に基づいて、当該公開鍵の送信元であるデバイスのIPアドレスを決定できるとともに、その正当性を認証できる。
【0144】
例えば、コントローラ100は、生成した購入要求12の送信先である運営サーバ300との間で認証済みIPアドレスを用いてデータ通信を行う。また、供給者端末200は、生成した販売要求22の送信先である運営サーバ300との間で認証済みIPアドレスを用いてデータ通信を行う。認証済みIPアドレスを用いることで、購入要求12および販売要求22を送信したデバイス自体を認証でき、なりすましなどによる不正な売買を防止できる。
【0145】
(f2:マッチング処理の簡素化)
上述の説明においては、同一の商品が複数の供給者20から提供される場合を想定したマッチング処理を例示したが、特定の商品を提供する供給者20が一つであった場合には、マッチング処理を簡素化してもよい。
【0146】
この場合には、運営サーバ300が消費エンティティ10(コントローラ100)からの購入要求12を受信すると、受信した購入要求12の内容に従って、取引を成立させるようにしてもよい。
【0147】
この場合、消費エンティティ10と供給者20との間で予め取り決めた価格を採用してもよい。
【0148】
(f3:配送費)
購入要求12と販売要求22とのマッチング処理においては、配送費を考慮するようにしてもよい。すなわち、運営サーバ300は、供給者20から消費エンティティ10までの特定の商品を配送するための配送費を反映した上で、購入要求12と販売要求22とがマッチングするか否かを判断する。この配送費の考慮にあたっては、消費エンティティ10と供給者20との間の距離を考慮してもよい。以下、配送費の算出方法の一例について説明する。
【0149】
図13は、本実施の形態に従う商品取引システム1において利用される配送費定義326の一例を示す図である。
図13に示す配送費定義326は、商品ごと(
図13の例では「商品A」)に配送費を定義する。配送費定義326においては、消費エンティティ10
と供給者20との間の距離を区分(区分1~5)して、区分ごとに配送費が定義される。購入要求12または販売要求22において配送費の算出が必要な場合には、消費エンティティ10の配送先情報352および配送費定義326を参照して、配送費が決定される。
【0150】
図13に示される配送費定義326は、販売要求22の配送費定義として利用されてもよい。
【0151】
図14は、本実施の形態に従う商品取引システム1において利用される配送費定義327の別の一例を示す図である。
図14に示す配送費定義327は、基本的にはすべての商品に対して配送費を定義する。配送費定義327においては、消費エンティティ10と供給者20との間の距離を区分(区分1~5)して、区分ごとに配送費が定義される。
【0152】
いずれかの商品について配送費の算出が必要な場合には、商品ごとの重量を示す重量テーブル328を参照して、各商品についての重量が決定され、当該決定された重量を配送費定義327に適用することで、配送費が決定される。
【0153】
なお、
図13および
図14には、消費エンティティ10と供給者20との間の距離を区分して、各区分について配送費が定義されている例を示したが、これに限らず、単位距離(例えば、1km)あたりに配送費を定義するようにしてもよい。さらに、国内用および海外用の配送費定義をそれぞれ規定してもよい。
【0154】
以上のように、本実施の形態に従う商品取引システム1においては、上述したような配送費定義を利用することで、必要な配送費を算出できる。このように算出される配送費を考慮して、マッチング処理を行うようにしてもよい。
【0155】
(f4:利用料)
本実施の形態に従う商品取引システム1を利用する費用については、消費エンティティ10および供給者20のいずれが負担するようにしてもよい。例えば、消費エンティティ10が消費を購入するたびに、商品の価格に所定率(例えば、1.0%)を乗じた額が自動的に利用料として口座から引き落とされるようにしてもよい。
【0156】
あるいは、商品を供給する供給者20が販売した商品の数あるいは販売額に応じた利用料を負担するようにしてもよい。さらに、商品を供給する供給者20は、供給する商品の数などに応じて定まる一定額を利用料として負担するようにしてもよい。このような利用料の負担については、任意に設計できる。
【0157】
但し、利用料を自動的に算出および徴収できるように、消費エンティティ10および供給者20の口座に関連付けた処理の実装が好ましい。
【0158】
(f5:メタ商品)
本実施の形態に従う商品取引システム1においては、同一種類の複数の商品をまとめて1つの商品として取り扱うようにしてもよい。このような商品を「メタ商品」とも称す。
【0159】
例えば、「洗剤」については、様々な商品が提供されているが、消費エンティティ10の一部は、特定の生産者および商品を特定することまでは行わず、単に「洗剤」を購入したいと希望するものも存在する。
【0160】
そこで、例えば、「A社製の洗剤AAA」といった商品を特定せず、包括的な商品種別を規定するメタ商品を規定してもよい。
【0161】
このようなメタ商品にいずれの商品が含まれるのかという対応付け情報を運営サーバ300に保持しておくことで、消費エンティティ10は、「洗剤」(いずれの商品かは問わない)を注文できる。
【0162】
一方、供給者20は、メタ商品が要求する商品種別に該当さえすれば、任意の商品を提供できるので、在庫処分などをより容易に行うことができる。
【0163】
なお、各メタ商品にどのような商品を含めるのかについては、運営サーバ300側で管理してもよいし、各メタ商品に含ませることのできる条件を明示して、当該条件に従って供給者20側でメタ商品として販売するようにしてもよい。運営サーバ300側でメタ商品を管理する場合には、メタ商品を示す商品識別番号と、当該メタ商品に含まれる特定の1または複数の商品の各々を示す商品識別番号とを対応付けるテーブルを保持するようにしてもよい。
【0164】
このように、メタ商品を利用可能にすることで、より柔軟な商品の取引を実現できる。
(f6:有効期限オプション)
消費エンティティ10および供給者20は、取引が成立するまでは、購入要求12および販売要求22をそれぞれ任意に取り消しあるいは撤回できるようにしてもよい。さらに、商品の特性によっては、特定に期限までに購入または販売しなければならない場合もある。
【0165】
このようなニーズを考慮して、購入要求12および販売要求22について有効期限を設定するようにしてもよい。より具体的には、消費エンティティ10および供給者20は、任意の購入要求12および販売要求22を生成したときに、取引が成立しなければ、要求を取り消しあるいは撤回する期限(有効期限の条件)を付加できるようにしてもよい。
【0166】
運営サーバ300は、有効期限が指定された購入要求12および販売要求22については、指定された有効期限が到来しても取引が成立していなければ、対応する購入要求12または販売要求22を強制的に取り消す。このような有効期限の条件を購入要求12または販売要求22に付加することで、時期に遅れて取引が成立してしまうような事態を回避できる。
【0167】
有効期限の指定方法としては、特定の日付、特定の日時、今日中、今週中、今月中などの任意の方法を採用してもよい。
【0168】
(f7:在庫有無オプション)
供給者20は特定の商品を常時供給することが予定されているが、何からの事情で一時的に商品を供給できない状況になっている可能性もある。このような場合、商品が入荷次第、商品は消費エンティティ10へ配送されることになるが、商品入荷まで待たされることになる。
【0169】
そこで、消費エンティティ10が購入要求12を生成する際に、指定した商品の在庫の有無を条件として追加するようにしてもよい。より具体的には、供給者20が在庫を有している場合に限って取引を成立させるのか、あるいは、供給者20が在庫を有していなくても取引を成立させるのかを消費エンティティ10が選択できるようにしてもよい。
【0170】
供給者20が在庫を有している場合に限って取引を成立させることが条件とされている場合には、指定された商品が供給者20の在庫として存在している場合に限って、取引が成立することになる。
【0171】
一方、供給者20が在庫を有していなくても取引を成立させることが指定されている場合には、供給者20に対象の商品が入荷するまでの時間などを消費エンティティ10に提示するようにしてもよい。
【0172】
(f8:配送開始期限オプション)
消費エンティティ10は何らかの商品をなるべく早く手に入れたいと考えている場合もある。そこで、消費エンティティ10が購入要求12を生成する際に、指定した商品が供給者20から配送されるまでの期限を条件として追加するようにしてもよい。より具体的には、消費エンティティ10は、取引が成立してから商品が配送されるまでの時間(例えば、取引成立から6時間以内など)、あるいは、商品を配送すべき期限(例えば、10月1日15時など)を指定できるようにしてもよい。
【0173】
このような条件が付加された購入要求12が生成された場合には、運営サーバ300は、供給者20からの配送可能時刻などの情報の提供を受けて、購入要求12と販売要求22との間で要求内容が合致するか否かを判断する。
【0174】
(f9:配送可能範囲オプション)
供給者20の事業規模によっては、商品を配送できる範囲が制限される場合がある。このような配送範囲の制限を考慮して、供給者20が販売要求22を生成する際に、商品を配送可能な範囲を予め指定するようにしてもよい。より具体的には、供給者20は、商品を配送可能な範囲(例えば、日本国内のみ、500km否かなど)を指定できるようにしてもよい。
【0175】
このような条件が付加された販売要求22が生成された場合には、運営サーバ300は、消費エンティティ10の配送先情報(消費エンティティ10の位置を示す情報)を参照して、購入要求12と販売要求22との間で要求内容が合致するか否かを判断する。
【0176】
<G.商品取引システム1の別形態>
上述の説明においては、運営サーバ300を中心とする商品取引システム1を例示するが、このような運営サーバ300を用いない構成を採用してもよい。すなわち、一種のピアトゥピアに類似した構成を採用してもよい。
【0177】
(g1:供給者20主導のシステム)
図15は、本実施の形態に従う別の商品取引システム1Aにおける処理の概要を説明するための図である。
図15を参照して、商品取引システム1Aは、1または複数の消費エンティティ10と、供給者20とを含む。
図15に示す商品取引システム1Aにおいては、運営サーバ300が存在しない代わりに、供給者20(供給者端末200)が消費エンティティ10(コントローラ100)からの購入要求12を処理する。
【0178】
すなわち、供給者20に配置された供給者端末200がマッチング処理を実行する。但し、供給者端末200で実行されるマッチング処理においては、単一の供給者20が販売要求22を生成するのみであるので、処理内容は簡素化されたものとなっている。
【0179】
このように、運営サーバ300を配置せず、供給者20(供給者端末200)と、1または複数の消費エンティティ10(コントローラ100)との間で通信を行って、必要に応じて購入要求12を処理するようにしてもよい。
【0180】
図15に示す商品取引システム1Aにおいて、供給者20に配置された供給者端末200は、
図3に示す構成に加えて、運営サーバ300が有している機能(例えば、
図4に示されるマッチングプログラム312、決済プログラム314、要求キュー316、および
ユーザ情報318など)を含むようにしてもよい。
【0181】
(g2:配送管理サーバ400を付加したシステム)
図15に示す商品取引システム1Aにおいては、
図1に示す商品取引システム1の運営サーバ300と同様の機能を有する供給者20(供給者端末200)を用いる構成例を示すが、配送に関する処理については、別のサーバを配置してもよい。
【0182】
図16は、本実施の形態に従うさらに別の商品取引システム1Bにおける処理の概要を説明するための図である。
図16を参照して、商品取引システム1Bは、
図15に示す商品取引システム1Aに対して配送管理サーバ400をさらに追加した構成に相当する。
【0183】
配送管理サーバ400は、供給者20(供給者端末200)と通信を行って、配送費および配送者を管理する処理を実行する。すなわち、配送管理サーバ400は、
図13および
図14に示すような配送費定義326,327を有しており、配送費を決定する処理や、複数の配送者から適切な配送者を決定する処理などを実行するようにしてもよい。
【0184】
このように、配送に関する処理を担当する配送管理サーバ400を配置することで、複数の供給者20(供給者端末200)からの依頼を統括して、適切な配送者30を決定できるので、効率的な配送を実現できる。また、利用可能な配送者が更新されても、配送管理サーバ400が保持する情報のみを更新すればよいので、柔軟なシステムを実現できる。
【0185】
<H.その他の形態>
(h1:自動注文機能の応用例)
本実施の形態に従う商品取引システム1に係る自動注文機能は、様々な施設および業種に応用が可能である。
【0186】
例えば、ホテルの備品(歯ブラシ、タオル、スリッパ、シャンプー、トイレットペーパなど)を自動的に注文するようなシステムに応用が可能である。この場合には、コントローラ100とホテルの予約システムとを接続し、あるいは、ホテルの予約システムの一部に自動注文プログラム108(
図2)を組み込むことで、宿泊者延べ数などを取得でき、その取得された宿泊者延べ数などの情報に基づいて、必要な備品を必要な数だけ自動的に注文できるようにしてもよい。
【0187】
また、例えば、フレッシュジュースショップにおいて、必要な原材料(牛乳、フルーツ、コップ、ストローなど)を自動的に注文するようなシステムに応用が可能である。この場合には、コントローラ100とレジスターとを接続し、あるいは、レジスターの一部に自動注文プログラム108(
図2)を組み込むことで、販売されたジュースの数および種類などを取得でき、その取得されたジュースの数および種類に基づいて、必要な原材料を必要な数だけ自動的に注文できるようにしてもよい。
【0188】
この場合、ジュースの種類ごとに消費される原材料の量が異なるので、ジュースの種類ごとに消費される原材料の種類および量などの成分情報を予め規定しておき、その規定された成分情報に各ジュースの販売数を乗じることで、必要な原材料の種類および量を決定できる。
【0189】
このように、本実施の形態に従う商品取引システム1は、様々な分野のビジネスに応用が可能である。
【0190】
(h2:口座)
商品取引システム1においては、国際的な商品の取引も可能であり、このような場合には、ユーザの口座は、特定の通貨(例えば、日本円や米国ドルなど)で統一してもよいし、複数の通貨からユーザが特定の通貨を選択するようにしてもよい。異なる通貨の口座間で取引が行われる場合には、取引時の為替レートを考慮して、口座間で代金が遣り取りされてもよい。
【0191】
あるいは、任意の仮想通貨を用いて各ユーザの口座を管理するようにしてもよい。共通の仮想通貨を用いることで、為替レートに基づく変換処理などを省略できる。
【0192】
(h3:分散配置)
上述の説明においては、運営サーバ300がマッチング処理および決済処理を実行する例を示すが、それぞれの処理を異なるサーバに実装してもよいし、複数の運営サーバ300を用いて実装してもよい。例えば、国ごとまたは地域ごとに運営サーバ300を用意するとともに、運営サーバ300同士を連携することで、国際的な商品の取引を実現できる。
【0193】
<I.利点>
本実施の形態に従う商品取引システム1によれば、コントローラ100が商品を消費する対象から当該商品の消費状態に関する情報を取得し、当該取得した情報に基づいて予め定められた条件が満たされたと判断すると、当該商品を購入するための購入要求12を自動的に生成して、運営サーバ300などへ送信する。そして、運営サーバ300を介して商品の取引が実行される。このように、本実施の形態に従う商品取引システム1によれば、状況に応じて自動的な取引を可能とするプラットフォームを提供できる。
【0194】
今回開示された実施の形態はすべての点で例示であって制限的なものでないと考えられるべきである。本発明の範囲は上記した説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【0195】
1,1A,1B 商品取引システム、10 消費エンティティ、12 購入要求、20
供給者、22 販売要求、30 配送者、50 機器、52 洗剤トレイ、54 洗剤、56 履歴情報、100 コントローラ、102,201,301 プロセッサ、104 主メモリ、106,210,310 ストレージ、108 自動注文プログラム、110 制御部、120,203,303 ネットワークインターフェイス、121 商品情報、122 個数情報、123 希望価格、124 配送期限、130 内部インターフェイス、140 センシング部、150 出力部、160 推定結果、162 しきい値、200 供給者端末、202,302 メインメモリ、204,304 入力部、205,305 ディスプレイ、206,306 内部バス、212 在庫管理プログラム、218 在庫情報、250 ユーザインターフェイス画面、252,2502 リスト、254 商品コード欄、256 商品名欄、258 販売価格欄、260 販売個数欄、262 残り個数欄、264 一部取引欄、266 検索ボタン、268 コード読取ボタン、270 内容変更ボタン、272 更新ボタン、300 運営サーバ、312 マッチングプログラム、314 決済プログラム、316 要求キュー、318 ユーザ情報、326,327 配送費定義、328 重量テーブル、350,360 管理情報、352 配送先情報、354,364 残高情報、356 購入履歴、366 販売履歴、400 配送管理サーバ。