JP2014215670A - 信頼度算出装置 - Google Patents

Abstract

【課題】車両の乗り合いの相手の決定などに好適な信頼度を算出する信頼度算出装置を提供する。
【解決手段】各ユーザの端末にて登録されている他ユーザのアドレス情報をアドレス取得部11が取得する。取得アドレスを集計して、各ユーザをノードとし、アドレスに登録があるユーザ間にエッジを設けることで、人間関係を表すユーザマップをユーザマップ生成部12が生成する。信頼度算出部13は、各ユーザにおける他ユーザの信頼度を、ユーザマップ上のつながりが多いほど高い値として算出する。さらにマッチング部14により信頼度に基づくユーザ同士のマッチングも可能であり、車両の乗り合いにおいては２ステップでつながるユーザを対象とするのが好ましい。
【選択図】図３

Description

本発明は、信頼度算出装置に関し、特に、車両の乗り合いの相手といったような、所定のイベントを共有する相手についての信頼度を自動で算出可能であり、さらに、当該信頼度を利用して、マッチングの相手の候補を提示することも可能な、信頼度算出装置に関する。

車両の乗り合い（ライドシェア・カーシェア）においては、利用メンバーや利用条件その他の決定が必要となる。

当該車両の乗り合いに関して、特許文献１では、乗り合い仲介装置を開示している。出発点・到着点の情報、出発時刻・到着時刻等の情報を共有して、メンバー間のメールでの情報交換をすることで乗り合いを実現している。

特開2003-281237号公報

このような乗り合いの場合、利用者間のセキュリティ問題が極めて大きい。従来の乗り合いでは、車を運転する人の利便性を中心にセキュリティ等の問題を解決するものは多い。例えば、以下の特許文献２（カーシェアリングシステムにおける認証システム）ではIC運転免許証を利用して、利用者の認証を行なっている。

[特許文献２] 特開2012-247818号公報

しかしながら、乗り合いの場合、運転せずに車を利用したいケースもある。このような場合に、特許文献２の技術は車を運転する人の利便性向上を目指すものであって、乗車する人の信頼性を向上させることはそもそも考慮されていない。従って、乗車する人の信頼性を必ずしも確保できず、場合によっては信頼度の低い人との乗り合いとならざるを得ず、一般の利用者にとっての利用障壁となっていた。

また、乗り合いに限らず、いわゆる街コンの参加者同士で、コミュニティを形成する場合など、不特定多数のメンバーの中から所定のイベントを共有する相手やグループを決定する際にも、信頼度を確保して相手やグループを決定できることが望ましい。またこの際、各メンバーは所定のシステムを利用するユーザであって、当該システムによって自動で信頼度を確保して決定できることが望ましい。

本発明は、上記のような課題に鑑み、相手の信頼度を算出することのできる信頼度算出装置を提供することを第一の目的とする。

本発明はまた、算出された信頼度によってユーザ同士のマッチングを実現することを第二の目的とする。

上記目的を達成するため、本発明は、各ユーザの端末を介して、各ユーザにおける他ユーザの信頼度を算出する信頼度算出装置であって、各端末より、登録されている他ユーザの端末のアドレスの情報を取得するアドレス取得部と、前記取得したアドレスを用いて、各ユーザをノードとし、アドレス登録があるユーザ間にエッジを設けたグラフとして、ユーザマップを生成するユーザマップ生成部と、前記生成したユーザマップを用いて、各ユーザにおける他ユーザの信頼度を、当該ユーザから他ユーザに至るパスに基づいて算出する信頼度算出部と、を備えることを第一の特徴とする。

また、本発明は、前記信頼度算出装置がさらに、マッチングを要求するユーザの端末に対して、当該要求ユーザに対して前記算出された信頼度に基づいてマッチング候補のユーザを提示することで、端末間でのマッチングの仲介を行うマッチング部を備えることを第二の特徴とする。

前記第一の特徴によれば、各端末から収集したアドレスにおけるユーザ同士の登録関係、すなわち、ユーザ同士の人間関係を反映してユーザマップが自動生成され、当該ユーザマップ上におけるユーザ間のパスによって信頼度を算出する。従って、人間関係を反映した信頼度が自動算出可能であり、前記第一の目的が達成される。

前記第二の特徴によれば、算出された信頼度によってユーザ同士のマッチングが実現されるので、前記第二の目的が達成される。

一実施形態に係る信頼度算出システムの構成図である。 本発明における信頼度算出とマッチングの概要を説明するための図である。 一実施形態に係る信頼度算出装置の機能ブロック図である。 ユーザマップの例である。 図４のユーザマップ生成に用いられた各端末のアドレス情報の例である。 マッチングの例を示すための、ユーザマップの例である。 第一実施形態のマッチングの際に、確定部が各ユーザに提示する一連の画面の例である。 第二実施形態のマッチングの際に、確定部が各ユーザに提示する一連の画面の例である。

図１は、一実施形態に係る信頼度算出システムの構成図である。信頼度算出システム100は、信頼度算出装置10と、各ユーザA, B, C, ...がそれぞれ所有する端末1A, 1B, 1C, ...と、を備える。各端末1A等は、典型的にはスマートフォン等の携帯情報端末によって構成することができる。信頼度算出装置10は、サーバとして構成されていてもよいし、各端末1A等のいずれかにおいて構成されていてもよい。当該構成による本発明の概要は以下の通りである。

