JP2022162521A - 売買支援装置、売買支援方法及びプログラム - Google Patents

Abstract

【課題】物品の取引を活性化させることが可能な売買支援装置、売買支援方法及びプログラムを提供すること。【解決手段】一実施形態にかかる管理サーバ１１（売買支援装置）は、登録されたユーザの端末情報と、端末情報に紐づけられたチャットサービスの担当者の端末情報を記憶する記憶部１１３と、記憶部１１３に記憶されたユーザの端末情報及び担当者の端末情報に基づいて、ユーザの端末と担当者の端末とを接続するチャットサービスを提供するサイト管理部１１２Ｃ（提供部）をさらに備える。【選択図】図３

Description

特許法第３０条第２項適用申請有り （１）令和２年７月１０日に横浜トヨペット株式会社発行の「ｍｏｂｉｌｉｃｏ（モビリコ）」のリーフレットにて公開 （２）令和２年９月１６日に横浜トヨペット株式会社のウェブサイトにて公開 （３）令和２年９月１７日に株式会社 ＰＲ ＴＩＭＥＳのウェブサイトにて公開

本発明は、売買支援装置、売買支援方法及びプログラムに関する。

物品（例えば中古品）の売買を支援するシステムが開発されている。

例えば、特許文献１には、自動車売買のサポートサーバが、自動車情報を提供し、売買を仲介することが記載されている。具体的には、ある自動車の売却希望者の端末がサポートサーバのウェブサイトにアクセスし、出品依頼を送信すると、サポートサーバは、その自動車の過去の整備に関する情報を内部に登録する。そして、自動車の購入希望者の端末から購入希望条件を受け付け、マッチングする自動車があった場合に、サポートサーバは、その自動車の整備に関する情報を、購入希望者の端末に送信する。

また、特許文献２には、店舗端末、車情報管理サーバ及び車データベースを備えた売買支援システムが開示されている。具体的には、店舗端末から車の売却依頼の受付処理がなされた場合、店舗端末は売却対象の車番号に基づいて、車情報を車データベースから取得し、その車情報に基づいて売却価格を算定する。店舗端末は、売却価格を含めた車の売却情報を、車データベース又は車販売システムに登録する。車購入希望のある個人は、別の店舗端末にて購入手続きをする場合に、車データベースに登録された、売却予定として掲示されている車情報を取得する。

特開２０１７－０１６２２４号公報 特開２０１９－１５３３３５号公報

上述のシステムでは、自動車の保有者が売却の意思を持った場合に、初めてその売却希望者の自動車情報がシステム側で登録されることになり、購入希望者の購入が可能となる。そのため、自動車の売買取引を実施する機会が限られていた。

本発明の目的は、上述の課題に鑑みてなされたものであり、物品の取引を活性化させることが可能な売買支援装置、売買支援方法及びプログラムを提供することである。

本発明の例示的な第１の態様に係る売買支援装置は、ユーザが保有している保有物品の更新情報を受信する受信部と、更新情報に基づいて、保有物品の情報である保有物品情報を取得する保有物品情報取得部と、少なくとも保有物品情報を用いて、保有物品に関連する買い替え候補物品を特定する特定部と、ユーザに保有物品から買い替え候補物品への買い替えを提案する、買い替え候補物品の情報が含まれた買い替え提案を生成する提案生成部を備える。これにより、更新情報の送信をトリガとして、売買支援装置は、ユーザに対して保有物品の買い替えを促すことができ、物品の取引を活性化させることが可能となる。

ここで、保有物品情報には、ユーザが保有物品を購入した際の価格情報が含まれており、売買支援装置の特定部は、価格情報に基づいて、買い替え候補物品を特定しても良い。これにより、売買支援装置は、ユーザが購入を想定すると考えられる価格帯の買い替え候補物品を提案することができるため、よりユーザに適した買い替えの提案をすることができる。

また、売買支援装置は、買い替え提案をユーザに送信する送信部をさらに備えても良い。受信部は、ユーザから、買い替え候補物品に興味を有する旨の通知をさらに受信し、特定部は、通知に基づいて、ユーザが興味を有する買い替え候補物品と類似の物品を、次回以降に提案生成部が提案する買い替え候補物品として特定しても良い。これにより、売買支援装置は、買い替え候補物品として、ユーザが興味を有する物品を将来提案することができるため、よりユーザに適した買い替えの提案をすることができる。

また、売買支援装置は、買い替え提案をユーザに送信する送信部をさらに備えても良い。特定部は、少なくとも保有物品情報を用いて、ユーザが購入可能な物品を記憶する購入可能物品データベースから、買い替え候補物品を特定しても良い。保有物品情報取得部は、購入可能物品データベースに追加物品の情報が追加物品情報として新たに追加された場合に、保有物品情報を記憶する保有物品データベースから保有物品情報を取得する。保有物品情報と追加物品情報との比較において、保有物品と追加物品とが類似していると判定された場合に、特定部は、追加物品を次回以降に提案する買い替え候補物品として特定し、送信部は、ユーザに対し、更新情報の送信を促す通知を送信する。これにより、売買支援装置は、保有物品と似ており、新たに購入可能となった物品（例えば新商品）を買い替え候補物品として提案することができるため、よりユーザの購買意欲を向上させることができる。

また、売買支援装置は、買い替え提案をユーザに送信する送信部をさらに備えても良い。特定部は、少なくとも保有物品情報を用いて、ユーザが購入可能な物品を記憶する購入可能物品データベースから、買い替え候補物品を特定しても良い。保有物品情報取得部は、購入可能物品データベースに追加物品の情報が追加物品情報として新たに追加された場合に、保有物品情報を記憶する保有物品データベースから保有物品情報を取得する。ユーザが嗜好を有する物品の情報である嗜好物品情報と追加物品情報との比較において、嗜好を有する物品と追加物品とが類似していると判定された場合に、特定部は、追加物品を次回以降に提案する買い替え候補物品として特定し、送信部は、ユーザに対し、更新情報の送信を促す通知を送信する。これにより、売買支援装置は、ユーザの嗜好に合っており、新たに購入可能となった物品（例えば新商品）を買い替え候補物品として提案することができるため、よりユーザの購買意欲を向上させることができる。

また、売買支援装置の送信部は、ユーザに対し、更新情報の送信を促す通知を送信してから所定の期間が経過するまで、新たな更新情報の送信を促す通知を送信しないようにしても良い。これにより、ユーザは、短い期間に売買支援装置から通知を重ねて受けなくなるため、ユーザが感じる煩わしさを抑制させることができる。

また、保有物品と追加物品とが類似しており、保有物品と追加物品との類似度が所定の類似度以上である場合には、更新情報の送信を促す通知を前回に送信してから所定の期間が経過する前であっても、売買支援装置の送信部は、新たな更新情報の送信を促す通知を送信しても良い。一方、保有物品と追加物品とが類似していても、保有物品と追加物品との類似度が所定の類似度未満である場合には、更新情報の送信を促す通知を前回に送信してから所定の期間が経過する前には、送信部は、新たな更新情報の送信を促す通知を送信しない。これにより、追加物品が保有物品と類似度が高いものでない限り、ユーザは所定の期間は通知を受信しない。したがって、ユーザは、自分の興味と一致度が低い物品の買い替え提案を受信しにくくなるため、ユーザが感じる煩わしさを抑制させることができる。

また、保有物品と追加物品とが類似しており、保有物品と追加物品との類似度が所定の類似度以上である場合には、更新情報の送信を促す通知を前回に送信してから第１の期間が経過した後に、売買支援装置の送信部は、新たな更新情報の送信を促す通知を送信しても良い。一方、保有物品と追加物品とが類似しており、保有物品と追加物品との類似度が所定の類似度未満である場合には、更新情報の送信を促す通知を前回に送信してから第１の期間よりも長い第２の期間が経過した後に、送信部は、新たな更新情報の送信を促す通知を送信する。これにより、売買支援装置は、追加物品が保有物品と類似度が低いものである場合に、類似度が高いものである場合と比べて、ユーザに通知させる頻度を少なくすることができる。したがって、ユーザは、自分の興味と一致度が低い物品の買い替え提案を受信しにくくなるため、ユーザが感じる煩わしさを抑制させることができる。

また、嗜好を有する物品と追加物品とが類似しており、嗜好を有する物品と追加物品との類似度が所定の類似度以上である場合には、更新情報の送信を促す通知を前回に送信してから所定の期間が経過する前であっても、売買支援装置の送信部は、新たな更新情報の送信を促す通知を送信しても良い。一方、嗜好を有する物品と追加物品とが類似していても、嗜好を有する物品と追加物品との類似度が所定の類似度未満である場合には、更新情報の送信を促す通知を前回に送信してから所定の期間が経過する前には、送信部は、新たな更新情報の送信を促す通知を送信しない。これにより、追加物品が嗜好を有する物品と類似度が高いものでない限り、ユーザは所定の期間は通知を受信しない。したがって、ユーザは、自分の興味と一致度が低い物品の買い替え提案を受信しにくくなるため、ユーザが感じる煩わしさを抑制させることができる。

また、嗜好を有する物品と追加物品とが類似しており、嗜好を有する物品と追加物品との類似度が所定の類似度以上である場合には、更新情報の送信を促す通知を前回に送信してから第１の期間が経過した後に、送信部は、新たな更新情報の送信を促す通知を送信しても良い。一方、嗜好を有する物品と追加物品とが類似しており、嗜好を有する物品と追加物品との類似度が所定の類似度未満である場合には、更新情報の送信を促す通知を前回に送信してから第１の期間よりも長い第２の期間が経過した後に、送信部は、新たな更新情報の送信を促す通知を送信する。これにより、売買支援装置は、追加物品が嗜好を有する物品と類似度が低いものである場合に、類似度が高いものである場合と比べて、ユーザに通知させる頻度を少なくすることができる。したがって、ユーザは、自分の興味と一致度が低い物品の買い替え提案を受信しにくくなるため、ユーザが感じる煩わしさを抑制させることができる。

また、上記売買支援装置は、登録されたユーザの端末情報と、端末情報に紐づけられたチャットサービスの担当者の端末情報を記憶する記憶部と、記憶部に記憶されたユーザの端末情報及び担当者の端末情報に基づいて、ユーザの端末と担当者の端末とを接続するチャットサービスを提供する提供部をさらに備えても良い。これにより、ユーザと担当者の間のコミュニケーションをよりスムーズに行うことができる。

また、上記売買支援装置は、ユーザとユーザの担当者とのコミュニケーション履歴と、ユーザの物品及びサービスの少なくともいずれかの購入履歴と、を有するトレーニングデータを用いて、物品及びサービスの少なくともいずれかの購入に関連するコミュニケーションのパターンを特定するコミュニケーションモデルを生成するコミュニケーションモデル生成部と、コミュニケーションモデルと、対象ユーザと対象ユーザの担当者とのコミュニケーション履歴を用いることにより、対象ユーザに係る対象物品及び対象サービスの少なくともいずれかの購入に関連するコミュニケーションについて、対象ユーザの担当者への提案を生成するコミュニケーション提案生成部をさらに備えても良い。これにより、対象ユーザの担当者は、対象物品又は対象サービスの購入に関連するコミュニケーションを取ることができるため、対象物品又は対象サービスの販売業績を向上させることができる。

ここで、コミュニケーション履歴は、ユーザとユーザの担当者とのチャット履歴であり、コミュニケーションモデル生成部は、トレーニングデータを用いて、物品及びサービスの少なくともいずれかの購入に関連するチャットでの会話パターンを特定するコミュニケーションモデルを生成し、コミュニケーション提案生成部は、コミュニケーションモデルと、対象ユーザと対象ユーザの担当者とのチャット履歴を用いることにより、対象物品及び対象サービスの少なくともいずれかの購入に関連するチャットでの会話について、提案を生成しても良い。これにより、対象ユーザの担当者は、対象物品又は対象サービスの購入に関連する会話をチャットで展開することができるため、対象物品又は対象サービスの販売業績を向上させることができる。

さらに、トレーニングデータは、ユーザの個人情報と、ユーザの物品及びサービスの少なくともいずれかの購入に関連する行動履歴と、ユーザの物品及びサービスの少なくともいずれかの販売促進に関する履歴の少なくともいずれかをさらに有し、コミュニケーション提案生成部は、対象ユーザの個人情報と、対象ユーザの対象物品及び対象サービスの少なくともいずれかの購入に関連する行動履歴と、対象ユーザの対象物品及び対象サービスの少なくともいずれかの販売促進に関する履歴の少なくともいずれかをさらに用いることにより、提案を生成しても良い。これにより、対象ユーザの担当者は、ユーザの属性又は行動により適したコミュニケーションを取ることができる。

そして、コミュニケーション提案生成部は、対象ユーザに対してコミュニケーションを取るタイミングと、対象ユーザに対して購入を勧める物品及びサービスの少なくともいずれかと、対象ユーザに対する対象物品及び対象サービスの少なくともいずれかの販売促進の手法の少なくともいずれかに関する提案を生成しても良い。これにより、対象ユーザの担当者は、物品又はサービスを販売するために、より効果的な手法を取ることができる。

また、上記売買支援装置は、物品及びサービスの少なくともいずれかに関する、広告及び販売促進の少なくともいずれかの履歴、並びに物品及びサービスの少なくともいずれかの販売履歴を有するトレーニングデータを用いて、物品及びサービスの少なくともいずれかの販売に関連する広告及び販売促進の少なくともいずれかの手法を特定する販売モデルを生成する販売モデル生成部と、販売モデルを用いて、対象物品及び対象サービスの少なくともいずれかの販売に関連する広告及び販売促進の少なくともいずれかについての提案を生成する販売方法提案生成部をさらに備えても良い。これにより、広告又は販売促進の担当者は、対象物品又は対象サービスの販売に関連する広告又は販売促進の手法を取り入れることができるため、対象物品又は対象サービスの販売業績を向上させることができる。

また、上記売買支援装置において、保有物品及びユーザが購入可能な物品は自動車であっても良い。これにより、売買支援装置は、自動車の取引を容易に仲介することができる。

本発明の例示的な第２の態様に係る売買支援装置が実行する売買支援方法は、ユーザが保有している保有物品の更新情報を受信する受信ステップと、更新情報に基づいて、保有物品の情報である保有物品情報を取得する保有物品情報取得ステップと、少なくとも保有物品情報を用いて、保有物品に関連する買い替え候補物品を特定する特定ステップと、ユーザに保有物品から買い替え候補物品への買い替えを提案する、買い替え候補物品の情報が含まれた買い替え提案を生成する提案生成ステップを備える。これにより、更新情報の送信をトリガとして、売買支援装置は、ユーザに対して保有物品の買い替えを促すことができ、物品の取引を活性化させることが可能となる。

本発明の例示的な第３の態様に係るプログラムは、コンピュータに、ユーザが保有している保有物品の更新情報を受信する受信ステップと、更新情報に基づいて、保有物品の情報である保有物品情報を取得する保有物品情報取得ステップと、少なくとも保有物品情報を用いて、保有物品に関連する買い替え候補物品を特定する特定ステップと、ユーザに保有物品から買い替え候補物品への買い替えを提案する、買い替え候補物品の情報が含まれた買い替え提案を生成する提案生成ステップを実行させる。これにより、更新情報の送信をトリガとして、コンピュータは、ユーザに対して保有物品の買い替えを促すことができ、物品の取引を活性化させることが可能となる。

本発明により、物品の取引を活性化させることが可能な売買支援装置、売買支援方法及びプログラムを提供することができる。

