<法的事項の遵守>
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
本開示に係る端末による取引先の評価を表示する表示方法を実施するための実施形態について、図面を参照して説明する。
<システム構成>
図1は、本開示の一実施形態に係る通信システム1の構成を示す。図1に開示されるように、通信システム1では、ネットワーク30を介してサーバ10と、端末20(端末20A,端末20B,端末20C)と、企業サーバ40とが接続される。サーバ10は、ネットワーク30を介してユーザが所有する端末20に、端末20間(企業サーバ40を含んでよい)でのメッセージの送受信を実現するサービスを提供する。なお、ネットワーク30に接続される端末20の数は限定されない。
ネットワーク30は、1以上の端末20と、1以上のサーバ10とを接続する役割を担う。すなわち、ネットワーク30は、端末20がサーバ10に接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
ネットワーク30のうちの1つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク30は、限定でなく例として、アドホック・ネットワーク(ad hoc network)、イントラネット、エクストラネット、仮想プライベート・ネットワーク(virtual private network:VPN)、ローカル・エリア・ネットワーク(local area network:LAN)、ワイヤレスLAN(wireless LAN:WLAN)、広域ネットワーク(wide area network:WAN)、ワイヤレスWAN(wireless WAN:WWAN)、大都市圏ネットワーク(metropolitan area network:MAN)、インターネットの一部、公衆交換電話網(Public Switched Telephone Network:PSTN)の一部、携帯電話網、ISDN(integrated service digital networks)、無線LAN、LTE(long term evolution)、CDMA(code division multiple access)、ブルートゥース(Bluetooth(登録商標))、衛星通信など、または、これらの2つ以上の組合せを含むことができる。ネットワーク30は、1つまたは複数のネットワーク30を含むことができる。
端末20(端末20A,端末20B,端末20C)は、各実施形態において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末20は、限定ではなく例として、スマートフォン、携帯電話(フィーチャーフォン)、コンピュータ(限定でなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定でなく例として、PDA・(personal digital assistant)、電子メールクライアントなど)、ウェアラブル端末(メガネ型デバイス、時計型デバイスなど)、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末20は情報処理端末と表現されてもよい。
端末20A、端末20Bおよび端末20Cの構成は基本的には同一であるため、以下の説明においては、端末20について説明する。また、必要に応じて、ユーザXが利用する端末を端末20Xと表現し、ユーザXまたは端末20Xに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Xと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
サーバ10は、端末20に対して、所定のサービスを提供する機能を備える。サーバ10は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ10は、限定でなく例として、サーバ装置、コンピュータ(限定でなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定でなく例として、PDA、電子メールクライアントなど)、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ10は情報処理装置と表現されてもよい。サーバ10と端末20とを区別する必要がない場合は、サーバ10と端末20とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
<ハードウェア(HW)構成>
図1を用いて、通信システム1に含まれる各装置のHW構成について説明する。
(1)端末のHW構成
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、表示部24、マイク233、スピーカ232、カメラ234を備える。端末20のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、端末20のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末20は、マイク233、カメラ234等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
通信I/F22は、ネットワーク30を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F22は、ネットワーク30を介して、サーバ10との通信を実行する機能を有する。通信I/F22は、各種データを制御部21からの指示に従って、サーバ10に送信する。また、通信I/F22は、サーバ10から送信された各種データを受信し、制御部21に伝達する。また、通信I/F22を単に通信部と表現する場合もある。また、通信I/F22が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。通信I/F22は、ネットワーク30を介して企業サーバ40との通信を実行する機能を有してもよいし、有さなくてもよい。
入出力部23は、端末20に対する各種操作を入力する装置、および、端末20で処理された処理結果を出力する装置を含む。入出力部23は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部21に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定でなく例として、タッチパネル231、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ234(動画像を介した操作入力)、マイク233(音声による操作入力)を含む。
出力部は、制御部21で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定でなく例として、 タッチパネル、タッチディスプレイ、スピーカ232(音声出力)、レンズ(限定でなく例として3D(three dimensions)出力や、ホログラム出力)、プリンターなどを含む。
表示部24は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部24は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ(限定でなく例として、液晶ディスプレイやOELD(organic electroluminescence display))、ヘッドマウントディスプレイ(HDM:Head Mounted Display)、プロジェクションマッピング、ホログラム、空気中など(真空であってもよいし、そうでなくてもよい)に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部24は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。
入出力部23がタッチパネルの場合、入出力部23と表示部24とは、略同一の大きさおよび形状で対向して配置されていてもよい。
制御部21は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
制御部21は、限定でなく例として、中央処理装置(CPU)、マイクロプロセッサ(microprocessor)、プロセッサコア(processor core)、マルチプロセッサ(multiprocessor)、ASIC(application-specific integrated circuit)、FPGA(field programmable gate array)を含む。
記憶部28は、端末20が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部28は、限定でなく例として、HDD(hard disk drive)、SSD(solid state drive)、フラッシュメモリ、RAM(random access memory)、ROM(read only memory)など各種の記憶媒体を含む。また、記憶部28は、メモリ(memory)と表現されてもよいし、されなくてもよい。
端末20は、プログラムPを記憶部28に記憶し、このプログラムPを実行することで、制御部21が、制御部21に含まれる各部としての処理を実行する。つまり、記憶部28に記憶されるプログラムPは、端末20に、制御部21が実行する各機能を実現させる。また、このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
マイク233は、音声データの入力に利用される。スピーカ232は、音声データの出力に利用される。カメラ234は、動画像データの取得に利用される。
(2)サーバのHW構成
サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、表示部13を備える。サーバ10のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、サーバ10のHWは、サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ10のHWは、表示部13を取り外すような構成であってもよいし、そうでなくてもよい。
制御部11は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
制御部11は、代表的には中央処理装置(CPU)、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ASIC、FPGAであってもよいし、そうでなくてもよい。本開示において、制御部11は、これらに限定されない。
記憶部15は、サーバ10が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部15は、HDD、SSD、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部15は、これらに限定されない。また、記憶部15は、メモリ(memory)と表現されてもよいし、されなくてもよい。
通信I/F14は、ネットワーク30を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F14は、ネットワーク30を介して、端末20や企業サーバ40との通信を実行する機能を有する。通信I/F14は、各種データを制御部11からの指示に従って、端末20又は企業サーバ40に送信する。また、通信I/F14は、端末20又は企業サーバ40から送信された各種データを受信し、制御部11に伝達する。また、通信I/F14を単に通信部と表現する場合もある。また、通信I/F14が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部12は、サーバ10に対する各種操作を入力する装置により実現される。入出力部12は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部11に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部12は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部12、限定でなく例として、タッチパネルやカメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部12は、これらに限定されない。
表示部13は、代表的にはモニタ(限定でなく例として、液晶ディスプレイやOELD(organic electroluminescence display))で実現される。なお、表示部13は、ヘッドマウントディスプレイ(HDM)などであってもよいし、そうでなくてもよい。なお、これらの表示部13は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。ただし、本開示において、表示部13は、これらに限定されない。
サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
企業サーバ40は、制御部41(CPU)、記憶部45、通信I/F44(インタフェース)、入出力部42、表示部43を備える。企業サーバ40のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。なお、企業サーバ40のHWは、企業サーバ40のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、企業サーバ40のHWは、表示部43を取り外すような構成であってもよいし、そうでなくてもよい。
制御部41は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
制御部41は、代表的には中央処理装置(CPU)、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ASIC、FPGAであってもよいし、そうでなくてもよい。本開示において、制御部41は、これらに限定されない。
記憶部45は、企業サーバ40が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部45は、HDD、SSD、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部45は、これらに限定されない。また、記憶部45は、メモリ(memory)と表現されてもよいし、されなくてもよい。
通信I/F44は、ネットワーク30を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F44は、ネットワーク30を介して、サーバ10との通信を実行する機能を有する。通信I/F44は、各種データを制御部41からの指示に従って、サーバ10に送信する。また、通信I/F44は、サーバ10から送信された各種データを受信し、制御部41に伝達する。また、通信I/F44を単に通信部と表現する場合もある。また、通信I/F44が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。通信I/F44は、ネットワーク30を介して、端末20と通信を実行する機能を有していてもよいし、有していなくてもよい。
入出力部42は、企業サーバ40に対する各種操作を入力する装置により実現される。入出力部42は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部41に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部42は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部42、限定でなく例として、タッチパネルやカメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部42は、これらに限定されない。
表示部43は、代表的にはモニタ(限定でなく例として、液晶表示部やOELD(organic electroluminescence display))で実現される。なお、表示部43は、ヘッドマウントディスプレイ(HDM)などであってもよいし、そうでなくてもよい。なお、これらの表示部43は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。ただし、本開示において、表示部43は、これらに限定されない。
本開示の各実施形態においては、端末20、サーバ10、または、企業サーバ40のCPUがプログラムPを実行することにより、実現するものとして説明する。
なお、端末20の制御部21、サーバ10の制御部11、または、企業サーバ40の制御部41は、制御回路を有するCPUだけでなく、集積回路(IC(Integrated Circuit)チップ、LSI(Large Scale Integration))等に形成された論理回路(ハードウェア)や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、1または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を1つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、LSIは、集積度の違いにより、VLSI、スーパーLSI、ウルトラLSIなどと呼称されることもある。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
また、本開示の各実施形態のプログラムP(限定ではなく、例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムPを記憶可能である。また、プログラムPは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよいし、そうでなくてもよい。
記憶媒体は、1つまたは複数の半導体ベースの、または他の集積回路(IC)(限定でなく例として、フィールド・プログラマブル・ゲート・アレイ(FPGA)または特定用途向けIC(ASIC)など)、ハード・ディスク・ドライブ(HDD)、ハイブリッド・ハード・ドライブ(HHD)、光ディスク、光ディスクドライブ(ODD)、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ(FDD)、磁気テープ、固体ドライブ(SSD)、RAMドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの2つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムPを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ(memory)と表現されてもよいし、されなくてもよい。
サーバ10、端末20、または、企業サーバ40は、記憶媒体に記憶されたプログラムPを読み出し、読み出したプログラムPを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
また、本開示のプログラムPDDは、当該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ10、端末20、または、企業サーバ40に提供されてもよいし、されなくてもよい。サーバ10、端末20、または、企業サーバ40は、限定でなく例として、インターネット等を介してダウンロードしたプログラムPを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
また、本開示の各実施形態は、プログラムPが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
サーバ10、端末20、または、企業サーバ40における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部を、サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理を、サーバ10で行う構成としてもよいし、そうでなくてもよい。
サーバ10における処理の少なくとも一部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
なお、本開示のプログラムは、限定でなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのオブジェクト指向プログラミング言語、HTML5などのマークアップ言語などを用いて実装される。
<機能構成>
<第1実施形態>
第1実施形態に係る通信システム1においては、ユーザの端末20からサーバ10に対して、見積もり依頼を送信し、サーバ10を介して、各企業サーバ40から見積もり情報を受信する。このとき、サーバ10は、ユーザの端末20に対して、見積もりを行う企業サーバ40各々の評価情報を送信する。端末20が、企業サーバ40各々の評価を表示することにより、ユーザは、それぞれの企業サーバ40各々の客観的な評価を認識することができ、見積もりを実際よりも安く見積もるような企業を選択しないようにすることができる。なお、以降においては、端末20、企業サーバ40においては、サーバ10が提供するメッセージングサービスを利用しているものとする。
(1)端末の機能構成
図1に示すように、端末20は、制御部21により実現される機能として、メッセージ処理部211と、表示処理部212とを備える。
メッセージ処理部211は、サーバ10が提供するメッセージングサービスにおいて提供されるメッセージングアプリケーションに従って、ユーザからの入力または通信I/F12が受信したメッセージの入力を受け付けて、表示処理部212に表示するように指示する。なお、ユーザからの入力を受け付けた場合には、その受け付けた入力内容を通信I/F22にサーバ10に宛てて送信するように指示する。
表示処理部212は、メッセージ処理部211からの指示に従ってトークルームの内容を示す表示情報を、表示部24に表示する指示する。本実施形態においては、表示処理部212は、ユーザが行った見積もり依頼に応じて、サーバ10から送信された見積もり依頼を行う企業サーバ40を特定可能な情報と、その企業サーバ40の評価を示す評価情報とを表示する。なお、このとき、企業サーバ40を特定可能な情報は、その評価情報に基づく表示を行ってもよいし、そうでなくてもよい。評価情報に基づく表示とは、限定ではなく一例として、企業サーバ40の評価情報で示される評価の高い順、あるいは、低い順に基づく表示であったり、企業サーバ40の評価を端的に示す評価値(数値、レベル、グラフ等)を示す表示であったり、評価の高い企業サーバ40を、評価の低い企業サーバ40とは区別する表示であってよい。この表示方法は、表示処理部212が予めユーザにより定められた設定によって決定されてもよいし、されなくてもよい。また、あるいは、サーバ10が指定するものであってもよいし、そうでなくてもよい。また、表示処理部212は、端末20が行う見積もり依頼に伴って、サーバ10や企業サーバ40とのやり取りに係る情報を表示する。
(2)サーバの機能構成
図1に示すように、サーバ10は、制御部11により実現される機能として、決定部111と、メッセージ処理部112と、を備える。また、記憶部15は、ユーザの情報を示すユーザ情報200と、企業(企業サーバ40)の情報を示す企業情報2100とを記憶している。
メッセージ処理部112は、各ユーザ間のやり取りを行うためのトークルームを管理する機能と、ユーザの端末20からされたトークルームに送信されたメッセージ(見積もり依頼)を解析して、決定部111が決定した企業サーバ40に見積もり依頼を送信する機能と、を備える。トークルームとは、サーバ10が提供するメッセージングサービスを介して、このメッセージングサービスを利用するユーザ(企業サーバ40を含む)間のメッセージのやり取りをする場所のことであり、トークルームに参加しているユーザが送信したメッセージが、トークルームに参加している全てのユーザが見ることができるユーザインターフェースである。トークルームは、メッセージングサービスを利用するユーザ(企業サーバ40を含む)、または、サーバ10が開設することができ、トークルームが開設されると、そのトークルームに対応付けられているユーザは、そのトークルームに対してメッセージを送信することができるようになる。トークルームにメッセージを送信することができるユーザは、トークルームを開設したユーザ、または、トークルームに参加しているユーザが設定することができる。また、トークルームからユーザは自身の任意により抜けることができる。また、サーバ10は、必要に応じて、トークルームを閉じることもできる。メッセージ処理部112は、ユーザからの見積もり依頼があった場合に、その見積もり依頼に従って、決定部111に見積もり依頼を送信する企業サーバ40を決定するように指示する。そして、決定部111が決定した複数の企業サーバ40に対して見積もり依頼(依頼情報)がある旨を送信する。依頼情報の詳細については後述する。メッセ0時処理部112は、決定部111が決定した複数の企業サーバ40から見積もりの提示がある旨を、各企業サーバ40についての評価情報とともに、端末20に送信する。ここで、評価情報は、予め記憶部15に記憶されていてもよいし、記憶されていなくてもよい。記憶部15に記憶されていない場合には、ネットワーク30や外部の装置から取得することとしてよい。評価情報は各企業サーバ40の評価を示す情報である。その評価は、客観的な数値やレベル表記(数値、記号のいずれの表現であってもよい)、文書などで表現されてよい。企業サーバ40の評価情報は、その企業サーバ40に寄せられた多くの利用者であるユーザからの評価を集計したものを用いるとよい。評価情報は適宜その評価内容が更新されてもよいし、されなくてもよい。評価情報は、過去の企業サーバ40の実績に基づくものであってよく、過去の全てのデータを利用することとしてもよいし、所定期間内(限定ではなく一例として、現在から過去2年以内)のデータを利用することとしてもよい。また、メッセージ処理部112は、ユーザに対してサービスを依頼する企業が決定した場合に、その企業が請求した請求額の情報を提供した場合に、特典を送信する旨をユーザに送信する機能も有する。また、メッセージ処理部112は、端末20または企業サーバ40に対して、決定部111が、ユーザ情報200と企業情報2100を用いて相性のよさから見積もり依頼を送信する企業サーバ40を決定した場合に、それぞれ、またはいずれか一方に対して、おすすめである旨を示す情報をトークルーム上に送信する。
決定部111は、ユーザの端末20からの見積もり依頼、即ち、ユーザから提供された情報に基づいて、その見積もり依頼を送信する対象となる企業サーバ40を決定する機能を有する。即ち、決定部111は、ユーザからの見積もり依頼の内容と、企業サーバ40との間のマッチングを行う。決定部111は、少なくとも2つの企業サーバ40を見積もり依頼の対象となる企業として決定する。このとき、決定部111は、ユーザからの見積もり依頼の内容と、その依頼内容を得意とする、あるいは、ユーザとの相性がよいと推察される企業サーバ40を、決定することとしてもよいし、しなくてもよい。決定部111は、相性がよいと推察される企業サーバ40を決定する場合には、ユーザ情報200と、企業情報2100とを参照して決定する。そうでない場合は、例えば、決定部111は、所定数の企業サーバ40をランダムに決定してもよい。ユーザと企業との間の関連性を考慮して企業サーバ40を決定する手法については後述する。
(3)企業サーバの機能構成
図1に示すように企業サーバ40は、制御部41により実現される機能として、メッセージ処理部411と、表示処理部412と、を備える。
メッセージ処理部411は、通信I/F44を介してサーバ10、または、端末20から送信されたメッセージを処理する機能を有する。メッセージ処理部411は、サーバ10から送信されたユーザからの見積もりの内容を示す依頼情報があることを示す情報を表示処理部412に表示させる。また、メッセージ処理部411は、企業サーバ40のオペレータから入力された依頼情報で示される見積もり依頼に対する見積もり額に関する情報を、通信I/F44から、サーバ10に送信させる。
表示処理部412は、サーバ10、または、端末20との間のやりとりをするためのトークルームの内容を、表示部43に表示する機能を有する。
<データ>
図2は、サーバ10の記憶部15に記憶されているユーザ情報の一例を示すデータ概念図である。図2に示すようにユーザ情報200は、サーバ10が提供するサービスを利用する各ユーザについての情報である。ユーザ情報200は、各ユーザについて、限定ではなく一例として、識別情報201と、名前202と、電話番号203と、メールアドレス204と、郵便番号205と、一部住所206と、番地207とが対応付けられた情報である。なお、ユーザ情報200は、図2に示す各情報について、含んでいてもよいし、含まなくてもよい。ユーザ情報200に示される各情報は、ユーザが自身の端末20に対して入力を行い、端末20の制御部11からの指示に従って通信I/F22が、サーバ10に送信したものであり、制御部11は、ユーザ情報200として記憶部15に記憶する。ユーザ情報200には、ユーザ個人を一意に特定できないもののユーザに関する情報(限定ではなく、第1情報の一例)と、ユーザ個人を特定可能な情報(限定ではなく、第2情報の一例)とが含まれる。図2の例で言えば、ユーザ個人を特定できないユーザ個人に関する情報は、識別情報201、郵便番号205、一部住所206が該当する。また、図2の例で言えば、名前202、電話番号203、メールアドレス204、番地207は、ユーザ個人を特定可能な情報に該当する。
識別情報201は、通信システム1において、サーバ10が各ユーザを一意に識別するための識別子である。識別情報201は、ユーザを特定できる情報であれば、どのような態様であってもよく、アルファベットや記号、数字等の一部又は全部を利用した組み合わせであってもよい。
名前202は、対応する識別情報201で示されるユーザの名前であって、ユーザが自身でサーバ10が提供するサービスを利用する際に登録した名前である。
電話番号203は、対応する識別情報201で示されるユーザと音声通話が可能な機器の電話番号を示す情報である。なお、電話番号203は、一人のユーザに対して複数記憶されていてもよい。
メールアドレス204は、対応する識別情報201で示されるユーザと電子メールによる連絡が可能なアドレスを示す情報である。なお、メールアドレス204は、一人のユーザに対して複数記憶されていてもよい。
郵便番号205は、対応する識別情報201で示されるユーザの住所に対して割り振られている郵便番号を示す情報である。
一部住所206は、対応する識別情報201で示されるユーザの居住している場所を示す情報であって、そのおおよその場所を示す情報である。
番地207は、対応する識別情報201で示されるユーザの居住している場所の番地を示す情報である。一般的には、一部住所206と番地207とを併せて住所とされる。
図2に示すユーザ情報を保持していることにより、サーバ10は、企業サーバ40に対して、ユーザが許諾した場合に、ユーザ自身の詳細な情報を提供することができる。
図3は、サーバ10から企業サーバ40に対して提供される依頼を示す依頼情報の一例を示すデータ概念図である。図3に示す依頼情報300は、ユーザから企業サーバ40が提供するサービスの提供を依頼するための情報であって、サーバ10から提供される情報である。図3に示すように依頼情報300は、依頼日301と、名前302と、電話番号303と、郵便番号304と、一部住所305と、住所詳細306と、その他307とが対応付けられた情報である。なお、依頼情報300は、サービスを提供するにあたって必要な情報があればよく、図3に示す情報の全てを含まずともよいし、ユーザに関連する情報であれば、図3以外の情報を追加で含んでもよい。依頼情報300は、企業サーバ40の記憶部45に記憶される。
依頼日301は、ユーザが依頼を行った日付を示す情報である。
名前302は、ユーザの名前を示す情報である。
電話番号303は、対応するユーザと音声通話が可能な機器の電話番号を示す情報である。なお、電話番号303は、一人のユーザに対して複数記憶されていてもよい。
郵便番号304は、対応するユーザの住所に対して割り振られている郵便番号を示す情報である。
一部住所305は、対応するユーザの居住している場所を示す情報であって、そのおおよその場所を示す情報である。おおよその場所の情報があることで、ユーザの厳密な居所を特定できないものの、引っ越しをする際のおおよその見積もりをすることができる。
住所詳細306は、対応するユーザの居住している場所の番地を示す情報である。一般的には、一部住所305と住所詳細306とを併せて住所とされる。
その他307には、対応するユーザとのトークを行うためのチャットボタンや、対応するユーザからの許諾が得られた場合に、ユーザに関する詳細情報を取得するための詳細ボタン327が配されている。チャットボタンをクリックした場合には、サーバ10が提供するメッセージングサービスの画面であって、企業サーバ40と、対応するユーザとの間のトークルームが起動され、チャットを行うことができるようになる。一方、詳細ボタン327をクリックした場合には、ユーザからの許諾を得ているという条件下で、対応するユーザに関する詳細な情報が得られる。
図3に示す依頼情報300は、サーバ10から提供される初期段階の情報であり、ユーザを特定できない程度の情報の開示がされている情報である。したがって、ユーザを特定可能な情報は、初期段階では空欄となっている。このとき、ユーザからの許諾を得て企業サーバ40のオペレータが詳細ボタン327をクリックすると、そのユーザに対応する詳細なユーザ情報をサーバ10から取得することができる。
図4は、図3に示す詳細ボタン327がクリックされた状態の依頼情報300を示している。図3から図4への変化を見ればわかるように、「B藤 B子」の名前と、その電話番号303や住所詳細306が、企業サーバ40にとって明らかになっている。
<動作>
図5は、本実施形態に係る通信システム1の動作を示すシーケンス図である。図5に示すシーケンス図は、ユーザがサービスの提供の依頼を行ってから、企業サーバ40が見積もりをユーザに送るまでの流れを示す図である。
図5に示すように、ユーザは、自身の端末20から、例えば、サーバ10が提供する各企業サーバ40が提供するサービスの依頼をするウェブフォームにアクセスして、見積もり依頼をサーバ10に送信する(ステップS501)。ここでは、引越しのための依頼ということで、例えば、ユーザは、引越し先や引越し人数等の情報を入力して、端末20からサーバ10に送信する。
見積もり依頼を受信したサーバ10は、その見積もり依頼を送信した端末20に対して、各企業サーバから見積もりが送信される旨を、端末20に送信する。限定ではなく、一例として、サーバ10は、サーバ10と端末20との間の専用のトークルームを介して、各企業サーバからの見積もりが後程送信される旨、及びそれらの企業の評価を示す評価情報を、端末20に通知する(ステップS502)。その一方で、サーバ10は、複数の企業サーバに対して、ユーザからの見積もり依頼を送信する(ステップS503)。
見積もり依頼を受信した各企業サーバ40は、見積もり依頼に含まれる条件のみから、おおよその見積もり額を算出する。そして、算出した見積もり額を、端末20との間に開かれたトークルームに書き込むことで、見積もり額を示す情報を、サーバ10を介して端末20に送信する(ステップS504)。
端末20のユーザは表示された簡易の見積もり額を表示し、ユーザはその内容を確認する。そして、ユーザは、その見積もりを提示した企業サーバに対して、詳細な見積もりを要求するために情報の開示を承諾する入力を行う。端末20は、情報開示を承諾した旨をサーバ10に通知する(ステップS505)。
サーバ10は、端末20が情報の開示を承諾しなかった企業とのトークを削除する(ステップS506)。一方で、ユーザが開示を許諾した企業サーバ40からの情報開示要求に応じて、ユーザの詳細な個人情報を送信する(ステップS507)。
ユーザの詳細な情報を見た企業サーバ40のオペレータは、詳細な見積もりを端末20に対して提示する(ステップS508)。
このようにして、ユーザは、自身で信用できると感じた企業サーバに対して詳細情報を開示し、見積もりをとることができる。
図6は、図5に示すやり取りを実現するための端末20において見積もりを得るまでの処理を示すフローチャートである。
図6に示すように、ユーザは、端末20から、企業サーバ40からのサービスの提供をうけるため、即ち、引越しの見積もり依頼をサーバ10に送信する(ステップS601)。即ち、端末20は、入出力部23に対してユーザから受け付けた見積もり依頼の入力を受け付ける。そして、この入力にしたがって通信I/F22は、見積もり依頼をネットワーク30を介してサーバ10に送信する。
通信I/F22は、見積もり依頼を受けたサーバ10から送信された見積もりを送信する予定の企業情報を受信する。通信I/F22は、受け付けた企業情報を制御部21に送信する。制御部21の表示処理部212は、送信された企業情報を表示部24に表示させる(ステップS602)。
制御部21は、通信I/F22が見積もり額の情報を受信したか否かを判定する(ステップS603)。制御部21は、見積もり額の情報を受信するまで(ステップS603のNO)は待機する。なお、この段階で受信する見積もり額は、おおよその見積もり額になる。
見積もり額の情報を受信すると(ステップS603のYES)、制御部21の表示処理部212は、受信した見積額の情報を、送信した企業サーバに対応するトークルームに表示する(ステップS604)。なお、ステップS602における見積もりを送信する予定の企業情報の受信およびステップS603における見積もり額の情報の受信は同時であってもよいし、同時でなくてもよい。
そのおおよその見積もり額を見て、詳細な見積もりが欲しいとユーザが感じた場合には、詳細な見積もりを要求するために、ユーザ自身の詳細情報を企業サーバ40に送信を許可する入力を行う。端末20の入出力部23は、ユーザから詳細情報の開示を許可する入力があるか否かを判定する(ステップS605)。
ユーザからの詳細情報の開示を許可する入力があった場合に(ステップS605のYES)、制御部21は、通信I/F22を介して、サーバ10に、詳細情報の開示許可を示す情報を送信する(ステップS606)。この情報には、どの企業サーバ40に対しての開示許可であるかを示す情報が含まれる。限定ではなく一例として、この企業サーバ40を特定できる情報として、ユーザがトークを行っていたトークルームを特定可能な情報を用いることができる。
制御部21は、通信I/F22がトークルーム削除情報を受信したか否かを判断する(ステップS607)。ここでいうトークルーム削除情報は、サーバ10から送信されるものであり、ユーザが詳細情報の開示許可を出さなかった企業サーバ40との間のトークルームの削除を示すものである。トークルーム削除情報を受信していない場合には(ステップS607のNO)、ステップS609の処理に移行する。トークルーム削除情報を受信している場合には(ステップS607のYES)、メッセージ処理部211は、ユーザが利用しているメッセージングサービスの中のトークルーム群の中から、トークルーム削除情報で示さえる企業サーバ40とのトークルームを削除する(ステップS608)。
一方で、制御部21は通信I/F22が詳細な見積もり情報を受信したか否かを判定する(ステップS609)。詳細な見積もり情報を受信した場合に(ステップS609のYES)、通信I/F22は、受信した見積もり情報を制御部21に送信する。制御部21の表示処理部212は、受信した詳細な見積もり情報をトークルーム上に表示する(ステップS610)。
制御部21は、ステップS605において詳細情報の開示を承諾した対象の企業サーバ40全てから詳細な見積もり情報を受信したか否かを判定する(ステップS611)。対象の企業サーバ40全てから詳細な見積もり情報を受信していない場合には(ステップS611のNO)、ステップS607の処理に戻り、受信している場合には(ステップS611のYES)、処理を終了する。
次に、図5に示すやり取りを実現するためのサーバ10の処理を、図7を用いて説明する。図7は、見積もり依頼をユーザが行った際の、サーバ10の処理を示すフローチャートである。
図7に示すように、サーバ10の通信I/F14は、ネットワーク30を介して、端末20から、見積もり依頼を受信する(ステップS701)。通信I/F14は受信した見積もり依頼を制御部11に送信する。制御部11は、見積もり依頼を受信すると、所定の基準にしたがって、見積もり依頼の送信先として所定数の企業サーバ40を選定する(ステップS702)。
制御部11は、サーバ10とユーザの端末20との間にトークルームを開設し、開設したトークルーム上で、ユーザに対して選定した複数の企業から見積もりが送付される旨、およびその企業の評価情報を通知する(ステップS703)。
制御部11は、選定した企業サーバ40各々に対して、ユーザからの見積もり依頼がある旨を通知するために、通信I/F14に、ネットワーク30を介して企業サーバ40にユーザからの見積もり依頼を示す情報を送信するよう指示する。通信I/F14は、この指示に従って、指定された企業サーバ40各々に、ユーザからの見積もり依頼を送信する(ステップS704)。このとき、サーバ10は、一人のユーザのみの見積もり依頼を送信することとしてもよいし、複数のユーザの見積もり依頼を送信することとしてもよい。
そして、制御部11は、選定した各企業サーバ40とユーザとの間のトークルームを開設する(ステップS705)。サーバ10からの見積もり依頼を受け付けて各企業サーバ40は、ユーザとの間でトークルームを介してのやり取りを開始可能にする。
制御部11は、ユーザの端末20と企業サーバ40との双方から、端末20のユーザの詳細情報の開示要求があるか否かを判定する(ステップS706)。これは、ユーザの端末20及び企業サーバ40各々から詳細情報の開示要求を示す通信があったか否かにより判定することができる。
ユーザの端末20と企業サーバ40との各々からユーザについての詳細情報の開示要求があった場合には(ステップS706のYES)、サーバ10の制御部11は、記憶部15に記憶しているユーザ情報を用いて、ユーザの詳細情報を、企業サーバ40に送信する(ステップS707)。なお、ここでは、ユーザの端末20と企業サーバ40との各々からユーザについての詳細情報の開示要求があった場合としているが(ステップS706)、これは、ユーザの端末20からの開示要求のみであってもよいし、ユーザの端末20からの開示要求のみでなくてもよい。また、企業サーバ40からの開示要求のみであってもよいが、この場合には、ユーザからの許可があるエビデンスを付与したユーザの詳細情報の開示要求を用いるとよい。
一方で、ユーザの端末20と企業サーバ40との各々からユーザについての詳細情報の開示要求がない場合には(ステップS706のNO)、サーバ10の制御部11は、対応する企業サーバ40とユーザとの間のトークルームを削除する(ステップS708)。なお、ここで、ユーザの端末20と企業サーバ40との各々からユーザについての詳細情報の開示要求がないというのは、ユーザの端末20からの開示要求の通知がなかった場合、ユーザの端末20から特定の企業サーバ40について開示要求をしないとの通知があった場合とを含む。また、ユーザの端末20からの開示要求の通知がないというのは、他の企業については開示要求があり、かつ、企業サーバ40との間のトークルームが開設してから所定時間が経過していることにより判断することもできる。
図8は、図5に示すやり取りを実現するための企業サーバ40における処理を示すフローチャートである。
図8に示すように、企業サーバ40の通信I/F44は、サーバ10からユーザからの見積もり依頼を受信する(ステップS801)。この見積もり依頼には、ユーザのおおよその引越し元、引越し先、引越し人数等の簡易的な見積もりをするに足る情報が含まれている。通信I/F44は、受信した見積もり依頼を制御部41に送信する。制御部41の表示処理部412は、見積もり依頼を表示部43に表示する。これを見て、企業サーバ40のオペレータは、おおよその見積もり額を決定する。ここでいうおおよその見積もり額とは、企業サーバ40が与えられている範囲内の情報で見積もれる範囲の金額のことをいい、限定ではなく一例として、与えられている範囲内の情報から、過去に行ったサービスと類似する案件を抽出し、その案件で行った見積もり若しくは請求の額面を用いた見積もり額のことをいう。また、ここで抽出する過去の案件は、複数あってよく、その場合には、おおよその見積もり額として、(i)類似度の高い案件の見積もり若しくは請求の額面を利用することとしてもよいし、(ii)複数の案件の見積もり額若しくは請求額の平均値や、(iii)複数の案件の類似度の高い所定割合又は所定件数の見積もり額若しくは請求額の平均値を用いることとしてもよい。
制御部41は、設定されたおおよその見積もり額を、通信I/F44に、見積もり額を決定したユーザの端末20に送信するように指示する。通信I/F44は、指定されたユーザの端末20に、見積もり額の情報を送信する(ステップS802)。企業サーバ40は、ユーザとの間のトークにおいてユーザからの詳細情報の開示承認を得ている場合に(ステップS803のYES)、制御部41は、企業サーバ40はオペレータからの入出力部42への入力に従って(ステップS804のYES)、対応するユーザの詳細情報の開示要求を通信I/F41に送信させる。通信I/F41は、詳細情報の開示要求を、サーバ10に送信する(ステップS805)。
詳細情報の開示要求に応じて、通信I/F44は、サーバ10から送信された、対応するユーザの詳細情報を受信する。通信I/F44は、受信した詳細情報を制御部41に送信する。制御部41の表示処理部412は、受信した詳細情報を表示部43に表示させる(ステップS806)。
表示された詳細情報を見て、企業サーバ40のオペレータは、詳細な見積もり額を決定する(ステップS807)。なお、この決定は、企業サーバ40が行ってもよい。例えば、引越し元と、引越し先、引越しする人数に基づいて引越し費用を算出するプログラムを予め記憶しておき、このプログラムを実行することで、見積額を算出することとしてもよい。
制御部41は、決定された詳細な見積もり額の情報を、通信I/F44に、送信させる。通信I/F41は、詳細な見積もり額の情報を、ネットワーク30を介して、ユーザの端末20に送信して(ステップS808)、処理を終了する。ステップS803において、ユーザからの詳細情報の開示の承認が得られなかった場合には(ステップS803のNO)、処理を終了する。
なお、図8のフローチャートには示していないが、詳細情報の開示を得た後に、実際に見積もりを策定するために、企業サーバ40のオペレータがユーザを直接訪問したうえで見積もりを行ってもよいことは言うまでもない。
以上が、企業サーバ40における詳細な見積もりを発行するまでの処理になる。
<具体例>
以上に説明した内容を、一具体例を用いて、よりわかりやすく説明する。まず、図9(a)は、ユーザが自身の端末20を用いて、見積もり依頼をする際の表示部24に表示される入力用のUIの一例を示す図である。図9(a)においては、引越しに係る最低限の必要事項として、引越し先に関する情報を入力する入力欄901と、引越し人数とを入力する入力欄902とを含む表示画面の例を示している。なお、入力欄901は、住所について詳細を入力する必要はなく、地域の情報までで留めてもよいし、留めなくてもよい。図9(a)に必要事項を入力して送信ボタンをクリックすると、端末20は、サーバ10に見積もり依頼を送信する(図5のステップS501参照)。
この見積もり依頼を受けて、サーバ10は、例えば、図9(b)に示すように、サーバ10が選定した企業サーバ40から見積もりが送付される旨が通知される(図5のステップS502参照)。図9(b)の例では、A社からE社までの5社からの見積もりが来る例を示している。そして、図9(b)に示されるように、各社に対しての評価についての情報が示される。図9(b)の例では、星形で評価を示しており、星の数が多いほど評価が高い。ただし、評価情報の表示方法は、図9(b)に示すものに限るものではなく、数値、文字色を用いた評価、文章による評価、など様々な態様を用いることが考えられ、サーバ10は、その評価情報を予め記憶、若しくは、ネットワークから取得して利用することができる。また、評価情報に基づく表示として、評価が数値で示される場合には、その評価を示す数値の降順、あるいは、昇順のいずれかで表示することとしてもよいし、しなくてもよい。また、評価が予め定められた閾値よりも低い場合には、その企業については、表示しないこととしてもよいし、しなくてもよい。そのような評価が低い企業については、予めサーバ10におけるふるい分けにより、評価の低い企業サーバ40に対しては見積もり依頼をしないように構成されていてもよいし、しなくてもよい。また、評価が他の所定の企業よりも低い企業については、画面上に表示しないように、ユーザがその設定ができるように構成されてもよいし、しなくてもよい。その設定がされている場合に、制御部11は、他の所定の企業の評価と、表示するか否かを決定する対象の評価とを比較し、他の所定の企業の評価よりも評価が低い場合には、表示しないと決定する。
また、図9(c)に示されるように、サーバ10が選択した企業サーバ40とユーザとの間のトークルームが開設される。なお、図9(c)は、ユーザの端末20に表示される画面例であって、トークルームの一覧を示す図である。トークルームの一覧は、トークリストと呼称することもある。図9(c)において、トークルームのいずれかを選択(タッチ)すると、その専用トークルームの表示に切り替わる。図9(c)に示すように、見積もりを行う各企業サーバ40とのトークルームがあることが理解できる。
例えば、図9(c)に示すA社引越しセンターを選択すると、端末20の表示部24には、図10(a)に示すように、A社引越センターとの間のトーク画面が表示される。図10(a)から理解できるように、A社引越しセンターは、引越しのおおよその見積もり額として、XXXXXX円を提示したことが理解できる。
また、ユーザが詳細な情報の開示を許諾する場合は、図10(a)の「開示する」と表示された箇所1001をタッチすることで、端末20からA社について端末20のユーザの詳細情報の開示を許可する旨をサーバ10に通知することができる。一方で、許諾しない場合は、図10(a)の「開示しない」と表示された箇所1002をタッチすることで、A社引越しセンターには、詳細情報を開示せず、以降は交渉をしないことになる。開示しない場合、端末20は、サーバ10に対して、以降の交渉を終了することを示す情報を送信してもよいし、しなくてもよい。なお、詳細情報を開示する企業の選択は、図10(a)を用いて説明した以外にも、例えば、図9(a)に示すような各企業とのトークの一覧の中から、詳細情報を開示する企業を選択する(タッチする)ことで決定してもよい。そして、この時に選択されなかったタッチされなかった企業とのトークは削除されるように構成されてもよい。
各企業サーバ40について、それぞれ詳細情報の開示の実行、非実行の入力が完了したら(完了していなくともよい)、ユーザはサーバ10とのトークにおいて、業者を決めたことを示す終了ボタン1011をタッチする。この終了ボタン1011へのタッチは、詳細な見積もりを依頼する業者を決めた段階でのものであってもよいし、実際に引越しを依頼する業者を定めた段階であってもよい。詳細な見積もりの依頼先を定めた段階の場合、その時点で、詳細情報を開示すると定めなかった業者については、トークルームを削除する。即ち、図10(c)に示すように、トークルームを削除する。図10(c)においては、ユーザがA社と、D社と、E社とを選択し、B社と、C社とのトークルームを削除した例を示している。
図9(c)から図10(c)への変化に見られるようにB社、C社、E社とのトークルームが削除されたことが理解できる。この後、A社とD社との間でユーザは見積もりのやり取り、実際のサービスの提供の依頼を行うことになる。
なお、詳細な見積もりを行う業者の選択、即ち、ユーザ自身の個人情報を開示する選択については、図10(a)に示した例に限るものではない。例えば、図11(a)に示すように、サーバ10とユーザとのトーク上のリッチメニュー1101という形式で選択できるように構成されてもよい。リッチメニューとはアカウント特有のメニューのことであり、トークに関与するユーザ、又は、サーバ10(のオペレータ)あるいは、企業サーバ40(のオペレータ)がその内容の設定を行うことができるメニューのことである。即ち、この場合、見積もりする業者の選択のための専用メニューのことをいう。一般的には、リッチメニューは、サービスを提供する側がユーザに対する利便性を提供するために、サーバ10又は企業サーバ40がその内容を設定する。
また、メッセージングサービスとして、業者とのやり取りをするための画像情報1111を予め用意しておき、ユーザが利用できるように構成されていてもよい。この画像は、サーバ10、あるいは、サーバ10が通信可能な他のサーバに保存され、ユーザは当該画像をダウンロードして利用することができ、スタンプと呼称されることもある。画像としては、限定ではなく一例として、図11(b)に示すように、価格交渉の画像であってよく、日程調整をお願いする画像などがあってよい。また、あるいは、ユーザにとって許容できる金額を示す画像情報や、その金額であればその企業に対してサービスを依頼する意思があることを示す画像情報であってもよく、この場合に、その画像情報に対して、金額は変更可能に構成されていてもよい。即ち、画像として表示する金額を、ユーザが端末20に対して金額を指定(入力)することとしてもよい。このような画像を予め用意し、提供することで、交渉事が苦手なユーザであっても、交渉をスムースに、気兼ねなく行えるようにすることができる。なお、ここでは、交渉、即ち、取引を、画像情報を用いて実行する例を示したが、これは、ユーザ自身が、取引のためのメッセージ(文字情報、テキスト)を直接トークルームに送信するものであってもよいのは言うまでもない。
また、本実施形態においては、引越しの見積もりを依頼する場合を一例として説明したが、見積もりの対象は、引越しに限るものではない。見積もりを要求する可能性のあるサービスについて、複数の競合他社が存在するサービスであれば、どのようなサービスであっても対象となり得ることは言うまでもない。簡単な情報でおおよその見積もりを出しつつ、詳細な情報で詳細な見積もりを出し得るものであればどのようなサービスでもよい。第1実施形態に示したシステムは、例えば、保険の見積もり、不動産売買の見積もり、士業の見積もり、病院の見積もり、社内システムの構築の見積もり、クラウドソーシングの見積もり、利用するECサイトの見積もりなどにも利用することができる。これらのうちのいくつかについて説明する。
保険の見積もりでいえば、ユーザ自身が希望する保険の種別や年齢等のユーザを特定できない程度の情報を提示する。ユーザは、その保険会社の評価情報を受け取る。保険会社の評価情報とは、限定ではなく一例として、保険会社の業績、ユーザの評価、コストパフォーマンス等に基づく評価を示す情報である。保険会社は、その段階での保険に係る費用の見積もりやプランの提示をしてもよいし、しなくてもよい。そして、その後にユーザが信頼した保険会社に対して詳細情報を開示して、詳細な見積もりをさせることができる。
また、例えば、不動産売買の見積もりでいえば、ユーザ自身が希望する物件の条件を提示する。ユーザは、その不動産会社の評価情報を受け取る。不動産売買の評価情報とは、限定ではなく一例として、不動産の売買実績、得意とする地域、コストパフォーマンス等に基づく評価を示す情報である。不動産会社は、その段階で希望に沿う条件、その場合の売買費用や賃貸費用等の見積もりを簡易的に提示してもよいし、しなくてもよい。そして、その後にユーザが信頼した不動産会社に対して、詳細情報を開示して、詳細な見積もりをさせることができる。
また、例えば、士業の見積もりでいえば、士業として弁護士に依頼をするにあたって、まず、どのような弁護を行って欲しいのか、どのような状況であるのかについて、ユーザが特定できない程度の情報のみを開示する。これに対して、ユーザは、その弁護士の評価情報を受け取る。弁護士の評価情報とは、限定ではなく一例として、得意とする分野、顧客評価、依頼費用等に基づく情報である。弁護士は、ユーザから簡易の情報を受け取っている段階で、おおよその対応費用の見積もりをしてもよいし、しなくてもよい。その後に、ユーザは、信頼した弁護士に対して、詳細情報を開示するように構成してよい。
また、例えば、病院の見積もりの場合は、病名や患者自身の容態等の情報のみの開示で、おおよその治療費用の見積もりを依頼する。これに対して、ユーザは、その病院や医者の評価情報を受け取る。病院や医者の評価情報とは、限定ではなく一例として、得意とする治療分野、医療実績、患者の感想、治療費等に基づく評価を示す情報である。評価情報を受け取った、その後に、ユーザが信頼した医者、病院等に対して、詳細情報を開示し、ユーザは詳細な見積もりを受け取ることとしてよい。
ECサイトの見積もりの場合、例えば、提供するサービスがある程度一致するサイト間での見積もりを行うことが考えられる。EC(Electronic Commerce)サイトとは、自社(他社を含んでもよい)の商品やサービスをインターネット上の独自運営のウェブサイトで販売するサイトのことをいう。ECサイトとしては、限定ではなく一例として、物品販売サービス、動画配信サービス、電子書籍販売サービス、旅行代理店サービスなどがある。限定ではなく一例として、旅行サービスを提供するECサイトで、ユーザが希望する旅行先、日時程度の、ユーザを特定できない情報を開示する。ユーザは、ECサイト各々の評価情報を受け取る。ここで、旅行サービスの場合のECサイトの評価情報とは、限定ではなく一例として、得意とする旅行先、得意とする人数、コストパフォーマンス等に基づく評価を示す情報である。ユーザからの情報に対して、ECサイト側は、おおよその見積もりやプランを提示する。そして、それらのうち、ユーザの心を引いたECサイトに対して詳細情報を提供するという構成をとってもよい。なお、ECサイトは企業による運営であってもよいし、個人による運営であってもよい。
このように、各種の業種に対して、本実施形態に係るシステムは有用である。なお、本第1実施形態においては、2段階の見積もりを出しているが、これは、その限りではなく、ユーザは評価情報のみで詳細情報を開示する対象となる業者(企業サーバ40)を決定する構成としてもよい。
<第1実施形態変形例>
(1)上記第1実施形態においては、サーバ10が、ユーザと企業サーバとの双方から詳細情報の開示要求があった場合に、サーバ10が保持するユーザの詳細情報を、企業サーバに送信する構成としているが、ユーザの詳細情報を企業サーバ40に送信する手法はこれに限られるものではない。ユーザ自身が、自身の詳細情報を直接企業サーバ40に宛てて送信してもよいことは言うまでもない。また、端末20において表示する情報の取捨選択は、端末20が自身で行うこととしてもよいし、サーバ10から指定されたものであってもよい。
(2)また、上記第1実施形態においては、評価情報としては、企業サーバ40各々の企業全体としての評価を示すものとして説明した。しかし、評価情報は企業そのものの評価に限るものではない。企業サーバ40が提供するサービスを担当する実際の担当者の評価を示すものであってもよい。限定ではなく、一例として、図12(a)に示すように、企業について、担当者の評価情報がある場合には、その担当者の評価情報も示してもよいし、示さなくてもよい。図12(a)は、ユーザの端末20の表示部24に示す画面例であって、サーバ10とユーザとの間のトークルームを示す画面図である。図12(a)に示すように、企業名に対応付けて担当者の名前とその評価が示される。ここでは、担当者の評価として、文章で担当者がどのような担当者であるかを表現した評価を示した例を示しているが、担当者の評価は、このような文章による評価に限らず、記号や数値等により担当者の評価を数値化した情報での表現であってもよい。また、名前だけでなく、担当者の顔写真などを併せて表示するようにしてもよい。図12(a)の例では、B社においてユーザのサービスを受けた場合に担当する担当者として、Hが担当し、その評価として、「迅速で無駄のない仕事ぶり」が示された例を示している。また、担当者の評価がある場合には、企業の評価については、あってもよいし、なくてもよい。そのために、サーバ10は、予め、企業サーバ40各々に属する担当者それぞれの評価を示す担当者評価情報を記憶部15に記憶していてもよいし、しなくてもよい。記憶していない場合には、通信により企業サーバ40から取得することとしてよい。また、担当者の評価と、企業そのものの評価と、を並列表記してもよいことは言うまでもない。
(3)また、上記第1実施形態においては、企業サーバ40各々の評価情報のみを表示しているが、それらの企業サーバ40の中から、ユーザに対して、おすすめの企業を特定し、おすすめである旨が端末20の表示部24に表示されるように構成されてもよい。ここで、このおすすめの表記の実現例について説明する。
サーバ10の制御部11は、ユーザからの見積もり依頼を受信した際に、ユーザ情報200を用いて、ユーザの嗜好に合致する企業を特定する。そして、特定した企業については、評価情報を送信する際に、おすすめである旨を通知する。この通知は、おすすめである企業が他の企業と比較してわかるようなものであれば、どのような態様であってもよく、例えば、おすすめを示す画像、あるいは、文字が、企業名と連動して表示される(限定ではなく一例として、企業名におすすめの画像あるいは文字が噴出しで表示される)ようにしてもよいし、おすすめの企業が、おすすめでない企業とは異なる表示色で表示することとしてよい。この表示態様は、端末20が決定してもよいし、サーバ10が指定してもよい。図12(b)には、ユーザの端末20の表示部24において、おすすめの企業を示した例を示している。図12(b)は、ユーザの端末20の表示部24において、ユーザとサーバ10との間のトークルームの一例を示す図であって、サーバ10からユーザからの見積もり依頼に対して、送信される情報を表示した画面であり、企業サーバ40から見積もり額の通知が送信される旨を連絡することを示す画面である。図12(b)の例では、B社がおすすめであることを示すように、B社の名称を他社と異なる態様で表示する。このとき、図12(b)に示すように、ユーザにとってより分かりやすく「オススメ」等の文言を社名に対応付けて表示するようにしてもよいし、しなくてもよい。このように、ユーザに対して、複数の企業を紹介するとともに、その中で、サーバ10からみてユーザにとっておすすめとなる企業が見て取れる態様で企業名を表示することで、企業の一覧の中で、ユーザに対しておすすめの企業がどれかを一目でユーザに理解させることができる。
また、サーバ10によるおすすめ企業の決定方法としては、ユーザ情報200に、更に、ユーザの嗜好情報を含ませるとともに、サーバ10が記憶部15に企業サーバ40の特色を示す情報を記憶しておくことにより実現することができる。限定ではなく一例として、ユーザの嗜好として、処理速度が迅速であることを好むという情報が対応付けられている場合には、迅速対応を旨とする企業をおすすめとし、他の例として、ユーザの嗜好として、作業時の雰囲気を重視するという情報が対応付けられている場合には、和気藹々とした雰囲気での仕事をすることを示す情報が対応付けられている企業をおすすめとして選択する。即ち、サーバ10の制御部11は、ユーザの嗜好情報と、企業サーバ40に対応する企業各々の仕事をする上での特色、モットー等の情報と、の一致度合いに基づいて、おすすめとするか否かを判定する。このようにして、サーバ10及び端末20は、依頼する企業サーバ40を決定するうえで、よりユーザにとって利益となる情報を提供することができる。
(4)また、上記第1実施形態においては、詳細な見積もりを受け取るところまでを説明している。実際には、その後に、ユーザは、サービスを依頼する企業サーバ40を決定し、その企業サーバ40からサービスの供与を受けることになる。その際、即ち、企業サーバ40からのサービスを受けた後に、ユーザは、自身の端末20を用いて、サーバ10に対して、企業サーバ40のユーザ自身の所感による評価を示すユーザ評価情報を送信することとしてよい。そして、サーバ10は、このユーザ評価情報を記憶部15に記憶する。サーバ10の制御部11は、各ユーザから、各企業からのサービスを受けた場合のユーザ評価情報を、各企業の評価情報に反映することとしてもよいし、しなくてもよい。制御部11は、ユーザ評価情報を受信する都度、企業の評価情報に反映させることとしてもよいし、させなくてもよい。また、あるいは、ユーザ評価情報の企業の評価情報への反映は、所定期間毎(例えば、1ヶ月毎)に実施されてもよいし、されなくてもよい。こうすることで、より現在時間に近い企業の生の情報を用いて、企業の評価をすることできる。
また、ここでは、企業に対する評価としているが、実際の作業をした担当者の評価を、送信することとしてもよく、その両方を送信することとしてもよいし、しなくてもよい。
<実施形態の効果>
以下、第1実施形態の効果について説明する。
上記第1実施形態に係る端末20は、ユーザからユーザの情報としてユーザ自身を特定できない程度の情報(見積もり依頼、限定ではなく第1情報の一例)をサーバ10に送信し、サーバ10から見積もりに基づいて依頼を受ける企業サーバに関する情報の一例として評価情報を受信して表示する。
これにより、端末20のユーザは見積もりを依頼する企業を決定する際に、自身で様々な情報の収集を行わずとも、企業の評判等の情報を視認することができるので、サービスを依頼する際の企業間の比較検討の際のユーザの手間を軽減することができる。
また、サーバ10は、端末20に対して、端末20からの依頼に対する応答として、見積もりをする企業各々の評価情報を送信する。
これにより、サーバ10は、端末20のユーザに対して、企業のサービス等の評価に関する情報を伝えることで、ユーザに対して、サービスを依頼する企業を決定する際の補助となる情報を提供して、ユーザの利便性を向上させることができる。
また、端末20は、各企業サーバとのトークルームにおいて、ユーザ自身の詳細情報の開示を承諾することによって、あるいは、ユーザ自身が詳細情報を送信することで、ユーザ自身の詳細情報がサーバ10から、各企業サーバにユーザの更なる情報を送信する。
これにより、ユーザの更なる情報を、企業サーバに送ることで、企業サーバに詳細な見積もりをしてもらうことができる。
また、サーバ10は、企業サーバ40からのユーザの詳細情報の開示の依頼を受けると、ユーザの更なる情報を送信する。
これにより、サーバ10は、企業サーバ40が詳細な見積もりをする上での必要となる情報を提示することができ、企業サーバ40の見積もり業務の利便性を向上させることができる。
また、端末20は、サーバ10から送信された企業の評価情報に基づいて、各々の企業の表示態様、即ち、文字色や文字の大きさなどを変更して表示することができる。例えば、各企業の評価の高さを示す情報の一例として、評価の高い企業の表示色を、評価の低い企業の表示色と変えて表示したりすることができる。
また、サーバ10は、端末20に対して、各企業の評価を示す表示情報を送信するように構成してもよい。
これにより、端末20は、各企業の評価をその表示態様を変えることによって示すことができ、ユーザにその企業の評価を認識させることができる。
また、端末20は、サーバ10から送信された企業の評価情報に基づいて定まる表示順序にしたがって、各企業を示す情報を表示することとしてもよく、サーバ10から端末20に対して評価情報を送信する際に、その評価情報に基づく順序で各企業サーバ40を示す情報を示した表示情報を送信することとしてもよい。
これにより、ユーザは、サービスを提供する企業が表示された順序に従って、各企業間の評価の高低を認識することができる。
また、端末20は、サーバ10から送信された評価情報に基づいて、所定の企業と比較して、評価の低い他の企業については、表示しないこととしてよい。
また、サーバ10は、評価情報として、評価情報で示される評価に従って、見積もりをする予定の企業として表示するか否かを示す情報を含むようにして送信することとしてよい。
これにより、端末20においては、評価が低いとされる企業については、表示しないようにすることで、ユーザがその企業に対する依頼をしないようにすることができる。したがって、ユーザが評価の低い企業に実際のサービスを依頼することでサービスを受けた際の不満が発生する可能性を抑制することができる。
また、各企業の評価を示す評価情報というのは、限定ではなく一例として、評価の高さの度合を示す情報(評価そのものを示す情報)であってもよい。
これにより、ユーザは直接かつ容易に各企業の評価を認識することができ、サービスを依頼する企業を決定するのに、分かり易い指標を得ることができる。
また、端末20のユーザは、自身の詳細情報を開示してよいと判断した企業サーバ40に対して送信する詳細情報を、サーバ10に送信することとしてよい。また、サーバ10は、端末20から、直接ユーザの詳細情報を受信するように構成してよい。
これにより、ユーザとしては、その都度、サービスを提供する企業サーバ40に対して開示する詳細情報を定めて送信することができる。また、サーバ10は、サーバ10がユーザの詳細情報を保持していない場合などには、ユーザの端末20からこれを得ることで、企業サーバ40に対して送信して、企業サーバ40に見積もりを依頼することができる。
また、端末20は、実際にその企業においてサービスを実施する担当者に関する情報として、担当者の評価を示す情報を受信することとしてよい。その担当者の評価を示す情報は、サーバ10から、端末20に送信することとしてよい。
これにより、ユーザは、自身が実際に接することになる担当者がどのような人物であるかを認識した上で、依頼をすることができるので、満足の高いサービスを受けることができる可能性が高くなる。
また、端末20は、サーバ10がおすすめする企業サーバ40を、他の企業サーバ40から区別して表示することができる。この、おすすめの企業サーバ40は、端末20のユーザの嗜好に合致する企業を、サーバ10が選択する。
これによって、端末20及びサーバ10は、ユーザに対して、ユーザにとってより好適なサービスを提供する企業サーバ40がどの企業であるかの情報を提供することができ、サービスを依頼する企業を選択する際のユーザの一助とする、即ち、判断材料を提供することができる。
また、端末20は、ユーザが企業サーバ40と交渉(取引)をするための情報をサーバ10に送信する。そして、サーバ10は、その交渉(取引)をするための情報を受信し、企業サーバ40に送信する。取引を示す情報は、メッセージ(文字情報)であってもよいし、取引の内容を示す画像であってもよい。
これにより、ユーザは、端末20を用いて、サーバ10を介して、企業サーバ40との間で、サービスを受ける上での取引をするための交渉を行うことができる。したがって、ユーザは、自身にとって、より好ましい条件でのサービスの提供を企業サーバ40に対して依頼することができる。
また、ユーザは、端末20からサーバ10に、企業サーバ40のサービスを享受した後に、ユーザ自身の所感である評価を示すユーザ評価情報を送信することとしてよい。なお、この評価は、実際に担当した企業サーバ40の担当者の評価を示す情報であってもよいし、その両方であってもよい。
これにより、端末20は、ユーザがサービスを受けたうえでのユーザ自身の企業あるいはその担当者に対する評価をサーバ10に送信することができる。そして、サーバ10は、その評価を受け取って、以降において、他のユーザに対して評価情報を提示する際に、その評価情報にユーザの評価を反映させて、よりリアルタイムの評価に関する情報を提供することができる。
また、端末20は、各企業を示す一覧(例えば、企業名の一覧や、対応するトークの一覧)を表示する。そして、端末20は、見積もりを行う各企業それぞれについて、自身の詳細情報を開示するか否かの選択をユーザから受け付ける。そして、端末20は、詳細情報を開示しないと決定した企業サーバ40との間の通信は、終了する。
これにより、ユーザにとって、不要となった企業との間の通信は終了することができ、以降、その企業との間の通信を行わずに済むので、例えば、取引を行わない企業からの営業活動などを受けずに済む。
また、端末20は、各企業それぞれとの間でサーバ10により立ち上げられたトークルームを介して、個別に交渉を行うことができる。
したがって、ユーザは、それぞれの企業との間で、他の企業とのやり取りやその状況を知られることなく、交渉を行うことができ、自身によって有利になるように取引を行うことができる。
また、端末20は、サーバ10との間のトークルームにおいて、リッチメニューを介して、取引を行う企業サーバ40それぞれの情報を表示することとしてもよい。
これにより、サーバ10が提供するサービスを享受するユーザ各々で異なった態様での情報の提供が可能になる。
<第2実施形態>
上記第1実施形態においては、ユーザが詳細情報を開示せずとも、ある程度の見積もりをしてもらい、信頼した業者に対して詳細情報を開示して、詳細な見積もりをしてもらうことができる例を説明した。これにより、ユーザの不必要な情報の拡散が防ぐことができ、業者による営業電話等の連絡が増加するのを抑制することができる。一方で、第1実施形態に示した見積もりをするシステムを利用する際に、実際の請求額との乖離が発生することがありえるが、サーバ10ではそのような乖離があったとしても認識するすべはなく、また、企業側にとっても、上層部がそのような乖離を認識できていない可能性もある。
このような見積もりの乖離は、限定ではなく一例として、見積もりを取る段階で、業者(担当者)が仕事を受けたいがために、いたずらに見積もり額を抑えて、実際の請求時には、本来の金額で請求したり、あるいは、請求時に請求者が不当に多く請求したりしている場合などが考えられる。そのような見積もりと実際の請求との間の乖離は、ユーザの不満を生むことになり、結果として、企業の評判の低下にもつながるという問題を内包している。そこで、本第2実施形態においては、そのような見積もりと、実際の請求との乖離を抑制することができるシステムについて説明する。
なお、本第2実施形態における処理は、見積もりを行い、実際にサービスを依頼したあとで、サービス側が請求書を発行する前後からの処理となる。そのため、構成としては、第1実施形態の図1に示した構成と変わらないため、共通する機能、処理については、本第2実施形態における説明は割愛する。
<構成>
サーバ10は、第1実施形態に示した機能に加えて、ユーザに対して、請求額の情報の提供を促す機能と、請求額の情報の提供をユーザから受けた場合に、何らかの特典を送信する機能とを有する。
制御部11は、ユーザと企業との間で契約が成立した場合に、このユーザとのトークにおいて、企業からの請求額の情報の提供を促す機能として、ユーザとサーバ10との間のトークルームに、企業から請求された金額に関する情報(限定ではなく一例として、金額の情報の直接の書き込みや、請求書のスキャンデータなど)の提示を依頼する文書を送信する。そして、その際には、請求された金額に関する情報を提示した場合には、ユーザに対して特典が与えられる旨も併せて通知する。
また、制御部11は、ユーザとサーバ10との間のトークルームに対して請求額についての情報が書き込まれた場合に、ユーザに対して特典を送信する。ここでいう特典は、ユーザにとって何らかの形で利得があるものであればなんでもよく、限定ではなく一例として、メッセージングアプリケーション上で利用できるポイント、他のサービスで金銭として利用可能なポイント、電子マネー、仮想通貨、何らかの物品、物品と引き換えるための引き換え券または電子引き換え券、または端末上でくじ引きが引けるサービスなどであってよく、これらの組み合わせであってもよい。また、特典としてポイントを送信するとは、メッセージングアプリケーション上でのユーザの識別子(ユーザID)に対応付けられているポイントに、特典に相当するポイントを加算することを意味する。同様に電子マネーを送信するとは、ネットワーク上でのユーザの識別子に対応付けられている電子マネーに、特典に相当する金額を加算することを意味する。仮想通貨を送信するとは、電子マネーの送信とほぼ同義であるが、ある定められたサービス内でのみ通用する金銭の代替物となる情報としての金額を、ユーザに対応付ける(加算する)ことを意味する。また、物品を送信するとは、物品をユーザに宛てて送付することを通知するとともに、ユーザの住所に宛てて、その物品を実際に送付することを意味する。また、物品と引き換えるための引き換え券または電子引き換え券を送信するとは、何らかの物品と引き換え可能であることを示す表示情報を送信することを意味する。引き換え券または電子引き換え券は、その物品を提供する店舗にその表示情報を提示することでその物品と交換が可能な情報(権利)である。また、端末上でくじ引きが引けるサービスを送信するとは、端末上で行う電子くじを引く権利をユーザに与えることをいう。ここでいう電子くじは、何らかの景品がもらえるものであり、一例として、サーバ10が提供するメッセージングサービスにおいて使用可能なポイントや、何らかの電子情報(例えば、壁紙)、金銭、何らかの物品が当選するものであってよい。
一方、端末20は、ユーザからの指示に基づき、企業サーバ40から請求された請求額の情報の入力を入出力部23を介して受け付けて、サーバ10に送信する。請求額の情報の入力は、入出力部23のタッチパネル231に対してユーザが直接金額を入力したものを受け付けることとしてもよいし、カメラ234が撮像した請求書の画像情報を受け付けるものであってもよい。端末20の制御部21は、通信I/F22を介して、サーバ10との間のトークルームに送信する。
また、端末20の通信I/F22は、サーバ10から送信された特典を受信する機能を有する。制御部21は、受信した特典情報を記憶部28に記憶することとしてもよいし、しなくてもよい。
<動作>
図13に示すシーケンス図を用いて、実施の形態2に係る通信システムにおける各装置間のやり取りについて説明する。図13は、図5に示すシーケンス図の後の処理であり、図13においては、図5のステップS508以降の処理を示している。
図13に示すように、詳細な見積もりをうけとった端末20のユーザは、その見積もり内容に納得がいった場合には、その企業サーバ40にサービスの依頼(引越しの依頼)をする(ステップS1301)。また、ユーザは端末20を用いて、サーバ10との間のトークルームにおいて、決定した引越し業者を通知する(ステップS1302)。
引越し業者の決定の通知を受け付けると、サーバ10は、ユーザに対して、請求書を要求する請求書要求を送信する(ステップS1303)。即ち、サーバ10は、端末20との間のトークルームにおいて、引越し後に企業サーバ40から送信された請求書、又は、請求書で示される請求額の情報を、トークルームに送信を依頼する通知を行う。
実際に引越しを終えた後、企業サーバ40は、端末20に請求書を送付する(ステップS1304)。なお、図13においては、企業サーバ40から端末20に送付するということで電子データの形で送付することとしているが、請求書は、別途郵送であってもよいし、ユーザに直接手渡しされるものであってもよい。なお、ステップS1303とステップS1304の処理は逆順で処理されてもよい。即ち、ステップS1304を先に実行し、その後にステップS1303を実行するように構成されてもよい。また、ステップS1303とステップS1304の処理は同時並行で実行されてもよい。
ユーザは、請求書を受け取ると、サーバ10との間のトークルームを介して、請求情報を送信する(ステップS1305)。請求情報を送信するとは、トークルームに対して請求額を直接書き込むことであってもよいし、請求書の電子データを送信することであってもよいし、請求書の実物をスキャンしたデータを送信することであってもよい。
ユーザからの請求情報を確認したサーバ10は、ユーザの端末20に対して、予め定められた特典を送信する(ステップS1306)。
図13に示すやり取りを実現するためのサーバ10の処理について、図14に示すフローチャートを用いて説明する。
サーバ10の通信I/F14は、業者決定情報を、ユーザの端末20から受信する(ステップS1401)。通信I/F14は、受信した業者決定情報を制御部11に送信する。
業者決定情報を受信した制御部11のメッセージ処理部112は、ユーザとの間のトークルームに対して、請求に関する情報を要求する請求書要求を送信する(ステップS1402)。
その後に、制御部11は、ユーザから請求書情報を受信したか否かを判定する(ステップS1403)。制御部11のメッセージ処理部112は、ユーザとの間のトークルームに請求書情報が送信されていた場合に(ステップS1403のYES)、制御部11は、ユーザに特典を送信して(ステップS1404)、処理を終了する。一方、ユーザが請求書情報を送信しなかった場合、即ち、請求書情報を受信しなかった場合(ステップS1403のNO)には、ユーザに対しては特典を送信しないで、処理を終了する。ここで、請求書情報を受信しなかった場合とは、ユーザ自身から、請求額の情報を送信するつもりがないとの意思表示があった場合、もしくは、ユーザがサービスを受けてから所定時間が経過しても請求書情報を受信できなかった場合に、請求書情報を受信しなかった場合としてよい。以上が、サーバ10の処理である。
図15は、図13のシーケンス図に示すやり取りを実現するための端末20の処理を示すフローチャートである。
ユーザは、自身の端末20から業者決定情報をサーバ10に送信する(ステップS1501)。限定ではなく一例として、ユーザは、自身の端末20を用いて、サーバ10との間のトークルームを介して、業者決定情報を送信する。
業者決定情報の送信に応じて、端末20の通信I/F22は、サーバ10から請求書情報の送付の依頼を受信する。通信I/F22は、サーバ10からの請求書情報の送付の依頼を受信すると、メッセージ処理部211に送信する。メッセージ処理部211は、受信した請求書情報の送付の依頼を示す文書情報をトークルーム上に示す情報を表示処理部212に表示するよう指示する。表示処理部212は、この指示を受けて、表示部24に、請求書情報の送付の依頼を示したトークルームの画像を表示させる(ステップS1502)。
その後に、ユーザは、企業サーバ40のサービスを受ける(例えば、引越しをする)。そして、ユーザの端末20は、企業サーバ40から請求書情報を受信する(ステップS1503)。なお、この請求書情報の受信は、上述の通り、手渡しであってもよいし、郵送であってもよい。
サービスを受けた企業サーバ40から請求書を受け取ったユーザは、その請求書で示される請求額に関する情報を、通信I/Fを介して、サーバ10に送信する(ステップS1504)。限定ではなく一例として、ユーザは、端末20を用いて、ユーザとサーバ10との間のトークルームを介して送信する。
通信I/F22は、請求書情報の送信に応じてサーバ10から送信された特典を受信して(ステップS1505)、処理を終了する。
<具体例>
ここから、本第2実施形態について、具体例を用いて説明する。図16(a)、(b)は、サーバ10と端末20との間のトークルームにおけるコンテンツ(メッセージ、スタンプ、画像、動画など)のやり取りの例を示す画面図である。
図16(a)は、ユーザが直接請求額を書き込んだパターンを示しており、図16(b)は、請求書の写真(ユーザが端末20のカメラ234を用いて請求書を撮像した撮像画像、もしくは、請求書のスキャンデータ)をトークルームに貼り付けたパターンを示している。
図16(a)に示すように、ユーザは、各企業サーバ40からの見積もりを見て、納得のいった業者との契約を果たす。その場合に、ユーザは、図16(a)のメッセージ1601に示すように、サービスを受ける企業が決定した旨をトークルームに書き込む。図16(a)に示す例では、ユーザは、サービスを提供する業者として「A社」に決定したことを示している。
これに対して、サーバ10は、ユーザに対して請求が発生したときの金額の情報の開示を要求するメッセージを送信する。図16(a)では、メッセージ1602に示すように、サーバ10(のオペレータ)が、最終の金額の提示を要求するとともに、請求額の提示をした場合に、特典、即ち、なんらかの報酬が与えられることを示すメッセージを書き込んだ例を示している。このメッセージ1602をサーバ10が実行するタイミングとしては、ユーザからサービスを依頼する企業が決定したことを示す情報のメッセージ1601の送信があった後であればいつでもよいが、基本的には、メッセージ1601が送信されたすぐ後、あるいは、ユーザからサービスを受ける日時の情報をメッセージ1601で受けていた場合には、その日時の後であってもよい。
実際のサービスを受けた後、ユーザは、請求額についての情報を書き込む。図16(a)に示す例では、メッセージ1603に示すように、請求額がXXXXXX円であったとの書き込みを行った例を示している。
このユーザが書き込んだメッセージ1603に対して、サーバ10は、特典が送信される旨のメッセージ1604の書き込みを行い、実際に特典を送信する。
このようにして、ユーザはサーバ10との間で請求額のやり取りを行う。なお、図16(b)と、図16(a)との差異は、メッセージ1603と画像1613との差異のみであり、図16(b)の例では、画像1613として、請求書の画像データをトークルームに貼った点で異なり、それ以外については、共通する。
このようにして、サーバ10は企業サーバ40が実際に行った請求の額面を認識することができる。なお、ここでは、ユーザから直接請求額の情報を受信することとしているが、ユーザが、例えば、メッセージングアプリケーションで使用できる仮想マネー、またはポイント決済を利用した取引を利用して、企業サーバ40に対する支払いを行った場合には、その支払い情報を参照して、請求額に関する情報を、ユーザから聞かずとも、取得することができる。なお、サーバ10を介して電子取引を行った場合にその請求額の情報をサーバ10が取得する条件として、ユーザから予め許可を得ているか、トークルーム上で請求額の確認を行ってもよいとの許可を求めてその許諾を得ているか、していることが望ましい。
<見積もり額まとめ通知>
上記第1実施形態及び第2実施形態においては、各企業サーバ40は、各々個別にユーザとの間で立ち上げられたトークルームを介して、見積もりについてのやり取りを行うこととしているが、企業サーバ40によっては、いち早く安めの見積もりを出して、依頼を受けようとする企業サーバ40が存在する可能性がある。そのような場合、その見積もりを見たユーザは、その安さに他の企業サーバ40からの見積もり連絡を待たずに依頼をしてしまう可能性がある。
そこで、企業サーバ40が一端各企業サーバ40からの見積もりを収集し、一定数の見積もりが得られたところで、まとめてユーザに見積もり額を通知するという構成を採ってもよいし、採らなくてもよい。
具体的には、サーバ10は、図17に示すように動作してもよい。図17に示す処理は、ユーザの端末20から見積もりを受け付けて、各企業サーバ40からの見積もりが後に送付される旨の通知を行った後の処理になる。
図17に示すように、サーバ10の通信I/F14は、業者、即ち、各企業サーバ40から、ユーザが行った見積もり依頼に対して行った見積もりの額を示す見積もり情報を受信する(ステップS1701)。通信I/F14は、受信した見積もり情報を制御部11に送信する。制御部11は、受信した見積もり情報を、その見積もり情報を送信した企業サーバ40を示す識別情報と対応付けて記憶部15に記憶する。
制御部11は、見積もり情報を受信すると、ユーザに対して見積もりを行う複数の企業サーバ40のうち、所定数以上の企業サーバ40から見積もり情報を受信しているか否かを判定する。即ち、制御部11は、ユーザの見積もり依頼に対して企業サーバ40から送付され、記憶部15に記憶されている見積もり情報の数が、所定数以上であるか否かを判定する(ステップS1702)。ここで、所定数は、ユーザが見積もり額の比較検討を行えるだけの数があればよいので、少なくとも2個であればよく、見積もりを行う企業サーバ40の総数と一致することとしてもよい。
見積もり情報の総数が所定数以上でない場合には(ステップS1702のNO)、ステップS1701の処理に戻り、次の、見積もり情報の受信まで待機する。見積もり情報の総数が所定数以上である場合には(ステップS1702のYES)、制御部11は、それらの見積もり情報を纏めて、ユーザとのトークルームに、企業サーバ40各々の見積もり額を比較が可能なように送信する(ステップS1703)。ここで、見積もり情報を纏めて送信とは、トークルーム上に、各見積もり情報で示される金額を直接ユーザとの間のトークルーム上に、サーバ10が書き込むものであってもよいし、見積もり情報そのものを順にトークルームに送信することであってもよい。
これにより、サーバ10は、見積もりを行う何れかの企業サーバ40が、他の企業サーバ40が先駆けて安い見積もりを行って、依頼を受けることができるのを防止できる。また、サーバ10は、ユーザにどの企業サーバ40に依頼をするかの検討を、見積もり額に基づいて行う機会を与えることができる。
図18は、所定数の企業サーバ40からの見積もりを受信した場合に、ユーザが見ることができるトークルームの画面例を示す図である。図18では、メッセージ1801に示すように、A社と、D社と、E社との3社からの見積もり額を纏めて、ユーザに対して送信したことが理解できる。図18の例では、A社がXXXXXX円、B社がYYYYYY円、C社がZZZZZZ円である例を示している。このとき、各企業が行った見積もり額の降順(あるいは昇順)で、各企業の企業名(識別情報)と、その見積もり額を表示してもよいし、しなくてもよい。
なお、図18では、メッセージ1801をサーバ10が行って、複数の企業サーバ40からの見積もり額を並列することとしているが、これは、各企業サーバ40がそれぞれ送付した見積もり情報をそのまま順番に送信することで実現されてもよい。
また、ここでは、詳細には記載しないが、上記第1実施形態に示した態様は、第2実施形態にも適用することとてもよいし、しなくてもよい。
例えば、図11(a)に示したリッチメニューを利用したユーザとサーバ10との間のやり取りは、本実施形態にも適用可能であり、本実施形態であれば、限定ではなく一例として、リッチメニューとして、見積もり額に係る情報を送信するための送信ボタン、請求額に係る情報を送信するための送信ボタンが設定されたリッチメニューを用いることができる。これらの送信ボタンを押すことにより、例えば、ユーザの端末20内の記憶部28に記憶された見積もり額の情報(データファイル)や、請求書の情報(データファイル)を指定することで、サーバ10に対して、それらの情報が送信される構成になっていてよく、その場合に、ユーザの入力の手間を軽減することができる。
また、本第2実施形態においても図11(b)に示したように、ユーザ又はサーバ10(のオペレータ)は、見積もり額および請求額に係るやり取りにおいて、メッセージングサービス上で利用可能な画像情報(スタンプ)を用いたやり取りをしてもよいし、しなくてもよい。限定ではなく一例として、サーバ10は、ユーザが請求額の情報をトークルームに送信した場合に、感謝の意を表す画像情報を送信することとしてもよい。
また、端末20は、請求額の送付とともに、請求額に係るユーザの企業サーバ40に対する評価を含むユーザ評価情報を、サーバ10に対して送信することとしてもよい。
<第2実施形態変形例>
(1)上記第2実施形態においては、サーバ10が端末20に対して特典を送信するところまでで処理を留めている。しかしながら、サーバ10は、更に、企業サーバ40が行った請求額の情報を受信したことにより以下の処理を実行してもよい。即ち、サーバ10は、請求額が見積もり額から、一定金額以上乖離していた場合に、その企業の評価情報を補正することとしてもよい。
例えば、サーバ10の制御部11は、請求額から見積もり額を減算した差分が、所定額よりも大きい場合には、請求額の方が見積もり額よりもかなり多いとして、企業サーバ40の評価情報を下げる補正をしてもよいし、しなくてもよい。また、サーバ10の制御部11は、請求額から見積もり額を減算した差分が、所定額よりも小さい場合には、見積もり額の方が請求額よりもかなり少ないとして、見積もりよりも少ない金額での請求を行う企業であるとして、企業サーバ40の評価情報を上げる補正をしてもよい。評価情報の上げ下げは、評価情報が数値やレベル等で設定されていれば加減算により実行することができる。また、文章による評価情報を追加することもできる。
(2)上記第2実施形態においては、サーバ10は、ユーザの端末20から請求額の情報を受信することとしているが、これは、企業サーバ40から受信するものであってもよい。また、端末20と企業サーバ40との双方から、請求額の情報を受信することとしてもよい。
(3)上記第2実施形態においては、サーバ10の制御部11は、所定数の見積もりが到来するまでは、待機し、所定数の見積もりを受信すると、まとめて端末20に送信する構成としたが、これはその限りではない。見積もりの数ではなく、時間によって、見積もりを送信することとしてもよい。即ち、サーバ10の制御部11は、各企業サーバ40に対して見積もり依頼を送信してから、所定時間(例えば、48時間)を計測する。そして、所定時間が経過すると、その時点で受信している見積もりの情報を、見積もり情報の数に関わりなく全て端末20に送信するように構成されてもよい。また、所定時間の経過を待って見積もり情報を端末20に送信する場合には、サーバ10がそれらを纏めて送信してもよいし、纏めて送信しなくてもよい。
(4)上記実施の形態2においては、サーバ10は、ユーザの端末20から請求額に関する情報を送信してもらうことによって、企業サーバ40が実際に行った請求に関する金額の情報を得ていたが、これはその限りではない。サーバ10が、電子マネー等による支払いの支払いサービスを有し、端末20がその支払いサービスを利用して、企業サーバ40に対して支払いを行った場合には、サーバ10は、自動的に、端末20から企業サーバ40に対してされた支払い額を、請求額に関する情報として取得することとしてもよい。この場合、端末20と、企業サーバ40と、から支払額の情報をサーバ10が取得することについて了承を得ていることが望ましい。
(5)上記実施の形態1又は2において、サーバ10の制御部11は、見積もりをする企業サーバ40各々について、その企業サーバ40が請求する請求額を予測し、予測した請求額に関する予測請求額の情報を端末20に送信してもよいし、しなくてもよい。制御部11は、各企業サーバ40について、過去に行ったサービスと、サービス内容の情報、そして、その際の請求額の情報を記憶部15に記憶する。これらの情報は、サーバ10がアクセス可能な外部の装置に記憶されていてもよい。
制御部11は、ユーザが行う見積もり依頼に対して、その内容と所定以上の相関を有するサービス内容の情報を有するデータを、見積もりを行う企業ごとに取得する。そして、相関の高いサービス内容が実行された際に、企業サーバ40が行った請求の額を、請求額の予測値である予測請求額として、新たに見積もり依頼をしてきたユーザに対して、送信することとしてもよい。複数の相関の高いデータが取得できた場合には、例えば、その平均値を、請求額の予測値である予測請求額として、送信することとしてもよいし、複数の請求額の中で最も高い金額、あるいは、最も安い金額を、予測請求額として、ユーザの端末20に送信することとしてもよい。なお、請求額の予測の手法はこれに限るものではなく、様々な手法を用いることができ、サーバ10のオペレータが好適と判ずる予測方法を用いるとよい。その他の手法としては、限定ではなく一例として、例えば、制御部11は、企業ごとに、その企業が過去に提供したサービスの内容と、請求した請求額に基づいて、サービスの内容から請求額を学習した学習モデルを構築し、その学習モデルに対して、ユーザが行った見積もり依頼を入力して、請求額を算出することとしてよい。
制御部11は、ユーザが見積もり依頼を行った後、各企業から見積もり情報が送信された後(される前でもよい)であって、ユーザが実際にサービスを依頼する企業を決定する前に、端末20に対して、算出した予測請求額の情報を送信する。そして、端末20は受信した予測請求額の情報を表示部24に表示する。このとき、端末20は、企業サーバ40が送信した見積もり情報と、サーバ10が予測した予測請求額とを併せて比較可能に表示部24に表示することとしてもよいし、しなくてもよい。また、予測請求額はサーバ10による予測額である旨を示す情報を併せて表示してもよいし、しなくてもよい。また、予測請求額に代えて(あるいは共に)、予測請求額と見積もり額との差分を表示してもよい。このように、サーバ10は、予測される請求額をユーザに、サービスを依頼する企業を決定するための判断材料として提供することとしてもよい。
<実施形態の効果>
上記第2実施形態において、端末20のユーザは、企業サーバ40から見積もりを受領したうえで、サーバ10に対して、企業サーバ40からのサービスを受けた後に、企業サーバ40から請求された請求額の情報を送信する。サーバ10は、その請求額の情報を受信する。
これにより、サーバ10は、企業サーバ40が行った見積もりと、請求とのそれぞれの額面に関する情報を取得することができる。したがって、サーバ10は、企業サーバ40が行っている見積もりと請求との間に、乖離があるか否かを認識することができる。よって、限定ではなく一例として、見積もりと請求との間に乖離がある場合には、その企業サーバ40の評価を下げたりすることができる。
また、評価としては、「見積もりよりも請求の方が多くなることがある」といった文書による評価を追加することとしてもよい。この場合、より多くの企業の評価に関する情報をユーザは取得することができる。したがって、ユーザはサービスを提供する企業を決定する場合の根拠となる情報をより多く取得することができる。
また、端末20は、ユーザからの指示に従って、カメラ234を用いて、企業サーバ40から送信された請求書を撮像した画像を、請求された金額に関する情報として送信する。また、サーバ10は、端末20から、請求書を撮像した画像を、企業サーバ40が請求した金額に関する情報として受信する。
これにより、サーバ10は、請求書の確かなエビデンスとして、請求された金額に関する情報を得ることができる。
また、サーバ10は、端末20から企業サーバ40から請求された金額に関する情報を受信すると、端末20(のユーザ)に対して、特典に関する情報を送信する。そして、端末20は、サーバ10から送信された特典に関する情報を受信する。
これによって、サーバ10は、端末20に対して、請求額に関する情報を提供することに対する謝礼を贈ることができる。
また、端末20は、サーバ10を介して、企業サーバ40に送金をする。即ち、サーバ10が電子商取引による金銭等のやり取りを実行する機能を有する場合に、端末20から企業サーバ40に対する支払額を請求額の情報として取得することができる。
これにより、サーバ10は、ユーザから請求額に関する情報を受け取ることなく、即ち、ユーザの手を煩わせることなく、企業サーバ40から端末20に対して請求された請求額の情報を取得することができる。
また、サーバ10は、過去の企業サーバ40が行った請求と、その際に提供したサービスの情報とを参考に、新たなユーザからの見積もり依頼に対して、実際に企業がそのサービスを提供したとするときの請求額を予測し、その予測額をユーザの端末20に送信する。端末20は、その予測額の情報を受信し、表示部24に表示する。
これにより、端末20及びサーバ10は、ユーザに対して、サービスを依頼する企業を決定するときの更なる判断材料を提供することができるので、ユーザのサービスを利用する上での利便性を向上させることができる。
また、サーバ10は、ユーザからの見積もり依頼を企業サーバ40に送信してから、所定時間の経過を待たずに企業サーバ40から見積もり情報を受信した場合には、その所定時間が経過するまでは、その見積もり情報を端末20に送信しない。そして、所定時間が経過したら、サーバ10は、その時点で企業サーバ40から受信している見積もり情報を端末20に送信する。したがって、端末20は、見積もり依頼を行ってから定められた所定時間後に最初の見積もり情報を1以上受信する。
また、サーバ10は、所定数の見積もり情報を企業サーバ40から受信するまでは、見積もり情報を企業サーバ40から受信したとしても端末20に送信せず、所定数以上の見積もり情報を受信して初めて、端末20にまとめて送信するように構成してもよい。
この構成によれば、サーバ10が一端、見積もり額の情報を預かることにより、複数の見積もり依頼先の企業サーバ40からの見積もり額を、最初に受信する時点で端末20において比較することができる可能性を高くすることができる。したがって、ある企業サーバ40が、実際に請求する請求額よりも安く見積もり情報をいち早く送信し、ユーザが、その企業に依頼して、サーバ10に対して不満を抱く可能性を低減することができる。
また、端末20は、サーバ10から送信された各企業サーバ40からの見積もり情報を纏めた画像情報を表示するように構成してもよいし、画像ではなく文字情報であってもよい。
これにより、ユーザは、各企業が行った見積もりの額面の比較を容易に行うことができる。
また、端末20は、サーバ10からまとめて送信された複数の企業サーバ40からの見積もり情報を受信して、その見積もり情報の見積もり額で示される順序で、表示部24に表示する。
これにより、ユーザは、どの企業が一番安く見積もったのか、あるいは、一番高く見積もったのかを、一目で認識することができる。
また、端末20は、ユーザが企業サーバ40と行った交渉(取引)の情報をサーバ10に送信する。ここで、取引を示す情報は、メッセージ(文字情報)であってもよいし、取引の内容を示す画像であってもよい。
これにより、ユーザは、端末20を用いて、企業サーバ40との間でメッセージや画像を用いて行った取引に係る情報を、サーバ10に伝達することができる。そして、サーバ10は、ユーザと企業サーバ40間で行われた取引の情報を得ることができるので、例えば、企業サーバ40の評価をすることができる。
また、ユーザは、端末20からサーバ10に、企業サーバ40のサービスを享受した後に、少なくとも請求額に係るユーザ自身の所感である評価を示すユーザ評価情報を送信することとしてよい。なお、この評価は、実際に担当した企業サーバ40の担当者の評価を示す情報であってもよいし、その両方であってもよい。
これにより、端末20は、ユーザがサービスを受けたうえでのユーザ自身の企業あるいはその担当者に対する評価をサーバ10に送信することができる。そして、サーバ10は、その評価を受け取って、以降において、他のユーザに対して評価情報を提示する際に、その評価情報にユーザの評価を反映させて、よりリアルタイムの評価に関する情報を提供することができる。
また、端末20は、各企業を示す一覧(例えば、企業名の一覧や、対応するトークの一覧)を表示する。そして、端末20は、見積もりを行う各企業それぞれについて、自身の詳細情報を開示するか否かの選択をユーザから受け付ける。そして、端末20は、詳細情報を開示しないと決定した企業サーバ40との間の通信は、終了する。
これにより、ユーザにとって、不要となった企業との間の通信は終了することができ、以降、その企業との間の通信を行わずに済むので、例えば、取引を行わない企業からの営業活動などを受けずに済む。
また、端末20は、各企業それぞれとの間でサーバ10により立ち上げられたトークルームを介して、個別に交渉を行うことができる。
したがって、ユーザは、それぞれの企業との間で、他の企業とのやり取りやその状況を知られることなく、交渉を行うことができ、自身によって有利になるように取引を行うことができる。
また、端末20は、サーバ10との間のトークルームにおいて、リッチメニューを介して、取引を行う企業サーバ40それぞれの情報を表示することとしてもよい。
これにより、サーバ10が提供するサービスを享受するユーザ各々で異なった態様での情報の提供が可能になる。
<第3実施形態>
上記第1実施形態及び第2実施形態においては、ユーザが受けたいサービスを受ける際に、ユーザにとってより好適な企業サーバ40を選択できるシステムについて説明した。本第3実施形態においては、サーバ10が提供する機能として、企業サーバ40側にとってメリットとなる構成を説明する。なお、上記第2実施形態と同様に、各機器の構成については、第1実施形態と共通するので、上記第1実施形態及び第2実施形態と異なる構成について説明し、共通する構成の説明については、省略する。
<構成>
第3実施形態に係るサーバ10は、ユーザだけでなく、企業サーバ40にとって有益となる情報を送信する。即ち、サーバ10は、見積もり依頼時に、企業サーバ40にとって、ユーザの依頼との相性がよさそうであれば、その旨を通知する。ここで、相性がよいというのは、企業サーバ40がユーザの嗜好に合致する仕事をすることができる、企業サーバ40の得意とする分野がユーザの依頼に合致する、などを意味するものであってもよいし、そうでなくてもよい。企業サーバ40がユーザの嗜好に合致するというのは、ユーザの好みとして、例えば、値段、品質、速度、依頼先の働きぶり(例えば、積極的にユーザに話しかけながら仕事をする、寡黙に職人気質に仕事をする等)や、対応のよさなどが、企業サーバ40とのサービスを提供する上での特色に合致することを意味する。ここで、ユーザの好みの値段とは、即ち、コストパフォーマンスの高さを好むのかどうかを示す。また、ユーザの好みの品質とは、品質、即ち、サービスの内容(質)の良さを好むのかどうかを示す。また、ユーザの好みの速度とは、仕事の早さを重視するか否かを示す。さらには、ユーザの好みとは、値段や、品質、速度といった好みのうち、いずれを優先するのかを示す情報であってもよいし、そうでなくてもよい。
このような態様を実現するために、サーバ10の制御部11は、記憶しているユーザ情報200には、更に、ユーザの嗜好、趣味など、図2に示す以外の情報を含んでいてもよいし、そうでなくともよい。含んでいれば、よりユーザとの相性のよい企業サーバ40の選定がしやすくなるが、含んでおらずとも、図2に示すユーザ情報200のみからでも企業サーバ40との得意とする分野との一致から、相性のよさを判断することができる。
また、更には、サーバ10の制御部11は、企業サーバ40にとって有益な情報の提供として、見積もり依頼を行ったユーザと、他の見積もり依頼を行っている他のユーザとの関連性を鑑みたマッチングも行う。他のユーザとの関連性を鑑みたマッチングとは、企業サーバ40が実際にサービスを提供する上で他のユーザの依頼と、新たな見積もり依頼を行ったユーザの依頼との間の関連性の度合の高低(相関の高低とも言える)に基づくマッチングを行うことをいう。限定ではなく一例として、企業サーバ40が引越し業者の場合には、依頼として、どの地域からどの地域への引越しが一致したり、引越し元が一致したりしたら、関連性が高いと判定することとしてよい。また、そのうえで、依頼の日付(引越しの希望日)が一致したりすれば、更に関連性が高いと判定することもできる。関連性が高い場合には、ユーザからその企業サーバ40に対して実際に依頼する可能性が高いといえる。
このような構成を実現するために、サーバ10の制御部11は、ユーザの依頼と、企業サーバ40との間のマッチングを行う機能を有する。具体的には、ユーザからの見積もり依頼を受信した際に、その見積もり依頼を行ったユーザのユーザ情報を記憶部15から読み出す。また、併せて、後述する記憶部15に記憶されている企業サーバ40各々の特色を示す情報である企業情報2100を読み出す。そして、制御部11は、見積もり依頼を行ったユーザのユーザ情報と、企業情報2100で示される各企業各々の特色それぞれとから、相性のよさを判断する。限定ではなく一例として、ユーザ情報と企業情報との関連しあう項目それぞれについての相関値を算出し、その相関値が所定閾値を超えるか否かで相性がよいか否かを判定することができる。
企業サーバ40は、サーバ10から依頼情報300を受信する。そして、受信した依頼情報300を表示部43に表示する。このとき、サーバ10が相性がよいと判定したユーザについては、他のユーザとは異なる表示態様で、おすすめ、即ち、依頼(取引)をする可能性が高いことを示したり、おすすめである旨を示す文字情報を表示したりしてもよい。また、サーバ10から企業サーバ40に対するおすすめのユーザについての情報は、企業サーバ40と、サーバ10との間のトークルームで表示することとしてもよい。おすすめであるか否かは、企業サーバ40から見て、ユーザの評価を示す情報となる。図19には、依頼情報300に、ユーザについての評価情報を含ませる例として、おすすめ度1901を含ませた例を示している。おすすめ度1901は、サーバ10から見た、企業サーバ40に対するユーザのおすすめの度合を示す情報であり、企業サーバ40から見た対応するユーザの評価情報のことである。図19に示す例では、おすすめ度を数値で示しているが、これは、A、B、C等のランクで示されるものであってもよいし、単純におすすめか否かを示す2値の値であってもよい。企業サーバ40のオペレータは、図19に示すような依頼情報300を見ることで、見積もりを送信する(サービスを提供してもよいと判断できる)ユーザを決定することができる。なお、ユーザがおすすめかどうかについては、サーバ10と企業サーバ40との間のトークルーム上で、サーバ10から企業サーバ40に対して通知されてもよい。即ち、図20(a)、(b)に示すように、ユーザの評価を示す情報と企業サーバ40に対して提供するようにしてもよい。図20(a)は、ユーザの評価を星印でトークルーム上に表示した例であって、企業サーバ40の表示部43に表示したトークルームの画面例を示す図である。また、図20(b)は、ユーザの評価としておすすめである旨を直接示したトークルームの画面例を示す図である。図19や図20に示したように、企業サーバ40は、表示部43に、サーバ10から送信されたユーザの評価を示す評価情報を表示することができる。
<データ>
図21は、企業サーバ40と、ユーザとのマッチング(相性のよさ)を判定するために用いるデータであって、企業サーバ40各々の特色を示す企業情報2100の一例を示すデータ概念図である。企業情報2100は、記憶部15に記憶されていてもよいし、サーバ10がアクセス可能な外部装置に記憶されていてもよい。
図21に示すように、企業情報2100は、企業名2101と、電話番号2102と、所在地2103と、得意地域2104と、得意人数2105と、企業特性2106とが対応付けられた情報である。企業名2101以外の情報については、企業情報2100に含まれていてもよいし、含まれていなくてもよい。なお、図21に示す企業情報2100は、各企業が引越し業者である場合の例を示しており、他の業種であれば、他の業種に応じた項目の情報が含まれていてもよい。
企業名2101は、一意に対応する企業サーバ40を特定するための識別情報である。企業名に代えて、企業サーバ40の他の識別子を用いることとしてもよい。
電話番号2102は、対応する企業名2101で示される企業との連絡に用いる電話番号を示す情報である。
所在地2103は、対応する企業名2101で示される企業の居所を示す情報である。
得意地域2104は、対応する企業名2101で示される企業が、サービスを提供する上で得意とする地域を示す情報のことであり、企業サーバ40が引越し業者である場合には、引越し作業をするにあたって得意とする地域、例えば、企業からの近くの地域や、企業の引越し用のトラックを格納している車庫の近くの地域や、トラックを運転する運転手が土地勘を有する地域を示す情報等のことである。
得意人数2105は、対応する企業名2101で示される企業が、サービスを提供する上で得意とするユーザ側の人数のことを示す情報のことである。企業サーバ40が引越し業者である場合には、引越しを実行するユーザが何人の世帯の引越しを行うのが得意なのか(例えば、一人暮らし専門とか、4人家族、2世帯家族であるとかなど)を示す情報である。
企業特性2106は、上述した以外の対応する企業名2101で示される企業の特色(属性)を示す情報である。企業特性2106は、企業の特性であればどのような情報であってもよく、コストパフォーマンスのよさ、サービスの品質、サービス提供までの速度や、サービスを提供する上での企業としての姿勢などであってよい。図21に示した例では理解しやすくするために、文章で企業特性2106を示しているが、これは、各企業について各種の項目(限定ではなく一例として、コストパフォーマンス、品質、速度など)ごとにその項目の企業の程度(レベル)を示す情報が対応付けられた情報で表現されてもよい。
図21の例では、企業名2101が「B社引越し本舗」で示される企業は、電話番号が080-XXXX-XXXXであり、住所が、東京都品川区五反田にあり、サービスを提供するにあたって得意とする地域は、関東全域であり、得意人数が2~8人であり、迅速対応を旨としていることが理解できる。
サーバ10は、主として、得意地域2104、得意人数2105、企業特性2106等の情報を用いて、依頼を行うユーザとの相性のよさ(おすすめとするかどうか)を判断する。なお、サーバ10は、これらの情報全てを用いて、相性を判断してもよいし、全てを用いずに相性を判断してもよい。
<動作>
図22には、サーバ10が企業サーバ40にとって、相性がよいと推測されるユーザを紹介するときの各装置間のやり取りを示すシーケンス図であり、ユーザが見積もり依頼を行ってから、企業サーバ40からおおよその見積もりを受け取るまでの流れを示している。
図22に示すステップS501とステップS504とは、図5を用いて示したシーケンス図におけるステップS501とステップS504と同一であり、説明を省略する。
ユーザの端末20から、見積もり依頼を受信するとサーバ10は、その見積もり依頼で示されるユーザの希望と、企業サーバ40とのマッチングを実行する(ステップS2201)。即ち、サーバ10は、ユーザの依頼と、相性のよさそうな企業サーバ40を特定する。逆に言えば、企業サーバ40にとって、相性のよい、おすすめのユーザを特定する。ここでいうおすすめのユーザを特定するとは、企業サーバ40から見ておすすめのユーザであるか、あるいは、ユーザがどれだけおすすめかを示す指標を特定することの少なくともいずれか一方を含む。
サーバ10は、マッチングにより決定したユーザの評価情報を含む依頼情報を、企業サーバ40に送信する(ステップS2202)。この依頼情報は、複数のユーザからの依頼が含まれてもよいし、含まれなくてもよい。なお、このとき、サーバ10は、ユーザの端末20に対して、後ほど、企業サーバ40から、おおよその見積もり額が通知される旨を連絡することとしてもよいし、しなくてもよい。
企業サーバ40のオペレータは、サーバ10から送信された依頼情報を見て、ユーザからの依頼を受けるかどうかを判断し、見積もりを送信するか否かを決定する(ステップS2203)。そして、見積もりを送信すると決定したユーザについて、そのユーザの見積もり依頼の内容からおおよその見積もり額を算定する。企業サーバ40は、算定した見積もり額と、どのユーザからの見積もり依頼に対する見積もり額が特定可能な情報とをサーバ10に送信する(ステップS2204)。
サーバ10は、企業サーバ40から見積もり額と、どの依頼に対する見積もり額であるかを示す情報を受信すると、その依頼を行ったユーザと企業サーバ40との間のトークルームを開設し、そのトークルーム上に企業サーバ40からの見積もり額を掲載して、端末20に送信する(ステップS2205)。ステップS2204、S2205の処理は、図5におけるステップS504の処理に相当する。このようにして、企業サーバ40(のオペレータ)は、1以上のユーザからの依頼について、そのユーザの評価から見積もり依頼を出すか(サービスを提供してもよいか)を判断することができる。なお、図22においては、ステップS2204、S2205に示すように、サーバ10を経由して、見積もり額の情報を企業サーバ40から端末20に送信することとしているが、これは、直接、企業サーバ40から端末20に送信されるものであってもよい。
次に、図22に示す処理を実現するための、サーバ10の処理について、図23を用いて説明する。図23は、図22に示すステップS2201~S2205の処理を実現する際の、動作であって、図7に示したフローチャートにその処理を組み込んだフローチャートを示している。したがって、ここでは、図7を用いて説明した処理内容については、説明を簡略化し、図7と異なる点について詳細に説明する。
図23に示すように、サーバ10は、端末20からの見積もり依頼を受信する(ステップS701)。
制御部11は、依頼済みの他案件との相関があるか否かを判定する(ステップS2301)。制御部11は、ステップS701で示される見積もり依頼の内容から、他のユーザから依頼されている見積もり依頼の内容との一致度合いから相関があるかを判定する。制御部11は、依頼済みの他案件と相関があると判定した場合には(ステップS2301のYES)、ユーザ情報200で示される内容と、企業情報2100で示される内容とから、マッチングを行って、依頼済みの他案件との相関があったことによる評価の上方修正を行った企業サーバ40にとってのユーザの評価を決定し(ステップS2302)、ステップS2304の処理に移行する。限定ではなく一例として、ユーザの特性として、コストパフォーマンスに対する嗜好、サービスの品質に対する嗜好、サービスを提供する速度に対する嗜好とが設定されており、同様に企業サーバ40の企業特性2106として、コストの評価、サービス品質の評価、サービスの提供速度の評価が設定されている場合に、それぞれの項目でユーザの嗜好を満たしているか否か、満たしている場合にその度合がどの程度であるかを算出し、その評価を統合することで企業サーバ40にとってのユーザの評価を決定することができる。このとき、単純におすすめかどうかを決定する場合には、その評価が所定の閾値を超えているか否かで決定することができる。また、他の例としては、ユーザの特性(嗜好)1つ1つについて、企業サーバ40がそれぞれを満たすか否かを判定し、満たした数を企業サーバ40にとってのユーザの評価としてもよい。一方で、制御部11は、依頼済みの他案件と相関がないと判定した場合には(ステップS2301のNO)、制御部11は、ユーザ情報200で示される内容と、企業情報2100で示される内容とから、マッチングを行って、企業サーバ40にとってのユーザの評価を決定する(ステップS2303)。制御部11は、通信I/F14を介して、ユーザの評価情報を含む依頼情報300を、企業サーバ40に送信する(ステップS2304)。
制御部11は、通信I/F14が、企業サーバ40からおおよその見積もり額の情報を受信したか否かを判定する(ステップS2305)。おおよその見積もり額の情報を受信するまでは待機する(ステップS2305のNO)。通信I/F14が、企業サーバ40からおおよその見積もり額の情報を受信した場合には(ステップS2305のYES)、制御部11は、企業サーバ40と、その見積もり額に対応する見積もり依頼を行ったユーザとの間にトークルームを開設する。そして、制御部11は、そのトークルーム上に、企業サーバ40から受信した見積もり額の情報を送信する(ステップS2306)。その後に、ステップS704の処理に移行する。このステップS2301からステップS2305の処理が、図7に示すステップS702からステップS703の処理に代えて実行される処理となる。
<マッチング処理の具体例>
企業サーバ40が引越し業者である場合に、サーバ10が見積もり依頼間の相関を見る際の処理手法について具体的に説明する。
図24(a)は、あるユーザU1からU1aからU1bに示される経路2401での見積もり依頼が既にある企業Aに見積もり依頼が行っている状況であるとする。この経路2401の見積もり依頼に対して、ユーザU1は、企業Aに対して依頼をすることを決定していてもよいし、決定していなくてもよい。そのような状況下において、新たな見積もり依頼がユーザU2からサーバ10に送信されたとする。
このとき、サーバ10が、ユーザU2の見積もり依頼の内容から、引越しの内容としてU2aからU2bまでの経路2402で示される引越しの依頼であることが認識できたとする。サーバ10の制御部11は、経路2401と経路2402との間の相関値を算出する。即ち、制御部11は、経路2401と経路2402とが、位置とその経路の形状とがどれだけ近しいかを算出する。そして、その相関値が予め定めた閾値よりも高い場合であって、引越しの希望日が一致するようなときには、ユーザU2からの見積もり依頼は、ユーザU1の見積もり依頼を送信した企業である企業Aとのマッチングを決定する。即ち、制御部11は、企業Aに対してユーザU2からの見積もり依頼を送信することを決定する。
また、同様に、図24(b)に示すように、ユーザU1からU1aからU1bに示される経路2411での見積もり依頼が既にある企業Aに見積もり依頼が行っている状況であるとする。この経路2411の見積もり依頼に対して、ユーザU1は、企業Aに対して依頼をすることを決定していてもよいし、決定していなくてもよい。そのような状況下において、新たな見積もり依頼として、ユーザU2から、U2aからU2bまでの経路2412で示される引越しの依頼がされたとする。
このとき、サーバ10の制御部11は、ユーザU2の依頼が、ユーザU1からの依頼と出発地点が同じであること、経路2411と経路2412との向きが一定以上同じ方向を向いていると判定した場合には、ユーザU2からの見積もり依頼は、ユーザU2の見積もり依頼を送信した企業である企業Aとのマッチングを決定する。即ち、制御部11は、企業Aに対してユーザU2からの見積もり依頼を送信することを決定する。このような場合に、制御部11は、限定ではなく一例として、経路2411と経路2412とのベクトルを算出し、ベクトル間の相関値が所定閾値以上であることを以て、マッチングを決定することとしてよい。例えば、相関値を算出する方法として、経路2411のベクトルと、経路2412のベクトルとの内積を計算し、所定の値以上になった場合は、相関値が閾値以上であるとして、マッチングしていると決定する。図24(b)のように、二つの依頼の出発地点が同じになる場合には、ユーザU1とU2とが許諾等すれば、例えば、経路2413に示すように、一方の到着地点を経由して、双方の引越しを行うことができるルートの選択も可能となり、経費の削減を行うことも考えられる。このような場合には、ユーザU1とユーザU2に対する請求額についても削減を行うことができるので、ユーザU1とユーザU2に対する見積もり額を低減することもできるようになり、依頼の受注の可能性を高めることができる。
図25は、サーバ10と、企業サーバ40との間のトークルームの一例を示す画面図であって企業サーバ40側の機器で見ることができる画面図を示している。図25(a)は、図23において、ステップS2303の処理を行った場合、即ち、新たな見積もり依頼が、過去の他の見積もり依頼との間に相関がなかった場合に、サーバ10から企業サーバ40に対して送信されるメッセージ例を示している。
図25(a)に示されるように、サーバ10からは企業サーバ40に対して、Aというユーザから依頼があること、その依頼が企業サーバ40に対して依頼がされているユーザBという人物とのマッチング率が高いことを示すメッセージが送信される。この際には、図25(a)に示すように、ユーザAの依頼、ユーザBの依頼を併せて表示するように、メッセージが送信されてもよいし、送信されなくてもよい。また、いずれか一方の依頼内容を示すにとどめてもよい。
図25(b)は、図23において、ステップS2302の処理を行った場合、即ち、新たな見積もり依頼が、過去の他の見積もり依頼との間に相関があった場合に、サーバ10から企業サーバ40に対して送信されるメッセージ例を示している。図25(b)に示されるようにサーバ10からは企業サーバ40に対して、Aというユーザから依頼があること、そのユーザAからの見積もり依頼の内容が、企業サーバ40とのマッチング率が高い、即ち、相性がよい旨を示すメッセージを送信する。この際には、図25(b)に示すように、新たな依頼主であるユーザAの依頼内容と、過去の関連がある他の見積もり依頼の依頼主であるユーザBの依頼内容も併せて表示するようにメッセージが送信されてもよいし、されなくてもよい。過去の依頼内容であるユーザBの依頼内容も併せて表示することで、企業サーバ40のオペレータは、新たなユーザAからの依頼内容との比較を容易に行うことができる。
図25に示すような、情報がサーバ10から得られることで、企業サーバ40は、見積もりの額の減縮、依頼を受けるか否かの意思決定がしやすくなるというメリットを得ることができる。
図24に示すような状況下にあっては、企業側としては、近い場所から近い場所への引越しということで、引越し作業自体が楽になる(引越し元への荷物の集配の手配、車両の手配等)といえ、個別の案件を処理するよりも、処理数を少なくできる可能性がある。そうすると、企業Aとしては、ユーザU1、U2それぞれに対するコストを低減することができる可能性があり、その分だけ見積もりを安くすることが許容できるようになる。したがって、ユーザU1、U2に対して、通常よりも安い見積もりを送付することによって、ユーザU1、U2双方からの依頼を受注できる可能性を高めることができる。
なお、ここでは、詳細には記載しないが、上記第1実施形態に示した態様は、第3実施形態にも適用することとてもよいし、しなくてもよい。例えば、図11(a)に示したリッチメニューを利用したユーザとサーバ10との間のやり取りは、ユーザを企業サーバ40に代えて、本実施形態にも適用可能である。本実施形態であれば、限定ではなく一例として、リッチメニューとして、サーバ10が見積もり依頼をしているユーザそれぞれを示すボタンを配したリッチメニューを表示することが考えられる。限定ではなく一例として、これらのボタンは、各ユーザとのトークを開始するためのボタンであってもよいし、そうでなくてもよい。
また、本第3実施形態においても図11(b)に示したように、企業サーバ40(のオペレータ)又はサーバ10(のオペレータ)は、見積もり依頼をしているユーザに係る情報のやり取りにおいて、画像情報(スタンプ)を用いたやり取りをすることとしてもよいし、そうでなくてもよい。限定ではなく一例として、企業サーバ40は、ユーザとのトークにおいて、提供するサービスにおいて、減額の意思があることを示す画像情報を用いることができ、それによって、ユーザが依頼をしやすくなるようにすることができる。
また、企業サーバ40は、サービスを提供した後、もしくは、サービスを提供する(提供前を含む)過程でユーザとしたやり取りなどから、ユーザを評価した評価情報を、サーバ10に送信することとしてもよい。そして、サーバ10は、その企業がしたユーザの評価をユーザ情報200にメタデータとして登録することとしてもよいし、しなくてもよい。また企業のユーザに対する評価は、以降の企業サーバ40へのユーザのマッチング率の算出に反映させてもよいし、させなくてもよい。
<実施形態の効果>
サーバ10の制御部11は、ユーザからの見積もり依頼があった場合に、その見積もり依頼の内容から、相性のよい企業を特定する。制御部11は、見積もり依頼の内容と、企業それぞれの情報(限定ではなく企業に関する情報の一例)または、企業の特色を示す情報(限定ではなく企業に関する情報の一例)とに基づいて、ユーザの見積もり依頼に対して相性のよい企業を特定する。そして、サーバ10の制御部11は、通信I/F14を介して、企業サーバ40に対して、ユーザからの見積もり依頼を送信する、とともに、そのユーザが企業サーバ40にとっておすすめのユーザである旨を示す情報を送信する。
また、企業サーバ40の表示部43は、受信した依頼情報とともに、その依頼を行ったユーザがおすすめである旨を示していた場合に、おすすめであることがわかる表示態様で表示する。
これにより、サーバ10は、企業サーバ40に対して、おすすめとなるユーザの情報を提供することで、企業サーバ40からの信頼を得ることができるとともに、ユーザに対してもユーザにとって好適な企業を紹介できる可能性を高くすることができ、ユーザからの信頼も得ることができる。
また、企業サーバ40としては、自社が得意とする分野、相性のよいユーザの依頼を受けるために、見積もり額の加減を判断することができる。自社が得意とする分野でのサービスの提供、相性のよいユーザに対するサービスの提供をするために、安めの見積もりをして、そのユーザの獲得を狙いつつ、ユーザの希望に沿う満足度の高いサービスを提供することで、ユーザからの高い評価を得て、新たな顧客(ユーザ)の獲得につなげる可能性を高めることができる。
また、制御部11は、ユーザの見積もり依頼で示される内容と、企業サーバ40の企業情報(特色)との一致度合い、関連度合に基づいて、企業サーバ40に対して、ユーザがおすすめであるか否かを示す情報を送信する。
これにより、サーバ10は、企業サーバ40に対してより依頼をしてくれる可能性の高いユーザを紹介することができる。したがって、企業サーバ40側としても、顧客の獲得のために、可能な範囲で見積もりを安くして、ユーザの満足度の高いサービスを提供することで、自社の評価を高めることにつなげられる。
また、サーバ10は、複数のユーザからの依頼を纏めた依頼情報300を企業サーバ40に送信し、その際に依頼情報300にその企業に対しておすすめであるか否かの情報を付して送信する。ここでおすすめであるか否かの情報とは、ユーザがその企業サーバ40と取引を行う可能性が高いか否かに基づく情報であってもよい。
これにより、企業サーバ40としては、複数のユーザからの見積もり依頼をうけつつも、それらの依頼の中でも自社として優先すべきユーザがどのユーザであるかを特定し、そのユーザを優先して対応することができる。
また、サーバ10の記憶部15はユーザ情報200を記憶している。ユーザ情報200には、ユーザを特定できないもののユーザに関し、依頼内容がある程度理解できる情報(限定ではなく、第1情報の例)と、ユーザを特定可能なユーザに関する情報(限定ではなく、第2情報の例)とが含まれる。
これにより、企業サーバ40は、ユーザを特定できないもののユーザに関し、依頼内容がある程度理解できる情報(限定ではなく、第1情報の例)があることにより、おおよその見積もり額を算定できて、ユーザに伝えることができる。一方で、ユーザは、自身を特定可能な情報(限定ではなく、第1情報の例)を開示することなく、受けたいサービスのおおよその金額を知ることができる。そして、自身を特定可能な情報を開示しないことで、その後の各種の業者からの広告や営業を受けずに済む。
また、ユーザを特定可能なユーザに関する情報(限定ではなく、第2情報の例)があることで、企業サーバ40は、詳細な見積もりを策定でき、ユーザは、その詳細な見積もりから、依頼をするか否か(サービスを受けるか否か)を判断するための判断材料とすることができる。
そして、サーバ10は、最初の段階での見積もり依頼においては、ユーザからの依頼内容については、企業サーバ40に送信するものの、ユーザ個人を特定可能な情報(限定ではなく第2情報の例)については、送信しない。そして、ユーザからの承諾がある場合に、ユーザ個人を特定可能な情報(限定ではなく第2情報の例)を送信する。
サーバ10は、ユーザの個人情報を明かすことなく、ユーザからの見積もり依頼を企業サーバ40に送信することができるとともに、ユーザからの承諾があった場合にのみ企業サーバ40にユーザの個人情報を送信するので、サーバ10は、ユーザからの信頼を得ることができる。
また、サーバ10の制御部11は、企業にとっておすすめのユーザを決定するにあたって、企業が過去に行った取引の情報を用いる。即ち、サーバ10から、企業サーバ40に対して、送信した過去の見積もり依頼の内容と、相関の高い新たな見積もり依頼がある場合などには、その企業サーバ40にとって得意であったり、依頼内容の関連性が高い場合にサービスを提供するための項数を減らしたりすることができる依頼である可能性があるので、おすすめのユーザとして紹介する。
これにより、サーバ10は、企業サーバ40に対して、信頼性の高い情報を提供することができる。
また、サーバ10は、ユーザからの見積もり依頼に対して、企業サーバ40に対しておすすめのユーザあるかを判定する際に、企業サーバ40の得意とする分野、特色(限定ではなく一例として、得意地域2104、得意人数2105、企業特性2106)の情報を用いておすすめのユーザを決定する。
企業サーバ40にとってサービスを提供するうえで、得意とする分野や特色を示す情報を用いて、おすすめのユーザを決定するので、ユーザから実際に依頼をしてもらえる可能性を向上させることができるとともに、企業サーバ40にとって得意とする分野でのサービスを提供することで効率よく処理をすることができる。
また、サーバ10は、ユーザからの見積もり依頼で示される引越しにおいて、引越し元の地域の情報と引越し先の地域との情報、及び、企業が得意とする地域、即ち、サービスを提供することが可能な領域を示す情報に基づいて、見積もり依頼をするユーザが、企業サーバ40にとっておすすめであるか否かを判定することができる。
これによって、サーバ10は、企業サーバ40にとって、サービスを提供するのに得意となる地域でのサービスをユーザに提供することで、ユーザの満足度をあげることができる。また、サーバ10は、企業サーバ40に対して、より好適なユーザを紹介することができるので、クオリティの高いサービを提供することができる。
また、企業サーバ40は、企業サーバ40がユーザと行った交渉(取引)に係る情報をサーバ10に送信する。そして、サーバ10は、その交渉(取引)をするための情報を受信する。取引に関する情報は、メッセージ(文字情報)であってもよいし、取引の内容を示す画像であってもよい。
これにより、企業サーバ40は、ユーザとの間で行った交渉(取引)に係る情報をサーバ10に送信することができ、サーバ10は、その情報を得ることができる。したがって、サーバ10は、ユーザと企業サーバ40との間で公正な取引が行われたかどうかを確認することができるとともに、ユーザと企業サーバ40とのそれぞれを、その取引の内容から評価することができる。この評価は、それぞれ、ユーザ情報200、企業情報2100に反映させることとしてもよいし、しなくてもよい。反映させた場合には、以降のユーザと企業サーバ40とのマッチングにおいて、最新のユーザまたは企業に係る情報を利用したマッチングが実現できる。
<その他>
本開示の実施形態を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本開示の範囲に含まれることに留意されたい。限定でなく例として、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステップ等を1つに組み合わせたり、或いは分割したりすることが可能である。また、各実施形態または各変形例に示す構成を適宜組み合わせることとしてもよい。
また、上記実施形態に示した端末20、サーバ10、企業サーバ40各々の構成は、図1に示した構成に代えて、図26に示すように構成されてもよい。
即ち、端末20は、図26(a)に示すように、通信部22と、制御部21とから構成されてよく、端末20の通信部22は、サーバ10からユーザの情報(見積もり依頼)を送信し、サーバ10から、取引を行う企業サーバ40とその評価を示す評価情報を受信し、表示部24にその企業サーバと評価情報とを表示する。
また、サーバ10は、図26(b)に示すように、通信部14から構成されてよく、サーバ10の通信部14は、ユーザの端末20からユーザの情報(見積もり依頼)を受信し、取引を行う企業サーバ40とその評価を示す評価情報を送信する。これにより、サーバ10は、ユーザにとってサービスを依頼する依頼先を決定するうえで有益となる情報を提供することができ、ユーザからの信頼を得ることができる。また、ユーザは、サービスを依頼する依頼先を決定するうえでの有益な判断材料を得ることができる。
また、端末20は、図26(a)に示すように、通信部22と、表示部24とから構成されてよく、通信部22は、ユーザの情報(見積もり依頼)を送信し、それに対して、サーバ10から企業サーバ40からの見積もり額に関する情報を受信する。端末20の表示部24は、その表示領域に受信した見積もり額に関する情報を表示する。端末20のユーザは、依頼し、サービスを受けた企業サーバ40から請求書を受け取る。そして、端末20の通信部22は、ユーザからの入力にしたがって、企業サーバ40からの請求書の情報を、サーバ10に送信する。
また、サーバ10は、図26(b)に示すように、通信部14から構成されてよく、ユーザの情報(見積もり依頼)を受信する。通信部14は、その見積もり依頼を企業サーバ40に送信し、それに対して、企業サーバ40から見積もり額を受信する。サーバ10の通信部14は、その見積もり額を、端末20に送信する。そして、通信部14は、端末20から、サービスを提供した企業サーバ40からの請求額に関する情報を受信する。これにより、サーバ10は、見積もり額と請求額それぞれの情報を得ることができるので、見積もり額と請求額との間に乖離があるか否かを確認することができる。
また、サーバ10は、図26(b)に示すように、通信部14から構成されてよく、ユーザの情報(見積もり依頼)を受信し、その見積もり依頼の送信先の企業サーバ40を決定し、決定した企業サーバ40に送信する。このとき、サーバ10は、企業サーバ40に対して、企業サーバ40にとっておすすめとなるユーザについて、そのユーザがおすすめであると評価する情報を併せて送信する。
また、企業サーバ40は、図26(c)に示すように、表示部43と、通信部44から構成されてよく、サーバ10から、ユーザからの見積もり依頼とともに、そのユーザがおすすめであると評価する情報を併せて受信する。そして、表示部43は、その見積もり依頼の内容と、ユーザがおすすめであることを示す情報とを表示する。これにより、サーバ10は、企業サーバ40にとって有益となる情報を提供することができ、企業サーバ40は、受注する依頼を選択する判断材料を得ることができる。