JP2002150470A - 乗合運行支援システム及びその方法 - Google Patents

Abstract

(57)【要約】 【課題】 運行しやすい状態に纏めた複数の乗客を乗合
車両運行業者に効率よく提供でき、顧客には、好きなと
きに、希望する場所から目的地まで希望する時間に楽に
移動することのできる安価で新しい交通手段を提供でき
る乗合運行支援方法及びそのシステムを提供する。 【解決手段】 顧客は顧客用端末３００から運行依頼を
行なう（Ｓ１）。サービスセンタ１００は受信した運行
依頼に対して乗合グルーピング処理を行い（Ｓ２）、Ｗ
ＷＷサーバ１２０を通じて乗合車両運行業者に運行依頼
を行う（Ｓ３）。乗合車両の運行依頼に応じることがで
きる乗合車両運行業者は、業者用端末４００から運行受
託を送信する（Ｓ４）。顧客はサービスセンタ１００か
ら運行決定通知を受け（Ｓ５）、所定の日時に乗合車両
運行業者の運行する乗合車両に乗車し（Ｓ６）、目的地
へと向かう（Ｓ７）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、乗合運行支援シス
テム及びその方法に関し、より詳細には、オンライン・
データベース管理システムにおいて、顧客から受け付け
た運行依頼を取り纏めて乗合車両運行業者に通知するこ
とにより乗合車両の運行支援を行う乗合運行支援システ
ム及びその方法に関する。

【０００２】

【従来の技術】特定の日、特定の時間に出発する電車や
飛行機に乗るために駅や空港に向かう場合は、電車やバ
スを乗り継いでいくのが通常である。１度乗ってしまえ
ば乗り換えの必要などなく目的地まで運んでくれるタク
シーは理想的な交通手段ではあるが、費用がかさむこと
から避けられることが多く、大きな荷物を抱えている場
合や、何人かでまとまって目的地に向かう場合などに限
って利用されることが多いのが実情である。

【０００３】この理想的な交通手段であるタクシーをよ
り安価に利用する方法として、いくつかの駅や空港で
は、特定の場所に移動したい乗客を何人か集め、所定の
人数が集まった時点で出発し、決まった場所まで運ぶ、
といった乗合タクシーの運行が行われている。

【０００４】

【発明が解決しようとする課題】しかしながら、従来の
乗合タクシーは、空港などの特定の場所において顧客を
集客し、場当たり的にその顧客をグループ化して運行を
決定するため、効率的な運行を行うことができなかっ
た、という問題があった。また、現在、タクシーの運行
予約はもっぱら電話、あるいはインターネットを介して
行われているが、このようにしてなされた運行予約の処
理と乗合車両運行業者との間での運行決定プロセスが確
立していないため、今後予約件数が増加した場合、効率
的に運行予約の処理を行うことができない、という問題
もあった。

【０００５】さらに、乗合タクシーを運行する乗合車両
運行業者は多数あるものの、それらの運行状況を取り纏
めるような運行決定システムが確立していないため、顧
客は、希望する条件で乗合タクシーを運行する乗合車両
運行業者を見つけ出すまで、料金や出発地などについて
個々に問い合わせを行わなければならない、という問題
もあった。

【０００６】このような状況は、タクシーなどを運行す
る乗合車両運行会社にとっても問題となっていた。費用
が嵩まなければタクシーを利用したいという潜在的な顧
客は多いものの、タクシー運転手自身で顧客の乗車希望
を取りまとめ、乗合客を発掘することは困難であり、乗
合車両運行会社にあっては、数少ない利用客を発見する
か、乗合タクシーの営業場所に出向いて乗合客を集めな
ければ収益機会を得ることができないという問題もあっ
た。

【０００７】本発明は、このような問題に鑑みてなされ
たもので、その目的とするところは、運行しやすい状態
に纏めた複数の乗客をタクシーなどの乗合車両を運行す
る乗合車両運行業者に効率よく提供でき、顧客には、好
きなときに、希望する場所から目的地まで希望する時間
に楽に移動することのできる安価で新しい交通手段を提
供できる乗合運行支援システムを提供することにある。

【０００８】また本発明の目的は、乗合運行支援システ
ムの備えるサーバと、業者用端末とに対し、運行しやす
い状態に纏めた複数の乗客を乗合車両運行業者へ効率よ
く提供することを実現することのできるプログラムを提
供することにある。また、顧客用端末に対し、好きなと
きに、希望する場所から目的地まで希望する時間に楽に
移動することのできる安価で新しい交通手段の提供を実
現することのできるプログラムを提供することにある。

【０００９】また本発明の目的は、運行しやすい状態に
纏めた複数の乗客を乗合車両運行業者に効率よく提供で
き、顧客には、好きなときに、希望する場所から目的地
まで希望する時間に楽に移動することのできる安価で新
しい交通手段を提供できる乗合運行支援方法を提供する
ことにある。

【００１０】

【課題を解決するための手段】このような目的を達成す
るために、請求項１に記載の発明は、業者用端末及び顧
客用端末に対し乗合情報を提供するサーバと、該サーバ
にネットワークを介して接続された前記業者用端末と前
記顧客用端末とを備えた乗合運行支援システムにおける
前記サーバにおいて、前記顧客用端末から受信した乗合
車両に対する運行依頼を記憶する第１の記憶手段と、前
記運行依頼を取り纏めて運行グループを生成する運行グ
ループ生成手段と、前記運行グループ生成手段が生成し
た運行グループを記憶する第２の記憶手段と、前記業者
用端末に対し、前記運行グループに対する運行を依頼す
る運行依頼信号を発信する依頼信号発信手段と、前記業
者用端末から受信した前記運行グループに対する運行計
画を記憶する第３の記憶手段と、前記顧客用端末からの
前記運行計画に対する最終確認信号の受信に応答して、
前記業者用端末に該運行計画に対する最終確認通知を発
信する確認通知発信手段とを備えたサーバであることを
特徴とする。

【００１１】ここで「乗合車両」とは、タクシー、ハイ
ヤー、貸切バス、乗合バス、乗合タクシーなどをいう。
また、「運行依頼」とは、顧客が乗合車両の運行を依頼
するために行う依頼をいい、出発日、出発希望時間、到
着日、到着希望時間、駅や空港名などの目的地あるいは
出発地、利用人数等を含むものをいう。「運行グルー
プ」とは、１台の乗合車両が運行する顧客のグループを
いう。

【００１２】請求項２に記載の発明は、請求項１に記載
のサーバにおいて、前記運行グループ生成手段は、前記
運行依頼から処理対象となる運行依頼を抽出する第１の
抽出手段と、前記第１の抽出手段の抽出した運行依頼か
ら、最低乗客数を満たす運行依頼を抽出して運行グルー
プを生成する第１のグルーピング手段とを備えたことを
特徴とする。

【００１３】ここで「最低乗客数」とは、乗合車両運行
会社が１台の乗合車両を運行するにあたり、収益をあげ
ることのできるであろう乗客の数をいう。

【００１４】請求項３に記載の発明は、請求項２に記載
のサーバにおいて、前記第１の抽出手段は、乗合車両乗
車日と、到着希望時間または出発希望時間の属する時間
帯とをキーとして処理対象となる運行依頼を抽出するこ
とを特徴とする。

【００１５】請求項４に記載の発明は、請求項２に記載
のサーバにおいて、前記第１の抽出手段は、前記顧客用
端末から受信した運行依頼の含む乗合車両乗車日と、到
着希望時間または出発希望時間の属する時間帯とをキー
として処理対象となる運行依頼を抽出することを特徴と
する。

【００１６】請求項５に記載の発明は、請求項２に記載
のサーバにおいて、前記第１のグルーピング手段が運行
グループの生成を行うことのできない場合、前記第１の
抽出手段の抽出した運行依頼から、同じ固定場所と、所
定の隣接度合いの出発地または到着地とを持つ隣接運行
依頼を抽出する第２の抽出手段と、前記隣接運行依頼を
取り纏めて、最低乗客数を満たす運行グループを生成す
る第２のグルーピング手段とを備えたことを特徴とす
る。

【００１７】請求項６に記載の発明は、請求項５に記載
のサーバにおいて、前記隣接度合いは、あらかじめ設定
された隣接地区テーブルに基づいて定められることを特
徴とする。

【００１８】請求項７に記載の発明は、請求項６に記載
のサーバにおいて、前記隣接地区テーブルは、郵便番号
に基づいて地域を区分けし、該区分けごとに地区相互の
隣接度合いを定めたものであることを特徴とする。

【００１９】請求項８に記載の発明は、請求項１に記載
のサーバにおいて、前記顧客用端末からの前記第２の記
憶手段の記憶する運行計画への運行依頼の追加発注信号
の受信に応答して、前記業者用端末に対し、該運行計画
への追加運行依頼信号を発信する追加依頼信号発信手段
を備えたことを特徴とする。

【００２０】請求項９に記載の発明は、請求項１から８
のいずれかに記載のサーバからの前記運行グループに対
する運行を依頼する運行依頼信号の受信に応答して、該
運行グループの含む運行依頼を出力する第１の出力手段
と、該運行依頼に対する運行計画を入力する第１の入力
手段と、該サーバから受信した前記運行計画に対する最
終確認通知を出力する第２の出力手段と、前記サーバと
前記運行依頼と前記運行計画と前記最終確認通知とを含
む情報の交信を行う業者端末側入出力手段とを備えた業
者用端末であることを特徴とする。

【００２１】請求項１０に記載の発明は、請求項９に記
載の業者用端末において、前記サーバの記憶する運行グ
ループを検索する検索手段と、前記検索手段の検索した
検索結果を出力する第３の出力手段と、前記検索手段の
検索した運行グループの含む運行依頼に対する運行計画
を入力する第２の入力手段とを備えたことを特徴とす
る。

【００２２】請求項１１に記載の発明は、請求項９に記
載の業者用端末において、前記サーバからの追加運行依
頼信号の受信に応答して、該追加発注信号の含む運行依
頼を出力する第４の出力手段と、該運行依頼に対する運
行計画を入力する第３の入力手段とを備えたことを特徴
とする。

【００２３】請求項１２に記載の発明は、乗合車両の運
行依頼を入力する入力手段と、請求項１から８のいずれ
かに記載のサーバから受信した前記運行依頼に対する運
行計画を出力する第１の出力手段と、前記サーバに対し
て前記運行計画に対する最終確認を表示する最終確認信
号を発信する最終確認信号発信手段と、前記サーバに対
して前記運行依頼と前記運行計画とを含む情報の交信を
行う顧客用端末側入出力手段とを備えた顧客用端末であ
ることを特徴とする。

【００２４】請求項１３に記載の発明は、請求項１２に
記載の顧客用端末において、前記サーバの記憶する運行
グループに対する運行計画を検索する検索手段と、前記
検索手段の検索した運行計画に対し運行依頼の追加発注
を指示する追加発注信号を発信する追加発注信号発信手
段と、前記サーバから受信した前記追加発注への運行計
画を出力する第２の出力手段とを備えたことを特徴とす
る。

【００２５】請求項１４に記載の発明は、請求項１から
８のいずれかに記載のサーバにおいて、前記顧客用端末
から受信した乗合車両に対する運行依頼を記憶するとと
もに、該運行依頼を取り纏めて運行グループを生成する
ステップと、前記運行グループを記憶するとともに、前
記業者用端末に対し、前記運行グループに対する運行を
依頼する運行依頼信号を発信するステップと、前記業者
用端末から受信した前記運行グループに対する運行計画
を記憶するステップと、前記運行計画を前記顧客用端末
に送信するステップと、前記顧客用端末からの前記運行
計画に対する最終確認信号の受信に応答して前記業者用
端末に最終確認通知を送信するステップとを実現させる
プログラムであることを特徴とする。

【００２６】請求項１５に記載の発明は、請求項１４に
記載のプログラムにおいて、前記運行グループを生成す
るステップは、前記運行依頼から処理対象となる運行依
頼を抽出するステップと、前記第１の抽出手段の抽出し
た運行依頼から、最低乗客数を満たす運行依頼を抽出し
て運行グループを生成するステップとを備えたことを特
徴とする。