実施の形態１にかかる売買支援システムを示す概略図である。 実施の形態１にかかる端末の構成を示すブロック図である。 実施の形態１にかかる管理サーバの構成を示すブロック図である。 実施の形態１にかかる管理サーバが実行する処理の一例を示すフローチャートである。 実施の形態１にかかる売買支援システムを示す概略図である。 実施の形態１にかかる管理サーバが実行する処理の一例を示すフローチャートである。 実施の形態２にかかる売買支援システムを示す概略図である。 実施の形態２にかかる管理サーバの構成を示すブロック図である。 実施の形態２にかかる管理サーバが実行する処理の一例を示すフローチャートである。 実施の形態３にかかる売買支援システムを示す概略図である。 実施の形態３にかかる管理サーバが実行する処理の一例を示すフローチャートである。 実施の形態４にかかる売買支援システムを示す概略図である。 実施の形態４にかかる管理サーバが実行する処理の一例を示すフローチャートである。 実施の形態５にかかる売買支援システムを示す概略図である。 実施の形態５にかかる管理サーバが実行する処理の一例を示すフローチャートである。 実施の形態６にかかる売買支援システムを示す概略図である。 実施の形態６にかかる管理サーバが実行する処理の一例を示すフローチャートである。 実施の形態７にかかる売買支援システムを示す概略図である。 実施の形態７にかかる管理サーバが実行する処理の一例を示すフローチャートである。 実施の形態８にかかる売買支援システムを示す概略図である。 実施の形態９にかかる売買支援システムを示す概略図である。 実施の形態９にかかる管理サーバの構成を示すブロック図である。 実施の形態９にかかる管理サーバが実行する処理の一例を示すフローチャートである。 各実施の形態に係る情報処理装置のハードウェア構成例を示すブロック図である。

実施の形態１
（１Ａ：整備・点検履歴の参照）
以下、図面を参照して本発明の実施の形態について説明する。なお、以下の各実施の形態では、物品として、自動車の売買がなされる例について説明する。実施の形態１では、管理サーバ（売買支援装置）が実行する基本処理について説明する。

図１は、実施の形態１に係る売買支援システムを示す概略図である。図１の概略を説明すると、売買支援システムＳ１は、端末１０Ａ、１０Ｂ、管理サーバ１１及び整備・点検履歴ＤＢ（Database）１２を少なくとも備える。端末１０Ａ、１０Ｂは、それぞれ、自動車の保有者（所有者）、自動車の買い手が有する端末である。管理サーバ１１は、端末１０Ａ、１０Ｂとそれぞれ接続されており、中古車の売買を仲介する仲介会社が保有するサーバである。管理サーバ１１は、保有者と買い手とを仲介し、両者の間の中古車の売買契約をサポートするプラットフォームとして機能する。整備・点検履歴ＤＢ１２は、管理サーバ１１と接続されており、複数のユーザの保有車の整備・点検履歴に関する情報を格納するデータベースである。整備・点検履歴ＤＢ１２は、管理サーバ１１を有する仲介会社が保有していても良いし、異なる会社が保有していても良い。また、図１内の矢印は、送受信される情報を時系列順に示したものであり、この詳細については後述する。以下、各端末又は装置の詳細な構成について説明する。

図２は、端末１０Ａ、１０Ｂの構成を示すブロック図である。なお、以下の記載において、端末１０Ａ、１０Ｂを総称して端末１０と記載する。端末１０は、通信部１０１、表示部１０２、入力部１０３、撮像部１０４、制御部１０５及び記憶部１０６を備える。端末１０は、スマートフォン、タブレット端末、ＰＣ（Personal Computer）等の任意の情報処理装置で構成される。

通信部１０１（トランシーバ）は、管理サーバ１１に情報を送信する送信部として機能するほか、管理サーバ１１から情報を受信する受信部として機能する。例えば、通信部１０１は、管理サーバ１１が運営する後述のウェブサイトにアクセスし、そこを介して入力部１０３によって情報を入力することで、管理サーバ１１に情報を送信することができる。ただし、通信部１０１は、その他の形態により管理サーバ１１と情報の送受信をすることも可能であり、管理サーバ１１以外の端末や装置との通信を実行することも可能である。通信は、有線または無線のいずれでなされても良い。

表示部１０２は、記憶部１０６に格納された情報や管理サーバ１１から受信した情報を表示するためのインタフェースである。入力部１０３は、端末１０のユーザ（保有者又は買い手）が情報を入力するためのインタフェースである。例えば、ユーザは、管理サーバ１１に送信する情報を入力することができる。表示部１０２は、例えばディスプレイやタッチパネルで構成され、入力部１０３は、例えばボタンやタッチパネルで構成される。なお、タッチパネルにより、表示部１０２、入力部１０３のそれぞれ少なくとも一部が共通の部品として構成されていても良い。

撮像部１０４は、カメラで構成されており、所望の内容を撮像する。撮像された情報は、制御部１０５によって表示部１０２に表示されたり、通信部１０１を介して送信されたりしても良い。また、撮像部１０４が車検証のＱＲコード（登録商標）等の二次元バーコードを読み取った場合には、制御部１０５は、通信部１０１を介して二次元バーコードが指定するウェブサイトにアクセスすることで、そのウェブサイト上に記載された情報を表示部１０２に表示させたり、記憶部１０６に格納させたりしても良い。

制御部１０５は、端末１０の各部の処理を制御するものであり、バスを介して、他の各構成要素と接続されている。例えば、制御部１０５は、管理サーバ１１から送信された情報を、表示部１０２に表示させることができる。また、制御部１０５は、入力部１０３から取得した入力情報を、通信部１０１を介して管理サーバ１１に送信することができる。

記憶部１０６は、制御部１０５の制御によって、入力部１０３に入力された情報や、管理サーバ１１から受信した情報を格納することができる。また、記憶部１０６には、制御部１０５が実行する処理を実現するためのプログラムが格納されていても良い。

図３は、管理サーバ１１の構成を示すブロック図である。管理サーバ１１は、通信部１１１、制御部１１２及び記憶部１１３を備える。ただし、管理サーバ１１は、端末１０と同様の機能を有する入力部や表示部をさらに備えても良い。管理サーバ１１は、１台又は複数台の任意の情報処理装置で構成される。また、管理サーバ１１は、端末１０がアクセス可能なウェブサイトを運営している。

通信部１１１（トランシーバ）は、端末１０、整備・点検履歴ＤＢ１２と情報を送受信する送信部及び受信部として機能する。例えば、端末１０とは、ウェブサイトを介した情報の送受信が可能である。ただし、通信部１１１は、その他の端末又は装置との通信を実行することも可能である。

制御部１１２は、記憶部１１３からソフトウェア（コンピュータプログラム）を読み出して実行することで、解析部１１２Ａ、検索部１１２Ｂ及びサイト管理部１１２Ｃ等の機能を実現する。以下、これらの各機能について説明する。

解析部１１２Ａは、通信部１１１を介して受信した情報を解析し、次に管理サーバ１１が実行する処理を決定する。例えば、端末１０Ａからユーザの保有車（保有物品）の情報を販売希望車の情報として受信した場合に、その情報を記憶部１１３に格納させるほか、その情報に基づいて、検索部１１２Ｂが、整備・点検履歴ＤＢ１２内の販売希望車の整備・点検履歴に関する情報（整備・点検履歴情報）を検索する処理をするように決定する。また、整備・点検履歴ＤＢ１２から、販売希望車に関する整備・点検履歴情報を取得した場合に、サイト管理部１１２Ｃがその整備・点検履歴情報をウェブサイトにアップロードするように決定する。さらに、端末１０Ｂから販売車に関する問い合わせ情報を受信した場合に、検索部１１２Ｂは、その問い合わせ情報の内容に応じて、記憶部１１３内に格納された販売希望車の情報を検索し、問い合わせに合致する販売希望車の情報を取得する。

さらに、解析部１１２Ａは、通信部１１１を介して、端末１０からウェブサイトへのアクセスがなされた場合、アクセスの内容に応じて、サイト管理部１１２Ｃが端末１０に対して表示するウェブサイトの内容を更新するように決定する。また、通信部１１１が、端末１０Ａから販売希望車の取り下げの指示を受信した場合に、解析部１１２Ａは、その指示を解析し、指示に係る販売希望車の情報をサイト管理部１１２Ｃがウェブサイト上から削除する（即ち端末１０Ｂから閲覧不可とする）ように決定しても良い。

検索部１１２Ｂは、端末１０から販売希望車又は問い合わせに係る情報を取得した場合に、解析部１１２Ａの解析結果に基づいて、所望の情報の検索を実行する。例えば、端末１０Ａから販売希望車に係る情報（販売希望車情報）を取得した場合、その情報内に含まれる車体番号等の自動車の特定情報を用いて、通信部１１１を介し、整備・点検履歴ＤＢ１２内の販売希望車に関する整備・点検履歴情報を検索し、取得する。一方、端末１０Ｂから販売車に関する問い合わせに係る情報を取得した場合、その問い合わせ情報に応じて、記憶部１１３内に格納された販売車の情報を検索し、取得する。

サイト管理部１１２Ｃは、端末１０がアクセス可能なウェブサイトを管理する。具体的には、サイト管理部１１２Ｃは、ウェブサイト上にアップロードする情報を管理しており、例えば検索部１１２Ｂが販売希望車に関する整備・点検履歴情報を取得した場合に、その整備・点検履歴情報をウェブサイトにアップロードする。また、端末１０Ａから販売希望車の取り下げの指示を受信した場合に、サイト管理部１１２Ｃは、その販売希望車の情報をウェブサイト上から削除する。さらに、端末１０からのアクセスの内容に応じて、アクセスがあった端末１０に対して表示するウェブサイトの内容を更新し、通信部１１１を介して、その内容を端末１０に送信する。

記憶部１１３には、保有者の端末１０Ａの接続先（宛先）に関連付けられて、保有者の個人情報、端末１０Ａから取得した販売希望車情報、検索部１１２Ｂが取得した販売希望車に関する整備・点検履歴情報が格納される。サイト管理部１１２Ｃは、この記憶部１１３に格納された情報の中から所定の情報をウェブサイト上にアップロードする。また、記憶部１１３には、制御部１１２が実行する処理を実現するためのプログラムが格納されていても良い。

図１に戻り、説明を続ける。整備・点検履歴ＤＢ１２は、複数のユーザの保有車の整備・点検履歴情報を格納している。整備・点検履歴情報は、自動車を特定する車体番号や、整備・点検履歴情報を特定する特定番号に紐づけられた、各自動車の車検、法定点検、その他の点検の少なくともいずれかに関する情報をいう。

以下、図１及び図４を用いて、売買支援システムＳ１内でなされる通信及び処理の詳細を説明する。図４は、管理サーバ１１が実行する処理の例を示すフローチャートである。なお、以下の明細書中の符号（１１）～（１６）は、図１内の（１１）～（１６）と対応した説明を示す。

（１１）まず、自動車の保有者は、端末１０Ａの入力部１０３を操作して、販売希望車情報をウェブサイト上で入力し、通信部１０１を介して管理サーバ１１に送信する。通信部１１１は、その販売希望車情報を受信する（ステップＳ１１）。販売希望車情報は、例えば、車体番号、車検証、整備・点検履歴情報を特定する特定番号、販売希望車の詳細情報（車種、メーカー、色、走行距離、車のオプション、外観及び内観の状態を示すコメントや写真等の情報）、販売希望車に関する保有者からのコメント等を含んでも良い。一例として、表示部１０２に表示されるウェブサイト上に撮像部１０４の起動ボタンが設けられ、保有者がそれを入力部１０３の操作で押下すると、サイト管理部１１２Ｃが端末１０Ａに指示を出力することで、撮像部１０４が起動する。保有者が起動した撮像部１０４で車検証のＱＲコードを撮影することによって、端末１０Ａは車検証のデータを取得し、それは通信部１０１を介して管理サーバ１１に送信される。取得された車検証のデータは、表示部１０２に表示されても良い。

（１２）解析部１１２Ａがその販売希望車情報を解析した後、検索部１１２Ｂは、受信した車体番号を用いて、整備・点検履歴ＤＢ１２内から、その車体番号に紐づけられた整備・点検履歴情報を検索する（ステップＳ１２）。または、検索部１１２Ｂは、検索に、整備・点検履歴情報を特定する特定番号を用いても良い。

（１３）通信部１１１は、（１２）で検索した整備・点検履歴情報を取得する。解析部１１２Ａがこの情報を解析した後、サイト管理部１１２Ｃは、販売希望車情報及び整備・点検履歴情報を関連付けて、ウェブサイト上にアップロードする処理を実行する（ステップＳ１３）。これにより、販売希望車情報及び整備・点検履歴情報は、任意の端末から閲覧可能な状態となる。また、取得された販売希望車情報及び整備・点検履歴情報は、記憶部１１３に格納される。ここで、（１１）、（１２）において取得された自動車の情報以外の保有者に関する個人情報は記憶部１１３に格納されるが、ウェブサイト上にはアップロードされない。そのため、端末１０Ｂからその情報を取得することはできない。

（１４）また、サイト管理部１１２Ｃは、通信部１１１を介して端末１０Ａに対し、販売希望車のウェブサイト上での登録が完了したことを通知する（ステップＳ１４）。

（１５）次に、自動車の買い手は、端末１０Ｂの入力部１０３を操作して、購入を希望する販売車の情報をウェブサイト上で入力し、問い合わせ情報として、通信部１０１を介して管理サーバ１１に送信する。なお、問い合わせ情報は、例えば、買い手がウェブサイト上で指定した特定の自動車の詳細な情報を問い合わせるものでも良い。または、買い手がウェブサイト上で購入希望車の所望の条件を入力し、マッチングを要求するものでも良い。

通信部１１１は、端末１０Ｂから問い合わせ情報を取得する。検索部１１２Ｂは、その問い合わせの内容に応じて、記憶部１１３内に格納された、ウェブサイト上で現在公開されている販売希望車情報を検索し、問い合わせに合致する販売希望車情報と、それに関連付けられた整備・点検履歴情報を取得する（ステップＳ１５）。例えば、買い手がウェブサイト上で購入希望者の所望の条件を入力した場合、検索部１１２Ｂは、その条件に該当する販売希望車情報と、対応する整備・点検履歴情報を全て取得する。

（１６）サイト管理部１１２Ｃは、取得した販売希望車情報及び整備・点検履歴情報を端末１０Ｂに対して表示するウェブサイト上に表示させるよう、通信部１１１を介して、その情報を端末１０Ｂに送信する（ステップＳ１６）。

なお、サイト管理部１１２Ｃは、ウェブサイト上で、保有者や買い手のユーザ登録を受け付けても良い。例えば、保有者が端末１０Ａを介してユーザ登録処理を実行した後で、サイト管理部１１２Ｃが、端末１０Ａにウェブサイト上での販売希望車情報登録画面を表示させることで、保有者が、販売希望車情報を管理サーバ１１に送信可能としても良い。

また、買い手が端末１０Ｂを介してユーザ登録処理を実行した場合、解析部１１２Ａは通信部１１１を介してその登録処理情報を解析した後、サイト管理部１１２Ｃに対して、端末１０Ｂからの自動車の購入受付を許可させる。これにより、端末１０Ｂは、ウェブサイト上で閲覧できる購入希望車について、管理サーバ１１に対して、自動車の購入を申請することができる。ここで、ユーザ登録処理で端末１０Ｂから送信された買い手の個人情報は記憶部１１３に格納され、ウェブサイト上にはアップロードされない。そのため、端末１０Ａからその情報を取得することはできない。

また、買い手は、端末１０Ｂによって、販売希望車に関するコメントを記載しても良い。また、そのコメントに対して、保有者が端末１０Ａによって回答のコメントを記載しても良い。これらのコメントは、各端末１０から管理サーバ１１に送信され、サイト管理部１１２Ｃによって、その販売希望車情報と関連付けられて、ウェブサイト上でアップロードされるほか、記憶部１１３に格納される。したがって、保有者と買い手との間で、ウェブサイト上でチャットのようなコミュニケーションをすることができるため、円滑な売買取引を実行することができる。

以上に示した売買支援システムＳ１では、買い手が購入希望車の情報を問い合わせた段階で、その整備・点検履歴を参照できるため、中古車取引の信頼性を上げることができる。また、保有者及び買い手の個人情報は管理サーバ１１側で管理し、本人以外に公開されないため、プライバシーを考慮した中古車の取引が可能となる。

