EP1358609A4 - Procede et systeme servant a executer une transaction entre un client et un vendeur - Google Patents

Procede et systeme servant a executer une transaction entre un client et un vendeur

Info

Publication number
EP1358609A4
EP1358609A4 EP02714853A EP02714853A EP1358609A4 EP 1358609 A4 EP1358609 A4 EP 1358609A4 EP 02714853 A EP02714853 A EP 02714853A EP 02714853 A EP02714853 A EP 02714853A EP 1358609 A4 EP1358609 A4 EP 1358609A4
Authority
EP
European Patent Office
Prior art keywords
customer
transaction
merchant
authorization
credit
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.)
Ceased
Application number
EP02714853A
Other languages
German (de)
English (en)
Other versions
EP1358609A2 (fr
Inventor
Vincent W Talbert
Thomas H Keithly
Daniel A Hirschfeld
Mark L Lavelle
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.)
Bill Me Later Inc
Original Assignee
I4 Commerce Inc
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
Application filed by I4 Commerce Inc filed Critical I4 Commerce Inc
Publication of EP1358609A2 publication Critical patent/EP1358609A2/fr
Publication of EP1358609A4 publication Critical patent/EP1358609A4/fr
Ceased legal-status Critical Current

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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • 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
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks

Definitions

  • the present invention relates generally to transaction systems, and in particular, to a method and system for completing a transaction between a customer and at least one merchant.
  • Remote purchases are defined as those purchases where the buyer and the seller (the merchant) are not physically proximate during the transaction. Specific examples of remote purchases are mail order, telephone order, Internet and wireless purchases.
  • the account number is used as a public credential along with expiration dates and very limited address information.
  • a public credential is defined as a transaction-enabling form of identification that accesses financial balances or credit lines or credit in order to complete a purchase of goods or services.
  • account numbers are the primary enablers of access to purchase. The fact that the account number is the key to credit causes the user to focus on creating counterfeit numbers and stealing valid numbers via a variety of methods.
  • the current industry standard process for authorizing a purchase for a credit or charge card customer provides inadequate authentication to protect merchants and consumers from external cost to the remote purchase transaction.
  • the process instead, focuses only on whether the account in use is open and in good standing and whether there exists adequate credit available to fund the purchase.
  • Fraud detection routines in use are typically statistically-based pattern recognition algorithms, but are not capable of authenticating a customer.
  • the current standard authorization message formats do not support the transmission of vital authentication information from the merchant to the issuer of the credit or charge card.
  • Some products do employ a very limited verification key built on portions of the customer's name and address, but the keys in use are not adequate to create a high level of transactional security.
  • the public key e.g., a credit card number
  • the present invention is directed to a method and system for completing a transaction between a customer and at least one merchant, including the steps of: (a) initiating a transaction by the customer with the merchant; (b) communicating an authorization request including customer data and transaction specific data by the merchant to a transaction system; (c) authenticating the customer by the transaction system; (d) authorizing the transaction by the transaction system; (e) communicating the authorization response by the transaction system to the merchant; and (f) completing the transaction between the merchant and the customer.
  • the present invention is also directed to a system and apparatus for implementing the above-described method.
  • FIG. 1 is a schematic view of a transaction system according to the prior art
  • FIG. 2 is a schematic view of a first embodiment of a method and system for completing a transaction between a customer and a merchant according to the present invention
  • FIG. 3 is a schematic view of a credit/authorization process flow according to the present invention.
  • FIG. 4 is a schematic view of another embodiment of a method and system for completing a transaction between a new customer and a merchant according to the present invention
  • FIG. 5 is a schematic view of a further embodiment of a method and system for completing a transaction between an existing customer and a merchant according
  • Fig. 6a is a flow diagram of an application and first purchasing authority decision process according to the present invention.
  • Fig. 6b is a flow diagram of a purchasing authority limit increase
  • Fig. 7 is a flow diagram of an application presentation process according to the present invention.
  • wireless purchases such as Internet, telephone, e-mail and wireless device purchases
  • a customer 10 credit card This process is illustrated in Fig. 1.
  • the customer 10 in order to receive a credit card, the customer 10 must receive a credit card application from a bank 12. These applications are distributed by the bank 12 through various channels, such as direct mail, "take-ones" and phone calls.
  • the customer 10 completes the application and returns it to the bank 12.
  • the bank 12 then enters the application data into a bank decision engine 14, which, in turn, requests a credit report from a third-party credit system 16 on the customer 10.
  • the third-party credit system 16 returns the credit data and a score for the customer 10.
  • the bank decision engine 14 uses the credit data and the application data to determine if the customer 10 is qualified for the credit card. The bank decision engine 14 then returns the credit decision to the bank 12. If approved, the bank 12 sets up an account for the customer 10 on the bank billing and servicing platform 18. Finally, the bank billing and servicing platform 18 mails the credit cards to the customer 10.
  • the customer 10 visits a merchant 20 to select the goods or services, enters the checkout process and inputs the credit card number and expiration date for payment.
  • the merchant 20 captures the customer credit card account number and submits it with the transaction details as an authorization request to a payment processor 22.
  • the payment processor 22 submits the authorization request to the payment network 24, which then passes the authorization request to the bank billing and servicing platform 18.
  • the bank billing and servicing platform 18 checks to see if there is available credit in the account and returns an authorization response to the payment network 24.
  • the payment network 24 passes the authorization response to the payment processor 22, who then passes the authorization response to the merchant 20.
  • the merchant 20 ships the goods or performs the services to or for the customer 10.
  • the merchant 20 sends the payment processor 22 a settlement/deposit request.
  • the payment processor 22 sends the payment network 24 this request, and the payment network 24 sends this request to the bank billing and servicing platform 18.
  • the bank 12 posts settlement to a transaction database.
  • the bank 12 remits settlement through the payment network 24, and the settlement record is sent and deposit is made to the payment network 24.
  • the payment network 24 sends the settlement record and makes a deposit to the payment processor 22.
  • the payment processor 22 sends the settlement record and makes the deposit to the merchant 20.
  • the above-described prior art system is particularly susceptible to fraud, resulting from the theft of the customer account number. Further, the prior art system lacks adequate customer authentication and does not enforce a positive authentication of the customer 10 at the time of a purchase request. For example, the credit card issuer receives the account number, expiration date and limited numeric/address fields in order to verify the identity of the purchaser. As long as the numeric/address information matches, the expiration date is valid, credit is sufficient and the account is in good standing, the sale is approved. Clearly, such a process is far from secure and has resulted in a considerable amount of fraud.
  • the present invention is directed to a method and system for completing a transaction, namely a purchase transaction, between the customer 10 and a merchant 20, and preferably, many different merchants 20.
  • the present invention integrates and efficiently manages the overall authorization and transactional process, and excludes the need for interaction with the bank 12, obtaining a credit card, and further eliminates, or drastically reduces, consumer fraud.
  • the term "credit” is meant to include traditional credit, purchasing authority, alternative payment processes and other similar processes.
  • the present invention is a computer-implemented method for completing a transaction between the customer 10 and the merchant 20 and includes the steps of: (a) initiating a transaction by the customer 10 with the merchant 20; (b) communicating an authorization request, including customer data and transaction specific data, by the merchant 20 to a transaction system 26; (c) authenticating the customer 10 by the transaction system 26; (d) authorizing the transaction by the transaction system 26; (e) communicating the authorization response by the transaction system 26 to the merchant 20; and (f) completing the transaction between the merchant 20 and the customer 10.
  • This process occurs each time the customer 10 interacts with the same merchant 20, or other merchants 20 that are approved by the transaction system 26.
  • this transaction system 26 provides both the merchant 20 and the customer 10 with a secured transaction and obviates the need for the customer 10 acquisition of a credit card from a bank 12.
  • the above-described computer-implemented method may be implemented on a computer, personal digital assistant, telephone, cell phone or other intelligent device.
  • the merchant 20 may have a web site on the Internet, through which the customer 10 desires to purchase goods or services.
  • the merchant 20 web site may be a secured merchant system, such as a system that requires a log-in sequence.
  • the transaction becomes more secure, in that an authorized user, or a user who wishes to perpetrate fraud, must first acquire the user name and password of the customer 10 in order to first enter the merchant 20 secured merchant system.
  • the customer 10 initiates the transaction with the merchant 20.
  • the merchant 20 communicates an authorization request to the transaction system 26.
  • the merchant 20 must collect and transmit an expanded data set or complete customer profile to the transaction system 26.
  • the merchant 20 may collect and transmit the information or data fields listed in Table 1 (as defined in Table 2) to the transaction system 26. This one-time application process is required in order to establish a customer account on the transaction system 26.
  • Transaction ID A unique sequential number assigned by the merchant to each transaction sent in order to track and match-off corresponding responses.
  • Account Number The unique 16-digit number assigned to these customers. For new customers this number is determined by transaction system and passed to the merchant in the authentication response (Auth-E response). For subsequent transactions, this number is supplied to transaction system by the merchant in the Authentication Request Transaction (Auth-E request).
  • Bill-to Street The street number of the customer's bill-to address.
  • Number Bill-to Street Name The street name of the customer's bill-to address.
  • Bill-to Apartment The customer's bill-to apartment number, if applicable. Number
  • Bill-to City The bill-to city of the customer.
  • Bill-to State The bill-to state of the customer.
  • Bill-to ZIP code The bill-to ZIP code for the customer.
  • T&C Version A unique identifier for the terms and conditions served to the customer for this transaction.
  • the promotional code identifier for this transaction, if applicable. This Code code is given to the merchant to support payment of co-marketing obligations (free shipping for example).
  • Merchant Fraud A fraud index provided by the merchant.
  • the merchant defines the Index format and values for this data element.
  • Customer Type A flag that identifies the customer as new or existing with the Flag merchant The definition of existing is - a customer who has completed at least one prior purchase with the merchant with no subsequent financial loss for the transaction
  • Item Category A numeric identifier for the category of item being purchased from the merchant. For multiple item purchases, the value is determined by the highest priced item in the shopping cart.
  • the category codes are provided by transaction system.
  • Savings Account Optional, reserved for future use, a yes/no flag indicating whether the customer has a savings account. Not used at the current time.
  • the authorization request along with the expanded data set, is sent to a payment processor subsystem 28, which is responsible for collecting, formatting and transmitting the appropriate information to a central control/authorization subsystem 30.
  • a payment processor subsystem 28 which is responsible for collecting, formatting and transmitting the appropriate information to a central control/authorization subsystem 30.
  • Both the payment processor subsystem 28 and the central control/authorization subsystem 30 are part of the transaction system 26.
  • the central control/authorization subsystem 30 transmits this customer profile, in the form of an application, to the credit authorization subsystem 32, which is also part of the transaction system 26.
  • the central control/authorization subsystem 30 is managed and/or operated by a third party.
  • the credit authorization subsystem 32 is configured to make decisions regarding the credit- worthiness of the customer 10 (or applicant), and also establishes a maximum credit quantity. After the credit authorization subsystem 32 has reached a decision, an authorization response for the customer 10, as well as the transaction requested, is communicated to the central control/authorization subsystem 30. It is also envisioned that the credit authorization subsystem 32 can transmit the customer data to a third-party credit system 34. This third-party credit system 34 performs a credit check of the customer 10 and communicates an authorization response back to the credit authorization subsystem 32 of the transaction system 26.
  • the credit authorization subsystem 32 is configured to be able to determine the credit- worthiness of the customer 10 without any outside consultation, for a new and unapproved customer, it is often desirable to seek the recommendation of the outside third-party credit system 34. Further, the third-party credit system 34 may consult with and receive information from a credit bureau or other third-party credit and customer databases. The authorization response from the third-party credit system 34 may include a customer credit score, and the credit authorization subsystem 32 may establish a maximum credit amount based upon this customer credit score.
  • a customer account is established on the transaction system 26.
  • the transaction system 26 creates a customer-specific authorization key, which may be based or at least partially derived from the customer data submitted by the merchant 20.
  • the authorization key may be identical to the customer account number.
  • this authorization key is made up of digits, letters, and/or symbolic characters. While it is envisioned that this authorization key is customer specific and is able to be used among multiple merchants 20, it is also possible that the customer 10 is assigned multiple authorization keys (typically, the customer account number remains the same). The reason for using multiple authorization keys is the ability to have a customer-specific authorization key for different merchants 20. This would allow the transaction system 26 to allow merchant-specific functionality as to the same customer 10. In order to provide even more security, the authorization key may be encrypted prior to any communication to the merchant 20.
  • the customer account is established by and tracked on an accounting subsystem 36, which is also part of the overall transaction system 26. While this accounting subsystem 36 may be part of the transaction system 26, it is also envisioned that a third-party accounting system 38 be utilized. Using a third-party accounting system 38 allows the transaction system 26 to avoid creating its own accounting subsystem 36 and associated infrastructure. Either the accounting subsystem 36 or the third-party accounting system 38 establishes a customer accounting database in order to track the customer 10 transactions and update the customer account on the customer accounting database.
  • the central control/authorization subsystem 30 transmits the authorization response either directly to the merchant 20 or through the payment processor subsystem 28 to the merchant 20.
  • the authorization key is also sent to the merchant 20, thus allowing the repeat customer 10 to initiate a second or subsequent transaction with the merchant 20, who transmits the authorization key to the transaction system 26. This then avoids the need for the merchant 20 to transmit the lengthy data set, and instead, to merely transmit the authorization key and the transaction specific data to the transaction system 26.
  • the merchant completes the transaction by transmitting an acknowledgement to the customer 10 or shipping the goods to the customer 10. If the customer 10 has ordered a service, as opposed to a good, the merchant 20 may then confirm service dates, costs and other pertinent information.
  • the authorization response may include the information or data fields listed in Table 3 (as defined in Table 4).
  • Merchant ID A unique numeric identifier assigned to each merchant. This identifier allows for control of all merchant-specific processing.
  • Transaction ID A unique number assigned by the merchant to each transaction sent in order to track and match-off corresponding responses.
  • Control Code A numeric code provided by transaction system for all approvals. This code can be retained and passed through to transaction system in the settlement record(s) associated with this authorization, no other authorization is necessary.
  • the merchant 20 may present the present invention as a payment option to the customer 10 using basic presentation rules. For example, the customer 10 may be presented with a maximum purchase amount eligible, or other such information. Also, it may be preferable for new applicants, who are not verified or known by the merchant 20, to match the ship-to address with the bill-to address. The merchant 20 also maintains an accurate list of pre-approved customers 10, if such a pre-approved program is in place with the merchant 20.
  • the payment processor subsystem 28 may also be substituted with a third-party payment processor system 40.
  • the benefit of using a third-party payment processor system 40 is its existing infrastructure and its ability to be a merchant aggregator.
  • the third-party payment processor system 40 may take care of the formatting of authorization requests, formatting of customer data, and even may act as a marketer of the transaction system 26. Also, such a design would allow the third-party payment processor system 40 to carry all the merchant credit risk, while the present invention would carry the consumer credit risk.
  • the accounting subsystem 36 of the transaction system 26 may also be replaced by the third-party accounting system 38.
  • the third-party accounting system 38 would be responsible for the creation and maintenance of the customer accounts; customer service and collections on-line systems; statement rendering; initiates settlement; remittance processing for customer payments on accounts; application of appropriate pricing per terms and conditions; credit bureau reporting for all existing customers; and real-time account balance and status rendering for authorization processing.
  • the accounting subsystem 36 may be internal to the transaction system 26, the use of a third-party accounting system 38 is preferable for managing customer account information and for customer account maintenance.
  • the third-party credit system 34 provides additional functionality, such as credit bureau agency or other credit database selection; credit report retrieval; credit report summarization; credit criteria application; verification queue assignment; decision review queue assignment; and decline letter rendition. Further, the third-party credit system 34 may manage the application of pre-approval criteria to potential customers 10 for any pre-approved programs implemented.
  • Fig. 3 illustrates the credit authorization process flow for both new and existing customers.
  • This embodiment uses a third-party payment processor system 40, a third-party accounting system 38 and a third-party credit system 34.
  • the merchant 20 transmits an authorization request to the third-party payment processor 40.
  • the customer data transmitted to the third-party payment processor system 40 would be the authorization key, which is now a privately-held credential between the merchant 20 and the transaction system 26.
  • the third-party processor system 40 sends the customer data, authorization key (if available) and the transaction specific data to the transaction system 26.
  • the transaction system 26 interacts with the third-party credit system 34 via the credit authorization subsystem 32, and authorizes, approves and establishes a new customer account.
  • a customer-specific file history database is maintained on either the accounting subsystem 36 or the third-party accounting system 38, and, for each subsequent transaction, a customer history is built for each customer account on this database.
  • the transaction system 26 analyzes the customer history in the customer-specific file history database and, may also send a status request to the third-party accounting system (if used) in order to allow this third-party accounting system 38 to conduct this analysis.
  • the third-party accounting system 38 then returns a status response to the transaction system 26, either approving or disapproving the subsequent transaction. If the analyzed customer history indicates that the customer 10 meets the set criteria for rejection of the transaction, the transaction system 26 communicates a declination or rejection to the customer 10, preferably via the payment processing subsystem 28 and the merchant 20.
  • the transaction system 26 transmits its authorization response to the third-party processor system 40, who in turn, transmits this authorization to the merchant 20.
  • the merchant 20 completes the transaction with the customer 10, as described above. It is envisioned that, in some instances, the merchant 20 will not transmit the customer-specific authorization key to the transaction system 26, but instead, will send a limited customer data set. This limited customer data set contains enough customer data to allow the transaction system 26 to analyze the customer data and match the pre-established customer-specific authorization key with the customer 10. This also may occur when only one authorization key is used for the customer 10. For example, if the same customer 10 attempts to initiate a transaction at a different merchant 20, that different merchant may or may not have access to the authorization key of that customer 10.
  • the merchant 20 would send either the limited or full and expanded customer data set to the transaction system 26, and the transaction system 26 would then match the customer 10 with the customer-specific transaction key. This allows the transaction system 26 to determine whether a new customer account should be established, or whether the customer 10 is a pre-existing customer 10 and aheady has an account on the transaction system 26.
  • the transaction system 26 may generate a customer-specific user identification and password for the customer account on the transaction system 26. When the account is established, the transaction system 26 sends this user identification and password directly to the customer 10. In order to allow a customer 10 to maintain his or her account, the transaction system 26 may also include a user interface, which is accessible by the user having the valid user identification and password. In operation, the customer 10 accesses the user interface on the transaction system 26 using the user identification and password, and the transaction system 26 then presents to the customer 10 certain account maintenance options.
  • the account maintenance options may include allowing the customer 10 to view his or her account status, view a transactional history of the account, settle a transaction on the account, complete a registration process, initiate chargeback transactions and view account history.
  • the transaction system 26 retrieves this customer account data from the third-party accounting system 38.
  • the customer accounting database or the customer-specific file history database track the transactions of the customer 10. These databases may be discrete, linked or combined as one overall customer database.
  • the transaction system 26 is configured to post new customer accounts, post monetary transactions, post non-monetary transactions and generate customer-specific statements.
  • the transaction system 26 must communicate the customer data, the transaction specific data and, preferably, the authorization key, to the third-party accounting system 38, where the third-party accounting system 38 performs these functions.
  • the authorization key is the private credential between the merchant 20 and the transaction system 26, it is preferably not transmitted to the customer 10. However, it may be transmitted to the merchant 20, the third-party payment processor system 40, the third-party credit system 34 and/or the third-party accounting system 38. However, since all of these systems are secure, the ultimate goal of fraud reduction is achieved.
  • the credit authorization process is typically used for new customers that are not pre-approved, it is also envisioned that the credit authorization subsystem 32, with or without the third-party credit system 34, could be used periodically for repeat customers 10. For example, in some instances, it may be useful to perform a credit evaluation of a customer 10 on an annual basis or when the customer 10 desires increased credit. This periodic credit checking is invisible to the customer 10, and therefore, poses no negative inferences to the customer 10.
  • One of the benefits of the present invention is the ability for the central control authorization subsystem 30, the accounting subsystem 36 and/or the third- party accounting system 38 to aggregate multiple transactions with multiple merchants 20 in a single statement.
  • the statement may then be transmitted to the customer 10 on a periodic basis for payment.
  • reconciliation, maintenance and presentation may occur on the transaction system 26.
  • the transaction system 26 allows credit purchases, account maintenance and merchant aggregation at a reduced risk of fraud.
  • a settlement/deposit request is sent by the merchant 20 to the payment processor 28 or third-party payment processor system 40, and this request is then sent to the transaction system 26.
  • the account is settled on the transaction system 26, particularly the accounting subsystem 36, and a settlement record is transmitted by the transaction system 26 to the payment processor subsystem 28 or the third-party payment processor system 40.
  • the settlement/deposit request must be sent to this system as well.
  • the settlement amount is deposited with the payment processor subsystem 28 or the third-party payment processor system 40, and, finally, the settlement record is transmitted to the merchant 20.
  • the transaction system 26 includes the payment processor subsystem 28 and the accounting subsystem 36, the settlement may be posted directly between the merchant 20 and the transaction system 26.
  • a merchant 20 must be approved by the transaction system 26 prior to the extension of credit to any of the merchant's customers 10. Therefore, a merchant profile may also be communicated from the merchant 20 to the transaction system 26. This merchant profile is used by the transaction system 26 to verify the format of the authorization transaction; retrieve the list of required application data elements; verify that the proper terms and conditions were presented to the customer 10; validate any promotional offers made by the merchant 20; and retrieve internal processing parameters used to correctly route the transaction through the transaction system 26. If however, a transaction is completed between a customer 10 and a merchant 20 without authorization from the transaction system 26 within a predetermined period of time, this transaction is deemed "out of compliance.” For such "out of compliance" transactions, a chargeback adjustment process is used to initiate a chargeback.
  • Such authorizations may be collected on an authorization or other database on the transaction system 26. If such a database is utilized, the transaction specific data for each transaction is entered onto the database. As discussed above, this authorization database may be discrete, linked, or combined with the other databases on the transaction system 26.
  • Another benefit of the present invention is its optional notification process. In order to decrease fraud, each subsequent transaction (or other variable frequency) initiated by the customer 10 may initiate a notification from the transaction system 26 to the customer 10. If an unauthorized consumer is somehow able to initiate a transaction on the transaction system 26, the rightful customer 10 will quickly know that there has been activity on his or her account. If this occurs, the customer 10 may then take the necessary steps to correct the unauthorized transaction. This notice function could be optionally triggered on every account transaction, transactions over a specific monetary amount, or other similar criteria.
  • Fig. 4 illustrates another embodiment of the present invention when a transaction is initiated between a new customer 10 and a merchant 20.
  • the customer 10 enters the checkout process at the merchant 20 and requests the present invention as the preferred method of billing.
  • the merchant 20 may offer the present invention to all customers 10, to their existing best customers 10, to customers 10 who have been pre-qualified for its use, or may use some other targeting approach agreed upon with the transaction system 26.
  • the merchant 20 may present promotional banners or can offer the present invention with other payment options.
  • the merchant 20 transmits an authorization request message to a third-party payment processor system 40.
  • This message includes the customer identification, credit qualification information, and transaction validation information.
  • the third-party payment process system 40 will validate the message and format it into standard authorized format and forward the transaction information to the transaction system 26.
  • the authorization process will validate the transactional data against the required format and content.
  • the transaction system 26 will check the customer's identification information, such as mailing address, shipping address, and computer IP address against a negative database file to determine if there is any derogatory history. If the consumer or customer 10 is declined due to negative file checks, the transaction system 26 will send an automated message to the credit authorization subsystem 32 or third-party credit system 34 in order to generate a decline letter to the customer 10.
  • the transaction system then creates a match key or authorization key based upon the customer identification and verifies that the new customer 10 is not an existing customer 10. This situation may occur if the customer 10 uses a different merchant 20.
  • the transaction system 26, using the credit authorization subsystem 32 will send the third-party credit system 34 a request for approval.
  • the transaction system 26 will use a local database to match the customer's pre- approval number against existing credit information.
  • the transaction system 26 has the logic to complete the credit decision internally. However, it is envisioned that all pre-approval credit decline letters could be generated by the third-party credit system.
  • the credit authorization subsystem 32 will check a "hash" table to see if the customer 10 had already been recently decisioned. If the customer 10 has not been recently decisioned, the decision engine will request a credit report from the third- party credit system 34 or an outside credit bureau. The credit authorization subsystem 32 will apply credit scoring criteria and will yield a decision.
  • the transaction system 26 When a credit decision is reached and sent back to the transaction system 26 or to the central control/authorization subsystem 30 of the transaction system 26, the transaction system 26 will generate a customer account number. For approved customers 10, the transaction system 26 will also generate a self-service site initial user identification and password, which is then e-mailed to the customer 10. The customer 10 will be able to click on a link in the e-mail to log in to the self-service site and complete the registration process. [0055] For approved customers, the transaction system 26 builds the customer profile in the local operational data store. An authorization approval code is generated, namely the authorization key, and the purchase transaction is recorded in an authorization or other database such as a customer account or customer-specific file history database.
  • a message is sent to the third-party accounting system 38 to build the new account.
  • the new account record typically includes the name, address, credit score, promotional code, source merchant code, credit segment, and terms and conditions version.
  • An entry is then posted on the new account describing the authorized transaction, including the merchant, amount, date, etc.
  • the authorization response message is sent back to the third-party payment processor system 40 and on to the merchant 20.
  • the merchant 20 updates the customer profile with the customer account number or authorization key.
  • the merchant 20 sends the sales transaction to the third-party payment processor system 40 when the order is fulfilled.
  • the third-party payment processor system 40 reformats the transaction into a standard format and sends the transaction to the third-party accounting system 38.
  • the third-party accounting system 38 edits and validates the file into dollar totals, which are communicated back to the third-payment processor system 40 for verification.
  • the third-party accounting system 38 performs a nightly batch (or possibly real-time) process update cycle that posts new accounts, monetary transactions, non- monetary transactions and also produces statements.
  • this third-party accounting system 38 transmits a daily ACH transaction (or wire transfer) via the Federal Reserve network to the third-party payment processing system 40. Separate ACH deposits are made for sales, discounts and adjustments.
  • the third-party payment processor system 40 will calculate the discount and make payment to the merchants 20 for their net sales.
  • the third- party accounting system 38 transmits the daily settlement reports to the third-party payment processor system 40, who uses the reports to reconcile the ACH deposits.
  • the third- party accounting system 38 transmits the daily posted monetary detail files to the transaction system 26.
  • the transaction system 26 performs daily settlement match processes.
  • the settlement match process matches the settlement transactions to the databases, and if a sale has been posted without a corresponding authorization with allowable time frames, the item is flagged as "out of compliance.”
  • the authorization or corresponding database on the transaction system 26 is processed to "age off authorization records and to query the status of "out of compliance” items. If an "out of compliance" item was posted to an account that has gone into a derogatory status, a chargeback adjustment for that item is generated. The chargeback adjustments are sent to the third-party accounting system 38 for posting.
  • FIG. 5 yet another embodiment is illustrated for use in the present invention with an existing customer.
  • the customer 10 enters the checkout process with the merchant 20 and requests the present invention as the billing option.
  • the merchant 20 transmits the authorization request message to the third-party payment processor system 40, and this message includes the authorization key, and transaction specific data, and possibly credit qualification information and other customer information.
  • the transaction system 26 receives the authorization request and authenticates the merchant's required formatting content.
  • the authorization process will validate the transaction-required format and content. It will check the customer's identification information, such as the IP address, mailing address, date of birth, name, shipping address, authorization key, etc., against a negative database file to determine if there is any derogatory history. Next, the authorization key is used to retrieve the customer's profile. The transaction system 26 then sends either a batch or real-time request to the third-party accounting system 38 for the account balance and status. If the third-party accounting system 38 is unavailable, the transaction system 26 will use the previously retrieved balance and status information to complete the authorization decision. This authorization process uses the customer profile, the customer balance and status and the transaction specific details to determine whether to approve the transaction.
  • the transaction is approved, an authorization response number is generated, and the transaction details are posted to the authorization or other database. Further, if the transaction is approved, an advice of authorization is placed on the third-party accounting system 38 and if the transaction is declined, a declination detail forewarning is placed on the third-party accounting system 38.
  • the authorization is sent back to the third- party payment processor system 40, and on to the merchant 20. If approved, the merchant 20 sends the sales transaction to the third-party payment processor system 40 when the order is fulfilled and third-party payment processor system 40 reformats the transaction and sends it to the third-party accounting system 38, who edits and validates the file and communicates the dollar total back to the third-party payment processing system 40 for verification.
  • the third-party accounting system 38 performs daily operations and communicates with both the third-party payment processor system 40 as well as the transaction system 26. The process flow continues as described with the above embodiment.
  • Figs. 6a and 6b illustrate a first credit decision process and the credit limit increase process.
  • the transaction dollar amount must first be analyzed. If the purchase amount is between $1 and $100, the transaction system 26 determines the customer 10 country of origin. In this embodiment, if the customer 10 is from Canada, an identification, phone, address, and fraud check is performed prior to approval. If the customer 10 originates in the United States, an address match, and credit decision occur. For a first purchase of between $101 and $499, a more advanced credit decision and checking process is utilized as performed by the credit authorization subsystem 32 and/or the third-party credit system 34. Finally, for purchases of over $500, a full credit decision is reached using the credit authorization subsystem 32, the third-party credit system 34 and/or an outside credit bureau.
  • an over-limit process is initiated, which evaluates the time the account was opened, the number of months of activity, the payment history of the customer 10, the amount of the purchase, and the percent over the limit. This subsequent purchase is then approved or may require a new credit decision. If the new outstanding balance is between $1 and $100 and the account status is good, the subsequent purchase is approved. If the new outstanding balance is between $101 and $499, depending upon the country of origin, a credit authorization process is again undertaken prior to approval.
  • the credit process may be based on the customer 10 revolving debt level and the age of the oldest file update at the credit bureau. Building revolving balances more quickly tends to move an applicant toward the low credit line strategy.
  • the process is used to assign customers with no credit bureau history, customers with no prior delinquency and customers with a prior delinquency to different credit groups.
  • approved customers 10 may also be manually checked against telephone directory databases for the validity of the name/phone number and address combination. Verification failures may result if the errors are serious.
  • the credit authorization process is similar to the process that is engaged in by the bank 12 or the bank decision engine 14, along with the credit bureaus or third-party credit system 34.
  • the customer 10 does not receive a credit card, but instead only receives approval for the transaction.
  • the authorization key is held as the private credential by the merchant 20 and the transaction system 26. It is envisioned that any means for verifying and correctly identifying the customer 10 may be utilized.
  • Fig. 7 illustrates the decision process for determining what information should be provided by the customer 10. If the customer 10 has successfully used the present invention at the merchant 20, minimal information is required for subsequent purchases. If the customer 10 has made a transaction before using a merchant's log-in sequence, the system may determine and match the bill-to and ship-to addresses. If these addresses do not match but the transaction is less than $500, minimal customer information may be required. However, if the transaction is greater than $500, the expanded data set of information would be required. This similar decision process may be used if the bill-to and ship-to addresses are the same. Also important in the process is whether the customer 10 has a chargeback or other non-payment on the account. Such negative file history may result in denying the transaction.
  • the present invention is an efficient process, and a typical data exchange will involve an encrypted XML message sent over the Internet using SOAP protocol over HTTPS.
  • the present invention may also offer frame relay or other high-speed and direct means of communication.
  • Response time for new customers 10 is expected to be sub-10 seconds.
  • Existing customer authorization is expected to be in the 3 to 5 second range. Of course, these estimates are somewhat dependent on the communication protocol chosen and whether the merchant 20 operates in different modes within the transaction system 26.
  • authorization messages between the transaction system and other systems will preferably adhere to the ISO 8583 format.
  • the preferred communication technology uses IP protocols over a Virtual Private Network (VPN) connection or a direct free relay or other high-speed, direct communication method.
  • VPN Virtual Private Network
  • the present invention offers considerable functionality.
  • the merchant 20 may display commercial banners, may participate in the pre-approval process, may offer the present invention payment option to all or targeted customers, may request authorizations, submit transactions, maintain customer profiles and resolve purchasing disputes directly with the customer 10.
  • the user-accessible interface of the transaction system 26 may be a self-service web site allowing the customer 10 to conveniently and accurately perform direct account inquiries and maintenance. For example, the customer 10 may view their current account balance, payment information, and last three months' transactions. Further, the customer 10 may update their address and other profile information.
  • a secure e-mail system is available directly from the site to customers 10.
  • the transaction system 26 may use a correspondence operation function to perform customer care for customers 10 who submit inquiries or requests via postal mail.
  • All customer service functions can be performed within a correspondence group, and responses to customers may be made via e-mail or postal mail. Retrievals, exception payments, returned mail, and microfilm conversion may also be provided. All policies covering procedures and letter or e-mail text are developed and monitored by the transaction system 26.
  • a voice response system may be used to provide a 24-hour automated information and service to customers 10 using the telephones.
  • the voice response units may provide balance and payment information and may temporarily block an account if the customer 10 suspects their account has been compromised.
  • Real-time live agents may also be used.
  • Customer security features may be provided for the detection of fraud patterns and to make outbound contacts. Further, such functionality may investigate fraud reports. Collections functionality may be provided to handle inbound and outbound contacts from delinquent customers 10 and to apply a variety of strategies to collect payments. Further, a lending facility may be used to provide and conduct lending and receivables funding.
  • the present invention is a method and system for completing a transaction between a customer 10 and a merchant 20 which integrates new customer underwriting and account setup processes into the established credit card transaction authorization process.
  • the present invention provides for using the customer data, such as the customer's name, address, phone number, date of birth and social security number to uniquely identify the customer account using an authorization key. Further, the present invention allows for the aggregation of multiple transactions for multiple merchants from the same customer onto one bill, which can be presented to the customer 10 in paper or electronic form.
  • the present invention allows for the dynamic presentment of this payment option based on the transaction and customer information.
  • the method and system provides for distributed authentication, whereby the existing merchant log-in credentials are used to authenticate the customer 10 prior to the use of the present invention payment option.
  • the present invention provides for single authorization split shipments, where a single authorization is used to approve a basket of goods when the goods are delivered in multiple shipments and results in multiple settlement transactions.
  • the present method and system reduces the chance of theft and fraudulent use of account numbers by replacing the typical credit card account number with a private authorization key. This enforces a positive authentication of the customer 10 at the time of transaction initiation.
  • the present invention redesigns the standard authorization process into an expanded authentication process using an expanded set of customer information.
  • the present method and system provides real-time account status checking and validation.

