特許 7402794 商品のバスケットについての高速学習推薦システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-13

(45)【発行日】2023-12-21

(54)【発明の名称】商品のバスケットについての高速学習推薦システム

(51)【国際特許分類】

   G06Q 30/0601 20230101AFI20231214BHJP

   G06Q 50/12 20120101ALI20231214BHJP

【ＦＩ】

G06Q30/0601

G06Q50/12

【請求項の数】 14

(21)【出願番号】P 2020528119

(86)(22)【出願日】2019-03-26

(65)【公表番号】

(43)【公表日】2021-08-12

(86)【国際出願番号】 US2019024024

(87)【国際公開番号】W WO2019203994

(87)【国際公開日】2019-10-24

【審査請求日】2022-01-11

(31)【優先権主張番号】15/955,054

(32)【優先日】2018-04-17

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】モダレシ，サジャド

(72)【発明者】

【氏名】バーンスタイン，フェルナンド

(72)【発明者】

【氏名】サウレ，デニス

(72)【発明者】

【氏名】ボロジェニ，セターレ・ボージアン

(72)【発明者】

【氏名】ウ，ス－ミン

(72)【発明者】

【氏名】コー，ロバート

(72)【発明者】

【氏名】ニコラキス，ニコス

【審査官】小原 正信

(56)【参考文献】

【文献】米国特許出願公開第２０１６／００６３５６６（ＵＳ，Ａ１）

【文献】米国特許第０７６８０７０３（ＵＳ，Ｂ１）

【文献】特開２０１６－２０６７３４（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／００９１３１９（ＵＳ，Ａ１）

【文献】特開２０１０－２３８１１８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

プロセッサが実行する方法であって、前記方法は、商品のバスケットの受信に応答して追加のアイテムについての推薦を提供する方法であって、前記方法は、
１組のバスケットタイプから前記商品のバスケットについてのタイプを判断するステップと、
１組の追加のターゲット化アイテムをターゲット推薦として受信するステップと、
受信された商品のバスケットのタイプの履歴を受信するステップと、
前記受信された商品のバスケットのタイプの履歴に基づいた前記バスケットタイプの各々の複数のクラスタへのクラスタ化と、前記ターゲット化アイテムの各々についての前記複数のクラスタの各々への嗜好更新とを複数回の限度回数まで繰り返し実行するステップとを含み、前記繰り返し実行するステップは、複数の繰り返しの後に、マッピングのシーケンスと嗜好パラメータのシーケンスとを出力するステップを有し、
前記方法はさらに、
前記マッピングのシーケンスからマッピングの集計の頻度を生成するステップと、
前記マッピングのシーケンス、前記嗜好パラメータのシーケンス、および前記マッピングの集計の頻度に基づいて前記推薦を生成するステップとを含み、
前記嗜好更新は、前記複数のクラスタの各々について、嗜好パラメータの組を生成することを含み、前記クラスタの各々の前記嗜好パラメータの組は、前記ターゲット化アイテムの各々についての当該クラスタの嗜好を示す要素を有したベクトルであり、
前記嗜好パラメータのシーケンスは、前記嗜好更新において生成された前記限度回数にあたる数の前記嗜好パラメータの組を示す、方法。

【請求項2】

前記１組の追加のターゲット化アイテムは、競合的であるとしてフラグを立てられ、前記推薦を生成するステップは、ザウレアルゴリズムを実行するステップを含む、請求項１に記載の方法。

【請求項3】

前記１組の追加のターゲット化アイテムは、非競合的であるとしてフラグを立てられ、前記推薦を生成するステップは、トンプソンサンプリングを実行するステップを含む、請求項１または２に記載の方法。

【請求項4】

前記商品のバスケットは、顧客によってレストランで現在の訪問中に注文されたアイテムを含む、請求項１～３のいずれか１項に記載の方法。

【請求項5】

前記商品のバスケットは、顧客によってホテルで現在の訪問中に購入された商品およびサービスを含む、請求項１～３のいずれか１項に記載の方法。

【請求項6】

前記１組の追加のターゲット化アイテムが非競合的であるとしてフラグを立てられる場合、前記嗜好更新はベイズ更新を含む、請求項１～５のいずれか１項に記載の方法。

【請求項7】

前記１組の追加のターゲット化アイテムが競合的であるとしてフラグを立てられる場合、前記嗜好更新はバスケット集計による更新を含む、請求項１～６のいずれか１項に記載の方法。

【請求項8】

請求項１～７のいずれか１項に記載の方法をプロセッサに実行させるためのプログラム。

【請求項9】

推薦システムであって、
命令を格納する記憶デバイスに結合されたプロセッサを含み、前記プロセッサは、商品のバスケットの受信に応答して追加のアイテムについての推薦を提供するための前記命令を実行し、
前記プロセッサは、１組のバスケットタイプから前記商品のバスケットについてのタイプを判断し、１組の追加のターゲット化アイテムをターゲット推薦として受信し、受信された商品のバスケットのタイプの履歴を受信し、
前記プロセッサは、前記受信された商品のバスケットのタイプの履歴に基づいた前記バスケットタイプの各々の複数のクラスタへのクラスタ化と、前記ターゲット化アイテムの各々についての前記複数のクラスタの各々への嗜好更新とを複数回の限度回数まで繰り返し実行し、前記繰り返し実行することは、複数の繰り返しの後に、マッピングのシーケンスと嗜好パラメータのシーケンスとを出力し、
前記プロセッサは、前記マッピングのシーケンスからマッピングの集計の頻度を生成し、前記マッピングのシーケンス、前記嗜好パラメータのシーケンス、および前記マッピングの集計の頻度に基づいて前記推薦を生成し、
前記嗜好更新は、前記複数のクラスタの各々について、嗜好パラメータの組を生成することを含み、前記クラスタの各々の前記嗜好パラメータの組は、前記ターゲット化アイテムの各々についての当該クラスタの嗜好を示す要素を有したベクトルであり、
前記嗜好パラメータのシーケンスは、前記嗜好更新において生成された前記限度回数にあたる数の前記嗜好の組を示す、推薦システム。

【請求項10】

前記１組の追加のターゲット化アイテムは、競合的であるとしてフラグを立てられ、前記推薦を生成することは、ザウレアルゴリズムを実行することを含む、請求項９に記載の推薦システム。

【請求項11】

前記１組の追加のターゲット化アイテムは、非競合的であるとしてフラグを立てられ、前記推薦を生成することは、トンプソンサンプリングを実行することを含む、請求項９または１０に記載の推薦システム。

【請求項12】

前記商品のバスケットは、顧客によってレストランで現在の訪問中に注文されたアイテムを含む、請求項９～１１のいずれか１項に記載の推薦システム。

【請求項13】

前記商品のバスケットは、顧客によってホテルで現在の訪問中に購入された商品およびサービスを含む、請求項９～１１のいずれか１項に記載の推薦システム。

【請求項14】

前記嗜好更新は、前記１組の追加のターゲット化アイテムが非競合的であるとしてフラグを立てられる場合には、ベイズ更新を含み、前記１組の追加のターゲット化アイテムが競合的であるとしてフラグを立てられる場合には、バスケット集計による更新を含む、請求項９～１３のいずれか１項に記載の推薦システム。

【発明の詳細な説明】

【技術分野】

【0001】

分野
一実施形態は一般に、推薦を提供するコンピュータシステムに向けられ、特に、速やかに変化する提供物にとって好適な推薦を提供するコンピュータシステムに向けられる。

