WO2016098774A1

WO2016098774A1 - 店舗端末装置、会員管理サーバー、決済代行サーバー、および決済方法

Info

Publication number: WO2016098774A1
Application number: PCT/JP2015/085089
Authority: WO
Inventors: 幸一佐々木; 昌宏川口; 西田　真; 英道沢野
Original assignee: 大日本印刷株式会社
Priority date: 2014-12-16
Filing date: 2015-12-15
Publication date: 2016-06-23
Also published as: JP2018041118A

Abstract

　顧客が所望する多様な支払方法に従った店舗端末での清算を、柔軟に、店員に負荷を強いることなく正確に行える店舗端末装置を提供すること、その際の決済方法、決済装置を提供する。具体的には、清算すべき金額を確定する処理手段と、会員利用者が提示したカードの番号が入力されると、この番号に基づいて前記会員管理サーバーに会員照会を行い、会員照会の結果、特定された会員利用者が登録した前記決済ポリシーデータに係るデータを会員管理サーバーから受領して、会員利用者に１つ以上の「支払い方」を選択可能な態様で前記表示部に表示する会員照会処理手段と、会員利用者が選択した「支払い方」に従った決済処理を決済代行サーバーに依頼する決済依頼処理手段と、を少なくとも備えた店舗端末装置により課題を解決する。

Description

店舗端末装置、会員管理サーバー、決済代行サーバー、および決済方法

　本発明は、会員カードやクレジットカードを利用した決済およびポイント処理の改善されたサービスに関する。

　来店した顧客に会員カードを発行して購入した金額に応じて割引ポイントを付与するサービス（ポイントサービス）は広く行われている。ポイントサービスは店舗を運営する業者ごとに行われるのが基本であるが、業者をまたいで運営されるポイントサービスも存在する。購入した金額に応じて付与するポイントとは別に来店に応じて付与する来店ポイントを付与するポイントサービスもある。生鮮食品スーパーやドラッグストアでは、ポイント５倍デー等と称して、会員利用者の誘因を図ることがある。また、クレジットカード会社は、クレジット引き落としのタイミング等でポイントを付与するポイントサービスを運営している。

　このように、ポイントサービスは生活者の消費生活に広く浸透している。そして生活者は、それぞれの消費生活行動に応じて何枚もの会員カードやクレジットカードを所有していることが多い。しかし、店舗におけるポイント付与は、商品購入時(サービス料金精算時)に当該店舗運営業者が発行する会員カードを提示することを条件として付与されるので、ポイント獲得の機会を逸することがないようにするために生活者は何枚もの会員カードを常に携行していなければならないという問題が生じる。このような問題を解決するために、生活者が保有する複数のカード（会員カード、クレジットカード）を連携させて、１つのカードで代表させるというサービス、システムの提案がなされている。

　特許文献１では、複数のカードのカード番号リストに顧客に一意的に割り当てた顧客ＩＤを対応付けて１件のレコードとしてカード管理テーブルに記録しておき、顧客が店舗において清算する際にカード管理テーブルに記録したいずれかのカードを提示すればポイントサービスを受けられるポイント管理システムが開示されている。但し、このポイント管理システムの場合、運営されるポイントサービスは各登録カード共通のポイントサービスとすることが前提である。

　特許文献２にも、特許文献１とほぼ同様なポイント管理システムが開示されている。特許文献２に開示されたポイント管理システムの場合は、店舗で清算した時に、付与ポイントと識別情報と店舗識別情報とをポイント管理サーバーに送信すると、ポイント管理サーバーでは、店舗ごとに識別情報で識別される会員の累計獲得ポイントを集計管理する仕組みが示されている。

　特許文献３には、Ａ社店舗にてＡ社ポイントカードを提示した顧客が、Ｂ社クレジットカードを提示することなくクレジット決済を行うことが可能な個人識別情報管理装置および個人識別情報管理方法が開示されている。このような機能を実現させるために個人識別情報管理装置は、会員利用者のＡ社の会員番号とＢ社のクレジットカード番号を関係づけたテーブルを関連情報記録部に保持し、Ａ社店舗端末でＡ社会員カードを提示した顧客がＡ社店舗端末上に設けられたボタンを押すことにより、Ａ社店舗端末から個人情報管理装置(管理サーバー)へ「Ｂ社クレジットカード情報要求」が送信され、管理サーバーは前記関連情報記録部をＡ社会員カード番号をキーにサーチしてＢ社クレジットカード番号を取得し、これをＡ社店舗端末に送信することが記載されている。

　特許文献４には、カード会社にて稼働するポイント充当方法およびそのシステムが開示されている。これはクレジットカード会員が前もって、ポイント充当に使用するポイントプログラムの名前と、そのポイントプログラムにおける会員の識別情報を含むポイント充当サービス申込を行っておくと、毎月のクレジット利用額引き落とし時に、当該クレジットカード会員のポイント充当サービスの登録されたポイントサービスの当該会員のポイント残高情報に基づいて移行ポイントを決定し、この移行ポイント分を引き落とし代金の一部に充当できるというものである。

特開２００８－２５７５４６号公報特開２００８－１９８０３０号公報特開２００３－９９６５６号公報特開２０１４－１７８９８６号公報

　特許文献１のポイント管理システムは各登録会員カードに共通の１とおりのポイントサービスの管理を対象とするので、どんな会員カードでも会員カードの関連付けによる恩恵を受けられるというものではない。特許文献２のポイント管理システムでは、登録したカードのいずれか１枚を店舗で提示すればその店のポイントサービスのポイントが累積されるので、多くの会員カードを携行しなくてよいという効果を得ることができる。しかし、クレジットカードとの連携は考慮されていないので、クレジット支払いを希望する場合には、会員カードとして提示するカードの他にクレジットカードを提示して店員にクレジット払いを希望することを伝える必要がある。特許文献３の個人識別情報管理方法・装置では、さらに会員カードとクレジットカードの関係付けによる支払方法の選択が可能であるため、クレジットカード番号をその顧客に関係づけて登録しておくことにより、会員カードを提示すれば、クレジットカード使用の意思を伝えるだけでクレジットカードを提示せずともクレジット払いを利用することができる。しかしながら現金、クレジット払い、ポイント充当以外のことは特段考慮されていない。

　支払時の選択肢としては、現金、クレジット、ポイント充当の他に各種電子マネーを使用する場合もある。支払時の選択肢が広がることは顧客にとっては便利ではあるが、いちいち店員に支払い方を伝える必要が生じる。一方、レジで対応する店員は、顧客の意向に従って誤りなく清算しなければならず、店舗端末を扱う店員の負荷も増している。

　本発明は、顧客が保有する複数の会員カードとクレジットカード等のカード類の情報を顧客識別情報と関係づけて記録した上で、顧客が所望する多様な支払方法に従った店舗端末での清算を、柔軟に、店員に負荷を強いることなく正確に行える店舗端末装置を提供すること、その際の決済方法、決済装置を提供することを課題とする。

　課題を解決する本願第１の発明は、会員利用者所有のカードに関する情報を当該会員利用者の識別情報と関係づけて登録した会員カードデータと、登録したカードを用いた「支払い方」を会員ごとに１つ以上登録した決済ポリシーデータとを含む会員情報を保持する会員管理サーバーおよび、ポイントサービス事業者も含む各種決済事業者装置に決済電文を送信する決済代行サーバーと連携して動作する店舗端末装置であって、表示部およびネットワークを通じて外部と通信する送受信部を備え、清算すべき金額を確定する処理手段と、会員利用者が提示したカードの番号が入力されると、この番号に基づいて前記会員管理サーバーに会員照会を行い、会員照会の結果、特定された会員利用者が登録した前記決済ポリシーデータに係るデータを会員管理サーバーから受領して、会員利用者に１つ以上の「支払い方」を選択可能な態様で前記表示部に表示する会員照会処理手段と、会員利用者が選択した「支払い方」に従った決済処理を決済代行サーバーに依頼する決済依頼処理手段と、を少なくとも備えた店舗端末装置である。

　ここで、当該店舗を運営する事業者が提供する会員サービス等に登録している会員サービスの利用者という意味で「会員利用者」の語を用いるが、会員顧客と言い換えてもよい。

　また、各種決済事業者とは、クレジットカード発行事業者以外に、ハウスプリペイド事業者、電子マネー事業者、キャリア決済事業者などを想定する。さらに、本願発明の趣旨から、単独の事業者又は異なる複数の事業者を股がるポイントサービスを行うポイントサービス事業者（特に複数の事業者を横断してサービスするものを共通ポイント事業者、そうでないものをハウスポイント事業者と記し、両者を総称してポイント事業者と記載する）も便宜的に決済事業者として総称することにする。決済事業者装置とは、それらの決済事業者に接続するためのアクセスポイントとして動作する装置または決済電文を受付けて処理するサーバー装置自体を意味する。

　さらに、決済電文とは、加盟店とクレジットカード発行事業者間でやり取りされる「与信」「売上」「与信取消」「売上取消」等を通常意味するが、本発明では、これら以外に、決済代行サーバーがハウスポイント事業者、ハウスプリペイド事業者、ポイント事業者、電子マネー事業者、キャリア決済事業者などとの間で、支払額の清算のためおよび／またはポイント加算減算のためにやり取りさせる電文も含めて決済電文という用語を用いる。

　このような構成の店舗端末装置であれば、予め会員利用者が登録した「支払い方」を店舗端末装置に呼び出すことができ、それを会員利用者が選択できるので、店舗のレジ係は、会員利用者に「ポイントカードはありますか？」「(クレジット払いの場合)１回払いでいいですか？」など会員利用者の望む「支払い方」の詳細をいちいち確認する必要はない。また、会員利用者は、登録したカードのうちの１つを提示すれば、会員利用者を認証して、会員利用者が登録した「支払い方」を全て呼び出せるので、例えば、クレジットカードを提示することにより、その事業者が発行した会員カードを提示した扱いを受けることができる（このように事前登録した２つのカードを連携させる機能を以後「カードスイッチ機能」として記載することがある）。このため、例えば、クレジット払いをしてその店のポイントを獲得することをクレジットカードだけ提示することだけで済ますことができるので、ポイントカードを携行しなくてもポイントが貯められるというメリットを享受できる。そして会員利用者は「支払い方」を柔軟に設定できるにもかかわらず、店舗のレジ係は「支払い方」の詳細に関与せずに済むため、レジ係の負荷が従前より増えるということもない。

　本願第１の発明において、前記「支払い方」は、１）ポイントを使うか使わずに貯めるか、２）支払方法、３）この支払結果を反映させるポイントサービスを特定する情報を明らかにしたデータであって、１件ごとに識別情報とともに「支払い方」の表示名が付けられているデータであることが好ましい。２）の支払い方法とは、支払額（ポイントを使う場合はポイントを充当した後の残金額）について、現金かクレジットカードか、電子マネー他で支払うことの指定である。

　本願第１の発明において、前記会員照会の結果、店舗端末装置に返される前記決済ポリシーデータに係るデータは、当該会員利用者が登録した全ての「支払い方」の識別情報と表示名であってもよい。店舗端末装置では「支払い方」の選択ができればよいのであるから、選択に必要な最小限データだけを店舗端末に送信するという構成でもよい。

　本願第１の発明において、前記会員管理サーバーは、会員利用者ごとに、本人認証する際に照合する本人認証データをも保持するものであって、前記決済依頼処理手段は、前記「支払い方」に従った決済処理を決済代行サーバーに依頼する直前に、会員利用者から本人認証データの入力を受付け、会員利用者が与えたこの本人認証データと前記会員管理サーバーが保持している本人認証データとの照合を前記会員管理サーバーに要求するよう構成されることが好適である。というのは、会員照会の段階では、カードを提示した者が会員利用者本人でなくても、提示されたカードが登録されたカードでありさえすれば、「支払い方」の表示ができてしまう。そこで、本来であれば、カードを提示した者が本人であるかどうかを確認する必要がある。このため、本人しか知りえない暗証番号等の入力を受けるような構成が望ましい。

