JP6881609B2 - 車両管理システム、車両管理装置、及び車両管理方法 - Google Patents

Description

本発明は、車両管理システム、車両管理装置、及び車両管理方法に関するものである。
本出願は、２０１７年１２月２７日に出願された日本国特許出願の特願２０１７−２５２０３４に基づく優先権を主張するものであり、文献の参照による組み込みが認められる指定国については、上記の出願に記載された内容を参照により本出願に組み込み、本出願の記載の一部とする。

モバイルデバイスから注文を行う注文方法であって、１以上の施設の周囲における道路の状態を示すコンテキスト情報をネットワークを介して取得するステップと、前記１以上の施設のうち、最も近い施設を、前記モバイルデバイスの現在の位置および前記コンテキスト情報に基づいて選択するステップと、前記モバイルデバイスにより、前記ネットワークを介して、選択した前記最も近い施設に対して前記注文を送信するステップと、を備え、顧客の位置情報を使用し、その顧客の期待される到着時刻に基づいて、ちょうどのタイミングで注文処理をスケジュールする注文方法が知られている（特許文献１）。

特開２０１６−１８４４１０号公報

しかしながら、上記の注文方法では、施設における店舗に空席があるとは限らないため、ユーザが、期待される到着時刻で施設に到着しても、注文したサービス等を受けることができない可能性がある。

本発明が解決しようとする課題は、車両が希望施設に到着するタイミングに合わせて、施設内でサービス等を受けることができる車両管理システム、車両管理装置、及び車両管理方法を提供することである。

本発明は、ユーザの端末機２から、当該ユーザが希望する希望施設を決定するために必要な希望情報を、サーバ１にて取得し、取得された希望情報に基づき車両の目的地を設定し、希望施設の空き状況を示す情報を含む施設情報を、サーバ１にて取得し、施設情報に基づき車両の走行を管理して、車両が目的地に到着する到着時刻を調整することによって、上記課題を解決する。

本発明によれば、車両利用サービスの利用率の向上を図ることができる。

本発明に係る車両管理システムの一実施の形態を示すブロック図である。 図１の車両管理システムにて実行される情報処理手順を示すフローチャートである。 図１のコミュニティ生成部にて生成される希望体験リストの一例を示す図である。 図１の目的地提案部にて実行される目的地候補の検索結果の一例を示す図である。 図１の目的地提案部からユーザの端末機に送信される提案情報の一例を示す図である。 図１の配車スケジュール生成部にて生成される配車スケジュールの一例を示す図である。 図１の自動運転制御部から輸送サービス用車両（自動運転車）に送信された配車スケジュールに基づいた走行ルートの一例を示す図である。 図１の車両管理システムにて実行される情報処理手順を示すフローチャートである。 図１の車両管理システムにて実行される情報処理手順を示すフローチャートである。 図１のサーバで管理される施設情報の一例を示す図である。 図１の車両管理システムにて実行される情報処理手順を示すフローチャートである。

以下、本発明に係る車両管理システムの一実施の形態を図面に基づいて説明する。図１は、本発明の一実施の形態に係る車両管理システムを示すブロック図であり、本実施形態のシステムは、サーバ１と、複数のユーザの端末機２と、電気通信回線網を構成するネットワーク３と、一又は複数の輸送サービス用車両４とを含む。本実施形態のシステムは、ユーザにより指定された条件から、ユーザが希望する希望施設を決定し、ユーザを目的地に運ぶために輸送サービス用車両４を配車する。そして、希望施設の現在の空き状況を示す情報を含む施設情報を取得し、目的地に到着したユーザが希望施設で長時間待つことがないように、空き状況に応じて、輸送サービス用車両４の走行を管理することで、目的地の到着時刻を調整するものである。

ユーザが希望する希望施設の決定方法は、例えば、ユーザが移動端末を操作して、具体的な施設（特定のレストラン、アミューズメント施設、ショッピング施設等）を選択できる場合には、サーバ１が、ネットワーク３を介して、選択された希望施設に関する希望情報を取得し、取得された希望情報に基づき、希望施設を決定すればよい。そして、希望施設の位置又は希望施設の周囲の位置が、輸送サービス用車両４の目的地に決まる。

一方、希望施設は必ずしもユーザにより選択される必要はなく、例えば、以下の方法で、ユーザの希望条件に基づき、希望施設を決定してもよい。なお、以下では、希望施設の位置を、輸送サービス用車両４の目的地とした上で、実施形態を説明するが、輸送サービス用車両４の目的地は、希望施設の位置の周囲であって、輸送サービス用車両４の駐停車に適した位置としてもよい。例えば、特定の目的地（行先）は決まっていないが、漠然とした希望体験を有するユーザが、その希望する体験に関する情報（希望情報）をサーバ１に送信することで、サーバ１が同じような体験を希望する他のユーザを抽出し、これらのユーザを一つのコミュニティとして集約したうえで、その希望する体験に最もマッチした目的地（希望施設）をデータベースから抽出してコミュニティを構成するユーザ達に当該目的地を提案する。すなわち、希望する体験に関する情報は、ユーザの希望施設を決定するために必要な希望情報の一例である。そして、輸送サービス用車両を配車し、この提案を承諾したユーザ達の位置を経由しながら搭乗させて目的地まで輸送するサービスを提供する。また、目的地まで輸送する処理には、希望施設の空き状況に応じて、目的地に到着したユーザが希望施設で長時間待つことがないように、輸送サービス用車両４の走行を管理することで、目的地の到着時刻を調整するような処理も含まれる。

特に限定されるものではないが、本発明の理解を容易にするためにその一例を挙げると、不慣れな土地にやって来た旅行者Ａが、次の予定まで数時間あり、その間に御当地グルメを食したい、その中でも特にお好み焼きを食べたいと思った場合に、従来であればスマートフォンなどの端末機を用いてグルメサイトでお好み焼きのおすすめ店舗を検索し、そこまでタクシーなどを使って移動するのが一般的である。しかしながら、従来のグルメサイトを使った店舗の検索では、場所と店舗名は表示されても、自分一人でその店舗まで行かなければならず、タクシー代は安くないし、廉価なバスを使うにしても不慣れな土地だけに行き方が分からないことが多い。また、そこまで行って帰るまでにどのくらいの時間がかかるのかも、ナビゲーションサイトなど、別の検索サイトを使わないと分からないため、非常に不便である。そのため、本実施形態のシステムでは、同じようにお好み焼きを食べたいと考えているユーザを集約し、予め記憶しておいたお勧めのお好み焼きの店舗を抽出するとともに、これら複数のユーザの現在位置に輸送サービス用車両を配車しながら搭乗させていき、目的とするお好み焼き店舗まで輸送する。

本実施形態に係る「希望する体験」とは、ユーザ自身が経験したい事柄を意味し、上述した例でいえば「食事がしたい」、その中でも「お好み焼きを食べたい」という体験である。この種の食事をしたいという体験の他にも、観光地へ行きたい、買い物がしたい、映画を見たい、スポーツを観戦したい、病院へ行きたい、といったジャンルがあり、本実施形態のシステムでは、こうした多種の体験が含まれる。

また本実施形態に係る「ユーザが希望する希望施設」とは、端末機２等の操作によりユーザが選択した施設、ユーザがサーバ側に提供した希望条件に基づき、サーバが選択した施設、あるいは、上記のように、ユーザが希望する体験に基づきサーバが提案する施設を含む。

本実施形態のサーバ１は、ハードウェア及びソフトウェアを備えたコンピュータにより構成され、プログラムを格納したＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）と、このＲＯＭに格納されたプログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、アクセス可能な記憶装置として機能するＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）とから構成されている。なお、動作回路としては、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）に代えて又はこれとともに、ＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）などを用いることができる。そして、図１に示すように、希望体験受付部１１と、コミュニティ生成部１２と、目的地提案部１３と、配車スケジュール生成部１４と、自動運転制御部１５とは、ＲＯＭに確立されたソフトウェアによって、後述する各機能を実現する。また、記憶ユニットとして、利用者情報記憶部１６と、体験・場所情報記憶部１７と、車両情報記憶部１８とを備え、これらに記憶された情報を利用しながら、上述した希望体験受付部１１と、コミュニティ生成部１２と、目的地提案部１３と、配車スケジュール生成部１４と、自動運転制御部１５とが、ＲＯＭに確立されたソフトウェアによって、後述する各機能を実現する。

