JP7468300B2

JP7468300B2 - 情報処理装置、情報処理方法、およびプログラム

Info

Publication number: JP7468300B2
Application number: JP2020183528A
Authority: JP
Inventors: 章佐々木; 修泉田; 聡史駒嶺; 晃史伊藤; 文菜竹下; 大輔村上
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2020-11-02
Filing date: 2020-11-02
Publication date: 2024-04-16
Anticipated expiration: 2040-11-02
Also published as: CN114445169A; JP2022073502A; US20220138823A1

Description

本発明は、ユーザを補助する技術に関する。

日用品をはじめとした、定期的に消費される物品の購入をサポートするための技術がある。例えば、特許文献１には、ネットワークを介して、定期的な商品の購入（定期購入）を依頼するためのシステムが開示されている。

特開２００３－１５０８６８号公報

日常的に利用する商品について、定期購入をしたほうがよいか、そうでないかを一般消費者が適切に判断することは容易ではなく、定期購入の普及に対する妨げとなっている。

本発明は、商品の購入に係るユーザの手間を削減することを目的とする。

本開示の第一の態様は、過去における、ユーザによる商品の購入履歴を取得することと、前記購入履歴に基づいて、前記ユーザが定期的に購入している対象商品が存在することを判定することと、前記判定の結果に基づいて、定期購入サービスを利用して前記対象商品を購入することを前記ユーザに提案することと、を実行する制御部を有する、情報処理装置である。

また、本開示の第二の態様は、過去における、ユーザによる商品の購入履歴を取得するステップと、前記購入履歴に基づいて、前記ユーザが定期的に購入している対象商品が存在することを判定するステップと、前記判定の結果に基づいて、定期購入サービスを利用して前記対象商品を購入することを前記ユーザに提案するステップと、を含む、情報処理方法である。

また、他の態様として、上記の情報処理方法を実行するためのプログラム、または、上記のプログラムを非一時的に記憶したコンピュータ可読記憶媒体が挙げられる。

本発明によれば、商品の購入に係るユーザの手間を削減することができる。

情報処理システムの概要を説明する図。第一の実施形態に係る情報処理システムの構成要素を詳細に示した図。記憶部に記憶されるユーザデータを説明する図。装置間におけるデータの流れを示す図。ＥＣサーバから提供される購入履歴データの例。第一の実施形態において制御部が実行する処理のフローチャート。第二の実施形態における購入履歴データの例。第二の実施形態において制御部が実行する処理のフローチャート。

ユーザによる申し込みに基づいて、例えば、日用品やアルコール飲料などの予め定められた商品を定期的に配送するサービス（定期購入サービス）が知られている。しかし、このようなサービスにおいては、配送間隔と発注量を適切に設定しなければならず、利用が敬遠される原因となっていた。また、定期購入を行うべきであるか否かを消費者が判断することは容易ではない。
実施の一態様に係る情報処理装置は、この問題に対応するため、ユーザによる商品の購入履歴に基づいて、当該ユーザに対して、定期購入サービスの利用を提案する。

なお、本明細書における定期購入サービスとは、ユーザが希望する所定の間隔で対象の商品を定期的に配送するサービスを指し、「定期購入を行う」とは、当該サービスを通して商品の購入を行うことを指す。この形態は、サブスクリプションとも呼ばれる。定期購入サービスには、商品の発送ごとに当該商品の対価を支払う形態と、ある期間に対応する料金を支払い、規定数の商品の提供を受ける形態などがある。

情報処理装置は、過去における、ユーザによる商品の購入履歴を取得することと、前記購入履歴に基づいて、前記ユーザが定期的に購入している対象商品が存在することを判定することと、前記判定の結果に基づいて、定期購入サービスを利用して前記対象商品を購入することを前記ユーザに提案することと、を実行する制御部を有する。

