特開 2022-98164 情報処理システム、情報処理プログラム、情報処理装置及び情報処理方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022098164

(43)【公開日】2022-07-01

(54)【発明の名称】情報処理システム、情報処理プログラム、情報処理装置及び情報処理方法

(51)【国際特許分類】

   G09B 29/00 20060101AFI20220624BHJP

   G09B 29/10 20060101ALI20220624BHJP

   G08G 1/0969 20060101ALI20220624BHJP

   G06Q 50/10 20120101ALI20220624BHJP

   G06N 20/00 20190101ALI20220624BHJP

   G16Y 10/40 20200101ALI20220624BHJP

   G16Y 20/10 20200101ALI20220624BHJP

   G16Y 40/10 20200101ALI20220624BHJP

   G16Y 40/30 20200101ALI20220624BHJP

【ＦＩ】

G09B29/00 F

G09B29/00 Z

G09B29/10 A

G08G1/0969

G06Q50/10

G06N20/00

G16Y10/40

G16Y20/10

G16Y40/10

G16Y40/30

【審査請求】未請求

【請求項の数】26

【出願形態】ＯＬ

(21)【出願番号】P 2020211549

(22)【出願日】2020-12-21

(71)【出願人】

【識別番号】500168811

【氏名又は名称】株式会社ナビタイムジャパン

(74)【代理人】

【識別番号】100091487

【弁理士】

【氏名又は名称】中村 行孝

(74)【代理人】

【識別番号】100105153

【弁理士】

【氏名又は名称】朝倉 悟

(74)【代理人】

【識別番号】100152205

【弁理士】

【氏名又は名称】吉田 昌司

(74)【代理人】

【識別番号】100202429

【弁理士】

【氏名又は名称】石原 信人

(72)【発明者】

【氏名】中村 康二

(72)【発明者】

【氏名】井櫻 涼介

(72)【発明者】

【氏名】小竹 輝幸

【テーマコード（参考）】

2C032

5H181

5L049

【Ｆターム（参考）】

2C032HB05

2C032HB15

2C032HC08

2C032HC11

2C032HC14

2C032HC22

2C032HC27

2C032HD26

5H181CC04

5H181KK06

5L049CC13

(57)【要約】      （修正有）

【課題】需給バランスを取得することにより駐車場等の施設の設置場所を適切に出力する、情報処理システムを提供する。
【解決手段】情報処理システム１は、機械学習により訓練された訓練済モデルを用いて、所定エリアにおける駐車場の使用状況から所定エリアにおける駐車場の需要情報を取得する手段３００と、所定エリアにおける駐車場の供給情報と、需要情報とに基づいて、駐車場の需給バランスを算出する手段３０４と、算出した需給バランスを地図上に表示する手段２００、２８と、を備える。
【選択図】図1

【特許請求の範囲】

【請求項1】

機械学習により訓練された訓練済モデルを用いて、所定エリアにおける駐車場の使用状況から前記所定エリアにおける前記駐車場の需要情報を取得する手段と、
前記所定エリアにおける前記駐車場の供給情報と、前記需要情報とに基づいて、前記駐車場の需給バランスを算出する手段と、
算出した前記需給バランスを地図上に表示する手段と、
を備える情報処理システム。

【請求項2】

前記使用状況は、前記所定エリアにおける前記駐車場に関する検索ログ、プローブ情報、ドライブレコーダにより取得された情報、又は、前記駐車場の滞在記録情報の少なくとも1つに基づく情報である、
請求項1に記載の情報処理システム。

【請求項3】

前記使用状況は、前記所定エリアのエリア属性に関する情報である、
請求項1又は請求項2に記載の情報処理システム。

【請求項4】

前記エリア属性は、前記所定エリアにおける前記駐車場に関する情報、前記所定エリアにおける建物、施設に関する情報、及び、前記所定エリアにおけるイベント情報、の少なくとも1つに関する情報である、
請求項3に記載の情報処理システム。

【請求項5】

前記使用状況は、前記所定エリアに加え、前記所定エリアの周辺エリアも対象とする
請求項1から請求項4のいずれかに記載の情報処理システム。

【請求項6】

前記需要情報は、前記駐車場が満車以上の需要であるかを示す情報である、
請求項1から請求項5のいずれかに記載の情報処理システム。

【請求項7】

前記供給情報は、前記所定エリア内における駐車可能な自動車の数に関する情報である、
請求項1から請求項6のいずれかに記載の情報処理システム。

【請求項8】

前記供給情報は、前記所定エリア内における駐車場を利用可能な時間帯に関する情報である、
請求項1から請求項7のいずれかに記載の情報処理システム。

【請求項9】

前記所定エリア内における駐車場の種別ごとに、前記地図上の表示を切り替えることが可能である、
請求項1から請求項8のいずれかに記載の情報処理システム。

【請求項10】

前記訓練済モデルに、前記使用状況の1つとして駐車場の満空情報を入力する、
請求項1から請求項9のいずれかに記載の情報処理システム。

【請求項11】

前記所定エリア及び／又は前記所定エリアの周辺エリアにおいて、駐車場を新設した場合の前記需給バランスの変動をシミュレーションする手段、
をさらに備える、請求項1から請求項10のいずれかに記載の情報処理システム。

【請求項12】

前記需給バランスに基づいて、駐車場を新設するエリアを探索する手段、
をさらに備え、
前記地図上に表示する手段は、前記地図上に、探索された前記エリアを表示する、
請求項1から請求項11のいずれかに記載の情報処理システム。

【請求項13】

前記地図上の表示は、時間に関する条件に基づいて切り替えることが可能である、
請求項1から請求項12のいずれかに記載の情報処理システム。

