カード使用通知システム
【課題】クレジットカードの契約者に対し、カードに化体した信用が他人に悪用された事実の早期発見に資する仕組みを提供する。
【解決手段】ユーザが商品またはサービスの購入にクレジットカードを利用する（１）場合、カードの提示を受けた加盟店は、カード会社に対し該カードの利用の可否（カードの有効性・利用可能額）を照会する（２）。この照会を受けたカード会社は、信用承認に関する処理を行ない（３）、該カードの利用を承認する場合はその旨を加盟店に対して返答する（４）とともに、利用額の確保処理を行なう。カードの利用が承認されると、加盟店は、所定のカード処理（例えば、本人確認，署名の照合等）を行ない（５）、ユーザにカード利用書を発行する（６）。以上の処理の完了後、カード会社は、承認情報をデータベースに登録し、この情報から生成した「利用確認メール」をユーザに対して送信する（７）。
【解決手段】ユーザが商品またはサービスの購入にクレジットカードを利用する（１）場合、カードの提示を受けた加盟店は、カード会社に対し該カードの利用の可否（カードの有効性・利用可能額）を照会する（２）。この照会を受けたカード会社は、信用承認に関する処理を行ない（３）、該カードの利用を承認する場合はその旨を加盟店に対して返答する（４）とともに、利用額の確保処理を行なう。カードの利用が承認されると、加盟店は、所定のカード処理（例えば、本人確認，署名の照合等）を行ない（５）、ユーザにカード利用書を発行する（６）。以上の処理の完了後、カード会社は、承認情報をデータベースに登録し、この情報から生成した「利用確認メール」をユーザに対して送信する（７）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クレジットカード等の契約者に対し、カードが使用されたこと等を迅速に通知するシステムに関するものである。
【背景技術】
【０００２】
最近、個人情報の流出やクレジットカードの不正利用等に関し、カード利用者の関心や不安感が高まっている。特に、カード番号の流出やスキミング等の実害として、契約者本人がカードを所持していながら、該カードに化体した信用が他人に悪用されてしまうという事態が問題となっている。
こうした悪用があった場合でも、契約者は通常、カード会社から送られてくる請求書を見るまで、その事実を把握することができない。しかも、請求書が契約者の手元に届くのは、通常、その悪用の事実があった日が含まれる月の翌月のことである。これは、カード会社による売上データの処理が、月単位で行なわれるからである。例えば、当月中に加盟店から送られてきた売上データは、翌月の定日（例えば、毎月１０日など）に契約者に対する請求データとして確定する。
このように、自己の信用が他人に悪用された事実を契約者本人が早期に把握するのは困難な状況にある。その結果、万一悪用があった場合でも、その事実の発見および対処（店舗等への確認，カードの利用停止等）が遅れ、被害の拡大につながるおそれがある。
【０００３】
こうした問題への対応として、カード会社が提供する会員専用のＷＥＢサイト上でカードの利用状況を確認することができるサービスが知られている。このサービスを利用すれば、契約者はいつでもカードの利用状況を確認することができる。
しかしながら、こうしたサービスは、契約者の自発的なアクセスを前提とするものである。さらには、提供される情報の性質上、確認の都度専用ページへのログインが必要になる。そのため、他人による悪用行為を日常的に監視するのは困難である。
【０００４】
また、カードの利用後、売上データがカード会社のデータベースに登録された時点で、契約者が指定したメールアドレス宛の電子メールでカードの利用内容を通知するサービスがある（本出願人による特願２００６−０３５２１１参照）。このサービスを利用すれば、契約者は、いち早く自身のカードの利用内容を確認することができる。
【０００５】
ここで、売上データがカード会社のデータベースに登録された時点で利用確認メールを送信する場合を説明する。
図１は、ユーザ，加盟店，カード会社および決済代行会社との間での売上情報に係る利用確認メールの送信を説明する図である。
クレジットカードの利用があった場合、加盟店は、売上請求に関する処理を行ない（１）、カード会社に対し利用額の支払いを請求する（２）。この請求処理は、信用承認のための照会処理と同時に行なう場合や、カードの利用から一定期間の経過後に、一定期間内の売上額を一括して行なう場合がある。インターネットショッピングの場合は商品の発送後に行なうことが多い。
この請求を受けたカード会社は、売上請求に関する処理を行ない（３）、各ユーザに対する売上請求額を確定させる。ユーザに対して「利用確認メール」を送信する（４）のはこの時点となる。
その後又は同時に、ユーザに対し利用額を請求（請求書を郵送）する（５）。この請求を受けたユーザは、カード会社に対し利用額を支払う（６または７）。カード会社も、加盟店に対し、自動引落等により利用額を支払う（６または７）。なお、（６）と（７）の先後は、場合により異なる。
なお、インターネットショッピングの場合は、上記の処理の一部は決済代行会社のシステムを通じて間接的に行なわれる（２）’。
【０００６】
このように、カード会社側のユーザに対する売上請求に関する処理は、各加盟店ごとに行なわれるカード会社に対する売上請求に関する処理が完了した後に行っている。そのため、確認メールの送信時を「売上データがカード会社のデータベースに登録された時点」とすると、ユーザに対する通知が遅れてしまう。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、クレジットカードの契約者に対し、カードに化体した信用が他人に悪用された事実の早期発見に資する仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明は、クレジットカードの使用があったことを、ユーザの端末に電子メールで通知するカード使用通知システムであって、クレジットカードの承認情報から生成した、前記ユーザのカード番号に対する利用承認情報を記憶する利用承認情報記憶手段と、前記ユーザのＩＤと、メールアドレスと、前記カード番号と、使用通知サービスの申請情報とを記憶しているユーザ情報記憶手段と、前記使用通知サービスを申請している前記ユーザの利用承認情報を、前記カード番号で前記利用承認情報記憶手段から読み出して使用確認メールを生成し、前記ユーザの前記メールアドレス宛に送信する使用確認メール生成・送信手段とを備えていることを特徴とする。
前記カード使用通知システムにおいて、さらに、クレジットカードの売上情報から生成した、前記ユーザのカード番号に対する利用明細情報を記憶する利用明細情報記憶手段を備え、前記使用確認メール生成・送信手段は、前記カード番号に対する利用明細情報を該利用明細情報記憶手段から読み出して、前記利用承認情報と前記利用明細情報とを区別して、使用確認メールを生成することを特徴としてもよい。
前記カード使用通知システムにおいて、前記利用承認情報は、さらに、クレジットカードの利用否認情報を含むことを特徴としてもよい。
【０００９】
前記カード使用通知システムにおいて、前記ユーザ情報記憶手段には、前記ユーザごとに複数のメールアドレスを記憶でき、前記ユーザ情報記憶手段に記憶している前記使用通知サービスの申請情報には、さらに、前記使用確認メールを送るべき送信先区分情報を含み、前記使用確認メール生成・送信手段は、前記メール送信先区分情報により前記送信するメールアドレスを決定することを特徴としてもよい。
前記カード使用通知システムにおいて、さらに、前記ユーザを、登録するときはカード番号で、更新するときは前記ＩＤで認証するログイン手段と、前記ユーザが、カード番号でログイン後、前記端末から前記使用通知サービスの申請情報を登録するための使用通知サービス申請情報登録手段と、前記使用通知サービス申請情報登録手段で登録後、前記ＩＤを付与するＩＤ付与手段と、前記ＩＤでログイン後、前記使用通知サービス申請情報を更新する更新手段とを備えることを特徴としてもよい。
【００１０】
また、本発明は、クレジットカードの使用があったことを、ユーザの端末に電子メールで通知するカード使用通知方法であって、クレジットカードの承認情報から生成した、前記ユーザのカード番号に対する利用承認情報を記憶する利用承認情報記憶手段と、前記ユーザのＩＤと、メールアドレスと、前記カード番号と、使用通知サービスの申請情報とを記憶しているユーザ情報記憶手段とを有し、前記使用通知サービスを申請している前記ユーザの利用承認情報を、前記カード番号で前記利用承認情報記憶手段から読み出して使用確認メールを生成し、前記ユーザの前記メールアドレス宛に送信することを特徴とする。
前記カード使用通知システムの各手段をコンピュータに機能として実現させるためのプログラムも本発明である。
【発明の効果】
【００１１】
本発明のカード使用通知システムによれば、クレジットカード契約者に対し、カードの使用があった事実を電子メールで迅速に通知することができる。その結果、万一カードが他人に悪用された場合であっても、契約者はその事実を早期に発見し適切に対処することで、被害を最小限に抑えることができる。しかも、契約者は、店舗側の信用承認処理タイミングと売上請求処理タイミングの間でカードが悪用された事実を発見できるので、売上請求処理の実行に対して適切に対処することができ、本システムは契約者の被害極小化に資することができる。
また、電子メールは保管や閲覧が容易である。そのため、本発明のカード使用通知システムにより通知された電子メールは、例えば、後に郵送された利用明細と照合して利用内容を再確認する等、カード利用の覚書としても有用である。
【発明を実施するための最良の形態】
【００１２】
以降、本発明のカード使用通知システムの実施形態の一例を、図面を参照して詳細に説明する。
なお、本実施形態において、「信用承認に関する処理」とは、クレジットカードの利用の可否（有効性，利用可能額等）に関する加盟店（店舗）からの照会に対して、該カードの利用の可否を該加盟店に返答する処理のことである。クレジットカードの利用を承認する場合、カード会社側のシステムでは売上の予約の処理（利用額の確保処理）を行ない、その利用承認に関するデータ（承認情報）をデータベースに登録する。
【００１３】
＜本実施形態の説明＞
（１．本実施形態の概略）
本実施形態の概略を、図面を参照して説明する。
図２は、ユーザ，加盟店，カード会社および決済代行会社との間での利用確認メールの送信を説明する図である。この図で、利用確認メールの送信の概略を説明する。
ユーザが商品またはサービスの購入にクレジットカードを利用する（１）場合、カードの提示を受けた加盟店は、カード会社に対し該カードの利用の可否（カードの有効性・利用可能額）を照会する（２）。
この照会を受けたカード会社は、信用承認に関する処理を行ない（３）、該カードの利用を承認する場合はその旨を加盟店に対して返答する（４）とともに、利用額の確保処理を行なう。
カードの利用が承認されると、加盟店は、所定のカード処理（例えば、本人確認，署名の照合等）を行ない（５）、ユーザにカード利用書を発行する（６）。
以上の処理の完了後、カード会社は、承認情報をデータベースに登録し、この情報から生成した「利用確認メール」をユーザに対して送信する（７）。ここで、カードの利用を承認しなかった（否認した）場合にも、「否認」したという承認情報をデータベースに登録し、確認メールを送信することとしてもよい。
なお、加盟店と契約をする機能（アクワイヤラー）とカードを発行する機能（イッシュアラー）とが分業化されている場合は、上記の処理の一部はアクワイヤラー（以下、「決済代行会社」という。）のシステムを通じて間接的に行なわれる（２）’，（４）’。
【００１４】
このように、信用承認に関する処理は、売上請求処理に先立って、クレジットカードの利用時にその都度行なわれるものである。したがって、利用確認メールの送信時を「承認データがカード会社のデータベースに登録された時点」とすることにより、カード利用後の早い時期にユーザに対して通知することが可能になる。
【００１５】
（２．本実施形態のシステム構成）
本実施形態のシステム構成を、図面を参照して説明する。
図３は、本実施形態のシステム構成の一例を示す図である。
前提として、パソコンや携帯電話等の端末を用いてＷＥＢ上でのサービスを利用しているＷＥＢ会員（ユーザ）が、本実施形態のシステムによるカード利用通知サービス（以下、「本サービス」という。）を申し込み、申し込みのあったカードに対して本サービスを提供するものとする。
なお、これは運用の一例であり、他の方法で本サービスの適用対象を決めてもよい。
【００１６】
顧客端末１０は、ＷＥＢ会員が用いる端末である。本実施形態では、例えばパソコンや携帯電話等の端末とする。
顧客端末１０は、インターネット等のネットワーク２０を介して、アプリケーション・サーバ３０から本サービスを受けることができる。ここでは、ＷＥＢ会員として入会する際にユニークなＩＤである「ＷＥＢ会員番号」と「パスワード」が与えられており、ＷＥＢ上でのサービスを受けるための認証はＷＥＢ会員番号（ＩＤ）とパスワードにより行なうものとする。
【００１７】
アプリケーション・サーバ３０は、顧客端末１０を通じてＷＥＢ会員に対してＷＥＢ上でサービスを提供するためのシステム等を格納しているサーバである。ここでは、本実施形態のシステムに関して必要な部分のみ説明する。
【００１８】
サービス利用登録・更新処理３２は、ＷＥＢ会員が顧客端末１０からカードごとに本サービスへの登録（新規または更新）を行なうと、その内容をデータベースに登録（更新）するプログラムである。
利用確認メール生成・送信処理３４は、本サービスが申し込まれているカードについて、カードの利用があったことを知らせるメール（利用確認メール）を生成し、該カードの契約者であるＷＥＢ会員の顧客端末１０宛に送信するプログラムである。
【００１９】
データベース・サーバ４０は、ＷＥＢ上でのサービスの提供等に必要なデータベースを格納しているサーバである。ここでは、本実施形態のシステムに関して必要な部分のみ説明する。
【００２０】
ＷＥＢ会員情報データベース４２は、ＷＥＢ会員の情報を格納しているデータベースである。ＷＥＢ会員情報データベース４２の主要な項目を図４（ａ）に示す。
図４（ａ）において、「ＷＥＢ会員番号」は、上述のＷＥＢ会員番号である。「パスワード」は、上述のように、ＷＥＢ会員の認証に用いるパスワードである。「パソコンメールアドレス」および「携帯メールアドレス」は、それぞれ、該ＷＥＢ会員のパソコンおよび携帯電話のメールアドレスであり、本実施形態の利用確認メールの送信先となる。これらのＷＥＢ会員情報データベース４２の各項目の内容は、例えばＷＥＢ会員として入会する際に登録され、必要に応じて更新される。
【００２１】
図３に戻り、契約情報データベース４４は、ＷＥＢ会員のカードの契約情報を格納しているデータベースである。契約情報データベース４４の主要な項目を図４（ｂ）に示す。
図４（ｂ）において、「契約番号」は、クレジットカード等のカードの契約番号（カード番号）であり、カードに一意の番号である。「ＷＥＢ会員番号」は、上述のＷＥＢ会員番号である。その他、カードの契約内容（例えば、カードの有効期限・契約者の生年月日・住所・電話番号・ＣＣＶ２等）を格納している。本実施形態では、カードの契約番号をＷＥＢ会員に紐付けるデータベースとして用いている。
【００２２】
図３に戻り、サービス申請情報データベース４６は、本サービスの申込みをしたＷＥＢ会員の現在のサービス状態および申込内容を格納しているデータベースである。サービス申請情報データベース４６の主要な項目を図４（ｃ）に示す。
図４（ｃ）において、「契約番号」は、上述の契約番号（カード番号）である。本実施形態では「契約番号」をサービス申請情報データベース４６の主キーとしており、ＷＥＢ会員はカードごとに本サービスを利用することができる。「サービス状態フラグ」は、本サービスの適用を有効にしているか無効にしているか（サービス提供対象であるか否か）を示すフラグである。「メール送信先区分」は、利用確認メールの送信先をパソコンのメールアドレスとするか、携帯電話のメールアドレスとするか、その両方とするかを示す区分である。「オプション機能状態フラグ」は、本サービスのオプション機能（速報通知の受信）の適用を有効にしているか無効にしているか（オプション機能の提供対象であるか否か）を示すフラグである。
【００２３】
図３に戻り、利用承認情報データベース４８は、カードの利用承認に関する情報（承認情報）から生成した利用承認情報を格納しているデータベースである。この利用承認情報は、後述の利用情報生成・送信処理５４にて、承認情報データベース５１の承認情報から生成されてデータベース・サーバ４０に送信され、利用承認情報データベース４８に格納される。利用承認情報データベース４８の主要な項目を図４（ｄ）に示す。
図４（ｄ）において、「契約番号」は、上述の契約番号（カード番号）である。「承認情報」は、カードの利用承認に関する情報であり、例えば利用日時・承認確定日・利用承認金額・企業コード等である。
【００２４】
図３に戻り、利用明細情報データベース４９は、カードの利用明細（売上）に関する情報（売上情報）から生成した利用明細情報を格納しているデータベースである。この利用明細情報は、後述の利用情報生成・送信処理５４にて、売上情報データベース５２の売上情報から生成されてデータベース・サーバ４０に送信され、利用明細情報データベース４９に格納される。利用明細情報データベース４９の主要な項目を図４（ｅ）に示す。
図４（ｅ）において、「契約番号」は、上述の契約番号（カード番号）である。「売上情報」は、カードの利用明細（売上）に関する情報であり、例えば利用日・売上確定日・加盟店番号・加盟店名称・利用金額・支払回数等である。
【００２５】
図３に戻り、ホスト・コンピュータ５０は、店舗（加盟店）でカードが利用されると、該店舗のＣＡＴ（Ｃｒｅｄｉｔｃａｒｄ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｔｅｒｍｉｎａｌ）端末６０から情報を受け取って、信用承認に関する処理，売上に関する処理，利用情報生成・送信に関する処理を行なうホスト・コンピュータである。
カードの利用承認に関する情報（承認情報）は、承認情報データベース５１に格納される。一方、信用承認されて、さらに加盟店から売上請求されたカードの利用明細（売上）に関する情報（売上情報）は、売上情報データベース５２に格納される。また、本実施形態のシステムのために利用情報生成・送信処理５４を用意する。
【００２６】
承認情報データベース５１は、上述のように、承認情報を格納しているデータベースである。承認情報データベース５１の主要な項目を図５（ａ）に示す。
図５（ａ）において、「契約番号」は、上述の契約番号（カード番号）である。「承認情報」は、カードの利用日時・承認確定日・利用承認金額・企業コード等の承認情報である。「データ処理済フラグ」は、その承認情報から利用承認情報を生成してデータベース・サーバ４０に送信済みであるか否かを示すフラグであり、利用承認情報を生成・送信したらフラグを立てる。
【００２７】
図３に戻り、売上情報データベース５２は、上述のように、売上情報を格納しているデータベースである。売上情報データベース５２の主要な項目を図５（ｂ）に示す。
図５（ｂ）において、「契約番号」は、上述の契約番号（カード番号）である。「売上情報」は、カードの利用日・売上確定日・加盟店番号・加盟店名称・利用金額・支払回数等の売上情報である。「データ処理済フラグ」は、その売上情報から利用明細情報を生成してデータベース・サーバ４０に送信済みであるかを示すフラグであり、利用明細情報を生成・送信したらフラグを立てる。
【００２８】
図３に戻り、利用情報生成・送信処理５４は、承認情報データベース５１から承認情報を、売上情報データベース５２から売上情報を、それぞれ取り出して上述の利用承認情報または利用明細情報を生成し、データベース・サーバ４０に送信するプログラムである。送信された利用情報は、承認情報から生成した利用承認情報については利用承認情報データベース４８に、売上情報から生成した利用明細情報については利用明細情報データベース４９に、それぞれ格納される。
【００２９】
（３．本実施形態のデータ処理）
図３に示すように、本実施形態のシステムに必要なデータ処理は次の３つである。
（１）サービス利用登録・更新処理３２
（２）利用情報生成・送信処理５４
（３）利用確認メール生成・送信処理３４
以降、これらのデータ処理を、図面を参照して詳細に説明する。
【００３０】
（３−１．サービス利用登録・更新処理）
サービス利用登録・更新処理３２は、ＷＥＢ会員が顧客端末１０から本サービスへの登録（新規または更新）を要求すると、その内容をデータベースに登録する処理である。
上述のように、本実施形態では、ＷＥＢ会員が申込みを行なったカードごとに本サービスを適用できる。ＷＥＢ会員は、ＷＥＢ会員専用のシステムにログインし、ＷＥＢ上で本サービスの利用を申込む。
なお、これは運用の一例であり、他の方法で本サービスの適用対象を決めてもよい。
【００３１】
ログインは、従来利用されているログイン・システムにより行なうとよい。
例えば、アプリケーション・サーバ３０から顧客端末１０に送信されたログイン用ページに、ＷＥＢ会員がＷＥＢ会員番号とパスワードを入力・送信すると、データベース・サーバ４０のＷＥＢ会員情報データベース４２を検索して該ＷＥＢ会員のＷＥＢ会員情報を取得する。入力されたＷＥＢ会員番号がＷＥＢ会員情報データベース４２にない場合やパスワードが間違っている場合はログイン失敗であり、その旨を表示したページ等を顧客端末１０に送信する。一方、ＷＥＢ会員番号とパスワードが正しければログイン成功であり、以降で説明する本サービスへの登録（新規または更新）を行なうことができる。
ＷＥＢ会員が複数のカードを契約している場合には、該会員が本サービスを適用したいカードを選択して、その選択したカードごとに登録を要求する。
【００３２】
図６は、サービス利用登録・更新処理３２の処理の流れを示すシーケンス図である。シーケンス図は上述のログイン成功後の処理を示している。
図６において、まず、顧客端末１０からアプリケーション・サーバ３０に、本サービスへの利用登録を要求する（Ｓ６０５）。例えば、ログインするとアプリケーション・サーバ３０から顧客端末１０にＷＥＢ会員専用のメニューページを送信し、ＷＥＢ会員がメニューの中から所望のサービスを選択する（本実施形態では、例えば、本サービスを適用したいカードを選択して本サービスの申込ページへのリンクをクリックする）ことにより行なう。
要求（Ｓ６０５）を受けると、アプリケーション・サーバ３０は、データベース・サーバ４０に、ＷＥＢ会員が選択したカードの契約番号でサービス申請情報データベース４６を検索する要求を送信する（Ｓ６１０）。データベース・サーバ４０ではサービス申請情報データベース４６を検索（Ｓ６１５）し、結果をアプリケーション・サーバ３０に送信する（Ｓ６２０）。
【００３３】
アプリケーション・サーバ３０は、データベース・サーバ４０から送られた結果（Ｓ６２０）に応じて、登録用ページを顧客端末１０に送信する（Ｓ６２５）。本実施形態では、ここで、サービス登録状態の確認ページを顧客端末１０に送信し、本サービスへの現在の登録状況を確認することとしている。
ここでは、本サービスに未登録のＷＥＢ会員に対して行なわれる処理を例に説明する。
図７は、顧客端末１０に送信されるサービス登録状態の確認ページの例である。
確認ページ７００において、「確認／変更／確認／完了」表示欄７４０は、登録の手順（サービス登録状態の確認→登録状態（表示内容）の変更→登録申請内容の確認→登録申請の完了）を示しており、ここでは「変更」の左の「確認」の部分を網掛けで示している。また、「トップへ戻る」ボタン７３０は、トップページ（例えば、ＷＥＢ会員専用のメニューページ）に戻るボタンである。
「サービス区分」表示欄７１０は、サービス区分の表示欄であり、サービス申請情報データベース４６のサービス状態フラグの現在の内容を表示する。すなわち、サービス申請情報データベース４６に契約番号に該当するレコードが存在しない場合には「未登録」と表示する。一方、レコードが存在する場合には、サービス状態フラグが立っていれば「登録中」、同フラグが立っていなければ「停止中」と表示する。
なお、登録中または停止中のユーザに対して送信される登録状態の確認ページには、サービス区分（サービス状態フラグの現在の内容）の他に、サービスが有効であれば、送信先区分（登録済のメールアドレス）やオプション機能状態フラグの現在の内容を表示してもよい。この場合、ボタン７２０には「変更する」と表示する。
【００３４】
ＷＥＢ会員が「登録する」ボタン７２０をクリックすると、アプリケーション・サーバ３０は、現在のサービス登録状態に応じて、登録（新規または更新）用ページを顧客端末１０に送信する（図６のＳ６２５）。
図８は、顧客端末１０に送信（図６のＳ６２５）されるサービス登録状態の変更ページの例である。
変更ページ８００において、「確認／変更／確認／完了」表示欄８５０は図７の確認ページ７００と同様であり、ここでは「変更」の部分を網掛けで表示する。また、「トップへ戻る」ボタン８４０は、図７の「トップへ戻る」ボタン７３０と同様である。
「メール送信先区分」入力欄８１０は、メール送信先区分の入力欄であり、サービス申請情報データベース４６のメール送信先区分に対応している。ＷＥＢ会員は、利用確認メールの送信先として「パソコン」，「携帯」，「両方」のいずれかを選択（ラジオボタンをクリック）する。「パソコン」を選択するとパソコンメールアドレスのみに、「携帯」を選択すると携帯メールアドレスのみに、「両方」を選択するとパソコンと携帯のメールアドレスに、利用確認メールが送信される。
なお、メール送信先区分の内容は一例である。また、本実施形態においては、確認メールの送信先のメールアドレスは、ＷＥＢ会員情報（図４（ａ））としてＷＥＢ会員情報データベース４２に登録されている情報を利用している。この送信先メールアドレスを変更する場合には、「メールアドレスの変更はコチラ」をクリックして、ＷＥＢ会員情報の変更登録をする必要がある。
「オプション機能」入力欄８２０は、オプション機能の入力欄であり、サービス申請情報データベース４６のオプション機能状態フラグに対応している。ＷＥＢ会員は、本サービスのオプション機能である速報通知を受信したい場合は、ラジオボタンをクリックする。
なお、図８は、メール送信先区分としてパソコンメールアドレスと携帯メールアドレスの「両方」、オプション機能として「速報通知を受信する」が選択された状態を示している。
【００３５】
ＷＥＢ会員が図８の変更ページ８００の各入力欄に必要な項目を入力（図６のＳ６３０）し、「入力内容を確認する」ボタン８３０をクリックすると、入力内容はアプリケーション・サーバ３０に送信される（Ｓ６３５）。本実施形態では、ここで、登録申請内容の確認ページを顧客端末１０に送信し、該ＷＥＢ会員に入力内容の確認を求める。
図９は、登録申請内容の確認ページの例である。図９の確認ページ９００において、「確認／変更／確認／完了」表示欄９６０は、図７の確認ページ７００および図８の変更ページ８００と同様であり、ここでは「変更」の右側の「確認」の部分を網掛けで表示する。「戻る」ボタン９５０は、前のページ（図８の変更ページ８００）に戻るためのボタンであり、入力内容を訂正する場合等に用いる。
「サービス区分」表示欄９１０には新規登録する旨の表示がなされる。また、「メール送信先区分」表示欄９２０および「オプション機能」表示欄９３０には、図８の変更ページ８００で入力（選択）された登録申請内容を表示する。
【００３６】
ＷＥＢ会員は、表示された内容で登録申請を行なう場合は、「申し込む」ボタン９４０をクリックする。入力内容はアプリケーション・サーバ３０に送信される（図６のＳ６３５）。
入力内容がアプリケーション・サーバ３０に送信される（Ｓ６３５）と、アプリケーション・サーバ３０は、該入力内容をデータベース・サーバ４０に送信する（Ｓ６４０）。データベース・サーバ４０は該入力内容をサービス申請情報データベース４６に登録し（Ｓ６４５）、登録完了の旨をアプリケーション・サーバ３０に送信する（Ｓ６５０）。
【００３７】
最後に、アプリケーション・サーバ３０は、登録申請の受付が完了した旨の登録申請の完了ページを顧客端末１０に送信する（Ｓ６５５）。
図１０は、登録申請の完了ページの例である。
図１０の完了ページ１０００において、「確認／変更／確認／完了」１０２０は、図７の確認ページ７００等と同様であり、ここでは「完了」の部分を網掛けで表示する。また、「トップページ」ボタン１０１０は、図７の確認ページ７００等の「トップへ戻る」ボタンと同様である。
【００３８】
上述した図７〜図１０の各ページは、顧客端末１０がパソコンである場合のページの例である。本実施形態では、顧客端末１０が携帯電話である場合も想定している。携帯電話用の各ページの例を図１１〜図１３に示す。
【００３９】
図１１は、サービス登録状態の確認ページの例であり、図７の確認ページ７００に対応している。「サービス区分」表示欄１１１０は、図７の「サービス区分」表示欄７１０と同じである。また、「登録する」ボタン１１２０，「トップページ」ボタン１１３０は、それぞれ図７の「登録する」ボタン７２０，図７の「トップへ戻る」ボタン７３０と同様である。
図１２は、登録状態の変更ページの例であり、図８の変更ページ８００に対応している。「メール送信先区分」入力欄１２１０，「オプション機能」入力欄１２２０は、それぞれ図８の「メール送信先区分」入力欄８１０，「オプション機能」入力欄８２０と同じである。また、「入力内容を確認」ボタン１２３０および「トップページ」ボタン１２４０も、それぞれ図８の「入力内容を確認する」ボタン８３０および「トップへ戻る」ボタン８４０と同様である。
図１３は、登録申請の完了ページの例であり、図１０の完了ページ１０００に対応している。「トップページ」ボタン１３１０は、図１０の「トップページ」ボタン１０１０と同様である。
なお、ここでは図示していないが、顧客端末１０が携帯電話の場合にも入力内容の確認ページ（図９の確認ページ９００に対応するページ）を設けてもよい。
【００４０】
（３−２．利用情報生成・送信処理）
利用情報生成・送信処理５４は、承認情報データベース５１の承認情報または売上情報データベース５２の売上情報から、それぞれ利用承認情報または利用明細情報を生成し、データベース・サーバ４０に送信する処理である。
本実施形態では、利用情報生成・送信処理を日次バッチ（例えば、当日分を夜間にバッチ処理）で行なうものとしているが、例えば一日に数回の定期バッチとしてもよく、さらには、カードの承認及び利用が同時に行なわれる場合にはリアルタイムで利用情報生成・送信処理を行なってもよい。
利用情報生成・送信処理でデータベース・サーバ４０に送信された利用情報は、承認情報から生成した利用承認情報については利用承認情報データベース４８に、売上情報から生成した利用明細情報については利用明細情報データベース４９に、それぞれ一旦格納され、その後、後述の利用確認メール生成・送信処理にて顧客端末１０に利用確認メールとして送信される。
【００４１】
図１４は、利用情報生成・送信処理５４の処理の流れを示すフローチャートである。なお、ここで示す処理手順は一例である。
まず、承認情報データベース５１から承認情報を、売上情報データベース５２から売上情報を、それぞれ取得する（Ｓ１４１０）。本実施形態では、データ処理済フラグを参照し、承認情報または売上情報のうちデータ処理済フラグが立っていない（すなわち、まだ利用情報生成・送信処理が行なわれていない）情報を取得する。
【００４２】
利用情報生成・送信処理を日次バッチで行なう場合、承認情報については、カードの信用承認に関する処理が完了して承認情報データベース５１に登録された、当日登録分の承認情報が処理の対象となる。一方、売上情報については、カード会社側のカード契約者に対する売上請求に関する処理が完了して売上情報データベース５２に登録された、当日登録分の売上情報が処理の対象となる。なお、利用情報生成・送信処理を定期バッチで行なう場合も、上記の処理は同じである。
取得するデータは、承認情報データベース５１の承認情報および売上情報データベース５２の売上情報のうち、利用確認メールの生成に必要な情報項目のみで足りる。
【００４３】
次に、取得した承認情報または売上情報から、利用情報（利用承認情報または利用明細情報）を生成して（図１４のＳ１４２０）、データベース・サーバ４０に送信する（Ｓ１４３０）。この処理を行なった日を、承認確定日または売上確定日とする。
最後に、送信した利用情報に対応する承認情報データベース５１および売上情報データベース５２のデータ処理済フラグにフラグを立てる（Ｓ１４４０）。データ処理済フラグを立てた承認情報および売上情報は、以降、利用情報生成・送信処理５４の処理対象から除かれる。
データベース・サーバ４０に送信された利用情報は、承認情報から生成した利用承認情報については利用承認情報データベース４８に、売上情報から生成した利用明細情報については利用明細情報データベース４９に、それぞれ別々に格納される。
【００４４】
（３−３．利用確認メール生成・送信処理）
利用確認メール生成・送信処理３４は、本サービスを申し込んでいるＷＥＢ会員のカードについて、カードの利用があったことを知らせるメール（利用確認メール）を生成し、該カードの契約者であるＷＥＢ会員宛に送信する処理である。
利用確認メールは、定期配信時（例えば、午前８時前後）に本サービスに登録しているＷＥＢ会員の顧客端末１０に対して送信する。本実施形態のように利用情報生成・送信処理を日次バッチ（当日分を夜間バッチ）で行なう場合、ＷＥＢ会員は、当日登録分の利用確認メールをその翌日の定期配信時に受け取ることができる。
このように、利用情報生成・送信処理５４と利用確認メール生成・送信処理３４との二段階に分けて処理を行なうことにより、迅速な利用通知を実現しながら、処理の負荷を軽減することができる。
【００４５】
図１５は、利用確認メール生成・送信処理３４の処理の流れを示すフローチャートである。この処理は、上述の定期配信時に起動して行う。なお、ここで示す処理手順は一例である。
最初に、利用承認情報データベース４８または利用明細情報データベース４９から利用確認メール生成・送信処理の対象となる利用情報を選択する（Ｓ１５１０〜Ｓ１５２０）。
この処理では、まず、サービス申請情報データベース４６を参照して、サービス状態フラグおよびオプション機能状態フラグのいずれもが立っている契約番号を取得する（Ｓ１５１０）。続いて、取得した契約番号をキーとして、利用承認情報データベース４８の利用承認情報から通知対象の項目（例えば、利用日・利用金額・加盟店名）を抽出する（Ｓ１５２０）。
同様に、サービス申請情報データベース４６を参照して、サービス状態フラグが立っている契約番号を取得する（Ｓ１５１０）。続いて、取得した契約番号をキーとして、利用明細情報データベース４９の利用明細情報から通知対象の項目（例えば、利用日・利用金額・加盟店名）を抽出する（Ｓ１５２０）。
【００４６】
次に、サービス申請情報データベース４６のメール送信先区分に応じて、ＷＥＢ会員情報データベース４２からパソコンメールアドレス、携帯メールアドレス、あるいはその両方を取得する（Ｓ１５３０）。
その後、利用確認メールを生成して（Ｓ１５４０）、顧客端末１０に送信する（Ｓ１５５０）。このとき、承認情報から生成した利用承認情報と売上情報から生成した利用明細情報のいずれもが送信対象である場合には、利用承認情報と利用明細情報とに区分して、１通のメールを生成する。
【００４７】
図１６は、顧客端末に送信する利用確認メールの例である。
利用確認メール１６００において、「宛先」欄１６１０には、上述で取得（Ｓ１５３０）したパソコンメールアドレス，携帯メールアドレスを入力する。「件名」欄１６２０は、あらかじめ用意した、「カード利用確認メール」である旨が分かりやすい件名とする。
「本文」欄１６３０には、利用承認情報から抽出した項目と，利用明細情報から抽出した項目とを、区別して入力する。ここでは、利用承認情報から抽出した項目は「速報情報」の項目とし、利用明細情報から抽出した項目は「売上情報」の項目としている。
また、利用承認情報から利用確認メールを生成する場合には、企業コードをキーとして、別途管理している同コードと加盟店名を紐付けたファイルを参照し、加盟店名を付加する。企業コードが上述の管理ファイルにない場合には、加盟店名を付加することができない。
また、上述のとおり、決済代行会社のシステムを通じて信用承認処理や売上請求処理が行なわれる場合、クレジットカード会社に対しては加盟店の情報が送信されないので、この場合にも加盟店名を入力することができない。図１６に示す利用確認メールの例では、加盟店名が不明な場合、アスタリスク（「＊」）を入力している。
その他、例えば、このメールがカード利用通知である旨の文章や、カード利用に心当たりがない場合の注意事項を示した文章等を自動的にメールの文面に含めるようにしてもよい。
【００４８】
最後に、利用確認メールを顧客端末１０に送信したら、定期バッチ処理等により、送信済の利用情報を利用承認情報データベース４８および利用明細情報データベース４９から削除する（図１５のＳ１５６０）。
【００４９】
＜他の実施形態の説明＞
上述の実施形態においては、カードの利用を承認した場合に限り、確認メールを送信することとしている。これに対し、カードの利用を承認しなかった（否認した）場合にも、確認メールを送信することとしてもよい。
この場合、ホスト・コンピュータ５０は、カードの利用を承認しなかった（否認した）という情報を、利用承認額０円の承認情報として、承認情報データベース５１に記憶する。これにより、顧客端末１０に対して、カードの利用を承認しなかった（否認した）という情報を、利用金額０円の速報情報として通知することが可能になる。
なお、確認メールの本文中では、利用金額の欄に「承認拒否」，「＊」等別の文字または記号を表示するようにして、カード契約者に対して注意喚起をしてもよい。また、確認メールの本文中には、利用金額欄に０円（または「承認拒否」，「＊」等の文字，記号）と表示されている場合には、カードの利用が承認されなかったことを明示するため、別途注意書きを設けてもよい。
【００５０】
上述の実施形態において、利用情報生成・送信処理５４は、日次バッチにより夜間に行なうこととしている。また、利用確認メール生成・送信処理３４は、１日１回の定期配信時に起動して実行することとしている。
これらの処理を定期的に（例えば、数時間ごと）行なうこととすれば、顧客端末に対し、利用確認メールをより迅速に送信することができる。また、承認情報が承認情報データベースに登録された直後にこれらの処理を行なうこととすれば、顧客端末に対し、利用確認メールをさらに迅速に送信することができる。
【図面の簡単な説明】
【００５１】
【図１】ユーザ，加盟店，カード会社および決済代行会社との間での売上情報に係る利用確認メールの送信を説明する図である。
【図２】承認情報に係る利用確認メールの送信のタイミングを説明するための図である。
【図３】本実施形態のシステム構成の一例を示す図である。
【図４】データベース・サーバの（ａ）ＷＥＢ会員情報データベース，（ｂ）契約情報データベース，（ｃ）サービス申請情報データベース，（ｄ）利用承認情報データベース，（ｅ）利用明細情報データベースの主要な項目を示す図である。
【図５】ホスト・コンピュータの（ａ）承認情報データベース，（ｂ）売上情報データベースの主要な項目を示す図である。
【図６】サービス利用登録・更新処理の流れを示すシーケンス図である。
【図７】サービス登録状態の確認ページの例を示す図である。
【図８】サービス登録状態の変更ページの例を示す図である。
【図９】登録申請内容の確認ページの例を示す図である。
【図１０】登録申請の完了ページの例を示す図である。
【図１１】携帯電話用のサービス登録状態の確認ページの例を示す図である。
【図１２】携帯電話用のサービス登録状態の変更ページの例を示す図である。
【図１３】携帯電話用の登録申請の完了ページの例を示す図である。
【図１４】利用情報生成・送信処理の流れを示すフローチャートである。
【図１５】利用確認メール生成・送信処理の流れを示すフローチャートである。
【図１６】利用確認メールの例を示す図である。
【符号の説明】
【００５２】
１０ 顧客端末
２０ ネットワーク
３０ アプリケーション・サーバ
３２ サービス利用登録・更新処理
３４ 利用確認メール生成・送信処理
４０ データベース・サーバ
４２ ＷＥＢ会員情報データベース
４４ 契約情報データベース
４６ サービス申請情報データベース
４８ 利用承認情報データベース
４９ 利用明細情報データベース
５０ ホスト・コンピュータ
５１ 承認情報データベース
５２ 売上情報データベース
５４ 利用情報生成・送信処理
６０ ＣＡＴ端末
７００ サービス登録状態の確認ページ
８００ サービス登録状態の変更ページ
９００ 登録申請内容の確認ページ
１０００ 登録申請の完了ページ
１１００ 携帯電話用のサービス登録状態の確認ページ
１２００ 携帯電話用のサービス登録状態の変更ページ
１３００ 携帯電話用の登録申請の完了ページ
１６００ 利用確認メール
【技術分野】
【０００１】
本発明は、クレジットカード等の契約者に対し、カードが使用されたこと等を迅速に通知するシステムに関するものである。
【背景技術】
【０００２】
最近、個人情報の流出やクレジットカードの不正利用等に関し、カード利用者の関心や不安感が高まっている。特に、カード番号の流出やスキミング等の実害として、契約者本人がカードを所持していながら、該カードに化体した信用が他人に悪用されてしまうという事態が問題となっている。
こうした悪用があった場合でも、契約者は通常、カード会社から送られてくる請求書を見るまで、その事実を把握することができない。しかも、請求書が契約者の手元に届くのは、通常、その悪用の事実があった日が含まれる月の翌月のことである。これは、カード会社による売上データの処理が、月単位で行なわれるからである。例えば、当月中に加盟店から送られてきた売上データは、翌月の定日（例えば、毎月１０日など）に契約者に対する請求データとして確定する。
このように、自己の信用が他人に悪用された事実を契約者本人が早期に把握するのは困難な状況にある。その結果、万一悪用があった場合でも、その事実の発見および対処（店舗等への確認，カードの利用停止等）が遅れ、被害の拡大につながるおそれがある。
【０００３】
こうした問題への対応として、カード会社が提供する会員専用のＷＥＢサイト上でカードの利用状況を確認することができるサービスが知られている。このサービスを利用すれば、契約者はいつでもカードの利用状況を確認することができる。
しかしながら、こうしたサービスは、契約者の自発的なアクセスを前提とするものである。さらには、提供される情報の性質上、確認の都度専用ページへのログインが必要になる。そのため、他人による悪用行為を日常的に監視するのは困難である。
【０００４】
また、カードの利用後、売上データがカード会社のデータベースに登録された時点で、契約者が指定したメールアドレス宛の電子メールでカードの利用内容を通知するサービスがある（本出願人による特願２００６−０３５２１１参照）。このサービスを利用すれば、契約者は、いち早く自身のカードの利用内容を確認することができる。
【０００５】
ここで、売上データがカード会社のデータベースに登録された時点で利用確認メールを送信する場合を説明する。
図１は、ユーザ，加盟店，カード会社および決済代行会社との間での売上情報に係る利用確認メールの送信を説明する図である。
クレジットカードの利用があった場合、加盟店は、売上請求に関する処理を行ない（１）、カード会社に対し利用額の支払いを請求する（２）。この請求処理は、信用承認のための照会処理と同時に行なう場合や、カードの利用から一定期間の経過後に、一定期間内の売上額を一括して行なう場合がある。インターネットショッピングの場合は商品の発送後に行なうことが多い。
この請求を受けたカード会社は、売上請求に関する処理を行ない（３）、各ユーザに対する売上請求額を確定させる。ユーザに対して「利用確認メール」を送信する（４）のはこの時点となる。
その後又は同時に、ユーザに対し利用額を請求（請求書を郵送）する（５）。この請求を受けたユーザは、カード会社に対し利用額を支払う（６または７）。カード会社も、加盟店に対し、自動引落等により利用額を支払う（６または７）。なお、（６）と（７）の先後は、場合により異なる。
なお、インターネットショッピングの場合は、上記の処理の一部は決済代行会社のシステムを通じて間接的に行なわれる（２）’。
【０００６】
このように、カード会社側のユーザに対する売上請求に関する処理は、各加盟店ごとに行なわれるカード会社に対する売上請求に関する処理が完了した後に行っている。そのため、確認メールの送信時を「売上データがカード会社のデータベースに登録された時点」とすると、ユーザに対する通知が遅れてしまう。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、クレジットカードの契約者に対し、カードに化体した信用が他人に悪用された事実の早期発見に資する仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明は、クレジットカードの使用があったことを、ユーザの端末に電子メールで通知するカード使用通知システムであって、クレジットカードの承認情報から生成した、前記ユーザのカード番号に対する利用承認情報を記憶する利用承認情報記憶手段と、前記ユーザのＩＤと、メールアドレスと、前記カード番号と、使用通知サービスの申請情報とを記憶しているユーザ情報記憶手段と、前記使用通知サービスを申請している前記ユーザの利用承認情報を、前記カード番号で前記利用承認情報記憶手段から読み出して使用確認メールを生成し、前記ユーザの前記メールアドレス宛に送信する使用確認メール生成・送信手段とを備えていることを特徴とする。
前記カード使用通知システムにおいて、さらに、クレジットカードの売上情報から生成した、前記ユーザのカード番号に対する利用明細情報を記憶する利用明細情報記憶手段を備え、前記使用確認メール生成・送信手段は、前記カード番号に対する利用明細情報を該利用明細情報記憶手段から読み出して、前記利用承認情報と前記利用明細情報とを区別して、使用確認メールを生成することを特徴としてもよい。
前記カード使用通知システムにおいて、前記利用承認情報は、さらに、クレジットカードの利用否認情報を含むことを特徴としてもよい。
【０００９】
前記カード使用通知システムにおいて、前記ユーザ情報記憶手段には、前記ユーザごとに複数のメールアドレスを記憶でき、前記ユーザ情報記憶手段に記憶している前記使用通知サービスの申請情報には、さらに、前記使用確認メールを送るべき送信先区分情報を含み、前記使用確認メール生成・送信手段は、前記メール送信先区分情報により前記送信するメールアドレスを決定することを特徴としてもよい。
前記カード使用通知システムにおいて、さらに、前記ユーザを、登録するときはカード番号で、更新するときは前記ＩＤで認証するログイン手段と、前記ユーザが、カード番号でログイン後、前記端末から前記使用通知サービスの申請情報を登録するための使用通知サービス申請情報登録手段と、前記使用通知サービス申請情報登録手段で登録後、前記ＩＤを付与するＩＤ付与手段と、前記ＩＤでログイン後、前記使用通知サービス申請情報を更新する更新手段とを備えることを特徴としてもよい。
【００１０】
また、本発明は、クレジットカードの使用があったことを、ユーザの端末に電子メールで通知するカード使用通知方法であって、クレジットカードの承認情報から生成した、前記ユーザのカード番号に対する利用承認情報を記憶する利用承認情報記憶手段と、前記ユーザのＩＤと、メールアドレスと、前記カード番号と、使用通知サービスの申請情報とを記憶しているユーザ情報記憶手段とを有し、前記使用通知サービスを申請している前記ユーザの利用承認情報を、前記カード番号で前記利用承認情報記憶手段から読み出して使用確認メールを生成し、前記ユーザの前記メールアドレス宛に送信することを特徴とする。
前記カード使用通知システムの各手段をコンピュータに機能として実現させるためのプログラムも本発明である。
【発明の効果】
【００１１】
本発明のカード使用通知システムによれば、クレジットカード契約者に対し、カードの使用があった事実を電子メールで迅速に通知することができる。その結果、万一カードが他人に悪用された場合であっても、契約者はその事実を早期に発見し適切に対処することで、被害を最小限に抑えることができる。しかも、契約者は、店舗側の信用承認処理タイミングと売上請求処理タイミングの間でカードが悪用された事実を発見できるので、売上請求処理の実行に対して適切に対処することができ、本システムは契約者の被害極小化に資することができる。
また、電子メールは保管や閲覧が容易である。そのため、本発明のカード使用通知システムにより通知された電子メールは、例えば、後に郵送された利用明細と照合して利用内容を再確認する等、カード利用の覚書としても有用である。
【発明を実施するための最良の形態】
【００１２】
以降、本発明のカード使用通知システムの実施形態の一例を、図面を参照して詳細に説明する。
なお、本実施形態において、「信用承認に関する処理」とは、クレジットカードの利用の可否（有効性，利用可能額等）に関する加盟店（店舗）からの照会に対して、該カードの利用の可否を該加盟店に返答する処理のことである。クレジットカードの利用を承認する場合、カード会社側のシステムでは売上の予約の処理（利用額の確保処理）を行ない、その利用承認に関するデータ（承認情報）をデータベースに登録する。
【００１３】
＜本実施形態の説明＞
（１．本実施形態の概略）
本実施形態の概略を、図面を参照して説明する。
図２は、ユーザ，加盟店，カード会社および決済代行会社との間での利用確認メールの送信を説明する図である。この図で、利用確認メールの送信の概略を説明する。
ユーザが商品またはサービスの購入にクレジットカードを利用する（１）場合、カードの提示を受けた加盟店は、カード会社に対し該カードの利用の可否（カードの有効性・利用可能額）を照会する（２）。
この照会を受けたカード会社は、信用承認に関する処理を行ない（３）、該カードの利用を承認する場合はその旨を加盟店に対して返答する（４）とともに、利用額の確保処理を行なう。
カードの利用が承認されると、加盟店は、所定のカード処理（例えば、本人確認，署名の照合等）を行ない（５）、ユーザにカード利用書を発行する（６）。
以上の処理の完了後、カード会社は、承認情報をデータベースに登録し、この情報から生成した「利用確認メール」をユーザに対して送信する（７）。ここで、カードの利用を承認しなかった（否認した）場合にも、「否認」したという承認情報をデータベースに登録し、確認メールを送信することとしてもよい。
なお、加盟店と契約をする機能（アクワイヤラー）とカードを発行する機能（イッシュアラー）とが分業化されている場合は、上記の処理の一部はアクワイヤラー（以下、「決済代行会社」という。）のシステムを通じて間接的に行なわれる（２）’，（４）’。
【００１４】
このように、信用承認に関する処理は、売上請求処理に先立って、クレジットカードの利用時にその都度行なわれるものである。したがって、利用確認メールの送信時を「承認データがカード会社のデータベースに登録された時点」とすることにより、カード利用後の早い時期にユーザに対して通知することが可能になる。
【００１５】
（２．本実施形態のシステム構成）
本実施形態のシステム構成を、図面を参照して説明する。
図３は、本実施形態のシステム構成の一例を示す図である。
前提として、パソコンや携帯電話等の端末を用いてＷＥＢ上でのサービスを利用しているＷＥＢ会員（ユーザ）が、本実施形態のシステムによるカード利用通知サービス（以下、「本サービス」という。）を申し込み、申し込みのあったカードに対して本サービスを提供するものとする。
なお、これは運用の一例であり、他の方法で本サービスの適用対象を決めてもよい。
【００１６】
顧客端末１０は、ＷＥＢ会員が用いる端末である。本実施形態では、例えばパソコンや携帯電話等の端末とする。
顧客端末１０は、インターネット等のネットワーク２０を介して、アプリケーション・サーバ３０から本サービスを受けることができる。ここでは、ＷＥＢ会員として入会する際にユニークなＩＤである「ＷＥＢ会員番号」と「パスワード」が与えられており、ＷＥＢ上でのサービスを受けるための認証はＷＥＢ会員番号（ＩＤ）とパスワードにより行なうものとする。
【００１７】
アプリケーション・サーバ３０は、顧客端末１０を通じてＷＥＢ会員に対してＷＥＢ上でサービスを提供するためのシステム等を格納しているサーバである。ここでは、本実施形態のシステムに関して必要な部分のみ説明する。
【００１８】
サービス利用登録・更新処理３２は、ＷＥＢ会員が顧客端末１０からカードごとに本サービスへの登録（新規または更新）を行なうと、その内容をデータベースに登録（更新）するプログラムである。
利用確認メール生成・送信処理３４は、本サービスが申し込まれているカードについて、カードの利用があったことを知らせるメール（利用確認メール）を生成し、該カードの契約者であるＷＥＢ会員の顧客端末１０宛に送信するプログラムである。
【００１９】
データベース・サーバ４０は、ＷＥＢ上でのサービスの提供等に必要なデータベースを格納しているサーバである。ここでは、本実施形態のシステムに関して必要な部分のみ説明する。
【００２０】
ＷＥＢ会員情報データベース４２は、ＷＥＢ会員の情報を格納しているデータベースである。ＷＥＢ会員情報データベース４２の主要な項目を図４（ａ）に示す。
図４（ａ）において、「ＷＥＢ会員番号」は、上述のＷＥＢ会員番号である。「パスワード」は、上述のように、ＷＥＢ会員の認証に用いるパスワードである。「パソコンメールアドレス」および「携帯メールアドレス」は、それぞれ、該ＷＥＢ会員のパソコンおよび携帯電話のメールアドレスであり、本実施形態の利用確認メールの送信先となる。これらのＷＥＢ会員情報データベース４２の各項目の内容は、例えばＷＥＢ会員として入会する際に登録され、必要に応じて更新される。
【００２１】
図３に戻り、契約情報データベース４４は、ＷＥＢ会員のカードの契約情報を格納しているデータベースである。契約情報データベース４４の主要な項目を図４（ｂ）に示す。
図４（ｂ）において、「契約番号」は、クレジットカード等のカードの契約番号（カード番号）であり、カードに一意の番号である。「ＷＥＢ会員番号」は、上述のＷＥＢ会員番号である。その他、カードの契約内容（例えば、カードの有効期限・契約者の生年月日・住所・電話番号・ＣＣＶ２等）を格納している。本実施形態では、カードの契約番号をＷＥＢ会員に紐付けるデータベースとして用いている。
【００２２】
図３に戻り、サービス申請情報データベース４６は、本サービスの申込みをしたＷＥＢ会員の現在のサービス状態および申込内容を格納しているデータベースである。サービス申請情報データベース４６の主要な項目を図４（ｃ）に示す。
図４（ｃ）において、「契約番号」は、上述の契約番号（カード番号）である。本実施形態では「契約番号」をサービス申請情報データベース４６の主キーとしており、ＷＥＢ会員はカードごとに本サービスを利用することができる。「サービス状態フラグ」は、本サービスの適用を有効にしているか無効にしているか（サービス提供対象であるか否か）を示すフラグである。「メール送信先区分」は、利用確認メールの送信先をパソコンのメールアドレスとするか、携帯電話のメールアドレスとするか、その両方とするかを示す区分である。「オプション機能状態フラグ」は、本サービスのオプション機能（速報通知の受信）の適用を有効にしているか無効にしているか（オプション機能の提供対象であるか否か）を示すフラグである。
【００２３】
図３に戻り、利用承認情報データベース４８は、カードの利用承認に関する情報（承認情報）から生成した利用承認情報を格納しているデータベースである。この利用承認情報は、後述の利用情報生成・送信処理５４にて、承認情報データベース５１の承認情報から生成されてデータベース・サーバ４０に送信され、利用承認情報データベース４８に格納される。利用承認情報データベース４８の主要な項目を図４（ｄ）に示す。
図４（ｄ）において、「契約番号」は、上述の契約番号（カード番号）である。「承認情報」は、カードの利用承認に関する情報であり、例えば利用日時・承認確定日・利用承認金額・企業コード等である。
【００２４】
図３に戻り、利用明細情報データベース４９は、カードの利用明細（売上）に関する情報（売上情報）から生成した利用明細情報を格納しているデータベースである。この利用明細情報は、後述の利用情報生成・送信処理５４にて、売上情報データベース５２の売上情報から生成されてデータベース・サーバ４０に送信され、利用明細情報データベース４９に格納される。利用明細情報データベース４９の主要な項目を図４（ｅ）に示す。
図４（ｅ）において、「契約番号」は、上述の契約番号（カード番号）である。「売上情報」は、カードの利用明細（売上）に関する情報であり、例えば利用日・売上確定日・加盟店番号・加盟店名称・利用金額・支払回数等である。
【００２５】
図３に戻り、ホスト・コンピュータ５０は、店舗（加盟店）でカードが利用されると、該店舗のＣＡＴ（Ｃｒｅｄｉｔｃａｒｄ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｔｅｒｍｉｎａｌ）端末６０から情報を受け取って、信用承認に関する処理，売上に関する処理，利用情報生成・送信に関する処理を行なうホスト・コンピュータである。
カードの利用承認に関する情報（承認情報）は、承認情報データベース５１に格納される。一方、信用承認されて、さらに加盟店から売上請求されたカードの利用明細（売上）に関する情報（売上情報）は、売上情報データベース５２に格納される。また、本実施形態のシステムのために利用情報生成・送信処理５４を用意する。
【００２６】
承認情報データベース５１は、上述のように、承認情報を格納しているデータベースである。承認情報データベース５１の主要な項目を図５（ａ）に示す。
図５（ａ）において、「契約番号」は、上述の契約番号（カード番号）である。「承認情報」は、カードの利用日時・承認確定日・利用承認金額・企業コード等の承認情報である。「データ処理済フラグ」は、その承認情報から利用承認情報を生成してデータベース・サーバ４０に送信済みであるか否かを示すフラグであり、利用承認情報を生成・送信したらフラグを立てる。
【００２７】
図３に戻り、売上情報データベース５２は、上述のように、売上情報を格納しているデータベースである。売上情報データベース５２の主要な項目を図５（ｂ）に示す。
図５（ｂ）において、「契約番号」は、上述の契約番号（カード番号）である。「売上情報」は、カードの利用日・売上確定日・加盟店番号・加盟店名称・利用金額・支払回数等の売上情報である。「データ処理済フラグ」は、その売上情報から利用明細情報を生成してデータベース・サーバ４０に送信済みであるかを示すフラグであり、利用明細情報を生成・送信したらフラグを立てる。
【００２８】
図３に戻り、利用情報生成・送信処理５４は、承認情報データベース５１から承認情報を、売上情報データベース５２から売上情報を、それぞれ取り出して上述の利用承認情報または利用明細情報を生成し、データベース・サーバ４０に送信するプログラムである。送信された利用情報は、承認情報から生成した利用承認情報については利用承認情報データベース４８に、売上情報から生成した利用明細情報については利用明細情報データベース４９に、それぞれ格納される。
【００２９】
（３．本実施形態のデータ処理）
図３に示すように、本実施形態のシステムに必要なデータ処理は次の３つである。
（１）サービス利用登録・更新処理３２
（２）利用情報生成・送信処理５４
（３）利用確認メール生成・送信処理３４
以降、これらのデータ処理を、図面を参照して詳細に説明する。
【００３０】
（３−１．サービス利用登録・更新処理）
サービス利用登録・更新処理３２は、ＷＥＢ会員が顧客端末１０から本サービスへの登録（新規または更新）を要求すると、その内容をデータベースに登録する処理である。
上述のように、本実施形態では、ＷＥＢ会員が申込みを行なったカードごとに本サービスを適用できる。ＷＥＢ会員は、ＷＥＢ会員専用のシステムにログインし、ＷＥＢ上で本サービスの利用を申込む。
なお、これは運用の一例であり、他の方法で本サービスの適用対象を決めてもよい。
【００３１】
ログインは、従来利用されているログイン・システムにより行なうとよい。
例えば、アプリケーション・サーバ３０から顧客端末１０に送信されたログイン用ページに、ＷＥＢ会員がＷＥＢ会員番号とパスワードを入力・送信すると、データベース・サーバ４０のＷＥＢ会員情報データベース４２を検索して該ＷＥＢ会員のＷＥＢ会員情報を取得する。入力されたＷＥＢ会員番号がＷＥＢ会員情報データベース４２にない場合やパスワードが間違っている場合はログイン失敗であり、その旨を表示したページ等を顧客端末１０に送信する。一方、ＷＥＢ会員番号とパスワードが正しければログイン成功であり、以降で説明する本サービスへの登録（新規または更新）を行なうことができる。
ＷＥＢ会員が複数のカードを契約している場合には、該会員が本サービスを適用したいカードを選択して、その選択したカードごとに登録を要求する。
【００３２】
図６は、サービス利用登録・更新処理３２の処理の流れを示すシーケンス図である。シーケンス図は上述のログイン成功後の処理を示している。
図６において、まず、顧客端末１０からアプリケーション・サーバ３０に、本サービスへの利用登録を要求する（Ｓ６０５）。例えば、ログインするとアプリケーション・サーバ３０から顧客端末１０にＷＥＢ会員専用のメニューページを送信し、ＷＥＢ会員がメニューの中から所望のサービスを選択する（本実施形態では、例えば、本サービスを適用したいカードを選択して本サービスの申込ページへのリンクをクリックする）ことにより行なう。
要求（Ｓ６０５）を受けると、アプリケーション・サーバ３０は、データベース・サーバ４０に、ＷＥＢ会員が選択したカードの契約番号でサービス申請情報データベース４６を検索する要求を送信する（Ｓ６１０）。データベース・サーバ４０ではサービス申請情報データベース４６を検索（Ｓ６１５）し、結果をアプリケーション・サーバ３０に送信する（Ｓ６２０）。
【００３３】
アプリケーション・サーバ３０は、データベース・サーバ４０から送られた結果（Ｓ６２０）に応じて、登録用ページを顧客端末１０に送信する（Ｓ６２５）。本実施形態では、ここで、サービス登録状態の確認ページを顧客端末１０に送信し、本サービスへの現在の登録状況を確認することとしている。
ここでは、本サービスに未登録のＷＥＢ会員に対して行なわれる処理を例に説明する。
図７は、顧客端末１０に送信されるサービス登録状態の確認ページの例である。
確認ページ７００において、「確認／変更／確認／完了」表示欄７４０は、登録の手順（サービス登録状態の確認→登録状態（表示内容）の変更→登録申請内容の確認→登録申請の完了）を示しており、ここでは「変更」の左の「確認」の部分を網掛けで示している。また、「トップへ戻る」ボタン７３０は、トップページ（例えば、ＷＥＢ会員専用のメニューページ）に戻るボタンである。
「サービス区分」表示欄７１０は、サービス区分の表示欄であり、サービス申請情報データベース４６のサービス状態フラグの現在の内容を表示する。すなわち、サービス申請情報データベース４６に契約番号に該当するレコードが存在しない場合には「未登録」と表示する。一方、レコードが存在する場合には、サービス状態フラグが立っていれば「登録中」、同フラグが立っていなければ「停止中」と表示する。
なお、登録中または停止中のユーザに対して送信される登録状態の確認ページには、サービス区分（サービス状態フラグの現在の内容）の他に、サービスが有効であれば、送信先区分（登録済のメールアドレス）やオプション機能状態フラグの現在の内容を表示してもよい。この場合、ボタン７２０には「変更する」と表示する。
【００３４】
ＷＥＢ会員が「登録する」ボタン７２０をクリックすると、アプリケーション・サーバ３０は、現在のサービス登録状態に応じて、登録（新規または更新）用ページを顧客端末１０に送信する（図６のＳ６２５）。
図８は、顧客端末１０に送信（図６のＳ６２５）されるサービス登録状態の変更ページの例である。
変更ページ８００において、「確認／変更／確認／完了」表示欄８５０は図７の確認ページ７００と同様であり、ここでは「変更」の部分を網掛けで表示する。また、「トップへ戻る」ボタン８４０は、図７の「トップへ戻る」ボタン７３０と同様である。
「メール送信先区分」入力欄８１０は、メール送信先区分の入力欄であり、サービス申請情報データベース４６のメール送信先区分に対応している。ＷＥＢ会員は、利用確認メールの送信先として「パソコン」，「携帯」，「両方」のいずれかを選択（ラジオボタンをクリック）する。「パソコン」を選択するとパソコンメールアドレスのみに、「携帯」を選択すると携帯メールアドレスのみに、「両方」を選択するとパソコンと携帯のメールアドレスに、利用確認メールが送信される。
なお、メール送信先区分の内容は一例である。また、本実施形態においては、確認メールの送信先のメールアドレスは、ＷＥＢ会員情報（図４（ａ））としてＷＥＢ会員情報データベース４２に登録されている情報を利用している。この送信先メールアドレスを変更する場合には、「メールアドレスの変更はコチラ」をクリックして、ＷＥＢ会員情報の変更登録をする必要がある。
「オプション機能」入力欄８２０は、オプション機能の入力欄であり、サービス申請情報データベース４６のオプション機能状態フラグに対応している。ＷＥＢ会員は、本サービスのオプション機能である速報通知を受信したい場合は、ラジオボタンをクリックする。
なお、図８は、メール送信先区分としてパソコンメールアドレスと携帯メールアドレスの「両方」、オプション機能として「速報通知を受信する」が選択された状態を示している。
【００３５】
ＷＥＢ会員が図８の変更ページ８００の各入力欄に必要な項目を入力（図６のＳ６３０）し、「入力内容を確認する」ボタン８３０をクリックすると、入力内容はアプリケーション・サーバ３０に送信される（Ｓ６３５）。本実施形態では、ここで、登録申請内容の確認ページを顧客端末１０に送信し、該ＷＥＢ会員に入力内容の確認を求める。
図９は、登録申請内容の確認ページの例である。図９の確認ページ９００において、「確認／変更／確認／完了」表示欄９６０は、図７の確認ページ７００および図８の変更ページ８００と同様であり、ここでは「変更」の右側の「確認」の部分を網掛けで表示する。「戻る」ボタン９５０は、前のページ（図８の変更ページ８００）に戻るためのボタンであり、入力内容を訂正する場合等に用いる。
「サービス区分」表示欄９１０には新規登録する旨の表示がなされる。また、「メール送信先区分」表示欄９２０および「オプション機能」表示欄９３０には、図８の変更ページ８００で入力（選択）された登録申請内容を表示する。
【００３６】
ＷＥＢ会員は、表示された内容で登録申請を行なう場合は、「申し込む」ボタン９４０をクリックする。入力内容はアプリケーション・サーバ３０に送信される（図６のＳ６３５）。
入力内容がアプリケーション・サーバ３０に送信される（Ｓ６３５）と、アプリケーション・サーバ３０は、該入力内容をデータベース・サーバ４０に送信する（Ｓ６４０）。データベース・サーバ４０は該入力内容をサービス申請情報データベース４６に登録し（Ｓ６４５）、登録完了の旨をアプリケーション・サーバ３０に送信する（Ｓ６５０）。
【００３７】
最後に、アプリケーション・サーバ３０は、登録申請の受付が完了した旨の登録申請の完了ページを顧客端末１０に送信する（Ｓ６５５）。
図１０は、登録申請の完了ページの例である。
図１０の完了ページ１０００において、「確認／変更／確認／完了」１０２０は、図７の確認ページ７００等と同様であり、ここでは「完了」の部分を網掛けで表示する。また、「トップページ」ボタン１０１０は、図７の確認ページ７００等の「トップへ戻る」ボタンと同様である。
【００３８】
上述した図７〜図１０の各ページは、顧客端末１０がパソコンである場合のページの例である。本実施形態では、顧客端末１０が携帯電話である場合も想定している。携帯電話用の各ページの例を図１１〜図１３に示す。
【００３９】
図１１は、サービス登録状態の確認ページの例であり、図７の確認ページ７００に対応している。「サービス区分」表示欄１１１０は、図７の「サービス区分」表示欄７１０と同じである。また、「登録する」ボタン１１２０，「トップページ」ボタン１１３０は、それぞれ図７の「登録する」ボタン７２０，図７の「トップへ戻る」ボタン７３０と同様である。
図１２は、登録状態の変更ページの例であり、図８の変更ページ８００に対応している。「メール送信先区分」入力欄１２１０，「オプション機能」入力欄１２２０は、それぞれ図８の「メール送信先区分」入力欄８１０，「オプション機能」入力欄８２０と同じである。また、「入力内容を確認」ボタン１２３０および「トップページ」ボタン１２４０も、それぞれ図８の「入力内容を確認する」ボタン８３０および「トップへ戻る」ボタン８４０と同様である。
図１３は、登録申請の完了ページの例であり、図１０の完了ページ１０００に対応している。「トップページ」ボタン１３１０は、図１０の「トップページ」ボタン１０１０と同様である。
なお、ここでは図示していないが、顧客端末１０が携帯電話の場合にも入力内容の確認ページ（図９の確認ページ９００に対応するページ）を設けてもよい。
【００４０】
（３−２．利用情報生成・送信処理）
利用情報生成・送信処理５４は、承認情報データベース５１の承認情報または売上情報データベース５２の売上情報から、それぞれ利用承認情報または利用明細情報を生成し、データベース・サーバ４０に送信する処理である。
本実施形態では、利用情報生成・送信処理を日次バッチ（例えば、当日分を夜間にバッチ処理）で行なうものとしているが、例えば一日に数回の定期バッチとしてもよく、さらには、カードの承認及び利用が同時に行なわれる場合にはリアルタイムで利用情報生成・送信処理を行なってもよい。
利用情報生成・送信処理でデータベース・サーバ４０に送信された利用情報は、承認情報から生成した利用承認情報については利用承認情報データベース４８に、売上情報から生成した利用明細情報については利用明細情報データベース４９に、それぞれ一旦格納され、その後、後述の利用確認メール生成・送信処理にて顧客端末１０に利用確認メールとして送信される。
【００４１】
図１４は、利用情報生成・送信処理５４の処理の流れを示すフローチャートである。なお、ここで示す処理手順は一例である。
まず、承認情報データベース５１から承認情報を、売上情報データベース５２から売上情報を、それぞれ取得する（Ｓ１４１０）。本実施形態では、データ処理済フラグを参照し、承認情報または売上情報のうちデータ処理済フラグが立っていない（すなわち、まだ利用情報生成・送信処理が行なわれていない）情報を取得する。
【００４２】
利用情報生成・送信処理を日次バッチで行なう場合、承認情報については、カードの信用承認に関する処理が完了して承認情報データベース５１に登録された、当日登録分の承認情報が処理の対象となる。一方、売上情報については、カード会社側のカード契約者に対する売上請求に関する処理が完了して売上情報データベース５２に登録された、当日登録分の売上情報が処理の対象となる。なお、利用情報生成・送信処理を定期バッチで行なう場合も、上記の処理は同じである。
取得するデータは、承認情報データベース５１の承認情報および売上情報データベース５２の売上情報のうち、利用確認メールの生成に必要な情報項目のみで足りる。
【００４３】
次に、取得した承認情報または売上情報から、利用情報（利用承認情報または利用明細情報）を生成して（図１４のＳ１４２０）、データベース・サーバ４０に送信する（Ｓ１４３０）。この処理を行なった日を、承認確定日または売上確定日とする。
最後に、送信した利用情報に対応する承認情報データベース５１および売上情報データベース５２のデータ処理済フラグにフラグを立てる（Ｓ１４４０）。データ処理済フラグを立てた承認情報および売上情報は、以降、利用情報生成・送信処理５４の処理対象から除かれる。
データベース・サーバ４０に送信された利用情報は、承認情報から生成した利用承認情報については利用承認情報データベース４８に、売上情報から生成した利用明細情報については利用明細情報データベース４９に、それぞれ別々に格納される。
【００４４】
（３−３．利用確認メール生成・送信処理）
利用確認メール生成・送信処理３４は、本サービスを申し込んでいるＷＥＢ会員のカードについて、カードの利用があったことを知らせるメール（利用確認メール）を生成し、該カードの契約者であるＷＥＢ会員宛に送信する処理である。
利用確認メールは、定期配信時（例えば、午前８時前後）に本サービスに登録しているＷＥＢ会員の顧客端末１０に対して送信する。本実施形態のように利用情報生成・送信処理を日次バッチ（当日分を夜間バッチ）で行なう場合、ＷＥＢ会員は、当日登録分の利用確認メールをその翌日の定期配信時に受け取ることができる。
このように、利用情報生成・送信処理５４と利用確認メール生成・送信処理３４との二段階に分けて処理を行なうことにより、迅速な利用通知を実現しながら、処理の負荷を軽減することができる。
【００４５】
図１５は、利用確認メール生成・送信処理３４の処理の流れを示すフローチャートである。この処理は、上述の定期配信時に起動して行う。なお、ここで示す処理手順は一例である。
最初に、利用承認情報データベース４８または利用明細情報データベース４９から利用確認メール生成・送信処理の対象となる利用情報を選択する（Ｓ１５１０〜Ｓ１５２０）。
この処理では、まず、サービス申請情報データベース４６を参照して、サービス状態フラグおよびオプション機能状態フラグのいずれもが立っている契約番号を取得する（Ｓ１５１０）。続いて、取得した契約番号をキーとして、利用承認情報データベース４８の利用承認情報から通知対象の項目（例えば、利用日・利用金額・加盟店名）を抽出する（Ｓ１５２０）。
同様に、サービス申請情報データベース４６を参照して、サービス状態フラグが立っている契約番号を取得する（Ｓ１５１０）。続いて、取得した契約番号をキーとして、利用明細情報データベース４９の利用明細情報から通知対象の項目（例えば、利用日・利用金額・加盟店名）を抽出する（Ｓ１５２０）。
【００４６】
次に、サービス申請情報データベース４６のメール送信先区分に応じて、ＷＥＢ会員情報データベース４２からパソコンメールアドレス、携帯メールアドレス、あるいはその両方を取得する（Ｓ１５３０）。
その後、利用確認メールを生成して（Ｓ１５４０）、顧客端末１０に送信する（Ｓ１５５０）。このとき、承認情報から生成した利用承認情報と売上情報から生成した利用明細情報のいずれもが送信対象である場合には、利用承認情報と利用明細情報とに区分して、１通のメールを生成する。
【００４７】
図１６は、顧客端末に送信する利用確認メールの例である。
利用確認メール１６００において、「宛先」欄１６１０には、上述で取得（Ｓ１５３０）したパソコンメールアドレス，携帯メールアドレスを入力する。「件名」欄１６２０は、あらかじめ用意した、「カード利用確認メール」である旨が分かりやすい件名とする。
「本文」欄１６３０には、利用承認情報から抽出した項目と，利用明細情報から抽出した項目とを、区別して入力する。ここでは、利用承認情報から抽出した項目は「速報情報」の項目とし、利用明細情報から抽出した項目は「売上情報」の項目としている。
また、利用承認情報から利用確認メールを生成する場合には、企業コードをキーとして、別途管理している同コードと加盟店名を紐付けたファイルを参照し、加盟店名を付加する。企業コードが上述の管理ファイルにない場合には、加盟店名を付加することができない。
また、上述のとおり、決済代行会社のシステムを通じて信用承認処理や売上請求処理が行なわれる場合、クレジットカード会社に対しては加盟店の情報が送信されないので、この場合にも加盟店名を入力することができない。図１６に示す利用確認メールの例では、加盟店名が不明な場合、アスタリスク（「＊」）を入力している。
その他、例えば、このメールがカード利用通知である旨の文章や、カード利用に心当たりがない場合の注意事項を示した文章等を自動的にメールの文面に含めるようにしてもよい。
【００４８】
最後に、利用確認メールを顧客端末１０に送信したら、定期バッチ処理等により、送信済の利用情報を利用承認情報データベース４８および利用明細情報データベース４９から削除する（図１５のＳ１５６０）。
【００４９】
＜他の実施形態の説明＞
上述の実施形態においては、カードの利用を承認した場合に限り、確認メールを送信することとしている。これに対し、カードの利用を承認しなかった（否認した）場合にも、確認メールを送信することとしてもよい。
この場合、ホスト・コンピュータ５０は、カードの利用を承認しなかった（否認した）という情報を、利用承認額０円の承認情報として、承認情報データベース５１に記憶する。これにより、顧客端末１０に対して、カードの利用を承認しなかった（否認した）という情報を、利用金額０円の速報情報として通知することが可能になる。
なお、確認メールの本文中では、利用金額の欄に「承認拒否」，「＊」等別の文字または記号を表示するようにして、カード契約者に対して注意喚起をしてもよい。また、確認メールの本文中には、利用金額欄に０円（または「承認拒否」，「＊」等の文字，記号）と表示されている場合には、カードの利用が承認されなかったことを明示するため、別途注意書きを設けてもよい。
【００５０】
上述の実施形態において、利用情報生成・送信処理５４は、日次バッチにより夜間に行なうこととしている。また、利用確認メール生成・送信処理３４は、１日１回の定期配信時に起動して実行することとしている。
これらの処理を定期的に（例えば、数時間ごと）行なうこととすれば、顧客端末に対し、利用確認メールをより迅速に送信することができる。また、承認情報が承認情報データベースに登録された直後にこれらの処理を行なうこととすれば、顧客端末に対し、利用確認メールをさらに迅速に送信することができる。
【図面の簡単な説明】
【００５１】
【図１】ユーザ，加盟店，カード会社および決済代行会社との間での売上情報に係る利用確認メールの送信を説明する図である。
【図２】承認情報に係る利用確認メールの送信のタイミングを説明するための図である。
【図３】本実施形態のシステム構成の一例を示す図である。
【図４】データベース・サーバの（ａ）ＷＥＢ会員情報データベース，（ｂ）契約情報データベース，（ｃ）サービス申請情報データベース，（ｄ）利用承認情報データベース，（ｅ）利用明細情報データベースの主要な項目を示す図である。
【図５】ホスト・コンピュータの（ａ）承認情報データベース，（ｂ）売上情報データベースの主要な項目を示す図である。
【図６】サービス利用登録・更新処理の流れを示すシーケンス図である。
【図７】サービス登録状態の確認ページの例を示す図である。
【図８】サービス登録状態の変更ページの例を示す図である。
【図９】登録申請内容の確認ページの例を示す図である。
【図１０】登録申請の完了ページの例を示す図である。
【図１１】携帯電話用のサービス登録状態の確認ページの例を示す図である。
【図１２】携帯電話用のサービス登録状態の変更ページの例を示す図である。
【図１３】携帯電話用の登録申請の完了ページの例を示す図である。
【図１４】利用情報生成・送信処理の流れを示すフローチャートである。
【図１５】利用確認メール生成・送信処理の流れを示すフローチャートである。
【図１６】利用確認メールの例を示す図である。
【符号の説明】
【００５２】
１０ 顧客端末
２０ ネットワーク
３０ アプリケーション・サーバ
３２ サービス利用登録・更新処理
３４ 利用確認メール生成・送信処理
４０ データベース・サーバ
４２ ＷＥＢ会員情報データベース
４４ 契約情報データベース
４６ サービス申請情報データベース
４８ 利用承認情報データベース
４９ 利用明細情報データベース
５０ ホスト・コンピュータ
５１ 承認情報データベース
５２ 売上情報データベース
５４ 利用情報生成・送信処理
６０ ＣＡＴ端末
７００ サービス登録状態の確認ページ
８００ サービス登録状態の変更ページ
９００ 登録申請内容の確認ページ
１０００ 登録申請の完了ページ
１１００ 携帯電話用のサービス登録状態の確認ページ
１２００ 携帯電話用のサービス登録状態の変更ページ
１３００ 携帯電話用の登録申請の完了ページ
１６００ 利用確認メール
【特許請求の範囲】
【請求項１】
クレジットカードの使用があったことを、ユーザの端末に電子メールで通知するカード使用通知システムであって、
クレジットカードの承認情報から生成した、前記ユーザのカード番号に対する利用承認情報を記憶する利用承認情報記憶手段と、
前記ユーザのＩＤと、メールアドレスと、前記カード番号と、使用通知サービスの申請情報とを記憶しているユーザ情報記憶手段と、
前記使用通知サービスを申請している前記ユーザの利用承認情報を、前記カード番号で前記利用承認情報記憶手段から読み出して使用確認メールを生成し、前記ユーザの前記メールアドレス宛に送信する使用確認メール生成・送信手段と
を備えていることを特徴とするカード使用通知システム。
【請求項２】
請求項１に記載のカード使用通知システムにおいて、
さらに、クレジットカードの売上情報から生成した、前記ユーザのカード番号に対する利用明細情報を記憶する利用明細情報記憶手段を備え、
前記使用確認メール生成・送信手段は、前記カード番号に対する利用明細情報を前記利用明細情報記憶手段から読み出して、前記利用承認情報と前記利用明細情報とを区別して、使用確認メールを生成する
ことを特徴とするカード使用通知システム。
【請求項３】
請求項１又は２に記載のカード使用通知システムにおいて、
前記利用承認情報は、さらに、クレジットカードの利用否認情報を含む
ことを特徴とするカード使用通知システム。
【請求項４】
請求項１〜３のいずれかに記載のカード使用通知システムにおいて、
前記ユーザ情報記憶手段には、前記ユーザごとに複数のメールアドレスを記憶でき、
前記ユーザ情報記憶手段に記憶している前記使用通知サービスの申請情報には、さらに、前記使用確認メールを送るべき送信先区分情報を含み、
前記使用確認メール生成・送信手段は、前記メール送信先区分情報により前記送信するメールアドレスを決定する
ことを特徴とするカード使用通知システム。
【請求項５】
請求項１〜４のいずれかに記載のカード使用通知システムにおいて、
さらに、前記ユーザを、登録するときはカード番号で、更新するときは前記ＩＤで認証するログイン手段と、
前記ユーザが、カード番号でログイン後、前記端末から前記使用通知サービスの申請情報を登録するための使用通知サービス申請情報登録手段と、
前記使用通知サービス申請情報登録手段で登録後、前記ＩＤを付与するＩＤ付与手段と、
前記ＩＤでログイン後、前記使用通知サービス申請情報を更新する更新手段と
を備えることを特徴とするカード使用通知システム。
【請求項６】
クレジットカードの使用があったことを、ユーザの端末に電子メールで通知するカード使用通知方法であって、
クレジットカードの承認情報から生成した、前記ユーザのカード番号に対する利用承認情報を記憶する利用承認情報記憶手段と、
前記ユーザのＩＤと、メールアドレスと、前記カード番号と、使用通知サービスの申請情報とを記憶しているユーザ情報記憶手段とを有し、
前記使用通知サービスを申請している前記ユーザの利用承認情報を、前記カード番号で前記利用承認情報記憶手段から読み出して使用確認メールを生成し、前記ユーザの前記メールアドレス宛に送信することを特徴とするカード使用通知方法。
【請求項７】
請求項１〜５のいずれかに記載のカード使用通知システムの各手段をコンピュータに機能として実現させるためのプログラム。
【請求項１】
クレジットカードの使用があったことを、ユーザの端末に電子メールで通知するカード使用通知システムであって、
クレジットカードの承認情報から生成した、前記ユーザのカード番号に対する利用承認情報を記憶する利用承認情報記憶手段と、
前記ユーザのＩＤと、メールアドレスと、前記カード番号と、使用通知サービスの申請情報とを記憶しているユーザ情報記憶手段と、
前記使用通知サービスを申請している前記ユーザの利用承認情報を、前記カード番号で前記利用承認情報記憶手段から読み出して使用確認メールを生成し、前記ユーザの前記メールアドレス宛に送信する使用確認メール生成・送信手段と
を備えていることを特徴とするカード使用通知システム。
【請求項２】
請求項１に記載のカード使用通知システムにおいて、
さらに、クレジットカードの売上情報から生成した、前記ユーザのカード番号に対する利用明細情報を記憶する利用明細情報記憶手段を備え、
前記使用確認メール生成・送信手段は、前記カード番号に対する利用明細情報を前記利用明細情報記憶手段から読み出して、前記利用承認情報と前記利用明細情報とを区別して、使用確認メールを生成する
ことを特徴とするカード使用通知システム。
【請求項３】
請求項１又は２に記載のカード使用通知システムにおいて、
前記利用承認情報は、さらに、クレジットカードの利用否認情報を含む
ことを特徴とするカード使用通知システム。
【請求項４】
請求項１〜３のいずれかに記載のカード使用通知システムにおいて、
前記ユーザ情報記憶手段には、前記ユーザごとに複数のメールアドレスを記憶でき、
前記ユーザ情報記憶手段に記憶している前記使用通知サービスの申請情報には、さらに、前記使用確認メールを送るべき送信先区分情報を含み、
前記使用確認メール生成・送信手段は、前記メール送信先区分情報により前記送信するメールアドレスを決定する
ことを特徴とするカード使用通知システム。
【請求項５】
請求項１〜４のいずれかに記載のカード使用通知システムにおいて、
さらに、前記ユーザを、登録するときはカード番号で、更新するときは前記ＩＤで認証するログイン手段と、
前記ユーザが、カード番号でログイン後、前記端末から前記使用通知サービスの申請情報を登録するための使用通知サービス申請情報登録手段と、
前記使用通知サービス申請情報登録手段で登録後、前記ＩＤを付与するＩＤ付与手段と、
前記ＩＤでログイン後、前記使用通知サービス申請情報を更新する更新手段と
を備えることを特徴とするカード使用通知システム。
【請求項６】
クレジットカードの使用があったことを、ユーザの端末に電子メールで通知するカード使用通知方法であって、
クレジットカードの承認情報から生成した、前記ユーザのカード番号に対する利用承認情報を記憶する利用承認情報記憶手段と、
前記ユーザのＩＤと、メールアドレスと、前記カード番号と、使用通知サービスの申請情報とを記憶しているユーザ情報記憶手段とを有し、
前記使用通知サービスを申請している前記ユーザの利用承認情報を、前記カード番号で前記利用承認情報記憶手段から読み出して使用確認メールを生成し、前記ユーザの前記メールアドレス宛に送信することを特徴とするカード使用通知方法。
【請求項７】
請求項１〜５のいずれかに記載のカード使用通知システムの各手段をコンピュータに機能として実現させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２００８−２７６４９９（Ｐ２００８−２７６４９９Ａ）
【公開日】平成２０年１１月１３日（２００８．１１．１３）
【国際特許分類】
【出願番号】特願２００７−１１９０８５（Ｐ２００７−１１９０８５）
【出願日】平成１９年４月２７日（２００７．４．２７）
【出願人】（３９９０３７４０５）楽天株式会社 (416)
【Ｆターム（参考）】
【公開日】平成２０年１１月１３日（２００８．１１．１３）
【国際特許分類】
【出願日】平成１９年４月２７日（２００７．４．２７）
【出願人】（３９９０３７４０５）楽天株式会社 (416)
【Ｆターム（参考）】
[ Back to top ]