Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberWO2009046157 A1
Publication typeApplication
Application numberPCT/US2008/078525
Publication date9 Apr 2009
Filing date2 Oct 2008
Priority date2 Oct 2007
Publication numberPCT/2008/78525, PCT/US/2008/078525, PCT/US/2008/78525, PCT/US/8/078525, PCT/US/8/78525, PCT/US2008/078525, PCT/US2008/78525, PCT/US2008078525, PCT/US200878525, PCT/US8/078525, PCT/US8/78525, PCT/US8078525, PCT/US878525, WO 2009/046157 A1, WO 2009046157 A1, WO 2009046157A1, WO-A1-2009046157, WO2009/046157A1, WO2009046157 A1, WO2009046157A1
InventorsGregory R. Morris, Eugene J. Walters, Bruce Mcanally
ApplicantTrihealix, Inc.
Export CitationBiBTeX, EndNote, RefMan
External Links: Patentscope, Espacenet
Multi-authorization processing
WO 2009046157 A1
Abstract
A multi-authorization processing system systematically processes type-specific authorization requests against a purchaser's funding sources to optimize funding authorizations and consolidate those authorizations into a single authorization response while minimizing the purchaser's remaining liability. An authorization request for an expense claim is received and routed to a multi-authorization processor. Authorization processors that may authorize at least a portion of the expense claim based on a type of the authorization request are identified and ordered. An appropriately formatted authorization request is routed by the multi-authorization processor to a first authorization processor in response to the ordering. The request and responses transactions are processed with one or more next authorization processors in sequence until all next authorization processors have responded or remaining liability is zero.
Claims  (OCR text may contain errors)
What is claimed is:
1 , A method of processing an expense claim, comprising:
receiving an authorization request for an expense claim;
routing the authorization request to a multi-authorization processor;
identifying authorization processors that may authorize at least a portion of the expense claim based on a type of the authorization request
ordering the authorization processors for multi-authorization processing; and
routing by the multi-authorization processor an appropriately formatted authorization request to a first authorization processor in response to said ordering.
2. The method of claim 1 further comprising:
validating the authorization request against a purchaser's available sources of funds.
3. The method of claim 1 further comprising:
formatting at least a portion of the authorization request by the multi- authorization processor in accordance with formats used by the respective processors.
4. The method of claim 1 , further comprising:
receiving an authorization response to said request from the first authorization processor by the multi-authorization processor;
determining by the multi -authorization processor based on the response received from the first authorization processor, whether a remaining expense claim liability exists; determining a next authorization processor that may authorize against the remaining expense claim liability, and
generating a revised authorization request to be sent to a next authorization processor in response to determining that additional authorization processor(s) may authorize at least a portion of the remaining expense claim liability.
5. The method of claim 4 wherein the revised authorization request is formatted according to a format of said next authorization processor.
6. The method of claim 1 , comprising:
processing said request and responses transactions with one or more next authorization processors in sequence until all next authorization processors have responded or remaining liability is zero.
7. The method of claim 6, comprising:
routing an appropriately formatted authorization request to a next authorization processor by the multi-authorization processor.
8. The method of claim 7, comprising:
receiving an authorization response from a next level authorization processor by the multi-authorization processor;
determining by the multi-authorization processor in response to receiving an authorization response whether a remaining expense claim liability exists;
determining a next source of funds and a next authorization processor that may authorize against the remaining expense claim liability; and
generating each subsequent authorization request being formatted appropriately for processing by subsequent next authorization processor.
9. The method of claim 8 further comprising:
determining by the multi-authorization processor, a consolidation of the authorized amounts by the authorization processors into a total authorized amount and remaining liability based on the results of each processor's authorization response;
formatting of a consolidated response message for delivery to the originating authorization request submitter; and
routing the consolidated response message by the multi-authorization processor to a submitting entity.
10. The method of claim 9, wherein the consolidated response provides a total authorized amount and remaining liability based on the responses of the authorization processor(s).
1 1. The method of claim 6 further comprising:
storing a record of transactions considered by the multi-authorization processor in the disposition of an original submitted authorization request.
12. The method of claim 1 1 wherein the record includes an originally submitted authorization request, a consolidated response to the originally submitted authorization request and all requests and responses exchanged between the multi- authorization processor and authorization processors in response to the originally submitted authorization request.
13. The method of claim of claim 6 further comprising: adjusting processing of multi-authorization processing transactions as necessary based on instructions for such adjustment processing by a submitting entity.
14. A system for processing an expense claim, comprising: means for receiving an authorization request for an expense claim;
means for routing the authorization request to a multi-authorization processor;
means for identifying authorization processors that may authorize at least a portion of the expense claim based on a type of the authorization request
means for ordering the authorization processors for multi-authorization processing; and
means for routing by the multi-authorization processor an appropriately formatted authorization request to a first authorization processor in response to said ordering.
15. A system for processing an expense claim comprising: a multi-authorization request processor in communication with one or more authorization request processors, the multi-authorization request processor being adapted to
identify authorization processors that may authorize at least a portion of the expense claim based on a type of the authorization request;
order the authorization processors for multi-authorization processing; and
route an appropriately formatted authorization request to a first authorization processor in response to said ordering.
16. The system of claim 15 wherein the multi-authorization request processor is adapted to: validate the authorization request against a purchaser's available sources of funds.
17. The system of claim 15 wherein the multi-authoriztion request processor is adapted to: format at least a portion of the authorization request in accordance with formats used by the respective processors.
18. The system of claim 15 wherein the multi-authorization request processor is adapted to:
receive an authorization response to said request from the first authorization processor;
determine based on the response received from the first authorization processor, whether a remaining expense claim liability exists;
determine a next authorization processor that may authorize against the remaining purchaser, and
generate a revised authorization request to be sent to a next authorization processor in response to determining that additional authorization processor(s) may authorize at least a portion of the remaining expense claim liability.
19. A computer readable medium including software executable on a computer for performing the steps of: receiving an authorization request for an expense claim;
routing the authorization request to a multi -authorization processor;
identifying authorization processors that may authorize at least a portion of the expense claim based on a type of the authorization request
ordering the authorization processors for multi-authorization processing; and
routing by the multi-authorization processor an appropriately formatted authorization request to a first authorization processor in response to said ordering.
20. The computer readable medium of claim 19 wherein the software is executable to perform the steps of: receiving an authorization response to said request from the first authorization processor by the multi-authorization processor;
determining by the multi -authorization processor based on the response received from the first authorization processor, whether a remaining expense claim liability exists;
determining a next authorization processor that may authorize against the remaining purchaser, and
generating a revised authorization request to be sent to a next authorization processor in response to determining that additional authorization processor(s) may authorize at least a portion of the remaining expense claim liability.
Description  (OCR text may contain errors)

