JP2005004628A

JP2005004628A - Settlement processing method, card processing server therefor and program for realizing processing for the card processing server

Info

Publication number: JP2005004628A
Application number: JP2003169495A
Authority: JP
Inventors: Yaeko Uchibori; 弥恵子内堀; 弘市郎 ▲吉▼野; Kouichiro Yoshino
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2003-06-13
Filing date: 2003-06-13
Publication date: 2005-01-06

Abstract

<P>PROBLEM TO BE SOLVED: To use one or more payment accounts determined by conditions of a settlement target to a card made to have a plurality of payment accounts, and to make the plurality of payment accounts share a settlement amount at designated ratio according to an item. <P>SOLUTION: This settlement processing method has: a card reader 102 taking in a card ID from the card; a means for taking in payment information including a money amount obligated to pay by commodity purchase or facility use; and a means (a card processing server 101) for holding correspondence relation between the card ID and the plurality of payment accounts, correspondence relation between a card reader ID and an installation place of the card reader, and correspondence relation between the payment account and payment conditions, and for referring to the card ID, the payment information, the card reader ID and each the correspondence relation to determine one or more payment accounts used for the settlement from the plurality of payment accounts, and a money amount to be settled in each the account. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
本発明は、少なくともカードを特定する情報（カードＩＤ）を保持するカードなどの媒体を用いて決済処理を行う技術に関し、特に該媒体に複数の異なる支払口座を対応付けておき、決済時に、該複数の異なる支払口座のうち決済対象の内容によって決められる支払口座を利用して決済処理することを可能にした決済処理方法、そのためのカード処理サーバ、該カード処理サーバの処理を実現するためのプログラムに関する。
【０００２】
【従来の技術】
従来、商品を購入したり、宿泊したりした場合に、クレジットカードを利用して決済する決済方法は周知であり、一般に普及している決済方法である。さらに近年、利用者の利便性を考慮し、一枚のカードに複数の決済方法のための情報を持たせておき、このカードを用いて指定された決済方法により決済するものも知られている。
【０００３】
例えば、特開２００２−８３１４５号公報（特許文献１）には、一枚のカードに複数のカード会社のクレジットカード機能を持たせたり、一枚のカードに複数の決済口座を対応づけて記憶しておいて、利用者の指定により利用するカード会社や決済口座を使い分けるようにしたものが記載されている。
【０００４】
また、特開２００２−６３３７４号公報（特許文献２）には、一枚のカードに複数のクレジットカード機能をもたせ、商品を購入時にどのクレジットカード機能を使って当該商品の決済をするかを注文者が決定するようにしたものが記載されている。
【０００５】
さらに、特開平１１−２５９５７７号公報（特許文献３）には、ＩＣチップを備えた一枚の決済カードに複数の決済機能（電子財布利用機能、クレジット利用機能、ポイントデータ利用機能、ポイントデータ利用機能など）を持たせ、これら複数の決済機能に予め優先順位を設定しておき、決済時にその優先順位に従って決済を行うようにした決済処理装置が記載されており、また決済時に残高不足が生じた場合には、現金で決済することも記載されている。
【０００６】
【特許文献１】
特開２００２−８３１４５号公報
【特許文献２】
特開２００２−６３３７４号公報
【特許文献３】
特開平１１−２５９５７７号公報
【０００７】
【発明が解決しようとする課題】
上記従来技術は、上述したように、一枚のカードに複数のクレジットカード機能を持たせておき、決済時に、決済するクレジットカード機能を利用者あるいは注文者が指定し、該指定したクレジットカード機能を用いて決済するようにしたり、あるいは、一枚のカードに電子財布利用機能、クレジット利用機能、ポイントデータ利用機能、ポイントデータ利用機能などの複数の決済機能を持たせ、それらに予め優先順位を設定しておき、決済時にその設定した優先順位に従った決済機能を用いて決済するようにしたものであり、一枚のクレジットカードを用いて複数の支払口座のうちの一つの支払口座を用いて決済できる点では便利であるが、これら従来技術は、利用者が指定した支払口座あるいは予め設定された優先順位によって決まる支払口座から決済するものであり、利用期間、利用場所、購入する商品、出張時の宿泊施設への支払いや交通費など決済対象の内容によって支払口座を決めることについては全く考慮していない。
【０００８】
そのため、複数の支払口座を持たせた一枚のクレジットカードを用いて決済する場合、利用者がいちいち支払口座を指定することなく、出張時（期間や場所が指定）の宿泊費や食費や交通費などは会社（企業）の支払口座で決済し、私用で購入した商品類は個人の支払口座で決済したり（団体（企業）／個人口座）、あるいは学用品や学習のための書籍は父親（または母親）の支払口座で決済し、子供が趣味のために購入した商品は子供名義の支払口座で決済するというようなことはできなかった。
【０００９】
本発明の目的は、複数の支払口座を持たせたカード（一般には媒体）に対し、決済対象の条件（例えば、特定の期間、場所、購入する商品、宿泊施設への支払い、交通費などの全て、あるいは、それらの組み合わせ）によって決められる支払口座を利用して決済処理すること、また、案件（例えば、食費）によっては決済額を複数の支払口座で指定された割合で分担させることが可能な決済処理方法、そのためのカード処理サーバ、該カード処理サーバの処理を実現するためのプログラムを提供することである。
【００１０】
【課題を解決するための手段】
上記目的を達成するために、本発明に係る決済処理方法は、複数の支払口座によって決済を行う決済処理方法であって、複数の支払口座に関連付けられているカードから該カードを特定するカードＩＤをカードリーダを用いて取り込むステップと、商品購入または施設利用によって支払義務が生じる金額を含む支払情報を取り込むステップと、カードＩＤと複数の支払口座の対応関係，カードリーダを特定するカードリーダＩＤと該カードリーダの設置場所の対応関係，および支払口座と支払条件の対応関係を保持し、前記取り込んだカードＩＤ，支払情報，および前記カードリーダＩＤに基づいて、前記各対応関係を参照して前記複数の支払口座から決済に利用する一つ以上の支払口座を判別し、該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定するステップと、該判別された一つ以上の支払口座により前記決定された金額を決済するステップとを有することを特徴としている。
【００１１】
また、カードを特定するカードＩＤと複数の支払口座の対応関係，カードリーダを特定するカードリーダＩＤと該カードリーダの設置場所の対応関係，および支払口座と支払条件の対応関係を対応関係保持手段に登録するステップと、複数の支払口座に関連付けられているカードからカードリーダで取り込んだカードＩＤ，商品購入または施設利用によって支払義務が生じる金額を含む支払情報，および前記カードリーダＩＤとを取り込み、前記対応関係保持手段を参照して、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別し、該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定するステップを有することを特徴としている。
【００１２】
また前記対応関係保持手段を参照しても、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別できない場合に、さらに詳細な情報を企業サーバに問合せるステップを有することを特徴としている。
【００１３】
前記対応関係保持手段は、さらに支払合計金額を複数の支払口座のそれぞれに割当てる割合を保持しており、前記判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定するステップは、前記割合を参照することを特徴としている。
【００１４】
本発明に係るカード処理サーバは、カードを特定するカードＩＤと複数の支払口座の対応関係，カードリーダを特定するカードリーダＩＤと該カードリーダの設置場所の対応関係，および支払口座と支払条件の対応関係を保持する対応関係保持手段と、複数の支払口座に関連付けられているカードからカードリーダで取り込んだカードＩＤ，商品購入または施設利用によって支払義務が生じる金額を含む支払情報，および前記カードリーダＩＤとを取り込み、前記対応関係保持手段を参照して、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別し、該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定する手段を有することを特徴としている。
【００１５】
また、本発明に係るプログラムは、カードＩＤと複数の支払口座の対応関係，カードリーダＩＤと該カードリーダの設置場所の対応関係，および決済対象の内容と支払口座の対応関係を保持する対応関係保持手段を具備し、決済を行う一つ以上の支払口座とそれらの口座に支払う金額を決定するカード処理サーバによって実行されるプログラムであって、複数の支払口座に関連付けられているカードからカードリーダで取り込んだカードＩＤ，商品購入または施設利用によって支払義務が生じる金額を含む支払情報，および前記カードリーダＩＤとを取り込む処理、前記対応関係保持手段を参照して、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別する処理、および該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定する処理を実現するものである。
【００１６】
【発明の実施の形態】
本発明の一実施の形態を、図面を用いて詳細に説明する。
図１は、本発明に係る決済処理システムの一実施形態を説明するための全体構成図である。
【００１７】
同図に示すように、本実施形態においては、カード処理サーバ１０１と、ホテルや駅やコンビニやその他諸々の場所に設置されているカードリーダ１０２と、複数のカード管理サーバ１０４（これらの多くは、カードの発行会社が有するサーバである）と、複数の企業サーバ１０３が、ネットワーク１０５を介して接続されている。
【００１８】
カードリーダ１０２は、カード会社が発行するカード（クレジットカードなど）のカード情報（少なくともカードＩＤ。その他の情報、例えばカード有効期限などを含んでいてもよい）を読み取り、そのカード情報を、当該カードリーダ１０２のカードリーダ情報（少なくとも該カードリーダを特定するカードリーダＩＤを含む。その他の情報、例えば該カードリーダの設置場所などを含んでいてもよい）と、例えば購入日時や購入商品名や購入価格などの商品購入情報とともにカード処理サーバ１０１に送信するものであり、さらにカード処理サーバ１０１から情報を受け取り、決済情報などを印字出力するためのものである。
【００１９】
なお、後述するカード処理サーバに、カードＩＤ対応に該カードの詳細な情報（例えばカードの有効期限など）やカードリーダＩＤ対応に該カードリーダの詳細な情報（例えばカードリーダの設置場所など）を登録するようにしておけば、カードリーダ１０２からカード処理サーバ１０１に送信するカード情報およびカードリーダ情報としては、カードＩＤおよびカードリーダＩＤだけでよい。以下、この場合の実施例を説明する。
【００２０】
企業サーバ１０３（詳細は図３に示す）は、特定のカードを登録（カードを一義的に識別するためのカードＩＤ対応に複数の支払口座を登録）するものであり、さらに、そのカード対応に登録された支払口座を用いて決済する決算対象の内容（期間、場所、利用目的などの情報）をカード処理サーバ１０１に送信して登録するためのものである。
【００２１】
カード処理サーバ１０１は（詳細は図２に示す）、ひとつまたは複数台あり、カードリーダ１０２から取得したカード情報（少なくともカードＩＤ）をもとに、そのカードが予め企業サーバ１０３から登録依頼があったものかを確認する。
【００２２】
確認の結果、そのカードは登録依頼があったものであるが、登録されている情報だけではどの支払口座でまたどの位の按分で決済してよいか判断できずさらに詳細な情報を必要とする場合は、企業サーバ１０３に問合せ、必要な情報のやりとりをする。
【００２３】
そして企業サーバ１０３から新たな情報を入手し、決済する支払口座が決まった場合に、当該カードの決済処理を各カード会社のカード管理サーバ１０４へ送信し、またカード会社のサーバ１０３からの情報を受け取る。
【００２４】
なお、カード処理サーバ１０１がカードリーダ１０２を具備していてもよく、またカード処理サーバ１０１がカード管理サーバ１０４を含んでいてもよい（あるいはカード管理サーバ１０４がカード処理サーバ１０１を含んでいてもよい）。
【００２５】
図２は、カード処理サーバ１０１の詳細図である。
カード処理サーバ１０１は、同図に示すように、購入情報認識部２０１と、購入情報送信部２０２と、購入情報判別結果受信部２０３と、企業別契約カード会社認識部２０４と、個人別契約カード会社認識部２０５と、企業別システム情報更新部２０６と、企業別利用案件一覧作成部２０７と、位置情報認識部２０８を有している。
【００２６】
また格納情報（ＤＢ）として、利用者情報データベース２０９と、企業情報データベース２１０、個人情報データベース２１１と、利用案件一覧データベース２１２と、位置情報データベース２１３を有している。
【００２７】
購入情報認識部２０１は、カードリーダ１０２から送られてきた購入品などの決済金額の情報（購入価格）と、それに対応したカードの情報（少なくともカードＩＤ）を読み込むためのものである。カードの情報には、有効期限やカード発行会社の情報やカード保有者の情報が含まれていてもよいが、前述したようにカードＩＤと有効期限やカード発行会社の情報やカード保有者の情報の対応関係が格納されていればカードＩＤだけでもよい。
【００２８】
購入情報送信部２０２は、該当する購入品に関する決済金額の情報、決済カードの情報を、企業サーバ１０３、またはカード管理サーバ１０４へ送信するためのものである（後述する図４のフローの詳細説明を参照のこと）
【００２９】
購入情報判別結果受信部２０３は、企業サーバ１０３から、該当する購入品の決済を企業カードにて実施してよいか判別した結果を受信するためのものである。
【００３０】
企業別契約カード会社認識部２０４は、カードリーダ１０２から送られてきた、カードの情報から、登録されている企業カードの情報を認識するためのものである。
【００３１】
個人別契約カード会社認識部２０５は、カードリーダ１０２から送られてきた、カードの情報から、登録されている個人カードの情報を認識するためのものである。
【００３２】
企業別システム情報更新部２０６は、企業サーバ１０３から送られてきた、システムの利用に関する情報を更新するためのものである。システムの利用に関する情報とは、企業カード利用者更新情報、個人カード利用者更新情報、出張予定情報、経費利用情報等である（後述する図７のカード処理サーバのデータベース更新フローの説明を参照）。
【００３３】
企業別利用案件一覧作成部２０７は、企業から登録された利用案件一覧情報（利用案件一覧ＤＢ２１２）に、実際カード決済が行われた情報を更新するものでもある。
【００３４】
位置情報認識部２０８は、カードリーダ１０２から送られてきたカードリーダ端末の情報、購入品などの決済日時の情報、およびカードリーダ端末の位置情報などの位置情報データベース２１３を読み込むためのものである。（なお、前述したように、カードリーダＩＤとカードリーダに関する情報やその設置場所の対応関係がカード処理サーバ１０１に登録してあれば、カードリーダ１０２からはカードリーダＩＤだけを読み込めばよい。）
【００３５】
カード処理サーバ１０１では、購入品などの決済日時、位置情報データベースの情報により、カードが不正に利用されていないか認識もする。
【００３６】
利用者情報データベース２０９は、システムを利用する利用者の情報を格納するものである。図８は、利用者情報データベース２０９のデータ例を示す図である。
【００３７】
同図に示すように、利用者情報データベース２０９は、利用者番号８０１と、所属企業番号８０２と、利用可能開始日時８０３と、利用終了日時８０４の項目よりなる。
【００３８】
例えば、同図の場合、番号１のデータは、利用者番号１２３４５６７８９の人の、所属企業番号は１００１−２３４５−１２３４であり、本利用者情報として利用可能開始日時は２００３年７月２３日１１時２２分、利用終了日時は２００８年１２月３１日２３時５９分である。
【００３９】
企業情報データベース２１０は、システムを利用する企業の情報を格納するものである。図９は、企業情報データベース２１０のデータ例を示す図である。
【００４０】
同図に示すように、企業情報データベース２１０は、企業番号９０１と、企業法人カード番号９０２と、契約カード会社番号９０３と、契約カード会社名９０４と、利用可能開始日時９０５と、利用終了日時９０６と、企業名称９０７と、商品購入などによって付与されるポイント９０８の項目よりなる。
【００４１】
例えば、同図の場合、番号１のデータは、企業番号１００１−２３４５−１２３４の、企業法人カード番号は１０００−１０００−１０００−１００１であり、契約カード会社番号は１０００１、契約カード会社名は×××、利用可能開始日時は２０００年４月１日０時０分、利用終了日時は２００８年３月３１日２３時５９分、企業名称は△△製作所、ポイントは７００４２６ポイントである。
【００４２】
個人情報データベース２１１は、システムを利用する利用者と企業カードとの関係を格納するものである。図１０は、個人情報データベース２１１のデータ例を示す図である。
【００４３】
同図に示すように、個人情報は、利用者番号１００１と、個人カード番号１００２と、契約カード会社番号１００３と、契約カード会社名１００４と、利用可能開始日時１００５と、カード利用期限１００６と、商品購入などによって付与されるポイント１００７の項目よりなる。
【００４４】
例えば、同図の場合、番号１のデータは、利用者番号１２３４５６７８９の人の、個人カード番号は４５６７−１２３４−１２３４−１２３４、契約カード会社番号は１０００１、契約カード会社名は×××、利用可能開始日時は２００１年７月２３日０時０分、カード利用期限は２００６年１２月、ポイントは１３ポイントである。
【００４５】
利用案件一覧データベース２１２は、カードを利用して決済した情報を格納するものである。図１１は、利用案件一覧データベース２１２のデータ例を示す図である。
【００４６】
同図に示すように、利用案件一覧データベース２１２は、企業番号１１０１と、利用者番号１１０２と、利用金額１１０３と、利用日時１１０４と、企業の按分比１１０５と、個人の按分比１１０６と、企業決済金額１１０７と、個人決済金額１１０８の項目よりなる。
【００４７】
例えば、同図の場合、番号１のデータは、企業番号１００１−２３４５−１２３４の企業で、利用者番号１２３４５６７８９の人の、利用金額は１０００円、利用日時は２００３年２月２１日２０時１分、按分企業比率が１００％、按分個人比率は０％、企業の決済金額が１０００円、個人の決済金額が０円である。
【００４８】
位置情報データベース２１３は、カードリーダ設置店舗の位置情報を格納するものである。図１２は、位置情報データベース２１３のデータ例を示す図である。
【００４９】
同図に示すように、位置情報データベース２１３は、カードリーダ番号１２０１と、所在地都道府県１２０２と、所在地市１２０３と、所在地町名１２０４の項目よりなる。
【００５０】
例えば、同図の場合、番号１のデータは、カードリーダが１０００−３３３２−２２２０−３３３の、所在地都道府県は東京都、所在地市は江戸川区、所在地町名は東葛西である。
【００５１】
図３は、企業サーバ１０３の詳細図である。
企業サーバ１０３は、同図に示すように、購入情報認識部３０１と、公費利用判定部３０２と、判別結果送信部３０３と、出張予定更新部３０４と、経費予定更新部３０５と、企業別利用案件一覧受信部３０５、予定情報送信部３０７を有し、格納情報（ＤＢ）として出張予定データベース３０８、経費予定データベース３０９を有する。
【００５２】
購入情報認識部３０１は、カード処理サーバ１０１から送られてきた購入品などの決済金額、決済日、それに対応したカードの情報を読み込むためのものである。ここで、カードの情報には、カードＩＤの他に、カード保有者の情報、カード有効期限の情報が含まれる（先に述べたように、カードＩＤとカード保有者の情報やカード有効期限の対応関係がカード処理サーバ１０１に登録されていればカードＩＤだけでもよい）。
【００５３】
公費利用判定部３０２は、該当する購入品を企業カードにて決済可能であるか利用を判定するためのものである。
【００５４】
判別結果送信部３０３は、公費利用判定部３０２で判定した公費利用判定の結果を、カード処理サーバ１０１へ送信するためのものである。
【００５５】
出張予定更新部３０４は、企業内で発生する出張行動予定の登録、変更、削除を、出張予定データベース３０８へ更新するためのものである。
【００５６】
経費予定更新部３０５は、企業内で発生する経費利用予定の登録、変更、削除を、経費予定データベース３０９へ更新するためのものである。
【００５７】
企業別利用案件一覧受信部３０６は、カード処理サーバ１０１から送られてきた、期間ごと、または指定した時期の利用案件結果の一覧を受信するためのものである。
【００５８】
予定情報送信部３０７は、企業サーバ１０３にて登録されている出張予定データベース３０８および経費予定データベース３０９において、更新されている情報をカード処理サーバ１０１へ送信するためのものである。
【００５９】
出張予定データベース３０８は、出張の行動予定情報を格納するものである。図１３は、出張予定データベース３０８のデータ例を示す図である。
【００６０】
同図に示すように、出張予定データベース３０８は、利用者番号１３０１と、利用予定日１３０２と、利用予定金額１３０３と、利用予定用途１３０４と、利用日時１３０５と、利用金額１３０６と、按分企業比１３０７と、按分個人比１３０８の項目よりなる。
【００６１】
例えば、同図の場合、番号１のデータは、利用者番号１２３４５６７８９の人の、利用予定日は２００３年２月２１日、利用予定金額は１０００円、利用予定用途は電車、利用日時は２００３年２月２１日１０時１０分、利用金額は１０００円、按分企業比率が１００％、按分個人比率は０％である。
【００６２】
経費予定データベース３０９は、経費の利用予定情報を格納するものである。図１４は、経費予定データベース３０９のデータ例を示す図である。
【００６３】
同図に示すように、経費予定データベース３０９は、利用者番号１４０１と、利用予定日１４０２と、利用予定金額１４０３と、利用予定用途１４０４と、利用日時１４０５と、利用金額１４０６と、按分企業比１４０７と、按分個人比１４０８の項目よりなる。
【００６４】
例えば、同図の場合、番号１のデータは、利用者番号１２３４５６７８９の人の、利用予定日は２００３年４月２６日、利用予定金額は５０００円、利用予定用途は接待、利用日時は２００３年４月２６日１６時００分、利用金額は５０００円、按分企業比率が９０％、按分個人比率は１０％である。
【００６５】
図４は、カード利用時における、カードリーダ１０２、カード処理サーバ１０１、企業サーバ１０３、およびカード管理サーバ１０４間のタイムチャートである。
【００６６】
最初にカードリーダ１０２からカード処理サーバ１０１に、カードＩＤ，それに対応した問合せ日時、カードリーダＩＤ（カードリーダの設置場所を示す）、問合せ金額（購入品などの決済金額の情報）等が明確になる情報が送信されると（Ｓ４０１）、カード処理サーバ１０１では、登録されている利用者の所属する企業（利用者情報データベース２０９参照）、利用案件（利用案件一覧データベース２１２参照）との整合性の判別を行う（Ｓ４０２）。
【００６７】
判別の結果、利用者の所属する企業、利用案件との整合性が確認できれば、後述する企業別契約カード会社や法人カード番号判別を行う（Ｓ４０６）。
【００６８】
判別の結果、利用者の所属する企業、利用案件との整合性が確認できない場合は、さらに詳細な情報を企業サーバ１０３に問い合わせる。例えば按分比率、利用案件内容、利用者等に関する問合せが必要である場合は、企業サーバ１０３に問合せをする（Ｓ４０３）。
【００６９】
企業サーバ１０３では、登録されている利用者の情報、出張予定の情報（出張予定データベース３０８参照）、経費予定の情報（経費予定データベース３０９参照）との整合性の判別を行い（Ｓ４０４）、その結果をカード処理サーバ１０１へ送信する（Ｓ４０５）。
【００７０】
カード処理サーバ１０１では、登録されている企業別契約カード会社や、企業の法人カード番号を判別して（Ｓ４０６）、その結果、購入品などの決済金額の情報をカード管理サーバ１０４へ送信する（Ｓ４０７）。
【００７１】
また、按分比率から、必要であれば、登録されている個人別契約カード会社や個人の利用カード番号を判別して（Ｓ４０８）、その結果、購入品などの決済金額の情報をカード管理サーバ１０４へ送信する（Ｓ４０９）。
【００７２】
カード管理サーバ１０４では、照会処理を実施する（Ｓ４１０）。照会処理とは、当該購入品を、カード決済する処理である。その結果、カード処理サーバ１０１へ照会を終了した旨を送信する（Ｓ４１１）。結果を送信する先は、カード処理サーバ１０１ではなくカードリーダ１０２でもよい。
【００７３】
図５は、カード処理サーバ１０１のフローチャートである。
カード処理サーバ１０１は、同図に示すように、まず最初に、カードリーダ１０２からの問合せ（データの受信）を受ける（Ｓ５０１）。
【００７４】
次に、その問い合わせで利用されているカードが特殊カードかどうかを判別する（Ｓ５０２）。ここで特殊カードとは、複数の支払口座を有し、決済対象の内容によって決済に利用する支払口座を異ならせるようにしたカードであり、あらかじめ企業サーバ１０３から登録され、企業が特定された任意のカードである。
【００７５】
判別（Ｓ５０２）が肯定（Ｓ５０３）であれば（特殊カードであれば）、その特殊カードの用途判別（Ｓ５０５）へ進む。判別（Ｓ５０２）が否定（Ｓ５０４）であれば（特殊カードでなければ）、個人決済の通常の処理（Ｓ５０９）に進む。その後、個人決済の処理が完了した旨の受信を待つ（Ｓ５１７）。
【００７６】
ここで個人決済の通常の処理とは、当該個人が契約している決済処理であり、対応するカード会社での決済処理に任せるためのものである。これはあらかじめ、各個人が、カード会社と契約するものである。
【００７７】
特殊カードの用途判別（Ｓ５０５）では、決済対象の内容（会社の出張の経費か個人的な経費かなど）に基づいて、企業別契約カード会社にて処理するか、個人別系カード会社にて処理するかを判別する。
【００７８】
用途判別（Ｓ５０５）の結果が肯定（Ｓ６０６）であれば、企業サーバ（１０３）へ問合せの必要性の判別（Ｓ５０８）へ進む。企業サーバ１０３へ問合せの必要性判別（Ｓ５０８）では、購入情報から、企業サーバ１０３へさらに詳細な情報の問合せをする必要があるか判別する。
【００７９】
用途判別（Ｓ５０５）の結果が否定（Ｓ５０７）であれば、個人決済（Ｓ５０９）の処理に進む。例えば、北海道への出張が予定されていた場合に、九州のホテルでカードを提示した場合には個人口座による決済処理となる。
【００８０】
企業サーバ（１０３）へ問合せの必要性の判別（Ｓ５０８）が肯定（Ｓ５１０）であれば、企業サーバ１０３へ問合せ（Ｓ５１１）する。例えば、北海道へ出張した場合の例で説明すると、宿泊ホテルのラウンジで使った費用を企業口座から決済してよいかどうかなど判断が明確でない場合には企業サーバ１０３に問い合わせる。その後、問合せ結果の受信待ち（Ｓ５１２）へ進む。受信した後、その購入情報における按分計算（Ｓ５１３）へ進む。
【００８１】
企業サーバ（１０３）へ問合せの必要性の判別（Ｓ５０８）の結果が否定（Ｓ５０９）であれば、例えば懸賞金の範囲内の支払の場合や、決められた金額（例えば５０００円）未満の場合には無条件で支払可にしてある場合などには企業サーバに問い合わせる必要はなく、直接按分計算（Ｓ５１３）へ進む。按分計算の処理（Ｓ５１３）では、当該購入情報から、企業別契約カードと個人カードで支払う割合（按分）を、図１１の利用案件一覧データベース（２１２）から取得して、企業決済金額および個人決済金額を計算する。
【００８２】
なお、按分は比率だけではなく、例えば一万円までは企業別契約カードで支払い、一万円の超えた場合はその超えた金額を個人カードで支払うというように直接金額を指定して按分する場合もある。
【００８３】
その後、ポイント加算の処理（Ｓ５１４）へ進む。ポイント加算の処理（Ｓ５１４）では、企業決済金額、および個人決済金額から、カードに付随するポイントを計算して加算する。なお、ポイントは、企業カードのみに加算、または企業カードおよび個人カードそれぞれに加算、または個人カードのみに加算することがある。
【００８４】
ポイント加算後、結果格納（Ｓ５１５）へ進む。結果格納（Ｓ５１５）では、当該購入情報を、図１１に示した如き利用案件一覧データベース（２１２）に格納する。
【００８５】
その後、決済処理（Ｓ５１６）へ進む。ここで決済の処理とは、当該企業および個人が契約している決済処理であり、対応するカード会社での決済処理に任せるためのものである。これはあらかじめ、各企業および各個人が、カード会社と個別に契約するものである。
【００８６】
その後、決済処理が完了した旨の受信を待つ（Ｓ５１７）。その結果を受信後、カードリーダ１０２へ伝票出力依頼（Ｓ５１８）を送信する。なお、伝票出力は、企業カード用伝票と個人用伝票の２枚、または複数枚出力されることもある。
【００８７】
図６は、企業サーバ１０３のフローチャートである。
企業サーバ１０３は、同図に示すように、まず最初に、カード処理サーバ１０１から企業サーバ１０３へ詳細情報の問合せを受ける（Ｓ６０１）。その結果、検索、解析の処理（Ｓ６０２）へ進む。検索、解析の処理（Ｓ６０２）では当該問合せ購入情報が、出張予定表データベース３０７、および経費予定データベース３０８に登録されているか解析する。
【００８８】
解析した結果、企業決済の必要性の判別（Ｓ６０３）へ進む。企業決済の必要性の判別（Ｓ６０３）は、検索、解析（Ｓ６０２）で、該当の問合せ購入情報が解析出来たか、出来なかったかの結果を用いて判別される。判別（Ｓ６０３）が肯定（Ｓ６０４）であれば、企業カード決済可能通知（Ｓ６０６）へ進む。
【００８９】
企業カード決済可能通知（Ｓ６０６）では、カード処理サーバ（１０１）へ、当該問合せ購入情報は登録している企業カードにて決済可能であること通知をする。
【００９０】
企業決済の必要性の判別（Ｓ６０３）が否定（Ｓ６０５）であれば、企業カード決済不可能通知（Ｓ６０７）へ進む。企業カード決済不可能通知（Ｓ６０７）では、カード処理サーバ（１０１）へ、当該問合せ購入情報は登録している企業カードで決済するのは不可能であり、個人カードから決済すべきことを通知する。例えば、北海道への出張が予定されていた場合に、九州のホテルでカードを提示した場合、あるいは、明らかに個人的使用の商品の購入の場合には個人口座による決済処理となる。
【００９１】
図７は、カード処理サーバ１０１のデータベース更新のフローチャートである。
同図に示すように、まず最初に、企業サーバ１０３から、カード処理サーバ１０１へ更新問合せ情報を受ける（ステップＳ７０１）。ここで更新問合せ情報とは、企業カードを新たに利用する者の情報、利用案件予定の情報、個人カードの情報、カードリーダ端末の情報等である。
【００９２】
次に、問合せの中に該当する更新情報があるか判別する（Ｓ７０２）。判別（Ｓ７０２）が肯定であれば（Ｓ７０３）、更新情報選別処理（Ｓ７０５）へ進む。更新情報選別の処理とは、更新する情報によって、更新先のデータベースを選定するためのものである。
【００９３】
更新先のデータベースとは、利用者情報でデータベース２０９、企業情報データベース２１０、個人情報データベース２１１、利用案件一覧データベース２１２、位置情報データベース２１３が含まれる。その結果、該当するデータベースへ情報を更新する（Ｓ７０６）。
【００９４】
なお、カード処理サーバの処理として図５に示した実施形態の説明では、Ｓ５０８において企業サーバへの問合せの必要性の判別を行い、Ｓ５１３において按分計算を行い、Ｓ５１４においてポイント加算を行う例を示したが、あらかじめ企業サーバへの問合せが不要であることがわかっている場合や、按分計算やポイント加算を必要としない場合はこれらの処理ステップを設ける必要がないことはいうまでもない。
【００９５】
また、上記説明では、カード処理サーバ１０１は、カードリーダからカードＩＤを受信して、ＤＢを参照して該カードＩＤに対応する各種情報を取得する例を説明したが、カードが大容量の情報を記憶できるＩＣカードなどの場合には、これら各種情報をあらかじめカードに記憶しておき、これらの情報をカードリーダで読み取ってカード処理サーバ１０１に送信するようにしてもよい。
【００９６】
また、複数の支払口座の例としては、例えば、企業を含む団体の口座と個人の口座、両親いずれかの口座と子供の口座、報奨金の振込み口座と個人の口座のいずれかの口座の組などが考えられるがこれに限るものではない。
【００９７】
例えば、定期券の購入代金を会社決済処理で対応することができる。すなわち、定期券購入を各人が所有しているカードを利用し、上述した仕組みにより、定期券代金を会社の口座を用いて決済することも可能である。
【００９８】
また、図５および図７を用いて説明したカード処理サーバの処理をプログラムコード化し、例えばＣＤ−ＲＯＭなどの記録媒体に格納して頒布したり、インターネットを介して利用者ＰＣにダウンロードさせることも可能である。
【００９９】
上記本発明の実施形態によれば、クレジット機能を有するカード自体を変更せずに、そのカードを処理するサーバ側で、そのカードにさまざまな付加機能を加えることができる。
【０１００】
例えば、企業においては出張清算については、あらかじめ、当該社員のカードをカード処理サーバ登録し、期間、場所、金額などを登録しておくことで、あるいは問いかけがあったときに認証を行い、その費用分を当該カードの決済にあてることができる。この場合は、指定場所以外での支払いや、指定金額より超える場合は、企業の決済からはずれて当該人が従来指定している決済処理にゆだねるものとすることができる。
【０１０１】
また、さらに、北海道旅行１００万円の懸賞金を当選者の任意のクレジットカードに該当させることもできる。このときは、そのカードで、北海道での買い物や宿泊などに１００万円までを懸賞金のスポンサーの決済にすることもできる。あるいは、同様に、指定ホテルやその期限を特定することが可能になり、付加価値の高いクレジットカードの利用形態を提供できる効果がある。
【０１０２】
【発明の効果】
本発明によれば、複数の支払口座を持たせたカード（一般には媒体）に対し、決済対象の条件（例えば、特定の期間、場所、購入する商品、宿泊施設への支払い、交通費などの全て、あるいは、それらの組み合わせ）によって決められる支払口座を利用して決済処理することが可能となる。また、案件（例えば、食費）によっては決済額を複数の支払口座で指定された割合で分担させることも可能となる。
【図面の簡単な説明】
【図１】本発明に係る決済処理システムの一実施形態を説明するための全体構成図である。
【図２】本発明に係るカード処理サーバの詳細図である。
【図３】本発明に係る企業サーバの構成図である。
【図４】カード利用時におけるカードリーダ、カード処理サーバ、企業サーバ、およびカード管理サーバ間のタイムチャートである。
【図５】本発明に係るカード処理サーバのフローチャートである。
【図６】本発明に係る企業サーバのフローチャートである。
【図７】本発明に係るカード処理サーバのデータベース更新のフローチャートである。
【図８】本発明に係る利用者情報データベースのデータ例を示す図である。
【図９】本発明に係る企業情報データベースのデータ例を示す図である。
【図１０】本発明に係る個人情報データベースのデータ例を示す図である。
【図１１】本発明に係る利用案件一覧データベースのデータ例を示す図である。
【図１２】本発明に係る位置情報データベースのデータ例を示す図である。
【図１３】本発明に係る出張予定データベースのデータ例を示す図である。
【図１４】本発明に係る経費予定データベースのデータ例を示す図である。
【符号の説明】
１０１…カード処理サーバ、１０２…カードリーダ、１０３…企業サーバ、１０４…カード管理サーバ、１０５…ネットワーク、
２０１…購入情報認識部、２０２…購入情報送信部、２０３…購入情報別判定結果受信部、２０４…企業別契約カード会社認識部、２０５…個人別契約カード会社認識部、２０６…企業別システム情報更新部、２０７…企業別利用案件一覧作成部、２０８…位置情報認識部、２０９…利用者情報データベース、２１０…企業情報データベース、２１１…個人情報データベース、２１２…利用案件一覧データベース、２１３…位置情報データベース、
３０１…購入情報認識部、３０２…公費利用判定部、３０３…判別結果送信部、３０４…出張予定更新部、３０５…経費予定更新部、３０６…企業別利用案件一覧受信部、３０７…予定情報送信部、３０８…出張予定データベース、３０９…経費予定データベース。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a technique for performing payment processing using a medium such as a card holding at least information (card ID) for identifying a card, and in particular, a plurality of different payment accounts are associated with the medium, A payment processing method capable of performing payment processing using a payment account determined by the content of the payment object among a plurality of different payment accounts, a card processing server therefor, and a program for realizing the processing of the card processing server About.
[0002]
[Prior art]
2. Description of the Related Art Conventionally, a settlement method that uses a credit card to make a settlement when purchasing a product or staying is well known and is a popular settlement method. Further, in recent years, in consideration of the convenience of users, there is also known a method in which information for a plurality of payment methods is given to a single card and payment is performed using a specified payment method using this card. .
[0003]
For example, in Japanese Patent Laid-Open No. 2002-83145 (Patent Document 1), one card is provided with a credit card function of a plurality of card companies, or a plurality of settlement accounts are associated with one card and stored. In addition, the card company and the settlement account used according to the designation of the user are described.
[0004]
Japanese Patent Laid-Open No. 2002-63374 (Patent Document 2) orders a card to have a plurality of credit card functions and which credit card function is used to settle the product when purchasing the product. Which is determined by the person.
[0005]
Furthermore, Japanese Patent Application Laid-Open No. 11-2559577 (Patent Document 3) discloses a plurality of payment functions (electronic wallet use function, credit use function, point data use function, point data use) on a single payment card having an IC chip. Etc.), a payment processing device is described in which priorities are set in advance for these multiple payment functions, and payment is made according to the priorities at the time of payment, and there is a shortage of balance at the time of payment. In the case of payment, it is also described that payment is made in cash.
[0006]
[Patent Document 1]
JP 2002-83145 A
[Patent Document 2]
JP 2002-63374 A
[Patent Document 3]
Japanese Patent Laid-Open No. 11-2559577
[0007]
[Problems to be solved by the invention]
As described above, the above prior art has a plurality of credit card functions on a single card, and the user or the orderer designates the credit card function to be settled at the time of settlement. Or use a single card with multiple payment functions such as an electronic wallet use function, credit use function, point data use function, point data use function, and prioritize them in advance. Set up and use the payment function according to the set priority at the time of payment, and use one payment account of multiple payment accounts using one credit card These conventional technologies are convenient in that they can be settled by payment, but these prior arts are determined by a payment account specified by the user or a preset priority. It is intended to settlement from the account, use period, use location, merchandise to buy, not at all consideration is given to determine the payment account by the payment and transportation costs, such as the contents of the settlement subject to a business trip at the time of accommodation.
[0008]
Therefore, when paying with a single credit card with multiple payment accounts, the user does not specify the payment account one by one, but the accommodation expenses, food expenses, and transportation during the business trip (the period and location are specified) Expenses etc. are settled in the payment account of the company (company), products purchased for private use are settled in the personal payment account (group (company) / individual account), or school supplies and books for learning are fathers It was not possible to settle with a payment account in the name of a child for a product purchased by a child (or mother) for payment as a hobby.
[0009]
It is an object of the present invention to set a condition (for example, a specific period, a place, a product to be purchased, a payment to an accommodation facility, a transportation fee, etc.) for a card (generally a medium) having a plurality of payment accounts. Settlement processing using payment accounts determined by all or a combination of them), and depending on the project (for example, food expenses), it is possible to share the payment amount at a ratio specified by multiple payment accounts And a card processing server therefor, and a program for realizing the processing of the card processing server.
[0010]
[Means for Solving the Problems]
In order to achieve the above object, a settlement processing method according to the present invention is a settlement processing method in which settlement is performed by a plurality of payment accounts, and a card ID that identifies the card from cards associated with the plurality of payment accounts. A card reader using a card reader, a step of capturing payment information including an amount of payment due to purchase of goods or use of facilities, a card reader ID corresponding to a plurality of payment accounts, and a card reader ID for identifying the card reader The correspondence relationship between the installation location of the card reader and the correspondence relationship between the payment account and the payment conditions are retained, and the correspondence relationship is referred to based on the captured card ID, payment information, and the card reader ID. One or more payment accounts to be used for settlement are determined from a plurality of payment accounts, and each of the determined one or more payment accounts is determined. Determining the amount to be settled in, it is characterized by a step of payment amounts that the determined by one or more payment account, which is the determination.
[0011]
Correspondence relationship between a card ID for identifying a card and a plurality of payment accounts, a correspondence relationship between a card reader ID for identifying a card reader and the installation location of the card reader, and a correspondence relationship between a payment account and payment conditions A card ID captured by a card reader from a card associated with a plurality of payment accounts, payment information including an amount of payment due to product purchase or facility use, and the card reader ID, Referring to the correspondence holding means, determine one or more payment accounts to be used for settlement from the plurality of payment accounts, and determine an amount to be settled in each of the determined one or more payment accounts. It is characterized by having steps.
[0012]
In addition, when one or more payment accounts to be used for settlement cannot be determined from the plurality of payment accounts by referring to the correspondence relationship holding means, there is a step of inquiring a company server for more detailed information. Yes.
[0013]
The correspondence relationship holding means further holds a ratio of assigning a total payment amount to each of a plurality of payment accounts, and determining the amount to be settled in each of the one or more determined payment accounts, The ratio is referred to.
[0014]
The card processing server according to the present invention includes a correspondence relationship between a card ID for identifying a card and a plurality of payment accounts, a correspondence relationship between a card reader ID for identifying a card reader and the installation location of the card reader, and a payment account and payment conditions. Correspondence relation holding means for holding correspondence relations, card ID taken by a card reader from cards associated with a plurality of payment accounts, payment information including an amount of payment due to product purchase or facility use, and the card reader ID is taken in, one or more payment accounts used for settlement are discriminated from the plurality of payment accounts with reference to the correspondence holding means, and settlement is performed in each of the discriminated one or more payment accounts. It is characterized by having a means for determining the amount of money.
[0015]
In addition, the program according to the present invention includes a correspondence relationship between a card ID and a plurality of payment accounts, a correspondence relationship between a card reader ID and the installation location of the card reader, and a correspondence relationship between contents to be settled and a payment account. A program executed by a card processing server that includes a holding means and determines one or more payment accounts for settlement and an amount to be paid to the accounts, and a card reader from cards associated with a plurality of payment accounts Payment processing including the card ID acquired in step S3, payment information including the amount of payment due to purchase of goods or use of the facility, and the card reader ID, and payment from the plurality of payment accounts with reference to the correspondence holding means Processing for determining one or more payment accounts to be used, and settlement with each of the determined one or more payment accounts. It is intended to implement the process of determining the amount of money.
[0016]
DETAILED DESCRIPTION OF THE INVENTION
An embodiment of the present invention will be described in detail with reference to the drawings.
FIG. 1 is an overall configuration diagram for explaining an embodiment of a payment processing system according to the present invention.
[0017]
As shown in the figure, in the present embodiment, a card processing server 101, a card reader 102 installed in a hotel, a station, a convenience store, and various other places, a plurality of card management servers 104 (many of these are A plurality of company servers 103 are connected via a network 105.
[0018]
The card reader 102 reads card information (at least a card ID, which may include other information such as a card expiration date) of a card (credit card or the like) issued by a card company, and uses the card information as the card. Card reader information of the reader 102 (including at least a card reader ID that identifies the card reader. Other information such as the installation location of the card reader may be included), for example, purchase date / time, purchased product name, and purchase The information is sent to the card processing server 101 together with product purchase information such as a price, and further for receiving information from the card processing server 101 and printing out payment information.
[0019]
In addition, detailed information of the card (for example, the expiration date of the card) corresponding to the card ID and detailed information of the card reader (for example, installation location of the card reader) corresponding to the card reader ID are sent to the card processing server described later. If registered, the card information and card reader information transmitted from the card reader 102 to the card processing server 101 need only be a card ID and a card reader ID. The embodiment in this case will be described below.
[0020]
The company server 103 (shown in detail in FIG. 3) registers a specific card (registers a plurality of payment accounts corresponding to the card ID for uniquely identifying the card), and further supports the card. This is for transmitting and registering the contents of the settlement target (information such as period, place, purpose of use, etc.) to be settled using the registered payment account to the card processing server 101.
[0021]
There are one or more card processing servers 101 (details are shown in FIG. 2). Based on the card information (at least the card ID) acquired from the card reader 102, the card has received a registration request from the company server 103 in advance. Check that it is correct.
[0022]
As a result of the confirmation, the card has been requested to be registered, but it is not possible to determine which payment account and how much distribution can be settled with only the registered information, and more detailed information is required. In this case, the company server 103 is inquired and necessary information is exchanged.
[0023]
When new information is obtained from the company server 103 and a payment account to be settled is determined, the payment processing of the card is transmitted to the card management server 104 of each card company, and information from the card company server 103 is also transmitted. receive.
[0024]
The card processing server 101 may include the card reader 102, and the card processing server 101 may include the card management server 104 (or the card management server 104 may include the card processing server 101). Good).
[0025]
FIG. 2 is a detailed view of the card processing server 101.
As shown in the figure, the card processing server 101 includes a purchase information recognition unit 201, a purchase information transmission unit 202, a purchase information determination result reception unit 203, a company-specific contract card company recognition unit 204, and an individual contract card. It has a company recognition unit 205, a company-specific system information update unit 206, a company-specific use case list creation unit 207, and a position information recognition unit 208.
[0026]
As stored information (DB), a user information database 209, a company information database 210, a personal information database 211, a use case list database 212, and a position information database 213 are provided.
[0027]
The purchase information recognition unit 201 reads payment amount information (purchase price) such as a purchased item sent from the card reader 102 and corresponding card information (at least a card ID). The card information may include the expiration date, card issuer information, and cardholder information, but as described above, the card ID, expiration date, card issuer information, and cardholder information. If the correspondence relationship is stored, only the card ID may be used.
[0028]
The purchase information transmission unit 202 is for transmitting the information on the payment amount and the information on the payment card regarding the purchased item to the company server 103 or the card management server 104 (detailed description of the flow of FIG. 4 described later). checking)
[0029]
The purchase information determination result receiving unit 203 is for receiving a result of determining from the company server 103 whether or not settlement of the corresponding purchased item can be carried out with the company card.
[0030]
The company-specific contract card company recognition unit 204 is for recognizing registered company card information from the card information sent from the card reader 102.
[0031]
The individual contract card company recognition unit 205 is for recognizing registered personal card information from the card information sent from the card reader 102.
[0032]
The company-specific system information update unit 206 is for updating information related to system use sent from the company server 103. Information related to the use of the system includes company card user update information, personal card user update information, business trip schedule information, expense use information, and the like (see the description of the database update flow of the card processing server in FIG. 7 described later). .
[0033]
The company-specific use case list creation unit 207 also updates information on actual card payments to the use case list information (use case list DB 212) registered by the company.
[0034]
The position information recognition unit 208 is for reading a position information database 213 such as card reader terminal information sent from the card reader 102, payment date and time information such as purchased items, and card reader terminal position information. . (As described above, if the card reader ID and the information related to the card reader and the correspondence between the installation locations are registered in the card processing server 101, only the card reader ID needs to be read from the card reader 102.)
[0035]
The card processing server 101 also recognizes whether or not the card has been used illegally based on the settlement date and time of the purchased item and the information in the position information database.
[0036]
The user information database 209 stores information on users who use the system. FIG. 8 is a diagram illustrating an example of data in the user information database 209.
[0037]
As shown in the figure, the user information database 209 includes items of a user number 801, an affiliated company number 802, an available start date / time 803, and a use end date / time 804.
[0038]
For example, in the case of the figure, the data of number 1 is the user number 123456789, the affiliated company number is 1001-2345-1234, and the available start date and time as this user information is July 23, 2003 11 Time 22 minutes, use end date and time is December 31, 2008 23:59.
[0039]
The company information database 210 stores information on companies that use the system. FIG. 9 is a diagram illustrating a data example of the company information database 210.
[0040]
As shown in the figure, the company information database 210 includes a company number 901, a corporate corporation card number 902, a contract card company number 903, a contract card company name 904, an available start date 905, and a use end date 906. And an item of a company name 907 and a point 908 given by purchasing a product.
[0041]
For example, in the figure, the data of the number 1 is the company number 1001-2345-1234, the corporate corporation card number is 1000-1000-1000-1001, the contract card company number is 10001, and the contract card company name is x. Xx, the use start date and time is 0:00 on April 1, 2000, the use end date and time is 23:59 on March 31, 2008, the company name is △△ manufactory, and the point is 700,006 points.
[0042]
The personal information database 211 stores a relationship between a user who uses the system and a company card. FIG. 10 is a diagram illustrating a data example of the personal information database 211.
[0043]
As shown in the figure, the personal information includes a user number 1001, a personal card number 1002, a contract card company number 1003, a contract card company name 1004, an available start date and time 1005, a card expiration date 1006, It consists of an item of points 1007 given by merchandise purchase or the like.
[0044]
For example, in the case of the figure, the data of number 1 is the person number 12456789, the personal card number is 4567-1234-1234-1234, the contract card company number is 10001, the contract card company name is xxx The possible start date and time is 03:00 on July 23, 2001, the card usage period is December 2006, and the points are 13 points.
[0045]
The use case list database 212 stores information settled using a card. FIG. 11 is a diagram illustrating an example of data in the use case list database 212.
[0046]
As shown in the figure, the use case list database 212 includes a company number 1101, a user number 1102, a use amount 1103, a use date and time 1104, a company proration ratio 1105, an individual proration ratio 1106, and a company. It consists of items of a settlement amount 1107 and a personal settlement amount 1108.
[0047]
For example, in the case of the figure, the data of the number 1 is the company with the company number 1001-2345-1234 and the person with the user number 12345789 has the usage amount of 1000 yen and the usage date is February 21, 2003 at 20:00. The prorated company ratio is 100%, the apportioned individual ratio is 0%, the corporate settlement amount is 1,000 yen, and the individual settlement amount is 0 yen.
[0048]
The position information database 213 stores position information of the store where the card reader is installed. FIG. 12 is a diagram illustrating a data example of the position information database 213.
[0049]
As shown in the figure, the location information database 213 includes items of a card reader number 1201, a location prefecture 1202, a location city 1203, and a location town name 1204.
[0050]
For example, in the case of the figure, the data of No. 1 is that the card reader is 1000-3332-2220-333, the location prefecture is Tokyo, the location city is Edogawa-ku, and the location town name is Tokasai.
[0051]
FIG. 3 is a detailed view of the company server 103.
As shown in the figure, the company server 103 includes a purchase information recognition unit 301, a public expense use determination unit 302, a determination result transmission unit 303, a business trip schedule update unit 304, an expense plan update unit 305, and a company-specific use. It has a case list receiving unit 305 and a schedule information transmitting unit 307, and has a business trip schedule database 308 and an expense schedule database 309 as stored information (DB).
[0052]
The purchase information recognition unit 301 is for reading the payment amount, the payment date, and the card information corresponding to the purchase amount sent from the card processing server 101. Here, in addition to the card ID, the card information includes card holder information and card expiration date information (as described above, the card ID and card holder information and the card expiration date information). If the correspondence is registered in the card processing server 101, only the card ID may be used).
[0053]
The public expense use determination unit 302 is for determining whether or not the purchase item can be settled with a company card.
[0054]
The discrimination result transmission unit 303 is for transmitting the result of the public expenditure usage determination determined by the public expenditure usage determination unit 302 to the card processing server 101.
[0055]
The business trip schedule update unit 304 is for updating the business trip schedule database 308 to register, change, and delete a business trip action schedule that occurs in the company.
[0056]
The expense schedule update unit 305 is used to update the expense schedule database 309 with registration, change, and deletion of the expense use schedule generated in the company.
[0057]
The company-specific use case list receiving unit 306 is for receiving a list of use case results sent from the card processing server 101 for each period or at a specified time.
[0058]
The schedule information transmission unit 307 is for transmitting information updated in the business trip schedule database 308 and the expense schedule database 309 registered in the company server 103 to the card processing server 101.
[0059]
The business trip schedule database 308 stores business trip action schedule information. FIG. 13 is a diagram illustrating an example of data in the business trip schedule database 308.
[0060]
As shown in the figure, the business trip schedule database 308 includes a user number 1301, a scheduled usage date 1302, a scheduled usage amount 1303, a scheduled usage usage 1304, a usage date and time 1305, a usage amount 1306, and an apportioned company ratio. 1307, and an item of prorated personal ratio 1308.
[0061]
For example, in the case of the figure, the data of number 1 indicates that the user number 12345789 has a scheduled use date of February 21, 2003, a scheduled usage amount of 1000 yen, a scheduled usage for a train, and a usage date of 2003. At 10:10 on February 21, the usage amount is 1,000 yen, the prorated company ratio is 100%, and the prorated personal ratio is 0%.
[0062]
The expense schedule database 309 stores expense utilization schedule information. FIG. 14 is a diagram illustrating an example of data in the expense schedule database 309.
[0063]
As shown in the figure, the expense schedule database 309 includes a user number 1401, a scheduled use date 1402, a scheduled use amount 1403, a scheduled use application 1404, a use date and time 1405, a use amount 1406, and an apportionment ratio. 1407, and an apportioned individual ratio 1408.
[0064]
For example, in the case of the figure, the data of No. 1 is the person whose user number is 12345789, the expected use date is April 26, 2003, the expected use amount is 5000 yen, the expected use is entertainment, and the use date is 2003 At 16:00 on April 26, the usage amount is 5000 yen, the prorated company ratio is 90%, and the prorated personal ratio is 10%.
[0065]
FIG. 4 is a time chart among the card reader 102, the card processing server 101, the company server 103, and the card management server 104 when the card is used.
[0066]
First, the card reader 102 sends to the card processing server 101 the card ID, the inquiry date and time corresponding to the card ID, the card reader ID (indicating the installation location of the card reader), the inquiry amount (information on the payment amount of the purchased item, etc.), etc. Is transmitted (S401), the card processing server 101 is consistent with the registered company to which the user belongs (see the user information database 209) and the use case (see the use case list database 212). Is discriminated (S402).
[0067]
As a result of the determination, if the consistency with the company to which the user belongs and the use case can be confirmed, the company-specific contract card company and the corporate card number are determined (S406).
[0068]
As a result of the discrimination, if the consistency with the company to which the user belongs and the use case cannot be confirmed, the company server 103 is inquired for more detailed information. For example, when an inquiry regarding the apportionment ratio, the contents of the use case, the user, etc. is required, an inquiry is made to the company server 103 (S403).
[0069]
The company server 103 determines consistency with registered user information, business trip schedule information (see the business trip schedule database 308), and expense plan information (see the expense plan database 309) (S404). The result is transmitted to the card processing server 101 (S405).
[0070]
The card processing server 101 discriminates the registered company-specific contract card company and the corporate card number of the company (S406), and as a result, transmits information on the payment amount such as purchased goods to the card management server 104 ( S407).
[0071]
Further, from the apportionment ratio, if necessary, the registered individual contract card company and the personal use card number are discriminated (S408), and as a result, information on the settlement amount such as the purchased item is obtained from the card management server 104. (S409).
[0072]
The card management server 104 performs an inquiry process (S410). The inquiry process is a process for making a card payment for the purchased item. As a result, the fact that the inquiry is finished is transmitted to the card processing server 101 (S411). The result may be sent to the card reader 102 instead of the card processing server 101.
[0073]
FIG. 5 is a flowchart of the card processing server 101.
As shown in the figure, the card processing server 101 first receives an inquiry (data reception) from the card reader 102 (S501).
[0074]
Next, it is determined whether or not the card used in the inquiry is a special card (S502). Here, the special card is a card having a plurality of payment accounts, and the payment account used for the payment varies depending on the contents of the payment target. Card.
[0075]
If the determination (S502) is affirmative (S503) (if it is a special card), the process proceeds to the use determination (S505) of the special card. If the determination (S502) is negative (S504) (if it is not a special card), the process proceeds to normal processing (S509) for personal settlement. After that, it waits for reception that the personal settlement processing is completed (S517).
[0076]
Here, the normal processing of personal payment is the payment processing contracted by the individual, and is for entrusting the payment processing at the corresponding card company. In this case, each individual makes a contract with a card company in advance.
[0077]
In the special card usage determination (S505), processing is performed by the company-specific contract card company based on the contents of the payment target (company business trip expense or personal expense, etc.), or by the individual card company Determine whether to process.
[0078]
If the result of the use determination (S505) is affirmative (S606), the process proceeds to determination of the necessity of inquiry to the company server (103) (S508). In the necessity determination of the inquiry to the company server 103 (S508), it is determined from the purchase information whether it is necessary to make an inquiry of more detailed information to the company server 103.
[0079]
If the result of the use determination (S505) is negative (S507), the process proceeds to personal settlement (S509). For example, if a business trip to Hokkaido is planned, and a card is presented at a hotel in Kyushu, the settlement process is performed using a personal account.
[0080]
If the determination of the necessity of inquiry to the enterprise server (103) (S508) is affirmative (S510), an inquiry is made to the enterprise server 103 (S511). For example, in the case of a business trip to Hokkaido, the company server 103 is inquired when it is not clear whether the expenses used at the hotel lounge can be settled from the company account. Thereafter, the process proceeds to waiting for reception of an inquiry result (S512). After the reception, the process proceeds to apportionment calculation (S513) in the purchase information.
[0081]
If the result of the determination of the necessity of inquiry (S508) to the company server (103) is negative (S509), for example, in the case of payment within the prize money range, or less than a predetermined amount (for example, 5000 yen) In the case where the payment is unconditional, it is not necessary to make an inquiry to the company server, and the process proceeds directly to the apportionment calculation (S513). In the apportionment calculation process (S513), from the purchase information, the proportion (proportional distribution) to be paid by the company-specific contract card and personal card is obtained from the use case list database (212) in FIG. Calculate the amount.
[0082]
In addition, the apportionment is not only a ratio, but for example, up to 10,000 yen can be paid with a company-specific contract card, and if it exceeds 10,000 yen, the amount exceeding that amount is paid with a personal card. In some cases.
[0083]
Thereafter, the process proceeds to point addition processing (S514). In the point addition process (S514), points associated with the card are calculated and added from the corporate settlement amount and the personal settlement amount. The points may be added only to the company card, added to each of the company card and the individual card, or added only to the individual card.
[0084]
After adding the points, the process proceeds to result storage (S515). In the result storage (S515), the purchase information is stored in the use case list database (212) as shown in FIG.
[0085]
Thereafter, the process proceeds to the settlement process (S516). Here, the payment process is a payment process contracted by the company and the individual, and is for entrusting the payment process to the corresponding card company. In this case, each company and each individual makes an individual contract with the card company.
[0086]
Thereafter, it waits for reception of the completion of the settlement process (S517). After receiving the result, a slip output request (S518) is transmitted to the card reader 102. Note that the slip output may be two or a plurality of corporate card slips and personal slips.
[0087]
FIG. 6 is a flowchart of the company server 103.
As shown in the figure, the company server 103 first receives a detailed information inquiry from the card processing server 101 to the company server 103 (S601). As a result, the process proceeds to search and analysis processing (S602). In the search and analysis process (S602), it is analyzed whether the inquiry purchase information is registered in the business trip schedule table database 307 and the expense schedule database 308.
[0088]
As a result of the analysis, the process proceeds to determination of the necessity for company settlement (S603). The necessity of corporate settlement (S603) is determined using the result of whether or not the corresponding inquiry purchase information can be analyzed in the search and analysis (S602). If the determination (S603) is affirmative (S604), the process proceeds to the notice of payment for company card (S606).
[0089]
In the corporate card settlement possible notification (S606), the card processing server (101) is notified that the inquiry purchase information can be settled with the registered corporate card.
[0090]
If the determination of the necessity for company payment (S603) is negative (S605), the process proceeds to the notice of company card payment impossible (S607). In the corporate card settlement impossible notification (S607), the card processing server (101) is notified that the inquiry purchase information cannot be settled with the registered corporate card and should be settled from the personal card. . For example, when a business trip to Hokkaido is scheduled, when a card is presented at a hotel in Kyushu, or when a product for personal use is clearly purchased, the settlement process is performed using a personal account.
[0091]
FIG. 7 is a flowchart of database update of the card processing server 101.
As shown in the figure, first, update inquiry information is received from the company server 103 to the card processing server 101 (step S701). Here, the update inquiry information is information on a person who newly uses a company card, information on a use case schedule, information on a personal card, information on a card reader terminal, and the like.
[0092]
Next, it is determined whether there is relevant update information in the inquiry (S702). If the determination (S702) is affirmative (S703), the process proceeds to update information selection processing (S705). The update information selection process is for selecting an update destination database based on information to be updated.
[0093]
The update destination database includes user information database 209, company information database 210, personal information database 211, use case list database 212, and position information database 213. As a result, information is updated to the corresponding database (S706).
[0094]
In the description of the embodiment shown in FIG. 5 as the processing of the card processing server, an example is shown in which the necessity of inquiry to the company server is determined in S508, the distribution calculation is performed in S513, and the point addition is performed in S514. However, it is needless to say that it is not necessary to provide these processing steps when it is known in advance that an inquiry to the company server is unnecessary, or when it is not necessary to perform proportional calculation or point addition.
[0095]
In the above description, the card processing server 101 receives the card ID from the card reader, and refers to the DB to acquire various information corresponding to the card ID. In the case of an IC card or the like that can store the information, these various types of information may be stored in the card in advance, and the information may be read by a card reader and transmitted to the card processing server 101.
[0096]
Examples of a plurality of payment accounts include, for example, a group account including a company and an individual account, a parent account and a child account, a reward transfer account and a personal account group. However, this is not a limitation.
[0097]
For example, a commuter pass purchase price can be dealt with by a company settlement process. That is, it is possible to use a card owned by each person to purchase a commuter pass and settle the commuter pass price using a company account by the above-described mechanism.
[0098]
Further, the processing of the card processing server described with reference to FIGS. 5 and 7 may be converted into a program code and stored in a recording medium such as a CD-ROM and distributed, or downloaded to a user PC via the Internet. Is possible.
[0099]
According to the embodiment of the present invention, various additional functions can be added to the card on the server side that processes the card without changing the card itself having the credit function.
[0100]
For example, in the case of a business trip settlement in a company, the card of the employee is registered in the card processing server in advance, and the period, place, amount, etc. are registered, or when there is an inquiry, the cost is charged. Can be used to pay for the card. In this case, payment outside the designated place, or if the amount exceeds the designated amount, it is possible to deviate from the company's payment and leave it to the payment process conventionally designated by the person.
[0101]
In addition, a prize money of 1 million yen for Hokkaido travel can be assigned to any credit card of the winner. In this case, you can use the card to make a sweepstakes sponsor's payment for up to 1 million yen for shopping or lodging in Hokkaido. Or similarly, it becomes possible to specify a designated hotel and its time limit, and there is an effect that it is possible to provide a use form of a credit card with high added value.
[0102]
【The invention's effect】
According to the present invention, for a card (generally a medium) having a plurality of payment accounts, conditions for settlement (for example, a specific period, a place, a product to be purchased, payment to an accommodation facility, transportation expenses, etc.) It is possible to perform settlement processing using a payment account determined by all or a combination thereof. Further, depending on the case (for example, food expenses), it is possible to share the settlement amount at a rate specified by a plurality of payment accounts.
[Brief description of the drawings]
FIG. 1 is an overall configuration diagram for explaining an embodiment of a payment processing system according to the present invention.
FIG. 2 is a detailed view of a card processing server according to the present invention.
FIG. 3 is a configuration diagram of a company server according to the present invention.
FIG. 4 is a time chart among a card reader, a card processing server, a company server, and a card management server when a card is used.
FIG. 5 is a flowchart of a card processing server according to the present invention.
FIG. 6 is a flowchart of a company server according to the present invention.
FIG. 7 is a flowchart of database update of the card processing server according to the present invention.
FIG. 8 is a diagram showing an example of data in a user information database according to the present invention.
FIG. 9 is a diagram showing a data example of a company information database according to the present invention.
FIG. 10 is a diagram showing an example of data in a personal information database according to the present invention.
FIG. 11 is a diagram showing a data example of a use case list database according to the present invention.
FIG. 12 is a diagram showing an example of data in a location information database according to the present invention.
FIG. 13 is a diagram showing a data example of a business trip schedule database according to the present invention.
FIG. 14 is a diagram showing an example of data in an expense schedule database according to the present invention.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 101 ... Card processing server, 102 ... Card reader, 103 ... Corporate server, 104 ... Card management server, 105 ... Network,
DESCRIPTION OF SYMBOLS 201 ... Purchase information recognition part, 202 ... Purchase information transmission part, 203 ... Decision result receiving part classified by purchase information, 204 ... Contract card company recognition part classified by company, 205 ... Contract card company recognition part classified by individual, 206 ... System information classified by company Update unit, 207 ... Company-specific use case list creation unit, 208 ... Location information recognition unit, 209 ... User information database, 210 ... Company information database, 211 ... Personal information database, 212 ... Usage case list database, 213 ... Location information Database,
DESCRIPTION OF SYMBOLS 301 ... Purchase information recognition part, 302 ... Public expense utilization determination part, 303 ... Discrimination result transmission part, 304 ... Business trip schedule update part, 305 ... Expense schedule update part, 306 ... Enterprise use case list reception part, 307 ... Schedule information transmission Department, 308 ... business trip schedule database, 309 ... expense plan database.