各ユーザA等は、自身の端末1A等より登録している他ユーザのアドレス情報を信頼度算出装置10に送信する。信頼度算出装置10は、各ユーザA等より当該送信されたアドレス情報を集計して、第一の処理として、各ユーザA等における他ユーザの信頼度を算出する。信頼度算出装置10はさらに第二の処理として、当該算出した信頼度と、各ユーザA等からのリクエストや事前登録情報に基づいて、ユーザ間のマッチングを仲介する。

図２は、本発明において算出される信頼度及び当該信頼度に基づくマッチングの概要を説明するための図である。信頼度算出装置10は、上記各ユーザA等より送信されたアドレス情報を集計して、図２に概念的に示すような、ユーザ間の人間関係情報（後述するユーザマップ）を構築する。当該人間関係情報は、ユーザ同士のうち友人関係（以下、「つながり」とする）にあるものを特定する情報である。

本発明では、当該つながりの多いユーザほど信頼度が高いものとして、信頼度の算出を行う。また、信頼度に基づいてマッチングを行う際は、２ステップでつながりがあるユーザを対象として、信頼度の高い順にマッチングを行う。２ステップでのつながりとはすなわち、「友人の友人」の関係であり、直接のつながり（１ステップでのつながり）はないが、共通の友人が存在している関係である。また、当該マッチングの際に、イベントを共有するための条件の摺り合わせを行い、条件が合致するユーザ間で、信頼度の高い順にマッチングを行う。

図２は、ユーザaを中心として見た場合の人間関係情報を、１ステップでのつながりがあるユーザ間に両方向矢印を描くことによって表している。図示するように、ユーザaと直接のつながり（１ステップでのつながり）がある3人のユーザがb, c及びdである。当該ユーザb, c及びdにはそれぞれ、自身から１ステップでのつながりがあり、ユーザaから見た場合には２ステップでのつながりがあるユーザb1, b2, b3と、c1, c2, c3と、d1, d2, d3と、が存在する。

従って、ユーザaとのマッチングを行う場合は、当該9人のユーザb1, b2, b3と、c1, c2, c3と、d1, d2, d3と、がマッチングの候補となり、当該9人のユーザのうちイベントを共有するための条件が合致するものが、信頼度の高い順にマッチング対象として選定される。

本発明では特に、このように２ステップでのつながりが存在するユーザをマッチング候補とすることにより、次のような効果を奏することができる。第一に、不特定多数のユーザの中から共通の友人の存在があるということに基づき、信頼度の高い候補が自動で選別される。第二に、当該候補の数も直接のつながりがあるユーザの概ね２乗となり多数存在するため、マッチングの条件が合致するユーザも多く見つかる。

なお、信頼度の条件を緩めることで、マッチングの条件が合致するユーザをより多数に渡って確保する観点からは、３ステップ以上でのつながりが存在するユーザをマッチング候補に追加してもよい。このような場合であっても、各候補には信頼度が算出されているので、信頼度の高い順に候補を提示することが可能である。

なおまた、１ステップでつながりが存在するユーザは、当該ユーザ間で直接やりとりが可能であるので、マッチング候補には含めない。２ステップ以上でのつながりが存在するユーザは、直接のやりとりはできないが多数存在するため、本発明によるマッチング候補としての意義を有する。

図３は、一実施形態に係る信頼度算出装置10の機能ブロック図である。信頼度算出装置10は、アドレス取得部11、ユーザマップ生成部12、信頼度算出部13及びマッチング部14を備える。ここで、マッチング部14はさらに、条件取得部141、候補提示部142及び確定部143を含む。

図３は、図１で示したような各ユーザ端末1A, 1B, 1C, ...とのやりとりを含めて描かれている。なお、説明の便宜上、図３及び以降の説明においては、マッチングを依頼するユーザが端末1Aの保有ユーザAであり、その他のユーザB, C. ...（端末1B, 1C, ...）を、マッチングの依頼を受け許諾する側とする。

アドレス取得部11は、各ユーザ端末1A, 1B, 1C, ...より登録されているアドレスを取得する。当該アドレスは、他ユーザの連絡先であり、次のようなものを利用することができる。各端末が携帯電話であればその電話番号を利用してよい。また、各端末における電子メールアドレスを利用してもよい。あるいは、各端末でユーザが利用しているSNS（ソーシャル・ネットワーキング・サービス）のIDを利用してもよい。SNSのIDを取得する際は、各端末からではなく当該SNSのサーバ等から取得してもよい。

また、アドレスと対応づけて、各ユーザの名前や端末IDなども取得してよい。当該名前等は、後述のマッチング部14にてユーザ間の仲介を行う際に、ユーザを示す情報として利用可能である。

ユーザマップ生成部12は、アドレス取得部11が取得した登録アドレスを用いて、ユーザ間につながりがあることをアドレスが登録されていることによって判定し、ユーザ間のつながりを表現したユーザマップを生成する。当該ユーザマップは、各ユーザをノードとし、アドレス登録の存在によるつながりが存在するユーザ間にエッジを設けたグラフとして生成される。

なお、アドレス登録からユーザ間のつながりの存在を判定する際は、両ユーザ間で相互にアドレス登録が存在している場合につながりがあると判定するようにしてもよいし、少なくともいずれか片方のみにアドレス登録が存在している場合につながりがあると判定するようにしてもよい。

すなわち、ユーザx, y間のつながりは、以下の条件(1)及び(2)の両方が満たされる場合につながりが存在すると判定してもよいし、条件(1)又は(2)のいずれか少なくとも一方が満たされる場合につながりが存在すると判定してもよい。なお、「アドレス帳」とは、各端末において登録されているアドレスを当該端末にて記憶する手段（メモリ領域など）を指す。
(1) xのアドレス帳にyが登録されている
(2) yのアドレス帳にxが登録されている