【００２７】請求項１６に記載の発明は、請求項１５に
記載のプログラムにおいて、前記運行依頼から処理対象
となる運行依頼を抽出するステップは、乗合車両乗車日
と、到着希望時間または出発希望時間の属する時間帯と
をキーとして処理対象となる運行依頼を抽出することを
特徴とする。

【００２８】請求項１７に記載の発明は、請求項１５に
記載のプログラムにおいて、前記運行依頼から処理対象
となる運行依頼を抽出するステップは、前記顧客用端末
から受信した運行依頼の含む乗合車両乗車日と、到着希
望時間または出発希望時間の属する時間帯とをキーとし
て処理対象となる運行依頼を抽出することを特徴とす
る。

【００２９】請求項１８に記載の発明は、請求項１５に
記載のプログラムにおいて、前記最低乗客数を満たす運
行依頼を抽出して運行グループを生成するステップにお
いて、運行グループの生成を行うことのできない場合、
前記抽出された運行依頼から、同じ固定場所と、所定の
隣接度合いの出発地または到着地とを持つ隣接運行依頼
を抽出するステップと、前記隣接運行依頼を取り纏め
て、最低乗客数を満たす運行グループを生成するステッ
プとを備えたことを特徴とする。

【００３０】請求項１９に記載の発明は、請求項９から
１１のいずれかに記載の業者用端末において、請求項１
から８のいずれかに記載のサーバからの前記運行グルー
プに対する運行を依頼する運行依頼信号の受信に応答し
て、該運行グループの含む運行依頼を出力するステップ
と、該運行依頼に対する運行計画の入力に応答して、前
記業者端末側入出力手段を制御して前記サーバに該運行
計画を送信するステップと、前記サーバから受信した前
記運行計画に対する最終確認通知を出力するステップと
を実現させるプログラムであることを特徴とする。

【００３１】請求項２０に記載の発明は、請求項１９に
記載のプログラムにおいて、前記サーバからの追加運行
依頼信号の受信に応答して、該追加発注信号の含む運行
依頼を出力するステップと、該運行依頼に対する運行計
画の入力に応答して、前記業者端末側入出力手段を制御
して前記サーバに該運行計画を送信するステップとを備
えたことを特徴とする。

【００３２】請求項２１に記載の発明は、請求項１０に
記載の業者用端末において、請求項１から８のいずれか
に記載のサーバの記憶する運行グループを検索し、検索
結果を出力するステップと、前記検索結果に対する運行
計画の入力に応答して前記サーバに該運行計画を送信す
るステップと、前記サーバから受信した前記運行計画に
対する最終確認通知を出力するステップとを実現させる
プログラムであることを特徴とする。

【００３３】請求項２２に記載の発明は、請求項１２ま
たは１３に記載の顧客用端末において、乗合車両の運行
依頼の入力に応答して、請求項１から８のいずれかに記
載のサーバに該運行依頼を送信するステップと、前記サ
ーバから受信した前記運行依頼に対する運行計画を出力
するステップと、前記サーバから受信した前記運行計画
に対する最終確認信号を前記サーバに対して発信するス
テップとを実現させるプログラムであることを特徴とす
る。

【００３４】請求項２３に記載の発明は、請求項１３に
記載の顧客用端末において、前記サーバの記憶する運行
グループに対する運行計画を検索するステップと、前記
検索手段の検索した運行計画に対し運行依頼の追加発注
を指示する追加発注信号を発信するステップと、前記サ
ーバから受信した前記追加発注に対する運行計画を出力
するステップと、前記運行計画に対する最終確認信号を
発信するステップとを実現させるプログラムであること
を特徴とする。

【００３５】請求項２４に記載の発明は、請求項１４か
ら２３のいずれかに記載のプログラムを格納するコンピ
ュータ読取可能な記録媒体であることを特徴とする。

【００３６】請求項２５に記載の発明は、請求項１から
８のいずれかに記載のサーバと、該サーバにネットワー
クを介して接続された請求項９から１１のいずれかに記
載の前記業者用端末と請求項１２または１３に記載の前
記顧客用端末とを備えた乗合運行支援システムを用いて
乗合運行の支援を行う方法であって、前記顧客用端末に
おいて、乗合車両への運行依頼を入力し、前記サーバに
送信するステップと、前記サーバにおいて、前記顧客用
端末から受信した前記運行依頼を取り纏めて運行グルー
プを生成するステップと、前記サーバにおいて、前記運
行グループを記憶するとともに、前記業者用端末に対
し、前記運行グループに対する運行を依頼する運行依頼
信号を発信するステップと、前記業者用端末において、
前記サーバからの前記運行グループに対する運行を依頼
する運行依頼信号の受信に応答して、該運行グループの
含む運行依頼を出力するステップと、前記業者用端末に
おいて、該運行グループに対する運行計画の入力に応答
して、前記第１の業者端末側入出力手段を制御して前記
サーバに該運行計画を送信するステップと、前記サーバ
において、前記業者用端末から受信した前記運行計画を
記憶し、前記顧客用端末に送信するステップと、前記顧
客用端末において、前記サーバから受信した前記運行計
画に対する最終確認信号を前記サーバに対して発信する
ステップと、前記サーバにおいて、前記顧客用端末から
の前記運行計画に対する最終確認信号の受信に応答して
前記業者用端末に最終確認通知を送信するステップと、
前記業者用端末において、前記サーバから受信した前記
運行計画に対する最終確認通知を出力するステップとを
備えた乗合運行支援方法であることを特徴とする。

【００３７】

【発明の実施の形態】本発明の実施例について、以下に
図面を参照しつつ詳細に説明する。図１は、本発明の実
施される乗合運行支援システムのシステム構成の一例を
示す図である。乗合運行支援システムは、サービスセン
タ１００と、顧客用端末３００と、業者用端末４００
と、サービスセンタ１００と顧客用端末３００と業者用
端末４００とを相互に接続するインターネットなどのネ
ットワーク５００とを備える。

【００３８】サービスセンタ１００は、乗合運行支援シ
ステムを運営管理するシステム管理者により管理される
ものであり、顧客から受け付けた乗車要求を運行しやす
いグループに取り纏め、業者用端末４００に提供する機
能を有する。サービスセンタ１００は、ウェブページ用
のＨＴＭＬデータ等を格納ＷＷＷサーバ１２０と、乗合
グルーピング処理などを実現する処理プログラム実行時
の演算処理を行なうデータベースサーバ１４０と、顧客
の乗車要求情報などを格納するデータベース２００とを
備える。

【００３９】顧客用端末３００は、乗合運行支援システ
ムを利用する顧客により使用される端末であり、乗合車
両への運行依頼を行うことのできる端末であれば、顧客
個人が所有する端末でも、顧客以外の他人の所有する端
末でも、店舗などの特定の場所に設置された端末でもよ
い。業者用端末４００は、ハイヤーやタクシー、貸切バ
スなどの乗合車両の運行を行う乗合車両運行業者により
使用される端末である。顧客用端末３００及び業者用端
末４００は、いずれもインターネットなどのネットワー
ク５００を介してサービスセンタ１００にアクセスする
機能を有する。顧客用端末３００及び業者用端末４００
の機器としては、ウェブ情報（ＨＴＭＬ文書などのマー
クアップランゲージ文書により規定される情報）を閲覧
可能なブラウザソフトウェア（例えば、マイクロソフト
社のインターネットエクスプローラ（商標）、ネットス
ケープ・コミュニケーション社のネットスケープ(商標)
等）を搭載した市販のパーソナルコンピュータ、ＰＤＡ
（Personal Data Assistance）等の情報処理装置や、
無線呼出端末、ＰＨＳ端末、移動体通信端末のうちいず
れかであってもよい。特に、移動体通信端末は、電子メ
ール機能やインターネットへのアクセス機能を有する端
末であってもよい（例えば、株式会社エヌ・ティ・ティ
・ドコモ社が提供するｉモード（サービス名）端末
等）。

【００４０】ネットワーク５００は、サービスセンタ１
００と、顧客用端末３００と業者用端末４００とを相互
に接続する機能を有し、例えば、インターネットや、イ
ントラネットや、ＬＡＮや、公衆電話網（アナログ／デ
ジタルの双方を含む）や、ＰＤＣ／ＰＤＣ―Ｐ方式等の
移動体通信回線交換網／移動体通信パケット交換網や、
無線呼出網や、ＰＨＳ網や、衛星通信網等のうちいずれ
かを含んでもよい。

【００４１】図２は、本実施例におけるサービスセンタ
におけるデータベースサーバ及び該データベースの構成
の一例を示す図である。本実施例におけるのデータベー
スサーバ１４０は、少なくとも、バス１４４を介して相
互に接続されたシステム全体を統括的に制御する主制御
部（以下「ＣＰＵ」とする）１４２と、システム管理者
が各種データを入力する入力手段である入力装置１４６
と、入力データのモニタに用いる表示装置１４８と、各
種監査結果その他のデータを出力する出力装置１５０
と、通信回線（有線／無線、ＬＡＮ／インターネット、
アナログ／デジタル等を含む）などに接続するモデムや
ターミナルアダプタなどからなる通信ポート１５２とか
ら構成される。なお、入力装置１４６、表示装置１４８
及び出力装置１５０は、それぞれ入出力インターフェー
スを介してＣＰＵ１４２に接続されていてもよい。なお
ＣＰＵ１４２は、ＯＳ（Operating System）等の制御
プログラムを有し、本実施例における乗合グルーピング
処理などを実現する処理プログラム実行時の演算処理を
行なう。

【００４２】データベース２００は、ハードディスク等
の固定ディスク装置、フレキシブルディスク、光ディス
クなどのストレージ手段であり、乗合グルーピング処理
などの各種処理プログラムや、処理プログラムの実現に
用いる各種のテーブル、データベース等を格納する。デ
ータベース２００は、第１の確定グループデータ２０
２、事業者情報データ２０４、第２の確定グループデー
タ２０６、固定場所データ２０８、ステータスデータ２
１０、第１の申込データ２１２、所属地区データ２１
４、第２の申込データ２１６、郵便番号データ２１８、
ユーザ情報データ２２０、隣接地区データ２２２など
を、図２に示すように相互に関連した状態で格納してい
る。

【００４３】入力装置１４６は、システム管理者が各種
データを入力する入力手段であり、画面上のメニューを
選択しデータを入力するためのマウス等の各種ポインテ
ィングデバイスやキーボードやイメージスキャナなどか
らなる。表示装置１４８は、各種メニュー画面や、処理
結果等を表示する機能を有し、例えばディスプレイ装置
等である。出力装置１５０は、処理結果を紙等の媒体に
出力する機能を有し、例えばプリンタ装置等である。通
信ポート１５２は、他の端末等と通信回線を介してデー
タを通信する機能を有する。また、サービスセンタ１０
０は、既知のパーソナルコンピュータ、ワークステーシ
ョン、ＰＨＳ端末、移動体通信端末、移動体通信端末ま
たはＰＤＡ等の情報処理端末等の情報処理装置にプリン
タやディスプレイやイメージスキャナ等の周辺装置を接
続し、該情報処理装置に乗合運行支援システムにおける
各種処理を実現させるソフトウェア（プログラム、デー
タ等を含む）を実装することにより実現してもよい。

【００４４】図３は、図２で示したデータベースの格納
する各データベースの構造の一例を示す図である。第１
の確定グループデータ２０２には、固定場所への運行を
希望する運行依頼に関する情報が格納されており、例え
ば、乗合車両に乗車する構成員である顧客に対するグル
ープＩＤ、当該グループを作成した作成日、当該グルー
プの人数、出発地、到着地の固定場所ＩＤなどの情報が
格納されている。第２の確定グループデータ２０６に
は、固定場所からの運行を希望する運行依頼に関する情
報が格納されており、例えば、乗合車両に乗車する構成
員である顧客に対するグループＩＤ、当該グループを作
成した作成日、当該グループの人数、出発地の固定場所
ＩＤ、到着地などの情報が格納されている。

