JP2020008940A - 情報処理装置および情報処理方法 - Google Patents

Abstract

【課題】同乗者を探す手間を軽減し、車両の相乗りを促進する。【解決手段】情報処理装置は、第１チケット購入者からイベントのチケットの購入を受け付けるとともに、イベントの開催場所まで車両で移動する場合に、相乗りの利用形態に関する情報の登録を受け付けることと、イベントまたはイベントと開催場所および開催期間の一部が共通する類似イベントのチケットを購入したチケット購入者の中から、第１チケット購入者の相乗りの利用形態に適合する第２チケット購入者を相乗り候補者として選択することと、第１チケット購入者に対し、第２チケット購入者を提示することと、を実行する制御部を備える。【選択図】図６

Description

本発明は、相乗りのマッチングを支援するための情報処理装置および情報処理方法に関する。

近年、同一の車両に複数のユーザが相乗り（ライドシェア）をする移動形態が広がっている。これに対し、特許文献１では、航空便の予約を行った顧客のうち到着地から最終目的地までタクシーを利用する顧客に相乗りタクシーを配車する技術が提案されている。また、特許文献２では、顧客と基本属性、購買行動、或いは地理条件の合致度が高い相乗り者が選出され、抵抗感の少ない相乗り者を検索する技術が提案されている。

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

イベント等に参加するため、開催地まで相乗りをして移動することを希望している場合でも、同乗者を探すのに手間がかかるという問題があった。そこで、本発明は、同乗者を探す手間を軽減し、車両の相乗りを促進することを目的とする。

本発明の第１の態様に係る情報処理装置は、
第１チケット購入者からイベントのチケットの購入を受け付けるとともに、前記イベントの開催場所まで車両で移動する場合に、相乗りの利用形態に関する情報の登録を受け付けることと、
前記イベントまたは前記イベントと開催場所および開催期間の一部が共通する類似イベントのチケットを購入したチケット購入者の中から、前記第１チケット購入者の相乗りの利用形態に適合する第２チケット購入者を相乗り候補者として選択することと、
前記第１チケット購入者に対し、前記第２チケット購入者を提示することと、
を実行する制御部を備える。

本発明の第２の態様に係る情報処理方法は、
コンピュータが、
第１チケット購入者からイベントのチケットの購入を受け付けるとともに、前記イベントの開催場所まで車両で移動する場合に、相乗りの利用形態に関する情報の登録を受け付けることと、
前記イベントまたは前記イベントと開催場所および開催期間の一部が共通する類似イベントのチケットを購入したチケット購入者の中から、前記第１チケット購入者の相乗りの利用形態に適合する第２チケット購入者を相乗り候補者として選択することと、
前記チケット購入者に対し、前記第２チケット購入者を提示することと、
を実行する、情報処理方法である。

本発明の第３の態様は、上記の第２の態様に係る情報処理方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体である。

本発明によれば、同乗者を探す手間を軽減し、車両の相乗りを促進することができる。

サーバおよび端末の概略構成を示す図である。 サーバの機能構成を示す図である。 イベント情報テーブルを例示する図である。 第１実施形態に係る購入者情報テーブルを例示する図である。 第１実施形態に係る相乗り情報テーブルを例示する図である。 第１実施形態に係るチケット購入時のマッチング処理の流れを例示するフローチャートである。 変形例１に係る相乗り候補者絞込処理の流れを例示するフローチャートである。 変形例２に係る相乗り候補者絞込処理の流れを例示するフローチャートである。 第２実施形態に係る購入者情報テーブルを例示する図である。 第２実施形態に係る相乗り情報テーブルを例示する図である。 第２実施形態に係るチケット購入時のマッチング処理の流れを例示するフローチャートである。

本発明の第１の態様に係る情報処理装置は、チケット購入者からイベントのチケットの購入を受け付けるとともに、イベントの開催場所まで車両で移動する場合に、相乗りの利用形態に関する情報の登録を受け付ける。コンサート、スポーツ、フェス等のイベントのチケット購入者は、イベントの開催場所までの移動手段として車両を使用する場合がある。車両で移動する場合、チケット購入者は、複数人が１つの車両に同乗する相乗りを希望することが考えられる。相乗りの利用形態に関する情報は、チケット購入者に提示する相乗り候補者を選択するために使用される情報であり、チケット購入者が相乗りを希望するか否かの情報を含む。具体的には、相乗りの利用形態に関する情報は、チケット購入者が、自身の提供する車両に他のチケット購入者の同乗を受け入れることを希望するか、または他のチケット購入者の提供する車両に同乗することを希望するかについての情報を含むことができる。また、相乗りの利用形態に関する情報は、車両を提供可能か否か、運転が可能か否かについての情報を含んでもよい。