本実施形態のシステムの前提として、ユーザとなり得る複数の人間は、日常的に携帯又は使用する端末機２をそれぞれ所有する。この種の端末機２としては、スマートフォン、携帯電話機、可搬コンピュータなどを用いることができる。本実施形態の端末機２は、コンピュータ機能を備え、後述するデータを入力するための入力部と、入力したデータをサーバ１の希望体験受付部１１に送信するための通信機能と、端末機２の現在位置を検出するＧＰＳ受信機などの位置検出機能と、を備える。そして、各端末機２は、自己のＩＤと、現在位置と、入力データとを、インターネットその他のネットワーク３（無線通信回線網）を介してサーバ１の希望体験受付部１１に送信する。本実施形態の端末機２に入力される各種情報の具体例については後述する。

輸送サービス用車両４は、自動運転機能を有する車両であって、ナビゲーション装置が搭載されるとともに走行制御（速度制御と操舵制御）を自動制御する機能を備える自動車であって人間が運転する自動車、又はナビゲーション装置が搭載されるとともに走行制御（速度制御と操舵制御）を自動制御する自動車であって無人で運転する自動車のいずれをも用いることができる。以下の実施形態では、道路交通法規が許すものとして、現在地から、経由地及び目的地５の位置情報（たとえば緯度・経度）と走行ルートに関するノード情報を入力することで、走行環境をカメラなどで検出しながら自動で発進、速度制御、停止、右左折などの速度制御と操舵制御を実行し、経由地でユーザを搭乗させつつ目的地５へ輸送する無人自動運転車を例に挙げて説明する。こうした輸送サービス用車両４は、複数台用意され、複数に用意された待機ステーションにて待機するか、又は所定の走行ルートを回遊しながらサーバ１からの走行指令を待機するものとする。

次にサーバ１における構成を説明する。希望体験受付部１１は、所定の時間間隔（たとえば１００ｍｓｅｃ）で、複数のユーザがそれぞれ携帯する端末機２から送信される情報を、ネットワーク３を介して受け付ける。希望体験受付部１１は、希望情報を取得するために機能ブロックとして、希望情報取得部を有している。図３は、サーバ１のコミュニティ生成部１２にて生成される希望体験リストの一例を示す図である。端末機２から送信される情報としては、図３に示すように、その端末機２を所有するユーザのＩＤに加えて、希望する体験に関する情報として、ジャンル、そのジャンルの中の小分類である抽象的な希望体験情報、行先の範囲、乗車位置、降車位置、希望する体験の希望時間帯、降車位置への戻り時間、希望予算などである。

ユーザのＩＤには、たとえば、氏名、住所、性別、年代（又は年齢）、出身国、趣味などが含まれ、各ユーザは、本実施形態のシステムを利用する前にシステムにアクセスして予めこれらの情報登録し、本実施形態のシステムは、この登録された各ユーザの情報を、サーバ１の利用者情報記憶部１６に記憶する。本実施形態のシステムに登録したユーザが、当該システムを利用する場合には、端末機２にインストールされた本実施形態のシステムの実行プログラム（アプリケーションソフトウェアなど）を立ち上げ、予め付与されたＩＤを入力することでサーバ１に繋がる。サーバ１の利用者情報記憶部１６には、各ユーザのＩＤに関連付けたかたちで、事前に登録された氏名、住所、性別、年代（又は年齢）、出身国、趣味などの属性情報が記憶され、特定のユーザが自分のＩＤを用いてサーバ１にアクセスすると、サーバ１は利用者情報記憶部１６に記憶されたこれらの属性情報を認識できるようになっている。

図示は省略するが、ユーザが端末機２を用いてサーバ１にアクセスすると、当該ユーザの端末機２には、上述した希望する体験に関する情報として、ジャンル、そのジャンルの中の小分類である抽象的な希望体験情報、行先の範囲、乗車位置、降車位置、希望する体験の希望時間帯、降車位置への戻り時間、希望予算などを入力できる画面が表示され、ユーザは、各項目に対して希望する体験に関する情報を入力する。また、希望体験受付部１１に送信される端末機２の現在の位置情報は、端末機２に備えられたＧＰＳ受信機などの位置検出センサにより、緯度及び経度が検出され、この位置情報が、希望する体験に関する情報とともに希望体験受付部１１に送信される。

なお、本実施形態のシステムでは、希望体験受付部１１に送信される情報として、ジャンル、そのジャンルの中の小分類である抽象的な希望体験情報、行先の範囲、乗車位置、降車位置、希望する体験の希望時間帯、降車位置への戻り時間、希望予算などを例示したが、少なくともジャンル又はそのジャンルの中の小分類である抽象的な希望体験情報を送信するものであればよく、その他の行先の範囲、乗車位置、降車位置、希望する体験の希望時間帯、降車位置への戻り時間、希望予算などの情報は必要に応じて送信するものであってもよい。また、ユーザが端末機２に表示された入力画面に対し、希望する体験情報を手入力してもよいが、入力される頻度が高いものをプルダウンメニューとして用意しておき、それを選択する入力方法であってもよい。さらに、これらの入力情報のうち、特に拘りのない項目については、「希望なし」という項目を用意するか、空欄のままサーバ１に送信することで、特段の希望がない旨を認識するようにしてもよい。

図３に示す一例では、ユーザＡ（女性、２０代、アメリカ出身）が、北緯３５°・東経１３９°にいて、「食事」のジャンル、なかでも「Ｘを食べたい」を選択し、行先範囲が「神奈川県内」、希望時間帯が「１５：００〜１６：００」、戻り時間が「１９：００まで」、希望予算が「３０００円まで」を選択したものとする。なお、「Ｘ」は食事の中の具体的な食べ物、たとえば上述した「お好み焼き」などである。また、乗車地が空欄であるのは、現在の位置において乗車することを希望していることを意味し、降車地が空欄であるのは、目的地５までの輸送のみを希望していることを意味する。

同様に、ユーザＢ（女性、２０代、アメリカ出身）が、北緯３３°・東経１３９°にいて、「食事」のジャンル、なかでも「Ｘ´を食べたい」を選択し、行先範囲が「神奈川県内」、希望時間帯が「午後」、戻り時間が「１９：００まで」、希望予算が「３０００円まで」を選択し、乗車地と降車地は空欄であるものとする。なお、「Ｘ´」は、上述した一例のお好み焼きＸに類似する食べ物、たとえばもんじゃ焼きなどである。

また同様に、ユーザＣ（男性、２０代、中国出身）が、北緯３４°・東経１４０°にいて、「観光」のジャンル、なかでも「Ｙを見たい」を選択し、行先範囲が「東京都内」、希望時間帯が「夜」、戻り時間が「２４：００まで」、希望予算が「４０００円まで」を選択し、乗車地と降車地は空欄であるものとする。

また同様に、ユーザＤ（女性、２０代、カナダ出身）が、北緯３５°・東経１４１°にいて、「食事」のジャンル、なかでも「Ｘを食べたい」を選択し、行先範囲が「神奈川県内」、希望時間帯が「午後」、戻り時間が「２０：００まで」、希望予算が「３０００円まで」を選択し、乗車地と降車地は空欄であるものとする。

また同様に、ユーザＥ（男性、３０代、中国出身）が、北緯３５°・東経１３９°にいて、「食事」のジャンル、なかでも「Ｚを食べたい」を選択し、行先範囲が「東京都内」、希望時間帯が「夜」、戻り時間が「２３：００まで」を選択し、希望予算と乗車地と降車地は空欄であるものとする。なお、「Ｚ」は、上述したお好み焼きＸには類似しない食べ物、たとえば日本そばなどである。

図１のコミュニティ生成部１２は、希望体験受付部１１にて受信したユーザからの希望体験に関する情報を図３に示すように仮想的にリスト化し、これら各ユーザの体験情報に対し、類似度が所定閾値以上の体験情報を送信したユーザを抽出して一つのコミュニティを生成する。コミュニティ生成部１２では、所定閾値に基づいて体験情報の類似度を判断するが、この所定閾値は予めジャンル及びジャンルの中の小分類である抽象的な希望体験に応じて定められている。たとえば、「食事」と「観光」のようにジャンル自体が異なると、類似度は所定値未満、すなわち非類似とされている。また、ジャンルが同じでも、ジャンルの中の小分類である抽象的な希望体験が同じ場所で体験できない内容である場合は、類似度は所定値未満、すなわち非類似とされている。たとえば、図３に示す例でいえば、ユーザＡ，Ｂ，Ｄ，Ｅはジャンル「食事」を選択し、ユーザＣはジャンル「観光」を選択したので、希望する体験の類似度は所定閾値未満、すなわち非類似と判断される。そのため、ユーザＣは、一つのコミュニティの構成メンバーとしては抽出されない。

