JP2004038576A - ユーザ管理システム、およびそのシステムを利用した乗車管理システム - Google Patents
ユーザ管理システム、およびそのシステムを利用した乗車管理システム Download PDFInfo
- Publication number
- JP2004038576A JP2004038576A JP2002195026A JP2002195026A JP2004038576A JP 2004038576 A JP2004038576 A JP 2004038576A JP 2002195026 A JP2002195026 A JP 2002195026A JP 2002195026 A JP2002195026 A JP 2002195026A JP 2004038576 A JP2004038576 A JP 2004038576A
- Authority
- JP
- Japan
- Prior art keywords
- user
- unit
- identification information
- pass
- path
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000009826 distribution Methods 0.000 claims abstract description 100
- 238000007726 management method Methods 0.000 claims description 104
- 238000000034 method Methods 0.000 claims description 41
- 230000005540 biological transmission Effects 0.000 claims description 10
- 230000010365 information processing Effects 0.000 claims description 10
- 238000001514 detection method Methods 0.000 claims description 6
- 238000012545 processing Methods 0.000 description 55
- 238000010586 diagram Methods 0.000 description 42
- 230000004048 modification Effects 0.000 description 22
- 238000012986 modification Methods 0.000 description 22
- 230000008569 process Effects 0.000 description 20
- 230000006870 function Effects 0.000 description 18
- 238000011835 investigation Methods 0.000 description 16
- 238000004364 calculation method Methods 0.000 description 11
- 238000000605 extraction Methods 0.000 description 10
- 230000001965 increasing effect Effects 0.000 description 9
- 238000011160 research Methods 0.000 description 9
- 230000000694 effects Effects 0.000 description 7
- 230000007423 decrease Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 4
- 230000015556 catabolic process Effects 0.000 description 3
- 238000009825 accumulation Methods 0.000 description 2
- 238000007792 addition Methods 0.000 description 2
- 230000003247 decreasing effect Effects 0.000 description 2
- 230000004069 differentiation Effects 0.000 description 2
- 230000003203 everyday effect Effects 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000007639 printing Methods 0.000 description 2
- 238000012797 qualification Methods 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 230000002123 temporal effect Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 235000014510 cooky Nutrition 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 239000006185 dispersion Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000001939 inductive effect Effects 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 235000012054 meals Nutrition 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 238000010187 selection method Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000029305 taxis Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Landscapes
- Devices For Checking Fares Or Tickets At Control Points (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】ユーザによる所定のサービスの利用を促進する。
【解決手段】配信装置６００は、ユーザに対応付けられた複数の識別情報を保持し、その一部を選択して第１端末装置６３０ａ、第２端末装置６３０ｂおよび第３端末装置６３０ｃに配信する。それらの端末装置６３０ａ、６３０ｂおよび６３０ｃは、例えばユーザが所持する会員カードに記録されている識別情報を読み込み、読み込んだ識別情報が配信装置６００から配信された識別情報に含まれているか否かを判定する。そして、含まれている場合に、当該ユーザ管理システム６５０はユーザにインセンティブを提供する。これにより、ユーザによる所定のサービスの利用を促進できる。
【選択図】 図１９
【解決手段】配信装置６００は、ユーザに対応付けられた複数の識別情報を保持し、その一部を選択して第１端末装置６３０ａ、第２端末装置６３０ｂおよび第３端末装置６３０ｃに配信する。それらの端末装置６３０ａ、６３０ｂおよび６３０ｃは、例えばユーザが所持する会員カードに記録されている識別情報を読み込み、読み込んだ識別情報が配信装置６００から配信された識別情報に含まれているか否かを判定する。そして、含まれている場合に、当該ユーザ管理システム６５０はユーザにインセンティブを提供する。これにより、ユーザによる所定のサービスの利用を促進できる。
【選択図】 図１９
Description
【０００１】
【発明の属する技術分野】
この発明は、情報管理技術に関する。この発明はとくに、ユーザにインセンティブを提供するシステムに関する。
【０００２】
【従来の技術】
取り扱う商品の種類や質で他業者との差別化が図りにくい現在、事業者は、他業者との差別化を顧客に対するサービスで見出そうとしている。顧客に対するサービスを充実するために、事業者はデータベースを利用して顧客情報を一元管理するようになった。これにより、事業者は顧客の住所や販売履歴などを管理でき、例えばダイレクトメール等の誘引活動に利用している。このような管理を行うために、ユーザごとに識別情報を割り当てる必要があり、その手段として識別情報を付した会員カードを配ることが一般に行われている。
【０００３】
【発明が解決しようとする課題】
会員カードには、例えば割り引きや購買額に応じたポイント加算など様々な特典が付与されている。このような特典により、事業者は他業者との差別化を図り顧客の拡大と継続的な来店を狙っている。このような顧客管理は、例えばクレジットカード会社、百貨店、被服販売店、電器量販店、レンタルビデオ店などの広い業種で行われている。また、鉄道などの交通機関においても、識別情報の付されたパスを利用して乗車管理を行うものがある。これらのカードやパスを使う事業者に共通することは、固定客の確保であり、そのためにカードやパスに付加する新たな特典を開発する必要がある。
【０００４】
本発明は、こうした点に鑑みてなされたものであり、その目的は、カードやパスの利用に伴い、利用者にインセンティブを与える技術を提供することにある。また、鉄道を移動手段としてホテルや美術館を利用する利用者、あるいは、ウェブ上のショッピングサイトを利用する利用者等に娯楽的要素を提供することにある。更には、利用者にとって利便性の高い乗車管理技術を提供することにある。更には、付加的なコストを必要とすることなしに、このようなシステムを構築する技術を提供することにある。更には、既存のインフラやサービスを現状のまま利用できるシステムを構築するための技術の提供にある。更には、パスの利用者数を増やすための技術を提供することにある。更には、地域経済の活性化を支援する技術を提供することにある。
【０００５】
【課題を解決するための手段】
本発明のある態様は、ユーザに対して所定のサービスを提供するユーザ管理システムである。このシステムは、配信装置と端末装置とを含み、前記配信装置は、複数のユーザにそれぞれ対応付けられた識別情報を保持する第１格納部と、前記第１格納部から所定の手順を経てユーザの識別情報を選択する選択部と、選択した識別情報を、前記端末装置に送信する送信部とを有し、前記端末装置は、前記送信部から識別情報を受信する受信部と、受信した識別情報を格納する第２格納部と、前記サービスの提供を受けるためにユーザが現れた場所にて、そのユーザの識別情報を読み取る読取部と、前記読み取った識別情報が前記第２格納部に含まれているか否かを判定する照合部と、照合結果に基づいてユーザにインセンティブを提供する提供部とを有する。
【０００６】
このシステムは、前記サービスの提供を受けるためにユーザが所定の媒体を提示したとき、この媒体に保持されているユーザの情報をそのユーザの識別情報として読み取り、前記サービスが提供される流れの中で前記インセンティブをユーザに提供する。この流れはユーザ自身が目的を持ち行動する中で自然とインセンティブが提供されるので、ユーザがインセンティブを得ることを特に意識する必要がない。また、既存のサービス、例えば交通機関における乗車管理システム、店舗で利用されているクレジットカード決済システムなどで使われているインフラストラクチャーを利用できるので、新たなコストの発生が少なく、普及が容易である。「媒体」は、例えば会員カードやパスなどである。「ユーザの情報」は、サービスの提供を受けるために必要な情報であり、そのサービスにおけるユーザの識別情報であるが、場合によっては氏名などであってよい。
【０００７】
「インセンティブ」は、例えば、金銭、金銭的価値を有するポイント、プレゼントなど有体、無体を問わずユーザにメリットを与えるものである。「端末装置」は、当該システムを利用する事業者の店舗、駅構内の改札装置、あるいは有料の美術館や無料の施設などに設置されており、専用の端末でもよいし、レジスターにその機能が設けられていてもよい。「ユーザの識別情報」は、例えばカードやパスに記載または記録されており、ユーザはそれらのカードを所持する。そして、例えば、商品購入時に、ユーザがカードを提示し、端末装置がカードに記録された識別情報を読取る。その作業はユーザ自身が操作してもよいし、店舗店員を介して行われてもよい。
【０００８】
「配信装置」は、ネットワーク上にひとつ設けられてもよいし、インセンティブを提供すべき識別情報の取り扱いに対応して複数設けられてもよい。複数の配信装置が設けられた場合、それらが識別情報を種類別に保持し、それぞれ識別情報の配信を行ってもよい。また、複数の配信装置が設けられ、かつそれらが同一の識別情報を保持する場合、それぞれ独立して識別情報の配信を行ってもよい。「第１格納部」は、例えば発行済みのカードやパスに付与した識別情報を全て保持する。「選択部」は、第１格納部から識別情報を選択するが、その選択方法はランダムに識別情報を選択してもよいし、ユーザの嗜好、購買履歴、乗車履歴などの個人情報に基づいて選択してもよい。また、端末装置ごとに配信する識別情報の数が予め設定されており、選択部は設定された数の識別情報を端末装置ごとに選択してもよい。さらに、選択部は所定のタイミングで選択処理を行ってもよい。例えば、そのタイミングは端末装置ごとに設定されていてもよく、毎日、毎週、毎月、所定期間毎、イベント開催日などの所定日に選択処理を行ってもよい。
【０００９】
「送信部」は、選択部の選択した識別情報を所定のタイミングで所定の端末装置に送信する。例えばそのタイミングは、端末装置を設置する店舗の営業時間外など識別情報の切替で支障が生じないことが好ましい。
【００１０】
「端末装置」は、例えば事業者の店舗に設置されたレジスターや来場者をチェックする入場装置、ネットワーク上で商品の販売などをするサーバである。
【００１１】
「受信部」は、識別情報の送信元である配信装置を認証する機能を有し、認証後に識別情報を受信してもよい。これにより、不正な識別情報の受信を防止できる。「第２格納部」は、前記受信部が受信した複数の識別情報を保持する。送信部が所定のタイミングで受信する度に前回保持した識別情報は全て消去して入替える。「読取部」は、ユーザーのカードまたはパスに記録された識別情報を読み取る磁気リーダー、半導体メモリリーダーであってよい。「照合部」は、取得部が取得したユーザの識別情報が第２格納部に保持されているか否かを判定する。「提供部」は、照合結果を例えばモニタに表示、紙に印刷、音声などによりユーザに通知する。
【００１２】
このシステムは、複数の端末装置を備え、前記選択部は、端末装置ごとに独立して前記第１格納部から識別情報を選択してもよい。「独立して」とは、端末装置ごとに新たに選択処理をすることをいい、例えば前回の選択結果を考慮せずに選択を行うことをいう。具体的には、選択部は、ある端末装置向けに選択した複数の識別情報を、他の端末装置に意図的に複製して配信するのではなく、端末装置ごとに毎回新たに選択処理を行う。
【００１３】
本発明の別の態様は、識別情報の付されたパスを利用する乗車管理システムである。このシステムは、駅構内に設けられた複数の改札装置と、前記改札装置に、発行済みのパスに付した識別情報を配信する配信装置とを備え、前記配信装置は、発行済みのパスの識別情報を保持する第１格納部と、前記第１格納部から識別情報を選択する選択部と、選択した識別情報を、駅構内に設けられた複数の改札装置の少なくとも１台に送信する送信部とを有し、前記改札装置は、ネットワークを介して前記識別情報を受信する受信部と、受信した識別情報を格納する第２格納部と、駅構内への入場または退場のために、ユーザが提示したパスに付与された識別情報を読み取る読取部と、読み取った識別情報が前記第２格納部に保持されているか否かを判定する照合部と、照合結果に基づいて、そのパスを所有するユーザにインセンティブを提供する提供部とを有する。
【００１４】
「選択部」は、ユーザの乗車履歴に基づいて、識別情報を選択してもよく、例えば所定の駅を多く利用しているユーザを優先的に選択してもよい。また、ユーザを所定の地域に誘導する目的で、その地域の店舗構成とユーザの嗜好が一致するユーザを優先的に選択してもよい。また、選択した識別情報に対応付けられたユーザに対して、その識別情報を保持する改札装置が設置された駅名もしくはヒントを通知する通知部を更に備えてもよい。「通知部」は、例えば移動体通信装置、電子メール、ホームページ、改札装置に設けられた表示部などを使ってユーザに通知してもよい。
【００１５】
本発明の別の態様も、ユーザ管理システムである。このシステムは、配信装置とウェブコンテンツを提供する情報処理装置とを含み、前記配信装置は、複数のユーザにそれぞれ対応付けられた識別情報を保持する第１格納部と、前記第１格納部から所定の手順を経てユーザの識別情報を選択する選択部と、選択した識別情報を、前記情報処理装置に送信する送信部とを有し、前記情報処理装置は、前記送信部から識別情報を受信する受信部と、受信した識別情報を格納する第２格納部と、ユーザからの要求に基づいて、前記ウェブコンテンツをそのユーザの閲覧装置に出力するページ出力部と、前記ウェブコンテンツの出力を検出する検出部と、前記検出部がウェブコンテンツの出力を検出した場合に、そのウェブコンテンツを要求したユーザの識別情報を読み取る読取部と、前記読み取った識別情報が前記第２格納部に含まれているか否かを判定する照合部と、照合結果に基づいてユーザにインセンティブを提供する提供部とを有する。
【００１６】
本発明の別の態様も、ユーザ管理システムである。このシステムは、ユーザに対応付けられた複数の第１識別情報を保持する第１格納部と、前記第１格納部から第１識別情報を選択する選択部と、選択した第１識別情報と、所定の場所に設置され、ユーザの第１識別情報を読み取る読取装置を特定する第２識別情報とを対応付けて保持する第２格納部と、ネットワークを介して、前記読取装置から第１識別情報と、第２識別情報とを取得する取得部と、取得した第１識別情報と第２識別情報との組み合わせが、前記第２格納部に保持されているか否かを判定する照合部と、照合結果に基づいてユーザにインセンティブを提供する提供部とを備える。これにより、第２格納部を読取装置ごとに設ける必要がない。
【００１７】
なお、以上の構成要素を任意に組合せ、本発明の表現を装置、方法、システム、コンピュータプログラムの間で変換したものもまた、本発明の態様として有効である。
【００１８】
【発明の実施の形態】
＜発券管理システム＞
図１は、発券管理システム５００の構成図である。本システム５００は、利用者に利便性豊かな交通機関の乗降システムを提供するために購入条件と乗車区間外運賃の支払い形態が異なる第１パス４２および第２パス４４を発券する。
【００１９】
第１パス４２は、予め乗車区間が設定された定期券としての役割と、乗車区間外での利用に際してはその都度の支払い処理、例えばプリペイド式やクレジットカードを使った決済処理を行う電子マネーとしての役割を併せ持つ。これにより乗車区間外の乗降でも新たに切符を購入する必要がないので、利用者にとって利便性の高いものとなる。第１パス４２を購入した利用者を第１利用者Ａという。
【００２０】
第２パス４４は、乗車区間が同じ定期券の価格に所定の追加料金αを加えた価格で販売され、有効期間内において乗車距離や乗降回数に応じた運賃の支払いなく交通機関を乗降可能とするパスである。これにより、利用者は第２パス４４の有効期間内であれば交通機関を利用する度に運賃を支払う必要がないので、色々な地域へ気軽に移動できる。第２パス４４を購入した利用者を第２利用者Ｂという。本システム５００は、主として第１パス４２の利用情報を第１利用者Ａごとに長期間に渡り蓄積し、その蓄積した情報に基づいて追加料金αを算出し、販売対象者を選択する構成と、第１利用者Ａおよび第２利用者Ｂによる地域事業者に対する消費活動を集計する構成を有する。
【００２１】
第１発券装置１６は、例えば、駅構内等に設置され、第１パス４２を不特定多数の購入希望者に発券する。その際、購入者の氏名や性別、年齢、住所等の個人情報を取得し、発券と同時に、その個人情報や定期券情報を第１管理装置１００に送信する。第２発券装置１８は、同じく駅構内に設置され、第２パス４４を発券する。第２パス４４の販売対象者は、第１パス４２の利用実績等により第１管理装置１００に選択された第１利用者Ａである。販売に際して、例えば「所定の期間内に所定の金額を事業者に対して消費しなければならない」といった条件を設定すれば、経済活動を活性化する効果をもたらす。第２パス４４を購入した第１利用者は購入日から第２利用者Ｂに登録されてもよいし、所定の日付から第２利用者Ｂに登録されてもよい。
【００２２】
乗車管理システム３０は、鉄道事業者毎に構築される乗車システム３０ａ、別の鉄道会社の乗車システム３０ｂと、駅毎に設けられた駅管理システム３２ａ、別の駅の駅管理システム３２ｂ、更に別の駅の駅管理システム３２ｃと、第２統括装置４０とを含む。駅管理システム３２ａは、入場側改札装置３４、退場側改札装置３６、および第１統括装置３８を有する。入場側改札装置３４は、第１パス４２または第２パス４４を所持した第１利用者Ａならびに第２利用者Ｂの入場を許可する。退場側改札装置３６は、乗車区間外運賃を含む利用情報を第１統括装置３８に送信する。第１統括装置３８は、駅構内に設けられた退場側改札装置３６から収集した利用情報を第２統括装置４０に送信する。第２統括装置４０は鉄道会社の路線上にある全ての駅から利用情報を収集する。第２統括装置４０は、この利用情報を第１管理装置１００に送信する。このような乗車管理システム３０ａは、鉄道会社毎に構築される。
【００２３】
第１管理装置１００は、鉄道会社毎に構築された乗車管理システム３０ａ、別の乗車管理システム３０ｂから収集した利用情報に基づいて追加料金αを算出する。また、第１管理装置１００は第２パス４４の販売対象者を第１パス４２の購入者の中から選択する。
【００２４】
事業者端末１４は、例えば、事業者の各店舗毎に設置され、第１パス４２または第２パス４４のデータを読み取り第２管理装置２００に送信する。「事業者」は、商店、映画館、美術館などである。「消費情報」は、商店で購入した商品の代金や役務、あるいは美術館や博物館など有料施設の入場料などに係わる情報である。第２管理装置２００は、事業者端末１４からその消費情報を収集する。
【００２５】
事業者は第１利用者Ａおよび第２利用者Ｂの消費に対して割り引きを行う。第１利用者Ａが行った消費に対しての割引金は、電子マネーとして第２管理装置２００にストックされる。そして、ストックされた電子マネーは、例えば第１利用者Ａが第２パス４４を購入するときに限り利用可能としてもよいし、第２パス４４パスの購入以外でも利用可能としてもよい。また、第２利用者Ｂは所定期間に所定金額を消費することが課せられているので、第２利用者Ｂの消費に対する割引率は特に所定期間の売り上げ総額に応じて逓増させることが可能である。事業者紹介装置１２は、例えばウェブ・ページを使い、第１利用者Ａまたは第２利用者Ｂの所持するＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｉｓｔａｎｔｓ）、携帯電話等の携帯情報端末に事業者店舗情報を提供し、事業者を紹介する。以上説明した図１の各装置や端末は有線や無線等を使って構築されたネットワーク１０を介して相互に通信可能である。
【００２６】
図２（ａ）は、第１パス４２と第２パス４４の概観とその構成図である。それぞれのパスの表面には印刷面４２４が設けられ、乗車区間、有効期間の末日、パス種類などが印刷されている。また、第１パス４２および第２パス４４は、データを格納する格納部４２０と、格納部４２０に対してデータの入出力を行う入出力部４２２とを有する。例えば、第１パス４２および第２パス４４はＩＣカードであってよく、入出力部４２２は図１の入場側改札装置３４、退場側改札装置３６に対して無線によりデータをやり取りしてもよいし、その他方法を利用してもよい。
【００２７】
図２（ｂ）は、第１パス４２の格納部４２０のデータ構造の一例を示す図である。パスＩＤ格納領域４３０は、当該パスを特定する識別情報（以下、これを「パスＩＤ」という）を保持する。パス種別格納領域４３２は、当該パスの種類、例えば、第１パスであることを指す情報を保持する。許諾情報格納領域４３４は、入場側改札装置３４及び退場側改札装置３６に対して、乗車区間外であっても入退場を許可することを指示する情報を保持する。精算種別格納領域４３６は、例えば、プリペイド決済、クレジットカード決済等の決済方法を指定する情報を保持する。精算用データ格納領域４３８は、精算に必要な情報、例えば、電子マネーの残高情報やクレジットカード番号等を保持する。
【００２８】
有効期間格納領域４４０は、当該パスの有効期間を保持する。乗車区間格納領域４２２は、利用者により指定された乗車区間に関する情報を保持する。例えば、乗車区間に関する情報は、利用者が主に利用する乗車駅と下車駅、及びその経路を含む。入場駅情報格納領域４４４および入場日時格納領域４４６は、入場時に入場側改札装置３４によって書き込まれ、入場駅情報格納領域４４４は入場駅を特定する情報を保持し、入場日時格納領域４４６は入場日時を保持する。
【００２９】
図２（ｃ）は、第２パス４４の格納部４２０のデータ構造の一例を示す図である。第２パス４４は、パスＩＤ格納領域４３０、パス種別格納領域４３２、許諾情報格納領域４３４、有効期間格納領域４４０、乗車区間格納領域４４２、入場駅情報格納領域４４４、入場日時格納領域４４６を有する。図２（ｂ）で説明した符号と同一の符号を付した格納領域はそれぞれ同様のデータを保持する。
【００３０】
図３は、図１の入場側改札装置３４の内部構成図である。入場側改札装置３４の各構成要素は、ハードウエアコンポーネントで言えば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされた処理プログラム、ネットワーク接続用インターフェースなどを中心に実現されるが、その実現方法、装置にはいろいろな変形例があることは、当事者には理解されるところである。これから説明する各図は、ハードウエア単位の構成ではなく、機能単位のブロックを示している。
【００３１】
取得部５２は、読出部５０を介して、第１パス４２または第２パス４４の格納部４２０から、入場を許可するか否かの判定に利用する情報、例えば有効期間、乗車区間、パス種類、許諾情報等を取得する。判定部５４は、取得部が取得したデータに基づいて入場を許可するか否かを判定する。ドア機構５６は、判定部５４の指示に基づいてドアの開閉を行う。通知部６６は、判定部５４による判定結果を利用者に、例えば画像や音声を使って通知する。入場駅コード格納部６４は、この入場側改札装置３４が設置されている駅を特定する駅識別情報（以下、これを「駅ＩＤ」といい、入場駅の駅ＩＤを「入場駅ＩＤ」という）を保持する。判定部５４が入場を許可した場合に、書込部６２は、その入場駅ＩＤと入場日時を第１パス４２または第２パス４４に書き込む。
【００３２】
図４は、入場側改札装置３４における入場判定処理のフローチャートである。まず、取得部５２は読出部５０を介して、入場許可判定に利用するデータを第１パス４２または第２パス４４から取得する（Ｓ１０）。次に判定部５４は、パスが有効期間内であるか否かを判定する（Ｓ１２）。パスが有効である場合（Ｓ１２のＹ）、判定部５４は、乗車区間内であるか否かを判定する（Ｓ１４）。乗車区間内である場合（Ｓ１４のＹ）、書込部６２は、入場日時と入場駅ＩＤをパスに書き込み（Ｓ１６）、判定部５４は、利用者の入場を許可する（Ｓ１８）。
【００３３】
Ｓ１２に戻り、有効期間外の場合（Ｓ１２のＮ）、通知部６６はその旨を利用者に通知し（Ｓ２４）、判定部５４は利用者の入場を拒否する（Ｓ２６）。Ｓ１４に戻り、乗車区間外の場合（Ｓ１４のＮ）、判定部５４は、許諾情報の有無を判定する（Ｓ１９）。許諾情報がある場合（Ｓ１９のＹ）、判定部５４は第１パス４２か否かを判定する（Ｓ２０）。そして、第１パス４２の場合（Ｓ２０のＹ）、乗車区間外運賃の精算が可能であるか否かを判定する（Ｓ２２）。精算可能の場合（Ｓ２２のＹ）、Ｓ１６に進む。この判定は、例えば、精算に使う電子マネーの残額があるか否かの判定である。
【００３４】
Ｓ１９に戻り、許諾情報がない場合（Ｓ１９のＮ）、通知部６６は入場できないことを利用者に通知し（Ｓ２４）、Ｓ２６に進む。Ｓ２０に戻り、第１パス４２でない、すなわち第２パス４４の場合（Ｓ２０のＮ）、Ｓ１６に進む。Ｓ２２に戻り、精算不可能の場合（Ｓ２２のＮ）、通知部６６はその旨を通知し（Ｓ２４）、Ｓ２６に進む。
【００３５】
図５は、図１の退場側改札装置３６の内部構成図である。取得部７２は、読出部７０を介して、第１パス４２または第２パス４４から必要な情報、例えば、パスＩＤ、パス種別、許諾情報、精算種別、精算用データ、乗車区間、入場駅ＩＤを取得する。判定部７４は、それらの情報に基づいて退場の可否判定を行う。ドア機構７６は、判定部７４の指示に基づいてドアの開閉を行う。通知部９０は、判定部７４による判定結果を利用者に通知する。
【００３６】
退場駅コード格納部８４は、この退場側改札装置３６が設置されている駅のＩＤ（以下、「退場駅ＩＤ」という）を保持する。算出部８０は、退場駅ＩＤおよび取得部７２によって取得された乗車区間、入場駅ＩＤに基づいて乗車区間外運賃を算出する。入場から退場までに複数の鉄道会社が関わる場合は乗車区間外運賃をそれぞれの鉄道会社別に算出する。精算部８２は精算種別として指定されている精算手段を使って乗車区間外運賃の精算処理を行う。例えば、精算種別としてプリペイド決済が指定されている場合、第１パス４２にストックされている電子マネーからその乗車区間外運賃を差し引く。送信部７８は、パスＩＤと乗車区間外運賃とを対応付けて利用情報として第１管理装置１００に送信する。消去部８６は、第１パス４２または第２パス４４に保持されている入場駅ＩＤおよび入場日時を消去する。
【００３７】
図６は、退場側改札装置３６における退場判定処理のフローチャートである。まず、取得部７２は読出部７０を介して第１パス４２または第２パス４４から、退場判定処理に必要な情報を取得する（Ｓ３０）。次に、判定部７４は、乗車区間外運賃が発生するか否かを判定する（Ｓ３２）。区間外運賃が発生した場合（Ｓ３２のＹ）、算出部８０は、乗車区間外運賃を算出する（Ｓ３４）。判定部７４は、第１パス４２か否かを判定する（Ｓ３６）。第１パス４２の場合（Ｓ３６のＹ）、その区間外運賃の精算が可能か否かを判定する（Ｓ４０）。
【００３８】
精算が可能な場合（Ｓ４０のＹ）、精算部８２は精算処理を行う（Ｓ４２）。そして、判定部７４は利用者の退場を許可する（Ｓ４４）。また、送信部７８は、利用情報を第１管理装置１００に送信する（Ｓ４６）。Ｓ４０で、精算が不可能な場合（Ｓ４０のＮ）、通知部９０はその旨を利用者に通知し（Ｓ４８）、判定部７４は、利用者の退場を拒否する（Ｓ５０）。Ｓ３２に戻り、乗車区間外運賃が発生しない場合（Ｓ３２のＮ）、Ｓ４４に進む。
【００３９】
Ｓ３６に戻り、第１パス４２でない、すなわち第２パス４４の場合（Ｓ３６のＮ）、判定部７４は、許諾情報の有無を判定する（Ｓ３８）。許諾情報が有る場合（Ｓ３８のＹ）、第２パス４４なので退場を許可する（Ｓ４４）。許諾情報がない場合（Ｓ３８のＮ）、Ｓ４８に進み、通知部９０は、退場出来ないことを利用者に通知する。
【００４０】
図７は、図１の第１管理装置１００の内部構成図と、図１の第２管理装置２００に設けられている事業者情報データベース２０６を示す図である。第１発券処理部１３０は、第１パス４２の発券にともない、図１の第１発券装置１６が第１パス４２を発券する際に取得した氏名等の個人情報を受信して個人情報データベース１２８に格納し、第１パス４２の乗車区間等のパスに係る情報をパス管理データベース１１４に格納する。
【００４１】
図８は、個人情報データベース１２８のデータ構造の一例である。利用者ＩＤ欄３５０は、利用者を特定する利用者識別情報（以下、「利用者ＩＤ」という）を保持する。この利用者ＩＤは、例えば、第１発券処理１３０が個人情報を個人情報データベース１２８に格納するときに、第１発券処理部１３０により自動的に生成される。氏名欄３５２は、利用者の氏名を保持する。生年月日欄３５４は、利用者の生年月日を保持する。性別欄３５６は、利用者の性別を保持する。休日欄３５８は、利用者の休日を保持する。パス種別欄３６０は、利用者のパスの種別を保持する。更新資格フラグ欄３６１は、第２パス４４の更新ができるか否かを示す情報を保持する。例えば、第２パス４４の購入条件である所定期間に所定金額を消費した場合に、更新できることを示す情報が書き込まれ、「１」は更新可能、「０」は更新不可能を意味する。具体的な例では、所定金額の８０％以上を消費した場合に更新可能とする。個人情報データベース１２８は、これらの情報以外に、利用者の住所や連絡先あるいは趣味など個人の情報を保持する。本図では、利用者ＩＤ「３６２５４３５」の利用者の氏名は、「ＪＪＫＫ」、生年月日は「１９７２年０２月０６日」、性別は「男性」、休日は「土、日曜日」、パス種別は「第１パス」であることがわかる。
【００４２】
図９は、パス管理データベース１１４のデータ構造の一例である。パスＩＤ欄３６２は、第１パス４２または第２パス４４のパスＩＤを保持する。このパスＩＤは、例えば、図１の第１発券装置１６または第２発券装置１８により自動的に生成されてもよいし、第１発券処理部１３０または後述する第２発券処理部１３２により生成されてもよい。利用者ＩＤ欄３６４は、前記個人情報データベース１２８に登録した利用者ＩＤと同じものを保持する。これにより、パス管理データベース１１４と個人情報データベース１２８とが連携する。
【００４３】
使用開始日欄３６６は、第１パス４２または第２パス４４の使用開始年月日を保持する。使用開始年月日は、購入日でもよいし、それぞれのパスが有効になる年月日でもよい。追加料金欄３６７は、追加料金を保持する。入場駅欄３６８は、乗車区間における一方の駅、例えば自宅側で入場する駅の駅ＩＤを保持する。退場駅欄３７０は、乗車区間における他方の駅、例えば目的地側で退場する駅の駅ＩＤを保持する。合計定期代金欄３７２は、鉄道会社毎の定期券代金の合計金額を保持する。定期券情報欄３７４は、乗車区間等に関する定期券情報を保持し、ある鉄道会社における定期券情報を保持する第１鉄道会社欄３７８ａと、他の鉄道会社における定期券情報を保持する第２鉄道会社欄３７８ｂと、更に別の鉄道会社における定期券情報を保持する第３鉄道会社欄３７８ｃを有する。これらの鉄道会社欄３７８は、乗車区間が複数の鉄道会社の路線にまたがる場合に会社毎に設けられる。
【００４４】
第１鉄道会社欄３７８ａは、鉄道会社名を保持する社名欄３７６ａ、乗車区間における自宅側の駅ＩＤを保持する会社別入場駅欄３７６ｂ、乗車区間における目的地側の駅ＩＤを保持する会社別退場駅欄３７６ｃ、会社別の乗車区間における定期券代金を保持する定期券代金欄３７６ｄ、および有効期間欄３７６ｅを有する。同様のデータが第２鉄道会社欄３７８ｂおよび第３鉄道会社欄３７８ｃにも設けられる。本図において、利用者ＩＤが「３６２５４３５」の利用者は、パスＩＤが「ＮＷＰ−１０００５２Ａ」のパスを保持し、乗車区間はＡ駅からＫ駅であり、合計定期券額は「５６０００円」であり、定期券の有効期間はＸ社の路線は「２００２／１２／５」でありＺ社の路線も「２００２／１２／５」であることがわかる。
【００４５】
図７の第１発券処理部１３０は、第１利用者Ａが乗車区間を変更した場合に利用者ＩＤを新しく生成してもよいし、利用者ＩＤは変えずに使用開始年月日を乗車区間を変更した日付に変えてもよい。各路線における定期券の有効期間はそれぞれ異なってもよいが、更新時のトラブルを少なくするために有効期間を統一することが好ましい。パス管理データベース１１４がこのようなデータ構造を有するので、利用者がパスを紛失した場合に、再びパスを発券できる。
【００４６】
図７に戻り、認証部１０６は、パスが利用可能であるか否かを判断する。例えば、認証部１０６は、乗車管理システム３０からパスＩＤを受信し、そのパスＩＤとパス管理データベース１１４に保持されているデータに基づいて、そのパスが利用可能であるか否かを判定し、その結果を乗車管理システム３０に通知する。保守部１１６は、利用者がパスを紛失した場合に、パス管理データベース１１４におけるパスＩＤと利用者ＩＤの対応関係を取り消す。これにより、パスを紛失した場合に本システムの管理者に届ける事で、第三者に勝手に利用されることを防止できる。
【００４７】
第１利用情報収集部１０２は、乗車管理システム３０から第１利用者Ａの利用情報を収集して第１利用情報データベース１１０に格納する。本実施の形態では、第１利用情報収集部１０２は、利用情報に含まれるパスＩＤに対応付けられた利用者ＩＤをパス管理データベース１１４から取得し、乗車区間外運賃などに対応付けて第１利用情報データベース１１０に格納する。
【００４８】
図１０は、第１利用情報データベース１１０のデータ構造の一例である。利用者ＩＤ欄３００は利用者ＩＤを保持する。区間外運賃欄３０２は、乗車区間外運賃を保持する。入場駅欄３０４は、入場駅ＩＤを保持する。入場日時欄３０６は、入場日時を保持する。退場駅欄３０８は、退場駅ＩＤを保持する。退場日時欄３１０は、退場日時を保持する。決済種別欄３１２は、乗車区間外運賃の決済方法、例えばクレジットカード決済、プリペイド決済等を指定する情報を保持する。決済フラグ欄３１４は、決済処理が完了しているか否かを示す情報を保持する。本実施の形態では、「０」は決済が完了していない状態を示し、「１」は決済が完了している状態を示す。図７の決済部１０８は、この決済フラグに基づいて、未決済状態の乗車区間外運賃の決済を、銀行やクレジットカード会社に対して行う。
【００４９】
鉄道会社内訳欄３１６は、鉄道会社毎の乗車区間外運賃を保持する。Ｘ社欄３１８ａはＸ鉄道会社の、Ｙ社欄３１８ｂはＹ鉄道会社の、Ｚ社欄３１８ｃはＺ鉄道会社の乗車区間外運賃をそれぞれ保持する。このような利用情報を長期に渡り蓄積することで、特定の利用者、性別、年齢、入場駅、退場駅、それらの組み合わせなどの様々な条件で利用情報を集計、分析が可能である。
【００５０】
図７に戻り、調査部１２４は第１管理装置１００の中心的役割を果たすために各種情報の収集、分析を行い、第２パス４４の発券枚数γや追加料金αの適正価格、および第２パス４４の販売対象者の利用者ＩＤを確定し、それぞれ発券枚数設定部１２６、価格算出部１２２、候補者抽出部１２０に送信する。また、発券履歴保存部１３４は、第２パス４４の発券履歴を保持し、例えば利用者ＩＤに対応付けて、発券年月日、発券駅、発券時間などの、調査部１２４が利用者ＩＤ別に第１パス４２の所持年数、第２パス４４の購入回数、期限切れから再購入までの期間などを分析するための情報を保持する。
【００５１】
調査部１２４は、例えば、「パス管理データベース１１４に保持されている第１パス４２の使用開始年月日から１年６ヶ月以上経過している利用者」や、「発券履歴保存部１３４の発券記録から前回購入から３年６ヶ月以上経過している利用者」や、「個人情報データベース１２８に保持されている生年月日が６０才以上の利用者」など所定の選択基準を設けて利用者を選抜し、候補者抽出部１２０に送信する。以下、調査部１２４が選抜した利用者を「選抜利用者」という。
【００５２】
候補者抽出部１２０は、選抜利用者毎に第１利用情報データベース１１０に保持されている利用情報を集計する。例えば、第２パス４４の発券開始日が２００４年０４月０１の場合、候補者抽出部１２０は、直前の一年間である「２００３年０４月０１日から２００４年０３月３１日」における年間乗車区間外運賃を選抜利用者別に抽出する。
【００５３】
図１１は、候補者抽出部１２０における抽出処理結果の一例を概念的に示す。利用者ＩＤ欄４１０は、選抜利用者の利用者ＩＤを保持する。最下段の総数欄４１４は、選抜利用者として選抜された利用者の総数ｇを保持する。区間外運賃集計欄４１２は、利用者ＩＤ毎に、年間乗車区間外運賃を昇順でソートして保持する。最下段にある区間外運賃総計欄４１６は、年間乗車区間外運賃の総額ｆを保持する。平均区間外運賃欄４１８は、年間の平均乗車区間外運賃Ａ１２を保持する。
【００５４】
この平均乗車区間外運賃Ａ１２は、
年間平均乗車区間外運賃Ａ１２＝区間外運賃総額ｆ／総数ｇ
で算出される。図７の候補者抽出部１２０は、こうして算出した「年間平均乗車区間外運賃Ａ１２」を価格算出部１２２に送信する。また、候補者抽出部１２０は、利用者ＩＤ欄４１０、および区間外運賃集計欄４１２に保持されているデータを選択処理部１３８に送信する。
【００５５】
価格算出部１２２は、追加料金αを「追加料金α＝固定額β＋増収額θ」になるように算出する。固定額βは、第１利用情報データベース１１０に保持されている利用情報に基づいて算出される。増収額θは、鉄道会社の増収成分と、追加料金αが常に同額になるように金額の調整を行う調整成分を有する額である。固定額βは、利用情報に基づいて算出するので、算出の時期、利用者数などの条件により変動する。そこで、この変動を抑え、追加料金αが一定金額になるように増収額θを設定する。これにより購入者に公平感を与えることが可能となる。
【００５６】
固定額βは、所定の基準を満たす第１利用者Ａによる平均的な乗車区間外運賃であり、第２パス４４の有効期間に応じて異なる。例えば、第２パス４４の有効期間が６ヶ月の場合、
【００５７】
固定額β＝年間平均乗車区間外運賃／２
とする。年間平均乗車区間外運賃は、各年毎に算出しそれを更に平均化してもよいし、第２パス４４を発券する前年の平均であってもよい。
【００５８】
追加料金αを長期間にわたって同一額にする公平性を提供する一方、候補者抽出部１２０が抽出した利用者ＩＤによっては、
（１）のケース 固定額β＞「年間の平均乗車区間外運賃（Ａ１２）／２」
（２）のケース 固定額β＜「年間の平均乗車区間外運賃（Ａ１２）／２」
となる場合もある。（１）のケースは、鉄道事業者の収益が増大し、（２）のケースは鉄道事業者の収益が減少することから、
【００５９】
（３）のケース 固定額β≒「年間の平均乗車区間外運賃（Ａ１２）／２」となるように、調査部１２４は選抜利用者を候補者抽出部１２０に送信することが望ましい。仮に、第２パス４４の発券回数に画一的な平等性を求める余り、特に（２）のケースが生じる場合は、発券間隔の見直し、例えば利用者ひとりにつき１０年間の発券回数が２回の場合、２年目と９年目や、５年目と７年目に購入機会を提供するなどして、（３）のケースになるように調整し鉄道事業者側への収益を優先させてもよい。
【００６０】
増収額θは、交通機関が第２パス４４を一枚発券する毎に対前年度比で売上げを向上させために固定額β、すなわち６ヶ月間の平均乗車区間外運賃Ａ６に上積みする額である。交通機関事業者は、契約率を向上するために、初期段階では増収額θを最低価格に設定し、第２パス４４を発券後に、図７の第２利用情報データベース１１２に蓄積される利用情報を分析することにより、後から増収額θを設定し直してもよい。
【００６１】
図７の駅情報データベース１１８は、路線上の各駅の改札数やプラットホームの広さ等で決まる許容人数、駅を日常的に利用する第１利用者Ａ、第２利用者Ｂ、その他一般利用者の乗降状況、駅を非日常的に利用する第１利用者Ａ、第２利用者Ｂの乗下車数を調査した実績数などの情報を保持する。事業者情報データベース２０６は、事業者の業種等と最寄り駅の情報とを対応付けて保持する。
【００６２】
調査部１２４は、発券枚数設定部１２６に指定する発券枚数γを確定する。その方法として、例えば調査部１２４は、調査時から所定期間中に有効期間が満了する第２パス４４を引き続き発券可能な枚数とし、その枚数と、駅情報データベース１１８および事業者情報データベース２０６を適宜利用して、駅の混雑状況、事業者毎の売上額、第２利用者Ｂの動向等を考慮して第２パス４４の発券枚数γを指定する。また、調査部１２４は年代別や性別や路線別に発券枚数γを指定してもよい。調査部１２４は、発券枚数γを発券枚数設定部１２６に供給する。発券枚数設定部１２６は、調査部１２４から発券枚数γを受け付けて、分散的に第２パス４４を配布する際の配布形態を選択処理部１３８に指示する。
【００６３】
図１２は発券枚数設定部１２６が作成した第２パス４４の配布表を示す。例えば、乗車区間外の利用が少ない第１利用者Ａ、または乗車区間外の利用が多い第１利用者Ａのいずれか一方に第２パス４４を販売するなどの偏りが生じる可能性がある。そこで、乗車区間外の利用状況を明確にし、偏りのない配布を行うために選択処理部１３８は、この配布表に基づいて選択処理を行う。区間外運賃範囲欄４５２は、乗車区間外運賃の範囲（以下、「運賃範囲」という）を保持する。本図では、運賃範囲を５００円ごとに設定する。グループ欄４５０は、運賃範囲毎のグループ名称を保持する。本図ではグループ名として「Ｇ０１」から「ＧＮ」が設定されている。利用者ＩＤ数欄４５４は、乗車区間外運賃が運賃範囲に属する第１利用者Ａの数を保持する。割当枚数欄４５６は、運賃範囲毎に割り当てられた第２パス４４の発券枚数を保持する。
【００６４】
図７の発券枚数設定部１２６は、合計値が発券枚数γになるように、それぞれの運賃範囲に割当枚数を設定する。発券枚数設定部１２６は、候補者抽出部１２０が抽出した第１利用者Ａの総数に対する発券枚数γの割合が、運賃範囲毎の利用者数に対する割当枚数の割合に等しくなるように割当枚数を設定してもよいし、鉄道事業者が任意に設定できてもよい、更に利用者の性別や年齢を考慮して割当枚数を設定してもよい。要は、候補者抽出部１２０が抽出した全ての第１利用者Ａからランダムに第２パス４４の販売対象者を選択することで平均乗車区間外運賃に偏りが生じないように、発券枚数設定部１２６は運賃範囲に相当する利用者数毎に第２パス４４の割当枚数を設定すればよい。
【００６５】
本図は、第１利用者Ａの総数が２５０万人、発券枚数γが５０万枚とする配布表である。グループ「Ｇ０１」は、運賃範囲が「０から５００円未満」に設定され、その運賃範囲に該当する利用者数は「１０万人」であり、割当枚数は「２万人」である。割当枚数は、運賃範囲に該当する利用者数との比率が、第１利用者Ａの総数と発券枚数γの比率「５：１」と等しくなるように設定される。発券枚数設定部１２６は、図１２の配布表を選択処理部１３８に送信する。
【００６６】
図７に戻り、選択処理部１３８は、配布表に基づいて第２パス４４の販売対象者を選択する。例えば、図１２のグループ「Ｇ３６」では、運賃範囲が「１７５００〜１８０００未満」の利用者ＩＤ数「９００００人」から割当枚数に相当する「１８０００人」分の販売対象者を選択する。選択処理部１３８は、乗車区間外運賃が運賃範囲に該当する第１利用者Ａの中からランダムに１８０００人を販売対象者として選択してもよいし、運賃範囲内で乗車区間外運賃の多い順に１８０００人を選択してもよい。選択処理部１３８は、それぞれのグループについて同様の選択処理を行い、販売対象者の利用者ＩＤを候補者データベース１４０に格納する。
【００６７】
図１３は、候補者データベース１４０のデータ構造の一例を示す図である。利用者ＩＤ欄３２０は、選択処理部１３８によって選択された第２パス４４の販売対象者の利用者ＩＤを保持している。パスＩＤ欄３２３は、パスＩＤを保持する。グループ欄３２１は、利用者が属する前述したグループ、例えば「Ｇ０１」から「ＧＮ」を保持する。通知タイミング欄３２２は、通知を行なう順番を指定する情報を保持する。例えば、「１」〜「１８３」を保持する。この１８３は第２パス４４の有効期間６ヶ月間の日数に相当する。これにより、段階的な発券処理が可能になる。販売期限欄３２４は、第２パス４４の販売期限を保持する。契約フラグ欄３２６は、第２パス４４を購入したか否かを示す情報を保持する。本図では、「１」は購入済みを意味し、「０」は販売通知を行なったが未契約状態を意味する。再選択フラグ欄３２８は、購入しなかった利用者ＩＤに替わって他の人を選択することを指定する情報を保持する。本図では、「１」は再選択の必要有を意味し、「０」は再選択不要を意味する。
【００６８】
図７に戻り、通知部１４２は、利用者ＩＤの氏名と住所を個人情報データベース１２８で検索して販売対象者である第１利用者Ａに通知する。通知情報には、第２パス４４の販売期限を含める。この通知方法は、例えば、ダイレクトメール等の紙媒体により行われてもよいし、電子メールや電話を使って行われてもよい。通知部１４２は、通知を行うとともに、図１３の候補者データベース１４０の販売期限欄３２４に、販売期限の年月日を書き込み、更に、契約フラグ欄には通知済み、すなわち販売開始を意味する「０」を書き込む。
【００６９】
販売状況監視部１３６は、候補者データベース１４０を常に監視しており、通知タイミング欄３２２に保持されている値に基づいて、関係する利用者宛てに通知を行うことを通知部１４２に指示する。また、販売状況監視部１３６は、図１３の販売期限欄３２４に保持した年月日の翌日以降に契約フラグ欄３２６に「０」が保持されている場合に、再選択フラグ欄３２８に、第２パス４４の購入を放棄したものと判定して「１」を格納する。図１３では、利用者ＩＤ「６５４３２１０」がそれに相当する。
【００７０】
販売状況監視部１３６は、候補者データベース１４０の再選択フラグ欄３２８に「１」が保持されている利用者ＩＤを選択処理部１３８に送信する。例えば、図１３の再選択フラグ欄３２８に「１」が保持されている利用者ＩＤ「６５４３２１０」に関するデータを送信すると同時に候補者データベース１４０から削除する。選択処理部１３８は、利用者ＩＤ「６５４３２１０」の利用者とグループが同じで、乗車区間外運賃の金額がほぼ等しい別の利用者を選択し、その利用者のＩＤを候補者データベース１４０に新たに格納する。
【００７１】
販売状況監視部１３６が、候補者データベース１４０を常時監視することで、再選択と再通知を繰り返し、図１２で割り当てた各グループの割当枚数を完売できる。その結果、第２パス４４を購入した第１利用者Ａの平均乗車区間外運賃と、選抜利用者に基づき候補者抽出部１２０が抽出した全ての第１利用者Ａの平均乗車区間外運賃はほぼ同額になり、全ての第１利用者Ａに第２パス４４を販売しなくても交通事業者に一定の収益増をもたらすことができる。
【００７２】
例えば、第１利用者Ａの総数が２５０万人で第２パス４４の発券枚数γが１００万枚、５０万枚、３０万枚、１０万枚の場合、発券枚数設定部１２６は、２５０対１００、２５０対５０、２５０対３０、２５０対１０の比率でグループ毎の割当枚数を算出する。そして、選択処理部１３８は、グループ毎に利用者を選択する。これにより、それぞれの発券枚数γの平均乗車区間外運賃を１００Ａ６、５０Ａ６、３０Ａ６、１０Ａ６とした場合、選択処理部１３８は、「２５０Ａ６≒１００Ａ６≒５０Ａ６≒３０Ａ６≒１０Ａ６」を満たすように販売対象者を選択することが可能となる。つまり、選択処理部１３８は、販売対象者の平均乗車区間外運賃が、全ての第１利用者Ａの平均乗車区間外運賃とほぼ等しくなるように選択する。ここで、調査部１２４は、第２パス４４の発券枚数γを闇雲に増大させるのではなく、混雑率と安全輸送に悪影響を来さない上限を発券枚数γに設定することが好ましい。
【００７３】
第２パス４４の販売枚数を効率よく拡大するためには、第２利用者Ｂが地域的、時間的に分散するように販売対象者を選択することが好ましい。例えば「地域的に分散」するとは特定の地域や駅あるいは路線に第２利用者Ｂの住所、職場等が集中しない事を意味する。このために選択処理部１３８は、パス管理データベース１１４と第１利用情報データベース１１０とに基づいて、利用者の入場駅や退場駅も考慮にいれて販売対象者を選択する。「時間的に分散」とは、第２利用者Ｂの出退勤時刻や出勤日が異なり同じ電車に集中しない事を意味している。このために選択処理部１３８は、パス管理データベース１１４と第１利用情報データベース１１０とに基づいて、利用者の休日や出退勤時刻も考慮にいれて販売対象者を選択する。
【００７４】
第１管理装置１００が有するデータベースは、それぞれユーザＩＤまたはパスＩＤにより連携されたリレーショナル・データベースであることが好ましい。選択処理部１３８は、それぞれのデータベースに保持されているデータを必要に応じてＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）などのデータベース処理言語を利用して検索できるので、販売対象者を様々な条件で選択することができる。選択処理部１３８は、例えば、前述のグループ毎に地域的、時間的な分散を考慮して販売対象者を選択してもよい。
【００７５】
次に、第２パス４４の発券と第２利用者Ｂの登録について説明する。通知部１４２から通知を受けた第１利用者Ａは第２パス４４を所定期日までに購入する権利を得る。その通知を受けた利用者は、駅に設置されている図１の第２発券装置１８に第１パス４２を提示する。第２発券装置１８は、第１パス４２に格納されているパスＩＤを第２発券処理部１３２に出力する。第２発券処理部１３２は、第２パス４４の発券が可能か否かをそのパスＩＤと候補者データベース１４０に保持されているデータとに基づいて判定し、その判定結果を第２発券装置１８に送信する。第２パス４４を発券した後、第２発券装置１８は、生成した第２パス４４のパスＩＤを第２発券処理部１３２に送信する。
【００７６】
第２発券処理部１３２は、既に個人情報データベース１２８に登録されているパス種別欄３６０の「第１パス」を「第２パス」に書き替え、パス管理データベース１１４の使用開始欄３６６を発券時点の年月日に書き替え、パスＩＤ欄３６２の第１パス４２のパスＩＤを新たに生成された第２パス４４のパスＩＤに書き換える。また、第２発券処理部１３２は、発券履歴保存部１３４に第２パス４４のパスＩＤと利用者ＩＤと発券年月日を送信する。
【００７７】
図９において、第２パス４４である「ＮＷＰ−２０００３３Ｂ」の鉄道会社毎の定期券の有効期間であるＹ１やＹ２が異なる場合は統一する方が好ましい。尚、図１３の候補者データベース１４０の通知タイミング欄３２２には、第１パス４２に格納された定期券の有効期間に関係無く通知順位を保持するので、第２パス発券装置１８は中途解約でない精算処理で有効期間を統合できることが好ましい。また、追加料金αは、パス毎に一律でなく異なってもよい。
【００７８】
図７に戻り、第２利用情報収集部１０４は、乗車管理システム３０から第２利用者Ｂの利用情報を収集して、第２利用情報データベース１１２に格納する。本実施の形態では、第２利用情報収集部１０４は、利用情報に含まれるパスＩＤに対応付けられている利用者ＩＤを、パス管理データベース１１４から取得し、乗車区間内運賃や乗車区間外運賃などに対応付けて第２利用情報データベース１１２に格納する。
【００７９】
図１４は、第２利用情報データベース１１２のデータ構造の一例である。利用者ＩＤ欄３３０は、利用者ＩＤを保持する。区間内運賃欄３３２は、乗車区間内の運賃を乗車の都度に支払う普通運賃で算出し保持する。区間外運賃欄３３４は、乗車区間外運賃を保持する。入場駅欄３３６は入場駅ＩＤを保持する。入場日時欄３３８は入場日時を保持する。退場駅欄３４０は退場駅ＩＤを保持する。退場日時欄３４２は退場日時を保持する。鉄道会社内訳欄３４４は、鉄道会社毎の乗車区間外運賃を保持する。Ｘ社欄３４６ａはＸ鉄道会社の、Ｙ社欄３４６ｂはＹ鉄道会社の乗車区間外運賃をそれぞれ保持する。このような利用情報を長期に渡り蓄積することで、特定の利用者、性別、年齢、入場駅、退場駅、それらの組み合わせなどの様々な条件で利用情報を集計、分析が可能である。
【００８０】
図７に戻り、分配部１４８は、図１４の鉄道会社内訳欄３４４に保持されているデータを各鉄道会社別に集計し、第２パス４４の販売価格である追加料金αと、後述する第２利用者Ｂが事業者に対して消費を行うことで変動する割引率により生じる金額の一部をそれぞれに比率配分する。調査部１２４は、前述の処理の他に、事業者の割引により生じる金額のうち鉄道会社毎に配分する額を決める。
【００８１】
本実施の形態では、第１利用者Ａが所定の地域に存在する事業者から商品や役務を購入する際に割引を受けることができる。販売額算出部１４６は、その割引金額を図１の第２管理装置２００から収集して、電子マネーとして利用者毎にストックする。そして、第２パス４４を購入する際に販売価格に充当する。第２発券処理部１３２は、充当後の価格を利用者に提示する。また、第２利用者Ｂの場合は所定期間に所定金額を消費することを契約条件に第２パス４４を発券する。その場合、事業者から消費する所定金額の一部を前納することも有り得る。
【００８２】
図１５は、図１の第２管理装置２００の内部構成図である。図１の各事業者に設置している事業者端末１４は、第１パス４２および第２パス４４のパスＩＤを図７の認証部１０６に送信しパスが利用可能であるか否かを確認する。消費情報収集部２０２は、パスの認証を終えた事業者端末１４から受け付けた第１利用者Ａまたは第２利用者Ｂの消費情報に利用者ＩＤを対応付けて、消費情報データベース２１０に格納する。
【００８３】
図１６は、消費情報データベース２１０のデータ構造の一例を示す。利用者ＩＤ欄３９２は、利用者ＩＤを保持する。パス種別欄３９４は、パス種別を保持する。事業者ＩＤ欄３９６は、利用者が商品や役務を購入した事業者を特定する識別情報（以下、「事業者ＩＤ」という）を保持する。消費日時欄３９８は、利用者が消費を行った日時を保持する。金額欄４００は、消費金額を保持する。品目欄４０２は、品目を保持する。例えば、このデータ構造から、利用者ＩＤが「３６２５４３５」の利用者は、第１パス４４の所有者であり、事業者「Ｓ０１２５４」で、２００２年１月１５日に食事のために５２００円の消費を行ったことがわかる。
【００８４】
図１５に戻り、前納金額情報データベース２０４は、第２パス４４の購入にともなって、第２利用者Ｂが前納金として予め納めた金額の一部を電子マネーとして保持する。前納金分配処理部２０８は、第２利用者Ｂが消費を行うたびに、その電子マネーから消費した金額の一部を差し引き、事業者に配分する。例えば、前納金額情報データベース２０４には、第２パス４４の購入条件とした所定の消費金額の半分が電子マネーとして予め保持されており、第２利用者Ｂが消費を行った場合、第２利用者Ｂはその場で消費金額の半分を支払い、前納金分配処理部２０８が、事業者端末１４からの消費情報に基づいて前納金額情報データベース２０４から残額を差し引いてよい。前納金分配処理部２０８は、電子マネーを事業者毎に蓄積し所定の期日毎に決済するが、その際、事業者毎に取り決めた所定の金額を差し引いて配分してもよい。
【００８５】
条件格納部２１８は、第２利用者Ｂに対する第２パス４４の利用条件を保持する。例えば、その利用条件は、所定の期間に消費すべき金額である。判定部２１６は、それぞれの第２利用者Ｂに対してその利用条件を満たしているか否かを判定する。通知部２１４は、条件を満たしていない第２利用者Ｂに対してその旨を通知する。
【００８６】
図１７は、事業者情報データベース２０６のデータ構造の一例を示す。事業者ＩＤ欄３８０は、事業者ＩＤを保持する。最寄駅欄３８２は、その事業者店舗の最寄駅の駅ＩＤを保持する。業種欄３８４は、事業者の業種を保持する。第１割引率欄３８６は、第１利用者Ａに対する割引率や第２利用者Ｂに課せられた所定の消費金額とは関係しない消費に対する割引率を保持する。例えば、図１５に戻って、消費額提供部２２２は、第１利用者Ａおよび第２利用者Ｂが第１割引率で消費した場合に、割引きした金額を図７の販売額算出部１４６に送信する。販売額算出部１４６は、利用者ＩＤ別にストック金額を保持し、第１利用者Ａあるいは第２利用者Ｂが第２パス４４を新規にあるいは継続して購入する場合に使用してもよい。第２割引率欄３８７は、第２利用者Ｂに課せられた所定の消費金額に関係する消費に対する割引率を保持する。総売上欄３８８は、第２利用者Ｂが第２割引率で消費した総売上を保持する。例えば、事業者はこの総売上に応じて第２割引率を変動させてもよいし、自動的に第２割引率を変動させる変動部（図示しない）を更に設けてもよい。住所欄３９０は、事業者の住所を保持する。図示しないが第１利用者Ａならびに第２利用者Ｂが第１割引率で消費した総売上を保持するフィールドを設けてもよいし、その他事業者に関する情報を保持してもよい。
【００８７】
図１５に戻り、事業者選択部２１２は、例えば、図７の第２利用情報データベース１１２から第２利用者Ｂが頻繁に利用している駅を抽出し、その駅周辺に存在する事業者の情報を事業者情報データベース２０６から取得する。そして、事業者選択部２１２は、その事業者の情報を通知部２１４に出力する。通知部２１４は、前述した消費条件を満たしていない第２利用者Ｂへの通知にその事業者を加えてもよい。これにより、第２利用者Ｂの消費を促すことができる。また、事業者選択部２１２は、消費情報データベース２１０からその利用者の嗜好を推定し、その嗜好にマッチした事業者を事業者情報データベース２０６から選択し、その情報を前述した通知に付加してもよい。
【００８８】
更新対象者選択部２２０は、例えば６ヶ月間有効な第２パス４４を一度だけ継続して所持することが可能な場合、一定の条件を満たした第２利用者Ｂを更新対象者として第１管理装置１００に通知する。仮に、所定金額を消費する所定期間を「第２パス４４の有効期間＋２ヶ月間」と設定した場合は第２パス４４の有効期間が切れる２週間前に消費金額の８０％を消費している利用者ＩＤを更新対象者として図７の通知部１４２に提供する。そして通知部１４２は、図８に示す個人情報データベース１２８の更新資格フラグ３６１を「１」に書き換える。消費金額の８０％を達成しないで第２パス４４の有効期間を過ぎた第２利用者Ｂは自動的に第１利用者Ａに移行する。その場合、交通機関ではなくインターネット・ショッピングなどで残額を消費できる環境を提供してもよい。しかし、最終期日までに当初の消費金額に達しなかった場合は、契約違反として前納金額情報データベース２０４の残金を使い必要な金額を精算する。例えば、この精算処理は前納金分配処理部２０８が行い、第２パス４４の有効期間中に使用した乗車区間外運賃が追加料金αを越えている場合は残額から補填し、乗車区間外運賃が追加料金α以下の場合は前納金額情報データベース２０４の残額を返還する処理を行ってもよい。
【００８９】
以上、識別情報を付したパスを利用した乗車管理システムを説明した。このシステム形態は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なことは当事者に理解されるところである。こうした変形例としては以下のものがある。
【００９０】
第１の変形例は、本システムを利用する交通機関に関する。実施の形態では、交通機関として鉄道を例に説明したが、交通機関は鉄道に限らず、バス、飛行機、船、レンタカー、レンタサイクル、タクシー、高速道路であってもよい。
【００９１】
第２の変形例は、図７の調査部１２４に関する。追加料金αの算出方法を前述したが、算出した追加料金αの妥当性を判断することが経営上必要になる。追加料金αの妥当性を単に、「追加料金α」と「乗車区間外運賃」とを比較して判断するのでは、第２パス４４には乗車区間が限定されていない点で正確さを欠く。そこで、調査部１２４は、第２利用情報データベース１１２が保持する乗車区間内運賃と乗車区間外運賃とに基づいて追加料金αの妥当性を判断する。第２パス４４による割引率Ｘは、「乗車区間内運賃Ｎ」、「乗車区間外運賃Ｔ」、「定期券代金Ｖ」、「追加料金α」から
【００９２】
割引率Ｘ＝｛１００−（Ｖ＋α）／（Ｎ＋Ｔ）×１００｝
の計算式で求められる。例えば、割引率Ｘが通常の定期券の割引率より少し高め程度なら追加料金αは妥当であると判断できる。このとき、割引率を利用者ＩＤごとに算出するのではなく、全ての第２利用者Ｂを対象に数年分の割引率の平均値を割引率としてもよい。そして、割引率が高すぎる場合は、追加料金αのひとつの成分である増収額θに一定額を上乗せし、妥当な追加料金αとしてもよい。
【００９３】
第３の変形例も図７の調査部１２４に関する。調査部１２４は、追加料金αを「世代別」に減額してもよい。調査部１２４は、割引率Ｘを世代別に算出し、仮に２０代の割引率を２０Ｘ、６０代の割引率を６０Ｘとしたとき、「２０Ｘ＞３０Ｘ＞４０Ｘ＞５０Ｘ＞６０Ｘ」のように、年齢が高くなるにつれて割引率が低くなる、すなわち乗車区間外の利用が少なくなるといった顕著な相関関係が有る場合は、年代別に追加料金αを減額してもよい。例えば上記の相関関係の場合は、減額値を２０代＝０円、３０代＝３００円、４０代＝６００円、５０代＝８００円、６０代＝１０００円などとして減額してもよい。これにより、第２パス４４の利用状況にあった価格を設定することができ、ひいては契約率を高めることができる。
【００９４】
第４の変形例も図７の調査部１２４に関する。調査部１２４は、追加料金αを「定期券代金別」に減額してもよい。調査部１２４は、割引率Ｘを定期券代金別に算出し、定期券代金が３万円未満の割引率を３Ｘ、定期券代金が２０万円未満の割引率を２０Ｘとしたとき、「３Ｘ＞５Ｘ＞８Ｘ＞１２Ｘ＞１６Ｘ＞２０Ｘ」のように、定期券代金が高くなるにつれて割引率が低くなる、すなわち乗車区間外の利用が少なくなるといった顕著な相関関係が有る場合は、乗車区間内が長くなるほど、すなわち定期券代金が高いほど追加料金から減額してもよい。
【００９５】
第５の変形例も図７の調査部１２４に関する。調査部１２４は、追加料金αを第３の変形例と第４の変形例で説明した減額方法を組み合わせて追加料金αを算出してもよい。
【００９６】
第６の変形例は、図１の入場側改札装置３４に関する。図１８は、他の形態における入場側改札装置３４の内部構成図である。この入場側改札装置３４は、図３で説明した入場側改札装置３４の構成に加えて、認証部５８とセンサ部６０とを更に含む。認証部５８は、センサ部６０から指紋や掌形、虹彩などの生体情報を取得し、その生態情報に基づいて認証を行う。これにより、認証部５８は、第１パス４２または第２パス４４が本人以外の第三者に使われているか否かを判定可能である。またこの場合、認証に必要な本人のデータを、第１パス４２や第２パス４４の格納部や個人情報データベース１２８に予め格納しておく。
【００９７】
この認証作業は、例えば、入場時に毎回行われてもよいし、一日に一度だけ行ってもよい。また、所定の確率に基づいて抜き打ちで認証を行ってもよい。この場合、他の入場側改札装置３４では認証処理を行わない可能性があるので、認証に失敗した時点で、そのパスを利用した入場を全て拒否することが好ましい。また、そのパスに対しては毎回認証処理を行ってもよい。更に認証を確率に基づいて行えば、認証は不定期になるので、一種のゲーム性を持たせてもよい。例えば、認証を受けたときにポイントを加算したり、景品をプレゼントしたりしてもよい。このような機能を退場側改札装置３６に設け、退場時に認証を行ってもよい。また、認証を行う確率を任意に設定できることが好ましく、例えば時間帯やイベント開催時などで変える。これにより、ラッシュ時には認証を行う確率を低くし、ラッシュ時間外では確率を高くすることができる。
【００９８】
第７の変形例も、第６の変形例と同様に認証に関する。パスに所有者の顔写真を印刷しておき、認証は有人改札で行うようにしてもよい。これを実現するために、入場側改札装置３４は、例えばランダムに入場を拒否し、有人改札での認証を促す。このとき、入場側改札装置３４はパスに入場拒否フラグを書き込む。そして、有人改札で駅員がパスに印刷した顔写真を参照して認証を行う。有人改札には、入場拒否フラグをパスから消去するための装置が設けられており、パスの利用者が本人である場合に、駅員はそのパスから入場拒否フラグを削除する。このときにも、ポイントの加算などユーザにインセンティブを提供してよい。
【００９９】
第８の変形例は、図７の調査部１２４と候補者抽出部１２０と選択処理部１３８に関する。調査部１２４は、第１利用情報データベース１１０に保持されているデータに基づいて、利用者の自宅側駅における主要な入退場時刻を推定し、利用者ＩＤと入場あるいは退場時刻とを対応付けて候補者抽出部１２０に送信し、選択処理部１３８は出勤時刻ならびに退勤時間が重ならないように、第２パス４４の販売対象者を選択してもよい。
【０１００】
第９の変形例は、第２パス４４の販売条件に関する。本システムは、第２パス４４により、利用者が交通機関を利用して自由に移動する手段を提供するとともに、その移動先となる地域経済を活性化することを一つの目的とする。地域経済の活性化を図るために、「所定期間に所定の金額を消費する」という条件を設定して第２パス４４を販売することとしたが、このような条件を設けなくてもよい。
【０１０１】
第１０の変形例は、第２パス４４の販売に関する。「所定の期間に所定の消費を行う」という販売条件を設定したが、その消費額は一定にするのではなく利用者毎に消費額を自由に設定してもよい。これにより、世代や性別その他それぞれの利用者のニーズにあった販売が可能になる。例えば、追加料金α＝０円にまで減額してもよい。
【０１０２】
第１１の変形例は、図７の通知部１４２に関する。第１利用者Ａに第２パス４４の購入対象者となったことを、電子メールや電話を使用するほかに、入場側改札装置３４の通知部６６あるいは退場側改札装置３６の通知部９０を活用して図７の通知部１４２の情報を通知してもよい。
【０１０３】
第１２の変形例は、第１パス４２および第２パス４４に関する。第１パス４２および第２パス４４は、予め乗車区間が設定され定期券としての役わりを有することとしたが、定期券のような乗車区間が設定されていなくてもよい。この場合、第１管理装置１００は、利用毎の運賃を蓄積し、その運賃に基づいて第２パス４４の価格を算出する。要は、第１パス４２を利用して、利用者の乗車傾向を分析し、それに基づいて第２パス４４の価格、販売方法を決定すれば、利便性の高い乗車券を提供できる。
【０１０４】
第１３の変形例は、図１２の各グループ毎の割当枚数に関する。同一の利用者が使用する乗車区間外運賃は各日、各週、各月、各年でばらつきが生じるのは当然のことであり、必然的に集計時期により属するグループが異なる。このことから、各グループの割当枚数に固執すれば長期的には公平な発券枚数を提供できなくなることが考えられる。図１２は所定の平均乗車区間外運賃を求めるための目安であるので、必要に応じて比率配分で確定した割当枚数または発券枚数γを増減させてもよい。要は、実際に第２パス４４を購入した利用者の平均乗車区間外運賃と候補者抽出部１２０で抽出した全ての第１利用者Ａの平均乗車区間外運賃がほぼ同額になればよい。
【０１０５】
第１４の変形例は、第２パス４４の契約率向上に関する。一般に乗車区間外運賃実績が高額の利用者の契約率や高く、低額の利用者の契約率は低いことが想定できるが、第１３の変形例に記述したケースや利用者の個人的事情により一様ではない。そこで、個人情報データベース１２８に希望フラグ欄を設け、例えば「１」は購入する意思を示し、「０」は購入する権利を留保する意思を示すなど、利用者が自由にフラグを書き換え可能としてもよい。そして、調査部１２４は、この情報を選抜利用者を確定する際の選択基準に加えてもよい。これにより、購入希望者を選択できるので契約率を向上できる。
【０１０６】
第１５の変形例は、第２パス４４に関する。通常、ひとり一人が乗車券を所持し改札装置を通過するが、第２パス４４を所持していれば、所持者とともに複数人が連続して改札装置を通過できるようにしてもよい（以下、この利用方法を「グループパス機能」という）。これにより、第２パス４４の所持者が家族や気の合う同行者とペアで気軽に利用することも可能となる。この場合、第２パス４４は、同時に利用できる人数（以下「同時利用者数」という）を保持する領域を利用者数格納領域として更に有する。入場側改札装置３４は、例えば、所定期間内、あるいは別のパス所持者が入場側改札装置を通過するまでの期間に改札を通過した人数をカウントし、カウント値を第２パス４４に格納する。そして退場側改札装置３６は、第２パス４４に保持されている入場人数と退場人数とを比較し、同数であることを確認し、かつその人数が同時利用者数以下であることを確認する。
【０１０７】
図３の入場側改札装置３４および図５の退場側改札装置３６は、利用者数格納領域から同時利用者数を読み取るユニットと、通過した人数をカウントするカウント部と、カウントした人数が同時利用者数以下で、かつ入退場時の人数が等しいか否かを判定するユニットとを備える。例えば、図３の取得部５２および図５の取得部７２が、第２パス４４から同時利用者数を読み取り、判定部５４および判定部７４がその判定を行ってもよい。また、入場側改札装置３４に乗車人員を申告する押しボタンを設け、利用者が入場時に操作することで意思の疎通を図ってもよい。グループパスの価格は第１パス４２の利用実績から確定できないが、基本的に第２パス４４の所持者と同行し乗車することが原則なので、第２パス４４の購入者の家族数などの申告により発行するなど所定の基準を設けることで新規の顧客を確保することが可能である。したがって、認証作業は第７の変形例で説明した認証を行うことが好ましい。そして、その認証の確率を高く設定し、認証回数に応じてポイントなどのインセンティブを提供するようにしてもよい。
【０１０８】
また、このグループパス機能を、予め設定した期間内であれば一日乗車券として利用可能な回数（以下「利用可能回数」という）を設定して使用できるようにしてもよい。この場合、第２パス４４は、グループパス機能を利用できる利用可能回数を保持する領域を利用回数格納領域として更に有する。そして、図３の入場側改札装置３４、または図５の退場側改札装置３６の少なくとも一方は、グループパス機能の利用可能回数をデクリメントするユニットを更に有する。いずれにしても、第２パス４４の利用者が単独で改札装置を通過する際は利用可能回数がデクリメントされることはなく、例えば、休日や夏休みなどに修学児童の体験学習として活用する機会を提供できる。このような目的でグループパス機能を提供する場合は、第１パス４２にも適用することが好ましいが、その場合、同時利用者数と利用可能回数に対してのみ同一価格とし、第１パス４２の所持者の乗車区間外運賃は常に実費で集計する。更に、第１パス４２および第２パス４４とは無関係に利用可能回数のみを有するグループパス機能（以下「観光パス」という）として、例えば、短期間滞在する外国人観光客に発行してもよい。これにより、乗車履歴を分析すれば、外国人観光者の人気スポットや目的地に達するまでの行動ルートから、より分かり易い観光案内書などを充実させることにも活用できるし、適正価格で利便性の高い観光パスを提供できる。
【０１０９】
第１６の変形例は、第１パス４２または第２パス４４の定期券部分に関する。一般に定期券は乗車区間内であれば乗降り自由であるが、予め決めた駅（以下、「指定駅」という）でのみ乗降りができる定期券（以下、「駅間限定定期券」という）を発行してもよい。これを第１パス４２とする場合、指定駅以外の利用は乗車区間外運賃として収集する。また、駅間限定定期券に一定金額を加えて通常の定期券として利用する場合でも、指定駅以外の利用を乗車区間外運賃として収集し、第２パス４４の追加料金の算出に利用してもよい。
【０１１０】
これを実現するために、第１パス４２または第２パス４４は、指定駅の駅ＩＤを保持する領域を指定駅ＩＤ格納領域として更に有する。そして、入場側改札装置３４および退場側改札装置３６は、その領域に保持されている駅でのみ乗降りを許可してもよい。このパスを、例えば事業者である企業と個人の要望で実現する通勤、通学専用の定期とし、通常の定期券より安い価格で提供してもよい。
【０１１１】
第１７の変形例は、第２パス４４に関する。第２パス４４の価格を「定期券の継続購入」と「追加料金＝平均的乗車区間外運賃＋事業者収益」を先払いすることで、乗車区間外運賃がかからず、乗り放題になるとしたが、「追加料金＝平均的乗車区間外運賃」に設定して、ユーザの乗車区間外運賃が、追加料金である平均的乗車区間外運賃より高くなった以降の乗車区間外運賃に対して所定の割り引き運賃を、その度に支払うようにしてもよい。この処理は、退場側改札装置３６が行う。例えば、第２パス４４を所定の金額で販売し、ユーザが先払いした平均的乗車区間外運賃より高くなるまで乗車し、それ以上の乗車区間外における利用に際して５０％割引きした金額をユーザが支払うようにしてもよい。また、「追加料金」で乗り放題とせずに、乗車区間外運賃に上限を例えば３０万円に設定し、その上限以上の利用に際しては、その度に乗車区間外運賃をユーザが支払うようにしてもよい。鉄道、バス、タクシーなど交通機関の種類や特徴に応じて、適切な支払い形態があるので、その事業者が支払形態を任意に設定できることが好ましい。
【０１１２】
＜ユーザ管理システム＞
上述した発券管理システム５００は、利用者の利便性を向上することのみならず、地域経済の活性化を支援できる。このシステムでは、識別情報の付されたパスを利用するが、そのパスを利用するごとにポイントの加算、プレゼントの抽選など、利用者にインセンティブと娯楽を提供することで利用者の拡大と、鉄道の利用を促すことができる。
【０１１３】
図１９は、こうした識別情報を利用したユーザ管理システムにおいてユーザにインセンティブを提供するユーザ管理システム６５０の構成図である。配信装置６００は、インセンティブを提供すべきユーザの識別情報（以下、「ユーザＩＤ」という）を、ネットワーク６５１を介して、複数の端末装置である第１端末装置６３０ａ、第２端末装置６３０ｂ、および第３端末装置６３０ｃに配信する。第１端末装置６３０ａは、配信装置６００からユーザＩＤを受信して保持する。そして、第１端末装置６３０ａを利用する利用者のユーザＩＤを取得して、インセンティブを提供すべきか否かを判定する。第１端末装置６３０ａは、例えば事業者の店舗に設置され、利用者の来店時に判定を行い、該当者にプレゼントを贈るなどのインセンティブを提供する。第２端末装置６３０ｂおよび第３端末装置６３０ｃはそれぞれ同一の構成および機能を有し、それぞれ独立して機能する。配信装置６００は、それぞれの端末装置に独立してインセンティブを提供すべきユーザＩＤを送信するので、利用者は第１端末装置６３０ａでプレゼントを獲得できなくても、第３端末装置６３０ｃでは獲得できることもありうる。このシステムにより、ユーザが店舗に立ち寄ることで娯楽的要素を提供できる。
【０１１４】
図２０は、図１９の配信装置６００の内部構成図である。サーバ側識別情報データベース６０２は、すべてのユーザＩＤを保持する第１格納部である。図２１にサーバ側データベース６０２のデータ構造の一例を示す。ユーザＩＤ欄６０２ａは、所定の事業者の会員カードに付与されたユーザＩＤを保持する。属性欄６０２ｂは、ユーザの属性である氏名、年齢、性別、住所、趣味等を保持する。例えば、この属性に基づいて、端末装置が設置されている店舗の顧客層に相応する利用者を選択することができる。他の例では、ユーザ属性は設けられていなくてもよい。図２０に戻り、配信先データベース６０８は、ユーザＩＤを送信する配信先を保持するデータベースである。
【０１１５】
図２２は、配信先データベース６０８のデータ構造の一例を示す。端末ＩＤ欄６０８ａは、サーバ側識別情報データベース６０２から選択したユーザＩＤの配信先となる端末装置の識別情報（以下「端末ＩＤ」という）を保持する。配信数欄６０８ｂは、選択するユーザＩＤの数を保持する。配信タイミング欄６０８ｃは、ユーザＩＤを配信する日時や期間など時間的タイミングを保持する。
【０１１６】
図２０に戻り、指示部６０６は、配信先データベース６０８に保持されているデータに基づいて、選択部６０４に所定のユーザＩＤ数を選択することを指示すると同時に、送信部６１０に、そのユーザＩＤの配信先となる端末ＩＤを指示する。選択部６０４は、指示部６０６の指示に基づいて選択処理を開始する。そして、送信部６１０は、指示部６０６に指示された配信先である端末ＩＤに、選択部６０４が選択したユーザＩＤを送信する。
【０１１７】
ここで、ユーザにインセンティブを提供する本ユーザ管理システムにおいては、複数の端末装置である第１端末装置６３０ａ、第２端末装置６３０ｂ、第３端末装置６３０ｃにユーザＩＤを配信した結果、Ａ氏のユーザＩＤとＢ氏のユーザＩＤとが、ほぼ同数配信されるという平等性を確保することが好ましい。また、第１端末装置６３０ａにはＡ氏のユーザＩＤが複数含まれるが、Ｂ氏のユーザＩＤは含まれないといった差別化を達成する配信結果が得られることが好ましい。したがって、必然的にサーバ側識別情報データベース６０２に保持しているユーザＩＤ総数ＴＵと、配信先データベース６０８の配信数欄６０８ｂに保持する配信数Ｈは、常に「ＴＵ＞Ｈ」の関係になる。しかし、配信数欄６０８ｂの配信数を合計した総計配信数ＴＨとの関係を「ＴＵ対ＴＨ」として比較すると「１対数百〜数千」になる程度に、端末装置の設置数と配信するユーザＩＤが増大することが予測される。
【０１１８】
指示部６０６は、例えば、配信先データベース６０８の、配信数欄６０８ｂに保持されている数のユーザＩＤの配信を、例えば上位の端末装置から順次処理する。次に、指示部６０６は、選択すべきユーザＩＤの数を選択部６０４に指示する。選択部６０４は、サーバ側識別情報データベース６０２に保持されているユーザＩＤを上位から順に、指示部６０６に指示された数だけ選択する。選択部６０４は、前記選択したユーザＩＤの次から引き続き下位方向に選択し、下位まで達した後は引き続き上位に戻る繰り返しを連続する。これにより、複数の端末装置には膨大な数のユーザＩＤが配信されるが、例えばＡ氏のユーザＩＤ数やＢ氏のユーザＩＤ数は、ほぼ同数配信されることになる。
【０１１９】
しかし、指示部６０６が、配信先データベース６０８の、配信数欄６０８ｂに保持されているユーザＩＤの配信数を一度に全部選択することを選択部６０４に指示すると、ひとつの端末装置にひとつのユーザＩＤしか含まれない可能性がある。したがって、指示部６０６は、一度に選択するユーザＩＤ数を、例えば、配信数欄６０８ｂに保持されている配信数から十分の一を選択するように、選択部６０４に指示すれば、可能性としては同一の端末装置にＡ氏のユーザＩＤが最大１０個含まれる可能性がでてくる。いずれにしても、Ａ氏のユーザＩＤが一つの端末装置に集中することと、より多くの端末装置に分散することはその達成度において対立する概念であるが両方を達成することが可能となる。
【０１２０】
更に、図２２の配信タイミング欄６０８ｃには毎日配信するユーザＩＤを更新して配信する場合がある。したがって、常に、同じパターンで配信することになり、例えば、図２１を用いて説明したサーバ側識別情報データベース６０２の、ユーザＩＤ欄６０２ａに保持しているＤ氏とＥ氏のユーザＩＤの配列が連続している場合、Ｄ氏とＥ氏のユーザＩＤはいつも同一の端末装置に含まれる可能性が高くなる。したがって、このような配信を防ぐために、指示部６０６が選択部６０４と送信部６１０に指示する前に、サーバ側識別情報データベース６０２、並びに、配信先データベース６０８のデータの並びを入れ替えることにより、毎回、別のパターンで配信することが可能となる。
【０１２１】
前記方法により、図２２の配信数欄６０８ｂの配信数の並びも変わるが、指示部６０６は、配信数を端末装置ごとにカウントし、カウントした合計が配信数欄６０８ｂに到達した場合には配信作業を停止するか、一時的に、配信先データベース６０８から削除するので、端末装置ごとに指定された数のユーザＩＤを配信できる。また、配信先データベース６０８の配信タイミング欄６０８ｃの配信日や配信時刻が区々の場合、指示部６０６は配信日を優先して選択部６０４に指示し、選択部６０４からユーザＩＤを受け付けた送信部６１０はユーザＩＤを配信時刻まで保持し、送信時刻に送信先となる端末装置に配信してもよい。これにより、例えば端末装置を管理する事業者の営業時間外に配信するという対応が可能となる。
【０１２２】
図２３は、図１９の第１端末装置６３０ａの内部構成図である。受信部６３２は、配信装置６００から複数のユーザＩＤを受信して、クライアント側識別情報データベース６３４に格納する。図２４は、クライアント側識別情報データベース６３４のデータ構造の一例を示す。ユーザＩＤ欄６３４ａは、受信部６３２が受信した複数のユーザＩＤを保持している。保持数欄６３４ｂは、同じく受信部６３２が受信したユーザＩＤのうち同一のユーザＩＤを合計して保持している。図２３に戻り、このクライアント側識別情報データベース６３４は、配信装置６００から所定のタイミングで受信する受信部６３２からのユーザＩＤを格納する前に、既に保持しているユーザＩＤを消去、あるいは、更新して新規に格納する。また、図示しないが、別の態様として、例えば、クライアント側識別情報データベース６３４−１とクライアント側識別情報データベース６３４−２のように複数の格納部を並列にセットし、瞬間的にそれらを切り替えることで、２４時間切れ間無く営業する事業者に対しても対応できる。また、受信部６３２は、ユーザＩＤを受信する前に配信装置６００の認証を行い、不正なユーザＩＤをクライアント側識別情報データベース６３４に格納することを防止してもよい。
【０１２３】
読取部６３８は、例えばカードリーダーであって、ユーザが保持する会員カードなどからユーザＩＤを読み込み、照合部６３６に出力する。照合部６３６は、読取部６３８が読み込んだユーザＩＤがクライアント側識別情報データベース６３４に格納されているか否かを判定する。格納されているユーザＩＤと読取部６３８が読み取ったユーザＩＤが一致した場合を、以下「当選」と表現する。提供部６４０は、その判定結果、すなわち、当選か否かをユーザに通知する。このように、当選と判定した場合、照合部６３６はユーザＩＤと、クライアント側識別情報データベース６３４の保持数欄６３４ｂが保持しているＩＤ数とを提供部６４０に供給する。例えば、ユーザが第１端末装置６３０ａを設置する事業者の店舗で商品を購入した時点で、照合部６３６が、照合を行い、その結果を提供部６４０に出力する。照合結果が当選の場合、提供部６４０は、購入金額並びに保持しているＩＤ数に応じて、事業者店舗が独自にインセンティブを提供してもよい。その場合、提供部６４０が当選したことをユーザに通知し、店員がプレゼントなどを直接手渡してもよい。いずれにしても、インセンティブとしては、ポイント、プレゼント、金銭など有体、無体を問わず事業者が任意に決められることが好ましい。
【０１２４】
本システムは複数の事業者が提携することで、ユーザにインセンティブを効果的に提供することをひとつの目的としていることから、更に、ユーザにインセンティブを提供する別の態様についても説明する。ユーザがあるホテルで宿泊をし、例えば、精算時にユーザが所持する所定のカードを、第１端末装置６３０ａに挿入すると、図２３の読取部６３８がユーザＩＤを読み取り、照合部６３６に出力する。照合部６３６が受信したユーザＩＤが、クライアント側識別情報データベース６３４に保持されているか否かを照合し、保持している場合は当選とし、一致するユーザＩＤ数を含めて提供部６４０に送信する。その際、提供部６４０は、ユーザが宿泊したホテルの支払い金額と保持するＩＤ数に応じて提供するポイント数を確定してもよい。しかし、ユーザへのインセンティブをその場で提供するのではなく、ユーザが獲得したポイントを蓄積するために、提供部６４０は、引き続き、配信装置６００にデータを送信する。
【０１２５】
図２０に戻り、引き続きユーザに提供するインセンティブについて説明する。管理部６１６は、第１端末装置６３０ａから送信されるデータを受領する。データは、例えば、ユーザＩＤと端末ＩＤとポイント数があればよく、そのデータを、ポイント蓄積部６１４に供給する。また、管理部６１６は、ポイント蓄積部６１４に保持されている例えば、第１端末装置６３０ａや第２端末装置６３０ｂなどが提供したポイント数を課金部６１２に供給する。さらに、管理部６１６は、ユーザＩＤ別に獲得ポイント数を管理し、課金部６１２が事業者から徴収した金額から、ユーザ個々にインセンティブとして提供する金額を計算し、ユーザの指定する銀行に振り込む。
【０１２６】
前記したように、管理部６１６に課せられた種々の目的を達成するために、例えば、管理部６１６が、第１端末装置６３０ａから受け付けるデータは、ポイントを獲得したユーザのユーザＩＤと獲得ポイント数、並びにそのポイントを提供した端末ＩＤとポイント数である。図２５は、ポイント蓄積部６１４のデータ構造を示す一例である。ユーザＩＤ欄６１４ａは、ユーザＩＤを保持する。獲得ポイント数欄６１４ｂは、ユーザＩＤに対応付けて獲得したポイント数をその都度に加算して保持する。また、端末ＩＤ欄６１４ｃは、第１端末装置６３０ａや第２端末情報６３０ｂなどに対応付けられた端末ＩＤである。提供ポイント数欄６１４ｄは、端末ＩＤがインセンティブとしてユーザに提供したポイント数をその都度に加算して保持する。このように、インセンティブとして、金銭的価値を有するポイントを獲得するユーザＩＤとポイントを提供する端末ＩＤとをその都度に対応付けて保持するので、獲得ポイント総数欄６１４ｅの獲得ポイント総数と提供ポイント総数欄６１４ｆ欄の提供ポイント総数は等しくなる。
【０１２７】
管理部６１６は、所定のタイミング、例えば、３ヶ月毎に第１端末装置６３０ａなどが提供したポイント数を、課金部６１２に送信する。課金部６１２は、第１端末装置６３０ａや第１端末装置６３０ｂなどを管理する事業者毎に課金額を請求する。また、管理部６１６は、別の請求、例えば、配信先データベース６０８に保持しているデータから第１端末装置６３０ａなどを管理する事業者にユーザＩＤの配信数と配信日数で計算した金額を課金部６１２に請求させてもよい。いずれにせよ課金方法はビジネスの形態により任意に設定できることが好ましい。
【０１２８】
管理部６１６は、ユーザにインセンティブを提供するために、１ポイントあたりの価格ＰＭを、課金部６１２が事業者から集めた金額の合計ＭＳと、図２５の獲得ポイント総数欄６１４ｅに保持されている全ユーザＩＤが獲得したポイント総数ＴＰとから、ＰＭ＝ＭＳ／ＴＰ（円／ポイント）として求めてもよい。こうして算出した１ポイントあたりの価格ＰＭと、同じくユーザＩＤ欄６１４ａに対応付けて、獲得ポイント数欄６１４ｂに保持されているユーザの獲得ポイントＵＰから、
【０１２９】
「インセンティブ（円）＝ＵＰ（ポイント）×ＰＭ（円／ポイント）」として算出してもよい。
【０１３０】
図２０に戻り、通知部６１８は、ユーザに対して、地域別、あるいは、複数のホテルなど競い合う事業者の端末装置に配信したユーザＩＤ数を、例えば携帯情報端末や電子メールなどを使って通知してもよい。これにより、ユーザが行きたい場所とインセンティブの基礎となるポイント獲得の可能性の両方を目安に行動する利用者を誘導することに活用できる。
【０１３１】
これらの装置を備えるユーザ管理システム６５０により、ユーザにインセンティブを提供できる。図１９のユーザ管理システム６５０では、配信装置６００は単体であるが、複数設けられていてもよい。例えば、ユーザＩＤの種類ごとに配信装置６００を設け、第１端末装置６３０ａや第２端末装置６３０ｂに種類の異なるユーザＩＤを配信してもよい。また別の態様としては、例えば、第１端末装置６３０ａを、更に配信装置６００に置き換えて配信する方法である。これは、本来、一つの端末装置に商店街の小さな店舗が配信先データベース６０８で契約するＩＤ数は少なく顧客誘導の効果が薄い場合に活用する。例えば、○○商店街が共同して顧客を誘導する戦略に活用できる。その他、デパートやショッピングモールや遊園地やテーマパークあるいは臨時的に一定期間主催されるお祭りやイベント会場などに配信装置６００を設置することで狭いエリア内でも確実に全利用者のユーザＩＤが配信されていることをアピールし顧客誘導することが可能となる。
【０１３２】
＜発券管理システム＞
図２６は、図１９のユーザ管理システム６５０を組み込んだ発券管理システム５００の構成図である。本図で、図１と同一の符号を付した構成は、図１で説明した同一の符号の構成と機能、および内部構成がほぼ同じである。異なる機能や構成について説明する。本図で、図１９の第１端末装置６３０ａに該当するのが、入場側改札装置３４、退場側改札装置３６、および事業者端末１４である。配信装置６００は、乗車管理システム３０および事業者端末１４に、第１パス４２ならびに第２パス４４の識別情報（以下、「パスＩＤ」という）を配信する。事業者端末１４は、図２３を用いて説明した第１端末装置６３０ａと同一の構成を有する。
【０１３３】
乗車管理システム３０ａは、鉄道会社の路線上の全駅を管理する管理システムである第２統括装置４０を有する。この第２統括装置４０の内部に、配信装置６００から最初に配信される複数のパスＩＤを受信して保持する第２分配部６５２を有する。駅管理システム３０ａは、複数の入場側改札装置３４および退場側改札装置３６を管理する管理システムである第１統括装置３８を有する。この第１統括装置３８の内部に、第２分配部６５２から配信される複数のパスＩＤを受信して保持する第１分配部６５４を有する。第１分配部６５４は、保持する複数のパスＩＤを入場側改札装置３４および退場側改札装置３６に順次に配分する。
【０１３４】
図２７は、入場側改札装置３４の内部構成図である。本図で、図３と同一の符号を付した構成は、図３で説明した同一の符号の構成と機能がほぼ同じである。異なる機能を有する構成について説明する。受信部６５６は、配信装置６００から配信されたパスＩＤを、第１統括装置３８を介して受信する。パスＩＤデータベース６５８は、受信したパスＩＤを保持する。判定部５４は、取得部５２が読出部５０を介して取得した第１パス４２または第２パス４４のパスＩＤを照合部６６０に出力する。照合部６６０は、判定部５４から供給されたパスＩＤがパスＩＤデータベース６５８に保持されているか否かを判定する。そして、含まれている場合を「当選」として、通知部６６はその旨をユーザに通知するとともに、提供部６６２は配信装置６００に提供するポイント数を送信する。図示しないが、退場側改札装置３６が図２７の入場側改札装置３４と同様の構成を有してもよい。
【０１３５】
他の例では、図２６の第１分配部６５４が改札装置に分配するときに、コピーして配分することで、配分前のパスＩＤを複数保持する格納部を有する。そして、図２７の照合部６６０は、受信したパスＩＤがパスＩＤデータベース６５８に保持されていない場合に、第１分配部６５４の格納部に保持されているパスＩＤに基づいて照合処理を行ってもよい。これにより、通過する改札装置で当選しなくても、駅全体に配信されているパスＩＤでは当選する確率を高くすることでインセンティブを提供する機会を増やすことが可能となる。このとき、照合に利用した上位格納部を入場側改札装置３４のパスＩＤデータベース６５８とし、下位格納部を第１分配部６５４として、上位か下位のいずれで当選したかにより、また、当選したパスＩＤの数により、ユーザが獲得できるポイント数を変えてもよい。これら、ユーザが獲得したポイント数を提供部６６２から配信装置６００に送信し、所定期間に獲得したポイント数に応じてインセンティブを提供してもよい。
【０１３６】
このように図１の発券管理システム５００に、ユーザ管理システム６５０を組み込むことで第１パス４２および第２パス４４が鉄道利用を拡大することが期待できる。また、パスＩＤの配信数を様々な駅の入場側改札装置３４または退場側改札装置３６で増減して配信することで、ユーザを所定の地域に誘導できる。
【０１３７】
＜ウェブサイトでの利用＞
ネットワーク上には、例えば商品の販売をするショッピングサイト、アンケートやクイズを提供するサイト、ニュースを提供するサイト、検索サイトなど、ユーザに所定のサービスを提供するウェブサイトが無数に存在し、ユーザを自らのウェブサイトに誘導することが事業者の課題になっている。図１９を用いて説明したユーザ管理システム６５０を導入することにより、ユーザをウェブサイトに誘導できる。
【０１３８】
図２８は、図１９のユーザ管理システム６５０に設けられた端末装置としての情報処理装置６７０の構成図である。本図において、図２３を用いて説明した構成と、同一の符号を付した構成は機能が同じである。機能が異なる構成について以下に説明する。ウェブページ格納部６７６は、ユーザに提供する例えばショッピング、ニュースなどのウェブページを格納する。ページ出力部６７４は、ユーザの指示に基づいてウェブページ格納部６７６からウェブページを読み出し、ユーザ端末に送信する。また、ページ出力部６７４は、送信したウェブページを特定する情報、ユーザ端末を特定する情報（以下、「装置ＩＤ」という）などを検出部６７２に出力する。「装置ＩＤ」は、例えば、ＩＰアドレス、ユーザが情報処理装置６７０に最初にアクセスしたときに個別に生成した特定情報などであってよい。例えば「個別に生成した特定情報」は、装置ＩＤとしてクッキーなどを利用してユーザ端末に格納され、ウェブページを要求する毎にページ出力部６７４に読み取られる。
【０１３９】
検出部６７２は、個々のユーザのアクセス状況を装置ＩＤに基づいて検出し、所定の状態になった場合に読取部６３８にユーザＩＤを取得することを指示する。検出部６７２は、ユーザがページのリンクを所定の回数辿った場合やユーザが所定のページに到達した場合に、例えば、一定量の広告を閲覧したと判断して、ユーザＩＤの取得と指示してもよい。ショッピングサイトにおいては、ユーザが商品の購入をした場合に取得を指示してもよい。
【０１４０】
読取部６３８は、検出部６７２から指示があった場合にユーザＩＤを要求する。この要求は、例えばユーザ端末にユーザＩＤの入力を要求する画面を表示させることで行ってよい。照合部６３６は、そのユーザＩＤに基づいて照合処理を行う。これにより、ウェブサイトにおいても、ユーザにインセンティブを提供できる。
【０１４１】
【発明の効果】
本発明によれば、ユーザインセンティブを提供し、利便性、娯楽性の高いユーザ管理技術を提供できる。
【図面の簡単な説明】
【図１】発券管理システムの構成図である。
【図２】図２（ａ）は、図１の第１パスおよび第２パスを説明するための図である。図２（ｂ）は、図１の第１パスが保持するデータ構造の一例である。図２（ｃ）は、図１の第２パスが保持するデータ構造の一例である。
【図３】図１の入場側改札装置の内部構成図である。
【図４】図３の入場側改札装置における入場処理のフローチャートである。
【図５】図１の退場側改札装置の内部構成図である。
【図６】図５の退場側改札装置における退場処理のフローチャートである。
【図７】図１の第１管理装置の内部構成図である。
【図８】図７の個人情報データベースのデータ構造の一例を示す図である。
【図９】図７のパス管理データベースのデータ構造の一例を示す図である。
【図１０】図７の第１利用情報データベースのデータ構造の一例を示す図である。
【図１１】図７の候補者抽出部における処理を説明するための図である。
【図１２】図７の発券枚数設定部により作成される第２パスの配布表の一例を示す図である。
【図１３】図７の候補者データベースのデータ構造の一例を示す図である。
【図１４】図７の第２利用情報データベースのデータ構造の一例を示す図である。
【図１５】図１の第２管理装置の内部構成図である。
【図１６】図１５の消費情報データベースのデータ構造の一例を示す図である。
【図１７】図１５の事業者情報データベースのデータ構造の一例を示す図である。
【図１８】図１の入場側改札装置の別の内部構成図である。
【図１９】実施の形態に係る、ユーザ管理システムの構成図である。
【図２０】図１９の配信装置の内部構成図である。
【図２１】図２０のサーバ側識別情報データベースのデータ構造の一例を示す図である。
【図２２】図２０の配信先データベースのデータ構造の一例を示す図である。
【図２３】図１９の第１端末装置の内部構成図である。
【図２４】図２３のクライアント側識別情報データベースのデータ構造の一例を示す図である。
【図２５】図２０のポイント蓄積部のデータ構造の一例を示す図である。
【図２６】配信装置を有する発券管理システムの構成図である。
【図２７】図２６の入場側改札装置の内部構成図である。
【図２８】図１９のユーザ管理システムに設けられる情報処理装置の内部構成図である。
【符号の説明】
１２ 事業者紹介装置、１４ 事業者端末、１６ 第１発券装置、１８ 第２発券装置、３４ 入場側改札装置、３６ 退場側改札装置、４２ 第１パス、４４ 第２パス、１００ 第１管理装置、１０２ 第１利用情報収集部、１０４ 第２利用情報収集部、１１０ 第１利用情報データベース、１１２ 第２利用情報データベース、１２０ 候補者抽出部、１２２ 価格算出部、１２６ 発券枚数設定部、１３０ 第１発券処理部、１３２ 第２発券処理部、１３４ 確定部、１３６ 販売状況監視部、１４２ 通知部、１４６ 販売額算出部、２００ 第２管理装置、２０２ 消費情報収集部、２０４ 前納金額情報データベース、２０６ 事業者情報データベース、２０８ 前納金分配処理部、２１０ 消費情報データベース、２１２ 事業者選択部、２１４ 通知部、２１６ 判定部、２１８ 条件格納部、５００ 発券管理システム、６００ 配信装置、６０２ サーバ側識別情報データベース、６０４ 選択部、６０６ 指示部、６０８ 配信先データベース、６３４ クライアント側識別情報データベース、６３６ 照合部、６４０ 提供部、６５０ ユーザ管理システム、６７０ 情報処理装置、６７２ 検出部。
【発明の属する技術分野】
この発明は、情報管理技術に関する。この発明はとくに、ユーザにインセンティブを提供するシステムに関する。
【０００２】
【従来の技術】
取り扱う商品の種類や質で他業者との差別化が図りにくい現在、事業者は、他業者との差別化を顧客に対するサービスで見出そうとしている。顧客に対するサービスを充実するために、事業者はデータベースを利用して顧客情報を一元管理するようになった。これにより、事業者は顧客の住所や販売履歴などを管理でき、例えばダイレクトメール等の誘引活動に利用している。このような管理を行うために、ユーザごとに識別情報を割り当てる必要があり、その手段として識別情報を付した会員カードを配ることが一般に行われている。
【０００３】
【発明が解決しようとする課題】
会員カードには、例えば割り引きや購買額に応じたポイント加算など様々な特典が付与されている。このような特典により、事業者は他業者との差別化を図り顧客の拡大と継続的な来店を狙っている。このような顧客管理は、例えばクレジットカード会社、百貨店、被服販売店、電器量販店、レンタルビデオ店などの広い業種で行われている。また、鉄道などの交通機関においても、識別情報の付されたパスを利用して乗車管理を行うものがある。これらのカードやパスを使う事業者に共通することは、固定客の確保であり、そのためにカードやパスに付加する新たな特典を開発する必要がある。
【０００４】
本発明は、こうした点に鑑みてなされたものであり、その目的は、カードやパスの利用に伴い、利用者にインセンティブを与える技術を提供することにある。また、鉄道を移動手段としてホテルや美術館を利用する利用者、あるいは、ウェブ上のショッピングサイトを利用する利用者等に娯楽的要素を提供することにある。更には、利用者にとって利便性の高い乗車管理技術を提供することにある。更には、付加的なコストを必要とすることなしに、このようなシステムを構築する技術を提供することにある。更には、既存のインフラやサービスを現状のまま利用できるシステムを構築するための技術の提供にある。更には、パスの利用者数を増やすための技術を提供することにある。更には、地域経済の活性化を支援する技術を提供することにある。
【０００５】
【課題を解決するための手段】
本発明のある態様は、ユーザに対して所定のサービスを提供するユーザ管理システムである。このシステムは、配信装置と端末装置とを含み、前記配信装置は、複数のユーザにそれぞれ対応付けられた識別情報を保持する第１格納部と、前記第１格納部から所定の手順を経てユーザの識別情報を選択する選択部と、選択した識別情報を、前記端末装置に送信する送信部とを有し、前記端末装置は、前記送信部から識別情報を受信する受信部と、受信した識別情報を格納する第２格納部と、前記サービスの提供を受けるためにユーザが現れた場所にて、そのユーザの識別情報を読み取る読取部と、前記読み取った識別情報が前記第２格納部に含まれているか否かを判定する照合部と、照合結果に基づいてユーザにインセンティブを提供する提供部とを有する。
【０００６】
このシステムは、前記サービスの提供を受けるためにユーザが所定の媒体を提示したとき、この媒体に保持されているユーザの情報をそのユーザの識別情報として読み取り、前記サービスが提供される流れの中で前記インセンティブをユーザに提供する。この流れはユーザ自身が目的を持ち行動する中で自然とインセンティブが提供されるので、ユーザがインセンティブを得ることを特に意識する必要がない。また、既存のサービス、例えば交通機関における乗車管理システム、店舗で利用されているクレジットカード決済システムなどで使われているインフラストラクチャーを利用できるので、新たなコストの発生が少なく、普及が容易である。「媒体」は、例えば会員カードやパスなどである。「ユーザの情報」は、サービスの提供を受けるために必要な情報であり、そのサービスにおけるユーザの識別情報であるが、場合によっては氏名などであってよい。
【０００７】
「インセンティブ」は、例えば、金銭、金銭的価値を有するポイント、プレゼントなど有体、無体を問わずユーザにメリットを与えるものである。「端末装置」は、当該システムを利用する事業者の店舗、駅構内の改札装置、あるいは有料の美術館や無料の施設などに設置されており、専用の端末でもよいし、レジスターにその機能が設けられていてもよい。「ユーザの識別情報」は、例えばカードやパスに記載または記録されており、ユーザはそれらのカードを所持する。そして、例えば、商品購入時に、ユーザがカードを提示し、端末装置がカードに記録された識別情報を読取る。その作業はユーザ自身が操作してもよいし、店舗店員を介して行われてもよい。
【０００８】
「配信装置」は、ネットワーク上にひとつ設けられてもよいし、インセンティブを提供すべき識別情報の取り扱いに対応して複数設けられてもよい。複数の配信装置が設けられた場合、それらが識別情報を種類別に保持し、それぞれ識別情報の配信を行ってもよい。また、複数の配信装置が設けられ、かつそれらが同一の識別情報を保持する場合、それぞれ独立して識別情報の配信を行ってもよい。「第１格納部」は、例えば発行済みのカードやパスに付与した識別情報を全て保持する。「選択部」は、第１格納部から識別情報を選択するが、その選択方法はランダムに識別情報を選択してもよいし、ユーザの嗜好、購買履歴、乗車履歴などの個人情報に基づいて選択してもよい。また、端末装置ごとに配信する識別情報の数が予め設定されており、選択部は設定された数の識別情報を端末装置ごとに選択してもよい。さらに、選択部は所定のタイミングで選択処理を行ってもよい。例えば、そのタイミングは端末装置ごとに設定されていてもよく、毎日、毎週、毎月、所定期間毎、イベント開催日などの所定日に選択処理を行ってもよい。
【０００９】
「送信部」は、選択部の選択した識別情報を所定のタイミングで所定の端末装置に送信する。例えばそのタイミングは、端末装置を設置する店舗の営業時間外など識別情報の切替で支障が生じないことが好ましい。
【００１０】
「端末装置」は、例えば事業者の店舗に設置されたレジスターや来場者をチェックする入場装置、ネットワーク上で商品の販売などをするサーバである。
【００１１】
「受信部」は、識別情報の送信元である配信装置を認証する機能を有し、認証後に識別情報を受信してもよい。これにより、不正な識別情報の受信を防止できる。「第２格納部」は、前記受信部が受信した複数の識別情報を保持する。送信部が所定のタイミングで受信する度に前回保持した識別情報は全て消去して入替える。「読取部」は、ユーザーのカードまたはパスに記録された識別情報を読み取る磁気リーダー、半導体メモリリーダーであってよい。「照合部」は、取得部が取得したユーザの識別情報が第２格納部に保持されているか否かを判定する。「提供部」は、照合結果を例えばモニタに表示、紙に印刷、音声などによりユーザに通知する。
【００１２】
このシステムは、複数の端末装置を備え、前記選択部は、端末装置ごとに独立して前記第１格納部から識別情報を選択してもよい。「独立して」とは、端末装置ごとに新たに選択処理をすることをいい、例えば前回の選択結果を考慮せずに選択を行うことをいう。具体的には、選択部は、ある端末装置向けに選択した複数の識別情報を、他の端末装置に意図的に複製して配信するのではなく、端末装置ごとに毎回新たに選択処理を行う。
【００１３】
本発明の別の態様は、識別情報の付されたパスを利用する乗車管理システムである。このシステムは、駅構内に設けられた複数の改札装置と、前記改札装置に、発行済みのパスに付した識別情報を配信する配信装置とを備え、前記配信装置は、発行済みのパスの識別情報を保持する第１格納部と、前記第１格納部から識別情報を選択する選択部と、選択した識別情報を、駅構内に設けられた複数の改札装置の少なくとも１台に送信する送信部とを有し、前記改札装置は、ネットワークを介して前記識別情報を受信する受信部と、受信した識別情報を格納する第２格納部と、駅構内への入場または退場のために、ユーザが提示したパスに付与された識別情報を読み取る読取部と、読み取った識別情報が前記第２格納部に保持されているか否かを判定する照合部と、照合結果に基づいて、そのパスを所有するユーザにインセンティブを提供する提供部とを有する。
【００１４】
「選択部」は、ユーザの乗車履歴に基づいて、識別情報を選択してもよく、例えば所定の駅を多く利用しているユーザを優先的に選択してもよい。また、ユーザを所定の地域に誘導する目的で、その地域の店舗構成とユーザの嗜好が一致するユーザを優先的に選択してもよい。また、選択した識別情報に対応付けられたユーザに対して、その識別情報を保持する改札装置が設置された駅名もしくはヒントを通知する通知部を更に備えてもよい。「通知部」は、例えば移動体通信装置、電子メール、ホームページ、改札装置に設けられた表示部などを使ってユーザに通知してもよい。
【００１５】
本発明の別の態様も、ユーザ管理システムである。このシステムは、配信装置とウェブコンテンツを提供する情報処理装置とを含み、前記配信装置は、複数のユーザにそれぞれ対応付けられた識別情報を保持する第１格納部と、前記第１格納部から所定の手順を経てユーザの識別情報を選択する選択部と、選択した識別情報を、前記情報処理装置に送信する送信部とを有し、前記情報処理装置は、前記送信部から識別情報を受信する受信部と、受信した識別情報を格納する第２格納部と、ユーザからの要求に基づいて、前記ウェブコンテンツをそのユーザの閲覧装置に出力するページ出力部と、前記ウェブコンテンツの出力を検出する検出部と、前記検出部がウェブコンテンツの出力を検出した場合に、そのウェブコンテンツを要求したユーザの識別情報を読み取る読取部と、前記読み取った識別情報が前記第２格納部に含まれているか否かを判定する照合部と、照合結果に基づいてユーザにインセンティブを提供する提供部とを有する。
【００１６】
本発明の別の態様も、ユーザ管理システムである。このシステムは、ユーザに対応付けられた複数の第１識別情報を保持する第１格納部と、前記第１格納部から第１識別情報を選択する選択部と、選択した第１識別情報と、所定の場所に設置され、ユーザの第１識別情報を読み取る読取装置を特定する第２識別情報とを対応付けて保持する第２格納部と、ネットワークを介して、前記読取装置から第１識別情報と、第２識別情報とを取得する取得部と、取得した第１識別情報と第２識別情報との組み合わせが、前記第２格納部に保持されているか否かを判定する照合部と、照合結果に基づいてユーザにインセンティブを提供する提供部とを備える。これにより、第２格納部を読取装置ごとに設ける必要がない。
【００１７】
なお、以上の構成要素を任意に組合せ、本発明の表現を装置、方法、システム、コンピュータプログラムの間で変換したものもまた、本発明の態様として有効である。
【００１８】
【発明の実施の形態】
＜発券管理システム＞
図１は、発券管理システム５００の構成図である。本システム５００は、利用者に利便性豊かな交通機関の乗降システムを提供するために購入条件と乗車区間外運賃の支払い形態が異なる第１パス４２および第２パス４４を発券する。
【００１９】
第１パス４２は、予め乗車区間が設定された定期券としての役割と、乗車区間外での利用に際してはその都度の支払い処理、例えばプリペイド式やクレジットカードを使った決済処理を行う電子マネーとしての役割を併せ持つ。これにより乗車区間外の乗降でも新たに切符を購入する必要がないので、利用者にとって利便性の高いものとなる。第１パス４２を購入した利用者を第１利用者Ａという。
【００２０】
第２パス４４は、乗車区間が同じ定期券の価格に所定の追加料金αを加えた価格で販売され、有効期間内において乗車距離や乗降回数に応じた運賃の支払いなく交通機関を乗降可能とするパスである。これにより、利用者は第２パス４４の有効期間内であれば交通機関を利用する度に運賃を支払う必要がないので、色々な地域へ気軽に移動できる。第２パス４４を購入した利用者を第２利用者Ｂという。本システム５００は、主として第１パス４２の利用情報を第１利用者Ａごとに長期間に渡り蓄積し、その蓄積した情報に基づいて追加料金αを算出し、販売対象者を選択する構成と、第１利用者Ａおよび第２利用者Ｂによる地域事業者に対する消費活動を集計する構成を有する。
【００２１】
第１発券装置１６は、例えば、駅構内等に設置され、第１パス４２を不特定多数の購入希望者に発券する。その際、購入者の氏名や性別、年齢、住所等の個人情報を取得し、発券と同時に、その個人情報や定期券情報を第１管理装置１００に送信する。第２発券装置１８は、同じく駅構内に設置され、第２パス４４を発券する。第２パス４４の販売対象者は、第１パス４２の利用実績等により第１管理装置１００に選択された第１利用者Ａである。販売に際して、例えば「所定の期間内に所定の金額を事業者に対して消費しなければならない」といった条件を設定すれば、経済活動を活性化する効果をもたらす。第２パス４４を購入した第１利用者は購入日から第２利用者Ｂに登録されてもよいし、所定の日付から第２利用者Ｂに登録されてもよい。
【００２２】
乗車管理システム３０は、鉄道事業者毎に構築される乗車システム３０ａ、別の鉄道会社の乗車システム３０ｂと、駅毎に設けられた駅管理システム３２ａ、別の駅の駅管理システム３２ｂ、更に別の駅の駅管理システム３２ｃと、第２統括装置４０とを含む。駅管理システム３２ａは、入場側改札装置３４、退場側改札装置３６、および第１統括装置３８を有する。入場側改札装置３４は、第１パス４２または第２パス４４を所持した第１利用者Ａならびに第２利用者Ｂの入場を許可する。退場側改札装置３６は、乗車区間外運賃を含む利用情報を第１統括装置３８に送信する。第１統括装置３８は、駅構内に設けられた退場側改札装置３６から収集した利用情報を第２統括装置４０に送信する。第２統括装置４０は鉄道会社の路線上にある全ての駅から利用情報を収集する。第２統括装置４０は、この利用情報を第１管理装置１００に送信する。このような乗車管理システム３０ａは、鉄道会社毎に構築される。
【００２３】
第１管理装置１００は、鉄道会社毎に構築された乗車管理システム３０ａ、別の乗車管理システム３０ｂから収集した利用情報に基づいて追加料金αを算出する。また、第１管理装置１００は第２パス４４の販売対象者を第１パス４２の購入者の中から選択する。
【００２４】
事業者端末１４は、例えば、事業者の各店舗毎に設置され、第１パス４２または第２パス４４のデータを読み取り第２管理装置２００に送信する。「事業者」は、商店、映画館、美術館などである。「消費情報」は、商店で購入した商品の代金や役務、あるいは美術館や博物館など有料施設の入場料などに係わる情報である。第２管理装置２００は、事業者端末１４からその消費情報を収集する。
【００２５】
事業者は第１利用者Ａおよび第２利用者Ｂの消費に対して割り引きを行う。第１利用者Ａが行った消費に対しての割引金は、電子マネーとして第２管理装置２００にストックされる。そして、ストックされた電子マネーは、例えば第１利用者Ａが第２パス４４を購入するときに限り利用可能としてもよいし、第２パス４４パスの購入以外でも利用可能としてもよい。また、第２利用者Ｂは所定期間に所定金額を消費することが課せられているので、第２利用者Ｂの消費に対する割引率は特に所定期間の売り上げ総額に応じて逓増させることが可能である。事業者紹介装置１２は、例えばウェブ・ページを使い、第１利用者Ａまたは第２利用者Ｂの所持するＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｉｓｔａｎｔｓ）、携帯電話等の携帯情報端末に事業者店舗情報を提供し、事業者を紹介する。以上説明した図１の各装置や端末は有線や無線等を使って構築されたネットワーク１０を介して相互に通信可能である。
【００２６】
図２（ａ）は、第１パス４２と第２パス４４の概観とその構成図である。それぞれのパスの表面には印刷面４２４が設けられ、乗車区間、有効期間の末日、パス種類などが印刷されている。また、第１パス４２および第２パス４４は、データを格納する格納部４２０と、格納部４２０に対してデータの入出力を行う入出力部４２２とを有する。例えば、第１パス４２および第２パス４４はＩＣカードであってよく、入出力部４２２は図１の入場側改札装置３４、退場側改札装置３６に対して無線によりデータをやり取りしてもよいし、その他方法を利用してもよい。
【００２７】
図２（ｂ）は、第１パス４２の格納部４２０のデータ構造の一例を示す図である。パスＩＤ格納領域４３０は、当該パスを特定する識別情報（以下、これを「パスＩＤ」という）を保持する。パス種別格納領域４３２は、当該パスの種類、例えば、第１パスであることを指す情報を保持する。許諾情報格納領域４３４は、入場側改札装置３４及び退場側改札装置３６に対して、乗車区間外であっても入退場を許可することを指示する情報を保持する。精算種別格納領域４３６は、例えば、プリペイド決済、クレジットカード決済等の決済方法を指定する情報を保持する。精算用データ格納領域４３８は、精算に必要な情報、例えば、電子マネーの残高情報やクレジットカード番号等を保持する。
【００２８】
有効期間格納領域４４０は、当該パスの有効期間を保持する。乗車区間格納領域４２２は、利用者により指定された乗車区間に関する情報を保持する。例えば、乗車区間に関する情報は、利用者が主に利用する乗車駅と下車駅、及びその経路を含む。入場駅情報格納領域４４４および入場日時格納領域４４６は、入場時に入場側改札装置３４によって書き込まれ、入場駅情報格納領域４４４は入場駅を特定する情報を保持し、入場日時格納領域４４６は入場日時を保持する。
【００２９】
図２（ｃ）は、第２パス４４の格納部４２０のデータ構造の一例を示す図である。第２パス４４は、パスＩＤ格納領域４３０、パス種別格納領域４３２、許諾情報格納領域４３４、有効期間格納領域４４０、乗車区間格納領域４４２、入場駅情報格納領域４４４、入場日時格納領域４４６を有する。図２（ｂ）で説明した符号と同一の符号を付した格納領域はそれぞれ同様のデータを保持する。
【００３０】
図３は、図１の入場側改札装置３４の内部構成図である。入場側改札装置３４の各構成要素は、ハードウエアコンポーネントで言えば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされた処理プログラム、ネットワーク接続用インターフェースなどを中心に実現されるが、その実現方法、装置にはいろいろな変形例があることは、当事者には理解されるところである。これから説明する各図は、ハードウエア単位の構成ではなく、機能単位のブロックを示している。
【００３１】
取得部５２は、読出部５０を介して、第１パス４２または第２パス４４の格納部４２０から、入場を許可するか否かの判定に利用する情報、例えば有効期間、乗車区間、パス種類、許諾情報等を取得する。判定部５４は、取得部が取得したデータに基づいて入場を許可するか否かを判定する。ドア機構５６は、判定部５４の指示に基づいてドアの開閉を行う。通知部６６は、判定部５４による判定結果を利用者に、例えば画像や音声を使って通知する。入場駅コード格納部６４は、この入場側改札装置３４が設置されている駅を特定する駅識別情報（以下、これを「駅ＩＤ」といい、入場駅の駅ＩＤを「入場駅ＩＤ」という）を保持する。判定部５４が入場を許可した場合に、書込部６２は、その入場駅ＩＤと入場日時を第１パス４２または第２パス４４に書き込む。
【００３２】
図４は、入場側改札装置３４における入場判定処理のフローチャートである。まず、取得部５２は読出部５０を介して、入場許可判定に利用するデータを第１パス４２または第２パス４４から取得する（Ｓ１０）。次に判定部５４は、パスが有効期間内であるか否かを判定する（Ｓ１２）。パスが有効である場合（Ｓ１２のＹ）、判定部５４は、乗車区間内であるか否かを判定する（Ｓ１４）。乗車区間内である場合（Ｓ１４のＹ）、書込部６２は、入場日時と入場駅ＩＤをパスに書き込み（Ｓ１６）、判定部５４は、利用者の入場を許可する（Ｓ１８）。
【００３３】
Ｓ１２に戻り、有効期間外の場合（Ｓ１２のＮ）、通知部６６はその旨を利用者に通知し（Ｓ２４）、判定部５４は利用者の入場を拒否する（Ｓ２６）。Ｓ１４に戻り、乗車区間外の場合（Ｓ１４のＮ）、判定部５４は、許諾情報の有無を判定する（Ｓ１９）。許諾情報がある場合（Ｓ１９のＹ）、判定部５４は第１パス４２か否かを判定する（Ｓ２０）。そして、第１パス４２の場合（Ｓ２０のＹ）、乗車区間外運賃の精算が可能であるか否かを判定する（Ｓ２２）。精算可能の場合（Ｓ２２のＹ）、Ｓ１６に進む。この判定は、例えば、精算に使う電子マネーの残額があるか否かの判定である。
【００３４】
Ｓ１９に戻り、許諾情報がない場合（Ｓ１９のＮ）、通知部６６は入場できないことを利用者に通知し（Ｓ２４）、Ｓ２６に進む。Ｓ２０に戻り、第１パス４２でない、すなわち第２パス４４の場合（Ｓ２０のＮ）、Ｓ１６に進む。Ｓ２２に戻り、精算不可能の場合（Ｓ２２のＮ）、通知部６６はその旨を通知し（Ｓ２４）、Ｓ２６に進む。
【００３５】
図５は、図１の退場側改札装置３６の内部構成図である。取得部７２は、読出部７０を介して、第１パス４２または第２パス４４から必要な情報、例えば、パスＩＤ、パス種別、許諾情報、精算種別、精算用データ、乗車区間、入場駅ＩＤを取得する。判定部７４は、それらの情報に基づいて退場の可否判定を行う。ドア機構７６は、判定部７４の指示に基づいてドアの開閉を行う。通知部９０は、判定部７４による判定結果を利用者に通知する。
【００３６】
退場駅コード格納部８４は、この退場側改札装置３６が設置されている駅のＩＤ（以下、「退場駅ＩＤ」という）を保持する。算出部８０は、退場駅ＩＤおよび取得部７２によって取得された乗車区間、入場駅ＩＤに基づいて乗車区間外運賃を算出する。入場から退場までに複数の鉄道会社が関わる場合は乗車区間外運賃をそれぞれの鉄道会社別に算出する。精算部８２は精算種別として指定されている精算手段を使って乗車区間外運賃の精算処理を行う。例えば、精算種別としてプリペイド決済が指定されている場合、第１パス４２にストックされている電子マネーからその乗車区間外運賃を差し引く。送信部７８は、パスＩＤと乗車区間外運賃とを対応付けて利用情報として第１管理装置１００に送信する。消去部８６は、第１パス４２または第２パス４４に保持されている入場駅ＩＤおよび入場日時を消去する。
【００３７】
図６は、退場側改札装置３６における退場判定処理のフローチャートである。まず、取得部７２は読出部７０を介して第１パス４２または第２パス４４から、退場判定処理に必要な情報を取得する（Ｓ３０）。次に、判定部７４は、乗車区間外運賃が発生するか否かを判定する（Ｓ３２）。区間外運賃が発生した場合（Ｓ３２のＹ）、算出部８０は、乗車区間外運賃を算出する（Ｓ３４）。判定部７４は、第１パス４２か否かを判定する（Ｓ３６）。第１パス４２の場合（Ｓ３６のＹ）、その区間外運賃の精算が可能か否かを判定する（Ｓ４０）。
【００３８】
精算が可能な場合（Ｓ４０のＹ）、精算部８２は精算処理を行う（Ｓ４２）。そして、判定部７４は利用者の退場を許可する（Ｓ４４）。また、送信部７８は、利用情報を第１管理装置１００に送信する（Ｓ４６）。Ｓ４０で、精算が不可能な場合（Ｓ４０のＮ）、通知部９０はその旨を利用者に通知し（Ｓ４８）、判定部７４は、利用者の退場を拒否する（Ｓ５０）。Ｓ３２に戻り、乗車区間外運賃が発生しない場合（Ｓ３２のＮ）、Ｓ４４に進む。
【００３９】
Ｓ３６に戻り、第１パス４２でない、すなわち第２パス４４の場合（Ｓ３６のＮ）、判定部７４は、許諾情報の有無を判定する（Ｓ３８）。許諾情報が有る場合（Ｓ３８のＹ）、第２パス４４なので退場を許可する（Ｓ４４）。許諾情報がない場合（Ｓ３８のＮ）、Ｓ４８に進み、通知部９０は、退場出来ないことを利用者に通知する。
【００４０】
図７は、図１の第１管理装置１００の内部構成図と、図１の第２管理装置２００に設けられている事業者情報データベース２０６を示す図である。第１発券処理部１３０は、第１パス４２の発券にともない、図１の第１発券装置１６が第１パス４２を発券する際に取得した氏名等の個人情報を受信して個人情報データベース１２８に格納し、第１パス４２の乗車区間等のパスに係る情報をパス管理データベース１１４に格納する。
【００４１】
図８は、個人情報データベース１２８のデータ構造の一例である。利用者ＩＤ欄３５０は、利用者を特定する利用者識別情報（以下、「利用者ＩＤ」という）を保持する。この利用者ＩＤは、例えば、第１発券処理１３０が個人情報を個人情報データベース１２８に格納するときに、第１発券処理部１３０により自動的に生成される。氏名欄３５２は、利用者の氏名を保持する。生年月日欄３５４は、利用者の生年月日を保持する。性別欄３５６は、利用者の性別を保持する。休日欄３５８は、利用者の休日を保持する。パス種別欄３６０は、利用者のパスの種別を保持する。更新資格フラグ欄３６１は、第２パス４４の更新ができるか否かを示す情報を保持する。例えば、第２パス４４の購入条件である所定期間に所定金額を消費した場合に、更新できることを示す情報が書き込まれ、「１」は更新可能、「０」は更新不可能を意味する。具体的な例では、所定金額の８０％以上を消費した場合に更新可能とする。個人情報データベース１２８は、これらの情報以外に、利用者の住所や連絡先あるいは趣味など個人の情報を保持する。本図では、利用者ＩＤ「３６２５４３５」の利用者の氏名は、「ＪＪＫＫ」、生年月日は「１９７２年０２月０６日」、性別は「男性」、休日は「土、日曜日」、パス種別は「第１パス」であることがわかる。
【００４２】
図９は、パス管理データベース１１４のデータ構造の一例である。パスＩＤ欄３６２は、第１パス４２または第２パス４４のパスＩＤを保持する。このパスＩＤは、例えば、図１の第１発券装置１６または第２発券装置１８により自動的に生成されてもよいし、第１発券処理部１３０または後述する第２発券処理部１３２により生成されてもよい。利用者ＩＤ欄３６４は、前記個人情報データベース１２８に登録した利用者ＩＤと同じものを保持する。これにより、パス管理データベース１１４と個人情報データベース１２８とが連携する。
【００４３】
使用開始日欄３６６は、第１パス４２または第２パス４４の使用開始年月日を保持する。使用開始年月日は、購入日でもよいし、それぞれのパスが有効になる年月日でもよい。追加料金欄３６７は、追加料金を保持する。入場駅欄３６８は、乗車区間における一方の駅、例えば自宅側で入場する駅の駅ＩＤを保持する。退場駅欄３７０は、乗車区間における他方の駅、例えば目的地側で退場する駅の駅ＩＤを保持する。合計定期代金欄３７２は、鉄道会社毎の定期券代金の合計金額を保持する。定期券情報欄３７４は、乗車区間等に関する定期券情報を保持し、ある鉄道会社における定期券情報を保持する第１鉄道会社欄３７８ａと、他の鉄道会社における定期券情報を保持する第２鉄道会社欄３７８ｂと、更に別の鉄道会社における定期券情報を保持する第３鉄道会社欄３７８ｃを有する。これらの鉄道会社欄３７８は、乗車区間が複数の鉄道会社の路線にまたがる場合に会社毎に設けられる。
【００４４】
第１鉄道会社欄３７８ａは、鉄道会社名を保持する社名欄３７６ａ、乗車区間における自宅側の駅ＩＤを保持する会社別入場駅欄３７６ｂ、乗車区間における目的地側の駅ＩＤを保持する会社別退場駅欄３７６ｃ、会社別の乗車区間における定期券代金を保持する定期券代金欄３７６ｄ、および有効期間欄３７６ｅを有する。同様のデータが第２鉄道会社欄３７８ｂおよび第３鉄道会社欄３７８ｃにも設けられる。本図において、利用者ＩＤが「３６２５４３５」の利用者は、パスＩＤが「ＮＷＰ−１０００５２Ａ」のパスを保持し、乗車区間はＡ駅からＫ駅であり、合計定期券額は「５６０００円」であり、定期券の有効期間はＸ社の路線は「２００２／１２／５」でありＺ社の路線も「２００２／１２／５」であることがわかる。
【００４５】
図７の第１発券処理部１３０は、第１利用者Ａが乗車区間を変更した場合に利用者ＩＤを新しく生成してもよいし、利用者ＩＤは変えずに使用開始年月日を乗車区間を変更した日付に変えてもよい。各路線における定期券の有効期間はそれぞれ異なってもよいが、更新時のトラブルを少なくするために有効期間を統一することが好ましい。パス管理データベース１１４がこのようなデータ構造を有するので、利用者がパスを紛失した場合に、再びパスを発券できる。
【００４６】
図７に戻り、認証部１０６は、パスが利用可能であるか否かを判断する。例えば、認証部１０６は、乗車管理システム３０からパスＩＤを受信し、そのパスＩＤとパス管理データベース１１４に保持されているデータに基づいて、そのパスが利用可能であるか否かを判定し、その結果を乗車管理システム３０に通知する。保守部１１６は、利用者がパスを紛失した場合に、パス管理データベース１１４におけるパスＩＤと利用者ＩＤの対応関係を取り消す。これにより、パスを紛失した場合に本システムの管理者に届ける事で、第三者に勝手に利用されることを防止できる。
【００４７】
第１利用情報収集部１０２は、乗車管理システム３０から第１利用者Ａの利用情報を収集して第１利用情報データベース１１０に格納する。本実施の形態では、第１利用情報収集部１０２は、利用情報に含まれるパスＩＤに対応付けられた利用者ＩＤをパス管理データベース１１４から取得し、乗車区間外運賃などに対応付けて第１利用情報データベース１１０に格納する。
【００４８】
図１０は、第１利用情報データベース１１０のデータ構造の一例である。利用者ＩＤ欄３００は利用者ＩＤを保持する。区間外運賃欄３０２は、乗車区間外運賃を保持する。入場駅欄３０４は、入場駅ＩＤを保持する。入場日時欄３０６は、入場日時を保持する。退場駅欄３０８は、退場駅ＩＤを保持する。退場日時欄３１０は、退場日時を保持する。決済種別欄３１２は、乗車区間外運賃の決済方法、例えばクレジットカード決済、プリペイド決済等を指定する情報を保持する。決済フラグ欄３１４は、決済処理が完了しているか否かを示す情報を保持する。本実施の形態では、「０」は決済が完了していない状態を示し、「１」は決済が完了している状態を示す。図７の決済部１０８は、この決済フラグに基づいて、未決済状態の乗車区間外運賃の決済を、銀行やクレジットカード会社に対して行う。
【００４９】
鉄道会社内訳欄３１６は、鉄道会社毎の乗車区間外運賃を保持する。Ｘ社欄３１８ａはＸ鉄道会社の、Ｙ社欄３１８ｂはＹ鉄道会社の、Ｚ社欄３１８ｃはＺ鉄道会社の乗車区間外運賃をそれぞれ保持する。このような利用情報を長期に渡り蓄積することで、特定の利用者、性別、年齢、入場駅、退場駅、それらの組み合わせなどの様々な条件で利用情報を集計、分析が可能である。
【００５０】
図７に戻り、調査部１２４は第１管理装置１００の中心的役割を果たすために各種情報の収集、分析を行い、第２パス４４の発券枚数γや追加料金αの適正価格、および第２パス４４の販売対象者の利用者ＩＤを確定し、それぞれ発券枚数設定部１２６、価格算出部１２２、候補者抽出部１２０に送信する。また、発券履歴保存部１３４は、第２パス４４の発券履歴を保持し、例えば利用者ＩＤに対応付けて、発券年月日、発券駅、発券時間などの、調査部１２４が利用者ＩＤ別に第１パス４２の所持年数、第２パス４４の購入回数、期限切れから再購入までの期間などを分析するための情報を保持する。
【００５１】
調査部１２４は、例えば、「パス管理データベース１１４に保持されている第１パス４２の使用開始年月日から１年６ヶ月以上経過している利用者」や、「発券履歴保存部１３４の発券記録から前回購入から３年６ヶ月以上経過している利用者」や、「個人情報データベース１２８に保持されている生年月日が６０才以上の利用者」など所定の選択基準を設けて利用者を選抜し、候補者抽出部１２０に送信する。以下、調査部１２４が選抜した利用者を「選抜利用者」という。
【００５２】
候補者抽出部１２０は、選抜利用者毎に第１利用情報データベース１１０に保持されている利用情報を集計する。例えば、第２パス４４の発券開始日が２００４年０４月０１の場合、候補者抽出部１２０は、直前の一年間である「２００３年０４月０１日から２００４年０３月３１日」における年間乗車区間外運賃を選抜利用者別に抽出する。
【００５３】
図１１は、候補者抽出部１２０における抽出処理結果の一例を概念的に示す。利用者ＩＤ欄４１０は、選抜利用者の利用者ＩＤを保持する。最下段の総数欄４１４は、選抜利用者として選抜された利用者の総数ｇを保持する。区間外運賃集計欄４１２は、利用者ＩＤ毎に、年間乗車区間外運賃を昇順でソートして保持する。最下段にある区間外運賃総計欄４１６は、年間乗車区間外運賃の総額ｆを保持する。平均区間外運賃欄４１８は、年間の平均乗車区間外運賃Ａ１２を保持する。
【００５４】
この平均乗車区間外運賃Ａ１２は、
年間平均乗車区間外運賃Ａ１２＝区間外運賃総額ｆ／総数ｇ
で算出される。図７の候補者抽出部１２０は、こうして算出した「年間平均乗車区間外運賃Ａ１２」を価格算出部１２２に送信する。また、候補者抽出部１２０は、利用者ＩＤ欄４１０、および区間外運賃集計欄４１２に保持されているデータを選択処理部１３８に送信する。
【００５５】
価格算出部１２２は、追加料金αを「追加料金α＝固定額β＋増収額θ」になるように算出する。固定額βは、第１利用情報データベース１１０に保持されている利用情報に基づいて算出される。増収額θは、鉄道会社の増収成分と、追加料金αが常に同額になるように金額の調整を行う調整成分を有する額である。固定額βは、利用情報に基づいて算出するので、算出の時期、利用者数などの条件により変動する。そこで、この変動を抑え、追加料金αが一定金額になるように増収額θを設定する。これにより購入者に公平感を与えることが可能となる。
【００５６】
固定額βは、所定の基準を満たす第１利用者Ａによる平均的な乗車区間外運賃であり、第２パス４４の有効期間に応じて異なる。例えば、第２パス４４の有効期間が６ヶ月の場合、
【００５７】
固定額β＝年間平均乗車区間外運賃／２
とする。年間平均乗車区間外運賃は、各年毎に算出しそれを更に平均化してもよいし、第２パス４４を発券する前年の平均であってもよい。
【００５８】
追加料金αを長期間にわたって同一額にする公平性を提供する一方、候補者抽出部１２０が抽出した利用者ＩＤによっては、
（１）のケース 固定額β＞「年間の平均乗車区間外運賃（Ａ１２）／２」
（２）のケース 固定額β＜「年間の平均乗車区間外運賃（Ａ１２）／２」
となる場合もある。（１）のケースは、鉄道事業者の収益が増大し、（２）のケースは鉄道事業者の収益が減少することから、
【００５９】
（３）のケース 固定額β≒「年間の平均乗車区間外運賃（Ａ１２）／２」となるように、調査部１２４は選抜利用者を候補者抽出部１２０に送信することが望ましい。仮に、第２パス４４の発券回数に画一的な平等性を求める余り、特に（２）のケースが生じる場合は、発券間隔の見直し、例えば利用者ひとりにつき１０年間の発券回数が２回の場合、２年目と９年目や、５年目と７年目に購入機会を提供するなどして、（３）のケースになるように調整し鉄道事業者側への収益を優先させてもよい。
【００６０】
増収額θは、交通機関が第２パス４４を一枚発券する毎に対前年度比で売上げを向上させために固定額β、すなわち６ヶ月間の平均乗車区間外運賃Ａ６に上積みする額である。交通機関事業者は、契約率を向上するために、初期段階では増収額θを最低価格に設定し、第２パス４４を発券後に、図７の第２利用情報データベース１１２に蓄積される利用情報を分析することにより、後から増収額θを設定し直してもよい。
【００６１】
図７の駅情報データベース１１８は、路線上の各駅の改札数やプラットホームの広さ等で決まる許容人数、駅を日常的に利用する第１利用者Ａ、第２利用者Ｂ、その他一般利用者の乗降状況、駅を非日常的に利用する第１利用者Ａ、第２利用者Ｂの乗下車数を調査した実績数などの情報を保持する。事業者情報データベース２０６は、事業者の業種等と最寄り駅の情報とを対応付けて保持する。
【００６２】
調査部１２４は、発券枚数設定部１２６に指定する発券枚数γを確定する。その方法として、例えば調査部１２４は、調査時から所定期間中に有効期間が満了する第２パス４４を引き続き発券可能な枚数とし、その枚数と、駅情報データベース１１８および事業者情報データベース２０６を適宜利用して、駅の混雑状況、事業者毎の売上額、第２利用者Ｂの動向等を考慮して第２パス４４の発券枚数γを指定する。また、調査部１２４は年代別や性別や路線別に発券枚数γを指定してもよい。調査部１２４は、発券枚数γを発券枚数設定部１２６に供給する。発券枚数設定部１２６は、調査部１２４から発券枚数γを受け付けて、分散的に第２パス４４を配布する際の配布形態を選択処理部１３８に指示する。
【００６３】
図１２は発券枚数設定部１２６が作成した第２パス４４の配布表を示す。例えば、乗車区間外の利用が少ない第１利用者Ａ、または乗車区間外の利用が多い第１利用者Ａのいずれか一方に第２パス４４を販売するなどの偏りが生じる可能性がある。そこで、乗車区間外の利用状況を明確にし、偏りのない配布を行うために選択処理部１３８は、この配布表に基づいて選択処理を行う。区間外運賃範囲欄４５２は、乗車区間外運賃の範囲（以下、「運賃範囲」という）を保持する。本図では、運賃範囲を５００円ごとに設定する。グループ欄４５０は、運賃範囲毎のグループ名称を保持する。本図ではグループ名として「Ｇ０１」から「ＧＮ」が設定されている。利用者ＩＤ数欄４５４は、乗車区間外運賃が運賃範囲に属する第１利用者Ａの数を保持する。割当枚数欄４５６は、運賃範囲毎に割り当てられた第２パス４４の発券枚数を保持する。
【００６４】
図７の発券枚数設定部１２６は、合計値が発券枚数γになるように、それぞれの運賃範囲に割当枚数を設定する。発券枚数設定部１２６は、候補者抽出部１２０が抽出した第１利用者Ａの総数に対する発券枚数γの割合が、運賃範囲毎の利用者数に対する割当枚数の割合に等しくなるように割当枚数を設定してもよいし、鉄道事業者が任意に設定できてもよい、更に利用者の性別や年齢を考慮して割当枚数を設定してもよい。要は、候補者抽出部１２０が抽出した全ての第１利用者Ａからランダムに第２パス４４の販売対象者を選択することで平均乗車区間外運賃に偏りが生じないように、発券枚数設定部１２６は運賃範囲に相当する利用者数毎に第２パス４４の割当枚数を設定すればよい。
【００６５】
本図は、第１利用者Ａの総数が２５０万人、発券枚数γが５０万枚とする配布表である。グループ「Ｇ０１」は、運賃範囲が「０から５００円未満」に設定され、その運賃範囲に該当する利用者数は「１０万人」であり、割当枚数は「２万人」である。割当枚数は、運賃範囲に該当する利用者数との比率が、第１利用者Ａの総数と発券枚数γの比率「５：１」と等しくなるように設定される。発券枚数設定部１２６は、図１２の配布表を選択処理部１３８に送信する。
【００６６】
図７に戻り、選択処理部１３８は、配布表に基づいて第２パス４４の販売対象者を選択する。例えば、図１２のグループ「Ｇ３６」では、運賃範囲が「１７５００〜１８０００未満」の利用者ＩＤ数「９００００人」から割当枚数に相当する「１８０００人」分の販売対象者を選択する。選択処理部１３８は、乗車区間外運賃が運賃範囲に該当する第１利用者Ａの中からランダムに１８０００人を販売対象者として選択してもよいし、運賃範囲内で乗車区間外運賃の多い順に１８０００人を選択してもよい。選択処理部１３８は、それぞれのグループについて同様の選択処理を行い、販売対象者の利用者ＩＤを候補者データベース１４０に格納する。
【００６７】
図１３は、候補者データベース１４０のデータ構造の一例を示す図である。利用者ＩＤ欄３２０は、選択処理部１３８によって選択された第２パス４４の販売対象者の利用者ＩＤを保持している。パスＩＤ欄３２３は、パスＩＤを保持する。グループ欄３２１は、利用者が属する前述したグループ、例えば「Ｇ０１」から「ＧＮ」を保持する。通知タイミング欄３２２は、通知を行なう順番を指定する情報を保持する。例えば、「１」〜「１８３」を保持する。この１８３は第２パス４４の有効期間６ヶ月間の日数に相当する。これにより、段階的な発券処理が可能になる。販売期限欄３２４は、第２パス４４の販売期限を保持する。契約フラグ欄３２６は、第２パス４４を購入したか否かを示す情報を保持する。本図では、「１」は購入済みを意味し、「０」は販売通知を行なったが未契約状態を意味する。再選択フラグ欄３２８は、購入しなかった利用者ＩＤに替わって他の人を選択することを指定する情報を保持する。本図では、「１」は再選択の必要有を意味し、「０」は再選択不要を意味する。
【００６８】
図７に戻り、通知部１４２は、利用者ＩＤの氏名と住所を個人情報データベース１２８で検索して販売対象者である第１利用者Ａに通知する。通知情報には、第２パス４４の販売期限を含める。この通知方法は、例えば、ダイレクトメール等の紙媒体により行われてもよいし、電子メールや電話を使って行われてもよい。通知部１４２は、通知を行うとともに、図１３の候補者データベース１４０の販売期限欄３２４に、販売期限の年月日を書き込み、更に、契約フラグ欄には通知済み、すなわち販売開始を意味する「０」を書き込む。
【００６９】
販売状況監視部１３６は、候補者データベース１４０を常に監視しており、通知タイミング欄３２２に保持されている値に基づいて、関係する利用者宛てに通知を行うことを通知部１４２に指示する。また、販売状況監視部１３６は、図１３の販売期限欄３２４に保持した年月日の翌日以降に契約フラグ欄３２６に「０」が保持されている場合に、再選択フラグ欄３２８に、第２パス４４の購入を放棄したものと判定して「１」を格納する。図１３では、利用者ＩＤ「６５４３２１０」がそれに相当する。
【００７０】
販売状況監視部１３６は、候補者データベース１４０の再選択フラグ欄３２８に「１」が保持されている利用者ＩＤを選択処理部１３８に送信する。例えば、図１３の再選択フラグ欄３２８に「１」が保持されている利用者ＩＤ「６５４３２１０」に関するデータを送信すると同時に候補者データベース１４０から削除する。選択処理部１３８は、利用者ＩＤ「６５４３２１０」の利用者とグループが同じで、乗車区間外運賃の金額がほぼ等しい別の利用者を選択し、その利用者のＩＤを候補者データベース１４０に新たに格納する。
【００７１】
販売状況監視部１３６が、候補者データベース１４０を常時監視することで、再選択と再通知を繰り返し、図１２で割り当てた各グループの割当枚数を完売できる。その結果、第２パス４４を購入した第１利用者Ａの平均乗車区間外運賃と、選抜利用者に基づき候補者抽出部１２０が抽出した全ての第１利用者Ａの平均乗車区間外運賃はほぼ同額になり、全ての第１利用者Ａに第２パス４４を販売しなくても交通事業者に一定の収益増をもたらすことができる。
【００７２】
例えば、第１利用者Ａの総数が２５０万人で第２パス４４の発券枚数γが１００万枚、５０万枚、３０万枚、１０万枚の場合、発券枚数設定部１２６は、２５０対１００、２５０対５０、２５０対３０、２５０対１０の比率でグループ毎の割当枚数を算出する。そして、選択処理部１３８は、グループ毎に利用者を選択する。これにより、それぞれの発券枚数γの平均乗車区間外運賃を１００Ａ６、５０Ａ６、３０Ａ６、１０Ａ６とした場合、選択処理部１３８は、「２５０Ａ６≒１００Ａ６≒５０Ａ６≒３０Ａ６≒１０Ａ６」を満たすように販売対象者を選択することが可能となる。つまり、選択処理部１３８は、販売対象者の平均乗車区間外運賃が、全ての第１利用者Ａの平均乗車区間外運賃とほぼ等しくなるように選択する。ここで、調査部１２４は、第２パス４４の発券枚数γを闇雲に増大させるのではなく、混雑率と安全輸送に悪影響を来さない上限を発券枚数γに設定することが好ましい。
【００７３】
第２パス４４の販売枚数を効率よく拡大するためには、第２利用者Ｂが地域的、時間的に分散するように販売対象者を選択することが好ましい。例えば「地域的に分散」するとは特定の地域や駅あるいは路線に第２利用者Ｂの住所、職場等が集中しない事を意味する。このために選択処理部１３８は、パス管理データベース１１４と第１利用情報データベース１１０とに基づいて、利用者の入場駅や退場駅も考慮にいれて販売対象者を選択する。「時間的に分散」とは、第２利用者Ｂの出退勤時刻や出勤日が異なり同じ電車に集中しない事を意味している。このために選択処理部１３８は、パス管理データベース１１４と第１利用情報データベース１１０とに基づいて、利用者の休日や出退勤時刻も考慮にいれて販売対象者を選択する。
【００７４】
第１管理装置１００が有するデータベースは、それぞれユーザＩＤまたはパスＩＤにより連携されたリレーショナル・データベースであることが好ましい。選択処理部１３８は、それぞれのデータベースに保持されているデータを必要に応じてＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）などのデータベース処理言語を利用して検索できるので、販売対象者を様々な条件で選択することができる。選択処理部１３８は、例えば、前述のグループ毎に地域的、時間的な分散を考慮して販売対象者を選択してもよい。
【００７５】
次に、第２パス４４の発券と第２利用者Ｂの登録について説明する。通知部１４２から通知を受けた第１利用者Ａは第２パス４４を所定期日までに購入する権利を得る。その通知を受けた利用者は、駅に設置されている図１の第２発券装置１８に第１パス４２を提示する。第２発券装置１８は、第１パス４２に格納されているパスＩＤを第２発券処理部１３２に出力する。第２発券処理部１３２は、第２パス４４の発券が可能か否かをそのパスＩＤと候補者データベース１４０に保持されているデータとに基づいて判定し、その判定結果を第２発券装置１８に送信する。第２パス４４を発券した後、第２発券装置１８は、生成した第２パス４４のパスＩＤを第２発券処理部１３２に送信する。
【００７６】
第２発券処理部１３２は、既に個人情報データベース１２８に登録されているパス種別欄３６０の「第１パス」を「第２パス」に書き替え、パス管理データベース１１４の使用開始欄３６６を発券時点の年月日に書き替え、パスＩＤ欄３６２の第１パス４２のパスＩＤを新たに生成された第２パス４４のパスＩＤに書き換える。また、第２発券処理部１３２は、発券履歴保存部１３４に第２パス４４のパスＩＤと利用者ＩＤと発券年月日を送信する。
【００７７】
図９において、第２パス４４である「ＮＷＰ−２０００３３Ｂ」の鉄道会社毎の定期券の有効期間であるＹ１やＹ２が異なる場合は統一する方が好ましい。尚、図１３の候補者データベース１４０の通知タイミング欄３２２には、第１パス４２に格納された定期券の有効期間に関係無く通知順位を保持するので、第２パス発券装置１８は中途解約でない精算処理で有効期間を統合できることが好ましい。また、追加料金αは、パス毎に一律でなく異なってもよい。
【００７８】
図７に戻り、第２利用情報収集部１０４は、乗車管理システム３０から第２利用者Ｂの利用情報を収集して、第２利用情報データベース１１２に格納する。本実施の形態では、第２利用情報収集部１０４は、利用情報に含まれるパスＩＤに対応付けられている利用者ＩＤを、パス管理データベース１１４から取得し、乗車区間内運賃や乗車区間外運賃などに対応付けて第２利用情報データベース１１２に格納する。
【００７９】
図１４は、第２利用情報データベース１１２のデータ構造の一例である。利用者ＩＤ欄３３０は、利用者ＩＤを保持する。区間内運賃欄３３２は、乗車区間内の運賃を乗車の都度に支払う普通運賃で算出し保持する。区間外運賃欄３３４は、乗車区間外運賃を保持する。入場駅欄３３６は入場駅ＩＤを保持する。入場日時欄３３８は入場日時を保持する。退場駅欄３４０は退場駅ＩＤを保持する。退場日時欄３４２は退場日時を保持する。鉄道会社内訳欄３４４は、鉄道会社毎の乗車区間外運賃を保持する。Ｘ社欄３４６ａはＸ鉄道会社の、Ｙ社欄３４６ｂはＹ鉄道会社の乗車区間外運賃をそれぞれ保持する。このような利用情報を長期に渡り蓄積することで、特定の利用者、性別、年齢、入場駅、退場駅、それらの組み合わせなどの様々な条件で利用情報を集計、分析が可能である。
【００８０】
図７に戻り、分配部１４８は、図１４の鉄道会社内訳欄３４４に保持されているデータを各鉄道会社別に集計し、第２パス４４の販売価格である追加料金αと、後述する第２利用者Ｂが事業者に対して消費を行うことで変動する割引率により生じる金額の一部をそれぞれに比率配分する。調査部１２４は、前述の処理の他に、事業者の割引により生じる金額のうち鉄道会社毎に配分する額を決める。
【００８１】
本実施の形態では、第１利用者Ａが所定の地域に存在する事業者から商品や役務を購入する際に割引を受けることができる。販売額算出部１４６は、その割引金額を図１の第２管理装置２００から収集して、電子マネーとして利用者毎にストックする。そして、第２パス４４を購入する際に販売価格に充当する。第２発券処理部１３２は、充当後の価格を利用者に提示する。また、第２利用者Ｂの場合は所定期間に所定金額を消費することを契約条件に第２パス４４を発券する。その場合、事業者から消費する所定金額の一部を前納することも有り得る。
【００８２】
図１５は、図１の第２管理装置２００の内部構成図である。図１の各事業者に設置している事業者端末１４は、第１パス４２および第２パス４４のパスＩＤを図７の認証部１０６に送信しパスが利用可能であるか否かを確認する。消費情報収集部２０２は、パスの認証を終えた事業者端末１４から受け付けた第１利用者Ａまたは第２利用者Ｂの消費情報に利用者ＩＤを対応付けて、消費情報データベース２１０に格納する。
【００８３】
図１６は、消費情報データベース２１０のデータ構造の一例を示す。利用者ＩＤ欄３９２は、利用者ＩＤを保持する。パス種別欄３９４は、パス種別を保持する。事業者ＩＤ欄３９６は、利用者が商品や役務を購入した事業者を特定する識別情報（以下、「事業者ＩＤ」という）を保持する。消費日時欄３９８は、利用者が消費を行った日時を保持する。金額欄４００は、消費金額を保持する。品目欄４０２は、品目を保持する。例えば、このデータ構造から、利用者ＩＤが「３６２５４３５」の利用者は、第１パス４４の所有者であり、事業者「Ｓ０１２５４」で、２００２年１月１５日に食事のために５２００円の消費を行ったことがわかる。
【００８４】
図１５に戻り、前納金額情報データベース２０４は、第２パス４４の購入にともなって、第２利用者Ｂが前納金として予め納めた金額の一部を電子マネーとして保持する。前納金分配処理部２０８は、第２利用者Ｂが消費を行うたびに、その電子マネーから消費した金額の一部を差し引き、事業者に配分する。例えば、前納金額情報データベース２０４には、第２パス４４の購入条件とした所定の消費金額の半分が電子マネーとして予め保持されており、第２利用者Ｂが消費を行った場合、第２利用者Ｂはその場で消費金額の半分を支払い、前納金分配処理部２０８が、事業者端末１４からの消費情報に基づいて前納金額情報データベース２０４から残額を差し引いてよい。前納金分配処理部２０８は、電子マネーを事業者毎に蓄積し所定の期日毎に決済するが、その際、事業者毎に取り決めた所定の金額を差し引いて配分してもよい。
【００８５】
条件格納部２１８は、第２利用者Ｂに対する第２パス４４の利用条件を保持する。例えば、その利用条件は、所定の期間に消費すべき金額である。判定部２１６は、それぞれの第２利用者Ｂに対してその利用条件を満たしているか否かを判定する。通知部２１４は、条件を満たしていない第２利用者Ｂに対してその旨を通知する。
【００８６】
図１７は、事業者情報データベース２０６のデータ構造の一例を示す。事業者ＩＤ欄３８０は、事業者ＩＤを保持する。最寄駅欄３８２は、その事業者店舗の最寄駅の駅ＩＤを保持する。業種欄３８４は、事業者の業種を保持する。第１割引率欄３８６は、第１利用者Ａに対する割引率や第２利用者Ｂに課せられた所定の消費金額とは関係しない消費に対する割引率を保持する。例えば、図１５に戻って、消費額提供部２２２は、第１利用者Ａおよび第２利用者Ｂが第１割引率で消費した場合に、割引きした金額を図７の販売額算出部１４６に送信する。販売額算出部１４６は、利用者ＩＤ別にストック金額を保持し、第１利用者Ａあるいは第２利用者Ｂが第２パス４４を新規にあるいは継続して購入する場合に使用してもよい。第２割引率欄３８７は、第２利用者Ｂに課せられた所定の消費金額に関係する消費に対する割引率を保持する。総売上欄３８８は、第２利用者Ｂが第２割引率で消費した総売上を保持する。例えば、事業者はこの総売上に応じて第２割引率を変動させてもよいし、自動的に第２割引率を変動させる変動部（図示しない）を更に設けてもよい。住所欄３９０は、事業者の住所を保持する。図示しないが第１利用者Ａならびに第２利用者Ｂが第１割引率で消費した総売上を保持するフィールドを設けてもよいし、その他事業者に関する情報を保持してもよい。
【００８７】
図１５に戻り、事業者選択部２１２は、例えば、図７の第２利用情報データベース１１２から第２利用者Ｂが頻繁に利用している駅を抽出し、その駅周辺に存在する事業者の情報を事業者情報データベース２０６から取得する。そして、事業者選択部２１２は、その事業者の情報を通知部２１４に出力する。通知部２１４は、前述した消費条件を満たしていない第２利用者Ｂへの通知にその事業者を加えてもよい。これにより、第２利用者Ｂの消費を促すことができる。また、事業者選択部２１２は、消費情報データベース２１０からその利用者の嗜好を推定し、その嗜好にマッチした事業者を事業者情報データベース２０６から選択し、その情報を前述した通知に付加してもよい。
【００８８】
更新対象者選択部２２０は、例えば６ヶ月間有効な第２パス４４を一度だけ継続して所持することが可能な場合、一定の条件を満たした第２利用者Ｂを更新対象者として第１管理装置１００に通知する。仮に、所定金額を消費する所定期間を「第２パス４４の有効期間＋２ヶ月間」と設定した場合は第２パス４４の有効期間が切れる２週間前に消費金額の８０％を消費している利用者ＩＤを更新対象者として図７の通知部１４２に提供する。そして通知部１４２は、図８に示す個人情報データベース１２８の更新資格フラグ３６１を「１」に書き換える。消費金額の８０％を達成しないで第２パス４４の有効期間を過ぎた第２利用者Ｂは自動的に第１利用者Ａに移行する。その場合、交通機関ではなくインターネット・ショッピングなどで残額を消費できる環境を提供してもよい。しかし、最終期日までに当初の消費金額に達しなかった場合は、契約違反として前納金額情報データベース２０４の残金を使い必要な金額を精算する。例えば、この精算処理は前納金分配処理部２０８が行い、第２パス４４の有効期間中に使用した乗車区間外運賃が追加料金αを越えている場合は残額から補填し、乗車区間外運賃が追加料金α以下の場合は前納金額情報データベース２０４の残額を返還する処理を行ってもよい。
【００８９】
以上、識別情報を付したパスを利用した乗車管理システムを説明した。このシステム形態は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なことは当事者に理解されるところである。こうした変形例としては以下のものがある。
【００９０】
第１の変形例は、本システムを利用する交通機関に関する。実施の形態では、交通機関として鉄道を例に説明したが、交通機関は鉄道に限らず、バス、飛行機、船、レンタカー、レンタサイクル、タクシー、高速道路であってもよい。
【００９１】
第２の変形例は、図７の調査部１２４に関する。追加料金αの算出方法を前述したが、算出した追加料金αの妥当性を判断することが経営上必要になる。追加料金αの妥当性を単に、「追加料金α」と「乗車区間外運賃」とを比較して判断するのでは、第２パス４４には乗車区間が限定されていない点で正確さを欠く。そこで、調査部１２４は、第２利用情報データベース１１２が保持する乗車区間内運賃と乗車区間外運賃とに基づいて追加料金αの妥当性を判断する。第２パス４４による割引率Ｘは、「乗車区間内運賃Ｎ」、「乗車区間外運賃Ｔ」、「定期券代金Ｖ」、「追加料金α」から
【００９２】
割引率Ｘ＝｛１００−（Ｖ＋α）／（Ｎ＋Ｔ）×１００｝
の計算式で求められる。例えば、割引率Ｘが通常の定期券の割引率より少し高め程度なら追加料金αは妥当であると判断できる。このとき、割引率を利用者ＩＤごとに算出するのではなく、全ての第２利用者Ｂを対象に数年分の割引率の平均値を割引率としてもよい。そして、割引率が高すぎる場合は、追加料金αのひとつの成分である増収額θに一定額を上乗せし、妥当な追加料金αとしてもよい。
【００９３】
第３の変形例も図７の調査部１２４に関する。調査部１２４は、追加料金αを「世代別」に減額してもよい。調査部１２４は、割引率Ｘを世代別に算出し、仮に２０代の割引率を２０Ｘ、６０代の割引率を６０Ｘとしたとき、「２０Ｘ＞３０Ｘ＞４０Ｘ＞５０Ｘ＞６０Ｘ」のように、年齢が高くなるにつれて割引率が低くなる、すなわち乗車区間外の利用が少なくなるといった顕著な相関関係が有る場合は、年代別に追加料金αを減額してもよい。例えば上記の相関関係の場合は、減額値を２０代＝０円、３０代＝３００円、４０代＝６００円、５０代＝８００円、６０代＝１０００円などとして減額してもよい。これにより、第２パス４４の利用状況にあった価格を設定することができ、ひいては契約率を高めることができる。
【００９４】
第４の変形例も図７の調査部１２４に関する。調査部１２４は、追加料金αを「定期券代金別」に減額してもよい。調査部１２４は、割引率Ｘを定期券代金別に算出し、定期券代金が３万円未満の割引率を３Ｘ、定期券代金が２０万円未満の割引率を２０Ｘとしたとき、「３Ｘ＞５Ｘ＞８Ｘ＞１２Ｘ＞１６Ｘ＞２０Ｘ」のように、定期券代金が高くなるにつれて割引率が低くなる、すなわち乗車区間外の利用が少なくなるといった顕著な相関関係が有る場合は、乗車区間内が長くなるほど、すなわち定期券代金が高いほど追加料金から減額してもよい。
【００９５】
第５の変形例も図７の調査部１２４に関する。調査部１２４は、追加料金αを第３の変形例と第４の変形例で説明した減額方法を組み合わせて追加料金αを算出してもよい。
【００９６】
第６の変形例は、図１の入場側改札装置３４に関する。図１８は、他の形態における入場側改札装置３４の内部構成図である。この入場側改札装置３４は、図３で説明した入場側改札装置３４の構成に加えて、認証部５８とセンサ部６０とを更に含む。認証部５８は、センサ部６０から指紋や掌形、虹彩などの生体情報を取得し、その生態情報に基づいて認証を行う。これにより、認証部５８は、第１パス４２または第２パス４４が本人以外の第三者に使われているか否かを判定可能である。またこの場合、認証に必要な本人のデータを、第１パス４２や第２パス４４の格納部や個人情報データベース１２８に予め格納しておく。
【００９７】
この認証作業は、例えば、入場時に毎回行われてもよいし、一日に一度だけ行ってもよい。また、所定の確率に基づいて抜き打ちで認証を行ってもよい。この場合、他の入場側改札装置３４では認証処理を行わない可能性があるので、認証に失敗した時点で、そのパスを利用した入場を全て拒否することが好ましい。また、そのパスに対しては毎回認証処理を行ってもよい。更に認証を確率に基づいて行えば、認証は不定期になるので、一種のゲーム性を持たせてもよい。例えば、認証を受けたときにポイントを加算したり、景品をプレゼントしたりしてもよい。このような機能を退場側改札装置３６に設け、退場時に認証を行ってもよい。また、認証を行う確率を任意に設定できることが好ましく、例えば時間帯やイベント開催時などで変える。これにより、ラッシュ時には認証を行う確率を低くし、ラッシュ時間外では確率を高くすることができる。
【００９８】
第７の変形例も、第６の変形例と同様に認証に関する。パスに所有者の顔写真を印刷しておき、認証は有人改札で行うようにしてもよい。これを実現するために、入場側改札装置３４は、例えばランダムに入場を拒否し、有人改札での認証を促す。このとき、入場側改札装置３４はパスに入場拒否フラグを書き込む。そして、有人改札で駅員がパスに印刷した顔写真を参照して認証を行う。有人改札には、入場拒否フラグをパスから消去するための装置が設けられており、パスの利用者が本人である場合に、駅員はそのパスから入場拒否フラグを削除する。このときにも、ポイントの加算などユーザにインセンティブを提供してよい。
【００９９】
第８の変形例は、図７の調査部１２４と候補者抽出部１２０と選択処理部１３８に関する。調査部１２４は、第１利用情報データベース１１０に保持されているデータに基づいて、利用者の自宅側駅における主要な入退場時刻を推定し、利用者ＩＤと入場あるいは退場時刻とを対応付けて候補者抽出部１２０に送信し、選択処理部１３８は出勤時刻ならびに退勤時間が重ならないように、第２パス４４の販売対象者を選択してもよい。
【０１００】
第９の変形例は、第２パス４４の販売条件に関する。本システムは、第２パス４４により、利用者が交通機関を利用して自由に移動する手段を提供するとともに、その移動先となる地域経済を活性化することを一つの目的とする。地域経済の活性化を図るために、「所定期間に所定の金額を消費する」という条件を設定して第２パス４４を販売することとしたが、このような条件を設けなくてもよい。
【０１０１】
第１０の変形例は、第２パス４４の販売に関する。「所定の期間に所定の消費を行う」という販売条件を設定したが、その消費額は一定にするのではなく利用者毎に消費額を自由に設定してもよい。これにより、世代や性別その他それぞれの利用者のニーズにあった販売が可能になる。例えば、追加料金α＝０円にまで減額してもよい。
【０１０２】
第１１の変形例は、図７の通知部１４２に関する。第１利用者Ａに第２パス４４の購入対象者となったことを、電子メールや電話を使用するほかに、入場側改札装置３４の通知部６６あるいは退場側改札装置３６の通知部９０を活用して図７の通知部１４２の情報を通知してもよい。
【０１０３】
第１２の変形例は、第１パス４２および第２パス４４に関する。第１パス４２および第２パス４４は、予め乗車区間が設定され定期券としての役わりを有することとしたが、定期券のような乗車区間が設定されていなくてもよい。この場合、第１管理装置１００は、利用毎の運賃を蓄積し、その運賃に基づいて第２パス４４の価格を算出する。要は、第１パス４２を利用して、利用者の乗車傾向を分析し、それに基づいて第２パス４４の価格、販売方法を決定すれば、利便性の高い乗車券を提供できる。
【０１０４】
第１３の変形例は、図１２の各グループ毎の割当枚数に関する。同一の利用者が使用する乗車区間外運賃は各日、各週、各月、各年でばらつきが生じるのは当然のことであり、必然的に集計時期により属するグループが異なる。このことから、各グループの割当枚数に固執すれば長期的には公平な発券枚数を提供できなくなることが考えられる。図１２は所定の平均乗車区間外運賃を求めるための目安であるので、必要に応じて比率配分で確定した割当枚数または発券枚数γを増減させてもよい。要は、実際に第２パス４４を購入した利用者の平均乗車区間外運賃と候補者抽出部１２０で抽出した全ての第１利用者Ａの平均乗車区間外運賃がほぼ同額になればよい。
【０１０５】
第１４の変形例は、第２パス４４の契約率向上に関する。一般に乗車区間外運賃実績が高額の利用者の契約率や高く、低額の利用者の契約率は低いことが想定できるが、第１３の変形例に記述したケースや利用者の個人的事情により一様ではない。そこで、個人情報データベース１２８に希望フラグ欄を設け、例えば「１」は購入する意思を示し、「０」は購入する権利を留保する意思を示すなど、利用者が自由にフラグを書き換え可能としてもよい。そして、調査部１２４は、この情報を選抜利用者を確定する際の選択基準に加えてもよい。これにより、購入希望者を選択できるので契約率を向上できる。
【０１０６】
第１５の変形例は、第２パス４４に関する。通常、ひとり一人が乗車券を所持し改札装置を通過するが、第２パス４４を所持していれば、所持者とともに複数人が連続して改札装置を通過できるようにしてもよい（以下、この利用方法を「グループパス機能」という）。これにより、第２パス４４の所持者が家族や気の合う同行者とペアで気軽に利用することも可能となる。この場合、第２パス４４は、同時に利用できる人数（以下「同時利用者数」という）を保持する領域を利用者数格納領域として更に有する。入場側改札装置３４は、例えば、所定期間内、あるいは別のパス所持者が入場側改札装置を通過するまでの期間に改札を通過した人数をカウントし、カウント値を第２パス４４に格納する。そして退場側改札装置３６は、第２パス４４に保持されている入場人数と退場人数とを比較し、同数であることを確認し、かつその人数が同時利用者数以下であることを確認する。
【０１０７】
図３の入場側改札装置３４および図５の退場側改札装置３６は、利用者数格納領域から同時利用者数を読み取るユニットと、通過した人数をカウントするカウント部と、カウントした人数が同時利用者数以下で、かつ入退場時の人数が等しいか否かを判定するユニットとを備える。例えば、図３の取得部５２および図５の取得部７２が、第２パス４４から同時利用者数を読み取り、判定部５４および判定部７４がその判定を行ってもよい。また、入場側改札装置３４に乗車人員を申告する押しボタンを設け、利用者が入場時に操作することで意思の疎通を図ってもよい。グループパスの価格は第１パス４２の利用実績から確定できないが、基本的に第２パス４４の所持者と同行し乗車することが原則なので、第２パス４４の購入者の家族数などの申告により発行するなど所定の基準を設けることで新規の顧客を確保することが可能である。したがって、認証作業は第７の変形例で説明した認証を行うことが好ましい。そして、その認証の確率を高く設定し、認証回数に応じてポイントなどのインセンティブを提供するようにしてもよい。
【０１０８】
また、このグループパス機能を、予め設定した期間内であれば一日乗車券として利用可能な回数（以下「利用可能回数」という）を設定して使用できるようにしてもよい。この場合、第２パス４４は、グループパス機能を利用できる利用可能回数を保持する領域を利用回数格納領域として更に有する。そして、図３の入場側改札装置３４、または図５の退場側改札装置３６の少なくとも一方は、グループパス機能の利用可能回数をデクリメントするユニットを更に有する。いずれにしても、第２パス４４の利用者が単独で改札装置を通過する際は利用可能回数がデクリメントされることはなく、例えば、休日や夏休みなどに修学児童の体験学習として活用する機会を提供できる。このような目的でグループパス機能を提供する場合は、第１パス４２にも適用することが好ましいが、その場合、同時利用者数と利用可能回数に対してのみ同一価格とし、第１パス４２の所持者の乗車区間外運賃は常に実費で集計する。更に、第１パス４２および第２パス４４とは無関係に利用可能回数のみを有するグループパス機能（以下「観光パス」という）として、例えば、短期間滞在する外国人観光客に発行してもよい。これにより、乗車履歴を分析すれば、外国人観光者の人気スポットや目的地に達するまでの行動ルートから、より分かり易い観光案内書などを充実させることにも活用できるし、適正価格で利便性の高い観光パスを提供できる。
【０１０９】
第１６の変形例は、第１パス４２または第２パス４４の定期券部分に関する。一般に定期券は乗車区間内であれば乗降り自由であるが、予め決めた駅（以下、「指定駅」という）でのみ乗降りができる定期券（以下、「駅間限定定期券」という）を発行してもよい。これを第１パス４２とする場合、指定駅以外の利用は乗車区間外運賃として収集する。また、駅間限定定期券に一定金額を加えて通常の定期券として利用する場合でも、指定駅以外の利用を乗車区間外運賃として収集し、第２パス４４の追加料金の算出に利用してもよい。
【０１１０】
これを実現するために、第１パス４２または第２パス４４は、指定駅の駅ＩＤを保持する領域を指定駅ＩＤ格納領域として更に有する。そして、入場側改札装置３４および退場側改札装置３６は、その領域に保持されている駅でのみ乗降りを許可してもよい。このパスを、例えば事業者である企業と個人の要望で実現する通勤、通学専用の定期とし、通常の定期券より安い価格で提供してもよい。
【０１１１】
第１７の変形例は、第２パス４４に関する。第２パス４４の価格を「定期券の継続購入」と「追加料金＝平均的乗車区間外運賃＋事業者収益」を先払いすることで、乗車区間外運賃がかからず、乗り放題になるとしたが、「追加料金＝平均的乗車区間外運賃」に設定して、ユーザの乗車区間外運賃が、追加料金である平均的乗車区間外運賃より高くなった以降の乗車区間外運賃に対して所定の割り引き運賃を、その度に支払うようにしてもよい。この処理は、退場側改札装置３６が行う。例えば、第２パス４４を所定の金額で販売し、ユーザが先払いした平均的乗車区間外運賃より高くなるまで乗車し、それ以上の乗車区間外における利用に際して５０％割引きした金額をユーザが支払うようにしてもよい。また、「追加料金」で乗り放題とせずに、乗車区間外運賃に上限を例えば３０万円に設定し、その上限以上の利用に際しては、その度に乗車区間外運賃をユーザが支払うようにしてもよい。鉄道、バス、タクシーなど交通機関の種類や特徴に応じて、適切な支払い形態があるので、その事業者が支払形態を任意に設定できることが好ましい。
【０１１２】
＜ユーザ管理システム＞
上述した発券管理システム５００は、利用者の利便性を向上することのみならず、地域経済の活性化を支援できる。このシステムでは、識別情報の付されたパスを利用するが、そのパスを利用するごとにポイントの加算、プレゼントの抽選など、利用者にインセンティブと娯楽を提供することで利用者の拡大と、鉄道の利用を促すことができる。
【０１１３】
図１９は、こうした識別情報を利用したユーザ管理システムにおいてユーザにインセンティブを提供するユーザ管理システム６５０の構成図である。配信装置６００は、インセンティブを提供すべきユーザの識別情報（以下、「ユーザＩＤ」という）を、ネットワーク６５１を介して、複数の端末装置である第１端末装置６３０ａ、第２端末装置６３０ｂ、および第３端末装置６３０ｃに配信する。第１端末装置６３０ａは、配信装置６００からユーザＩＤを受信して保持する。そして、第１端末装置６３０ａを利用する利用者のユーザＩＤを取得して、インセンティブを提供すべきか否かを判定する。第１端末装置６３０ａは、例えば事業者の店舗に設置され、利用者の来店時に判定を行い、該当者にプレゼントを贈るなどのインセンティブを提供する。第２端末装置６３０ｂおよび第３端末装置６３０ｃはそれぞれ同一の構成および機能を有し、それぞれ独立して機能する。配信装置６００は、それぞれの端末装置に独立してインセンティブを提供すべきユーザＩＤを送信するので、利用者は第１端末装置６３０ａでプレゼントを獲得できなくても、第３端末装置６３０ｃでは獲得できることもありうる。このシステムにより、ユーザが店舗に立ち寄ることで娯楽的要素を提供できる。
【０１１４】
図２０は、図１９の配信装置６００の内部構成図である。サーバ側識別情報データベース６０２は、すべてのユーザＩＤを保持する第１格納部である。図２１にサーバ側データベース６０２のデータ構造の一例を示す。ユーザＩＤ欄６０２ａは、所定の事業者の会員カードに付与されたユーザＩＤを保持する。属性欄６０２ｂは、ユーザの属性である氏名、年齢、性別、住所、趣味等を保持する。例えば、この属性に基づいて、端末装置が設置されている店舗の顧客層に相応する利用者を選択することができる。他の例では、ユーザ属性は設けられていなくてもよい。図２０に戻り、配信先データベース６０８は、ユーザＩＤを送信する配信先を保持するデータベースである。
【０１１５】
図２２は、配信先データベース６０８のデータ構造の一例を示す。端末ＩＤ欄６０８ａは、サーバ側識別情報データベース６０２から選択したユーザＩＤの配信先となる端末装置の識別情報（以下「端末ＩＤ」という）を保持する。配信数欄６０８ｂは、選択するユーザＩＤの数を保持する。配信タイミング欄６０８ｃは、ユーザＩＤを配信する日時や期間など時間的タイミングを保持する。
【０１１６】
図２０に戻り、指示部６０６は、配信先データベース６０８に保持されているデータに基づいて、選択部６０４に所定のユーザＩＤ数を選択することを指示すると同時に、送信部６１０に、そのユーザＩＤの配信先となる端末ＩＤを指示する。選択部６０４は、指示部６０６の指示に基づいて選択処理を開始する。そして、送信部６１０は、指示部６０６に指示された配信先である端末ＩＤに、選択部６０４が選択したユーザＩＤを送信する。
【０１１７】
ここで、ユーザにインセンティブを提供する本ユーザ管理システムにおいては、複数の端末装置である第１端末装置６３０ａ、第２端末装置６３０ｂ、第３端末装置６３０ｃにユーザＩＤを配信した結果、Ａ氏のユーザＩＤとＢ氏のユーザＩＤとが、ほぼ同数配信されるという平等性を確保することが好ましい。また、第１端末装置６３０ａにはＡ氏のユーザＩＤが複数含まれるが、Ｂ氏のユーザＩＤは含まれないといった差別化を達成する配信結果が得られることが好ましい。したがって、必然的にサーバ側識別情報データベース６０２に保持しているユーザＩＤ総数ＴＵと、配信先データベース６０８の配信数欄６０８ｂに保持する配信数Ｈは、常に「ＴＵ＞Ｈ」の関係になる。しかし、配信数欄６０８ｂの配信数を合計した総計配信数ＴＨとの関係を「ＴＵ対ＴＨ」として比較すると「１対数百〜数千」になる程度に、端末装置の設置数と配信するユーザＩＤが増大することが予測される。
【０１１８】
指示部６０６は、例えば、配信先データベース６０８の、配信数欄６０８ｂに保持されている数のユーザＩＤの配信を、例えば上位の端末装置から順次処理する。次に、指示部６０６は、選択すべきユーザＩＤの数を選択部６０４に指示する。選択部６０４は、サーバ側識別情報データベース６０２に保持されているユーザＩＤを上位から順に、指示部６０６に指示された数だけ選択する。選択部６０４は、前記選択したユーザＩＤの次から引き続き下位方向に選択し、下位まで達した後は引き続き上位に戻る繰り返しを連続する。これにより、複数の端末装置には膨大な数のユーザＩＤが配信されるが、例えばＡ氏のユーザＩＤ数やＢ氏のユーザＩＤ数は、ほぼ同数配信されることになる。
【０１１９】
しかし、指示部６０６が、配信先データベース６０８の、配信数欄６０８ｂに保持されているユーザＩＤの配信数を一度に全部選択することを選択部６０４に指示すると、ひとつの端末装置にひとつのユーザＩＤしか含まれない可能性がある。したがって、指示部６０６は、一度に選択するユーザＩＤ数を、例えば、配信数欄６０８ｂに保持されている配信数から十分の一を選択するように、選択部６０４に指示すれば、可能性としては同一の端末装置にＡ氏のユーザＩＤが最大１０個含まれる可能性がでてくる。いずれにしても、Ａ氏のユーザＩＤが一つの端末装置に集中することと、より多くの端末装置に分散することはその達成度において対立する概念であるが両方を達成することが可能となる。
【０１２０】
更に、図２２の配信タイミング欄６０８ｃには毎日配信するユーザＩＤを更新して配信する場合がある。したがって、常に、同じパターンで配信することになり、例えば、図２１を用いて説明したサーバ側識別情報データベース６０２の、ユーザＩＤ欄６０２ａに保持しているＤ氏とＥ氏のユーザＩＤの配列が連続している場合、Ｄ氏とＥ氏のユーザＩＤはいつも同一の端末装置に含まれる可能性が高くなる。したがって、このような配信を防ぐために、指示部６０６が選択部６０４と送信部６１０に指示する前に、サーバ側識別情報データベース６０２、並びに、配信先データベース６０８のデータの並びを入れ替えることにより、毎回、別のパターンで配信することが可能となる。
【０１２１】
前記方法により、図２２の配信数欄６０８ｂの配信数の並びも変わるが、指示部６０６は、配信数を端末装置ごとにカウントし、カウントした合計が配信数欄６０８ｂに到達した場合には配信作業を停止するか、一時的に、配信先データベース６０８から削除するので、端末装置ごとに指定された数のユーザＩＤを配信できる。また、配信先データベース６０８の配信タイミング欄６０８ｃの配信日や配信時刻が区々の場合、指示部６０６は配信日を優先して選択部６０４に指示し、選択部６０４からユーザＩＤを受け付けた送信部６１０はユーザＩＤを配信時刻まで保持し、送信時刻に送信先となる端末装置に配信してもよい。これにより、例えば端末装置を管理する事業者の営業時間外に配信するという対応が可能となる。
【０１２２】
図２３は、図１９の第１端末装置６３０ａの内部構成図である。受信部６３２は、配信装置６００から複数のユーザＩＤを受信して、クライアント側識別情報データベース６３４に格納する。図２４は、クライアント側識別情報データベース６３４のデータ構造の一例を示す。ユーザＩＤ欄６３４ａは、受信部６３２が受信した複数のユーザＩＤを保持している。保持数欄６３４ｂは、同じく受信部６３２が受信したユーザＩＤのうち同一のユーザＩＤを合計して保持している。図２３に戻り、このクライアント側識別情報データベース６３４は、配信装置６００から所定のタイミングで受信する受信部６３２からのユーザＩＤを格納する前に、既に保持しているユーザＩＤを消去、あるいは、更新して新規に格納する。また、図示しないが、別の態様として、例えば、クライアント側識別情報データベース６３４−１とクライアント側識別情報データベース６３４−２のように複数の格納部を並列にセットし、瞬間的にそれらを切り替えることで、２４時間切れ間無く営業する事業者に対しても対応できる。また、受信部６３２は、ユーザＩＤを受信する前に配信装置６００の認証を行い、不正なユーザＩＤをクライアント側識別情報データベース６３４に格納することを防止してもよい。
【０１２３】
読取部６３８は、例えばカードリーダーであって、ユーザが保持する会員カードなどからユーザＩＤを読み込み、照合部６３６に出力する。照合部６３６は、読取部６３８が読み込んだユーザＩＤがクライアント側識別情報データベース６３４に格納されているか否かを判定する。格納されているユーザＩＤと読取部６３８が読み取ったユーザＩＤが一致した場合を、以下「当選」と表現する。提供部６４０は、その判定結果、すなわち、当選か否かをユーザに通知する。このように、当選と判定した場合、照合部６３６はユーザＩＤと、クライアント側識別情報データベース６３４の保持数欄６３４ｂが保持しているＩＤ数とを提供部６４０に供給する。例えば、ユーザが第１端末装置６３０ａを設置する事業者の店舗で商品を購入した時点で、照合部６３６が、照合を行い、その結果を提供部６４０に出力する。照合結果が当選の場合、提供部６４０は、購入金額並びに保持しているＩＤ数に応じて、事業者店舗が独自にインセンティブを提供してもよい。その場合、提供部６４０が当選したことをユーザに通知し、店員がプレゼントなどを直接手渡してもよい。いずれにしても、インセンティブとしては、ポイント、プレゼント、金銭など有体、無体を問わず事業者が任意に決められることが好ましい。
【０１２４】
本システムは複数の事業者が提携することで、ユーザにインセンティブを効果的に提供することをひとつの目的としていることから、更に、ユーザにインセンティブを提供する別の態様についても説明する。ユーザがあるホテルで宿泊をし、例えば、精算時にユーザが所持する所定のカードを、第１端末装置６３０ａに挿入すると、図２３の読取部６３８がユーザＩＤを読み取り、照合部６３６に出力する。照合部６３６が受信したユーザＩＤが、クライアント側識別情報データベース６３４に保持されているか否かを照合し、保持している場合は当選とし、一致するユーザＩＤ数を含めて提供部６４０に送信する。その際、提供部６４０は、ユーザが宿泊したホテルの支払い金額と保持するＩＤ数に応じて提供するポイント数を確定してもよい。しかし、ユーザへのインセンティブをその場で提供するのではなく、ユーザが獲得したポイントを蓄積するために、提供部６４０は、引き続き、配信装置６００にデータを送信する。
【０１２５】
図２０に戻り、引き続きユーザに提供するインセンティブについて説明する。管理部６１６は、第１端末装置６３０ａから送信されるデータを受領する。データは、例えば、ユーザＩＤと端末ＩＤとポイント数があればよく、そのデータを、ポイント蓄積部６１４に供給する。また、管理部６１６は、ポイント蓄積部６１４に保持されている例えば、第１端末装置６３０ａや第２端末装置６３０ｂなどが提供したポイント数を課金部６１２に供給する。さらに、管理部６１６は、ユーザＩＤ別に獲得ポイント数を管理し、課金部６１２が事業者から徴収した金額から、ユーザ個々にインセンティブとして提供する金額を計算し、ユーザの指定する銀行に振り込む。
【０１２６】
前記したように、管理部６１６に課せられた種々の目的を達成するために、例えば、管理部６１６が、第１端末装置６３０ａから受け付けるデータは、ポイントを獲得したユーザのユーザＩＤと獲得ポイント数、並びにそのポイントを提供した端末ＩＤとポイント数である。図２５は、ポイント蓄積部６１４のデータ構造を示す一例である。ユーザＩＤ欄６１４ａは、ユーザＩＤを保持する。獲得ポイント数欄６１４ｂは、ユーザＩＤに対応付けて獲得したポイント数をその都度に加算して保持する。また、端末ＩＤ欄６１４ｃは、第１端末装置６３０ａや第２端末情報６３０ｂなどに対応付けられた端末ＩＤである。提供ポイント数欄６１４ｄは、端末ＩＤがインセンティブとしてユーザに提供したポイント数をその都度に加算して保持する。このように、インセンティブとして、金銭的価値を有するポイントを獲得するユーザＩＤとポイントを提供する端末ＩＤとをその都度に対応付けて保持するので、獲得ポイント総数欄６１４ｅの獲得ポイント総数と提供ポイント総数欄６１４ｆ欄の提供ポイント総数は等しくなる。
【０１２７】
管理部６１６は、所定のタイミング、例えば、３ヶ月毎に第１端末装置６３０ａなどが提供したポイント数を、課金部６１２に送信する。課金部６１２は、第１端末装置６３０ａや第１端末装置６３０ｂなどを管理する事業者毎に課金額を請求する。また、管理部６１６は、別の請求、例えば、配信先データベース６０８に保持しているデータから第１端末装置６３０ａなどを管理する事業者にユーザＩＤの配信数と配信日数で計算した金額を課金部６１２に請求させてもよい。いずれにせよ課金方法はビジネスの形態により任意に設定できることが好ましい。
【０１２８】
管理部６１６は、ユーザにインセンティブを提供するために、１ポイントあたりの価格ＰＭを、課金部６１２が事業者から集めた金額の合計ＭＳと、図２５の獲得ポイント総数欄６１４ｅに保持されている全ユーザＩＤが獲得したポイント総数ＴＰとから、ＰＭ＝ＭＳ／ＴＰ（円／ポイント）として求めてもよい。こうして算出した１ポイントあたりの価格ＰＭと、同じくユーザＩＤ欄６１４ａに対応付けて、獲得ポイント数欄６１４ｂに保持されているユーザの獲得ポイントＵＰから、
【０１２９】
「インセンティブ（円）＝ＵＰ（ポイント）×ＰＭ（円／ポイント）」として算出してもよい。
【０１３０】
図２０に戻り、通知部６１８は、ユーザに対して、地域別、あるいは、複数のホテルなど競い合う事業者の端末装置に配信したユーザＩＤ数を、例えば携帯情報端末や電子メールなどを使って通知してもよい。これにより、ユーザが行きたい場所とインセンティブの基礎となるポイント獲得の可能性の両方を目安に行動する利用者を誘導することに活用できる。
【０１３１】
これらの装置を備えるユーザ管理システム６５０により、ユーザにインセンティブを提供できる。図１９のユーザ管理システム６５０では、配信装置６００は単体であるが、複数設けられていてもよい。例えば、ユーザＩＤの種類ごとに配信装置６００を設け、第１端末装置６３０ａや第２端末装置６３０ｂに種類の異なるユーザＩＤを配信してもよい。また別の態様としては、例えば、第１端末装置６３０ａを、更に配信装置６００に置き換えて配信する方法である。これは、本来、一つの端末装置に商店街の小さな店舗が配信先データベース６０８で契約するＩＤ数は少なく顧客誘導の効果が薄い場合に活用する。例えば、○○商店街が共同して顧客を誘導する戦略に活用できる。その他、デパートやショッピングモールや遊園地やテーマパークあるいは臨時的に一定期間主催されるお祭りやイベント会場などに配信装置６００を設置することで狭いエリア内でも確実に全利用者のユーザＩＤが配信されていることをアピールし顧客誘導することが可能となる。
【０１３２】
＜発券管理システム＞
図２６は、図１９のユーザ管理システム６５０を組み込んだ発券管理システム５００の構成図である。本図で、図１と同一の符号を付した構成は、図１で説明した同一の符号の構成と機能、および内部構成がほぼ同じである。異なる機能や構成について説明する。本図で、図１９の第１端末装置６３０ａに該当するのが、入場側改札装置３４、退場側改札装置３６、および事業者端末１４である。配信装置６００は、乗車管理システム３０および事業者端末１４に、第１パス４２ならびに第２パス４４の識別情報（以下、「パスＩＤ」という）を配信する。事業者端末１４は、図２３を用いて説明した第１端末装置６３０ａと同一の構成を有する。
【０１３３】
乗車管理システム３０ａは、鉄道会社の路線上の全駅を管理する管理システムである第２統括装置４０を有する。この第２統括装置４０の内部に、配信装置６００から最初に配信される複数のパスＩＤを受信して保持する第２分配部６５２を有する。駅管理システム３０ａは、複数の入場側改札装置３４および退場側改札装置３６を管理する管理システムである第１統括装置３８を有する。この第１統括装置３８の内部に、第２分配部６５２から配信される複数のパスＩＤを受信して保持する第１分配部６５４を有する。第１分配部６５４は、保持する複数のパスＩＤを入場側改札装置３４および退場側改札装置３６に順次に配分する。
【０１３４】
図２７は、入場側改札装置３４の内部構成図である。本図で、図３と同一の符号を付した構成は、図３で説明した同一の符号の構成と機能がほぼ同じである。異なる機能を有する構成について説明する。受信部６５６は、配信装置６００から配信されたパスＩＤを、第１統括装置３８を介して受信する。パスＩＤデータベース６５８は、受信したパスＩＤを保持する。判定部５４は、取得部５２が読出部５０を介して取得した第１パス４２または第２パス４４のパスＩＤを照合部６６０に出力する。照合部６６０は、判定部５４から供給されたパスＩＤがパスＩＤデータベース６５８に保持されているか否かを判定する。そして、含まれている場合を「当選」として、通知部６６はその旨をユーザに通知するとともに、提供部６６２は配信装置６００に提供するポイント数を送信する。図示しないが、退場側改札装置３６が図２７の入場側改札装置３４と同様の構成を有してもよい。
【０１３５】
他の例では、図２６の第１分配部６５４が改札装置に分配するときに、コピーして配分することで、配分前のパスＩＤを複数保持する格納部を有する。そして、図２７の照合部６６０は、受信したパスＩＤがパスＩＤデータベース６５８に保持されていない場合に、第１分配部６５４の格納部に保持されているパスＩＤに基づいて照合処理を行ってもよい。これにより、通過する改札装置で当選しなくても、駅全体に配信されているパスＩＤでは当選する確率を高くすることでインセンティブを提供する機会を増やすことが可能となる。このとき、照合に利用した上位格納部を入場側改札装置３４のパスＩＤデータベース６５８とし、下位格納部を第１分配部６５４として、上位か下位のいずれで当選したかにより、また、当選したパスＩＤの数により、ユーザが獲得できるポイント数を変えてもよい。これら、ユーザが獲得したポイント数を提供部６６２から配信装置６００に送信し、所定期間に獲得したポイント数に応じてインセンティブを提供してもよい。
【０１３６】
このように図１の発券管理システム５００に、ユーザ管理システム６５０を組み込むことで第１パス４２および第２パス４４が鉄道利用を拡大することが期待できる。また、パスＩＤの配信数を様々な駅の入場側改札装置３４または退場側改札装置３６で増減して配信することで、ユーザを所定の地域に誘導できる。
【０１３７】
＜ウェブサイトでの利用＞
ネットワーク上には、例えば商品の販売をするショッピングサイト、アンケートやクイズを提供するサイト、ニュースを提供するサイト、検索サイトなど、ユーザに所定のサービスを提供するウェブサイトが無数に存在し、ユーザを自らのウェブサイトに誘導することが事業者の課題になっている。図１９を用いて説明したユーザ管理システム６５０を導入することにより、ユーザをウェブサイトに誘導できる。
【０１３８】
図２８は、図１９のユーザ管理システム６５０に設けられた端末装置としての情報処理装置６７０の構成図である。本図において、図２３を用いて説明した構成と、同一の符号を付した構成は機能が同じである。機能が異なる構成について以下に説明する。ウェブページ格納部６７６は、ユーザに提供する例えばショッピング、ニュースなどのウェブページを格納する。ページ出力部６７４は、ユーザの指示に基づいてウェブページ格納部６７６からウェブページを読み出し、ユーザ端末に送信する。また、ページ出力部６７４は、送信したウェブページを特定する情報、ユーザ端末を特定する情報（以下、「装置ＩＤ」という）などを検出部６７２に出力する。「装置ＩＤ」は、例えば、ＩＰアドレス、ユーザが情報処理装置６７０に最初にアクセスしたときに個別に生成した特定情報などであってよい。例えば「個別に生成した特定情報」は、装置ＩＤとしてクッキーなどを利用してユーザ端末に格納され、ウェブページを要求する毎にページ出力部６７４に読み取られる。
【０１３９】
検出部６７２は、個々のユーザのアクセス状況を装置ＩＤに基づいて検出し、所定の状態になった場合に読取部６３８にユーザＩＤを取得することを指示する。検出部６７２は、ユーザがページのリンクを所定の回数辿った場合やユーザが所定のページに到達した場合に、例えば、一定量の広告を閲覧したと判断して、ユーザＩＤの取得と指示してもよい。ショッピングサイトにおいては、ユーザが商品の購入をした場合に取得を指示してもよい。
【０１４０】
読取部６３８は、検出部６７２から指示があった場合にユーザＩＤを要求する。この要求は、例えばユーザ端末にユーザＩＤの入力を要求する画面を表示させることで行ってよい。照合部６３６は、そのユーザＩＤに基づいて照合処理を行う。これにより、ウェブサイトにおいても、ユーザにインセンティブを提供できる。
【０１４１】
【発明の効果】
本発明によれば、ユーザインセンティブを提供し、利便性、娯楽性の高いユーザ管理技術を提供できる。
【図面の簡単な説明】
【図１】発券管理システムの構成図である。
【図２】図２（ａ）は、図１の第１パスおよび第２パスを説明するための図である。図２（ｂ）は、図１の第１パスが保持するデータ構造の一例である。図２（ｃ）は、図１の第２パスが保持するデータ構造の一例である。
【図３】図１の入場側改札装置の内部構成図である。
【図４】図３の入場側改札装置における入場処理のフローチャートである。
【図５】図１の退場側改札装置の内部構成図である。
【図６】図５の退場側改札装置における退場処理のフローチャートである。
【図７】図１の第１管理装置の内部構成図である。
【図８】図７の個人情報データベースのデータ構造の一例を示す図である。
【図９】図７のパス管理データベースのデータ構造の一例を示す図である。
【図１０】図７の第１利用情報データベースのデータ構造の一例を示す図である。
【図１１】図７の候補者抽出部における処理を説明するための図である。
【図１２】図７の発券枚数設定部により作成される第２パスの配布表の一例を示す図である。
【図１３】図７の候補者データベースのデータ構造の一例を示す図である。
【図１４】図７の第２利用情報データベースのデータ構造の一例を示す図である。
【図１５】図１の第２管理装置の内部構成図である。
【図１６】図１５の消費情報データベースのデータ構造の一例を示す図である。
【図１７】図１５の事業者情報データベースのデータ構造の一例を示す図である。
【図１８】図１の入場側改札装置の別の内部構成図である。
【図１９】実施の形態に係る、ユーザ管理システムの構成図である。
【図２０】図１９の配信装置の内部構成図である。
【図２１】図２０のサーバ側識別情報データベースのデータ構造の一例を示す図である。
【図２２】図２０の配信先データベースのデータ構造の一例を示す図である。
【図２３】図１９の第１端末装置の内部構成図である。
【図２４】図２３のクライアント側識別情報データベースのデータ構造の一例を示す図である。
【図２５】図２０のポイント蓄積部のデータ構造の一例を示す図である。
【図２６】配信装置を有する発券管理システムの構成図である。
【図２７】図２６の入場側改札装置の内部構成図である。
【図２８】図１９のユーザ管理システムに設けられる情報処理装置の内部構成図である。
【符号の説明】
１２ 事業者紹介装置、１４ 事業者端末、１６ 第１発券装置、１８ 第２発券装置、３４ 入場側改札装置、３６ 退場側改札装置、４２ 第１パス、４４ 第２パス、１００ 第１管理装置、１０２ 第１利用情報収集部、１０４ 第２利用情報収集部、１１０ 第１利用情報データベース、１１２ 第２利用情報データベース、１２０ 候補者抽出部、１２２ 価格算出部、１２６ 発券枚数設定部、１３０ 第１発券処理部、１３２ 第２発券処理部、１３４ 確定部、１３６ 販売状況監視部、１４２ 通知部、１４６ 販売額算出部、２００ 第２管理装置、２０２ 消費情報収集部、２０４ 前納金額情報データベース、２０６ 事業者情報データベース、２０８ 前納金分配処理部、２１０ 消費情報データベース、２１２ 事業者選択部、２１４ 通知部、２１６ 判定部、２１８ 条件格納部、５００ 発券管理システム、６００ 配信装置、６０２ サーバ側識別情報データベース、６０４ 選択部、６０６ 指示部、６０８ 配信先データベース、６３４ クライアント側識別情報データベース、６３６ 照合部、６４０ 提供部、６５０ ユーザ管理システム、６７０ 情報処理装置、６７２ 検出部。
Claims (5)
- ユーザに対して所定のサービスを提供するユーザ管理システムであって、
当該システムは、配信装置と端末装置とを含み、
前記配信装置は、
複数のユーザにそれぞれ対応付けられた識別情報を保持する第１格納部と、
前記第１格納部から所定の手順を経てユーザの識別情報を選択する選択部と、
選択した識別情報を、前記端末装置に送信する送信部と、
を有し、
前記端末装置は、
前記送信部から識別情報を受信する受信部と、
受信した識別情報を格納する第２格納部と、
前記サービスの提供を受けるためにユーザが現れた場所にて、そのユーザの識別情報を読み取る読取部と、
前記読み取った識別情報が前記第２格納部に含まれているか否かを判定する照合部と、
照合結果に基づいてユーザにインセンティブを提供する提供部と、
を有することを特徴とするユーザ管理システム。 - 前記サービスの提供を受けるためにユーザが所定の媒体を提示したとき、この媒体に保持されているユーザの情報をそのユーザの識別情報として読取り、前記サービスが提供される流れの中で前記インセンティブが提供されることを特徴とする請求項１に記載のユーザ管理システム。
- 当該システムは複数の端末装置を備え、前記選択部は、端末装置ごとに独立して前記第１格納部から識別情報を選択することを特徴とする請求項１または２に記載のユーザ管理システム。
- 識別情報の付されたパスを利用する乗車管理システムにおいて、
駅構内に設けられた複数の改札装置と、
前記改札装置に、発行済みのパスに付した識別情報を配信する配信装置と、
を備え、
前記配信装置は、
発行済みのパスの識別情報を保持する第１格納部と、
前記第１格納部から識別情報を選択する選択部と、
選択した識別情報を、駅構内に設けられた複数の改札装置の少なくとも１台に送信する送信部と、
を有し、
前記改札装置は、
ネットワークを介して前記識別情報を受信する受信部と、
受信した識別情報を格納する第２格納部と、
駅構内への入場または退場のために、ユーザが提示したパスに付与された識別情報を読み取る読取部と、
前記読み取った識別情報が前記第２格納部に保持されているか否かを判定する照合部と、
照合結果に基づいて、そのパスを所有するユーザにインセンティブを提供する提供部と、
を有することを特徴とする乗車管理システム。 - ユーザに対して所定のサービスを提供するユーザ管理システムであって、
当該システムは、配信装置とウェブコンテンツを提供する情報処理装置とを含み、
前記配信装置は、
複数のユーザにそれぞれ対応付けられた識別情報を保持する第１格納部と、
前記第１格納部から所定の手順を経てユーザの識別情報を選択する選択部と、
選択した識別情報を、前記情報処理装置に送信する送信部と、
を有し、
前記情報処理装置は、
前記送信部から識別情報を受信する受信部と、
受信した識別情報を格納する第２格納部と、
ユーザからの要求に基づいて、前記ウェブコンテンツをそのユーザの閲覧装置に送信するページ出力部と、
前記ウェブコンテンツの送信を検出する検出部と、
前記検出部がウェブコンテンツの送信を検出した場合に、そのウェブコンテンツを要求したユーザの識別情報を読み取る読取部と、
前記読み取った識別情報が前記第２格納部に含まれているか否かを判定する照合部と、
照合結果に基づいてユーザにインセンティブを提供する提供部と、
を有することを特徴とするユーザ管理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002195026A JP2004038576A (ja) | 2002-07-03 | 2002-07-03 | ユーザ管理システム、およびそのシステムを利用した乗車管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002195026A JP2004038576A (ja) | 2002-07-03 | 2002-07-03 | ユーザ管理システム、およびそのシステムを利用した乗車管理システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004038576A true JP2004038576A (ja) | 2004-02-05 |
Family
ID=31703568
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002195026A Pending JP2004038576A (ja) | 2002-07-03 | 2002-07-03 | ユーザ管理システム、およびそのシステムを利用した乗車管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004038576A (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007086942A (ja) * | 2005-09-21 | 2007-04-05 | Aantsusha:Kk | 商取引システムおよび方法並びにプログラム |
| JP2007304925A (ja) * | 2006-05-12 | 2007-11-22 | Hitachi Ltd | 交通チケット運用管理システム |
| JP2010092311A (ja) * | 2008-10-09 | 2010-04-22 | Bitwallet Inc | 店舗端末、及び情報処理サーバ |
| JP2018018367A (ja) * | 2016-07-29 | 2018-02-01 | 株式会社Ihi | 認証システム、認証方法、および認証プログラム |
| JP2022038916A (ja) * | 2020-08-27 | 2022-03-10 | トヨタ自動車株式会社 | 情報提供システム、情報提供装置および情報提供プログラム |
| JP7223184B1 (ja) | 2022-03-03 | 2023-02-15 | Kddi株式会社 | 情報処理装置及び情報処理方法 |
-
2002
- 2002-07-03 JP JP2002195026A patent/JP2004038576A/ja active Pending
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007086942A (ja) * | 2005-09-21 | 2007-04-05 | Aantsusha:Kk | 商取引システムおよび方法並びにプログラム |
| JP4756144B2 (ja) * | 2005-09-21 | 2011-08-24 | 和秀 有川 | 商取引システムおよび方法並びにプログラム |
| JP2007304925A (ja) * | 2006-05-12 | 2007-11-22 | Hitachi Ltd | 交通チケット運用管理システム |
| JP2010092311A (ja) * | 2008-10-09 | 2010-04-22 | Bitwallet Inc | 店舗端末、及び情報処理サーバ |
| JP2018018367A (ja) * | 2016-07-29 | 2018-02-01 | 株式会社Ihi | 認証システム、認証方法、および認証プログラム |
| JP2022038916A (ja) * | 2020-08-27 | 2022-03-10 | トヨタ自動車株式会社 | 情報提供システム、情報提供装置および情報提供プログラム |
| JP7223184B1 (ja) | 2022-03-03 | 2023-02-15 | Kddi株式会社 | 情報処理装置及び情報処理方法 |
| JP2023128452A (ja) * | 2022-03-03 | 2023-09-14 | Kddi株式会社 | 情報処理装置及び情報処理方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4475455B2 (ja) | アトラクション入場管理方法及び装置 | |
| US6732922B2 (en) | System enablement of automatic fare collection devices using a network | |
| US20160300162A1 (en) | Apparatus and method for managing access to a resource | |
| US20010016825A1 (en) | Electronic ticketing and reservation system and method | |
| JP2007503066A (ja) | クレジットカードの特典プログラムシステムおよび方法 | |
| CN110245762A (zh) | 兴趣预约管理的通信方法和移动终端以及服务器和系统 | |
| JP2004038576A (ja) | ユーザ管理システム、およびそのシステムを利用した乗車管理システム | |
| KR20210030065A (ko) | 멤버십 공유 시스템 및 방법 | |
| JP2004151911A (ja) | 運賃精算方法 | |
| JP3682448B2 (ja) | 発券管理システムおよび管理装置 | |
| JP2022137424A (ja) | 販売促進システム、販売促進方法、及び、販売促進プログラム | |
| JP2010165307A (ja) | ポイント管理装置 | |
| JP2023146787A (ja) | 情報処理装置及び情報処理方法 | |
| JP2004326554A (ja) | 情報処理装置、改札機、決済端末及び乗車券システム | |
| JP5717085B2 (ja) | マーケティングデータ作成装置およびコンピュータプログラム | |
| WO2023127030A1 (ja) | サービス管理装置、サービス管理方法、およびプログラム | |
| JP7235264B1 (ja) | 情報処理システム、方法、装置 | |
| WO2004068416A1 (ja) | 発券管理システム | |
| JP2004334435A (ja) | 端末機器及び旅行案内システム | |
| JP4707852B2 (ja) | 一括発券システム | |
| JP2008134759A (ja) | 情報配信装置、情報配信システム、および情報配信方法 | |
| JP2023080889A (ja) | 共通基盤システムおよび共通基盤プログラム | |
| JP2024040361A (ja) | 交通系サーバおよびコンピュータプログラム | |
| JP3548827B2 (ja) | 情報配信システム及び方法 | |
| Cure | East Texas Council of Governments: GoBus Fare Collection |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050628 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080212 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080610 |