上記の情報処理装置は、イベントまたはイベントと開催場所および開催期間の一部が共通する類似イベントのチケットを購入した他のチケット購入者の中から、チケット購入者の相乗りの利用形態に適合する相乗り候補者を選択する。チケット購入者（「第１チケット購入者」に相当）は、イベントのチケットを購入するとともに、相乗りの利用形態に関する情報を登録する者である。相乗り候補者（「第２チケット購入者」に相当）は、既にチケットを購入済みであって、相乗りを希望する他のチケット購入者の中から、当該チケット購入者と相乗りをする候補者として選択される者である。相乗り候補者は、チケットを購入したときに、相乗りの利用形態に関する情報も登録したものとする。チケット購入者の相乗りの利用形態に適合する相乗り候補者は、例えば、チケット購入者が相乗りさせてもらうことを希望する場合には、同乗者を受け入れることを希望する他のチケット購入者の中から選択され、チケット購入者が相乗りを受け入れることを希望する場合には、相乗りさせてもらうことを希望する他のチケット購入者の中から選択される。また、チケット購入者の相乗りの利用形態に適合する相乗り候補者は、車両を提供可能か否か、運転が可能か否かに基づいて選択されてもよい。

異なるイベントであっても、開催場所および開催期間の一部が共通する場合、異なるイベントのチケット購入者間で、相乗りをして移動することが考えられる。このため、イベントと開催場所および開催期間の一部が共通する類似イベントのチケット購入者を、相乗りの対象となる候補者に含めることができる。これにより、情報処理装置は、チケット購入者に対し、相乗り候補者として幅広い選択肢を提供できる。

また、上記の情報処理装置は、チケット購入者に対し、選択された相乗り候補者を提示する。情報処理装置は、チケット購入者に対し、相乗り候補者を複数提示してもよい。情報処理装置は、相乗り候補者の連絡先を通知したり、相乗りの仲介サービスを提供する所定のアプリケーションに誘導したりすることで、チケット購入者に対して相乗り候補者を提示することができる。

つまり、本発明の第１の態様に係る情報処理装置であれば、イベント等のチケット購入者は、同乗者を探す手間を軽減することができ、車両の相乗りを促進することができる。

以下、本発明の具体的な実施形態について図面に基づいて説明する。以下に示す実施形態は、単なる例示であり、本開示の技術的範囲を以下の態様に限定するものではない。

＜第１実施形態＞
本発明の第１実施形態は、イベント等のチケットを販売する場合に、チケット購入者の端末を介して、相乗りの利用形態に関する情報を収集し、購入者間のマッチングを提案する情報処理装置である。マッチングは、相乗りの希望有無、車両の提供可否および運転可否等の相乗りの利用形態に応じて、相乗りの仲介をすることである。

［構成］
（ハードウェア構成）
図１は、サーバおよび端末の概略構成を示す図である。第１実施形態に係るサーバ１は、イベント等のチケット販売者によって設置され、チケット販売等のサービスを提供するためのコンピュータである。サーバ１は、一般的なコンピュータの構成を有し、ネットワークＮを介して端末２に接続される。サーバ１は、ＣＰＵ（Central Processing Unit）
１１、ＲＡＭ（Random Access Memory）１２、記憶装置１３、通信インタフェース(I/F)
１４を備える。サーバ１は、「情報処理装置」の一例である。ＣＰＵ１１は、「制御部」の一例である。

ＣＰＵ１１は、中央演算処理装置であり、ＲＡＭ１２等に展開された各種プログラムの命令及びデータを処理することで、ＲＡＭ１２、記憶装置１３等を制御する。なお、サーバ１は、ＣＰＵ１１等の汎用プロセッサの代わりに、専用プロセッサや専用回路等により実現されてもよい。

ＲＡＭ１２は、主記憶装置であり、ＣＰＵ１１によって制御され、各種命令やデータが書き込まれ、読み出される。記憶装置１３は、不揮発性の記憶装置であり、ＲＡＭ１２にロードされる各種プログラム等、永続性が求められる情報が書き込まれ、読み出される。記憶装置１３は、例えば、ＥＥＰＲＯＭ(Electrically Erasable Programmable Read-Only Memory)、ＨＤＤ(Hard Disk Drive)等である。通信インタフェース１４は、ゲートウェイ等を介して世界規模の公衆パケット通信網であるインターネット、その他の通信網に接続するためのインタフェースである。

端末２は、チケット購入者または相乗り候補者となり得る他のチケット購入者が、チケットを購入したり、相乗りの利用形態に関する情報を入力したりするための端末である。端末２は、１台に限られず、複数台がネットワークＮを介してサーバ１に接続されてもよ
い。端末２は、例えば、スマートフォン、携帯電話、タブレット端末、個人情報端末、ウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。また、端末２は、ネットワークＮを介してサーバ１に接続される、パーソナルコンピュータ（Personal Computer、PC）、コンビニエンスストア等に設置されるキオスク端末であっ
てもよい。

端末２は、ＣＰＵ２１、ＲＡＭ２２、記憶装置２３、通信インタフェース(I/F)２４、
入力装置２５を備える。ＣＰＵ２１、ＲＡＭ２２、記憶装置２３、通信インタフェース２４は、サーバ１のＣＰＵ１１、ＲＡＭ１２、記憶装置１３、通信インタフェース１４と同様であるため説明を省略する。入力装置２５は、例えば、タッチパッド、マウス、タッチパネル等のポインティングデバイス、キーボード、操作ボタン等であり、操作入力を受け付ける。更に、入力装置２５は、映像や画像の入力を可能にするカメラを含む。また、入力装置２５は、マイクロフォンのような音声の入力部を含むことができる。入力装置２５は、チケットを購入しようとする者から、購入者情報の入力およびチケット購入等の操作を受け付ける。購入者情報のうち、年齢または性別等の情報は、カメラ等の撮像装置による購入者の撮影画像を解析することにより取得されてもよい。