【００４５】事業者情報データ２０４には、事業者Ｉ
Ｄ、パスワード、住所、電話番号などの情報が格納され
ている。固定場所データ２０８には、固定場所として指
定されている駅名や空港名などの固定場所名とそのＩ
Ｄ、郵便番号などの情報が、図４のに示すように相互
に関連付けられた固定場所テーブルといった状態で格納
されている。ステータスデータ２１０には、第１の確定
グループデータ２０２あるいは第１の申込データ２１２
などの各種データの状態を示すステータス名、ステータ
スＩＤなどの情報が、図４のに示すように相互に関連
付けられたステータステーブルといった状態で格納され
ている。

【００４６】第１の申込データ２１２には、固定場所へ
の運行を希望する顧客からの運行依頼に関する情報が格
納されており、例えば、運行依頼を行なった申込日時、
運行依頼に対して割り当てられた申込番号、運行依頼を
したユーザのユーザＩＤ、到着場所の固定場所ＩＤのほ
か、出発地の郵便番号や住所、出発日、出発希望時間な
どの情報が格納されている。第２の申込データ２１６に
は、固定場所からの運行を希望する顧客からの運行依頼
に関する情報が格納されており、例えば、運行依頼を行
なった申込日時、運行依頼に対して割り当てられた申込
番号、運行依頼をしたユーザのユーザＩＤ、出発場所の
固定場所ＩＤのほか、到着地の郵便番号や住所、到着
日、到着希望時間などの情報が格納されている。

【００４７】所属地区データ２１４には、それぞれの地
区の住民特性などによる固定場所への利用頻度などに鑑
み、各郵便番号が、特定の固定場所との関係においてラ
ンク付けがされ、図４のに示すように相互に関連付け
られた所属地区テーブルといった状態で格納されてい
る。郵便番号データ２１８には、郵便番号と、各郵便番
号に基づいて特定される隣接地区などの情報が、図５の
に示すように相互に関連付けられた郵便番号テーブル
といった状態で格納されている。ユーザ情報データ２２
０には、運行依頼を行ったユーザのユーザＩＤ、パスワ
ード、住所、電話番号などの情報が格納されている。隣
接地区データ２２２には、郵便番号、各郵便番号から特
定される隣接地区郵便番号、隣接地区ランクなどの情報
が、図５のに示すように相互に関連付けられた隣接地
区テーブルといった状態で格納されている。

【００４８】なお、このように構成されたサービスセン
タ１００を所有するシステム管理者は、例えばハイヤー
やタクシー、貸切バスを保有し、乗合車両の運行を行っ
ているタクシー会社などに対し、顧客の手配を専門に行
う業者などであってもよく、また、タクシー会社自身で
あってもよい。

【００４９】次に、このように構成された本実施形態に
おける乗合運行支援システムの動作の一例について説明
する。乗合運行支援システムの動作の主なものとして
は、顧客から受けた運行予約の取り纏めを行い、それに
基づいて乗合車両の運行を行う予約依頼型と、予約依頼
型での取り纏め処理に間に合わなかった運行依頼予約
や、予約依頼型では取り纏め処理を行うことのできない
ような細かな運行依頼予約などの取り纏めを行う未確定
依頼型と、急な出張などにより、あらかじめ乗合車両の
運行予約を行うことのできなかった顧客が、自ら乗合車
両の運行状況などをチェックし、既に運行の決定してい
る乗合車両に対して、必要に応じて随時自らの運行依頼
をいれていくリアルタイム依頼型とがある。

【００５０】まず、本実施形態における基本的な処理過
程である予約依頼型について説明する。図６は、顧客か
ら受けた運行予約の取り纏めを行い、それに基づいて乗
合車両の運行を行うという、予約依頼型における処理過
程の流れの一例を示す図である。

【００５１】駅や空港へ向かう必要の生じた顧客は、自
己の保有する顧客用端末３００からサービスセンタ１０
０にアクセスし、運行依頼を行う(Ｓ１)。顧客がサービ
スセンタ１００に運行依頼入力要求を行うと、サービス
センタ１００は顧客用端末３００にユーザＩＤとパスワ
ードなどの認証情報の入力を促すので、まず顧客は、事
前にサービスセンタ１００に登録してある認証情報の入
力を行う。認証情報を受信すると、サービスセンタ１０
０のデータベースサーバ１４０は、データベース２００
内のユーザ情報データ２２０を検索し、アクセスしてき
た顧客に対する認証処理を行う。顧客が認証された場合
には、顧客用端末３００には、図７に示すような運行依
頼入力画面が送信されるので、顧客はこの運行依頼入力
画面から必要事項の入力を行い、サービスセンタ１００
に送信し、運行依頼を行なう。

【００５２】運行依頼入力画面(図７)には、乗合車両に
乗車する場所を入力する出発地入力欄７ａ、目的地を入
力する到着地入力欄７ｂ、乗車日を入力する出発日入力
欄７ｃ、出発希望時間入力欄７ｄ、目的地への到着日を
入力する到着日入力欄７ｅなどのほか、飛行機などの出
発時間に合わせて目的地に到着したい場合に入力する到
着希望時間７ｆ、顧客とともに乗合車両へ乗車する人数
を入力する申込人数入力欄７ｇ、前回利用した際の印象
などから、運行業者を指定したい場合に入力を行う指定
業者入力欄７ｈ、荷物の過多や、小さい子供の有無など
の連絡時項を入力する要望事項入力欄７ｉなどが設けら
れており、顧客はここから少なくとも出発地と到着地、
到着希望時間、申込人数の入力を行うことにより運行依
頼を行う。図７に示すように、出発地入力欄７ａ、到着
地入力欄７ｂ、指定業者入力欄７ｈなどは、あらかじめ
登録されている選択肢の中から顧客が選択することによ
り入力を行う形としてもよい。なお、顧客用端末３００
からサービスセンタ１００に運行依頼を行なうために
は、顧客は事前にサービスセンタ１００に対して顧客名
や住所、パスワードなどの顧客登録を行い、ユーザＩＤ
の交付を受けておく必要がある。

【００５３】サービスセンタ１００は、顧客からの運行
依頼を受信すると、データベース２００内の第１の申込
データ２１２内に受信した情報を格納し、受信した運行
依頼に一対一で対応する申込番号の付与を行なった後、
顧客用端末３００に対し、顧客に自己が入力した運行依
頼を確認させるために、図８に示すような申込内容確認
画面を送信する(Ｓ２)。申込内容確認画面(図８)には、
顧客が運行依頼入力画面(図７)において入力した事項が
表示されている。運行依頼を変更する必要を発見した顧
客は、この申込内容確認画面(図８)の「変更」ボタン８ａ
を選択することにより、一旦登録した運行依頼を変更す
ることもできる。

【００５４】サービスセンタ１００は、受信した運行依
頼を取りまとめ、出発日、出発地、到着地などに基づい
て、１つの運行で数人の乗客を効率よく乗車させ、かつ
目的地に送り届けることのできるようないくつかの運行
グループに割り振る、乗合グルーピング処理を行う（Ｓ
３）。この乗合グルーピング処理については、後に詳述
する。

【００５５】次にサービスセンタ１００は、この乗合グ
ルーピング処理(Ｓ３)によって作成した仮確定グループ
（仮の運行グループ）に関する運行依頼情報をウェブ情
報に掲載することにより、乗合車両運行業者に対して
し、Ｓ２で作成したグループに対する車両の手配を行っ
てくれる乗合車両運行業者を求める運行依頼を行う（Ｓ
４）。

【００５６】乗合車両運行業者は、業者用端末４００か
らサービスセンタ１００内のＷＷＷサーバ１２０に随時
アクセスし、仮確定グループに対する運行依頼情報が掲
載されているか否か、運行依頼情報の検索を行う(Ｓ
５)。仮確定グループに対する運行依頼情報が掲載され
ている場合には、業者用端末４００には、図９に示すよ
うな仮確定グループ一覧画面が表示される。仮確定グル
ープ一覧画面(図９)には、サービスセンタ１００に登録
されている仮確定グループの、グループ番号、到着地、
到着希望時間、申込数、申込人数などの情報が掲示され
ている。仮確定グループ一覧(図９)の中に、関心のある
運行依頼を発見した場合は、グループ番号表示欄９ａに
表示されているグループ番号の中から関心のある仮確定
グループを示すグループ番号を指定することにより、そ
の仮確定グループの詳細情報を取得することができる。

【００５７】図１０は、グループ番号「１００７」を持つ
仮確定グループについての詳細情報を表示した運行グル
ープ詳細表示画面である。運行グループ詳細表示画面
(図１０)には、グループ「１００７」を構成している顧客
についての、申込番号、顧客名、住所、電話番号、出発
希望時間、到着希望時間、申込人数などの情報が表示さ
れている。乗合車両運行業者は、仮確定グループについ
ての詳細情報を取得した上で、運行依頼に応じようとす
る場合には、「受注及び運行計画作成」ボタン１０ａを操
作することにより、運行グループ詳細表示画面(図１０)
に表示された仮確定グループからの運行依頼に対する受
注を行うことができる。

【００５８】なお、乗合車両運行業者がサービスセンタ
１００に運行依頼情報の検索要求を行うと、サービスセ
ンタ１００は業者用端末４００にユーザＩＤとパスワー
ドなどの認証情報の入力を促すので、乗合車両運行業者
は、事前にサービスセンタ１００に登録してある認証情
報の入力を行う。認証情報を受信すると、サービスセン
タ１００のデータベースサーバ１４０は、データベース
２００内の事業者情報データ２０４を検索し、アクセス
してきた乗合車両運行業者に対する認証処理を行う。乗
合車両運行業者が認証された場合に、業者用端末４００
に仮確定グループ一覧画面(図９)が送信される。したが
って、乗合車両運行業者は事前にサービスセンタ１００
に対して事業社名、住所、電話番号、パスワードなどを
登録し、事業者ＩＤの交付を受けるといった事業者登録
を行っておく必要がある。

【００５９】乗合車両運行業者が、運行グループ詳細表
示画面(図１０)の「受注及び運行計画作成」ボタン１０ａ
を操作することにより仮確定グループからの運行依頼に
対する受注を行うと、業者用端末４００には、図１１に
示すような運行計画入力画面が表示される。運行計画入
力画面(図１１)には、仮確定グループを構成している顧
客についての申込番号、顧客名、住所、電話番号、申込
人数などの情報が表示されている。乗合車両運行業者
は、仮確定グループの構成員である顧客の住所や目的地
などを鑑み、適切なルートの選択を行い、目的地に間違
いなく顧客の到着希望時間に到着することのできる出発
予定時間と顧客との待ち合わせ場所とを選択し、出発予
定時間入力欄１１ａから出発予定時間を、待ち合わせ場
所入力欄１１ｂから待ち合わせ場所を入力し、料金表示
欄１１ｃから運行依頼ごとに運賃を入力する。乗合車両
運行業者は、運賃が表示された運行計画入力画面(図１
１)の入力内容の確認を行った後、「登録ボタン」１１ｄ
を押すことにより、サービスセンタ１００に運行計画を
送信する(Ｓ７)。

【００６０】サービスセンタ１００は、データベース２
００内の第１の確定グループデータ２０２内に業者用端
末４００から受信した運行計画を格納し、それに基づ
き、顧客用端末３００に対して料金及び運行計画の通知
を行う(Ｓ８)。このとき、業者用端末４００から受信し
た運行計画は、第１の申込データ２１２の記憶するかく
運行依頼に対しても格納する。図１２は、顧客用端末３
００に表示された料金及び運行計画通知画面の一例であ
る。料金及び運行計画通知画面(図１２)には、顧客名
と、申込番号と、その申し込み番号を持つ運行依頼をグ
ルーピング処理したことにより付与されたグループＩＤ
と、料金と、乗合車両運行業者の指定した待ち合わせ場
所と待ち合わせ時間とが表示されているので、顧客は表
示内容の確認を行い、「最終確認」ボタン１２ａを操作す
ることにより、運行確認を行う（Ｓ９)。顧客が運行確
認を行うと、サービスセンタ１００から顧客用端末３０
０に対し、図１３に示すような申込確定確認画面が送信
されることとなる。

