特許 7601843 制御装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-12-09

(45)【発行日】2024-12-17

(54)【発明の名称】制御装置

(51)【国際特許分類】

   G06Q 50/40 20240101AFI20241210BHJP

   G01C 21/34 20060101ALI20241210BHJP

【ＦＩ】

G06Q50/40

G01C21/34

【請求項の数】 4

(21)【出願番号】P 2022161225

(22)【出願日】2022-10-05

(65)【公開番号】P2024054776

(43)【公開日】2024-04-17

【審査請求日】2023-11-01

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(73)【特許権者】

【識別番号】519182659

【氏名又は名称】ＭＯＮＥＴ Ｔｅｃｈｎｏｌｏｇｉｅｓ株式会社

(74)【代理人】

【識別番号】100147485

【弁理士】

【氏名又は名称】杉村 憲司

(74)【代理人】

【識別番号】230118913

【弁護士】

【氏名又は名称】杉村 光嗣

(74)【代理人】

【識別番号】100187078

【弁理士】

【氏名又は名称】甲原 秀俊

(74)【代理人】

【識別番号】100220674

【弁理士】

【氏名又は名称】小山 祐

(72)【発明者】

【氏名】野勢 健太

(72)【発明者】

【氏名】橋本 賢明

【審査官】菅原 浩二

(56)【参考文献】

【文献】特開２０１６－１７６９０３（ＪＰ，Ａ）

【文献】特開２０２１－０７７９６４（ＪＰ，Ａ）

【文献】特開２００９－１４０３７２（ＪＰ，Ａ）

【文献】特開２０１２－０７８１１２（ＪＰ，Ａ）

【文献】特開２００８－０９６４４５（ＪＰ，Ａ）

【文献】特開２０２０－０１６９６７（ＪＰ，Ａ）

【文献】特開２０１２－２２５８２０（ＪＰ，Ａ）

【文献】特開２０２０－０５６７３９（ＪＰ，Ａ）

【文献】特開２００９－０５８４６８（ＪＰ，Ａ）

【文献】特開２０１１－１６３７８８（ＪＰ，Ａ）

【文献】特開２０２２－０１２５３３（ＪＰ，Ａ）

【文献】特開２０２１－１４９３１６（ＪＰ，Ａ）

【文献】米国特許出願公開第２０２０／０３７８７７５（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

Ｇ０１Ｃ ２１／３４

(57)【特許請求の範囲】

【請求項1】

記憶部と、通信部と、制御部とを備える制御装置であって、
前記通信部は、ユーザの端末装置と、モビリティサービスを利用した経路探索をそれぞれ実行する複数のサーバ装置と通信し、
前記制御部は、
前記端末装置からユーザの移動要求を示す移動要求情報を、前記通信部を介して取得すると、前記ユーザの体調情報、前記ユーザのスケジュール情報、移動予定日時の天候情報、及び前記移動予定日時の曜日を示す曜日情報のうち少なくとも１つに基づいて、前記経路探索に関する要求仕様を決定し、
前記要求仕様と、前記記憶部に格納された、複数のモビリティサービスのそれぞれの仕様を示す仕様情報とに基づいて、前記複数のモビリティサービスの中から少なくとも１つの候補サービスを選択し、
前記複数のサーバ装置のうち、選択した前記少なくとも１つの候補サービスに対応するサーバ装置のＡＰＩの入力形式に応じた、前記少なくとも１つの候補サービスを利用した経路探索の検索要求を、前記サーバ装置へ前記通信部を介して送信し、
前記経路探索の結果を、前記サーバ装置から前記通信部を介して取得し、前記結果を前記端末装置へ前記通信部を介して送信し、
前記要求仕様は、前記モビリティサービスを利用した経路探索の結果のレスポンス速度、前記モビリティサービスを利用した経路探索を行うための出発時刻又は到着時刻の時間的許容幅、前記モビリティサービスを利用した経路探索を行うための出発位置又は到着位置の位置的許容幅、前記モビリティサービスの相乗り可否の少なくとも１つを含む、制御装置。

【請求項2】

請求項１に記載の制御装置であって、
前記制御部は、前記体調情報が、前記ユーザの体調が悪いことを示す場合、前記要求仕様としてのレスポンス速度を速い程度に決定する、制御装置。

【請求項3】

請求項１に記載の制御装置であって、
前記制御部は、前記スケジュール情報が、前記ユーザが勤務中であることを示す場合、前記要求仕様としての相乗り可否を相乗り不可と決定する、制御装置。

【請求項4】

請求項１から３のいずれか１項に記載の制御装置であって、
前記制御部は、前記体調情報、前記スケジュール情報、前記天候情報、及び前記曜日情報と、前記モビリティサービスとを対応付けた対応情報を取得し、前記対応情報に基づいて前記候補サービスを選択する、制御装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、制御装置に関する。

【背景技術】

【0002】

従来、ルーティングエンジンを用いて経路を探索する技術が知られている。例えば特許文献１には、経路検索エンジンを用いて経路検索を行うサーバについて開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１０－２６４９３７号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