対象商品は、ユーザによって定期的に購入される商品である。対象商品は、例えば、トイレットペーパーなどの日用品であってもよいし、アルコール飲料などの嗜好品、または食品であってもよい。制御部は、ユーザによる商品の購入履歴を参照することで、ユーザによって定期的に購入されている対象商品が存在することを判定する。なお、商品の購入履歴は、ユーザが利用するコンピュータから取得してもよいし、ＥＣ（electronic commerce）サーバから取得してもよい。

ユーザが定期的に購入している商品がある場合、定期購入サービスを利用したほうが有利な場合がある。このため、情報処理装置は、ユーザに対応する購入履歴に基づいて、対象の商品について定期購入サービスを利用したほうがよいか否かを判定し、ユーザに対して、定期購入サービスの利用提案を自律的に行う。これにより、ユーザの利便性を向上させることができる。

また、前記制御部は、過去の所定の期間において、前記ユーザが前記対象商品を所定の回数以上購入している場合に、前記提案を行うことを特徴としてもよい。
所定の回数は、定期的な購入であると評価できる値であることが好ましい。

また、前記制御部は、前記提案に対する前記ユーザの応答を取得し、前記応答に基づいて、前記定期購入サービスを提供するサーバ装置に対して、前記定期購入サービスの利用を申し込むためのデータを送信することを特徴としてもよい。
例えば、ユーザが提案に同意した場合に、定期購入サービスの申し込みを行うようにしてもよい。

また、前記制御部は、前記定期購入サービスを提供するサーバ装置に対して、前記対象商品の取り扱い有無を問い合わせ、前記定期購入サービスにおいて前記対象商品の取り扱いがある場合に、前記提案を行うことを特徴としてもよい。
かかる構成によると、対象商品について定期購入サービスが利用できる場合に限って、提案を行うことができる。

また、前記制御部は、前記購入履歴に基づいて、過去の所定の期間における前記対象商品の購入間隔を判定し、前記購入間隔に基づいて、前記定期購入サービスにおける配送間隔を提案することを特徴としてもよい。
商品を定期購入する際の配送間隔は、ユーザ自身が当該商品を購入した間隔と一致させることが好ましいためである。

また、前記制御部は、前記購入間隔のばらつきが所定値を下回っている場合に、前記提案を行うことを特徴としてもよい。
対象の商品が複数回購入されていても、その購入間隔がばらついている場合、ユーザが当該商品を定期的に購入していないと評価できるためである。ばらつきは、例えば、分散や標準偏差によって求めてもよい。

また、前記対象商品は、内容量のみが異なる複数バリエーションの商品を含むことを特徴としてもよい。
例えば、内容物が同一であって、内容量のみが異なる複数のパッケージが存在する場合がある。これら複数のパッケージを別個の商品としてしまうと、ユーザが定期的に同じ商品を購入していることが正しく判定できなくなるためである。

また、前記制御部は、過去の所定の期間における前記対象商品の購入間隔、および、前記対象商品のパッケージに含まれる内容量を表す情報を取得し、前記対象商品の消費ペースを推定することを特徴としてもよい。
また、前記制御部は、前記推定した消費ペースに基づいて、前記定期購入サービスにおける配送間隔、および、発注量を提案することを特徴としてもよい。

内容量が異なる複数のパッケージが存在する場合、ユーザによる対象商品の消費ペースを推定してもよい。これにより、どのパッケージを定期購入の対象とするか（換言すると、一回にどの程度の量を発注するか）と、その配送間隔を正確に決定することが可能になる。

また、前記制御部は、前記推定した消費ペースに基づいて、前記ユーザの元にある前記対象商品の在庫量を推定し、前記在庫量が所定値を下回ったタイミングにおいて、前記提案を行うことを特徴としてもよい。
かかる構成によると、ユーザの元にある対象商品の在庫量が減少したタイミングで、定期購入サービスの提案を行えるようになる。

以下、図面に基づいて、本開示の実施の形態を説明する。以下の実施形態の構成は例示であり、本開示は実施形態の構成に限定されない。