MULTI-AUTHORIZATION PROCESSING

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims priority to U.S. Provisional Application No.

60/976,838, filed on October 2, 2007, which is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates generally to payment authorization for goods and services on behalf of a purchaser, and more specifically to payment authorization on behalf of a purchaser utilizing one or more funding sources to satisfy all or part of the purchaser's liability.

BACKGROUND OF THE INVENTION Purchasers of goods and services often pay for such goods and services by using a variety of funding sources and/or payment arrangements. For example, a purchaser may split payment across two separate credit cards, which may be facilitated by two separate authorization transactions covering the total amount due for the goods and services. Payment arrangements may also be more complex. For example, a purchaser of goods and services may be an eligible beneficiary, a member of a discount or incentive plan, or part of an insured or prearranged benefit plan that reduces the purchaser's payment liability outright or transfers payment liability (in whole or in part) to a third party on behalf of the purchaser.

In the case of discounts, incentives, and insurance benefits, a third party may have pre-arranged terms with a merchant/seller of goods and services that modifies the invoice or expense claim amount, thereby altering the amount due from the purchaser. Such payment arrangements often involve the merchant/seller submitting the invoice or expense claim to a third party who re-prices the goods and service, applies benefits, and determines the remaining amount due to the merchant/seller from the purchaser. Additionally, the third party may also play a role in authorizing and/or settling a benefit claim. Further adding to this complexity, the purchaser may have additional, stacked funding sources that further reduce the remaining expense claim liability. Once all of these funding sources have been processed for authorization and reduction of the purchaser's liability, the purchaser may then be presented with a "net invoice" and choose to fund the remaining amount from one or more additional funding sources (e.g. cash, one or more debit cards, and/or one or more credit cards, etc.).