（１Ｂ：金額表示の処理）
図５は、（１Ａ）に記載の処理と並行して実施可能な処理を実施可能な売買支援システムを示す概略図である。図５は、図１と異なり、整備・点検履歴ＤＢ１２の代わりに、販売金額ＤＢ１３が設けられている。販売金額ＤＢ１３は、管理サーバ１１と接続されており、各種の中古車の販売金額の情報（いわゆる相場の情報）が、その中古車の詳細情報（車種、メーカー、色、走行距離、車のオプション、外観及び内観の状態を示すコメントや写真等）と対応付けて格納されているデータベースである。販売金額ＤＢ１３は、管理サーバ１１を有する仲介会社が保有していても良いし、異なる会社が保有していても良い。なお、端末１０、管理サーバ１１のブロック図は、図２、３に示した通りであるため、説明を省略する。

以下、図５及び図６を用いて、売買支援システムＳ１’内でなされる通信及び処理の詳細を説明する。図６は、管理サーバ１１が実行する処理の例を示すフローチャートである。図５内の（１１’）～（１６’）は、送受信される情報を時系列順に示したものであり、以下の明細書中の符号（１１’）～（１６’）は、図５内の（１１’）～（１６’）と対応した説明を示す。また、（１１’）～（１６’）の処理は、それぞれ、図１の（１１）～（１６）の処理と並行してなされるものである。

（１１’）まず、自動車の保有者は、販売希望車情報を送信する際に、その販売希望車の販売希望金額情報もウェブサイト上で入力し、通信部１０１を介して管理サーバ１１に送信する。この販売希望金額は、例えばＡＩ（Artificial Intelligence）による査定金額を参考にして保有者が決定するものでも良い。管理サーバ１１の通信部１１１は、販売希望車情報を端末１０Ａから受信する（ステップＳ１１’）。

（１２’）検索部１１２Ｂは、受信した販売希望車情報を用いて、販売金額ＤＢ１３内から、その販売希望車と類似した中古車の販売金額情報を検索する（ステップＳ１２’）。なお、検索には、（１３）で得られた整備・点検履歴情報をさらに用いても良い。

ここで、「販売希望車と類似した中古車」とは、例えば、販売金額を決定する要素である中古車の詳細情報と販売希望車の詳細情報とが、１又は複数の観点（例えば車種、メーカー、色、走行距離、車のオプション、外観及び内観の状態、整備・点検履歴といった観点）において、一致又は一致と見なせる範囲内にあることを示す。この類似の観点は、例えば検索部１１２Ｂが決定した上で検索しても良い。この類比判断については、適宜、公知の技術を用いることができる。

（１３’）通信部１１１は、（１２’）で検索した中古車の販売金額情報を取得する。解析部１１２Ａは、この情報を解析し、取得した中古車の販売金額の分布において、（１１’）で取得した販売希望金額がどの程度の位置にあるかを視覚的に認知可能なグラフを作成する。グラフは、棒グラフ等、任意の種類のグラフである。サイト管理部１１２Ｃは、販売希望車情報等と、この販売希望金額及びグラフを関連付けて、ウェブサイト上にアップロードする処理を実行する（ステップＳ１３’）。これにより、販売希望金額及びグラフは、販売希望車情報と関連付けられて、任意の端末から閲覧可能な状態となる。また、販売希望金額及びグラフは、販売希望車情報と関連付けられて、記憶部１１３に格納される。

（１４’）また、サイト管理部１１２Ｃは、通信部１１１を介して端末１０Ａに対し、販売希望車のウェブサイト上での登録が完了したことを通知する（ステップＳ１４’）。

（１５’）次に、自動車の買い手は、購入希望車の情報をウェブサイト上で入力し、問い合わせ情報として、通信部１０１を介して管理サーバ１１に送信する。検索部１１２Ｂは、その問い合わせの内容に合致する販売希望車情報等と、それに関連付けられた販売希望金額及びグラフ情報を、記憶部１１３を検索することで取得する（ステップＳ１５’）。

（１６’）サイト管理部１１２Ｃは、取得した販売希望金額及びグラフを端末１０Ｂに送信して表示させる（ステップＳ１６’）。なお、サイト管理部１１２Ｃは、端末１０Ｂに対し、少なくとも販売希望金額の情報を電子ファイルとして提供可能なようにウェブサイトを構成しても良い。電子ファイルの形式は、一例としてＰＤＦ（Portable Document Format）である。サイト管理部１１２Ｃは、端末１０Ｂからのアクセスに基づいて、通信部１１１を介して電子ファイルを端末１０Ｂに送信する。これにより、買い手は、購入希望車の販売価格を見積もりとしてダウンロードできる。なお、電子ファイルは、買い手の個人情報と紐づけて、記憶部１１３に格納されても良い。

以上のようにして、買い手は、購入希望車の販売希望金額を、その購入希望車と類似する中古車の販売金額のデータと合わせた形式のグラフとして閲覧できる。したがって、購入を検討している中古車が相場と比較してお得か否かを簡単に判定することができ、買い手の購入意欲の向上につながる。

なお、（１Ｂ）の処理において、（１Ａ）に示した整備・点検履歴情報の取得処理（１２）～（１３）は必須ではない。また、保有者がウェブサイト上でユーザ登録をした後で、サイト管理部１１２Ｃが、端末１０Ａにウェブサイト上での販売希望金額の入力画面を表示させ、販売希望金額を入力した後で（１１’）以降の処理がなされても良い。これにより、保有者がユーザ登録によって販売価格の査定ができるようになるため、保有者に対してユーザ登録をすることの動機付けを与えることができる。

その他、（１Ｂ）では、適宜、（１Ａ）と同じ処理又はバリエーションを適用することができる。例えば、保有者がその販売希望車に対してコメントを入力可能である場合、保有者は、ウェブサイト上で開示された販売希望金額及びグラフを参照して、販売希望車に関するアピールポイントをコメントして入力しても良い。例えば、販売希望金額がグラフ上で相場の金額より高い場合に、保有者はその理由（例えば、販売希望車にプレミアがついている等の理由）をコメントで記載できるため、より販売希望車を売りやすくなる。

また、管理サーバ１１は、（１２’）、（１３’）の処理に加えて、予め機械学習がなされた中古車とその販売金額との関係を示したモデルに対して、販売希望車情報を入力データとして入力させ、出力データとして出品目安の金額情報を取得し、その金額情報を販売希望車情報と関連付けてウェブサイト上で表示させても良い。このモデルは、例えば、管理サーバ１１の記憶部１１３に格納された、過去に販売された自動車の詳細情報及びその販売金額情報に基づいて、管理サーバ１１又は他の装置が機械学習することにより生成されたものであっても良い。また、モデルは、適宜更新することが可能である。

また、販売金額ＤＢ１３に代えて、予め機械学習がなされ、入力データと出力データとがそれぞれ類似する自動車を示すモデルが設けられても良い。検索部１１２Ｂは、そのモデルに対して、販売希望車情報を入力データとして入力させることで、出力データとして出力された（販売希望車と類似した）中古車の情報を取得する。この中古車の情報には販売金額情報が含まれているため、検索部１１２Ｂは、出力データから、中古車の販売金額情報を取得することができる。

実施の形態２
（２Ａ：買い替え提案の通知）
次に、実施の形態２では、管理サーバ（売買支援装置）が自動車の保有者に対する買い替え提案を生成し、それを送信する処理について説明する。

図７は、実施の形態２に係る売買支援システムを示す概略図である。図７の概略を説明すると、売買支援システムＳ２は、端末１０Ａ、管理サーバ２１、保有車ＤＢ２２（保有物品データベース）及び購入対象車ＤＢ２３（購入可能物品データベース）を少なくとも備える。端末１０Ａは、自動車の保有者が有する端末であり、その構成は図２で説明した通りである。管理サーバ２１は、端末１０Ａ、保有車ＤＢ２２及び購入対象車ＤＢ２３とそれぞれ接続されており、仲介会社が保有するサーバである。保有車ＤＢ２２、購入対象車ＤＢ２３は、それぞれ、複数のユーザの保有車に関する情報を格納するデータベース、ユーザが現在購入可能な自動車に関する情報を格納するデータベースであり、管理サーバ２１を有する仲介会社が保有していても良いし、異なる会社が保有していても良い。また、図７内の矢印は、送受信される情報を時系列順に示したものであり、この詳細については後述する。以下、各端末又は装置の詳細な構成について説明する。

図８は、管理サーバ２１の構成を示すブロック図である。管理サーバ２１は、通信部２１１、制御部２１２及び記憶部２１３を備える。ただし、管理サーバ２１は、端末１０と同様の機能を有する入力部や表示部をさらに備えても良い。管理サーバ２１は、１台又は複数台の任意の情報処理装置で構成される。また、管理サーバ２１は、端末１０がアクセス可能なウェブサイトを運営している。

通信部２１１（トランシーバ）は、端末１０、保有車ＤＢ２２及び購入対象車ＤＢ２３と情報を送受信する送信部及び受信部として機能する。例えば、端末１０とは、ウェブサイトを介した情報の送受信が可能である。

制御部２１２は、記憶部２１３からソフトウェア（コンピュータプログラム）を読み出して実行することで、解析部２１２Ａ、検索部２１２Ｂ、サイト管理部２１２Ｃ及び提案生成部２１２Ｄ等の機能を実現する。以下、これらの各機能について説明する。

解析部２１２Ａは、通信部２１１を介して受信した情報を解析し、次に管理サーバ２１が実行する処理を決定する。例えば、端末１０Ａからユーザの保有車の更新情報を受信した場合に、その情報を記憶部１１３に格納させるほか、その情報に基づいて、検索部２１２Ｂが、保有車ＤＢ２２内の保有車の情報（保有車情報）を検索する処理をするように決定する。また、解析部２１２Ａは、保有車ＤＢ２２から保有車情報を取得した場合に、その保有車情報に基づいて、検索部２１２Ｂが、購入対象車ＤＢ２３からその保有車に関連する買い替え候補車を検索（特定）する処理をするように決定する。なお、解析部２１２Ａは、実施の形態１に係る解析部１１２Ａと同様の処理を実行することもできる。

検索部２１２Ｂ（保有物品情報取得部及び特定部）は、解析部２１２Ａの解析結果に基づいて、所望の情報の検索を実行する。例えば、端末１０Ａから受信した更新情報に係る自動車の情報を、通信部２１１を介して保有車ＤＢ２２内の保有車情報の中から検索し、取得する。また、保有車ＤＢ２２から取得した保有車情報を用いて、保有車に関連する買い替え候補車の情報を、通信部２１１を介して購入対象車ＤＢ２３内の購入対象車情報の中から検索し、取得する。なお、検索部２１２Ｂは、実施の形態１に係る検索部１１２Ｂと同様の処理を実行することもできる。

ここで、検索部２１２Ｂは、「保有車に関連する買い替え候補車」を、例えば次の通り決定することができる。例えば、検索部２１２Ｂは、保有車情報と、購入対象車ＤＢ２３内の購入対象車情報とを、購入対象車毎に比較し、保有車と購入対象車とが類似していると判定された場合に、その購入対象車を買い替え候補車として特定しても良い。ここで、「保有車と購入対象車とが類似」とは、保有車と購入対象車とが類似しているといえる要素である保有車の詳細情報と購入対象車の詳細情報とが、１又は複数の観点（例えば車種、メーカー、色、車のオプション、外観及び内観の外見といった観点）において、一致又は一致と見なせる範囲内にあることを示す。この類似の観点は、記憶部２１３に事前に格納されているものを検索部２１２Ｂが読みだして用いることができる。

また、購入対象車ＤＢ２３に代えて、予め機械学習がなされ、入力データとして自動車情報が入力された場合に、その自動車に類似する購入対象車の情報を出力データとして出力するようなモデルが設けられても良い。検索部２１２Ｂは、そのモデルに対して、保有車情報を入力データとして入力させることで、出力データとして出力された（保有車と類似した）購入対象車を、買い替え候補車として取得する。

また、保有車情報には、ユーザが保有車を購入した際の価格情報が含まれていても良い。検索部２１２Ｂは、上述の観点として価格情報を考慮に入れた類似の判定を実行することで、買い替え候補車を特定する。これにより、検索部２１２Ｂは、購入対象車ＤＢ２３、又は機械学習によるモデルを用いたいずれの場合でも、保有車を購入した際の価格と同程度の価格帯の買い替え候補車を特定することができる。

サイト管理部２１２Ｃは、実施の形態１に係るサイト管理部１１２Ｃと同様の処理を実行するものであるため、説明を省略する。

提案生成部２１２Ｄは、ユーザに保有車から買い替え候補車への買い替えを提案する、買い替え候補車の情報が含まれた買い替え提案を生成する。例えば、ユーザの保有車がＡ車、買い替え候補車がＢ車である場合には、提案生成部２１２Ｄは、「新しく販売されたＢ車のご購入をご検討されてはいかがでしょうか」といった提案を生成する。提案生成部２１２Ｄは、買い替え提案を生成後、通信部２１１を介して端末１０Ａに送信しても良い。あるいは、提案生成部２１２Ｄは、生成した買い替え提案を管理サーバ２１の表示部に表示させ、営業スタッフ等が管理サーバ２１の入力部によって買い替え提案の情報を修正可能なようにしても良い。修正された買い替え提案は、営業スタッフの操作によって、端末１０Ａに送信される。

記憶部２１３には、端末１０Ａから取得した自動車の更新情報、検索部２１２Ｂが取得した保有車情報及び買い替え候補車の情報が格納される。また、記憶部２１３には、提案生成部２１２Ｄで生成された買い替え提案の内容及びその送信日時の情報が、管理サーバ２１が管理する保有者の個人情報（例えば氏名、保有車の車体番号等）に関連付けられて格納されている。さらに、記憶部２１３には、制御部２１２が実行する処理を実現するためのプログラムが格納されていても良い。なお、記憶部２１３は、実施の形態１に係る記憶部１１３と同様の処理を実行することもできる。

図７に戻り、説明を続ける。保有車ＤＢ２２は、仲介会社が把握するユーザについて、その保有車の保有車情報を格納している。保有車情報は、自動車を特定する車体番号や、自動車の車種、メーカー、色、走行距離、車のオプション、外観及び内観の状態等の詳細情報を含んでも良い。また、保有車情報には、上述の整備・点検履歴情報が含まれても良い。保有車ＤＢ２２は、例えば、ユーザが現在の保有車を購入したとき、又はユーザが仲介会社にユーザ登録をしたときに、保有車情報が格納される。

購入対象車ＤＢ２３は、ユーザが現在購入可能な自動車及び将来購入可能となる自動車に関する購入対象車情報を格納している。購入対象車情報は、保有車情報と同様の詳細情報を含んでも良い。また、購入可能な自動車は、新車だけでなく中古車も含まれていても良い。

以下、図７及び図９を用いて、売買支援システムＳ２内でなされる通信及び処理の詳細を説明する。図９は、管理サーバ１１が実行する処理の例を示すフローチャートである。なお、以下の明細書中の符号（２１）～（２６）は、図７内の（２１）～（２６）と対応した説明を示す。

（２１）まず、自動車の保有者は、端末１０Ａの入力部１０３を操作して、自身の保有車の更新情報を、通信部１０１を介して管理サーバ２１に送信する。更新情報は、管理サーバ２１が運営しているウェブサイト上で入力されることにより送信されても良いし、メール等の媒体により管理サーバ２１に送信されても良い。更新情報は、保有車の購入時又は前回の更新情報送信時からの保有車の状態の変化の有無を示す情報であり、例えば整備・点検履歴、車検の更新情報、事故の有無、走行距離の変化、外観及び内観状態の変化（例えば傷の発生）の少なくともいずれかを示す情報であっても良いが、これらに限られない。更新情報は、「変化なし」であることを示す情報であっても良い。また、更新情報には、車体番号等、保有車情報の検索に用いられる情報が含まれる。管理サーバ２１の通信部２１１は、更新情報を端末１０Ａから受信する（ステップＳ２１；受信ステップ）。

