Patent Description:
Various activities undertaken by members of organizations (e.g. employees of a corporate entity) may require the members to incur expenses. Examples of such activities include travel, obtaining supplies, and the like. Reimbursement of such expenses typically occurs after the expenses have been not only incurred, but also paid for by the members. In other words, reimbursement is typically a retrospective process that may be poorly suited to applying expense policies, detecting potential fraud, and the like. Further, reimbursement processes are typically conducted manually, and may therefore be time-consuming and error-prone. <CIT> describes an electronic bill presentment and payment system enabling determining payers for billable events based among other on the participants involved.

An aspect of the specification provides a method of intermediating transactions, comprising, at an intermediation server: receiving invoice data defining a price payable to a vendor for supplying a product to a customer; extracting, from the invoice data, a vendor identifier corresponding to the vendor; determining, in association with the invoice data, a customer identifier corresponding to the customer; retrieving a payer identifier corresponding to a payer associated with the customer; retrieving, based on at least the payer identifier, a transaction policy; according to the retrieved transaction policy, allocating an eligible portion of the price to the payer identifier, and allocating a remaining portion of the price to the customer identifier; and generating and transmitting payment data for initiating a payment of the eligible portion from the payer to the vendor.

In an embodiment, receiving the invoice data comprises receiving the invoice data from a vendor computing device corresponding to the vendor identifier. In another embodiment, determining the customer identifier comprises extracting the customer identifier from the invoice data. In yet another embodiment, determining the customer identifier comprises: obtaining a unique invoice identifier; and receiving an association request from a customer computing device corresponding to the customer identifier, the association request containing the unique invoice identifier. In another embodiment, obtaining the unique invoice identifier comprises generating the unique identifier and transmitting the unique identifier to the vendor computing device for capture by the customer computing device.

In an embodiment, receiving the invoice data comprises receiving invoice data from a customer computing device corresponding to the customer identifier. In another embodiment, extracting the vendor identifier comprises performing optical character recognition on the invoice data. In yet another embodiment, the provided method further comprises: when the remaining portion is non-zero, transmitting a notification to a customer computing device corresponding to the customer identifier, the notification containing an indication of the remaining portion.

In an embodiment, generating and transmitting the payment data comprises: requesting the payment data from an external payment system; and transmitting the payment data to a customer computing device corresponding to the customer identifier for presentation to a vendor computing device corresponding to the vendor identifier to effect the payment. In another embodiment, generating and transmitting the payment data comprises: sending a payment instruction to an external payment system to effect the payment; and sending payment notifications to each of (i) a customer computing device corresponding to the customer identifier and (ii) a vendor computing device corresponding to the vendor identifier.

A second aspect of the specification provides an intermediation server that fulfils the steps of the provided method.

A third aspect provides a system for real-time three-party transaction processing, comprising: (i) a vendor computing device associated with a vendor, and configured to generate invoice data defining a price payable to the vendor for supplying a product to a customer; (ii) an intermediation server configured to: receive the invoice data via a network; extract, from the invoice data, a vendor identifier corresponding to the vendor; determine, in association with the invoice data, a customer identifier corresponding to the customer; retrieve a payer identifier corresponding to a payer associated with the customer; retrieve, based on at least the payer identifier, a transaction policy; according to the retrieved transaction policy, allocate an eligible portion of the price to the payer identifier, and allocate a remaining portion of the price to the customer identifier; generate and transmit payment data, via the network, for initiating a payment of the eligible portion from the payer to the vendor; and (iii) a customer computing device associated with the customer, the customer computing device configured to: receive the payment data from the intermediation server via the network; and present the payment data for receipt by the vendor computing device to execute the payment of the eligible portion.

In an embodiment, the intermediation server is further configured, to generate the payment data, to request a virtual card number (VCN) from a payment subsystem connected with the intermediation server via the network; and wherein the customer computing device is configured to receive and present the VCN to the vendor computing device In another embodiment, the vendor computing device is configured to execute the payment of the eligible portion by transmitting the VCN to the payment subsystem. In yet another embodiment, the vendor computing device is configured to transmit the invoice data to the intermediation server via the network.

In an embodiment, the intermediation server is configured, responsive to receiving the invoice data from the vendor computing device, to obtain a unique invoice identifier and transmit the unique invoice identifier to the vendor computing device for presentation to the customer computing device; wherein the customer computing is configured to capture the unique invoice identifier and transmit an association request containing the customer identifier and the unique invoice identifier to the intermediation server via the network; and wherein the intermediation server is configured to determine the customer identifier by retrieving the customer identifier from the association request. In another embodiment, the customer computing device is configured to capture the invoice data and transmit the invoice data to the intermediation server via the network.

Embodiments are described with reference to the following figures, in which:.