【背景技術】

【0002】

背景情報
オンライン小売業者にとって、「推薦システム」を使用することはますます一般的になってきている。推薦システムとは、ある顧客の購入履歴および他のすべての顧客の購入履歴に基づいて、顧客へのアイテムの推薦を行なうシステムである。そのようなシステムは、レストランまたはホテル業界では比較的それほど一般的ではない。そのような業界では、推薦はしばしば、顧客の購入を分析するシステム化されたソフトウェアアルゴリズムアプローチではなく、人間の直観を使用するような、その場限りの手段によって行なわれる。

【0003】

ソフトウェアアプローチが使用される場合であっても、それは遅すぎて、変化する提供物ならびに変化する顧客ミックスおよび嗜好に適応できないことに苦慮するかもしれない。レストラン業界では、同じオーダーでどのアイテムが購入されたかについての履歴調査を行ない、そのような調査から推薦を生成することが可能である。しかしながら、履歴の調査がおそらくそのコストのせいでめったに行なわれない場合、そのような推薦は静的である。履歴の調査が頻繁に行なわれる場合であっても、システムがその推薦を変更し得る前に入ってくるべき新たなデータの量のせいで、公知のシステムは依然として適応するのが遅い。

【発明の概要】

【課題を解決するための手段】

【0004】

概要
実施形態は、商品のバスケットの受信に応答して追加のアイテムについての推薦を提供する方法を提供する。実施形態は、１組のバスケットタイプから商品のバスケットについてのタイプを判断し、１組の追加のターゲット化アイテムをターゲット推薦として受信し、受信された商品のバスケットのタイプの履歴を受信する。実施形態は、受信された商品のバスケットのタイプの履歴に基づいたバスケットタイプの各々の複数のクラスタへのクラスタ化と、ターゲット化アイテムの各々についての複数のクラスタの各々への嗜好更新とを繰り返し実行する。繰り返し実行することは、複数の繰り返しの後に、マッピングのシーケンスと嗜好パラメータのシーケンスとを出力する。実施形態は、マッピングのシーケンスからマッピングの集計の頻度を生成し、次に、マッピングのシーケンス、嗜好パラメータのシーケンス、およびマッピングの集計の頻度に基づいて推薦を生成する。

【図面の簡単な説明】

【0005】

【図1】ここに開示されるコンポーネントのうちのいずれかを実現し得る、実施形態に従ったコンピュータサーバ／システムのブロック図である。

【図2】一実施形態に従った、商品またはサービスのバスケットに基づいて追加の商品およびサービスを推薦する場合の図１の推薦モジュールの機能のフロー図である。

【図3】一実施形態に従った、商品またはサービスのバスケットに基づいて追加の商品およびサービスを推薦する場合の図１の推薦モジュールの機能のフロー図である。

【図4】この発明の実施形態に従ったＵＩのスクリーンショットを示す図である。

【図5】この発明の実施形態に従ったＵＩのスクリーンショットを示す図である。

【図6】この発明の実施形態に従った高レベルのシステム図である。

【発明を実施するための形態】

【0006】

詳細な説明
一実施形態は、レストランまたはホテルへの１回の訪問で顧客によって購入された商品およびサービスのバスケット全体を分析し、その分析に基づき、バスケットの内容に基づいて追加の商品およびサービスを推薦するシステムである。実施形態は、推薦を行なうために必要な履歴データの量を最小化し、このため、決定の速度を上げる。

【0007】

図１は、本発明の一実施形態に従ったコンピュータサーバ／システム１０のブロック図である。単一のシステムとして図示されているが、システム１０の機能は、分散型システムとして実現され得る。また、ここに開示される機能は、ネットワークを通してともに結合され得る別個のサーバまたはデバイス上で実現され得る。また、システム１０の１つ以上のコンポーネントが含まれていなくてもよい。たとえば、サーバの機能に関し、システム１０はプロセッサとメモリとを含む必要があり得るが、キーボードまたはディスプレイといった、図１に示す他のコンポーネントのうちの１つ以上を含んでいなくてもよい。

【0008】

システム１０は、情報を通信するためのバス１２または他の通信機構と、バス１２に結合された、情報を処理するためのプロセッサ２２とを含む。プロセッサ２２は、任意のタイプの汎用または特定用途プロセッサであってもよい。システム１０はさらに、プロセッサ２２によって実行される命令および情報を格納するためのメモリ１４を含む。メモリ１４は、ランダムアクセスメモリ（random access memory：ＲＡＭ）、読出専用メモリ（read only memory：ＲＯＭ）、磁気ディスクまたは光ディスクなどの静的ストレージ、もしくは任意の他のタイプのコンピュータ読取可能媒体の任意の組合せから構成され得る。システム１０はさらに、ネットワークへのアクセスを提供するための、ネットワークインターフェイスカードなどの通信デバイス２０を含む。したがって、ユーザは、システム１０と直接、またはネットワークを通してリモートで、または任意の他の方法でインターフェイス接続してもよい。

【0009】

コンピュータ読取可能媒体とは、プロセッサ２２によってアクセスされ得る利用可能なあらゆる媒体であってもよく、揮発性媒体および不揮発性媒体、リムーバブル媒体および非リムーバブル媒体の双方、ならびに通信媒体を含む。通信媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュール、もしくは、搬送波または他の移送機構などの変調データ信号における他のデータを含んでいてもよく、任意の情報伝送媒体を含む。

【0010】

プロセッサ２２はさらに、バス１２を介して、液晶ディスプレイ（Liquid Crystal Display：ＬＣＤ）などのディスプレイ２４に結合される。キーボード２６とコンピュータマウスなどのカーソル制御デバイス２８とがさらにバス１２に結合され、ユーザがシステム１０とインターフェイス接続することを可能にする。

【0011】

一実施形態では、メモリ１４は、プロセッサ２２によって実行された場合に機能を提供するソフトウェアモジュールを格納する。モジュールは、システム１０のためのオペレーティングシステム機能を提供するオペレーティングシステム１５を含む。モジュールはさらに、商品またはサービスのバスケットに基づいて追加の商品およびサービスを推薦する推薦モジュール１６と、ここに開示されるすべての他の機能とを含む。システム１０は、より大きいシステムの一部であってもよい。したがって、システム１０は、オラクル・コーポレイションからの「ホスピタリティ・シンフォニー」（Hospitality Simphony）販売時点情報管理（point of sale：ＰＯＳ）クラウドおよびモバイルホスピタリティ管理プラットフォームといった追加機能を含むための１つ以上の追加機能モジュール１８を含んでいてもよい。データベース１７がバス１２に結合されて、モジュール１６および１８のための集中格納を提供し、顧客データ、製品データ、トランザクションデータなどを格納する。一実施形態では、データベース１７は、格納されたデータを管理するために構造化問合せ言語（Structured Query Language：ＳＱＬ）を使用できるリレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）である。一実施形態では、専用の販売時点情報管理（ＰＯＳ）端末１００が、ユーザがユーザインターフェイスを使用して選択を行ない、推薦を受信することを可能にするクライアントデバイスとして機能する。ＰＯＳ端末１００は、有線または無線を含む任意の通信手段を通して、またはインターネットなどの付加ネットワークを介して、システム１０の残りに結合される。ＰＯＳ端末１００自体は、ここに開示される機能のうちの一部またはすべてを実行可能であり、それ自体のプロセッサ、メモリなどを含む。