ルーティングエンジンごとに専用ＡＰＩが提供されることが一般的であり、１つのＡＰＩ（Application Program Interface）で複数のエンジンを使い分けることはされていない。互いに仕様の異なる様々なモビリティサービスの専用ＡＰＩを利用しようとする場合、入力項目の違いから処理が煩雑になり得る。このように、モビリティサービスの経路探索を行う技術には改善の余地があった。

【0005】

かかる事情に鑑みてなされた本開示の目的は、モビリティサービスの経路探索を行う技術を改善することにある。

【課題を解決するための手段】

【0006】

本開示の一実施形態に係る制御装置は、ユーザの端末装置からユーザの移動要求を示す移動要求情報を取得すると、前記ユーザの体調情報、前記ユーザのスケジュール情報、移動予定日時の天候情報、及び前記移動予定日の曜日情報のうち少なくとも１つの情報に基づいて、複数のモビリティサービスの中から少なくとも１つを候補サービスとして選択し、前記少なくとも１つの候補サービスを利用した経路探索の結果を取得し、前記結果を前記端末装置へ送信する制御部を備える。

【発明の効果】

【0007】

本開示の一実施形態によれば、モビリティサービスの経路探索を行う技術を改善することが可能となる。

【図面の簡単な説明】

【0008】

【図1】第１実施形態に係るシステムの概略構成を示すブロック図である。

【図2】第１実施形態に係る制御装置の動作を示すフローチャートである。

【図3】第１実施形態に係る要求仕様の例を示す図である。

【図4】第１実施形態に係る仕様情報の例を示す図である。

【図5】第２実施形態に係る対応情報の例を示す図である。

【発明を実施するための形態】

【0009】

（第１実施形態）
以下、本発明の第１実施形態について説明する。まず図１を参照して本開示の実施形態に係るシステム１の概要について説明する。システム１は、制御装置１０と、サーバ装置２０Ａから２０Ｄと、端末装置３０とを備える。各装置は例えばインターネットを含むネットワーク４０を介して互いに通信可能に接続される。図１には４つのサーバ装置が示されているがシステム１が備えるサーバ装置の数はこれに限定されない。以下、サーバ装置２０Ａからサーバ装置２０Ｄを特に区別しない場合、単に「サーバ装置２０」と記載する。

【0010】

制御装置１０は、データセンタ等の施設に設置される。制御装置１０は、例えば、クラウドコンピューティングシステム又はその他のコンピューティングシステムに属するサーバである。制御装置１０はモビリティサービスを用いた経路検索の結果を取得するためのＡＰＩ１００を提供する。以下で説明するように、制御装置１０は、複数のモビリティサービスから選択した候補サービスに係るサーバ装置２０に対し経路探索の要求を行い、経路探索の結果を、当該ＡＰＩ１００を介して提供する。

【0011】

サーバ装置２０は、各モビリティサービスを提供する事業者の施設等に設置される。サーバ装置２０は例えばクラウドコンピューティングシステム又はその他のコンピューティングシステムに属するサーバである。図１のサーバ装置２０Ａから２０Ｄのそれぞれは、制御部と、通信部と、記憶部とを備え、当該記憶部はルーティングエンジンを格納している。ルーティングエンジンは、各事業者が提供するモビリティサービスによって出発地から目的地までの経路を検索するためのアプリケーションプログラムである。例えばサーバ装置２０Ａはタクシー事業者によって管理されており、サーバ装置２０Ａが備えるルーティングエンジンは、タクシーで移動する場合の経路探索を実行可能なプログラムである。

【0012】

サーバ装置２０Ａから２０Ｄのそれぞれは、ルーティングエンジンを使用して経路探索した結果を取得するためのＡＰＩ２００ＡからＡＰＩ２００Ｄをそれぞれ提供する。以下、ＡＰＩ２００ＡからＡＰＩ２００Ｄを特に区別しない場合、単に「ＡＰＩ２００」と記載する。

【0013】

端末装置３０は、複数のユーザのそれぞれによって保持され、使用される。端末装置３０は例えば、携帯電話機、スマートフォン、又はタブレットなどのモバイル機器である。

【0014】

ネットワーク４０は、インターネット、少なくとも１つのＷＡＮ、少なくとも１つのＭＡＮ、又はこれらの組み合わせを含む。「ＷＡＮ」は、wide area networkの略語である。「ＭＡＮ」は、metropolitan area networkの略語である。ネットワーク４０は、少なくとも１つの無線ネットワーク、少なくとも１つの光ネットワーク、又はこれらの組み合わせを含んでもよい。無線ネットワークは、例えば、アドホックネットワーク、セルラーネットワーク、無線ＬＡＮ、衛星通信ネットワーク、又は地上マイクロ波ネットワークである。「ＬＡＮ」は、local area networkの略語である。

【0015】

まず、本実施形態の概要について説明し、詳細については後述する。制御装置１０は、ユーザの端末装置３０からユーザの移動要求を示す移動要求情報を取得すると、ユーザの体調情報、ユーザのスケジュール情報、移動予定日時の天候情報、及び移動予定日の曜日情報のうち少なくとも１つの情報に基づいて、複数のモビリティサービスの中から少なくとも１つを候補サービスとして選択し、少なくとも１つの候補サービスを利用した経路探索の結果を取得し、結果を端末装置３０へ送信する。

【0016】