（２２）解析部２１２Ａがその更新情報を解析した後、検索部２１２Ｂは、受信した車体番号を用いて、保有車ＤＢ２２内から、その車体番号に紐づけられた保有車情報を検索する（ステップＳ２２）。

（２３）通信部２１１は、（２２）で検索した保有車情報を取得し、解析部２１２Ａがこの情報を解析する（ステップＳ２３；保有物品情報取得ステップ）。

（２４）検索部２１２Ｂは、取得した保有車情報を用いて、保有車に関連する買い替え候補車を、通信部２１１を介して、購入対象車ＤＢ２３内の購入対象車情報の中から検索する（ステップＳ２４；特定ステップ）。なお、検索部２１２Ｂは、検索の際に、ステップＳ２１で取得した更新情報や、記憶部２１３に格納された保有者の個人情報を用いても良い。

（２５）通信部２１１は、（２４）で検索した買い替え候補車の情報を取得し、解析部２１２Ａがこの情報を解析する。そして、提案生成部２１２Ｄは、買い替え候補車の情報が含まれた買い替え提案を生成する（ステップＳ２５；提案生成ステップ）。

（２６）提案生成部２１２Ｄは、通信部１１１を介して、買い替え提案を端末１０Ａに送信する（ステップＳ２６）。端末１０Ａは、通信部１０１で受信した買い替え提案を表示部１０２に表示させることで、保有者が買い替え提案を見ることができる。提案生成部２１２Ｄは、生成した買い替え提案の内容及びその送信日時の情報を、保有者毎に記憶部２１３に格納させる。

ここで、保有者は、入力部１０３を操作し、買い替え提案で提案された買い替え候補物品に興味を有する旨の通知を、管理サーバ２１に送信しても良い。保有者は、例えば、買い替え提案のメールに返信することにより、この通知を送信することができる。通信部２１１は、この通知を受信し、解析部２１２Ａは、この通知内容を解析して、検索部２１２Ｂの設定を次のように変更する。検索部２１２Ｂは、その通知に基づいて、ユーザが興味を有する買い替え候補車と類似の購入対象車を、次回以降に提案生成部２１２Ｄが提案する買い替え候補車として特定する。次回以降とは、例えば、端末１０Ａから更新情報を次に受信したタイミングであっても良いし、それ以降のタイミングであっても良い。その場合、検索部２１２Ｂは、保有車情報に代えて買い替え候補車に係る情報を、購入対象車ＤＢ２３又は機械学習によるモデルに適用して、上述の購入対象車の特定方法を実行すれば良い。

なお、ステップＳ２４にて検索部２１２Ｂが保有車に関連する買い替え候補車を検索できなかった場合には、管理サーバ２１は、以降の処理を実行しない。

以上に示した売買支援システムＳ２では、更新情報の送信をトリガとして、管理サーバ２１が保有物品の買い替えを促すことができるため、物品の取引を活性化させることが可能となる。

ここで、検索部２１２Ｂが価格情報に基づいて、買い替え候補物品を特定することもできる。これにより、管理サーバ２１は、ユーザが購入を想定すると考えられる価格帯の買い替え候補物品を提案することができるため、よりユーザに適した買い替えの提案をすることができる。

（２Ｂ：買い替え提案に関する詳細その１）
（２Ａ）に示した管理サーバ２１の処理として、（２Ｂ）、（２Ｃ）に記載のような、さらに詳細な以下の処理がなされても良い。

例えば、購入対象車ＤＢ２３に新たに購入対象車情報（以下、追加車情報と記載）が追加された場合に、購入対象車ＤＢ２３は管理サーバ２１に対し、その旨を通知しても良い。解析部２１２Ａはその通知を解析し、検索部２１２Ｂに対して、購入対象車ＤＢ２３から追加車情報を取得させる。なお、購入対象車ＤＢ２３は、追加車情報を新たに格納した場合に、管理サーバ２１に自動的に送信しても良い。

また、検索部２１２Ｂは、保有車ＤＢ２２から、ある保有者の保有車情報を取得する。ここで、保有車情報が取得対象（つまり、以降における買い替え提案の生成判定の対象）となる保有者は、例えば、記憶部２１３に格納されている全ての保有者であっても良いし、前回の買い替え提案を送信してから所定の閾値（期間）が経過後の保有者であっても良い。この所定の閾値は、記憶部２１３に格納されている。検索部２１２Ｂは、この閾値と、買い替え提案の前回の送信日時の情報を記憶部２１３から取得して、買い替え提案の生成判定の対象となる保有者を判定することを、保有者毎に行う。

そして、検索部２１２Ｂは、保有車情報における保有車と、追加車情報における自動車が類似しているか否かを判定する。この類似の判定方法は、例えば（２Ａ）に記載の通りである。両者が類似していると判定された場合に、検索部２１２Ｂは、その追加された自動車を、提案生成部２１２Ｄが次回以降に提案する買い替え候補車として特定する。提案生成部２１２Ｄは、この買い替え候補車に係る買い替え提案を生成し、通信部２１１は、保有者に対し、更新情報の送信を促す通知を送信する。管理サーバ２１は、買い替え提案の生成判定の対象となった全ての保有者に対して、この処理を行う。

「更新情報の送信を促す通知」は、例えば、「〇〇様のお車に最近変わった点はありませんか？以下の中から選択してください」といったように、保有者に対して更新情報を入力させることを促すものである。その通知に保有者が所定情報を入力して返信すると、更新情報が上述のステップＳ２１のように管理サーバ２１に送信される。管理サーバ２１の解析部２１１Ａがその更新情報を解析した上で、提案生成部２１２Ｄはその更新情報をトリガとして、以上の処理で予め生成した買い替え提案を端末１０Ａに送信させる。

また、記憶部２１３に格納された保有者の個人情報には、保有者が嗜好を有する自動車の情報（嗜好車情報）が含まれていても良い。嗜好車情報には、例えば嗜好を有する自動車における、車種、メーカー、色、走行距離、車のオプション、外観及び内観の外見等が含まれる。検索部２１２Ｂは、嗜好車情報における自動車と、追加車情報における自動車が類似しているか否かを判定する。つまり、上述の保有車情報に代えて、嗜好車情報を類似の判定に用いる。

嗜好車情報における自動車と、追加車情報における自動車とが類似していると判定された場合に、検索部２１２Ｂは、その追加された自動車を、提案生成部２１２Ｄが次回以降に提案する買い替え候補車として特定する。提案生成部２１２Ｄは、この買い替え候補車に係る買い替え提案を生成し、通信部２１１は、保有者に対し、更新情報の送信を促す通知を送信する。管理サーバ２１は、買い替え提案の生成判定の対象となった全ての保有者に対して、この処理を行う。管理サーバ２１が保有者から更新情報を受信した場合には、解析部２１２Ａがそのことを判定した上で、提案生成部２１２Ｄがその保有者に対して予め生成した買い替え提案を、通信部２１１を介して送信させる。

これにより、管理サーバ２１は、新たに購入可能となった自動車のうち、保有車と似ている自動車、又は保有者の嗜好に合った自動車を買い替え候補物品として提案することができるため、よりユーザの購買意欲を向上させることができる。

なお、管理サーバ２１は、更新情報の送信を促す通知に代えて、類似すると判定された追加車情報における自動車に関する買い替え提案を生成し、端末１０Ａに送信することもできる。しかしながら、保有者からのアクションを一旦待ってから買い替え提案を端末１０Ａに送信することで、保有者に買い替え提案をより受け入れてもらいやすくなる。

さらに、記憶部２１３には、各保有者に関して、更新情報の送信を促す通知の前回の送信日時の情報が格納されていても良い。検索部２１２Ｂは、買い替え提案の生成判定の対象となる保有者を決定する場合に、保有者毎にこの前回の送信日時の情報を抽出して、前回の送信日時から所定の閾値（期間）が経過したか否かを判定する。そして、前回の送信日時から所定の閾値が経過後の保有者を、買い替え提案の生成判定の対象とする一方、それ以外の保有者は、その対象外とする。すなわち、それ以外の保有者には、新たな更新情報の送信を促す通知が送信されない。この所定の閾値は、記憶部２１３に格納されている。これにより、保有者は、短い期間に管理サーバ２１から通知を重ねて受けなくなるため、保有者が感じる煩わしさを抑制させることができる。

（２Ｃ：買い替え提案に関する詳細その２）
（２Ｂ）において、保有車情報における保有車と、追加車情報における自動車が類似していると判定された場合に、検索部２１２Ｂは、両者の類似度をさらに判定しても良い。類似度は、例えば、類似に関する上述の観点（例えば車種、メーカー、色、車のオプション、外観及び内観の外見といった観点）において、一致又は一致と見なせる範囲内にある要素の数で表される。又は、上述の通り、購入対象車ＤＢ２３に代えて予め機械学習がなされたモデルが用いられる場合には、モデルが出力する出力データに、類似する自動車の情報の他、その自動車と入力データに係る自動車との類似度の数値が含まれることで表されても良い。検索部２１２Ｂは、両者の類似度が所定の閾値（類似度）以上であるか否かを判定する。この所定の閾値は、記憶部２１３に格納されているものである。

両者の類似度が所定の閾値以上である場合には、更新情報の送信を促す通知を前回に送信してから所定の期間（例えば、数週間～数か月）が経過する前であっても、検索部２１２Ｂは、追加された自動車を、提案生成部２１２Ｄが現在提案する買い替え候補車として特定する。提案生成部２１２Ｄは、この買い替え候補車に係る買い替え提案を生成し、通信部２１１は、保有者に対し、更新情報の送信を促す通知を送信する。

一方、両者の類似度が所定の閾値未満である場合には、検索部２１２Ｂは、追加された自動車を、提案生成部２１２Ｄが将来提案する買い替え候補車として特定する。この「将来」は、更新情報の送信を促す通知を前回に送信してから所定の期間が経過した後のタイミングをいう。そのタイミングが到来した場合に、提案生成部２１２Ｄは、この買い替え候補車に係る買い替え提案を生成し、通信部２１１は、保有者に対し、更新情報の送信を促す通知を送信する。したがって、この段階では、新たな更新情報の送信を促す通知は送信されない。管理サーバ２１は、買い替え提案の生成判定の対象となる全ての保有者に対して、以上の処理を行う。

また、両者の類似度が所定の閾値以上である場合には、検索部２１２Ｂは、更新情報の送信を促す通知を前回に送信してから第１の期間ｔ１が経過した後に、通信部２１１が保有者に対して更新情報の送信を促す通知を送信するように設定しても良い。一方、両者の類似度が所定の閾値未満である場合には、検索部２１２Ｂは、更新情報の送信を促す通知を前回に送信してから第２の期間ｔ２（＞ｔ１）が経過した後に、通信部２１１が保有者に対して更新情報の送信を促す通知を送信するように設定する。第１の期間ｔ１、第２の期間ｔ２は、記憶部２１３に格納された判定用の閾値である。また、検索部２１２Ｂは、上述と同様、追加された自動車を、提案生成部２１２Ｄが将来提案する買い替え候補車として特定する。

以上の処理により、保有者は、自分の興味と一致度が低い物品の買い替え提案を受信しにくくなるため、保有者が感じる煩わしさを抑制させることができる。

また、この（２Ｃ）に記載した処理は、保有車情報における保有車と、追加車情報における自動車が類似していると判定された場合ではなく、保有者が嗜好を有する自動車と追加車情報における自動車が類似していると判定された場合でも、同様に実行可能である。このようにしても、同様の効果が得られる。なお、いずれの場合でも、管理サーバ２１が保有者から更新情報を受信した場合には、解析部２１２Ａがそのことを判定し、提案生成部２１２Ｄがその保有者に対して予め生成した買い替え提案を、通信部２１１を介して送信させることができる。また、判定に用いる閾値は、任意に変更されることができる。

以降の実施の形態では、実施の形態１、２における売買支援システムに適宜適用可能な、その他の実施形態について説明する。また、異なる実施の形態に記載された構成及び処理についても、適宜組み合わせて用いることができる。

実施の形態３（販売希望金額の決定）
図１０は、実施の形態３に係る売買支援システムを示す概略図である。図１０の概略を説明すると、売買支援システムＳ３は、端末１０Ａ、１０Ｂ、管理サーバ１１、販売金額ＤＢ１３及び関連情報ＤＢ３１を少なくとも備える。端末１０Ａ、１０Ｂ、販売金額ＤＢ１３については、実施の形態１にて説明した通りである。管理サーバ１１は、端末１０Ａ、１０Ｂ、管理サーバ１１、販売金額ＤＢ１３及び関連情報ＤＢ３１とそれぞれ接続されており、仲介会社が保有するサーバである。管理サーバ１１の構成については、図３に示した通りである。また、図１０内の矢印は、送受信される情報を時系列順に示したものであり、この詳細については後述する。

関連情報ＤＢ３１は、管理サーバ１１が管理する保有者の保有車に関する関連情報を格納するデータベースであり、管理サーバ１１を有する仲介会社が保有していても良いし、異なる会社が保有していても良い。ここで、関連情報とは、例えば、保有車のカタログデータ（車両諸元表）、環境性能割課税、自動車税、修理保証料金といった、中古車の買い手が支払う金銭全般の情報を含む。関連情報は、保有車の車体番号等、保有車を特定可能な情報と関連付けられて関連情報ＤＢ３１内に格納されている。

以下、図１０及び図１１を用いて、売買支援システムＳ３内でなされる通信及び処理の詳細を説明する。図１１は、管理サーバ１１が実行する処理の例を示すフローチャートである。なお、以下の明細書中の符号（３１）～（３７）は、図１０内の（３１）～（３７）と対応した説明を示す。

（３１）まず、自動車の保有者は、入力部１０３を用いて販売希望車情報を入力し、管理サーバ１１に送信する。これにより、通信部１１１がその販売希望車情報を受信する（ステップＳ３１）。入力は、例えばＱＲコードを撮影して取得したデータを、ウェブサイト経由で管理サーバ１１に送信するものであっても良い。また、この販売希望車情報には、保有車の販売希望金額は含まれていない。

（３２）解析部１１２Ａがその販売希望車情報を解析した後、検索部１１２Ｂは、受信した販売希望車情報を用いて、販売金額ＤＢ１３内から、その販売希望車と類似した中古車の販売金額情報を検索する。この詳細は、ステップＳ１２’と同様である。

（３２’）また、検索部１１２Ｂは、受信した販売希望車情報を用いて、関連情報ＤＢ３１内から、その販売希望車に関する関連情報を検索する（ステップＳ３２）。以上の検索には、例えば受信した車体番号が用いられる。

（３３）通信部１１１は、（３２）で検索した中古車の販売金額情報を取得する。解析部１１２Ａは、この情報を解析し、中古車の販売金額情報の分布に関するグラフを作成する。このグラフの具体例は、ステップＳ１３’で説明した通りである。

（３３’）また、通信部１１１は、（３２’）で検索した関連情報を取得する（ステップＳ３３）。以上の処理で得られた情報は、販売希望車情報と関連付けられて、記憶部１１３に格納される。

また、管理サーバ１１は、（３２）、（３３）、（３２’）、（３３’）の処理に加えて、予め機械学習がなされた中古車とその販売金額との関係を示したモデルに対して、販売希望車情報を入力データとして入力させることで、出品目安の金額情報を出力データとして取得しても良い。このモデルの詳細は実施の形態１に記載の通りである。さらに、このモデルとは別のＡＩによって導出された査定金額も、出品目安の金額情報として算出されても良い。このように取得された金額情報は、販売希望車情報と関連付けられて、記憶部１１３に格納される。

（３４）検索部１１２Ｂは、以上の処理で得られたグラフ、販売希望車に関する関連情報、及び出品目安の金額情報を、販売希望金額の決定に関する情報として、通信部１１１を介して端末１０Ａに送信する（ステップＳ３４）。