【0012】

一実施形態では、特に多数のレストラン／ホテル、多数のアイテム、および大量の履歴データがある場合、データベース１７は、インメモリデータベース（in-memory database：ＩＭＤＢ）として実現される。ＩＭＤＢとは、コンピュータデータ記憶のために主としてメインメモリに依拠するデータベース管理システムである。それは、ディスク記憶機構を採用するデータベース管理システムと対比される。メインメモリデータベースは、ディスク最適化データベースよりも速い。なぜなら、ディスクアクセスはメモリアクセスよりも遅く、内部最適化アルコリズムはより単純であり、より少数のＣＰＵ命令を実行するためである。メモリ内のデータにアクセスすることは、そのデータを問合せる際のシーク時間をなくし、それは、ディスクよりも高速でより大きな予測可能性を提供する。

【0013】

一実施形態では、データベース１７は、ＩＭＤＢとして実現される場合、分散データグリッドに基づいて実現される。分散データグリッドとは、分散されたまたはクラスタ化された環境内で、コンピュータサーバの集まりが、１つ以上のクラスタ内でともに作動して、情報と計算などの関連動作とを管理するシステムである。分散データグリッドは、サーバ間で共有されるアプリケーションオブジェクトおよびデータを管理するために使用され得る。分散データグリッドは、少ない応答時間、高スループット、予測可能なスケーラビリティ、連続的な利用可能性、および情報信頼性を提供する。特定の例では、たとえばオラクル・コーポレイションからの「オラクル・コヒーレンス」（Oracle Coherence）データグリッドなどの分散データグリッドは、情報をメモリに格納して、より高い性能を達成し、また、その情報のコピーを複数のサーバ間で同期させたままにする際に冗長性を採用し、このため、サーバが故障した場合のシステムの復元力およびデータの連続的な利用可能性を保証する。

【0014】

一実施形態では、システム１０は、企業組織のためのアプリケーションまたは分散アプリケーションの集まりを含むコンピューティング／データ処理システムであり、物流、製造、および在庫管理機能も実現してもよい。アプリケーションおよびコンピューティングシステム１０は、クラウドベースのネットワーキングシステム、ソフトウェア・アズ・ア・サービス（software-as-a-service：ＳａａＳ）アーキテクチャ、または他のタイプのコンピューティングソリューションを用いて動作するように構成されてもよく、もしくは、そのようなものとして実現されてもよい。

【0015】

一般に、履歴トランザクションの調査も、多くの公知の推薦システムによって行なわれているように、過度に単純化されるかもしれない。これは、公知のシステムは一般に、あるオーダーでともに生じるアイテムのペアのみを調査するためであり、これは相関ルールマイニング（Association Rule Mining：ＡＲＭ）と呼ばれる。代わりに、この発明の実施形態と同様に、ともに取られたオーダーにおける全アイテムの組は、オーダーのタイプまたはオーダーを出す個人のタイプのより良好な指標であり、この追加情報を使用することは、より良好でより正確な推薦をもたらし得る。さらに、ＡＲＭを使用する公知のシステムは典型的には、推薦を改良するためにも使用され得る顧客に関する人口統計学的情報をまったく勘案しない。

【0016】

また、レストランのための推薦に具体的に関連するように、レストランでは提供物が頻繁に変化し、これらの変化は、提供物の数がレストランでの数よりもはるかに多い小売りでのそのような変化よりもはるかに大きい効果を与え得る。たとえば、食料品店での品揃えは頻繁に変化するが、典型的な食料品店は６００００個の最小在庫管理単位（stock keeping unit：ＳＫＵ）を抱え得るため、任意の１つの品揃えの変化は、総売上高に対して比較的小さい全体的効果しか与えないと思われる。対照的に、レストランはたった数百個の異なるアイテムしか提供しないかもしれず、また、推薦がメインディッシュといったたった１つのタイプのアイテムに重点を置く場合、推薦はたった数十個に限定されるかもしれない。新しいメインディッシュを追加することは、顧客に対して著しい効果を与えると思われ、公知の推薦システムは一般に、その効果に十分速やかに適応することができない。

【0017】

また、オンライン小売業者は一般に、ある顧客の全購入履歴が利用可能になるように顧客によるトランザクションにタグ付けすることを意味する、「顧客にリンクされたトランザクション」を採用する推薦システムを使用する。お得意様カードプログラムを有する旧来の小売業者も一般に、このアプローチを使用する。しかしながら、このアプローチは一般に、典型的にはお得意様カードプログラムを有していないレストランにとっては有用ではない。対照的に、この発明の実施形態は、現在のオーダーにおけるアイテムのみに基づいて推薦を行なうことができ、したがって、顧客にリンクされたトランザクションが利用できない場合でも使用可能である。

【0018】

レストランと同様に、実施形態は、顧客が部屋番号によって識別され得るホテル業界でも特に有用である。顧客はしばしば勘定をホテルの自分の部屋に付けるため、ホテルは、顧客が１回の滞在中に購入したアイテムおよびサービスのリストを見ることができる。このリストは、レストランの顧客が１回の訪問中に注文する１組のアイテムと類似しており、ホテルで利用可能な他のアイテムおよびサービスの推薦を生成するために、この発明の実施形態によって同様に使用され得る。最高級のホテルでは、アイテムおよびサービスの提供物はかなり多いかもしれず、実施形態は、ホテルが、他のどのアイテムおよびサービスを顧客に推薦するべきかを判断することを可能にし得る。

【0019】

また、実施形態は、顧客の部屋番号すら必要とすることなく顧客の購入および賭博を追跡するための稼働中のシステムを概してすでに有しているカジノホテルでも使用可能である。カジノは典型的には、顧客にお得意様カードを発行し、顧客が商品またはサービスの購入または賭博を行なう際はいつでもお得意様カードをスキャンするための稼働中のシステムを現在有している。この発明の実施形態は、これらのシステムとともに機能して、お得意様カードがスキャンされた時に別の製品またはサービスについての推薦を生成することができる。

【0020】

実施形態では、「バスケット」または「商品のバスケット」とは、顧客がこれらのタイプの施設（たとえば、レストラン、ホテル、カジノホテルなど）のうちのいずれかへの１回の訪問で購入した１組の商品またはサービスを意味する。レストランについては、バスケットとは、一実施形態では、単にオーダーにおけるフードおよびドリンクアイテムである。ホテルまたはカジノについては、バスケットとは、一実施形態では、数日を含み得る１回の滞在中に顧客が注文した１組の商品およびサービスである。カジノは加えて、滞在中に顧客がどの形式の博打を使用したかをバスケットに追加してもよい。

【0021】

また、実施形態における「推薦」は、施設の特定タイプに依存する。レストランについては、推薦は、追加のフードまたはドリンクアイテムであってもよい。ホテルについては、推薦は、フードおよびドリンクを含む、ホテルが販売するあらゆるアイテム、ならびに、温泉サービスまたはクリーニングサービスまたはルームサービスといった、ホテルが提供し得るあらゆるサービスであってもよい。カジノについては、推薦は、カジノ特有の商品またはサービスも含んでいてもよい。

【0022】

