WO2005124636A2 - Systeme et technique de traitement de transactions recurrentes - Google Patents

Systeme et technique de traitement de transactions recurrentes Download PDF

Info

Publication number
WO2005124636A2
WO2005124636A2 PCT/US2005/020623 US2005020623W WO2005124636A2 WO 2005124636 A2 WO2005124636 A2 WO 2005124636A2 US 2005020623 W US2005020623 W US 2005020623W WO 2005124636 A2 WO2005124636 A2 WO 2005124636A2
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
payment
recurring
invoice
recuning
Prior art date
Application number
PCT/US2005/020623
Other languages
English (en)
Other versions
WO2005124636A3 (fr
Inventor
Dean W. Hahn-Carlson
Kevin M. Armstrong
Original Assignee
U.S.Bancorp Licensing, 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
Priority claimed from US10/864,761 external-priority patent/US7925551B2/en
Application filed by U.S.Bancorp Licensing, Inc. filed Critical U.S.Bancorp Licensing, Inc.
Publication of WO2005124636A2 publication Critical patent/WO2005124636A2/fr
Publication of WO2005124636A3 publication Critical patent/WO2005124636A3/fr

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

Definitions

  • the present invention is directed to transaction processing and, more specifically, to the processing and management of recurring transactions involving goods and/or services.
  • BACKGROUND Transaction processing has typically involved intensive manual effort and, in instances where automatic processing has been used, intensive user intervention.
  • many transaction processes involve the use of a variety of different types of transaction documents such as orders, invoices, receipts and bills of lading (BOL).
  • BOL bills of lading
  • These types of transaction documents include infonnation associated with the transaction and used by parties to the transaction to monitor and process the transaction.
  • infonnation associated with the transaction and used by parties to the transaction to monitor and process the transaction.
  • Many of these and other types of transactions occur on a cyclic or other recurring basis, with elements to the transaction that repeat. While repetitive in nature, certain elements of transactions, such as delivery confirmation and payment, are typically addressed on an individual transaction cycle or period basis. Cyclic and other recurring transaction documents are electronically processed for a multitude of different types of applications.
  • Interaction data e.g., electronic or physical documents
  • Interaction data e.g., electronic or physical documents
  • parties to the transaction in addition to the common buyer and seller, such as shippers, financial institutions, distributors and regulatory agencies (e.g., customs, taxation agencies).
  • parties to the transaction in addition to the common buyer and seller, such as shippers, financial institutions, distributors and regulatory agencies (e.g., customs, taxation agencies).
  • Each of these parties often provides one or more different types of documents that relate to the transaction, and provides these documents at different times.
  • an invoice may be sent for a cyclic transaction prior to goods or services for the transaction being accepted.
  • the quantity of items for certain cyclic transactions widely vary over time, with associated changes in billing and inventory needing to be made.
  • Additional costs also arise as a result of existing inefficiencies in a variety of recurring transaction-processing approaches. Many of the costs are individually small, but very large in the aggregate. For example, typical parties to transactions incur administrative costs including those relating to creating and delivering transaction documents, resolving billing disputes, providing a signed copy of documents to other parties and posting accounts receivable. In addition, the cost of parsing, recognizing and categorizing documents related to these and other items add to the administrative costs of transactions. An additional challenge to transaction management is related to the inability to obtain immediate information regarding a transaction. Transaction data from one party is typically not readily available to other transaction parties without direct access to private- party systems.
  • recurring transactions are managed using an approach generally involving the use of transaction information for processing payment-related aspects of the recurring transactions.
  • cyclic or other recurring-type characteristics assigned to a particular transaction using data based rules are used to process transaction data.
  • transaction data is received, the data is associated with transaction data based rules using information received with the transaction data.
  • a transaction-processing system is adapted for managing a plurality of recurring transactions involving merchant offerings among parties including buyers and sellers.
  • the system includes a transaction databank arrangement that implements one or more data storage devices at one or more distinct locations and that is adapted to store information for recurring transactions between buyers and sellers.
  • the stored information generally includes data associated with conditions of the recurring transaction upon which payment is authorized or otherwise facilitated.
  • a transaction processor is adapted to receive transaction-based data from parties to a transaction and, for each particular recurring transaction, to associate transaction-based data with conditions of the recurring transaction upon which payment is authorized. Using the associated conditions, the transaction processor facilitates payment for each transaction.
  • the transaction processor further updates the transaction databank arrangement with billed quantities for the recurring transaction, reflecting a quantity or other characteristic of goods and/or services associated with the recurring transaction as indicated in the received transaction-based data.
  • a transaction- processing system processes recurring transactions involving merchant offerings among parties including buyers and sellers.
  • the system includes a transaction databank and a computer (processing) arrangement that interacts with the transaction databank for processing the transactions.
  • the databank implemented in a single or distributed arrangement, is adapted to store information for a plurality of recurring transactions between buyers and sellers.
  • the stored information includes data associated with conditions of each recurring transaction between a buyer and a seller and upon which conditions payment for invoices can be selectively authorized on behalf of the buyer for each transaction.
  • the computer arrangement is adapted to receive transaction data, audit payment of an invoice, authorize payment and update stored data for each particular recurring transaction.
  • the received transaction-based data generally pertains to buyer and seller parties participating in the particular recurring transaction, with information including conditions upon which payment for invoices can be selectively authorized for the particular recurring transaction, which is stored in the transaction databank.
  • the computer arrangement audits payment of an invoice for the particular recurring transaction as a function of data in the invoice and stored data that specifies conditions of the particular recurring transaction upon which payment can be authorized.
  • the computer arrangement authorizes payment as a function of the audit, e.g., in response to the audit indicating that the recurring transaction is ripe for payment (e.g., payment is not premature) and/or that payment is appropriate based on conditions such as the quantity or merchant offerings that are the subject of the payment.
  • data characterizing billed quantities for the recurring transaction are updated in the transaction databank arrangement to include a billed quantity in the invoice for which payment is authorized.
  • FIG. 1 shows a transaction processing arrangement, according to an example embodiment of the present invention
  • FIG. 2 is a flow diagram showing an approach for recurring transaction management, according to another example embodiment of the present invention
  • FIG. 3 is another flow diagram for the management of cyclic transaction data, according to another example embodiment of the present invention
  • FIG. 4 is a block diagram showing a storage arrangement for storing and processing cyclic transaction information, according to another example embodiment of the present invention.
  • a transaction management system uses stored recurring transaction information to manage a transaction involving the exchange of merchant offerings (e.g., goods and/or services) between a buyer and a seller. Payment for the transaction is automatically audited and authorized as a function of the stored recurring transaction information.
  • merchant offerings e.g., goods and/or services
  • invoice-type data Upon receipt of invoice-type data (e.g., via an electronic document or other data transfer approach), the invoice-type data is parsed and associated with a particular recurring transaction.
  • the invoice-type data may be generated, for example, by a party to the transaction or automatically (e.g. , by the transaction management system) as defined by programming and stored recurring transaction rules.
  • Item quantities such as goods and/or services associated with the invoice- type data are compared with stored recurring transaction characteristics to determine a payment-related condition.
  • the payment-related condition is then used to determine whether the payment should be made and/or whether conditions relating to the payment such as timing and amount (known and/or estimated) should be taken into consideration.
  • the transaction management system can be programmed to automatically authorize payment (partial or full) for the transaction when the payment-related condition meets selected criteria. If an invoice is premature (i.e., before a contracted payment date), the invoice can be stored for processing once the payment matures.
  • the transaction management system is configured to manage term characteristics of the recurring transaction. For example, the life and frequency of a particular recurring transaction can be managed using fixed and/or variable type data. Fixed data relating to specific times or time periods can be programmed into the transaction management system.
  • Variable data such as conditions life or term related data can also be programmed into the transaction management system (e.g., the life of a recurring transaction expires after a selected quantity of goods and/or services are rendered).
  • transaction events such as a payment initiation event or payment termination event can be used to trigger term characteristics of the transaction. For instance, where a particular recurring transaction is to be carried out on a specified cycle for a set time period, a payment initiation event can be used to start the time period.
  • a payment initiation event can also be used to start other functions, such as tracking functions for quantity of goods and/or services rendered.
  • Payment termination events can similarly be used to trigger other term characteristics of the transaction, such as by ending the transaction with a payment termination event.
  • a payment flagged as a final payment, or a payment that results in a total amount for a particular transaction having been satisfied, such as for a loan can be used as an indication that a particular transaction should be ended.
  • payment is authorized in accordance with one or more conditions of delivery.
  • the condition(s) of delivery may include, for example, conditions relating to the physical receipt of the goods by a buyer and/or the acceptance/rejection of the goods by a buyer.
  • payment can be authorized as a function of a certain percentage of the items pertaining to the transaction being delivered as indicated on an invoice.
  • the transaction management system authorizes payment when stored recurring transaction information for the transaction associated with the invoice indicates that delivery has been perfected in a manner consistent with the condition of delivery.
  • the transaction management system automatically generates an invoice in response to receiving confirmation of delivery in accordance with conditions of delivery sufficient to authorize payment.
  • payment is authorized as a function of timing characteristics associated with the particular recurring transaction. For example, parties to the recurring transaction may agree on a particular payment relationship involving the payment for goods/services at a specified time after performance, or on a particular date for outstanding balances.
  • timing characteristics are related to the performance of the transaction, such as a time of delivery or service.
  • the amount of payment for the recurring transaction may be predicated by the timing of delivery of goods for the transaction (e.g., with longer delivery times resulting in lower payment).
  • the timing of the performance of a recurring service transaction may be predicated by the date that the service is performed.
  • performance characteristics relating to the transactions can be tied to payment.
  • a recurring transaction involving a fixed payment is managed with a transaction management system.
  • Transactions to which this approach is amenable include, for example, rental contracts for building space, lease contracts for equipment or automobiles, insurance contracts, service contracts and more.
  • a transaction management system stores characteristics of a recurring transaction for a particular party to a transaction and automatically manages the payment of fees associated with the recurring transaction.
  • invoices are automatically generated.
  • invoices received are automatically paid.
  • invoices and payments are automatically processed by the transaction management system.
  • a variable payment approach is used in another implementation, where recurring transaction rules are used to audit invoice-type data in order to authorize an indicated payment.
  • Parties to a transaction agree upon and store transaction-based rules at a transaction management system. These rules include information that can be used by the transaction management system to evaluate a particular payment amount.
  • the recurring transaction rules associated with the parties to the transaction for which the invoice-type data is generated are used to determine whether a payment can be made and, in some applications, when the payment is to be made.
  • the recurring transaction rules include tolerance (e.g., percentage) information, where payments within a particular range of a target value can be automatically authorized. For example, where a recurring transaction is a utility transaction for heating gas, a target value can be programmed into the transaction management system.
  • This target value can also be tailored to a particular month of the year, with heating-season months generally having a higher target value than non-heating season months.
  • Information used to set the target value may be based on historical data, such as heating gas usage in a previous year, current heating gas prices and average temperature conditions.
  • Recurring transaction rules can be made to automatically approve heating gas invoices within a particular range (e.g., 10%) of target value.
  • the billed amount on a heating gas invoice is processed to determine whether it is within range of a particular target value, with the target value optionally being set using one or more of the above conditions. If the amount billed is within range, the transaction management system automatically authorizes payment. If the amount billed is out of range, payment is not authorized.
  • the transaction management system is programmed to pay up to an authorized amount for an out-of range bill. In other instances, the transaction management system is further optionally programmed to automatically flag the invoice-type data for follow-up to determine whether the out of range portion of the bill can be paid.
  • the transaction management system interacts with one or more financial institutions for effecting payment. In this regard, the transaction management system uses recurring transaction data for parties to a transaction to determine a condition of payment for a transaction as discussed above. Rules regarding a relationship between a financial institution and a party (e.g., buyer) to the transaction are the used to authorize payment from the financial institution, on behalf of the party to the transaction, to another party (e.g., seller) to the transaction.
  • the financial institution automatically pays a seller on a cyclic basis as defined by parties to the transaction and in relation to a cyclic nature of goods and/or services pertaining to the transaction. For example, payment from a financial institution to a seller for a cyclic transaction can be effected on a calendar basis (e.g., the 1 st of each month) using the transaction management system to trigger payment. The financial institution then collects payment from the buyer in one or more of a variety of manners, using the transaction management system or otherwise. In addition, the financial institution can pay multiple sellers in this manner for a particular buyer, with the buyer correspondingly making a single payment to the financial institution for all payable amounts based on the cyclic transaction.
  • the transaction management system automatically categorizes components of recurring transactions into expense type categories for the buyer for whom payment is being authorized. For instance, where a recurring transaction involved the purchase of goods and services relating to different types of business expenses, the transaction management system not only manages the recurring nature of the transaction, it also automatically categorizes components of each recurring transaction into expense-related categories.
  • the transaction management system not only manages the recurring nature of the transaction, it also automatically categorizes components of each recurring transaction into expense-related categories.
  • recurring interactions are managed using an approach that facilitates automatically processing certain interaction data as a function of common characteristics of the data.
  • Interaction data from two sources e.g., two documents
  • common data that is found in both sources is used to define a particular interaction category. Additional sources bearing the common data are thus grouped into the particular interaction category.
  • recurring attributes are managed and monitored, with recurring transactions being used to automatically update related transaction data.
  • interaction data is automatically categorized into groups that can be used to identify documents and other interaction data that belongs to a particular interaction.
  • FIG. 1 shows a transaction processing arrangement 100, according to another example embodiment of the present invention.
  • the transaction processing arrangement 100 includes a transaction processor 110 having a recurring transaction engine 115 that is configured for processing recurring transaction information and, in some applications, for generating the recurring transaction information on a selected basis.
  • the transaction processor 110 is coupled to a database 112 that is used to store information, including recurring transaction rules 113 and transaction party profile data 114, used by the transaction processor 110 and the recurring transaction engine 115 for processing recurring transactions.
  • the database 112 is selectively implemented using one or more data storage arrangements, which may be located at common or distinct locations and coupled via a network or other communications link.
  • a plurality of user nodes 120, 122, 124, 126 and 128 are communicatively coupled to the transaction processor 110 for passing transaction-related information.
  • the user nodes include one or more of a variety of transaction parties related to a transaction, such as buyers, sellers, shippers, carriers, financial institutions and regulatory entities.
  • the user nodes are implemented as follows: user nodes 120-N represent buyers, 122-N represent sellers, 124-N represent seller financial institutions, 126- N represent buyer financial institutions and 128 represents an administrator that manages and otherwise operates the transaction processor 110.
  • the recurring transaction engine 115 is programmed to employ the recurring transaction rules 113 stored in the database 112 and/or at one of the user nodes 120-128 to automatically determine a payment-related condition of transactions, such as that related to invoice-type data received via, or generated on behalf of, one of the sellers 122-N.
  • the recurring transaction engine 115 determines whether payment for a recurring transaction is appropriate for a variety of transactions, such as in connection with one or more of the above-discussed approaches to the management and processing of recurring transactions.
  • the recurring transaction engine 115 automatically associates the payment- related data with one or more of the buyer (120-N) and seller (122-N) parties associated with the transaction using the transaction party profile data 114 in the database 112.
  • the recurring transaction engine 115 associates the transaction data with the buyer and seller.
  • recurring transaction rules 113 for one or more of the buyer, seller and transaction therebetween are implemented by the recurring transaction engine 115 to audit the transaction data for authorizing payment therefor.
  • Payment authorization is thus generally based upon user-defined rules that are stored with the recurring transaction rules 113.
  • the recurring transaction rules 113 specify, for a particular transaction, that payment-related data be compared against stored recurring transaction data to determine a condition relating to the payment for goods and/or services that are the subject of the recurring transaction. If certain conditions (e.g., quantity delivered, approval of delivered goods, percentage of services performed) are met, the recurring transaction engine 115 authorizes payment. If these certain conditions are not met, the recurring transaction engine 115 does not authorize payment.
  • a payment processor 116 uses the authorization to facilitate payment to the seller 122 on behalf of the buyer 120 using transaction party profile data 114 and/or recurring transaction rules 113 applicable to one or both of the buyer and seller.
  • Facilitating payment involves one or more of a variety of functions, depending upon the application; such functions include, for example, one or more of transferring funds, extending credit and sending payment authorization.
  • the payment processor engine 116 initiates the payment.
  • an amount of credit available to the buyer is made available via the profile data and used to determine a condition of payment (or ability to pay).
  • the payment to the seller financial institution 124 is made directly from the buyer financial institution 126 or, in some applications (e.g., as programmed at the transaction processor 110), to the administrator 128, which in turn sends payment to the seller financial institution 124.
  • one or more of the financial institutions 124-N and 126-N have profile information stored with the transaction party profile data 114 and used by the payment processor 116 to interact therewith for facilitating payment. In other applications, one or more of the financial institutions 124-N and 126-N do not have profile information stored in the database 112, but do have sufficient information stored with particular buyer and/or seller profiles in the database 112 for use by the payment processor 116 in facilitating payment.
  • a fee processor 117 assesses a fee against one or more transaction parties, on behalf of the administrator 128, for processing the recurring transactions. These fees are assessed, for example, as a function of a transaction amount (e.g.
  • the fee processor 117 assesses a fee against the seller 122 (or, if selected, the buyer 120) for processing the transactions, with the fee reflecting each recurrence of the recurring transaction.
  • the recurring transaction engine 115 processes payment-related conditions that are generated by the recurring transaction engine 115 at the direction of buyer and seller parties engaging in the recurring transaction.
  • the recurring transaction rules 113 for the recurring transaction specify these terms.
  • the recurring transaction engine 115 automatically generates a payment authorization on the first of each month, in the specified amount, every month for a year.
  • the authorization for the payment may specify that the buyer 120 must agree to the payment before it is made, such that the recurring transaction engine 115 generates a payment authorization on the first of the month, in response to an agreement received from the buyer 120.
  • a variety of such payment-related conditions are thus specifiable by parties to transactions processed by the transaction processor 110, as stored in the recurring transaction rules 113 and used to initiate and/or authorize payment for a recurring transaction.
  • the database 112 can be used to store transaction-related data that can be tailored for characteristics of specific transactions.
  • the stored transaction-related data may include, for example, transaction party profile data 114 that specifies the identity of parties to the transaction.
  • the recurring transaction rules 113 may specify the identity of the transaction (e.g., transaction-specific number, loan number, and account number), beginning and/or ending payment dates and fixed or flexible payment amounts.
  • processing data such as that used for determining what criteria is sufficient for authorizing payment and for notification of payment-related timing characteristics (e.g., notice of service acceptance) is selectively stored with the recurring transaction rules 113.
  • data for each recurring transaction served by the database can be stored accordingly having data of a specific recurring nature as identified, for example, by timing and processing characteristics.
  • the transaction processor 110 is adapted to automatically exchange data with one or more user nodes, with authorization data being used to control information access at one or both of the transaction processor and the user node(s).
  • the transaction processor 110 can access remote data sources at one or more of the user nodes 120 - 128.
  • Program information stored at the database 112 is used for extracting information from remote data sources. Extracted information includes, for example, payment-related conditions for recurring transactions, payment initiation information, payment termination information and/or merchant offerings provided to a buyer.
  • a comparison and/or other processing approach involving the extracted information is selectively implemented for auditing aspects of and/or facilitating payment for the transaction.
  • the transaction processor 110 selectively interacts with the processor at the user node 120 to retrieve information stored at the data source.
  • a user a user node 120 can, with proper programming and access authorization, access the database 112 via the transaction processor 110 for retrieving, changing and/or storing data, when a request for such access matches information stored with the transaction party profile data 114.
  • one or more of the user nodes 120-128 includes a user interface configured for receiving infonnation that can be used for interacting with the transaction processor.
  • the user interface may be generated at the user node (using, e.g., an application program), or generated by the transaction processor 110 and accessible by users at the user nodes via a network such as the Internet.
  • the user interface facilitates the exchange of information, such as requests for reports, the storage of profile or transaction rule information in the database 112, or data relating to the provision of an invoice.
  • a variety of transaction events can be used in initiating payment for a particular recurring transaction, depending upon the particular application. These payment initiating events are stored with the recurring transaction rules 116 in the database 112 and implemented by the recurring transaction engine 115 to initiate a payment request (e.g., to facilitate the processing of a received or generated invoice).
  • One such example transaction between the buyer 120 and the seller 122 has a monthly payment cycle, with the transaction event being the first day of each month.
  • the recurring transaction engine 115 facilitates the initiation of a payment request.
  • the recurring transaction rules 116 simply indicate that payment is to be made in a particular amount on the first of the month.
  • the recurring transaction rules 116 specify that payment can be made on the first of the month, when certain other criteria are met. Such criteria include, e.g., the seller 122 providing an invoice, the buyer 120 approving an invoice, the buyer acknowledging the receipt of goods and/or services, or an invoice matching, or falling within a particular tolerance of, a predefined amount.
  • FIG. 2 is a flow diagram showing an approach for cyclic transaction management, according to another example embodiment of the present invention. The approach shown in FIG. 2 may be implemented, for example, in connection with the transaction processing anangement 100 shown in FIG. 1.
  • cyclic accounting profile attributes are stored for a plurality of transaction parties such as buyers, sellers and financial institutions via which payment for transactions between buyers and sellers is transferred. These cyclic accounting profile attributes are stored in a database anangement.
  • Cyclic transaction events are generated using the stored cyclic accounting profile attributes at block 220. These accounting profile attributes may specify, for example, conditions upon which a transaction event such as a payment initiation is generated (e.g., a date, the receipt of a particular set of data from a transaction party such as a receipt for goods and/or services, or quantity data indicating that a particular item is below a specified level and reorder is appropriate).
  • a transaction event such as a payment initiation is generated
  • the transaction database is parsed to identify received items conesponding to the invoice. That is, where an invoice specifies a particular item for which payment is requested, the database is parsed to identify conesponding items.
  • a payable condition for the invoice at block 240 i.e., items for which payment is requested on the invoice have been delivered
  • payment for the invoice is authorized at block 250.
  • a payment field is updated to reflect the payment for the received items in the database. If the received items as indicated in the database do not indicate a payable condition for an invoice at block 240, the invoice is placed into a not-payable status at block 260. Such a not-payable status is generally maintained together with the invoice data until such time as the invoice becomes payable.
  • the status of the received items as stored in the database is monitored at block 270 and, when the received items indicate a payable condition for the invoice at block 240, payment is facilitated at block 250 as discussed above.
  • payment for a partial amount of items (or services) indicated on an invoice is facilitated at block 250, with payment for other items placed in a not-payable status at block 260.
  • an invoice specifies an amount that covers more than an amount of goods received for a particular transaction
  • payment for a received portion of the goods is facilitated while payment for goods that have not been received is delayed until the receipt thereof.
  • an invoice specifies payment for more than one recunence in a recuning transaction
  • payment can accordingly be authorized as a function of each recurrence happening (i. e. , in response to the delivery of goods and/or services corresponding to a particular recunence).
  • a particular recurring transaction specifies that a seller is to deliver a set amount of a particular good on the first of each month for one year
  • a single invoice from the seller can be used to facilitate payment for the transaction.
  • delivery of each recunence is reflected in received item data in the database, payment for that recurrence is authorized while payment for any remaining recurrences is withheld.
  • FIG. 3 is another flow diagram showing an approach to the management of recuning transaction data, with recurring data of a cyclic nature discussed by way of example, according to another example embodiment of the present invention.
  • the approach shown in FIG. 3 may be implemented, for example, in connection with the transaction processing anangement 100 shown in FIG. 1, for storing and/or updating information such as the recurring transaction rules 113 or other transaction-specific quantity, price or recunence data, stored in the database 112.
  • transaction data having cyclic transaction identification information is received and cyclic transaction data fields (e.g., stored in a database) are parsed for data that matches the received data at block 320.
  • the identification information includes, for example, buyer or seller identification numbers, a transaction identification number or other information that can be used for associating the transaction data with a particular transaction. If the cyclic transaction identification information does not match stored cyclic transaction data in the data fields at block 330, the process stops at block 340. If there is such a match at block 330, but an update to the stored cyclic transaction information is not allowed (e.g., if the information received at block 310 does not have proper authorization or if access to the stored information is somehow restricted) at block 350, the process stops at block 340. If there is a match at block 330 and updates are allowed at block 350, the stored cyclic transaction data is updated at block 360 with the transaction data received at block 310.
  • FIG. 4 is a block diagram showing a storage anangement 400 for storing and processing recurring transaction information, according to another example embodiment of the present invention.
  • a central processor 410 interacts with users 402 via a communications node 405 for receiving and storing transaction data upon which transactions are processed, for receiving information indicating a payment event, for facilitating payment for transactions or for interacting with a variety of users in the facilitation of recurring transactions.
  • interactions with users 402 via the communications node 405 may involve direct users such as buyers and sellers or indirect users such as financial institutions.
  • the user interaction involves initial interaction for establishing rules or profile information.
  • the user interaction also typically involves the generation and/or communication of invoice data for recurring transactions.
  • the user interaction also involves the communication of updates for updating stored information, of receipts to acknowledge receipt of goods and/or services or of information such as stock quantity that can be used in processing recurring transactions.
  • the central processor 410 controls the storage of and access to recurring transaction data at storage locations 420, 430, 440 and 450.
  • the storage location 420 is used to store profile information for transaction parties, as applicable to different transactions in which the parties are involved.
  • Each of the storage locations 430-450 is assigned to a particular recurring transaction, with data associated with the particular recurring transaction stored therewith, and including information specifying one or more profiles, in the storage location 420, that apply to the particular recurring transaction.
  • the data stored in the cyclic transaction data storage locations 430-450 generally includes sufficient information for facilitating payment for recunences of a particular cyclic transaction, such as information identifying a recuning date or other event at which payment is to be processed, as well as data identifying parties and, ultimately, payment conditions.
  • other cyclic transaction data such as order amounts, thresholds, stock levels and others as discussed herein are stored with the cyclic transaction data storage locations 430-450.

Landscapes

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

Abstract

La présente invention a trait à un système permettant de faciliter des interactions basées sur des transactions à l'aide de techniques de traitement de transactions récurrentes. Selon un mode de réalisation représentatif de la présente invention, des transactions récurrentes sont gérées au moyen de règles applicables aux participants à la transactions (par exemple, par association automatique aux transactions récurrentes en fonction d'une information dans les transactions et les règles). Dans ce contexte, l'information de transaction est traitée selon des règles caractérisant la nature récurrente de la transaction à laquelle l'information s'applique. Une telle récurrence de transactions peut être mise en oeuvre, par exemple, grâce à l'utilisation d'une condition cyclique, entraînée par un événement ou d'un autre type récurrent. Des aspects associés aux paiements de la transactions sont également effectués en fonction du traitement de transaction et de caractéristiques récurrentes associées.
PCT/US2005/020623 2004-06-09 2005-06-09 Systeme et technique de traitement de transactions recurrentes WO2005124636A2 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US57842904P 2004-06-09 2004-06-09
US57868904P 2004-06-09 2004-06-09
US60/578,429 2004-06-09
US10/864,761 2004-06-09
US10/864,761 US7925551B2 (en) 2004-06-09 2004-06-09 Automated transaction processing system and approach
US60/578,689 2004-06-09

Publications (2)

Publication Number Publication Date
WO2005124636A2 true WO2005124636A2 (fr) 2005-12-29
WO2005124636A3 WO2005124636A3 (fr) 2006-03-16

Family

ID=35510406

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/020623 WO2005124636A2 (fr) 2004-06-09 2005-06-09 Systeme et technique de traitement de transactions recurrentes

Country Status (1)

Country Link
WO (1) WO2005124636A2 (fr)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5920847A (en) * 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
US20010032183A1 (en) * 1994-06-03 2001-10-18 Midwest Payment Systems, Inc. System and method for paying bills and other obligations including selective payor and payee controls
US20020087344A1 (en) * 2000-10-24 2002-07-04 Billings Sarah T. System and method for collecting information to facilitate enrollment in an electronic funds transfer program
US20030233321A1 (en) * 2001-11-30 2003-12-18 Scolini Anthony J. Integrated invoice solution
US20030233292A1 (en) * 2002-06-13 2003-12-18 Visa U.S.A., Inc. Method and system for facilitating electronic dispute resolution
US20040191711A1 (en) * 2003-03-28 2004-09-30 Watson Eric Kent Systems and methods for controlling gas flow
US20050234820A1 (en) * 2004-04-16 2005-10-20 Mackouse Jack System and method for bill pay with credit card funding

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5920847A (en) * 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
US20010032183A1 (en) * 1994-06-03 2001-10-18 Midwest Payment Systems, Inc. System and method for paying bills and other obligations including selective payor and payee controls
US20020087344A1 (en) * 2000-10-24 2002-07-04 Billings Sarah T. System and method for collecting information to facilitate enrollment in an electronic funds transfer program
US20030233321A1 (en) * 2001-11-30 2003-12-18 Scolini Anthony J. Integrated invoice solution
US20030233292A1 (en) * 2002-06-13 2003-12-18 Visa U.S.A., Inc. Method and system for facilitating electronic dispute resolution
US20040191711A1 (en) * 2003-03-28 2004-09-30 Watson Eric Kent Systems and methods for controlling gas flow
US20050234820A1 (en) * 2004-04-16 2005-10-20 Mackouse Jack System and method for bill pay with credit card funding

Also Published As

Publication number Publication date
WO2005124636A3 (fr) 2006-03-16

Similar Documents

Publication Publication Date Title
US8762238B2 (en) Recurring transaction processing system and approach
US8650119B2 (en) Order-resource fulfillment and management system and approach
US8751337B2 (en) Inventory-based payment processing system and approach
US8595099B2 (en) Financial institution-based transaction processing system and approach
US8712884B2 (en) Transaction finance processing system and approach
US7970671B2 (en) Automated transaction processing system and approach with currency conversion
AU2005255453B2 (en) Financial institution-based transaction processing system and approach
US20050278255A1 (en) Transaction data exchange system and approach
US10127558B2 (en) Expense tracking, electronic ordering, invoice presentment, and payment system and method
AU2007221878B2 (en) Transaction finance processing system and approach
WO2005124636A2 (fr) Systeme et technique de traitement de transactions recurrentes
AU2008200560B2 (en) Financial institution-based transaction processing system and approach

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 BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase in:

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase
DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)