特開 2024-165481 運行スケジュール作成方法及び運行スケジュール作成プログラム

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

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

(11)【公開番号】P2024165481

(43)【公開日】2024-11-28

(54)【発明の名称】運行スケジュール作成方法及び運行スケジュール作成プログラム

(51)【国際特許分類】

   G08G 1/123 20060101AFI20241121BHJP

   G06Q 50/40 20240101ALI20241121BHJP

【ＦＩ】

G08G1/123 A

G06Q50/30

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2023081722

(22)【出願日】2023-05-17

(71)【出願人】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100087480

【弁理士】

【氏名又は名称】片山 修平

(72)【発明者】

【氏名】大西 隆史

(72)【発明者】

【氏名】金政 泰彦

(72)【発明者】

【氏名】ミヒャエリス ユリウス

(72)【発明者】

【氏名】青木 啓晃

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

5H181

5L049

5L050

【Ｆターム（参考）】

5H181AA06

5H181BB13

5H181FF01

5H181FF03

5H181FF17

5H181MA23

5H181MA25

5H181MA26

5H181MA28

5H181MA48

5L049CC42

5L050CC42

(57)【要約】

【課題】患者を車両で病院に送り届ける運行スケジュールを新たな患者のリクエストに応じて適切に変更する。
【解決手段】運行スケジュール作成部は、１又は複数の第１の患者が診察開始時刻に間に合うように、第１の患者を車両で病院に送り届ける際の運行スケジュールを作成する。また、運行スケジュール作成部は、新たな第２の患者からリクエストを受信すると、第１、第２の患者を車両で病院に送り届けるように、作成した運行スケジュールを修正する。そして、判定部は、修正した運行スケジュールにおいて第１の患者が受診できる時刻が、第１の患者の診察開始時刻の前、又は、第１の患者の診察開始時刻の後であるが、第１の患者の許容時間を超えない時間内であれば、修正した運行スケジュールを第１、第２の患者を送り届ける際の運行スケジュールと決定する。
【選択図】図１５

【特許請求の範囲】

【請求項1】

１又は複数の第１の患者が診察開始時刻に間に合うように、前記第１の患者を車両で病院に送り届ける際の運行スケジュールを作成し、
新たな第２の患者からリクエストを受信すると、前記第１の患者と前記第２の患者とを車両で病院に送り届けるように、作成した前記運行スケジュールを修正し、
修正した前記運行スケジュールにおいて前記第１の患者が受診できる時刻が、前記第１の患者の診察開始時刻の前、又は、前記第１の患者の診察開始時刻の後であるが、前記第１の患者の許容時間を超えない時間内であれば、修正した前記運行スケジュールを前記第１の患者と前記第２の患者を車両で病院に送り届ける際の運行スケジュールと決定する、
処理をコンピュータが実行することを特徴とする運行スケジュール作成方法。

【請求項2】

前記修正する処理において修正する前記運行スケジュールは、既に車両が運行を開始している運行スケジュールである、ことを特徴とする請求項１に記載の運行スケジュール作成方法。

【請求項3】

前記許容時間は、前記第１の患者が診察を受ける病院又は診療科ごとに定められている、ことを特徴とする請求項１又は２に記載の運行スケジュール作成方法。

【請求項4】

前記許容時間は、前記第１の患者ごとに定められている、ことを特徴とする請求項１又は２に記載の運行スケジュール作成方法。

【請求項5】

前記運行スケジュールを作成する処理において、患者の許容時間を参照して、前記許容時間が所定範囲に含まれる複数の患者を前記第１の患者とする、ことを特徴とする請求項１又は２に記載の運行スケジュール作成方法。

【請求項6】

１又は複数の第１の患者が診察開始時刻に間に合うように、前記第１の患者を車両で病院に送り届ける際の運行スケジュールを作成し、
新たな第２の患者からリクエストを受信すると、前記第１の患者と前記第２の患者とを車両で病院に送り届けるように、作成した前記運行スケジュールを修正し、
修正した前記運行スケジュールにおいて前記第１の患者が受診できる時刻が、前記第１の患者の診察開始時刻の前、又は、前記第１の患者の診察開始時刻の後であるが、前記第１の患者の許容時間を超えない時間内であれば、修正した前記運行スケジュールを前記第１の患者と前記第２の患者を車両で病院に送り届ける際の運行スケジュールと決定する、
処理をコンピュータに実行させることを特徴とする運行スケジュール作成プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、運行スケジュール作成方法及び運行スケジュール作成プログラムに関する。

【背景技術】

【0002】