なお、条件(1)又は(2)の少なくとも一方（単方向）でつながりを判定する場合は、両方（双方向）の登録がある場合に、後述する信頼度算出部13におけるユーザ間の信頼度を単方向の場合よりも高く算出するようにしてもよい。当該算出の詳細は後述する。

ユーザマップ生成部12では、アドレス取得部11が取得した登録アドレスの全てを集計して、全ユーザのつながりが表現されたユーザマップを一括で生成してもよい。あるいは、ユーザマップ生成部12では、（図３中に点線矢印で示すように、）マッチングの要求を特定ユーザAの端末1Aより受信してから、アドレス取得部11が取得した登録アドレスを参照して、当該特定ユーザAを中心とした所定範囲内においてユーザマップを生成してもよい。

図４は、ユーザマップの例である。図５は、図４のユーザマップを生成するのに用いられた、各端末に登録されたアドレス情報の例である。ここでは、部分的な例として、ユーザAを中心として、つながりが存在する周辺のユーザB〜Ｉが示されている。

信頼度算出部13は、ユーザマップ生成部12の生成したユーザマップを用いて、各ユーザにおける他ユーザの信頼度を算出する。特に、マッチングの要求を特定ユーザAの端末1Aより受信した際は、当該特定ユーザ1Aから見た他ユーザの各々について信頼度を算出する。算出結果は、信頼度算出の起点となったユーザ（マッチング要求があった場合は、当該要求したユーザA）の端末に通知してもよい。

当該算出の際に信頼度算出部13は、ユーザマップを参照して、信頼度算出の起点となるユーザからのつながりのステップ数によって信頼度算出対象の他ユーザをグループ分けしてから、当該グループ毎に、他ユーザの信頼度を算出する。つながりのステップ数は、ユーザマップにおいてユーザを表すノード間を移動するのに要するステップ数の最小値である。

図４及び図５の例において、ユーザAから見た他ユーザB〜Ｉの各々の信頼度を算出する場合であれば、図５において(0), (1), (2)と区別したように、以下のようなグループ毎に区別して信頼度が算出される。
１ステップでつながるユーザのグループ：B, H, G, I, F
２ステップでつながるユーザのグループ：C, D, E, ...
（同様に、３ステップ以上でつながるユーザの各グループについて算出してもよい。）

１ステップでつながるユーザに対する信頼度は、次のような方針で算出する。

第一の方針として、ユーザ間における当該最小の１ステップ以外のパスも多いほど、共通の友人も多く当該ユーザ同士がより親密な関係にあると判断できることから、信頼度の値をより高く算出する。ここで、１ステップ以外のパスに関しては、所定数n（n≧2）ステップまでのパスを考慮し、ステップ数i（2≦i≦n）が小さいパスほど信頼度に加算する度合いを大きくする。

例えば、図４の例では、ユーザAから見て１ステップでつながるユーザBに関しては、A-Bの１ステップのパス以外にも、A-G-B及びA-H-Bの2ステップのパスも存在するので、この分だけユーザAから見たユーザBの信頼度を高く計算する。

第二の方針として、上記第一の方針における所定数n（n≧2）ステップまでのパスを有する共通の友人の数が更新され増加していく頻度が高いほど、共通の友人の交流も活発であると判断できることから、当該ユーザ同士の信頼度をより高く算出する。

以上の第一及び第二の方針によれば、具体的には例えば次のようにして、１ステップでつながるユーザに対する信頼度tr1を算出することができる。信頼度tr1に用いる値として、当該ユーザ間において、最小回数i（i≧2）で辿りつくパスの数をs_iとする。例えば、図４の例にてユーザAから見たユーザBの信頼度を算出する場合、上記A-G-B及びA-H-Bが存在するので、当該ユーザA, B間においてs₂＝2である。

また、信頼度tr1に用いる値として、当該ユーザ間において、最後に当該i回で辿りつく友人が追加された時点（いずれかのユーザのアドレス帳更新によって、当該i回のつながり関係が新たに発生した直近の時点）から現時点までの経過時間をt_iとする。例えば、図４の例にてユーザAから見たユーザBの信頼度を算出する場合、上記A-G-B及びA-H-Bのつながり関係が発生した日時をT(G)及びT(H)とし、現在日時をT_nowとすると、t₂は、｛T_now−T(G)｝と｛T_now−T(H)｝とのうちの、値が小さい方となる。

以上のパス数s_i及び経過時間t_iと、所定の正値単調増加関数f及び正値単調減少関数gとにより、例えば以下の(式1)で信頼度tr1を算出することができる。定数n（n≧2）は、前述のように、当該考慮するつながりのステップ回数iの上限である。

すなわち、(式1)では関数fが第一の方針の項であり、パスの数s_iが多いほど信頼度を高める。また、関数gが第二の方針の項であり、直近の更新時点からの経過時間t_iが短いほど信頼度を高める。

なお、経過時間t_iについては、アドレス取得部11でアドレス情報を取得する際に、各端末において他端末のアドレスを登録した日時の情報を含めて取得しておき、当該日時の情報から算出することができる。あるいは、アドレス取得部11によるアドレス情報の取得とユーザマップ生成部12によるユーザマップの生成とを定期的に実施し、ユーザマップを定期的に更新すると共に履歴を残すことで、現時点の信頼度算出対象のユーザに関連する部分が現時点の状態になった直近の過去を、当該履歴を参照して求めるようにしてもよい。

