JP2021149294A - 車両乗合支援システム - Google Patents

Abstract

【課題】車両乗合支援システムにおいて、乗合利用者の希望条件をより反映した乗合グループを形成し易くする車両乗合支援システムを提供する。【解決手段】車両乗合支援システムにおいて、、利用者端末と、利用者端末とネットワークを介して接続され、乗合利用者から入力された複数の乗合条件に基づいて、推奨される乗合グループのセットを作成して出力するサーバとを有する。乗合条件は、乗合利用者から利用者端末において許容範囲が入力される第１乗合条件と、乗合利用者から希望度とともに利用者端末において入力される第２乗合条件とを含む。サーバは、乗合利用者それぞれに対して、第１乗合条件が許容条件を満たし、且つ、第２乗合条件の希望度に応じて定められる抽出条件を満たす乗合グループのセットを抽出する抽出処理と、抽出されたセットの中から、入力された乗合条件に適合するセットを選択して出力する選択処理とを順に実行する。【選択図】図１

Description

本発明は、ユーザにライドシェアサービスを提供する車両乗合支援システムに関する。

共有車の運転者を効率的に決定するための乗合運転者決定システムが公知である（たとえば、特許文献１）。乗合運転者決定システムでは、各運転者に対して炭素排出量、電力消費量、運転距離、時間等の項目の評価値を評価し、それぞれの評価値に重みを積算して和を取った加重和に基づいて、運転者の割り当てが行われる。

自動車で移動する予定のある運転者と、他人の車に乗り合って目的地まで移動することを希望する乗合者とを組み合わせることによって、自動車のライドシェア（乗合）を支援する車両乗合支援システム（ライドシェアサービスシステム）が公知である（例えば、特許文献２）。

米国特許出願公開第２０１４／０１８８７７５号明細書 特開２００２−１４０３９９号公報

特許文献２に記載の車両乗合支援システムの利用を希望する乗合利用者は、自らが乗合を利用する場合に端末に希望する条件（以下、乗合条件）を入力する。

近年のライドシェアの普及によって、乗合利用者の希望する乗合条件は距離や時間に限定されず、たとえば、乗り合う車両の車内環境や、同乗者の属性（性別や、喫煙の有無等）もまた重要な希望条件となりうることが明らかとなってきた。そこで、車両乗合支援システムにおいて、乗合利用者からより多くの乗合条件を受け付けて、全ての乗合条件を満たすように乗合グループを構成することが考えられる。しかしながら、乗合利用者からの乗合条件が増加すると、車両乗合支援システムは全ての乗合条件を満たすように乗合グループを構成し難くなるという問題がある。

本発明は、以上の背景を鑑み、車両乗合支援システムにおいて、乗合利用者の希望条件をより反映した乗合グループを形成し易くすることを課題とする。

上記課題を解決するために本発明のある態様は、利用者端末（２）と、前記利用者端末とネットワーク（３）を介して接続され、前記利用者端末において乗合利用者から入力された複数の乗合条件に基づいて、推奨される乗合グループのセットを作成して出力するサーバ（４）とを有する車両乗合支援システム（１、１００、２００）であって、前記乗合条件は、前記乗合利用者から前記利用者端末において許容できる許容範囲が入力される第１乗合条件と、前記乗合利用者からの希望が前記希望に対する希望度とともに前記利用者端末において入力される第２乗合条件とを含み、前記サーバは、前記乗合利用者それぞれにおいて、前記第１乗合条件が前記許容範囲内にあり、且つ、前記第２乗合条件の前記希望度に応じて定められる抽出範囲内の前記乗合グループの前記セットを抽出する抽出処理（ＳＴ２２）と、抽出された前記セットの中から、入力された前記乗合条件に適合する前記セットを選択する選択処理（ＳＴ２３）とを順に実行することを特徴とする。

この構成によれば、第１乗合条件の抽出範囲を第２乗合条件の希望度に応じて変更することができる。すなわち、例えば、第２乗合条件の希望度が高い（すなわち、合致し難い）場合には抽出範囲を広げることによって、抽出処理においてより多くの乗合グループのセットを抽出することができる。これにより、入力された複数の乗合条件に適合する乗合グループのセットが形成され易くなる。

上記の態様において、前記サーバは、前記選択処理において、前記乗合グループの前記セットそれぞれについて、前記乗合利用者の前記第２乗合条件それぞれに対して満たされる度合いを充足度として算出するステップ（ＳＴ２３Ｂ）と、前記乗合利用者の前記充足度の前記乗合グループそれぞれの平均値の総和が最大となる前記セットを推奨される前記セットとして選択するステップ（ＳＴ２３Ｄ）とを順に実行するとよい。

この構成によれば、第２乗合条件がより充足された乗合グループのセットが推奨されるセットとして出力される。よって、乗合利用者の希望に即した乗合グループが形成されて出力され易くなる。

上記の態様において、前記第１乗合条件は、乗合を利用することによって前記乗合利用者が追加されることを許容する迂回時間であるとよい。

この構成によれば、第１乗合条件として迂回時間を用いることで、抽出範囲の拡大縮小を容易に行うことができる。

上記の態様において、前記サーバには、前記迂回時間に係る前記許容範囲が、前記迂回時間の上限値によって入力されるとよい。

この構成によれば、許容範囲を迂回時間の上限値として設定することによって、迂回時間が乗合利用者の意に反して延長されることが防止できる。

上記の態様において、前記サーバは、所定の前記第２乗合条件に対して所定の停止入力があったときには、前記停止入力に対応する前記第２乗合条件によって定められる前記抽出範囲を、前記許容範囲に設定するとよい。

上記の態様において、前記サーバは、所定の前記第２乗合条件に対して所定の必須入力があったときには、前記抽出処理において、前記必須入力を行った前記乗合利用者の前記必須入力がされた前記第２乗合条件が満たされる前記乗合グループの前記セットを抽出し、前記選択処理において、抽出された前記セットの中から、入力された前記乗合条件に適合する前記セットを選択するとよい。

