説明

決済処理システムおよび方法

【課題】従来の購買システムからスムーズにパーチェシングカードを使用した購買システムを可能とする。
【解決手段】購買支援サーバ110には、売上予定情報や検収情報等を受信する情報受信部301、決済処理要求等を送信するデータ送信部302、決済処理についての処理を実行する決済要求部303を備え、本実施形態の基本的な購買支援に関する処理を実行する。これに加え、業者端末からの問い合わせに対応するための進捗管理等を実行する業者進捗処理部304、顧客端末からの問い合わせに対応するための進捗管理等を実行する顧客進捗処理部305、取引明細の処理を実行する取引明細処理部306なども備え、より厚い支援を実行することができる。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、決済処理システムおよび方法に関し、より詳細にはパーチェシングカードを使用した発注における決済処理システムおよび方法に関する。
【背景技術】
【0002】
従来から、事務用品や部材などを企業が業者から購入する場合にクレジット決済システムを活用して、支払い処理などを支援するパーチェシングカードが提案されている(例えば、特許文献1参照)。パーチェシングカードシステムは、納品された事務用品や部材などを発注する場合、その支払いを企業向けのクレジットカード方式のカードにより決済することにより、企業向けにクレジットカードの利便性を実現するものである。このようなシステムを用いることにより、企業は購入時の支払いが容易になるという利点がある。
【0003】
【特許文献1】特開2002−216058号公報
【発明の開示】
【発明が解決しようとする課題】
【0004】
しかしながら、多くの企業で各々独自の購買システムを有しており、それぞれ異なる発注フォームを持っていたり、納入業者との独自の伝票管理などを行っていたりするため、支払い部分だけクレジットカードの決済機能を使用する従来のパーチェシングカードでは、これらに対応できず、ほとんど使用されていないという問題がある。
【0005】
また、単に決済機能を提供するのみであれば、金融機関を用いた振込処理や、ネットバンキングなどでもある程度代用することができ、システムの利用促進のためには有効な付加機能が必要である。
【0006】
本発明は、このような問題に鑑みてなされたもので、一意の発注番号を使用することにより、従来の購買システムからスムーズにパーチェシングカードを使用した購買システムを可能とする決済処理システムおよび方法を提供することを目的とする。また、企業の発注管理や、納入業者の納入処理などを効率化する決済処理システムおよび方法を提供することも目的とする。
【課題を解決するための手段】
【0007】
このような目的を達成するために、本出願の請求項1に記載の発明は、決済処理システムであって、発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を送信する発注手段と、発注識別情報で識別される発注に対応する納品が行われた場合、発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を送信する検収送信手段とを含む顧客装置と、発注要求を受信すると、商品識別情報で識別される商品の納品を指示する納品指示手段と、発注識別情報と、発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む発注要求に対応する売上予定情報を送信する売上送信手段とを含む業者装置と、顧客装置および業者装置から売上予定情報および検収情報をそれぞれ受信し、発注識別情報によって受信した売上予定情報と受信した検収情報とが対応すると判定される場合は、売上予定情報に含まれる業者識別情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する決済要求手段を含む購買支援装置と、購買支援装置から決済処理要求を受信すると、カード情報で特定されるカードの顧客に対する支払請求処理の指示を行う請求指示手段と、受信した決済処理要求の売上に関する売上予定情報を送信した業者装置の業者に対応する支払処理をするよう支払指示を行う支払手段とを含む決済処理装置とを備えたことを特徴とする。
【0008】
請求項2に記載の発明は、請求項1に記載の決済処理システムにおいて、発注要求は、取引識別情報をさらに含み、購買支援装置は、記憶手段に記憶された取引識別情報とカード情報との対応付け情報により、取引上識別情報で識別される取引の決済に使用されるカードのカード情報を抽出するカード情報抽出手段をさらに含むことを特徴とする。
【0009】
請求項3に記載の発明は、請求項2に記載の決済処理システムにおいて、取引識別情報は、カード情報の一部であることを特徴とする。
【0010】
請求項4に記載の発明は、請求項1、2または3に記載の決済処理システムにおいて、購買支援装置は、発注識別情報により識別される売上の決済処理の進捗情報を、売上情報を送信した業者装置に送信する業者進捗送信手段をさらに含むことを特徴とする。
【0011】
請求項5に記載の発明は、請求項1ないし4のいずれかに記載の決済処理システムにおいて、購買支援装置は、カード情報で特定されるカードの顧客からの発注についての売上の決済処理の進捗情報を顧客装置に送信する顧客進捗送信手段をさらに含むことを特徴とする。
【0012】
請求項6に記載の発明は、請求項1ないし5のいずれかに記載の決済処理システムにおいて、購買支援装置は、業者識別情報で特定される業者についての取引明細情報を業者の業者装置に送信する業者明細送信手段をさらに含むことを特徴とする。
【0013】
請求項7に記載の発明は、請求項1ないし6のいずれかに記載の決済処理システムにおいて、購買支援装置は、カード情報で特定されるカードの顧客からの発注について取引明細情報を顧客装置に送信する顧客明細送信手段をさらに含むことを特徴とする。
【0014】
請求項8に記載の発明は、購買支援装置であって、顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って商品識別情報で識別される商品の納品を指示する業者装置から送信された発注識別情報と、発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む発注要求に対応する売上予定情報を受け取る売上予定情報受信手段と、発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信手段と、発注識別情報によって、業者装置から受信した売上予定情報と顧客装置から受信した検収情報とが対応すると判定される場合は、売上予定情報に含まれる業者識別情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する決済要求手段とを備えたことを特徴とする。
【0015】
請求項9に記載の発明は、顧客装置、業者装置および決済処理装置を備え、顧客の発注に基づき納品された商品の決済処理を行う決済処理システムにおいて実行される決済処理方法であって、顧客装置によって、発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を送信し、発注識別情報で識別される発注に対応する納品が行われた場合、発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を送信する顧客ステップと、業者装置によって、発注要求を受信すると、商品識別情報で識別される商品の納品を指示し、発注識別情報と、発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む発注要求に対応する売上予定情報を送信する業者ステップと、決済処理装置によって、顧客装置および業者装置から売上予定情報および検収情報をそれぞれ受信し、発注識別情報によって受信した売上予定情報と受信した検収情報とが対応すると判定される場合は、売上予定情報に含まれる業者識別情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する購買支援ステップと、決済処理装置が、購買支援装置から決済処理要求を受信すると、カード情報で特定されるカードの顧客に対する支払請求処理の指示を行い、受信した決済処理要求の売上に関する売上予定情報を送信した業者装置の業者に対応する支払処理をするよう支払指示を行う決済処理ステップとを備えたことを特徴とする。
【0016】
請求項10に記載の発明は、請求項9に記載の決済処理方法において、発注要求は、取引識別情報をさらに含み、購買支援ステップは、記憶手段に記憶された取引識別情報とカード情報との対応付け情報により、取引上識別情報で識別される取引の決済に使用されるカードのカード情報を抽出するカード情報抽出ステップをさらに含むことを特徴とする。
【0017】
請求項11に記載の発明は、請求項2に記載の決済処理方法において、取引識別情報は、カード情報の一部であることを特徴とする。
【0018】
請求項12に記載の発明は、請求項9、10または11に記載の決済処理方法において、購買支援ステップは、発注識別情報により識別される売上の決済処理の進捗情報を、売上情報を送信した業者装置に送信する業者進捗送信ステップを含むことを特徴とする。
【0019】
請求項13に記載の発明は、請求項9ないし12のいずれかに記載の決済処理方法において、購買支援ステップは、カード情報で特定されるカードの顧客からの発注についての売上の決済処理の進捗情報を顧客装置に送信する顧客進捗送信ステップを含むことを特徴とする。
【0020】
請求項14に記載の発明は、請求項9ないし13のいずれかに記載の決済処理方法において、購買支援ステップは、業者識別情報で特定される業者についての取引明細情報を業者の業者装置に送信する業者明細送信ステップを含むことを特徴とする。
【0021】
請求項15に記載の発明は、請求項9ないし14のいずれかに記載の決済処理方法において、購買支援ステップは、カード情報で特定されるカードの顧客からの発注について取引明細情報を顧客装置に送信する顧客明細送信ステップを含むことを特徴とする。
【0022】
請求項16に記載の発明は、顧客の発注に基づき納品された商品の決済処理の支援を行う購買支援装置において実行される購買支援処理方法であって、売上予定情報受信手段によって、顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って商品識別情報で識別される商品の納品を指示する業者装置から送信された発注識別情報と、発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む発注要求に対応する売上予定情報を受け取る売上予定情報受信ステップと、検収情報受信によって、発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信ステップと、決済要求によって、発注識別情報によって、業者装置から受信した売上予定情報と顧客装置から受信した検収情報とが対応すると判定される場合は、売上予定情報に含まれる業者識別情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する決済要求ステップとを備えたことを特徴とする。
【0023】
請求項17に記載の発明は、購買支援装置に、顧客の発注に基づき納品された商品の決済処理の支援である購買支援処理を実行させるプログラムであって、売上予定情報受信手段によって、顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って商品識別情報で識別される商品の納品を指示する業者装置から送信された発注識別情報と、発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む発注要求に対応する売上予定情報を受け取る売上予定情報受信ステップと、検収情報受信によって、発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信ステップと、決済要求によって、発注識別情報によって、業者装置から受信した売上予定情報と顧客装置から受信した検収情報とが対応すると判定される場合は、売上予定情報に含まれる業者識別情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する決済要求ステップとを実行することを特徴とする。
【発明の効果】
【0024】
以上説明したように、本発明によれば、顧客装置および業者装置から売上予定情報および検収情報をそれぞれ受信し、発注識別情報によって受信した売上予定情報に対応する検収情報を受信した場合は、売上予定情報で特定される業者の売り上げの、カード情報により特定されるカードによる決済処理要求を送信する決済要求手段を含む購買支援装置を備えているので、一意の発注番号を使用することにより、従来の購買システムからスムーズにパーチェシングカードを使用した購買システムを可能とする決済処理システムおよび方法を提供することが可能となる。
【発明を実施するための最良の形態】
【0025】
(第1実施形態)
以下、図面を参照しながら本発明の実施形態について詳細に説明する。
図1は、本発明にかかる第1実施形態のシステム全体を示すブロック図である。
【0026】
(本実施形態のシステム構成)
本実施形態の決済処理システムでは、大きく分けて購買支援サーバ110、顧客システム120、業者システム130および決済処理サーバ140がネットワークで接続されている。購買支援サーバ110は、本実施形態のシステムの中心的な機能を実行する部分であり、本実施形態の決済処理に関して顧客側処理と業者側処理とを支援し、データベース111〜112を備えている。なお、図1においては、1つの購買支援サーバ110が示されているが、実行される機能を複数のサーバに分散させて全体として図1に示す購買支援サーバ110を実現することもできる。ここで、以上のシステムあるいはサーバは相互に何らかのネットワークにより接続されている。このネットワークにはインターネットを含むことができるが、一方で、専用回線により接続することもできるし、一部のやり取りをFAXやその他の従来の手続により行うこともできる。その他、接続のハードウェアあるいはソフトウェアについては特定の規格、製品を採用する必要はなく、本技術分野で知られたいずれの手法、構成によってもデータのやりとりが可能であれば本願発明の目的を達することができる。なお、本明細書でシステムは端末、サーバおよびデータベースのいずれかを含むものであるが、本願発明を実装するためにはこのようなものでなくても、データ通信、データ処理およびデータの管理が可能なものであれば、いずれの装置、機器を用いてシステムを構成することもできる。
【0027】
また、顧客システム120は、本実施形態の顧客側の処理を実装する部分であり、取引の照会を行う端末121や検収処理などを実行する端末122などを備え、さらにデータベース123および124を備える。ここで、顧客システム120は所定の端末およびデータベースを備えるが、これに限られることなく1台の端末で処理を実行することもできるし、より多くの端末やデータベースに機能、データを分けて実装することもできる。
【0028】
業者システム130は、顧客に種々の商品を納入する業者側の処理を実装するものであり、通常のクレジットカードシステムにおいてはいわゆる加盟店装置あるいはシステムに相当する。本実施形態では、顧客システム120と同様に取引の照会などを行う端末131や売り上げ処理などを行う端末132、およびデータベース133を備えるが、上述の顧客システム120と同様、図1に示すのとは異なる種々の形態で構成することができる。一般的には、顧客である企業は様々な業者と取引をしており、このような業者システム130は複数存在しているが、図1等では便宜上あるいは説明の都合上1つだけで例示させて説明するものとする。
【0029】
決済処理サーバ140は、本質的には通常のクレジットカードシステムあるいはパーチェシングカードシステムと同様の機能を備えている。これは、本実施形態において従来の顧客システムや業者システムの処理と異なる部分の処理を購買支援サーバ110においてできる限り吸収することによって可能としている。すなわち、例えば通常のクレジットカード処理システムでは業者システムに相当する加盟店の端末から決済処理サーバに売上情報が直接送信され、これに基づいて決済処理が行われるが、本実施形態では業者システムから売上予定データがいったん購買支援サーバ110に送信され、顧客システム120からの検収の情報を待って実際の売り上げ情報の送信、つまり決済処理要求を行う。このような処理を行うことにより、通常は加盟店からの確定的な売り上げ情報を受信して決済処理を行う決済処理サーバ140に同様の送信を行うことが可能となり、従来のクレジットカードあるいはパーチェシングカードの処理自体を流用し、あるいは処理スキームを用いることができる。ここで、このような処理を可能にするため本発明では発注から決済要求までの間で取引内容を特定できるよう発注識別情報である発注番号を付与する。この発注番号はその取引が終了するまで共通して用いられ、これにより取引が常に特定できることとなる。
【0030】
(本実施形態のモジュール構成)
本システムの全体の構成は以上のようなものであるが、本実施形態の個別のシステムを構成する端末、サーバは少なくともネットワークに接続可能な通常のコンピュータの機能を有している必要がある。このようなハードウェアの条件の下、本実施形態の個別のシステムの処理の実行はソフトウェアプログラムがこのようなハードウェアにインストールされて行われる。各ソフトウェアは例えば図3ないし図6に示すようなモジュール構成で示すことができるが、これは単なる例示であり、各モジュールの機能をさらにいくつかのモジュールで分担したり、いくつかのモジュールの機能を統合したモジュールを想定したりすることができるのはいうまでもない。以下に、各個別システムのモジュール構成を説明するが、これらのモジュールが相互に連携を取って実行され、後述する本実施形態の処理が達成されるのである。なお、本実施形態では図4に示す顧客システム120および図5に示す業者システム130の処理は、各サーバまたは端末がソフトウェアによって処理するよう説明しているが、本願発明を実施するためにはこれに限られず、図3に示す購買支援サーバ110および図6に示す決済処理サーバ140以外の構成の一部または全部をこのようなソフトウェアの処理とせずに、購買支援サーバ110および決済処理サーバ140への情報の伝達をFAXやメール等の従来の通信手法により行うこともできる。
【0031】
図3は、購買支援サーバ110のモジュール構成を示す図である。購買支援サーバ110には、売上予定情報や検収情報等を受信する情報受信部301、決済処理要求等を送信するデータ送信部302、決済処理についての処理を実行する決済要求部303を備え、本実施形態の基本的な購買支援に関する処理を実行する。これに加え、業者端末からの問い合わせに対応するための進捗管理等を実行する業者進捗処理部304、顧客端末からの問い合わせに対応するための進捗管理等を実行する顧客進捗処理部305、取引明細の処理を実行する取引明細処理部306なども備え、より厚い支援を実行することができる。
【0032】
図4は、顧客システム120のモジュール構成を示す図である。図4においては、システムの中心にサーバ410を備え、これに接続された端末121、122からの指示により、本実施形態の主な処理をサーバ410が実行するように示されているが、これに限られることなく、端末121、122にサーバ410と同様の機能を持たせて各々単独で処理を実行するようにすることもできる。サーバ410、したがって顧客システムは、発注要求を実行する発注要求部401、検収処理の入力を受けて検収情報を送信する検収処理部402、および種々のデータ通信を処理するデータ送受信部404を本実施形態の基本機能を実行するモジュールとして備える。さらに、購買支援サーバ110への種々の問い合わせを処理する顧客情報問合部403を備える。
【0033】
図5は、業者システム130のモジュール構成を示す図であり、顧客システム120のモジュール構成と同様、図に示す例ではシステムの主な処理はサーバにより行われるが、これに限られない。業者システム130は、本発明の基本処理を行うモジュールとして、顧客からの発注に基づき納品を指示する納品指示部501、売上予定情報を作成等する売上処理部502および種々のデータ通信を行う送受信部504を備える。さらに、売上予定情報送信後の売上処理の進捗の問い合わせ等を行う業者問合部503を備える。
【0034】
図6は、決済処理サーバ140のモジュール構成を示す図であり、ハードウェア構成は上述の各個別システムと同様種々の形態をとることができる。また、決済処理サーバあるいはシステムは本技術分野で広く知られているものであり、様々な方式や付加機能を有するものが多く知られているため、ここでは、本実施形態の説明上必要と考えられる部分だけに絞って説明するが、必要であればこのような既に知られている技術を考慮して理解することもできる。決済処理サーバ140は、本実施形態で必要な基本処理を実行するモジュールとして、顧客に請求書を発行したりする請求発行部601、業者に売り上げ情報に対応する支払指示等を行う支払処理部602および種々のデータ通信を行う送受信部603を備える。ここで、上述の通りクレジットカードあるいはパーチェシングカードによる決済処理においては、一般に請求書を発行するといった請求処理だけではなく、その後所定の口座から請求額を引き落としたり、振込を受け取ったり、場合によっては受け取り書を送信したりする処理により請求処理は完結する。本実施形態では、請求処理に伴う、あるいは引き続き必要となるこのような処理については特に説明しないが、本実施形態で請求処理と言った場合、これに伴う、あるいは引き続き必要な種々の本技術分野で知られた処理が行われるものとする。したがって、請求処理以外の処理を行うシステムも本発明の範囲に含まれるのはもちろん、そのような本実施形態で説明しない処理にここで言う請求処理がどのような形態で組み込まれていても、そのようなもの全体を指して請求処理と呼ぶことができるものとする。支払指示についても実際には振込処理やその他の送金処理が引き続いて行われるが、請求処理と同様に解釈するものとする。
【0035】
(本実施形態の処理)
以上、本実施形態の構成について説明したが、図2を参照して以上の構成を持つシステムを用いた本実施形態の処理を説明する。図2は、本実施形態の処理を説明するための図である。本実施形態では原則として図2に示す番号の順番に処理が行われるが、これはあくまで本実施形態のようなシステムの典型的な流れであって、常にこのような順序である必要はなく、一部順序を変更したり、一部の手順を入れ替えたり、異なる手順を加えることもできる。
【0036】
この処理の前提として、本実施形態の顧客システムは一定の発注および検収システムを有しており、業者システムとは、そのような顧客システムに独自なシステムで処理を行うものとする。顧客システムにおいて商品の発注処理を行うときは、先ず品目、数量、金額について業者システムから予め情報を入手しておき(ステップ(1))、この情報をもとに発注処理を行う。なお、図2に示される各処理のカッコ内の情報はその処理により送られる情報を示しているが、これに限られず本願発明の効果を奏するためにより少ないまたはより多い情報を含めることができる。発注処理は、希望する品目、数量、金額を決定して行うが、顧客システム120では、このような情報とともにパーチェシングカードのカード番号が指定されて発注が入力されると、発注要求部401は発注識別情報である発注番号を設定して業者端末130に発注要求を送信する(ステップ(2))。
【0037】
ここで、本実施形態の発注要求にはカード番号の代わりに取引番号が用いられ、業者側にはカード番号が直接知られないようにしている。これにより、セキュリティを確保するとともに顧客側の安心感を得ることができる。本実施形態では、この取引番号はカード番号の一部、例えばカード番号が16桁とすると下8桁を使用するようにすることができるが、これに限られず取引を特定できる情報であればいずれのものも使用することができ、取引番号自体使用しなくても本願発明の効果を奏することができる。すなわち、本実施形態では顧客システム120、業者システム130および購買支援サーバ110の間で発注識別情報である1つの発注番号を一貫して用いることにより取引を特定できるため、取引番号を付与するか否かで本願発明の権利範囲は限定されない。このような意味で、本実施形態で、発注番号に加え敢えて取引番号を使用するのは、情報に冗長性を持たせることにより、本実施形態のシステムを用いる使用者が誤入力をした場合などに対応するためでもあるということができる。すなわち、例えば売上予定情報が送られてきた場合に、取引番号によりカード番号や顧客を特定して、送られた情報に誤りがないかチェックすることができ、そのような誤りが検出されたときは、業者端末にそれを表示して報知したり、修正を促したりすることができる。また、カード番号(あるいはその一部として使用する取引番号)についてチェックデジットを使用したり、入力項目の桁数チェックをしたりすることによっても入力誤り、登録ミスなどを未然に防止することができる。
【0038】
なお、本実施形態の取引番号は売上予定情報とともに購買支援サーバ110に送られ、購買支援サーバ110側で予め用意された取引番号とカード番号との対応付データを参照してカード番号に置き換えることができ、購買支援サーバ110、顧客システム120および決済処理サーバ140においてはカード番号を相互にやり取りして取引の特定や、その他の確認処理をすることができる。特に本実施形態では、カード番号の上8桁を顧客ごとに定めておいて、業者側から送られた下8桁と合体させるだけで元のカード番号を生成することもできる。
【0039】
発注要求を受信した業者システム130は、納品指示部501が発注要求に含まれる商品、数量などに基づいて納品の指示を行う。その結果、要求された商品が顧客に納品される(ステップ(3))とともに、売上処理部502は、発注要求および納品状況に基づき、発注番号を含む売上予定情報を作成し購買支援サーバ110に送信するようにする(ステップ(4))。ここで、購買支援サーバ110に送られるのは、あくまで売上予定の情報である。これは、従来のパーチェシングカードシステムでは業者からはオーソリがなされた後で売上情報を決済処理サーバに送っていたが、本実施形態では後述するように別途顧客側から入手する検収情報により漸く売上情報として確定してから購買支援サーバが送信するため、購買支援サーバに送られるのは売上予定にならざるを得ないからである。
【0040】
本実施形態のステップ(3)および(4)で業者システムは、送信する情報に請求番号を生成して含めることができる。これは、業者システム内で専ら使用する請求番号を生成することにより、納品は顧客に対してであるのに、支払は決済サーバからなされるというアンバランスを解消するためのものであり、この請求番号をキーにすることにより、突合処理や、照会処理を効率よく行うことができる。
以上により、発注、納品が完了すると、顧客側では発注した納品が確実にされたかどうかを確認する、いわゆる検品を行うが、本実施形態のシステムでは顧客システムに取引明細のデータベース123または124を有しており、まず発注した情報により納品の確認、すなわち検品を行う。その後、購買支援サーバ110が業者システム130から受信した売上予定情報を顧客システム120が取り込み(ステップ(5))、その情報と検品の結果とを照合し(ステップ(6))、検収の入力を行う。検収の入力が行われると、検収処理部402は発注番号および納品された商品の情報を含む検収情報を購買支援サーバ110に送信する(ステップ(7))。ここで、納品が不足している場合や、発注内容が変更されている場合などを検収情報に反映させることもできる。なお、本実施形態では顧客システムは発注した情報に基づいて検品を行うが、購買支援サーバ110から売上予定情報を入手して検品に使用することもできる。
【0041】
このように、業者システム130および顧客システム120からそれぞれ売上予定情報および検収情報が購買支援サーバ110に送信されることにより、従来のパーチェシングカードにおいて納品時に行っていたオーソリ処理が、結果的に完了したことになるため、購買支援サーバ110は、決済処理サーバ140に売上情報を送信して決済処理を要求することができる。具体的には、情報受信部301において上記の各情報を受信すると、決済要求部303は、売上予定情報と検収情報とを比較して検収が行われた売上について売上情報を作成し、決済処理サーバ140に決済処理要求を送信する(ステップ(8))。ここで、通常のパーチェシングカードあるいはクレジットカードのシステムでは、売上とともにほぼリアルタイムで送信されるか、または加盟店の都合に合わせて送信されるが、本実施形態の決済処理要求は、ネットワークのトランザクションやシステムの環境、条件に考慮して月1回まとめて送信される。ただし、これは任意のタイミングで行うことができ、月1回に限らず、複数回送信したり、都度送信したりすることもできる。なお、本実施形態では、このような処理を通じて売上予定データを記憶するデータベース111から検収済みの売上予定データ(売上データ)を記憶するデータベース112へと切り替え管理されるが、本技術分野で知られたその他の方法でデータ管理することもできる。
【0042】
決済処理要求を受信した決済処理サーバ140は、業者に振込通知を行った上で(ステップ(9))、売上代金の振込を行う(ステップ(10))が、上述の通り決済処理サーバは種々の方法により送金処理が行われるので、本実施形態の例に限られることはない。同様に顧客に対しては請求書送付等の請求処理(ステップ(11))、およびこれに基づく顧客からの支払処理が行われるが、本発明を実装するために本実施形態と同じ処理をする必要がないことはいうまでもない。顧客から支払われる手数料についてもまた同様である。さらに、この手数料については、顧客側から一定の手数料を業者側に求める場合は、購買支援サーバ側で予め業者側に課す手数料を盛り込んだ金額を算出して、売上処理をすることもでき、この目的で、各業者ごとに課す手数料を顧客システムから予め入力し、格納しておくデータベースを備えることができる。また、業者側に手数料を課す別の方法としては、顧客側に請求する際に、上記で説明した手数料を請求せずに手数料を差し引いた額を業者側に送金するようにすることもできる。したがって、業者および顧客との種々の取引条件を格納しておくことにより、本技術分野で知られる様々な方法で請求、送金などの処理が可能となる。
【0043】
(本実施形態のその他の処理)
上記では、本実施形態の基本機能である発注から決済までの各処理について説明したが、これにより従来のパーチェシングカードでは困難であった顧客企業側のシステムとの融合が可能になり、本発明の決済処理を用いた効率的な購買処理が可能になる。
【0044】
さらに、本実施形態のシステムでは図7に示すような各個別システム、端末などのアクセス制限を行うことによりシステム全体のセキュリティが確保される。本実施形態では、図7に示す識別情報であるIDやパスワードは各システムからの申請などにより生成され、予め通知されるが、具体的な申請方法や、ID/パスワードの生成方法などは本技術分野で知られたいずれの方法も用いることができるのでここでは詳説しない。また、申請により生成せずに他のデータベースから流用するなど別の方法も用いることができる。本実施形態では業者識別情報である業者番号および業者用に割当てられたIDの双方を用いるが、これらを統合して処理の簡素化を可能とすることもできる。すなわち、購買支援サーバ110は売上予定情報を受信する際、送信した業者を特定するため業者番号を必要とし、システムによっては売上予定情報に業者番号を含めることもできるが、業者システムから購買支援サーバにアクセスする際IDおよびパスワードを要求する場合には、アクセスの際に使用したIDにより業者を特定することができるので、業者番号を入力または送信する必要がないようにすることができる。このような構成をとることにより、本実施形態では、業者システムにおける操作を簡素化することができ、加えて誤入力のおそれを低減することができる。
【0045】
また、顧客システム120および業者システム130からは購買支援サーバ110のデータベース708および707にアクセスが可能となっており、発注から決済までの間において取引が現在どの処理にあるか進捗状況を確認することができる。例えば、業者システム130からは売上予定の取引が既に検収されているのかといった現在の状況や、いつごろ送金が行われるか(振込の場合は振込されたかどうか)なども確認することができるので、このようなシステムでは本実施形態のような振込通知などは必ずしも要らないようにすることもできる。なお、本実施形態では顧客用の売上データベース708および業者用の売上データベース707は、マスタである売上情報データベース706から生成され、管理される。また、本実施形態では顧客システム120は特定の企業を前提にしているため、請求処理は通常予め決まっているが、複数の顧客の場合顧客ごとに請求処理が異なる、例えば締め日や請求日が異なるため、このような情報も購買支援サーバ110に記憶しておいて、照会時に利用することができる。
【0046】
顧客システム120や業者システム130からのアクセスを考慮して、図7に示すようにユーザ登録・照会や取引明細照会などが可能なように購買支援サーバ110ではパスワード認証機能703を備えている。このような処理、および上述の進捗管理処理などのため購買支援サーバ110はユーザ管理用に顧客データベース704および業者データベース705を備えることができる。
【0047】
また、本実施形態では購買支援サーバ110において取引明細が管理されるため、その情報を流用できれば、顧客システムにおいても管理が容易になる。そこで購買支援サーバ110は取引明細や売上情報を顧客システム120に提供できるようにすることもできる。一方、顧客システム120が独自のフォーマットで発注や取引明細を管理している場合は、購買支援サーバ110でそのような顧客システムに合わせたフォーマットで種々のデータを提供することができるので、本実施形態のシステムへの移行がさらに容易にできることとなる。
【0048】
(第2実施形態)
以上、顧客システムで独自の発注システムを有している顧客に本発明の原理を導入した場合のシステムである第1実施形態について説明したが、本実施形態では、そのような独自システムを有しない場合のシステムについて説明する。本実施形態でも基本的にはシステム構成は図1を参照して説明した第1実施形態と同様であり、図3ないし6を参照して説明したモジュール構成も同様であるが、顧客システムなどの各コンポーネント間のやり取りは、第1実施形態以上にFAXやメール等の従来の手続で行われる場合が多い。
【0049】
図8は、本実施形態の処理を説明するための図である。本実施形態では主に顧客システム820が第1実施形態と異なるだけなので、本実施形態の処理のうち見積〜売上処理(ステップ(1)〜(4))および決済要求送信処理〜決済処理(ステップ(6)〜ステップ(10))は第1実施形態と同様なので説明を省略する。
【0050】
したがって、納品が行われた後の顧客システム820の処理から説明すると、顧客は納品された商品を発注要求した取引内容あるいは業者により示された納品伝票等により確認して、相違がなければ検収処理を行って、顧客システム820から検収情報が購買支援サーバ810に送信される(ステップ(5))。ここで、検収情報はカード情報、発注番号および業者識別情報である業者番号を通知することができる方法で購買支援サーバ810に送られれば足りるが、一般には、購買支援サーバ810で指定する何らかのフォーマットで手続されることとなる。なお、本実施形態では顧客システムには独自のシステムが存在しないか、あっても購買支援サーバ810を改変させるほどのものではないため、特に第1実施形態で行われた売上情報の取り込みなどは行わないが、第1実施形態と同様に別途定めた方法により処理の進捗などを顧客システム820などから問い合わせることは可能である。
【0051】
本実施形態では、顧客企業は第1実施形態の顧客と異なり独自のシステムを有していないため、1つの購買支援サーバで複数の顧客企業の顧客システムを処理することができる。また、上述の通り業者システムも複数あり、図7に示す顧客マスタデータベース704や業者マスタデータベース705により管理される。本実施形態の購買支援サーバにはこのようなマスタデータが備えられているので、顧客システムから業者の情報を検索したり、業者システムから顧客情報を検索したりすることがで、第1実施形態と同様顧客システムおよび業者システムから売上予定データの照会が可能である。
【0052】
以上、本実施形態の特徴的な処理について説明したが、これにより従来のパーチェシングカードで必要だった専用端末や業者側でのオーソリ処理が不要になり、本発明の決済処理を用いた効率的な購買処理が可能になる。
【図面の簡単な説明】
【0053】
【図1】本発明にかかる一実施形態のシステム全体の構成を示す図である。
【図2】本実施形態の処理を説明するための図である。
【図3】本発明の一実施形態の購買支援サーバのモジュール構成を示すブロック図である。
【図4】本発明の一実施形態の顧客システムのモジュール構成を示すブロック図である。
【図5】本発明の一実施形態の業者システムのモジュール構成を示すブロック図である。
【図6】本発明の一実施形態の決済処理サーバのモジュール構成を示すブロック図である。
【図7】本発明にかかる一実施形態のセキュリティシステムを示す図である。
【図8】本発明にかかる一実施形態のシステム全体の構成を示す図である。
【符号の説明】
【0054】
110、810 購買支援サーバ
111、112 データベース
120、820 顧客システム
121、122 端末
123、124 データベース
130 業者システム
131、132 端末
133 データベース
140 決済処理サーバ
301 情報受信部
302 データ送信部
303 決済要求部
304 業者進捗処理部
305 顧客進捗処理部
306 取引明細処理部
401 発注要求部
402 検収処理部
403 顧客情報問合部
404 データ送受信部
410 サーバ
501 納品指示部
502 売上処理部
503 業者問合部
504 送受信部
601 請求発行部
602 支払処理部
603 送受信部
703 パスワード認証機能
704 顧客データベース
705 業者データベース
706 売上情報データベース
707 業者売上データベース
708 顧客売上データベース

