IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ BHI株式会社の特許一覧

特開2024-25225情報処理システム、情報処理方法及びプログラム
<>
  • 特開-情報処理システム、情報処理方法及びプログラム 図1
  • 特開-情報処理システム、情報処理方法及びプログラム 図2
  • 特開-情報処理システム、情報処理方法及びプログラム 図3
  • 特開-情報処理システム、情報処理方法及びプログラム 図4
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024025225
(43)【公開日】2024-02-26
(54)【発明の名称】情報処理システム、情報処理方法及びプログラム
(51)【国際特許分類】
   G06Q 30/0207 20230101AFI20240216BHJP
【FI】
G06Q30/02 350
【審査請求】有
【請求項の数】5
【出願形態】OL
(21)【出願番号】P 2022128491
(22)【出願日】2022-08-10
(11)【特許番号】
(45)【特許公報発行日】2023-04-13
(71)【出願人】
【識別番号】515239711
【氏名又は名称】BHI株式会社
(74)【代理人】
【識別番号】110002790
【氏名又は名称】One ip弁理士法人
(72)【発明者】
【氏名】日昔 靖裕
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049BB07
(57)【要約】
【課題】商品やサービスの提案による効果に応じたリワードを与えることができるようにする。
【解決手段】情報処理システムであって、ユーザが使用するユーザ端末にインストールされるアプリの所定期間における起動回数を取得するアクティブ状況取得部と、起動回数に応じたタイミングでユーザに宛てた電子メールを取得する電子メール取得部と、電子メールを解析して商品又はサービスに係る取引情報を抽出する抽出部と、取引情報に応じてユーザにリワードを付与するリワード付与部と、を備え、電子メール取得部は、所定期間における起動回数が所定数未満であるユーザについては、起動回数が所定数以上であるユーザよりも頻度低く電子メールを取得すること、を特徴とする。
【選択図】図1
【特許請求の範囲】
【請求項1】
ユーザが使用するユーザ端末にインストールされるアプリの所定期間における起動回数を取得するアクティブ状況取得部と、
前記起動回数に応じたタイミングでユーザに宛てた電子メールを取得する電子メール取得部と、
前記電子メールを解析して商品又はサービスに係る取引情報を抽出する抽出部と、
前記取引情報に応じて前記ユーザにリワードを付与するリワード付与部と、
を備え、
前記電子メール取得部は、前記所定期間における前記起動回数が所定数未満である前記ユーザについては、前記起動回数が前記所定数以上である前記ユーザよりも頻度低く前記電子メールを取得すること、
を特徴とする情報処理システム。
【請求項2】
請求項1に記載の情報処理システムであって、
前記電子メール取得部は、前記所定期間における前記起動回数が前記所定数未満である前記ユーザについては、前記電子メールを取得しないこと、
を特徴とする情報処理システム。
【請求項3】
請求項1に記載の情報処理システムであって、
前記ユーザが使用するユーザ端末にインストールされるアプリに情報を送信する情報送信部をさらに備え、
前記アクティブ状況取得部は、前記ユーザが前記所定期間に前記アプリにおいて前記情報を閲覧した閲覧頻度を前記使用頻度として取得すること、
を特徴とする情報処理システム。
【請求項4】
ユーザが使用するユーザ端末にインストールされるアプリの所定期間における起動回数を取得するステップと、
前記起動回数に応じたタイミングでユーザに宛てた電子メールを取得するステップと、
前記電子メールを解析して商品又はサービスに係る取引情報を抽出するステップと、
前記取引情報に応じて前記ユーザにリワードを付与するステップと、
をコンピュータが実行し、
前記電子メールを取得するステップにおいて、前記コンピュータは、前記所定期間における前記起動回数が所定数未満である前記ユーザについては、前記起動回数が前記所定数以上である前記ユーザよりも頻度低く前記電子メールを取得すること、
を特徴とする情報処理方法。
【請求項5】
ユーザが使用するユーザ端末にインストールされるアプリの所定期間における起動回数を取得するステップと、
前記起動回数に応じたタイミングでユーザに宛てた電子メールを取得するステップと、
前記電子メールを解析して商品又はサービスに係る取引情報を抽出するステップと、
前記取引情報に応じて前記ユーザにリワードを付与するステップと、
をコンピュータに実行させ、
前記電子メールを取得するステップにおいて、前記コンピュータに、前記所定期間における前記起動回数が所定数未満である前記ユーザについては、前記起動回数が前記所定数以上である前記ユーザよりも頻度低く前記電子メールを取得させること、
を特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理システム、情報処理方法及びプログラムに関する。
【背景技術】
【0002】
広告を閲覧したユーザに対してリワードを与えることが行われている(特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特表2015-520903号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、特許文献1に記載のシステムでは、広告に応じた消費活動が行われたかどうかまでは分からない。
【0005】
本発明はこのような背景を鑑みてなされたものであり、商品やサービスの提案による効果に応じたリワードを与えることができる技術を提供することを目的とする。
【課題を解決するための手段】
【0006】
上記課題を解決するための本発明の主たる発明は、情報処理システムであって、ユーザが使用するユーザ端末にインストールされるアプリの所定期間における起動回数を取得するアクティブ状況取得部と、前記起動回数に応じたタイミングでユーザに宛てた電子メールを取得する電子メール取得部と、前記電子メールを解析して商品又はサービスに係る取引情報を抽出する抽出部と、前記取引情報に応じて前記ユーザにリワードを付与するリワード付与部と、を備え、前記電子メール取得部は、前記所定期間における前記起動回数が所定数未満である前記ユーザについては、前記起動回数が前記所定数以上である前記ユーザよりも頻度低く前記電子メールを取得すること、を特徴とする。
【0007】
その他本願が開示する課題やその解決方法については、発明の実施形態の欄及び図面により明らかにされる。
【発明の効果】
【0008】
本発明によれば、商品やサービスの提案による効果に応じたリワードを与えることができる。
【図面の簡単な説明】
【0009】
図1】本発明の一実施形態に係るレコメンドシステムの全体構成例を示す図である。
図2】サーバ装置20のハードウェア構成例を示す図である。
図3】サーバ装置20のソフトウェア構成例を示す図である。
図4】本実施形態のレコメンドシステムの動作を説明する図である。
【発明を実施するための形態】
【0010】
<発明の概要>
本発明の実施形態の内容を列記して説明する。本発明は、たとえば、以下のような構成を備える。
[項目1]
ユーザが使用するユーザ端末にインストールされるアプリの所定期間における起動回数を取得するアクティブ状況取得部と、
前記起動回数に応じたタイミングでユーザに宛てた電子メールを取得する電子メール取得部と、
前記電子メールを解析して商品又はサービスに係る取引情報を抽出する抽出部と、
前記取引情報に応じて前記ユーザにリワードを付与するリワード付与部と、
を備え、
前記電子メール取得部は、前記所定期間における前記起動回数が所定数未満である前記ユーザについては、前記起動回数が前記所定数以上である前記ユーザよりも頻度低く前記電子メールを取得すること、
を特徴とする情報処理システム。
[項目2]
項目1に記載の情報処理システムであって、
前記電子メール取得部は、前記所定期間における前記起動回数が前記所定数未満である前記ユーザについては、前記電子メールを取得しないこと、
を特徴とする情報処理システム。
[項目3]
項目1に記載の情報処理システムであって、
前記ユーザが使用するユーザ端末にインストールされるアプリに情報を送信する情報送信部をさらに備え、
前記アクティブ状況取得部は、前記ユーザが前記所定期間に前記アプリにおいて前記情報を閲覧した閲覧頻度を前記使用頻度として取得すること、
を特徴とする情報処理システム。
[項目4]
ユーザが使用するユーザ端末にインストールされるアプリの所定期間における起動回数を取得するステップと、
前記起動回数に応じたタイミングでユーザに宛てた電子メールを取得するステップと、
前記電子メールを解析して商品又はサービスに係る取引情報を抽出するステップと、
前記取引情報に応じて前記ユーザにリワードを付与するステップと、
をコンピュータが実行し、
前記電子メールを取得するステップにおいて、前記コンピュータは、前記所定期間における前記起動回数が所定数未満である前記ユーザについては、前記起動回数が前記所定数以上である前記ユーザよりも頻度低く前記電子メールを取得すること、
を特徴とする情報処理方法。
[項目5]
ユーザが使用するユーザ端末にインストールされるアプリの所定期間における起動回数を取得するステップと、
前記起動回数に応じたタイミングでユーザに宛てた電子メールを取得するステップと、
前記電子メールを解析して商品又はサービスに係る取引情報を抽出するステップと、
前記取引情報に応じて前記ユーザにリワードを付与するステップと、
をコンピュータに実行させ、
前記電子メールを取得するステップにおいて、前記コンピュータに、前記所定期間における前記起動回数が所定数未満である前記ユーザについては、前記起動回数が前記所定数以上である前記ユーザよりも頻度低く前記電子メールを取得させること、
を特徴とするプログラム。
【0011】
<システム概要>
以下、本発明の一実施形態に係るレコメンドシステムについて説明する。本実施形態のレコメンドシステムは、ユーザに対して商品(サービスを含む。以下同じ。)を提案し、商品の購入を訴求する。レコメンドシステムは、例えば、ディスプレイ広告やネイティブ広告として商品を提案するようにしてもよいし、商品情報の閲覧時に関連商品を提案するようにしてもよいし、検索連動広告として商品を提案するようにしてもよいし、旅程に関するカレンダーの設定時に当該旅程に必要な商品を提案するようにしてもよいし、TODOの設定時に、当該TODO項目に関連する商品を提案するようにしてもよい。すなわち、本実施形態のレコメンドシステムは、ユーザに対して商品の購入を訴求するものであればどのような形態のものであってもよい。
【0012】
図1は、本発明の一実施形態に係るレコメンドシステムの全体構成例を示す図である。本実施形態のレコメンドシステムは、サーバ装置20を含んで構成される。サーバ装置20は、ユーザ端末10、外部サーバ41及び電子メールサーバ42のそれぞれと、通信ネットワーク30を介して通信可能に接続される。通信ネットワーク30は、たとえばインターネットであり、公衆電話回線網や携帯電話回線網、無線通信路、イーサネット(登録商標)などにより構築される。
【0013】
ユーザ端末10は、商品の消費者であるユーザが操作するコンピュータである。ユーザ端末10は、例えば、スマートフォンやタブレットコンピュータ、パーソナルコンピュータなどである。ユーザ端末10は、例えば、Webブラウザの機能を備え、ユーザはユーザ端末10においてWebブラウザを操作することにより、オンラインショッピングにより商品を購入したり、有料コンテンツを閲覧したりすることができる。
【0014】
外部サーバ41は、商品の販売に関連するコンピュータである。外部サーバ41は、例えば、ECサイトを運営するWebサーバとすることができる。ユーザは、ユーザ端末10を利用して外部サーバ41にアクセスして商品を購入することができる。外部サーバ41は、例えば、商品を販売するオンラインストアを提供するサーバであってもよいし、動画や書籍などのコンテンツを提供するコンテンツ配信サービスのサーバであってもよいし、旅行サービスを提供する旅行会社のサーバであってもよい。すなわち、外部サーバ41は、商品をユーザに販売するシステムであればよい。外部サーバ41は、ユーザが商品を購入した場合には、購入した商品に関する情報を電子メール(チャットサービスにおけるメッセージを含む。以下同じ。)にてユーザに送信する。これは、一般的なECサイトなどにおいても行われていることである。
【0015】
電子メールサーバ42は、電子メールを管理するコンピュータである。電子メールサーバ42は、いわゆるMRA(Mail Retrieval Agent)であり、メールボックスを備え、例えば、IMAPやPOPなどのプロトコルによりメールボックスに配送されている電子メールを提供することができる。
【0016】
サーバ装置20は、ユーザに対する商品のレコメンドを行うとともに、レコメンドに応じて商品が購入された場合に、ユーザに対してリワードを付与するコンピュータである。サーバ装置20は、例えば、ユーザ端末10で動作するソフトウェア(アプリ)に対して商品を提案し、ユーザ端末10が実行するアプリ上でユーザに対して商品が提案されるようにしてもよいし、ECサイトなどの外部サーバ41からのリクエストに応じて商品を提案し、ユーザはユーザ端末10が実行するWebブラウザによりECサイトの画面上で提案された商品を閲覧するようにしてもよい。サーバ装置20は、例えばワークステーションやパーソナルコンピュータのような汎用コンピュータとしてもよいし、あるいはクラウド・コンピューティングによって論理的に実現されてもよい。
【0017】
<サーバ装置20の構成>
図2は、サーバ装置20のハードウェア構成例を示す図である。なお、図示された構成は一例であり、これ以外の構成を有していてもよい。サーバ装置20は、CPU201、メモリ202、記憶装置203、通信インタフェース204、入力装置205、出力装置206を備える。記憶装置203は、各種のデータやプログラムを記憶する、例えばハードディスクドライブやソリッドステートドライブ、フラッシュメモリなどである。通信インタフェース204は、通信ネットワーク30に接続するためのインタフェースであり、例えばイーサネット(登録商標)に接続するためのアダプタ、公衆電話回線網に接続するためのモデム、無線通信を行うための無線通信機、シリアル通信のためのUSB(Universal Serial Bus)コネクタやRS232Cコネクタなどである。入力装置205は、データを入力する、例えばキーボードやマウス、タッチパネル、ボタン、マイクロフォンなどである。出力装置206は、データを出力する、例えばディスプレイやプリンタ、スピーカなどである。なお、後述するサーバ装置20が備える各機能部は、CPU201が記憶装置203に記憶されているプログラムをメモリ202に読み出して実行することにより実現され、サーバ装置20が備える各記憶部は、メモリ202及び記憶装置203が提供する記憶領域の一部として実現される。
【0018】
図3は、サーバ装置20のソフトウェア構成例を示す図である。サーバ装置20は、商品提案部210、電子メール取得部211、購入データ抽出部212、リワード付与部213、リワード記憶部231、商品情報記憶部232、提案履歴記憶部233、購入データ記憶部234を備える。
【0019】
リワード記憶部231は、商品ごとに、ユーザに付与するリワードを管理する。リワード記憶部231は、例えば、商品の広告主によるキャンペーンごとに、どの商品にどのようなリワードを与えるかを示す情報(以下、リワード情報という。)を記憶する。リワード記憶部231が記憶するリワード情報には、キャンペーンを特定するリワードIDと、商品を特定する商品IDとに対応付けて、商品の提案に係る条件と、付与するリワードとが含まれる。条件は、例えば、ターゲティング広告におけるセグメントを特定するための情報(例えば、ユーザのデモグラフィック情報の指定など)であってもよいし、特定の商品を購入したユーザを特定するための情報(商品を特定する情報)であってもよい。また、条件には、キャンペーンの期間(開始日時と終了日時)を設定するようにしてもよい。付与するリワードは、ポイントや仮想通貨などの交換価値を有するものであってもよいし、割引券などのクーポンであってもよいし、実体的なグッズなどのプレゼントであってもよいし、デジタルコンテンツなどであってもよい。また、リワードには、例えば、ポイントやプレゼントの個数などを計算するための計算式を設定し、リワードを付与するときに、付与するポイント数やプレゼントの個数を動的に計算するようにしてもよい。また、リワードには、他にもリワードを決定するルールを設定するようにし、リワードを付与する際にルールに従ってリワードを決定するようにしてもよい。
【0020】
商品情報記憶部232は、商品についての情報(以下、商品情報という。)を記憶する。商品情報には、商品を特定する商品IDに対応付けて、タイトル及び商品説明を含めることができる。タイトルには商品の名称を設定してもよいし、商品を提案する際のキャッチコピーなどを設定してもよい。商品説明には、自由記述のテキストデータや画像データ、動画データなどを含めることができる。
【0021】
商品提案部210は、ユーザに対して商品又はサービスを提案する。商品提案部210は、例えば、リワード記憶部231に登録されているリワード情報のうち条件が充足されているものを取得し、取得したリワード情報に含まれる商品IDが示す商品情報を商品情報記憶部232から取得してユーザに提案する。商品提案部210は、例えば、ユーザ端末10に対して商品情報を送信するようにすることができる。商品提案部210は、例えば、リワード情報にユーザの属性に対する条件が設定されている場合には、ユーザの属性(ユーザごとの属性を管理するユーザデータベースを設けるようにしてもよいし、ユーザの属性を管理している外部サーバに問い合わせるようにしてもよい。)を取得して、取得した属性が条件を満たすリワード情報を検索することができる。また、リワード情報にキャンペーン期間が設定されている場合には、現在の日時がキャンペーン期間に含まれているものを検索することができる。また、これらの複数の条件をAND又はOR条件として検索するようにしてもよい。
【0022】
提案履歴記憶部233は、ユーザに対して提案した商品を記憶する。提案履歴記憶部233が記録する提案履歴には、提案先となったユーザを示すユーザID、提案した商品を示す商品ID、リワード情報を示すリワードID、提案した日時を対応付けて含めることができる。また、本実施形態では、当該提案履歴に対応する購買活動が行われたことに対するリワードが付与されたか否かを示すリワードフラグも提案履歴に含まれるものとする。商品提案部210は、商品を提案したときに、提案したユーザを示すユーザID、提案した商品を示す商品ID、リワード情報を示すリワードID、提案した日時、「偽」のリワードフラグを設定した提案履歴を作成して提案履歴記憶部233に追加することができる。
【0023】
電子メール取得部211は、ユーザに宛てた電子メールを取得する。電子メール取得部211は、電子メールサーバ42からユーザ宛の電子メールを取得することができる。電子メール取得部211は、商品の販売者からユーザに宛てた電子メールのみを取得するようにしてもよい。例えば、電子メール取得部211は、機械学習により学習した、電子メールの内容がプライベートな内容であるか、購買活動に関するものであるかを分類する分類器を用いて、電子メールサーバ42のメールボックスに格納されている電子メールのうち、購買活動に関するもののみを取得するようにすることができる。
【0024】
購入データ抽出部212は、電子メールを解析して商品又はサービスに係る購入データを抽出する。購入データ抽出部212は、例えば、予め用意してある電子メールのフォーマットを解析するためのルールを適用することにより、電子メールから購入データを取得することができる。ルールには、例えば、正規表現などによりどのような情報がどのような形式で記述されているかを特定しておくことができる。また、ルールは、商品の販売者(ECサイトや直販サイトなど)ごとに準備するようにしてもよい。購入データには、少なくとも商品を特定する情報(例えば、メーカー名や商品名など)が含まれるものする。購入データ抽出部212は、抽出した購入データを購入データ記憶部234に登録する。
【0025】
購入データ記憶部234は、購入データを記憶する。購入データには、ユーザを示すユーザID、ユーザが商品を購入した日時、購入した商品を示す商品ID、購入数、購入金額などを含めることができる。これらは、ECサイトなどの販売者が購入者であるユーザに対して確認のための情報として送信した電子メールから取得することができる。購入データ抽出部212は、電子メールからこれらの項目を抽出して、購入データとして購入データ記憶部234に登録することができる。また、購入データにも、リワードフラグを含めることができる。購入データの登録時にはリワードフラグは「偽」とすることができる。
【0026】
リワード付与部213は、電子メールから提案した商品に係る購入データを抽出できたことに応じてユーザにリワードを付与する。リワード付与部213は、例えば、購入データ抽出部212が購入データの抽出に成功したときに、抽出した購入データに含まれる商品と、電子メールの宛先のユーザとに対応する提案履歴(リワードフラグが「偽」のもの)が提案履歴記憶部233に登録されていた場合に、ユーザにリワードを行うことができる。リワード付与部213は、ユーザにリワードを行った後、購入データ及び提案履歴のリワードフラグには「真」を設定することができる。
【0027】
リワード付与部213は、抽出された購入データの商品に対応するリワード情報に応じて付与するリワードの内容(種類や量)を決定することができる。リワード付与部213は、抽出した購入データがリワード情報に含まれる条件を満たす場合に、当該リワード情報に設定されているリワード(又はリワード情報に基づいて決定されるリワード)をユーザに対して付与することができる。
【0028】
リワード付与部213は、リワード情報に依らずにリワードを付与するようにしてもよい。例えば、リワード付与部213は、電子メールから購入データを抽出できたことに応じて同一の又はユーザの属性に応じて異なるリワードをユーザに付与することができる。また、リワード付与部213は、電子メールから抽出された購入データに応じてリワードの種類や数を決定することもできる。例えば、リワード付与部213は、購入データに含まれる商品(購入された商品)の数や金額に応じてリワードを決定することができる。また、リワード付与部213は、購入データ記憶部234に記憶されている当該ユーザの過去の購入データに応じて、付与するリワードの種類や数を変更するようにしてもよい。
【0029】
また、リワード付与部213は、付与するリワードの種類や量を抽選により決定するようにしてもよい。リワード付与部213は、例えば、クーポンやプレゼントなどのリワードを付与するか否かを抽選により決定することができる。また、リワード付与部213は、例えば、付与するポイントの数、付与するプレゼントのレアリティや価値などを抽選により決定することができる。この場合に、リワード付与部213は、例えば、ミニゲームをユーザ端末10で実行させ、ミニゲームの結果に応じて付与するリワードの種類や量を決定するようにしてもよい。
【0030】
<動作>
図4は、本実施形態のレコメンドシステムの動作を説明する図である。
【0031】
サーバ装置20は、ユーザに対して商品をレコメンドし(S301)、レコメンドした商品(レコメンド商品)を記憶しておく(S302)。サーバ装置20は、ユーザ宛の電子メール(例えば、商品を販売する販売者から購入者であるユーザに宛てた電子メール)を電子メールサーバ42から取得し(S303)、取得した電子メールから購入データを抽出する(S304)。抽出に成功した場合(S304:YES)、購入した商品に対応するレコメンド商品を検索し(S305)、レコメンド商品があれば(S306:YES)、ユーザにリワードを付与する(S307)。
【0032】
以上のようにして、ユーザに対して提案した商品が実際に購入したことを、ECサイト等の販売者からユーザに宛てた電子メールから検出し、実際に購入されたことを確認したうえで、ユーザにリワードを付与することができる。
【0033】
以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。
【0034】
例えば、本実施形態では、サーバ装置20により商品のレコメンドが行われるものとしたが、サーバ装置20以外(例えば、外部サーバ41)でレコメンドが行われるようにしてもよい。この場合、サーバ装置20は、レコメンドしたユーザとレコメンドした商品とを含む情報を取得して提案履歴記憶部233に登録できればよい。
【0035】
また、本実施形態では、レコメンドされた商品が購入されたことを示す購入データが含まれる電子メールを受信したことに応じてリワードが付与されるものとしたが、レコメンドがされたか否かを問わず、購入データが含まれる電子メールを受信したことに応じてリワードを付与するようにしてもよい。例えば、電子メール取得部211は、過去の電子メールの全部又は一部(例えば、過去所定年分など)を取得するようにし、購入データ抽出部212が、取得した電子メールから購入データを抽出できたことに応じてリワード付与部213はリワードを付与することができる。この場合、リワード付与部213は、リワード情報に依らず、別のロジックにより付与するリワードの種類や量を決定するようにしてもよい。例えば、リワード付与部213は、どのユーザにも同じポイントやクーポンなどを付与したり、ユーザごとに付与する内容をランダムに変化させたり、ユーザの属性に応じて付与するリワードの種類を決定したりすることができる。また、例えば、リワード付与部213は、購入データを抽出できた電子メールの数、抽出できた購入データの数、抽出できた購入データに含まれていた商品の数(購入個数)、購入データに係る金額の集計値(例えば合計値)などに応じて、発行するポイントの数などリワードの量を決定することができる。
【0036】
また、本実施形態では、購入データを起点として、購入データの抽出に成功し、当該購入データに含まれる商品に対応する提案履歴が存在した場合にリワードを付与するものとしたが、これに限らず、レコメンドや購入データの抽出とは独立してリワードの付与処理を行うこともできる。リワード付与部213は、例えば、提案履歴記憶部233と購入データ記憶部234とに記憶されている提案履歴と購入データとに基づいて、ユーザにリワードを付与することができる。リワード付与部213は、提案履歴記憶部233に記憶されている提案履歴のうち、リワードフラグが「偽」であるものを特定し、特定したリワード情報に含まれるユーザID及び商品IDに対応する購入データを購入データ記憶部234から検索し、当該購入データが見つかった場合に、当該ユーザに対して、リワード情報に設定されているリワードを付与する。リワード付与部213は、リワードを付与した後、特定した提案履歴及び検索した購入データのリワードフラグを「真」に設定することができる。
【0037】
==電子メールの取得頻度==
また、電子メールの取得頻度を調整してもよい。例えば、サーバ装置20は、ユーザの種類を特定するユーザ種類特定部を備えるようにし、電子メール取得部211は、ユーザの種類に応じて新規の電子メールを取得する頻度を変更することができる。
【0038】
(アクティブユーザかどうか=アプリの使用頻度)
例えば、ユーザ種類特定部は、ユーザが使用するユーザ端末にインストールされるアプリの起動頻度を取得し、起動頻度に応じてユーザの種類を特定することができる。例えば、ユーザ種類特定部は、所定期間におけるアプリの起動回数が所定数(例えば1回)以上であるユーザをアクティブユーザとして特定することができる。非アクティブユーザについては、アクティブユーザよりも頻度低く電子メールを取得するようにすることができる。したがって、アプリを起動しないユーザについては、電子メールを取得する処理を行わないようにして、電子メール取得にかかる処理負荷やネットワーク負荷を軽減し、コストを低減することができる。また、非アクティブユーザについては、電子メールを取得しないようにすることもできる。非アクティブユーザについては、次回にアプリが起動されるまで、電子メールを取得しないようにするようにしてもよい。
【0039】
(アプリで情報を見た頻度)
また、サーバ装置20は、ユーザ端末10にインストールされるアプリに情報を送信する情報送信部215をさらに備えることができる。商品提案部210が情報送信部であってもよいし、商品提案部210とは別に情報送信部を設けてもよい。ユーザ種類特定部は、ユーザがアプリにおいて情報を閲覧した閲覧頻度を取得することができ、閲覧頻度に応じて種類を特定することができる。
【0040】
(時間帯ごとの電子メールの数)
また、ユーザ種類特定部は、過去に電子メール取得部が取得した電子メールの数を時間帯ごとに集計し、時間帯ごとの電子メールの数に応じて、時間帯ごとにユーザの種類を特定するようにしてもよい。例えば、取得することのできた電子メールの数の多い時間帯ほど、電子メールの取得頻度を高くすることができる。この場合に、購入データを抽出することのできた電子メールの数だけを集計してもよい。
【0041】
(プレミアムユーザ等の設定)
また、サーバ装置20は、ユーザごとにユーザの種類を記憶する種類記憶部を備えるようにしてもよい。ユーザ種類特定部は、種類記憶部を参照してユーザの種類を特定することができる。例えば、電子メールの特定グループの取得頻度は、他のグループよりも高くなるように設定することができる。種類記憶部には、種類ごとに、ユーザの条件(ユーザを特定するための情報)と、電子メールの取得頻度とを記憶するようにしてもよい。
【0042】
(購入データの数)
また、ユーザ種類特定部は、ユーザごとに購入データの数を集計し、購入データの集計数に応じてユーザの種類を特定するようにしてもよい。すなわち、購入データの数に応じて電子メールの取得頻度を変更することができる。例えば、多くの購入データを抽出することができるほど、電子メールの取得頻度を高くすることができる。また、電子メールから抽出することのできた取引情報に含まれる商品の数に応じて電子メールの取得頻度を設定してもよい。
【0043】
(特定の商品を購入したユーザ)
また、ユーザ種類特定部は、購入データに含まれる商品又はサービスに応じて、ユーザの種類を特定するようにしてもよい。例えば、特定の商品を購入したユーザと、購入しなかったユーザとで電子メールの取得頻度を変更してよい。
【0044】
(全体最適化(ユーザ全員の頻度))
また、サーバ装置20は、複数のユーザについて電子メールを受信した時間帯を特定し、時間帯ごとの複数のユーザの電子メールの数を集計することができる。電子メール取得部211は、時間帯ごとの電子メールの数に応じて頻度を変更することができる。例えば、全体として取得できた電子メールの数が多いほど、取得頻度を高くすることができる。また、時間帯ごとに、電子メールを取得することのできたユーザの数を集計し、電子メールを取得することのできたユーザの数に応じて電子メールの取得頻度を変更することができる。例えば、過去の電子メールを取得することのできたユーザの数が多かった時間帯ほど、電子メールの取得頻度を高くすることができる。
【0045】
(設定)
また、サーバ装置20は、電子メールを取得するタイミングを記憶するタイミング記憶部を備え、電子メール取得部211は、記憶されているタイミングに応じて電子メールを取得するようにしてもよい。この場合、タイミング記憶部は、ユーザごとに又はユーザの種類ごとに、電子メールを取得するタイミングを記憶するようにしてもよい。タイミングは、例えば、何分ごと、何時間ごとに1回というように、定期的に電子メールサーバ42にアクセスするインターバル時間としてもよいし、24時間中の何時にアクセスするかを指定するようにしてもよい。
【0046】
(ロックされたユーザ)
また、サーバ装置20は、電子メールへのアクセスがロックされているか否かに応じて、電子メールサーバ42へのアクセス頻度を変更するようにしてもよい。例えば、サーバ装置20では、電子メール取得部211があるユーザについて電子メールサーバ42へのアクセスに失敗した場合(例えば認証に失敗した場合や、認証に成功してもユーザによる承認が得られるまでアクセスできない場合など)に、当該ユーザについては、ユーザからの承認を得るまで、電子メールサーバ42へのアクセス頻度を減らす(又は無くす)ようにしてもよい。ユーザからの承認は、例えば、ユーザが電子メールサーバ42に対してサーバ装置20からのアクセスを承認する手続を行った後に、電子メールサーバ42から発行されたトークンをサーバ装置20に与えることなどにより行うことができる。
【0047】
(ツールを用いたアクティブ性の判断)
また、ユーザがアクティブなユーザであるか否かを、ユーザ端末10にインストールされたアプリの使用状況を解析するツールから取得するようにしてもよい。この場合に、例えば、アプリの提供者(アプリストアの運用者など)が、アプリの開発者向けに提供しているオンラインツールを、サーバ装置20から制御して、あるいはアプリの提供者が提供するAPIを呼び出すことなどにより、サーバ装置20は、アプリの利用状況を取得することができる。
【符号の説明】
【0048】
10 ユーザ端末
20 サーバ装置
30 外部サーバ
210 商品提案部
211 電子メール取得部
212 購入データ抽出部
213 リワード付与部
231 リワード記憶部
232 商品情報記憶部
233 提案履歴記憶部
234 購入データ記憶部
図1
図2
図3
図4
【手続補正書】
【提出日】2022-12-26
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
ユーザが使用するユーザ端末にインストールされるアプリの所定期間における起動回数を取得するアクティブ状況取得部と、
前記起動回数に応じたタイミングでユーザに宛てた電子メールを取得する電子メール取得部と、
前記電子メールを解析して商品又はサービスに係る取引情報を抽出する抽出部と、
前記取引情報に応じて前記ユーザにリワードを付与するリワード付与部と、
を備え、
前記電子メール取得部は、前記所定期間における前記起動回数が所定数未満である前記ユーザについては、前記起動回数が前記所定数以上である前記ユーザよりも頻度低く前記電子メールを取得すること、
を特徴とする情報処理システム。
【請求項2】
請求項1に記載の情報処理システムであって、
前記電子メール取得部は、前記所定期間における前記起動回数が前記所定数未満である前記ユーザについては、前記電子メールを取得しないこと、
を特徴とする情報処理システム。
【請求項3】
請求項1に記載の情報処理システムであって、
前記ユーザが使用するユーザ端末にインストールされるアプリに情報を送信する情報送信部をさらに備え、
前記アクティブ状況取得部は、前記ユーザが前記所定期間に前記アプリにおいて前記情報を閲覧した閲覧頻度を前記起動回数として取得すること、
を特徴とする情報処理システム。
【請求項4】
ユーザが使用するユーザ端末にインストールされるアプリの所定期間における起動回数を取得するステップと、
前記起動回数に応じたタイミングでユーザに宛てた電子メールを取得するステップと、
前記電子メールを解析して商品又はサービスに係る取引情報を抽出するステップと、
前記取引情報に応じて前記ユーザにリワードを付与するステップと、
をコンピュータが実行し、
前記電子メールを取得するステップにおいて、前記コンピュータは、前記所定期間における前記起動回数が所定数未満である前記ユーザについては、前記起動回数が前記所定数以上である前記ユーザよりも頻度低く前記電子メールを取得すること、
を特徴とする情報処理方法。
【請求項5】
ユーザが使用するユーザ端末にインストールされるアプリの所定期間における起動回数を取得するステップと、
前記起動回数に応じたタイミングでユーザに宛てた電子メールを取得するステップと、
前記電子メールを解析して商品又はサービスに係る取引情報を抽出するステップと、
前記取引情報に応じて前記ユーザにリワードを付与するステップと、
をコンピュータに実行させ、
前記電子メールを取得するステップにおいて、前記コンピュータに、前記所定期間における前記起動回数が所定数未満である前記ユーザについては、前記起動回数が前記所定数以上である前記ユーザよりも頻度低く前記電子メールを取得させること、
を特徴とするプログラム。