アイテムのペアのみを使用する代わりに、実施形態は、顧客によって購入されたアイテムのバスケット全体を使用することができる。たとえば、実施形態は、オーダーに子供向けの食事がいくつあるかといった、オーダー全体の特徴を使用して、その推薦を生成することができる。ホテルについては、実施形態は、顧客が注文したルームサービスがいくらであったかを、顧客が温泉を訪れたかどうかとともに使用することができる。対照的に、ＡＲＭを使用する公知のソリューションは、推薦を行なう際にアイテムのペアしか考慮しないことが多い。

【0023】

実施形態はまた、バスケット全体とともに、顧客の人口統計学的属性を使用することができる。たとえば、実施形態は、顧客の年齢が分かればそれを使用することができ、したがって、購入中のアイテムのバスケットが異なる顧客によって購入されたものと同じであっても、顧客の年齢に基づいて顧客に異なる製品またはサービスを推薦することができる。

【0024】

したがって、この発明の実施形態は、顧客の購入の以下の特徴のうちの一部またはすべてを使用する能力を有する：
● 顧客のバスケットにおける個々のアイテム；
● バスケット全体の全体的特徴；
● 顧客の人口統計学的属性。

【0025】

実施形態は、提供物の変化または顧客嗜好の変化に適応するために必要なデータの量を減少させるための、以下により詳細に開示されるアルゴリズム／規則を使用する。実施形態は、レストランおよびホテルに最も関連する、上に開示された３つの特徴に概して基づいて、推薦を生成する。

【0026】

これら３つの特徴に基づいて、各バスケットは、いくつかの異なる「タイプ」のうちの１つに分類される。特定の１組の特徴、すなわち、特定のバスケット特徴および特定の人口統計学的属性と、異なるタイプとは、入力として提供され、レストランまたはホテルによって提供される。たとえば、非常に単純な１組のタイプは、バスケットにおいてお金がいくら費やされたかを示す階層であってもよく、そのため、階層は、施設での顧客の購買意欲を示すようになっている。典型的には、タイプはより複雑であり、レストランまたはホテルがそのビジネスにとって重要であると考える顧客特徴を反映するであろう。たとえば、レストランでの１組のタイプは、オーダーが前菜を含んでいたかどうか、注文されたメインディッシュの価格階層、および、オーダーが子供向けの食事を含んでいたかどうか、であってもよい。このため、タイプは、これらの属性のすべての組合せになるであろう。そのため、メインディッシュの階層が３つあった場合、すべてのオーダーを分類するためのタイプは合計で２×３×２個になるであろう。

【0027】

実施形態によって使用される第２の入力は、どの組の商品またはサービスが推薦のためのターゲットになるかである。たとえば、レストランでは、推薦ターゲットは、レストランが供する前菜およびドリンクのすべてを含んでいてもよい。典型的には、レストランは、推薦ターゲットを特定のアイテムに限定したいであろう。なぜなら、別のメインディッシュといったあるアイテムは、推薦する意味がないためである。レストランはまた、特定のアイテムの販売促進に関心があるかもしれない。同様に、ホテルについては、推薦される特定の商品およびサービスは限定され得る。

【0028】

実施形態は次に、ターゲットセットからどの推薦を各バスケットタイプについて行なうかを、履歴データから発見する。実施形態は、推薦を発見し、同時に、どのタイプが互いに類似し、そのため組合され得るかを発見することによって、推薦を生成するための時間を著しく減少させるための、以下により詳細に開示される規則／アルゴリズムを使用する。クラスタとは、１組の類似するタイプであり、これらのタイプは類似するため、クラスタ全体についての推薦は同じであり得る。したがって、実施形態は、異なる推薦を必要とするタイプの数を効果的に減少させ、これは、正しい推薦を発見するために必要なデータの量を減少させる。

【0029】

さらに、タイプのクラスタへのグループ化は動的であり、変化する提供物および顧客および顧客嗜好に適応することができる。したがって、提供物が変化し、顧客嗜好が変化するにつれて、同じクラスタ内にあった２つのタイプが今では異なるクラスタ内にある、ということが起こり得る。実施形態は、新しい購入データが入ってくるにつれて動的に適応するであろう。

【0030】

一般に、この開示のために、一実施形態における「組織」とは、単一のレストランチェーン、または単一のホテルチェーンのいずれかである。一実施形態における「場所」とは、そのホテルチェーン内のある特定のホテル、またはそのレストランチェーン内のある特定のレストランである。一実施形態における「アイテム」とは、商品またはサービスのいずれかである。

【0031】

一実施形態では、「バスケット」とは、顧客によって１回の訪問内で購入された１組のアイテムである。バスケットはまた、特定の組織に依存して、購入されたアイテムの他に、それに添付された追加データを有していてもよい。たとえば、組織は、顧客に関する人口統計学的データを所有する場合、そのようなデータをバスケットに添付してもよい。「バスケット」という用語は、購入された１組のアイテムと、任意の追加の添付データとを指す。添付データは組織によって定義され、実施形態は、組織によって定義された任意のデータが適切なデータベースに格納され、バスケットに適切に関連付けられている限り、当該データを用いて機能することができる。

【0032】

一実施形態では、「タイプ別バスケット」とは、組織が１組のタイプおよび各バスケットのタイプのために使用すると定めたものを指す。その関連付けられたタイプを有するバスケットが、「タイプ別バスケット」である。実施形態は、タイプの説明を何ら必要とはしない。代わりに、バスケットをタイプラベルに関連付ける手段が必要とされる。たとえば、この発明はタイプの説明を必要とはしないため、タイプラベルは単に整数であってもよい。バスケットをタイプラベルに関連付けることは、この発明の実施形態を実現するために、組織によって前もって実行される。

【0033】

この発明の実施形態は、各場所で、その特定の場所で履歴バスケットを使用し、その場所に特有の推薦を行なって、独立して実行可能である。

【0034】

図２および図３は、一実施形態に従った、商品またはサービスのバスケットに基づいて追加の商品およびサービスを推薦する場合の図１の推薦モジュール１６の機能のフロー図である。図２はプロセス全体のフロー図であり、図３は、図２の機能の一部である「ＭＣＭＣ」サンプリング機能のフロー図である。一実施形態では、図２および図３のフロー図の機能は、メモリまたは他のコンピュータ読取可能媒体または有形媒体に格納され、プロセッサによって実行されるソフトウェアによって実現される。他の実施形態では、機能は、ハードウェアによって（たとえば、特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）、プログラマブルゲートアレイ（programmable gate array：ＰＧＡ）、フィールドプログラマブルゲートアレイ（field programmable gate array：ＦＰＧＡ）などの使用を通して）、または、ハードウェアとソフトウェアとの任意の組合せによって実行されてもよい。

【0035】

機能を実現する前に、実施形態は、あるセットアップ入力／パラメータを必要とする。セットアップ入力は「ターゲットアイテム」を含み、それらは、この発明の実施形態がそこから推薦を生成する１組のアイテムである。典型的には、組織は、推薦を、特定の１組のアイテムから生じるものに限定するであろう。たとえば、レストランでは、推薦は、メインディッシュではなく、前菜またはサイドディッシュのみから生じてもよい。以下の開示では、めったに経時変化しない安定した１組のターゲットアイテムがあると仮定される。しかしながら、実施形態はまた、変化する１組のターゲットアイテムを用いて使用するために適応され得る。

【0036】

