(57)【要約】【課題】購入希望者が適切なタイミングで商品等を購入することが可能な情報処理装置を提供する。【解決手段】サーバ１００は、購入側端末１０からの要求に対する、提供側端末２０からの提案を受け付ける通信部１１０と、通信部１１０により受け付けられた提案に係る商品・サービスの購入の推奨度ＰＲを算出する推奨度算出部１２０と、を備える。通信部１１０は、推奨度算出部１２０により算出された推奨度ＰＲを、提案とともに購入側端末１０に送信する。【選択図】図２
2017068407.tif 000002
【特許請求の範囲】
【請求項１】
商品・サービスの購入希望者の購入側端末からの要求に対する、商品・サービスの提供者の提供側端末からの提案を受け付ける受付手段と、
前記受付手段により受け付けられた提案に係る商品・サービスの購入の推奨度を算出する算出手段と、
前記算出手段により算出された推奨度を、前記受付手段により受け付けられた提案とともに前記購入側端末に送信する送信手段と、
を備える情報処理装置。
【請求項２】
前記算出手段は、前記受付手段により新たな提案が受け付けられると前記推奨度を再び算出し、
前記送信手段は、前記算出手段により前記推奨度が再び算出されると、前記算出手段により再び算出された推奨度を、前記受付手段により受け付けられた前記新たな提案とともに前記購入側端末に送信する、
請求項１に記載の情報処理装置。
【請求項３】
前記算出手段は、所定の周期で新たな前記推奨度を算出し、
前記送信手段は、前記算出手段により算出された新たな推奨度を、前記受付手段により受け付けられた提案とともに前記購入側端末に送信する、
請求項１に記載の情報処理装置。
【請求項４】
前記算出手段は、前記受付手段により受け付けられた提案の数、および、前記提供者が前記提供側端末を用いて前記要求を閲覧した数、の少なくとも一方に基づいて、前記推奨度を算出する、
請求項１〜３のいずれか１項に記載の情報処理装置。
【請求項５】
前記算出手段は、前記提案の数が大きいほど、前記推奨度が高くなるように算出する、
請求項４に記載の情報処理装置。
【請求項６】
前記算出手段は、前記閲覧した数が大きいほど、前記推奨度が高くなるように算出する、
請求項４または５に記載の情報処理装置。
【請求項７】
前記購入側端末は、
前記情報処理装置の前記送信手段から送信された推奨度および提案を受信する受信手段と、
前記受信手段により受信された推奨度に応じた態様で、前記提案を提示する提示手段と、
を備える、請求項１〜６のいずれか１項に記載の情報処理装置。
【請求項８】
前記推奨度に対するしきい値を設定する設定手段、をさらに備え、
前記購入側端末の前記提示手段は、前記受信手段により受信された推奨度が前記しきい値以上の場合に、所定の通知処理を実行する、
請求項７に記載の情報処理装置。
【請求項９】
前記送信手段が送信した推奨度と、前記受付手段が受け付けた提案の数と、前記購入希望者が購入した商品・サービスの数と、を記憶する記憶手段、をさらに備え、
前記設定手段は、前記記憶手段に記憶された情報に基づいて、前記受付手段により受け付けられる提案の数に対する前記購入希望者による商品・サービスの購入の数の割合を示すコンバージョン率が所定値以上になると予測される推奨度を、前記しきい値として設定する、
請求項８に記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に関する。
【背景技術】
【０００２】
従来より、購入希望者の要求に対して提供者が商品を提案するための技術が知られている（たとえば下記特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１４−１６４４４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
複数の提供者が存在する場合、購入希望者に対して、複数の提供者から異なるタイミングで商品が提案されることがある。購入希望者としては、提案される複数の商品について比較検討を行ったうえで商品を購入することが好ましい。
【０００５】
しかしながら、購入希望者が、現時点までに提案された商品の中から購入する商品を選択すべきか、それとも、さらに別の商品が提案された後で購入する商品を選択すべきかといった、商品の購入のタイミングを判断することは難しい。
【０００６】
本発明は、上記課題に鑑みてなされたものであり、購入希望者が適切なタイミングで商品等を購入することが可能な情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一態様に係る情報処理装置は、商品・サービスの購入希望者の購入側端末からの要求に対する、商品・サービスの提供者の提供側端末からの提案を受け付ける受付手段と、受付手段により受け付けられた提案に係る商品・サービスの購入の推奨度を算出する算出手段と、算出手段により算出された推奨度を、受付手段により受け付けられた提案とともに購入側端末に送信する送信手段と、を備える。
【０００８】
上記の情報処理装置では、提案に係る商品・サービスの購入の推奨度が算出され、提案とともに購入側端末に送信される。これにより、購入希望者は、購入側端末に送信された推奨度に基づいて、提案に係る商品・サービスを購入すべきか否かを判断することができる。よって、購入希望者が適切なタイミングで商品・サービスを購入することが可能になる。
【０００９】
算出手段は、受付手段により新たな提案が受け付けられると推奨度を再び算出し、送信手段は、算出手段により推奨度が再び算出されると、算出手段により再び算出された推奨度を、受付手段により受け付けられた新たな提案とともに購入側端末に送信してもよい。このように新たな提案が受け付けられたことに応じて推奨度が再び算出されて購入側端末に送信されることによって、購入希望者は、新たな提案をも考慮した推奨度に基づいて、より適切なタイミングで商品・サービスを購入できるようになる。
【００１０】
算出手段は、所定の周期で新たな推奨度を算出し、送信手段は、算出手段により算出された新たな推奨度を、受付手段により受け付けられた提案とともに購入側端末に送信してもよい。このように所定の周期で新たな推奨度が算出されて購入側端末に送信されることによって、購入希望者は、新しい推奨度に基づいて、適切なタイミングで商品・サービスを購入できるようになる。
【００１１】
算出手段は、受付手段により受け付けられた提案の数（提案数）、および、提供者が提供側端末を用いて要求を閲覧した数（閲覧数）、の少なくとも一方に基づいて、推奨度を算出してもよい。たとえば、算出手段は、提案の数が大きいほど、推奨度が高くなるように算出してもよい。提案数が大きいほどすでに十分な提案が行われた可能性が高いと考えられるので、この算出手法によれば、十分な提案が行われた可能性が高いほど推奨度が大きくなる。あるいは、算出手段は、閲覧した数（閲覧数）が大きいほど、推奨度が高くなるように算出してもよい。閲覧数が大きいほど今後さらに提案が行われる可能性が低いと考えられるので、この算出手法によれば、今後提案が行われる可能性が低いほど推奨度が大きくなる。以上により、推奨度を適切に設定することができる。
【００１２】
購入側端末は、情報処理装置の送信手段から送信された推奨度および提案を受信する受信手段と、受信手段により受信された推奨度に応じた態様で、提案を提示する提示手段と、を備えてもよい。この場合、たとえば推奨度が高いほど商品・サービスの購入を購入希望者に強く促すような提示態様とすることで、購入希望者は、より適切なタイミングで商品・サービスを購入することができるようになる。
【００１３】
情報処理装置は、推奨度に対するしきい値を設定する設定手段、をさらに備え、購入側端末の提示手段は、受信手段により受信された推奨度がしきい値以上の場合に、所定の通知処理を実行してもよい。このように推奨度がしきい値以上の場合に購入希望者への通知が行われることによって、商品・サービスを購入すべき適切なタイミングで、購入希望者に商品・サービスの購入を促すことができる。
【００１４】
情報処理装置は、送信手段が送信した推奨度と、受付手段が受け付けた提案の数と、購入希望者が購入した商品・サービスの数と、を記憶する記憶手段、をさらに備え、設定手段は、記憶手段に記憶された情報に基づいて、受付手段により受け付けられる提案の数に対する購入希望者による商品・サービスの購入の数の割合を示すコンバージョン率が所定値以上になると予測される推奨度を、しきい値として設定してもよい。これにより、上述の通知処理を実行することで、所定値以上のコンバージョン率で購入希望者が商品・サービスを購入することが期待できる。
【発明の効果】
【００１５】
本発明によれば、購入希望者が適切なタイミングで商品等を購入できるようになる。
【図面の簡単な説明】
【００１６】
【図１】情報処理装置によって実現される情報処理システムの概要を説明するための図である。
【図２】情報処理システムの機能ブロックを示す図である。
【図３】要求ＤＢの一例を示す図である。
【図４】提案ＤＢの一例を示す図である。
【図５】提供者ＤＢの一例を示す図である。
【図６】商品ＤＢの一例を示す第１の図である。
【図７】商品ＤＢの一例を示す第２の図である。
【図８】しきい値の設定について説明するための図である。
【図９】サーバのハードウェア構成の一例を示す図である。
【図１０】情報処理システムにおいて実行される処理の一例を示すフローチャートである。
【図１１】購入側端末における表示の一例を示す図である。
【図１２】図１０のステップＳ２５において実行される処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１７】
以下、本発明の実施形態について、図面を参照しながら説明する。なお、図面の説明において同一要素には同一符号を付し、重複する説明は省略する。
【００１８】
図１は、実施形態に係る情報処理装置によって実現される情報処理システムの概要を説明するための図である。この情報処理システム１は、たとえばサーバ１００によって実現され、購入希望者Ｕおよび提供者Ｐによって利用される。
【００１９】
購入希望者Ｕは、商品・サービスの購入を希望する消費者であり、サーバ１００と通信可能な購入側端末１０を有している。提供者Ｐは、商品・サービス（以下、単に「商品」という場合もある）を提供する販売者であり、サーバ１００と通信可能な提供側端末２０を有している。サーバ１００は、購入希望者Ｕが購入を希望する商品の要求と、その要求に対する提供者Ｐからの商品の提案とをマッチさせる。以下では、購入希望者Ｕが商品の購入を希望する場合について説明し、サービスの購入を希望する場合については説明を省略する。商品の種類はとくに限定されるものではない。本明細書では、商品として衣服を例に挙げて説明する。
【００２０】
図１に示す例では、１人の購入希望者Ｕ、および３人の提供者Ｐが情報処理システム１を利用する。３人の提供者Ｐを区別し得るように、各提供者Ｐには、ＰＡ，ＰＢ，ＰＣの異なる符号も付している。
【００２１】
購入希望者Ｕは、要求を行う。ここでの「要求」は、購入希望者Ｕが購入を希望する商品に対して提供者Ｐから提案が行われることに対する要求である。具体的に、購入希望者Ｕは、購入側端末１０を用いて要求データＲの登録を行う。要求データＲは、購入側端末１０によってサーバ１００に送信される。なお、図１に示す例では、購入希望者Ｕが１つの要求を行う（１つの要求データＲを登録する）様子が示されるが、購入希望者Ｕは、複数の要求を行なってもよい。
【００２２】
サーバ１００は、要求を受け付け（要求データＲを受信し）、要求リストＬを生成する。複数の要求が受け付けられた場合には、要求リストＬは、複数の要求で構成されるリストとなる。サーバ１００は、生成した要求リストＬを、提供者Ｐの提供側端末２０にそれぞれ送信する。
【００２３】
図１に示す例では、要求リストＬは、「要求ＩＤ」と、「要求属性」とを対応づけて記述している。「要求ＩＤ」は、各要求を区別するための識別子（ＩＤ：Identifier）である。図１では、理解を容易にするため、要求ＩＤとして、要求データＲの符号を用いて表している。「要求属性」は、要求ＩＤに対応する要求データＲの具体的な内容を示す。この例では、要求属性は衣服の種類（シャツ、長袖など）、色彩（青など）、サイズ（Ｍなど）を用いて表される。
【００２４】
提供者Ｐは、提案を行う。ここでの「提案」は、購入希望者Ｕからの要求に対して行う商品の提案である。提供者Ｐは、サーバ１００から提供側端末２０に送信された要求リストＬを、提供側端末２０を用いて参照することによって、要求リストＬ内の要求に対して提案を行い得る。具体的に、提供者Ｐは、提供側端末２０を用いて提案データＦの登録を行う。提案データＦは、提供側端末２０からサーバ１００に送信される。図１に示す例では、３人の提供者Ｐのうちの、提供者ＰＡおよび提供者ＰＢが、提案データＦの登録を行う。各提供者Ｐの提案に係る提案データＦをそれぞれ区別し得るように、ＦＡ，ＦＢの異なる符号も付している。
【００２５】
サーバ１００は、提案を受け付ける（提案データＦを受信する）。図１に示す例では、サーバ１００は、複数の提案を受け付ける（提案データＦＡ、ＦＢを受信する）。各提案が行われるタイミングは同時でない場合もあるので、各提案は、時間差を有して受け付けられ得る。サーバ１００は、受信した提案データＦを、購入希望者Ｕの購入側端末１０に送信する。
【００２６】
ここで、提案データＦを購入側端末１０に送信する際、サーバ１００は、推奨度ＰＲを算出し、算出した推奨度ＰＲを、複数の提案データＦ（ＦＡ，ＦＢ）とともに購入側端末１０に送信する。換言すれば、推奨度ＰＲは、要求ごとに算出され、対応する要求に対して、当該要求に対して行われた提案とともに、購入側端末１０に送信される。推奨度ＰＲは、たとえば０〜１の間の数値に設定される。推奨度ＰＲの算出手法については後に詳述する。
【００２７】
たとえば以上のようにして、購入希望者Ｕに対して、提供者Ｐからの提案がそれぞれ行われる。また、各提案（各提案データＦ）は、推奨度ＰＲとともに、サーバ１００から購入側端末１０へ送信される。購入側端末１０では、推奨度ＰＲに応じた種々の態様で、提案データＦが提供者Ｐに提示される。これにより、提供者Ｐは、推奨度ＰＲに基づいて、要求に対して行われた提案に係る商品を購入すべきか否かを判断することができるようになる。
【００２８】
図２は、情報処理システム１の機能ブロックを示す図である。図２に示すように、情報処理システム１は、購入側端末１０と、サーバ１００と、提供側端末２０とを含む。
【００２９】
まず、購入側端末１０について説明する。購入側端末１０は、通信部１２と、操作部１４と、表示部１６と、制御部１８とを含む。
【００３０】
通信部１２は、後述のサーバ１００の通信部１１０と通信を行う部分である。これにより、購入側端末１０とサーバ１００との通信が可能になる。たとえば、通信部１２は、要求データＲをサーバ１００に送信する。通信部１２は、サーバ１００の通信部１１０から送信された推奨度ＰＲおよび提案データＦを受信する部分（受信手段）でもある。
【００３１】
操作部１４は、購入側端末１０のユーザ、つまり購入希望者Ｕ（図１）によるユーザ操作を受け付ける部分である。たとえば、操作部１４は、要求を行う（要求データＲを登録する）ための操作を受け付ける要求データ登録部として機能する。操作部１４は、提案に対する評価を行う（後述の評価情報を登録する）ための操作なども受け付ける。
【００３２】
表示部１６は、購入希望者Ｕに対して種々の情報を表示する部分である。たとえば、表示部１６は、要求に対して行われた提案の内容を表示する提案商品表示部として機能する。表示部１６は、通信部１１０により受信された推奨度ＰＲに応じた態様で、提案（提案データＦ）を提示する部分（提示手段）でもある。同一の購入希望者Ｕによって複数の要求が行われている場合には、各要求に対して行われた提案がそれぞれ提示される。
【００３３】
たとえば、表示部１６は、要求および当該要求に対する提案（ここでは単に「要求」という）とともに、推奨度ＰＲの数値（０〜１）を表示する。あるいは、表示部１６は、各要求を、推奨度ＰＲが高いほど（１に近いほど）その要求を、購入希望者Ｕの注意を惹きやすい態様で表示する。たとえば、推奨度ＰＲが高いほど、要求が表示部１６の上方の部分に表示されたり、注意を惹きやすい色で表示されたりする。
【００３４】
上述の表示部１６による表示は、たとえば、購入希望者Ｕが購入側端末１０を操作することに応じて行われる。換言すれば、購入希望者Ｕが購入側端末１０を操作しない場合には、表示部１６による表示は行われなくてもよい。その場合、表示部１６は、推奨度ＰＲに応じて、所定の通知処理を実行してもよい。通知処理は、提案が行われた旨を購入希望者Ｕに通知するための処理であり、文字列で構成されたメッセージの表示などであってよい。たとえば、そのメッセージが表示された部分が購入希望者Ｕによる購入側端末１０の操作によって選択されると、上述の表示部１６による表示が行われる。このような通知処理は、たとえば、通信部１１０によって受信された推奨度ＰＲが後述のしきい値以上の場合に実行され、推奨度ＰＲがしきい値未満の場合には実行されないようにしてもよい。
【００３５】
制御部１８は、購入側端末１０に含まれる各要素を制御することによって購入側端末１０の全体制御を行う部分である。たとえば、購入側端末１０によって情報処理システム１を利用するためのアプリケーションプログラムが、制御部１８によって実行される。
【００３６】
次に、サーバ１００について説明する。サーバ１００は、通信部１１０と、推奨度算出部１２０と、要求リスト生成部１３０と、しきい値設定部１３５と、記憶部１４０と、制御部１５０とを含む。
【００３７】
通信部１１０は、購入側端末１０の通信部１２と通信を行う部分である。通信部１１０は、要求データＲを受信することによって、購入側端末１０からの要求を受け付ける部分でもある。また、通信部１１０は、要求リストＬを提供側端末２０に送信する部分でもある。また、通信部１１０は、提案データＦを受信することによって、要求に対する提供側端末２０からの提案を受け付ける部分（受付手段）でもある。また、通信部１１０は、推奨度ＰＲとともに提案（提案データＦ）を購入側端末１０に送信する部分（送信手段）でもある。また、通信部１１０は、評価情報を受信することによって、提案に対する購入側端末１０からの評価情報を受け付ける部分でもある。また、通信部１１０は、閲覧情報（後述）を受信することによって、要求に対する提供側端末２０からの閲覧情報を受け付ける部分でもある。
【００３８】
推奨度算出部１２０は、通信部１１０により受け付けられた提案に係る商品の購入の推奨度を算出する部分（算出手段）である。推奨度の算出の手法については後述する。
【００３９】
要求リスト生成部１３０は、要求リストＬを生成する部分である。要求リストＬは、複数の要求を含んでもよい。要求リストＬは、たとえば要求の登録が行われたときなどに生成される。新たな要求の登録が行われた時などには、要求リスト生成部１３０は、要求リストＬを更新してもよい。
【００４０】
しきい値設定部１３５は、推奨度ＰＲに対するしきい値を設定する部分（設定手段）である。しきい値設定部１３５によるしきい値の設定手法については、後に図８を参照して説明する。
【００４１】
記憶部１４０は、サーバ１００によって実行される処理に必要な種々の情報を記憶する部分（記憶手段）である。記憶部１４０は、複数のデータベース（ＤＢ：Data  Base）を含む。本実施形態では、記憶部１４０は、要求ＤＢ１４２と、提案ＤＢ１４４と、提供者ＤＢ１４６と、商品ＤＢ１４８とを含む。要求ＤＢ１４２は、要求に関する情報を記憶する部分である。提案ＤＢ１４４は、提案に関する情報を記憶する部分である。提供者ＤＢ１４６は、提供者に関する情報を記憶する部分である。商品ＤＢ１４８は、商品に関する情報を記憶する部分である。具体的に、図３〜図７を参照して、各ＤＢの例を説明する。
【００４２】
まず、図３を参照して、要求ＤＢ１４２の一例について説明する。この例では、要求ＤＢ１４２は、「要求データ」と「要求管理データ」とに大別される。「要求データ」は、先に説明した、購入側端末１０からサーバ１００に送信される要求データＲである。例えば、購入側端末１０において、要求データＲを入力するための購入希望者Ｕによるユーザ操作を、操作部１４が受け付ける。すると、その情報が、要求データＲとして１０からサーバ１００に送信され、要求ＤＢ１４２に登録される。その際、後述の要求ＩＤおよび購入希望者ＩＤが、購入側端末１０あるいはサーバ１００において自動的に付与されてよい。「要求管理データ」は、各要求を管理するためのデータである。
【００４３】
「要求データ」では、「要求ＩＤ」と、「購入希望者ＩＤ」と、「提案期限」と、「購入希望場所」と、「カテゴリ」と、「サイズ」と、「色」と、「価格」とが対応付けて記述される。
【００４４】
「要求ＩＤ」については、先に図１を参照して説明したとおりである。なお、図３に示される例では、要求ＩＤは、図１の例とは異なり、数字の組み合わせ（「０００１」）などで表される。
【００４５】
「購入希望者ＩＤ」は、各購入希望者Ｕを区別するための識別子である。図３に示す例では、購入希望者ＩＤは、アルファベットの組み合わせ（「ＵｓｅｒＡ」など）で表される。
【００４６】
「提案期限」は、要求に対して行われる提案の期限である。図３に示す例では、提案期限は、日付および時刻（「２０１５/１/３０  ２０：００」など）で表される。
【００４７】
「希望購入場所」は、購入希望者Ｕが商品の購入を希望する場所である。図３に示す例では、希望購入場所は、地域の名称、都市の名称など（「東京都世田谷区」、「神奈川県川崎市」など）で表される。
【００４８】
「カテゴリ」、「サイズ」、「色」、「価格」は、要求に係る商品の情報である。図３に示す例では、商品の情報は、「Ｓｈｉｒｔ」等のカテゴリ、「Ｌ」等のサイズ、「Ｒｅｄ」等の色、「５，０００円」等の価格で表される。
【００４９】
一方、「要求管理データ」では、「閲覧数」と、「提案数」と、「購入推奨度」とが対応付けて記述される。
【００５０】
「閲覧数」は、対応する要求ＩＤに係る要求が、これまでに提供者Ｐによって閲覧された回数である。たとえば、提供側端末２０において、表示部２４に表示された要求リストＬ内のいずれかの要求を閲覧するための提供者Ｐによる操作を、操作部２６が受け付ける。すると、その要求に関する詳細な情報（つまり要求データＲなど）が、表示部２４に表示され、提供者Ｐによって閲覧される。これに応じて、要求が閲覧されたという情報（閲覧情報）が提供側端末２０からサーバ１００に送信され、閲覧数が増加する。
【００５１】
「提案数」は、対応する要求ＩＤに係る要求に対して、これまでに提供者Ｐが行った提案の回数である。提供者Ｐが提案の登録を行うと、提案数は増加する。
【００５２】
「購入推奨度」は、先に説明した推奨度ＰＲである。
【００５３】
次に、図４を参照して、提案ＤＢ１４４の一例について説明する。この例では、提案ＤＢ１４４は、「提案データ」と、「提案管理データ」とに大別される。「提案データ」は、先に説明した、提供側端末２０からサーバ１００に送信される提案データＦである。たとえば、提供側端末２０において、提案データＦを入力するための提供者Ｐによるユーザ操作を、操作部２６が受け付ける。すると、その情報が、提案データＦとして提供側端末２０からサーバ１００に送信され、提案ＤＢ１４４に登録される。その際、後述の商品ＩＤ、要求ＩＤ、提案日時および提供者ＩＤ（図５参照）は、提供側端末２０あるいはサーバ１００において自動的に付与されてよい。「提案管理データ」は、各提案を管理するためのデータである。
【００５４】
「提案データ」では、「商品ＩＤ」と、「要求ＩＤ」と、「提案日時」と、「提案コメント」とが対応づけて記述される。
【００５５】
「商品ＩＤ」は、各提案に係る商品を区別するための識別子である。図４に示す例では、商品ＩＤは、アルファベットおよび数字の組み合わせ（「Ｐ＿００２」など）で表される。
【００５６】
「要求ＩＤ」については、先に図３を参照して説明したとおりである。
【００５７】
「提案日時」は、提案が行われた日時である。たとえば、サーバ１００が提供側端末２０から提案データＦを受信したタイミングが、提案日時とされる。図４に示す例では、提案日時は、日付および時刻（「２０１５/１/２９  ２０：１２」など）で表される。
【００５８】
「提案コメント」は、提案に係る商品についてのコメントである。図４に示す例では、提案コメントは、文字列（「新商品です」など）で表される。
【００５９】
一方「提案管理データ」は、「消費者からの評価」を含む。
【００６０】
「消費者からの評価」は、対応する商品ＩＤに係る商品に対する購入希望者Ｕの評価、つまり提供者Ｐからの提案に対する購入希望者Ｕの評価の度合いを数値で示したものである。たとえば、購入側端末１０において、表示部１６に表示された提案データＦに対する評価を示す情報（評価情報）を入力するための購入希望者Ｕによる操作を、操作部１４が受け付ける。すると、その評価情報が、購入側端末１０からサーバ１００に送信され、提案ＤＢ１４４に評価が登録される。図４に示す例では、消費者からの評価は、１〜３の範囲で定められる。たとえば評価が最も低い場合には評価＝１とされ、評価が最も高い場合には評価＝３とされる。
【００６１】
次に、図５を参照して、提供者ＤＢ１４６の一例について説明する。この例では、提供者ＤＢ１４６は、「提供者ＩＤ」と、「提供場所」と、「提案数」と、「売上数」と、「閲覧数」と、「年齢層」と、「性別」とを対応づけて記述する。
【００６２】
「提供者ＩＤ」は、各提供者Ｐを区別するための識別子である。図５に示す例では、購入希望者ＩＤは、アルファベットおよび数字の組み合わせ（「Ｐ＿００３」など）で表される。
【００６３】
「提供場所」は、提案に係る商品が提供される場所（たとえば店舗の所在地など）であり、先に説明した図３における「購入希望場所」と同様に表されてよい。
【００６４】
「提案数」は、対応する提供者ＩＤに係る提供者Ｐが、これまでに行った提案の回数の総和である。ここでの提案数には、いずれの要求に対して行われた提案であるかによらず、すべての提案がカウントされる。たとえば、サーバ１００が提供側端末２０から送信された提案データＦを受信すると、対応する提供者Ｐの提案数が増加する。
【００６５】
「売上数」は、対応する提供者ＩＤに係る提供者Ｐが、情報処理システム１を利用することによって、これまでに販売した商品の総数を示す。たとえば、提供者Ｐが提案した商品を購入希望者Ｕが購入すると、その旨が購入側端末１０および／または提供側端末２０からサーバ１００に通知され、その提供者Ｐの売上数が増加する。
【００６６】
「閲覧数」は、対応する提供者ＩＤに係る提供者Ｐが、これまでに要求を閲覧した回数の総和である。ここでの閲覧数には、いずれの要求に対して行われた閲覧であるかによらず、すべての閲覧がカウントされる。
【００６７】
「年齢層」、「性別」は、提供者Ｐがターゲットとする購入希望者（ターゲット層）の情報である。図５に示す例では、ターゲット層の情報は、「２０〜４０歳」等の年齢層、「Ｍ」等の性別で表される。
【００６８】
次に、図６および図７を参照して、商品ＤＢ１４８の一例について説明する。商品ＤＢ１４８は、商品内部情報および商品外部情報を含む。商品内部情報は、提案に係る商品に関する情報である。商品外部情報は、提案に係る商品であるか否かによらず、情報処理システム１で購入等が可能な全ての商品に関する情報である。
【００６９】
図６は、商品ＤＢ１４８に含まれる商品内部情報の一例を示す。この例では、商品内部情報は、「商品情報」と、「商品管理情報」とに大別される。
【００７０】
「商品情報」では、「商品ＩＤ」と、「提供者ＩＤ」と、「カテゴリ」と、「サイズ」と、「色」と、「価格」と、「商品画像」とが対応づけて記述される。
【００７１】
「商品ＩＤ」および「提供者ＩＤ」については、先に図４および図３を参照して説明したとおりである。
【００７２】
「カテゴリ」、「サイズ」、「色」、「価格」は、提案に係る商品の情報であり、先に説明した図３における「カテゴリ」、「サイズ」、「色」、「価格」と同様に表されてよい。
【００７３】
「商品画像」は、提案に係る商品の画像データである。画像データは、たとえば、提供側端末２０のカメラ（不図示）などを用いて撮像された商品の画像データが、提供側端末２０からサーバ１００に送信されることによって取得される。図４に示す例では、商品画像は、アルファベットを組み合わせたファイル名（「Img_002.jpg」など）で表される。
【００７４】
「商品管理情報」では、「販売開始日時」と、「販売数」と、「在庫数」と、「総合評価」とが対応付けて記述される。
【００７５】
「販売開始日時」は、対応する商品ＩＤに係る商品の販売が開始された日時である。販売開始日時は、先に図４を参照して説明した「提案日時」であってよい。
【００７６】
「販売数」は、これまでに販売された、対応する商品ＩＤに係る商品の総数を示す。販売数は、たとえば、先に図５を参照して説明した「売上数」と同様にして増加する。
【００７７】
「在庫数」は、対応する商品ＩＤに係る商品の在庫数である。在庫数は、提供者Ｐの店舗における商品の仕入れおよび販売などに応じて増減する。
【００７８】
「総合評価」は、対応する商品ＩＤに係る商品に対する、情報処理システム１を利用している全ての購入希望者Ｕによる評価の度合いを数値で示したものである。「総合評価」は、先に図４を参照して説明した「消費者からの評価」と同様にして登録される。「総合評価」は、たとえば各購入希望者Ｕによる評価の平均値である。
【００７９】
図７は、商品ＤＢ１４８に含まれる商品外部情報の一例を示す。商品外部情報では、たとえば、「商品種類数」と、「在庫数」と、「提供者数」とが対応づけて記述される。
【００８０】
「商品種類数」は、情報処理システム１で購入等が可能な全ての商品の種類の数である。「在庫数」は、情報処理システム１で購入等が可能な全ての商品の在庫の数である。「提供者数」は、情報処理システム１を利用しているすべての提供者Ｐの数である。
【００８１】
再び図２に戻り、記憶部１４０は、通信部１１０が通信部１１０に送信した推奨度ＰＲと、通信部１１０が提供側端末２０から受信した提案の数と、購入希望者Ｕが購入した商品の数とを対応づけて記述するデータ（購入履歴データ）を記憶してもよい。
【００８２】
制御部１５０は、サーバ１００に含まれる各要素を制御することによってサーバ１００の全体制御を行う部分である。
【００８３】
先に説明したように、サーバ１００の推奨度算出部１２０は、推奨度ＰＲを算出する。推奨度ＰＲは、要求に対して行われた提案に係る商品の購入の推奨の度合いを示す指標であり、要求ごとに算出される。推奨度ＰＲは、先に説明した記憶部１４０に記憶された種々の情報に基づいて算出される。たとえば、推奨度ＰＲは、提案数および閲覧数（図３）などに基づいて算出される。たとえば、推奨度算出部１２０は、提案数が大きいほど、推奨度ＰＲが高くなるように算出する。また、推奨度算出部１２０は、閲覧数が大きいほど、推奨度ＰＲが高くなるように算出する。
【００８４】
具体的に、各要求について、推奨度ＰＲが、ＰＲ＝α×（ＮＰ／ＮＰｇｏａｌ）＋β×（ＮＣ／ＮＳ）として算出される。
【００８５】
ＮＰは、要求に対する提案数（たとえば図３の「提案数」に相当）である。ＮＰｇｏａｌは、要求に対して行われる提案数の目標の数（目標提案数）であり、予め定められた任意の数であってよい。（ＮＰ／ＮＰｇｏａｌ）は、要求に対して行われた提案数の、目標提案数に対する達成の度合いを示す。αは、（ＮＰ／ＮＰｇｏａｌ）を適切な範囲に変換するための係数（提案数パラメータ）である。（ＮＰ／ＮＰｇｏａｌ）の適切な範囲は、推奨度ＰＲが所定の範囲（たとえば０〜１）に収まるような、（ＮＰ／ＮＰｇｏａｌ）の範囲である。α×（ＮＰ／ＮＰｇｏａｌ）は、目標提案数に対して十分な提案が行われたかを示す値であるとも言える。
【００８６】
ＮＣは、要求に対する閲覧数（たとえば図３の「閲覧数」に相当）である。ＮＳは、提供者Ｐの総数（たとえば図７の「提供者数」に相当）である。よって、（ＮＣ／ＮＳ）は、提供者Ｐの総数に対する、要求を閲覧した提供者Ｐの数の割合を示す。βは、（ＮＣ／ＮＳ）を適切な範囲に変換するための係数（閲覧数パラメータ）である。（ＮＣ／ＮＳ）の適切な範囲は、推奨度ＰＲが所定の範囲（たとえば０〜１）に収まるような、（ＮＣ／ＮＳ）の範囲である。β×（ＮＣ／ＮＳ）は、提供者Ｐの総数に対して十分に多くの提供者Ｐから閲覧が行われたか否かを示す値であるとも言える。
【００８７】
上述の式に基づけば、推奨度算出部１２０は、提案数が大きいほど、推奨度ＰＲが高くなるように算出する。また、推奨度算出部１２０は、閲覧数が大きいほど、推奨度ＰＲが高くなるように算出する。
【００８８】
さらに、推奨度ＰＲは、提案数および閲覧数以外の情報に基づいて算出されてもよい。
【００８９】
推奨度ＰＲは、先に図６を参照して説明した商品内部情報に基づいて算出されてもよい。具体的に、商品内部情報のうちの商品管理情報、すなわち「販売開始日時」、「販売数」、「在庫数」、「総合評価」に基づいて、推奨度ＰＲが算出されてもよい。たとえば、「販売開始日時」と現在日時との差が大きいほど、推奨度ＰＲが高くなるように算出される。「販売数」が多いほど、推奨度ＰＲが高くなるように算出される。商品内部情報における「在庫数」が少ないほど、推奨度ＰＲが高くなるように算出される。「総合評価」が高いほど、推奨度ＰＲが高くなるように算出される。
【００９０】
次に、しきい値設定部１３５（図２）の詳細について説明する。先に説明したように、しきい値設定部１３５は、推奨度ＰＲに対するしきい値を設定する。また、先に説明したように、しきい値は、表示部１６が所定の通知処理を実行するか否かを判断するための基準値とされる。しきい値は予め定められた一つの値であってもよいが、次に説明するように、しきい値設定部１３５によって、より適切な値に設定（更新）されてもよい。
【００９１】
先に説明したように、購入側端末１０では、推奨度ＰＲに応じた態様で各要求に対する提案が提示され、購入希望者Ｕが提案に係る商品を購入すべきか否かを判断する。そして、記憶部１４０は、前述の購入履歴データを記憶してもよい。購入履歴データに基づけば、購入希望者Ｕが提案に係る商品を購入することがある程度期待できる推奨度ＰＲの大きさを求めることができる。しきい値設定部１３５は、このようにして求めた推奨度ＰＲの大きさを、しきい値として設定する。具体的に、図８を用いて説明する。
【００９２】
図８は、しきい値の設定手法の一例を説明するための図である。図８のグラフの横軸は推奨度ＰＲを示し、縦軸は、コンバージョン率ＣＲを示す。コンバージョン率ＣＲは、提案数に対する購入数の比率である。コンバージョン率ＣＲは、購入希望者Ｕごとにそれぞれ定められる値であってもよいし、情報処理システム１を利用するすべての購入希望者Ｕについて定められる１つの値であってもよい。コンバージョン率ＣＲは、提案が行われた場合に購入希望者Ｕが提案に係る商品を購入することが期待できる期待値であるとも言える。そして、図８に示す例では、コンバージョン率ＣＲが所定値（たとえば０．４５程度）となる推奨度ＰＲの大きさ（たとえば０．７）が、推奨度ＰＲに対するしきい値とされる。このようなしきい値がしきい値設定部１３５によって設定されると、推奨度ＰＲが当該しきい値以上の推奨度ＰＲの場合に、表示部１６によって前述の通知処理が実行され、購入希望者Ｕは、所定のコンバージョン率ＣＲで提案に係る商品を購入することが期待できる。
【００９３】
次に、図９を参照して、サーバ１００のハードウェア構成について説明する。図９に示すように、サーバ１００は、物理的には、１または複数のＣＰＵ（Central  Processing  unit）５１、主記憶装置であるＲＡＭ（Random  Access  Memory）５２およびＲＯＭ（Read  Only  Memory)５３、データ送受信デバイスである通信モジュール５４、半導体メモリなどの補助記憶装置５５、ユーザ操作の入力を受け付ける入力装置５６、ディスプレイといった出力装置５７などを備えるコンピュータとして構成され得る。図２におけるサーバ１００の各機能は、たとえば、ＣＰＵ５１，ＲＡＭ５２などのハードウェア上に１または複数の所定のコンピュータソフトウェアを読み込ませることにより、ＣＰＵ５１の制御のもとで通信モジュール５４、入力装置５６、出力装置５７などを動作させるとともに、ＲＡＭ５２および補助記憶装置５５におけるデータの読み出しおよび書き込みを行うことで実現することができる。
【００９４】
次に、情報処理システム１において実行される処理の一例について、図１０を参照して説明する。この処理は、たとえば、購入側端末１０において、情報処理システム１を利用するための所定のアプリケーションが起動されたことに応じて開始される。なお、このフローチャートでは、複数の提供者Ｐの各提供側端末２０（第１および第２の提供側端末）から提案が行われる場合について説明する。とくに説明が無い場合には、第１および第２の提供側端末をまとめて提供側端末２０として説明する。
【００９５】
購入側端末１０は、要求データの入力を受け付け（ステップＳ１０）、要求データを送信する（ステップＳ１１）。具体的に、購入側端末１０の操作部１４が購入希望者Ｕのユーザ操作による要求データＲの入力を受け付け、購入側端末１０の通信部１２が、要求データＲをサーバ１００の通信部１１０に送信する。
【００９６】
ステップＳ１１の処理が実行されると、サーバ１００は、要求データを取得する（ステップＳ２０）。具体的に、サーバ１００の通信部１１０が、購入側端末１０から送信される要求データＲを受信する（要求を受け付ける）。
【００９７】
また、サーバ１００は、要求リストを生成する（ステップＳ２１）。具体的に、要求リスト生成部１３０が先のステップＳ２０において取得された要求データＲに基づいて、要求リストＬを生成する。
【００９８】
そして、サーバ１００は、要求リストを送信する（ステップＳ２２）。具体的にサーバ１００の通信部１１０が、先のステップＳ２１において生成された要求リストＬを、対応する提供者Ｐの提供側端末２０の通信部２２にそれぞれ送信する。
【００９９】
ステップＳ２２の処理が実行されると、提供側端末２０は、要求リストを受信する（ステップＳ３０）。具体的に、提供側端末２０の通信部２２が、サーバ１００の通信部１１０から送信される要求リストＬを受信する（要求を取得する）。
【０１００】
次に、提供側端末２０は、要求リストを表示する（ステップＳ３１）。具体的に、提供側端末２０の表示部２４が、先のステップＳ３０において受信された要求リストＬを表示する。
【０１０１】
そして、提供側端末２０は、提案データの入力を受け付け（ステップＳ３２）、提案データを送信する（ステップＳ３３）。具体的に、提供側端末２０の操作部２６が提供者Ｐのユーザ操作による提案データＦの入力を受け付け、提供側端末２０の通信部２２が、提案データＦをサーバ１００の通信部１１０に送信する。
【０１０２】
ここで、ステップＳ３２の処理は、第１の提供側端末と第２の提供側端末とで時間差を有して実行される。ステップＳ３３の処理も、第１の提供側端末と第２の提供側端末とで時間差を有して実行される。図１０に示す例では、まず、第１の提供側端末によってステップＳ３３の処理が実行され、その後、時間差を有して、第２の提供側端末によってステップＳ３３の処理が実行される。
【０１０３】
第１の提供側端末によってステップＳ３３の処理が実行されると、サーバ１００は、提案データを受信し、データを更新する（ステップＳ２３）。提案データの受信は、通信部１１０によって実行される。データの更新は、たとえば制御部１５０によって実行される。具体的に、制御部１５０が、記憶部１４０に記憶されている提案ＤＢ１４４に、受信した提案データＦの内容（図４の「商品ＩＤ」など）が追加されるように、提案ＤＢ１４４を更新する。なお、記憶部１４０に記憶されている要求ＤＢ１４２（「閲覧数」、「提案数」など）、提供者ＤＢ１４６（「提案数」など）も、適宜更新される。
【０１０４】
同様に、第２の提供側端末によってステップＳ３３の処理が実行されると、サーバ１００は、提案データを受信し、データを更新する（ステップＳ２４）。
【０１０５】
ステップＳ２３，Ｓ２４において受信された各提案データＦは、所定のデータ送信のタイミングで、購入側端末１０に送信される。所定のタイミングは、たとえば、各提案データＦが受信されたタイミングであってもよいし、所定の数の提案データＦ（たとえば数個の提案データＦ）が受信されたタイミングであってもよい。また、所定のタイミングは、所定の周期に基づくタイミング（たとえば数時間から数十時間毎）であってもよく、これについては、後に図１２を参照して説明する。
【０１０６】
上述のデータ送信のタイミングに至った後（ステップＳ２５）、サーバ１００は、購入推奨度を算出し（ステップＳ２６）、提案データとともに購入推奨度を送信する（ステップＳ２７）。具体的に、推奨度算出部１２０が推奨度ＰＲを算出し、通信部１１０が、先のステップＳ２３，Ｓ２４において受信された提案データＦ（受け付けられた提案）とともに推奨度算出部１２０によって算出された推奨度ＰＲをサーバ１００の購入側端末１０に送信する。なお、購入推奨度が算出された際、たとえば制御部１５０によって、要求ＤＢ１４２（「購入推奨度」）も適宜更新される。
【０１０７】
ステップＳ２７の処理が完了した後、サーバ１００は、再びステップＳ２３に処理を戻す。この場合のステップＳ２３では、第１および第２の提供側端末以外の図示しない提供側端末２０から送信された新たな提案データＦが、通信部１１０によって受信される。その後のステップＳ２６では、推奨度算出部１２０によって、推奨度ＰＲが再び算出される。その後のステップＳ２７では、新たな提案データＦとともに再び算出された推奨度ＰＲが、購入側端末１０に送信される。
【０１０８】
サーバ１００によってステップＳ２７の処理が実行されると、購入側端末１０は、推奨度および提案データを受信する（ステップＳ１３）。具体的に、購入側端末１０の通信部１２がサーバ１００の通信部１１０から送信される推奨度ＰＲおよび提案データＦを受信する。
【０１０９】
そして、購入側端末１０は、提案を表示する（ステップＳ１４）。具体的に、購入側端末１０の表示部１６が、先のステップＳ１３において受信された推奨度ＰＲに応じた態様で、提案データＦを提示する。
【０１１０】
ステップＳ１４の処理が完了した後、フローチャートの処理が終了する。
【０１１１】
図１１は、図１０のステップＳ１４における提案の表示の一例を示す図である。図１１に示す例では、購入希望者Ｕによって登録された２つの要求データＲ１，Ｒ２の各々に対して、提案データＦがそれぞれ表示されている。より具体的には、要求データＲ１に対して、提供者ＰＡ（図１）によって登録された提案データＦＡ１および提供者ＰＢ（図１）によって登録された提案データＦＢ１が表示されている。同様に、要求データＲ２に対しても、提供者ＰＡによって登録された提案データＦＡ２および提供者ＰＢによって登録された提案データＦＢ２が表示されている。
【０１１２】
また、表示部１６において表示されている要求データＲ１の上方に、推奨度ＰＲを示す図形（星印）および文字列（「買うなら今！」）が表示されている。この表示は、たとえば推奨度ＰＲが比較的高い場合（たとえば０．７以上）に表示される。これにより、購入側端末１０の提供者Ｐに対して、要求データＲ１に対する提案データＦＡ１，ＦＢ１に係る商品の購入が促される。
【０１１３】
一方、要求データＲに対する提案データＦＡ２，ＦＢ２に係る商品については、推奨度ＰＲが比較的低く（たとえば０．７未満）、未だ、提供者Ｐに対して購入を促す提示態様とされていない。
【０１１４】
図１１に示す例では、要求データＲ１の推奨度ＰＲの方が、要求データＲ２の推奨度ＰＲよりも高く、その結果、要求データＲ１および提案データＦＡ１、ＦＢ１が表示部１６の上側に表示され、要求データＲ２および提案データＦＡ２，ＦＢ２が表示部１６の下側に表示されている。すなわち、推奨度ＰＲに応じて、要求データＲおよび提案データＦの表示順序が定められている。
【０１１５】
なお、図１１には図示しないが、推奨度ＰＲに応じて、要求データＲおよび提案データＦの表示色が変更されてもよい。たとえば、推奨度ＰＲが高い要求データＲ１および提案データＦＡ１，ＦＢ１の表示色ほど、提供者Ｐの注意を惹きやすい色とされる。
【０１１６】
次に、サーバ１００の作用効果について説明する。サーバ１００によれば、受け付けられた提案に係る商品の購入の推奨度ＰＲが算出され（ステップＳ２３，Ｓ２４，Ｓ２６）、提案とともに購入側端末に送信される（ステップＳ２７）。これにより、提供者Ｐは、購入側端末１０に送信された推奨度ＰＲを参考として、提案に係る商品を購入すべきか否かを判断することができる。よって、提供者Ｐが適切なタイミングで商品を購入することが可能になる。
【０１１７】
また、新たな提案が受け付けられると（ステップＳ２３，Ｓ２４）、推奨度ＰＲが再び算出され（ステップＳ２６）、再び算出された推奨度ＰＲが、新たな提案とともに購入側端末１０に送信される（ステップＳ２７）。このように新たな提案が受け付けられたことに応じて推奨度ＰＲが再び算出されて購入側端末１０に送信されることによって、提供者Ｐは、新たな提案をも考慮した推奨度ＰＲに基づいて、より適切なタイミングで商品を購入できるようになる。
【０１１８】
推奨度ＰＲは、たとえば、提案数および閲覧数に基づいて算出される。提案の数が大きいほど、推奨度ＰＲが高くなるように算出される。提案数が大きいほどすでに十分な提案が行われた可能性が高いと考えられるので、この算出手法によれば、十分な提案が行われた可能性が高いほど推奨度ＰＲが大きくなる。また、閲覧数が大きいほど、推奨度ＰＲが高くなるように算出される。閲覧数が大きいほど今後さらに提案が行われる可能性が低いと考えられるので、この算出手法によれば、今後提案が行われる可能性が低いほど推奨度が大きくなる。以上のようにして、推奨度ＰＲを適切に設定することができる。
【０１１９】
また、購入側端末１０では、サーバ１００から送信された推奨度ＰＲおよび提案が受信され（ステップＳ１３）、受信された推奨度ＰＲに応じた態様で、提案が提示される（図１１）。提示態様は、推奨度が高いほど商品の購入を提供者Ｐに強く促すような提示態様とされる。たとえば、推奨度ＰＲが高いほど、要求が表示部１６の上方側の部分に表示されたり、注意を惹きやすい色で表示されたりする。これにより、提供者Ｐは、より適切なタイミングで商品・サービスを購入することができるようになる。
【０１２０】
また、購入側端末１０の表示部１６は、推奨度ＰＲがしきい値以上の場合に所定の通知処理を実行する。たとえば、提案が行われた旨を購入希望者Ｕに通知するためのメッセージが表示される。このように推奨度ＰＲがしきい値以上の場合に購入希望者Ｕへの通知が行われることによって、商品を購入すべき適切なタイミングで、購入希望者Ｕに商品の購入を促すことができる。
【０１２１】
推奨度ＰＲに対するしきい値は、たとえば、コンバージョン率ＣＲが所定値以上になると予測される推奨度ＰＲの大きさに設定される。コンバージョン率ＣＲは、提案が行われた場合に購入希望者Ｕが提案に係る商品を購入することが期待できる期待値であるとも言える。通知処理が実行されることによって、所定値以上のコンバージョン率ＣＲで（つまりある程度の期待値で）、購入希望者Ｕが商品を購入することが期待できる。
【０１２２】
次に、先に説明した図１０のステップＳ２５において実行される処理の一例について、図１２を参照して説明する。この例では、所定のタイミングは、所定の周期に基づくタイミングとされる。なお、図１２に示されるステップＳ２６およびステップＳ２７については先に図１０を参照して説明したのでここでは説明を省略する。
【０１２３】
図１２に示す例では、サーバ１００は、前回の購入推奨度の更新から所定期間以上経過したか否かを判断する（ステップＳ２５１）。図１０に示すようにステップＳ２３〜Ｓ２７の処理は繰り返し実行され得るので、たとえば、前回ステップＳ２６において推奨度ＰＲが算出されたときから所定期間以上経過していると、前回の購入推奨度の更新から所定期間以上経過したと判断される。所定期間は、たとえば２４時間に設定されてよい。前回の購入推奨度の更新から所定期間以上経過した場合（ステップＳ２５１：ＹＥＳ）、サーバ１００は、ステップＳ２６に処理を進める。そうでない場合（ステップＳ２５１：ＮＯ）、サーバ１００は、ステップＳ２３（図１０）に再び処理を戻す。
【０１２４】
先に説明したように推奨度ＰＲは閲覧数等によっても変化するので、たとえば所定期間の間に閲覧数が変化していれば、ステップＳ２６において、前記算出された推奨度ＰＲとは異なる新たな推奨度ＰＲが算出されることとなる。
【０１２５】
図１２のフローチャートによれば、所定の周期で新たな推奨度ＰＲが算出され（ステップＳ２５１：ＹＥＳ、ステップＳ２６）、算出された新たな推奨度ＰＲが、提案とともに購入側端末１０に送信される（ステップＳ２７）。このように所定の周期で新たな推奨度ＰＲが算出されて購入側端末１０に送信されることによって、提供者Ｐは、新しい推奨度ＰＲに基づいて、より適切なタイミングで商品を購入できるようになる。
【符号の説明】
【０１２６】
１…情報処理システム、１０…購入側端末、１２…通信部（受信手段）、１６…表示部（提示手段）、２０…提供側端末、１００…サーバ、１１０…通信部（受付手段、送信手段）、１２０…推奨度算出部（算出手段）、１３５…しきい値設定部（設定手段）、１４０…記憶部（記憶手段）。
【図１】
2017068407.tif 000003
【図２】
2017068407.tif 000004
【図３】
2017068407.tif 000005
【図４】
2017068407.tif 000006
【図５】
2017068407.tif 000007
【図６】
2017068407.tif 000008
【図７】
2017068407.tif 000009
【図８】
2017068407.tif 000010
【図９】
2017068407.tif 000011
【図１０】
2017068407.tif 000012
【図１１】
2017068407.tif 000013
【図１２】
2017068407.tif 000014