<FIG> depicts a system <NUM> for real-time transaction intermediation. The transactions discussed herein typically include the provision of products (i.e. goods and/or services) from a vendor <NUM> to a customer <NUM>. The vendor <NUM>, in the present example, is a hotel operator and the products provided to the customer <NUM> may therefore be lodging in hotel rooms. As will be apparent to those skilled in the art, however, a wide variety of vendors may provide a wide variety of products to the customer <NUM>. As will also be apparent, although a single vendor <NUM> and a single customer <NUM> are illustrated in <FIG>, the functionality of the system <NUM> discussed herein may be applied to any suitable number of vendors <NUM> and customers <NUM>.

The products provided to the customer <NUM> by the vendor <NUM>, such as the above-mentioned hotel stays, have associated prices payable to the vendor <NUM> in exchange for the products. Payment of such prices to the vendor <NUM> is not necessarily made by the customer <NUM>, however, although the customer <NUM> is the recipient of the products. Specifically, in the example illustrated in <FIG>, the customer <NUM> is associated with a payer entity <NUM>. The payer entity <NUM> (also referred to simply as the payer <NUM> herein) may be an organization or an individual, and the association between the payer <NUM> and the customer <NUM> is not particularly limited. In the discussion below, for the purpose of illustration, the payer <NUM> is assumed to be a corporation employing the customer <NUM>. A wide variety of other associations between payers <NUM> and customers <NUM> are also contemplated. In general, as a result of the association (whatever the specific nature of the association may be) between the payer <NUM> and the customer <NUM>, it may be necessary for at least some payments for products supplied by the vendor <NUM> to the customer <NUM> to be made by the payer <NUM> rather than the customer <NUM>.

To that end, the system <NUM> includes various components enabling payment to be effected from the payer <NUM> (i.e. from an account, e.g. at a financial institution, controlled by the payer <NUM>) to the vendor <NUM> responsive to the provision of products by the vendor <NUM> to the customer <NUM>. Of particular note, the system <NUM> enables such payments to be made via intermediation of a primary transaction (i.e. the transaction during which the vendor <NUM> receives payment) between the vendor <NUM> and the customer <NUM>. In other words, the mechanisms discussed herein are not directed to retrospectively reimbursing the customer <NUM> for payments made by the customer <NUM> to the vendor <NUM>, via secondary transactions (i.e. transactions in which the customer <NUM> receives payment) occurring after the primary transaction. For the above reason, the intermediation functionality discussed herein is referred to as real-time intermediation, i.e. intermediate during the primary transaction.

To implement real-time intermediation of transactions, the system <NUM> includes a plurality of computing devices interconnected by a network <NUM>. The network <NUM> includes any suitable combination of local and wide-area networks (e.g. including the Internet), implemented as any suitable combination of wired and/or wireless networks. In particular, the system <NUM> includes an intermediation server <NUM> (also referred to herein simply as the server <NUM>) configured, as will be discussed in detail below, to receive invoice data defining a primary transaction. The intermediation server <NUM> is further configured to allocate portions of a payment (i.e. a price for the product(s) involved in the transaction) defined by the invoice data between the customer <NUM> and the payer <NUM>. The intermediation server <NUM> is further configured to generate and transmit payment data to other devices of the system <NUM> to effect payment of any portion allocated to the payer <NUM>, from the payer <NUM> to the vendor <NUM>.

The intermediation server <NUM>, to implement the above-mentioned functionality, stores an invoice repository <NUM> containing received invoice data as well as associated data generated and employed during transaction intermediation. The intermediation server <NUM> also stores a policy repository <NUM> containing rules and other settings employed both in carrying out the allocation of payment portions between the payer <NUM> and the customer <NUM>, and in effecting payments from the payer <NUM> to the vendor <NUM>.

The system <NUM> also includes a vendor computing device <NUM> operated by the vendor <NUM>. The vendor device <NUM> can be implemented as any one of, or any combination of, a server, desktop computer, mobile computing device, or the like. In general, the vendor device <NUM> generates invoice data specifying a price payable to the vendor <NUM> for one or more products supplied by the vendor <NUM> to the customer <NUM>. The vendor device <NUM> may also transmit the invoice data to other computing devices in the system <NUM>, in some embodiments, and may also receive notifications, payment data and the like from such other devices.

In addition, the system includes a customer computing device <NUM> operated by the customer <NUM>. The customer device <NUM> can be a desktop computer, a mobile computing device such as a smart phone, laptop computer, tablet computer or the like. The customer device <NUM> is configured to exchange data with one or more of the intermediation server <NUM> and the vendor device <NUM>. For example, in some embodiments the customer device <NUM> is configured to obtain invoice data and provide the invoice data to the intermediation server <NUM> to initiate intermediation of a transaction. The customer device <NUM> can also be configured to receive notifications and/or payment data from the intermediation server <NUM>.