セットアップ入力はさらに、「競合」および「非競合」アイテムというアイデンティティを含み、それは、ターゲットアイテムの特徴に基づいてフラグとして実現される。フラグの値は「競合」または「非競合」（もしくは、真または偽など）のいずれかである。たとえば、レストランの場合、フラグは典型的には競合に設定されるであろう。なぜなら、顧客はおそらく、ターゲットセット（前菜およびサイド）から推薦アイテムを２つ以上購入しないためである。しかしながら、ホテルの場合、フラグはおそらく非競合に設定されるであろう。なぜなら、ターゲットアイテムは、顧客が追加のルームサービスおよび温泉療法の双方を購入するというように２つ以上購入する場合が考えられるほど、十分異なっているためである。

【0037】

実施形態はまた、図２および図３の機能が実現されるたびに変化し得る２つのタイプの「リアルタイム入力」を受信する。入力の各々は、ＭＣＭＣサンプリング２０６およびマッピング集計２０８という、別個のリンクされたアルゴリズム／機能によって取り扱われる。リアルタイム入力は、タイプ別バスケット履歴２０２を含む。一実施形態におけるタイプ別バスケット履歴２０２は、バスケットの全履歴（たとえば、昨年の履歴バスケットのすべて）である。バスケットのこの全履歴は、ボックス２０６、２０８、２１１、２１２、および２１３での処理において使用される。

【0038】

実施形態は次に、それが新たなタイプ別バスケットを受信するたびに、図２の機能を実行する。具体的には、一実施形態において機能２０６、２０８、２１１、２１２、および２１３を開始するものは、客がホテルでの滞在を完了することによる、履歴データにおける新たなバスケットの存在であり、このため、このバスケットはここで履歴になる。他の実施形態では、ホテルは、複数の新たな履歴バスケットを累積させるためにたとえば２週間待つかもしれず、そのため、新たな履歴バスケットが１つだけあるからといって２０６が実行されることはない。したがって、実施形態では、ホテルは、２０６および関連付けられたボックスを２週間に１度しか実行しないかもしれない。バスケットが完了されると（すなわち、顧客が訪問を完了すると）、タイプ別ラベルが各バスケットに添付される。同様に、レストランについては、各顧客訪問が完了するたびに、新たなバスケットが生成されてもよい。

【0039】

また、図２の機能は、新たな履歴バスケットを処理することに加えて、２０４で推薦を要求するホテルまたはレストランでのシステムによって開始されてもよい。これら２つの開始は、アルゴリズムの異なる部分によって取り扱われる。２０２からの開始では、履歴バスケットはおそらくバッチ単位で処理されている。２０４からの開始では、ホテル／レストランはリアルタイム応答を捜している。なぜなら、それは、ホテルでの滞在をまだ完了していない客に推薦を行なおうとしているためである。この場合、実施形態は、２０９、２２０、２２２、および２５０での機能を使用して推薦を生成する。

【0040】

別のリアルタイム入力は、部分的なまたは完全なタイプ別バスケットが推薦についての要求の一部としていつ受信されるかという、推薦についての問合せ２０４である。推薦問合せにおいてタイプ別バスケットを受信した後で、実施形態は、２５０で生成されたアイテム推薦を表わすターゲットアイテムのサブセットを用いて応答する。

【0041】

２０２で新たなタイプ別履歴バスケットが入ってきた場合、実施形態は、２０６でのＭＣＭＣサンプリングと２０８でのマッピング集計という２つの機能を実行する。入ってきた新たなタイプ別バスケットは、これら２つの機能を実行するためのトリガであるが、実行された場合、トリガである最も最近のバスケットだけでなく、２０２でこれまで入ってきたタイプ別バスケットの全履歴が使用される。

【0042】

機能がいったんトリガされると、ＭＣＭＣサンプリング２０６は、タイプ別バスケット履歴２０２を入力として使用して実行される。ＭＣＭＣサンプリング２０６のより詳細な説明を図３に示す。ＭＣＭＣサンプリング２０６は、クラスタ更新３０２および嗜好更新３０４を（この順序で）η回実現する。ここでηは、実施形態の初期設定中に今回限り設定され、繰り返し限度３０６として機能する調整バラメータである。

【0043】

クラスタ更新３０２は、タイプからクラスタへの新たなマッピングを生成する。実施形態は、どのタイプ同士を、それらが製品嗜好の点で類似しているという理由で、同じクラスタへとともに併合することができるかを判断する。ここでのマッピングは、どのタイプ同士が同じクラスタ内にあるかを示す。クラスタ更新３０２は、最も最近のタイプ別バスケットだけではなく、これまで入ってきたタイプ別バスケットの全履歴を使用する。それはまた、以前の繰り返しからの嗜好更新３０４の結果を使用する。

【0044】

【数1】

【0045】

したがって、新たなタイプ別バスケットが受信された場合、ＭＣＭＣサンプリングステップ２０６の出力は、η個のマッピングのシーケンス２１１およびη個の嗜好パラメータのシーケンス２１２である。マッピングのシーケンスについての表記は、図３に示すループ（すなわち、３０２、３０４、および３０６）において繰り返しｓで生成されたマッピングに関し、Ｍ_ｓである。このため、ｓは１～ηである。

【0046】

ＭＣＭＣサンプリング
クラスタ更新３０２および嗜好更新３０４を含むＭＣＭＣサンプリング２０６のより詳細な説明は、以下のとおりである。プロファイルをクラスタにランダムに割り当てる任意のマッピングＭ_１から開始し、各クラスタごとに嗜好パラメータをＨ_０からサンプリングする。ｓ＝１、．．．、ηについて、サンプリングプロセスを以下のように繰り返す。

【0047】

【数2】

【0048】

ベイズ更新（３２２）を使用する嗜好更新３０４：ＭＣＭＣサンプリング２０６の後で、３２１でフラグが非競合に設定される場合、３２２でのベイズ更新を使用する非競合のための嗜好更新が、以下のように実行される。各クラスタごとに嗜好パラメータのベクトルを更新する。各ｃ∈｛ｃ_１、．．．、ｃ_Ｉ｝ごとに（履歴をＸ_ｔと仮定して）μ^ｃの事後分布を計算し、その事後分布からμ^ｃについての新たな実現値を導く。

【0049】

【数3】

【0050】

ＭＣＭＣサンプリング２０６を完了後、２０８で、実施形態は以下のマッピングの集計を生成する。ＭＣＭＣサンプリング２０６からの生成されたマッピングのシーケンスでは、同じマッピングが２回以上生成されることが起こり得る。ｓ＝１．．．Ｌについて、一意的なマッピングをＭ_ｓとしてラベル付けし、ここでＬは別個のマッピングの数である（ここで下付き文字は、下付き文字がＭＣＭＣループカウントを示した前述の使用とは対照的に、単に別個のマッピングの指標であり、そのため、Ｌ≦ηである）。各Ｍ_ｓに関連付けられているのは頻度割合ｆ_ｓであり、それは、生成されたマッピングのシーケンスにおいてＭ_ｓが現われた回数のカウントを、シーケンスにおけるマッピングの総数で除算したものである（このため、それは常に０と１との間の数である）。ｆ_ｓは、マッピング集計２０８または現在の集計２１３の出力である。

【0051】

２０４で問合せが受信されると、実施形態は２５０で、ＭＣＭＣサンプリング２０６の最新の実行によって生成された（すなわち、最後の新たなタイプバスケットによってトリガされるような）マッピングのシーケンス２１１、嗜好パラメータのシーケンス２１２、およびマッピング集計２０８を使用することによって、ターゲットアイテムの推薦を生成する。全体を通し、Ｌは、マッピングの最新のシーケンスにおける別個のマッピングの数であり、ｆ_ｌは、マッピングの頻度集計についての表記である。