なお、第二の方針に関して、(式1)におけるg(t_i)を次の項で置き換えたものを利用してもよい。すなわち、上記履歴をもとに、当該i回のつながり関係が追加され更新される頻度を所定方式で数値化してα_iとし、所定の正値単調増加関数Aを用いたA(α_i)によって、(式1)におけるg(t_i)を置き換えてもよい。

なおまた、第二の方針は利用せずに、第一の方針のみから信頼度tr1を算出してもよい。この場合、(式1)にて、g(t_i)＝1と置き換えればよい。例えば、図４の例においてユーザAから１ステップでつながるユーザB, H, G, I, Fについて第一の方針のみで信頼度を算出すると、その大小関係は以下のようになる。
B＞H＝G＞I＝F

すなわち、Aから見た場合、BにはA-H-B及びA-G-Bという2ステップでつながる関係が2つ存在し、H及びGにはそれぞれA-B-H及びA-B-Gという2ステップでつながる関係が1つ存在し、I及びFには2ステップでつながる関係は存在しないので、上記の大小関係となる。なお、当該例においては、上限ステップ数n＝2としている。

２ステップでつながるユーザに対する信頼度については、１ステップでつながるユーザにおいて適用した第一及び第二の方針に加えてさらに、第三の方針を適用して算出することができる。

第三の方針では、２ステップでつながるユーザ間において、経由する共通の友人の信頼度（１ステップでつながるユーザに関して算出済みの信頼度）を考慮し、当該信頼度が高いほど、当該２ステップでつながるユーザ間の信頼度も高いものとする。

当該２ステップでつながる際に経由する共通の友人jについて(式1)によりそれぞれ求めた信頼度tr1[j]を、全てのjにつき足し合わせた値をTRとする。なお、ここで、j=1, 2, ...であり、複数の２ステップによるつながり関係がある場合に、当該共通の友人が1人以上存在することを当該jで表している。第三の方針を反映するための所定の正値単調増加関数hを用いて、具体的には例えば、以下の(式2)で２ステップでつながるユーザ間の信頼度tr2を算出することができる。

あるいは、以下の(式2-b)及び(式2-c)のように、パスの数s_iを求める際に、各パスで経由するユーザの信頼度を考慮して、その値をs_i'へと修正することで、第三の方針を反映した信頼度tr2を求めてもよい。なお、(式2-b)におけるtr_i,jは、パスの数s_iにおける各パス内の各経由ユーザjに対する信頼度であり、i≧3については以下説明する方法のいずれかで予め算出しておけばよい。

なお、第二の方針及び／又は第三の方針の適用を省略して、ステップでつながるユーザ間の信頼度tr2を算出してもよい。この場合、(式2)などにて、g(t_i)＝1や、h(TR)＝1などといった置き換えを行えばよい。

３ステップ以上のkステップでつながるユーザ間で信頼度trkを求める場合も、２ステップでつながるユーザ間における(式2)のと同様にして、以下の(式20)から算出すればよい。ここで、経由する共通の友人の信頼度として足し合わせる値TRは、k−1ステップ以下で算出済みの値を利用して求め、関数f及びgの積の項の和（Σ）は、(式20)に記載のようにi=kからi＝nまでの範囲で求めればよい。こうして、３ステップ以上でつながるユーザ間の信頼度も、３ステップ、４ステップ、…（n−1）ステップ、nステップ、と順次算出することができる。あるいは、(式20)の代わりに(式2-b),(式2-c)の手法で算出してもよい。

なお、第三の方針を適用しなければ、kステップでつながるユーザ間で信頼度の算出に際して、（k−1）ステップ以下の信頼度TRを参照せずに、ユーザマップ（及び更新日時の情報）のみから算出することが可能である。この場合、(式20)でh(TR)=1と置き換えればよい。

以上のようなつながりの各ステップ数におけるユーザ間の信頼度の算出に際してさらに、第四の方針として、ユーザ間のコミュニケーション頻度を加味して、コミュニケーション頻度が高いほど値が高くなるように信頼度を算出するようにしてもよい。

コミュニケーション頻度に関しては、アドレス取得部11で各ユーザが登録している他ユーザのアドレスを取得した際に、追加情報として、各ユーザのアドレス間における通信履歴として、例えば所定期間に渡る通信回数などとして取得すればよい。こうして、１ステップでつながるユーザ間のコミュニケーション頻度が数値として得られる。

第四の方針により、信頼度の算出に当該数値として得られたコミュニケーション頻度を反映するには、例えば以下のような手法を用いることができる。以下の第一及び第二の手法は、いずれか片方のみを利用してもよいし、両方利用してもよい。

第一の手法として、(式1)の代わりに、例えば以下の(式3)のように修正したものを利用することができる。ここで、uは当該(式3)にて信頼度を算出する対象となっているユーザ間のコミュニケーション頻度の数値であり、Fは所定の単調増加関数である。

第二の手法として、(式1)又は(式3)や、(式2)、(式20)における最小回数i（i≧2）で辿りつくパスの数s_iを、例えば以下の(式4)のようにして、当該s_i個のパス内における各2ユーザ間のコミュニケーション頻度の値uの総和U_iに基づいて修正した値とすることができる。ここで、Gは所定の正値単調増加関数であり、１より大きな値を取る。当該修正された値は、必ずしも整数でなくともよい。なお、以下の(式4)の修正手法は例であり、その他の手法でコミュニケーション頻度をs_iの値に反映してもよい。(式2-b)及び(式2-c)等を併用して、s_iの値を修正してもよい。