この構成によれば、ユーザは第２乗合条件が必ず満たされることを希望する場合に、第２乗合条件に対して必須入力を行うと、第２乗合条件が満たされた乗合グループのセットが抽出されて、その中から乗合グループが選択されて出力される。これにより、出力される乗合グループは必ず第２乗合条件を満たしたものとなるため、ユーザの希望により即した乗合グループが出力され易くなる。

この構成によれば、乗合利用者が希望しない第２乗合条件によって抽出される乗合グループのセットの範囲が狭められることが防止できる。これにより、ユーザの希望に即さない乗合グループが選択され難くなる。

上記の態様において、前記サーバは、前記選択処理の後に、前記乗合利用者の前記利用者端末に、同乗者の前記第２乗合条件の前記希望を表示させる表示処理を実行するとよい。

この構成によれば、乗合利用者は利用者端末の表示によって、同乗者が設定した第２乗合条件の希望度を知ることができる。これにより、乗合利用者が同乗者に対して気遣いをし、同乗者の希望に即した行動を行うことが期待できるため、車内環境の向上を図ることができる。

上記の態様において、前記サーバは、前記抽出処理において、過去の予約履歴に基づいて、前記希望度に対応する前記抽出範囲を設定し、前記抽出範囲を満たす前記乗合グループを抽出できる確率を算出して、前記利用者端末に表示させるとよい。

この構成によれば、乗合利用者は、希望度の変更によって、乗合グループが抽出され易いかを理解することができる。これにより、乗合利用者は希望度を設定し易くなる。

上記の態様において、前記サーバは、前記抽出処理において、現在の予約状況に基づいて、前記希望度に対応する前記抽出範囲を設定し、前記抽出範囲を満たす前記乗合グループに含まれる前記乗合利用者の数を算出して、前記利用者端末に表示させるとよい。

この構成によれば、乗合利用者は、希望度の変更によって、乗合グループが抽出され易いかを理解することができる。これにより、乗合利用者は希望度を設定し易くなる。

上記の態様において、前記第２乗合条件は、同乗者の性別、車内の音楽の選択、ラジオ局の選択、会話の有無、車内の飲食の可否のいずれか１つを含むとよい。

この構成によれば、乗合利用者から乗り合う車両の車内環境や、同乗者の属性に係る希望を受け付けることができる。

以上の構成によれば、車両乗合支援システムにおいて、乗合利用者の希望条件をより反映した乗合グループを形成し易くすることができる。

第１実施形態に車両乗合支援システムの構成図 乗合支援処理の手順を示すフローチャート 申込受付処理の手順を示すフローチャート （Ａ）条件選択画面、（Ｂ）希望度入力画面、及び、（Ｃ）確認画面を説明するための説明図 運行予定作成処理の手順を示すフローチャート 運行予定表示画面を説明するための説明図 第２実施形態に係る希望度入力画面を説明するための説明図 第２実施形態に係る希望度入力画面の第１変形例を説明するための説明図 第２実施形態に係る希望度入力画面の第２変形例を説明するための説明図

＜＜第１実施形態＞＞
以下、図面を参照して、車両乗合支援システム１の実施形態について説明する。実施形態に係る車両乗合支援システム１は、特定の団体（企業、役所、スポーツクラブ、介護施設、買物施設等）の構成員（ユーザ）に対して、移動時の車両の乗合を支援するサービスを提供する。本実施形態では、車両乗合支援システム１は、ユーザの特定の施設への往路の移動に対して、自動車の乗合（ライドシェア）サービスを提供する。ここでいう往路の移動とは、例えばユーザの朝の通勤、すなわち出勤における移動に対応する。すなわち、車両乗合支援システム１は、ユーザの出勤時の移動経路（往路）における乗合を支援し、ユーザは、車両乗合支援システム１の利用者、すなわち、乗合利用者である。

本実施形態に係る車両乗合支援システム１を利用する団体は、構成員に使用させる目的で複数の共用車を所有している。共用車は、通勤を含む構成員の移動に使用される。車両乗合支援システム１は、複数の共用車と、構成員の自家用車の内で乗合に使用することに同意した自動車（以下、提供車という）とを乗合のために使用する。全てのユーザ、共用車及び提供車は、車両乗合支援システム１に登録されている。車両乗合支援システム１において、全てのユーザにはユーザ識別番号が設定され、全ての共用車及び提供車には車両識別番号が設定されている。

（車両乗合支援システムの構成）
図１に示すように、車両乗合支援システム１は、ユーザに保持された複数のユーザ端末２（利用者端末）と、それぞれのユーザ端末２とネットワーク３を介して接続されたホストサーバ４とを有する。各ユーザ端末２は各ユーザに所持されている。ホストサーバ４は任意の場所に設けられてよく、例えば車両乗合支援システム１を運営する企業の建屋内に設けられるとよい。ネットワーク３は、例えばインターネットである。

ユーザ端末２は、アプリケーションを実行するための処理部１１と、入力画面やメッセージを表示するとともにユーザからの入力を受け付けるユーザインタフェース１２と、ネットワーク３を介してホストサーバ４と通信を行うための通信部１３とを備えている。ユーザ端末２は、例えば、スマートホンや、タブレットＰＣ、携帯電話、ＰＤＡ等である。ユーザ端末２の処理部１１は、ユーザの入力操作による乗合申込を受け付ける申込受付部１５を有する。申込受付部１５は、乗合申込を受け付ける際に、ユーザ識別番号、ユーザの希望出発地、希望目的地、希望出発時間、使用可能車情報（使用可能車の車両識別番号）、及び、乗合を利用する際に希望する条件（乗合条件）に関する情報の入力を要求する。ここで、使用可能車とは、ユーザが申込したライドシェアにおいて、ユーザが運転手として希望出発地から運行可能な車両をいい、共用車及び提供車を含む。具体的には、ユーザが選択した希望出発地の付近に駐車された車両であり、かつユーザが車両の利用に必要なキー又は認証カード等を所持している車両が使用可能車に該当する。