【請求項14】

前記時間に関する条件は、時間帯別、日別、曜日別、週別、月別、及び、季節別の条件のうち少なくとも1つの条件である、
請求項13に記載の情報処理システム。

【請求項15】

前記地図上の表示は、前記所定エリアにおけるイベントの開催状況に基づいて切り替えることが可能である、
請求項1から請求項14のいずれかに記載の情報処理システム。

【請求項16】

前記地図上の表示は、前記需要情報と前記供給情報を数値化してグラフで可視化した情報である、
請求項1から請求項15のいずれかに記載の情報処理システム。

【請求項17】

前記地図上の表示は、前記所定エリア及び／又は前記所定エリアの周辺エリアにおけるスポットごと、又は、前記スポットまでの距離ごと、に切り替えることが可能である、
請求項1から請求項16のいずれかに記載の情報処理システム。

【請求項18】

機械学習により訓練された訓練済モデルを用いて、所定エリアにおける駐車場の使用状況から前記所定エリアにおける前記駐車場の需要情報と、前記所定エリアにおける前記駐車場の供給情報と、に基づいて算出された前記駐車場の需給バランスを地図上に表示する、ディスプレイ
を備える情報処理装置。

【請求項19】

機械学習により訓練された訓練済モデルを用いて、所定エリアにおける駐車場の使用状況から前記所定エリアにおける前記駐車場の需要情報を取得する手段と、
前記所定エリアにおける前記駐車場の供給情報と、前記需要情報とに基づいて、前記駐車場の需給バランスを算出する手段と、
算出した前記需給バランスに関するデータとして送信する手段と、
を備える情報処理装置。

【請求項20】

コンピュータを、
機械学習により訓練された訓練済モデルを用いて、所定エリアにおける駐車場の使用状況から前記所定エリアにおける前記駐車場の需要情報と、前記所定エリアにおける前記駐車場の供給情報と、に基づいて算出された前記駐車場の需給バランスを地図上に表示する手段、
都市的の得させる情報処理プログラム。

【請求項21】

コンピュータを、
機械学習により訓練された訓練済モデルを用いて、所定エリアにおける駐車場の使用状況から前記所定エリアにおける前記駐車場の需要情報を取得する手段、
前記所定エリアにおける前記駐車場の供給情報と、前記需要情報とに基づいて、前記駐車場の需給バランスを算出する手段、
算出した前記需給バランスに関するデータとして送信する手段、
として機能させる情報処理プログラム。

【請求項22】

コンピュータを、
機械学習により訓練された訓練済モデルを用いて、所定エリアにおける駐車場の使用状況から前記所定エリアにおける前記駐車場の需要情報を取得する手段、
前記所定エリアにおける前記駐車場の供給情報と、前記需要情報とに基づいて、前記駐車場の需給バランスを算出する手段、
算出した前記需給バランスを地図上に表示する手段、
として機能させる情報処理プログラム。

【請求項23】

通信可能に接続された複数のコンピュータによって、請求項1から請求項17のいずれかに記載の情報処理システムを機能させるために、
前記コンピュータのうち1つを請求項1から請求項17のいずれかに記載の情報処理システムにおける各手段の少なくとも1つとして機能させる情報処理プログラム。

【請求項24】

コンピュータを、請求項１から請求項17のいずれかに記載の情報処理システムにおける各手段の少なくとも１つとして機能させる情報処理プログラム。

【請求項25】

通信可能に接続された複数の情報処理装置によって、
機械学習により訓練された訓練済モデルを用いて、所定エリアにおける駐車場の使用状況から前記所定エリアにおける前記駐車場の需要情報を取得する手段と、
前記所定エリアにおける前記駐車場の供給情報と、前記需要情報とに基づいて、前記駐車場の需給バランスを算出する手段と、
算出した前記需給バランスを地図上に表示する手段と、
を備えた情報処理システムを構成するために、上記手段の少なくとも１つを備える情報処理装置。

【請求項26】

コンピュータにより、機械学習により訓練された訓練済モデルを用いて、所定エリアにおける駐車場の使用状況から前記所定エリアにおける前記駐車場の需要情報を取得するステップと、
コンピュータにより、前記所定エリアにおける前記駐車場の供給情報と、前記需要情報とに基づいて、前記駐車場の需給バランスを算出するステップと、
コンピュータにより、算出した前記需給バランスを地図上に表示するステップと、
を備える情報処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理システム、情報処理プログラム、情報処理装置及び情報処理方法に関する。

【背景技術】

【0002】

駐車場の新設をする場合、エリアごとの実態調査は、駐車場を設置しようとする業者が実行している。この設置の調査においては、分析データについて横断的なデータを収集できない状態でなされている場合が多い。また、基本的にはエリア内の駐車場検索総数等を用いて巡回目視で行われていることが多く、総合的にどの位置にどの程度の大きさの駐車場を新設するべきかを判定するのが困難であるとともに、時間的、人的なコストが高くなる。例えば、所定エリア内の全ての駐車場を網羅することはできない。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開2002-056420号

【発明の概要】

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

【0004】

例えば、満車となっている駐車場がある場合に、当該エリアにどの程度の需要があるか、例えば、現在の120%の需要があるのか、又は、200%の需要があるのかを判断することは、困難である。

【0005】

本開示においては、需給バランスを取得することにより駐車場等の施設の設置場所を適切に出力する、情報処理システムを提供する。

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

【0006】

一実施形態によれば、情報処理システムは、機械学習により訓練された訓練済モデルを用いて、所定エリアにおける駐車場の使用状況から前記所定エリアにおける前記駐車場の需要情報を取得する手段と、前記所定エリアにおける前記駐車場の供給情報と、前記需要情報とに基づいて、前記駐車場の需給バランスを算出する手段と、算出した前記需給バランスを地図上に表示する手段と、を備える。