また、同じジャンル「食事」を選択したユーザＡ，Ｂ，Ｄ，Ｅであっても、ジャンルの中の小分類である抽象的な希望体験が非類似と判断される「Ｚを食べたい」を選択したユーザＥは、「Ｘを食べたい」を選択したユーザＡ，Ｄ及び「Ｘ´を食べたい」を選択したユーザＢとともに、一つのコミュニティの構成メンバーとしては抽出されない。すなわち、お好み焼きやもんじゃ焼きを提供する店舗と、日本そばを提供する店舗とは同じ店舗である可能性は極めて低く、一つの目的地５として提案できないからである。これに対して、「Ｘを食べたい」を選択したユーザＡ，Ｄと、「Ｘ´を食べたい」を選択したユーザＢとは、お好み焼き屋さんにてお好み焼きともんじゃ焼きが食べられる可能性が極めて高いので、ジャンルの中の小分類である抽象的な希望体験が異なっていても類似度が所定閾値以上である場合には、一つの目的地５が提案できる。そのため、コミュニティ生成部１２は、これらユーザＡ，Ｂ，Ｄの類似度が所定閾値以上の体験情報を送信したユーザであると判断し、ユーザＡ，Ｂ，Ｄを一つのコミュニティとして生成する。

コミュニティ生成部１２にて判断する体験情報の類似度は、目的地提案部１３にて最終的に提案する目的地５が共通するか否かによって設定することが望ましい。上述した例のように、食事のジャンルにおいては、同じ店舗にて提供できる食べ物であるか否かという判断基準を所定閾値に設定することが望ましい。また、観光地というジャンルにおいては、小分類として、たとえば神社や寺院などの文化的観光地、温泉や山岳などの自然景観地、遺跡などの歴史的観光地などがあるため、目的地提案部１３にて最終的に提案する目的地５が共通するか否かによって設定することが望ましい。また、買い物（ショッピング）というジャンルにおいても、主として何を購入したいかといった小分類、たとえばバッグ、財布なのか、衣服なのかなどに分類できるため、目的地提案部１３にて最終的に提案する目的地５が共通するか否かによって設定することが望ましい。

コミュニティ生成部１２は、体験情報の類似度を判断して一つのコミュニティを生成するが、体験情報の類似度に加えて、端末機２の現在の位置情報又は希望する乗車位置を考慮してもよい。図３に示すユーザＡ〜Ｅの例では、各端末機２の現在位置（希望する乗車位置）が、北緯３３°〜３５°、東経１３９°〜１４１°とそれぞれ近郊にいるため、体験情報の類似度が所定閾値以上であれば一つのコミュニティを生成して配車しても、目的地５までにさほど時間はかからないが、これらのユーザＡ〜Ｅから所定閾値以上も離れた現在地にいる（又はその場所で乗車を希望する）ユーザがいる場合には、そのユーザを一つのコミュニティから除外してもよい。本実施形態のシステムでは、同一又は類似の体験を希望するユーザを抽出して一つのコミュニティを生成し、これらのユーザ達に目的地５を提案することを第１の目的とするが、その目的地５に向かって輸送サービス用車両を配車することを第２の目的とする。したがって、輸送サービス用車両を配車する場合に、遠隔地にいるユーザを経由して目的地５に行くと時間がかかり過ぎることは、コミュニティを構成する他のユーザにとっては不利益になるからである。

また、コミュニティ生成部１２は、体験情報の類似度を判断して一つのコミュニティを生成するが、体験情報の類似度や上述した端末機２の現在の位置情報又は希望する乗車位置に加えて、各ユーザが希望する行き先範囲に関する情報を考慮してもよい。図３に示す例でいえば、ユーザＡ，Ｂ，Ｄの３名は行先範囲として神奈川県内を希望しているのに対し、ユーザＣ，Ｅは行先範囲として東京都内を希望している。したがって、ユーザＡ，Ｂ，ＤとユーザＣ，Ｅとは、それぞれ希望する行先範囲が異なり、提案する目的地５の両立はできないため、ユーザＡ，Ｂ，ＤとユーザＣ，Ｅとは、一つのコミュニティを生成する際に別のコミュニティとして考慮してもよい。

さらに、コミュニティ生成部１２は、体験情報の類似度を判断して一つのコミュニティを生成するが、体験情報の類似度や上述した端末機２の現在の位置情報又は希望する乗車位置に加えて、各ユーザが希望する利用時間帯に関する情報を考慮してもよい。図３に示す例でいえば、ユーザＡ，Ｂ，Ｄの３名は利用時間帯として１５：００〜１６：００又は午後を希望しているのに対し、ユーザＣ，Ｅは利用時間帯として夜を希望している。したがって、ユーザＡ，Ｂ，ＤとユーザＣ，Ｅとは、それぞれ希望する利用時間帯が異なり、提案する目的地５の両立はできないため、ユーザＡ，Ｂ，ＤとユーザＣ，Ｅとは、一つのコミュニティを生成する際に別のコミュニティとして考慮してもよい。

さらにまた、コミュニティ生成部１２は、体験情報の類似度を判断して一つのコミュニティを生成するが、体験情報の類似度に加えて、ユーザの性別、年齢その他のユーザ属性情報を考慮してもよい。図３に示す例でいえば、ユーザＡ，Ｂ，Ｄの３名はいずれも２０代の女性で出身国がアメリカ又はカナダという英語圏であるのに対し、ユーザＣ，Ｅは２０代又は３０代の男性で出身国がいずれも中国という非英語圏である。したがって、特に断定はできないが、ユーザＡ，Ｂ，Ｄを一つのコミュニティとして生成しても、性別、年齢、言語といったユーザ属性が共通するため、目的地５まで比較的仲良く相乗りすることができるものと予想される。

以上、コミュニティ生成部１２は、図３に示すユーザＡ〜Ｅに対し、ジャンルの中の小分類である抽象的な希望体験「お好み焼きＸを食べたい」又はこれに類似する希望体験「もんじゃ焼きＸ´を食べたい」を送信したユーザＡ，Ｂ，Ｄを一つのコミュニティとして生成したものとして、以下説明する。

体験・場所情報記憶部１７は、上述したユーザが希望する種々の体験に関する体験情報に対して、一又は複数の適した場所（目的地５）を関連付けて記憶したデータベースである。図３に示す例でいえば、食事のジャンルの中で「お好み焼きＸを食べたい」という体験情報に対し、お好み焼きＸを提供する一又は複数の店舗の位置情報（緯度・経度）と店舗名とが、「Ｘを食べたい」という体験情報に関連付けて記憶されている。図４は、サーバ１の目的地提案部１３にて実行される目的地候補の検索結果の一例を示す図であるが、体験・場所情報記憶部１７には、「お好み焼きＸを食べたい」という体験情報に対し、お好み焼きＸを提供する一又は複数の店舗の位置情報（緯度・経度）と店舗名とが図４に示すように記憶されている。また、体験・場所情報記憶部１７には、店舗の位置情報に限らず、店舗の客席数、店舗で提供される商品情報、店舗の営業時間等の店舗情報が記憶されている。なお、食事のジャンル以外のジャンルについても同様に場所の位置情報と場所名とが、ジャンルの中の小分類である抽象的な体験に関連付けて記憶されている。なお、図４に示すように、その場所に対する他のユーザの評価値（図４に示す「グルメサイトの評価」の欄）がある場合には、その情報も記憶させてもよいし、図５に示すように、その場所にて体験をするのに費用がかかる場合は、その予算の幅も記憶させてもよい。

目的地提案部１３は、輸送サービス用車両４の目的地に設定するための機能ブロックとして、目的地設定部を含んでいる。ユーザにより希望施設が選択される場合には、目的地提案部１３は、ユーザにより選択された希望施設を、輸送サービス用車両４の目的地に設定する。また、目的地提案部１３は、コミュニティ生成部１２によりコミュニティを形成した上で、体験・場所情報記憶部１７を用いて目的地を抽出する場合には、抽出した目的地を、輸送サービス用車両４の目的地に設定する。

目的地提案部１３は、予め体験情報と目的地５とを関連付けて記憶した体験・場所情報記憶部１７を用いて、類似度が所定閾値以上の体験情報に関連付けられた目的地５を抽出する。図３に示す例でいえば、コミュニティ生成部１２は、一つのコミュニティとしてユーザＡ，Ｂ，Ｄを生成したので、目的地提案部１３は、ジャンルの中の小分類である抽象的な希望体験「お好み焼きＸを食べたい」に関連付けられた場所（店舗）の名称と位置情報及びこれに類似する希望体験「もんじゃ焼きＸ´を食べたい」に関連付けられた場所（店舗）の名称と位置情報とを、体験・場所情報記憶部１７から抽出する。図４は、サーバ１の目的地提案部１３にて実行される目的地候補の検索結果の一例を示す図であり、複数の場所（店舗）とその位置情報が抽出されている。