【００６１】顧客が運行確認を行い、顧客用端末３００
に申込確定確認画面（図１３）の送信が行われると、業
者用端末４００には、図１４に示すような運行グループ
状況確認画面が送信され、これによりＳ７において乗合
車両運行業者が送信した運行計画が最終決定される(Ｓ
１０)。運行グループ状況確認画面(図１４)には、グル
ープ番号、出発地、到着地、到着予定時間、グループを
構成する顧客の申込番号、顧客名、顧客の住所、電話番
号、申込人数などのほか、ステータス表示欄１４ａには
表示されている各顧客の運行依頼のステータスが表示さ
れている。ステータス表示欄１４ａに表示されるステー
タスとしては、図４のに示す８段階があるが、Ｓ１０
においては、各顧客の運行依頼は、各顧客から運行計画
に対する最終確認が行われた段階にあるので、ユーザ確
認が終わった段階であることを示すステータス「ユーザ
確認」が表示されている。

【００６２】乗合車両運行業者は、最終決定された運行
計画に基づき、乗合車両の運行を行い（Ｓ１１）、顧客
を目的地へと運び、顧客から運賃の支払を受ける(Ｓ１
２)。その後、乗合車両運行業者は、サービスセンタ１
００に対し、運行結果の報告を行い、運行依頼情報を取
得したことに対するシステム使用料などの支払を行う
(Ｓ１３)。図１５は、乗合車両運行業者が、サービスセ
ンタ１００に対し、運行結果の報告を行う際に入力を行
う運行結果報告画面の一例を示す図である。運行結果報
告画面(図１５)には、乗合車両運行業者がＳ７で送信を
行った運行計画入力画面(図１１)における入力内容が表
示されているので、万一実際の運行が運行計画と異なっ
た場合には、人数入力欄１５ａ、出発時間入力欄１５
ｂ、待ち合わせ場所入力欄１５ｃ、料金入力欄１５ｄ等
から表示内容の修正を行い、「登録」ボタン１５ｅを操作
することによりサービスセンタ１００に対して運行結果
の報告を行う。

【００６３】次に、図６のＳ３において行う乗合グルー
ピング処理について説明する。図１６は、乗合グルーピ
ング処理の処理手順の一例を示すフローチャートであ
る。乗合グルーピング処理は、図１６に示すように、基
本的には、運行依頼の選択(Ｓ１)と、乗合グルーピング
結合処理１(Ｓ２)と、乗合グルーピング結合処理２(Ｓ
３)とにより行われる。以下、詳細に説明する。

【００６４】運行依頼の選択(Ｓ１)は、第１の申込デー
タ２１２、あるいは第２の申込データ２１６に格納され
ている運行依頼のうち、出発到着希望時間が、グルーピ
ング対象指定日のグルーピング指定時間帯にある運行依
頼を選択することによって行う。固定場所への行きにつ
いての運行依頼に対する乗合グルーピング処理を行う場
合は、第１の申込データ２１２に格納されている運行依
頼を対象に行い、固定場所からの帰りについての運行依
頼に対する乗合グルーピング処理を行う場合は、第２の
申込データ２１６に格納されている運行依頼を対象に行
う。グルーピング指定時間帯は、午前と午後の２つの時
間帯に分けたりするだけでなく、１日を数時間ごとに区
切り、いくつかの時間帯を設けたりなどすることによ
り、グルーピング指定時間帯を複数も受けることもでき
る。

【００６５】図１７は、乗合グルーピング結合処理１の
処理手順の一例を示すフローチャートであり、この乗合
グルーピング結合処理１は、運行依頼の選択(図１６の
Ｓ１)によって選択された運行依頼に対して以下の手順
を踏むことによって行われる。

【００６６】まず、乗合車両運行会社の設定した、乗合
車両の運行費用に見合う最低乗客人数である最低乗客人
数「ｃ」を満たす申込人数を持つ運行依頼の抽出を行う
(Ｓ１)。この運行依頼の抽出は、運行依頼の選択(図１
６のＳ１)と同様、固定場所への行きについて乗合グル
ーピング処理を行う場合は第１の申込データ２１２に格
納されている運行依頼を対象に行い、固定場所からの帰
りについて乗合グルーピング処理を行う場合は第２の申
込データ２１６に格納されている運行依頼を対象に行
う。

【００６７】次に、抽出された運行依頼を一件と読み込
み、その人数を「ｐ」とし(Ｓ２)、図１８に示す仮確定
グループ決定処理を行う(Ｓ３)。そして、このような処
理を、図１６の２のＳ１で抽出した全ての運行依頼に対
して行った時点で乗合グルーピング処理１は完了となる
(Ｓ４)。

【００６８】図１８は、仮確定グループ決定処理の処理
手順の一例を示すフローチャートである。仮確定グルー
プ決定処理は、まず、乗合グルーピング結合処理１を示
す図１７のＳ２において１件として読みこまれた運行依
頼に対し、仮のグループＩＤを付与し、仮確定グループ
を作成する(Ｓ１)。そして、この仮確定グループの運行
依頼に基づいて、固定場所ＩＤの付与、出発到着希望時
間の抽出を行う。そして、この仮確定グループからの運
行依頼に対し「仮確定グループ」状態であることを示す
ステータス３とし、固定場所ＩＤ、出発到着希望時間、
とともに、データベース２００に格納する(Ｓ２)。ここ
で、仮確定グループの運行依頼を格納する先は、固定場
所への行きについて乗合グルーピング処理を行っている
場合は第１の確定グループデータ２０２、固定場所から
の帰りについて乗合グルーピング処理を行っている場合
は第２の確定グループデータ２０６となる。そして、申
込番号を手がかりに、第１の申込データ２１２、あるい
は第２の申込データ２１６の格納する仮のグループＩＤ
を付与された運行依頼のステータスを、第１の確定グル
ープデータ２０２、あるいは第２の確定グループデータ
２０６と同様に、「仮確定グループ」状態であることを
示すステータス３に変更する(Ｓ３)。

【００６９】なお、仮確定グループ決定処理(図１８)に
おいて、固定場所ＩＤは、固定場所への行きについて乗
合グルーピング処理を行っている場合は到着地の、固定
場所からの帰りについて乗合グルーピング処理を行って
いる場合は出発地の地名を、図４のに示す固定場所デ
ータ２０８に照合することにより付与される。例えば、
固定場所への行きについて乗合グルーピング処理を行っ
ている場合に、目的地を羽田空港とする運行依頼につい
ては、東京国際空港(羽田)を指す固定場所ＩＤ「１」が付
与され、目的地を成田空港とする運行依頼については、
新東京国際空港(成田)を指す固定場所ＩＤ「２」が付与さ
れることとなる。また、出発到着希望時間は、固定場所
への行きについて乗合グルーピング処理を行っている場
合は、到着希望日の到着希望時間に基づいて、固定場所
からの帰りについて乗合グルーピング処理を行っている
場合は、出発希望日の出発希望時間に基づいて定められ
る。

【００７０】図１９は、乗合グルーピング結合処理２の
処理手順の一例を示すフローチャートである。この乗合
グルーピング結合処理２は、乗合グルーピング結合処理
１(図１７)を終えた後の、仮のグループＩＤを付与され
ていない、ばらばらな状態にある運行依頼を相互に関連
付け、仮確定グループを作成するためにを行うものであ
る。

【００７１】まず、乗合グルーピング結合処理２の対象
となる運行依頼に対して、固定場所ＩＤの付与を行う
(Ｓ１)。固定場所ＩＤは、仮確定グループ決定処理(図
１８)における場合と同様、固定場所への行きについて
乗合グルーピング処理を行っている場合は到着地の、固
定場所からの帰りについて乗合グルーピング処理を行っ
ている場合は出発地の地名を、図４のに示す固定場所
データ２０８に照合することにより付与される。例え
ば、固定場所からの帰りについて乗合グルーピング処理
を行っている場合に、出発地を羽田空港とする運行依頼
については、東京国際空港(羽田)を指す固定場所ＩＤ
「１」が付与され、出発地を成田空港とする運行依頼につ
いては、新東京国際空港(成田)を指す固定場所ＩＤ「２」
が付与されることとなる。

【００７２】次に、所属地区データ２１４に格納されて
いるテーブルに基づき、固定場所に所属する郵便番号が
ランク順に抽出される(Ｓ２)。例えば、目的地を羽田空
港とする行きの運行依頼について乗合グルーピング処理
を行っている場合には、固定場所ＩＤ「１」を持つ運行依
頼に対しては、郵便番号「２２７−００５１」地域がラン
ク１として、郵便番号「２２７−００６２」地域がランク
２として抽出されることとなる。

【００７３】そして、図１６のＳ１で運行依頼を選択す
る際に参照した指定時間帯(例えば指定時間帯「ａ−
ｂ」)の開始時間を「ｇ」とする(Ｓ３)。次に仮確定グ
ループを作成するために参照する最大参照地域を示す隣
接地区ランクの最大値を「ｈ」、抽出時に参照する隣接
地区のランクを「ｉ(抽出開始時の「ｉ」は、出発地あるい
は到着地の郵便番号地域と一致することを示す「０」と
する)」とする(Ｓ４)。ここで「ｈ」は、郵便番号テー
ブル（図５の）の示す隣接地区Ａ、または隣接地区Ｂ
から参照する。例えば、郵便番号が「２２７−００５
１」の地域については、郵便番号テーブル（図５の）
の示す隣接地区Ａのランクは「３」、隣接地区Ｂのラン
クは「５」となっている。よって、この地域の最大参照
地域「ｈ」は、固定場所への行きについてグルーピング
を行う場合は「３」、固定場所からのから帰りについて
グルーピングを行う場合は「５」ということになる。

【００７４】次に、乗合車両に同乗する顧客が、同乗客
との関係で、例えば早めに目的地に到着することとなる
ような場合に、顧客が目的地で飛行機や電車に乗る時間
まで待つこととなる時間幅を「ｋ(抽出開始時の「ｋ」は、
全く待ち時間のない状態である「０」とする)」、顧客が
許容し得るであろう「ｋ」の最大時間幅を「ｓ」とする(Ｓ
５)。ここで「ｓ」は、郵便番号テーブル（図５の）
の示す、最大時間幅Ｅ、または最大時間幅Ｆから参照す
る。例えば、郵便番号が「２２７−００５１」の地域に
ついては、郵便番号テーブル（図５の）の示す最大時
間幅Ｅは「３０分」、最大時間幅Ｆは「６０分」となっ
ている。よって、この地域の最大時間幅「ｓ」は、固定
場所への行きについてグルーピングを行う場合は「３０
分」、固定場所からのから帰りについてグルーピングを
行う場合は「６０分」ということになる。

【００７５】隣接地区データ２２２の格納するテーブル
から隣接地区ランク「ｉ」までの郵便番号の検出を行った
上で(Ｓ６)、指定時間帯「ａ-ｂ」の開始時間「ｇ」か
ら、時間幅「ｋ」分の範囲内に出発到着希望時間を持
ち、出発到着地郵便番号がＳ４で指定された隣接地区ラ
ンク「ｉ」内となっている郵便番号群の中にあり、かつ、
第１の申込データ２１２、あるいは第２の申込データ２
１６の格納する運行依頼のステータスが「未確定」状態を
示す「０」となっている運行依頼の抽出を行い、合計人数
を算出する(Ｓ７)。ここで、出発到着希望時間は、固定
場所への行きについて乗合グルーピング処理を行ってい
る場合は、到着希望日の到着希望時間であり、固定場所
からの帰りについて乗合グルーピング処理を行っている
場合は、出発希望日の出発希望時間である。