あるいは、パスの数s_iを(式4)のように修正して用いる代わりに、上記(式4)のG(U_i)自体を、関数fやgの項に対して積算してもよい。例えば(式2)であれば、以下の(式5)のように修正してもよい。

第五の方針として、以上におけるパス数s_iの項による信頼度への寄与を、ユーザマップ生成部12の説明にて前述のアドレス登録が単方向ではなく双方向である場合に、例えば2倍の寄与があるものとして考慮する等して、単方向のみ登録されている場合よりも信頼度を高く算出するようにしてもよい。この場合、(式4)と類似の手法により、当該s_i個のパス内における各2ユーザ間の登録のうち双方向であるものの割合などに基づいて、当該割合が大きいほどその値が大きくなるように、s_iの値を修正すればよい。

以上、信頼度算出部13を説明した。以下、図３に戻って、各部の説明を行う。

マッチング部14は、マッチングを要求するユーザAの端末1Aに対して、信頼度算出部13が算出した当該ユーザAから見た他ユーザの信頼度に基づき、マッチング相手を提示する等してマッチングの仲介を行う。当該仲介のため、各部141,142,143は以下のような処理を行う。

条件取得部141は、各端末より、ユーザ同士でイベントを共有する際に相手に対して課す条件を取得する。当該条件は、所定の項目に分けたうえで、各項目についてイベントの共有相手に対して要求するか否かをユーザに選択させることによって、特定されるようにしてもよい。こうした所定項目は、マッチングのリクエストを受け付ける前に予め、各ユーザから選択させるようにしてもよい。また、リクエスト時に端末等から取得される所定のデータに基づく項目が存在してもよい。

例えば、当該イベントが車両の乗り合いである場合であれば、予め選択する所定の項目として、各ユーザが車両を提供する側か提供される側かを特定する項目の他に、次のようなものを設けておいてもよい。車両の提供ユーザが提供相手のユーザに課す条件の項目として、車両を提供可能な日時及び地域や、提供相手ユーザの属性（性別、年齢、住所、運転免許証の有無その他）などを設定してよい。逆に、車の提供を受けるユーザの側からの条件として、車両の提供を受けたい（乗り合いを行いたい）日時及び地域や、提供ユーザの属性を設定してもよい。

ここで、地域は、出発地及び到達地に分けて設定されてもよい。提供相手ユーザ及び提供ユーザの属性を他者から参照して判断する際に利用可能なように、それぞれ提供ユーザ及び提供相手ユーザの立場としての、自分自身の属性を設定してもよい。その他、特許文献１等に開示の諸項目を設定してもよい。

なお、各項目については、当該項目を条件として課す場合に、所定のメニュー内から該当するものを選択することで特定可能なように構成されていてもよい。例えば、地域については、関東・関西などのメニュー項目の中から選択して特定されるようにしてもよい。当該項目については要求しない場合、その旨を表すメニュー項目を選択するように構成されていてもよい。

また、車両の乗り合いの場合、リクエスト時に条件取得部141により端末から取得される所定のデータとして、各端末の位置情報を利用してよい。なお、位置情報は、GPS（全地球測位システム）等により各端末が取得する。車両の提供側のユーザであれば、位置情報は、提供する車両に備わる機器（カーナビゲーションシステム等）で取得したものであってもよい。

当該位置情報は、車両の乗り合いをリクエストする側のユーザが、リクエストしてから直ちにその時点で車両を提供可能な近くの位置に存在するユーザ（偶然、近くで共通目的地に向かって運転中のドライバなど）を探索し、ユーザ間で合意を行ったのち、速やかにユーザ間で落ち合って乗り合いを実施するような場合に利用することが好ましい。車両の乗り合いを将来（例えば１週間後などに）実施するための予約としてリクエストがなされる場合、当該位置情報は必ずしも必要ない。

なお、上記のように直ちに乗り合いを実施する場合は、リクエスト側は条件取得部141に対してその旨を入力し、提供側は、所定期間において（位置情報の条件が合致すれば）そのようなリクエストに対応可能か否かを、条件取得部141に設定するようにしておけばよい。当該設定により、以下説明する候補提示部142により、条件合致ユーザを自動選定可能となる。

候補提示部142は、マッチング要求を行うユーザAに対して、信頼度算出部13で算出された当該ユーザAから見た信頼度が高い側のユーザから順次、条件取得部141で取得したユーザA及び当該信頼度の高いユーザの両者における条件が合致するかを確認し、合致したものを所定数、マッチング候補のリストとしてユーザAの端末1Aに通知する。なお、当該合致するかの確認は、両ユーザにおいて設定された所定項目が全て整合するかを調べることにより、自動で確認可能である。当該リストの通知の際に、信頼度の値又はその順位・ランクや、マッチングに関連して条件取得部141で取得した事項を併せて通知してもよい。

前述のGPS等による位置情報を利用する場合は、候補提示部142は、位置情報により求まるユーザ間の距離が所定値以内である場合に、合致と判定すればよい。当該所定値に関しても、条件取得部141に対して各ユーザで予め入力して設定するようにしてもよい。この場合、2ユーザで異なる距離が設定されていた場合、小さい方の値を合致判定に用いればよい。あるいは、所定の地域区分がなされた地図を用意しておき、位置情報において両ユーザが同一地域にある場合に、合致と判定してもよい。

なお、前述のように、１ステップつながりは直接の友人であるので、端末1Aに通知するマッチング候補は、２ステップでつながるユーザの中から信頼度の高い順に選ぶようにすることが好ましい。２ステップでつながるユーザの中から条件が合致するユーザが所定数に達しない場合は、３ステップでつながるユーザを対象として、同様に信頼度の高い順から選ぶようにしてもよい。数が不足する場合はさらに同様に、４ステップ以降のユーザから選べばよい。以降、同様である。