目的地提案部１３は、一つのコミュニティを構成する各ユーザＡ，Ｂ，Ｄの端末機２へ抽出された場所の名称と位置情報（目的地５）を送信するが、その前に、各ユーザＡ，Ｂ，Ｄから当該目的地５までの移動時間を算出し、これを併せて送信してもよい。各ユーザＡ，Ｂ，Ｄから当該目的地５までの移動時間は、各ユーザＡ，Ｂ，Ｄの現在位置と目的地５の位置情報とから、ナビゲーション装置で用いられている地図情報と走行ルート演算手法を用いて算出することができる。

また目的地提案部１３は、一つのコミュニティを構成する各ユーザＡ，Ｂ，Ｄの端末機２へ抽出された場所の名称と位置情報（目的地５）を送信するが、図３に示す希望体験情報のうち、小分類である抽象的な希望体験以外の、行先範囲、希望時間帯、戻り時間などを勘案し、これらの情報に合致しない目的地５を除外した上で、合致する目的地５のみを一又は複数送信してもよい。図４に示す例でいえば、Ｎ店は、東京都町田市にあるため、ユーザＡ，Ｂ，Ｄが希望する行先範囲である神奈川県内に合致しないし、Ｍ店は、行先範囲は合致するが予約可能時間が希望時間帯に合致しない。したがって、小分類である抽象的な希望体験、行先範囲、希望時間帯、戻り時間などの全てを満足するＬ店を目的地５として提案する。なお、図４に示すコミュニティの合計スコアとは、コミュニティを構成する各ユーザＡ，Ｂ，Ｄの全体のマッチング度合を定量的に示す値であり、０〜１００を範囲とし、合計スコアが大きい順に目的地５を提案する。また、図４に示す各ユーザＡ，Ｂ，Ｄのスコアとは、ユーザＡ，Ｂ，Ｄのそれぞれのマッチング度合を定量的に示す値であり、この情報は、各ユーザＡ，Ｂ，Ｄの端末機２に送信してもよい。

図５は、サーバ１の目的地提案部１３からユーザＡ，Ｂ，Ｄの端末機２のそれぞれに送信される提案情報の一例を示す図である。上述したとおり、一つのコミュニティを構成するユーザＡ，Ｂ，Ｄの希望体験、行先範囲、希望時間帯、戻り時間などの全てを満足するＬ店の名称、位置情報、予約可能時刻、グルメサイト評価、予算の幅、戻り時刻、当該コミュニティを構成するユーザの属性の概要が、各端末機２に送信されて表示される。なお、戻り時刻は、各ユーザＡ，Ｂ，Ｄから当該目的地５までの移動時間を算出した場合と同様に、各ユーザＡ，Ｂ，Ｄが、目的地５から現在位置へ戻った場合の移動時間を算出すればよい。

目的地提案部１３から図５に示す提案情報を端末機２で受信したユーザＡ，Ｂ，Ｄは、提案された目的地５（店舗Ｌ）を承諾したものとして、現在位置にて輸送サービス用車両４が来るのを待機してもよいが、本実施形態のシステムでは、ユーザＡ，Ｂ，Ｄの端末機２から、提案した目的地５（店舗Ｌ）へ行くことを承諾する旨の承諾情報又は承諾しない旨の不承諾情報を、ネットワーク３を介してサーバ１にて受け付け、不承諾情報を送信した端末機２のユーザについては、当該コミュニティから除外することとしている。コミュニティを構成するユーザＡ，Ｂ，Ｄによっては、希望体験は満足しても、その他の行先範囲、希望時間帯、戻り時間などの全てを満足しているとは限らず、また当初の予定が変更される場合もあるからである。そして、ユーザＡ，Ｂ，Ｄの端末機２から送信された承諾情報をサーバ１にて受け付けると、目的地提案部１３は、提案した目的地５（店舗Ｌ）を、輸送サービス用車両４の目的地に設定する。

そのため、配車スケジュール生成部１４は、コミュニティを構成するユーザＡ，Ｂ，Ｄの各端末機２のうち、承諾情報を送信した端末機２の位置情報に基づいて、輸送サービス用車両４の走行ルートと、承諾情報を送信した端末機２の各位置に到着する時間と、提案した目的地５（店舗Ｌ）に到着する時間とを含む配車スケジュールを生成する。配車スケジュール生成部１４は、輸送サービス用車両４の現在地から、コミュニティを構成するユーザＡ，Ｂ，Ｄ（全員が目的地５を承諾したものとする）の端末機２のそれぞれの現在地を経由し、目的地５（店舗Ｌ）へ向かう、好ましくは最短距離又は最短時間の走行ルートを、従来のナビゲーション装置のルート検索機能などを用いて生成する。そして、配車スケジュール生成部１４は、図５に示す配車スケジュールを各ユーザＡ，Ｂ，Ｄの端末機２へ送信し、各ユーザＡ，Ｂ，Ｄの端末機２はこれを表示する。

また配車スケジュール生成部１４は、予約情報を目的地５に相当する施設に対して送信する。予約情報は、承諾情報に含まれる予約可能時刻、及び、承諾情報を送信した人数の情報を含む。また予約情報には、注文内容を含めてもよい。配車スケジュール生成部１４は、承諾情報を送信したユーザに対して、店舗Ｌで提供可能な商品情報を送信する。ユーザは、ユーザ端末機２上のディスプレイで商品情報を確認し、注文する商品を選択する。例えば、ユーザＡが、広島風のお好み焼きを食べたい場合には、ユーザＡのユーザ端末機２は、ユーザＡにより指定された商品情報をサーバ１に送信する。配車スケジュール生成部１４は、ユーザにより指定された注文内容の情報を予約情報に含めて、目的地５（店舗Ｌ）に送信する。

配車スケジュール生成部１４は、希望施設の空き状況を示す情報を取得するための機能ブロックとして、施設情報取得部を有している。配車スケジュール生成部１４は、目的地５（店舗Ｌ）から、施設の空き状況を示す施設情報を取得する。空き状況は、施設における混雑状況を表しており、例えば店舗内の座席数に対して、客が座っていない座席数の割合で表される。目的地５における店舗内には、空き状況を管理するシステムが設けられている。システムの一例として、カメラが店舗内に設置されており、店舗内のシステムがカメラ画像を用いた画像解析により空席数を算出することで、空き状況を管理している。なお、空き状況の管理システムは、カメラを用いたシステムに限らず、他の公知のシステムでもよい。また店舗内のシステムは、注文を受注した後、商品又はサービスを提供できるための提供時間を、施設情報に含めて、サーバ１に送信する。例えば、お好み焼きの店舗では、提供時間は、客からの注文を確定した注文確定時刻から、お好み焼きを客に提供するまでの時刻に相当する。

配車スケジュール生成部１４は、施設情報に含まれる空き状況の情報を取得し、空き状況に基づき、目的地５への到着予定時刻を算出する。例えば、車両が、図５に示す配車スケジュールの予定通り、店舗Ｌに１５：００に到着した場合において、店舗Ｌの空き状況が１５：００で混雑を示すときには、ユーザは店舗Ｌに到着しても、お好み焼きを食べるまで待つことが予想される。このとき、ユーザ心理としては、店舗でお好み焼きの提供を待つよりも、車両の走行時間を延長して走行中の車両への乗車時間を延ばす方が、ストレスが少ない。そのため、配車スケジュール生成部１４は、配車スケジュールで示される目的地Ｌへの到着時刻に、店舗での空き状況に応じた待ち時間を加算することで、到着予定時刻を変更する。店舗における空席数が少ないほど、空き状況に応じた待ち時間は長くなる。図５に示す配車スケジュールの例の場合に、空き状況に応じた待ち時間が３０分のときには、配車スケジュール生成部１４は、到着時刻を１５：００から１５：３０に変更する。また配車スケジュール生成部１４は、変更後の到着時刻を店舗Ｌの予約時間として店舗Ｌに予約情報を送信する。

自動運転制御部１５は、配車スケジュール生成部１４にて生成された配車スケジュールに含まれる位置情報及び時間情報を取得し、配車センターから、ユーザＡ，Ｂ，Ｄの現在地Ｐ１，Ｐ２，Ｐ３を経由し、目的地５（店舗Ｌ）へ向かう走行ルートを実現する制御を輸送サービス用車両４に対して実行する。なお、自動運転制御部１５は、配車スケジュール生成部１４にて生成された配車スケジュールに含まれる位置情報及び時間情報を輸送サービス用車両４の車載制御装置に送信し、ここで自動運転制御を実行してもよい。なお、サーバ１に備える車両情報記憶部１８は、輸送サービス用車両４に備えられた各種のセンサ類から送信される輸送サービス用車両４の車両状態に関する情報や、走行ルートを生成する際に必要とされる地図データなどが記憶されたデータベースである。