Expense claim processing is not standardized to a single authorization format or process. Depending on the type of expense claim, the industry, and other factors, there are a number of different electronic message formats, protocols, standards, and process flows (e.g. international organization of standards (ISO), Credit Card Association, automated clearing house (ACH), national council for prescription drug programs (NCPDP), electronic data interchange (EDI), health insurance portability and accountability act (HIPAA), and others) that require the merchant/seller to execute individual sequential transactions that are unrelated. These transactions would then be re-constructed against the expense claim to account for payment authorizations and to determine the remaining amount owed by the purchaser. Alternatively, a merchant/seller may opt out of this complexity by demanding out of pocket payment, thereby transferring the responsibility for managing the reimbursement from the funding sources to the purchaser.

An example of current art processing technology in the healthcare industry may be viewed in terms of a prescription drug purchase by a customer. In such an example, the pharmacist would typically send a NCPDP prescription billing transaction to the purchaser's primary prescription drug plan (PDP) authorization processor for adjudication/authorization, and would receive a response indicating any prearranged discounted price for the prescription drug, a commitment of the amount payable by the PDP, and any remaining amount payable by the consumer. The pharmacist would then execute a second billing transaction to the purchaser's secondary insurance plan, indicating the amount paid by the PDP and the remaining amount due, to request additional funding authorization against the remaining amount owed by the consumer. The secondary plan would send an additional response indicating any amount to be paid by the secondary plan, and the remaining amount still owed by the purchaser. The pharmacist would then request the form of payment (e.g. cash, debit, or credit) from the purchaser for the remaining amount and would process the relevant transaction for the remaining amount due. The pharmacy would receive three separate payments, and presumably apply them individually against the prescription sale.

A disadvantage of current processing technology is that a single invoice or expense claim for goods and services may require that multiple, independent, and unrelated transactions of potentially different transaction types be processed and authorized in order for payment in full to be authorized and settled.

A further disadvantage of this multi-step process is that it increases a variety of costs for the merchant/seller including, but not limited to, administrative resource costs and fees required to process and track invoices and payments, transaction resource costs and fees to gain relevant authorizations, cash flow costs related to multiple, sequential authorizations, and other costs and inefficiencies associated with the increased time required to deal with such a multi-step process.

A disadvantage for the purchaser is that these complexities often result in paperwork and other investments in time associated with managing and understanding payments from available funding sources.

SUMMARY OF THE INVENTION

The present invention provides a method for addressing the problems that are presented to a merchant/seller and to a purchaser/consumer of goods and services when more than one funding source and/or more than one transaction type is to be used to gain payment authorization against an invoice or claim. A multi-authorization processing system and method works with a myriad transaction modes (standard and proprietary) to gain individual authorizations against an invoice or claim, by recognizing an initial authorization request transaction and processing it within the rules and standards for its transaction type. For example, such claims may include, but are not limited to, healthcare claims (HIPAA), prescription claims(NCPDP), automated clearinghouse claims (NACHA), and/or credit/debit card claims (e.g. MasterCard, Visa, Discover, etc.). Transactions are processed based on knowledge of the purchaser's funding sources and proprietary rules management. The multi-authorization processing system systematically processes type-specific authorization requests against the purchaser's funding sources to optimize funding authorizations and consolidate those authorizations into a single authorization response while minimizing the purchaser's remaining liability.

An illustrative embodiment of the invention provides a method of processing an expense claim. The method includes the steps of receiving an authorization request for an expense claim, routing the authorization request to a multi-authorization processor, identifying authorization processors that may authorize at least a portion of the expense claim based on a type of the authorization request, ordering the authorization processors for multi-authorization processing; and routing by the multi-authorization processor an appropriately formatted authorization request to a first authorization processor in response to the ordering. The illustrative method also includes processing the request and responses transactions with one or more next authorization processors in sequence until all next authorization processors have responded or remaining liability is zero.

