未来の出会いと恋がわかる！キュンする新技術たち

位置情報を常に発信・受信するスマートフォンの普及に伴って、最近では位置情報を用いたゲーム（いわゆる位置ゲー）や、コロナウイルス感染症の拡大防止のための接触確認アプリ（COCOA：現在は機能停止）といった形で、スマホが携帯型コンピュータ端末であることを前提としたアプリが活用されるようになってきました。

このような携帯端末の究極形は、いわゆるウェアラブル端末といわれる「身につけるコンピュータ」ですが、その中でもARグラス（拡張現実グラス）はコンピュータのモニターを透かして現実世界を観るということで、仮想現実技術が発展するとともに、その活用方法の研究開発が広く行われています。

今回紹介する特許は、ARグラスを用いたリアルタイムのマッチングサービスに関し、街を歩いて自動的に好みの相手を探し出すというものです（もちろん、相手に声をかけることができるかはユーザーの「コミュ力」によります）。どのような技術・観点で「好みの相手」を抽出するのか、特許発明の詳細について、解説していきます。

発明の背景

ソフトバンクは、ウェアラブルコンピューティングの関連機器と、その利用方法に関する研究開発を続けていて、カメラを内蔵した眼鏡型デバイスによって、ユーザーが注視している人物を特定して、その人物に関連する情報を表示する技術（特開2012-008290）を開示しています。

この技術は、あくまでも注視している対象人物を、サーバと連携して精度良く特定することができる技術を開示したものであり、その応用範囲を具体的に特定するものではありませんでした。

どんな発明？

発明の目的

本発明は、マッチングシステム、眼鏡型デバイス、マッチングサーバ及びプログラムに関するものです。AR（Augmented Reality：拡張現実）グラス等の眼鏡型デバイスは、今後普及が進み、眼鏡型デバイスによって、装着者の視線データ、つまり何を見ているかという情報が取得可能になります。

例えば、通り過ぎた人の中でどのような人に着目したかがわかるようになります。本発明は、このような情報が取得できるという技術を前提として、その情報をもとにしたマッチングサービスを提供しようというものです。

発明の詳細

では、図・画像を一部参照しながら、本発明の詳細を説明していきます。

まず、図１は、マッチングシステム１０の一例を概略的に示したものです。マッチングシステムは、複数の眼鏡型デバイス１００とマッチングサーバ３００を備えます。

【図１】

眼鏡型デバイス１００は、いわゆるARグラスです。撮像範囲に合わせたコンテンツを、透明又は半透明のグラス上に表示することによって、実空間にコンテンツが配置されているような感覚をユーザ１０２に与えることが可能なデバイスです。

マッチングサーバ３００は、ユーザ１０２に対してマッチングサービスを提供します。マッチングサービスとは、恋人や結婚相手等を見つけることを支援するサービスです。マッチングサーバ３００は、ユーザ１０２に対して、当該ユーザの好みの顔の特徴を持った人物を紹介したり、当該ユーザの顔の特徴が好みである相手を紹介したり、互いに好みが一致した相手を紹介したりするサービスを提供します。

【図２】

図２は、マッチングシステム１０における処理の流れの一例を概略的に示したものです。ここでは、ユーザ１０２が、マッチングサーバ３００のマッチングサービスに登録して、ユーザ１０２の好みにあった他のサービス登録者の「レコメンド」を受けるまでの流れを概略的に示します。

ステップ（以下、ステップをＳと省略して記載します）１０２では、ユーザ１０２が、眼鏡型デバイス１００によって、マッチングサーバ３００に利用者登録を行います。眼鏡型デバイス１００は、ユーザ１０２の指示に従って、ユーザ１０２の登録者情報をマッチングサーバ３００に送信します（もちろん、ユーザは眼鏡型デバイス経由だけでなく、スマホやPCから利用者登録を行ってもよい）。

Ｓ１０４では、ユーザ１０２が日常生活を送っている間に、眼鏡型デバイス１００が、ユーザ１０２が注目した人物の顔画像をマッチングサーバ３００に送信していきます。眼鏡型デバイス１００は、眼鏡型デバイス１００のカメラによって撮像された撮像画像から、ユーザ１０２が注目した人物の顔画像を取得して、マッチングサーバ３００に送信していくのです。

Ｓ１０６では、マッチングサーバ３００が、ユーザ１０２の眼鏡型デバイス１００から受信した複数の顔画像に基づいて、ユーザ１０２の好みの顔の特徴を学習します。Ｓ１０８では、マッチングサーバ３００が、Ｓ１０６において学習した学習データに基づいて、複数のサービス登録者から、ユーザ１０２の好みの顔の特徴を有するサービス登録者を抽出します。

【図３】

図３は、眼鏡型デバイス１００による顔特定処理について説明するための説明図です。眼鏡型デバイス１００は、ユーザ１０２の視線に基づいて、ユーザ１０２が注目した顔を特定していきます。

例えば、ユーザ１０２の視線が向けられた人物に対応するレンズ上の位置に、人物のアイコン４００を表示します。

ここから、ユーザ１０２が「本当に注目した顔」であると決定するにあたっては、いくつかの態様が考えられます。例えば手動登録の態様としては以下の２つの例が挙げられます。手動登録とすることによって、マッチングサーバ３００は、ユーザ１０２の好みの顔の顔画像を高い精度で収集することができます。

①ユーザ１０２によってアイコン４００が指定された場合に、指定されたアイコン４００に対応する顔を、ユーザ１０２が注目した顔として特定する。
②アイコン４００に「いいねボタン」を含め、ユーザ１０２によっていいねボタンが指定されたことに応じて、ユーザ１０２が注目した顔として特定する。

これに対して、眼鏡型デバイス１００は、ユーザ１０２が注目した顔を自動登録する態様も考えられます。

③ユーザ１０２が視線を向けた回数に基づいて、ユーザ１０２が注目した顔を特定する。例えば、ユーザ１０２の視線が向けられた回数が予め定められた回数よりも多い顔を、ユーザ１０２が注目した顔として特定する。
④ユーザ１０２が視線を向けた時間に基づいて、ユーザ１０２が注目した顔を特定する。例えば、ユーザ１０２の視線が向けられた時間が予め定められた時間よりも長い顔を、ユーザ１０２が注目した顔として特定する。

自動登録とすることによって、ユーザ１０２に負荷をかけることなく、マッチングサーバ３００が、ユーザ１０２の好みである可能性が高い顔の顔画像を収集することができます。

【図４】