【0052】

問合せにおいて受信されたタイプ別バスケットをｂとする。実施形態は次に、ｂを購入した顧客のための推薦として１組のターゲットアイテムを返す。ｂのタイプをｉとして示す（すなわち、タイプ別バスケットは、バスケットおよびそのタイプの双方からなる）。

【0053】

実施形態は、競合／非競合フラグの（すなわち２２０または２２２での）設定に依存して、異なる態様で１組の推薦２５０を生成する。

【0054】

２２０での競合の場合については、実施形態は、ザウレ（Saure）、Ｄ．およびゼエビ（Zeevi）、Ａ．、「要求学習を用いた最適な動的品揃え計画」（Optimal dynamic assortment planning with demand learning）、製造サービス動作管理（Manufacturing Service Oper. Management）１５（３）、３８７～４０４（２０１３）に開示されたアルゴリズム３（「ザウレ」アルゴリズム）を適応し、当該文献の開示は、その全体がここに引用により援用される。ザウレアルゴリズムは、到着した各顧客ｔごとに、以下のように探求するかまたは活用するかを判断する。（オーダーＩｎ（ｔ）の）すべての製品が少なくとも複数回探求された場合、アルゴリズムは現在の最適な品揃えを活用する。その他の場合、それは、テスト中の製品を含む品揃えを提供する（探求）。

【0055】

ザウレアルゴリズムは、顧客の均質な母集団を仮定する。しかしながら、動的クラスタ化ポリシーのベイズセットアップでは、マッピングおよび顧客嗜好の事後分布への近似から推定が導き出される。したがって、実施形態は、動的クラスタ化ポリシーのためにザウレアルゴリズムを適応させる。

【0056】

【数4】

【0057】

上に開示されたマッピング集計についての表記に従って、推薦についての問合せが受信される時に、実施形態は、頻度割合ｆ_ｌを有する別個のマッピングＭ_ｌを有すると仮定する。実施形態は次に、各ターゲットアイテムｊごとに以下の数を計算する：

【0058】

【数5】

【0059】

表記Ｍ_ｌ（ｉ）は、マッピングＭ_ｌがタイプｉをマッピングするクラスタを意味する。実施形態はここで、最大のＱ_ｊを有する上位Ｃ個のターゲットアイテムｊを取り上げる。これが、タイプ別バスケットｂを購入した顧客に提供される１組の推薦されるアイテム２５０である。

【0060】

実施形態は、クライアント／サーバモデルを使用して実現され得る。ここで、クライアントは図１のＰＯＳデバイス１００であってもよく、図１の残りがサーバとして機能する。クライアントは、図２の２５０で生成された推薦をレストラン（たとえば、ファーストフードまたはクイックサービス方式のレストラン）のレジ係または接客係に表示することができ、レジ係または接客係は次に、それらの推薦を提案することができる。クライアントはまた、レストランのテーブルの上に置かれたリモートデバイスといった、顧客が直接利用可能なデバイスであってもよい。

【0061】

図４～５は、この発明の実施形態に従ったＵＩのスクリーンショットを示す。図４に示す例は、顧客がレジ係にオーダーを出して、オーダーが用意されるのを待つ「クイックサービス」方式のレストランをサポートするように構成されたクライアントデバイス向けのものである。この発明を実現し、独創的な機能を提供するクライアントデバイスは、専用デバイスである。

【0062】

図４は、現在のオーダーを形成する商品のバスケット４２５に応答して生成される５つの推薦４０１～４０５を示す。５つの推薦のうち、最上位の推薦４０２は赤で示され、点滅している。実施形態は、すでにオーダーにある他のアイテムに基づいて計算される最も高い購入確率を有する５つのアイテムを取り上げることにより、これらの推薦を生成する。ランキング機能は、２５０で実行される。

【0063】

図５は、顧客がお得意様番号を有する場合にレジ係がどこにどのように顧客のお得意様番号を入力できるかを示しており、この発明は次に、お得意様カードに関連付けられた任意の人口統計学的情報を使用して推薦を修正することができる。人口統計学的情報は、バスケットのタイプの定義に関連付けられ得る。レジ係は次に、顧客が最上位アイテムをオーダーに追加したいかどうか、顧客に尋ねるべきである（ただし、他の４つのアイテムも推薦する柔軟性を有する）。いくつかの実施形態は次に、推薦が顧客に与えられたかどうかを検証するよう、レジ係を促す。

【0064】

図６は、この発明の実施形態に従った高レベルのシステム図を示す。「データサイエンス」または「ＤＳ」エンジンは、推薦提案を生成する、システム１０を含む実施形態を指す。６０１で、ＤＳエンジンは、タイプのリストと、タイプのクラスタへのマッピングと、各クラスタに関連付けられた購入確率とを生成する。ポータル６０２で、ユーザはこの出力を見直し、所望通り手動変更を行なうことができる。次に、６０３で、この情報を含むファイルが店舗ごとに生成される。実施形態は、各店舗ごとに別々の推薦を定め、このため、顧客の好みの地域差を考慮に入れる。店舗ごとのこれらのファイルは次に、６０４で「シンフォニー」サーバにロードされ、このサーバは次に、６０５でこれらのファイルを販売時点情報管理システム（すなわち、レジ係が実際に使用するハードウェア）に分散させる。販売時点情報管理システムは次に、６０６で販売トランザクションを記録し、販売トランザクションは次に、シンフォニーサーバにアップロードされる。実施形態は次に、これらの最新の販売成績を使用して、その購入確率、およびそのタイプのクラスタへのマッピングも更新する。

【0065】

ホテルについてのこの発明の実施形態の例示的な使用事例
例示的な使用事例については、お得意様カードプログラムを有する最高級のホテルチェーンと、ホテルが年齢といったその顧客に関する何らかの人口統計学的情報を有することとを仮定する。ホテルが、以下の特徴に基づいた以下の１組のタイプを定義したと仮定する：
● 部屋を予約した人の年齢層：２０～３０才、３０～４０才、４０～５０才、５０～６０才、６０才以上；
● 客の一行の人数：１名、２名、３名、４名以上；
● 客の一行に子供がいるかどうか；
● 客が予約した部屋の価格階層：高、中、低。

【0066】

これらの特徴についての値の組合せまたは組の各々が、１つのタイプを形成する。例示的なタイプは、以下のとおりである：年齢 ３０～４０才；客 ２名；子供 いない；低。

【0067】

タイプの総数は、５×４×２×３＝１２０である。この発明の実施形態の目標は、補助的提供物についてのタイプの嗜好が十分に類似しているという理由で、これら１２０タイプのうちのどれをともに組合せることができるかを判断することである。例示的な特徴はここでは、この発明は、ホテルがその客についての特徴を判断する方法を有する限り、ホテルがタイプについての任意の特徴を使用するのに十分に柔軟である、ということを示す。

【0068】

この例を簡単にするために、特徴は、顧客が訪問中にすでに購入したかもしれない補助的アイテムのバスケットの特徴を含まず、実際、この例でのバスケットは、客が予約した部屋のみからなる。しかしながら、実際の実現化例では、特徴はおそらく、バスケットがすでに温泉療法を含む（つまり、客がこの滞在中にそれをすでに購入した）かどうかといった、客がこの滞在中にどんな補助的アイテムをすでに購入したかについての何らかの表示を含むであろう。

