US20090144194A1 - Computer automated systems, devices and methods for data processing of accounting records - Google Patents

Computer automated systems, devices and methods for data processing of accounting records Download PDF

Info

Publication number
US20090144194A1
US20090144194A1 US12/131,597 US13159708A US2009144194A1 US 20090144194 A1 US20090144194 A1 US 20090144194A1 US 13159708 A US13159708 A US 13159708A US 2009144194 A1 US2009144194 A1 US 2009144194A1
Authority
US
United States
Prior art keywords
buyer
payment
transaction
accounts
account
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12/131,597
Inventor
Mark Dickelman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
US Bank NA
Original Assignee
US Bank NA
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 US Bank NA filed Critical US Bank NA
Priority to US12/131,597 priority Critical patent/US20090144194A1/en
Assigned to U.S. BANK NATIONAL ASSOCIATION reassignment U.S. BANK NATIONAL ASSOCIATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DICKELMAN, MARK
Publication of US20090144194A1 publication Critical patent/US20090144194A1/en
Priority to US15/089,780 priority patent/US9881131B1/en
Abandoned legal-status Critical Current

Links

Images

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/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • G06Q20/204Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
    • 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/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • 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/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • 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/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • G06Q20/202Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
    • 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

Definitions

  • This invention relates generally to computer-automated devices, systems and methods relating to data processing involving accounting records, and as an example, to systems and methods for automated computer systems and networks implemented as may be found in a control center of a financial institution.
  • Accounting data can include data relating and leading up to implementations of payment systems and associated networks. More and more transactions are accomplished without direct payment (e.g., cash) from the buyer to the merchant/seller.
  • these associated networks involve two primary components.
  • the first component is a seller access network (e.g., Nova®) that provides connection to the point-of-sale (POS) devices (either directly or via merchant internal networks) and identification of the type of payment account (e.g., Visa® or Voyager®).
  • POS point-of-sale
  • a second component includes payment processing networks that process payment instructions based on established agreements by the participants.
  • these payment processing networks are one of two different categories, proprietary networks (e.g., Voyager®) or association networks.
  • association networks include the networks provided by VISA® and MASTERCARD® and/or the particular acquiring/issuing banks.
  • VISA® and MASTERCARD® the networks provided by VISA® and MASTERCARD® and/or the particular acquiring/issuing banks.
  • the operator of the association network controls the flow of funds for the transaction. Often, this includes a fee that is passed on to the seller, such as a percentage of the transaction.
  • the participating sellers have an agreement with the network (e.g., VISA or MASTERCARD), but do not have a transactional relationship between one another with respect to the association network transactions.
  • Such transactions are often implemented where the seller has an existing relationship with a bank.
  • the seller sends the transaction information to this bank, sometimes referred to as the acquiring bank.
  • the acquiring bank can forward the payment information to a bank that issued the card, sometimes referred to as the issuing bank.
  • the payment processing networks assign interchange fees that are paid between the parties based on the type of transaction, authentication and location. These fees may be passed on to the seller.
  • An example of a proprietary network is a merchant-provided in-store credit or debit account.
  • the seller or a seller contracted third party, handles the settlement, authorization and/or other functions associated with a transaction.
  • the seller can form bilateral agreements with other sellers to allow use of one network by multiple sellers or to coordinate use of multiple networks between multiple sellers.
  • the sellers establish the bilateral agreements with one another to allow such functionality. For instance, two department stores may allow use of the same proprietary network card at either store or they may allow use of two different proprietary network cards (i.e., one from each store) at either store.
  • a few networks allow for a single (multi-purpose) card to provide access to more than one account.
  • the card interfaces with a network that would otherwise support one or more of the accounts.
  • the cardholder designates a desired account to use.
  • the transaction is processed as if the card associated with the desired account had been used.
  • the underlying transactional functions operate in much the same manner as if the original card had been used.
  • the buyer must still carry the multi-purpose card for use and can only use the multi-purpose card at locations that support that particular card.
  • the present invention involves a financial control center that processes data in response to a purchase transaction in which a plurality of data-identifiable items (i.e., merchant offerings such as goods and/or services) are purchased over a payment network.
  • the payment network interfaces with a computer-operated arrangement and one or more financial institutions that oversee different buyer accounts.
  • the control center accesses information about buyers (and in some instances, sellers also) involved in the purchase transaction and their accounts which might be adjusted (e.g., debited) in consideration of the data-identifiable items involved in the transaction.
  • the payment network determines whether the buyer has sufficient funds or credit to cover the transaction amount.
  • a buyer account is (e.g., actually or effectively) debited for the transaction amount, and the seller is credited for the transaction amount.
  • a payment parser examines the transaction data to parse items according to other buyer accounts for debiting. The associated buyer accounts are debited for the values of the associated items and the corresponding amounts are credited to the originally debited buyer account.
  • transaction data about a plurality of items (e.g., goods or services) purchased is provided to a payment network along with buyer and/or seller credentials/identification data.
  • a payment parser examines the transaction data to parse items according to other buyer accounts for debiting.
  • the associated buyer accounts are debited for the value of the associated items and any remaining amount can be debited to a default buyer account.
  • the payment parser determines whether a particular transaction item qualifies for specific accounts.
  • the account may have requirements on the types of transactions that can be debited (e.g., due to favorable tax treatment of the account).
  • the account is a medical account for which only medically related items qualify.
  • Example medical accounts include insurance accounts and health savings accounts (HSAs).
  • buyer and/or seller credentials/identification data is provided to a payment network.
  • the transaction can optionally be completed using transfers between accounts held within the same payment network.
  • a disparate network system can process the transaction.
  • the credential does not explicitly identify the buyer and seller as participants in a common payment network, the system can determine that the buyer and seller have an account on a supported payment network.
  • a common settlement mechanism can be identified allowing for transfer of funds between buyer and seller accounts on disparate networks.
  • a system facilitates payment between sellers providing goods or services to buyers paying for the goods or services.
  • the payment is provided between disparate payment networks of the buyers and sellers.
  • An interface receives transaction data.
  • the transaction data can include various different types of information, such as a buyer identifier, a seller identifier, a transaction amount, transaction time, transaction type and location of transaction.
  • a payment network selector receives the transaction data from the interface.
  • the payment network selector uses the received transaction data to select a payment network for one of the buyer and seller as a function of respective profile data.
  • a routing arrangement routes at least a portion of the transaction data to the selected payment network and another portion of the transaction data to a disparate payment network. Consistent with the transaction amount, an account held at the selected payment network is either debited or credited and an account held at the disparate payment network is the other of debited or credited.
  • a system executes payment for transactions between buyers and sellers using profile data that identifies payment accounts and corresponding payment networks available to the buyers and sellers.
  • a transaction interface arrangement receives a transaction request for a transaction between a seller and a buyer.
  • the transaction request includes a buyer identifier, a seller identifier and a transaction amount.
  • An authorization processor that, for the received transaction request, authorizes the transaction by verifying that transaction request meets stored business rules.
  • a payment processor selects at least one of at least two available payment processing networks for use in providing funds for the transaction request using preferences for at least one of the seller and the buyer.
  • a routing arrangement routes payment information regarding the transaction request to the at least one selected payment processing network.
  • a method for facilitating payment between buyers and sellers. For each of a plurality of electronic payment requests received from sellers, a number of steps are implemented. Data contained in the request is used to identify a consumer/buyer and a seller. At least one of at least two available payment processing systems are selected for use in providing funds for the payment request using preferences for at least one of the consumer and the seller. Payment to the seller and collection from the buyer are provided as a function of the at least one selected payment processing system.
  • a method for executing payment for transactions between consumers and sellers. For each of a plurality of payment requests received from sellers, a number of steps are implemented. Data from the request is used to identify a consumer and seller. Payment is effected to the seller on behalf of the buyer. Specifically, a buyer payment method is identified for providing funds for the payment request as a function of buyer profile information; a seller payment method is identified for providing funds to the seller as a function of seller profile information, and payment to the seller and collection from the buyer are facilitated as a function of the selected buyer and seller payment methods.
  • a payment system executes payment in an environment involving mobile device users, mobile carriers and financial processing entities.
  • the system uses profile data that characterizes mobile service criteria and financial-account criteria for each mobile device user.
  • a seller interface arrangement receives payment requests from sellers, each payment request includes a mobile device identifier for a particular mobile device user.
  • an authentication processor authenticates the payment request using the mobile device identifier and profile data for the particular mobile device user.
  • a payment processor approves payment for each authenticated payment request as a function of the profile data for the particular mobile device user.
  • the payment processor also generates and sends electronic payment data for paying the seller for the authenticated payment request and assesses a fee for each payment.
  • a tracking processor tracks payments made on behalf of each mobile device user to facilitate the collection of funds for the payments.
  • Mobile authentication methods can include, but are not limited to, confirmation of phone presence at retailer (e.g., GPS, E911 and other device-retailer device communication), confirmation to user (e.g., a text message or email) and system initiation (e.g., user must “turn on” mobile payment by activating via phone before seller can send in data to be processed).
  • retailer e.g., GPS, E911 and other device-retailer device communication
  • confirmation to user e.g., a text message or email
  • system initiation e.g., user must “turn on” mobile payment by activating via phone before seller can send in data to be processed.
  • a distributed mobile payment system is implemented in an environment involving mobile device users, sellers, mobile carriers and a financial processing entity that contracts with mobile carriers for providing mobile payment.
  • the system has a databank arrangement to store, for each mobile device user, profile data characterizing mobile service criteria and financial processing criteria.
  • the data bank arrangement can also include, for each mobile carrier, profile data characterizing purchasing functions to be carried out on behalf of mobile device user customers of the mobile carrier.
  • a purchase processing arrangement facilitates payment to sellers for mobile device user purchases.
  • the facilitation can include associating received mobile payment requests with a particular mobile user and a particular mobile carrier as a function of mobile device user identification data in the requests; processing mobile payment for each associated mobile payment request by executing computer-readable code specified in profile data for the associated mobile device user and mobile carrier to facilitate payment to the seller sending the payment request and to track payments made on behalf of the mobile device user, and assessing a fee to each seller for payments made to the seller.
  • a method for processing payment for transactions between a seller and a mobile device user.
  • a mobile device identifier is used for the mobile device user and a financial processing system to populate and process closed and open network purchase systems for processing payment to sellers on behalf of mobile device users, thereby permitting trustworthy user-seller transactions based upon the mobile device identifier.
  • FIG. 1 shows an example of data flow for a control center and processing in response thereto, according to an example embodiment of the present invention
  • FIG. 2 is a block diagram showing aspects of a data parsing system, consistent with example embodiments of the present invention
  • FIG. 3 is a data-flow diagram for a data parsing system, consistent with example embodiments of the present invention.
  • FIG. 4 is a flow diagram for a data parsing system that uses a network routing arrangement, consistent with example embodiments of the present invention
  • FIG. 5 is a flowchart illustrating an example process that is consistent with an embodiment of the present invention.
  • FIG. 6 is an example block diagram depicting various elements of an example system, implemented according to aspects of the present invention.
  • FIG. 7 is an example flow diagram illustrating an example process that can be used in connection with parsing of transaction items, also consistent with the present invention.
  • a system or method is implemented to process accounting data and provide output that can be used to facilitate intelligent routing of transaction data to desired accounts.
  • a data-processing control center responds to a transaction involving a plurality of items (i.e., goods and/or services) parsed into groups that are distinguishable by the type of item. These groups are associated with different buyer accounts from which the funds for the associated items are debited or otherwise accounted for. While the present invention is not necessarily limited to such applications, various aspects of the invention may be appreciated through a discussion of various examples using this context.
  • the data-processing control center processes received data to generate a transaction profile that specifies how the seller is to be credited for the full transaction amount independent of receiving funds from other buyer accounts.
  • the control center generates or acts on transaction profiles.
  • the seller is able to process the transaction much like a conventional transaction (e.g., a credit or debit card purchase).
  • the buyer is able to complete the purchase/transaction with the seller without manually parsing the items at the time of purchase by, for example, paying for different items in the transaction using different cards, checks or other account identifiers.
  • a specific example embodiment of the present invention is designed for use with healthcare products and services.
  • a growing number of account types, insurance options and employee plans provide patients with options in health-related purchases.
  • insurance policies may pay for a portion or all of a policy holders expenses. Such policies can vary greatly in what is covered, how much is covered and other factors such as deductibles.
  • the healthcare provider must then wait for the insurance company to approve and provide compensation. If the entire transaction is not approved or compensation is less than for the full amount, then the healthcare provider may need to issue a bill to the patient. Not only is the healthcare provider burdened by the cost of issuing and collecting on such a bill, there can sometimes be a significant delay between the submission to the insurance company and the compensation/approval by the insurance company.
  • the patient may have several options from which to pay for the healthcare services. These can include, for example, insurance policy claims, health savings accounts and general accounts.
  • the patient may not have an intimate knowledge of all of the options and their associated rules. This could lead to less than ideal selection of how to pay for the healthcare and other goods.
  • the patient may have to make multiple transactions for a single purchase.
  • the following situation shows an example of a healthcare purchase using a system and/or method according to an embodiment of the present invention.
  • a buyer may enter a store that sells a number of different products including prescription medication and non-healthcare products.
  • the buyer wishes to purchase a number of items including prescription medication, nonprescription medication and non-healthcare products.
  • the buyer has an insurance policy that covers some prescription medication, a health savings account that covers most healthcare products including nonprescription medication and a number of general accounts, such as credit or debit accounts.
  • the buyer presents all of the items to the store/seller.
  • the transaction data is collected.
  • the transaction data includes, for example, a cost of each item, universal-product-code (UPC) data and/or a description of the items, such an identification denoting whether the item is (and possibly the type of) prescription medication.
  • UPC universal-product-code
  • the transaction can be completed without the buyer or seller individually parsing out the different items according to accounts associated with the buyer.
  • the buyer may present a single identifier (e.g., an insurance card, a credit card or a debit card) to the seller.
  • This identifier could be associated with any one of the buyer accounts, or merely a buyer identifier (e.g., a driver's license).
  • the system subsequently parses the items into groups using the transaction data and submits the data for the parsed items (hereafter, “parsed item groups”) to the corresponding buyer accounts.
  • the terms “items,” “transaction items” and “parsed items” are used to denote data that identifies the physical items or services involved in the transaction. More specific implementations, other embodiments (e.g., non-healthcare), and variations from this example will become apparent from the discussions and figures herein.
  • a system for processing the parsed transactions.
  • the system handles routing of the parsed item groups to designated networks and an associated account. Handling of routing can include direct communication with the routing network and/or generation of a payment profile, which is to be implemented by a routing system/network.
  • the system selects networks based upon user profile data and business rule data associated with the designated networks. Transactional data is routed to the selected networks to implement the monetary portion of the transaction. In one instance, the system routes this transactional data in real-time as part of the initial seller-buyer transaction. In another instance, the system first authorizes the transaction against, for example, a default (e.g., credit/debit) account. Assuming the transaction is authorized, the seller is credited for the transaction. The system then parses the transaction items according to preferred buyer accounts. These preferred accounts are debited accordingly.
  • a default e.g., credit/debit
  • the system can automatically implement the parsing and debiting functions.
  • the system can also be configured to provide a buyer interface for reviewing the implemented functions. While the buyer can review these functions, the buyer need not take affirmative action to carry out the transactions.
  • the system processes transactions relating to healthcare.
  • the accounts can be, for example, health insurance accounts, health-savings accounts, medical spending accounts and the like.
  • one or more of the debiting steps can be made responsive to buyer input.
  • This input can range from confirmation of a selection suggested by the system to direct selection of the accounts by the buyer.
  • the system can receive input from the buyer as to how to parse the items (e.g., at the POS device or subsequently provided buyer input over the Internet).
  • the buyer could present the system with a suggested parsing of the payments and/or the system could provide a suggested payment profile to the buyer.
  • the suggested payment profile could indicate how the items have been parsed and assigned to buyer networks/accounts.
  • the buyer or system can review, adjust and/or confirm the payment profile.
  • the system can implement the payment profile without buyer input. The system can still allow the buyer to review the implemented payment profile.
  • the buyer can choose to adjust the implemented payment profile as desired. This can be accomplished, for example, by delaying implementation of the payment profile during an adjustment period. During the adjustment period, the buyer is allowed to modify the payment profile. At the end of the adjustment period, or after the buyer has confirmed the payment profile, the payment profile can be implemented.
  • the seller need not have direct knowledge of the buyer's selected network(s). In certain instances, the buyer and seller do not have existing agreements with the selected network of the other party.
  • a system for processing buyer-seller transactions using disparate seller and buyer networks and accounts held therein.
  • the system captures buyer and seller transaction data associated with the sale and purchase of goods or services.
  • the system selects a buyer network from a plurality of possible networks.
  • the system routes a portion of the buyer-seller transaction data to the selected buyer network.
  • the buyer network is a network for which the seller does not have an existing relationship.
  • the system selects a seller network from a plurality of possible networks.
  • the system routes a portion of the buyer-seller transaction data to the selected seller network.
  • the seller network is a network for which the buyer does not have an existing relationship.
  • the system selects both a seller network and a buyer network from a plurality of possible networks.
  • the system routes a portion of the buyer-seller transaction data to the selected networks.
  • Another embodiment of the invention includes the identification of potential accounts in the seller access network on an account-by-account (e.g., Payment Card Account) basis.
  • the identified accounts include accounts for which bilateral agreements do not exist with the payment network associated with the buyer identification of selected payment network.
  • FIG. 1 shows an example system for implementing a transaction using a payment parser and disparate seller and buyer networks, according to an example embodiment of the present invention.
  • An example of disparate networks includes the instances where the buyer account is not recognized on the seller network.
  • the system can identify the buyer and determine that settlement can occur using a set of rules embodied and processed in the financial control system 116 .
  • a buyer wishes to purchase goods and services from a seller.
  • a buyer/seller interface captures transaction data ( 100 ) and transmits the data to transaction parsers 120 .
  • Transaction parser 120 groups items of the transaction according to transaction types that correspond to one or more networks/accounts.
  • the parsed transactions are sent to network/account selector 150 .
  • Network/account selector 150 provides an indication of the selected network(s) to routing blocks 160 and/or 170 .
  • Financial control system 116 receives inputs from buyer/seller interface 100 and from the selected networks.
  • the buyer and seller transactional data is captured, for example, using a buyer-seller interface to read the transaction data.
  • the buyer and seller interfaces could be distinct interfaces or they could be part of the same interface.
  • the buyer interface could be a card reader, a computer interface for entering identification (e.g., over the Internet) or a smart-card interface.
  • the seller interface could include point-of-sale devices that allow the seller to input data. Examples of interfaces that can receive data from both sellers and buyers include a website or an automated transaction machine, such as a self-service gas pump. There are numerous other possible interfaces, some of which are discussed in further detail herein.
  • the capture of the transactional data ( 100 ) includes the buyer identification, the seller identification and the transaction amount.
  • security information include various secondary identifications including, but not limited to, personal pin numbers, biometric data, passwords, social security numbers and authentication via an external communication device, such as via email or a cellular phone.
  • the transactional data is packaged for sending to two different networks.
  • the buyer information e.g., buyer identification and/or security data
  • the seller information e.g., seller identification and/or security data
  • This is possible due to the use of different networks by the buyer and seller.
  • some or all of the transaction data is duplicated for use by the system. This can be useful for a variety of applications, such as applications in which the buyer and seller networks have bilateral agreements. Further details of such applications are discussed further herein.
  • Network selector 150 selects a buyer and/or seller network to use in processing the transaction.
  • the network selector compares the buyer or seller identification to a stored list of buyer or sellers.
  • a profile is retrieved for the participant and used in the selection of the network for the participant.
  • the data from the retrieved profile can be applied to a set of business rules to determine the network for the participant.
  • the selected network can be determined without knowledge of the other participant.
  • a profile of the other participant can also be retrieved and used to select the network. For instance, a particular network may be selected because the seller has a favorable bilateral agreement with a network that is usable by the buyer.
  • Network selections 112 and 113 include data that indicates the proper network to route the transactional data.
  • Inputs 114 and 115 receive the transactional data necessary for the selected network of the buyer and seller, respectively.
  • the routing blocks 110 and 111 use this information to send the proper transactional data to the selected network from the possible networks.
  • a network selected for the seller will process the transaction so as to credit the seller for the value of the transaction.
  • a network selected for the buyer will process the transaction so as to debit/charge the buyer for the value of the transaction.
  • the settlement between the two networks can be accomplished using a number of different settlement processes.
  • the networks can directly communicate with one another. This may be the case where the networks have bilateral agreements with each other.
  • the transactional data received by each network can be used to reconcile the debit and credits for a transaction by, for example, matching a transaction identifier received by each network.
  • Such settlement can be done immediately or on a periodic basis (e.g., daily).
  • the networks may have a number of settlement options of which the overall system is aware.
  • the overall system can use network profiles and/or business rules to determine if the networks are compatible, and if so, which settlement rules to implement.
  • the system can then provide the networks with the proper data to allow the networks to settle the transaction(s) between one another.
  • the data may include information such as an identification of the settlement protocols to use, communication methods or fee calculations. This can be particularly useful for networks that do not have explicit bilateral agreements with one another, but nonetheless, desire to effect settlement directly with one another.
  • the seller and buyer networks do not directly effect settlement with one another. Instead, one or more third parties can be used to effect settlement.
  • a financial entity 116 such as a bank, can collect from the buyer network while crediting the seller network. The financial entity reconciles the collected and credited amounts. This can be particularly useful for facilitating transactions between networks that are either incompatible or unwilling to interface directly with one another.
  • the seller and buyer networks may be the same network and the settlement can then be implemented according to a protocol of the selected network.
  • Each of the selected networks is allowed to process the transaction according to their respectively established protocols. In some cases this includes the billing and reporting functions to the buyer and seller. For example, a credit card network can send a statement to the buyer that includes the transaction amount. The buyer is then obligated to repay the proper party within the credit card network. Likewise, the seller could be credited for the value of the transaction through an appropriate network and notified of the transaction details using a transaction statement/report (mailed, online or otherwise).
  • a portion of the system is implemented to facilitate population of the system with buyers and/or sellers.
  • Sellers and buyers alike obtain more value as the number of sellers and buyers participating with a specific network increases. For example, sellers are able to offer the purchase options to more buyers, while buyers are able to use the service at more locations/sellers. This network effect often presents a buyer/seller population problem for newly implemented systems as they often do not have a critical mass of buyers and sellers necessary to make the systems valuable.
  • This population system can include a database of eligible buyers and/or sellers that is used to identify potential new participants in the system. These potential participants can be notified of their eligibility using an acceptable mechanism. For example, the system may detect a purchase placed by a buyer who is a participant in a network associated with the system. The population system can perform a number of different actions with this information. For instance, the identified buyer can be immediately notified of their eligibility. This can be done, for example, by notifying the buyer or seller of the option before the transaction is completed. In some instances, the buyer may be notified of potential savings, or other incentives, should they choose to participate. This can include the option to use one or more preferred accounts associated with a network other than the network that would otherwise be used by the buyer in the instant transaction. In another example, the buyer is notified at a later date. For instance, the buyer could be notified through a targeted mailing or email communication. In another instance, the buyer can be notified of his options in conjunction with a subsequent statement or bill.
  • FIG. 2 shows a block diagram for a payment parsing system, according to an example embodiment of the present invention.
  • Buyer/seller transaction data is captured at point-of-sale (POS) device 204 .
  • the buyer presents the seller with identification information, such as an identification card 202 (e.g., a debit/credit card).
  • POS device 204 can capture data that identifies properties of items involved in the transaction.
  • the captured data is sent to system 206 .
  • System 206 provides authorization and payment to the seller at block 208 .
  • the payment can originate from account 212 .
  • Account 212 can be implemented in a number of different manners.
  • account 212 is a default account of the buyer.
  • the account 212 is the default account in the sense that the account is suitable for use with all items in the transaction.
  • Example accounts include, but are not limited to, credit card accounts, debit card accounts, savings accounts, checking accounts, pre-paid card accounts and a loan extended by a financial institution.
  • account 212 represents a financial institution's temporary payment on behalf of the buyer.
  • the financial institution can extend temporary credit to the buyer until such a time as the transaction has been parsed and the proper accounts have been debited.
  • Payment processor 210 receives the transaction data and parses the data into groups of items.
  • the groups of items are determined using a set of profile rules that can be tailored to the specific buyer, the type of transactions and the available accounts 220 .
  • the transaction amount relative to the parsed groups of items can then be debited from the appropriate accounts 220 . These amounts can then be used to offset the outstanding balance of account 212 .
  • the system can submit a parsed group of items to be debited from a selected account.
  • the account can be selected by transaction processor 216 using various data 218 including, but not limited to, business rules, profile information, transaction-specific information and input from the buyer or seller.
  • a database is used to store the current status of the group of items as represented by pending transaction warehouse 214 .
  • pending transaction warehouse 214 can be updated accordingly.
  • a selected account may respond in various fashions. In one instance, the selected account determines that the entire transaction amount for the submitted group is covered from the account. In another instance, the selected account determines that the entire transaction amount for the submitted group is not covered from the account. Other examples include partial coverage of the transaction amount or indications of delays in processing the submitted group.
  • the system can determine if there is another buyer account to which the selected group is to be submitted.
  • the selection of the second account involves use of a sorted list of eligible accounts.
  • the list can be sorted according to business rules that select the most desirable accounts first and the less desirable accounts last.
  • the transaction amounts can be submitted to the accounts in descending order so as to allow the preferred accounts to be used first.
  • the system first submits transactions information for a group of items to a preferred account.
  • the preferred account provides an indication as to how much, if any, of the transaction amount is acceptable. Any remaining transaction amount can then be submitted to the next account in the sorted list.
  • the system can submit the transaction information to multiple (or all) of the eligible accounts relatively simultaneously.
  • the accounts can indicate how much, if any, of the transaction amount will be accepted.
  • the system can then partition the transaction amount between the various accounts according to the indications.
  • the system submits transaction information about a group of items to a first account that is selected according to a set of business rules and user profile information.
  • the system modifies the status of the group of items accordingly.
  • the system uses the modified status to select a second account according to a set of business rules and user profile information.
  • This recursive process can be continued until the transaction for the group of items is settled or no eligible accounts remain.
  • the indications from the accounts affect the selection of an account.
  • the preferred account may change based upon the amount of the transaction remaining, or in response to some of the items of the group which may have been compensated for by another account.
  • the recursive nature can be useful for a system that dynamically prioritizes accounts based upon input from one or more accounts.
  • parsing of the items can be facilitated using input from the buyer.
  • the buyer is able to enter a desired or suggested parsing for the system to implement.
  • the buyer is able to verify and/or modify a suggested parsing presented by the system.
  • FIG. 3 shows a flow diagram for transaction data, according to an example embodiment of the present invention.
  • Merchant/Seller 304 accepts a buyer identifier 302 from a buyer desiring to purchase various merchant/seller offerings (e.g., items or services).
  • the seller captures information from the buyer identifier 302 and data 308 , representing the transaction items, using POS device 306 .
  • transaction data 308 can be supplemented by buyer input at a later time (e.g., via a website that allows the buyer to provide parsing information about the transaction).
  • the captured data is sent to parsing processor 310 .
  • a suspense account 303 is debited for the transaction.
  • Parsing processor 310 associates the items found in data 308 to buyer accounts to generate parsed data 311 .
  • the associated accounts are debited using settlement processor 312 .
  • Settlement processor debits the appropriate buyer accounts 314 and credits suspense account 303 .
  • Seller 304 is also credited for the transaction amount.
  • authorization processor 316 authorizes the transaction by notifying the POS device 306 .
  • Suspense account 303 can be implemented in a variety of manners.
  • suspense account 303 can be a default account of the buyer. Examples include, but are not limited to, a credit card account or a checking/savings account.
  • suspense account 303 is initially debited to pay the seller. If any of the buyer accounts 314 are debited, the amount can be credited to suspense account 303 .
  • the system could credit another user account. This flexibility allows the buyer to shift funds depending upon various parameters.
  • the suspense account 303 may be a credit card account. The buyer may desire that rather than crediting this account, the credit should be applied instead to a savings account. One reason for such a transfer is that the buyer may wish to receive interest on the credited amount. Presumably, the buyer would transfer funds from the savings (or another) account prior to the payment due date for the credit card.
  • suspense account 303 is a seller account.
  • the seller account represents a temporary extension of credit to the buyer.
  • an authorization from the system can be particularly advantageous as it can provide the seller with a level of confidence (e.g., that the buyer has sufficient means to pay for the transaction).
  • suspense account 303 is a third party account.
  • the bank may implement the suspense account 303 on behalf of the buyer.
  • the credit to the seller would come from such an account and the settlement from the buyer accounts would compensate for this credit.
  • the suspense accounts are implemented as individual accounts for each buyer who enrolls in the system.
  • a provider of an account initially credits the seller. It may be that the provider does not debit the entire amount credited from the buyer's account, leaving an outstanding balance. The provider could directly bill the buyer for the outstanding amount. Alternatively, the provider could notify the system of the outstanding amount. The system could then submit the outstanding balance to another eligible account and/or bill the buyer for the remaining amount.
  • Database 309 stores data for pending settlements related to various transactions.
  • the system updates the data as accounts 314 are debited.
  • Database 309 is updated according to the debited amounts.
  • the updated data is processed to parse the transactions again. In this manner, recursive parsing is implemented until the transaction has been settled, no options remain for buyer accounts, or some other threshold criterion is met.
  • authorization processor can receive data about the associated buyer accounts that indicate whether the transaction is valid. This can include, for example, information regarding current account balances, periodic limits on transaction amounts, buyer-defined constraints and/or tax laws.
  • the entire process can be implemented in relatively rapid fashion allowing the seller and buyer authorization and settlement to be completed at the time of the initial transaction.
  • portions of the transaction can be completed at a later date.
  • One such instance involves the use of a temporary or default account. This default account can be used to verify the transaction and to pay the seller. The parsing of the items and debiting of the associated accounts can then be accomplished at a later time. Such processing functions can occur on a periodic basis.
  • FIG. 4 shows a flow diagram for processing transaction data to be used by a network routing arrangement, according to an example embodiment of the present invention.
  • Parsing processor 402 receives transaction data that includes a number of different items involved in the transaction.
  • parsing processor 402 can group the items independent of knowledge of the accounts held by the buyer. For example, parsing processor can tag each item with multiple eligibly account types (e.g., insurance claim, health-savings account and credit card). This determination can be made based upon an item identifier (e.g., universal product code (UPC), textual product description or custom identifiers) or upon buyer provided data (e.g., via a website).
  • UPC universal product code
  • the parsed transactions 406 can then be sent to an authorization processor 410 .
  • Authorization processor 410 can make a determination as to whether the system determines that the transaction is valid. Notification of the determination can then be sent to the seller and buyer.
  • the parsed buyer transaction data 408 is sent to account selection 412 .
  • Buyer profiles 414 and business profiles 416 determine the proper network and account for each transaction item. This can be accomplished, for example, by correlating the eligible accounts indicated by the tag with accounts available to the particular buyer. Additional data can also be used in the determination step. For example, account balances, buyer preferences, associated fees, transaction amount limits, tax implications and account-based interest can each be included into the determination of which account an item is to be assigned.
  • the determined/assigned account is then sent to system select input 420 .
  • the transaction data (e.g., transaction amount and account identifier) is sent to input 422 .
  • the transaction data is routed to the appropriate buyer account(s) 418 for processing and/or settlement.
  • the selected buyer network can provide feedback to ultimately be used by authorization processor 410 in a determination of whether the transaction is valid.
  • FIG. 5 shows a flowchart for a process that is consistent with an example embodiment of the present invention.
  • items of a transaction are parsed according to the item types, their costs or other transaction data.
  • the parsed items are associated with one or more eligible buyer accounts at step 504 .
  • the process proceeds to step 508 . If there are no eligible accounts and/or payment may not be completely covered, the process can proceed to step 514 to institute default payment rules (e.g., paying from a default account) or dispute resolution/collection.
  • step 502 items of a transaction are parsed according to the item types, their costs or other transaction data.
  • the parsed items are associated with one or more eligible buyer accounts at step 504 . Assuming there are eligible accounts indicated for a particular group (per decision step 506 ), the process proceeds to step 508 . If there are no eligible accounts and/or payment may not be completely covered, the process can proceed to step 514 to institute default payment rules (e.g., paying from a default account) or dispute resolution/collection
  • a particular account is selected.
  • This selection step can be accomplished by taking in a number of different parameters and considerations.
  • Example factors include, but are not limited to, the amount of the transaction, known limits of various buyer accounts, tax implications, interest rates and the type of items in the transaction. This process can be particularly useful for allowing modularity in the various components.
  • the system could implement an algorithm that attempts to maximize gains of the buyer.
  • the system could instead implement an algorithm that maximizes gains of the system implementer or the seller.
  • Other possibilities include, but are not limited to, maximal efficiency between all parties, reduced tax implications and predictive algorithms.
  • more than one account can be selected at the same time.
  • the amount of the transaction can be split between multiple buyer accounts, or the entire transaction amount can be sent to each buyer account and actual debits from the accounts can be determined from the responses from the buyer account systems. For example, if the transaction is for $100 and there are 3 potential/eligible accounts, the first approach would involve portioning the $100 between the eligible accounts (e.g., $40 to a first, $60 to a second and $0 to a third). The second approach would send $100 request to each of the 3 buyer accounts. The buyer accounts would respond with an indication of how much, if any, of the transaction amount is approved (e.g., $80 from a first, $50 from a second and $0 from a third). The system could then apportion the $100 between the accounts as desired (e.g., $50 from the first and $50 from the second or $80 from the first and $20 from the second).
  • a request for payment is sent to the selected account(s) and a response is subsequently received.
  • Decision step 512 depends upon whether or not the entire transaction amount has been covered from the buyer accounts. If it has, the system can complete the transaction processing at step 516 . If the entire transaction amount has not been accounted for, the system can return to decision step 506 .
  • An optional implementation includes a time-window function. This can be useful, for example, with insurance policy claims that may take several days or even weeks to receive a response. If a response has not been received within the time window, the process can proceed by attempting to debit from another account. The insurance claim can then either be maintained or it can be canceled.
  • the system can implement one of two different paths shown by the dotted area 520 .
  • the transaction data is updated at step 518 .
  • This update can include information received from selected buyer account(s) providers.
  • an account provider may provide a value of the transaction that is acceptable, a list of items that are acceptable/unacceptable or a time-period before any transaction can be authorized. This information can then be used in either or both of steps 502 and 504 .
  • FIG. 6 shows a block diagram depicting various elements of a system implemented consistent with an example embodiment of the present invention.
  • Sellers 610 provide various products or services to buyer 600 .
  • the transactional data is captured and sent to parsing system 630 .
  • Parsing system 630 parses the transaction data.
  • the parsed transaction data can then be sent to selected buyer accounts provided by various institutions/companies 640 .
  • the buyer 600 is allowed to access transaction data from the parsing system 630 using a network interface, such as a website or dedicated software.
  • the institutions/companies 640 shown are representative of a few examples including, but not limited to, investment companies, financial institutions, educational institutions, businesses and governmental institutions. Moreover, the provider of parsing system 630 may hold one or more buyer account types.
  • the provider of parsing system 630 is a banking institution. Such institutions can be particularly well situated to provide the interfaces between varieties of different account providers.
  • a specific aspect of the present invention includes the selection of the buyer account for various parsed groups of items.
  • buyer 600 can provide input (e.g., monitoring, confirmation or parsing selections) via a personal interface 620 , such as a home computer.
  • the selection is accomplished using one or more selection algorithms, which can be tailored to the specific implementation, current laws and regulations, the financial markets, current interest rates and a host of other parameters, some of which are subject to continual changes. As such, an exhaustive description of all such algorithms, related business rules, and possible input data would be impractical.
  • An example set of business-rule data for various medical items is provided in Table 1.
  • Table 2 shows an example set of business-rule data for various non-medical items.
  • Table 1 shows the medically-related groups for each buyer
  • Table 2 shows the non-medically-related groups for each buyer.
  • the table includes data regarding the cost of the group and whether the group includes a service and/or a prescription. Other data includes whether a predefined rule exists for the group. Such predefined rules can be implemented as, for example, a rule setup by the buyer or rules dictated by laws or regulations.
  • Table 1 also includes data regarding the Medical Account numbers, as well as a default account number.
  • Table 2 contains non-medically related information, such as whether the group is personal or for business.
  • the business rules and related algorithms use the data in Tables 1 and 2 as inputs in the selection of a buyer account to associate with the particular group.
  • buyer-specific data e.g., account limits/balances, buyer selected preferences, buyer credit-history or other buyer data
  • Example algorithms include the use of (alone or in combination) lookup tables, statistical weighting of inputs, adaptive learning, calculations or predictions of the cost/fees, and/or predicted tax consequences.
  • the buyer account can be selected by accessing a lookup table in a database, where the lookup table is indexed by one or more of the data from the above tables.
  • the entries in the lookup table can be populated to be consistent with a set of business rules regarding transactions and the buyer accounts.
  • a lookup table is initialized and/or modified according to data provided by one or more analytical/optimization algorithms. Sets of input data can be input into the algorithm(s).
  • the output of the algorithm(s) can include the desired account type(s) for each set of input data. This results in a matching between each set and specific types of accounts. This matching can be used to populate or modify the lookup table.
  • lookup table need not require that the algorithm be run, the need to execute the algorithm(s) for each buyer account selection can be alleviated. This can be particularly useful where the algorithm(s) are particularly complex and/or processing intensive. Where multiple algorithms are used, some algorithms may be tailored to different outcomes (e.g., maximize short/long-term gains, minimize tax implications, minimize fees or optimize gain/costs for certain/all parties). In a specific instance, different lookup tables can be set up for each algorithm. A specific lookup table can be selected according to the buyer-selected-profile (e.g., the buyer selects short term gain as an important factor). Alternatively, multiple lookup-tables can be used where multiple buyer accounts result from different lookup-tables, a selection can be made therefrom.
  • weight-factor In a specific buyer-account-selection algorithm, data from the above tables is assigned a weight-factor.
  • a computer implements an algorithm that uses the weighted data to determine the preferred account. This allows for certain data to be afforded more importance.
  • the weight factors can represent priorities assigned to the different data inputs. These priorities can be determined, for example, from statistical data, the owner of the system, the buyer, the seller, providers of the buyer account, or combinations thereof.
  • the algorithm uses a database of prior history to determine the buyer accounts.
  • an unsupervised learning algorithm can be employed.
  • the unsupervised learning algorithm takes all the data available and develops probabilistic models from the data. For example, one such algorithm may be used to determine the likelihood that a buyer will make a payment on-time. This can affect the desired account, as some accounts may charge higher penalties and/or interest rates. Should the desired result be a minimization of buyer costs and the buyer is deemed to be likely to make a late payment, the accounts can be selected accordingly.
  • Another example buyer-account-selection algorithm employs a supervised learning model.
  • the algorithm develops a model to conform with sets of inputs that are matched to sets of outputs. This can provide a model for predicting any number of different outcomes (e.g., fees, chance of acceptance by account or delay time in processing) from the available input data (e.g., transaction amount, item descriptions or buyer account).
  • Both supervised and unsupervised modeling can be useful for continual updating of the models and the resulting selection of the buyer account made by the system.
  • the database of knowledge can be updated accordingly.
  • the updates to the database allow for modification of, for example, the buyer account selection.
  • Such modeling can also be particularly useful for adding, removing or otherwise changing the input data or output data used in selecting a buyer account.
  • FIG. 7 shows an example flow diagram that can be used in connection with parsing of transaction items.
  • the path used to reach the node may not be important.
  • this path data can be used in the final grouping.
  • the node information could include the entire path set ⁇ 0, 1, 3, 8, 15 ⁇ or portions thereof. This data can be used in grouping the various items. In specific instances, a lookup table can be consulted to determine the grouping for each item. Thus, the path set ⁇ 0, 1, 3, 8, 15 ⁇ may point to a grouping N in a lookup table.
  • Certain items can follow more than one path or have more than one final node.
  • an item may be related to both travel ( 22 ) and government ( 20 ).
  • Such situations can be handled in a number of different manners, one of which involves establishing priorities between the various nodes.
  • a buyer account associated with a higher priority node can be used before those of a lower priority node. This can be particularly useful when implementing a recursive process, such as that discussed in connection with FIG. 5 .
  • a transaction group exists that relates to multiple nodes having different priorities. The system can first submit the transaction group to the buyer account associated with the highest priority node. Should this buyer account not provide a credit for the item or provide only partial credit for the item, a buyer account associated with a lower-priority node can be used.
  • Another possible mechanism for handling such situations involves using each of the nodes to select a buyer account. This can result in multiple buyer accounts being selected and used. As discussed in more detail above, multiple buyer accounts for the same group of items can be contacted in either a parallel fashion or a serial fashion and the transaction amount can be split between the buyer accounts or the full amount can be submitted to each buyer account.
  • an identifier provides all details necessary to categorize and parse the items.
  • Example identifiers include, but are not limited to, a UPC, an insurance code/descriptor and textual descriptions. While these identifiers contain specific information, they may or may not be known by the system prior to being received. For example, new products are continually reaching the market, and an exhaustive list of each new product would be, at best, difficult to maintain. Should the specific item be known with certainty, however, the categorization can be accomplished using a simple lookup of the categorization associated with the identifier. This can be particularly useful for items/applications for which a standardized identifier is used in the buyer-seller transaction.
  • One method involves categorization of such items and using the categorization to populate a lookup table as transaction data. For example, a previously unknown identifier or combination of transaction data is first compared against the lookup table. Assuming that the lookup table does not have an entry for the identifier, categorization can be determined for the identifier. Once a categorization is known, the lookup table can be populated accordingly.
  • One example method for determining the proper categorization is to allow the buyer to select a proper categorization.
  • the buyer could select the categorization using an online interface such as a website or other software configured to interface with the system.
  • the buyer can provide such an indication by explicitly selecting a certain category.
  • the buyer can answer a set of questions regarding the specific item and related transaction.
  • the set of questions can be provided by the system and tailored to correctly categorize the item. Such questions can be particularly useful for properly categorizing the item(s) without requiring the buyer to know the proper rules behind each categorization.
  • Another example method for determining the proper categorization is to use prediction algorithm(s) to determine the most likely categorization. For instance, these algorithms can use a variety of textual recognition and/or draw from a database of past categorizations based upon similar transaction data. Both supervised and unsupervised learning algorithms could be employed to predict the proper categorization.
  • an item may be improperly categorized. This could be detected, for example, where the selected buyer account holder rejects the item or where the buyer corrects the categorization.
  • the system can use this data to update accordingly, including updates to any lookup tables or prediction models.
  • parsing tree of FIG. 7 uses medical and nonmedical as the first parsing level, the invention is not so limited. Additional and/or different parsing selections can also be implemented.
  • the various embodiments describe herein can be implemented using one or more processors running software configured to implement various functions described herein.
  • the system allows for modularity in a number of aspects including the interfaces between the various components.
  • the specific code and algorithms for implementing many of the functions would depend upon the particulars of implementation.
  • an Internet-based sale may use secure-socket-layer protocols.
  • a seller interface using a credit/debit transaction card reader at the point-of-sale device might use protocols consistent with various transaction processing networks (e.g., Nabanco, Omaha, Paymentech, NDC Atlanta, Nova, Vital, Concord EFSnet, and VisaNet).
  • the various buyer accounts may use a variety of (in some cases proprietary) protocols and standards.
  • these and other standards are often subject to continual updates and changes. As such, a discussion of each individual protocol and implementation is not practical. The skilled artisan would recognize that these and other variations do not depart from the heart of the invention.

Abstract

Devices, systems, methods and arrangements are implemented in variety of manners. In a specific instance, a computer arrangement implements the following operations for a transaction involving a plurality of merchant offerings that are parseable by merchant offering identifiers. For a plurality of identified buyer accounts from which monetary payables (e.g., cash, credit and/or debit limits) are tracked, stored data sets are accessed that are indicative of types of merchant offerings to be associated with particular ones of the plurality of buyer accounts. Payment is facilitated for the items as a function of at least one of the plurality of buyer accounts. Payment is tracked for the items as a function of the merchant offering identifiers.

Description

    RELATED PATENT DOCUMENTS
  • This patent document claims the benefit, under 35 U.S.C. §119(e), of U.S. Provisional Patent Application Ser. No. 60/991,379, entitled “Control System Arrangements and Methods for Disparate Network Systems” to Dickelman, Mark and filed on Nov. 30, 2007, which is fully incorporated herein by reference as describing and illustrating subject matter (in part(s) or in its entirety) that can be practiced with the subject matter disclosed herein.
  • FIELD OF THE INVENTION
  • This invention relates generally to computer-automated devices, systems and methods relating to data processing involving accounting records, and as an example, to systems and methods for automated computer systems and networks implemented as may be found in a control center of a financial institution.
  • BACKGROUND
  • Computer systems and networks that process accounting data in a control center of financial institutions have struggled to keep up with the ever increasingly complex and expanding variety of electronic accounting data. Accounting data can include data relating and leading up to implementations of payment systems and associated networks. More and more transactions are accomplished without direct payment (e.g., cash) from the buyer to the merchant/seller. Generally, these associated networks involve two primary components. The first component is a seller access network (e.g., Nova®) that provides connection to the point-of-sale (POS) devices (either directly or via merchant internal networks) and identification of the type of payment account (e.g., Visa® or Voyager®). A second component includes payment processing networks that process payment instructions based on established agreements by the participants. Generally, these payment processing networks are one of two different categories, proprietary networks (e.g., Voyager®) or association networks. Examples of association networks include the networks provided by VISA® and MASTERCARD® and/or the particular acquiring/issuing banks. For a particular transaction, the operator of the association network controls the flow of funds for the transaction. Often, this includes a fee that is passed on to the seller, such as a percentage of the transaction. The participating sellers have an agreement with the network (e.g., VISA or MASTERCARD), but do not have a transactional relationship between one another with respect to the association network transactions.
  • Such transactions are often implemented where the seller has an existing relationship with a bank. The seller sends the transaction information to this bank, sometimes referred to as the acquiring bank. The acquiring bank can forward the payment information to a bank that issued the card, sometimes referred to as the issuing bank. Often the payment processing networks assign interchange fees that are paid between the parties based on the type of transaction, authentication and location. These fees may be passed on to the seller.
  • An example of a proprietary network is a merchant-provided in-store credit or debit account. The seller, or a seller contracted third party, handles the settlement, authorization and/or other functions associated with a transaction. In some instances, the seller can form bilateral agreements with other sellers to allow use of one network by multiple sellers or to coordinate use of multiple networks between multiple sellers. The sellers establish the bilateral agreements with one another to allow such functionality. For instance, two department stores may allow use of the same proprietary network card at either store or they may allow use of two different proprietary network cards (i.e., one from each store) at either store.
  • A few networks allow for a single (multi-purpose) card to provide access to more than one account. The card interfaces with a network that would otherwise support one or more of the accounts. The cardholder designates a desired account to use. The transaction is processed as if the card associated with the desired account had been used. Thus, the underlying transactional functions operate in much the same manner as if the original card had been used. The buyer must still carry the multi-purpose card for use and can only use the multi-purpose card at locations that support that particular card.
  • In this complex and ever expanding background of various payment networks, consumers have an increasing number of accounts from which they can access funds for purchases (e.g., credit, debit, insurance, health-savings accounts, money markets, investment and retirement). These accounts can vary with respect to their respective fees, tax implications, interest rates, limitations on withdraw amounts and a number of other properties. Often the consumer is forced to spend considerable time and effort to manage such accounts and associated transactions. For example, considerable time and effort can be expended in determining how to best apply specific transactions and/or purchased items to the various accounts. In some instances, the actual implementation of such a determination can be just as difficult.
  • SUMMARY
  • Consistent with an example embodiment, the present invention involves a financial control center that processes data in response to a purchase transaction in which a plurality of data-identifiable items (i.e., merchant offerings such as goods and/or services) are purchased over a payment network. The payment network interfaces with a computer-operated arrangement and one or more financial institutions that oversee different buyer accounts. The control center accesses information about buyers (and in some instances, sellers also) involved in the purchase transaction and their accounts which might be adjusted (e.g., debited) in consideration of the data-identifiable items involved in the transaction. The payment network determines whether the buyer has sufficient funds or credit to cover the transaction amount. If the transaction is authorized, a buyer account is (e.g., actually or effectively) debited for the transaction amount, and the seller is credited for the transaction amount. A payment parser examines the transaction data to parse items according to other buyer accounts for debiting. The associated buyer accounts are debited for the values of the associated items and the corresponding amounts are credited to the originally debited buyer account.
  • Consistent with one embodiment of the invention, transaction data about a plurality of items (e.g., goods or services) purchased is provided to a payment network along with buyer and/or seller credentials/identification data. A payment parser examines the transaction data to parse items according to other buyer accounts for debiting. The associated buyer accounts are debited for the value of the associated items and any remaining amount can be debited to a default buyer account.
  • In a particular embodiment of the invention, the payment parser determines whether a particular transaction item qualifies for specific accounts. For example, the account may have requirements on the types of transactions that can be debited (e.g., due to favorable tax treatment of the account). In one instance, the account is a medical account for which only medically related items qualify. Example medical accounts include insurance accounts and health savings accounts (HSAs).
  • Consistent with an example embodiment of the invention, buyer and/or seller credentials/identification data is provided to a payment network. For a situation where the credential data identifies the same payment network for both the buyer and seller, the transaction can optionally be completed using transfers between accounts held within the same payment network. As another option or for a situation where the buyer and seller do not present credentials that are associated with the same payment network, a disparate network system can process the transaction. Thus, even though the credential does not explicitly identify the buyer and seller as participants in a common payment network, the system can determine that the buyer and seller have an account on a supported payment network.
  • If accounts held at the same payment network or payment networks with established settlement are not available through the operation of the disparate network system, a common settlement mechanism can be identified allowing for transfer of funds between buyer and seller accounts on disparate networks.
  • Consistent with one embodiment of the invention, a system facilitates payment between sellers providing goods or services to buyers paying for the goods or services. The payment is provided between disparate payment networks of the buyers and sellers. An interface receives transaction data. The transaction data can include various different types of information, such as a buyer identifier, a seller identifier, a transaction amount, transaction time, transaction type and location of transaction. A payment network selector receives the transaction data from the interface. The payment network selector uses the received transaction data to select a payment network for one of the buyer and seller as a function of respective profile data. A routing arrangement routes at least a portion of the transaction data to the selected payment network and another portion of the transaction data to a disparate payment network. Consistent with the transaction amount, an account held at the selected payment network is either debited or credited and an account held at the disparate payment network is the other of debited or credited.
  • Consistent with another embodiment of the invention, a system executes payment for transactions between buyers and sellers using profile data that identifies payment accounts and corresponding payment networks available to the buyers and sellers. A transaction interface arrangement receives a transaction request for a transaction between a seller and a buyer. The transaction request includes a buyer identifier, a seller identifier and a transaction amount. An authorization processor that, for the received transaction request, authorizes the transaction by verifying that transaction request meets stored business rules. A payment processor selects at least one of at least two available payment processing networks for use in providing funds for the transaction request using preferences for at least one of the seller and the buyer. A routing arrangement routes payment information regarding the transaction request to the at least one selected payment processing network.
  • Consistent with another embodiment of the invention, a method is implemented for facilitating payment between buyers and sellers. For each of a plurality of electronic payment requests received from sellers, a number of steps are implemented. Data contained in the request is used to identify a consumer/buyer and a seller. At least one of at least two available payment processing systems are selected for use in providing funds for the payment request using preferences for at least one of the consumer and the seller. Payment to the seller and collection from the buyer are provided as a function of the at least one selected payment processing system.
  • Consistent with another embodiment of the invention, a method is implemented for executing payment for transactions between consumers and sellers. For each of a plurality of payment requests received from sellers, a number of steps are implemented. Data from the request is used to identify a consumer and seller. Payment is effected to the seller on behalf of the buyer. Specifically, a buyer payment method is identified for providing funds for the payment request as a function of buyer profile information; a seller payment method is identified for providing funds to the seller as a function of seller profile information, and payment to the seller and collection from the buyer are facilitated as a function of the selected buyer and seller payment methods.
  • Consistent with another embodiment of the invention, a payment system executes payment in an environment involving mobile device users, mobile carriers and financial processing entities. The system uses profile data that characterizes mobile service criteria and financial-account criteria for each mobile device user. A seller interface arrangement receives payment requests from sellers, each payment request includes a mobile device identifier for a particular mobile device user. For each received payment request, an authentication processor authenticates the payment request using the mobile device identifier and profile data for the particular mobile device user. A payment processor approves payment for each authenticated payment request as a function of the profile data for the particular mobile device user. The payment processor also generates and sends electronic payment data for paying the seller for the authenticated payment request and assesses a fee for each payment. A tracking processor tracks payments made on behalf of each mobile device user to facilitate the collection of funds for the payments.
  • Mobile authentication methods can include, but are not limited to, confirmation of phone presence at retailer (e.g., GPS, E911 and other device-retailer device communication), confirmation to user (e.g., a text message or email) and system initiation (e.g., user must “turn on” mobile payment by activating via phone before seller can send in data to be processed).
  • Consistent with another embodiment of the invention, a distributed mobile payment system is implemented in an environment involving mobile device users, sellers, mobile carriers and a financial processing entity that contracts with mobile carriers for providing mobile payment. The system has a databank arrangement to store, for each mobile device user, profile data characterizing mobile service criteria and financial processing criteria. The data bank arrangement can also include, for each mobile carrier, profile data characterizing purchasing functions to be carried out on behalf of mobile device user customers of the mobile carrier. A purchase processing arrangement facilitates payment to sellers for mobile device user purchases. The facilitation can include associating received mobile payment requests with a particular mobile user and a particular mobile carrier as a function of mobile device user identification data in the requests; processing mobile payment for each associated mobile payment request by executing computer-readable code specified in profile data for the associated mobile device user and mobile carrier to facilitate payment to the seller sending the payment request and to track payments made on behalf of the mobile device user, and assessing a fee to each seller for payments made to the seller.
  • Consistent with another embodiment of the invention, a method is implemented for processing payment for transactions between a seller and a mobile device user. A mobile device identifier is used for the mobile device user and a financial processing system to populate and process closed and open network purchase systems for processing payment to sellers on behalf of mobile device users, thereby permitting trustworthy user-seller transactions based upon the mobile device identifier.
  • The above summary of the present invention is not intended to describe each illustrated embodiment or every implementation of the present invention.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The invention may be more completely understood in consideration of the detailed description of various embodiments of the invention that follows in connection with the accompanying drawings, in which:
  • FIG. 1 shows an example of data flow for a control center and processing in response thereto, according to an example embodiment of the present invention;
  • FIG. 2 is a block diagram showing aspects of a data parsing system, consistent with example embodiments of the present invention;
  • FIG. 3 is a data-flow diagram for a data parsing system, consistent with example embodiments of the present invention;
  • FIG. 4 is a flow diagram for a data parsing system that uses a network routing arrangement, consistent with example embodiments of the present invention;
  • FIG. 5 is a flowchart illustrating an example process that is consistent with an embodiment of the present invention;
  • FIG. 6 is an example block diagram depicting various elements of an example system, implemented according to aspects of the present invention; and
  • FIG. 7 is an example flow diagram illustrating an example process that can be used in connection with parsing of transaction items, also consistent with the present invention.
  • While the invention is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.
  • DETAILED DISCUSSION
  • Consistent with an embodiment of the present invention, a system or method is implemented to process accounting data and provide output that can be used to facilitate intelligent routing of transaction data to desired accounts. In particular, a data-processing control center responds to a transaction involving a plurality of items (i.e., goods and/or services) parsed into groups that are distinguishable by the type of item. These groups are associated with different buyer accounts from which the funds for the associated items are debited or otherwise accounted for. While the present invention is not necessarily limited to such applications, various aspects of the invention may be appreciated through a discussion of various examples using this context.
  • According to an example embodiment of the present invention, the data-processing control center processes received data to generate a transaction profile that specifies how the seller is to be credited for the full transaction amount independent of receiving funds from other buyer accounts. In certain instances, the control center generates or acts on transaction profiles. The seller is able to process the transaction much like a conventional transaction (e.g., a credit or debit card purchase). Similarly, at the time of sale the buyer is able to complete the purchase/transaction with the seller without manually parsing the items at the time of purchase by, for example, paying for different items in the transaction using different cards, checks or other account identifiers.
  • A specific example embodiment of the present invention is designed for use with healthcare products and services. A growing number of account types, insurance options and employee plans provide patients with options in health-related purchases. For example, insurance policies may pay for a portion or all of a policy holders expenses. Such policies can vary greatly in what is covered, how much is covered and other factors such as deductibles. Should the healthcare provider submit an insurance claim on behalf of a patient, the healthcare provider must then wait for the insurance company to approve and provide compensation. If the entire transaction is not approved or compensation is less than for the full amount, then the healthcare provider may need to issue a bill to the patient. Not only is the healthcare provider burdened by the cost of issuing and collecting on such a bill, there can sometimes be a significant delay between the submission to the insurance company and the compensation/approval by the insurance company.
  • From the patient side, the patient may have several options from which to pay for the healthcare services. These can include, for example, insurance policy claims, health savings accounts and general accounts. The patient may not have an intimate knowledge of all of the options and their associated rules. This could lead to less than ideal selection of how to pay for the healthcare and other goods. Moreover, the patient may have to make multiple transactions for a single purchase. The following situation shows an example of a healthcare purchase using a system and/or method according to an embodiment of the present invention.
  • A buyer may enter a store that sells a number of different products including prescription medication and non-healthcare products. The buyer wishes to purchase a number of items including prescription medication, nonprescription medication and non-healthcare products. The buyer has an insurance policy that covers some prescription medication, a health savings account that covers most healthcare products including nonprescription medication and a number of general accounts, such as credit or debit accounts. The buyer presents all of the items to the store/seller. The transaction data is collected. The transaction data includes, for example, a cost of each item, universal-product-code (UPC) data and/or a description of the items, such an identification denoting whether the item is (and possibly the type of) prescription medication. The transaction can be completed without the buyer or seller individually parsing out the different items according to accounts associated with the buyer. For example, the buyer may present a single identifier (e.g., an insurance card, a credit card or a debit card) to the seller. This identifier could be associated with any one of the buyer accounts, or merely a buyer identifier (e.g., a driver's license). The system subsequently parses the items into groups using the transaction data and submits the data for the parsed items (hereafter, “parsed item groups”) to the corresponding buyer accounts. Unless otherwise indicated, the terms “items,” “transaction items” and “parsed items” are used to denote data that identifies the physical items or services involved in the transaction. More specific implementations, other embodiments (e.g., non-healthcare), and variations from this example will become apparent from the discussions and figures herein.
  • According to an example embodiment of the present invention, a system is implemented for processing the parsed transactions. The system handles routing of the parsed item groups to designated networks and an associated account. Handling of routing can include direct communication with the routing network and/or generation of a payment profile, which is to be implemented by a routing system/network. The system selects networks based upon user profile data and business rule data associated with the designated networks. Transactional data is routed to the selected networks to implement the monetary portion of the transaction. In one instance, the system routes this transactional data in real-time as part of the initial seller-buyer transaction. In another instance, the system first authorizes the transaction against, for example, a default (e.g., credit/debit) account. Assuming the transaction is authorized, the seller is credited for the transaction. The system then parses the transaction items according to preferred buyer accounts. These preferred accounts are debited accordingly.
  • In one instance, the system can automatically implement the parsing and debiting functions. The system can also be configured to provide a buyer interface for reviewing the implemented functions. While the buyer can review these functions, the buyer need not take affirmative action to carry out the transactions.
  • In a specific embodiment, the system processes transactions relating to healthcare. The accounts can be, for example, health insurance accounts, health-savings accounts, medical spending accounts and the like.
  • In another instance, one or more of the debiting steps can be made responsive to buyer input. This input can range from confirmation of a selection suggested by the system to direct selection of the accounts by the buyer. For example, the system can receive input from the buyer as to how to parse the items (e.g., at the POS device or subsequently provided buyer input over the Internet). The buyer could present the system with a suggested parsing of the payments and/or the system could provide a suggested payment profile to the buyer. The suggested payment profile could indicate how the items have been parsed and assigned to buyer networks/accounts. The buyer or system can review, adjust and/or confirm the payment profile. In another example, the system can implement the payment profile without buyer input. The system can still allow the buyer to review the implemented payment profile. In one implementation, the buyer can choose to adjust the implemented payment profile as desired. This can be accomplished, for example, by delaying implementation of the payment profile during an adjustment period. During the adjustment period, the buyer is allowed to modify the payment profile. At the end of the adjustment period, or after the buyer has confirmed the payment profile, the payment profile can be implemented.
  • Consistent with a specific embodiment of the present invention, the seller need not have direct knowledge of the buyer's selected network(s). In certain instances, the buyer and seller do not have existing agreements with the selected network of the other party.
  • According to an example embodiment of the present invention, a system is implemented for processing buyer-seller transactions using disparate seller and buyer networks and accounts held therein. The system captures buyer and seller transaction data associated with the sale and purchase of goods or services. In one embodiment of the invention, the system selects a buyer network from a plurality of possible networks. The system routes a portion of the buyer-seller transaction data to the selected buyer network. In a particular instance, the buyer network is a network for which the seller does not have an existing relationship.
  • In another embodiment of the invention, the system selects a seller network from a plurality of possible networks. The system routes a portion of the buyer-seller transaction data to the selected seller network. In a particular instance, the seller network is a network for which the buyer does not have an existing relationship.
  • Consistent with one embodiment of the invention, the system selects both a seller network and a buyer network from a plurality of possible networks. The system routes a portion of the buyer-seller transaction data to the selected networks.
  • Another embodiment of the invention includes the identification of potential accounts in the seller access network on an account-by-account (e.g., Payment Card Account) basis. In certain instances, the identified accounts include accounts for which bilateral agreements do not exist with the payment network associated with the buyer identification of selected payment network.
  • FIG. 1 shows an example system for implementing a transaction using a payment parser and disparate seller and buyer networks, according to an example embodiment of the present invention. An example of disparate networks includes the instances where the buyer account is not recognized on the seller network. The system can identify the buyer and determine that settlement can occur using a set of rules embodied and processed in the financial control system 116. A buyer wishes to purchase goods and services from a seller. A buyer/seller interface captures transaction data (100) and transmits the data to transaction parsers 120. Transaction parser 120 groups items of the transaction according to transaction types that correspond to one or more networks/accounts. The parsed transactions are sent to network/account selector 150. Network/account selector 150 provides an indication of the selected network(s) to routing blocks 160 and/or 170. Financial control system 116 receives inputs from buyer/seller interface 100 and from the selected networks.
  • To initiate a transaction, the buyer and seller transactional data is captured, for example, using a buyer-seller interface to read the transaction data. The buyer and seller interfaces could be distinct interfaces or they could be part of the same interface. For instance, the buyer interface could be a card reader, a computer interface for entering identification (e.g., over the Internet) or a smart-card interface. The seller interface could include point-of-sale devices that allow the seller to input data. Examples of interfaces that can receive data from both sellers and buyers include a website or an automated transaction machine, such as a self-service gas pump. There are numerous other possible interfaces, some of which are discussed in further detail herein. The capture of the transactional data (100) includes the buyer identification, the seller identification and the transaction amount. Various other data can also be included, such as time-stamps or security information. Examples of security information include various secondary identifications including, but not limited to, personal pin numbers, biometric data, passwords, social security numbers and authentication via an external communication device, such as via email or a cellular phone.
  • The transactional data is packaged for sending to two different networks. In one instance, the buyer information (e.g., buyer identification and/or security data) is separated from the seller information (e.g., seller identification and/or security data). This is possible due to the use of different networks by the buyer and seller. In another instance, some or all of the transaction data is duplicated for use by the system. This can be useful for a variety of applications, such as applications in which the buyer and seller networks have bilateral agreements. Further details of such applications are discussed further herein.
  • Network selector 150 selects a buyer and/or seller network to use in processing the transaction. The network selector compares the buyer or seller identification to a stored list of buyer or sellers. A profile is retrieved for the participant and used in the selection of the network for the participant. The data from the retrieved profile can be applied to a set of business rules to determine the network for the participant. In some instances, the selected network can be determined without knowledge of the other participant. In other instances, a profile of the other participant can also be retrieved and used to select the network. For instance, a particular network may be selected because the seller has a favorable bilateral agreement with a network that is usable by the buyer.
  • Once a network is selected, the necessary transactional data is sent to the selected network(s) using buyer and/or seller routing systems 160 and 170. Network selections 112 and 113 include data that indicates the proper network to route the transactional data.
  • Inputs 114 and 115 receive the transactional data necessary for the selected network of the buyer and seller, respectively. The routing blocks 110 and 111 use this information to send the proper transactional data to the selected network from the possible networks. A network selected for the seller will process the transaction so as to credit the seller for the value of the transaction. A network selected for the buyer will process the transaction so as to debit/charge the buyer for the value of the transaction.
  • The settlement between the two networks can be accomplished using a number of different settlement processes. In one example of a settlement process, the networks can directly communicate with one another. This may be the case where the networks have bilateral agreements with each other. The transactional data received by each network can be used to reconcile the debit and credits for a transaction by, for example, matching a transaction identifier received by each network. Such settlement can be done immediately or on a periodic basis (e.g., daily). In the instance of direct communication between networks, the networks may have a number of settlement options of which the overall system is aware. The overall system can use network profiles and/or business rules to determine if the networks are compatible, and if so, which settlement rules to implement. The system can then provide the networks with the proper data to allow the networks to settle the transaction(s) between one another. The data may include information such as an identification of the settlement protocols to use, communication methods or fee calculations. This can be particularly useful for networks that do not have explicit bilateral agreements with one another, but nonetheless, desire to effect settlement directly with one another.
  • In another example of settlement, the seller and buyer networks do not directly effect settlement with one another. Instead, one or more third parties can be used to effect settlement. For instance, a financial entity 116, such as a bank, can collect from the buyer network while crediting the seller network. The financial entity reconciles the collected and credited amounts. This can be particularly useful for facilitating transactions between networks that are either incompatible or unwilling to interface directly with one another. In another example, the seller and buyer networks may be the same network and the settlement can then be implemented according to a protocol of the selected network.
  • Each of the selected networks is allowed to process the transaction according to their respectively established protocols. In some cases this includes the billing and reporting functions to the buyer and seller. For example, a credit card network can send a statement to the buyer that includes the transaction amount. The buyer is then obligated to repay the proper party within the credit card network. Likewise, the seller could be credited for the value of the transaction through an appropriate network and notified of the transaction details using a transaction statement/report (mailed, online or otherwise).
  • In a particular embodiment, a portion of the system is implemented to facilitate population of the system with buyers and/or sellers. Sellers and buyers alike obtain more value as the number of sellers and buyers participating with a specific network increases. For example, sellers are able to offer the purchase options to more buyers, while buyers are able to use the service at more locations/sellers. This network effect often presents a buyer/seller population problem for newly implemented systems as they often do not have a critical mass of buyers and sellers necessary to make the systems valuable.
  • This population system can include a database of eligible buyers and/or sellers that is used to identify potential new participants in the system. These potential participants can be notified of their eligibility using an acceptable mechanism. For example, the system may detect a purchase placed by a buyer who is a participant in a network associated with the system. The population system can perform a number of different actions with this information. For instance, the identified buyer can be immediately notified of their eligibility. This can be done, for example, by notifying the buyer or seller of the option before the transaction is completed. In some instances, the buyer may be notified of potential savings, or other incentives, should they choose to participate. This can include the option to use one or more preferred accounts associated with a network other than the network that would otherwise be used by the buyer in the instant transaction. In another example, the buyer is notified at a later date. For instance, the buyer could be notified through a targeted mailing or email communication. In another instance, the buyer can be notified of his options in conjunction with a subsequent statement or bill.
  • For further details regarding systems, methods and arrangements for routing, settlement and auditing between multiple networks and accounts reference can be made to the U.S. Provisional Patent Application Ser. No. 60/991,379, entitled “Control System Arrangements and Methods for Disparate Network Systems,” to Dickelman, Mark and filed on Nov. 30, 2007, which forms part of this application and is fully incorporated herein by reference.
  • FIG. 2 shows a block diagram for a payment parsing system, according to an example embodiment of the present invention. Buyer/seller transaction data is captured at point-of-sale (POS) device 204. In a specific example, the buyer presents the seller with identification information, such as an identification card 202 (e.g., a debit/credit card). POS device 204 can capture data that identifies properties of items involved in the transaction. The captured data is sent to system 206. System 206 provides authorization and payment to the seller at block 208. The payment can originate from account 212. Account 212 can be implemented in a number of different manners.
  • In one instance, account 212 is a default account of the buyer. The account 212 is the default account in the sense that the account is suitable for use with all items in the transaction. Example accounts include, but are not limited to, credit card accounts, debit card accounts, savings accounts, checking accounts, pre-paid card accounts and a loan extended by a financial institution.
  • In another instance, account 212 represents a financial institution's temporary payment on behalf of the buyer. The financial institution can extend temporary credit to the buyer until such a time as the transaction has been parsed and the proper accounts have been debited.
  • Payment processor 210 receives the transaction data and parses the data into groups of items. The groups of items are determined using a set of profile rules that can be tailored to the specific buyer, the type of transactions and the available accounts 220. The transaction amount relative to the parsed groups of items can then be debited from the appropriate accounts 220. These amounts can then be used to offset the outstanding balance of account 212.
  • In a specific embodiment, the system can submit a parsed group of items to be debited from a selected account. The account can be selected by transaction processor 216 using various data 218 including, but not limited to, business rules, profile information, transaction-specific information and input from the buyer or seller. A database is used to store the current status of the group of items as represented by pending transaction warehouse 214. Once an account responds to the submission by the system, pending transaction warehouse 214 can be updated accordingly. A selected account may respond in various fashions. In one instance, the selected account determines that the entire transaction amount for the submitted group is covered from the account. In another instance, the selected account determines that the entire transaction amount for the submitted group is not covered from the account. Other examples include partial coverage of the transaction amount or indications of delays in processing the submitted group.
  • If the entire transaction amount is indicated as being covered by the account, then the default account can be credited for the transaction amount. If the transaction amount is indicated as not being covered (entirely or partially) by the account, then the system can determine if there is another buyer account to which the selected group is to be submitted.
  • In one instance, the selection of the second account involves use of a sorted list of eligible accounts. The list can be sorted according to business rules that select the most desirable accounts first and the less desirable accounts last. The transaction amounts can be submitted to the accounts in descending order so as to allow the preferred accounts to be used first. For instance, the system first submits transactions information for a group of items to a preferred account. The preferred account provides an indication as to how much, if any, of the transaction amount is acceptable. Any remaining transaction amount can then be submitted to the next account in the sorted list. Alternatively, the system can submit the transaction information to multiple (or all) of the eligible accounts relatively simultaneously. The accounts can indicate how much, if any, of the transaction amount will be accepted. The system can then partition the transaction amount between the various accounts according to the indications.
  • In another instance, the system submits transaction information about a group of items to a first account that is selected according to a set of business rules and user profile information. Upon receiving, from the first account, an indication regarding details about acceptance of the transaction, the system modifies the status of the group of items accordingly. The system then uses the modified status to select a second account according to a set of business rules and user profile information. This recursive process can be continued until the transaction for the group of items is settled or no eligible accounts remain. This can be particularly advantageous for applications where the indications from the accounts affect the selection of an account. For example, the preferred account may change based upon the amount of the transaction remaining, or in response to some of the items of the group which may have been compensated for by another account. Thus, the recursive nature can be useful for a system that dynamically prioritizes accounts based upon input from one or more accounts.
  • According to one embodiment of the present invention, parsing of the items can be facilitated using input from the buyer. In one such example, the buyer is able to enter a desired or suggested parsing for the system to implement. In another example, the buyer is able to verify and/or modify a suggested parsing presented by the system.
  • FIG. 3 shows a flow diagram for transaction data, according to an example embodiment of the present invention. Merchant/Seller 304 accepts a buyer identifier 302 from a buyer desiring to purchase various merchant/seller offerings (e.g., items or services). In one instance, the seller captures information from the buyer identifier 302 and data 308, representing the transaction items, using POS device 306. Alternatively, transaction data 308 can be supplemented by buyer input at a later time (e.g., via a website that allows the buyer to provide parsing information about the transaction). The captured data is sent to parsing processor 310. A suspense account 303 is debited for the transaction. Parsing processor 310 associates the items found in data 308 to buyer accounts to generate parsed data 311. The associated accounts are debited using settlement processor 312. Settlement processor debits the appropriate buyer accounts 314 and credits suspense account 303. Seller 304 is also credited for the transaction amount. Optionally, authorization processor 316 authorizes the transaction by notifying the POS device 306.
  • Suspense account 303 can be implemented in a variety of manners. For instance, suspense account 303 can be a default account of the buyer. Examples include, but are not limited to, a credit card account or a checking/savings account. In this instance, suspense account 303 is initially debited to pay the seller. If any of the buyer accounts 314 are debited, the amount can be credited to suspense account 303. Optionally, the system could credit another user account. This flexibility allows the buyer to shift funds depending upon various parameters. For instance, the suspense account 303 may be a credit card account. The buyer may desire that rather than crediting this account, the credit should be applied instead to a savings account. One reason for such a transfer is that the buyer may wish to receive interest on the credited amount. Presumably, the buyer would transfer funds from the savings (or another) account prior to the payment due date for the credit card.
  • Another possibility is that suspense account 303 is a seller account. The seller account represents a temporary extension of credit to the buyer. In such instances, an authorization from the system can be particularly advantageous as it can provide the seller with a level of confidence (e.g., that the buyer has sufficient means to pay for the transaction).
  • In yet another instance, suspense account 303 is a third party account. For example, if the system is operated, in part, by a financial institution such as a bank, the bank may implement the suspense account 303 on behalf of the buyer. The credit to the seller would come from such an account and the settlement from the buyer accounts would compensate for this credit. In a specific instance, the suspense accounts are implemented as individual accounts for each buyer who enrolls in the system.
  • Another possibility involves one or more providers of the buyer accounts implementing suspense account 303. In this manner, a provider of an account initially credits the seller. It may be that the provider does not debit the entire amount credited from the buyer's account, leaving an outstanding balance. The provider could directly bill the buyer for the outstanding amount. Alternatively, the provider could notify the system of the outstanding amount. The system could then submit the outstanding balance to another eligible account and/or bill the buyer for the remaining amount.
  • Database 309 stores data for pending settlements related to various transactions. The system updates the data as accounts 314 are debited. Database 309 is updated according to the debited amounts. In a particular instance, the updated data is processed to parse the transactions again. In this manner, recursive parsing is implemented until the transaction has been settled, no options remain for buyer accounts, or some other threshold criterion is met.
  • In one instance, authorization processor can receive data about the associated buyer accounts that indicate whether the transaction is valid. This can include, for example, information regarding current account balances, periodic limits on transaction amounts, buyer-defined constraints and/or tax laws.
  • In various instances, the entire process can be implemented in relatively rapid fashion allowing the seller and buyer authorization and settlement to be completed at the time of the initial transaction. In other instances, portions of the transaction can be completed at a later date. One such instance involves the use of a temporary or default account. This default account can be used to verify the transaction and to pay the seller. The parsing of the items and debiting of the associated accounts can then be accomplished at a later time. Such processing functions can occur on a periodic basis.
  • FIG. 4 shows a flow diagram for processing transaction data to be used by a network routing arrangement, according to an example embodiment of the present invention. Parsing processor 402 receives transaction data that includes a number of different items involved in the transaction. In one implementation, parsing processor 402 can group the items independent of knowledge of the accounts held by the buyer. For example, parsing processor can tag each item with multiple eligibly account types (e.g., insurance claim, health-savings account and credit card). This determination can be made based upon an item identifier (e.g., universal product code (UPC), textual product description or custom identifiers) or upon buyer provided data (e.g., via a website).
  • Optionally, the parsed transactions 406 can then be sent to an authorization processor 410. Authorization processor 410 can make a determination as to whether the system determines that the transaction is valid. Notification of the determination can then be sent to the seller and buyer.
  • The parsed buyer transaction data 408 is sent to account selection 412. Buyer profiles 414 and business profiles 416 determine the proper network and account for each transaction item. This can be accomplished, for example, by correlating the eligible accounts indicated by the tag with accounts available to the particular buyer. Additional data can also be used in the determination step. For example, account balances, buyer preferences, associated fees, transaction amount limits, tax implications and account-based interest can each be included into the determination of which account an item is to be assigned. The determined/assigned account is then sent to system select input 420. The transaction data (e.g., transaction amount and account identifier) is sent to input 422. The transaction data is routed to the appropriate buyer account(s) 418 for processing and/or settlement.
  • Optionally, the selected buyer network can provide feedback to ultimately be used by authorization processor 410 in a determination of whether the transaction is valid.
  • FIG. 5 shows a flowchart for a process that is consistent with an example embodiment of the present invention. At step 502, items of a transaction are parsed according to the item types, their costs or other transaction data. The parsed items are associated with one or more eligible buyer accounts at step 504. Assuming there are eligible accounts indicated for a particular group (per decision step 506), the process proceeds to step 508. If there are no eligible accounts and/or payment may not be completely covered, the process can proceed to step 514 to institute default payment rules (e.g., paying from a default account) or dispute resolution/collection.
  • At step 508, a particular account is selected. This selection step can be accomplished by taking in a number of different parameters and considerations. Example factors include, but are not limited to, the amount of the transaction, known limits of various buyer accounts, tax implications, interest rates and the type of items in the transaction. This process can be particularly useful for allowing modularity in the various components. As an example, when selecting preferred accounts, the system could implement an algorithm that attempts to maximize gains of the buyer. Alternatively, the system could instead implement an algorithm that maximizes gains of the system implementer or the seller. Other possibilities include, but are not limited to, maximal efficiency between all parties, reduced tax implications and predictive algorithms.
  • In certain embodiments, more than one account can be selected at the same time. The amount of the transaction can be split between multiple buyer accounts, or the entire transaction amount can be sent to each buyer account and actual debits from the accounts can be determined from the responses from the buyer account systems. For example, if the transaction is for $100 and there are 3 potential/eligible accounts, the first approach would involve portioning the $100 between the eligible accounts (e.g., $40 to a first, $60 to a second and $0 to a third). The second approach would send $100 request to each of the 3 buyer accounts. The buyer accounts would respond with an indication of how much, if any, of the transaction amount is approved (e.g., $80 from a first, $50 from a second and $0 from a third). The system could then apportion the $100 between the accounts as desired (e.g., $50 from the first and $50 from the second or $80 from the first and $20 from the second).
  • At step 510, a request for payment is sent to the selected account(s) and a response is subsequently received.
  • Decision step 512 depends upon whether or not the entire transaction amount has been covered from the buyer accounts. If it has, the system can complete the transaction processing at step 516. If the entire transaction amount has not been accounted for, the system can return to decision step 506. An optional implementation includes a time-window function. This can be useful, for example, with insurance policy claims that may take several days or even weeks to receive a response. If a response has not been received within the time window, the process can proceed by attempting to debit from another account. The insurance claim can then either be maintained or it can be canceled.
  • Optionally, the system can implement one of two different paths shown by the dotted area 520. In this optional implementation, the transaction data is updated at step 518. This update can include information received from selected buyer account(s) providers. For example, an account provider may provide a value of the transaction that is acceptable, a list of items that are acceptable/unacceptable or a time-period before any transaction can be authorized. This information can then be used in either or both of steps 502 and 504.
  • FIG. 6 shows a block diagram depicting various elements of a system implemented consistent with an example embodiment of the present invention. Sellers 610 provide various products or services to buyer 600. The transactional data is captured and sent to parsing system 630. Parsing system 630 parses the transaction data. The parsed transaction data can then be sent to selected buyer accounts provided by various institutions/companies 640. In certain embodiments the buyer 600 is allowed to access transaction data from the parsing system 630 using a network interface, such as a website or dedicated software.
  • The institutions/companies 640 shown are representative of a few examples including, but not limited to, investment companies, financial institutions, educational institutions, businesses and governmental institutions. Moreover, the provider of parsing system 630 may hold one or more buyer account types.
  • In a specific embodiment, the provider of parsing system 630 is a banking institution. Such institutions can be particularly well situated to provide the interfaces between varieties of different account providers.
  • A specific aspect of the present invention includes the selection of the buyer account for various parsed groups of items. In one implementation, buyer 600 can provide input (e.g., monitoring, confirmation or parsing selections) via a personal interface 620, such as a home computer. The selection is accomplished using one or more selection algorithms, which can be tailored to the specific implementation, current laws and regulations, the financial markets, current interest rates and a host of other parameters, some of which are subject to continual changes. As such, an exhaustive description of all such algorithms, related business rules, and possible input data would be impractical. An example set of business-rule data for various medical items is provided in Table 1.
  • TABLE 1
    Predefined (Medical) Default
    Parsed Group Cost Medical Service Precription Rule Account# Account#
    Buyer-1
    1 $100 Y N Y N HSA#, Credit
    Insurance# Card#
    2 $30 Y Y N Y HAS#, Credit
    Insurance# Card#
    Buyer-2
    1 $3,000 Y Y N N MSA#, Savings
    Insurance# Account#
    2 $100 Y N Y N MSA#, Savings
    Insurance# Account#
    3 $320 Y N Y Y MSA#, Savings
    Insurance# Account#
  • Table 2 shows an example set of business-rule data for various non-medical items.
  • TABLE 2
    Predefined Default
    Parsed Group Cost Medical Personal Business Rule Account# Account#
    Buyer-1
    3 $250 N N Y N Personal#, Credit
    Business# Card#
    4 $70 N Y N Y Personal#, Credit
    Business# Card#
    Buyer-2
    4 $2,322 N Y N N Personal#, Savings
    Business# Account#
    5 $43 N N Y N Personal#, Savings
    Business# Account#
    6 $75 N N Y Y Personal#, Savings
    Business# Account#
  • As show in Tables 1 and 2, the transaction involving Buyer-1 has four parsed item groups and the transaction involving Buyer-2 has six parsed groups. Table 1 shows the medically-related groups for each buyer, whereas Table 2 shows the non-medically-related groups for each buyer. For each of the medically-related groups, the table includes data regarding the cost of the group and whether the group includes a service and/or a prescription. Other data includes whether a predefined rule exists for the group. Such predefined rules can be implemented as, for example, a rule setup by the buyer or rules dictated by laws or regulations. Table 1 also includes data regarding the Medical Account numbers, as well as a default account number. Table 2 contains non-medically related information, such as whether the group is personal or for business.
  • The business rules and related algorithms use the data in Tables 1 and 2 as inputs in the selection of a buyer account to associate with the particular group. Although not shown, buyer-specific data (e.g., account limits/balances, buyer selected preferences, buyer credit-history or other buyer data) can also be used in selection of a buyer account. Example algorithms include the use of (alone or in combination) lookup tables, statistical weighting of inputs, adaptive learning, calculations or predictions of the cost/fees, and/or predicted tax consequences.
  • For instance, the buyer account can be selected by accessing a lookup table in a database, where the lookup table is indexed by one or more of the data from the above tables. The entries in the lookup table can be populated to be consistent with a set of business rules regarding transactions and the buyer accounts. In a specific example, a lookup table is initialized and/or modified according to data provided by one or more analytical/optimization algorithms. Sets of input data can be input into the algorithm(s). The output of the algorithm(s) can include the desired account type(s) for each set of input data. This results in a matching between each set and specific types of accounts. This matching can be used to populate or modify the lookup table. As the lookup table need not require that the algorithm be run, the need to execute the algorithm(s) for each buyer account selection can be alleviated. This can be particularly useful where the algorithm(s) are particularly complex and/or processing intensive. Where multiple algorithms are used, some algorithms may be tailored to different outcomes (e.g., maximize short/long-term gains, minimize tax implications, minimize fees or optimize gain/costs for certain/all parties). In a specific instance, different lookup tables can be set up for each algorithm. A specific lookup table can be selected according to the buyer-selected-profile (e.g., the buyer selects short term gain as an important factor). Alternatively, multiple lookup-tables can be used where multiple buyer accounts result from different lookup-tables, a selection can be made therefrom.
  • In a specific buyer-account-selection algorithm, data from the above tables is assigned a weight-factor. A computer implements an algorithm that uses the weighted data to determine the preferred account. This allows for certain data to be afforded more importance. The weight factors can represent priorities assigned to the different data inputs. These priorities can be determined, for example, from statistical data, the owner of the system, the buyer, the seller, providers of the buyer account, or combinations thereof.
  • In another buyer-account-selection algorithm, the algorithm uses a database of prior history to determine the buyer accounts. In a specific example, an unsupervised learning algorithm can be employed. The unsupervised learning algorithm takes all the data available and develops probabilistic models from the data. For example, one such algorithm may be used to determine the likelihood that a buyer will make a payment on-time. This can affect the desired account, as some accounts may charge higher penalties and/or interest rates. Should the desired result be a minimization of buyer costs and the buyer is deemed to be likely to make a late payment, the accounts can be selected accordingly.
  • Another example buyer-account-selection algorithm employs a supervised learning model. The algorithm develops a model to conform with sets of inputs that are matched to sets of outputs. This can provide a model for predicting any number of different outcomes (e.g., fees, chance of acceptance by account or delay time in processing) from the available input data (e.g., transaction amount, item descriptions or buyer account).
  • Both supervised and unsupervised modeling can be useful for continual updating of the models and the resulting selection of the buyer account made by the system. Particularly, as the system continues to operate, the database of knowledge can be updated accordingly. The updates to the database allow for modification of, for example, the buyer account selection. Such modeling can also be particularly useful for adding, removing or otherwise changing the input data or output data used in selecting a buyer account.
  • Another aspect of the invention involves the use of various methodologies to parse the transaction items. FIG. 7 shows an example flow diagram that can be used in connection with parsing of transaction items. The different nodes 1-27 represent different categories that may be relevant to grouping of the items. In a simplistic selection method, a single path is traversed for each item until the final node is reached. The final node represents the category for the item. For example, a prescription medication would follow the node path: 0=>1=>3=>8=>15. The prescription medication could then be grouped with other items that fall into node 15.
  • As shown in FIG. 7 (e.g., nodes 11 and 12), there may be several paths to reach the same node. In certain applications, the path used to reach the node may not be important. For applications that path information is important, this path data can be used in the final grouping. Thus, for the prescription medication example provided above, the node information could include the entire path set {0, 1, 3, 8, 15} or portions thereof. This data can be used in grouping the various items. In specific instances, a lookup table can be consulted to determine the grouping for each item. Thus, the path set {0, 1, 3, 8, 15} may point to a grouping N in a lookup table.
  • Certain items can follow more than one path or have more than one final node. For example, an item may be related to both travel (22) and government (20). Such situations can be handled in a number of different manners, one of which involves establishing priorities between the various nodes. A buyer account associated with a higher priority node can be used before those of a lower priority node. This can be particularly useful when implementing a recursive process, such as that discussed in connection with FIG. 5. For example, assume that a transaction group exists that relates to multiple nodes having different priorities. The system can first submit the transaction group to the buyer account associated with the highest priority node. Should this buyer account not provide a credit for the item or provide only partial credit for the item, a buyer account associated with a lower-priority node can be used.
  • Another possible mechanism for handling such situations involves using each of the nodes to select a buyer account. This can result in multiple buyer accounts being selected and used. As discussed in more detail above, multiple buyer accounts for the same group of items can be contacted in either a parallel fashion or a serial fashion and the transaction amount can be split between the buyer accounts or the full amount can be submitted to each buyer account.
  • Aspects of the parsing method are directed to how the system determines the proper categorization of each item. In a simple implementation, an identifier provides all details necessary to categorize and parse the items. Example identifiers include, but are not limited to, a UPC, an insurance code/descriptor and textual descriptions. While these identifiers contain specific information, they may or may not be known by the system prior to being received. For example, new products are continually reaching the market, and an exhaustive list of each new product would be, at best, difficult to maintain. Should the specific item be known with certainty, however, the categorization can be accomplished using a simple lookup of the categorization associated with the identifier. This can be particularly useful for items/applications for which a standardized identifier is used in the buyer-seller transaction.
  • For items where the transaction data does not lend itself to a simple lookup procedure (e.g., new products or unknown/uncertain product identifiers), various other methods can be used. One method involves categorization of such items and using the categorization to populate a lookup table as transaction data. For example, a previously unknown identifier or combination of transaction data is first compared against the lookup table. Assuming that the lookup table does not have an entry for the identifier, categorization can be determined for the identifier. Once a categorization is known, the lookup table can be populated accordingly.
  • One example method for determining the proper categorization is to allow the buyer to select a proper categorization. The buyer could select the categorization using an online interface such as a website or other software configured to interface with the system. The buyer can provide such an indication by explicitly selecting a certain category. Alternatively, the buyer can answer a set of questions regarding the specific item and related transaction. The set of questions can be provided by the system and tailored to correctly categorize the item. Such questions can be particularly useful for properly categorizing the item(s) without requiring the buyer to know the proper rules behind each categorization.
  • Another example method for determining the proper categorization is to use prediction algorithm(s) to determine the most likely categorization. For instance, these algorithms can use a variety of textual recognition and/or draw from a database of past categorizations based upon similar transaction data. Both supervised and unsupervised learning algorithms could be employed to predict the proper categorization.
  • In certain instances an item may be improperly categorized. This could be detected, for example, where the selected buyer account holder rejects the item or where the buyer corrects the categorization. The system can use this data to update accordingly, including updates to any lookup tables or prediction models.
  • While the particular parsing tree of FIG. 7 uses medical and nonmedical as the first parsing level, the invention is not so limited. Additional and/or different parsing selections can also be implemented.
  • The various embodiments describe herein can be implemented using one or more processors running software configured to implement various functions described herein. The system allows for modularity in a number of aspects including the interfaces between the various components. The specific code and algorithms for implementing many of the functions would depend upon the particulars of implementation. For example, an Internet-based sale may use secure-socket-layer protocols. A seller interface using a credit/debit transaction card reader at the point-of-sale device might use protocols consistent with various transaction processing networks (e.g., Nabanco, Omaha, Paymentech, NDC Atlanta, Nova, Vital, Concord EFSnet, and VisaNet). The various buyer accounts may use a variety of (in some cases proprietary) protocols and standards. Moreover, these and other standards are often subject to continual updates and changes. As such, a discussion of each individual protocol and implementation is not practical. The skilled artisan would recognize that these and other variations do not depart from the heart of the invention.
  • The various embodiments described above are provided by way of illustration only and should not be construed to limit the invention. Based on the above discussion and illustrations, those skilled in the art will readily recognize that various modifications and changes may be made to the present invention without strictly following the exemplary embodiments and applications illustrated and described herein. For instance, such changes may include the implementation of various components by different entities that may or may not operate at arms length from one another. Such modifications and changes do not depart from the true spirit and scope of the present invention.

Claims (14)

1. For use by a computer arrangement in response to a transaction that involves a plurality of items and transaction data about a cost of each item and a description of each item, a method comprising:
identifying a plurality of buyer accounts;
processing financial data to facilitate payment for the items, in response to the description of each item and to a set of business rules that associate item types with buyer accounts, by:
parsing the transaction data by matching respective sets of the plurality of items to respective buyer accounts of the plurality of buyer accounts, and
using the matched buyer accounts to facilitate payment for the respectively matched sets.
2. The method of claim 1, further including the steps of
further parsing the transaction data, responsive to less-than-all payment for the respective matched sets, by further matching respective sets of the plurality of items to further respective buyer accounts of the plurality of buyer accounts, and
using the further matched buyer accounts to facilitate payment for the further respectively matched sets.
3. The method of claim 1, further including the step of, for respective the sets of the plurality of items, generating a prioritized list of eligible buyer accounts.
4. The method of claim 2, further including the steps of,
receiving a payment indication from a selected buyer account that indicates that the selected buyer account will not provide a credit for the entire value of the payment request; and
responsive to the payment indication, selecting another eligible buyer account from the prioritized list of eligible buyer accounts.
5. The method of claim 1, wherein the steps of parsing, selecting and using are repeated in response to receiving a payment indication from the selected buyer account that indicates that the selected buyer account will not provide a credit for the entire value of the payment request.
6. The method of claim 1, wherein the plurality of buyer accounts includes one or more accounts that have use limitations related to healthcare.
7. A computer-based payment system responsive to a transaction that involves a plurality of items and transaction data about a cost of each item and a description of each item, a payment system comprising:
a processor arrangement for identifying a plurality of buyer accounts;
parsing the transaction data by matching respective sets of the plurality of items and to respective buyer accounts of the plurality of buyer accounts, in response to the description of each item and a set of business rules;
responsive to the parsed transaction data, selecting a buyer account for a set of the sets of the plurality of items; and
sending a payment request to the selected buyer account for a value based upon the respective sets of the plurality of items.
8. For use in a transaction between a seller and buyer that involves a plurality of items and transaction data that includes information about a cost of each item and a description of each item, a method comprising:
providing a front-end interface that accepts a credit network identifier or a debit network identifier;
using a network identifier from the buyer to select a suspense account to effect payment to the seller using a credit network or a debit network;
parsing the transaction data by matching respective sets of the plurality of items and to respective buyer accounts of a plurality of buyer accounts, in response to the description of each item;
collecting payment from the matched buyer accounts; and
applying the collected payment to the selected suspense account.
9. A system for facilitating payment between sellers providing goods or services to buyers paying for the goods or services, the payment being provided between disparate payment networks of the buyers and sellers, the system comprising:
an interface to receive transaction data that includes a buyer identifier, a seller identifier, and a transaction amount;
a payment parser to tag items in the transaction data with one or more buyer accounts;
a payment network selector to receive the transaction data from the interface and to select a payment network for the buyer as a function of respective profile data and the tagged one or more buyer accounts; and
a routing arrangement for routing a portion of the transaction data to the selected payment network and another portion of the transaction data to a disparate payment network, wherein, for the transaction amount, an account held at the selected payment network is one of debited and credited and an account held at the disparate payment network is the other of debited and credited.
10. The system of claim 9, wherein the payment parser is responsive to buyer-provided parsing selections of the transaction data.
11. A computer automated system for performing operations that occur for a transaction involving a plurality of merchant offerings that are parseable by merchant offering identifiers, the operations including:
for a plurality of identified buyer accounts from which monetary payables (e.g., cash, credit and/or debit limits) are tracked, accessing stored data sets indicative of types of merchant offerings to be associated with particular ones of the plurality of buyer accounts;
facilitating payment for the items as a function of at least one of the plurality of buyer accounts; and
tracking payment for the items as a function of the merchant offering identifiers.
12. The computer automated system of claim 11, wherein facilitating payment for the items includes debiting one account of the plurality of buyer accounts by an amount that corresponds to the amount for the entire transaction, and debiting other buyer accounts of the plurality of buyer accounts in respective amounts corresponding to different ones of the plurality of merchant offerings.
13. The computer automated system of claim 11, wherein facilitating payment for the items includes debiting one of the plurality of buyer accounts by an amount that corresponds to the amount for the entire transaction.
14. The computer automated system of claim 11, wherein facilitating payment for the items includes debiting one of the plurality of buyer accounts in amounts that correspond all to at least two different types of the plurality of merchant offerings involved in the transaction and, relative to said amount debited from one of the plurality of buyer accounts, debiting other ones of the plurality of buyer accounts in respective amounts corresponding to different ones of said at least two different types of the plurality of merchant offerings.
US12/131,597 2007-11-30 2008-06-02 Computer automated systems, devices and methods for data processing of accounting records Abandoned US20090144194A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/131,597 US20090144194A1 (en) 2007-11-30 2008-06-02 Computer automated systems, devices and methods for data processing of accounting records
US15/089,780 US9881131B1 (en) 2007-11-30 2016-04-04 Computer automated systems, devices and methods for data processing of accounting records

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US99137907P 2007-11-30 2007-11-30
US12/131,597 US20090144194A1 (en) 2007-11-30 2008-06-02 Computer automated systems, devices and methods for data processing of accounting records

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/089,780 Division US9881131B1 (en) 2007-11-30 2016-04-04 Computer automated systems, devices and methods for data processing of accounting records

Publications (1)

Publication Number Publication Date
US20090144194A1 true US20090144194A1 (en) 2009-06-04

Family

ID=40676725

Family Applications (3)

Application Number Title Priority Date Filing Date
US12/131,597 Abandoned US20090144194A1 (en) 2007-11-30 2008-06-02 Computer automated systems, devices and methods for data processing of accounting records
US12/323,127 Active 2032-05-07 US9147184B2 (en) 2007-11-30 2008-11-25 Control system arrangements and methods for disparate network systems
US15/089,780 Active US9881131B1 (en) 2007-11-30 2016-04-04 Computer automated systems, devices and methods for data processing of accounting records

Family Applications After (2)

Application Number Title Priority Date Filing Date
US12/323,127 Active 2032-05-07 US9147184B2 (en) 2007-11-30 2008-11-25 Control system arrangements and methods for disparate network systems
US15/089,780 Active US9881131B1 (en) 2007-11-30 2016-04-04 Computer automated systems, devices and methods for data processing of accounting records

Country Status (1)

Country Link
US (3) US20090144194A1 (en)

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090327148A1 (en) * 2008-06-27 2009-12-31 Microsoft Corporation Mechanisms and architecture for mobile opportunistic commerce
US20100093306A1 (en) * 2008-10-09 2010-04-15 West Corporation System and method for availing information relating to a circumstance
US20100145856A1 (en) * 2008-12-08 2010-06-10 Laima Kardokas Automated merchant performance rating for payments on account
US20110022517A1 (en) * 2009-07-22 2011-01-27 Ayman Hammad Apparatus including data bearing medium for authorizing a payment transaction using seasoned data
US20110119189A1 (en) * 2009-11-18 2011-05-19 American Express Travel Related Services Company, Inc. Data processing framework
US20110119274A1 (en) * 2009-11-18 2011-05-19 American Express Travel Related Services Company, Inc. File listener system and method
US20110119178A1 (en) * 2009-11-18 2011-05-19 American Express Travel Related Services Company, Inc. Metadata driven processing
US20110119188A1 (en) * 2009-11-18 2011-05-19 American Express Travel Related Services Company, Inc. Business to business trading network system and method
US20120089521A1 (en) * 2010-01-11 2012-04-12 Abrevaya Adam Method and apparatus for billing purchases from a mobile phone application
US8639587B1 (en) * 2013-03-14 2014-01-28 Google Inc. Method, medium, and system for secure direct purchase
US8738049B1 (en) * 2012-11-05 2014-05-27 International Business Machines Corporation Converged dialog in hybrid mobile applications
US8805725B2 (en) * 2012-06-18 2014-08-12 Bank Of America Corporation Payment vehicle recommendations based on payment rules
US20140337234A1 (en) * 2013-05-09 2014-11-13 Dresser, Inc. Systems and methods for secure communication
US20150278810A1 (en) * 2014-03-28 2015-10-01 Confia Systems, Inc. Device commerce using trusted computing system
US9430796B1 (en) 2013-10-16 2016-08-30 Google Inc. Direct purchase from user-received advertisement
US9602292B2 (en) 2015-07-25 2017-03-21 Confia Systems, Inc. Device-level authentication with unique device identifiers
US9603019B1 (en) 2014-03-28 2017-03-21 Confia Systems, Inc. Secure and anonymized authentication
US20190205858A1 (en) * 2013-11-19 2019-07-04 Wayne Fueling Systems Llc Systems and Methods for Convenient and Secure Mobile Transactions
US10484359B2 (en) 2015-07-25 2019-11-19 Confia Systems, Inc. Device-level authentication with unique device identifiers
US20210201316A1 (en) * 2019-12-27 2021-07-01 Lendingclub Corporation Multi-layered credit card with transaction-dependent source selection

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US8931058B2 (en) 2010-07-01 2015-01-06 Experian Information Solutions, Inc. Systems and methods for permission arbitrated transaction services
US8744956B1 (en) 2010-07-01 2014-06-03 Experian Information Solutions, Inc. Systems and methods for permission arbitrated transaction services
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
US9047636B2 (en) * 2011-02-25 2015-06-02 Bank Of America Corporation Dynamic determination of appropriate payment account
US9665854B1 (en) 2011-06-16 2017-05-30 Consumerinfo.Com, Inc. Authentication alerts
US9106691B1 (en) 2011-09-16 2015-08-11 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US9195999B2 (en) 2012-10-24 2015-11-24 Mastercard International Incorporated Methods and systems for routing e-invoices
US8856894B1 (en) 2012-11-28 2014-10-07 Consumerinfo.Com, Inc. Always on authentication
US9514456B2 (en) 2013-03-14 2016-12-06 Bank Of America Corporation Single payment card for flexible payment vehicle options for a transaction
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US10373240B1 (en) 2014-04-25 2019-08-06 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
WO2016116943A2 (en) * 2015-01-23 2016-07-28 Al Rafae Badr M Front end transaction system
US10051015B2 (en) 2015-10-30 2018-08-14 Bank Of America Corporation System for configuration, device connectivity and device control based on user selection
US10158535B2 (en) 2015-10-30 2018-12-18 Bank Of America Corporation System for active configuration of devices based on user selection
USD815107S1 (en) 2015-10-30 2018-04-10 Bank Of America Corporation Display screen with a transitional graphical user interface
US10091206B2 (en) 2015-10-30 2018-10-02 Bank Of America Corporation System for discovery of devices and connections associated with a device
USD784403S1 (en) 2015-10-30 2017-04-18 Bank Of America Corporation Display screen with a transitional graphical user interface
US9929917B2 (en) 2015-10-30 2018-03-27 Bank Of America Corporation System for configuration and device connectivity based on user selection
US10430025B2 (en) 2015-10-30 2019-10-01 Bank Of America Corporation Active selection configuration system with suggested actions
US10031645B2 (en) 2015-10-30 2018-07-24 Bank Of America Corporation Application connectivity for aggregation
US10095497B2 (en) 2015-10-30 2018-10-09 Bank Of America Corporation System for discovery of software operable on a device
US10048836B2 (en) 2015-10-30 2018-08-14 Bank Of America Corporation Application connectivity for aggregation and for use in data filtering
US10909541B1 (en) * 2017-06-21 2021-02-02 Wells Fargo Bank, N.A. Mobile wallet application with payment receipt support
US10911234B2 (en) 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
KR20200034020A (en) 2018-09-12 2020-03-31 삼성전자주식회사 Electronic apparatus and control method thereof
RU191684U1 (en) * 2019-05-29 2019-08-15 Общество с ограниченной ответственностью "Регион-Медсервис" Automated device for organizing a mixed voluntary health insurance system
CN110827001A (en) * 2019-11-07 2020-02-21 深圳乐信软件技术有限公司 Accounting event bookkeeping method, system, equipment and storage medium
US20220029932A1 (en) * 2020-07-22 2022-01-27 Bank Of America Corporation Electronic system for processing technology resource identifiers and establishing dynamic context-based cross-network communications for resource transfer activities

Citations (100)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US78783A (en) * 1868-06-09 Improvement in portable fence
US5426281A (en) * 1991-08-22 1995-06-20 Abecassis; Max Transaction protection system
US5596642A (en) * 1994-09-30 1997-01-21 Electronic Payment Services, Inc. Network settlement performed on consolidated information
US5649118A (en) * 1993-08-27 1997-07-15 Lucent Technologies Inc. Smart card with multiple charge accounts and product item tables designating the account to debit
US5649117A (en) * 1994-06-03 1997-07-15 Midwest Payment Systems System and method for paying bills and other obligations including selective payor and payee controls
US5650604A (en) * 1995-02-22 1997-07-22 Electronic Data Systems Corporation System and method for electronic transfer of funds using an automated teller machine to dispense the transferred funds
US5717989A (en) * 1994-10-13 1998-02-10 Full Service Trade System Ltd. Full service trade system
US6070150A (en) * 1996-10-18 2000-05-30 Microsoft Corporation Electronic bill presentment and payment system
US6105009A (en) * 1997-06-16 2000-08-15 Cuervo; Vincent Automated teller machine dispenser of debit cards
US20010014878A1 (en) * 1998-11-09 2001-08-16 Nilotpal Mitra Transaction method and apparatus
US6292789B1 (en) * 1997-08-26 2001-09-18 Citibank, N.A. Method and system for bill presentment and payment
US6298335B1 (en) * 1995-01-06 2001-10-02 Robert Bernstein Method of controlling payment of debts
US20010034771A1 (en) * 2000-01-14 2001-10-25 Sun Microsystems, Inc. Network portal system and methods
US20020002495A1 (en) * 2000-05-19 2002-01-03 Npax, Inc. Integrated pharmaceutical accounts management system and method
US20020069244A1 (en) * 1999-11-24 2002-06-06 John Blair Message delivery system billing method and apparatus
US20020111886A1 (en) * 2001-02-12 2002-08-15 Chenevich William L. Payment management
US20020111916A1 (en) * 2001-02-12 2002-08-15 Coronna Mark S. Payment management
US20020111915A1 (en) * 2001-02-12 2002-08-15 Clemens Christopher Donald Payment management
US20020145051A1 (en) * 2001-04-09 2002-10-10 Charrin Philippe A. Combined smartcard and magnetic-stripe card and reader and associated method
US6473740B2 (en) * 1998-11-29 2002-10-29 Qpass, Inc. Electronic commerce using a transaction network
US20030009382A1 (en) * 2001-06-12 2003-01-09 D'arbeloff Matthew A. Customer identification, loyalty and merchant payment gateway
US6529187B1 (en) * 2000-10-26 2003-03-04 Mark Dickelman Generalized system for internet and services navigation from keypad equipped internet devices, including browser equipped phones
US20030061229A1 (en) * 2001-09-08 2003-03-27 Lusen William D. System for processing objects for storage in a document or other storage system
US20030061157A1 (en) * 2001-07-24 2003-03-27 Hirka Jeffrey L. Multiple account advanced payment card and method of routing card transactions
US20030061216A1 (en) * 2001-03-27 2003-03-27 Fred Moses System and method for managing objects and resources with access rights embedded in nodes within a hierarchical tree structure
US20030105688A1 (en) * 2001-12-05 2003-06-05 Brown Owen H. Secure digital escrow account transactions system and method
US20030126094A1 (en) * 2001-07-11 2003-07-03 Fisher Douglas C. Persistent dynamic payment service
US20030200179A1 (en) * 1999-08-11 2003-10-23 Khal Hee Kwan Method, apparatus and program to make payment in any currencies through a communication network system using pre-paid cards
US20030212632A1 (en) * 2002-01-07 2003-11-13 S.W.I.F.T.S.C.; Electronic payment initiation and assurance system
US20030225619A1 (en) * 2002-03-15 2003-12-04 Maynard Dokken System and method for dealing with loyalty program points
US20040024703A1 (en) * 2002-07-30 2004-02-05 James Roskind Smart payment instrument selection
US20040030657A1 (en) * 1999-04-23 2004-02-12 First Data Resources, Inc. Financial transaction account usage parameter access and control method
US6701303B1 (en) * 1999-12-23 2004-03-02 International Business Machines, Corp. E-commerce system and method of operation enabling a user to conduct transactions with multiple retailers without certification and/or trusted electronic paths
US20040044621A1 (en) * 2002-08-27 2004-03-04 Visa U.S.A., Inc. Method and system for facilitating payment transactions using access devices
US20040042470A1 (en) * 2000-06-16 2004-03-04 Geoffrey Cooper Method and apparatus for rate limiting
US20040083092A1 (en) * 2002-09-12 2004-04-29 Valles Luis Calixto Apparatus and methods for developing conversational applications
US20040093302A1 (en) * 2001-09-27 2004-05-13 Baker Eric H. System and method for providing logistics for a sale or transfer of goods with proceeds provided to a third party
US20040167852A1 (en) * 2001-05-09 2004-08-26 Cutler Nicholas Leeds Payment system
US20040236632A1 (en) * 2000-12-07 2004-11-25 Maritzen Michael L. System and method for conducing financial transactions using a personal transaction device with vehicle-accessed, payment-gateway terminals
US20050010394A1 (en) * 2000-07-27 2005-01-13 Bergeron Heather Ellen Configuring a semantic network to process transactions
US20050010428A1 (en) * 2000-07-27 2005-01-13 Bergeron Heather Ellen Processing transactions using a semantic network
US6847953B2 (en) * 2000-02-04 2005-01-25 Kuo James Shaw-Han Process and method for secure online transactions with calculated risk and against fraud
US20050033583A1 (en) * 2000-07-27 2005-02-10 Bergeron Heather Ellen Processing transactions using a structured natural language
US20050033605A1 (en) * 2000-07-27 2005-02-10 Bergeron Heather Ellen Configuring a semantic network to process health care transactions
US20050060579A1 (en) * 2003-09-15 2005-03-17 Anexsys, L.L.C. Secure network system and associated method of use
US20050077350A1 (en) * 2003-10-13 2005-04-14 Starbucks Corporation Dual card
US20050080691A1 (en) * 2003-09-26 2005-04-14 First Data Corporation Systems and methods for participant controlled communications regarding financial accounts
US20050198174A1 (en) * 2003-12-30 2005-09-08 Loder Theodore C. Economic solution to the spam problem
US20050222961A1 (en) * 2004-04-05 2005-10-06 Philippe Staib System and method of facilitating contactless payment transactions across different payment systems using a common mobile device acting as a stored value device
US20050274792A1 (en) * 2004-06-09 2005-12-15 Hahn-Carlson Dean W Transaction accounting processing system and approach
US20060036541A1 (en) * 2004-07-16 2006-02-16 Joerg Schleicher Method and system to process credit card payment transactions initiated by a merchant
US20060089906A1 (en) * 2004-10-21 2006-04-27 Michael Rowley Method for securing a payment transaction over a public network
US20060113376A1 (en) * 2004-12-01 2006-06-01 Humana Inc.; Metavante Corporation Account control method and system that allows only eligible and authorized items to be purchased using the account
US20060116957A1 (en) * 2000-03-17 2006-06-01 Jason May Method and apparatus for facilitating online payment transactions in a network-based transaction facility
US20060173672A1 (en) * 2000-07-27 2006-08-03 Bergeron Heather E Processing health care transactions using a semantic network
US7092913B2 (en) * 2002-02-26 2006-08-15 Cannon Jr Thomas Calvin System for inexpensively executing online purchases
US20070017976A1 (en) * 2005-07-19 2007-01-25 Plastyc Inc. System and method for child card payment
US7174302B2 (en) * 2001-06-11 2007-02-06 Evolution Benefits, Inc. System and method for processing flexible spending account transactions
US20070038577A1 (en) * 2005-08-15 2007-02-15 Werner Gerald C Method of purchasing digitally encoded music, audiobooks, and video by one party for subsequent delivery to a third party
US20070061255A1 (en) * 2005-09-12 2007-03-15 Epting Thomas W Point of Sale Credit System
US20070112671A1 (en) * 2003-12-17 2007-05-17 Guaranteed Markets Ltd Transaction management system and method
US20070168910A1 (en) * 2003-04-10 2007-07-19 Charismatek Software Metrics Pty Ltd Automatic sizing of software functionality
US20070174160A1 (en) * 2003-04-29 2007-07-26 Solberg Eric L Hierarchical transaction filtering
US20070175985A1 (en) * 2004-11-19 2007-08-02 American Express Travel Related Services Company, Inc. Linking Transaction Cards With Spending Accounts
US20070179873A1 (en) * 2003-04-29 2007-08-02 Solberg Eric L Transaction allocation
US20070233597A1 (en) * 2006-03-06 2007-10-04 First Data Corporation Least cost network routing for electronic transactions
US20080014908A1 (en) * 2006-07-17 2008-01-17 Abraham Vasant System and method for coordinating customized mobility services through a network
US20080015985A1 (en) * 2006-07-11 2008-01-17 Armand Abhari System and process for expedited payment through online banking/payment channel
US20080021813A1 (en) * 2006-07-21 2008-01-24 Sheshunoff Management Services, Lp Method for scoring accounts for retention and marketing accounts based on retention and profitability
US20080025572A1 (en) * 2006-04-18 2008-01-31 Schneider John K Augmented Biometric Authorization System And Method
US20080046366A1 (en) * 2006-06-29 2008-02-21 Vincent Bemmel Method and system for providing biometric authentication at a point-of-sale via a mobile device
US20080046358A1 (en) * 1998-04-24 2008-02-21 First Data Corporation Methods For Processing A Group Of Accounts Corresponding To Different Products
US20080097783A1 (en) * 2000-11-17 2008-04-24 Iannacci Gregory F System and method for preference-based account enrollment
US20080103968A1 (en) * 2006-10-31 2008-05-01 Discover Financial Services Llc Redemption of Credit Card Rewards at a Point of Sale
US20080109320A1 (en) * 2006-11-06 2008-05-08 Jonathan Kleinhans Interactive RFID Transaction Automation
US7383223B1 (en) * 2000-09-20 2008-06-03 Cashedge, Inc. Method and apparatus for managing multiple accounts
US20080154773A1 (en) * 2000-02-10 2008-06-26 Jove Corporation System and method for secure data and funds transfer
US20080162295A1 (en) * 2006-12-29 2008-07-03 Ebay Inc. Method and system for payment authentication
US20080201769A1 (en) * 2007-02-15 2008-08-21 Peter George Finn System and method for processing payment options
US20080218338A1 (en) * 2007-03-07 2008-09-11 Optimal Licensing Corporating System and method for premises monitoring using weight detection
US20090030848A1 (en) * 2007-07-26 2009-01-29 Fididel, Inc. Systems and methods for online sales negotiations
US20090112747A1 (en) * 2007-10-30 2009-04-30 Visa U.S.A. Inc. System and Method For Processing Multiple Methods of Payment
US20090112766A1 (en) * 2007-10-25 2009-04-30 Ayman Hammad Device including multiple payment applications
US7584151B2 (en) * 2001-12-07 2009-09-01 American Express Travel Related Services Company, Inc. Electronic purchasing method and apparatus for performing the same
US20090228336A1 (en) * 1999-02-19 2009-09-10 Giordano Joseph A System and method for processing financial transactions
US7590557B2 (en) * 2003-11-19 2009-09-15 American Express Travel Related Services Company, Inc. Healthcare card incentive program for multiple users
US7661586B2 (en) * 2003-10-30 2010-02-16 Datapath, Inc. System and method for providing a credit card with back-end payment filtering
US7664690B2 (en) * 2005-07-29 2010-02-16 Accenture Global Services Gmbh Insurance claim management
US7668771B1 (en) * 2007-02-28 2010-02-23 Island Intellectual Property Llc System and method for allocation to obtain zero activity in a selected aggregated account
US7668772B1 (en) * 1998-10-21 2010-02-23 Island Intellectual Property Llc Systems and methods for money fund banking with flexible interest allocation
US7672886B2 (en) * 1998-10-21 2010-03-02 Island Intellectual Property Llc Systems and methods for managing client accounts
US7702553B1 (en) * 2003-11-06 2010-04-20 Jp Morgan Chase Bank, N.A. System and method for conversion of initial transaction to final transaction
US7702530B2 (en) * 2003-07-29 2010-04-20 Lifespring Health Network Llc Systems and methods for consumers to purchase health care and related products
US20100211499A1 (en) * 2009-02-13 2010-08-19 Bank Of America Corporation Systems, methods and computer program products for optimizing routing of financial payments
US7814015B2 (en) * 2002-05-21 2010-10-12 Tekelec Methods and systems for performing a sales transaction using a mobile communications device
US7831490B2 (en) * 2003-02-28 2010-11-09 Payment Pathways, Inc. Enhanced system for electronic funds transfer and elimination of the payee's need for encryption and privacy
US20110101092A1 (en) * 2009-10-29 2011-05-05 Jorge Fernandez Bin routing for payment processing
US20110167002A1 (en) * 2002-06-12 2011-07-07 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US8015084B1 (en) * 2000-09-06 2011-09-06 Jpmorgan Chase Bank, N.A. System and method for linked account having sweep feature
US20120072347A1 (en) * 2009-03-20 2012-03-22 Anthony Conway Policy-based payment transaction routing service for credit card payment processing

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5315509A (en) * 1989-10-23 1994-05-24 International Business Machines Corporation Artificial intelligence system for item analysis for rework shop orders
US5287267A (en) * 1991-05-10 1994-02-15 International Business Machines Corporation Methods for parts procurement quantity determination where demand is uncertain for the product in which the parts are used
US5381332A (en) * 1991-12-09 1995-01-10 Motorola, Inc. Project management system with automated schedule and cost integration
US5365425A (en) * 1993-04-22 1994-11-15 The United States Of America As Represented By The Secretary Of The Air Force Method and system for measuring management effectiveness
US5465206B1 (en) 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
US5450317A (en) * 1993-11-24 1995-09-12 U S West Advanced Technologies, Inc. Method and system for optimized logistics planning
US5745880A (en) * 1994-10-03 1998-04-28 The Sabre Group, Inc. System to predict optimum computer platform
US5737727A (en) * 1996-01-25 1998-04-07 Electronic Data Systems Corporation Process management system and method
US5793632A (en) * 1996-03-26 1998-08-11 Lockheed Martin Corporation Cost estimating system using parametric estimating and providing a split of labor and material costs
US7167924B1 (en) 1996-06-10 2007-01-23 Diebold, Incorporated Financial transaction processing system and method
US5848394A (en) * 1996-09-18 1998-12-08 Leonard & Caroline White Method and system for producing a work breakdown structure for a project
WO1999046711A1 (en) * 1998-03-13 1999-09-16 Aspen Technology, Inc. Computer method and apparatus for automatic execution of software applications
US6381610B1 (en) * 1999-01-22 2002-04-30 Unmesh B. Gundewar System and method for implementing project procedures
US7020621B1 (en) * 1999-10-06 2006-03-28 Accenture Llp Method for determining total cost of ownership
US20060178986A1 (en) * 2000-02-17 2006-08-10 Giordano Joseph A System and method for processing financial transactions using multi-payment preferences
US7146338B2 (en) * 2001-06-28 2006-12-05 Checkfree Services Corporation Inter-network financial service
US20020184147A1 (en) 2001-06-05 2002-12-05 Boulger Gordon D. System for paying invoices
US7693783B2 (en) * 2002-06-12 2010-04-06 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US6819381B2 (en) 2002-10-28 2004-11-16 Eastman Kodak Company Compensation films for liquid crystal displays
US7464859B1 (en) 2004-12-17 2008-12-16 Fred Hawkins Reimbursement process and processor for conducting a financial transaction
US8732044B2 (en) 2006-05-23 2014-05-20 Mastercard International Incorporated Electronic transaction apparatus and method
IL176262A0 (en) * 2006-06-12 2006-10-05 Cidway Technologies Ltd Secure and friendly payment system
US8078515B2 (en) 2007-05-04 2011-12-13 Michael Sasha John Systems and methods for facilitating electronic transactions and deterring fraud
US20080306838A1 (en) 2007-06-07 2008-12-11 Ustrive2, Inc. System and Method of Bridging a Product Catalog from a Central E-Commerce Website to Remote Access
US8560448B2 (en) * 2008-12-30 2013-10-15 Municipay, Llc System and method to initiate funding of multiple merchant accounts
US20110093324A1 (en) * 2009-10-19 2011-04-21 Visa U.S.A. Inc. Systems and Methods to Provide Intelligent Analytics to Cardholders and Merchants
US20130124263A1 (en) * 2011-11-14 2013-05-16 Visa International Service Association Systems and Methods to Summarize Transaction data

Patent Citations (110)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US78783A (en) * 1868-06-09 Improvement in portable fence
US5426281A (en) * 1991-08-22 1995-06-20 Abecassis; Max Transaction protection system
US5649118A (en) * 1993-08-27 1997-07-15 Lucent Technologies Inc. Smart card with multiple charge accounts and product item tables designating the account to debit
US5649117A (en) * 1994-06-03 1997-07-15 Midwest Payment Systems System and method for paying bills and other obligations including selective payor and payee controls
US5596642A (en) * 1994-09-30 1997-01-21 Electronic Payment Services, Inc. Network settlement performed on consolidated information
US5596643A (en) * 1994-09-30 1997-01-21 Electronic Payment Services, Inc. Network settlement performed on consolidated information
US5717989A (en) * 1994-10-13 1998-02-10 Full Service Trade System Ltd. Full service trade system
US6298335B1 (en) * 1995-01-06 2001-10-02 Robert Bernstein Method of controlling payment of debts
US5650604A (en) * 1995-02-22 1997-07-22 Electronic Data Systems Corporation System and method for electronic transfer of funds using an automated teller machine to dispense the transferred funds
US6070150A (en) * 1996-10-18 2000-05-30 Microsoft Corporation Electronic bill presentment and payment system
US6105009A (en) * 1997-06-16 2000-08-15 Cuervo; Vincent Automated teller machine dispenser of debit cards
US6292789B1 (en) * 1997-08-26 2001-09-18 Citibank, N.A. Method and system for bill presentment and payment
US20080046358A1 (en) * 1998-04-24 2008-02-21 First Data Corporation Methods For Processing A Group Of Accounts Corresponding To Different Products
US7672886B2 (en) * 1998-10-21 2010-03-02 Island Intellectual Property Llc Systems and methods for managing client accounts
US7668772B1 (en) * 1998-10-21 2010-02-23 Island Intellectual Property Llc Systems and methods for money fund banking with flexible interest allocation
US20010014878A1 (en) * 1998-11-09 2001-08-16 Nilotpal Mitra Transaction method and apparatus
US6473740B2 (en) * 1998-11-29 2002-10-29 Qpass, Inc. Electronic commerce using a transaction network
US20090228336A1 (en) * 1999-02-19 2009-09-10 Giordano Joseph A System and method for processing financial transactions
US20040030657A1 (en) * 1999-04-23 2004-02-12 First Data Resources, Inc. Financial transaction account usage parameter access and control method
US20030200179A1 (en) * 1999-08-11 2003-10-23 Khal Hee Kwan Method, apparatus and program to make payment in any currencies through a communication network system using pre-paid cards
US20020069244A1 (en) * 1999-11-24 2002-06-06 John Blair Message delivery system billing method and apparatus
US6701303B1 (en) * 1999-12-23 2004-03-02 International Business Machines, Corp. E-commerce system and method of operation enabling a user to conduct transactions with multiple retailers without certification and/or trusted electronic paths
US20010034771A1 (en) * 2000-01-14 2001-10-25 Sun Microsystems, Inc. Network portal system and methods
US6847953B2 (en) * 2000-02-04 2005-01-25 Kuo James Shaw-Han Process and method for secure online transactions with calculated risk and against fraud
US20080154773A1 (en) * 2000-02-10 2008-06-26 Jove Corporation System and method for secure data and funds transfer
US20060116957A1 (en) * 2000-03-17 2006-06-01 Jason May Method and apparatus for facilitating online payment transactions in a network-based transaction facility
US20020002495A1 (en) * 2000-05-19 2002-01-03 Npax, Inc. Integrated pharmaceutical accounts management system and method
US20040042470A1 (en) * 2000-06-16 2004-03-04 Geoffrey Cooper Method and apparatus for rate limiting
US20060173672A1 (en) * 2000-07-27 2006-08-03 Bergeron Heather E Processing health care transactions using a semantic network
US20050033605A1 (en) * 2000-07-27 2005-02-10 Bergeron Heather Ellen Configuring a semantic network to process health care transactions
US20050033583A1 (en) * 2000-07-27 2005-02-10 Bergeron Heather Ellen Processing transactions using a structured natural language
US20050010428A1 (en) * 2000-07-27 2005-01-13 Bergeron Heather Ellen Processing transactions using a semantic network
US20050010394A1 (en) * 2000-07-27 2005-01-13 Bergeron Heather Ellen Configuring a semantic network to process transactions
US8015084B1 (en) * 2000-09-06 2011-09-06 Jpmorgan Chase Bank, N.A. System and method for linked account having sweep feature
US7383223B1 (en) * 2000-09-20 2008-06-03 Cashedge, Inc. Method and apparatus for managing multiple accounts
US6529187B1 (en) * 2000-10-26 2003-03-04 Mark Dickelman Generalized system for internet and services navigation from keypad equipped internet devices, including browser equipped phones
US20080097783A1 (en) * 2000-11-17 2008-04-24 Iannacci Gregory F System and method for preference-based account enrollment
US20040236632A1 (en) * 2000-12-07 2004-11-25 Maritzen Michael L. System and method for conducing financial transactions using a personal transaction device with vehicle-accessed, payment-gateway terminals
US20020111886A1 (en) * 2001-02-12 2002-08-15 Chenevich William L. Payment management
US20020111916A1 (en) * 2001-02-12 2002-08-15 Coronna Mark S. Payment management
US20020111915A1 (en) * 2001-02-12 2002-08-15 Clemens Christopher Donald Payment management
US20030061216A1 (en) * 2001-03-27 2003-03-27 Fred Moses System and method for managing objects and resources with access rights embedded in nodes within a hierarchical tree structure
US20020145051A1 (en) * 2001-04-09 2002-10-10 Charrin Philippe A. Combined smartcard and magnetic-stripe card and reader and associated method
US20040167852A1 (en) * 2001-05-09 2004-08-26 Cutler Nicholas Leeds Payment system
US7174302B2 (en) * 2001-06-11 2007-02-06 Evolution Benefits, Inc. System and method for processing flexible spending account transactions
US7680679B1 (en) * 2001-06-11 2010-03-16 Evolution Benefits, Inc. Method and system for processing transactions involving accounts for reimbursing medical expenses or patient responsible balances with multiple transaction substantiation modes
US20030009382A1 (en) * 2001-06-12 2003-01-09 D'arbeloff Matthew A. Customer identification, loyalty and merchant payment gateway
US20030126094A1 (en) * 2001-07-11 2003-07-03 Fisher Douglas C. Persistent dynamic payment service
US7225156B2 (en) * 2001-07-11 2007-05-29 Fisher Douglas C Persistent dynamic payment service
US20030061157A1 (en) * 2001-07-24 2003-03-27 Hirka Jeffrey L. Multiple account advanced payment card and method of routing card transactions
US20030061229A1 (en) * 2001-09-08 2003-03-27 Lusen William D. System for processing objects for storage in a document or other storage system
US20040093302A1 (en) * 2001-09-27 2004-05-13 Baker Eric H. System and method for providing logistics for a sale or transfer of goods with proceeds provided to a third party
US20030105688A1 (en) * 2001-12-05 2003-06-05 Brown Owen H. Secure digital escrow account transactions system and method
US7584151B2 (en) * 2001-12-07 2009-09-01 American Express Travel Related Services Company, Inc. Electronic purchasing method and apparatus for performing the same
US20030212632A1 (en) * 2002-01-07 2003-11-13 S.W.I.F.T.S.C.; Electronic payment initiation and assurance system
US7092913B2 (en) * 2002-02-26 2006-08-15 Cannon Jr Thomas Calvin System for inexpensively executing online purchases
US20030225619A1 (en) * 2002-03-15 2003-12-04 Maynard Dokken System and method for dealing with loyalty program points
US7814015B2 (en) * 2002-05-21 2010-10-12 Tekelec Methods and systems for performing a sales transaction using a mobile communications device
US20110167002A1 (en) * 2002-06-12 2011-07-07 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US20040024703A1 (en) * 2002-07-30 2004-02-05 James Roskind Smart payment instrument selection
US7280981B2 (en) * 2002-08-27 2007-10-09 Visa U.S.A. Inc. Method and system for facilitating payment transactions using access devices
US20040044621A1 (en) * 2002-08-27 2004-03-04 Visa U.S.A., Inc. Method and system for facilitating payment transactions using access devices
US20080103985A1 (en) * 2002-08-27 2008-05-01 Jean Huang Method and system for facilitating payment transactions using access devices
US7711621B2 (en) * 2002-08-27 2010-05-04 Visa U.S.A. Inc. Method and system for facilitating payment transactions using access devices
US20040083092A1 (en) * 2002-09-12 2004-04-29 Valles Luis Calixto Apparatus and methods for developing conversational applications
US7831490B2 (en) * 2003-02-28 2010-11-09 Payment Pathways, Inc. Enhanced system for electronic funds transfer and elimination of the payee's need for encryption and privacy
US20070168910A1 (en) * 2003-04-10 2007-07-19 Charismatek Software Metrics Pty Ltd Automatic sizing of software functionality
US20070174160A1 (en) * 2003-04-29 2007-07-26 Solberg Eric L Hierarchical transaction filtering
US20070179873A1 (en) * 2003-04-29 2007-08-02 Solberg Eric L Transaction allocation
US7702530B2 (en) * 2003-07-29 2010-04-20 Lifespring Health Network Llc Systems and methods for consumers to purchase health care and related products
US20050060579A1 (en) * 2003-09-15 2005-03-17 Anexsys, L.L.C. Secure network system and associated method of use
US20050080691A1 (en) * 2003-09-26 2005-04-14 First Data Corporation Systems and methods for participant controlled communications regarding financial accounts
US20050077350A1 (en) * 2003-10-13 2005-04-14 Starbucks Corporation Dual card
US7661586B2 (en) * 2003-10-30 2010-02-16 Datapath, Inc. System and method for providing a credit card with back-end payment filtering
US7702577B1 (en) * 2003-11-06 2010-04-20 Jp Morgan Chase Bank, N.A. System and method for conversion of initial transaction to final transaction
US7702553B1 (en) * 2003-11-06 2010-04-20 Jp Morgan Chase Bank, N.A. System and method for conversion of initial transaction to final transaction
US7590557B2 (en) * 2003-11-19 2009-09-15 American Express Travel Related Services Company, Inc. Healthcare card incentive program for multiple users
US20070112671A1 (en) * 2003-12-17 2007-05-17 Guaranteed Markets Ltd Transaction management system and method
US20050198174A1 (en) * 2003-12-30 2005-09-08 Loder Theodore C. Economic solution to the spam problem
US20050222961A1 (en) * 2004-04-05 2005-10-06 Philippe Staib System and method of facilitating contactless payment transactions across different payment systems using a common mobile device acting as a stored value device
US20050274792A1 (en) * 2004-06-09 2005-12-15 Hahn-Carlson Dean W Transaction accounting processing system and approach
US7392934B2 (en) * 2004-06-09 2008-07-01 U.S. Bank National Association Transaction accounting processing system and approach
US20060036541A1 (en) * 2004-07-16 2006-02-16 Joerg Schleicher Method and system to process credit card payment transactions initiated by a merchant
US20060089906A1 (en) * 2004-10-21 2006-04-27 Michael Rowley Method for securing a payment transaction over a public network
US20070175985A1 (en) * 2004-11-19 2007-08-02 American Express Travel Related Services Company, Inc. Linking Transaction Cards With Spending Accounts
US7905399B2 (en) * 2004-11-19 2011-03-15 Barnes Brian T Linking transaction cards with spending accounts
US20060113376A1 (en) * 2004-12-01 2006-06-01 Humana Inc.; Metavante Corporation Account control method and system that allows only eligible and authorized items to be purchased using the account
US20070017976A1 (en) * 2005-07-19 2007-01-25 Plastyc Inc. System and method for child card payment
US7664690B2 (en) * 2005-07-29 2010-02-16 Accenture Global Services Gmbh Insurance claim management
US20070038577A1 (en) * 2005-08-15 2007-02-15 Werner Gerald C Method of purchasing digitally encoded music, audiobooks, and video by one party for subsequent delivery to a third party
US20070061255A1 (en) * 2005-09-12 2007-03-15 Epting Thomas W Point of Sale Credit System
US20070233597A1 (en) * 2006-03-06 2007-10-04 First Data Corporation Least cost network routing for electronic transactions
US20080025572A1 (en) * 2006-04-18 2008-01-31 Schneider John K Augmented Biometric Authorization System And Method
US20080046366A1 (en) * 2006-06-29 2008-02-21 Vincent Bemmel Method and system for providing biometric authentication at a point-of-sale via a mobile device
US20080015985A1 (en) * 2006-07-11 2008-01-17 Armand Abhari System and process for expedited payment through online banking/payment channel
US20080014908A1 (en) * 2006-07-17 2008-01-17 Abraham Vasant System and method for coordinating customized mobility services through a network
US20080021813A1 (en) * 2006-07-21 2008-01-24 Sheshunoff Management Services, Lp Method for scoring accounts for retention and marketing accounts based on retention and profitability
US20080103968A1 (en) * 2006-10-31 2008-05-01 Discover Financial Services Llc Redemption of Credit Card Rewards at a Point of Sale
US20080109320A1 (en) * 2006-11-06 2008-05-08 Jonathan Kleinhans Interactive RFID Transaction Automation
US20080162295A1 (en) * 2006-12-29 2008-07-03 Ebay Inc. Method and system for payment authentication
US20080201769A1 (en) * 2007-02-15 2008-08-21 Peter George Finn System and method for processing payment options
US7668771B1 (en) * 2007-02-28 2010-02-23 Island Intellectual Property Llc System and method for allocation to obtain zero activity in a selected aggregated account
US7672901B1 (en) * 2007-02-28 2010-03-02 Island Intellectual Property Llc System and method for holdback procedure for after-hours transactions
US20080218338A1 (en) * 2007-03-07 2008-09-11 Optimal Licensing Corporating System and method for premises monitoring using weight detection
US20090030848A1 (en) * 2007-07-26 2009-01-29 Fididel, Inc. Systems and methods for online sales negotiations
US20090112766A1 (en) * 2007-10-25 2009-04-30 Ayman Hammad Device including multiple payment applications
US20090112747A1 (en) * 2007-10-30 2009-04-30 Visa U.S.A. Inc. System and Method For Processing Multiple Methods of Payment
US20100211499A1 (en) * 2009-02-13 2010-08-19 Bank Of America Corporation Systems, methods and computer program products for optimizing routing of financial payments
US20120072347A1 (en) * 2009-03-20 2012-03-22 Anthony Conway Policy-based payment transaction routing service for credit card payment processing
US20110101092A1 (en) * 2009-10-29 2011-05-05 Jorge Fernandez Bin routing for payment processing

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090327148A1 (en) * 2008-06-27 2009-12-31 Microsoft Corporation Mechanisms and architecture for mobile opportunistic commerce
US20100093306A1 (en) * 2008-10-09 2010-04-15 West Corporation System and method for availing information relating to a circumstance
US20100145856A1 (en) * 2008-12-08 2010-06-10 Laima Kardokas Automated merchant performance rating for payments on account
US10438181B2 (en) * 2009-07-22 2019-10-08 Visa International Service Association Authorizing a payment transaction using seasoned data
US20110022517A1 (en) * 2009-07-22 2011-01-27 Ayman Hammad Apparatus including data bearing medium for authorizing a payment transaction using seasoned data
US11030593B2 (en) * 2009-07-22 2021-06-08 Visa International Service Association Processing authorization request using seasoned data
US10685338B2 (en) * 2009-07-22 2020-06-16 Visa International Service Association Authorizing a payment transaction using seasoned data
US20110119189A1 (en) * 2009-11-18 2011-05-19 American Express Travel Related Services Company, Inc. Data processing framework
US20110119274A1 (en) * 2009-11-18 2011-05-19 American Express Travel Related Services Company, Inc. File listener system and method
US20110119178A1 (en) * 2009-11-18 2011-05-19 American Express Travel Related Services Company, Inc. Metadata driven processing
US20110119188A1 (en) * 2009-11-18 2011-05-19 American Express Travel Related Services Company, Inc. Business to business trading network system and method
US8332378B2 (en) 2009-11-18 2012-12-11 American Express Travel Related Services Company, Inc. File listener system and method
US20120089521A1 (en) * 2010-01-11 2012-04-12 Abrevaya Adam Method and apparatus for billing purchases from a mobile phone application
US8805725B2 (en) * 2012-06-18 2014-08-12 Bank Of America Corporation Payment vehicle recommendations based on payment rules
US8738049B1 (en) * 2012-11-05 2014-05-27 International Business Machines Corporation Converged dialog in hybrid mobile applications
US8761818B2 (en) * 2012-11-05 2014-06-24 International Business Machines Corporation Converged dialog in hybrid mobile applications
US9842361B2 (en) * 2013-03-14 2017-12-12 Google Llc Method, medium, and system for secure direct purchase option
US8639587B1 (en) * 2013-03-14 2014-01-28 Google Inc. Method, medium, and system for secure direct purchase
US10325307B2 (en) * 2013-03-14 2019-06-18 Google Llc Method, medium, and system for a secure direct purchase option
US20160140645A1 (en) * 2013-03-14 2016-05-19 Google Inc. Secure direct purchase option
US20140337234A1 (en) * 2013-05-09 2014-11-13 Dresser, Inc. Systems and methods for secure communication
US11127001B2 (en) * 2013-05-09 2021-09-21 Wayne Fueling Systems Llc Systems and methods for secure communication
CN105556892A (en) * 2013-05-09 2016-05-04 韦恩加油系统有限公司 Systems and methods for secure communication
US9430796B1 (en) 2013-10-16 2016-08-30 Google Inc. Direct purchase from user-received advertisement
US20190205858A1 (en) * 2013-11-19 2019-07-04 Wayne Fueling Systems Llc Systems and Methods for Convenient and Secure Mobile Transactions
US11276051B2 (en) * 2013-11-19 2022-03-15 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions
US20150278810A1 (en) * 2014-03-28 2015-10-01 Confia Systems, Inc. Device commerce using trusted computing system
US9603019B1 (en) 2014-03-28 2017-03-21 Confia Systems, Inc. Secure and anonymized authentication
US10484359B2 (en) 2015-07-25 2019-11-19 Confia Systems, Inc. Device-level authentication with unique device identifiers
US9602292B2 (en) 2015-07-25 2017-03-21 Confia Systems, Inc. Device-level authentication with unique device identifiers
US20210201316A1 (en) * 2019-12-27 2021-07-01 Lendingclub Corporation Multi-layered credit card with transaction-dependent source selection
US11580554B2 (en) * 2019-12-27 2023-02-14 LendingClub Bank, National Association Multi-layered credit card with transaction-dependent source selection

Also Published As

Publication number Publication date
US20090144166A1 (en) 2009-06-04
US9147184B2 (en) 2015-09-29
US9881131B1 (en) 2018-01-30

Similar Documents

Publication Publication Date Title
US9881131B1 (en) Computer automated systems, devices and methods for data processing of accounting records
US9141948B2 (en) Control system arrangements and methods for disparate network systems
US7580857B2 (en) Methods and systems for online transaction processing
US8275705B2 (en) System and method for providing dispute resolution for electronic payment transactions
US7849010B2 (en) System and method for real time account and account number generation using origination APIS
US20030130919A1 (en) Systems and methods for selectively accessing financial account information
US10679194B1 (en) Profile based arrangements and methods for disparate network systems
US11748726B1 (en) Disparate network systems and methods
US20110087592A1 (en) Systems and methods for facilitating transactions
US7873566B1 (en) Systems and methods for selectively accessing or using financial account data for subsequent risk determination
US20050015280A1 (en) Health care eligibility verification and settlement systems and methods
US9251510B2 (en) Buyer routing arrangements and methods for disparate network systems
US20050192897A1 (en) Methods and systems for payment-network enrollment
US20110077951A1 (en) Mobile Device Including Mobile Application
US11030589B2 (en) Hosted disbursement system
US20120143749A1 (en) Methods and systems for assigning interchange rates to financial transactions using an interchange network
US20120296814A1 (en) System and method for facilitating large scale payment transactions
US20120330825A1 (en) Processing a purchase transaction based on different payment methods
AU2002247375A1 (en) Method and system for making small payments using a payment card
US10210566B1 (en) Online exchange for payment transaction auctions
US20120197786A1 (en) Phone number payments for bill payments users
US20240037513A1 (en) Payment processing method and apparatus using an intermediary platform
WO2019071263A2 (en) Method and system for payment processing & syndicated consumer credit
US20150235208A1 (en) Proof-of-verification network
US20150235221A1 (en) Proof-of-verification network for third party issuers

Legal Events

Date Code Title Description
AS Assignment

Owner name: U.S. BANK NATIONAL ASSOCIATION, OHIO

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DICKELMAN, MARK;REEL/FRAME:021280/0753

Effective date: 20080715

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION