JP6586217B1 - 情報処理方法、情報処理装置及び情報処理プログラム - Google Patents

Abstract

【課題】電子決済サービスを用いて商品を購入した購入者を特定する情報と、この購入者が購入した個々の商品の商品情報とを対応付ける。【解決手段】コンピュータによる情報処理方法であって、前記コンピュータが、電子決済サービスを用いて商品を購入した購入者の前記商品の購入時の決済情報と、前記商品を特定する情報と対応付けられた商品管理情報とを取得し、前記決済情報と前記商品管理情報とのそれぞれに含まれる、前記商品の購入に関する共通の情報に基づき、前記決済情報に含まれる購入者を特定する情報と、前記商品管理情報に含まれる商品情報と、を対応付ける。【選択図】図１

Description

本発明は、情報処理方法、情報処理装置及び情報処理プログラムに関する。

近年では、電子決済サービスの普及に伴い、店頭等においても電子決済により商品代金の支払いが行われるケースが増えつつある。

特開２０１１−１９１８５７号公報

従来では、電子決済サービスのユーザを特定する情報と、電子決済サービスによって購入された個々の商品の情報とは、電子決済サービスの提供者と、商品を販売する店舗と、のそれぞれで別々に管理されている。

このため、従来では、電子決済サービスを用いた商品の購入者を特定する情報と、購入者が購入した個々の商品情報とを対応付けることができない。

本発明は、上記事情に鑑みてこれを解決すべく成されたものであり、電子決済サービスを用いて商品を購入した購入者を特定する情報と、この購入者が購入した個々の商品の商品情報とを対応付けることを目的とする。

開示の技術は、コンピュータによる情報処理方法であって、前記コンピュータが、電子決済サービスを用いて商品を購入した購入者の前記商品の購入時の決済情報と、前記商品を特定する情報と対応付けられた商品情報を含む商品管理情報とを取得し、前記決済情報と前記商品管理情報とのそれぞれに含まれる、前記商品の購入日時を示す情報と、前記商品の購入金額を示す情報と、前記商品が購入された位置を特定する情報と、に基づき、前記決済情報に含まれる購入者を特定する情報と、前記商品管理情報に含まれる商品情報と、を対応付ける。

電子決済サービスを用いた商品を購入した購入者を特定する情報と、この購入者が購入した個々の商品の商品情報とを関連付けることができる。

本実施形態の概要を説明する図である。 情報処理システムのシステム構成の一例を示す図である。 サーバのハードウェア構成の一例を示す図である。 対応付けデータベースの一例を示す図である。 商品管理データベースの一例を示す図である。 サーバの機能を説明する図である。 別客ＩＤについて説明する図である。 情報処理システムの動作を説明するシーケンス図である。 第１突合対象情報を説明する第一の図である。 第１突合対象情報を説明する第二の図である。 第２突合対象情報について説明する図である。 突合処理部による処理を説明するフローチャートである。 別客ＩＤ判定部の処理を説明するフローチャートである。 別客ＩＤ判定部の処理を説明する第一の図である。 別客ＩＤ判定部の処理を説明する第二の図である。

以下に図面を参照して、本実施形態について説明する。図１は、本実施形態の概要を説明する図である。

本実施形態のサーバ１００は、電子決済サービスのユーザが店舗を訪れて、電子決済サービスを用いて商品を購入した場合に、店舗で管理されている商品管理情報と、商品購入時の決済情報とを取得し、ユーザを特定する情報と、商品購入情報に含まれる商品情報と、決済情報に含まれるユーザを特定する情報とを対応付ける。

電子決済サービスとは、１以上のユーザが、現金を用いずに金銭または金銭相当物の授受ができるサービスであり、限定でなく例として、一次元コード（バーコードなど）、二次元コード（ＱＲコード（登録商標）など）（以下で、一次元コードおよび二次元コードをまとめて「二次元コード等」と総称する。）、近距離無線通信（ＮＦＣ (Near Field Communication)、ＢＬＥ（Bluetooth（登録商標） Low Energy）、Wi-Fi（登録商標）、超音波通信、赤外線通信など）を利用して決済を行うサービスや、クレジットカードを利用して決済を行うサービスを含む。電子決済サービスの提供者が管理する決済サーバ等において、決済情報が記録される。

電子決済サービスのユーザを特定する情報とは、電子決済サービスにおいてユーザが利用するアカウントを意味している。アカウントは、個人と対応付けられていてもよいし、法人等に対応付けられていてもよい。以下の説明では、ユーザを特定する情報を、ユーザＩＤとして説明する。

商品管理情報とは、商品ＩＤと対応付けられた情報であり、個々の商品名、商品金額、商品ＩＤが取得された日時を示す商品ＩＤ取得日時、商品金額を合計した合計金額、店舗を特定するための情報である店舗ＩＤ等を含む。商品管理情報は、後述する商品登録システム２０によって管理される情報であり、サーバ１００が、後述する通信端末２３０を介して商品登録システム２０から取得する情報である。

商品ＩＤとは、商品を特定するために各商品に付与された情報であり、バーコードから読み取られてもよいし、ＱＲコードやＲＦ（radio frequency）タグ等の非接触タグから読み取られてもよい。

商品情報とは、商品ＩＤと、個々の商品名と、商品金額とが対応付けられた情報である。商品情報は、商品管理情報に含まれる。

決済情報とは、後述する決済用読み取り装置２２０から取得される情報に基づき、得られる情報である。決済情報は、電子決済サービスを利用したユーザを特定するためのユーザＩＤ、電子決済サービスにおいて決済された決済金額、決済が完了した日時等を含み、電子決済サービスの提供者によって取得される情報である。

本実施形態の商品登録システム２０は、商品登録装置２００、商品読み取り装置２１０、商品管理データベース４００を含む。商品登録システム２０は、例えば、ＰＯＳ（Point of sale）システム等である。

商品登録装置２００は、例えば、レジスタ等である。商品読み取り装置２１０は、商品ＩＤを読み取って商品登録装置２００へ送信する。商品読み取り装置２１０は、例えば、バーコードリーダ等の２次元コード読み取り装置や、近距離無線通信を用いた読み取り装置であってもよい。商品管理データベース４００は、商品情報が格納されたデータベースである。

また、本実施形態の商品登録装置２００は、決済用読み取り装置２２０及び通信端末２３０と接続されている。

決済用読み取り装置２２０は、例えば、ＩＣカードや端末１のディスプレイ等から、電子マネーと対応付けられたバーコードやＱＲコード等を読み取って、サーバ１００へ送信する。決済用読み取り装置２２０は、複数種類の電子決済サービスに対応したものであってもよいし、電子決済サービスの種類毎に設けられていてもよい。また、本実施形態の決済用読み取り装置２２０は、バーコードリーダ等の２次元コード読み取り装置や、近距離無線通信を用いた読み取り装置であってもよい。

通信端末２３０は、商品登録装置２００が取得した情報をサーバ１００へ送信する。通信端末２３０は、商品登録装置２００が取得した情報をサーバ１００へ送信することができる機器であれば、どのような機器であってもよい。

尚、商品登録装置２００が、商品登録装置２００が取得した情報をサーバ１００へ送信することができる場合には、通信端末２３０は設けられていなくても良い。商品登録装置２００が、商品登録装置２００が取得した情報をサーバ１００へ送信できる場合とは、例外的な場合である。

サーバ１００は、通信端末２３０から受信した情報に含まれる商品ＩＤに基づき、商品管理データベース４００から商品ＩＤと対応する商品情報を取得し、取得した商品情報を、商品ＩＤ取得日時と店舗ＩＤ、合計金額と対応付けて商品管理情報とする。そして、サーバ１００は、商品管理情報と決済情報とを突合させて、商品情報とユーザＩＤとを対応付ける。

以下に、その手順を説明する。

以下の説明では、端末１のユーザが、商品登録システム２０が設置された店舗で、電子決済サービスを用いて、商品群２を購入する場合について説明する。

商品登録システム２０において、商品登録装置２００は、商品読み取り装置２１０により商品ＩＤが読み取られると、商品管理データベース４００を参照して対応する商品金額を取得し、商品ＩＤと、商品ＩＤ取得日時と、商品金額の合計金額と、を通信端末２３０へ出力する（手順Ｓ１）。

尚、例えば、野菜や惣菜等のように、商品にバーコード等が取り付けられていない場合には、店員が、商品登録装置２００に対して、商品名と商品金額を直接入力してもよい。このとき、商品登録装置２００には、商品の個数も店員によって入力される。

通信端末２３０は、商品ＩＤと、商品ＩＤ取得日時と、商品金額の合計金額に、通信端末２３０を特定する情報を対応付けて、サーバ１００へ送信する（手順Ｓ２）。

また、商品登録システム２０において、商品登録装置２００は、商品金額の合計金額を端末１のユーザに提示すると共に、決済用読み取り装置２２０に出力する（手順Ｓ３）。

決済用読み取り装置２２０は、端末１がかざされて、端末１に表示されたＱＲコード等を読み取ることで、電子決済サービスのユーザＩＤを取得し、合計金額と、ユーザＩＤと、決済用読み取り装置２２０を特定する情報とを、サーバ１００へ送信する（手順Ｓ４）。

尚、ここでは、端末１に表示されたＱＲコードが決済用読み取り装置２２０に読み取られるものとしたが、これに限定されない。決済用読み取り装置２２０は、例えば、電子マネーがチャージされたＩＣカードやクレジットカード等からユーザＩＤを取得してもよい。

サーバ１００は、通信端末２３０から情報を受信すると、通信端末２３０を特定する情報を店舗ＩＤに変換する。また、サーバ１００は、商品管理データベース４００から、商品ＩＤと対応する商品情報を取得する。つまり、サーバ１００は、商品管理データベース４００から、商品ＩＤと対応する商品名と商品金額を取得する。