例えば、図４の例でユーザAがマッチング要求を行っている場合、ユーザAの端末1Aには、２ステップでつながる友人C, D, Eのうち、条件が合致しているユーザが信頼度の高い順にリストで通知される。この際、後述の確定部143での選択のために、候補ユーザのプロフィール等の情報（共通の友人がBである旨や、現時点での位置情報など）を併記してリストを提示してもよい。なお、信頼度順位は必ずしも通知する必要はない。順位に代えて、信頼度が「高」あるいは「普通」など、ランクを通知してもよいし、信頼度の値を通知してもよい。

なお、候補提示部142による候補リストの通知は、各種の態様が可能である。例えば、端末1Aの側に電子メールなどの形式で送信して通知するようにしてもよいし、信頼度算出装置10の提供するウェブサイト上で、端末1Aのマッチングのために生成したウェブページによって通知するようにしてもよい。

確定部143は、上記候補リストの通知を受けたユーザAの端末1Aと、マッチングを行う相手としてユーザAから選択されたユーザの端末と、の間において、イベント共有に関する最終的な合意の確認を、当該両ユーザの端末を介して仲介することでマッチングを確定させる。当該確定のフローは以下のステップ(S1)及び(S2)の通りである。

(S1)リクエスト側ユーザAは、候補ユーザのリストよりマッチングを望む相手xを選択し、端末1Aより確定部143に通知する。

(S2)確定部143は、当該選択されたユーザxの端末1xとリクエスト側ユーザAの端末1Aとの間で通信を確立させ、両者がマッチングに合意するかの確認を行わせる。合意がなされれば、その旨を確定部143が受信して当該フローは終了する。合意に至らなければ、その旨を確定部143が受信した後、相手xとして別の相手を選択させることをユーザA側に通知し、ステップ(S1)に戻って繰り返す。

当該フローの補足事項は以下の通りである。

ステップ(S2)にて通信を確立させる場合、依頼側ユーザAの選択結果xに従って両ユーザA及びxに相手のアドレス（アドレス取得部11で取得したものと同種）を通知して、当該アドレスに対応する通信手段（アドレスが電話番号であれば、電話）で合意確認を行わせるようにしてもよい。また、当該アドレスは通知せず、確定部143を介して（信頼度算出装置10が提供するウェブサイト等、専用の通信手段により）合意確認の仲介を実施してもよい。

車両の乗り合いの場合であれば、当該ステップ(S2)の確認の際に、両ユーザA,x間では、実際にどのように落ち合うかの取り決めも行うことも可能である。

なお、車両の乗り合いの場合であれば、前述の条件取得部141で取得したGPS等による位置情報は、候補提示部142で条件の合致判定に利用するか否かとは独立に、次のように利用してもよい。

第一に、確定部143の仲介によるステップ(S2)での合意の確認の際に、合意するか否かを依頼されたユーザx側で判断するための情報として、依頼された側の端末1xにリクエスト側の端末1Aの位置情報を提供してもよい。第二に、リクエスト側の端末1Aにおいて、ステップ(S1)にて候補リストの中から選択する際の参考情報とすべく、候補提示部142が候補リストを作成する際に、当該候補リストに候補ユーザの位置情報を含めておくようにしてもよい。

以上、マッチング部14による第一実施形態として、マッチングを依頼する側のユーザAと、マッチング候補となるユーザ（２ステップ以上離れたユーザ）と、の間での仲介を行う例を説明した。次に、マッチング部14による第二実施形態として、依頼側ユーザAの直接の友人である１ステップでつながるユーザからの推薦を追加して利用することで、マッチングを行う例を説明する。

なお、当該推薦を可能とするため、第二実施形態では、マッチング候補となるユーザは２ステップ離れたユーザのみで構成され、３ステップ以上離れたユーザは含まれない。

第二実施形態では、条件取得部141は第一実施形態と同様の処理を行い、候補提示部142及び確定部143が、直接の友人を介することによって第一実施形態と異なる処理を行う。当該処理はマッチング相手が確定するまで繰り返しを含むので、以下(S10)〜(S50)とステップを分けて説明する。

(S10)候補提示部142は、第一実施形態と同様にして所定数の候補ユーザをリストとして求め、第一実施形態とは異なり当該リストに記載の候補ユーザの代わりに、候補ユーザとのつながりを発生させている直接の友人のリスト（推薦依頼リスト）を、マッチングを要求する端末1Aへと通知する。

(S20)端末1Aでは、リクエストユーザAが当該直接の友人のリスト（推薦依頼リスト）の中から、マッチング相手の推薦を依頼したい友人Xを選択して、確定部143に通知する。

(S30)確定部143では、上記候補提示部142の求めた候補ユーザのリスト内より、当該友人Xを介してユーザAとつながっているユーザを推薦候補リストとして抽出し、当該友人Xの端末1Xに対して、推薦を行わせるために当該推薦候補リストを送信する。

(S40)友人Xは、推薦候補リスト内より、友人Aに対して推薦するマッチング相手Yを選択して、確定部143に通知する。（なおここで、特記すべき点として、推薦候補リストにはユーザXの直接の友人が記載されており、推薦依頼者AもユーザXの直接の友人であるので、ユーザXは推薦相手Yを決めやすい点が挙げられる。）