上述のようなARグラスの例示としては、図４のようなデバイスが考えられます。カメラ１２０、センサ１２２、視線検出部１２４、制御装置２００などを備えます。センサ１２２は周囲の環境を特定するために必要なものです。視線検出部１２４はユーザの目を常に撮像してその視線を検出します。制御装置２００は例えばGPSやジャイロセンサなどによって眼鏡型デバイスの位置や向き、姿勢を特定するセンサをはじめ、ネットワークを介した通信を行ったりする中核的な機能を有するものです。図５に、制御装置２００の機能構成を例示します。

【図５】

撮像画像取得部２０４は、カメラ１２０によって撮像された撮像画像を取得し、格納部２０２に格納（保存）します。

利用者登録部２０６は、ユーザ１０２の指示に従って、マッチングサーバ３００に対して利用者登録を行います。

視線情報取得部２１０は、ユーザ１０２の視線を示す視線情報を、視線検出部１２４から取得します。

顔画像取得部２１２は、ユーザ１０２の視線に基づいて、カメラ１２０によって撮像された撮像画像から顔画像を取得します。

顔画像送信部２１４は、顔画像取得部２１２によって取得された顔画像をマッチングサーバ３００に送信します。

指定受付部２１６は、ユーザ１０２による、撮像画像取得部２０４が取得した撮像画像内の顔の指定を受け付けます。

表示制御部２１８は、通知情報受信部２２２が通知情報を受信した場合に、レンズ１１６に通知アイコンを表示します。

撮像画像送信部２２０は、撮像画像取得部２０４によって撮像される撮像画像を継続的にマッチングサーバ３００に送信します。マッチングサーバ３００は、眼鏡型デバイス１００から継続的に受信する撮像画像を解析して、ユーザ１０２の好みの顔の特徴を有すると推定したサービス登録者が含まれるか否かを判定します。そして、含まれると判定した場合に、眼鏡型デバイス１００に対して通知情報を送信します。

通知情報受信部２２２は、マッチングサーバ３００から通知情報を受信します。

位置情報送信部２２４は、眼鏡型デバイス１００の位置情報をマッチングサーバ３００に送信します。予め定められたタイミングに従って、眼鏡型デバイス１００の位置情報をマッチングサーバ３００に送信します。

マッチングサーバ３００に関する機能構成の一例は、図６に示されます。

【図６】

登録受付部３０２は、ユーザ１０２による、マッチングサービスに対する登録を受け付けます。

登録者情報格納部３０４は、登録受付部３０２が受信した登録者情報を格納します。

顔画像受信部３０８は、複数のユーザ１０２のそれぞれの眼鏡型デバイス１００から、顔画像取得部２１２が、ユーザ１０２の視線に基づいて取得した顔画像を受信します。

収集情報格納部３１０は、顔画像受信部３０８が眼鏡型デバイス１００から受信した顔画像を、当該眼鏡型デバイス１００のユーザ１０２に対応付けて格納します。

顔画像特定部３１２は、登録者情報格納部３０４に格納されている複数の顔画像から、収集情報格納部３１０に格納されている一のユーザ１０２に対応する複数の顔画像に類似する顔画像を特定します。例えば、収集情報格納部３１０に格納されている一のユーザ１０２に対応する複数の顔画像に基づいて、当該一のユーザ１０２の好みの顔の特徴を学習し、学習データに基づいて、登録者情報格納部３０４に格納されている複数の顔画像から当該一のユーザ１０２に対応する複数の顔画像に類似する顔画像を特定します。

レコメンド実行部３１４は、顔画像特定部３１２によって特定された顔画像に基づいて、ユーザ１０２に対する他のサービス登録者のレコメンドを実行します。例えば、顔画像特定部３１２によって特定された顔画像に対応するサービス登録者を、ユーザ１０２が好みの相手として、レコメンドします。

また、例えば、顔画像特定部３１２が特定した、収集情報格納部３１０に格納されている他のサービス登録者に対応する複数の顔画像に類似する顔画像に、ユーザ１０２の顔画像が含まれる他のサービス登録者を、ユーザ１０２の顔を好みとする相手として、ユーザ１０２にレコメンドすることも考えられます。これにより、ユーザ１０２は、複数のサービス登録者のうち、自分の顔を好みとする可能性が高いサービス登録者を知ることができます。このように、本実施形態に係るマッチングシステム１０によれば、自分を好みとする相手を探すことに貢献でき、マッチングが成立する可能性を高めることができるのです。

なお、サービス登録者であることを、外部に公開するか否かは、当該サービス登録者の設定に応じて変更可能です。例えば、登録受付部３０２は、ユーザ１０２による、サービス登録者であることを外部に公開するか否かの設定を受け付けます。ユーザ１０２は、例えば、自分の状況に応じて、適宜、設定を変更し得ます。レコメンド実行部３１４は、第１のユーザ１０２に対してレコメンドする対象となる第２のユーザ１０２の当該設定に基づいて、第１のユーザ１０２への第２ユーザ１０２のレコメンドを実行するか否かを判定します。

具体的には、レコメンド実行部３１４は、一のユーザ１０２が装着している眼鏡型デバイス１００の撮像範囲内に、顔画像特定部３１２によって特定された一のユーザ１０２に対応する複数の顔画像に類似する顔画像に対応する他のサービス登録者が含まれる場合に、当該サービス登録者の設定を確認します。

そして、サービス登録者であることを外部に公開するよう設定されている場合には、当該他のサービス登録者を一のユーザ１０２にレコメンドし、サービス登録者であることを外部に公開しないよう設定されている場合には、レコメンドを行いません。これにより、例えば、街中で急いでいるとき等、声をかけられたくない状況のときに、急に声をかけられてしまうことを防止することができ、ユーザ１０２の利便性を向上することができます。

【図７】

図７は、眼鏡型デバイス１００による通知アイコン４１０の表示例を概略的に示したものです。眼鏡型デバイス１００は、カメラ１２０の撮像範囲内に、ユーザ１０２が好みとする顔の特徴を有すると推定したサービス登録者が含まれる条件が満たされたことに応じ、マッチングサーバ３００が送信した通知情報に基づいて、通知アイコン４１０をレンズ１１６に表示します。通知アイコン４１０は、図７に示すように、「好みの方が付近にいます」等のメッセージを含みます。これにより、ユーザ１０２は、サービス登録者であって、自分が好みとする顔の特徴を有する人物を認識することができます。このようなマッチングシステム１０によれば、出会いの機会を増加させることが可能です。

【図８】