そして、サーバ１００は、商品ＩＤ取得日時、商品名、商品金額、店舗ＩＤを対応付けて、商品管理情報１０１とする。サーバ１００は、商品管理情報１０１を取得すると、この商品管理情報１０１に、商品ＩＤ取得日時に基づく付加情報を付与した第１突合対象情報として保管する。付加情報の詳細は後述する。

また、サーバ１００は、決済用読み取り装置２２０から情報を受信した後に、電子決済サービスを提供する決済サーバから決済完了の通知を受け付けると、決済用読み取り装置２２０を特定する情報を店舗ＩＤへ変換する。そして、サーバ１００は、合計金額を決済された決済金額とし、決済が完了した日時を示す決済完了日時と、ユーザＩＤとを対応付けた決済情報１０２を、第２突合対象情報として保管する。

本実施形態のサーバ１００は、商品管理情報１０１を含む第１突合対象情報と、決済情報１０２を含む第２突合対象情報とを突合させ（手順Ｓ５）、両者に含まれる、商品の購入に関する共通の情報に基づき、ユーザＩＤと、購入された個々の商品の商品情報とを対応付ける。突合した結果の情報は、突合済み情報１０３としてサーバ１００に格納される。

尚、図１に示す第１突合対象情報１０１、第２突合対象情報１０２、突合済み情報１０３は、一例であり、これに限定されない。これらの情報には、図１に示す情報の項目以外の項目が含まれてよいが、ここでは概要説明のため、簡略化している。第１突合対象情報、第２突合対象情報、突合済み情報の詳細は、後述する。

このように、本実施形態のサーバ１００は、商品管理情報と、決済情報とを取得し、それぞれに共通の情報に基づき、ユーザＩＤと、購入された個々の商品の商品情報とを対応付けている。

言い換えれば、サーバ１００は、商品登録システム２０が設置された店舗において、購入予定の商品の商品ＩＤに紐付いた商品管理情報と、購入予定の商品の決済が完了したときに取得される決済情報と、のそれぞれに含まれる、商品の購入に関する共通の情報に基づき、決済情報に含まれるユーザＩＤと、商品管理情報に含まれる商品情報とを対応付ける。

商品管理情報と、決済情報とにおける、商品の購入に関する共通の情報とは、店舗を特定する情報である店舗ＩＤ、商品が購入された日時に関する情報である商品ＩＤ取得日時と決済完了日時、商品の購入金額に関する情報である個々の商品の金額又は商品の合計金額と決済された決済金額である。尚、商品の合計金額は、例外的に、サーバ１００が商品登録装置２００から情報を取得できた場合に得られる情報であり、商品の合計金額が取得できない場合には、商品の合計金額自体が、突合処理によって得られる情報となる。

言い換えれば、商品管理情報と、決済情報とにおいて、商品の購入に関する共通する情報とは、商品の購入日時を示す情報、前記商品の購入金額を示す情報、前記商品が購入された位置を特定する情報である。

本実施形態では、このように、商品登録システム２０が設置された実店舗において、商品を購入した購入者と、購入者が購入した個々の商品情報とを対応付けることができる。

このため、本実施形態によれば、例えば、ユーザ毎の購入履歴が通信によって取得できない場合であっても、この店舗で商品を購入した購入者の端末１に、店舗で取り扱っている商品の広告情報を、ネットワークを介して通知することができる。

具体的には、例えば、ある店舗において、電子決済サービスを用いてビールを購入した購入者がいたとする。この場合、この店舗では、この購入者を特定するユーザＩＤと、この購入者が購入したビールに関する商品情報とが対応付けられている。したがって、この店舗は、この購入者に対し、店舗で取り扱っているビールに関する広告情報を、例えば、購入者の端末に通知し、表示させることができる。

したがって、本実施形態によれば、オンライン上に商品管理データベースが設けられていない店舗であっても、あたかもオンライン上に商品管理データベースが設けられているかのように、商品の購入者に広告情報を通知することができる。

さらに、本実施形態では、従来から店舗で管理されていた商品管理情報と、店舗に導入されている電子決済サービスを購入者が利用する際に取得される決済情報と、を用いて購入者と商品情報の対応付けを行っている。

言い換えれば、本実施形態では、店舗が保有している既存の資源を用いて、購入者と商品情報の対応付けを行う。したがって、本実施形態では、店舗側に新たな作業を発生させることがない。このため、本実施形態は、商品登録システムと商品管理データベースを有している店舗であれば、どのような店舗にも適用することができる。

さらに、本実施形態では、突合済み情報を端末１に提供することも考えられる。この場合、端末１のユーザは、電子決済サービスを用いて購入した商品の内訳を知ることができる。したがって、端末１のユーザは、例えば、家計簿等を作成する際に、端末１によって、購入した商品の内訳が記載されているレシートの写真を撮像し、レシートの画像から商品名を読み取らせる、と言った煩雑な操作を行う必要がなくなる。

以下に、本実施形態について、更に説明する。図２は、情報処理システムのシステム構成の一例を示す図である。

本実施形態の情報処理システム３００は、サーバ１００と、商品登録システム２０と、商品管理データベース４００、決済サーバ５００とを含む。尚、図２の例では、情報処理システム３００は、商品管理データベース４００や決済サーバ５００を含むものとしたが、これに限定されず、商品管理データベース４００と決済サーバ５００は、情報処理システム３００に含まれなくてもよい。

本実施形態のサーバ１００は、対応付けデータベース１１０、第１突合対象情報データベース１２０、第２突合対象情報データベース１３０、突合済み情報データベース１４０、情報処理部１５０を有する。

本実施形態の対応付けデータベース１１０は、商品登録システム２０と店舗とを対応づけるための情報等が格納されている。対応付けデータベース１１０は、予めサーバ１００に設けられていてもよい。第１突合対象情報データベース１２０は、情報処理部１５０の処理によって取得される第１突合対象情報が格納される。第２突合対象情報データベース１３０は、情報処理部１５０の処理によって取得される第２突合対象情報が格納される。突合済み情報データベース１４０は、情報処理部１５０の処理によって生成される突合済み情報が格納される。各データベースの詳細は後述する。

情報処理部１５０は、対応付けデータベース１１０、第１突合対象情報データベース１２０、第２突合対象情報データベース１３０、商品管理データベース４００を参照し、第１突合対象情報と第２突合対象情報とに基づき、突合済み情報を生成し、突合済み情報データベース１４０に格納する。

尚、以下に説明する実施形態では、突合済み情報を、突合済み情報データベース１４０に格納するものとしたが、これに限定されない。第１突合対象情報と第２突合対象情報とを突合した結果は、例えば、第１突合対象情報データベース１２０内で、突合の結果として特定されたユーザＩＤを第１突合対象情報と対応付ける形式で格納されてもよい。

この場合、第１突合対象情報データベース１２０において、商品情報とユーザＩＤとが対応付けられて蓄積されるため、突合済み情報データベース１４０を有していなくてもよい。

また、商品管理データベース４００に格納された商品情報は、予めサーバ１００内に取り込まれていてもよい。商品管理データベース４００の詳細は後述する。

決済サーバ５００は、サーバ１００からの決済可否の判定を要求されると、決済の可否を判定し、その結果をサーバ１００へ送信する。

次に、図３を参照して、本実施形態のサーバ１００のハードウェア構成について説明する。図３は、サーバのハードウェア構成の一例を示す図である。

本実施形態のサーバ１００は、それぞれバスＢで相互に接続されている入力装置１１、出力装置１２、ドライブ装置１３、補助記憶装置１４、メモリ装置１５、演算処理装置１６及びインターフェース装置１７を含む情報処理装置である。

入力装置１１は、各種の情報の入力を行うための装置であり、例えばキーボードやポインティングデバイス等により実現される。出力装置１２は、各種の情報の出力を行うためものであり、例えばディスプレイ等により実現される。インターフェース装置１７は、ＬＡＮカード等を含み、ネットワークに接続する為に用いられる。

後述する情報処理プログラムは、サーバ１００を制御する各種プログラムの少なくとも一部である。情報処理プログラムは、例えば記憶媒体１８の配布やネットワークからのダウンロード等によって提供される。情報処理プログラムを記録した記憶媒体１８は、ＣＤ−ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的、電気的或いは磁気的に記録する記憶媒体、ＲＯＭ、フラッシュメモリ等のように情報を電気的に記録する半導体メモリ等、様々なタイプの記憶媒体を用いることができる。

また、情報処理プログラムは、情報処理プログラムを記録した記憶媒体１８がドライブ装置１３にセットされると、記憶媒体１８からドライブ装置１３を介して補助記憶装置１４にインストールされる。ネットワークからダウンロードされた情報処理プログラムは、インターフェース装置１７を介して補助記憶装置１４にインストールされる。

補助記憶装置１４は、インストールされた情報処理プログラムを格納すると共に、各データベースや、必要なファイル、データ等を格納する。メモリ装置１５は、サーバ１００の起動時に補助記憶装置１４から情報処理プログラムを読み出して格納する。そして、演算処理装置１６はメモリ装置１５に格納された情報処理プログラムに従って、後述するような各種処理を実現している。

次に、図４を参照して、本実施形態の対応付けデータベース１１０について説明する。図４は、対応付けデータベースの一例を示す図である。

本実施形態の対応付けデータベース１１０は、商品登録システム２０に含まれる各装置と店舗を対応付ける対応付け情報１１０−１、１１０−２と、決済用読み取り装置２２０と店舗とを対応付ける対応付け情報１１０−３と、を含む。また、対応付けデータベース１１０は、決済手段ＩＤと決済手段名とを対応付ける対応付け情報１１０−４を含む。

対応付け情報１１０−１は、情報の項目として、通信端末ＩＤと、店舗ＩＤとを有する。通信端末ＩＤは、通信端末２３０を特定するための識別情報であり、店舗ＩＤは、店舗を特定するための識別情報である。

