Classifications

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

Definitions

• the present invention relates generally to the field of financial transaction records and, more specifically, to method of, and merchant network equipment for, creating a transaction related record.
• the invention also relates to a method of, and transaction processing equipment for, processing a transaction between a purchaser and a merchant.
• a method of creating a transaction related record including: communicating selection data to a remote user terminal, the selection data providing a user with an option to select payment for a transaction from one of a credit card, a telephone, and a bank account; monitoring which particular account type the user selects; receiving account data associated with the particular account; and including the account data in a transaction record for communication to transaction processing equipment, the transaction record including an account type identifier that identifies the account type selected by the user.
• merchant network equipment which includes: a communication module to communicate selection data to a plurality remote user terminals via a communication network, the selection data providing a user with an option to select payment for a transaction from one of a credit card, a telephone, and a bank account, and receive account data associated with a particular account type which the user selects; and a processor module to include the account data-in a transaction record for communication to centralized transaction processing equipment, the transaction record including an account type identifier that identifies the account type selected by the user.
• a method of processing a transaction between a merchant and a purchaser including: receiving a transaction record from merchant network equipment; identifying from the transaction record an account type selected from the group including credit card, a telephone and a bank, account; creating a standard transaction record from the transaction record when the account type is a credit card account and a bank account; and communicating the standard transaction record to a credit card gateway when the selected account type is a credit card account and to an automatic clearing house (ACH) when the selected account type is a bank account.
• ACH automatic clearing house
• transaction processing equipment for processing a transaction between a merchant and a purchaser, the processing equipment including: a merchant communication module to receive a transaction record from merchant network equipment; a processor module to identify from the transaction record an account type selected from the group including credit card, a telephone and a bank, account and, create a standard transaction record from the transaction record when the account type is a credit card account and a bank account; and a financial service communication module to communicate the standard transaction record to a credit card gateway when the selected account type is a credit card account and to an automatic clearing house network (ACH) when the selected account type is a bank account.
• ACH automatic clearing house network
• the invention extends to a transaction processing system, which includes: merchant network equipment including: a user communication module to communicate selection data to a plurality remote user terminals via a communication network, the selection data providing a purchaser with an option to select payment for a transaction from one of a credit card, a telephone, and a bank account, and receive account data associated with a particular account type which the purchaser selects; and a processor module to include the account data in a transaction record which includes an account type identifier that identifies the account type selected by the user; and transaction processing equipment connected to the merchant network equipment via a communication network, the transaction processing equipment including: a merchant communication module to receive a transaction record from the merchant network equipment; a processor module to identify from the transaction record an account type selected by the purchaser and, create a standard transaction record from the transaction record when the account type is a credit card account and a bank account; and a financial service communication module to communicate the standard transaction record to a credit card gateway when the selected account type is a credit card account and to an automatic clearing house network
• Figure 1 shows a schematic block diagram of a prior art system for processing a transaction concluded via the Internet
• FIG. 3 shows a schematic block diagram of transaction processing equipment, in accordance to the invention.
• Figure 9 shows a schematic operational flow diagram of the transaction processing equipment
• Figure 10 shows a schematic block diagram of a validation system for validating a transaction requested by a purchaser to be billed to a telephone account
• Figure 11 shows a schematic flow diagram of the system of Figure 9
• Figures 12 to 14 show more detail schematic diagrams of certain steps of the flow diagram of Figure 11 ;
• Figure 15 shows a schematic operational diagram of the transaction processing equipment during a billing cycle for a particular transaction
• Figure 16 shows a schematic flow diagram of a billing process using a hybrid transaction record
• Figure 17 shows a schematic block diagram of computer equipment that may be used to implement the user terminal, merchant network equipment, and/or the transaction processing equipment.
• the merchant 22 first validates or checks whether or not the transaction can be processed by communicating with the bank validation gateway 28 or credit card validation gateway 30 and, if so, the merchant 22 may then obtain payment for the transaction via an appropriate bank 32.
• the merchant 22 is required to communicate a standard authorization record, either a standard credit card authorization record or a standard bank account authorization record, to a validation facility. Different records are thus communicated to different facilities dependent upon the particular payment method selected by the user.
• the merchant network equipment 42 communicates a choice of payment method screen layout 88 (see Figure 5) for display on the user terminal 52.
• the screen layout 88 includes a credit card button 90, a bank account button 92, and a telephone bill button 94. This may also include additional payment options not shown in this drawing such as Direct Bill, WebBill or the like.
• the purchaser may then select which particular account type he or she wishes to use to effect payment for the purchase and, dependent upon which particular button is activated, a further screen layout is provided by the merchant network equipment 42.
• a credit card information screen layout 96 (see Figure 6) is provided on the user terminal 52. The user then selects the particular type of credit card to be used, as shown at 98, and thereafter enters both credit card and billing address details as shown at 100. If, however, the user activates the bank account button 92 thereby selecting to effect payment by the bank account, a bank account detail screen layout 102 (see Figure 7) is provided on the user terminal 52. The user then enters the appropriate data into the fields as shown at 104.
• the merchant 50 Prior to finalizing any transaction, the merchant 50 typically requires validation of the particular account type that the user has selected to secure payment. Accordingly, the merchant 50 communicates a validation request, as shown by arrow 116 (see Figure 4) to the transaction processing facility 82.
• the request is in the form of the transaction record, as herein before described, which includes transaction type identification data as well as merchant identification data.
• the transaction processing facility 82 then, via its transaction processing equipment 44, investigates an appropriate facility, e.g., the credit card validation facility 54, the phone bill validation facility 56, the bank validation facility 58, the check validation facility 60 or the direct bill validation facility 62.
• an appropriate facility e.g., the credit card validation facility 54, the phone bill validation facility 56, the bank validation facility 58, the check validation facility 60 or the direct bill validation facility 62.
• the system 80 allows the merchant 50 to validate a transaction using a single transaction processing facility 82 which, in turn, performs the necessary validations.
• the transaction processing equipment 44 then communicates validation data, as shown by arrow 118, to the merchant network equipment 42 of the merchant 50.
• the merchant network equipment 42 then communicates an appropriate response to the user terminal 52 dependent upon whether or not the transaction has been validated. If the transaction has been validated, the transaction is then finalized between the merchant 50 and the purchaser and an appropriate communication is then forwarded to the transaction processing facility 82 to effect payment for the transaction, as described in more detail below
• An example of an HTTP validation request received by the transaction processing equipment 44 is as follows:
• the API 65 parses the transaction record an extracts the relevant identification data to determine the specific account type that the user has selected (see step 122). Once the account type has been identified (for example, 01 being for a telephone account, 04 being for a credit card account, and 05 being for an account requiring ACH type transaction), the API 65 extracts the telephone number associated with the subscriber line (ANI) unless a billing telephone number (BTN) is present in the record received from the merchant network equipment 42. The validation procedure is then carried out as shown at step 126 (see Figure 9). The transaction is then either approved or declined as shown in step 128 and an appropriate response is returned to the browser initiating the HTTP request at the merchant network equipment 42.
• ANI subscriber line
• BTN billing telephone number
• the API 65 detects that the user has in fact selected a credit card type account for payment for the transaction, in which the transaction indicator data includes the indicator 04, the API 65 parses the transaction record received and creates a standard credit card inquiry record which is communicated to a conventional credit card gateway or validation facility 54.
• the request received from the merchant network equipment 42 is also in the form of a HTTP request which includes identification data indicating that the request is for a credit card validation.
• the data including in the HTTP request is typically as follows:
• the API 65 converts an HTTP request, including indication data indicating the particular account type with which the request is associated, to a standard transaction record suitable for communication to the credit card validation facility 54 (see also Figure 2).
• the validation request communicated by the merchant network equipment 42 to the transaction processing equipment 44 includes details of an ABA/routing number as well as a bank account number.
• the record is as follows:
• the user has the option to select one of a plurality of different account types to effect payment for a transaction.
• the merchant network equipment 42 communicates a transaction record to the transaction processing equipment 44 which then performs the particular validation request.
• a validation response has been received from the credit card validation facility 54, the phone bill validation facility 56, or the ACH facility 58, an appropriate transaction record is then communicated using HTTP techniques to the merchant network equipment 42.
• a storage flag may be set to store account information associated with the user at the transaction processing facility 44 so that, in future transactions, an account identifier need only be sent to the transaction processing facility 44 thereby to enhance security of the account information.
• the transaction processing equipment 44 When responding to a validation request, the transaction processing equipment 44 typically includes a transaction record including the following fields:
• step 138 if the transaction is not approved then an appropriate response is returned to the merchant 50 (see line 140 and step 132).
• the transaction processing equipment 44 if instructed to do so via the storage flag, may store account data associated with the particular account type selected by the user.
• the transaction validation request generated by the merchant network equipment 42 includes a subscriber or user identification (Subid) and a unique key for mapping stored account data to the specific user, (see credit card specific validation request above).
• Subscriber or user identification Subscriber or user identification
• a unique key for mapping stored account data to the specific user see credit card specific validation request above.
• All-in-one billing record which may be provided at the merchant or at the transaction processing facility 82.
• direct communication 130 occurs and the customer management system is hosted at the transaction processing facility 82, then the billing cycles will be initiated at the transaction processing facility as follows: All-in-One Billing Record
• This file may be client provided or hosted at the transaction processing facility. If direct communication 130 occurs and the customer management system is hosted at the transaction processing facility, then the billing cycles will be initiated at the transaction processing facility 82.
• the process takes the key to identify the account information in the database at the facility 82. After that, the records are sent to the appropriate gateway for inclusion on the bill page.
• the all-in-one billing record defines a hybrid record in that, dependent upon its field values (which define a record type identifier), it may be associated with a plurality of different account types that are to be billed.
• An example of the different account types that may be billed is shown above. In particular, when the record includes a "01" field value then an account at a LEC is to be billed, a "02" field value then direct billing is to be carried out, "03" field value then web billing is to be effected, "04" then credit card processing is to be carried out, and "05” then ACH/check processing is to be carried out. It is to be appreciated that further field values may be included in other embodiments.
• the transaction processing facility 82 allows the merchant 50 to communicate a single record to a single facility which then processes the transaction.
• the transaction processing facility 82 may, via the credit card gateway 54, in a conventional fashion debit the appropriate credit card account at the bank 32, as shown by lines 150 and 152 in Figure 4.
• the bank 32 would then send an appropriate credit card statement to the user, as shown by line 154 who, in response thereto, is obliged to settle the account as shown by line 156.
• the transaction processing facility 82 pays the merchant 50 as shown by line 158 an amount equal to the transaction amount less a fee or commission, and the transaction processing facility 82 receives payment for the transaction in the full amount from the bank 32 as shown by lines 160 and 162.
• the transaction processing equipment 44 retrieves confidential account information from its database (see step 197) and processes the transaction as shown at step 198.
• the ACH transaction file may then, in a conventional fashion, be communicated to a secure FTP site.
• reference numeral 200 generally indicates a schematic block diagram of and exemplary validation module provided at the phone bill validation facility (which is typically provided at the transaction processing facility 82).
• the module 200 includes an application program interface (API) 201 that is connected to the transaction processing equipment 44.
• API application program interface
• the API 201 may be connected to a variety of different hosts or clients which require validation of a subscriber line via which the remote terminals 52 carry out transactions for goods and/or services via the Internet 26.
• the transaction processing equipment 40 communicates the telephone number of the subscriber line to the module 200 which then processes the information and provides a validation status, e.g. a code indicating a valid billable number or a code indicating that the line number is not a valid billable number (unbillable or non-billable).
• a validation status e.g. a code indicating a valid billable number or a code indicating that the line number is not a valid billable number (unbillable or non-billable).
• a plurality of codes associated with various statuses of the subscriber line is communicated to the transaction processing equipment 44 as described in more detail below.
• the processor module 202 then translates the validation response into an appropriate response that is communicated to the transaction processing equipment 44 for communication to the merchant 50 (see step 214).
• the CMS 72 updates purchase data, and creates an account for the user as shown in step 132.
• the API 201 communicates a display screen to the electronic terminal 52 that thanks the user for ordering the good and/or services.
• each transaction defines a billing that is recorded at the merchant 50 and, together with other billing events, is communicated to the transaction processing facility 82 at the end of a billing cycle (see step 218).
• the processor module 202 If the line number is in the OFFNET database 222, then the processor module 202 generates a plurality of codes (see step 272) and communicates these codes to the transaction processing equipment 44.
• the codes indicate that the NPA/NXX and OCN for the particular line number are not billable and, accordingly, charges for goods and/or services requested by the user cannot be included in a monthly telephone account by the module 200.
• the codes provide an indication to the transaction processing equipment 44 why the subscriber line is not billable or deliverable. If the subscriber line number is not included in the OFFNET database 222, a check is conducted to see whether or not the subscriber line number is included in the ONNET database 224. This check is however optional in the embodiment depicted in the drawings, but may be mandatory if the module 200 does not include the OFFNET database 222.
• the processor module 202 checks the RAO database 238 to ascertain whether or not the RAO is billable, as shown at step 300. If the RAO is not billable, then the processor module 202 generates and communicates a return code (see step 302) to indicate to the transaction processing equipment 44 that the line number belongs to a CLEC that is not billable by the module 200.
• the module 200 interrogates the ANI watch database 248 (see step 328) to ascertain whether or not the area code of the line number has been changed or is scheduled to change. This interrogation is typically for billing purposes only and is not used to decide upon the validity of the request.
• the transaction processing equipment 44 requesting the validation typically updates the billing file with the new area code number, and the processor module 202 generates a code (see step 330) to advise the transaction processing equipment 44 of the scheduled change to the area code.
• the local Telco typically sends the BNA and codes as to why the number is unavailable to the transaction processing facility 44. If the BNA is found in the CARE database 246, the processor module 202 then checks to see whether or not the account was created within the last 90 days as shown at step 342. If the account was not created within the last 90 days, then the business indicator is checked as shown at step 344 and the process ends as previously shown at step 346. If, however, the number was found in the CARE database 246, the account was created within the last 90 days, or has an active business indicator then the module 200 generates the appropriate codes that are communicated to transaction processing equipment 44 and the process terminates as shown at step 348.
• the transaction processing facility 82 processes all transactions during the cycle at the end of a bill cycle.
• Reference numeral 350 generally indicates an example of a telephone account billing process in which the merchant 50 communicates a billing transaction file in a all-in-one or hybrid format to the facility 82 (see step 352 in Figure 16).
• Each event or transaction in the transaction file includes an indicator or identification data to identify the particular account that it is related to, e.g. a telephone account, a credit card account, a bank account, or the like.
• the transaction processing system 44 of the facility 82 then receives the billing request file as shown at step 354, whereafter the request file is parsed, as shown at step 356, to identify only those transactions to billed to telephone accounts.
• the request file is also parsed by the processor module 64 to check whether or not all the required information is present in the file (see step 358). If not, a code is appended to the record as show at step 360. If all the information is present in the file, the process then proceeds to step 362 where the telephone account validation steps 208-214, as described above, are executed. Once the validation procedure has been completed, the BTN billing response is formatted into all- one-one format response with a response code appended to the end of each record and, the records are then returned to the CMS 72 (see step 366).
• EMI electronic message interface
• the EMI formatted file is then transferred to the Telco for billing as shown in step 368 whereafter the Telco call places each billing event on telephone account associated with the subscriber line(see step 370).
• the Telco returns any records that can not be billed to the telephone account or that have already been billed and credited, or written off because of non payment to the transaction processing facility 82 as shown at step 372.
• the records received by the facility 82 are in the EMI format and the facility 82 translates the record to an appropriate return record including a reason code appended to the record, as shown at step 372, whereafter record is returned to the CMS 72.

Landscapes

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

Applications Claiming Priority (3)

Publications (2)

Family

ID=27658643

Family Applications (1)

Country Status (4)

Families Citing this family (5)

Family Cites Families (4)

• 2003
  • 2003-01-30 WO PCT/US2003/003016 patent/WO2003065277A1/en not_active Application Discontinuation
  • 2003-01-30 CA CA002474663A patent/CA2474663A1/en not_active Abandoned
  • 2003-01-30 EP EP03707653A patent/EP1476838A4/de not_active Withdrawn
  • 2003-01-30 BR BR0307309-2A patent/BR0307309A/pt not_active IP Right Cessation

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events