（第一の実施形態）
第一の実施形態に係る情報処理システムの概要について、図１を参照しながら説明する。本実施形態に係る情報処理システムは、ユーザが商品の発注に利用する装置であるユーザ端末２００と、商品の発注を受け付けるＥＣサーバ３００と、ユーザが行った発注の履歴に基づいて、定期購入サービスの利用を提案するサーバ装置１００と、を含んで構成される。

ＥＣサーバ３００は、ネットワーク（例えば、インターネット）を介して、商品の注文を受け付ける装置である。ＥＣサーバ３００は、ウェブサーバを内蔵しており、ユーザは、ウェブブラウザを介してＥＣサイトにログインして商品の注文を行うことができる。ＥＣサーバ３００は、通信販売事業を運営する事業者によって管理される。

ユーザ端末２００は、ユーザが所有するコンピュータである。ユーザは、ユーザ端末２００を介してＥＣサーバ３００にアクセスし、商品の注文（購入申し込み）を行うことができる。

サーバ装置１００は、ユーザに関連付いた購入履歴（ユーザがＥＣサイトを介して商品を注文した履歴）に基づいて、特定の商品について定期購入を行うことについての是非を判定する。また、定期購入が可能であると判定した場合に、その旨をユーザに提案する。ユーザは、提案に沿って、該当する商品の定期購入をＥＣサーバ３００に申し込むことができる。

なお、サーバ装置１００はユーザの自宅内に設置されていてもよいが、遠隔地に設置されていてもよい。また、一台のサーバ装置１００が、複数のユーザを管轄してもよい。
また、本例では単一のＥＣサーバ３００を例示しているが、ＥＣサーバ３００は複数あってもよく、それぞれが、異なる複数のＥＣサイトを提供していてもよい。

図２は、本実施形態に係る情報処理システムの構成要素をより詳細に示した図である。ここではまず、ユーザ端末２００について説明する。
ユーザ端末２００は、例えば、パーソナルコンピュータ、スマートフォン、携帯電話、タブレットコンピュータ、個人情報端末といった、個人が利用するコンピュータである。ユーザ端末２００は、制御部２０１、記憶部２０２、通信部２０３、および入出力部２０４を含んで構成される。

制御部２０１は、ユーザ端末２００が行う制御を司る演算装置である。制御部２０１は、ＣＰＵ（Central Processing Unit）などの演算処理装置によって実現することができ
る。
制御部２０１は、ＥＣサーバ３００にアクセスしてインタラクションを行う機能を実行する。当該機能は、ユーザ端末２００で動作するウェブブラウザによって実現されてもよい。

記憶部２０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部２０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部２０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。補助記憶装置には、制御部２０１で実行されるプログラムをアプリケーションとしてパッケージ化したものを記憶してもよい。また、これらのアプリケーションを実行するためのオペレーティングシステムを記憶してもよい。補助記憶装置に記憶されたプログラムが主記憶装置にロードされ、制御部２０１によって実行されることで、以降に説明する処理が行われる。

主記憶装置は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）を含んでもよい。また、補助記憶装置は、ＥＰＲＯＭ（Erasable Programmable ROM）やハード
ディスクドライブ（ＨＤＤ、Hard Disk Drive）を含んでもよい。さらに、補助記憶装置
は、リムーバブルメディア、すなわち可搬記録媒体を含んでもよい。

通信部２０３は、ユーザ端末２００をネットワークに接続するための無線通信インタフェースである。通信部２０３は、例えば、無線ＬＡＮや３Ｇ、ＬＴＥ、５Ｇ等の移動体通信サービスを介して、サーバ装置１００およびＥＣサーバ３００と通信可能に構成される。
入出力部２０４は、ユーザが行った入力操作を受け付け、ユーザに対して情報を提示するユニットである。本実施形態では一つのタッチパネルディスプレイからなる。すなわち、液晶ディスプレイとその制御手段、タッチパネルとその制御手段から構成される。