【0069】

特定の補助的提供物は、以下を含む：
１．温泉療法；
２．ジムサービス；
３．ミニバーアイテム；
４．ルームサービス。

【0070】

これらは、入力として提供される１組の「ターゲットアイテム」である。この例についての「バスケット」とは単に、この特定の訪問中に客によってすでに購入された１組の補助的アイテムである。

【0071】

最後に、２０９で非競合フラグが設定される。なぜなら、これらの補助的アイテムはすべて一緒に購入可能である（すなわち、それらは互いに代わりになるものではなく、実際、典型的な顧客は１回の訪問で２つ以上を購入するかもしれない）ためである。

【0072】

表記
例のターゲット提供物には４つのアイテムがあり（上記参照）、このため、上で言及されたベクトルμは、ターゲットセットにおける４つのアイテムの各々の購入確率を与える長さ４のベクトルである。μの各要素は、０と１との間の数である。なお、非競合フラグが設定されるため、要素の合計は、１よりも大きいものを含め、何であってもよい。各要素は、他の要素から独立した購入の確率を表わす。つまり、顧客は各々を別々に決める。代わりに競合フラグが設定された場合、これはあてはまらず、購入確率は独立しておらず、実際、合計が１未満の何かになるはずである。

【0073】

新たな履歴バスケットの取り扱い
本文で開示されたように、客が滞在を完了すると、実施形態は、２０２で履歴バスケットを絶えず受信する。これらの新たな履歴バスケットを受信すると、実施形態は、バスケットを処理するためにＭＣＭＣサンプリング２０６を実行する。

【0074】

ＭＣＭＣサンプリング２０６は、η回実行されるループである。各繰り返しは、以下の表１のような表を生成する：

【0075】

【表1】

【0076】

表の一部のみが上に示される。実際のシステムでは、表は、バスケット特徴の組合せごとに１行（このため、全部で１２０行）を含むであろう。「クラスタ」列は、タイプのクラスタへのマッピングを与え、このため、上に示されるタイプのうちの３つが同じクラスタに割り当てられ、この特定のマッピングでは、それら３つのタイプが同じ嗜好パラメータを有するとして扱われることを示す。１～４とラベル付けされた列は、購入確率として表わされる、各ターゲットアイテムについての嗜好パラメータ（上でηと呼ばれる）を与える。各クラスタごとに１組の嗜好パラメータがある。なぜなら、クラスタは定義により、すべてのその構成タイプについて同じ嗜好パラメータを有するためである。

【0077】

クラスタ１についての嗜好パラメータの合計がどのように１を上回るかに留意されたい。この場合も、これは、非競合フラグが設定されるためである。

【0078】

上述の表１は、ループの繰り返しｓで（ループをｓ回通った後で）ＭＣＭＣサンプリング２０６によって生成されたと仮定する。ここで、繰り返しｓ＋１については、繰り返しｓからの表１が使用され、以下のステップが新たな表を生成する：
１．（クラスタ更新３０２）おそらく、タイプのクラスタへの割り当てに変更を加える；
２．（嗜好更新３０４）最新の１組の履歴バスケットとクラスタ更新で行なわれた任意の新たな割り当てとを使用して、各クラスタごとに新たな嗜好パラメータを生成する。

【0079】

おそらく変更を加える
これは、現在の表の各行ごとに実行されるマルチステップ手順である。たとえば、表の行３のための手順が実行中であると仮定する。システムは、おそらく行３を具体的にはクラスタ３に切り替える（上述の表では、行３は現在、クラスタ２内にある）ために候補クラスタをすでに生成している。実施形態はここで、実際に行３をクラスタ３に切り替えるかどうかを判断するために、以下を実行する：
１．その現在のクラスタである２に割り当てられた行３について「尤度」スコアを計算し、行３に示されたタイプの各履歴バスケットを取り上げ、補助的提供物の各履歴購入について上述の表に示された購入確率の連続乗算を保つ。たとえば、履歴バスケットが温泉療法の購入を有した場合、０．１を乗算する。なぜなら、０．１は、温泉についてのクラスタ２での購入確率であるためである。履歴バスケットが温泉およびミニバーの双方を有した場合、０．１および０．３を乗算する。これを、行３に示されたタイプの全履歴バスケットについて行なう；
２．クラスタ３に切り替えられた行３について、ここではクラスタ２についてリストされた購入確率の代わりにクラスタ３についてリストされた購入確率を使用すること以外は同じ連続乗算によって、第２の「尤度」スコアを計算する；
３．２の尤度スコアを１の尤度スコアで除算する。比率が１より上である場合、行３をクラスタ３に切り替える。比率が１より下である場合、その比率と等しい確率で行３をクラスタ３に切り替える。

【0080】

尤度スコアとは、各クラスタの購入確率が実際の購入履歴にどれくらいよく適合するかという測定値である。このため、クラスタ３がクラスタ２よりも良好に購入を記載する場合、上記は、行３をクラスタ３に切り替える。このようにして、実施形態は、異なる行を同じクラスタに統合することができ、それは、この発明の基本ポイントのうちの１つである。

【0081】

上述のステップは、上述の表のすべての行ごとに実行されて、新たな表である表２を生成する。その一部をここに示す：

【0082】

【表2】

【0083】

この例では、行３のタイプはクラスタ２からクラスタ３に切り替えられ、このため、クラスタ３はここでは、行３および行５におけるタイプの双方からなり、一方、クラスタ２はここでは、行２および行４におけるタイプのみからなる。

【0084】

各クラスタごとに新たな嗜好パラメータを生成する
なお、上述の新たな表２では、嗜好パラメータは空である。次に、クラスタについての嗜好パラメータを書き込むために、嗜好更新３０４が各クラスタごとに実行される。行２および行４からなるクラスタ２が処理中であると仮定する：
１．クラスタにおける任意の行（行２または行４のいずれかであろう）のタイプに適合するすべての履歴バスケットを見つける。それらが１０００個あると仮定する；
２．１０００個のうち、補助的アイテムの各々を購入した比率を見つける。たとえば、アイテム１＝０．１、アイテム２＝０．１５、アイテム３＝０．３、およびアイテム４＝０．２３である；
３．これらの値はここで、嗜好パラメータのために使用され得る。すなわち、μ［１］＝０．１、μ［２］＝０．１５、などである。しかしながら、これは、これらの値における不確実性を勘案していないであろう、つまり、これらは単に、真の値への近似である。なぜなら、過去の顧客の挙動にはランダム性が常にあるためである。実施形態は、ザウレ、Ｄ．およびゼエビ、Ａ．、「要求学習を用いた最適な動的品揃え計画」、製造サービス動作管理１５（３）、３８７～４０４（２０１３）（「ザウレ」）の式（４ａ）、（４ｂ）、および（４ｃ）の使用を通して、不確実性を勘案する。標準アプローチであるベイズ方法論は、これらの式を使用して適用され、結果として生じるμ値は、たとえば上述のものから０．１５、０．１６、０．３２、および０．２８へ若干変更されるであろう。この方法論を適用することはまた、ホテル経営者が以前の経験を適用して、μの全体的平均値が何であるかに関する確信を意味する、方法論が「先験値」と呼ぶものを特定することを可能にする。この場合、ホテル経営者は０．２、０．２、０．４、０．４という先験値を特定したかもしれないため、ベイズアルゴリズムは、μについての値を若干増加させている。先験値は、ザウレではＨ_０によって示され、式（４ｃ）において標準ベイズアプローチへの入力として使用される。