Abstract

Procédé et système informatique servant à exécuter une transaction entre un client (10) et au moins un vendeur (20), ce qui consiste à: (a) débuter une transaction par un client (10) avec un vendeur (20); (b) communiquer une demande d'autorisation, y compris des données client et des données spécifiques à la transaction, par le vendeur (20) à un système de transaction (26); (c) authentifier le client (10) par le système de transaction (26); (d) autoriser la transaction par le système de transaction (26); (e) communiquer la réponse d'autorisation par le système de transaction (26) au vendeur (20); (f) exécuter la transaction entre le vendeur (20) et le client (10). L'invention concerne également un dispositif servant à mettre ce procédé en application.
EP02714853A 2001-02-07 2002-02-07 Procede et systeme servant a executer une transaction entre un client et un vendeur Ceased EP1358609A4 (fr)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US26699501P 2001-02-07 2001-02-07
US266995P 2001-02-07
US27549401P 2001-03-13 2001-03-13
US275494P 2001-03-13
US32896401P 2001-10-12 2001-10-12
US328964P 2001-10-12
PCT/US2002/003743 WO2002063432A2 (fr) 2001-02-07 2002-02-07 Procede et systeme servant a executer une transaction entre un client et un vendeur

Publications (2)

Publication Number Publication Date
EP1358609A2 EP1358609A2 (fr) 2003-11-05
EP1358609A4 true EP1358609A4 (fr) 2007-11-28