従来、予め設定された路線を、予め計画された時間通りに運行する路線バス（定時定路線バス）が利用されている。しかしながら、このような定時定路線バスにあっては、高齢化、人口の減少、自家用車の普及により利用者が減少しているケースがあり、廃止されている地域もある。そこで、近年、定時定路線バスに代えてデマンド型の交通手段（以下「デマンド型交通」）の導入を行う地域や団体が増加している。デマンド型交通には、運行方式、運行ダイヤ、出発地及び到着地、運行地域における他の交通手段の状況、及び道路事情等に応じて各種の運行形態がある。例えば、過疎化や高齢化が深刻な地域では、病院に送迎する交通手段としてデマンド型交通（オンデマンド送迎バス）が導入され、医療へのアクセシビリティの向上が図られている。

【0003】

このようなデマンド型交通において、車両が乗客を輸送する途中に他の乗客からの乗車要求があった場合に、乗客がサービス時間に遅れずに目的地に到着できるように柔軟に車両のルートを変更する方法が知られている（例えば特許文献１等参照）。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】米国特許出願公開第２０１３／００７３３２７号明細書

【特許文献2】米国特許出願公開第２０２２／０１９８４０２号明細書

【発明の概要】

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

【0005】

しかしながら、車両が運行を開始した後に他の乗客から乗車要求があったとしても、乗客全員がサービス時間に遅れずに目的地に到着できるようにルートを変更するのが難しいことが多い。サービス時間ぎりぎりに目的地に到達するような乗客が車両に既に乗っている、あるいは乗ることが予定されている場合があるからである。

【0006】

１つの側面では、本発明は、患者を車両で病院に送り届ける運行スケジュールを新たな患者のリクエストに応じて適切に変更することが可能な運行スケジュール作成方法及び運行スケジュール作成プログラムを提供することを目的とする。

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

【0007】

一つの態様では、運行スケジュール作成方法は、１又は複数の第１の患者が診察開始時刻に間に合うように、前記第１の患者を車両で病院に送り届ける際の運行スケジュールを作成し、新たな第２の患者からリクエストを受信すると、前記第１の患者と前記第２の患者とを車両で病院に送り届けるように、作成した前記運行スケジュールを修正し、修正した前記運行スケジュールにおいて前記第１の患者が受診できる時刻が、前記第１の患者の診察開始時刻の前、又は、前記第１の患者の診察開始時刻の後であるが、前記第１の患者の許容時間を超えない時間内であれば、修正した前記運行スケジュールを前記第１の患者と前記第２の患者を車両で病院に送り届ける際の運行スケジュールと決定する、処理をコンピュータが実行する運行スケジュール作成方法である。

【発明の効果】

【0008】

患者を車両で病院に送り届ける運行スケジュールを新たな患者のリクエストに応じて適切に変更することができる。

【図面の簡単な説明】

【0009】

【図1】図１（ａ）、図１（ｂ）は、第１の実施形態に係るオンデマンドバス管理システムの処理の概要を説明するための図（その１）である。

【図2】第１の実施形態に係るオンデマンドバス管理システムの処理の概要を説明するための図（その２）である。

【図3】第１の実施形態に係るオンデマンドバス管理システムの構成の一例を示す図である。

【図4】図４（ａ）は、バス管制サーバ及び診察予約管理サーバのハードウェア構成の一例を示す図であり、図４（ｂ）は、バス端末及び端末のハードウェア構成の一例を示す図である。

【図5】バス管制サーバ及び診察予約管理サーバの機能ブロック図である。

【図6】図６（ａ）は、リクエストテーブルの一例を示す図であり、図６（ｂ）は、運行スケジュールテーブルの一例を示す図であり、図６（ｃ）は、バス情報テーブルの一例を示す図である。

【図7】図７（ａ）は、許容時間テーブルの一例を示す図であり、図７（ｂ）は、予約情報テーブルの一例を示す図である。

【図8】バス管制サーバの一連の処理を示すフローチャートである。

【図9】図８のステップＳ１０の運行スケジュール作成処理の詳細を示すフローチャートである。

【図10】図８のステップＳ１４のバス運行処理の詳細を示すフローチャートである。

【図11】図１１（ａ）は、図１０のステップＳ１４６の運行スケジュール変更通知処理の詳細を示すフローチャートであり、図１１（ｂ）は、図１０のステップＳ１５０のバス発進処理の詳細を示すフローチャートである。

【図12】図８のステップＳ２４の運行スケジュール更新処理の詳細を示すフローチャートである。

【図13】図１２のステップＳ２４６の運行スケジュール再作成処理の詳細を示すフローチャートである。

【図14】図１２のステップＳ２４８の運行中のバスの利用可否判定処理の詳細を示すフローチャートである。

【図15】図１４のステップＳ２４８８の処理の概要を示す図である。

【図16】診察予約管理サーバの処理を示すフローチャートである。

【図17】図１６のステップＳ３４の診察予約受付処理の詳細を示すフローチャートである。