ネットワークＮは、例えば、インターネット等の世界規模の公衆パケット通信網であり、サーバ１と端末２とを相互に接続する。なお、ネットワークＮは、インターネットの代わりに、ＷＡＮ（Wide Area Network）やその他の通信網が採用されてもよい。

（機能構成）
図２は、サーバの機能構成を示す図である。サーバ１は、例えば、チケットの販売業者によって設置され、チケット販売サイトを提供するコンピュータが例示される。サーバ１は、機能構成要素として、受付部１０１、選択部１０２、提示部１０３、相乗り受付部１０４、チケット販売データベース（DB）１１０、相乗り情報データベース（DB）１１１を備える。サーバ１のＣＰＵ１１は、ＲＡＭ１２上のコンピュータプログラムにより、受付部１０１、選択部１０２、提示部１０３、相乗り受付部１０４の処理を実行する。ただし、各機能構成素のいずれか、またはその処理の一部がハードウェア回路により実行されてもよい。

チケット販売データベース１１０および相乗り情報データベース１１１は、ＣＰＵ１１によって実行されるデータベース管理システム（Database Management System、DBMS）のプログラムが、記憶装置１３に記憶されるデータを管理することで構築される。チケット販売データベース１１０および相乗り情報データベース１１１は、例えば、リレーショナルデータベースである。

受付部１０１は、チケット購入者の端末２を介して、イベントのチケットの購入を受け付ける。また、受付部１０１は、チケット購入者が、イベントの開催場所まで、車両の相乗りを希望するか、車両の提供が可能か、運転が可能か等の相乗りの利用形態に関する情報の登録を受け付ける。

受付部１０１は、チケット購入者が相乗りを希望する場合に、車両に乗車する出発地の情報を取得してもよい。受付部１０１は、チケット購入者が、チケットを購入する場合に、端末２に入力した情報から出発地の情報を取得することができる。また、受付部１０１は、チケットを購入するために事前に登録されたチケット購入者の住所を、出発地の情報として取得してもよい。

選択部１０２は、イベントのチケットを購入したチケット購入者が相乗りを希望する場合に、相乗り候補者を選択する。選択部１０２は、チケット購入者がチケットを購入した
イベントまたはその類似イベントの他のチケット購入者の中から、相乗り候補者を選択する。

選択部１０２は、受付部１０１がチケット購入者の出発地の情報を取得した場合、チケット購入者の出発地と相乗り候補者の出発地との距離が、所定の閾値以下となるように、相乗り候補者選択することができる。出発地間の距離に関する所定の閾値は、例えば、車によって１５〜３０分程度で移動可能な距離を想定し、１０〜２０ｋｍの範囲内で定めることができる。

また、選択部１０２は、チケット購入者の出発地からイベントの開催場所までの第１経路と、相乗り候補者の出発地からイベントの開催場所までの第２経路との重複度が、所定の閾値以上となるように、相乗り候補者を選択してもよい。選択部１０２は、例えば、チケット購入者の出発地が第２経路上にある場合、または相乗り候補者の出発地が第１経路上にある場合に、第１経路と第２経路の重複度が所定の閾値以上となるように、相乗り候補者を選択すればよい。重複度は、例えば、第１経路において第２経路と重複する距離の割合とすることができる。重複度に関する所定の閾値は、例えば、６０％以上の範囲内で定めることができる。

提示部１０３は、チケット購入者に対し、選択部１０２によって選択された相乗り候補者を提示する。提示部１０３は、チケット購入者の端末２に相乗り候補者の情報を電子メール等で送信したり、相乗りの仲介サービスを提供するアプリケーション等を介して相乗り候補者の情報をチケット購入者に提示したりすることができる。

相乗り受付部１０４は、チケット購入者から、相乗り候補者に対する相乗りの申込みを受け付ける。相乗り受付部１０４は、申込みの対象となった対象候補者の端末２に、申込みの内容を送信する。申込みの内容は、例えば、チケット購入者の氏名、連絡先、出発地等の情報を含む。

チケット販売データベース１１０は、チケット販売に関する情報を格納するデータベースである。チケット販売データベース１１０は、イベント情報テーブル及び購入者情報テーブルを有する。図３および図４により、イベント情報テーブル及び購入者情報テーブルのデータ構造を説明する。なお、イベント情報テーブル及び購入者情報テーブルに格納される情報は、図３および図４に示す例に限られず、適宜フィールドの追加、変更、削除が可能である。

図３は、イベント情報テーブルを例示する図である。イベント情報テーブルは、チケット販売対象のイベントを管理するためのテーブルである。イベント情報テーブルは、イベントＩＤ、開催場所、開催日、開始時刻、終了時刻のフィールドを有する。イベントＩＤは、イベントを識別するＩＤであり、チケットの販売者等によって付与される。イベントＩＤは、例えば、選択部１０２が相乗り候補者を選択する際、同じイベントのチケット購入者を抽出するために使用される。