眼鏡型デバイス１００による通知のさらなる例として図８が示されます。眼鏡型デバイス１００は、眼鏡型デバイス１００の位置から予め定められた範囲内に、ユーザ１０２が好みとする顔の特徴を有すると推定したサービス登録者が含まれる条件が満たされたことに応じてマッチングサーバ３００が送信した通知情報に基づいて、通知アイコン４２０をレンズ１１６に表示します。通知アイコン４２０は、対象となるサービス登録者が位置する方向を示す方向オブジェクト４２２を含みます。これにより、ユーザ１０２は、サービス登録者であって、自分が好みとする顔の特徴を有する人物がいる方向を認識することができます。このように、本実施形態に係るマッチングシステム１０によれば、出会いの機会を増加させることができるのです。

さて、ここまで、好みである可能性の高い相手をレコメンドするまでの仕組みを説明してきましたが、レコメンド後、レコメンド実行部３１４は、ユーザ１０２に対して他のサービス登録者をレコメンドした後に、ユーザ１０２と他のサービス登録者とのマッチングが成立したか否かを特定します。

例えば、眼鏡型デバイス１００は、レコメンドされた相手とマッチングしたことを送信するＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を表示する。そして、眼鏡型デバイス１００は、ＵＩに対するユーザ１０２の指定を受け付けた（つまり、ユーザ１０２が手動でマッチングしたことを入力した）ことに応じて、ユーザ１０２と他のサービス登録者とがマッチングしたことを通知する通知情報をマッチングサーバ３００に送信します。

逆に、ＵＩに対するユーザ１０２の指定を受け付けないまま一定時間が経過し、タイムアウトした場合に、マッチングが成立しなかったことを示す通知情報をマッチングサーバ３００に送信します。眼鏡型デバイス１００は、レコメンドされた相手とマッチングしたこと、又はしなかったことを送信するＵＩを表示します。

なお、眼鏡型デバイス１００が、ユーザ１０２と他のサービス登録者とのマッチングが成立したか否かを自動的に判定する態様も考えられます。例えば、レコメンドされた他のサービス登録者が、ユーザ１０２の視界に映る時間が予め定められた時間よりも長かったり、ユーザ１０２と他のサービス登録者との距離が予め定められた距離よりも短い状態が予め定められた時間以上継続したりした場合に、ユーザ１０２と他のサービス登録者とがマッチングしたとみなします。

そして、レコメンド実行部３１４は、マッチングが成立している状態である場合には、レコメンドを一時的に停止します。

これにより、レコメンドによってマッチングし、ユーザ１０２と他のサービス登録者とが食事等を一緒にした場合に、食事中に「好みの方が付近にいます」というレコメンドを受けてしまったり、マッチングしているにも関わらず、自身のことを好みであるという相手に通知が行ってしまったりすることを防止できます。

なお、顔画像送信部２１４は、顔画像取得部２１２が取得した顔画像のうち、除外対象の顔を設定することができます。除外の対象となる人物の顔画像である場合、マッチングサーバ３００に送信しないように構成されます。これにより、好みの顔かどうかにはかかわらず、日常的によく見る家族、友人、及び同僚等の顔が好みの顔として登録されてしまうことを防止できます。

ここがポイント！

本発明は、ARグラス等の眼鏡型デバイスによって、装着者の視線データを取得することによって、ユーザがどのような人に着目したか、逆にどのような人がユーザを着目しているのかというデータを取得し、そのデータに基づいてマッチングを図るシステムです。視線データを解析し、どのような観点・閾値に基づいて「好みの顔」だと認定するかが本発明の技術的ポイントといえるでしょう。

ただ、好みの相手というのは顔だけで決まるものではないことは、一般的に知られたことですので、単に顔を注視したことをもって「好み」とするかどうかは、今後本発明の技術が実用化がされる場合には、議論が分かれるところかもしれません。

未来予想

ARグラス自体はすでに実用可能なデバイスとして、我々もそのガジェットとしての機能・構成は広く理解されていると思われます（現実に広く普及しているかどうかは別として）。しかし、その利用方法については、やはりすでに我々が活用しているモニターに投影する様々な技術、例えばナビゲーションシステムであったり動画等の視聴などは容易に思いつくものの、本発明のようなリアルタイムのマッチング技術というのはなかなか新しい活用方法だと感じます。

現実的には実用化にあたって種々のモラル的な問題をはらんでいるようにも思えますが、技術的には今後のさらなる応用が期待できますね。

特許の概要

昔から、恋愛ステータスアイテムの一つにクルマがありますよね。必ずしも高級車ではなくともよいのですが、素敵なクルマに乗っているとデートも楽しいのではないか、なんて想像しやすかったのかもしれません。このようなクルマを介した出会いを、さらに安全・安心に可能とするかもしれない発明が、日本最大手のカーサプライヤーであるトヨタ自動車から出願されました。

互いのドライバーが、自分の情報や写真、相手に求めるスペックなどをクルマに登録しておくと、走行中に自動的に周囲のクルマをスキャンし、相性の良い相手とマッチングしてくれるのだそうです。

具体的にどのようなシステムなのでしょうか。詳細を解説していきます。

発明の背景

人と人との出会いをサポートするマッチングシステムが知られています。マッチングシステムでは、通常、ユーザは、他のユーザの外見やプロフィールなどを確認したうえで、他のユーザに連絡するか否かを判断します。

近年、こうしたマッチングシステムに、車両（自動車など）を利用することも提案されています。車両を利用すると行動範囲が広くなるため、より多くの人と出会える可能性があります。例えば、ナンバープレートを入力し、該当する車両の所有者に連絡できるマッチングシステムが提案されています。

しかし、車両の運転手は、運転操作に集中する必要があります。そのため、他の車両の乗員の外見などを運転手が確認したうえで、連絡するか否かを運転手が判断することは望ましくありません。また、他の車両の乗員の立場から考えると、見知らぬ人から自身の外見や車両のナンバープレートを確認されることに強い抵抗感を抱きます。

どんな発明？

発明の目的

本発明では、車両の乗員同士が、より安全かつ安心して出会えるマッチングシステムを提供します。

本発明のマッチングシステムには、ホスト乗員が乗車するホスト車両、および、ゲスト乗員が乗車するゲスト車両が登場します。やや抽象的でわかりにくいため、あえて「ホスト」を「男性」に、「ゲスト」を「女性」に置き換えて説明します。なお、女性がホストで男子がゲストである場合もあります。

さらには、同じ趣味の人同士、同じ出身地の人同士といったマッチングもありますので、ゲストおよびホストの両方が同性である場合もあります。男性および女性で分けるのは単なる例示であることを付け加えます。また、「車両」を「自動車」に、「乗員」を「運転手」に置き換えて説明します。