移動要求情報は、移動予定日時と、出発地と、目的地とを含む。これに限られず、移動要求情報はユーザの移動に関する任意の情報を含んでよい。図１において、第１の検索要求は端末装置３０から制御装置１０へ行う経路探索の要求を、第２の検索要求は制御装置１０からサーバ装置２０へ行う経路探索の要求をそれぞれ表す。端末装置３０から、移動要求情報を含む第１の検索要求が、制御装置１０のＡＰＩ１００を介して制御装置１０に送信される。制御装置１０は移動要求情報を受信すると、以下で説明するように、各種情報に基づきモビリティサービスに対する要求仕様を決定し、複数のサーバ装置２０に係るモビリティサービスのうち適合したモビリティサービスを候補サービスとして選択する。モビリティサービスは、バス、電車、タクシー、シェアリングカー等の移動手段を含む。

【0017】

制御装置１０は、少なくとも１つの選択した候補サービスに係るサーバ装置２０が提供するＡＰＩ２００を介して、ユーザの移動要求情報に基づいた第２の検索要求を送信する。このとき制御装置１０は、該ＡＰＩ２００の入力形式に応じた第２の検索要求を送信できる。該第２の検索要求を受信したサーバ装置２０は、ルーティングエンジンを用いて経路探索を実行し、結果を、ＡＰＩ２００を介して制御装置１０へ送信して返す。制御装置１０は、受信した当該結果を、ＡＰＩ１００を介して端末装置３０へ送信して返す。

【0018】

本実施形態によれば、ユーザは制御装置１０に対し経路探索の要求をするだけで、制御装置１０によって自動的に選択されたモビリティサービスによる経路探索の結果を取得できる。複数のモビリティサービスの中から、ユーザにとって適切なサービスが自動的に選択されるため、モビリティサービスの経路探索を行う技術を改善することが可能となる。

【0019】

次に、システム１が備える制御装置１０の構成について詳細に説明する。図１に示すように、制御装置１０は、制御部１１と、記憶部１２と、通信部１３とを備える。

【0020】

制御部１１には、少なくとも１つのプロセッサ、少なくとも１つの専用回路又はこれらの組み合わせが含まれる。プロセッサはＣＰＵ若しくはＧＰＵ等の汎用プロセッサ又は特定の処理に特化した専用プロセッサである。「ＣＰＵ」はcentral processing unitの略語である。「ＧＰＵ」はgraphics processing unitの略語である。専用回路は例えば、ＦＰＧＡ又はＡＳＩＣである。「ＦＰＧＡ」はfield-programmable gate arrayの略語である。「ＡＳＩＣ」はapplication specific integrated circuitの略語である。制御部１１は制御装置１０の各部を制御しながら、制御装置１０の動作に関わる処理を実行する。

【0021】

記憶部１２には、少なくとも１つの半導体メモリ、少なくとも１つの磁気メモリ、少なくとも１つの光メモリ又はこれらのうち少なくとも２種類の組み合わせが含まれる。半導体メモリは例えばＲＡＭ又はＲＯＭである。「ＲＡＭ」はrandom access memoryの略語である。「ＲＯＭ」はread only memoryの略語である。ＲＡＭは例えばＳＲＡＭ又はＤＲＡＭである。「ＳＲＡＭ」はstatic random access memoryの略語である。「ＤＲＡＭ」はdynamic random access memoryの略語である。ＲＯＭは例えばＥＥＰＲＯＭである。「ＥＥＰＲＯＭ」はelectrically erasable programmable read only memoryの略語である。記憶部１２は例えば主記憶装置、補助記憶装置又はキャッシュメモリとして機能する。記憶部１２には制御装置１０の動作に用いられる情報と、制御装置１０の動作によって得られた情報とが記憶される。例えば記憶部１２はシステムプログラム、アプリケーションプログラム、データベース及び地図情報等を記憶してもよい。記憶部１２に記憶された情報は通信部１３を介してネットワーク４０から取得される情報で更新可能であってもよい。

【0022】

通信部１３には、少なくとも１つの通信用インタフェースが含まれる。通信用インタフェースは、例えば、ＬＡＮインタフェースである。通信部１３は、制御装置１０の動作に用いられる情報を受信し、また制御装置１０の動作によって得られる情報を送信する。

【0023】

制御装置１０の機能は、本実施形態に係る制御プログラムを制御部１１に相当するプロセッサで実行することにより実現される。すなわち制御装置１０の機能は、ソフトウェアにより実現される。制御プログラムは制御装置１０の動作をコンピュータに実行させることで、コンピュータを制御装置１０として機能させる。すなわちコンピュータは制御プログラムに従って制御装置１０の動作を実行することにより制御装置１０として機能する。

【0024】

プログラムは、非一時的なコンピュータ読取り可能な媒体に記憶しておくことができる。非一時的なコンピュータ読取り可能な媒体は、例えば、磁気記録装置、光ディスク、光磁気記録媒体、又はＲＯＭである。プログラムの流通は、例えば、プログラムを記憶したＤＶＤ又はＣＤ－ＲＯＭなどの可搬型媒体を販売、譲渡、又は貸与することによって行う。「ＤＶＤ」は、digital versatile discの略語である。「ＣＤ－ＲＯＭ」は、compact disc read only memoryの略語である。プログラムをサーバのストレージに格納しておき、サーバから他のコンピュータにプログラムを転送することにより、プログラムを流通させてもよい。プログラムをプログラムプロダクトとして提供してもよい。