【００７６】Ｓ８により抽出された運行依頼の合計人数
を「ｍ」とし、以下の判断を行う(Ｓ８)。まず、「ｍ」が
「０」を超えているか否かの判断を行う(Ｓ９)。「ｍ」が
「０」以下である場合、すなわち運行依頼の抽出を行えな
かった場合には、後述するＳ１９へと移り、一方「ｍ」
が「０」を超えている場合、すなわち運行依頼の抽出があ
った場合には、「ｍ」が乗合車両運行会社の設定した、
乗合車両の運行費用に見合う最低乗客人数である最低乗
客人数ｃを満たしているか否かの判断を行う(Ｓ１０)。
「ｍ」が「ｃ」未満である場合、すなわち最低乗客人数を有
していない場合、後述するＳ１５へと移り、一方「ｍ」が
「ｃ」以上、すなわち最低乗客人数を有している場合に
は、乗合車両運行会社が運行を予定している乗合車両１
台あたりの乗車可能人数「ｄ」を「ｍ」が超えていないか
否かの判断を行う(Ｓ１１)。

【００７７】「ｍ」が「ｄ」を超えているような場合には、
図２０に示す乗合グループ分割処理を行い、抽出した運
行依頼を運行可能な人数に分割するような処理を行う
(Ｓ１２)。一方、「ｍ」が「ｄ」以下である場合には、抽出
した運行依頼を纏めて運行を行うことができることとな
るので、「ｍ」を「ｐ」とし（Ｓ１４）、抽出した運行
依頼に対して仮確定グループ決定処理(図１８)を行う
（Ｓ１５）。すなわち、当該運行依頼に仮のグループＩ
Ｄを付与して仮確定グループを作成し(図１８のＳ１)、
第１の確定グループデータ２０２、あるいは第２の確定
グループデータ２０６に当該仮確定グループの運行依頼
を格納し(図１８のＳ２)、第１の申込データ２１２、あ
るいは第２の申込データ２１６の格納する運行依頼のス
テータスを、「仮確定グループ」状態であることを示す
ステータス３に変更する(図１８のＳ３)。

【００７８】「ｍ」が最低乗客人数「ｃ」を有していない場
合、あるいは後述する乗合グループ分割処理(図２０)に
よって処理しきれなかった未処理分がある場合、あるい
は抽出した運行依頼全てについて仮確定グループ決定処
理(図１８)がなされた場合、最低乗客人数「ｃ」人以上乗
車可能人数「ｄ」人以下となるようなグループを生成する
ために、時間幅「ｋ」を「ｔ」づつ広げて(Ｓ１６)、より広
い時間幅を用いてＳ７の抽出処理を行う(Ｓ１７)。ここ
で、時間幅「ｔ」は、固定場所への行きについて乗合グ
ルーピング処理を行っている場合は郵便番号データ２１
８に格納されている図５のに示す郵便番号テーブルの
時間幅Ａを用い、固定場所からの帰りについて乗合グル
ーピング処理を行っている場合は、郵便番号データ２１
８に格納されている図５のに示す郵便番号テーブルの
時間幅Ｂを用いて行う。そして、時間幅「ｋ」をすこしづ
つ、例えば時間幅「ｔ」づつ広げた結果、顧客が許容し得
るであろう「ｋ」の最大時間幅「ｓ」を「ｋ」が超えてし
まったような場合には、時間幅「ｋ」を拡大することによ
る再抽出をやめ、参照地域の拡大による再抽出、すなわ
ち抽出時に参照する隣接地区のランク「ｉ」を「１」づつ拡
大して(Ｓ１８)、より広い参照地域に対してＳ５からの
抽出処理を行う(Ｓ１９)。

【００７９】ここで参照地域「ｉ」を「１」づつ拡大した
結果、仮確定グループを作成するために参照する最大抽
出地域を示す隣接地区ランクの最大値「ｈ」を「ｉ」が
超えてしまったような場合には、参照地域「ｉ」を拡大す
ることによる再抽出をやめ、指定時間帯「ａ-ｂ」の開
始時間「ｇ」に顧客が許容し得るであろう「ｋ」の最大
時間幅「ｓ」を加えることにより指定時間帯の変更を行う
(Ｓ２０)。そして、指定時間帯「ａ-ｂ」の開始時間
「ｇ」に最大時間幅「ｓ」を加えた結果が指定時間帯「ａ
-ｂ」の終了時間「ｂ」を超えてしまっているか否かの判
断を行い(Ｓ２１)、超えてしまった場合には、固定場所
の所属地区郵便番号にある郵便番号は全て参照したか否
かのチェックを行い(Ｓ２２)、超えていない場合には、
再度Ｓ３からの処理を行う。

【００８０】そして、ｓ２２において、まだ参照を行っ
ていない郵便番号があることが判明した場合には、再度
Ｓ２からの処理を行い、一方、全ての郵便番号について
の参照を終えている場合には、固定場所データ２０８に
格納されている全ての固定場所について処理を終えてい
るかの確認を行う(Ｓ２３)。そして、まだ処理を終えて
いない固定場所がある場合には、その固定場所について
Ｓ１からの処理を行い、全ての固定場所について処理を
終えている場合には、乗合グループ結合処理２が終了と
なる。

【００８１】次に、上述の乗合グループ結合処理２(図
１９)のＳ１２、すなわち、乗合グループ結合処理２(図
１９)のＳ１１において、乗合車両運行会社が運行を予
定している乗合車両１台あたりの乗車可能人数「ｄ」を、
Ｓ８により抽出された運行依頼の合計人数「ｍ」が超え
ている場合に行われる、乗合グループ分割処理について
説明する。を行い、抽出した運行依頼を運行可能な人数
に分割するような処理を行う(Ｓ１２)。

【００８２】図２０は、乗合グループ分割処理の処理手
順の一例を示すフローチャートである。まず、乗合グル
ープ結合処理２(図１９)のＳ１１において、乗合車両運
行会社が運行を予定している乗合車両１台あたりの乗車
可能人数「ｄ」を超えているＳ８により抽出された運行依
頼の合計人数「ｍ」に対して、指定時間帯「ａ-ｂ」の
開始時間「ｇ」から、時間幅「ｋ」分の範囲内に出発到
着希望時間を持ち、出発到着地郵便番号がＳ４で指定さ
れた隣接地区ランク「ｉ」内となっている郵便番号群の中
にあり、かつ、第１の申込データ２１２、あるいは第２
の申込データ２１６の格納する運行依頼のステータスが
「未確定」状態を示す「０」となっている運行依頼の抽出を
行う(Ｓ１)。そして、抽出された運行依頼の合計人数を
「ｎ」とする(Ｓ２)。次に、運行依頼の合計人数を「ｎ」が
乗合車両１台あたりの乗車可能人数「ｄ」を超えているか
否かの判断を行い(Ｓ３)、超えていない場合には、その
運行依頼の合計人数を「ｎ」を「ｐ」とし(Ｓ４)、図１８
に示す仮確定グループ決定処理を行い(Ｓ５)、運行依頼
の合計人数を「ｎ」を「０」として処理を終了する(Ｓ６)。

【００８３】一方、運行依頼の合計人数を「ｎ」が乗合車
両１台あたりの乗車可能人数「ｄ」を超えている場合に
は、抽出している運行依頼を、最低乗客人数「ｃ」人以上
乗車可能人数「ｄ」人以下になるように分割してグループ
を生成する(Ｓ７)。この運行依頼の合計人数「ｎ」の分割
は、ステータスが「０」の運行依頼に対し、例えば申込日
の早い順に抽出してグループを生成したり、利用回数な
どに基づく顧客ランクの高い順に抽出してグループを生
成したり、運行依頼登録時に登録された要望事項に基づ
いてグループを作成したりすることなどにより行う。な
お、１グループの人数を最低乗客人数「ｃ」人以上乗車可
能人数「ｄ」人以下とするために、１つの運行依頼内の申
込人数を分割することはできない。そして、合計人数を
「ｎ」を分割することにより生成したグループの人数を
「ｐ」とし(Ｓ８)、図１８に示す仮確定グループ決定処
理を行い(Ｓ９)、運行依頼の合計人数を「ｎ」からグルー
プ人数「ｐ」の控除を行い(Ｓ１０)、グループ人数
「ｐ」の控除後の人数が最低乗客人数「ｃ」人以上か否か
の判断を行う(Ｓ１１)。最低乗客人数「ｃ」人以上である
場合には、さらに「ｎ」を分割してグループを作成できる
こととなることから、再度Ｓ３からの処理を行う。一
方、最低乗客人数「ｃ」人未満である場合には、そこで乗
合グループ分割処理が終了となる。

【００８４】次に、未確定依頼型の処理過程について説
明する。未確定依頼型は、サービスセンタ１００が受け
付けた運行依頼を事業者の運行ニーズに基づいて組み合
わせ、運行ルートの決定を行うという点において、顧客
の運行依頼に基づき運行ルートの組合せを行う上述の予
約依頼型と異なるものである。そのため、予約依頼型で
の処理を前提とせずに未確定依頼型での処理を行うこと
としても良い。また、既に２、３人からの運行依頼を受
注してはいるが、まだ乗合車両の定員には余裕があるよ
うな乗合車両運行業者が、より運行の効率を上げよう
と、既に受注している運行依頼と近いルートでの運行を
希望する顧客からの運行依頼を個別に受注するために利
用することなどが考えられる。

【００８５】図２１は、未確定依頼型における処理過程
の流れの一例を示す図である。駅や空港へ向かう必要の
生じた顧客は、自己の保有する顧客用端末３００からサ
ービスセンタ１００にアクセスし、運行依頼を行う(Ｓ
１)。顧客がサービスセンタ１００に運行依頼入力要求
を行うと、サービスセンタ１００は顧客用端末３００に
ユーザＩＤとパスワードなどの認証情報の入力を促すの
で、まず顧客は、事前にサービスセンタ１００に登録し
てある認証情報の入力を行う。認証情報を受信すると、
サービスセンタ１００のデータベースサーバ１４０は、
データベース２００内のユーザ情報データ２２０を検索
し、アクセスしてきた顧客に対する認証処理を行う。顧
客が認証された場合には、顧客用端末３００には、図７
に示すような運行依頼入力画面が送信されるので、顧客
はこの運行依頼入力画面から必要事項の入力を行い、サ
ービスセンタ１００に送信し、運行依頼を行なう。

【００８６】顧客は運行依頼入力画面(図７)から少なく
とも出発地と到着地、到着希望時間、申込人数の入力を
行うことにより運行依頼を行う。なお、予約依頼型同
様、顧客用端末３００からサービスセンタ１００に運行
依頼を行なうためには、顧客は事前にサービスセンタ１
００に対して顧客名や住所、パスワードなどの顧客登録
を行い、ユーザＩＤの交付を受けておく必要がある。

【００８７】サービスセンタ１００は、顧客からの運行
依頼を受信すると、データベース２００内の第１の申込
データ２１２内に受信した情報を格納し、受信した運行
依頼に一対一で対応する申込番号の付与を行なった後、
顧客用端末３００に対し、顧客に自己が入力した運行依
頼を確認させるために、図８に示すような申込内容確認
画面を送信する(Ｓ２)。申込内容確認画面(図８)には、
顧客が運行依頼入力画面(図７)において入力した事項が
表示されている。運行依頼を変更する必要を発見した顧
客は、この申込内容確認画面(図８)の「変更」ボタン８ａ
を選択することにより、一旦登録した運行依頼を変更す
ることもできる。

【００８８】乗合車両運行業者は、業者用端末４００か
らサービスセンタ１００内のＷＷＷサーバ１２０に随時
アクセスし、顧客が登録した運行依頼情報の検索を行う
(Ｓ３)。乗合車両運行業者からのアクセスを受け、サー
ビスセンタ１００は業者用端末４００に対し、図２２に
示すような未確定運行依頼一覧を送信する。未確定運行
依頼一覧画面(図２２)には、サービスセンタ１００に登
録されている各運行依頼の申込番号、到着地、到着希望
時間、申込数、申込人数などの情報が掲示されている。
乗合車両運行業者は、未確定運行依頼一覧画面(図２２)
の中に、関心のある運行依頼を発見した場合は、申込番
号表示欄２２ａに表示されている申込番号の中から関心
のある運行依頼を示す申込番号を指定することにより、
その運行依頼についての詳細情報を取得することができ
る。