【図18】第２の実施形態において用いる許容時間テーブルの一例を示す図である。

【図19】第２の実施形態における、運行中のバスの利用可否判定処理（Ｓ２４８）の詳細を示すフローチャートである。

【図20】図２０（ａ）は、第２の実施形態の変形例において用いる許容時間リストの一例を示す図であり、図２０（ｂ）は、第２の実施形態の変形例において作成される許容時間テーブルの一例を示す図である。

【図21】第３の実施形態を説明するための図である。

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

【0010】

《第１の実施形態》
以下、オンデマンドバス管理システムの第１の実施形態について説明する。

【0011】

図１（ａ）～図２は、本第１の実施形態に係るオンデマンドバス管理システムの処理の概要を説明するための図である。図１（ａ）は、オンデマンドバスを運行している病院において診察を予約し、送迎をリクエストした患者の診察予約状況を示す図である。図１（ａ）に示すように、患者Ａは、９時から内科の診察を予約しており、患者Ｂは、９時から外科の診察を予約しており、患者Ｃは、９時からリハビリ科の診察を予約しているものとする。そして、オンデマンドバス管理システムは、例えば当日の朝等において、患者Ａ、Ｂ、Ｃを各患者の自宅から病院まで送り届けるバスの運行スケジュール（運行ダイヤ）を作成したとする。

【0012】

図１（ｂ）には、運行スケジュールの一例が示されている。図１（ｂ）の運行スケジュールは、リクエストに対して最適なルーティング・ダイヤを算出するＶＲＰ（配送計画問題）を解くことにより決定される。図１（ｂ）の例では、バスは病院を出発して、患者Ａの自宅→患者Ｂの自宅→患者Ｃの自宅と経由し、病院まで患者Ａ，Ｂ，Ｃを送り届けるようになっている。本実施形態においては、送迎をリクエストした全ての患者が診察予約の時刻に間に合うようにバスの運行スケジュールを決定している。

【0013】

ところで、バスが運行スケジュールに沿って運行を開始した後に、突発的に新たな患者から送迎のリクエストが入ってくる場合がある。例えば、図１（ｂ）のような運行スケジュールでバスが運行している状況で、新たな患者Ｓが送迎のリクエストを行ったとする。この場合、運行中のバスで患者Ｓを病院まで送り届けることができれば効率が良く、患者Ｓの待ち時間を減らすことができる。そこで、本実施形態では、図２に示すように、患者Ａ、Ｂ、Ｃに患者Ｓを加えて改めてＶＲＰを解くことで、運行スケジュール（仮運行スケジュール）を作成する。そして、仮運行スケジュールを採用しても問題ないかを判定し、問題が無ければ、仮運行スケジュールを新たな運行スケジュールとして採用する。なお、新たな運行スケジュールが問題ないかどうかを判定する方法の詳細については、後述する。

【0014】

以下、本第１の実施形態のオンデマンドバス管理システム１００について、図３～図１７に基づいて詳細に説明する。

【0015】

図３には、第１の実施形態に係るオンデマンドバス管理システム１００の構成の一例が概略的に示されている。オンデマンドバス管理システム１００は、図３に示すように、バス管制サーバ１０、診察予約管理サーバ２０、バス端末６０、端末７０等を備える。バス管制サーバ１０、診察予約管理サーバ２０、バス端末６０、端末７０は、インターネットやＶＰＮ（Virtual Private Network）などのネットワーク８０に接続されている。

【0016】

バス管制サーバ１０は、病院が運行するオンデマンド送迎バスに関する種々情報を管理して日々の運行スケジュールを作成し、バスが適切に運行されるように管理する情報処理装置である。

【0017】

図４（ａ）には、バス管制サーバ１０のハードウェア構成の一例が示されている。図４（ａ）に示すように、バス管制サーバ１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、ストレージ（ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これらバス管制サーバ１０の構成各部は、伝送用のバス９８に接続されている。バス管制サーバ１０では、ＲＯＭ９２あるいはストレージ９６に格納されているプログラム（運行スケジュール作成プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラムをＣＰＵ９０が実行することにより、図５に示す各部の機能が実現される。なお、図５のバス管制サーバ１０の各部の機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。なお、図５の各部の詳細については後述する。

【0018】

診察予約管理サーバ２０は、病院の各診療科における診察予約の情報を管理する情報処理装置である。診察予約管理サーバ２０のハードウェア構成は、バス管制サーバ１０と同様である（図４（ａ）参照）。診察予約管理サーバ２０では、ＣＰＵ９０がプログラムを実行することにより、図５に示す予約受付部２１の機能が実現される。なお、図５の予約受付部２１の機能は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現されてもよい。予約受付部２１は、病院の受付担当者等が利用する端末７０から入力された予約情報を取得し、予約情報テーブル４２に格納して管理する。なお、診察予約管理サーバ２０が有する予約情報テーブル４２や許容時間テーブル４１の詳細については後述する。