Further, the system <NUM> includes a payer computing device <NUM> operated by the payer <NUM>. The payer device <NUM> can be implemented as any one of, or any combination of, a server, desktop computer, mobile computing device, or the like. The payer device <NUM> can be configured to receive notifications from the intermediation server <NUM>, and may also be configured to provide data to the intermediation server <NUM> for storage in the profile repository <NUM> (e.g. during deployment of the system <NUM>). For example, the payer device <NUM> can maintain and periodically update transaction policy data defining how payments are allocated between the payer <NUM> and the customer <NUM>. The payer device <NUM> can provide such policy data to the intermediation server <NUM>, or can respond to requests for policy decisions from the intermediation server <NUM>. The payer device <NUM> may also maintain an expense repository or the like, containing records defining payments made by the payer <NUM> for products provided to the customer <NUM>, and the like. Such records may be updated responsive to notifications received at the payer device <NUM> from the intermediation server <NUM>.

The system <NUM> also includes a payment subsystem <NUM>, including one or more computing devices (e.g. servers and the like) operated by one or more financial institutions, payment networks and the like. In general, the payment subsystem <NUM> maintains financial accounts associated with each of the payer <NUM> and the vendor <NUM> (and optionally, the customer <NUM>). The payment subsystem <NUM> is configured to receive payment instructions and effect payments (i.e. transfers of funds between the above-mentioned accounts). The payment subsystem <NUM> can also be configured to generate payment data, such as virtual credit card numbers and the like, for use by other components of the system <NUM> prior to effecting payment.

Turning now to <FIG>, before discussing the functionality of the system <NUM> in greater detail, certain components of the intermediation server <NUM> will be discussed in greater detail.

The intermediation server <NUM> includes at least one processor <NUM>, such as a central processing unit (CPU) or the like. The processor <NUM> is interconnected with a memory <NUM>, implemented as a suitable non-transitory computer-readable medium (e.g. a suitable combination of non-volatile and volatile memory subsystems including any one or more of Random Access Memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory, magnetic computer storage, and the like). The processor <NUM> and the memory <NUM> are generally comprised of one or more integrated circuits (ICs).

The server <NUM> also includes a communications interface <NUM> interconnected with the processor <NUM>. The communications interface <NUM> enables the server <NUM> to communicate with the other computing devices of the system <NUM> via the network <NUM>. The communications interface <NUM> therefore includes any necessary components (e.g. network interface controllers (NICs), radio units, and the like) to communicate via the network <NUM>. The specific components of the communications interface <NUM> are selected based on upon the nature of the network <NUM>. The server <NUM> can also include input and output devices (not shown) connected to the processor <NUM>, such as keyboards, mice, displays, and the like.

The components of the server <NUM> mentioned above can be deployed in a single enclosure, or in a distributed format. In some examples, therefore, the intermediate server <NUM> includes a plurality of processors, either sharing the memory <NUM> and communications interface <NUM>, or (e.g. when geographically distributed but logically associated with each other) each having distinct corresponding memories and communications interfaces.

The memory <NUM> stores the repositories <NUM> and <NUM> mentioned above in connection with <FIG>. The memory <NUM> also stores a plurality of computer-readable programming instructions, executable by the processor <NUM>, in the form of various applications. The applications stored in the memory <NUM> include an orchestrator application <NUM>, a notification application <NUM>, and a parser application <NUM>. As will be understood by those skilled in the art, the processor <NUM> executes the instructions of the applications <NUM>, <NUM> and <NUM> (as well as any other suitable applications stored in the memory <NUM>) in order to perform various actions defined by the instructions contained therein. In the description below, the processor <NUM>, and more generally the server <NUM>, are said to be configured to perform those actions. It will be understood that they are so configured via the execution (by the processor <NUM>) of the instructions of the applications stored in memory <NUM>.

Execution of the orchestrator application <NUM>, as will be discussed below, configures the intermediate server <NUM> to receive invoice data for storage in the repository <NUM>, and to intermediate a transaction to effect payment corresponding to the invoice data, based on the contents of the repository <NUM> (and optionally, data retrieved from computing devices external to the server <NUM>). The specific technical functions performed by the server <NUM> to implement the above functionality will be discussed in greater detail below.

The orchestrator application <NUM> can also implement one or more application programming interfaces (APIs) exposed to other computing devices via the network <NUM>, for sending and receiving various data relating to the transactions intermediated by the server <NUM>. The vendor device <NUM>, the customer device <NUM> and the payer device <NUM>, as will now be apparent to those skilled in the art, may be configured to transmit data to the server <NUM> in accordance with the above-mentioned APIs.

Execution of the notification application <NUM> configures the server <NUM> to generate and transmit notifications (e.g. email messages, text messages, application messages formatted according to one or more APIs, or the like) to one or more of the vendor device <NUM>, the customer device <NUM> and the payer device <NUM>. The notifications transmitted via execution of the application <NUM> are generated in response to certain actions performed via execution of the application <NUM>. In other examples, the functionality implemented by the application <NUM> can be implemented by a separate computing device in the system <NUM>, to which the server <NUM> transmits notification requests for processing.

