WO2002075499A2 - Method and system for making small payments using a payment card - Google Patents

Method and system for making small payments using a payment card Download PDF

Info

Publication number
WO2002075499A2
WO2002075499A2 PCT/US2002/008417 US0208417W WO02075499A2 WO 2002075499 A2 WO2002075499 A2 WO 2002075499A2 US 0208417 W US0208417 W US 0208417W WO 02075499 A2 WO02075499 A2 WO 02075499A2
Authority
WO
WIPO (PCT)
Prior art keywords
micropayment
transaction
cardholder
repudiation
payment
Prior art date
Application number
PCT/US2002/008417
Other languages
French (fr)
Other versions
WO2002075499A3 (en
Inventor
John Wankmueller
Original Assignee
Mastercard International Incorporated
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 Mastercard International Incorporated filed Critical Mastercard International Incorporated
Priority to JP2002574042A priority Critical patent/JP2004527038A/en
Priority to AU2002247375A priority patent/AU2002247375B2/en
Priority to CA002440682A priority patent/CA2440682A1/en
Priority to EP02715158A priority patent/EP1371002A4/en
Publication of WO2002075499A2 publication Critical patent/WO2002075499A2/en
Publication of WO2002075499A3 publication Critical patent/WO2002075499A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/24Credit schemes, i.e. "pay after"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/29Payment schemes or models characterised by micropayments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/407Cancellation of a transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03Credit; Loans; Processing thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/18Legal services
    • G06Q50/188Electronic negotiation

Definitions

  • payment cards - such as credit and debit cards - are ubiquitous methods of payment. These payment cards are issued by individual card companies or are issued by financial institutions that are members of a payment association (such as MasterCard® International Incorporated). As used in this application, the term "payment card” includes not only physical payment cards in which the payment account information is stored on a physical card, but also virtual payment cards in which the payment account information is stored in digital or electronic form.
  • micropayments A problem with conventional payment cards has been in using them for making small payments, also called "micropayments.”
  • the level below which a payment is considered a micropayment varies depending on the circumstance.
  • a typical range for the threshold level for micropayments, however, is about $4 to $25.
  • Card issuers generally do not like cardholders to make micropayments on conventional payment cards because such transactions are not cost-effective for them.
  • costs associated with micropayment repudiations which are the costs incurred when a cardholder disputes a micropayment on a statement.
  • Such costs include processing costs, costs associated with customer call centers facilities and equipment, and salaries for customer service representatives.
  • the statement costs for separately itemizing micropayments on a statement are also a concern.
  • micropayment schemes As an alternative to conventional payment cards, several different micropayment schemes have been suggested. By way of example, some schemes have introduced the concept of digital currency or tokens, which consumers would pay for using conventional payment methods and load in a digital wallet. Other schemes rely on aggregation, in which the micropayments are aggregated periodically by a micropayment provider and the aggregated amount is then charged to a payment card account.
  • a micropayment transaction being conducted through a conventional payment network is uniquely identified in some way as a "micropayment".
  • the repudiation is handled automatically - i.e., the account holder's account is automatically credited with the amount of the micropayment transaction. Since the repudiation is handled automatically, under the present invention, the issuer is not required to spend money to maintain a customer call center to handle disputed micropayment transactions.
  • a party keeps a database of the individual micropayment transactions for a certain period of time, and the database is accessible to cardholders through some communication means known in the art (for example, by Internet or by telephone). If a cardholder repudiates a micropayment transaction in the database, a credit or refund to the cardholder's account is performed automatically (which would preferably be displayed on the cardholder's subsequent periodic statement).
  • an issuer may elect whether or not to separately itemize micropayment transactions in a cardholder's periodic statement. If an issuer itemizes individual micropayment transactions in a cardholder's periodic statement, the issuer may include a reference number that identifies each micropayment transaction, and the cardholder may use such a reference number to repudiate a micropayment transaction. Preferably, the issuer would separate the micropayment transactions from other transactions (for example, list the micropayment transactions on a separate sheet or sheets). Preferably, the issuer would also provide instructions on how to repudiate a micropayment transaction, which would involve the use of an automatic system instead of calling a customer service representative. The automatic system may involve an interactive voice response unit (for using the telephone to repudiate micropayment transactions), a web interface (for using a web browser to repudiate micropayment transactions), and/or an email system (for using email to repudiate micropayment transactions).
  • an interactive voice response unit for using the telephone to repudiate micropayment transactions
  • a web interface for using a web browser to repudiate micro
  • the card issuer need not separately itemize the micropayment transactions on a cardholder statement.
  • the micropayment transactions are aggregated either by the card issuer or by another party (for example, the payment card association through which the transactions were carried) and only the aggregated amount is presented to the cardholder on the cardholder's statement with one line item indicating the aggregated amount.
  • a cardholder accesses the micropayment transaction database and uses information in this database to repudiate a micropayment transaction.
  • the cardholder may access the database as explained above through any communication means known in the art, such as through the telephone or the Internet.
  • micropayment repudiation could be predefined, which would trigger an appropriate action. For example, the number of repudiations per payment account or per cardholder per period could be tracked, and after a certain threshold, appropriate action could be taken against the cardholder.
  • the micropayment transaction database could also be statistically analyzed for merchant fraud.
  • Fig. 1 is a functional block diagram showing the relationships of parties in a conventional payment association payment card system
  • Fig. 2 shows a payment card system according to an exemplary embodiment of the present invention
  • FIGs. 3 A and 3B show flow charts of a transaction according to an exemplary embodiment of the present invention.
  • Fig. 4 shows a flow chart of a repudiation according to an exemplary embodiment of the present invention.
  • Fig. 1 illustrates the relationships between the parties involved in a conventional payment association payment card system.
  • the cardholder 100 is issued a payment card by the card issuer 108.
  • the cardholder 100 presents his or her payment card (either in-person or over the telephone or Internet) to the merchant 102.
  • the merchant 102 has a relationship with an acquirer 104, which has access to a payment network 106.
  • the acquirer is typically a financial institution or bank in which the merchant has a financial account.
  • the card issuer 108 is also in communication with the payment network 106.
  • the merchant 102 When the merchant is presented with the cardholder's payment card, the merchant 102 requests authorization for the transaction from the acquirer 104.
  • the acquirer in turn forwards the authorization request through the payment network to the card issuer.
  • the card issuer Based upon the cardholder's account status and the amount of the transaction, the card issuer authorizes or denies the authorization request.
  • the card issuer's response is routed through the payment network and the acquirer to the merchant.
  • Fig. 2 shows a payment card system according to an exemplary embodiment of the present invention.
  • the relationships between the cardholder 100, merchant 102, acquirer 104, payment network 106, and card issuer 108 are the same as described in relation to Fig. 1.
  • the payment network either incorporates or communicates with a micropayment handling system (MHS) 200.
  • the MHS 200 incorporates or communicates with a micropayment transaction database (hereafter referred to as the "MDB").
  • MDB micropayment transaction database
  • the MHS handles the micropayment transactions that pass through the payment network, including storing the micropayment transaction information in the MDB.
  • the cardholder 100 has access to the MDB through any means known in the art.
  • the cardholder 100 has access to the MDB through a telephone or web interface 204.
  • Figs. 3 A and 3B show flow charts of a transaction according to an exemplary embodiment of the present invention.
  • a cardholder presents a payment card to a merchant for a transaction involving a micropayment.
  • the payment card may be any type of payment card known in the art. For example, it could be a physical payment card (such as a plastic credit card), or it could be a virtual payment card (such as a payment account number stored in a software application).
  • the presentment of the payment card may be in any form, such as face-to-face (card- present), over the telephone, or over the Internet.
  • the present invention may be utilized with any type of merchant, the present invention is especially advantageous for use with Internet merchants.
  • the merchant sends an authorization request to the acquirer for a micropayment transaction.
  • POS point-of-sale
  • the merchant will swipe a payment card in a POS terminal that is in communication with the acquirer, and the terminal will send an authorization request to the acquirer.
  • the merchant will receive cardholder information over the Internet (usually by the cardholder filling out an online form), and the merchant will generate an authorization request using this cardholder information.
  • the authorization request message includes an identification of the transaction as a micropayment transaction. This may be accomplished in a number of ways. For example, one or more new fields may be inserted in the authorization request message, the value of which will indicate a micropayment transaction. Preferably, however, one or more existing fields in the authorization request message are used, and a new value or combination of values for these existing fields is defined as indicating a micropayment transaction. For example, if an existing data element in the authorization message has an undefined value, a new value in that data element (previously undefined) may be defined as indicating a micropayment transaction. As another example, a combination of the amount, merchant, and/or merchant type may be used to indicate a micropayment transaction.
  • the micropayment identification may be performed manually by the merchant or the cardholder or it may be based on transaction-based parameters. If performed manually by the merchant or the cardholder, the merchant may require new or modified terminals (in the case of POS merchants) or new or modified software (in the case of Internet merchants) that have an appropriate input device or mechanism to indicate a micropayment transaction.
  • the input device may be a button or combination of buttons on a terminal, or the input device may be a separate card reader to be used only in conjunction with micropayment transactions.
  • the input mechanism may be a software button, check list, drop-down list, or data entry field on a purchase order screen that the cardholder clicks on, selects, or enters data in to indicate a micropayment.
  • the micropayment identification may also be based on transaction- based parameters.
  • a micropayment may be indicated by transactions involving amounts less than a predefined threshold amount. Although any threshold amount may be selected, by way of example, the threshold amount may be $4.
  • Hardware or software at any point along the transaction authorization path could then be configured or programmed with this parameter to recognize micropayment transactions. When a micropayment transaction is recognized, such hardware or software could forward the transactional information to a micropayment handling system (as described below) or it could insert an identification in the transaction message (as described above) indicating that the transaction is a micropayment for further processing along the authorization path.
  • step 304 the acquirer sends the authorization request message to the payment network.
  • step 306 the payment network recognizes the transaction as a micropayment transaction (because of the identification of such in the transaction message). Accordingly, the payment network forwards the transaction information to the MHS and forwards the authorization message to the proper card issuer.
  • the card issuer authorizes or denies the transaction based on the transaction details and the status of the cardholder's account.
  • the card issuer recognizes the transaction as a micropayment and, when statements are printed, the card issuer need not individually itemize these transactions. Instead, the card issuer (or a third party processor) may aggregate the micropayment transactions for the statement period and print only the aggregated amount. Alternatively, the MHS may aggregate these payments for each card issuer and send the aggregated amounts to the card issuers for each statement period.
  • the MHS creates a record for and stores the micropayment transaction in the MDB.
  • step 312 the payment network forwards the authorization response to the acquirer and, recognizing the transaction as a micropayment, sends the authorization response to the MHS.
  • step 3134 the MHS stores the authorization response in the MDB.
  • step 316 the acquirer forwards the authorization message to the merchant.
  • step 318 the merchant completes or rejects the transaction based on the authorization response. Assuming that the merchant receives a positive authorization, the merchant is then guaranteed payment under the rules of the major payment associations.
  • the micropayment transactions may or may not be individually itemized on the statement. If the micropayment transactions are not individually itemized on the statement, there will be only one line item for micropayment transactions, which will be the aggregated amount of all micropayment transactions for that statement period. In this case, to examine information about a particular micropayment transaction, the cardholder must access the MDB through interface 204 (see Fig. 2).
  • a cardholder who desires to repudiate a micropayment transaction accesses the MDB.
  • a cardholder may access the MDB through any available technology, but familiar and convenient interfaces for most cardholders are the telephone and the World Wide Web.
  • the cardholder provides the payment account number used to make the disputed transaction.
  • appropriate security measures (which are known in the art) are used to authenticate the cardholder.
  • the cardholder may provide a personal identification number (PIN).
  • PIN personal identification number
  • the cardholder identifies the specific micropayment transaction that the cardholder desires to repudiate.
  • a reference number may be provided on the statement.
  • a cardholder may identify an individual micropayment transaction using the interface to the MDB.
  • the cardholder repudiates the specific micropayment transaction. This repudiation may be accomplished in any feasible manner. For example, if the interface is a telephone interface, the cardholder may be asked to press a specific button on the telephone, or if the interface is a Web interface, the cardholder may click on an appropriate button on his or her computer screen. Alternatively, the cardholder could be asked to send a written request for repudiation through mail or email, including in the request an identifier of the specific micropayment transaction.
  • the MHS receives the repudiation request from the cardholder. It processes the repudiation automatically (i.e., credits the cardholder's account for the amount of the transaction) without any investigation or query into whether the transaction was validly executed.
  • the issuer may bear the cost of this automatic credit.
  • the issuer may still decide, at its option, whether or not to proceed with a chargeback (in which the issuer attempts to receive a credit from an acquirer). It may be the case that, because of the processing costs involved, it will not make economic sense for an issuer to proceed with a chargeback.
  • the MHS also stores the repudiation request in a database (either the MDB or another database) which contains or links to a database containing certain conditions under which certain actions may be taken, such as generating a report or other message regarding the cardholder to the card issuer. For example, a report or message may be generated if the cardholder has repudiated more than a predefined number of micropayment transactions in any particular period. The report or message may be sent to the card issuer, which may take appropriate action, such as warning the cardholder, canceling the cardholder's ability to perform micropayments with an account number, or canceling the cardholder's account.
  • the MHS determines whether the repudiation by the cardholder triggers any predefined conditions. If the repudiation does not trigger any conditions, then the processing is complete. If the repudiation does trigger any conditions, then the MHS takes the action associated with the triggered condition, such as generating a report or message to the card issuer.
  • Card issuers do not need to separately itemize micropayments on cardholder statements.
  • Card issuers do not incur the conventional costs associated with handling cardholder repudiation.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Technology Law (AREA)
  • Computer Security & Cryptography (AREA)
  • Primary Health Care (AREA)
  • Human Resources & Organizations (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Development Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

A system for conducting a financial transaction over a payment network is disclosed, which system includes a micropayment system (400) interfaced with the payment network for allowing identification of the transaction (402) as a micropayment transaction and allowing, at the option of the cardholder (402), repudiation of the micropayment transaction automatically by crediting the cardholder's account the amount of the micropayment transaction (404).

Description

METHOD AND SYSTEM FOR MAKING SMALL PAYMENTS USING A PAYMENT CARD
SPECIFICATION
PRIORITY APPLICATION This application claims priority to United States provisional application 60/277,143 filed on March 19, 2001, and entitled "Method and System for Making Small Payments Using a Payment Card," which is hereby incorporated by reference.
BACKGROUND In today's commercial environment, payment cards - such as credit and debit cards - are ubiquitous methods of payment. These payment cards are issued by individual card companies or are issued by financial institutions that are members of a payment association (such as MasterCard® International Incorporated). As used in this application, the term "payment card" includes not only physical payment cards in which the payment account information is stored on a physical card, but also virtual payment cards in which the payment account information is stored in digital or electronic form.
A problem with conventional payment cards has been in using them for making small payments, also called "micropayments." The level below which a payment is considered a micropayment varies depending on the circumstance. A typical range for the threshold level for micropayments, however, is about $4 to $25.
Card issuers generally do not like cardholders to make micropayments on conventional payment cards because such transactions are not cost-effective for them. Of particular concern are the costs associated with micropayment repudiations, which are the costs incurred when a cardholder disputes a micropayment on a statement. Such costs include processing costs, costs associated with customer call centers facilities and equipment, and salaries for customer service representatives. To a lesser extent, the statement costs for separately itemizing micropayments on a statement are also a concern.
As an alternative to conventional payment cards, several different micropayment schemes have been suggested. By way of example, some schemes have introduced the concept of digital currency or tokens, which consumers would pay for using conventional payment methods and load in a digital wallet. Other schemes rely on aggregation, in which the micropayments are aggregated periodically by a micropayment provider and the aggregated amount is then charged to a payment card account.
One of the biggest obstacles with the existing micropayment schemes is that each scheme requires a merchant to install a micropayment provider's proprietary technology. Lacking widespread support in the marketplace for any one particular scheme, consumers are then required to register and open multiple accounts with multiple micropayment providers to purchase content from different merchants. This is obviously very inconvenient to consumers.
Therefore, there exists a need for a micropayment scheme that will work with conventional payment cards and that could be implemented by all merchants that accept conventional payment cards with little or no changes to their existing systems, while at the same time addressing the economic concerns of card issuers.
SUMMARY OF THE INVENTION The present invention solves the foregoing need. In the present invention, a micropayment transaction being conducted through a conventional payment network is uniquely identified in some way as a "micropayment". Under the present invention, if an account holder repudiates a micropayment transaction, the repudiation is handled automatically - i.e., the account holder's account is automatically credited with the amount of the micropayment transaction. Since the repudiation is handled automatically, under the present invention, the issuer is not required to spend money to maintain a customer call center to handle disputed micropayment transactions.
In a preferred embodiment of the present invention, a party keeps a database of the individual micropayment transactions for a certain period of time, and the database is accessible to cardholders through some communication means known in the art (for example, by Internet or by telephone). If a cardholder repudiates a micropayment transaction in the database, a credit or refund to the cardholder's account is performed automatically (which would preferably be displayed on the cardholder's subsequent periodic statement).
Under the present invention, an issuer may elect whether or not to separately itemize micropayment transactions in a cardholder's periodic statement. If an issuer itemizes individual micropayment transactions in a cardholder's periodic statement, the issuer may include a reference number that identifies each micropayment transaction, and the cardholder may use such a reference number to repudiate a micropayment transaction. Preferably, the issuer would separate the micropayment transactions from other transactions (for example, list the micropayment transactions on a separate sheet or sheets). Preferably, the issuer would also provide instructions on how to repudiate a micropayment transaction, which would involve the use of an automatic system instead of calling a customer service representative. The automatic system may involve an interactive voice response unit (for using the telephone to repudiate micropayment transactions), a web interface (for using a web browser to repudiate micropayment transactions), and/or an email system (for using email to repudiate micropayment transactions).
In another embodiment of the present invention, the card issuer need not separately itemize the micropayment transactions on a cardholder statement.
Instead, the micropayment transactions are aggregated either by the card issuer or by another party (for example, the payment card association through which the transactions were carried) and only the aggregated amount is presented to the cardholder on the cardholder's statement with one line item indicating the aggregated amount. To repudiate an individual micropayment transaction, a cardholder accesses the micropayment transaction database and uses information in this database to repudiate a micropayment transaction. The cardholder may access the database as explained above through any communication means known in the art, such as through the telephone or the Internet.
To prevent cardholder fraud, certain conditions associated with micropayment repudiation could be predefined, which would trigger an appropriate action. For example, the number of repudiations per payment account or per cardholder per period could be tracked, and after a certain threshold, appropriate action could be taken against the cardholder. The micropayment transaction database could also be statistically analyzed for merchant fraud.
BRIEF DESCRIPTION OF THE DRAWINGS Exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings in which:
Fig. 1 is a functional block diagram showing the relationships of parties in a conventional payment association payment card system;
Fig. 2 shows a payment card system according to an exemplary embodiment of the present invention;
Figs. 3 A and 3B show flow charts of a transaction according to an exemplary embodiment of the present invention; and
Fig. 4 shows a flow chart of a repudiation according to an exemplary embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION By way of background, Fig. 1 illustrates the relationships between the parties involved in a conventional payment association payment card system. The cardholder 100 is issued a payment card by the card issuer 108. When the cardholder desires to purchase goods or services from a merchant 102, the cardholder 100 presents his or her payment card (either in-person or over the telephone or Internet) to the merchant 102. The merchant 102 has a relationship with an acquirer 104, which has access to a payment network 106. The acquirer is typically a financial institution or bank in which the merchant has a financial account. The card issuer 108 is also in communication with the payment network 106. When the merchant is presented with the cardholder's payment card, the merchant 102 requests authorization for the transaction from the acquirer 104. The acquirer in turn forwards the authorization request through the payment network to the card issuer. Based upon the cardholder's account status and the amount of the transaction, the card issuer authorizes or denies the authorization request. The card issuer's response is routed through the payment network and the acquirer to the merchant.
Fig. 2 shows a payment card system according to an exemplary embodiment of the present invention. The relationships between the cardholder 100, merchant 102, acquirer 104, payment network 106, and card issuer 108 are the same as described in relation to Fig. 1. In this case, however, the payment network either incorporates or communicates with a micropayment handling system (MHS) 200. The MHS 200 incorporates or communicates with a micropayment transaction database (hereafter referred to as the "MDB"). The MHS handles the micropayment transactions that pass through the payment network, including storing the micropayment transaction information in the MDB. The cardholder 100 has access to the MDB through any means known in the art. Preferably, the cardholder 100 has access to the MDB through a telephone or web interface 204.
Figs. 3 A and 3B show flow charts of a transaction according to an exemplary embodiment of the present invention. In step 300, a cardholder presents a payment card to a merchant for a transaction involving a micropayment. The payment card may be any type of payment card known in the art. For example, it could be a physical payment card (such as a plastic credit card), or it could be a virtual payment card (such as a payment account number stored in a software application). The presentment of the payment card may be in any form, such as face-to-face (card- present), over the telephone, or over the Internet. Although the present invention may be utilized with any type of merchant, the present invention is especially advantageous for use with Internet merchants.
In step 302, the merchant sends an authorization request to the acquirer for a micropayment transaction. As an example, during a typical point-of-sale (POS), card-present transaction, the merchant will swipe a payment card in a POS terminal that is in communication with the acquirer, and the terminal will send an authorization request to the acquirer. When the transaction is conducted over the Internet, the merchant will receive cardholder information over the Internet (usually by the cardholder filling out an online form), and the merchant will generate an authorization request using this cardholder information.
In the present invention, the authorization request message includes an identification of the transaction as a micropayment transaction. This may be accomplished in a number of ways. For example, one or more new fields may be inserted in the authorization request message, the value of which will indicate a micropayment transaction. Preferably, however, one or more existing fields in the authorization request message are used, and a new value or combination of values for these existing fields is defined as indicating a micropayment transaction. For example, if an existing data element in the authorization message has an undefined value, a new value in that data element (previously undefined) may be defined as indicating a micropayment transaction. As another example, a combination of the amount, merchant, and/or merchant type may be used to indicate a micropayment transaction.
The micropayment identification may be performed manually by the merchant or the cardholder or it may be based on transaction-based parameters. If performed manually by the merchant or the cardholder, the merchant may require new or modified terminals (in the case of POS merchants) or new or modified software (in the case of Internet merchants) that have an appropriate input device or mechanism to indicate a micropayment transaction. In the case of a POS merchant, the input device may be a button or combination of buttons on a terminal, or the input device may be a separate card reader to be used only in conjunction with micropayment transactions. In the case of an Internet merchant, the input mechanism may be a software button, check list, drop-down list, or data entry field on a purchase order screen that the cardholder clicks on, selects, or enters data in to indicate a micropayment.
The micropayment identification may also be based on transaction- based parameters. As a simple example, a micropayment may be indicated by transactions involving amounts less than a predefined threshold amount. Although any threshold amount may be selected, by way of example, the threshold amount may be $4. Hardware or software at any point along the transaction authorization path could then be configured or programmed with this parameter to recognize micropayment transactions. When a micropayment transaction is recognized, such hardware or software could forward the transactional information to a micropayment handling system (as described below) or it could insert an identification in the transaction message (as described above) indicating that the transaction is a micropayment for further processing along the authorization path.
Returning to Fig. 3, in step 304, the acquirer sends the authorization request message to the payment network. In step 306, the payment network recognizes the transaction as a micropayment transaction (because of the identification of such in the transaction message). Accordingly, the payment network forwards the transaction information to the MHS and forwards the authorization message to the proper card issuer.
In step 308, the card issuer authorizes or denies the transaction based on the transaction details and the status of the cardholder's account. The card issuer recognizes the transaction as a micropayment and, when statements are printed, the card issuer need not individually itemize these transactions. Instead, the card issuer (or a third party processor) may aggregate the micropayment transactions for the statement period and print only the aggregated amount. Alternatively, the MHS may aggregate these payments for each card issuer and send the aggregated amounts to the card issuers for each statement period. In step 310, the MHS creates a record for and stores the micropayment transaction in the MDB.
After the card issuer sends a response to the authorization request, in step 312, the payment network forwards the authorization response to the acquirer and, recognizing the transaction as a micropayment, sends the authorization response to the MHS.
In step 314, the MHS stores the authorization response in the MDB.
In step 316, the acquirer forwards the authorization message to the merchant.
In step 318, the merchant completes or rejects the transaction based on the authorization response. Assuming that the merchant receives a positive authorization, the merchant is then guaranteed payment under the rules of the major payment associations.
When a cardholder receives his or her statement, the micropayment transactions may or may not be individually itemized on the statement. If the micropayment transactions are not individually itemized on the statement, there will be only one line item for micropayment transactions, which will be the aggregated amount of all micropayment transactions for that statement period. In this case, to examine information about a particular micropayment transaction, the cardholder must access the MDB through interface 204 (see Fig. 2).
Turning to Fig. 4, this figure shows a flow chart of a repudiation according to an exemplary embodiment of the present invention. In step 400, a cardholder who desires to repudiate a micropayment transaction accesses the MDB. A cardholder may access the MDB through any available technology, but familiar and convenient interfaces for most cardholders are the telephone and the World Wide Web. At a minimum, the cardholder provides the payment account number used to make the disputed transaction. Preferably, appropriate security measures (which are known in the art) are used to authenticate the cardholder. For example, the cardholder may provide a personal identification number (PIN). In step 402, the cardholder identifies the specific micropayment transaction that the cardholder desires to repudiate. If the micropayment transactions are individually itemized on the cardholder's statement, a reference number may be provided on the statement. Alternatively, and in the case where micropayment transactions are not individually itemized on a cardholder's statement, a cardholder may identify an individual micropayment transaction using the interface to the MDB. In step 404, the cardholder repudiates the specific micropayment transaction. This repudiation may be accomplished in any feasible manner. For example, if the interface is a telephone interface, the cardholder may be asked to press a specific button on the telephone, or if the interface is a Web interface, the cardholder may click on an appropriate button on his or her computer screen. Alternatively, the cardholder could be asked to send a written request for repudiation through mail or email, including in the request an identifier of the specific micropayment transaction.
In step 406, the MHS receives the repudiation request from the cardholder. It processes the repudiation automatically (i.e., credits the cardholder's account for the amount of the transaction) without any investigation or query into whether the transaction was validly executed. The issuer may bear the cost of this automatic credit. When a repudiation is processed automatically, the issuer may still decide, at its option, whether or not to proceed with a chargeback (in which the issuer attempts to receive a credit from an acquirer). It may be the case that, because of the processing costs involved, it will not make economic sense for an issuer to proceed with a chargeback. The MHS also stores the repudiation request in a database (either the MDB or another database) which contains or links to a database containing certain conditions under which certain actions may be taken, such as generating a report or other message regarding the cardholder to the card issuer. For example, a report or message may be generated if the cardholder has repudiated more than a predefined number of micropayment transactions in any particular period. The report or message may be sent to the card issuer, which may take appropriate action, such as warning the cardholder, canceling the cardholder's ability to perform micropayments with an account number, or canceling the cardholder's account. In step 408, the MHS determines whether the repudiation by the cardholder triggers any predefined conditions. If the repudiation does not trigger any conditions, then the processing is complete. If the repudiation does trigger any conditions, then the MHS takes the action associated with the triggered condition, such as generating a report or message to the card issuer.
The advantages of the present invention include:
. No cardholder registration for micropayment service is required. The cardholder receives the service by use of an already applied-for and issued payment card. (Of course, a card issuer may decide to provide the micropayment service as an option to cardholders, in which case some sort of registration process may be involved. This process, however, should be simpler than signing onto a completely separate micropayment scheme provider, since the cardholder already has a relationship with the card issuer.) • Merchants are required to make little or no changes to their existing systems.
Existing payment methodologies and infrastructure may be utilized.
• Ease of implementation and guaranteed payments under existing payment methodologies should assure wide-spread adoption by merchants.
Card issuers do not need to separately itemize micropayments on cardholder statements.
. Card issuers do not incur the conventional costs associated with handling cardholder repudiation.

Claims

1. A method for conducting a financial transaction by a cardholder, having a payment card and an associated account, through a conventional payment network, comprising, conducting said financial transaction with said payment card; identifying said financial transaction as one involving a micropayment transaction; allowing, at the option of the cardholder, repudiation of said micropayment transaction automatically by crediting said account the amount of said micropayment transaction.
2. The method of claim 1 further comprising: providing a database for storing said micropayment transactions conducted by one or more cardholders over a certain period of time; allowing access to said database by said one or more cardholders over a communications network; utilizing said database to identify the micropayment transaction to be repudiated.
3. The method of claim 2, further comprising: providing said cardholder with a statement which presents said micropayment transactions in the aggregate.
4. The method of claim 1 further comprising: providing said cardholder with a statement itemizing said micropayment transaction; assigning a reference number to each such micropayment transaction; utilizing said reference number in repudiating said micropayment transaction.
5. The method of claim 4 further comprising: separating on said statement said micropayment transactions.
6. The method of claim 1 , wherein said repudiation of said micropayment transaction involves use of an automatic system comprising one or more of an interactive voice response unit, a web interface and an email system.
7. The method of claim 6, further comprising: defining one or more conditions required to be satisfied before allowing said repudiation to occur.
8. The method of claim 7, wherein said one or more conditions comprises tracking the number of repudiations per account and disallowing said repudiation or transaction after a threshold number of repudiations.
9. The method of claim 7, wherein said one or more conditions comprises tracking the number of repudiations per cardholder and disallowing said repudiation or transaction after a threshold number of repudiations.
10. A system for conducting a financial transaction, comprising: an issuer which issues a payment card to a cardholder having an associated account; an acquirer which receives an authorization request from a merchant to whom said payment card is presented for conducting said transaction; a payment network through which said authorization request is transmitted, said network receiving said request and forwarding it to said issuer of said payment card and receiving said card issuer's response and routing said response back to said acquirer; a micropayment system interfaced with said payment network for allowing, at the option of said cardholder, repudiation of said micropayment transaction automatically by crediting said account the amount of said micropayment transaction.
11. The system of claim 10 wherein said micropayment system comprises : a micropayment handling system for processing said micropayment transactions; and a micropayment transaction database for storing said micropayment transaction information, and wherein said cardholder has access to said database through a communication network to achieve said repudiation.
12. The system of claim 10 wherein transaction-based parameters comprising one or more of the transaction amount, said merchant and a type of merchant, indicate whether said transaction is a micropayment transaction.
13. The system of claim 10 wherein said authorization request identifies said financial transaction as a micropayment transaction.
14. The system of claim 13 wherein said authorization request comprises a plurality of fields one or more of which having a value indicative of said micropayment transaction.
15. The system of claim 10 wherein said merchant indicates whether said transaction is a micropayment transaction.
16. The system of claim 10 wherein said cardholder indicates whether said transaction is a micropayment transaction.
17. The system of claim 11 wherein said micropayment system aggregates the micropayment transactions and sends the aggregates to said card issuers.
18. The system of claim 11 wherein said repudiation is effected through an input device connected to said micropayment handling system.
PCT/US2002/008417 2001-03-19 2002-02-19 Method and system for making small payments using a payment card WO2002075499A2 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2002574042A JP2004527038A (en) 2001-03-19 2002-02-19 Method and system for making a small payment using a payment card
AU2002247375A AU2002247375B2 (en) 2001-03-19 2002-02-19 Method and system for making small payments using a payment card
CA002440682A CA2440682A1 (en) 2001-03-19 2002-02-19 Method and system for making small payments using a payment card
EP02715158A EP1371002A4 (en) 2001-03-19 2002-02-19 Method and system for making small payments using a payment card

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US27714301P 2001-03-19 2001-03-19
US60/277,143 2001-03-19

Publications (2)

Publication Number Publication Date
WO2002075499A2 true WO2002075499A2 (en) 2002-09-26
WO2002075499A3 WO2002075499A3 (en) 2002-12-05

Family

ID=23059567

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/008417 WO2002075499A2 (en) 2001-03-19 2002-02-19 Method and system for making small payments using a payment card

Country Status (7)

Country Link
US (1) US7146344B2 (en)
EP (1) EP1371002A4 (en)
JP (1) JP2004527038A (en)
AU (1) AU2002247375B2 (en)
CA (1) CA2440682A1 (en)
WO (1) WO2002075499A2 (en)
ZA (1) ZA200307302B (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008092010A2 (en) * 2007-01-28 2008-07-31 Bora Payment Systems, Llc Payer direct hub
US8521650B2 (en) 2007-02-26 2013-08-27 Zepfrog Corp. Method and service for providing access to premium content and dispersing payment therefore
US11093907B2 (en) 2002-01-15 2021-08-17 Jpmorgan Chase Bank, N.A. System and method for processing microtransactions

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2358528C (en) 1998-12-23 2015-04-14 The Chase Manhattan Bank System and method for integrating trading operations including the generation, processing and tracking of trade documents
US7805365B1 (en) 1999-10-25 2010-09-28 Jpmorgan Chase Bank, N.A. Automated statement presentation, adjustment and payment system and method therefor
US8571975B1 (en) 1999-11-24 2013-10-29 Jpmorgan Chase Bank, N.A. System and method for sending money via E-mail over the internet
US7822656B2 (en) 2000-02-15 2010-10-26 Jpmorgan Chase Bank, N.A. International banking system and method
CA2445573A1 (en) * 2001-04-27 2002-11-07 Massachusetts Institute Of Technology Method and system for micropayment transactions
US7899753B1 (en) 2002-03-25 2011-03-01 Jpmorgan Chase Bank, N.A Systems and methods for time variable financial authentication
US20040059687A1 (en) * 2002-08-29 2004-03-25 Vantresa Stickler Providing a verifiable delivery payment coding
WO2006004794A2 (en) * 2004-06-25 2006-01-12 Peppercoin, Inc. Payment processing method and system
JP2009501981A (en) 2005-07-15 2009-01-22 レボリューション マネー,インコーポレイテッド System and method for new execution and management of financial and data transactions
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US20080040261A1 (en) * 2006-04-24 2008-02-14 Robert Nix Systems and methods for implementing financial transactions
US20070267479A1 (en) * 2006-05-16 2007-11-22 Chockstone, Inc. Systems and methods for implementing parking transactions and other financial transactions
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
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
US8645273B2 (en) 2008-02-21 2014-02-04 The Coca-Cola Company Systems and methods for providing a vending network
US20090216675A1 (en) * 2008-02-21 2009-08-27 The Coca-Cola Company Commission Centric Network Operation Systems and Methods
US20090216665A1 (en) * 2008-02-21 2009-08-27 The Coca-Cola Company Systems and Methods for Providing Vending Network Data Management
US9460440B2 (en) 2008-02-21 2016-10-04 The Coca-Cola Company Systems and methods for providing electronic transaction auditing and accountability
US8121917B2 (en) * 2008-03-03 2012-02-21 The Coca-Cola Company Systems for implementing a loyalty program
US20090222300A1 (en) * 2008-03-03 2009-09-03 The Coca-Cola Company Systems and Methods of Marketing to Defined Consumer Groups
US8015088B2 (en) * 2008-03-03 2011-09-06 The Coca-Cola Company Methods for implementing a loyalty program
US9208485B2 (en) 2008-03-24 2015-12-08 American Express Travel Related Services Company, Inc. System and method for facilitating online transactions
US20110202462A1 (en) * 2008-09-08 2011-08-18 Mastercard International Inc. Method for a payment cardholder to control and manage the use of a payment card
US9230259B1 (en) 2009-03-20 2016-01-05 Jpmorgan Chase Bank, N.A. Systems and methods for mobile ordering and payment
US20100293017A1 (en) * 2009-05-18 2010-11-18 Contenture, Inc. Micropayment and website content control systems and methods
US20110238540A1 (en) * 2010-03-26 2011-09-29 Mastercard International, Inc. Financial account management based on specified criteria
US9846872B2 (en) 2010-04-06 2017-12-19 American Express Travel Related Services Company, Inc. Secure exchange of indicia of value and associated information
US9280689B2 (en) 2010-09-21 2016-03-08 Marvin T. Ling Method and apparatus for conducting offline commerce transactions
US20140337235A1 (en) * 2013-05-08 2014-11-13 The Toronto-Dominion Bank Person-to-person electronic payment processing
US9058626B1 (en) 2013-11-13 2015-06-16 Jpmorgan Chase Bank, N.A. System and method for financial services device usage

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020059114A1 (en) * 1998-11-29 2002-05-16 Michael P. Cockrill Electronic commerce using a transaction network

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5465206B1 (en) * 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
US5557516A (en) * 1994-02-04 1996-09-17 Mastercard International System and method for conducting cashless transactions
US5692132A (en) * 1995-06-07 1997-11-25 Mastercard International, Inc. System and method for conducting cashless transactions on a computer network
US5699528A (en) * 1995-10-31 1997-12-16 Mastercard International, Inc. System and method for bill delivery and payment over a communications network
US5704046A (en) * 1996-05-30 1997-12-30 Mastercard International Inc. System and method for conducting cashless transactions
US5995948A (en) * 1997-11-21 1999-11-30 First Usa Bank, N.A. Correspondence and chargeback workstation
US6330551B1 (en) * 1998-08-06 2001-12-11 Cybersettle.Com, Inc. Computerized dispute resolution system and method
US6315193B1 (en) * 1998-08-31 2001-11-13 Mastercard International Incorporated Financial transaction card with installment loan feature
US20020007302A1 (en) * 2000-03-06 2002-01-17 Work Bruce V. Method and apparatus for tracking vendor compliance with purchaser guidelines and related method for the commercial distribution of software and hardware implementing same
AU2000254223A1 (en) * 2000-06-22 2002-01-08 Trintrech Limited A transaction dispute management system and method
US10185936B2 (en) * 2000-06-22 2019-01-22 Jpmorgan Chase Bank, N.A. Method and system for processing internet payments
WO2002014973A2 (en) * 2000-08-11 2002-02-21 Cardis International Intertrust N.V System and method for micropayment in electronic commerce
CA2327935C (en) * 2000-12-08 2013-10-22 Wmode Inc. System and method to provide real time transaction validation and billing via a communications network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020059114A1 (en) * 1998-11-29 2002-05-16 Michael P. Cockrill Electronic commerce using a transaction network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1371002A2 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11093907B2 (en) 2002-01-15 2021-08-17 Jpmorgan Chase Bank, N.A. System and method for processing microtransactions
WO2008092010A2 (en) * 2007-01-28 2008-07-31 Bora Payment Systems, Llc Payer direct hub
WO2008092010A3 (en) * 2007-01-28 2008-09-12 Bora Payment Systems Llc Payer direct hub
US7676434B2 (en) 2007-01-28 2010-03-09 Bora Payment Systems, Llc Payer direct hub
US8521650B2 (en) 2007-02-26 2013-08-27 Zepfrog Corp. Method and service for providing access to premium content and dispersing payment therefore
US9076174B2 (en) 2007-02-26 2015-07-07 Zepfrog Corp. Method and service for providing access to premium content and dispersing payment therefore

Also Published As

Publication number Publication date
US7146344B2 (en) 2006-12-05
WO2002075499A3 (en) 2002-12-05
AU2002247375B2 (en) 2008-02-07
ZA200307302B (en) 2004-04-20
EP1371002A4 (en) 2008-01-30
EP1371002A2 (en) 2003-12-17
US20030033257A1 (en) 2003-02-13
CA2440682A1 (en) 2002-09-26
JP2004527038A (en) 2004-09-02

Similar Documents

Publication Publication Date Title
US7146344B2 (en) Method and system for making small payments using a payment card
US11880827B1 (en) Payment vehicle with on and off function
AU2002247375A1 (en) Method and system for making small payments using a payment card
JP2004527038A5 (en)
US8229848B2 (en) Secure networked transaction system
US20130006811A1 (en) Online funds transfer method
US20070175984A1 (en) Open-loop gift card system and method
US20020152124A1 (en) Methods and systems for remote point-of-sale funds transfer
US20050027655A1 (en) System and method for activating or changing the status of an account associated with a prepaid card
US11748726B1 (en) Disparate network systems and methods
US20180121975A1 (en) Providing security in electronic real-time transactions
US20050192892A1 (en) Automated clearing house compatible loadable debit card system and method
EP2409270A2 (en) Account activity alert
EP2382588A2 (en) System and method for providing dispute resolution for electronic payment transactions
US20190318354A1 (en) Secure electronic billing with real-time funds availability
US20030167226A1 (en) Method and system for improving fraud prevention in connection with a newly opened credit account
US20100161478A1 (en) Computer payment banking system and method
US8396792B1 (en) Dynamically specifying a merchant identifier in an electronic financial transaction
US11127017B2 (en) Enablement of enhanced authorization decisions of purchases including stored value products
WO2003042893A1 (en) Online payments
AU2005100221A4 (en) Credit card transaction processing
Lomas Amex offers card-based utility payments
AU2013263718A1 (en) Account activity alert

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC 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 OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM 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 GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC 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 OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM 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 GQ GW ML MR NE SN TD TG

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: 2440682

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2002247375

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2003/07302

Country of ref document: ZA

Ref document number: 200307302

Country of ref document: ZA

WWE Wipo information: entry into national phase

Ref document number: 2002715158

Country of ref document: EP

Ref document number: 2002574042

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 2002715158

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642