JP2005332222A - 便益提供システム及びその方法及びプログラム - Google Patents

Abstract

【課題】 利用者に特別の恩恵を与える便益提供において、提供者及び利用者双方の作業労力を大幅に削減できると共に、本人に限って活用できる便益提供システム及びその方法及びプログラムを提供する。
【解決手段】 通学定期券の発行を希望する学生から、予約情報を受付けて記憶及び管理する中央管理装置７と、インターネット２を介して中央管理装置７に接続され、予約情報を中央管理装置７に申請する第１情報端末４と、インターネット２を介して中央管理装置７に接続され、個人情報を含む前記予約情報の正当性を判定して、その判定結果を中央管理装置７に通知する第２情報端末５と、前記予約情報が正当である旨の通知が確認された後、中央管理装置７によって付与された承認コードを便益希望者が提示することを条件に、中央管理装置７に管理されている予約情報に基づいた通学定期券を発行する自動券売機８とを備える。
【選択図】 図１

Description

本発明は、通学定期券の発行のように利用者に特別の恩恵を与える便益提供において、利用者及び提供者双方の作業労力を大幅に削減できると共に、通学定期券などを円滑に発行できる便益提供システムに関する。

バスや電車の旅客業においては、従来から特別に高い割引率の通学定期券を発行しており、このサービスによって各家庭の教育費の軽減に大きく寄与してきた。この折角の学生支援サービスも、これが悪用されぬよう適切な管理が必要であり、従来は、学校から学割用の特別の証明書を発行してもらっていた。そして、通学定期券の購入時には、学生は、必要事項を記入した定期券申込み用紙と共に、この証明書を駅窓口に示す必要があり、一方、提示を受けた駅係員は、その証明書の真偽を確認すると共に、発行する定期券について発行日や有効期間などを追加して証明書に記入していた。

しかしながら、上記の作業は学生にとっても駅係員にとっても負担が大きく、特に、定期券の申込みが殺到する年度始めや正月開けは、駅窓口に長蛇の列ができる大きな原因となり、社会人も含め、実際に定期券をうけるのに長時間を要するのが実情であった。

しかも、学割用の証明書は、単なる紙の書面であるので、年度などを示す数値を改ざんされるおそれもあり、卒業生でありながら、学割定期の恩恵を受け続けるような事態も心配されるところである。更にまた、従来の方法では、学生による定期券の利用状況を学校では全く把握できないので、通学定期券の不正転売などを心理的に抑制することさえできず、この点も教育指導的な観点から大きな問題であった。

なお、上記の問題点は、単に通学定期券に限らず、他の割引券などにおいても共通する部分が多く、そのため、これら証票を円滑迅速に発行できると共に本人だけが利用できる便益提供システムが望まれるところである。

この発明は、これらの問題点に鑑みてなされたものであって、利用者に特別の恩恵を与える便益提供において、提供者及び利用者双方の作業労力を大幅に削減できると共に、本人に限って活用できる便益提供システム及びその方法及びプログラムを提供することを目的とする。

上記の目的を達成するため、本発明に係る便益提供システムは、証票の発行又は役務の提供を希望する便益希望者から、予約情報を受付けて記憶及び管理する中央管理装置（７）と、汎用通信回線（２）を介して前記中央管理装置に接続され、前記予約情報を前記中央管理装置に申請する第１情報端末（４）と、汎用通信回線（２）を介して前記中央管理装置（７）に接続され、個人情報を含む前記予約情報の正当性を判定して、その判定結果を前記中央管理装置に通知する認証者の第２情報端末（５）と、前記予約情報が正当である旨の通知が確認された後、前記中央管理装置（７）によって明示的に付与された承認コードか、或いは、前記認証者又は便益提供者から非明示的に予め付与されている個人コードを便益希望者が提示することを条件に、前記中央管理装置（７）に管理されている予約情報に基づいた証票の発行又は役務の提供により便益を実現する発行端末（８）と、を備えることを特徴とする便益提供システム、を備えている。

ここで、中央管理装置、第１情報端末、第２情報端末、及び発行端末は、全てコンピュータ機器である。なお、発行端末は、必ずしも、何らかの有体物を発行する必要はなく、中央管理装置からの指示に基づいて、割引などの便益希望者の望むサービスを許可するものであっても良い。なお、本発明に係るプログラムは、上記システムにおいて中央管理装置で動作するソフトウェアであり、また、これを記憶した記憶媒体である。

また、本発明に係る便益提供方法は、証票の発行又は役務の提供を希望する便益希望者から、予約情報を受付けて記憶及び管理する中央管理装置（７）と、汎用通信回線（２）を介して前記中央管理装置に接続され、前記予約情報を前記中央管理装置に申請する第１情報端末（４）と、汎用通信回線（２）を介して前記中央管理装置（７）に接続され、個人情報を含む前記予約情報の正当性を判定して、その判定結果を前記中央管理装置に通知する認証者の第２情報端末（５）と、前記予約情報が正当である旨の通知が確認された後、前記中央管理装置（７）によって付与された承認コードか、或いは、前記認証者又は便益提供者から非明示的に予め付与されている個人コードを便益希望者が提示することを条件に、前記中央管理装置（７）に管理されている予約情報に基づいた証票の発行又は役務の提供により便益を実現する発行端末（８）と、を備えて、便益希望者による予約情報の申請手続きと、便益希望者の在籍団体である認証者の予約情報の認証手続きと、便益提供者による便益希望者及びその在籍団体に対する電子的な連絡手続きを含んだ管理手続きとの協働によって円滑に便益を提供している。

上記各発明において、前記個人情報には、便益希望者の電子メールアドレスが含まれており、前記中央管理装置に予約情報が受付けられると、受付けられたことを示す確認情報が前記電子メールアドレスに向けて発信されるよう構成されるのが好ましい。同様に、前記個人情報には、便益希望者の電子メールアドレスが含まれており、前記中央管理装置は、予約情報が正当性を確認する判定結果を第２情報端末から受けたことを条件に承認コードを生成して、これを前記電子メールアドレスに向けて発信するよう構成されるのが好ましい。

上記各発明において、前記中央管理装置に受付けられた予約情報は、一定期間内の受付け総件数として前記第２情報端末に伝送されるよう構成されるのが好ましく、また、前記発行端末は、発行済みの証票と交換に、本人確認の他の手続きを要することなく新規の証票を発行するよう構成されるのが好ましい。

好ましい中央管理装置には、申請された予約情報の登録欄と、予約情報の認証状態を示すステータス欄と、中央管理装置から付与される承認コードの登録欄とを有する記憶部が設けられ、前記予約情報には、便益希望者が在籍する所属団体と、便益希望者の電子メールアドレスとが含まれており、前記第１情報端末から申請された形式ミスのない予約情報のみを前記登録欄に記憶すると共に、前記ステータス欄に申請中フラグを記憶する第１手段と、前記第１手段によって前記登録欄に予約情報が記憶されると、その予約情報に含まれる電子メールアドレス宛に申請確認メールを発信する第２手段と、申請中フラグを有する予約情報を一定時間毎に抽出すると共に、これを予約情報に含まれる所属団体毎に集計して、集計された予約情報の総件数を各所属団体宛に発信する第３手段と、第３手段による通知を受けた後、前記第２情報端末を前記中央管理装置に接続し、正当権利者の認証を受けた後、前記総数分の予約情報の閲覧を可能にする第４手段と、予約情報の閲覧の後、予約情報の全部又は一部であって受益希望者の属する団体が認証すべき事項を判定して、この判定結果を前記中央管理装置に通知する第５手段と、通知された判定結果に基づき、前記ステータス欄の申請中フラグを承認フラグ又は却下フラグに変更すると共に、承認フラグに変更した場合には当該予約情報の正当性を一意に特定する承認コードを生成して前記記憶部の該当欄に記憶する第６手段と、前記承認コードが提示された場合には、提示された承認コードと予約情報とが正当に対応することを前記記憶部の記憶内容に基づいて確認した後、予約情報に対応する証票を発行する第７手段と、が備えられている。