The parser application <NUM>, when executed by the processor <NUM>, configures the server <NUM> to parse invoice data obtained by the server <NUM>. In particular, the server <NUM> can be configured to parse unstructured invoice data (e.g. images of printed receipts) to extract relevant information therefrom for further processing. The parser application <NUM> can also be executed to parse invoice data that, while not in image format, does not comply with a predetermined schema as will be discussed below. For example, the invoice data may be received as a PDF file containing computer-readable text rather than images. The text may nevertheless not be presented in a predefined schema and may therefore still require parsing. Such invoice data is also referred to herein as unstructured. In some embodiments, the functionality implemented by the application <NUM> can be implemented by a separate computing device in the system <NUM>, to which the server <NUM> transmits parsing requests, and from which the server <NUM> receives extracted invoice data.

Turning now to <FIG>, certain aspects of the operation of the system <NUM> will be described in greater detail. Specifically, <FIG> illustrates a method <NUM> of real-time transaction intermediation. The method <NUM> will be described in conjunction with its performance within the system <NUM>. In particular, the blocks of the method <NUM> are performed by intermediation server <NUM> via execution of the orchestrator application <NUM>, the notification application <NUM> and the parser application <NUM> by the processor <NUM>.

At block <NUM>, the server <NUM> is configured to receive invoice data defining a primary transaction. That is, the invoice data received at block <NUM> defines a price payable to the vendor <NUM> for supplying one or more products to the customer <NUM> (although, as will be evident in the discussion below, the invoice data does not necessarily identify the customer <NUM>). Several mechanisms are contemplated for receiving invoice data at block <NUM>, examples of which are illustrated in <FIG>.

Referring first to <FIG>, the invoice data can be received at block <NUM> from the vendor device <NUM> via the network <NUM>. For example, responsive to generation of the invoice data (e.g. when the customer <NUM> checks out of the hotel <NUM>), the vendor device <NUM> can be configured to transmit the invoice data to the server <NUM>. <FIG> illustrates example invoice data <NUM> in the form of structured data. That is, the invoice data <NUM> contains various attributes in computer-readable fields (e.g. name / value pairs), according to any suitable predefined schema. An example of the format employed for the invoice data is the "Invoice" schema defined by schema. org (e.g. see http://schema. org/Invoice), although a wide variety of other schemas may also be employed. Structured invoice data may be received in any of a variety of file formats, including eXtensible Markup Language (XML), JavaScript Object Notation (JSON), and the like.

Transmission of invoice data from the vendor device <NUM> to the server <NUM> typically requires integration between the vendor device <NUM> and the server <NUM>. For example, the vendor <NUM> may be required to configure the vendor device <NUM> to interoperate with the server <NUM> (e.g. via the APIs mentioned above), and to generate invoice data in the predefined format. Certain vendors may lack such integration, and the invoice data may therefore also be received at the server <NUM> from the customer device <NUM> rather than the vendor device <NUM>.

<FIG> illustrates the receipt of invoice data <NUM> from the customer device <NUM>. For example, the invoice data <NUM> may be an image (in any suitable file format, e.g. PDF, JPEG, or the like) of a printed invoice generated by the vendor device <NUM> or a peripheral connected thereto, and captured by a camera of the customer device <NUM>. The invoice data <NUM> is therefore referred to as unstructured, as specific attributes of the invoice data, although represented visually by the image, are not explicitly delimited according to a computer-readable format.

In other words, the invoice data can be received at block <NUM> from either of the vendor device <NUM> and the customer device <NUM>. Further, the invoice data can be received as structured data (e.g. as shown in <FIG>), or as unstructured data (e.g. as shown in <FIG>). Although the receipt of structured invoice data is shown in <FIG> as being associated with the vendor device <NUM>, in other examples structured invoice data can also be received from the customer device <NUM>. For example, the customer device <NUM> can be configured to generate a graphical interface for receiving input (e.g. from the customer <NUM>) consisting of the structured invoice data. Additionally, in some embodiments unstructured invoice data (e.g. an image as shown in <FIG>) can be received from the vendor device <NUM>. In further embodiments, the invoice data received at block <NUM> may include both an image as in <FIG> and structured data as in <FIG>.

Upon receipt of the invoice data, the server <NUM> is configured to store the invoice data in the repository <NUM>. The server <NUM> may also generate a unique identifier corresponding to the invoice data, and store the identifier in the repository in association with the invoice data.

For the server <NUM> to intermediate a transaction, the identities of each of the vendor <NUM>, the customer <NUM>, and the payer <NUM> must be known to the server <NUM>. At block <NUM>, the server <NUM> is therefore configured to extract a vendor identifier (i.e. of the vendor <NUM>) from the invoice data, and to determine a customer identifier (i.e. of the customer <NUM>) that corresponds to the invoice data. The actions performed by the server <NUM> to obtain the vendor and customer identifiers vary depending on the contents of the invoice data received at block <NUM>. <FIG> illustrates an example method of performing block <NUM>.

Beginning at block <NUM>, the server <NUM> is configured to determine whether the invoice data received at block <NUM> is structured or unstructured data. When the invoice data in unstructured, such as the invoice data <NUM> shown in <FIG> (e.g. an image captured by camera of the customer device <NUM>), the server <NUM> proceeds to block <NUM>. At block <NUM>, the server <NUM> is configured to parse the unstructured invoice data, for example via execution of the parser application <NUM>. Via execution of the parser application <NUM> the server <NUM> is configured to identify text in the invoice data <NUM> (e.g. via any suitable optical character recognition, OCR, operation), and to classify the text identified in the invoice data <NUM>. Classification of text identified in the invoice data <NUM> serves to identify portions of the text corresponding to various attributes of the primary transaction, including any one or more of a vendor identifier, a customer identifier, a price, date and/or time information, a description of the products provided by the vendor <NUM>, and the like. Classification of text identified in the invoice data can be achieved through the application of any suitable one of, or any suitable combination of, classification mechanisms, including machine learning-based classifiers.

In other words, at block <NUM> the server <NUM> is configured to generate structured invoice data from the unstructured invoice data. The output of the parsing operation(s) is stored in the repository <NUM> in association with the initially received unstructured invoice data, e.g. in a common data object. In some embodiments, rather than perform block <NUM> locally, the server <NUM> is configured to transmit a parsing request containing the unstructured invoice data to a further computing device of the system <NUM>, which is in turn configured to parse the unstructured invoice data and return the resulting structured invoice data to the server <NUM>.

At block <NUM>, having obtained structured invoice data (either via block <NUM>, or because the invoice data received at block <NUM> was structured invoice data), the server <NUM> is configured to extract a vendor identifier from the structured invoice data. The vendor identifier can be a name of the vendor, such as the string "HOTEL <NUM>" in the invoice data <NUM> shown in <FIG>. The vendor identifier may also be a predefined identifier also stored in the profile repository <NUM>, such as the string "HTL123" in the invoice data <NUM> shown in <FIG>. In other examples, the vendor identifier need not be extracted directly from the invoice data itself, but can instead be extracted from metadata accompanying the invoice data. For example, when the invoice data is received at block <NUM> in the form of structured invoice data via a predefined API call, the vendor device <NUM> has typically provided authentication data (e.g. an account identifier and password, or the like) to the server <NUM> prior to transmitting the invoice data. The authentication process associates the vendor device <NUM> with a vendor identifier from the profile repository <NUM>, and the vendor identifier therefore need not be present in the invoice data itself.

At block <NUM>, the server <NUM> is configured to determine whether the invoice data (or metadata associated therewith, obtained from a transmission containing the invoice data as described above) contains a customer identifier. In particular, the profile repository <NUM> includes records corresponding to each customer <NUM> enrolled for use of the system <NUM>, and the server <NUM> is configured to determine at block <NUM> whether a customer identifier corresponding to one of the above-mentioned records is present in the invoice data or associated metadata. Dependent on the presence or absence of a customer identifier, the server <NUM> is configured to select a different customer identification mechanism to obtain the customer identifier.

When the invoice data is received at block <NUM> from the customer device <NUM>, the determination at block <NUM> is typically affirmative. As discussed in connection with the vendor identifier at block <NUM>, the customer device <NUM> can be configured to transmit invoice data to the server <NUM> via an authenticated connection established via the network <NUM>, and therefore even when the invoice data lacks a customer identifier, the transmission (e.g. an API call transmitted by the customer device <NUM>) is associated with a customer identifier). In other examples, the invoice data itself includes a customer identifier, such as the string "Alice Smith" in the invoice data <NUM> or the email address "alice@acme. com" in the invoice data <NUM>.

