JP6998284B2

JP6998284B2 - プログラム、情報処理方法、端末、サーバ

Info

Publication number: JP6998284B2
Application number: JP2018179568A
Authority: JP
Inventors: 彰二藤原; 正樹国京
Original assignee: Line Corp
Current assignee: Line Corp
Priority date: 2018-09-25
Filing date: 2018-09-25
Publication date: 2022-01-18
Anticipated expiration: 2038-09-25
Also published as: US20210110442A1; KR20210065966A; WO2020066038A1; JP7273097B2; JP2021144720A; CN112136147A; JP2020052590A

Description

本開示は、プログラム、情報処理方法、端末、サーバに関する。

近年、メッセージングサービスを介して、顧客とサービスを供給する企業との間でやり取りを行って取引を行う機会が増加している。特許文献１には、顧客と店舗との間でチャットを利用してコミュニケーションをとることができる情報提供システムが開示されている。

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

本発明の第１の態様によると、サーバと情報の通信を行うユーザの端末によって実行されるプログラムは、ユーザの情報を含み、ユーザが特定されない情報である第１情報を端末の通信部によってサーバに送信することと、第１情報に基づく、ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、少なくとも１つ以上の候補企業に対する評価に関する評価情報と、第１情報に基づく、少なくとも１つ以上の候補企業によって送信された第１金額の情報とを通信部によってサーバから受信することと、評価情報に基づく、少なくとも１つ以上の候補企業に関する情報と、第１金額の情報に基づく第１表示とを端末の表示領域に表示することと、表示領域に表示された、少なくとも１つ以上の候補企業に関する情報のうち、ユーザによって選択された企業に対して、ユーザが特定可能になる情報を含む第２情報を通信部によってサーバに送信することと、第２情報に基づく、ユーザによって選択された企業によって送信された第２金額の情報を通信部によってサーバから受信することと、第２金額の情報に基づく第２表示を表示領域に表示することとが端末によって実行される。
本発明の第２の態様によると、サーバと情報の通信を行うユーザの端末の情報処理方法は、ユーザの情報を含み、ユーザが特定されない情報である第１情報を端末の通信部によってサーバに送信することと、第１情報に基づく、ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、少なくとも１つ以上の候補企業に対する評価に関する評価情報と、第１情報に基づく、少なくとも１つ以上の候補企業によって送信された第１金額の情報とを通信部によってサーバから受信することと、評価情報に基づく、少なくとも１つ以上の候補企業に関する情報と、第１金額の情報に基づく第１表示とを端末の表示領域に表示することと、表示領域に表示された、少なくとも１つ以上の候補企業に関する情報のうち、ユーザによって選択された企業に対して、ユーザが特定可能になる情報を含む第２情報を通信部によってサーバに送信することと、第２情報に基づく、ユーザによって選択された企業によって送信された第２金額の情報を通信部によってサーバから受信することと、第２金額の情報に基づく第２表示を表示領域に表示することとを含む。
本発明の第３の態様によると、サーバと情報の通信を行うユーザの端末は、ユーザの情報を含み、ユーザが特定されない情報である第１情報をサーバに送信し、第１情報に基づく、ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、少なくとも１つ以上の候補企業に対する評価に関する評価情報と、第１情報に基づく、少なくとも１つ以上の候補企業によって送信された第１金額の情報とを受信する通信部と、評価情報に基づく、少なくとも１つ以上の候補企業に関する情報と、第１金額の情報に基づく第１表示とを表示する表示部とを備え、通信部は、表示部に表示された、少なくとも１つ以上の候補企業に関する情報のうち、ユーザによって選択された企業に対して、ユーザが特定可能になる情報を含む第２情報をサーバに送信し、第２情報に基づく、ユーザによって選択された企業によって送信された第２金額の情報をサーバから受信し、表示部は、第２金額の情報に基づく第２表示を表示する。
本発明の第４の態様によると、ユーザの端末と情報の通信を行うサーバによって実行されるプログラムは、ユーザの情報を含み、ユーザが特定されない情報である第１情報をサーバの通信部によって端末から受信することと、第１情報に基づいて、ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、少なくとも１つ以上の候補企業に対する評価に関する評価情報と、第１情報に基づいて、少なくとも１つ以上の候補企業によって送信された第１金額の情報とを通信部によって端末に送信することと、端末の表示領域に表示された、少なくとも１つ以上の候補企業に関する情報のうち、ユーザによって選択された企業に対して、ユーザが特定可能になる情報を含む第２情報を通信部によって端末から受信することと、第２情報に基づく、ユーザによって選択された企業によって送信された第２金額の情報を通信部によって端末に送信することとがサーバによって実行される。
本発明の第５の態様によると、ユーザの端末と情報の通信を行うサーバの情報処理方法は、ユーザの情報を含み、ユーザが特定されない情報である第１情報をサーバの通信部によって端末から受信することと、第１情報に基づいて、ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、少なくとも１つ以上の候補企業に対する評価に関する評価情報と、第１情報に基づいて、少なくとも１つ以上の候補企業によって送信された第１金額の情報とを通信部によって端末に送信することと、端末の表示領域に表示された、少なくとも１つ以上の候補企業に関する情報のうち、ユーザによって選択された企業に対して、ユーザが特定可能になる情報を含む第２情報を通信部によって端末から受信することと、第２情報に基づく、ユーザによって選択された企業によって送信された第２金額の情報を通信部によって端末に送信することとを含む。
本発明の第６の態様によると、ユーザの端末と情報の通信を行うサーバは、ユーザの情報を含み、ユーザが特定されない情報である第１情報を端末から受信し、第１情報に基づいて、ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、少なくとも１つ以上の候補企業に対する評価に関する評価情報と、第１情報に基づいて、少なくとも１つ以上の候補企業によって送信された第１金額の情報とを端末に送信し、端末の表示領域に表示された、少なくとも１つ以上の候補企業に関する情報のうち、ユーザによって選択された企業に対して、ユーザが特定可能になる情報を含む第２情報を受信し、第２情報に基づく、ユーザによって選択された企業によって送信された第２金額の情報を端末に送信する通信部を備える。

実施形態の一態様における通信システムの構成を示す図。ユーザ情報の構成例を示すデータ概念図。依頼情報の構成例を示すデータ概念図。詳細が開示された状態の依頼情報の構成例を示すデータ概念図。端末に見積もりが送信されるまでの通信システムにおける各装置のやり取りの例を示すシーケンス図。図５におけるやり取りを実現する端末の動作例を示すフローチャート。図５におけるやり取りを実現するサーバの動作例を示すフローチャート。図５におけるやり取りを実現する企業サーバの動作例を示すフローチャート。（ａ）は、端末が見積もりを依頼する際の例を示す端末の画面図。（ｂ）は、サーバとの間のトークルームの例を示す端末の画面図。（ｃ）は、トークルームの一覧が示された例を示す端末の画面図。（ａ）は、企業サーバとの間のトークルームの例を示す端末の画面図。（ｂ）は、サーバとの間のトークルームの例を示す端末の画面図。（ｃ）は、一部のトークルームが削除されたトークルームの一覧を示す端末の画面図。（ａ）は、リッチメニューの例を示す端末の画面図。（ｂ）は、交渉用の画像を用いた企業サーバとの取引の例を示す端末の画面図。（ａ）は、サーバとの間のトークルームの様子を示す画面例であって、担当者の評価例を示す画面図。（ｂ）は、ユーザにおすすめの企業を示す場合の例を示す画面図。端末に特典が送信されるまでの通信システムにおける各装置のやり取りの例を示すシーケンス図。図１３におけるやり取りを実現するサーバの動作例を示すフローチャート。図１３におけるやり取りを実現する端末の動作例を示すフローチャート。（ａ）、（ｂ）は、端末から請求額の情報をサーバに送信する例を示す端末の画面図。サーバが端末に見積もりを送信する際の他の動作例を示すフローチャート。サーバから端末にまとめて見積もりが送信された際の例を示す端末の画面図。おすすめユーザが示された依頼情報の例を示す図。おすすめユーザが示されたトークルームの例を示す画面図。企業情報の構成例を示すデータ概念図。サーバがユーザと企業との間のマッチングをする際のやり取りの例を示すシーケンス図。サーバのユーザと企業とのマッチングをする際の動作例を示すフローチャート。（ａ）、（ｂ）は、マッチングを行う際の２つの依頼間の関係の例を示すためのイメージ図。（ａ）、（ｂ）は、サーバから企業サーバに依頼がされた際に特定のユーザをおすすめする際の例を示す企業サーバにおける画面図。（ａ）は、端末の他の構成例を示すブロック図、（ｂ）は、サーバの他の構成例を示すブロック図、（ｃ）は企業サーバの他の構成例を示すブロック図。

＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。

本開示に係る端末による取引先の評価を表示する表示方法を実施するための実施形態について、図面を参照して説明する。

＜システム構成＞
図１は、本開示の一実施形態に係る通信システム１の構成を示す。図１に開示されるように、通信システム１では、ネットワーク３０を介してサーバ１０と、端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ）と、企業サーバ４０とが接続される。サーバ１０は、ネットワーク３０を介してユーザが所有する端末２０に、端末２０間（企業サーバ４０を含んでよい）でのメッセージの送受信を実現するサービスを提供する。なお、ネットワーク３０に接続される端末２０の数は限定されない。

ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０とを接続する役割を担う。すなわち、ネットワーク３０は、端末２０がサーバ１０に接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定でなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。

端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ）は、各実施形態において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ・（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。

端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は基本的には同一であるため、以下の説明においては、端末２０について説明する。また、必要に応じて、ユーザXが利用する端末を端末２０Xと表現し、ユーザXまたは端末２０Xに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Xと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。

サーバ１０は、端末２０に対して、所定のサービスを提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定でなく例として、サーバ装置、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。

＜ハードウェア（HW）構成＞
図１を用いて、通信システム１に含まれる各装置のHW構成について説明する。

（１）端末のHW構成

端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、表示部２４、マイク２３３、スピーカ２３２、カメラ２３４を備える。端末２０のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、端末２０のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、マイク２３３、カメラ２３４等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。通信Ｉ／Ｆ２２は、ネットワーク３０を介して企業サーバ４０との通信を実行する機能を有してもよいし、有さなくてもよい。

入出力部２３は、端末２０に対する各種操作を入力する装置、および、端末２０で処理された処理結果を出力する装置を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

入力部は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定でなく例として、タッチパネル２３１、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ２３４（動画像を介した操作入力）、マイク２３３（音声による操作入力）を含む。

出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定でなく例として、タッチパネル、タッチディスプレイ、スピーカ２３２（音声出力）、レンズ（限定でなく例として３D（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ（限定でなく例として、液晶ディスプレイやOELD（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Dで表示データを表示可能であってもよいし、そうでなくてもよい。

入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。

制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

制御部２１は、限定でなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。

記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定でなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。

端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。

マイク２３３は、音声データの入力に利用される。スピーカ２３２は、音声データの出力に利用される。カメラ２３４は、動画像データの取得に利用される。

（２）サーバのHW構成
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、表示部１３を備える。サーバ１０のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、サーバ１０のHWは、サーバ１０のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のHWは、表示部１３を取り外すような構成であってもよいし、そうでなくてもよい。

制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。

制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。

記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。

通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０や企業サーバ４０との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０又は企業サーバ４０に送信する。また、通信Ｉ／Ｆ１４は、端末２０又は企業サーバ４０から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部１２は、サーバ１０に対する各種操作を入力する装置により実現される。入出力部１２は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部１２は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部１２、限定でなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部１２は、これらに限定されない。

表示部１３は、代表的にはモニタ（限定でなく例として、液晶ディスプレイやOELD（organic electroluminescence display））で実現される。なお、表示部１３は、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらの表示部１３は、３Dで表示データを表示可能であってもよいし、そうでなくてもよい。ただし、本開示において、表示部１３は、これらに限定されない。
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。

企業サーバ４０は、制御部４１（ＣＰＵ）、記憶部４５、通信Ｉ／Ｆ４４（インタフェース）、入出力部４２、表示部４３を備える。企業サーバ４０のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、企業サーバ４０のHWは、企業サーバ４０のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、企業サーバ４０のHWは、表示部４３を取り外すような構成であってもよいし、そうでなくてもよい。

制御部４１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。

制御部４１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部４１は、これらに限定されない。

記憶部４５は、企業サーバ４０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部４５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部４５は、これらに限定されない。また、記憶部４５は、メモリ(memory)と表現されてもよいし、されなくてもよい。

通信Ｉ／Ｆ４４は、ネットワーク３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ４４は、ネットワーク３０を介して、サーバ１０との通信を実行する機能を有する。通信Ｉ／Ｆ４４は、各種データを制御部４１からの指示に従って、サーバ１０に送信する。また、通信Ｉ／Ｆ４４は、サーバ１０から送信された各種データを受信し、制御部４１に伝達する。また、通信Ｉ／Ｆ４４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ４４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。通信Ｉ／Ｆ４４は、ネットワーク３０を介して、端末２０と通信を実行する機能を有していてもよいし、有していなくてもよい。

入出力部４２は、企業サーバ４０に対する各種操作を入力する装置により実現される。入出力部４２は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部４１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部４２は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部４２、限定でなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部４２は、これらに限定されない。

表示部４３は、代表的にはモニタ（限定でなく例として、液晶表示部やOELD（organic electroluminescence display））で実現される。なお、表示部４３は、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらの表示部４３は、３Dで表示データを表示可能であってもよいし、そうでなくてもよい。ただし、本開示において、表示部４３は、これらに限定されない。

本開示の各実施形態においては、端末２０、サーバ１０、または、企業サーバ４０のＣＰＵがプログラムPを実行することにより、実現するものとして説明する。

なお、端末２０の制御部２１、サーバ１０の制御部１１、または、企業サーバ４０の制御部４１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

