CN1203437C - System and method for verifying commercial transactions - Google Patents

System and method for verifying commercial transactions Download PDF

Info

Publication number
CN1203437C
CN1203437C CN 01812985 CN01812985A CN1203437C CN 1203437 C CN1203437 C CN 1203437C CN 01812985 CN01812985 CN 01812985 CN 01812985 A CN01812985 A CN 01812985A CN 1203437 C CN1203437 C CN 1203437C
Authority
CN
China
Prior art keywords
account holder
confirming
advance
trading approving
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CN 01812985
Other languages
Chinese (zh)
Other versions
CN1449537A (en
Inventor
戴维·N·哈里斯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/617,361 external-priority patent/US8380628B1/en
Application filed by Individual filed Critical Individual
Publication of CN1449537A publication Critical patent/CN1449537A/en
Application granted granted Critical
Publication of CN1203437C publication Critical patent/CN1203437C/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Selective Calling Equipment (AREA)

Abstract

A system and method verify a commercial transaction between a card-holder, a merchant, and a credit card company. The card-holder makes a purchase with the merchant using a full credit card number. The merchant submits a transaction approval request for approval with the credit card company (702). The credit card company executes conventional credit approval of the transaction approval request (704, 706), as well as verifies the transaction approval request with the card-holder (710). An approval is sent to the merchant only after the transaction approval request is both conventionally approved by the credit card company and verified by the card-holder (714). The card-holder, or the credit card company, may initiate verification of the transaction approval request. The request can also be automatically verified if one or many pre-verification criteria are satisfied by data contained in the request. The pre-verification criteria can be initially determined and/or modified by the card holder.

Description

The verifying commercial transactions system and method
Technical field
Present invention relates in general to ecommerce, relate in particular to a kind of system and method that is used to provide secure electronic transaction.More specifically, the present invention relates to be used to be convenient to a kind of method and system that the account holder confirms electronic business transaction.
Background technology
Ecommerce by the electronic method dealing has become a common thing in modern society's life.Along with popularizing of the Internet (especially WWW), ecommerce has moved towards to have the family and the office at anyone place of computing machine.Owing to a plurality of reasons, increasing people will be chosen in make business on the computing machine of their family or office (for example, shopping).For example, because typically provide the discounting commodity item, so the consumer is attracted to Internet commerce based on the commercial affairs of the Internet.In addition, the Internet can both be visited in one day 24 hours, thereby had made things convenient for consumer's shopping.
The main mode that the most consumers electronic business transaction is paid is to use credit card.Credit card has been represented predetermined house account of holder.The holder uses a credit card and businessman to carry out electronic transaction.Businessman submits to credit card company buying request (comprise and send complete credit card number), is used for buying and authorizes.The credit card trade of credit card company's mandate or rejection and described businessman.If this purchase is given the ratification, then from being scheduled to cut in the house account amount of money of described purchase.
Credit card brings many advantages for the card holder.For example, spend in bank and for account's balance between revenue and expenditure with the people of credit card and check and the time less of savings bank need.In addition, credit card has been eliminated the demand of carrying buckets of cash.And, when using credit card, can buy approval automatically, the purchase approval of check or cash order is then incured loss through delay.So, when buying, utilize credit card to eliminate and send the delay that geld interrelates by mail by phone or mail order.
As the consequence that ecommerce increases, credit card safety has become the main focus of card holder.Some card holders are intercepted owing to the credit card number of worrying them or be stolen, and are very careful to utilizing credit card to carry out shopping online.Because the used HTML (HTML) of most of internet webpages has adopted the method for pregnable forwarding information, their worry is justified.In order to solve the internet security problem, some commercial network have used encryption technology to guarantee the safety of online transaction.This does not give the consumer who is concerned about how many comforts, because the offender of high iq can crack these encryption technologies.In addition, even the transmission of credit card number is safe, described credit card number still will be stored on take over party's computing machine, and can be stolen by swarming into this computing machine.In addition, credit card number can also directly be stolen from card by the equipment such as pocket scanner of uses such as dishonest waiter, administrator.
Some commercial account (for example, check account) provides debit card, does not at least also face with the same security risk of credit card if increase it.Debit card and credit-card type seemingly, yet, in order to finish, when buying, except card number, also must provide card holder's Personal Identification Number (PIN) by means of account transaction.In addition, debit card extraction fund from the account's (being typically check account) who interrelates with it.In most of the cases, in company with debit card transaction PIN that provides and the PIN identical (for example, by ATM or phone) that is used to visit the account who interrelates with described debit card.If the transaction that utilizes debit card to carry out is intercepted or be stolen, then this thief can utilize debit card number and PIN shopping, can directly go up the extraction fund from the relevant account account that borrows again.
To improving the concern of credit card security, impel will the give security method of secure electronic transaction of credit card company and businessman.For example, United States Patent (USP) the 6th, 012,144 (Pickett) have been described a kind of method of maintaining Internet credit card trade safety, this method is by credit card number being divided into two sections, and realizing on the data storage device of every section separation that is stored in one or more server computer.This card holder determines which part of credit card number will be sent to each memory device, and determines a plurality of processing codes (password).Can obtain from the card holder by automatic telephone call after handling code, so that can confirm described purchase there.This method has several shortcomings.The first, the method for Pickett is extremely time-consuming concerning the card holder, because credit card number is not entirely sent to businessman.On the contrary, described card holder must analyze this credit card number, and considers a fragment code.In addition, in order to confirm described transaction, the card holder must remember this fragment code, and the fragment code of each transaction can be different.In addition, provide the burden of fail-safe software to drop on the body of described businessman, he may be ready or be unwilling to provide a kind of like this system.Thereby,, then do not provide security if the card holder wishes that a kind of never like this businessman of system goes to buy.
United States Patent (USP) the 5th, 903,721 (Sixtus) have been described and have been used to provide an alternative method improving the credit card trade security.The method of Sixtus relates to the card holder and does shopping by the Internet." trust server " that is used to confirm the card holder receives a purchase request that has IP (Internet Protocol) address that holds the person of having.If by the described IP address and this registered IP matching addresses of blocking the holder that trust server receives, then confirm this purchase, and it mail to " credit instruments clearing house ", ratify or veto described purchase there.When not having responsive credit card information to send, only just can carry out from the transaction of computing machine from the IP address to trust server that registered by unsafe network.In addition, some ISP (ISP) uses dynamic IP addressing, wherein, gives him a temporary transient IP address assignment when the user logins this ISP network.Thereby, have the ISP's who utilizes dynamic IP addressing card holder, can not use the transaction security system of lecturing by Sixtus.
For another example, United States Patent (USP) the 5th, 991,738 (Ogram) have lectured a method of utilizing encryption software.The card holder wishes to adopt the businessman of Ogram method to buy article there from certain, download encryption software from the computing machine of this businessman.This encryption software was encrypted any sensitive information before sending to described businessman.A shortcoming of Ogram method is not buy with card holder's safety to confirm to handle.In addition, the encryption technology that is adopted can be intercepted and be cracked during the transmission.
Need the system and method that is used to provide safe and reliable credit card trade processing.Also needing businessman is system and method transparent, that be used to provide safe and reliable credit card trade processing.Also need a system, be convenient to the card holder confirm credit card trade and provide card holder each attempt to use the prompting of credit card to notify.
Summary of the invention
To be used to provide safe and reliable be the system and method that transparent credit card trade is handled to businessman by providing one in the present invention, solves the problem that interrelates with prior art.The present invention is convenient to the card holder and before an approval in-formation is sent to businessman each credit card trade is confirmed, and attempts each to use the prompting notice of described credit card to offer the account holder.
The invention discloses a computer system that is used to handle the business transaction between account holder and businessman, it comprises a processing unit, is used for carrying out data and code and a storage arrangement, is used to store data and code.This storage arrangement comprises, businessman's communication module, be used to receive the trading approving request that comprises a complete account number, an account holder communication module, be used to and confirm described trading approving request and be convenient to be connected and an authorization module, be used for described trading approving request is responded with the independent of account holder, and be used for an approval in-formation being sent to described businessman as long as described account holder's described trading approving request is identified.
In a certain embodiments, described authorization module comprises: one mutual confirms to be used for module certain the trading approving request that receives is responded, and is used to start and being connected of account holder.At one more specifically among the embodiment, described computer system also comprises a network interface, and, described mutual affirmation module is mainly used to by this network interface an electronic information be sent to the account holder, in case and be used for receiving answer about the electronic information that is sent, confirm described trading approving request.
In another specific embodiment, described computer system also comprises a remote communication devices, and confirm that alternately module is used for the account holder is sent an automatic telephone call, repeat certain part of trading approving request to the account holder, and from the confirmation of receipt instruction of account holder there.At one more specifically among the embodiment, described mutual affirmation module is used for asking for an authorization code before certain part of repeating the trading approving request.
Alternatively, described mutual affirmation module is waited for communicating by letter of account holder startup and system, and perhaps, system start-up is communicated by letter with the account holder's, pending trading approving request for confirmation.
In a specific embodiment, be used for authorization module that the instruction from the account holder is responded, also not under the situation of account holder input,, can optionally forbid confirming to handle by the follow-up trading approving request of automatic affirmation.
In another specific embodiment, authorization module comprises a main affirmation module, if the account holder does not also have approval about confirming request in the time cycle of confirming in advance in the past, then this master's affirmation module is abandoned this affirmation request automatically.Main affirmation module also is used for sending notice to the account holder when confirming that request is abandoned.
In another specific embodiment, a trading approving request comprises an affirmation request from third party financial institution, and authorization module is used for the affirmation mark is sent to this third party financial institution.
The invention also discloses a kind of method of the business transaction that is used between account holder and businessman, providing safe and reliable.Described method comprises: reception comprises a trading approving request that is used for confirming account holder account full account number, by being independent of the independent communication of businessman, the trading approving request is confirmed with this account holder in electronization ground, as long as this account holder confirms described trading approving request, also an approval in-formation is sent to described businessman.
In a concrete grammar, be used for confirming that with the account holder step of trading approving request comprises that prompting account holder confirms described trading approving request.At one more specifically in the method, remind the account holder to comprise and send an electronic information.More specifically in the method, be used for confirming that the step of described trading approving request comprises the answer of reception to described electronic information at another.In another concrete grammar, remind described account holder to comprise and send an automatic telephone call to it, foundation and described account holder are connected, and repeat a part of trading approving request at least, and from the confirmation of receipt instruction of account holder there.At one more specifically in the method, the described account holder of proof is true before repeating described at least one part of trading approving request.
Another alternative approach comprises waits for that the account holder starts affirmation by communicating by letter with described computer system and handles.At one more specifically in the method, connecting startup by the account holder by network or phone confirms, and confirm to comprise, receive connection request by network or communication facilities from the account holder, foundation and described account holder are connected, proof account holder is true, sends at least one part of trading approving request to the account holder, and receives the affirmation instruction about described trading approving request from the account holder.
The account holder can optionally select permission or forbid described affirmation processing.
In another concrete grammar, the step of the described trading approving request of electronic affirmation comprises, if the account holder does not confirm the trading approving request in the preset time interval, then abandons described trading approving request.At one more specifically in the method, when abandoning described trading approving request, send notice to the account holder.
In another concrete grammar, the step that is used for receiving from a trading approving request of businessman comprises, receives of third party financial institution who receives the trading approving request there since described businessman to confirm request.The step that an approval in-formation is sent to described businessman comprises described acknowledgement indicator is sent to described third party financial institution.
The present invention also discloses a system and method for certain transaction between businessman and account holder that is used for confirming in advance.In a specific embodiment, a computer system comprises a processing unit that is used for deal with data and code, and a memory storage that is used to store data and code.Described data comprise at least one standard in advance confirmed relevant with the account holder.Described memory storage comprises businessman's communication module and authorization module that is used for receiving from businessman the trading approving request there.Described authorization module will confirm in advance standard and trading approving request compare, if described confirm in advance standard be met, then confirm described trading approving request automatically, eliminate this necessity thus, promptly before finishing described approval process, obtain account holder's direct affirmation to described trading approving request.
In certain specific embodiment, the described standard of confirming in advance comprises relevant a plurality of standard of confirming in advance with the account holder, and if any one of the described standard of confirming in advance is met, then described trading approving request obtains affirmation.In an embodiment that can substitute, be met the just described trading approving request of affirmation automatically up to whole a plurality of standards of confirming in advance.The example of the useful standard of confirming in advance may be thought any other standard easily including, but not limited to businessman's identification marking, number of transaction (for example, purchasing price), trade date, exchange hour or account holder.Alternatively be that described code comprises that also card holder's communication module and/or one are used for being convenient to the mutual affirmation module that the account holder makes amendment to the standard of confirming in advance.In one embodiment, the described standard of confirming is in advance promptly revised the described standard of confirming in advance up to described account holder by initial setting up like this, can confirm the trading approving request automatically.As another replacement scheme, the described initial standard of confirming in advance can be by account holder deletion (for example, when opening described account).
Description of drawings
Describe the present invention with reference to figure below, wherein, similarly Ref. No. is composed to similar composition.
Fig. 1 be one at block scheme according to the Internet between card of the present invention holder, individual businessman, credit card company and the third party's affirmation company;
Fig. 2 is used for the block scheme of a server of credit card company in the displayed map 1, is included in a working storage and an authorization module in the described working storage;
Fig. 3 is the block scheme that is used for describing in detail authorization module shown in Figure 2;
Fig. 4 is used for showing the credit card that is used at Fig. 2 the ratify a motion block scheme of exemplary data structure of record of formation store transaction that ratifies a motion;
Fig. 5 is used for showing the block scheme that is used in the exemplary data structure of the card holder list block memory card holder data of Fig. 2;
Fig. 6 is used for showing the block scheme that is used in the exemplary data structure of the purchase history module store transaction logs of Fig. 2;
Fig. 7 is used for summing up the process flow diagram that is used for according to a kind of method that the invention provides safe and reliable electronic transaction;
Is is Fig. 8 used for summing up the 4th step that is used for execution graph 7 described methods (affirmation under an embargo?) a kind of process flow diagram of method;
Fig. 9 is the process flow diagram that is used for summing up a kind of method of the 5th step (card the holder confirm) that is used for execution graph 7 described methods;
Figure 10 is the process flow diagram that is used for summing up a kind of alternative method of the 5th step (card the holder confirm) that is used for execution graph 7 described methods;
Figure 11 is the block scheme that is used for showing an alternative authorization module of an alternative server that comprises the standard of confirming in advance and the transaction that is used to confirm in advance according to the present invention;
Figure 12 is the block scheme that is used for describing in detail the described alternative authorization module of Figure 11;
Figure 13 is used for showing being used to store the described block scheme of the exemplary data structure of the standard of affirmation in advance of Figure 11;
Figure 14 is used for summing up the process flow diagram that is used for according to the another kind of method that the invention provides safe and reliable electronic transaction;
Is is Figure 15 used for summing up the 5th step that is used to carry out the described method of Figure 14 (standard of Que Rening met in advance?) a kind of process flow diagram of method;
Is Figure 15 A used for summing up being used to carry out described the 5th step of Figure 14 (standard of Que Rening being met in advance?) a kind of process flow diagram of alternative method;
Figure 16 is the process flow diagram that is used for summing up a kind of method that is used to the standard of confirming in advance that the card holder revises and its account interrelates;
Embodiment
The present invention solves the problem relevant with prior art by providing a kind of new system and method, and this system and method provides safe and reliable electronic transaction by confirming every electronic transaction with the account holder.In the following description, a large amount of detail (for example, by the affirmation of credit card company's processing, by affirmation that blocks holder's initiation or the like) has been proposed so that provide about a thorough of the present invention.Yet, those skilled in the art will recognize that leaving these details also can realize the present invention.In the other situation, ignored the details (for example, electronic credit request/approval, computer operating system, communication software etc.) of some well-known ecommerce practices, to the present invention so that need not make primary and secondary unclear.
Fig. 1 is used for showing a system 100, it comprises that card holder 102, businessman 104, credit card company 106 and a third party confirm company 108, they link to each other with interconnection network 110 (as the Internet) by physical network media 112 (1-4) (for example, telephone wire, concentric cable etc.) separately.Card holder 102, businessman 104, credit card company 106 and affirmation company 108 also communicate by another physical network media 114 (for example telephone wire).
Card holder 102 has a credit card, and an account who is provided by credit card company 106 is provided the number by credit card.Businessman 104 provides card holder 102 to utilize credit card number to pass through commodity and service that interconnection network 110 can be bought.Card holder 102 buys request by providing complete credit card number to propose electronics from businessman 104.This purchase can be passed through interconnection network 110, and physical network media 114 perhaps even in person carries out.Respond as the butt joint purchase request of buying, businessman 104 can submit to credit card company 106 to a trading approving request (TAR).
Next, before the information of an approval or rejection was distributed to businessman 104, described TAR can experience two-part checking and approving.At first, the credit approval of standard is carried out in described purchase request by credit card company 106.After credit approval, will otherwise by credit card company 106, or confirm described purchase request by affirmation company 108 and card holder 102.Both can also can implement to confirm by interconnection network 110 by physical network media 114.After affirmation, if purchase not only by credit card company's 106 approvals but also by card holder 102 affirmations, is then passed through physical network media 114 or interconnection network 110 to approval in-formation of businessman's 104 transmissions.
In this specific embodiment, a credit card has been simplified ecommerce.Yet, one of ordinary skill in the art will recognize that the present invention is not limited to use sales slip.Can combine use the present invention with any type of account (for example, debit card), so that promote to comprise the safe and reliable electronic transaction of transmitting an account number.Will appreciate that also that in the following description credit card company 106 carries out described affirmation and handles.Yet this affirmation is handled can confirm that company 108 selectively carries out by the third party.In a kind of like this embodiment, credit card company 106 confirms that request sends to affirmation company 108 to one.Affirmation company 108 then confirms card holder's 102 described transaction request, and acknowledgement indicator (indicate this transaction request whether to be identified, abandon etc.) is postbacked to credit card company 106.
Fig. 2 is the block scheme that is connected to the server 200 (for example HTTP Internet server) on the interconnection network 110 by physical network media 112 (3).In this specific embodiment, server 200 is trading servers of a credit card company 106, is used to handle the credit card trade of credit card company 106.Server 200 comprises a processing unit (PU) 202, a network interface 204, system bus 206, nonvolatile memory 208, at least one I/O (I/O) controller 210, system clock 212, a communicator 214 and a working storage 216, so that the function (for example, handling credit card trade) that makes server 200 realize it to want.System bus 206 makes the communication between the each several part of server 200 more convenient.
Server 200 is communicated by letter on interconnection network 110 by network interface 204.Network interface 204 (for example, the Ethernet adapter) is dealt into packet on the interconnection network 110 and from interconnection network 110 and receives packet, thereby, allow server 200 communicate by letter by interconnection network 110 with card holder 102.Nonvolatile memory 208 (for example, ROM (read-only memory), perhaps one or more hard disk drive) is even provide the also still data of maintenance and the storage of code (for example, guidance code and program) when server 200 is turned off power supply.I/O controller 210 is used for the connection of user interface devices (not marking) for server 200 System Administrator Managements.The I/O device comprises that typically keyboard, mouse, monitor, printer and other are convenient to communicating devices between server 200 and the keeper.Server 200 also comprises a system clock 212 that is used to safeguard correct date and time, and the date and time data are provided on request.
Server 200 also comprises a remote communication devices 214 (for example, modulator-demodular unit, perhaps a phone), is used between a far end system or litigant and server 200 setting up being data or being the connection of voice.The example of far end system comprises computing machine 102, businessman 104 or the affirmation company 108 that is had by the account holder.In a specific embodiment, be connected and be used to confirm pending TAR with card holder's 102 voice.
Working storage 216 (for example, random access storage device) provides dynamic storage for server 200, and is included in the executable code (for example, operating system 218) that is loaded into working storage 216 during the system start-up.Operating system 218 makes the control that is loaded into the every other module in the working storage 216 and carries out facility.Working storage 216 also comprise credit ratify a motion formation (CARQ) 220, card holder list block 222, card holder communication module 224, authorization module 226, confirm pending formation (VPQ) 228, buy history module 230 and businessman's communication module 232.When starting, utilize each module and formation above the known method initialization of those skilled in the art, and they are loaded into working storage 216 from nonvolatile memory 208.Can selectively from mass data storage replacement device, be loaded into working storage 216 to module noted earlier and formation, these storage replacement device comprise, CD-ROM, tape or driver (for example, the Jaz of Iomega of jumbo removable data memory disc is arranged TMOr Zip TMBut also be not limited thereto driver).
Approval and the affirmation of authorization module 226 controls and coordination TAR.As mentioned above, confirmed that by the third party company 108 handles in the alternate embodiment of confirming, authorization module 226 is used for a request that is used to confirm is sent to affirmation company 108, and, from affirmation company 108 confirmation of receipt marks.The request that is sent out that is used to confirm comprises and the relevant information of described purchase request, such as a product description, purchasing price, merchant name or any other affirmation information that helps the identification card holder to conclude the business.For example, the affirmation mark that is received will comprise that an expression has been confirmed by described card holder or a code of the concrete transaction abandoned.Availablely be that as the reaction to the instruction that provided by card holder 102, authorization module forbids optionally that also described affirmation handles (for example, automatically confirming the transaction of each transaction or certain concrete businessman).Card holder 102 usually will start the instruction of forbidding that described affirmation is handled by a secure network (for example, by phone or mail).
Businessman's communication module 232 receives TAR by network interface 204 or remote communication devices 214 from businessman 104 theres, and approval or rejection information are sent to him.The communication between server 200 and card holder 102 of card holder communication module 224 by interconnection network 110 or 114 management of physical network media.Card holder list block 222 is databases, is used to store the current client's (comprising card holder 102) of credit card company 106 personal information and account information.Those skilled in the art will appreciate that this card holder list block 222 can be a typical super large file.Therefore, when display card holder list block 222 in storer 216, should be understood that described whole client file may be stored in the big data-storage system, such as, nonvolatile memory 208, the some parts of described whole tabulation will be where necessary advanced the holder by exchange and tabulate 222 or from wherein exchanging away.
The credit card formation (CARQ) 220 that ratifies a motion is provided for waiting for the storage of TAR of processing of credit approval of the routine of authorization module 226.Businessman's communication module 232 is periodically interrogated network interface 204 and remote communication devices 214, so that determine whether to exist the TAR from any introducing of businessman 104, and any such request is transmitted to CARQ 220.
Confirm that pending formation (VPQ) 228 is provided for pending storage by the TAR that blocks holder's 102 affirmations.Be identified correspondingly with an effective account at described TAR, and by after the conventional credit approval, authorization module 226 is forwarded to VPQ 228 to TAR from CARQ 220.TAR remains on VPQ228, up to being identified, vetoing or up to having spent the preset time cycle.
In case TAR is given the ratification or is vetoed, will be transmitted to the record of described TAR and buy history module 230.Buy the information of the previous account activity of history module 230 predetermined period of times of storage (for example, 30 days one-periods).In case surpass a clerking of described transaction (bill for example, perhaps electronic bill etc.) conveys to card holder 102 described predetermined period of times, will be forwarded to a more permanent storage medium (for example, tape) to each expired TAR from working storage 216.
Fig. 3 has shown the block scheme of authorization module 226, comprises credit approval module 302, leads affirmation module 304, confirms module 306 and businessman's respond module 308 alternately.Credit approval module 302 utilizes the known method of those skilled in the art that each TAR that stores in CARQ 220 is carried out conventional credit approval process.Main affirmation module 304 is coordinated described mandates and confirms to handle, and, be responsible for all controls of authorization module 226.Mutual affirmation module 306 is finished card holder 102 affirmation.Businessman's respond module 308 is by transmission trading approving or the information startup of transaction rejection and final the communicating by letter of businessman 104.
Fig. 4 has shown the ratify a motion example of data structure 400 of a credit that is applicable to that specific embodiments of the invention are used.Those skilled in the art will be identified as chained list record 402 (1-n) to data structure 400.Each represents a pending TAR among record 402 (1-n), and comprise a complete credit card number 404, buy explanation 406 for one, a purchasing price 408, Business Information 410 is bought date and time information 412, a sign that is identified 414,415, one of the signs that affirmation is activated go through to indicate sign 418 and pointer 420 that 416, one quilts are vetoed.Server 200 receives complete credit card number 404, one there from the businessman with described TAR and buys explanation 406, purchasing price 408, Business Information 410 and buy date and time information 412.The sign 414 that use is identified, go through to indicate 416 and the sign 418 vetoed be illustrated in the state of each record 402 in the described authorisation process, will be described this point in more detail below.Pointer 420 is illustrated in the storage address of the next record 402 (+1) in the described table.Last record 402 (n) comprises the end of tabular value 422, and it is illustrated in last record in the described table.
The sign 414 that is identified, the sign of confirming to be activated 415, go through to indicate 416 and the sign 418 vetoed be to represent the individual bit sign of recording status separately.Whether the TAR that sign 414 expressions that are identified are got in touch is identified (for example, being identified sign 414=1) or whether described TAR is not identified (for example, being identified sign 414=0).Whether confirm to be activated sign 415 expression servers 200 has started blocking described affirmation processing of the holder 102.Go through to indicate 416 represent whether described relevant TAR goes through (sign=1 for example, goes through).Whether the described relevant TAR of sign 418 expressions that is vetoed is by rejection (for example, being vetoed sign=1).
Fig. 5 has shown an example of a card holder data structure 500, and this data structure is applicable to memory card holder data in card holder list block 222.One of ordinary skill in the art will recognize that data structure 500 is chained lists of record 502 (1-n), an effective house account being provided by credit card company 106 is provided each record 502.Each record 502 comprise a complete credit card number 504 being distributed to the associated card holder, one by one people's identification number (PIN) 506, card holder information 508, contact details 510, credit limit 512, one confirm that requested sign 514, one start acknowledgement indicator 516 and a pointer 518.
PIN 506 is used for confirming card holder 102 during confirming processing, perhaps allow card holder 102 settings with reference to the code that (for example, confirm to be requested to indicate 514, start acknowledgement indicator 516 etc.) is set.Card holder information 508 includes but not limited to such as more such personal information: card holder's name, date of birth, social insurance number and/or address.Contact details 510 comprise the necessary information that is used to communicate by letter of being correlated with the card holder, in particular for the affirmation information of TAR.Contact details 510 may include but not limited to telephone number, pager number or e-mail address.The credit that the relevant card holder of credit limit 512 expressions is scheduled to limits amount.Confirm to be requested to indicate that 514 allow card holder 102, for example under situation about further not importing,, forbid selectively confirming to handle by the follow-up TAR of automatic affirmation from card holder 102.In this embodiment, confirm to be requested to indicate that 514 is signs of individual bit that wherein, numerical value 1 expression should be finished and confirm to handle, and the described card holder of numerical value 0 expression wishes to delay to confirm to handle.516 expressions of individual bit startup acknowledgement indicator block holders and whether wish that server 200 starts the affirmation processing, and perhaps whether server 200 should wait for that user 102 starts affirmation and handles.If the value that startup acknowledgement indicator 516 has is 1, confirm that alternately module 306 just starts relevant card holder's affirmation processing (for example, Email, automatic telephone call etc.).If starting the numerical value of acknowledgement indicator 516 is 0, then Xiang Guan card holder must start and confirms processing (for example, send call to server, by interconnection network logon server 200 etc.).Pointer 518 is illustrated in the start address in the next record 502 in the card holder data structure 500.Tabulation ending indication 520 is illustrated in that this record 502 (n) is last record in the card holder data structure 500.
Fig. 6 has shown the example of the purchase history data structure 600 of the use that is applicable to specific embodiments of the invention.Purchase history data structure 600 is lists of links of record 602 (1-n), and its each record comprises complete credit card number 604, purchase information 606, purchasing price 608, Business Information 610, confirms date and time information 612 and pointer 614.Credit card number 604 allows concrete transaction and relevant card holder unanimity.Purchase information 606 includes the information (for example, product description) that helps discern and block holder's transaction.The expense that purchasing price 608 expressions are relevant with purchase.The businessman that TAR is submitted in Business Information 610 identifications to.Pointer 614 is illustrated in the address of the next record 602 in the data structure 600.Tabulation ending designator 616 (n) is illustrated in and writes down 602 (n) in the purchase history data structure 600 is last record.
Those skilled in the art will understand the aforesaid credit data structure 400 that ratifies a motion, and card holder's data structure 500 and purchase history data structure 600 are actually exemplary, and may, adopt other data structure in the present invention.Therefore, be not considered to substantive key element of the present invention with method concrete data structure described here for example.
Operation referring now to Fig. 1-6 explanation specific embodiment of the present invention.When card holder 102 submits the order of a commodity or service to businessman 104, and when using the credit card number of distributing, just begun processing by credit card company 106 as the means of payment.Businessman 104 is then comprising that the credit card number that is provided by card holder 102, a trading approving request buying the information of instructions, purchasing price, purchase date and time and identification businessman 104 send to credit card company 106.
Businessman's communication module 232 (Fig. 2) is periodically interrogated network interface 204 and any TAR from businessman 104 of remote communication devices 214 about importing.When receiving a TAR, businessman's communication module 232 tabulates 222 so that determine whether to exist record 502 (Fig. 5) that the credit card number that is complementary 504 that provides with TAR is arranged with regard to the scanning card holder.Do not have such record if tabulate the card holder in 222, then businessman's communication module 232 sends to businessman 104 to the information of a rejection.
Yet, if submitted credit card number coupling is in tabulate a credit card number 502 (x) in 222 of card holder, then businessman's communication module 232 just utilizes the information that provides in TAR to generate field 404,406,408,410 and 412, and produce the credit card record 402 that ratifies a motion, and in CARQ 220, store new record.Originally, be identified sign 414, go through to indicate 416 and be set to 0 entirely by rejection sign 418.
The main affirmation module 304 of authorization module 226 is scan A RQ 220 periodically, seeks pending TAR.Any pending TAR of state processing based on sign 414,416 and 418.For example, if the approved sign 416 (1) of first TAR record 402 (1) is set to 0 entirely, then main affirmation module 304 will be ratified module 302 to credit and call out so that carry out the conventional credit approval of TAR 402 (1).
Credit approval module 302 utilizes the known method of those skilled in the art to carry out conventional credit approval process.Conventional credit approval typical case includes but are not limited to, and relatively blocks the credit of holder's 102 (x) credit limit 512 (x) with purchasing price 408 (1) and relevant card holder's 102 (x) existing surplus and ratifies module 302.If the summation of purchasing price 408 (1) and relevant card holder's 102 (x) existing surplus is smaller or equal to credit limit 512 (x), then credit approval module 302 is just going through to indicate that 416 (1) are set to 1.If (for example in the account, have any difference that exceeds, back money), if perhaps the summation of purchasing price 408 (1) and relevant card holder's 102 (x) existing surplus is greater than credit limit 512 (x), then credit approval module 302 is just being set to 1 by rejection sign 418 (1).
In the next scan period of CARQ 220, main confirm module 304 again checkmark 414 (1), 416 (1) and 418 (1) so that definite appropriate behavior.Notice that because also TAR record 402 (1) is not confirmed to handle, the sign 414 (1) that is identified should still equal 0.If be set to 1 by rejection sign 418 (1), then main affirmation module 304 is just called out businessman's respond module 308 so that send a rejection information to businessman 104, deletion record 402 (1) from CARQ 220, and write a record 602 about the transaction of being vetoed in buying history module 230.If going through to indicate that 416 (1) are set to 1, then main authorization module 304 retrievals confirm to be requested to indicate 514 (x), so that determine whether card holder 102 (x) has optionally forbidden confirming to handle.If confirming to be requested to indicate that 514 (x) are set to 0, then main affirmation module 304 automatically is set to 1 being identified sign 416 (1), and stays TAR record 402 (1) in CARQ 220.If confirm to be requested to indicate that 514 (x) equal 0, then main affirmation module 304 is transmitted to VPQ 228 to TAR record 402 (1), confirms so that wait for card holder 102 (x).
Main affirmation module 304 also periodically scans VPQ 228 (for example, after each scanning CARQ 220) simultaneously, so that any pending TAR that is used to confirm that handles in VPQ 228 writes down 402.If the being identified sign in the physical record 402 414 is set to 1, its expression card holder 102 (x) has confirmed and has write down 402 corresponding TAR.Write down 402 (1) among the VPQ 228 when being scanned for the first time, be identified sign 414 (1) and affirmation and be activated and indicate that 415 (1) all should be set to 0.Main confirm that module 304 is then from the card holder search records 502 (x) 222 of tabulating, so that determine whether server 200 should start affirmation and (for example handle, Email is sent to user 102 (x), calling user 102 (x), makes a phone call to user 102 (x) etc.), perhaps whether server 200 should be waited for that user 102 (x) starts and confirm to handle.If be set to 0 starting acknowledgement indicator 516 (x), then main affirmation module is set to 1 confirming to be activated sign 415 (1).Even server 200 is not activated and confirm handles, be provided with and confirm to be activated sign and equal 1, also eliminated at every turn by the main demand of confirming to be requested to indicate 516 (x) of checking when confirming module 304 scanning VPQ 228.
During the record 402 (1) that scans for the first time in VPQ 228, if main affirmation module 304 is determined to be set to 1 starting acknowledgement indicator 516 (x), then main affirmation module 304 is just called out the mutual module 306 of confirming, so that startup card holder's 102 (x) affirmation is handled.Confirm that alternately module 306 then starts described affirmation and handles, equal confirm to be activated sign 415 (x) setting to 1, and control is returned to the main module 304 of confirming, in VPQ 228, retrieve the next record 402 that is used to handle by the latter.
Main affirmation module 304 is also periodically called out the mutual module 306 of confirming simultaneously, so that pending TAR in VPQ228 is carried out the affirmation of reality.Being confirmed to be by connecting with card holder 102 (x) of pending TAR finished, and this connection with independently open by receiving being connected that TAR and businessman 104 set up at first, electronic transaction such as atm card purchase with prior art is compared, and it provides extra security.May look like the most widely by it, phrase as used herein " connected " to be interpreted as and to include but are not limited to, and sets up network and connects, sets up data by modulator-demodular unit and connect, set up voice by remote communication devices and connect, send or receive Email etc.Thereby, card holder 102 may by interconnection network 110 logon servers 200, by network 114 and server set up being connected of direct modulator-demodular unit, by phone to server 200 dialing, Email send to server 200, to answering from the Email of server 200 or any other form of electronic communications, confirm pending trading approving request.
In an alternate embodiment, can be revised as system 200 and allow that account holder 102 ratifies some expense in advance.For example, the card holder tabulates and 222 may comprise the field (perhaps any other standard of wanting) that is used for ratifying in advance businessman.Then, when handling the trading approving request, authorization module 226 can be discerned businessman's list of ratifying in advance with relevant card holder's quilt to businessman and compare, and, if businessman appears on the list, then automatically confirm TAR.Card holder 102 may pass through the way access system 200 of interconnection network 110, network 114 or any other renewal customer data, so that revise the list that such quilt is ratified in advance.
In specific embodiments of the invention as Figure 1-3, confirm that alternately module 306 communicates by card holder communication module 224, network interface 204 and remote communication devices 214 and card holder 102.Card holder communication module 224 is periodically interrogated network interface 204 and remote communication devices 214 in order to introduce connection request (for example, Email, network connection, call etc.), and sets up any such connection.Such signal procedure (for example, E-mail software, procotol etc.) for a person skilled in the art, is well-known, therefore makes the present invention primary and secondary unclear in order to be unlikely to, and need not be explained in detail.
Mutual confirm that module 306 interrogates card holder communication module 224,, and handle the connection that each is established so that determine whether to establish and block being connected of holder 102.Suppose that card holder 102 (x) has set up and being connected of server 200, then the affirmation of pending TAR can be carried out according to the following procedure.Connection request should identification card holder 102 (x) (for example, pass through credit card number), and can comprise proof code (for example, being used for proving card holder's 102 (x) Personal Identification Number (PIN)) selectively, so that proof card holder 102 (x) is true.Mutual confirm that module 306 utilizes the identifying information in the connection request to tabulate 222 search corresponding to card holder's 102 (x) record 502 (x) from the card holder.Then, confirm PIN and PIN 506 (x) that module 306 relatively provides alternately in connection request, so that confirm the card holder.If these PIN do not match, then stop connecting.If these PIN couplings are then confirmed to handle.
It will be appreciated by those skilled in the art that when for the first time receiving an incorrect PIN, with being connected and stopping of card holder 102 (x).For example, typically, conventional network safety system disconnects and before being connected of user, is allowing the incorrect input of a predetermined quantity.As selection,, can adopt some safety practices to attempt access system such as stopping the user when starting a little when connecting.
Next, confirm the pending formation 228 of module 306 scanning affirmations alternately, seek the TAR of all credit card numbers 402 and card holder's 102 (x) credit card number 504 (x) coupling.Then the TAR of each coupling being offered card holder 102 (x) confirms or abandons.If card holder 102 (x) confirms concrete transaction, confirm alternately that then module 306 just is set to 1 to the sign that is identified 414 of this TAR record.If card holder 102 (x) drops the business (for example, this is not bought and authorize), confirm alternately that then module 306 will be set to 1 to the TAR record by rejection sign 418.
Connection type according to setting up with server 200 has the multiple method that pending TAR is offered card holder 102 (x) and instructs from card holder 102 (x) confirmation of receipt.For example, be connected, then can provide pending TAR according to the form of internet webpage if card holder 102 (x) has set up HTTP with server 200.Perhaps, if being a call voice, the connection between card holder 102 (x) and server 200 connects, then, can offer card holder 102 (x) to pending TAR, such as known such in the prior art by the text voice automated conversion system.Card holder 102 (x) may then send by voice or keyboard commands (for example, contact button 1 is used for confirming that touch button 2 is used for abandoning) and confirm instruction.Still as described in another example, be that email response can comprise the affirmation instruction (for example, in the Subject field of Email) that can be handled automatically by mutual affirmation module 306 in the situation about occurring of the form with an email response at connection request.When thinking when utilizing aforesaid any one connection type to confirm that TAR is innovative point of the present invention, just concrete connection type to usually can not considered as a substance of the present invention.
Mutual confirm module 306 treated behind any one connection request, control is turned back to the main module 304 of confirming, its scanning VPQ 228 also transmits being identified sign 414 or being set to any TAR record of 1 by rejection sign 418.In addition, all records 402 that main affirmation module 304 scannings retain in VPQ 228, and use the date and time and the value in buying date and time field 412 that provide by system clock 212 to compare.If the later time difference surpasses preset time (for example, 24 hours) at interval, then main affirmation module 304 will be set to 1 to the quilt rejection sign 418 of relative recording 402, and be transmitted to CARQ 220 writing down 402.
In the next scan period of CARQ 220, main affirmation module 304 will be sought any acknowledgement indicator 414 and go through to indicate that 416 all are set to 1 TAR record, call out businessman's respond module so that an approval in-formation is sent to the businessman that quilt is identified in record field 410, from CARQ 220, delete this record, and a record 602 is write in the purchase history data 230 so that completed transaction is filed.Be identified the businessman except a rejection information rather than an approval in-formation are sent to, award of bid will right 418 be found be set to 1 record carry out similar processing.
Fig. 7 sums up the process flow diagram of handling TAR method 700 according to the present invention.In the 1st step 702, businessman's communication module 232 receives the TAR that comprises complete credit card number from businessman 104 theres, generates TAR record 402 and TAR record 402 is write CARQ 220.In the 2nd step 704, authorization module 226 is submitted to conventional credit approval process to TAR record 402, and going through to indicate 416 or be set to be used for representing that by rejection sign 418 requested credit goes through or vetoed.In the 3rd step 706, authorization module 226 is according to going through to indicate 416 or determined whether to ratify or veto to be requested credit by rejection sign 418, then, in the 4th step 708, authorization module 226 determines whether card holder 102 has optionally forbidden confirming to handle.If optionally do not forbid confirming to handle, then in the 5th step 710, authorization module 226 is confirmed the transaction with card holder 102.Then in the 6th step 712, authorization module 226 determines whether card holder 232 has ratified TAR.If confirmed TAR, then in the 7th step 714, businessman's communication module 716 sends to businessman 104 to the information of trading approving.Then, in the 8th step 716, authorization module 226 determines whether also there is record in CARQ220.If no longer include record in CARQ 220, then method 700 finishes.
If in the 3rd step 706, authorization module 226 determines that credit request is vetoed, and then method 700 then proceeds to the 9th step 718, and businessman's communication module 232 sends to businessman 104 to a rejection information.If in the 4th step 708, authorization module 226 is determined optionally to have forbidden confirming to handle, and then method 700 proceeds to the 7th step 714, and at this, businessman's communication module 232 sends to businessman 104 to approval in-formation.If in the 6th step 712, authorization module 226 determines that card holder 102 does not confirm TAR, and then method 700 proceeds to the 9th step 718, in this businessman's communication module 232 rejection information is sent to businessman 104.At last, if the 8th step 716, authorization module 226 determines to exist more pending record TAR in CARQ 220, and then method 700 turns back to first step 702 so that the next one of handling in CARQ 220 is handled.
Fig. 8 sums up according to specific embodiments of the invention to be used to realize optionally forbidding that described TAR confirms the process flow diagram of the method 800 of processing.In the 1st step 802, authorization module 226 determines whether CARQ220 is empty.If CARQ 220 is not empty, then in the 2nd step 804, authorization module 226 reads in the TAR record among the CARQ 220.Then, in the 3rd step 806, authorization module 226 will block holder 102 and a TAR connects, and from the card holder tabulate 222 retrieval with specifically block the corresponding card holder of holder and write down 502.In the 4th step 808, authorization module 226 writes down 502 according to the card holder and determines whether requirement of card holder 102, confirms TAR. by card holder 102 before approval in-formation is sent to businessman 104.If determined to ask (promptly allowing) card holder's affirmation, then in the 5th step 810, authorization module 226 sends to VPQ 228 to relevant TAR record.Next, in the 6th step 812, authorization module 226 determines whether the last record in CARQ 220 is processed, if method 800 finishes.
If in the 4th step 808, authorization module 226 determines not require (promptly forbidding) to confirm, then in the 7th step 814, automatically is set to 1 to represent to have confirmed TAR being identified sign 414.If in the 6th step 812, authorization module 226 determines also not handle the last record in CARQ 220, and then method 800 turns back to the 2nd step 804, begins to handle the next record in CARQ 220.
Fig. 9 is the process flow diagram of summing up the concrete grammar 900 be used to confirm TAR according to the present invention.At first step 902, authorization module 226 determines whether VPQ 228 is empty.If VPQ 228 is not empty, then in the 2nd step 904, authorization module 226 reads in first TAR record 402 among the VPQ 228.In the 3rd step 906, authorization module 226 determines whether before just to have vetoed TAR record 402 (for example, being vetoed sign 418=1).If before do not vetoed TAR, then in the 4th step 908, authorization module 226 determines whether current TAR before had been identified (for example, acknowledgement indicator 414=1).If this TAR also is not identified, then in the 5th step 910, authorization module 226 will determine whether server 200 has started affirmation and handled (for example, confirming to be activated sign 415=1).Equal 1 if confirm to be activated sign 415, then in the 6th step 912, authorization module 226 will be determined, adm server 200 has received since the current TAR, whether the preset time cycle (for example, read and buy date and time 412 and comparison system clock 212) surpasses, if surpassed the preset time cycle, then in the 9th step 914, authorization module 226 is abandoned TAR (for example, being provided with by sign=1) automatically, and, in the 8th step 916, the TAR record is forwarded to CARQ 220.In the 9th step 918, authorization module 226 has determined whether the last record in VPQ 228 treated.If all records in VPQ have obtained handling, then in the 10th step 920, authorization module 226 is carried out the affirmation of the card holder in any TAR record that VPQ 228 retains and is handled.
If in the 1st step 902, authorization module 226 determines that VPQ 228 is empty, and then method 900 finishes.If in the 3rd step 906, authorization module 226 is determined to have vetoed the TAR record of handling, and then method 900 is directly to the 8th step 916.Similarly, if in the 4th step 908, authorization module 226 determines before to have confirmed the processing of TAR, and then method 900 proceeds to the 8th step 916.
If in the 5th step 910, authorization module 226 determines that confirming to be activated sign equals 0, and then method 900 proceeds to the 11st step 922, at this, authorization module 226 determines also whether authorization module 226 should start affirmation and handle (for example, starting acknowledgement indicator 516=1).If in the 11st step 922, authorization module 226 determines to start card holder's affirmation processing, and then in the 12nd step 924, server 200 starts card holders' 102 affirmation to be handled, and in the 13rd step 926, the affirmation sign that has started is set to 1.Then, method 900 proceeds to the 8th step 916.If in the 11st step 922, authorization module 226 is determined to start acknowledgement indicator and is set to 0, and then method 900 is directly to the 13rd step 926.
In the 6th step 912, authorization module 226 is determined not surpass predetermined period of time at interval, and then method 900 proceeds to the 8th step 916.If in the 9th step 918, authorization module 226 is determined to have other TAR record in VPQ 228, then method 900 turns back to the 2nd step 904, so that handle next TAR record.
Figure 10 is the process flow diagram of summing up the method 1000 of the pending TAR be used to confirm card holder 102.In the 1st step 1002, card holder communication module 224 is interrogated network interface 204 and remote communication devices 214, so that (for example determine whether to exist from any card holder communication request of blocking holder 102, call, network connecting request etc.), if exist, then in the 2nd step 1004, authorization module 226 is called out the mutual module 306 of confirming, so that set up and being connected of card holder 102.In the 3rd step 1006, confirm module 306 card authentication holders 102 (for example, requiring the proof code) alternately, and in the 4th step 1008, search VPQ 228 seeks 102 relative recordings with the card holder.Then, in the 5th step 1010, confirm that alternately module 306 offers card holder 102 at least one part of pending TAR (enough blocking holder's identification).Next,, confirm that alternately module interrogates the connection that is established, so that determine whether card holder 102 has sent instruction and confirmed submitted TAR in the 6th step 1012.If there is no confirm the instruction of TAR,, confirm alternately whether module 306 definite card holders 102 have sent the instruction of abandoning TAR then in the 7th step 1014 from card holder 102.If there is no abandon the instruction of TAR,, confirm the last pending TAR that module 306 just determines whether treated to interrelate with card holder 102 alternately then in the 8th step 1016.If treated last pending TAR, then in the 9th step 1018, mutual confirm that module 306 will stop and block holder 102 and connect, and method 1000 turns back to step 1002, so that determine whether to exist any communication request of blocking the holder from other.If in the 1st step 1002, card holder communication module 224 determines not exist card holder communication request, and then method 1000 finishes.
If in the 6th step 1012, mutual affirmation module 306 receives the submitted TAR of confirmation command from card holder 102 theres, then in the 10th step with regard to 1020, confirm that alternately module 306 just is set to numerical value 1 to the sign 414 that is identified of TAR record 402, be used for expression and confirmed TAR.Then, method 1000 turns back to the 5th step 1010.Similarly, if in the 7th step 1014, mutual affirmation module 306 receives instruction from card holder 102 theres and abandons submitted TAR, then in the 11st step 1022, mutual confirm module 306, be used for expression to have abandoned this TAR just being set to numerical value 1 by rejection sign 418 in the TAR record 402.Then, method 1000 turns back to the 5th step 1010.
In the 8th step 1016, determine not handle concrete card holder's last pending request if confirm module 306 alternately, then method 1000 turns back to the 5th step 1010, so that handle concrete card holder's next pending TAR.
Figure 11 is the block scheme of an alternative server 200A.Except server 200A comprised in advance approval standards (PVC) 1102 and alternative authorization module 226A, the function of server 200A and the server of Fig. 2 200 were similar.Authorization module 226A controls and coordinates approval and the affirmation of TAR, and, except the function of carrying out by authorization module 226, also use the standard of confirming in advance automatically to confirm any TAR that the satisfied standard of confirming in advance 1102 requires.Use standard 1102 facilities confirmed in advance the acceleration of TAR confirm because authorization module 226A needn't wait for direct affirmation of the card holder 102.
The standard 1102 of Que Rening is the standard database that comprises that 106 current each user's of credit card company that are used to comprise card holder 102 personalization is confirmed in advance in advance.The standard of Que Rening typically includes but not limited in advance, businessman's identification marking, maximum purchasing price and be limited to authorization module 226A and can confirm to buy date between the date automatically.One of ordinary skill in the art will recognize that the standard module of confirming in advance 1102 can be a typical super large file.Therefore, when in storer 216, showing the standard module of confirming in advance 1102, will be appreciated that whole client file may be stored in the big data-storage system, such as nonvolatile memory 208, some part of whole tabulation ought can exchange with the standard module of confirming in advance 1102 in case of necessity.
At first, when opening credit card account, determine the standard of affirmation in advance like this: make the standard of confirming in advance can not confirm any purchase by credit card company 106.In other words, each account's initial default is that the TAR that consequently do not have that is provided with like this satisfies the described standard of confirming in advance (for example, maximum purchasing price=0).Perhaps, when opening described account, the standards that can determine to confirm in advance by card holder 102 (for example, according to they credit card in please).In both of these case, card holder 102 can pass through secure network (for example, by phone or modem access), revises their standard of confirming in advance, and this names a person for a particular job and describes hereinafter.
Figure 12 has shown the block scheme of authorization module 226A, and it comprises credit approval module 302, substitutes the main module 304A that confirms, confirms module 306A and businessman's respond module 308 alternately.Credit approval module 302 realizes conventional credit approval to each TAR that deposits by the known method of those skilled in the art in CARQ 220.Main confirm module 304A coordination delegate and confirm to handle, comprise the affirmation that standard that utilization is confirmed is in advance carried out, and be responsible for overhead control authorization module 226A.The mutual affirmation of confirming module 306A execution and card holder 102, and coordinate by the card holder the modification of the standard of affirmation in advance.Businessman's respond module 308 is approval in-formation or is that rejection information starts with the final of businessman 104 and communicates by letter by sending.
Figure 13 has shown the example that is suitable for standard data structure 1300 specific embodiment of the invention, that application is confirmed in advance.One of ordinary skill in the art will recognize that data structure 1300 as the chained list of record 1302 (1-n).The standard of confirming in advance that each record 1302 (1-n) representative and concrete card holder interrelate, and comprise, complete credit card number 1304, first businessman's identification marking 1306 (1), r businessman identification marking 1306 (r), maximum confirm in advance purchasing price 1310, various standard 1314 and the pointer 1316 confirmed in advance of a pair of date 1312, the kind of confirming in advance.The standard recording 1302 (a) that complete credit card number 1304 will specifically be blocked holder 102 (a) and affirmation in advance connects.Each businessman's identification marking 1306 (1-r) all contains the information that is similar to the Business Information 410 that each TAR contains.Each businessman's identification marking 1306 (1-r) all is that each card holder has identified the businessman that is identified in advance.Authorization module 226A automatically confirms from being identified the TAR that businessman receives in advance there.The purchasing price 1310 that is identified in advance is for confirming to be provided with maximum purchasing price automatically.Authorization module 226A automatically confirms to comprise than any TAR that confirms the purchasing price 408 that purchasing price 1310 is low in advance.The date 1312 of Que Rening comprises a Start Date and a Close Date in advance.All comprise that the Start Date of dropping in advance the date of confirming 1314 and the TAR on the purchase date 412 between the Close Date are automatically confirmed by authorization module 226A.Add the various standard of confirming in advance 1314 of kind, so that explanation, may be used to make that authorization module 226A confirms certain TAR is not the above-mentioned specific concrete standard of listing.For example, in the time should confirming to buy automatically, card holder 102 may want to limit the concrete time in one day.For a kind of like this situation, the various standard of confirming in advance 1314 of kind can comprise a zero-time and a stand-by time.Pointer 1316 (a) is illustrated in the storage address of the next record 1316 (a+1) in the tabulation.Write down 1302 (n) at last and comprise that expression record 1302 (n) are the end of the list value 1318 of the last record in described tabulation.
Figure 14 is according to a particular embodiment of the invention, utilizes the standard of confirming in advance to sum up to be used to the process flow diagram of the method 800A that realizes described automatic affirmation TAR.In the 1st step 802, authorization module 226A determines whether CARQ 220 is empty.If CARQ 220 is empty, then method 800A finishes.If CARQ 220 is not empty, then in the 2nd step 804, authorization module 226A reads in a TAR record that writes down among the CARQ220.Then, in the 3rd step 806, authorization module 226A will block holder 102 and a TAR connects, and from card holder tabulate retrieval and the corresponding card holder record of described concrete card holder 222.In the 4th step 808, authorization module 226A writes down 502 according to the card holder and determines, whether card holder 102 requires will confirm TAR with card holder 102 before the transmission approval in-formation is to businessman.If determined to have asked (promptly allowing) card holder's affirmation, then in the 5th step 809, authorization module 226A determines whether the in advance standard of affirmation relevant with card holder 102 is met.If in the 5th step 809, the standard of Que Rening is not being met in advance, and then in the 6th step 810, authorization module 226A sends to VPQ 228 to relevant TAR record.Next, in the 7th step 812, authorization module 226A determines whether the last record in CARQ 220 is processed, and if processed, then method 800A finishes.
If in the 4th step 808, authorization module 226A determines not require (promptly forbidding) to confirm that then method 800A proceeds to the 8th step 814, and at this, authorization module 226A is set to 1 being identified sign 414, has confirmed TAR with expression.Similarly, if in the 5th step 809, authorization module 226A determines that the standard of confirming in advance is met, and then method 800A proceeds to the 8th step 814, and at this, authorization module 226A is set to 1 being identified sign 414.If in the 7th step 812, authorization module 226A determines also not handle the last record in CARQ 220, and then method 800A turns back to the 2nd step 804, begins to handle the next record in CARQ220.
Figure 15 is the process flow diagram that is used for showing the method 1500 of the 5th step 809 in the described method of carrying out Figure 14 (determining whether the described standard of confirming in advance is met).In the 1st step 1502, the record 1302 (a) of the standard of confirming in advance 1102 that authorization module 226A retrieval interrelates with the card holder who is identified (for example, card holder 102) in described TAR.In the 2nd step 1504, authorization module 226A determines among record 1302 (a) one of (1-r) the corresponding Business Information 410 that comprises whether of identification marking 1306 (a) of businessman in TAR.If the businessman's identification marking 1306 (a) that writes down among 1302 (a) (1-r) can not be discerned described businessman, then in the 3rd step 1506, authorization module 226A just determines whether the purchasing price 408 of TAR is lower than the maximum purchasing price of confirming in advance 1310 (a).If the purchasing price among the TAR 408 is not less than the maximum purchasing price of confirming in advance 1310 (a), then, in the 4th step 1508, authorization module 226A determine among the TAR purchase date 412 whether between confirm in advance date 1312 (a) between.If buy the date 412 not between being identified in advance between the date 1312 (a), then in the 5th step 1510, authorization module 226A determines whether the various standard of confirming in advance 1314 (a) of kind is met.If the various standard of confirming in advance 1314 (a) of kind is not being met, perhaps block the unqualified any standard of confirming in advance 1314 (a) of holder, then method 1500 determines that the standard of confirming in advance is not met.
If in the 2nd step 1504, authorization module 226A determines businessman's identification marking 1306 (a) certain in (1-r) among record 1302 (a) corresponding to the Business Information 410 that comprises among the TAR, and then method 1500 determines that the standards of confirming in advance are met.If in the 3rd step 1506, authorization module 226A determines that purchasing price 408 is lower than and is identified purchasing price 1310 (a) in advance that then method 1500 determines that the standards of confirming in advance are met.Similarly, if in the 4th step 1508, authorization module 226A determines the purchase date 412 of TAR between the date 1312 (a) that is identified in advance, and then method 1500 determines that the standard of confirming in advance is met.At last, if in the 5th step 1510, authorization module 226A determines that pending TAR satisfies the various standard of confirming in advance 1314 (a) of kind, and then method 1500 determines that the standard of confirming in advance is met.Those of skill in the art recognize that if any one in the various standard (for example, the highest purchasing price) is met method 1500 will determine that concrete TAR satisfies the standard of confirming in advance, and is therefore confirmed automatically.
Figure 15 A is the process flow diagram that is used for showing the alternative method 1500A of step 809 in the method for carrying out Figure 14, and wherein, before confirming TAR automatically, all standards of confirming in advance must be met.In the 1st step 1502, the record 1302 (a) of the standard of confirming in advance 1102 that authorization module 226A retrieval interrelates with the card holder who is identified (for example, card holder 102) in TAR.At the 2nd step 1504A, authorization module 226A determines one of identification marking 1306 (1-r) of businessman Business Information 410 whether correspondence comprises among record 1302 (a) in described TAR.Identification marking 1306 (1-r) of businessman can not discern described businessman among 1302 (a) if write down, and then method 1500A determines that pending TAR does not satisfy the standard of confirming in advance, and ending method 1500A.Yet, one of identification marking 1306 (1-r) of businessman among 1302 (a) are corresponding to be identified businessman in TAR if write down, then method 1500A proceeds to the 3rd step 1506A, wherein, authorization module 226A determines whether the purchasing price 408 among the TAR is lower than described maximum and is identified purchasing price 1310 (a) in advance, if the described purchasing price 408 of described TAR is not identified under the purchasing price 1310 (a) in advance in maximum, then method 1500A determines that the standard of confirming in advance is not being met, and finishes this method.Be identified purchasing price 1310 (a) in advance if the purchasing price among the TAR 408 is lower than maximum, at the 4th step 1508A, authorization module 226A determines that purchase date 412 among the TAR is whether between the date 1312 (a) that is identified in advance.If buy the date 412 not between the date 1312 (a) that is identified in advance, then method 1500A determines that the standard of confirming in advance is not being met, and finishes this method.If buy the date 412 between the date 1312 (a) that is identified in advance, then at the 5th step 1510A, authorization module 226A determines whether the various standard of confirming in advance 1314 (a) of kind is met.If the various standard of confirming in advance 1314 (a) of kind is not being met, perhaps block the unqualified any standard of confirming in advance 1314 (a) of holder, then method 1500A determines that the described standard of confirming in advance is not met, and, ending method 1500A.Yet if the various standard of confirming in advance 1314 (a) of kind is met, method 1500A determines that the described standard of confirming in advance is met, and described pending TAR should be confirmed automatically.
Figure 16 sums up to be used to allow card holder 102 to revise the process flow diagram of the method 1600 of the relevant standard of confirming in advance 1302.Confirm that alternately module 306A can carry out and mutual affirmation module 306 identical functions, still also is used to coordinate and control the modification of the standard of confirming in advance 1302 (1-n).At first step 1602, card holder communication module 224 is interrogated network interface 204 and remote communication devices 214, so that (for example determine whether to exist from any card holder communication request of blocking holder 102, call, network connecting request etc.), if exist, then, confirm that alternately module 306A just connects with card holder 102 in the 2nd step 1604.In the 3rd step 1606, confirm module 306A card authentication holder 102 (for example, requiring the proof code) alternately, and, confirm that alternately module 306A search is used for the standard of confirming in advance 1302 that interrelates with card holder 102 in the 4th step 1608.In the 5th step 1610, confirm that alternately module 306A determines card holder 102 standard 1302 whether desired modifications is confirmed in advance (for example, receive respond the voice response of recording menu in advance).Determine the standard 1302 that card holder 102 desired modifications are confirmed in advance if confirm module 306A alternately, then in the 6th step 1612, mutual affirmation module 306A offers card holder 102 to first standard of confirming in advance (for example, businessman's identification marking 1306 (1)).Next, in the 7th step 1614, mutual affirmation module 306A determines card holder 102 standard whether desired modifications provides in step 1612, if card holder 102 selects not revise the standard of confirming in advance 1302 that is provided, then then in the 8th step 1616, mutual affirmation module determines whether card holder 102 wants to enter into the next standard of confirming in advance (for example, businessman's identification marking 1306 (2)).If described card holder 102 does not wish to continue to revise the standard of confirming in advance, then confirm module 306A alternately in the 9th step 1618, termination and card holder 102 are connected.
At first step 1602, if not from card holder's communication request, then ending method 1600.If in step 1610, card holder 102 does not wish the standard of confirming is in advance changed, and then method 1600 enters the 9th step 1618, wherein, confirms being connected of module 306A termination and card holder 102 alternately.If in step 1614, card holder 102 wishes the standard of confirming is in advance made an amendment, confirm alternately that then module 306A starts the 10th step 1620, wherein, receive new data from card holder 102 theres, and before method 1600 proceeds to the 8th step 1616, replace the standard of confirming in advance provided with new data.If receive the instruction that card holder 102 wishes the standard of confirming in advance 1302 is done more modifications in the 8th step 1616, then method 1600 turns back to step 1610.
Finished the description of specific embodiments of the invention at this.Can substitute, change or ignore described numerous characteristics without departing from the present invention.For example, except Card Type account described here, can realize the present invention in conjunction with the alternative type account (for example, balance due account) who obtains safe handling.As another example, the third party confirms that on behalf of credit card company 106, company 108 can adopt transaction processing method described here, and will confirm that label information sends credit card company 106 to.In addition, when showing the standard of confirming in advance 1102 shown in Figure 11 according to autonomous block, those skilled in the art will understand to change the standard of confirming in advance into and be stored in other record the insides that the holder tabulates 222 such as card.Similarly, card holder communication module 224 and mutual affirmation module 306 can be synthesized and be the single operation module.In fact, the functional module that tissue and classification the present invention describe is for the present invention clearly is described, can not mechanically think concrete separation function be essential elements of the present invention.Shown in specific embodiment these or other change and to accomplish easily for a person skilled in the art, especially with reference to the description of front.

Claims (56)

1. computer system that is used between account holder and businessman confirming business transaction, described computer system comprises:
A processing unit that is used for deal with data and code;
A storage arrangement that is used to store described data and described code,
This storage arrangement comprises:
Businessman's communication module is used to set up and being connected of described businessman, and is used for receiving a trading approving request that comprises a full account number,
An account holder communication module is used to set up a separate connection with the account holder, be used to confirm described trading approving request and
An authorization module responds to receiving described trading approving request, and as long as described account holder confirms that this ratifies a motion, is used for an approval in-formation is sent to described businessman.
2. a kind of computer system as claimed in claim 1, wherein, described authorization module comprises that one mutual is confirmed module, responds and is used to start and described account holder sets up is connected receiving described trading approving request.
3. a kind of computer system as claimed in claim 2 also comprises a network interface, and wherein, described mutual affirmation module is used to by described network interface an electronic information be sent to described account holder.
4. a kind of computer system as claimed in claim 3, wherein, described mutual affirmation module is used to response and receives the described electronic information of answer there from described account holder, thereby confirms described trading approving request.
5. a kind of computer system as claimed in claim 2 also comprises a remote communication devices, and wherein, described mutual affirmation module sends to described account holder to an automatic telephone call.
6. a kind of computer system as claimed in claim 5, wherein, this confirms that alternately module is used to:
Set up and be connected with described account holder's phone;
At least the part of described trading approving request is repeated to this account holder; And
Receive about the affirmation of this trading approving request instruction from this account holder.
7. a kind of computer system as claimed in claim 6, wherein, should confirm alternately that module also was used to, before the described step of at least part of this trading approving request being repeated to this account holder, ask for an authentication codes there from this account holder.
8. a kind of computer system as claimed in claim 1, wherein, described authorization module comprises a mutual affirmation module, is used for waiting for that described account holder startup is connected with the described of its.
9. a kind of computer system as claimed in claim 8 also comprises a network interface, and wherein, this confirms that alternately module is used for by the communication of described network interface wait from described account holder.
10. a kind of computer system as claimed in claim 8 also comprises a network interface, and wherein, described mutual affirmation module is used for
Receive a connection request by this network interface there from described account holder;
Foundation and this account holder's network service;
Checking this account holder;
At least a described part that ratifies a motion is sent to this account holder by this network interface; And
Receive about this affirmation that ratifies a motion instruction from this account holder there.
11. a kind of computer system as claimed in claim 8 also comprises a remote communication devices, and wherein, described mutual affirmation module is used for waiting for the call from described account holder.
12. a kind of computer system as claimed in claim 8 also comprises a remote communication devices, wherein, described mutual affirmation module is used to:
Receive a call there from described account holder;
Checking this account holder;
At least the part of described trading approving request is repeated to this account holder; And,
Receive about the affirmation of this trading approving request instruction from this account holder.
13. a kind of computer system as claimed in claim 1, wherein, response is not having to be used to automatically confirm follow-up trading approving request under the situation about further importing from this account holder from the described authorization module of described account holder's instruction.
14. a kind of computer system as claimed in claim 1, wherein, described authorization module comprises a main affirmation module, is used for responding the passage of certain predetermined period of time, if and described account holder also do not confirm described ratifying a motion, be used for abandoning this and ratify a motion.
15. a kind of computer system as claimed in claim 14 wherein, describedly main confirms that module also is used for, and when abandoning described trading approving request notice is sent to described account holder.
16. a kind of computer system as claimed in claim 1, wherein:
Described trading approving request is an affirmation request from third party financial institution; And,
Described authorization module is used for confirming that a mark sends to described third party financial institution.
17. be used to confirm a kind of method of business transaction between account holder and businessman in computer system, described method comprises:
Reception is from a trading approving request of described businessman, and described ratifying a motion comprises a complete account number of confirming described account holder account;
By separate with communicating by letter of described businessman with the communicating by letter of described account holder, confirm this trading approving request with this account holder electronically; And,
As long as described account holder has confirmed described trading approving request, then an approval in-formation is sent to described businessman.
18. a kind of method as claimed in claim 17, wherein, affirmation comprises about the step of described card holder's trading approving request, reminds described account holder to confirm this trading approving request.
19. a kind of method as claimed in claim 18, wherein said prompting this account holder confirms that the step of described trading approving request comprises, an electronic information is sent to this account holder.
20. a kind of method as claimed in claim 19, wherein the described step about this trading approving request of this account holder comprises, receives the answer to described electronic information.
21. a kind of method as claimed in claim 18 wherein reminds described account holder to confirm that the step of described trading approving request comprises, sends an automatic telephone call to this account holder.
22. a kind of method as claimed in claim 21, wherein the step that sends an automatic telephone call to described account holder comprises:
Set up and be connected with this account holder's a phone;
At least the part of this trading approving request is repeated to this account holder;
And receive about the affirmation of this trading approving request instruction from this account holder.
23. a kind of method as claimed in claim 22, wherein the step that sends an automatic telephone call to described account holder also comprises, before described at least a portion this trading approving request is repeated step to this account holder, receive a Validation Code from this account holder.
24. a kind of method as claimed in claim 17, wherein, the described step of confirming this trading approving request electronically with this account holder comprises and waits for communicating by letter of this account holder startup and described computer system.
25. a kind of method as claimed in claim 24 wherein, is connected by network by this account holder and to start and the communicating by letter of described computer system.
26. a kind of method as claimed in claim 24 wherein, describedly confirms that with this account holder the step of this trading approving request comprises electronically:
Receive a connection request by a network interface from this account holder;
Foundation and this account holder's a network service;
Checking this account holder;
At least the part of described trading approving request is sent to this account holder; And
Receive about the affirmation of this trading approving request instruction from this account holder there.
27. a kind of method as claimed in claim 24 wherein connects communicating by letter of startup and described computer system by described account holder by phone.
28. a kind of method as claimed in claim 24 wherein, describedly confirms that with this account holder the step of this trading approving request comprises electronically:
Receive a call from this account holder;
Checking this account holder;
At least the part of described trading approving request is repeated to described account holder; And,
From the affirmation instruction of this account holder reception about this trading approving request.
29. a kind of method as claimed in claim 17, wherein, described account holder can optionally allow or forbid, the described step of confirming this trading approving request electronically with this account holder.
30. a kind of method as claimed in claim 17, wherein, describedly confirm that with this account holder the step of this trading approving request comprises electronically, if at the fixed time at interval in this account holder do not confirm this trading approving request, then abandon this automatically and ratify a motion.
31. a kind of method as claimed in claim 30 also comprises, when abandoning this trading approving request, notice is sent to this account holder.
32. a kind of method as claimed in claim 17, wherein:
The step that receives described trading approving request from described businessman there comprises, receives one there and confirms request from receiving third party financial institution that this merchant transaction ratifies a motion; With
The step that an approval in-formation is sent to this businessman comprises acknowledgement indicator is sent to described third party financial institution.
33. a computer system that is used for confirming the business transaction between card holder and businessman, described computer system comprises:
A processing unit that is used for deal with data and code; With
A storage arrangement that is used for storing described data and described code,
Described storage arrangement comprises: businessman's communication module, be used to set up and being connected of described businessman, and be used for receiving a trading approving request that comprises the full account number that interrelates with described account holder,
Described data comprise: at least one standard confirmed in advance that interrelates with this account holder,
Described storage arrangement also comprises: the authorization module of a described trading approving request of response, be used for relatively this trading approving request and the described standard of confirming in advance, and if at least one standard of confirming in advance is met, then confirm this trading approving request.
34. a kind of computer system as claimed in claim 33, wherein:
Described at least one standard of confirming in advance comprises the multinomial standard of confirming in advance; And,
When the standard that described authorization module is confirmed in advance at least one item is met, confirm described trading approving request.
35. a kind of computer system as claimed in claim 33, wherein:
Described at least one standard of confirming in advance comprises the multinomial standard of confirming in advance; And,
Described authorization module only when the described multinomial standard of confirming in advance all is met, is just confirmed described trading approving request.
36. a kind of computer system as claimed in claim 33 wherein, is determined the described standard of confirming in advance by described account holder.
37. a kind of computer system as claimed in claim 33 also comprises an account holder communication module, is used for:
Reception is from described account holder's connection request;
Foundation is connected with this account holder's;
Checking this account holder;
At least one of the described standard of confirming in advance offered this account holder; And,
Receive the instruction that is used to revise one of this standard of confirming in advance there from this account holder.
38. a kind of computer system as claimed in claim 37, wherein, before the described modify instruction that receives from described account holder, described trading approving request neither one can satisfy the described standard of confirming in advance.
39. a kind of computer system as claimed in claim 33, wherein, the described standard of confirming in advance comprises at least one businessman's identification marking.
40. a kind of computer system as claimed in claim 39, wherein, described authorization module responds to receiving described trading approving request, is used for:
Described trading approving request and each businessman's identification marking that described businessman is sent compare;
If identify the described trading approving request that this businessman sends by certain businessman's identification marking, then confirm this trading approving request.
41. a kind of computer system as claimed in claim 33, wherein, the described standard of confirming in advance comprises the purchasing price that a maximum is confirmed in advance.
42. a kind of computer system as claimed in claim 41, wherein, described authorization module responds to receiving described trading approving request, is used for:
The purchasing price that the purchasing price that comprises in this trading approving request and described maximum are confirmed in advance compares; And,
If the purchasing price that the purchasing price that comprises in this trading approving request is confirmed in advance less than this maximum is then confirmed this trading approving request.
43. a kind of computer system as claimed in claim 33, wherein, the described standard of confirming in advance comprises a from date and a Close Date.
44. a kind of computer system as claimed in claim 43, wherein said authorization module responds to receiving described trading approving request, is used for:
Purchase date that this trading approving request is comprised and described from date and described Close Date compare; And,
If this purchase date is between this from date and should confirm then that this ratified a motion between the Close Date.
45. in certain computer system, be used to confirm a kind of method of the business transaction between account holder and businessman, described method comprises:
At least one standard of confirming in advance that storage and described account holder interrelate;
Reception is from the trading approving request of described businessman, and described trading approving request comprises a complete account number that interrelates with this account holder;
This trading approving request and this standard of confirming are in advance compared; And,
If this standard of confirming in advance is met, confirm described trading approving request.
46. a kind of method as claimed in claim 45, wherein:
The step that is used for storing at least one standard of confirming in advance comprises the multinomial standard of confirming in advance of storage; And,
The step of confirming described trading approving request comprises, if at least one described standard of confirming in advance is met, then confirms this trading approving request.
47. a kind of method as claimed in claim 45, wherein:
The step that is used for storing at least one standard of confirming in advance comprises the multinomial standard of confirming in advance of storage; And,
The described step of confirming described trading approving request comprises having only the described standard of confirming in advance all to be met, and just confirms this trading approving request.
48. a kind of method as claimed in claim 45 wherein, is determined described at least one standard of confirming in advance by described account holder.
49. a kind of method as claimed in claim 45 also comprises:
One of foundation and described account holder is connected;
Checking this account holder; And,
Allow this account holder to revise the described standard of confirming in advance that interrelates with this account holder.
50. a kind of method as claimed in claim 49, wherein, before described account holder revised, the described standard of confirming in advance can not be met.
51. a kind of method as claimed in claim 45, wherein, the described standard of confirming in advance comprises at least one businessman's identification marking.
52. a kind of method as claimed in claim 51, wherein:
The described standard of confirming in advance comprises a plurality of businessmans identification marking;
If some in described a plurality of businessmans identification marking identifies described businessman, then confirm described trading approving request.
53. a kind of method as claimed in claim 45, wherein, the described standard of confirming in advance comprises a purchasing price of confirming in advance.
54. a kind of method as claimed in claim 53, wherein, if certain purchasing price of in described trading approving request, discerning less than described confirm in advance purchasing price, then confirm this trading approving request.
55. a kind of method as claimed in claim 45, wherein, the described standard of confirming in advance comprises the date that at least one is confirmed in advance.
56. a kind of method as claimed in claim 55, wherein:
The described standard of confirming in advance comprises the date that at least one pair of is confirmed in advance; And
If the trade date that comprises in described trading approving request is then confirmed this trading approving request between the described date of confirming in advance.
CN 01812985 2000-07-17 2001-07-16 System and method for verifying commercial transactions Expired - Fee Related CN1203437C (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US09/617,361 2000-07-17
US09/617,361 US8380628B1 (en) 2000-07-17 2000-07-17 System and method for verifying commercial transactions
US09/760,271 US8352369B2 (en) 2000-07-17 2001-01-12 System and method for pre-verifying commercial transactions
US09/760,271 2001-01-12

Publications (2)

Publication Number Publication Date
CN1449537A CN1449537A (en) 2003-10-15
CN1203437C true CN1203437C (en) 2005-05-25

Family

ID=27088013

Family Applications (1)

Application Number Title Priority Date Filing Date
CN 01812985 Expired - Fee Related CN1203437C (en) 2000-07-17 2001-07-16 System and method for verifying commercial transactions

Country Status (7)

Country Link
EP (1) EP1312009A4 (en)
JP (1) JP2004519022A (en)
CN (1) CN1203437C (en)
AU (2) AU2001273490A1 (en)
CA (1) CA2415366A1 (en)
NZ (1) NZ523746A (en)
WO (1) WO2002008995A1 (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7264154B2 (en) 2004-07-12 2007-09-04 Harris David N System and method for securing a credit account
US7324976B2 (en) * 2004-07-19 2008-01-29 Amazon Technologies, Inc. Automatic authorization of programmatic transactions
DE112007002763T5 (en) * 2006-11-16 2009-09-24 Net1 Ueps Technologies, Inc. Identification verification of the buyer
CN105654269A (en) * 2014-11-12 2016-06-08 阿里巴巴集团控股有限公司 Characteristic date data node configuration method and device

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5708422A (en) * 1995-05-31 1998-01-13 At&T Transaction authorization and alert system
US6088683A (en) * 1996-08-21 2000-07-11 Jalili; Reza Secure purchase transaction method using telephone number
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
US6064990A (en) * 1998-03-31 2000-05-16 International Business Machines Corporation System for electronic notification of account activity
EP1006469A1 (en) * 1998-12-02 2000-06-07 Koninklijke KPN N.V. System for secure transactions
JP2000194747A (en) * 1998-12-25 2000-07-14 Toshiba Corp Transaction approval system

Also Published As

Publication number Publication date
AU2001273490A1 (en) 2002-02-05
AU2008202099A1 (en) 2008-06-05
EP1312009A4 (en) 2007-07-04
NZ523746A (en) 2004-10-29
CA2415366A1 (en) 2002-01-31
CN1449537A (en) 2003-10-15
EP1312009A1 (en) 2003-05-21
WO2002008995A1 (en) 2002-01-31
JP2004519022A (en) 2004-06-24

Similar Documents

Publication Publication Date Title
US8332310B2 (en) System and method for facilitating the handling of a dispute using disparate architecture
CN1454364A (en) Method and system for processing Internet payments
US20160098721A1 (en) Confirming local marketplace transaction consummation for online payment consummation
US20080071678A1 (en) System and method for facilitating loan provision
WO2012150980A1 (en) Systems and methods for electronic document identification and certification
CN1647089A (en) Electronic transfer system
CN1459068A (en) Automated payment system
CN1682232A (en) Electronic payment validation using transaction authorization tokens
CN1842813A (en) A system and method for facilitating on-line payment
US20030182227A1 (en) Payment monitoring system
CN1666215A (en) Insurance contract accounting system
CN1554064A (en) Portable card reader and card settlement system
US20020010638A1 (en) Method and system for mixed-mode electronic commerce processing of on-line orders
US20050178824A1 (en) On-line merchant services system and method for facilitating resolution of post transaction disputes
CN1203437C (en) System and method for verifying commercial transactions
JP2002099655A (en) System and method for electronically informationized dealing of ticket, and recording medium
US20030033208A1 (en) Method and system for communicating using a user defined alias representing confidential data
US20090106034A1 (en) System and method for making third party pickup available to retail customers
US20020099566A1 (en) Network service applying apparatus, network service applying method, strorage medium and computer data signal
JP4516661B2 (en) Intellectual property license agreement brokerage system and method
JP2016164786A (en) Shareholder management device, shareholder management method and program
JP2008276499A (en) Card use notification system
CN1370308A (en) System and method for managing phirality of accounts of internet sites by ising integrated circuit card
JP2005215889A (en) Personal identification method and personal identification program
JP7414245B2 (en) Computer-implemented method, computer system for exercising rights associated with blockchain non-fungible tokens

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
C17 Cessation of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20050525

Termination date: 20130716