特許 7737295 検索サーバ、検索システム、及び検索方法

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

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

(11)【特許番号】

(24)【登録日】2025-09-02

(45)【発行日】2025-09-10

(54)【発明の名称】検索サーバ、検索システム、及び検索方法

(51)【国際特許分類】

   G08G 1/127 20060101AFI20250903BHJP

   G01C 21/26 20060101ALI20250903BHJP

   G01C 21/34 20060101ALI20250903BHJP

   G06Q 50/40 20240101ALI20250903BHJP

   G08G 1/00 20060101ALI20250903BHJP

   G08G 1/005 20060101ALI20250903BHJP

   G16Y 10/40 20200101ALI20250903BHJP

   G16Y 40/60 20200101ALI20250903BHJP

【ＦＩ】

G08G1/127 B

G01C21/26 P

G01C21/34

G06Q50/40

G08G1/00 D

G08G1/005

G16Y10/40

G16Y40/60

【請求項の数】 8

(21)【出願番号】P 2021192695

(22)【出願日】2021-11-29

(65)【公開番号】P2023079299

(43)【公開日】2023-06-08

【審査請求日】2024-09-20

(73)【特許権者】

【識別番号】000237592

【氏名又は名称】株式会社デンソーテン

(74)【代理人】

【識別番号】110001933

【氏名又は名称】弁理士法人 佐野特許事務所

(72)【発明者】

【氏名】三浦 寿

(72)【発明者】

【氏名】藤井 亮太

【審査官】宮本 礼子

(56)【参考文献】

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

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

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

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

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

Ｇ０８Ｇ １／００－９９／００

Ｇ０１Ｃ ２１／００－２１／３６

Ｇ０１Ｃ ２３／００－２５／００

Ｇ０６Ｑ ５０／４０

Ｇ１６Ｙ １０／４０

Ｇ１６Ｙ ４０／６０

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

【請求項1】

単一の路線を時間差で走行する複数の車両が立ち寄る停留所を乗降予約により決定する検索サーバであって、
前記検索サーバは利用者の情報端末と通信可能であり、
前記情報端末から前記利用者の位置、目的地、および、出発日時を受信し、
前記利用者の位置に基づき前記単一の路線内の複数の候補停留所を決定し、
前記単一の路線を走行する車両が前記複数の候補停留所に立ち寄る際の到着時間と、
前記利用者の位置から前記複数の候補停留所までの移動時間、および、前記複数の候補停留所から前記目的地までの乗車時間をそれぞれ算出し、
乗車可能な前記複数の候補停留所を前記情報端末に送信し、
前記情報端末から前記複数の候補停留所から選ばれた候補停留所で乗車予約を受信したとき、選ばれた前記候補停留所を乗車予約対象車両の停車する停留所として前記乗車予約対象車両の経路を決定する、
検索サーバ。

【請求項2】

前記利用者の位置から前記候補停留所までの移動には交通手段での移動を許容する、請求項１に記載の検索サーバ。

【請求項3】

前記候補停留所は前記利用者の前記候補停留所での待機の条件を含めて決定する、請求項１または２に記載の検索サーバ。

【請求項4】

前記利用者の位置から前記候補停留所まで移動する時刻の天候に基づいて前記候補停留所をソートする、請求項１～３のいずれか一項に記載の検索サーバ。

【請求項5】

前記利用者の位置から前記目的地への到着日時に基づいて前記候補停留所をソートする、請求項１～３のいずれか一項に記載の検索サーバ。

【請求項6】

前記利用者の年齢を含む属性に基づいて前記候補停留所までの到達が困難であると判断した場合、前記属性に基づいて前記候補停留所をソートする、請求項１～５のいずれか一項に記載の検索サーバ。

【請求項7】

請求項１～６のいずれか一項に記載の検索サーバと、
前記利用者の位置、目的地、出発日時を送信し、前記複数の候補停留所を受信して表示する情報端末と、
を備える、検索システム。

【請求項8】