また、好ましい中央管理装置には、申請された予約情報の登録欄と、予約情報の認証状態を示すステータス欄とを有する記憶部が設けられ、前記予約情報には、便益希望者が在籍する所属団体と、便益希望者の電子メールアドレスと、便益希望者の個人情報とが含まれており、前記と同様の第１手段〜第５手段に加えて、通知された判定結果に基づき、前記ステータス欄の申請中フラグを承認フラグ又は却下フラグに変更する第８手段と、前記個人情報と一対一に対応し、非明示的に記録されている個人コードを便益希望者の個人カードから読み取り、読み取った個人コードと予約情報とが正当に対応することを前記記憶部の記憶内容に基づいて確認した後、予約情報に対応する証票を発行する第９手段とが備えられている。

また、前記予約情報には、便益希望者が申請したパスワードが含まれており、前記発行端末には、少なくともパスワードが提示されることを条件に予約した便益が提供されるのが好ましく、発行される証票は、通学定期券であるのが典型例である。

本発明によれば、提供者及び利用者双方の労力を大幅に削減できると共に、本人に限って活用できる便益提供システム及びその方法及びプログラムを提供できる。

以下、実施例に基づいて本発明を更に詳細に説明する。図１は、実施例に係る通学定期券の発行システムＳＹＳを示すシステム構成図である。図示の通り、この通学定期券発行システムＳＹＳは、移動体通信網１と、インターネット通信網２と、社内ネットワーク３とを介して、各種のコンピュータ機器が接続されて構成されている。なお、コンピュータ機器間の通信プロトコルは、ＳＳＬ（Secure Sockets Layer）などの通信安全性の高いものが採用される。

各種のコンピュータ機器には、この実施例では、移動体通信網１又はインターネット通信網２に接続可能な学生所有の情報端末４と、インターネット通信網２に接続可能な学校所有の情報端末５と、インターネット通信網２に接続されたメールサーバ６と、インターネット通信網２に接続された事業者所有の中央管理装置７と、社内ネットワーク３を介して中央管理装置７に接続された券売機８とが該当する。

学生所有の情報端末４は、典型的には、ＷＥＢブラウザ(World Wide Web Browser)とメーラー(Mailer)とを内蔵した携帯電話機ＭＢ又はパソコンＰＣｉであり、原則として、本システムＳＹＳを利用して定期券を購入する学生が所有する必要がある。但し、学校に設置されたパソコンＰＣｉの使用を学生に開放しても良いのは勿論である。なお、ＷＥＢブラウザは、ＨＴＴＰプロトコルによるファイル転送を行ない、ＨＴＭＬで記述されたハイパーテキストを解読して表示できるものであれば、特に限定されないが、パソコンＰＣｉ用としては、典型的には、Netscape Navigator（登録商標）やMicrosoft Internet Explorer（登録商標）が該当する。また、メーラーは、電子メールを送受信するソフトウェアであれば特に限定されないが、パソコンＰＣｉ用としては、Netscape Mail 、Microsoft Outlook Express（登録商標）、Eudoraなどが好適に採用される。但し、携帯電話機ＭＢのメーラーやＷＥＢブラウザは、各社独自のソフトウェアが好適に使用される。

学校所有の情報端末５は、在籍する学生の管理データである学生管理マスタＳＴＵを有する大型記憶装置に接続されたパソコンＰＣｊで構成されている。また、メールサーバ６は、ＳＭＴＰ(Simple Mail Transfer Protocol)サーバ及びＰＯＰ(Post Office Protocol)サーバとして機能するコンピュータ機器である。

中央管理装置７は、ファイヤウォールＦＷを介してインターネット通信網２に接続されるＷＥＢサーバ９と、社内ネットワーク３に接続されたホストコンピュータ１０と、ＷＥＢサーバ９やホストコンピュータ１０からアクセスされるデータベースサーバ１１とで構成されている。データベースサーバ１１は、最寄りの駅名や５０音の先頭文字によって正式の大学名称を抽出可能な学校マスタと、全ての発着駅の組み合わせについて通学路線及び通学定期運賃を記憶する路線マスタと、学生からの申請データを記憶する学割管理マスタＭＮＧとを備えている。学割管理マスタＭＮＧには、情報端末４から受けた学生申請データを記憶する他、情報端末５から受けた学校担当者による承認／却下の情報も記憶する。また、学校担当者に承認された学生申請データは、データベースサーバ１１の学割管理マスタＭＮＧからホストコンピュータ１０の総合管理マスタＭＡＩＮに転記されるようになっている。

図６は、学割管理マスタＭＮＧの一部を図示したものであり、ステータス、学校名、学籍番号、発駅、着駅、住所、メールアドレス、氏名、性別、生年月日、申請日、判定日、承認番号、却下理由、判定者、申請回数、発行期限などが、所定のコードで記載されている。ここで、ステータスは、「申請中」、「承認済み」、「却下」に区分されている。

「申請中」とは、学生からの申請データを受け付けて記憶したが、まだ学校の承認を受けていない状態を意味する。この「申請中」の状態では、学生が申請した内容と、累積申請回数（申請毎に＋１される）とが記憶されているに止まり、その他の判定日、承認番号、却下理由、判定者などは未記入の状態である。

一方、「承認済み」とは、学生から申請された内容が学校担当者によって承認された状態を意味し、承認番号の他に、判定日、却下理由、判定者、発行期限が、所定のコードで規定されている。本システムＳＹＳの運用において、この承認番号が重要な意味を持ち、券売機８では、この承認番号を拠りどころにして本人確認をして定期券を発行する。

なお、「却下」とは、学生から申請された内容が学校担当者によって承認されなかった状態を意味する。却下理由は、学校担当者によって検出された申請住所の不実記載や、発着駅の申請不備などであり、本来の学生住所と定期券の申請区間の不整合が典型例である。

続いて、図１の発行システムＳＹＳを利用して通学定期券の発行を受けるまでの手続きを説明する。

＜学生による申請手続き（図２）＞
先ず、図２を参照しつつ、学生による申請手続きを説明する。本システムＳＹＳを利用するには、毎年、年度始め（学年初めの４月）に、学生自身によって定期券購入のための申請手続きを行う必要がある。申請手続きでは、携帯電話機ＭＢ又はパソコンＰＣｉをインターネット通信網２に接続して、鉄道事業者などのＷＥＢサーバ９をアクセスし、申請用の画面（ＨＴＭＬファイル）をダウンロードすることから始める（図２のアクションＡ１−１及びＡ２−１を参照）。

そして、ＷＥＢブラウザが描いた申請用画面において、学生自身の操作によって、必要な個人情報を入力する。具体的には、学生の氏名（漢字＋カナ）、性別、生年月日、電話番号、郵便番号、住所、メールアドレス、学校名、学籍番号、通学用の乗車区間（発駅＋着駅）を申請用画面上で特定する。なお、メールアドレスとしては、必ず、学校から付与されたものか、学校から承認された個人メールアドレスを記入することとする。これは、本人確認の手段として、電子メールのアドレスを活用するので、このメールアドレスの正当性を学校担当者に確認してもらうためである。つまり、本システムでは、学生が申請するメールアドレスが、その学生に学校から付与されたメールアドレスと一致するか、或いは、学校に申請して承認された真正な個人メールアドレスと一致することが確認され、且つ、その他の情報「氏名、住所、学籍番号…」の正当性が確認される。そして、学生の申請内容が学校に承認されることを条件に定期券の発行が可能となる。