ホストサーバ４（サーバ）は、ネットワーク３を介してユーザ端末２と通信するための通信部２１と、ユーザからの乗合申込を受け付ける申込処理部２２と、乗合を希望するユーザの乗合申込情報を記憶する申込情報管理部２３と、乗合申込があったユーザをグループ化して複数の乗合グループを作成するとともに、外部のナビゲーションサーバ５を使って各乗合グループの運行予定を作成する運行予定作成部２４と、作成した乗合グループ及び運行予定を記憶する乗合情報管理部２５と、ユーザ毎の情報を保持するユーザ情報管理部２６と、登録された車両情報を保持する車両情報管理部２７と、外部の道路情報サーバ６を使って道路の混雑状況を取得する道路情報取得部２８、及び、乗合の運行予定情報をユーザに通知するためのユーザ通知部２９とを有する。ナビゲーションサーバ５及び道路情報サーバ６は、ホストサーバ４の一部として構成されてもよい。

ユーザ情報管理部２６は、ユーザ毎にユーザに関連する情報をユーザ情報として記憶している。ユーザ情報は、ユーザ識別番号や、ユーザ氏名、住所、ユーザが所有する提供車の車両識別番号を含む。ユーザ情報には、運転技能レベルや、過去の運転手担当情報が含まれていてもよい。

車両情報管理部２７は、ライドシェアで使用する車両として登録された複数の共用車及び提供車の情報を車両情報として記憶している。車両情報は、登録された車両毎に、車両識別番号、所有者、車種名、乗車定員数を含む。車両情報には、燃費や、走行距離当りのＣＯ_２排出量が含まれていてもよい。

申込情報管理部２３は、申込処理部２２から乗合申込情報を受け取り、記憶する。乗合申込情報は、申込を行なったユーザのユーザ識別番号、ユーザの希望出発地、希望目的地、希望出発時間、使用可能な車両の車両識別番号、及び、乗合条件を含む。

運行予定作成部２４は、申込情報管理部２３に記憶された乗合申込情報に基づき、後述する運行予定作成処理（図４参照）を実行することによって、乗合申込を行なったユーザをグループ化して複数の乗合グループを作成するとともに、各乗合グループにおける各ユーザの役割（運転手、又は、運転手以外の乗員）、各乗合グループが使用する車両、各乗合グループの経路を設定する。また、運行予定作成部２４は、設定した各乗合グループの経路に基づいて、各ユーザの出発地、目的地、出発時間、及び目的地到着予想時間を設定する。

乗合情報管理部２５は、運行予定作成部２４が作成した運行予定情報を記憶する。運行予定情報は、乗合グループ毎に作成され、乗合グループの識別番号、乗合グループに含まれるユーザの識別番号、運転手に設定されたユーザの識別番号、使用される車両の識別番号、各ユーザの出発地、目的地、出発時間、目的地到着予想時間を含む。

ユーザ通知部２９は、乗合情報管理部２５に記憶された運行予定情報から、ユーザ毎の運行予定情報であるユーザ運行予定情報を作成し、通信部１３によって各ユーザ端末２に対応するユーザ運行予定情報を送信する。ユーザ運行予定情報は、ユーザの識別番号、乗合グループの識別番号、使用される車両の識別番号、ユーザの出発地、目的地、出発時間、目的地到着予想時間、ユーザ役割情報を含む。ユーザ役割情報は、ユーザが運転手（ドライバー）及び、運転者以外の乗員（ライダー）のいずれであるかを示す情報である。ユーザ運行予定情報は、ユーザ毎の出発時間、出発地、目的地等を含み、乗合車両の走行経路情報を含む。乗合車両の走行経路情報は、道路情報サーバ６の道路情報、及び、道路情報取得部２８によって取得された道路の混雑状況に基づいて作成される。ユーザ端末２に、ユーザ運行予定情報を送信されると、ユーザインタフェース１２にはユーザ運行予定情報を表示される。

（乗合支援処理）
以下に、実施形態に係る車両乗合支援システム１の乗合支援処理の手順について説明する。車両乗合支援システム１は、複数のユーザが実際に出勤を行なう時間帯に実施期間を設定し、その実施期間に対応して往路における乗合支援処理を実行する。実施期間は、例えば、平日の朝の出勤帯（６時〜１０時）であるとよい。

図２は、乗合支援処理の手順を示すフローチャートを示している。最初にステップＳＴ１において、ホストサーバ４の申込処理部２２が乗合申込の受付を開始する。乗合申込の受付期間は、実施期間の開始時から所定の時間前に設定される。例えば、実施期間がある日の出勤時（６時〜１０時）を含む場合、申込処理部２２はその日の３日前の６時に乗合申込の受付を開始する。

同時に、申込処理部２２はユーザ端末２に受付開始信号を送信し、ユーザ端末２の申込受付部１５は所定の実施期間を対象とした乗合申込の受付処理（以下、申込受付処理）を可能にする。これにより、乗合の利用を希望するユーザ（乗合利用希望者）はユーザ端末２を使用して申込受付部１５に申込受付処理を実行させて、所定の実施期間を対象とした乗合申込を入力することができる。

ユーザがユーザ端末２に所定の入力を行うと、申込受付部１５は、申込受付処理を開始する。申込受付部１５は、申込受付処理においてユーザに対して、希望出発地、希望目的地、希望出発時間、使用可能な車両の車両識別番号、及び、乗合条件を含む乗合申込情報の入力を要求する。なお、ユーザ識別番号、希望出発地、希望目的地、提供車（使用可能車）の車両識別番号は、ユーザ端末２、ユーザ情報管理部２６、及び車両情報管理部２７に記憶されたデータを参照して入力を省略されてもよい。