【発明の効果】

【0007】

駐車場等の施設の設置場所を適切に予測することが可能となる。

【図面の簡単な説明】

【0008】

【図1】一実施形態に係る情報処理システムを模式的に示すブロック図。

【図2】一実施形態に係る情報処理システムの処理を示すフローチャート。

【図3】一実施形態に係るエリア入力を模式的に示す図。

【図4】一実施形態に係る需給バランスの表示例を示す図。

【図5】一実施形態に係る表示例を示す図。

【図6】一実施形態に係る表示例を示す図。

【図7】一実施形態に係る表示例を示す図。

【図8】一実施形態に係る表示例を示す図。

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

【0009】

(第1実施形態)
図1は、第1実施形態に係る情報処理システムを模式的に示すブロック図である。情報処理システム1は、クライアント2と、サーバ3を備えて構成される。クライアント2とサーバ3は、有線又は無線のネットワーク4により接続される。図においては、クライアント2とサーバ3は、それぞれ1個が示されているがこれには限られず、1個のサーバ3について複数のクライアント2が存在していてもよいし、1個のクライアント2に対して複数のサーバ3が存在していてもよい。また、複数のクライアント2と複数のサーバ3とが適切にネットワーク4により切り替えられてシステムを形成してもよい。

【0010】

この情報処理システム1は、例えば、必要となる建物、施設等の対象がどの程度必要であるか、どの程度求められているかを示す指標を地図上に重ねて表示するシステムである。この情報処理システム1は、例えば、過去に収集された情報に基づいて、エリアごとに当該対象の需要と供給のバランスを考慮して、指標を生成し、地図上に重ねて出力する。以下、一例として、対象が駐車場であり、情報処理システム1は、駐車場を新設しようとするエリアを適切に抽出できる情報を出力する例について説明する。

【0011】

クライアント2は、制御部20と、記憶部22と、通信部24と、入力部26と、出力部28と、を備える。

【0012】

制御部20は、情報処理システム1におけるクライアント2の制御を実行する。制御部20は、例えば、表示情報生成部200を備える。また、制御部20は、例えば、クライアント2の他の制御を実行する汎用のCPU(Central Processing Unit)等のプロセッサを備えて構成されてもよい。

【0013】

表示情報生成部200は、通信部24を介してサーバ3から取得した情報に基づいて、クライアント2側で表示、出力する情報を生成する。

【0014】

記憶部22は、クライアント2において情報処理システムとして出力する情報等に必要となるデータを記憶する。記憶部22は、例えば、メモリ、ストレージ等を備えて構成されてもよい。記憶部22は、表示情報生成部200が必要とする情報を、一時的又は非一時的に格納する。また、クライアント2がソフトウェアによる情報処理がハードウェア資源を用いて具体的に実現される場合には、当該ソフトウェアによる情報処理を実行するためのプログラム等の情報が記憶されていてもよい。この他、クライアント2が起動するために必要な情報が適宜格納される。

【0015】

通信部24は、クライアント2が外部と通信するために必要なインタフェースである。クライアント2は、この通信部24を介して、外部、特に情報処理システム1としてはサーバ3と接続される。クライアント2は、この通信部24を介してサーバ3とデータの送受信を行う。

【0016】

入力部26は、クライアント2における入力インタフェースである。クライアント2が一般的なコンピュータである場合、入力部26は、マウス、トラックボール、キーボード、マイク等のデバイスであってもよい。クライアント2がタブレット型端末、スマートホン等の携帯型端末である場合、入力部26は、タッチパネル、マイク等のデバイスであってもよい。このように、入力部26は、クライアント2の筐体と別個備えられるものであってもよいし、一体として備えられるものであってもよい。クライアント2は、この入力部26を介してユーザからの入力を受け付ける。

【0017】

出力部28は、クライアント2における出力インタフェースである。クライアント2が上記のようなデバイスである場合には、出力部28は、ディスプレイ、ステレオ装置等であってもよい。出力部28は、少なくとも、表示情報生成部200により生成された情報を表示する、表示デバイスを備える。

【0018】

クライアント2は、上記の構成要素により、サーバ3から取得したデータに基づいて表示する情報を生成し、出力部28に生成した情報を出力する。また、クライアント2は、入力部26から入力された情報に基づいて、出力する情報を表示情報生成部200が再生成し、この再生成した情報を出力部28に出力してもよい。

【0019】

例えば、クライアント2は、駐車場を新設したい事業者が利用する端末装置であり、地図上の任意のエリアに関する駐車場の需給情報を出力部28から出力する。任意のエリアは、事業者が入力部26を介して入力することにより設定される。クライアント2は、サーバ3から当該エリア、及び、当該エリアの周辺エリアに関するデータを受信し、制御部20において地図情報と適切に合成し、出力部28から出力する。

【0020】

制御部20により地図情報と合成される情報は、例えば、駐車場の需給バランスを示す情報である。事業者は、クライアント2において出力された情報を参照することにより、任意のエリアにおける新たな駐車場の必要性等、また、新設した場合の費用対効果等を算出するための情報を適切に取得することができる。

【0021】

サーバ3は、クライアント2において求められる情報を生成するためのデータを算出する装置である。サーバ3は、制御部30と、記憶部32と、通信部34と、を備える。

【0022】

制御部30は、記憶部32に格納されている情報に基づいて、種々の情報を取得、算出し、クライアント2へと送信するデータを取得する。制御部30は、需要情報取得部300と、供給情報取得部302と、需給バランス算出部304と、を備える。

【0023】