単一の路線を時間差で走行する複数の車両が立ち寄る停留所を乗降予約により決定する検索方法であって、
利用者の情報端末から前記利用者の位置、目的地、および、出発日時を受信し、
前記利用者の位置に基づき前記単一の路線内の複数の候補停留所を決定し、
前記単一の路線を走行する車両が前記複数の候補停留所に立ち寄る際の到着時間と、
前記利用者の位置から前記複数の候補停留所までの移動時間、および、前記複数の候補停留所から前記目的地までの乗車時間をそれぞれ算出し、
乗車可能な前記複数の候補停留所を前記情報端末に送信し、
前記情報端末から前記複数の候補停留所から選ばれた候補停留所で乗車予約を受信したとき、選ばれた前記候補停留所を乗車予約対象車両の停車する停留所として前記乗車予約対象車両の経路を決定する、
検索サーバに備えられる情報処理装置が実行する、
検索方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、検索条件に適合する乗車可能なバスを検索する検索サーバ、検索システム、及び検索方法に関する。

【背景技術】

【0002】

バス停方式のデマンドバスは、利用者の予約に応じて運行計画が決定され、停留所で利用者の乗降が行われる。

【0003】

従来、バス停方式のデマンドバスを予約する予約システムでは、利用者が乗車を希望する停留所を１つ選択して得られる検索結果を用いて予約を実行する仕組みが採用されている。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１８－１６０１０９号公報（図３）

【発明の概要】

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

【0005】

したがって、利用者は、乗車を希望する停留所（乗車希望停留所）を１つ選択し、乗車希望時間以降に到着するデマンドバスを検索することになる。しかしながら、タイミングが悪ければ、待ち時間が非常に長くなるおそれがある。

【0006】

例えば、図１に示すように、利用者の乗車希望停留所が利用者の自宅Ｈ１に最も近い停留所Ａのみであるとする。この場合、デマンドバス２号車Ｂ２が停留所Ａを通過した直後に利用者が検索を行うと、１時間後に停留所Ｓを出発するデマンドバス３号車Ｂ３が検索結果となる。

【0007】

待ち時間が非常に長い場合、利用者は、デマンドバスへの乗車を諦めてしまうことがある。このため、乗車の機会損失が生じるという問題がある。

【0008】

なお、特許文献１のバス検索システムでは、複数の路線の停留所における乗車時刻を検索することで、乗車の機会損失を抑制している。しかしながら、過疎地域等では複数の路線が存在しないことがある。このため、特許文献１に開示されたシステムでは、効果的に乗車の機会損失を抑制できないおそれがある。

【0009】

本発明は、上記課題に鑑みて、単一のバス路線において乗車の機会損失を抑制することができる検索サーバ、検索システム、及び検索方法を提供することを目的とする。

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

【0010】

例示的な本発明の検索サーバは、検索サーバは、受信部と、情報処理部と、を備える。前記受信部は、検索条件を受信する。前記情報処理部は、前記検索条件に基づき単一のバス路線における複数の停留所を乗車候補の停留所として選択し、前記検索条件に適合する乗車可能なバスの情報を出力する。

【発明の効果】

【0011】

例示的な本発明によると、単一のバス路線において乗車の機会損失を抑制することができる。

【図面の簡単な説明】

【0012】

【図1】デマンドバスの運行状況を模式的に示す図

【図2】本発明の一実施形態に係る検索システムの全体構成を示す図

【図3】検索サーバの一構成例を示す図

【図4】検索サーバの動作例を示すフローチャート

【図5】検索条件の入力画面の一例を示す図

【図6】検索結果を表示する画面の一例を示す図

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

【0013】

以下、本発明の例示的な実施形態について、図面を参照しながら詳細に説明する。

【0014】

図２は、本発明の一実施形態に係る検索システム１（以下、「検索システム１」という）の全体構成を示す図である。検索システム１は、検索サーバ２と、情報端末３と、を備える。検索システム１は、検索サーバ２に検索条件に基づいた検索を行わせ、検索サーバ２に検索結果を出力させる。検索システム１は、検索サーバ２に出力させた検索結果を情報端末３に表示させる。

【0015】

検索サーバ２は、検索条件を受信し、受信した検索条件に基づき単一のバス路線における複数の停留所を乗車候補の停留所として選択する。また、検索サーバ２は、受信した検索条件に適合する乗車可能なバスを検索し、検索結果を出力する。

【0016】

検索サーバ２は、情報端末３と双方向通信が可能である。検索サーバ２は、単一の場所に設定されるサーバ装置に限定されず、構成要素が複数の場所に分散して設置される分散型のサーバ装置又はクラウドサーバであってもよい。

【0017】