(S50)確定部143は、第一実施形態のステップ(S2)と同様にして、ユーザAの端末1Aと、推薦されたマッチング相手Yの端末1Yとの間で、合意確認の仲介を行う。合意に至れば、その旨を確定部143が受信してフローは終了する。合意に至らなかった場合、ステップ(S2)とは異なる場合分けとして、以下の(C1)又は(C2)のような場合分けに従い、合意に至るまで同様の処理を繰り返す。

(C1)推薦を依頼した友人Xにおける推薦候補リスト内にその他のユーザが残っていれば、上記ステップ(S40)に戻り、確定部143は残っているユーザから再度友人Xの側に推薦を促し、以降同様の処理を行う。

(C2)推薦を依頼した友人Xにおける推薦候補リスト内にその他のユーザが残っていなければ、上記ステップ(S20)に戻り、確定部143はマッチング要求ユーザAに対して、直接の友人のリスト（推薦依頼リスト）から、共通の友人X以外を推薦相手として選択させた後、以降同様の処理を行う。

なお、以上のステップにおいて、友人「Ｘ」及び相手「Ｙ」は、各ステップの時点で残っているユーザ名を格納するための「変数」である。従って、当該「Ｘ」及び「Ｙ」は、プログラム処理を記述する際の慣例に従い、繰り返しの処理がなされた場合は、対応する残っているユーザ名に置き換えられるものとする。また同様に、(C2)等では既に依頼済みの友人を全て除外した中から、推薦相手を選択させる。

また、ステップ(S30)で推薦候補リストを抽出する際は、候補ユーザのリストに記載の信頼度の順番で抽出して、友人Xに対してステップ(S40)での判断に供すべく、信頼度の順位の情報を伝えるようにしてもよい。

図６並びに図７及び図８は、以上の第一実施形態及び第二実施形態のマッチング例を示すための図である。図６は、当該例にて利用するユーザマップであり、図４のユーザマップに対してさらに、Gの友人J, K, Lが追加されている。図７及び図８は、ユーザAがマッチングを要求した際に、それぞれ第一実施形態及び第二実施形態で確定部143によって、対応する各ユーザに提示される画面の例である。図７及び図８の例では、ユーザAに対し、両実施形態において、２ステップつながりのC, D, E, J, K, Lの6名のうち、条件が合致したのがC, D, J, Kの4名が候補ユーザであったものとする。

図７は、第一実施形態で各ユーザに提示される一連の画面の例である。画面G10では、マッチング要求ユーザAに対して候補ユーザC, D, J, Kが提示されている。画面G11では、当該ユーザAが候補ユーザCを選んだ場合に、ユーザCに対して許諾するかの確認を求めている。画面G12は、当該ユーザCが許諾した場合に、許諾した旨をユーザAに伝えている。画面G13は、当該ユーザCが許諾しなかった場合に、ユーザAにCを除いた残りの候補ユーザD, J, Kの中からの選択を促している。

図８は、第二実施形態で各ユーザに提示される画面の例である。画面G20では、マッチング要求ユーザAに対して候補ユーザを推薦可能な友人B, Gが提示されている。（なおここで、候補ユーザC, D, J, Kのうち、C, Dの友人がBであり、J,Kの友人がGである。）画面G21では、当該ユーザAが友人Bに推薦を依頼した場合に、ユーザBに対して、候補ユーザC, D（すなわち、Bの友人）の中からの推薦を依頼している。

画面G22では、ユーザBが候補ユーザCを推薦対象として選んだ場合に、ユーザCに対してユーザBの推薦でユーザAとのマッチングを許諾するかの確認を求めている。画面G23は、当該ユーザCが許諾した旨をユーザAに伝えている。画面G24は、当該ユーザCが許諾しなかった場合に、ユーザBに残っている候補ユーザDのからの推薦を促している。

なお、画面G24の後にユーザBが候補ユーザDを推薦し、ユーザDが許諾しなかった場合には、ユーザBにおける推薦候補リスト内の全ユーザC, Dが不許諾となり、ユーザBからは推薦不可能となる。この場合、画面G20に対応する画面によって依頼ユーザAに対して残っている推薦依頼ユーザ（ユーザG）を選択させる。そして、推薦依頼されたユーザGは、画面G21に対応する画面によって、ユーザJ, Kの中からの推薦を促される。

なお、システム側（信頼度算出装置10側）では、マッチング部14において、ライドシェアを利用する人の履歴を保存しておき、利用料金の計算に利用してもよい。この履歴には、乗った場所（GPS）・降りた場所（GPS）・仲介した友人（仲介者がある場合）・車に乗せた友人の友人が記録される。利用頻度と距離にもとづいて料金が計算され、仲介した友人に対して、利用料金の一定割合がフィードバックされてもよい。利用料金（及びフィードバック料金）は条件取得部141での取得条件をもとに、ライドシェアを行った場合に想定される目安の値を予め算出して、依頼側及び許諾側の両者（及び仲介者）に確認のため提示するようにしてもよい。

以下、補足事項を説明する。

第一の補足事項として、本発明の説明において、「つながり」は友人関係であるものとして説明したが、アドレスの登録関係に基づくものであるので、当該「つながり」は知人の関係や家族の関係その他であってもよい。

第二の補足事項として、マッチング部14によるマッチングは、車両の乗り合いの場合を例として、車両に乗ることを要求する1ユーザAと、車両を提供する1ユーザとのマッチングを説明したが、当該車両に乗ることを要求するユーザが2人以上存在してもよい。