（３５）自動車の保有者は、送信された情報を閲覧して、保有車の販売金額の相場や、保有車の買い手が支払うことになる金額の情報を確認する。これらの情報に基づいて、保有者は、保有車の販売希望金額を決定し、その販売希望金額をウェブサイト上で入力して、管理サーバ１１に送信する。管理サーバ１１は、販売希望金額の情報を受信する（ステップＳ３５）。

（３６）解析部１１２Ａが販売希望金額の情報を解析した後、サイト管理部１１２Ｃは、取得した販売希望車の販売希望金額をグラフ上でプロットする。そして、販売希望車情報、関連情報、販売希望車の販売希望金額及びプロットされたグラフを関連付けて、ウェブサイト上にアップロードする処理を実行する（ステップＳ３６）。また、サイト管理部１１２Ｃは、通信部１１１を介して端末１０Ａに対し、販売希望車のウェブサイト上での登録が完了したことを通知する。

（３７）アップロードされた情報は、任意の端末、例えば端末１０Ｂから閲覧可能な状態となる。端末１０Ｂは、アップロードされた購入に係る金額情報を、概算見積もりの電子ファイルとして取得することもできる。なお、電子ファイルは、買い手の個人情報と紐づけて、記憶部１１３に格納されても良い。

以上の処理によって、保有者が販売希望金額を決定する際に、保有車の販売金額の相場や、保有者の買い手が支払うことになる金額の情報を確認することができるため、より販売しやすい金額又は当初の予想よりも高い金額を設定することができる。したがって、保有者にとって利益となる取引が可能となる。また、買い手にとっても、中古車の関連情報を確認することができるため、支払うことになる金額をより正確に知ることができる。

なお、（３１）において、端末１０Ａから送信される販売希望車情報に、保有車の販売希望金額が含まれていても良い。この場合、（３５）で、自動車の保有者は、送信された情報を閲覧した上で保有車の販売希望金額を修正し、その販売希望金額情報を管理サーバ１１に送信することになる。（３６）で生成されるグラフには、修正後の販売希望金額情報が表示される。

実施の形態４（お試し出品のシステム）
図１２は、実施の形態４に係る売買支援システムを示す概略図である。図１２の概略を説明すると、売買支援システムＳ４は、端末１０Ａ、１０Ｂ、管理サーバ１１、整備・点検履歴ＤＢ１２及び販売金額ＤＢ１３を少なくとも備える、保有車のお試し出品（仮出品）を可能とするシステムである。売買支援システムＳ４の各構成要素については、実施の形態１で説明した通りである。また、図１２内の矢印は、送受信される情報を時系列順に示したものであり、以下、この詳細について説明する。

図１２及び図１３を用いて、売買支援システムＳ４内でなされる通信及び処理の詳細を説明する。図１３は、管理サーバ１１が実行する処理の例を示すフローチャートである。なお、以下の明細書中の符号（４１）～（４７）は、図１２内の（４１）～（４７）と対応した説明を示す。

（４１）まず、自動車の保有者は、入力部１０３を用いて、お試し出品の対象となる保有車についての販売希望車情報及び販売希望金額を入力し、管理サーバ１１に送信する。これにより、通信部１１１がその販売希望車情報を受信する（ステップＳ４１）。なお、入力は、例えばウェブサイト上でなされても良い。

（４２）管理サーバ１１がステップＳ１２と同様の処理をすることで、検索部１１２Ｂは、販売希望車に関する整備・点検履歴情報を検索する。

（４２’）また、管理サーバ１１がステップＳ１２’と同様の処理をすることで、検索部１１２Ｂは、販売金額ＤＢ１３内から、その販売希望車と類似した中古車の販売金額情報を検索する（ステップＳ４２）。

（４３）通信部１１１は、（４２）で検索した整備・点検履歴情報を取得する。

（４３’）また、通信部１１１は、（４２’）で検索した関連情報を取得する。解析部１１２Ａがこれらの情報を解析した後、サイト管理部１１２Ｃは、販売希望車情報、販売金額情報及び整備・点検履歴情報を関連付けて、ウェブサイト上にアップロードする処理を実行する（ステップＳ４３）。これにより、アップロードされた情報は、任意の端末から閲覧可能な状態となる。また、以上の処理で得られた情報は、販売希望車情報と関連付けられて、記憶部１１３に格納される。

（４４）サイト管理部１１２Ｃは、通信部１１１を介して端末１０Ａに対し、販売希望車のウェブサイト上での仮登録（お試し出品）が完了したことを通知する（ステップＳ４４）。

（４５）ウェブサイト上でお試し出品された中古車（販売希望車）に関しては、サイト管理部１１２Ｃは、他の端末からの購入手続きは受け付けていない。その代わり、サイト管理部１１２Ｃは、お試し出品された中古車に関連付けて、その中古車の本出品の申請を受け付ける構成を、ウェブサイトに備える。買い手は、お試し出品された販売希望車情報を閲覧した後、その自動車の本出品の申請を、端末１０Ｂの入力部１０３を操作することで、ウェブサイトを介して管理サーバ１１に送信する。通信部１１１は、端末１０Ｂから送信された本出品の申請を受信する（ステップＳ４５）。

（４６）解析部１１２Ａが受信した情報を解析した後、サイト管理部１１２Ｃは、端末１０Ａに対して、本出品の申請がなされたことを通知する（ステップＳ４６）。

（４７）保有者は、端末１０Ａになされた通知から、本出品の申請がなされたことを把握し、本出品をすることで保有車が売れる可能性が高いと判断して、入力部１０３を操作することで、管理サーバ１１に本出品の要求を送信する。通信部１１１は、端末１０Ａから送信された本出品の要求を受信する。そして、サイト管理部１１２Ｃは、本出品の要求があった販売希望車について、他の端末からの購入手続きの受付を開始する本出品処理を行う（ステップＳ４７）。

以上の処理によって、保有者は、本出品の前にお試し出品が可能となり、自分の保有車に需要があるか否かを、本出品の前に知ることができる。したがって、保有者は、需要があると考えられる効果的なタイミングで、保有車を販売することができる。

なお、お試し出品中に、保有者は、端末１０Ａを通じてお試し出品を取り下げる要求を管理サーバ１１に送信することも可能である。この場合、サイト管理部１１２Ｃは、要求があった販売希望車について、その販売希望車情報等のアップロードを取り下げ、他の端末から表示されないようにする。また、管理サーバ１１は、お試し出品から所定の期間が経過するまで保有者から本出品の要求が通知されない場合にも、お試し出品を取り下げても良い。この所定の期間は、記憶部１１３に格納されている。

また、サイト管理部１１２Ｃは、ウェブサイトに、現在ウェブサイトにアップロードされた自動車（本出品されたものとお試し出品されたものの両方を含む）を買い手が検索する機能を設けても良い。端末１０Ｂは、ウェブサイトを通じて、買い手が入力した購入希望車の詳細情報（価格帯、車種、メーカー、色、走行距離、車のオプション、外観及び内観の状態等の情報）を管理サーバ１１に送信する。通信部１１１は、その情報を受信し、解析部１１２Ａはその情報を解析する。その結果に応じて、サイト管理部１１２Ｃは、アップロードされている自動車の中から、指定された購入希望車の条件を満たすものを抽出し、抽出された自動車の販売希望車情報を、ウェブサイト上で表示される情報として、通信部１１１から端末１０Ｂに送信する。買い手は、この情報を閲覧することにより、購入を希望する特定の自動車に関して、上述の本出品の申請をすることができる。

また、管理サーバ１１は、実施の形態２における買い替え提案とともに、保有車のお試し出品の提案を送信しても良い。その提案に返信する形で、端末１０Ａから保有車のお試し出品を希望する通知が送信された場合、管理サーバ１１は、（４１）に係る販売希望金額が入力可能な入力フォーマットの情報を、メールやウェブサイト等によって端末１０Ａに送信する。この場合、販売希望車情報は、ステップＳ２３で事前に取得した保有車情報を転用することができるため、保有者から取得する必要はない。

実施の形態５（傷情報に基づく修理金額算出のシステム）
図１４は、実施の形態５に係る売買支援システムを示す概略図である。図１４の概略を説明すると、売買支援システムＳ５は、端末１０Ａ、１０Ｂ、管理サーバ１１及び傷情報ＤＢ５１を少なくとも備える、保有車の修理金額算出を可能とするシステムである。傷情報ＤＢ５１は、自動車に傷が生じた各事例における詳細な傷情報、修理内容及び修理金額が対応付けて格納されている。傷情報は、例えば傷の位置、種類、大きさ、修復履歴といった傷の属性情報を有する。修理内容は、例えば板金加工や塗装が該当するが、これに限られない。その他の売買支援システムＳ５の各構成要素については、実施の形態１で説明した通りである。また、図１４内の矢印は、送受信される情報を時系列順に示したものであり、以下、この詳細について説明する。

図１４及び図１５を用いて、売買支援システムＳ５内でなされる通信及び処理の詳細を説明する。図１５は、管理サーバ１１が実行する処理の例を示すフローチャートである。なお、以下の明細書中の符号（５１）～（５７）は、図１４内の（５１）～（５７）と対応した説明を示す。また、以下の処理は、一例として、実施の形態３の（３１）以降の処理と並行に実行することができる。

（５１）まず、管理サーバ１１は、端末１０Ａからのアクセスに基づいて、保有者が自身の自動車の傷情報を入力するための画面（傷入力画面）を、通信部１１１によって端末１０Ａに送信する（ステップＳ５１）。なお、傷入力画面の表示は、例えばウェブサイト上で表示されても良い。傷入力画面は、例えば、自動車のパーツ毎に、傷情報の入力（例えば写真の添付）が可能なものであっても良い。

（５２）保有者は、自車両の外観や内観の傷情報を、コメント、図面の記載、写真の添付等の任意の方法で、表示部１０２上で入力し、管理サーバ１１に送信する。通信部１１１は、その情報を受信する（ステップＳ５２）。

（５３）解析部１１２Ａが受信した情報の解析をした結果、検索部１１１Ｂによる傷情報ＤＢ５１の検索がなされる（ステップＳ５３）。詳細には、検索部１１１Ｂは、傷情報に含まれる傷の位置、種類、大きさ、修復履歴といった属性に基づいて、ステップＳ５１で受信した傷と類似の傷の事例を傷情報ＤＢ５１から抽出する。

（５４）検索部１１１Ｂは、抽出された事例における修理内容及び修理金額の情報を取得する（ステップＳ５４）。

（５５）通信部１１１は、ステップＳ５４で取得した修理内容及び修理金額の情報を見積もりの情報として、端末１０Ａに送信する（ステップＳ５５）。

（５６）端末１０Ａのユーザは、送信された修理の見積もりの情報に基づいて、保有車の販売希望金額を決定する。なお、端末１０Ａには、修理の見積もりの情報のほか、（３５）で示した、保有車の販売金額の相場や、保有車の買い手が支払うことになる金額の情報も表示されていても良い。保有者は、販売希望金額をウェブサイト上で入力して、管理サーバ１１に送信する。管理サーバ１１は、販売希望金額の情報を受信する。そして、サイト管理部１１２Ｃは、販売希望金額の情報をウェブサイト上にアップロードする（ステップＳ５６）。さらに、サイト管理部１１２Ｃは、ステップＳ５２で受信した傷情報、ステップＳ５４で取得した修理内容及び修理金額の情報もウェブサイト上にアップロードしても良い。また、通信部１１１を介して端末１０Ａに対し、販売希望車のウェブサイト上での登録が完了したことを通知する。

（５７）アップロードされた情報は、任意の端末、例えば端末１０Ｂから閲覧可能な状態となる。端末１０Ｂは、アップロードされた購入に係る金額情報を、概算見積もりの電子ファイルとして取得することもできる。

以上の処理によって、保有者は、修理費用の見積もりを事前に知ることで、より妥当と考えられる販売希望金額を設定することができる。また、買い手にとっても、購入に係る費用をより正確に知ることができる。

なお、傷情報ＤＢ５１に代えて、傷情報とその修理内容及び修理金額に関して予め機械学習がなされたモデルが設けられても良い。検索部２１２Ｂは、そのモデルに対して、ステップＳ５２で得られた傷情報を入力データとして入力させることで、出力データとして出力された修理内容及び修理金額の情報を取得する。

また、サイト管理部１１２Ｃは、（５２）において、ウェブサイトの機能として、傷情報に係る写真の背景を加工する機能や、写真に写りこんだ保有車のナンバープレートを隠す機能を、端末１０Ａに提供しても良い。写真の背景を加工するとは、例えば保有車以外の背景領域を白抜きにしたり、仮想の背景領域にしたりすることをいう。保有者は、ウェブサイト上で入力部１０３を操作することで、写真に対してこれらの処理を実行する。サイト管理部１１２Ｃは、この処理済の写真をウェブサイト上にアップロードすることで、プライバシーに配慮した表示をすることができる。

実施の形態６（保有車の各種情報の取得）
図１６は、実施の形態６に係る売買支援システムを示す概略図である。図１６の概略を説明すると、売買支援システムＳ６は、端末１０Ａ、管理サーバ１１、販売金額ＤＢ１３及び保有車ＤＢ２２を少なくとも備える、保有車の各種情報の取得を可能とするシステムである。売買支援システムＳ６の各構成要素については、以前の実施の形態で説明した通りである。また、図１６内の矢印は、送受信される情報を時系列順に示したものであり、以下、この詳細について説明する。

図１６及び図１７を用いて、売買支援システムＳ６内でなされる通信及び処理の詳細を説明する。図１７は、管理サーバ１１が実行する処理の例を示すフローチャートである。なお、以下の明細書中の符号（６１）～（６４）は、図１４内の（６１）～（６４）と対応した説明を示す。また、以下の処理は、実施の形態２における更新情報の送信を促す通知に基づいてなされるとして説明されるが、それに限られず、任意のタイミングでなされても良い。

（６１）まず、自動車の保有者は、更新情報の送信を促す通知を受信すると、その通知に返信する形式で、入力部１０３を用いて、保有車に関する情報を管理サーバ１１に送信する。ここでは、撮像部１０４が車検証のＱＲコードを撮影することにより、端末１０Ａが車検証のデータを取得し、管理サーバ１１に送信するが、保有車に関する情報を送信する方法はこれに限られない。車検証のデータを取得する方法の詳細は上述の通りである。以上のようにして、通信部１１１は、車検証のデータを受信する（ステップＳ６１）。

（６２）解析部１１２Ａは、受信した車検証のデータを解析することにより、検索部１１１Ｂに保有車に関する検索を実施させる。具体的には、検索部１１１Ｂは、受信した保有車情報中の車体番号を用いて、保有車ＤＢ２２内から、その車体番号に紐づけられた保有車情報を検索する。この保有車情報には、例えば、保有車がリコール対象であるか否か、車検や法定点検（１２か月・２４か月）のタイミング、車両のオプション（例えばサンルーフ、カーナビ、シート）の有無に関する各種情報が含まれる。また、保有車情報には、上述の保有車の詳細情報や、整備・点検履歴情報が含まれていても良い。

（６２’）また、検索部１１１Ｂは、受信した車検証のデータに含まれる情報を用いて、販売金額ＤＢ１３内から、その保有車と類似した中古車の販売金額情報を検索する（ステップＳ６２）。なお、検索部１１１Ｂは、（６２）で保有車ＤＢ２２から取得された保有車の詳細情報や、整備・点検履歴情報を検索に用いても良い。

（６３）通信部１１１は、（６２）で検索した所有車の保有車情報を取得する。

（６３’）また、通信部１１１は、（６２’）で検索した中古車の販売金額情報を取得する。ここで取得される販売金額情報には、各中古車の使用年数や、走行距離等の情報も含まれる。

解析部１１２Ａは、車検証のデータや保有車情報を解析して、（６３’）で取得した中古車の販売金額情報に基づき、対象となる保有車の現在又は将来の査定価格を予測する（ステップＳ６３）。例えば、解析部１１２Ａは、各種情報に基づいて、保有車の次回の車検のタイミングを判定する。そして、その時点での保有車の使用年数の情報と、平均的な使用における走行距離のデータに基づいて算出されたその時点での予想走行距離の情報に基づいて、取得した中古車の販売金額情報を用い、その時点での保有車の査定価格を予測する。なお、予測対象となるタイミングは、複数であっても良い。