ところで、乗車区間の発駅は、学生の住所に対応して決定される場合が多く、着駅は学校の住所に対応して決定される場合が多いが、複数の事業者の路線を乗り継いで自宅から学校に通う場合もあり、その場合には、学生が使用する通学路線の一部が、本システムＳＹＳで申請する乗車区間（発駅＋着駅）となる。

また、決定された発着駅の組み合わせに対して、乗車区間が複数通りある場合もあるが、データベースサーバ１１には、全ての発駅と全ての着駅との間の乗車区間を特定するデータを路線マスタに用意しているので、ＷＥＢサーバ９は、リンクを辿ったＷＥＢブラウザからの問合せに応じて（アクションＡ１−２）、これを提示するようにしている（アクションＡ２−２）。つまり、この実施例では、本システムＳＹＳで対応可能な総数Ｎ個の駅について、路線マスタは、Ｎ×（Ｎ−１）／２の発着駅の全組み合わせに関し、運賃データと路線データを持っている。

そのため、例えば、図７のように、学校がｃ駅の近くにあり、学生の自宅がａ駅の近くにあるような場合、ａ駅とｃ駅とを学生が特定してＷＥＢサーバ９に指定すると、鉄道事業者が許容する場合には、ａ駅−ｂ駅−・・・・ｃ駅の路線と、ｂ駅を経由しないａ駅−・・・ｃ駅の２つの路線が自動的に提示され、任意の一方を学生が選択できることになる。この複数通りの路線の提示において、ＷＥＢサーバ９は、路線マスタをアクセスするだけであって、路線検出のための演算処理が不要であるので、必要な情報を直ちに提示できる。

このように、学生はＷＥＢブラウザとＷＥＢサーバの会話を通して、必要な情報を得つつ、ＷＥＢブラウザの管理下で申請内容を記入する。なお、学校名は、最寄り駅や５０音の先頭数文字を指定してＷＥＢサーバ９に問合せると（アクションＡ１−２）、プルダウンメニューを備えるリンク画面において候補が提示される（アクションＡ２−２）。同様に、発駅や着駅も、路線名や地域を指定してＷＥＢサーバに問合せて候補を得ることができるようになっている。

このような手順を経て、ＷＥＢブラウザの管理下で入力された個人情報は、最後に、ＨＴＭＬのＦＯＲＭアクションなどによってＷＥＢサーバ９に伝送される（アクションＡ１−３）。そこで、次に、ＷＥＢサーバ９では、データベースサーバ１１の学割管理マスタＭＮＧをアクセスして、申請内容を申請内容ごとにエラーチェックする（アクションＡ３−１）。

先に説明したように、学割管理マスタＭＮＧは、図６のような構造であるが、ＷＥＢサーバ９では、必要に応じて学割管理マスタＭＮＧを参照しつつ、申請内容ごとにエラーチェックする。エラーチェックとしては、先ず、学割管理マスタＭＮＧのうち、ステータスが「却下」ではないものを検索し、学校名及び学籍番号が一致するデータが検出された場合には、重複申請として受付を拒否する。これは、学割管理マスタＭＮＧは、年度始めに作成又は更新された後は、住所変更や定期券の紛失などの特別な事情がない限り、変更を許可する必要がないからである。なお、本システムＳＹＳでは、住所変更や定期券の紛失の場合には、後述する専用の手続きを必要としている。

一方、ステータスが「却下」状態であれば、却下理由を解消させた重複申請であると推定して申請を受け付ける。なお、却下状態の申請データを削除しないのは、不実記載を繰り返す不真面目な学生を抽出できるようにするためである。また、通常一回であるはずの申請回数を、あえて累積計算して記憶するのは、住所変更や定期券の紛失を繰り返す学生を抽出できるようにするためである。

その他のエラーチェックとしては、「学籍番号やメールアドレスなどが、半角文字で記入されているか？」、「住所や氏名欄の文字が、文字コードとして不合理性がないか？」などの文法チェックであり、住所と発駅の不整合など記載内容の実質的なチェックは行わない。それは、交通の利便性や定期券代金の軽減化などの必要から、あえて最寄り駅以外の駅を発駅とする場合もあり、かかる申請の採否判断は学校に委ねるべきだからである。

例えば、図７の場合、学生がａ駅を発駅としない理由について、ＷＥＢサーバ９では不問とし、自転車などの利用によってｂ駅を発駅に設定できるようにしている。同様に、着駅についても、ｃ駅、ｅ駅、ｄ駅、その他の駅の選択をＷＥＢサーバ９では任意に許容している。このように本システムＳＹＳでは、発着駅の選択を申請者に委ねるので、自宅や学校の住所と発着駅との整合性を判定するアルゴリズムが不要となり、システム構築が容易であり、且つ、申請受付処理を迅速に進めることが可能となる。