　本願第１の発明において、店舗端末装置は、バーコード読み取り部を備え、
前記清算すべき金額を確定する手段は、商品に付されたコードをバーコード読み取りしたコードをキーにして商品ごとの売価を読み出して合計金額を算出するＰＯＳ処理手段であってもよい。また、さらに、前記決済処理の応答結果を受けてレシートを印字する手段を備えてもよい。これらは店舗端末装置にＰＯＳレジの機能を兼用させるための構成要件である。

　あるいは、本願第１の発明に係る店舗端末装置において、前記清算すべき金額を確定する手段は、外部装置より合計金額を取得する接続部であって、前記決済代行サーバーから受領した前記決済処理の応答結果を前記接続部を介して前記外部装置に伝える構成としたものであってもよい。このような構成によれば、既存のＰＯＳレジ装置はそのままで、適当な接続インターフェースにより本願発明に係る店舗端末装置を既存のＰＯＳレジ装置に合体させて運用する構成とできる。

　本願第１の発明において、前記会員管理サーバーは、会員利用者所有のカードと対応づけてクーポン企画の情報を保持し、前記会員照会処理手段は、前記「支払い方」で用いるカードに対応した前記クーポン企画の情報を前記会員管理サーバーから受領して、前記「支払い方」とともに前記表示部に表示する構成とすることが望ましい。このような構成によれば、消費者は支払方法を選択する際にクーポン情報の有無などを参考とすることができる。また店舗側は効果的にクーポンを発行することができる。

　ここでクーポン企画とは、会員利用者に何らかの特典を与える企画のことであり、紙に印刷された割引券或いは引換券(クーポン券)を提供することや、例えばポイントを通常より割増して与えるなども含む。

　課題を解決する本願第２の発明は、店舗の利用者が提示したカードに基づいて会員照会を行う店舗端末装置と連携して動作する会員管理サーバーであって、会員利用者所有のカードに関する情報を当該会員利用者の識別情報と関係づけて登録した会員カードデータと、登録したカードを用いた「支払い方」を会員ごとに１つ以上登録した決済ポリシーデータとを含む会員情報を保持する会員データ記憶部と、ネットワークを通じて店舗端末装置からの会員照会リクエストを受信し結果を返信する送受信部と、店舗端末装置からの会員照会リクエストに付されたカード番号をキーにして前記会員カードデータを検索し、一致したカード番号を有する記録がある場合は、そのカード情報記録を登録した会員が登録した決済ポリシーデータに係るデータを前記会員データ記憶部より抽出して、店舗端末装置に返信する会員照会処理手段と、を備えた会員管理サーバーである。

　このような構成の会員管理サーバーを備えることにより、会員利用者は、所有するカード情報を登録し、登録したカードを用いた支払方法を決済ポリシーデータとして登録でき、これを店舗端末から呼び出すことができるので、店舗のレジ係は、会員利用者に「ポイントカードはありますか？」「(クレジット払いの場合)１回払いでいいですか？」など会員の望む「支払い方」の詳細をいちいち確認する必要はない。また、会員利用者は、登録したカードのうちの１つを提示すれば、会員利用者を認証して、会員利用者が登録した「支払い方」を全て呼び出せるので、例えば、クレジットカードを提示することにより、その事業者が発行した会員カードを提示した扱いを受けることができる。このため、ポイントカードを携行しなくてもポイントが貯められるというメリットを享受できる。そして会員利用者は「支払い方」を柔軟に設定できるにもかかわらず、店舗のレジ係は「支払い方」の詳細に関与せずに済むため、レジ係の負荷が従前より増えるということもない。

　前記会員カードデータの１件のデータは、会員を特定する識別情報、カードの種別を特定する情報、カード番号、有効期限情報を含むことが好適である。また、前記カードの種別を特定する情報は、現金払い、電子マネー、クレジットカード、ポイントカードを区別する情報であることが好適である。これらは、「支払い方」を柔軟に多様に定義することにつながる。

　前記「支払い方」の１件のデータは、その「支払い方」を実行する場合に必要となる決済事業者への決済電文の内容と実行順をもれなく列挙して、各決済電文ごとに、ポイントを利用するかしないかを区別する情報、使用するカードを特定する情報を含むものとすることが好適である。このようなデータ構造をとることにより、定義した「支払い方」を実際の決済電文に置き換えることが容易になる。

　また、本願第２の発明に係る会員管理サーバーは、会員利用者が連携して使用したいカードの情報を登録するカード情報登録手段と、会員利用者の決済ポリシーを幾つかの登録したカードを用いた支払い方のセットとして定義して登録する決済ポリシー登録手段とを備えて、会員利用者ごとの会員カードデータと決済ポリシーデータの登録をネットワークを介して受付けるように構成することが好適である。

　また、本願第２の発明に係る会員管理サーバーは、会員利用者所有のカードと対応づけてクーポン企画の情報を保持するクーポンデータ記憶部、を更に備え、前記会員照会処理手段は、カード番号をキーとして１以上のクーポン企画の情報を検索し、店舗端末装置に返信するように構成することが望ましい。このとき、会員利用者のクーポン企画へのエントリーを受け付けるクーポンエントリー手段、を更に備え、前記クーポンデータ記憶部が保持する前記クーポン企画の情報は、前記クーポンエントリー手段により会員利用者からエントリーの受け付けがあったクーポン企画の情報であることが望ましい。また、前記会員照会処理手段は、全ての「支払い方」について、検索された各クーポン企画のクーポンが出力可能か否か、或いはクーポン企画に基づいた特典付与が可能か否かを判定し、クーポンが出力可能、または特典付与が可能と判定された支払い方が存在する場合は、当該支払い方と当該支払い方でクーポンが出力可能なクーポン企画の情報を、店舗端末装置に返信することが望ましい。

　課題を解決する本願第３の発明は、会員利用者が予め定義した１つ以上の「支払い方」を表示して会員利用者の選択を受付ける店舗端末装置と連携して動作する決済代行サーバーであって、前記「支払い方」は、１）ポイントを使うか使わずに貯めるか、２）支払方法、３）この支払結果を反映させるポイントサービスを特定する情報を明らかにして、１件ごとに識別情報とともに「支払い方」の表示名が付けられているデータであって、会員利用者に関係づけて当該会員利用者所有のカードに関する情報を登録した会員カードデータと、登録したカードを用いた「支払い方」を会員ごとに１つ以上登録した決済ポリシーデータとを含む会員情報を保持する会員データ記憶部と、ネットワークを通じて店舗端末装置からの決済手続きリクエストおよびそれへの応答の受発信を行う店舗電文送受信部と、各種決済事業者が設置する決済事業者装置への決済電文およびその応答電文の受発信を行う決済電文送受信部と、前記店舗電文送受信部を介して受付けた前記決済手続きリクエストに含まれる「支払い方」を特定する情報に基づいて前記決済ポリシーデータを検索して、指定した「支払い方」に従って清算処理するために必要となる前記決済事業者装置への決済電文の内容と実行順情報を抽出して、これらの情報に従って必要な決済電文を１つずつ前記決済電文送受信部を介して所定の順序で前記決済事業者装置に発信する電文振分手段と、指定した「支払い方」の実行結果を前記店舗電文送受信部を介して店舗端末装置に返信する決済結果応答手段と、を備えた構成とした決済代行サーバーである。

　このような構成の決済代行サーバーは、店舗端末装置から会員利用者が選択した「支払い方」の指定を受取るだけで、その「支払い方」を実行するための決済電文を必要なだけ正しい順序で作成して処理を実行するので、会員利用者はカードを１枚提示するだけで多様な支払い方を選択でき、レジ係は何枚ものカードを読み取って煩雑な処理を行う必要がないという効果を奏する。

　本願第３の発明において、会員利用者所有のカードと対応づけてクーポン企画の情報を保持するクーポンデータ記憶部と、前記「支払い方」で前記クーポン企画のクーポンが出力可能か否かを判定するクーポン出力判定手段と、を更に備え、前記クーポン出力判定手段によりクーポン出力可能と判定された前記クーポン企画の情報を、前記店舗電文送受信部を介して店舗端末装置に返信することが望ましい。

　本願第３の発明において、会員利用者所有のカードと対応づけてクーポン企画の情報を保持するクーポンデータ記憶部と、前記「支払い方」で前記クーポン企画に応じた特典の付与が可能か否かを判定するクーポン出力判定手段と、を更に備え、前記クーポン出力判定手段によりクーポン企画に応じた特典の付与が可能と判定された場合は前記決済事業者装置へ前記決済電文送受信部を介して特典付与に応じた決済電文を送信するものであることが好ましい。

　なお、第２の発明に係る会員管理サーバーと第３の発明に係る決済代行サーバーはそれぞれ別個のサーバー装置上に実現してもよいが、機能を統合して１台のサーバー装置上に決済代行サーバーとして実現してもよい。

　課題を解決する本願第４の発明は、事業者の店舗に設置される店舗端末装置、事業者の会員利用者を管理する会員管理サーバー、決済事業者と決済電文をやり取りする決済代行サーバーがネットワークを通じて接続される決済システムにおける決済方法であって、会員利用者が、前記会員管理サーバーにアクセスして会員利用者が所有する１つ以上のカードの情報を入力するステップ、前記会員管理サーバーが、前記入力されたカード情報を含む会員利用者に関する情報を、前記会員利用者を識別する情報と関係づけて前記会員管理サーバーの会員データ記憶部に登録するステップ、会員利用者が、前記会員管理サーバーにアクセスして前記事業者の店舗を利用する際の、前記登録したカードを用いた「支払い方」を１つ以上定義して、会員を識別する情報と関係づけた決済ポリシーとして前記会員管理サーバーの会員データ記憶部に登録するステップ、会員利用者が、前記事業者の店舗端末装置で購入商品又はサービスに対する支払いをする際に、登録したカードの一つを提示するステップ、前記店舗端末装置が、提示されたカードのカード番号を読み出し、会員照会処理を行うことにより、前記会員管理サーバーから、当該会員利用者が登録した決済ポリシーに係る情報を呼び出すステップ、前記店舗端末装置が、呼び出した決済ポリシーに係る「支払い方」を会員利用者が選択できるよう店舗端末装置の表示部に表示して会員利用者の選択を促すステップ、前記店舗端末装置が、会員利用者が選択した「支払い方」及び支払額を前記決済代行サーバーへ送信して決済依頼を行うステップ、前記決済代行サーバーが、前記会員利用者により選択された「支払い方」に従って、購入商品又はサービスの代金を決済処理するための必要な決済電文を生成し送信するステップ、前記店舗端末装置が、前記決済電文に係る処理の応答結果を前記決済代行サーバーを通じて受信して、正常応答であればその結果に基づいてレシートを発行し、異常終了であれば、顧客に他の支払い方法の選択を促すステップ、を含む手順で実行される決済方法である。

　本願発明に係る店舗端末装置、会員管理サーバー、決済代行サーバー、決済方法によれば、会員利用者が保有する複数の会員カードとクレジットカード等のカード類の情報を顧客識別情報と関係づけて記録した上で、会員利用者が所望する多様な支払方法に従った店舗での清算を、柔軟に、店員に負荷を強いることなく正確に行うことができる。この時、会員利用者は登録したカードを１枚提示するだけでよいので、多くのカードを携行し、また複数のカードをレジに呈示するといった煩雑さから解放されるという顕著な効果を奏する。

１つの実施形態としての決済システム１の全体構成を説明する図である。店舗端末１００の構成を説明するブロック図である。決済代行サーバー２００の構成を説明するブロック図である。会員利用者から見た、決済システム１を利用する場合の処理の流れを概略的に説明するフロー図である。図４で説明した一連の処理の流れを、店舗端末１００、決済代行サーバー２００の処理内容を中心に説明する概略図である。決済代行サーバー２００の電文振分処理機能を説明する表である。図４のＳ３０以降の、会員利用者、レジ係、店舗端末１００、決済代行サーバー２００の間の情報の詳細なやり取りを上から下へ時系列的に表したフロー図である。決済代行サーバー２００からクライアント端末４００に提供されるカード登録画面５００である。決済代行サーバー２００からクライアント端末４００に提供されるマイ決済登録画面５２０である。会員利用者の決済ポリシー登録情報を確認し、新たなカードの登録、暗証番号の更新、新たなマイ決済の登録を行うための入り口となる決済ポリシー登録画面５４０である。カード登録に関係するデータの管理構造を説明する概念図である。会員利用者が定義する１件の支払い方である「マイ決済」の設定に関係するデータベースの構造を説明する図である。決済代行サーバー２００がＥＣ店舗７００と連携する構成とした決済システム２の全体概要図である。決済システム１の決済代行サーバー２００を会員管理サーバー２００Ａに分離して構成した場合の一例を説明する図である。決済システム１の決済代行サーバー２００を決済代行サーバー２００Ｂに分離して構成した場合の一例を説明する図である。クーポン企画情報を設定登録するクーポン企画登録画面４５０の例を示す図である。クーポン企画情報を保持するデータベースの構造を説明する図である。決済代行サーバー２００からクライアント端末４００に提供されるクーポンエントリー画面５３０である。決済代行サーバー２００が実行するクーポン出力判定処理の流れを示すフローチャートである。支払い方を選択する会員カード決済画面５５０の例を示す図である。