対応付け情報１１０−２は、情報の項目として、商品登録装置ＩＤと、店舗ＩＤとを有する。商品登録装置ＩＤは、商品登録装置２００を特定するための識別情報である。

対応付け情報１１０−３は、情報の項目として、決済用読み取り装置ＩＤと、店舗ＩＤとを有する。決済用読み取り装置ＩＤは、決済用読み取り装置２２０を特定するための識別情報である。

対応付け情報１１０−４は、情報の項目として、決済手段ＩＤと、決済手段名とを有する。決済手段ＩＤは、商品の購入者が利用する電子決済サービスの種類を特定する識別情報である。電子決済サービスの種類とは、例えば、クレジットカード決済や、電子マネーによる決済、スマートフォン等の携帯端末を用いたモバイル決済等である。決済手段名は、電子決済サービスの名称を示す情報である。

次に、図５を参照して、本実施形態の商品管理データベース４００について説明する。図５は、商品管理データベースの一例を示す図である。

本実施形態の商品管理データベース４００は、例えば、店舗ＩＤ毎に設けられていてもよい。商品管理データベース４００は、情報の項目として、商品ＩＤ、商品名、商品金額を有し、項目「商品ＩＤ」と、その他の項目とが対応付けられている。

項目「商品ＩＤ」の値は、商品を特定するための識別情報であり、項目「商品名」の値は、商品の名称を示し、項目「商品金額」の値は、商品の単価を示す。

次に、図６を参照して、本実施形態のサーバ１００の有する情報処理部１５０の機能について説明する。本実施形態の情報処理部１５０は、サーバ１００の演算処理装置１６が、メモリ装置１５等に格納されたプログラムを読みだして実行することで実現される。

図６は、サーバの機能を説明する図である。本実施形態のサーバ１００の情報処理部１５０は、商品管理情報取得部５１０、決済情報取得部５２０、情報付加部５３０、突合処理部５４０、対応付け部５５０を有する。

本実施形態の商品管理情報取得部５１０は、商品登録システム２０から、通信端末２３０を介して商品管理情報を取得する。具体的には、商品管理情報取得部５１０は、商品登録システム２０から、商品管理情報に含まれる商品ＩＤ、商品ＩＤ取得日時、通信端末ＩＤ等を取得し、商品管理データベース４００から商品ＩＤと対応した商品情報を取得する。

決済情報取得部５２０は、決済情報を取得する。具体的には、決済情報取得部５２０は、決済用読み取り装置２２０から、電子決済サービスのユーザＩＤ、決済金額、決済用読み取り装置２２０を特定する決済用読み取り装置ＩＤを取得する。また、決済情報取得部５２０は、決済サーバ５００から決済完了日時を取得する。

情報付加部５３０は、商品管理情報に対して、突合処理部５４０による処理で参照するための情報を付加し、第１突合対象情報とする。

情報付加部５３０によって付加される情報は、ある商品ＩＤと対応する商品と、その商品の前後の購入された商品とが、同一の購入者であるか否かを判定する際に参照される情報である。以下の説明では、情報付加部５３０によって付加される情報を、別客ＩＤと呼ぶ。情報付加部５３０の処理の詳細は後述する。

突合処理部５４０は、第１突合対象情報データベース１２０に格納された第１突合対象情報と、第２突合対象情報データベース１３０に格納された第２突合対象情報と、を突合させて、第１突合対象情報と第２突合対象情報が対応付けられるか否かを判定する。

突合処理部５４０は、情報抽出部５６０、情報判定部５７０、別客ＩＤ突合部５８０、購入履歴判定部５９０を有する。

情報抽出部５６０は、第１突合対象情報データベース１２０と第２突合対象情報データベース１３０から同一店舗において、一定の時間の間に取得された、第１突合対象情報と第２突合対象情報とを抽出する。

情報判定部５７０は、抽出した第１突合対象情報と第２突合対象情報に基づき、第１突合対象情報と第２突合対象情報から、電子決済サービスを用いて商品を購入した購入者のユーザＩＤと商品情報とが対応付けられるか否かを判定する。

別客ＩＤ突合部５８０は、情報判定部５７０によって、ユーザＩＤと商品情報とが対応付けられないと判定された場合に、第１突合対象情報に含まれる別客ＩＤを用いて、電子決済サービスを用いて商品を購入した購入者のユーザＩＤと商品情報とが対応付けられるか否かを判定する。

購入履歴判定部５９０は、別客ＩＤ突合部５８０によって、ユーザＩＤと商品情報とが対応付けられないと判定された場合に、ユーザＩＤと対応する購入履歴に基づき、商品の購入者と商品情報とが対応付けられるか否かを判定する。

対応付け部５５０は、突合処理部５４０による突合の結果、第１突合対象情報と第２突合対象情報とが対応付けられると判定された場合に、第１突合対象情報に含まれる商品情報と、第２突合対象情報に含まれるユーザＩＤとを対応付ける。そして、対応付け部５５０は、対応付けた結果を、突合済み情報として、突合済み情報データベース１４０に格納する。

また、本実施形態では、対応付け部５５０は、商品情報とユーザＩＤとに、商品ＩＤ取得日時や決済完了日時等の、商品を購入した時間帯を示す情報を対応付ける。したがって、突合済み情報には、ユーザＩＤ、商品情報、商品を購入した時間帯を示す情報が含まれる。

次に、図７を参照して、本実施形態の情報付加部５３０によって、商品管理情報に付加される別客ＩＤについて説明する。図７は、別客ＩＤについて概念的に説明する図である。

図７の例では、商品登録システム２０が設置された店舗において、購入者Ｐ１が、２つの商品を購入し、その次に、購入者Ｐ２が３つの商品を購入し、その次に、購入者Ｐ３が３つの商品を購入した場合を示している。

この場合、サーバ１００は、購入者Ｐ１が購入した２つの商品について、商品ＩＤ７１、７２を取得し、次に、購入者Ｐ２が購入した３つの商品の商品ＩＤ７３、７４、７５を取得し、次に、購入者Ｐ３が購入した３つの商品の商品ＩＤ７６、７７、７８を取得する。

本実施形態の情報付加部５３０では、ある商品ＩＤの商品ＩＤ取得日時から、次に商品ＩＤの商品ＩＤ取得日時までの間隔に、２種類の閾値を設け、各閾値と対応した２種類の別客ＩＤ１、別客ＩＤ２を商品ＩＤに付加する。

情報付加部５３０は、ある商品ＩＤの商品ＩＤ取得日時から、次に商品ＩＤを取得したときの商品ＩＤ取得日時までの間隔が、２種類の閾値のうち、第１の閾値未満である場合、これらの商品ＩＤと対応する複数の商品は、同一の購入者によって購入されたものと判定する。第１の閾値とは、例えば、１５秒程度である。

したがって、情報付加部５３０は、ある商品ＩＤの商品ＩＤ取得日時から、次に商品ＩＤを取得したときの商品ＩＤ取得日時までの間隔が第１の閾値未満である場合、これらの商品ＩＤに同一の別客ＩＤ１を付加し、第１の閾値以上である場合には、それぞれに異なる別客ＩＤ１を付加する。

また、情報付加部５３０は、ある商品ＩＤの商品ＩＤ取得日時から、次に商品ＩＤを取得したときの商品ＩＤ取得日時までの間隔が、２種類の閾値のうち、第２の閾値以上である場合、これらの商品ＩＤと対応する複数の商品は、別々の購入者によって購入されたものと判定する。第２の閾値とは、例えば、３分程度である。つまり、第２の閾値は、第１の閾値よりも値の大きい閾値である。

したがって、情報付加部５３０は、ある商品ＩＤの商品ＩＤ取得日時から、次に商品ＩＤを取得したときの商品ＩＤ取得日時までの間隔が第２の閾値以上である場合、これらの商品ＩＤに異なる別客ＩＤ２を付加し、第２の閾値未満である場合には、それぞれに同一の別客ＩＤ２を付加する。

つまり、別客ＩＤ１と別客ＩＤ２とは、複数の商品が同一の購入者によって購入された商品であるか否かを判定する際に参照される第１付加情報と、第２付加情報である。

本実施形態の別客ＩＤ突合部５８０は、始めに、別客ＩＤ１が一致する商品ＩＤが示す商品を、同一の購入者によって購入されたものとして、第１突合対象情報に含まれる商品情報と、第２突合対象情報に含まれるユーザＩＤとが対応付けられるか否かを判定する。

そして、別客ＩＤ突合部５８０は、別客ＩＤ１が一致する場合であっても、ユーザＩＤと商品情報とが対応付けられないと判定された場合に、別客ＩＤ２が一致する商品のうち、別客ＩＤ１の組み合わせ毎に、同一の購入者によって購入されたものとして、ユーザＩＤと対応付けられるか否かを判定する。

図７の例では、サーバ１００が商品ＩＤ７１を取得した時刻から、商品ＩＤ７２を取得した時刻までの間隔は、１５秒未満である。したがって、情報付加部５３０は、商品ＩＤ７１と商品ＩＤ７２のそれぞれに、同一の別客ＩＤ１「１００」を付加する。

また、商品ＩＤ７１を取得した時刻から、商品ＩＤ７２を取得した時刻までの間隔は、３分未満でもある。したがって、情報付加部５３０は、商品ＩＤ７１と商品ＩＤ７２のそれぞれに、同一の別客ＩＤ２「５００」を付加する。

また、サーバ１００が商品ＩＤ７２を取得した時刻から、商品ＩＤ７３を取得した時刻までの間隔は、１５秒以上であり、３分未満である。したがって、情報付加部５３０は、商品ＩＤ７３に対し、商品ＩＤ７２と異なる別客ＩＤ１「１０１」を付加し、別客ＩＤ２は、商品ＩＤ７２と同様の「５００」を付与する。