（６４）通信部１１１は、検索で取得された保有車情報及び予測された保有車の査定価格の情報を、端末１０Ａに送信する（ステップＳ６４）。

以上の処理によって、保有者は、車検証のＱＲコードを撮影することにより、保有車の詳細な情報と、その査定価格を知ることができる。したがって、ユーザへのサービス（例えば自動車購入後のアフターサービス）の質を向上させるほか、保有者に買い替えの動機付けを与えることができる。

なお、（６１）において、保有者は、自車の現在の走行距離の情報を、車検証のデータと併せて管理サーバ１１に送信しても良い。例えば、記憶部１１３には、保有者毎に、その自動車（保有車）の走行距離のデータが、各データの更新タイミングとともに格納されていても良い。解析部１１２Ａは、定期的に記憶部１１３に格納された自動車の走行距離のデータを確認し、所定期間以上、走行距離のデータに更新がない自動車がある場合に、その自動車の保有者の端末を宛先として、走行距離情報の送信を促す通知を送信する。この通知は、実施の形態２で記載された更新情報の送信を促す通知と併せてなされても良い。また、通知を送信する判定の閾値となる所定期間は、記憶部１１３に格納されており、管理者が更新可能であっても良い。

この場合、解析部１１２Ａは、ステップＳ６３における査定価格の予測において、現在の走行距離の情報を用いることができる。例えば、次回の車検のタイミングにおける査定価格を予測する場合には、その時点での保有車の走行距離を、現在の走行距離の情報を用いて算出することによって予測し、その予測された走行距離を用いて保有車の査定価格を予測する。これにより、査定価格をより精度良く予測することができる。

また、（６２）において、解析部１１２Ａが走行距離のデータを受信したことを認識すると、そのデータを送信した保有者に対して所定のサービスポイントを付与する。このサービスポイントの情報は、記憶部１１３における保有者のデータとして記録されるほか、端末１０Ａに対しても送信される。サービスポイントは、これ以外の処理によっても付与される。解析部１１２Ａは、サービスポイントが一定の値を超えると、クーポン券を発行する処理を実行する。クーポン券は、電子データとして端末１０Ａに送信されても良いし、管理サーバ１１に接続されたプリンタから紙に印刷されても良い。クーポン券は、例えば保有車に関するサービス（例えば、オプション取り付けや修理、洗車、購入対象車の購入）への費用支払いに用いられるものでも良いし、その他、仲介会社又はその系列会社における商品又は役務への費用支払いに用いられるものでも良い。ただし、クーポン券のデータは、保有者の個人情報と関連付けられて記憶部１１３に格納されても良い。また、走行距離のデータだけでなく、保有車に関するその他の情報を更新した場合でも、同様のサービスポイントの付与処理が可能である。これにより、保有者に対して情報更新を実行してもらう動機付けを与えるほか、管理サーバ１１側でより正確な保有車の情報を把握することができ、サービスの向上につなげることができる。なお、サービスポイントを付与する処理及び付与するポイント数の情報は、記憶部１１３に記憶されており、解析部１１２Ａがサービスポイントの付与においてこの情報を参照する。

また、実施の形態１に記載した通り、販売金額ＤＢ１３に代えて、予め機械学習がなされたモデルが用いられても良い。この場合には、保有車情報をモデルへの入力データとして入力させることで、検索部１１２Ｂは、出力データとして出力された中古車の情報を取得する。この入力される保有車情報には、走行距離のデータが含まれていても良い。

実施の形態７（出品希望情報の取得）
図１８は、実施の形態７に係る売買支援システムを示す概略図である。図１８の概略を説明すると、売買支援システムＳ７は、端末１０Ａ、１０Ｂ、管理サーバ１１、保有車ＤＢ２２及び登録車ＤＢ７１を少なくとも備える、出品希望情報の取得を可能とするシステムである。

端末１０Ａは、仲介会社から自動車を購入した保有者か、又は、ユーザ登録処理がなされた保有者の端末である。ユーザ登録処理については、（１Ａ）で説明した通りである。

保有車ＤＢ２２には、保有車の詳細情報を含む保有車情報が、各保有車の保有者が有する端末１０Ａの接続先（宛先）情報と関連付けられて格納されている。このデータは、例えば上述のユーザ登録処理がなされる際に、保有車ＤＢ２２に格納される。保有車ＤＢ２２は、仲介会社の顧客が保有する自動車のＤＢである。また、登録車ＤＢ７１には、ユーザ登録処理がなされた登録車の詳細情報を含む登録車情報が、各登録車の登録ユーザ（保有者）が有する端末１０Ａの接続先情報と関連付けられて格納されている。なお、この登録車には、実施の形態４で示したお試し出品中の自動車も含まれており、登録車情報には、登録車がお試し出品中か否かを示すフラグが含まれていても良い。

管理サーバ１１のサイト管理部１１２Ｃは、端末１０Ａ、１０Ｂがアクセス可能なウェブサイトの１つとして、出品希望掲示板を管理する。端末１０Ａ、１０Ｂは、出品希望掲示板に任意の内容のコメントを書き込むことができる。解析部１１２Ａは、通信部１１１を介して、この書き込まれた情報を取得し、解析する。書き込まれた情報が、買い手からの出品希望車の詳細情報である場合には、検索部１１２Ｂが、保有車ＤＢ２２及び登録車７１ＤＢ内に格納された自動車の情報の中から、出品希望車の詳細情報に対応する自動車を検索する処理をするように決定する。検索部１１２Ｂは、その決定に応じて、通信部１１１を介し、保有車ＤＢ２２及び登録車７１ＤＢ内から出品希望車の詳細情報に対応する保有車情報及び登録車情報を検索する。そして、対応する保有車情報及び登録車情報に関連付けられた端末１０Ａの接続先情報を取得する。解析部１１２Ａは、取得した端末１０Ａの接続先に対して、出品を促す通知を送信するよう、通信部１１１を制御する。

それ以外の売買支援システムＳ７の各構成要素が実行する処理については、以前の実施の形態で説明した通りである。また、図１８内の矢印は、送受信される情報を時系列順に示したものであり、以下、この詳細について説明する。

図１８及び図１９を用いて、売買支援システムＳ７内でなされる通信及び処理の詳細を説明する。図１９は、管理サーバ１１が実行する処理の例を示すフローチャートである。なお、以下の明細書中の符号（７１）～（７５）は、図１８内の（７１）～（７５）と対応した説明を示す。

（７１）まず、買い手は、サイト管理部１１２Ｃが管理する出品希望掲示板に対して、出品を希望する自動車の詳細情報を書き込む。これにより、通信部１１１は、端末１０Ｂから出品希望車の詳細情報を受信する（ステップＳ７１）。解析部１１２Ａは、この出品希望車の詳細情報を解析する。そして、検索部１１２Ｂが、保有車ＤＢ２２及び登録車７１ＤＢ内に格納された自動車の情報の中から、出品希望車の詳細情報に対応（該当）する自動車を検索する処理をするように決定する。

（７２）検索部１１２Ｂは、その決定に応じて、通信部１１１を介し、保有車ＤＢ２２内から、出品希望車の詳細情報に対応する保有車情報を検索する（ステップＳ７２）。

（７２’）また、検索部１１２Ｂは、通信部１１１を介し、登録車ＤＢ２２内から、出品希望車の詳細情報に対応する登録車情報を検索する。

（７３）通信部１１１は、（７２）での検索によって特定した保有車情報に関連付けられた端末１０Ａの接続先情報を取得する（ステップＳ７３）。

（７３’）また、通信部１１１は、（７２’）での検索によって特定した登録車情報に関連付けられた端末１０Ａの接続先情報を取得する。

（７４）解析部１１２Ａは、（７３）及び（７３’）で取得した端末１０Ａの接続先に対して、出品を促す通知を送信するよう、通信部１１１を制御する。このとき、解析部１１２Ａは、保有車情報に関連付けられた端末１０Ａ、及び、お試し出品中でない登録車の登録車情報に関連付けられた端末１０Ａに対しては、本出品及びお試し出品の少なくともいずれかを促す通知を送信するように制御する。例えば、解析部１１２Ａは、通知内容に、保有者が保有する自動車の購入を希望するユーザがいるため、本出品の検討を促すこと、また本出品の前に自分の保有車の需要をさらに確認したい場合にはお試し出品も可能であること、を含めても良い。これに対して、お試し出品中である登録車の登録車情報に関連付けられた端末１０Ａに対しては、解析部１１２Ａは、本出品を促す通知を送信するように制御する。通信部１１１は、解析部１１２Ａの制御に応じて、出品を促す通知を端末１０Ａの接続先に送信する（ステップＳ７４）。

（７５）端末１０Ａのユーザは、送信された通知に基づいて、自身の保有車のお試し出品又は本出品を決定する。そして、端末１０Ａにより、保有車のお試し出品又は本出品の要求を送信する。通信部１１１は、端末１０Ａから送信された要求を受信する。そして、サイト管理部１１２Ｃは、要求があった保有車について、お試し出品又は本出品の処理を行う（ステップＳ７５）。この処理については、実施の形態４の（４１）～（４４）又は（４７）に記載の通りである。

以上の処理によって、保有者は、自身の自動車に需要があることを理解することができるため、お試し出品又は本出品をする動機付けが生じ、取引の活性化につなげることができる。

実施の形態８（チャットサービス）
図２０は、実施の形態８に係る売買支援システムを示す概略図である。図２０の概略を説明すると、売買支援システムＳ８は、端末１０、管理サーバ１１及び端末８０を少なくとも備える。この実施の形態では、管理サーバ１１が、端末１０（自動車の保有者又は買い手の端末）と、端末１０のユーザに対応するチャットサービスの担当者の端末８０とを直接接続するチャットサービスを提供する例について説明する。図２０における矢印は、チャットに関する情報の送受信を示している。端末８０は、スマートフォン、タブレット端末、ＰＣ等の任意の情報処理装置で構成される。

管理サーバ１１の記憶部１１３には、チャットサービスに登録されたユーザの端末情報と、その端末情報に紐づけられたチャットサービスの担当者の端末情報が格納されている。チャットサービスへの登録は、上述のユーザ登録処理によってなされても良い。チャットサービスの担当者は、例えば、ユーザを担当する仲介会社の営業スタッフである。ユーザの端末情報、担当者の端末情報は、それぞれ、各端末の接続先情報を含む。ここで、ユーザ、担当者について、それぞれ複数の端末の情報が紐づけられて記憶部１１３に格納されていても良い。さらに、記憶部１１３には、チャットサービスの画面（チャット画面）情報と、端末１０及び端末８０からチャットサービスを介して送信された情報が格納されている。チャットサービスは、リアルタイムで会話がなされるチャット形式のサービスであれば、任意の種類のサービスを適用することができる。

サイト管理部１１２Ｃは、記憶部１１３に格納された上述のユーザの端末情報及び担当者の端末情報に基づいて、ユーザの端末１０と担当者の端末８０とを接続するチャットサービスを提供する提供部として機能する。詳細には、サイト管理部１１２Ｃは、記憶部１１３に格納された情報に基づいて、チャット画面を端末１０及び端末８０に表示させる。そして、端末１０及び端末８０のいずれかから書き込み等がなされた場合には、通信部１１１から取得したその書き込み内容をチャット画面に反映させ、反映された画面を端末１０及び端末８０に表示させる。

提供されるチャットサービスは、端末１０と端末８０間でなされるサービスであり、他の端末から両者のチャットの内容を閲覧することはできない。また、このチャットサービスにより、端末１０、８０の双方から、文字である書き込みのほか、画像、ＰＤＦ、クーポン券等の各種の電子データを送信することが可能である。

例えば、担当者は端末８０を操作して、ユーザに対する挨拶、ユーザの保有車の調子伺い、ユーザに関連するイベントのお祝い、新車の販売や新しいサービスに関する営業提案、電話又は対面での面談に関する日程予約、サイト管理部１１２Ｃが管理するウェブサイトの操作サポートといった内容を書き込むことができる。ユーザに関連するイベントは、例えば、ユーザの誕生日といったユーザのイベントや、子供の入学等といったユーザの家族のイベントである。ウェブサイトの操作サポートは、例えば、上述に示した本出品やお試し出品の方法や、コメント対応の方法に関するサポートである。さらに、所定のサービスに関するＵＲＬ（Uniform Resource Locator）を入力することもできる。

ユーザは、端末１０を操作して、上述の内容に関する返信を書き込むことができるほか、入力されたＵＲＬを操作することにより、所定のサービスのホームページを閲覧することができる。また、ユーザは、保有車の状態を担当者に示すため、保有車の画像を端末１０の撮像部１０４で撮影し、その画像をチャットにアップロードすることもできる。担当者は、その画像をチャット画面上で閲覧し、保有車に傷等がある場合には、実施の形態５に示した修理金額の見積もりサービスを受けるように提案することができる。

他の例として、担当者は端末８０を操作して上述の整備・点検履歴ＤＢ１２にアクセスすることで、ユーザの保有車の整備・点検履歴に関する情報を参照する。これにより、端末８０は、ユーザの保有車の車検日、法定点検日、自動車保険の満期日といったユーザの保有車に関する情報を取得する。また、担当者の操作により、端末８０が、管理サーバ１１の記憶部１１３に格納された保有者の個人情報を参照することで、実施の形態６に記載した保有者の所有するサービスポイントやクーポン券のデータを取得することもできる。さらに、担当者の操作により、個人情報を参照することで、端末８０が、上述の実施の形態に記載した販売希望金額、概算見積もりといった所定事項が記入済の電子ファイルや、販売に関するパンフレット等、これ以外の電子ファイルを取得することもできる。担当者が端末８０の画面上でこれらの情報をチャットにアップロードすることにより、ユーザは端末１０からその情報を容易に確認することができる。

端末１０、８０には、チャット用のアプリケーション（以降、アプリと記載）が導入されており、このアプリの機能により、チャットに新たな内容が記載された場合には、チャットが更新されたことを、プッシュ通知によって端末１０、８０の表示部上に示す。これにより、ユーザ、担当者とも、相手から新たにコミュニケーションがなされたことを確認することができる。

以上に示したように、管理サーバ１１が提供するチャットサービスでは、ユーザとその担当者とを直接つなぐことで、両者のコミュニケーションをよりスムーズに行うことができる。例えば、ユーザは、自身の保有車に関する各種情報を、担当者からの連絡によって、普段から容易に確認することができる。また、電話や郵便といった方法と比較して、ユーザのコミュニケーションに関するストレスを減らすこともできる。

また、担当者にとっては、顧客とのコミュニケーションの機会を増加させることができるため、アフターサービスの向上や、営業の機会の増大につなげることができる。そのため、取引を活性化させることができる。さらに、管理サーバ１１は、チャットでのコミュニケーションの情報を把握できるため、この情報をビッグデータとして、後述の営業方法の改善提案に活かすことができる。

さらに、担当者にとっては、顧客のデータ管理を容易にすることもできる。例えば、担当者が別の新しい担当者に引き継いだ場合でも、記憶部１１３に格納された上述の担当者の端末情報を更新することにより、新しい担当者は、自身の端末を操作することで、以前の担当者のチャット上のコミュニケーションを容易に確認することができる。

なお、上述のユーザの保有車に関する情報や、保有者の個人情報については、担当者ではなく、管理サーバ１１が自動的に取得し、チャット画面にアップロードしても良い。詳細には、管理サーバ１１の検索部１１２Ｂが、定期的に、整備・点検履歴ＤＢ１２にアクセスしたり、又は記憶部１１３に格納された保有者の個人情報を参照したりすることで、上述の情報を取得する。そして、サイト管理部１１２Ｃがこれらの情報をチャットにアップロードする。管理サーバ１１は、記憶部１１３に格納されたユーザの販売希望金額等の電子ファイルについても、チャットにアップロードすることができる。