また、本開示の各実施形態のプログラムP(限定ではなく、例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムPを記憶可能である。また、プログラムPは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。

記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定でなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。

サーバ１０、端末２０、または、企業サーバ４０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。

また、本開示のプログラムＰＤＤは、当該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０、端末２０、または、企業サーバ４０に提供されてもよいし、されなくてもよい。サーバ１０、端末２０、または、企業サーバ４０は、限定でなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。

また、本開示の各実施形態は、プログラムPが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
サーバ１０、端末２０、または、企業サーバ４０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０における処理の少なくとも一部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。

なお、本開示のプログラムは、限定でなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのオブジェクト指向プログラミング言語、HTML5などのマークアップ言語などを用いて実装される。

＜機能構成＞
＜第１実施形態＞
第１実施形態に係る通信システム１においては、ユーザの端末２０からサーバ１０に対して、見積もり依頼を送信し、サーバ１０を介して、各企業サーバ４０から見積もり情報を受信する。このとき、サーバ１０は、ユーザの端末２０に対して、見積もりを行う企業サーバ４０各々の評価情報を送信する。端末２０が、企業サーバ４０各々の評価を表示することにより、ユーザは、それぞれの企業サーバ４０各々の客観的な評価を認識することができ、見積もりを実際よりも安く見積もるような企業を選択しないようにすることができる。なお、以降においては、端末２０、企業サーバ４０においては、サーバ１０が提供するメッセージングサービスを利用しているものとする。

（１）端末の機能構成
図１に示すように、端末２０は、制御部２１により実現される機能として、メッセージ処理部２１１と、表示処理部２１２とを備える。

メッセージ処理部２１１は、サーバ１０が提供するメッセージングサービスにおいて提供されるメッセージングアプリケーションに従って、ユーザからの入力または通信Ｉ／Ｆ１２が受信したメッセージの入力を受け付けて、表示処理部２１２に表示するように指示する。なお、ユーザからの入力を受け付けた場合には、その受け付けた入力内容を通信Ｉ／Ｆ２２にサーバ１０に宛てて送信するように指示する。

表示処理部２１２は、メッセージ処理部２１１からの指示に従ってトークルームの内容を示す表示情報を、表示部２４に表示する指示する。本実施形態においては、表示処理部２１２は、ユーザが行った見積もり依頼に応じて、サーバ１０から送信された見積もり依頼を行う企業サーバ４０を特定可能な情報と、その企業サーバ４０の評価を示す評価情報とを表示する。なお、このとき、企業サーバ４０を特定可能な情報は、その評価情報に基づく表示を行ってもよいし、そうでなくてもよい。評価情報に基づく表示とは、限定ではなく一例として、企業サーバ４０の評価情報で示される評価の高い順、あるいは、低い順に基づく表示であったり、企業サーバ４０の評価を端的に示す評価値（数値、レベル、グラフ等）を示す表示であったり、評価の高い企業サーバ４０を、評価の低い企業サーバ４０とは区別する表示であってよい。この表示方法は、表示処理部２１２が予めユーザにより定められた設定によって決定されてもよいし、されなくてもよい。また、あるいは、サーバ１０が指定するものであってもよいし、そうでなくてもよい。また、表示処理部２１２は、端末２０が行う見積もり依頼に伴って、サーバ１０や企業サーバ４０とのやり取りに係る情報を表示する。

（２）サーバの機能構成
図１に示すように、サーバ１０は、制御部１１により実現される機能として、決定部１１１と、メッセージ処理部１１２と、を備える。また、記憶部１５は、ユーザの情報を示すユーザ情報２００と、企業（企業サーバ４０）の情報を示す企業情報２１００とを記憶している。

メッセージ処理部１１２は、各ユーザ間のやり取りを行うためのトークルームを管理する機能と、ユーザの端末２０からされたトークルームに送信されたメッセージ（見積もり依頼）を解析して、決定部１１１が決定した企業サーバ４０に見積もり依頼を送信する機能と、を備える。トークルームとは、サーバ１０が提供するメッセージングサービスを介して、このメッセージングサービスを利用するユーザ（企業サーバ４０を含む）間のメッセージのやり取りをする場所のことであり、トークルームに参加しているユーザが送信したメッセージが、トークルームに参加している全てのユーザが見ることができるユーザインターフェースである。トークルームは、メッセージングサービスを利用するユーザ（企業サーバ４０を含む）、または、サーバ１０が開設することができ、トークルームが開設されると、そのトークルームに対応付けられているユーザは、そのトークルームに対してメッセージを送信することができるようになる。トークルームにメッセージを送信することができるユーザは、トークルームを開設したユーザ、または、トークルームに参加しているユーザが設定することができる。また、トークルームからユーザは自身の任意により抜けることができる。また、サーバ１０は、必要に応じて、トークルームを閉じることもできる。メッセージ処理部１１２は、ユーザからの見積もり依頼があった場合に、その見積もり依頼に従って、決定部１１１に見積もり依頼を送信する企業サーバ４０を決定するように指示する。そして、決定部１１１が決定した複数の企業サーバ４０に対して見積もり依頼（依頼情報）がある旨を送信する。依頼情報の詳細については後述する。メッセ０時処理部１１２は、決定部１１１が決定した複数の企業サーバ４０から見積もりの提示がある旨を、各企業サーバ４０についての評価情報とともに、端末２０に送信する。ここで、評価情報は、予め記憶部１５に記憶されていてもよいし、記憶されていなくてもよい。記憶部１５に記憶されていない場合には、ネットワーク３０や外部の装置から取得することとしてよい。評価情報は各企業サーバ４０の評価を示す情報である。その評価は、客観的な数値やレベル表記（数値、記号のいずれの表現であってもよい）、文書などで表現されてよい。企業サーバ４０の評価情報は、その企業サーバ４０に寄せられた多くの利用者であるユーザからの評価を集計したものを用いるとよい。評価情報は適宜その評価内容が更新されてもよいし、されなくてもよい。評価情報は、過去の企業サーバ４０の実績に基づくものであってよく、過去の全てのデータを利用することとしてもよいし、所定期間内（限定ではなく一例として、現在から過去２年以内）のデータを利用することとしてもよい。また、メッセージ処理部１１２は、ユーザに対してサービスを依頼する企業が決定した場合に、その企業が請求した請求額の情報を提供した場合に、特典を送信する旨をユーザに送信する機能も有する。また、メッセージ処理部１１２は、端末２０または企業サーバ４０に対して、決定部１１１が、ユーザ情報２００と企業情報２１００を用いて相性のよさから見積もり依頼を送信する企業サーバ４０を決定した場合に、それぞれ、またはいずれか一方に対して、おすすめである旨を示す情報をトークルーム上に送信する。

決定部１１１は、ユーザの端末２０からの見積もり依頼、即ち、ユーザから提供された情報に基づいて、その見積もり依頼を送信する対象となる企業サーバ４０を決定する機能を有する。即ち、決定部１１１は、ユーザからの見積もり依頼の内容と、企業サーバ４０との間のマッチングを行う。決定部１１１は、少なくとも２つの企業サーバ４０を見積もり依頼の対象となる企業として決定する。このとき、決定部１１１は、ユーザからの見積もり依頼の内容と、その依頼内容を得意とする、あるいは、ユーザとの相性がよいと推察される企業サーバ４０を、決定することとしてもよいし、しなくてもよい。決定部１１１は、相性がよいと推察される企業サーバ４０を決定する場合には、ユーザ情報２００と、企業情報２１００とを参照して決定する。そうでない場合は、例えば、決定部１１１は、所定数の企業サーバ４０をランダムに決定してもよい。ユーザと企業との間の関連性を考慮して企業サーバ４０を決定する手法については後述する。

（３）企業サーバの機能構成
図１に示すように企業サーバ４０は、制御部４１により実現される機能として、メッセージ処理部４１１と、表示処理部４１２と、を備える。

メッセージ処理部４１１は、通信Ｉ／Ｆ４４を介してサーバ１０、または、端末２０から送信されたメッセージを処理する機能を有する。メッセージ処理部４１１は、サーバ１０から送信されたユーザからの見積もりの内容を示す依頼情報があることを示す情報を表示処理部４１２に表示させる。また、メッセージ処理部４１１は、企業サーバ４０のオペレータから入力された依頼情報で示される見積もり依頼に対する見積もり額に関する情報を、通信Ｉ／Ｆ４４から、サーバ１０に送信させる。

表示処理部４１２は、サーバ１０、または、端末２０との間のやりとりをするためのトークルームの内容を、表示部４３に表示する機能を有する。

＜データ＞
図２は、サーバ１０の記憶部１５に記憶されているユーザ情報の一例を示すデータ概念図である。図２に示すようにユーザ情報２００は、サーバ１０が提供するサービスを利用する各ユーザについての情報である。ユーザ情報２００は、各ユーザについて、限定ではなく一例として、識別情報２０１と、名前２０２と、電話番号２０３と、メールアドレス２０４と、郵便番号２０５と、一部住所２０６と、番地２０７とが対応付けられた情報である。なお、ユーザ情報２００は、図２に示す各情報について、含んでいてもよいし、含まなくてもよい。ユーザ情報２００に示される各情報は、ユーザが自身の端末２０に対して入力を行い、端末２０の制御部１１からの指示に従って通信Ｉ／Ｆ２２が、サーバ１０に送信したものであり、制御部１１は、ユーザ情報２００として記憶部１５に記憶する。ユーザ情報２００には、ユーザ個人を一意に特定できないもののユーザに関する情報（限定ではなく、第１情報の一例）と、ユーザ個人を特定可能な情報（限定ではなく、第２情報の一例）とが含まれる。図２の例で言えば、ユーザ個人を特定できないユーザ個人に関する情報は、識別情報２０１、郵便番号２０５、一部住所２０６が該当する。また、図２の例で言えば、名前２０２、電話番号２０３、メールアドレス２０４、番地２０７は、ユーザ個人を特定可能な情報に該当する。

識別情報２０１は、通信システム１において、サーバ１０が各ユーザを一意に識別するための識別子である。識別情報２０１は、ユーザを特定できる情報であれば、どのような態様であってもよく、アルファベットや記号、数字等の一部又は全部を利用した組み合わせであってもよい。

名前２０２は、対応する識別情報２０１で示されるユーザの名前であって、ユーザが自身でサーバ１０が提供するサービスを利用する際に登録した名前である。

電話番号２０３は、対応する識別情報２０１で示されるユーザと音声通話が可能な機器の電話番号を示す情報である。なお、電話番号２０３は、一人のユーザに対して複数記憶されていてもよい。

メールアドレス２０４は、対応する識別情報２０１で示されるユーザと電子メールによる連絡が可能なアドレスを示す情報である。なお、メールアドレス２０４は、一人のユーザに対して複数記憶されていてもよい。

郵便番号２０５は、対応する識別情報２０１で示されるユーザの住所に対して割り振られている郵便番号を示す情報である。

一部住所２０６は、対応する識別情報２０１で示されるユーザの居住している場所を示す情報であって、そのおおよその場所を示す情報である。

番地２０７は、対応する識別情報２０１で示されるユーザの居住している場所の番地を示す情報である。一般的には、一部住所２０６と番地２０７とを併せて住所とされる。

図２に示すユーザ情報を保持していることにより、サーバ１０は、企業サーバ４０に対して、ユーザが許諾した場合に、ユーザ自身の詳細な情報を提供することができる。

図３は、サーバ１０から企業サーバ４０に対して提供される依頼を示す依頼情報の一例を示すデータ概念図である。図３に示す依頼情報３００は、ユーザから企業サーバ４０が提供するサービスの提供を依頼するための情報であって、サーバ１０から提供される情報である。図３に示すように依頼情報３００は、依頼日３０１と、名前３０２と、電話番号３０３と、郵便番号３０４と、一部住所３０５と、住所詳細３０６と、その他３０７とが対応付けられた情報である。なお、依頼情報３００は、サービスを提供するにあたって必要な情報があればよく、図３に示す情報の全てを含まずともよいし、ユーザに関連する情報であれば、図３以外の情報を追加で含んでもよい。依頼情報３００は、企業サーバ４０の記憶部４５に記憶される。

依頼日３０１は、ユーザが依頼を行った日付を示す情報である。

名前３０２は、ユーザの名前を示す情報である。

電話番号３０３は、対応するユーザと音声通話が可能な機器の電話番号を示す情報である。なお、電話番号３０３は、一人のユーザに対して複数記憶されていてもよい。

郵便番号３０４は、対応するユーザの住所に対して割り振られている郵便番号を示す情報である。

一部住所３０５は、対応するユーザの居住している場所を示す情報であって、そのおおよその場所を示す情報である。おおよその場所の情報があることで、ユーザの厳密な居所を特定できないものの、引っ越しをする際のおおよその見積もりをすることができる。

住所詳細３０６は、対応するユーザの居住している場所の番地を示す情報である。一般的には、一部住所３０５と住所詳細３０６とを併せて住所とされる。

その他３０７には、対応するユーザとのトークを行うためのチャットボタンや、対応するユーザからの許諾が得られた場合に、ユーザに関する詳細情報を取得するための詳細ボタン３２７が配されている。チャットボタンをクリックした場合には、サーバ１０が提供するメッセージングサービスの画面であって、企業サーバ４０と、対応するユーザとの間のトークルームが起動され、チャットを行うことができるようになる。一方、詳細ボタン３２７をクリックした場合には、ユーザからの許諾を得ているという条件下で、対応するユーザに関する詳細な情報が得られる。

図３に示す依頼情報３００は、サーバ１０から提供される初期段階の情報であり、ユーザを特定できない程度の情報の開示がされている情報である。したがって、ユーザを特定可能な情報は、初期段階では空欄となっている。このとき、ユーザからの許諾を得て企業サーバ４０のオペレータが詳細ボタン３２７をクリックすると、そのユーザに対応する詳細なユーザ情報をサーバ１０から取得することができる。

図４は、図３に示す詳細ボタン３２７がクリックされた状態の依頼情報３００を示している。図３から図４への変化を見ればわかるように、「Ｂ藤Ｂ子」の名前と、その電話番号３０３や住所詳細３０６が、企業サーバ４０にとって明らかになっている。

＜動作＞
図５は、本実施形態に係る通信システム１の動作を示すシーケンス図である。図５に示すシーケンス図は、ユーザがサービスの提供の依頼を行ってから、企業サーバ４０が見積もりをユーザに送るまでの流れを示す図である。

図５に示すように、ユーザは、自身の端末２０から、例えば、サーバ１０が提供する各企業サーバ４０が提供するサービスの依頼をするウェブフォームにアクセスして、見積もり依頼をサーバ１０に送信する（ステップＳ５０１）。ここでは、引越しのための依頼ということで、例えば、ユーザは、引越し先や引越し人数等の情報を入力して、端末２０からサーバ１０に送信する。

見積もり依頼を受信したサーバ１０は、その見積もり依頼を送信した端末２０に対して、各企業サーバから見積もりが送信される旨を、端末２０に送信する。限定ではなく、一例として、サーバ１０は、サーバ１０と端末２０との間の専用のトークルームを介して、各企業サーバからの見積もりが後程送信される旨、及びそれらの企業の評価を示す評価情報を、端末２０に通知する（ステップＳ５０２）。その一方で、サーバ１０は、複数の企業サーバに対して、ユーザからの見積もり依頼を送信する（ステップＳ５０３）。

見積もり依頼を受信した各企業サーバ４０は、見積もり依頼に含まれる条件のみから、おおよその見積もり額を算出する。そして、算出した見積もり額を、端末２０との間に開かれたトークルームに書き込むことで、見積もり額を示す情報を、サーバ１０を介して端末２０に送信する（ステップＳ５０４）。

端末２０のユーザは表示された簡易の見積もり額を表示し、ユーザはその内容を確認する。そして、ユーザは、その見積もりを提示した企業サーバに対して、詳細な見積もりを要求するために情報の開示を承諾する入力を行う。端末２０は、情報開示を承諾した旨をサーバ１０に通知する（ステップＳ５０５）。

サーバ１０は、端末２０が情報の開示を承諾しなかった企業とのトークを削除する（ステップＳ５０６）。一方で、ユーザが開示を許諾した企業サーバ４０からの情報開示要求に応じて、ユーザの詳細な個人情報を送信する（ステップＳ５０７）。

ユーザの詳細な情報を見た企業サーバ４０のオペレータは、詳細な見積もりを端末２０に対して提示する（ステップＳ５０８）。

このようにして、ユーザは、自身で信用できると感じた企業サーバに対して詳細情報を開示し、見積もりをとることができる。

図６は、図５に示すやり取りを実現するための端末２０において見積もりを得るまでの処理を示すフローチャートである。

図６に示すように、ユーザは、端末２０から、企業サーバ４０からのサービスの提供をうけるため、即ち、引越しの見積もり依頼をサーバ１０に送信する（ステップＳ６０１）。即ち、端末２０は、入出力部２３に対してユーザから受け付けた見積もり依頼の入力を受け付ける。そして、この入力にしたがって通信Ｉ／Ｆ２２は、見積もり依頼をネットワーク３０を介してサーバ１０に送信する。

通信Ｉ／Ｆ２２は、見積もり依頼を受けたサーバ１０から送信された見積もりを送信する予定の企業情報を受信する。通信Ｉ／Ｆ２２は、受け付けた企業情報を制御部２１に送信する。制御部２１の表示処理部２１２は、送信された企業情報を表示部２４に表示させる（ステップＳ６０２）。

制御部２１は、通信Ｉ／Ｆ２２が見積もり額の情報を受信したか否かを判定する（ステップＳ６０３）。制御部２１は、見積もり額の情報を受信するまで（ステップＳ６０３のＮＯ）は待機する。なお、この段階で受信する見積もり額は、おおよその見積もり額になる。

見積もり額の情報を受信すると（ステップＳ６０３のＹＥＳ）、制御部２１の表示処理部２１２は、受信した見積額の情報を、送信した企業サーバに対応するトークルームに表示する（ステップＳ６０４）。なお、ステップＳ６０２における見積もりを送信する予定の企業情報の受信およびステップＳ６０３における見積もり額の情報の受信は同時であってもよいし、同時でなくてもよい。

そのおおよその見積もり額を見て、詳細な見積もりが欲しいとユーザが感じた場合には、詳細な見積もりを要求するために、ユーザ自身の詳細情報を企業サーバ４０に送信を許可する入力を行う。端末２０の入出力部２３は、ユーザから詳細情報の開示を許可する入力があるか否かを判定する（ステップＳ６０５）。

ユーザからの詳細情報の開示を許可する入力があった場合に（ステップＳ６０５のＹＥＳ）、制御部２１は、通信Ｉ／Ｆ２２を介して、サーバ１０に、詳細情報の開示許可を示す情報を送信する（ステップＳ６０６）。この情報には、どの企業サーバ４０に対しての開示許可であるかを示す情報が含まれる。限定ではなく一例として、この企業サーバ４０を特定できる情報として、ユーザがトークを行っていたトークルームを特定可能な情報を用いることができる。

制御部２１は、通信Ｉ／Ｆ２２がトークルーム削除情報を受信したか否かを判断する（ステップＳ６０７）。ここでいうトークルーム削除情報は、サーバ１０から送信されるものであり、ユーザが詳細情報の開示許可を出さなかった企業サーバ４０との間のトークルームの削除を示すものである。トークルーム削除情報を受信していない場合には（ステップＳ６０７のＮＯ）、ステップＳ６０９の処理に移行する。トークルーム削除情報を受信している場合には（ステップＳ６０７のＹＥＳ）、メッセージ処理部２１１は、ユーザが利用しているメッセージングサービスの中のトークルーム群の中から、トークルーム削除情報で示さえる企業サーバ４０とのトークルームを削除する（ステップＳ６０８）。

一方で、制御部２１は通信Ｉ／Ｆ２２が詳細な見積もり情報を受信したか否かを判定する（ステップＳ６０９）。詳細な見積もり情報を受信した場合に（ステップＳ６０９のＹＥＳ）、通信Ｉ／Ｆ２２は、受信した見積もり情報を制御部２１に送信する。制御部２１の表示処理部２１２は、受信した詳細な見積もり情報をトークルーム上に表示する（ステップＳ６１０）。

制御部２１は、ステップＳ６０５において詳細情報の開示を承諾した対象の企業サーバ４０全てから詳細な見積もり情報を受信したか否かを判定する（ステップＳ６１１）。対象の企業サーバ４０全てから詳細な見積もり情報を受信していない場合には（ステップＳ６１１のＮＯ）、ステップＳ６０７の処理に戻り、受信している場合には（ステップＳ６１１のＹＥＳ）、処理を終了する。

次に、図５に示すやり取りを実現するためのサーバ１０の処理を、図７を用いて説明する。図７は、見積もり依頼をユーザが行った際の、サーバ１０の処理を示すフローチャートである。

図７に示すように、サーバ１０の通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０から、見積もり依頼を受信する（ステップＳ７０１）。通信Ｉ／Ｆ１４は受信した見積もり依頼を制御部１１に送信する。制御部１１は、見積もり依頼を受信すると、所定の基準にしたがって、見積もり依頼の送信先として所定数の企業サーバ４０を選定する（ステップＳ７０２）。

制御部１１は、サーバ１０とユーザの端末２０との間にトークルームを開設し、開設したトークルーム上で、ユーザに対して選定した複数の企業から見積もりが送付される旨、およびその企業の評価情報を通知する（ステップＳ７０３）。

制御部１１は、選定した企業サーバ４０各々に対して、ユーザからの見積もり依頼がある旨を通知するために、通信Ｉ／Ｆ１４に、ネットワーク３０を介して企業サーバ４０にユーザからの見積もり依頼を示す情報を送信するよう指示する。通信Ｉ／Ｆ１４は、この指示に従って、指定された企業サーバ４０各々に、ユーザからの見積もり依頼を送信する（ステップＳ７０４）。このとき、サーバ１０は、一人のユーザのみの見積もり依頼を送信することとしてもよいし、複数のユーザの見積もり依頼を送信することとしてもよい。

そして、制御部１１は、選定した各企業サーバ４０とユーザとの間のトークルームを開設する（ステップＳ７０５）。サーバ１０からの見積もり依頼を受け付けて各企業サーバ４０は、ユーザとの間でトークルームを介してのやり取りを開始可能にする。

制御部１１は、ユーザの端末２０と企業サーバ４０との双方から、端末２０のユーザの詳細情報の開示要求があるか否かを判定する（ステップＳ７０６）。これは、ユーザの端末２０及び企業サーバ４０各々から詳細情報の開示要求を示す通信があったか否かにより判定することができる。

ユーザの端末２０と企業サーバ４０との各々からユーザについての詳細情報の開示要求があった場合には（ステップＳ７０６のＹＥＳ）、サーバ１０の制御部１１は、記憶部１５に記憶しているユーザ情報を用いて、ユーザの詳細情報を、企業サーバ４０に送信する（ステップＳ７０７）。なお、ここでは、ユーザの端末２０と企業サーバ４０との各々からユーザについての詳細情報の開示要求があった場合としているが（ステップＳ７０６）、これは、ユーザの端末２０からの開示要求のみであってもよいし、ユーザの端末２０からの開示要求のみでなくてもよい。また、企業サーバ４０からの開示要求のみであってもよいが、この場合には、ユーザからの許可があるエビデンスを付与したユーザの詳細情報の開示要求を用いるとよい。

一方で、ユーザの端末２０と企業サーバ４０との各々からユーザについての詳細情報の開示要求がない場合には（ステップＳ７０６のＮＯ）、サーバ１０の制御部１１は、対応する企業サーバ４０とユーザとの間のトークルームを削除する（ステップＳ７０８）。なお、ここで、ユーザの端末２０と企業サーバ４０との各々からユーザについての詳細情報の開示要求がないというのは、ユーザの端末２０からの開示要求の通知がなかった場合、ユーザの端末２０から特定の企業サーバ４０について開示要求をしないとの通知があった場合とを含む。また、ユーザの端末２０からの開示要求の通知がないというのは、他の企業については開示要求があり、かつ、企業サーバ４０との間のトークルームが開設してから所定時間が経過していることにより判断することもできる。

図８は、図５に示すやり取りを実現するための企業サーバ４０における処理を示すフローチャートである。

図８に示すように、企業サーバ４０の通信Ｉ／Ｆ４４は、サーバ１０からユーザからの見積もり依頼を受信する（ステップＳ８０１）。この見積もり依頼には、ユーザのおおよその引越し元、引越し先、引越し人数等の簡易的な見積もりをするに足る情報が含まれている。通信Ｉ／Ｆ４４は、受信した見積もり依頼を制御部４１に送信する。制御部４１の表示処理部４１２は、見積もり依頼を表示部４３に表示する。これを見て、企業サーバ４０のオペレータは、おおよその見積もり額を決定する。ここでいうおおよその見積もり額とは、企業サーバ４０が与えられている範囲内の情報で見積もれる範囲の金額のことをいい、限定ではなく一例として、与えられている範囲内の情報から、過去に行ったサービスと類似する案件を抽出し、その案件で行った見積もり若しくは請求の額面を用いた見積もり額のことをいう。また、ここで抽出する過去の案件は、複数あってよく、その場合には、おおよその見積もり額として、（ｉ）類似度の高い案件の見積もり若しくは請求の額面を利用することとしてもよいし、（ｉｉ）複数の案件の見積もり額若しくは請求額の平均値や、（ｉｉｉ）複数の案件の類似度の高い所定割合又は所定件数の見積もり額若しくは請求額の平均値を用いることとしてもよい。

制御部４１は、設定されたおおよその見積もり額を、通信Ｉ／Ｆ４４に、見積もり額を決定したユーザの端末２０に送信するように指示する。通信Ｉ／Ｆ４４は、指定されたユーザの端末２０に、見積もり額の情報を送信する（ステップＳ８０２）。企業サーバ４０は、ユーザとの間のトークにおいてユーザからの詳細情報の開示承認を得ている場合に（ステップＳ８０３のＹＥＳ）、制御部４１は、企業サーバ４０はオペレータからの入出力部４２への入力に従って（ステップＳ８０４のＹＥＳ）、対応するユーザの詳細情報の開示要求を通信Ｉ／Ｆ４１に送信させる。通信Ｉ／Ｆ４１は、詳細情報の開示要求を、サーバ１０に送信する（ステップＳ８０５）。

詳細情報の開示要求に応じて、通信Ｉ／Ｆ４４は、サーバ１０から送信された、対応するユーザの詳細情報を受信する。通信Ｉ／Ｆ４４は、受信した詳細情報を制御部４１に送信する。制御部４１の表示処理部４１２は、受信した詳細情報を表示部４３に表示させる（ステップＳ８０６）。

表示された詳細情報を見て、企業サーバ４０のオペレータは、詳細な見積もり額を決定する（ステップＳ８０７）。なお、この決定は、企業サーバ４０が行ってもよい。例えば、引越し元と、引越し先、引越しする人数に基づいて引越し費用を算出するプログラムを予め記憶しておき、このプログラムを実行することで、見積額を算出することとしてもよい。

制御部４１は、決定された詳細な見積もり額の情報を、通信Ｉ／F４４に、送信させる。通信Ｉ／Ｆ４１は、詳細な見積もり額の情報を、ネットワーク３０を介して、ユーザの端末２０に送信して（ステップＳ８０８）、処理を終了する。ステップＳ８０３において、ユーザからの詳細情報の開示の承認が得られなかった場合には（ステップＳ８０３のＮＯ）、処理を終了する。

なお、図８のフローチャートには示していないが、詳細情報の開示を得た後に、実際に見積もりを策定するために、企業サーバ４０のオペレータがユーザを直接訪問したうえで見積もりを行ってもよいことは言うまでもない。

以上が、企業サーバ４０における詳細な見積もりを発行するまでの処理になる。

＜具体例＞
以上に説明した内容を、一具体例を用いて、よりわかりやすく説明する。まず、図９（ａ）は、ユーザが自身の端末２０を用いて、見積もり依頼をする際の表示部２４に表示される入力用のＵＩの一例を示す図である。図９（ａ）においては、引越しに係る最低限の必要事項として、引越し先に関する情報を入力する入力欄９０１と、引越し人数とを入力する入力欄９０２とを含む表示画面の例を示している。なお、入力欄９０１は、住所について詳細を入力する必要はなく、地域の情報までで留めてもよいし、留めなくてもよい。図９（ａ）に必要事項を入力して送信ボタンをクリックすると、端末２０は、サーバ１０に見積もり依頼を送信する（図５のステップＳ５０１参照）。

この見積もり依頼を受けて、サーバ１０は、例えば、図９（ｂ）に示すように、サーバ１０が選定した企業サーバ４０から見積もりが送付される旨が通知される（図５のステップＳ５０２参照）。図９（ｂ）の例では、Ａ社からＥ社までの５社からの見積もりが来る例を示している。そして、図９（ｂ）に示されるように、各社に対しての評価についての情報が示される。図９（ｂ）の例では、星形で評価を示しており、星の数が多いほど評価が高い。ただし、評価情報の表示方法は、図９（ｂ）に示すものに限るものではなく、数値、文字色を用いた評価、文章による評価、など様々な態様を用いることが考えられ、サーバ１０は、その評価情報を予め記憶、若しくは、ネットワークから取得して利用することができる。また、評価情報に基づく表示として、評価が数値で示される場合には、その評価を示す数値の降順、あるいは、昇順のいずれかで表示することとしてもよいし、しなくてもよい。また、評価が予め定められた閾値よりも低い場合には、その企業については、表示しないこととしてもよいし、しなくてもよい。そのような評価が低い企業については、予めサーバ１０におけるふるい分けにより、評価の低い企業サーバ４０に対しては見積もり依頼をしないように構成されていてもよいし、しなくてもよい。また、評価が他の所定の企業よりも低い企業については、画面上に表示しないように、ユーザがその設定ができるように構成されてもよいし、しなくてもよい。その設定がされている場合に、制御部１１は、他の所定の企業の評価と、表示するか否かを決定する対象の評価とを比較し、他の所定の企業の評価よりも評価が低い場合には、表示しないと決定する。

また、図９（ｃ）に示されるように、サーバ１０が選択した企業サーバ４０とユーザとの間のトークルームが開設される。なお、図９（ｃ）は、ユーザの端末２０に表示される画面例であって、トークルームの一覧を示す図である。トークルームの一覧は、トークリストと呼称することもある。図９（ｃ）において、トークルームのいずれかを選択（タッチ）すると、その専用トークルームの表示に切り替わる。図９（ｃ）に示すように、見積もりを行う各企業サーバ４０とのトークルームがあることが理解できる。

例えば、図９（ｃ）に示すＡ社引越しセンターを選択すると、端末２０の表示部２４には、図１０（ａ）に示すように、Ａ社引越センターとの間のトーク画面が表示される。図１０（ａ）から理解できるように、Ａ社引越しセンターは、引越しのおおよその見積もり額として、ＸＸＸＸＸＸ円を提示したことが理解できる。

また、ユーザが詳細な情報の開示を許諾する場合は、図１０（ａ）の「開示する」と表示された箇所１００１をタッチすることで、端末２０からＡ社について端末２０のユーザの詳細情報の開示を許可する旨をサーバ１０に通知することができる。一方で、許諾しない場合は、図１０（ａ）の「開示しない」と表示された箇所１００２をタッチすることで、Ａ社引越しセンターには、詳細情報を開示せず、以降は交渉をしないことになる。開示しない場合、端末２０は、サーバ１０に対して、以降の交渉を終了することを示す情報を送信してもよいし、しなくてもよい。なお、詳細情報を開示する企業の選択は、図１０（ａ）を用いて説明した以外にも、例えば、図９（ａ）に示すような各企業とのトークの一覧の中から、詳細情報を開示する企業を選択する（タッチする）ことで決定してもよい。そして、この時に選択されなかったタッチされなかった企業とのトークは削除されるように構成されてもよい。

各企業サーバ４０について、それぞれ詳細情報の開示の実行、非実行の入力が完了したら（完了していなくともよい）、ユーザはサーバ１０とのトークにおいて、業者を決めたことを示す終了ボタン１０１１をタッチする。この終了ボタン１０１１へのタッチは、詳細な見積もりを依頼する業者を決めた段階でのものであってもよいし、実際に引越しを依頼する業者を定めた段階であってもよい。詳細な見積もりの依頼先を定めた段階の場合、その時点で、詳細情報を開示すると定めなかった業者については、トークルームを削除する。即ち、図１０（ｃ）に示すように、トークルームを削除する。図１０（ｃ）においては、ユーザがＡ社と、Ｄ社と、Ｅ社とを選択し、Ｂ社と、Ｃ社とのトークルームを削除した例を示している。

図９（ｃ）から図１０（ｃ）への変化に見られるようにＢ社、Ｃ社、Ｅ社とのトークルームが削除されたことが理解できる。この後、Ａ社とＤ社との間でユーザは見積もりのやり取り、実際のサービスの提供の依頼を行うことになる。

なお、詳細な見積もりを行う業者の選択、即ち、ユーザ自身の個人情報を開示する選択については、図１０（ａ）に示した例に限るものではない。例えば、図１１（ａ）に示すように、サーバ１０とユーザとのトーク上のリッチメニュー１１０１という形式で選択できるように構成されてもよい。リッチメニューとはアカウント特有のメニューのことであり、トークに関与するユーザ、又は、サーバ１０（のオペレータ）あるいは、企業サーバ４０（のオペレータ）がその内容の設定を行うことができるメニューのことである。即ち、この場合、見積もりする業者の選択のための専用メニューのことをいう。一般的には、リッチメニューは、サービスを提供する側がユーザに対する利便性を提供するために、サーバ１０又は企業サーバ４０がその内容を設定する。

また、メッセージングサービスとして、業者とのやり取りをするための画像情報１１１１を予め用意しておき、ユーザが利用できるように構成されていてもよい。この画像は、サーバ１０、あるいは、サーバ１０が通信可能な他のサーバに保存され、ユーザは当該画像をダウンロードして利用することができ、スタンプと呼称されることもある。画像としては、限定ではなく一例として、図１１（ｂ）に示すように、価格交渉の画像であってよく、日程調整をお願いする画像などがあってよい。また、あるいは、ユーザにとって許容できる金額を示す画像情報や、その金額であればその企業に対してサービスを依頼する意思があることを示す画像情報であってもよく、この場合に、その画像情報に対して、金額は変更可能に構成されていてもよい。即ち、画像として表示する金額を、ユーザが端末２０に対して金額を指定（入力）することとしてもよい。このような画像を予め用意し、提供することで、交渉事が苦手なユーザであっても、交渉をスムースに、気兼ねなく行えるようにすることができる。なお、ここでは、交渉、即ち、取引を、画像情報を用いて実行する例を示したが、これは、ユーザ自身が、取引のためのメッセージ（文字情報、テキスト）を直接トークルームに送信するものであってもよいのは言うまでもない。

また、本実施形態においては、引越しの見積もりを依頼する場合を一例として説明したが、見積もりの対象は、引越しに限るものではない。見積もりを要求する可能性のあるサービスについて、複数の競合他社が存在するサービスであれば、どのようなサービスであっても対象となり得ることは言うまでもない。簡単な情報でおおよその見積もりを出しつつ、詳細な情報で詳細な見積もりを出し得るものであればどのようなサービスでもよい。第１実施形態に示したシステムは、例えば、保険の見積もり、不動産売買の見積もり、士業の見積もり、病院の見積もり、社内システムの構築の見積もり、クラウドソーシングの見積もり、利用するＥＣサイトの見積もりなどにも利用することができる。これらのうちのいくつかについて説明する。

保険の見積もりでいえば、ユーザ自身が希望する保険の種別や年齢等のユーザを特定できない程度の情報を提示する。ユーザは、その保険会社の評価情報を受け取る。保険会社の評価情報とは、限定ではなく一例として、保険会社の業績、ユーザの評価、コストパフォーマンス等に基づく評価を示す情報である。保険会社は、その段階での保険に係る費用の見積もりやプランの提示をしてもよいし、しなくてもよい。そして、その後にユーザが信頼した保険会社に対して詳細情報を開示して、詳細な見積もりをさせることができる。

また、例えば、不動産売買の見積もりでいえば、ユーザ自身が希望する物件の条件を提示する。ユーザは、その不動産会社の評価情報を受け取る。不動産売買の評価情報とは、限定ではなく一例として、不動産の売買実績、得意とする地域、コストパフォーマンス等に基づく評価を示す情報である。不動産会社は、その段階で希望に沿う条件、その場合の売買費用や賃貸費用等の見積もりを簡易的に提示してもよいし、しなくてもよい。そして、その後にユーザが信頼した不動産会社に対して、詳細情報を開示して、詳細な見積もりをさせることができる。

また、例えば、士業の見積もりでいえば、士業として弁護士に依頼をするにあたって、まず、どのような弁護を行って欲しいのか、どのような状況であるのかについて、ユーザが特定できない程度の情報のみを開示する。これに対して、ユーザは、その弁護士の評価情報を受け取る。弁護士の評価情報とは、限定ではなく一例として、得意とする分野、顧客評価、依頼費用等に基づく情報である。弁護士は、ユーザから簡易の情報を受け取っている段階で、おおよその対応費用の見積もりをしてもよいし、しなくてもよい。その後に、ユーザは、信頼した弁護士に対して、詳細情報を開示するように構成してよい。

また、例えば、病院の見積もりの場合は、病名や患者自身の容態等の情報のみの開示で、おおよその治療費用の見積もりを依頼する。これに対して、ユーザは、その病院や医者の評価情報を受け取る。病院や医者の評価情報とは、限定ではなく一例として、得意とする治療分野、医療実績、患者の感想、治療費等に基づく評価を示す情報である。評価情報を受け取った、その後に、ユーザが信頼した医者、病院等に対して、詳細情報を開示し、ユーザは詳細な見積もりを受け取ることとしてよい。

ＥＣサイトの見積もりの場合、例えば、提供するサービスがある程度一致するサイト間での見積もりを行うことが考えられる。ＥＣ（Electronic Commerce）サイトとは、自社（他社を含んでもよい）の商品やサービスをインターネット上の独自運営のウェブサイトで販売するサイトのことをいう。ＥＣサイトとしては、限定ではなく一例として、物品販売サービス、動画配信サービス、電子書籍販売サービス、旅行代理店サービスなどがある。限定ではなく一例として、旅行サービスを提供するＥＣサイトで、ユーザが希望する旅行先、日時程度の、ユーザを特定できない情報を開示する。ユーザは、ＥＣサイト各々の評価情報を受け取る。ここで、旅行サービスの場合のＥＣサイトの評価情報とは、限定ではなく一例として、得意とする旅行先、得意とする人数、コストパフォーマンス等に基づく評価を示す情報である。ユーザからの情報に対して、ＥＣサイト側は、おおよその見積もりやプランを提示する。そして、それらのうち、ユーザの心を引いたＥＣサイトに対して詳細情報を提供するという構成をとってもよい。なお、ＥＣサイトは企業による運営であってもよいし、個人による運営であってもよい。

このように、各種の業種に対して、本実施形態に係るシステムは有用である。なお、本第１実施形態においては、２段階の見積もりを出しているが、これは、その限りではなく、ユーザは評価情報のみで詳細情報を開示する対象となる業者（企業サーバ４０）を決定する構成としてもよい。

＜第１実施形態変形例＞
（１）上記第１実施形態においては、サーバ１０が、ユーザと企業サーバとの双方から詳細情報の開示要求があった場合に、サーバ１０が保持するユーザの詳細情報を、企業サーバに送信する構成としているが、ユーザの詳細情報を企業サーバ４０に送信する手法はこれに限られるものではない。ユーザ自身が、自身の詳細情報を直接企業サーバ４０に宛てて送信してもよいことは言うまでもない。また、端末２０において表示する情報の取捨選択は、端末２０が自身で行うこととしてもよいし、サーバ１０から指定されたものであってもよい。

（２）また、上記第１実施形態においては、評価情報としては、企業サーバ４０各々の企業全体としての評価を示すものとして説明した。しかし、評価情報は企業そのものの評価に限るものではない。企業サーバ４０が提供するサービスを担当する実際の担当者の評価を示すものであってもよい。限定ではなく、一例として、図１２（ａ）に示すように、企業について、担当者の評価情報がある場合には、その担当者の評価情報も示してもよいし、示さなくてもよい。図１２（ａ）は、ユーザの端末２０の表示部２４に示す画面例であって、サーバ１０とユーザとの間のトークルームを示す画面図である。図１２（ａ）に示すように、企業名に対応付けて担当者の名前とその評価が示される。ここでは、担当者の評価として、文章で担当者がどのような担当者であるかを表現した評価を示した例を示しているが、担当者の評価は、このような文章による評価に限らず、記号や数値等により担当者の評価を数値化した情報での表現であってもよい。また、名前だけでなく、担当者の顔写真などを併せて表示するようにしてもよい。図１２（ａ）の例では、Ｂ社においてユーザのサービスを受けた場合に担当する担当者として、Ｈが担当し、その評価として、「迅速で無駄のない仕事ぶり」が示された例を示している。また、担当者の評価がある場合には、企業の評価については、あってもよいし、なくてもよい。そのために、サーバ１０は、予め、企業サーバ４０各々に属する担当者それぞれの評価を示す担当者評価情報を記憶部１５に記憶していてもよいし、しなくてもよい。記憶していない場合には、通信により企業サーバ４０から取得することとしてよい。また、担当者の評価と、企業そのものの評価と、を並列表記してもよいことは言うまでもない。

（３）また、上記第１実施形態においては、企業サーバ４０各々の評価情報のみを表示しているが、それらの企業サーバ４０の中から、ユーザに対して、おすすめの企業を特定し、おすすめである旨が端末２０の表示部２４に表示されるように構成されてもよい。ここで、このおすすめの表記の実現例について説明する。

サーバ１０の制御部１１は、ユーザからの見積もり依頼を受信した際に、ユーザ情報２００を用いて、ユーザの嗜好に合致する企業を特定する。そして、特定した企業については、評価情報を送信する際に、おすすめである旨を通知する。この通知は、おすすめである企業が他の企業と比較してわかるようなものであれば、どのような態様であってもよく、例えば、おすすめを示す画像、あるいは、文字が、企業名と連動して表示される（限定ではなく一例として、企業名におすすめの画像あるいは文字が噴出しで表示される）ようにしてもよいし、おすすめの企業が、おすすめでない企業とは異なる表示色で表示することとしてよい。この表示態様は、端末２０が決定してもよいし、サーバ１０が指定してもよい。図１２（ｂ）には、ユーザの端末２０の表示部２４において、おすすめの企業を示した例を示している。図１２（ｂ）は、ユーザの端末２０の表示部２４において、ユーザとサーバ１０との間のトークルームの一例を示す図であって、サーバ１０からユーザからの見積もり依頼に対して、送信される情報を表示した画面であり、企業サーバ４０から見積もり額の通知が送信される旨を連絡することを示す画面である。図１２（ｂ）の例では、Ｂ社がおすすめであることを示すように、Ｂ社の名称を他社と異なる態様で表示する。このとき、図１２（ｂ）に示すように、ユーザにとってより分かりやすく「オススメ」等の文言を社名に対応付けて表示するようにしてもよいし、しなくてもよい。このように、ユーザに対して、複数の企業を紹介するとともに、その中で、サーバ１０からみてユーザにとっておすすめとなる企業が見て取れる態様で企業名を表示することで、企業の一覧の中で、ユーザに対しておすすめの企業がどれかを一目でユーザに理解させることができる。

また、サーバ１０によるおすすめ企業の決定方法としては、ユーザ情報２００に、更に、ユーザの嗜好情報を含ませるとともに、サーバ１０が記憶部１５に企業サーバ４０の特色を示す情報を記憶しておくことにより実現することができる。限定ではなく一例として、ユーザの嗜好として、処理速度が迅速であることを好むという情報が対応付けられている場合には、迅速対応を旨とする企業をおすすめとし、他の例として、ユーザの嗜好として、作業時の雰囲気を重視するという情報が対応付けられている場合には、和気藹々とした雰囲気での仕事をすることを示す情報が対応付けられている企業をおすすめとして選択する。即ち、サーバ１０の制御部１１は、ユーザの嗜好情報と、企業サーバ４０に対応する企業各々の仕事をする上での特色、モットー等の情報と、の一致度合いに基づいて、おすすめとするか否かを判定する。このようにして、サーバ１０及び端末２０は、依頼する企業サーバ４０を決定するうえで、よりユーザにとって利益となる情報を提供することができる。

（４）また、上記第１実施形態においては、詳細な見積もりを受け取るところまでを説明している。実際には、その後に、ユーザは、サービスを依頼する企業サーバ４０を決定し、その企業サーバ４０からサービスの供与を受けることになる。その際、即ち、企業サーバ４０からのサービスを受けた後に、ユーザは、自身の端末２０を用いて、サーバ１０に対して、企業サーバ４０のユーザ自身の所感による評価を示すユーザ評価情報を送信することとしてよい。そして、サーバ１０は、このユーザ評価情報を記憶部１５に記憶する。サーバ１０の制御部１１は、各ユーザから、各企業からのサービスを受けた場合のユーザ評価情報を、各企業の評価情報に反映することとしてもよいし、しなくてもよい。制御部１１は、ユーザ評価情報を受信する都度、企業の評価情報に反映させることとしてもよいし、させなくてもよい。また、あるいは、ユーザ評価情報の企業の評価情報への反映は、所定期間毎（例えば、１ヶ月毎）に実施されてもよいし、されなくてもよい。こうすることで、より現在時間に近い企業の生の情報を用いて、企業の評価をすることできる。

また、ここでは、企業に対する評価としているが、実際の作業をした担当者の評価を、送信することとしてもよく、その両方を送信することとしてもよいし、しなくてもよい。

＜実施形態の効果＞
以下、第１実施形態の効果について説明する。

上記第１実施形態に係る端末２０は、ユーザからユーザの情報としてユーザ自身を特定できない程度の情報（見積もり依頼、限定ではなく第１情報の一例）をサーバ１０に送信し、サーバ１０から見積もりに基づいて依頼を受ける企業サーバに関する情報の一例として評価情報を受信して表示する。

これにより、端末２０のユーザは見積もりを依頼する企業を決定する際に、自身で様々な情報の収集を行わずとも、企業の評判等の情報を視認することができるので、サービスを依頼する際の企業間の比較検討の際のユーザの手間を軽減することができる。

また、サーバ１０は、端末２０に対して、端末２０からの依頼に対する応答として、見積もりをする企業各々の評価情報を送信する。

これにより、サーバ１０は、端末２０のユーザに対して、企業のサービス等の評価に関する情報を伝えることで、ユーザに対して、サービスを依頼する企業を決定する際の補助となる情報を提供して、ユーザの利便性を向上させることができる。

また、端末２０は、各企業サーバとのトークルームにおいて、ユーザ自身の詳細情報の開示を承諾することによって、あるいは、ユーザ自身が詳細情報を送信することで、ユーザ自身の詳細情報がサーバ１０から、各企業サーバにユーザの更なる情報を送信する。

これにより、ユーザの更なる情報を、企業サーバに送ることで、企業サーバに詳細な見積もりをしてもらうことができる。

また、サーバ１０は、企業サーバ４０からのユーザの詳細情報の開示の依頼を受けると、ユーザの更なる情報を送信する。

これにより、サーバ１０は、企業サーバ４０が詳細な見積もりをする上での必要となる情報を提示することができ、企業サーバ４０の見積もり業務の利便性を向上させることができる。

また、端末２０は、サーバ１０から送信された企業の評価情報に基づいて、各々の企業の表示態様、即ち、文字色や文字の大きさなどを変更して表示することができる。例えば、各企業の評価の高さを示す情報の一例として、評価の高い企業の表示色を、評価の低い企業の表示色と変えて表示したりすることができる。

また、サーバ１０は、端末２０に対して、各企業の評価を示す表示情報を送信するように構成してもよい。

これにより、端末２０は、各企業の評価をその表示態様を変えることによって示すことができ、ユーザにその企業の評価を認識させることができる。

また、端末２０は、サーバ１０から送信された企業の評価情報に基づいて定まる表示順序にしたがって、各企業を示す情報を表示することとしてもよく、サーバ１０から端末２０に対して評価情報を送信する際に、その評価情報に基づく順序で各企業サーバ４０を示す情報を示した表示情報を送信することとしてもよい。

これにより、ユーザは、サービスを提供する企業が表示された順序に従って、各企業間の評価の高低を認識することができる。

また、端末２０は、サーバ１０から送信された評価情報に基づいて、所定の企業と比較して、評価の低い他の企業については、表示しないこととしてよい。

また、サーバ１０は、評価情報として、評価情報で示される評価に従って、見積もりをする予定の企業として表示するか否かを示す情報を含むようにして送信することとしてよい。

これにより、端末２０においては、評価が低いとされる企業については、表示しないようにすることで、ユーザがその企業に対する依頼をしないようにすることができる。したがって、ユーザが評価の低い企業に実際のサービスを依頼することでサービスを受けた際の不満が発生する可能性を抑制することができる。

また、各企業の評価を示す評価情報というのは、限定ではなく一例として、評価の高さの度合を示す情報（評価そのものを示す情報）であってもよい。

これにより、ユーザは直接かつ容易に各企業の評価を認識することができ、サービスを依頼する企業を決定するのに、分かり易い指標を得ることができる。

また、端末２０のユーザは、自身の詳細情報を開示してよいと判断した企業サーバ４０に対して送信する詳細情報を、サーバ１０に送信することとしてよい。また、サーバ１０は、端末２０から、直接ユーザの詳細情報を受信するように構成してよい。

これにより、ユーザとしては、その都度、サービスを提供する企業サーバ４０に対して開示する詳細情報を定めて送信することができる。また、サーバ１０は、サーバ１０がユーザの詳細情報を保持していない場合などには、ユーザの端末２０からこれを得ることで、企業サーバ４０に対して送信して、企業サーバ４０に見積もりを依頼することができる。

また、端末２０は、実際にその企業においてサービスを実施する担当者に関する情報として、担当者の評価を示す情報を受信することとしてよい。その担当者の評価を示す情報は、サーバ１０から、端末２０に送信することとしてよい。

これにより、ユーザは、自身が実際に接することになる担当者がどのような人物であるかを認識した上で、依頼をすることができるので、満足の高いサービスを受けることができる可能性が高くなる。

また、端末２０は、サーバ１０がおすすめする企業サーバ４０を、他の企業サーバ４０から区別して表示することができる。この、おすすめの企業サーバ４０は、端末２０のユーザの嗜好に合致する企業を、サーバ１０が選択する。

これによって、端末２０及びサーバ１０は、ユーザに対して、ユーザにとってより好適なサービスを提供する企業サーバ４０がどの企業であるかの情報を提供することができ、サービスを依頼する企業を選択する際のユーザの一助とする、即ち、判断材料を提供することができる。

また、端末２０は、ユーザが企業サーバ４０と交渉（取引）をするための情報をサーバ１０に送信する。そして、サーバ１０は、その交渉（取引）をするための情報を受信し、企業サーバ４０に送信する。取引を示す情報は、メッセージ（文字情報）であってもよいし、取引の内容を示す画像であってもよい。

これにより、ユーザは、端末２０を用いて、サーバ１０を介して、企業サーバ４０との間で、サービスを受ける上での取引をするための交渉を行うことができる。したがって、ユーザは、自身にとって、より好ましい条件でのサービスの提供を企業サーバ４０に対して依頼することができる。

また、ユーザは、端末２０からサーバ１０に、企業サーバ４０のサービスを享受した後に、ユーザ自身の所感である評価を示すユーザ評価情報を送信することとしてよい。なお、この評価は、実際に担当した企業サーバ４０の担当者の評価を示す情報であってもよいし、その両方であってもよい。

これにより、端末２０は、ユーザがサービスを受けたうえでのユーザ自身の企業あるいはその担当者に対する評価をサーバ１０に送信することができる。そして、サーバ１０は、その評価を受け取って、以降において、他のユーザに対して評価情報を提示する際に、その評価情報にユーザの評価を反映させて、よりリアルタイムの評価に関する情報を提供することができる。

また、端末２０は、各企業を示す一覧（例えば、企業名の一覧や、対応するトークの一覧）を表示する。そして、端末２０は、見積もりを行う各企業それぞれについて、自身の詳細情報を開示するか否かの選択をユーザから受け付ける。そして、端末２０は、詳細情報を開示しないと決定した企業サーバ４０との間の通信は、終了する。

これにより、ユーザにとって、不要となった企業との間の通信は終了することができ、以降、その企業との間の通信を行わずに済むので、例えば、取引を行わない企業からの営業活動などを受けずに済む。

また、端末２０は、各企業それぞれとの間でサーバ１０により立ち上げられたトークルームを介して、個別に交渉を行うことができる。

したがって、ユーザは、それぞれの企業との間で、他の企業とのやり取りやその状況を知られることなく、交渉を行うことができ、自身によって有利になるように取引を行うことができる。

また、端末２０は、サーバ１０との間のトークルームにおいて、リッチメニューを介して、取引を行う企業サーバ４０それぞれの情報を表示することとしてもよい。

これにより、サーバ１０が提供するサービスを享受するユーザ各々で異なった態様での情報の提供が可能になる。

＜第２実施形態＞
上記第１実施形態においては、ユーザが詳細情報を開示せずとも、ある程度の見積もりをしてもらい、信頼した業者に対して詳細情報を開示して、詳細な見積もりをしてもらうことができる例を説明した。これにより、ユーザの不必要な情報の拡散が防ぐことができ、業者による営業電話等の連絡が増加するのを抑制することができる。一方で、第１実施形態に示した見積もりをするシステムを利用する際に、実際の請求額との乖離が発生することがありえるが、サーバ１０ではそのような乖離があったとしても認識するすべはなく、また、企業側にとっても、上層部がそのような乖離を認識できていない可能性もある。

このような見積もりの乖離は、限定ではなく一例として、見積もりを取る段階で、業者（担当者）が仕事を受けたいがために、いたずらに見積もり額を抑えて、実際の請求時には、本来の金額で請求したり、あるいは、請求時に請求者が不当に多く請求したりしている場合などが考えられる。そのような見積もりと実際の請求との間の乖離は、ユーザの不満を生むことになり、結果として、企業の評判の低下にもつながるという問題を内包している。そこで、本第２実施形態においては、そのような見積もりと、実際の請求との乖離を抑制することができるシステムについて説明する。

なお、本第２実施形態における処理は、見積もりを行い、実際にサービスを依頼したあとで、サービス側が請求書を発行する前後からの処理となる。そのため、構成としては、第１実施形態の図１に示した構成と変わらないため、共通する機能、処理については、本第２実施形態における説明は割愛する。

＜構成＞
サーバ１０は、第１実施形態に示した機能に加えて、ユーザに対して、請求額の情報の提供を促す機能と、請求額の情報の提供をユーザから受けた場合に、何らかの特典を送信する機能とを有する。

制御部１１は、ユーザと企業との間で契約が成立した場合に、このユーザとのトークにおいて、企業からの請求額の情報の提供を促す機能として、ユーザとサーバ１０との間のトークルームに、企業から請求された金額に関する情報（限定ではなく一例として、金額の情報の直接の書き込みや、請求書のスキャンデータなど）の提示を依頼する文書を送信する。そして、その際には、請求された金額に関する情報を提示した場合には、ユーザに対して特典が与えられる旨も併せて通知する。

また、制御部１１は、ユーザとサーバ１０との間のトークルームに対して請求額についての情報が書き込まれた場合に、ユーザに対して特典を送信する。ここでいう特典は、ユーザにとって何らかの形で利得があるものであればなんでもよく、限定ではなく一例として、メッセージングアプリケーション上で利用できるポイント、他のサービスで金銭として利用可能なポイント、電子マネー、仮想通貨、何らかの物品、物品と引き換えるための引き換え券または電子引き換え券、または端末上でくじ引きが引けるサービスなどであってよく、これらの組み合わせであってもよい。また、特典としてポイントを送信するとは、メッセージングアプリケーション上でのユーザの識別子（ユーザＩＤ）に対応付けられているポイントに、特典に相当するポイントを加算することを意味する。同様に電子マネーを送信するとは、ネットワーク上でのユーザの識別子に対応付けられている電子マネーに、特典に相当する金額を加算することを意味する。仮想通貨を送信するとは、電子マネーの送信とほぼ同義であるが、ある定められたサービス内でのみ通用する金銭の代替物となる情報としての金額を、ユーザに対応付ける（加算する）ことを意味する。また、物品を送信するとは、物品をユーザに宛てて送付することを通知するとともに、ユーザの住所に宛てて、その物品を実際に送付することを意味する。また、物品と引き換えるための引き換え券または電子引き換え券を送信するとは、何らかの物品と引き換え可能であることを示す表示情報を送信することを意味する。引き換え券または電子引き換え券は、その物品を提供する店舗にその表示情報を提示することでその物品と交換が可能な情報（権利）である。また、端末上でくじ引きが引けるサービスを送信するとは、端末上で行う電子くじを引く権利をユーザに与えることをいう。ここでいう電子くじは、何らかの景品がもらえるものであり、一例として、サーバ１０が提供するメッセージングサービスにおいて使用可能なポイントや、何らかの電子情報（例えば、壁紙）、金銭、何らかの物品が当選するものであってよい。

一方、端末２０は、ユーザからの指示に基づき、企業サーバ４０から請求された請求額の情報の入力を入出力部２３を介して受け付けて、サーバ１０に送信する。請求額の情報の入力は、入出力部２３のタッチパネル２３１に対してユーザが直接金額を入力したものを受け付けることとしてもよいし、カメラ２３４が撮像した請求書の画像情報を受け付けるものであってもよい。端末２０の制御部２１は、通信Ｉ／Ｆ２２を介して、サーバ１０との間のトークルームに送信する。

また、端末２０の通信Ｉ／Ｆ２２は、サーバ１０から送信された特典を受信する機能を有する。制御部２１は、受信した特典情報を記憶部２８に記憶することとしてもよいし、しなくてもよい。

＜動作＞
図１３に示すシーケンス図を用いて、実施の形態２に係る通信システムにおける各装置間のやり取りについて説明する。図１３は、図５に示すシーケンス図の後の処理であり、図１３においては、図５のステップＳ５０８以降の処理を示している。

図１３に示すように、詳細な見積もりをうけとった端末２０のユーザは、その見積もり内容に納得がいった場合には、その企業サーバ４０にサービスの依頼（引越しの依頼）をする（ステップＳ１３０１）。また、ユーザは端末２０を用いて、サーバ１０との間のトークルームにおいて、決定した引越し業者を通知する（ステップＳ１３０２）。

引越し業者の決定の通知を受け付けると、サーバ１０は、ユーザに対して、請求書を要求する請求書要求を送信する（ステップＳ１３０３）。即ち、サーバ１０は、端末２０との間のトークルームにおいて、引越し後に企業サーバ４０から送信された請求書、又は、請求書で示される請求額の情報を、トークルームに送信を依頼する通知を行う。

実際に引越しを終えた後、企業サーバ４０は、端末２０に請求書を送付する（ステップＳ１３０４）。なお、図１３においては、企業サーバ４０から端末２０に送付するということで電子データの形で送付することとしているが、請求書は、別途郵送であってもよいし、ユーザに直接手渡しされるものであってもよい。なお、ステップＳ１３０３とステップＳ１３０４の処理は逆順で処理されてもよい。即ち、ステップＳ１３０４を先に実行し、その後にステップＳ１３０３を実行するように構成されてもよい。また、ステップＳ１３０３とステップＳ１３０４の処理は同時並行で実行されてもよい。

ユーザは、請求書を受け取ると、サーバ１０との間のトークルームを介して、請求情報を送信する（ステップＳ１３０５）。請求情報を送信するとは、トークルームに対して請求額を直接書き込むことであってもよいし、請求書の電子データを送信することであってもよいし、請求書の実物をスキャンしたデータを送信することであってもよい。

ユーザからの請求情報を確認したサーバ１０は、ユーザの端末２０に対して、予め定められた特典を送信する（ステップＳ１３０６）。

図１３に示すやり取りを実現するためのサーバ１０の処理について、図１４に示すフローチャートを用いて説明する。

サーバ１０の通信Ｉ／Ｆ１４は、業者決定情報を、ユーザの端末２０から受信する（ステップＳ１４０１）。通信Ｉ／Ｆ１４は、受信した業者決定情報を制御部１１に送信する。

業者決定情報を受信した制御部１１のメッセージ処理部１１２は、ユーザとの間のトークルームに対して、請求に関する情報を要求する請求書要求を送信する（ステップＳ１４０２）。

その後に、制御部１１は、ユーザから請求書情報を受信したか否かを判定する（ステップＳ１４０３）。制御部１１のメッセージ処理部１１２は、ユーザとの間のトークルームに請求書情報が送信されていた場合に（ステップＳ１４０３のＹＥＳ）、制御部１１は、ユーザに特典を送信して（ステップＳ１４０４）、処理を終了する。一方、ユーザが請求書情報を送信しなかった場合、即ち、請求書情報を受信しなかった場合（ステップＳ１４０３のＮＯ）には、ユーザに対しては特典を送信しないで、処理を終了する。ここで、請求書情報を受信しなかった場合とは、ユーザ自身から、請求額の情報を送信するつもりがないとの意思表示があった場合、もしくは、ユーザがサービスを受けてから所定時間が経過しても請求書情報を受信できなかった場合に、請求書情報を受信しなかった場合としてよい。以上が、サーバ１０の処理である。

図１５は、図１３のシーケンス図に示すやり取りを実現するための端末２０の処理を示すフローチャートである。

ユーザは、自身の端末２０から業者決定情報をサーバ１０に送信する（ステップＳ１５０１）。限定ではなく一例として、ユーザは、自身の端末２０を用いて、サーバ１０との間のトークルームを介して、業者決定情報を送信する。

業者決定情報の送信に応じて、端末２０の通信Ｉ／Ｆ２２は、サーバ１０から請求書情報の送付の依頼を受信する。通信Ｉ／Ｆ２２は、サーバ１０からの請求書情報の送付の依頼を受信すると、メッセージ処理部２１１に送信する。メッセージ処理部２１１は、受信した請求書情報の送付の依頼を示す文書情報をトークルーム上に示す情報を表示処理部２１２に表示するよう指示する。表示処理部２１２は、この指示を受けて、表示部２４に、請求書情報の送付の依頼を示したトークルームの画像を表示させる（ステップＳ１５０２）。

その後に、ユーザは、企業サーバ４０のサービスを受ける（例えば、引越しをする）。そして、ユーザの端末２０は、企業サーバ４０から請求書情報を受信する（ステップＳ１５０３）。なお、この請求書情報の受信は、上述の通り、手渡しであってもよいし、郵送であってもよい。

サービスを受けた企業サーバ４０から請求書を受け取ったユーザは、その請求書で示される請求額に関する情報を、通信Ｉ／Ｆを介して、サーバ１０に送信する（ステップＳ１５０４）。限定ではなく一例として、ユーザは、端末２０を用いて、ユーザとサーバ１０との間のトークルームを介して送信する。

通信Ｉ／Ｆ２２は、請求書情報の送信に応じてサーバ１０から送信された特典を受信して（ステップＳ１５０５）、処理を終了する。

＜具体例＞
ここから、本第２実施形態について、具体例を用いて説明する。図１６（ａ）、（ｂ）は、サーバ１０と端末２０との間のトークルームにおけるコンテンツ（メッセージ、スタンプ、画像、動画など）のやり取りの例を示す画面図である。

図１６（ａ）は、ユーザが直接請求額を書き込んだパターンを示しており、図１６（ｂ）は、請求書の写真（ユーザが端末２０のカメラ２３４を用いて請求書を撮像した撮像画像、もしくは、請求書のスキャンデータ）をトークルームに貼り付けたパターンを示している。

図１６（ａ）に示すように、ユーザは、各企業サーバ４０からの見積もりを見て、納得のいった業者との契約を果たす。その場合に、ユーザは、図１６（ａ）のメッセージ１６０１に示すように、サービスを受ける企業が決定した旨をトークルームに書き込む。図１６（ａ）に示す例では、ユーザは、サービスを提供する業者として「Ａ社」に決定したことを示している。

これに対して、サーバ１０は、ユーザに対して請求が発生したときの金額の情報の開示を要求するメッセージを送信する。図１６（ａ）では、メッセージ１６０２に示すように、サーバ１０（のオペレータ）が、最終の金額の提示を要求するとともに、請求額の提示をした場合に、特典、即ち、なんらかの報酬が与えられることを示すメッセージを書き込んだ例を示している。このメッセージ１６０２をサーバ１０が実行するタイミングとしては、ユーザからサービスを依頼する企業が決定したことを示す情報のメッセージ１６０１の送信があった後であればいつでもよいが、基本的には、メッセージ１６０１が送信されたすぐ後、あるいは、ユーザからサービスを受ける日時の情報をメッセージ１６０１で受けていた場合には、その日時の後であってもよい。

実際のサービスを受けた後、ユーザは、請求額についての情報を書き込む。図１６（ａ）に示す例では、メッセージ１６０３に示すように、請求額がＸＸＸＸＸＸ円であったとの書き込みを行った例を示している。

このユーザが書き込んだメッセージ１６０３に対して、サーバ１０は、特典が送信される旨のメッセージ１６０４の書き込みを行い、実際に特典を送信する。

このようにして、ユーザはサーバ１０との間で請求額のやり取りを行う。なお、図１６（ｂ）と、図１６（ａ）との差異は、メッセージ１６０３と画像１６１３との差異のみであり、図１６（ｂ）の例では、画像１６１３として、請求書の画像データをトークルームに貼った点で異なり、それ以外については、共通する。

このようにして、サーバ１０は企業サーバ４０が実際に行った請求の額面を認識することができる。なお、ここでは、ユーザから直接請求額の情報を受信することとしているが、ユーザが、例えば、メッセージングアプリケーションで使用できる仮想マネー、またはポイント決済を利用した取引を利用して、企業サーバ４０に対する支払いを行った場合には、その支払い情報を参照して、請求額に関する情報を、ユーザから聞かずとも、取得することができる。なお、サーバ１０を介して電子取引を行った場合にその請求額の情報をサーバ１０が取得する条件として、ユーザから予め許可を得ているか、トークルーム上で請求額の確認を行ってもよいとの許可を求めてその許諾を得ているか、していることが望ましい。

＜見積もり額まとめ通知＞
上記第１実施形態及び第２実施形態においては、各企業サーバ４０は、各々個別にユーザとの間で立ち上げられたトークルームを介して、見積もりについてのやり取りを行うこととしているが、企業サーバ４０によっては、いち早く安めの見積もりを出して、依頼を受けようとする企業サーバ４０が存在する可能性がある。そのような場合、その見積もりを見たユーザは、その安さに他の企業サーバ４０からの見積もり連絡を待たずに依頼をしてしまう可能性がある。

そこで、企業サーバ４０が一端各企業サーバ４０からの見積もりを収集し、一定数の見積もりが得られたところで、まとめてユーザに見積もり額を通知するという構成を採ってもよいし、採らなくてもよい。

具体的には、サーバ１０は、図１７に示すように動作してもよい。図１７に示す処理は、ユーザの端末２０から見積もりを受け付けて、各企業サーバ４０からの見積もりが後に送付される旨の通知を行った後の処理になる。

図１７に示すように、サーバ１０の通信Ｉ／Ｆ１４は、業者、即ち、各企業サーバ４０から、ユーザが行った見積もり依頼に対して行った見積もりの額を示す見積もり情報を受信する（ステップＳ１７０１）。通信Ｉ／Ｆ１４は、受信した見積もり情報を制御部１１に送信する。制御部１１は、受信した見積もり情報を、その見積もり情報を送信した企業サーバ４０を示す識別情報と対応付けて記憶部１５に記憶する。

制御部１１は、見積もり情報を受信すると、ユーザに対して見積もりを行う複数の企業サーバ４０のうち、所定数以上の企業サーバ４０から見積もり情報を受信しているか否かを判定する。即ち、制御部１１は、ユーザの見積もり依頼に対して企業サーバ４０から送付され、記憶部１５に記憶されている見積もり情報の数が、所定数以上であるか否かを判定する（ステップＳ１７０２）。ここで、所定数は、ユーザが見積もり額の比較検討を行えるだけの数があればよいので、少なくとも２個であればよく、見積もりを行う企業サーバ４０の総数と一致することとしてもよい。

見積もり情報の総数が所定数以上でない場合には（ステップＳ１７０２のＮＯ）、ステップＳ１７０１の処理に戻り、次の、見積もり情報の受信まで待機する。見積もり情報の総数が所定数以上である場合には（ステップＳ１７０２のＹＥＳ）、制御部１１は、それらの見積もり情報を纏めて、ユーザとのトークルームに、企業サーバ４０各々の見積もり額を比較が可能なように送信する（ステップＳ１７０３）。ここで、見積もり情報を纏めて送信とは、トークルーム上に、各見積もり情報で示される金額を直接ユーザとの間のトークルーム上に、サーバ１０が書き込むものであってもよいし、見積もり情報そのものを順にトークルームに送信することであってもよい。

これにより、サーバ１０は、見積もりを行う何れかの企業サーバ４０が、他の企業サーバ４０が先駆けて安い見積もりを行って、依頼を受けることができるのを防止できる。また、サーバ１０は、ユーザにどの企業サーバ４０に依頼をするかの検討を、見積もり額に基づいて行う機会を与えることができる。

図１８は、所定数の企業サーバ４０からの見積もりを受信した場合に、ユーザが見ることができるトークルームの画面例を示す図である。図１８では、メッセージ１８０１に示すように、Ａ社と、Ｄ社と、Ｅ社との３社からの見積もり額を纏めて、ユーザに対して送信したことが理解できる。図１８の例では、Ａ社がＸＸＸＸＸＸ円、Ｂ社がＹＹＹＹＹＹ円、Ｃ社がＺＺＺＺＺＺ円である例を示している。このとき、各企業が行った見積もり額の降順（あるいは昇順）で、各企業の企業名（識別情報）と、その見積もり額を表示してもよいし、しなくてもよい。

なお、図１８では、メッセージ１８０１をサーバ１０が行って、複数の企業サーバ４０からの見積もり額を並列することとしているが、これは、各企業サーバ４０がそれぞれ送付した見積もり情報をそのまま順番に送信することで実現されてもよい。

また、ここでは、詳細には記載しないが、上記第１実施形態に示した態様は、第２実施形態にも適用することとてもよいし、しなくてもよい。

例えば、図１１（ａ）に示したリッチメニューを利用したユーザとサーバ１０との間のやり取りは、本実施形態にも適用可能であり、本実施形態であれば、限定ではなく一例として、リッチメニューとして、見積もり額に係る情報を送信するための送信ボタン、請求額に係る情報を送信するための送信ボタンが設定されたリッチメニューを用いることができる。これらの送信ボタンを押すことにより、例えば、ユーザの端末２０内の記憶部２８に記憶された見積もり額の情報（データファイル）や、請求書の情報（データファイル）を指定することで、サーバ１０に対して、それらの情報が送信される構成になっていてよく、その場合に、ユーザの入力の手間を軽減することができる。

また、本第２実施形態においても図１１（ｂ）に示したように、ユーザ又はサーバ１０（のオペレータ）は、見積もり額および請求額に係るやり取りにおいて、メッセージングサービス上で利用可能な画像情報（スタンプ）を用いたやり取りをしてもよいし、しなくてもよい。限定ではなく一例として、サーバ１０は、ユーザが請求額の情報をトークルームに送信した場合に、感謝の意を表す画像情報を送信することとしてもよい。

また、端末２０は、請求額の送付とともに、請求額に係るユーザの企業サーバ４０に対する評価を含むユーザ評価情報を、サーバ１０に対して送信することとしてもよい。

＜第２実施形態変形例＞
（１）上記第２実施形態においては、サーバ１０が端末２０に対して特典を送信するところまでで処理を留めている。しかしながら、サーバ１０は、更に、企業サーバ４０が行った請求額の情報を受信したことにより以下の処理を実行してもよい。即ち、サーバ１０は、請求額が見積もり額から、一定金額以上乖離していた場合に、その企業の評価情報を補正することとしてもよい。

例えば、サーバ１０の制御部１１は、請求額から見積もり額を減算した差分が、所定額よりも大きい場合には、請求額の方が見積もり額よりもかなり多いとして、企業サーバ４０の評価情報を下げる補正をしてもよいし、しなくてもよい。また、サーバ１０の制御部１１は、請求額から見積もり額を減算した差分が、所定額よりも小さい場合には、見積もり額の方が請求額よりもかなり少ないとして、見積もりよりも少ない金額での請求を行う企業であるとして、企業サーバ４０の評価情報を上げる補正をしてもよい。評価情報の上げ下げは、評価情報が数値やレベル等で設定されていれば加減算により実行することができる。また、文章による評価情報を追加することもできる。

（２）上記第２実施形態においては、サーバ１０は、ユーザの端末２０から請求額の情報を受信することとしているが、これは、企業サーバ４０から受信するものであってもよい。また、端末２０と企業サーバ４０との双方から、請求額の情報を受信することとしてもよい。

（３）上記第２実施形態においては、サーバ１０の制御部１１は、所定数の見積もりが到来するまでは、待機し、所定数の見積もりを受信すると、まとめて端末２０に送信する構成としたが、これはその限りではない。見積もりの数ではなく、時間によって、見積もりを送信することとしてもよい。即ち、サーバ１０の制御部１１は、各企業サーバ４０に対して見積もり依頼を送信してから、所定時間（例えば、４８時間）を計測する。そして、所定時間が経過すると、その時点で受信している見積もりの情報を、見積もり情報の数に関わりなく全て端末２０に送信するように構成されてもよい。また、所定時間の経過を待って見積もり情報を端末２０に送信する場合には、サーバ１０がそれらを纏めて送信してもよいし、纏めて送信しなくてもよい。

（４）上記実施の形態２においては、サーバ１０は、ユーザの端末２０から請求額に関する情報を送信してもらうことによって、企業サーバ４０が実際に行った請求に関する金額の情報を得ていたが、これはその限りではない。サーバ１０が、電子マネー等による支払いの支払いサービスを有し、端末２０がその支払いサービスを利用して、企業サーバ４０に対して支払いを行った場合には、サーバ１０は、自動的に、端末２０から企業サーバ４０に対してされた支払い額を、請求額に関する情報として取得することとしてもよい。この場合、端末２０と、企業サーバ４０と、から支払額の情報をサーバ１０が取得することについて了承を得ていることが望ましい。

（５）上記実施の形態１又は２において、サーバ１０の制御部１１は、見積もりをする企業サーバ４０各々について、その企業サーバ４０が請求する請求額を予測し、予測した請求額に関する予測請求額の情報を端末２０に送信してもよいし、しなくてもよい。制御部１１は、各企業サーバ４０について、過去に行ったサービスと、サービス内容の情報、そして、その際の請求額の情報を記憶部１５に記憶する。これらの情報は、サーバ１０がアクセス可能な外部の装置に記憶されていてもよい。

制御部１１は、ユーザが行う見積もり依頼に対して、その内容と所定以上の相関を有するサービス内容の情報を有するデータを、見積もりを行う企業ごとに取得する。そして、相関の高いサービス内容が実行された際に、企業サーバ４０が行った請求の額を、請求額の予測値である予測請求額として、新たに見積もり依頼をしてきたユーザに対して、送信することとしてもよい。複数の相関の高いデータが取得できた場合には、例えば、その平均値を、請求額の予測値である予測請求額として、送信することとしてもよいし、複数の請求額の中で最も高い金額、あるいは、最も安い金額を、予測請求額として、ユーザの端末２０に送信することとしてもよい。なお、請求額の予測の手法はこれに限るものではなく、様々な手法を用いることができ、サーバ１０のオペレータが好適と判ずる予測方法を用いるとよい。その他の手法としては、限定ではなく一例として、例えば、制御部１１は、企業ごとに、その企業が過去に提供したサービスの内容と、請求した請求額に基づいて、サービスの内容から請求額を学習した学習モデルを構築し、その学習モデルに対して、ユーザが行った見積もり依頼を入力して、請求額を算出することとしてよい。

制御部１１は、ユーザが見積もり依頼を行った後、各企業から見積もり情報が送信された後（される前でもよい）であって、ユーザが実際にサービスを依頼する企業を決定する前に、端末２０に対して、算出した予測請求額の情報を送信する。そして、端末２０は受信した予測請求額の情報を表示部２４に表示する。このとき、端末２０は、企業サーバ４０が送信した見積もり情報と、サーバ１０が予測した予測請求額とを併せて比較可能に表示部２４に表示することとしてもよいし、しなくてもよい。また、予測請求額はサーバ１０による予測額である旨を示す情報を併せて表示してもよいし、しなくてもよい。また、予測請求額に代えて（あるいは共に）、予測請求額と見積もり額との差分を表示してもよい。このように、サーバ１０は、予測される請求額をユーザに、サービスを依頼する企業を決定するための判断材料として提供することとしてもよい。

＜実施形態の効果＞
上記第２実施形態において、端末２０のユーザは、企業サーバ４０から見積もりを受領したうえで、サーバ１０に対して、企業サーバ４０からのサービスを受けた後に、企業サーバ４０から請求された請求額の情報を送信する。サーバ１０は、その請求額の情報を受信する。

これにより、サーバ１０は、企業サーバ４０が行った見積もりと、請求とのそれぞれの額面に関する情報を取得することができる。したがって、サーバ１０は、企業サーバ４０が行っている見積もりと請求との間に、乖離があるか否かを認識することができる。よって、限定ではなく一例として、見積もりと請求との間に乖離がある場合には、その企業サーバ４０の評価を下げたりすることができる。
また、評価としては、「見積もりよりも請求の方が多くなることがある」といった文書による評価を追加することとしてもよい。この場合、より多くの企業の評価に関する情報をユーザは取得することができる。したがって、ユーザはサービスを提供する企業を決定する場合の根拠となる情報をより多く取得することができる。

また、端末２０は、ユーザからの指示に従って、カメラ２３４を用いて、企業サーバ４０から送信された請求書を撮像した画像を、請求された金額に関する情報として送信する。また、サーバ１０は、端末２０から、請求書を撮像した画像を、企業サーバ４０が請求した金額に関する情報として受信する。

これにより、サーバ１０は、請求書の確かなエビデンスとして、請求された金額に関する情報を得ることができる。

また、サーバ１０は、端末２０から企業サーバ４０から請求された金額に関する情報を受信すると、端末２０（のユーザ）に対して、特典に関する情報を送信する。そして、端末２０は、サーバ１０から送信された特典に関する情報を受信する。

これによって、サーバ１０は、端末２０に対して、請求額に関する情報を提供することに対する謝礼を贈ることができる。

また、端末２０は、サーバ１０を介して、企業サーバ４０に送金をする。即ち、サーバ１０が電子商取引による金銭等のやり取りを実行する機能を有する場合に、端末２０から企業サーバ４０に対する支払額を請求額の情報として取得することができる。

これにより、サーバ１０は、ユーザから請求額に関する情報を受け取ることなく、即ち、ユーザの手を煩わせることなく、企業サーバ４０から端末２０に対して請求された請求額の情報を取得することができる。

また、サーバ１０は、過去の企業サーバ４０が行った請求と、その際に提供したサービスの情報とを参考に、新たなユーザからの見積もり依頼に対して、実際に企業がそのサービスを提供したとするときの請求額を予測し、その予測額をユーザの端末２０に送信する。端末２０は、その予測額の情報を受信し、表示部２４に表示する。

これにより、端末２０及びサーバ１０は、ユーザに対して、サービスを依頼する企業を決定するときの更なる判断材料を提供することができるので、ユーザのサービスを利用する上での利便性を向上させることができる。

また、サーバ１０は、ユーザからの見積もり依頼を企業サーバ４０に送信してから、所定時間の経過を待たずに企業サーバ４０から見積もり情報を受信した場合には、その所定時間が経過するまでは、その見積もり情報を端末２０に送信しない。そして、所定時間が経過したら、サーバ１０は、その時点で企業サーバ４０から受信している見積もり情報を端末２０に送信する。したがって、端末２０は、見積もり依頼を行ってから定められた所定時間後に最初の見積もり情報を１以上受信する。
また、サーバ１０は、所定数の見積もり情報を企業サーバ４０から受信するまでは、見積もり情報を企業サーバ４０から受信したとしても端末２０に送信せず、所定数以上の見積もり情報を受信して初めて、端末２０にまとめて送信するように構成してもよい。

この構成によれば、サーバ１０が一端、見積もり額の情報を預かることにより、複数の見積もり依頼先の企業サーバ４０からの見積もり額を、最初に受信する時点で端末２０において比較することができる可能性を高くすることができる。したがって、ある企業サーバ４０が、実際に請求する請求額よりも安く見積もり情報をいち早く送信し、ユーザが、その企業に依頼して、サーバ１０に対して不満を抱く可能性を低減することができる。

また、端末２０は、サーバ１０から送信された各企業サーバ４０からの見積もり情報を纏めた画像情報を表示するように構成してもよいし、画像ではなく文字情報であってもよい。

これにより、ユーザは、各企業が行った見積もりの額面の比較を容易に行うことができる。

また、端末２０は、サーバ１０からまとめて送信された複数の企業サーバ４０からの見積もり情報を受信して、その見積もり情報の見積もり額で示される順序で、表示部２４に表示する。

これにより、ユーザは、どの企業が一番安く見積もったのか、あるいは、一番高く見積もったのかを、一目で認識することができる。

また、端末２０は、ユーザが企業サーバ４０と行った交渉（取引）の情報をサーバ１０に送信する。ここで、取引を示す情報は、メッセージ（文字情報）であってもよいし、取引の内容を示す画像であってもよい。

これにより、ユーザは、端末２０を用いて、企業サーバ４０との間でメッセージや画像を用いて行った取引に係る情報を、サーバ１０に伝達することができる。そして、サーバ１０は、ユーザと企業サーバ４０間で行われた取引の情報を得ることができるので、例えば、企業サーバ４０の評価をすることができる。

また、ユーザは、端末２０からサーバ１０に、企業サーバ４０のサービスを享受した後に、少なくとも請求額に係るユーザ自身の所感である評価を示すユーザ評価情報を送信することとしてよい。なお、この評価は、実際に担当した企業サーバ４０の担当者の評価を示す情報であってもよいし、その両方であってもよい。

＜第３実施形態＞
上記第１実施形態及び第２実施形態においては、ユーザが受けたいサービスを受ける際に、ユーザにとってより好適な企業サーバ４０を選択できるシステムについて説明した。本第３実施形態においては、サーバ１０が提供する機能として、企業サーバ４０側にとってメリットとなる構成を説明する。なお、上記第２実施形態と同様に、各機器の構成については、第１実施形態と共通するので、上記第１実施形態及び第２実施形態と異なる構成について説明し、共通する構成の説明については、省略する。

＜構成＞
第３実施形態に係るサーバ１０は、ユーザだけでなく、企業サーバ４０にとって有益となる情報を送信する。即ち、サーバ１０は、見積もり依頼時に、企業サーバ４０にとって、ユーザの依頼との相性がよさそうであれば、その旨を通知する。ここで、相性がよいというのは、企業サーバ４０がユーザの嗜好に合致する仕事をすることができる、企業サーバ４０の得意とする分野がユーザの依頼に合致する、などを意味するものであってもよいし、そうでなくてもよい。企業サーバ４０がユーザの嗜好に合致するというのは、ユーザの好みとして、例えば、値段、品質、速度、依頼先の働きぶり（例えば、積極的にユーザに話しかけながら仕事をする、寡黙に職人気質に仕事をする等）や、対応のよさなどが、企業サーバ４０とのサービスを提供する上での特色に合致することを意味する。ここで、ユーザの好みの値段とは、即ち、コストパフォーマンスの高さを好むのかどうかを示す。また、ユーザの好みの品質とは、品質、即ち、サービスの内容（質）の良さを好むのかどうかを示す。また、ユーザの好みの速度とは、仕事の早さを重視するか否かを示す。さらには、ユーザの好みとは、値段や、品質、速度といった好みのうち、いずれを優先するのかを示す情報であってもよいし、そうでなくてもよい。

このような態様を実現するために、サーバ１０の制御部１１は、記憶しているユーザ情報２００には、更に、ユーザの嗜好、趣味など、図２に示す以外の情報を含んでいてもよいし、そうでなくともよい。含んでいれば、よりユーザとの相性のよい企業サーバ４０の選定がしやすくなるが、含んでおらずとも、図２に示すユーザ情報２００のみからでも企業サーバ４０との得意とする分野との一致から、相性のよさを判断することができる。

また、更には、サーバ１０の制御部１１は、企業サーバ４０にとって有益な情報の提供として、見積もり依頼を行ったユーザと、他の見積もり依頼を行っている他のユーザとの関連性を鑑みたマッチングも行う。他のユーザとの関連性を鑑みたマッチングとは、企業サーバ４０が実際にサービスを提供する上で他のユーザの依頼と、新たな見積もり依頼を行ったユーザの依頼との間の関連性の度合の高低（相関の高低とも言える）に基づくマッチングを行うことをいう。限定ではなく一例として、企業サーバ４０が引越し業者の場合には、依頼として、どの地域からどの地域への引越しが一致したり、引越し元が一致したりしたら、関連性が高いと判定することとしてよい。また、そのうえで、依頼の日付（引越しの希望日）が一致したりすれば、更に関連性が高いと判定することもできる。関連性が高い場合には、ユーザからその企業サーバ４０に対して実際に依頼する可能性が高いといえる。

このような構成を実現するために、サーバ１０の制御部１１は、ユーザの依頼と、企業サーバ４０との間のマッチングを行う機能を有する。具体的には、ユーザからの見積もり依頼を受信した際に、その見積もり依頼を行ったユーザのユーザ情報を記憶部１５から読み出す。また、併せて、後述する記憶部１５に記憶されている企業サーバ４０各々の特色を示す情報である企業情報２１００を読み出す。そして、制御部１１は、見積もり依頼を行ったユーザのユーザ情報と、企業情報２１００で示される各企業各々の特色それぞれとから、相性のよさを判断する。限定ではなく一例として、ユーザ情報と企業情報との関連しあう項目それぞれについての相関値を算出し、その相関値が所定閾値を超えるか否かで相性がよいか否かを判定することができる。

企業サーバ４０は、サーバ１０から依頼情報３００を受信する。そして、受信した依頼情報３００を表示部４３に表示する。このとき、サーバ１０が相性がよいと判定したユーザについては、他のユーザとは異なる表示態様で、おすすめ、即ち、依頼（取引）をする可能性が高いことを示したり、おすすめである旨を示す文字情報を表示したりしてもよい。また、サーバ１０から企業サーバ４０に対するおすすめのユーザについての情報は、企業サーバ４０と、サーバ１０との間のトークルームで表示することとしてもよい。おすすめであるか否かは、企業サーバ４０から見て、ユーザの評価を示す情報となる。図１９には、依頼情報３００に、ユーザについての評価情報を含ませる例として、おすすめ度１９０１を含ませた例を示している。おすすめ度１９０１は、サーバ１０から見た、企業サーバ４０に対するユーザのおすすめの度合を示す情報であり、企業サーバ４０から見た対応するユーザの評価情報のことである。図１９に示す例では、おすすめ度を数値で示しているが、これは、Ａ、Ｂ、Ｃ等のランクで示されるものであってもよいし、単純におすすめか否かを示す２値の値であってもよい。企業サーバ４０のオペレータは、図１９に示すような依頼情報３００を見ることで、見積もりを送信する（サービスを提供してもよいと判断できる）ユーザを決定することができる。なお、ユーザがおすすめかどうかについては、サーバ１０と企業サーバ４０との間のトークルーム上で、サーバ１０から企業サーバ４０に対して通知されてもよい。即ち、図２０（ａ）、（ｂ）に示すように、ユーザの評価を示す情報と企業サーバ４０に対して提供するようにしてもよい。図２０（ａ）は、ユーザの評価を星印でトークルーム上に表示した例であって、企業サーバ４０の表示部４３に表示したトークルームの画面例を示す図である。また、図２０（ｂ）は、ユーザの評価としておすすめである旨を直接示したトークルームの画面例を示す図である。図１９や図２０に示したように、企業サーバ４０は、表示部４３に、サーバ１０から送信されたユーザの評価を示す評価情報を表示することができる。

＜データ＞
図２１は、企業サーバ４０と、ユーザとのマッチング（相性のよさ）を判定するために用いるデータであって、企業サーバ４０各々の特色を示す企業情報２１００の一例を示すデータ概念図である。企業情報２１００は、記憶部１５に記憶されていてもよいし、サーバ１０がアクセス可能な外部装置に記憶されていてもよい。

図２１に示すように、企業情報２１００は、企業名２１０１と、電話番号２１０２と、所在地２１０３と、得意地域２１０４と、得意人数２１０５と、企業特性２１０６とが対応付けられた情報である。企業名２１０１以外の情報については、企業情報２１００に含まれていてもよいし、含まれていなくてもよい。なお、図２１に示す企業情報２１００は、各企業が引越し業者である場合の例を示しており、他の業種であれば、他の業種に応じた項目の情報が含まれていてもよい。

企業名２１０１は、一意に対応する企業サーバ４０を特定するための識別情報である。企業名に代えて、企業サーバ４０の他の識別子を用いることとしてもよい。

電話番号２１０２は、対応する企業名２１０１で示される企業との連絡に用いる電話番号を示す情報である。

所在地２１０３は、対応する企業名２１０１で示される企業の居所を示す情報である。

得意地域２１０４は、対応する企業名２１０１で示される企業が、サービスを提供する上で得意とする地域を示す情報のことであり、企業サーバ４０が引越し業者である場合には、引越し作業をするにあたって得意とする地域、例えば、企業からの近くの地域や、企業の引越し用のトラックを格納している車庫の近くの地域や、トラックを運転する運転手が土地勘を有する地域を示す情報等のことである。

得意人数２１０５は、対応する企業名２１０１で示される企業が、サービスを提供する上で得意とするユーザ側の人数のことを示す情報のことである。企業サーバ４０が引越し業者である場合には、引越しを実行するユーザが何人の世帯の引越しを行うのが得意なのか（例えば、一人暮らし専門とか、４人家族、２世帯家族であるとかなど）を示す情報である。

企業特性２１０６は、上述した以外の対応する企業名２１０１で示される企業の特色（属性）を示す情報である。企業特性２１０６は、企業の特性であればどのような情報であってもよく、コストパフォーマンスのよさ、サービスの品質、サービス提供までの速度や、サービスを提供する上での企業としての姿勢などであってよい。図２１に示した例では理解しやすくするために、文章で企業特性２１０６を示しているが、これは、各企業について各種の項目（限定ではなく一例として、コストパフォーマンス、品質、速度など）ごとにその項目の企業の程度（レベル）を示す情報が対応付けられた情報で表現されてもよい。

図２１の例では、企業名２１０１が「Ｂ社引越し本舗」で示される企業は、電話番号が０８０－ＸＸＸＸ－ＸＸＸＸであり、住所が、東京都品川区五反田にあり、サービスを提供するにあたって得意とする地域は、関東全域であり、得意人数が２～８人であり、迅速対応を旨としていることが理解できる。

サーバ１０は、主として、得意地域２１０４、得意人数２１０５、企業特性２１０６等の情報を用いて、依頼を行うユーザとの相性のよさ（おすすめとするかどうか）を判断する。なお、サーバ１０は、これらの情報全てを用いて、相性を判断してもよいし、全てを用いずに相性を判断してもよい。

＜動作＞
図２２には、サーバ１０が企業サーバ４０にとって、相性がよいと推測されるユーザを紹介するときの各装置間のやり取りを示すシーケンス図であり、ユーザが見積もり依頼を行ってから、企業サーバ４０からおおよその見積もりを受け取るまでの流れを示している。

図２２に示すステップＳ５０１とステップＳ５０４とは、図５を用いて示したシーケンス図におけるステップＳ５０１とステップＳ５０４と同一であり、説明を省略する。

ユーザの端末２０から、見積もり依頼を受信するとサーバ１０は、その見積もり依頼で示されるユーザの希望と、企業サーバ４０とのマッチングを実行する（ステップＳ２２０１）。即ち、サーバ１０は、ユーザの依頼と、相性のよさそうな企業サーバ４０を特定する。逆に言えば、企業サーバ４０にとって、相性のよい、おすすめのユーザを特定する。ここでいうおすすめのユーザを特定するとは、企業サーバ４０から見ておすすめのユーザであるか、あるいは、ユーザがどれだけおすすめかを示す指標を特定することの少なくともいずれか一方を含む。

サーバ１０は、マッチングにより決定したユーザの評価情報を含む依頼情報を、企業サーバ４０に送信する（ステップＳ２２０２）。この依頼情報は、複数のユーザからの依頼が含まれてもよいし、含まれなくてもよい。なお、このとき、サーバ１０は、ユーザの端末２０に対して、後ほど、企業サーバ４０から、おおよその見積もり額が通知される旨を連絡することとしてもよいし、しなくてもよい。

企業サーバ４０のオペレータは、サーバ１０から送信された依頼情報を見て、ユーザからの依頼を受けるかどうかを判断し、見積もりを送信するか否かを決定する（ステップＳ２２０３）。そして、見積もりを送信すると決定したユーザについて、そのユーザの見積もり依頼の内容からおおよその見積もり額を算定する。企業サーバ４０は、算定した見積もり額と、どのユーザからの見積もり依頼に対する見積もり額が特定可能な情報とをサーバ１０に送信する（ステップＳ２２０４）。

サーバ１０は、企業サーバ４０から見積もり額と、どの依頼に対する見積もり額であるかを示す情報を受信すると、その依頼を行ったユーザと企業サーバ４０との間のトークルームを開設し、そのトークルーム上に企業サーバ４０からの見積もり額を掲載して、端末２０に送信する（ステップＳ２２０５）。ステップＳ２２０４、Ｓ２２０５の処理は、図５におけるステップＳ５０４の処理に相当する。このようにして、企業サーバ４０（のオペレータ）は、１以上のユーザからの依頼について、そのユーザの評価から見積もり依頼を出すか（サービスを提供してもよいか）を判断することができる。なお、図２２においては、ステップＳ２２０４、Ｓ２２０５に示すように、サーバ１０を経由して、見積もり額の情報を企業サーバ４０から端末２０に送信することとしているが、これは、直接、企業サーバ４０から端末２０に送信されるものであってもよい。

次に、図２２に示す処理を実現するための、サーバ１０の処理について、図２３を用いて説明する。図２３は、図２２に示すステップＳ２２０１～Ｓ２２０５の処理を実現する際の、動作であって、図７に示したフローチャートにその処理を組み込んだフローチャートを示している。したがって、ここでは、図７を用いて説明した処理内容については、説明を簡略化し、図７と異なる点について詳細に説明する。

図２３に示すように、サーバ１０は、端末２０からの見積もり依頼を受信する（ステップＳ７０１）。

制御部１１は、依頼済みの他案件との相関があるか否かを判定する（ステップＳ２３０１）。制御部１１は、ステップＳ７０１で示される見積もり依頼の内容から、他のユーザから依頼されている見積もり依頼の内容との一致度合いから相関があるかを判定する。制御部１１は、依頼済みの他案件と相関があると判定した場合には（ステップＳ２３０１のＹＥＳ）、ユーザ情報２００で示される内容と、企業情報２１００で示される内容とから、マッチングを行って、依頼済みの他案件との相関があったことによる評価の上方修正を行った企業サーバ４０にとってのユーザの評価を決定し（ステップＳ２３０２）、ステップＳ２３０４の処理に移行する。限定ではなく一例として、ユーザの特性として、コストパフォーマンスに対する嗜好、サービスの品質に対する嗜好、サービスを提供する速度に対する嗜好とが設定されており、同様に企業サーバ４０の企業特性２１０６として、コストの評価、サービス品質の評価、サービスの提供速度の評価が設定されている場合に、それぞれの項目でユーザの嗜好を満たしているか否か、満たしている場合にその度合がどの程度であるかを算出し、その評価を統合することで企業サーバ４０にとってのユーザの評価を決定することができる。このとき、単純におすすめかどうかを決定する場合には、その評価が所定の閾値を超えているか否かで決定することができる。また、他の例としては、ユーザの特性（嗜好）１つ１つについて、企業サーバ４０がそれぞれを満たすか否かを判定し、満たした数を企業サーバ４０にとってのユーザの評価としてもよい。一方で、制御部１１は、依頼済みの他案件と相関がないと判定した場合には（ステップＳ２３０１のＮＯ）、制御部１１は、ユーザ情報２００で示される内容と、企業情報２１００で示される内容とから、マッチングを行って、企業サーバ４０にとってのユーザの評価を決定する（ステップＳ２３０３）。制御部１１は、通信Ｉ／Ｆ１４を介して、ユーザの評価情報を含む依頼情報３００を、企業サーバ４０に送信する（ステップＳ２３０４）。

制御部１１は、通信Ｉ／Ｆ１４が、企業サーバ４０からおおよその見積もり額の情報を受信したか否かを判定する（ステップＳ２３０５）。おおよその見積もり額の情報を受信するまでは待機する（ステップＳ２３０５のＮＯ）。通信Ｉ／Ｆ１４が、企業サーバ４０からおおよその見積もり額の情報を受信した場合には（ステップＳ２３０５のＹＥＳ）、制御部１１は、企業サーバ４０と、その見積もり額に対応する見積もり依頼を行ったユーザとの間にトークルームを開設する。そして、制御部１１は、そのトークルーム上に、企業サーバ４０から受信した見積もり額の情報を送信する（ステップＳ２３０６）。その後に、ステップＳ７０４の処理に移行する。このステップＳ２３０１からステップＳ２３０５の処理が、図７に示すステップＳ７０２からステップＳ７０３の処理に代えて実行される処理となる。

＜マッチング処理の具体例＞
企業サーバ４０が引越し業者である場合に、サーバ１０が見積もり依頼間の相関を見る際の処理手法について具体的に説明する。

図２４（ａ）は、あるユーザＵ１からＵ１ａからＵ１ｂに示される経路２４０１での見積もり依頼が既にある企業Ａに見積もり依頼が行っている状況であるとする。この経路２４０１の見積もり依頼に対して、ユーザＵ１は、企業Ａに対して依頼をすることを決定していてもよいし、決定していなくてもよい。そのような状況下において、新たな見積もり依頼がユーザＵ２からサーバ１０に送信されたとする。

このとき、サーバ１０が、ユーザＵ２の見積もり依頼の内容から、引越しの内容としてＵ２ａからＵ２ｂまでの経路２４０２で示される引越しの依頼であることが認識できたとする。サーバ１０の制御部１１は、経路２４０１と経路２４０２との間の相関値を算出する。即ち、制御部１１は、経路２４０１と経路２４０２とが、位置とその経路の形状とがどれだけ近しいかを算出する。そして、その相関値が予め定めた閾値よりも高い場合であって、引越しの希望日が一致するようなときには、ユーザＵ２からの見積もり依頼は、ユーザＵ１の見積もり依頼を送信した企業である企業Ａとのマッチングを決定する。即ち、制御部１１は、企業Ａに対してユーザＵ２からの見積もり依頼を送信することを決定する。

また、同様に、図２４（ｂ）に示すように、ユーザＵ１からＵ１ａからＵ１ｂに示される経路２４１１での見積もり依頼が既にある企業Ａに見積もり依頼が行っている状況であるとする。この経路２４１１の見積もり依頼に対して、ユーザＵ１は、企業Ａに対して依頼をすることを決定していてもよいし、決定していなくてもよい。そのような状況下において、新たな見積もり依頼として、ユーザＵ２から、Ｕ２ａからＵ２ｂまでの経路２４１２で示される引越しの依頼がされたとする。

このとき、サーバ１０の制御部１１は、ユーザＵ２の依頼が、ユーザＵ１からの依頼と出発地点が同じであること、経路２４１１と経路２４１２との向きが一定以上同じ方向を向いていると判定した場合には、ユーザＵ２からの見積もり依頼は、ユーザＵ２の見積もり依頼を送信した企業である企業Ａとのマッチングを決定する。即ち、制御部１１は、企業Ａに対してユーザＵ２からの見積もり依頼を送信することを決定する。このような場合に、制御部１１は、限定ではなく一例として、経路２４１１と経路２４１２とのベクトルを算出し、ベクトル間の相関値が所定閾値以上であることを以て、マッチングを決定することとしてよい。例えば、相関値を算出する方法として、経路２４１１のベクトルと、経路２４１２のベクトルとの内積を計算し、所定の値以上になった場合は、相関値が閾値以上であるとして、マッチングしていると決定する。図２４（ｂ）のように、二つの依頼の出発地点が同じになる場合には、ユーザＵ１とＵ２とが許諾等すれば、例えば、経路２４１３に示すように、一方の到着地点を経由して、双方の引越しを行うことができるルートの選択も可能となり、経費の削減を行うことも考えられる。このような場合には、ユーザＵ１とユーザＵ２に対する請求額についても削減を行うことができるので、ユーザＵ１とユーザＵ２に対する見積もり額を低減することもできるようになり、依頼の受注の可能性を高めることができる。

図２５は、サーバ１０と、企業サーバ４０との間のトークルームの一例を示す画面図であって企業サーバ４０側の機器で見ることができる画面図を示している。図２５（ａ）は、図２３において、ステップＳ２３０３の処理を行った場合、即ち、新たな見積もり依頼が、過去の他の見積もり依頼との間に相関がなかった場合に、サーバ１０から企業サーバ４０に対して送信されるメッセージ例を示している。

図２５（ａ）に示されるように、サーバ１０からは企業サーバ４０に対して、Ａというユーザから依頼があること、その依頼が企業サーバ４０に対して依頼がされているユーザＢという人物とのマッチング率が高いことを示すメッセージが送信される。この際には、図２５（ａ）に示すように、ユーザＡの依頼、ユーザＢの依頼を併せて表示するように、メッセージが送信されてもよいし、送信されなくてもよい。また、いずれか一方の依頼内容を示すにとどめてもよい。

図２５（ｂ）は、図２３において、ステップＳ２３０２の処理を行った場合、即ち、新たな見積もり依頼が、過去の他の見積もり依頼との間に相関があった場合に、サーバ１０から企業サーバ４０に対して送信されるメッセージ例を示している。図２５（ｂ）に示されるようにサーバ１０からは企業サーバ４０に対して、Ａというユーザから依頼があること、そのユーザＡからの見積もり依頼の内容が、企業サーバ４０とのマッチング率が高い、即ち、相性がよい旨を示すメッセージを送信する。この際には、図２５（ｂ）に示すように、新たな依頼主であるユーザＡの依頼内容と、過去の関連がある他の見積もり依頼の依頼主であるユーザＢの依頼内容も併せて表示するようにメッセージが送信されてもよいし、されなくてもよい。過去の依頼内容であるユーザＢの依頼内容も併せて表示することで、企業サーバ４０のオペレータは、新たなユーザＡからの依頼内容との比較を容易に行うことができる。

図２５に示すような、情報がサーバ１０から得られることで、企業サーバ４０は、見積もりの額の減縮、依頼を受けるか否かの意思決定がしやすくなるというメリットを得ることができる。

図２４に示すような状況下にあっては、企業側としては、近い場所から近い場所への引越しということで、引越し作業自体が楽になる（引越し元への荷物の集配の手配、車両の手配等）といえ、個別の案件を処理するよりも、処理数を少なくできる可能性がある。そうすると、企業Ａとしては、ユーザＵ１、Ｕ２それぞれに対するコストを低減することができる可能性があり、その分だけ見積もりを安くすることが許容できるようになる。したがって、ユーザＵ１、Ｕ２に対して、通常よりも安い見積もりを送付することによって、ユーザＵ１、Ｕ２双方からの依頼を受注できる可能性を高めることができる。

なお、ここでは、詳細には記載しないが、上記第１実施形態に示した態様は、第３実施形態にも適用することとてもよいし、しなくてもよい。例えば、図１１（ａ）に示したリッチメニューを利用したユーザとサーバ１０との間のやり取りは、ユーザを企業サーバ４０に代えて、本実施形態にも適用可能である。本実施形態であれば、限定ではなく一例として、リッチメニューとして、サーバ１０が見積もり依頼をしているユーザそれぞれを示すボタンを配したリッチメニューを表示することが考えられる。限定ではなく一例として、これらのボタンは、各ユーザとのトークを開始するためのボタンであってもよいし、そうでなくてもよい。

また、本第３実施形態においても図１１（ｂ）に示したように、企業サーバ４０（のオペレータ）又はサーバ１０（のオペレータ）は、見積もり依頼をしているユーザに係る情報のやり取りにおいて、画像情報（スタンプ）を用いたやり取りをすることとしてもよいし、そうでなくてもよい。限定ではなく一例として、企業サーバ４０は、ユーザとのトークにおいて、提供するサービスにおいて、減額の意思があることを示す画像情報を用いることができ、それによって、ユーザが依頼をしやすくなるようにすることができる。

また、企業サーバ４０は、サービスを提供した後、もしくは、サービスを提供する（提供前を含む）過程でユーザとしたやり取りなどから、ユーザを評価した評価情報を、サーバ１０に送信することとしてもよい。そして、サーバ１０は、その企業がしたユーザの評価をユーザ情報２００にメタデータとして登録することとしてもよいし、しなくてもよい。また企業のユーザに対する評価は、以降の企業サーバ４０へのユーザのマッチング率の算出に反映させてもよいし、させなくてもよい。

＜実施形態の効果＞
サーバ１０の制御部１１は、ユーザからの見積もり依頼があった場合に、その見積もり依頼の内容から、相性のよい企業を特定する。制御部１１は、見積もり依頼の内容と、企業それぞれの情報（限定ではなく企業に関する情報の一例）または、企業の特色を示す情報（限定ではなく企業に関する情報の一例）とに基づいて、ユーザの見積もり依頼に対して相性のよい企業を特定する。そして、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４を介して、企業サーバ４０に対して、ユーザからの見積もり依頼を送信する、とともに、そのユーザが企業サーバ４０にとっておすすめのユーザである旨を示す情報を送信する。
また、企業サーバ４０の表示部４３は、受信した依頼情報とともに、その依頼を行ったユーザがおすすめである旨を示していた場合に、おすすめであることがわかる表示態様で表示する。

これにより、サーバ１０は、企業サーバ４０に対して、おすすめとなるユーザの情報を提供することで、企業サーバ４０からの信頼を得ることができるとともに、ユーザに対してもユーザにとって好適な企業を紹介できる可能性を高くすることができ、ユーザからの信頼も得ることができる。

また、企業サーバ４０としては、自社が得意とする分野、相性のよいユーザの依頼を受けるために、見積もり額の加減を判断することができる。自社が得意とする分野でのサービスの提供、相性のよいユーザに対するサービスの提供をするために、安めの見積もりをして、そのユーザの獲得を狙いつつ、ユーザの希望に沿う満足度の高いサービスを提供することで、ユーザからの高い評価を得て、新たな顧客（ユーザ）の獲得につなげる可能性を高めることができる。

また、制御部１１は、ユーザの見積もり依頼で示される内容と、企業サーバ４０の企業情報（特色）との一致度合い、関連度合に基づいて、企業サーバ４０に対して、ユーザがおすすめであるか否かを示す情報を送信する。

これにより、サーバ１０は、企業サーバ４０に対してより依頼をしてくれる可能性の高いユーザを紹介することができる。したがって、企業サーバ４０側としても、顧客の獲得のために、可能な範囲で見積もりを安くして、ユーザの満足度の高いサービスを提供することで、自社の評価を高めることにつなげられる。

また、サーバ１０は、複数のユーザからの依頼を纏めた依頼情報３００を企業サーバ４０に送信し、その際に依頼情報３００にその企業に対しておすすめであるか否かの情報を付して送信する。ここでおすすめであるか否かの情報とは、ユーザがその企業サーバ４０と取引を行う可能性が高いか否かに基づく情報であってもよい。

これにより、企業サーバ４０としては、複数のユーザからの見積もり依頼をうけつつも、それらの依頼の中でも自社として優先すべきユーザがどのユーザであるかを特定し、そのユーザを優先して対応することができる。

また、サーバ１０の記憶部１５はユーザ情報２００を記憶している。ユーザ情報２００には、ユーザを特定できないもののユーザに関し、依頼内容がある程度理解できる情報（限定ではなく、第１情報の例）と、ユーザを特定可能なユーザに関する情報（限定ではなく、第２情報の例）とが含まれる。

これにより、企業サーバ４０は、ユーザを特定できないもののユーザに関し、依頼内容がある程度理解できる情報（限定ではなく、第１情報の例）があることにより、おおよその見積もり額を算定できて、ユーザに伝えることができる。一方で、ユーザは、自身を特定可能な情報（限定ではなく、第１情報の例）を開示することなく、受けたいサービスのおおよその金額を知ることができる。そして、自身を特定可能な情報を開示しないことで、その後の各種の業者からの広告や営業を受けずに済む。
また、ユーザを特定可能なユーザに関する情報（限定ではなく、第２情報の例）があることで、企業サーバ４０は、詳細な見積もりを策定でき、ユーザは、その詳細な見積もりから、依頼をするか否か（サービスを受けるか否か）を判断するための判断材料とすることができる。

そして、サーバ１０は、最初の段階での見積もり依頼においては、ユーザからの依頼内容については、企業サーバ４０に送信するものの、ユーザ個人を特定可能な情報（限定ではなく第２情報の例）については、送信しない。そして、ユーザからの承諾がある場合に、ユーザ個人を特定可能な情報（限定ではなく第２情報の例）を送信する。

サーバ１０は、ユーザの個人情報を明かすことなく、ユーザからの見積もり依頼を企業サーバ４０に送信することができるとともに、ユーザからの承諾があった場合にのみ企業サーバ４０にユーザの個人情報を送信するので、サーバ１０は、ユーザからの信頼を得ることができる。

また、サーバ１０の制御部１１は、企業にとっておすすめのユーザを決定するにあたって、企業が過去に行った取引の情報を用いる。即ち、サーバ１０から、企業サーバ４０に対して、送信した過去の見積もり依頼の内容と、相関の高い新たな見積もり依頼がある場合などには、その企業サーバ４０にとって得意であったり、依頼内容の関連性が高い場合にサービスを提供するための項数を減らしたりすることができる依頼である可能性があるので、おすすめのユーザとして紹介する。

これにより、サーバ１０は、企業サーバ４０に対して、信頼性の高い情報を提供することができる。

また、サーバ１０は、ユーザからの見積もり依頼に対して、企業サーバ４０に対しておすすめのユーザあるかを判定する際に、企業サーバ４０の得意とする分野、特色（限定ではなく一例として、得意地域２１０４、得意人数２１０５、企業特性２１０６）の情報を用いておすすめのユーザを決定する。

企業サーバ４０にとってサービスを提供するうえで、得意とする分野や特色を示す情報を用いて、おすすめのユーザを決定するので、ユーザから実際に依頼をしてもらえる可能性を向上させることができるとともに、企業サーバ４０にとって得意とする分野でのサービスを提供することで効率よく処理をすることができる。

また、サーバ１０は、ユーザからの見積もり依頼で示される引越しにおいて、引越し元の地域の情報と引越し先の地域との情報、及び、企業が得意とする地域、即ち、サービスを提供することが可能な領域を示す情報に基づいて、見積もり依頼をするユーザが、企業サーバ４０にとっておすすめであるか否かを判定することができる。

これによって、サーバ１０は、企業サーバ４０にとって、サービスを提供するのに得意となる地域でのサービスをユーザに提供することで、ユーザの満足度をあげることができる。また、サーバ１０は、企業サーバ４０に対して、より好適なユーザを紹介することができるので、クオリティの高いサービを提供することができる。

また、企業サーバ４０は、企業サーバ４０がユーザと行った交渉（取引）に係る情報をサーバ１０に送信する。そして、サーバ１０は、その交渉（取引）をするための情報を受信する。取引に関する情報は、メッセージ（文字情報）であってもよいし、取引の内容を示す画像であってもよい。

これにより、企業サーバ４０は、ユーザとの間で行った交渉（取引）に係る情報をサーバ１０に送信することができ、サーバ１０は、その情報を得ることができる。したがって、サーバ１０は、ユーザと企業サーバ４０との間で公正な取引が行われたかどうかを確認することができるとともに、ユーザと企業サーバ４０とのそれぞれを、その取引の内容から評価することができる。この評価は、それぞれ、ユーザ情報２００、企業情報２１００に反映させることとしてもよいし、しなくてもよい。反映させた場合には、以降のユーザと企業サーバ４０とのマッチングにおいて、最新のユーザまたは企業に係る情報を利用したマッチングが実現できる。

＜その他＞
本開示の実施形態を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本開示の範囲に含まれることに留意されたい。限定でなく例として、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。また、各実施形態または各変形例に示す構成を適宜組み合わせることとしてもよい。

また、上記実施形態に示した端末２０、サーバ１０、企業サーバ４０各々の構成は、図１に示した構成に代えて、図２６に示すように構成されてもよい。
即ち、端末２０は、図２６（ａ）に示すように、通信部２２と、制御部２１とから構成されてよく、端末２０の通信部２２は、サーバ１０からユーザの情報（見積もり依頼）を送信し、サーバ１０から、取引を行う企業サーバ４０とその評価を示す評価情報を受信し、表示部２４にその企業サーバと評価情報とを表示する。
また、サーバ１０は、図２６（ｂ）に示すように、通信部１４から構成されてよく、サーバ１０の通信部１４は、ユーザの端末２０からユーザの情報（見積もり依頼）を受信し、取引を行う企業サーバ４０とその評価を示す評価情報を送信する。これにより、サーバ１０は、ユーザにとってサービスを依頼する依頼先を決定するうえで有益となる情報を提供することができ、ユーザからの信頼を得ることができる。また、ユーザは、サービスを依頼する依頼先を決定するうえでの有益な判断材料を得ることができる。
また、端末２０は、図２６（ａ）に示すように、通信部２２と、表示部２４とから構成されてよく、通信部２２は、ユーザの情報（見積もり依頼）を送信し、それに対して、サーバ１０から企業サーバ４０からの見積もり額に関する情報を受信する。端末２０の表示部２４は、その表示領域に受信した見積もり額に関する情報を表示する。端末２０のユーザは、依頼し、サービスを受けた企業サーバ４０から請求書を受け取る。そして、端末２０の通信部２２は、ユーザからの入力にしたがって、企業サーバ４０からの請求書の情報を、サーバ１０に送信する。
また、サーバ１０は、図２６（ｂ）に示すように、通信部１４から構成されてよく、ユーザの情報（見積もり依頼）を受信する。通信部１４は、その見積もり依頼を企業サーバ４０に送信し、それに対して、企業サーバ４０から見積もり額を受信する。サーバ１０の通信部１４は、その見積もり額を、端末２０に送信する。そして、通信部１４は、端末２０から、サービスを提供した企業サーバ４０からの請求額に関する情報を受信する。これにより、サーバ１０は、見積もり額と請求額それぞれの情報を得ることができるので、見積もり額と請求額との間に乖離があるか否かを確認することができる。
また、サーバ１０は、図２６（ｂ）に示すように、通信部１４から構成されてよく、ユーザの情報（見積もり依頼）を受信し、その見積もり依頼の送信先の企業サーバ４０を決定し、決定した企業サーバ４０に送信する。このとき、サーバ１０は、企業サーバ４０に対して、企業サーバ４０にとっておすすめとなるユーザについて、そのユーザがおすすめであると評価する情報を併せて送信する。
また、企業サーバ４０は、図２６（ｃ）に示すように、表示部４３と、通信部４４から構成されてよく、サーバ１０から、ユーザからの見積もり依頼とともに、そのユーザがおすすめであると評価する情報を併せて受信する。そして、表示部４３は、その見積もり依頼の内容と、ユーザがおすすめであることを示す情報とを表示する。これにより、サーバ１０は、企業サーバ４０にとって有益となる情報を提供することができ、企業サーバ４０は、受注する依頼を選択する判断材料を得ることができる。

１通信システム
１０サーバ
１１制御部
１１１決定部
１１２メッセージ処理部
１２入出力部
１３表示部
１４通信Ｉ／Ｆ（通信部）
２０端末
２１制御部
２１１表示処理部
２１２広告処理部
２２通信Ｉ／Ｆ
２３入出力部
２３１タッチパネル
２３２スピーカ
２３３マイク
２３４カメラ
２４表示部（ディスプレイ）
２５位置情報取得部
２８記憶部
３０ネットワーク
４０企業サーバ
４１制御部
４１１メッセージ処理部
４１２表示処理部
４２入出力部
４３表示部
４４通信Ｉ／Ｆ
４５記憶部

Claims

サーバと情報の通信を行うユーザの端末によって実行されるプログラムであって、
前記ユーザの情報を含み、前記ユーザが特定されない情報である第１情報を前記端末の通信部によって前記サーバに送信することと、
前記第１情報に基づく、前記ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、前記少なくとも１つ以上の候補企業に対する評価に関する評価情報と、前記第１情報に基づく、前記少なくとも１つ以上の候補企業によって送信された第１金額の情報とを前記通信部によって前記サーバから受信することと、
前記評価情報に基づく、前記少なくとも１つ以上の候補企業に関する情報と、前記第１金額の情報に基づく第１表示とを前記端末の表示領域に表示することと、
前記表示領域に表示された、前記少なくとも１つ以上の候補企業に関する情報のうち、前記ユーザによって選択された企業に対して、前記ユーザが特定可能になる情報を含む第２情報を前記通信部によって前記サーバに送信することと、
前記第２情報に基づく、前記ユーザによって前記選択された企業によって送信された第２金額の情報を前記通信部によって前記サーバから受信することと、
前記第２金額の情報に基づく第２表示を前記表示領域に表示することとが前記端末によって実行される。
請求項１に記載のプログラムであって、
前記少なくとも１つ以上の候補企業は、複数の候補企業であり、
前記評価情報は、前記複数の候補企業各々の評価情報を含み、
前記第１金額の情報は、前記複数の候補企業各々によって送信された金額の情報を含む。
請求項１または請求項２に記載のプログラムであって、
前記少なくとも１つ以上の候補企業に関する情報は、前記評価情報に基づく表示態様で前記表示領域に表示される。
請求項３に記載のプログラムであって、
前記少なくとも１つ以上の候補企業は、前記評価情報に基づく順序で前記表示領域に表示される。
請求項３または請求項４に記載のプログラムであって、
前記少なくとも１つ以上の候補企業は、第１候補企業と第２候補企業とを含み、
前記評価情報に基づき、前記第１候補企業より評価が低い前記第２候補企業を前記表示領域に表示しないことが前記端末によって実行される。
請求項３から請求項５のいずれか一項に記載のプログラムであって、
前記評価情報に基づき、前記少なくとも１つ以上の候補企業に対する評価を前記表示領域に表示することが前記端末によって実行される。
請求項２に記載のプログラムであって、
前記ユーザによって前記選択された前記企業に対する、前記ユーザの評価情報を前記通信部によって前記サーバに送信することが前記端末によって実行される。
請求項１から請求項７のいずれか一項に記載のプログラムであって、
前記少なくとも１つ以上の候補企業の担当者に関する情報を前記通信部によって前記サーバから受信することが前記端末によって実行される。
請求項８に記載のプログラムであって、
前記担当者の評価情報を前記通信部によって前記サーバから受信することが前記端末によって実行される。
請求項１から請求項９のいずれか一項に記載のプログラムであって、
前記ユーザの嗜好に関する情報に基づいて、前記少なくとも１つ以上の候補企業のうち、前記ユーザにおすすめする企業の情報を前記通信部によって前記サーバから受信することが前記端末によって実行される。
請求項１から請求項１０のいずれか一項に記載のプログラムであって、
前記少なくとも１つ以上の候補企業に対する前記取引に関する情報を前記通信部によって前記サーバに送信することが前記端末によって実行される。
請求項１１に記載のプログラムであって、
前記取引に関する情報は、コンテンツを含む。
請求項１１または請求項１２に記載のプログラムであって、
前記取引に関する情報は、前記少なくとも１つ以上の候補企業と前記取引を行うための画像情報を含む。
請求項１から請求項１３のいずれか一項に記載のプログラムであって、
前記少なくとも１つ以上の候補企業のうちの少なくともいずれか一つに対する前記ユーザの評価を前記通信部によって前記サーバに送信することが前記端末によって実行される。
請求項１から請求項１４のいずれか一項に記載のプログラムであって、
前記少なくとも１つ以上の候補企業は、複数の候補企業であり、
前記複数の候補企業各々に関する情報を前記表示領域に表示することと、
前記表示領域に表示された前記複数の候補企業のうち、前記ユーザによって選択された企業以外の各々に関する情報が前記表示領域に表示されず、前記ユーザによって前記選択された企業以外との前記取引に関する情報の通信ができない状態にする制御を前記端末の制御部によって行うこととが前記端末によって実行される。
請求項１５に記載のプログラムであって、
前記取引に関する情報は、メッセージにより、前記端末と前記ユーザによって前記選択された企業の各々とで通信される。
請求項１５または請求項１６に記載のプログラムであって、
前記端末ごとに変更可能な、前記複数の候補企業に関する情報を前記表示領域に表示することが前記端末によって実行される。
請求項１から請求項１７のいずれか一項に記載のプログラムであって、
前記第２情報は、前記第１情報よりも詳細な前記ユーザの情報を含む。
請求項１から請求項１８のいずれか一項に記載のプログラムであって、
前記第２情報は、前記ユーザの氏名、前記ユーザの郵便番号、前記ユーザの住所、前記ユーザのメールアドレスおよび前記ユーザの電話番号のいずれか一つを含む。
請求項１から請求項１７のいずれか一項に記載のプログラムであって、
前記第１情報は、前記ユーザの住所の一部分である第１住所情報である。
請求項２０に記載のプログラムであって、
前記第２情報は、前記第１住所情報とは異なる第２住所情報であり、
前記ユーザの住所は、前記第１住所情報と前記第２住所情報とで構成される。
請求項１から請求項１７のいずれか一項に記載のプログラムであって、
前記ユーザは、前記第１情報と前記第２情報とによって特定可能になる。
サーバと情報の通信を行うユーザの端末の情報処理方法であって、
前記ユーザの情報を含み、前記ユーザが特定されない情報である第１情報を前記端末の通信部によって前記サーバに送信することと、
前記第１情報に基づく、前記ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、前記少なくとも１つ以上の候補企業に対する評価に関する評価情報と、前記第１情報に基づく、前記少なくとも１つ以上の候補企業によって送信された第１金額の情報とを前記通信部によって前記サーバから受信することと、
前記評価情報に基づく、前記少なくとも１つ以上の候補企業に関する情報と、前記第１金額の情報に基づく第１表示とを前記端末の表示領域に表示することと、
前記表示領域に表示された、前記少なくとも１つ以上の候補企業に関する情報のうち、前記ユーザによって選択された企業に対して、前記ユーザが特定可能になる情報を含む第２情報を前記通信部によって前記サーバに送信することと、
前記第２情報に基づく、前記ユーザによって前記選択された企業によって送信された第２金額の情報を前記通信部によって前記サーバから受信することと、
前記第２金額の情報に基づく第２表示を前記表示領域に表示することとを含む。
サーバと情報の通信を行うユーザの端末であって、
前記ユーザの情報を含み、前記ユーザが特定されない情報である第１情報を前記サーバに送信し、前記第１情報に基づく、前記ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、前記少なくとも１つ以上の候補企業に対する評価に関する評価情報と、前記第１情報に基づく、前記少なくとも１つ以上の候補企業によって送信された第１金額の情報とを受信する通信部と、
前記評価情報に基づく、前記少なくとも１つ以上の候補企業に関する情報と、前記第１金額の情報に基づく第１表示とを表示する表示部とを備え、
前記通信部は、前記表示部に表示された、前記少なくとも１つ以上の候補企業に関する情報のうち、前記ユーザによって選択された企業に対して、前記ユーザが特定可能になる情報を含む第２情報を前記サーバに送信し、前記第２情報に基づく、前記ユーザによって選択された企業によって送信された第２金額の情報を前記サーバから受信し、
前記表示部は、前記第２金額の情報に基づく第２表示を表示する。
ユーザの端末と情報の通信を行うサーバによって実行されるプログラムであって、
前記ユーザの情報を含み、前記ユーザが特定されない情報である第１情報を前記サーバの通信部によって前記端末から受信することと、
前記第１情報に基づいて、前記ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、前記少なくとも１つ以上の候補企業に対する評価に関する評価情報と、前記第１情報に基づいて、前記少なくとも１つ以上の候補企業によって送信された第１金額の情報とを前記通信部によって前記端末に送信することと、
前記端末の表示領域に表示された、前記少なくとも１つ以上の候補企業に関する情報のうち、前記ユーザによって選択された企業に対して、前記ユーザが特定可能になる情報を含む第２情報を前記通信部によって前記端末から受信することと、
前記第２情報に基づく、前記ユーザによって前記選択された企業によって送信された第２金額の情報を前記通信部によって前記端末に送信することとが前記サーバによって実行される。
請求項２５に記載のプログラムであって、
前記少なくとも１つ以上の候補企業は、複数の候補企業であり、
前記評価情報は、前記複数の候補企業各々の評価情報を含み、
前記第１金額の情報は、前記複数の候補企業各々によって送信された金額の情報を含む。
請求項２５または請求項２６に記載のプログラムであって、
前記評価情報は、前記少なくとも１つ以上の候補企業に関する情報を前記端末の表示領域に表示するための情報を含む。
請求項２７に記載のプログラムであって、
前記評価情報は、前記少なくとも１つ以上の候補企業を前記表示領域に表示する順序に関する情報を含む。
請求項２７または請求項２８に記載のプログラムであって、
前記評価情報は、前記評価情報に基づき、前記少なくとも１つ以上の候補企業のうち、前記表示領域に表示しないための情報を含む。
請求項２７から請求項２９のいずれか一項に記載のプログラムであって、
前記評価情報は、前記少なくとも１つ以上の候補企業に対する評価を示す情報を含む。
請求項２６に記載のプログラムであって、
前記ユーザによって前記選択された企業に対する、前記ユーザの評価情報を前記通信部によって前記端末から受信することが前記サーバによって実行される。
請求項２５から請求項３１のいずれか一項に記載のプログラムであって、
前記少なくとも１つ以上の候補企業の担当者に関する情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
請求項３２に記載のプログラムであって、
前記担当者の評価情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
請求項２５から請求項３３のいずれか一項に記載のプログラムであって、
前記ユーザの嗜好に関する情報に基づいて、前記少なくとも１つ以上の候補企業のうち、前記ユーザにおすすめする企業の情報を前記通信部によって前記端末に送信することが前記サーバによって実行される。
請求項２５から請求項３４のいずれか一項に記載のプログラムであって、
前記少なくとも１つ以上の候補企業に対する前記取引に関する情報を前記通信部によって前記端末から受信することが前記サーバによって実行される。
請求項３５に記載のプログラムであって、
前記取引に関する情報は、コンテンツを含む。
請求項３５に記載のプログラムであって、
前記取引に関する情報は、前記少なくとも１つ以上の候補企業と前記取引を行うための画像情報を含む。
請求項２５から請求項３７のいずれか一項に記載のプログラムであって、
前記少なくとも１つ以上の候補企業のうちの少なくともいずれか一つに対する前記ユーザの評価を前記通信部によって前記端末から受信することが前記サーバによって実行される。
請求項２５から請求項３８のいずれか一項に記載のプログラムであって、
前記第２情報は、前記第１情報よりも詳細な前記ユーザの情報を含む。
請求項２５から請求項３９のいずれか一項に記載のプログラムであって、
前記第２情報は、前記ユーザの氏名、前記ユーザの郵便番号、前記ユーザの住所、前記ユーザのメールアドレスおよび前記ユーザの電話番号のいずれか一つを含む。
請求項２５から請求項３８のいずれか一項に記載のプログラムであって、
前記第１情報は、前記ユーザの住所の一部分である第１住所情報である。
請求項４１に記載のプログラムであって、
前記第２情報は、前記第１住所情報とは異なる第２住所情報であり、
前記ユーザの住所は、前記第１住所情報と前記第２住所情報とで構成される。
請求項２５から請求項３８のいずれか一項に記載のプログラムであって、
前記ユーザは、前記第１情報と前記第２情報とによって特定可能になる。
ユーザの端末と情報の通信を行うサーバの情報処理方法であって、
前記ユーザの情報を含み、前記ユーザが特定されない情報である第１情報を前記サーバの通信部によって前記端末から受信することと、
前記第１情報に基づいて、前記ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、前記少なくとも１つ以上の候補企業に対する評価に関する評価情報と、前記第１情報に基づいて、前記少なくとも１つ以上の候補企業によって送信された第１金額の情報とを前記通信部によって前記端末に送信することと、
前記端末の表示領域に表示された、前記少なくとも１つ以上の候補企業に関する情報のうち、前記ユーザによって選択された企業に対して、前記ユーザが特定可能になる情報を含む第２情報を前記通信部によって前記端末から受信することと、
前記第２情報に基づく、前記ユーザによって前記選択された企業によって送信された第２金額の情報を前記通信部によって前記端末に送信することとを含む。
ユーザの端末と情報の通信を行うサーバであって、
前記ユーザの情報を含み、前記ユーザが特定されない情報である第１情報を前記端末から受信し、前記第１情報に基づいて、前記ユーザと取引を行う候補である、少なくとも１つ以上の候補企業に関する情報と、前記少なくとも１つ以上の候補企業に対する評価に関する評価情報と、前記第１情報に基づいて、前記少なくとも１つ以上の候補企業によって送信された第１金額の情報とを前記端末に送信し、前記端末の表示領域に表示された、前記少なくとも１つ以上の候補企業に関する情報のうち、前記ユーザによって選択された企業に対して、前記ユーザが特定可能になる情報を含む第２情報を受信し、前記第２情報に基づく、前記ユーザによって選択された企業によって送信された第２金額の情報を前記端末に送信する通信部を備える。