需要情報取得部300は、クライアント2において表示したいエリアにおける対象の需要情報を、当該対象の使用状況を示す種々のデータに基づいて取得する。一例として、需要情報取得部300は、訓練データを用いて種々の機械学習アルゴリズムにより最適化された訓練済モデルを用いて、当該対象の使用状況から、所定エリアにおける対象の需要情報を取得する。この訓練済モデルは、例えば、需要情報を需要指標として出力する。入力するデータは、例えば、過去の当該エリアにおける対象の検索ログ、当該エリアの属性が含まれていてもよい。

【0024】

この需要情報には、駐車場の使用状況として、例えば、駐車場の滞在記録情報、当該エリア及び／又は当該エリアの周辺エリアにおけるプローブ情報(複数台の自動車の走行ログ)、ドライブレコーダの撮影データ等の情報が入力データに含まれていてもよい。さらに、上述した検索エンジン、駐車場検索サイト等による検索ログがこの使用状況に含まれてもよい。また、この場合、入力データは、エリアに存在する駐車場の利用状況情報、満空情報が含まれてもよいし、POI(Point of Interest)又は当該エリアにおいて開催されるイベントとの紐付け情報が含まれてもよい。

【0025】

プローブ情報等が入力可能である場合、訓練データとして、プローブにおける当該エリア及び当該エリア周辺の情報を抽出して、この走行情報において、駐車場を探している確率を出力するモデルを機械学習により最適化してもよい。例えば、プローブ情報において、速度、駐車場近くにおける運転等の情報を取得し、その後に駐車場に入った等の情報を訓練データとすることができる。この運転等の情報には、プローブ情報により取得した駐車場における駐車情報、又は、路上での駐停車時間の情報等が含まれてもよい。

【0026】

また、エリア内の駐車場をいくつか巡回したり、その後に、離れたエリアの駐車場に入ったり、といった情報と、当該エリア及び周辺エリアの運転情報とを紐付けて訓練データとすることもできる。また、別の例として、アンケートにより、プローブ情報において駐車場を探していた時間を指定してもらい、この情報を訓練データとしてもよい。これらには限られず、プローブ情報と、駐車場を探している情報とを紐付けることにより、訓練データとして用いることができる。

【0027】

プローブ情報の他には、ソフトウェア、アプリケーション、ウェブブラウザ等におけるナビゲーションにおける目的地、POI又はエリア等の位置情報、及び、出発日時、到着日時等の時間的な情報のうち少なくとも1つを需要情報として用いてもよい。さらに、経路探索時に指定された目的地と、その後に実際に入った駐車場との距離といった情報を需要情報として用いてもよい。

【0028】

このように抽出された情報を訓練データとして用いることにより、訓練済モデルは、単純な満空情報にしたがった需要情報ではなく、満車である場合にどの程度の過剰な需要があるかについての情報を出力することが可能となる。もちろん、プローブ情報だけではなく、検索ログの情報、ドライブレコーダの撮影データ等も同様に訓練データとして用いることが可能である。

【0029】

エリアの属性とは、エリアにおける種々の建物、施設に関する情報のうち、少なくとも1つを含む情報である。より広義な意味として、エリア属性は、例えば、当該エリアが観光地である、ビジネス街である、駅が存在している、等を示す情報である。より細かくは、建物、施設に関する情報とは、例えば、観光施設、文化施設、商業施設、病院、駅、空港、自然(POI)等がどの程度存在するかの情報、及び、その種類、規模等の情報である。

【0030】

供給情報取得部302は、エリアごとに、どの程度の対象があるかを示す情報から供給キャパシティを取得する。例えば、対象が駐車場である場合には、供給情報取得部302は、駐車場情報として、当該エリアにどの程度の規模の駐車場がいくつあるか、又は、エリア全体として駐車可能台数はどの程度であるかの情報を取得する。

【0031】

駐車場情報は、この利用可能台数の他、利用可能時間、駐車場種別等の情報を含んでもよい。駐車場種別とは、例えば、施設内の駐車場、コインパーキング、自宅駐車場の時間限定貸し出し、道路におけるパーキングメータ設置箇所等の駐車場の設置場所や設置方法等の種別を表す。また、高速道路等の有料道路において進入可能なパーキングエリア、サービスエリアの駐車場を含まない情報としてもよい。

【0032】

需給バランス算出部304は、需要情報取得部300が取得した需要情報及び供給情報取得部302が取得した供給情報に基づいて、エリアごとに、対象の需給バランスを算出する。例えば、需要情報取得部300と、供給情報取得部302は、ともに所定の算出方法により、上記の情報に基づいて需要情報と供給情報とのそれぞれの指標を数値として出力する。需給バランス算出部304は、この需要値と供給値を用いて、需給バランスを算出する。需給バランス算出部304は、例えば、(需要値) ÷ (供給値)を需給バランスの指標として算出する。この需給バランスは、エリアごとに算出され、通信部34を介してクライアント2に送信される。

【0033】

記憶部32は、サーバ3の動作、及び、各構成において必要とされるデータ等が格納される。記憶部32は、例えば、メモリ、ストレージ等の一時的又は非一時的な記憶デバイスを備えていてもよい。また、図1においてはサーバ3に含まれているが、記憶部32の少なくとも一部の領域は、サーバ3とネットワークを介して接続される別のファイルサーバ等に格納されているものであってもよい。

【0034】

この記憶部32には、例えば、図に示すように、需要情報DB 320と、供給情報DB 322と、が備えられる。また、これらの他に、サーバ3の制御に必要なデータ、また、各処理を実行するために必要となるデータが備えられてもよい。例えば、需要情報取得部300は、上述のように訓練済モデルを用いて需要情報を取得するが、この訓練済モデルのパラメータ等は、記憶部32に適切に格納され、需要情報取得部300は、実行時にネットワークを適切に構成して需要情報を取得してもよい。