さらに、管理サーバ１１は、実施の形態１～７に記載した、端末１０と管理サーバ１１との自動車の売買に関する通信を、サイト管理部１１２Ｃが提供するチャットサービス上で実行することができる。例えば、販売希望車の販売希望車情報及び販売希望金額情報をユーザがチャットで入力することで端末１０Ａを用いて管理サーバ１１に送信すると、解析部１１２Ａはその情報を解析することで、通信部１１１を介して、管理サーバ１１と連動したＡＩサービスに対し、ＡＩによる販売希望車の査定を要求しても良い。ＡＩサービスは、査定を実行し、査定金額の情報を管理サーバ１１に返送する。解析部１１２Ａは、その情報を解析して、サイト管理部１１２Ｃに対し、その査定金額の情報をチャットに反映させるように制御する。これにより、実施の形態１の（１１’）に示したＡＩ査定による査定金額の情報を、ユーザは取得することができる。

また、管理サーバ１１は、実施の形態２に記載した（２１）及び（２６）の処理を、チャットサービス上で実行することもできる。まず、（２１）において、自動車の保有者は、端末１０Ａを用いて更新情報をチャットにアップロードする。（２２）～（２５）の処理は、実施の形態２に記載の通りである。そして、（２６）において、通信部１１１は、買い替え提案の情報をチャットにアップロードすることで、端末１０Ａに送信する。別の例として、実施の形態６に記載した（６１）及び（６４）の処理が、チャットサービス上で実行されても良い。まず、（６１）において、自動車の保有者は、車検証のＱＲコードを端末１０で撮影し、それをチャットにアップロードする。（６２）～（６３’）の処理は、実施の形態６に記載の通りである。そして、（６４）において、通信部１１１は、検索で取得された保有車情報及び予測された保有車の査定価格の情報を、チャットにアップロードする。以上により、ユーザは、各種情報を手軽に把握することができる。

また、サイト管理部１１２Ｃが提供するチャットサービスには、良く使われる機能に関するショートカットキーが含まれていても良い。良く使われる機能は、例えば、下取り査定依頼、来店日程調整といったものである。

それ以外の売買支援システムＳ８の各構成要素が実行する処理については、以前の実施の形態で説明した通りである。なお、図３に示した管理サーバ１１ではなく、図８に示した管理サーバ２１でも、以上に示した処理は実行可能である。

実施の形態９（営業、広告及び販売促進方法の改善提案）
（９Ａ）
図２１は、実施の形態９に係る売買支援システムを示す概略図である。図２１の概略を説明すると、売買支援システムＳ９は、端末１０、端末８０、管理サーバ９１及び購買ＤＢ９２を少なくとも備える。端末１０は仲介会社の顧客Ｃの端末であり、端末８０は顧客Ｃの営業担当者Ｄの端末である。ここで、顧客Ｃは、上述のユーザ登録がなされたユーザであっても良いし、以前に仲介会社を介して自動車を購入したユーザであっても良い。営業担当者Ｄは、仲介会社に所属する社員である。

管理サーバ９１は、端末１０、端末８０及び購買ＤＢ９２とそれぞれ接続されており、仲介会社が保有するサーバである。購買ＤＢ９２は、仲介会社のこれまでの自動車（販売対象物品）に関する購買のデータが格納されている。また、図２１における端末１０と管理サーバ９１間の矢印、及び端末８０と管理サーバ９１間の矢印は、図２０と同様、チャットに関する情報の送受信を示している。そして、図２１における管理サーバ９１と購買ＤＢ９２間の矢印は、後述の通り、管理サーバ９１からの購買ＤＢ９２へのアクセスと、管理サーバ９１が購買ＤＢ９２から購買データを取得することを示す。

この実施の形態では、仲介会社の営業、広告及び販売促進方法の改善提案について説明する。以下、各装置の詳細な構成について説明する。

図２２は、管理サーバ９１の構成を示すブロック図である。管理サーバ９１は、通信部１１１、制御部９１２及び記憶部１１３を備えるが、入力部や表示部をさらに備えても良い。管理サーバ９１は、１台又は複数台の任意の情報処理装置で構成される。

通信部９１１（トランシーバ）は、端末１０、端末８０及び購買ＤＢ９２と情報を送受信する送信部及び受信部として機能する。例えば、端末１０とは、ウェブサイト及びチャットサービスを介した情報の送受信が可能である。

制御部９１２は、記憶部９１３からソフトウェア（コンピュータプログラム）を読み出して実行することで、解析部９１２Ａ、検索部９１２Ｂ、サイト管理部９１２Ｃ、モデル生成部９１２Ｄ及び提案生成部９１２Ｅ等の機能を実現する。以下、これらの各機能について説明する。

解析部９１２Ａ及び検索部９１２Ｂの実行する処理は、解析部１１２Ａ及び検索部１１２Ｂと同様であるため、説明を省略する。サイト管理部９１２Ｃは、サイト管理部１１２Ｃと同様に、端末１０がアクセス可能なウェブサイトを管理するほか、実施の形態８で示した通り、端末１０と端末８０とを接続するチャットサービスを提供する提供部としても機能する。

モデル生成部９１２Ｄは、過去の顧客とその顧客の営業担当者とのチャット履歴（コミュニケーション履歴）と、その顧客の自動車の購入履歴を少なくとも有するトレーニングデータを用いて、機械学習により、自動車の購入に関連するチャットでのコミュニケーションパターンを特定するコミュニケーションモデルを生成する。この過去の顧客は、ユーザ登録がなされたユーザであっても良いし、以前に仲介会社を介して自動車を購入したユーザであっても良い。自動車の購入履歴は、特定の自動車に対する顧客の購入の有無（契約の成否）を示す。モデル生成部９１２Ｄは、複数の過去の顧客に関する、このようなチャット履歴と購入履歴に基づいて、顧客と営業担当者とのどのようなチャットの会話パターンが、購入の成否を決定付けたかを特定するコミュニケーションモデルを生成する。

また、モデル生成部９１２Ｄは、モデル生成に際して、公知の様々な機械学習の技術を適用することができる。例えば、モデル生成部９１２Ｄは、チャット履歴の解析のため、ディープラーニング等による自然言語解析を実行しても良い。このコミュニケーションモデルにより、例えば、過去の統計上、かなり高い所定の確率以上で自動車の購入契約が成立した会話パターン（好ましい会話パターン）、あるいは、かなり高い所定の確率以上で自動車の購入契約が成立しなかった会話パターン（好ましくない会話パターン）の少なくともいずれかが特定できる。

コミュニケーションパターンは、例えば、チャットの回数、１回の会話中での所定のキーワードの頻度、１文の長さ、といった数量化されるものが対象とされても良い。あるいは、モデル生成部９１２Ｄは、自然言語解析を用いることで、会話の流れに関してのコミュニケーションパターンを生成しても良い。この場合、例えば顧客のどのような発言に対してどう応答するのが好ましい、又は好ましくないか、ということがより明確になる。

提案生成部９１２Ｅは、コミュニケーションモデルと、現在の顧客Ｃ（対象ユーザ）と営業担当者Ｄとのこれまでのチャット履歴を用いることにより、自動車の購入に関連するコミュニケーションについて、営業担当者Ｄへの提案を生成する。

例えば、提案生成部９１２Ｅは、これまでのチャット履歴が、コミュニケーションモデルが特定する好ましい会話パターンに該当しているか否かを判定する。一例として、好ましい会話パターンが、１文当たりの文字数が３０文字以内であり、かつチャットの会話の間隔（返信の間隔）が３分以内であるとする。提案生成部９１２Ｅは、顧客Ｃと営業担当者Ｄとのこれまでのチャットの会話を解析して、この会話パターンに該当していないことを判定した場合には、営業担当者Ｄに対し、「１文をもう少し短くし、会話のテンポを上げていきましょう」という提案を生成する。提案生成部９１２Ｅは、通信部９１１を介して端末８０にこの提案を送信する。端末８０には、支援ツールとしてのアプリが導入されており、このアプリによって、端末８０の表示部に、チャット画面とは別の箇所にこの提案が表示される。それにより、営業担当者Ｄは、チャットで好ましい会話パターンを展開することができるため、自動車の契約を得る可能性を高めることができる。

なお、提案生成部９１２Ｅは、好ましい会話パターンに代えて、又はそれに加えて、好ましくない会話パターンを用いても、同様に提案を生成することができる。また、提案は、「文章を具体的に書きましょう」や、「この点を会話で触れましょう」といった、他のものであっても良いことは言うまでもない。

図２１に戻り、説明を続ける。購買ＤＢ９２は、仲介会社の販売対象物品である自動車に関する過去の購買データ（ビッグデータ）が、営業担当者により、顧客毎のログとして格納されている。具体的には、顧客の個人情報、顧客の自動車の購入に関連する行動履歴、顧客と、その顧客の営業担当者とのコミュニケーション履歴、顧客の自動車の購入履歴及び自動車の販売促進に関する履歴が、購買データとして格納されている。

顧客の個人情報は、顧客の氏名、保有車又は購入車の車体番号のほか、保有車又は購入車の種類、顧客の性別、年齢、住所、家族構成等、顧客の属性に関する情報を含む。顧客の自動車の購入に関連する行動履歴は、顧客が仲介会社に来店したときの行動履歴、及び、サイト管理部１１２Ｃが管理する仲介会社のウェブサイトに顧客がアクセスしたときの行動履歴を含む。前者の例は、販売中の自動車の見学や試乗といった行動履歴である。後者の例は、ウェブサイトの閲覧履歴（どのような自動車を閲覧したか）や、特定の自動車に対する「お気に入り」の登録情報、販売希望車に関するコメント履歴や、出品希望掲示板に書き込んだコメント履歴といったものでも良い。これらのコメントの説明については、上述の実施の形態で示した通りである。

コミュニケーション履歴には、顧客と、その顧客の営業担当者とのチャット履歴のほか、両者の間でなされたメール、両者の間での電話や体面による会話といったコミュニケーションの内容が含まれている。顧客の自動車の購入履歴は、特定の自動車に対する顧客の購入の有無を示す。自動車の販売促進に関する履歴は、例えば仲介会社が自動車の販売を促進するために行った各種キャンペーン、クーポン券等の特典といった情報の履歴を含む。

それ以外の売買支援システムＳ９の各構成要素が実行する処理については、以前の実施の形態で説明した通りである。

図２３を用いて、売買支援システムＳ９内で管理サーバ９１が実行する処理を説明する。まず、モデル生成部９１２Ｄは、通信部１１１を介して購買ＤＢ９２にアクセスすることにより、過去の顧客のチャット履歴と、その顧客の購入履歴を、少なくとも取得する。そして、取得した情報をトレーニングデータとして用いて、上述の通り、コミュニケーションモデルを生成する（ステップＳ９１）。

サイト管理部１１２Ｃがチャットサービスを提供し、顧客Ｃと営業担当者Ｄとがそれぞれの端末を操作してチャットをしているときに、提案生成部９１２Ｅは、ステップＳ９１で生成されたコミュニケーションモデルと、顧客Ｃと営業担当者Ｄとのこれまでのチャット履歴を用いることにより、自動車の購入に関連するコミュニケーションについて、営業担当者Ｄへの提案を生成する（ステップＳ９２）。以上により、営業担当者Ｄは、自動車の購入に関連する会話をチャットで展開することができるため、自動車の販売業績を向上させることができる。これにより、取引を活性化させることもできる。

なお、モデル生成部９１２Ｄは、トレーニングデータとして、購買ＤＢ９２に格納された、チャット履歴以外のメール、会話といったコミュニケーション履歴を用いても良い。その場合、モデル生成部９１２Ｄは、自動車の購入に関連するメール、会話でのコミュニケーションパターンを特定するコミュニケーションモデルを生成することができる。提案生成部９１２Ｅは、そのコミュニケーションモデルと、顧客Ｃと営業担当者Ｄとのこれまでのメール、会話といったコミュニケーション履歴を用いることにより、顧客Ｃが自動車を購入する可能性がより高まるメールや会話の内容について、営業担当者Ｄへの提案を生成する。営業担当者Ｄは、その提案を用いて、自動車の販売業績を向上させることができる。なお、顧客Ｃと営業担当者Ｄとのコミュニケーション履歴は、例えば購買ＤＢ９２に格納されており、提案生成部９１２Ｅが購買ＤＢ９２にアクセスすることで取得することができる。

（９Ｂ）
（９Ａ）に示したモデル生成部９１２Ｄは、トレーニングデータとして、購買ＤＢ９２に格納されたコミュニケーション履歴や顧客の自動車の購入履歴だけでなく、顧客の個人情報、顧客の自動車の購入に関連する行動履歴、及び自動車の販売促進に関する履歴の少なくともいずれかをさらに用いても良い。提案生成部９１２Ｅは、モデル生成部９１２Ｄがトレーニングデータとして用いたデータに対応する、顧客Ｃに関するデータを用いる。すなわち、提案生成部９１２Ｅは、顧客Ｃの個人情報と、自動車の購入に関連する顧客Ｃの行動履歴と、自動車の顧客Ｃに対する販売促進に関する履歴の少なくともいずれかをさらに用いることにより、上述の提案を生成する。なお、提案生成部９１２Ｅが用いるこれらの情報は、例えば購買ＤＢ９２に格納されており、提案生成部９１２Ｅが購買ＤＢ９２にアクセスすることで取得することができる。これにより、営業担当者Ｃは、顧客Ｄの属性又は行動により適したコミュニケーションを取ることができる。

また、提案生成部９１２Ｅは、顧客Ｃに対してコミュニケーションを取るタイミング、及び顧客Ｃに対して購入を勧める自動車、及び自動車の販売促進の手法の少なくともいずれかに関する提案を生成することができる。

例えば、提案生成部９１２Ｅは、顧客Ｃの個人情報として、以前の車を買って数年が経過したこと、子供が近いうちに小学生になったことを取得する。また、顧客Ｃの行動履歴として、サイト管理部１１２Ｃが管理するウェブサイトに顧客Ｃが最近アクセスするようになったことも取得する。このときに、提案生成部９１２Ｅは、顧客の個人情報及び行動履歴に基づいて生成されたコミュニケーションモデルを用いて、顧客Ｃがそろそろ自動車を買い替えようとしていること、また顧客Ｃが家族用の比較的大きなサイズの自動車を所望していることを推定する。提案生成部９１２Ｅは、その推定に基づいて、営業担当者Ｄに対し、顧客Ｃとコミュニケーションを取ることが望ましく、また比較的大きなサイズの自動車の購入を勧めることを、提案内容として、端末８０に送信する。また、販売促進の手法の情報にも基づいてコミュニケーションモデルが生成された場合には、提案生成部９１２Ｅは、クーポン券、割引等の販売促進の手法を顧客Ｃに対して打ち出すことも、提案内容に含められる。このようにして、営業担当者Ｄは、自動車を販売するために、より効果的な手法を取ることができる。

他の例として、提案生成部９１２Ｅは、コミュニケーションモデルを用いて、最近連絡がない顧客に対して、放置すると将来の購買の可能性が下がることを推定することにより、営業担当者Ｄに対し、その顧客とコミュニケーション（例えば時候の挨拶）を取ることを提案しても良い。

なお、（９Ａ）、（９Ｂ）において、コミュニケーションモデルは、顧客の個人情報における属性、購入車の属性の少なくともいずれかに基づいて分けられて生成しても良い。例えば、性別及び年齢に応じて複数の属性が定義された上で、モデル生成部９１２Ｄは、過去の顧客をその属性毎に分け、その属性毎に上述の情報に基づいてコミュニケーションモデルを生成する。これにより、コミュニケーションモデルは複数生成される。そして、提案生成部９１２Ｅは、顧客Ｃの個人情報に基づいて、複数のコミュニケーションモデルの中から、顧客Ｃの属性と合致したコミュニケーションモデルを１つ選択する。そして、選択されたコミュニケーションモデルを用いて、上述の処理を実行する。これにより、提案生成部９１２Ｅは、顧客の属性に応じた、さらに精度の高い提案を生成することができる。