【0025】

コンピュータは、例えば、可搬型媒体に記憶されたプログラム又はサーバから転送されたプログラムを、一旦、主記憶装置に格納する。そして、コンピュータは、主記憶装置に格納されたプログラムをプロセッサで読み取り、読み取ったプログラムに従った処理をプロセッサで実行する。コンピュータは、可搬型媒体から直接プログラムを読み取り、プログラムに従った処理を実行してもよい。コンピュータは、コンピュータにサーバからプログラムが転送される度に、逐次、受け取ったプログラムに従った処理を実行してもよい。サーバからコンピュータへのプログラムの転送は行わず、実行指示及び結果取得のみによって機能を実現する、いわゆるＡＳＰ型のサービスによって処理を実行してもよい。「ＡＳＰ」は、application service providerの略語である。プログラムには、電子計算機による処理の用に供する情報であってプログラムに準ずるものが含まれる。例えば、コンピュータに対する直接の指令ではないがコンピュータの処理を規定する性質を有するデータは、「プログラムに準ずるもの」に該当する。

【0026】

制御装置１０の一部又は全ての機能が、制御部１１としてのプログラマブル回路又は専用回路により実現されてもよい。すなわち、制御装置１０の一部又は全ての機能が、ハードウェアにより実現されてもよい。

【0027】

次に、システム１が備える端末装置３０の構成を説明する。端末装置３０は、制御部３１と、記憶部３２と、通信部３３と、入出力部３４とを備える。

【0028】

制御部３１には、少なくとも１つのプロセッサ、少なくとも１つの専用回路、又はこれらの組み合わせが含まれる。プロセッサは、ＣＰＵ若しくはＧＰＵ等の汎用プロセッサ、又は特定の処理に特化した専用プロセッサである。専用回路は、例えば、ＦＰＧＡ又はＡＳＩＣである。制御部３１は、端末装置３０の各部を制御しながら、端末装置３０の動作に関わる処理を実行する。

【0029】

記憶部３２には、少なくとも１つの半導体メモリ、少なくとも１つの磁気メモリ、少なくとも１つの光メモリ、又はこれらのうち少なくとも２種類の組み合わせが含まれる。半導体メモリは、例えば、ＲＡＭ又はＲＯＭである。ＲＡＭは、例えば、ＳＲＡＭ又はＤＲＡＭである。ＲＯＭは、例えば、ＥＥＰＲＯＭである。記憶部３２は、例えば、主記憶装置、補助記憶装置、又はキャッシュメモリとして機能する。記憶部３２には、端末装置３０の動作に用いられる情報と、端末装置３０の動作によって得られた情報とが記憶される。

【0030】

通信部３３には、少なくとも１つの通信用インタフェースが含まれる。通信用インタフェースは、例えば、ＬＴＥ、４Ｇ規格、若しくは５Ｇ規格等の移動通信規格に対応したインタフェース、Bluetooth（登録商標）等の近距離無線通信に対応したインタフェース、又はＬＡＮインタフェースである。「ＬＴＥ」は、Long Term Evolutionの略語である。「４Ｇ」は、4th generationの略語である。「５Ｇ」は、5th generationの略語である。通信部３３は、端末装置３０の動作に用いられる情報を受信し、また端末装置３０の動作によって得られる情報を送信する。

【0031】

入出力部３４は、ユーザによる入力を検出し、入力情報を制御部３１に送る入力インタフェースを含む。入力インタフェースは、たとえば、物理キー、静電容量キー、パネルディスプレイと一体的に設けられたタッチスクリーン、または音声入力を受け付けるマイクロフォン等であるが、これらに限られず、任意の入力部であってもよい。入出力部３４は、制御部３１が生成した情報又は記憶部３２から読み出された情報を、ユーザに対して出力する出力インタフェースを含む。出力インタフェースは、例えば、情報を画像で出力するパネルディスプレイ、又は情報を音声で出力するスピーカ等であるが、これらに限られず、任意の出力部であってよい。入出力部３４は、通信部３３を介して取得した情報を、ユーザに対して音声又は画面表示等により通知することができる。入出力部３４は、端末装置３０に備えられる代わりに、外部の出力機器として端末装置３０に接続されてもよい。

【0032】

端末装置３０の機能は、本実施形態に係る端末プログラムを、制御部３１に含まれるプロセッサで実行することにより実現される。すなわち、端末装置３０の機能は、ソフトウェアにより実現される。端末プログラムは、端末装置３０の動作に含まれるステップの処理をコンピュータに実行させることで、当該ステップの処理に対応する機能をコンピュータに実現させるためのプログラムである。すなわち、端末プログラムは、コンピュータを端末装置３０として機能させるためのプログラムである。

【0033】

端末装置３０の一部又は全ての機能が、制御部３１に含まれる専用回路により実現されてもよい。すなわち、端末装置３０の一部又は全ての機能が、ハードウェアにより実現されてもよい。

【0034】