【0035】

需要情報DB 320は、需要情報を格納し、適切にアクセスするためのデータベースである。需要情報DB 320には、例えば、需要情報取得部300が用いるデータである、駐車場の滞在記録情報、当該エリア及び／又は当該エリアの周辺エリアにおけるプローブ情報(複数台の自動車の走行ログ)、ドライブレコーダの撮像データ等の情報、検索エンジン、駐車場検索サイト等による検索ログ、駐車場の利用状況情報、満空情報が含まれてもよいし、POI又はイベントとの紐付け情報、エリア属性等のデータが格納される。また、需要情報DB 320は、これらの情報を、例えば、エリアごとに付与される識別子をキーとして取得できるようにデータベースを構築して格納する。

【0036】

供給情報DB 322は、供給情報を格納し、適切にアクセスするためのデータベースである。供給情報DB 322には、例えば、供給情報取得部302が用いるデータである、エリアごとにどの程度の規模の駐車場がいくつあるか、又は、エリア全体として駐車可能台数はどの程度であるかの情報、利用可能時間、駐車場種別等の情報のデータが格納される。需要情報DB 322は、これらの情報を、例えば、エリアごとに付与される識別子をキーとして取得できるようにデータベースを構築して格納する。

【0037】

図2は、本実施形態に係る情報処理システム1の処理を示すフローチャートである。次に、この図2を用いて、本実施形態に係る情報処理システム1の処理の流れについて説明する。

【0038】

まず、ユーザは、クライアント2の入力部26を介して、駐車場を新設する候補となるエリアの情報を入力する(S200)。この入力は、厳密にエリアの位置を指定する必要は無く、例えば、周囲30km四方といった周辺エリアを選択してもよい。エリアの選択は、例えば、出力部28に表示されている地図の任意の場所をタップしたり、又は、文字入力により、「東京都」と入力したり、「港区」と入力したりといった行政区を指定できるものであってもよい。また、これよりも細かい町、丁目等を入力したり、さらには、緯度、経度を入力したりするものであってもよい。クライアント2は、この入力部26を介して受け付けた情報を、通信部24を介してサーバ3へと送信する。

【0039】

図3は、本実施形態に係るエリア入力の一例を示す図である。ユーザは、例えば、タッチパネル付ディスプレイにおいて、表示されている地図の一点をタップすることにより、エリアを指定して入力することが可能である。図3においてはスマートホン等の例を示したが、もちろん、クライアント2は、PCであってもよく、この場合、出力部28であるモニタに表示された地図上において、マウス、トラックボール等により、一点を指定してクリックしてもよいし、上述したように文字情報としてエリアを指定してもよい。他の例としては、音声入力を受け付け、音声を解析することによりエリアを指定してもよい。また、図3は、地図領域のみを表示しているが、他の入力領域等のインタフェースがあることを排除しているものではなく、適切に他のインタフェースが備えられていてもよい。

【0040】

サーバ3において、通信部34を介してエリアの入力、選択情報を取得すると、需要情報取得部300は、当該エリア(及び当該エリアの周辺エリア)に関する需要情報を取得する(S300)。この取得には、上述したように、訓練済モデルに需要情報DB 320に格納されているデータに基づいた入力をして、出力してもよい。例えば、当該エリア及び周辺エリアに関するプローブ情報、検索された頻度等を入力とすることにより、駐車場の満空情報だけではなく、エリア内の駐車場が満車に近い状態である場合に、需要情報が100%をどの程度越えるかの情報をも需要情報に含めることができる。

【0041】

次に、供給情報取得部302は、当該エリア(及び周辺エリア)に関する供給情報を取得する(S302)。この取得は、上述したように、供給情報DB 322から取得した情報から適切に当該エリアの情報を抽出することにより実行される。

【0042】

なお、この需要情報の取得(S300)と、供給情報の取得(S302)は、順番が入れ替わってもよいし、並行して実行されるものであればよい。次の需給バランスの算出処理までに、需要情報と供給情報とが適切に取得できている状態であればよい。

【0043】

次に、取得した需要情報と、供給情報と、に基づいて、当該エリア(及び周辺エリア)における需給バランスを算出する(S304)。例えば、需給バランス算出部304は、当該エリア及び周辺エリアにおいて、エリアごとに取得された需要情報及び供給情報に基づいて、需給バランスを算出する。需給バランス算出部304が算出した需給バランスは、通信部34を介してクライアント2へと送信される。

【0044】

需給バランスの情報を取得したクライアント2は、入力されたエリアが含まれる周辺の地図を取得する(S202)。なお、地図の取得は必須ではなく、地図上の一点を示すことによりエリア入力をした場合には、当該入力に用いた地図を引き続き用いてもよい。また、エリア地図の取得は、このタイミングではなく、エリア入力の処理を受け付けた後、需給バランスを受信するまでの間に実行されてもよい。すなわち、サーバ3におけるS300からS304の処理の間に、地図情報を受信して画像に復号等してもよい。

【0045】

次に、表示情報生成部200は、エリアを含む地図情報に各エリアにおける需給バランス情報を重ね合わせることにより、需給バランスに関するデータを地図上に描画する(S204)。

【0046】

出力部28は、表示情報生成部200が生成した、需給バランス情報が描画された地図を出力し(S206)、処理を終了する。

【0047】