次に、サーバ装置１００について説明する。
サーバ装置１００は、事前に設定された情報を用いてＥＣサーバ３００にログインすることで、対象のユーザに対応する商品の購入履歴を取得する。さらに、購入履歴に含まれる商品について、定期購入が可能か否かを判定し、当該判定の結果に基づいて、ユーザに対する提案を生成する。

サーバ装置１００は、汎用のコンピュータにより構成することができる。すなわち、サーバ装置１００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。なお、リムーバブルメディアは、例えば、ＵＳＢメモリ、あるいは、ＣＤやＤＶＤのようなディスク記録媒体であってもよい。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを主記憶装置の作業領域にロードして実行し、プログラムの実行を通じて各構成部等が制御されることによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。

制御部１０１は、サーバ装置１００が行う制御を司る演算装置である。制御部１０１は、ＣＰＵなどの演算処理装置によって実現することができる。
制御部１０１は、履歴取得部１０１１と、提案部１０１２の２つの機能モジュールを有して構成される。各機能モジュールは、記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

履歴取得部１０１１は、ＥＣサーバ３００にアクセスし、対象のユーザについての、過去の所定の期間における商品の購入履歴（以下、単に購入履歴と称する）を取得する。なお、ＥＣサーバ３００にアクセスするための情報（例えば、ＥＣサイトにログインするための認証情報）は、後述する記憶部１０２に記憶させることができる。履歴取得部１０１１は、ＥＣサーバ３００が提供するＥＣサイトにログインすることで、過去の所定の期間における購入履歴を取得し、取得した購入履歴を、提案部１０１２に引き渡す。

提案部１０１２は、ＥＣサーバ３００から取得した購入履歴に基づいて、定期購入サービスの利用をユーザに提案するか否かを決定する。具体的には、（１）過去の所定の期間において、ある商品が所定の回数（例えば、３回）以上注文されており、（２）注文の間隔が定期的であると評価される場合であって、（３）定期購入サービスにおいて対象の商品が利用可能ある場合に、当該商品の購入を定期購入に切り替える旨の提案を生成する。生成された提案はユーザ端末２００に送信され、ユーザの操作によって定期購入サービスの申し込みが行われる。

記憶部１０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部１０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部１０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。

また、記憶部１０２は、ユーザに対応するユーザデータを記憶する。図３は、記憶部１０２に記憶されるユーザデータの例である。ユーザデータは、ユーザの識別子、当該ユーザが利用するＥＣサイトに関する情報（識別子およびＵＲＬ等）、当該ＥＣサイトにログインするための認証情報等を含む。サーバ装置１００が複数のユーザを管理する場合、記憶部１０２は、複数人ぶんのユーザデータを記憶してもよい。

通信部１０３は、サーバ装置１００をネットワークに接続するための通信インタフェースである。通信部１０３は、例えば、ネットワークインタフェースボードや、無線通信のための無線通信インタフェースを含んで構成される。

なお、図２に示した構成は一例であり、図示した機能の全部または一部は、専用に設計された回路を用いて実行されてもよい。また、図示した以外の、主記憶装置および補助記憶装置の組み合わせによってプログラムの記憶ないし実行を行ってもよい。

次に、サーバ装置１００が行う処理について、装置間で送受信されるデータを示した図である図４を参照しながら説明する。図示した処理は、ユーザ単位で実行される。

まず、履歴取得部１０１１が、所定の周期で、ＥＣサーバ３００が提供するＥＣサイトにログインし、ユーザに対応する購入履歴データを要求する（ステップＳ１１）。図５は、購入履歴データの例である。購入履歴データは、例えば、ユーザの識別子、ＥＣサイトの識別子、商品の注文日、商品の識別子（例えば、ＪＡＮコードまたはＥＡＮコード）、および、注文された商品の個数等を含む。ＥＣサーバ３００は、要求に応答して、ユーザに対応する購入履歴データをサーバ装置１００に送信する（ステップＳ１２）。