Claims

A payment processing method for performing payment by a plurality of payment accounts,
Using a card reader to capture a card ID identifying the card from cards associated with a plurality of payment accounts;
Capturing payment information including the amount that payment obligations are due to product purchases or facility use;
The correspondence between the card ID and a plurality of payment accounts, the correspondence between the card reader ID for identifying the card reader and the installation location of the card reader, and the correspondence between the payment account and the payment conditions are retained. Based on the information and the card reader ID, one or more payment accounts to be used for settlement are determined from the plurality of payment accounts with reference to each correspondence relationship, and the one or more payment accounts determined Determining the amount to be settled for each;
Paying the determined amount with the determined one or more payment accounts.

Correspondence relationship between a card ID for identifying a card and a plurality of payment accounts, a correspondence relationship between a card reader ID for identifying a card reader and the installation location of the card reader, and a correspondence relationship between a payment account and payment conditions are registered in the correspondence relationship holding means. And steps to
A card ID captured by a card reader from a card associated with a plurality of payment accounts, payment information including an amount of payment due to product purchase or facility use, and the card reader ID; With reference to the above, the method includes the step of determining one or more payment accounts used for settlement from the plurality of payment accounts, and determining an amount to be settled in each of the determined one or more payment accounts. Settlement processing method.

The settlement processing method according to claim 2,
In the case where one or more payment accounts used for settlement cannot be determined from the plurality of payment accounts by referring to the correspondence relationship holding means, there is a step of inquiring more detailed information to a company server. Payment processing method.