Family

ID=27401931

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02714853A Ceased EP1358609A4 (fr) 2001-02-07 2002-02-07 Procede et systeme servant a executer une transaction entre un client et un vendeur

Country Status (4)

Country Link
EP (1) EP1358609A4 (fr)
AU (1) AU2009200162B2 (fr)
CA (1) CA2437507C (fr)
WO (1) WO2002063432A2 (fr)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1630865A (zh) 1998-11-13 2005-06-22 大通银行 在非安全的网络上用于多币种多银行处理的系统和方法
JP2003524220A (ja) 1998-12-23 2003-08-12 ジェイピーモルガン・チェース・バンク 取引書類の作成、処理、及びトラッキングを含む取引活動を統合するためのシステム及び方法
US7068832B1 (en) 1999-05-11 2006-06-27 The Chase Manhattan Bank Lockbox imaging system
US7805365B1 (en) 1999-10-25 2010-09-28 Jpmorgan Chase Bank, N.A. Automated statement presentation, adjustment and payment system and method therefor
US6965865B2 (en) 1999-12-30 2005-11-15 Bank One Delaware N.A. System and method for integrated customer management
US7822656B2 (en) 2000-02-15 2010-10-26 Jpmorgan Chase Bank, N.A. International banking system and method
US8768836B1 (en) 2000-02-18 2014-07-01 Jpmorgan Chase Bank, N.A. System and method for electronic deposit of a financial instrument by banking customers from remote locations by use of a digital image
US8468071B2 (en) 2000-08-01 2013-06-18 Jpmorgan Chase Bank, N.A. Processing transactions using a register portion to track transactions
AU2001285422A1 (en) 2000-08-11 2002-02-25 John J. Loy Trade receivable processing method and apparatus
AU2002224482A1 (en) 2000-11-06 2002-05-15 First Usa Bank, N.A. System and method for selectable funding of electronic transactions
US8805739B2 (en) 2001-01-30 2014-08-12 Jpmorgan Chase Bank, National Association System and method for electronic bill pay and presentment
US7822684B2 (en) 2001-10-05 2010-10-26 Jpmorgan Chase Bank, N.A. Personalized bank teller machine
US7689482B2 (en) 2002-05-24 2010-03-30 Jp Morgan Chase Bank, N.A. System and method for payer (buyer) defined electronic invoice exchange
US10311412B1 (en) 2003-03-28 2019-06-04 Jpmorgan Chase Bank, N.A. Method and system for providing bundled electronic payment and remittance advice
US8630947B1 (en) 2003-04-04 2014-01-14 Jpmorgan Chase Bank, N.A. Method and system for providing electronic bill payment and presentment
US7792717B1 (en) 2003-10-31 2010-09-07 Jpmorgan Chase Bank, N.A. Waterfall prioritized payment processing
US7814003B2 (en) 2003-12-15 2010-10-12 Jp Morgan Chase Billing workflow system for crediting charges to entities creating derivatives exposure
US7380707B1 (en) 2004-02-25 2008-06-03 Jpmorgan Chase Bank, N.A. Method and system for credit card reimbursements for health care transactions
US8554673B2 (en) 2004-06-17 2013-10-08 Jpmorgan Chase Bank, N.A. Methods and systems for discounts management
US8121944B2 (en) 2004-06-24 2012-02-21 Jpmorgan Chase Bank, N.A. Method and system for facilitating network transaction processing
US8290863B2 (en) 2004-07-23 2012-10-16 Jpmorgan Chase Bank, N.A. Method and system for expediting payment delivery
US7983468B2 (en) 2005-02-09 2011-07-19 Jp Morgan Chase Bank Method and system for extracting information from documents by document segregation
US7676409B1 (en) 2005-06-20 2010-03-09 Jpmorgan Chase Bank, N.A. Method and system for emulating a private label over an open network
US8301529B1 (en) 2005-11-02 2012-10-30 Jpmorgan Chase Bank, N.A. Method and system for implementing effective governance of transactions between trading partners
US7734545B1 (en) 2006-06-14 2010-06-08 Jpmorgan Chase Bank, N.A. Method and system for processing recurring payments
US7916925B2 (en) 2007-02-09 2011-03-29 Jpmorgan Chase Bank, N.A. System and method for generating magnetic ink character recognition (MICR) testing documents
US8762270B1 (en) 2007-08-10 2014-06-24 Jpmorgan Chase Bank, N.A. System and method for providing supplemental payment or transaction information
US8622308B1 (en) 2007-12-31 2014-01-07 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
DE112009000137T5 (de) 2008-01-15 2011-02-17 Visa U.S.A. Inc., San Francisco System und Verfahren zur Datenvervollständigung mit Anschubkennung
US8112355B1 (en) 2008-09-05 2012-02-07 Jpmorgan Chase Bank, N.A. Method and system for buyer centric dispute resolution in electronic payment system
US8391584B2 (en) 2008-10-20 2013-03-05 Jpmorgan Chase Bank, N.A. Method and system for duplicate check detection
US9092447B1 (en) 2008-10-20 2015-07-28 Jpmorgan Chase Bank, N.A. Method and system for duplicate detection
US9058626B1 (en) 2013-11-13 2015-06-16 Jpmorgan Chase Bank, N.A. System and method for financial services device usage

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5793028A (en) * 1996-06-24 1998-08-11 Fred N. Gratzon Electronic transaction security system
WO2000002150A1 (fr) * 1998-07-01 2000-01-13 Webcard Inc. Procede d'autorisation de transaction
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7366695B1 (en) * 2000-02-29 2008-04-29 First Data Corporation Electronic purchase method and funds transfer system
US20020035538A1 (en) * 2000-09-15 2002-03-21 Moreau Lawrence R. Method and system for facilitating buying and selling transactions
US20020069166A1 (en) * 2000-09-15 2002-06-06 Moreau Lawrence R. Method and system for facilitating buying and selling transactions

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5793028A (en) * 1996-06-24 1998-08-11 Fred N. Gratzon Electronic transaction security system
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
WO2000002150A1 (fr) * 1998-07-01 2000-01-13 Webcard Inc. Procede d'autorisation de transaction