開催場所は、イベントの開催場所であり、例えば、住所または郵便番号等により指定することができる。開催場所は、選択部１０２により、チケット購入者がチケットを購入したイベントと開催場所の一部が共通する類似イベントを取得するために使用される。開催場所の一部が共通する類似イベントは、例えば、チケット購入者がチケットを購入したイベントと開催場所の住所の市区町村までが同一であるイベント、郵便番号が同一であるイベント等とすることができる。また、開催場所は、相乗りの目的地として、チケット購入者または相乗り候補者の出発地からの経路を取得するために使用される。

開催日は、イベントの開催される日である。複数日開催されるイベントは、開催日ごとに１レコードが登録されればよい。開始時刻および終了時刻は、イベントの開始時刻および終了時刻である。開催日、開始時刻および終了時刻は、選択部１０２により、チケット購入者がチケットを購入したイベントと開催期間の一部が共通する類似イベントを取得するために使用される。

開始時刻および終了時刻は、イベントの開始時刻および終了時刻である。開始時刻および終了時刻は、選択部１０２により、チケット購入者がチケットを購入したイベントの類似イベントを取得するために使用される。

図３の例では、イベントＩＤが「Ｅ０４」のイベント（以下、イベントＥ０４のように記載する）は、開催日が２０１８／Ｘ２／Ｙ２、開始時刻が１０：００、終了時刻が１８：００であり、イベントＥ０２と同じである。また、イベントＥ０４の開催場所は、ＢＢＢＣであり、イベントＥ０２の開催場所ＢＢＢに近接する。この場合、選択部１０２は、イベントＥ０４をイベントＥ０２の類似イベントとして取得することができる。一方、イベントＥ０５は、開催日がイベントＥ０２と同じであり、開催場所がＢＢＢＤであってイベントＥ０２の開催場所ＢＢＢに近接する。しかし、イベントＥ０５の開始時刻および終了時刻は、それぞれ１９：００および２１：００であり、イベントＥ０２の開始時刻および終了時刻とは異なる。この場合、選択部１０２は、イベントＥ０５をイベントＥ０２の類似イベントに含めないようにすることができる。このように、選択部１０２は、予め定められた条件を満たすイベントを、類似イベントとして特定することができる。

図４は、第１実施形態に係る購入者情報テーブルを例示する図である。購入者情報テーブルは、チケットを販売する場合に、購入者から取得した購入者情報を管理するためのテーブルである。購入者情報テーブルは、例えば、チケット販売のサービスを提供するサイトにおいて、ユーザ登録手続として端末２に入力された購入者の情報を格納することができる。購入者情報テーブルは、購入者ＩＤ、氏名、住所、連絡先のフィールドを有する。購入者ＩＤは、購入者を識別するＩＤであり、例えば、チケットの販売サイトでのユーザ登録手続において付与されるＩＤとすることができる。

氏名は、購入者の氏名であり、提示部１０３によって、相乗り候補者の氏名として、チケット購入者に提示される。住所は、購入者の住所であり、相乗りの出発地として使用されてもよい。連絡先は、購入者の連絡先であり、電話番号またはメールアドレス等の連絡先を格納する。連絡先は、提示部１０３により、相乗り候補者の氏名とともにチケット購入者に提示されてもよい。チケット購入者は、提示された相乗り候補者の情報を使用して、相乗り候補者に対して相乗りの申し出、出発地および出発時刻の調整等をすることができる。

相乗り情報データベース１１１は、相乗りのマッチングに使用される情報を格納するデータベースである。相乗り情報データベース１１１は、相乗り情報テーブルを有する。図５により、相乗り情報テーブルのデータ構造を説明する。なお、相乗り情報テーブルに格納される情報は、図５に示す例に限られず、適宜フィールドの追加、変更、削除が可能である。

図５は、第１実施形態に係る相乗り情報テーブルを例示する図である。相乗り情報テーブルは、購入者の相乗りに関する情報を管理するためのテーブルである。相乗り情報テーブルには、チケットが購入された場合に、購入者とイベントとを対応づける１レコードが挿入される。相乗り情報テーブルは、購入者ＩＤ、イベントＩＤ、相乗り利用形態、出発地、目的地のフィールドを有する。

購入者ＩＤは、図４に示す購入者情報テーブルの購入者ＩＤであり、イベントのチケットを購入したチケット購入者の購入者ＩＤを格納する。イベントＩＤは、図３に示すイベント情報テーブルのイベントＩＤであり、チケット購入者がチケットを購入したイベントのイベントＩＤを格納する。

相乗り利用形態は、チケット購入者と相乗り候補者とをマッチングするために使用される情報を格納する。図５の例では、相乗り利用形態は、チケット購入者が相乗りを希望するか否か、車両の提供可否、運転可否の情報を格納する。なお、相乗り利用形態は、チケット購入者と相乗り候補者とをマッチングすることができる情報であればよく、図５の例に限られない。相乗り利用形態は、チケット購入者が、自身の提供する車両に他のチケット購入者の同乗を受け入れることを希望するか、または他のチケット購入者の提供する車両に同乗することを希望するかについての情報を格納するようにしてもよい。