図２から図４を参照して、本実施形態に係る制御装置１０の動作について説明する。この動作は、本実施形態に係る制御方法に相当する。以下において、制御装置１０は、外部の各装置との情報の送受信を、通信部１３及びネットワーク４０を介して行う。

【0035】

図２のステップＳ１において、制御装置１０の制御部１１はユーザの移動要求情報を取得する。移動要求情報の取得には任意の手法が採用されてよい。本実施形態では、端末装置３０から移動要求情報を含む第１の検索要求が制御装置１０へ送信される。制御部１１は移動要求情報が含む情報を、ＡＰＩ１００への入力値として受信することで取得する。

【0036】

ステップＳ２において、制御部１１は、ユーザの体調を示す体調情報を取得する。体調情報の取得には任意の手法が採用されてよい。本実施形態では、制御部１１は端末装置３０から体調情報を受信することで取得する。

【0037】

本実施形態では、体調情報はユーザの体調の程度を０から１０の段階的な数値で示す。当該数値は１から１０に近づく程体調が良いことを示す。制御部１１は、複数のユーザの平均値と比較して体調の程度を算出してもよいし、ユーザの過去の履歴と比較して算出してもよい。体調情報は病気又は怪我の有無、体温等、任意の情報を含んでもよい。

【0038】

以下のステップＳ３、５、７、及び９において、制御部１１は、取得した各情報に基づいて対応する各要求仕様の値を決定する。要求仕様とは、制御部１１が以下で説明するように経路探索に用いるルーティングエンジンを最終的に決定するための、ルーティングエンジン又はモビリティサービスの仕様をいう。ルーティングエンジン又はモビリティサービスの仕様は「レスポンス速度」、「時間的許容幅」、「位置的許容幅」、及び「相乗り可否」を含む。仕様はこれらに限られず、例えばペット同伴の可否等、任意の仕様を含んでよい。以下で説明するように、ルーティングエンジンのそれぞれについて、これらの仕様は予め設定されている。

【0039】

「レスポンス速度」は、サーバ装置２０においてルーティングエンジンにより経路探索の結果を取得できる速度をいい、本実施形態ではレスポンス速度の程度をＲ１からＲ１０の段階的な数値で示す。レスポンス速度は、経路探索の条件が複雑化すると一般的に遅くなる。例えばモビリティサービスが相乗り可能なシェアリングカーであり、当該相乗りを希望するユーザが複数存在する場合であって、各ユーザの出発地と目的地とがそれぞれ異なる場合、当該シェアリングカーの経路探索は、路線バス等のモビリティサービスの経路探索と比較して複雑となり、レスポンス速度は遅くなる。

【0040】

「時間的許容幅」は、各モビリティサービスの経路検索が実行されるときに必要な最小の時間幅であり、本実施形態では時間的許容幅の程度をＴ１からＴ１０の段階的な数値で示す。時間的許容幅は、出発時刻又は到着時刻についてユーザの希望に沿えない可能性の高いモビリティサービスほど大きくなる。例えばユーザが出発時刻を指定して配車されるタクシーの時間的許容幅の程度はＴ２と小さく、一方で路線バスの時間的許容幅の程度はＴ９と大きい。以下で説明するように、制御部１１は、時間的許容幅の仕様がユーザの要求仕様より小さい程度であるモビリティサービスを候補サービスとして選択してよい。例えば、ユーザの要求仕様がＴ５、モビリティサービスとしての路線バスの仕様がＴ９、タクシーの仕様がＴ２であるとき、制御部１１はユーザの要求仕様よりも小さい程度の仕様であるタクシーを候補サービスとして選択してよい。

【0041】

「位置的許容幅」は、各モビリティサービスの経路検索が実行されるときに必要な最小の位置幅であり、本実施形態では位置的許容幅の程度をＰ１からＰ１０の段階的な数値で示す。位置的許容幅は、出発位置又は到着位置についてユーザの希望に沿えない可能性の高いモビリティサービスほど大きくなる。例えばユーザが出発位置を指定して配車されるタクシーの位置的許容幅の程度はＰ２と小さく、一方で路線バスの位置的許容幅の程度はＰ９と大きい。以下で説明するように、制御部１１は、位置的許容幅の仕様がユーザの要求仕様より小さい程度であるモビリティサービスを候補サービスとして選択してよい。例えば、ユーザの要求仕様がＰ５、モビリティサービスとしての路線バスの仕様がＰ９、タクシーの仕様がＰ２であるとき、制御部１１はユーザの要求仕様よりも小さい程度の仕様であるタクシーを候補サービスとして選択してよい。

【0042】

「相乗り可否」は、モビリティサービスが相乗り可能であるかを示す。相乗りが可能なモビリティサービスは、複数のユーザを一台の車両に乗せて移動することが可能である。

【0043】

ステップＳ３において制御部１１は、取得した体調情報に基づいて要求仕様を決定する。制御部１１は１から１０の体調の程度それぞれに対し、要求仕様のレスポンス速度の程度を決定する。

【0044】

制御部１１による要求仕様の決定の手法には任意の手法が採用されてよく、以下のステップＳ５、７、９においても同様である。また、制御部１１が各種情報に基づいて決定する要求仕様の値は一例であり、自由に設定されてよく、以下のステップＳ５、７、９においても同様である。

【0045】