Another illustrative embodiment of the invention provides a system for processing an expense claim including a multi-authorization request processor in communication with one or more authorization request processors. The multi-authorization request processor is adapted to identify authorization processors that may authorize at least a portion of the expense claim based on a type of the authorization request, order the authorization processors for multi-authorization processing and route an appropriately formatted authorization request to a first authorization processor in response to the ordering. The multi-request processor may be further adapted to validate the authorization request against a purchaser's available sources of funds. In an illustrative embodiment, the multi-authorization processor is also adapted to format at least a portion of the authorization request in accordance with formats used by the respective processors. The multi-authorization processor may receive an authorization response to the request from the first authorization processor, determine based on the response received from the first authorization processor, whether a remaining expense claim liability exists, determine a next authorization processor that may authorize against the remaining purchaser, and generate a revised authorization request to be sent to a next authorization processor in response to determining that additional authorization processor(s) may authorize at least a portion of the remaining expense claim liability. Another illustrative embodiment of the invention provides a computer readable medium including software executable on a computer for performing the steps of receiving an authorization request for an expense claim, routing the authorization request to a multi -authorization processor, identifying authorization processors that may authorize at least a portion of the expense claim based on a type of the authorization request, ordering the authorization processors for multi-authorization processing; and routing by the multi -authorization processor an appropriately formatted authorization request to a first authorization processor in response to the ordering. The software may also be executable to perform the steps of receiving an authorization response to said request from the first authorization processor by the multi-authorization processor, determining by the multi -authorization processor based on the response received from the first authorization processor, whether a remaining expense claim liability exists, determining a next authorization processor that may authorize against the remaining purchaser, and generating a revised authorization request to be sent to a next authorization processor in response to determining that additional authorization processor(s) may authorize at least a portion of the remaining expense claim liability. BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other features and advantages of the present invention will be more fully understood from the following detailed description of illustrative embodiments, taken in conjunction with the accompanying drawings in which:

FIG. 1 is a block diagram depicting an expense claim involving one or more authorization processors and a single authorization request according to an illustrative embodiment of the invention; FIG. 2 is a block diagram depicting prescription drug claim billing in a multi-source funding model according to an illustrative embodiment of the invention; and FIG. 3 is a flow diagram of a multi-authorization processor method according to an illustrative embodiment of the invention. DETAILED DESCRIPTION

A general embodiment of the invention provides a multi-authorization processing method to payment authorizations in which one or more funding sources may be used to fund the payment of a financial liability of a consumer, business, or other entity. Such an embodiment is depicted in FIG. 1, which provides a block diagram depicting a general multi-authorization process 104. A single authorization request 100 can be satisfied from one or more funding sources that may be administered by "N" levels of authorization processors 108, 1 10, and 1 12. The funding sources may include, but are not limited to, cash, debit/credit cards, checking/savings accounts, retirement accounts, and/or lines of credit.

According to a general embodiment, a single authorization request 100 may be sent to the multi-authorization processor 120 in a standard format 1 14.

The authorization request 101 may be sent directly to the multi -authorization processor 120, or routed to the multi-authorization processor 120 via a request transaction router 102.

The multi-authorization processor 120 receives the authorization request 100, and validates the purchaser on the request against the source of funds manager 118, which stores information about the purchaser's preferred funding sources and the preferred order for accessing these sources. It is contemplated that the source of funds manager 1 18 may store similar information for a variety of other purchaser claim types.

The source of funds manager 1 18 determines the available sources of funds, and their respective processing orders if there are more than one. The multi-authorization processor 120 then sends a primary billing request 124 to the first authorization processor 108 identified in the primary billing request 124. This request may be sent directly, or it may be routed to the first authorization processor 108 via a billing transaction router 106. A primary billing request 124 may be sent to the first authorization processor 108 in a variety of standard formats.

The first authorization processor 108 processes the primary billing request 124 and returns a primary billing response 126 in a standard format to the multi-authorization processor 120. Upon receipt of the primary billing response 126, if there is remaining expense claim liability, the multi-authorization processor 120 identifies the secondary authorization processor 110 designated as the next available source of funds by the source of funds manager 1 18.