情報端末３は、利用者が所持及び操作する機器であり、例えば、利用者が所持するスマートフォン、タブレット、パーソナルコンピュータ等である。情報端末３には検索用アプリがインストールされていてもよい。情報端末３にインストールされた検索用アプリは、情報端末３に入力された検索条件を、検索サーバ２に提供する。また、情報端末３に検索用アプリがインストールされていない場合、情報端末３は、検索用ＷＥＢサイトにアクセスしてもよい。この場合、検索用ＷＥＢサイトは、情報端末３から入力された検索条件を、検索サーバ２に提供する。

【0018】

なお、検索システム１は、実際には複数の利用者に対して運用されるシステムであり、各利用者が情報端末３を所持することになる。但し、以下では、説明の明確化及び具体化のため、特に述べない限りは、利用者及び情報端末３として一人の利用者と当該一人の利用者が所持する情報端末３にのみ注目するものとする。

【0019】

図３は、検索サーバ２の一構成例を示す図である。図３に示す構成例では、検索サーバ２は、情報処理部２１と、記録部２２と、通信部２３と、を備える。情報処理部２１と、記録部２２と、通信部２３とは、ＢＵＳ２４を通じて双方向通信可能である。なお、ＢＵＳ２４は、物理的な配線等の実体を有することが必須の要件ではなく、仮想的な接続や概念的な接続であってもよい。

【0020】

情報処理部２１は、少なくとも一つのプロセッサを備えるコンピュータである。すなわち、情報処理部２１は、情報処理装置である。具体的には、情報処理部２１は、図示しないＣＰＵ（Central Processing Unit）と、ＲＡＭ（Random Access Memory）等の揮発性メモリと、ＲＯＭ（Read Only Memory）等の不揮発性メモリと、を備えるコンピュータである。情報処理部２１は、記録部２２に不揮発的に記録されたプログラムに基づいて情報の処理及び送受信を行い、検索サーバ２の全体を制御する。

【0021】

通信部２３は、情報端末３と無線通信を行う。通信部２３は、情報端末３から送信されるデータを受信する受信部である。また、通信部２３は、情報端末３にデータを送信又は出力する送信部である。

【0022】

次に、図４を参照して、検索サーバ２の動作を説明する。検索サーバ２は、検索システム１の稼働中に図４に示すフローチャートの動作を行う。

【0023】

まず、情報処理部２１は、通信部２３が情報端末３から検索条件を受信したか否かを判定する（ステップＳ１０）。

【0024】

情報端末３は、アプリ、ＷＥＢサイト等を経由して、検索条件を検索サーバ２に送信する。本実施形態では、検索条件は、情報端末３が検索サーバ２にアクセスした際に、検索サーバ２が情報端末３の画面等に表示させる画面を用いて入力させる。

【0025】

例えば、情報処理部２１は、アプリ、ＷＥＢサイト等を利用して検索サーバ２にアクセスしてきた情報端末３に対して検索条件を入力させる画面を表示させる。図５は、情報端末３に表示される検索条件の入力画面の一例である。図５に示す入力画面では、出発地の入力欄ＩＮ１に「自宅」と入力され、目的地の入力欄ＩＮ２に「停留所Ｇ」と入力され、出発日時の入力欄ＩＮ３に「９月１４日１２時２０分」と入力されている。

【0026】

なお、出発日時ソフトウェアキーＫ１の代わりに到着日時ソフトウェアキーＫ２がタッチパネル、カーソル等によって選択されると、出発日時が入力できなくなくなる代わりに、到着日時が入力できるようになる。検索実行ソフトウェアキーＫ３がタッチパネル、カーソル等によって選択されると、情報端末３から検索サーバ２に検索条件が送信され、通信部２３が検索条件を受信する。

【0027】

情報処理部２１は、通信部２３が検索条件を受信したと判定するまで、ステップＳ１０の処理を繰り返す。

【0028】

情報処理部２１は、通信部２３が検索条件を受信したと判定すると、単一のバス路線における複数の停留所を乗車候補の停留所として選択する（ステップＳ２０）。

【0029】

例えば、図５に示す入力画面のように検索条件の出発地の入力欄ＩＮ１に「自宅」と入力されている場合、各利用者の自宅の位置と単一のバス路線における複数の停留所の位置とが事前に紐づけられて記録部２２に登録されているとよい。この場合、情報処理部２１は、記録部２２に記録されている登録内容に従って、単一のバス路線における複数の停留所を乗車候補の停留所として選択する。

【0030】