以上のようなチェックの結果、受付拒否や文法エラーなどの情報が情報端末４に伝送され(アクションＡ２−３）、不備の是正された申請データが、再度、情報端末４からＷＥＢサーバ９に送信されることになる(アクションＡ１−３）。一方、不備のない申請データを受けたＷＥＢサーバ９では、申請内容を学生に最終確認してもらった上で（アクションＡ２−４，Ａ１−４）、これを学割管理マスタＭＮＧに登録する。なお、この状態の申請データのステータス欄は「申請中」である。

以上の処理が終われば、ＷＥＢサーバ９は、申請されたメールアドレス宛に、(1)学割用の申請データが登録されたこと、(2)学校によるチェックの後に正式の承認番号が通知されることに加えて、(3)申請内容を確認したい場合や削除したい場合（例えば、不注意による不実記載を削除したい場合）にアクセスすべきＵＲＬを通知する。なお、確認作業の容易化のために、申請された内容を電子メールに添付して送付しても良い。

このように本システムでは、申請された事実が電子メールで本人に通知されるので、例えば、「甲」がイタズラ心から同じ学校に在籍する「乙」になりすまして申請しても、申請された事実は「甲」ではなく「乙」に通知されるので、それ以上の不都合が生じない。この場合、「乙」は、直ちにイタズラされた申請データの削除手続きを採ることもできる。なお、「甲」が、「乙」の個人情報と「甲」のメールアドレスを用いて申請すると、申請された事実が「甲」に通知されるので、「乙」は把握できないが、その後の学校担当者のチェックによって不実の申請が判明するので、それ以上の不都合は生じない。

また、ＷＥＢサーバ９では、一日に一回、学割管理マスタＭＮＧを検索して、ステータスが「申請中」のデータを学校毎に集計して、申請件数を通知する電子メールを各学校宛に発信する（アクションＡ４）。なお、この電子メールは、学校関係者の操作に応じて情報端末５に取得されるが（アクションＡ６）、電子メールには、当日新たに追加された申請件数を特定して、未処理の総申請件数が記載されている。すなわち、電子メールでは、申請データの伝送はなく、専ら未処理の件数だけが通知される。これは、申請データを通知したのでは、担当者が何日分かまとめて処理しようとした場合に、申請データを紛失してしまう可能性があるからである。これに対して、本システムでは、未処理件数が毎日通知されてくるので、学校担当者は、未処理件数が適当数に達したタイミングで、まとめて承認作業を行うことができ、しかも申請データを消失させるおそれもない。

＜申請内容の閲覧又は削除手続き（図３）＞
次に、学校担当者による承認手続きを説明するに先立って、図３に基づいて、学生が申請内容を閲覧したり、或いは、申請内容を削除する手続きについて説明する。先に説明したように、申請手続きをとった学生には、電子メールによって申請を受け付けた旨の通知と共に、ＵＲＬが通知される（図２のアクションＡ５）。このＵＲＬは「http://www.*********.htm?+++++++」のように構成されており、記号「？」に続いて、申請者に固有の情報（クエリー文字列+++++++）が付加されている。

そのため、本システムＳＹＳでは、学割管理マスタＭＮＧのステータスが「申請中」であることを条件に、本人だけが申請内容を閲覧することができ、また申請内容を本人だけが削除することが可能となる。すなわち、クエリー文字列（+++++++）は、申請者を特定する文字列となっているので、本システムＳＹＳでは、電子メールで通知されたＵＲＬにアクセスした場合にだけ（このとき、ＷＥＢサーバには、自動的にクエリー文字列が伝送されるので）、申請内容の閲覧や削除が可能となる。なお、ＷＥＢサーバ９では、付与したクエリー文字列（+++++++）を、学割管理マスタＭＮＧの当該申請者に対応付けて記憶しており（図６参照）、クエリー文字列の一致しない学生データのアクセスは許可しない。このように、本システムＳＹＳでは、申請者に固有の文字列を自動的に付与し、電子メールによって通知するので、プライベート情報の漏洩がなく、また学生には有りがちなイタズラによって他人の申請データが削除されてしまうこともない。

なお、上記の説明では、申請中のデータを閲覧または削除する場合には、申請確認メールで伝送されてくるＵＲＬを使用したが（図２のアクションＡ５参照）、学生が直ちに手続きしない場合には、このＵＲＬを消失してしまう場合もある。かかる場合には、再度、ＷＥＢサーバ９に個人情報を伝送して（図３のアクションＡ２０）、電子メールでクエリー文字列（+++++++）が付加されたＵＲＬを受けることになる（アクションＡ２１）。その後の処理は、先の場合と同じであり（アクションＡ２２）、学割管理マスタＭＮＧのステータスが「申請中」であることを条件に、申請内容を閲覧でき、また申請内容を削除することができる（アクションＡ２３）。なお、申請内容が削除される前に、学校担当者が申請内容をチェックして承認してしまう可能性もあるが、かかる場合には、学生に対する承認番号の付与手続きが実行されないのは勿論である。

また、図３では、申請内容の閲覧手順について説明したが、再度、個人情報をＷＥＢサーバ９に伝送する上記と同じ手順によって、承認済みの申請データの内容を閲覧できるようにしても良い。

＜学校担当者による承認手続き（図４）＞
続いて、図４に基づいて、学校担当者による申請データの承認作業について説明する。メールサーバ６から連絡をうけた担当者が承認作業を行う場合には、ＷＥＢサーバ９をアクセスして、正当な担当者であることの認証用のＩＤとパスワードを該当ページに入力する。すると、ＷＥＢサーバ９では、学割管理マスタＭＮＧのうち、該当する学校の申請データであって、且つステータスが「申請中」の申請データを抽出し、一覧表としてＷＥＢブラウザに閲覧可能に送信する（図４のアクションＡ７）。

そこで、学校担当者は、情報端末５に表示された一覧表を確認しながら、申請内容の正当性をチェックする。チェック内容としては、学籍番号、住所、メールアドレス、氏名、性別、生年月日の組み合わせの正当性の他に、学生住所と対比した場合の発駅選択の合理性、及び、学校住所と対比した場合の着駅選択の合理性である。そして、全てのチェック項目に問題がなければ、情報端末５に描かれた一覧表の承認欄にチェックマークを入れる。

一方、例えば、図７において「甲」から、ａ駅より学校から遠ざかるｆ駅が申請されている場合や、本来ｃ駅とすべき着駅としてｅ駅が申請されている場合には、アルバイトなどの便宜のためであると想像して申請を却下する。この場合、具体的には、情報端末５に描かれた一覧表の却下欄にチェックマークを入れると共に、該当欄に却下理由を特定するコードを記入する。

一般に、各学校では、全学生の個人情報を把握していると共に、個人情報の申請時に通学用の発駅を申請させるので、担当者は、上記のチェック作業を学生管理マスタＳＴＵの情報に基づいて画一的に行うことになる。なお、一見不審に思われるｆ駅やｅ駅の選択に正当理由がある場合もあるが、そのような場合には、本人が学校に出頭して事情を説明すれば足りるので、本システムでは、学生管理マスタＳＴＵの情報と整合しない申請は画一的に却下したので足りる。

このように、学校担当者によるチェック作業は、単純な照合作業で足りるので、好ましくは、コンピュータ処理によって照合処理を終えるべきである。そこで、本システムＳＹＳでは、コンピュータによる照合処理を可能にするべく、担当者の要求に基づいて、ＨＭＬファイルの一覧表に該当するデータをＣＳＶファイルとして送信するようにしている（アクションＡ７）。そのため、ＣＳＶファイルをダウンロードした学校担当者は、専用のアプリケーションプログラムを起動させて、申請データと学生管理マスタＳＴＵのデータとの一致判定をさせることができる。なお、ＣＳＶとはComma Separated Valuesの略であり、各データがカンマで区切られたものである。

何れにしても、学校担当者の介在する処理によって学生からの申請データの正当性がチェックされる。そして、チェック作業が終われば、承認／却下を特定したデータがＷＥＢサーバ９に送信される（アクションＡ８）。そこで、これを受けたＷＥＢサーバ９では、学割管理マスタＭＮＧのステータス欄を「申請中」から「承認」又は「却下」に変更すると共に、承認された申請データについて、学生を一意に特定する承認番号を付与して学割管理マスタＭＮＧのステータス欄に登録する。この承認番号は、申請データが承認された後、通学定期券が発行されるまで、申請者を特定する重要なデータであるので、他人から容易の類推されないよう１桁のチェックデジットを付加している。ここで、チェックデジットとは、承認番号の他の桁の数値から一意に算出される０〜９の範囲内の数値である。なお、この承認番号が付与されると、クエリー文字列（固有情報）は削除されて開放されるので、そのクエリー文字列の他人への利用が可能となる。

このようにして承認された学生申請データは、承認番号などの管理情報と共に、適宜なタイミングでホストコンピュータ１０の総合管理マスタＭＡＩＮに転記される。また、ＷＥＢサーバ９では、学校担当者から承認された申請データについて、その申請をした学生に対して、承認番号を電子メールで送信する（アクションＡ１０）。本実施例では、学生申請データが承認された事実は、学校を経由することなく、直接、学生本人に承認番号と共に通知されるので、学校の負担が軽減され、しかも、学生本人は迅速に承認番号を知ることができる。しかも、この承認番号は、電子メールで伝送されるので、情報端末４に記憶させることが可能となり、この意味でも便利である。

一方、学校担当者から却下された申請データについて、却下された事実を却下理由と共に電子メールで送信する（アクションＡ１０）。したがって、承認番号を受けた学生は、この番号に基づいて定期券の発行を受けることができ、一方、却下理由を知った学生は、再度、図２の手続きを経て承認番号の付与を求めることになる。なお、学割管理マスタＭＮＧのステータスが「却下」の場合には、個人情報の重複申請処理が許容されるのは最初に説明した通りである。

＜初回の通学定期券の発行（図４）＞
承認番号の付与を受けた学生が通学定期券の発行を受けるには、自動券売機８に対して、必要な情報を入力する。なお、必要な情報は、自動券売機との会話形式で入力できるようになっており、券売機の指示に基づいて、大学名、学籍番号、承認番号、氏名、性別、生年月日、通学乗車区間（発着駅）、使用開始日、及び使用月数を特定する。

入力された上記の情報は、社内ネットワーク３を通してホストコンピュータ１０に伝送され、総合管理マスタＭＡＩＮに登録されている学割管理用のデータ（学生が申請し学校が承認したデータ）と照合される。そして、大学名、学籍番号、承認番号、氏名、性別、生年月日、通学乗車区間（発着駅）の全てが一致する場合には、通学定期券の発行が許可され、自動券売機８では、使用開始日と使用月数を特定した通学定期券を発行する。また、この処理に合わせて、総合管理マスタＭＡＩＮには発行実績データが記憶され、その後の重複する期間における通学定期券の発行は禁止される。なお、定期券の発行は、自動券売機８を使用せず、駅の窓口で駅員を経由して行うこともできるが、その場合も、承認番号の提示が通学定期券の発行の前提条件となる。

先に説明したように、他人になりすました申請は、電子メールを利用した本人への通信連絡のために成功しない。また、仮に、他人の個人情報と自己の電子メールアドレスとを組み合わせても、学校担当者のチェックによって容易に露見する。更にまた、申請手続きを経ることなく、他人の名前で通学定期券を購入しようとしても（例えば、図７の「乙」が「甲」の名前で購入しようとしても）、承認番号を知らない他人「乙」の企ては成功しない。

また、本システムＳＹＳでは、携帯電話機ＭＢやパソコンＰＣｉに伝送された承認番号の提示をもって本人確認をしている。したがって、一々、駅の窓口において対面接触することなく、自動券売機によって迅速に定期券を取得することができる。しかも、初回の通学定期券の発行を受けた後は、通学区間の変更がない限り、所持している定期券を自動券売機８に投入するか、駅窓口に提示することによって、大学名、学籍番号、承認番号、氏名、性別、生年月日、通学乗車区間（発着駅）を特定することなく、新たな定期券を取得することができる。なお、古い定期券は鉄道事業者側に必ず回収されるので、その後、古い定期券が悪用されるおそれはない。

このように、本システムＳＹＳでは、事業者が発行した定期券を本人確認のための身分証明書として活用することにより、学生及び事業者の双方にとって合理的なシステムを構築している。すなわち、本人名義の定期券を所持しているということは、とりもなおさず本人であることの強力な確認となるので、煩雑な手続きを経ることなく直ちに定期券を発行することができる。

しかも、この定期券はほぼ毎日使用されるため、クレジットカードのように紛失の発見が遅れるようなことがなく、そのため紛失時には直ちに鉄道事業者に申告されると期待できるので、定期券の他人による悪用の可能性は低く、その意味でも極めて合理的な本人確認の手段となる。更にまた、クレジットカードは、それ自身に大きな金銭的価値があるので偽造されるおそれもあるが、通学定期券の場合には、それほどの金銭的価値はなく、しかも自動改札機で毎日チェックされるので偽造される可能性は極めて低い。
＜登録データの変更又は定期券紛失時の手続き（図２、図４、図５）＞
次に、図２及び図４に基づいて、学生の住所移転などにより登録データを変更したい場合、及び定期券を紛失した場合について説明する。登録データの変更時には、改めて、学生がＷＥＢサーバ９をアクセスしてデータ変更用の専用ページを要求する必要がある。また、定期券を紛失した場合にも、改めて、学生がＷＥＢサーバ９をアクセスして紛失申告用の専用ページを要求する。

そして、登録データの変更時には、年度始めと同様に申請データを記入して、年度始めの場合と同様の手順を経て、申請データをＷＥＢサーバ９に伝送する（図２のアクションＡ１〜Ａ３を参照）。この場合、ＷＥＢサーバ９が文法エラーを検出する点や、ＷＥＢサーバ９から申請データの確認画面が送信される点も、年度始めの場合の処理と同様である。一方、定期券を紛失した場合にも、その事情を説明する文章をＷＥＢサーバ９に送信する。

その後、確認メールが本人に伝送されると共に、学校担当者宛にも、登録データの変更や定期券紛失の手続きがされたことが通知される（図２のアクションＡ４〜Ａ６を参照）。そして、変更申請の内容や定期券紛失の事情を閲覧した学校担当者が、記載内容を承認すれば、ＷＥＢサーバ９では、学割管理マスタＭＮＧの内容を変更後のデータで更新すると共に、新たに付与した承認番号を学生宛に電子メールで送信する（図４のアクションＡ７〜Ａ１１を参照）。この場合、変更された学割管理マスタＭＮＧの内容や、新規の承認番号は、総合管理マスタＭＡＩＮにも登録されるので、学生は、新規の承認番号に基づいて券売機８から新たな通学定期券を取得することができる（図４のアクションＡ９参照）。

なお、上記した住所変更時の処理は、必ずしも、学生の情報端末４から行う必要はない。すなわち、図５に示すように、学生による変更申請などの手続きに先立って、通常は、学校に住所変更などの事実を届け出る必要があるので、その際に、住所変更の届けを受け付けた学校担当者がＷＥＢサーバ９をアクセスし、学校担当者の操作によって学割管理マスタＭＮＧの内容を更新しても良い（図５のアクションＡ３０〜Ａ３２）。なお、更新された内容が、総合管理マスタＭＡＩＮにも反映されるのは勿論であり（図５のアクションＡ３３）、学校担当者宛に新規の承認番号が伝送されるので（図５のアクションＡ３４）、学生は、新規の承認番号に基づいて券売機８から通学区間の異なる新たな通学定期券を取得することができる。

これらの点は、定期券紛失時についても同様であり、学生は、先ず定期券を紛失したことを学校に届け出て、学校担当者との対面説明によって紛失事実を説明するのが好ましい。この場合、説明内容の合理性が確認できた場合だけ、学校担当者の操作によって、紛失事実がＷＥＢサーバに伝送される。すると、適宜なタイミングで総合管理マスタＭＡＩＮに紛失事実が登録されると共に（図５のアクションＡ３３）、学校担当者宛に新規の承認番号が伝送されるので（図５のアクションＡ３４）、学生は、新規の承認番号に基づいて券売機８から期間の重複した別の通学定期券を取得することができる。なお、新規の承認番号が付与された段階で、その学生に対する古い承認番号は効力を失うので、紛失した定期券を所持する者が、これを券売機に投入しても新規の定期券を取得することはできない。

ところで、本システムで発行する通学定期券は、磁気データを記憶した磁気カードであるのが簡易的であるが、ＩＣカードを採用しても良い。この場合には、センサの上に単に載置するだけで改札口を通過できるよう定期券を構成できるだけでなく、学生証と一体化した定期券であって、使用実績を蓄積できるだけでなく、自動券売機８において有効期間に関するデータを書き加えるだけで、同じ媒体を用いて新規の定期券の役目をさせることができる。

また、上記した通学定期券の発行システムＳＹＳでは、券売機８に承認番号を入力して通学定期券の発行を受けていたが、承認番号の入力に変えて、学生証を券売機８に投入して通学定期券の発行を求めるようにしても良い。この場合には、学生証は、例えば磁気カードやＩＣカードなどで構成されたＩＤカード（個人カード）であり、このＩＤカードには学校から付与された認証コード（個人コード）が内部的に記憶されている。そして、認証コードは、学生を一意に特定するユニークなコードであり、通学定期券の発行時に正当権利者であることがホストコンピュータ１０で確認できなければならない。

そのため、この場合には、例えば学校からランダムに付与された認証コードが、総合管理マスタＭＡＩＮ（学割管理マスタＭＮＧが転記されたもの）に記憶されている。そして、発券機８は、受付けた認証コードに基づいて総合管理マスタＭＡＩＮを検索し、そこに記憶された予約情報に基づいて通学定期券を発行することになる。ここで、学生証に記憶されている認証コードは、学籍番号などのように学割管理マスタＭＮＧに記憶済みの学生固有のデータと、学校固有の暗号化キーとの演算によって生成されたものが好適である。このような認証コードであれば、学校毎の暗号キーと暗号化アルゴリズムを把握すれば、各学生の認証コードをホストコンピュータ側で自動的に生成することができ、全学生の認証コードを学校から伝送してもらう煩雑さが解消される。

なお、学生を特定する認証コードが、学割管理マスタＭＮＧに記憶済みの学生固有のデータと、学校固有の暗号化キーとに基づいて一意に生成されるものであれば、そのような認証コードは、必ずしも総合管理マスタＭＡＩＮに記憶しておく必要はない。すなわち、発券機８が学生証から認証コードを読み取った後、発券機８か又はホストコンピュータ１０が、復号アルゴリズムと各学校固有の復号化キーとによって学籍番号などの学生固有のデータに復号化すれば、発券を求めている学生を直ちに特定することが可能となる。また、この認証コード（個人コード）は、確実に本人であることを確認できるものであれば、鉄道会社など便益提供者側から付与された個人カードに非明示的に記憶されたものであっても良い。

更にまた、本システムにおいて、学生の通学定期券の購入状態を一定期間集計して、学校担当者に電子メールで送信するようにしても良い。例えば、高校などでは、自転車通学やオートバイ通学の有無を管理しているので、自転車通学の学生が通学定期券を購入している事態を発見することもできる。かかる異常事態は、実際にはあり得ないが、通学定期券の購入状態が学校に連絡されていることを学内で告知するだけで、通学定期券の販売などの違法行為を未然に防止できる。

以上、本発明の一実施例を詳細に説明したが、具体的な記載内容は特に本発明を限定する趣旨ではなく適宜に変更可能である。例えば、以下のような変更例が考えられる。なお、以下の説明において、＜中央管理装置＞は、電子証明および証票発行の予約を管理するコンピュータ装置を意味する。＜第１情報端末＞は、インターネットと接続されるパソコン又は携帯電話機を意味する。＜第２情報端末＞は、中央管理装置と通信回線（専用回線やＬＡＮまたはインターネット）で接続される認証用入力端末を意味する。＜発行端末＞は、中央管理装置と通信回線（専用回線やＬＡＮまたはインターネット）で接続した証票発行端末、又は販売管理端末あるいはサービス提供のためのフロント端末を意味する。
（Ａ）本発明を流通業に適用した場合：
本発明を流通業に適用した場合には、＜便益提供者＞は、百貨店など小売店となる。また、＜便益希望者＞は、百貨店での割引購入などの優待資格を与えられる団体所属の個人となり、＜認証者＞は、所属員への優待販売の契約を百貨店と結んだ団体となる。そして、処理概要は以下の通りである。
（１）便益希望者は、便益提供者に対し、予め第１情報端末を使って便益提供者の中央管理装置に必要な個人情報と団体（認証者）の所属員としてのＩＤ（社員番号など）、及び任意のパスワードを登録する。このとき希望する商品を予約申し込むこともできる。（２）便益提供者の中央管理装置は、登録内容が正しいかどうか、認証者にメールまたは第２情報端末への表示をもって証明を依頼する。（３）認証者は、所属員として正しい登録内容であることを第２情報端末への入力操作によって証明する。（４）便益提供者は、承認番号を便益希望者に対して、認証者が予め所属員として便益提供者に与えた所属員メールアドレス宛に送信する。（５）便益希望者は、承認番号と必要に応じてパスワードを使って、便益提供者の店内に設置された発行端末に入力して割引券を受け取る。（６）または直接レジ端末で承認番号とパスワードを入力することで割引を受ける。

この構成によれば、便益提供者は中央管理装置に記録された利用データにより、割引券の発行枚数（割引の回数）を管理（制限）するとともに、商品開発、販売予測による仕入れ計画、販売促進といったマーケティングに活用できる。
（Ｂ）本発明を飲食業に適用した場合：
本発明を飲食業に適用した場合には、＜便益提供者＞は、飲食店である。また、＜便益希望者＞は、割引などの優待資格を与えられる団体所属の個人であり、＜認証者＞は、所属員への優待割引の契約を飲食店と結んだ団体である。この場合の処理概要は以下の通りである。
（１）便益希望者は、便益提供者に対し、予め第1情報端末を使って便益希望者の中央管理装置に必要な個人情報と団体（認証者）の所属員としてのＩＤ（社員番号など）、及び任意のパスワードを登録する。このとき、希望する日時、人数、テーブル、メニューを予約申し込むこともできる。（２）便益提供者は、登録内容が正しいかどうか、認証者にメールまたは第２情報端末への表示をもって証明を依頼する。（３）認証者は、所属員として正しい登録内容であることを第２情報端末への入力操作によって証明する。（４）便益提供者は、承認番号を便益希望者に対して、認証者が予め所属員として便益希望者に与えた所属員メールアドレスに送信する。（５）便益希望者は、承認番号と必要に応じてパスワードを使って、便益提供者の店内に設置された発行端末に入力して割引券を受け取る。（６）または直接レジ端末で承認番号とパスワードを入力することで割引を受ける。

この構成によれば、便益提供者は、中央管理装置に記録された飲食履歴のデータにより、割引券の発行枚数（割引の回数）を管理（制限）するとともに、メニュー開発、食材の仕入れ計画、販売促進といったマーケティングに活用できる。
（Ｃ）本発明を旅行業に適用した場合：
本発明を旅行業に適用した場合には、＜便益提供者＞は、旅行会社または旅行代理店である。また、＜便益希望者＞は、旅行商品の割引購入などの優待資格を与えられる団体所属の個人、或いは、出張手配から精算までの業務に関して契約を結んだ企業や団体に所属する個人である。＜認証者＞は、所属員への優待販売の契約を便益提供者と結んだ団体、或いは出張手配から精算までの業務に関して契約を結んだ企業や団体である。この場合の処理概要は以下の通りである。
（１）便益希望者は、便益提供者に対し予め第１情報端末を使って便益提供者の中央管理装置に必要な個人情報と団体（認証者）の所属員としてのＩＤ（社員番号など）、及び任意のパスワードを登録する。このとき希望する旅行商品などを予約申し込むこともできる。（２）便益提供者は登録内容が正しいかどうか、認証者にメールまたは第２情報端末への表示をもって証明を依頼する。（３）認証者は、所属員として正しい登録内容であることを第２情報端末への入力操作によって証明する。（４）便益提供者は、承認番号を便益希望者に対して、認証者が予め所属員として便益希望者に与えた所属員メールアドレスに送信する。（５）便益希望者は、承認番号と必要に応じてパスワードを使って、便益提供者の店内に設置された発行端末に入力して割引券（出張事務の契約を結んでいる場合は、出張手配クーポン）を受け取る。（６）または、直接便益提供者の旅行クーポン発行端末で、承認番号とパスワードを入力することで、予約した旅行クーポンを受け取る。便益提供者と便益希望者が出張事務に関する契約を結んでいる場合は事後精算による旅行手配を受ける。

この構成によれば、便益提供者は中央管理装置に記録された利用データにより、割引券の発行枚数（または割引や旅行手配の回数）を管理（制限）するとともに、出張手配の場合は事後精算として便益希望者への請求を行うことができる。
（Ｄ）本発明をホテル、旅館業に適用した場合：
本発明をホテル、旅館業に適用した場合には、＜便益提供者＞は、ホテル、旅館である。また、＜便益希望者＞は、宿泊料金の割引などの優待資格を与えられる団体所属の個人、又は保養所としての契約を結んだ企業や団体に所属する個人である。＜認証者＞は、所属員への優待の契約を便益提供者と結んだ団体、又は保養所としての契約を結んだ企業や団体である。この場合の処理概要は以下の通りである。
（１）便益希望者は、便益提供者に対し予め第1情報端末を使って便益提供者の中央管理装置に必要な個人情報と団体（認証者）の所属員としてのＩＤ（社員番号など）、及び任意のパスワードを登録する。このとき希望する部屋を予約申し込むこともできる。（２）便益提供者は、登録内容が正しいかどうか、認証者にメールまたは第２情報端末への表示をもって証明を依頼する。（３）認証者は、所属員として正しい登録内容であることを第２情報端末への入力操作によって証明する。（４）便益提供者は、承認番号を便益希望者に対して、認証者が予め所属員として便益希望者に与えた所属員メールアドレスに送信する。（５）便益希望者は、承認番号と必要に応じてパスワードを使って、便益提供者の宿泊施設内に設置された発行端末に入力して割引券（保養所利用券）を受け取る。（６）または直接、便益提供者のフロントの宿泊管理端末で、承認番号とパスワードを入力することで、割引料金が適用される。

この構成によれば、便益提供者は中央管理装置に記録された利用データにより、割引券（保養所利用券）の発行枚数（または利用人数や部屋数）を管理（制限）するとともに、保養所扱いによる事後精算行う場合は便益希望者への請求を行うことができる。
（Ｅ）本発明を鑑賞チケット販売に適用した場合：
本発明を演劇、映画、音楽コンサート、美術展などの鑑賞チケット販売に適用した場合には、＜便益提供者＞は、チケット販売会社となる。また＜便益希望者＞は、鑑賞券の割引購入などの優待資格を与えられる団体所属の個人であり、＜認証者＞は、所属員への優待販売の契約を便益提供者と結んだ団体である。この場合の処理概要は以下の通りである。
（１）便益希望者は、便益提供者に対し予め第１情報端末を使って便益提供者の中央管理装置に必要な個人情報と団体（認証者）の所属員としてのＩＤ（社員番号など）、及び任意のパスワードを登録する。このとき、希望する鑑賞券を予約申し込むこともできる。（２）便益提供者は、登録内容が正しいかどうか、認証者にメールまたは第２情報端末への表示をもって証明を依頼する。（３）認証者は、所属員として正しい登録内容であることを第２情報端末への入力操作によって証明する。（４）便益提供者は、承認番号を便益希望者に対して、認証者が予め所属員として便益希望者に与えた所属員メールアドレスに送信する。（５）便益希望者は、承認番号と必要に応じてパスワードを使って、便益提供者の発券カウンターに設置された発行端末に入力して鑑賞券あるいは割引券を受け取る。（６）または劇場や映画館、コンサートホール、美術館に設置した便益提供者の発券端末で、承認番号とパスワードを入力することで、予約した鑑賞券を受け取る。

この構成によれば、便益提供者は中央管理装置に発券履歴を記録することにより、鑑賞券の二重発券を防止し、あるいは割引券の発行枚数を管理（制限）することができる。
（Ｆ）本発明を医療、介護ビジネスに適用した場合：
本発明を医療、介護ビジネスに適用した場合には、＜便益提供者＞は、医療機関、介護サービス業者である。また、＜便益希望者＞は、定期健康診断、人間ドックなどの受診資格や、介護サービスの受ける資格を与えられる団体（企業や健保組合）所属の個人であり、＜認証者＞は、所属員への医療・介護サービス提供の契約を便益提供者と結んだ団体である。この場合の処理概要は以下の通りである。
（１）便益希望者は、便益提供者に対し予め第１情報端末を使って便益提供者の中央管理装置に必要な個人情報と団体（認証者）の所属員としてのＩＤ（社員番号など）、及び任意のパスワードを登録する。このとき、希望する医療・介護サービスを予約申し込むこともできる。（２）便益提供者は、登録内容が正しいかどうか、認証者にメールまたは第２情報端末への表示をもって証明を依頼する。（３）認証者は、所属員として正しい登録内容であることを第２情報端末への入力操作によって証明する。（４）便益提供者は、承認番号を便益希望者に対して、認証者が予め所属員として便益希望者に与えた所属員メールアドレスに送信する。（５）便益希望者は、承認番号と必要に応じてパスワードを使って、便益提供者の発券カウンターに設置された発行端末に入力して受診券や利用券あるいは割引券を受け取る。（６）または便益提供者の予約確認端末で、承認番号とパスワードを入力することで、対象者（申込者）であることを確認されサービスを受ける。

この構成によれば、便益提供者は、中央管理装置に利用履歴を記録することにより、二重の利用を防止するとともに、利用状況を把握することができる。
（Ｇ）本発明を金融業に適用した場合：
本発明を金融業に適用した場合には、＜便益提供者＞は、銀行、証券会社、保険会社である。また、＜便益希望者＞は、社員預金扱い、ローン金利優遇、投資信託や株式の売買手数料優遇、年金・保険商品の団体割引を受ける資格を与えられる団体（企業や健保組合）所属の個人であり、＜認証者＞は、所属員への社員預金扱い、ローン金利優遇、投資信託・株式の売買手数料優遇、年金・保険商品の団体割引などに関する契約を便益提供者と結んだ団体である。この場合の処理概要は以下の通りである。
（１）便益希望者は、中央管理装置に対し予め第１情報端末を使って便益提供者の中央管理装置に必要な個人情報と団体（認証者）の所属員としてのＩＤ（社員番号など）、及び任意のパスワードを登録する。このとき、希望する金融商品・サービスを予約申し込むこともできる。（２）公益提供者は、登録内容が正しいかどうか、認証者にメールまたは第２情報端末への表示をもって証明を依頼する。（３）認証者は、所属員として正しい登録内容であることを第２情報端末への入力操作によって証明する。（４）便益提供者は、承認番号を便益希望者に対して、認証者が予め所属員として便益希望者に与えた所属員メールアドレスに送信する。（５）便益希望者は、承認番号と必要に応じてパスワードを使って、便益提供者の店舗窓口に設置された発行端末に入力して資格者証明書や利用券あるいは割引券を受け取る。（６）または便益提供者の確認端末で、承認番号とパスワードを入力することで、対象者（申込者）であることを確認され、社員預金扱い、ローン金利優遇、投資信託・株式の売買手数料優遇、年金・保険商品の団体割引などのサービスを受ける。

この構成によれば、便益提供者は、中央管理装置に利用履歴を記録することにより、利用状況を把握するとともに、予め認証者との間で定めた条件による管理を行うことができる。

実施例に係る通学定期券の発行システムを示す構成図である。 図１のシステムにおいて、学生からの申請事実が、本人と学校に通知されるまでを説明する図面である。 図１のシステムにおいて、学生が、申請済みのデータを閲覧又は削除する方法を説明する図面である。 図１のシステムにおいて、申請事実を学校が承認し、その結果が本人に通知されるまでを説明する図面である。 図１のシステムにおいて、登録内容を変更する場合、又は、定期券を紛失した場合の手続きを説明する図面である。 学割管理マスタの記憶内容を例示したものである。 通学定期の申請内容を説明する図面である。

符号の説明

７ 中央管理装置
２ 汎用通信回線（インターネット）
４ 第１情報端末
５ 第２情報端末
８ 発行端末（自動券売機）
ＳＹＳ 便益提供システム（学割定期発行システム）

Claims (10)

1. 証票の発行又は役務の提供を希望する便益希望者から、予約情報を受付けて記憶及び管理する中央管理装置（７）と、
   汎用通信回線（２）を介して前記中央管理装置に接続され、前記予約情報を前記中央管理装置に申請する第１情報端末（４）と、
   汎用通信回線（２）を介して前記中央管理装置（７）に接続され、個人情報を含む前記予約情報の正当性を判定して、その判定結果を前記中央管理装置に通知する認証者の第２情報端末（５）と、
   前記予約情報が正当である旨の通知が確認された後、前記中央管理装置（７）によって明示的に付与された承認コードか、或いは、前記認証者又は便益提供者から非明示的に予め付与されている個人コードを便益希望者が提示することを条件に、前記中央管理装置（７）に管理されている予約情報に基づいた証票の発行又は役務の提供により便益を実現する発行端末（８）と、を備えることを特徴とする便益提供システム。
2. 前記個人情報には、便益希望者の電子メールアドレスが含まれており、前記中央管理装置に予約情報が受付けられると、受付けられたことを示す確認情報が前記電子メールアドレスに向けて発信されるよう構成された請求項１に記載の便益提供システム。
3. 前記個人情報には、便益希望者の電子メールアドレスが含まれており、前記中央管理装置は、予約情報の正当性を確認する判定結果を前記第２情報端末から受けたことを条件に承認コードを生成して、これを前記電子メールアドレスに向けて発信するよう構成された請求項１又は２に記載の便益提供システム。
4. 前記中央管理装置に受付けられた予約情報は、一定期間内の受付け総件数として前記第２情報端末に伝送されるよう構成された請求項１〜３の何れかに記載の便益提供システム。
5. 前記中央管理装置には、申請された予約情報の登録欄と、予約情報の認証状態を示すステータス欄と、中央管理装置から付与される承認コードの登録欄とを有する記憶部が設けられ、前記予約情報には、便益希望者が在籍する所属団体と、便益希望者の電子メールアドレスとが含まれており、
   前記第１情報端末から申請された形式ミスのない予約情報のみを前記登録欄に記憶すると共に、前記ステータス欄に申請中フラグを記憶する第１手段と、
   前記第１手段によって前記登録欄に予約情報が記憶されると、その予約情報に含まれる電子メールアドレス宛に申請確認メールを発信する第２手段と、
   申請中フラグを有する予約情報を一定時間毎に抽出すると共に、これを予約情報に含まれる所属団体毎に集計して、集計された予約情報の総件数を各所属団体宛に発信する第３手段と、
   第３手段による通知を受けた後、前記第２情報端末を前記中央管理装置に接続し、正当権利者の認証を受けた後、前記総数分の予約情報の閲覧を可能にする第４手段と、
   予約情報の閲覧の後、予約情報の全部又は一部であって受益希望者の属する団体が認証すべき事項を判定して、この判定結果を前記中央管理装置に通知する第５手段と、
   通知された判定結果に基づき、前記ステータス欄の申請中フラグを承認フラグ又は却下フラグに変更すると共に、承認フラグに変更した場合には当該予約情報の正当性を一意に特定する承認コードを生成して前記記憶部の該当欄に記憶する第６手段と、
   前記承認コードが提示された場合には、提示された承認コードと予約情報とが正当に対応することを前記記憶部の記憶内容に基づいて確認した後、予約情報に対応する証票を発行する第７手段とを備えることを特徴とする請求項１〜４何れかに記載の便益提供システム。
6. 前記中央管理装置には、申請された予約情報の登録欄と、予約情報の認証状態を示すステータス欄とを有する記憶部が設けられ、前記予約情報には、便益希望者が在籍する所属団体と、便益希望者の電子メールアドレスと、便益希望者の個人情報とが含まれており、
   前記第１情報端末から申請された形式ミスのない予約情報のみを前記登録欄に記憶すると共に、前記ステータス欄に申請中フラグを記憶する第１手段と、
   前記第１手段によって前記登録欄に予約情報が記憶されると、その予約情報に含まれる電子メールアドレス宛に申請確認メールを発信する第２手段と、
   申請中フラグを有する予約情報を一定時間毎に抽出すると共に、これを予約情報に含まれる所属団体毎に集計して、集計された予約情報の総件数を各所属団体宛に発信する第３手段と、
   第３手段による通知を受けた後、前記第２情報端末を前記中央管理装置に接続し、正当権利者の認証を受けた後、前記総数分の予約情報の閲覧を可能にする第４手段と、
   予約情報の閲覧の後、予約情報の全部又は一部であって受益希望者の属する団体が認証すべき事項を判定して、この判定結果を前記中央管理装置に通知する第５手段と、
   通知された判定結果に基づき、前記ステータス欄の申請中フラグを承認フラグ又は却下フラグに変更する第８手段と、
   前記個人情報と一対一に対応し、非明示的に記録されている個人コードを、便益希望者の個人カードから読み取り、読み取った個人コードと予約情報とが正当に対応することを前記記憶部の記憶内容に基づいて確認した後、予約情報に対応する証票を発行する第９手段とを備えることを特徴とする請求項１〜４何れかに記載の便益提供システム。
7. 前記予約情報には、便益希望者が申請したパスワードが含まれており、前記発行端末には、少なくともパスワードが提示されることを条件に予約した便益が提供される請求項１〜６の何れかに記載の便益提供システム。
8. 前記証票は通学定期券である請求項１〜７の何れかに記載の便益提供システム。
9. 請求項１〜８の何れかの中央管理装置で使用されるプログラム。
10. 証票の発行又は役務の提供を希望する便益希望者から、予約情報を受付けて記憶及び管理する中央管理装置（７）と、
    汎用通信回線（２）を介して前記中央管理装置に接続され、前記予約情報を前記中央管理装置に申請する第１情報端末（４）と、
    汎用通信回線（２）を介して前記中央管理装置（７）に接続され、個人情報を含む前記予約情報の正当性を判定して、その判定結果を前記中央管理装置に通知する認証者の第２情報端末（５）と、
    前記予約情報が正当である旨の通知が確認された後、前記中央管理装置（７）によって付与された承認コードか、或いは、前記認証者又は便益提供者から非明示的に予め付与されている個人コードを便益希望者が提示することを条件に、前記中央管理装置（７）に管理されている予約情報に基づいた証票の発行又は役務の提供により便益を実現する発行端末（８）と、を備えて、
    便益希望者による予約情報の申請手続きと、便益希望者の在籍団体である認証者の予約情報の認証手続きと、便益提供者による便益希望者及びその在籍団体に対する電子的な連絡手続きを含んだ管理手続きとの協働によって円滑に便益を提供するコンピュータを用いた便益提供方法。

Images