出発地は、チケット購入者が相乗りを希望する場合の出発地である。受付部１０１は、チケット購入者がチケットを購入したときに端末２に入力した出発地の情報を利用形態に関する情報として受信し、相乗り情報テーブルの出発地フィールドに格納してもよい。また、受付部１０１は、チケット購入者がチケットを購入したときに、購入者情報テーブルからチケット購入者の住所を出発地として取得し、相乗り情報テーブルの出発地フィールドに格納してもよい。さらに、購入者が端末２に対して、出発地または住所の情報を入力しなかった場合、受付部１０１は、端末２の位置情報を出発地として取得してもよい。端末２がキオスク端末である場合には、受付部１０１は、出発地をキオスク端末が設置されている住所とすることも可能である。

目的地は、チケット購入者が相乗りを希望する場合の目的地である。受付部１０１は、チケット購入者がチケットを購入したときに端末２に入力した目的地の情報を受信して、相乗り情報テーブルの目的地フィールドに格納してもよい。また、受付部１０１は、チケット購入者がチケットを購入したときに、イベント情報テーブルからイベントの開催場所を目的地として取得し、相乗り情報テーブルの目的地フィールドに格納してもよい。

［処理の流れ］
図６から図８により、チケット購入者と、相乗り候補者とのマッチング処理の流れについて説明する。第１実施形態に係るマッチング処理は、同じイベントまたは類似イベントのチケット購入者の中から、相乗りの希望有無に基づいて相乗り候補者を選択し、チケット購入者に提示する。また、第１実施形態に係るマッチング処理は、チケット購入者の出発地と相乗り候補者の出発地とに基づいて、相乗り候補者をチケット購入者に提示する。

図６は、第１実施形態に係るチケット購入時のマッチング処理の流れを例示するフローチャートである。図６に例示するマッチング処理は、サーバ１が、チケット購入者からチケットの購入および相乗りの利用形態に関する情報の登録を受け付け、相乗り候補者を選択してチケット購入者に提示する処理を含む。また、図６に例示するマッチング処理は、チケット購入者が相乗り候補者に相乗りを申込む処理を含む。マッチング処理は、例えば、チケット購入者がチケットを購入したことを契機に開始される。

Ｓ１１では、受付部１０１は、チケット購入者が端末２に入力した購入者情報を、通信インタフェース１４を介して取得する。購入者情報は、例えば、購入者の氏名、住所、連絡先等の情報を含む。受付部１０１は、取得した購入者情報を、購入者情報テーブルに格納する。

Ｓ１２では、受付部１０１は、端末２から、イベントのチケットの購入を受け付けるとともに、チケット購入者の相乗りの利用形態に関する情報を取得する。チケット購入者の
利用形態に関する情報は、端末２において、チケット購入者によって入力される。受付部１０１は、チケット購入者とチケットが購入されたイベントとを対応付け、相乗りの利用形態についての情報を、相乗り情報テーブルに格納する。

Ｓ１３では、選択部１０２は、チケット購入者が相乗りを希望するか否かを判定する。選択部１０２は、相乗り情報テーブルにおいて相乗り利用形態フィールドで「相乗り希望：有」の場合に、チケット購入者が相乗りを希望すると判定することができる。また、選択部１０２は、相乗り利用形態フィールドで「相乗り希望：無」の場合に、チケット購入者が相乗りを希望しないと判定することができる。チケット購入者が相乗りを希望する場合（Ｓ１３：Ｙｅｓ）、処理はＳ１４に進む。チケット購入者が相乗りを希望しない場合（Ｓ１３：Ｎｏ）、チケット購入者に対するマッチングは実行されず、図６に示す処理は終了する。

Ｓ１４では、選択部１０２は、チケット購入者の利用形態に適合する相乗り候補者を選択する。選択部１０２は、相乗り情報テーブルを参照し、チケット購入者がチケットを購入したイベントと対応付けられた購入者を抽出する。なお、選択部１０２は、当該イベントの類似イベントと対応づけられた購入者を含めて抽出してもよい。そして、選択部１０２は、抽出した購入者の中から、チケット購入者の利用形態に適合する相乗り候補者を選択する。具体的には、選択部１０２は、チケット購入者が相乗りを希望する場合、抽出した購入者の中から、相乗りを希望する購入者を相乗り候補者として選択する。さらに、選択部１０２は、例えば、チケット購入者が車両を提供可能でない場合には、車両を提供可能な相乗り候補者を選択すればよい。また、選択部１０２は、チケット購入者が運転可能でない場合には、運転可能な相乗り候補者を選択すればよい。

ここで、図５の例において、購入者ＩＤが「Ｕ００２」の購入者（以下、購入者Ｕ００２のように記載）に対し、相乗り候補者を選択する具体例について説明する。購入者Ｕ００２は、イベントＥ０２のチケットを購入している。このため、選択部１０２は、相乗り情報テーブルから、イベントＥ０２または類似イベント（図５において、イベントＥ０４とする）に対応付けられた購入者Ｕ００４および購入者Ｕ００５を抽出する。購入者Ｕ００２の利用形態は、相乗りを希望、車両提供可、運転可である。したがって、購入者Ｕ００２の利用形態に適合する相乗り候補者として、類似イベントＥ０４のチケットを購入し、相乗りを希望する購入者Ｕ００５が選択される。このように、選択部１０２は、チケット購入者の利用形態に応じて、チケット購入者の利用形態に適合する相乗り候補者を選択することができる。