また、図７の例では、サーバ１００が商品ＩＤ７５の商品ＩＤ取得日時から、商品ＩＤ７６を商品ＩＤ取得日時までの間隔は、３分以上である。したがって、情報付加部５３０は、商品ＩＤ７６に対し、商品ＩＤ７５の別客ＩＤ１「１０２」と異なる別客ＩＤ１「１０３」と、商品ＩＤ７５の別客ＩＤ２「５００」と異なる別客ＩＤ２「５０１」と、を付加する。

以上のように、本実施形態では、第１付加情報（別客ＩＤ１）と第２付加情報（別客ＩＤ２）とを商品ＩＤに付加することで、同一の購入者に購入された可能性が高い商品と、別々の購入者に購入された可能性が高い商品とを区別している。

次に、図８を参照して、本実施形態の情報処理システム３００の動作について説明する。図８は、情報処理システムの動作を説明するシーケンス図である。

本実施形態では、ステップＳ８０１からステップＳ８２３までの処理によって、第１突合対象情報が生成される。したがって、ステップＳ８０１からステップＳ８２３までの処理は、第１突合対象情報を生成する処理と言える。第１突合対象情報の詳細は後述する。

ステップＳ８０１からステップＳ８０７までの処理は、商品読み取り装置２１０が商品ＩＤを読み取ったときの商品読み取り装置２１０と通信端末２３０の動作を示す。

本実施形態の情報処理システム３００において、商品読み取り装置２１０は、購入者Ｐによる購入予定の商品から商品ＩＤを読み取り（ステップＳ８０１）、商品ＩＤを取得する（ステップＳ８０２）。このとき、商品読み取り装置２１０は、商品ＩＤを取得した日時を示す商品ＩＤ取得日時を取得する（ステップＳ８０３）。

続いて、商品読み取り装置２１０は、商品ＩＤと、商品ＩＤ取得日時と、を通信端末２３０へ送信する（ステップＳ８０４）。また、商品読み取り装置２１０は、商品ＩＤを商品登録装置２００へ送信する（ステップＳ８０５）。

通信端末２３０は、商品読み取り装置２１０から商品ＩＤと商品ＩＤ取得日時を取得すると、商品ＩＤと商品ＩＤ取得日時をサーバ１００へ送信する（ステップＳ８０６）。また、通信端末２３０は、自機の通信端末ＩＤをサーバ１００へ送信する（ステップＳ８０７）。

また、本実施形態では、「サーバ１００が、商品登録装置２００から、商品登録装置２００に入力された情報を取得することが可能である」という条件が満たされる場合には、ステップＳ８１６からステップＳ８２２までの処理Ｂを行い、ステップＳ８０４、８０５、８０７の処理は行わない。

ステップＳ８０８からステップＳ８１３までは、サーバ１００が商品ＩＤを受信したときのサーバ１００の動作を示す。

サーバ１００は、商品ＩＤと、商品ＩＤ取得日時と、通信端末ＩＤとを受信すると、商品管理情報取得部５１０により、これらの情報を第１突合対象情報データベース１２０に格納する（ステップＳ８０８）。

また、サーバ１００は、商品登録システム２０において、商品ＩＤ取得日時が取得されなかった場合には、処理Ａを実行する。処理Ａにおいて、サーバ１００は、商品管理情報取得部５１０により、サーバ１００が商品ＩＤを受信した日時を商品ＩＤ取得日時として、第１突合対象情報データベース１２０に格納する（ステップＳ８０９）。

次に、サーバ１００は、商品管理情報取得部５１０により、対応付け情報１１０の対応付け情報１１０−１を参照し、第１突合対象情報データベース１２０に格納された通信端末ＩＤを、店舗ＩＤに変換する（ステップＳ８１０）。

続いて、サーバ１００は、商品管理情報取得部５１０により、商品管理データベース４００へ商品ＩＤと対応する商品情報の取得要求を行い（ステップＳ８１１）、該当する商品情報を取得する（ステップＳ８１２）。

続いて、サーバ１００は、商品管理情報取得部５１０により、取得した商品情報を、商品ＩＤと対応付けて第１突合対象情報データベース１２０に格納する（ステップＳ８１３）。

尚、図８では、購入者Ｐの商品の購入時に、サーバ１００において、商品ＩＤと商品情報の対応付けが行われるものとしたが、これに限定されない。例えば、店舗に商品が入荷された際に、店舗のスタッフ等によって、商品読み取り装置２１０により商品ＩＤが読み取られてサーバ１００へ送信され、サーバ１００において、商品ＩＤと商品情報との対応付けが行われてもよい。また、本実施形態では、サーバ１００が、予め商品管理データベース４００をサーバ１００内に取得しておいてもよい。

ステップＳ８１４からステップＳ８１６までは、商品登録装置２００が商品ＩＤを取得したときの商品登録装置２００の動作を示す。

商品登録装置２００は、商品ＩＤを取得した後に、商品の購入個数の入力を受け付ける（ステップＳ８１４）。また、商品登録装置２００は、商品ＩＤと、商品ＩＤと対応する商品の購入個数との入力を受け付ける（ステップＳ８１５）。

続いて、商品登録装置２００は、合計金額を求め、決済用読み取り装置２２０へ合計金額を通知する（ステップＳ８１６）。

商品登録装置２００は、商品ＩＤと購入個数とを、サーバ１００へ送信する（ステップＳ８１７）。また、商品登録装置２００は、決済手段を特定する決済手段ＩＤをサーバ１００へ送信する（ステップＳ８１８）。続いて、商品登録装置２００は、商品登録装置２００の商品登録装置ＩＤをサーバ１００に送信する（ステップＳ８１９）。

サーバ１００は、商品管理情報取得部５１０により、商品登録装置２００から受信した商品ＩＤ、購入個数、決済手段ＩＤを第１突合対象情報データベース１２０に格納する（ステップＳ８２０）。

続いて、サーバ１００は、商品管理情報取得部５１０により、商品登録装置２００から情報を受信した日時を商品ＩＤ取得日時として、第１突合対象情報データベース１２０に格納する（ステップＳ８２１）。

続いて、サーバ１００は、商品管理情報取得部５１０により、対応付けデータベース１１０の対応付け情報１１０−２、１１０−３を参照して、商品登録装置ＩＤを店舗ＩＤへ変換し、決済手段ＩＤを決済手段名に変換する（ステップＳ８２２）。

次に、サーバ１００は、情報付加部５３０により、前回商品ＩＤを取得したときの商品ＩＤ取得日時から今回の商品ＩＤの商品ＩＤ取得日時までの間隔が第一の閾値以上である場合、第１突合対象情報データベース１２０において、この商品ＩＤに、前回取得した商品ＩＤに付与した別客ＩＤ１をインクリメントした値を付与する（ステップＳ８２３）。

また、サーバ１００は、情報付加部５３０により、前回商品ＩＤを取得したときの商品ＩＤ取得日時から今回の商品ＩＤの商品ＩＤ取得日時までの間隔が第二の閾値以上である場合、第１突合対象情報データベース１２０において、この商品ＩＤに、前回取得した商品ＩＤに付与した別客ＩＤ２をインクリメントした値を付与する（ステップＳ８２４）。

本実施形態では、ステップＳ８２５からステップＳ８３９までの処理により、第２突合対象情報が生成される。したがって、ステップＳ８２５からステップＳ８３９までの処理は、第２突合対象情報を生成する処理と言える。第２突合対象情報の詳細は後述する。

ステップＳ８２５からステップＳ８２９までの処理は、決済用読み取り装置２２０の動作を示す。

決済用読み取り装置２２０は、商品登録装置２００から支払い金額を取得すると、支払い金額を購入者Ｐに対して提示する（ステップＳ８２５）。決済用読み取り装置２２０は、購入者Ｐから、決済手段の提示を受け付ける（ステップＳ８２６）。尚、決済手段の提示とは、具体的には、購入者Ｐの端末に表示されたＱＲコードや、クレジットカード、電子マネーがチャージされたＩＣカード等が提示されることを示す。

続いて、決済用読み取り装置２２０は、電子決済サービスを利用する購入者Ｐを特定するユーザＩＤを取得し、サーバ１００へ送信する（ステップＳ８２７）。また、決済用読み取り装置２２０は、電子決済サービスで決済される決済金額（支払い金額）をサーバ１００へ送信する（ステップＳ８２８）。

さらに、決済用読み取り装置２２０は、決済用読み取り装置ＩＤをサーバ１００に送信し（ステップＳ８２９）、提示された決済手段ＩＤをサーバ１００へ送信する（ステップＳ８３０）。

尚、本実施形態では、サーバ１００が決済用読み取り装置２２０から直接情報を取得できない場合には、決済用読み取り装置２２０がステップＳ８２７からステップＳ８３０で取得した情報は、決済用読み取り装置２２０を管理する外部サーバへ送信されてもよい。

この場合、サーバ１００は、この外部サーバに対して、情報の取得要求を行ってもよい。具体的には、例えば、決済用読み取り装置２２０は、購入者Ｐから決定手段の提示を受けて、決済用読み取り装置ＩＤをサーバ１００へ通知し、サーバ１００は、この決済用読み取り装置ＩＤと対応付く情報の取得要求を外部サーバへ行ってもよい。

ステップＳ８３１からステップＳ８３９までは、サーバ１００が決済用読み取り装置２２０から情報を受信した後のサーバ１００の動作を示す。

サーバ１００は、決済用読み取り装置２２０から受信したユーザＩＤ、決済金額、決済用読み取り装置ＩＤ、決済手段ＩＤを第２突合対象情報データベース１３０に格納する（ステップＳ８３１）。

