(57)【特許請求の範囲】
【請求項１】
ネットワークを介して商品を注文するシステムであって、
上記システムは、以下を含む；
購入者が行った発話を音声データとして取得する音声入力部、
取得された上記音声データから、購入を希望する商品の品名が発話されたことを検知する検知部、
購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部、
上記記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定部、
少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部、
上記購入者を認証する認証部、
上記検知部は、上記品名に加えて、購入者の購入の意思を意味する所定のキーワードとしての合言葉が発話されたことを検知し、
上記記憶部には、購入者と所定の合言葉とが対応付けて記憶されており、
上記認証部は、購入者によって発話された合言葉と、上記記憶部において上記購入者に対応付けられた合言葉とが一致する場合に、上記発注部に対して注文することを許可し、
上記発注部は、上記認証部によって注文が許可された場合に注文する。
【請求項２】
ネットワークを介して商品を注文するサーバであって、
上記サーバは、以下を含む；
購入者が行った発話の音声データから、購入を希望する商品の品名が発話されたことを検知する検知部、
購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部、
上記記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定部、
少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部、
上記購入者を認証する認証部、
上記検知部は、上記品名に加えて、購入者の購入の意思を意味する所定のキーワードとしての合言葉が発話されたことを検知し、
上記記憶部には、購入者と所定の合言葉とが対応付けて記憶されており、
上記認証部は、購入者によって発話された合言葉と、上記記憶部において上記購入者に対応付けられた合言葉とが一致する場合に、上記発注部に対して注文することを許可し、
上記発注部は、上記認証部によって注文が許可された場合に注文する。
【請求項３】
請求項２に記載のサーバにおいて、
上記記憶部には、購入者ごとに、品名に、商品の個数がさらに対応付けて記憶されており、
上記特定部は、さらに、個数を特定し、
上記発注部は、特定された上記商品識別情報および個数を上記発注先サーバに送信する。
【請求項４】
請求項２または３に記載のサーバにおいて、
上記記憶部には、購入者ごとに、品名に、発注先がさらに対応付けて記憶されており、
上記発注部は、検知された上記品名に対応付けられた発注先に注文する。
【請求項５】
請求項２から４のいずれか１項に記載のサーバは、以下を含む；
上記特定部によって特定された商品識別情報が示す商品の発注先を選択する選択部、
上記選択部は、複数の発注先の中から、上記商品を提供可能な発注先を選択し、
上記発注部は、上記選択部によって選択された発注先に注文する。
【請求項６】
請求項２から５のいずれか１項に記載のサーバは、以下を含む；
上記購入者が購入を希望する商品および個数を指定するための購入画面を生成する生成部、
上記発注部は、上記購入画面を表示して上記購入者の操作を受け付ける端末から受信した、上記購入者によって指定された商品の商品識別情報および個数を、上記発注先サーバに送信することにより、上記購入者が購入を希望する商品を、発注先に注文する。
【請求項７】
請求項６に記載のサーバは、以下を含む；
上記購入者と対話する装置に、上記購入画面を介して購入された商品の品名を発話させて、上記記憶部への登録を促す音声制御部、
上記装置による上記発話に対して、上記購入者が登録に同意する旨の発話したことが、上記検知部によって検知された場合に、上記品名と該品名に対応する商品識別情報とを、上記購入者に対応付けて上記記憶部に登録する登録部。
【請求項８】
ネットワークを介して商品を注文するシステムの制御方法であって、
上記システムの制御方法は、以下を含む；
購入者が行った発話を音声データとして取得する音声取得ステップ、
取得された上記音声データから、購入を希望する商品の品名が発話されたことを検知する検知ステップ、
上記購入者を認証する認証ステップ、
購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定ステップ、
少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注ステップ、
上記検知ステップでは、上記品名に加えて、購入者の購入の意思を意味する所定のキーワードとしての合言葉が発話されたことを検知し、
上記記憶部には、購入者と所定の合言葉とが対応付けて記憶されており、
上記認証ステップでは、購入者によって発話された合言葉と、上記記憶部において上記購入者に対応付けられた合言葉とが一致する場合に、上記発注ステップにおいて注文することを許可し、
上記発注ステップでは、上記認証ステップによって注文が許可された場合に注文する。
【請求項９】
ネットワークを介して商品を注文するサーバの制御方法であって、
上記サーバの制御方法は、以下を含む；
購入者が行った発話の音声データから、購入を希望する商品の品名が発話されたことを検知する検知ステップ、
上記購入者を認証する認証ステップ、
購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定ステップ、
少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した商品を、発注先に対して注文する発注ステップ、
上記検知ステップでは、上記品名に加えて、購入者の購入の意思を意味する所定のキーワードとしての合言葉が発話されたことを検知し、
上記記憶部には、購入者と所定の合言葉とが対応付けて記憶されており、
上記認証ステップでは、購入者によって発話された合言葉と、上記記憶部において上記購入者に対応付けられた合言葉とが一致する場合に、上記発注ステップにおいて注文することを許可し、
上記発注ステップでは、上記認証ステップによって注文が許可された場合に注文する。
【請求項１０】
請求項２に記載のサーバとしてコンピュータを機能させるための制御プログラムであって、上記検知部、上記特定部、上記発注部および上記認証部としてコンピュータを機能させるための制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークを介して店舗から商品を購入するためのシステム、サーバ、装置、端末、制御方法、および、プログラムに関する。
【背景技術】
【０００２】
従来、音声入出力機能および対話機能が備えられた家庭内機器（冷蔵庫、電子レンジなど）が普及しており、ユーザは、音声によって、家庭内機器を操作したり、家庭内機器から情報を得たりすることが可能になっている（例えば、特許文献１および特許文献２）。また、特許文献２に記載されているとおり、家庭内機器が通信機能を備え、他の装置と情報の送受信を直接行うなど、家庭内機器の多機能化が進んでいる。
【０００３】
一方、冷蔵庫など物品を保管する家庭内機器に関し、その在庫を管理して、ユーザの物品購入を支援するための技術が存在する。例えば、特許文献３には、購入周期に基づいて常備品となる品目を特定し、常備品の在庫が不足した場合に、ユーザ端末に購入指示を出力する在庫情報管理装置が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−２５６０３６号公報（２００１年９月２１日公開）
【特許文献２】特開２００７−１３２５５１号公報（２００７年５月３１日公開）
【特許文献３】特開２０１３−２５０６９８号公報（２０１３年１２月１２日公開）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述のような従来技術は、電子商取引によるユーザの購入活動に対し、十分な利便性が提供できないという問題がある。
【０００６】
具体的には、特許文献３の技術では、購入が必要な物品について、ユーザ端末に通知するのみであるため、物品購入のための実際の作業をユーザが行わなければならないことに変わりはない。電子商取引の場合、ユーザは、結局、わざわざ、通信機能を有した機器を操作して、物品購入のための入力作業を行わなければならない。
【０００７】
しかし、一方で、購入には代金の支払いが伴うため、購入の最終的な決断は、ユーザが行わなければならず、したがって、物品購入のための入力作業の全てを装置によって自動化することはできない。
【０００８】
また、ユーザの購入意欲が最も高まるのは、物品を保管する家庭内機器（冷蔵庫など）の使用時に、ユーザが物品の不足を確認したときである。しかし、上記家庭内機器と、物品購入の入力作業を行うための通信機器とは別の装置であり、使用シーンも異なる。そのため、上記通信機器の使用時には、ユーザが購入の必要性を失念したり、気が変わったりして、購入の機会を逃すことがある。
【０００９】
そこで、本発明は、これらの問題点に鑑みて、電子商取引における購入活動に係る作業工程を、簡易な入力手段で実現することにより、好ましくはユーザが購入の機会を逃すことなく、簡易に購入活動を行うことを可能にする、利便性の高い購入代行システムを実現することを目的とする。
【課題を解決するための手段】
【００１０】
上記の課題を解決するために、本発明の一態様に係るシステムは、ネットワークを介して商品を注文するシステムであって、上記システムは、以下を含む；購入者が行った発話を音声データとして取得する音声入力部、取得された上記音声データから、購入を希望する商品の品名が発話されたことを検知する検知部、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部、上記記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定部、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部。
【００１１】
上記の課題を解決するために、本発明の一態様に係るサーバは、ネットワークを介して商品を注文するサーバであって、上記サーバは、以下を含む；購入者が行った発話の音声データから、購入を希望する商品の品名が発話されたことを検知する検知部、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部、上記記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定部、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部。
【発明の効果】
【００１２】
本発明の一態様によれば、購入者が簡易に購入活動を行うことを可能にする、利便性の高い購入代行システムを実現することができるという効果を奏する。
【図面の簡単な説明】
【００１３】
【図１】本発明の各実施形態に係る購入代行システムに含まれる各装置の要部構成を示すブロック図である。
【図２】本発明の各実施形態に係る購入代行システムの概要を示す図である。
【図３】対話ログＤＢのデータ構造の一例を示す図である。
【図４】合言葉ＤＢのデータ構造の一例を示す図である。
【図５】（ａ）は、購入代行システムにおいて、定常商品として設定することが可能な全品目を示すテーブルの一例を示す図であり、（ｂ）は、定常商品として設定している商品の一覧を、ユーザごとに管理するためのテーブルの一例を示す図である。
【図６】店舗情報ＤＢのデータ構造の一例を示す図である。
【図７】購入履歴ＤＢのデータ構造の一例を示す図である。
【図８】買い物メモＤＢのデータ構造の一例を示す図である。
【図９】購入代行システムにおける処理の流れを示すシーケンス図である。
【図１０】購入代行サーバが実行する購入代行処理の流れを示すフローチャートである。
【図１１】ユーザインターフェースの一具体例を示す図である。
【図１２】ユーザインターフェースの一具体例を示す図である。
【図１３】（ａ）〜（ｄ）は、ユーザインターフェースの一具体例を示す図である。
【図１４】ユーザインターフェースの一具体例を示す図である。
【図１５】（ａ）〜（ｄ）は、ユーザインターフェースの一具体例を示す図である。
【図１６】（ａ）〜（ｄ）は、ユーザインターフェースの一具体例を示す図である。
【図１７】（ａ）、（ｂ）は、ユーザインターフェースの一具体例を示す図である。
【図１８】（ａ）、（ｂ）は、発注先選択部が生成する価格比較表の一具体例を示す図である。
【図１９】（ａ）、（ｂ）は、ユーザインターフェースの一具体例を示す図である。
【図２０】本発明の各実施形態に係る購入代行装置、購入代行サーバ、または、購入補助端末として利用可能なコンピュータの構成を例示したブロック図である。
【発明を実施するための形態】
【００１４】
〔実施形態１〕
以下、本発明の実施の形態について、図１〜図１７に基づいて説明すれば、以下のとおりである。
【００１５】
（購入代行システムの概要）
図２は、購入代行システム１００の概要を示す図である。購入代行システム１００は、購入代行装置１と購入代行サーバ２とが連携して、ユーザに対して以下のサービスを提供するためのシステムである。すなわち、ユーザが、通信ネットワークを介して店舗（例えば、図２の店舗Ａ、店舗Ｂなど）から希望する商品を購入する際に行う作業を、購入代行装置１および購入代行サーバ２が代行することにより、ユーザが簡易に電子商取引における購入活動を行うことを可能にする。購入代行システム１００は、少なくとも、購入代行装置１（装置）および購入代行サーバ２（サーバ）を含み、好ましくは、購入補助端末３（端末）を含む。
【００１６】
購入代行装置１は、電子商取引における購入活動のうち、ユーザが購入のために実施する工程を簡易に実行するための入力手段をユーザに提供する。当該入力手段は、音声入力部である。購入代行装置１は、宅内でユーザによって使用される家庭内電子機器によって実現される。本実施形態では、例えば、購入代行装置１は、冷蔵庫１ａである。購入代行装置１は、宅内に複数設置されていてもよい（例えば、電子レンジ１ｂ）。購入代行装置１は、さらに、音声出力部を備え、ユーザに対して音声を出力することができる。
【００１７】
具体的には、購入代行装置１は、音声認識機能および発話機能を有する購入代行サーバ２と通信し、ユーザの発話を録音した入力音声データ（以下、ユーザ発話データ）を購入代行サーバ２に送信する。そして、購入代行装置１は、上記ユーザ発話データに対する応答として出力すべき出力音声データ（以下、機器発話データ）を購入代行サーバ２から受信し、それを音声として出力する。これにより、擬人化された購入代行装置１が、あたかも意思を持って発話しているかのように、ユーザに見せかけることができ、購入代行装置１（のキャラクター）とユーザとの対話が実現する。このように、ユーザが購入を希望する商品について、ユーザは、購入代行装置１に対する発話によって、購入代行サーバ２に知らせることができる。すなわち、購入代行装置１自体がユーザとの音声による対話によって購入代行を受け付ける音声入出力ユーザインターフェースとして機能する。
【００１８】
購入代行サーバ２は、音声認識機能および発話機能を有し、購入代行装置１を制御して購入代行装置１にユーザと対話させる。そして、対話の中から、ユーザが購入を希望する商品を特定し、特定した内容に応じて、実際のユーザの購入活動を代行する（購入代行機能）。具体的には、店舗が所有する店舗サーバ４（例えば、店舗Ａの店舗サーバ４ａ、店舗Ｂの店舗サーバ４ｂなどの発注先サーバ）に対して、商品（および個数）を指定して注文する工程、および、発注を確定させる工程を実行する。さらに必要に応じて、購入代行サーバ２は、発注先を選択する工程、および、発注先からの応答（注文受付Ａｃｋ、請求書、配達予定通知、配達完了通知など）を受信して管理する工程を実行してもよい。
【００１９】
さらに、本実施形態では、購入代行サーバ２は、ユーザが携帯する購入補助端末３と通信し、購入補助端末３と連携して以下の機能を実現する。すなわち、購入代行サーバ２は、購入補助端末３を介して指定された商品（および個数）を、購入予定リストに登録して管理する機能、および、購入補助端末３を介して入力された購入指示に従って、購入予定リストに登録された商品を所定の店舗に注文する機能（購入支援機能）を有する。購入補助端末３を介して入力された商品および個数の購入予定リストを以下では、「買い物メモ」と称し、上記リストに登録して管理する機能を、「買い物メモ機能」と称する。
【００２０】
購入代行サーバ２は、購入活動を支援するための様々な情報をユーザごとに保持し、上述の例以外にも、購入活動に係る様々な購入補助端末３からのリクエストに対してレスポンスを返す機能を有する。
【００２１】
なお、購入代行サーバ２が保持するユーザごとの各種情報について、例えばＯａｕｔｈ認証を用いることにより、購入代行サーバ２、および、購入代行サーバ２と提携する店舗サーバ４のそれぞれは、ユーザが許可した範囲で互いに共有することができる。ユーザごとの情報としては、上述の買い物メモなどの他に、ユーザの氏名、住所、電話番号、決済に使用するクレジットカードの情報、購入する商品名、購入履歴、請求書などが含まれるが、この例に限定されない。
【００２２】
購入補助端末３は、ユーザの購入活動を支援するためのグラフィカルユーザインターフェースを提供する。具体的には、購入補助端末３は、購入代行サーバ２から、買い物メモ作成画面、購入履歴画面などを受信して、それを表示する。また、画面に対するユーザ操作を受け付けて、当該操作によって特定された情報を購入代行サーバ２に送信する。本実施形態では、購入補助端末３は、ユーザが携帯するスマートフォンである。
【００２３】
（定常商品および一般商品について）
以上のとおり、本実施形態に係る購入代行システム１００によれば、ユーザが通信ネットワークを介して店舗から商品を購入するルートは２つある。すなわち、ユーザが購入代行装置１に音声を入力して、購入代行サーバ２に商品の購入を代行させる第１のルート、および、ユーザが購入補助端末３を操作して、購入したい商品および個数の選択を行い、購入代行サーバ２に対して購入を指示する第２のルートである。
【００２４】
第１のルートでは、ユーザは、購入代行装置１に対して少なくとも購入を希望する品名を発話すればよく、その後の購入に係る工程は、購入代行サーバ２が代行する。具体的には、購入代行サーバ２は、ユーザ発話データを解析することにより、ユーザが購入を希望する商品を特定することができ、店舗サーバ４に対して注文を行う。ここで、第１のルートでは、ユーザは、購入を希望する商品について、店舗サーバ４がその商品を一意に特定するための商品識別情報（商品ＩＤまたは商品正式名）および希望する購入個数を都度指定する必要はない。よって、第１のルートは、ユーザが購入したい商品の商品識別情報および個数の組み合わせが一定していて滅多に変わらない場合に利用可能であり、さらに、購入手続きが簡易であるので、購入頻度が高い場合に、好適に利用可能である。このように、ユーザにとって購入希望商品の商品識別情報および個数の組み合わせが一定していてほとんど変わらない商品を「定常商品」と称する。本実施形態において、定常商品は、ユーザごとに設定可能である。定常商品に関するユーザごとの設定情報は、購入代行サーバ２によって管理される。
【００２５】
定常商品以外の商品については、ユーザが都度、購入希望の商品の商品識別情報および個数を指定しなければならないので、従来の電子商取引における購入活動とほぼ同様に、第２のルートによって購入される。第２のルートによって購入される定常商品以外の商品を、当該定常商品と区別して「一般商品」と称する。
【００２６】
なお、本実施形態において、定常商品は、第２のルートで購入することもできる。購入代行サーバ２は、ユーザが定常商品の品名（商品正式名でなく、その商品を表す一般名詞でよい）を発話したことを検知して、当該定常商品の商品識別情報および個数を、一般商品とともに買い物メモに登録する。買い物メモに登録された商品は、定常商品と一般商品の区別によらず、購入補助端末３を介して購入手続きが実施される。すなわち、第２のルートにて購入される。
【００２７】
以上のとおり、本発明の購入代行システム１００によれば、ユーザは、定常商品について、簡易な入力手段を用いるのみ（すなわち、品名を発話するのみ）で、簡単に欲しい商品を購入することが可能となる。
【００２８】
（各装置の構成）
図１は購入代行システム１００を構成する上記の各装置の要部構成の一例を示すブロック図である。なお、以降の説明では、購入代行装置１を実現する家庭内機器の一例として冷蔵庫１ａを、購入補助端末３の一例としてスマートフォンを例に挙げて説明する。また、本発明に直接関係のない部分（例えば、購入補助端末３において電話回線を利用して通話を実現する部分や、冷蔵庫４ａにおいて庫内に冷気を放出する部分など）については、以下の説明および上記ブロック図から省略している。また、店舗サーバ４の構成の詳細についても本発明との関連が薄いため省略する。
【００２９】
１：購入代行サーバのハードウェア構成
図１に示すように、購入代行サーバ２は、通信部１１、制御部１２および記憶部１３を備える。通信部１１は、購入代行装置１、購入補助端末３および店舗サーバ４との通信を行って、上述したとおり、各種情報のやりとりを行う。
【００３０】
制御部１２は、購入代行サーバ２の機能を統括して制御する。制御部１２は、機能ブロックとして、少なくとも、音声制御部２１および購入代行部２２を含み、必要に応じて、要求処理部２３（生成部）および音声要求処理部２４（登録部／リスト作成部）を含む。機能ブロックの各部については、後に詳述する。
【００３１】
記憶部１３は、購入代行サーバ２が使用する各種データを記憶する。記憶部１３は、少なくとも、対話ログデータベース（ＤＢ）３１および定常商品リストデータベース（ＤＢ）３３を含む。記憶部１３は、さらに、必要に応じて、合言葉データベース（ＤＢ）３２、店舗情報データベース（ＤＢ）３４、購入履歴データベース（ＤＢ）３５および買い物メモデータベース（ＤＢ）３６を含んでいてもよい。各ＤＢのデータ構造は、別図を参照して詳述する。なお、図示しないが、記憶部１３は、音声フォーマットを格納するためのデータベースを含んでいる。音声フォーマットＤＢは、いわば音声（発話）の素材集である。音声制御部２１が、機器発話データを生成する際に本ＤＢを参照する。音声の素材は、音声データであってもよいしテキストデータであってもよい。
【００３２】
２：購入代行装置としての家庭内機器（冷蔵庫）の構成
図１に示すように、冷蔵庫１ａは、通信部４１（受信部／送信部）、制御部４２、マイク４３、スピーカ４４、操作部４５および開閉センサ４６（開閉センサ部）を備える。通信部４１は購入代行サーバ２と通信を行う。具体的には、通信部４１は後述する音声制御部４２１によって生成されたユーザ発話データを、購入代行サーバ２に送信する。また、通信部４１は購入代行サーバ２から機器発話データを受信し、これを処理する音声制御部４２１に出力する。
【００３３】
制御部４２は、冷蔵庫１ａの機能を統括して制御する。制御部４２は音声制御部４２１を含む。音声制御部４２１は、音声データに関する処理を行う。具体的には、音声制御部４２１は、マイク４３が取得した音声（ユーザが発話した音声）を録音し、ユーザ発話データを生成する。また、音声制御部４２１は、通信部４１が受信した機器発話データを処理して、冷蔵庫１ａの発話としての音声をスピーカ４４から出力する。
【００３４】
操作部４５は、ユーザによる入力操作を受け付ける。操作部４５は例えば物理ボタン、タッチパネルなどであり、入力操作を受け付けたことを示す入力信号を音声制御部４２１に出力する。音声制御部４２１は当該入力信号を受けて、対話を開始する。音声制御部４２１は、ユーザとの対話の開始イベントが発生した旨を、購入代行サーバ２に通知し、購入代行サーバ２の制御下で、音声データを入出力して対話を実行する。なお、操作部４５は冷蔵庫１ａのドアであってもよい。この場合、ユーザがドアを開けたことをトリガにして、音声制御部４２１が対話を開始してもよい。具体的には、冷蔵庫１ａは、ドアの開閉センサ４６を備え、開閉センサ４６は、ドアが開けられたこと、または、閉じられたことを検知すると、その検知結果を音声制御部４２１に出力する。なお、開閉センサ４６は、明るさセンサ、接触センサなど適宜のセンサで実現される。また、マイク４３およびスピーカ４４は常に起動された状態であってもよく、所定のイベントが発生したことをトリガとして、冷蔵庫１ａから発話を開始する形で、ユーザとの対話が開始されてもよい。つまり、ユーザが操作部４５に対して対話を開始するための入力操作を行わない構成であってもよい。さらに、冷蔵庫１ａは、図示しないタイマを備えていてもよい。例えば、タイマは、開閉センサ４６がドアの開閉を検知した時点（あるいは、その他の対話開始イベント発生時点）から計時を開始する。冷蔵庫１ａは、その時点から所定時間（例えば、３分）が経過するまでの間、マイク４３およびスピーカ４４を起動する構成であってもよいし、音声制御部４２１は、上記タイマによる計時期間のみ音声データを入出力する構成であってもよい。これにより、ユーザが冷蔵庫１ａを使用している所定期間に限って、効率よく音声認識処理が実行されるため、冷蔵庫１ａおよび購入代行サーバ２の処理の負荷を軽減させることができる。さらに、冷蔵庫１ａを使用（ドアを開閉）している所定期間は、ユーザが、在庫の不足に気づいたりして、購買意欲が最も高まっている期間であると考えられる。このように、ユーザが冷蔵庫１ａを使用してからの所定期間内に、音声入力による購入作業を可能にすることにより、ユーザが購入の必要性を失念したり、気が変わったりして、購入の機会を逃す虞がなくなる。
【００３５】
３：購入補助端末（スマートフォン）の構成
図１に示すように、スマートフォンである購入補助端末３は、通信部５１（受信部／送信部）、制御部５２、操作部５４、表示部５５を備える。通信部５１は購入代行サーバ２と通信を行う。具体的には、通信部５１は後述するＵＩ処理部５２１によって処理された情報を、購入代行サーバ２に送信する。また、通信部５１は購入代行サーバ２から受信した情報を、それを処理するＵＩ処理部５２１に出力する。
【００３６】
制御部５２は、購入補助端末３の機能を統括して制御する。制御部５２は、ＵＩ処理部５２１および表示制御部５２２を含む。ＵＩ処理部５２１は、表示部５５に表示されるユーザインターフェース（以下、ＵＩ）に関する処理を実行する。具体的には、ＵＩ処理部５２１は、購入代行サーバ２から買い物メモを作成したり編集したりするための画面あるいは商品を購入するための画面（購入画面）を取得し、その画面が表示部５５に表示されるよう、当該画面を表示部５５の仕様に適合した配置に変換して表示制御部５２２に出力する。また、ＵＩ処理部５２１は、操作部５４を介して上記画面が操作されたことによって入力された入力信号にしたがって、各種情報を生成する。生成された情報は、購入代行サーバ２に送信される。表示制御部５２２は、ＵＩ処理部５２１が生成した画面に対応する映像信号を表示部５５に出力して、当該画面を表示部５５に表示させる。
【００３７】
操作部５４は、ユーザの入力操作を受け付けて、当該入力操作に対応する入力信号をＵＩ処理部５２１に出力する。なお、ここでは操作部５４はタッチパネルであるものとして説明するが、物理ボタンであってもよいし、その他の入力デバイスであってもよい。操作部５４がタッチパネルである場合、操作部５４は表示部５５と一体となっている。表示部５５は、表示制御部５２２が出力した映像信号に対応する画面を表示する。なお、表示部５５としては液晶ディスプレイ（Liquid Crystal Display；ＬＣＤ）が挙げられるが、これに限定されない。
【００３８】
（購入代行サーバのソフトウェア構成）
１：音声制御機能
音声制御部２１は、冷蔵庫１ａによって入出力される音声データに関する処理を行う。音声制御部２１は、図示しない音声解析部および音声生成部を含む。音声解析部は、冷蔵庫１ａから受信したユーザ発話データに対して音声解析を実行する。具体的には、受信したユーザ発話データをテキストデータ化し、発話が成された日時とともに、対話ログＤＢ３１に格納する。格納されたテキストデータは、音声生成部によって、次に冷蔵庫１ａに発話させる内容を決定するために参照されたり、購入代行部２２によって、購入に係る特定のキーワードが発話されたか否かを判定するために参照されたりする。なお、音声解析部が実行する音声解析処理（ユーザ発話データのテキストデータ化）については、既存の技術が利用できる。音声生成部は、冷蔵庫１ａに出力させる機器発話データを生成する。機器発話データは、対話ログＤＢ３１に格納されたユーザの発話に対する応答としてふさわしい内容を含んでいなければならない。そこで、音声生成部は、音声フォーマットＤＢに格納されている音声データの１以上の素材、および、ユーザによって発話されたキーワードを組み合わせて、ユーザとの対話が成立するような内容を含む機器発話データを生成する。生成された機器発話データのテキストデータは、冷蔵庫１ａの発話として対話ログＤＢ３１に格納されるとともに、通信部１１を介して冷蔵庫１ａに供給される。
【００３９】
２：定常商品の購入代行機能（第１のルートによる購入）
図１は、購入代行サーバ２の購入代行機能に係る要部構成を示す図である。購入代行機能を担う購入代行部２２は、少なくとも、発注品特定部２２２（特定部）および発注部２２４を含む。さらに、必要に応じて、購入代行部２２は、認証部２２１、発注先選択部２２３を含んでいてもよい。
【００４０】
購入代行部２２は、まず、対話ログＤＢ３１を監視して、購入代行処理のトリガとなるキーワードがユーザによって発話された否かを判断する。すなわち、購入代行部２２は、ユーザの発話の内容から特定のキーワードを検知する検知部として機能する。購入代行のトリガとなる特定のキーワードとしては、定常商品の品名（例えば、「たまご」など）が少なくとも含まれる。本実施形態では、品名に加えて、ユーザが購入を決断したときの決まり文句をキーワードとして特定する。なお、決まり文句は、「買うわ。」「注文して。」など、ユーザの購入の意思を直接的に意味する日常会話の類であってもよいが、「ひらけごま」などのように、家族の中で購入の権限がある者のみ知り得る合言葉やパスワードの類であることが好ましい。本実施形態では、合言葉がユーザ（１家庭）ごとに予め設定されている。また、対話ログＤＢ３１において全てのユーザ発話データには、ユーザ（１家庭）を一意に識別する情報（以下、クライアントＩＤ）が関連付けられているので、購入代行部２２は、ユーザの対話ログを参照して、そのユーザに固有の合言葉が発話されたか否かを検知することができる。
【００４１】
定常商品リストＤＢ３３には、ユーザごとにどの商品を定常商品として設定しているのかが記憶されている。購入代行部２２は、定常商品リストＤＢ３３を参照して、そのユーザに対応付けられた定常商品の品名が発話されたことを検知すると、ユーザがその定常商品の購入を決断したと判断する。そして、購入代行部２２は、購入代行処理の開始を決定し、購入代行部２２内の各部に購入代行処理の実行を指示する。
【００４２】
購入代行部２２が認証部２２１を含む場合、認証部２２１は、ユーザを認証して、購入代行処理を続行してよいかどうかを決定する。具体的には、認証部２２１は、合言葉ＤＢ３２において事前に登録されている上記ユーザの合言葉と、購入代行部２２が検知した（すなわち、ユーザによって実際に発話された）合言葉とを比較する。合言葉が一致した場合、認証部２２１は、購入代行処理の続行を決定する。
【００４３】
発注品特定部２２２は、発話された定常商品の品名（例：たまご）に基づいて、発注に必要な情報を特定する。発注に必要な情報とは、少なくとも、発話された品名に対応する商品の商品識別情報である。商品識別情報は、店舗サーバ４が販売・配達すべき商品を一意に特定するための情報であり、例えば、商品ＩＤあるいは商品正式名などである。本実施形態では、発注品特定部２２２は、商品正式名を特定する。例えば、定常商品の品名「たまご」に対応する商品正式名は、「栄養卵ひかり  Ｍ玉  １０個パック」などである。定常商品リストＤＢ３３において、ユーザごとに、定常商品の品名に関連付けて、商品正式名が記憶されている。発注品特定部２２２は、定常商品リストＤＢ３３を参照することにより、発話された定常商品の品名「たまご」から、そのユーザが「たまご」と言った場合には、「栄養卵ひかり  Ｍ玉  １０個パック」ことである、と特定することができる。
【００４４】
さらに、本実施形態では、発注品特定部２２２は、特定した商品の発注すべき個数を特定する。定常商品リストＤＢ３３において、定常商品の品名には、さらに、個数が対応付けられており、発注品特定部２２２は、定常商品リストＤＢ３３を参照することで、発話された品名に対応する商品正式名に加えて個数を特定することができる。
【００４５】
なお、実施形態１では、発注品特定部２２２は、さらに、特定した商品の発注先を特定する。定常商品リストＤＢ３３において、定常商品の品名には、さらに、発注先が対応付けられており、発注品特定部２２２は、さらに、発話された品名の商品の発注先を特定することができる。
【００４６】
発注部２２４は、発注品特定部２２２によって特定された発注先に対して、ユーザが発話した定常商品を注文する。具体的には、発注部２２４は、少なくとも、発注品特定部２２２によって特定された商品識別情報（商品正式名）を、上記発注先の店舗サーバ４に送信して、注文を実行する。発注品特定部２２２によって、商品ＩＤや個数などが特定された場合には、それらも併せて店舗サーバ４に送信する。なお、発注部２２４は、例えば、店舗サーバ４が指定するフォーマットにしたがって注文書データを作成したり、店舗サーバ４との間で取り決められた発注プロトコルにしたがって、店舗サーバ４と情報の交換を行ったりすることもできる。
【００４７】
発注部２２４によって注文が完了すると、購入代行部２２は、最後に、注文が完了した定常商品について購入履歴を残してもよい。この場合、購入代行部２２は、注文された定常商品の品名、商品正式名、個数、発注先、発注日時などを、購入履歴ＤＢ３５に格納する。なお、実施形態１の購入代行部２２は、必ずしも発注先選択部２２３（選択部）を含まない。発注先選択部２２３については、実施形態２にて詳述する。
【００４８】
３：要求処理機能
要求処理部２３は、通信部１１を介して購入補助端末３と通信し、購入補助端末３からのリクエストに対応して、これには限定されないが、例えば、以下の処理を実行する；（１）合言葉の登録および変更、（２）定常商品の設定および解除、（３）買い物メモの表示、新規作成および編集、（４）買い物メモを用いた購入商品の指定、（５）購入可能な商品（定常商品および一般商品）の一覧表示、検索および選択、（６）対話ログの表示、（７）購入履歴の表示、（８）配達記録の表示などである。
【００４９】
要求処理部２３は、必要に応じて、上記処理の実行結果をレスポンスとして購入補助端末３に返してもよい。レスポンスを返すことの中には、要求処理部２３が、上記処理の実行指示を受け付けるための画面を作成し、購入補助端末３に提供することも含まれる。これにより、ユーザは、購入補助端末３に表示された画面を見ながら購入補助端末３に対して入力を行い、上記の処理の実行を購入代行サーバ２に対して命令することができる。
【００５０】
音声要求処理部２４は、ユーザによって発話された内容を受けて、必要に応じて記憶部１３に記憶されている各種ＤＢの情報を更新する。音声要求処理部２４の具体的な機能については後述する。
【００５１】
３−１：一般商品の購入支援機能（第２のルートによる購入）
要求処理部２３は、購入補助端末３からのリクエストが、一般商品の購入を指示する「購入指示」である場合、注文に必要な情報を購入補助端末３から受信する。注文に必要な情報は、上記リクエストに含まれていてもよいし、要求処理部２３が上記リクエストを受けて購入補助端末３に対して要求することにより後から取得されてもよい。注文に必要な情報は、購入を希望しているユーザを特定するためのクライアントＩＤ、購入が希望されている商品を特定するための商品識別情報（商品ＩＤまたは商品正式名）、購入希望個数、および、その商品の発注先の店舗ＩＤなどである。要求処理部２３は、購入補助端末３から受信した注文に必要な情報を購入代行部２２に引き渡し、購入代行処理を依頼する。発注部２２４は、要求処理部２３から注文に必要な情報を受け取り、以降は第１のルートと同様に商品を発注する。
【００５２】
（データベース）
１：対話ログＤＢ
図３を参照して、対話ログＤＢ３１のデータ構造の一例を説明する。図３において、対話ログＤＢ３１のデータ構造をテーブル形式にて示したことは一例であって、当該データ構造を、テーブル形式に限定する意図はない。以降、データ構造を説明するためのその他の図においても同様である。
【００５３】
対話ログＤＢ３１は、これには限定されないが、例えば、クライアントＩＤ、発話ＩＤ、ユーザ発話データ、機器発話データ、および、発話日時のカラムを含む。クライアントＩＤは、図２に示された、購入代行システム１００のサービスを利用する１家庭につき、１つ付与されるものであり、購入代行サーバ２において、サービスの受け手を家庭単位で識別するのに用いられる。本実施形態では、１家庭について、購入の権限者として一人のユーザが、また、購入の窓口として１台の購入代行装置１（家庭内機器；冷蔵庫１ａ）が想定されている。そのため、購入代行サーバ２は、このクライアントＩＤひとつで、サービスの受け手を一意に特定することができる。１家庭内に、購入の権限者であるユーザが複数いたり、購入代行装置１としての家庭内機器が複数設けられたりする場合には、ユーザおよび家庭内機器を識別するためのＩＤが別途設定される。
【００５４】
ユーザ発話データのカラムには、ユーザの発話に対応するテキストデータが格納される。機器発話データのカラムには、冷蔵庫１ａの発話に対応するテキストデータが格納される。１つのテキストデータは、１つの音声データに対応している。１つのテキストデータにつき、便宜上、発話ＩＤが割り当てられていてもよい。
【００５５】
発話日時のカラムには、ユーザ発話データの場合、当該ユーザ発話データの録音が開始された日時が格納される。機器発話データの場合、当該機器発話データの出力が開始された日時が格納される。
【００５６】
対話ログＤＢ３１の各カラムに格納された以上のデータは、購入代行部２２が特定のキーワード（品名および合言葉）を検知するときに参照される。
【００５７】
２：合言葉
図４を参照して、合言葉ＤＢ３２のデータ構造の一例を説明する。合言葉ＤＢ３２は、これには限定されないが、例えば、クライアントＩＤおよび合言葉のカラムを含む。同図に示すとおり、クライアントＩＤに関連付けて合言葉が格納されている。すなわち、１ユーザ（１家庭）につき、１つの合言葉が設定されている。認証部２２１は、合言葉が含まれた対話ログに対応付けられたクライアントＩＤと同じクライアントＩＤの合言葉を合言葉ＤＢ３２から読み出し、対話ログの中の合言葉と読み出した合言葉との一致／不一致によって、購入代行処理の続行可否を判断する。合言葉のカラムに格納される合言葉のデータ形式は、音声データであってもよいし、テキストデータであってもよい。音声データである場合には、発話の音声データと、合言葉のカラムに格納されている音声データとの声質、声紋などを比較してもよい。
【００５８】
本実施形態では、上記データ構造によれば、１家庭につき合言葉を１つ設定することができるが、これに限らず、合言葉ＤＢ３２は、複数の合言葉（第１候補、第２候補、第３候補・・・）を設定できるデータ構造を有していてもよい。また、１家庭につき複数のユーザが想定されている場合には、ユーザごとに合言葉が設定できるデータ構造であってもよい。
【００５９】
また、特定の定常商品に関し、定常商品ごとに個別の合言葉が設定できるデータ構造であってもよい。すなわち、合言葉ＤＢ３２は、クライアントＩＤ、定常商品の商品ＩＤに関連付けて、合言葉が格納されるデータ構造を有していてもよい。該データ構造によれば、定常商品に対応付けられた合言葉を知る者しか当該定常商品を購入できないように、権限者以外の購入活動をブロックすることができる。例えば、該データ構造は、高価な定常商品などを子供が勝手に購入できないようにする場合に好適に用いられる。
【００６０】
３：定常商品リスト
図５の（ａ）および（ｂ）を参照して、定常商品リストＤＢ３３のデータ構造の一例を説明する。定常商品リストＤＢ３３は、以下の２つのテーブルを含む。
【００６１】
図５の（ａ）は、購入代行システム１００において、定常商品として設定することが可能な全品目を示すテーブルの一例である。該テーブルは、これには限定されないが、定常設定可能品目ＩＤ、品名、商品正式名、および、単価のカラムなどを含む。品名と商品正式名との対応関係は、購入代行システム１００全体、および、発注先の全店舗サーバ４によって共有される。そのため、単価のカラムは、発注先の店舗サーバ４が複数ある場合には、カラム自体が設けられないか、あるいは、単価のカラムに、参考小売価格、平均価格などが格納される。
【００６２】
品名のカラムには、定常商品として設定可能な品目の通称が格納される。品名は、ユーザが音声入力によって購入希望商品を指すときに発する言葉であるので、その商品を表現するときに広く一般的に用いられる言葉であり、短く簡単であることが好ましい。品名ごとに、便宜上、定常設定可能品目ＩＤが付与されてもよい。
【００６３】
商品正式名のカラムには、上記品名に対応付けることができる商品候補の商品正式名が格納される。同図に示すとおり、１つの品名に対して、関連付けが可能な商品の候補は複数あってもよい。なお、本実施形態では、品名に関連付けることが可能な商品正式名の候補は、全クライアントで共通とする。すなわち、商品正式名に対して割り当てられる品名（呼称）は、ユーザが自由に作成できるものではなく、購入代行サーバ２があらかじめ準備したものが用いられる。
【００６４】
図５の（ａ）に示すテーブルは、要求処理部２３が定常商品の設定および解除を行うための画面を生成するときに参照される。上記データ構造によれば、例えば、ユーザは、自分が「たまご」と言えば、どの銘柄のどのサイズのどの数量のたまごであるのかを、候補の中から好きに選択することができる。
【００６５】
図５の（ｂ）は、定常商品として設定している商品の一覧を、ユーザごとに管理するためのテーブルの一例である。該テーブルは、これには限定されないが、クライアントＩＤ、品名、商品正式名、および、個数のカラムなどを含む。
【００６６】
同図に示すとおり、ユーザは、１つの品名につき、１つの商品正式名とその個数とをあらかじめ選択して該テーブルに登録しておくことができる。ユーザが単に品名を発話するだけで、発注品特定部２２２は、該テーブルを参照すれば、注文に必要な情報、すなわち、購入すべき商品の商品正式名および個数を一意に特定することができる。具体的には、発注品特定部２２２は、例えば、クライアントＩＤ「ＳＨ１２３４５６」のユーザが“「牛乳」を購入する”と言ったときには、“商品正式名「恵みのミルク１Ｌ」を、個数「２」個購入する”ことを意味すると認識することができる。
【００６７】
以上のように、どの商品を定常商品として設定するのかは、家庭（クライアント）ごとに異なっており、品名と商品正式名との対応関係は、クライアントＩＤを用いてクライアントごとに管理される。
【００６８】
なお、同図に示すとおり、１家庭につき、複数の品目を定常商品として設定することができてもよい。また、上記テーブルにおいて、発注先のカラムが設けられ、品名ごとに、発注先が対応付けられていてもよい。これにより、発注品特定部２２２は、その商品を注文するときの発注先を特定することができる。さらに、配達日時のカラムが設けられ、品名ごとに、配達日時が対応付けられていてもよい。これにより、発注品特定部２２２は、その商品の配達日時を特定し、発注先に対して指定することができる。例えば、配達日時のカラムに「金曜日１７時以降」が格納されている場合、注文した商品が、発注日以降の配達可能な直近の金曜日１７時以降に配達されるように、購入代行サーバ２が店舗サーバ４に対して指定することができる。
【００６９】
４：店舗情報
図６を参照して、店舗情報ＤＢ３４のデータ構造の一例を説明する。なお、購入代行サーバ２が商品を注文する店舗サーバ４が１つしかない場合には、記憶部１３は、その店舗サーバ４の情報を記憶しておくだけでよく、店舗情報ＤＢ３４を含まなくてもよい。
【００７０】
店舗情報ＤＢ３４は、これには限定されないが、店舗ＩＤ、店舗名、ＵＲＬ、メールアドレス、および、注文手順のカラムなどを含む。店舗ＩＤのカラムには、店舗およびその店舗サーバ４を一意に識別するための識別情報が格納される。店舗名のカラムには、店舗の名称が格納される。ＵＲＬまたはメールアドレスのカラムには、注文を送信するときの店舗サーバ４の宛先が格納される。ＵＲＬのカラムには、店舗のＷｅｂサイトのホームページ、注文フォームのページ、あるいは、商品リストまたは価格表などのページのアドレスが格納されていてもよい。注文手順のカラムには、店舗サーバ４によって規定された注文のマニュアル、注文書の作成手順、注文書のテンプレート、または、発注プロトコルなどが格納されていてもよい。注文手順のカラムに格納された情報を参照することにより、発注部２２４は、店舗によって規定された注文の仕方で、ユーザが希望する商品を正確に発注することができる。
【００７１】
５：購入履歴
図７を参照して、購入履歴ＤＢ３５のデータ構造の一例を説明する。購入履歴ＤＢ３５は、これには限定されないが、発注日時、店舗ＩＤ、商品正式名、区分、個数、単価、合計、および、ステータスのカラムなどを含む。上記各カラムに格納されている情報は、ユーザごとに管理される。すなわち、クライアントＩＤに関連付けて格納されている。
【００７２】
発注日時のカラムには、発注部２２４が店舗サーバ４に対して注文に必要な情報を送信した日時が格納される。店舗ＩＤのカラムには、発注先の店舗の店舗ＩＤが格納される。商品正式名のカラムには、注文した商品の商品正式名が格納される。区分のカラムには、注文した商品が定常商品であるのか一般商品であるのかを示す情報が格納される。個数のカラムには、上記商品の注文個数が格納される。単価のカラムには、上記商品の、発注先の店舗における販売価格が格納される。合計のカラムには、当該商品について、単価×個数で求められる支払金額の合計が格納される。ステータスのカラムには、当該商品についての現在の状況が格納される。例えば、「発注完了」は、購入代行サーバ２が店舗サーバ４に対して発注を完了させており、店舗サーバ４から注文受付Ａｃｋが送信されるのを待機している状況であることを意味する。「配達中」は、購入代行サーバ２が店舗サーバ４から注文受付Ａｃｋを受信し、よって注文が確定し、発注先の店舗が注文された商品の配達を手配している途中であることを意味する。「配達完了」は、注文された商品が購入者であるユーザの家庭に配達されたことを意味する。「支払完了」は、上記商品の対価を上記店舗に対して支払い、その入金が店舗サーバ４において確認されたことを意味する。
【００７３】
購入代行部２２は、発注が完了した商品に関する情報を上述の各カラムに格納する。購入履歴ＤＢ３５は、要求処理部２３が購入補助端末３からのリクエストを受け付けて、購入履歴画面を生成するときに参照される。
【００７４】
６：買い物メモ
図８を参照して、買い物メモＤＢ３６のデータ構造の一例を説明する。買い物メモＤＢ３６は、これには限定されないが、例えば、登録日時、品名、商品正式名、区分、個数、単価、合計、および、購入フラグのカラムを含む。これらのカラムに格納されている情報は、ユーザごとに管理されている。すなわち、クライアントＩＤに関連付けて格納されている。登録日時のカラムには、商品のレコードが新規に買い物メモＤＢ３６に登録された日時が格納される。購入フラグのカラムには、買い物メモにリストアップされた当該商品について、ユーザの購入意思の有無を表すフラグが格納される。例えば、購入フラグ「ＯＮ」は、その商品についてユーザが購入の意思があることを意味し、購入フラグ「ＯＦＦ」は、その商品についてユーザは購入を決断していない（保留している）ことを意味している。その他のカラムについては、上述した通りであるので説明を省略する。
【００７５】
本実施形態では、商品を購入する場合と同様に、２つのルートのどちらを経由しても買い物メモＤＢ３６に商品を登録することが可能である。１つ目は、ユーザが、冷蔵庫１ａとの対話を通じて、買い物メモに商品を登録する旨の発話を行い、発話内容にしたがって、音声要求処理部２４が、買い物メモＤＢ３６を更新する第１のルートである。２つ目は、ユーザが、購入補助端末３に表示されている買い物メモ作成画面を操作し、該操作にしたがって、要求処理部２３が、買い物メモＤＢ３６を更新する第２のルートである。
【００７６】
音声要求処理部２４または要求処理部２３によって商品が登録された買い物メモＤＢ３６は、購入代行部２２が商品を注文するときに参照される。購入代行部２２は、登録日時、区分、商品正式名（および個数）、および、購入フラグによって特定される商品のステートに応じて、その商品の注文を行うか否かを決定する。とりわけ、発注部２２４は、第１のルートで音声登録された定常商品に対して、その対話の場ですぐに購入が決断されなかった場合には、購入フラグがＯＮの定常商品について、所定時刻（例えば、１５：００）になると、発注を実行する。あるいは、発注部２２４は、登録日時から所定時間経過（例えば、３時間経過）すると、発注を実行してもよい。ここで、買い物メモＤＢ３６に登録される商品（レコード）のステートは、以下の５パターンが想定される。
【００７７】
６−１：区分が「定常商品」で購入フラグが「ＯＦＦ」のレコードについて
本パターンのレコードは、第１のルートを介して、登録されたレコードである。具体的には、冷蔵庫１ａに定常商品の品名が音声入力されると、音声要求処理部２４が、該品名に対応する商品のレコードを買い物メモＤＢ３６に新規登録する。レコードが登録されると、発注品特定部２２２は、定常商品リストＤＢ３３を参照し、登録された品名に対応する商品正式名と個数とを特定し、当該レコードのそれぞれのカラムを埋める。発注品特定部２２２は、必要に応じて、発注先を特定し、さらに、その商品の単価と合計とをそれぞれのカラムに格納してもよい。
【００７８】
本パターンでは、登録されたレコードは、購入意思を意味する決まり文句（または合言葉）が発話されていないために、注文が確定せず待機状態となっている。また、購入フラグが「ＯＦＦ」であるため、所定時刻になっても、発注部２２４によって発注されない。
【００７９】
例えば、図８に示す１行目のレコード（品名「たまご」）が本パターンに該当する。このレコードについて、発注部２２４が発注を実行するためには、ユーザが、購入補助端末３に表示された買い物メモ作成画面を操作して、購入フラグを「ＯＮ」にした上で、（１）購入確定ボタンを押下するか、または、（２）所定時刻になればよい。あるいは、音声制御部２１が当該レコードの商品購入を促す発話を冷蔵庫１ａに実行させて、これにより、ユーザに合言葉を言わせたり、または、購入フラグを「ＯＮ」にすることに同意する旨を発話させたりすればよい。これに応じて購入代行部２２が購入代行処理を開始することができる。
【００８０】
６−２：区分が「定常商品」で購入フラグが「ＯＮ」のレコードについて
本パターンのレコードは、上記と同様に、第１のルートを介して、音声要求処理部２４によって登録されたレコードであり、さらにその後、ユーザが、購入補助端末３に表示された買い物メモ作成画面を操作して、購入フラグを「ＯＮ」にしたレコードである。
【００８１】
例えば、図８に示す２行目のレコード（品名「牛乳」）が本パターンに該当する。このレコードの商品は、（１）所定時刻までにユーザが買い物メモ作成画面を操作して購入確定ボタンを押下することによって、購入フラグが「ＯＮ」の他の商品とともに発注されるか、または、（２）所定時刻になったときに発注部２２４によって自動的に発注される。
【００８２】
６−３：区分が「一般商品」で商品正式名が「ＮＵＬＬ」のレコードについて
本パターンのレコードは、品名が発話されたことにより、第１のルートを介して、音声要求処理部２４によって登録されたレコードである。しかし、上記の各パターンと異なる点は、発話された品名に対応する商品が定常商品として設定されていない（一般商品である）点である。この場合、品名に対応する商品正式名および個数が定常商品リストＤＢ３３に登録されていないために、発注品特定部２２２は、当該レコードの正式商品名および個数のカラムを埋めることができない。すなわち、本レコードは、品名が発話されたことをトリガとして、とりあえず登録されたが、注文に必要な情報が欠けている未完成のレコードである。音声要求処理部２４は、注文に必要な情報が補完されていない現時点では、当該レコードの購入フラグを「ＯＦＦ」にする。
【００８３】
例えば、図８に示す３行目のレコード（品名「ヨーグルト」）が本パターンに該当する。ユーザは、ヨーグルトを買い物メモに登録する旨の発話をしたものの、事前に、ヨーグルトを定常商品として設定していなかった。このため、発話時点で、発注品特定部２２２が情報を特定できないカラムは、「ＮＵＬＬ」となる。このレコードについて、発注部２２４が発注を実行するためには、少なくとも、ユーザが発話した品名「ヨーグルト」について、対応する商品正式名および個数が指定されなければならない。この指定は、購入補助端末３に表示される操作画面を介して、ユーザが所望するヨーグルトの商品正式名および個数を選択することによって実現する。
【００８４】
以上のとおり、ユーザは、定常商品として設定していない一般商品について、品名を発話するのみで買い物メモに登録することはできる。ただし、ユーザは、当該品名のレコードの購入フラグを「ＯＮ」にしたり、音声入力のみで購入を確定させたりするために、登録後に、購入補助端末３を用いて商品正式名および個数を指定する必要がある。
【００８５】
６−４：区分が「一般商品」で商品正式名および個数が特定されており、購入フラグが「ＯＮ」のレコードについて
本パターンのレコードは、第２のルートを介して、要求処理部２３によって登録されたレコードである。具体的には、購入補助端末３に表示された買い物メモ作成画面を介して、商品正式名および個数が指定され、かつ、購入フラグが「ＯＮ」に設定される。要求処理部２３は、購入補助端末３から上記の操作内容を含むリクエストを受け付けて、上記レコードの商品正式名および個数のカラムに、指定された商品正式名および個数を格納し、購入フラグを「ＯＮ」に変更する。
【００８６】
例えば、図８に示す４行目のレコード（品名「納豆」）が本パターンに該当する。このレコードについて、発注部２２４が発注を実行するためには、ユーザが、購入補助端末３に表示された買い物メモ作成画面を操作して、購入確定ボタンを押下すればよい。本レコードの商品は一般商品であるので、発注部２２４が、音声入力に応じて発注を確定させたり、定刻に自動発注したりすることはない。
【００８７】
６−５：区分が「一般商品」で商品正式名および個数が特定されており、購入フラグが「ＯＦＦ」のレコードについて
本パターンのレコードは、上記パターンと同様に、第２のルートを介して、要求処理部２３によって登録されたレコードである。しかし、買い物メモ作成画面において購入フラグを「ＯＮ」する操作がユーザによって実行されていない。すなわち、購入が保留されている状態である。購入フラグが「ＯＦＦ」の状態で、購入確定ボタンが押下されても、発注部２２４は当該商品の発注を実行しない。また、上記パターンと同様に、本パターンのレコードについても、発注部２２４は、音声入力に応じて発注を確定させたり、定刻に自動発注したりすることはしない。
【００８８】
以上のように、本実施形態では、購入代行部２２は、買い物メモＤＢ３６を参照して、商品ごとの登録日時と区分とに基づいて、商品を注文するか否かを決定することができる。また、発注品特定部２２２は、必要に応じて定常商品リストＤＢ３３を参照して、商品正式名と個数とを特定することができる。そして、発注部２２４は、購入フラグが「ＯＮ」の商品のうち、商品正式名と個数とが買い物メモにおいて特定されている商品について発注を実行する。
【００８９】
上記構成によれば、ユーザは、音声入力による簡易な購入活動を実施するとともに、その購入活動と矛盾や混乱をきたすことなく、購入補助端末３を用いて買い物メモを作成、編集しながら容易に購入活動を実施することができる。
【００９０】
（購入代行処理の概要）
図９は、購入代行システム１００における処理の流れを示すシーケンス図である。図９は、とりわけ、第１のルートを介して買い物メモが作成されているときに購入活動が実施される場合の処理の概要を示す。
【００９１】
ユーザが、買い物メモを作成したいときに、冷蔵庫１ａに対して買い物メモを作成したい旨の発話を行い（Ｓ１）、冷蔵庫１ａとの対話を開始させる。事前に「買い物メモ作って」などの決まり文句が設定されていてもよい。Ｓ１において、冷蔵庫１ａとの対話開始のトリガは、上記に限定されない。例えば、ユーザは、買い物メモの作成を指示する操作ボタン（冷蔵庫１ａに設けられている）を押してもよい。あるいは、冷蔵庫のドアの開閉が対話開始のトリガとなってもよい。この場合、ユーザが、冷蔵庫１ａのドアを開けたり、閉じたりすると、冷蔵庫１ａの開閉センサ４６が、ドアの開閉を検知する（Ｓ１’）。なお、冷蔵庫１ａが開閉センサ４６を備えない場合は、Ｓ１’の処理は省略される。
【００９２】
買い物メモ作成に関する音声または操作信号が冷蔵庫１ａに入力されると（音声取得ステップ）、あるいは、開閉センサ４６が、ドアの開閉を検知すると（Ｓ１’でＹＥＳ）、冷蔵庫１ａの音声制御部４２１は、ユーザとの対話を開始させるイベントが発生したと判断し、通信部４１を介して、購入代行サーバ２に対話開始イベントを通知する（Ｓ２）。具体的には、音声制御部４２１は、自機に関連付けられているクライアントＩＤと、Ｓ１で入力、録音されたユーザ発話データとを購入代行サーバ２に送信する。
【００９３】
購入代行サーバ２の音声制御部２１は、Ｓ２の通知によって、対話開始イベントが発生したことを検知すると（Ｓ３でＹＥＳ）、冷蔵庫１ａを制御して対話を実行させる（Ｓ４）。具体的には、音声制御部２１は、ユーザ発話データの解析と対話ログの記録とを実行し、ユーザの発話に対する返答としてふさわしい内容の機器発話データを生成して冷蔵庫１ａに供給する。冷蔵庫１ａは、機器発話データを取得し、音声として出力することにより発話する。こうして、冷蔵庫１ａは、入力されたユーザ発話データの転送、および、供給された機器発話データの出力を、購入代行サーバ２の制御下で繰り返し、ユーザとの対話を実行する（Ｓ５）。ユーザは、買い物メモ作成のための対話を冷蔵庫１ａと継続する（Ｓ６）。
【００９４】
ここで、ユーザが、買い物メモに登録したい商品の品名を発話すると、その品名が含まれたユーザ発話データを音声制御部２１が解析する。音声要求処理部２４は、買い物メモ作成に係る対話の文脈で、品名が発話されたと判断し（Ｓ７でＹＥＳ）、上記商品のレコードを買い物メモＤＢ３６に登録する（Ｓ８）。
【００９５】
さらに、ユーザが、買い物メモに登録した商品を購入する意思を示す発話を行うと、購入代行部２２は、買い物メモに登録された定常商品の購入が指示されたと判断し（Ｓ９でＹＥＳ）、買い物メモに登録された定常商品の購入代行処理を実行する（Ｓ１０）。
【００９６】
上記方法によれば、ユーザは、冷蔵庫１ａとの対話のみで、買い物メモを作成することが可能であり、引き続き、対話のみで買い物メモに登録した商品の購入を購入代行サーバ２に対して指示することが可能となる。
【００９７】
なお、冷蔵庫１ａがタイマを備える場合には、タイマが、対話開始イベントが発生した時点から計時を行い、該時点から所定時間経過後に対話が終了されてもよい。具体的には、音声制御部４２１は、ドアの開閉などの対話開始イベントが発生してから所定時間（例えば、３分）経過した場合に（Ｓ１１）、ユーザとの対話を終了してもよい（Ｓ１２）。
【００９８】
上記のように所定時間経過後に対話が終了したり、あるいは、買い物メモの作成途中（Ｓ５において冷蔵庫１ａと対話中）に、ユーザが一旦冷蔵庫１ａを離れたりするなどの状態で、購入が決断されないままに買い物メモの作成が中断することが想定される。この場合、作成途中の買い物メモは、買い物メモＤＢ３６に維持されており、ユーザは、冷蔵庫１ａと対話を再開させることで、中断した買い物メモの作成を再開することができる。
【００９９】
この再開のトリガとしては、例えば、以下のものが想定される。
・ユーザが、冷蔵庫１ａに対して買い物メモの作成を再開したい旨の発話を行う。
・買い物メモが中断されると、冷蔵庫１ａが、買い物メモ中断を意味するボタンを点滅させて、再び冷蔵庫１ａに近づいたユーザに対して注意喚起する。点滅したボタンをユーザが押下することにより、冷蔵庫１ａが買い物メモ作成に係る対話を再開させる。
・作成途中の買い物メモが買い物メモＤＢ３６に記録されている場合、音声制御部２１が、最終登録日時から一定時間経過後に、冷蔵庫１ａから話しかけるように、冷蔵庫１ａを制御する。これにユーザが応答することにより、買い物メモ作成が再開される。
【０１００】
あるいは、買い物メモＤＢ３６に商品の登録がなくても、音声制御部２１は、適切な時機に冷蔵庫１ａから話しかけるように、冷蔵庫１ａを制御してもよい。具体的には、音声制御部２１は、購入履歴ＤＢ３５を参照して、周期的に購入している商品を特定し、次回の発注タイミングを予測する。そして、音声制御部２１は、当該発注タイミングになったら、冷蔵庫１ａから話しかけるように、冷蔵庫１ａを制御する。これにユーザが応答することにより、買い物メモ作成が開始される。
【０１０１】
（購入代行処理の流れ−詳細）
図１０は、購入代行サーバ２が実行する購入代行処理の流れを示すフローチャートである。まず、音声制御部２１は、対話の終了イベントが通知されない限り、冷蔵庫１ａを制御して買い物メモ作成に係る対話（図９のＳ４）を継続する（Ｓ１０１）。
【０１０２】
ここで、購入代行部２２は、対話ログＤＢ３１を監視し、商品の品名が発話されたことを検知した場合（Ｓ１０２でＹＥＳ）（検知ステップ）、その商品の購入意思を意味するキーワード（例えば、合言葉）が発話されたか否かを監視する（Ｓ１０３）。
【０１０３】
購入代行部２２が合言葉が発話されたことを検知すると（Ｓ１０３でＹＥＳ）、次に、認証部２２１は、Ｓ１０３で検知された合言葉と、そのユーザについて事前に合言葉ＤＢ３２に登録されている合言葉とを比較する（Ｓ１０４）。ここで、合言葉が一致しなかった場合には、購入代行処理は中断される。この場合（Ｓ１０４でＮＯ）、音声制御部２１が、例えば「合言葉が違うよ。もう一度言って」などの機器発話データを冷蔵庫１ａに供給し、ユーザに合言葉をもう一度言わせるように対話を継続させてもよい。
【０１０４】
上記２つの合言葉が一致した場合（Ｓ１０４でＹＥＳ）、認証部２２１は、購入代行処理の続行を許可し、一連の処理が継続される。具体的には、発注品特定部２２２は、定常商品リストＤＢ３３を参照して、Ｓ１０２で検知された品名に対応付けられた商品正式名および個数を特定する（Ｓ１０５）（特定ステップ）。さらに、品名に発注先が関連付けられている場合には、発注品特定部２２２は、その商品の発注先を特定してもよい（Ｓ１０６）。
【０１０５】
発注部２２４は、発注品特定部２２２によって特定された発注先の店舗サーバ４に対して、クライアントＩＤと対応付けて正式商品名および個数を送信し、注文を確定させる（Ｓ１０７）（発注ステップ）。必要に応じて、購入代行部２２は、発注が完了した商品について、購入履歴を購入履歴ＤＢ３５に登録してもよい（Ｓ１０８）。
【０１０６】
（ＵＩの具体例）
図１１は、購入代行システム１００のサービスを利用するにあたり、最初に、ユーザ登録を行うためのＵＩの一具体例を示す。特に、図１１は、購入補助端末３に表示される合言葉登録画面を示す。合言葉登録画面は、ユーザが合言葉を購入代行サーバ２に登録するためのものである。
【０１０７】
図１１に示すとおり、ユーザは、購入補助端末３を操作して、合言葉をテキストデータで入力する。入力する合言葉は、複数あってもよい。合言葉登録画面を介して購入補助端末３に合言葉（テキストデータ）が入力されると、購入補助端末３のＵＩ処理部５２１は、クライアントＩＤとともに上記テキストデータを購入代行サーバ２に送信する。購入代行サーバ２は、受信したテキストデータを合言葉ＤＢ３２に格納する。
【０１０８】
なお、購入代行サーバ２の購入代行部２２は、買い物メモの作成に係る対話が行われる前であっても、合言葉と品名とが発話されていれば、該品名に対応する商品の購入代行処理を実行できる。これにより、ユーザは、合言葉を発話することによって、定常商品の購入に際し、冷蔵庫との対話（買い物メモ作成のためのやりとり）をスキップして、すぐに定常商品の購入を冷蔵庫１ａに指示することができる。
【０１０９】
図１２は、ユーザ登録を行うためのＵＩの別の一具体例を示す。特に、図１２は、購入補助端末３に表示される定常商品設定画面を示す。定常商品設定画面は、ユーザが、定常商品を選択し、その定常商品の商品正式名および個数を購入代行サーバ２に対して指定するためのものである。
【０１１０】
図１２に示される定常商品設定画面は、購入代行サーバ２の要求処理部２３が、定常商品リストＤＢ３３に記憶されている、定常設定可能品目を示すテーブル（図５の（ａ））を参照して作成する。
【０１１１】
ＵＩ処理部５２１が定常商品設定画面を処理することにより以下が実現される。ユーザは、品名に対応する左のカラムにチェックを入れることで、定常商品に設定したい商品を選択することができる。品名にチェックを入れると、１品名につき、１つの商品正式名にチェックを入れて指定することができる。商品正式名のチェックは、１品名につき、１つにしか入れることができないように、ＵＩ処理部５２１が排他的に制御している。ＵＩ処理部５２１は、品名にチェックが入っていない場合には、商品正式名を選択することができないように制御し、そのことが視覚的に分かるように、品名未選択の商品正式名のチェックボックスを非表示あるいは目立たなくしてもよい。また、ＵＩ処理部５２１は、商品正式名が１つ選択された場合には、選択された商品正式名を強調表示して、その他の商品正式名が選択されていないことを視覚的に表現してもよい。さらに、ＵＩ処理部５２１は、品名と商品正式名とがチェックされたレコードにおいては、個数を自由に変更することができるような入力セルを設ける。ここで、さらに配達希望日時（曜日）などを指定できるカラムを設けてもよい。
【０１１２】
品名および商品正式名にチェックが入り、個数が入力された状態で、設定終了ボタン（不図示）が押下されると、ＵＩ処理部５２１は、選択された品名、および、それに対応付けて指定された商品正式名および個数を、クライアントＩＤとともに購入代行サーバ２に送信する。購入代行サーバ２は、受信した情報を定常商品リストＤＢ３３に格納する（図５の（ｂ））。
【０１１３】
図１３の（ａ）〜（ｄ）および図１４は、購入補助端末３に表示される買い物メモ作成画面を示す。買い物メモ作成画面は、ユーザが、購入を予定している商品および個数をリストアップするためのものである。
【０１１４】
本実施形態では、買い物メモの作成は、冷蔵庫１ａとの対話のみによって作成することが可能である。しかし、図１３の（ａ）〜（ｄ）に示すとおり、ユーザは、必要に応じて、対話によって作成進行中の買い物メモを購入補助端末３に表示させることも可能である。音声制御部２１が解析したテキストデータに品名が含まれている場合、音声要求処理部２４は、買い物メモＤＢ３６にその品名に対応する商品のレコードを追加する。要求処理部２３は、購入補助端末３から買い物メモ作成画面を要求するリクエストを受け付けた場合、対話ログＤＢ３１および買い物メモＤＢ３６を参照して、図１３の（ａ）〜（ｄ）に示すような買い物メモ作成画面を生成し、購入補助端末３に供給する。冷蔵庫１ａの「他には何かある？」の問いかけに対して、ユーザが、買い物メモの作成を終了させる旨の発話（「おわり」など）を行うと、音声要求処理部２４は、買い物メモＤＢ３６に完成した買い物メモを格納して買い物メモの作成処理を終了する。そして、冷蔵庫１ａは、買い物メモに登録した商品の購入を促すメッセージを購入代行サーバ２の制御下で出力する。
【０１１５】
さらに、本実施形態では、図１４に示すとおり、買い物メモ作成画面は、リストアップした商品を購入するように購入代行サーバ２に対して指示するための購入支援ツールとしても機能する。買い物メモが完成すると、要求処理部２３は、図１４に示す買い物メモ作成画面を生成して、購入補助端末３に供給する。完成した買い物メモを表示する買い物メモ作成画面には、購入を促すメッセージが、冷蔵庫１ａのキャラクターのイラストとともに表示されてもよい。
【０１１６】
ＵＩ処理部５２１は、図１４に示すとおり、買い物メモにおいて登録された品名ごとに、ユーザが購入フラグのＯＮ／ＯＦＦを設定できるようなチェックボックスを設けるとともに、購入代行サーバ２に対して購入を指示するための購入確定ボタンを設ける。ＵＩ処理部５２１は、一般商品について、商品正式名が指定されず品名だけが音声で登録されたレコード（図１４の例では品名「ヨーグルト」）については、商品正式名および個数が特定できず注文ができないため、購入フラグを「ＯＮ」にできないようにＵＩを制御する。
【０１１７】
１つ以上の商品について購入フラグが「ＯＮ」の状態で、購入確定ボタンが押下されると、ＵＩ処理部５２１は、購入フラグが「ＯＮ」の商品の品名または商品正式名を購入代行サーバ２に送信し、その商品の購入を購入代行サーバ２に対して要求する。
【０１１８】
さらに、要求処理部２３は、商品正式名を指定する必要があるレコード、すなわち、品名しか特定されていない一般商品のレコードについて、ユーザが商品正式名を指定するための商品指定画面を生成し、購入補助端末３に供給する。
【０１１９】
図１５の（ａ）〜（ｄ）は、購入補助端末３に表示される商品指定画面を示す。購入代行サーバ２の音声制御部２１は、一般商品について、品名のみが発話された場合、購入補助端末３の商品指定画面を見るように促すメッセージを冷蔵庫１ａに出力させる。
【０１２０】
ＵＩ処理部５２１は、要求処理部２３によって供給された商品指定画面を介して、発話された品名に対応する複数の商品正式名の候補を選択可能に提示する（図１５の（ｃ））。ユーザは、単にチェックを入れる操作を行うだけでよい。これにより、ユーザは、具体的にどの商品を意図しているのかについて、その商品正式名を知らなくとも、購入代行サーバ２に対して指定することができる。
【０１２１】
所望の商品正式名にチェックを入れた状態でユーザが購入確定ボタンを押下すると、ＵＩ処理部５２１は、選択された商品正式名をクライアントＩＤとともに購入代行サーバ２に送信し、その商品の購入を要求する。なお、購入補助端末３に表示された買い物メモを介して購入活動が行われる場合、合言葉は要求されない。購入補助端末３の認証は、必要に応じて従来技術を用いて実行される。
【０１２２】
なお、一般商品のリストが含まれた画面（例えば、図１５の（ｃ））は、要求処理部２３が、店舗サーバ４から得られる商品の情報と、記憶部１３に記憶されている情報とに基づいて作成するものである。店舗サーバ４によって提供される商品の一覧画面が購入補助端末３にそのまま転送されるわけではない。なお、定常商品と一般商品との区別、および、品名と商品正式名との対応関係は、購入代行サーバ２と店舗サーバ４とによって共有されている。これにより、購入代行サーバ２は、商品指定画面を、店舗サーバ４が保持する商品リストを参照して作成することができる。
【０１２３】
さらに、図１６の（ａ）〜（ｃ）に示すとおり、要求処理部２３は、購入確定ボタンが押下されたことに応答して一度発注を完了させると、購入履歴ＤＢ３５を参照して、ユーザにおすすめすべき商品を選択して、購入を促す購入誘導画面を生成してもよい。図１６の（ａ）に示すとおり、購入誘導画面には、対話の相手である冷蔵庫１ａのキャラクターからのおすすめメッセージが含まれていてもよい。さらに、図１６の（ｄ）に示すとおり、要求処理部２３は、購入確定ボタンが押下されたことに応答して一度発注を完了させると、その発注が完了した商品の配達予定日時を通知する配達予定日通知画面を生成してもよい。配達予定日は、発注品特定部２２２によって特定されてもよいし、発注部２２４による注文を受け付けた店舗サーバ４から通知されてもよい。
【０１２４】
さらに、図１７の（ａ）および（ｂ）に示すとおり、要求処理部２３は、購入履歴ＤＢ３５を参照して、購入履歴画面を生成して購入補助端末３に供給してもよい。購入補助端末３が表示する購入履歴画面には、発注が完了した商品の現在のステータスが含まれていることが好ましい。また、ユーザは、購入履歴画面を操作して、ステータスを更新することが可能である。具体的には、ユーザは、注文した商品が届くと、届いた商品のレコードに対して配達完了のチェックを入れて、「届いたよ！」と記載された配達完了ボタンを押下する。ＵＩ処理部５２１は、チェックが入った品名の商品の配達が完了したことを示す情報を購入代行サーバ２に送信する。要求処理部２３は、上記情報を受信したことに応答して、購入履歴ＤＢ３５において、チェックが入った品名のレコードについて、ステータスを「配達完了」に更新する。
【０１２５】
以上、実施形態１に係る購入代行システム１００の各装置の構成および購入代行処理の方法について説明した。上記構成および方法によれば、ユーザは、商品の一般名詞など、単純な言葉を冷蔵庫１ａに対して音声入力するだけで、簡単に、当該商品の購入活動を実施することができる。すなわち、店舗サーバ４に注文する際に必要な情報（商品正式名、個数、発注先および配達日時など）は、ユーザによって発話された上記品名に基づいて購入代行サーバ２が特定するので、ユーザは、商品の品名を発話するだけで済む。
【０１２６】
このように、本発明の購入代行システム１００は、ユーザが最低限実行しなければならない購入のために必要な工程（購入希望商品を指定する工程）を、簡易な入力手段（音声入力）で実現し、その他の購入活動ための複雑な操作を購入代行サーバ２が代行することで、結果として、ユーザが簡易に購入活動を行うことを可能にする。
【０１２７】
また、購入のために必要な工程を実施するための簡易な入力手段（音声入力）は、冷蔵庫１ａなどの家庭内機器に設けられている。したがって、家庭内での生活の導線に沿って、適切なタイミングで購入活動を促すことができる。具体的には、冷蔵庫１ａを使用し、必要な食材の取り出し、在庫の確認、買い物メモの作成などを行っているその場で、冷蔵庫１ａを使って購入活動を実施することができる。結果として、ユーザが購入の機会を逃すことがなくなる。
【０１２８】
さらに、本発明の購入代行システム１００によれば、冷蔵庫１ａと通信する購入代行サーバ２において、冷蔵庫１ａとユーザとの対話ログ、作成された買い物メモ、購入履歴）が蓄積される構成である。これにより、マーケティングの観点から利用価値の高い情報が手に入るというメリットがある。
【０１２９】
〔実施形態２〕
本発明の他の実施形態について、図１８、図１９に基づいて説明すれば、以下のとおりである。なお、説明の便宜上、前記実施形態にて説明した部材と同じ機能を有する部材については、同じ符号を付記し、その説明を省略する。
【０１３０】
本実施形態では、図２に示す購入代行システム１００において、１つの定常商品について発注先の店舗が複数存在し、固定されていない。そのため購入代行サーバ２は、定常商品の購入を代行するとき、動的に発注先の店舗（店舗サーバ４）を選択する必要がある。
【０１３１】
実施形態２の購入代行サーバ２において、実施形態１の購入代行サーバ２と異なる点は、購入代行部２２が発注先選択部２２３を含んでいる点である。発注先選択部２２３は、発注品特定部２２２によって特定された商品（および個数）を購入可能な店舗が複数ある場合に、所定の条件にしたがって発注先の店舗を１つ選択する。発注先選択部２２３は、店舗情報ＤＢ３４を参照したり、各店舗サーバ４とやりとりして店舗サーバ４の最新の情報を取得したりして、上記条件に最も合致する店舗を発注先として１つ選択する。
【０１３２】
例えば、「販売価格が最も安いこと」という条件が事前に規定されている場合、発注先選択部２２３は、各店舗の店舗サーバ４から最新の商品価格表を取得し、発注時に販売価格が一番安い店舗を選択する。あるいは、「配達日が最も早いこと」という条件が規定されている場合、発注先選択部２２３は、各店舗サーバ４から配達予定日を取得して、配達予定日が最も早い店舗を選択してもよい。さらには、これらの条件の組み合わせにしたがって、販売価格と配達予定日とを総合的に考慮して最も好ましい条件の店舗を選択してもよい。例えば、ユーザに、購入補助端末３を介して、「節約モード」および「お急ぎモード」のいずれかを選択させておく。発注先選択部２２３は、「節約モード」が設定されている場合、販売価格の安さを最も重要視して店舗を選択し、「お急ぎモード」が設定されている場合、配達日の早さを最も重要視して店舗を選択する。発注先選択部２２３は、複数の商品がまとめて発話された場合でも、より条件のよい発注先を求めて、個々の商品ごとに発注先を選択することができる。
【０１３３】
上記構成によれば、発注先選択部２２３が条件に基づいて発注先を商品ごとに選択してくれる。したがって、発注先が複数あっても、ユーザは、１つの買い物リストと１つの合言葉を使って、発注先の多様性を意識することなく、１回の購入活動で、欲しい商品をより好条件にて全て注文することができる。
【０１３４】
あるいは、発注先選択部２２３は、複数の商品をまとめて１つの店舗に注文する場合、複数の商品の販売価格合計、または、全商品の中で最も遅い配達予定日に基づいて、最もよい条件の店舗を選択することができる。
【０１３５】
１：定常商品を第１のルート（音声入力）を介して購入する場合
図１８の（ａ）および（ｂ）を参照して、具体例を用いて発注先選択部２２３の機能を説明すると以下のとおりである。冷蔵庫１ａとの対話で、ユーザが「たまご」と「牛乳」とを購入することが判明したとする。ここで、発注品特定部２２２は、上記品名に基づいて、上記ユーザについて「たまご」および「牛乳」の商品正式名（商品ＩＤ）をそれぞれ特定する。
【０１３６】
「販売価格が最も安いこと」という条件が規定されている場合、発注先選択部２２３は、特定された商品正式名（商品ＩＤ）について、各店舗の販売価格を取得する。販売価格は、記憶部１３にあらかじめ記憶されている店舗ごとの商品ＤＢ（不図示）から取得されてもよいし、各店舗の店舗サーバ４に対して、商品正式名（商品ＩＤ）を送信して問合せを行い、最新の販売価格を取得してもよい。
【０１３７】
発注先選択部２２３は、各店舗における「たまご」および「牛乳」の販売価格を取得すると、その販売価格合計を店舗ごとに比較する。例えば、発注先選択部２２３は、図１８の（ａ）に示すとおり、発注日現在の価格比較表を生成してもよい。図１８の（ａ）に示す例では、発注日（２０１５／１２／２５）現在、「たまご」および「牛乳」の販売価格合計が最も安いのは「スーパーＢ」となる。そこで、発注先選択部２２３は、上記ユーザの「たまご」および「牛乳」の発注先として、「スーパーＢ」を選択する。発注先選択部２２３が選択した店舗の店舗ＩＤは、発注部２２４に伝達される。発注部２２４は、発注先選択部２２３が選択した店舗に対して、「たまご」および「牛乳」を発注する。
【０１３８】
なお、「配達日が最も早いこと」という条件が規定されている場合、発注先選択部２２３は、各店舗サーバ４に、商品正式名（商品ＩＤ）を送信して配達予定日の問合せを行い、各商品の配達予定日を取得する。ここで、以下の配達予定日を各店舗の店舗サーバ４から受信したとする。
スーパーＡ：たまご「当日」、牛乳「明日」
スーパーＢ：たまご「明日」、牛乳「明日」
スーパーＣ：たまご「当日」、牛乳「当日」
この場合、すべて商品を最も早く配達できるのは、「スーパーＣ」であるので、発注先選択部２２３は、「たまご」および「牛乳」の発注先として、「スーパーＣ」を選択する。
【０１３９】
さらに、「たまご」と「牛乳」とに続けて「ヨーグルト」が発話され、この３つの商品を購入することが判明したとする。「販売価格が最も安いこと」という条件が規定されている場合、発注先選択部２２３は、図１８の（ｂ）に示す価格比較表を生成する。該価格比較表によれば、３つの商品の販売価格合計が最も安いのは「スーパーＡ」である。そこで、発注先選択部２２３は、上記ユーザの「たまご」、「牛乳」および「ヨーグルト」の発注先として、「スーパーＢ」を選択する。
【０１４０】
２：商品を第２のルート（購入補助端末３の画面操作）を介して購入する場合
図１９の（ａ）および（ｂ）を参照して、具体例を用いて発注先選択部２２３の機能を説明すると以下のとおりである。ユーザが、購入補助端末３の買い物メモ作成画面を操作して、「たまご」、「牛乳」および「ヨーグルト」を購入する操作を行ったとする。「たまご」、「牛乳」および「ヨーグルト」の商品正式名は、発注品特定部２２２によって特定されるか、または、買い物メモ作成画面においてすでに指定されているものとする。
【０１４１】
ここで、「販売価格が最も安いこと」という条件が規定されている場合、発注先選択部２２３は、第１のルートの場合と同様に、図１８の（ｂ）に示す価格比較表を生成してもよい。さらに、発注先選択部２２３は、販売価格合計が安い順に各店舗をソートして順位付けする。要求処理部２３は、発注先選択部２２３によって生成された価格比較表および順位付けにしたがって、店舗のランキング表示画面を生成する。
【０１４２】
購入補助端末３のＵＩ処理部５２１は、図１９の（ａ）に示すとおり、要求処理部２３から供給されたランキング表示画面を、店舗を選択可能なＵＩとして表示する。その際、ＵＩ処理部５２１は、「販売価格が最も安いこと」という条件に基づくランキングであることを視覚的に明示することが好ましい。例えば、節約モードを意味する「節約」タブを付けることが考えられる。
【０１４３】
一方、「配達日が最も早いこと」という条件が規定されている場合、発注先選択部２２３は、第１のルートの場合と同様に、各店舗に各商品の配達予定日を問い合わせる。そして、１つの店舗につき、すべての商品の中で最も遅い配達予定日を、その店舗の最終配達予定日として決定する。続いて、発注先選択部２２３は、最終配達予定日が早い順に各店舗をソートして順位付けする。要求処理部２３は、発注先選択部２２３によって決定された最終配達予定日の順位付けにしたがって、店舗のランキング表示画面を生成する。
【０１４４】
購入補助端末３のＵＩ処理部５２１は、図１９の（ｂ）に示すとおり、要求処理部２３から供給されたランキング表示画面を、店舗を選択可能なＵＩとして表示する。その際、ＵＩ処理部５２１は、「配達日が最も早いこと」という条件に基づくランキングであることを視覚的に明示することが好ましい。例えば、お急ぎモードを意味する「お急ぎ」タブを付けることが考えられる。
【０１４５】
上記構成によれば、ユーザは、購入補助端末３を操作して、自分にとって最も条件のよい店舗を、購入代行サーバ２に対して指定することができる。ランキング表示画面において店舗が１つ指定されると、ＵＩ処理部５２１は、指定された店舗の店舗ＩＤを、クライアントＩＤとともに購入代行サーバ２に送信する。発注先選択部２２３は、上記店舗ＩＤを取得して、その店舗ＩＤが示す店舗を発注先として選択する。
【０１４６】
なお、店舗情報ＤＢ３４において、店舗ごとに点数が管理されていてもよい。この場合、発注先選択部２２３は、発注先を選択する際に、上記点数が最も高い店舗を発注先として選択することが考えられる。上記点数は、各店舗が購入代行サーバ２に対して代金を支払うことにより加算されてもよい。つまり、店舗は、購入代行サーバ２が自店舗を発注先として優先的に選択することの見返りに、購入代行サーバ２に対して対価（広告料）を払うという、ビジネスモデルが構築される。
【０１４７】
〔実施形態３〕
本発明の他の実施形態について、以下のとおり説明する。なお、説明の便宜上、前記実施形態にて説明した部材と同じ機能を有する部材については、同じ符号を付記し、その説明を省略する。
【０１４８】
上述の各実施形態では、定常商品を設定するために、ユーザが、購入補助端末３に表示された定常商品設定画面（図１２）を操作する方法が提供された。本実施形態では、音声入力によって、より簡易に、定常商品を設定する方法を提示する。
【０１４９】
実施形態３では、音声要求処理部２４は、購入履歴ＤＢ３５を参照し、購入された回数が所定条件を満たした一般商品を検出する。条件を満たした一般商品を検出した場合、その一般商品を定常商品として設定することを提案するように、音声制御部２１に対して指示する。
【０１５０】
音声制御部２１は、音声要求処理部２４からの指示にしたがって機器発話データを生成し、冷蔵庫１ａに供給し、定常商品として設定することを提案する発話を冷蔵庫１ａに行わせる。
【０１５１】
例えば、音声要求処理部２４は、購入履歴ＤＢ３５を参照して、同一の商品正式名の商品が、同一個数で購入された回数が所定数（例１０回）を超えている商品およびその購入個数を特定する。具体例を挙げると、音声要求処理部２４は、あるユーザについて、商品正式名「栄養卵ひかり  Ｍ玉  １０個パック」が「２個」購入された回数が、１１回であることを検出する。音声要求処理部２４は、定常商品リストＤＢ３３のテーブル（図５の（ａ）を参照し、「栄養卵ひかり  Ｍ玉  １０個パック」に対応する品名「たまご」を特定する。音声要求処理部２４は、商品正式名「栄養卵ひかり  Ｍ玉  １０個パック」および個数「２個」を、品名「たまご」として定常商品化することを、上記ユーザに提案するよう音声制御部２１に依頼する。
【０１５２】
音声制御部２１は、例えば、「栄養卵ひかり  Ｍ玉  １０個パックを２個、いつも買っているね！この商品は、『たまご』で、定常商品に設定することができるよ！設定する？」という機器発話データを生成し、上記ユーザの冷蔵庫１ａに発話させる。
【０１５３】
この発話に応答して、例えば、ユーザが「ＯＫ！」と発話すると、音声制御部２１は、上記提案が受け入れられたと判断する。音声要求処理部２４は、提案が受け入れられたと判断された場合に、先に特定しておいた、商品正式名「栄養卵ひかり  Ｍ玉  １０個パック」および個数「２個」を、品名「たまご」に対応付ける。そして、音声要求処理部２４は、定常商品リストＤＢ３３のテーブル（図５の（ｂ））において、上記ユーザのクライアントＩＤに関連付けて、上記の品名、商品正式名および個数を新規に登録する。
【０１５４】
上記構成によれば、ユーザは、自身が頻繁に購入している商品について、「ＯＫ！」という発話１つで簡易に定常商品の設定を行うことができる。ユーザは、自身がどんな商品をどれくらいの頻度で購入しているのかを意識する必要もなければ、購入補助端末３にて定常商品設定画面を呼び出して、自発的に定常商品を設定するための操作を行う必要もない。結果として、より一層利便性の高い購入代行システムを実現することができる。
【０１５５】
定常商品化を提案するときの購入回数の条件は、上記に限定されない。音声要求処理部２４は、例えば、所定期間（３カ月）に所定回数（４回）以上、同じ商品が同じ個数で購入された場合に、定常商品化を提案してもよい。あるいは、音声要求処理部２４は、購入タイミングが周期的である商品について、定常商品化を提案してもよい。
【０１５６】
なお、購入代行サーバ２は、購入補助端末３の操作画面を介して、一般商品の定常商品化を提案することも可能である。この場合、例えば、図１７の（ａ）または（ｂ）に示す購入履歴画面において、同図の「般」のアイコンが付与されている（一般商品の）レコードに「定常化ボタン」を追加すればよい。該定常化ボタンが押下されると、購入補助端末３のＵＩ処理部５２１は、定常化ボタンが押された商品を特定する情報を購入代行サーバ２の要求処理部２３に通知する。これにより、要求処理部２３は、購入回数に関係なく、一般商品から定常商品への設定変更を実行する。このようにすれば、ユーザは、比較的簡易な操作で、一般商品から定常商品への設定変更を行うことが可能となる。
【０１５７】
〔変形例〕
上述の各実施形態では、購入代行システム１００は、購入補助端末３を含んでいるが必須ではない。本発明の購入代行システム１００において、ユーザは、購入補助端末３に表示される画面を確認したり、操作したりせずとも、冷蔵庫１ａとの対話によってのみ、定常商品の購入活動を実行したり、定常商品の買い物メモを作成したりすることができる。
【０１５８】
上述の各実施形態では、購入代行サーバ２は、買い物メモ機能（要求処理部２３および買い物メモＤＢ３６）を備えているが、必須ではない。購入代行部２２は、買い物メモＤＢ３６に商品が登録されていなくとも、対話ログＤＢ３１において、ユーザが品名を発話したことを検知したことに基づいて、購入代行処理を実行することができる。
【０１５９】
上述の各実施形態では、購入代行装置１として、冷蔵庫１ａを想定しているが、購入代行装置１としての家電は、家庭内に複数あってもよい。例えば、冷蔵庫１ａに加えて電子レンジ１ｂが購入代行装置として設けられていてもよい。この場合、電子レンジ１ｂに記憶されているレシピ情報に基づいて、電子レンジ１ｂとの対話によって、必要な食材の買い物メモが作成されたり、購入代行処理が実行されたりする。なお、家庭内に購入代行装置１としての家電が複数設けられる場合には、これらの家電と、購入代行サーバ２とのやりとりを仲介して取りまとめを行うホームサーバが設置されることが望ましい。
【０１６０】
上述の各実施形態では、セキュリティの観点から、ユーザの購入意思を意味する所定のキーワード（合言葉など）が発話されない限り、発注部２２４は発注を行わない構成である。しかし、利便性を高める観点から、品名が発話されたことをもってその商品の発注が実行されるように購入代行部２２を構成することも可能である。ただし、品名と所定のキーワードとが発話された場合に発注する構成であれば、ユーザが購入希望と無関係に品名を口にしたときに、誤って商品が発注されることを防ぐことができるのでより好ましい。
【０１６１】
なお、購入代行処理は、冷蔵庫１ａと同様にホームネットワークに接続されている他の家電（例えば、テレビ）と連携して、動的に実行されてもよい。例えば、「今テレビで放送されていた商品がほしい」というユーザの発話に対応して、発注品特定部２２２が、ユーザ所望の商品の商品識別情報を特定できてもよい。また、データ放送で表示されたパスワードを、購入を確定させるための合言葉として利用してもよい。
【０１６２】
上述の各実施形態において、第１のルート、すなわち、冷蔵庫１ａへの音声入力によって、購入活動が実施される場合、購入代行サーバ２は、発注を完了させる直前に、冷蔵庫１ａに、購入予定の商品正式名、個数、および、価格を復唱させて、発注の了解を得ることが好ましい。さらには、購入代行サーバ２は、最終的に注文を確定させるボタンを、購入補助端末３に表示させて、その画面を見るようにユーザを誘導するメッセージを冷蔵庫１ａに発話させてもよい。ユーザが上記画面にて上記ボタンを押下することにより、発注部２２４が発注を完了させる。
【０１６３】
上述の各実施形態では、対話機能（音声制御部２１の音声解析部および音声生成部、ならびに、音声フォーマット、辞書など）のすべてを購入代行サーバ２が備えている構成であった。しかし、本発明の購入代行システム１００において、対話機能は、全て冷蔵庫１ａに設けられていてもよいし、購入代行サーバ２および冷蔵庫１ａに分散して設けられていてもよい。例えば、冷蔵庫１ａには、簡易的な対話機能を搭載し、当該対話機能で対応できない場合に、購入代行サーバ２の対話機能が対話を制御することが考えられる。
【０１６４】
上述の各実施形態では、発注部２２４が発注を行う相手は、１店舗に対応する１つの店舗サーバ４である。しかし、発注先の店舗の形態はこれに限定されない。例えば、発注部２２４が発注を行う相手は、ショッピングモールや商店街などのような複数の店舗の集合体に対応する１台のサーバであってもよい。この場合、決済は、店舗単位で行われず、上記集合体単位で実行される。
【０１６５】
なお、店舗サーバ４は、ＥＣ事業者または配達業者などが所有する他のサーバと連携し、購入代行サーバ２から受け付けた発注商品の配達を、上記他のサーバを介して、ＥＣ事業者または配達業者などに委託してもよい。
【０１６６】
〔実施形態４〕
上記各実施形態では、１つの購入代行サーバ２を用いる例を説明したが、購入代行サーバ２の有する各機能が、個別のサーバにて実現されていてもよい。そして、複数のサーバを適用する場合においては、各サーバは、同じ事業者によって管理されていてもよいし、異なる事業者によって管理されていてもよい。
【０１６７】
〔実施形態５〕
購入代行装置１、購入代行サーバ２および購入補助端末３の各ブロックは、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。後者の場合、購入代行装置１、購入代行サーバ２および購入補助端末３のそれぞれを、図２０に示すようなコンピュータ（電子計算機）を用いて構成することができる。
【０１６８】
図２０は、購入代行装置１、購入代行サーバ２または購入補助端末３として利用可能なコンピュータ９１０の構成を例示したブロック図である。コンピュータ９１０は、バス９１１を介して互いに接続された演算装置９１２と、主記憶装置９１３と、補助記憶装置９１４と、入出力インターフェース９１５と、通信インターフェース９１６とを備えている。演算装置９１２、主記憶装置９１３、および補助記憶装置９１４は、それぞれ、例えばＣＰＵ、ＲＡＭ（random access memory）、ハードディスクドライブであってもよい。入出力インターフェース９１５には、ユーザがコンピュータ９１０に各種情報を入力するための入力装置９２０、および、コンピュータ９１０がユーザに各種情報を出力するための出力装置９３０が接続される。入力装置９２０および出力装置９３０は、コンピュータ９１０に内蔵されたものであってもよいし、コンピュータ９１０に接続された（外付けされた）ものであってもよい。例えば、入力装置９２０は、キーボード、マウス、タッチセンサなどであってもよく、出力装置９３０は、ディスプレイ、プリンタ、スピーカなどであってもよい。また、タッチセンサとディスプレイとが一体化されたタッチパネルのような、入力装置９２０および出力装置９３０の双方の機能を有する装置を適用してもよい。そして、通信インターフェース９１６は、コンピュータ９１０が外部の装置と通信するためのインターフェースである。
【０１６９】
補助記憶装置９１４には、コンピュータ９１０を購入代行装置１、購入代行サーバ２または購入補助端末３として動作させるための各種のプログラムが格納されている。そして、演算装置９１２は、補助記憶装置９１４に格納された上記プログラムを主記憶装置９１３上に展開して該プログラムに含まれる命令を実行することによって、コンピュータ９１０を、購入代行装置１、購入代行サーバ２または購入補助端末３が備える各部として機能させる。なお、補助記憶装置９１４が備える、プログラム等の情報を記録する記録媒体は、コンピュータ読み取り可能な「一時的でない有形の媒体」であればよく、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブル論理回路などであってもよい。
【０１７０】
また、上記プログラムは、コンピュータ９１０の外部から取得してもよく、この場合、任意の伝送媒体（通信ネットワークや放送波等）を介して取得してもよい。そして、本発明は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
【０１７１】
〔まとめ〕
本発明の態様１に係るシステム（購入代行システム１００）は、ネットワークを介して商品を注文するシステムであって、上記システムは、以下を含む；購入者（ユーザ）が行った発話を音声データとして取得する音声入力部（マイク４３）、取得された上記音声データ（ユーザ発話データ）から、購入を希望する商品の品名が発話されたことを検知する検知部（購入代行部２２）、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部（記憶部１３の定常商品リストＤＢ３３）、上記記憶部から、検知された上記品名に対応付けられた商品識別情報（商品正式名／商品ＩＤ）を特定する特定部（発注品特定部２２２）、少なくとも特定された上記商品識別情報を上記発注先サーバ（店舗サーバ４）に送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部（発注部２２４）。
【０１７２】
上記の構成によれば、音声入力部が、購入者の発話を音声データとして取得し、検知部が、音声データから、購入を希望する商品の品名が発話されたことを検知する。特定部は、発話された品名から、その品名の商品識別情報を特定する。特定部は、記憶部を参照することにより品名から商品識別情報を特定することができる。記憶部には、購入者ごとに、品名に対応付けて商品識別情報が記憶されているからである。発注部は、特定部によって特定された商品識別情報を発注先サーバに送信することにより、購入者が発話した商品を発注先に注文する。発注先サーバには、品名ではなく、商品識別情報が送信されるので、発注先サーバは、購入者に提供すべき商品を一意に識別することが可能である。
【０１７３】
以上のとおり、発注先サーバに対して購入希望商品を正確に指定するまでの間に、購入者がしなければならないことは、購入を希望する商品の品名を発話することのみである。こうして本発明のシステムは、電子商取引における購入活動のうち、購入者が実行せざるを得ない購入希望商品を指定するという作業を、音声入力という簡易な入力手段で実現する。当該システムは、その後の作業に関し、発注先サーバに対する発注を誤りなく代行する（購入希望商品を正確に発注先に指定する）。結果として、購入者が簡易に購入活動を行うことを可能にする、利便性の高い購入代行システムを実現することができる。
【０１７４】
本発明の態様２に係るサーバ（購入代行サーバ２）は、ネットワークを介して商品を注文するサーバであって、上記サーバは、以下を含む；購入者が行った発話の音声データから、購入を希望する商品の品名が発話されたことを検知する検知部、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部、上記記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定部、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部。上記の構成によれば、態様１に係るシステムと同様の効果を奏する。
【０１７５】
本発明の態様３に係るサーバは、上記態様２のサーバにおいて、上記検知部は、上記品名とともに、購入者の購入の意思を意味する所定のキーワードが発話されたことを検知し、上記発注部は、上記キーワードが検知された場合に注文する。上記の構成によれば、購入者が購入希望と無関係に品名を口にしたときに、誤って商品が発注されることを防ぐことができる。
【０１７６】
本発明の態様４に係るサーバは、上記態様２または３において、以下を含む；上記購入者を認証する認証部、上記記憶部には、購入者と所定の合言葉とが対応付けて記憶されており、上記認証部は、購入者によって発話された合言葉と、上記記憶部において上記購入者に対応付けられた合言葉とが一致する場合に、上記発注部に対して注文することを許可する。
【０１７７】
上記の構成によれば、サーバに対して購入を指示できるのは、合言葉を知る者だけに限定される。したがって、商品を購入する権限を持つ者のみが知り得る合言葉を用いることにより、商品を購入する権限を持たない者の発話によって誤って商品が発注されることを防ぐことができる。
【０１７８】
本発明の態様５に係るサーバは、上記態様２から４のいずれかにおいて、上記記憶部には、購入者ごとに、品名に、商品の個数がさらに対応付けて記憶されており、上記特定部は、さらに、個数を特定し、上記発注部は、特定された上記商品識別情報および個数を上記発注先サーバに送信する。
【０１７９】
上記の構成によれば、特定部は、発話された品名から、その品名の商品識別情報に加えて、購入個数を特定する。特定部は、記憶部を参照することにより品名から商品識別情報および個数を特定することができる。記憶部には、購入者ごとに、品名に対応付けて、商品識別情報に加えてさらに個数が記憶されているからである。発注部は、特定部によって特定された商品識別情報および個数を発注先サーバに送信することにより、購入者が発話した商品を発注先に注文する。発注先サーバには、商品識別情報に加えて個数が送信されるので、発注先サーバは、購入者に提供すべき商品とその個数を把握することができる。結果として、購入者が簡易に購入活動を行うことを可能にする、より利便性の高い購入代行システムを実現することができる。
【０１８０】
本発明の態様６に係るサーバは、上記態様２から５のいずれかにおいて、上記記憶部には、購入者ごとに、品名に、発注先がさらに対応付けて記憶されており、上記発注部は、検知された上記品名に対応付けられた発注先に注文する。
【０１８１】
上記の構成によれば、特定部は、発話された品名から、さらに発注先を特定する。特定部は、記憶部を参照することにより、品名から、商品識別情報、個数および発注先を特定することができる。記憶部には、購入者ごとに、品名に対応付けて、商品識別情報および個数に加えてさらに発注先が記憶されているからである。発注部は、特定部によって特定された商品識別情報および個数を、特定部によって特定された発注先の発注先サーバに送信することにより、購入者が発話した商品を注文する。これにより、購入者が意図する決まった発注先に注文を送ることが可能となる。結果として、購入者が簡易に購入活動を行うことを可能にする、より利便性の高い購入代行システムを実現することができる。
【０１８２】
本発明の態様７に係るサーバは、上記態様２から６のいずれかにおいて、以下を含む；上記特定部によって特定された商品識別情報が示す商品の発注先を選択する選択部（発注先選択部２２３）、上記選択部は、複数の発注先の中から、上記商品を提供可能な発注先を選択し、上記発注部は、上記選択部によって選択された発注先に注文する。
【０１８３】
上記の構成によれば、発注先が複数あって、特に、購入者によって発注先が指定されていない場合でも、選択部が、複数の発注先の中から、購入すべき商品を提供可能な発注先を選択することができる。なお、提供可能な発注先がさらに複数存在する場合には、選択部は、条件が最も良い発注先を選択してもよい。例えば、販売価格が最安値の発注先、または、配達予定日が最先の発注先を選んでもよい。結果として、購入者が簡易に購入活動を行うことを可能にする、より利便性の高い購入代行システムを実現することができる。
【０１８４】
本発明の態様８に係るサーバは、上記態様２から７のいずれかにおいて、以下を含む；上記購入者が購入を希望する商品および個数を指定するための購入画面（買い物メモ作成画面）を生成する生成部（要求処理部２３）、上記発注部は、上記購入画面を表示して上記購入者の操作を受け付ける端末（購入補助端末３／スマートフォン）から受信した、上記購入者によって指定された商品の商品識別情報および個数を、上記発注先サーバに送信することにより、上記購入者が購入を希望する商品を、発注先に注文する。
【０１８５】
上記の構成によれば、サーバは、記憶部に品名が登録されていない商品（一般商品）について、音声入力を介しての購入指示は受け付けられないが、端末に表示される購入画面を介して、購入者の購入活動を支援することが可能となる。購入者は、音声入力によって簡易に購入活動を実施したい場合と、購入画面を操作して、詳細な内容を自ら指定して購入活動を実施したい場合とで、これらの購入ツールを使い分けることができる。
【０１８６】
本発明の態様９に係るサーバは、上記態様８において、以下を含む；上記購入者と対話する装置（購入代行装置１、冷蔵庫１ａ、電子レンジ１ｂ）に、上記購入画面を介して購入された商品の品名を発話させて、上記記憶部への登録を促す音声制御部（音声制御部２１）、上記装置による上記発話に対して、上記購入者が登録に同意する旨の発話したことが、上記検知部によって検知された場合に、上記品名と該品名に対応する商品識別情報とを、上記購入者に対応付けて上記記憶部に登録する登録部（音声要求処理部２４）。
【０１８７】
上記の構成によれば、購入画面を介して商品が購入された場合に、音声制御部は、今後その商品を、音声入力のみで簡易に購入することができるように、記録部への登録を購入者に促す。購入者が登録に同意すれば、登録部は、その購入者に対応付けて、上記商品の品名と商品識別情報とを上記記憶部に登録する。
【０１８８】
これにより、購入者は、一度購入画面を操作して購入した商品について、音声入力だけで、簡易に、記憶部に登録することができる。記憶部にその商品が登録されたということは、これ以後、当該商品については購入画面を操作せずとも、音声入力だけで購入活動を実施することができるということを意味する。結果として、購入者が簡易に購入活動を行うことを可能にする、より利便性の高い購入代行システムを実現することができる。
【０１８９】
本発明の態様１０に係る装置（購入代行装置１、冷蔵庫１ａ、電子レンジ１ｂ）は、ネットワークを介して商品を注文するサーバと通信する装置であって、上記サーバは、以下を含む；購入者が行った発話の音声データから、購入を希望する商品の品名が発話されたことを検知する検知部、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部、上記記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定部、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部、上記装置は、以下を含む；上記装置が出力する発話の音声データ（機器発話データ）を上記サーバから受信する受信部（通信部４１）、上記受信部によって受信された上記音声データを出力する音声出力部（スピーカ４４）、購入者が行った発話を音声データ（ユーザ発話データ）として取得する音声入力部（マイク４３）、上記音声入力部によって取得された上記音声データを上記サーバに送信する送信部（通信部４１）。
【０１９０】
上記の構成によれば、上記システムのうち、購入者の発話を受け付ける音声入力部の機能をサーバとは別の装置が担う。これにより、購入者は、購入希望商品を指定するという作業（音声入力）を、購入者の身近に設置され使用されている装置を用いて実施することができる。したがって、ユーザが購入の機会を逃すことなく、簡易に購入活動を行うことを可能にする、より利便性の高い購入代行システムを実現することが可能となる。
【０１９１】
本発明の態様１１に係る装置は、上記態様１０において、冷蔵庫（１ａ）であって、さらに以下を含む；冷蔵庫のドアの開閉を検知する開閉センサ部（開閉センサ４６）、上記音声入力部は、上記開閉センサ部によってドアの開閉が検知された場合に、上記購入者が行った発話を音声データとして取得する。
【０１９２】
これにより、ユーザが冷蔵庫を使用しているときに、冷蔵庫に対して音声を入力することで、簡単に、商品の購入を、装置およびサーバに対して指示することができる。冷蔵庫を使用（ドアを開閉）しているときは、ユーザが、在庫の不足に気づいたりして、購買意欲が最も高まっているときであると考えられる。このように、ユーザが冷蔵庫を使用しているときに、音声入力による購入作業を可能にすることにより、ユーザが購入の必要性を失念したり、気が変わったりして、購入の機会を逃す虞がなくなる。
【０１９３】
本発明の態様１２に係る端末（購入補助端末３、スマートフォン）は、ネットワークを介して商品を注文するサーバと通信する端末であって、上記サーバは、以下を含む；購入者が行った発話の音声データから、購入を希望する商品の品名が発話されたことを検知する検知部、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部、上記記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定部、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注部、上記購入者が購入を希望する商品および個数を指定するための購入画面を生成する生成部、上記端末は、以下を含む；上記購入画面を上記サーバから受信する受信部（通信部５１）、上記受信部によって受信された上記購入画面を表示する表示部（５５）、上記購入画面に対する操作を受け付けて、該操作によって指定された商品の商品識別情報および個数を特定するＵＩ処理部（５２１）、特定された上記商品識別情報および上記個数を上記サーバに送信する送信部（通信部５１）、上記サーバの上記発注部は、上記端末から受信した、上記商品識別情報および上記個数を上記発注先サーバに送信することにより、上記購入者が購入を希望する商品を、発注先に注文する。上記の構成によれば、態様８に係るサーバと同様の効果を奏する。
【０１９４】
本発明の態様１３に係るシステムの制御方法は、ネットワークを介して商品を注文するシステムの制御方法であって、上記システムの制御方法は、以下を含む；購入者が行った発話を音声データとして取得する音声取得ステップ（Ｓ２）、取得された上記音声データから、購入を希望する商品の品名が発話されたことを検知する検知ステップ（Ｓ１０２）、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定ステップ（Ｓ１０５）、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した品名の商品を、発注先に注文する発注ステップ（Ｓ１０７）。上記の方法によれば、態様１に係るシステムと同様の効果を奏する。
【０１９５】
本発明の態様１４に係るサーバの制御方法は、ネットワークを介して商品を注文するサーバの制御方法であって、上記サーバの制御方法は、以下を含む；購入者が行った発話の音声データから、購入を希望する商品の品名が発話されたことを検知する検知ステップ（Ｓ１０２）、購入者ごとに、品名に、発注先サーバが商品を一意に識別可能な商品識別情報を対応付けて記憶する記憶部から、検知された上記品名に対応付けられた商品識別情報を特定する特定ステップ（Ｓ１０５）、少なくとも特定された上記商品識別情報を上記発注先サーバに送信することにより、上記購入者が発話した商品を、発注先に対して注文する発注ステップ（Ｓ１０７）。上記の方法によれば、態様２に係るサーバと同様の効果を奏する。
【０１９６】
本発明の態様１５に係るサーバは、上記態様２〜９のいずれかにおいて、以下を含む；検知部によって検知された品名を、上記記憶部（記憶部１３の買い物メモＤＢ３６）に格納されている購入予定リスト（買い物メモ）に登録するリスト作成部（音声要求処理部２４）、上記発注部は、所定時刻になると上記購入予定リストに登録された品名の商品を、発注先に注文する。
【０１９７】
上記の構成によれば、音声入力によって購入予定リストに登録された品名に基づいて、商品識別情報などが特定部によって特定される。発注部は、特定された商品識別情報を所定時刻になると発注先サーバに送信する。
【０１９８】
購入予定リストに登録された商品はすなわち購入希望商品である。したがって、態様２のサーバと同様に、発注先サーバに対して購入希望商品を正確に指定するまでの間に、購入者がしなければならないことは、購入を希望する商品の品名を発話することのみであることに変わりがない。結果として、購入者が簡易に購入活動を行うことを可能にする、利便性の高い購入代行システムを実現することができる。
【０１９９】
本発明の各態様に係るサーバ、装置および端末は、コンピュータによって実現してもよく、この場合には、コンピュータを上記サーバ、装置または端末が備える各部（ソフトウェア要素）として動作させることにより上記サーバ、装置または端末をコンピュータにて実現させるサーバ、装置または端末の制御プログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。
【０２００】
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。さらに、各実施形態にそれぞれ開示された技術的手段を組み合わせることにより、新しい技術的特徴を形成することができる。
【符号の説明】
【０２０１】
１  購入代行装置（装置／家庭内機器／家電）、１ａ  冷蔵庫（装置／家庭内機器／家電）、１ｂ  電子レンジ（装置／家庭内機器／家電）、２  購入代行サーバ（サーバ）、３  購入補助端末（端末／スマートフォン）、４  店舗サーバ（発注先サーバ）、１３  記憶部、２１  音声制御部、２２  購入代行部（検知部）、２３  要求処理部（生成部）、２４  音声要求処理部（登録部／リスト作成部）、３１  対話ログＤＢ、３２  合言葉ＤＢ、３３  定常商品リストＤＢ（記憶部）、３４  店舗情報ＤＢ、３５  購入履歴ＤＢ、３６  買い物メモＤＢ、４１  通信部（受信部／送信部）、４３  マイク（音声入力部）、４４  スピーカ（音声出力部）、４５  操作部、４６  開閉センサ（開閉センサ部）、５１  通信部（受信部／送信部）、５４  操作部、５５  表示部、１００  購入代行システム（システム）、２２１  認証部、２２２  発注品特定部（特定部）、２２３  発注先選択部（選択部）、２２４  発注部、４２１  音声制御部、５２１  ＵＩ処理部
【図１】
0006707352.tif 000002
【図２】
0006707352.tif 000003
【図３】
0006707352.tif 000004
【図４】
0006707352.tif 000005
【図５】
0006707352.tif 000006
【図６】
0006707352.tif 000007
【図７】
0006707352.tif 000008
【図８】
0006707352.tif 000009
【図９】
0006707352.tif 000010
【図１０】
0006707352.tif 000011
【図１１】
0006707352.tif 000012
【図１２】
0006707352.tif 000013
【図１３】
0006707352.tif 000014
【図１４】
0006707352.tif 000015
【図１５】
0006707352.tif 000016
【図１６】
0006707352.tif 000017
【図１７】
0006707352.tif 000018
【図１８】
0006707352.tif 000019
【図１９】
0006707352.tif 000020
【図２０】
0006707352.tif 000021