図4は、需給バランス情報を重ね合わせた地図の一例を示す図である。この図4に示すように、例えば、需給バランスの情報は、地図に重ね合わされてメッシュ状に数値として表示されてもよい。例えば、100が需要と供給のバランスがとれている、すなわち、駐車場が満車であり、駐車場待ちの自動車がいない状態を示し、100より小さければ、駐車場に余裕があり、100より大きければ、駐車場待ちの自動車がいる状態を表す。

【0048】

この表示は、例えば、色別に表されてもよい。一例として、0～20であれば緑色、20～40であれば黄緑色、40～60であれば黄色、60～80であれば橙色、80～であれば赤色、等と色分けをして地図上に示してもよい。この場合、需給バランス自体の数値を表示してもよいし、表示しなくてもよい。また、需給バランスにおいて需要が過多であるエリアが点滅するなど、目立つように表示させてもよい。

【0049】

このような表示を見ることにより、例えば、需給バランスが150と表示されているエリアにおいては、駐車場に対する需要が供給に対して大きく上回っていることがわかる。このため、事業者は、このエリアに駐車場を新設することを検討することが可能となる。一方で、需給バランスが0、27等のエリアにおいては、供給が十分であり、新設には適さないことがわかる。

【0050】

以上のように、本実施形態によれば、単純な駐車場の満空情報では取得することのできない需要が供給を大きく上回っているエリアを抽出することが可能となる。

【0051】

なお、本実施形態においては、図4に示すように、エリアはメッシュ状のものであるとしたが、これには限られない。例えば、エリアは、行政区により分割されていてもよい。この場合、面積、形状は、エリアごとに異なるものとなる。エリアの面積に関しては、大体同等の面積になるように、行政区等により分割された1つのエリアを、2以上のエリアに分割し、又は、行政区等により分割された2以上のエリアを1つのエリアに結合してもよい。

【0052】

また、クライアント2においては、最初に需給バランスを表示しない地図を表示させ、エリアを選択する形態としたが、これに限られるものではない。例えば、日本地図、世界地図等の広域の地図を最初に表示し、当該地図上に、例えば、国別、地方自治体別の需給バランスを重ねて表示しておき、そこからユーザが詳しく見たい箇所を選択、限定していく処理としてもよい。この場合、図2におけるS200の処理の前に、S300～S304の処理を実行し、S200と、S300～S304の処理を繰り返し実行する流れとしてもよい。

【0053】

また、ユーザが地図を拡大するたびにシーケンシャルにエリアを細かくしていき、最終的に図4のようなメッシュ状の需給バランスを表示する形態としてもよい。例えば、表示エリアの拡大は、タッチディスプレイ上におけるピンチアウト、ダブルタップ等の操作を入力部26が受け付けることにより実行されてもよい。

【0054】

逆に、表示エリアを縮小してもよく、この場合、エリアを粗くしていき、粗くしたエリアごとに周辺エリア等の情報とともに需給バランスを表示させてもよい。例えば、表示エリアの縮小は、タッチディスプレイ等におけるピンチイン等の操作を入力部26が受け付けることにより実行されてもよい。

【0055】

別の例として、地図上に拡大、縮小を示すボタンを備えていてもよいし、拡大、縮小率を操作するバー等が備えられていてもよい。この場合、予め地図上にこれらのボタン等を表示しておき、ディスプレイ上に表示されるエリアの距離、面積、拡大率等をこれらのボタン等で指定することにより、拡大率、縮小率を決定してもよい。

【0056】

また、地図の拡大、縮小だけではなく、エリアの拡大、縮小を可能な形態としてもよい。例えば、メッシュ状のエリアで需給バランスが示される場合には、エリアの面積をユーザが任意に決定できる実装であってもよい。最小エリア面積を、例えば、30m × 30m程度等としておき、表示されている地図上において、エリアを示すメッシュの大きさを任意に指定できるボタン等を表示しておいてもよい。このボタン等の操作により、メッシュの大きさの変更を入力部26が受け付け、表示情報生成部200が当該メッシュの大きさに基づいて表示を更新してもよい。この場合、必要であれば、サーバ3においてメッシュごとの需給バランスを再計算してもよい。

【0057】

以下、上述した実施形態の種々の形態について図面を参照しながら説明する。下記に説明する形態は、それぞれ独立して用いられるものであってもよいし、適切に組み合わせて用いられるものであってもよい。例えば、第2実施形態の実装のみが利用可能であってもよいし、第2実施形態と第3実施形態の実装が組み合わされて利用可能であってもよい。

【0058】

(第2実施形態)
図5は、表示の一例を示す図である。需給バランスが表示された後に、ユーザが表示されているエリアの詳細情報を検索する形態としてもよい。例えば、需給バランスを表示している状態において、任意のエリアを選択することにより、選択したエリアにおける駐車場の満空情報を表示してもよい。

【0059】

また、図に示されるように、エリア内における駐車場の位置を示してもよい。地図上において位置を示すほか、エリアの中心からの距離、道のり等の情報を表示させてもよい。さらに、駐車場ごとに、時間貸しの料金の情報、設置事業者の情報、駐車場種別等を表示させてもよい。また、キャッシュレス決済可能等の情報を表示させてもよい。これらの情報は、適切に表現できるのであれば、アイコン等のわかりやすい表示により表現されてもよい。

【0060】

表示する情報は、予めサーバ3からクライアント2へと送信され、クライアント2において表示を切り替えるものであってもよいし、入力部26が受け付けたエリアにおける駐車場の情報を、サーバ3において抽出して、この抽出結果をクライアント2において表示させてもよい。

【0061】

(第3実施形態)
図6は、表示の一例を示す図である。前述の各実施形態においては、需給バランスを表示するものであったが、需給バランスではなく、他の指標を表示させてもよい。表示する指標は、例えば、需要／供給別の数、POI別の需給バランス、満空情報そのもの、等の情報であってもよい。

