(57)【要約】【課題】購入希望者の要求と提供者の提案とをマッチさせる際に、特定の購入希望者の満足度だけが低くなりすぎることを防ぐことが可能な情報処理装置を提供する。【解決手段】サーバ１００は、商品・サービスの購入希望者の購入側端末１０からの要求を受け付ける要求受付手段（通信部１１０）と、通信部１１０より受け付けられた複数の要求のそれぞれについて、各要求の期限に基づく優先度Ｉを算出する算出部１２０と、算出部１２０によって算出された優先度Ｉに基づいて、要求リストＬを生成する要求リスト生成部１３０と、要求リスト生成部１３０により生成された要求リストＬを、商品・サービスの提供者の提供側端末２０に送信するリスト送信手段（通信部１１０）と、を備える。【選択図】図２
2017033160.tif 000002
【特許請求の範囲】
【請求項１】
商品・サービスの購入希望者の購入側端末からの要求を受け付ける要求受付手段と、
前記要求受付手段により受け付けられた複数の要求のそれぞれについて、各要求の期限に基づく優先度を算出する算出手段と、
前記算出手段によって算出された優先度に基づいて、前記複数の要求のリストを生成する生成手段と、
前記生成手段により生成されたリストを、商品・サービスの提供者の提供側端末に送信するリスト送信手段と、
を備える情報処理装置。
【請求項２】
前記算出手段は、前記要求の期限における前記購入希望者の満足度が所定の目標満足度に近づくように、前記優先度を算出する、請求項１に記載の情報処理装置。
【請求項３】
前記要求に対する前記提供側端末からの提案を受け付ける提案受付手段、
をさらに備え、
前記算出手段は、前記提案受付手段によって受け付けられた提案の数に基づいて前記満足度を算出する、請求項２に記載の情報処理装置。
【請求項４】
前記提案受付手段によって受け付けられた提案を前記購入側端末に送信する提案送信手段と、
前記提案に対する前記購入側端末からの評価情報を受け付ける評価情報受付手段と、
をさらに備え、
前記算出手段は、前記提案の数および前記評価情報に基づいて前記満足度を算出する、請求項３に記載の情報処理装置。
【請求項５】
前記要求に対する前記提供側端末からの閲覧情報を受け付ける閲覧情報受付手段、
をさらに備え、
前記算出手段は、前記閲覧情報受付手段によって受け付けられた前記要求の閲覧の回数に対する当該要求への提案の数の割合が小さいほど前記優先度が低くなるように算出する、請求項２〜４のいずれか１項に記載の情報処理装置。
【請求項６】
前記購入希望者に関する情報を記憶する購入希望者情報記憶手段と、
前記提供者に関する情報を記憶する提供者情報記憶手段と、
をさらに備え、
前記算出手段は、前記購入希望者情報記憶手段および前記提供者情報記憶手段に記憶された情報に基づいて定められる前記購入希望者と前記提供者との相性度が高いほど前記優先度が高くなるように、前記優先度を算出する、請求項１〜５のいずれか１項に記載の情報処理装置。
【請求項７】
前記購入希望者に関する情報は、前記購入希望者が商品・サービスの購入を希望する場所の情報を含み、
前記提供者に関する情報は、前記提供者が商品・サービスを提供する場所の情報を含み、
前記相性度は、前記購入希望者が商品・サービスの購入を希望する場所と、前記提供者が商品・サービスを提供する場所との位置関係に基づいて定められる、請求項６に記載の情報処理装置。
【請求項８】
前記相性度が所定レベル以上の要求を抽出する抽出手段、
をさらに備え、
前記生成手段は、前記抽出手段により抽出された要求に基づいて前記リストを生成する、請求項６または７に記載の情報処理装置。
【請求項９】
前記情報処理装置は、さらに、
前記購入側端末を用いた情報処理装置の利用の程度、または前記購入希望者による前記提供者の店舗の利用の程度を示す利用情報を記憶する利用情報記憶手段と、
を備え、
前記算出手段は、前記利用情報記憶手段に記憶された利用情報によって示される利用の程度が高いほど、当該購入側端末からの要求の優先度が高くなるように、前記優先度を算出する、請求項１〜８のいずれか１項に記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に関する。
【背景技術】
【０００２】
従来より、購入希望者の要求に対して提供者が商品を提案するための技術が知られている。たとえば下記特許文献１は、過去の購入履歴等に基づいて新たな商品の提案をすべき見込み顧客を抽出し、リストアップする手法を開示する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−３３４２０１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に記載された手法によれば、提供者は、リストから選択した顧客に対して商品を提案できる。しかしながら、この場合には、次のような問題が生じ得る。
【０００５】
すなわち、複数の要求がリストアップされた場合、たとえば、提供者にとって都合のよい購入希望者（購入実績のある者など）の要求に対して提案が集中してしまう可能性がある。その場合、他の要求に対しては期限までに十分な提案が行われず、そのような十分な提案が行われない要求に係る特定の購入希望者の満足度が低下してしまう。
【０００６】
本発明は、上記課題に鑑みてなされたものであり、特定の購入希望者の満足度だけが低くなりすぎることを防ぐことが可能な情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一態様に係る情報処理装置は、商品・サービスの購入希望者の購入側端末からの要求を受け付ける要求受付手段と、要求受付手段により受け付けられた複数の要求のそれぞれについて、各要求の期限に基づく優先度を算出する算出手段と、算出手段によって算出された優先度に基づいて、複数の要求のリストを生成する生成手段と、生成手段により生成されたリストを、商品・サービスの提供者の提供側端末に送信するリスト送信手段と、を備える。
【０００８】
上記の情報処理装置では、複数の要求のそれぞれについて各要求の期限に基づく優先度が算出され、算出された優先度に基づいて複数の要求のリストが生成される。生成されたリストは提供側端末に送信される。この場合、たとえば、提供側端末において優先度が高い要求に対して提案が行われやすいような態様でリストが生成されるように各優先度を適切に算出することができる。その結果、購入側端末からの要求つまり購入希望者の要求と、提供者の提案とを過不足なくマッチさせることができる。よって、特定の購入希望者の満足度だけが低くなりすぎることを防ぐことが可能になる。
【０００９】
算出手段は、要求の期限における購入希望者の満足度が所定の目標満足度に近づくように、優先度を算出してもよい。これにより、いずれの要求に対しても、要求の期限までに、購入希望者が満足する提案が行われるようにすることができる。
【００１０】
情報処理装置は、要求に対する提供側端末からの提案を受け付ける提案受付手段、をさらに備え、算出手段は、提案受付手段によって受け付けられた提案の数に基づいて満足度を算出してもよい。これにより、いずれの要求に対しても、要求の期限までに、購入希望者が満足する数の提案が行われるようにすることができる。
【００１１】
情報処理装置は、提案受付手段によって受け付けられた提案を購入側端末に送信する提案送信手段と、提案に対する購入側端末からの評価情報を受け付ける評価情報受付手段と、をさらに備え、算出手段は、提案の数および評価情報に基づいて満足度を算出してもよい。これにより、いずれの要求に対しても、要求の期限までに、購入希望者が満足する数および質の提案が行われるようにすることができる。
【００１２】
情報処理装置は、要求に対する提供側端末からの閲覧情報を受け付ける閲覧情報受付手段、をさらに備え、算出手段は、閲覧情報受付手段によって受け付けられた要求の閲覧の回数に対する当該要求への提案の数の割合が小さいほど優先度が低くなるように算出してもよい。これにより、たとえば、閲覧はされたものの要求の内容が特殊すぎるなどの理由で提案の数の少ない要求の優先度を下げることができる。その結果、提案が行われにくい要求の優先度が必要以上に高くなりすぎることを防ぐことができる。
【００１３】
情報処理装置は、購入希望者に関する情報を記憶する購入希望者情報記憶手段と、提供者に関する情報を記憶する提供者情報記憶手段と、をさらに備え、算出手段は、購入希望者情報記憶手段および提供者情報記憶手段に記憶された情報に基づいて定められる購入希望者と提供者との相性度が高いほど優先度が高くなるように、優先度を算出してもよい。これにより、相性の良い提供者によって提案が行われる可能性を高めることができる。
【００１４】
購入希望者に関する情報は、購入希望者が商品・サービスの購入を希望する場所の情報を含み、提供者に関する情報は、提供者が商品・サービスを提供する場所の情報を含み、相性度は、購入希望者が商品・サービスの購入を希望する場所と、提供者が商品・サービスを提供する場所との位置関係に基づいて定められてもよい。これにより、たとえば、購入希望者が商品・サービスの購入を希望する場所（アクセスに便利な場所など）の近くに消費・サービスを提供する場所（店舗など）を有する提供者によって提案が行われる可能性を高めることができる。
【００１５】
情報処理装置は、相性度が所定レベル以上の要求を抽出する抽出手段、をさらに備え、生成手段は、抽出手段により抽出された要求に基づいてリストを生成してもよい。この場合、抽出された要求についてのみリストを生成すればよいので、リストを生成するための計算コストを低減することができる。また、相性度の低い要求をリストに含めないようにすることで、たとえば購入希望者にとって不都合な（たとえば提供者の店舗が遠すぎるなどの）提案が行われることを防ぐことができる。
【００１６】
情報処理装置は、さらに、購入側端末を用いた情報処理装置の利用の程度、または購入希望者による提供者の店舗の利用の程度を示す利用情報を記憶する利用情報記憶手段と、を備え、算出手段は、利用情報記憶手段に記憶された利用情報によって示される利用の程度が高いほど、当該購入側端末からの要求の優先度が高くなるように、優先度を算出してもよい。これにより、購入側端末を用いた情報処理装置の利用に起因する、要求頻度、提案に対する評価の頻度など、または、購入希望者による提供者の店舗の利用に起因する、提案された商品・サービスの購入頻度、来店頻度、購入金額といった利用の程度に基づいて、将来的にも商品・サービスを購入する可能性が高い購入希望者の要求の優先度を高くすることができる。その結果、利用の程度の高い購入希望者の要求の優先度が低くなりすぎることを防ぐことができる。
【発明の効果】
【００１７】
本発明によれば、特定の買い手の満足度だけが低くなりすぎることを防ぐことが可能になる。
【図面の簡単な説明】
【００１８】
【図１】情報処理装置によって実現される情報処理システムの概要を説明するための図である。
【図２】第１実施形態に係る情報処理装置（サーバ）が用いられる情報処理システムの機能ブロックを示す図である。
【図３】要求ＤＢの一例を示す図である。
【図４】提案ＤＢの一例を示す図である。
【図５】提供者ＤＢの一例を示す図である。
【図６】購入希望者ＤＢの一例を示す図である。
【図７】優先度の算出方法を説明するための第１の図である。
【図８】優先度の算出方法を説明するための第２の図である。
【図９】優先度の算出方法を説明するための第３の図である。
【図１０】サーバのハードブロックを示す図である。
【図１１】情報処理システムにおいて実行される処理の一例を示す第１のフローチャートである。
【図１２】購入側端末における表示の一例を示す図である。
【図１３】情報処理システムにおいて実行される処理の一例を示す第２のフローチャートである。
【図１４】情報処理システムにおいて実行される処理の一例を示す第３のフローチャートである。
【図１５】情報処理システムにおいて実行される処理の一例を示す第４のフローチャートである。
【図１６】情報処理システムにおいて実行される処理の一例を示す第５のフローチャートである。
【図１７】提供側端末における表示の一例を示す図である。
【図１８】第２実施形態に係るサーバの機能ブロックを示す図である。
【図１９】図１８のサーバによって実行される処理の一例を示す第１のフローチャートである。
【図２０】図１８のサーバによって実行される処理の一例を示す第２のフローチャートである。
【図２１】図１８のサーバによって実行される処理の一例を示す第２のフローチャートである。
【図２２】第３実施形態に係るサーバの機能ブロックを示す図である。
【図２３】相性度の算出方法を説明するための図である。
【図２４】相性度ＤＢの一例を示す図である。
【図２５】図２２のサーバによって実行される処理の一例を示す第１のフローチャートである。
【図２６】図２２のサーバによって実行される処理の一例を示す第２のフローチャートである。
【図２７】第４実施形態に係るサーバの機能ブロックを示す図である。
【図２８】図２７のサーバによって実行される処理の一例を示すフローチャートである。
【図２９】第５実施形態に係るサーバの機能ブロックを示す図である。
【図３０】図２９に示すサーバによって実行される処理の一例を示す第１のフローチャートである。
【図３１】図２９に示すサーバによって実行される処理の一例を示す第２のフローチャートである。
【図３２】図２９に示すサーバによって実行される処理の一例を示す第２のフローチャートである。
【図３３】図２９に示すサーバによって実行される処理の一例を示す第３のフローチャートである。
【発明を実施するための形態】
【００１９】
以下、本発明の実施形態について、図面を参照しながら説明する。なお、図面の説明において同一要素には同一符号を付し、重複する説明は省略する。
【００２０】
［情報処理装置によって実現される情報処理システムの概要］
はじめに、図１を用いて、各実施形態に係る情報処理装置によって実現される情報処理システムの概要を説明する。この情報処理システム１は、たとえばサーバ１００によって実現され、購入希望者Ｕおよび提供者Ｐによって利用されるシステムである。なお、サーバ１００は、後述の第１実施形態に係るサーバ１００でもある。
【００２１】
購入希望者Ｕは、商品・サービスの購入を希望する消費者であり、サーバ１００と通信可能な購入側端末１０を有している。提供者Ｐは、商品・サービス（以下、単に「商品」とうい場合もある）を提供する販売者であり、サーバ１００と通信可能な提供側端末２０を有している。サーバ１００は、購入希望者Ｕが購入を希望する商品の要求と、その要求に対する提供者Ｐからの商品の提案とをマッチさせる。以下では、購入希望者Ｕが商品の購入を希望する場合について説明し、サービスの購入を希望する場合については説明を省略する。商品の種類はとくに限定されるものではない。本明細書では、商品として衣服を例に挙げて説明する。
【００２２】
情報処理システム１を利用する購入希望者Ｕの数はとくに限定されない。購入希望者Ｕは、１人であってもよいし、複数人であってもよい。図１に示す例では、３人の購入希望者Ｕが情報処理システム１を利用する態様が示される。なお、各購入希望者Ｕを区別し得るように、各購入希望者Ｕには、ＵＡ，ＵＢ，ＵＣの異なる符号も付している。提供者Ｐの数についても同様であり、図１に示す例では、各提供者Ｐには、ＰＡ、ＰＢ，ＰＣの異なる符号も付している。
【００２３】
購入希望者Ｕは、要求を行う。ここでの「要求」は、購入希望者Ｕが購入を希望する商品に対して提供者Ｐから提案が行われることに対する要求である。具体的に、購入希望者Ｕは、購入側端末１０を用いて要求データＲの登録を行う。要求データＲは、購入側端末１０によってサーバ１００に送信される。なお、各購入希望者Ｕの要求に係る要求データＲをそれぞれ区別し得るように、各要求データＲには、ＲＡ，ＲＢ，ＲＣの異なる符号も付している。
【００２４】
サーバ１００は、複数の要求を受け付け（複数の要求データＲを受信し）、要求リストＬを生成する。要求リストＬは、複数の要求で構成されるリストである。要求リストＬは、提供者Ｐごとに生成されてもよい。各要求リストＬは同じ内容であってもよいし、図１に示すように対応する提供者Ｐごとに異なる内容であってもよい。サーバ１００は、生成した各要求リストＬを、対応する提供者Ｐの提供側端末２０にそれぞれ送信する。
【００２５】
図１に示す例では、要求リストＬは、「要求ＩＤ」と、「要求属性」とを対応づけて記述している。「要求ＩＤ」は、各要求を区別するための識別子（ＩＤ：Identifier）である。図１では、理解を容易にするために、要求ＩＤとして、要求データＲＡなどの符号を用いて表している。なお、要求ＩＤとして図示されるもののうち、ＲＸ，ＲＹは、購入希望者ＵＡ，ＵＢ，ＵＣ以外の図示しない他の購入希望者Ｕからの要求に対応する要求ＩＤである。
【００２６】
「要求属性」は、要求ＩＤに対応する要求データＲの具体的な内容を示す。この例では、要求属性は、衣服の種類（シャツ、ポロシャツ、チュニック、長袖、半袖など）、色彩（青、紫、青、ブルー系、チェックなど）、サイズ（Ｍなど）、価格（９０００円など）を用いて表される。なお、各提供者Ｐに対するそれぞれの要求リストＬを区別し得るように、各要求リストＬには、ＬＡ，ＬＢ，ＬＣの異なる符号も付している。要求リストＬＡは提供者ＰＡに提示され、要求リストＬＢは提供者ＰＢに提示され、要求リストＬＣは提供者ＰＣに提示される。
【００２７】
図１に示す例では、要求リストＬにおいて、さらに「優先度」が示されているが、この優先度は、サーバ１００が要求リストＬを生成する際に利用するパラメータであり、要求リストＬが提供者Ｐに提示される際には非表示とされていてよい。図１に示す例では、優先度が高い（値が大きい）要求ＩＤが要求リストＬの上側に位置することによって、提供者Ｐの注意を惹きやすく、提供者Ｐから提案が行われやすい提示態様となっている。
【００２８】
提供者Ｐは、提案を行う。ここでの「提案」は、購入希望者Ｕからの要求に対して行う商品の提案である。提供者Ｐは、サーバ１００から提供側端末２０に送信された要求リストＬを提供側端末２０を用いて参照することによって、要求リストＬ内の任意の要求に対して提案を行い得る。具体的に、提供者Ｐは、提供側端末２０を用いて提案データＦの登録を行う。提案データＦは、提供側端末２０からサーバ１００に送信される。なお、図１に示す例では、提供者ＰＣからの提案データＦとして、ＦＣの異なる符号も付している。
【００２９】
サーバ１００は、提案を受け付け（提案データＦを受信し）、受信した提案データＦを、対応する購入希望者Ｕの購入側端末１０に送信する。図１に示す例では、提供者ＰＣが購入希望者ＵＡの要求（要求ＩＤ：ＲＡ）に対して提案を行うことによって、提案データＦＣが、サーバ１００から購入希望者ＵＲの購入側端末１０に送信される様子が示される。
【００３０】
たとえば以上のようにして、購入希望者Ｕの要求に対して、提供者Ｐからの提案が行われる。後述の各実施形態に係るサーバによれば、購入希望者Ｕの要求に対して購入希望者Ｕが満足できるような提案が提供者Ｐから行われ、それによって、購入希望者Ｕの要求と、提供者Ｐからの提案とがマッチする。
【００３１】
［第１実施形態］
図２は、第１実施形態に係る情報処理装置が用いられる情報処理システムの機能ブロックを示す図である。図２に示すように、情報処理システム１は、購入側端末１０と、サーバ１００と、提供側端末２０とを含む。
【００３２】
まず、購入側端末１０について説明する。購入側端末１０は、通信部１２と、操作部１４と、表示部１６と、制御部１８とを含む。
【００３３】
通信部１２は、後述のサーバ１００の通信部１１０と通信を行う部分である。これにより、購入側端末１０とサーバ１００との通信が可能になる。たとえば、通信部１２は、購入側端末１０からの要求データＲをサーバ１００に送信する。
【００３４】
操作部１４は、購入側端末１０のユーザ、つまり購入希望者Ｕ（図１）によるユーザ操作を受け付ける部分である。たとえば、操作部１４は、要求を行う（要求データＲを登録する）ための操作を受け付ける部分（要求データ登録部）として機能する。操作部１４は、提案に対する評価を行う（評価情報（後述）を登録する）ための操作なども受け付ける。
【００３５】
表示部１６は、購入希望者Ｕに対して種々の情報を提示するための部分である。たとえば、表示部１６は、要求に対して行われた提案の内容を表示する提案商品表示部として機能する。
【００３６】
制御部１８は、購入側端末１０に含まれる各要素を制御することによって購入側端末１０の全体制御を行う部分である。たとえば、購入側端末１０によって情報処理システム１を利用するためのアプリケーションプログラムが、制御部１８によって実行される。
【００３７】
次に、サーバ１００について説明する。サーバ１００は、通信部１１０と、算出部１２０と、要求リスト生成部１３０と、記憶部１４０と、制御部１５０とを含む。
【００３８】
通信部１１０は、購入側端末１０の通信部１２と通信を行う部分である。通信部１１０は、要求データＲを受信することによって、購入側端末１０からの要求を受け付ける部分（要求受付手段）でもある。また、通信部１１０は、要求リストＬを提供側端末２０に送信する部分（リスト送信手段）でもある。また、通信部１１０は、提案データＦを受信することによって、要求に対する提供側端末２０からの提案を受け付ける部分（提案受付手段）でもある。また、通信部１１０は、提案データＦを購入側端末１０に送信することによって、提案を購入側端末１０に送信する部分（提案送信手段）でもある。また、通信部１１０は、評価情報を受信することによって、提案に対する購入側端末１０からの評価情報を受け付ける部分（評価情報受付手段）でもある。また、通信部１１０は、閲覧情報（後述）を受信することによって、要求に対する提供側端末２０からの閲覧情報を受け付ける部分（閲覧情報受付手段）でもある。
【００３９】
算出部１２０は、通信部１１０によって受け付けられた複数の要求のそれぞれについて、優先度Ｉを算出する部分（算出手段）である。優先度Ｉの算出手法については、後に図７〜９を参照して説明する。
【００４０】
要求リスト生成部１３０は、算出部１２０によって算出された優先度Ｉに基づいて要求リストＬを生成する部分（生成手段）である。要求リストＬは、複数の要求を含む。要求リストＬは、たとえば要求の登録が行われたときなどに生成される。また、要求リスト生成部１３０は、新たな要求の登録が行われたときなどに要求リストＬを更新する部分（更新手段）でもある。
【００４１】
記憶部１４０は、サーバ１００によって実行される処理に必要な種々の情報を記憶する部分（記憶手段）である。記憶部１４０は、複数のデータベース（ＤＢ：Data  Base）を含む。本実施形態では、記憶部１４０は、要求ＤＢ１４２と、提案ＤＢ１４４と、提供者ＤＢ１４６と、購入希望者ＤＢ１４８とを含む。要求ＤＢ１４２は、要求に関する情報を記憶する部分（要求情報記憶手段）である。提案ＤＢ１４４は、提案に関する情報を記憶する部分（提案情報記憶手段）である。提供者ＤＢ１４６は、提供者に関する情報を記憶する部分（提供者情報記憶手段）である。購入希望者ＤＢ１４８は、購入希望者に関する情報を記憶する部分（購入希望者情報記憶手段）である。具体的に、図３〜図６を参照して、各ＤＢのそれぞれについて一例を説明する。
【００４２】
まず、図３を参照して、要求ＤＢ１４２の一例について説明する。この例では、要求ＤＢ１４２は、「要求データ」と「要求管理データ」とに大別される。「要求データ」は、先に説明した、購入側端末１０からサーバ１００に送信される要求データＲである。たとえば、購入側端末１０において、要求データＲを入力するための購入希望者Ｕによるユーザ操作を、操作部１４が受け付ける。すると、その情報が、要求データＲとして購入側端末１０からサーバ１００に送信され、要求ＤＢ１４２に登録される。なお、要求ＩＤおよび購入希望者ＩＤは、購入側端末１０あるいはサーバ１００において自動的に付与されてよい。「要求管理データ」は、各要求を管理するためのデータである。
【００４３】
「要求データ」では、「要求ＩＤ」と、「購入希望者ＩＤ」と、「提案期限」と、「購入希望場所」と、「カテゴリ」と、「サイズ」と、「色」と、「価格」とが対応づけて記述される。
【００４４】
「要求ＩＤ」については、先に図１を参照して説明したとおりである。なお、図３に示す例では、要求ＩＤは、図１の例とは異なり、数字の組み合わせ（「００１」など）で表される。
【００４５】
「購入希望者ＩＤ」は、各購入希望者Ｕを区別するための識別子である。図３に示す例では、購入希望者ＩＤは、アルファベットの組み合わせ（「ＵｓｅｒＡ」など）で表される。
【００４６】
「提案期限」は、要求に対して行われる提案の期限である。図３に示す例では、提案期限は、日付および時刻（「２０１５/１/３０  ２０：００」など）で表される。
【００４７】
「希望購入場所」は、購入希望者Ｕが商品の購入を希望する場所である。図３に示す例では、希望購入場所は、地域の名称、都市の名称など（「東京都世田谷区」、「神奈川県川崎市」など）で表される。
【００４８】
「カテゴリ」、「サイズ」、「色」、「価格」は、要求に係る商品の情報である。図３に示す例では、商品の情報は、「Ｓｈｉｒｔ」等のカテゴリ、「Ｌ」等のサイズ、「Ｒｅａｄ」等の色、「５０００円」等の価格で表される。
【００４９】
一方、「要求管理データ」では、「閲覧数」と、「提案数」と、「基礎優先度」と、「優先度差分値」と、「優先度」とが対応づけて記述される。
【００５０】
「閲覧数」は、対応する要求ＩＤに係る要求が、これまでに提供者Ｐによって閲覧された回数である。たとえば、提供側端末２０において、表示部２４に表示された要求リストＬ内のいずれかの要求を閲覧するための提供者Ｐによる操作を、操作部２６が受け付ける。すると、その要求に関する詳細な情報（つまり要求データＲなど）が、表示部２４に表示され、提供者Ｐによって閲覧される。これに応じて、要求が閲覧されたという情報（閲覧情報）が提供側端末２０からサーバ１００に送信され、閲覧数が増加する。
【００５１】
「提案数」は、対応する要求ＩＤに係る要求に対して、これまでに提供者Ｐが行った提案の回数である。提供者Ｐが提案の登録を行うと、提案数は増加する。
【００５２】
「基礎優先度」、「優先度差分値」、「優先度」のうち、「優先度」については、先に説明した優先度Ｉである。「基礎優先度」および「優先度差分値」は、優先度の算出に用いられるパラメータであるが、これについては、後に図７〜９を参照して説明する。
【００５３】
次に、図４を参照して、提案ＤＢ１４４の一例について説明する。この例では、提案ＤＢ１４４は、「提案データ」と、「提案管理データ」とに大別される。「提案データ」は、先に説明した、提供側端末２０からサーバ１００に送信される提案データＦである。たとえば、提供側端末２０において、提案データＦを入力するための提供者Ｐによるユーザ操作を、操作部２６が受け付ける。すると、その情報が、提案データＦとして提供側端末２０からサーバ１００に送信され、提案ＤＢ１４４に登録される。なお、商品ＩＤ、要求ＩＤ、提案日時、提供者ＩＤは、提供側端末２０あるいはサーバ１００において自動的に付与されてよい。「提案管理データ」は、各提案を管理するためのデータである。
【００５４】
「提案データ」では、「商品ＩＤ」と、「要求ＩＤ」と、「提案日時」と、「提供者ＩＤ」と、「カテゴリ」と、「サイズ」と、「色」と、「価格」と、「在庫数」と、「商品画像」とが対応づけて記述される。
【００５５】
「商品ＩＤ」は、各提案に係る商品を区別するための識別子である。図４に示す例では、商品ＩＤは、アルファベットおよび数字の組み合わせ（「Ｐ＿００２」など）で表される。
【００５６】
「要求ＩＤ」については、先に図３を参照して説明したとおりである。
【００５７】
「提案日時」は、提案が行われた日時である。たとえば、サーバ１００が提供側端末２０から提案データＦを受信したタイミングが、提案日時とされる。図４に示す例では、提案日時は、日付および時刻（「２０１５/１/２９  ２０：１２」など）で表される。
【００５８】
「カテゴリ」、「サイズ」、「色」、「価格」は、提案に係る商品の情報であり、先に説明した図３における「カテゴリ」、「サイズ」、「色」、「価格」と同様に表されてよい。
【００５９】
「在庫数」は、提案に係る商品の在庫数である。在庫数は、提供者Ｐの店舗において提案に係る商品の仕入れおよび販売などに応じて増減する。
【００６０】
「商品画像」は、提案に係る商品の画像データである。画像データは、たとえば、提供側端末２０のカメラ（不図示）などを用いて撮像された商品の画像データが、提供側端末２０からサーバ１００に送信されることによって取得される。図４に示す例では、商品画像は、アルファベットを組み合わせたファイル名（「Img_002.jpg」など）で表される。
【００６１】
一方、「提案管理データ」は、「評価」を含む。
【００６２】
「評価」は、対応する商品ＩＤに係る商品に対する購入希望者Ｕの評価、つまり提供者Ｐからの提案に対する購入希望者Ｕの評価の度合いを数値で示したものである。たとえば、購入側端末１０において、表示部１６に表示された提案データＦに対する評価を示す情報（評価情報）を入力するための購入希望者Ｕによる操作を、操作部１４が受け付ける。すると、その評価情報が、購入側端末１０からサーバ１００に送信され、提案ＤＢ１４４に評価が登録される。図４に示す例では、評価は、０〜２の範囲で定められる。たとえば評価が比較的低い場合には評価＝０とされ、評価が比較的高い場合には評価＝２とされてよい。評価が無い場合には、たとえば評価＝１とされてよい。
【００６３】
次に、図５を参照して、提供者ＤＢ１４６の一例について説明する。この例では、提供者ＤＢ１４６は、「提供者ＩＤ」と、「提供場所」と、「提案数」と、「売上数」と、「閲覧数」と、「年齢層」と、「性別」と、「関連ブランド」とを対応づけて記述する。
【００６４】
「提供者ＩＤ」については、先に図４を参照して説明したとおりである。
【００６５】
「提供場所」は、提案に係る商品が提供される場所（たとえば店舗の所在地など）であり、先に説明した図３における「購入希望場所」と同様に表されてよい。
【００６６】
「提案数」は、対応する提供者ＩＤに係る提供者Ｐが、これまでに行った提案の回数の総和である。ここでの提案数には、いずれの要求に対して行われた提案であるかに依らず、すべての提案がカウントされる。たとえば、サーバ１００が提供側端末２０から送信された提案データＦを受信すると、対応する提供者Ｐの提案数が増加する。
【００６７】
「売上数」は、対応する提供者ＩＤに係る提供者Ｐが、情報処理システム１を利用することによって、これまでに販売した商品の総数を示す。たとえば、提供者Ｐが提案した商品を購入希望者Ｕが購入すると、その旨が購入側端末１０および／または提供側端末２０からサーバ１００に通知され、その提供者Ｐの売上数が増加する。
【００６８】
「閲覧数」は、対応する提供者ＩＤに係る提供者Ｐが、これまでに要求を閲覧した回数の総和である。ここでの閲覧数には、いずれの要求に対して行われた閲覧であるかによらず、すべての閲覧がカウントされる。
【００６９】
「年齢層」、「性別」、「関連ブランド」は、提供者Ｐがターゲットとする購入希望者（ターゲット層）の情報である。図５に示す例では、ターゲット層の情報は、「２０〜４０歳」等の年齢層、「Ｍ」等の性別、「Ａブランド、Ｃブランド」等の関連ブランドで表される。関連ブランドは、提供者Ｐが取り扱っている衣服のブランドに関する情報（ブランドの名称など）である。
【００７０】
次に、図６を参照して、購入希望者ＤＢ１４８の一例について説明する。この例では、購入希望者ＤＢ１４８は、「購入希望者ＩＤ」と、「生活圏」と、「要求数」と、「購買数」と、「タイプ」と、「年齢」と、「性別」と、「好きなブランド」と、「ロイヤリティ度」とを対応づけて記述する。
【００７１】
「購入希望者ＩＤ」については、先に図３を参照して説明したとおりである。
【００７２】
「生活圏」は、対応する購入希望者ＩＤに係る購入希望者Ｕの生活圏（たとえば住居のある地域など）であり、先に説明した図３における「購入希望場所」と同様に表されてよい。
【００７３】
「要求数」は、対応する購入希望者ＩＤに係る購入希望者Ｕが、これまでに行った要求の回数である。たとえば購入側端末１０から送信される要求データＲをサーバ１００が受信すると、その購入希望者Ｕの要求数は増加する。
【００７４】
「購買数」は、対応する購入希望者ＩＤに係る購入希望者Ｕが、情報処理システム１を利用（購入側端末１０を用いて要求を行うなど）するによって、これまでに商品の購入を行った回数である。たとえば、提供者Ｐが提案した商品を購入希望者Ｕが購入すると、その旨が購入側端末１０および／または提供側端末２０によってサーバ１００に通知され、その購入希望者Ｕの購買数は増加する。
【００７５】
「タイプ」、「年齢」、「性別」、「好きなブランド」は、購入希望者Ｕの好みに関する情報（嗜好情報）である。図６に示す例では、嗜好情報は、「Ａ」等のタイプ、「３４歳」等の年齢、「Ｍ」等の性別、「Ａブランド」等の好きなブランドで表される。タイプは、たとえばカジュアル、クラシック、ヴィンテージなど、商品の分類を示す。なお、好きなブランドが無い場合にはブランクとされる（図６の例では「−」として示される）。
【００７６】
「ロイヤリティ度」は、購入希望者Ｕの購入側端末１０を用いたサーバ１００の利用情報に基づいて定められる利用の程度を示す指標である。ロイヤリティ度の詳細については、後述の第５実施形態において図２９等を参照して説明する。
【００７７】
なお、以上説明した「要求数」、「購買数」などを含む購入希望者ＤＢ１４８は、購入希望者Ｕの購入側端末１０を用いたサーバ１００の利用情報や、購入希望者Ｕによる提供者Ｐの店舗の利用情報を記憶する部分（利用情報記憶手段）であるとも言える。このため、図６には図示しないが、購入希望者Ｕが要求を行った頻度（要求頻度）、提案された商品を購入した頻度（購入頻度）などを含む購入希望者Ｕによる情報処理システム１の利用頻度の情報は、購入希望者ＤＢ１４８を参照して求めることもできる。また、それらの情報が、利用情報として購入希望者ＤＢ１４８に記憶されていてよい。さらに、購入希望者Ｕが提供者Ｐの店舗に来店した回数（来店回数）およびそれに基づいて求められる来店頻度や、提案に対して行った評価の回数（評価回数）およびそれに基づいて求められる評価頻度も、利用情報として購入希望者ＤＢ１４８に記憶されていてもよい。またさらに、購入希望者Ｕが提案された商品・サービスを購入した際に支払われた購入金額の情報も、利用情報として購入希望者ＤＢ１４８に記憶されていてよい。なお、上述の来店頻度は、情報処理システム１を利用する全ての提供者Ｐに係る全店舗について定められる一つの値であってもよいし、各店舗ごとにそれぞれ定められる複数の値であってもよい。
【００７８】
再び図２に戻り、制御部１５０について説明する。制御部１５０は、サーバ１００に含まれる各要素を制御することによってサーバ１００の全体制御を行う部分である。
【００７９】
先に説明したように、サーバ１００の算出部１２０は、優先度Ｉを算出する。ここで、図７〜図９を参照して、優先度Ｉの算出手法について説明する。優先度Ｉは、要求の期限（図３の「提案期限」）に応じて定められる。
【００８０】
図７は、期限と優先度Ｉとの関係を概念的に示すグラフである。グラフの横軸は時間を示し、縦軸は優先度Ｉを示す。図７において、時刻ｔは現在の時刻である。時刻ｔ１０は、要求が行われた時点（要求データＲが登録された時点）である。時刻ｔ２０は、要求の期限である。図７に示すように、本実施形態では、優先度Ｉは、基礎優先度ＩＥと、優先度差分値Ｓｄｉｆｆとの和、すなわちＩ＝ＩＥ＋Ｓｄｉｆｆとして算出される。
【００８１】
まず、基礎優先度ＩＥについて、図８を参照して説明する。基礎優先度ＩＥは、要求の期限までの残り期間Ｔ（Ｔ＝ｔ２０−ｔ）に応じて変化する。図８に示す例では、残り期間Ｔが短くなるほど、基礎優先度ＩＥは優先度目標値ＩＧに近づくように変化する。優先度目標値ＩＧは、期限（時刻ｔ２０）において目標とする優先度であり、予め定められた任意の値であってよい。基礎優先度ＩＥは、たとえば、ＩＥ＝α（ＩＧ−βＴ）として求めることができる。
【００８２】
この式によれば、βは、残り期間Ｔを適切な大きさに変換するための係数である。βが大きいほどβＴも大きくなり、基礎優先度ＩＥは小さくなる。たとえば、βは、残り期間Ｔにおいて行われることが予測される提案数に比例した値（提案予測係数）とされ得る。βが大きいほど、残り期間Ｔにおいて多くの提案が行われると考えられるので、現時点（時刻ｔ）での基礎優先度ＩＥは、小さくてもよいからである。αは、基礎優先度ＩＥを適切な範囲に変換するための係数（正規化係数）である。基礎優先度ＩＥの適切な範囲は、優先度Ｉ（すなわち基礎優先度ＩＥ＋優先度差分値Ｓｄｉｆｆ）が所定の範囲（たとえば０〜１）に収まるような、基礎優先度ＩＥの範囲である。
【００８３】
次に、優先度差分値Ｓｄｉｆｆについて、図９を参照して説明する。優先度差分値Ｓｄｉｆｆは、提案に対する購入希望者Ｕの満足度に応じて変化する。図９に示す例では、優先度差分値Ｓｄｉｆｆは、期限（時刻ｔ２０）における満足度推定値ＳＡと、満足度目標値ＳＧとの差分として算出される。
【００８４】
満足度推定値ＳＡは、現時点において推定される時刻ｔ２０での満足度の値であり、残り期間Ｔにおいて行われる可能性のある提案を考慮して算出される。たとえば、満足度推定値ＳＡは、現時点（時刻ｔ）においてすでに行われた各提案に対する購入希望者Ｕの満足度の総和を示す総満足度Ｓ（ｔ）と、残り期間Ｔにおいて行われる可能性のある提案によって上昇し得る購入希望者Ｕの満足度の期待値Ｓ´（ｔ）との和、すなわちＳＡ＝Ｓ（ｔ）＋Ｓ´（ｔ）として求めることができる。期待値Ｓ´（ｔ）を総満足度Ｓ（ｔ）に組合せることによって、要求の期限（時刻ｔ２０）における満足度を適切に推定することができる。満足度目標値ＳＧは、要求の期限（時刻ｔ２０）において目標とする満足度（目標満足度）であり、予め定められた任意の値であってよい。優先度差分値Ｓｄｉｆｆは、たとえば、Ｓｄｉｆｆ＝α（ＳＧ−ＳＡ）として求めることができる。
【００８５】
この式によれば、満足度目標値ＳＧと満足度推定値ＳＡとの差分が小さいほど、優先度差分値Ｓｄｉｆｆは小さくなる。要求の期限（時刻ｔ２０）において、満足度目標値ＳＧに近い満足度が得られることが予測されるためである。αは、優先度差分値Ｓｄｉｆｆを適切な範囲に変換するための係数である。優先度差分値Ｓｄｉｆｆの適切な範囲は、優先度Ｉ（すなわち基礎優先度ＩＥ＋優先度差分値Ｓｄｉｆｆ）が所定の範囲（たとえば０〜１）に収まるような、優先度差分値Ｓｄｉｆｆの範囲である。
【００８６】
現時点（時刻ｔ）における購入希望者Ｕの満足度を示す総満足度Ｓ（ｔ）は、現時点での提案数と、各提案への購入希望者Ｕの評価値とに基づいて算出されてよい。これにより、提案の量と質とを考慮して、要求についての現時点での総満足度Ｓ（ｔ）を正確に推定できる。たとえば、現時点までに行われた各提案に、対応する評価値を乗じた値の総和を、総満足度Ｓ（ｔ）として算出してもよい。評価値は、先に図４を参照して説明した「評価」であってよく、その場合、０，１，２のいずれかの値となる。
【００８７】
以上図７〜図９を参照して説明した優先度Ｉの算出手法によれば、要求の期限（時刻ｔ２０）における購入希望者Ｕの満足度が満足度目標値ＳＧに近づくように、優先度Ｉが算出される。その際、現時点における購入希望者Ｕの満足度を示す総満足度ＳＡＴは、現時点までに行われた提案の数（および評価値）に基づいて算出される。
【００８８】
以上図７〜図９を参照して説明した優先度Ｉの算出は、算出部１２０（図２）によって行われる。再び図２に戻り、算出部１２０の詳細について説明する。先に説明したように、算出部１２０は優先度Ｉを算出し、優先度Ｉは基礎優先度ＩＥと優先度差分値Ｓｄｉｆｆとの和として算出される。このため、算出部１２０は、基礎優先度算出部１２２と、優先度差分値算出部１２４とを含む。基礎優先度算出部１２２は、基礎優先度ＩＥを算出する部分である。優先度差分値算出部１２４は、優先度差分値Ｓｄｉｆｆを算出する部分である。基礎優先度ＩＥの算出手法およびＳｄｉｆｆの算出手法については、先に図７〜図９を参照して説明したとおりである。
【００８９】
ここで、図１０を参照して、サーバ１００のハードウェア構成について説明する。図１０に示すように、サーバ１００は、物理的には、１または複数のＣＰＵ（Central  Processing  unit）５１、主記憶装置であるＲＡＭ（Random  Access  Memory）５２およびＲＯＭ（Read  Only  Memory)５３、データ送受信デバイスである通信モジュール５４、半導体メモリなどの補助記憶装置５５、ユーザ操作の入力を受け付ける入力装置５６、ディスプレイといった出力装置５７などを備えるコンピュータとして構成され得る。図２におけるサーバ１００の各機能は、たとえば、ＣＰＵ５１，ＲＡＭ５２などのハードウェア上に１または複数の所定のコンピュータソフトウェアを読み込ませることにより、ＣＰＵ５１の制御のもとで通信モジュール５４、入力装置５６、出力装置５７などを動作させるとともに、ＲＡＭ５２および補助記憶装置５５におけるデータの読み出しおよび書き込みを行うことで実現することができる。
【００９０】
次に、情報処理システム１において実行される処理の一例について、図１１〜図１７を参照して説明する。
【００９１】
図１１は、購入希望者Ｕが要求を行う際に購入側端末１０において実行される処理の一例を示すフローチャートである。
【００９２】
購入側端末１０は、要求データの入力を受け付け（ステップＳ１０）、要求データを送信する（ステップＳ１１）。具体的に、購入側端末１０の操作部１４が購入希望者Ｕのユーザ操作による要求データＲの入力を受け付け、購入側端末１０の通信部１２が、要求データＲをサーバ１００の通信部１１０に送信する。
【００９３】
図１２は、図１１のステップＳ１０におけるユーザ操作のための画面の一例を示す図である。この画面は、購入側端末１０の表示部１６によって表示される。
【００９４】
図１２（ａ）に示すように、購入側端末１０の表示部１６には、複数の衣服の画像が、それを説明する衣服の種類や提供場所を示す文字列（「刺繍ワンピース」、「渋谷」など）とともに表示されている。これらの情報は、これまでに行われた要求に対応する提案に係る提案データＦの内容を表している。購入希望者Ｕが新たな要求を行う場合には、表示部１６の下側の中央部分にあるアイコン（この例では丸で囲まれたシャツの形を示すアイコン）を選択する。
【００９５】
すると、図１２（ｂ）に示すように、購入側端末１０に設けられたカメラ（不図示）が起動する。これにより、カメラを用いて、新たな要求に係る衣服の参考となる画像が取得される。この画像は、要求データＲの一部を構成し得る。
【００９６】
さらに、図１２（ｃ）に示すように、画像に加えて、種々の情報の入力を受け付けるための画面が表示される。この例では、「アイテム」、「色」、「柄」、「サイズ」、「素材」、「コメント」が入力可能となっており、これらの情報も要求データＲに含まれ得る。
【００９７】
たとえば以上のようにして、購入側端末１０において要求データの入力が受け付けられる。
【００９８】
図１３〜図１５は、サーバ１００において実行される処理の一例を示すフローチャートである。
【００９９】
図１３は、サーバ１００が要求データＲの登録を行う際に実行される処理の一例を示すフローチャートである。この処理は、たとえば、先に説明した図１１のステップＳ１１の処理が実行されたことに応じて開始される。
【０１００】
まず、サーバ１００は、要求データを取得する（ステップＳ２０）。具体的に、サーバ１００の通信部１１０が、購入側端末１０から送信される要求データＲを受信する（要求を受け付ける）。
【０１０１】
次に、サーバ１００は、日時を取得する（ステップＳ２１）。たとえば制御部１５０がタイマ機能を有しており、制御部１５０によって現在の日時が取得される。
【０１０２】
次に、サーバ１００は、基礎優先度を算出し（ステップＳ２２）、優先度を算出する（ステップＳ２３）。具体的に、算出部１２０の基礎優先度算出部１２２が、先のステップＳ２０，Ｓ２１で取得された情報に基づいて、先に図７〜図９を参照して説明したように、基礎優先度ＩＥを算出する。また、先に図７〜図９を参照して説明したように優先度差分値Ｓｄｉｆｆが算出され、算出された基礎優先度ＩＥおよび優先度差分値Ｓｄｉｆｆに基づいて優先度Ｉが算出される。
【０１０３】
次に、サーバ１００は、要求ＤＢを更新する（ステップＳ２４）。たとえば制御部１５０が、先のステップＳ２０で取得された要求データＲと、その要求データＲに対応し先のステップＳ２２，Ｓ２３において算出された基礎優先度ＩＥ、優先度差分値Ｓｄｉｆｆおよび優先度Ｉとを要求ＤＢ１４２に追加して格納することによって、要求ＤＢ１４２を更新する。
【０１０４】
ステップＳ２３の処理が完了した後、サーバ１００は、フローチャートの処理を終了する。
【０１０５】
図１３に示すフローチャートによって算出された優先度Ｉは、たとえば、閲覧数や提案数に変化があった場合に更新される。また、優先度Ｉは、閲覧数や提案数に変化がない場合でも定期的（たとえば１回／日）に更新されてよい。
【０１０６】
図１４は、サーバ１００が優先度Ｉを更新する際に実行される処理の一例を示すフローチャートである。
【０１０７】
まず、サーバ１００は、要求データを取得する（ステップＳ３０）。たとえば制御部１５０が、記憶部１４０の要求ＤＢ１４２を参照して要求データＲを取得する。
【０１０８】
次に、先に図１３を参照して説明したステップＳ２１と同様の処理が実行される。すなわち、サーバ１００は、日時を取得する（ステップＳ３１）。
【０１０９】
次に、サーバ１００は、基礎優先度を更新する（ステップＳ３２）。具体的に、算出部１２０の基礎優先度算出部１２２が、先のステップＳ３１で取得された現在の日時に基づいて先に図７〜図８を参照して説明したように基礎優先度ＩＥを再び算出する。そして、たとえば制御部１５０が、記憶部１４０の要求ＤＢ１４２に記憶された基礎優先度ＩＥが、算出した基礎優先度ＩＥとなるように、要求ＤＢ１４２を更新する。
【０１１０】
また、サーバ１００は、優先度差分値を算出する（ステップＳ３３）。具体的に、算出部１２０の優先度差分値算出部１２４が、先に図７〜図９を参照して説明したように、優先度差分値Ｓｄｉｆｆを算出する。
【０１１１】
その後、サーバ１００は、優先度を更新する（ステップＳ３４）。具体的に、算出部１２０が、先のステップＳ３２において更新された基礎優先度ＩＥと、先のステップＳ３３において算出された優先度差分値Ｓｄｉｆｆとに基づいて、新たな優先度Ｉを再び算出する。
【０１１２】
そして、サーバ１００は、要求ＤＢを更新する（ステップＳ３５）。たとえば制御部１５０が、要求ＤＢ１４２に記憶された優先度Ｉが、先のステップＳ３４において算出された優先度Ｉとなるように、要求ＤＢ１４２を更新する。
【０１１３】
ステップＳ３５の処理が完了した後、サーバ１００は、フローチャートの処理を終了する。
【０１１４】
図１３および図１４に示すフローチャートによって算出された優先度Ｉは、提供者Ｐに提示する要求リストＬを生成する際に用いられる。生成された要求リストＬは、提供側端末２０に送信され、提供者Ｐによって閲覧される。
【０１１５】
図１５は、要求リストＬが提供者Ｐによって閲覧される際に実行される処理の一例を示すフローチャートである。
【０１１６】
まず、サーバ１００は、要求データを取得する（ステップＳ４０）。たとえば制御部１５０が、記憶部１４０の要求ＤＢ１４２を参照して要求データＲを取得する。
【０１１７】
次に、サーバ１００は、優先度に基づき要求リストを生成する（ステップＳ４１）。具体的に要求リスト生成部１３０が、先のステップＳ４０において取得された優先度Ｉに基づいて、要求リストＬを生成する。要求リストＬは、提供者Ｐごとに対応して複数生成される。要求リストＬは提供側端末２０の表示部２４によって提供者Ｐに提示されることになるが、このとき、優先度Ｉが高い要求に対して提案が行われやすいような提示態様となるように、要求リストＬが生成される。たとえば、先に図１を参照して説明したような、優先度Ｉが高い要求ほど要求リストＬの上側に位置するような提示態様となるように、要求リストＬが生成される。
【０１１８】
そして、サーバ１００は、要求リストを提供側端末に送信する（ステップＳ４２）。具体的に、サーバ１００の通信部１１０が、先のステップＳ４１において生成された複数の要求リストＬを、対応する提供者Ｐの提供側端末２０の通信部２２にそれぞれ送信する。
【０１１９】
ステップＳ４２の処理が完了した後、サーバ１００は、フローチャートの処理を終了する。
【０１２０】
図１５のフローチャートの処理によれば、優先度Ｉに基づいて、提供者Ｐごとに要求リストＬが生成される。生成された要求リストＬは、対応する提供者Ｐの提供側端末２０にそれぞれ送信される。提供者Ｐは、送信される要求リストＬを見て、適宜提案を行い得る。
【０１２１】
図１６は提供者Ｐが提案を行う際に、提供側端末２０において実行される処理の一例を示すフローチャートである。
【０１２２】
まず、提供側端末２０は、要求リストを取得する（ステップＳ５０）。具体的に、提供側端末２０の通信部２２が、サーバ１００の通信部１１０から送信される要求リストＬを受信する。
【０１２３】
次に、提供側端末２０は、要求リストを表示する（ステップＳ５１）。具体的に、提供側端末２０の表示部２４が、先のステップＳ５０において受信された要求リストＬを表示する。提供者Ｐは、この要求リストＬを見て、適宜提案を行うことになるが、このとき、前述したように、要求リストＬは、優先度Ｉが高い要求に対して提案が行われやすいような提示態様となっている。よって、優先度Ｉが高い要求に対して提案が行われることが期待される。
【０１２４】
そして、提供側端末２０は、要求に対する提案を受け付ける（ステップＳ５２）。具体的に、提案データＦを入力するための提供者Ｐによるユーザ操作を、提供側端末２０の操作部２６が受け付ける。
【０１２５】
次に、提供側端末２０は、提案データをサーバに送信する（ステップＳ５３）。具体的に、提供側端末２０の通信部２２が、サーバ１００の通信部１１０に提案データＦを送信する。なお、提案データＦを受信したサーバ１００は、その旨を、提供側端末２０に通知してもよい。
【０１２６】
ステップＳ５３の処理が完了した後、提供側端末２０はフローチャートの処理を終了する。
【０１２７】
図１７は、図１６のステップＳ５１における要求リストＬの表示の一例を示す図である。要求リストＬは、提供側端末２０の表示部２４によって表示される。
【０１２８】
図１７に示すように、表示部２４には、複数の衣服の画像が、それを説明する衣服の種類、購入希望場所や要求の期限を示す文字列（「スカート」、「渋谷」、「今日」など）とともに表示されている。図１７に示す例では、先に図１２を参照して説明した新たな要求の優先度Ｉが高くなっており、その結果、当該要求に係る衣服の画像およびそれを説明する文字列が、提供者Ｐの注意を惹きやすいように、表示部２４の左上に表示されている。なお、たとえば、表示部２４において、検索式（「カジュアル×渋谷」など）による検索、あるいは、並び替え（「提案数が多い順」など）などの操作が行われてもよい。
【０１２９】
次に、サーバ１００の作用効果について説明する。
【０１３０】
サーバ１００によれば、複数の要求（要求データＲ）のそれぞれについて各要求の期限に基づく優先度Ｉが算出（または更新）され（ステップＳ２３，Ｓ３４）、算出された優先度Ｉに基づいて要求リストＬが生成される（ステップＳ４１）。たとえば、要求リストＬは、優先度Ｉが高い要求ＩＤが要求リストＬの上側に位置することによって、提供者Ｐの注意を惹きやすく、提供者Ｐから提案が行われやすい提示態様となっている（図１７）。優先度Ｉは各要求の期限に基づいて算出されているので、期限までに各要求に対して十分な提案が行われるように、購入側端末１０からの購入希望者Ｕの要求と、提供側端末２０からの提供者Ｐの提案とを過不足なくマッチさせることができる。よって、特定の購入者の満足度だけが低くなりすぎることを防ぐことが可能になる。
【０１３１】
とくに、先に図１３を参照して説明したように、優先度Ｉは、たとえば閲覧数や提案数に変化があった場合に更新されたり、定期的に更新されたりするので、都度、優先度Ｉが適切な値となるように再び算出されて更新される。したがって、購入側端末１０からの購入希望者Ｕの要求と、提供側端末２０からの提供者Ｐの提案とをより適切に過不足なくマッチさせることができる。
【０１３２】
算出部１２０は、要求の期限（ｔ２０）における購入希望者Ｕの満足度が満足度目標値ＳＧに近づくように優先度Ｉを算出する（図９）。これにより、いずれの要求に対しても要求の期限（ｔ２０）までに、購入希望者Ｕが満足する提案が行われるようにすることができる。
【０１３３】
算出部１２０は、提案の数（および評価情報）に基づいて満足度を算出する。具体的に、先に図９を参照して説明したように、現時点（時刻ｔ）における購入希望者Ｕの満足度を示す総満足度Ｓ（ｔ）が、現時点での提案数と、各提案への購入希望者Ｕの評価値とに基づいて算出される。そのような満足度が反映された優先度Ｉに基づいて要求リストＬが生成されることによって、たとえば満足度が低い要求の優先度Ｉは相対的に高くなり提案を受けやすくなる。その結果、いずれの要求に対しても、要求の期限までに、購入希望者Ｕが希望する数（および質）の提案が行われるようにすることができる。
【０１３４】
［第２実施形態］
図１８は、第２実施形態に係る情報処理装置としてのサーバ１００Ａの機能ブロックを示す図である。サーバ１００Ａは、サーバ１００（図２）と比較して、算出部１２０に代えて算出部１２０Ａを含む点において相違する。
【０１３５】
算出部１２０Ａは、算出部１２０（図２）と比較して、さらに、要求評価値算出部１２６を含む点において相違する。
【０１３６】
要求評価値算出部１２６は、要求評価値ＲＶを算出する部分である。要求評価値ＲＶは、要求に対してどの程度提案が行われたかを評価するための指標である。要求評価値ＲＶは、基礎優先度算出部１２２によって算出された基礎優先度ＩＥと優先度差分値算出部１２４によって算出された優先度差分値Ｓｄｉｆｆとに基づいて算出された優先度Ｉ（Ｉ＝ＩＥ＋Ｓｄｉｆｆ）を補正するためのパラメータとして用いられる。たとえば、要求評価値ＲＶを（ＩＥ＋Ｓｄｉｆｆ）に乗ずることによって、優先度Ｉを補正することができる。その場合、優先度Ｉは、Ｉ＝（ＩＥ＋Ｓｄｉｆｆ）×ＲＶとして算出される。たとえば、要求評価値ＲＶは０〜１の範囲とされ、要求評価値ＲＶが小さいほど優先度Ｉが低くなる。
【０１３７】
要求評価値ＲＶは、要求を閲覧した提供者Ｐの数と、当該要求に対して提案を行った提供者Ｐの数とに基づいて算出される。要求を閲覧した提供者Ｐの数および当該要求に対して提案を行った提供者Ｐの数は、先に図３を参照して説明した要求ＤＢ１４２の「閲覧数」および「提案数」であってよい。具体的に、要求評価値ＲＶは、要求の閲覧の回数に対する当該要求への提案の数の割合が小さいほど優先度Ｉが低くなるように定められる。そのような要求評価値ＲＶは、たとえば、提案数を閲覧数で除し、所定の係数を乗じることによって算出されてよい。
【０１３８】
なお、要求評価値ＲＶの算出において、さらに、全ての提供者Ｐの数が考慮されてもよい。全ての提供者Ｐの数は、情報処理システム１（図１，２）を利用する提供者Ｐの総数である。たとえば、要求を閲覧した提供者Ｐの数が、提供者Ｐの総数に対して所定の割合以上であれば、サンプル数は十分であり、上述のようにして算出された要求評価値ＲＶの信頼性は比較的高いと考えられる。そのような場合には、要求評価値ＲＶによる補正を行うとよい。一方で、要求を閲覧した提供者Ｐの数が、提供者Ｐの総数に対して所定の割合未満であれば、サンプル数が少なく、上述のようにして算出された要求評価値ＲＶの信頼性は比較的低いと考えられる。そのような場合には、要求評価値ＲＶによる補正を行うことなく、優先度Ｉを算出してよい。
【０１３９】
図１９〜図２１は、サーバ１００Ａにおいて実行される処理の一例を示すフローチャートである。
【０１４０】
図１９は、サーバ１００Ａが要求データＲの登録を行う際に実行される処理の一例を示すフローチャートである。このフローチャートでは、先に説明した図１３のフローチャートの処理と同様の処理が実行される。すなわち、サーバ１００Ａは、要求データを取得し（ステップＳ６０）、日時を取得し（ステップＳ６１）、基礎優先度を算出し（ステップＳ６２）、優先度を算出し（ステップＳ６３）、要求ＤＢを更新する（ステップＳ６４）。ステップＳ６４の処理が完了した後、サーバ１００Ａは、フローチャートの処理を終了する。
【０１４１】
図２０は、サーバ１００Ａが優先度Ｉを更新する際に実行される処理の一例を示すフローチャートである。
【０１４２】
まず、ステップＳ７０〜ステップＳ７３において、先に図１４を参照して説明したステップＳ３０〜Ｓ３３と同様の処理が実行される。すなわち、サーバ１００Ａは、要求データを取得し（ステップＳ７０）、日時を取得し（ステップＳ７１）、基礎優先度を更新し（ステップＳ７２）、優先度差分値を算出する（ステップＳ７３）。
【０１４３】
次に、サーバ１００Ａは、要求評価値を算出する（ステップＳ７４）。具体的に、要求評価値算出部１２６が、たとえば要求ＤＢ１４２を参照し、閲覧数および提案数に基づいて、要求評価値ＲＶを算出する。
【０１４４】
次に、サーバ１００Ａは、優先度を更新する（ステップＳ７５）。具体的に、算出部１２０が、先のステップＳ７２において更新された基礎優先度ＩＥと、先のステップＳ７３において算出された優先度差分値Ｓｄｉｆｆとに基づいて優先度Ｉを求め、その優先度Ｉをさらに先のステップＳ７４において算出された要求評価値ＲＶで補正した値を、新たな優先度Ｉとして算出する。
【０１４５】
その後、Ｓ７６において、先に図１４を参照して説明したステップＳ３５と同様の処理が実行される。すなわち、サーバ１００Ａは、要求ＤＢを更新する（ステップＳ７６）。
【０１４６】
ステップＳ７６の処理が完了した後、サーバ１００Ａは、フローチャートの処理を終了する。
【０１４７】
図２１は、要求リストＬが提供者Ｐによって閲覧される際に実行される処理の一例を示すフローチャートである。このフローチャートでは、先に説明した図１５のフローチャートの処理と同様の処理が実行される。すなわち、サーバ１００Ａは、要求データを取得し（ステップＳ８０）、優先度に基づき要求リストを生成し（ステップＳ８１）、要求リストを提供側端末に送信する（ステップＳ８２）。ステップＳ８２の処理が完了した後、サーバ１００Ａは、フローチャートの処理を終了する。
【０１４８】
以上説明したように、サーバ１００Ａによれば、要求評価値ＲＶを算出することによって、たとえば、要求の閲覧の回数に対する当該要求への提案の数の割合が小さいほど優先度Ｉが低くなるように算出する（ステップＳ７４，Ｓ７５）。これにより、たとえば、閲覧はされたものの要求の内容が特殊すぎるなどの理由で提案の数の少ない要求の優先度Ｉを下げることができる。その結果、提案が行われにくい要求の優先度Ｉが必要以上に高くなりすぎることを防ぐことができる。
【０１４９】
［第３実施形態］
図２２は、第３実施形態に係る情報処理装置としてのサーバ１００Ｂの機能ブロックを示す図である。サーバ１００Ｂは、サーバ１００（図２）と比較して、算出部１２０に代えて算出部１２０Ｂを含む点、および記憶部１４０に代えて記憶部１４０Ｂを含む点において相違する。
【０１５０】
算出部１２０Ｂは、算出部１２０（図２）と比較して、さらに、相性度算出部１２８を含む点において相違する。
【０１５１】
相性度算出部１２８は、相性度Ｃを算出する部分である。相性度Ｃは、購入希望者Ｕと提供者Ｐとの相性の程度を示す指標である。相性度Ｃは、基礎優先度算出部１２２によって算出された基礎優先度ＩＥと優先度差分値算出部１２４によって算出された優先度差分値Ｓｄｉｆｆとに基づいて算出された優先度Ｉ（Ｉ＝ＩＥ＋Ｓｄｉｆｆ）を補正するためのパラメータとして用いられる。たとえば、相性度Ｃを（ＩＥ＋Ｓｄｉｆｆ）に加算することによって、優先度Ｉを補正することができる。その場合、優先度Ｉは、Ｉ＝（ＩＥ＋Ｓｄｉｆｆ）＋Ｃとして算出される。つまり、相性度Ｃが高くほど、優先度Ｉも高くなる。
【０１５２】
相性度Ｃは、購入希望者Ｕの属性や趣味嗜好と、提供者Ｐとの相性を考慮して定められてよい。購入希望者Ｕの属性は、年齢や性別であり、たとえば購入希望者ＤＢ１４８（図６）における「年齢」、「性別」であってよい。購入希望者Ｕの趣味嗜好は、購入希望者Ｕの購入履歴や購入希望者Ｕの入力により得られた商品属性であってよい。購入希望者Ｕの購入履歴は、購入希望者ＤＢ１４８（図６）における「購買数」およびその具体的な内容（購買の対象となった商品および商品に関する情報など）であってよい。購入希望者Ｕの入力により得られた商品属性は、たとえば購入希望者ＤＢ１４８（図６）における「タイプ」や「好きなブランド」であってよく、それ以外にも、「色」、「カテゴリ」、「素材」、「価格」などが含まれてよい。購入希望者Ｕの属性や趣味嗜好と提供者Ｐとの相性は、提供者Ｐのターゲット層との比較により定められてよい。提供者Ｐのターゲット層は、たとえば提供者ＤＢ１４６（図５）における「年齢層」、「性別」、「関連ブランド」であってよい。購入希望者Ｕの属性の内容と提供者Ｐのターゲット層の内容が近いほど、相性度Ｃは高くなるように算出される。相性度Ｃは、属性や趣味嗜好が変更された場合には変化し得る。
【０１５３】
ここで、一例として、商品属性のうちの好きなブランドに基づいて相性度Ｃを算出する場合について、図２３を用いて説明する。図２３に示すグラフの横軸は、購入希望者Ｕの好きなブランド（図６）と提供者Ｐの関連ブランド（図５）とが一致した数（ブランド一致数）Ｎを示す。縦軸は、相性度を示す。この例では、ブランド一致数Ｎが大きくなるにつれて相性度Ｃが大きくなる。そのような相性度Ｃは、たとえば、Ｃ＝γＮとして算出される。γは、適切な範囲の相性度Ｃを算出するための比例係数である。適切な範囲の相性度Ｃは、たとえば、優先度Ｉ（すなわち基礎優先度ＩＥ＋優先度差分値Ｓｄｉｆｆ＋相性度Ｃ）が所定の範囲（たとえば０〜１）に納まるような、相性度Ｃである。
【０１５４】
また、相性度Ｃは、購入希望者Ｕが商品の購入を希望する場所（購入希望場所）と、提供者Ｐが商品を提供する場所（提供場所）との位置関係に基づいて定められてもよい。購入希望場所は、たとえば購入希望者ＤＢ１４８（図６）における「生活圏」であってよい。購入希望者Ｕの生活圏は、たとえば購入側端末１０の移動履歴に基づいて推定されてもよい。移動履歴は、たとえば購入側端末１０に備えられた図示しないＧＰＳ（Global  Positioning  System）センサなどを用いて取得され得る。また、購入希望場所は、要求ごとに購入希望者Ｕが指定した場所であってもよい。その場合、エリア名、座標、駅などを用いて購入希望場所が指定されてもよいし、購入側端末１０の現在地が購入希望場所として指定されてもよい。提供場所は、たとえば提供者ＤＢ１４６（図５）における「提供場所」であってよい。
【０１５５】
購入希望場所と提供場所との位置関係は、たとえば、両者を地図上で直線的に結んだ距離に基づいて定められても良く、実際の経路における距離に基づいて定められてもよい。たとえば距離が短いほど、相性度Ｃは高くなる。あるいは、位置関係は、購入希望場所と提供場所との間を公共機関や自動車などを利用して移動した場合に要する時間（所要時間）に基づいて定められてもよい。たとえば所要時間が短いほど、相性度Ｃは高くなる。また、位置関係は、エリア名の一致・不一致に基づいて定められてもよい。たとえばエリア名が一致する場合に、相性度Ｃは高くなる。
【０１５６】
なお、相性度Ｃは、上述した、購入希望者Ｕの属性・趣味嗜好と提供者Ｐとの相性、および、購入希望場所と提供場所との位置関係の組み合わせに基づいて定められてもよい。
【０１５７】
再び図２２に戻り、記憶部１４０Ｂについて説明する。記憶部１４０Ｂは、記憶部１４０（図２）と比較して、さらに相性度ＤＢ１４１を含む点において相違する。
【０１５８】
具体的に、図２４を参照して、相性度ＤＢ１４１の一例について説明する。この例では、相性度ＤＢ１４１は、「購入希望者ＩＤ」と、「提供者ＩＤ」と、「相性度」とを対応づけて記述している。
【０１５９】
「購入希望者ＩＤ」および「提供者ＩＤ」については、先に図３および図４を参照して説明したとおりである。
【０１６０】
「相性度」は、対応する購入希望者ＩＤに係る購入希望者Ｕと、対応する提供者ＩＤに係る提供者Ｐとの相性度Ｃを示す。
【０１６１】
図２５および図２６は、サーバ１００Ｂにおいて実行される処理の一例を示すフローチャートである。
【０１６２】
図２５は、サーバ１００Ｂが相性度Ｃを算出する際に実行される処理であり、定期的（たとえば１回／日）に実行され得る。
【０１６３】
まず、サーバ１００Ｂは、購入希望者データを取得する（ステップＳ９０）。たとえば制御部１５０が、購入希望者ＤＢ１４８を参照して、購入希望者Ｕの属性や趣味嗜好の情報（図６の「タイプ」、「年齢」、「性別」、「好きなブランド」など）を取得する。
【０１６４】
次に、サーバ１００Ｂは、提供者データを取得する（ステップＳ９１）。たとえば制御部１５０が、提供者ＤＢ１４６を参照して、提供者Ｐのターゲット層の情報（図５の「年齢層」、「性別」、「関連ブランド」など）を取得する。
【０１６５】
次に、サーバ１００Ｂは、相性度を算出する（ステップＳ９２）。具体的に、相性度算出部１２８が、先のステップＳ９０およびステップＳ９１において取得された各情報に基づいて相性度Ｃを算出する。
【０１６６】
そして、サーバ１００Ｂは、相性度ＤＢを更新する（ステップＳ９３）。たとえば制御部１５０が、相性度ＤＢ１４１に記憶された相性度Ｃが、先のステップＳ９２において算出された相性度Ｃとなるように、相性度ＤＢ１４１を更新する。
【０１６７】
ステップＳ９２の処理が完了した後、サーバ１００Ｂは、フローチャートの処理を終了する。
【０１６８】
図２６は、要求リストＬが提供者Ｐによって閲覧される際に実行される処理の一例を示すフローチャートである。
【０１６９】
まず、ステップＳ１００において、先に図１５を参照して説明したステップＳ４０と同様の処理が実行される。すなわち、サーバ１００Ｂは、要求データを取得する（ステップＳ１００）。
【０１７０】
次に、サーバ１００Ｂは、相性度を取得する（ステップＳ１０１）。たとえば制御部１５０が、記憶部１４０の相性度ＤＢ１４１を参照して相性度Ｃを取得する。
【０１７１】
次に、サーバ１００Ｂは、優先度を算出する（ステップＳ１０２）。たとえば制御部１５０が要求ＤＢ１４２を参照して優先度Ｉを取得する。そして、取得された優先度Ｉに先のステップＳ１０１において取得された相性度Ｃを加算することによって、新たな優先度Ｉが算出される。
【０１７２】
次に、サーバ１００Ｂは、優先度に基づき要求リストを生成する（ステップＳ１０３）。ここで、相性度Ｃは、購入希望者Ｕと提供者Ｐとの組合せについてそれぞれ算出されるので（図２４）、たとえば先に図１を参照して説明したように、各提供者Ｐ（ＰＡ，ＰＢ，ＰＣ）に対応して異なる内容の要求リストＬ（ＬＡ、ＬＢ，ＬＣ）が生成され得る。
【０１７３】
そして、先に図１５を参照して説明したステップＳ４２と同様の処理が実行される。すなわち、サーバ１００Ｂは、要求リストを提供側端末に送信する（ステップＳ１０４）。
【０１７４】
ステップＳ４２の処理が完了した後、サーバ１００Ｂは、フローチャートの処理を終了する。
【０１７５】
以上説明したように、サーバ１００Ｂによれば、購入希望者Ｕと提供者Ｐとの相性度Ｃを算出し（ステップＳ９２）、相性度Ｃが高いほど優先度Ｉが高くなるように、優先度Ｉを算出する（ステップＳ１０２）。たとえば、購入希望者Ｕの好きなブランド（図６）と提供者Ｐの関連ブランド（図５）とが一致した数（ブランド一致数）Ｎが大きくなるにつれて相性度Ｃが大きくなるように相性度ＣをＣ＝γＮとして算出し、優先度Ｉを、Ｉ＝（ＩＥ＋Ｓｄｉｆｆ）＋Ｃとして算出する。相性度Ｃは、購入希望者Ｕと提供者Ｐとの組合せについてそれぞれ算出されるので、提供者Ｐごとに対応して異なる内容の要求リストＬが生成され得る。これにより、購入希望者Ｕの提案に対して、当該購入希望者Ｕと相性のよい提供者Ｐによって提案が行われる可能性を高めることができる。
【０１７６】
また、相性度Ｃは、購入希望者Ｕが商品の購入を希望する場所と、提供者Ｐが商品を提供する場所との位置関係に基づいて定められてもよく、その場合には、たとえば、購入希望者Ｕが商品の購入を希望する場所（アクセスに便利な場所など）の近くに商品を提供する場所（店舗など）を有する提供者Ｐによって提案が行われる可能性を高めることができる。
【０１７７】
［第４実施形態］
図２７は、第４実施形態に係る情報処理装置としてのサーバ１００Ｃの機能ブロックを示す図である。サーバ１００Ｃは、サーバ１００Ｂ（図２２）と比較して、さらに、購入希望者抽出部１６０を含む点において相違する。
【０１７８】
購入希望者抽出部１６０は、相性度算出部１２８によって算出された相性度Ｃが閾値（所定レベル）以上の要求を抽出する部分（抽出手段）である。相性度Ｃに対する閾値は、予め定められた値に設定されてもよい。
【０１７９】
また、購入希望者抽出部１６０は、算出部１２０によって算出された優先度Ｉが高いものから上位Ｎ個の要求データＲを抽出してもよい。Ｎは予め定められた２以上の整数であってよい。
【０１８０】
図２８は、要求リストＬが提供者Ｐによって閲覧される際にサーバ１００Ｃにおいて実行される処理の一例を示すフローチャートである。
【０１８１】
まず、サーバ１００Ｃは、相性度Ｃが閾値以上の購入希望者を抽出する（ステップＳ１１０）。具体的に、購入希望者抽出部１６０が、相性度ＤＢ１４１を参照して、相性度Ｃが閾値以上の購入希望者ＩＤおよび提供者ＩＤの組み合わせに対応した要求データＲを抽出する。
【０１８２】
次に、サーバ１００Ｃは、抽出された購入希望者の要求の中で優先度が上位Ｎ個の要求データを取得（抽出）する（ステップＳ１１１）。具体的に、購入希望者抽出部１６０が、要求ＤＢ１４２を参照し、先のステップＳ１１０において抽出された要求データＲのうち、さらに、上位Ｎ個の優先度Ｉが高い要求データＲを抽出する。なお、先のステップＳ１１０の処理が完了した後、このステップＳ１１１がスキップされて、次のステップＳ１１２に処理が進められてもよい。
【０１８３】
そして、サーバ１００Ｃは、優先度に基づき要求リストを生成する（ステップＳ１１１）。すなわち、要求リスト生成部１３０が、先のステップＳ１１０、あるいはステップＳ１１０およびＳ１１１において抽出された要求データＲに係る要求についての要求リストＬを生成する。
【０１８４】
その後、先に図１５を参照して説明したステップＳ４２と同様の処理が実行される。すなわち、サーバ１００Ｃは、要求リストを提供側端末に送信する（ステップＳ１１２）。
【０１８５】
ステップＳ１１２の処理が完了した後、サーバ１００Ｃは、フローチャートの処理を終了する。
【０１８６】
以上説明したように、サーバ１００Ｃによれば、相性度Ｃが閾値以上の要求を抽出し（ステップＳ１１０）、抽出した要求に基づいて要求リストＬが生成される（ステップＳ１１２）。この場合、抽出された要求についてのみ要求リストＬを生成すればよいので、要求リストＬを生成するための計算コストを低減することができる。また、相性度Ｃの低い要求を要求リストＬに含めないようにすることで、たとえば購入希望者にとって不都合な（たとえば提供者の店舗が遠すぎるなどの）提案が行われることを防ぐことができる。
【０１８７】
また、上述のステップＳ１１１の処理が実行される場合には、要求リストＬの対象となる要求の数を確実にＮ個以下にすることができるので、要求リストＬを生成するための計算コストをより確実に低減できる。
【０１８８】
［第５実施形態］
図２９は、第５実施形態に係る情報処理装置としてのサーバ１００Ｄの機能ブロックを示す図である。サーバ１００Ｄは、サーバ１００（図２）と比較して、算出部１２０に代えて算出部１２０Ｄを含む点、および、さらに購入希望者抽出部１６０を含む点において相違する。購入希望者抽出部１６０については先に図２７を参照して説明したので、ここでは説明を省略する。
【０１８９】
算出部１２０Ｄは、算出部１２０（図２）と比較して、さらに、ロイヤリティ算出部１２１を含む点において相違する。
【０１９０】
ロイヤリティ算出部１２１は、ロイヤリティ度ＣＲを算出する部分である。ロイヤリティ度ＣＲは、先に図６を参照して説明したように、購入希望者Ｕの購入側端末１０を用いたサーバ１００の利用情報や、購入希望者Ｕによる提供者Ｐの店舗の利用情報に基づいて定められる利用の程度を示す指標である。ロイヤリティ度ＣＲは、購入希望者ＤＢ１４８に記憶された利用情報に基づいて定められる。
【０１９１】
ロイヤリティ度ＣＲは、基礎優先度算出部１２２によって算出された基礎優先度ＩＥと優先度差分値算出部１２４によって算出された優先度差分値Ｓｄｉｆｆとに基づいて算出された優先度Ｉ（Ｉ＝ＩＥ＋Ｓｄｉｆｆ）を補正するためのパラメータとして用いられる。たとえば、ロイヤリティ度ＣＲを（ＩＥ＋Ｓｄｉｆｆ）に加算することによって、優先度Ｉを補正することができる。その場合、優先度Ｉは、Ｉ＝（ＩＥ＋Ｓｄｉｆｆ）＋ＣＲとして算出される。つまり、ロイヤリティ度ＣＲが高いほど、その購入希望者Ｕの購入側端末１０からの要求の優先度Ｉが高くなる。
【０１９２】
ロイヤリティ度ＣＲは、たとえば先に図６を参照して説明したように、購入希望者Ｕの要求を行う頻度（要求頻度）、提案された商品を購入した頻度（購入頻度）、提供者Ｐの店舗へ来店した頻度（来店頻度）、提案に対して行った評価の頻度（評価頻度）、および購入金額の少なくとも一つに基づいて算出されてよい。たとえば、要求頻度、購入頻度、評価頻度が高くなったり、購入金額が大きくなったりするほど、ロイヤリティ度ＣＲも高く成り得る。なお、前述のように、来店頻度は店舗ごとに定められてもよく、その場合には、たとえば、店舗に係る提供者Ｐごとに異なるロイヤリティ度ＣＲが算出される。その場合、提供者Ｐごとに異なる優先度Ｉが算出されるので、各提供者Ｐ（たとえば図１のＰＡ，ＰＢ，ＰＣ）に対して異なる要求リストＬ（たとえば図１のＬＡ，ＬＢ，ＬＣ）が生成され得る。
【０１９３】
図３０〜図３３は、サーバ１００Ｄにおいて実行される処理の一例を示すフローチャートである。
【０１９４】
図３０は、サーバ１００Ｄが要求データＲの登録を行う際に実行される処理の一例を示すフローチャートである。このフローチャートでは、先に説明した図１３のフローチャートの処理と同様の処理が実行される。すなわちサーバ１００Ｄは、要求データを取得し（ステップＳ１２０）、日時を取得し（ステップＳ１２１）、基礎優先度を算出し（ステップＳ１２２）、優先度を算出し（ステップＳ１２３）、要求ＤＢを更新する（ステップＳ１２４）。ステップＳ１２４の処理が完了した後、サーバ１００Ｄは、フローチャートの処理を完了する。
【０１９５】
図３１は、サーバ１００Ｄがロイヤリティ度ＣＲを算出する際に実行される処理であり、定期的（たとえば１回／日）に実行され得る。
【０１９６】
まず、サーバ１００Ｄは、購入希望者データを取得する（ステップＳ１３０）。たとえば制御部１５０が、購入希望者ＤＢ１４８を参照して履歴情報（たとえば「要求数」、「購買数」など）を取得する。
【０１９７】
次に、サーバ１００Ｄは、ロイヤリティ度を算出する（ステップＳ１３１）。具体的に、ロイヤリティ算出部１２１が、先のステップＳ１３０において取得された購入希望者データに基づいて、ロイヤリティ度ＣＲを算出する。
【０１９８】
そして、サーバ１００Ｄは、購入希望者ＤＢを更新する（ステップＳ１３２）。たとえば制御部１５０が、購入希望者ＤＢ１４８に記憶されたロイヤリティ度ＣＲが、先のステップＳ１３１において算出されたロイヤリティ度ＣＲとなるように、購入希望者ＤＢ１４８を更新する。
【０１９９】
ステップＳ１３２の処理が完了した後、サーバ１００Ｄは、フローチャートの処理を終了する。
【０２００】
図３２は、サーバ１００Ｄが優先度Ｉを更新する際に実行される処理の一例を示すフローチャートである。
【０２０１】
まず、ステップＳ１４０〜Ｓ１４３において、先に図１４を参照して説明したステップＳ３０〜Ｓ３３の処理が実行される。すなわち、サーバ１００Ｄは、要求データを取得し（ステップＳ１４０）、日時を取得し（ステップＳ１４１）、基礎優先度を更新し（ステップＳ１４２）、優先度差分値を算出する（ステップＳ１４３）。
【０２０２】
次に、サーバ１００Ｄは、ロイヤリティ度を取得する（ステップＳ１４４）。たとえば制御部１５０が、購入希望者ＤＢ１４８を参照してロイヤリティ度ＣＲを取得する。
【０２０３】
そして、サーバ１００は、優先度を更新する（ステップＳ１４５）。具体的に、算出部１２０が、先のステップＳ１４２において更新された基礎優先度ＩＥと、先のステップＳ１４３において算出された優先度差分値Ｓｄｉｆｆと、先のステップＳ１４４において取得されたロイヤリティ度ＣＲとに基づいて、新たな優先度Ｉを算出する。
【０２０４】
その後、先に図１４を参照して説明したステップＳ３５と同様の処理が実行される。すなわち、サーバ１００Ｄは、要求ＤＢを更新する（ステップＳ１４６）。
【０２０５】
ステップＳ１４６の処理が完了した後、サーバ１００Ｄは、フローチャートの処理を終了する。
【０２０６】
図３３は、要求リストＬが提供者Ｐによって閲覧される際に実行される処理の一例を示すフローチャートである。
【０２０７】
まず、サーバ１００Ｄは、優先度が高いＮ個の要求データを取得する（ステップＳ１５０）。具体的に、購入希望者抽出部１６０が、要求ＤＢ１４２を参照し、上位Ｎ個の優先度Ｉが高い要求データＲを抽出する。なお、このステップＳ１５０はスキップされて、次のステップＳ１５１に処理が進められてもよい。
【０２０８】
次に、サーバ１００Ｄは、ロイヤリティ度を取得する（ステップＳ１５１）。たとえば制御部１５０が購入希望者ＤＢ１４８を参照し、ロイヤリティ度ＣＲを取得する。
【０２０９】
次に、サーバ１００Ｄは、優先度を算出する（ステップＳ１５２）。具体的に、算出部１２０Ｄが先のステップＳ１５１において取得されたロイヤリティ度ＣＲを用いて、優先度Ｉを算出する。
【０２１０】
そして、サーバ１００Ｄは、優先度に基づき要求リストを生成する（ステップＳ１５３）。具体的に、要求リスト生成部１３０が、先のステップＳ１５２において算出された優先度Ｉに基づいて、要求リストＬを生成する。先のステップＳ１５０の処理が実行された場合には、ステップＳ１５０において抽出された要求データＲに係る要求についての要求リストＬが生成される。
【０２１１】
その後、先に図２８を参照して説明したステップＳ１１３と同様の処理が実行される。すなわち、サーバ１００Ｄは、要求リストを提供側端末に送信する（ステップＳ１５４）。ステップＳ１５４の処理が完了した後、サーバ１００Ｄは、フローチャートの処理を終了する。
【０２１２】
サーバ１００Ｄによれば、購入希望者Ｕのロイヤリティ度ＣＲが算出され（ステップＳ１３１）、ロイヤリティ度ＣＲに基づいて優先度Ｉが算出される（ステップＳ１４５，Ｓ１５２）。ロイヤリティ度ＣＲは、購入希望者Ｕの購入側端末１０を用いたサーバ１００の利用情報に基づいて定められる利用の程度を示す指標であり、たとえば、上述した要求頻度、購入頻度、来店頻度、評価頻度および購入金額のうち少なくとも一つに基づいて算出される。ロイヤリティ度ＣＲが高いほど、その購入希望者Ｕの購入側端末１０からの要求の優先度Ｉが高くなる。これにより、将来的にも商品を購入する可能性が高い購入希望者Ｕの要求の優先度Ｉを高くすることができる。その結果、ロイヤリティ度ＣＲ（利用の程度）の高い購入希望者Ｕの要求の優先度Ｉが低くなりすぎることを防ぐことができる。また、各提供者Ｐにおいては、商品の購入の可能性が高い購入希望者Ｕに提案がされやすくなるので、販売数、売上、来店客数などの増加が期待できる。
【０２１３】
以上、本発明の実施形態について説明したが、本発明は、上述した実施形態に限定されるものではない。たとえば、各実施形態の特徴部分を適宜組み合わせた構成についても、本発明の実施形態とすることができる。
【符号の説明】
【０２１４】
１０…購入側端末、２０…提供側端末、１００，１００Ａ，１００Ｂ，１００Ｃ，１００Ｄ…サーバ、１１０…通信部（要求受付手段、リスト送信手段、提案受付手段、提案送信手段、評価情報受付手段、閲覧情報受付手段）、１２０…算出部（算出手段）、１３０…要求リスト生成部（生成手段）、１４０…記憶部、１４６…提供者ＤＢ（提供者情報記憶手段）、１４８…購入希望者ＤＢ（購入希望者情報記憶手段、履歴情報記憶手段）、１６０…購入希望者抽出部（抽出手段）。
【図１】
2017033160.tif 000003
【図２】
2017033160.tif 000004
【図３】
2017033160.tif 000005
【図４】
2017033160.tif 000006
【図５】
2017033160.tif 000007
【図６】
2017033160.tif 000008
【図７】
2017033160.tif 000009
【図８】
2017033160.tif 000010
【図９】
2017033160.tif 000011
【図１０】
2017033160.tif 000012
【図１１】
2017033160.tif 000013
【図１２】
2017033160.tif 000014
【図１３】
2017033160.tif 000015
【図１４】
2017033160.tif 000016
【図１５】
2017033160.tif 000017
【図１６】
2017033160.tif 000018
【図１７】
2017033160.tif 000019
【図１８】
2017033160.tif 000020
【図１９】
2017033160.tif 000021
【図２０】
2017033160.tif 000022
【図２１】
2017033160.tif 000023
【図２２】
2017033160.tif 000024
【図２３】
2017033160.tif 000025
【図２４】
2017033160.tif 000026
【図２５】
2017033160.tif 000027
【図２６】
2017033160.tif 000028
【図２７】
2017033160.tif 000029
【図２８】
2017033160.tif 000030
【図２９】
2017033160.tif 000031
【図３０】
2017033160.tif 000032
【図３１】
2017033160.tif 000033
【図３２】
2017033160.tif 000034
【図３３】
2017033160.tif 000035