続いて、サーバ１００は、決済情報取得部５２０により、対応付けデータベース１１０の対応付け情報１１０−４を参照して、第１突合対象情報データベース１２０における、決済手段ＩＤを決済手段名へ変換する（ステップＳ８３２）。

続いて、サーバ１００は、決済情報取得部５２０により、決済用読み取り装置２２０から情報を取得した日時を決済情報取得日時として第１突合対象情報データベース１２０に格納する（ステップＳ８３３）。

続いて、サーバ１００は、決済情報取得部５２０により、対応付けデータベース１１０対応付け情報１１０−３を参照して、第２突合対象情報データベース１３０における、決済用読み取り装置ＩＤを店舗ＩＤへ変換する（ステップＳ８３４）。

続いて、サーバ１００は、決済情報取得部５２０により、決済サーバ５００に対して決済の可否の判定を要求し（ステップＳ８３５）、決済サーバ５００から決済完了の通知を受け付ける（ステップＳ８３６）。

続いて、サーバ１００は、決済情報取得部５２０により、決済完了の通知を受け付けた日時を、決済完了日時として、第２突合対象情報データベース１３０に格納する（ステップＳ８３７）。

続いて、サーバ１００は、決済情報取得部５２０により、決済完了の通知を決済用読み取り装置２２０へ送信し（ステップＳ８３８）、決済用読み取り装置２２０は、決済の完了の通知を購入者Ｐに通知する（ステップＳ８３９）。

サーバ１００は、第１突合対象情報と第２突合対象情報が生成されると、突合処理部５４０によって第１突合対象情報と第２突合対象情報を突合させて、購入者と商品情報との対応付けを行い（ステップＳ８３９）、処理を終了する。

尚、図８では、突合処理部５４０によるステップＳ８３９の処理は、購入者Ｐによる商品の購入時の一連の処理の１つとしているが、これに限定されない。突合処理部５４０による処理は、購入者が商品を購入するタイミングと無関係に、任意のタイミングで実行されてもよい。例えば、突合処理部５４０の処理は、予め決められた時刻となったときに実行されてもよいし、定期的に実行されてもよいし、店舗側からのリクエスト等に応じて実行されてもよい。突合処理部５４０の処理の詳細は後述する。

次に、図９乃至図１１を参照して、第１突合対象情報と第２突合対象情報の生成の手順について説明する。始めに、図９と図１０を参照して、図８の処理Ｂが実行されない場合の第１突合対象情報と、処理Ｂが実行された場合の第１突合対象情報と、について説明する。

図９は、第１突合対象情報の生成の手順を説明する第一の図である。図９に示す例は、図８において、処理Ｂが行われない場合における第１突合対象情報の生成の手順の例を示している。

図９（Ａ）は、図８のステップＳ８０７において、第１突合対象情報データベース１２０に格納されている情報１２０−Ａを示している。ここでは、第１突合対象情報データベース１２０には、商品読み取り装置２１０から取得した商品ＩＤ、通信端末ＩＤ、商品ＩＤ取得日時を含む情報１２０−Ａが格納される。

尚、情報１２０−Ａにおいて、商品ＩＤ取得日時として、「２０１８１００３１２４５０８」と示される場合には、２０１８年１０月３１日１２時４５分０８秒という日時を示している。

図９（Ｂ）は、図８のステップＳ８１２において第１突合対象情報データベース１２０に格納されている情報１２０−Ｂを示している。

情報１２０−Ｂには、商品管理データベース４００から取得された商品情報が、情報１２０−Ａに追加されている。また、情報１２０−Ｂでは、通信端末ＩＤが店舗ＩＤに変換されている。

したがって、情報１２０−Ｂは、商品ＩＤ、店舗ＩＤ、商品ＩＤ取得日時、商品名、商品金額を含む。

図９（Ｃ）は、図８のステップＳ８２３において第１突合対象情報データベース１２０に格納された情報１２０−Ｃを示している。つまり、情報１２０−Ｃは、本実施形態の第１突合対象情報の一例である。

情報１２０−Ｃには、情報１２０−Ｂに加えて、別客ＩＤ１と別客ＩＤ２とが付与されている。したがって、情報１２０−Ｃは、商品ＩＤ、店舗ＩＤ、商品ＩＤ取得日時、商品名、商品金額、別客ＩＤ１、別客ＩＤ２を含む。

つまり、情報１２０−Ｃは、商品ＩＤ、店舗ＩＤ、商品ＩＤ取得日時、商品名、商品金額を含む商品管理情報と、別客ＩＤ１、別客ＩＤ２とを含む情報となる。

図１０は、第１突合対象情報が生成される手順を説明する第二の図である。図１０に示す例は、図８において、処理Ｂが行われる場合における第１突合対象情報の生成の手順を示している。

図１０（Ａ）は、図８のステップＳ８１９において、第１突合対象情報データベース１２０に格納されている情報１２０−Ａ′を示している。ここでは、第１突合対象情報データベース１２０には、商品ＩＤ、購入個数、商品登録装置ＩＤを含む情報１２０−Ａ′が格納される。

図１０（Ｂ）は、図８のステップＳ８２１において第１突合対象情報データベース１２０に格納されている情報１２０−Ｂ′を示している。

情報１２０−Ｂ′では、サーバ１００が商品登録装置２００から、情報１２０−Ａ′に対して、商品ＩＤを取得した日時を示す商品ＩＤ取得時間が追加されている。また、情報１２０−Ａ′では、商品登録装置ＩＤを店舗ＩＤに変換されており、決済手段ＩＤが決済手段名に変換されている。

したがって、情報１２０−Ｂ′は、商品ＩＤ、購入個数、決済手段ＩＤ、店舗ＩＤ、商品ＩＤ取得時間を含む。

図１０（Ｃ）は、図１０のステップＳ８２３において第１突合対象情報データベース１２０に格納された情報１２０−Ｃ′を示している。つまり、情報１２０−Ｃ′は、本実施形態の第１突合対象情報の一例である。

情報１２０−Ｃ′には、情報１２０−Ｂ′に加えて、商品情報と、別客ＩＤ１と別客ＩＤ２とが付与されている。したがって、情報１２０−Ｃ′は、商品ＩＤ、購入個数、店舗ＩＤ、商品ＩＤ取得日時、商品名、商品金額、決済手段ＩＤ、別客ＩＤ１、別客ＩＤ２を含む。

つまり、情報１２０−Ｃ′は、商品ＩＤ、購入個数、決済手段ＩＤ、店舗ＩＤ、商品ＩＤ取得時間を含む商品管理情報と、別客ＩＤ１、別客ＩＤ２とを含む情報となる。

次に、図１１を参照して、第２突合対象情報の生成の手順について説明する。図１１は、第２突合対象情報の生成の手順について説明する図である。

図１１（Ａ）は、図８のステップＳ８３０において、第２突合対象情報データベース１３０に格納されている情報１３０−Ａを示している。ここでは、第２突合対象情報データベース１３０には、ユーザＩＤ、決済金額、決済用読み取り装置ＩＤ、決済手段ＩＤを含む情報１３０−Ａが格納される。

図１１（Ｂ）は、図８のステップＳ８３３において、第２突合対象情報データベース１３０に格納されている情報１３０−Ｂを示している。情報１３０−Ｂでは、情報１３０−Ａに、情報１３０−Ａを取得した日時を示す決済情報取得日時が追加されている。また、情報１３０−Ａでは、決済用読み取り装置ＩＤが店舗ＩＤに変換されており、決定手段ＩＤが決済手段名に変換されている。

図１１（Ｃ）は、図８のステップＳ８３６において、第２突合対象情報データベース１３０に格納されている情報を示している。つまり、情報１３０−Ｃは、本実施形態の第２突合対象情報の一例である。

情報１３０−Ｃでは、情報１３０−Ｂに、決済が完了した日時を示す決済完了日時が追加されている。したがって、情報１３０−Ｃは、ユーザＩＤ、店舗ＩＤ、決済手段名、決済情報取得日時、決済完了日時を含む決済情報である。

次に、図１２を参照して、突合処理部５４０による、図９乃至図１１で生成の手順を説明した第１突合対象情報と第２突合対象情報との突合処理について説明する。図１２は、突合処理部による処理を説明するフローチャートである。図１２の処理は、図８のステップＳ８３９の処理の詳細を示している。

本実施形態のサーバ１００において、突合処理部５４０は、情報抽出部５６０により、第１突合対象情報データベース１２０と第２突合対象情報データベース１３０とから、店舗ＩＤが一致し、且つ、商品ＩＤ取得日時と決済完了日時との差が５分以内である第１突合対象情報と第２突合対象情報を抽出する（ステップＳ１２０１）。

尚、商品ＩＤ取得日時と決済完了日時との差は、５分以内に限定されない。ここでは、一人の購入者が商品の購入する際に、商品ＩＤの読み取りから決済の完了までにかかる時間の上限を５分間とみなし、５分以内としている。

続いて、突合処理部５４０は、情報判定部５７０により、抽出した第１突合対象情報に、商品の購入個数と商品金額が含まれるか否かを判定する（ステップＳ１２０２）。言い換えれば、突合処理部５４０は、図８の処理Ｂが実行されたか否かを判定している。ステップＳ１２０２においてＹｅｓの場合とは、図８の処理Ｂが実行された場合である。

図８の処理Ｂが実行されると、第１突合対象情報に含まれる項目は、図１０（Ｃ）に示す情報１２０−Ｃ′のようになる。したがって、情報判定部５７０は、抽出された第１突合対象情報が、図１０（Ｃ）に示す情報１２０−Ｃ′が示す項目を含むか否かを判定している。

ステップＳ１２０２において、購入個数と商品金額が含まれない場合、突合処理部５４０は、後述するステップＳ１２０７へ進む。

