(57)【要約】【課題】従来の購買システムからスムーズにパーチェシングカードを使用した購買システムを可能とする。【解決手段】購買支援サーバ１１０には、売上予定情報や検収情報等を受信する情報受信部３０１、決済処理要求等を送信するデータ送信部３０２、決済処理についての処理を実行する決済要求部３０３を備え、本実施形態の基本的な購買支援に関する処理を実行する。これに加え、業者端末からの問い合わせに対応するための進捗管理等を実行する業者進捗処理部３０４、顧客端末からの問い合わせに対応するための進捗管理等を実行する顧客進捗処理部３０５、取引明細の処理を実行する取引明細処理部３０６なども備え、より厚い支援を実行することができる。【選択図】図１
2008123286.tif 000002
【特許請求の範囲】
【請求項１】
発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を送信する発注手段と、前記発注識別情報で識別される発注に対応する納品が行われた場合、前記発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を送信する検収送信手段とを含む顧客装置と、
前記発注要求を受信すると、前記商品識別情報で識別される商品の納品を指示する納品指示手段と、前記発注識別情報と、前記発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む前記発注要求に対応する売上予定情報を送信する売上送信手段とを含む業者装置と、
前記顧客装置および前記業者装置から前記売上予定情報および前記検収情報をそれぞれ受信し、前記発注識別情報によって前記受信した売上予定情報と前記受信した検収情報とが対応すると判定される場合は、前記売上予定情報に含まれる業者識別情報で特定される前記業者の売り上げの、前記カード情報により特定されるカードによる決済処理要求を送信する決済要求手段を含む購買支援装置と、
前記購買支援装置から決済処理要求を受信すると、前記カード情報で特定されるカードの顧客に対する支払請求処理の指示を行う請求指示手段と、前記受信した決済処理要求の売上に関する売上予定情報を送信した業者装置の業者に前記対応する支払処理をするよう支払指示を行う支払手段とを含む決済処理装置と
を備えたことを特徴とする決済処理システム。
【請求項２】
前記発注要求は、取引識別情報をさらに含み、前記購買支援装置は、記憶手段に記憶された該取引識別情報と前記カード情報との対応付け情報により、前記取引上識別情報で識別される取引の決済に使用されるカードのカード情報を抽出するカード情報抽出手段をさらに含むことを特徴とする請求項１に記載の決済処理システム。
【請求項３】
前記取引識別情報は、前記カード情報の一部であることを特徴とする請求項２に記載の決済処理システム。
【請求項４】
前記購買支援装置は、前記発注識別情報により識別される売上の決済処理の進捗情報を、該売上情報を送信した業者装置に送信する業者進捗送信手段をさらに含むことを特徴とする請求項１、２または３に記載の決済処理システム。
【請求項５】
前記購買支援装置は、前記カード情報で特定されるカードの顧客からの発注についての売上の決済処理の進捗情報を該顧客装置に送信する顧客進捗送信手段をさらに含むことを特徴とする請求項１ないし４のいずれかに記載の決済処理システム。
【請求項６】
前記購買支援装置は、前記業者識別情報で特定される業者についての取引明細情報を該業者の業者装置に送信する業者明細送信手段をさらに含むことを特徴とする請求項１ないし５のいずれかに記載の決済処理システム。
【請求項７】
前記購買支援装置は、前記カード情報で特定されるカードの顧客からの発注について取引明細情報を該顧客装置に送信する顧客明細送信手段をさらに含むことを特徴とする請求項１ないし６のいずれかに記載の決済処理システム。
【請求項８】
顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って前記商品識別情報で識別される商品の納品を指示する業者装置から送信された前記発注識別情報と、前記発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む前記発注要求に対応する売上予定情報を受け取る売上予定情報受信手段と、
前記発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する前記発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信手段と、
前記発注識別情報によって、前記業者装置から受信した売上予定情報と前記顧客装置から受信した検収情報とが対応すると判定される場合は、前記売上予定情報に含まれる業者識別情報で特定される前記業者の売り上げの、前記カード情報により特定されるカードによる決済処理要求を送信する決済要求手段と
を備えたことを特徴とする購買支援装置。
【請求項９】
顧客装置、業者装置および決済処理装置を備え、顧客の発注に基づき納品された商品の決済処理を行う決済処理システムにおいて実行される決済処理方法であって、
顧客装置によって、発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を送信し、前記発注識別情報で識別される発注に対応する納品が行われた場合、前記発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を送信する顧客ステップと、
業者装置によって、前記発注要求を受信すると、前記商品識別情報で識別される商品の納品を指示し、前記発注識別情報と、前記発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む前記発注要求に対応する売上予定情報を送信する業者ステップと、
決済処理装置によって、前記顧客装置および前記業者装置から前記売上予定情報および前記検収情報をそれぞれ受信し、前記発注識別情報によって前記受信した売上予定情報と前記受信した検収情報とが対応すると判定される場合は、前記売上予定情報に含まれる業者識別情報で特定される前記業者の売り上げの、前記カード情報により特定されるカードによる決済処理要求を送信する購買支援ステップと、
決済処理装置が、前記購買支援装置から決済処理要求を受信すると、前記カード情報で特定されるカードの顧客に対する支払請求処理の指示を行い、前記受信した決済処理要求の売上に関する売上予定情報を送信した業者装置の業者に前記対応する支払処理をするよう支払指示を行う決済処理ステップと
を備えたことを特徴とする決済処理方法。
【請求項１０】
前記発注要求は、取引識別情報をさらに含み、前記購買支援ステップは、記憶手段に記憶された該取引識別情報と前記カード情報との対応付け情報により、前記取引上識別情報で識別される取引の決済に使用されるカードのカード情報を抽出するカード情報抽出ステップをさらに含むことを特徴とする請求項９に記載の決済処理方法。
【請求項１１】
前記取引識別情報は、前記カード情報の一部であることを特徴とする請求項１０に記載の決済処理方法。
【請求項１２】
前記購買支援ステップは、前記発注識別情報により識別される売上の決済処理の進捗情報を、該売上情報を送信した業者装置に送信する業者進捗送信ステップを含むことを特徴とする請求項９、１０または１１に記載の決済処理方法。
【請求項１３】
前記購買支援ステップは、前記カード情報で特定されるカードの顧客からの発注についての売上の決済処理の進捗情報を該顧客装置に送信する顧客進捗送信ステップを含むことを特徴とする請求項９ないし１２のいずれかに記載の決済処理方法。
【請求項１４】
前記購買支援ステップは、前記業者識別情報で特定される業者についての取引明細情報を該業者の業者装置に送信する業者明細送信ステップを含むことを特徴とする請求項９ないし１３のいずれかに記載の決済処理方法。
【請求項１５】
前記購買支援ステップは、前記カード情報で特定されるカードの顧客からの発注について取引明細情報を該顧客装置に送信する顧客明細送信ステップを含むことを特徴とする請求項９ないし１４のいずれかに記載の決済処理方法。
【請求項１６】
顧客の発注に基づき納品された商品の決済処理の支援を行う購買支援装置において実行される購買支援処理方法であって、
売上予定情報受信手段によって、顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って前記商品識別情報で識別される商品の納品を指示する業者装置から送信された前記発注識別情報と、前記発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む前記発注要求に対応する売上予定情報を受け取る売上予定情報受信ステップと、
検収情報受信によって、前記発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する前記発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信ステップと、
決済要求によって、前記発注識別情報によって、前記業者装置から受信した売上予定情報と前記顧客装置から受信した検収情報とが対応すると判定される場合は、前記売上予定情報に含まれる業者識別情報で特定される前記業者の売り上げの、前記カード情報により特定されるカードによる決済処理要求を送信する決済要求ステップと
を備えたことを特徴とする購買支援方法。
【請求項１７】
購買支援装置に、顧客の発注に基づき納品された商品の決済処理の支援である購買支援処理を実行させるプログラムであって、
売上予定情報受信手段によって、顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って前記商品識別情報で識別される商品の納品を指示する業者装置から送信された前記発注識別情報と、前記発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む前記発注要求に対応する売上予定情報を受け取る売上予定情報受信ステップと、
検収情報受信によって、前記発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する前記発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信ステップと、
決済要求によって、前記発注識別情報によって、前記業者装置から受信した売上予定情報と前記顧客装置から受信した検収情報とが対応すると判定される場合は、前記売上予定情報に含まれる業者識別情報で特定される前記業者の売り上げの、前記カード情報により特定されるカードによる決済処理要求を送信する決済要求ステップと
を実行することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、決済処理システムおよび方法に関し、より詳細にはパーチェシングカードを使用した発注における決済処理システムおよび方法に関する。
【背景技術】
【０００２】
従来から、事務用品や部材などを企業が業者から購入する場合にクレジット決済システムを活用して、支払い処理などを支援するパーチェシングカードが提案されている（例えば、特許文献１参照）。パーチェシングカードシステムは、納品された事務用品や部材などを発注する場合、その支払いを企業向けのクレジットカード方式のカードにより決済することにより、企業向けにクレジットカードの利便性を実現するものである。このようなシステムを用いることにより、企業は購入時の支払いが容易になるという利点がある。
【０００３】
【特許文献１】特開２００２−２１６０５８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、多くの企業で各々独自の購買システムを有しており、それぞれ異なる発注フォームを持っていたり、納入業者との独自の伝票管理などを行っていたりするため、支払い部分だけクレジットカードの決済機能を使用する従来のパーチェシングカードでは、これらに対応できず、ほとんど使用されていないという問題がある。
【０００５】
また、単に決済機能を提供するのみであれば、金融機関を用いた振込処理や、ネットバンキングなどでもある程度代用することができ、システムの利用促進のためには有効な付加機能が必要である。
【０００６】
本発明は、このような問題に鑑みてなされたもので、一意の発注番号を使用することにより、従来の購買システムからスムーズにパーチェシングカードを使用した購買システムを可能とする決済処理システムおよび方法を提供することを目的とする。また、企業の発注管理や、納入業者の納入処理などを効率化する決済処理システムおよび方法を提供することも目的とする。
【課題を解決するための手段】
【０００７】
このような目的を達成するために、本出願の請求項１に記載の発明は、決済処理システムであって、発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を送信する発注手段と、発注識別情報で識別される発注に対応する納品が行われた場合、発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を送信する検収送信手段とを含む顧客装置と、発注要求を受信すると、商品識別情報で識別される商品の納品を指示する納品指示手段と、発注識別情報と、発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む発注要求に対応する売上予定情報を送信する売上送信手段とを含む業者装置と、顧客装置および業者装置から売上予定情報および検収情報をそれぞれ受信し、発注識別情報によって受信した売上予定情報と受信した検収情報とが対応すると判定される場合は、売上予定情報に含まれる業者識別情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する決済要求手段を含む購買支援装置と、購買支援装置から決済処理要求を受信すると、カード情報で特定されるカードの顧客に対する支払請求処理の指示を行う請求指示手段と、受信した決済処理要求の売上に関する売上予定情報を送信した業者装置の業者に対応する支払処理をするよう支払指示を行う支払手段とを含む決済処理装置とを備えたことを特徴とする。
【０００８】
請求項２に記載の発明は、請求項１に記載の決済処理システムにおいて、発注要求は、取引識別情報をさらに含み、購買支援装置は、記憶手段に記憶された取引識別情報とカード情報との対応付け情報により、取引上識別情報で識別される取引の決済に使用されるカードのカード情報を抽出するカード情報抽出手段をさらに含むことを特徴とする。
【０００９】
請求項３に記載の発明は、請求項２に記載の決済処理システムにおいて、取引識別情報は、カード情報の一部であることを特徴とする。
【００１０】
請求項４に記載の発明は、請求項１、２または３に記載の決済処理システムにおいて、購買支援装置は、発注識別情報により識別される売上の決済処理の進捗情報を、売上情報を送信した業者装置に送信する業者進捗送信手段をさらに含むことを特徴とする。
【００１１】
請求項５に記載の発明は、請求項１ないし４のいずれかに記載の決済処理システムにおいて、購買支援装置は、カード情報で特定されるカードの顧客からの発注についての売上の決済処理の進捗情報を顧客装置に送信する顧客進捗送信手段をさらに含むことを特徴とする。
【００１２】
請求項６に記載の発明は、請求項１ないし５のいずれかに記載の決済処理システムにおいて、購買支援装置は、業者識別情報で特定される業者についての取引明細情報を業者の業者装置に送信する業者明細送信手段をさらに含むことを特徴とする。
【００１３】
請求項７に記載の発明は、請求項１ないし６のいずれかに記載の決済処理システムにおいて、購買支援装置は、カード情報で特定されるカードの顧客からの発注について取引明細情報を顧客装置に送信する顧客明細送信手段をさらに含むことを特徴とする。
【００１４】
請求項８に記載の発明は、購買支援装置であって、顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って商品識別情報で識別される商品の納品を指示する業者装置から送信された発注識別情報と、発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む発注要求に対応する売上予定情報を受け取る売上予定情報受信手段と、発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信手段と、発注識別情報によって、業者装置から受信した売上予定情報と顧客装置から受信した検収情報とが対応すると判定される場合は、売上予定情報に含まれる業者識別情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する決済要求手段とを備えたことを特徴とする。
【００１５】
請求項９に記載の発明は、顧客装置、業者装置および決済処理装置を備え、顧客の発注に基づき納品された商品の決済処理を行う決済処理システムにおいて実行される決済処理方法であって、顧客装置によって、発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を送信し、発注識別情報で識別される発注に対応する納品が行われた場合、発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を送信する顧客ステップと、業者装置によって、発注要求を受信すると、商品識別情報で識別される商品の納品を指示し、発注識別情報と、発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む発注要求に対応する売上予定情報を送信する業者ステップと、決済処理装置によって、顧客装置および業者装置から売上予定情報および検収情報をそれぞれ受信し、発注識別情報によって受信した売上予定情報と受信した検収情報とが対応すると判定される場合は、売上予定情報に含まれる業者識別情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する購買支援ステップと、決済処理装置が、購買支援装置から決済処理要求を受信すると、カード情報で特定されるカードの顧客に対する支払請求処理の指示を行い、受信した決済処理要求の売上に関する売上予定情報を送信した業者装置の業者に対応する支払処理をするよう支払指示を行う決済処理ステップとを備えたことを特徴とする。
【００１６】
請求項１０に記載の発明は、請求項９に記載の決済処理方法において、発注要求は、取引識別情報をさらに含み、購買支援ステップは、記憶手段に記憶された取引識別情報とカード情報との対応付け情報により、取引上識別情報で識別される取引の決済に使用されるカードのカード情報を抽出するカード情報抽出ステップをさらに含むことを特徴とする。
【００１７】
請求項１１に記載の発明は、請求項２に記載の決済処理方法において、取引識別情報は、カード情報の一部であることを特徴とする。
【００１８】
請求項１２に記載の発明は、請求項９、１０または１１に記載の決済処理方法において、購買支援ステップは、発注識別情報により識別される売上の決済処理の進捗情報を、売上情報を送信した業者装置に送信する業者進捗送信ステップを含むことを特徴とする。
【００１９】
請求項１３に記載の発明は、請求項９ないし１２のいずれかに記載の決済処理方法において、購買支援ステップは、カード情報で特定されるカードの顧客からの発注についての売上の決済処理の進捗情報を顧客装置に送信する顧客進捗送信ステップを含むことを特徴とする。
【００２０】
請求項１４に記載の発明は、請求項９ないし１３のいずれかに記載の決済処理方法において、購買支援ステップは、業者識別情報で特定される業者についての取引明細情報を業者の業者装置に送信する業者明細送信ステップを含むことを特徴とする。
【００２１】
請求項１５に記載の発明は、請求項９ないし１４のいずれかに記載の決済処理方法において、購買支援ステップは、カード情報で特定されるカードの顧客からの発注について取引明細情報を顧客装置に送信する顧客明細送信ステップを含むことを特徴とする。
【００２２】
請求項１６に記載の発明は、顧客の発注に基づき納品された商品の決済処理の支援を行う購買支援装置において実行される購買支援処理方法であって、売上予定情報受信手段によって、顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って商品識別情報で識別される商品の納品を指示する業者装置から送信された発注識別情報と、発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む発注要求に対応する売上予定情報を受け取る売上予定情報受信ステップと、検収情報受信によって、発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信ステップと、決済要求によって、発注識別情報によって、業者装置から受信した売上予定情報と顧客装置から受信した検収情報とが対応すると判定される場合は、売上予定情報に含まれる業者識別情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する決済要求ステップとを備えたことを特徴とする。
【００２３】
請求項１７に記載の発明は、購買支援装置に、顧客の発注に基づき納品された商品の決済処理の支援である購買支援処理を実行させるプログラムであって、売上予定情報受信手段によって、顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って商品識別情報で識別される商品の納品を指示する業者装置から送信された発注識別情報と、発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む発注要求に対応する売上予定情報を受け取る売上予定情報受信ステップと、検収情報受信によって、発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信ステップと、決済要求によって、発注識別情報によって、業者装置から受信した売上予定情報と顧客装置から受信した検収情報とが対応すると判定される場合は、売上予定情報に含まれる業者識別情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する決済要求ステップとを実行することを特徴とする。
【発明の効果】
【００２４】
以上説明したように、本発明によれば、顧客装置および業者装置から売上予定情報および検収情報をそれぞれ受信し、発注識別情報によって受信した売上予定情報に対応する検収情報を受信した場合は、売上予定情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する決済要求手段を含む購買支援装置を備えているので、一意の発注番号を使用することにより、従来の購買システムからスムーズにパーチェシングカードを使用した購買システムを可能とする決済処理システムおよび方法を提供することが可能となる。
【発明を実施するための最良の形態】
【００２５】
（第１実施形態）
以下、図面を参照しながら本発明の実施形態について詳細に説明する。  
図１は、本発明にかかる第１実施形態のシステム全体を示すブロック図である。
【００２６】
（本実施形態のシステム構成）
本実施形態の決済処理システムでは、大きく分けて購買支援サーバ１１０、顧客システム１２０、業者システム１３０および決済処理サーバ１４０がネットワークで接続されている。購買支援サーバ１１０は、本実施形態のシステムの中心的な機能を実行する部分であり、本実施形態の決済処理に関して顧客側処理と業者側処理とを支援し、データベース１１１〜１１２を備えている。なお、図１においては、１つの購買支援サーバ１１０が示されているが、実行される機能を複数のサーバに分散させて全体として図１に示す購買支援サーバ１１０を実現することもできる。ここで、以上のシステムあるいはサーバは相互に何らかのネットワークにより接続されている。このネットワークにはインターネットを含むことができるが、一方で、専用回線により接続することもできるし、一部のやり取りをＦＡＸやその他の従来の手続により行うこともできる。その他、接続のハードウェアあるいはソフトウェアについては特定の規格、製品を採用する必要はなく、本技術分野で知られたいずれの手法、構成によってもデータのやりとりが可能であれば本願発明の目的を達することができる。なお、本明細書でシステムは端末、サーバおよびデータベースのいずれかを含むものであるが、本願発明を実装するためにはこのようなものでなくても、データ通信、データ処理およびデータの管理が可能なものであれば、いずれの装置、機器を用いてシステムを構成することもできる。
【００２７】
また、顧客システム１２０は、本実施形態の顧客側の処理を実装する部分であり、取引の照会を行う端末１２１や検収処理などを実行する端末１２２などを備え、さらにデータベース１２３および１２４を備える。ここで、顧客システム１２０は所定の端末およびデータベースを備えるが、これに限られることなく１台の端末で処理を実行することもできるし、より多くの端末やデータベースに機能、データを分けて実装することもできる。
【００２８】
業者システム１３０は、顧客に種々の商品を納入する業者側の処理を実装するものであり、通常のクレジットカードシステムにおいてはいわゆる加盟店装置あるいはシステムに相当する。本実施形態では、顧客システム１２０と同様に取引の照会などを行う端末１３１や売り上げ処理などを行う端末１３２、およびデータベース１３３を備えるが、上述の顧客システム１２０と同様、図１に示すのとは異なる種々の形態で構成することができる。一般的には、顧客である企業は様々な業者と取引をしており、このような業者システム１３０は複数存在しているが、図１等では便宜上あるいは説明の都合上１つだけで例示させて説明するものとする。
【００２９】
決済処理サーバ１４０は、本質的には通常のクレジットカードシステムあるいはパーチェシングカードシステムと同様の機能を備えている。これは、本実施形態において従来の顧客システムや業者システムの処理と異なる部分の処理を購買支援サーバ１１０においてできる限り吸収することによって可能としている。すなわち、例えば通常のクレジットカード処理システムでは業者システムに相当する加盟店の端末から決済処理サーバに売上情報が直接送信され、これに基づいて決済処理が行われるが、本実施形態では業者システムから売上予定データがいったん購買支援サーバ１１０に送信され、顧客システム１２０からの検収の情報を待って実際の売り上げ情報の送信、つまり決済処理要求を行う。このような処理を行うことにより、通常は加盟店からの確定的な売り上げ情報を受信して決済処理を行う決済処理サーバ１４０に同様の送信を行うことが可能となり、従来のクレジットカードあるいはパーチェシングカードの処理自体を流用し、あるいは処理スキームを用いることができる。ここで、このような処理を可能にするため本発明では発注から決済要求までの間で取引内容を特定できるよう発注識別情報である発注番号を付与する。この発注番号はその取引が終了するまで共通して用いられ、これにより取引が常に特定できることとなる。
【００３０】
（本実施形態のモジュール構成）
本システムの全体の構成は以上のようなものであるが、本実施形態の個別のシステムを構成する端末、サーバは少なくともネットワークに接続可能な通常のコンピュータの機能を有している必要がある。このようなハードウェアの条件の下、本実施形態の個別のシステムの処理の実行はソフトウェアプログラムがこのようなハードウェアにインストールされて行われる。各ソフトウェアは例えば図３ないし図６に示すようなモジュール構成で示すことができるが、これは単なる例示であり、各モジュールの機能をさらにいくつかのモジュールで分担したり、いくつかのモジュールの機能を統合したモジュールを想定したりすることができるのはいうまでもない。以下に、各個別システムのモジュール構成を説明するが、これらのモジュールが相互に連携を取って実行され、後述する本実施形態の処理が達成されるのである。なお、本実施形態では図４に示す顧客システム１２０および図５に示す業者システム１３０の処理は、各サーバまたは端末がソフトウェアによって処理するよう説明しているが、本願発明を実施するためにはこれに限られず、図３に示す購買支援サーバ１１０および図６に示す決済処理サーバ１４０以外の構成の一部または全部をこのようなソフトウェアの処理とせずに、購買支援サーバ１１０および決済処理サーバ１４０への情報の伝達をＦＡＸやメール等の従来の通信手法により行うこともできる。
【００３１】
図３は、購買支援サーバ１１０のモジュール構成を示す図である。購買支援サーバ１１０には、売上予定情報や検収情報等を受信する情報受信部３０１、決済処理要求等を送信するデータ送信部３０２、決済処理についての処理を実行する決済要求部３０３を備え、本実施形態の基本的な購買支援に関する処理を実行する。これに加え、業者端末からの問い合わせに対応するための進捗管理等を実行する業者進捗処理部３０４、顧客端末からの問い合わせに対応するための進捗管理等を実行する顧客進捗処理部３０５、取引明細の処理を実行する取引明細処理部３０６なども備え、より厚い支援を実行することができる。
【００３２】
図４は、顧客システム１２０のモジュール構成を示す図である。図４においては、システムの中心にサーバ４１０を備え、これに接続された端末１２１、１２２からの指示により、本実施形態の主な処理をサーバ４１０が実行するように示されているが、これに限られることなく、端末１２１、１２２にサーバ４１０と同様の機能を持たせて各々単独で処理を実行するようにすることもできる。サーバ４１０、したがって顧客システムは、発注要求を実行する発注要求部４０１、検収処理の入力を受けて検収情報を送信する検収処理部４０２、および種々のデータ通信を処理するデータ送受信部４０４を本実施形態の基本機能を実行するモジュールとして備える。さらに、購買支援サーバ１１０への種々の問い合わせを処理する顧客情報問合部４０３を備える。
【００３３】
図５は、業者システム１３０のモジュール構成を示す図であり、顧客システム１２０のモジュール構成と同様、図に示す例ではシステムの主な処理はサーバにより行われるが、これに限られない。業者システム１３０は、本発明の基本処理を行うモジュールとして、顧客からの発注に基づき納品を指示する納品指示部５０１、売上予定情報を作成等する売上処理部５０２および種々のデータ通信を行う送受信部５０４を備える。さらに、売上予定情報送信後の売上処理の進捗の問い合わせ等を行う業者問合部５０３を備える。
【００３４】
図６は、決済処理サーバ１４０のモジュール構成を示す図であり、ハードウェア構成は上述の各個別システムと同様種々の形態をとることができる。また、決済処理サーバあるいはシステムは本技術分野で広く知られているものであり、様々な方式や付加機能を有するものが多く知られているため、ここでは、本実施形態の説明上必要と考えられる部分だけに絞って説明するが、必要であればこのような既に知られている技術を考慮して理解することもできる。決済処理サーバ１４０は、本実施形態で必要な基本処理を実行するモジュールとして、顧客に請求書を発行したりする請求発行部６０１、業者に売り上げ情報に対応する支払指示等を行う支払処理部６０２および種々のデータ通信を行う送受信部６０３を備える。ここで、上述の通りクレジットカードあるいはパーチェシングカードによる決済処理においては、一般に請求書を発行するといった請求処理だけではなく、その後所定の口座から請求額を引き落としたり、振込を受け取ったり、場合によっては受け取り書を送信したりする処理により請求処理は完結する。本実施形態では、請求処理に伴う、あるいは引き続き必要となるこのような処理については特に説明しないが、本実施形態で請求処理と言った場合、これに伴う、あるいは引き続き必要な種々の本技術分野で知られた処理が行われるものとする。したがって、請求処理以外の処理を行うシステムも本発明の範囲に含まれるのはもちろん、そのような本実施形態で説明しない処理にここで言う請求処理がどのような形態で組み込まれていても、そのようなもの全体を指して請求処理と呼ぶことができるものとする。支払指示についても実際には振込処理やその他の送金処理が引き続いて行われるが、請求処理と同様に解釈するものとする。
【００３５】
（本実施形態の処理）
以上、本実施形態の構成について説明したが、図２を参照して以上の構成を持つシステムを用いた本実施形態の処理を説明する。図２は、本実施形態の処理を説明するための図である。本実施形態では原則として図２に示す番号の順番に処理が行われるが、これはあくまで本実施形態のようなシステムの典型的な流れであって、常にこのような順序である必要はなく、一部順序を変更したり、一部の手順を入れ替えたり、異なる手順を加えることもできる。
【００３６】
この処理の前提として、本実施形態の顧客システムは一定の発注および検収システムを有しており、業者システムとは、そのような顧客システムに独自なシステムで処理を行うものとする。顧客システムにおいて商品の発注処理を行うときは、先ず品目、数量、金額について業者システムから予め情報を入手しておき（ステップ（１））、この情報をもとに発注処理を行う。なお、図２に示される各処理のカッコ内の情報はその処理により送られる情報を示しているが、これに限られず本願発明の効果を奏するためにより少ないまたはより多い情報を含めることができる。発注処理は、希望する品目、数量、金額を決定して行うが、顧客システム１２０では、このような情報とともにパーチェシングカードのカード番号が指定されて発注が入力されると、発注要求部４０１は発注識別情報である発注番号を設定して業者端末１３０に発注要求を送信する（ステップ（２））。
【００３７】
ここで、本実施形態の発注要求にはカード番号の代わりに取引番号が用いられ、業者側にはカード番号が直接知られないようにしている。これにより、セキュリティを確保するとともに顧客側の安心感を得ることができる。本実施形態では、この取引番号はカード番号の一部、例えばカード番号が１６桁とすると下８桁を使用するようにすることができるが、これに限られず取引を特定できる情報であればいずれのものも使用することができ、取引番号自体使用しなくても本願発明の効果を奏することができる。すなわち、本実施形態では顧客システム１２０、業者システム１３０および購買支援サーバ１１０の間で発注識別情報である１つの発注番号を一貫して用いることにより取引を特定できるため、取引番号を付与するか否かで本願発明の権利範囲は限定されない。このような意味で、本実施形態で、発注番号に加え敢えて取引番号を使用するのは、情報に冗長性を持たせることにより、本実施形態のシステムを用いる使用者が誤入力をした場合などに対応するためでもあるということができる。すなわち、例えば売上予定情報が送られてきた場合に、取引番号によりカード番号や顧客を特定して、送られた情報に誤りがないかチェックすることができ、そのような誤りが検出されたときは、業者端末にそれを表示して報知したり、修正を促したりすることができる。また、カード番号（あるいはその一部として使用する取引番号）についてチェックデジットを使用したり、入力項目の桁数チェックをしたりすることによっても入力誤り、登録ミスなどを未然に防止することができる。
【００３８】
なお、本実施形態の取引番号は売上予定情報とともに購買支援サーバ１１０に送られ、購買支援サーバ１１０側で予め用意された取引番号とカード番号との対応付データを参照してカード番号に置き換えることができ、購買支援サーバ１１０、顧客システム１２０および決済処理サーバ１４０においてはカード番号を相互にやり取りして取引の特定や、その他の確認処理をすることができる。特に本実施形態では、カード番号の上８桁を顧客ごとに定めておいて、業者側から送られた下８桁と合体させるだけで元のカード番号を生成することもできる。
【００３９】
発注要求を受信した業者システム１３０は、納品指示部５０１が発注要求に含まれる商品、数量などに基づいて納品の指示を行う。その結果、要求された商品が顧客に納品される（ステップ（３））とともに、売上処理部５０２は、発注要求および納品状況に基づき、発注番号を含む売上予定情報を作成し購買支援サーバ１１０に送信するようにする（ステップ（４））。ここで、購買支援サーバ１１０に送られるのは、あくまで売上予定の情報である。これは、従来のパーチェシングカードシステムでは業者からはオーソリがなされた後で売上情報を決済処理サーバに送っていたが、本実施形態では後述するように別途顧客側から入手する検収情報により漸く売上情報として確定してから購買支援サーバが送信するため、購買支援サーバに送られるのは売上予定にならざるを得ないからである。
【００４０】
本実施形態のステップ（３）および（４）で業者システムは、送信する情報に請求番号を生成して含めることができる。これは、業者システム内で専ら使用する請求番号を生成することにより、納品は顧客に対してであるのに、支払は決済サーバからなされるというアンバランスを解消するためのものであり、この請求番号をキーにすることにより、突合処理や、照会処理を効率よく行うことができる。  
以上により、発注、納品が完了すると、顧客側では発注した納品が確実にされたかどうかを確認する、いわゆる検品を行うが、本実施形態のシステムでは顧客システムに取引明細のデータベース１２３または１２４を有しており、まず発注した情報により納品の確認、すなわち検品を行う。その後、購買支援サーバ１１０が業者システム１３０から受信した売上予定情報を顧客システム１２０が取り込み（ステップ（５））、その情報と検品の結果とを照合し（ステップ（６））、検収の入力を行う。検収の入力が行われると、検収処理部４０２は発注番号および納品された商品の情報を含む検収情報を購買支援サーバ１１０に送信する（ステップ（７））。ここで、納品が不足している場合や、発注内容が変更されている場合などを検収情報に反映させることもできる。なお、本実施形態では顧客システムは発注した情報に基づいて検品を行うが、購買支援サーバ１１０から売上予定情報を入手して検品に使用することもできる。
【００４１】
このように、業者システム１３０および顧客システム１２０からそれぞれ売上予定情報および検収情報が購買支援サーバ１１０に送信されることにより、従来のパーチェシングカードにおいて納品時に行っていたオーソリ処理が、結果的に完了したことになるため、購買支援サーバ１１０は、決済処理サーバ１４０に売上情報を送信して決済処理を要求することができる。具体的には、情報受信部３０１において上記の各情報を受信すると、決済要求部３０３は、売上予定情報と検収情報とを比較して検収が行われた売上について売上情報を作成し、決済処理サーバ１４０に決済処理要求を送信する（ステップ（８））。ここで、通常のパーチェシングカードあるいはクレジットカードのシステムでは、売上とともにほぼリアルタイムで送信されるか、または加盟店の都合に合わせて送信されるが、本実施形態の決済処理要求は、ネットワークのトランザクションやシステムの環境、条件に考慮して月１回まとめて送信される。ただし、これは任意のタイミングで行うことができ、月１回に限らず、複数回送信したり、都度送信したりすることもできる。なお、本実施形態では、このような処理を通じて売上予定データを記憶するデータベース１１１から検収済みの売上予定データ（売上データ）を記憶するデータベース１１２へと切り替え管理されるが、本技術分野で知られたその他の方法でデータ管理することもできる。
【００４２】
決済処理要求を受信した決済処理サーバ１４０は、業者に振込通知を行った上で（ステップ（９））、売上代金の振込を行う（ステップ（１０））が、上述の通り決済処理サーバは種々の方法により送金処理が行われるので、本実施形態の例に限られることはない。同様に顧客に対しては請求書送付等の請求処理（ステップ（１１））、およびこれに基づく顧客からの支払処理が行われるが、本発明を実装するために本実施形態と同じ処理をする必要がないことはいうまでもない。顧客から支払われる手数料についてもまた同様である。さらに、この手数料については、顧客側から一定の手数料を業者側に求める場合は、購買支援サーバ側で予め業者側に課す手数料を盛り込んだ金額を算出して、売上処理をすることもでき、この目的で、各業者ごとに課す手数料を顧客システムから予め入力し、格納しておくデータベースを備えることができる。また、業者側に手数料を課す別の方法としては、顧客側に請求する際に、上記で説明した手数料を請求せずに手数料を差し引いた額を業者側に送金するようにすることもできる。したがって、業者および顧客との種々の取引条件を格納しておくことにより、本技術分野で知られる様々な方法で請求、送金などの処理が可能となる。
【００４３】
（本実施形態のその他の処理）
上記では、本実施形態の基本機能である発注から決済までの各処理について説明したが、これにより従来のパーチェシングカードでは困難であった顧客企業側のシステムとの融合が可能になり、本発明の決済処理を用いた効率的な購買処理が可能になる。
【００４４】
さらに、本実施形態のシステムでは図７に示すような各個別システム、端末などのアクセス制限を行うことによりシステム全体のセキュリティが確保される。本実施形態では、図７に示す識別情報であるＩＤやパスワードは各システムからの申請などにより生成され、予め通知されるが、具体的な申請方法や、ＩＤ／パスワードの生成方法などは本技術分野で知られたいずれの方法も用いることができるのでここでは詳説しない。また、申請により生成せずに他のデータベースから流用するなど別の方法も用いることができる。本実施形態では業者識別情報である業者番号および業者用に割当てられたＩＤの双方を用いるが、これらを統合して処理の簡素化を可能とすることもできる。すなわち、購買支援サーバ１１０は売上予定情報を受信する際、送信した業者を特定するため業者番号を必要とし、システムによっては売上予定情報に業者番号を含めることもできるが、業者システムから購買支援サーバにアクセスする際ＩＤおよびパスワードを要求する場合には、アクセスの際に使用したＩＤにより業者を特定することができるので、業者番号を入力または送信する必要がないようにすることができる。このような構成をとることにより、本実施形態では、業者システムにおける操作を簡素化することができ、加えて誤入力のおそれを低減することができる。
【００４５】
また、顧客システム１２０および業者システム１３０からは購買支援サーバ１１０のデータベース７０８および７０７にアクセスが可能となっており、発注から決済までの間において取引が現在どの処理にあるか進捗状況を確認することができる。例えば、業者システム１３０からは売上予定の取引が既に検収されているのかといった現在の状況や、いつごろ送金が行われるか（振込の場合は振込されたかどうか）なども確認することができるので、このようなシステムでは本実施形態のような振込通知などは必ずしも要らないようにすることもできる。なお、本実施形態では顧客用の売上データベース７０８および業者用の売上データベース７０７は、マスタである売上情報データベース７０６から生成され、管理される。また、本実施形態では顧客システム１２０は特定の企業を前提にしているため、請求処理は通常予め決まっているが、複数の顧客の場合顧客ごとに請求処理が異なる、例えば締め日や請求日が異なるため、このような情報も購買支援サーバ１１０に記憶しておいて、照会時に利用することができる。
【００４６】
顧客システム１２０や業者システム１３０からのアクセスを考慮して、図７に示すようにユーザ登録・照会や取引明細照会などが可能なように購買支援サーバ１１０ではパスワード認証機能７０３を備えている。このような処理、および上述の進捗管理処理などのため購買支援サーバ１１０はユーザ管理用に顧客データベース７０４および業者データベース７０５を備えることができる。
【００４７】
また、本実施形態では購買支援サーバ１１０において取引明細が管理されるため、その情報を流用できれば、顧客システムにおいても管理が容易になる。そこで購買支援サーバ１１０は取引明細や売上情報を顧客システム１２０に提供できるようにすることもできる。一方、顧客システム１２０が独自のフォーマットで発注や取引明細を管理している場合は、購買支援サーバ１１０でそのような顧客システムに合わせたフォーマットで種々のデータを提供することができるので、本実施形態のシステムへの移行がさらに容易にできることとなる。
【００４８】
（第２実施形態）
以上、顧客システムで独自の発注システムを有している顧客に本発明の原理を導入した場合のシステムである第１実施形態について説明したが、本実施形態では、そのような独自システムを有しない場合のシステムについて説明する。本実施形態でも基本的にはシステム構成は図１を参照して説明した第１実施形態と同様であり、図３ないし６を参照して説明したモジュール構成も同様であるが、顧客システムなどの各コンポーネント間のやり取りは、第１実施形態以上にＦＡＸやメール等の従来の手続で行われる場合が多い。
【００４９】
図８は、本実施形態の処理を説明するための図である。本実施形態では主に顧客システム８２０が第１実施形態と異なるだけなので、本実施形態の処理のうち見積〜売上処理（ステップ（１）〜（４））および決済要求送信処理〜決済処理（ステップ（６）〜ステップ（１０））は第１実施形態と同様なので説明を省略する。
【００５０】
したがって、納品が行われた後の顧客システム８２０の処理から説明すると、顧客は納品された商品を発注要求した取引内容あるいは業者により示された納品伝票等により確認して、相違がなければ検収処理を行って、顧客システム８２０から検収情報が購買支援サーバ８１０に送信される（ステップ（５））。ここで、検収情報はカード情報、発注番号および業者識別情報である業者番号を通知することができる方法で購買支援サーバ８１０に送られれば足りるが、一般には、購買支援サーバ８１０で指定する何らかのフォーマットで手続されることとなる。なお、本実施形態では顧客システムには独自のシステムが存在しないか、あっても購買支援サーバ８１０を改変させるほどのものではないため、特に第１実施形態で行われた売上情報の取り込みなどは行わないが、第１実施形態と同様に別途定めた方法により処理の進捗などを顧客システム８２０などから問い合わせることは可能である。
【００５１】
本実施形態では、顧客企業は第１実施形態の顧客と異なり独自のシステムを有していないため、１つの購買支援サーバで複数の顧客企業の顧客システムを処理することができる。また、上述の通り業者システムも複数あり、図７に示す顧客マスタデータベース７０４や業者マスタデータベース７０５により管理される。本実施形態の購買支援サーバにはこのようなマスタデータが備えられているので、顧客システムから業者の情報を検索したり、業者システムから顧客情報を検索したりすることがで、第１実施形態と同様顧客システムおよび業者システムから売上予定データの照会が可能である。
【００５２】
以上、本実施形態の特徴的な処理について説明したが、これにより従来のパーチェシングカードで必要だった専用端末や業者側でのオーソリ処理が不要になり、本発明の決済処理を用いた効率的な購買処理が可能になる。
【図面の簡単な説明】
【００５３】
【図１】本発明にかかる一実施形態のシステム全体の構成を示す図である。
【図２】本実施形態の処理を説明するための図である。
【図３】本発明の一実施形態の購買支援サーバのモジュール構成を示すブロック図である。
【図４】本発明の一実施形態の顧客システムのモジュール構成を示すブロック図である。
【図５】本発明の一実施形態の業者システムのモジュール構成を示すブロック図である。
【図６】本発明の一実施形態の決済処理サーバのモジュール構成を示すブロック図である。
【図７】本発明にかかる一実施形態のセキュリティシステムを示す図である。
【図８】本発明にかかる一実施形態のシステム全体の構成を示す図である。
【符号の説明】
【００５４】
１１０、８１０  購買支援サーバ
１１１、１１２  データベース
１２０、８２０  顧客システム
１２１、１２２  端末
１２３、１２４  データベース
１３０  業者システム
１３１、１３２  端末
１３３  データベース
１４０  決済処理サーバ
３０１  情報受信部
３０２  データ送信部
３０３  決済要求部
３０４  業者進捗処理部
３０５  顧客進捗処理部
３０６  取引明細処理部
４０１  発注要求部
４０２  検収処理部
４０３  顧客情報問合部
４０４  データ送受信部
４１０  サーバ
５０１  納品指示部
５０２  売上処理部
５０３  業者問合部
５０４  送受信部
６０１  請求発行部
６０２  支払処理部
６０３  送受信部
７０３  パスワード認証機能
７０４  顧客データベース
７０５  業者データベース
７０６  売上情報データベース
７０７  業者売上データベース
７０８  顧客売上データベース
【図１】
2008123286.tif 000003
【図２】
2008123286.tif 000004
【図３】
2008123286.tif 000005
【図４】
2008123286.tif 000006
【図５】
2008123286.tif 000007
【図６】
2008123286.tif 000008
【図７】
2008123286.tif 000009
【図８】
2008123286.tif 000010