The multi-authorization processor 120 then sends a secondary billing request 128 to the second authorization processor 1 10, either directly or indirectly via a billing transaction router 106, which indicates the remaining expense claim liability. The second authorization processor 1 10 processes the secondary billing request 128 and returns a secondary billing response 130 in a standard format to the multi-authorization processor 120. Based on the response from the second authorization processor 110, if there is remaining expense claim liability, the multi-authorization processor 120 identifies the next preferred funding source from the source of funds manager 1 18 and sends a level N billing request 132 to the level N authorization processor 112, which then processes the request in a manner analogous to that described above for the first and second authorization processors 108, 1 10. The level N authorization processor 1 12 then returns a level N billing response 134 in standard format to the multi-authorization processor 120.

Upon receiving the level N billing response 134, the multi-authorization processor 120 confirms that no additional funding sources are available (or applicable) to satisfy any remaining expense claim liability. The multi-authorization processor 120 consolidates all of the authorized amounts and creates a consolidated billing response 1 16 that indicates the total amount payable (sum of the N number of authorization processor cycles and their respective authorized amounts), as well as the net/final remaining liability. The consolidated billing response 1 16 is then returned to the initial entity that submitted the single authorization request 100. The multi -authorization process 104 stores and relates all of the authorization request/response transactions performed while completing the single authorization request 100 and manages that information through the Multi -Authorization Transaction Manager 122.

FIG. 2 depicts an illustrative embodiment of the invention as used in the healthcare industry for a prescription drug purchase at a pharmacy. A purchaser of prescription medication may have a primary and a secondary prescription drug plan (PDP) that entitles the purchaser (in this case an individual covered under a health care plan) to a discounted purchase price and/or insured benefits. The purchaser may also have a preferred credit card account that he or she wishes to use to pay any remaining purchase liability after the primary and secondary insurance plans have been applied. In this embodiment, a multi-authorization processing system 204 consolidates and keeps track of the purchaser's preferred funding sources via a source of funds manager 218, which allows the purchaser to identify and maintain any and/or all sources of funds that may be used to fulfill the purchase liability associated with various types of expense claims. When the purchaser goes to a pharmacy and purchases a prescription drug, the pharmacy initiates a prescription billing request 200 that may be sent to a multi- authorization processor 220 via a standard format 201 that may include, but is not limited to, a variety of healthcare claim types. For example, such purchaser claim types may include, but are not limited to, vision claims, general medical claims, and any other expense claims that might involve authorizations against multiple funding sources. The prescription billing request 200 may be sent directly to the multi-authorization processor 220, or routed to the multi-authorization processor 220 via a pharmacy request transaction router 214.

The multi-authorization processor 220 processes the prescription billing request 200 against the purchaser's sources of funds that are applicable for prescription billing, as documented in the source of funds manager 218. The source of funds manager 218 may contain the purchaser's primary and secondary PDP information, which may include, but is not limited to, cardholder identification #, cardholder plan type, transaction routing information, co-payment amount, etc. Additionally, the source of funds manager 218 may contain information about the purchaser's preferred funding sources, which may include, but are not limited to, cash, debit/credit cards, checking/savings accounts, retirement accounts, and/or lines of credit. Advantageously, in addition to storing information about the purchaser's preferred funding sources, the source of funds manager 218 may order this information, effectively creating a funding source sequence for the processing of each prescription billing request related to that purchaser. A further advantage is that similar information may be stored and managed within the source of funds manager 218 for various other expense claim types (for example vision claims, general medical claims, and any other expense claims that might involve authorizations against multiple funding sources).