上記の例示に沿って本発明の概要を説明しますと、本発明のマッチングシステムは、ホスト乗員（男性運転手）が乗車するホスト車両（男性自動車）、および、ゲスト乗員（女性運転手）が乗車するゲスト車両（女性自動車）、を備えます。

本発明のマッチングシステムを利用すると、男性運転手の希望に女性運転手が合致しているか否かを診断するのが男性自動車であるため、男性運転手は、運転操作に集中でき、安全性が確保されます。また、女性運転手は、自分の外見等を見知らぬ男性運転手ではなく自動車に判断されるため、安心感が向上します。その結果、運転手同士が、より安全にかつ安心して出会えます。

発明の詳細

図１は、マッチングシステム１０の構成を表します。マッチングシステム１０は、複数の自動車１２ｈ，１２ｇと、管理サーバ１４と、を有します。

【図１】

一つの自動車は、男性自動車１２ｈとしても、女性自動車１２ｇとしても機能します。男性自動車１２ｈと女性自動車１２ｇとを区別しない場合は、単に「自動車１２」と記載します。また、男性自動車１２ｈの運転手を「男性運転手８０ｈ」と記載し、女性自動車１２ｇの運転手を「女性運転手８０ｇ」と記載します。両者を区別しない場合は、単に「運転手８０」と記載します。

男性自動車１２ｈは、女性自動車１２ｇに、直接的または間接的に招待情報４６を提供します。招待情報４６は、男性運転手８０ｈが女性運転手８０ｇと出会いたいと判断された場合に、男性自動車１２ｈから女性自動車１２ｇに送られます。この招待情報４６には、男性運転手８０ｈの自己紹介、男性運転手８０ｈから女性運転手８０ｇへのメッセージ、または、男性運転手８０ｈの連絡先などが含まれています。

ここに示す例では、招待情報４６を含むユーザ情報４４が管理サーバ１４に記憶されています。このユーザ情報４４へアクセスするためのアクセス情報３６を男性自動車１２ｈは女性自動車１２ｇに提供します。女性自動車１２ｇは、このアクセス情報３６に基づいて、管理サーバ１４にアクセスし、ユーザ情報４４、および招待情報４６を取得します。

図２のブロック図は、自動車１２および管理サーバ１４の構成を示します。図２において、自動車１２の構成要素のうち、破線のブロックは、男性自動車１２ｈとして機能する場合に使用する要素であり、一点鎖線のブロックは、女性自動車１２ｇとして機能する場合に使用する要素であり、実線のブロックは、男性自動車１２ｈおよび女性自動車１２ｇのいずれの場合でも使用する要素です。

【図２】

図２に示すように、自動車１２は、前方カメラ２０、後方カメラ２２、後方ディスプレイ２４、通信装置２６、および、コントローラ２７を備えています。

前方カメラ２０は、自動車１２の前部に設けられ、自動車１２よりも前方を撮影します。後方カメラ２２は、自動車１２の後部に設けられ、自動車１２よりも後方を撮影します。

前方カメラ２０および後方カメラ２２は、マッチング処理のために専用に設けられる場合がありますが、例えば、ドライブレコーダー用のカメラをマッチング処理のために流用する場合もあります。

後方ディスプレイ２４は、後続自動車によって目で確認される情報を映し出すディスプレイです。後方ディスプレイ２４は、例えば、自動車１２のリアウィンドウ（後部窓）の部分に配置されます。

通信装置２６は、自動車１２の外部機器とデータ通信します。具体的には、自動車１２は、通信装置２６を介して、管理サーバ１４、運転手８０の所有するユーザ端末８２（例えばスマートホン等）、および、他の自動車１２とデータ通信します。このデータ通信は、専用の通信回線、または、携帯電話会社が提供する汎用的なモバイルデータ回線を利用して行います。また、通信装置２６は、ユーザ端末８２と通信するために、ブルートゥース（登録商標）等の短距離無線通信を利用する場合もあります。

コントローラ２７は、プロセッサ２８および記憶装置３０を有するコンピュータです。コントローラ２７は、運転手８０の希望を機械学習するＡＩとしても機能します。なお、プロセッサ２８は、例えば汎用的なプロセッサ（例えばＣＰＵ）などです。

記憶装置３０は、マッチング処理のために必要な各種プログラムおよびデータを記憶します。記憶装置３０は、半導体メモリ（例えばＲＡＭ、ＲＯＭ、ソリッドステートドライブ等）および磁気ディスク（例えば、ハードディスクドライブ等）などを有します。

記憶装置３０には、マッチング処理を実行するためのアプリケーションのプログラム（図示せず）が記憶されています。プロセッサ２８は、このプログラムに従って各種演算を実行します。記憶装置３０には、希望傾向情報３２、受取条件３４、アクセス情報３６、簡易紹介情報３８が、あらかじめ記憶されています。

希望傾向情報３２は、男性運転手８０ｈが出会いたい人物の傾向を示す情報であり、例えば、出会いたい人物の属性（性別や年齢範囲、体型、休日の曜日、居住エリア、職業、年収範囲等）が含まれています。希望傾向情報３２には、出会いたい人物の外見について機械学習した結果も含まれています。

上記の構成を有する自動車１２は、男性運転手８０ｈに対して、出会いたい人物の外見に関する様々な質問を行います。この質問に対する男性運転手８０ｈの回答に基づいて、男性運転手８０ｈの出会いたい人物の外見の傾向を取得します。

【図３】

図３は、機械学習時に、運転手８０に提示される希望傾向学習画面４８の一例を示します。機械学習のとき、コントローラ２７は、自動車１２に搭載された表示器（図示せず）に、図３に示したような希望傾向学習画面４８を表示します。希望傾向学習画面４８には、多数の人物の写真が現れます。運転手８０は、希望傾向学習画面４８に表示される多数の人物のうち、出会いたい人物を、複数選択します。選択結果に基づいて、コントローラ２７は、運転手８０が出会いたい人物の外見の傾向を学習し、その学習結果を、希望傾向情報３２として記憶します。

受取条件３４（図２をご参照）は、自車が、女性自動車１２ｇとして機能するときに、男性運転手８０ｈからのどのような招待情報４６を受け取るかを定めた条件です。コントローラ２７は、受取条件３４に合致しない男性運転手８０ｈから提供される招待情報４６については、受け取りを拒否します。