図５の例は、車両を提供可能か否か、運転が可能か否かの利用形態に適合する相乗り候補者を選択する例を示すが、これに限られない。チケット購入者の相乗りの利用形態に適合する相乗り候補者は、例えば、チケット購入者が相乗りさせてもらうことを希望する場合には、同乗者を受け入れることを希望する他のチケット購入者の中から選択され、チケット購入者が相乗りを受け入れることを希望する場合には、相乗りさせてもらうことを希望する他のチケット購入者の中から選択されるようにしてもよい。

Ｓ１５では、提示部１０３は、Ｓ１４で選択された相乗り候補者を、チケット購入者に提示する。提示部１０３は、購入者情報テーブルを参照して、相乗り候補者の氏名、連絡先等の購入者情報を取得することができる。提示部１０３は、チケット購入者の端末２に、取得した相乗り候補者の購入者情報を送信することで、相乗り候補者をチケット購入者に提示することができる。なお、提示部１０３は、相乗り候補者が複数存在する場合、予め定めた人数、例えば、１０人の候補者を提示するようにしてもよい。

Ｓ１６では、相乗り受付部１０４は、チケット購入者から、相乗り候補者に対する相乗
りの申込みを受け付ける。チケット購入者は、相乗り候補者として複数の相乗り候補者が提示された場合、いずれかの候補者を選択して相乗りの申込みをすることができる。

Ｓ１７では、相乗り受付部１０４は、Ｓ１６で相乗りの申込み対象となった候補者の端末２に、相乗りの申込みがあった旨を通知する。相乗り受付部１０４は、相乗りの申込みの通知とともに、チケット購入者の連絡先等の購入者情報を購入者情報テーブルから取得して送信してもよい。

Ｓ１８では、相乗り受付部１０４は、相乗り候補者の端末２から、相乗りの申込みを承認する旨の通知を受けたか否かを判定する。相乗りの申込みを承認する旨の通知を受けた場合（Ｓ１８：Ｙｅｓ）、処理はＳ１９に進む。相乗りの申込みを承認する旨の通知を受けなかった場合（Ｓ１８：Ｎｏ）、処理はＳ１４に戻る。Ｓ１４に戻った場合、選択部１０２は、相乗りの申込みを承認しなかった候補者を除外して、新たに相乗り候補者を選択するようにしてもよい。

Ｓ１９では、相乗り受付部１０４は、チケット購入者の端末２に対し、相乗りの申込みが承認された旨を通知し、図６に示すマッチング処理は終了する。

第１実施形態では、イベントのチケットを購入するチケット購入者は、チケットを購入するとともに、同じイベントまたは類似イベントの他のチケット購入者の中から、自身の利用形態に適合した相乗りの同乗者を探すことができる。チケットの購入とは別に相乗りの手配をする手間が軽減されるため、車両の相乗りを促進することができる。

［変形例］
上記の第１実施形態は、選択部１０２が相乗り候補者を選択する際、イベントのチケット購入者が相乗りを希望するか否かに基づいて、候補者を選択する例を説明する。これに対し、変形例は、チケット購入者および相乗り候補者の出発地に基づいて、相乗り候補者をさらに絞り込む例である。

（変形例１）
変形例１は、チケット購入者の出発地と相乗り候補者の出発地との距離に基づいて、相乗り候補者を絞り込む例である。変形例１において、選択部１０２は、図６に示すマッチング処理のＳ１４の処理に加えて、図７に示す相乗り候補者絞込処理を実行する。

図７は、変形例１に係る相乗り候補者絞込処理の流れを例示するフローチャートである。Ｓ１４１１では、選択部１０２は、図６のＳ１４で選択された相乗り候補者の出発地の情報を、相乗り情報テーブルから取得する。Ｓ１４１２では、選択部１０２は、図６のＳ１４で選択された相乗り候補者を、チケット購入者の出発地と相乗り候補者の出発地との距離が所定の閾値以下となる相乗り候補者に絞り込む。

また、図６のＳ１５において、提示部１０３は、チケット購入者の出発地と相乗り候補者の出発地との距離が短い順に、相乗り候補者を提示するようにしてもよい。変形例１では、出発地間の距離が所定の閾値以下の相乗り候補者が提示されるため、チケット購入者は、出発地が近く待ち合わせの利便性が良い同乗者を探す手間を軽減することができる。

（変形例２）
変形例２は、目的地に到るチケット購入者の経路と相乗り候補者の経路との重複距離に基づいて、相乗り候補者を絞り込む例である。変形例２において、選択部１０２は、図６に示すマッチング処理のＳ１４の処理に加えて、図８に示す相乗り候補者絞込処理を実行する。

図８は、変形例２に係る相乗り候補者絞込処理の流れを例示するフローチャートである。Ｓ１４２１では、選択部１０２は、図６のＳ１４で選択された相乗り候補者の出発地及び目的地の情報を、相乗り情報テーブルから取得する。Ｓ１４２２では、選択部１０２は、出発地及び目的地の情報から、チケット購入者および相乗り候補者の経路情報を取得する。経路情報は、例えば、予めパーキングエリア等の中継点を定義し、出発地から目的地に到るまでの通過する中継点の情報とすることができる。Ｓ１４２３では、選択部１０２は、チケット購入者の経路と、相乗り候補者の経路を対比し、経路の重複度が所定の閾値以上となるように相乗り候補者を絞り込む。選択部１０２は、例えば、チケット購入者の経路上の中継点のうち、相乗り候補者の経路上にある中継点の数の割合を重複度とすることができる。