また例えば、図５に示す入力画面のように検索条件に含まれる出発地の入力欄ＩＮ１に「自宅」と入力されている場合、各利用者の自宅の位置情報が記録部２２に登録されていてもよい。この場合、情報処理部２１は、記録部２２に記録されている登録内容と記録部２２に記録されている地図情報とに従って、例えば自宅から徒歩５分圏内に存在する単一のバス路線における複数の停留所を乗車候補の停留所として選択する。例えば、情報処理部２１は、図１に示した例の場合、自宅Ｈ１から徒歩５分圏内である停留所Ａ及び停留所Ｅを乗車候補の停留所として選択する。

【0031】

なお、情報端末３がＧＰＳ等の位置情報取得手段を有する場合には、検索条件に含まれる出発地を「現在地」とし、例えば現在地から徒歩５分圏内に存在する単一のバス路線における複数の停留所が乗車候補の停留所として選択されてもよい。

【0032】

上述した例示では、情報処理部２１が、検索条件に含まれる出発地に基づき乗車候補の停留所を自動的に選択することになる。したがって、利用者は、検索の度に複数の停留所を乗車候補の停留所として入力せずにすむ。これにより、利便性が向上する。ただし、利用者が、検索条件の入力画面において、単一のバス路線における複数の停留所を出発地（乗車候補の停留所）として手動で入力するような仕様であってもよい。

【0033】

図４を参照する。次に、情報処理部２１は、検索条件に適合する乗車可能なバスを検索する（ステップＳ３０）。図５に示す入力画面のような検索条件であれば、検索条件に適合するには、出発地の入力欄ＩＮ１に入力された「自宅」を出発日時の入力欄ＩＮ３に入力された「９月１４日１２時２０分」以降に出発して間に合う必要がある。図５に示す入力画面のような検索条件であれば、情報処理部２１は、自宅から乗車候補の停留所それぞれまでの移動時間及びバスの時刻表を把握して、検索条件に適合する乗車可能なバスを検索する。なお、単一のバス路線における複数の停留所を出発地（乗車候補の停留所）として入力するような仕様であれば、情報処理部２１は、自宅から乗車候補の停留所それぞれまでの移動時間を把握しなくてよい。

【0034】

情報処理部２１は、検索条件に適合する乗車可能なバスを例えば目的地への到着日時でソートしたものを検索結果とする。

【0035】

図４を参照する。次に、通信部２３は、検索結果を情報端末３に送信又は出力する（ステップＳ４０）。検索結果を受信した情報端末３は、図６に示すような検索結果を情報端末３に備わる表示画面に表示する。図６に示す検索結果は、９月１４日１２時２０分の時点でデマンドバスの運行状況が図１に示す状況であり、乗車候補の停留所が停留所Ａ及び停留所Ｅである場合を示している。

【0036】

図６に示す検索結果では、検索結果の表示欄Ｄ１に上から順に、最も早く目的地に到着する検索結果Ｒ１、２番目に早く目的地に到着する検索結果Ｒ２、３番目に早く目的地に到着する検索結果Ｒ３が表示される。

【0037】

最も早く目的地に到着する検索結果Ｒ１は、最も早く目的地に到着する具体的な経路を示す「１２：２３出発地発→１２：２５停留所Ｅ発→１２：３８目的地着」という表示である。

【0038】

２番目に早く目的地に到着する検索結果Ｒ２は、２番目に早く目的地に到着する具体的な経路を示す「１２：３９出発地発→１２：４２停留所Ｅ発→１２：５５目的地着」という表示である。

【0039】

３番目に早く目的地に到着する検索結果Ｒ３は、３番目に早く目的地に到着する具体的な経路を示す「１３：０２出発地発→１３：０４停留所Ａ発→１３：２８目的地着」という表示である。

【0040】

９月１４日１２時２０分の時点でデマンドバスの運行状況が図１に示す状況であって、乗車候補の停留所が利用者の自宅Ｈ１に最も近い停留所Ａのみであれば、デマンドバスＢ３にしか乗車できない。しかしながら、上述したような例のように乗車候補の停留所を複数の停留所（停留所Ａ及び停留所Ｅ）にすることで、停留所Ａを既に通過しているデマンドバスＢ１及びＢ２にも乗車することが可能となる。つまり、単一のバス路線において乗車の機会損失を抑制することができる。これは、バス事業者からすれば、乗車率の向上を図ることができる。

【0041】

検索サーバ２は、ステップＳ４０の処理を完了した後、再びステップＳ１０の処理を行う。