【0019】

バス端末６０は、バスに搭載された端末又はバスの乗務員が保持する端末であり、バスの運行スケジュールの情報をバス管制サーバ１０から受信して表示する機能を有する。また、バス端末６０は、走行中のバスの位置情報をバス管制サーバ１０に送信する。

【0020】

図４（ｂ）には、バス端末６０のハードウェア構成の一例が示されている。図４（ｂ）に示すように、バス端末６０は、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、ストレージ１９６、ネットワークインタフェース１９７、表示部１９３、入力部１９５、及び可搬型記憶媒体用ドライブ１９９等を備えている。これらバス端末６０の構成各部は、伝送用のバス１９８に接続されている。

【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】

（第２処理について）
図８の第２処理においては、まず、ステップＳ２２において、リクエスト受信部１１は、新規リクエストを受信するまで待機する。病院の受付担当者が利用する端末７０や患者が利用する端末７０から、新規のバス送迎のリクエスト（乗車要求）を受け付けると、ステップＳ２４に移行する。なお、リクエスト受信部１１は、受信したリクエストの内容を、リクエストテーブル３２に格納する。

【0054】

ステップＳ２４に移行すると、運行スケジュール更新処理が実行される。この運行スケジュール更新処理（Ｓ２４）は、図１２のフローチャートに沿って実行される。

【0055】

図１２の処理が開始されると、まずステップＳ２４２において、運行スケジュール作成部１２は、新規のリクエストをリクエストテーブル３２から取得する。次いで、ステップＳ２４４に移行すると、運行スケジュール作成部１２は、新規のリクエストを、現在運行中の運行スケジュールに組み込む必要があるのかを判定する。例えば、新規リクエストが翌日の診察予約に対応するリクエストであった場合や、数時間後の診察予約に対応するリクエストであった場合には、このステップＳ２４４の判断は否定される。ステップＳ２４４の判断が否定された場合には、運行スケジュール作成部１２は、ステップＳ２４６に移行し、運行スケジュール再作成処理を実行する。

【0056】

ステップＳ２４６においては、運行スケジュール作成部１２は、図１３のフローチャートに沿った処理を実行する。具体的には、図１３の処理において、運行スケジュール作成部１２は、ステップＳ２４６２において、新規リクエストが当日の送迎を希望するリクエストか否かを判断する。このステップＳ２４６２の判断が否定された場合（翌日以降の送迎を希望するリクエストであった場合）には、運行スケジュール作成部１２は、そのリクエストについての処理を行わずに、図１３の全処理を終了する。

【0057】

一方、ステップＳ２４６２の判断が肯定された場合（当日の送迎を希望するリクエストであった場合）には、運行スケジュール作成部１２は、ステップＳ２４６４に移行し、リクエストテーブル３２から、当日の未運行の運行スケジュールに対応するリクエストを全て取得する。すなわち、リクエストテーブル３２に格納されている予約日時が当日であり、運行中の運行スケジュールに対応するリクエスト以外のリクエストを全て取得する。なお、運行中の運行スケジュールに対応するリクエストであるか否かは、運行スケジュールテーブル３１の「状態」が「バス走行中」である運行スケジュールで送迎対象となっている患者のリクエストであるか否かにより判断することができる。

【0058】

次いで、ステップＳ２４６６において、運行スケジュール作成部１２は、取得したリクエストと新規リクエストを用いて運行スケジュールを再作成する。この運行スケジュールの再作成処理は、図９のステップＳ１０４と同様の処理である。次いで、運行スケジュール作成部１２は、ステップＳ２４６８において、運行スケジュールテーブル３１に格納されている当日の未運行の運行スケジュールを削除し、再作成した運行スケジュールを保存する。

【0059】

次いで、ステップＳ２４７０において、運行スケジュール作成部１２は、新たに保存した運行スケジュールをバス端末６０及び患者の端末７０に通知する。このようにバス端末６０に新たな運行スケジュールが通知されることで、バスが新たな運行スケジュールに従って運行できるようになる。また、患者の端末７０にも新たな運行スケジュールが通知されるため、患者はバスが迎えに来る時刻を正確に把握することができる。

【0060】

以上のようにステップＳ２４７０までの処理が行われると、図１３の全処理を終了するとともに、図１２の全処理を終了する。

【0061】

一方、ステップＳ２４４の判断が肯定された場合、すなわち、新規のリクエストが突発的なリクエストである場合（図６（ａ）の「予約日時」が「突発」の場合）には、ステップＳ２４８に移行する。ステップＳ２４８においては、運行中のバスの利用可否判定処理が実行される。具体的には、図１４の処理が実行される。