【００８９】図２３は、申込番号「０３１０」を持つ運行
依頼についての詳細情報を表示した運行依頼詳細表示画
面である。運行依頼詳細表示画面(図２３)には、運行依
頼「００５４」についての、申込番号、顧客名、住所、電
話番号、出発希望時間、到着希望時間、申込人数などの
情報が表示されている。乗合車両運行業者は、運行依頼
についての詳細情報を取得した上で運行依頼に応じよう
とする場合には、乗合車両運行業者が「受注及び運行計
画作成」ボタン２３ａを操作することにより、業者用端
末４００に表示される追加申込依頼受注登録画面(図２
４)から運行計画を入力することによりその運行依頼に
対する受注を行うことができる。

【００９０】なお、乗合車両運行業者がサービスセンタ
１００に運行依頼情報の検索要求を行うと、サービスセ
ンタ１００は業者用端末４００にユーザＩＤとパスワー
ドなどの認証情報の入力を促すので、乗合車両運行業者
は、事前にサービスセンタ１００に登録してある認証情
報の入力を行う。認証情報を受信すると、サービスセン
タ１００のデータベースサーバ１４０は、データベース
２００内の事業者情報データ２０４を検索し、アクセス
してきた乗合車両運行業者に対する認証処理を行う。乗
合車両運行業者が認証された場合に、業者用端末４００
に未確定運行依頼一覧画面(図２２)が送信されることと
なる。したがって、乗合車両運行業者は事前にサービス
センタ１００に対して事業社名、住所、電話番号、パス
ワードなどを登録し、事業者ＩＤの交付を受けるといっ
た事業者登録を行う必要がある。

【００９１】乗合車両運行業者が、運行依頼詳細表示画
面(図２３)の「受注及び運行計画作成」ボタン２３ａを操
作することにより、業者用端末４００には図２４のよう
な追加申込依頼受注登録画面が表示される。追加申込依
頼受注登録画面（図２４）には、運行依頼を行った顧客
についての申込番号、顧客名、住所、電話番号、申込人
数などの情報が表示されている。乗合車両運行業者は、
顧客の住所や目的地などを鑑み、適切なルートの選択を
行い、目的地に間違いなく顧客の到着希望時間に到着す
ることのできる出発予定時間と顧客との待ち合わせ場所
とを選択し、確定グループ番号入力欄２４ａから運行依
頼を追加しようとする運行計画の確定グループ番号（グ
ループＩＤ）を入力する。そして、出発予定日入力欄２
４ｂから出発予定日を、出発予定時間入力欄２４ｃから
出発予定時間を、待ち合わせ場所入力欄２４ｄから待ち
合わせ場所を、料金表示欄２４ｆから運賃をそれぞれ入
力する。乗合車両運行業者は、追加申込依頼受注登録画
面（図２４）の入力内容の確認を行った後、「登録ボタ
ン」２４ｇを押すことにより、サービスセンタ１００に
運行計画を送信し、未確定運行依頼の受注を行う(Ｓ
４)。

【００９２】サービスセンタ１００は、データベース２
００内の第１の確定グループデータ２０２内に業者用端
末４００から運行計画を受信した運行計画を格納し、そ
れに基づき、顧客用端末３００に対して料金及び運行計
画の通知を行う(Ｓ５)。図１２は、顧客用端末３００に
表示された料金及び運行計画通知画面の一例である。料
金及び運行計画通知画面(図１２)には、顧客名と、申込
番号と、その申し込み番号を持つ運行依頼をグルーピン
グ処理したことにより付与されたグループＩＤと、料金
と、乗合車両運行業者の指定した待ち合わせ場所と待ち
合わせ時間とが表示されているので、顧客は表示内容の
確認を行い、「最終確認」ボタン１２ａを操作することに
より、運行確認を行う（Ｓ６)。顧客が運行確認を行う
と、サービスセンタ１００から顧客用端末３００に対
し、図１３に示すような申込確定確認画面が送信される
こととなる。

【００９３】顧客が運行確認を行い、顧客用端末３００
に申込確定確認画面（図１３）の送信が行われると、業
者用端末４００には、図１４に示すような運行グループ
状況確認画面が送信され（Ｓ７）、これによりＳ４にお
いて乗合車両運行業者が送信した運行計画が最終決定さ
れる(Ｓ８)。運行グループ状況確認画面(図１４)には、
今回受注を行なった申込番号「００５４」についての申
込番号、出発地、到着地、到着予定時間、顧客名、顧客
の住所、電話番号、申込人数などのほか、当該乗合車両
運行業者が既に受注している他の運行依頼についての申
込番号、出発地、到着地、到着予定時間、顧客名、顧客
の住所、電話番号、申込人数などの情報も掲示されてい
る。なお、ステータス表示欄１４ａには、各顧客から運
行計画に対する最終確認が行われた段階であることを示
すステータス「ユーザ確認」が表示されている。

【００９４】乗合車両運行業者は、サービスセンタ１０
０から運行グループ状況確認画面(図１４)の業者用端末
４００への送信により最終決定された運行グループに
て、運行計画に基づいて乗合車両の運行を行い（Ｓ
９）、顧客を目的地へと運び、顧客から運賃の支払を受
ける(Ｓ１０)。その後、乗合車両運行業者は、サービス
センタ１００に対し、運行結果の報告を行い、運行依頼
情報を取得したことに対するシステム使用料などの支払
を行う(Ｓ１１)。図１５は、乗合車両運行業者が、サー
ビスセンタ１００に対し、運行結果の報告を行う際に入
力を行う運行結果報告画面の一例を示す図である。

【００９５】次に、リアルタイム依頼型について説明す
る。リアルタイム依頼型は、顧客自らがサービスセンタ
１００に既に決まっている他の運行計画の検索を行い、
個々の運行計画に対する乗車の可否の判断を行い、同乗
したい運行計画に発注を行うという点において、顧客の
運行依頼に基づき運行ルートの組合せを行う予約依頼型
や、事業者の運行ニーズに基づいて運行依頼を組み合わ
せる未確定依頼型と異なるものである。

【００９６】図２５は、リアルタイム依頼型における処
理過程の流れの一例を示す図である。駅や空港へ向かう
必要の生じた顧客は、自己の保有する顧客用端末３００
からサービスセンタ１００にアクセスし、運行依頼を行
う(Ｓ１)。顧客がサービスセンタ１００に運行依頼入力
要求を行うと、サービスセンタ１００は顧客用端末３０
０にユーザＩＤとパスワードなどの認証情報の入力を促
すので、まず顧客は、事前にサービスセンタ１００に登
録してある認証情報の入力を行う。認証情報を受信する
と、サービスセンタ１００のデータベースサーバ１４０
は、データベース２００内のユーザ情報データ２２０を
検索し、アクセスしてきた顧客に対する認証処理を行
う。顧客が認証された場合には、顧客用端末３００に
は、図２６に示すようなリアルタイム運行依頼入力画面
が送信されるので、顧客はこの運行依頼入力画面から必
要事項の入力を行う。

【００９７】リアルタイム運行依頼入力画面(図２６)に
は、図７の運行依頼入力画面同様、乗合車両に乗車する
場所を入力する出発地入力欄２６ａ、目的地を入力する
到着地入力欄２６ｂ、乗車日を入力する出発日入力欄２
６ｃ、出発希望時間入力欄２６ｄ、目的地への到着日を
入力する到着日入力欄２６ｅなどのほか、飛行機などの
出発時間に合わせて目的地に到着したい場合に入力する
到着希望時間２６ｆ、顧客とともに乗合車両へ乗車する
人数を入力する申込人数入力欄２６ｇ、前回利用した際
の印象などから、運行業者を指定したい場合に入力を行
う指定業者入力欄２６ｈ、荷物の過多や、小さい子供の
有無などの連絡時項を入力する要望事項入力欄２６ｉな
どが設けられており、顧客はここから少なくとも出発地
と到着地、到着希望時間、申込人数の入力を行うことに
より運行依頼を行う。なお、予約依頼型同様、顧客用端
末３００からサービスセンタ１００に運行依頼を行なう
ためには、顧客は事前にサービスセンタ１００に対して
顧客名や住所、パスワードなどの顧客登録を行い、ユー
ザＩＤの交付を受けておく必要がある。

【００９８】次に顧客は、リアルタイム運行依頼入力画
面(図２６)にある「確定グループ一覧検索」ボタン２６
ｊを操作することにより、既に運行の決定している他の
運行計画の抽出を行う（Ｓ２）。図２７は、リアルタイ
ム運行依頼入力画面(図２６)にある「確定グループ一覧
検索」ボタン２６ｊを操作した顧客の顧客用端末３００
にサービスセンタ１００から送信された運行決定グルー
プ一覧画面を示す図である。運行決定グループ一覧画面
（図２７）には、既に運行を行うことが決定されている
運行計画のグループ番号、出発地、到着地、到着予定時
間、指定業者、運行決定グループを構成している運行依
頼の申込数、グループの合計人数などが表されている。
顧客は、出発地や到着地、到着予定時間、合計人数など
に鑑み、この運行決定グループ一覧画面（図２７）の中
に、自分の運行依頼の追加を行うことのできそうな運行
決定グループがあるか否かを探す。自分の運行依頼の追
加を行うことのできそうな運行決定グループがあった場
合は、グループ番号表示欄２７ａに表示されているグル
ープ番号の中から自分の運行依頼の追加を行うことので
きそうな運行決定グループを示すグループ番号を指定す
ることにより、追加申込の発注を行う（Ｓ３）。

【００９９】サービスセンタ１００は、顧客用端末３０
０から追加申込の発注を受けると、追加申込のされた既
決定運行グループを運行する乗合車両運行業者の業者用
端末４００に、図２８に示すような追加申込依頼一覧を
送信し、決定運行への顧客追加依頼を行なう（Ｓ４）。

【０１００】追加申込依頼一覧（図２８）には、サービ
スセンタ１００が受信した追加申込依頼についての申込
番号、到着地、出発希望時間、到着希望時間、追加申込
の行われた既決定運行グループのグループ番号、追加申
込のされた人数などが表示されている。乗合車両運行業
者は、既決定運行グループについての運行計画の確認を
行い、追加申込に応じるか否かの判断を行う（Ｓ５）。
追加申込に応じることができるか否か判断するにあた
り、追加申込依頼一覧画面（図２８）の申込番号表示欄
２８ａから、応じることのできそうな追加申込の申し込
み番号を指定することにより、その追加申込についての
詳細情報を取得することができる。

【０１０１】図２９は、申込番号「４５０１」を持つ追加
申込依頼についての詳細情報を表示した追加申込依頼詳
細表示画面である。追加申込依頼詳細表示画面(図２９)
には、申込番号「４５０１」を持つ追加申込についての、
申込番号、顧客名、住所、電話番号、出発希望時間、到
着希望時間、申込人数などの情報が表示されている。乗
合車両運行業者は、これら詳細情報を取得した上で、追
加申込依頼に応じようとする場合には、「受注及び運行
計画作成」ボタン２９ａを操作することにより受注を行
うことができる。

【０１０２】乗合車両運行業者が、「受注及び運行計画
作成」ボタン２９ａを操作すると、業者用端末４００に
は、図３０に示すような追加申込依頼受注登録画面が表
示される。追加申込依頼受注登録画面(図３０)には、追
加申込依頼を行なった顧客についての申込番号、顧客
名、到着地、到着希望時間、申込人数などの情報が表示
されている。乗合車両運行業者は、既に運行を決定して
いる運行計画に鑑み、追加申込依頼を追加するための適
切なルートの選択を行い、目的地に間違いなく顧客の到
着希望時間に到着することのできる出発予定時間と顧客
との待ち合わせ場所とを選択し、出発予定日入力欄３０
ａから出発予定日の、出発予定時間入力欄３０ｂから出
発予定時間の、待ち合わせ場所入力欄３０ｂから待ち合
わせ場所の、料金表示欄３０ｅから運賃の入力を行う。
乗合車両運行業者は、追加申込依頼受注登録画面(図３
０)の入力内容の確認を行った後、「登録ボタン」３０ｆ
を操作することにより、サービスセンタ１００に既決定
運行計画に対する追加申込依頼への受注を送信する(Ｓ
６)。