When the determination at block <NUM> is negative, indicating that the invoice data (and any metadata associated with the transmission of the invoice data to the server <NUM>) does not contain a customer identifier matching a record in the profile repository <NUM>, the server <NUM> is configured to proceed to block <NUM>. At block <NUM>, the server <NUM> is configured to initiate an association process to retrieve a customer identifier. Typically, when the determination at block <NUM> is negative, the invoice data was received at block <NUM> from the vendor device <NUM> rather than from the customer device <NUM>. Therefore at block <NUM>, the server <NUM> is configured to transmit the above-mentioned unique invoice identifier to the vendor device <NUM> from which the invoice data was received at block <NUM>. The unique invoice identifier is presented by the vendor device <NUM>, e.g. on a display, via a short-range communication interface, or the like, for capture by the customer device <NUM>. The customer device <NUM> is then configured to transmit an association request to the server <NUM>, containing the unique identifier (as well as the customer identifier, by virtue of the above-noted authentication between the customer device <NUM> and the server <NUM>).

At block <NUM>, the server <NUM> is configured to receive the association request containing the invoice identifier and the customer identifier. At block <NUM>, the server <NUM> is configured to store the customer identifier in the repository <NUM> in connection with the invoice data. <FIG> illustrates the above-mentioned process. In particular, <FIG> illustrates the transmission of structured invoice data <NUM> from the vendor device <NUM> to the intermediation server <NUM> (i.e. at block <NUM>). As illustrated in <FIG>, the invoice data <NUM> does not include any information identifying the customer <NUM> (in contrast to the invoice data <NUM> shown in <FIG>).