【0062】

図１４の処理が開始されると、まず、ステップＳ２４８１において、運行スケジュール作成部１２は、現在運行中のバスの運行スケジュール（「状態」が「バス走行中」の運行スケジュール）を運行スケジュールテーブル３１から取得する。

【0063】

次いで、ステップＳ２４８２において、運行スケジュール作成部１２は、取得した運行スケジュールに対応するリクエストをリクエストテーブル３２から取得する。すなわち、運行スケジュール作成部１２は、取得した運行スケジュールで送迎対象となっている患者のリクエストを取得する。

【0064】

次いで、ステップＳ２４８３において、運行スケジュール作成部１２は、取得したリクエストと新規リクエストを用いて仮運行スケジュールを作成する（運行スケジュールを修正する）。この仮運行スケジュールの作成処理は、図９のステップＳ１０４、図１３のステップＳ２４６６と同様の処理である。ただし、運行スケジュール作成部１２は、現在運行中の運行スケジュールのうち、未走行の部分のみを修正して、仮運行スケジュールを作成する。なお、運行スケジュールのうち未走行の部分については、バス端末６０から取得可能なバスの位置情報から特定することができる。運行スケジュール作成部１２は、作成した仮運行スケジュールを判定部１３に送信する。

【0065】

次いで、ステップＳ２４８４において、判定部１３は、予約情報テーブル４２（図７（ｂ））から、ステップＳ２４８２において取得したリクエストに対応する患者全員の予約時刻を取得する。

【0066】

次いで、ステップＳ２４８５において、判定部１３は、許容時間テーブル４１（図７（ａ））から、各診療科の許容時間を取得する。

【0067】

次いで、ステップＳ２４８６において、判定部１３は、仮運行スケジュールの病院到着時刻と、元の運行スケジュールの病院到着時刻から、病院到着時刻の遅れを算出する。例えば、図６（ｂ）のスケジュールＩＤ＝Ｓ００１（病院到着時刻＝１２：５０）の例において、仮運行スケジュールの病院到着時刻が１３：００であった場合には、遅れは１０分と算出される。

【0068】

次いで、ステップＳ２４８７において、判定部１３は、算出した遅れから、各患者の診察開始可能時刻を算出する。例えば、図６（ｂ）のスケジュールＩＤ＝Ｓ００１（診察開始可能時刻＝１２：５５）の例において、遅れが１０分であった場合には、各患者の診察開始可能時刻は１３：０５と算出される。

【0069】

次いで、ステップＳ２４８８において、判定部１３は、各患者の診察開始可能時刻と、各患者の診察予約時刻との差を算出する。図１５は、ステップＳ２４８８の処理の概要を示す図である。例えば、図１５の上図に示すように、診察開始可能時刻が１３：０５であり、患者Ａの診察予約時刻が１３：００であった場合には、差は＋５分と算出される。また、患者Ｂ、Ｅの診察予約時刻が１２：５５であった場合には、差は＋１０分と算出される。また、患者Ｃの診察予約時刻が１３：１０であった場合には、差は－５分と算出される。更に、患者Ｄの診察予約時刻が１３：０５であった場合には、差は０分と算出される。

【0070】

次いで、ステップＳ２４８９において、判定部１３は、診療科ごとに算出した差の最大値を特定し、各診療科の許容時間と比較する。例えば、内科の患者について算出した差が、図１５の上図に示すように、＋５分、＋１０分、－５分であったとすると、これらの差の最大値は＋１０分となる。また、例えば、外科の患者について算出した差が、０分、＋１０分であったとすると、これらの差の最大値は＋１０分となる。

【0071】

次いで、ステップＳ２４９０において、判定部１３は、全診療科において差の最大値が許容時間以下であるかを判断する（図１５の「比較」参照）。このステップＳ２４９０の判断が否定された場合、すなわち、少なくとも１つの診療科の差の最大値が許容時間を超えている場合には、ステップＳ２４９１に移行する。ステップＳ２４９１に移行した場合、判定部１３は、新規のリクエストを行った患者は、運行中のバスを利用不可能であると判定する。判定部１３は、この判定結果を運行スケジュール作成部１２に通知する。その後は、図１４の全処理を終了し、図１２のステップＳ２５０に移行する。

【0072】

一方、ステップＳ２４９０の判断が肯定された場合、例えば、図１５に示すように全ての診療科の差の最大値が許容時間以下であった場合には、ステップＳ２４９２に移行する。ステップＳ２４９２に移行すると、判定部１３は、新規のリクエストを行った患者が、運行中のバスを利用可能であると判定する。判定部１３は、この判定結果を運行スケジュール作成部１２に通知する。その後は、図１４の全処理を終了し、図１２のステップＳ２５０に移行する。

【0073】

