(57)【要約】【課題】運転の安全を確保しつつ、好適な対象に情報送信を行う。【解決手段】情報処理装置は、第１のユーザの使用する第１の端末から取得した情報に基づき、該第１のユーザが現在車両の運転中であるか否かを判定する。また装置は、第１のユーザの運転する車両に同乗している、第１のユーザとは異なる第２のユーザを特定し、第１のユーザが運転中であると判定した場合に、第１のユーザに通知すべき通知情報を、該第２のユーザの使用する第２の端末に送信する。【選択図】図６
2018074484.tif 000002
【特許請求の範囲】
【請求項１】
第１のユーザの使用する第１の端末から取得した情報に基づき、該第１のユーザが現在車両の運転中であるか否かを判定する判定手段と、
前記第１のユーザの運転する車両に同乗している、前記第１のユーザとは異なる第２のユーザを特定する特定手段と、
前記判定手段により前記第１のユーザが運転中であると判定された場合に、前記第１のユーザに通知すべき通知情報を、前記第２のユーザの使用する第２の端末に送信する通知手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記通知手段は、前記第２の端末に前記通知情報を送信する場合、前記第１の端末における報知を行わせない態様で、前記通知情報を前記第１の端末にも送信することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第１の端末に送信された前記通知情報は、前記判定手段により前記第１のユーザが運転中でないと判定された場合に、前記第１の端末において表示可能に制御されることを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記通知手段は、前記第２の端末に前記通知情報を送信する場合に、前記通知すべき通知情報が前記第２の端末に送信されたことを、該第２の端末が具備する音声出力手段及び前記第１の端末に外部接続された音声出力手段の少なくともいずれかから報知させることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記第１のユーザが運転する車両が、ユーザに通知すべき前記通知情報が確定してから所定の時間内に停止が可能な状況であるか否かを判断する第１の判断手段をさらに有し、
前記通知手段は、前記第１のユーザが運転中であると判定された場合であっても、前記第１の判断手段により前記所定の時間内に停止が可能な状況であると判断される場合には、前記通知情報を前記第２の端末に送信しないことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記通知手段は、前記第１の判断手段により前記所定の時間内に停止が可能な状況であると判断された後、該時間の経過後に車両の停止がなされない場合に、前記通知情報を前記第２の端末に送信する請求項５に記載の情報処理装置。
【請求項７】
前記通知手段は、前記第１のユーザが運転中でないと判定された場合に、前記通知情報を、前記第２の端末には送信せず、前記第１の端末に送信することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
【請求項８】
前記特定手段は、前記第１のユーザが運転する車両につき、同乗が予約されたユーザの情報を取得し、該同乗が予約されたユーザの使用する端末の位置情報に基づき、前記第２のユーザを特定することを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
【請求項９】
車両に乗車しているユーザを、運転者である前記第１のユーザと同乗者である前記第２のユーザとに分類する分類手段をさらに有し、
前記判定手段による判定及び前記特定手段による特定は、前記分類手段の分類結果に基づき行われることを特徴とする請求項１乃至８のいずれか１項に記載の情報処理装置。
【請求項１０】
前記分類手段は、車両の走行中に前記通知手段により送信された所定の通知に対して最初に操作を受け付けた端末のユーザを前記第２のユーザに分類することを特徴とする請求項９に記載の情報処理装置。
【請求項１１】
前記分類手段は、車両の走行中に端末において起動されている所定のアプリケーションが操作を受け付けている状態にある場合に、該端末のユーザを前記第２のユーザに分類することを特徴とする請求項９または１０に記載の情報処理装置。
【請求項１２】
前記第１のユーザと前記第２のユーザにつき、ユーザ間の関係性を評価する評価手段をさらに有し、
前記通知手段は、前記評価手段による評価結果に基づき決定した優先度に従って、複数の前記第２のユーザのうちから前記通知情報を端末に送信する前記第２のユーザを決定することを特徴とする請求項１乃至１１のいずれか１項に記載の情報処理装置。
【請求項１３】
前記通知情報に係る通知は、ユーザによる応答を要件とするものであることを特徴とする請求項１乃至１２のいずれか１項に記載の情報処理装置。
【請求項１４】
前記通知情報に係る通知は、時間的及び地理的の少なくともいずれかに係る応答可能な条件が定められ、
前記通知手段は、前記応答可能な条件を満たす場合に、前記通知情報を送信することを特徴とする請求項１３に記載の情報処理装置。
【請求項１５】
前記通知手段は、車両につき予め設定された運転経路計画及び車両の現在の位置に基づいて前記応答可能な条件を満たすか否かを判断することを特徴とする請求項１４に記載の情報処理装置。
【請求項１６】
前記通知情報に係る通知は、同乗の申込に係る同乗要求を示し、該同乗要求の受け入れ可否をユーザに選択させる通知を含むことを特徴とする請求項１３乃至１５のいずれか１項に記載の情報処理装置。
【請求項１７】
ユーザに情報を通知すべきか否かを判断する第２の判断手段をさらに有し、
前記第２の判断手段は、同乗の申込に係る同乗要求を受信した場合、または応答を要するものとして予め定められた種別のメッセージを受信した場合に、該同乗要求または該メッセージを通知すべきと判断し、
前記通知手段は、前記第２の判断手段により通知すべきと判断された前記同乗要求または前記メッセージに係る前記通知情報を送信することを特徴とする請求項１３乃至１６のいずれか１項に記載の情報処理装置。
【請求項１８】
前記通知情報に係る応答は、該通知情報を受信した端末における入力を要するものであり、
前記情報処理装置は、前記通知情報を送信した端末における入力可否を制御する制御手段をさらに有し、
前記制御手段は、前記判定手段により前記第１のユーザが運転中であると判定されている期間、前記通知手段により前記第１の端末に送信された前記通知情報につき、該第１の端末における入力を受け付けないよう制御することを特徴とする請求項１３乃至１７のいずれか１項に記載の情報処理装置。
【請求項１９】
前記制御手段は、前記第１の端末における入力を受け付けないよう制御した際に、該第１の端末における入力中の情報を取得し、
前記通知手段は、取得された前記入力中の情報と前記通知情報とを前記第２の端末に送信し、
前記制御手段は、前記第２の端末において、前記入力中の情報への追加の入力を受け付けるよう制御することを特徴とする請求項１８に記載の情報処理装置。
【請求項２０】
前記制御手段は、前記判定手段により前記第１のユーザが運転中であると判定されている期間に限り、前記通知手段により前記第２の端末に送信された前記通知情報につき、該第２の端末における入力を受け付けるよう制御することを特徴とする請求項１８または１９に記載の情報処理装置。
【請求項２１】
前記第１の端末により発行された、前記通知情報の受信に係るチケットを取得したことを示すチケット情報を前記第２の端末から受信する受信手段をさらに有し、
前記通知手段は、前記チケット情報を受信した前記第２の端末に前記通知情報を送信することを特徴とする請求項１乃至２０のいずれか１項に記載の情報処理装置。
【請求項２２】
前記チケットは、
前記判定手段による判定が、前記第１のユーザが運転中でない状態から前記第１のユーザが運転中である状態に変化した場合に、前記第１の端末から前記第２の端末に送信され、
前記判定手段による判定が、前記第１のユーザが運転中である状態から前記第１のユーザが運転中でない状態に変化した場合に、前記第２の端末から前記第１の端末に返却される
ことを特徴とする請求項２１に記載の情報処理装置。
【請求項２３】
第１のユーザの使用する第１の端末から取得した情報に基づき、該第１のユーザが現在車両の運転中であるか否かを判定する判定工程と、
前記第１のユーザの運転する車両に同乗している、前記第１のユーザとは異なる第２のユーザを特定する特定工程と、
前記判定工程において前記第１のユーザが運転中であると判定された場合に、前記第１のユーザに通知すべき通知情報を、前記第２のユーザの使用する第２の端末に送信する通知工程と、
を有することを特徴とする情報処理装置の制御方法。
【請求項２４】
コンピュータを、請求項１乃至２２のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラム。
【請求項２５】
ユーザに通知すべき通知情報を、ユーザの使用する端末に送信する通知手段を有する通知システムであって、
第１のユーザの使用する第１の端末から取得した情報に基づき、該第１のユーザが現在車両の運転中であるか否かを判定する判定手段と、
前記第１のユーザの運転する車両に同乗している、前記第１のユーザとは異なる第２のユーザを特定する特定手段と、を有し、
前記通知手段は、前記判定手段により前記第１のユーザが運転中であると判定された場合に、前記第１のユーザに通知すべき通知情報を、前記第２のユーザの使用する第２の端末に送信することを特徴とする通知システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、制御方法、プログラム及び通知システムに関し、特に車両走行時の情報通信技術に関する。
【背景技術】
【０００２】
自動車等の車両の運転において、運転中に運転者が情報通信端末等を操作することは安全の観点で好ましくない。特許文献１には、安全確保のため、運転中に運転者の携帯電話に着信があった場合に、別の電話装置に転送する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−１１９４５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１のように別の装置に着信等の情報を転送する技術では、即時の対応が要求されるような情報に運転者が対応できない可能性があった。一方、例えば運転中の車両に同乗者が存在する状態では、該同乗者が情報通信端末を操作することは可能である。故に、運転者の受信すべき情報を同乗者の操作する端末に転送することで、即時の対応が要求されるような情報も好適に運転者に伝達されることが想定されるが、これまで同乗者という適切な受信者を特定し、運転者が運転中である状況にのみ、該同乗者の端末に情報送信する技術はなかった。
【０００５】
本発明は、上述の問題点に鑑みてなされたものであり、運転の安全性を確保しつつ、好適な対象に情報送信を行う情報処理装置、制御方法、プログラム及び通知システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
前述の目的を達成するために、本発明の情報処理装置は、第１のユーザの使用する第１の端末から取得した情報に基づき、該第１のユーザが現在車両の運転中であるか否かを判定する判定手段と、第１のユーザの運転する車両に同乗している、第１のユーザとは異なる第２のユーザを特定する特定手段と、判定手段により第１のユーザが運転中であると判定された場合に、第１のユーザに通知すべき通知情報を、第２のユーザの使用する第２の端末に送信する通知手段と、を有することを特徴とする。
【発明の効果】
【０００７】
このような構成により本発明によれば、運転の安全を確保しつつ、好適な対象に情報送信を行うことが可能となる。
【図面の簡単な説明】
【０００８】
【図１】本発明の実施形態及び変形例に係る通知システムのシステム構成を例示した図
【図２】本発明の実施形態及び変形例に係る管理サーバ１００の機能構成を例示したブロック図
【図３】本発明の実施形態及び変形例に係る運転者端末２００の機能構成を例示したブロック図
【図４】本発明の実施形態及び変形例に係る同乗者端末３００の機能構成を例示したブロック図
【図５】本発明の実施形態及び変形例に係る通知システムで用いられる各種データのデータ構成を例示した図
【図６】本発明の実施形態１及び変形例に係る管理サーバ１００で実行される通知処理を例示したフローチャート
【図７】本発明の実施形態２及び変形例に係る通知処理を例示したフローチャート
【発明を実施するための形態】
【０００９】
［実施形態１］
以下、本発明の例示的な実施形態について、図面を参照して詳細に説明する。なお、以下に説明する一実施形態は、通知システムの一例として、ユーザ間で行われる「相乗り（または同乗）運転」の予約及び管理を行う、本発明の情報処理装置としての管理サーバと、相乗り運転において車両の運転を行う運転者（第１のユーザ）が使用する、本発明の第１の端末としての運転者端末、及び相乗り運転において車両に同乗する同乗者（第２のユーザ）が使用する、本発明の第２の端末としての同乗者端末で構成される最小構成の通知システムに、本発明を適用した例を説明する。しかし、本発明は、相乗り運転を管理し、運転者及び同乗者への通知を車両の状態に応じて制御することが可能な任意の機器または機器群に適用可能である。また、本明細書において、「運転者」とは、車両を実際に運転するユーザを指し、「同乗者」とは、運転者の運転する車両に実際に乗るユーザであって、運転を行っていないユーザを指すものとして説明する。
【００１０】
《通知システムの構成》
図１は、本発明の実施形態に係る通知システムのシステム構成を示したシステム図である。本実施形態では通知システムの例示として、目的地が同一のユーザ等、運転者が運転する自動車に同乗して目的地まで移動する、所謂相乗り相手を募集するサービスを提供するシステムを用いる。このようなサービスは、ガソリン代や有料道路の利用料金等、移動経費の一部を同乗したユーザから徴収できるよう構成されており、運転者にとっては単独で移動する場合よりも移動経費を削減できる、また同乗するユーザにとっては利便性の高い交通手段を安価に利用できるといった利点がある。
【００１１】
図示されるように、本実施形態では管理サーバ１００と運転者端末２００及び同乗者端末３００とは、ネットワーク４００を介して接続され、情報の送受信が可能に構成される。後述するように、本実施形態では管理サーバ１００が、ユーザ情報の管理、相乗り運転に係るドライブ開始（所定の運転計画に基づく車両の出発）前の相乗りの募集及び予約の管理、ドライブ開始後の実際の相乗りの状況の管理、及び相乗り運転に係る通知の管理の機能を集約して行うものとして説明するが、本発明の実施はこれに限られるものではない。このような機能の一部は、管理サーバ１００と通信可能に構成された他の装置により実現されるよう分離され、管理サーバ１００は該他の装置と協働して動作する態様であってもよい。
【００１２】
また本実施形態では簡単のため、運転者端末２００及び同乗者端末３００には、通知システムにより提供される、相乗り運転に係るサービスを利用するための所定のアプリケーションが格納され、サービス利用中はフォアグラウンドまたはバックグラウンドにて該アプリケーションが起動され、管理サーバ１００との通信が可能なように構成されているものとして説明する。しかしながら、本発明の実施はこれに限られるものではなく、サービス利用に係る各端末での動作は、ブラウジングアプリケーションを介してサイトアクセスすることで行われる等、どのような手法により実現されるものであってもよい。
【００１３】
また本実施形態では、相乗り運転に係る同乗者の募集を行ったユーザが、車両の提供と運転を行う運転者であるものとし、該募集に応じて申込を行い、同乗が確約されたユーザが、同乗者（乗車前は同乗予定者）であるものとし、各ユーザの使用する端末を運転者端末２００、同乗者端末３００として明示的に識別して説明する。
【００１４】
〈管理サーバ１００の構成〉
図２は、本発明の実施形態に係る管理サーバ１００の機能構成を示したブロック図である。なお、各装置の機能構成の説明において同様の機能を実現する構成については、管理サーバ１００、運転者端末２００、同乗者端末３００のいずれの構成であるかを判別可能とするため、各々「管理」、「運転」、「同乗」の接頭文字を付して識別するものとして以下説明する。
【００１５】
管理制御部１０１は、例えばＣＰＵ等であり、管理サーバ１００が有する各ブロックの動作を制御する。具体的には管理制御部１０１は、管理記録媒体１０２に記録されている各ブロックの動作プログラムやサービス提供に係る種々の処理のプログラムを読み出し、管理メモリ１０３に展開して実行することにより各ブロックの動作を制御する。
【００１６】
管理記録媒体１０２は、例えば不揮発性メモリやＨＤＤ等の、格納された情報を恒久的に保持する記録装置である。管理記録媒体１０２は、上記プログラムだけでなく、管理サーバ１００が有する各ブロックの動作において必要となるパラメータ等の情報を記録する。また管理メモリ１０３は、例えば揮発性メモリ等の、格納された情報を簡易にアクセス可能な状態で、一時的に保持する記憶装置である。管理メモリ１０３は、プログラムの展開領域としてだけでなく、各ブロックの動作において出力された中間データ等を一時的に保持する格納領域として用いられる。
【００１７】
ユーザＤＢ１０４は、本実施形態の通知システムが提供する相乗り運転に係るサービスに、運転者、同乗者を問わず「利用ユーザ」として登録されているユーザの各種情報（ユーザ情報）を管理するデータベースである。ユーザ情報は、例えばユーザを識別するユーザＩＤに関連付けて、氏名、年齢、住所、趣味、運転免許の有無、車両所有の有無、車種等の個人情報に加え、サービス利用に用いられる（車両の走行中に携帯されている）端末の情報及び該端末との通信に必要な端末特定のための情報等を含むものであってよい。
【００１８】
予約ＤＢ１０５は、実施が予定される相乗り運転（ドライブ）の各々につき、各種の情報（予約情報）を管理するデータベースである。１回のドライブについての予約ＤＢ１０５への予約情報の追加は、運転者による同乗者募集に係る情報登録がなされたことに応じて行われる。予約情報は、例えば図５（ａ）に示されるように予約情報を識別するための予約ＩＤ５０１に関連付けて、情報登録者（運転者）のユーザＩＤ５０２、ドライブ実施日５０３、出発地、到着地、出発予定時刻、到着予定時刻を含む予定の運転経路計画５０４、同乗者を募集する人数を示す空席数５０５、募集する同乗者の条件等を定める条件情報５０６、同乗予定のユーザまたは同乗の申込が行われているユーザの各種情報を示す同乗者情報５０７、及び該予約情報に係るドライブが実施中であるか否かを示す（例えば論理型の）実施中フラグ（実施中なら真、実施前または実施後なら偽）を管理するものであってよい。ここで同乗者情報５０７は、同乗の申込要求を行ったユーザの各々につき、例えば図５（ｂ）に示されるように同乗者情報５０７を識別するための識別ＩＤ５１１に関連付けて、申込要求を行ったユーザのユーザＩＤ５１２、希望乗車地及び希望降車地を示す同乗区間情報５１３、同乗予定人数５１４、運転者による同乗の許可（同乗予約の確定）がなされたか否かを示す（例えば論理型の）確定フラグ５１５を管理するものであってよい。なお、同乗の許可に係り、確定フラグ５１５を真（ｔｒｕｅ：同乗を許可した状態）に設定可能な同乗者情報５０７の数は、同乗予定人数５１４も考慮して空席数５０５以下の同乗者が確定するよう制御されることは言うまでもない。
【００１９】
ドライブＤＢ１０６は、予約ＤＢ１０５とは異なり、実施されているドライブの各々につき、各種の情報（ドライブ情報）を管理するデータベースである。ドライブ情報は、例えば予約ＤＢ１０５に予約情報が登録されているドライブの実施開始条件が満たされた場合（ドライブ実施日５０３の出発予定時刻となった）、あるいは運転者の使用する運転者端末２００においてドライブの開始申請に係る操作入力がなされたことに応じて、予約情報に基づきドライブＤＢ１０６に登録されるものであってよい。ドライブ情報は、例えば図５（ｃ）に示されるようにドライブ情報を識別するためのドライブＩＤ５２１に関連付けて、運転者に係る運転者情報５２２、同乗者に係る同乗者情報５２３、実際に走行した経路の情報を示す運転経路５２４、及びドライブが完了したか否かを示す（例えば論理型の）完了フラグ５２５を管理するものであってよい。ここで、運転者情報５２２は、運転者のユーザＩＤ５３１に関連付けて、運転者が使用する運転者端末２００から取得された位置情報の履歴を示す端末位置履歴５３２を管理するよう構成されていてよい。対して同乗者情報５２３は、同乗者（同乗の許可がなされたユーザ）のユーザＩＤ５４１に関連付けて、同乗者が使用する同乗者端末３００から取得された位置情報の履歴を示す端末位置履歴５４２に加え、実際に該同乗者が、運転者の運転する車両に乗車した位置や時刻等を示す乗車情報５４３、及び同様に降車した位置や時刻等を示す降車情報５４４を管理するよう構成されていてよい。なお、運転経路５２４は、基本的には運転者端末２００に係る端末位置履歴５３２に基づいて決定されるものであってよく、相乗り運転に係る各同乗者の負担費用（有料高速道路の利用料金やガソリン代等の実費）の確定に用いられる情報である。
【００２０】
判定部１０７は、ドライブＤＢ１０６に情報登録がなされたドライブの各々につき、運転者が車両を運転中であるか否かを判定する。より詳しくは判定部１０７は、該当のドライブ情報に含まれる運転者情報５２２の端末位置履歴５３２のうち、直近の端末位置の時間推移に基づき、車両が走行中と停止中（停車中または駐車中、あるいは一時停止中を含むものであってもよい）のいずれであるか、即ち運転者が運転中であるか否かを判定する。なお、本実施形態では車両の走行状態に応じて運転者が運転中であるか否かを判定するものとして説明するが、運転中であるかの判定基準は、いずれであってもよい。
【００２１】
通知決定部１０８は、相乗り運転の間に運転者に通知すべき情報（通知情報）が生じた場合に、通知を行うか否か、いずれの端末に通知情報を送信するか否かを決定する。
【００２２】
背景技術にて述べたように、運転中の運転者に対する情報送信、特に運転者による運転者端末２００での応答操作を要件とする情報の送信は、運転の安全性の観点では好適ではない。一方で、相乗り運転は公共交通機関のように厳密な運行計画が定められているものではなく、またインターネット上等において同乗者を募るようなケースでは運転者と同乗者に必ずしも面識があるわけでもないため、運転者による応答操作が必要となるようなユーザ間のやり取りが発生し得る。例えば、道路状況や天候に応じた乗車位置や乗車予定時刻の変更、あるいはドライブ開始後の同乗予約のキャンセル等、運転者と同乗者との意思疎通や、ドライブ後の実費精算に影響を及ぼし得る事項につき運転者の意思確認が必要となるようなケースが様々生じ得る。
【００２３】
また運転者としては、自身の実費負担分を低減するとの観点では、空席が少ない状態でドライブを実施できることが好ましい。この点を考慮し、本実施形態の通知システムは、計画されたドライブの開始までに同乗者が確定しなかった空席について、開始後も同乗者の募集を行えるよう構成される。従って、上述したような確定している同乗者とのやり取りだけでなく、ドライブ開始後の同乗の申込に係る同乗要求につき、運転者に可否判断を問い合わせる際にも、運転者による応答操作が必要となる状況が本システムでは発生し得る。
【００２４】
故に、本実施形態では通知決定部１０８は、ドライブ開始後に同乗予約者や他のユーザの使用する端末から、同乗の申込に係る同乗要求を受信した場合、または応答を要するものとして予め定められた種別のメッセージを受信した場合において、運転者に通知すべき通知情報が発生したと判断する。なお、１回のドライブが実施されている間は、例えば運転者が別の日程のドライブにつき同乗募集をしている場合、運転者に同乗申込がなされたことを示す通知等が発生し得るが、このような通知は実施中のドライブに関係ないため、該ドライブの完了後に運転者に通知されたとしても問題がない。従って、通知決定部１０８は、今回のドライブにつき、実施後の同乗申込に係る同乗要求、または同乗予約が確定しているユーザからの上記メッセージを受信した場合のみ、運転者に通知すべきと判断し、通知情報を生成するものとする。
【００２５】
さらに、本実施形態の通知システムでは、このように運転者に通知すべき情報が発生したと判断した場合、運転者の状態も考慮して、より運転が安全に遂行されるよう、通知情報の送信制御を行う。より詳しくは通知決定部１０８は、通知情報の発生時に運転者が運転中であり、かつ運転中の車両に同乗者が存在するのであれば、運転者端末２００ではなく該同乗者の使用する同乗者端末３００に通知情報を送信するよう決定する。このとき通知決定部１０８は、該当のドライブ情報に含まれる同乗者情報５２３を参照し、いずれの同乗者の同乗者端末３００に通知情報を送信すべきか決定する。つまり、通知情報の送信先は、ドライブ情報の同乗者情報５２３に含まれる全ての同乗者（同乗予定者を含む）の同乗者端末３００が対象ではなく、車両に乗っていることが確認された同乗者につき、端末への通知情報の送信を行うよう、通知決定部１０８は決定を行う。運転者の運転する車両に乗っているか否かは、例えば管理制御部１０１がドライブ情報内の端末位置履歴５４２と端末位置履歴５３２の一致度とに基づき、同乗者が運転者の運転する車両に同乗していることを判断したした判断結果に基づき行われるものであってよい。このようにすることで、運転者端末２００への通知情報を送信することで安全運転が妨げられることを回避し、かつ運転者端末２００を介さず運転者と口頭でコミュニケーションをとることが可能な状態にある、車両に同乗中の同乗者によって、運転者の意思を踏まえた通知情報への応答を得ることができる。
【００２６】
通知ＤＢ１０９は、ドライブＤＢ１０６に情報登録がなされたドライブの各々につき、ドライブの実施中に生じた通知情報、及びこれに対してなされた応答入力の情報（応答情報）を、例えばタイムスタンプを関連付けて管理するデータベースである。上述したように運転中の運転者に通知すべき通知情報が生じた場合に、本実施形態の通知システムでは該通知情報を運転者の使用する運転者端末２００ではなく、同乗者の使用する同乗者端末３００に送信し得る。故に、この間運転者は、同乗者端末３００に送信された通知情報及び該通信情報につき入力された応答情報を、自身の運転者端末２００において直接的に確認することが困難であるため、これらの情報のやり取り履歴を確認できるよう、通知ＤＢ１０９にはドライブの実施中に生じた通知情報及び応答情報がドライブＩＤに関連付けて管理される。該情報は、ドライブ完了後、あるいは車両が停止している判断できる状態（停車、駐車）にある場合に、運転者端末２００からの閲覧要求に応じて提供され、運転者端末２００において表示可能に構成される。
【００２７】
管理通信部１１０は、管理サーバ１００が有する通信インタフェースである。管理通信部１１０は、ネットワーク４００を介して他の装置（運転者端末２００及び同乗者端末３００、場合によっては分離された機能を実現する外部装置）と接続し、所定のプロトコルに従った通信方式で、機器間のデータの送受信を行う。
【００２８】
本実施形態ではハードウェアとして管理サーバ１００が備える各ブロックにおいて処理が実現されるものとして説明するが、本発明の実施はこれに限らず、各ブロックの処理は該各ブロックと同様の処理を行うプログラムで実現されてもよい。
【００２９】
〈運転者端末２００及び同乗者端末３００の構成〉
以下、運転者端末２００及び同乗者端末３００の機能構成につき、図３及び図４のブロック図を用いて説明する。本実施形態では、運転者端末２００及び同乗者端末３００が有する基本的な構成は同様であるものとして説明するが、本発明の実施において、運転者端末２００及び同乗者端末３００の構成はこれに限られるものではない。
【００３０】
運転制御部２０１及び同乗制御部３０１は、例えばＣＰＵであり、各々運転者端末２００または同乗者端末３００が有する各ブロックの動作を制御する。具体的には運転制御部２０１及び同乗制御部３０１は、各々の端末が有する運転記録媒体２０２または同乗記録媒体３０２に記録されている、各ブロックの動作プログラムや、通知システムにより提供されるサービスを利用するために必要となるアプリケーションプログラム等を読み出し、それぞれ運転メモリ２０３または同乗メモリ３０３に展開して実行することにより、各端末上において各ブロックの動作制御を行う。なお、サービスを利用するために必要となるアプリケーション（サービスアプリ）の動作については、後述する。
【００３１】
運転記録媒体２０２及び同乗記録媒体３０２は、例えば不揮発性メモリやＨＤＤ等の、格納された情報を恒久的に保持する記録装置である。運転記録媒体２０２及び同乗記録媒体３０２は、上記プログラムだけでなく、各ブロックの動作において必要となるパラメータ等の情報を各々記録する。また運転メモリ２０３及び同乗メモリ３０３は、例えば揮発性メモリ等の、格納された情報を簡易にアクセス可能な状態で、一時的に保持する記憶装置である。運転メモリ２０３及び同乗メモリ３０３は、プログラムの展開領域としてだけでなく、各ブロックの動作において出力された中間データ等を一時的に保持する格納領域として用いられる。
【００３２】
運転位置取得部２０４及び同乗位置取得部３０４は、ＧＰＳ利用等の所定の方式で、各端末の位置情報を取得する。本実施形態の通知システムでは、運転者端末２００及び同乗者端末３００においてサービスアプリが起動あるいはバックグラウンド動作している間、所定の時間間隔で位置情報を取得し、該位置情報を管理サーバ１００に送信する動作が行われる。
【００３３】
運転操作入力部２０５及び同乗操作入力部３０５は、ボタンやタッチパネル等、各端末が備える操作入力に係るユーザインタフェースである。運転操作入力部２０５及び同乗操作入力部３０５は、該ユーザインタフェースに対して操作がなされたことを検出すると、該操作の内容を解析し、操作入力結果として運転制御部２０１または同乗制御部３０１にそれぞれ伝達する。操作入力結果は、例えば端末のオペレーションプログラムやサービスアプリで定められたいずれかの入力イベントと判断されるものであってよい。
【００３４】
運転通信部２０６及び同乗通信部３０６は、それぞれ運転者端末２００または同乗者端末３００が有する通信インタフェースである。本実施形態の通知システムでは、運転者端末２００及び同乗者端末３００は、サービス利用にあたり、特に登録された相乗り運転に係るドライブが開始された後に、管理サーバ１００との通信を行うことが必須となるため、通信インタフェースは不可欠な構成である。運転通信部２０６及び同乗通信部３０６は、ネットワーク４００を介して他の装置（管理サーバ１００、場合によってはネットワーク４００を介さず互いの端末間で、あるいはその他の並行利用すべきサービスを提供する外部装置）と接続し、所定のプロトコルに従った通信方式で、機器間のデータの送受信を行う。
【００３５】
《サービス概要》
ここで、本実施形態の通知システムで提供されるサービスの概要につき、それぞれの利用段階で行われる動作の概要を説明する。
【００３６】
〈同乗者募集（ドライブ開始前）〉
実施を予定する相乗り運転に係る同乗者募集を出発前（実施前）に行う場合、運転者は例えば運転者端末２００を用いてサービスにログインし、ドライブ実施日、運転経路計画、募集人数、募集条件等の必要な情報を登録する。管理制御部１０１は、運転者端末２００からこれらの情報を受信すると、該情報に基づき新たな予約情報を生成し、予約ＤＢ１０５に追加させる。
【００３７】
予約情報が新たに追加されたことに応じて、例えば同乗募集の検索ページからの参照リンクが設定された、利用ユーザに閲覧及び同乗申込を可能ならしめる詳細ページが、該予約情報に基づいて生成される。運転者以外の利用ユーザは、予約状況においてまだ空席が存在する場合、同乗区間情報及び同乗予定人数、またコメント等を詳細フォームに入力することで、同乗申込に係る手続を詳細ページにおいて行うことができる。同乗申込がなされた場合には、管理制御部１０１は該同乗申込に基づき予約情報に同乗者情報５０７を追加し、対応する予約情報のユーザＩＤ５０２により示される運転者に関連付けられた運転者端末２００に、その旨を通知する。このとき運転者は、例えば希望乗車地の条件や公開されている申込者のユーザ情報等を参照し、なされた同乗申込につき同乗を許可するか否かを決定することができる。管理制御部１０１は、同乗可否に係る情報を運転者端末２００から受信すると、申込者の端末に該情報に係る通知を行う。運転者が同乗申込を許可した場合、管理制御部１０１は、該当の同乗者情報５０７の確定フラグ５１５を偽（初期値）から真に変更する。また管理制御部１０１は、予約情報の空席数５０５を該許可した同乗申込に係る同乗予定人数分減算した値に更新する。
【００３８】
〈同乗者募集（ドライブ開始後）〉
既に開始されている相乗り運転に係る同乗者募集を出発後（実施中）も行う場合、即ち、ドライブ開始前までに募集していた人数の同乗者の同乗予約が確定しなかった場合、本実施形態の通知システムで提供されるサービスにおいては、同乗者の募集を継続して行う。つまり、管理制御部１０１は、実施中フラグ５０８が真となっている予約情報についても、空席数５０５が１以上である場合には、例えば同乗募集の検索ページからの参照リンクが設定された、利用ユーザに閲覧及び同乗申込を可能ならしめる詳細ページを保持するよう制御する。運転者と同乗予約の確定している同乗予定者を除いた利用ユーザは、ドライブ開始前と同様に、同乗申込に係る手続を詳細ページにおいて行うことができる。
【００３９】
なお、ドライブ開始後の同乗者募集については、管理制御部１０１は該同乗申込につき同乗を許可するか否かを選択するための通知情報を生成して、後述する通知処理に基づき運転者端末２００または同乗者端末３００に送信する。そして通知情報に対する応答情報（選択結果）を受信すると、管理制御部１０１は同乗申込を行った利用ユーザの端末に対して、その応答情報に基づく通知（同乗可否）を送信する。また管理制御部１０１は、生成した通知情報及び応答情報に基づき通知ＤＢ１０９に情報登録を行う。この他、管理制御部１０１は、応答情報に基づき該当の予約情報の及びドライブ情報の更新（予約情報の空席数５０５及び同乗者情報５０７の更新、ドライブ情報の同乗者情報５２３の更新）も行う。
【００４０】
〈ドライブ実施中〉
上述したように、予約ＤＢ１０５に予約情報が登録されているドライブの実施開始条件が満たされた場合、あるいは運転者の使用する運転者端末２００においてドライブ開始に係る操作入力がなされた場合、管理制御部１０１は該予約情報に基づき、ドライブ情報を生成してドライブＤＢ１０６に追加する。
【００４１】
ドライブが開始されると、例えば運転者端末２００ではサービスアプリが運転者モードにて起動され、常駐状態となる。サービスアプリの起動は、例えばドライブ開始に係る操作入力を運転者端末２００において行う際にユーザによりなされるものであってもよいし、出発予定時刻の所定時間前になった場合に運転者端末２００におけるタスクスケジューラにより、あるいは管理サーバ１００からの起動命令に応じてなされるものであってもよい。サービスアプリは常駐状態となると、所定の時間間隔で運転位置取得部２０４に位置情報（時刻の情報を含む）の取得を行わせ、運転制御部２０１は取得された位置情報を運転通信部２０６を介して管理サーバ１００に送信する。管理制御部１０１は、運転者端末２００から受信した位置情報を、該当のドライブ情報に含まれる運転者情報５２２の端末位置履歴５３２に随時追加していく。
【００４２】
一方、同乗予約が確定している同乗予定者についても、該当の車両に乗車したか否かの把握や、乗降事実を踏まえた公平な実費精算を実現する必要があるため、運転者の運転する車両に実際に乗車した位置や時刻の情報（乗車情報５４３）及び車両から実際に降車した位置や時刻の情報（降車情報５４４）を登録する必要がある。故に、同乗者端末３００においても、サービスアプリが同乗者モードにて起動され、常駐状態となる。サービスアプリの起動は、例えば該当の車両に乗車したことを示す操作入力を同乗者端末３００において行う際にユーザによりなされるものであってもよいし、乗車予定時刻の所定時間前になった場合に同乗者端末３００におけるタスクスケジューラにより、あるいは管理サーバ１００からの起動命令に応じてなされるものであってもよい。サービスアプリは常駐状態となると、所定の時間間隔で同乗位置取得部３０４に位置情報の取得を行わせ、同乗制御部３０１は取得された位置情報を同乗通信部３０６を介して管理サーバ１００に送信する。管理制御部１０１は、同乗者端末３００から受信した位置情報を、該当のドライブ情報に含まれる同乗者情報５２３のうち、同乗者端末３００を使用するユーザのユーザＩＤ５４１が関連付けられた端末位置履歴５４２に随時追加していく。
【００４３】
なお、管理制御部１０１は、乗車したことを示す操作入力が同乗者端末３００においてなされたことに応じて受信された位置情報に基づき、同乗者に係る乗車情報５４３の入力を行うものであってよい。または、該当の車両への乗車したことを示す操作入力を同乗者端末３００において必要としない構成の場合、あるいは必要とする構成であったとしても乗車が確実に行われたかを判別するために、管理制御部１０１は、端末位置履歴５３２と該当の端末位置履歴５４２との位置情報の推移の一致度に基づき、該同乗者に係る乗車情報５４３を入力するものであってもよい。
【００４４】
また該当の車両から降車についても、降車したことを示す操作入力が同乗者端末３００においてなされた際に対応して受信された位置情報に基づき、管理制御部１０１は同乗者に係る降車情報５４４の入力を行うものであってよい。または、該当の車両から降車したことを示す操作入力を同乗者端末３００において行わない場合、あるいは行ったとしても後者が確実に行われたかを判別するために、管理制御部１０１は、端末位置履歴５３２と該当の端末位置履歴５４２との位置情報の推移の一致度に基づき、該同乗者に係る降車情報５４４を入力するものであってもよい。
【００４５】
なお、本実施形態では管理制御部１０１が、運転者に係る端末位置履歴５３２と同乗者に係る端末位置履歴５４２との一致度をもって判断するものとして説明するが、本発明の実施はこれに限られるものではない。即ち、同乗しているか否か、あるいは乗車したか降車したかは、必ずしも位置情報の推移で判断する手法に限られず、例えば車両に搭載された所定のビーコンや運転者端末２００から定期的に発生される信号を、所定回数受信した、あるいは所定期間内に受信していることをもって、管理制御部１０１が同乗していると判断する等、どのような手法が用いられてもよいことは言うまでもない。
【００４６】
《通知処理》
上述のような構成を有する本実施形態の管理サーバ１００で実行される、通知情報の送信に係る通知処理について、図６のフローチャートを用いて具体的な処理を説明する。該フローチャートに対応する処理は、管理制御部１０１が、例えば管理記録媒体１０２に記憶されている対応する処理プログラムを読み出し、管理メモリ１０３に展開して実行することにより実現することができる。なお、本通知処理は、例えばドライブ開始後に、運転者に通知すべき通知情報が生じたと判断した際に開始されるものとして説明する。以下では簡単のため、同時並行して実施され得るドライブのうち、１つのドライブ情報に係り実施中のドライブについて行われる通知処理について説明する。
【００４７】
Ｓ６０１で、管理制御部１０１は、現在運転者が運転中であるか否かを判断する。具体的には管理制御部１０１は、判定部１０７による判定結果に基づき本ステップの判断を行う。管理制御部１０１は、現在運転者が運転中であると判断した場合には処理をＳ６０２に移し、運転中でないと判断した場合には処理をＳ６０６に移す。
【００４８】
Ｓ６０２で、管理制御部１０１は、運転中の車両に同乗者が存在するか否かを判断する。車両に同乗している同乗者は、例えば該当のドライバ情報の同乗者情報５２３に含まれる各ユーザの情報が、乗車情報５４３に乗車位置等の情報が格納され、降車情報５４４が初期値（あるいはnull）である状態であるかによって特定される。管理制御部１０１は、同乗者が存在すると判断した場合は処理をＳ６０３に移し、存在しないと判断した場合は処理をＳ６０５に移す。
【００４９】
Ｓ６０３で、通知決定部１０８は、運転中の車両に同乗していると特定された同乗者のうちから、同乗者端末３００に通知情報を送信する同乗者を決定する。通知情報を送信する同乗者を、管理制御部１０１により車両に同乗していることが特定された同乗者の一部とするか全部とするかは、例えば運転者によって事前に定められる、あるいは通知システムで定められた条件に従うものであってよい。
【００５０】
Ｓ６０４で、通知決定部１０８は、送信対象の通知情報を管理通信部１１０に伝送し、Ｓ６０３において決定した同乗者の同乗者端末３００に対して該通知情報を送信させ、本通知処理を完了する。
【００５１】
一方、Ｓ６０２において同乗者が存在しないと判断された場合、通知決定部１０８はＳ６０５で、運転が停止したと判断されるまで待機して、送信対象の通知情報を管理通信部１１０に伝送し、運転者の運転者端末２００に対して該通知情報を送信させ、本通知処理を完了する。
【００５２】
またＳ６０１において運転中でないと判断された場合、通知決定部１０８はＳ６０６で、送信対象の通知情報を管理通信部１１０に伝送し、運転者の運転者端末２００に対して該通知情報を送信させ、本通知処理を完了する。
【００５３】
このようにすることで、本実施形態の通知システムによれば、運転者の運転中に該運転者に通知すべき情報が発生した場合であっても、同乗者の有無に応じて適切な端末に通知情報を送信することができ、通知が運転に与える影響を低減しつつ、該通知情報に対して応答がなされるまでの時間を短縮することができる。
【００５４】
なお、本実施形態では運転者が運転中であると判定された場合には、通知情報は運転者端末２００ではなく同乗者の同乗者端末３００に送信するものとし、運転者は車両停止後に通知ＤＢ１０９に格納された通知情報及び応答情報の履歴を確認できる態様について説明した。この場合、通知情報を受信した同乗者端末３００を使用する同乗者が、運転者に対して受信したことを口頭で伝えなければ運転者が応答のやり取りを確実に把握できない可能性がある。このため、例えば同乗者端末３００に通知情報が送信された場合には、同乗者端末３００の有するスピーカ、あるいは運転者端末２００と外部接続された例えば車載スピーカ等から、通知情報が同乗者に送信されたことを示す音声出力を行うよう、構成されるものであってもよい。
【００５５】
また、本発明の実施はこれらに限られるものではなく、例えば通知情報を同乗者端末３００に送信する場合であっても、通知情報は運転者端末２００にも送信されるものとしてもよい。この場合、運転者の運転の妨げにならないよう、運転者端末２００における通知情報の受信に係る所定の報知（着信音の音声出力、振動子の駆動等）が行われない態様で、通知情報は送信されればよい。より詳しくは、通知決定部１０８により報知を行わない旨の制御命令を関連付けた通知情報が送信されることにより実現されてもよいし、あるいは通知システムにおいて運転中と判定されていることを示す情報を運転者端末２００に送信し、運転者端末２００上で起動しているサービスアプリの処理において、運転中との判定期間中に受信した通知情報については報知を行わない動作が実現されるものであってもよい。さらに運転者端末２００が受信した通知情報については、運転中でなくなったと判定されるまでは、内容確認に係る表示を不能にする、即ち応答不可能に制御を行わせるものであってもよい。
【００５６】
また、本実施形態ではドライブ開始後にも車両に空席が存在する、即ち募集人数の同乗者がドライブ開始前に確定しなかった場合、同乗要求を受信したことに応じて通知情報を生成し、運転者端末２００または同乗者端末３００に送信するものとして説明したが、本発明の実施はこれに限られるものではない。特に長距離の運転経路計画に基づきドライブが行われる場合等、経路に含まれている地点からの同乗申込に係る要求がなされたとしても、例えば既に該地点を通過している、該地点を経由することで予定していた時刻までに到着地に到達することが困難になる、あるいは該地点には到達していなくとも、通知を行ってから応答が得られるまでに現在の走行速度で走行すれば該地点を通過してしまう等、通知情報を送信したとしても、同乗を希望するユーザにとって好ましい応答情報が得られない可能性がある。また、車両の運転者や同乗者にとっても、受け入れが困難な同乗要求に係る通知情報を頻繁に受信することは好適でない。
【００５７】
従って、通知決定部１０８は、ドライブ開始後になされた同乗要求については、例えば該要求に係る通知情報を送信することで応答が可能であるかを判断し、送信の有無を決定するように構成してもよい。同乗要求に係る応答可能な条件は、例えば同乗を希望するユーザの乗車希望地や車両の現在位置等の地理的な条件や、同乗を希望するユーザの乗車希望時刻や車両の乗車希望地に到達するまでに要する予想時間等の時間的な条件、あるいはこれらを複合的に考慮して定められるものであってよい。また車両側につき判断される条件は、例えば運転経路計画にさらに経路変更（迂回や経由地変更等）の許容度も含めて運転者に設定させるものであってもよい。この場合、同乗要求を受信した際の車両の現在位置と、該現在位置からの経路変更も含めた運転経路計画に基づき、応答可能な条件を満たすか否かを判断すればよい。
【００５８】
以上説明したように、本実施形態の通知システムによれば、運転者の状態を考慮して応答が必要な通知情報の送信先が制御できるため、運転の安全性を確保しつつ、動的な利用希望に柔軟に対応できる相乗り募集の仕組みを実現することができる。より詳しくは、本来運転者に通知されるべき通知情報に対する代理の応答権限を、運転中は同乗者に与えることで応答がなされるまでの時間を低減することができ、例えばドライブ開始後になされた同乗要求に対しても好適に対応することが可能になる。
【００５９】
［実施形態２］
上述した実施形態１では、運転者が運転中かつ同乗者が存在する場合に、通知情報に係る通知に対する応答につき、代理の応答権限を送信先の同乗者端末３００の同乗者に与える態様について説明した。一方で、通知がなされた後にも車両の運転状況は変化し得るものであり、例えば運転中でなくなった場合には運転者は運転者端末２００を操作可能であるため、応答の権限は同乗者から運転者に移されることが好ましい。また例えば運転中でないときに通知情報を運転者端末２００に送信したが、その後応答がなされる前に運転中となった場合には、運転者端末２００においてのみ通知に対する応答が可能な状態では安全な運転が担保されない、あるいは通知に対する応答がなされるまでの時間が長期化し得るため、同乗者が応答の権限を有していることが好ましい。
【００６０】
故に、本実施形態の通知システムでは、通知処理における通知情報の発生時に加え、応答までの間に生じた運転状況の変化を考慮し、通知情報の送信及び送信した端末における通知に対する応答可否の制御を動的に行う態様について説明する。なお、本実施形態の通知システムにおける管理サーバ１００、運転者端末２００、同乗者端末３００の機能構成は実施形態１と同様であるものとして説明を省略する。また簡単のため、本実施形態の運転者端末２００及び同乗者端末３００において実行されるサービスアプリにおける、通知情報に対する応答を含む操作（入力）の可否は、管理サーバ１００より送信される命令に応じて制御されるものとして説明するが、運転者端末２００及び同乗者端末３００における操作可否は、本実施形態で説明する以外の態様（後述の変形例１等）で制御されるものであってもよい。
【００６１】
《通知処理》
以下、本実施形態の管理サーバ１００で実行される通知処理について、図７のフローチャートを用いて具体的な処理を説明する。なお、実施形態１の通知処理と同様の処理を行うステップについては、同一の参照符号を付して説明を省略し、以下では本実施形態特有の動作を行うステップの処理について説明する。また、本実施形態の通知処理も実施形態１と同様に、ドライブ開始後に、運転者に通知すべき通知情報が生じたと判断した際に開始されるものとして説明する。
【００６２】
Ｓ６０３において同乗者端末３００に通知情報を送信する同乗者を決定した後、通知決定部１０８はＳ７０１で、送信対象の通知情報を管理通信部１１０に伝送し、送信先に決定した同乗者端末３００に対して、該通知情報とともに該同乗者端末３００における応答に係る操作を可能にせしめる制御命令を送信させる。該制御命令は、同乗者端末３００において受信された場合に、同乗者端末３００において該通知情報に係る通知に対する応答操作をサービスアプリ上で同乗者に可能ならしめるものである。一方、本ステップにおいて通知決定部１０８は、運転者端末２００に対しては、運転者端末２００における応答に係る操作、あるいはサービスアプリに係るいずれの操作も不可能にせしめる制御命令を管理通信部１１０に送信させる。このようにすることで、管理サーバ１００を介して運転者の有する応答権限の同乗者への一時的な移譲を実現する。
【００６３】
Ｓ７０２で、管理制御部１０１は、Ｓ７０１において送信させた通知情報に係る応答情報を、該送信の対象である同乗者端末３００から受信したか否かを判断する。管理制御部１０１は、通知情報に係る応答情報を同乗者端末３００から受信したと判断した場合は本通知処理を完了し、まだ受信していないと判断した場合は処理をＳ７０３に移す。
【００６４】
Ｓ７０３で、管理制御部１０１は、運転者が運転中でなくなったか否か、即ち車両が停止していると判断する状態になったか否かを判断する。管理制御部１０１は、運転者が運転中でなくなったと判断した場合は処理をＳ７０４に移し、まだ運転者が運転中であると判断した場合は処理をＳ７０２に戻す。
【００６５】
Ｓ７０４で、通知決定部１０８は、送信対象の通知情報を管理通信部１１０に伝送し、運転者端末２００に対して、該通知情報とともに運転者端末２００における応答に係る操作を可能にせしめる制御命令を送信させる。一方、通知決定部１０８は、通知情報の送信先である同乗者端末３００に対しては、該同乗者端末３００における応答に係る操作を不可能にせしめる制御命令を管理通信部１１０に送信させる。このようにすることで、管理サーバ１００を介して同乗者に一時的に移譲されていた応答権限の運転者への返却が実現される。即ち、本通知システムによれば、運転者の運転中に通知情報が発生してから、運転者が運転中であると判定される期間に限定して、運転者からの同乗者への応答権限の移譲が一時的になされる。
【００６６】
Ｓ７０５で、管理制御部１０１は、Ｓ７０４において送信させた通知情報に係る応答情報を、運転者端末２００から受信したか否かを判断する。管理制御部１０１は、通知情報に係る応答情報を運転者端末２００から受信したと判断した場合は本通知処理を完了し、まだ受信していないと判断した場合は処理をＳ７０６に移す。
【００６７】
Ｓ７０６で、管理制御部１０１は、運転者が運転中となったか否か、即ち車両が停止していると判断する状態から走行状態になったか否かを判断する。管理制御部１０１は、運転者が運転中となったと判断した場合は処理をＳ６０２に移し、運転者が運転中でないままであると判断した場合は処理をＳ７０５に戻す。このようにすることで、運転者が再び運転中となった場合に、再度同乗者への応答権限の移譲を行うことができる。
【００６８】
なお、Ｓ６０１における判断において現在運転者が運転中でないと判断した場合、管理制御部１０１は処理をＳ７０４に移せばよい。この場合、まだ応答権限の同乗者への移譲は行われていない状態ではあるが、同様に応答操作に係る制御命令を同乗者端末３００に送信したとしても、処理上問題となることはない。
【００６９】
このようにすることで、運転者が運転中であれば、通知情報に係る通知が同乗者に行われ、かつ該通知に対する応答権限を同乗者に一時的に移譲し、その後運転者が運転中でなくなった場合には、応答権限は戻され、運転者が通知を確認して応答を行うよう、制御することができる。故に、同乗者端末３００に対して送信された通知情報に対して運転者自ら応答を行いたい場合には、運転者が車両を停止させれば再度通知情報が運転者端末２００に対して送信され、（同乗者が応答不能な状態となった上で）運転者が応答を行うことができる。また、運転者が運転中でない場合に運転者端末２００に対してなされた通知について、その後応答を行わないまま運転中となった場合であっても、再度通知情報が同乗者端末３００に対して送信され、同乗者が代理に応答を行うことができるため、通知に対する応答がなされるまでの時間が長期化し得ることを回避することができる。
【００７０】
なお、本実施形態の通知処理では、運転状態が変化したことに応じて、状態変化前に通知情報を送信した端末とは異なる端末に通知情報の再送が行われ、再送した端末において該通知情報に対する応答操作を可能とする構成について説明したが、本発明の実施はこれに限られるものではない。例えば、運転状態の変化に伴って、端末が応答操作が可能な状態から不可能な状態に制御される場合、該端末において応答に係り入力中であった情報を管理サーバ１００に送信させるよう、操作を不可能にせしめる制御命令を構成し、代替として通知情報が再送される端末には、該入力中であった情報を含めて通知情報を送信するように構成することで、入力を引き継いだ状態から応答に係る操作を始められるようにしてもよい。このとき、運転者端末２００における入力も同乗者端末３００における入力も、他方の端末に引き継がれた場合に編集等可能に構成されるものであってよいが、例えば運転者により入力された情報は確定した応答内容とし、同乗者端末３００に通知情報が送信された場合には、入力中の情報に対する追加の入力のみ受け付けるよう制御するように構成してもよい。
【００７１】
［変形例１］
上述した実施形態２では、通知情報に対する応答操作の入力可否を、管理サーバ１００側において全て制御するものとして説明したが、本発明の実施はこれに限られるものではない。例えば、通知に対する応答権限は、運転者端末２００と同乗者端末３００との間で行われた通信を基準に制御されるものであってもよい。本変形例では、応答権限は運転者端末２００により発行される、所定のビット数のコードを有して構成されるチケットを所有している端末に与えられるものとして説明する。即ち、端末において起動されているサービスアプリはチケットを保有しているかによって、通知情報に対する応答操作が可能であるか否かを判断し、処理を行うよう構成されているものとする。
【００７２】
チケットは運転者端末２００と同乗者端末３００との間で直接やり取りがなされるものであり、例えば応答権限を同乗者に移譲する場合には、運転者端末２００で実行されるサービスアプリにおいて予め設定された同乗者端末３００に送信され、該同乗者端末３００からチケットを取得した（保有している）ことを示す情報（チケット情報）が管理サーバ１００に送信される。また、同乗者から運転者に応答権限が戻される場合には、チケットは保有している同乗者端末３００から運転者端末２００に返却（返送）され、運転者端末２００からチケット情報が管理サーバ１００に送信される。このようにすることで、管理制御部１０１が、１つのドライブ情報に係りいずれの端末が現在応答権限を有しているかを把握でき、通知決定部１０８がいずれの端末に通知情報を送信すべきかを容易に特定できる。
【００７３】
運転者端末２００と同乗者端末３００との間のチケットの送受信は、管理サーバ１００の判定部１０７による判定結果に変化が生じたことに応じて行われる。具体的には、運転者が運転中でない状態から運転中である状態に判定結果が変化した場合、管理制御部１０１は管理通信部１１０を介して運転者端末２００に、運転中になったと判定したことを示す情報、あるいはチケットの送信命令を送信し、運転制御部２０１はこれに応じて予め設定された同乗者端末３００に対して機器間通信にてチケットを送信する。また運転者が運転中である状態から運転中でない状態に判定結果が変化した場合、管理制御部１０１は管理通信部１１０を介して現在チケットを保有している同乗者端末３００に、停止した状態になったと判定したことを示す情報、あるいはチケットの返却命令を送信し、同乗制御部３０１はこれに応じて運転者端末２００に対して機器間通信にてチケットを返送する。
【００７４】
このようにすることで、例えば通知情報が運転者端末２００に送信され、応答がなされないまま運転中に運転状態が変化した場合であっても、運転者端末２００はチケットを保有していないため、運転者端末２００は応答操作を受け付けない状態に制御することができる。また通知情報を運転者端末２００及び同乗者端末３００に同時に送信する構成とした場合であっても、運転状態の変化に応じて端末間でチケットのやり取りが行われるため、管理サーバ１００において応答権限の制御を設定するための制御を行わずとも、実施形態２と同様の効果を得ることができる。また、本変形例のように構成することで、運転者が設定した同乗者であり、かつ機器間通信が可能な距離に存在する同乗者端末３００を使用する同乗者に応答権限が移譲されるため、例えば信頼できる同乗者等に応答を任せ、運転者はより運転に集中することができる。
【００７５】
なお、チケットには応答期限が設定されていてよく、例えば該応答期限がチケット情報に含まれて送信され、管理制御部１０１は、例えば該応答期限に到達した後に通知情報が生じた際に判定部１０７による判定結果を運転者端末２００に送信して、再度のチケット発行に係る各動作の実行を促し、その後のチケット情報の受信に応じて通知情報の送信制御を行えばよい。
【００７６】
［変形例２］
上述した実施形態１及び２では、運転者に対して通知すべき情報が発生した場合、運転者が運転中であれば同乗者端末３００に通知情報を送信するものとして説明したが、本発明の実施において、運転中であるとの判定後、直ちに通知情報が同乗者端末３００に送信されなくともよい。
【００７７】
例えば、通知情報が生じた時点で、予約情報で設定されている他の同乗予定者の希望乗車地や、運転経路計画で設定された休憩地点等の、停止が予定されている位置まで所定の時間内で到達可能な場合、あるいは車両が走行中の道路において所定の時間内に停車が可能（一般道を走行中である、高速道路であってもＳＡ／ＰＡに到達可能である等）、または（車線変更や進行速度等の要素の変化から）車両が所定の時間内に停車するものと推定される場合、通知決定部１０８は通知情報の送信先の決定及びその送信を、通知情報の発生から所定の時間待機するよう構成してもよい。この場合、所定の時間が経過するまでに車両が停止している状態とならなかった場合には、通知決定部１０８はその時点で通知情報を同乗者端末３００に送信し、所定の時間が経過するまでに車両が停止している状態となった場合には、通知決定部１０８は通知情報を運転者端末２００に送信するよう構成すればよい。このようにすることで、運転者が応答可能な状況では可能な限り運転者による応答操作がなされるようにし、応答が困難な状況でのみ同乗者による応答操作がなされるように、通知情報の送信を制御することができる。
【００７８】
［変形例３］
上述した実施形態と変形例では、同乗募集を行ったユーザ（募集ユーザ）が運転者であることを前提として説明したが、実際に運転を行っているユーザは、例えば同乗募集に応募したユーザ（応募ユーザ）や同乗募集前から募集ユーザ以外に乗車が確定していた（空席として登録されなかった人数分の）ユーザ（確定ユーザ）等、必ずしも募集ユーザでない可能性がある。本変形例では、このようなケースも想定し、真の運転者であるユーザを特定し、運転中、該ユーザが使用する端末に通知がなされないよう、好適に制御する態様について説明する。
【００７９】
例えば、管理制御部１０１は、ドライブの開始時や運転者の変更が行われ得る停止が行われたと判断できる状況において、車両に乗車している各ユーザの使用する端末（通知すべき内容である必要はない）所定の通知を送信し、該通知に対する応答の受信に応じて乗車しているユーザを、運転者（または運転者である可能性が高いと判断されるユーザ）と同乗者のいずれかに分類すればよい。分類は、例えば所定の通知から予め定められた時間内に応答操作がなされた、あるいは所定の通知がなされた際や通知情報が発生した際にサービスアプリにおいて（通知とは無関係に）操作を受け付けている状態にある場合に、該端末のユーザを同乗者に分類し、残りのユーザを運転者に分類するものであってよい。また前者の場合、安全性を担保するため、同乗者に分類されたユーザのうちから通知を行う対象は最初に応答操作がなされた端末を使用するユーザとしてもよい。また、このような端末の使用状態に基づく分類は、定期的に行われ、更新されるものであってよい。
【００８０】
さらに、このような分類は、ユーザにつき登録された情報を参照して行われるものであってもよい。例えば、管理制御部１０１はユーザＤＢ１０４に登録された属性情報に基づき、車両運転免許証を有していない場合は該ユーザを同乗者に分類、運転免許証を取得可能な年齢未満のユーザは同乗者に分類、車両保険の適用範囲が所有者に限られる場合は募集ユーザのみを運転者に分類等、端末の使用状況に限らず分類を行ってもよい。
【００８１】
この他、管理制御部１０１が同乗者に分類されるユーザにつき、例えば確定ユーザ中に家族や知人である、あるいは既に複数回のドライブにて募集ユーザと同乗している等、募集ユーザとの関係性を評価した結果に基づき応答権限の移譲に係る優先度（家族を優先する、同乗回数の多いユーザを優先する等）を定め、通知決定部１０８が該優先度に従い通知情報を送信する同乗者端末３００を決定する構成としてもよい。
【００８２】
［変形例４］
これまで通知情報は特定の端末に送信するものとして説明したが、例えば予約情報生成時等、事前に車両に乗車するユーザにつきグループチャットを設け、ドライブ開始後の同乗申込を行ったユーザをグループチャットに追加し、チャットにおける発言の態様で通知情報の送信を行うものとしてもよい。この場合、チャットでのやり取りを経て、同乗の可否を応答として決定する構成としてよく、該最終決定の応答権限が運転状態に応じて変化するよう構成されてよい。該態様によれば、申込ユーザを実際に車両に同乗させる前に、例えば既に乗車しているユーザとの相性等、グループチャットにおいて申込ユーザの情報をある程度把握することができるため、同乗を許可するか否かの判断に役立てることができる。
【００８３】
［その他の実施形態］
本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。また本発明に係る情報処理装置や通知システムは、１以上のコンピュータを該情報処理装置やシステムの構成機器として機能させるプログラムによっても実現可能である。該プログラムは、コンピュータが読み取り可能な記録媒体に記録されることにより、あるいは電気通信回線を通じて、提供／配布することができる。
【符号の説明】
【００８４】
１００：管理サーバ、１０１：管理制御部、１０２：管理記録媒体、１０３：管理メモリ、１０４：ユーザＤＢ、１０５：予約ＤＢ、１０６：ドライブＤＢ、１０７：判定部、１０８：通知決定部、１０９：通知ＤＢ、１１０：管理通信部、２００：運転者端末、２０１：運転制御部、２０２：運転記録媒体、２０３：運転メモリ、２０４：運転位置取得部、２０５：運転操作入力部、２０６：運転通信部、３００：同乗者端末、３０１：同乗制御部、３０２：同乗記録媒体、３０３：同乗メモリ、３０４：同乗位置取得部、３０５：同乗操作入力部、３０６：同乗通信部
【図１】
2018074484.tif 000003
【図２】
2018074484.tif 000004
【図３】
2018074484.tif 000005
【図４】
2018074484.tif 000006
【図５】
2018074484.tif 000007
【図６】
2018074484.tif 000008
【図７】
2018074484.tif 000009