　これから、本願発明の好適な実施形態を図面を使いながら説明してゆく。図１は、本願第１の発明の１つの実施形態としての決済システム１の全体構成を説明する図である。この決済システム１は店舗端末１００、決済代行サーバー２００、決済事業者装置（カード会社、電子マネー事業者等の各種決済機関、およびポイント事業者等の決済事業者に接続するためのアクセスポイントとして動作する装置または決済電文を受付けて処理するサーバー装置自体）がネットワークを介して接続されて構成されている。図１では店舗端末１００（店舗端末装置の一例）は1つだけ描かれているが、実際には顧客管理を行う事業者が保有する各店舗数に設置される複数の店舗端末と決済代行サーバー２００がネットワーク９を介して接続される。ネットワーク９は典型的にはインターネット上に暗号化等のセキュアな通信を行う機能を付加したＶＰＮ（Vertual Private Network）として構築することができるが、専用線網により構築してもよい。３００Ａから３００Ｆに示すのは、各種の決済事業者が設置する決済事業者装置である。図１では、カード会社Ａ（３００Ａ）、キャリア決済事業者Ｂ（３００Ｂ）、電子マネー事業者Ｃ（３００Ｃ）、ハウスプリペイド事業者Ｄ（３００Ｄ）、ハウスポイント事業者Ｅ（３００Ｅ）、共通ポイント事業者Ｆ（３００Ｆ）への決済電文を処理する装置（またはアクセスポイント）が決済事業者装置の例として描かれているが、これらは例示的に描いたものであり、実際のシステムはこのような構成に限定されるわけではない。４００は、会員利用者が後述するカード情報、決済ポリシー情報を登録する際使用するクライアント装置である。

　決済代行サーバー２００と決済事業者３００Ａ～３００Ｆの間のネットワーク７Ａ～７Ｆは、それぞれの事業者ごとの専用線であってもよいし、インターネット上に構築したＶＰＮであってもよい。店舗端末１００と決済代行サーバー２００、あるいはまた、決済代行サーバー２００と決済事業者３００Ａ～３００Ｆとの間で電子的なメッセージ(電文)がやり取りされるが、以下の記載では、店舗端末１００と決済代行サーバー２００との間でやり取りされる電文を「店舗電文」と総称し、決済代行サーバー２００と決済事業者３００Ａ～３００Ｆとの間でやり取りされる電文を「決済電文」と総称して区別することにする。

　図２は、店舗端末１００の構成を説明するブロック図である。店舗端末１００はいわゆるＰＯＳレジ端末に本発明特有の機能を実現するコンピュータプログラムを組み込んで実現することができる。すなわち、店舗端末１００は、制御部１０２、表示部１０３、入力部１０４、バーコードリーダー１０５、カードリーダー１０６、レシートプリンタ１０７、店舗電文送受信部１０８、記憶部１１０がバス１０１を介して電気的論理的に接続されて構成される。制御部１０２はＣＰＵ、稼働時のワークメモリ領域であるＲＡＭ、起動時のプログラムコード等を記憶したＲＯＭが集積された制御ボードである。表示部１０３は店員の操作画面を表示する表示部ａ（１０３ａ）と顧客(会員利用者)向けの表示および操作画面を提供する表示部ｂ（１０３ｂ）を備える。入力部１０４は、キーボード、テンキーボード、およびマウス等である。尚、表示部１０３（１０３ａ、１０３ｂ）をタッチパネルとしてもよく、その場合は入力部１０４の機能の一部は表示部１０３と一体化された構成をとる。記憶部１１０は、不揮発メモリ領域であり、図示していない制御プログラム（ＯＳ）のコードを記憶するとともに、バーコードリーダー１０５が読み取った商品コードをキーとしてＰＬＵ(Price Lookup)を行い販売時点管理を行うＰＯＳ処理機能を実現するプログラムコード１１１、後述する会員照会処理を実現するプログラムコード１１２、後述する決済依頼処理を実現するプログラムコード１１３、後述する店舗電文処理を実現するプログラムコード１１４が記録されている。これらのプログラムコードが制御部１０２のＣＰＵに読み込まれて解釈実行されることにより、ＰＯＳ処理手段（清算すべき金額を確定する処理手段の一例）、会員照会処理手段、決済依頼処理手段、店舗電文処理手段として機能することになる。店舗電文送受信部１０８は、店舗電文処理において店舗電文処理手段の制御の元で決済代行サーバー２００に必要な店舗電文をネットワーク９に送出し、決済代行サーバー２００からの応答電文を受信して、内容を店舗電文処理手段に伝える。ネットワーク９はゲートウェイを通してインターネットに接続される。

　図３は、決済代行サーバー２００（会員管理サーバーの機能を兼ね備えた決済代行サーバーの一例）の構成を説明するブロック図である。決済代行サーバー２００は、サーバーコンピュータに本発明特有の機能を実現するコンピュータプログラムを組み込んで実現することができる。すなわち、決済代行サーバー２００は、制御部２０２、記憶部２１０、大容量記憶装置２２０、店舗電文送受信部２３０、決済電文送受信部２４０がバス２０１を介して接続されて構成される。制御部２０２はＣＰＵ、稼働時のワークメモリ領域であるＲＡＭ、起動時のプログラムコード等を記憶したＲＯＭが集積された制御ボードである。記憶部２１０は、不揮発メモリ領域であり、図示していない制御プログラム（ＯＳ）のコードを記憶するとともに、後述するカード情報登録処理を実現するプログラムコード２１１、後述する決済ポリシー登録処理を実現するプログラムコード２１２、後述する会員照会処理を実現するプログラムコード２１３、後述する電文振分処理を実現するプログラムコード２１４、後述する会員認証処理を実現するプログラムコード２１５、後述する決済結果応答処理を実現するプログラムコード２１６、後述するクーポンエントリー処理を実現するプログラムコード２１７が記録されている。これらのプログラムコードが制御部２０２のＣＰＵに読み込まれて解釈実行されることにより、カード情報登録手段、決済ポリシー登録手段、会員照会手段、電文振分処理手段、会員認証手段、決済結果応答手段、クーポンエントリー手段として機能することになる。

　大容量記憶装置２２０は会員情報データベース２２１（会員データ記憶部の一例）を記憶保持する。

　店舗電文送受信部２３０は、店舗端末１００から送られてくる店舗電文を受信し、店舗端末１００に送信する電文(応答電文)をネットワーク９に送出する。決済電文送受信部２４０は、決済事業者装置３００への決済電文をネットワーク７に送出し、決済事業者装置３００からの応答電文を受ける。電文振分処理手段は店舗電文送受信部２３０を介して受け付けた１件の店舗電文の処理に必要な幾つかの決済電文を作成して決済電文送受信部２４０を通じて決済事業者装置３００に決済電文を送信する。

　図４は、会員利用者から見た、決済システム１を利用する場合の処理の流れを概略的に説明するフロー図である。このフロー図によれば、会員利用者はまず事業者が運営する会員サイトにインターネットを通じてアクセスするなどして会員利用者本人が所有するカード（カードスイッチ機能によって連携させたいカード）を登録する（Ｓ１０）。登録するカードとしては、典型的には当該事業者発行の会員カード(ポイントカード)とよく使用するクレジットカードである。この他に、他の事業者の会員カードを登録してもよい。

　続いて、会員利用者は、決済ポリシーを登録する（Ｓ２０）。決済ポリシーは店舗で購入品の代金を支払うときの「支払い方」（後述するユーザ画面インターフェース(以下ＧＵＩと記す)においては「マイ決済」と称する）を何通りか定義したものである。通常、ポイントを貯める時の支払い方とポイントを利用する時の支払い方をそれぞれ最低１通り登録する必要がある。支払い方のバリエーションをさらに何通りか登録しておいてもよい。会員利用者の保有カードと決済ポリシーの登録を受けた事業者のサイトは、これらの情報を会員利用者を一意に識別する会員コードに関係づけて１件の会員レコードとして会員情報データベース２２１に登録する。

　続いて、会員利用者は、会員サイトにおいてクーポンエントリーを行う（Ｓ３０）。クーポンエントリーとは、会員サイトの管理者によって予め登録されたクーポン企画（商品購入時に支払った金額などに応じてクーポン(割引券、引換券)を提供したり、特別なポイント付与などの特典を与える企画）に参加登録することをいう。会員利用者はクーポン企画にクーポンエントリーすることによって、クーポンの提供を受ける機会を得ることとなる。会員利用者がクーポンエントリーする手段と会員サイトの管理者がクーポン企画を登録する手段、については後述する。
―ここまでが前準備である。

　会員利用者は、店舗を利用して購入商品（飲食サービス等）の代金を支払う際に、登録した保有カードの何れか一つを提示する（Ｓ４０）。このカードは当該事業者発行の会員カードであってもよいし、登録された他の事業者の会員カード、或いはクレジットカードであってもよい。

　店舗端末は、提示されたカードをカードリーダー１０６で読みとったカード番号を決済代行サーバー２００に送付して、会員の照会を行う（Ｓ５０）。決済代行サーバー２００は会員情報データベース２２１に提示されたカードのカード番号が登録されていれば、対応する会員利用者が登録している決済ポリシーを店舗端末１００に返信する。提示されたカードのカード番号と一致する番号が会員情報データベース２２１になければ認証失敗を店舗端末１００に返信する。またこのとき、決済代行サーバー２００は、提示されたカード番号から、クーポン出力対象カードレコード８２０（図１７参照、詳細は後述）を参照して、会員利用者がエントリーしているクーポン企画を特定する。そして１以上のエントリー済みのクーポン企画が特定された場合には、決済ポリシーに登録されている全ての支払い方について、特定された各クーポン企画のクーポンが出力可能かどうか(以後、「クーポン（が）出力可能」は、クーポン企画に基づく特典付与が可能であることも含めた意味で用いる)をクーポン出力判定処理（図１９参照、詳細は後述）により判定する。クーポン出力可能と判定された支払い方が存在する場合は、応答電文に当該支払い方と当該支払い方でクーポン出力可能な１以上のクーポン企画情報とを明示して、店舗端末１００に返信する。

　店舗端末１００は、決済ポリシー等が返された場合は、そのポリシーに登録されている支払い方を支払い方の選択肢として表示部１０３ｂに表示して、会員利用者の選択を促す（Ｓ６０）。このとき、クーポン出力可能な支払い方がある場合には、当該支払い方とともにクーポン出力可能な１以上のエントリー済みのクーポン企画情報を併せて表示部１０３ｂに表示する。認証失敗が返された場合は、他のカードを提示し直すか、現金払いかを促す表示をして会員利用者の次の行動を促す。会員利用者は、店舗端末１００の表示部１０３ｂのＧＵＩを利用するなどしてその時の「支払い方」を選択する（Ｓ７０）。

　図２０は、表示部１０３ｂに表示される支払い方を選択する会員カード決済画面５５０を示す図である。５５１において、各支払い方が選択可能に表示される。また、支払い方のうちクーポン出力可能なエントリー済みのクーポン企画が存在する場合には、支払い方とともにクーポン企画の情報を明示する。図の例では、支払い方５５１（「クレジット」）とともにクーポン番号５５２（「Ｎｏ．１０１」）、支払い方５５１（「ポイントＢ利用、クレジット」）とともにクーポン番号５５２（「Ｎｏ．１０１」）、支払い方５５１（「マイ決済：出来るだけポイントを使う」）とともにクーポン番号５５２（「Ｎｏ．１０１、１０２」）が表示されている。これにより、会員利用者はどの支払い方を選択すればクーポンの提供を受けることが可能かを容易に把握できる。