ステップＳ１３では、提案部１０１２が、取得した購入履歴データに基づいて、定期購入サービスの利用を提案するか否かを決定する。本ステップでは、以下の条件を満たす場合に、該当する商品の定期購入を提案する。
（１）過去の所定の期間において、特定の商品（以下、対象商品）が所定の回数以上注文されている
（２）対象商品の注文間隔にばらつきが無い
（３）定期購入サービスにおいて対象商品の取り扱いがある
具体的な方法については後述する。

サーバ装置１００が、定期購入サービスの利用を提案すると決定した場合、ステップＳ１４で、提案データがユーザ端末２００に送信される。提案データは、対象商品について定期購入が可能な旨の案内、推奨される配送間隔、および、推奨される発注量などを含むデータである。提案データは、ユーザ端末２００を介してユーザに提示される。ユーザが提案を受諾すると、定期購入の申し込みを行うためのデータが、ユーザ端末２００からＥＣサーバ３００へ送信される（ステップＳ１５）。

図６は、サーバ装置１００が、定期購入の提案の是非を決定するステップ（ステップＳ１３）を詳細に説明するフローチャートである。

まず、ステップＳ１３１で、購入履歴データから、所定の期間における、商品の購入履歴を抽出する。所定の期間は、例えば、１ヶ月，３ヶ月，６ヶ月等とすることができる。
次に、ステップＳ１３２で、特定の商品について、所定回数以上の購入がされているか否かを判定する。所定回数は、定期的な購入であるか否かが判定できる回数（例えば、３回以上）であることが好ましい。ここで、肯定判定がなされた場合、処理はステップＳ１３３へ遷移する。

ステップＳ１３３では、対象商品についての購入間隔を判定する。例えば、ある商品が合計４回購入され、その発注間隔が、２４日、３０日、２７日であった場合、平均して２７日に１回の割合で当該商品が購入されていることがわかる。

ステップＳ１３４では、判定された購入間隔のばらつきが所定値以下であるか否かを判定する。例えば、ある商品の購入間隔が、４５日、３０日、１０日といったようにばらつ
いている場合、定期的な購入ではなく、単発的な購入であるものと推定される。このような場合、定期購入の提案は行わない。ばらつきは、例えば、購入間隔（日数）の分散や標準偏差によって求めることができる。

次に、ステップＳ１３５で、ＥＣサーバ３００が提供する定期購入サービスにおいて、対象商品の取り扱いがあるか（定期購入が可能であるか）否かを判定する。本ステップでは、購入履歴に含まれる商品の識別子を用いてＥＣサーバ３００へ問い合わせを行い、回答を取得する。定期購入が可能である場合、処理はステップＳ１３６へ遷移する。定期購入が不可能である場合、処理は終了する。
なお、本ステップにおいて、定期購入の是非をユーザが判断するために必要な情報（例えば、商品の詳細、商品の単価、申し込みから配送までの所要日数など）を、ＥＣサーバ３００から取得してもよい。

ステップＳ１３６では、定期購入サービスにおける配送間隔を決定する。定期購入サービスにおける配送間隔は、ステップＳ１３３で判定された購入間隔に基づいて決定することができる。例えば、対象商品について過去に複数回の購入がある場合、その購入間隔の平均値を用いてもよい。

ステップＳ１３７では、商品の定期購入を提案するためのデータ（提案データ）を生成する。提案データには、当該商品の定期購入を勧める旨、推奨される配送間隔、推奨される発注量、支払金額、および商品の単価などが含まれてもよい。
ステップＳ１４以降の処理については、前述した通りである。

以上説明したように、第一の実施形態に係るシステムでは、過去においてユーザがＥＣサイトを利用して商品を購入した履歴に基づいて、当該商品を定期購入するための提案を行う。かかる構成によると、ユーザが定期的に消費する商品の購入を、定期購入に切り替えさせることができ、商品の購入に係るユーザの手間を削減することが可能になる。

なお、第一の実施形態では、定期購入サービスにおいて対象商品の取り扱いがある場合に提案の生成を行ったが、さらなる条件を加えてもよい。例えば、単発で購入するよりも商品の単価が安くなる場合に限って提案を行うようにしてもよい。