【0062】

図6においては、一例として、需要／供給別の数を表示している。需要／供給別の表示を選択した場合には、一例として、需給バランスが100%を越えているエリアにおける需要と供給の数値を表示させてもよい。もちろん、全てのエリアにおいて、需要／供給の数値を表示させてもよい。図に示されるように、収容可能台数、需要台数とともに、需給バランスを表示させてもよい。

【0063】

POI別需給とは、例えば、当該エリア及び周辺エリアにおいてPOIが設定されている場合、当該POIを利用する自動車の駐車需要と供給可能な駐車台数に基づいて表示がされる。満空情報は、エリアごとの需要を考慮しない単純な満空情報が表示される。このように、表示する指標を変更できるようにしてもよい。当該エリア及び周辺エリアにおいて複数のPOIが設定されている場合には、ユーザがPOIを選択できる態様であってもよい。

【0064】

また、図6においては、数値を文字として表示しているが、これには限られない。すなわち、ユーザが直感的に理解できるように、色、グラフ等を用いて表示してもよい。このグラフは、2Dには限られず、地図を鳥瞰図に変換し、エリアごとに地図上に鉛直方向に延びる3Dのグラフとして表示されてもよい。

【0065】

また、例えば、需給バランスが高く出ているにも拘わらず、収容可能台数が極端に低いエリアには、「候補エリア」と表示し、駐車場を新設する候補のエリアであることを明示的に表示してもよい。候補エリアの表示ではなく、色、エリアを大きく表示して強調等することにより、候補エリアであることを明示的に示してもよい。このように、需給に関する指標を表示するだけではなく、ユーザに対して候補となるエリアをリコメンドする形態であってもよい。

【0066】

図7は、表示の一例を示す図である。POI別需給とした場合には、周辺エリアにおけるPOIを選択できるようにしてもよい。この場合、POIからの距離又は道のりに応じたエリアにおける需給バランスを表示してもよい。POIは、所望のPOIをユーザが指定できるものであってもよいし、自動的に周辺エリアのPOIごとに表示するものであってもよい。また、POIに限られず、ユーザが任意の地点を指定できるものであってもよい。これらの場合については、例えば、指定された条件をクライアント2からサーバ3に送信することにより、サーバ3が適切に条件に基づいて表示する数値等を再取得する形態としてもよい。

【0067】

前述の第2実施形態と組み合わせることにより、POIの周辺エリアにおける収容可能台数、駐車場の位置を表示させることも可能である。この表示に基づいて、例えば、半径200m、400m、800m内ではそれぞれ、需要に対してどの程度供給が不足しているか、等の情報をも示すことが可能となる。

【0068】

POIとしては、所定の施設等ではなく、例えば、商店街周辺、病院周辺、通学路等の任意の属性を有する点及び領域を指定することも可能である。

【0069】

上記においては、POIからの距離、道のり等としたが、さらにPOI等におけるイベントの開催等に基づいて需給バランスを表示できる形態であってもよい。例えば、スポーツイベント、コンサート等の人が多く集まるイベントにおいては、駐車場が一時的に足りなくなる可能性もある。このような場合に、駐車場等を適切に設置することが可能となる。この駐車場は、例えば、臨時的に設置される駐車場であってもよい。

【0070】

イベント等の需給バランスを取得する場合は、例えば、イベントの名称と駐車場とを合わせた検索ログ等を抽出することにより、未来のイベントの需給バランスを予測してもよい。この予測によるシミュレーションを実行することも可能である。例えば、需給バランスの変動をシミュレーションすることにより、必要となるであろう駐車場の収容台数を予測してもよい。

【0071】

シミュレーションは、イベント等の開催には限られない。例えば、エリアごとの情報において、任意のエリアに収容台数を指定して駐車場を設置した場合に、需給バランスがどのように変動するかをシミュレーションしてもよい。このような変動情報を取得することにより、事業者は、さらに適切な駐車場の新設位置を検討することが可能となる。

【0072】

(第4実施形態)
図8は、表示の一例を示す図である。この図8に示すように、需給バランスを取得したい日時の特性を指定できるものであってもよい。例えば、平日、休日のいずれかを選択できる形式としてもよいし、時間帯を指定できる形式としてもよい。また、平日、休日のみならず、曜日の指定、日付の指定や日単位の期間の指定(日別の指定)、週別の指定、月別の指定、季節別の指定等、時間に関する情報を条件として指定可能であってもよい。

【0073】

このように、時間帯等の時間に関する情報に基づいて需給バランスを表示できる形態である場合、サーバ3は、一日、一週間、過去の全てのデータ等において需給バランスを算出するほか、平日及び休日の時間帯ごとの需給バランスを予め算出してクライアント2に送信しておき、クライアント2側において、選択された表示をしてもよい。別の例として、クライアント2側において指定された条件をサーバ3に送信し、サーバ3で指定された条件に基づいた表示対象を取得し直してクライアント2に送信して表示させてもよい。

【0074】

本実施形態によれば、例えば、平日の10時と、休日の16時といった別の条件に基づいた需給バランスをそれぞれ表示することが可能となる。この結果に基づいて、事業者はより適切に対象の新設を検討することが可能となる。

【0075】

時間帯別の需給バランスが取得できることにより、対象の新設以外にも各実施形態の適用範囲を広げることができる。例えば、時間貸しの駐車場において、時間ごとの需給バランスから、時間帯ごとの駐車料金を決定してもよい。このように価格の適正化についても本開示の各実施形態を応用することが可能である。

【0076】