　店舗端末１００は、選択された「支払い方」に基づいて、決済処理を行う決済電文、ポイント処理を行う決済電文を決済代行サーバー２００を通じて決済事業者に対して発信する（Ｓ８０）。決済事業者からは決済代行サーバー２００を通じて、決済電文に関する応答電文が、ポイント処理事業者からはポイント増減結果に関する応答電文が返される。また決済代行サーバー２００は、選択された支払い方がクーポン出力可能な場合には、決済処理、ポイント処理の各段階で、当該支払い方でクーポン出力可能か否かをクーポン出力判定処理（図１９参照）により再度判定し、クーポン出力可能と判定された場合には応答電文にクーポン企画情報を設定する（或いは、クーポン企画情報に基づいた決済電文を設定する）。店舗端末１００は、応答電文に基づいてレシート情報を生成して、会員利用者に出力する。会員利用者はレシートを受領する（Ｓ９０）。応答電文にクーポン企画情報が設定されている場合には、クーポン企画情報のコンテンツを印字したレシートが生成される。

　図５は、図４で説明した一連の処理の流れ（特に、提供される特典が引き換え券のような印刷された紙として提供される場合（後述する「特典付与形式」が「紙」の場合）におけるクーポンエントリーから商品、クーポンの受け取りまでの流れ）を、店舗端末１００、決済代行サーバー２００の処理内容を中心に説明する概略的図である。図の中央の事業者会員サイトとあるのは、決済代行サーバー２００がインターネット上に開設する会員サイトである。決済代行サーバー２００はＷＷＷサーバー機能を備えて会員向けホームページを提供している。

　決済代行サーバー２００は会員サイト上で、会員利用者からクーポンエントリーを受付け、これらの情報を会員識別情報と関係づけて会員情報データベース２２１に登録する（図５の丸ゼロ、丸１）。

　店舗のレジ係は、会員利用者がとった購入希望商品の商品コードをレジ（店舗端末１００）のバーコードリーダー１０５に読み取らせる。店舗端末１００は商品売価データベースを参照して当日の売価を読み出して、購入希望商品全ての合計金額を算出し店舗端末１００の表示部に呈示する。

　同時に店舗のレジ係は会員利用者が提示したカードをレジ（店舗端末１００）のカードリーダー１０６に読み取らせる。店舗端末１００は、読み取ったカード番号を含んだ店舗電文（会員情報）を決済代行サーバー２００に送信して、会員利用者の認証を行うとともに、会員利用者の決済ポリシー情報を取得する。また前記したように決済ポリシーに登録された全ての支払い方についてクーポン出力判定処理（図１９参照）を実行することで、クーポン出力可能な支払い方、および当該支払い方でクーポン出力可能なクーポン企画情報を特定する。
　会員利用者が支払方法を選択すると、店舗端末１００は、店舗電文(決済要求)を送信する（丸５）。

　決済代行サーバー２００は電文振分処理を実行し、例えば、会員利用者が選択した支払い方がクレジットカード払いでポイントをためるという内容であれば、決済代行サーバー２００はまず、クレジットカード会社に決済電文（与信、売上処理）を送信し（丸７）、その応答結果を受け（丸８）、正常応答ならば続けて、ポイントサービス会社に決済電文（ポイント付与）の電文を送信して（丸１０）、その応答を受ける（丸１１）。このように決済代行サーバー２００の特徴的な機能の一つにこのような電文振分処理機能がある。

　決済代行サーバー２００はカード会社からの応答とポイントサービス会社からの応答に基づいて、正常な場合には、応答電文（決済ポイント付与完了）を店舗端末に返信する（丸１２）。
　このとき、決済代行サーバー２００は、選択された支払い方に対してクーポン企画情報が設定されている場合には、カード会社からの応答とポイントサービス会社からの応答のあと、当該支払い方でクーポン出力可能か否かをクーポン出力判定処理（図１９参照）により再度判定し、クーポン出力可能と判定された場合には応答電文にクーポン企画情報を設定する。
　店舗端末１００はこの応答電文に基づいてレシートを作成し、レジ係は印字されレシートを会員利用者に渡す（丸１３）。このとき、応答電文にクーポン企画情報が設定されていれば、レシートにクーポン企画情報に関するコンテンツが印字される。また、クーポンと引き換えに特典を会員利用者に渡してもよい（丸１４）。

　図６は、決済代行サーバー２００の電文振分処理機能を説明する表である。この機能は、基本電文、スイッチング電文、エクストラ電文を使い分けることでカード連携処理を実現する。基本電文は、提示されたカードに応じた通常の処理を行う場合に発信される電文である。例えば、シナリオとして、会員利用者がその事業者の店舗でその事業者が発行した会員カードを提示する場合（Ｎｏ．１－１）は、その事業者のポイント管理サーバーにポイント加算の電文が発信される。また顧客がクレジットカードを提示してクレジット払いを指定した場合は、そのカード発行会社へ与信を行うための電文が発行される（Ｎｏ．１－２）。これらはいずれも通常の処理における電文処理であり、本願発明に特徴的な機能ではない。

　一方、スイッチング電文は、提示されたカードと異なる登録済カード番号に変換して発信される電文である。例えば、シナリオとして、会員利用者が会員カードを提示してクレジット処理を行う場合（Ｎｏ．２－２）は、読み取られた（入力された）会員カードの番号を登録されたクレジットカードの番号に変換して与信処理の電文を発信する。また、エクストラ電文は、１回のカード読み取り操作で、登録済み別カードの電文を新しく複数発信させる電文であり、基本電文およびスイッチング電文の組み合わせで構成される。例えば、会員カードを提示してポイント加算とクレジット決済を行う場合（Ｎｏ．３－２）は、会員利用者の決済ポリシーにて指定されているクレジットカード会社に与信を確認する電文がまず送信され、正常応答が得られた場合には、更に、その会員利用者の決済ポリシーにて指定された事業者のポイント管理サーバーにポイント加算の電文が発信される。

　図７は、図４のＳ４０以降の、会員利用者、レジ係、店舗端末１００、決済代行サーバー２００の間の情報の詳細なやり取りを上から下へ時系列的に表したフロー図である。このフロー図により店舗端末１００、決済代行サーバー２００の処理を詳細に説明する。

　まず会員利用者は店舗で購入する商品をレジ係に渡し（図７の（Ａ））、レジ係はバーコードリーダー１０５で商品コードを読み取ると（Ｂ）、店舗端末１００はプライスルックアップを行って、会計金額を表示する（Ｃ）。そこで会員利用者はカードを提示する（Ｄ）（ここまでは図４のＳ４０に相当）。

　レジ係は店舗端末１００のカードリーダー１０６にカードを挿入して店舗端末１００にカード番号を読み取らせる（Ｅ）。店舗端末１００は、このカード番号が会員情報の一部として登録されているかどうかを、このカード番号を特定した会員照会リクエストという電文を送付することにより決済代行サーバー２００に問い合わせる（Ｆ）（このステップは図４のＳ５０に相当）。
決済代行サーバー２００は、会員情報データベース２２１に、該当するカード番号の登録記録を含む会員レコードが存在する場合は、その会員レコードから会員識別情報と決済ポリシー情報（定義されている「支払い方」の表示名情報）とクーポン出力判定処理（図１９参照）によって取得されるクーポン出力可能なクーポン企画情報を読み出して（抽出して）店舗端末１００に返信する。店舗端末１００は、これらの情報を表示部１０３ａ、１０３ｂに表示してレジ係、会員利用者の双方に、会員利用者の決済ポリシー情報（支払い方の選択肢）とクーポン企画情報とが認識できるように表示する（Ｈ）（このステップは図４のＳ６０に相当）。「支払い方」と「クーポン企画情報」を表示することにより、実際の支払いを行う前に、どの「支払い方」が会員利用者にとってメリットがあるかを容易に判断することができる。

　会員利用者は会員向けの表示部１０３ｂの表示内容を確認し、その時に所望する支払い方を１つ選択する（Ｉ）（このステップは図４のＳ７０に相当）。すると、店舗端末１００はあらためて、会員利用者が本当に会員情報データベース２２１から読み出した会員レコードの会員であるかどうかの本人認証を要求する（Ｋ）。提示されたカードのカード番号は会員情報データベース２２１に登録されていることはわかったが、そのカードを提示した人物が本当に会員本人なのかを確認する必要があるからである。本人確認手順は、店舗端末１００が会員向けの表示部１０３ｂであるタッチパネルから暗証番号（本人認証データの一例）を入力させるというやり方でもよいし、店舗端末１００に接続されたテンキーボードから暗証番号を入力させるというやり方でもよい。店舗端末１００は入力された暗唱番号を受付ける（Ｌ）。店舗端末１００は、この暗証番号と会員の識別情報を１つの店舗電文（決済時認証要求）として決済代行サーバー２００に問い合わせる（Ｍ）。

　会員の暗証番号が正しければ、その旨の応答が店舗端末１００に返信される。すると店舗端末１００は、会員を識別する情報、支払金額、会員利用者が選択した支払い方を識別する情報、選択した支払い方でクーポン出力可能なクーポン企画情報を含む店舗電文（決済手続きリクエスト）を決済代行サーバー２００に送信する（Ｎ）。決済代行サーバー２００は、会員顧客識別情報および会員利用者が選択した支払い方を識別する情報に従って必要な決済電文を決済事業者に送信する（Ｏ、Ｑ、Ｓ）。この時、店舗電文にクーポン企画情報が含まれる場合で、当該クーポン企画に係る特典付与形式が「紙」の場合は、まず、会員顧客識別情報および会員利用者が選択した支払い方を識別する情報に従って必要な決済電文を決済事業者に送信し、決済事業者から応答電文が返されると、決済代行サーバー２００は、クーポン出力判定処理（図１９参照）を実行する（Ｐ、Ｒ、Ｔ）。

　また、店舗電文にクーポン企画情報が含まれる場合で、当該クーポン企画に係る特典付与形式が「電文」の場合（クーポン企画情報により会員利用者に与える特典がポイント付与やキャッシュバックなどの場合）には、先にクーポン出力判定を行い、その結果に応じて必要な決済電文を決済事業者に送信する。なお、店舗電文にクーポン企画情報が含まれない場合は単に会員顧客識別情報および会員利用者が選択した支払い方を識別する情報に従って必要な決済電文を決済事業者に送信するだけである。
図７の場合には、クレジット決済とポイント付与およびポイント加算が必要とされる場合が例示されている（この一連のステップは図４のＳ８０に相当）。決済処理が正常に終了した場合は、店舗端末１００はレシートを発行し、会員利用者に商品と共に渡される（Ｕ、Ｖ）。決済代行サーバー２００から店舗端末１００に送られる応答電文にクーポン企画情報が設定されていれば、レシートにクーポン企画情報に関するコンテンツが印字される。また、クーポンと引き換えに特典を会員利用者に渡してもよい。クーポン企画に係る特典付与形式が「電文」の場合には、それらの特典を与えた旨をレシートに印字する情報を応答電文に含めてもよい。

　ここからしばらくは、本願発明の特徴である会員利用者ごとの、保有カードと決済ポリシーの登録の仕方と、クーポンエントリーの仕方と、それらがいかなるデータ構造をもって管理されるかについて説明する。本願発明の一実施態様としての決済システム１の決済代行サーバー２００がネットワーク９を通じてアクセスしてくる会員利用者が操作するクライアント端末４００に提供するユーザーインターフェース画面５００，５２０，５３０，５４０により説明する。