乗合条件は、第１乗合条件、及び、第２乗合条件を含む。第１乗合条件とは、ユーザが乗合申込を行うときに、許容できる許容範囲の入力が要求される乗合条件である。本実施形態では、第１乗合条件は、ユーザが乗合を利用することによって、直接移動する場合に比べて追加されることを許容する時間（以下、迂回時間）の上限値として入力が要求される。第２乗合条件とは、各ユーザの希望と、その希望が達せられるべき度合いを示す希望度との入力がユーザに対して要求される乗合条件である。第２乗合条件とは、例えば、乗合が行われているときの車内環境（例えば、選局されるラジオ局や、スピーカの音量等）や、同乗者の属性（車内での喫煙の希望の有無、車内での会話の希望の有無、車内の飲食の可否、性別、所属部署、車内の音楽の選択（音楽ジャンル）等）に関する条件である。これにより、ユーザから乗り合う車両の車内環境や、同乗者の属性に係る多様な希望を受け付けることができる。

ユーザが申込受付処理において入力した乗合申込情報を含む入力情報は、ホストサーバ４に送信され、申込情報管理部２３に記憶される。

次に、ステップＳＴ２において、申込処理部２２は、乗合申込の受付開始から所定の期間経過後であり、実施期間の開始前に乗合申込の受付期間を終了する。例えば、実施期間がある日の往路を対象とする場合、申込処理部２２はその前日の１８時に乗合申込の受付を終了する。同時に、申込処理部２２はユーザ端末２に受付終了信号を送信し、ユーザ端末２の申込受付部１５は所定の実施期間を対象とした乗合申込の受付を終了する。これにより、その後は、ユーザは所定の実施期間を対象とした乗合申込ができなくなる。

次に、ステップＳＴ３において、運行予定作成部２４は、各ユーザの乗合申込情報に基づいて運行予定作成処理を実行する。運行予定作成処理の詳細については図４を参照して後述する。運行予定作成処理によって、往路における運行予定である運行予定情報が作成される。運行予定情報は、複数のユーザを含む複数の乗合グループ、各乗合グループにおける運転手、各乗合グループの経路、各ユーザの出発地、到着地、出発時間、及び目的地到着予想時間を含む。運行予定作成部２４は、運行予定情報を乗合情報管理部２５に記憶する。運行予定作成部２４は、ユーザ毎の運行予定情報であるユーザ運行予定情報を作成し、乗合情報管理部２５に保存する。

次に、ステップＳＴ４において、ユーザ通知部２９は、通信部１３によって各ユーザ端末２に対応するユーザ運行予定情報を予約結果として送信する。これにより、ユーザ端末２に、ユーザ運行予定情報が表示されて、ユーザはユーザ端末２によって自身のユーザ運行予定情報を確認することができる。

（申込受付処理）
次に、申込受付部１５が実行する申込受付処理の手順について、図３に示すフローチャートを参照して説明する。申込受付部１５は、申込受付処理の最初のステップＳＴ１１において、第１乗合条件に対してユーザが許容できる範囲（許容範囲）の入力を受け付ける画面をユーザインタフェース１２に表示し、ユーザから入力を受け付ける。より具体的には、本実施形態では、第１乗合条件は迂回時間であり、申込受付部１５はステップＳＴ１１において、迂回時間の上限値の受付を行う。申込受付部１５は迂回時間の上限値の入力が完了した（例えば、ユーザインタフェース１２に次への文字とともに表示されたボタンへの押圧が検知された）ことを検知すると、申込受付部１５はステップＳＴ１２を実行する。

申込受付部１５はステップＳＴ１２において、ユーザ自身の属性についての設定の入力を受け付ける。より具体的には、入力を行っているユーザが車内での選局されることを希望するラジオ局、車内での喫煙の希望の有無、車内での会話を希望するか否かの選択、また、ユーザの性別などの記入欄をユーザインタフェース１２に表示し、ユーザからの入力を受け付ける。ユーザインタフェース１２にユーザから入力が完了した旨の入力が検知されると、申込受付部１５はステップＳＴ１３を実行する。

申込受付部１５は、ステップＳＴ１３において、ユーザインタフェース１２に、希望出発地、希望目的地、希望出発時間、及び、使用可能な車両識別番号の入力欄を表示してユーザからの入力を受け付ける。ユーザからの入力が完了すると、申込受付部１５は、ステップＳＴ１４を実行する。

申込受付部１５は、ステップＳＴ１４において、第２乗合条件についての希望と、その希望が達せられるべき度合いを示す希望度とともに入力される入力画面（図４（Ａ）参照。以下、条件選択画面）をユーザインタフェース１２に表示して、ユーザから入力を受け付ける。本実施形態では、第２乗合条件は、車内環境に係るものとして、選局されるラジオ局に関する条件を含み、同乗者の属性に係るものとして、車内での喫煙の希望の有無、車内での会話の有無、及び、同性を希望するか否かの条件を含む。

本実施形態では、図４（Ａ）に示すように、申込受付部１５は、各乗合条件に対応する項目が記載された欄（例えば、会話の有無に関するものであることを示す「あまり話をしたくない」の文字が記載された欄）の所定部分（図４（Ａ）の「＞」が表示されている部分）へのタッチを検出すると、図４（Ｂ）に示すように、当該乗合条件に対応する希望度の入力画面（以下、希望度入力画面）をユーザインタフェース１２に表示する。

本実施形態では、「あまり話をしたくない」の文字が記載された欄にタッチがあった場合には、ユーザインタフェース１２には、会話の有無に関することであることを示す項目名（「あまり話をしたくない」の文字）と、「ＯＦＦ」（停止入力）、「ＯＮ」、「１分」、「２分」、・・・・、「ＭＡＸ」の選択肢が示された選択枠とが表示される。但し、選択肢として表示される時間は、迂回時間の上限値よりも小さくなるように設定されている。

「ＯＦＦ」は、乗合グループの決定の際にユーザが会話の有無を条件とすることを希望しないことを示している。このように、ユーザは「ＯＦＦ」を入力することによって、対応する第２乗合条件が乗合グループの決定の条件とはならないように設定することができる。「ＯＮ」は、乗合グループの決定の際にユーザが会話の有無を条件とすることを希望し、且つ、車内での会話を希望しないユーザとのみ乗合グループを形成することを希望することを示している。