【0085】

これは、ＭＣＭＣサンプリング２０６の現在の繰り返しを完了させ、ここでＭＣＭＣサンプリング２０６は次の繰り返しに移り、完成したばかりの表を次の繰り返しのための入力として使用する。上に開示されたように、各繰り返しは、前の繰り返しからの表を使用し、前の表のクラスタおよび嗜好パラメータの双方を使用して、その表を構築する。したがって、完了時、ＭＣＭＣサンプリング２０６は、η個のそのような表を、各繰り返しにおいて１つずつ生成している。

【0086】

マッピング集計ステップ
ＭＣＭＣサンプリングがすべてのη個の繰り返しを経た後で、マッピング集計２０８は、ＭＣＭＣサンプリング２０６によって生成された表からクラスタマッピングだけを抽出し（嗜好パラメータを無視）、以下を行なう：
● 別個のマッピングを判断する（ＭＣＭＣサンプリングの２回以上の繰り返しにおいて同じマッピングが生成されたということは起こり得る）。別個のマッピングの数は、多くてη個である；
● 各別個のマッピングごとにマッピングの数をカウントする；
● 各別個のマッピングごとに頻度割合を生成する。

【0087】

ＭＣＭＣサンプリング２０６が例においてη＝１１０で１０個の別個のマッピングを生成したと仮定する。マッピング集計は、以下の表３のような表を生成する：

【0088】

【表3】

【0089】

単一ではなく複数のマッピングを生成することは、マッピングが真に何であるかに関する不確実性を反映する。頻度割合は確率として解釈可能であり、このため、真のマッピングがマッピングＡである可能性は８．１パーセントであり、それがマッピングＢである可能性は１０％である。このように不確実性を取り扱うことは、実施形態の重要な新規の特徴である。

【0090】

推薦についての問合せ
開示されるように、実施形態は、２０４での推薦についての問合せに応答することができる。実施形態はバスケットおよびそのタイプを与えられ、次に２５０で、どの補助的アイテムを客に推薦するかという推薦を用いて応答する。

【0091】

与えられたバスケットは、上述のマッピング表の行３で与えられたタイプのものであると仮定する。タイプがどのクラスタに属したかが絶対に確かであった場合、行３が属したどんなクラスタに対してもザウレに開示された標準アルゴリズムを単に実行し、そのように推薦を得れば十分であろう。しかしながら、上に開示されたように、この発明の重要な特徴は、どのマッピングが真のマッピングであるかについての不確実性を取り扱うことである。このため、複数のマッピングを標準アルゴリズムと組合せることが必要である。

【0092】

【数6】

【0093】

しかしながら、複数のマッピングがあるため、マッピングＡおよびマッピングＢの双方が、それらの効果を組合せることによって勘案される：

【0094】

【数7】

【0095】

０．０８１はマッピングＡの頻度割合であり、０．１はマッピングＢの頻度割合である。なお、マッピングＢは行３をクラスタ３に割り当てており、このため、上付き文字はクラスタ２ではなくクラスタ３になる。省略符号は、対応する頻度割合だけ各々乗算される他のマッピングの寄与を示す。言い換えれば、最終的なＱ_ｊは加重平均であり、重みはマッピングの頻度割合である。このようにして、実施形態は、マッピングが真のマッピングであると思われる強度に従って、すべてのマッピングにわたって平均を取る。次に、推薦を得るために、最も大きいＱ_ｊに関連付けられた補助的アイテムが選択される。

【0096】

開示されるように、実施形態は、以下の２つの基準に基づいて推薦を行なう：
１．どのアイテムが最も顧客に受け入れられそうか
２．どのアイテムがまだ頻繁に顧客に推薦されていないか
１を行なうだけで十分であると仮定され得るが、この場合、データのランダム性または不十分なデータのせいで、顧客が実際にはかなり受け入れそうなアイテムがまったく推薦されないということが起こり得る。このため、実施形態は、時々「リスクを冒して」、常に１を使用する代わりに基準２を使用してアイテムを推薦する。このため、実施形態は、「活用」（基準１）と「探求」（基準２）とのバランスをとる。

【0097】

ホテルは、推薦についての問合せから受信される推薦の数を選択することができる。典型的には、ホテルは推薦を１つだけ望むかもしれず、その場合、最も高いＱスコアを有する補助的アイテムが選択される。しかしながら、実施形態は、ホテルが望めばもっと多くを選択するように構成可能である。

【0098】

ホテルが２５０での推薦を受信した後で、推薦は、さらなる機能を提供するために他の専用コンピュータシステムによって使用されてもよい。たとえば：
１．客が購入を行なって部屋番号を与えると、推薦が、ホテルが有する販売時点情報管理システムに現われてもよい。販売時点情報管理システムのユーザが次に、客に口頭で推薦を行なう。推薦には小割引が伴ってもよい；
２．推薦は電子メールで、おそらくはこの場合も小割引とともに客に送信されてもよい；
３．推薦は、再度ホテルに滞在することを選ぶ誘因として、ホテルでの客の次回の滞在について客に約束されてもよい。

【0099】

開示されるように、実施形態は、顧客がこれまで購入したものに基づいて追加の製品およびサービスについての推薦を行ない、アイテムおよびサービスのメニューが頻繁に変化するレストランおよびホテルに特に適している。ＡＲＭ以外の公知のシステムは、推薦を行なうためにアイテムのバスケット全体または人口統計学的属性をすでに使用しているかもしれないが、バスケットの異なるタイプの数がかなり多くなり得るため、そのようなシステムは新たな推薦を行なう前に大量の履歴バスケット情報を必要とするかもしれず、それは、システムがその推薦を提供物または顧客嗜好の変化に適応させ得る速度を遅くする。人口統計学的属性が追加される場合、問題はさらに悪化する。

【0100】

公知のシステムとは対照的に、実施形態は、変化する提供物または変化する顧客嗜好に適応する前に、入ってくるはずの新たなデータの量の減少に依拠する。したがって、実施形態は、（１）顧客のバスケットにおける個々のアイテム；（２）バスケット全体の全体的特徴；または（３）顧客の人口統計学的属性という、顧客の購入の特徴のうちの多くて３つのみに基づいて推薦を生成することを実用的にする。実施形態はその推薦を、公知のシステムよりも速く、新たなデータに適応させることができ、それは、提供物および顧客嗜好が連続的に変化する業界において重要である。

【0101】

また、レストランは典型的にはお得意様プログラムを有していないため、レストランのための推薦システムは、顧客にリンクされたトランザクションを要求できない。公知のＡＲＭベースの推薦システムは、顧客にリンクされたトランザクションを必要とはしないものの、典型的にはアイテムのペアのみを考慮する上で限界があり、バスケット特性または人口統計学的属性を考慮しない。対照的に、実施形態は、顧客にリンクされたトランザクションを必要とせず、また、バスケット特性および人口統計学的属性の双方を考慮することができる。人口統計学的特性を含める能力は、常連客のカスタマイズされたもてなしに関心があるホテルおよびレストラン業界では重要である。

【0102】

いくつかの実施形態が、ここに具体的に例示され、および／または記載されている。しかしながら、開示された実施形態の変更および変形は、この発明の精神および意図された範囲から逸脱することなく、上述の教示によって網羅され、添付された請求項の範囲内にある、ということが理解されるであろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】