（第二の実施形態）
第一の実施形態では、購入履歴に含まれる商品と同一の識別子を持つ商品を定期購入の対象とした。しかし、同じ商品であっても、内容量が異なる複数のパッケージが存在する場合がある。

例えば、ユーザが過去において、内容量が異なるパッケージを複数回購入していた場合、これらが同一の商品とみなされず、定期購入の提案が正しく行われないケースが発生しうる。また、日頃ユーザが購入しているものよりも大容量で、商品単価が低いパッケージがある場合であっても、これをユーザに勧めることができない。

第二の実施形態は、これに対応するため、内容物が同じである商品をグループ化し、グループを用いて処理を行う実施形態である。さらに、第二の実施形態では、ユーザによる商品の消費ペースを推定し、消費ペースに一致するような定期購入の方法を提案する。
これにより、対象商品に、内容量が異なる複数のパッケージが存在するような場合であっても、正しく提案が行えるようになる。

図７は、第二の実施形態における購入履歴データの例である。図示したように、本実施形態では、購入履歴データにグループＩＤが追加される。グループＩＤは、商品グループ
の識別子であり、内容量や入数等が異なる同一の商品には、同一のグループＩＤが付与される。これにより、内容物が同一（実質同一）であって、内容量のみが異なる他のパッケージを特定することが可能になる。
さらに、第二の実施形態では、購入履歴データに、商品の最小単位、および、内容量に関する情報が追加される。これにより、ユーザが、どの程度の量の商品を購入したかを判定することが可能になる。

図８は、第二の実施形態においてサーバ装置１００が実行する処理のフローチャートである。なお、第一の実施形態と同様のステップについては、点線で図示し、説明は省略する。

第二の実施形態では、ステップＳ１３２Ａにおいて、商品ＩＤではなく、グループＩＤを用いて、過去における商品の購入回数を判定する。すなわち、同一のグループに属する商品の購入回数を判定する。
また、ステップＳ１３５Ａにおいて、ＥＣサーバ３００に対して、同一のグループに属する商品の取り扱いを問い合わせる。なお、ＥＣサーバ３００において、同一のグループに属する複数の商品の取り扱いがある場合、それぞれの商品についての情報（内容量や入数など）を一時的に記憶する。

ステップＳ１３６１では、対象商品について、消費ペースを判定する。例えば、対象商品が、特定ブランドのトイレットペーパーであって、４ロール入りの商品が１ヶ月間隔で購入されていた場合、「一週間で１ロールが消費される」と判定することができる。本ステップでは、設定された最小単位ぶんの商品が、何日で消費されるかを判定する。

ステップＳ１３６２では、判定した消費ペースに基づいて、最適な購入量および配送間隔を決定する。具体的には、（ステップＳ１３５Ａで取得した）定期購入が可能な商品ごとに、判定された消費ペースを当てはめ、どの商品（どのパッケージ）を、どれほどの間隔で配送するかを決定する。例えば、一週間で１ロールのトイレットペーパーを消費する場合、「１ヶ月ごとに４ロール入りの商品を配送」、「３ヶ月ごとに１２ロール入りの商品を配送」といった、複数の発注パターンを決定することができる。

なお、本ステップにおいては、商品の賞味期限や有効期限を考慮してもよい。例えば、対象商品が食品や医薬品など、期限が付されたものである場合、大容量パッケージを購入しても、期限内に消費し切れない場合がある。これに対応するため、消費ペースに基づいて、賞味期限や有効期間内に商品を消費し切れるか否かを判定し、推奨できない発注パターンを除外するようにしてもよい。

なお、発注パターンが複数ある場合、所定のルールによって、採用するパターンを決定してもよい。例えば、商品の単価が最も安くなるパターンを採用してもよい。また、どのパターンを採用するかの選択肢を提案データに含ませ、ユーザに問い合わせるようにしてもよい。