「１分」、「２分」・・・等の時間を示す選択肢はそれぞれ、車内での会話を希望しないユーザとのみ乗合グループを形成することを希望し、且つ、迂回時間が最も短くなる組み合わせに対して、設定した分の迂回時間が追加されてもよいことを示している。すなわち、申込受付部１５は、第２乗合条件の車内の会話の有無に対して、車内の会話が行われないことを希望する旨と、追加されうる迂回時間への換算値によって会話が行われないことを希望する希望度とを選択枠において受け付ける。

「ＭＡＸ」は、車内での会話を希望しないユーザとのみ乗合グループを形成することを希望し、且つ、ステップＳＴ１１において入力された上限値の迂回時間が追加されてもよいことを示している。選択枠への入力が行われると、申込受付部１５は、ユーザインタフェース１２に条件選択画面を表示する。以下、第２乗合条件のうち、ユーザが希望度入力画面において「ＯＮ」を選択したもの、すなわち、希望度が入力されず、必ず満たすべき条件を必須条件と記載する。

希望度入力画面において選択枠への入力が完了すると、ユーザインタフェース１２には、条件確認画面が表示される。図４（Ａ）に示すように、条件確認画面には、項目名と、その選択内容が表示されるため、ユーザは容易に自らの選択内容を確認することができる。

図４（Ａ）に示すように、条件確認画面には、第２乗合条件の入力が完了したことを示す入力を受け付けるボタン（図４（Ａ）の「次へ」と記載されたボタン）が含まれる。ユーザから当該ボタンへの押圧が検知されると、申込受付部１５は、ステップＳＴ１５を実行する。

申込受付部１５は、図４（Ｃ）に示すように、ユーザインタフェース１２に入力された第１乗合条件、及び第２乗合条件を含む乗合条件の表示と、修正ボタン及び送信ボタンとを含む画面（以下、確認画面）を表示する。確認画面の表示が完了すると、申込受付部１５はステップＳＴ１６を実行する。

申込受付部１５は、ステップＳＴ１６において、ユーザから修正ボタンへの入力（押圧）があったかを判定する。入力が有った場合には、申込受付部１５はステップＳＴ１１を実行する。これにより、ユーザは再度、乗合条件等を入力することができる。修正ボタンへの入力がない場合には、申込受付部１５はステップＳＴ１７を実行する。

申込受付部１５は、ステップＳＴ１７において、ユーザから送信ボタンへの入力（押圧）があったかを判定する。送信ボタンへの入力が有った場合には、申込受付部１５は、ステップＳＴ１８を実行し、入力がない場合には、ステップＳＴ１６を実行する。

申込受付部１５は、ステップＳＴ１８において、乗合申込情報を含むユーザから入力された全ての入力情報をホストサーバ４に送信する。

（運行予定作成処理）
ホストサーバ４は入力情報を受信した後、乗合申込の受付期間が終了すると、運行予定作成部２４は運行予定作成処理を実行する。以下では、運行予定作成処理の手順について、図５に示すフローチャートを参照して説明する。

運行予定作成部２４は運行予定作成処理の最初のステップＳＴ２１において、乗合申込を行ったユーザ（乗合利用者）に対して、第１乗合条件に関する抽出範囲を決定する。抽出範囲は第２乗合条件の希望度に応じて定められるものであって、希望度が高くなるにつれて、抽出範囲が拡大される。本実施形態では、運行予定作成部２４は、各ユーザが第２乗合条件のそれぞれに対して設定した迂回時間（例えば、図４（Ｂ）参照）の最大値によって抽出範囲を定める。抽出範囲の決定が完了すると、運行予定作成部２４はステップＳＴ２２を実行する。

運行予定作成部２４は、ステップＳＴ２２において、抽出処理を実行する。抽出処理は、乗合申込を行ったユーザをグループ化して、乗合を実行することのできる乗合グループのセットを作成し、その中から、迂回時間（第１乗合条件）が抽出範囲内であることを満たすセットを抽出する処理である。

より具体的には、運行予定作成部２４は、抽出処理において、まず、乗合申込を行ったユーザをグループ化して、乗合グループの複数のセットを作成する（ＳＴ２２Ａ）。その後、運行予定作成部２４は、セットそれぞれに対して、各ユーザの乗合申込情報の希望出発地、希望目的地、希望出発時間、及び、使用可能車両の車両識別番号に基づいて、ユーザの役割（運転手又は乗員）、及び、使用可能な車両を考慮して、走行経路を作成し、各グループにおいて乗合を実行できるかを判定する。運行予定作成部２４は、全ての乗合グループにおいて乗合を実行できるセットを実行可能セットとして抽出する（ＳＴ２２Ｂ）。

次に、運行予定作成部２４は、実施可能セットに含まれる各乗合グループにおいて、各ユーザに対し、希望出発地から希望目的地に直接移動する場合に比べて要する時間、すなわち、迂回時間を算出する。その後、運行予定作成部２４は、各ユーザの迂回時間が抽出範囲内にあるか否かを判定し、全てのユーザの迂回時間が抽出範囲内にあるセットを、抽出セットとして抽出する（ＳＴ２２Ｃ）。抽出セットの抽出が完了すると、運行予定作成部２４はステップＳＴ２３を実行する。

運行予定作成部２４はステップＳＴ２３において、ユーザから入力された乗合条件に最も適合するセットを選択し、推奨される乗合グループのセットとして出力する選択処理を行う。

より具体的には、運行予定作成部２４は、選択処理において、まず、抽出セットの各乗合グループに対して、ユーザのそれぞれに対して必須条件が全て充足されているか否かを判定し、必須条件が全て充足されている抽出セットを充足セットとして抽出する（ＳＴ２３Ａ）。

充足セットの抽出が完了すると、運行予定作成部２４は、充足セットの各セットに対して、各ユーザに対して、乗合の利用を希望するユーザの第２乗合条件が充足されている度合いを示す充足度（以下、コスト）を算出する（ＳＴ２３Ｂ）。