したがって、例えば、受取条件３４として「４０歳以下」が、設定されている場合、４０歳超過の男性運転手８０ｈからの招待情報４６は、受け取りが拒否されます。この受取条件３４は、あらかじめ女性運転手８０ｇにより設定され、記憶装置３０に記憶されています。

アクセス情報３６（図２をご参照）は、自車が男性自動車１２ｈとして機能する際に、女性自動車１２ｇに提供する情報であり、また、管理サーバ１４に記録されたユーザ情報４４に女性自動車１２ｇがアクセスするための情報です。すなわち、管理サーバ１４には、各運転手８０の情報であるユーザ情報４４が記録されています。ユーザ情報４４には、運転手８０の顔画像、属性情報（例えば年齢や体型、職業、休日等）、男性運転手８０ｈから女性運転手８０ｇへのメッセージ等が含まれています。

また、ユーザ情報４４には、招待情報４６も含まれています。運転手８０は、自動車に搭載された装置、または、自身が所有するユーザ端末８２を操作して、自身に関する情報を「ユーザ情報４４」として管理サーバ１４に登録します。

アクセス情報３６は、他の自動車１２（すなわち女性自動車１２ｇ）が、自車の運転手８０（すなわち男性運転手８０ｈ）のユーザ情報４４へアクセスする際に使用されます。アクセス情報３６としては、例えば、ユーザ情報４４にアクセスする際のＵＲＬのテキスト、ＵＲＬを示す二次元バーコード画像等が挙げられます。

簡易紹介情報３８（図２をご参照）は、自車が、男性自動車１２ｈとして機能する際に使用される情報です。簡易紹介情報３８は、男性運転手８０ｈを簡易的に紹介する情報であり、例えば、男性運転手８０ｈの顔画像、基本的な属性情報（例えば、年齢や居住エリアなど）を含んでいます。後に詳説する通り、簡易紹介情報３８は、特定の状況下で女性自動車１２ｇに提供されます。

【図４】

次に、マッチング処理の流れの一例について図４を参照して説明します。マッチング処理では、例えば、先行する自動車が男性自動車１２ｈとして機能し、男性自動車１２ｈの後に続く自動車が女性自動車１２ｇとして機能します。この例は、あくまでもマッチングシステムを利用する人同士の間で行われる処理となります。

男性自動車１２ｈは、図４の上段に示すように後方カメラ２２で、女性自動車１２ｇの運転手（女性運転手８０ｇ）を撮像します。この撮像で得られた画像が女性画像５０となります。したがって、後方カメラ２２は、女性画像５０を取得する女性画像取得部として機能します。

男性自動車１２ｈのコントローラ２７（図２参照）は、女性画像５０と希望傾向情報３２とを照らし合わせます。そして、女性運転手８０ｇが男性運転手８０ｈの希望に合致しているか否かを診断します。したがって、コントローラ２７は、男性側診断部として機能します。

男性運転手８０ｈの希望と女性運転手８０ｇとが合致していると判断した場合、男性自動車１２ｈのコントローラ２７は、図４の下段に示すように、アクセス情報３６を後方ディスプレイ２４に表示させます。図４の例では、アクセス情報３６は、アクセス先ＵＲＬを示す二次元バーコード画像です。アクセス情報３６は、上述した通り、男性運転手８０ｈのユーザ情報４４にアクセスするための情報です。したがって、後方ディスプレイ２４は、男性運転手８０ｈの情報を女性自動車１２ｇに提供する男性情報提供部として機能します。

女性自動車１２ｇは、前方カメラ２０で先行自動車（すなわち男性自動車１２ｈ）を撮影し、前方画像５１として取得します。この前方画像５１にアクセス情報３６が含まれている場合、女性自動車１２ｇのコントローラ２７は、アクセス情報３６に基づき通信装置２６を介して、管理サーバ１４に記録されている男性運転手８０ｈのユーザ情報にアクセスします。したがって、前方カメラ２０、コントローラ２７および通信装置２６は、男性運転手８０ｈのユーザ情報４４を取得する男性情報取得部として機能します。

男性運転手８０ｈのユーザ情報４４が取得できれば、女性自動車１２ｇのコントローラ２７は、女性運転手８０ｇの受取条件３４と男性運転手８０ｈとが合致しているか否かを診断します。したがって、コントローラは、女性側診断部としても機能します。

診断の結果、男性運転手８０ｈが女性運転手８０ｇの受取条件３４を満たさない場合、女性自動車１２ｇは、受け取り拒否のメッセージを男性自動車１２ｈに送信します。受け取り拒否のメッセージは、管理サーバ１４を経由して送信される場合、車－車間通信を利用して直接男性自動車１２ｈに送信される場合があります。

一方、診断の結果、男性運転手８０ｈが女性運転手８０ｇの受取条件３４を満たす場合、女性自動車１２ｇのコントローラ２７は、ユーザ情報４４に含まれている招待情報４６を女性運転手８０ｇに通知します。例えば、女性自動車１２ｇの通信装置２６は、女性運転手８０ｇのユーザ端末８２に、招待情報４６を送信します。この送信は、近距離無線通信、または、電子メールやＳＮＳ等を利用して行われます。ユーザ端末８２は、受信した招待情報４６に含まれている男性運転手８０ｈの自己紹介文、顔画像、連絡先等を表示します。したがって、通信装置２６は、招待情報を女性運転手８０ｇに通知する招待通知部として機能します。

なお、招待情報４６をユーザ端末８２に送信せず、車内に設けられた車載ディスプレイに表示することもできます。この場合、車載ディスプレイが、招待通知部として機能します。いずれの場合であっても、この招待情報４６の女性運転手８０ｇへの通知は、女性運転手８０ｇの運転操作の邪魔にならないタイミング（例えば女性自動車１２ｇが信号で停車しているタイミング等）に行います。女性運転手８０ｇは、通知された招待情報４６をみて、男性運転手８０ｈが気に入れば男性運転手８０ｈに連絡を送ります。

以上の通り、本例では、男性自動車１２ｈが、男性運転手８０ｈが出会いたい人物の傾向を示す希望傾向情報３２をあらかじめ記憶しており、男性運転手８０ｈが女性運転手８０ｇに出会いたいか否かを、男性運転手８０ｈの代わりに男性自動車１２ｈが診断しています。その結果、男性運転手８０ｈは、運転操作中に、女性運転手８０ｇの外見等を注視する必要がなく運転操作に集中できます。その一方で、男性自動車１２ｈ側が自動的に招待情報４６を送るため、男性運転手８０ｈの出会いの機会を多数確保できます。

