(57)【要約】  取引要求者たるユーザに対して、多数の取引申込者からのオファー情報が送信されすぎないようにする。このために、取引申込者から取得したオファー情報について、比較対象を設定して比較を行う。そして比較結果に基づいて、当該オファー情報に関する送信を前記取引要求者端末に対して実行するか否かを決定する。この決定に基づいて、オファー情報についての取引要求者端末への送信処理を制御する。これにより比較処理で選択されたオファー情報についてのみ、オファー情報に関する送信が取引要求者端末に対して実行される。
2015181946.tif 000002
【特許請求の範囲】
【請求項１】
取引要求者端末から送信された取引要求情報に対応して、複数の取引申込者が互いのオファー内容を知り得ない状態で生成される、複数の取引申込者についてのオファー情報を取得する商取引情報取得部と、
前記商取引情報取得部が取得した前記オファー情報についての比較対象を設定する比較対象設定部と、
前記商取引情報取得部が取得した前記オファー情報と、前記比較対象設定部が設定した比較対象との比較結果に基づいて、当該オファー情報に関する送信を前記取引要求者端末に対して実行するか否かを決定する送信可否決定処理部と、
前記送信可否決定処理部の決定に基づいて、オファー情報に関する前記取引要求者端末への送信処理を制御する送信制御部と、を備えた
情報処理装置。
【請求項２】
前記送信可否決定処理部は、オファー情報に含まれる見積金額が、比較対象に含まれる金額よりも取引要求者側にとって優位な金額である場合に、当該オファー情報に関する前記取引要求者端末への送信を実行すると決定する
請求項１に記載の情報処理装置。
【請求項３】
前記送信可否決定処理部は、オファー情報に含まれる見積金額が、比較対象に含まれる金額よりも取引要求者側にとって劣位な金額である場合、金額差分が第１閾値未満であれば、当該オファー情報に関する前記取引要求者端末への送信を実行すると決定する
請求項１又は請求項２に記載の情報処理装置。
【請求項４】
前記第１閾値は、比較対象とされたオファー情報のオファー元である取引申込者の実績情報、又は比較対象と比較するオファー情報のオファー元である取引申込者の実績情報を用いて設定される
請求項３に記載の情報処理装置。
【請求項５】
前記第１閾値は、オファー情報の対象の取引要求者端末へのオファー情報に関する送信実行状況に基づいて設定される
請求項３に記載の情報処理装置。
【請求項６】
前記第１閾値は、前記比較対象設定部によって比較対象に設定されたオファー情報との比較結果により、前記取引要求者端末へ送信しないと決定されたオファー情報の数に基づいて設定される
請求項３に記載の情報処理装置。
【請求項７】
前記送信可否決定処理部は、オファー情報に含まれる見積金額を比較用に補正したうえで比較対象と比較する
請求項１乃至請求項６のいずれかに記載の情報処理装置。
【請求項８】
前記送信可否決定処理部は、オファー情報に関する条件要素と、取引要求情報に関連づけられた設定条件との差の大きさに基づいて、オファー情報に含まれる見積金額を比較用に補正する
請求項７に記載の情報処理装置。
【請求項９】
前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報のオファー元である取引申込者への通知処理を実行するか否かを決定する処理を行う
請求項１乃至請求項８のいずれかに記載の情報処理装置。
【請求項１０】
前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報に含まれる見積金額と比較対象に含まれる金額の金額差分が所定閾値未満であれば、当該オファー情報のオファー元である取引申込者への通知処理を実行すると決定する
請求項９に記載の情報処理装置。
【請求項１１】
前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報についての取引申込者への通知処理は、当該オファー情報のオファー元である取引申込者による他のオファー情報の状況に基づいて、実行するか否かを決定する
請求項９に記載の情報処理装置。
【請求項１２】
前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報のオファー元である取引申込者への通知処理を実行する場合、前記通知処理による通知情報には、再オファー情報の送信を推奨する内容を含むようにする
請求項１乃至請求項１１のいずれかに記載の情報処理装置。
【請求項１３】
前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報のオファー元である取引申込者への通知処理を実行する場合、前記通知処理による通知情報には、オファーの対象とする取引要求情報の変更を推奨する内容を含むようにする
請求項１乃至請求項１２のいずれかに記載の情報処理装置。
【請求項１４】
前記送信可否決定処理部は、比較結果からオファー情報に関する送信を前記取引要求者端末に対して実行するか否かを決定するための条件を、送信対象の取引要求者端末へのオファー情報送信状況に基づいて選択する
請求項１乃至請求項１３のいずれかに記載の情報処理装置。
【請求項１５】
前記比較対象設定部は、前記商取引情報取得部が取得したオファー情報と同じ取引要求情報に対応し、かつ前記取引要求者端末に送信された他のオファー情報であって、前記取引要求者端末側での所定操作が行われたオファー情報を、比較対象に設定する
請求項１乃至請求項１４のいずれかに記載の情報処理装置。
【請求項１６】
取引要求者端末から送信された取引要求情報に対応して、複数の取引申込者が互いのオファー内容を知り得ない状態で生成される、複数の取引申込者についてのオファー情報を取得する商取引情報取得ステップと、
前記商取引情報取得ステップで取得した前記オファー情報についての比較対象を設定する比較対象設定ステップと、
前記商取引情報取得ステップで取得した前記オファー情報と、前記比較対象設定ステップで設定した比較対象との比較結果に基づいて、当該オファー情報に関する送信を前記取引要求者端末に対して実行するか否かを決定する送信可否決定ステップと、
前記送信可否決定ステップの決定に基づいて、オファー情報に関する前記取引要求者端末への送信処理を制御する送信制御ステップと、を有する
情報処理方法。
【請求項１７】
取引要求者端末から送信された取引要求情報に対応して、複数の取引申込者が互いのオファー内容を知り得ない状態で生成される、複数の取引申込者についてのオファー情報を取得する商取引情報取得手順と、
前記商取引情報取得手順で取得した前記オファー情報についての比較対象を設定する比較対象設定手順と、
前記商取引情報取得手順で取得した前記オファー情報と、前記比較対象設定手順で設定した比較対象との比較結果に基づいて、当該オファー情報に関する送信を前記取引要求者端末に対して実行するか否かを決定する送信可否決定手順と、
前記送信可否決定手順の決定に基づいて、オファー情報に関する前記取引要求者端末への送信処理を制御する送信制御手順と、
を情報処理装置に実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理装置、情報処理方法、プログラムに関し、特に取引要求者からの取引要求と、それに対するオファー情報を処理する技術分野に関する。
【先行技術文献】
【特許文献】
【０００２】
【特許文献１】特開２００２−１５１６１号公報
【背景技術】
【０００３】
従来、インターネット等の通信網を介して一般ユーザが商取引を要求し、例えば事業者が取引のオファーを行うことを仲介するサービスが行われている。
このようなサービスに関する技術として、上記特許文献１等が開示されている。例えばユーザが仲介業者のホームページにアクセスし、オートバイの購入又は売却条件を提示し、仲介業者がこれを事業者に送信する。事業者は見積もりをユーザに回答する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら従来の仲介システムでは、ユーザ（取引要求者）に対して提示される事業者からのオファーが多すぎることが発生している。例えばユーザが端末を用いて取引をリクエストした場合、例えばあまりに多数の事業者からの電子メール等により見積もりが送られてきて、逆にユーザにとって電子メール自体が負担となったり、見積もりの選択が困難となることが多々生じている。
そこで本発明では、取引要求者に対してオファーが多すぎることによる負担を解消又は軽減することを目的とする。
【課題を解決するための手段】
【０００５】
第１に、本発明に係る情報処理装置は、取引要求者端末から送信された取引要求情報に対応して、複数の取引申込者が互いのオファー内容を知り得ない状態で生成される、複数の取引申込者についてのオファー情報を取得する商取引情報取得部と、前記商取引情報取得部が取得した前記オファー情報についての比較対象を設定する比較対象設定部と、前記商取引情報取得部が取得した前記オファー情報と、前記比較対象設定部が設定した比較対象との比較結果に基づいて、当該オファー情報に関する送信を前記取引要求者端末に対して実行するか否かを決定する送信可否決定処理部と、前記送信可否決定処理部の決定に基づいて、オファー情報に関する前記取引要求者端末への送信処理を制御する送信制御部とを備えたものである。
取引要求者端末とは、取引要求者、例えば商品の売却、購入、契約等の商取引を求めるユーザが用いる端末である。取引申込者とは、取引要求者との商取引を申し入れる事業者等である。すなわちこの情報処理装置は、取引要求者と複数の取引申込者を仲介するシステムとして機能する。この場合に、取引要求情報に対する複数の取引申込者からのそれぞれのオファー情報について、比較対象との比較処理を行って、取引要求者端末へのオファー情報に関する送信を行うか否かを決定する。すなわち各オファー情報についてフィルタリングして取引要求者への送信を実行する機能を備える。【０００６】
第２に、上記した本発明に係る情報処理装置においては、前記送信可否決定処理部は、オファー情報に含まれる見積金額が、比較対象に含まれる金額よりも取引要求者側にとって優位な金額である場合に、当該オファー情報に関する前記取引要求者端末への送信を実行すると決定することが望ましい。
取引要求者にとって優位な見積金額であるということは、取引要求者にとって好ましい、つまり取引の成約に関して検討に値するオファー情報であるため、そのようなオファー情報をユーザに提示することが適切となる。【０００７】
第３に、上記した本発明に係る情報処理装置においては、前記送信可否決定処理部は、オファー情報に含まれる見積金額が、比較対象に含まれる金額よりも取引要求者側にとって劣位な金額である場合、金額差分が第１閾値未満であれば、当該オファー情報に関する前記取引要求者端末への送信を実行すると決定するようにしてもよい。
取引要求者にとって劣位な見積金額であったとしても、各種事情により取引要求者が成約を望む場合もある。ただし、金額的にあまりに劣位であると、通常は成約の候補にはなりにくい。そこで金額的には劣位であるが、比較対象との金額差分が第１閾値未満であれば、成約の候補になり得るとして、そのオファー情報に関する取引要求者端末への送信を実行する。【０００８】
第４に、上記した本発明に係る情報処理装置においては、前記第１閾値は、比較対象とされたオファー情報のオファー元である取引申込者の実績情報、又は比較対象と比較するオファー情報のオファー元である取引申込者の実績情報を用いて設定してもよい。
金額差分の上限としての第１閾値は、固定値でもよいが、取引申込者の実績に応じて可変してもよい。これにより取引申込者の信用等を反映して、取引要求者への送信可否を判断できる。実績情報は、例えば取引申込者による過去の成約取引についての、オファー情報に示された見積金額と成約金額との差額情報などとする。【０００９】
第５に、上記した本発明に係る情報処理装置においては、前記第１閾値は、オファー情報の対象の取引要求者端末へのオファー情報に関する送信実行状況に基づいて設定されるようにしてもよい。
第１閾値は、取引要求者への送信実行判定を厳しくするか緩くするかの機能を持つ。第１閾値を大きくすれば、取引要求者端末への送信が実行されるオファー情報の数が増えやすくなり、第１閾値を小さくすれば、取引要求者端末への送信が実行されるオファー情報の数が絞られる傾向となる。オファー情報に関する送信は、多すぎることは取引要求者の負担となるが、逆に少なすぎると、取引要求者が適度な数のオファーから成約したいオファーを選択するという機能が不十分となる。そこで第１閾値を取引要求者端末へのオファー情報に関する送信実行状況に基づいて設定する。これにより適度な数のオファーを取引要求者に提示できる。【００１０】
第６に、上記した本発明に係る情報処理装置においては、前記第１閾値は、前記比較対象設定部によって比較対象に設定されたオファー情報との比較結果により、前記取引要求者端末へ送信しないと決定されたオファー情報の数に基づいて設定されるようにしてもよい。
これも適度な数のオファーを取引要求者に提示するための調整機能を実現するための処理となる。例えば比較対象とされた他のオファー情報が、取引要求者にとって甚だしく優位なものの場合、他のオファー情報のほとんどが送信されないものとなることが想定される。そこで、そのような状況に応じて第１閾値を可変し、適度な数の送信が行われるようにする。【００１１】
第７に、上記した本発明に係る情報処理装置においては、前記送信可否決定処理部は、オファー情報に含まれる見積金額を比較用に補正したうえで比較対象と比較するようにしてもよい。
取引要求者が成約したいと考える条件は、見積金額、利便性、事業者の信用など多岐にわたる。そこで見積金額のみ劣位であるために取引要求者への送信が実行されない、あるいは見積金額のみ優位であるため送信が実行されるということをなくすため、比較に用いる見積金額を増減する補正を行うことを可能とする。これによりユーザに多様な条件の見積もりが提示されるようにする。【００１２】
第８に、上記した本発明に係る情報処理装置においては、前記送信可否決定処理部は、オファー情報に関する条件要素と、取引要求情報に関連づけられた設定条件との差の大きさに基づいて、オファー情報に含まれる見積金額を比較用に補正するようにしてもよい。
取引要求者が取引要求情報において設定条件を提示することで、取引要求者が成約に求める条件を判断できる。そのような条件に適したオファーは、比較時の見積金額の補正により、取引要求者端末への送信が行われやすくできる。【００１３】
第９に、上記した本発明に係る情報処理装置においては、前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報のオファー元である取引申込者への通知処理を実行するか否かを決定する処理を行うようにしてもよい。
取引要求者端末への送信を行わないとされたオファー情報は、取引申込者にとっては成約不可能又は成約困難なものとなる。そこでその旨を通知する。【００１４】
第１０に、上記した本発明に係る情報処理装置においては、前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報に含まれる見積金額と比較対象に含まれる金額の金額差分が所定閾値未満であれば、当該オファー情報のオファー元である取引申込者への通知処理を実行すると決定するようにしてもよい。
金額差分が所定閾値未満ということは、比較により送信不実行と決定されたが、比較処理においてさほど大きく負けたものではないという意味になる。そこで再オファーを促す意味などで、通知処理が好適となる。【００１５】
第１１に、上記した本発明に係る情報処理装置においては、前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報についての取引申込者への通知処理は、当該オファー情報のオファー元である取引申込者による他のオファー情報の状況に基づいて、実行するか否かを決定するようにしてもよい。
例えば当該取引申込者の他のオファー情報により、同様の商品の取引の成約機会が存在しているなどの状況により、送信不実行の通知が必ずしも必要ではない場合があるためである。【００１６】
第１２に、上記した本発明に係る情報処理装置においては、前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報のオファー元である取引申込者への通知処理を実行する場合、前記通知処理による通知情報には、再オファー情報の送信を推奨する内容を含むようにすることが望ましい。
通知により再オファー情報の送信を推奨することで、取引申込者に成約のチャンスを提供できる。【００１７】
第１３に、上記した本発明に係る情報処理装置においては、前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報のオファー元である取引申込者への通知処理を実行する場合、前記通知処理による通知情報には、オファーの対象とする取引要求情報の変更を推奨する内容を含むようにすることが望ましい。
オファーの対象を変更すれば、取引申込者に新たに成約のチャンスを提供できる場合があるためである。【００１８】
第１４に、上記した本発明に係る情報処理装置においては、前記送信可否決定処理部は、比較結果からオファー情報に関する送信を前記取引要求者端末に対して実行するか否かを決定するための条件を、送信対象の取引要求者端末へのオファー情報送信状況に基づいて選択するようにしてもよい。
送信を実行するか否かの決定条件は、厳しい条件や緩い条件で可変してもよい。このような条件選択を取引要求者端末へのオファー情報送信状況に基づいて行うことで、取引要求者端末へ適度な数のオファー情報の提示を実現できる。【００１９】
第１５に、上記した本発明に係る情報処理装置においては、前記比較対象設定部は、前記商取引情報取得部が取得したオファー情報と同じ取引要求情報に対応し、かつ前記取引要求者端末に送信された他のオファー情報であって、前記取引要求者端末側での所定操作が行われたオファー情報を、比較対象に設定するようにしてもよい。
比較処理における比較対象には、取引要求者にとって成約可否の基準となるものが望ましい。既に取引要求者に提示し取引要求者が興味を示したオファー情報は、このような基準として適切と想定される。そこで取引要求者端末側で、クリック（閲覧）等の所定操作が行われたオファー情報を、比較対象に設定する。【００２０】
本発明に係る情報処理方法は、取引要求者端末から送信された取引要求情報に対応して、複数の取引申込者が互いのオファー内容を知り得ない状態で生成される、複数の取引申込者についてのオファー情報を取得する商取引情報取得ステップと、前記商取引情報取得ステップで取得した前記オファー情報についての比較対象を設定する比較対象設定ステップと、前記商取引情報取得ステップで取得した前記オファー情報と、前記比較対象設定ステップで設定した比較対象との比較結果に基づいて、当該オファー情報に関する送信を前記取引要求者端末に対して実行するか否かを決定する送信可否決定ステップと、前記送信可否決定ステップの決定に基づいて、オファー情報に関する前記取引要求者端末への送信処理を制御する送信制御ステップと、を有する。
これにより多数のオファー情報についてフィルタリングして取引要求者への送信を実行する機能を実現する。
また本発明に係るプログラムは、上記情報処理方法の各ステップを情報処理装置に実行させるプログラムである。このプログラムにより上記の情報処理装置を実現する。
【発明の効果】
【００２１】
本発明によれば、取引要求者に対してオファーが多すぎることによる負担を解消又は軽減することができる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施の形態の取引仲介装置を含むシステム構成のブロック図である。
【図２】実施の形態で用いられるコンピュータ装置のブロック図である。
【図３】実施の形態の取引仲介装置の機能構成のブロック図である。
【図４】実施の形態のユーザデータベース、ベンダーデータベースの説明図である。
【図５】実施の形態の見積要求情報データベース、オファー情報データベースの説明図である。
【図６】実施の形態の成約情報データベースの説明図である。
【図７】第１〜第６の実施の形態における各端末間の処理の流れの説明図である。
【図８】第１の実施の形態の取引仲介装置の処理のフローチャートである。
【図９】実施の形態の比較対象設定処理のフローチャートである。
【図１０】実施の形態の比較対象設定処理のフローチャートである。
【図１１】実施の形態の比較対象設定処理のフローチャートである。
【図１２】実施の形態の比較対象設定処理のフローチャートである。
【図１３】実施の形態の比較対象設定処理のフローチャートである。
【図１４】実施の形態の比較／送信可否決定処理のフローチャートである。
【図１５】実施の形態の比較／送信可否決定処理のフローチャートである。
【図１６】実施の形態の比較／送信可否決定処理のフローチャートである。
【図１７】実施の形態の比較／送信可否決定処理のフローチャートである。
【図１８】実施の形態の比較／送信可否決定処理のフローチャートである。
【図１９】実施の形態の差分閾値設定処理のフローチャートである。
【図２０】実施の形態の差分閾値設定処理のフローチャートである。
【図２１】実施の形態の比較処理の変形例のフローチャートである。
【図２２】実施の形態の比較処理の変形例のフローチャートである。
【図２３】実施の形態の非送信オファー処理のフローチャートである。
【図２４】実施の形態の非送信オファー処理のフローチャートである。
【図２５】実施の形態の通知情報生成処理のフローチャートである。
【図２６】第２，第３の実施の形態の取引仲介装置の処理のフローチャートである。
【図２７】第４，第５の実施の形態の取引仲介装置の処理のフローチャートである。
【図２８】第６の実施の形態の取引仲介装置の処理のフローチャートである。
【図２９】第７の実施の形態における各端末間の処理の流れの説明図である。
【図３０】第７の実施の形態のオファー条件データベースの説明図である。
【図３１】第７の実施の形態の取引仲介装置の処理のフローチャートである。
【図３２】第８の実施の形態における各端末間の処理の流れの説明図である。
【図３３】第８の実施の形態のウェブ提示例の説明図である。
【図３４】第８の実施の形態の取引仲介装置の処理のフローチャートである。
【発明を実施するための形態】
【００２３】
以下、実施の形態を次の順序で説明する。
＜１．ネットワークシステム構成＞
＜２．取引仲介装置およびデータベースの構成＞
＜３．第１の実施の形態＞
［３−１：システム全体の処理の流れ］
［３−２：取引仲介装置の処理］
［３−３：比較対象設定処理］
［３−４：比較／送信可否決定処理］
［３−５：差分閾値設定処理］
［３−６：比較処理に関する変形例］
［３−７：非送信オファー処理］
＜４．第２〜第６の実施の形態＞
＜５．第７の実施の形態＞
＜６．第８の実施の形態＞
＜７．まとめ及び変形例＞
＜８．プログラム及び記憶媒体＞
【００２４】
なお実施の形態では、本発明請求項にいう情報処理装置の例として、例えば自動車の買取を仲介する取引仲介装置を挙げる。取引仲介装置は１又は複数の情報処理装置によって実現されるものであり、従って本発明請求項にいう情報処理装置は、１つの情報処理装置或いは複数の情報処理装置が連携して実現される。
また実施の形態で用いる主な語句については、以下の意味となる。
・ユーザ：取引要求者を指す。例えば自動車の売却（ベンダーによる買取）を希望するユーザである。
・ユーザ端末：ユーザが使用するネットワーク通信可能な情報処理装置である。
・ベンダー：取引申込者を指す。例えば自動車買取業者である。
・ベンダー端末：ベンダーが使用するネットワーク通信可能な情報処理装置である。
・見積要求情報：ユーザが見積を求めるために取引仲介装置に送信する情報を包括的に示す用語としている。販売したい商品の情報や条件等の各種内容を含む。この「見積要求情報」が、本発明請求項にいう取引要求情報の一例である。
・オファー情報：見積要求情報に対してのベンダーによるオファー（取引の申し入れ）に関する情報を包括的に示す用語としている。見積金額その他の各種内容を含む。実施の形態で述べる「オファー情報」が、本発明請求項にいうオファー情報の一例である。
【００２５】
＜１．ネットワークシステム構成＞
図１に実施の形態の取引仲介装置２を含むネットワークシステムの構成例を示す。
本実施の形態に係るネットワークシステムは、取引仲介装置２、複数のベンダー端末４（４ａ，４ｂ，４ｃ・・・）、複数のユーザ端末５（５ａ，５ｂ，５ｃ・・・）がネットワーク１により相互に通信可能に接続されている。
また取引仲介装置２はデータベース群３として示す各種データベースにアクセス可能とされている。なお、以下「データベース」については「ＤＢ」と表記する。
【００２６】
ネットワーク１の構成は多様な例が想定される。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が想定される。
またネットワーク１の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線等の有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。
【００２７】
取引仲介装置２は、ネットワーク通信を介して、ユーザとベンダーの間での商取引を仲介するサービスを行う情報処理装置である。大まかには次のようなサービスとなる。
ユーザは、ユーザ端末５から取引仲介装置２にアクセスすることで、取引仲介装置２が用意する買取仲介サービスのウェブページを閲覧できる。
例えば自己が所有する自動車を売却したいと考えるユーザは、当該ウェブページにおいて見積要求を行うことができる。例えばユーザは、買取仲介サービスにログインし、ウェブページとして用意された申込画面において、車種、年式、色、走行距離などの売却商品の情報を入力する。この入力された情報は、見積要求情報として、ログインしたユーザの情報とともに取引仲介装置２に取得される。
【００２８】
取引仲介装置２は、見積要求情報の内容の一部又は全部を、登録された複数のベンダー端末４に送信する。これにより複数のベンダーが、ユーザによる見積要求の内容を知ることができる。各ベンダーは任意に、内容、即ち車種、年式、色、走行距離などの情報に応じた見積を作成し、見積金額を含むオファー情報を取引仲介装置２に送信する。このベンダー端末４からのオファー情報は、見積要求を行ったユーザに直接送信されるものではなく、一旦、取引仲介装置２に取得されるようにする。なお、このため本実施の形態では、取引仲介装置２は、ユーザの連絡先の情報、例えばユーザの電子メールアドレス等をベンダーに通知する必要はない。
【００２９】
また本実施の形態の場合、取引仲介装置２は、ユーザからの取引要求情報に対応してのオファー情報として、複数の取引申込者のオファー情報を取得することになるが、各オファー情報は、互いのオファー内容を知り得ない状態で生成される。即ち各ベンダーは、商取引の競合者である他のベンダーのオファー内容を知り得ない。つまり取引仲介装置２は、各ベンダー端末４ａ，４ｂ・・・に、それぞれ見積要求情報の内容を送信するが、他のベンダーのオファー内容については送信しないようにする。
各ベンダーは、それぞれのベンダー端末４ａ，４ｂ・・・により、他のベンダーのオファー内容（例えば買取の見積金額）を認識せずに、自己のオファー情報を生成し、取引仲介装置２に送信することになる。或いは第７の実施の形態で述べるように、取引仲介装置２が、ベンダー間で互いにオファー内容を知り得ない状態を維持しながら、各ベンダーのオファー情報を生成する場合もある。
【００３０】
取引仲介装置２は、受信したオファー情報については、そのままユーザ端末に転送するのではなく、詳しくは後述する比較／送信可否決定処理を行い、送信可と判定したオファー情報に関して、ユーザ端末５への送信を実行する。
このように取引仲介装置２は、多数のベンダー端末４から取得した多数のオファー情報に関して、ユーザ端末５に送信するためのフィルタリングを行うことになる。
なお取引仲介装置２は、第１〜第７の実施の形態では、ユーザ端末５へオファー情報の内容を送信する。第８の実施の形態ではオファー情報発生の通知を送信する。ここではユーザ端末５へはオファー情報の内容を送信するものとして説明を続ける。
【００３１】
その後、ユーザは、送信されてきたオファー情報を検討して、取引相手を決めることができる。ユーザは取引を希望するベンダーと連絡を取り、実際の商談を行うことができる。
本実施の形態では、オファー情報は、見積要求に対する見積金額等を内容として含んでいる。あくまでも「見積」であって、その見積金額等の条件による成約を強制するものではない。従って、ユーザは、複数のベンダーからのオファー情報を検討したうえで、金額、ベンダーの信用、所在地、サービスその他の各種の条件を検討したうえで、任意に商談を行うことができる。
つまり取引仲介装置２がフィルタリングによって選択して、その内容又は通知がユーザ端末５に送信されたオファー情報によって、ベンダーの取引が強制されるものではない。換言すれば、取引仲介装置２が行うフィルタリングとは、成約させるオファーを選択するためのものではない。
【００３２】
以上のように取引仲介装置２は、主に、ユーザ端末５からの見積要求情報に応じたベンダーのオファー情報の取得、オファー情報のフィルタリング、フィルタリング結果に基づくユーザ端末５へのオファー情報に関する送信制御を行う。
ＤＢ群３としては、このような取引仲介装置２の処理で必要な情報の格納が行われる１又は複数のＤＢを模式的に示している。詳細は後述する。
【００３３】
ベンダー端末４は、ベンダーが使用する情報処理装置であり、ネットワーク１を介した取引仲介装置２との通信や登録に用いられる。登録とは、取引仲介装置２によるサービスの対象としてのベンダーとなるための登録である。
ユーザ端末５は、ユーザによって操作される情報処理装置として示している。
ユーザ端末５やベンダー端末４は、例えばパーソナルコンピュータ、携帯電話機、又は携帯情報端末等の情報処理装置により実現される。
【００３４】
本実施形態の場合、例えば取引仲介装置２ではＨＴＴＰ（Hypertext Transfer Protocol）デーモンが起動される。またベンダー端末４又はユーザ端末５ではブラウザが起動され、ベンダー端末４又はユーザ端末５からは、ブラウザを介して処理要求（ＨＴＴＰリクエスト）が取引仲介装置２に送信される。取引仲介装置２からは、上記の処理要求に対応する処理結果（ＨＴＴＰレスポンス）がベンダー端末４又はユーザ端末５に送信される。例えばウェブページ記述言語で記述されたページデータがベンダー端末４又はユーザ端末５に送信される。そして、このページデータに基づいて、処理結果に基づくウェブページ（画面）がベンダー端末４又はユーザ端末５の表示部に表示される。またベンダー端末４又はユーザ端末５ではブラウザ画面上で入力を行い、情報を取引仲介装置２に送信することができる。
取引仲介装置２はこのような動作によりユーザ端末５に対して自動車買取のためのサービスページを提供し、またユーザ端末５からの見積要求情報の受付を行うことができる。また取引仲介装置２は、ベンダー端末４に対してオファー（取引の申し入れ）のためのサービスページを提供し、ベンダー端末４からのオファー情報の受付を行うことができる。
【００３５】
また取引仲介装置２は、ベンダー端末４、ユーザ端末５に対して電子メール等による通信を行うことができる。例えば取引仲介装置２は電子メールデータを生成し、図示していない電子メールサーバ（プロバイダー）を介してベンダー端末４やユーザ端末５に各種の通知を送信する。例えば取引仲介装置２はベンダー端末４に対しては、ユーザからの見積要求情報の内容を通知したり、オファー情報についてのユーザ端末５への送信状況などの通知を電子メール等により行う。
また取引仲介装置２はユーザ端末５に対しては、オファー情報の送信や、オファー情報の発生の通知などを電子メール等により送信する。
【００３６】
続いて図１に示した取引仲介装置２、ベンダー端末４、ユーザ端末５を構成する情報処理装置のハードウエア構成を図２に示す。取引仲介装置２、ベンダー端末４、ユーザ端末５として示した各装置は、情報処理および情報通信が可能な図２に示すようなコンピュータ装置として実現できる。
【００３７】
図２において、コンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ( Read Only Memory)１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ( Random Access Memory )１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
入出力インターフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力装置１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどよりなる出力装置１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、ネットワーク１を介しての通信処理や機器間通信を行う通信部１０９が接続されている。
入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。
【００３８】
このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、取引仲介装置２、ベンダー端末４、ユーザ端末５としての必要な情報処理や通信が実行される。
なお、取引仲介装置２、ベンダー端末４、ユーザ端末５を構成する情報処理装置は、図２のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮ等によりシステム化されていてもよいし、インターネット等を利用したＶＰＮ等により遠隔地に配置されたものでもよい。
【００３９】
＜２．取引仲介装置およびデータベースの構成＞
図３に１又は複数の情報処理装置で構成される取引仲介装置２としての機能構成およびＤＢ群３として示した各種のＤＢを示す。
取引仲介装置２としての各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し以下説明する全部又は一部の各構成の処理をハードウエアにより実現してもよい。
また各機能をソフトウエアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。１つのプログラムにより複数の機能の処理が実行されてもよいし、１つの機能が複数のプログラムモジュールの連携で実現されてもよい。
【００４０】
取引仲介装置２は、通信部２０、商取引情報取得部２１、比較対象設定部２２、送信可否決定処理部２３、送信制御部２４、ＷＥＢサーバ２５を有する。
【００４１】
通信部２０は、ネットワーク１を介してのユーザ端末５やベンダー端末４、或いは他の情報処理装置との各種通信を行う。例えばユーザ端末５やベンダー端末４においてブラウザ上で提示されるＷＥＢページを構成するＨＴＭＬデータの送信や、ＷＥＢ画面で提供した入力フォームに対するユーザやベンダーによる入力情報（例えば見積要求情報やオファー情報）の送信を受け付ける。また電子メールの送受信を行う。
【００４２】
商取引情報取得部２１は、通信部２０により受信された商取引情報を取得する。或いは商取引情報取得部２１は、通信部２０により受信された情報に基づいて商取引情報を生成して取得する場合もある。
実施の形態でいう商取引情報とは、例えばユーザ端末５から送信される見積要求情報や、ベンダー端末４から送信されるオファー情報、成約時にユーザ端末５又はベンダー端末４から送信される成約情報等である。
商取引情報取得部２１は、各種の商取引情報に関する後述する各ＤＢの登録、更新等の処理を行い、またオファー情報について上述のフィルタリング機能を実現する比較処理の実行指示、準備処理の指示等や、そのための必要な情報のＤＢ読出等を行う。
また商取引情報取得部２１は、見積要求情報の取得に応じて、各ベンダー端末４への紹介情報の送信も行う。
なお、オファー情報に関しては、商取引情報取得部２１は、ユーザ端末５から送信された取引要求情報に対応して、複数の取引申込者が互いのオファー内容を知り得ない状態で生成される、複数の取引申込者についてのオファー情報を取得することになる。
【００４３】
比較対象設定部２２は、オファー情報に関しての比較処理のために、比較相手となる比較対象を設定する処理を行う。
本実施の形態では、上述のようにオファー情報に関して、ユーザへの送信の実行を行うか否かを決定するという、オファー情報のフィルタリングを行う。つまり、ユーザにとって必要と判定されるオファー情報をユーザに提示し、逆に不要と判定されるオファー情報に関しての送信は実行しないようにする。比較対象とは、このような判定のための基準となるものである。各種例を後述するが、比較対象は固定値、可変値各種考えられる。あるオファー情報についての判定のための比較対象として他のオファー情報を用いることもある。
【００４４】
送信可否決定処理部２３は、商取引情報取得部２１が取得したオファー情報と、比較対象設定部２２が設定した比較対象との比較結果に基づいて、当該オファー情報に関する送信をユーザ端末５に対して実行するか否かを決定する処理を行う。
最もシンプルな例としては、或るオファー情報が、比較対象よりもユーザサイドから見て優位な条件である場合（例えば買取の見積金額が高い等）に、当該オファー情報に関する送信をユーザ端末５に対して実行すると決定し、逆にユーザサイドから見て劣位な条件である場合に、当該オファー情報に関する送信をユーザ端末５に対して実行しないと決定する。送信決定のための具体的処理は多様に考えられるため各種の例を後述する。
また送信可否決定処理部２３は、ユーザ端末５に対する送信を実行しないと決定したオファー情報について、そのオファー元のベンダーへの通知に関する処理も行う。
【００４５】
送信制御部２４は、送信可否決定処理部２３の決定に基づいて、オファー情報に関するユーザ端末５への送信処理を制御する。即ち送信実行と決定されたオファー情報について、その内容を反映したユーザ宛ての電子メールデータの生成や、通信部２０への電子メールデータの送信要求を行う。
また送信制御部２４は、送信可否決定処理部２３により送信を実行しないと決定されたオファー情報について、そのオファー元のベンダーへの通知のための電子メールデータの生成や、通信部２０への電子メールデータの送信要求を行う。
これらの電子メールデータは通信部２０の処理によりユーザ端末５やベンダー端末４に送信される。
【００４６】
ＷＥＢサーバ２５は、自動車買取サービスのためのＷＥＢページを提供するサーバである。自動車売却を希望するユーザは、ＷＥＢサーバ２５が提供するＷＥＢページにアクセスしログインする。そしてＷＥＢサーバ２５が提供する見積要求のページに進み、見積要求情報としての各種内容を入力することができる。
買取業者としてのベンダーは、ベンダー端末４からＷＥＢサーバ２５が提供するＷＥＢページにアクセスし、登録ページからユーザ（売却希望者）の紹介をうける業者として登録を受けることができる。登録されたベンダーには、取引仲介装置２が見積要求情報を供給する。また登録されたベンダーは、ベンダー端末４からログインし、ＷＥＢサーバ２５が提供するオファー入力ページに進み、オファー情報としての各種内容を入力することができる。
なお後述する第８の実施の形態の場合、ＷＥＢサーバ２５は、ユーザに対してオファー情報提示用のページの生成／更新／ユーザ端末による閲覧可能可の処理も行う。
【００４７】
続いて各種ＤＢについて説明する。取引仲介装置２がアクセスするＤＢとして、図示のようにユーザＤＢ３１、ベンダーＤＢ３２、見積要求情報ＤＢ３３、オファー情報ＤＢ３４、成約情報ＤＢ３５、オファー条件ＤＢ３６がある。
これらの各ＤＢ（３１〜３６）は、取引仲介装置２がアクセス可能とされていればどのような形態で実現されていてもよい。例えば取引仲介装置２と同一システム内の記憶部に各ＤＢ（３１〜３６）のすべてが形成されていてもよいし、各ＤＢ（３１〜３６）の一部又は全部が別体、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各ＤＢ（３１〜３６）が一つの装置（例えば一つのＨＤＤ等）内に形成されている必要はない。また各ＤＢ（３１〜３６）のそれぞれが、それぞれ１つのＤＢとして構成される必要もない。例えばユーザＤＢ３１として記憶される情報が、複数のユーザＤＢ（例えばログイン用のユーザＤＢと取引用のユーザＤＢなど）により記憶管理されてもよい。以下説明する各ＤＢ（３１〜３６）は、実施の形態の処理に関連する情報を、それぞれ１つのＤＢの形態で例示したものに過ぎない。
【００４８】
ユーザＤＢ３１は、取引仲介装置２によるサービスを受けるユーザの情報が記憶される。図４ＡにユーザＤＢ３１の一例を示す。ユーザＤＢ３１には、ユーザＩＤ（identification）に対応してユーザの氏名、住所、ログイン用のパスワード、電子メールアドレス、見積要求履歴等が記憶される。
ユーザＩＤはユーザ個々の識別情報である。各ユーザＩＤをＵ１，Ｕ２・・・として示している。ユーザＩＤとパスワードは、例えばユーザがユーザ端末５から自動車買取サービスのためのＷＥＢページにログインする際に用いられる。
取引仲介装置２はユーザがログインした場合、ユーザＩＤに基づいてユーザＤＢ３１を参照することで、そのユーザの氏名、住所、電子メールアドレス、見積要求履歴を確認できる。見積要求履歴としては、例えば過去の見積要求情報を示す情報（例えば後述の見積要求ＩＤ）が記憶される。
なおユーザＤＢ３１には、図示以外にも、性別や年齢等の属性情報、決済情報、他のサービスに関する情報などが登録されてもよい。
【００４９】
ベンダーＤＢ３２は、取引仲介装置２に登録したベンダーの情報が記憶される。図４ＢにベンダーＤＢ３２の一例を示す。ベンダーＤＢ３２には、ベンダーＩＤに対応してベンダーの名称、住所、ログイン用のパスワード、電子メールアドレス、対応車種、評価等が記憶される。
ベンダーＩＤは登録されたベンダー個々に発行される識別情報である。各ベンダーＩＤをＶ１，Ｖ２・・・として示している。ベンダーＩＤとパスワードは、例えばベンダーがベンダー端末４から自動車買取サービスのためのＷＥＢページにログインする際に用いられる。
取引仲介装置２はベンダーがログインした場合、ベンダーＩＤに基づいてベンダーＤＢ３２を参照することで、そのベンダーの名称、住所、電子メールアドレス、対応車種、評価を確認できる。
対応車種とは、ベンダーが買取に応じることができる自動車の車種、色、年式等の情報である。ベンダーは登録変更により、任意に対応車種の情報を更新できる。
評価とは、例えば取引仲介装置２が、そのベンダーの過去の取引実績等から算出したベンダーの評価情報である。
なおベンダーＤＢ３２には、図示以外にも、各種のベンダーの属性情報、対応可能な決済種別情報などが登録されてもよい。
【００５０】
見積要求情報ＤＢ３３の例を図５Ａに示す。見積要求情報ＤＢ３３には、個々の見積要求情報に対応して各種の情報が記憶される。
見積要求ＩＤは、ユーザ端末５から送信されてきた個々の見積要求情報の識別情報である。各見積要求ＩＤをＲＱ１，ＲＱ２・・・として示している。
この見積要求ＩＤに対応して、取得日時、ユーザＩＤ、見積対象情報、ステータス、ユーザ設定条件等が記憶される。
取得日時は、取引仲介装置２がユーザ端末５からの見積要求情報を取得した日時である。
ユーザＩＤとしては、見積要求情報を送信したユーザのユーザＩＤが記憶される。
見積対象情報とは、見積要求にかかる対象商品（売却希望の自動車）の情報であって、例えば車種、色、走行距離、オプション、事故歴などの情報を含む。この見積対象情報はユーザから送信された見積要求情報に含まれている情報である。
ステータスは、その見積要求についての進行状況を示す情報である。例えばオファー受付前、オファー受付中、オファー受付終了、キャンセルなどの情報が記憶される。
ユーザ設定条件は、見積に対してユーザが要求する条件の情報であり、ユーザが任意に設定できる。例えば希望最低価格等の取引希望金額に関する条件や、成約期限などの時間的な条件、ベンダーの所在地などの位置的条件などがユーザの設定に応じて記憶される。
【００５１】
オファー情報ＤＢ３４の例を図５Ｂに示す。オファー情報ＤＢ３４には、個々のオファー情報に対応して各種の情報が記憶される。
オファーＩＤは、個々のオファー情報の識別情報である。各オファーＩＤをＯＦ１，ＯＦ２・・・として示している。このオファーＩＤに対応して、取得日時、ベンダーＩＤ、ユーザＩＤ、見積要求ＩＤ、見積金額、オファー発行日、オファー有効期限、ステータス、送信日時等が記憶される。
取得日時は、取引仲介装置２がオファー情報を取得した日時である。具体的にはベンダー端末４からオファー情報を受信して取得した日時や、ベンダーからの指定等に基づいて取引仲介装置２がオファー情報を生成して取得した日時である。
ベンダーＩＤとしては、オファー情報を発行したオファー元のベンダーのベンダーＩＤが記憶される。
ユーザＩＤとしては、オファー情報が対応する見積要求情報を送信したユーザのユーザＩＤが記憶される。
見積要求ＩＤとしては、オファー情報が対応する見積要求情報についての見積要求ＩＤが記憶される。
見積金額は、見積要求情報に示された自動車についての買取価格の見積金額である。
オファー発効日は、そのオファー情報の効力開始日である。
オファー有効期限は、そのオファー情報の有効期限日である。
ステータスは、そのオファー情報についての進行状況を示す情報である。例えばフィルタリングのための比較前、送信決定、非送信（送信不可）決定、ユーザ宛の送信済み、採用、不採用、キャンセルなどの情報が記憶される。
送信日時としては、ユーザ端末５に宛てての送信の実行日時や、非送信決定されてベンダー端末４に通知を行った場合の送信日時が記憶される。
【００５２】
成約情報ＤＢ３５の例を図６に示す。成約情報ＤＢ３５には、成約したオファー情報と見積要求情報の組についての各種の情報が記憶される。
オファーＩＤと見積要求ＩＤにより、成約したオファー情報と見積要求情報の組が示される。また当該見積要求ＩＤに係るユーザＩＤ、オファーＩＤに係るベンダーＩＤが示される。そして成約した組について、見積金額、成約金額、差額、成約日が記憶される。
見積金額は、成約したオファー情報に示された見積金額である。
成約金額は、成約時の実際の買取金額である。
差額は、見積金額と成約金額の差額である。
成約日は、成約の日時である。
【００５３】
ユーザＤＢ３１、ベンダーＤＢ３２、見積要求情報ＤＢ３３、オファー情報ＤＢ３４、成約情報ＤＢ３５は、例えば以上のように情報が記憶される。もちろん図示していない情報がさらに含まれていてもよいし、図示した情報が全て含まれている必要もない。
なお図３に示したオファー条件ＤＢ３６については第７の実施の形態で用いる情報であるため図３０で後述する。
【００５４】
取引仲介装置２は、これらのＤＢに対して逐次アクセスを行い、新規記憶、更新、読出を行うことになる。例えば取引仲介装置２は、ユーザが自動車買取サービスの利用登録することに応じて、そのユーザについての情報をユーザＤＢ３１に新規登録する。またベンダーが登録することに応じて、そのベンダーについての情報をベンダーＤＢ３２に新規登録する。
また取引仲介装置２は、ユーザ端末５から見積要求情報を取得することに応じて、その見積要求情報に係る情報を見積要求情報ＤＢ３３に新規登録する。
また取引仲介装置２は、オファー情報を取得することに応じて、そのオファー情報に係る情報をオファー情報ＤＢ３４に新規登録する。
さらに取引仲介装置２は、処理過程で逐次、見積要求情報ＤＢ３３やオファー情報ＤＢ３４におけるステータスを更新する。
また取引仲介装置２は、ユーザ端末５又はベンダー端末４から成約情報が通知されることに応じて、その成約の内容に応じて成約情報ＤＢへの情報記憶を行う。
【００５５】
＜３．第１の実施の形態＞
［３−１：システム全体の処理の流れ］
以下、第１の実施の形態としての取引仲介装置２の処理について説明する。
図７は第１（および後述の第２〜第６）の実施の形態における、ユーザ端末５、取引仲介装置２、ベンダー端末４の各情報処理装置間の処理の流れの概要を示している。具体的には、ユーザ端末５による見積要求情報の送信から、ユーザ端末５へのオファー情報の送信までの処理の流れである。
【００５６】
まずステップＳ２１として、自動車の売却を希望するユーザは、ユーザ端末５を用いて見積要求情報ＲＱを取引仲介装置２に送信する。
具体的には、ユーザはユーザＩＤ、パスワードを用いて自動車買取サービスにログインし、所定の見積要求ＷＥＢページに入力項目を入力して送信する。例えばユーザ名、見積対象情報、ユーザ設定条件などを入力する。そして送信操作を行う。すると、これらの情報を含む見積要求情報ＲＱが、取引仲介装置２に送信されることになる。
【００５７】
取引仲介装置２はステップＳ１で見積要求情報ＲＱを受信・取得したら、続いてステップＳ２で、見積要求の紹介情報ＩＲＱをベンダー端末４に送信する。紹介情報ＩＲＱは、見積要求情報ＲＱの内容として、例えば少なくとも見積要求ＩＤと見積対象情報（車種、色、走行距離、オプション、事故歴など）を含むものとする。
図７では図示の都合上、１つのベンダー端末４のみ示しているが、実際にはこの場合、取引仲介装置２は、登録されている複数のベンダーのベンダー端末４ａ，４ｂ・・・に対して、それぞれ紹介情報ＩＲＱを送信することになる。但し、見積対象情報が対応車種（図４Ｂ参照）に該当しないベンダーには紹介情報ＩＲＱを送信しないようにしてもよい。
【００５８】
ステップＳ３１で紹介情報ＩＲＱを受信した各ベンダーは、ステップＳ３２でそれぞれオファー情報ＯＦを生成し、取引仲介装置２に送信する。
取引仲介装置２には、１つの見積要求情報ＲＱに対応して、複数のオファー情報ＯＦが、逐次送信されてくることになる。もちろんすべてのベンダーが紹介情報ＩＲＱに興味を示さず、オファー情報ＯＦが１つも送信されてこないことや、１つ等少数のオファー情報ＯＦしか送信されてこないということもあり得るが、多くの場合、１つの紹介情報ＩＲＱに対応して多数のオファー情報ＯＦが逐次送信されてくる。
なおオファー情報ＯＦは、対応する見積要求ＩＤや、見積金額、オファー発効日、オファー有効期限等を含むものとする。
【００５９】
取引仲介装置２は、ステップＳ３で受信・取得したオファー情報ＯＦのそれぞれについて、ステップＳ４以降の処理を行う。
まずステップＳ４でオファー情報ＯＦに対する比較対象（比較相手）を設定する。そしてステップＳ５で比較／送信可否決定処理を行う。これはオファー情報ＯＦを比較対象と比較する処理を行い、その比較結果に応じて、当該オファー情報ＯＦをユーザ端末５に送信するか否かを決定する処理である。
取引仲介装置２は、ステップＳ６では送信可否の決定結果により処理を分岐する。オファー情報ＯＦについて送信可と決定された場合は、ステップＳ７において、当該オファー情報ＯＦの内容（オファー情報内容ＯＦｖ）を例えば電子メールの形態でユーザ端末５に送信する。なお送信するオファー情報内容ＯＦｖは、オファー情報ＯＦのすべての内容を含んでもよいし、一部の内容のみとしてもよい。
ユーザ端末５では、ステップＳ２２で電子メールによるオファー情報内容ＯＦｖを受信したら、ユーザはその電子メールを開封して、オファーの内容を確認できる。例えばベンダー名称、ベンダーの連絡先、ベンダーのホームページのＵＲＬ（Uniform Resource Locator）、見積価格、オファー有効期限などを確認することができる。以降、ユーザは任意にベンダーとコンタクトをとり、商談を進めることができる。
【００６０】
一方、取引仲介装置２は、ステップＳ５の比較／送信可否決定処理により、或るオファー情報ＯＦについて非送信と決定した場合は、ステップＳ６からＳ８に進み、ベンダーに対して通知を行うか否かを判断する。
通知を行わない場合は、そのまま当該オファー情報ＯＦに関しては、ユーザ端末５にもベンダー端末４にも通知を行わないことになる。
通知を行う場合は、取引仲介装置２はステップＳ９で当該オファー情報ＯＦのオファー元であるベンダー端末４に対して、通知情報ＩＬを送信する。例えば電子メールの形態で通知情報ＩＬをベンダー端末４に送信する。通知情報ＩＬとは、比較処理で劣位となったためユーザ端末５への送信を行わない旨や、再オファーの推奨、オファー対象の変更の推奨などを含む内容とすることが考えられる。
【００６１】
通知情報ＩＬの送信が行われた場合、ベンダー端末４では、ステップＳ３３で通知情報ＩＬを受信する。ベンダーの担当者は、その電子メールを開封して、内容を確認できる。例えばオファーが成約に至らないことの残念通知、再オファーの推奨等を確認できる。
もしベンダーの担当者が、その通知情報ＩＬを確認して、見積金額を高くするなどして再オファーを発行したい場合は、再オファー情報ＯＦ’を送信できる（ステップＳ３４）。この再オファー情報ＯＦ’も通常のオファー情報ＯＦと同様に取引仲介装置２によって取得される。取引仲介装置２は、再オファー情報ＯＦ’についても同様にステップＳ４以降の処理を行う。
【００６２】
以上の全体の流れから理解されるように、本実施の形態では、或る見積要求情報ＲＱに対して、多数のオファー情報ＯＦが発行されても、それがすべてユーザに届くとは限らない。即ち取引仲介装置２において、各オファー情報ＯＦがユーザにとって好ましいもの（例えば検討に値するもの）であるか否かを判断し、好ましいもののみを送信するというフィルタリングが行われる。
以下では、このような取引仲介装置２の詳細な処理例を説明していく。
【００６３】
［３−２：取引仲介装置の処理］
図７のシステム処理を実現する取引仲介装置２の処理例（第１の実施の形態）を図８で説明する。なお、以降、各実施の形態として説明する取引仲介装置２の処理とは、図３で示した機能構成を有する情報処理装置のＣＰＵ１０１によって実行される処理である。具体的には、商取引情報取得部２１、比較対象設定部２２、送信可否決定処理部２３、送信制御部２４としての各機能による処理である。
【００６４】
図８の第１の実施の形態の取引仲介装置２の処理例としては、取引仲介装置２が見積要求情報ＲＱ、オファー情報ＯＦ、又は成約情報を取得することに応じて実行される処理を示している。
取引仲介装置２（商取引情報取得部２１）は、図８のステップＳ１０１、Ｓ１０２，Ｓ１０３でそれぞれ見積要求情報ＲＱ、オファー情報ＯＦ、成約情報の受信を監視している。
【００６５】
ユーザ端末５からの見積要求情報ＲＱが受信された場合は、取引仲介装置２（商取引情報取得部２１）はステップＳ１０１からＳ１０４に進み、当該受信した見積要求情報ＲＱを取り込み、見積要求情報ＤＢ３３へ登録する処理を行う。
即ち受信して取得した見積要求情報ＲＱについて、見積要求ＩＤを設定し、図５Ａの見積要求情報ＤＢ３３に、見積要求ＩＤに紐づけて取得日時、ユーザＩＤ、見積対象情報、ステータス、ユーザ設定条件を記憶する。ユーザＩＤはログイン情報、或いは見積要求情報ＲＱに含まれることで判別される。見積対象情報、ユーザ設定条件は見積要求情報ＲＱに含まれている。ステータスは、この時点では例えば「オファー受付前」などとする。
【００６６】
続いてステップＳ１０５で取引仲介装置２（商取引情報取得部２１）は、紹介先ベンダーの情報を取得する。例えば図４ＢのベンダーＤＢ３２を参照し、各ベンダーの電子メールアドレスを取得する。
なお、紹介先としてベンダーＤＢ３２に登録されたすべてのベンダーを対象としてもよいが、一部でもよい。例えば見積要求情報ＲＱにおける見積対象情報（車種等）と合致する対応車種が記憶されているベンダーのみを抽出したり、あるいは、ユーザＤＢ３１から判定できるユーザの住所から、所在地があまり離れていないベンダーを抽出するなどが考えられる。さらにユーザ設定条件により該当するベンダーを選択してもよい。またベンダーの評価の情報を用いて選択してもよい。
【００６７】
ステップＳ１０６で取引仲介装置２（商取引情報取得部２１）は、紹介先として選定した１又は複数のベンダー端末４に対して、紹介情報ＩＲＱを送信する。例えば紹介情報ＩＲＱとしては、見積要求ＩＤと、見積要求情報ＲＱに記された見積対象情報（車種等）を少なくとも含む電子メールデータを生成し、これをステップＳ１０５で選定した紹介先ベンダーの電子メールアドレス宛に送信する。なお紹介情報ＩＲＱには、見積対象情報の他、ユーザの住所、ユーザ設定条件等を含むようにしてもよい。
また取引仲介装置２は、紹介情報ＩＲＱの送信に応じて、見積要求情報ＤＢ３３における当該見積要求情報ＲＱについてのステータスを「オファー受付中」に更新する。
【００６８】
ベンダー端末４からのオファー情報ＯＦが受信された場合は、取引仲介装置２はステップＳ１０２から、ステップＳ１０７〜Ｓ１１３の処理、つまりオファー情報ＯＦ取得に応じた処理に進むことになる。
オファー情報ＯＦが送信されてくるタイミングは、ベンダーの都合によるため不定である。従って取引仲介装置２は、１つのオファー情報ＯＦの受信の都度、ステップＳ１０２からＳ１０７へ進む。
また、ステップＳ１０２で監視するオファー情報ＯＦの受信とは、上述の再オファー情報ＯＦ’の受信も含む。
【００６９】
ステップＳ１０７では、取引仲介装置２（商取引情報取得部２１）は受信したオファー情報ＯＦを取り込み、オファー情報ＤＢ３４へ登録する処理を行う。
即ち受信して取得したオファー情報ＯＦについて、オファーＩＤを設定し、図５Ｂのオファー情報ＤＢ３４に、オファーＩＤに紐づけて取得日時、ベンダーＩＤ、ユーザＩＤ、見積要求ＩＤ、見積金額、オファー発効日、オファー有効期限、ステータスを記憶する。
ベンダーＩＤはログイン情報、或いはオファー情報ＯＦに含まれることで判別される。見積要求ＩＤ、見積金額、オファー発効日、オファー有効期限はオファー情報ＯＦに含まれている内容である。ユーザＩＤは、見積要求ＩＤを用いて見積要求情報ＤＢ３３を参照することで判別できる。ステータスは、この時点では例えば「比較前」などとする。
【００７０】
なお、受信が再オファー情報ＯＦ’であった場合は、オファー情報ＤＢ３４へ登録は、元のオファー情報ＯＦについての情報において変更部分を更新してもよいし、新規にオファーＩＤを与えて各内容を元のオファー情報ＯＦとは別個に登録してもよい。
【００７１】
ステップＳ１０８で取引仲介装置２（比較対象設定部２２）は、比較対象設定処理を行う。即ち今回取得したオファー情報ＯＦに対して比較相手とする比較対象を設定する。比較対象は固定値の場合もあるし、他のオファー情報を選択する場合もある。各例は後述する。
ステップＳ１０９で取引仲介装置２（送信可否決定処理部２３）は、比較／送信可否決定処理を行う。即ち今回取得したオファー情報ＯＦと比較対象を比較し、当該オファー情報ＯＦについてユーザ端末５への送信を実行するか否かの決定を行う。この比較／送信可否決定処理の各例は後述する。
【００７２】
取引仲介装置２は、ステップＳ１１０では送信可否の決定結果により処理を分岐する。オファー情報ＯＦについて送信可と決定された場合は、取引仲介装置２はステップＳ１１１で送信制御を行う。即ち取引仲介装置２（送信制御部２４）は当該オファー情報ＯＦの内容を示した電子メールデータ（オファー情報内容ＯＦｖ）を生成し、通信部２０からユーザ端末５に送信させる。
ステップＳ１１２では、取引仲介装置２（商取引情報取得部２１）は、オファー情報内容ＯＦｖの送信に応じたＤＢ更新を行う。例えばオファー情報ＤＢ３４における当該オファー情報ＯＦのステータスを「送信済」に更新する。
【００７３】
ステップＳ１０９の比較／送信可否決定処理により、現在処理中のオファー情報ＯＦについて非送信と決定した場合は、取引仲介装置２はステップＳ１１０からＳ１１３に進み、非送信オファー処理を行う。非送信オファー処理とは、送信可否決定処理部２３、送信制御部２４、商取引情報取得部２１によって実行される、非送信と決定したオファーについての処理である。具体的には非送信とされたことをベンダーに通知するか否かの判断や、その判断に応じた通知情報ＩＬの送信制御処理、さらには非送信決定や通知に応じたオファー情報ＤＢ３４におけるステータスの更新処理などである。
非送信オファー処理の各例については後述する。
【００７４】
上述の図７では示していないが、本実施の形態では、ユーザとベンダーの間で取引が成立した場合、ユーザとベンダーの一方又は両方から成約情報が送信されてくるようにしている。
成約情報を受信した場合は、取引仲介装置２（商取引情報取得部２１）は、図８のステップＳ１０３からＳ１１４に進み、成約情報ＤＢ３５の登録を行う。成約情報としては、例えばユーザＩＤ、ベンダーＩＤ、見積要求ＩＤ、オファーＩＤ、成約金額、成約日が含まれているようにする。
取引仲介装置２は、受信・取得した成約情報からこれらの情報を抽出し、成約情報ＤＢに登録する。またオファーＩＤから検索できる見積金額を記憶し、見積金額と成約金額の差額を求めて成約情報ＤＢに記憶する。
【００７５】
なお、再オファー情報ＯＦ’が元のオファー情報ＯＦと異なるオファーＩＤを付与される場合（オファー情報ＤＢ３４参照）、成約情報ＤＢ３５におけるオファーＩＤとしては、再オファー情報ＯＦ’のオファーＩＤと元のオファー情報ＯＦのオファーＩＤが記憶される。
またあるオファーについて対応する見積要求情報ＲＱが変更される場合もあり得るが、その場合、成約情報ＤＢ３５における見積要求ＩＤとしては、成約した見積要求情報の見積要求ＩＤと、変更前の元の見積要求情報ＲＱの見積要求ＩＤも記憶されるようにする。
このようにすることで、再オファーや対応する見積要求情報ＲＱの変更に応じた成約状況も確認できる。
【００７６】
［３−３：比較対象設定処理］
図８のステップＳ１０８として取引仲介装置２（比較対象設定部２２）が実行する各種の比較対象設定処理例を図９〜図１３で説明する。
ここでは比較対象として、オファー情報ＯＦ又は再オファー情報ＯＦ’に含まれる見積金額と比較する金額を設定する例を述べる。
また図８のステップＳ１０８，Ｓ１０９で現在処理対象としている或るオファー情報ＯＦ又は再オファー情報ＯＦ’のことを、以下「現オファー情報ＯＦ」と表記する。
【００７７】
図９Ａは相場情報に基づいて比較対象としての金額を設定する例である。
比較対象設定処理として取引仲介装置２は、まずステップＳ２０１で相場情報を取得する。取引仲介装置２は、現オファー情報ＯＦが対応する見積要求情報ＲＱについての見積対象情報を参照し、該当車種等についての相場情報を取得する。例えば、車種、年式、色、走行距離等から買取相場としての金額を導く。
このためには、車種等の条件で買取相場を検索できる相場ＤＢにアクセスして相場情報を所得することが考えられる。また相場情報は、中古車市場で常に変動するものであるため、相場ＤＢは、市況を反映して更新されるＤＢであることが望ましい。またそのような相場ＤＢを直接利用せずに、相場情報を提供する業者等から相場情報を取得するようにしてもよい。
或いは、成約情報ＤＢ３５から、車種、年式、色、走行距離等が同条件の成約実績を抽出し、その成約金額から求めた値、例えば平均値を相場情報としてもよい。
【００７８】
相場情報を取得したらステップＳ２０２で取引仲介装置２は、相場情報に基づいて比較対象金額を設定する。例えば相場としての金額をそのまま比較対象金額とする。或いは相場としての金額から多少割引又は上乗せした金額を比較対象金額と設定する。
これにより、市況を反映して現オファー情報ＯＦの送信可否決定を行うための比較対象設定が可能となる。
【００７９】
図９Ｂは、ユーザの希望金額を反映する処理例である。
見積要求情報ＲＱには、ユーザの設定情報として、ユーザが取引の希望額、例えば売却の際に希望する最低金額を含めることができる。
現オファー情報ＯＦに対応する見積要求情報ＲＱにこのような希望額が含まれている場合、この希望額に基づいて比較対象金額を設定することもできる。
【００８０】
例えばステップＳ１０８の比較対象設定処理において取引仲介装置２は、図９ＢのステップＳ２１０で、ユーザの希望額が見積要求情報ＲＱに含まれているか否かを確認する。
希望額が存在した場合、取引仲介装置２はステップＳ２１１に進み、ユーザの希望額に基づいて比較対象金額を設定する。例えば希望額そのものを比較対象金額とする。或いは、希望額から所定差額もしくは所定％を割り引いた価格を比較対象金額とするなどである。
【００８１】
一方、見積要求情報ＲＱに希望額が設定されていなければ、取引仲介装置２はステップＳ２１０からＳ２１２に進み、相場情報を取得し、ステップＳ２１３で相場情報に基づいて比較対象金額を設定する。即ち図９Ａの処理を行う。
【００８２】
以上のようにすることで、ユーザの希望額を反映した比較対象金額を設定することができる。
なお、希望額はユーザ自身が任意に設定するものであるため、希望額が実際には市場の実勢価格からかけ離れている場合も想定される。そのため、希望額を、相場情報に基づいて調整することも考えられる。例えばステップＳ２１１において、相場情報として得られる金額の±２０％を有効範囲と設定し、希望額がその有効範囲内であれば、そのまま希望額を比較対象金額とする。希望額が有効範囲内から外れていたら、有効範囲の上限又は下限の金額を比較対象金額とするなどである。
また、ウェブページとしてユーザに提供する見積要求情報の入力画面で、車種等の条件が入力された段階で相場情報を取得し、希望額の有効範囲を提示して、入力範囲を制限するようなことも考えられる。
【００８３】
図１０〜図１３は、現オファー情報ＯＦに対する比較対象金額として、他のオファー情報の見積金額を利用して設定する例である。
なおこれらの例でいう「他のオファー情報ＯＦ」とは、同一の見積要求情報ＲＱに対するオファー情報ＯＦであり、かつ、現オファー情報ＯＦのベンダーとは異なるベンダーのオファー情報ＯＦであるという条件を満たしたオファー情報ＯＦである。
【００８４】
図１０は、１又は複数の他のオファー情報ＯＦの見積金額を比較対象金額に設定する例である。
図１０の場合、取引仲介装置２はステップＳ２２０でオファー情報ＤＢ３４を検索し、現オファー情報ＯＦとは同一の見積要求ＩＤに対応した、異なるベンダーＩＤのオファー情報ＯＦを抽出する。なお図８のステップＳ１０８は、オファー情報の受信がある度に実行されるため、対象となる他のオファー情報ＯＦとは、現オファー情報ＯＦよりも先の時点で取引仲介装置２に受信されたオファー情報となる。
現オファー情報ＯＦとは同一の見積要求ＩＤに対応した、異なるベンダーＩＤのオファー情報という条件で、１又は複数のオファー情報ＯＦが抽出されたら、取引仲介装置２は図１０のステップＳ２２１からＳ２２２に進み、抽出した全オファー情報ＯＦの見積金額を、それぞれ比較対象金額と設定する。従って比較対象金額が複数となることもある。
【００８５】
なお、ステップＳ２２０で条件に該当する他のオファー情報ＯＦが抽出できなかった場合、ステップＳ２２１からＳ２２３に進む。
ステップＳ２２３は、比較対象となり得る他のオファー情報ＯＦが存在しないことから、他のオファー情報ＯＦを利用しないで比較対象金額を設定する処理を行う。例えば図９Ａ、図９Ｂのような処理で比較対象金額を設定すればよい。或いは、何らかの固定値を用いて比較対象金額を設定してもよい。
いずれにしてもステップＳ２２３は、他のオファー情報ＯＦを利用しないで比較対象金額設定を行う処理を表す。以下ではステップＳ２２３の処理を「他オファー不使用設定処理」と呼び、他の処理例でもステップＳ２２３として記載する。
【００８６】
以上の図１０の処理では、同一の見積要求情報ＲＱに対する競合するオファー情報ＯＦが用いられて、現オファー情報ＯＦに対する比較対象金額が設定される。このためその後の比較／送信可否決定処理では、各ベンダーのオファー情報ＯＦ同士で競争するように比較処理が行われることになり、オファー情報ＯＦ間の競争で、現オファー情報ＯＦがユーザに送信されるか否かが決定されるようにすることができる。
【００８７】
次に図１１Ａ、図１１Ｂは、１又は複数の他のオファー情報ＯＦのうちで、ユーザにとって最もよい優位なオファー情報ＯＦの見積金額を比較対象金額に設定する例である。
【００８８】
図１１Ａの例では、取引仲介装置２はステップＳ２４０でオファー情報ＤＢ３４を検索し、現オファー情報ＯＦとは同一の見積要求ＩＤに対応した、異なるベンダーＩＤのオファー情報ＯＦを抽出する。
この条件に該当する１又は複数のオファー情報ＯＦが抽出されたら、取引仲介装置２はステップＳ２４１からＳ２４２に進み、抽出した全オファー情報ＯＦのうちで、見積金額が最もユーザにとって優位（つまり買取見積額として最高値）のオファー情報ＯＦを選択する。そしてステップＳ２４３で、最も優位なオファー情報ＯＦの見積金額を、比較対象金額と設定する。
なお、ステップＳ２４０で条件に該当する他のオファー情報ＯＦが抽出できなかった場合、ステップＳ２４１からＳ２２３に進み、他オファー不使用設定処理を行う。
【００８９】
図１１Ｂの例では、取引仲介装置２はステップＳ２５０でオファー情報ＤＢ３４を検索し、現オファー情報ＯＦとは同一の見積要求ＩＤに対応した、異なるベンダーＩＤのオファー情報ＯＦを抽出する。
さらにステップＳ２５１では、ステップＳ２５０で抽出したオファー情報ＯＦのうちで、取引仲介装置２が現オファー情報ＯＦ以前に取得したオファー情報ＯＦを抽出する。即ちオファー情報ＤＢ３４の取得日時の情報に基づいてオファー情報ＯＦを絞り込む。
以上のステップＳ２５０，Ｓ２５１の条件に該当する１又は複数のオファー情報ＯＦが抽出されたら、取引仲介装置２はステップＳ２５２からＳ２５３に進み、抽出した全オファー情報ＯＦのうちで、見積金額が最もユーザにとって優位なオファー情報ＯＦを選択する。そしてステップＳ２４３で、最も優位なオファー情報ＯＦの見積金額を、比較対象金額と設定する。
なお、ステップＳ２５０、Ｓ２５１で条件に該当する他のオファー情報ＯＦが抽出できなかった場合、ステップＳ２５２からＳ２２３に進み、他オファー不使用設定処理を行う。
【００９０】
以上の図１１Ａ、図１１Ｂでは、同一の見積要求情報ＲＱに対する競合するオファー情報ＯＦのうちで、競合相手として最も強力なオファー情報ＯＦが用いられて、現オファー情報ＯＦに対する比較対象金額が設定される。このためその後の比較／送信可否決定処理では、現オファー情報ＯＦは、最も強力な競合相手と比較されてユーザに送信されるか否かが決定されることになる。
【００９１】
次に図１２Ａ、図１２Ｂは、１又は複数の他のオファー情報ＯＦのうちで、ユーザ端末５に送信された、もしくは送信すると決定されたオファー情報ＯＦの見積金額を用いて比較対象金額を設定する例である。
【００９２】
図１２Ａの例では、取引仲介装置２はステップＳ２６０でオファー情報ＤＢ３４を検索し、現オファー情報ＯＦとは同一の見積要求ＩＤに対応した、異なるベンダーＩＤのオファー情報ＯＦを抽出する。
さらにステップＳ２６１では、ステップＳ２６０で抽出したオファー情報ＯＦについてステータスを確認し、ステータスが「送信済」とされているオファー情報ＯＦを抽出し、さらにその中で、送信日時が最も新しいオファー情報ＯＦを選択する。
以上のステップＳ２６０，Ｓ２６１の条件に該当するオファー情報ＯＦ、即ち直近にユーザ端末５に送信されたオファー情報ＯＦが抽出されたら、取引仲介装置２はステップＳ２６２からＳ２６３に進み、当該オファー情報ＯＦの見積金額を、比較対象金額と設定する。
なお、ステップＳ２６０、Ｓ２６１で条件に該当する他のオファー情報ＯＦが抽出できなかった場合、ステップＳ２６２からＳ２２３に進み、他オファー不使用設定処理を行う。
【００９３】
図１２Ｂの例では、取引仲介装置２はステップＳ２７０でオファー情報ＤＢ３４を検索し、現オファー情報ＯＦとは同一の見積要求ＩＤに対応した、異なるベンダーＩＤのオファー情報ＯＦを抽出する。
さらにステップＳ２７１では、ステップＳ２７０で抽出したオファー情報ＯＦについてステータスを確認し、ステータスが「送信済」又は「送信決定」とされているオファー情報ＯＦを抽出する。つまり既にユーザ端末５に送信された、もしくはまだ未送信であるが送信すると決定されたオファー情報ＯＦを抽出する。
以上のステップＳ２７０，Ｓ２７１の条件に該当する１又は複数のオファー情報ＯＦが抽出されたら、取引仲介装置２はステップＳ２７２からＳ２７３に進み、抽出した全オファー情報ＯＦの見積金額の平均値を算出し、平均値を比較対象金額と設定する。
なお、ステップＳ２７０、Ｓ２７１で条件に該当する他のオファー情報ＯＦが抽出できなかった場合、ステップＳ２７２からＳ２２３に進み、他オファー不使用設定処理を行う。
【００９４】
なおステップＳ２７３では、ユーザ端末５に送信された、もしくは送信すると決定されたオファー情報ＯＦの見積金額の平均値ではなく、最高値、最低値、重心値等を用いてもよい。
【００９５】
以上の図１２Ａ、図１２Ｂでは、同一の見積要求情報ＲＱに対する競合するオファー情報ＯＦのうちで、ユーザへの送信対象となったオファー情報ＯＦが用いられて、現オファー情報ＯＦに対する比較対象金額が設定される。このためその後の比較／送信可否決定処理では、現オファー情報ＯＦは、これまでの送信対象のオファー情報ＯＦを基準に、送信に適しているか否かが判定されることになる。
なお、ユーザへの送信対象となった複数のオファー情報ＯＦの見積金額の全てを比較対象金額とする例も考えられる。
【００９６】
次に図１３Ａ、図１３Ｂ、図１３Ｃは、１又は複数の他のオファー情報ＯＦのうちで、ユーザが興味を持ったと推定されるオファー情報ＯＦの見積金額を用いて比較対象金額を設定する例である。
【００９７】
図１３Ａの例では、取引仲介装置２はステップＳ２８０でオファー情報ＤＢ３４を検索し、現オファー情報ＯＦとは同一の見積要求ＩＤに対応した、異なるベンダーＩＤのオファー情報ＯＦを抽出する。
さらにステップＳ２８１では、ステップＳ２８０で抽出したオファー情報ＯＦのうちで、ユーザの反応があったオファー情報ＯＦを抽出する。具体的にはまず、図１２Ａで説明したように、ステータスが「送信済」とされているオファー情報ＯＦを抽出する。さらにその中で、ユーザがオファー情報内容ＯＦｖの電子メールに興味をもったものを抽出する。
ユーザの興味は、電子メールに対するユーザの反応に応じて推定する。例えば電子メールで送信するオファー情報内容ＯＦｖに、ベンダーのホームページのＵＲＬや、ベンダーの買取情報、履歴情報、評判情報などを提示するウェブページのＵＲＬ等のリンクを付加しておく。ユーザがＵＲＬをクリックして該当ページを閲覧したというようなユーザアクションは、当該ＵＲＬに対するリダイレクトの情報等により検出することができる。
或いは、オファー情報内容ＯＦｖの電子メールに対する返信を受け付けるようにし、ユーザからの返信の有無により、オファー情報ＯＦに対する興味有無を推定してもよい。
取引仲介装置２は、例えばこれらの手法により、各オファー情報ＯＦについてユーザ反応の有無を確認し、ユーザ反応があったオファー情報ＯＦを抽出する。
【００９８】
以上のステップＳ２８０，Ｓ２８１の条件に該当するオファー情報ＯＦ、即ちユーザ反応があったとしてユーザが興味を示していると推定されるオファー情報ＯＦが抽出されたら、取引仲介装置２はステップＳ２８２からＳ２８３に進み、抽出した全オファー情報ＯＦの見積金額を、比較対象金額と設定する。
なお、ステップＳ２８０、Ｓ２８１で条件に該当する他のオファー情報ＯＦが抽出できなかった場合、ステップＳ２８２からＳ２２３に進み、他オファー不使用設定処理を行う。
【００９９】
図１３Ｂの例は、ステップＳ２８０，Ｓ２８１，Ｓ２８２，Ｓ２２３は図１３Ａと同様である。取引仲介装置２はステップＳ２８４では、ユーザの反応があったとして抽出されたオファー情報ＯＦのうちで、ユーザにとって最も優位なオファー情報ＯＦを選択する。例えば最も見積金額が高いオファー情報ＯＦである。そしてステップＳ２８５でそのオファー情報ＯＦの見積金額を、比較対象金額と設定する。
【０１００】
図１３Ｃの例も、ステップＳ２８０，Ｓ２８１，Ｓ２８２，Ｓ２２３は図１３Ａと同様である。取引仲介装置２はステップＳ２８６では、ユーザの反応があったとして抽出された全オファー情報ＯＦの見積金額の平均値を求める。そしてその平均値を比較対象金額と設定する。
なお見積金額の平均値ではなく、最高値、最低値、重心値等を用いてもよい。
【０１０１】
以上の図１３Ａ、図１３Ｂ、図１３Ｃでは、同一の見積要求情報ＲＱに対する競合するオファー情報ＯＦのうちで、ユーザが興味を持ったと推定されるオファー情報ＯＦが用いられて、現オファー情報ＯＦに対する比較対象金額が設定される。このためその後の比較／送信可否決定処理では、現オファー情報ＯＦは、推定されるユーザの思惑を基準に、送信に適しているか否かが判定されるようにすることができる。
【０１０２】
ここまで比較対象の設定例を説明したが、比較対象の設定処理例は他にも多様に考えられる。また図９〜図１３の処理の組み合わせによってもよい。さらには、状況に応じて適用する処理を変化させてもよい。状況とは、例えばオファー情報ＯＦの取得状況、ユーザ端末５への送信数、送信頻度、時間帯、商品市場の状況、相場状況などである。
【０１０３】
［３−４：比較／送信可否決定処理］
続いて、図８のステップＳ１０９として取引仲介装置２（送信可否決定処理部２３）が実行する各種の比較／送信可否決定処理例を図１４〜図１８で説明する。
ここでは上述のように設定された比較対象金額と、現オファー情報ＯＦの見積金額とを比較し、その比較結果に応じてユーザ端末５への送信可否を決定する処理例を述べる。
【０１０４】
なお、以下の各例の比較／送信可否決定処理において、現オファー情報ＯＦの見積金額と比較対象金額が同額であった場合は、現オファー情報ＯＦの見積金額がユーザにとって優位な金額である場合と同様に扱うこととしている。基準となる比較対象金額と同額であれば、ユーザにとっては検討に値するオファーであると推定できるためである。ただし、ユーザへ提示するオファーの数の増大を防ぐという観点からは、現オファー情報ＯＦの見積金額と比較対象金額が同額であった場合は、逆に、現オファー情報ＯＦの見積金額がユーザにとって劣位な金額である場合と同様に扱うこととしてもよい。
【０１０５】
図１４、図１５，図１６は、現オファー情報ＯＦに含まれる見積金額が、比較対象金額よりも取引要求者側にとって優位な金額である場合に、当該オファー情報ＯＦについてオファー情報内容ＯＦｖをユーザ端末５への送信を実行すると決定する例である。
【０１０６】
まず図１４は、１つの比較対象金額が設定される場合に対応する。例えば比較対象設定処理が図９Ａ、図９Ｂ、図１１Ａ、図１１Ｂ、図１２Ｂ、図１３Ｂ、図１３Ｃのように行われる場合に対応する。
この図１４の場合、取引仲介装置２はステップＳ３００で現オファー情報ＯＦの見積金額と比較対象金額を比較する。そして現オファー情報ＯＦの見積金額がユーザにとって優位又は同額であれば、ステップＳ３０１からＳ３０２に進み、取引仲介装置２は現オファー情報ＯＦのオファー情報内容ＯＦｖをユーザ端末５へ送信すると決定する。
現オファー情報ＯＦの見積金額がユーザにとって劣位な金額であれば、取引仲介装置２はステップＳ３０１からＳ３０３に進み、現オファー情報ＯＦのオファー情報内容ＯＦｖをユーザ端末５へは送信しないと決定する。
従ってこの例では、現オファー情報ＯＦは、見積金額が単純に比較対象金額と比較されて送信可否が決定される。
【０１０７】
図１５は、１又は複数の比較対象金額が設定される場合に対応する。例えば比較対象設定処理が図１０、図１３Ａのように行われる場合に対応する。
取引仲介装置２はステップＳ３１０で変数ｎ＝１にセットする。また定数ｎＭＡＸに比較対象設定処理で設定された比較対象金額の数を代入する。
ステップＳ３１１で取引仲介装置２は、第ｎの比較対象金額と現オファー情報ＯＦの見積金額を比較する。
この比較において、現オファー情報ＯＦの見積金額がユーザにとって劣位な金額であれば、ステップＳ３１２からＳ３１６に進み、取引仲介装置２は現オファー情報ＯＦのオファー情報内容ＯＦｖをユーザ端末５へは送信しないと決定する。
【０１０８】
ステップＳ３１１の比較において現オファー情報ＯＦの見積金額がユーザにとって優位又は同等な金額であれば、ステップＳ３１２からＳ３１３に進み、変数ｎが定数（比較対象数）ｎＭＡＸに達しているか否かを判断する。
ｎ≧ｎＭＡＸであれば、取引仲介装置２はステップＳ３１５に進み、現オファー情報ＯＦのオファー情報内容ＯＦｖをユーザ端末５へ送信すると決定する。
ｎ≧ｎＭＡＸでなければ、取引仲介装置２はステップＳ３１４で変数ｎをインクリメントした後、ステップＳ３１１で第ｎの比較対象金額と現オファー情報ＯＦの見積金額を比較する。
【０１０９】
即ちこの例の場合、現オファー情報ＯＦの見積金額を１又は複数の比較対象金額と順次比較していき、一度でも現オファー情報ＯＦの見積金額が劣位であれば、非送信と決定する。現オファー情報ＯＦの見積金額が、すべての比較対象金額よりも優位又は同等であれば、送信と決定することになる。
【０１１０】
図１６は、図１５と同じく１又は複数の比較対象金額が設定される場合に対応する例である。
図１６の例では、まず取引仲介装置２はステップＳ３２０で変数ｎ＝１にセットする。また定数ｎＭＡＸに比較対象設定処理で設定された比較対象金額の数を代入する。さらに勝ち数を示す変数ＰＷ、負け数を示す変数ＰＬをそれぞれ０にセットする。
【０１１１】
ステップＳ３２１で取引仲介装置２は、第ｎの比較対象金額と現オファー情報ＯＦの見積金額を比較する。
この比較において現オファー情報ＯＦの見積金額がユーザにとって優位又は同等な金額であれば、ステップＳ３２２からＳ３２３に進み、勝ち数ＰＷをインクリメントする。
また現オファー情報ＯＦの見積金額がユーザにとって劣位な金額であれば、ステップＳ３２２からＳ３２４に進み、負け数ＰＬをインクリメントする。
そしてステップＳ３２５で取引仲介装置２は、変数ｎが定数ｎＭＡＸに達しているか否かを判断する。ｎ≧ｎＭＡＸでなければ、取引仲介装置２はステップＳ３２６で変数ｎをインクリメントした後、ステップＳ３２１に戻って第ｎの比較対象金額と現オファー情報ＯＦの見積金額を比較する。
【０１１２】
ステップＳ３２５で変数ｎが比較対象数である定数ｎＭＡＸに達した時点では、現オファー情報ＯＦの見積金額が、優位又は同等であった場合の数が勝ち数ＰＷとして保持され、劣位であった場合の数が負け数ＰＬとして保持されている。
そこでステップＳ３２５でｎ≧ｎＭＡＸとなった時点でステップＳ３２７に進み、取引仲介装置２は勝ち数ＰＷと負け数ＰＬを比較する。
勝ち数ＰＷ≧負け数ＰＬであったら、取引仲介装置２はステップＳ３２８に進み、現オファー情報ＯＦのオファー情報内容ＯＦｖをユーザ端末５へ送信すると決定する。
勝ち数ＰＷ≧負け数ＰＬでなければ、取引仲介装置２はステップＳ３２９に進み、現オファー情報ＯＦのオファー情報内容ＯＦｖを非送信と決定する。
【０１１３】
即ちこの例の場合、現オファー情報ＯＦの見積金額を１又は複数の比較対象金額と順次比較していき、現オファー情報ＯＦの勝ち数（優位又は同等となった数）と、負け数（劣位となった数）を判定する。そして勝ち数が負け数以上となったら送信と決定するものである。
なお、この場合は勝率（ＰＷ÷ｎＭＡＸ）が５割以上の場合を送信と決定したが、５割でなくてもよい。例えば７割以上、３割以上などとする処理例も考えられる。
【０１１４】
続いて図１７，図１８は、現オファー情報に含まれる見積金額が、比較対象金額よりも取引要求者側にとって劣位な金額である場合にも、送信と決定される場合が生ずる例である。即ち現オファー情報の見積金額が劣位であっても、金額差分が第１閾値ｔｈＤ１未満であれば、当該オファー情報ＯＦのオファー情報内容ＯＦｖをユーザ端末５へ送信すると決定する
なお図１７，図１８は１つの比較対象金額が設定される場合に対応する例としている。  
【０１１５】
図１７の処理例では、まず取引仲介装置２はステップＳ３３０で現オファー情報ＯＦの見積金額と比較対象金額を比較する。そして現オファー情報ＯＦの見積金額がユーザにとって優位又は同額であれば、ステップＳ３３１からＳ３３２に進み、取引仲介装置２は現オファー情報ＯＦのオファー情報内容ＯＦｖをユーザ端末５へ送信すると決定する。
【０１１６】
現オファー情報ＯＦの見積金額がユーザにとって劣位な金額であれば、取引仲介装置２はステップＳ３３１からＳ３３３に進み、差分閾値ｔｈＤ１の設定を行う。この差分閾値ｔｈＤ１の設定処理例については各例を後述するが、差分閾値ｔｈＤ１は、現オファー情報ＯＦの見積金額が劣位であっても金額差が小さければ、送信を許容するとする場合に、その金額差の限度を設定する値である。なお差分閾値ｔｈＤ１は固定値でもよく、固定値の場合はステップＳ３３３の処理は不要である。
次に取引仲介装置２はステップＳ３３４で、現オファー情報ＯＦの見積金額と比較対象金額の差分を算出する。そして取引仲介装置２はステップＳ３３５で差分金額が差分閾値ｔｈＤ１を越えていなければステップＳ３３２で現オファー情報ＯＦのオファー情報内容ＯＦｖをユーザ端末５へ送信すると決定する。
差分金額が差分閾値ｔｈＤ１を越えていれば取引仲介装置２はステップＳ３３６に進み、で現オファー情報ＯＦのオファー情報内容ＯＦｖをユーザ端末５へ送信しないと決定する。
【０１１７】
従ってこの例では、現オファー情報ＯＦは、見積金額が比較対象金額よりも有利又は同等である場合に加え、劣位であったとしても、比較対象金額との差が小さければ（差分閾値ｔｈＤ１を越えていなければ）、ユーザ端末５に送信されるものと決定されることになる。
【０１１８】
図１８は、図１７と同様の考え方で送信決定を行うものであるが、処理手順を変形した例である。
取引仲介装置２はステップＳ３４０で差分閾値ｔｈＤ１の設定を行う。但し差分閾値ｔｈＤ１を固定値とする場合、当該ステップＳ３４０は不要である。
ステップＳ３４１で取引仲介装置２は、変数ＣＰＶに比較対象金額を代入する。
ステップＳ３４２で取引仲介装置２は、比較対象金額ＣＰＶから差分閾値ｔｈＤ１を減算し、減算結果を補正比較対象金額ＣＰＶ’とする。
【０１１９】
ステップＳ３４３で取引仲介装置２は、現オファー情報ＯＦの見積金額と補正比較対象金額ＣＰＶ’を比較する。そして現オファー情報ＯＦの見積金額が、補正比較対象金額ＣＰＶ’よりもユーザにとって優位であれば、ステップＳ３４４からＳ３４５に進み、取引仲介装置２は現オファー情報ＯＦのオファー情報内容ＯＦｖをユーザ端末５へ送信すると決定する。
また現オファー情報ＯＦの見積金額が、補正比較対象金額ＣＰＶ’よりもユーザにとって劣位（又は同額）であれば、ステップＳ３４４からＳ３４６に進み、取引仲介装置２は現オファー情報ＯＦのオファー情報内容ＯＦｖをユーザ端末５へ送信しないと決定する。
つまりこの例では、差分閾値ｔｈＤ１により比較対象金額を補正してから現オファー情報ＯＦの見積金額と比較するようにしたものであり、図１７と同様の結果が得られる。
【０１２０】
なお、以上の図１７，図１８は比較対象金額が１つの場合の例で述べたが、図１５，図１６のように比較対象金額が複数設定される場合にも、この図１７、図１８の考え方を適用できる。
例えば図１５のステップＳ３１２→Ｓ３１６の過程で、図１７のステップＳ３３３，Ｓ３３４，Ｓ３３５を実行し、差分金額が差分閾値ｔｈＤ１未満であればステップＳ３１３に進み、差分金額が差分閾値ｔｈＤ１以上であればステップＳ３１６に進むようにすればよい。
また例えば図１６のステップＳ３２２→Ｓ３２４の過程で図１７のステップＳ３３３，Ｓ３３４，Ｓ３３５を実行し、差分金額が差分閾値ｔｈＤ１未満であれば、ステップＳ３２３で勝ち数ＰＷがインクリメントされ、差分金額が差分閾値ｔｈＤ１以上であれば、ステップＳ３２４で負け数ＰＬがインクリメントされるようにすればよい。
【０１２１】
［３−５：差分閾値設定処理］
上述の図１７におけるステップＳ３３３や、図１８におけるステップＳ３４０で実行される差分閾値ｔｈＤ１の設定処理の例を図１９、図２０で説明する。
なお、図１７，図１８から理解されるように、差分閾値ｔｈＤ１は、大きい値となるほど送信決定判断が緩くなり、小さい値となるほど、送信決定判断が厳しくなる。以下の差分閾値ｔｈＤ１の設定処理例は、状況に応じて送信決定の難易度を調整するものともいえる。
【０１２２】
図１９Ａは差分閾値ｔｈＤ１を、現オファー情報と比較する比較対象とされたオファー情報のオファー元であるベンダーの実績情報を用いて設定する例である。特にこの例では実績とは、ベンダーの過去の取引における見積金額と成約金額の差額（以下「見積−成約差分」と呼ぶ）とする。
【０１２３】
図１９Ａの例では、取引仲介装置２はステップＳ４０１で現オファー情報ＯＦに対して比較対象に設定された他のオファー情報ＯＦにかかるベンダーの実績情報を取得する。即ち見積金額が比較対象金額として設定されたオファー情報ＯＦのベンダーについてである。
この場合、比較対象とされたオファー情報ＯＦのベンダーＩＤから図６の成約情報ＤＢ３５を検索し、当該ベンダーの成約情報を抽出する。そして１又は複数の成約情報における見積金額と成約金額の差額を読み出す。そして読み出した差額の情報から、見積−成約差分を算出又は取得する。
例えば比較対象となったオファー情報ＯＦのベンダーについて１つの成約情報が成約情報ＤＢ３５に存在する場合、その成約情報に記憶された差額の値を、そのまま見積−成約差分とする。
比較対象となったオファー情報ＯＦのベンダーについて複数の成約情報が成約情報ＤＢ３５に存在する場合、それらの各成約情報に記憶された差額の値から見積−成約差分を求める。例えば次のような例が考えられる。
・該当ベンダーの全ての成約情報における見積金額と成約金額の差額の平均値、最大値、又は最小値
・直近の成約日の成約情報における見積金額と成約金額の差額
・所定期間内の成約日の成約情報における見積金額と成約金額の差額の平均値、最大値、又は最小値
・現オファー情報ＯＦに適合する、つまり車種などの条件が一致または類似の取引における見積金額と成約金額の差額の平均値、最大値、又は最小値
【０１２４】
なお、過去の当該ベンダーの成約情報が存在しない、つまり成約情報ＤＢ３５に当該ベンダーの成約情報が記憶されていなければ、例えば見積−成約差分＝０とすることが考えられる。
【０１２５】
見積−成約差分を取得したら、ステップＳ４０３で、見積−成約差分から補正係数Ｋｈ１を設定する。
見積−成約差分は正負の値をとる。例えばここでは、見積金額よりも成約金額が低くなることを想定して、ベンダーが見積よりも低い価格で買い取った場合の差額を正値、見積よりも高い価格で買い取った場合の差額を負値とする。即ち成約情報ＤＢ３５における「差額」とは、（見積金額）−（成約金額）であるとする。
見積−成約差分が負値となるベンダーは、ユーザにとっては望ましいベンダーである。一方、見積−成約差分が正値となるベンダーは、ユーザにとって望ましくないベンダーとは必ずしもいえないが、見積−成約差分の値が高いベンダーはユーザにとってはあまり望ましくない。見積−成約差分の値（正値）が大きいベンダーは、見積金額の信用度が低いと考えられる。
そこで、例えば見積−成約差分の値が負値であったら、補正係数Ｋｈ＝１（つまり補正なし）とし、見積−成約差分が正値であった場合、その見積−成約差分の値に比例して補正係数Ｋｈが大きくなるようにする（Ｋｈは１以上）。
【０１２６】
そしてステップＳ４０４で取引仲介装置２は、差分閾値ｔｈＤ１の初期値ＤＦｔｈＤ１に補正係数Ｋｈ１を乗算し、乗算結果を差分閾値ｔｈＤ１として設定する。
このように差分閾値ｔｈＤ１を設定することで、比較対象とされたオファー情報ＯＦのベンダーの見積金額の信用度が低いほど、差分閾値ｔｈＤ１が大きくなる。つまり図１７，図１８の処理において、送信判定が緩くなる。つまり比較対象金額の信用度を考慮して、現オファー情報ＯＦの判定が厳しくなりすぎないようにすることができる。
【０１２７】
なお、比較対象が複数設定されている場合、比較対象毎に差分閾値ｔｈＤ１が設定されることが望ましい。比較対象毎に見積金額の信用度が異なるためである。但し、各比較対象との比較に用いる１つの差分閾値ｔｈＤ１を設定するようにしてもよい。例えば見積−成約差分の値が最も大きいベンダーに合わせて設定した差分閾値ｔｈＤ１を他の比較対象との比較にも用いるなどである。
【０１２８】
ところで以上の図１９Ａの例では、比較対象とされたベンダーの実績情報をを用いて差分閾値ｔｈＤ１を設定したが、図１９Ａの変形例として差分閾値ｔｈＤ１を、現オファー情報のオファー元であるベンダーの実績情報をを用いて設定する例も考えられる。
その場合、ステップＳ４０１は、現オファー情報ＯＦにかかるベンダーの実績情報を成約情報ＤＢ３５から取得する処理とする。
そしてステップＳ４０２で現オファー情報ＯＦのベンダーの見積−成約差分を取得し、ステップＳ４０３で補正係数Ｋｈ１を設定する。
【０１２９】
但しこの場合は、現オファー情報ＯＦのベンダーの見積金額の信用度を考慮したものとするため、補正係数Ｋｈの生成論理を次のようにする。
例えば見積−成約差分の値が負値であったら、補正係数Ｋｈ＝１（つまり補正なし）とし、見積−成約差分が正値であった場合、その見積−成約差分の値に反比例して補正係数Ｋｈが低くなるようにする（Ｋｈは１未満）。
そしてステップＳ４０４で取引仲介装置２は、差分閾値ｔｈＤ１の初期値ＤＦｔｈＤ１に補正係数Ｋｈ１を乗算し、乗算結果を差分閾値ｔｈＤ１として設定する。
このように差分閾値ｔｈＤ１を設定することで、現オファー情報ＯＦのベンダーが、見積金額の信用度が低いベンダーであるほど、差分閾値ｔｈＤ１が小さくなる。つまり図１７，図１８の処理において、送信判定が厳しくなる。このような例によっても、ベンダーの実績情報を考慮した送信可否判定が可能となる。
【０１３０】
なお、以上の図１９Ａの例、またその変形例において、見積−成約差分をベンダーの実績情報としたが、これ以外に、あるいはこれと併せて、ベンダーの過去の成約数、直近所定期間の成約数、直近所定期間の見積−成約差額、評価情報（図４Ｂ参照）などを差分閾値ｔｈＤ１の設定に用いてもよい。
また、比較対象とされたオファー情報ＯＦのオファー元ベンダーの実績情報と、現オファー情報のオファー元ベンダーの実績情報の両方を用いて差分閾値ｔｈＤ１を設定することも考えられる。例えば図１９Ａの処理で求めた差分閾値ｔｈＤ１と、上記の変形例の処理で求めた差分閾値ｔｈＤ１の平均値を使用する差分閾値ｔｈＤ１とするなどである。
【０１３１】
続いて図１９Ｂ、図２０Ａは、差分閾値ｔｈＤ１を、現オファー情報ＯＦの対象であるユーザ端末５へのオファー情報に関する送信実行状況に基づいて設定する例である。
【０１３２】
まず図１９Ｂの例では、ユーザ端末５への既送信オファー数（送信済みのオファー情報内容ＯＦｖの数）に基づいて差分閾値ｔｈＤ１を設定する。
取引仲介装置２はステップＳ４１０で現オファー情報ＯＦに対応する見積要求ＩＤについての送信済みオファー数を取得する。例えばオファー情報ＤＢ３４を検索し、見積要求ＩＤが現オファー情報ＯＦと同一で、ステータスが「送信済」となっているオファー情報ＯＦの数を確認する。
ステップＳ４１１で取引仲介装置２は、送信済みオファー数に応じて補正ステップ、補正方向を設定する。補正ステップ数とは、例えば差分閾値ｔｈＤ１の補正単位を何ステップ分変更するかの値である。補正方向は、差分閾値ｔｈＤ１を小さくするか大きくするかの方向である。
そして、ステップＳ４１２で取引仲介装置２は、現在の差分閾値ｔｈＤ１について、補正方向に補正ステップ分だけ増減する。
【０１３３】
これにより、現オファー情報ＯＦが対応する見積要求情報ＲＱに対して、既に送信したオファー情報内容ＯＦｖの数により、差分閾値ｔｈＤ１が調整される。つまり既送信オファー数が少ない時点では差分閾値ｔｈＤ１は比較的大きいが、既送信オファー数が増えるに従って差分閾値ｔｈＤ１が小さくなるように調整されることになる。
なお、既送信オファー数は、ステータスが「送信済」となっているオファー情報ＯＦの数としたが、ステータスが「送信決定」のものを含むようにしてもよい。
またステップＳ４１２で現在の差分閾値ｔｈＤ１から増減するものとしたが、初期値ＤＦｔｈＤ１から補正方向に補正ステップ分だけ増減するようにしてもよい。
さらに図１９Ａのように補正係数Ｋｈ１の乗算を用いてもよい。例えば送信オファー数に応じて補正係数Ｋｈ１を設定して、差分閾値ｔｈＤ１又は初期値ＤＦｔｈＤ１に乗算する。
なお、図１９Ａの処理において、ベンダーの実績情報に応じて、図１９Ｂのように補正ステップ数と補正方向を設定して差分閾値ｔｈＤ１を設定することも考えられる。
【０１３４】
図２０Ａの例では、ユーザ端末５への直近の既送信オファーからの経過時間に基づいて差分閾値ｔｈＤ１を設定する。
取引仲介装置２はステップＳ４２０で現オファー情報ＯＦに対応する見積要求ＩＤについての送信済みオファーのうち、直近のオファーを取得する。例えばオファー情報ＤＢ３４を検索し、見積要求ＩＤが現オファー情報ＯＦと同一で、ステータスが「送信済」となっているオファー情報ＯＦのうちで、送信日時が最も現在に近いものを抽出する。
ステップＳ４２１で取引仲介装置２は、抽出した直近の既送信オファーの送信日時から現在までの経過時間を算出する。
ステップＳ４２２で取引仲介装置２は、算出した経過時間に応じて補正係数Ｋｈ１を設定する。例えば経過時間が短いほど、補正係数Ｋｈ１を小さくし（Ｋｈ１は１未満）、経過時間が長いほど、補正係数Ｋｈ１を大きくする（Ｋｈ１を１以上）。
そしてステップＳ４２３で取引仲介装置２は、差分閾値ｔｈＤ１の初期値ＤＦｔｈＤ１に補正係数Ｋｈ１を乗算し、乗算結果を差分閾値ｔｈＤ１として設定する。
【０１３５】
これにより、現オファー情報ＯＦが対応する見積要求情報ＲＱに対して、頻繁に送信オファー情報内容ＯＦが送信されているときは、差分閾値ｔｈＤ１は比較的大きくされて、送信決定判断が厳しくなり、あまり送信されなくなったときは、差分閾値ｔｈＤ１が小さくされて送信決定判断が緩くなる。
なお、経過時間に応じて、図１９Ｂのように補正ステップ数徒歩正方向を設定し、現在の差分閾値ｔｈＤ１又は初期値ＤＦｔｈＤ１から補正方向に補正ステップ分だけ増減するようにしてもよい。
【０１３６】
続いて図２０Ｂは、差分閾値ｔｈＤ１を、図１０〜図１３の処理で比較対象に設定された他のオファー情報との比較結果により、ユーザ端末５へ送信しないと決定されたオファー情報ＯＦの数に基づいて設定される例である。
ステップＳ４３０で取引仲介装置２は、現在の比較対象を用いた比較処理によって非送信と決定されたオファー情報ＯＦの数を取得する。例えばオファー情報ＤＢ３４を検索し、見積要求ＩＤが現オファー情報ＯＦと同一で、ステータスが「非送信決定」となっているオファー情報ＯＦの数を確認する。なお、同一の見積要求情報ＲＱに対するオファー情報ＯＦについて比較対象の「他のオファー情報」が変更されることがなければ、ステータスが「非送信決定」となっているオファー情報ＯＦの数を確認すればよいが、「他のオファー情報」が変更されることがある場合は、ステータスが「非送信決定」であり、かつ「比較対象が同一の「他のオファー情報」であったものの数を確認する。なおこのために、オファー情報ＤＢ３４には各オファー情報ＤＢについて比較対象を記憶しておくようにしておくことや、比較対象が変更された時点と、各オファー情報ＯＦの比較処理日時を記憶しておくようにすることが考えられる。
【０１３７】
ステップＳ４３１で取引仲介装置２は、現在の比較対象を用いた比較処理によって非送信と決定されたオファー情報ＯＦの数に応じて補正ステップ、補正方向を設定する。即ち非送信のオファー情報ＯＦの数が多いほど、差分閾値ｔｈＤ１を小さくする方向に補正ステップ数が多く、非送信のオファー情報ＯＦの数が少ないほど、差分閾値ｔｈＤ１を大きくする方向に補正ステップ数が多くされる。
そして、ステップＳ４３２で取引仲介装置２は、現在の差分閾値ｔｈＤ１について、補正方向に補正ステップ分だけ増減する。
【０１３８】
これにより、現オファー情報ＯＦと比較する比較対象としての他のオファー情報が強力すぎて、なかなか送信決定がなされないような場合に、差分閾値ｔｈＤ１が大きくされて送信決定判断が緩くなり、逆に非送信になるオファー情報ＯＦの数が少ないときほど、差分閾値ｔｈＤ１が小さくされて送信決定判断が厳しくなる。
なお、この例において、図１９Ａのように補正係数Ｋｈ１の乗算を用いてもよい。例えば非送信決定数に応じて補正係数Ｋｈ１を設定して、差分閾値ｔｈＤ１又は初期値ＤＦｔｈＤ１に乗算する。
また図９，図１０のように相場情報やユーザ設定に応じて比較対象設定が行われた場合にも、この図２０Ｂの処理は適用できる。
【０１３９】
［３−６：比較処理に関する変形例］
ここで、取引仲介装置２（比較／送信可否決定処理部２３）によって行われる比較処理の変形例を説明する。具体的には図１４のステップＳ３００、図１５のステップＳ３１１、図１６のステップＳ３２１の変形例である。これらステップＳ３００、Ｓ３１１、Ｓ３２１は、現オファー情報ＯＦの見積金額と比較対象金額を比較する処理であるが、図２１Ａ、図２１Ｂ、図２２のような処理例も考えられる。これらは、比較時に、現オファー情報ＯＦの見積金額をユーザ設定条件に応じて補正した比較用見積金額に用いる処理例である。
【０１４０】
図２１Ａの例では、取引仲介装置２はステップＳ５０１で、現オファー情報ＯＦに対応する見積要求情報ＲＱに含まれるユーザ設定条件を取得する。ユーザの設定条件とは、例えばベンダーの所在地やベンダーの実績である。
【０１４１】
ステップＳ５０２で取引仲介装置２は、現オファー情報ＯＦについて、ユーザ設定条件に対する条件判定を行い、条件を満たすか否かを判断する。
例えばベンダーの所在地が条件とされている場合、
・ベンダー所在地のユーザ住所からの距離が所定値以内で条件を満たすか否か
・ユーザが設定した地域範囲にベンダー所在地が含まれているか否か
等の判定を行う。
またベンダーの実績が条件とされている場合、
・ベンダーの過去の見積金額と買取金額の差額（例えば図１９Ａで説明した見積−成約差分）が所定値以内であるか否か
・ベンダーの過去の見積数又は買取数のうち少なくとの一方が所定値以上であるか否か
・ベンダーの評価（多数のユーザによる評価値）が所定値以上であるか否か
等の判定を行う。
【０１４２】
これらのような条件を満たしている場合、取引仲介装置２はステップＳ５０３に進み、現オファー情報ＯＦの見積金額を＋ｘ％（例えば＋２０％）した比較用見積金額とする。
また条件を満たしていない場合、取引仲介装置２はステップＳ５０４に進み、現オファー情報ＯＦの見積金額を−ｙ％（例えば−２０％）した比較用見積金額とする。
ｘ＝ｙでもよいし、ｘ≠ｙでもよい。
そして取引仲介装置２はステップＳ５０５で、比較用見積金額と比較対象金額を比較する。
【０１４３】
ステップＳ３００、Ｓ３１１、Ｓ３２１でこの図２１Ａの処理が行われることで、ユーザの設定条件を満たすオファー情報ＯＦの場合、見積金額がｘ％割り増しされて比較対象金額と比較されるため、ユーザ端末５への送信決定がされやすくなる。一方、ユーザ設定条件を満たさないオファー情報ＯＦの場合、見積金額がｙ％割り引かれるため、送信決定は難しくなる。
【０１４４】
図２１Ｂ、図２２の例は、ユーザ設定条件と、オファー情報に関する条件要素との差の大きさに基づいて、比較用見積金額を算出する例である。
図２１Ｂの場合、まずステップＳ５１０で取引仲介装置２はユーザ設定条件を取得する。ステップＳ５１１で取引仲介装置２は、ユーザ設定条件と現オファー情報ＯＦの差分を算出する。
例えばベンダー所在地が条件とされている場合、ユーザ住所とベンダー所在地の距離が、ユーザ設定条件との「差分」に相当する。
ベンダーの過去の見積数又は買取数の数をユーザが条件設定した場合、その設定数と、ベンダーの見積数又は買取数の差がユーザ設定条件との「差分」に相当する。
ベンダーの評価ポイントをユーザが条件設定した場合、その設定数と、ベンダーの実際の評価値の差がユーザ設定条件との「差分」に相当する。
【０１４５】
ステップＳ５１２で取引仲介装置２は、上記「差分」に応じて補正係数Ｋｈ２を設定する。この場合、差分がユーザ設定条件からみて望ましい場合ほど、補正係数Ｋｈ２を大きくし、望ましくない場合ほど、小さくする。
例えばベンダー所在地が条件の場合、距離が近いほど、補正係数Ｋｈ２は大きくする。
また例えばベンダーの見積数、買取数、評価値がユーザ設定より高く、その差が大きいほど、補正係数Ｋｈ２を大きくする。
【０１４６】
ステップＳ５１４で取引仲介装置２は、現オファー情報ＯＦの見積金額に補正係数Ｋｈ２を乗算して、それを比較用見積金額とする。そしてステップＳ５１４で、比較用見積金額と比較対象金額を比較する。
このような処理により、ユーザによって望ましい度合いが大きいオファー情報ＯＦの場合ほど、比較用見積金額が高くなり、送信決定されやすくなる。
【０１４７】
図２２の処理の場合、まずステップＳ５２０で取引仲介装置２はユーザ設定条件を取得する。ステップＳ５２１で取引仲介装置２は、ユーザ設定条件と現オファー情報ＯＦの条件要素を比較して条件を満たしているか否かを判定する。
【０１４８】
現オファー情報ＯＦがユーザ設定条件を満たしている場合、取引仲介装置２はステップＳ５２２に進み、ユーザ設定条件と現オファー情報ＯＦの差分を算出する（図２１ＢのステップＳ５１１と同様）。
ステップＳ５２２で取引仲介装置２は、上記「差分」に応じて補正係数Ｋｈ３を設定する。差分がユーザ設定条件からみて望ましい場合ほど、補正係数Ｋｈ３を大きくし、望ましくない場合ほど、小さくする。
ステップＳ５２４で取引仲介装置２は、現オファー情報ＯＦの見積金額について（ｘ＋Ｋｈ３）％を割り増しした比較用見積金額を得る。そしてステップＳ５２８で、比較用見積金額と比較対象金額を比較する。「ｘ」とは、例えば図２１Ａで説明した割り増しの値である。
【０１４９】
現オファー情報ＯＦがユーザ設定条件を満たしていない場合、取引仲介装置２はステップＳ５２５に進み、ユーザ設定条件と現オファー情報ＯＦの差分を算出する（ステップＳ５２２と同様）。
ステップＳ５２６で取引仲介装置２は、「差分」に応じて補正係数Ｋｈ３を設定する。この場合は、ステップＳ５２３とは逆に、差分がユーザ設定条件からみて望ましい場合ほど補正係数Ｋｈ３を小さくし、望ましくない場合ほど大きくする。
ステップＳ５２７で取引仲介装置２は、現オファー情報ＯＦの見積金額について（ｙ＋Ｋｈ３）％を割り引きした比較用見積金額を得る。そしてステップＳ５２８で、比較用見積金額と比較対象金額を比較する。「ｙ」とは、例えば図２１Ａで説明した割り引きの値である。
【０１５０】
このような処理により、ユーザによって望ましい度合いが大きいオファー情報ＯＦの場合ほど、比較用見積金額が高くなり、送信決定されやすくなり、またユーザによって望ましくない度合いが大きいオファー情報ＯＦの場合ほど、比較用見積金額が低くなり、送信決定されにくくなる。
【０１５１】
［３−７：非送信オファー処理］
続いて、図８のステップＳ１１３の非送信オファー処理について図２３，図２４で各例を説明する。これは現オファー情報ＯＦが、非送信と決定された場合に行われる処理である。
【０１５２】
図２３Ａの処理例は、非送信決定された場合、特にベンダーへの通知を行わない例である。
ステップＳ６０１で取引仲介装置２は、現オファー情報ＯＦが図８のステップＳ１０９で非送信と決定されたことに応じて、オファー情報ＤＢ３４において現オファー情報ＯＦのステータスを「非送信決定」に更新する。
【０１５３】
図２３Ｂ、図２３Ｃ、図２４Ａ、図２３Ｂの例は、非送信決定したオファー情報について、当該オファー情報のオファー元である取引申込者への通知処理を実行するか否かを決定する処理を行う例である。
【０１５４】
まず図２３Ｂの処理例は、非送信決定された場合、必ずベンダーへの通知を行うようにする例である。
ステップＳ６１０で取引仲介装置２（送信可否決定処理部２３）は、現オファー情報ＯＦが図８のステップＳ１０９で非送信と決定されたことに応じて、現オファー情報ＯＦのベンダーに対して通知を行うと決定し、通知情報を生成する。通知情報の内容については後述する。
そしてステップＳ６１１で取引仲介装置２（送信制御部２４）は通知処理を行う。例えば通知情報としての内容の電子メールデータを生成し、通信部２０から該当ベンダーに対して通知情報ＩＬとしての電子メールを送信する（図７参照）。
そしてステップＳ６１２でオファー情報ＤＢ３４において現オファー情報ＯＦのステータスを「非送信決定」に更新する。
【０１５５】
図２３Ｃの例は、非送信と決定したオファー情報について、オファー情報に含まれる見積金額と比較対象金額の金額差分が所定閾値未満であれば、当該オファー情報のオファー元であるベンダーへの通知処理を実行すると決定する例である。
ステップＳ６２０で取引仲介装置２は、比較処理における金額差分、即ち現オファー情報ＯＦの見積金額と比較対象金額の差額を取得する。
ステップＳ６２１で取引仲介装置２は、当該金額差分が差分閾値ｔｈＤ２以内であるか否かを判断する。
なお、比較／送信可否決定処理が図１５，図１６のように差分閾値ｔｈＤ１を用いて行われる場合、差分閾値ｔｈＤ２＞差分閾値ｔｈＤ１とする。
【０１５６】
比較処理における金額差分が差分閾値ｔｈＤ２以内であったら、取引仲介装置２はステップＳ６２２に進み、現オファー情報ＯＦのベンダーに対して通知を行うと決定し、通知情報を生成する。
そしてステップＳ６２３で取引仲介装置２は通知処理を行う。即ち通知情報としての内容の電子メールデータを生成し、該当ベンダーに対して送信する。
ステップＳ６２４で取引仲介装置２はオファー情報ＤＢ３４において現オファー情報ＯＦのステータスを「非送信決定」に更新する。
【０１５７】
比較処理における金額差分が差分閾値ｔｈＤ２を越えていた場合は、取引仲介装置２はステップＳ６２１からＳ６２４に進み、オファー情報ＤＢ３４において現オファー情報ＯＦのステータスを「非送信決定」に更新する。この場合、ベンダーへの通知処理は行わないことになる。
【０１５８】
この図２３Ｃの処理によれば、非送信と決定されてしまったが、比較処理における金額差分が差分閾値ｔｈＤ２以内であった場合は、ベンダーへの通知が行われる。これは、比較処理で比較対象に負けたが、惜しかった場合に通知を行うということとなる。例えばベンダーが見積金額を多少修正して再オファーすれば、送信決定される可能性が見込まれるような場合に通知が行われる。
一方で、比較処理における金額差分が差分閾値ｔｈＤ２を越える場合は、このベンダーの見積金額は、とても他のベンダー等の比較対象とは競争にならないような負け方であるとし、再オファーしても勝てる見込みがないような場合である。このような場合は通知しないこととする。
【０１５９】
次に図２４Ａの例は、非送信と決定したオファー情報について、オファー元のベンダーによる他のオファー情報の状況に基づいて、通知処理を実行するか否かを決定する例である。
ステップＳ６３０で取引仲介装置２は、現オファー情報ＯＦについてのベンダーの他のオファー情報ＯＦを確認する。例えばオファー情報ＤＢ３４から、同一のベンダーＩＤのオファー情報ＯＦを抽出する。
ステップＳ６３１で取引仲介装置２は、当該ベンダーが、類似商品であって送信済のオファー情報ＯＦが存在するか否かを判断する。即ち当該ベンダーのオファー情報ＯＦのうちで、ステータスが「送信済」のものを抽出する。さらに抽出したオファー情報ＯＦについて見積要求ＩＤをたどって見積要求情報ＤＢ３３を参照し、見積対象情報が同一又は類似であるか否かを確認する。
【０１６０】
もし、当該ベンダーについて、ユーザは問わないが、類似商品であって送信済のオファー情報ＯＦが存在した場合は、通知処理は行わずにステップＳ６３４に進み、オファー情報ＤＢ３４において現オファー情報ＯＦのステータスを「非送信決定」に更新する。
現オファー情報ＯＦの商品とは代替的に、類似商品についてのオファーが或るユーザに送信されているため、現オファー情報ＯＦについては再オファーを求めないとする判断である。
【０１６１】
一方、当該ベンダーについて、類似商品であって送信済のオファー情報ＯＦが存在しなければ、ステップＳ６３２に進み、現オファー情報ＯＦのベンダーに対して通知を行うと決定し、通知情報を生成する。
そしてステップＳ６３３で通知処理を行う。さらにステップＳ６３４でオファー情報ＤＢ３４において現オファー情報ＯＦのステータスを「非送信決定」に更新する。
【０１６２】
この図２４Ａの処理によれば、類似の商品の見積要求情報ＲＱがいくつか存在し、或るベンダーが、それぞれに対してオファー情報ＯＦを発行している場合に、その中で１つ以上、ユーザ端末５に送信されていれば、非送信とされたオファー情報ＯＦについては、再オファーを求めないという処理になる。
【０１６３】
なお、ステップＳ６３０，Ｓ６３１で存在を判断する、類似商品を対象としてユーザ端末５に送信済の当該ベンダーのオファー情報ＯＦとは、所定時間以内のオファー情報を対象とすることが望ましい。古いオファー情報は、現オファー情報との関連性は見込めないためである。
また対象のオファー情報ＯＦとして、見積依頼が継続しているオファーを条件とすることが望ましい。つまり成約に至っておらず、かつユーザによって見積依頼自体がキャンセルされていないことを条件とする。この条件により、通知をしなくても、当該ベンダーの該当商品に取引機会をむやみに奪うことにはならないためである。
【０１６４】
図２４Ｂの例も、非送信と決定したオファー情報について、オファー元のベンダーによる他のオファー情報の状況に基づいて、通知処理を実行するか否かを決定する例であるが、この場合は、他のユーザに対するオファーのうち、類似商品に対するオファーの数が閾値ｔｈＯＮ以下の場合にベンダーへの通知処理を行うものとする。
【０１６５】
ステップＳ６４０で取引仲介装置２は、現オファー情報ＯＦについてのベンダーの他のオファー情報ＯＦを確認する。例えばオファー情報ＤＢ３４から、同一のベンダーＩＤのオファー情報ＯＦを抽出する。
ステップＳ６４１で取引仲介装置２は、他のユーザに対するオファーとして、現オファー情報ＯＦと類似商品に関するオファー情報ＯＦの数を確認する。即ち対応する見積要求情報ＲＱにおける見積対象情報が同一又は類似である各オファー情報ＯＦの数を確認する。
【０１６６】
ステップＳ６４２では、取引仲介装置２は該当のオファー情報ＯＦの数が閾値ｔｈＯＮ以下であるか否かを確認する。
該当のオファー情報ＯＦの数が閾値ｔｈＯＮを越えていれば、通知処理は行わずにステップＳ６４５に進み、オファー情報ＤＢ３４において現オファー情報ＯＦのステータスを「非送信決定」に更新する。
【０１６７】
該当のオファー情報ＯＦの数が閾値ｔｈＯＮ以下であれば、ステップＳ６４３に進み、現オファー情報ＯＦのベンダーに対して通知を行うと決定し、通知情報を生成する。
そしてステップＳ６４４で通知処理を行う。さらにステップＳ６４５でオファー情報ＤＢ３４において現オファー情報ＯＦのステータスを「非送信決定」に更新する。
【０１６８】
この図２４Ｂの処理によれば、類似の商品について多数のオファー情報ＯＦを発行しているベンダーの場合は、現オファー情報ＯＦが非送信と決定されても通知処理は行わない。代替的な商品取引機会が他にも存在するためである。
なお、この例の場合も、ステップＳ６４０，Ｓ６４１で判断する、類似商品を対象とした当該ベンダーのオファー情報ＯＦの数については、所定時間以内のオファー情報、成約に至っておらず、かつユーザによって見積依頼自体がキャンセルされていないオファー情報ＯＦを対象とすることが望ましい。
【０１６９】
以上の図２３，図２４の各例のように非送信オファー処理が行われるが、通知処理の内容としては、以下のようなものが想定される。
・残念通知
ユーザに提示されるオファーとして採用されなかったことの通知である。
・再オファー推奨
見積金額等を修正して再オファー（再オファー情報ＯＦ’の送信）を進める通知である。これによりベンダーに対して再度取引機会を与えることができる。
・オファー先変更推奨
当該オファー情報ＯＦを、他の見積要求情報ＲＱについての変更を進める内容である。例えば異なるユーザから同時期に、同一の車種、色、走行距離範囲等において類似と判断できる商品の見積要求情報ＲＱが複数取得されることは珍しくはない。そこで通知情報において、同一又は類似商品の見積要求情報ＲＱを紹介し、ベンダーに、オファー情報ＯＦの相手先を変更するように勧める。これによりベンダーの取引機会を広げることができる。
【０１７０】
図２３ＢのステップＳ６１０、図２３ＣのステップＳ６２２、図２４ＡのステップＳ６３２、図２４ＢのステップＳ６４３で行われる通知情報生成処理として、再オファー推奨やオファー先変更推奨を含む通知情報生成処理例を図２５Ａ、図２５Ｂに示す。
【０１７１】
図２５Ａは再オファー推奨を行う場合である。
取引仲介装置２はステップＳ６６０で、現オファー情報ＯＦと比較された比較対象金額を取得する。
そしてステップＳ６６１で、比較対象金額を提示し、その比較対象金額以上の見積金額で再オファーを薦める内容を含む通知情報を生成する。即ちどの程度の見積金額で再オファーすれば送信実行と判定される可能性が生ずるかの案内情報を含めたうえで、再オファーを薦める内容とする。これによりベンダーは再オファーを行うか否か判断しやすいものとなる。
なお、比較処理の際に上述の図１７，図１８のように差分閾値ｔｈＤ１を用いる場合、比較対象金額から差分閾値ｔｈＤ１の額を減算した値を、送信判断される可能性のある金額として通知情報内に提示するようにしてもよい。さらに図２１、図２２のように比較処理において補正した比較用見積金額を用いる場合、その補正を考慮した金額を提示してもよい。
【０１７２】
図２５Ｂはオファー先変更を推奨する場合である。
取引仲介装置２は、見積要求情報ＤＢ３３から、現オファー情報ＯＦが取引申入の対象としていた見積要求情報ＲＱと同一又は類似の見積対象情報を有する他の見積要求情報ＲＱを抽出する。
そして抽出した１又は複数の見積要求情報ＲＱについて、ステップＳ６７１でステータスを確認して絞り込みを行う。即ちステータスが「オファー受付前」又は「オファー受付中」の見積要求情報ＲＱを抽出する。「オファー受付終了」や「キャンセル」の見積要求情報ＲＱについては、それらにオファー先を変更しても意味がないためである。
【０１７３】
ステータスが「オファー受付前」又は「オファー受付中」の見積要求情報ＲＱが１以上抽出されたら、ステップＳ６７３に進み、取引仲介装置２はオファー変更先候補のリストを作成する。即ち抽出された見積要求情報ＲＱの一覧である。
そしてステップＳ６７４で取引仲介装置２はオファー変更先候補リストを含む通知情報を生成する。即ち、ベンダーに対して、車種等の見積対象情報が同一又は類似である他の見積要求情報ＲＱをリスト化して提示し、ベンダーに、オファー先変更を提案する内容を含む通知情報を生成する。
【０１７４】
また変更先候補に該当する見積要求情報ＲＱが１つも存在しない場合もある。その場合は取引仲介装置２はステップＳ６７２からＳ６７５に進み、変更先候補リストを含まない通知情報を生成する。例えば上述の残念通知のみの内容とする。
【０１７５】
以上のようにオファー変更先候補が存在する場合は、ベンダーに通知してオファー先変更を推奨することで、ベンダーの取引機会を広げることができる。
なお、オファー変更先推奨と、再オファー推奨の両方を含むようにしてもよい。例えば図２５ＢのステップＳ６７５では、図２５Ａで述べた処理を行って、再オファー推奨を含む通知情報を生成するようにしてもよい。これにより、変更先候補が存在すればオファー先変更推奨が行われ、存在しなければ再オファー推奨を行うという処理が実現される。
また、図２５ＢのステップＳ６７４でも図２５Ａで述べた処理を行って、オファー先変更推奨と再オファー推奨の両方を含む通知情報を生成する例も考えられる。
【０１７６】
＜４．第２〜第６の実施の形態＞
第２〜第６の実施の形態を順次説明する。以下では、第１の実施の形態の図８の処理との相違点のみを説明し、重複説明は避ける。なお第２〜第６の実施の形態でも、図９〜図２５で説明した処理はそれぞれ適用できるものである。
【０１７７】
図２６Ａに第２の実施の形態としての取引仲介装置２の処理を示す。これは図８のステップＳ１０７とＳ１１０の間の処理として示している。即ち比較対象設定処理、比較／送信可否決定処理の実行に関する処理例である。
【０１７８】
この第２の実施の形態では、取引仲介装置２がオファー情報ＯＦを受信し、図８のステップＳ１０７の処理を行った後において、取引仲介装置２は図２６ＡのステップＳ１５０で、現オファー情報ＯＦが対応する見積要求情報ＲＱと同一の見積要求情報ＲＱについての既受信のオファー情報ＯＦの数（既受信オファー数ＮＲ）を確認する。これはオファー情報ＤＢ３４を参照して、現オファー情報ＯＦと対応する見積要求ＩＤが同一のオファー情報ＯＦの数を確認すればよい。
【０１７９】
ステップＳ１５１で取引仲介装置２は、既受信オファー数ＮＲが閾値ｔｈＮＲ以下であるか否かを確認する。
ＮＲ≦ｔｈＮＲであれば、ステップＳ１５２において無条件で送信実行と決定する。
ＮＲ≦ｔｈＮＲでなければ、第１の実施の形態で説明してきたステップＳ１０８の比較対象設定処理、ステップＳ１０９の比較／送信可否決定処理を行う。
そして図８のステップＳ１１０に進む。
【０１８０】
このような第２の実施の形態のでは、例えば閾値ｔｈＮＲ＝１とすれば、或る見積要求情報ＲＱについて最初に送信されてきたオファー情報ＯＦについては、必ずユーザ端末５に送信するものとなる。
また例えば閾値ｔｈＮＲ＝３とすれば、或る見積要求情報ＲＱについて１番目から３番目に受信されたオファー情報ＯＦについては、必ずユーザ端末５に送信するものとなる。
そしてそれら以降に受信されたオファー情報ＯＦについては、比較／送信可否決定処理で送信か非送信かが決められることになる。
このような処理によれば、少なくとも閾値ｔｈＮＲの数に相当するオファー情報ＯＦについては、ユーザ端末５への送信を確保される。従って１以上のオファー情報ＯＦが発行される限り、ユーザへ提示されるオファー情報ＯＦの数がゼロとなるということはない。そのうえで、それ以上の数のオファー情報ＯＦが受信された場合は、ユーザ端末５への送信についてのフィルタリングが行われ、ユーザにとって無用と判定されるオファー情報ＯＦは送信を制限されることになる。
【０１８１】
図２６Ｂに第３の実施の形態としての取引仲介装置２の処理を示す。これも図８のステップＳ１０７とＳ１１０の間の処理として示している。
図８のステップＳ１０７の後、取引仲介装置２はステップＳ１６０で、現オファー情報ＯＦが対応する見積要求情報ＲＱと同一の見積要求情報ＲＱについての既送信のオファー情報ＯＦの数（既送信オファー数ＮＴ）を確認する。これはオファー情報ＤＢ３４を参照して、現オファー情報ＯＦと対応する見積要求ＩＤが同一で、かつステータスが「送信済」のオファー情報ＯＦの数を確認すればよい。なおステータスが「送信決定」のオファー情報ＯＦの数を含めてもよい。
【０１８２】
ステップＳ１６１で取引仲介装置２は、既送信オファー数ＮＲが閾値ｔｈＮＴ１以上であるか否かを確認する。
ＮＲ≧ｔｈＮＴ１でなければ、ステップＳ１６２において無条件で送信実行と決定する。
ＮＲ≧ｔｈＮＴ１であれば、ステップＳ１０８の比較対象設定処理、ステップＳ１０９の比較／送信可否決定処理を行う。
そして図８のステップＳ１１０に進む。
【０１８３】
このような第３の実施の形態のでは、例えば閾値ｔｈＮＴ１＝３とすれば、或る見積要求情報ＲＱについて少なくとも３つのオファー情報ＯＦがユーザ端末５に送信されるまでは、無条件で送信決定される。従って、少なくとも閾値ｔｈＮＴ１の数に相当するオファー情報ＯＦについては、ユーザ端末５への送信を確保される。そのうえで、それ以上の数のオファー情報ＯＦが受信された場合は、ユーザ端末５への送信についてのフィルタリングが行われ、ユーザにとって無用と判定されるオファー情報ＯＦは送信を制限される。
なお、ステップＳ１６０では、既送信オファー数ＮＴは、現在から所定時間前までの間での既送信のオファー情報ＯＦの数としてもよい。このようにすれば、送信が集中しているときは送信可否決定が行われ、送信があまりない時間帯では無条件に送信を行うようにすることができる。
【０１８４】
以上の第２，第３の実施の形態は、送信可否決定を行わずに無条件で送信する場合を設けたものといえる。これらのように無条件送信の場合を設ける例として、例えば直近のオファー情報ＯＦの受信日時や、ユーザ端末５への送信日時からの経過時間で無条件送信を行う例も考えられる。
例えば直近の受信日時又は送信日時から所定時間を経過していなければ、現オファー情報ＯＦについてステップＳ１０８，Ｓ１０９の送信可否判断を行うが、所定時間を経過していれば、そのまま無条件で送信するものである。このような処理によっても、送信が集中しているときは送信可否決定を行って送信数を制限し、送信があまりない時間帯では無条件に送信を行うことで、一時的にユーザへの送信が集中することを避けるような処理が可能となる。
【０１８５】
次に、第４，第５の実施の形態を図２７Ａ、図２７Ｂで説明する。
これらは、比較結果からオファー情報ＯＦに関する送信をユーザ端末５に対して実行するか否かを決定するための条件を、送信対象のユーザ端末５へのオファー情報送信状況に基づいて選択するものである。
【０１８６】
まず第４の実施の形態では、取引仲介装置２は図８のステップＳ１０７の後、図２７ＡのステップＳ１７０で、現オファー情報ＯＦが対応する見積要求情報ＲＱと同一の見積要求情報ＲＱについての既送信のオファー情報ＯＦの数（既送信オファー数ＮＴ）を確認する（図２６ＢのステップＳ１６０と同様）。
ステップＳ１７１で取引仲介装置２は、既送信オファー数ＮＲが閾値ｔｈＮＴ２以上であるか否かを確認する。
ＮＲ≧ｔｈＮＴ２でなければ、ステップＳ１７２で第１の送信可否決定条件を設定する。
ＮＲ≧ｔｈＮＴ２であれば、ステップＳ１７３で第２の送信可否決定条件を設定する。
そしてステップＳ１０８の比較対象設定処理、ステップＳ１０９の比較／送信可否決定処理を行い、その後図８のステップＳ１１０に進む。
【０１８７】
この場合、既送信オファー数が閾値ｔｈＮＴ２より少ない場合の第１の送信可否決定条件とは、比較的緩い条件とする設定である。例えば図１７のように現オファー情報ＯＦの見積金額がユーザにとって劣位であっても差分閾値ｔｈＤ１以内の差であれば、送信実行とする処理を採用する設定である。
一方、第２の送信可否決定条件は比較的厳しい条件とする設定である。例えば図１４のように、現オファー情報ＯＦの見積金額がユーザにとって劣位であったら即座に非送信とされる処理である。
つまり第４の実施の形態では、ユーザ端末５に対して既送信オファー数が多い場合は、送信の条件を厳しくし、既送信オファー数が少ない場合は、送信の条件を緩くすることで、適度な数のオファーがユーザに提示されるようにするものである。
【０１８８】
次に第５の実施の形態では、取引仲介装置２は図８のステップＳ１０７の後、図２７ＢのステップＳ１８０で、現オファー情報ＯＦが対応する見積要求情報ＲＱと同一の見積要求情報ＲＱについての既送信のオファー情報ＯＦのうち、直近のものの送信日時を取得する。例えばオファー情報ＤＢ３４を検索し、見積要求ＩＤが現オファー情報ＯＦと同一で、ステータスが「送信済」となっているオファー情報ＯＦのうちで、送信日時が最も現在に近いものを抽出する。
ステップＳ１８１で取引仲介装置２は、抽出した直近の既送信オファーの送信日時から現在までの経過時間を算出する。
ステップＳ１８２で取引仲介装置２は、経過時間が閾値ｔｈＴＭ以上であるか否かを確認する。
経過時間が閾値ｔｈＴＭ以上であれば、ステップＳ１８３で比較的緩い第１の送信可否決定条件を設定する。例えば図１７の処理を選択する。
経過時間が閾値ｔｈＴＭ以上でなければ、ステップＳ１８４で比較的厳しい第２の送信可否決定条件を設定する。例えば図１４の処理を選択する。
そしてステップＳ１０８の比較対象設定処理、ステップＳ１０９の比較／送信可否決定処理を行い、その後図８のステップＳ１１０に進む。
【０１８９】
これにより、現オファー情報ＯＦが対応する見積要求情報ＲＱに対して、頻繁に送信オファー情報内容ＯＦが送信されているときは、送信決定される条件が厳しくなり、逆にあまり送信が行われていなければ、送信決定される条件が緩くなる。これにより、ユーザに提示されるオファー情報ＯＦの数や頻度が調整される。
【０１９０】
続いて第６の実施の形態を図２８で説明する。
第６の実施の形態は、第１の実施の形態の図８の処理に代えて適用できる処理例である。特には、第６の実施の形態は、オファー情報ＯＦについての送信可否判断を逐次受信時ではなく、或るタイミングでまとめて行う例である。なお、図２８において図８と同一の処理は同一のステップ番号を付し、説明を省略する。
【０１９１】
図２８Ａは、取引仲介装置２が見積要求情報ＲＱ、オファー情報ＯＦ、成約情報の受信に応じて実行する処理を示している。
見積要求情報ＲＱの受信に応じて、ステップＳ１０１からステップＳ１０４（見積要求情報の登録），Ｓ１０５（紹介先ベンダーの情報取得），Ｓ１０６（紹介情報送信）の処理が図８と同様に行われる。
オファー情報ＯＦの受信に応じて、ステップＳ１０２からステップＳ１０７（オファー情報の登録）の処理が図８と同様に行われる。
成約情報の受信に応じてステップＳ１０３からＳ１１４の処理（成約情報の登録）が図８と同様に行われる。
【０１９２】
取引仲介装置２は、この図２８Ａの処理とは並行して、或るタイミングで図２８Ｂの処理を実行する。
即ちステップＳ１２０で実行タイミングを検知したら、取引仲介装置２はステップＳ１２１で未処理のオファー情報ＯＦを取得する。これは、受信されたが、まだ送信可否決定を行っていないオファー情報ＯＦ（例えばステータスが「比較前」のオファー情報ＯＦ）をオファー情報ＤＢ３４から抽出する処理となる。
そして抽出した各オファー情報ＯＦのそれぞれについて、ステップＳ１０８の比較対象設定処理、ステップＳ１０９の比較／送信可否決定処理を行う。
ステップＳ１２２では、比較／送信可否決定処理で送信実行と決定された１又は複数のオファー情報ＯＦのそれぞれについてのユーザ端末５への送信制御（図８のステップＳ１１１と同様の処理）を行う。
ステップＳ１２３では、比較／送信可否決定処理で非送信と決定された１又は複数のオファー情報ＯＦのそれぞれについての非送信オファー処理（図８のステップＳ１１３と同様の処理）を行う。
ステップＳ１２４で、各オファー情報ＯＦについて、送信／非送信に応じたＤＢ更新、即ちオファー情報ＤＢ３４のステータス更新を行う。
【０１９３】
このような処理例でも、図８と同様に、オファー情報ＯＦのユーザへの提示に関してのフィルタリングを行うことができる。
なおステップＳ１２０の実行タイミングの例は各種考えられる。
実行タイミングは一定時間毎としてもよい。また時間帯によって可変的なタイミングを設定してもよい。例えばオファー情報ＯＦの受信が多い時間帯や少ない時間帯で、それぞれ異なる間隔で実行タイミングを設定してもよい。
また、ステータスが「比較前」のオファー情報ＯＦが所定数たまった時点を実行タイミングとしてもよい。
またユーザ端末５宛の直近の送信からの経過時間が所定時間となった時点を実行タイミングとしてもよい。
【０１９４】
＜５．第７の実施の形態＞
第７の実施の形態を図２９，図３０，図３１により説明する。
第７の実施の形態は、ベンダーが逐次オファー情報ＯＦを送信するのではなく、見積要求情報ＲＱに対応して、取引仲介装置２が各ベンダーのオファー情報ＯＦを生成する例である。
【０１９５】
図２９にシステム全体の処理の流れを示す。なお図７と同一部分は同一ステップ番号を付して説明を省略する。
この場合、ステップＳ３０としてベンダーはベンダー端末４から取引仲介装置２に、あらかじめオファー条件情報ＯＦＣを通知しておく。取引仲介装置２はステップＳＳ０でオファー条件情報ＯＦＣを受信すると、これをオファー条件ＤＢ３６に登録しておく。
【０１９６】
その後、ステップＳ２１でユーザ端末５から見積要求情報ＲＱが送信されてきたら、取引仲介装置２はステップＳ１で受信した後、ステップＳ３Ａでオファー情報ＯＦの生成を行うことになる。
つまりベンダー端末４への紹介情報ＩＲＱの送信を行うことなく、取引仲介装置２が、各ベンダー端末４から受け取っていたオファー条件情報ＯＦＣに基づいて、各ベンダーについてのオファー情報ＯＦを生成する。
そして生成した各オファー情報ＯＦのそれぞれについて、ステップＳ４（比較対象設定処理）、Ｓ５（比較／送信可否決定処理）、Ｓ６（送信可否決定に応じた処理分岐）、Ｓ７（オファー情報内容ＯＦｖのユーザ端末５への送信）、Ｓ８（通知判定）、Ｓ９（通知情報ＩＬのベンダー端末４への送信）の処理を、図７の場合と同様に行うことになる。
なお、ステップＳ９の通知情報ＩＬに応じてベンダー端末４から再オファー情報ＯＦ’が送信されてきた場合は、取引仲介装置２はステップＳ３Ａでその再オファー情報ＯＦ’を取得し、再オファー情報ＯＦ’についてもステップＳ４〜Ｓ９の処理を行う。
【０１９７】
オファー条件ＤＢ３６の構成例を図３０に示す。
ベンダーＩＤ（Ｖ１、Ｖ２・・・）で示されるベンダー毎に、１又は複数のオファー条件と、それに応じた見積価格が記憶される。
例えばベンダーは、車種、色、年式、走行距離と、その場合の見積金額をセットにした１又は複数のオファー条件情報ＯＦＣをあらかじめ取引仲介装置２に提供しておく。取引仲介装置２はこのようなオファー条件情報ＯＦＣをオファー条件ＤＢ３６に登録しておく。これにより取引仲介装置２は、ユーザ端末５からの見積要求情報ＲＱを受信した際に、オファー条件ＤＢ３６を参照して、各ベンダーのオファー情報ＯＦを生成することができる。
なお、ベンダーが、取引仲介装置２に提供するオファー条件情報ＯＦＣは、車種等の各条件から見積金額を導くアルゴリズム、プログラム等でもよく、それらがオファー条件ＤＢ３６に登録されていてもよい。
【０１９８】
図３１は、第７の実施の形態における取引仲介装置２の処理例である。第１の実施の形態の図８に相当する処理であり、同一処理には同一のステップ番号を付す。
取引仲介装置２は、図３１のステップＳ１０１、Ｓ１０１，Ｓ１０３で見積要求情報ＲＱ、オファー情報ＯＦ、成約情報の受信を監視している。
【０１９９】
ユーザ端末５からの見積要求情報ＲＱが受信された場合は、取引仲介装置２はステップＳ１０１からＳ１０４に進み、当該受信した見積要求情報ＲＱを取り込み、見積要求情報ＤＢ３３へ登録する処理を行う（図８と同様）。
【０２００】
続いてステップＳ１３０で取引仲介装置２は、紹介先ベンダーの情報を取得する。ここではオファー条件ＤＢ３６から、各ベンダーのオファー条件情報を読み出すことになる。
そしてステップＳ１３１で取引仲介装置２は、各ベンダーについてのオファー情報ＯＦを生成する。
【０２０１】
オファー条件情報があらかじめ提示されていた各ベンダーについてのオファー情報ＯＦを生成したら、取引仲介装置２はそれぞれのオファー情報ＯＦについて、ステップＳ１０８Ａ（比較対象設定処理）、Ｓ１０９Ａ（比較／送信可否決定処理）を行う。
ステップＳ１１１Ａでは、比較／送信可否決定処理で送信実行と決定された１又は複数のオファー情報ＯＦのそれぞれについてのユーザ端末５への送信制御（図８のステップＳ１１１と同様の処理）を行う。
ステップＳ１１３Ａでは、比較／送信可否決定処理で非送信と決定された１又は複数のオファー情報ＯＦのそれぞれについての非送信オファー処理（図８のステップＳ１１３と同様の処理）を行う。
ステップＳ１２４Ａで、各オファー情報ＯＦについて、送信／非送信に応じたＤＢ更新、即ちオファー情報ＤＢ３４のステータス更新を行う。
【０２０２】
この図３１の場合、ステップＳ１０２で監視する、ベンダー端末４からのオファー情報ＯＦが受信される場合とは、再オファー情報ＯＦ’が送信された場合と想定される。
この場合、取引仲介装置２はステップＳ１０２から、ステップＳ１０７に進み、受信した再オファー情報ＯＦ’を取り込み、オファー情報ＤＢ３４へ登録する処理を行う。
そして、ステップＳ１０８Ｂ（比較対象設定処理）、Ｓ１０９Ｂ（比較／送信可否決定処理）、およびステップＳ１１０、Ｓ１１１Ｂ、Ｓ１１２Ｂ、Ｓ１１３Ｂを、図８のステップＳ１０８〜Ｓ１１３と同様に行う。
【０２０３】
成約情報を受信した場合は、取引仲介装置２は、ステップＳ１０３からＳ１１４に進み、図８と同様に成約情報ＤＢ３５の登録を行う。
【０２０４】
このような第７の実施の形態によれば、第１〜第６の実施の形態と同様にオファー情報ＯＦのユーザ端末５への送信に関するフィルタリングが行われる。さらにこの場合、オファー情報ＯＦは取引仲介装置２が生成する。このためベンダーのスタッフが見積要求情報ＲＱに対して常に待機している必要はない。従ってベンダーの負担は著しく軽減される。
【０２０５】
＜６．第８の実施の形態＞
第８の実施の形態を図３２，図３３，図３４により説明する。
この第８の実施の形態は、オファー情報内容ＯＦｖをユーザ端末５に送信するのではなく、オファー情報ＯＦの内容については、特に制限せずにウェブサイトに提示する。但し各オファー情報ＯＦについて、送信可否決定は、これまでの実施の形態と同様に行い、送信実行と決定されたオファー情報ＯＦについては、ウェブサイトへの掲載の通知をユーザ端末５に送信するものとしている。
【０２０６】
図３２にシステム全体の処理の流れを示す。なお図７と同一部分は同一ステップ番号を付して詳細な説明は避ける。
ステップＳ２１でユーザ端末５から見積要求情報ＲＱが送信されてきたら、取引仲介装置２はステップＳ１で受信した後、ステップＳ２で、見積要求の紹介情報ＩＲＱをベンダー端末４に送信する。
ステップＳ３１で紹介情報ＩＲＱを受信した各ベンダーは、ステップＳ３２でそれぞれオファー情報ＯＦを生成し、取引仲介装置２に送信する。
【０２０７】
取引仲介装置２は、ステップＳ３で受信・取得したオファー情報ＯＦのそれぞれについて、ステップＳ１０でウェブサイトにアップロードする。
図３３にオファー情報ＯＦを掲示するウェブページの例を示す。
例えば見積要求情報ＲＱを送信したユーザがログイン状態で閲覧できるページとして、図３３に示すように、その見積要求情報ＲＱの内容（車種、色、年式、走行距離等の見積対象情報）や、各ベンダーからのオファー情報ＯＦの内容として、例えばベンダー名称、所在地や、見積金額が提示される。
【０２０８】
また取引仲介装置２は取得したオファー情報ＯＦについて、ステップＳ４（比較対象設定処理）、Ｓ５（比較／送信可否決定処理）を行う。
そして送信実行と決定された場合は、ステップＳ１１からステップＳ１２に進み、ユーザ端末５にアップロードを知らせる通知メールＭＬｖを送信する。図３３のようなページにおいて、新たなオファー情報ＯＦが追加されたことの通知である。
ユーザ端末５は、ステップＳ２２で通知メールＭＬｖを受信する。ユーザはその電子メールを開封して、オファーが追加されたことを知ることができ、ユーザが閲覧可能とされるウェブサイトにアクセスしてオファー情報ＯＦの内容を確認できる。
【０２０９】
図３４に第８の実施の形態における取引仲介装置２の処理例を示す。第１の実施の形態の図８と同一処理には同一のステップ番号を付し、図８と異なる点のみを説明する。
この場合、図８のステップＳ１０７，Ｓ１０８の間にステップＳ１４１が加えられている。即ち取引仲介装置２は、オファー情報ＯＦを受信したら、ステップＳ１０７でオファー条件ＤＢ３６への登録を行うとともに、ステップＳ１４１で、当該オファー情報ＯＦの内容をウェブサイトへ掲載する処理を行う。
その後ステップＳ１０８（比較対象設定処理）、Ｓ１０９（比較／送信可否決定処理）を行い、当該オファー情報ＯＦについて送信可否決定を行うが、送信決定された場合は、ステップＳ１１０からＳ１４２に進み、通知メールＭＬｖの送信制御を行う。即ち取引仲介装置２は新たにオファー情報ＯＦが追加されたことを示した電子メールデータを生成し、通信部２０からユーザ端末５に送信する。
ステップＳ１４２では、取引仲介装置２は、通知メールＭＬｖの送信に応じたＤＢ更新を行う。例えばオファー条件ＤＢ３６における当該オファー情報ＯＦのステータスを「送信済」に更新する。
【０２１０】
一方、非送信と決定されても、先述の各実施の形態のようなベンダー端末４に対する通知情報ＩＬの送信は行わない。非送信と決定されるものでも、ウェブサイト掲載は行われるため、ユーザは閲覧可能となっているためである。
【０２１１】
以上のように第８の実施の形態では、ウェブサイトにオファー情報ＯＦを掲載するが、掲載したことのユーザへの通知に関しては、ユーザにとって有用と判定されるオファー情報ＯＦのみとしている。
なお、図３３のようなウェブページでは、通知メールＭＬｖの送信を行ったオファー情報ＯＦと、非送信のオファー情報ＯＦを区別できる態様で掲載するようにしてもよい。
また図３４の処理に代えて、図２８のように比較／送信可否決定を所定の実行タイミング毎に行うようにする処理例も考えられる。
【０２１２】
＜７．まとめ及び変形例＞
以上の第１〜第８の実施の形態では以下の効果が得られる。
実施の形態の取引仲介装置２は、ユーザ端末５（取引要求者端末）から送信された見積要求情報ＲＱ（取引要求情報）に対応して、複数のベンダー（取引申込者）が互いのオファー内容を知り得ない状態で生成される、複数のベンダーについてのオファー情報ＯＦを取得する商取引情報取得部２１と、商取引情報取得部２１が取得したオファー情報ＯＦについての比較対象を設定する比較対象設定部２２と、商取引情報取得部２１が取得したオファー情報ＯＦと、比較対象設定部２２が設定した比較対象との比較結果に基づいて、当該オファー情報ＯＦに関する送信をユーザ端末５に対して実行するか否かを決定する送信可否決定処理部２３と、送信可否決定処理部２３の決定に基づいて、オファー情報ＯＦに関するユーザ端末５への送信処理を制御する送信制御部２４とを備えている。
この取引仲介装置２は、ユーザと複数のベンダーを仲介するシステムとして機能する。この場合に、見積要求情報ＲＱに対する複数のオファー情報ＯＦについて、比較対象との比較処理を行って、ユーザ端末５へのオファー情報に関する送信（例えばオファー情報内容ＯＦｖや通知メールＭＬｖの送信）を行うか否かを決定する。すなわち各オファー情報ＯＦについてユーザへの提示に関するフィルタリング機能を備える。
従って、オファーが多すぎることによるユーザの負担を解消又は軽減することができる。
具体的には第１〜第７の実施の形態によれば、多数のベンダーからの大量のオファー内容が逐一ユーザに送信されてしまうようなことを解消でき、ユーザは、比較により選択されたオファーのみを確認すればよく、無駄なオファー確認の解消、有用なオファーの吟味等を適切に行うことができる。
第８の実施の形態によれば、オファーが生じた場合に、逐一ユーザに報告されないため、この場合もユーザは、通知が多すぎて煩わしくなるといったことが解消又は軽減できる。
【０２１３】
また実施の形態の場合、ベンダーがオファー情報ＯＦを作成する時点において、他のベンダーのオファー内容（見積金額等）を知ることはできないシステムである。これによりベンダーの過度の競争を促さないという趣旨を持った取引仲介の運営に適したものとなる。
またユーザに提示されるオファー情報は取引の申し入れのための見積金額等であり、成約条件ではない。このためユーザ側は、１つのオファー情報ＯＦのみを受け入れるのではなく、複数のオファー情報ＯＦについて検討し、成約を検討できる。もちろんオファー情報ＯＦの送信後にも商談の機会も残されている。従って実施の形態のシステムは、ベンダー、ユーザの双方に、オファー内容の成約までの維持や、成約の義務を課すものではなく、あくまで紹介を想定したものとなる。この意味で、多数のオファーがユーザに提示されることが許容されるのであるが、そのため、ユーザの負担を本実施の形態で解消することに大きな意義が生ずる。つまり本実施の形態は、ユーザが複数のオファーを受け付けることができるシステムにおいて顕著な効果を生ずるものである。
【０２１４】
また図１４、図１５で説明したように、取引仲介装置２（送信可否決定処理部２３）は、オファー情報ＯＦに含まれる見積金額が、比較対象金額よりもユーザ側にとって優位な金額である場合に、当該オファー情報ＯＦに関するユーザ端末５への送信を実行すると決定する。図１６のように、優位な金額である場合の数に応じて決定する場合もある。
ユーザにとって優位な見積金額であるということは、ユーザにとって好ましく、成約に関して検討に値するオファー情報である。そのためそのようなオファー情報ＯＦをユーザに提示することがユーザの負担解消や、ユーザ、ベンダー間の望ましい取引の仲介として適切となる。
【０２１５】
また取引仲介装置２（送信可否決定処理部２３）は、図１７、図１８で説明したように、オファー情報ＯＦに含まれる見積金額が、比較対象金額よりもユーザ側にとって劣位な金額である場合、金額差分が第１閾値（差分閾値ｔｈＤ１）未満であれば、当該オファー情報に関するユーザ端末５への送信を実行すると決定してもよい。
ユーザにとって劣位な見積金額であったとしても、各種事情、例えば所在地や期日、付加的なサービスなどの条件によりユーザが成約を望む場合もある。ただし、金額的にあまりに劣位であると、通常は成約の候補にはなりにくいため、ユーザに提示するオファーとしての価値は低い。そこで金額的には劣位であるが、比較対象との金額差分が差分閾値ｔｈＤ１未満であれば、成約の候補になり得るとして、そのオファー情報ＯＦに関するユーザ端末５への送信を実行する。これにより、成約の可能性のあるオファーをむやみに排除せず、またユーザにとっては多様なオファーを確認できるという機能も担保できる。
【０２１６】
また取引仲介装置２（送信可否決定処理部２３）は、図１９Ａ及びその変形例で説明したように、第１閾値（差分閾値ｔｈＤ１）を、比較対象とされたオファー情報のオファー元である取引申込者の実績情報、又は比較対象と比較するオファー情報のオファー元である取引申込者の実績情報を用いて設定してもよい。
即ち金額差分の上限としての差分閾値ｔｈＤ１は、固定値でもよいが、ベンダーの実績に応じて可変してもよい。これによりベンダーの信用等を反映して、ユーザへの送信可否を判断できる。
例えば比較対象のオファー情報ＯＦのベンダーが、見積金額と成約金額の差が大きく見積金額（比較対象金額）の信用度が低い場合は、差分閾値ｔｈＤ１を大きくして現オファー情報ＯＦの送信可否決定を緩くすることで、ユーザの満足度の高い取引仲介の可能性を高めることができる。
または、現オファー情報ＯＦのベンダーが、例えば見積金額と成約金額の差が大きくユーザに不利なベンダーである場合は送信可否決定を厳しく、見積金額と成約金額の差が小さい、ユーザに有利なベンダーである場合は送信可否決定を緩くすることでも、ユーザの満足度の高い取引仲介の可能性を高めることができる。
【０２１７】
また取引仲介装置２（送信可否決定処理部２３）は、図１９Ｂ、図２０Ａで説明したように、第１閾値（差分閾値ｔｈＤ１）を、オファー情報ＯＦの対象のユーザ端末５へのオファー情報に関する送信実行状況に基づいて設定されるようにしてもよい。
差分閾値ｔｈＤ１を大きくすれば、送信可否決定が緩くなり、ユーザ端末５への送信が実行されるオファー情報の数が増えやすくなり、差分閾値ｔｈＤ１を小さくすれば、送信可否決定が厳しくなり、ユーザ設定５への送信が実行されるオファー情報の数が絞られる。そこで、ユーザ端末５への送信実行状況に基づいて設定すれば、適度な数のオファーをユーザに提示できる。つまり、多すぎることだけでなく、少なすぎることにも対応できる。
【０２１８】
また取引仲介装置２（送信可否決定処理部２３）は、図２０Ｂで説明したように、第１閾値（差分閾値ｔｈＤ１）を、比較対象に設定された他のオファー情報ＯＦとの比較結果により、非送信と決定されたオファー情報ＯＦの数に基づいて設定されるようにしてもよい。比較対象とされた他のオファー情報ＯＦが強力すぎる場合、それ以外のオファー情報ＯＦがほとんど非送信と決定されてしまう場合がある。その場合、なかなかユーザにオファー情報ＯＦが届かないといったこともある。そこで差分閾値ｔｈＤ１を調整することで、適度な数のオファー情報ＯＦがユーザに提示されるようにできる。
【０２１９】
また取引仲介装置２（送信可否決定処理部２３）は、図２１，図２２で説明したように、オファー情報に含まれる見積金額を比較用に補正した比較用見積金額を比較対象と比較するようにしてもよい。
ユーザが成約したいと考える条件は、見積金額、利便性、事業者の信用など多岐にわたる。そこで見積金額のみ劣位であるために取引要求者への送信が実行されない、あるいは見積金額のみ優位であるため送信が実行されるということをなくすため、比較に用いる見積金額を増減する補正を行う。これによりユーザに多様な条件の見積もりが提示されるようにできる。
このように比較用見積金額を用いて比較を行う場合、図２２のようにオファー情報ＯＦに関する条件要素、例えば地理的要素、時期的要素、ベンダーの信用等と、ユーザ設定条件との差の大きさに基づいて、見積金額を比較用に補正するようにしてもよい。
ユーザが見積要求情報ＲＱにおいて設定条件を提示することで、ユーザが成約に求める条件を判断できる。そのような条件に適したオファーを、比較時の見積金額の補正により、ユーザ端末５への送信が行われやすくすることができる。逆に条件にそぐわないオファーを非送信の可能性を高くする。従ってユーザに対して望ましいオファーを届けやすくできる。
【０２２０】
また取引仲介装置２（送信可否決定処理部２３）は、図２３，図２４の非送信オファー処理で説明したように、ユーザ端末５へのオファー情報に関する送信を実行しないと決定したオファー情報ＯＦについて、当該オファー情報ＯＦのオファー元であるベンダーへの通知処理を実行するか否かを決定する処理を行うようにしてもよい。
取引要求者端末への送信を行わないとされたオファー情報は、取引申込者にとっては成約不可能又は成約困難なものとなる。そこでその旨を通知することでベンダーの適切な報告や、ベンダーの対応を促すことができる。
【０２２１】
また図２３Ｃのように、非送信オファー処理では、非送信と決定したオファー情報ＯＦについて、当該オファー情報ＯＦに含まれる見積金額と比較対象金額の金額差分が所定閾値（差分閾値ｔｈＤ２）未満であれば、当該オファー情報のオファー元である取引申込者への通知処理を実行すると決定するようにしてもよい。
金額差分が所定閾値未満ということは、比較により送信不実行と決定されたが、比較処理においてさほど大きく負けたものではないという意味になる。そこで再オファーを促す意味などで、通知処理が好適となる。
【０２２２】
また図２４Ａ、図２４Ｂのように、非送信オファー処理では、非送信と決定したオファー情報ＯＦについて、当該オファー情報ＯＦのベンダーによる他のオファー情報の状況に基づいて、実行するか否かを決定するようにしてもよい。
例えば当該ベンダーの他のオファー情報により、同様の商品の取引の成約機会が存在しているなどの状況により、送信不実行の通知が必ずしも必要ではない場合があるためであり、これにより通知処理の簡易化、ベンダーの業務の効率化もはかれる。
【０２２３】
また非送信オファー処理でベンダーに通知する通知情報ＩＬには、図２５Ａのように再オファー情報の送信を推奨する内容を含むようにすることが望ましい。通知により再オファー情報の送信を推奨することで、ベンダーに成約のチャンスを提供できる。
また通知情報ＩＬには、図２５Ｂのようにオファーの対象とする見積要求情報ＲＱの変更を推奨する内容を含むようにしてもよい。オファーの対象を変更すれば、ベンダーに新たに成約のチャンスを提供できる場合があるためである。
【０２２４】
また第２、第３，第４，第５の実施の形態（図２６Ａ、図２６Ｂ、図２７Ａ、図２７Ｂ）で説明したように、取引仲介装置２（送信可否決定処理部２３）は、比較結果からオファー情報ＯＦに関するユーザ端末５への送信を実行するか否かを決定するための条件を、ユーザ端末５へのオファー情報送信状況に基づいて選択するようにしてもよい。
送信を実行するか否かの決定条件は、厳しい条件や緩い条件で可変することが考えられる。このような条件選択をユーザ端末５へのオファー情報送信状況に基づいて行うことで、ユーザ端末５へ適度な数のオファー情報の提示を実現できる。
【０２２５】
また図１３Ａ、図１３Ｂ、図１３Ｃで説明したように、取引仲介装置２（比較対象設定部２２）は、他のオファー情報であってユーザ端末５側での所定操作が行われたオファー情報を、比較対象に設定してもよい。
比較処理における比較対象には、ユーザにとって成約可否の基準となるものが望ましい。既にユーザに提示しユーザが興味を示したオファー情報は、このような基準として適切と考えられる。そこでユーザ端末５側で、オファー情報内容ＯＦｖとしての電子メール内でのＵＲＬリンクのクリックなどの所定操作が行われたオファー情報を、比較対象に設定する。これにより、ユーザにとって望ましいオファーを提示するための送信可否決定機能を高めることができる。
【０２２６】
また比較対象設定に関しては、図９Ａのように相場情報を用いること、図９Ｂのようにユーザ希望額を用いることでも、ユーザにとって望ましいオファーを提示するための送信可否決定機能を高めることができる。
また図１０，図１１，図１２の各例のように、競合する他のオファー情報ＯＦを比較対象として用いることで、多数のベンダーの中でユーザにとって優位なオファーを選択し、ユーザに提示できる。
【０２２７】
なお本発明の情報処理装置は、実施の形態の取引仲介装置２の例に限らず、多様な変形例が想定される。
まず、自動車買取サービスの例で説明したが、他の各種の商取引の仲介サービスとして本発明は適用できる。
例えば自動車保険、生命保険、損害保険、火災保険、地震保険その他の各種保険商品の成約の仲介サービスが考えられる。また車検、引っ越し、運送等のためにユーザが業者を探すためのサービスとしても好適である。住宅販売等の不動産取引の仲介、旅行商品の販売の仲介としても好適である。中古品の買取サービスにも適用できる。以上はあくまで例示であり、これら以外にも本発明の適用分野は多様に想定される。
【０２２８】
また実施の形態では「ユーザにとって優位」とは、見積金額が高いということを想定して説明したが、逆に保険、車検、不動産販売等、ユーザが購入するという形態の場合は、「ユーザにとって優位」とは、見積金額が安いということとなることは、言うまでもない。
なお、見積金額が安い場合がユーザに有利な取引に適用する場合、図１８のステップＳ３４２は「ＣＰＶ’←ＣＰＶ＋ｔｈＤ１」とするなど、各例は適切に変形すればよい。
【０２２９】
また実施の形態では、比較処理では、見積金額と比較対象金額としたが、金額以外での値を用いて比較処理を行うこともできる。例えば取引数量、取引日時、ベンダーの評価値などを金額と併せて、或いは金額に代えて比較処理で用いてもよい。
また取引要求情報の例として見積要求情報ＲＱを挙げたが、見積金額を比較対象としない例も考えられることから取引要求情報には、見積要求情報ＲＱ以外の例も考えられる。例えば取引数量、取引日時等としての可能数や可能日時の提示を要求するようなリクエストも取引要求情報の例として考えられる。
【０２３０】
＜８．プログラム及び記憶媒体＞
以上、本発明の情報処理装置の実施の形態としての取引仲介装置２を説明してきたが、実施の形態のプログラムは、取引仲介装置２における商取引情報取得部２１、比較対象設定部２２、送信可否決定処理部２３、送信制御部２４の処理を情報処理装置（ＣＰＵ等）に実行させるプログラムである。
【０２３１】
実施の形態のプログラムは、ユーザ端末５から送信された見積要求情報ＲＱに対応して、複数のベンダーが互いのオファー内容を知り得ない状態で生成される、複数のベンダーについてのオファー情報ＯＦを取得する商取引情報取得手順を情報処理装置に実行させる。また、商取引情報取得手順で取得したオファー情報ＯＦについての比較対象を設定する比較対象設定手順を情報処理装置に実行させる。また商取引情報取得手順で取得したオファー情報ＯＦと、比較対象設定手順で設定した比較対象との比較結果に基づいて、当該オファー情報ＯＦに関する送信をユーザ端末５に対して実行するか否かを決定する送信可否決定手順を情報処理装置に実行させる。さらに送信可否決定手順の決定に基づいて、オファー情報に関ＯＦするユーザ端末５への送信処理を制御する送信制御手順を情報処理装置に実行させるプロ。
即ちこのプログラムは、情報処理装置のＣＰＵ１０１に対して図８、図２６Ａ、図２６Ｂ、図２７Ａ、図２７Ｂ、図２８、図３１、又は図３４で第１〜第８の実施の形態として説明した処理を実行させるプログラムである。
【０２３２】
このようなプログラムにより、上述した取引仲介装置２としての情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置等の機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭ等に予め記憶しておくことができる。あるいはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的あるいは永続的に格納（記憶）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。
【符号の説明】
【０２３３】
１  ネットワーク、２  取引仲介装置、３  ＤＢ群、４  ベンダー端末、５  ユーザ端末、２０  通信部、２１  商取引情報取得部、２２  比較対象設定部、２３  送信可否決定処理部、２４  送信制御部、２５  ＷＥＢサーバ
【図１】
2015181946.tif 000003
【図２】
2015181946.tif 000004
【図３】
2015181946.tif 000005
【図４】
2015181946.tif 000006
【図５】
2015181946.tif 000007
【図６】
2015181946.tif 000008
【図７】
2015181946.tif 000009
【図８】
2015181946.tif 000010
【図９】
2015181946.tif 000011
【図１０】
2015181946.tif 000012
【図１１】
2015181946.tif 000013
【図１２】
2015181946.tif 000014
【図１３】
2015181946.tif 000015
【図１４】
2015181946.tif 000016
【図１５】
2015181946.tif 000017
【図１６】
2015181946.tif 000018
【図１７】
2015181946.tif 000019
【図１８】
2015181946.tif 000020
【図１９】
2015181946.tif 000021
【図２０】
2015181946.tif 000022
【図２１】
2015181946.tif 000023
【図２２】
2015181946.tif 000024
【図２３】
2015181946.tif 000025
【図２４】
2015181946.tif 000026
【図２５】
2015181946.tif 000027
【図２６】
2015181946.tif 000028
【図２７】
2015181946.tif 000029
【図２８】
2015181946.tif 000030
【図２９】
2015181946.tif 000031
【図３０】
2015181946.tif 000032
【図３１】
2015181946.tif 000033
【図３２】
2015181946.tif 000034
【図３３】
2015181946.tif 000035
【図３４】
2015181946.tif 000036
【手続補正書】
【提出日】平成28年11月4日(2016.11.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信ネットワークにより通信可能な不特定ユーザの端末である取引要求者端末から送信された取引要求情報に対応して、複数の取引申込者が互いのオファー内容を知り得ない状態で生成される、複数の取引申込者についてのオファー情報を取得する商取引情報取得部と、
前記商取引情報取得部が取得した前記オファー情報についての比較対象を設定する比較対象設定部と、
前記商取引情報取得部が取得した前記オファー情報と、前記比較対象設定部が設定した比較対象との比較結果に基づいて、取引要求情報の送信元の前記取引要求者端末に対して当該オファー情報を仲介して提示するための当該オファー情報に関する送信を実行するか否かを決定する送信可否決定処理部と、
前記送信可否決定処理部の決定に基づいて、取引要求情報の送信元の前記取引要求者端末へのオファー情報に関する送信処理を制御する送信制御部と、を備えた
情報処理装置。
【請求項２】
前記送信可否決定処理部は、オファー情報に含まれる見積金額が、比較対象に含まれる金額よりも取引要求者側にとって優位な金額である場合に、当該オファー情報に関する前記取引要求者端末への送信を実行すると決定する
請求項１に記載の情報処理装置。
【請求項３】
前記送信可否決定処理部は、オファー情報に含まれる見積金額が、比較対象に含まれる金額よりも取引要求者側にとって劣位な金額である場合、金額差分が第１閾値未満であれば、当該オファー情報に関する前記取引要求者端末への送信を実行すると決定する
請求項１又は請求項２に記載の情報処理装置。
【請求項４】
前記第１閾値は、比較対象とされたオファー情報のオファー元である取引申込者の実績情報、又は比較対象と比較するオファー情報のオファー元である取引申込者の実績情報を用いて設定される
請求項３に記載の情報処理装置。
【請求項５】
前記第１閾値は、オファー情報の対象の取引要求者端末へのオファー情報に関する送信実行状況に基づいて設定される
請求項３に記載の情報処理装置。
【請求項６】
前記第１閾値は、前記比較対象設定部によって比較対象に設定されたオファー情報との比較結果により、前記取引要求者端末へ送信しないと決定されたオファー情報の数に基づいて設定される
請求項３に記載の情報処理装置。
【請求項７】
前記送信可否決定処理部は、オファー情報に含まれる見積金額を比較用に補正したうえで比較対象と比較する
請求項１乃至請求項６のいずれかに記載の情報処理装置。
【請求項８】
前記送信可否決定処理部は、オファー情報に関する条件要素と、取引要求情報に関連づけられた設定条件との差の大きさに基づいて、オファー情報に含まれる見積金額を比較用に補正する
請求項７に記載の情報処理装置。
【請求項９】
前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報のオファー元である取引申込者への通知処理を実行するか否かを決定する処理を行う
請求項１乃至請求項８のいずれかに記載の情報処理装置。
【請求項１０】
前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報に含まれる見積金額と比較対象に含まれる金額の金額差分が所定閾値未満であれば、当該オファー情報のオファー元である取引申込者への通知処理を実行すると決定する
請求項９に記載の情報処理装置。
【請求項１１】
前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報についての取引申込者への通知処理は、当該オファー情報のオファー元である取引申込者による他のオファー情報の状況に基づいて、実行するか否かを決定する
請求項９に記載の情報処理装置。
【請求項１２】
前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報のオファー元である取引申込者への通知処理を実行する場合、前記通知処理による通知情報には、再オファー情報の送信を推奨する内容を含むようにする
請求項１乃至請求項１１のいずれかに記載の情報処理装置。
【請求項１３】
前記送信可否決定処理部は、前記取引要求者端末へのオファー情報に関する送信を実行しないと決定したオファー情報について、当該オファー情報のオファー元である取引申込者への通知処理を実行する場合、前記通知処理による通知情報には、オファーの対象とする取引要求情報の変更を推奨する内容を含むようにする
請求項１乃至請求項１２のいずれかに記載の情報処理装置。
【請求項１４】
前記送信可否決定処理部は、比較結果からオファー情報に関する送信を前記取引要求者端末に対して実行するか否かを決定するための条件を、送信対象の取引要求者端末へのオファー情報送信状況に基づいて選択する
請求項１乃至請求項１３のいずれかに記載の情報処理装置。
【請求項１５】
前記比較対象設定部は、前記商取引情報取得部が取得したオファー情報と同じ取引要求情報に対応し、かつ前記取引要求者端末に送信された他のオファー情報であって、前記取引要求者端末側での所定操作が行われたオファー情報を、比較対象に設定する
請求項１乃至請求項１４のいずれかに記載の情報処理装置。
【請求項１６】
通信ネットワークにより通信可能な不特定ユーザの端末である取引要求者端末から送信された取引要求情報に対応して、複数の取引申込者が互いのオファー内容を知り得ない状態で生成される、複数の取引申込者についてのオファー情報を取得する商取引情報取得ステップと、
前記商取引情報取得ステップで取得した前記オファー情報についての比較対象を設定する比較対象設定ステップと、
前記商取引情報取得ステップで取得した前記オファー情報と、前記比較対象設定ステップで設定した比較対象との比較結果に基づいて、取引要求情報の送信元の前記取引要求者端末に対して当該オファー情報を仲介して提示するための当該オファー情報に関する送信を実行するか否かを決定する送信可否決定ステップと、
前記送信可否決定ステップの決定に基づいて、取引要求情報の送信元の前記取引要求者端末へのオファー情報に関する送信処理を制御する送信制御ステップと、を有する
情報処理方法。
【請求項１７】
通信ネットワークにより通信可能な不特定ユーザの端末である取引要求者端末から送信された取引要求情報に対応して、複数の取引申込者が互いのオファー内容を知り得ない状態で生成される、複数の取引申込者についてのオファー情報を取得する商取引情報取得手順と、
前記商取引情報取得手順で取得した前記オファー情報についての比較対象を設定する比較対象設定手順と、
前記商取引情報取得手順で取得した前記オファー情報と、前記比較対象設定手順で設定した比較対象との比較結果に基づいて、取引要求情報の送信元の前記取引要求者端末に対して当該オファー情報を仲介して提示するための当該オファー情報に関する送信を実行するか否かを決定する送信可否決定手順と、
前記送信可否決定手順の決定に基づいて、取引要求情報の送信元の前記取引要求者端末へのオファー情報に関する送信処理を制御する送信制御手順と、
を情報処理装置に実行させるプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
第１に、本発明に係る情報処理装置は、通信ネットワークにより通信可能な不特定ユーザの端末である取引要求者端末から送信された取引要求情報に対応して、複数の取引申込者が互いのオファー内容を知り得ない状態で生成される、複数の取引申込者についてのオファー情報を取得する商取引情報取得部と、前記商取引情報取得部が取得した前記オファー情報についての比較対象を設定する比較対象設定部と、前記商取引情報取得部が取得した前記オファー情報と、前記比較対象設定部が設定した比較対象との比較結果に基づいて、取引要求情報の送信元の前記取引要求者端末に対して当該オファー情報を仲介して提示するための当該オファー情報に関する送信を実行するか否かを決定する送信可否決定処理部と、前記送信可否決定処理部の決定に基づいて、取引要求情報の送信元の前記取引要求者端末へのオファー情報に関する送信処理を制御する送信制御部とを備えたものである。
取引要求者端末とは、取引要求者、例えば商品の売却、購入、契約等の商取引を求めるユーザが用いる端末である。取引申込者とは、取引要求者との商取引を申し入れる事業者等である。すなわちこの情報処理装置は、取引要求者と複数の取引申込者を仲介するシステムとして機能する。この場合に、取引要求情報に対する複数の取引申込者からのそれぞれのオファー情報について、比較対象との比較処理を行って、取引要求者端末へのオファー情報に関する送信を行うか否かを決定する。すなわち各オファー情報についてフィルタリングして取引要求者への送信を実行する機能を備える。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００２０
【補正方法】変更
【補正の内容】
【００２０】
本発明に係る情報処理方法は、通信ネットワークにより通信可能な不特定ユーザの端末である取引要求者端末から送信された取引要求情報に対応して、複数の取引申込者が互いのオファー内容を知り得ない状態で生成される、複数の取引申込者についてのオファー情報を取得する商取引情報取得ステップと、前記商取引情報取得ステップで取得した前記オファー情報についての比較対象を設定する比較対象設定ステップと、前記商取引情報取得ステップで取得した前記オファー情報と、前記比較対象設定ステップで設定した比較対象との比較結果に基づいて、取引要求情報の送信元の前記取引要求者端末に対して当該オファー情報を仲介して提示するための当該オファー情報に関する送信を実行するか否かを決定する送信可否決定ステップと、前記送信可否決定ステップの決定に基づいて、取引要求情報の送信元の前記取引要求者端末へのオファー情報に関する送信処理を制御する送信制御ステップと、を有する。
これにより多数のオファー情報についてフィルタリングして取引要求者への送信を実行する機能を実現する。
また本発明に係るプログラムは、上記情報処理方法の各ステップを情報処理装置に実行させるプログラムである。このプログラムにより上記の情報処理装置を実現する。
【手続補正４】
【補正対象書類名】図面
【補正対象項目名】図１９
【補正方法】変更
【補正の内容】
【図１９】
2015181946.tif 000037
【手続補正５】
【補正対象書類名】図面
【補正対象項目名】図２６
【補正方法】変更
【補正の内容】
【図２６】
2015181946.tif 000038
【国際調査報告】
2015181946.tif 000039
2015181946.tif 000040
2015181946.tif 000041
2015181946.tif 000042