　図１０は、会員利用者の決済ポリシー登録情報を確認し、新たなカードの登録、暗証番号の更新、新たなマイ決済の登録を行うための入り口となる決済ポリシー登録画面５４０である。決済代行サーバー２００は、ネットワーク９を通じてアクセスしてきた会員利用者が使用しているクライアント端末にこの画面を表示するデータを送付して、会員利用者に現在の登録情報を提示するとともに新たな情報を登録させるように促す。５４１は会員基本情報表示欄である。５４２は保有ポイント表示欄である。５４３は登録済カード表示欄である。会員利用者による既登録済の保有カード情報が表示される。したがって、カード情報が未登録の場合にはカードを登録するボタン５４３９が表れるだけである。５４４は暗証番号設定欄である。５４４１で暗証番号を入力し、適用するボタン５４４９をクリックすると暗証番号が更新され会員情報データベース２２１の一項目として保持される。尚、現在設定されている暗証番号は表示されない。この暗証番号は、図７の「暗唱番号入力（Ｌ）」で会員利用者が店舗端末１００で入力する暗証番号と照合される番号である。５４５は、業者のレジで支払いを行うときの支払い方（システムの画面上では「マイ決済」と称する）の内容を表示するエリアである。「マイ決済」が未登録の場合にはカードを登録するボタン５４３９が表れるだけである。５４６は、会員利用者がエントリーしているクーポン企画の件数を表示するエリアである。ボタン５４６９をクリックするとクーポンエントリー画面５３０（図１８参照）が表示される。

　図８は、決済ポリシー登録画面５４０でカードを登録するボタン５４３９が選択された場合に決済代行サーバー２００からクライアント端末４００に提供されるカード登録画面５００である。会員利用者は、画面５００より保有カードを登録する。５０１はカード種別を選択入力する入力欄である。後述するカード種別テーブル６２０に登録されているカード種別から会員利用者が今登録しようとしているカードに該当するカード種別を選択する。５０２はカード番号を入力する。５０３は登録するカードがクレジットカードの場合のみ有効期限（有効期限情報）を入力する欄である。５０５は、この登録中のカードを事業者が発行している会員カードの代替カードとして設定する場合は選択マーク「レ」を設定する。そうでない場合は（単に決済用のカードとして用いる場合は）何も記入しない。５０１～５０５の入力が終われば５０９のＯＫボタンを押下する。会員利用者は５０１～５０５の設定を登録したいカード１枚ごとに行う必要がある。５０９のＯＫボタンが押されると、画面５４０が更新された状態で再表示される。登録済カード表示欄５４３には、今入力されたカード情報が仮登録ということがわかるような態様で（表示色を登録済みの内容表示と変えるなど）表示される。この状態で「カードを登録するボタン」５４３９を再度選択すると、カード情報が登録される(表示色が既登録済の表示色となる)。

　図１１は、カード登録に関係するデータの管理構造を説明する概念図である。会員レコード６００は、会員利用者ごとにユニークに作成される。会員利用者の名前、メールアドレスの他、５４４で入力された決済用暗証番号が会員利用者を識別する会員番号（さらにレコードＩＤとしてのＵＩＤ（＝会員ＵＩＤ））に関係づけられて登録される。尚、会員利用者の名前、メールアドレスは、決済ポリシー登録画面５４０とは別に用意される会員登録画面（図示せず）により決済システム１に入力されるものとする。

　カード登録画面５００でＯＫボタンが押されると、そのたびに、そこで入力された情報は、カードレコード６１０に１件のレコードとして追加される。カードレコード６１０に記録される１件のレコードは、（カードレコード６１０の）ＵＩＤ、会員ＵＩＤ、カード種別ＵＩＤ、カード番号（５０２で入力したカード番号）、有効期限（５０３で入力した有効期限）、会員カードフラグ（５０５でチェックした場合は「Ｔｒｕｅ」チェックしなければ空欄）を含む。

　カード種別テーブル６２０は、決済システム１で扱うことが可能な全てのカードの種別を網羅した一覧表である。図１１に示したのはその一例である。会員カード（ポイントカード）の場合は、ポイントサービスごとにカード種別は区別される。プリペイドカードについても同様である。クレジットカードはカード番号によりカード会社が区別できるので、カード種別としては１種類である。（会員レコード６００、カードレコード６１０およびカード種別テーブル６２０は本願発明における会員カードデータの一例である。）

　図９は、決済ポリシー登録画面５４０で「マイ決済を登録する」ボタン５４５９が選択された場合に決済代行サーバー２００からクライアント端末４００に提供されるマイ決済登録画面５２０である。この画面５２０により会員利用者は、業者のレジで支払いを行うときの支払い方の１つの指定である「マイ決済」を１件ずつ登録して会員利用者の決済ポリシーを決済システム１のデータベースに登録させることになる。

　５２１は、この画面で指定する１件の「マイ決済」を識別する表示名を指定する入力欄である。表示名は、会員利用者が認識できればどんなものでもよい。５２２は、ポイントを利用する際の情報・条件を入力するエリアである。５２２１は会員利用者が登録した保有カードのうちポイントカードに該当するものが表示される。５２２２は選択欄であって、５２２１に表示されたポイントカードのうち今設定する「マイ決済」において、ポイント利用するものにチェックを入れる。５２２３は５２２２で二つ以上チェックが入った場合の優先順を指定する。５２２４はポイント利用の態様を「利用しない」「全て利用する」「一部利用する」から指定する。一部利用する場合は５２２５のポイント端数利用桁数を指定する。５２２６は「一部利用する」場合の異なるオプションで、有効期限が近付いたらその分のポイントを使用させる設定欄である。５２３は支払方法を指定する設定欄である。５２２でポイントを全て利用すると指定した場合であっても、残金が生じる場合があるため、残金の支払い方法を指定する必要がある。５２４はポイント付与の設定を行う設定欄である。５２３で支払った結果支払額等に応じて獲得できるポイントを提供するポイントサービスを特定する情報（支払結果を反映させるポイントサービスを特定する情報）を、５２４２に、その支払に対してポイントを付与するカードとして指定する。

　通常、「マイ決済」は、ポイントをためる場合の支払い方法（５２２４でポイント利用の態様を「利用しない」を選択したもの）１つと、ポイントを利用する場合の支払い方法１つの２種類を登録する必要があるものと考えられる。これ以外にも、会員利用者の事情により、例えば、支払う方法として現金で払う「マイ決済」とクレジットカードで払う「マイ決済」の２通りを設定したり、ポイントを使用する支払い方として「全て利用する」場合と「一部利用する」場合の支払い方を設定するなども可能である。

　図１２は、「マイ決済」の設定に関係するデータベースの構造を説明する図である。会員利用者が画面５２０により設定した１件の「マイ決済」の情報はマイ決済レコード６５０に１件のレコードとして登録される。１件のマイ決済レコードは会員ＵＩＤと表示名（５２１で指定）を組にしてＵＩＤを付して記録される。１件のマイ決済が実行されるとき、店舗端末１００から決済代行サーバー２００へは、（会員ＵＩＤ、マイ決済ＵＩＤ、清算金額）を含むマイ決済リクエストが送信される(図７の（Ｎ）)。マイ決済リクエストに対応して決済代行サーバー２００において電文振分けされてカード会社等へ発信される決済電文の詳細とその実行順については、実行電文レコード６４０に記録される。１件の実行電文レコードは、（マイ決済ＵＩＤ、実行電文種別ＵＩＤ、カードＵＩＤ、電文種別ＵＩＤ、実行順番、ポイント利用区分ＵＩＤ、ポイント端数利用桁数、ポイント有効期限月閾値、クレジット支払い区分ＵＩＤ、クレジット支払い回数）から構成される。実行電文レコードには、店舗端末が１件の「マイ決済」を実行する時に決済代行サーバー２００が送信する必要のある電文の１件ごとに、１件のレコードが記録される。

　図１２の例では、例えばマイ決済レコードのＵＩＤ＝１のレコードは会員ＵＩＤ＝１で特定される会員利用者が定義した「できるだけポイントを使う」という表示名の「マイ決済」であって、これを実行するには、実行電文レコード６４０のＵＩＤ＝１からＵＩＤ＝５で指定される店舗電文をこの順で発信しなければならないことを示している。（マイ決済レコード６５０と実行電文レコード６４０および実行電文レコード６４０が参照する各種テーブルは本発明における「決済ポリシーデータ」の一例である。）

　実行電文書別ＵＩＤは、実行電文種別テーブル６６０に定義されている実行電文の種別を表す名前（「ポイント利用」、「お支払」、「ポイント付与」の何れか）を指定する。電文種別ＵＩＤは、電文種別テーブル６７０に定義されているその電文が行う処理（現金で支払い、電子マネーで支払い、クレジット与信、クレジット売上、クレジット返品、クレジット無効カード照会、ポイント照会、ポイント付与、ポイント利用、ポイント加算、プリペイド残高照会、プリペイド入金、プリペイド利用）を指定する。ポイント利用区分ＵＩＤは、ポイント利用区分テーブル６８０で指定されている「全て利用する」（ポイント利用区分ＵＩＤ＝１）または「一部利用する」（ポイント利用区分ＵＩＤ＝２）の何れかを指定する。クレジット支払い区分ＵＩＤは、クレジット支払い区分テーブル６９０で指定されている「一括払い」（クレジット支払い区分ＵＩＤ＝１）から「リボ払い」（クレジット支払い区分ＵＩＤ＝５）の何れか１つを指定する。

　ところで、図１２に例示した実行電文レコード６４０によれば、会員番号０００１、大日本太郎が登録した「できるだけポイントを使う」を表示名とする「マイ決済」は、
（実行順１）ハウスポイントカードＡ社のカード「６０００－」によりポイント利用し、ポイント充当後に残金が生じる場合は、
（実行順２）共通ポイントカード＃１「８０００－」によりポイント利用し、ポイント充当後に残金が生じる場合は、
（実行順３）クレジットカード「４９＊＊－＊＊＊＊－＊＊＊＊－００００」によりポイント充当後残金を支払い額として「クレジット与信」し、
（実行順４）同クレジットカードにて「クレジット売上」し、
（実行順５）支払額に対してハウスポイントカードＡ社のカード「６０００－」にポイント付与させる。
という一連の決済電文を発行することになる。１つの「マイ決済」を実行するための一連の実行電文は、1件の「マイ決済」が画面５２０により設定されれば、その設定内容から、機械的に、ポイント利用の電文→支払いのための電文→ポイント獲得のための電文を作成して実行電文レコードを生成することが可能である。

　次に、会員利用者がクーポン企画にエントリーする手段について説明する。
ここで、あらかじめクーポン企画情報が、会員サイトの管理者によって設定登録されているものとする。
　図１６はクーポン企画情報を設定登録するクーポン企画登録画面４５０の例を示す図である。４５１は、クーポン企画を特定する識別番号である「企画番号」とクーポン企画の名称である「企画名」とクーポンの提供期間である「企画期間」と、提供する特典が紙に印刷された引換券・クーポン券（特典付与形式＝「紙」）か特別ポイント付与など決済電文に反映される特典（特典付与形式＝「電文」）かを区別する「特典付与形式」と、クーポン出力可能な回数の上限である「クーポン出力上限回数」を設定するエリアである。

　４５２は、クーポンの出力対象となる「対象端末」を設定するエリアである。図示は省略するが、「一覧へ」ボタンを押下すると店舗端末を選択可能に一覧表示する画面が起動する。この画面上でクーポンの出力対象となる店舗端末を選択することができる。４５２の「２５３４件」とは、クーポンの出力対象となる店舗端末の総数を示す。

　４５３は、クーポンの出力対象となる「対象カード」を設定するエリアである。対象カードを設定する方法は任意であるが、図の例では、「出力種別」において、クーポンの出力対象とするカードをカード番号のＢＩＮ（レンジ幅）によって設定する。「対象カード番号件数」には、クーポンの出力対象となるカード件数が表示され、「一覧へ」ボタンを押下することによりクーポンの出力対象であるカード一覧が表示される。「対象ＢＩＮ件数」には、設定したＢＩＮの件数が表示され、また「一覧へ」ボタンを押下することによりクーポンの出力対象とするカード番号のＢＩＮ（レンジ幅）の確認および設定をすることができる。「除外カード件数」には、クーポン出力対象から除外するカード件数が表示される。「一覧へ」ボタンを押下することにより除外カードの確認および設定をすることができる。

　４５４は、クーポンの出力対象となる「対象取引」を設定するエリアである。図の例では、クレジットカードでの支払い（企画期間内での支払い）が、都度単価１００円以上または累計単価１０００円以上の場合であって、ハウスポイントへのポイント付与が３０００～９０００ポイントまたはハウスポイントのポイント利用が１００～５００ポイントの場合、にクーポンが出力可能であることを示している。