ステップＳ１２０２において、購入個数と商品金額が含まれる場合、情報判定部５７０は、抽出した第１突合対象情報のうちの、ある第１突合対象情報について、商品の合計金額と同額の決済金額の決済を行ったユーザが一意に特定できるか判定する（ステップＳ１２０３）。言い換えれば、情報判定部５７０は、ある第１突合対象情報について、合計金額と、決済金額が一致する第２突合対象情報を一意に特定できるか否かを判定している。

ステップＳ１２０３において、一意に特定できる場合、後述するステップＳ１２０６へ進む。

以下に、ステップＳ１２０３について具体的に説明する。例えば、図１０（Ｃ）に示すように、ある第１突合対象情報の商品名がおにぎりであり、商品金額が２００円であり、購入個数が２個である場合、購入者が、２００円のおにぎり２個のみを購入していれば、決済金額は４００円となる。したがって、情報判定部５７０は、抽出した第２突合対象情報に、決済金額が４００円の第２突合対象情報が１つ存在する場合には、商品名がおにぎりであり、商品金額が２００円であり、購入個数が２個である第１突合対象情報について、第２突合対象情報を一意に特定できたものと判定し、後述するステップＳ１２０６へ進む。

また、情報判定部５７０は、決済金額が４００円の第２突合対象情報が存在しない場合に、商品名がおにぎりであり、商品金額が２００円であり、購入個数が２個である第１突合対象情報と対応する第２突合対象情報を一意に特定できないと判定し、ステップＳ１２０４へ進む。

この場合、購入者が、商品名がおにぎりであり、商品金額が２００円であり、購入個数が２個である第１突合対象情報が示す商品以外の商品も、一緒に購入した場合が考えられる。つまり、この購入者は、１つ２００円のおにぎり２つの他にも商品を購入したと考えられる。

つまり、ある第１突合対象情報と対応する第２突合対象情報が一意に特定されない場合とは、第１突合対象情報の１つのレコードから算出される合計金額と、決済金額が一致する第２突合対象情報が存在しない場合を示す。

ステップＳ１２０３において、一意に特定できない場合、情報判定部５７０は、抽出した第１突合対象情報と第２突合対象情報のそれぞれに決済手段名が含まれるか否かを判定する（ステップＳ１２０４）。ステップＳ１２０４において、決済手段名が含まれない場合、突合処理部５４０は、処理を終了する。

尚、この場合、突合処理部５４０は、後述する図１５に示すように、ある第１突合対象情報に含まれる商品情報を抽出し、対応付けられるユーザＩＤが不明な突合済み情報として、突合済み情報データベース１４０に格納してもよい。

ステップＳ１２０４において、決済手段名が含まれる場合、突合処理部５４０は、情報判定部５７０により、ある第１突合対象情報と、決済手段名が一致する第２突合対象情報との組み合わせが一意に特定できるか否かを判定する（ステップＳ１２０５）。

以下に、ステップＳ１２０５について具体的に説明する。例えば、ある第１突合対象情報の決済手段名がＳｕｉｃａ（登録商標）であったとする。この場合、情報判定部５７０は、抽出した第１突合対象情報の中から、決済手段名がＳｕｉｃａ（登録商標）である第１突合対象情報を取得する。

ここでは、ある第１突合対象情報の商品名がおにぎりであり、商品金額が２００円であり、購入個数が２個とし、決済手段名がＳｕｉｃａ（登録商標）である他の第１突合対象情報の商品名がお茶であり、商品金額が１５０円であり、購入個数が１個とする。

この場合、おにぎりとお茶が同一の購入者によって購入された場合、決済金額は５５０円となる。したがって、情報判定部５７０は、決済金額が５５０円である第２突合対象情報が存在する場合に、商品名がおにぎりである第１突合対象情報と、商品名がお茶である第１突合対象情報と、決済金額が５５０円の第２突合対象情報とを一意に特定される組み合わせとする。

ステップＳ１２０５において、組み合わせが一意に特定できない場合、突合処理部５４０は、処理を終了する。一意に特定できない場合とは、決済手段名が一致している複数の第１突合対象情報のそれぞれから求められる合計金額の合算と、決済金額が一致する第２突合対象情報が存在しない場合である。

ステップＳ１２０５において、組み合わせが一意に特定できる場合、突合処理部５４０は、対応付け部５５０によって、ある第１突合対象情報に含まれる商品情報と、一意に特定された第２突合対象情報に含まれるユーザＩＤとを対応づけて、突合済み情報として突合済み情報データベース１４０に格納し（ステップＳ１２０６）、処理を終了する。

具体的には、対応付け部５５０は、特定された組み合わせにおける第１突合対象情報に含まれる商品情報として、「おにぎり、２００円」と、「お茶、１５０円」とを抽出し、特定された組み合わせにおける第２突合対象情報に含まれるユーザＩＤと対応付ける。

ステップＳ１２０２において、第１突合対象情報に購入個数と商品金額が含まれない場合、つまり、第１突合対象情報が図９（Ｃ）に示す情報１２０−Ｃが示す項目を含む第１突合対象情報である場合、突合処理部５４０は、別客ＩＤ突合部５８０による処理を行う（ステップＳ１２０７）。ステップＳ１２０７の処理の詳細は後述する。

続いて、突合処理部５４０は、情報判定部５７０により、ステップＳ１２０７の処理を行った結果、計算式の解が単一であるか否かを判定する（ステップＳ１２０８）。この場合、第１突合対象情報に対応する第２突合対象情報が一意に特定されたことになるため、突合処理部５４０は、ステップＳ１２０６へ進む。

ステップＳ１２０８において、計算式の解が単一でない場合、突合処理部５４０は、購入履歴判定部５９０により、突合済み情報データベース１４０を参照し、第１突合対象情報が示す商品と一致する商品を、過去に購入したユーザが存在するか否かを判定する（ステップＳ１２０９）。

具体的には、購入履歴判定部５９０は、突合済み情報データベース１４０に蓄積された突合済み情報に、第１突合対象情報の商品ＩＤが一致する商品ＩＤと対応付けられたユーザＩＤが存在するか否かを判定している。

ステップＳ１２０９において、該当するユーザが存在しない場合、突合処理部５４０は、ユーザＩＤを不明として、第１突合対象情報の商品情報を突合済み情報データベース１４０へ格納し、処理を終了する。

ステップＳ１２０９において、該当するユーザが存在する場合、購入履歴判定部５９０は、過去の突合済み情報において、最も多く第１突合対象情報が示す商品と一致する商品を購入しているユーザが一意に特定できるか否かを判定する（ステップＳ１２１０）。尚、ここで特定されるユーザは、第１突合対象情報が示す商品と一致する商品の購入個数が最も多いユーザであってもよいし、該当する商品の購入回数が最も多いユーザであってもよい。

ステップＳ１２１０において、該当するユーザが特定される場合、突合処理部５４０は、特定されたユーザのユーザＩＤを含む第２突合対象情報を、第１突合対象情報と対応付けられる第２突合対象情報に特定し、ステップＳ１２０６へ進む。

ステップＳ１２１０において、該当するユーザが特定されない場合、突合処理部５４０は、購入履歴判定部５９０により、過去の突合済み情報において、最も多く第１突合対象情報が示す商品と一致する商品を購入しているユーザのうち、過去に、ステップＳ１２０１で抽出した第１突合対象情報に含まれる店舗ＩＤによって特定される店舗で商品を購入した履歴があるユーザが一人特定できるか否かを判定する（ステップＳ１２１１）。

具体的には、購入履歴判定部５９０は、過去の突合済み情報から、最も多く第１突合対象情報が示す商品と一致する商品を購入しているユーザのユーザＩＤと決済完了日時とを抽出し、第２ソース情報データベース１３０を参照して、このユーザＩＤが商品を購入した店舗の店舗ＩＤを特定し、ステップＳ１２０１で抽出した第１突合対象情報と一致するか否かを判定する。

ステップＳ１２１１において、該当するユーザが特定されない場合、突合処理部５４０は、ユーザＩＤを不明として、第１突合対象情報の商品情報を突合済み情報データベース１４０へ格納し、処理を終了する。

ステップＳ１２１１において、該当するユーザが特定された場合、特定されたユーザのユーザＩＤを含む第２突合対象情報を、第１突合対象情報と対応付けられる第２突合対象情報に特定し、ステップＳ１２０６へ進む。

本実施形態の突合処理部５４０は、図１２に示す処理を、第１突合対象情報データベース１２０に格納された全ての第１突合対象情報と第２突合対象情報について行う。

次に、図１３から図１５を参照して、本実施形態の別客ＩＤ突合部５８０の処理について説明する。図１３は、別客ＩＤ判定部の処理を説明するフローチャートである。図１３は、図１２のステップＳ１２０７の処理の詳細を示している。図１４は、別客ＩＤ突合部の処理におけるデータの流れを示す第一の図であり、図１５は、別客ＩＤ突合部の処理におけるデータの流れを示す第二の図である。

本実施形態の別客ＩＤ突合部５８０は、第１突合対象情報データベース１２０から、値が最も小さい別客ＩＤ１が付与された第１突合対象情報を抽出する（ステップＳ１３０１）。

図１４（Ａ）の第１突合対象情報１２１−Ａは、図１３のステップＳ１３０１で抽出された第１突合対象情報の一例を示す。第１突合対象情報１２１−Ａにおいては、最も値の小さい別客ＩＤ１は、「１００」である。

続いて、別客ＩＤ突合部５８０は、抽出した第１突合対象情報の商品ＩＤ取得日時のうち、最も遅い時刻から、５分以内に取得された第２突合対象情報を抽出する（ステップＳ１３０２）。

言い換えれば、別客ＩＤ突合部５８０は、抽出した各第１突合対象情報の商品ＩＤ取得日時のうち、最も遅い時刻から、所定の時間内に、決済完了日時が含まれる第２突合対象情報を抽出する。