また、図６のＳ１５において、提示部１０３は、チケット購入者の経路と相乗り候補者の経路との重複度が高い順に、相乗り候補者を提示するようにしてもよい。変形例２では、出発地から目的地までの経路の重複度が所定の閾値以上の相乗り候補者が提示されるため、チケット購入者は、無駄な迂回の抑制が可能となる同乗者を、効率良く探すことができる。

＜第２実施形態＞
第１実施形態では、イベントのチケット購入者が相乗りを希望するか否かに基づいて相乗り候補者を提示する。これに対し、第２実施形態では、チケット購入者の同乗者に対する希望条件に応じた相乗り候補者を提示する。

第２実施形態の構成は第１実施形態と略同様であり、購入者情報テーブルおよび相乗り情報テーブルのデータ構造が異なる。以下、第１実施形態と異なる点について主に説明する。

図９は、第２実施形態に係る購入者情報テーブルを例示する図である。第２実施形態に係る購入者情報テーブルは、第１実施形態の購入者情報テーブル（図４）に示されるフィールドに加えて、性別および年齢のフィールドを有する。性別および年齢は、チケットを購入したチケット購入者または相乗り候補者の性別および年齢であり、購入者の属性を示す情報（以下、属性情報ともいう）である。属性情報は、性別および年齢に限られず、家族構成、趣味、職業等の各種情報を含んでもよい。購入者情報テーブルには、各属性に対応するフィールドが追加されればよい。受付部１０１は、端末２に入力された情報から購入者の属性情報を取得し、図９に示す購入者情報テーブルに格納することができる。なお、受付部１０１は、端末２に設置されたカメラ等によって撮影された購入者の撮像画像を解析することで、性別または年齢等の属性情報を取得してもよい。

図１０は、第２実施形態に係る相乗り情報テーブルを例示する図である。第２実施形態に係る相乗り情報テーブルは、第１実施形態の相乗り情報テーブル（図５）に示されるフィールドに加えて、希望年齢および希望性別のフィールドを有する。希望年齢および希望性別は、相乗りの同乗者として希望する相手の年齢および性別である。希望条件は、年齢および性別に限られず、各種属性情報を含んでも良い。相乗り情報テーブルには、各属性の希望条件を格納するフィールドが追加されればよい。受付部１０１は、チケット購入者がチケットを購入する場合に、相乗りの同乗者に対して希望する条件を、端末２に入力された情報から取得し、図１０に示相乗り情報テーブルに格納する。

図１１は、第２実施形態に係るチケット購入時のマッチング処理の流れを例示するフローチャートである。Ｓ１５以降の処理は、図６に示すマッチング処理と同様であるため、Ｓ１５までの処理について説明する。

Ｓ２１では、受付部１０１は、図６のＳ１１と同様に、イベントのチケットを購入するチケット購入者が端末２に入力した購入者情報を、通信インタフェース１４を介して取得する。購入者情報は、購入者の氏名、住所、連絡先等の情報に加え、購入者の性別、年齢等の属性情報を含んでもよい。受付部１０１は、取得した購入者情報を、購入者情報テーブルに格納する。

Ｓ２２では、受付部１０１は、図６のＳ１２と同様に、端末２から、イベントのチケットの購入を受け付ける。これとともに、受付部１０１は、チケット購入者の相乗りに関する希望条件を取得する。相乗りに関する希望条件は、相乗りの利用形態に関する情報に含まれ、端末２において、チケット購入者によって入力される。受付部１０１は、チケット購入者とチケットが購入されたイベントとを対応付け、相乗りに関する希望条件の情報を、相乗り情報テーブルに格納する。

Ｓ２３では、選択部１０２は、図６のＳ１３と同様に、チケット購入者が相乗りを希望するか否かを判定する。チケット購入者が相乗りを希望する場合（Ｓ２３：Ｙｅｓ）、処理はＳ２４に進む。チケット購入者が相乗りを希望しない場合（Ｓ２３：Ｎｏ）、チケット購入者に対するマッチングは実行されず、図１１に示す処理は終了する。

Ｓ２４では、選択部１０２は、チケット購入者の利用形態に適合する相乗り候補者を選択する。選択部１０２は、図６のＳ１４と同様に、相乗り情報テーブルを参照し、チケット購入者がチケットを購入したイベントと対応付けられた購入者を抽出する。なお、選択部１０２は、当該イベントの類似イベントと対応づけられた購入者を含めて抽出してもよい。選択部１０２は、抽出した購入者の中から、チケット購入者の利用形態に適合する相乗り候補者を選択する。そして、選択部１０２は、選択した相乗り候補者を、チケット購入者が同乗者の属性に対して希望する属性情報の条件を満たす相乗り候補者に絞り込む。具体的には、選択部１０２は、抽出した購入者のうち、チケット購入者の同乗者に対する希望年齢および希望性別を満たす購入者に絞り込む。