第二の実施形態によると、商品の消費ペースを推定したうえで、購入量や配送間隔を適切に提案することができる。

（第二の実施形態の変形例）
前述した実施形態では、図４に示した処理を所定の周期で行い、提案データを生成した。一方、ユーザの元に十分な量の商品がある状態で提案を行っても、これが受け入れられる可能性は低い。これに対応するため、ユーザの元にある商品の在庫量を推定し、在庫量が少なくなったタイミングで提案を行うようにしてもよい。

第二の実施形態では、ユーザによる商品の消費ペース、および、商品を最後に購入した日付を得ることができる。よって、当該日付から消費ペースを計算することで、ユーザの元にある商品の在庫量が所定値以下となるタイミングを特定することができる。当該タイミングが到来するまで、ステップＳ１４の実行を保留することで、適切なタイミングでユーザに対する提案を行うことが可能になる。

なお、ステップＳ１４の実行を保留するのではなく、定期購入における初回の配送日を、在庫量に基づいて決定してもよい。例えば、「現在の消費ペースによると、月末に在庫量が所定値を下回るため、初回の商品が月末に到着するように定期購入を申し込む」といった提案を行うようにしてもよい。

（変形例）
上記の実施形態はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、実施形態の説明では、単一のＥＣサーバ３００を例示したが、システムに、異なる事業者によってそれぞれ運営される複数のＥＣサーバ３００が含まれてもよい。この場合、サーバ装置１００が有する履歴取得部１０１１が、複数のＥＣサーバ３００にログインし、例示した処理をそれぞれ実行するようにしてもよい。さらに、購入履歴データを提供するＥＣサーバと、定期購入サービスを提供するＥＣサーバは別のサーバであってもよい。また、購入履歴データを提供する第一のＥＣサーバと、定期購入サービスを提供する第二のＥＣサーバが、それぞれ別の事業者によって運営されていてもよい。

また、実施形態の説明では、履歴取得部１０１１が、ＥＣサーバから購入履歴データを取得したが、購入履歴データは、実店舗における商品の購入履歴を示すデータであってもよい。この場合、サーバ装置１００は、購入履歴データとして、ユーザが行ったキャッシュレス決済に関するデータを取得してもよい。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１００・・・サーバ装置
１０１，２０１・・・制御部
１０２，２０２・・・記憶部
１０３，２０３・・・通信部
２００・・・ユーザ端末
３００・・・ＥＣサーバ

Claims