女性運転手８０ｇの立場に立てば、見知らぬ男性運転手８０ｈに自身の外見を判断されることに抵抗感を感じる人も多いのですが、本例によれば、女性運転手８０ｇの外見が男性運転手８０ｈによって判断されず男性自動車１２ｈによって判断されるため、女性運転手８０ｇが感じる抵抗感を大幅に低減できます。

また、男性運転手８０ｈは、女性運転手８０ｇから連絡が来ない限り、女性運転手８０ｇの情報（例えば女性画像５０、女性運転手８０ｇのユーザ情報４４等）にアクセスできません。女性運転手８０ｇは、男性運転手８０ｈのユーザ情報４４のうち、男性運転手８０ｈが公開することを許容している招待情報４６にしかアクセスできません。その結果、男性運転手８０ｈおよび女性運転手８０ｇの個人情報を適切に保護できます。

一方で、男性自動車１２ｈは、女性画像５０にアクセスでき、女性自動車１２ｇは、男性運転手８０ｈのユーザ情報４４にアクセスできるため、男性運転手８０ｈおよび女性運転手８０ｇの相性を比較的高い精度で推測できます。したがって、男性運転手８０ｈおよび女性運転手８０ｇの個人情報を十分に保護しつつ、両者の相性を適切に判断できます。

上述の説明では、男性自動車１２ｈは、男性運転手８０ｈが女性運転手８０ｇを気に入ったと判断した場合に、後方ディスプレイ２４にアクセス情報３６のみを表示しています。しかし、状況によっては、アクセス情報３６とともに、男性運転手８０ｈを簡易的に紹介する簡易紹介情報３８を表示する場合もあります。

例えば、赤信号等により、男性自動車１２ｈおよび女性自動車１２ｇの両方が停車する場合があります。この場合、女性運転手８０ｇは、運転操作以外の作業を行っても特段問題ありません。そこで、男性自動車１２ｈおよび女性自動車１２ｇの両方が停車している場合、男性自動車１２ｈは、アクセス情報３６とともに簡易紹介情報３８を、後方ディスプレイ２４に表示できます。図５は、後方ディスプレイ２４に、アクセス情報３６と簡易紹介情報３８とを表示した様子です。

【図５】

女性自動車１２ｇは、前方カメラ２０で取得した前方画像５１に簡易紹介情報３８が含まれていると判断した場合、その旨を女性運転手８０ｇに通知します。具体的には、女性自動車１２ｇは、この女性自動車１２ｇの車載ディスプレイに簡易紹介情報３８を表示するとともに、招待情報４６の受け取りの可否を問い合わせます。女性運転手８０ｇは、表示された簡易紹介情報３８に基づいて、男性運転手８０ｈからの招待情報４６の受け取りの可否を判断します。そして、女性運転手８０ｇが招待情報４６の受け取りを許可した場合、女性自動車１２ｇは女性運転手８０ｇに招待情報４６を通知します。

このように、女性自動車１２ｇの停車中に限り、女性運転手８０ｇに簡易紹介情報３８を提供して、女性運転手８０ｇに招待情報４６の受け取りの可否を判断させることができます。これにより、運転操作に悪影響を与えることなく、女性運転手８０ｇの希望にあった出会いを提供できます。

以上のとおり、本例によれば、運転手８０の運転操作に悪影響を与えることなく、運転手８０同士に適切な出会いを提供できます。なお、出会いの機会をより多く確保するために、招待情報４６の送受信の結果を記憶しておき、それを運転手８０に提供することができます。例えば、自動車１２（男性自動車１２ｈ）は、招待情報４６を提供した際の位置、日時、受け取り結果などを提供履歴として記憶装置に記憶します。そして、この提供履歴に基づいて、出会いの確率の高いエリアを運転手に提供します。出会いの確率が高い地名を提示すること、また、図９（ａ）、図９（ｂ）に示すようなヒートマップの形態で提供することができます。

【図９】

図９（ａ）は、招待情報４６の提供頻度のエリアごとの高低をヒートマップ形式で示した提供地域ヒートマップ５２です。提供地域ヒートマップ５２では、地図画像に、エリアごとの招待情報４６の提供頻度を示す色彩が重ねられています。図９（ａ）において、ハッチングの濃度が濃いほど、男性自動車１２ｈとして招待情報４６を提供した頻度が高いことを示しています。

また、男性運転手８０ｈは、ヒートマップの生成条件として、例えば、時間帯、曜日、日付、期間、天気等を指定できます。自動車１２は、指定された生成条件で算出された提供頻度を色彩の濃淡で示したヒートマップを生成します。例えば、生成条件として、「１２時から１５時」の「晴れ」の「過去１か月間」が指定された場合、自動車１２は、招待情報４６の提供履歴のうち過去１か月間の晴れの日の１２時から１５時に提供したデータのみを抽出し、抽出されたデータに基づいて、提供地域ヒートマップ５２を生成して運転手８０に提示します。

ここで、招待情報４６は、男性運転手８０ｈの希望に合致した女性運転手８０ｇに提供されます。したがって、招待情報４６の提供頻度が高いエリアは、男性運転手８０ｈの希望に合致した女性運転手８０ｇに出会える確率が高いエリアといえます。よって、男性運転手８０ｈは、提供地域ヒートマップ５２を参照すると希望の女性運転手８０ｇに出会いやすいエリアを容易に把握できます。そして、男性運転手８０ｈは、出会いの確率が高いエリアを積極的に走行することにより、好みの女性運転手８０ｇとの出会いの確率が向上します。

また、招待情報４６の提供頻度ではなく、招待情報４６が女性運転手８０ｇによって受け取られて出会いが成立したエリアごとの頻度をヒートマップ形式で示すこともできます。

図９（ｂ）は、出会いが成立した頻度のエリアごとの高低を示す成立地域ヒートマップ５４です。この成立地域ヒートマップ５４についても、男性運転手８０ｈは、その生成条件を指定できます。そして、男性運転手８０ｈは、成立地域ヒートマップ５４を参照することで、出会いが成立しやすいエリアを容易に把握できます。男性運転手８０ｈは、出会いが成立する確率が高いエリアを積極的に走行すると出会い成立の確率が向上します。

【図１０】

次に、マッチングシステム１０の他の例について図１０を参照して説明します。図１０のマッチングシステム１０では、男性自動車１２ｈおよび女性自動車１２ｇは、いずれも、不特定多数の運転手が乗り降りするライドシェア自動車です。この場合、男性自動車１２ｈおよび女性自動車１２ｇの目的地は同一です。