本実施形態においてユーザの体調が悪く、体調情報が２の値を示すとする。制御部１１は、レスポンス速度についてＲ２の値を決定する。これにより最終的に候補サービスを選択するとき、制御部１１は、体調が悪く、家又は病院等への移動を望んでいると推定されるユーザに対し、素早く経路探索結果を取得可能なモビリティサービスを選択できる。

【0046】

体調情報に基づいて決定される要求仕様はレスポンス速度に限られない。例えば制御部１１は、上述のレスポンス速度に代えて、又は加えて、相乗り可否を決定してもよい。この場合制御部１１は、体調の程度が１に近い程、要求仕様として「相乗り可」であることを決定してよい。これにより制御部１１は、体調が悪く感染症を患った可能性のあるユーザに対し、他人と同乗する必要の無いモビリティサービスを最終的に選択できる。

【0047】

ステップＳ４において、制御部１１は、移動予定日時におけるユーザのスケジュールを示すスケジュール情報を取得する。スケジュール情報の取得には任意の手法が採用されてよい。制御部１１は端末装置３０からスケジュール情報を受信することで取得してよい。

【0048】

本実施形態では、スケジュール情報は「勤務中」「勤務時間外」又は「休務中」のいずれかを示す。これに限られず、スケジュール情報は任意の情報を含んでよい。

【0049】

ステップＳ５において、制御部１１は、取得したスケジュール情報に基づいて要求仕様を決定する。制御部１１は、例えばスケジュール情報が勤務中を示す場合に、時間的許容幅についてＴ３の値を決定し、スケジュール情報が示すユーザのスケジュールが勤務時間外又は休務中である場合に、Ｔ５の値を決定する。これにより最終的に候補サービスを選択するとき、制御部１１は、勤務中のユーザに対してなるべく時間に融通が効くモビリティサービスを選択できる。本実施形態において、スケジュール情報が休務中を示すとする。制御部１１は、時間的許容幅をＴ５と決定する。

【0050】

スケジュール情報に基づいて決定される要求仕様は時間的許容幅に限られない。例えば制御部１１は、上述の時間的許容幅に代えて、又は加えて、レスポンス速度を決定してもよい。この場合制御部１１は、スケジュール情報が勤務中である場合、勤務時間外又は休務中である場合に比較してレスポンス速度を早い値に決定してもよい。これにより制御部１１は、勤務中のユーザに対し、素早く経路検索の結果を取得可能なモビリティサービスを最終的に選択できる。

【0051】

ステップＳ６において制御部１１は、移動予定日時の天候を示す天候情報を取得する。天候情報の取得には任意の手法が採用されてよい。制御部１１は、ユーザの指定する出発地を含む領域の気象を予測する気象観測センタのデータベース等の外部装置と通信し、当該外部装置から天候情報を受信することで取得してもよい。

【0052】

本実施形態では、天候情報は「雨」「曇り」「晴れ」等の天候を示す。これに限られず、天候情報は降水確率、気温、湿度等任意の情報を含んでよい。

【0053】

ステップＳ７において制御部１１は、取得した天候情報に基づいて要求仕様を決定する。制御部１１は、例えば天候情報が雨を示す場合に位置的許容幅についてＰ３の値を決定し、天候情報が曇り又は晴れを示す場合にＰ５の値を決定する。これにより最終的に候補サービスを選択するとき、制御部１１はユーザに対し、天候が悪い場合はモビリティサービスへの乗車場所又は降車場所の融通がより効きやすいサービスを選択できる。本実施形態において天候情報が雨を示すとする。制御部１１は、位置的許容幅をＰ３と決定する。

【0054】

天候情報に基づいて決定される要求仕様は位置的許容幅に限られない。例えば制御部１１は、上述の位置的許容幅に代えて、又は加えて、要求仕様としての「屋外の乗り換え有無」を決定してもよい。これにより最終的に候補サービスを選択するとき、制御部１１は、悪天候下で屋外の乗り換えをせずに移動可能なモビリティサービスを選択できる。

【0055】

ステップＳ８において制御部１１は、移動予定日時の曜日を示す曜日情報を取得する。曜日情報の取得には任意の手法が採用されてよい。

【0056】

本実施形態では、曜日情報は、「平日」と、土曜、日曜及び祝日を含む「休日」とを示す。これに限られず、曜日情報は曜日に関連した任意の情報を含んでよい。

【0057】

ステップＳ９において制御部１１は、取得した曜日情報に基づいて要求仕様を決定する。制御部１１は、例えば曜日情報が平日を示す場合に相乗り不可とすることを決定し、曜日情報が休日を示す場合に相乗り可とすることを決定する。これにより最終的に候補サービスを選択するとき、平日の移動中にユーザが仕事を行う可能性が推定される場合、制御部１１は相乗り不可であるモビリティサービスを選択できる。本実施形態では曜日情報が平日を示すとする。制御部１１は相乗り可否について相乗り不可とすることを決定する。

【0058】

曜日情報に基づいて決定される要求仕様は相乗り可否に限られない。例えば制御部１１は、上述の相乗り可否に代えて、又は加えて、レスポンス速度を決定してもよい。この場合制御部１１は、曜日情報が平日である場合、休日である場合に比較してレスポンス速度を早い値に決定してもよい。これにより制御部１１は、平日に勤務中であることが推定されるユーザに対し、素早く経路探索結果を取得可能なモビリティサービスを最終的に選択できる。