Also Published As

Publication number Publication date
AU2002247093B2 (en) 2008-10-16
CA2437507A1 (fr) 2002-08-15
AU2009200162B2 (en) 2011-06-02
WO2002063432A3 (fr) 2003-03-06
CA2437507C (fr) 2015-10-27
WO2002063432A8 (fr) 2003-12-24
EP1358609A2 (fr) 2003-11-05
WO2002063432A2 (fr) 2002-08-15
AU2009200162A1 (en) 2009-02-12

Similar Documents

Publication Publication Date Title
US7890393B2 (en) Method and system for completing a transaction between a customer and a merchant
AU2009200162B2 (en) Method and system for completing a transaction between a customer and a merchant
CA2604913C (fr) Procede et systeme destines a la gestion des risques dans une transaction
US5974146A (en) Real time bank-centric universal payment system
US6999943B1 (en) Routing methods and systems for increasing payment transaction volume and profitability
US7627524B2 (en) System, method, and computer program product for receiving and processing payments
US8195565B2 (en) Systems and methods for point of interaction based policy routing of transactions
US8851369B2 (en) Systems and methods for transaction processing using a smartcard
US8180706B2 (en) Systems and methods for maximizing a rewards accumulation strategy during transaction processing
US20060085335A1 (en) Point of sale systems and methods for consumer bill payment
US20140337183A1 (en) Online processing for offshore business transactions
US20090271278A1 (en) Systems and methods for routing a transaction request to a payment system via a transaction device
US20090265249A1 (en) Systems and methods for split tender transaction processing
US20090265250A1 (en) Systems and methods for processing a transaction according to an allowance
US20030216996A1 (en) Methods and systems for providing financial payment services
US20090271277A1 (en) Systems and methods for transaction processing based upon an overdraft scenario
US20070106558A1 (en) System and method of automatic insufficient funds notification and overdraft protection
US20050192892A1 (en) Automated clearing house compatible loadable debit card system and method
AU2002247093B8 (en) Method and system for completing a transaction between a customer and a merchant
AU2002247093A1 (en) Method and system for completing a transaction between a customer and a merchant
US20050251472A1 (en) Marketing of transaction cards
WO2001084517A2 (fr) Systeme et procede de transactions securisees sur reseau

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030806

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

A4 Supplementary search report drawn up and despatched

Effective date: 20071025

17Q First examination report despatched

Effective date: 20080520

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20170410