【０１０３】サービスセンタ１００は、データベース２
００内の第１の確定グループデータ２０２内に業者用端
末４００から運行計画を受信した運行計画を格納し、そ
れに基づき、顧客用端末３００に対して申込内容の確認
と、料金及び運行計画の通知を行うための申込内容確認
画面（図３１）を送信する(Ｓ７)。申込内容確認画面
(図３１)には、顧客名と、申込番号と、出発地、到着
地、到着希望時間、人数、追加申込依頼の追加された既
決定運行グループのグループＩＤ、料金と、乗合車両運
行業者の指定した待ち合わせ場所と待ち合わせ時間とが
表示されているので、顧客は表示内容の確認を行い、
「最終確認」ボタン３１ａを操作することにより、運行確
認を行う（Ｓ８)。

【０１０４】顧客が運行確認を行うと、業者用端末４０
０には、図１４に示すような運行グループ状況確認画面
が送信され（Ｓ９）、これによりＳ７において乗合車両
運行業者が送信した運行計画が最終決定される(Ｓ１
０)。運行グループ状況確認画面(図１４)には、グルー
プ番号、出発地、到着地、到着予定時間、グループを構
成する顧客の申込番号、顧客名、顧客の住所、電話番
号、申込人数、ステータスなどが表示されている。運行
グループ状況確認画面(図１４)のステータス表示欄１４
ａに表示されるステータスは、各顧客の運行依頼が、各
顧客から運行計画に対する最終確認が行われた段階にあ
ることを示すステータス「ユーザ確認」が表示されてい
る。

【０１０５】乗合車両運行業者は、最終決定された運行
計画に基づき、乗合車両の運行を行い（Ｓ１１）、顧客
を目的地へと運び、顧客から運賃の支払を受ける(Ｓ１
２)。その後、乗合車両運行業者は、サービスセンタ１
００に対し、運行結果の報告を行い、運行依頼情報を取
得したことに対するシステム使用料などの支払を行う
(Ｓ１３)。図１５は、乗合車両運行業者が、サービスセ
ンタ１００に対し、運行結果の報告を行う際に入力を行
う運行結果報告画面の一例を示す図である。運行結果報
告画面(図１５)には、乗合車両運行業者がＳ６で送信を
行った追加申込依頼受注登録画面(図３０)における入力
内容が表示されているので、万一実際の運行が運行計画
と異なった場合には、出発時間入力欄１５ａ、待ち合わ
せ場所入力欄１５ｂ、料金入力欄１５ｃ、到着時間入力
欄１５ｇから表示内容の修正を行い、「登録」ボタン１５
ｄを操作することによりサービスセンタ１００に対して
運行結果の報告を行う。

【０１０６】次に、他の実施の形態について説明する。
上述した実施の形態においては、固定場所からの行きか
帰りかでデータベースを分け、顧客用端末３００から入
力された運行依頼が固定場所への行きである場合は第１
の申込データ２１２に、固定場所からの帰りであれば第
２の申込データ２１６２、また固定場所への行きについ
ての運行決定グループに関する情報であれば第１の確定
グループデータ２０２に、固定場所からの帰りについて
の運行決定グループに関する情報であれば第２の確定グ
ループデータ２０６に、それぞれ分けて格納する場合を
一例について説明したが、本発明はこの場合に限定され
るものではなく、他の実施の形態においては、固定場所
への行きか帰りかで格納するデータベースを分けること
なく、１つのデータベースに運行依頼、または運行決定
グループに関する情報を格納することも考えられる。

【０１０７】上述した実施の形態においては、予約依頼
型処理、未確定依頼型処理、リアルタイム依頼型処理の
それぞれを個別に説明したが、本発明はこの場合に限定
されるものではなく、他の実施の形態においては、予約
依頼型処理と未確定依頼型処理とリアルタイム依頼型処
理とを組み合わせて、例えば予約依頼型処理を行った後
に未確定依頼型処理を行ったり、あるいは未確定依頼型
処理を行った後にリアルタイム依頼型処理を行ったり、
予約依頼型処理を行った後にリアルタイム依頼型を行っ
たり、予約依頼型処理、未確定依頼型処理、リアルタイ
ム依頼型処理の順に全ての形態の処理を行うこととして
もよい。

【０１０８】また、上述した実施の形態においては、乗
合グルーピング処理を行う際に参照する隣接地区データ
を設定するにあたり、郵便番号に基づいて隣接地区ラン
クを設定する場合を一例に説明したが、本発明はこの場
合に限定されるものではなく、他の実施の形態において
は、例えば電話番号の局番を用いたり、市販の地図デー
タベースを用いて隣接地区データを設定することも考え
られる。

【０１０９】また、上述した実施の形態においては、運
行グループを作成する際に、対象となる運行依頼の受付
けをある時間で区切り、それら運行依頼の含む時間帯
や、目的地などの基づいて乗合グルーピング処理を行う
場合を一例に説明したが、本発明はこの場合に限定され
るものではない。他の実施の形態においては、運行グル
ープの作成にあたって運行依頼の受けつけ時間を区切る
ことなく、例えば顧客用端末３００から運行依頼を受け
付け次第、その受けつけた運行依頼の含む時間帯や、目
的地などに基づいて、随時運行グループを作成すること
も考えられる。

【０１１０】また、上述の図２１に示した未確定依頼型
の処理においては、乗合車両運行業者が運行依頼を追加
受注する際、どの運行計画に追加して受注するのかをあ
らかじめ特定して受注を行う場合を一例に説明したが、
本発明はこの場合に限定されるものではない。他の実施
の形態においては、運行依頼の追加受注を行う際に、ど
の運行計画に追加して受注するのかを特定することな
く、自由に運行依頼を受注させることも考えられる。そ
の際には、追加申込依頼受注画面（図２４）の確定グル
ープ番号入力欄２４ａから、確定グループ番号を入力す
ることなく空白としたままサービスセンタ１００に運行
計画を送信する、とすることが考えられる。

【０１１１】また、上述の図２５に示すリアルタイム依
頼型処理においては、顧客の運行依頼と全く異なる出発
地、到着地などを持つ運行決定グループの表示も含めて
表示する運行決定グループ一覧画面（図２７）の中か
ら、顧客自らが自己の運行依頼の追加を行うことのでき
そうな運行決定グループを探し出し、追加申込の発注を
行う場合を一例に説明したが、本発明はこの場合に限定
されるものではない。他の実施の形態においては、顧客
用端末３００からの確定グループ一覧検索要求の受信に
応答して、サービスセンタ１００において顧客が図２５
のＳ１において入力した運行依頼に含まれる出発地、到
着地、乗車日などの情報をもとに顧客の運行依頼を追加
することのできそうな運行確定グループの検索を行い、
運行決定グループ一覧画面（図２７）を表示する顧客用
端末３００の表示画面上に表示させ、その中から顧客に
追加申込の発注を行わせることも考えられる。

【０１１２】また、上述した実施の形態においては、顧
客が、顧客用端末３００からサービスセンタ１００にア
クセスする際に、顧客に対しユーザＩＤ、パスワードな
どの認証情報を入力させ、認証処理を行う場合を一例に
説明したが、本発明はこの場合に限定されるものではな
く、他の実施の形態においては、アクセス時ではなく、
運行依頼をサービスセンタ１００に送信する際にユーザ
ＩＤ、パスワードなどの認証情報を入力させ、認証処理
を行うことも考えられる。

【０１１３】以上述べたように、本実施形態によれば、
顧客用端末から入力された運行依頼をサーバが取り纏め
ることにより、乗合車両運行業者は、運行しやすい状態
に纏められた複数の乗客を効率よく獲得できる。また、
本実施形態によれば、顧客は、既に運行の決定している
乗合グループに対して自己の運行依頼を追加できること
により、好きなときに希望する場所から目的地まで希望
する時間に楽に移動することのできる、安価で新しい交
通手段を得ることができる。

【０１１４】

【発明の効果】以上述べたように、請求項１〜７、９、
１２、１４〜１９、２２、２４、２５に記載の発明によ
れば、乗合車両運行業者は、運行しやすい状態に纏めた
複数の乗客を効率よく取得でき、顧客は、好きなとき
に、希望する場所から目的地まで希望する時間に楽に移
動することのできる安価で新しい交通手段を得ることが
できる。

【０１１５】また、請求項１０、２１に記載の発明によ
れば、運行依頼の入力された時間や、利用人数、利用地
域などの関係で運行グループ取り纏めの対象からはずれ
てしまったような運行依頼であっても、既に運行の決定
している乗合グループに吸収することにより乗合車両の
運行対象とすることができる。

【０１１６】また、請求項８、１１、１３、２０、２３
に記載の発明によれば、既に運行の決定している運行グ
ループに対して顧客自身が自己の運行依頼を追加できる
ことにより、顧客は、あらかじめ運行依頼の予約を行っ
ていなくても、希望する場所から目的地まで希望する時
間に楽に移動することのできる、安価で新しい交通手段
を得ることができる。

【図面の簡単な説明】

【図１】本発明の実施される乗合運行支援システムのシ
ステム構成の一例を示す図である。

【図２】本実施例におけるサービスセンタにおけるデー
タベースサーバ及び該データベースの構成の一例を示す
図である。

【図３】データベースの格納する各データベースの構造
の一例を示す図である。

【図４】データベースのデータ格納例を示す図である。

【図５】データベースのデータ格納例を示す図である。

【図６】予約依頼型における処理過程の流れの一例を示
す図である。

【図７】運行依頼入力画面の一例を示す図である。

【図８】申込内容確認画面の一例を示す図である。

【図９】仮確定グループ一覧画面の一例を示す図であ
る。

【図１０】運行グループ詳細表示画面の一例を示す図で
ある。

【図１１】運行計画入力画面の一例を示す図である。

【図１２】料金及び運行計画通知画面の一例を示す図で
ある。

【図１３】申込確定確認画面の一例を示す図である。

【図１４】運行グループ状況確認画面の一例を示す図で
ある。

【図１５】運行結果報告画面の一例を示す図である。

【図１６】乗合グルーピング処理の処理手順の一例を示
すフローチャートである。

【図１７】乗合グルーピング結合処理の処理手順の一例
を示すフローチャートであ

【図１８】仮確定グループ決定処理の処理手順の一例を
示すフローチャートである。

【図１９】乗合グルーピング結合処理の処理手順の一例
を示すフローチャートである。

【図２０】乗合グループ分割処理の処理手順の一例を示
すフローチャートである。

【図２１】未確定依頼型における処理過程の流れの一例
を示す図である。

【図２２】未確定運行依頼一覧の一例を示す図である。

【図２３】運行依頼詳細表示画面の一例を示す図であ
る。

【図２４】追加申込依頼受注登録画面の一例を示す図で
ある。

【図２５】リアルタイム依頼型顧客における処理過程の
流れの一例を示す図である。

【図２６】リアルタイム運行依頼入力画面の一例を示す
図である。

【図２７】運行決定グループ一覧画面の一例を示す図で
ある。

【図２８】追加申込依頼一覧の一例を示す図である。

【図２９】追加申込依頼詳細表示画面の一例を示す図で
ある。

【図３０】追加申込依頼受注登録画面の一例を示す図で
ある。

【図３１】申込内容確認画面の一例を示す図である。

【符号の説明】

１００ サービスセンタ １２０ＷＷＷサーバ １４０ データベースサーバ １４２ 主制御部（ＣＰＵ） １４４ バス １４６ 入力装置 １４８ 表示装置 １５０ 出力装置 １５２ 通信ポート ２００ データベース ２０２ 第１の確定グループデータ ２０４ 事業者情報データ ２０６ 第２の確定グループデータ ２０８ 固定場所データ ２１０ ステータスデータ ２１２ 第１の申込データ ２１４ 所属地区データ ２１６ 第２の申込データ ２１８ 郵便番号データ ２２０ ユーザ情報データ ２２２ 隣接地区データ ３００ 顧客用端末 ４００ 業者用端末 ５００ ネットワーク

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5B049 BB32 CC05 EE05 GG04 GG07 5H180 AA14 BB05 BB15 FF01