【0059】

上述に限られず、各情報に基づいた要求仕様の決定には任意の手法が採用されてよい。例えば要求仕様はユーザによって予め設定されてもよい。例えば制御部１１は取得した各種情報のうち２つ以上の組み合わせに基づき、少なくとも１つの要求仕様を決定してもよい。例えば制御部１１は、体調情報が示すユーザの体調が５以上の値であり、スケジュール情報が休務中を示し、天候情報が晴れを示し、曜日情報が休日を示す場合に、要求仕様としての相乗り可否について相乗り可とすることを決定してもよい。これにより制御部１１は、休日の天候が良い日にユーザが外出するとき、相乗りがあることを推定し、ユーザが友人等と一緒に移動できるモビリティサービスを選択できる。制御部１１は当該推定を、ユーザの過去の行動履歴に基づいて行ってもよい。

【0060】

図３はステップＳ３、５、７及び９において決定された、モビリティサービスに対するユーザの要求仕様を示す表である。図３を参照すると、レスポンス速度はＲ２の値、時間的許容幅はＴ５の値、位置的許容幅はＰ３の値、相乗り可否は相乗り不可とすることが決定されている。

【0061】

ステップＳ１０において、制御部１１は決定した要求仕様に適合するモビリティサービスを候補サービスとして少なくとも１つ選択する。選択には任意の手法が採用されてよい。本実施形態では、制御部１１は、記憶部１２に格納された、各モビリティサービスとその仕様とが予め登録された仕様情報を参照して候補サービスを選択する。

【0062】

図４は仕様情報の例を表形式で示す。仕様情報の形式は表形式に限られない。第１列は各モビリティサービスの名称を示し、第２列から第５列はモビリティサービスの仕様であるレスポンス速度、時間的許容幅、位置的許容幅、及び相乗り可否のそれぞれを表す。制御部１１は、図３の要求仕様と適合するモビリティサービスを候補サービスとして選択する。本実施形態では制御部１１は、図４の仕様情報のうち、レスポンス速度の仕様がステップＳ３で決定した要求仕様以下の程度であり、時間的許容幅の仕様がステップＳ５で決定した要求仕様以下の程度であり、位置的許容幅の仕様がステップＳ７で決定した要求仕様以下の程度であり、相乗り可否の仕様がステップＳ９で決定した要求仕様と同様である、モビリティサービスＡを候補サービスとして選択する。

【0063】

ステップＳ１１において、制御部１１は、ステップＳ１０で選択したモビリティサービスに対して、ユーザの移動要求情報に基づいて経路検索の要求を行う。具体的には、制御部１１は、選択したモビリティサービスを提供する事業者のサーバ装置２０に、ＡＰＩ２００を介して第２の検索要求を送信する。この場合制御部１１は、当該ＡＰＩ２００の入力形式に応じてユーザの移動要求情報の入力値を変換できてよい。制御部１１は複数の候補サービスを選択した場合、複数の候補サービスに対して経路検索の要求を行ってよい。

【0064】

例えばステップＳ１０で選択した候補サービスに係るサーバ装置２０が提供するＡＰＩ２００の入力形式において、相乗り要否の入力値が必要であり、ステップＳ１で取得されたユーザの移動要求情報が相乗り要否についての情報を含んでいなかったとする。この場合制御部１１は、相乗り要否の入力値を自動的に決定し、ＡＰＩ２００の入力形式に適合させて検索の要求を送信できてよい。制御部１１が自動的に決定する入力値は予め設定されていてもよいし、制御部１１が過去のユーザの入力の履歴に基づいて決定してもよい。これにより、ＡＰＩ２００への入力形式がモビリティサービスごとに異なっていても、各サーバ装置２０へ円滑に経路探索の要求が行われる。サーバ装置２０の制御部は、ＡＰＩ２００への入力値に基づいてルーティングエンジンを使用して経路探索を実行し、結果の制御装置１０に送信する。

【0065】

ステップＳ１２において、制御装置１０はサーバ装置２０から経路探索の結果を受信し、当該結果をユーザの端末装置３０に送信する。その後、制御部１１の動作は終了する。

【0066】

ユーザの端末装置３０の制御部３１は、制御装置１０から受信した検索結果の応答をユーザに対し通知する。通知の手法には任意の手法が採用されてよい。制御部３１はさらに当該通知後にユーザが候補サービスを受け入れたか否かを示す情報を取得し、当該情報を制御装置１０へ送信してもよい。この場合、制御装置１０の制御部１１は、候補サービスがユーザに受け入れられたか否かに基づいて、決定する要求仕様を修正してもよい。例えば、候補サービスがユーザに受け入れられた場合は、体調情報等に対し決定する要求仕様を緩和し、ユーザに受け入れられなかった場合は、決定する要求仕様を厳格化してもよい。要求仕様の緩和の一例として、制御部１１は、ステップＳ５においてスケジュール情報が勤務中を示す場合に決定する要求仕様の時間的許容幅をＴ３からＴ４に増加させてもよい。要求仕様の厳格化の一例として、制御部１１は、ステップＳ５においてスケジュール情報が勤務中を示す場合の時間的許容幅をＴ３からＴ２に低減させてもよい。