男性運転手８０ｈのユーザ端末８２には、この男性運転手８０ｈの希望傾向情報３２、アクセス情報３６が記憶されています。男性運転手８０ｈが男性自動車１２ｈに乗車すると、男性自動車１２ｈは男性運転手８０ｈのユーザ端末８２とデータ通信し、男性運転手８０ｈの希望傾向情報３２、アクセス情報３６を取得します。

続いて、男性自動車１２ｈは、走行中に他のライドシェア自動車を撮影して女性画像５０を取得します。そして、女性画像５０と希望傾向情報３２とに基づいて、男性運転手８０ｈの希望に合う運転手が、他のライドシェア自動車（すなわち女性自動車１２ｇ）に乗車しているかどうかを判断します。乗車していると判断した場合、男性自動車１２ｈは、車－車通信によって女性自動車１２ｇにアクセス情報３６を提供します。

女性自動車１２ｇは、受信したアクセス情報３６に基づいて管理サーバ１４にアクセスし、男性運転手８０ｈのユーザ情報４４を取得します。ユーザ情報４４が得られれば、女性自動車１２ｇは、ユーザ情報４４に含まれる招待情報４６を女性運転手８０ｇのユーザ端末８２に送信します。女性運転手８０ｇは、受信した招待情報４６を参照して、招待の受け取りの可否を判断します。女性自動車１２ｇは、この受け取りの結果を取得して男性自動車１２ｈに送信します。

また、女性運転手８０ｇが招待情報４６を受け取った場合、さらに、女性運転手８０ｇに対して男性運転手８０ｈが隣席することの可否を問い合わせることもできます。女性運転手８０ｇが隣席を許可した場合、男性自動車１２ｈおよび女性自動車１２ｇは、互いに近接した位置で停車します。そして、男性運転手８０ｈは、男性自動車１２ｈを降車して女性自動車１２ｇに乗車して女性運転手８０ｇの隣に座ります。これにより、女性運転手８０ｇと男性運転手８０ｈとが対面してコミュニケーションできます。

ここがポイント！

上記の通り、本発明は、車両の乗員同士が安全にかつ安心して出会えるマッチングシステムを提供します。

本発明のマッチングシステムを要約しますと、ホスト車両（例えば男性自動車）およびゲスト車両（例えば女性自動車）で構成されています。ホスト車両をホスト乗員（例えば男性運転手）が運転し、ゲスト車両をゲスト乗員（例えば女性運転手）が運転します。なお、上述した通り、ホストが女性でゲストが男性であってもよく、ゲストおよびホストの両方が男性または女性であってもよく、自分と同じ趣味を有する人を探す人がホストである場合もあります。以下、ホストが男性でゲストが女性である場合を挙げて簡単に説明します。

ホスト車両（男性自動車）は、以下の構成を備えます。

• 記憶装置：半導体メモリやプログラムなど（男性運転手が出会いたい人物の傾向を示す希望傾向情報を記憶する）
• 女性画像取得部：後方カメラなど（女性運転手を撮像した女性画像を取得する）
• 男性側診断部：コントローラなど（女性画像と希望傾向情報とに基づいて、女性運転手が男性運転手の希望に合致しているか否かを診断する）
• 男性情報提供部：後方ディスプレイなど（男性運転手の希望に女性運転手が合致していると診断した場合、男性運転手の情報である男性情報を女性自動車に提供する）

一方、ゲスト車両（女性自動車）は、以下の構成を備えます。

• 記憶装置：半導体メモリやプログラムなど（女性運転手が、男性運転手からの招待を受け取る条件を示す受取条件を記憶する）
• 男性情報取得部：前方カメラ、コントローラ、および通信装置など（女性自動車から提供される男性情報を取得する）
• 女性側診断部：コントローラなど（男性情報が受取条件に合致しているか否かを診断する）
• 招待通知部：通信装置や車載ディスプレイなど（男性情報が受取条件に合致していると診断した場合、男性情報に含まれる招待情報を女性運転手に通知する）

未来予想

本特許は、トヨタ自動車株式会社から出願されたものです。日本だけでなく世界でも有名な自動車製造メーカーです。ところが、世界的自動車メーカーであっても将来的な業績は必ずしも順風満帆ではありません。特に日本では若い人の自動車離れが進んでいるといわれています。将来的に人口が減少することを予想すると、自動車の国内販売数は減っていくと予想されます。

しかし、運転しながら希望する人に出会えるチャンスがあるのであれば、自動車に乗りたいと思う人を増やすことが可能です。

本特許発明の発明は、自動車離れを防ぐために考え出されたアイデアであると思われます。本特許発明の技術が実現されるかどうか予測できませんが、性能やデザインが良いという理由で選んでいた自動車に続く、次世代の自動車をユーザーに楽しんでもらいたいという熱意が本特許発明を生んだと思われます。

特許の概要

最近の婚活は、マッチングアプリから始まるケースが多いそうです。昔は婚活といえば、仲介人の方がお見合い写真を片手に適齢期の男女の間をとりもったり（いつの時代だ）、婚活サービスに登録して大都市圏で開催される「ねるとんパーティ」に参加したり（ねるとんパーティがわからない方はぜひググってください）、やはり人と人とを結びつけるには直接会うことが必要なわけですが、この「直接会う」までのプロセスが昔と今とでは大きく異なるようですね。

ネットを介して恋人を見つける、いわゆるマッチングサービスは、現在多数提供されていますが、今回紹介する特許は、マッチングサービスに関して今までにない、オークション的な形式で相手を「落札」するというものです。いったいどのようなサービスなのでしょうか。今回はこの特許発明の詳細について、解説していきます。

発明の背景

従来、インターネット等のネットワークを活用したシステムにより、恋愛対象者同士のコミュニケーションやマッチングを支援する種々の技術が提案されています。

例えば、お互いが電話等の直接のコミュニケーションを取ることなく、お互いの気持ちを相手に伝え、知りたいときに相手の気持ちを知ることができる新しい恋愛チェッカーシステム（特開2014-063407）などが知られています。

しかし、上記先行技術に開示されたものは、デートプランを媒介として恋愛対象者同士をマッチングするものではありませんでした。

どんな発明？

発明の目的

本発明は、デートプランを媒介として、恋愛対象者同士をマッチングするサーバ装置です。デートプランを含む入札を受け付け、当該デートプランを入札対象者に提示し、入札対象者の選択に基づいて落札者を決定します。また、デートプランに替えてプレゼントの提供を入札対象者に提示してもよく、電子決済を行う機能を更に備えてもよいものとされます。

発明の詳細