Following the receipt of the invoice data <NUM>, the server <NUM> is configured to extract and store the vendor identifier "HTL123" at block <NUM>. Further, in response to a negative determination at block <NUM>, at block <NUM> the server <NUM> is configured to generate and transmit a unique invoice identifier <NUM> to the vendor device <NUM>. In the present example, the identifier is the string "B2NUKGIN5OR5", although a wide variety of other identifier formats may also be employed.

Upon receipt of the invoice identifier <NUM>, the vendor device <NUM> is configured to present the invoice identifier <NUM> for capture by the customer device <NUM>. The mechanism of presentation, in the example shown in <FIG>, is to render the string as a machine-readable indicium such as a QR code <NUM> on a display <NUM> of the vendor device <NUM>. Other presentation mechanisms may also be employed, however, including transmitting the identifier <NUM> via short-range communication protocol (e.g. near-field communication, NFC). The customer device <NUM> is configured to capture the identifier <NUM>, for example by capturing an image of the QR code <NUM> and decoding the identifier <NUM> therefrom. Following capture of the identifier <NUM>, the customer device <NUM> is configured to transmit an association request <NUM> containing a customer identifier (e.g. "alice@acme. com") and the identifier <NUM>. The request <NUM> may, for example, employ a "getinvoice" service implemented by the above-mentioned APIs exposed by the server <NUM>. The server <NUM>, responsive to receiving the request <NUM> (at block <NUM>), stores the customer identifier in association with the invoice data. In other words, the process illustrated in <FIG> and <FIG> enables the customer device <NUM> to "claim" invoice data provided to the server <NUM> without any customer identifier.

At block <NUM>, the server <NUM> can also be configured to generate one or more notifications for transmission to one or more of the customer device <NUM>, the vendor device <NUM>, and the payer device <NUM>. For example, when the invoice data is received from the vendor device <NUM> at block <NUM> and identifies the customer <NUM>, such that there is no need for the invoice claiming process shown in <FIG>, the server <NUM> can be configured to transmit a notification to the customer device <NUM> via execution of the notification application <NUM> containing at least a portion of the invoice data, indicating that the invoice data has been submitted by the vendor <NUM> and is undergoing processing. In further examples, when the invoice data is received from the customer device <NUM> at block <NUM>, the server <NUM> can be configured to generate a notification for transmission to the vendor device <NUM> containing at least a portion of the invoice data, indicating that the invoice data has been submitted by the customer <NUM> and is undergoing processing.

Thus, returning to <FIG>, following the performance of block <NUM>, the repository <NUM> contains the invoice data received at block <NUM>, as well as a structured version of the invoice data when the original invoice data was unstructured, and identifiers corresponding to each of the vendor <NUM> and the customer <NUM>.

At block <NUM>, the server <NUM> is configured to retrieve a payer identifier (i.e. corresponding to the payer <NUM> and therefore the payer device <NUM>). For example, the payer ID may be retrieved from the profile repository <NUM> based on the customer identifier determined at block <NUM>. More specifically, the repository <NUM> defines logical links between payer identifiers and customer identifiers, for example to indicate which customers <NUM> are associated with which payers <NUM> (e.g. by employment). Therefore, at block <NUM> the server <NUM> can be configured to query the repository <NUM> for a payer identifier that is logically linked to the customer identifier from block <NUM>.

In other examples, the retrieval of the payer identifier at block <NUM> may be performed simultaneously with the performance of block <NUM>. For example, the invoice data itself (as received at block <NUM>) may contain the payer identifier. This may be the case when, for example, the products represented by the invoice data are travel-related services previously reserved by the payer <NUM> on behalf of the customer <NUM>, and therefore previously associated with the payer <NUM>. In such instances, the separate performance of block <NUM> is unnecessary and may be omitted. Following retrieval of the payer identifier at block <NUM>, the server <NUM> can also be configured to transmit a notification to the payer device <NUM>, for example containing at least a portion of the invoice data and at least one of the customer identifier and the vendor identifier.

Having retrieved the payer identifier at block <NUM>, the server <NUM> is configured to proceed to block <NUM>. At block <NUM>, the server <NUM> is configured to retrieve a transaction policy for application to the primary transaction defined by the invoice data, based at least on the payer identifier from block <NUM>. The profile repository <NUM>, as noted earlier, contains rules and other settings for allocating portions of the price defined for a transaction between the payer <NUM> and the customer <NUM>. The contents of the profile repository <NUM> also defines criteria for selecting methods of payment and information employed to effect payments from the payer <NUM> to the vendor <NUM>. The above-mentioned information is collectively referred to as a transaction policy. The repository <NUM> contains a transaction policy for each payer <NUM> for which the system <NUM> has been deployed. At block <NUM> the server <NUM> is therefore configured to retrieve the transaction policy corresponding to the payer identifier (i.e. to the payer <NUM>, in the present example).

In general, the transaction policy defines criteria for allocating expenses between the payer <NUM> and the customer <NUM>. In other words, the transaction policy defines criteria permitting the server <NUM> to determine whether the product(s) indicated in the invoice data are eligible for payment by the payer <NUM>, ineligible for payment by the payer <NUM> (and therefore require payment by the customer <NUM>), or eligible only in part. The policy can define any of a wide variety of criteria for making the above allocation, a number of examples of which will occur to those skilled in the art.