また、変動料金(ダイナミックプライシング)のための教師データを生成することも可能となる。例えば、すでに取得されている変動料金と、平日／休日、時間帯ごとの過去データから需給バランスを算出して、このデータを元に機械学習により、日時ごとの料金の最適化のためのモデルを最適化することもできる。

【0077】

例えば、予約制駐車場の単位時間、又は、定められた時間あたりの料金を需要に応じて変動する適切な料金を取得するモデルを生成することができる。より具体的には、駐車場過剰エリアとその時間帯、駐車場不足エリアとその時間帯等のデータを用いることにより、より適切なダイナミックプライシングを適用することが可能となる。

【0078】

さらには、料金を指定した場合に、どのような需給バランスになるかをシミュレーションできる構成としてもよい。

【0079】

予約制駐車場の料金等を適切に設定し、予約制駐車場の利用を促進することが可能となるとともに、この結果として、適切な料金で適切に駐車場を確保できることから、違法路上駐車等の削減をも実現することが可能となる。

【0080】

以上、種々の実施形態を説明したが、各実施形態によれば、事業者は、適切に対象の設置場所を検討することが可能となる。また、一般ユーザにとっても、適切に対象が設置されることにより、満足度を向上することが可能となる。これらの出力に用いるデータは、過去及び現在において収集されたデータに基づく、さらには、自動的に収集可能なデータに基づいて取得することが可能であるので、事業者としては、時間的、人的なコストを削減することも可能となる。また、人的に行っていた調査では、エリアを網羅することが困難であるが、本実施形態によれば、プローブ情報等の自動的に取得でき、広域、かつ、時間帯に縛られない情報が取得できる方法により、情報を収集することが可能となる。

【0081】

なお、前述の各実施形態においては、地図上への需給バランスの描画は、クライアント2において実行されていたが、これには限られない。例えば、サーバ3側で地図上に需給バランスの描画までを行ったデータを生成し、クライアント2に送信して、クライアント2において地図を表示させてもよい。この場合、クライアント2の表示情報生成部200は、地図上に需給バランスを重ね合わせる必要は無く、取得したデータの復号等を実行し、出力部28に出力させればよい。

【0082】

また、逆に、サーバ3を介さずに、クライアント2において需要情報及び供給情報を取得の処理をも実行してもよい。この場合、例えば、クライアント2において需給バランスが算出され、出力部28を介して出力される。これらには限られず、比較的データベースからの取得が必要となるデータが多いと見込まれる需要情報の取得をサーバ3で実行し、その他の処理をクライアント2側で実行する等の構成であってもよい。すなわち、情報処理システム1は、ディスプレイへの出力の処理等、クライアント2側で必要な処理を除く処理については、適切にクライアント2、サーバ3のいずれかにおいて実行される態様であってもよい。

【0083】

上述した実施形態で説明した情報処理システムの少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、情報処理システムの少なくとも一部の機能を実現するプログラムをフレキシブルディスクやCD-ROM等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等着脱可能なものに限定されず、ハードディスク装置やメモリなど固定型の記録媒体でもよい。

【0084】

また、情報処理システムの少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調を掛けたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、或いは記録媒体に収納して頒布してもよい。

【0085】

さらに、１つ又は複数の情報処理装置によって情報処理システムを機能させてもよい。複数の情報処理装置を用いる場合、情報処理装置のうち１つをコンピュータとし、当該コンピュータが所定のプログラムを実行することにより情報処理システムの少なくとも１つの手段として機能が実現されてもよい。

【0086】

上記の記載に基づいて、当業者であれば、本発明の追加や効果や種々の変形を想到できるかもしれないが、本発明の態様は、上述した個々の実施形態に限定されるものではない。特許請求の範囲に規定された内容及びその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更及び部分的削除が可能である。

【0087】

例えば、上記においては、駐車場を一例として説明したが、もちろん駐車場以外の対象に対しても同様の出力を実現することが可能である。

【0088】

例えば、対象をコインランドリーとしてもよい。この場合、用いる情報は、利用可能台数、稼働率、ダイナミックプライシングを含む料金等の情報である。

【0089】

例えば、対象を会議室、レンタルスペースとしてもよい。この場合、用いる情報は、建物種別、用途、広さ、ダイナミックプライシングを含む料金等の情報である。

【0090】

例えば、対象を民泊施設としてもよい。この場合、用いる情報は、宿泊可能な人数、個室、ツイン等の部屋種別、マンション、一軒家等の建物種別、個人、企業といったオーナー種別、ダイナミックプライシングを含む料金等の情報である。

【0091】

例えば、対象を弁当、パン、その他の食料品、雑貨等の移動販売としてもよい。この場合用いる情報は、販売する対象、販売されることを欲している人数、時間帯別の人口、同業種店舗数、販売個数、販売する商品の種類(例えば、弁当であれば、和食、洋食、片手で持てる、歩きながら食べることができるもの、等の種別)、料金、売り上げ、周辺の環境(オフィス街、住宅街、繁華街等)等の情報である。

【0092】

また、飲食店等の施設についても、同様に対象とすることが可能となる。

【0093】

なお、上記において、価格の変動は、値そのものを入力、又は、出力するものとしたが、これには限られず、現状からの加減算度により入出力できるものであってもよい。また、減算される場合には出力せずに、加算の場合を強調して出力できる形態であってもよい。

【符号の説明】

【0094】

1:情報処理システム、
2:クライアント、
20:制御部、
200：表示情報生成部、
22:記憶部、
24:通信部、
26:入力部、
28:出力部、
3:サーバ、
30:制御部、
300:需要情報取得部、302:供給情報取得部、304:需給バランス算出部、
32:記憶部、
320：需要情報DB、322:供給情報DB、
34:通信部、
4:ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】