より具体的には、運行予定作成部２４は、各ユーザに対し、コストを、第２乗合条件のそれぞれに対し、（設定した迂回時間×希望に該当する同乗者数÷同乗人数）−２×（設定した迂回時間×希望に該当しない同乗者数÷同乗人数）として算出する。次に、運行予定作成部２４は、乗合グループごとのコストを、乗合グループを構成するユーザの平均値として算出し、乗合グループのコストの総和を、各セットの総コストとして算出する（ＳＴ２３Ｃ）。

例えば、３人のユーザによって乗合グループを構成され、全員が「同性の方がよい」の条件に対応する迂回時間を１５分に設定し、３人とも女性の場合には、各ユーザのコストは、１５分×２名÷２名＝１５分と算出され、当該乗合グループのコストは１５分となる。３人のユーザのうち、２名が女性であり、１名が男性である場合には、女性のユーザのコストは、（１５×１÷２）−２×（１５×１÷２）＝−７．５分、男性のユーザのコストは、−２×（１５×１÷２）＝−１５分と算出され、当該乗合グループのコストは−１０分となる。

次に、運行予定作成部２４は、総コストが最大となるセットを、乗合の実行に最も適した乗合グループのセット（以下、推奨セット）として選択する（ＳＴ２３Ｄ）。出力が完了する（選択処理を終える）と、運行予定作成部２４は、ステップＳＴ２４を実行する。

次に、運行予定作成部２４は、ステップＳＴ２４において、推奨セットに対応するユーザ毎の運行予定情報を作成し、ユーザ毎の運行予定情報であるユーザ運行予定情報を作成し、乗合情報管理部２５に保存する。保存が完了すると、運行予定作成部２４は、運行予定作成処理を終える。

本実施形態では、ユーザ通知部２９は、通信部１３によって各ユーザ端末２に、対応するユーザ運行予定情報の予約結果に加えて、同乗者それぞれの氏名、出発予定地（乗車地点）、乗車予定時刻、及び、第２乗合条件に対する希望を送信して、ユーザ端末２に表示させる表示処理を実行する。

ユーザ通知部２９は、第２乗合条件の「希望するラジオ局」に入力があったときに、当該ユーザにラジオを車内で聞きたいという希望があるとして、ユーザ端末２に通知するとともに、そのラジオ局で乗合が実行されるときに放送される番組名をユーザ端末２に通知するとよい。

ユーザ端末２は、ユーザ通知部２９から通知を受信すると、予約結果に加えて、同乗者の第２乗合条件の希望を表示する画面（以下、運行情報表示画面）をユーザインタフェース１２に表示する。より具体的には、ユーザ端末２は、運行情報表示画面に、図６に示すように、予約結果に加えて、乗り合うユーザそれぞれの氏名、ユーザの役割（ドライバー、又はライダー）、車両情報、出発予定地（乗車地点）、及び、乗車予定時刻を表示する。更に、ユーザ端末２は、表示画面に、第２乗合条件に対する希望をアイコン３１〜３３として表示する。より具体的には、本実施形態では、運行情報表示画面において、ドライバの予約情報を示す欄が、車内での喫煙を希望しないことを示すアイコン３１とともに表示される。また、ライダーＡ及びＢの予約情報を示す欄にはそれぞれ、車内での会話を希望しないことを示す、読書を示す本を模したアイコン３２が表示される。また、ライダーＡの予約情報を示す欄には、希望するラジオ局への入力があった旨を示すアイコン３３が表示される。また、そのアイコン３３に入力があったときには、運行情報表示画面に、ライダーＢが希望するラジオ局において、乗合が実行されるときに放送される番組名をポップアップによって重ねて表示するとよい。また、ユーザの希望が満たされない場合（たとえば、ユーザが車内での会話を希望し、且つ、乗合グループに車内での会話を希望しない同乗者が多い場合）には、アイコン３３に希望が満たされないことを示す図形３４（本実施形態では斜線）を重ねて表示するとよい。

次に、このように構成した車両乗合支援システム１の効果について説明する。車両乗合支援システム１では、ステップＳＴ２１において、各ユーザに対して、第２乗合条件の希望度に応じて、抽出範囲が設定される。抽出範囲は希望度が高くなる（すなわち、迂回時間が長くなる）につれて広げられる。よって、希望度が高くなり、ユーザの希望に合致する乗合グループが形成され難くなる場合に、抽出範囲が広げられるため、より希望に合致する乗合グループが抽出され易くなる。よって、ユーザから入力された乗合条件に適合する乗合グループのセットが形成され易くなる。

運行予定作成部２４は、乗合グループのセットのそれぞれについて、ユーザの第２乗合条件に対する充足度を算出し、充足度の乗合グループごとの平均値の総和が最大となるセットを推奨されるセットとして選択する。これにより、ユーザの希望がより充足されたセットが推奨されるセットとして出力されるため、ユーザの希望に即した乗合グループが形成されて出力され易くなる。

本実施形態では、第１乗合条件は迂回時間によって定められる。これにより、ユーザは希望度に応じた迂回時間を設定することで、抽出範囲の拡大縮小を容易に行うことができる。また、図４（Ｂ）で表示される選択肢として表示される時間は、迂回時間の上限値よりも小さくなるように設定されている。よって、迂回時間の上限値以下の範囲、すなわち、許容範囲内で、推奨セットが抽出されるため、迂回時間がユーザの意に反して延長されることが防止できる。更に、抽出範囲は、各ユーザが設定した迂回時間（例えば、図４（Ｂ）参照）の最大値によって定められるため、ユーザの想定よりも迂回時間が長い乗合グループのセットが選択されることが防止できる。

図４（Ｂ）に示すように希望度入力画面において、ユーザは「ＯＦＦ」を入力することによって、対応する第２乗合条件が乗合グループの決定の条件とはならないように設定することができる。すなわち、運行予定作成部２４は希望度入力画面においてユーザから「ＯＦＦ」の入力があった（すなわち、抽出条件として使用されることを停止させる停止入力があった）場合には、対応する第２乗合条件（停止入力があった第２乗合条件）による抽出範囲を第１乗合条件の最大の範囲、すなわち、許容範囲に設定する。これにより、ユーザが希望しない第２乗合条件によって抽出される乗合グループのセットの範囲が狭められることが防止できる。よって、ユーザの希望に即さない乗合グループが選択され難くなり、乗合利用者の希望により即した乗合グループが形成されて出力され易くなる。