当該リクエスト側が２人以上存在する場合、以下の条件(1)〜(3)を候補提示部142にて確認する。
(1)リクエスト側の全員が条件取得部141に対して入力することで相手に対して設定した条件（乗り合いの日時を含む）が一致する。
(2)リクエスト側の全員に共通の友人が存在し、当該友人の友人が上記条件を満たして車両を提供可能である。
(3)当該車両の提供者と、リクエスト側の全員と、から選ばれた任意の2者が直接の友人ではない。

上記全条件(1)〜(3)の確認後、確定部143にて、当該車両の提供者と、リクエスト側の全員と、の間での最終合意の仲介を行えばよい。

あるいは、車両に乗ることを要求する1ユーザAは、当該Aの知人などを含む複数のリクエスト者の代表であって、当該複数が乗車を要求することを条件取得部141に設定したうえで、以上説明した1ユーザAの実施形態によって、1人の車両提供者を見つけ、複数人での乗り合いを実現してもよい。

あるいは、車両を提供するのはユーザではなく別途の業者等であって、その際の乗り合い条件を設定するために、各ユーザ間でマッチングがなされてもよい。

第三の補足事項として、条件取得部141でユーザ属性（性別、年齢、住所、運転免許証の有無その他）を取得する場合、ユーザ属性における所定項目の一致、不一致などに基づく所定の数式でユーザ間の相性を数値化してもよい。候補提示部142では、信頼度算出部13で算出された信頼度にさらに当該相性を加味した値を、以上説明した信頼度の代わりに用いてもよい。

第四の補足事項として、信頼度算出装置10は、図３の構成からマッチング部14を省略したものであってもよい。信頼度算出部13の算出した信頼度により、その他の手法でマッチングを実現してもよいし、マッチング以外の用途に信頼度を利用してもよい。なお、マッチング部14を省略しない構成においては、信頼度算出装置10をマッチング装置10と称してもよい。

10…信頼度算出装置、11…アドレス取得部、12…ユーザマップ生成部、13…信頼度算出部、14…マッチング部、141…条件取得部、142…候補提示部、143…確定部

Claims (12)

1. 各ユーザの端末を介して、各ユーザにおける他ユーザの信頼度を算出する信頼度算出装置であって、
   各端末より、登録されている他ユーザの端末のアドレスの情報を取得するアドレス取得部と、
   前記取得したアドレスを用いて、各ユーザをノードとし、アドレス登録があるユーザ間にエッジを設けたグラフとして、ユーザマップを生成するユーザマップ生成部と、
   前記生成したユーザマップを用いて、各ユーザにおける他ユーザの信頼度を、当該ユーザから他ユーザに至るパスに基づいて算出する信頼度算出部と、を備えることを特徴とする信頼度算出装置。
2. 前記信頼度算出部は、各ユーザから他ユーザに至るパスの数及び各パスのステップ数に基づいて信頼度を算出することを特徴とする請求項１に記載の信頼度算出装置。
3. 前記信頼度算出部は、各ユーザにおける他ユーザの信頼度を、当該ユーザから他ユーザに至るパスに基づいて、当該パス上に存在するユーザの端末に登録されているアドレスの更新頻度を加味して、信頼度を算出することを特徴とする請求項１または２に記載の信頼度算出装置。
4. 前記信頼度算出部は、各ユーザにおける他ユーザの信頼度を、当該ユーザから他ユーザに至るパスの最短ステップ数毎に区別して算出することを特徴とする請求項１ないし３のいずれかに記載の信頼度算出装置。
5. 前記信頼度算出部は、前記最短ステップ数が小さい側から順に、各ユーザにおける他ユーザの信頼度を算出し、当該ユーザから他ユーザに至るパスに基づいて、当該パス上に存在するユーザに対して既に算出されている信頼度を加味して、信頼度を算出することを特徴とする請求項４に記載の信頼度算出装置。
6. 前記信頼度算出部は、各ユーザにおける他ユーザの信頼度を、当該ユーザから他ユーザに至るパスに基づいて、当該パス上に存在するユーザの端末間における通信履歴を加味して、信頼度を算出することを特徴とする請求項１ないし５のいずれかに記載の信頼度算出装置。
7. 前記信頼度が、ユーザ間で所定イベントを共有することに関するものであることを特徴とする請求項１ないし６のいずれかに記載の信頼度算出装置。
8. マッチングを要求するユーザの端末に対して、当該要求ユーザに対して前記算出された信頼度に基づいてマッチング候補のユーザを提示することで、端末間でのマッチングの仲介を行うマッチング部をさらに備えることを特徴とする請求項１ないし７のいずれかに記載の信頼度算出装置。
9. 前記マッチング部が、
   各ユーザの端末よりマッチングの際の条件を所定項目から選択させることで取得する条件取得部と、
   前記要求ユーザとの間で前記取得した条件が合致し、且つ前記算出された信頼度が高い側の所定数のユーザをマッチング候補として、前記要求ユーザの端末に通知する候補提示部と、
   前記要求ユーザによって前記マッチング候補から選択されたユーザの端末と、前記要求ユーザの端末との間で、マッチングを確定するための仲介を行う確定部と、を含むことを特徴とする請求項８に記載の信頼度算出装置。
10. 前記候補提示部が、前記ユーザマップを参照して、前記要求ユーザと２ステップ以上でつながるユーザからマッチング候補を選択することを特徴とする請求項９に記載の信頼度算出装置。
11. 前記条件取得部が、前記マッチングの際の条件としてさらに、、各ユーザの端末より位置情報を取得することを特徴とする請求項９または１０に記載の信頼度算出装置。
12. 前記マッチングが、ユーザ同士での車両の乗り合いに関するものであることを特徴とする請求項９ないし１１のいずれかに記載の信頼度算出装置。