【0042】

上記実施形態は、全ての点で例示であって、制限的なものではないと考えられるべきであり、本発明の技術的範囲は、上記実施形態の説明ではなく、特許請求の範囲によって示されるものであり、特許請求の範囲と均等の意味及び範囲内に属する全ての変更が含まれると理解されるべきである。

【0043】

例えば、検索条件は、バスの運行に関する条件であるバス運行条件に追加して適用する条件である追加条件を含んでも良い。追加条件としては、例えば、出発地から停留所までの移動に関する条件、停留所での待機に関する条件等を挙げることができる。出発地から停留所までの移動に関する条件としては、例えば、下記（１）～（４）等を挙げることができる。また、停留所での待機に関する条件としては、例えば、下記（５）等を挙げることができる。
（１）雨天時には出発地から乗車候補の停留所までの移動で極力雨に濡れないという条件
（２）出発地から乗車候補の停留所までの移動で日陰が極力多いという条件
（３）出発地から乗車候補の停留所までの移動で極力階段が少ないという条件
（４）出発地から乗車候補の停留所までの移動で極力勾配が小さいという条件
（５）乗車候補の停留所に椅子が設置されているという条件

【0044】

そして、情報処理部３１が、追加条件に応じて検索結果をソートすればよい。例えば、追加条件を最優先する条件として検索結果がソートされてもよい。また、例えば、目的地への到着日時を一定時間で区切り、区切られた一定時間内で追加条件に応じて検索結果がソートされてもよい。追加条件に応じて検索結果がソートされることで、利用者が利用者の好みや利用者の属性に合ったバスでの移動方法を見つけることが容易になる。

【0045】

利用者の属性とは、例えば、利用者の年齢である。利用者がいわゆる高齢者である場合、利用者は、長い階段の乗降や勾配の大きな道の歩行が困難な場合がある。そこで、上記の追加条件（３）（４）を用いることで、利用者が高齢者である場合も、安全に到達できるバス停を検索することができる。

【0046】

上記の追加条件（１）～（５）は、利用者の属性に基づいて、自動で適用されてもよい。この場合、情報端末３は、利用者の属性に関する情報を有し、上記の追加条件（１）～（５）から適用すべき条件を選択する。そして、情報端末３は、検索条件の送信の際に、選択した追加条件を送信する。

【0047】

上記の追加条件（１）～（５）は、時刻や天候を考慮して適用されてもよい。例えば、上記の追加条件（２）に含まれる日陰の位置は時刻や天候に基づいて変化する。このため、上記の追加条件（１）～（５）を時刻や天候を考慮して適用することで、より効果的な検索ができる。

【0048】

検索サーバ２は、利用者の属性を記録したデータベースを有してもよい。この場合、検索サーバ２は、利用者の属性に基づいて、上記の追加条件（１）～（５）のうち、適用すべき条件を考慮して検索する。

【0049】

また例えば、情報処理部３１が、バス以外の交通手段との組み合わせを許容して検索条件に適合する乗車可能なバスを検索してもよい。例えば、出発地から乗車候補の停留所までタクシーで移動することを許容してもよい。これにより、検索結果が多様化するので、単一のバス路線において乗車の機会損失をより一層抑制することができる。

【0050】

また例えば、情報処理部３１が、検索条件に基づき単一のバス路線における複数の停留所を降車候補の停留所として選択してもよい。複数の降車候補の停留所は、乗車候補の停留所と同様に情報処理部３１が自動的に選択してもよく、利用者によって手動で入力されてもよい。これにより、例えば目的地への到着日時に制約がある場合等において検索結果が多様化するので、単一のバス路線において乗車の機会損失をより一層抑制することができる。

【0051】

また例えば、単一のバス路がデマンドバスの路線である場合には、情報処理部３１は、デマンドバスの予約を受け付けてもよい。この場合、情報端末３が検索結果を表示する画面においてデマンドバスの予約を促すようにすればよい。これにより、利用者にとって検索と予約がシームレスとなり、利便性が向上する。

【0052】

また、単一のバス路がデマンドバス以外の座席予約可能なバスの路線である場合にも、同様に情報処理部３１がバスの座席予約を受け付けてもよい。

【符号の説明】

【0053】

１ 検索システム
２ 検索サーバ
３ 情報端末
２１ 情報処理部
２２ 記録部
２３ 通信部
２４ ＢＵＳ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】