また、ユーザ通知部２９は、ユーザ端末２に、同乗者の第２乗合条件の希望を表示させる表示処理を実行する。これにより、ユーザ端末２には、同乗者の設定した第２乗合条件の希望が表示される。これにより、ユーザは、ユーザ端末２の表示によって、同乗者が設定した第２乗合条件の希望度を知ることができる。これにより、ユーザが同乗者に対して気遣いをし、同乗者の希望に即した行動を行うことが期待できるため、車内環境の向上を図ることができる。

また、第２乗合条件には、同乗者の性別、希望する車内のラジオ局の選択、及び、車内での会話の有無が含まれる。これにより、ユーザから乗り合う車両の車内環境や、同乗者の属性に係る希望を受け付けることができる。但し、第２乗合条件は、同乗者の性別、希望する車内のラジオ局の選択、及び、車内での会話の有無のすべてが含まれていなくてもよく、いずれかを含んでいればよい。また、第２乗合条件は、希望する車内の音楽、又は、車内の飲食の可否を含んでいてもよい。

＜＜第２実施形態＞＞
第２実施形態に係る車両乗合支援システム１００は、第１実施形態に比べて、受付申込処理のＳＴ１４が異なり、他の構成については第１実施形態と同様であるため、説明を省略する。

申込受付部１５は、ステップＳＴ１４において、第１実施形態と同様に、第２乗合条件についての希望と、その希望が達せられるべき度合いを示す希望度とともに入力される希望度入力画面をユーザインタフェース１２に表示して、ユーザから入力を受け付ける。

申込受付部１５は、各乗合条件に対応する欄（例えば、図４（Ａ）の会話の有無に関するものであることを示す「あまり話をしたくない」の文字が記載された欄）へのタッチを検出すると、図７（Ａ）に示す会話の有無に関する希望度の入力画面（以下、希望度入力画面）をユーザインタフェース１２に表示する。

申込受付部１５は、各乗合条件に対応する欄へのタッチが検出されたときには、タッチ検出された乗合条件を、ステップＳＴ１２において入力されたユーザ自身の属性に関する情報と、ステップＳＴ１３において入力された希望出発地、希望目的地、及び希望出発時間とともに、確率算出情報としてホストサーバ４に送信する。確率算出情報を受信したホストサーバ４は、過去の予約履歴に基づいて、確率算出情報に含まれる乗合条件に対して、ユーザが選択可能な希望度（ＯＮ、ＯＦＦ、１分、２分・・など）に対応する迂回時間を設定したときに、乗合グループを抽出することのできる確率（以下、マッチング確率）を算出する。

より具体的には、ホストサーバ４は、確率算出情報を受信すると、確率算出情報を受信した日の前日から１００日分の過去の予約履歴に基づいて、各希望度に対応する迂回時間に基づいて抽出範囲を設定し、前日からの１００日分の予約履歴のそれぞれに対して、希望出発地、希望目的地、及び希望出発時間を満たす乗合グループを抽出する。その後、ホストサーバ４は、１００日分において乗合グループが抽出できた日の割合をマッチング確率として算出し、ユーザ端末２に送信する。

マッチング確率を受信した申込受付部１５は、図７に示すように、ユーザが選択可能な希望度とともに、受信したマッチング確率を表示する。

次に、このように構成した車両乗合支援システム１００の効果について説明する。図７に示すように、希望度を入力するときに、ユーザは希望度の設定によって、乗合グループの抽出し易さを理解することができる。これにより、ユーザは希望度を設定し易くなる。

＜＜第３実施形態＞＞
第３実施形態に係る車両乗合支援システム２００は、乗合条件（第２乗合条件）の希望度の選択枠（図４（Ａ）参照）に「ＭＡＸ」が入力された（必須入力が行われた）ときの抽出処理、より具体的にはステップＳＴ２２Ｃが異なり、他の構成については第１実施形態と同様であるため、説明を省略する。

運行予定作成部２４は、ステップＳＴ２２Ｃにおいて、実施可能セットに含まれる各乗合グループにおいて、各ユーザについて、希望出発地から希望目的地に直接移動する場合に比べて要する時間、すなわち、迂回時間を算出する。その後、運行予定作成部２４は、各ユーザの迂回時間が抽出範囲内にあるか否かを判定するとともに、選択枠に「ＭＡＸ」を入力したユーザがいる場合には、そのユーザの選択枠に「ＭＡＸ」が入力された乗合条件が満たされているか否かを判定する。その後、運行予定作成部２４は、全てのユーザの迂回時間が抽出範囲内にあり、且つ、選択枠に「ＭＡＸ」を入力したユーザがいる場合には、そのユーザの選択枠に「ＭＡＸ」が入力された乗合条件が満たされているセットを、抽出セットとして抽出する。抽出セットの抽出が完了すると、運行予定作成部２４はステップＳＴ２２Ｃを終える。

次に、このように構成した車両乗合支援システム２００の効果について説明する。必ず満たされることを希望する乗合条件があるユーザが、対応する希望度の選択枠に「ＭＡＸ」を入力すると、抽出処理のステップＳＴ２２Ｃにおいて、対応する乗合条件が満たされているセットが抽出セットとして抽出される。その後、選択処理において、抽出セットの中から、乗合条件に適合する乗合グループのセットが選択されて出力される。よって、出力される乗合グループは、ユーザが満たされることを希望した乗合条件（第２乗合条件）が満たされたものとなるため、ユーザの希望により即した乗合グループが出力され易くなる。

