WO2001035570A1 - Payment method and system for online commerce - Google Patents
Payment method and system for online commerce Download PDFInfo
- Publication number
- WO2001035570A1 WO2001035570A1 PCT/US2000/030427 US0030427W WO0135570A1 WO 2001035570 A1 WO2001035570 A1 WO 2001035570A1 US 0030427 W US0030427 W US 0030427W WO 0135570 A1 WO0135570 A1 WO 0135570A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- transaction
- party
- administrator
- key
- merchant
- Prior art date
Links
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/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
Definitions
- the present invention relates to conducting commerce utilizing the Internet, and more particularly to a payment system that utilizes a transaction administration system to process, authorize and match purchase requests to merchants, verify merchant fulfillment of the purchase request and execute the associated credit or debit payment from the purchasing party's account to the merchant.
- Cards and debit cards have been used in commerce for many years.
- the consumer physically authenticates himself in the presence of the merchant by presenting his card and agrees to the terms of the transaction by signing a purchase slip and simultaneously taking physical possession of the purchased goods.
- the merchant can usually electronically confirm that the purchase amount is within the card's credit limit.
- the merchant delivers the purchase slip to his bank (the "Acquiring Bank") for payment.
- the Acquiring Bank delivers the purchase slip to the bank that issued the credit card (the "Issuing Bank"), which credits the Acquiring Bank.
- the purchase slip may be delivered physically or electronically.
- the Issuing Bank typically uses the ground mail system to deliver statements, confirm transactions, and receive payments from cardholders.
- the Internet also represents a significant and growing source of merchant fraud against the existing credit and debit card system, in part because of the rapid formation of merchants with a limited operating history.
- One of the advantages of Internet commerce is that the Internet is capable of connecting customers and merchants, or even two private individuals, in transactions where the parties do not know each other and will have no association in the future.
- these anonymous transactions create new types of transaction risks for all parties to an electronic transaction.
- the risks created by these anonymous transactions cannot be addressed with the existing debit or credit card systems.
- Another risk that is unique to the Internet is with the intellectual property that is acquired and delivered via the Internet, such as software, games or music files. Such intellectual property is exposed to effectively unlimited copying and use in violation of the rights of the owner of the intellectual property.
- the current payment systems have no reliable method or procedure that can link the purchaser of intellectual property with the use of said intellectual property, or even a method verifying that the purchaser in fact received a working copy of the subject intellectual property. Because the owner or licensor of intellectual property may have difficulty verifying that the purchaser received the purchased or licensed intellectual property, the owner is currently limited in his ability to enforce payment by the purchaser and to protect from outright theft.
- Another security issue is the potential for credit card and debit card fraud. Unlike a physical transaction, the merchant cannot ask the buyer for identification in an online transaction. Teen that acquires a valid credit card account number can potentially use it to make purchases. There is also a potential for merchant fraud. Once the merchant has the credit card account number, he can potentially misuse it by overcharging the buyer, not delivering the goods ordered after receiving payment, or giving the account number to another. Additionally, there is the risk of interception by third parties, as the credit or debit card account number and other personal information is electronically transmitted during the transaction processing.
- the present invention has been made in view of the above circumstances and solves the problems of current payment systems by creating an on-line payment system that verifies the authenticity of the transaction parties, verifies that the transaction details are correct, facilitates the verification of delivery of the goods and services, provides increased protection to owners of intellectual property conducting business on the Internet, prevents the misappropriation of personal information, prevents Internet identity theft through credit or debit card information, and reduces the cost of unwinding an electronic commerce transaction in a manner that does not constrain or diminish the cost-reducing impact of the Internet on commerce.
- One object of the present invention is to provide an on-line payment system that uses electronic real-time connections to match, authenticate, and confirm all the components of a transaction between all the parties involved in the transaction that does not require the use of traditional physical credit or debit cards or the transmission of card account numbers to make purchases.
- Another object of the present invention is to provide a transaction administration system for confirming and authorizing transactions by receiving the terms of the transaction from a first transaction party, receiving the terms of the transaction from a second transaction party and comparing the terms of the transaction received from the first transaction party with the terms of the transaction received from the second transaction party to determine whether the terms match.
- a further object of the present invention is to provide a method for merchants to obtain authorization of an electronic transaction by providing transaction information to the buyer, receiving a transaction key from the buyer, transmitting the transaction key to the transaction administrator and receiving a purchase authorization from the transaction administrator.
- a further object of the present invention is to provide a transaction administration system for confirming delivery of purchases by receiving the terms of the delivery from a transaction party, receiving the confirmation of the delivery from a delivery agent and comparing the terms of the delivery received from the transaction party with the delivery confirmation to determine whether the terms match.
- a further object of the invention is to provide a method of identifying a transaction party through his client software.
- one aspect of the invention includes a method of authenticating an electronic transaction between a plurality of transaction parties by a transaction administrator. This method comprises receiving the terms of the transaction from a first transaction party; receiving the terms of the transaction from a second transaction party; comparing the terms of the transaction received from the first transaction party with the terms of the transaction received from the second transaction party to determine whether the terms match; and if the terms match, validating the transaction.
- a further aspect of the invention includes a method for a seller to obtain authorization of an electronic transaction.
- This method comprises providing transaction information including a seller identifier to a buyer; receiving a transaction key from the buyer; transmitting the transaction key to a transaction administrator; and receiving an authorization from the transaction administrator.
- Another aspect of the invention includes a method of authorizing an electronic transaction between a plurality of transaction participants by a transaction administrator.
- This method comprises providing transaction information by a first transaction party to the transaction administrator; generating a transaction key by the transaction administrator and providing the transaction key from the transaction administrator to the first transaction party; providing the transaction key from the first transaction party to a second transaction party; providing the transaction key from a second transaction party to the transaction administrator for validation; and validating the transaction by the transaction administrator.
- Another aspect of the invention includes a method of authorizing an electronic transaction between a plurality of transaction participants by a transaction administrator.
- This method comprises providing transaction information by a first transaction party to the transaction administrator; generating a transaction key by the transaction administrator and providing the transaction key from the transaction administrator to the first transaction party; providing the transaction key from the first transaction party to a second transaction party; providing the transaction key from a second transaction party to the first transaction party; providing the transaction key from the first transaction party to the transaction administrator for validation; and validating the transaction by the transaction administrator.
- Another aspect of the invention includes a method of authenticating the delivery of goods between a plurality of transaction parties. This method comprises providing a transaction administration system for confirming delivery of purchases; receiving the terms of the delivery from a transaction party; receiving the confirmation of the delivery from a delivery agent; and comparing the terms of the delivery received from the transaction party with the delivery confirmation to determine whether the terms match.
- Another aspect of the invention includes a method of authenticating a transaction between a plurality of transaction parties.
- This method comprises requesting a transaction from a second transaction party by a first transaction party; providing transaction information to the transaction administrator by the second transaction party; requesting the first transaction party to confirm the transaction request; providing confirmation to the transaction administrator by the first transaction party; comparing the confirmation with stored confirmation data for the first transaction party; and validating the transaction by the transaction administrator.
- Another aspect of the invention includes a method of authenticating a transaction between a plurality of transaction parties.
- This method comprises requesting a transaction by a first transaction party from a second transaction party; providing transaction information to the transaction administrator from the second transaction party; providing a transaction number to the second transaction party by the transaction administrator; communicating the transaction number to the first transaction party by the second transaction party; confirming the transaction by the first transaction party contacting the transaction administrator and communicating the transaction number; comparing the confirmation provided by the first transaction party with the stored transaction number; and validating the transaction by the transaction administrator.
- Another aspect of the present invention includes a method of unwinding a transaction between a buyer and a seller each having an account with a transaction administrator.
- This method comprises requesting a return transaction from the seller; receiving a return transaction number; returning goods to a delivery agent; delivering the return goods to the seller by the delivery agent; and crediting the buyer's account and debiting the merchant's account by the transaction administrator upon the seller's receipt of the return goods.
- Another aspect of the present invention includes a method of verifying the electronic purchase and delivery of intellectual property between a plurality of transaction parties, where a first transaction party requests to purchase downloadable intellectual property from a second transaction party by a transaction administrator.
- This method comprises providing transaction information to a transaction administrator; generating and providing a transaction key and a private delivery key to the first transaction party by the transaction administrator; providing the transaction key to the second transaction party from the first transaction party; providing the transaction key to the transaction administrator by the second transaction party; validating the transaction by comparing the received transaction key with the one generated; if the transaction is validated, providing a public delivery key to the second transaction party; providing the intellectual property to the first transaction party encrypted with the private delivery key; and decrypting the intellectual property by the first transaction party.
- Fig. 1 illustrates the enrollment process for buyers, merchants, shipping agents, and issuing banks.
- Fig. 2 illustrates the relationships of the transaction parties for a typical transaction in the present invention.
- Fig. 3 illustrates software components of the system of the present invention.
- Fig. 4 illustrates the connectivity of the system of the present invention.
- Fig. 5 is a flowchart illustrating the basic transaction authentication process of the system of the present invention.
- Fig. 6A-B illustrate embodiments of the transaction authentication process.
- Fig. 7A-B illustrate the data flow for embodiments of the transaction authentication process.
- Fig. 8 is a flowchart illustrating the process for authentication from a remote terminal.
- Fig. 9 is a flowchart illustrating the process for an off-line transaction from a telephone.
- Fig. 10 illustrates the Order Delivery Confirmation Service process.
- Fig. 11 illustrates the Online Delivery process.
- Fig. 12 illustrates the periodic payment process. DETAILED DESCRIPTION
- a key issue for the growth of electronic commerce over the Internet is the ability to be able to order goods and services without the fear of privacy invasion or credit or debit card fraud.
- a number of encryption methods and other methods have been used to address this issue; however, these methods only reduce certain risks. Moreover, they do not attempt to address authentication or original message validity. Therefore electronic transactions are still vulnerable to theft or fraud.
- the present invention solves the problems of conventional card based electronic commerce transactions by creating an on-line payment system that does not use traditional physical credit or debit cards, signatures, or account numbers.
- the system of the present invention is implemented through client software on the computers of the system participants and a central transaction administration system. Each client software component interacts with the client software of one or more other system participants and with the central transaction administration system.
- the transaction administration system receives transaction requests other parties to a transaction and simultaneously compares the information received from each other to ensure that the transaction information received from each party matches, thereby authenticating the transaction.
- the first party to the transaction is a buyer
- the second party to the transaction is a merchant
- the transaction request is a request from the buyer to purchase goods or services from the merchant charging the purchase price to the buyer's account with a financial institution affiliated with the transaction administration system.
- the transaction administration system compares the terms of the transaction as the buyer knows them to the terms of the transaction as the merchant knows them, to ensure that all terms match.
- the terms in a buyer-merchant transaction may include the buyer's identity, the merchant's identity, item identifiers, prices and quantities, payment mechanisms, and delivery instructions. If the terms of the transaction as known by the buyer match the terms as known by the merchant, then the transaction administration system may authenticate the transaction. When the merchant receives authorization from the transaction administration system, he ships or downloads the purchased goods or information to the buyer.
- Every transaction party that participates in the system has a unique and private identifier.
- the identifier is assigned to a party through his client software. The actual party to a transaction does not even need to know what his identifier is, as the client software on his computer automatically identifies that party to the system.
- the identifiers are preferably embedded in the client software, and not made known to the users. The identifiers are used by the transaction administrator in the authentication matching process. Only the transaction administration system can tell who a party is through an identifier. Because a system identifier cannot be altered, duplicated or stolen, the risk of fraud is virtually eliminated. Additional security can be achieved by using a password or PIN in conjunction with the private identifier.
- the client software on his computer sends his unique identifier to the client software on the merchant's system.
- the buyer's identifier becomes one of the transaction terms that the merchant "knows" for purposes of the authentication matching that takes place later.
- the merchant does not actually know who the buyer is, but rather the client software on the merchant's system receives the buyer's identifier as part of the process.
- the client software on the merchant's system sends the merchant's unique identifier to the buyer, adding to the terms of the transaction that the buyer "knows" through the buyer's client software.
- the transaction administration system compares transaction terms, the purchase will only be approved if all of the terms, including the party identifiers, match. If all of the terms match, the transaction administration system generates and returns a transaction key to the buyer. To complete the process, the buyer transmits the transaction key to the merchant. The merchant gets final approval for the purchase by transmitting the transaction key back to the transaction administration system. The transaction administration system validates the transaction by matching the transaction key that was sent back by the merchant with the one that it generated when it performed the first match. The merchant does not ship or download the purchased goods, or perform the purchased services, until he receives a validation confirmation from the transaction administration system. By going through this process, there is a high level of assurance that the buyer is buying said goods or services, and that the merchant has agreed to the terms.
- Matching ensures that there is no transaction misunderstanding and therefore little possibility of transaction fraud. Matching can be applied to the delivery of the goods or services as well as the sale of the goods or services. By electronically connecting the delivery agent, the transaction administrator can confirm actual delivery of goods and services.
- the system of the present invention allows all users, includes individuals, to act as buyers and sellers. Since both parties are electronically linked to a network, either can act as buyer or seller. This enables individuals to act as sellers, allowing for person to person electronic commerce.
- a credit or debit card account number is not required. Instead, the transaction parties are directly linked with the transaction administration system. The accounts are established when the buyer and merchant register or enroll with the transaction administration system. The system identifies the transaction parties through the client software on each party's computer.
- system of the present invention is described in terms of credit or debit cards, it should be understood that the concepts of the system of the present invention can be variously and appropriately applied and combined with many types of financial services and products.
- Demand Deposit Accounts Direct Debit Accounts, Lines of Credit, Securities Accounts, Mutual Fund Accounts, and Stored Value Accounts can be advantageously combined with or compliment the system of the present invention.
- Many types of financial transactions such as installment loans, secured debt accounts or revolving debt accounts, can be implemented by the system of the present invention.
- the system of the present invention implements a Transaction Administration system to process purchase requests over a public network, such as the Internet.
- a Transaction Administrator (TA), working with affiliated financial institutions, may act as a clearinghouse, cash recipient, and/or payment disburser to the actual parties of an online transaction.
- the TA validates the transaction by comparing the terms of the transaction that one transaction party knows with the terms of the transaction that another transaction party knows. Parties to the transaction may include buyers, merchants and shipping agents.
- the transaction term matching that the TA performs can apply to sales as well as delivery transactions. The TA will validate the transaction only if all the terms match.
- the matching process virtually eliminates transaction and settlement risks. Neither party can claim to have not entered into the transaction, nor that delivery was not completed. Additionally, the terms of sale and delivery are unambiguously settled by the TA, thereby defining the contract between the parties.
- the parties to an electronic transaction register or enroll with the system before any transactions take place.
- the enrollment process identifies a party to the system, and provides each party with the appropriate software to enable that party to participate in the system.
- Fig. 1A-1D illustrate the preferred four types of parties to the system and the process of enrolling for each party.
- a preferred "Merchant” is an organization selling goods or services via the Internet.
- a merchant For a merchant to participate in the system of the present invention, he must become an Authorized Merchant with the system.
- an online merchant can request to participate in the system, or be asked to participate in the system. If the merchant decides to participate, he signs an agreement with the TA agreeing to use the system as a form of payment. The agreement defines the transaction terms for the merchant, comparable to the merchant who accepts VISA or MasterCard.
- the TA provides the Authorized Merchant with Merchant software in step 112.
- This Merchant software may include Application Program Interfaces (APIs) and Applications that the Authorized Merchant must integrate into its Website and order fulfillment system in order to participate in the system, at step 114.
- APIs Application Program Interfaces
- the APIs typically manage communications with the TA and with existing Merchant software programs.
- the Merchant software can be electronically transmitted to the Merchant, or it can be delivered via CD-ROM or the like.
- the Merchant software preferably establishes a unique identifier to identify the Merchant's system to the TA at step 116. This Merchant ID is used throughout the system to identify the Merchant to the TA.
- a preferred "Issuing Bank” is a financial institution subject to federal and/or state banking laws that is authorized to offer consumer credit and demand deposit accounts in the jurisdictions in which it operates. Any Issuing Bank that participates in the system already has the infrastructure and technology to offer debit and credit transaction in real-time. As shown at step 120 in Fig. IB, a financial institution can request to participate in the system, or be asked to participate in the system.
- the TA may sign a "franchise" agreement with the TA.
- the TA preferably provides Issuing Bank software to the financial institution in step 122.
- This Issuing Bank software may include Application Program Interfaces (APIs) and Web Connection Modules that the financial institution integrates into its systems, at step 124.
- This software can be electronically transmitted to the financial institution, or it can be delivered via CD-ROM or the like.
- a preferred "Shipping Agent" can be any type of shipping company or service.
- a Participating Shipper will utilize the system's tracking software and collect required signatures from package recipients as part of the Order Delivery Confirmation service.
- a shipping agent can request to participate in the system, or be asked to participate in the system. If the shipping agent decides to participate, he signs an agreement with the TA.
- the TA provides Shipper software to the shipping agent in step 132.
- This Shipper software may include APIs and Applications that the shipping agent integrates into its system in order to participate in the system, at step 134. This software can be electronically transmitted to the shipping agent, or it can be delivered via CD-ROM or the like.
- a preferred "Account Holder” can be an individual or corporation that establishes a credit/debit relationship with an Issuing Bank.
- An Account Holder can set up subaccounts to manage the transactions of employees or family members.
- the subaccounts can be linked to purchase order systems or secure email approval notices to an authorizing party.
- a person or organization must request to participate in the system, as shown at step 140 in Fig. ID.
- the TA provides Account Holder software to the Account Holder in step 142.
- the Account Holder software typically includes Internet browser plug-ins or applets.
- the Account Holder installs the Account Holder software at step 144. This software can be electronically transmitted to the Account Holder, or it can be delivered via CD-ROM or the like.
- the Account Holder software creates a unique identifier to identify the Account Holder's computer to the TA at step 146. It is through the Account Holder software that the system identifies the Account Holder. There are a number of methods that can be used to uniquely identify the computer or device through the Account Holder client software. The identifier may be determined through a fixed spot on the computer's hard drive, through the CPU's identifier, or through a secret token embedded in the software, for example. The Account Holder does not know his identifier, and cannot give it away. The transaction administration system may periodically establish new Account Holder identifiers to further ensure security. Additional security may be achieved by using a password or Personal Identification Number (PIN) in conjunction with the private ID established by the Account Holder client software.
- PIN Personal Identification Number
- the Account Holder software is typically a browser plug-in that works with publicly available Internet browsers, such as Netscape Navigator and Microsoft Explorer.
- the Account Holder software may be a Wireless Application Protocol designed to work with the Operating Systems on handheld wireless devices, such as Palm OS, Go OS, and Mac OS, or with digital wireless telephones.
- the Account Holder client software may have built-in links to Quicken and Microsoft Money, so that transaction information can be populated into these applications. With the Account Holder client software, the Account Holder may review online payment histories, and the like. The Account Holder client software may also be customized so that it can block purchases by amount, type of goods, or Merchant. This is an important feature for Account Holders who wish set up subaccounts for family members or employees.
- Fig. 2 A preferred relationship between the participating entities of the present invention are shown in Fig. 2 and will now be explained.
- Merchant 290 is an organization selling goods or services via the Internet that has registered with the Transaction Administrator (TA) 250 to become an Authorized Merchant.
- TA Transaction Administrator
- To participate in the system, Merchant 290 has integrated the Merchant Software into its e-commerce Website and order fulfillment system. This enables purchasers to choose the system of the present invention as the method of payment when making purchases from the Merchant's Website.
- Account Holder 280 preferably has a standard Merchant-Client relationship with Merchant 290, ordering retail products and/or services from Merchant 290.
- Each participating Merchant 290 preferably establishes an account at a
- Merchant Bank 220 that also participates in the system. Merchant Bank 220 is responsible for making payments to the Merchant 290 on receipt of valid credit events. As indicated by the dashed lines, TA 250 can also act as a Merchant Bank. Merchants may electronically present payment events to TA 250 or a Merchant Bank 220 for payment.
- Merchant Bank 220 or TA 250 has an account at each Issuing Bank 210.
- Merchant Bank 220 sweeps on a regular basis to credit Merchant accounts, collecting payments due as directed by TA 250, or TA 250 may act as a Merchant Bank, and process disbursements from Issuing Bank 210 to Merchant 290.
- Issuing banks 210 establish credit/debit relationships with the system's registered Account Holders 280. Issuing Bank 210 establishes the account and provides funds availability to the Account Holder 280. Issuing Bank 210 sends statements to Account Holder 280 just like a traditional credit card or debit card issuing bank.
- TA 250 preferably maintains control of discount points, coupon distribution and discounts from Merchants to Account Holders.
- TA 250 may provide customer service for the software and technology for Account Holders for the Issuing Bank.
- Merchant 290 may also establish an account with Shipper 260.
- Account Holder 280 receives purchases goods via delivery from Shipper 260. In charge-on-delivery transactions, the Account Holder's account is debited upon signing/receipt of the goods.
- Shipper 260 transmits the required information to TA 250.
- Shipper 260 also has an account with Merchant 290.
- TA 250 provides the real-time transaction clearing utilities and acts as the cash recipient from Issuing Banks 210 and payment disburser to Merchant Bank 220, or to Merchant 290, if it is also acting as the Merchant Bank.
- a preferred high-level view of the software components of the system of the present invention is show in Fig. 3.
- Account Holder 280 communicates through the Account Holder client software, typically a Netscape Navigator or Microsoft Explorer Browser plug-in 380.
- a Merchant 290 uses its own Merchant Transaction systems to communicate through the Merchant client software 390, which may consist of an Authorized Merchant Application and API.
- the Merchant client software 390 may be integrated with the Merchant's own sales and order fulfillment systems.
- Issuing bank 210 communicates through Issuing Bank software 310, which may include Issuing Bank Web Connection Module and API.
- the Issuing Bank client software is integrated into the Issuing Bank's own system.
- Shipper 260 communicates through Authorized Shipping Agent client software 360, which may include an Authorized Shipper Application API.
- TA 250 communicates through the Account and Transaction Management Application 350.
- the Account and Transaction Management Application 350 performs all of the TA functions, such as transaction term matching, account management, order fulfillment management, and the like.
- the transaction parties do not have to be connected to the system through their respective software components over the Internet, or any other public network.
- Other modes of communication can be considered for each of the various connections shown.
- Account Holder connections in the system are preferably Secured Server Links (SSLs).
- SSLs Secured Server Links
- connection 410 between an Account Holder and a Merchant connection 420 between an Account Holder and an Issuing Bank
- connection 430 between an Account Holder and the TA are Secured Server Links.
- Connection 450 between an Issuing Bank and the TA, and connection 460 between a Merchant and the TA are preferably either a Virtual Private Network Connection (VPN) or a Secure Shell Connection (SSC).
- VPN Virtual Private Network Connection
- SSC Secure Shell Connection
- a first transaction party sends his transaction information to the TA.
- a second transaction party sends his transaction information to the TA.
- the TA compares these transaction information packets to determine if they are identical. If they match, then the TA returns a transaction authorization at step 570. If they do not match, a return to start may occur or termination of the process may occur.
- Fig. 5 The basic process outlined in Fig. 5 can be achieved through many different methodologies. Two preferred embodiments are shown in Figs. 6 and 7. A first preferred embodiment of the invention is illustrated in Figs 6A and 7A.
- a transaction process begins with the Account Holder 280. As shown in Fig. 7A, Account Holder 280 visits Merchant's Website 290, and makes purchase selections. Account Holder 280 then sends a purchase request 711 to Merchant 290 selecting the system of the present invention as the method of payment. For example, this can occur after he fills his electronic shopping cart or when he selects the Merchant's
- the purchase request typically contains such information as item Universal Price Codes (UPCs), price, and quantity.
- UPCs Universal Price Codes
- the client software at the Merchant's Website 290 responds to the purchase request by first generating a transaction identifier (ID), then transmitting this transaction ID along with the Merchant ID and transaction information 712 to the client software on the Account Holder's computer 280.
- ID transaction identifier
- the transaction ID is used throughout the process to identify this particular transaction. Because one buyer and one merchant may have a number of transactions over time, the transaction ID is needed to uniquely identify this particular transaction.
- the Account Holder client software on the Account Holder's computer adds the Account Holder's unique ID to the information and transmits all of the information 713 to the TA 250.
- the Account Holder's ID may be encrypted before it is transmitted with the rest of the transaction information.
- the information that is sent to TA 250 in data packet 713 defines the transaction as the Account Holder "knows" it. It is actually the client software on the Account Holder's computer that knows all of the terms of the transaction, not the actual Account Holder, as the user of the software never sees any of the identifiers used in the system. Because the Account Holder ID is only now transmitted, the Merchant is never in possession of any Account Holder information.
- TA creates and transmits an Issuing Bank approval request 720 to Issuing Bank 210 for the amount of the transaction.
- the client software on the Issuing Bank's system 210 uses the Account Holder's ID to access the Account Holder's account to determine whether to approve or reject the amount requested.
- the Issuing Bank 210 then transmits the transaction approval code 721 to TA 250. If the Issuing Bank 210 approves the transaction, TA 250 generates and transmits a Transaction Key 731 along with the Transaction ID to the Account Holder's computer.
- the client software on the Account Holder's computer 280 Upon receipt of the transaction key, the client software on the Account Holder's computer 280 sends the Transaction key and Transaction ID to Merchant 290 in data packet 732. In addition, the Account Holder may be prompted at this time for delivery method instructions. Delivery information will also be passed to the Merchant 290 in data packet 732. The client software on the Merchant's system 290 then transmits the Transaction ID, Transaction key, and transaction information including delivery instructions in data packet 733 to TA 250.
- TA 250 then matches keys and associated information that was sent by the Merchant 290. If the information matches, then TA 250 transmits an Approval Code with the Transaction ID 770 to the Merchant 290. In addition, TA 250 transmits a debit notice 780 to Issuing Bank 210. Upon receipt of the debit notice, Issuing Bank 210 debits Account Holder's account and credits TA's master account. The Merchant's account at the Merchant Bank or with the TA is then credited.
- Merchant 290 confirms to Account Holder 280 that the transaction is complete 790, and ships the goods.
- Step 510 from Fig. 5 is expanded to include substeps 611, 612, and 613.
- a first transaction party sends a transaction request to the second transaction party.
- Step 611 corresponds to data packet 711 in Fig. 7A, where the buyer makes a purchase request from a Merchant.
- the second party sends the transaction information including his identifier to the first party.
- Step 612 corresponds to data packet 712 in Fig. 7A, where the Merchant transmits the Merchant ID, Transaction ID, and all of the transaction information to the buyer.
- the first party transmits all of the information he received from the second party, including the second party's identifier, and his private identifier to the TA.
- Step 613 corresponds to data packet 713 in Fig. 7A, where the client software on the Account Holder's computer encrypts the Account Holder's private identifier, and sends it with the transaction information received from the Merchant to the TA.
- Substeps 611, 612, and 613 correspond to Step 510, where a first transaction party sends the transaction terms as he knows them to the TA.
- the first transaction party is the buyer, who is sending all of the specific purchase information, the Merchant's ID, and the Account Holder's ID to the TA.
- the client software on the Account Holder's machine manages all of the transmittals.
- the Account Holder does not have to manually transmit all of this information, and need not know what the client software is doing.
- the Account Holder simply makes a purchase request from the Merchant's Website.
- the client software on the Account Holder's computer receives the information from the Merchant, encrypts the Account Holder's ID and transmits the necessary information on to the TA.
- Step 620 in Fig. 6A corresponds to data packets 720 and 721 in Fig. 7A.
- the TA makes a transaction approval request from the Issuing Bank for the Account Holder for the amount of this specific transaction, and receives the Issuing Bank's approval code. If the transaction is approved, then the process in Fig. 6A continues to step 631.
- Step 530 from Fig. 5 is expanded to include substeps 631, 632, and 633 in Fig. 6 A.
- the TA generates and sends a Transaction Key with the Transaction ID to the client software on the Account Holder's computer.
- Step 631 corresponds to data packet 731 in Fig. 7A.
- the first party sends the transaction key and transaction ID the second party.
- Step 632 corresponds to data packet 732 in Fig. 7A.
- the second party transmits all of the information he received from the first party, including the transaction key to the TA.
- Step 633 corresponds to data packet 733 in Fig. 7A.
- Step 530 the TA compares all of the transaction information received from the first party in step 613 to the transaction information received from the second party in step 633 to ensure that every term, including party identifiers, matches.
- the TA compares the transaction key received from the second party at step 633 with the transaction key it generated and sent to the first party at step 631 to ensure a match. Only if all of the data items match does the TA send an approval code to the second party at step 570.
- the second party cannot complete the transaction without the transaction key.
- the only way that the second party can acquire the transaction key is through the first party. This protects the first party from unauthorized purchases on his account.
- a second preferred embodiment of the invention is shown in Figs. 6B and 7B.
- all communication to the TA is through one party.
- the first party performs the same steps 611, 612, and 613, transmitting the transaction terms to the TA.
- the TA receives the second party's transaction terms through the first party instead of through the TA.
- a transaction process begins when Account Holder 280 visits Merchant's Website 290, and makes purchase selections. Account Holder 280 then sends a purchase request 711 to Merchant 290 selecting the system of the present invention as the method of payment.
- the client software at the Merchant's Website 290 responds to the purchase request by first generating a transaction identifier (ID), then transmitting this transaction ID along with the Merchant ID and transaction information 712 to the client software on the Account Holder's computer 280.
- ID transaction identifier
- the Account Holder client software on the Account Holder's computer adds the Account Holder's unique ID to the information and transmits all of the information 713 to the TA 250.
- TA Upon receiving data packet 713, TA creates and transmits an Issuing Bank approval request 720 to Issuing Bank 210 for the amount of the transaction. The Issuing Bank 210 then transmits the transaction approval code 721 to TA 250. If the Issuing Bank 210 approves the transaction, TA 250 transmits a Transaction Key 731 along with the Transaction ID to the Account Holder's computer.
- the client software on the Account Holder's computer 280 Upon receipt of the transaction key, the client software on the Account Holder's computer 280 sends the Transaction key and Transaction ID to Merchant 290 in data packet 732. In addition, the Account Holder may be prompted at this time for delivery method instructions. Delivery information will also be passed to the Merchant 290 in data packet 732. The client software on the Merchant's system 290 will then re-transmit the Transaction ID, Transaction key, and transaction information including delivery instructions in data packet 733 back to the Account Holder 280. The client software on the Account Holder's computer 280 then re-transmits this information in data packet 734 to TA 250.
- TA 250 then matches keys and associated information that was sent by Account Holder 280. If the information matches, then TA 250 transmits a Transaction Approval Code with the Transaction ID 770 to Account Holder 280. The client software on the Account Holder's computer 280 then re-transmits the same information in data packet 771 to Merchant 290.
- TA 250 transmits a debit notice 780 to Issuing Bank 210.
- Issuing Bank 210 debits Account Holder's account and credits TA's master account. The Merchant's account at the Merchant Bank or with the TA is then credited.
- Merchant 290 confirms to Account Holder 280 that the transaction is complete 790, and ships the goods.
- Step 510 from Fig. 5 is expanded to include substeps 611, 612, and 613.
- a first transaction party sends a transaction request to the second transaction party.
- Step 611 corresponds to data packet 711 in Fig. 7B, where the buyer makes a purchase request from a Merchant.
- the second party sends the transaction information including his identifier to the first party.
- Step 612 corresponds to data packet 712 in Fig. 7B, where the Merchant transmits the Merchant ID, Transaction ID and all of the transaction information to the buyer.
- the first party transmits all of the information he received from the second party, including the second party's identifier, and his private identifier to the TA.
- Step 613 corresponds to data packet 713 in Fig. 7B, where the client software on the Account Holder's computer encrypts the Account Holder's private identifier, and sends it with the transaction information.
- the TA After performing steps 611, 612, and 613, thereby transmitting the first party's transaction terms to the TA, the TA gets credit approval for the transaction at step 620. After receiving approval for the transaction, the TA generates and sends a transaction key to the first party at step 631. The first party sends the transaction key to the second party at step 632. The second party transmits the transaction key and transaction information back to the first party at step 635. The first party resends this transmission to the TA at step 636. Steps 636 and 637 correspond to data packets 736 and 737 in Fig. 7B. The TA uses the information received at step 636 to compare against the information received at step 613 and the transaction key it generated at step 631 to ensure that all terms match.
- Steps 670 and 671 correspond to data packets 770 and 771 in Fig. 7B.
- the Merchant does not communicate directly with the TA. Instead, the Merchant transmits all of his transaction information through the Account Holder. The transmissions are not apparent to the user at the Account Holder's computer.
- the TA receives the transaction key directly from the second party, and in the second embodiment, the TA receives the transaction key indirectly through the first party. However, in both embodiments, the second party cannot complete the transaction without the transaction key.
- a feature of the system of the present invention is that an Account Holder does not have to use his machine or device that has the Account Holder client software installed. In the case where the Account Holder is using a "remote" computer or device that does not have the Account Holder client software installed, he may still request to use his account with the system as his method of payment.
- the transaction process for a purchase made from a remote terminal is shown in Fig. 8. Steps 510 and 530 from Fig. 5 are expanded to include substeps required for a remote transaction.
- the Account Holder is using a computer or other electronic device that is not his "home" computer, or any computer that does not have the Account Holder client software installed on it.
- the Account Holder visits the Merchant's Website on this remote computer and makes a purchase request, selecting the system of the present invention as the method of payment.
- the Merchant client software sends the Merchant ID and transaction information to the computer that sent the purchase request to the Merchant. If there is some type of communication failure, the computer will not respond. This could happen because the Account Holder is using a computer that does not have the client software installed, for example. Therefore at step 815, the client software on the Merchant system will not get a response, and will therefore proceed to step 817.
- the Merchant client software switches the Webpage on the Account Holder's remote computer to a remote transaction screen, and transmits the same transaction information as in step 813 to the TA's remote transaction site.
- the TA connects to the Account Holder's remote server site through a SSL connection, and at step 831 requests the user to verify the transaction and answer or ask one of the security questions that the Account Holder entered when the Account was set up. The user verifies the transaction by correctly answering or asking security questions at step 833.
- the TA transmits a credit approval request to the Issuing Bank for the Account Holder in question for the transaction amount.
- the Issuing Bank approves or disapproves the amount requested by transmitting an Issuing Bank approval code or disapproval code to the TA.
- the TA may also request the Account Holder to select one of his stored delivery address(es) or enter a new delivery address at this point.
- the TA can then send a transaction approval code to the Merchant along with the delivery instructions in step 871. Although not shown, the TA transmits a debit notice to the Issuing Bank. Upon receipt of the debit notice, the Issuing Bank debits the Account Holder's account and credits TA's master account. The Merchant's account at the Merchant Bank is then credited.
- the remote transaction site switches the Account Holder back to the Merchant's site where the Merchant confirms to the Account Holder that the transaction is complete and will be shipped.
- the TA transmits an e-mail to the Account Holder requesting confirmation that the Account Holder completed a remote transaction. Confirmation must be received from the Account Holder within 24 hours or the transaction will be cancelled.
- the Account Holder may e-mail the confirmation or may call a toll-free number and answer a security question to confirm the transaction.
- the system of the present invention can also handle offline transactions, such as one initiated from a telephone call.
- the transaction process for a purchase made from a telephone is shown in Fig. 9. Steps 510 and 530 from Fig. 5 are expanded to include substeps preferred for this type of transaction.
- the Account Holder tells a Merchant representative that the system of the present invention as the method of payment. This is typically done over the telephone, although it can be done in person at a Merchant's store.
- the Merchant transmits the Merchant ID, Transaction ID, customer name, UPCs, prices, purchase amount, and delivery instructions to the TA.
- the TA generates a unique off-line transaction ID for this transaction and transmits it to the Merchant at step 920.
- the Merchant phone or in-store representative informs the Account Holder of the off-line transaction ID and preferably a toll-free number to call to complete the transaction.
- the Account Holder preferably calls the toll-free number and enters the off-line transaction ID. Other types of communication by the Account Holder could also be considered.
- the TA pulls the transaction from its database and reads it to the Account Holder using voice generation technology.
- the Account Holder accepts or rejects the transaction at step 933. If accepted, then the TA prompts the Account Holder to randomly select from the Account Holder's stored security questions at step 935. These questions were set up when the Account Holder enrolled in the system of the present invention.
- the TA may then use text to voice conversion technology to determine whether the security questions are answered correctly.
- the TA transmits a credit approval request to the Issuing Bank for the Account Holder in question for the transaction amount.
- the Issuing Bank approves or disapproves the amount requested by transmitting an Issuing Bank approval code or disapproval code to the TA. If the Account Holder verified the transaction in steps 933 and 935, then the terms do "match" for purposes of step 550.
- the TA can then send a transaction approval code to the Merchant in step 971.
- the TA transmits a debit notice to the Issuing Bank. Upon receipt of the debit notice, the Issuing Bank debits the Account Holder's account and credits TA's master account. The Merchant's account at the Merchant Bank is then credited.
- the system of the present invention can also reduce fraud through its Order Confirmation and Delivery Service.
- the Account Holder may choose one of his previously stored delivery address(es) or enter a new delivery address. For example, in the first embodiment of the present invention shown in Figs 6A and 7A, this can be done as part of step 632 in data packet 732.
- This delivery information becomes part of the transaction information that is transmitted to the TA in step 633 as part of data packet 733.
- the delivery information is part of the information compared to determine whether the transaction is valid.
- Fig. 10 The information flow for the Order Confirmation and Delivery process is shown in Fig. 10.
- Merchant 290 sends a sale completed confirmation notice 790 to Account Holder 280 (as shown in Figs 7A and 7B)
- Merchant 290 transfers packaged goods to Shipper 260 with delivery instructions 1010.
- Shipper 260 then delivers the Shipper's package/shipping ID to Merchant through data packet 1020.
- the Merchant then sends the transaction ID along with the shipping ID and shipping date to TA 250 as data packet 1030.
- TA 250 periodically transmits its package watch list to Shipper 260 and indicates which ones must have signatures and from whom such signatures must be obtained if it is a delivery versus payment (DVP) shipment at data packet 1040.
- DVP shipments require picture identification, or some other type of physical authentication such as a fhumbprint, or other biometric data.
- Goods are delivered to Account Holder's 280 specified delivery address at 1050.
- the required signature or biometric sample, if any, is obtained following normal retry procedures.
- Account Holder 280 then accepts the delivery and signs if required at 1055.
- Shipper 260 transmits Package Change Statuses to TA 250 to confirm receipt of the goods in data packet 1060.
- TA 250 transmits Transaction ID and receipt status upon any change in status to Merchant 290 in data packet 1070.
- the Merchant's account is credited upon notice that the goods have been delivered and the authorized signature has been obtained, and TA 250 notifies Issuing Bank 210 to debit the Account Holder's account in data packet 1080.
- the system can also handle the transmission and downloading of purchased intellectual property items, such as music, news articles, and software.
- purchased intellectual property items such as music, news articles, and software.
- This use of a network linking buyers, sellers and a transaction administrator allows for the secure sales and delivery of intellectual property data items.
- the linkage between the purchase and usage of intellectual property provides better management of these assets, because the purchase and delivery is managed by the same system.
- the downloaded intellectual property goes to the Account Holder's computer that already has the Account Holder client software installed on it. Therefore the Account holder client software can track the delivery and usage of any such purchased and downloaded intellectual property.
- This link allows merchants to have a better understanding of who is actually downloading their intellectual property, whether the intellectual property is copied, and how many times it is copied or played.
- financial instruments such as online mutual funds can be purchased and delivered through the system of the present invention.
- the system can also handle person-to-person money wires and cash advances.
- the system can also securely deliver a password for an online service to an account holder.
- the system provides these types of electronic file and/or password delivery through a combination of public and private encryption keys.
- the Account Holder is the only party that ever receives the private portion of the encryption key from the TA.
- Merchants and other third parties may receive the public portion of the encryption key. This combination protects the downloaded files and/or password from theft and unauthorized use.
- the information flow for the online delivery process is shown in Fig. 11.
- the Account Holder 280 makes a purchase request from Merchant 290 for an intellectual property item that is capable of electronic delivery through data packet 1111.
- Merchant 290 transmits the Merchant ID, transaction ID, product description(s), price information, delivery information (including date, time and method) to the client software on the Account Holder's computer 280 in data packet 1112.
- the Account Holder client software 280 transmits the information received in packet 1112 plus the encrypted Account Holder's private ID located on the Account Holder's system to TA 250 in data packet 1113.
- TA 250 transmits an Issuing Bank approval request to Issuing Bank 210 for the amount of the purchase in data packet 1120.
- Issuing Bank 210 approves or disapproves the transaction through the Approval/Disapproval Code 1121. If the credit is approved, TA 250 transmits a transaction key, the Transaction ID and a private portion of the online delivery encryption key to the Account Holder's client software 280.
- Account Holder client software 280 transmits the transaction key and Transaction ID to Merchant 290 in data packet 1132.
- the private portion of the online delivery encryption key will be used to decrypt the file or information when it is electronically delivered. By using a private encryption key in this manner, the delivery of the purchased electronic goods or services is more secure.
- TA 250 matches the keys and associated information regarding delivery, etc. and sends a transaction approval code with the Transaction ID and the public portion of the online delivery encryption key to Merchant 290 in data packet 1170.
- Merchant 290 may then avail itself of the option to engage in a secure transaction for the intellectual property or password so that the information/product will be encrypted using the public half of the online delivery encryption key.
- Account Holder 280 executes an unpack command on the downloaded file or the downloaded file automatically executes an unpack
- the program will retrieve the private half of the encryption key from the Account Holder's client software by using the Transaction ID and transaction key. This private portion of the encryption key is then used to decrypt the downloaded file/password. Additionally, the unpack can set flags in the Account Holder client software for tracking the delivery and usage of the downloaded intellectual property.
- Account Holder client software 280 When Account Holder client software 280 completes decrypting the delivered file, it sends a completion code, Transaction ID and the public portion of the online delivery encryption key to TA 250 in data packet 1174. TA 250 sends a debit notice to Issuing Bank 210 in data packet 1180, and Issuing Bank 210 credits the TA master account. The Merchant's Account at the Merchant Bank or with the TA is then credited on the terms in accordance with the Merchant's agreement with the system.
- the system of the present invention may also be used for periodic payments. This feature may be used in sales of monthly ISP service or for an installment loan, for example. The information flow for a periodic payment purchase is shown in Fig. 12. Data packet 1132 is the same as for the embodiment shown in Fig.
- Fig. 12 illustrates the preferred steps that are taken each payment period for a purchase on a periodic basis.
- Merchant 290 transmits the transaction key, transaction ID, transaction information and periodic price to TA 250.
- TA 250 matches the keys and associated information regarding delivery , etc. and requests Issuing Bank approval for the periodic payment in data packet 1242.
- Issuing bank 210 approves or disapproves the amount requested and transmits an Issuing bank approval code 1244 to TA 250.
- Issuing Bank 210 will receive and approve such a request from TA 250 once every payment period.
- the full purchase price is approved only once.
- Issuing Bank 210 debits the Account Holder's account, and credits the Merchant's account with the Merchant Bank or with TA in data packet 1280.
- An important feature of the system of the present invention is the ability to easily "unwind" a transaction. In current systems, the return process is handled manually and is therefore quite expensive. It can cost as much as $25 or $30 to process the return of purchased goods, because every party to the transaction, including the buyer, the merchant and any associated financial institutions, must manually process the return transaction. With the growth of micro transactions on the Internet, this cost is unacceptable.
- the TA has all of the data for every transaction that is processed through it.
- every party to a transaction is electronically linked to the TA. Therefore, the TA can process an unwind transaction as easily as a regular purchase transaction.
- an Account Holder can return a product purchased through the system of the present invention by simply visiting the Merchant's Website to request a return number. The system then processes this new transaction by sending a request for pick-up to a Shipper participating in the system. The Account Holder gives the return goods to the
- the Merchant receives the return goods in due course.
- the TA clears the transaction, credits the Account Holder's account and debits the Merchant's account, as it tracks the delivery of the return goods. No other intervention by any party is needed.
- the system of the present invention can completely unwind a transaction with no external communication. Because the return goods were purchased through the system, the TA already has all of the information necessary for the unwind transaction
- An unwind may be handled by the system of the present invention as a regular transaction, where the Account Holder is the party that is delivering goods to the Merchant. It can be handled like a regular transaction with the parties reversed.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (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)
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA002390167A CA2390167A1 (en) | 1999-11-05 | 2000-11-06 | Payment method and system for online commerce |
AU15840/01A AU775065B2 (en) | 1999-11-05 | 2000-11-06 | Payment method and system for online commerce |
JP2001537199A JP2003514316A (en) | 1999-11-05 | 2000-11-06 | Payment method and system for online commerce |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US43451699A | 1999-11-05 | 1999-11-05 | |
US09/434,516 | 1999-11-05 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2001035570A1 true WO2001035570A1 (en) | 2001-05-17 |
Family
ID=23724542
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2000/030427 WO2001035570A1 (en) | 1999-11-05 | 2000-11-06 | Payment method and system for online commerce |
Country Status (4)
Country | Link |
---|---|
JP (1) | JP2003514316A (en) |
AU (1) | AU775065B2 (en) |
CA (1) | CA2390167A1 (en) |
WO (1) | WO2001035570A1 (en) |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1388991A2 (en) | 2002-08-08 | 2004-02-11 | Fujitsu Limited | Secure communications |
JPWO2004075081A1 (en) * | 2003-02-20 | 2006-06-01 | ソースジャパン株式会社 | Mobile/Internet commerce payment system |
EP1782255A2 (en) * | 2004-06-09 | 2007-05-09 | U.S. Bancorp Licensing Inc. | Transaction processing with core and distributor processor implementations |
US7349871B2 (en) * | 2002-08-08 | 2008-03-25 | Fujitsu Limited | Methods for purchasing of goods and services |
US7784684B2 (en) * | 2002-08-08 | 2010-08-31 | Fujitsu Limited | Wireless computer wallet for physical point of sale (POS) transactions |
US8069054B2 (en) | 2002-05-10 | 2011-11-29 | Syncada Llc | Automated transaction processing system and approach |
US8392285B2 (en) | 1996-11-12 | 2013-03-05 | Syncada Llc | Multi-supplier transaction and payment programmed processing approach with at least one supplier |
US8396811B1 (en) | 1999-02-26 | 2013-03-12 | Syncada Llc | Validation approach for auditing a vendor-based transaction |
US8589268B2 (en) | 1996-11-12 | 2013-11-19 | Syncada Llc | Financial institution-based transaction processing system and approach |
US8650119B2 (en) | 2004-06-09 | 2014-02-11 | Syncada Llc | Order-resource fulfillment and management system and approach |
EP2709050A1 (en) * | 2007-12-04 | 2014-03-19 | Accumulate Ab | A method for secure transactions |
US8712884B2 (en) | 2006-10-06 | 2014-04-29 | Syncada Llc | Transaction finance processing system and approach |
US8751337B2 (en) | 2008-01-25 | 2014-06-10 | Syncada Llc | Inventory-based payment processing system and approach |
US8762238B2 (en) | 2004-06-09 | 2014-06-24 | Syncada Llc | Recurring transaction processing system and approach |
CN104652125A (en) * | 2013-11-25 | 2015-05-27 | 3M创新有限公司 | Fabric structure and manufacturing method thereof |
US11651358B2 (en) | 2017-07-25 | 2023-05-16 | Mastercard International Incorporated | Method and system for transaction processing with complete cryptographic auditability |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7318050B1 (en) * | 2000-05-08 | 2008-01-08 | Verizon Corporate Services Group Inc. | Biometric certifying authorities |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4317957A (en) * | 1980-03-10 | 1982-03-02 | Marvin Sendrow | System for authenticating users and devices in on-line transaction networks |
US4755940A (en) * | 1983-09-17 | 1988-07-05 | International Business Machines Corporation | Transaction security system |
US5878143A (en) * | 1996-08-16 | 1999-03-02 | Net 1, Inc. | Secure transmission of sensitive information over a public/insecure communications medium |
US5910896A (en) * | 1996-11-12 | 1999-06-08 | Hahn-Carlson; Dean W. | Shipment transaction system and an arrangement thereof |
US6029150A (en) * | 1996-10-04 | 2000-02-22 | Certco, Llc | Payment and transactions in electronic commerce system |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6076078A (en) * | 1996-02-14 | 2000-06-13 | Carnegie Mellon University | Anonymous certified delivery |
-
2000
- 2000-11-06 JP JP2001537199A patent/JP2003514316A/en active Pending
- 2000-11-06 AU AU15840/01A patent/AU775065B2/en not_active Ceased
- 2000-11-06 WO PCT/US2000/030427 patent/WO2001035570A1/en active IP Right Grant
- 2000-11-06 CA CA002390167A patent/CA2390167A1/en not_active Abandoned
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4317957A (en) * | 1980-03-10 | 1982-03-02 | Marvin Sendrow | System for authenticating users and devices in on-line transaction networks |
US4755940A (en) * | 1983-09-17 | 1988-07-05 | International Business Machines Corporation | Transaction security system |
US5878143A (en) * | 1996-08-16 | 1999-03-02 | Net 1, Inc. | Secure transmission of sensitive information over a public/insecure communications medium |
US6029150A (en) * | 1996-10-04 | 2000-02-22 | Certco, Llc | Payment and transactions in electronic commerce system |
US5910896A (en) * | 1996-11-12 | 1999-06-08 | Hahn-Carlson; Dean W. | Shipment transaction system and an arrangement thereof |
Cited By (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8392285B2 (en) | 1996-11-12 | 2013-03-05 | Syncada Llc | Multi-supplier transaction and payment programmed processing approach with at least one supplier |
US8595099B2 (en) | 1996-11-12 | 2013-11-26 | Syncada Llc | Financial institution-based transaction processing system and approach |
US8589268B2 (en) | 1996-11-12 | 2013-11-19 | Syncada Llc | Financial institution-based transaction processing system and approach |
US8396811B1 (en) | 1999-02-26 | 2013-03-12 | Syncada Llc | Validation approach for auditing a vendor-based transaction |
US8069054B2 (en) | 2002-05-10 | 2011-11-29 | Syncada Llc | Automated transaction processing system and approach |
EP1388991A3 (en) * | 2002-08-08 | 2007-12-19 | Fujitsu Limited | Secure communications |
US7349871B2 (en) * | 2002-08-08 | 2008-03-25 | Fujitsu Limited | Methods for purchasing of goods and services |
US7353382B2 (en) | 2002-08-08 | 2008-04-01 | Fujitsu Limited | Security framework and protocol for universal pervasive transactions |
EP1388991A2 (en) | 2002-08-08 | 2004-02-11 | Fujitsu Limited | Secure communications |
US7784684B2 (en) * | 2002-08-08 | 2010-08-31 | Fujitsu Limited | Wireless computer wallet for physical point of sale (POS) transactions |
JPWO2004075081A1 (en) * | 2003-02-20 | 2006-06-01 | ソースジャパン株式会社 | Mobile/Internet commerce payment system |
EP1782259A4 (en) * | 2004-06-09 | 2009-04-22 | Us Bancorp Licensing Inc | Distributor-based transaction processing arrangement and approach |
EP1782255A4 (en) * | 2004-06-09 | 2009-04-29 | Us Bancorp Licensing Inc | Transaction processing with core and distributor processor implementations |
US8560439B2 (en) | 2004-06-09 | 2013-10-15 | Syncada Llc | Transaction processing with core and distributor processor implementations |
EP1782259A2 (en) * | 2004-06-09 | 2007-05-09 | U.S. Bancorp Licensing Inc. | Distributor-based transaction processing arrangement and approach |
EP1782255A2 (en) * | 2004-06-09 | 2007-05-09 | U.S. Bancorp Licensing Inc. | Transaction processing with core and distributor processor implementations |
US8650119B2 (en) | 2004-06-09 | 2014-02-11 | Syncada Llc | Order-resource fulfillment and management system and approach |
US8762238B2 (en) | 2004-06-09 | 2014-06-24 | Syncada Llc | Recurring transaction processing system and approach |
US8712884B2 (en) | 2006-10-06 | 2014-04-29 | Syncada Llc | Transaction finance processing system and approach |
EP2698754A3 (en) * | 2007-12-04 | 2014-03-19 | Accumulate Ab | A method for secure transactions |
EP2657896A3 (en) * | 2007-12-04 | 2014-03-19 | Accumulate Ab | Method for secure transactions |
EP2657895A3 (en) * | 2007-12-04 | 2014-03-19 | Accumulate Ab | A method for secure transactions |
EP2711884A1 (en) * | 2007-12-04 | 2014-03-26 | Accumulate Ab | A method for secure transactions |
EP2709049A1 (en) * | 2007-12-04 | 2014-03-19 | Accumulate Ab | A method for secure transactions |
EP2709050A1 (en) * | 2007-12-04 | 2014-03-19 | Accumulate Ab | A method for secure transactions |
US8751337B2 (en) | 2008-01-25 | 2014-06-10 | Syncada Llc | Inventory-based payment processing system and approach |
CN104652125A (en) * | 2013-11-25 | 2015-05-27 | 3M创新有限公司 | Fabric structure and manufacturing method thereof |
US11651358B2 (en) | 2017-07-25 | 2023-05-16 | Mastercard International Incorporated | Method and system for transaction processing with complete cryptographic auditability |
Also Published As
Publication number | Publication date |
---|---|
JP2003514316A (en) | 2003-04-15 |
AU775065B2 (en) | 2004-07-15 |
AU1584001A (en) | 2001-06-06 |
CA2390167A1 (en) | 2001-05-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6324526B1 (en) | System and method for performing secure credit card purchases | |
US7627531B2 (en) | System for facilitating a transaction | |
EP1264259B1 (en) | A network-based system | |
US8676694B2 (en) | Secure and efficient payment processing system | |
US5883810A (en) | Electronic online commerce card with transactionproxy number for online transactions | |
US20010051902A1 (en) | Method for performing secure internet transactions | |
US20010032878A1 (en) | Method and system for making anonymous electronic payments on the world wide web | |
US20050177437A1 (en) | E-commerce system | |
US20010025271A1 (en) | Commercial transaction system and method for protecting the security and privacy of buyers transacting business over a communication network | |
AU775065B2 (en) | Payment method and system for online commerce | |
WO2002029508A2 (en) | Broker-mediated online shopping system and method | |
EP1234223A2 (en) | System and method for secure electronic transactions | |
US20050015304A1 (en) | Secure purchasing over the internet | |
KR100623429B1 (en) | Transaction intermediate system and method of transacting using thereof | |
US20020123935A1 (en) | Secure commerce system and method | |
KR20060124375A (en) | Transaction system and method of authenticating users using thereof | |
KR20020064473A (en) | System and method for servicing electronic payment assurance integrated with electronic wallet | |
KR20010070545A (en) | Intermediate transaction method using payment guarantee check issued as collateral for deposit amount of buyer's real name verified financial account in e-commerce and reality | |
WO2002086650A2 (en) | A transaction facilitation system | |
WO2002043337A1 (en) | System and method for secured payment and settlement in network environment | |
AU2002255206A1 (en) | A transaction facilitation system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2390167 Country of ref document: CA Ref document number: PA/A/2002/004456 Country of ref document: MX |
|
ENP | Entry into the national phase |
Ref document number: 2001 537199 Country of ref document: JP Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 15840/01 Country of ref document: AU |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
122 | Ep: pct application non-entry in european phase | ||
WWG | Wipo information: grant in national office |
Ref document number: 15840/01 Country of ref document: AU |