　４５５は、クーポンの出力対象となる「対象商品」を設定するエリアである。図示は省略するが、「一覧へ」ボタンを押下すると商品を選択可能に一覧表示する画面が起動し、この画面上でクーポンの出力対象となる商品を選択することができる。４５５の「２件」とは、クーポンの出力対象となる商品件数である。尚、特典付与形式が「電文」の場合は、ここに付与するポイント点数やキャッシュバックする金額を特定する情報が設定される。

　４５６は、レシートに印字するクーポン企画に関するコンテンツを設定するエリアである。図の例では、端末の機種（「ＶＥＧＡ５０００」「ＣＡＴ５９００」「ＥＣ」）ごとに、出力仕様に応じたコンテンツ情報が設定されている。コンテンツは文字情報や画像情報で設定することが可能である。

　そして、「更新」ボタン４５０２を押下すると、クーポン企画情報が登録され、図１７のデータベースに保持される。
　「削除」ボタン４５０３を押下すると、画面４５０に現在表示されているクーポン企画情報を削除することができる。すなわち、図１７のデータベースから当該クーポン企画情報に関する一切のデータが削除される。
　「流用登録」ボタン４５０１を押下すると、既に登録した任意のクーポン企画情報を選択する画面が起動する。この画面上でクーポン企画情報を１つ選択すると、選択した当該クーポン企画情報を新たな企画番号を付けて画面４５０上に表示させることができる。これにより、新たなクーポン企画情報を設定登録する際に、既に登録したクーポン企画情報を利用することができる。

　図１７は、クーポン企画情報を保持するデータベースの構造を説明する図である。管理者が画面４５０により設定した１件のクーポン企画の情報は企画レコード８００に１件のレコードとして登録される。１件の企画レコードはクーポン企画を特定するＵＩＤ（４５１で設定された企画番号）、企画名（４５１で設定された企画名）、期間（４５１で設定された企画期間）、特典付与形式（４５１で設定された特典付与形式である「紙」または「電文」）、クーポン情報（提供されるクーポンの情報）、クーポン出力上限回数（４５１で設定された上限回数）、図示していないが４５５で設定される対象商品の情報（特典付与形式が「電文」の場合は、付与ポイント数など、を含む。

　クーポン出力対象店舗レコード８１０は、企画レコード８００に登録されている各クーポン企画のクーポン出力対象となる対象店舗（４５２で設定された対象端末）の情報を保持する。図に示すように、クーポン企画を特定する「企画ＵＩＤ」と「店舗名」が対応づいて保持されている。
　例えば、図の例では、企画ＵＩＤ（＝１０１）の企画（オープニングキャンペーン）は、「Ａコンビニ五反田店」の店舗端末でクーポンが出力可能であり、企画ＵＩＤ（＝１０２）の企画（ポイント使おうキャンペーン）は、「Ａコンビニ五反田店」および「Ｂコンビニ市ヶ谷店」の店舗端末でクーポンが出力可能であることを示している。

　クーポン出力対象カードレコード８２０には、企画レコード８００に登録されている各クーポン企画のクーポン出力対象となる対象カード（４５３で設定された対象カード）が登録される。なお、クーポン出力対象カードレコード８２０には、会員利用者が当該クーポン企画にエントリーした場合にのみ、その会員利用者が保有するカードが登録される。これにより、決済代行サーバー２００は、クーポン出力対象カードレコード８２０を参照することで、会員利用者がどのクーポン企画にエントリーしているかを判断することができる。図に示すように、クーポン企画を特定する「企画ＵＩＤ」と「カード種別ＵＩＤ」と「カード番号」と「累積購入額」と「クーポン出力回数」が対応づいて保持されている。「クーポン出力回数」は初期値ゼロであり、クーポン出力されるたびにインクリメントされる。

　クーポン出力対象取引レコード８３０は、企画レコード８００に登録されている各クーポン企画のクーポン出力対象となる対象取引の情報を保持する。図に示すように、クーポン企画を特定する「企画ＵＩＤ」と「カード種別ＵＩＤ」と「都度単価」と「累計単価」とが対応付けて保持されている。
　例えば、図の例では、企画ＵＩＤ（＝１０１）の企画（オープニングキャンペーン）は、クーポンの出力対象となる取引を、クレジットカードによる支払い（カード種別ＵＩＤ＝３）であり、かつ、クーポン企画の期間内での支払金額が都度単価１００円若しくは累計単価１０００円以上、の取引に設定している。

　クーポン出力対象商品レコード８４０は、企画レコード８００に登録されている各クーポン企画のクーポン出力対象となる商品の情報を保持する。図に示すように、クーポン企画を特定する「企画ＵＩＤ」と「商品コード」（特典付与形式が「電文」の場合は、付与ポイント数など）とが対応付けて保持されている。

　図１８は、決済ポリシー登録画面５４０で「クーポンエントリーを確認する」ボタン５４６９が押下された場合に決済代行サーバー２００からクライアント端末４００に提供されるクーポンエントリー画面５３０である。この画面において、会員利用者はクーポン企画にエントリーすることができる。クーポンエントリー画面５３０には、クーポン企画の情報が一覧表示される。会員利用者は、この画面５３０上で、エントリー済みのクーポン企画を確認したり、或いは、未エントリーのクーポン企画にエントリーすることができる。５３１は未エントリーのクーポン企画（クーポンＮｏ．１０１）であり、５３２はエントリー済みのクーポン企画（クーポンＮｏ．１０２）である。例えば、会員利用者は、５３１のボタン５３１９を押下することで、未エントリーのクーポン企画（クーポンＮｏ．１０１）にエントリーすることができる。この場合、ボタン５３１９の表示が「エントリー済みです」へと切り替わる。また例えば、５３２のボタン５３２９を押下することで、エントリー済みのクーポン企画（クーポンＮｏ．１０２）をリセットし、未エントリーとすることができる。この場合、ボタン５３２９の表示が「エントリーする」へと切り替わる。クーポン企画へのエントリーを受け付けると、クーポン出力対象カードレコード８２０（図１７参照）に、会員利用者が登録したカードのうち当該クーポン企画のクーポン出力対象となるカードの情報が登録される。

　決済代行サーバー２００が実行するカード情報登録手段は、前述したように、記憶部２１０に記憶されているプログラムコード２１１が制御部２０２のＣＰＵに読み込まれて解釈実行されることによりその機能が発揮される。そしてその具体的な処理は、会員利用者が操作するクライアント端末４００からの要求に応えて、会員レコード６００、カードレコード６１０、マイ決済レコード６５０、実行電文レコード６４０を参照して決済ポリシー登録画面５４０を表示するデータを送付し、その後、カードを登録するボタン５４３９が選択されたことによりカード登録画面５００を表示するデータを送付し、その後ＯＫボタン５０９が選択されたことによりクライアント端末４００より新規カード登録要求がされた場合は、カードレコード６１０に新たに、当該会員利用者のＵＩＤに関係づけた１件のカードレコードを追加する処理を行う。また、暗証番号入力欄５４４１に暗証番号が入力され、適用するボタン５４４９が選択されることにより、クライアント端末４００より暗証番号更新要求がなされた時は、会員レコード６００の当該会員利用者のレコードの会員カード決済用暗証番号の項目を更新する。

　決済代行サーバー２００が実行する決済ポリシー登録手段は、前述したように、記憶部２１０に記憶されているプログラムコード２１２が制御部２０２のＣＰＵに読み込まれて解釈実行されることによりその機能が発揮される。そしてその具体的な処理は、画面５４０において、マイ決済を登録するボタン５４５９が選択されたことによりクライアント端末４００よりマイ決済登録開始要求がなされた時に、これに応えてマイ決済登録画面５２０をクライアント端末４００で生成表示させるデータを送出し、その後、ＯＫボタン５２９が選択されたことによりクライアント端末４００より画面５２０で指定された情報を含んだマイ決済新規登録要求がなされた時に、画面５２０で指定された情報を受領して当該会員利用者の会員ＵＩＤについての新たなマイ決済レコード（マイ決済ＵＩＤで一意に特定される）をマイ決済レコード６５０に追加するとともに、画面５２０で指定された情報の内容から、当該新たなマイ決済ＵＩＤに関する実行電文を自動作成して記録する。

　決済代行サーバー２００が実行するクーポンエントリー手段は、前述したように、記憶部２１０に記憶されているプログラムコード２１７が制御部２０２のＣＰＵに読み込まれて解釈実行されることによりその機能が発揮される。そしてその具体的な処理は、画面５４０において、クーポンエントリーを確認するボタン５４６９を押下することにより、図１７のデータベースを参照して、クーポン企画に関する情報を取得し、クーポンエントリー画面５３０をクライアント端末４００で表示するデータを生成して送付する。このとき、クーポン出力対象カードレコード８２０を参照して各クーポン企画のエントリー状況（エントリー済み、または未エントリー）を取得し、併せて送信する。これにより、図１８に示したように、クーポンエントリー画面５３０でエントリーの状況を把握することができる。クーポンエントリー画面５３０から新たなクーポン企画へのエントリーを受け付けると、会員利用者が登録したカードのうち当該クーポン企画のクーポン出力対象となるカードの情報をクーポン出力対象カードレコード８２０へ登録する。

　決済代行サーバー２００が実行する会員照会処理手段は、前述したように、記憶部２１０に記憶されているプログラムコード２１３が制御部２０２のＣＰＵに読み込まれて解釈実行されることによりその機能が発揮される。そしてその具体的な処理は、店舗端末１００からのカード番号を含む店舗電文（会員照会要求）（図７（Ｆ））に応答して、そのカード番号をキーとしてカードレコード６１０を参照して同一のカード番号が登録されているカードレコードの存在を調べ、存在する場合はそのカードレコードの会員ＵＩＤの項目を読み出し、この会員ＵＩＤをキーとしてマイ決済レコード６５０を検索して、この会員ＵＩＤで特定される会員利用者が登録した全てのマイ決済の、マイ決済ＵＩＤと端末表示画面名を読み出し、これらを店舗端末１００に返信する。店舗端末１００からの店舗電文（会員照会要求）に指定されたカード番号と一致するカード番号をもつカードレコードが存在しない場合は、その旨の応答を店舗端末１００に返信する。

　決済代行サーバー２００が実行する会員認証処理手段は、前述したように、記憶部２１０に記憶されているプログラムコード２１５が制御部２０２のＣＰＵに読み込まれて解釈実行されることによりその機能が発揮される。そしてその具体的な処理は、店舗端末１００からの店舗電文（決済時認証要求）（図７（Ｍ））に応答して、会員レコード６００に記録されている会員カード決済用暗証番号との照合結果を返信することである。

　決済代行サーバー２００が実行する電文振分手段は、前述したように、記憶部２１０に記憶されているプログラムコード２１４が制御部２０２のＣＰＵに読み込まれて解釈実行されることによりその機能が発揮される。そしてその具体的な処理は、店舗端末１００から発信された（会員ＵＩＤ、マイ決済ＵＩＤ、清算金額）を含むマイ決済リクエストに応えて（図７（Ｎ））、実行電文レコード６４０を指定されたマイ決済ＵＩＤをキーとして参照し、該当する電文レコードをその実行順番に、該当するカード会社やポイントサービス事業者で規定されているプロトコル、フォーマットの決済電文に変換して送信することである。１件の売上処理要求データをクレジットカード会社(決済事業者)が受け取れる決済電文に変換して送信する際には、決済事業者が提供するライブラリルーチンを利用して、「与信」や「売上処理」を意味する電文を作成して送信することになるが、このような処理は公知であり、詳細は割愛する（例えば特開２００５－１０７９９３号公報に関連技術の記載がある）。

　決済代行サーバー２００が実行する決済結果応答手段は、前述したように、記憶部２１０に記憶されているプログラムコード２１６が制御部２０２のＣＰＵに読み込まれて解釈実行されることによりその機能が発揮される。そしてその具体的な処理は、電文振分手段が発行した決済電文の結果応答が正常でない場合は、その内容を直ちにマイ決済リクエストに対する応答結果として「異常終了」を店舗電文送受信部２３０を介して店舗端末１００に返すことである。また、全ての決済電文の結果応答が正常であった場合に限り、マイ決済リクエストに対する応答結果として「正常終了」を店舗電文送受信部２３０を介して店舗端末１００に返すように動作する。