以上で具体的実施形態の説明を終えるが、本発明は上記実施形態に限定されることなく幅広く変形実施することができる。例えば、第２実施形態において、ホストサーバ４は、確率算出情報を受信すると、確率算出情報を受信した日の前日から１００日分の過去の予約履歴に基づいて、出発時刻を変えながら、各希望度に対応する迂回時間に基づいて抽出範囲を設定し、前日からの１００日分の予約履歴を用いて、マッチング確率を算出して、ユーザ端末２に送信してもよい。ユーザ端末２は、図８に示すように、希望の内容を示す欄（「あまり話したくない」と記載された欄）に確率表示ボタンが表示されているとよい。ユーザ端末２は、当該確率表示ボタンにタッチが検出されたときに、希望度を変えたときの出発時刻とマッチング確率との関係を示す時系列グラフをユーザインタフェース１２にポップアップ１０３によって表示するとよい。

また、ホストサーバ４は、確率算出情報を受信すると、受信した日の予約状況（すなわち、現在の予約状況）に基づいて、出発時刻を変えながら、各希望度に対応する迂回時間に基づいて抽出範囲を設定し、抽出範囲内の乗合グループに含まれるユーザの数（以下、マッチング人数）を算出する。その後、ホストサーバ４は、ユーザ端末２に算出されたマッチング人数を送信して、ユーザ端末２のユーザインタフェース１２に作成できたマッチング人数を表示させてもよい（例えば、図９参照）。これにより、ユーザは、希望度の変更によって、乗合グループが抽出され易いかを理解することができる。これにより、ユーザは希望度を設定し易くなる。

上記実施形態において、ステップＳＴ２１において、運行予定作成部２４は、迂回時間の最大値によって抽出範囲を定めていたが、この態様には限定されない。例えば、運行予定作成部２４は、迂回時間の積算によって抽出範囲を定めてもよい。但し、迂回時間の積算値が迂回時間の上限値を超える場合には、迂回時間の上限値に設定するとよい。

上記実施形態において、運行予定作成部２４は、コストに基づいて、推奨セットを選択していたがこの態様には限定されない。例えば、運行予定作成部２４は、充足セットの中から、ユーザの迂回時間の総和が最も小さいものを推奨セットとして選択するように構成されていてもよい。

１ ：第１実施形態に係る車両乗合支援システム
２ ：ユーザ端末（利用者端末）
３ ：ネットワーク
４ ：ホストサーバ（サーバ）
１００ ：第２実施形態に係る車両乗合支援システム
２００ ：第３実施形態に係る車両乗合支援システム
ＳＴ２２ ：ステップ（抽出処理）
ＳＴ２３ ：ステップ（選択処理）

Claims (10)

1. 利用者端末と、前記利用者端末とネットワークを介して接続され、前記利用者端末において乗合利用者から入力された複数の乗合条件に基づいて、推奨される乗合グループのセットを作成して出力するサーバとを有する車両乗合支援システムであって、
   前記乗合条件は、前記乗合利用者から前記利用者端末において許容できる許容範囲が入力される第１乗合条件と、前記乗合利用者からの希望が前記希望に対する希望度とともに前記利用者端末において入力される第２乗合条件とを含み、
   前記サーバは、前記乗合利用者それぞれにおいて、前記第１乗合条件が前記許容範囲内にあり、且つ、前記第２乗合条件の前記希望度に応じて定められる抽出範囲内の前記乗合グループの前記セットを抽出する抽出処理と、抽出された前記セットの中から、入力された前記乗合条件に適合する前記セットを選択する選択処理とを順に実行することを特徴とする車両乗合支援システム。
2. 前記サーバは、前記選択処理において、前記乗合グループの前記セットそれぞれについて、前記乗合利用者の前記第２乗合条件それぞれに対して満たされる度合いを充足度として算出するステップと、
   前記乗合利用者の前記充足度の前記乗合グループそれぞれの平均値の総和が最大となる前記セットを推奨される前記セットとして選択するステップとを順に実行することを特徴とする請求項１に記載の車両乗合支援システム。
3. 前記第１乗合条件は、乗合を利用することによって前記乗合利用者が追加されることを許容する迂回時間であることを特徴とする請求項１又は請求項２に記載の車両乗合支援システム。
4. 前記サーバには、前記迂回時間に係る前記許容範囲が、前記迂回時間の上限値によって入力されることを特徴とする請求項３に記載の車両乗合支援システム。
5. 前記サーバは、所定の前記第２乗合条件に対して所定の停止入力があったときには、前記停止入力に対応する前記第２乗合条件によって定められる前記抽出範囲を、前記許容範囲に設定することを特徴とする請求項１〜請求項４のいずれか１つの項に記載の車両乗合支援システム。
6. 前記サーバは、所定の前記第２乗合条件に対して所定の必須入力があったときには、前記抽出処理において、前記必須入力を行った前記乗合利用者の前記必須入力がされた前記第２乗合条件が満たされる前記乗合グループの前記セットを抽出し、前記選択処理において、抽出された前記セットの中から、入力された前記乗合条件に適合する前記セットを選択することを特徴とする請求項１〜請求項５のいずれか１つの項に記載の車両乗合支援システム。
7. 前記サーバは、前記選択処理の後に、前記乗合利用者の前記利用者端末に、同乗者の前記第２乗合条件の前記希望を表示させる表示処理を実行することを特徴とする請求項２〜請求項６のいずれか１つの項に記載の車両乗合支援システム。
8. 前記サーバは、前記抽出処理において、過去の予約履歴に基づいて、前記希望度に対応する前記抽出範囲を設定し、前記抽出範囲を満たす前記乗合グループを抽出できる確率を算出して、前記利用者端末に表示させることを特徴とする請求項１〜請求項７のいずれか１つの項に記載の車両乗合支援システム。
9. 前記サーバは、前記抽出処理において、現在の予約状況に基づいて、前記希望度に対応する前記抽出範囲を設定し、前記抽出範囲を満たす前記乗合グループに含まれる前記乗合利用者の数を算出して、前記利用者端末に表示させることを特徴とする請求項１〜請求項７のいずれか１つの項に記載の車両乗合支援システム。
10. 前記第２乗合条件は、同乗者の性別、車内の音楽の選択、ラジオ局の選択、会話の有無、車内の飲食の可否のいずれか１つを含む請求項１〜請求項９のいずれか１つの項に記載の車両乗合支援システム。

Images