過去における、ユーザによる商品の購入履歴を取得することと、
前記購入履歴に基づいて、前記ユーザが定期的に購入している対象商品が存在することを判定することと、
前記判定の結果に基づいて、定期購入サービスを利用して前記対象商品を購入することを前記ユーザに提案することと、
を実行する制御部を有し、
前記対象商品は、内容量のみが異なる複数バリエーションの商品を含み、前記複数バリエーションの商品は、異なる複数の商品の識別子を有し、かつ、１つの同じ商品グループの識別子を有しており、
前記購入履歴は、前記商品の識別子、前記商品グループの識別子、および、前記複数バリエーションの商品のパッケージに含まれる内容量を表す情報を含み、
前記制御部は、
前記商品グループの識別子を用いて、前記購入履歴に基づいて、過去の所定の期間における前記複数バリエーションの商品の購入間隔を判定し、
前記商品グループの識別子、および、前記商品の識別子を用いて、前記購入履歴から、前記複数バリエーションの商品の前記内容量を表す情報を取得し、
前記購入間隔、および、前記内容量を表す情報に基づいて、前記複数バリエーションの商品の消費ペースを推定し、
前記推定した消費ペース、および、前記内容量を表す情報に基づいて、前記複数バリエーションの商品の発注パターンであって、前記定期購入サービスにおける配送間隔、および、発注量が異なる複数の発注パターンを提案する、情報処理装置。
前記制御部は、過去の所定の期間において、前記ユーザが前記対象商品を所定の回数以上購入している場合に、前記提案を行う、
請求項１に記載の情報処理装置。
前記制御部は、前記提案に対する前記ユーザの応答を取得し、
前記応答に基づいて、前記定期購入サービスを提供するサーバ装置に対して、前記定期購入サービスの利用を申し込むためのデータを送信する、
請求項１または２に記載の情報処理装置。
前記制御部は、前記定期購入サービスを提供するサーバ装置に対して、前記対象商品の取り扱い有無を問い合わせ、前記定期購入サービスにおいて前記対象商品の取り扱いがある場合に、前記提案を行う、
請求項１または２に記載の情報処理装置。
前記制御部は、前記購入履歴に基づいて、過去の所定の期間における前記複数バリエーションの商品以外の前記対象商品の購入間隔を判定し、
前記購入間隔に基づいて、前記定期購入サービスにおける配送間隔を提案する、
請求項１から４のいずれか１項に記載の情報処理装置。
前記制御部は、前記購入間隔のばらつきが所定値を下回っている場合に、前記提案を行う、
請求項１または５に記載の情報処理装置。
前記制御部は、前記推定した消費ペースに基づいて、前記ユーザの元にある前記対象商品の在庫量を推定し、
前記在庫量が所定値を下回ったタイミングにおいて、前記提案を行う、
請求項１に記載の情報処理装置。
過去における、ユーザによる商品の購入履歴を取得するステップと、
前記購入履歴に基づいて、前記ユーザが定期的に購入している対象商品が存在することを判定するステップと、
前記判定の結果に基づいて、定期購入サービスを利用して前記対象商品を購入することを前記ユーザに提案するステップと、
を含み、
前記対象商品は、内容量のみが異なる複数バリエーションの商品を含み、前記複数バリエーションの商品は、異なる複数の商品の識別子を有し、かつ、１つの同じ商品グループの識別子を有しており、
前記購入履歴は、前記商品の識別子、前記商品グループの識別子、および、前記複数バリエーションの商品のパッケージに含まれる内容量を表す情報を含み、
前記商品グループの識別子を用いて、前記購入履歴に基づいて、過去の所定の期間における前記複数バリエーションの商品の購入間隔を判定するステップと、
前記商品グループの識別子、および、前記商品の識別子を用いて、前記購入履歴から、前記複数バリエーションの商品の前記内容量を表す情報を取得するステップと、
前記購入間隔、および、前記内容量を表す情報に基づいて、前記複数バリエーションの商品の消費ペースを推定するステップと、
前記推定した消費ペース、および、前記内容量を表す情報に基づいて、前記複数バリエーションの商品の発注パターンであって、前記定期購入サービスにおける配送間隔、および、発注量が異なる複数の発注パターンを提案するステップと、
を含む、情報処理方法。
過去の所定の期間において、前記ユーザが前記対象商品を所定の回数以上購入している場合に、前記提案を行う、
請求項８に記載の情報処理方法。
前記提案に対する前記ユーザの応答を取得し、
前記応答に基づいて、前記定期購入サービスを提供するサーバ装置に対して、前記定期購入サービスの利用を申し込むためのデータを送信する、
請求項８または９に記載の情報処理方法。
前記定期購入サービスを提供するサーバ装置に対して、前記対象商品の取り扱い有無を問い合わせ、前記定期購入サービスにおいて前記対象商品の取り扱いがある場合に、前記提案を行う、
請求項８または９に記載の情報処理方法。
前記購入履歴に基づいて、過去の所定の期間における前記複数バリエーションの商品以外の前記対象商品の購入間隔を判定し、
前記購入間隔に基づいて、前記定期購入サービスにおける配送間隔を提案する、
請求項８から１１のいずれか１項に記載の情報処理方法。
前記購入間隔のばらつきが所定値を下回っている場合に、前記提案を行う、
請求項８または１２に記載の情報処理方法。
請求項８から１３のいずれか１項に記載の情報処理方法をコンピュータに実行させるためのプログラム。