〔実施形態1〕
以下、本発明の実施の形態について、図1〜図17に基づいて説明すれば、以下のとおりである。
(購入代行システムの概要)
図2は、購入代行システム100の概要を示す図である。購入代行システム100は、購入代行装置1と購入代行サーバ2とが連携して、ユーザに対して以下のサービスを提供するためのシステムである。すなわち、ユーザが、通信ネットワークを介して店舗(例えば、図2の店舗A、店舗Bなど)から希望する商品を購入する際に行う作業を、購入代行装置1および購入代行サーバ2が代行することにより、ユーザが簡易に電子商取引における購入活動を行うことを可能にする。購入代行システム100は、少なくとも、購入代行装置1(装置)および購入代行サーバ2(サーバ)を含み、好ましくは、購入補助端末3(端末)を含む。
購入代行装置1は、電子商取引における購入活動のうち、ユーザが購入のために実施する工程を簡易に実行するための入力手段をユーザに提供する。当該入力手段は、音声入力部である。購入代行装置1は、宅内でユーザによって使用される家庭内電子機器によって実現される。本実施形態では、例えば、購入代行装置1は、冷蔵庫1aである。購入代行装置1は、宅内に複数設置されていてもよい(例えば、電子レンジ1b)。購入代行装置1は、さらに、音声出力部を備え、ユーザに対して音声を出力することができる。
具体的には、購入代行装置1は、音声認識機能および発話機能を有する購入代行サーバ2と通信し、ユーザの発話を録音した入力音声データ(以下、ユーザ発話データ)を購入代行サーバ2に送信する。そして、購入代行装置1は、上記ユーザ発話データに対する応答として出力すべき出力音声データ(以下、機器発話データ)を購入代行サーバ2から受信し、それを音声として出力する。これにより、擬人化された購入代行装置1が、あたかも意思を持って発話しているかのように、ユーザに見せかけることができ、購入代行装置1(のキャラクター)とユーザとの対話が実現する。このように、ユーザが購入を希望する商品について、ユーザは、購入代行装置1に対する発話によって、購入代行サーバ2に知らせることができる。すなわち、購入代行装置1自体がユーザとの音声による対話によって購入代行を受け付ける音声入出力ユーザインターフェースとして機能する。
購入代行サーバ2は、音声認識機能および発話機能を有し、購入代行装置1を制御して購入代行装置1にユーザと対話させる。そして、対話の中から、ユーザが購入を希望する商品を特定し、特定した内容に応じて、実際のユーザの購入活動を代行する(購入代行機能)。具体的には、店舗が所有する店舗サーバ4(例えば、店舗Aの店舗サーバ4a、店舗Bの店舗サーバ4bなどの発注先サーバ)に対して、商品(および個数)を指定して注文する工程、および、発注を確定させる工程を実行する。さらに必要に応じて、購入代行サーバ2は、発注先を選択する工程、および、発注先からの応答(注文受付Ack、請求書、配達予定通知、配達完了通知など)を受信して管理する工程を実行してもよい。
さらに、本実施形態では、購入代行サーバ2は、ユーザが携帯する購入補助端末3と通信し、購入補助端末3と連携して以下の機能を実現する。すなわち、購入代行サーバ2は、購入補助端末3を介して指定された商品(および個数)を、購入予定リストに登録して管理する機能、および、購入補助端末3を介して入力された購入指示に従って、購入予定リストに登録された商品を所定の店舗に注文する機能(購入支援機能)を有する。購入補助端末3を介して入力された商品および個数の購入予定リストを以下では、「買い物メモ」と称し、上記リストに登録して管理する機能を、「買い物メモ機能」と称する。
購入代行サーバ2は、購入活動を支援するための様々な情報をユーザごとに保持し、上述の例以外にも、購入活動に係る様々な購入補助端末3からのリクエストに対してレスポンスを返す機能を有する。
なお、購入代行サーバ2が保持するユーザごとの各種情報について、例えばOauth認証を用いることにより、購入代行サーバ2、および、購入代行サーバ2と提携する店舗サーバ4のそれぞれは、ユーザが許可した範囲で互いに共有することができる。ユーザごとの情報としては、上述の買い物メモなどの他に、ユーザの氏名、住所、電話番号、決済に使用するクレジットカードの情報、購入する商品名、購入履歴、請求書などが含まれるが、この例に限定されない。
購入補助端末3は、ユーザの購入活動を支援するためのグラフィカルユーザインターフェースを提供する。具体的には、購入補助端末3は、購入代行サーバ2から、買い物メモ作成画面、購入履歴画面などを受信して、それを表示する。また、画面に対するユーザ操作を受け付けて、当該操作によって特定された情報を購入代行サーバ2に送信する。本実施形態では、購入補助端末3は、ユーザが携帯するスマートフォンである。
(定常商品および一般商品について)
以上のとおり、本実施形態に係る購入代行システム100によれば、ユーザが通信ネットワークを介して店舗から商品を購入するルートは2つある。すなわち、ユーザが購入代行装置1に音声を入力して、購入代行サーバ2に商品の購入を代行させる第1のルート、および、ユーザが購入補助端末3を操作して、購入したい商品および個数の選択を行い、購入代行サーバ2に対して購入を指示する第2のルートである。
第1のルートでは、ユーザは、購入代行装置1に対して少なくとも購入を希望する品名を発話すればよく、その後の購入に係る工程は、購入代行サーバ2が代行する。具体的には、購入代行サーバ2は、ユーザ発話データを解析することにより、ユーザが購入を希望する商品を特定することができ、店舗サーバ4に対して注文を行う。ここで、第1のルートでは、ユーザは、購入を希望する商品について、店舗サーバ4がその商品を一意に特定するための商品識別情報(商品IDまたは商品正式名)および希望する購入個数を都度指定する必要はない。よって、第1のルートは、ユーザが購入したい商品の商品識別情報および個数の組み合わせが一定していて滅多に変わらない場合に利用可能であり、さらに、購入手続きが簡易であるので、購入頻度が高い場合に、好適に利用可能である。このように、ユーザにとって購入希望商品の商品識別情報および個数の組み合わせが一定していてほとんど変わらない商品を「定常商品」と称する。本実施形態において、定常商品は、ユーザごとに設定可能である。定常商品に関するユーザごとの設定情報は、購入代行サーバ2によって管理される。
定常商品以外の商品については、ユーザが都度、購入希望の商品の商品識別情報および個数を指定しなければならないので、従来の電子商取引における購入活動とほぼ同様に、第2のルートによって購入される。第2のルートによって購入される定常商品以外の商品を、当該定常商品と区別して「一般商品」と称する。
なお、本実施形態において、定常商品は、第2のルートで購入することもできる。購入代行サーバ2は、ユーザが定常商品の品名(商品正式名でなく、その商品を表す一般名詞でよい)を発話したことを検知して、当該定常商品の商品識別情報および個数を、一般商品とともに買い物メモに登録する。買い物メモに登録された商品は、定常商品と一般商品の区別によらず、購入補助端末3を介して購入手続きが実施される。すなわち、第2のルートにて購入される。
以上のとおり、本発明の購入代行システム100によれば、ユーザは、定常商品について、簡易な入力手段を用いるのみ(すなわち、品名を発話するのみ)で、簡単に欲しい商品を購入することが可能となる。
(各装置の構成)
図1は購入代行システム100を構成する上記の各装置の要部構成の一例を示すブロック図である。なお、以降の説明では、購入代行装置1を実現する家庭内機器の一例として冷蔵庫1aを、購入補助端末3の一例としてスマートフォンを例に挙げて説明する。また、本発明に直接関係のない部分(例えば、購入補助端末3において電話回線を利用して通話を実現する部分や、冷蔵庫4aにおいて庫内に冷気を放出する部分など)については、以下の説明および上記ブロック図から省略している。また、店舗サーバ4の構成の詳細についても本発明との関連が薄いため省略する。
1:購入代行サーバのハードウェア構成
図1に示すように、購入代行サーバ2は、通信部11、制御部12および記憶部13を備える。通信部11は、購入代行装置1、購入補助端末3および店舗サーバ4との通信を行って、上述したとおり、各種情報のやりとりを行う。
制御部12は、購入代行サーバ2の機能を統括して制御する。制御部12は、機能ブロックとして、少なくとも、音声制御部21および購入代行部22を含み、必要に応じて、要求処理部23(生成部)および音声要求処理部24(登録部/リスト作成部)を含む。機能ブロックの各部については、後に詳述する。
記憶部13は、購入代行サーバ2が使用する各種データを記憶する。記憶部13は、少なくとも、対話ログデータベース(DB)31および定常商品リストデータベース(DB)33を含む。記憶部13は、さらに、必要に応じて、合言葉データベース(DB)32、店舗情報データベース(DB)34、購入履歴データベース(DB)35および買い物メモデータベース(DB)36を含んでいてもよい。各DBのデータ構造は、別図を参照して詳述する。なお、図示しないが、記憶部13は、音声フォーマットを格納するためのデータベースを含んでいる。音声フォーマットDBは、いわば音声(発話)の素材集である。音声制御部21が、機器発話データを生成する際に本DBを参照する。音声の素材は、音声データであってもよいしテキストデータであってもよい。
2:購入代行装置としての家庭内機器(冷蔵庫)の構成
図1に示すように、冷蔵庫1aは、通信部41(受信部/送信部)、制御部42、マイク43、スピーカ44、操作部45および開閉センサ46(開閉センサ部)を備える。通信部41は購入代行サーバ2と通信を行う。具体的には、通信部41は後述する音声制御部421によって生成されたユーザ発話データを、購入代行サーバ2に送信する。また、通信部41は購入代行サーバ2から機器発話データを受信し、これを処理する音声制御部421に出力する。
制御部42は、冷蔵庫1aの機能を統括して制御する。制御部42は音声制御部421を含む。音声制御部421は、音声データに関する処理を行う。具体的には、音声制御部421は、マイク43が取得した音声(ユーザが発話した音声)を録音し、ユーザ発話データを生成する。また、音声制御部421は、通信部41が受信した機器発話データを処理して、冷蔵庫1aの発話としての音声をスピーカ44から出力する。
操作部45は、ユーザによる入力操作を受け付ける。操作部45は例えば物理ボタン、タッチパネルなどであり、入力操作を受け付けたことを示す入力信号を音声制御部421に出力する。音声制御部421は当該入力信号を受けて、対話を開始する。音声制御部421は、ユーザとの対話の開始イベントが発生した旨を、購入代行サーバ2に通知し、購入代行サーバ2の制御下で、音声データを入出力して対話を実行する。なお、操作部45は冷蔵庫1aのドアであってもよい。この場合、ユーザがドアを開けたことをトリガにして、音声制御部421が対話を開始してもよい。具体的には、冷蔵庫1aは、ドアの開閉センサ46を備え、開閉センサ46は、ドアが開けられたこと、または、閉じられたことを検知すると、その検知結果を音声制御部421に出力する。なお、開閉センサ46は、明るさセンサ、接触センサなど適宜のセンサで実現される。また、マイク43およびスピーカ44は常に起動された状態であってもよく、所定のイベントが発生したことをトリガとして、冷蔵庫1aから発話を開始する形で、ユーザとの対話が開始されてもよい。つまり、ユーザが操作部45に対して対話を開始するための入力操作を行わない構成であってもよい。さらに、冷蔵庫1aは、図示しないタイマを備えていてもよい。例えば、タイマは、開閉センサ46がドアの開閉を検知した時点(あるいは、その他の対話開始イベント発生時点)から計時を開始する。冷蔵庫1aは、その時点から所定時間(例えば、3分)が経過するまでの間、マイク43およびスピーカ44を起動する構成であってもよいし、音声制御部421は、上記タイマによる計時期間のみ音声データを入出力する構成であってもよい。これにより、ユーザが冷蔵庫1aを使用している所定期間に限って、効率よく音声認識処理が実行されるため、冷蔵庫1aおよび購入代行サーバ2の処理の負荷を軽減させることができる。さらに、冷蔵庫1aを使用(ドアを開閉)している所定期間は、ユーザが、在庫の不足に気づいたりして、購買意欲が最も高まっている期間であると考えられる。このように、ユーザが冷蔵庫1aを使用してからの所定期間内に、音声入力による購入作業を可能にすることにより、ユーザが購入の必要性を失念したり、気が変わったりして、購入の機会を逃す虞がなくなる。
3:購入補助端末(スマートフォン)の構成
図1に示すように、スマートフォンである購入補助端末3は、通信部51(受信部/送信部)、制御部52、操作部54、表示部55を備える。通信部51は購入代行サーバ2と通信を行う。具体的には、通信部51は後述するUI処理部521によって処理された情報を、購入代行サーバ2に送信する。また、通信部51は購入代行サーバ2から受信した情報を、それを処理するUI処理部521に出力する。
制御部52は、購入補助端末3の機能を統括して制御する。制御部52は、UI処理部521および表示制御部522を含む。UI処理部521は、表示部55に表示されるユーザインターフェース(以下、UI)に関する処理を実行する。具体的には、UI処理部521は、購入代行サーバ2から買い物メモを作成したり編集したりするための画面あるいは商品を購入するための画面(購入画面)を取得し、その画面が表示部55に表示されるよう、当該画面を表示部55の仕様に適合した配置に変換して表示制御部522に出力する。また、UI処理部521は、操作部54を介して上記画面が操作されたことによって入力された入力信号にしたがって、各種情報を生成する。生成された情報は、購入代行サーバ2に送信される。表示制御部522は、UI処理部521が生成した画面に対応する映像信号を表示部55に出力して、当該画面を表示部55に表示させる。
操作部54は、ユーザの入力操作を受け付けて、当該入力操作に対応する入力信号をUI処理部521に出力する。なお、ここでは操作部54はタッチパネルであるものとして説明するが、物理ボタンであってもよいし、その他の入力デバイスであってもよい。操作部54がタッチパネルである場合、操作部54は表示部55と一体となっている。表示部55は、表示制御部522が出力した映像信号に対応する画面を表示する。なお、表示部55としては液晶ディスプレイ(Liquid Crystal Display;LCD)が挙げられるが、これに限定されない。
(購入代行サーバのソフトウェア構成)
1:音声制御機能
音声制御部21は、冷蔵庫1aによって入出力される音声データに関する処理を行う。音声制御部21は、図示しない音声解析部および音声生成部を含む。音声解析部は、冷蔵庫1aから受信したユーザ発話データに対して音声解析を実行する。具体的には、受信したユーザ発話データをテキストデータ化し、発話が成された日時とともに、対話ログDB31に格納する。格納されたテキストデータは、音声生成部によって、次に冷蔵庫1aに発話させる内容を決定するために参照されたり、購入代行部22によって、購入に係る特定のキーワードが発話されたか否かを判定するために参照されたりする。なお、音声解析部が実行する音声解析処理(ユーザ発話データのテキストデータ化)については、既存の技術が利用できる。音声生成部は、冷蔵庫1aに出力させる機器発話データを生成する。機器発話データは、対話ログDB31に格納されたユーザの発話に対する応答としてふさわしい内容を含んでいなければならない。そこで、音声生成部は、音声フォーマットDBに格納されている音声データの1以上の素材、および、ユーザによって発話されたキーワードを組み合わせて、ユーザとの対話が成立するような内容を含む機器発話データを生成する。生成された機器発話データのテキストデータは、冷蔵庫1aの発話として対話ログDB31に格納されるとともに、通信部11を介して冷蔵庫1aに供給される。
2:定常商品の購入代行機能(第1のルートによる購入)
図1は、購入代行サーバ2の購入代行機能に係る要部構成を示す図である。購入代行機能を担う購入代行部22は、少なくとも、発注品特定部222(特定部)および発注部224を含む。さらに、必要に応じて、購入代行部22は、認証部221、発注先選択部223を含んでいてもよい。
購入代行部22は、まず、対話ログDB31を監視して、購入代行処理のトリガとなるキーワードがユーザによって発話された否かを判断する。すなわち、購入代行部22は、ユーザの発話の内容から特定のキーワードを検知する検知部として機能する。購入代行のトリガとなる特定のキーワードとしては、定常商品の品名(例えば、「たまご」など)が少なくとも含まれる。本実施形態では、品名に加えて、ユーザが購入を決断したときの決まり文句をキーワードとして特定する。なお、決まり文句は、「買うわ。」「注文して。」など、ユーザの購入の意思を直接的に意味する日常会話の類であってもよいが、「ひらけごま」などのように、家族の中で購入の権限がある者のみ知り得る合言葉やパスワードの類であることが好ましい。本実施形態では、合言葉がユーザ(1家庭)ごとに予め設定されている。また、対話ログDB31において全てのユーザ発話データには、ユーザ(1家庭)を一意に識別する情報(以下、クライアントID)が関連付けられているので、購入代行部22は、ユーザの対話ログを参照して、そのユーザに固有の合言葉が発話されたか否かを検知することができる。
定常商品リストDB33には、ユーザごとにどの商品を定常商品として設定しているのかが記憶されている。購入代行部22は、定常商品リストDB33を参照して、そのユーザに対応付けられた定常商品の品名が発話されたことを検知すると、ユーザがその定常商品の購入を決断したと判断する。そして、購入代行部22は、購入代行処理の開始を決定し、購入代行部22内の各部に購入代行処理の実行を指示する。
購入代行部22が認証部221を含む場合、認証部221は、ユーザを認証して、購入代行処理を続行してよいかどうかを決定する。具体的には、認証部221は、合言葉DB32において事前に登録されている上記ユーザの合言葉と、購入代行部22が検知した(すなわち、ユーザによって実際に発話された)合言葉とを比較する。合言葉が一致した場合、認証部221は、購入代行処理の続行を決定する。
発注品特定部222は、発話された定常商品の品名(例:たまご)に基づいて、発注に必要な情報を特定する。発注に必要な情報とは、少なくとも、発話された品名に対応する商品の商品識別情報である。商品識別情報は、店舗サーバ4が販売・配達すべき商品を一意に特定するための情報であり、例えば、商品IDあるいは商品正式名などである。本実施形態では、発注品特定部222は、商品正式名を特定する。例えば、定常商品の品名「たまご」に対応する商品正式名は、「栄養卵ひかり M玉 10個パック」などである。定常商品リストDB33において、ユーザごとに、定常商品の品名に関連付けて、商品正式名が記憶されている。発注品特定部222は、定常商品リストDB33を参照することにより、発話された定常商品の品名「たまご」から、そのユーザが「たまご」と言った場合には、「栄養卵ひかり M玉 10個パック」ことである、と特定することができる。
さらに、本実施形態では、発注品特定部222は、特定した商品の発注すべき個数を特定する。定常商品リストDB33において、定常商品の品名には、さらに、個数が対応付けられており、発注品特定部222は、定常商品リストDB33を参照することで、発話された品名に対応する商品正式名に加えて個数を特定することができる。
なお、実施形態1では、発注品特定部222は、さらに、特定した商品の発注先を特定する。定常商品リストDB33において、定常商品の品名には、さらに、発注先が対応付けられており、発注品特定部222は、さらに、発話された品名の商品の発注先を特定することができる。
発注部224は、発注品特定部222によって特定された発注先に対して、ユーザが発話した定常商品を注文する。具体的には、発注部224は、少なくとも、発注品特定部222によって特定された商品識別情報(商品正式名)を、上記発注先の店舗サーバ4に送信して、注文を実行する。発注品特定部222によって、商品IDや個数などが特定された場合には、それらも併せて店舗サーバ4に送信する。なお、発注部224は、例えば、店舗サーバ4が指定するフォーマットにしたがって注文書データを作成したり、店舗サーバ4との間で取り決められた発注プロトコルにしたがって、店舗サーバ4と情報の交換を行ったりすることもできる。
発注部224によって注文が完了すると、購入代行部22は、最後に、注文が完了した定常商品について購入履歴を残してもよい。この場合、購入代行部22は、注文された定常商品の品名、商品正式名、個数、発注先、発注日時などを、購入履歴DB35に格納する。なお、実施形態1の購入代行部22は、必ずしも発注先選択部223(選択部)を含まない。発注先選択部223については、実施形態2にて詳述する。
3:要求処理機能
要求処理部23は、通信部11を介して購入補助端末3と通信し、購入補助端末3からのリクエストに対応して、これには限定されないが、例えば、以下の処理を実行する;(1)合言葉の登録および変更、(2)定常商品の設定および解除、(3)買い物メモの表示、新規作成および編集、(4)買い物メモを用いた購入商品の指定、(5)購入可能な商品(定常商品および一般商品)の一覧表示、検索および選択、(6)対話ログの表示、(7)購入履歴の表示、(8)配達記録の表示などである。
要求処理部23は、必要に応じて、上記処理の実行結果をレスポンスとして購入補助端末3に返してもよい。レスポンスを返すことの中には、要求処理部23が、上記処理の実行指示を受け付けるための画面を作成し、購入補助端末3に提供することも含まれる。これにより、ユーザは、購入補助端末3に表示された画面を見ながら購入補助端末3に対して入力を行い、上記の処理の実行を購入代行サーバ2に対して命令することができる。
音声要求処理部24は、ユーザによって発話された内容を受けて、必要に応じて記憶部13に記憶されている各種DBの情報を更新する。音声要求処理部24の具体的な機能については後述する。
3−1:一般商品の購入支援機能(第2のルートによる購入)
要求処理部23は、購入補助端末3からのリクエストが、一般商品の購入を指示する「購入指示」である場合、注文に必要な情報を購入補助端末3から受信する。注文に必要な情報は、上記リクエストに含まれていてもよいし、要求処理部23が上記リクエストを受けて購入補助端末3に対して要求することにより後から取得されてもよい。注文に必要な情報は、購入を希望しているユーザを特定するためのクライアントID、購入が希望されている商品を特定するための商品識別情報(商品IDまたは商品正式名)、購入希望個数、および、その商品の発注先の店舗IDなどである。要求処理部23は、購入補助端末3から受信した注文に必要な情報を購入代行部22に引き渡し、購入代行処理を依頼する。発注部224は、要求処理部23から注文に必要な情報を受け取り、以降は第1のルートと同様に商品を発注する。
(データベース)
1:対話ログDB
図3を参照して、対話ログDB31のデータ構造の一例を説明する。図3において、対話ログDB31のデータ構造をテーブル形式にて示したことは一例であって、当該データ構造を、テーブル形式に限定する意図はない。以降、データ構造を説明するためのその他の図においても同様である。
対話ログDB31は、これには限定されないが、例えば、クライアントID、発話ID、ユーザ発話データ、機器発話データ、および、発話日時のカラムを含む。クライアントIDは、図2に示された、購入代行システム100のサービスを利用する1家庭につき、1つ付与されるものであり、購入代行サーバ2において、サービスの受け手を家庭単位で識別するのに用いられる。本実施形態では、1家庭について、購入の権限者として一人のユーザが、また、購入の窓口として1台の購入代行装置1(家庭内機器;冷蔵庫1a)が想定されている。そのため、購入代行サーバ2は、このクライアントIDひとつで、サービスの受け手を一意に特定することができる。1家庭内に、購入の権限者であるユーザが複数いたり、購入代行装置1としての家庭内機器が複数設けられたりする場合には、ユーザおよび家庭内機器を識別するためのIDが別途設定される。
ユーザ発話データのカラムには、ユーザの発話に対応するテキストデータが格納される。機器発話データのカラムには、冷蔵庫1aの発話に対応するテキストデータが格納される。1つのテキストデータは、1つの音声データに対応している。1つのテキストデータにつき、便宜上、発話IDが割り当てられていてもよい。
発話日時のカラムには、ユーザ発話データの場合、当該ユーザ発話データの録音が開始された日時が格納される。機器発話データの場合、当該機器発話データの出力が開始された日時が格納される。
対話ログDB31の各カラムに格納された以上のデータは、購入代行部22が特定のキーワード(品名および合言葉)を検知するときに参照される。
2:合言葉
図4を参照して、合言葉DB32のデータ構造の一例を説明する。合言葉DB32は、これには限定されないが、例えば、クライアントIDおよび合言葉のカラムを含む。同図に示すとおり、クライアントIDに関連付けて合言葉が格納されている。すなわち、1ユーザ(1家庭)につき、1つの合言葉が設定されている。認証部221は、合言葉が含まれた対話ログに対応付けられたクライアントIDと同じクライアントIDの合言葉を合言葉DB32から読み出し、対話ログの中の合言葉と読み出した合言葉との一致/不一致によって、購入代行処理の続行可否を判断する。合言葉のカラムに格納される合言葉のデータ形式は、音声データであってもよいし、テキストデータであってもよい。音声データである場合には、発話の音声データと、合言葉のカラムに格納されている音声データとの声質、声紋などを比較してもよい。
本実施形態では、上記データ構造によれば、1家庭につき合言葉を1つ設定することができるが、これに限らず、合言葉DB32は、複数の合言葉(第1候補、第2候補、第3候補・・・)を設定できるデータ構造を有していてもよい。また、1家庭につき複数のユーザが想定されている場合には、ユーザごとに合言葉が設定できるデータ構造であってもよい。
また、特定の定常商品に関し、定常商品ごとに個別の合言葉が設定できるデータ構造であってもよい。すなわち、合言葉DB32は、クライアントID、定常商品の商品IDに関連付けて、合言葉が格納されるデータ構造を有していてもよい。該データ構造によれば、定常商品に対応付けられた合言葉を知る者しか当該定常商品を購入できないように、権限者以外の購入活動をブロックすることができる。例えば、該データ構造は、高価な定常商品などを子供が勝手に購入できないようにする場合に好適に用いられる。
3:定常商品リスト
図5の(a)および(b)を参照して、定常商品リストDB33のデータ構造の一例を説明する。定常商品リストDB33は、以下の2つのテーブルを含む。
図5の(a)は、購入代行システム100において、定常商品として設定することが可能な全品目を示すテーブルの一例である。該テーブルは、これには限定されないが、定常設定可能品目ID、品名、商品正式名、および、単価のカラムなどを含む。品名と商品正式名との対応関係は、購入代行システム100全体、および、発注先の全店舗サーバ4によって共有される。そのため、単価のカラムは、発注先の店舗サーバ4が複数ある場合には、カラム自体が設けられないか、あるいは、単価のカラムに、参考小売価格、平均価格などが格納される。
品名のカラムには、定常商品として設定可能な品目の通称が格納される。品名は、ユーザが音声入力によって購入希望商品を指すときに発する言葉であるので、その商品を表現するときに広く一般的に用いられる言葉であり、短く簡単であることが好ましい。品名ごとに、便宜上、定常設定可能品目IDが付与されてもよい。
商品正式名のカラムには、上記品名に対応付けることができる商品候補の商品正式名が格納される。同図に示すとおり、1つの品名に対して、関連付けが可能な商品の候補は複数あってもよい。なお、本実施形態では、品名に関連付けることが可能な商品正式名の候補は、全クライアントで共通とする。すなわち、商品正式名に対して割り当てられる品名(呼称)は、ユーザが自由に作成できるものではなく、購入代行サーバ2があらかじめ準備したものが用いられる。
図5の(a)に示すテーブルは、要求処理部23が定常商品の設定および解除を行うための画面を生成するときに参照される。上記データ構造によれば、例えば、ユーザは、自分が「たまご」と言えば、どの銘柄のどのサイズのどの数量のたまごであるのかを、候補の中から好きに選択することができる。
図5の(b)は、定常商品として設定している商品の一覧を、ユーザごとに管理するためのテーブルの一例である。該テーブルは、これには限定されないが、クライアントID、品名、商品正式名、および、個数のカラムなどを含む。
同図に示すとおり、ユーザは、1つの品名につき、1つの商品正式名とその個数とをあらかじめ選択して該テーブルに登録しておくことができる。ユーザが単に品名を発話するだけで、発注品特定部222は、該テーブルを参照すれば、注文に必要な情報、すなわち、購入すべき商品の商品正式名および個数を一意に特定することができる。具体的には、発注品特定部222は、例えば、クライアントID「SH123456」のユーザが“「牛乳」を購入する”と言ったときには、“商品正式名「恵みのミルク1L」を、個数「2」個購入する”ことを意味すると認識することができる。
以上のように、どの商品を定常商品として設定するのかは、家庭(クライアント)ごとに異なっており、品名と商品正式名との対応関係は、クライアントIDを用いてクライアントごとに管理される。
なお、同図に示すとおり、1家庭につき、複数の品目を定常商品として設定することができてもよい。また、上記テーブルにおいて、発注先のカラムが設けられ、品名ごとに、発注先が対応付けられていてもよい。これにより、発注品特定部222は、その商品を注文するときの発注先を特定することができる。さらに、配達日時のカラムが設けられ、品名ごとに、配達日時が対応付けられていてもよい。これにより、発注品特定部222は、その商品の配達日時を特定し、発注先に対して指定することができる。例えば、配達日時のカラムに「金曜日17時以降」が格納されている場合、注文した商品が、発注日以降の配達可能な直近の金曜日17時以降に配達されるように、購入代行サーバ2が店舗サーバ4に対して指定することができる。
4:店舗情報
図6を参照して、店舗情報DB34のデータ構造の一例を説明する。なお、購入代行サーバ2が商品を注文する店舗サーバ4が1つしかない場合には、記憶部13は、その店舗サーバ4の情報を記憶しておくだけでよく、店舗情報DB34を含まなくてもよい。
店舗情報DB34は、これには限定されないが、店舗ID、店舗名、URL、メールアドレス、および、注文手順のカラムなどを含む。店舗IDのカラムには、店舗およびその店舗サーバ4を一意に識別するための識別情報が格納される。店舗名のカラムには、店舗の名称が格納される。URLまたはメールアドレスのカラムには、注文を送信するときの店舗サーバ4の宛先が格納される。URLのカラムには、店舗のWebサイトのホームページ、注文フォームのページ、あるいは、商品リストまたは価格表などのページのアドレスが格納されていてもよい。注文手順のカラムには、店舗サーバ4によって規定された注文のマニュアル、注文書の作成手順、注文書のテンプレート、または、発注プロトコルなどが格納されていてもよい。注文手順のカラムに格納された情報を参照することにより、発注部224は、店舗によって規定された注文の仕方で、ユーザが希望する商品を正確に発注することができる。
5:購入履歴
図7を参照して、購入履歴DB35のデータ構造の一例を説明する。購入履歴DB35は、これには限定されないが、発注日時、店舗ID、商品正式名、区分、個数、単価、合計、および、ステータスのカラムなどを含む。上記各カラムに格納されている情報は、ユーザごとに管理される。すなわち、クライアントIDに関連付けて格納されている。
発注日時のカラムには、発注部224が店舗サーバ4に対して注文に必要な情報を送信した日時が格納される。店舗IDのカラムには、発注先の店舗の店舗IDが格納される。商品正式名のカラムには、注文した商品の商品正式名が格納される。区分のカラムには、注文した商品が定常商品であるのか一般商品であるのかを示す情報が格納される。個数のカラムには、上記商品の注文個数が格納される。単価のカラムには、上記商品の、発注先の店舗における販売価格が格納される。合計のカラムには、当該商品について、単価×個数で求められる支払金額の合計が格納される。ステータスのカラムには、当該商品についての現在の状況が格納される。例えば、「発注完了」は、購入代行サーバ2が店舗サーバ4に対して発注を完了させており、店舗サーバ4から注文受付Ackが送信されるのを待機している状況であることを意味する。「配達中」は、購入代行サーバ2が店舗サーバ4から注文受付Ackを受信し、よって注文が確定し、発注先の店舗が注文された商品の配達を手配している途中であることを意味する。「配達完了」は、注文された商品が購入者であるユーザの家庭に配達されたことを意味する。「支払完了」は、上記商品の対価を上記店舗に対して支払い、その入金が店舗サーバ4において確認されたことを意味する。
購入代行部22は、発注が完了した商品に関する情報を上述の各カラムに格納する。購入履歴DB35は、要求処理部23が購入補助端末3からのリクエストを受け付けて、購入履歴画面を生成するときに参照される。
6:買い物メモ
図8を参照して、買い物メモDB36のデータ構造の一例を説明する。買い物メモDB36は、これには限定されないが、例えば、登録日時、品名、商品正式名、区分、個数、単価、合計、および、購入フラグのカラムを含む。これらのカラムに格納されている情報は、ユーザごとに管理されている。すなわち、クライアントIDに関連付けて格納されている。登録日時のカラムには、商品のレコードが新規に買い物メモDB36に登録された日時が格納される。購入フラグのカラムには、買い物メモにリストアップされた当該商品について、ユーザの購入意思の有無を表すフラグが格納される。例えば、購入フラグ「ON」は、その商品についてユーザが購入の意思があることを意味し、購入フラグ「OFF」は、その商品についてユーザは購入を決断していない(保留している)ことを意味している。その他のカラムについては、上述した通りであるので説明を省略する。
本実施形態では、商品を購入する場合と同様に、2つのルートのどちらを経由しても買い物メモDB36に商品を登録することが可能である。1つ目は、ユーザが、冷蔵庫1aとの対話を通じて、買い物メモに商品を登録する旨の発話を行い、発話内容にしたがって、音声要求処理部24が、買い物メモDB36を更新する第1のルートである。2つ目は、ユーザが、購入補助端末3に表示されている買い物メモ作成画面を操作し、該操作にしたがって、要求処理部23が、買い物メモDB36を更新する第2のルートである。
音声要求処理部24または要求処理部23によって商品が登録された買い物メモDB36は、購入代行部22が商品を注文するときに参照される。購入代行部22は、登録日時、区分、商品正式名(および個数)、および、購入フラグによって特定される商品のステートに応じて、その商品の注文を行うか否かを決定する。とりわけ、発注部224は、第1のルートで音声登録された定常商品に対して、その対話の場ですぐに購入が決断されなかった場合には、購入フラグがONの定常商品について、所定時刻(例えば、15:00)になると、発注を実行する。あるいは、発注部224は、登録日時から所定時間経過(例えば、3時間経過)すると、発注を実行してもよい。ここで、買い物メモDB36に登録される商品(レコード)のステートは、以下の5パターンが想定される。
6−1:区分が「定常商品」で購入フラグが「OFF」のレコードについて
本パターンのレコードは、第1のルートを介して、登録されたレコードである。具体的には、冷蔵庫1aに定常商品の品名が音声入力されると、音声要求処理部24が、該品名に対応する商品のレコードを買い物メモDB36に新規登録する。レコードが登録されると、発注品特定部222は、定常商品リストDB33を参照し、登録された品名に対応する商品正式名と個数とを特定し、当該レコードのそれぞれのカラムを埋める。発注品特定部222は、必要に応じて、発注先を特定し、さらに、その商品の単価と合計とをそれぞれのカラムに格納してもよい。
本パターンでは、登録されたレコードは、購入意思を意味する決まり文句(または合言葉)が発話されていないために、注文が確定せず待機状態となっている。また、購入フラグが「OFF」であるため、所定時刻になっても、発注部224によって発注されない。
例えば、図8に示す1行目のレコード(品名「たまご」)が本パターンに該当する。このレコードについて、発注部224が発注を実行するためには、ユーザが、購入補助端末3に表示された買い物メモ作成画面を操作して、購入フラグを「ON」にした上で、(1)購入確定ボタンを押下するか、または、(2)所定時刻になればよい。あるいは、音声制御部21が当該レコードの商品購入を促す発話を冷蔵庫1aに実行させて、これにより、ユーザに合言葉を言わせたり、または、購入フラグを「ON」にすることに同意する旨を発話させたりすればよい。これに応じて購入代行部22が購入代行処理を開始することができる。
6−2:区分が「定常商品」で購入フラグが「ON」のレコードについて
本パターンのレコードは、上記と同様に、第1のルートを介して、音声要求処理部24によって登録されたレコードであり、さらにその後、ユーザが、購入補助端末3に表示された買い物メモ作成画面を操作して、購入フラグを「ON」にしたレコードである。
例えば、図8に示す2行目のレコード(品名「牛乳」)が本パターンに該当する。このレコードの商品は、(1)所定時刻までにユーザが買い物メモ作成画面を操作して購入確定ボタンを押下することによって、購入フラグが「ON」の他の商品とともに発注されるか、または、(2)所定時刻になったときに発注部224によって自動的に発注される。
6−3:区分が「一般商品」で商品正式名が「NULL」のレコードについて
本パターンのレコードは、品名が発話されたことにより、第1のルートを介して、音声要求処理部24によって登録されたレコードである。しかし、上記の各パターンと異なる点は、発話された品名に対応する商品が定常商品として設定されていない(一般商品である)点である。この場合、品名に対応する商品正式名および個数が定常商品リストDB33に登録されていないために、発注品特定部222は、当該レコードの正式商品名および個数のカラムを埋めることができない。すなわち、本レコードは、品名が発話されたことをトリガとして、とりあえず登録されたが、注文に必要な情報が欠けている未完成のレコードである。音声要求処理部24は、注文に必要な情報が補完されていない現時点では、当該レコードの購入フラグを「OFF」にする。
例えば、図8に示す3行目のレコード(品名「ヨーグルト」)が本パターンに該当する。ユーザは、ヨーグルトを買い物メモに登録する旨の発話をしたものの、事前に、ヨーグルトを定常商品として設定していなかった。このため、発話時点で、発注品特定部222が情報を特定できないカラムは、「NULL」となる。このレコードについて、発注部224が発注を実行するためには、少なくとも、ユーザが発話した品名「ヨーグルト」について、対応する商品正式名および個数が指定されなければならない。この指定は、購入補助端末3に表示される操作画面を介して、ユーザが所望するヨーグルトの商品正式名および個数を選択することによって実現する。
以上のとおり、ユーザは、定常商品として設定していない一般商品について、品名を発話するのみで買い物メモに登録することはできる。ただし、ユーザは、当該品名のレコードの購入フラグを「ON」にしたり、音声入力のみで購入を確定させたりするために、登録後に、購入補助端末3を用いて商品正式名および個数を指定する必要がある。
6−4:区分が「一般商品」で商品正式名および個数が特定されており、購入フラグが「ON」のレコードについて
本パターンのレコードは、第2のルートを介して、要求処理部23によって登録されたレコードである。具体的には、購入補助端末3に表示された買い物メモ作成画面を介して、商品正式名および個数が指定され、かつ、購入フラグが「ON」に設定される。要求処理部23は、購入補助端末3から上記の操作内容を含むリクエストを受け付けて、上記レコードの商品正式名および個数のカラムに、指定された商品正式名および個数を格納し、購入フラグを「ON」に変更する。
例えば、図8に示す4行目のレコード(品名「納豆」)が本パターンに該当する。このレコードについて、発注部224が発注を実行するためには、ユーザが、購入補助端末3に表示された買い物メモ作成画面を操作して、購入確定ボタンを押下すればよい。本レコードの商品は一般商品であるので、発注部224が、音声入力に応じて発注を確定させたり、定刻に自動発注したりすることはない。
6−5:区分が「一般商品」で商品正式名および個数が特定されており、購入フラグが「OFF」のレコードについて
本パターンのレコードは、上記パターンと同様に、第2のルートを介して、要求処理部23によって登録されたレコードである。しかし、買い物メモ作成画面において購入フラグを「ON」する操作がユーザによって実行されていない。すなわち、購入が保留されている状態である。購入フラグが「OFF」の状態で、購入確定ボタンが押下されても、発注部224は当該商品の発注を実行しない。また、上記パターンと同様に、本パターンのレコードについても、発注部224は、音声入力に応じて発注を確定させたり、定刻に自動発注したりすることはしない。
以上のように、本実施形態では、購入代行部22は、買い物メモDB36を参照して、商品ごとの登録日時と区分とに基づいて、商品を注文するか否かを決定することができる。また、発注品特定部222は、必要に応じて定常商品リストDB33を参照して、商品正式名と個数とを特定することができる。そして、発注部224は、購入フラグが「ON」の商品のうち、商品正式名と個数とが買い物メモにおいて特定されている商品について発注を実行する。
上記構成によれば、ユーザは、音声入力による簡易な購入活動を実施するとともに、その購入活動と矛盾や混乱をきたすことなく、購入補助端末3を用いて買い物メモを作成、編集しながら容易に購入活動を実施することができる。
(購入代行処理の概要)
図9は、購入代行システム100における処理の流れを示すシーケンス図である。図9は、とりわけ、第1のルートを介して買い物メモが作成されているときに購入活動が実施される場合の処理の概要を示す。
ユーザが、買い物メモを作成したいときに、冷蔵庫1aに対して買い物メモを作成したい旨の発話を行い(S1)、冷蔵庫1aとの対話を開始させる。事前に「買い物メモ作って」などの決まり文句が設定されていてもよい。S1において、冷蔵庫1aとの対話開始のトリガは、上記に限定されない。例えば、ユーザは、買い物メモの作成を指示する操作ボタン(冷蔵庫1aに設けられている)を押してもよい。あるいは、冷蔵庫のドアの開閉が対話開始のトリガとなってもよい。この場合、ユーザが、冷蔵庫1aのドアを開けたり、閉じたりすると、冷蔵庫1aの開閉センサ46が、ドアの開閉を検知する(S1’)。なお、冷蔵庫1aが開閉センサ46を備えない場合は、S1’の処理は省略される。
買い物メモ作成に関する音声または操作信号が冷蔵庫1aに入力されると(音声取得ステップ)、あるいは、開閉センサ46が、ドアの開閉を検知すると(S1’でYES)、冷蔵庫1aの音声制御部421は、ユーザとの対話を開始させるイベントが発生したと判断し、通信部41を介して、購入代行サーバ2に対話開始イベントを通知する(S2)。具体的には、音声制御部421は、自機に関連付けられているクライアントIDと、S1で入力、録音されたユーザ発話データとを購入代行サーバ2に送信する。
購入代行サーバ2の音声制御部21は、S2の通知によって、対話開始イベントが発生したことを検知すると(S3でYES)、冷蔵庫1aを制御して対話を実行させる(S4)。具体的には、音声制御部21は、ユーザ発話データの解析と対話ログの記録とを実行し、ユーザの発話に対する返答としてふさわしい内容の機器発話データを生成して冷蔵庫1aに供給する。冷蔵庫1aは、機器発話データを取得し、音声として出力することにより発話する。こうして、冷蔵庫1aは、入力されたユーザ発話データの転送、および、供給された機器発話データの出力を、購入代行サーバ2の制御下で繰り返し、ユーザとの対話を実行する(S5)。ユーザは、買い物メモ作成のための対話を冷蔵庫1aと継続する(S6)。
ここで、ユーザが、買い物メモに登録したい商品の品名を発話すると、その品名が含まれたユーザ発話データを音声制御部21が解析する。音声要求処理部24は、買い物メモ作成に係る対話の文脈で、品名が発話されたと判断し(S7でYES)、上記商品のレコードを買い物メモDB36に登録する(S8)。
さらに、ユーザが、買い物メモに登録した商品を購入する意思を示す発話を行うと、購入代行部22は、買い物メモに登録された定常商品の購入が指示されたと判断し(S9でYES)、買い物メモに登録された定常商品の購入代行処理を実行する(S10)。
上記方法によれば、ユーザは、冷蔵庫1aとの対話のみで、買い物メモを作成することが可能であり、引き続き、対話のみで買い物メモに登録した商品の購入を購入代行サーバ2に対して指示することが可能となる。
なお、冷蔵庫1aがタイマを備える場合には、タイマが、対話開始イベントが発生した時点から計時を行い、該時点から所定時間経過後に対話が終了されてもよい。具体的には、音声制御部421は、ドアの開閉などの対話開始イベントが発生してから所定時間(例えば、3分)経過した場合に(S11)、ユーザとの対話を終了してもよい(S12)。
上記のように所定時間経過後に対話が終了したり、あるいは、買い物メモの作成途中(S5において冷蔵庫1aと対話中)に、ユーザが一旦冷蔵庫1aを離れたりするなどの状態で、購入が決断されないままに買い物メモの作成が中断することが想定される。この場合、作成途中の買い物メモは、買い物メモDB36に維持されており、ユーザは、冷蔵庫1aと対話を再開させることで、中断した買い物メモの作成を再開することができる。
この再開のトリガとしては、例えば、以下のものが想定される。
・ユーザが、冷蔵庫1aに対して買い物メモの作成を再開したい旨の発話を行う。
・買い物メモが中断されると、冷蔵庫1aが、買い物メモ中断を意味するボタンを点滅させて、再び冷蔵庫1aに近づいたユーザに対して注意喚起する。点滅したボタンをユーザが押下することにより、冷蔵庫1aが買い物メモ作成に係る対話を再開させる。
・作成途中の買い物メモが買い物メモDB36に記録されている場合、音声制御部21が、最終登録日時から一定時間経過後に、冷蔵庫1aから話しかけるように、冷蔵庫1aを制御する。これにユーザが応答することにより、買い物メモ作成が再開される。
あるいは、買い物メモDB36に商品の登録がなくても、音声制御部21は、適切な時機に冷蔵庫1aから話しかけるように、冷蔵庫1aを制御してもよい。具体的には、音声制御部21は、購入履歴DB35を参照して、周期的に購入している商品を特定し、次回の発注タイミングを予測する。そして、音声制御部21は、当該発注タイミングになったら、冷蔵庫1aから話しかけるように、冷蔵庫1aを制御する。これにユーザが応答することにより、買い物メモ作成が開始される。
(購入代行処理の流れ−詳細)
図10は、購入代行サーバ2が実行する購入代行処理の流れを示すフローチャートである。まず、音声制御部21は、対話の終了イベントが通知されない限り、冷蔵庫1aを制御して買い物メモ作成に係る対話(図9のS4)を継続する(S101)。
ここで、購入代行部22は、対話ログDB31を監視し、商品の品名が発話されたことを検知した場合(S102でYES)(検知ステップ)、その商品の購入意思を意味するキーワード(例えば、合言葉)が発話されたか否かを監視する(S103)。
購入代行部22が合言葉が発話されたことを検知すると(S103でYES)、次に、認証部221は、S103で検知された合言葉と、そのユーザについて事前に合言葉DB32に登録されている合言葉とを比較する(S104)。ここで、合言葉が一致しなかった場合には、購入代行処理は中断される。この場合(S104でNO)、音声制御部21が、例えば「合言葉が違うよ。もう一度言って」などの機器発話データを冷蔵庫1aに供給し、ユーザに合言葉をもう一度言わせるように対話を継続させてもよい。
上記2つの合言葉が一致した場合(S104でYES)、認証部221は、購入代行処理の続行を許可し、一連の処理が継続される。具体的には、発注品特定部222は、定常商品リストDB33を参照して、S102で検知された品名に対応付けられた商品正式名および個数を特定する(S105)(特定ステップ)。さらに、品名に発注先が関連付けられている場合には、発注品特定部222は、その商品の発注先を特定してもよい(S106)。
発注部224は、発注品特定部222によって特定された発注先の店舗サーバ4に対して、クライアントIDと対応付けて正式商品名および個数を送信し、注文を確定させる(S107)(発注ステップ)。必要に応じて、購入代行部22は、発注が完了した商品について、購入履歴を購入履歴DB35に登録してもよい(S108)。
(UIの具体例)
図11は、購入代行システム100のサービスを利用するにあたり、最初に、ユーザ登録を行うためのUIの一具体例を示す。特に、図11は、購入補助端末3に表示される合言葉登録画面を示す。合言葉登録画面は、ユーザが合言葉を購入代行サーバ2に登録するためのものである。
図11に示すとおり、ユーザは、購入補助端末3を操作して、合言葉をテキストデータで入力する。入力する合言葉は、複数あってもよい。合言葉登録画面を介して購入補助端末3に合言葉(テキストデータ)が入力されると、購入補助端末3のUI処理部521は、クライアントIDとともに上記テキストデータを購入代行サーバ2に送信する。購入代行サーバ2は、受信したテキストデータを合言葉DB32に格納する。
なお、購入代行サーバ2の購入代行部22は、買い物メモの作成に係る対話が行われる前であっても、合言葉と品名とが発話されていれば、該品名に対応する商品の購入代行処理を実行できる。これにより、ユーザは、合言葉を発話することによって、定常商品の購入に際し、冷蔵庫との対話(買い物メモ作成のためのやりとり)をスキップして、すぐに定常商品の購入を冷蔵庫1aに指示することができる。
図12は、ユーザ登録を行うためのUIの別の一具体例を示す。特に、図12は、購入補助端末3に表示される定常商品設定画面を示す。定常商品設定画面は、ユーザが、定常商品を選択し、その定常商品の商品正式名および個数を購入代行サーバ2に対して指定するためのものである。
図12に示される定常商品設定画面は、購入代行サーバ2の要求処理部23が、定常商品リストDB33に記憶されている、定常設定可能品目を示すテーブル(図5の(a))を参照して作成する。
UI処理部521が定常商品設定画面を処理することにより以下が実現される。ユーザは、品名に対応する左のカラムにチェックを入れることで、定常商品に設定したい商品を選択することができる。品名にチェックを入れると、1品名につき、1つの商品正式名にチェックを入れて指定することができる。商品正式名のチェックは、1品名につき、1つにしか入れることができないように、UI処理部521が排他的に制御している。UI処理部521は、品名にチェックが入っていない場合には、商品正式名を選択することができないように制御し、そのことが視覚的に分かるように、品名未選択の商品正式名のチェックボックスを非表示あるいは目立たなくしてもよい。また、UI処理部521は、商品正式名が1つ選択された場合には、選択された商品正式名を強調表示して、その他の商品正式名が選択されていないことを視覚的に表現してもよい。さらに、UI処理部521は、品名と商品正式名とがチェックされたレコードにおいては、個数を自由に変更することができるような入力セルを設ける。ここで、さらに配達希望日時(曜日)などを指定できるカラムを設けてもよい。
品名および商品正式名にチェックが入り、個数が入力された状態で、設定終了ボタン(不図示)が押下されると、UI処理部521は、選択された品名、および、それに対応付けて指定された商品正式名および個数を、クライアントIDとともに購入代行サーバ2に送信する。購入代行サーバ2は、受信した情報を定常商品リストDB33に格納する(図5の(b))。
図13の(a)〜(d)および図14は、購入補助端末3に表示される買い物メモ作成画面を示す。買い物メモ作成画面は、ユーザが、購入を予定している商品および個数をリストアップするためのものである。
本実施形態では、買い物メモの作成は、冷蔵庫1aとの対話のみによって作成することが可能である。しかし、図13の(a)〜(d)に示すとおり、ユーザは、必要に応じて、対話によって作成進行中の買い物メモを購入補助端末3に表示させることも可能である。音声制御部21が解析したテキストデータに品名が含まれている場合、音声要求処理部24は、買い物メモDB36にその品名に対応する商品のレコードを追加する。要求処理部23は、購入補助端末3から買い物メモ作成画面を要求するリクエストを受け付けた場合、対話ログDB31および買い物メモDB36を参照して、図13の(a)〜(d)に示すような買い物メモ作成画面を生成し、購入補助端末3に供給する。冷蔵庫1aの「他には何かある?」の問いかけに対して、ユーザが、買い物メモの作成を終了させる旨の発話(「おわり」など)を行うと、音声要求処理部24は、買い物メモDB36に完成した買い物メモを格納して買い物メモの作成処理を終了する。そして、冷蔵庫1aは、買い物メモに登録した商品の購入を促すメッセージを購入代行サーバ2の制御下で出力する。
さらに、本実施形態では、図14に示すとおり、買い物メモ作成画面は、リストアップした商品を購入するように購入代行サーバ2に対して指示するための購入支援ツールとしても機能する。買い物メモが完成すると、要求処理部23は、図14に示す買い物メモ作成画面を生成して、購入補助端末3に供給する。完成した買い物メモを表示する買い物メモ作成画面には、購入を促すメッセージが、冷蔵庫1aのキャラクターのイラストとともに表示されてもよい。
UI処理部521は、図14に示すとおり、買い物メモにおいて登録された品名ごとに、ユーザが購入フラグのON/OFFを設定できるようなチェックボックスを設けるとともに、購入代行サーバ2に対して購入を指示するための購入確定ボタンを設ける。UI処理部521は、一般商品について、商品正式名が指定されず品名だけが音声で登録されたレコード(図14の例では品名「ヨーグルト」)については、商品正式名および個数が特定できず注文ができないため、購入フラグを「ON」にできないようにUIを制御する。
1つ以上の商品について購入フラグが「ON」の状態で、購入確定ボタンが押下されると、UI処理部521は、購入フラグが「ON」の商品の品名または商品正式名を購入代行サーバ2に送信し、その商品の購入を購入代行サーバ2に対して要求する。
さらに、要求処理部23は、商品正式名を指定する必要があるレコード、すなわち、品名しか特定されていない一般商品のレコードについて、ユーザが商品正式名を指定するための商品指定画面を生成し、購入補助端末3に供給する。
図15の(a)〜(d)は、購入補助端末3に表示される商品指定画面を示す。購入代行サーバ2の音声制御部21は、一般商品について、品名のみが発話された場合、購入補助端末3の商品指定画面を見るように促すメッセージを冷蔵庫1aに出力させる。
UI処理部521は、要求処理部23によって供給された商品指定画面を介して、発話された品名に対応する複数の商品正式名の候補を選択可能に提示する(図15の(c))。ユーザは、単にチェックを入れる操作を行うだけでよい。これにより、ユーザは、具体的にどの商品を意図しているのかについて、その商品正式名を知らなくとも、購入代行サーバ2に対して指定することができる。
所望の商品正式名にチェックを入れた状態でユーザが購入確定ボタンを押下すると、UI処理部521は、選択された商品正式名をクライアントIDとともに購入代行サーバ2に送信し、その商品の購入を要求する。なお、購入補助端末3に表示された買い物メモを介して購入活動が行われる場合、合言葉は要求されない。購入補助端末3の認証は、必要に応じて従来技術を用いて実行される。
なお、一般商品のリストが含まれた画面(例えば、図15の(c))は、要求処理部23が、店舗サーバ4から得られる商品の情報と、記憶部13に記憶されている情報とに基づいて作成するものである。店舗サーバ4によって提供される商品の一覧画面が購入補助端末3にそのまま転送されるわけではない。なお、定常商品と一般商品との区別、および、品名と商品正式名との対応関係は、購入代行サーバ2と店舗サーバ4とによって共有されている。これにより、購入代行サーバ2は、商品指定画面を、店舗サーバ4が保持する商品リストを参照して作成することができる。
さらに、図16の(a)〜(c)に示すとおり、要求処理部23は、購入確定ボタンが押下されたことに応答して一度発注を完了させると、購入履歴DB35を参照して、ユーザにおすすめすべき商品を選択して、購入を促す購入誘導画面を生成してもよい。図16の(a)に示すとおり、購入誘導画面には、対話の相手である冷蔵庫1aのキャラクターからのおすすめメッセージが含まれていてもよい。さらに、図16の(d)に示すとおり、要求処理部23は、購入確定ボタンが押下されたことに応答して一度発注を完了させると、その発注が完了した商品の配達予定日時を通知する配達予定日通知画面を生成してもよい。配達予定日は、発注品特定部222によって特定されてもよいし、発注部224による注文を受け付けた店舗サーバ4から通知されてもよい。
さらに、図17の(a)および(b)に示すとおり、要求処理部23は、購入履歴DB35を参照して、購入履歴画面を生成して購入補助端末3に供給してもよい。購入補助端末3が表示する購入履歴画面には、発注が完了した商品の現在のステータスが含まれていることが好ましい。また、ユーザは、購入履歴画面を操作して、ステータスを更新することが可能である。具体的には、ユーザは、注文した商品が届くと、届いた商品のレコードに対して配達完了のチェックを入れて、「届いたよ!」と記載された配達完了ボタンを押下する。UI処理部521は、チェックが入った品名の商品の配達が完了したことを示す情報を購入代行サーバ2に送信する。要求処理部23は、上記情報を受信したことに応答して、購入履歴DB35において、チェックが入った品名のレコードについて、ステータスを「配達完了」に更新する。
以上、実施形態1に係る購入代行システム100の各装置の構成および購入代行処理の方法について説明した。上記構成および方法によれば、ユーザは、商品の一般名詞など、単純な言葉を冷蔵庫1aに対して音声入力するだけで、簡単に、当該商品の購入活動を実施することができる。すなわち、店舗サーバ4に注文する際に必要な情報(商品正式名、個数、発注先および配達日時など)は、ユーザによって発話された上記品名に基づいて購入代行サーバ2が特定するので、ユーザは、商品の品名を発話するだけで済む。
このように、本発明の購入代行システム100は、ユーザが最低限実行しなければならない購入のために必要な工程(購入希望商品を指定する工程)を、簡易な入力手段(音声入力)で実現し、その他の購入活動ための複雑な操作を購入代行サーバ2が代行することで、結果として、ユーザが簡易に購入活動を行うことを可能にする。
また、購入のために必要な工程を実施するための簡易な入力手段(音声入力)は、冷蔵庫1aなどの家庭内機器に設けられている。したがって、家庭内での生活の導線に沿って、適切なタイミングで購入活動を促すことができる。具体的には、冷蔵庫1aを使用し、必要な食材の取り出し、在庫の確認、買い物メモの作成などを行っているその場で、冷蔵庫1aを使って購入活動を実施することができる。結果として、ユーザが購入の機会を逃すことがなくなる。
さらに、本発明の購入代行システム100によれば、冷蔵庫1aと通信する購入代行サーバ2において、冷蔵庫1aとユーザとの対話ログ、作成された買い物メモ、購入履歴)が蓄積される構成である。これにより、マーケティングの観点から利用価値の高い情報が手に入るというメリットがある。
〔実施形態2〕
本発明の他の実施形態について、図18、図19に基づいて説明すれば、以下のとおりである。なお、説明の便宜上、前記実施形態にて説明した部材と同じ機能を有する部材については、同じ符号を付記し、その説明を省略する。
本実施形態では、図2に示す購入代行システム100において、1つの定常商品について発注先の店舗が複数存在し、固定されていない。そのため購入代行サーバ2は、定常商品の購入を代行するとき、動的に発注先の店舗(店舗サーバ4)を選択する必要がある。
実施形態2の購入代行サーバ2において、実施形態1の購入代行サーバ2と異なる点は、購入代行部22が発注先選択部223を含んでいる点である。発注先選択部223は、発注品特定部222によって特定された商品(および個数)を購入可能な店舗が複数ある場合に、所定の条件にしたがって発注先の店舗を1つ選択する。発注先選択部223は、店舗情報DB34を参照したり、各店舗サーバ4とやりとりして店舗サーバ4の最新の情報を取得したりして、上記条件に最も合致する店舗を発注先として1つ選択する。
例えば、「販売価格が最も安いこと」という条件が事前に規定されている場合、発注先選択部223は、各店舗の店舗サーバ4から最新の商品価格表を取得し、発注時に販売価格が一番安い店舗を選択する。あるいは、「配達日が最も早いこと」という条件が規定されている場合、発注先選択部223は、各店舗サーバ4から配達予定日を取得して、配達予定日が最も早い店舗を選択してもよい。さらには、これらの条件の組み合わせにしたがって、販売価格と配達予定日とを総合的に考慮して最も好ましい条件の店舗を選択してもよい。例えば、ユーザに、購入補助端末3を介して、「節約モード」および「お急ぎモード」のいずれかを選択させておく。発注先選択部223は、「節約モード」が設定されている場合、販売価格の安さを最も重要視して店舗を選択し、「お急ぎモード」が設定されている場合、配達日の早さを最も重要視して店舗を選択する。発注先選択部223は、複数の商品がまとめて発話された場合でも、より条件のよい発注先を求めて、個々の商品ごとに発注先を選択することができる。
上記構成によれば、発注先選択部223が条件に基づいて発注先を商品ごとに選択してくれる。したがって、発注先が複数あっても、ユーザは、1つの買い物リストと1つの合言葉を使って、発注先の多様性を意識することなく、1回の購入活動で、欲しい商品をより好条件にて全て注文することができる。
あるいは、発注先選択部223は、複数の商品をまとめて1つの店舗に注文する場合、複数の商品の販売価格合計、または、全商品の中で最も遅い配達予定日に基づいて、最もよい条件の店舗を選択することができる。
1:定常商品を第1のルート(音声入力)を介して購入する場合
図18の(a)および(b)を参照して、具体例を用いて発注先選択部223の機能を説明すると以下のとおりである。冷蔵庫1aとの対話で、ユーザが「たまご」と「牛乳」とを購入することが判明したとする。ここで、発注品特定部222は、上記品名に基づいて、上記ユーザについて「たまご」および「牛乳」の商品正式名(商品ID)をそれぞれ特定する。
「販売価格が最も安いこと」という条件が規定されている場合、発注先選択部223は、特定された商品正式名(商品ID)について、各店舗の販売価格を取得する。販売価格は、記憶部13にあらかじめ記憶されている店舗ごとの商品DB(不図示)から取得されてもよいし、各店舗の店舗サーバ4に対して、商品正式名(商品ID)を送信して問合せを行い、最新の販売価格を取得してもよい。
発注先選択部223は、各店舗における「たまご」および「牛乳」の販売価格を取得すると、その販売価格合計を店舗ごとに比較する。例えば、発注先選択部223は、図18の(a)に示すとおり、発注日現在の価格比較表を生成してもよい。図18の(a)に示す例では、発注日(2015/12/25)現在、「たまご」および「牛乳」の販売価格合計が最も安いのは「スーパーB」となる。そこで、発注先選択部223は、上記ユーザの「たまご」および「牛乳」の発注先として、「スーパーB」を選択する。発注先選択部223が選択した店舗の店舗IDは、発注部224に伝達される。発注部224は、発注先選択部223が選択した店舗に対して、「たまご」および「牛乳」を発注する。
なお、「配達日が最も早いこと」という条件が規定されている場合、発注先選択部223は、各店舗サーバ4に、商品正式名(商品ID)を送信して配達予定日の問合せを行い、各商品の配達予定日を取得する。ここで、以下の配達予定日を各店舗の店舗サーバ4から受信したとする。
スーパーA:たまご「当日」、牛乳「明日」
スーパーB:たまご「明日」、牛乳「明日」
スーパーC:たまご「当日」、牛乳「当日」
この場合、すべて商品を最も早く配達できるのは、「スーパーC」であるので、発注先選択部223は、「たまご」および「牛乳」の発注先として、「スーパーC」を選択する。
さらに、「たまご」と「牛乳」とに続けて「ヨーグルト」が発話され、この3つの商品を購入することが判明したとする。「販売価格が最も安いこと」という条件が規定されている場合、発注先選択部223は、図18の(b)に示す価格比較表を生成する。該価格比較表によれば、3つの商品の販売価格合計が最も安いのは「スーパーA」である。そこで、発注先選択部223は、上記ユーザの「たまご」、「牛乳」および「ヨーグルト」の発注先として、「スーパーB」を選択する。
2:商品を第2のルート(購入補助端末3の画面操作)を介して購入する場合
図19の(a)および(b)を参照して、具体例を用いて発注先選択部223の機能を説明すると以下のとおりである。ユーザが、購入補助端末3の買い物メモ作成画面を操作して、「たまご」、「牛乳」および「ヨーグルト」を購入する操作を行ったとする。「たまご」、「牛乳」および「ヨーグルト」の商品正式名は、発注品特定部222によって特定されるか、または、買い物メモ作成画面においてすでに指定されているものとする。
ここで、「販売価格が最も安いこと」という条件が規定されている場合、発注先選択部223は、第1のルートの場合と同様に、図18の(b)に示す価格比較表を生成してもよい。さらに、発注先選択部223は、販売価格合計が安い順に各店舗をソートして順位付けする。要求処理部23は、発注先選択部223によって生成された価格比較表および順位付けにしたがって、店舗のランキング表示画面を生成する。
購入補助端末3のUI処理部521は、図19の(a)に示すとおり、要求処理部23から供給されたランキング表示画面を、店舗を選択可能なUIとして表示する。その際、UI処理部521は、「販売価格が最も安いこと」という条件に基づくランキングであることを視覚的に明示することが好ましい。例えば、節約モードを意味する「節約」タブを付けることが考えられる。
一方、「配達日が最も早いこと」という条件が規定されている場合、発注先選択部223は、第1のルートの場合と同様に、各店舗に各商品の配達予定日を問い合わせる。そして、1つの店舗につき、すべての商品の中で最も遅い配達予定日を、その店舗の最終配達予定日として決定する。続いて、発注先選択部223は、最終配達予定日が早い順に各店舗をソートして順位付けする。要求処理部23は、発注先選択部223によって決定された最終配達予定日の順位付けにしたがって、店舗のランキング表示画面を生成する。
購入補助端末3のUI処理部521は、図19の(b)に示すとおり、要求処理部23から供給されたランキング表示画面を、店舗を選択可能なUIとして表示する。その際、UI処理部521は、「配達日が最も早いこと」という条件に基づくランキングであることを視覚的に明示することが好ましい。例えば、お急ぎモードを意味する「お急ぎ」タブを付けることが考えられる。
上記構成によれば、ユーザは、購入補助端末3を操作して、自分にとって最も条件のよい店舗を、購入代行サーバ2に対して指定することができる。ランキング表示画面において店舗が1つ指定されると、UI処理部521は、指定された店舗の店舗IDを、クライアントIDとともに購入代行サーバ2に送信する。発注先選択部223は、上記店舗IDを取得して、その店舗IDが示す店舗を発注先として選択する。
なお、店舗情報DB34において、店舗ごとに点数が管理されていてもよい。この場合、発注先選択部223は、発注先を選択する際に、上記点数が最も高い店舗を発注先として選択することが考えられる。上記点数は、各店舗が購入代行サーバ2に対して代金を支払うことにより加算されてもよい。つまり、店舗は、購入代行サーバ2が自店舗を発注先として優先的に選択することの見返りに、購入代行サーバ2に対して対価(広告料)を払うという、ビジネスモデルが構築される。
〔実施形態3〕
本発明の他の実施形態について、以下のとおり説明する。なお、説明の便宜上、前記実施形態にて説明した部材と同じ機能を有する部材については、同じ符号を付記し、その説明を省略する。
上述の各実施形態では、定常商品を設定するために、ユーザが、購入補助端末3に表示された定常商品設定画面(図12)を操作する方法が提供された。本実施形態では、音声入力によって、より簡易に、定常商品を設定する方法を提示する。
実施形態3では、音声要求処理部24は、購入履歴DB35を参照し、購入された回数が所定条件を満たした一般商品を検出する。条件を満たした一般商品を検出した場合、その一般商品を定常商品として設定することを提案するように、音声制御部21に対して指示する。
音声制御部21は、音声要求処理部24からの指示にしたがって機器発話データを生成し、冷蔵庫1aに供給し、定常商品として設定することを提案する発話を冷蔵庫1aに行わせる。
例えば、音声要求処理部24は、購入履歴DB35を参照して、同一の商品正式名の商品が、同一個数で購入された回数が所定数(例10回)を超えている商品およびその購入個数を特定する。具体例を挙げると、音声要求処理部24は、あるユーザについて、商品正式名「栄養卵ひかり M玉 10個パック」が「2個」購入された回数が、11回であることを検出する。音声要求処理部24は、定常商品リストDB33のテーブル(図5の(a)を参照し、「栄養卵ひかり M玉 10個パック」に対応する品名「たまご」を特定する。音声要求処理部24は、商品正式名「栄養卵ひかり M玉 10個パック」および個数「2個」を、品名「たまご」として定常商品化することを、上記ユーザに提案するよう音声制御部21に依頼する。
音声制御部21は、例えば、「栄養卵ひかり M玉 10個パックを2個、いつも買っているね!この商品は、『たまご』で、定常商品に設定することができるよ!設定する?」という機器発話データを生成し、上記ユーザの冷蔵庫1aに発話させる。
この発話に応答して、例えば、ユーザが「OK!」と発話すると、音声制御部21は、上記提案が受け入れられたと判断する。音声要求処理部24は、提案が受け入れられたと判断された場合に、先に特定しておいた、商品正式名「栄養卵ひかり M玉 10個パック」および個数「2個」を、品名「たまご」に対応付ける。そして、音声要求処理部24は、定常商品リストDB33のテーブル(図5の(b))において、上記ユーザのクライアントIDに関連付けて、上記の品名、商品正式名および個数を新規に登録する。
上記構成によれば、ユーザは、自身が頻繁に購入している商品について、「OK!」という発話1つで簡易に定常商品の設定を行うことができる。ユーザは、自身がどんな商品をどれくらいの頻度で購入しているのかを意識する必要もなければ、購入補助端末3にて定常商品設定画面を呼び出して、自発的に定常商品を設定するための操作を行う必要もない。結果として、より一層利便性の高い購入代行システムを実現することができる。
定常商品化を提案するときの購入回数の条件は、上記に限定されない。音声要求処理部24は、例えば、所定期間(3カ月)に所定回数(4回)以上、同じ商品が同じ個数で購入された場合に、定常商品化を提案してもよい。あるいは、音声要求処理部24は、購入タイミングが周期的である商品について、定常商品化を提案してもよい。
なお、購入代行サーバ2は、購入補助端末3の操作画面を介して、一般商品の定常商品化を提案することも可能である。この場合、例えば、図17の(a)または(b)に示す購入履歴画面において、同図の「般」のアイコンが付与されている(一般商品の)レコードに「定常化ボタン」を追加すればよい。該定常化ボタンが押下されると、購入補助端末3のUI処理部521は、定常化ボタンが押された商品を特定する情報を購入代行サーバ2の要求処理部23に通知する。これにより、要求処理部23は、購入回数に関係なく、一般商品から定常商品への設定変更を実行する。このようにすれば、ユーザは、比較的簡易な操作で、一般商品から定常商品への設定変更を行うことが可能となる。
〔変形例〕
上述の各実施形態では、購入代行システム100は、購入補助端末3を含んでいるが必須ではない。本発明の購入代行システム100において、ユーザは、購入補助端末3に表示される画面を確認したり、操作したりせずとも、冷蔵庫1aとの対話によってのみ、定常商品の購入活動を実行したり、定常商品の買い物メモを作成したりすることができる。
上述の各実施形態では、購入代行サーバ2は、買い物メモ機能(要求処理部23および買い物メモDB36)を備えているが、必須ではない。購入代行部22は、買い物メモDB36に商品が登録されていなくとも、対話ログDB31において、ユーザが品名を発話したことを検知したことに基づいて、購入代行処理を実行することができる。
上述の各実施形態では、購入代行装置1として、冷蔵庫1aを想定しているが、購入代行装置1としての家電は、家庭内に複数あってもよい。例えば、冷蔵庫1aに加えて電子レンジ1bが購入代行装置として設けられていてもよい。この場合、電子レンジ1bに記憶されているレシピ情報に基づいて、電子レンジ1bとの対話によって、必要な食材の買い物メモが作成されたり、購入代行処理が実行されたりする。なお、家庭内に購入代行装置1としての家電が複数設けられる場合には、これらの家電と、購入代行サーバ2とのやりとりを仲介して取りまとめを行うホームサーバが設置されることが望ましい。
上述の各実施形態では、セキュリティの観点から、ユーザの購入意思を意味する所定のキーワード(合言葉など)が発話されない限り、発注部224は発注を行わない構成である。しかし、利便性を高める観点から、品名が発話されたことをもってその商品の発注が実行されるように購入代行部22を構成することも可能である。ただし、品名と所定のキーワードとが発話された場合に発注する構成であれば、ユーザが購入希望と無関係に品名を口にしたときに、誤って商品が発注されることを防ぐことができるのでより好ましい。
なお、購入代行処理は、冷蔵庫1aと同様にホームネットワークに接続されている他の家電(例えば、テレビ)と連携して、動的に実行されてもよい。例えば、「今テレビで放送されていた商品がほしい」というユーザの発話に対応して、発注品特定部222が、ユーザ所望の商品の商品識別情報を特定できてもよい。また、データ放送で表示されたパスワードを、購入を確定させるための合言葉として利用してもよい。
上述の各実施形態において、第1のルート、すなわち、冷蔵庫1aへの音声入力によって、購入活動が実施される場合、購入代行サーバ2は、発注を完了させる直前に、冷蔵庫1aに、購入予定の商品正式名、個数、および、価格を復唱させて、発注の了解を得ることが好ましい。さらには、購入代行サーバ2は、最終的に注文を確定させるボタンを、購入補助端末3に表示させて、その画面を見るようにユーザを誘導するメッセージを冷蔵庫1aに発話させてもよい。ユーザが上記画面にて上記ボタンを押下することにより、発注部224が発注を完了させる。
上述の各実施形態では、対話機能(音声制御部21の音声解析部および音声生成部、ならびに、音声フォーマット、辞書など)のすべてを購入代行サーバ2が備えている構成であった。しかし、本発明の購入代行システム100において、対話機能は、全て冷蔵庫1aに設けられていてもよいし、購入代行サーバ2および冷蔵庫1aに分散して設けられていてもよい。例えば、冷蔵庫1aには、簡易的な対話機能を搭載し、当該対話機能で対応できない場合に、購入代行サーバ2の対話機能が対話を制御することが考えられる。
上述の各実施形態では、発注部224が発注を行う相手は、1店舗に対応する1つの店舗サーバ4である。しかし、発注先の店舗の形態はこれに限定されない。例えば、発注部224が発注を行う相手は、ショッピングモールや商店街などのような複数の店舗の集合体に対応する1台のサーバであってもよい。この場合、決済は、店舗単位で行われず、上記集合体単位で実行される。
なお、店舗サーバ4は、EC事業者または配達業者などが所有する他のサーバと連携し、購入代行サーバ2から受け付けた発注商品の配達を、上記他のサーバを介して、EC事業者または配達業者などに委託してもよい。
〔実施形態4〕
上記各実施形態では、1つの購入代行サーバ2を用いる例を説明したが、購入代行サーバ2の有する各機能が、個別のサーバにて実現されていてもよい。そして、複数のサーバを適用する場合においては、各サーバは、同じ事業者によって管理されていてもよいし、異なる事業者によって管理されていてもよい。
〔実施形態5〕
購入代行装置1、購入代行サーバ2および購入補助端末3の各ブロックは、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェアによって実現してもよい。後者の場合、購入代行装置1、購入代行サーバ2および購入補助端末3のそれぞれを、図20に示すようなコンピュータ(電子計算機)を用いて構成することができる。
図20は、購入代行装置1、購入代行サーバ2または購入補助端末3として利用可能なコンピュータ910の構成を例示したブロック図である。コンピュータ910は、バス911を介して互いに接続された演算装置912と、主記憶装置913と、補助記憶装置914と、入出力インターフェース915と、通信インターフェース916とを備えている。演算装置912、主記憶装置913、および補助記憶装置914は、それぞれ、例えばCPU、RAM(random access memory)、ハードディスクドライブであってもよい。入出力インターフェース915には、ユーザがコンピュータ910に各種情報を入力するための入力装置920、および、コンピュータ910がユーザに各種情報を出力するための出力装置930が接続される。入力装置920および出力装置930は、コンピュータ910に内蔵されたものであってもよいし、コンピュータ910に接続された(外付けされた)ものであってもよい。例えば、入力装置920は、キーボード、マウス、タッチセンサなどであってもよく、出力装置930は、ディスプレイ、プリンタ、スピーカなどであってもよい。また、タッチセンサとディスプレイとが一体化されたタッチパネルのような、入力装置920および出力装置930の双方の機能を有する装置を適用してもよい。そして、通信インターフェース916は、コンピュータ910が外部の装置と通信するためのインターフェースである。
補助記憶装置914には、コンピュータ910を購入代行装置1、購入代行サーバ2または購入補助端末3として動作させるための各種のプログラムが格納されている。そして、演算装置912は、補助記憶装置914に格納された上記プログラムを主記憶装置913上に展開して該プログラムに含まれる命令を実行することによって、コンピュータ910を、購入代行装置1、購入代行サーバ2または購入補助端末3が備える各部として機能させる。なお、補助記憶装置914が備える、プログラム等の情報を記録する記録媒体は、コンピュータ読み取り可能な「一時的でない有形の媒体」であればよく、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブル論理回路などであってもよい。
また、上記プログラムは、コンピュータ910の外部から取得してもよく、この場合、任意の伝送媒体(通信ネットワークや放送波等)を介して取得してもよい。そして、本発明は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
〔まとめ〕
本発明の態様1に係るシステム(購入代行システム100)は、ネットワークを介して商品を注文するシステムであって、上記システムは、以下を含む;購入者(ユーザ)が行った発話を音声データとして取得する音声入力部(マイク43)、取得された上記音声データ(ユーザ発話データ)から、購入を希望する商品の品名が発話されたことを検知する検知部(購入代行部22)、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部(記憶部13の定常商品リストDB33)、上記記憶部から、検知された上記品名に対応付けられた商品識別情報(商品正式名/商品ID)を特定する特定部(発注品特定部222)、少なくとも特定された上記商品識別情報を上記発注先サーバ(店舗サーバ4)に送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部(発注部224)。
上記の構成によれば、音声入力部が、購入者の発話を音声データとして取得し、検知部が、音声データから、購入を希望する商品の品名が発話されたことを検知する。特定部は、発話された品名から、その品名の商品識別情報を特定する。特定部は、記憶部を参照することにより品名から商品識別情報を特定することができる。記憶部には、購入者ごとに、品名に対応付けて商品識別情報が記憶されているからである。発注部は、特定部によって特定された商品識別情報を発注先サーバに送信することにより、購入者が発話した商品を発注先に注文する。発注先サーバには、品名ではなく、商品識別情報が送信されるので、発注先サーバは、購入者に提供すべき商品を一意に識別することが可能である。
以上のとおり、発注先サーバに対して購入希望商品を正確に指定するまでの間に、購入者がしなければならないことは、購入を希望する商品の品名を発話することのみである。こうして本発明のシステムは、電子商取引における購入活動のうち、購入者が実行せざるを得ない購入希望商品を指定するという作業を、音声入力という簡易な入力手段で実現する。当該システムは、その後の作業に関し、発注先サーバに対する発注を誤りなく代行する(購入希望商品を正確に発注先に指定する)。結果として、購入者が簡易に購入活動を行うことを可能にする、利便性の高い購入代行システムを実現することができる。
本発明の態様2に係るサーバ(購入代行サーバ2)は、ネットワークを介して商品を注文するサーバであって、上記サーバは、以下を含む;購入者が行った発話の音声データから、購入を希望する商品の品名が発話されたことを検知する検知部、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部、上記記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定部、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部。上記の構成によれば、態様1に係るシステムと同様の効果を奏する。
本発明の態様3に係るサーバは、上記態様2のサーバにおいて、上記検知部は、上記品名とともに、購入者の購入の意思を意味する所定のキーワードが発話されたことを検知し、上記発注部は、上記キーワードが検知された場合に注文する。上記の構成によれば、購入者が購入希望と無関係に品名を口にしたときに、誤って商品が発注されることを防ぐことができる。
本発明の態様4に係るサーバは、上記態様2または3において、以下を含む;上記購入者を認証する認証部、上記記憶部には、購入者と所定の合言葉とが対応付けて記憶されており、上記認証部は、購入者によって発話された合言葉と、上記記憶部において上記購入者に対応付けられた合言葉とが一致する場合に、上記発注部に対して注文することを許可する。
上記の構成によれば、サーバに対して購入を指示できるのは、合言葉を知る者だけに限定される。したがって、商品を購入する権限を持つ者のみが知り得る合言葉を用いることにより、商品を購入する権限を持たない者の発話によって誤って商品が発注されることを防ぐことができる。
本発明の態様5に係るサーバは、上記態様2から4のいずれかにおいて、上記記憶部には、購入者ごとに、品名に、商品の個数がさらに対応付けて記憶されており、上記特定部は、さらに、個数を特定し、上記発注部は、特定された上記商品識別情報および個数を上記発注先サーバに送信する。
上記の構成によれば、特定部は、発話された品名から、その品名の商品識別情報に加えて、購入個数を特定する。特定部は、記憶部を参照することにより品名から商品識別情報および個数を特定することができる。記憶部には、購入者ごとに、品名に対応付けて、商品識別情報に加えてさらに個数が記憶されているからである。発注部は、特定部によって特定された商品識別情報および個数を発注先サーバに送信することにより、購入者が発話した商品を発注先に注文する。発注先サーバには、商品識別情報に加えて個数が送信されるので、発注先サーバは、購入者に提供すべき商品とその個数を把握することができる。結果として、購入者が簡易に購入活動を行うことを可能にする、より利便性の高い購入代行システムを実現することができる。
本発明の態様6に係るサーバは、上記態様2から5のいずれかにおいて、上記記憶部には、購入者ごとに、品名に、発注先がさらに対応付けて記憶されており、上記発注部は、検知された上記品名に対応付けられた発注先に注文する。
上記の構成によれば、特定部は、発話された品名から、さらに発注先を特定する。特定部は、記憶部を参照することにより、品名から、商品識別情報、個数および発注先を特定することができる。記憶部には、購入者ごとに、品名に対応付けて、商品識別情報および個数に加えてさらに発注先が記憶されているからである。発注部は、特定部によって特定された商品識別情報および個数を、特定部によって特定された発注先の発注先サーバに送信することにより、購入者が発話した商品を注文する。これにより、購入者が意図する決まった発注先に注文を送ることが可能となる。結果として、購入者が簡易に購入活動を行うことを可能にする、より利便性の高い購入代行システムを実現することができる。
本発明の態様7に係るサーバは、上記態様2から6のいずれかにおいて、以下を含む;上記特定部によって特定された商品識別情報が示す商品の発注先を選択する選択部(発注先選択部223)、上記選択部は、複数の発注先の中から、上記商品を提供可能な発注先を選択し、上記発注部は、上記選択部によって選択された発注先に注文する。
上記の構成によれば、発注先が複数あって、特に、購入者によって発注先が指定されていない場合でも、選択部が、複数の発注先の中から、購入すべき商品を提供可能な発注先を選択することができる。なお、提供可能な発注先がさらに複数存在する場合には、選択部は、条件が最も良い発注先を選択してもよい。例えば、販売価格が最安値の発注先、または、配達予定日が最先の発注先を選んでもよい。結果として、購入者が簡易に購入活動を行うことを可能にする、より利便性の高い購入代行システムを実現することができる。
本発明の態様8に係るサーバは、上記態様2から7のいずれかにおいて、以下を含む;上記購入者が購入を希望する商品および個数を指定するための購入画面(買い物メモ作成画面)を生成する生成部(要求処理部23)、上記発注部は、上記購入画面を表示して上記購入者の操作を受け付ける端末(購入補助端末3/スマートフォン)から受信した、上記購入者によって指定された商品の商品識別情報および個数を、上記発注先サーバに送信することにより、上記購入者が購入を希望する商品を、発注先に注文する。
上記の構成によれば、サーバは、記憶部に品名が登録されていない商品(一般商品)について、音声入力を介しての購入指示は受け付けられないが、端末に表示される購入画面を介して、購入者の購入活動を支援することが可能となる。購入者は、音声入力によって簡易に購入活動を実施したい場合と、購入画面を操作して、詳細な内容を自ら指定して購入活動を実施したい場合とで、これらの購入ツールを使い分けることができる。
本発明の態様9に係るサーバは、上記態様8において、以下を含む;上記購入者と対話する装置(購入代行装置1、冷蔵庫1a、電子レンジ1b)に、上記購入画面を介して購入された商品の品名を発話させて、上記記憶部への登録を促す音声制御部(音声制御部21)、上記装置による上記発話に対して、上記購入者が登録に同意する旨の発話したことが、上記検知部によって検知された場合に、上記品名と該品名に対応する商品識別情報とを、上記購入者に対応付けて上記記憶部に登録する登録部(音声要求処理部24)。
上記の構成によれば、購入画面を介して商品が購入された場合に、音声制御部は、今後その商品を、音声入力のみで簡易に購入することができるように、記録部への登録を購入者に促す。購入者が登録に同意すれば、登録部は、その購入者に対応付けて、上記商品の品名と商品識別情報とを上記記憶部に登録する。
これにより、購入者は、一度購入画面を操作して購入した商品について、音声入力だけで、簡易に、記憶部に登録することができる。記憶部にその商品が登録されたということは、これ以後、当該商品については購入画面を操作せずとも、音声入力だけで購入活動を実施することができるということを意味する。結果として、購入者が簡易に購入活動を行うことを可能にする、より利便性の高い購入代行システムを実現することができる。
本発明の態様10に係る装置(購入代行装置1、冷蔵庫1a、電子レンジ1b)は、ネットワークを介して商品を注文するサーバと通信する装置であって、上記サーバは、以下を含む;購入者が行った発話の音声データから、購入を希望する商品の品名が発話されたことを検知する検知部、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部、上記記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定部、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部、上記装置は、以下を含む;上記装置が出力する発話の音声データ(機器発話データ)を上記サーバから受信する受信部(通信部41)、上記受信部によって受信された上記音声データを出力する音声出力部(スピーカ44)、購入者が行った発話を音声データ(ユーザ発話データ)として取得する音声入力部(マイク43)、上記音声入力部によって取得された上記音声データを上記サーバに送信する送信部(通信部41)。
上記の構成によれば、上記システムのうち、購入者の発話を受け付ける音声入力部の機能をサーバとは別の装置が担う。これにより、購入者は、購入希望商品を指定するという作業(音声入力)を、購入者の身近に設置され使用されている装置を用いて実施することができる。したがって、ユーザが購入の機会を逃すことなく、簡易に購入活動を行うことを可能にする、より利便性の高い購入代行システムを実現することが可能となる。
本発明の態様11に係る装置は、上記態様10において、冷蔵庫(1a)であって、さらに以下を含む;冷蔵庫のドアの開閉を検知する開閉センサ部(開閉センサ46)、上記音声入力部は、上記開閉センサ部によってドアの開閉が検知された場合に、上記購入者が行った発話を音声データとして取得する。
これにより、ユーザが冷蔵庫を使用しているときに、冷蔵庫に対して音声を入力することで、簡単に、商品の購入を、装置およびサーバに対して指示することができる。冷蔵庫を使用(ドアを開閉)しているときは、ユーザが、在庫の不足に気づいたりして、購買意欲が最も高まっているときであると考えられる。このように、ユーザが冷蔵庫を使用しているときに、音声入力による購入作業を可能にすることにより、ユーザが購入の必要性を失念したり、気が変わったりして、購入の機会を逃す虞がなくなる。
本発明の態様12に係る端末(購入補助端末3、スマートフォン)は、ネットワークを介して商品を注文するサーバと通信する端末であって、上記サーバは、以下を含む;購入者が行った発話の音声データから、購入を希望する商品の品名が発話されたことを検知する検知部、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部、上記記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定部、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部、上記購入者が購入を希望する商品および個数を指定するための購入画面を生成する生成部、上記端末は、以下を含む;上記購入画面を上記サーバから受信する受信部(通信部51)、上記受信部によって受信された上記購入画面を表示する表示部(55)、上記購入画面に対する操作を受け付けて、該操作によって指定された商品の商品識別情報および個数を特定するUI処理部(521)、特定された上記商品識別情報および上記個数を上記サーバに送信する送信部(通信部51)、上記サーバの上記発注部は、上記端末から受信した、上記商品識別情報および上記個数を上記発注先サーバに送信することにより、上記購入者が購入を希望する商品を、発注先に注文する。上記の構成によれば、態様8に係るサーバと同様の効果を奏する。
本発明の態様13に係るシステムの制御方法は、ネットワークを介して商品を注文するシステムの制御方法であって、上記システムの制御方法は、以下を含む;購入者が行った発話を音声データとして取得する音声取得ステップ(S2)、取得された上記音声データから、購入を希望する商品の品名が発話されたことを検知する検知ステップ(S102)、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定ステップ(S105)、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注ステップ(S107)。上記の方法によれば、態様1に係るシステムと同様の効果を奏する。
本発明の態様14に係るサーバの制御方法は、ネットワークを介して商品を注文するサーバの制御方法であって、上記サーバの制御方法は、以下を含む;購入者が行った発話の音声データから、購入を希望する商品の品名が発話されたことを検知する検知ステップ(S102)、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定ステップ(S105)、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した商品を、発注先に対して注文する発注ステップ(S107)。上記の方法によれば、態様2に係るサーバと同様の効果を奏する。
本発明の態様15に係るサーバは、上記態様2〜9のいずれかにおいて、以下を含む;検知部によって検知された品名を、上記記憶部(記憶部13の買い物メモDB36)に格納されている購入予定リスト(買い物メモ)に登録するリスト作成部(音声要求処理部24)、上記発注部は、所定時刻になると上記購入予定リストに登録された品名の商品を、発注先に注文する。
上記の構成によれば、音声入力によって購入予定リストに登録された品名に基づいて、商品識別情報などが特定部によって特定される。発注部は、特定された商品識別情報を所定時刻になると発注先サーバに送信する。
購入予定リストに登録された商品はすなわち購入希望商品である。したがって、態様2のサーバと同様に、発注先サーバに対して購入希望商品を正確に指定するまでの間に、購入者がしなければならないことは、購入を希望する商品の品名を発話することのみであることに変わりがない。結果として、購入者が簡易に購入活動を行うことを可能にする、利便性の高い購入代行システムを実現することができる。
本発明の各態様に係るサーバ、装置および端末は、コンピュータによって実現してもよく、この場合には、コンピュータを上記サーバ、装置または端末が備える各部(ソフトウェア要素)として動作させることにより上記サーバ、装置または端末をコンピュータにて実現させるサーバ、装置または端末の制御プログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。さらに、各実施形態にそれぞれ開示された技術的手段を組み合わせることにより、新しい技術的特徴を形成することができる。