輸送サービス車両４は、自動運転制御１５からの制御指令に基づき、配車スケジュールどおりに走行するように、走行を制御する。輸送サービス車両４は、目的地５への到着時刻を調整するために機能ブロックとして、到着時刻調整部を含んでいる。輸送サービス車両４は、輸送サービス用車両４の走行中、配車スケジュールにそって走行するための制御指令をサーバ１から取得し、制御指令に基づき、走行制御（速度制御と操舵制御）を実行する。このとき、制御指令が到着予定時刻を調整する旨の指令を含む場合には、輸送サービス車両４は、変更後の到着時刻に到着できるように、車速及び／又は走行ルートを変更する。

上記のように、サーバ１は、配車スケジュール生成部１４により配車スケジュールを生成し、自動運転制御部１５により配車スケジュールに基づき輸送サービス用車両４を制御することで、輸送サービス用車両４を管理している。なお、サーバ１による輸送サービス用車両４の管理には、少なくとも配車スケジュールの作成を含めばよい。すなわち、サーバ１が、配車スケジュールの情報を輸送サービス用車両４に送信し、輸送サービス用車両４は、配車スケジュール通りに走行するように、車速、操舵角等を制御する。これにより、サーバ１は輸送サービス用車両４を管理する。また、サーバ１は、店舗Ｌの空き状況を含む施設情報に基づき配車スケジュールを生成して、輸送サービス用車両４を介して目的地５への到着時刻を調整している。

図６は、配車スケジュール生成部１４にて生成される配車スケジュールの一例を示す図、図７は、自動運転制御部１５から輸送サービス用車両４（自動運転車）に送信された配車スケジュールに基づいた走行ルートの一例を示す図である。輸送サービス用車両４がある配車センターを１４：００に出発し、ユーザＡが待機するＰ１地点に１４：１４に到着してユーザＡを搭乗させ、１４：１５にＰ１地点を出発し、ユーザＢが待機するＰ２地点に１４：２９に到着してユーザＢを搭乗させ、１４：３０にＰ２地点を出発し、ユーザＤが待機するＰ３地点に１４：４４に到着してユーザＤを搭乗させ、１４：４５にＰ３地点を出発し、目的地５である店舗Ｌに１５：００に到着する。

次に、本実施形態のシステムにて実行される情報処理手順の概要を説明する。図２は、その情報処理手順を示すフローチャートである。

まずステップＳ１において、ユーザが、端末機２を用いてサーバ１にアクセスすると、当該ユーザの端末機２には、上述した希望する体験に関する情報として、ジャンル、そのジャンルの中の小分類である抽象的な希望体験情報、行先の範囲、乗車位置、降車位置、希望する体験の希望時間帯、降車位置への戻り時間、希望予算などを入力できる画面が表示され、ユーザは、各項目に対して希望する体験に関する情報を入力する。また、端末機２に備えられたＧＰＳ受信機などの位置検出センサにより、緯度及び経度が検出され、この位置情報が、希望する体験に関する情報とともに、サーバ１の希望体験受付部１１に送信される。

ステップＳ２において、サーバ１の希望体験受付部１１は、所定の時間間隔（たとえば１００ｍｓｅｃ）で、複数のユーザがそれぞれ携帯する端末機２から送信される上記の情報を、ネットワーク３を介して受け付ける。端末機２から送信される情報としては、図３に示すように、その端末機２を所有するユーザのＩＤに加えて、希望する体験に関する情報として、ジャンル、そのジャンルの中の小分類である抽象的な希望体験情報、行先の範囲、乗車位置、降車位置、希望する体験の希望時間帯、降車位置への戻り時間、希望予算などである。

ステップＳ３において、サーバ１のコミュニティ生成部１２は、希望体験受付部１１にて受信したユーザからの希望体験に関する情報を図３に示すように仮想的にリスト化し、続くステップＳ４において、これら各ユーザの体験情報に対し、類似度が所定閾値以上の体験情報を送信したユーザを抽出して一つのコミュニティを生成する。本実施形態のシステムでは、コミュニティ生成部１２は、体験情報の類似度に加えて、端末機２の現在の位置情報又は希望する乗車位置、各ユーザが希望する行き先範囲に関する情報、各ユーザが希望する利用時間帯に関する情報、ユーザの性別、年齢その他のユーザ属性情報を考慮して一つのコミュニティを生成する。これにより、図３に示すユーザＡ〜Ｅに対し、ジャンルの中の小分類である抽象的な希望体験「お好み焼きＸを食べたい」又はこれに類似する希望体験「もんじゃ焼きＸ´を食べたい」を送信したユーザＡ，Ｂ，Ｄを一つのコミュニティとして生成したものとする。

ステップＳ５において、サーバ１の目的地提案部１３は、体験・場所情報記憶部１７に記憶された体験情報と目的地５とを関連付けた情報を用いて、類似度が所定閾値以上の体験情報に関連付けられた目的地５を抽出する。図３に示す例でいえば、一つのコミュニティとしてユーザＡ，Ｂ，Ｄを生成したので、目的地提案部１３は、ジャンルの中の小分類である抽象的な希望体験「お好み焼きＸを食べたい」に関連付けられた場所（店舗）の名称と位置情報及びこれに類似する希望体験「もんじゃ焼きＸ´を食べたい」に関連付けられた場所（店舗）の名称と位置情報とを、体験・場所情報記憶部１７から抽出する。その結果、図４に示す店舗Ｌが目的地５として最適であると判断されたものとする。

ステップＳ６において、サーバ１の目的地提案部１３からユーザＡ，Ｂ，Ｄの端末機２のそれぞれに対し、図５に示す提案情報が送信される。そして、ステップＳ７において、図５に示すような、一つのコミュニティを構成するユーザＡ，Ｂ，Ｄの希望体験、行先範囲、希望時間帯、戻り時間などの全てを満足するＬ店の名称、位置情報、予約可能時刻、グルメサイト評価、予算の幅、戻り時刻、当該コミュニティを構成するユーザの属性の概要が、各端末機２に表示される。

ステップＳ８において、ユーザＡ，Ｂ，Ｄのそれぞれは、各端末機２を用いて、提案された目的地５（店舗Ｌ）を承諾するか否かを判断し、承諾する場合は承諾情報をサーバ１に送信し、承諾しない場合は不承諾情報をサーバ１に送信する。なお、ここ不承諾情報を送信した端末機２を所有するユーザは、当該コミュニティから除外され、当該ユーザに関しては、ステップＳ１の処理に戻る。以下の説明は、ステップＳ８においてコミュニティを構成する全てのユーザＡ，Ｂ，Ｄが承諾情報を送信したものとする。

ステップＳ９において、サーバ１の配車スケジュール生成部１４は、コミユニティを構成するユーザＡ，Ｂ，Ｄの各端末機２の位置情報に基づいて、輸送サービス用車両４の相乗り調整、すなわち、図６に示すような、輸送サービス用車両４の走行ルートと、３名のユーザＡ，Ｂ，Ｄの端末機２の各現在位置Ｐ１，Ｐ２，Ｐ３に到着する時間と、提案した目的地５（店舗Ｌ）に到着する時間とを含む配車スケジュールを生成し、ステップＳ１０にてこれを確定する。

ステップＳ１１において、サーバ１の配車スケジュール生成部１４は、図５に示す配車スケジュールを各ユーザＡ，Ｂ，Ｄの端末機２へ送信し、ステップＳ１２において各ユーザＡ，Ｂ，Ｄの端末機２はこれを表示する。これにより、各ユーザＡ，Ｂ，Ｄは、輸送サービス用車両４の到着時刻を把握することができるので、ステップＳ１３において、この配車スケジュールを承諾するか否かを判断し、承諾する場合は承諾情報をサーバ１に送信し、承諾しない場合は不承諾情報をサーバ１に送信する。なお、ここ不承諾情報を送信した端末機２を所有するユーザは、当該コミュニティから除外され、当該ユーザに関しては、ステップＳ１の処理に戻る。以下の説明は、ステップＳ１３においてコミュニティを構成する全てのユーザＡ，Ｂ，Ｄが承諾情報を送信したものとする。そして、ステップＳ１４において、サーバ１の配車スケジュール生成部１４は、配車スケジュールの予約が完了したと判断する。