In the settlement processing method according to claim 1 or 2,
The correspondence relationship holding means further holds a ratio of assigning a total payment amount to each of a plurality of payment accounts, and determining the amount to be settled in each of the one or more determined payment accounts, A settlement processing method characterized by referring to the ratio.

Correspondence relationship between a card ID for identifying a card and a plurality of payment accounts, a correspondence relationship between a card reader ID for identifying a card reader and the installation location of the card reader, and a correspondence relationship holding means for retaining a correspondence relationship between a payment account and payment conditions When,
A card ID captured by a card reader from a card associated with a plurality of payment accounts, payment information including an amount of payment due to product purchase or facility use, and the card reader ID; With reference to the above, the apparatus has means for determining one or more payment accounts to be used for settlement from the plurality of payment accounts, and determining an amount to be settled in each of the determined one or more payment accounts. A card processing server.

Corresponding relationship between a card ID and a plurality of payment accounts, a correspondence relationship between a card reader ID and the installation location of the card reader, and a correspondence relationship holding means for holding a correspondence relationship between contents to be settled and a payment account are provided for settlement. A program executed by a card processing server to determine one or more payment accounts and the amount to be paid to those accounts,
A process for fetching a card ID captured by a card reader from a card associated with a plurality of payment accounts, payment information including an amount of payment due to product purchase or facility use, and the card reader ID; Referring to FIG. 4, the processing for determining one or more payment accounts used for settlement from the plurality of payment accounts, and the processing for determining the amount to be settled in each of the determined one or more payment accounts is realized. Program to do.