(57)【特許請求の範囲】
【請求項１】
バス車上ポイント交換システムと、複数のバス車両所にそれぞれ設けられたバス車両所システムと、複数のバスのそれぞれに設けられたバスシステムとを有するバスポイント交換システムであって、
前記バス車上ポイント交換システムは、
ユーザからポイントカード特定情報と交換ポイントを受付け、
前記受付けた交換ポイントとポイントカード特定情報をそれぞれ対応付けて配信データとして配布用データベースに記憶し、
前記配信データを、前記バス車両所システムへ送信し、
前記バス車両所システムは、
前記配信データを前記バスシステムが前記バス車両所システムと接続可能な状況である場合に、バス車両上のバスシステムへ前記受信した配信データを前記バスシステムへ送信し、
前記バスシステムは、非接続状態の場合に、
ユーザから受付けたポイントカード情報と、前記受信した配信データ内のポイントカード特定情報とを照合して一致したポイントカードの交換ポイント分の金銭的価値を前記受付けたユーザのポイントカードに付与し、
前記バスシステムが前記バス車両所システムと接続可能な状況である場合に、ポイントの交換が完了したことを示す情報を前記バス車両所システムに送信し、前記バス車両所システムは前記受信した完了情報をバス車上交換システムに送信する
ことを特徴とするバスポイント交換システム。
【請求項２】
請求項１に記載のバスポイント交換システムであって、
前記バス車上ポイント交換システムは更に、
ユーザからの路線情報を受付け、
前記交換ポイントと前記ポイントカード特定情報と前記路線情報とを対応付けて交換情報データベースに記憶し、
車両を特定する車両情報毎に、車両所を特定する車両所情報と路線情報をそれぞれ対応付けて、運行する順番にバス運用データベースに記憶し、
前記交換情報データベースの情報とバス運用データベースの情報を照合して、各ポイントカード特定情報に対応する車両所情報と車両情報を特定し、
前記特定された車両所情報と車両情報を対応付けて配布用データベースに記憶し、
前記配信データで特定される車両所のうち、最初に運行されるバス車両所システムへ対応する交換ポイントとポイントカード特定情報と車体情報を送信し、
前記バス車両所システムは、
前記受信した車両情報に対応する車両のバスシステムに、前記車両情報に対応する前記受信した交換ポイントとポイントカード特定情報を送信する
ことを特徴とするバスポイント交換システム。
【請求項３】
請求項１乃至請求２に記載のそのそれぞれのバスポイント交換システムであって、
前記バス車上ポイント交換システムは更に、
ユーザ毎のポイントカード特定情報に対応する優先度を表す情報を受付け、
前記優先度に応じて、配信用データベースを複数作成し、
前記複数の配信用データベースを前記バス車両上システムに送信し、
前記バス車両上システムは
優先度の高い配信用データベースから順に前記車両情報を基に対応する車両のバスシステムに前記車両情報に対応する前記受信した交換ポイントとポイントカード特定情報を送信する
ことを特徴とするバスポイント交換システム。
【請求項４】
請求項１乃至請求項３のそのそれぞれのバスポイント交換システムであって、
前記バス車上ポイント交換システムが
特定される複数の車両所のバス車両システムへ交換ポイントとポイントカード特定情報と車体情報を送信することを
特徴とするバスポイント交換システム。
【請求項５】
バス車上ポイント交換システムと、複数のバス車両所にそれぞれ設けられたバス車両所システムと、複数のバスのそれぞれに設けられたバスシステムとを有するバスポイント交換方法であって、
前記バス車上ポイント交換システムは、
ユーザからポイントカード特定情報と交換ポイントを受付けるステップと、
前記受付けた交換ポイントとポイントカード特定情報をそれぞれ対応付けて配信データとして配布用データベースに記憶するステップと、
前記配信データを、前記バス車両所システムへ送信するステップとを有し、
前記バス車両所システムは、
前記配信データを前記バスシステムが前記バス車両所システムと接続可能な状況である場合に、バス車両上のバスシステムへ前記受信した配信データを前記バスシステムへ送信するステップを有し、
前記バスシステムは、非接続状態の場合に、
ユーザから受付けたポイントカード情報と、前記受信した配信データ内のポイントカード特定情報とを照合して一致したポイントカードの交換ポイント分の金銭的価値を前記受付けたユーザのポイントカードに付与するステップと、
前記バスシステムが前記バス車両所システムと接続可能な状況である場合に、ポイントの交換が完了したことを示す情報を前記バス車両所システムに送信し、前記バス車両所システムは前記受信した完了情報をバス車上交換システムに送信するステップと
を有するバスポイント交換方法。
【発明の詳細な説明】
【技術分野】
【０００１】
車両上でポイントを金銭的価値に変換する技術に関する。
【背景技術】
【０００２】
商品を購入した場合に、ポイントを付与して、そのポイントを運賃等に割当てるような技術が知られている。（特許文献１）
また、ポイントを直接運賃等に割当てるのではなく、ポイントをＳＦ（Ｓｔｏｒｅｄ Ｆａｒｅ）として還元するサービスが知られている。ＳＦは、ＩＣカード乗車券に記録される金銭的価値で、運賃の支払いや乗車券類との引き換えに充当するものをいう。
【０００３】
利用者が保有するポイントをカード発行元会社などが管理している場合、ポイントをＳＦに変換するにはカード発行元会社が保有・設置しているポイント交換機に出向く必要がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2002-157311号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
バスにあるＩＣ乗車券を読み書きする為のリーダ／ライタをＳＦのポイント交換機としようとした場合、バスは常に移動しており外部のポイントを管理する装置に接続できず、顧客がかざしたＩＣ乗車券は認識出来ても、その保有ポイントを把握出来ず、ポイント交換機として動作させることができない。
【０００６】
また、前以て保有ポイント等のポイント交換希望データをバスに送信しようとすると、会員数が多い大規模なポイントシステムにおいては、その会員のポイント交換希望データは大量になる為、ポイント交換のデータ全てを多数のリーダ／ライタに送るとなると、ネットワーク回線に負荷がかかるため、バスのようにポイント交換システムに長時間接続出来ない端末上で限られた短い伝送時間帯の中で処理を行うのは困難であり、効率的なポイント交換を実現することができない。
【課題を解決するための手段】
【０００７】
上記課題を解決する為、本発明は、バス車上ポイント交換システムと、複数のバス車両所にそれぞれ設けられたバス車両所システムと、複数のバスのそれぞれに設けられたバスシステムとを有するバスポイント交換システムであって、バス車上ポイント交換システムは、ユーザからポイントカード特定情報と交換ポイントを受付け、受付けた交換ポイントとポイントカード特定情報をそれぞれ対応付けて配信データとして配布用データベースに記憶し、配信データを、前記バス車両所システムへ送信し、バス車両所システムは、配信データをバスシステムがバス車両所システムと接続可能な状況である場合に、バス車両上のバスシステムへ受信した配信データをバスシステムへ送信し、バスシステムは、非接続状態の場合に、ユーザから受付けたポイントカード情報と、受信した配信データ内のポイントカード特定情報とを照合して一致したポイントカードの交換ポイント分の金銭的価値を受付けたユーザのポイントカードに付与し、バスシステムがバス車両所システムと接続可能な状況である場合に、ポイントの交換が完了したことを示す情報をバス車両所システムに送信し、バス車両所システムは受信した完了情報をバス車上交換システムに送信する  ことを特徴とする。
【０００８】
また、バス車上ポイント交換システムは更に、ユーザからの路線情報を受付け、交換ポイントと前記ポイントカード特定情報と前記路線情報とを対応付けて交換情報データベースに記憶し、車両を特定する車両情報毎に、車両所を特定する車両所情報と路線情報をそれぞれ対応付けて、運行する順番にバス運用データベースに記憶し、交換情報データベースの情報とバス運用データベースの情報を照合して、各ポイントカード特定情報に対応する車両所情報と車両情報を特定し、特定された車両所情報と車両情報を対応付けて配布用データベースに記憶し、配信データで特定される車両所のうち、最初に運行されるバス車両所システムへ対応する交換ポイントとポイントカード特定情報と車体情報を送信し、バス車両所システムは、受信した車両情報に対応する車両のバスシステムに、前記車両情報に対応する前記受信した交換ポイントとポイントカード特定情報を送信することを特徴とする。
【０００９】
また、バス車上ポイント交換システムは更に、ユーザ毎のポイントカード特定情報に対応する優先度を表す情報を受付け、優先度に応じて、配信用データベースを複数作成し、複数の配信用データベースを前記バス車両上システムに送信し、バス車両上システムは優先度の高い配信用データベースから順に前記車両情報を基に対応する車両のバスシステムに車両情報に対応する前記受信した交換ポイントとポイントカード特定情報を送信することを特徴とする。
【００１０】
また、バス車上ポイント交換システムが、特定される複数の車両所のバス車両システムへ交換ポイントとポイントカード特定情報と車体情報を送信しすることを特徴とする。
【発明の効果】
【００１１】
バス車上で効率の良い金銭的価値をポイントカードに付与する処理を行うことが出来る。
【図面の簡単な説明】
【００１２】
【図１】バス車上ポイント交換装置の構成図の例である。
【図２】バス停DBのデータ構成図を示す。
【図３】バス運用DBのデータ構成図を示す。
【図４】会員情報DBのデータ構成図を示す。
【図５】交換情報DBのデータ構成図を示す。
【図６】配布用DBのデータ構成図を示す。
【図７】車両所配布用DB（Gold）のデータ構成図を示す。
【図８】車両所配布用DB（Silver）のデータ構成図を示す。
【図９】車両所配布用DB（Bronze）のデータ構成図を示す。
【図１０】車上交換用DBのデータ構成図を示す。
【図１１】受信状態DBのデータ構成図を示す。
【図１２】乗車顧客DBのデータ構成図を示す。
【図１３】車両読替DBのデータ構成図を示す。
【図１４】車両上でのポイント交換のフローチャートを示す。
【発明を実施するための形態】
【００１３】
以下、実施例を図面を用いて説明する。
【００１４】
本実施例では、クレジットカードなどのＩＣカード利用に伴い発生したポイントを、電子マネーに変換してＩＣ乗車券に還元するシステムを説明する。
【００１５】
図１は本実施例のバスポイント交換システムの構成図の例である。WEB接続端末とバス車上ポイント交換システム１、ポイント管理システム４、バス管理システム、バス車両所システム２、バスシステム３がネットワークを介して接続している。バス管理システムにはDBとしてバス停DB１０、バス運用DB１１がある。バス運用ＤＢ１１、バス停ＤＢ１０はバス管理システム上に限定されるものではなく、バス車上ポイント交換システム１上にあってもよい。
【００１６】
ポイント管理システム４にはDBとして会員情報DB１２がある。これはポイント管理システム上に限定されるものではなく、バス車上ポイント交換システム１上にあってもよい。バス車上ポイント交換システム１にはDBとして交換情報DB１３、配布用ＤＢ１４がある。
【００１７】
バス車両所システム２にはDBとして車両所配布用ＤＢ(Gold)１５、(Silver)１６、(Bronze)１７、車両読替ＤＢ２１がある。バスシステム３にはDBとして車上交換ＤＢ１８、受信状態ＤＢ１９、乗車顧客ＤＢ２０がある。ICカードにはデータとしてカード情報、交換済フラグがある。
【００１８】
WEB接続端末は広く一般に普及しているインターネット接続端末である。またDBについてはバス車上ポイント交換システムとバス車両所間の回線が細い事によるバスとバス車上ポイント交換システムとの直接通信する場合の性能面の不安から分散させているが、バス車両所側のDBである車両所配布用DB１５〜１７と車両読替DB２１はバス車上ポイント交換システム側にあってもよい。
【００１９】
図２では、バス停DB１０のデータ構成図を示す。本DBには、バス停名(101)、路線No. (102〜106)を格納する。路線No.が複数あるのはバス停とそのバス停を使用する路線の関係が１：Nの関係であるからである。バス亭DB１０は顧客がＷＥＢから路線No.を指定する場合に使用する。具体的には後述する(S004)の処理で使用する。
【００２０】
図３では、バス運用DB１１のデータ構成図を示す。本DBには、バス車両No. (111)、路線(102〜106)を格納する。バス運用DB１１はバス車両No.(111)を主キーとし、運用情報(112)⇒運用情報(113)のように出発車両所と路線No.、到着車両所が順々にわかるようになっている。
図４では、会員情報DB１２のデータ構成図を示す。本DBには、カードNo.(121)、パスワード(122)、保有ポイント(123)、Mail(124)、会員区分(125)、削除日付(126)を格納する。
【００２１】
図５では、交換情報DB１３のデータ構成図を示す。本DBには、交換用通番(131)、カードNo. (132)、交換ポイント数(133)、会員区分(134)、交換開始日付(135)、交換終了日付(136)、路線No. (137)、路線No. (138)、交換完了フラグ(139)を格納する。
【００２２】
図６では、配布用DB１４のデータ構成図を示す。本DBには、車両所No.(145〜147)、車両No.(148,149)、交換用通番(141)、カードNo.(142)、交換ポイント数(143)、会員区分(144)を格納する。
【００２３】
図７〜９では、車両所配布用DB15〜17のデータ構成図を示す。本DBには、車両No.(151,161,171)、交換用通番(152,162,172)、カードNo.(153,163,173)、交換ポイント数(154,164,174)、会員区分(155,165,175)、交換済フラグ(156,166,176)を格納する。
【００２４】
図１０では、車上交換用DB１８のデータ構成図を示す。本DBには、交換用通番(181)、カードNo.(182)、交換ポイント(183)、交換済フラグ(184)を格納する。
【００２５】
図１１では、受信状態DB１９のデータ構成図を示す。本DBには、車両No.(191)、完了会員区分（Golｄ）(192)、完了会員区分（Silver）(193)、完了会員区分（Bronze）(194)を格納する。
【００２６】
図１２では、乗車顧客DB２０のデータ構成図を示す。本DBには、車両No.(201)、カードNo.(202〜205)を格納する。
【００２７】
図１３では、車両読替DB２１のデータ構成図を示す。本DBには、読替元車両No.(211)、読替後車両No.(212)を格納する。
【００２８】
図１４では、ポイント交換情報をどの車両に配信するかを決め、配信用のデータを作成する処理の流れを示す。本実施例のポイント配信処理は毎日行われる。以降図１４のフローチャートに沿って説明する。このフローチャートはそれぞれ、バス車上ポイント交換システム１、バス車両所システム２、バスシステム３とデータの流れに沿って一連のシステムの処理についてのフローチャートである。
<処理の前段階として>
ポイント管理システム４が予め会員毎にICカード利用頻度や利用額から会員種別をGold、Silver、Bronzeに分けておくこととする。また会員は予めポイント管理システム４にカードＮｏとパスワード、メールアドレスを登録しておくものとする。カードＮｏとはＩＣカード裏面に記載のＮｏ及び各ＩＣカード内にある一意のＮｏとする。ポイント管理システムは会員情報DB１２のカードNo(121)とパスワード(122)、MAIL(124)に入力された項目においてそれぞれ登録する。ここでは具体的にはカードNo(121)に「1001」、パスワード(122)に「bus」、Mail(124)に「123@abc」と登録した会員AとカードNo(121)に「1002」、パスワード(122)に「pass」、Mail(124)に「456@abc」と登録した会員Bがいたものとする(ステップS001)。
<WEB接続>
まず会員はパソコン等のWebブラウザからバス車上ポイント交換システム４へアクセスを行う。そこで会員AはカードＮｏ「1001」とパスワード「bus」を入力、会員BはカードＮｏ「1002」とパスワード「pass」を入力し、会員用ページへログインを行う(ステップS002)。バス車上ポイント交換システム１は入力されたカードＮｏ「1001」とパスワード「bus」に対し会員情報DB１２のカードNo(121)「1001」とパスワード(122)「bus」と照らし合わせ認証を行う。会員Bについても同様の処理を行う (ステップS003)。
【００２９】
バス車上ポイント交換システム１は予約画面表示処理部(H01)は会員Aについて会員用ページ上で会員情報DB１２のカードNo(121)「1001」である会員Aをログイン者と判断し、保有ポイント(123)「300」と現在の会員区分(125)「Gold」を表示、ポイント交換手続き可能状態に移行する。会員Bについても同様の処理を行い、保有ポイント(123)「289」と現在の会員区分(125)「Silver」を表示する。交換予約受付部(H02)では、まず会員は交換を希望する交換希望ポイント数「78」と日付期間(開始)「20110331」、日付期間(終了)「20110407」を入力する。バス車上ポイント交換システムは１会員情報DB１２の保有ポイント数(123)「300」と会員が希望した交換希望ポイント数「78」を照らし合わせ、この場合保有ポイント(123)「300」が交換希望ポイント「78」を上回っているため交換可能と判定する。会員Bについても同様に保有ポイント(123)「289」が交換希望ポイント「30」を上回っているため交換可能と判定する。バス車上ポイント交換システム１に交換可能と判定された場合、会員は交換を希望するバスの路線Ｎｏを指定することが出来る。具体的にはまず会員A、Bは、共に路線Ｎｏ指定のためＷｅｂ画面上で乗車バス停「博多一丁目」と降車バス停「中洲三丁目」を指定する。バス車上ポイント交換システム１はバス停DB１０のバス停名(101)「博多一丁目」と「中洲三丁目」のレコードに共通している路線Noとして「305」と「306」を抽出。指定されたバス亭を通過する路線Ｎｏ(102, 103)として「305」、「306」を表示する。
【００３０】
会員は表示された路線Ｎｏ(102, 103)「305」、「306」から「305」、「306」を選択し、ポイント交換手続きを完了とする。勿論、ここで選択する路線Ｎｏは複数個、単数個どちらでも構わない(ステップS004)。
【００３１】
バス車上ポイント交換システムは会員A、Bからの路線Ｎｏ指定「305」、「306」を持って交換手続き終了とみなし、会員情報DB１２の顧客の保有ポイント(123)「300」から交換ポイント数「78」の減算処理をポイント減算部(H03)で行う。減算の結果、会員情報DB１２の保有ポイント(123)が「300」から「222」となる。ポイント交換手続きの結果、後述のステップS006の処理で交換ポイント数は交換情報DB１３の交換ポイント数(133)に「78」として格納される。但しポイント付与はバス車上で行うため、まだ付与自体はされていない(ステップS005)。ここではポイント入力を受付けてから、路線番号を指定したが、この順序に限定されるものではなく、路線番号の入力を受付けてから、ポイントの入力を受付けることとしてもよい。
【００３２】
バス車上ポイント交換システム１は交換情報DB１３に交換希望を受け付けたカードＮｏ(132)「1001」と交換ポイント数(133)「78」、交換開始日付(135)「20110331」、交換終了日付(136)「20110407」、路線Ｎｏ(137,138)「305」、「306」に交換用通番(131)「00230046」を採番し格納する。交換開始日付(135)と交換終了日付(136)は後述するステップS008の夜間バッチ処理でポイント交換対象のレコードを抽出する場合に使用する(ステップS006)。
【００３３】
このタイミングで減算を行うのは、会員が別サービスでポイント交換を行った場合に、バス車上ポイント交換システム１が保有ポイント以上のポイント交換予約を受け付けてしまう可能性があるためである。具体的には後日減算を行う方式の場合、上記のように会員情報DB１２の保有ポイント(123)「300」の顧客がバス車上ポイント交換システム１で「78」ポイントのポイント交換手続きをとった直後に別サービスで「300」ポイント分ポイント交換を行い会員情報DB１２の保有ポイント「０」となった場合、後で交換バス車上ポイント交換システム１が、予約を受け付けたポイント分「78」を会員情報DB１２の保有ポイント(123)「0」から減算を行うとしても減算出来ないためエラーとなってしまう。
<夜間バッチ>
バス車上ポイント交換システム１は毎日夜間帯に夜間バッチを起動させる(ステップS007)。夜間バッチでは、サーバのシステム日付と交換情報DB１３の交換開始日付(135)「20110331」、交換終了日付(136)「20110407」とを比較し、交換開始日付(135)＜＝サーバのシステム日付＜＝交換終了日付(136)となっている交換用通番(131)「00230046」のレコードを抽出する(ステップS008)。
【００３４】
次に抽出した交換情報DB１３のレコードの路線Ｎｏ(137)「305」と路線Ｎｏ(138)「306」と、バス運用DB１１の路線No(1122,1132,11N2)とを比較し、バス運用DB１１の路線No(1122,1132,11N2)の中で「305」と「306」のどちらか１方を持つレコードが２レコード存在することがわかる。そして抽出したこの２レコードの車両Noを参照することで、配信先決定部(H04)はバス運用DB１１においてバス車両Ｎｏ(111)「A100」、「B100」を特定する。ここまでで、つまり顧客が指定した路線Ｎｏからその路線Ｎｏで実際に走る予定である車両Ｎｏまでを特定出来る。
【００３５】
次にバス運用DB１１から特定した車両Ｎｏ(111)「A100」、「B100」をもとにこの２車両がが一日の間に立ち寄る車両所Ｎｏ(1121,1131,11N1)を検索する。ここでバスがその日立ち寄る車両所Ｎｏを特定する理由は車両所Ｎｏが不明の場合、ポイント交換情報を配信したい車両が止まる車両所(特に夜間バッチを行う車両所)がわからないため、どの車両所にポイント交換情報の配信すれば良いか不明となり、全車両所にポイント交換情報を配信しなければならなくなるからである。その場合、バス車上ポイント交換システムと車両所を繋ぐネットワーク負荷とバス車両所のディスク容量が莫大なものとなるからである。車両所を特定することでポイント交換情報を配信したい車両が止まる車両所にポイント交換情報を配信することが出来、ネットワーク負荷とバス車両所のディスク容量の削減につながる。
【００３６】
次に実際の車両所の特定の仕方を以下に記す。まず上記で特定したバス車両Ｎｏ(111)「A100」をキーにバス車両No(111)を検索し該当レコードを参照する。するとバス車両Ｎｏ(111)「A100」はバス車両所(1121)「L001」を始発車両所にし路線Ｎｏ(1122)「305」として出発し、バス車両所(1131)「L002」に到着。次にバス車両所(1131)「L002」を路線Ｎｏ(1132)「306」として出発し(以下Ｎ回繰り返し)…のような１日のスケジュールであることがわかる。つまり車両No(111)「A100」が１日に立ち寄る車両所はバス車両所No(1121,1131)「L001」と「L002」であること、また始発車両所(1121)が「L001」であることがわかる。同様に車両No(111)「B100」もバス車両所No(1121,1131)「L002」「L003」に立ち寄り始発車両所が(1121)「L002」であることがわかる。
【００３７】
ここで始発車両所とはバスが前日の業務を終えてから翌朝発車するまで待機し夜間バッチ処理を受ける車両所を指す。そのため車両所の中でも始発車両所まで特定する必要がある。ここまでで顧客が指定した路線Ｎｏ(1122,1132)「305」と「306」からその路線Ｎｏとして走る予定のあるバス車両(111)「A100」、「B100」を特定、次にそのバス車両Ｎｏ(111)から、そのバスが止まる車両所(1121,1131)「L001」と「L002」、「L003」を特定、またその中でも特に「L001」と「L002」がバス「A100」、「B100」の夜間バッチを行う始発車両所であることまでわかる。ここでバス運用DB１１は車両NO(111)を主キーに、運用情報(111〜11N)という配列を、その日のスケジュール順に配置・連結する構造としているため、あえて「始発車両所フラグ」等のデータ項目を付加する事なく、自動的に運用情報(1)の車両所が始発車両所であるとわかる構造としている。このことによりデータ項目の削減と、始発車両所が必ず先頭に並んでいることによる始発車両所データ検索速度の高速化を図っている。複数の配信データ作成部(H05)は、交換情報DB１３から抽出した交換用通番(131)「00230046」のレコードからカードNo(132)「1001」と交換ポイント数(133)「78」、会員区分(134)「Gold」、車両所No(145〜147)「L001」「L002」「L003」、車両No(148,149)「A100」、「B100」を配布用DB１４に追加し格納する(ステップS009)。
【００３８】
次に配布用DB１４の交換用通番(141)「00230046」のレコードを車両所No(145〜147)「L001」、「L002」、「L003」のバス車両所に向けて配信する。ここで交換用通番とはWEB経由でポイント交換を受付け、交換情報DB１３にデータを格納する場合にバス車上ポイント交換システム１が付加するユニークキーである。
【００３９】
また夜間バッチを行う始発車両所だけでなく、バスが立ち寄る車両所にもデータを配信するのは後述する(ステップS012)〜(ステップS013)の車両が故障した場合の対応で、バスとバス車上ポイント交換システムとの直接通信量を減らすため、予めデータのバックアップ先として車両所を利用するためである(ステップS010)。
<バス車両所>
配布用DBで特定されるバス車両所(145〜147)「L001」、「L002」、「L003」のバス車両所システム２ではバス車上ポイント交換システム１から配布された配布用DB１４の情報を会員区分(144)でソートし車両所配布用DB（Gold）１５、車両所配布用DB（Silver）１６、車両所配布用DB（Bronze）１７に分類を行う。本実施例ではバス車両所システム２で分類するとしたが、これに限定されるものではなく、バス車上ポイント交換システム１で前以て変換しておいてもよい。
【００４０】
交換用通番(141)「00230046」のレコードは会員区分(144)「Gold」のため、車両所配布用DB（Gold）１５に格納する。この編成を持って夜間バッチは完了とする。
【００４１】
分類する意図としては配信する情報に優先度を付け優先度順に配信を行うためである。バスは車両故障や交通事情による交通遅延が多いため、バスがダイヤを優先するためバス車両所からのポイント情報を全て受信する前に発進する必要に迫られる事が多くなることを想定している。この場合ポイント交換情報が全て配信されるまでバスを発車させないということにするとダイヤ乱れが拡大する可能性が高まるため、ポイント交換情報が完全には配信出来ていなくても本発明では発車可能とする。また本発明では、このようなポイント交換情報の未配信を防ぐために、基本的に夜間に集中的にポイント交換情報各バスに配布するようにしているため、実際の運用ではポイント交換情報が配信されないことは少ない。優先度情報を付加し配布しているのは、本発明では可能性が少ないが、もし送れかった場合のことまで想定して被害を最小限に抑えるために利用頻度が高い顧客に優先的に情報配信する仕組みを提供するためである。また仕組みとしてポイント交換情報が完全に配信されるまでバスを発車させないということにすればバスのダイヤ乱れが発生する可能性がありますが、ポイント交換情報が送れないということと天秤にかけてどっちを優先するかはバス会社の方針に寄る(ステップS011)。バス車両所ではバス「A100」から送られてくる受信状態DB１９をもとに情報配信を行う。
【００４２】
まず受信状態DB１９に含まれている完了会員区分(192〜194)をもとに送信すべき車両所配布用DB（１５〜１７）の区分（GoldかSilverかBronzeか）を選択し、次に車両Ｎｏ(151,161,171)から車両所配布用DB（１５〜１７）の配信すべきレコードを決定する。具体的には受信状態DB１９の完了区分(192)(Gold)が「０」の場合は車両所配布用DB(Gold)１５、(Silver)１６、(Bronze)１７全て配信されていないとみなし、車両所配布用DB（Gold）１５、車両所配布用DB（Silver）１６、車両所配布用DB（Bronze）１７の順に配信を開始する。そして車両所配布用DB(Gold)１５の送信が完了した場合、バス「A100」の受信状態DB１９の完了会員区分(192)(Gold)を「１」に更新する。同様に他の完了会員区分(193,194)も情報配信が完了した場合に完了会員区分(192,193,194)を更新する。バスは車両所停車中、定期間隔でバス車両所に受信状態DB１９の車両Ｎｏ(191)「A100」、完了会員区分(192)(Gold)、完了会員区分(193) (Silver)、完了会員区分(194)(Bronze)を送信する。
【００４３】
バス車両所は上記でバスから送信された受信状態DB１９の車両NO(191)「A100」、完了会員区分(192〜194)(Gold)、(Silver)、(Bronze)をもとに送信可否を判断する。
【００４４】
つまりバスから送信された完了会員区分が「１」に更新されていた場合はその完了会員区分の車両所配布用DB（１５〜１７）は配信済みとして配信を行わない。車両所はバスに向けて交換用通番(152)「00230046」とカードNo(153)「1001」、交換ポイント数(154)「78」、交換済フラグ(156)「0」を送信する。バスでは受け取った情報を車上交換用DB１８に格納する(ステップS014)。
【００４５】
バスは定期間隔で受信状態DB１９の完了会員区分(192)(Gold)が更新されているかのチェックを行う。Goldだけをチェックする理由としては、本特許ではバスが発車可能状態に移行するのに必要な条件は会員区分「Gold」の会員向けのポイント交換情報をバスが受け取っていることなので、バスから見るとGoldを受け取り完了しているかどうかがだけが必要な情報だからであるからである。
【００４６】
ここでバス車上ポイント交換システム１で顧客がポイント交換を希望した路線Ｎｏだけでなく、車両Ｎｏまでバス車上ポイント交換システム１が特定しポイント交換情報を配信する意図を説明する。意図としては路線Ｎｏだけでなく、車両Ｎｏまで特定することで、路線Ｎｏで一括りにするのではなく、配信先である各バス１台１台に合わせたポイント交換情報を配信するためである。また、ではなぜ会員に車両Noでなく、路線Noを指定させるのかというと、会員は普通、バスに対しては路線Noまでしか知ることが出来ず、また実際どのバスでポイント交換するか分からないので、路線Noで指定するしかない。そのため本発明では会員が指定した路線Noの情報と日々のバス運用情報とを組み合わせて車両Noを特定するという処理を行う。車両Noを特定する処理の流れとしては、まずバス運用DB１１より車両Ｎｏ(111)「A100」は路線Ｎｏ(1122)「305」、路線Ｎｏ(1132)「306」の予定であり、「B100」は路線Ｎｏ(1122)「3」、路線Ｎｏ(1132)「306」の予定であることがわかる。このことから交換情報DB１３の路線No(137,138)「305」と「306」でポイント交換を希望している交換通番(131)「00230046」と「00230047」のレコードは夜間バッチでバス「A100」、「B100」に配信しておくことで後述する異常の場合以外は夜間バッチで全ての情報配信を完了させることが出来る。
【００４７】
逆に路線Noだけで情報配信をしようとすれば、時間帯やバス車両所に寄る度に路線Noが変化することが多いバスダイヤにおいて、路線No毎に情報配信することになるため、バスの路線Noが切り替わる度に、バス車上ポイント交換システム１から見ると全く別のバスに変化したように見え、夜間バッチだけでは情報配信完了できず、バス車両所からの情報配信を路線Noが切り替わる毎にやり直す必要がある。その場合、バス車両所に寄る度にバスと車両所間の通信が発生するため、車両所からバスへの情報配信失敗やそれに伴うバスダイヤの乱れが発生する可能性が高まる。
【００４８】
つまり路線Ｎｏでなく、バス車両Ｎｏとバス車両所Ｎｏまで特定することで、まずトラフィックの削減(バス車両所を特定することで夜間バッチを行う車両所と、バックアップ先として利用するバスが立ち寄る車両所への情報配信が可能となる)。次に情報配信失敗可能性の削減(バス車両を特定することで夜間バッチでの一括配信が可能となる)が可能となる。
【００４９】
ダイヤを優先するため、受信状態DB１９の完了会員区分 (Gold) (192)が「1」に更新されたのを以ってバス発進状態に移行する。つまり最低限完了会員区分(Gold) (192)のポイント交換情報が配信されていなければバスは発進出来ないが、完了会員区分(Silver) (193)や(Bronze) (194)はなくても発進は可能である(ステップS015)。
【００５０】
バス発進状態に移行したバスはその後ダイヤに従ってバス車両所を出発する。ここで配信出来なかったポイント交換情報の取り扱いについては(ステップS022)で説明を行う(ステップS016)。
【００５１】
上記の受信状態DB１９をもとに情報配信を行う処理はバスが1日の内に各バス車両所「L100」、「L101」、「L003」に立ち寄るたびに配信判断部(H10)が毎回行う(ステップS017)。
<バス車上>
バスでのポイント交換情報配信は、ポイント交換を予約した会員が乗車した場合、若しくは降車した場合にカードをＩＣカード読取機にかざした場合に行う。バスにあるバスシステム３のポイント処理部(H12)は、読み取ったカードＮｏ「1001」をと車上交換用DB１８のカードNo(182)「1001」を比較、対象レコードとして交換用通番(181)「00230046」のレコードを抽出し、交換ポイント数(183)「78」だけＳＦへのチャージを行う(ステップS018)。ここでＳＦとは金銭的価値をいい、好感ポイント数分の金銭的価値をＩＣカードに付与（例えば乗車運賃、電子マネー等）するものをいう。
【００５２】
チャージを行ったタイミングで車上交換用DB１８の交換用通番(131)「00230046」のレコードとチャージを受けたＩＣカード「1001」の交換済フラグを「1」に更新する。このことによって同じＩＣカード「1001」を持った会員が別のバス「B100」に乗車した場合のポイントの二重交換を防ぐことが出来る。
【００５３】
またバスはＩＣカードをかざし乗車した客のカードＮｏ「1001」を乗車顧客DB２０のカードNo (202)に格納する。ここでカードNoを乗車顧客DB２０に格納する理由としては、(ステップS022)にて後述するが、ポイント交換を希望し、該当する路線Noのバスに乗車したのにも関わらず、交換が行われなかった顧客がいなかったかどうか調査する場合に必要なデータだからである(ステップS019)。
<夜間バッチ>
営業終了後、バス「A100」はバス車両所「L100」に戻りバス車上ポイント交換システムと通信を行う。バス車上ポイント交換システムは乗車顧客DB２０のカードＮｏ(202)「1001」を読み取る(ステップS020)。この場合、バス車両所システムを経由して通信してもよく、これに限定されるものではない。
【００５４】
車上交換用DB２０の交換済みフラグ(184)が「1」に更新されている交換用通番(181)「00230046」のレコードの交換用通番(181)「00230046」を読み取り、交換情報DB１３の交換用通番(131)「00230046」のレコードを抽出し、交換完了フラグ(139)を「1」に更新する(ステップS021)。
【００５５】
次に配信漏れ顧客特定部(H08)は、ポイント交換を希望し且つ対象となる車両に乗車したのにも関わらずポイント交換が行われなかったレコードが存在するかどうかチェックを行う。具体的には乗車顧客DB２０の車両No(201)「A100」とカードNo(202)「1001」、交換情報DB１３の車両No「A100」とカードNo(132)「1001」とを比較し、交換完了フラグ(139)を「1」を参照する。ここでは交換完了フラグ(139)が「１」となっているため、乗車顧客にポイント付与が行われたことがわかる。
【００５６】
しかし、ここで交換用通番(131)「00230047」にて交換を希望したカードＮｏ(132)「1002」は車両No(201)「A100」の乗車顧客DB２０に格納されているにも関わらず、交換情報DB１３の交換用通番(131)「00230047」のレコードの交換完了フラグが「0」である。このことから交換を希望した顧客が乗車したのにも関わらずバス車上でポイント交換が行えなかったことがわかる。
【００５７】
上記のような処理とケースが発生する理由として(ステップS014)〜(ステップS016)においてGold会員の情報のみを持って発進するバスが発生する可能性があるため、通常業務の範囲内においてポイント交換情報の配信が出来ないケースが発生し得るからである。またこの処理によりポイント交換情報を配信出来なかった顧客のカードNo「1002」と交換用通番「00230047」を特定することが出来る(ステップS022)。 
上記(S022)の処理でポイント交換情報の配信が出来なかったカードＮｏ「1002」の顧客に対してはバス車上ポイント交換システムのWEB画面や会員情報DB１２のMail「456@abc」にお詫びの連絡を入れるなど対策を取る(ステップS023)。
【００５８】
バス車上ポイント交換システムは交換情報DB１３の交換完了フラグ(139)が「1」に更新された交換用通番(131)「00230046」のレコードについて、交換完了とみなし交換済データ削除部(H07)は、交換情報DB１３からレコードを削除する(ステップS024)。
【００５９】
交換情報DB１３の交換完了フラグ(139)が「1」に更新されないまま交換日付（終了）を過ぎたポイント交換情報については、未交換ポイント加算部(H09)として、交換希望ポイント分をポイント交換を希望した会員の保有ポイントへの加算を行う。ここで交換情報DB１３の交換用通番(131)「00230047」のレコードについて交換日付（終了）(136)「20110407」を過ぎても交換完了フラグ(139)が「1」に更新されない場合、交換ポイント数(133)「30」を保有ポイントへ加算を行う(ステップS025)。次に各バスとバス車両所の車両所配布用DB（１５〜１７）を全て削除し終了する(ステップS026)。
<異常処理>
基本的にポイント交換情報の配信は夜間バッチにてポイント管理サーバからバス車両所を通してバスに配信される。しかし、バスは他交通機関と違い交通事情により、ダイヤ乱れが発生し易いため事前に計画していなかったバス車両が運行する可能性がある。この場合夜間バッチでは予め計画されていた情報に従ってバスにポイント交換情報を配信しているため、予定外のバスには対応出来ない。具体的には車両所への到着が遅れているバス「A100」があった場合、代理として予備車両「C100」に路線No「305」と乗務員を割り振り発進させるケースや車両故障により予備車両を発進させるケースである。この場合予備車両には夜間バッチにてポイント交換情報が配信されていないため、(ステップS015)で記述した通り発進状態に移行出来ない。そのためダイヤ乱れ等により予備車両を使用する場合は事前に車両No読替登録部(H06)で処理を行っておく必要がある(ステップS012)。
【００６０】
車両No読替登録部(H06)の流れは以下である。バス車両所においてダイヤ乱れ等により予備車両「C100」を使用すると決定した場合、バス車両所からバス管理システムへ読替対象の車両No「C100」、「A100」を通達する。バス管理システムは車両読替DB２１に読替元車両Ｎｏ(211)「C100」と読替後車両Ｎｏ(212)「A100」を格納する。
【００６１】
バス管理システムは随時全バス車両所に車両読替DB２１を配信している。バス車両所は車両読替DB２１の替元車両Ｎｏ(211)「C100」と読替後車両Ｎｏ(212)「A100」を参照し、車両Ｎｏ読替部(H11)で処理を行う。車両Ｎｏ読替部(H11)では具体的には(ステップS014)でバスから送信されてくる受信状態DB１９の車両Ｎｏ(191)「C100」を車両読替DB２１に従って「A100」に読替る。
【００６２】
こうすることでバス車両所からみて予備車両「C100」はあたかも当初予定されていた車両「A100」のように見えるため、後は(ステップS014)で記述したように受信状態DB１９の内容に従ってポイント交換情報を配信する(ステップS013)。
【符号の説明】
【００６３】
１：バス車上ポイント交換システム、２：バス車両所システム、３：バスシステム、１１：バス運用データベース、１２：会員情報データベース、１３：交換情報データベース、１４：配布用データベース、１５：車両所配布用データベース、１８：車上交換データベース
【図１】
0005433675.tif 000002
【図２】
0005433675.tif 000003
【図３】
0005433675.tif 000004
【図４】
0005433675.tif 000005
【図５】
0005433675.tif 000006
【図６】
0005433675.tif 000007
【図７】
0005433675.tif 000008
【図８】
0005433675.tif 000009
【図９】
0005433675.tif 000010
【図１０】
0005433675.tif 000011
【図１１】
0005433675.tif 000012
【図１２】
0005433675.tif 000013
【図１３】
0005433675.tif 000014
【図１４】
0005433675.tif 000015