An example of criteria defined in the transaction policy include criteria based on product types. For example, the policy can define eligible product types, such as hotel rooms, that are eligible for payment by the payer <NUM>, and ineligible product types, such as minibar charges associated with hotel rooms, that are not eligible for payment by the payer <NUM>. As will now be apparent, the invoice data received at block <NUM> typically itemizes individual products, and each product can therefore be assessed independently. Product type-based criteria can also specify that certain product types are partially eligible, e.g. that a specified percentage of the price of a product is eligible, or that the product is eligible up to a threshold price (and therefore that any portion of the product's price beyond the threshold is ineligible).

Further examples of criteria defined in the transaction policy include geographic criteria, defining whether expenses are eligible for payment by the payer <NUM> based on the geographic location of one or both of the vendor <NUM> and the customer <NUM>. Still further examples of criteria defined in the transaction policy include validation criteria applied to certain product types. For example, the transaction policy can contain a criterion requiring the comparison of a vendor location to travel itinerary data corresponding to the customer <NUM>, and specifying that the expense is eligible only if the vendor location aligns with the itinerary data. The itinerary data can be stored at the payer device <NUM>, or at a distinct subsystem connected to the network <NUM>.

At block <NUM>, having retrieved the relevant transaction policy from the repository <NUM>, the server <NUM> is configured to apply the policy to the invoice data. Application of the transaction policy to the invoice data serves to allocate an eligible portion of the price defined in the invoice data for payment by the payer <NUM>. Any remaining portion of the price defined in the invoice data is ineligible for payment by the payer <NUM>, and must instead be paid by the customer <NUM>. The remaining, ineligible, portion of the price is therefore allocated for payment by the customer <NUM>. The application of the policy at block <NUM> is performed by comparing the invoice data to the criteria defined by the policy, to determine which portion of the price defined by the invoice data is eligible. For example, a geographic criterion may be assessed by comparing a location of the vendor <NUM> (retrieved according to the vendor identifier obtained at block <NUM>) to a location or region defined by the criterion.

The output of the application of the transaction policy is an allocation of the entirety of the total price defined in the invoice data (e.g. $<NUM> in the invoice data shown in <FIG>) between the payer <NUM> and the customer <NUM>. The eligible portion, allocated to the payer <NUM>, may be between zero and the entirety of the price. Any portion of the price that is not eligible is allocated to the customer <NUM>, such that the sum of the eligible and ineligible portions is equal to the total price. The server <NUM> can be configured to transmit notifications to one or more of the payer device <NUM>, the vendor device <NUM> and the customer device <NUM> indicating the allocations.

At block <NUM>, the server <NUM> is configured to generate and transmit one or more of payment data and notification(s). In particular, when the eligible portion is non-zero, the server <NUM> is configured to generate payment data for transmission to one or more elements of the system <NUM> to initiate a payment of the eligible portion from the payer <NUM> to the vendor <NUM>. When the eligible portion is zero, the generation of payment data is typically omitted, and the server <NUM> may generate notifications only at block <NUM>.

Turning to <FIG>, an example method of performing block <NUM> at the server <NUM> is illustrated. At block <NUM>, the server <NUM> is configured to determine whether the eligible portion of the total price defined by the invoice data as determined at block <NUM> is non-zero. When the eligible portion is zero, indicating that the entire price defined by the invoice data is allocated to the customer <NUM> rather than the payer <NUM>, the performance of block <NUM> passes directly to block <NUM> (to be discussed below), without generating payment data.

When the determination at block <NUM> is affirmative, the server <NUM> selects a payment method and obtains payment data at block <NUM>. The selection of a payment method can be based on the transaction policy retrieved at block <NUM>. For example, the transaction policy can define, in addition to the above-mentioned allocation criteria, payment method selection criteria. The payment method selection criteria define one or more payment methods and corresponding conditions under which each payment method may be selected. For example, certain payment methods may correspond to specific geographic areas, specific vendors, specific customers, or the like.

A variety of payment methods are contemplated, including payment methods initiated directly by the server <NUM> (e.g. wire transfers), and payment methods initiated by the customer device <NUM> using data received from the server <NUM>. For example, the selected payment method may be a virtual credit card (VCC, also referred to as a virtual card number, VCN), in which the server <NUM> obtains and provides a VCN to the customer device <NUM>, for subsequent presentation to the vendor device <NUM> to effect the payment.

The mechanism employed by the server <NUM> to obtain the payment data therefore varies with the selected payment mechanism. For example, in the case of a virtual credit card, the server <NUM> is configured, at block <NUM>, to send a request to the payment subsystem <NUM> for a VCN associated with a predetermined account corresponding to the payer <NUM>. For other payment methods, the payment data may be generated locally at the server <NUM>, e.g. in the form of wire transfer instructions.

At block <NUM>, the server <NUM> is configured to determine whether the payment method selected at block <NUM> requires payment to be effected via the customer device <NUM> (as noted above in connection with the VCN payment method). When the determination is negative, the server <NUM> proceeds to block <NUM>, and transmits a payment instruction including the payment data to the payment subsystem <NUM>. For example, the server <NUM> can transmit a wire transfer instruction to a financial institution for transferring the eligible portion allocated at block <NUM> from an account (e.g. defined in the repository <NUM>) associated with the payer <NUM> to an account associated with the vendor <NUM>.

When the determination at block <NUM> is affirmative, the server <NUM> instead transmits the payment data to the customer device <NUM> at block <NUM>. For example, the server <NUM> can transmit the above-mentioned VCN to the customer device <NUM>, for presentation to the vendor device <NUM> or an associated device (e.g. a point-of-sale terminal). The vendor device <NUM>, in turn, transmits the VCN to the payment subsystem <NUM> to effect the payment, as will be apparent to those skilled in the art. The transmission of payment data to the customer device <NUM> at block <NUM> can be accompanied by a notification of any ineligible portion of the payment as allocated at block <NUM>. For example, referring to <FIG>, an example interface presented by the customer device <NUM> is illustrated, including payment data <NUM> received from the server <NUM> in the form of a virtual credit card, and an indication <NUM> of the eligible portion of the total invoice price. Also shown in <FIG> is a notification <NUM> (e.g. received along with the payment data) indicating that a portion of the invoice's price is ineligible for payment by the payer <NUM>, and must be paid by the customer <NUM>. The notification <NUM> can also include, in some examples, an indication <NUM> of the reason(s) for ineligibility (i.e. indications of which criteria in the transaction policy resulted in allocation of the ineligible portion to the customer <NUM>).

Following the performance of either of blocks <NUM> and <NUM>, at block <NUM> the server <NUM> awaits confirmation that the payment has been completed. Confirmation may be received at block <NUM> from the payment subsystem <NUM>, for example in the form of an Instant Payment Notification (IPN) message generated by the payment subsystem <NUM>.

Following receipt of payment confirmation at block <NUM>, the server <NUM> is configured to generate at least one notification at block <NUM>. In particular, the server <NUM> can notify any one or more of the payer device <NUM>, the vendor device <NUM> and the customer device <NUM> that the payment has been completed.

Variations to the above systems and methods are contemplated. For example, in some embodiments the server <NUM> can be configured to generate and transmit payment data to the customer device (e.g. a VCN, as discussed above), without receiving invoice data defining a specific primary transaction. For example, the payment data may define a per-diem amount usable by the customer <NUM> for payment of any invoices (i.e. to any vendor <NUM>). The performance of blocks <NUM>-<NUM>, in other words, may be omitted and the payment data may be generated according to the transaction policy for a predetermined amount (or an amount requested by the customer device <NUM>).

In further embodiments, certain blocks of the method <NUM> can be performed by the server <NUM> only in response to explicit requests, e.g. from the customer device <NUM>. For example, the performance of block <NUM> may be initiated only in response to an approval request submitted by the customer device <NUM> (once the customer device <NUM> has received the processed invoice data obtained via blocks <NUM>-<NUM>).

In further embodiments, transaction policies may be maintained at the payer device <NUM> rather than in the repository <NUM> at the intermediation server <NUM>. In such embodiments, rather than retrieving a transaction policy at block <NUM> and applying the policy to allocate portions of the payment to the payer <NUM> and/or the customer <NUM>, the server <NUM> is configured to transmit a request for a policy decision to the payer device <NUM>. The request may include, for example, the invoice data as well as the identifiers determined at blocks <NUM> and <NUM>. Responsive to the request, the server <NUM> receives a policy decision from the payer device <NUM>, specifying the allocation of eligible and ineligible portions of the price defined by the invoice data.

Claim 1:
A method of real-time three-party transaction processing, comprising, at an intermediation server:
receiving invoice data defining a price payable to a vendor for supplying a product to a customer;
prior to initiation of a payment to the vendor for supplying the product:
extracting, from the invoice data, a vendor identifier corresponding to the vendor;
selecting, based on the invoice data, a customer identification mechanism; determining, in association with the invoice data, a customer identifier corresponding to the customer according to the selected customer identification mechanism, wherein, in response to a determination that the invoice data does not contain the customer identifier, determining the customer identifier comprises:
obtaining a unique invoice identifier, wherein obtaining the unique invoice identifier comprises generating the unique invoice identifier and transmitting the unique invoice identifier to a vendor computing device for capture by a customer computing device; and
receiving an association request from the customer computing device containing the unique invoice identifier and the customer identifier;
retrieving a payer identifier corresponding to a payer associated with the customer;
retrieving, based on at least the payer identifier, a transaction policy;
according to the retrieved transaction policy, allocating an eligible portion of the price to the payer identifier, and allocating a remaining portion of the price to the customer identifier; and
generating and transmitting payment data for initiating a payment of the eligible portion from the payer to the vendor.