ここで、図１０の例において、購入者Ｕ００３に対し、利用形態に適合する相乗り候補者を選択し、希望条件を満たす相乗り候補者に絞り込む例について説明する。購入者Ｕ００３は、イベントＥ０１のチケットを購入しており、購入者Ｕ００３の利用形態は、相乗りを希望、車両提供可、運転可である。また、購入者Ｕ００３が同乗者に対して希望する属性情報の条件は、希望年齢はなし、希望性別は男性である。したがって、購入者Ｕ００３の利用形態に適合する相乗り候補者として、まず、イベントＥ０１のチケットを購入し、相乗りを希望する購入者Ｕ００１が選択される。また、購入者Ｕ００１は、購入者Ｕ００３は、図９の購入者情報テーブルに示すように男性であるため、購入者Ｕ００３が希望する属性情報の条件を満たし、相乗り候補者として選択される。なお、図９から図１１では、属性情報として、年齢と性別を例として説明したが、これらに限られず、家族構成、趣味、職業等の各種属性情報の条件を満たす相乗り候補者が選択されるようにしてもよい。Ｓ１５以降の処理は、図６に示すマッチング処理と同様である。

第２実施形態では、イベントのチケットを購入するチケット購入者は、チケットの購入とともに、同じイベントまたは類似イベントの他のチケット購入者の中から、希望する条件に応じた相乗りの同乗者を探すことができる。これにより、チケット購入者の相乗りに対する動機づけを高め、車両の相乗りを促進することができる。

＜その他の実施形態＞
上記の実施形態はあくまでも一例であって、本発明はその要旨を逸脱しない範囲内で適宜変更して実施しうる。本開示において説明した処理や手段は、技術的な矛盾が生じない
限りにおいて、自由に組み合わせて実施することができる。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本発明は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤディスク、ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１：サーバ
１１：ＣＰＵ １２：ＲＡＭ １３：記憶装置 １４：通信インタフェース
１０１：受付部 １０２：選択部 １０３：提示部 １０４：相乗り受付部
１１０：チケット販売データベース １１１：相乗り情報データベース
２：端末
２１：ＣＰＵ ２２：ＲＡＭ ２３：記憶装置 ２４：通信インタフェース
２５：入力装置

Claims (10)

1. 第１チケット購入者からイベントのチケットの購入を受け付けるとともに、前記イベントの開催場所まで車両で移動する場合に、相乗りの利用形態に関する情報の登録を受け付けることと、
   前記イベントまたは前記イベントと開催場所および開催期間の一部が共通する類似イベントのチケットを購入したチケット購入者の中から、前記第１チケット購入者の相乗りの利用形態に適合する第２チケット購入者を相乗り候補者として選択することと、
   前記第１チケット購入者に対し、前記第２チケット購入者を提示することと、
   を実行する制御部を備える情報処理装置。
2. 第２チケット購入者は、前記第１チケット購入者が相乗りさせてもらうことを希望する場合には、同乗者を受け入れることを希望する前記チケット購入者の中から選択され、前記第１チケット購入者が相乗りを受け入れることを希望する場合には、相乗りさせてもらうことを希望する前記チケット購入者の中から選択される、
   請求項１に記載の情報処理装置。
3. 前記制御部は、
   前記第１チケット購入者の出発地の情報を取得し、前記取得した出発地の情報に基づいて前記第２チケット購入者を絞り込むこと
   をさらに実行する、請求項１または２に記載の情報処理装置。
4. 前記制御部は、
   前記第１チケット購入者の出発地と前記第２チケット購入者の出発地との距離が、所定の閾値以下となるように前記第２チケット購入者を絞り込むこと
   をさらに実行する、請求項３に記載の情報処理装置。
5. 前記制御部は、
   前記第１チケット購入者の出発地から前記イベントの開催場所までの第１経路と、前記第２チケット購入者の出発地から前記イベントの開催場所までの第２経路との重複度が、所定の閾値以上となるように前記第２チケット購入者を絞り込むこと
   をさらに実行する、請求項３に記載の情報処理装置。
6. 前記制御部は、
   前記第１チケット購入者が希望する属性情報の条件を満たす前記第２チケット購入者に絞り込むこと
   をさらに実行する、請求項１から５のいずれか一項に記載の情報処理装置。
7. 前記制御部は、
   前記第２チケット購入者を撮像した画像を解析して前記第２チケット購入者の属性情報を取得することをさらに実行する、
   請求項６に記載の情報処理装置。
8. 前記制御部は、
   前記第１チケット購入者から、前記第２チケット購入者に対する相乗りの申込みを受け付け、前記申込みの対象となった対象候補者の端末に前記申込みの内容を送信すること
   をさらに実行する、請求項１から７のいずれか１項に記載の情報処理装置。
9. コンピュータが、
   第１チケット購入者からイベントのチケットの購入を受け付けるとともに、前記イベン
   トの開催場所まで車両で移動する場合に、相乗りの利用形態に関する情報の登録を受け付けることと、
   前記イベントまたは前記イベントと開催場所および開催期間の一部が共通する類似イベントのチケットを購入したチケット購入者の中から、前記第１チケット購入者の相乗りの利用形態に適合する第２チケット購入者を相乗り候補者として選択することと、
   前記第１チケット購入者に対し、前記第２チケット購入者を提示することと、
   を実行する、情報処理方法。
10. 請求項９に記載の情報処理方法をコンピュータに実行させるためのプログラム。

Images