図１２のステップＳ２５０に移行すると、運行スケジュール作成部１２は、新規のリクエストを行った患者が、運行中のバスを利用可能であるか否かを判断する。このステップＳ２５０の判断が否定された場合には、ステップＳ２４６に移行し、前述したように、未運行の運行スケジュールに対応するリクエストに新規リクエスト追加して、運行スケジュールを再作成する処理を実行する。これに対し、ステップＳ２５０の判断が肯定された場合には、ステップＳ２５２に移行し、運行スケジュール作成部１２は、運行スケジュールテーブル３１において、現在運行中の運行スケジュールを仮運行スケジュール（修正後の運行スケジュール）で上書きする。すなわち、本実施形態では、仮運行スケジュールが、全ての患者が診察開始時刻に間に合う、又は遅れたとしても許容時間以内になるようなスケジュールであれば、元の運行スケジュールを仮運行スケジュールで置き換えることとしている。

【0074】

次いで、ステップＳ２５４において、運行スケジュール作成部１２は、上書きした運行スケジュールの内容を運行中のバスのバス端末６０に通知する。これにより、バスは、元々運行スケジュールに含まれていた患者と、新規のリクエストを行った患者を迎えに行くことができる。なお、ステップＳ２５４においては、上書き後の運行スケジュールに含まれる患者の端末７０に対して、上書き後の運行スケジュールを通知してもよい。

【0075】

以上により、図１２の全処理（ステップＳ２４の全処理）が終了すると、図８のステップＳ２６に移行する。ステップＳ２６に移行すると、図８の処理が終了となったか否かを判断する。このステップＳ２６の判断が否定された場合には、ステップＳ２２に戻り、その後は、ステップＳ２６の判断が肯定されるまで、ステップＳ２２、Ｓ２４、Ｓ２６の処理・判断が繰り返し実行されるようになっている。

【0076】

そして、ステップＳ１６及びステップＳ２６の判断が肯定されると、図８の全処理が終了する。

【0077】

（診察予約管理サーバ２０の処理について）
次に、診察予約管理サーバ２０の処理について、図１６、図１７のフローチャートに沿って、その他図面を適宜参照しつつ詳細に説明する。

【0078】

図１６の処理は、病院の１日の業務が開始されたタイミングで開始される。図１６の処理が開始されると、まず、ステップＳ３２において、予約受付部２１が、病院の受付担当者が利用する端末７０から新規診察の予約を受信するまで待機する。予約受付部２１は、新規診察の予約を受信すると、ステップＳ３４に移行し、診察予約受付処理を実行する。

【0079】

図１７には、ステップＳ３４の診察予約受付処理がフローチャートにて示されている。図１７の処理が開始されると、まず、ステップＳ３４２において、予約受付部２１が、新規診察予約の情報を取得する。次いで、ステップＳ３４４において、予約受付部２１は、取得した新規診察予約の情報を予約情報テーブル４２に格納する。これらの処理が行われた後は、図１６のステップＳ３６に移行する。

【0080】

図１６のステップＳ３６に移行すると、病院の業務が終了したか否かを判断する。このステップＳ３６の判断が否定された場合には、ステップＳ３２に戻り、ステップＳ３６の判断が肯定されるまで、ステップＳ３２、Ｓ３４、Ｓ３６の処理・判断を繰り返す。一方、ステップＳ３６の判断が肯定されると、図１６の全処理が終了する。

【0081】

なお、本第１の実施形態では、運行スケジュール作成部１２が作成した運行スケジュールの送迎対象の患者が第１の患者に対応し、突発的なリクエストを行った患者が第２の患者に対応する。

【0082】

以上、詳細に説明したように、本第１の実施形態によると、運行スケジュール作成部１２は、患者それぞれが診察開始時刻に間に合うように、各患者をバスで病院に送り届ける際の運行スケジュールを作成する（図８のＳ１０、図９のＳ１０４）。また、運行スケジュール作成部１２は、新たな患者から新規リクエストを受信すると、新たな患者を追加して、作成した運行スケジュールを修正する（仮運行スケジュールを作成する）（図１４のＳ２４８３）。そして、判定部１３は、仮運行スケジュールにおいて全患者の診察開始可能時刻が、各患者の診察開始時刻の前、又は、各患者の診察開始時刻の後であるが許容時間を超えない時間内であれば、作成した運行スケジュールを仮運行スケジュールで上書きし、利用する（図１２のＳ２５２）。このように、本第１の実施形態では、仮運行スケジュールが全患者の受診を可能にする適切な運行スケジュールである場合に、仮運行スケジュールを利用することとしている。これにより、新規リクエストを行った患者を効率よく病院に送り届けることが可能であり、患者の待ち時間を削減することができる。また、バスで病院に送迎される各患者の予約時刻を変更しなくてもよいため、診察予約管理サーバ２０の処理量を低減することができる。なお、運行スケジュールが仮運行スケジュールで更新された場合には、その旨を病院内の端末７０に通知することとしてもよい。これにより、各診療科は、患者が予約時刻に間に合わない可能性があることを事前に知ることができる。