ステップＳ１５において、自動運転制御部１５は、配車スケジュール生成部１４にて生成された配車スケジュールに含まれる位置情報及び時間情報を取得し、図７に示すように、配車センターから、ユーザＡ，Ｂ，Ｄの現在地Ｐ１，Ｐ２，Ｐ３を経由し、目的地５（店舗Ｌ）へ向かう走行ルートを実現する制御を輸送サービス用車両４に対して実行する。ステップＳ１６において、輸送サービス用車両４は、自動運転制御部１５からの制御指令に応じて輸送サービスを実行するべく自動運転を開始する。

次に、輸送サービス用車両４を開始し、ユーザＡ，Ｂ，Ｄをピックアップする時の情報処理手順を説明する。図８は、その情報処理手順を示すフローチャートである。

ステップＳ２１において、端末機２が現在の位置情報をサーバ１に送信する。ステップＳ２２にて、配車スケジュール生成部１４は、ユーザの停車場所への到着予定時刻を算出する。停車場所は、ユーザをピックアップする際の、輸送サービス用車両４の停車位置である。ステップＳ２３にて、輸送サービス用車両４は、現在の位置情報をサーバ１に送信する。

ステップＳ２４において、配車スケジュール生成部１４は、現在の交通情報を取得し、輸送サービス用車両４の現在位置から停車場所への走行時間を算出し、停車場所への到着予定時刻を算出する。

ステップＳ２５において、配車スケジュール生成部１４は、ステップＳ２２の情報処理で算出された到着予定時刻と、ステップＳ２４の情報処理で算出された到着予定時刻が異なる場合には、到着予定時刻を調整する旨の指令を、輸送サービス用車両４に送信する。また、配車スケジュール生成部１４は、算出された到着予定時刻を含む配車スケジュールの情報を、自動運転制御部１５に出力する。輸送サービス用車両４が調整後の配線スケジュールに沿って走行できるように、自動運転制御部１５は、走行ルートの情報及び車速情報を輸送サービス用車両４に送信する。これにより、サーバ１から輸送サービス用車両４に対して、停車場所への到着時刻の調整が指示される。

ステップＳ２６において、輸送サービス用車両４は、走行ルートと、ルート走行時の車速を変更する。なお、輸送サービス用車両４の車速又は走行ルートは、車両の実際の走行状況により適宜、変更される。ステップＳ２７において、輸送サービス用車両４は、変更後の走行ルートの情報、車速情報、及び位置情報をサーバ１に送信する。

ステップＳ２８において、配車スケジュール生成部１４は、取得された輸送サービス用車両４の現在位置及び車速を用いて、輸送サービス用車両４の現在位置から停車場所への走行時間を算出し、停車場所への到着予定時刻を推定する。ステップＳ２９において、配車スケジュール生成部１４は、推定された推定到着時刻及び車両の現在位置の情報を端末機２に送信する。ステップＳ３０において、端末機２は、ディスプレイに、到着予定時刻及び輸送サービス用車両４の現在位置を表示する。

次に、輸送サービス用車両４の走行中の情報処理手順を説明する。図９は、その情報処理手順を示すフローチャートである。なお、図９に示す制御フローは、所定の周期で繰り返し実行される。

ステップＳ３１において、端末機２は、目的地Ｌの施設で提供される料理の情報を表示し、ユーザに対して料理の選択を要求する。端末機２は、ユーザの操作に基づき料理を選択する。また、端末機２は、ユーザから人数の入力を受け付ける。端末機２は、人数及び選択された料理の情報をサーバ１に送信することで、料理を注文する。なお、料理の注文は、輸送サービス用車両４に乗車しているユーザの端末機２毎で実行されてもよい。また、料理の注文を端末機２毎に実行させる場合には、ステップＳ３１の処理において、人数の出力を省略してもよい。

ステップＳ３２において、サーバ１の配車スケジュール生成部１４は、予約情報、及び、注文内容の情報を施設（店舗Ｌ）に送信する。予約情報は、人数と到着時刻の情報を含んでいる。到着時刻は、ステップＳ２８の情報処理において推定された時刻である。

ステップＳ３３において、施設（店舗Ｌ）に設けられた管理システムは、注文内容及び予約情報を受信し、予約情報に示された条件で予約を受け付ける。なお、この時点の予約は仮予約であり、特に予約開始時刻は以降の処理で決定する。

ステップＳ３４において、施設（店舗Ｌ）内の管理システムは店内の状況を示す施設情報をサーバ１に送信する。施設情報は、施設の空き状況を示す情報、及び、料理提供までの時間情報を含んでいる。また施設情報は、調理場の映像等、調理状況を示す情報を含んでいる。図１０は、施設（店舗Ｌ）で管理されている施設情報の一例を示す図である。施設情報は、予約番号、予約者名、テーブル番号、到着時刻、ステータス、及び退出予定時刻で示される。管理システムは、ユーザから予約を受け付けた時に、予約番号、予約者名、テーブル番号、及び予約時間をデータベースに記録する。管理システムのカメラは、各テーブルの状況を撮像しており、管理システムは撮像画像から、客のステータスを確認する。管理システムは、客の現在の状況を示すステータスとして、「会計中」、「食事中」、「料理待ち中」等を管理している。管理システムは、予約時間とステータスに基づき、客の退出予測時刻を算出している。例えば、予約番号「１」の客は、１４時から１６時までを到着時刻として予約しており、現在のステータスが会計中であるため、例えば現在の時刻（例えば、１５時１５分）から所定時間（例えば１５分）を、退出予測時刻をとして算出する。そして、施設（店舗Ｌ）内の管理システムは施設の空き状況を示す情報の１つとして、算出された退出予測時刻をサーバ１に出力する。

ステップＳ３５において、配車スケジュール生成部１４は施設情報を受信する。ステップＳ３６において、配車スケジュール生成部１４は施設情報に基づき目標到着時刻を設定する。具体的には、配車スケジュール生成部１４は、施設情報により示される空き状況及び料理提供の時間から、店舗Ｌに推定到着時刻に到着した時の待ち時間を算出する。待ち時間は、空き状況で示される混雑率が高いほど長くなり、料理提供の時間が長いほど、長くなる。そして、配車スケジュール生成部１４は、ステップＳ２８の情報処理において推定された到着時刻に、待ち時間を加算することで、目標到着時刻を設定する。これにより、到着時刻が施設状況に基づき調整される。また、配車スケジュール生成部１４は、設定された目標到着時刻に到着するように、配車スケジュールを調整する。配車スケジュールは、ルートの変更及び／又はルートを走行する際の車速の変更により調整される。配車スケジュール生成部１４は、調整後の配車スケジュールの情報を自動運転制御部１５に出力する。輸送サービス用車両４が調整後の配線スケジュールに沿って走行できるように、自動運転制御部１５は、走行ルートの情報及び車速情報を輸送サービス用車両４に送信する。

なお、配車スケジュール生成部１４は、施設（店舗Ｌ）内の管理システムから、所定の周期で施設情報を取得している。そして、施設情報で示される空き状況から、輸送サービス用車両４の到着予定時刻よりも早く席が空く場合には、目標到着時刻を早めてもよい。

ステップＳ３７において、輸送サービス用車両４は、走行ルートと、ルート走行時の車速を変更する。なお、輸送サービス用車両４の車速又は走行ルートは、車両の周囲の混雑率（渋滞等）等、実際の走行状況により適宜、変更される。また、輸送サービス用車両４は、車室内のディスプレイに、調理状況を示す映像を表示する。車室内のユーザは映像を確認することで、料理の準備状況を確認できる。ステップＳ３８において、輸送サービス用車両４は、変更後のルート情報、車速情報、及び位置情報をサーバ１に送信する。

ステップＳ３９において、配車スケジュール生成部１４は、取得された輸送サービス用車両４の現在位置及び車速を用いて、輸送サービス用車両４の現在位置から目的地への走行時間を算出し、目的地への到着予定時刻を推定する。ステップＳ４０において、配車スケジュール生成部１４は、推定された推定到着時刻の情報を施設（店舗Ｌ）に送信する。ステップＳ４１において、施設（店舗Ｌ）は、推定到着時刻の情報を受信し、推定到着時刻を予約時間に設定する。これにより、予約が確定する。

次に、輸送サービス用車両が走行を開始してから目的地に到着するまでの、サーバ１のける情報処理手順の概要を説明する。図１１は、その情報処理手順を示すフローチャートである。