では、図・画像を一部参照しながら、本発明の詳細を説明していきます。これ以降、発明の理解のために、入札者を男性、入札対象者を女性として考えていきます。もちろん逆になる実施態様もあることを予めご了承ください。

【図１】

図１には、本発明の実施形態に係る情報処理システムの構成が例示されます。サーバ装置１と、入札者（男性）の端末２、入札対象者（女性）の端末３はインターネット等の通信網４を通じて接続されています。これはごく一般的なネットワークの模式図です。

【図２】

図２には、サーバ装置１の構成が開示されています。

サーバ装置１は、全体の制御を司る制御部１１，通信部１２、記憶部１３を含みます。記憶部は例えばRAMやフラッシュメモリで構成されますが、記憶部13の中にユーザ情報記憶部14、入札情報記憶部15、デートプラン記憶部16を有します。

ユーザ情報記憶部14には、ユーザIDと、ニックネーム、年齢、電話番号、及びe-mailアドレス等の属性情報、並びに入札ID等が紐付けられています。

入札情報記憶部15には、入札IDと、入札者のユーザID、入札対象者のユーザID、デートプラン情報、プレゼント情報等が紐付けられて記憶されます。

デートプラン記憶部16には、デートプランIDと、デートプランの詳細情報（例えば、時間帯、場所、イベント等）等が紐付けられて記憶されます。

受付部１１ａは、デートプランやプレゼントを含む入札を受け付けます。入札処理部１１ｂは、入札に係るデートプランやプレゼントを含む入札情報を入札対象者に提示すべく表示データを生成又は更新します。決定部１１ｃは、入札対象者の選択に基づいて落札者を決定します。評価部１１ｄは、この決定部１１ｃの決定を受けてデートプランを評価します。送信部１１ｅは、デートプランやプレゼントの情報を含む入札情報に係る表示データ等を端末装置２，３に送信し、決済部１１ｆは、決定部１１ｃによる決定を受けて電子決済を行います。

次に、フローチャートを参照して、本発明の情報処理システムの入札に係る一連の処理手順を説明します。

【図４】

入札者（男性）は端末装置２によりサーバ装置１の提供するＷｅｂサイトにアクセスし、Ｗｅｂページを閲覧します（Ｓ１）。端末装置２では、サーバ装置１から送信されるＨＴＭＬ形式等の表示データを受信し、端末にＷｅｂページの表示をすることになります。

【図５】

具体的には、図５に示されるような画面を見ながら、入札対象者（女性）の選定を行います。つまり、誰にデートプランを提示しようか、と選定するわけですね。この画面で「詳細を見る」のボタン100ｄを押すと、図６のような詳細情報画面に推移します。

【図６】

詳細情報の画面には、入札対象者（女性）に係る情報が表示され、既に入札されているデートプランの入札者、デート応募額、デートプラン詳細が表示されます。この画面において、「デートを申し込もう！」のボタン１０１ｃが選択されると、申し込み対象が特定されます（図４のＳ２）。そして図７のような画面が表示されます。

【図７】

この画面では、例えばゲージ１０２ａを動かすことでデートの応募額を設定できるようになっており、支払い方法も種々の決済手段が選べるようになっています（図８）。

【図８】

図７の画面において「希望プレゼントを表示」のボタン１０２ｃを押すと、入札対象者（女性）の欲しがっているプレゼントの一覧を確認し、選択できるようになっています（図9）。

【図９】

デートプラン自体も、いくつかのテンプレートから選択することができ（図１０）、プレゼントやデートプランが選択されると、入札に係る指示をサーバ装置１に送信することとなります（S3）

【図１０】

以上のようにして、入札者（男性）の端末装置２から入札に係る指示をサーバ装置１に送信されることで、一連の入札処理が終了します。

【図１１】

次に、図１１のフローチャートによって、「落札」の処理手順を説明していきます。

入札対象者（女性）は、端末装置３でサーバ装置１の提供するWebサイトにアクセスします（S11）。このサイトでは、入札されたデートプラン一覧を確認することができます。入札対象者（女性）の端末装置３によって、提示されたデートプランの中から承諾するデートプランが選択されると、その決定通知がサーバ装置１に送信されます（S13)。

このようにして入札から落札の処理がなされ、落札決定に基づいて、落札者の評価を行い、評価内容を更新します（S15）。例えば、１回落札するたびに、ユーザに対して所定のポイントを付与する等のルールに基づいて、ユーザの評価ポイントの更新を行います。

その後、落札通知を入札者（男性）の端末装置２に送信し（S17）、決済指示がされると電子決済が行われます（S18、S19）。こうして、落札決定から決済までの一連の処理が終了します。

なお、ユーザごとに、１回落札するたびに、ユーザに対して所定のポイントを付与する等のルールに基づいて、ユーザの評価ポイントの更新を行っているので、評価ポイントの高い順にユーザ（入札者側）をランキングして提示することも可能です。また、入札の数やその成立率等も評価可能であり、その場合には、入札数の多いユーザ（男性側）、或いは成立率の高いユーザ（女性側）をランキングして提示することも可能です。

最後に、入札者（男性）を示す画面の表示例は、図１２に示すとおりです。このような画面が、入札対象者（女性）側からは閲覧可能ということになります。

【図１２】

ここがポイント！

本発明は、デートプランを作成又は選択し、当該デートプランを伴う入札を行うことができ、入札対象者（女性）は、当該デートプランに基づいて落札の可否を判断できるので、デートプランを媒介とした恋愛のマッチングを促進することができます。

さらに、落札数等に基づいて、ユーザを評価することができるので、落札数に基づくユーザのランキング等を可能となり、入札対象者（女性）は、入札者のランキングや過去の実績、評価に基づいて安心して落札決定を行うことができます。また、入札対象者（女性）についても、デートプランを伴う入札の入札数（申し込み数）や、その成立率等の情報に基づくランキングや情報提示も可能となり、入札者（男性）が入札に際して参考とすることが可能となります。

未来予想

いわゆる「マッチングサービス」の歴史はとても古く、かつては雑誌の「文通相手募集欄」などで文通相手を探したり（今思えばなんとプラトニックな話でしょうか）、恋愛に限定しなければ、バンドのメンバー募集掲示板などもよく知られたところです。

本発明は、マッチングサービスを、いわゆるネットオークションのシステムと掛け合わせたところに新しさがあるように思えます。相手を商品のように扱うところはちょっと道徳的にどうかというところはありますが、人口が少なくなっていく時代にあって、こうした「出会い」の手法も、ネット世代には手軽でよいのかもしれませんね。

特許の概要