バス車上ポイント交換システムと、複数のバス車両所にそれぞれ設けられたバス車両所システムと、複数のバスのそれぞれに設けられたバスシステムとを有するバスポイント交換システムであって、前記バス車上ポイント交換システムは、ユーザからポイントカード特定情報と交換ポイントを受付け、前記受付けた交換ポイントとポイントカード特定情報をそれぞれ対応付けて配信データとして配布用データベースに記憶し、前記配信データを、前記バス車両所システムへ送信し、前記バス車両所システムは、前記配信データを前記バスシステムが前記バス車両所システムと接続可能な状況である場合に、バス車両上のバスシステムへ前記受信した配信データを前記バスシステムへ送信し、前記バスシステムは、非接続状態の場合に、ユーザから受付けたポイントカード情報と、前記受信した配信データ内のポイントカード特定情報とを照合して一致したポイントカードの交換ポイント分の金銭的価値を前記受付けたユーザのポイントカードに付与し、前記バスシステムが前記バス車両所システムと接続可能な状況である場合に、ポイントの交換が完了したことを示す情報を前記バス車両所システムに送信し、前記バス車両所システムは前記受信した完了情報をバス車上交換システムに送信することを特徴とするバスポイント交換システム。請求項1に記載のバスポイント交換システムであって、前記バス車上ポイント交換システムは更に、ユーザからの路線情報を受付け、前記交換ポイントと前記ポイントカード特定情報と前記路線情報とを対応付けて交換情報データベースに記憶し、車両を特定する車両情報毎に、車両所を特定する車両所情報と路線情報をそれぞれ対応付けて、運行する順番にバス運用データベースに記憶し、前記交換情報データベースの情報とバス運用データベースの情報を照合して、各ポイントカード特定情報に対応する車両所情報と車両情報を特定し、前記特定された車両所情報と車両情報を対応付けて配布用データベースに記憶し、前記配信データで特定される車両所のうち、最初に運行されるバス車両所システムへ対応する交換ポイントとポイントカード特定情報と車体情報を送信し、前記バス車両所システムは、前記受信した車両情報に対応する車両のバスシステムに、前記車両情報に対応する前記受信した交換ポイントとポイントカード特定情報を送信することを特徴とするバスポイント交換システム。請求項1乃至請求2に記載のそのそれぞれのバスポイント交換システムであって、前記バス車上ポイント交換システムは更に、ユーザ毎のポイントカード特定情報に対応する優先度を表す情報を受付け、前記優先度に応じて、配信用データベースを複数作成し、前記複数の配信用データベースを前記バス車両上システムに送信し、前記バス車両上システムは優先度の高い配信用データベースから順に前記車両情報を基に対応する車両のバスシステムに前記車両情報に対応する前記受信した交換ポイントとポイントカード特定情報を送信することを特徴とするバスポイント交換システム。請求項1乃至請求項3のそのそれぞれのバスポイント交換システムであって、前記バス車上ポイント交換システムが特定される複数の車両所のバス車両システムへ交換ポイントとポイントカード特定情報と車体情報を送信することを特徴とするバスポイント交換システム。バス車上ポイント交換システムと、複数のバス車両所にそれぞれ設けられたバス車両所システムと、複数のバスのそれぞれに設けられたバスシステムとを有するバスポイント交換方法であって、前記バス車上ポイント交換システムは、ユーザからポイントカード特定情報と交換ポイントを受付けるステップと、前記受付けた交換ポイントとポイントカード特定情報をそれぞれ対応付けて配信データとして配布用データベースに記憶するステップと、前記配信データを、前記バス車両所システムへ送信するステップとを有し、前記バス車両所システムは、前記配信データを前記バスシステムが前記バス車両所システムと接続可能な状況である場合に、バス車両上のバスシステムへ前記受信した配信データを前記バスシステムへ送信するステップを有し、前記バスシステムは、非接続状態の場合に、ユーザから受付けたポイントカード情報と、前記受信した配信データ内のポイントカード特定情報とを照合して一致したポイントカードの交換ポイント分の金銭的価値を前記受付けたユーザのポイントカードに付与するステップと、前記バスシステムが前記バス車両所システムと接続可能な状況である場合に、ポイントの交換が完了したことを示す情報を前記バス車両所システムに送信し、前記バス車両所システムは前記受信した完了情報をバス車上交換システムに送信するステップとを有するバスポイント交換方法。バスにあるIC乗車券を読み書きする為のリーダ/ライタをSFのポイント交換機としようとした場合、バスは常に移動しており外部のポイントを管理する装置に接続できず、顧客がかざしたIC乗車券は認識出来ても、その保有ポイントを把握出来ず、ポイント交換機として動作させることができない。また、前以て保有ポイント等のポイント交換希望データをバスに送信しようとすると、会員数が多い大規模なポイントシステムにおいては、その会員のポイント交換希望データは大量になる為、ポイント交換のデータ全てを多数のリーダ/ライタに送るとなると、ネットワーク回線に負荷がかかるため、バスのようにポイント交換システムに長時間接続出来ない端末上で限られた短い伝送時間帯の中で処理を行うのは困難であり、効率的なポイント交換を実現することができない。上記課題を解決する為、本発明は、バス車上ポイント交換システムと、複数のバス車両所にそれぞれ設けられたバス車両所システムと、複数のバスのそれぞれに設けられたバスシステムとを有するバスポイント交換システムであって、バス車上ポイント交換システムは、ユーザからポイントカード特定情報と交換ポイントを受付け、受付けた交換ポイントとポイントカード特定情報をそれぞれ対応付けて配信データとして配布用データベースに記憶し、配信データを、前記バス車両所システムへ送信し、バス車両所システムは、配信データをバスシステムがバス車両所システムと接続可能な状況である場合に、バス車両上のバスシステムへ受信した配信データをバスシステムへ送信し、バスシステムは、非接続状態の場合に、ユーザから受付けたポイントカード情報と、受信した配信データ内のポイントカード特定情報とを照合して一致したポイントカードの交換ポイント分の金銭的価値を受付けたユーザのポイントカードに付与し、バスシステムがバス車両所システムと接続可能な状況である場合に、ポイントの交換が完了したことを示す情報をバス車両所システムに送信し、バス車両所システムは受信した完了情報をバス車上交換システムに送信することを特徴とする。また、バス車上ポイント交換システムは更に、ユーザからの路線情報を受付け、交換ポイントと前記ポイントカード特定情報と前記路線情報とを対応付けて交換情報データベースに記憶し、車両を特定する車両情報毎に、車両所を特定する車両所情報と路線情報をそれぞれ対応付けて、運行する順番にバス運用データベースに記憶し、交換情報データベースの情報とバス運用データベースの情報を照合して、各ポイントカード特定情報に対応する車両所情報と車両情報を特定し、特定された車両所情報と車両情報を対応付けて配布用データベースに記憶し、配信データで特定される車両所のうち、最初に運行されるバス車両所システムへ対応する交換ポイントとポイントカード特定情報と車体情報を送信し、バス車両所システムは、受信した車両情報に対応する車両のバスシステムに、前記車両情報に対応する前記受信した交換ポイントとポイントカード特定情報を送信することを特徴とする。また、バス車上ポイント交換システムは更に、ユーザ毎のポイントカード特定情報に対応する優先度を表す情報を受付け、優先度に応じて、配信用データベースを複数作成し、複数の配信用データベースを前記バス車両上システムに送信し、バス車両上システムは優先度の高い配信用データベースから順に前記車両情報を基に対応する車両のバスシステムに車両情報に対応する前記受信した交換ポイントとポイントカード特定情報を送信することを特徴とする。また、バス車上ポイント交換システムが、特定される複数の車両所のバス車両システムへ交換ポイントとポイントカード特定情報と車体情報を送信しすることを特徴とする。バス車上で効率の良い金銭的価値をポイントカードに付与する処理を行うことが出来る。以下、実施例を図面を用いて説明する。本実施例では、クレジットカードなどのICカード利用に伴い発生したポイントを、電子マネーに変換してIC乗車券に還元するシステムを説明する。図1は本実施例のバスポイント交換システムの構成図の例である。WEB接続端末とバス車上ポイント交換システム1、ポイント管理システム4、バス管理システム、バス車両所システム2、バスシステム3がネットワークを介して接続している。バス管理システムにはDBとしてバス停DB10、バス運用DB11がある。バス運用DB11、バス停DB10はバス管理システム上に限定されるものではなく、バス車上ポイント交換システム1上にあってもよい。ポイント管理システム4にはDBとして会員情報DB12がある。これはポイント管理システム上に限定されるものではなく、バス車上ポイント交換システム1上にあってもよい。バス車上ポイント交換システム1にはDBとして交換情報DB13、配布用DB14がある。バス車両所システム2にはDBとして車両所配布用DB15、16、17、車両読替DB21がある。バスシステム3にはDBとして車上交換DB18、受信状態DB19、乗車顧客DB20がある。ICカードにはデータとしてカード情報、交換済フラグがある。WEB接続端末は広く一般に普及しているインターネット接続端末である。またDBについてはバス車上ポイント交換システムとバス車両所間の回線が細い事によるバスとバス車上ポイント交換システムとの直接通信する場合の性能面の不安から分散させているが、バス車両所側のDBである車両所配布用DB15~17と車両読替DB21はバス車上ポイント交換システム側にあってもよい。図2では、バス停DB10のデータ構成図を示す。本DBには、バス停名、路線Noを格納する。路線Noが複数あるのはバス停とそのバス停を使用する路線の関係が1:Nの関係であるからである。バス亭DB10は顧客がWEBから路線Noを指定する場合に使用する。具体的には後述するの処理で使用する。図3では、バス運用DB11のデータ構成図を示す。本DBには、バス車両No、路線を格納する。バス運用DB11はバス車両Noを主キーとし、運用情報⇒運用情報のように出発車両所と路線No、到着車両所が順々にわかるようになっている。図4では、会員情報DB12のデータ構成図を示す。本DBには、カードNo、パスワード、保有ポイント、Mail、会員区分、削除日付を格納する。図5では、交換情報DB13のデータ構成図を示す。本DBには、交換用通番、カードNo、交換ポイント数、会員区分、交換開始日付、交換終了日付、路線No、路線No、交換完了フラグを格納する。図6では、配布用DB14のデータ構成図を示す。本DBには、車両所No、車両No、交換用通番、カードNo、交換ポイント数、会員区分を格納する。図7~9では、車両所配布用DB15~17のデータ構成図を示す。本DBには、車両No、交換用通番、カードNo、交換ポイント数、会員区分、交換済フラグを格納する。図10では、車上交換用DB18のデータ構成図を示す。本DBには、交換用通番、カードNo、交換ポイント、交換済フラグを格納する。図11では、受信状態DB19のデータ構成図を示す。本DBには、車両No、完了会員区分Gold、完了会員区分Silver、完了会員区分Bronzeを格納する。図12では、乗車顧客DB20のデータ構成図を示す。本DBには、車両No、カードNoを格納する。図13では、車両読替DB21のデータ構成図を示す。本DBには、読替元車両No、読替後車両Noを格納する。図14では、ポイント交換情報をどの車両に配信するかを決め、配信用のデータを作成する処理の流れを示す。本実施例のポイント配信処理は毎日行われる。以降図14のフローチャートに沿って説明する。このフローチャートはそれぞれ、バス車上ポイント交換システム1、バス車両所システム2、バスシステム3とデータの流れに沿って一連のシステムの処理についてのフローチャートである。ポイント管理システム4が予め会員毎にICカード利用頻度や利用額から会員種別をGold、Silver、Bronzeに分けておくこととする。また会員は予めポイント管理システム4にカードNoとパスワード、メールアドレスを登録しておくものとする。カードNoとはICカード裏面に記載のNo及び各ICカード内にある一意のNoとする。ポイント管理システムは会員情報DB12のカードNoとパスワード、MAILに入力された項目においてそれぞれ登録する。ここでは具体的にはカードNoに1001、パスワードにbus、Mailに123abcと登録した会員AとカードNoに1002、パスワードにpass、Mailに456abcと登録した会員Bがいたものとする。まず会員はパソコン等のWebブラウザからバス車上ポイント交換システム4へアクセスを行う。そこで会員AはカードNo1001とパスワードbusを入力、会員BはカードNo1002とパスワードpassを入力し、会員用ページへログインを行う。バス車上ポイント交換システム1は入力されたカードNo1001とパスワードbusに対し会員情報DB12のカードNo1001とパスワードbusと照らし合わせ認証を行う。会員Bについても同様の処理を行う。バス車上ポイント交換システム1は予約画面表示処理部は会員Aについて会員用ページ上で会員情報DB12のカードNo1001である会員Aをログイン者と判断し、保有ポイント300と現在の会員区分Goldを表示、ポイント交換手続き可能状態に移行する。会員Bについても同様の処理を行い、保有ポイント289と現在の会員区分Silverを表示する。交換予約受付部では、まず会員は交換を希望する交換希望ポイント数78と日付期間20110331、日付期間20110407を入力する。バス車上ポイント交換システムは1会員情報DB12の保有ポイント数300と会員が希望した交換希望ポイント数78を照らし合わせ、この場合保有ポイント300が交換希望ポイント78を上回っているため交換可能と判定する。会員Bについても同様に保有ポイント289が交換希望ポイント30を上回っているため交換可能と判定する。バス車上ポイント交換システム1に交換可能と判定された場合、会員は交換を希望するバスの路線Noを指定することが出来る。具体的にはまず会員A、Bは、共に路線No指定のためWeb画面上で乗車バス停博多一丁目と降車バス停中洲三丁目を指定する。バス車上ポイント交換システム1はバス停DB10のバス停名博多一丁目と中洲三丁目のレコードに共通している路線Noとして305と306を抽出。指定されたバス亭を通過する路線Noとして305、306を表示する。会員は表示された路線No305、306から305、306を選択し、ポイント交換手続きを完了とする。勿論、ここで選択する路線Noは複数個、単数個どちらでも構わない。バス車上ポイント交換システムは会員A、Bからの路線No指定305、306を持って交換手続き終了とみなし、会員情報DB12の顧客の保有ポイント300から交換ポイント数78の減算処理をポイント減算部で行う。減算の結果、会員情報DB12の保有ポイントが300から222となる。ポイント交換手続きの結果、後述のステップS006の処理で交換ポイント数は交換情報DB13の交換ポイント数に78として格納される。但しポイント付与はバス車上で行うため、まだ付与自体はされていない。ここではポイント入力を受付けてから、路線番号を指定したが、この順序に限定されるものではなく、路線番号の入力を受付けてから、ポイントの入力を受付けることとしてもよい。バス車上ポイント交換システム1は交換情報DB13に交換希望を受け付けたカードNo1001と交換ポイント数78、交換開始日付20110331、交換終了日付20110407、路線No305、306に交換用通番00230046を採番し格納する。交換開始日付と交換終了日付は後述するステップS008の夜間バッチ処理でポイント交換対象のレコードを抽出する場合に使用する。このタイミングで減算を行うのは、会員が別サービスでポイント交換を行った場合に、バス車上ポイント交換システム1が保有ポイント以上のポイント交換予約を受け付けてしまう可能性があるためである。具体的には後日減算を行う方式の場合、上記のように会員情報DB12の保有ポイント300の顧客がバス車上ポイント交換システム1で78ポイントのポイント交換手続きをとった直後に別サービスで300ポイント分ポイント交換を行い会員情報DB12の保有ポイント0となった場合、後で交換バス車上ポイント交換システム1が、予約を受け付けたポイント分78を会員情報DB12の保有ポイント0から減算を行うとしても減算出来ないためエラーとなってしまう。バス車上ポイント交換システム1は毎日夜間帯に夜間バッチを起動させる。夜間バッチでは、サーバのシステム日付と交換情報DB13の交換開始日付20110331、交換終了日付20110407とを比較し、交換開始日付<=サーバのシステム日付<=交換終了日付となっている交換用通番00230046のレコードを抽出する。次に抽出した交換情報DB13のレコードの路線No305と路線No306と、バス運用DB11の路線Noとを比較し、バス運用DB11の路線Noの中で305と306のどちらか1方を持つレコードが2レコード存在することがわかる。そして抽出したこの2レコードの車両Noを参照することで、配信先決定部はバス運用DB11においてバス車両NoA100、B100を特定する。ここまでで、つまり顧客が指定した路線Noからその路線Noで実際に走る予定である車両Noまでを特定出来る。次にバス運用DB11から特定した車両NoA100、B100をもとにこの2車両がが一日の間に立ち寄る車両所Noを検索する。ここでバスがその日立ち寄る車両所Noを特定する理由は車両所Noが不明の場合、ポイント交換情報を配信したい車両が止まる車両所がわからないため、どの車両所にポイント交換情報の配信すれば良いか不明となり、全車両所にポイント交換情報を配信しなければならなくなるからである。その場合、バス車上ポイント交換システムと車両所を繋ぐネットワーク負荷とバス車両所のディスク容量が莫大なものとなるからである。車両所を特定することでポイント交換情報を配信したい車両が止まる車両所にポイント交換情報を配信することが出来、ネットワーク負荷とバス車両所のディスク容量の削減につながる。次に実際の車両所の特定の仕方を以下に記す。まず上記で特定したバス車両NoA100をキーにバス車両Noを検索し該当レコードを参照する。するとバス車両NoA100はバス車両所L001を始発車両所にし路線No305として出発し、バス車両所L002に到着。次にバス車両所L002を路線No306として出発し...のような1日のスケジュールであることがわかる。つまり車両NoA100が1日に立ち寄る車両所はバス車両所NoL001とL002であること、また始発車両所がL001であることがわかる。同様に車両NoB100もバス車両所NoL002L003に立ち寄り始発車両所がL002であることがわかる。ここで始発車両所とはバスが前日の業務を終えてから翌朝発車するまで待機し夜間バッチ処理を受ける車両所を指す。そのため車両所の中でも始発車両所まで特定する必要がある。ここまでで顧客が指定した路線No305と306からその路線Noとして走る予定のあるバス車両A100、B100を特定、次にそのバス車両Noから、そのバスが止まる車両所L001とL002、L003を特定、またその中でも特にL001とL002がバスA100、B100の夜間バッチを行う始発車両所であることまでわかる。ここでバス運用DB11は車両NOを主キーに、運用情報という配列を、その日のスケジュール順に配置連結する構造としているため、あえて始発車両所フラグ等のデータ項目を付加する事なく、自動的に運用情報の車両所が始発車両所であるとわかる構造としている。このことによりデータ項目の削減と、始発車両所が必ず先頭に並んでいることによる始発車両所データ検索速度の高速化を図っている。複数の配信データ作成部は、交換情報DB13から抽出した交換用通番00230046のレコードからカードNo1001と交換ポイント数78、会員区分Gold、車両所NoL001L002L003、車両NoA100、B100を配布用DB14に追加し格納する。次に配布用DB14の交換用通番00230046のレコードを車両所NoL001、L002、L003のバス車両所に向けて配信する。ここで交換用通番とはWEB経由でポイント交換を受付け、交換情報DB13にデータを格納する場合にバス車上ポイント交換システム1が付加するユニークキーである。また夜間バッチを行う始発車両所だけでなく、バスが立ち寄る車両所にもデータを配信するのは後述する~の車両が故障した場合の対応で、バスとバス車上ポイント交換システムとの直接通信量を減らすため、予めデータのバックアップ先として車両所を利用するためである。配布用DBで特定されるバス車両所L001、L002、L003のバス車両所システム2ではバス車上ポイント交換システム1から配布された配布用DB14の情報を会員区分でソートし車両所配布用DBGold15、車両所配布用DBSilver16、車両所配布用DBBronze17に分類を行う。本実施例ではバス車両所システム2で分類するとしたが、これに限定されるものではなく、バス車上ポイント交換システム1で前以て変換しておいてもよい。交換用通番00230046のレコードは会員区分Goldのため、車両所配布用DBGold15に格納する。この編成を持って夜間バッチは完了とする。分類する意図としては配信する情報に優先度を付け優先度順に配信を行うためである。バスは車両故障や交通事情による交通遅延が多いため、バスがダイヤを優先するためバス車両所からのポイント情報を全て受信する前に発進する必要に迫られる事が多くなることを想定している。この場合ポイント交換情報が全て配信されるまでバスを発車させないということにするとダイヤ乱れが拡大する可能性が高まるため、ポイント交換情報が完全には配信出来ていなくても本発明では発車可能とする。また本発明では、このようなポイント交換情報の未配信を防ぐために、基本的に夜間に集中的にポイント交換情報各バスに配布するようにしているため、実際の運用ではポイント交換情報が配信されないことは少ない。優先度情報を付加し配布しているのは、本発明では可能性が少ないが、もし送れかった場合のことまで想定して被害を最小限に抑えるために利用頻度が高い顧客に優先的に情報配信する仕組みを提供するためである。また仕組みとしてポイント交換情報が完全に配信されるまでバスを発車させないということにすればバスのダイヤ乱れが発生する可能性がありますが、ポイント交換情報が送れないということと天秤にかけてどっちを優先するかはバス会社の方針に寄る。バス車両所ではバスA100から送られてくる受信状態DB19をもとに情報配信を行う。まず受信状態DB19に含まれている完了会員区分をもとに送信すべき車両所配布用DB15~17の区分GoldかSilverかBronzeかを選択し、次に車両Noから車両所配布用DB15~17の配信すべきレコードを決定する。具体的には受信状態DB19の完了区分が0の場合は車両所配布用DB15、16、17全て配信されていないとみなし、車両所配布用DBGold15、車両所配布用DBSilver16、車両所配布用DBBronze17の順に配信を開始する。そして車両所配布用DB15の送信が完了した場合、バスA100の受信状態DB19の完了会員区分を1に更新する。同様に他の完了会員区分も情報配信が完了した場合に完了会員区分を更新する。バスは車両所停車中、定期間隔でバス車両所に受信状態DB19の車両NoA100、完了会員区分、完了会員区分、完了会員区分を送信する。バス車両所は上記でバスから送信された受信状態DB19の車両NOA100、完了会員区分、、をもとに送信可否を判断する。つまりバスから送信された完了会員区分が1に更新されていた場合はその完了会員区分の車両所配布用DB15~17は配信済みとして配信を行わない。車両所はバスに向けて交換用通番00230046とカードNo1001、交換ポイント数78、交換済フラグ0を送信する。バスでは受け取った情報を車上交換用DB18に格納する。バスは定期間隔で受信状態DB19の完了会員区分が更新されているかのチェックを行う。Goldだけをチェックする理由としては、本特許ではバスが発車可能状態に移行するのに必要な条件は会員区分Goldの会員向けのポイント交換情報をバスが受け取っていることなので、バスから見るとGoldを受け取り完了しているかどうかがだけが必要な情報だからであるからである。ここでバス車上ポイント交換システム1で顧客がポイント交換を希望した路線Noだけでなく、車両Noまでバス車上ポイント交換システム1が特定しポイント交換情報を配信する意図を説明する。意図としては路線Noだけでなく、車両Noまで特定することで、路線Noで一括りにするのではなく、配信先である各バス1台1台に合わせたポイント交換情報を配信するためである。また、ではなぜ会員に車両Noでなく、路線Noを指定させるのかというと、会員は普通、バスに対しては路線Noまでしか知ることが出来ず、また実際どのバスでポイント交換するか分からないので、路線Noで指定するしかない。そのため本発明では会員が指定した路線Noの情報と日々のバス運用情報とを組み合わせて車両Noを特定するという処理を行う。車両Noを特定する処理の流れとしては、まずバス運用DB11より車両NoA100は路線No305、路線No306の予定であり、B100は路線No3、路線No306の予定であることがわかる。このことから交換情報DB13の路線No305と306でポイント交換を希望している交換通番00230046と00230047のレコードは夜間バッチでバスA100、B100に配信しておくことで後述する異常の場合以外は夜間バッチで全ての情報配信を完了させることが出来る。逆に路線Noだけで情報配信をしようとすれば、時間帯やバス車両所に寄る度に路線Noが変化することが多いバスダイヤにおいて、路線No毎に情報配信することになるため、バスの路線Noが切り替わる度に、バス車上ポイント交換システム1から見ると全く別のバスに変化したように見え、夜間バッチだけでは情報配信完了できず、バス車両所からの情報配信を路線Noが切り替わる毎にやり直す必要がある。その場合、バス車両所に寄る度にバスと車両所間の通信が発生するため、車両所からバスへの情報配信失敗やそれに伴うバスダイヤの乱れが発生する可能性が高まる。つまり路線Noでなく、バス車両Noとバス車両所Noまで特定することで、まずトラフィックの削減。次に情報配信失敗可能性の削減が可能となる。ダイヤを優先するため、受信状態DB19の完了会員区分が1に更新されたのを以ってバス発進状態に移行する。つまり最低限完了会員区分のポイント交換情報が配信されていなければバスは発進出来ないが、完了会員区分やはなくても発進は可能である。バス発進状態に移行したバスはその後ダイヤに従ってバス車両所を出発する。ここで配信出来なかったポイント交換情報の取り扱いについてはで説明を行う。上記の受信状態DB19をもとに情報配信を行う処理はバスが1日の内に各バス車両所L100、L101、L003に立ち寄るたびに配信判断部が毎回行う。バスでのポイント交換情報配信は、ポイント交換を予約した会員が乗車した場合、若しくは降車した場合にカードをICカード読取機にかざした場合に行う。バスにあるバスシステム3のポイント処理部は、読み取ったカードNo1001をと車上交換用DB18のカードNo1001を比較、対象レコードとして交換用通番00230046のレコードを抽出し、交換ポイント数78だけSFへのチャージを行う。ここでSFとは金銭的価値をいい、好感ポイント数分の金銭的価値をICカードに付与例えば乗車運賃、電子マネー等するものをいう。チャージを行ったタイミングで車上交換用DB18の交換用通番00230046のレコードとチャージを受けたICカード1001の交換済フラグを1に更新する。このことによって同じICカード1001を持った会員が別のバスB100に乗車した場合のポイントの二重交換を防ぐことが出来る。またバスはICカードをかざし乗車した客のカードNo1001を乗車顧客DB20のカードNoに格納する。ここでカードNoを乗車顧客DB20に格納する理由としては、にて後述するが、ポイント交換を希望し、該当する路線Noのバスに乗車したのにも関わらず、交換が行われなかった顧客がいなかったかどうか調査する場合に必要なデータだからである。営業終了後、バスA100はバス車両所L100に戻りバス車上ポイント交換システムと通信を行う。バス車上ポイント交換システムは乗車顧客DB20のカードNo1001を読み取る。この場合、バス車両所システムを経由して通信してもよく、これに限定されるものではない。車上交換用DB20の交換済みフラグが1に更新されている交換用通番00230046のレコードの交換用通番00230046を読み取り、交換情報DB13の交換用通番00230046のレコードを抽出し、交換完了フラグを1に更新する。次に配信漏れ顧客特定部は、ポイント交換を希望し且つ対象となる車両に乗車したのにも関わらずポイント交換が行われなかったレコードが存在するかどうかチェックを行う。具体的には乗車顧客DB20の車両NoA100とカードNo1001、交換情報DB13の車両NoA100とカードNo1001とを比較し、交換完了フラグを1を参照する。ここでは交換完了フラグが1となっているため、乗車顧客にポイント付与が行われたことがわかる。しかし、ここで交換用通番00230047にて交換を希望したカードNo1002は車両NoA100の乗車顧客DB20に格納されているにも関わらず、交換情報DB13の交換用通番00230047のレコードの交換完了フラグが0である。このことから交換を希望した顧客が乗車したのにも関わらずバス車上でポイント交換が行えなかったことがわかる。上記のような処理とケースが発生する理由として~においてGold会員の情報のみを持って発進するバスが発生する可能性があるため、通常業務の範囲内においてポイント交換情報の配信が出来ないケースが発生し得るからである。またこの処理によりポイント交換情報を配信出来なかった顧客のカードNo1002と交換用通番00230047を特定することが出来る。上記の処理でポイント交換情報の配信が出来なかったカードNo1002の顧客に対してはバス車上ポイント交換システムのWEB画面や会員情報DB12のMail456abcにお詫びの連絡を入れるなど対策を取る。バス車上ポイント交換システムは交換情報DB13の交換完了フラグが1に更新された交換用通番00230046のレコードについて、交換完了とみなし交換済データ削除部は、交換情報DB13からレコードを削除する。交換情報DB13の交換完了フラグが1に更新されないまま交換日付終了を過ぎたポイント交換情報については、未交換ポイント加算部として、交換希望ポイント分をポイント交換を希望した会員の保有ポイントへの加算を行う。ここで交換情報DB13の交換用通番00230047のレコードについて交換日付終了20110407を過ぎても交換完了フラグが1に更新されない場合、交換ポイント数30を保有ポイントへ加算を行う。次に各バスとバス車両所の車両所配布用DB15~17を全て削除し終了する。基本的にポイント交換情報の配信は夜間バッチにてポイント管理サーバからバス車両所を通してバスに配信される。しかし、バスは他交通機関と違い交通事情により、ダイヤ乱れが発生し易いため事前に計画していなかったバス車両が運行する可能性がある。この場合夜間バッチでは予め計画されていた情報に従ってバスにポイント交換情報を配信しているため、予定外のバスには対応出来ない。具体的には車両所への到着が遅れているバスA100があった場合、代理として予備車両C100に路線No305と乗務員を割り振り発進させるケースや車両故障により予備車両を発進させるケースである。この場合予備車両には夜間バッチにてポイント交換情報が配信されていないため、で記述した通り発進状態に移行出来ない。そのためダイヤ乱れ等により予備車両を使用する場合は事前に車両No読替登録部で処理を行っておく必要がある。車両No読替登録部の流れは以下である。バス車両所においてダイヤ乱れ等により予備車両C100を使用すると決定した場合、バス車両所からバス管理システムへ読替対象の車両NoC100、A100を通達する。バス管理システムは車両読替DB21に読替元車両NoC100と読替後車両NoA100を格納する。バス管理システムは随時全バス車両所に車両読替DB21を配信している。バス車両所は車両読替DB21の替元車両NoC100と読替後車両NoA100を参照し、車両No読替部で処理を行う。車両No読替部では具体的にはでバスから送信されてくる受信状態DB19の車両NoC100を車両読替DB21に従ってA100に読替る。こうすることでバス車両所からみて予備車両C100はあたかも当初予定されていた車両A100のように見えるため、後はで記述したように受信状態DB19の内容に従ってポイント交換情報を配信する。