【0083】

また、本第１の実施形態では、突発的なリクエストがあった場合に、現在運行中の運行スケジュールに突発的なリクエストを行った患者を組み込むこととしている。これにより、突発的なリクエストを行った患者をなるべく早く病院に送り届けるようにすることができるので、突発的なリクエストを行った患者の待ち時間を減らすことができる。

【0084】

また、本第１の実施形態では、許容時間を診療科ごとに定めているので、診療科の特性等を考慮した適切な許容時間を処理に用いることが可能である。

【0085】

なお、上記実施形態では、許容時間を診療科ごとに定めることとしたが、これに限らず、診療科が同一であっても診療の種類（検査や手術など）ごとに許容時間を異ならせてもよい。例えば、予約時刻に遅れたときに他の患者への影響や病院経営に対する影響が大きい診療の種類に対して、短めの許容時間を設定するなどしてもよい。

【0086】

なお、上記第１の実施形態では、図６（ｂ）の運行スケジュールにおいて、１台のバスで病院に送り届ける患者全員の診察開始可能時刻を、病院到着時刻に基づいて一律に定めている。しかしながら、これに限らず、病院到着時刻に基づいて、各患者の診察開始可能時刻を別々に算出してもよい。この場合、例えば病院のバスの停留所から各診療科までの距離に基づいて、各診療科を受診する患者の診察開始可能時刻を算出してもよい。また、例えば各患者の年齢に基づいて、各患者の診察開始可能時刻を算出してもよい。この場合、患者の年齢が高いほど病院到着時刻と診察開始可能時刻の間の時間を長くするなどすればよい。また、患者の年齢以外の要素を考慮して、診察開始可能時刻を算出してもよい。

【0087】

《第２の実施形態》
以下、第２の実施形態について説明する。上記第１の実施形態においては、許容時間テーブル４１（図７（ａ））において、診療科ごとに許容時間を設定する場合について説明したが、本第２の実施形態においては、図１８に示すような許容時間テーブル４１’を用いるものとする。図１８の許容時間テーブル４１’においては、患者ごと（患者ＩＤごと）に許容時間が予め設定される。なお、患者ごとの許容時間は、患者が送迎のリクエストを行う際に、患者自身が設定してもよいし、病院の受付担当者が設定してもよい。

【0088】

この場合、第１の実施形態の図１４の処理に代えて、図１９に示すような処理を行うこととすればよい。第１の実施形態では、図１４のステップＳ２４８５において、判定部１３が、許容時間テーブル４１から各診療科の許容時間を取得することとしていた。また、第１の実施形態では、図１４のステップＳ２４８９において、判定部１３が、診療科ごとに算出した差の最大値を特定し、各診療科の許容時間と比較することとしていた。これに対し、本第２の実施形態では、図１９のステップＳ２４８５’において、判定部１３は、許容時間テーブル４１’から各患者の許容時間を取得する。また、本第２の実施形態では、図１９のステップＳ２４８９’において、判定部１３は、各患者の診察開始可能時刻と診察予約時刻との差と、各患者の許容時間とを比較する。そして、ステップＳ２４９０’において、判定部１３は、全患者の診察開始可能時刻と診察予約時刻との差が、各患者の許容時間以下であるかを判断する。

【0089】

このようにしても、上記第１の実施形態と同様、作成した仮運行スケジュールが、バスに乗る全患者を適切に送り届けることが可能なスケジュールである場合に、作成した仮運行スケジュールを実際に利用することが可能となる。

【0090】

なお、患者ごとに許容時間を設定できるようにすることで、診療科の許容時間だけでなく、各患者の希望を反映させることができる。例えば、診療科の許容時間が３０分であっても、患者自身が早めに診察を受けたい場合には、その患者の許容時間を短く（例えば、０分や５分などに）設定することができる。

【0091】

なお、各患者の許容時間を設定する場合、図２０（ａ）に示すような許容時間リストを予め用意しておいてもよい。この場合、各患者の許容時間を設定する際に図２０（ｂ）に示すような許容時間テーブル４１’を参照することで許容時間を容易に設定することが可能となる。

【0092】

《第３の実施形態》
以下、第３の実施形態について説明する。本第３の実施形態では、図９のステップＳ１０４において、運行スケジュール作成部１２が取得したリクエストから当日の運行スケジュールを作成する際に、患者が受診する診療科の許容時間を考慮する。

【0093】

