(57)【要約】【課題】複数の支払口座を持たせたカードに対し、決済対象の条件によって決められる一以上の支払口座を利用し、また、案件によっては決済額を複数の支払口座で指定された割合で分担させること。【解決手段】カードからカードＩＤを取り込むカードリーダ１０２と、商品購入または施設利用によって支払義務が生じる金額を含む支払情報を取り込む手段と、カードＩＤと複数の支払口座の対応関係，カードリーダＩＤと該カードリーダの設置場所の対応関係，および支払口座と支払条件の対応関係を保持する対応関係保持し、前記カードＩＤ，支払情報，カードリーダＩＤと上記各対応関係を参照し、複数の支払口座から決済に利用する一つ以上の支払口座、それぞれの口座で決済すべき金額を決定する手段（カード処理サーバ１０１）を有する。【選択図】      図１
2005004628.tif 000002
【特許請求の範囲】
【請求項１】
複数の支払口座によって決済を行う決済処理方法であって、
複数の支払口座に関連付けられているカードから該カードを特定するカードＩＤをカードリーダを用いて取り込むステップと、
商品購入または施設利用によって支払義務が生じる金額を含む支払情報を取り込むステップと、
カードＩＤと複数の支払口座の対応関係，カードリーダを特定するカードリーダＩＤと該カードリーダの設置場所の対応関係，および支払口座と支払条件の対応関係を保持し、前記取り込んだカードＩＤ，支払情報，および前記カードリーダＩＤに基づいて、前記各対応関係を参照して前記複数の支払口座から決済に利用する一つ以上の支払口座を判別し、該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定するステップと、
該判別された一つ以上の支払口座により前記決定された金額を決済するステップとを有することを特徴とする決済処理方法。
【請求項２】
カードを特定するカードＩＤと複数の支払口座の対応関係，カードリーダを特定するカードリーダＩＤと該カードリーダの設置場所の対応関係，および支払口座と支払条件の対応関係を対応関係保持手段に登録するステップと、
複数の支払口座に関連付けられているカードからカードリーダで取り込んだカードＩＤ，商品購入または施設利用によって支払義務が生じる金額を含む支払情報，および前記カードリーダＩＤとを取り込み、前記対応関係保持手段を参照して、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別し、該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定するステップを有することを特徴とする決済処理方法。
【請求項３】
請求項２記載の決済処理方法において、
前記対応関係保持手段を参照しても、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別できない場合に、さらに詳細な情報を企業サーバに問合せるステップを有することを特徴とする決済処理方法。
【請求項４】
請求項１または２記載の決済処理方法において、
前記対応関係保持手段は、さらに支払合計金額を複数の支払口座のそれぞれに割当てる割合を保持しており、前記判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定するステップは、前記割合を参照することを特徴とする決済処理方法。
【請求項５】
カードを特定するカードＩＤと複数の支払口座の対応関係，カードリーダを特定するカードリーダＩＤと該カードリーダの設置場所の対応関係，および支払口座と支払条件の対応関係を保持する対応関係保持手段と、
複数の支払口座に関連付けられているカードからカードリーダで取り込んだカードＩＤ，商品購入または施設利用によって支払義務が生じる金額を含む支払情報，および前記カードリーダＩＤとを取り込み、前記対応関係保持手段を参照して、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別し、該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定する手段を有することを特徴とするカード処理サーバ。
【請求項６】
カードＩＤと複数の支払口座の対応関係，カードリーダＩＤと該カードリーダの設置場所の対応関係，および決済対象の内容と支払口座の対応関係を保持する対応関係保持手段を具備し、決済を行う一つ以上の支払口座とそれらの口座に支払う金額を決定するカード処理サーバによって実行されるプログラムであって、
複数の支払口座に関連付けられているカードからカードリーダで取り込んだカードＩＤ，商品購入または施設利用によって支払義務が生じる金額を含む支払情報，および前記カードリーダＩＤとを取り込む処理、前記対応関係保持手段を参照して、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別する処理、および該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定する処理を実現するプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、少なくともカードを特定する情報（カードＩＤ）を保持するカードなどの媒体を用いて決済処理を行う技術に関し、特に該媒体に複数の異なる支払口座を対応付けておき、決済時に、該複数の異なる支払口座のうち決済対象の内容によって決められる支払口座を利用して決済処理することを可能にした決済処理方法、そのためのカード処理サーバ、該カード処理サーバの処理を実現するためのプログラムに関する。
【０００２】
【従来の技術】
従来、商品を購入したり、宿泊したりした場合に、クレジットカードを利用して決済する決済方法は周知であり、一般に普及している決済方法である。さらに近年、利用者の利便性を考慮し、一枚のカードに複数の決済方法のための情報を持たせておき、このカードを用いて指定された決済方法により決済するものも知られている。
【０００３】
例えば、特開２００２−８３１４５号公報（特許文献１）には、一枚のカードに複数のカード会社のクレジットカード機能を持たせたり、一枚のカードに複数の決済口座を対応づけて記憶しておいて、利用者の指定により利用するカード会社や決済口座を使い分けるようにしたものが記載されている。
【０００４】
また、特開２００２−６３３７４号公報（特許文献２）には、一枚のカードに複数のクレジットカード機能をもたせ、商品を購入時にどのクレジットカード機能を使って当該商品の決済をするかを注文者が決定するようにしたものが記載されている。
【０００５】
さらに、特開平１１−２５９５７７号公報（特許文献３）には、ＩＣチップを備えた一枚の決済カードに複数の決済機能（電子財布利用機能、クレジット利用機能、ポイントデータ利用機能、ポイントデータ利用機能など）を持たせ、これら複数の決済機能に予め優先順位を設定しておき、決済時にその優先順位に従って決済を行うようにした決済処理装置が記載されており、また決済時に残高不足が生じた場合には、現金で決済することも記載されている。
【０００６】
【特許文献１】
特開２００２−８３１４５号公報
【特許文献２】
特開２００２−６３３７４号公報
【特許文献３】
特開平１１−２５９５７７号公報
【０００７】
【発明が解決しようとする課題】
上記従来技術は、上述したように、一枚のカードに複数のクレジットカード機能を持たせておき、決済時に、決済するクレジットカード機能を利用者あるいは注文者が指定し、該指定したクレジットカード機能を用いて決済するようにしたり、あるいは、一枚のカードに電子財布利用機能、クレジット利用機能、ポイントデータ利用機能、ポイントデータ利用機能などの複数の決済機能を持たせ、それらに予め優先順位を設定しておき、決済時にその設定した優先順位に従った決済機能を用いて決済するようにしたものであり、一枚のクレジットカードを用いて複数の支払口座のうちの一つの支払口座を用いて決済できる点では便利であるが、これら従来技術は、利用者が指定した支払口座あるいは予め設定された優先順位によって決まる支払口座から決済するものであり、利用期間、利用場所、購入する商品、出張時の宿泊施設への支払いや交通費など決済対象の内容によって支払口座を決めることについては全く考慮していない。
【０００８】
そのため、複数の支払口座を持たせた一枚のクレジットカードを用いて決済する場合、利用者がいちいち支払口座を指定することなく、出張時（期間や場所が指定）の宿泊費や食費や交通費などは会社（企業）の支払口座で決済し、私用で購入した商品類は個人の支払口座で決済したり（団体（企業）／個人口座）、あるいは学用品や学習のための書籍は父親（または母親）の支払口座で決済し、子供が趣味のために購入した商品は子供名義の支払口座で決済するというようなことはできなかった。
【０００９】
本発明の目的は、複数の支払口座を持たせたカード（一般には媒体）に対し、決済対象の条件（例えば、特定の期間、場所、購入する商品、宿泊施設への支払い、交通費などの全て、あるいは、それらの組み合わせ）によって決められる支払口座を利用して決済処理すること、また、案件（例えば、食費）によっては決済額を複数の支払口座で指定された割合で分担させることが可能な決済処理方法、そのためのカード処理サーバ、該カード処理サーバの処理を実現するためのプログラムを提供することである。
【００１０】
【課題を解決するための手段】
上記目的を達成するために、本発明に係る決済処理方法は、複数の支払口座によって決済を行う決済処理方法であって、複数の支払口座に関連付けられているカードから該カードを特定するカードＩＤをカードリーダを用いて取り込むステップと、商品購入または施設利用によって支払義務が生じる金額を含む支払情報を取り込むステップと、カードＩＤと複数の支払口座の対応関係，カードリーダを特定するカードリーダＩＤと該カードリーダの設置場所の対応関係，および支払口座と支払条件の対応関係を保持し、前記取り込んだカードＩＤ，支払情報，および前記カードリーダＩＤに基づいて、前記各対応関係を参照して前記複数の支払口座から決済に利用する一つ以上の支払口座を判別し、該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定するステップと、該判別された一つ以上の支払口座により前記決定された金額を決済するステップとを有することを特徴としている。
【００１１】
また、カードを特定するカードＩＤと複数の支払口座の対応関係，カードリーダを特定するカードリーダＩＤと該カードリーダの設置場所の対応関係，および支払口座と支払条件の対応関係を対応関係保持手段に登録するステップと、複数の支払口座に関連付けられているカードからカードリーダで取り込んだカードＩＤ，商品購入または施設利用によって支払義務が生じる金額を含む支払情報，および前記カードリーダＩＤとを取り込み、前記対応関係保持手段を参照して、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別し、該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定するステップを有することを特徴としている。
【００１２】
また前記対応関係保持手段を参照しても、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別できない場合に、さらに詳細な情報を企業サーバに問合せるステップを有することを特徴としている。
【００１３】
前記対応関係保持手段は、さらに支払合計金額を複数の支払口座のそれぞれに割当てる割合を保持しており、前記判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定するステップは、前記割合を参照することを特徴としている。
【００１４】
本発明に係るカード処理サーバは、カードを特定するカードＩＤと複数の支払口座の対応関係，カードリーダを特定するカードリーダＩＤと該カードリーダの設置場所の対応関係，および支払口座と支払条件の対応関係を保持する対応関係保持手段と、複数の支払口座に関連付けられているカードからカードリーダで取り込んだカードＩＤ，商品購入または施設利用によって支払義務が生じる金額を含む支払情報，および前記カードリーダＩＤとを取り込み、前記対応関係保持手段を参照して、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別し、該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定する手段を有することを特徴としている。
【００１５】
また、本発明に係るプログラムは、カードＩＤと複数の支払口座の対応関係，カードリーダＩＤと該カードリーダの設置場所の対応関係，および決済対象の内容と支払口座の対応関係を保持する対応関係保持手段を具備し、決済を行う一つ以上の支払口座とそれらの口座に支払う金額を決定するカード処理サーバによって実行されるプログラムであって、複数の支払口座に関連付けられているカードからカードリーダで取り込んだカードＩＤ，商品購入または施設利用によって支払義務が生じる金額を含む支払情報，および前記カードリーダＩＤとを取り込む処理、前記対応関係保持手段を参照して、前記複数の支払口座から決済に利用する一つ以上の支払口座を判別する処理、および該判別された一つ以上の支払口座のそれぞれで決済すべき金額を決定する処理を実現するものである。
【００１６】
【発明の実施の形態】
本発明の一実施の形態を、図面を用いて詳細に説明する。
図１は、本発明に係る決済処理システムの一実施形態を説明するための全体構成図である。
【００１７】
同図に示すように、本実施形態においては、カード処理サーバ１０１と、ホテルや駅やコンビニやその他諸々の場所に設置されているカードリーダ１０２と、複数のカード管理サーバ１０４（これらの多くは、カードの発行会社が有するサーバである）と、複数の企業サーバ１０３が、ネットワーク１０５を介して接続されている。
【００１８】
カードリーダ１０２は、カード会社が発行するカード（クレジットカードなど）のカード情報（少なくともカードＩＤ。その他の情報、例えばカード有効期限などを含んでいてもよい）を読み取り、そのカード情報を、当該カードリーダ１０２のカードリーダ情報（少なくとも該カードリーダを特定するカードリーダＩＤを含む。その他の情報、例えば該カードリーダの設置場所などを含んでいてもよい）と、例えば購入日時や購入商品名や購入価格などの商品購入情報とともにカード処理サーバ１０１に送信するものであり、さらにカード処理サーバ１０１から情報を受け取り、決済情報などを印字出力するためのものである。
【００１９】
なお、後述するカード処理サーバに、カードＩＤ対応に該カードの詳細な情報（例えばカードの有効期限など）やカードリーダＩＤ対応に該カードリーダの詳細な情報（例えばカードリーダの設置場所など）を登録するようにしておけば、カードリーダ１０２からカード処理サーバ１０１に送信するカード情報およびカードリーダ情報としては、カードＩＤおよびカードリーダＩＤだけでよい。以下、この場合の実施例を説明する。
【００２０】
企業サーバ１０３（詳細は図３に示す）は、特定のカードを登録（カードを一義的に識別するためのカードＩＤ対応に複数の支払口座を登録）するものであり、さらに、そのカード対応に登録された支払口座を用いて決済する決算対象の内容（期間、場所、利用目的などの情報）をカード処理サーバ１０１に送信して登録するためのものである。
【００２１】
カード処理サーバ１０１は（詳細は図２に示す）、ひとつまたは複数台あり、カードリーダ１０２から取得したカード情報（少なくともカードＩＤ）をもとに、そのカードが予め企業サーバ１０３から登録依頼があったものかを確認する。
【００２２】
確認の結果、そのカードは登録依頼があったものであるが、登録されている情報だけではどの支払口座でまたどの位の按分で決済してよいか判断できずさらに詳細な情報を必要とする場合は、企業サーバ１０３に問合せ、必要な情報のやりとりをする。
【００２３】
そして企業サーバ１０３から新たな情報を入手し、決済する支払口座が決まった場合に、当該カードの決済処理を各カード会社のカード管理サーバ１０４へ送信し、またカード会社のサーバ１０３からの情報を受け取る。
【００２４】
なお、カード処理サーバ１０１がカードリーダ１０２を具備していてもよく、またカード処理サーバ１０１がカード管理サーバ１０４を含んでいてもよい（あるいはカード管理サーバ１０４がカード処理サーバ１０１を含んでいてもよい）。
【００２５】
図２は、カード処理サーバ１０１の詳細図である。
カード処理サーバ１０１は、同図に示すように、購入情報認識部２０１と、購入情報送信部２０２と、購入情報判別結果受信部２０３と、企業別契約カード会社認識部２０４と、個人別契約カード会社認識部２０５と、企業別システム情報更新部２０６と、企業別利用案件一覧作成部２０７と、位置情報認識部２０８を有している。
【００２６】
また格納情報（ＤＢ）として、利用者情報データベース２０９と、企業情報データベース２１０、個人情報データベース２１１と、利用案件一覧データベース２１２と、位置情報データベース２１３を有している。
【００２７】
購入情報認識部２０１は、カードリーダ１０２から送られてきた購入品などの決済金額の情報（購入価格）と、それに対応したカードの情報（少なくともカードＩＤ）を読み込むためのものである。カードの情報には、有効期限やカード発行会社の情報やカード保有者の情報が含まれていてもよいが、前述したようにカードＩＤと有効期限やカード発行会社の情報やカード保有者の情報の対応関係が格納されていればカードＩＤだけでもよい。
【００２８】
購入情報送信部２０２は、該当する購入品に関する決済金額の情報、決済カードの情報を、企業サーバ１０３、またはカード管理サーバ１０４へ送信するためのものである（後述する図４のフローの詳細説明を参照のこと）
【００２９】
購入情報判別結果受信部２０３は、企業サーバ１０３から、該当する購入品の決済を企業カードにて実施してよいか判別した結果を受信するためのものである。
【００３０】
企業別契約カード会社認識部２０４は、カードリーダ１０２から送られてきた、カードの情報から、登録されている企業カードの情報を認識するためのものである。
【００３１】
個人別契約カード会社認識部２０５は、カードリーダ１０２から送られてきた、カードの情報から、登録されている個人カードの情報を認識するためのものである。
【００３２】
企業別システム情報更新部２０６は、企業サーバ１０３から送られてきた、システムの利用に関する情報を更新するためのものである。システムの利用に関する情報とは、企業カード利用者更新情報、個人カード利用者更新情報、出張予定情報、経費利用情報等である（後述する図７のカード処理サーバのデータベース更新フローの説明を参照）。
【００３３】
企業別利用案件一覧作成部２０７は、企業から登録された利用案件一覧情報（利用案件一覧ＤＢ２１２）に、実際カード決済が行われた情報を更新するものでもある。
【００３４】
位置情報認識部２０８は、カードリーダ１０２から送られてきたカードリーダ端末の情報、購入品などの決済日時の情報、およびカードリーダ端末の位置情報などの位置情報データベース２１３を読み込むためのものである。（なお、前述したように、カードリーダＩＤとカードリーダに関する情報やその設置場所の対応関係がカード処理サーバ１０１に登録してあれば、カードリーダ１０２からはカードリーダＩＤだけを読み込めばよい。）
【００３５】
カード処理サーバ１０１では、購入品などの決済日時、位置情報データベースの情報により、カードが不正に利用されていないか認識もする。
【００３６】
利用者情報データベース２０９は、システムを利用する利用者の情報を格納するものである。図８は、利用者情報データベース２０９のデータ例を示す図である。
【００３７】
同図に示すように、利用者情報データベース２０９は、利用者番号８０１と、所属企業番号８０２と、利用可能開始日時８０３と、利用終了日時８０４の項目よりなる。
【００３８】
例えば、同図の場合、番号１のデータは、利用者番号１２３４５６７８９の人の、所属企業番号は１００１−２３４５−１２３４であり、本利用者情報として利用可能開始日時は２００３年７月２３日１１時２２分、利用終了日時は２００８年１２月３１日２３時５９分である。
【００３９】
企業情報データベース２１０は、システムを利用する企業の情報を格納するものである。図９は、企業情報データベース２１０のデータ例を示す図である。
【００４０】
同図に示すように、企業情報データベース２１０は、企業番号９０１と、企業法人カード番号９０２と、契約カード会社番号９０３と、契約カード会社名９０４と、利用可能開始日時９０５と、利用終了日時９０６と、企業名称９０７と、商品購入などによって付与されるポイント９０８の項目よりなる。
【００４１】
例えば、同図の場合、番号１のデータは、企業番号１００１−２３４５−１２３４の、企業法人カード番号は１０００−１０００−１０００−１００１であり、契約カード会社番号は１０００１、契約カード会社名は×××、利用可能開始日時は２０００年４月１日０時０分、利用終了日時は２００８年３月３１日２３時５９分、企業名称は△△製作所、ポイントは７００４２６ポイントである。
【００４２】
個人情報データベース２１１は、システムを利用する利用者と企業カードとの関係を格納するものである。図１０は、個人情報データベース２１１のデータ例を示す図である。
【００４３】
同図に示すように、個人情報は、利用者番号１００１と、個人カード番号１００２と、契約カード会社番号１００３と、契約カード会社名１００４と、利用可能開始日時１００５と、カード利用期限１００６と、商品購入などによって付与されるポイント１００７の項目よりなる。
【００４４】
例えば、同図の場合、番号１のデータは、利用者番号１２３４５６７８９の人の、個人カード番号は４５６７−１２３４−１２３４−１２３４、契約カード会社番号は１０００１、契約カード会社名は×××、利用可能開始日時は２００１年７月２３日０時０分、カード利用期限は２００６年１２月、ポイントは１３ポイントである。
【００４５】
利用案件一覧データベース２１２は、カードを利用して決済した情報を格納するものである。図１１は、利用案件一覧データベース２１２のデータ例を示す図である。
【００４６】
同図に示すように、利用案件一覧データベース２１２は、企業番号１１０１と、利用者番号１１０２と、利用金額１１０３と、利用日時１１０４と、企業の按分比１１０５と、個人の按分比１１０６と、企業決済金額１１０７と、個人決済金額１１０８の項目よりなる。
【００４７】
例えば、同図の場合、番号１のデータは、企業番号１００１−２３４５−１２３４の企業で、利用者番号１２３４５６７８９の人の、利用金額は１０００円、利用日時は２００３年２月２１日２０時１分、按分企業比率が１００％、按分個人比率は０％、企業の決済金額が１０００円、個人の決済金額が０円である。
【００４８】
位置情報データベース２１３は、カードリーダ設置店舗の位置情報を格納するものである。図１２は、位置情報データベース２１３のデータ例を示す図である。
【００４９】
同図に示すように、位置情報データベース２１３は、カードリーダ番号１２０１と、所在地都道府県１２０２と、所在地市１２０３と、所在地町名１２０４の項目よりなる。
【００５０】
例えば、同図の場合、番号１のデータは、カードリーダが１０００−３３３２−２２２０−３３３の、所在地都道府県は東京都、所在地市は江戸川区、所在地町名は東葛西である。
【００５１】
図３は、企業サーバ１０３の詳細図である。
企業サーバ１０３は、同図に示すように、購入情報認識部３０１と、公費利用判定部３０２と、判別結果送信部３０３と、出張予定更新部３０４と、経費予定更新部３０５と、企業別利用案件一覧受信部３０５、予定情報送信部３０７を有し、格納情報（ＤＢ）として出張予定データベース３０８、経費予定データベース３０９を有する。
【００５２】
購入情報認識部３０１は、カード処理サーバ１０１から送られてきた購入品などの決済金額、決済日、それに対応したカードの情報を読み込むためのものである。ここで、カードの情報には、カードＩＤの他に、カード保有者の情報、カード有効期限の情報が含まれる（先に述べたように、カードＩＤとカード保有者の情報やカード有効期限の対応関係がカード処理サーバ１０１に登録されていればカードＩＤだけでもよい）。
【００５３】
公費利用判定部３０２は、該当する購入品を企業カードにて決済可能であるか利用を判定するためのものである。
【００５４】
判別結果送信部３０３は、公費利用判定部３０２で判定した公費利用判定の結果を、カード処理サーバ１０１へ送信するためのものである。
【００５５】
出張予定更新部３０４は、企業内で発生する出張行動予定の登録、変更、削除を、出張予定データベース３０８へ更新するためのものである。
【００５６】
経費予定更新部３０５は、企業内で発生する経費利用予定の登録、変更、削除を、経費予定データベース３０９へ更新するためのものである。
【００５７】
企業別利用案件一覧受信部３０６は、カード処理サーバ１０１から送られてきた、期間ごと、または指定した時期の利用案件結果の一覧を受信するためのものである。
【００５８】
予定情報送信部３０７は、企業サーバ１０３にて登録されている出張予定データベース３０８および経費予定データベース３０９において、更新されている情報をカード処理サーバ１０１へ送信するためのものである。
【００５９】
出張予定データベース３０８は、出張の行動予定情報を格納するものである。図１３は、出張予定データベース３０８のデータ例を示す図である。
【００６０】
同図に示すように、出張予定データベース３０８は、利用者番号１３０１と、利用予定日１３０２と、利用予定金額１３０３と、利用予定用途１３０４と、利用日時１３０５と、利用金額１３０６と、按分企業比１３０７と、按分個人比１３０８の項目よりなる。
【００６１】
例えば、同図の場合、番号１のデータは、利用者番号１２３４５６７８９の人の、利用予定日は２００３年２月２１日、利用予定金額は１０００円、利用予定用途は電車、利用日時は２００３年２月２１日１０時１０分、利用金額は１０００円、按分企業比率が１００％、按分個人比率は０％である。
【００６２】
経費予定データベース３０９は、経費の利用予定情報を格納するものである。図１４は、経費予定データベース３０９のデータ例を示す図である。
【００６３】
同図に示すように、経費予定データベース３０９は、利用者番号１４０１と、利用予定日１４０２と、利用予定金額１４０３と、利用予定用途１４０４と、利用日時１４０５と、利用金額１４０６と、按分企業比１４０７と、按分個人比１４０８の項目よりなる。
【００６４】
例えば、同図の場合、番号１のデータは、利用者番号１２３４５６７８９の人の、利用予定日は２００３年４月２６日、利用予定金額は５０００円、利用予定用途は接待、利用日時は２００３年４月２６日１６時００分、利用金額は５０００円、按分企業比率が９０％、按分個人比率は１０％である。
【００６５】
図４は、カード利用時における、カードリーダ１０２、カード処理サーバ１０１、企業サーバ１０３、およびカード管理サーバ１０４間のタイムチャートである。
【００６６】
最初にカードリーダ１０２からカード処理サーバ１０１に、カードＩＤ，それに対応した問合せ日時、カードリーダＩＤ（カードリーダの設置場所を示す）、問合せ金額（購入品などの決済金額の情報）等が明確になる情報が送信されると（Ｓ４０１）、カード処理サーバ１０１では、登録されている利用者の所属する企業（利用者情報データベース２０９参照）、利用案件（利用案件一覧データベース２１２参照）との整合性の判別を行う（Ｓ４０２）。
【００６７】
判別の結果、利用者の所属する企業、利用案件との整合性が確認できれば、後述する企業別契約カード会社や法人カード番号判別を行う（Ｓ４０６）。
【００６８】
判別の結果、利用者の所属する企業、利用案件との整合性が確認できない場合は、さらに詳細な情報を企業サーバ１０３に問い合わせる。例えば按分比率、利用案件内容、利用者等に関する問合せが必要である場合は、企業サーバ１０３に問合せをする（Ｓ４０３）。
【００６９】
企業サーバ１０３では、登録されている利用者の情報、出張予定の情報（出張予定データベース３０８参照）、経費予定の情報（経費予定データベース３０９参照）との整合性の判別を行い（Ｓ４０４）、その結果をカード処理サーバ１０１へ送信する（Ｓ４０５）。
【００７０】
カード処理サーバ１０１では、登録されている企業別契約カード会社や、企業の法人カード番号を判別して（Ｓ４０６）、その結果、購入品などの決済金額の情報をカード管理サーバ１０４へ送信する（Ｓ４０７）。
【００７１】
また、按分比率から、必要であれば、登録されている個人別契約カード会社や個人の利用カード番号を判別して（Ｓ４０８）、その結果、購入品などの決済金額の情報をカード管理サーバ１０４へ送信する（Ｓ４０９）。
【００７２】
カード管理サーバ１０４では、照会処理を実施する（Ｓ４１０）。照会処理とは、当該購入品を、カード決済する処理である。その結果、カード処理サーバ１０１へ照会を終了した旨を送信する（Ｓ４１１）。結果を送信する先は、カード処理サーバ１０１ではなくカードリーダ１０２でもよい。
【００７３】
図５は、カード処理サーバ１０１のフローチャートである。
カード処理サーバ１０１は、同図に示すように、まず最初に、カードリーダ１０２からの問合せ（データの受信）を受ける（Ｓ５０１）。
【００７４】
次に、その問い合わせで利用されているカードが特殊カードかどうかを判別する（Ｓ５０２）。ここで特殊カードとは、複数の支払口座を有し、決済対象の内容によって決済に利用する支払口座を異ならせるようにしたカードであり、あらかじめ企業サーバ１０３から登録され、企業が特定された任意のカードである。
【００７５】
判別（Ｓ５０２）が肯定（Ｓ５０３）であれば（特殊カードであれば）、その特殊カードの用途判別（Ｓ５０５）へ進む。判別（Ｓ５０２）が否定（Ｓ５０４）であれば（特殊カードでなければ）、個人決済の通常の処理（Ｓ５０９）に進む。その後、個人決済の処理が完了した旨の受信を待つ（Ｓ５１７）。
【００７６】
ここで個人決済の通常の処理とは、当該個人が契約している決済処理であり、対応するカード会社での決済処理に任せるためのものである。これはあらかじめ、各個人が、カード会社と契約するものである。
【００７７】
特殊カードの用途判別（Ｓ５０５）では、決済対象の内容（会社の出張の経費か個人的な経費かなど）に基づいて、企業別契約カード会社にて処理するか、個人別系カード会社にて処理するかを判別する。
【００７８】
用途判別（Ｓ５０５）の結果が肯定（Ｓ６０６）であれば、企業サーバ（１０３）へ問合せの必要性の判別（Ｓ５０８）へ進む。企業サーバ１０３へ問合せの必要性判別（Ｓ５０８）では、購入情報から、企業サーバ１０３へさらに詳細な情報の問合せをする必要があるか判別する。
【００７９】
用途判別（Ｓ５０５）の結果が否定（Ｓ５０７）であれば、個人決済（Ｓ５０９）の処理に進む。例えば、北海道への出張が予定されていた場合に、九州のホテルでカードを提示した場合には個人口座による決済処理となる。
【００８０】
企業サーバ（１０３）へ問合せの必要性の判別（Ｓ５０８）が肯定（Ｓ５１０）であれば、企業サーバ１０３へ問合せ（Ｓ５１１）する。例えば、北海道へ出張した場合の例で説明すると、宿泊ホテルのラウンジで使った費用を企業口座から決済してよいかどうかなど判断が明確でない場合には企業サーバ１０３に問い合わせる。その後、問合せ結果の受信待ち（Ｓ５１２）へ進む。受信した後、その購入情報における按分計算（Ｓ５１３）へ進む。
【００８１】
企業サーバ（１０３）へ問合せの必要性の判別（Ｓ５０８）の結果が否定（Ｓ５０９）であれば、例えば懸賞金の範囲内の支払の場合や、決められた金額（例えば５０００円）未満の場合には無条件で支払可にしてある場合などには企業サーバに問い合わせる必要はなく、直接按分計算（Ｓ５１３）へ進む。按分計算の処理（Ｓ５１３）では、当該購入情報から、企業別契約カードと個人カードで支払う割合（按分）を、図１１の利用案件一覧データベース（２１２）から取得して、企業決済金額および個人決済金額を計算する。
【００８２】
なお、按分は比率だけではなく、例えば一万円までは企業別契約カードで支払い、一万円の超えた場合はその超えた金額を個人カードで支払うというように直接金額を指定して按分する場合もある。
【００８３】
その後、ポイント加算の処理（Ｓ５１４）へ進む。ポイント加算の処理（Ｓ５１４）では、企業決済金額、および個人決済金額から、カードに付随するポイントを計算して加算する。なお、ポイントは、企業カードのみに加算、または企業カードおよび個人カードそれぞれに加算、または個人カードのみに加算することがある。
【００８４】
ポイント加算後、結果格納（Ｓ５１５）へ進む。結果格納（Ｓ５１５）では、当該購入情報を、図１１に示した如き利用案件一覧データベース（２１２）に格納する。
【００８５】
その後、決済処理（Ｓ５１６）へ進む。ここで決済の処理とは、当該企業および個人が契約している決済処理であり、対応するカード会社での決済処理に任せるためのものである。これはあらかじめ、各企業および各個人が、カード会社と個別に契約するものである。
【００８６】
その後、決済処理が完了した旨の受信を待つ（Ｓ５１７）。その結果を受信後、カードリーダ１０２へ伝票出力依頼（Ｓ５１８）を送信する。なお、伝票出力は、企業カード用伝票と個人用伝票の２枚、または複数枚出力されることもある。
【００８７】
図６は、企業サーバ１０３のフローチャートである。
企業サーバ１０３は、同図に示すように、まず最初に、カード処理サーバ１０１から企業サーバ１０３へ詳細情報の問合せを受ける（Ｓ６０１）。その結果、検索、解析の処理（Ｓ６０２）へ進む。検索、解析の処理（Ｓ６０２）では当該問合せ購入情報が、出張予定表データベース３０７、および経費予定データベース３０８に登録されているか解析する。
【００８８】
解析した結果、企業決済の必要性の判別（Ｓ６０３）へ進む。企業決済の必要性の判別（Ｓ６０３）は、検索、解析（Ｓ６０２）で、該当の問合せ購入情報が解析出来たか、出来なかったかの結果を用いて判別される。判別（Ｓ６０３）が肯定（Ｓ６０４）であれば、企業カード決済可能通知（Ｓ６０６）へ進む。
【００８９】
企業カード決済可能通知（Ｓ６０６）では、カード処理サーバ（１０１）へ、当該問合せ購入情報は登録している企業カードにて決済可能であること通知をする。
【００９０】
企業決済の必要性の判別（Ｓ６０３）が否定（Ｓ６０５）であれば、企業カード決済不可能通知（Ｓ６０７）へ進む。企業カード決済不可能通知（Ｓ６０７）では、カード処理サーバ（１０１）へ、当該問合せ購入情報は登録している企業カードで決済するのは不可能であり、個人カードから決済すべきことを通知する。例えば、北海道への出張が予定されていた場合に、九州のホテルでカードを提示した場合、あるいは、明らかに個人的使用の商品の購入の場合には個人口座による決済処理となる。
【００９１】
図７は、カード処理サーバ１０１のデータベース更新のフローチャートである。
同図に示すように、まず最初に、企業サーバ１０３から、カード処理サーバ１０１へ更新問合せ情報を受ける（ステップＳ７０１）。ここで更新問合せ情報とは、企業カードを新たに利用する者の情報、利用案件予定の情報、個人カードの情報、カードリーダ端末の情報等である。
【００９２】
次に、問合せの中に該当する更新情報があるか判別する（Ｓ７０２）。判別（Ｓ７０２）が肯定であれば（Ｓ７０３）、更新情報選別処理（Ｓ７０５）へ進む。更新情報選別の処理とは、更新する情報によって、更新先のデータベースを選定するためのものである。
【００９３】
更新先のデータベースとは、利用者情報でデータベース２０９、企業情報データベース２１０、個人情報データベース２１１、利用案件一覧データベース２１２、位置情報データベース２１３が含まれる。その結果、該当するデータベースへ情報を更新する（Ｓ７０６）。
【００９４】
なお、カード処理サーバの処理として図５に示した実施形態の説明では、Ｓ５０８において企業サーバへの問合せの必要性の判別を行い、Ｓ５１３において按分計算を行い、Ｓ５１４においてポイント加算を行う例を示したが、あらかじめ企業サーバへの問合せが不要であることがわかっている場合や、按分計算やポイント加算を必要としない場合はこれらの処理ステップを設ける必要がないことはいうまでもない。
【００９５】
また、上記説明では、カード処理サーバ１０１は、カードリーダからカードＩＤを受信して、ＤＢを参照して該カードＩＤに対応する各種情報を取得する例を説明したが、カードが大容量の情報を記憶できるＩＣカードなどの場合には、これら各種情報をあらかじめカードに記憶しておき、これらの情報をカードリーダで読み取ってカード処理サーバ１０１に送信するようにしてもよい。
【００９６】
また、複数の支払口座の例としては、例えば、企業を含む団体の口座と個人の口座、両親いずれかの口座と子供の口座、報奨金の振込み口座と個人の口座のいずれかの口座の組などが考えられるがこれに限るものではない。
【００９７】
例えば、定期券の購入代金を会社決済処理で対応することができる。すなわち、定期券購入を各人が所有しているカードを利用し、上述した仕組みにより、定期券代金を会社の口座を用いて決済することも可能である。
【００９８】
また、図５および図７を用いて説明したカード処理サーバの処理をプログラムコード化し、例えばＣＤ−ＲＯＭなどの記録媒体に格納して頒布したり、インターネットを介して利用者ＰＣにダウンロードさせることも可能である。
【００９９】
上記本発明の実施形態によれば、クレジット機能を有するカード自体を変更せずに、そのカードを処理するサーバ側で、そのカードにさまざまな付加機能を加えることができる。
【０１００】
例えば、企業においては出張清算については、あらかじめ、当該社員のカードをカード処理サーバ登録し、期間、場所、金額などを登録しておくことで、あるいは問いかけがあったときに認証を行い、その費用分を当該カードの決済にあてることができる。この場合は、指定場所以外での支払いや、指定金額より超える場合は、企業の決済からはずれて当該人が従来指定している決済処理にゆだねるものとすることができる。
【０１０１】
また、さらに、北海道旅行１００万円の懸賞金を当選者の任意のクレジットカードに該当させることもできる。このときは、そのカードで、北海道での買い物や宿泊などに１００万円までを懸賞金のスポンサーの決済にすることもできる。あるいは、同様に、指定ホテルやその期限を特定することが可能になり、付加価値の高いクレジットカードの利用形態を提供できる効果がある。
【０１０２】
【発明の効果】
本発明によれば、複数の支払口座を持たせたカード（一般には媒体）に対し、決済対象の条件（例えば、特定の期間、場所、購入する商品、宿泊施設への支払い、交通費などの全て、あるいは、それらの組み合わせ）によって決められる支払口座を利用して決済処理することが可能となる。また、案件（例えば、食費）によっては決済額を複数の支払口座で指定された割合で分担させることも可能となる。
【図面の簡単な説明】
【図１】本発明に係る決済処理システムの一実施形態を説明するための全体構成図である。
【図２】本発明に係るカード処理サーバの詳細図である。
【図３】本発明に係る企業サーバの構成図である。
【図４】カード利用時におけるカードリーダ、カード処理サーバ、企業サーバ、およびカード管理サーバ間のタイムチャートである。
【図５】本発明に係るカード処理サーバのフローチャートである。
【図６】本発明に係る企業サーバのフローチャートである。
【図７】本発明に係るカード処理サーバのデータベース更新のフローチャートである。
【図８】本発明に係る利用者情報データベースのデータ例を示す図である。
【図９】本発明に係る企業情報データベースのデータ例を示す図である。
【図１０】本発明に係る個人情報データベースのデータ例を示す図である。
【図１１】本発明に係る利用案件一覧データベースのデータ例を示す図である。
【図１２】本発明に係る位置情報データベースのデータ例を示す図である。
【図１３】本発明に係る出張予定データベースのデータ例を示す図である。
【図１４】本発明に係る経費予定データベースのデータ例を示す図である。
【符号の説明】
１０１…カード処理サーバ、１０２…カードリーダ、１０３…企業サーバ、１０４…カード管理サーバ、１０５…ネットワーク、
２０１…購入情報認識部、２０２…購入情報送信部、２０３…購入情報別判定結果受信部、２０４…企業別契約カード会社認識部、２０５…個人別契約カード会社認識部、２０６…企業別システム情報更新部、２０７…企業別利用案件一覧作成部、２０８…位置情報認識部、２０９…利用者情報データベース、２１０…企業情報データベース、２１１…個人情報データベース、２１２…利用案件一覧データベース、２１３…位置情報データベース、
３０１…購入情報認識部、３０２…公費利用判定部、３０３…判別結果送信部、３０４…出張予定更新部、３０５…経費予定更新部、３０６…企業別利用案件一覧受信部、３０７…予定情報送信部、３０８…出張予定データベース、３０９…経費予定データベース。
【図１】
2005004628.tif 000003
【図２】
2005004628.tif 000004
【図３】
2005004628.tif 000005
【図４】
2005004628.tif 000006
【図５】
2005004628.tif 000007
【図６】
2005004628.tif 000008
【図７】
2005004628.tif 000009
【図８】
2005004628.tif 000010
【図９】
2005004628.tif 000011
【図１０】
2005004628.tif 000012
【図１１】
2005004628.tif 000013
【図１２】
2005004628.tif 000014
【図１３】
2005004628.tif 000015
【図１４】
2005004628.tif 000016