ここでは、別客ＩＤ突合部５８０は、第１突合対象情報１２１−Ａのうち、商品ＩＤ取得日時が最も遅い時刻であるレコードＲ１を特定し、レコードＲ１の商品ＩＤ取得日時から５分以内に取得された第２突合対象情報を抽出する。

図１４（Ｂ）に示す第２突合対象情報１３１−Ａは、ステップＳ１３０２において抽出された第２突合対象情報の一例を示す。

続いて、別客ＩＤ突合部５８０は、抽出した第２突合対象情報１３１−Ａのうち、決済完了日時が早い順に、決済金額と購入個数の組み合わせとを算出する（ステップＳ１３０３）。

続いて、別客ＩＤ突合部５８０は、ステップＳ１３０３の結果として、整数解が得られたか否かを判定する（ステップＳ１３０４）。ステップＳ１３０４において、整数解が得られた場合には、図１２のステップＳ１２０８へ進む。

具体的には、別客ＩＤ突合部５８０は、図１４（Ａ）、（Ｂ）に示す第１突合対象情報１２１−Ａと第２突合対象情報１３１−Ａを抽出すると、ステップＳ１３０３において、決済完了日時が早い第２突合対象情報１３１−Ａから順に、購入個数の組み合わせを算出する。

例えば、第２突合対象情報１３１−Ａにおいて、最も決済完了日時が早い決済金額は、３５０円である。また、第１突合対象情報１２１−Ａでは、３種類の商品の商品金額が含まれる。そこで、別客ＩＤ突合部５８０は、３種類の商品それぞれの購入個数をｎ１、ｎ２、ｎ３とし、以下の式（１）を満たし、且つ、ｎ１、ｎ２、ｎ３が整数となる解を求める。

ｎ１×１００＋ｎ２×２００＋ｎ３×５０＝３５０ 式（１）
ここで、ｎ１、ｎ２、ｎ３が全て整数となる解が得られた場合には、別客ＩＤ突合部５８０は、図１２のステップＳ１２０８へ進む。

つまり、本実施形態の別客ＩＤ突合部５８０は、別客ＩＤ１が一致する第１突合対象情報のレコード数と、第２突合対象情報の決済金額とに基づき、別客ＩＤ１が一致する第１突合対象情報に含まれる商品情報と、第２突合対象情報に含まれるユーザＩＤとを対応付けるか否かを判定している。

また、ここで、ｎ１、ｎ２、ｎ３が全て整数となる解が得られない場合、別客ＩＤ突合部５８０は、ステップＳ１３０５へ進む。

ステップＳ１３０３の結果として、整数解が得られない場合には、別客ＩＤ突合部５８０は、第１突合対象情報データベース１２０から、値が最も小さい別客ＩＤ２が付与された第１突合対象情報を抽出する（ステップＳ１３０５）。

図１４（Ｃ）の第１突合対象情報１２１−Ｂは、図１３のステップＳ１３０５で抽出された第１突合対象情報の一例を示す。ここでは、値が最も小さい別客ＩＤ２が「５００」である場合を示している。

続いて、別客ＩＤ突合部５８０は、ステップＳ１３０５で抽出した第１突合対象情報１２１−Ｂのうち、別客ＩＤ１の合計が最も小さい値となる第１突合対象情報を抽出する（ステップＳ１３０６）。

図１４（Ｄ）の第１突合対象情報１２１−Ｃは、図１３のステップＳ１３０６で抽出された第１突合対象情報の一例を示す。

第１突合対象情報１２１−Ｂには、別客ＩＤ１「１００」、「１０１」、「１０２」が含まれる。このなかで、別客ＩＤ１の合計が最も小さい値となる組み合わせは、別客ＩＤ１「１００」、「１０１」である。

よって、別客ＩＤ突合部５８０は、ステップＳ１３０６において、第１突合対象情報１２１−Ｂから、別客ＩＤ１「１００」の第１突合対象情報と、別客ＩＤ１「１０１」の第１突合対象情報とを抽出する。

続いて、別客ＩＤ突合部５８０は、ステップＳ１３０６で抽出した第１突合対象情報１２１−Ｃのうち、商品ＩＤ取得日時が示す最も遅い時刻から５分以内に取得された第２突合対象情報を抽出し（ステップＳ１３０７）、ステップＳ１３０８へ進む。

図１４（Ｅ）の第２突合対象情報１３１−Ｂは、図１３のステップＳ１３０７で抽出された第２突合対象情報の一例を示す。

別客ＩＤ突合部５８０は、第１突合対象情報１２１−Ｃのうち、商品ＩＤ取得日時が最も遅い時刻を示すレコードＲ２を特定し、レコードＲ２の商品ＩＤ取得日時から５分以内に取得された第２突合対象情報１３１−Ｂを、ステップＳ１３０７で抽出する。

続いて、別客ＩＤ突合部５８０は、ステップＳ１３０７で抽出した第２突合対象情報１３１−Ｂのうち、決済完了日時が早い順に、決済金額と購入個数の組み合わせとを算出する（ステップＳ１３０８）。

続いて、別客ＩＤ突合部５８０は、ステップＳ１３０８の結果として、整数解が得られたか否かを判定する（ステップＳ１３０９）。ステップＳ１３０９において、整数解が得られた場合には、図１２のステップＳ１２０８へ進む。

具体的には、別客ＩＤ突合部５８０は、図１４（Ｄ）に示す第１突合対象情報１２１−Ｃと、図１４（Ｅ）に示す第２突合対象情報１３１−Ｂを抽出すると、ステップＳ１３０８において、決済完了日時が早い第２突合対象情報１３１−Ｂから順に、購入個数の組み合わせを算出する。

例えば、第２突合対象情報１３１−Ｂにおいて、最も決済完了日時が早い決済金額は、５００円である。また、第１突合対象情報１２１−Ｃでは、５種類の商品の商品金額が含まれる。そこで、別客ＩＤ突合部５８０は、５種類の商品それぞれの購入個数をｎ１、ｎ２、ｎ３、ｎ４、ｎ５とし、以下の式（２）を満たし、且つ、ｎ１、ｎ２、ｎ３、ｎ４、ｎ５が整数となる解を求める。

ｎ１×１００＋ｎ２×２００＋ｎ３×５０＋ｎ４×１２０＋ｎ５×３００
＝５００ 式（２）
ここで、ｎ１、ｎ２、ｎ３、ｎ４、ｎ５が全て整数となる解が得られた場合には、別客ＩＤ突合部５８０は、図１２のステップＳ１２０８へ進む。

つまり、本実施形態の別客ＩＤ突合部５８０は、別客ＩＤ２が一致する第１突合対象情報から、別客ＩＤ１が特定の条件を満たすように抽出された第１突合対象情報の数と、第２突合対象情報の決済金額とに基づき、別客ＩＤ２が一致する第１突合対象情報に含まれる商品情報と、第２突合対象情報に含まれるユーザＩＤとを対応付けるか否かを判定している。

別客ＩＤ突合部５８０は、ｎ１、ｎ２、ｎ３、ｎ４、ｎ５が全て整数となる解が得られない場合、ステップＳ１３１０へ進む。

ステップＳ１３０９において、整数解がでない場合、別客ＩＤ突合部５８０は、突合済み情報データベース１４０に格納された突合済み情報を、商品ＩＤ取得日時の順にソートする（ステップＳ１３１０）。

続いて、別客ＩＤ突合部５８０は、ユーザＩＤが不明とされた突合済み情報と、この突合済み情報の前後の、ユーザＩＤが判明している突合済み情報と、を抽出する（ステップＳ１３１１）。

図１５（Ａ）は、ソート後の突合済み情報データベース１４０の一例を示す。

本実施形態の突合済み情報データベース１４０は、情報の項目として、商品ＩＤ、正目品名、商品金額、商品ＩＤ取得日時、ユーザＩＤを含む。尚、突合済み情報データベース１４０が有する情報の項目は、図１５（Ａ）の例に限定されない。突合済み情報データベース１４０は、少なくとも商品情報とユーザＩＤとが含まれれば良く、図１５（Ａ）に示す項目以外の項目が含まれていてもよい。

別客ＩＤ突合部５８０は、ステップＳ１３１１において、突合済み情報データベース１４０から、項目「ユーザＩＤ」の値が不明であり、且つ、前後のユーザＩＤが決まっている突合済み情報を抽出する。

図１５（Ａ）の例では、レコードＲ３、Ｒ４のユーザＩＤが不明であり、レコードＲ３の前のユーザＩＤと、レコードＲ４の後のレコードＲ６のユーザＩＤとが決まっている。

よって、別客ＩＤ突合部５８０は、突合済み情報データベース１４０から、レコードＲ３、Ｒ４、Ｒ５、Ｒ６を抽出する。

続いて、別客ＩＤ突合部５８０は、第２突合対象情報データベース１３０を決済完了日時の順にソートする（ステップＳ１３１２）。

図１５（Ｂ）の第２突合対象情報１３１−Ｃは、決済完了日時の順にソートされた第２突合対象情報の例を示している。

図１５（Ｂ）の第２突合対象情報１３１−Ｃは、決済完了日時と、レコードＲ３、Ｒ４、Ｒ５、Ｒ６の商品ＩＤ取得日時との差が所定の時間内となる第２突合対象情報を示している。

尚、ここでの所定の時間とは、予めサーバ１００の管理者等によって設定されていても良い。ここでは、レコードＲ３、Ｒ４、Ｒ５、Ｒ６と対応付ける第２突合対象情報を特定することを目的としている。したがって、ここでの所定の時間内は、商品ＩＤの読み取りから決済の完了までにかかる時間の上限を５分間とみなし、５分以内としている。

続いて、別客ＩＤ突合部５８０は、抽出した突合済み情報と、ソートした第２突合対象情報とを照合し、ユーザ情報が不明とされた突合済み情報と対応する第２突合対象情報を特定し、特定した第２突合対象情報からユーザＩＤを抽出する（ステップＳ１３１３）。