Claims (25)

【特許請求の範囲】
1. 【請求項１】 業者用端末及び顧客用端末に対し乗合情
   報を提供するサーバと、該サーバにネットワークを介し
   て接続された前記業者用端末と前記顧客用端末とを備え
   た乗合運行支援システムにおける前記サーバにおいて、 前記顧客用端末から受信した乗合車両に対する運行依頼
   を記憶する第１の記憶手段と、 前記運行依頼を取り纏めて運行グループを生成する運行
   グループ生成手段と、 前記運行グループ生成手段が生成した運行グループを記
   憶する第２の記憶手段と、 前記業者用端末に対し、前記運行グループに対する運行
   を依頼する運行依頼信号を発信する依頼信号発信手段
   と、 前記業者用端末から受信した前記運行グループに対する
   運行計画を記憶する第３の記憶手段と、 前記顧客用端末からの前記運行計画に対する最終確認信
   号の受信に応答して、前記業者用端末に該運行計画に対
   する最終確認通知を発信する確認通知発信手段とを備え
   たことを特徴とするサーバ。
2. 【請求項２】 前記運行グループ生成手段は、 前記運行依頼から処理対象となる運行依頼を抽出する第
   １の抽出手段と、 前記第１の抽出手段の抽出した運行依頼から、最低乗客
   数を満たす運行依頼を抽出して運行グループを生成する
   第１のグルーピング手段とを備えたことを特徴とする請
   求項１に記載のサーバ。
3. 【請求項３】 前記第１の抽出手段は、乗合車両乗車日
   と、到着希望時間または出発希望時間の属する時間帯と
   をキーとして処理対象となる運行依頼を抽出することを
   特徴とする請求項２に記載のサーバ。
4. 【請求項４】 前記第１の抽出手段は、前記顧客用端末
   から受信した運行依頼の含む乗合車両乗車日と、到着希
   望時間または出発希望時間の属する時間帯とをキーとし
   て処理対象となる運行依頼を抽出することを特徴とする
   請求項２に記載のサーバ。
5. 【請求項５】 前記第１のグルーピング手段が運行グル
   ープの生成を行うことのできない場合、前記第１の抽出
   手段の抽出した運行依頼から、同じ固定場所と、所定の
   隣接度合いの出発地または到着地とを持つ隣接運行依頼
   を抽出する第２の抽出手段と、 前記隣接運行依頼を取り纏めて、最低乗客数を満たす運
   行グループを生成する第２のグルーピング手段とを備え
   たことを特徴とする請求項２に記載のサーバ。
6. 【請求項６】 前記隣接度合いは、あらかじめ設定され
   た隣接地区テーブルに基づいて定められることを特徴と
   する請求項５に記載のサーバ。
7. 【請求項７】 前記隣接地区テーブルは、郵便番号に基
   づいて地域を区分けし、該区分けごとに地区相互の隣接
   度合いを定めたものであることを特徴とする請求項６に
   記載のサーバ。
8. 【請求項８】 前記顧客用端末からの前記第２の記憶手
   段の記憶する運行計画への運行依頼の追加発注信号の受
   信に応答して、前記業者用端末に対し、該運行計画への
   追加運行依頼信号を発信する追加依頼信号発信手段を備
   えたことを特徴とする請求項１に記載のサーバ。
9. 【請求項９】 請求項１から８のいずれかに記載のサー
   バからの前記運行グループに対する運行を依頼する運行
   依頼信号の受信に応答して、該運行グループの含む運行
   依頼を出力する第１の出力手段と、 該運行依頼に対する運行計画を入力する第１の入力手段
   と、 該サーバから受信した前記運行計画に対する最終確認通
   知を出力する第２の出力手段と、 前記サーバと前記運行依頼と前記運行計画と前記最終確
   認通知とを含む情報の交信を行う業者端末側入出力手段
   とを備えたことを特徴とする業者用端末。
10. 【請求項１０】 前記サーバの記憶する運行グループを
    検索する検索手段と、 前記検索手段の検索した検索結果を出力する第３の出力
    手段と、 前記検索手段の検索した運行グループの含む運行依頼に
    対する運行計画を入力する第２の入力手段とを備えたこ
    とを特徴とする請求項９に記載の業者用端末。
11. 【請求項１１】 前記サーバからの追加運行依頼信号の
    受信に応答して、該追加発注信号の含む運行依頼を出力
    する第４の出力手段と、 該運行依頼に対する運行計画を入力する第３の入力手段
    とを備えたことを特徴とする請求項９に記載の業者用端
    末。
12. 【請求項１２】 乗合車両の運行依頼を入力する入力手
    段と、 請求項１から８のいずれかに記載のサーバから受信した
    前記運行依頼に対する運行計画を出力する第１の出力手
    段と、 前記サーバに対して前記運行計画に対する最終確認を表
    示する最終確認信号を発信する最終確認信号発信手段
    と、 前記サーバに対して前記運行依頼と前記運行計画とを含
    む情報の交信を行う顧客用端末側入出力手段とを備えた
    ことを特徴とする顧客用端末。
13. 【請求項１３】 前記サーバの記憶する運行グループに
    対する運行計画を検索する検索手段と、 前記検索手段の検索した運行計画に対し運行依頼の追加
    発注を指示する追加発注信号を発信する追加発注信号発
    信手段と、 前記サーバから受信した前記追加発注への運行計画を出
    力する第２の出力手段とを備えたことを特徴とする請求
    項１２に記載の顧客用端末。
14. 【請求項１４】 請求項１から８のいずれかに記載のサ
    ーバにおいて、 前記顧客用端末から受信した乗合車両に対する運行依頼
    を記憶するとともに、該運行依頼を取り纏めて運行グル
    ープを生成するステップと、 前記運行グループを記憶するとともに、前記業者用端末
    に対し、前記運行グループに対する運行を依頼する運行
    依頼信号を発信するステップと、 前記業者用端末から受信した前記運行グループに対する
    運行計画を記憶するステップと、 前記運行計画を前記顧客用端末に送信するステップと、 前記顧客用端末からの前記運行計画に対する最終確認信
    号の受信に応答して前記業者用端末に最終確認通知を送
    信するステップとを実現させることを特徴とするプログ
    ラム。
15. 【請求項１５】 前記運行グループを生成するステップ
    は、 前記運行依頼から処理対象となる運行依頼を抽出するス
    テップと、 前記第１の抽出手段の抽出した運行依頼から、最低乗客
    数を満たす運行依頼を抽出して運行グループを生成する
    ステップとを備えたことを特徴とする請求項１４に記載
    のプログラム。
16. 【請求項１６】 前記運行依頼から処理対象となる運行
    依頼を抽出するステップは、乗合車両乗車日と、到着希
    望時間または出発希望時間の属する時間帯とをキーとし
    て処理対象となる運行依頼を抽出することを特徴とする
    請求項１５に記載のプログラム。
17. 【請求項１７】 前記運行依頼から処理対象となる運行
    依頼を抽出するステップは、前記顧客用端末から受信し
    た運行依頼の含む乗合車両乗車日と、到着希望時間また
    は出発希望時間の属する時間帯とをキーとして処理対象
    となる運行依頼を抽出することを特徴とする請求項１５
    に記載のプログラム。
18. 【請求項１８】 前記最低乗客数を満たす運行依頼を抽
    出して運行グループを生成するステップにおいて、運行
    グループの生成を行うことのできない場合、前記抽出さ
    れた運行依頼から、同じ固定場所と、所定の隣接度合い
    の出発地または到着地とを持つ隣接運行依頼を抽出する
    ステップと、 前記隣接運行依頼を取り纏めて、最低乗客数を満たす運
    行グループを生成するステップとを備えたことを特徴と
    する請求項１５に記載のプログラム。
19. 【請求項１９】 請求項９から１１のいずれかに記載の
    業者用端末において、 請求項１から８のいずれかに記載のサーバからの前記運
    行グループに対する運行を依頼する運行依頼信号の受信
    に応答して、該運行グループの含む運行依頼を出力する
    ステップと、 該運行依頼に対する運行計画の入力に応答して、前記業
    者端末側入出力手段を制御して前記サーバに該運行計画
    を送信するステップと、 前記サーバから受信した前記運行計画に対する最終確認
    通知を出力するステップとを実現させることを特徴とす
    るプログラム。
20. 【請求項２０】 前記サーバからの追加運行依頼信号の
    受信に応答して、該追加発注信号の含む運行依頼を出力
    するステップと、 該運行依頼に対する運行計画の入力に応答して、前記業
    者端末側入出力手段を制御して前記サーバに該運行計画
    を送信するステップとを備えたことを特徴とする請求項
    １９に記載のプログラム。
21. 【請求項２１】 請求項１０に記載の業者用端末におい
    て、 請求項１から８のいずれかに記載のサーバの記憶する運
    行グループを検索し、検索結果を出力するステップと、 前記検索結果に対する運行計画の入力に応答して前記サ
    ーバに該運行計画を送信するステップと、 前記サーバから受信した前記運行計画に対する最終確認
    通知を出力するステップとを実現させることを特徴とす
    るプログラム。
22. 【請求項２２】 請求項１２または１３に記載の顧客用
    端末において、 乗合車両の運行依頼の入力に応答して、請求項１から８
    のいずれかに記載のサーバに該運行依頼を送信するステ
    ップと、 前記サーバから受信した前記運行依頼に対する運行計画
    を出力するステップと、 前記サーバから受信した前記運行計画に対する最終確認
    信号を前記サーバに対して発信するステップとを実現さ
    せることを特徴とするプログラム。
23. 【請求項２３】 請求項１３に記載の顧客用端末におい
    て、 前記サーバの記憶する運行グループに対する運行計画を
    検索するステップと、 前記検索手段の検索した運行計画に対し運行依頼の追加
    発注を指示する追加発注信号を発信するステップと、 前記サーバから受信した前記追加発注に対する運行計画
    を出力するステップと、 前記運行計画に対する最終確認信号を発信するステップ
    とを実現させることを特徴とするプログラム。
24. 【請求項２４】 請求項１４から２３のいずれかに記載
    のプログラムを格納することを特徴とするコンピュータ
    読取可能な記録媒体。
25. 【請求項２５】 請求項１から８のいずれかに記載のサ
    ーバと、該サーバにネットワークを介して接続された請
    求項９から１１のいずれかに記載の前記業者用端末と請
    求項１２または１３に記載の前記顧客用端末とを備えた
    乗合運行支援システムを用いて乗合運行の支援を行う方
    法であって、 前記顧客用端末において、乗合車両への運行依頼を入力
    し、前記サーバに送信するステップと、 前記サーバにおいて、前記顧客用端末から受信した前記
    運行依頼を取り纏めて運行グループを生成するステップ
    と、 前記サーバにおいて、前記運行グループを記憶するとと
    もに、前記業者用端末に対し、前記運行グループに対す
    る運行を依頼する運行依頼信号を発信するステップと、 前記業者用端末において、前記サーバからの前記運行グ
    ループに対する運行を依頼する運行依頼信号の受信に応
    答して、該運行グループの含む運行依頼を出力するステ
    ップと、 前記業者用端末において、該運行グループに対する運行
    計画の入力に応答して、前記第１の業者端末側入出力手
    段を制御して前記サーバに該運行計画を送信するステッ
    プと、 前記サーバにおいて、前記業者用端末から受信した前記
    運行計画を記憶し、前記顧客用端末に送信するステップ
    と、 前記顧客用端末において、前記サーバから受信した前記
    運行計画に対する最終確認信号を前記サーバに対して発
    信するステップと、 前記サーバにおいて、前記顧客用端末からの前記運行計
    画に対する最終確認信号の受信に応答して前記業者用端
    末に最終確認通知を送信するステップと、 前記業者用端末において、前記サーバから受信した前記
    運行計画に対する最終確認通知を出力するステップとを
    備えたことを特徴とする乗合運行支援方法。