　決済代行サーバー２００が実行するクーポン出力判定手段は、会員照会処理手段および電文振分手段の一部として構成され、前述したように、会員照会時には記憶部２１０に記憶されているプログラムコード２１３、決済処理時には記憶部２１０に記憶されているプログラムコード２１４が制御部２０２のＣＰＵに読み込まれて解釈実行されることによりその機能が発揮される。具体的な処理を、図１９を参照して説明する。

　図１９は、図７の（Ｇ）、（Ｐ）、（Ｒ）、（Ｔ）において実行されるクーポン出力判定処理の流れを示すフローチャートである。図７の（Ｇ）（会員照会時）においては、会員利用者が登録した全ての支払い方についてクーポン出力判定処理を実行する。図７の（Ｐ）、（Ｒ）、（Ｔ）（決済処理時）においては、図７の（Ｉ）（Ｊ）で選択決定された支払い方についてのみクーポン出力判定処理を実行する。

　事前処理として、決済代行サーバー２００は、カード番号をキーとして、クーポン出力対象カードレコード８２０を参照し、エントリー済みの１以上のクーポン企画情報（企画ＵＩＤ）を特定する。
　そして、決済代行サーバー２００は、企画レコード８００（「期間」）を参照して、特定された各クーポン企画が、企画期間内か否かを判定する（ステップＳ１００）。次に、決済代行サーバー２００は、クーポン出力対象店舗レコード８１０を参照して、店舗端末１００がクーポン出力対象の対象店舗か否かを判定する（ステップＳ２００）。次に、決済代行サーバー２００は、クーポン出力対象カードレコード８２０を参照して、会員利用者が登録したカードがクーポン出力対象のカードが否かを判定する（ステップＳ３００）。次に、決済代行サーバー２００は、クーポン出力対象取引レコード８３０およびクーポン出力対象商品レコード８４０を参照して、クーポン出力対象となる買い物か否かを判定する（ステップＳ４００）。

　次に、決済代行サーバー２００は、企画レコード８００（「出力回数上限」）およびクーポン出力対象取引レコード８３０（出力回数）を参照して、クーポン出力（特典付与）が出力上限値以内かどうかを判定する（ステップＳ４１０）。以上のステップＳ１００～Ｓ４１０の全ての判定が「Ｙｅｓ」の場合、決済代行サーバー２００は、クーポン出力判定処理の呼出し元が会員照会手段であれば（ステップ４２０）、クーポン企画情報（クーポン企画を一意に特定する「企画ＵＩＤ」など）を応答電文に設定する（ステップＳ５００）。ステップＳ１００～Ｓ４１０の全ての判定が「Ｙｅｓ」の場合で、クーポン出力判定処理の呼出し元が電文振分手段であって、当該クーポン企画情報の特典付与形式が「紙」の場合（ステップ４２０）も、クーポン企画情報（クーポン企画を一意に特定する「企画ＵＩＤ」など）を応答電文に設定する（ステップＳ５００）。一方、ステップＳ１００～Ｓ４１０の全ての判定が「Ｙｅｓ」の場合で、クーポン出力判定処理の呼出し元が電文振分手段であって、当該クーポン企画情報の特典付与形式が「電文」の場合（ステップ４２０）は、クーポン企画情報（クーポン企画を一意に特定する「企画ＵＩＤ」、クーポン出力対象商品レコード８４０）に基づいた決済電文を設定する（ステップＳ５１０）。また、ステップＳ１００～Ｓ４００のいずれかの判定が「Ｎｏ」となる場合、決済代行サーバー２００は、クーポン情報を応答電文或いは決済電文に設定せずに処理を終了する。なお図１９のステップＳ１００～ステップＳ４１０の各判定処理の順序は、図の例に限らず、任意に入替え可能である。

　なおクーポン企画によっては、対象店舗（８１０）、対象取引（８３０）、対象商品（８４０）の少なくとも１以上が設定されていない場合がある。対象店舗が設定されていない場合とは、例えば、全店舗においてクーポン出力が可能な場合である。対象取引が設定されていない場合とは、例えば、全取引がクーポン出力対象となるような場合である。対象商品が設定されていない場合とは、例えば、全商品がクーポン出力対象となるような場合である。このような場合、決済代行サーバー２００は、ステップＳ２００、Ｓ４００において、クーポン出力対象店舗レコード８１０、クーポン出力対象取引レコード８３０、クーポン出力対象商品レコード８４０を参照する際に、企画ＵＩＤに対応するデータを取得することができないが、クーポン出力判定結果を強制的に「Ｙｅｓ」として次のステップへ処理を移行する。

　店舗端末１００が実行する店舗電文処理手段は、前述したように、記憶部１１０に記憶されているプログラムコード１１３が制御部１０２のＣＰＵに読み込まれて解釈実行されることによりその機能が発揮される。そしてその具体的な処理は、会員情報照会（図４のＳ４０，図７の（Ｆ））、決済時認証要求（図７の（Ｍ））、マイ決済リクエスト（図７の（Ｎ））、の各店舗電文を作成し店舗電文送受信部１０８を通じて決済代行サーバー２００に送信し、その応答を受信することである。会員情報照会は店舗端末１００が読み取ったカード番号を電文の引数として含める。決済時認証要求は店舗端末１００が会員利用者を名乗る者から受付けた暗証番号入力を電文の引数として含める。マイ決済リクエストは会員利用者が選択したマイ決済を特定するマイ決済ＵＩＤを電文の引数として含める。

　店舗端末１００が実行する会員照会処理手段は、前述したように、記憶部１１０に記憶されているプログラムコード１１２が制御部１０２のＣＰＵに読み込まれて解釈実行されることによりその機能が発揮される。そしてその具体的な処理は、レジ係の操作によりカードリーダー１０６から読み取られたカード番号を店舗電文処理手段に渡して会員情報照会の店舗電文を送信させること、会員照会の結果、決済代行サーバー２００から返信された会員利用者の決済ポリシー情報（少なくともマイ決済の表示名）を店舗端末１００の表示部１０３に表示させること、カード番号が未登録という旨の応答が返ってきた場合は、現金払いを促す表示を行うこと、等である。このとき、決済ポリシーに登録されている各支払い方とともにクーポン出力可能なクーポン企画情報を併せて表示部１０３ｂに表示する。このクーポン企画情報は、決済代行サーバー２００が実行するクーポン出力判定処理（図１９参照）によって応答電文に設定される。

　店舗端末１００が実行する決済依頼処理手段は、前述したように、記憶部１１０に記憶されているプログラムコード１１３が制御部１０２のＣＰＵに読み込まれて解釈実行されることによりその機能が発揮される。そしてその具体的な処理は、店舗端末１００が会員利用者のマイ決済情報（少なくともマイ決済の表示名）を表示した後、会員利用者が決済方法の選択肢を選択した時に、暗証番号を促す画面を表示し、テンキーその他の手段により暗証番号を受付け、これを引数として、店舗電文処理手段に渡して決済時認証要求の店舗電文を送信させること、そして、決済代行サーバー２００から「認証された（暗証番号が一致した）」旨の応答を受領した時は、会員ＵＩＤ、会員利用者が選択したマイ決済に対応するマイ決済ＵＩＤを店舗電文処理手段に渡して決済実行要求の店舗電文を送信させることである。一方、決済時認証要求に対する決済代行サーバー２００からの応答が「認証されなかった」場合は、再度暗証番号を促す画面表示に戻るが、失敗が連続して所定回数続いた場合は、現金払いを要求する表示を出力する等のエラー処理(異常処理)を行う。

　以上、本願発明の好適な実施形態に係る決済システム１を詳細に説明したが、本願発明は、これまで説明した決済システム１に限られるものではなく、その趣旨に逸脱しない限りにおいて様々に変形可能である。

　例えば、システム１の決済代行サーバー２００は、会員管理的な機能である、カード情報登録処理、決済ポリシー登録処理、会員照会処理、会員認証処理の各処理と、決済代行処理本来の処理といえる電文振分処理、決済結果応答処理の両機能を備えたサーバーの構成であるが、これを前者の機能を備えた会員管理サーバーと、後者の機能だけを行う決済代行サーバーの二つに分けた構成としてもよい。但し、この場合、会員情報データベース２２１は両方のサーバーで参照できるように構成する必要がある。またこの構成において、会員管理サーバーはさらに、カード情報登録処理、決済ポリシー登録処理の機能を別のサーバー装置に分離して構成してもよい。図１４及び図１５は、決済システム１の決済代行サーバー２００を会員管理サーバー２００Ａ（図１４）と決済代行サーバー２００Ｂ（図１５）に分離して構成した場合の一例を説明する図である。図１４、図１５において、図３の決済代行サーバー２００と同じ構成要素は同じ番号を付してある。会員管理サーバー２００Ａと決済代行サーバー２００Ｂに分離することにより同じ機能を発揮する構成要素は図３の対応する構成要素の番号の末尾にそれぞれＡ又はＢを付して示してある。尚、図１４、図１５では会員情報データベース２２１は会員管理サーバー２００Ａと決済代行サーバー２００Ｂのそれぞれに２重化して持たせるように示しているが、会員管理サーバー２００Ａだけに持たせて、決済代行サーバー２００Ｂにおいて電文振分処理を行うときに、会員管理サーバー２００Ａの会員情報データベース２２１にアクセスして必要な情報を読み出すように構成することも可能であることは当業者において容易に理解されるであろう。

　また、店舗端末１００は、ＰＯＳレジの機能を兼ね備えたものとして記載したが、別体のＰＯＳレジ装置（本願請求項７に記載の発明における「外部装置」）に接続して使用する装置として構成してもよい。その場合、清算すべき金額等の情報をＰＯＳレジ装置から受け取り、決済代行サーバー２００から受領した決済処理の応答結果をＰＯＳレジ装置に伝えるための何らかの接続インターフェース（同「接続部」の一例）を備える必要がある。

　また、店舗端末１００は、マイ決済リクエストを行う直前に決済時認証要求（図７の（Ｍ）を行うという説明をしたが、この決済時認証要求は省略してもよい。セキュリティは落ちるが、少額決済が主体でレジの処理能力を重視せざるを得ない業態の事業者においては、このような構成もあり得る。

　実施形態の説明および図１１、図１２で示した会員情報データベース２２１のデータ構造は説明のための一例を示したものであって、本願発明の趣旨が同図で示したデータスキームに限られるというものではない。

　また、システム１の説明の中で本願発明に係る決済方法についても説明された。

　システム１において説明した決済代行サーバー２００は、実店舗の店舗端末１００ではなく、電子商取引を行うＥＣ店舗から店舗電文を受けて決済システムを構成することも可能である。図１３は、決済代行サーバー２００がＥＣ店舗７００と連携する構成とした決済システム２の全体概要図である。システム２において、決済代行サーバー２００がＥＣ店舗７００から受ける店舗電文（会員照会リクエスト、決済時認証要求、決済手続きリクエスト）は、システム１において店舗端末１００から受けるものと全く同じである。ＥＣ店舗７００は、会員利用者がクライアント端末４００を通じてＥＣ店舗にログインした後、会員利用者が商品を選択して支払手続に進んだ時に適当なタイミングで決済代行サーバー２００に会員照会リクエストを送り、決済代行サーバー２００から返信される当該会員利用者が定義した決済ポリシーに係る情報と決済ポリシーに登録されている各支払い方でクーポン出力可能なクーポン企画情報を取得して、この情報をクライアント端末４００に会員利用者が選択可能な態様で表示させるように構成すればよい。それ以後の処理（図７における「支払い方の決定（Ｊ）」以降の処理）については、図７に示される店舗端末１００の処理をＥＣ店舗７００がクライアント端末４００と決済代行サーバー２００との間に入って行うように、ＥＣ店舗７００を構成すればよい。但し、ＥＣ店舗７００は「レシート出力（Ｕ）」はできないので、その代わりにレシート内容をクライアント端末４００に表示させるデータを送出するようにすればよい。