図１５（Ｂ）の第２突合対象情報１３１−Ｃにおいて、レコードＲ７のユーザＩＤは、突合済み情報データベース１４０のレコードＲ５のユーザＩＤと一致しており、レコードＲ７の決済完了日時は、レコードＲ５の商品ＩＤ取得日時から所定の時間（５分）以内である。したがって、レコードＲ７のユーザＩＤ「１０００１０」は、突合済み情報データベース１４０において、レコードＲ５と対応付けられている。

同様に、第２突合対象情報１３１−Ｃにおいて、レコードＲ８のユーザＩＤは、突合済み情報データベース１４０のレコードＲ６のユーザＩＤと一致しており、レコードＲ８の決済完了日時は、レコードＲ６の商品ＩＤ取得日時から５分以内である。したがって、レコードＲ８は、レコードＲ６と対応付けられた第２突合対象情報である。

これらの関係から、突合済み情報データベース１４０のレコードＲ３、Ｒ４は、第２突合対象情報１３１−ＣにおけるレコードＲ７とレコードＲ９の間の時間帯に取得されたレコードＲ８に対応する可能性が高い。

図１５の例では、第２突合対象情報１３１−ＣにおけるレコードＲ７とレコードＲ８の間に取得された第２突合対象情報は、レコードＲ９である。したがって、別客ＩＤ突合部５８０は、ステップＳ１３１３において、レコードＲ９のユーザＩＤ「５１２２３」を抽出する。

続いて、別客ＩＤ突合部５８０は、ステップＳ１３１３で抽出したユーザＩＤが１つであるか否かを判定する（ステップＳ１３１４）。ステップＳ１３１４において、抽出されたユーザＩＤが１つでない場合、別客ＩＤ突合部５８０は処理を終了する。

ステップＳ１３１４において、抽出されたユーザＩＤが１つである場合、別客ＩＤ突合部５８０は、このユーザＩＤを、ユーザＩＤが不明とされていた突合済み情報のユーザＩＤとして、突合済み情報データベース１４０に格納し（ステップＳ１３１５）、処理を終了する。

図１５の例では、ステップＳ１３１１で抽出されたユーザＩＤは、レコードＲ９のユーザＩＤ「５１２２３」のみである。このため、レコードＲ９に含まれるユーザＩＤによって特定されるユーザが、突合済み情報データベース１４０のレコードＲ３、Ｒ４に含まれる商品情報が示す商品を購入したことになる。

よって、別客ＩＤ突合部５８０は、突合済み情報データベース１４０のレコードＲ３、Ｒ４において、不明とされていたユーザＩＤを、第２突合対象情報１３１−ＣのレコードＲ９のユーザＩＤ「５１２２３」とする。

図１５（Ｃ）の突合済み情報データベース１４０−Ａは、ユーザＩＤが不明とされていたレコードＲ３、Ｒ４に、第２突合対象情報１３１−ＣのレコードＲ９のユーザＩＤ「５１２２３」が対応付けられた状態を示している。

このように、本実施形態では、ユーザＩＤが不明な状態で突合済み情報データベース１４０に商品情報が格納された場合でも、蓄積された決済情報に基づき、ユーザＩＤを対応付けることができる。

以上のように、本実施形態では、電子決済サービスの提供者と、商品を販売する店舗と、のそれぞれで別々に管理されている、電子決済サービスのユーザＩＤと、商品情報とを対応付けることができる。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

２０ 商品登録システム
１００ サーバ
１１０ 対応付けデータベース
１２０ 第１突合対象情報データベース
１３０ 第２突合対象情報データベース
１４０ 突合済み情報データベース
１５０ 情報処理部
２００ 商品登録装置
２１０ 商品ＩＤ読み取り装置
２２０ 決済用読み取り装置
３００ 情報処理システム
４００ 商品管理データベース
５００ 決済サーバ
５１０ 商品管理情報取得部
５２０ 決済情報取得部
５３０ 情報付加部
５４０ 突合処理部
５５０ 対応付け部
５６０ 情報抽出部
５７０ 情報判定部
５８０ 別客ＩＤ突合部
５９０ 購入履歴判定部

Claims (11)

1. コンピュータによる情報処理方法であって、前記コンピュータが、
   電子決済サービスを用いて商品を購入した購入者の前記商品の購入時の決済情報と、前記商品を特定する情報と対応付けられた商品情報を含む商品管理情報とを取得し、
   前記決済情報と前記商品管理情報とのそれぞれに含まれる、前記商品の購入日時を示す情報と、前記商品の購入金額を示す情報と、前記商品が購入された位置を特定する情報と、に基づき、前記決済情報に含まれる購入者を特定する情報と、前記商品管理情報に含まれる商品情報と、を対応付ける、情報処理方法。
2. 前記コンピュータが、
   前記購入者を特定する情報と、前記商品管理情報に含まれる商品情報と、を対応付けた突合済み情報を記憶部に格納する、請求項１記載の情報処理方法。
3. 前記コンピュータが、
   前記商品を特定する情報を取得する直前に取得した他の商品を特定する情報の取得日時から、前記商品を特定する情報の取得日時までの間隔に応じて、前記商品を特定する情報を含む商品管理情報に、
   前記商品を特定する情報で特定される商品と、前記他の商品を特定する情報で特定される商品とが、同一の購入者によって購入されたか否かを判定するための第１付加情報と、
   前記商品を特定する情報で特定される商品と、前記他の商品を特定する情報で特定される商品とが、別々の購入者によって購入されたか否かを判定するための第２付加情報と、を付与する、請求項２記載の情報処理方法。
4. 前記コンピュータが、
   前記間隔が第１の閾値以下である場合に、前記商品管理情報に、前記他の商品を特定する情報を含む他の商品管理情報と同じ第１付加情報を付与し、
   前記間隔が、前記第１の閾値より値の大きい第２の閾値以下である場合に、前記商品管理情報に、前記他の商品管理情報と同じ第２付加情報を付与する、請求項３記載の情報処理方法。
5. 前記コンピュータが、
   前記位置を特定する情報が一致し、且つ、所定の時間内に取得された商品管理情報と、前記決済情報とを抽出し、
   前記商品管理情報に、前記商品の個数と、前記商品の単価とが含まれる場合に、
   前記商品管理情報に基づき算出された購入金額と一致する決済情報を特定し、
   特定された決済情報が示す購入者と、前記商品管理情報に含まれる商品情報と、を対応付ける、請求項４記載の情報処理方法。
6. 前記コンピュータが、
   前記商品管理情報に、前記商品の個数と、前記商品の単価とが含まれない場合に、
   前記第１付加情報が一致する前記商品管理情報を抽出し、抽出された前記商品管理情報の数と、前記決済情報に含まれる前記商品の購入金額を示す情報と、に基づき、前記抽出された前記商品管理情報に含まれる商品情報と、抽出された前記決済情報が示す購入者とを対応付くか否かを判定する、請求項５記載の情報処理方法。
7. 前記コンピュータが、
   前記第１付加情報が一致する前記商品管理情報に含まれる商品情報と、抽出された前記決済情報が示す購入者とが対応付かないと判定した場合に、
   前記第２付加情報が一致する前記商品管理情報から、前記第１付加情報が特定の条件を満たす商品管理情報を抽出し、抽出された商品管理情報の数と、前記決済情報に含まれる前記商品の購入金額を示す情報と、に基づき、前記抽出された前記商品管理情報に含まれる商品情報と、抽出された前記決済情報が示す購入者とを対応付くか否かを判定する、請求項６記載の情報処理方法。
8. 前記コンピュータが、
   前記商品管理情報に含まれる商品情報が、前記決済情報が示す購入者を対応付かないと判定された場合に、前記記憶部を参照し、
   前記商品管理情報に含まれる商品情報と一致する商品情報と対応付けられた購入者が存在する場合に、前記商品管理情報に含まれる商品情報と該購入者とを対応付ける、請求項７記載の情報処理方法。
9. 前記コンピュータが、
   前記記憶部に格納された前記突合済み情報を、前記突合済み情報に含まれる商品情報が取得された日時の順にソートし、
   商品情報に購入者が対応付けられていない突合済み情報が存在する場合に、該突合済み情報に含まれる商品情報が取得された日時を含む所定の時間帯に取得された決済情報を抽出し、
   前記商品情報に購入者が対応付けられていない突合済み情報の前後の突合済み情報において、商品情報と対応付けられた購入者と、抽出された決済情報に含まれる購入者とを照合して、購入者が対応付けられていない商品情報と対応付ける購入者を特定する、請求項８記載の情報処理方法。
10. 電子決済サービスを用いて商品を購入した購入者の前記商品の購入時の決済情報と、前記商品を特定する情報と対応付けられた商品情報を含む商品管理情報とを取得する取得部と、
    前記決済情報と前記商品管理情報とのそれぞれに含まれる、前記商品の購入日時を示す情報と、前記商品の購入金額を示す情報と、前記商品が購入された位置を特定する情報と、に基づき、前記決済情報に含まれる購入者を特定する情報と、前記商品管理情報に含まれる商品情報と、を対応付ける対応付け部と、を有する情報処理装置。
11. 電子決済サービスを用いて商品を購入した購入者の前記商品の購入時の決済情報と、前記商品を特定する情報と対応付けられた商品情報を含む商品管理情報とを取得する処理と、
    前記決済情報と前記商品管理情報とのそれぞれに含まれる、前記商品の購入日時を示す情報と、前記商品の購入金額を示す情報と、前記商品が購入された位置を特定する情報と、に基づき、前記決済情報に含まれる購入者を特定する情報と、前記商品管理情報に含まれる前記商品の商品情報と、を対応付ける処理と、をコンピュータに実行させる情報処理プログラム。

Images