ステップＳ５１において、サーバ１は、輸送サービス用車両４が通常の走行計画で走行するように、輸送サービス用車両４の走行制御を実行する。走行制御は、配車スケジュール１４による配車スケジュールの生成と、自動運転制御部１５による、車両位置及び車速制御である。配車スケジュールは、複数のユーザのうち最後のユーザが輸送サービス用車両４に乗車するまでの第１走行経路と、最後のユーザが輸送サービス用車両４に乗車したあとの第２走行経路とを含んでいる。第１走行計画が通常の走行計画に相当し、第２走行計画が後述する変更後の走行計画に相当する。第１走行計画は、車両の出発地から全てのユーザをピックアップする地点までの走行ルート、及び、各ピックアップ地点での停車時刻を含む。図６の例では、乗車ユーザＤが輸送サービス用車両４に乗車するまでの走行計画が通常の走行計画となる。通常の走行計画では、希望施設の空き状況に応じて到着時刻が調整されない。そのため、通常の走行計画での走行中、到着時刻を調整するために、ルート変更及び車速変更が行われることはない。

ステップＳ５２において、サーバ１は、予約者全員が輸送サービス用車両４に乗車したか否かを判定する。サーバ１は、走行中の輸送サービス用車両４の位置情報を取得しており、輸送サービス用車両４が最後のユーザの乗車位置に到着した場合に、予約者全員が輸送サービス用車両４に乗車したと判定すればよい。

ステップＳ５３において、サーバ１は、目的地（施設Ｌ）への到着時刻を変更するか否かを判定する。配車スケジュール生成部１４は、全てのユーザをピックアップした後の、目的地に向かうための配車スケジュールを生成する。そして、車両の走行中に、目的地となる施設Ｌから空き状況を示す情報を取得し、空き状況に応じて目的地への到着時刻を調整する。輸送サービス用車両４が調整後の到着時刻に到着するように、配車スケジュールを変更する。このとき、変更後の配車スケジュールで示される走行計画が第２走行計画となる。到着時刻を変更する場合には、ステップＳ５４において、サーバ１は、輸送サービス用車両４が変更後の走行計画で走行するように、輸送サービス用車両の走行制御を実行する。

以上のとおり、本実施形態のシステムによれば、ユーザの端末機２から、当該ユーザが希望する希望施設を決定するために必要な希望情報を、電気通信回線網３を介してサーバ１にて取得し、取得された希望情報に基づき自動運転機能を有する車両の目的地を設定し、希望施設の空き状況を示す情報を含む施設情報を、電気通信回線網３を介してサーバ１にて取得し、施設情報に基づき車両が目的地に到着する到着時刻を調整して、車両の走行を管理する。

ところで、ユーザが施設の利用を希望する予約時間に、空席が施設にない場合には、輸送サービス用車両４が施設に到着しても、ユーザは施設においてサービスの提供を受けることができず、待ち時間が発生する。このような事態を避けるためには、ユーザが輸送サービス用車両４を利用する前に、料理等の注文と席の予約を同時に行うことが考えられる。しかしながら、ユーザの希望時間に席が空いていない場合には、予約できないため、ユーザは他の施設を探すことになる。そのため、店舗側はユーザの希望に応えることができず、システムに対するユーザの満足度が低下し、システムの利用率が下がるという問題がある。

本実施形態では、施設の空き状況に応じて施設への到着時刻を調整して、輸送サービス用車両４を管理しているため、施設への到着後、席が空くまで待つことなく、サービス又は商品の提供を受けることができる。また、予約していた席が、予定時刻よりも早く空く場合には、設定された予約時間よりも到着予定時刻を早めることができるため、施設側の稼働率が向上し、ユーザにとっては時間を有効に活用できる。

また本実施形態では、サーバ１において、端末機２の位置情報に基づき、ユーザが輸送サービス用車両４に乗車する位置情報、輸送サービス用車両４が前記目的地に到着する到着時刻の情報を含む配車スケジュールを作成する。これにより、サーバ側で、配車スケジュールを作成することで、配車スケジュールに基づく車速や車両位置の調整量を少なくすることができるため、より滑らかな走行を実現できる。

また本実施形態では、輸送サービス用車両４が目的地に到着するまでの走行ルートを算出し、走行ルート、及び、車速の少なくとも何れか一方を変更することで、到着時刻を調整する。これにより、道路状況等により、予定通りに到着できない恐れがある場合、又は、施設の空き状況が変更した場合でも、到着予定時刻に到着することができる。

また本実施形態では、サーバ１において、複数のユーザの端末機２の位置情報に基づき、複数のユーザが相乗りにて輸送サービス用車両４に乗車し、目的地に到着するまでの配車スケジュールを作成する。これにより、相乗りにより車両を利用する場合であっても、席に空きができるタイミングで施設に到着することができる。

また本実施形態では、配車スケジュールは、複数のユーザのうち最後のユーザが輸送サービス用車両４に乗車するまでの第１走行計画と、最後のユーザが輸送サービス用車両４に乗車した後の第２走行計画とを含み、サーバにおいて、第１走行計画を変更せず、第２走行計画を変更することで、目的地への到着時刻を調整する。相乗り対象の全ユーザが車両に乗車する前に、到着時刻を調整するために走行経路を変更する場合には、ユーザが車両の到着を待つ時間が長くなってしまう。一方、相乗り対象の全ユーザが車両に乗車した後に、走行経路を変更する場合には、例えばユーザ間の会話が弾んでいることもあり、走行経路変更に伴う車速調整又はルート変更に対して、ユーザの違和感を軽減させることができる。

また本実施形態では、サーバ１において、希望施設の予約時間を管理し、目的地への到着時刻を推定し、推定された到着時刻に対応するように到着時刻を変更し、変更された到着時刻を含む情報をサーバから希望施設を管理する装置に送信する。渋滞等によって到着が遅れた場合に、到着時刻が変更されないときには、予約席は遅延分、利用されないことになるため、施設側の稼働率が低下する。一方、本実施形態では、到着時刻に応じて予約時間が変更されるため、施設側の稼働率を高めることができる。

また本実施形態では、希望施設を管理する装置から、希望施設におけるサービス又は商品の提供時間に関する時間情報を、サーバ１にて取得し、当該時間情報に基づいて到着時刻を調整する。これにより、例えば、車室内にいるユーザから注文のタイミングが遅れて、商品又はサービスの提供時間が遅くなった場合であっても、輸送サービス用車両４の到着のタイミングで、商品又はサービスの提供を受けることができる。その結果として、施設側の稼働率を高めることができる。

また本実施形態では、希望施設を管理する装置から、希望施設における調理状況を示す情報を、サーバ１にて取得し、調理状況を示す情報をサーバ１から輸送サービス用車両４に対して送信し、輸送サービス用車両４に設けられたディスプレイにおいて、調理状況を表示する。これにより、施設における商品又はサービスの準備状況を車室内で確認することができ、移動中のユーザの感動体験を最大化できる。

なお、上記ではお好み焼きなどの飲食店を施設の一例として、本実施形態を説明したが、本実施形態のシステムは、例えば電気自動車用の充電ステーションに適用してもよい。充電ステーションには、複数の駐車スペースと、各駐車スペースに急速用の充電装置が設けられている。そして、充電ステーションを管理する充電管理装置は、各駐車スペースにおいて、充電装置の利用ステータスと利用時間を管理している。利用ステータスは、例えば「空き状態」、「充電中」、「充電終了（車両駐車中）」等である。利用時間は、車載バッテリの充電時間に相当する。そして、例えば、充電管理装置は、輸送サービス用車両４から、充電装置を利用したい旨の注文及び予約情報を受信すると、充電装置の空き状況を示す情報をサーバ１に送信する。また、予約情報で示される予約時間に、充電装置の空きがない場合には、充電管理装置は、充電装置が利用できる時刻（充電終了時刻に相当）の情報をサーバ１に送信する。そして、サーバ１の配車スケジュール生成部１４は、充電ステーションに、推定到着時刻に到着した時の待ち時間を算出する。配車スケジュール生成部１４は、推定到着時刻に待ち時間を加算することで目標到着時刻を設定して、到着時刻を充電ステーションの空き状況に応じて調整する。また、配車スケジュール生成部１４は、設定された目標到着時刻に到着するように、配車スケジュールを調整する。

また本実施形態のシステムは、相乗りによる車両の利用形態に限らず、１人のユーザを乗せて施設に向かうような利用形態にも適用できる。

なお、本実施形態の変形例に係るシステムでは、ユーザが施設の空き状況を確認し、ユーザが、空き状況に基づき施設への到着時刻を指定し、サーバ１が、端末機２を用いて、ユーザにより指定された到着時刻に輸送サービス用車両４が到着するように、配車スケジュールを作成してもよい。例えば、以下の情報処理がシステムで実行される。まず、サーバ１は、施設を管理する装置から、施設の空き状況の情報を含む施設情報を取得する。空き状況は時間で表される。サーバ１は、施設の空き状況の情報を含む施設情報を端末機２に送信する。端末機２は、ディスプレイに、施設の空き状況を表示する。