例えば、各診療科において図２１に示すような診察予約が入っているとする。図２１のように、放射線科の許容時間が０分の場合、放射線科を受診する患者が運行スケジュールに１人でも含まれていると、突発的なリクエストを行った患者をその運行スケジュールに含めることができなくなる可能性が高い。このような場合、例えば、当日の運行スケジュールを作成する際に、放射線科以外の患者だけで運行スケジュールを作成するとともに、放射線科の患者だけで運行スケジュールを作成する（図２１の太線枠参照）。これにより、放射線科以外の患者だけで作成した運行スケジュールについては、新規のリクエストを高い確率で含めるようにすることが可能となる。

【0094】

なお、上記各実施形態では、突発的なリクエストがあった場合に、現在運行中の運行スケジュールに突発的なリクエストを行った患者の送迎を含められるかを判定する場合について説明したが、これに限られるものではない。例えば、未運行の運行スケジュールにリクエストを行った患者の送迎を含められるかを判定する際に、上記各実施形態と同様に未運行の運行スケジュールから仮運行スケジュールを作成（未運行の運行スケジュールを修正）してもよい。そして、作成した仮運行スケジュールが適切であるかを上記各実施形態と同様に判定してもよい。

【0095】

なお、上記各実施形態では、バスが１つの病院に患者を送り届ける場合について説明したが、これに限らず、バスは複数の病院に患者を送り届けることとしてもよい。この場合、許容時間は、病院ごとに定めてもよいし、各病院の診療科ごとに許容時間を定めてもよい。なお、バスが複数の病院に患者を送る場合、バス管制サーバ１０は、例えば自治体が管理するものとし、バス管制サーバ１０には複数の診察予約管理サーバ２０が接続されるものとする。

【0096】

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記憶媒体（ただし、搬送波は除く）に記録しておくことができる。

【0097】

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記憶媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

【0098】

プログラムを実行するコンピュータは、例えば、可搬型記憶媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記憶媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

【0099】

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

【0100】

なお、以上の第１～第３の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） １又は複数の第１の患者が診察開始時刻に間に合うように、前記第１の患者を車両で病院に送り届ける際の運行スケジュールを作成し、
新たな第２の患者からリクエストを受信すると、前記第１の患者と前記第２の患者とを車両で病院に送り届けるように、作成した前記運行スケジュールを修正し、
修正した前記運行スケジュールにおいて前記第１の患者が受診できる時刻が、前記第１の患者の診察開始時刻の前、又は、前記第１の患者の診察開始時刻の後であるが、前記第１の患者の許容時間を超えない時間内であれば、修正した前記運行スケジュールを前記第１の患者と前記第２の患者を車両で病院に送り届ける際の運行スケジュールと決定する、
処理をコンピュータが実行することを特徴とする運行スケジュール作成方法。
（付記２） 前記修正する処理において修正する前記運行スケジュールは、既に前記車両が運行を開始している運行スケジュールである、ことを特徴とする付記１に記載の運行スケジュール作成方法。
（付記３） 前記許容時間は、前記第１の患者が診察を受ける病院又は診療科ごとに定められている、ことを特徴とする付記１又は２に記載の運行スケジュール作成方法。
（付記４） 前記許容時間は、前記第１の患者ごとに定められている、ことを特徴とする付記１又は２に記載の運行スケジュール作成方法。
（付記５） 前記運行スケジュールを作成する処理において、患者の許容時間を参照して、前記許容時間が所定範囲に含まれる複数の患者を前記第１の患者とする、ことを特徴とする付記１～４のいずれかに記載の運行スケジュール作成方法。
（付記６） １又は複数の第１の患者が診察開始時刻に間に合うように、前記第１の患者を車両で病院に送り届ける際の運行スケジュールを作成し、
新たな第２の患者からリクエストを受信すると、前記第１の患者と前記第２の患者とを車両で病院に送り届けるように、作成した運行スケジュールを修正し、
修正した前記運行スケジュールにおいて前記第１の患者が受診できる時刻が、前記第１の患者の診察開始時刻の前、又は、前記第１の患者の診察開始時刻の後であるが、前記第１の患者の許容時間を超えない時間内であれば、修正した前記運行スケジュールを前記第１の患者と前記第２の患者を車両で病院に送り届ける際の運行スケジュールと決定する、
処理をコンピュータに実行させることを特徴とする運行スケジュール作成プログラム。

【符号の説明】

【0101】

１０ バス管制サーバ
１１ リクエスト受信部
１２ 運行スケジュール作成部
１３ 判定部
１４ 運行スケジュール通知部
１５ バス情報受信部
２１ 予約受付部
３１ 運行スケジュールテーブル
３２ リクエストテーブル
３３ バス情報テーブル
４１ 許容時間テーブル
４２ 予約情報テーブル
２０ 診察予約管理サーバ
６０ バス端末
７０ 端末

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】