　以上、詳細に説明した内容から読み取られる通り、本願発明に係る店舗端末装置、会員管理サーバー、決済代行サーバー、および決済方法は、様々な小売業において顧客に便益を提供する手段として利用可能である。

１　　　　　決済システム
９　　　　　ネットワーク(インターネット)
７　　　　　ネットワーク
１００　　　店舗端末
１０１　　　バス
１０２　　　制御部
１０３ａ　　表示部ａ
１０３ｂ　　表示部ｂ
１０５　　　バーコードリーダー
１０６　　　カードリーダー
１０７　　　レシートプリンタ
１０８　　　店舗電文送受信部
１１０　　　記憶部
２００　　　決済代行サーバー
２０１　　　バス
２０２　　　制御部
２１０　　　記憶部
２２０　　　大容量記憶装置
２２１　　　会員情報データベース
２３０　　　店舗電文送受信部
２４０　　　決済電文送受信部
３００　　　決済事業者装置
４００　　　クライアント端末
４５０　　　クーポン企画登録画面
５００　　　カード登録画面
５２０　　　マイ決済登録画面
５３０　　　クーポンエントリー画面
５４０　　　決済ポリシー登録画面
５５０　　　会員カード決済画面
７００　　　ＥＣ店舗

Claims

　会員利用者所有のカードに関する情報を当該会員利用者の識別情報と関係づけて登録した会員カードデータと、登録したカードを用いた「支払い方」を会員ごとに１つ以上登録した決済ポリシーデータとを含む会員情報を保持する会員管理サーバーおよび、ポイントサービス事業者も含む各種決済事業者が設置する決済事業者装置に決済電文を送信する決済代行サーバーと連携して動作する店舗端末装置であって、
　表示部およびネットワークを通じて前記会員管理サーバーおよび決済代行サーバーと通信する送受信部を備え、
　清算すべき金額を確定する処理手段と、
　会員利用者が提示したカードの番号が入力されると、この番号に基づいて前記会員管理サーバーに会員照会を行い、会員照会の結果、特定された会員利用者が登録した前記決済ポリシーデータに係るデータを会員管理サーバーから受領して、会員利用者に１つ以上の「支払い方」を選択可能な態様で前記表示部に表示する会員照会処理手段と、
　会員利用者が選択した「支払い方」に従った決済処理を決済代行サーバーに依頼する決済依頼処理手段と、
を少なくとも備える店舗端末装置。
　前記「支払い方」は、１）ポイントを使うか使わずに貯めるか、２）支払方法、３）この支払結果を反映させるポイントサービスを特定する情報　を明らかにしたデータであって、１件ごとに識別情報とともに「支払い方」の表示名が付けられているデータであることを特徴とする請求項１に記載の店舗端末装置。
　前記会員照会の結果、店舗端末装置に返される前記決済ポリシーデータに係るデータは、当該会員利用者が登録した全ての「支払い方」の識別情報と表示名であることを特徴とする請求項１又は請求項２に記載の店舗端末装置。
　前記会員管理サーバーは、会員利用者ごとに、本人認証する際に照合する本人認証データをも保持するものであって、
　前記決済依頼処理手段は、前記「支払い方」に従った決済処理を決済代行サーバーに依頼する直前に、会員利用者から本人認証データの入力を受付け、会員利用者が与えたこの本人認証データと前記会員管理サーバーが保持している本人認証データとの照合を前記会員管理サーバーに要求するよう構成された請求項１又は請求項２に記載の店舗端末装置。
　バーコード読み取り部を備え、
前記清算すべき金額を確定する手段は、商品に付されたコードをバーコード読み取りしたコードをキーにして商品ごとの売価を読み出して合計金額を算出するＰＯＳ処理手段であることを特徴とする請求項１または請求項２に記載の店舗端末装置。
　請求項５に記載の店舗端末装置であって、前記決済処理の応答結果を受けてレシートを印字する手段を備えた店舗端末装置。
　請求項１または請求項２に記載の店舗端末装置であって、前記清算すべき金額を確定する手段は、外部装置より合計金額を取得する接続部であって、前記決済代行サーバーから受領した前記決済処理の応答結果を前記接続部を介して前記外部装置に伝える構成とした店舗端末装置。
　前記会員管理サーバーは、会員利用者所有のカードと対応づけてクーポン企画の情報を保持し、
　前記会員照会処理手段は、前記「支払い方」で用いるカードに対応した前記クーポン企画の情報を前記会員管理サーバーから受領して、前記「支払い方」とともに前記表示部に表示することを特徴とする請求項１に記載の店舗端末装置。
　店舗の利用者が提示したカードに基づいて会員照会を行う店舗端末装置と連携して動作する会員管理サーバーであって、
　会員利用者所有のカードに関する情報を当該会員利用者の識別情報と関係づけて登録した会員カードデータと、登録したカードを用いた「支払い方」を会員ごとに１つ以上登録した決済ポリシーデータとを含む会員情報を保持する会員データ記憶部と、
　ネットワークを通じて店舗端末装置からの会員照会リクエストを受信し、照会の結果を返信する送受信部と、
　店舗端末装置からの会員照会リクエストに付されたカード番号をキーにして前記会員カードデータを検索し、一致したカード番号を有する記録がある場合は、そのカードに関する情報を登録した会員が登録した決済ポリシーデータに係るデータを前記会員データ記憶部より抽出して、店舗端末装置に返信する会員照会処理手段と、
を備えた会員管理サーバー。
　前記会員カードデータの１件のデータは、会員を特定する識別情報、カードの種別を特定する情報、カード番号、有効期限情報を含むものである請求項９に記載の会員管理サーバー。
　前記カードの種別を特定する情報は、現金払い、電子マネー、クレジットカード、ポイントカードを区別する情報であることを特徴とする請求項９に記載の会員管理サーバー。
　前記「支払い方」の１件のデータは、その「支払い方」を実行する場合に必要となる決済事業者への決済電文の内容と実行順をもれなく列挙して、各決済電文ごとに、ポイントを利用するかしないかを区別する情報、使用するカードを特定する情報を含むものである請求項９に記載の会員管理サーバー。
　会員利用者が連携して使用したいカードの情報を登録するカード情報登録手段と、会員利用者の決済ポリシーを幾つかの登録したカードを用いた支払い方のセットとして定義して登録する決済ポリシー登録手段とを備えて、会員利用者ごとの会員カードデータと決済ポリシーデータの登録をネットワークを介して受付ける請求項９に記載の会員管理サーバー。
　会員利用者所有のカードと対応づけてクーポン企画の情報を保持するクーポンデータ記憶部、を更に備え、
　前記会員照会処理手段は、カード番号をキーとして１以上のクーポン企画の情報を検索し、店舗端末装置に返信することを特徴とする請求項９に記載の会員管理サーバー。
　会員利用者のクーポン企画へのエントリーを受け付けるクーポンエントリー手段、を更に備え、
　前記クーポンデータ記憶部が保持する前記クーポン企画の情報は、前記クーポンエントリー手段により会員利用者からエントリーの受け付けがあったクーポン企画の情報であることを特徴とする請求項１４に記載の会員管理サーバー。
　前記会員照会処理手段は、全ての「支払い方」について、検索された各クーポン企画のクーポンが出力可能か否か、或いはクーポン企画に基づいた特典付与が可能か否かを判定し、クーポンが出力可能、または特典付与が可能と判定された支払い方が存在する場合は、当該支払い方と当該支払い方でクーポンが出力可能または特典付与が可能なクーポン企画の情報を、店舗端末装置に返信することを特徴とする請求項１４に記載の会員管理サーバー。
　会員利用者が予め定義した1つ以上の「支払い方」を表示して会員利用者の選択を受付ける店舗端末装置と連携して動作する決済代行サーバーであって、
前記「支払い方」は、１）ポイントを使うか使わずに貯めるか、２）支払方法、３）この支払結果を反映させるポイントサービスを特定する情報を明らかにして、１件ごとに識別情報とともに「支払い方」の表示名が付けられているデータであって、
　会員利用者に関係づけて当該会員利用者所有のカードに関する情報を登録した会員カードデータと、登録したカードを用いた「支払い方」を会員ごとに１つ以上登録した決済ポリシーデータとを含む会員情報を保持する会員データ記憶部と、
　ネットワークを通じて店舗端末装置からの決済手続きリクエストおよびそれへの応答の受発信を行う店舗電文送受信部と、
各種決済事業者が設置する決済事業者装置への決済電文およびその応答電文の受発信を行う決済電文送受信部と、
　前記店舗電文送受信部を介して受付けた前記決済手続きリクエストに含まれる「支払い方」を特定する情報に基づいて前記決済ポリシーデータを検索して、指定した「支払い方」に従って清算処理するために必要となる前記決済事業者装置への決済電文の内容と実行順情報を抽出して、これらの情報に従って必要な決済電文を１つずつ前記決済電文送受信部を介して所定の順序で前記決済事業者装置に発信する電文振分手段と、
　指定した「支払い方」の実行結果を前記店舗電文送受信部を介して店舗端末装置に返信する決済結果応答手段と
を備えることを特徴とする決済代行サーバー。
　会員利用者所有のカードと対応づけてクーポン企画の情報を保持するクーポンデータ記憶部と、
　前記「支払い方」で前記クーポン企画のクーポンが出力可能か否かを判定するクーポン出力判定手段と、を更に備え、
　前記クーポン出力判定手段によりクーポン出力可能と判定された前記クーポン企画の情報を、前記店舗電文送受信部を介して店舗端末装置に返信することを特徴とする請求項１７に記載の決済代行サーバー。
　会員利用者所有のカードと対応づけてクーポン企画の情報を保持するクーポンデータ記憶部と、
　前記「支払い方」で前記クーポン企画に応じた特典の付与が可能か否かを判定するクーポン出力判定手段と、を更に備え、
　前記クーポン出力判定手段によりクーポン企画に応じた特典の付与が可能と判定された場合は前記決済事業者装置へ前記決済電文送受信部を介して特典付与に応じた決済電文を送信することを特徴とする請求項１７に記載の決済代行サーバー。
　請求項９から請求項１６のいずれか１項に記載の会員管理サーバーを兼ね備えた請求項１７に記載の決済代行サーバー。
　事業者の店舗に設置される店舗端末装置、事業者の会員利用者を管理する会員管理サーバー、決済事業者と決済電文をやり取りする決済代行サーバーがネットワークを通じて接続される決済システムにおける決済方法であって、
　会員利用者が、前記会員管理サーバーにアクセスして会員利用者が所有する１つ以上のカードの情報を入力するステップ、
　前記会員管理サーバーが、前記入力されたカード情報を含む会員利用者に関する情報を、前記会員利用者を識別する情報と関係づけて前記会員管理サーバーの会員データ記憶部に登録するステップ、
　会員利用者が、前記会員管理サーバーにアクセスして前記事業者の店舗を利用する際の、前記登録したカードを用いた「支払い方」を１つ以上定義して、会員を識別する情報と関係づけた決済ポリシーとして前記会員管理サーバーの会員データ記憶部に登録するステップ、
　会員利用者が、前記事業者の店舗端末装置で購入商品又はサービスに対する支払いをする際に、登録したカードの一つを提示するステップ、
前記店舗端末装置が、提示されたカードのカード番号を読み出し、会員照会処理を行うことにより、前記会員管理サーバーから、当該会員利用者が登録した決済ポリシーに係る情報を呼び出すステップ、
　前記店舗端末装置が、呼び出した決済ポリシーに係る「支払い方」を会員利用者が選択できるよう店舗端末装置の表示部に表示して会員利用者の選択を促すステップ、
　前記店舗端末装置が、会員利用者が選択した「支払い方」及び支払額を前記決済代行サーバーへ送信して決済依頼を行うステップ、
　前記決済代行サーバーが、前記会員利用者により選択された「支払い方」に従って、購入商品又はサービスの代金を決済処理するための必要な決済電文を生成し送信するステップ、
　前記店舗端末装置が、前記決済電文に係る処理の応答結果を前記決済代行サーバーを通じて受信して、正常応答であればその結果に基づいてレシートを発行し、異常終了であれば、顧客に他の支払い方法の選択を促すステップ、
を含む手順で実行される決済方法。