ユーザはディスプレイの表示画面を確認して、空き時間の中から予約時間を指定する。端末機２は、ユーザにより指定された予約時間の情報及び端末機２の位置情報をサーバ１に送信する。サーバ１の配車スケジュール生成部１４は、端末機２の位置情報及び予約時間の情報に基づき、輸送サービス用車両４が、施設に予約時間に到着できるように、配車スケジュールを生成する。すなわち、ユーザにより指定された予約時間は、目的地（施設）への到着時刻となる。

これにより、ユーザにより指定された予約時間に対応できるように、到着時刻を調整して、車両の走行を管理できるため、ユーザの利便性を向上できる。

１…サーバ
１１…希望体験受付部
１２…コミュニティ生成部
１３…目的地提案部
１４…配車スケジュール生成部
１５…自動運転制御部
１６…利用者情報記憶部
１７…体験・場所情報記憶部
１８…車両情報記憶部
２…端末機
３…ネットワーク
４…輸送サービス用車両
５…目的地

Claims (15)

1. サーバと、ユーザの端末機と、車両とを含む車両管理システムであって、
   前記端末機は、当該ユーザが希望する希望施設を決定するために必要な希望情報を、前記サーバに送信する送信部を備え、
   前記サーバは、
   前記希望情報に基づき、前記車両の目的地を設定する目的地設定部と、
   前記希望施設の空き状況を示す情報を含む施設情報を取得する施設情報取得部と、を備え、
   前記車両は、
   前記施設情報に基づき当該車両の走行を管理して、当該車両が前記目的地に到着する到着時刻を調整する到着時刻調整部を備え、
   前記サーバは前記目的地への到着予定時刻を算出し、
   前記到着時刻調整部は、
   前記施設情報で示される前記空き状況から、前記到着予定時刻よりも早い時刻に、前記希望施設に空きがある場合には、前記目的地への目標到着時刻が早くなるように、前記到着時刻を調整する車両管理システム。
2. サーバと、ユーザの端末機と、車両とを含む車両管理システムであって、
   前記端末機は、当該ユーザが希望する希望施設を決定するために必要な希望情報を、前記サーバに送信する送信部を備え、
   前記サーバは、
   前記希望情報に基づき、前記車両の目的地を設定する目的地設定部と、
   前記希望施設の空き状況を示す情報を含む施設情報を取得する施設情報取得部と、を備え、
   前記車両は、
   前記施設情報に基づき当該車両の走行を管理して、前記車両が前記目的地に到着する到着時刻を調整する到着時刻調整部を備え、
   前記到着時刻調整部は、複数のユーザのうち最後のユーザが前記車両に乗車した後に、前記車両が前記目的地に到着する前記到着時刻を調整する車両管理システム。
3. 前記サーバは、前記複数のユーザのうち最後のユーザが前記車両に乗車するまでの第１走行計画と、前記最後のユーザが前記車両に乗車した後の第２走行計画を生成する請求項２記載の車両管理システム。
4. 前記サーバは、前記複数のユーザの端末機の位置情報に基づき、前記複数のユーザが相乗りにて前記車両に乗車し、前記目的地に到着するまでの配車スケジュールを作成し、
   前記配車スケジュールは、前記第１走行計画と、前記第２走行計画とを含み、
   前記サーバは、前記車両は、前記第１走行計画を変更せず、前記第２走行計画を変更することで、前記配車スケジュールを変更する請求項３記載の車両管理システム。
5. 前記端末機は、前記端末機の位置情報を前記サーバに送信し、
   前記サーバは、前記端末機の前記位置情報に基づき、前記ユーザが前記車両に乗車する位置情報、前記車両が前記目的地に到着する前記到着時刻の情報を含む配車スケジュールを作成する請求項１又は２のいずれか一項に記載の車両管理システム。
6. 前記サーバは、前記車両が前記目的地に到着するまでの走行ルートを算出し、
   前記車両は、前記走行ルート、及び、前記車両の車速の少なくとも何れか一方を変更することで、前記到着時刻を調整する請求項１又は２のいずれか一項に記載の車両管理システム。
7. 前記サーバは、
   複数のユーザの前記端末機から、前記端末機の位置情報を取得し、
   前記複数のユーザの端末機の前記位置情報に基づき、前記複数のユーザが相乗りにて前記車両に乗車し、前記目的地に到着するまでの配車スケジュールを作成する請求項１又は２のいずれか一項に記載の車両管理システム。
8. 前記サーバは、
   前記希望施設の予約時間を管理し、
   前記目的地への到着時刻を推定し、
   推定された前記到着時刻に対応するように、前記予約時間を変更し、
   変更された前記予約時間を含む情報を、前記希望施設を管理する装置に送信する請求項１〜７のいずれか一項に記載の車両管理システム。
9. 前記サーバは、前記希望施設を管理する装置から、前記希望施設におけるサービス又は商品の提供時間に関する時間情報を取得し、
   前記車両は、前記時間情報に基づいて前記到着時刻を調整する請求項１〜８のいずれか一項に記載の車両管理システム。
10. 前記サーバは、
    前記希望施設を管理する装置から、前記希望施設における調理状況を示す情報を取得し、
    前記調理状況を示す情報を前記車両に対して送信し、
    前記車両に設けられたディスプレイは前記調理状況を表示する請求項１〜９のいずれか一項に記載の車両管理システム。
11. 前記希望施設を管理する装置から、前記希望施設の空き時間に関する情報を前記サーバにて取得し、
    前記サーバから、前記希望施設の空き時間に関する情報を前記ユーザの端末機に送信し、
    前記ユーザの端末機から、前記空き時間に基づきユーザにより指定された、前記目的地への前記到着時刻に関する情報、及び、前記ユーザの端末機の位置情報を前記サーバにて取得し、
    前記サーバにおいて、前記ユーザが前記車両に乗車する位置情報、前記車両が前記目的地に到着する到着時刻の情報を含む配車スケジュールを作成する請求項１又は２のいずれか一項に記載の車両管理システム。
12. ユーザの端末機から、当該ユーザが希望する希望施設に関する情報を含む希望情報を取得する希望情報取得部と、
    前記希望情報に基づき、車両の目的地を設定する目的地設定部と、
    前記希望施設の空き状況を示す施設情報を取得する施設情報取得部と、
    前記施設情報に基づき前記車両の走行を管理することで、前記車両が前記目的地に到着する到着時刻を調整する到着時刻調整部と、を備え、
    前記到着時刻調整部は、
    前記施設情報で示される前記空き状況から、前記目的地への到着予定時刻よりも早い時刻に、前記希望施設に空きがある場合には、前記目的地への目標到着時刻が早くなるように、前記到着時刻を調整する車両管理装置。
13. ユーザの端末機から、当該ユーザが希望する希望施設に関する情報を含む希望情報を取得する希望情報取得部と、
    前記希望情報に基づき、車両の目的地を設定する目的地設定部と、
    前記希望施設の空き状況を示す施設情報を取得する施設情報取得部と、
    前記施設情報に基づき前記車両の走行を管理することで、前記車両が前記目的地に到着する到着時刻を調整する到着時刻調整部と、を備え
    前記到着時刻調整部は、複数のユーザのうち最後のユーザが前記車両に乗車した後に、前記車両が前記目的地に到着する前記到着時刻を調整する車両管理装置。
14. サーバを用いて、車両の走行を管理する車両管理方法において、
    ユーザの端末機から、当該ユーザが希望する希望施設を決定するために必要な希望情報を、前記サーバにて取得し、
    前記サーバにおいて、前記希望情報に基づき、車両の目的地を設定し、
    前記希望施設の空き状況を示す情報を含む施設情報を前記サーバにて取得し、
    前記サーバにおいて、前記施設情報に基づき前記車両の走行を管理して、前記車両が前記目的地に到着する到着時刻を調整し、
    前記サーバにおいて、前記施設情報で示される前記空き状況から、前記目的地への到着予定時刻よりも早い時刻に、前記希望施設に空きがある場合には、前記目的地への目標到着時刻が早くなるように、前記到着時刻を調整する車両管理方法。
15. サーバを用いて、車両の走行を管理する車両管理方法において、
    ユーザの端末機から、当該ユーザが希望する希望施設を決定するために必要な希望情報を、前記サーバにて取得し、
    前記サーバにおいて、前記希望情報に基づき、車両の目的地を設定し、
    前記希望施設の空き状況を示す情報を含む施設情報を前記サーバにて取得し、
    前記サーバにおいて、前記施設情報に基づき前記車両の走行を管理して、複数のユーザのうち最後のユーザが前記車両に乗車した後に、前記車両が前記目的地に到着する到着時刻を調整する車両管理方法。
    

Images