（９Ｃ）
また、モデル生成部９１２Ｄは、自動車に関する、広告及び販売促進の少なくともいずれかの履歴、並びに自動車の販売履歴を有するトレーニングデータを用いて、自動車の販売に関連する広告及び販売促進の少なくともいずれかの手法を特定する販売モデルを生成しても良い。広告は、端末１０に上述のチャットのプッシュ通知として表示されるものでも良いし、テレビコマーシャル等として表示されるものでも良い。広告の履歴は、期間毎の広告の内容を示す情報である。広告及び販売促進の履歴は、購買ＤＢ９２に格納されており、モデル生成部９１２Ｄはそれを取得して、自然言語解析等、公知の機械学習の手法を用いて販売モデルを生成する。この販売モデルにより、例えば、過去の統計上、かなり高い所定の確率以上で自動車の購入契約が向上した広告又は販売促進の手法（好ましい広告又は販売促進の手法）、あるいは、かなり高い所定の確率以上で自動車の購入契約が低下した広告又は販売促進の手法（好ましくない広告又は販売促進の手法）の少なくともいずれかが特定できる。

提案生成部９１２Ｅは、モデル生成部９１２Ｄが生成した販売モデルを用いて、自動車の販売に関連する、広告及び販売促進の少なくともいずれかについての提案を生成する。例えば、提案生成部９１２Ｅは、現在検討されている広告のキャッチコピーが、販売モデルが特定する好ましい広告に該当しているか否かを判定する。一例として、好ましい広告のキャッチコピーの文字数が１５文字以内である一方、現在検討されている広告のキャッチコピーが２０文字であることを判定した場合には、提案生成部９１２Ｅは、「キャッチコピーをもう少し短くしましょう」という提案を生成する。提案生成部９１２Ｅは、通信部９１１を介して端末８０にこの提案を送信し、端末８０はこの提案を表示部に表示させる。

以上の処理により、自動車の広告又は販売促進の担当者は、より自動車の販売に関連する広告又は販売促進の手法を取ることができるため、自動車の販売業績を向上させることができる。

なお、（９Ｃ）において、販売モデルは、顧客の個人情報における属性、購入車の属性の少なくともいずれかに基づいて分けられて生成しても良い。例えば、性別及び年齢に応じて複数の属性が定義された上で、モデル生成部９１２Ｄは、広告及び販売促進の少なくともいずれかの履歴と、自動車の販売履歴を、それぞれ属性毎に分ける。そして、それぞれの属性に関して、販売モデルを生成する。そして、提案生成部９１２Ｅは、今回対象とする顧客の属性に基づいて、複数の販売モデルの中から、顧客の属性と合致した販売モデルを１つ選択する。そして、選択された販売モデルを用いて、上述の処理を実行する。これにより、提案生成部９１２Ｅは、顧客の属性に応じた、さらに精度の高い広告又は販売促進の提案を生成することができる。

（９Ａ）～（９Ｃ）は、適宜組み合わせることができる。なお、（９Ａ）～（９Ｃ）において、販売対象となるのは自動車に限られず、自動車関連の物品であっても良いし、自動車の保険や点検サービスといった、自動車関連の各種サービスであっても良い。また、モデル生成部９１２Ｄが生成するモデル及び提案生成部９１２Ｅが生成する提案は、物品、サービスの両方を対象とするものであっても良い。

なお、本発明は上記実施の形態１～９に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。例えば、端末１０Ａ、１０Ｂは、保有者や買い手が有する端末ではなく、少なくともいずれかが、仲介会社等の店舗に設けられた端末であっても良い。また、実施の形態１～７、９において検索に用いられた各種のＤＢは、管理サーバの外部ではなく、内部に設けられた記憶部として構成されても良い。

実施の形態１～９では、物品として、自動車の売買がなされる例について説明したが、本発明は、自動車に限られず、任意の有体物（例えば不動産、時計、洋服、装飾品等）の売買においても適用できる。

図２４は、以上に示した各実施の形態の処理が実行される情報処理装置（信号処理装置）のハードウェア構成例を示すブロック図である。図２４を参照すると、この情報処理装置Ｉ０は、信号処理回路Ｉ１、プロセッサＩ２及びメモリＩ３を含む。

信号処理回路Ｉ１は、プロセッサＩ２の制御に応じて、信号を処理するための回路である。なお、信号処理回路Ｉ１は、送信装置から信号を受信する通信回路を含んでいても良い。

プロセッサＩ２は、メモリＩ３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態において説明された装置の処理を行う。プロセッサ９２の一例として、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＤＳＰ（Demand-Side Platform）、ＡＳＩＣ（Application Specific Integrated Circuit）のうち一つを用いてもよいし、そのうちの複数を並列で用いてもよい。

メモリＩ３は、揮発性メモリや不揮発性メモリ、またはそれらの組み合わせで構成される。メモリＩ３は、１個に限られず、複数設けられてもよい。なお、揮発性メモリは、例えば、ＤＲＡＭ (Dynamic Random Access Memory)、ＳＲＡＭ (Static Random Access Memory)等のＲＡＭ (Random Access Memory)であってもよい。不揮発性メモリは、例えば、ＰＲＯＭ (Programmable Random Only Memory)、ＥＰＲＯＭ (Erasable Programmable Read Only Memory) 等のＲＯＭ (Random Only Memory)、フラッシュメモリや、ＳＳＤ（Solid State Drive）であってもよい。

メモリＩ３は、１以上の命令を格納するために使用される。ここで、１以上の命令は、ソフトウェアモジュール群としてメモリＩ３に格納される。プロセッサＩ２は、これらのソフトウェアモジュール群をメモリＩ３から読み出して実行することで、上述の実施形態において説明された処理を行うことができる。

なお、メモリＩ３は、プロセッサＩ２の外部に設けられるものに加えて、プロセッサＩ２に内蔵されているものを含んでもよい。また、メモリＩ３は、プロセッサＩ２を構成するプロセッサから離れて配置されたストレージを含んでもよい。この場合、プロセッサＩ２は、Ｉ/Ｏ（Input / Output）インタフェースを介してメモリＩ３にアクセスすることができる。

以上に説明したように、上述の実施形態における各装置が有する１又は複数のプロセッサは、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。この処理により、各実施の形態に記載された管理サーバ又は端末の処理が実現できる。

プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、光学記憶媒体（例えばＤＶＤ（Digital Versatile Disc）、ＣＤ（Compact Disc）といった光ディスク）、半導体メモリ（例えば、マスクＲＯＭ（Read Only Memory）、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

以上、実施の形態を参照して本発明を説明したが、本発明は上記によって限定されるものではない。本発明の構成や詳細には、開示のスコープ内で当業者が理解し得る様々な変更をすることができる。

１０ 端末
１０１ 通信部
１０２ 表示部
１０３ 入力部
１０４ 撮像部
１０５ 制御部
１０６ 記憶部
１１ 管理サーバ
１１１ 通信部
１１２ 制御部
１１２Ａ 解析部 １１２Ｂ 検索部 １１２Ｃ サイト管理部
１１３ 記憶部
１２ 整備・点検履歴ＤＢ
１３ 販売金額ＤＢ
２１ 管理サーバ
２１１ 通信部
２１２ 制御部
２１２Ａ 解析部 ２１２Ｂ 検索部 ２１２Ｃ サイト管理部
２１２Ｄ 提案生成部
２１３ 記憶部
２２ 保有車ＤＢ
２３ 購入対象車ＤＢ
３１ 関連情報ＤＢ
５１ 傷情報ＤＢ
９１ 管理サーバ
９１１ 通信部
９１２ 制御部
９１２Ａ 解析部 ９１２Ｂ 検索部 ９１２Ｃ サイト管理部
９１２Ｄ モデル生成部 ９１２Ｅ 提案生成部
９１３ 記憶部
９２ 購買ＤＢ

Claims (15)

1. 登録されたユーザの端末情報と、前記端末情報に紐づけられたチャットサービスの担当者の端末情報と、を記憶する記憶部と、
   前記記憶部に記憶された前記ユーザの端末情報及び前記担当者の端末情報に基づいて、前記ユーザの端末と前記担当者の端末とを接続するチャットサービスを提供する提供部と、を備える、
   売買支援装置。
2. ユーザと前記ユーザの担当者とのコミュニケーション履歴と、前記ユーザの物品及びサービスの少なくともいずれかの購入履歴と、を有するトレーニングデータを用いて、前記物品及びサービスの少なくともいずれかの購入に関連するコミュニケーションのパターンを特定するコミュニケーションモデルを生成するコミュニケーションモデル生成部と、
   前記コミュニケーションモデルと、対象ユーザと前記対象ユーザの担当者とのコミュニケーション履歴を用いることにより、前記対象ユーザに係る対象物品及び対象サービスの少なくともいずれかの購入に関連するコミュニケーションについて、前記対象ユーザの担当者への提案を生成するコミュニケーション提案生成部と、をさらに備える、
   請求項１に記載の売買支援装置。
3. 前記コミュニケーション履歴は、前記ユーザと前記ユーザの担当者との前記チャットサービスにおけるチャット履歴であり、
   前記コミュニケーションモデル生成部は、前記トレーニングデータを用いて、前記物品及びサービスの少なくともいずれかの購入に関連するチャットでの会話パターンを特定する前記コミュニケーションモデルを生成し、
   前記コミュニケーション提案生成部は、前記コミュニケーションモデルと、前記対象ユーザと前記対象ユーザの担当者とのチャット履歴を用いることにより、前記対象物品及び前記対象サービスの少なくともいずれかの購入に関連するチャットでの会話について、前記提案を生成する、
   請求項２に記載の売買支援装置。
4. 前記トレーニングデータは、前記ユーザの個人情報と、前記ユーザの物品及びサービスの少なくともいずれかの購入に関連する行動履歴と、前記ユーザの物品及びサービスの少なくともいずれかの販売促進に関する履歴と、の少なくともいずれかをさらに有し、
   前記コミュニケーション提案生成部は、前記対象ユーザの個人情報と、前記対象ユーザの前記対象物品及び前記対象サービスの少なくともいずれかの購入に関連する行動履歴と、前記対象物品及び前記対象サービスの少なくともいずれかの販売促進に関する履歴と、の少なくともいずれかをさらに用いることにより、前記提案を生成する、
   請求項２又は３に記載の売買支援装置。
5. 前記トレーニングデータは、前記売買支援装置が管理するウェブサイトに前記ユーザがアクセスしたときの行動履歴を、前記ユーザの個人情報として含み、
   前記コミュニケーション提案生成部は、前記行動履歴を用いることにより、前記提案を生成する、
   請求項４に記載の売買支援装置。
6. 前記コミュニケーション提案生成部は、前記対象ユーザに対してコミュニケーションを取るタイミングと、前記対象ユーザに対して購入を勧める物品及びサービスの少なくともいずれかと、前記対象ユーザに対する前記対象物品及び前記対象サービスの少なくともいずれかの販売促進の手法と、の少なくともいずれかに関する前記提案を生成する、
   請求項４又は５に記載の売買支援装置。
7. 物品及びサービスの少なくともいずれかに関する、広告及び販売促進の少なくともいずれかの履歴、並びに前記物品及びサービスの少なくともいずれかの販売履歴を有するトレーニングデータを用いて、前記物品及びサービスの少なくともいずれかの販売に関連する広告及び販売促進の少なくともいずれかの手法を特定する販売モデルを生成する販売モデル生成部と、
   前記販売モデルを用いて、対象物品及び対象サービスの少なくともいずれかの販売に関連する、広告及び販売促進の少なくともいずれかについての提案を生成する販売方法提案生成部と、をさらに備える、
   請求項１乃至６のいずれか１項に記載の売買支援装置。
8. 前記ユーザが保有している保有物品の更新情報であり、前記保有物品の購入時又は前回の更新情報送信時からの前記保有物品の状態の変化の有無を示す情報であって、前記保有物品の検索に用いられる検索用情報を含む更新情報を、前記チャットサービスを介して前記ユーザの端末から取得する更新情報取得部と、
   前記更新情報を取得したことに応じて、前記保有物品の情報であり、前記検索用情報に紐づけられた保有物品情報を保有物品データベースから取得する保有物品情報取得部と、
   前記記憶部から類似の観点に関する情報を取得し、前記類似の観点に関する情報を用いて、前記保有物品情報と、前記ユーザが購入可能な物品を記憶する購入可能物品データベースに格納された、買い替え候補の物品の情報である買い替え候補物品情報とを比較し、前記保有物品と前記買い替え候補の物品とが類似していると判定した場合に、前記買い替え候補物品を、前記保有物品に類似する物品として特定する特定部と、
   前記ユーザに対し、前記保有物品に類似する物品として特定された前記買い替え候補物品を、前記保有物品から買い替える対象の物品として提案する、前記買い替え候補物品の情報が含まれた買い替え提案を生成する提案生成部と、
   前記買い替え提案を、前記チャットサービスを介して前記ユーザの端末に提示する提示部と、をさらに備える、
   請求項１に記載の売買支援装置。
9. 前記保有物品情報には、前記ユーザが保有物品を購入した際の価格情報が含まれており、
   前記特定部は、前記価格情報を用いて、前記保有物品と前記買い替え候補の物品とが類似しているか否かを判定し、前記価格情報と前記買い替え候補物品価格情報とが類似していると判定した場合に、前記買い替え候補物品を、前記保有物品に類似する物品として特定する、
   請求項８に記載の売買支援装置。
10. 前記特定部は、前記チャットサービスを介して、前記ユーザの端末から前記買い替え候補物品に興味を有する旨の通知を取得した場合に、前記通知に基づいて、前記ユーザが興味を有する前記買い替え候補物品と類似の物品を、次回以降に前記提案生成部が提案する前記買い替え候補物品として特定する、
    請求項８又は９に記載の売買支援装置。
11. 前記ユーザが保有している保有車に関する情報であって、前記保有車の検索に用いられる検索用情報を含む保有車に関する情報を、前記チャットサービスを介して前記ユーザの端末から取得する情報取得部と、
    前記検索用情報に紐づけられた前記保有車の保有車情報を、保有車データベースから取得する保有車情報取得部と、
    前記記憶部から類似の観点に関する情報を取得し、前記類似の観点に関する情報を用いて、前記保有車情報と、中古車の販売金額を記憶する販売金額データベースに格納された中古車情報とを比較し、前記保有車と前記中古車とが類似していると判定した場合に、前記中古車の販売金額情報を前記販売金額データベースから取得する販売金額取得部と、
    前記保有車情報と、前記中古車の販売金額情報とに基づいて、前記保有車の現在又は将来の査定価格を予測する予測部と、
    予測された前記査定価格を、前記チャットサービスを介して前記ユーザの端末に提示する提示部と、をさらに備える、
    請求項１乃至１０のいずれか１項に記載の売買支援装置。
12. 前記保有車情報には、前記保有車のリコール対象の有無、車検のタイミング、法定点検のタイミングの少なくともいずれかに関する情報が含まれる、
    請求項１１に記載の売買支援装置。
13. 前記保有車に関する情報は、前記保有車の車検証のデータを含む、
    請求項１１又は１２に記載の売買支援装置。
14. 登録されたユーザの端末情報と、前記端末情報に紐づけられたチャットサービスの担当者の端末情報と、を記憶する記憶ステップと、
    記憶された前記ユーザの端末情報及び前記担当者の端末情報に基づいて、前記ユーザの端末と前記担当者の端末とを接続するチャットサービスを提供する提供ステップと、
    を売買支援装置が実行する売買支援方法。
15. 登録されたユーザの端末情報と、前記端末情報に紐づけられたチャットサービスの担当者の端末情報と、を記憶する記憶ステップと、
    記憶された前記ユーザの端末情報及び前記担当者の端末情報に基づいて、前記ユーザの端末と前記担当者の端末とを接続するチャットサービスを提供する提供ステップと、
    をコンピュータに実行させるプログラム。

Images