Once the multi-authorization processor 220 receives the pharmacy billing request 200, it compares the purchaser on the billing request 200 with the source of funds manager 218 and determines the purchaser's available sources of funds and the respective processing order of each source. The multi -authorization processor 220 then transfers a primary prescription billing request 224 to the PDP Authorization Processor 208 identified by the source of funds manager 1 18. This transfer may occur either directly, or via the pharmacy billing transaction router 206. The PDP authorization processor 208 processes the request and returns a primary prescription billing response 226 in the NCPDP Rx Billing Response standard format to the multi-authorization processor 220. Upon receipt of the primary prescription billing response 226, if there is remaining expense claim liability, the multi-authorization processor 220 identifies the secondary PDP from the source of funds manager 218 that represents the next available source of funds, and forms a secondary prescription billing request 228 indicating the remaining purchase liability and the result of the primary PDP's authorization (as indicated in the NCPDP Rx Billing Request transaction standard) to be sent to the secondary PDP authorization processor 210 for processing, either directly or via the pharmacy billing transaction router 206. Based on the secondary prescription billing response 230 received from the secondary PDP authorization processor 210, if there is remaining expense claim liability, then multi-authorization processor 220 identifies the preferred credit card from the source of funds manager 218 as the next source of funds. The multi-authorization processor 220 forms a credit card authorization request 232 in the credit card association standard indicating the remaining expense claim liability amount as the authorization request amount to be sent to the credit card issuer processor 212 for processing, either directly or via a credit card association network (not shown). Upon receiving the credit card billing response 234 from the credit card issuer processor 212, the multi-authorization process 220 confirms no additional funding accounts are available (or applicable) to satisfy any remaining amount. The multi-authorization processor 220 consolidates all of the authorized amounts and creates a consolidated prescription billing response 202, indicating the total amount payable (sum of the N number of authorization processor cycles and their respective authorized amounts), as well as the net/final remaining liability. The multi-authorization processor 220 then transmits the consolidated prescription billing response 202 in the NCPDP Rx Billing Response standard format. Multi-authorization processing 204 stores and relates all of the authorization request/response transactions performed while completing the pharmacy prescription billing request 200 and manages that information through the multi-authorization transaction manager 222.

FIG. 3 is a process flow diagram describing a multi-authorization processing method according to an illustrative embodiment of the invention. The system receives an authorization request from a submitter 300 and determines from the source of funds manager (SOFM) whether or not there there is a level 1 authorization processor record 302 If there is not a level 1 record, the system triggers an error 304 and informs the submitter of the response failure. If there is a level 1 record, the system routes the authorization response to the identified level 1 authorization processor 306 and waits for a response.

When the system receives the level 1 authorization processor response 308, it queries whether or not the response was approved 310. If the response was not approved, the system queries whether or not there was a critical error 312. If there was a critical error, the authorization response is returned to the submitter 314.

If there was not a critical error, the system queries whether or not there was an unmet responsibility 316. If there was no unmet responsibility, the authorization response is returned to the submitter 314. If there was an unmet responsibility, the system then queries whether or not there is a level 2 authorization processor record 318. If there is not, then the authorization response is returned to the submitter 314.

If there is a level 2 record, then the system builds a level 2 authorization request 320 and routes the authorization response to the identified level 2 authorization processor 322 and waits for a response.

When the system receives the level 2 authorization response 324, it recalculates the authorization totals and unmet responsibility 326. The system then queries whether or not there is any remaining unmet responsibility 328. If there is no remaining unmet responsibility, the system builds an authorization response for return to the submitter 352, and returns the response to the submitter 354. If there is remaining unmet responsibility, the system queries whether or not there is a level 3 authorization processor record. If there is not, the system builds an authorization response for return to the submitter 352, and returns the response to the submitter 354.

If there is, the system builds a level 3 authorization request 332 and sends it to the identified level 3 authorization processor 334 and waits for a response. When the system receives the level 3 authorization response 336, it recalculates the authorization totals and unmet responsibility 338. The system then queries whether or not there is any remaining unmet responsibility 340. If there is no remaining unmet responsibility, the system builds an authorization response for return to the submitter 352, and returns the response to the submitter 354. If there is remaining unmet responsibility, the system queries whether or not there is a level 4 authorization processor record. If it is not, the system builds an authorization response for return to the submitter 352, and returns the response to the submitter 354.

If there is, the system builds a level 4 authorization request 344 and sends it to the identified level 4 authorization processor 346 and waits for a response. When the system receives the level 4 authorization response 348, it recalculates the authorization totals and unmet responsibility 350. The system then builds an authorization response for return to the submitter 352, and returns the response to the submitter 354.