【特許請求の範囲】
【請求項1】
発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を送信する発注手段と、前記発注識別情報で識別される発注に対応する納品が行われた場合、前記発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を送信する検収送信手段とを含む顧客装置と、
前記発注要求を受信すると、前記商品識別情報で識別される商品の納品を指示する納品指示手段と、前記発注識別情報と、前記発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む前記発注要求に対応する売上予定情報を送信する売上送信手段とを含む業者装置と、
前記顧客装置および前記業者装置から前記売上予定情報および前記検収情報をそれぞれ受信し、前記発注識別情報によって前記受信した売上予定情報と前記受信した検収情報とが対応すると判定される場合は、前記売上予定情報に含まれる業者識別情報で特定される前記業者の売り上げの、前記カード情報により特定されるカードによる決済処理要求を送信する決済要求手段を含む購買支援装置と、
前記購買支援装置から決済処理要求を受信すると、前記カード情報で特定されるカードの顧客に対する支払請求処理の指示を行う請求指示手段と、前記受信した決済処理要求の売上に関する売上予定情報を送信した業者装置の業者に前記対応する支払処理をするよう支払指示を行う支払手段とを含む決済処理装置と
を備えたことを特徴とする決済処理システム。
【請求項2】
前記発注要求は、取引識別情報をさらに含み、前記購買支援装置は、記憶手段に記憶された該取引識別情報と前記カード情報との対応付け情報により、前記取引上識別情報で識別される取引の決済に使用されるカードのカード情報を抽出するカード情報抽出手段をさらに含むことを特徴とする請求項1に記載の決済処理システム。
【請求項3】
前記取引識別情報は、前記カード情報の一部であることを特徴とする請求項2に記載の決済処理システム。
【請求項4】
前記購買支援装置は、前記発注識別情報により識別される売上の決済処理の進捗情報を、該売上情報を送信した業者装置に送信する業者進捗送信手段をさらに含むことを特徴とする請求項1、2または3に記載の決済処理システム。
【請求項5】
前記購買支援装置は、前記カード情報で特定されるカードの顧客からの発注についての売上の決済処理の進捗情報を該顧客装置に送信する顧客進捗送信手段をさらに含むことを特徴とする請求項1ないし4のいずれかに記載の決済処理システム。
【請求項6】
前記購買支援装置は、前記業者識別情報で特定される業者についての取引明細情報を該業者の業者装置に送信する業者明細送信手段をさらに含むことを特徴とする請求項1ないし5のいずれかに記載の決済処理システム。
【請求項7】
前記購買支援装置は、前記カード情報で特定されるカードの顧客からの発注について取引明細情報を該顧客装置に送信する顧客明細送信手段をさらに含むことを特徴とする請求項1ないし6のいずれかに記載の決済処理システム。
【請求項8】
顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って前記商品識別情報で識別される商品の納品を指示する業者装置から送信された前記発注識別情報と、前記発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む前記発注要求に対応する売上予定情報を受け取る売上予定情報受信手段と、
前記発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する前記発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信手段と、
前記発注識別情報によって、前記業者装置から受信した売上予定情報と前記顧客装置から受信した検収情報とが対応すると判定される場合は、前記売上予定情報に含まれる業者識別情報で特定される前記業者の売り上げの、前記カード情報により特定されるカードによる決済処理要求を送信する決済要求手段と
を備えたことを特徴とする購買支援装置。
【請求項9】
顧客装置、業者装置および決済処理装置を備え、顧客の発注に基づき納品された商品の決済処理を行う決済処理システムにおいて実行される決済処理方法であって、
顧客装置によって、発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を送信し、前記発注識別情報で識別される発注に対応する納品が行われた場合、前記発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を送信する顧客ステップと、
業者装置によって、前記発注要求を受信すると、前記商品識別情報で識別される商品の納品を指示し、前記発注識別情報と、前記発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む前記発注要求に対応する売上予定情報を送信する業者ステップと、
決済処理装置によって、前記顧客装置および前記業者装置から前記売上予定情報および前記検収情報をそれぞれ受信し、前記発注識別情報によって前記受信した売上予定情報と前記受信した検収情報とが対応すると判定される場合は、前記売上予定情報に含まれる業者識別情報で特定される前記業者の売り上げの、前記カード情報により特定されるカードによる決済処理要求を送信する購買支援ステップと、
決済処理装置が、前記購買支援装置から決済処理要求を受信すると、前記カード情報で特定されるカードの顧客に対する支払請求処理の指示を行い、前記受信した決済処理要求の売上に関する売上予定情報を送信した業者装置の業者に前記対応する支払処理をするよう支払指示を行う決済処理ステップと
を備えたことを特徴とする決済処理方法。
【請求項10】
前記発注要求は、取引識別情報をさらに含み、前記購買支援ステップは、記憶手段に記憶された該取引識別情報と前記カード情報との対応付け情報により、前記取引上識別情報で識別される取引の決済に使用されるカードのカード情報を抽出するカード情報抽出ステップをさらに含むことを特徴とする請求項9に記載の決済処理方法。
【請求項11】
前記取引識別情報は、前記カード情報の一部であることを特徴とする請求項10に記載の決済処理方法。
【請求項12】
前記購買支援ステップは、前記発注識別情報により識別される売上の決済処理の進捗情報を、該売上情報を送信した業者装置に送信する業者進捗送信ステップを含むことを特徴とする請求項9、10または11に記載の決済処理方法。
【請求項13】
前記購買支援ステップは、前記カード情報で特定されるカードの顧客からの発注についての売上の決済処理の進捗情報を該顧客装置に送信する顧客進捗送信ステップを含むことを特徴とする請求項9ないし12のいずれかに記載の決済処理方法。
【請求項14】
前記購買支援ステップは、前記業者識別情報で特定される業者についての取引明細情報を該業者の業者装置に送信する業者明細送信ステップを含むことを特徴とする請求項9ないし13のいずれかに記載の決済処理方法。
【請求項15】
前記購買支援ステップは、前記カード情報で特定されるカードの顧客からの発注について取引明細情報を該顧客装置に送信する顧客明細送信ステップを含むことを特徴とする請求項9ないし14のいずれかに記載の決済処理方法。
【請求項16】
顧客の発注に基づき納品された商品の決済処理の支援を行う購買支援装置において実行される購買支援処理方法であって、
売上予定情報受信手段によって、顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って前記商品識別情報で識別される商品の納品を指示する業者装置から送信された前記発注識別情報と、前記発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む前記発注要求に対応する売上予定情報を受け取る売上予定情報受信ステップと、
検収情報受信によって、前記発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する前記発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信ステップと、
決済要求によって、前記発注識別情報によって、前記業者装置から受信した売上予定情報と前記顧客装置から受信した検収情報とが対応すると判定される場合は、前記売上予定情報に含まれる業者識別情報で特定される前記業者の売り上げの、前記カード情報により特定されるカードによる決済処理要求を送信する決済要求ステップと
を備えたことを特徴とする購買支援方法。
【請求項17】
購買支援装置に、顧客の発注に基づき納品された商品の決済処理の支援である購買支援処理を実行させるプログラムであって、
売上予定情報受信手段によって、顧客からの発注識別情報および発注を要求する商品を識別する商品識別情報を含む発注要求を受け取って前記商品識別情報で識別される商品の納品を指示する業者装置から送信された前記発注識別情報と、前記発注要求に対応する納品を指示した業者を識別する業者識別情報とを含む前記発注要求に対応する売上予定情報を受け取る売上予定情報受信ステップと、
検収情報受信によって、前記発注識別情報で識別される発注に対応する納品が行われた顧客装置が送信する前記発注識別情報を含む検収情報および決済処理に使用するカードのカード情報を受信する検収情報受信ステップと、
決済要求によって、前記発注識別情報によって、前記業者装置から受信した売上予定情報と前記顧客装置から受信した検収情報とが対応すると判定される場合は、前記売上予定情報に含まれる業者識別情報で特定される前記業者の売り上げの、前記カード情報により特定されるカードによる決済処理要求を送信する決済要求ステップと
を実行することを特徴とするプログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate


【公開番号】特開2008−123286(P2008−123286A)
【公開日】平成20年5月29日(2008.5.29)
【国際特許分類】
【出願番号】特願2006−307025(P2006−307025)
【出願日】平成18年11月13日(2006.11.13)
【出願人】(594103301)三井住友カード株式会社 (39)