【0067】

上述のように、本実施形態に係る制御装置１０は、ユーザの端末装置３０からユーザの移動要求を示す移動要求情報を取得すると、ユーザの体調情報、ユーザのスケジュール情報、移動予定日時の天候情報、及び移動予定日の曜日情報のうち少なくとも１つの情報に基づいて、複数のモビリティサービスの中から少なくとも１つを候補サービスとして選択し、少なくとも１つの候補サービスを利用した経路探索の結果を取得し、結果を端末装置３０へ送信する制御部１１を備える。本実施形態によれば、各種情報に基づき選択された最も適切なモビリティサービスのルーティングエンジンを用いて経路探索が行われる。ユーザが、ＡＰＩが互いに異なる複数のモビリティサービスについて個別に経路探索を要求する必要がないため、ユーザの利便性が向上する。よってモビリティサービスの経路探索を行う技術を改善することができる。

【0068】

上述のように、本実施形態に係る制御部１１は、体調情報、スケジュール情報、天候情報、及び曜日情報の少なくとも１つに基づいて、候補サービスとして選択するモビリティサービスに対する要求仕様を決定し、要求仕様は、モビリティサービスを利用した経路探索の結果のレスポンス速度、モビリティサービスを利用した経路探索を行うための出発時刻又は到着時刻の時間的許容幅、モビリティサービスを利用した経路探索を行うための出発位置又は到着位置の位置的許容幅、モビリティサービスの相乗り可否の少なくとも１つを含む。本実施形態によれば、制御部１１は各種情報に基づきモビリティサービスの要求仕様を具体的に決定し、要求仕様に応じた適切な候補サービスを精度よく選択できる。

【0069】

上述のように、本実施形態に係る制御部１１は、体調情報が、ユーザの体調が悪いことを示す場合、要求仕様としてのレスポンス速度を速い程度に決定する。本実施形態によれば、体調が悪くユーザが早く移動したいことを希望する場合に、制御部１１は、レスポンス速度の速いモビリティサービスを自動的に選択できる。

【0070】

上述のように、本実施形態に係る制御部１１は、スケジュール情報が、ユーザが勤務中であることを示す場合、要求仕様としての相乗り可否を相乗り不可と決定する。本実施形態によれば、ユーザが勤務中であり移動中にも仕事を行うことが想定される場合に、制御部１１は、相乗りが無いモビリティサービスを自動的に選択できる。

【0071】

（第２実施形態）
以下、本発明の第２実施形態について説明する。本実施形態では、制御部１１が取得する体調情報等の各種情報は二値で表される。具体的には、体調情報はユーザの体調が「良い」又は「悪い」ことを示し、天候情報は移動予定日時の天候が「良い」又は「悪い」ことを示し、曜日情報は移動予定日が「平日」又は「休日」であることを示し、スケジュール情報は移動予定日時のユーザのスケジュールが「勤務中」又は「勤務時間外」であることを示す。制御装置１０の記憶部１２には、これらの情報の全組み合わせの１６通りについて対応するモビリティサービスを予め登録した対応情報を格納している。制御部１１は、記憶部１２から当該対応情報を読み出すことで取得して参照し、候補サービスを選択する。上述の二値で表された情報に限られず、各種情報は任意の離散的な値で表現されてもよい。

【0072】

図５は、本実施形態に係る対応情報の例を示す。図５を参照すると、体調情報が「良い」を示し、スケジュール情報が「勤務中」を示し、天候情報が「良い」を示し、曜日情報が「平日」を示す場合、モビリティサービスＫが対応付けられている。制御部１１は当該対応情報を参照し、取得した各種情報に対応付けられたモビリティサービスを候補サービスとして選択する。その後、制御部１１は、第１実施形態と同様に、選択した候補サービスのサーバ装置２０に対しＡＰＩ２００を介して経路探索を要求し、サーバ装置２０から返された経路探索の結果を、ユーザの端末装置３０に送信する。

【0073】

上述のように、本実施形態に係る制御部１１は、体調情報、スケジュール情報、天候情報、及び曜日情報と、モビリティサービスとを対応付けた対応情報を取得し、対応情報に基づいて候補サービスを選択する。本実施形態によれば、各種情報の対応するモビリティサービスが決定されているため、制御部１１が効率的に候補サービスを選択することが可能となる。よってモビリティサービスの経路探索を行う技術を改善することができる。

【0074】

本発明を諸図面及び実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形及び改変を行ってもよいことに注意されたい。したがって、これらの変形及び改変は本発明の範囲に含まれることに留意されたい。例えば、各構成部又は各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の構成部又はステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。

【符号の説明】

【0075】

１ システム
１０ 制御装置
１１ 制御部
１２ 記憶部
１３ 通信部
２０，２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ サーバ装置
３０ 端末装置
３１ 制御部
３２ 記憶部
３３ 通信部
３４ 入出力部
４０ ネットワーク
１００，２００Ａ，２００Ｂ，２００Ｃ，２００Ｄ ＡＰＩ

【図1】

【図2】

【図3】

【図4】

【図5】