For illustrative purposes, the flow diagram depicted in FIG. 3 depicts Levels 1 - 4, although fewer or additional levels may be associated with a purchaser via a source of funds manager. For example, level 1 may be a Medicare Part D plan administrator/processor, level 2 may be a supplemental pharmacy assistance plan administrator/processor, level 3 may be a flexible spending account administrator/processor, and level 4 may be a credit card administrator/processor. One skilled in the art will appreciate that multi-authorization processing, as described in the pharmacy billing example above, automates, consolidates, relates, and simultaneously processes all of the authorizations within the transaction by process standards recognized by pharmacies, PDPs, purchasers and other constituents in the pharmacy billing environment, while streamlining and reducing the resource investment required to complete those activities.

In one embodiment, a consumer/purchaser may be a person or entity that agrees to pay for goods and/or services received from a merchant/seller. In another embodiment, a merchant/seller may be a person or entity that provides goods or services to a consumer/purchaser in exchange for an agreement to pay for those goods and services.

In yet another embodiment, an authorization submitter may be the source of an authorization request. This may be, but is not limited to, the merchant/seller or a representative.

In another embodiment, the transaction router may be an entity or network that moves transactions between submitter, multi-authorization processor, and authorization processor. A transaction router may include, but is not limited to, clearinghouses, switches, card associations, trading partners, and/or intermediaries. In another embodiment, an authorization request may include a request transaction from a merchant/seller claiming purchaser liability for goods and/or service seeking processing by at least one authorization processor for an amount due. For example, an authorization request may include, but is not limited to, a major medical or preventive care insurance claim submission (e.g. HIPAA ANSI X12 837), a pharmacy prescription claim (e.g. NCPDP v5.1 Bl), retail debit /credit card authorization request (e.g. ISO 8583), and/or an automated clearing house (ACH) request (NACHA format)

In an embodiment, a source of funds may include any financial account or benefit account/set associated with a consumer/purchaser, directly or indirectly, that may be utilized to fulfill all or part of an authorization request. In another embodiment, a level "N' authorization processor may be any entity that processes an authorization request against consumer's/purchaser's source(s) of funds to meet all or part of the consumer's/purchaser's responsibility based on the terms of the source of funds as established by the source of fund's issuer/sponsor and as managed by that processor. Examples of might include (without limitation): a medical insurance plan sponsor or its third party administrator, health plan, pharmacy benefit manager, credit or debit card issuer or processor, a bank or any other entity that authorizes requests against a consumer's/purchaser's "source(s) of funds."

While the invention has been described with reference to illustrative embodiments, it will be understood by those skilled in the art that various other changes, omissions, and/or additions may be made and substantial equivalents may be substituted for elements thereof without departing from the spirit and scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teaching of the invention without departing from the scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed for carrying out this invention, but that the invention will include all embodiments, falling within the scope of the appended claims. Moreover, unless specifically stated any use of the terms first, second, etc., do not denote any order of importance, but rather the terms first, second, etc. are used to distinguish one element from another.

Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5500890 *19 Aug 199319 Mar 1996Exxon Research And Engineering CompanyPoint-of-sale system using multi-threaded transactions and interleaved file transfer
US20030212904 *11 Jun 200313 Nov 2003Randle William M.Standardized transmission and exchange of data with security and non-repudiation functions
US20040210531 *23 Oct 200221 Oct 2004Total System Services, Inc.System and method for single event authorization control of transactions
Classifications
International ClassificationH04M11/00
Cooperative ClassificationG06Q30/06
European ClassificationG06Q30/06
Legal Events
DateCodeEventDescription
10 Jun 2009121Ep: the epo has been informed by wipo that ep was designated in this application
Ref document number: 08836322
Country of ref document: EP
Kind code of ref document: A1
7 Apr 2010NENPNon-entry into the national phase in:
Ref country code: DE
27 Oct 2010122Ep: pct app. not ent. europ. phase
Ref document number: 08836322
Country of ref document: EP
Kind code of ref document: A1