DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Double Patenting
Claims 23–42 are rejected on the ground of non-statutory obviousness-type double patenting as being unpatentable over claims 1–20 of U.S. Patent No. 12,387,232 B2.
Although the claims at issue are not identical, they are not patentably distinct from the claims of U.S. Patent No. 12,387,232 B2 because the presently claimed subject matter constitutes an obvious variation of the patented payment-routing architecture.
The judicially created doctrine of obviousness-type double patenting is intended to prevent an unjustified or improper timewise extension of patent rights and to prevent multiple patents from issuing on claims that are merely obvious variations of one another.
For purposes of this rejection, the claims of U.S. Patent No. 12,387,232 B2 constitute the reference claims.
With respect to claim 23, patented claim 1 recites receiving, by a POS computing system, payment vehicle data corresponding to a payment vehicle for a credit transaction. Thus, patented claim 1 encompasses the presently claimed step of receiving payment vehicle data associated with a payment vehicle tendered by a user.
Regarding: determining, by the POS computing system, whether a credit transaction includes enhanced data requiring alternate routing, patented claim 2 recites determining whether the credit transaction is to be routed to the issuer through an out-of-band network or through a card network.
Patented claims 4 and 5 further teach making the routing determination according to transaction-specific parameters. Claim 4 expressly identifies consumer data, loyalty data, offer data, account data, and SKU data as transaction-specific information affecting the routing determination.
Thus, the patented claims establish determining at the POS whether transaction information requires an alternative communication route based upon characteristics/data associated with the transaction.
Regarding: splitting ... the credit transaction into an authorization request message and an enhanced data message, the patented claims do not expressly require splitting a single transaction into those two messages.
However, patented claims 1–7 collectively claim transmitting transaction information between the POS and issuer through an out-of-band network while claim 2 expressly contemplates both an out-of-band network and a card network as alternative transaction-routing infrastructures. Patented claims 3 and 7 further establish that the out-of-band network may be a PIN debit network different from the card network.
Given this claimed architecture, it would have been an obvious variation to communicate the ordinary authorization request over the ordinary card-network route while communicating the transaction-specific enhanced information identified in patented claim 4 over the already-claimed out-of-band/PIN-debit route. Such arrangement predictably utilizes each existing network to carry the information suited to that route while preserving conventional authorization processing.
Regarding: transmitting ... the authorization request message to an issuer computing system via an acquirer computing system and a card network, patented claim 2 expressly claims the alternative of routing the credit transaction to the issuer computing system via a card network.
Regarding: transmitting ... the enhanced data message to the issuer computing system via a ... PIN debit network, patented claim 3 expressly provides that the out-of-band network comprises a PIN debit network, while patented claim 4 expressly associates the alternate routing decision with transaction-specific enhanced information including consumer, loyalty, offer, account, and SKU information.
Patented claim 7 further requires that the out-of-band network be different from the card network associated with the payment vehicle.
Regarding: matching ... the authorization request message and the enhanced data message using a common identifier for processing the credit transaction, the patented claims do not expressly recite matching two separately routed messages using a common identifier.
Nevertheless, once transaction information corresponding to the same credit transaction is communicated over the two network paths expressly contemplated by patented claims 2, 3, 4, and 7, it would have been obvious to associate the separately received information with the corresponding transaction using a transaction identifier or other common identifier. Such correlation would have been necessary or at least an obvious implementation choice to ensure that the issuer applies the separately transmitted transaction-specific information to the correct authorization transaction.
Accordingly, the differences between instant claim 23 and patented claims 1–7 reside principally in dividing the transaction information between the two claimed communication paths and correlating the resulting messages at the issuer, which constitutes an obvious variation of the dual-routing payment architecture already claimed in the patent.
Therefore, claim 23 is not patentably distinct from claims 1–7 of U.S. Patent No. 12,387,232 B2.
Claim 24 further requires queuing the authorization request message until the enhanced data message is received and thereafter processing the authorization request.
As explained with respect to claim 23, the patented claims render obvious communicating transaction-related information over separate card-network and out-of-band paths.
Once related transaction information is received through separate communication paths, it would have been obvious to delay completion of authorization processing until the related information necessary for processing the transaction is available. Queuing the first-arriving message pending receipt of its corresponding message represents a predictable synchronization mechanism for the dual-path arrangement.
Accordingly, claim 24 is not patentably distinct from patented claims 1–7.
Claim 25 requires generating an authorization response based upon the matched authorization request and enhanced data and transmitting the authorization response to the POS through the acquirer and card network.
Patented claim 1 expressly claims the issuer providing an authorization response message corresponding to the credit transaction and the POS receiving that authorization response.
Patented claim 2 expressly claims use of the card network as a transaction route. Once the authorization request is routed through the card network as discussed above, returning the corresponding authorization response through that transaction path would have been an obvious implementation of the patented transaction architecture. Accordingly, claim 25 is not patentably distinct.
Claim 26 specifies that the card network relays the authorization request and response between the acquirer and issuer.
Patented claim 2 expressly recites routing the transaction from the POS to the issuer through a card network. Employing the conventional card network to relay corresponding authorization requests and responses constitutes an obvious implementation of that claimed card-network routing alternative.
Accordingly, claim 26 is not patentably distinct.
Claim 27 requires the PIN debit network to comprise one-to-many or many-to-many configurations connecting the POS to an acquirer or issuer and to operate as an out-of-band communication network for the enhanced data. Patented claim 3 expressly recites that the out-of-band network comprises a PIN debit network. Patented claim 6 recites an out-of-band network comprising a closed-loop communication channel connecting the POS to the issuer.
Patented claim 7 expressly requires the out-of-band network to be different from the card network.
Thus, use of the PIN debit network as the out-of-band communication channel is expressly claimed by the patent. The particular one-to-many or many-to-many network topology represents an obvious implementation detail of that claimed network architecture and does not render claim 27 patentably distinct.
Claim 28 requires determining whether a user response is required based upon enhanced data and transmitting a response request to the POS through the PIN debit network.
Patented claim 4 expressly identifies transaction-specific consumer data, loyalty data, offer data, account data, and SKU data as information used in routing/processing the credit transaction, while claims 1, 3, and 6 establish bidirectional POS-to-issuer communications through the out-of-band network.
It would have been obvious, when such transaction-specific information indicates additional customer input is required, to request that input through the same out-of-band communication path being used to exchange the enhanced transaction information.
Accordingly, claim 28 constitutes an obvious variation of the patented claims.
Claim 29 requires receiving the requested user response at the POS and transmitting it to the issuer through the PIN debit network. For the reasons discussed regarding claim 28, returning the requested response through the same PIN-debit/out-of-band communication path represents the predictable reciprocal communication required to complete the requested information exchange. Claim 29 therefore is not patentably distinct.
Claim 30 requires transmitting the authorization request message and enhanced data message in parallel. Patented claims 2, 3, and 7 establish two different available communication infrastructures: the card network and a separate out-of-band PIN debit network. Once the transaction is divided between those independent communication paths, transmitting the respective messages concurrently rather than serially would have been an obvious optimization to reduce transaction-processing latency.
Claim 30 therefore constitutes an obvious variation of the patented dual-network architecture.
Claim 31 requires the enhanced data message to include an identifier corresponding to a transaction identifier in the authorization request.
As explained regarding claim 23, correlation of separately transmitted information belonging to the same transaction would have been an obvious requirement or implementation choice when employing the two claimed network paths. Providing corresponding transaction identifiers represents a predictable mechanism for accomplishing such association.
Accordingly, claim 31 is not patentably distinct.
Claim 32 specifies enhanced data comprising: loyalty account identifier; SKU data; promotional offer data; financial offer data; payment-card application data; or credit-line-increase data.
There is particularly substantial overlap with patented claim 4, which expressly claims transaction-specific parameters comprising: consumer data; loyalty data; offer data; account data; and SKU data.
Thus, loyalty information, SKU information, and offer information are expressly encompassed by the patented claims. Financial offers, payment-card application information, and credit-line information represent closely related financial/account information employed in determining or processing a credit transaction and constitute predictable variations of the claimed offer and account data.
Claim 32 therefore does not define patentably distinct subject matter.
System Claims 33–39
Claim 33
Claim 33 recites the system counterpart of method claim 23.
Patented independent claim 8 claims a POS device comprising memory and processors configured to:
receive payment vehicle data;
transmit an authorization request to the issuer over an out-of-band network;
receive an authorization response over that network; and
execute the credit transaction.
Patented claims 9–14 correspond to claims 2–7 and additionally claim:
selection between card-network and out-of-band routing;
a PIN debit network;
routing according to loyalty, offer, account, and SKU information;
closed-loop communications; and
an out-of-band network different from the card network.
For substantially the same reasons explained with respect to claim 23, splitting the information between the already-claimed card-network and PIN-debit-network paths and correlating the messages at the issuer constitutes an obvious variation of patented claims 8–14.
Accordingly, claim 33 is not patentably distinct.
Claims 34–39 substantially correspond to method claims 24–29 in system form.
Thus:
claim 34's queuing corresponds to the synchronization discussed for claim 24;
claim 35's authorization response corresponds to claim 25;
claim 36's card-network relaying corresponds to claim 26;
claim 37's PIN-debit out-of-band topology corresponds to claim 27;
claim 38's user-response request corresponds to claim 28; and
claim 39's return of the user response corresponds to claim 29.
Changing the statutory form from method limitations to processor-executed system operations does not render the subject matter patentably distinct where the substantive transaction-processing operations remain obvious variations of patented claims 8–14.
Accordingly, claims 34–39 are rejected on the ground of OTDP.
Computer-Readable-Medium Claims 40–42
Claim 40
Claim 40 recites the computer-readable-medium counterpart of claim 23.
Patented independent claim 15 already claims a non-transitory computer-readable medium storing instructions for causing POS processors to receive payment vehicle data, communicate an authorization request with the issuer through the out-of-band network, receive an authorization response, and execute the credit transaction.
Patented claims 16–20 further claim:
determining card-network versus out-of-band routing;
use of a PIN debit network;
transaction-specific consumer, loyalty, offer, account, and SKU data;
BIN/account/interchange-fee routing parameters; and
a closed-loop POS-to-issuer out-of-band communication channel.
For the same reasons discussed regarding claims 23 and 33, dividing the transaction into conventionally routed authorization information and enhanced information routed through the already-claimed PIN debit channel represents an obvious variation of the patented computer-readable-medium claims.
Claim 40 therefore is not patentably distinct from patented claims 15–20.
Claim 41 adds queuing of the authorization request until enhanced data arrives.
For the reasons discussed regarding claim 24, synchronizing separately routed transaction messages by retaining the first message until its associated message arrives represents a predictable implementation of the obvious dual-path transaction arrangement.
Claim 41 therefore is not patentably distinct.
Claim 42 requires generating an authorization response based upon the matched authorization request and enhanced data and returning the response through the acquirer/card-network route. Patented claim 15 expressly requires receiving an authorization response corresponding to the credit transaction, and patented claim 16 expressly establishes the card network as an available transaction route.
Using the card-network path to return the authorization response when that same path carries the authorization request constitutes a predictable implementation of the patented payment architecture. Claim 42 therefore is not patentably distinct.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 29 and 39 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
With respect to claim 29, the claim recites:
“receiving, by the POS computing system, the user response; and transmitting, by the POS computing system, the user response to the issuer computing system via the PIN debit network.”
However, claim 29 depends from claim 26. Neither claim 26 nor independent claim 23, from which claim 26 depends, previously introduces or defines a “user response.”
Although claim 28 introduces a “user response” by reciting determining whether such response is required and transmitting a response request message “for receiving the user response,” claim 29 does not depend from claim 28.
Consequently, it is unclear what previously recited subject matter is referenced by “the user response” in claim 29. The dependency chain of claim 29 therefore fails to provide proper antecedent basis for this limitation, thereby rendering the metes and bounds of claim 29 uncertain.
Accordingly, claim 29 is indefinite.
With respect to claim 39, claim 39 similarly recites: “receiving, by the POS computing system, the user response; and transmitting, by the POS computing system, the user response to the issuer computing system via the PIN debit network.”
Claim 39, however, depends from claim 36. Neither claim 36 nor independent claim 33 introduces a “user response.”
Claim 38 introduces the user-response functionality, but claim 39 does not depend from claim 38.
Thus, it is unclear what previously recited subject matter is referenced by “the user response” in claim 39.
Accordingly, claim 39 is indefinite under 35 U.S.C. 112(b).
Claims 24, 34, and 41 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 24 recites: “wherein transmitting the authorization request message and the enhanced data message, further comprises:”
followed by: (1) “queuing, by the issuer computing system, the authorization request message until the enhanced data message is received”; and
(2) “processing, by the issuer computing system, the authorization request message upon receiving the enhanced data message.”
The scope of the claim is unclear because queuing a received authorization request and subsequently processing the authorization request are not facially acts comprising “transmitting” the authorization request message and enhanced data message.
Rather, the parent claim separately recites transmission of the respective messages from the POS computing system to the issuer computing system. Claim 24 thereafter characterizes issuer-side queuing and processing as further comprising that transmission.
Accordingly, it is unclear whether claim 24 requires:
(a) additional operations performed as part of the claimed transmission;
(b) post-transmission issuer processing;
(c) a particular store-and-forward transmission mechanism; or
(d) some combination thereof.
The relationship between the introductory phrase and the subsequently recited operations therefore fails to define the claimed method with reasonable clarity.
The same deficiency occurs in claim 34, which recites substantially identical language in system form, and claim 41, which recites substantially identical language in computer-readable-medium form.
Accordingly, claims 24, 34, and 41 are indefinite under 35 U.S.C. 112(b).
Claim 27 is rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 27 recites, in pertinent part: “wherein the PIN debit network includes one-to-many or many-to-many network configurations that connects the POS computing system to the acquirer computing system or the issuer computing system.”
The recitation renders the scope uncertain.
First, it is unclear whether “that connects” modifies the singular “PIN debit network,” each individual “network configuration,” or collectively the plural “network configurations.”
Second, the recitation “connects the POS computing system to the acquirer computing system or the issuer computing system” leaves unclear whether the claimed PIN debit network must provide:
(a) a POS-to-acquirer connection;
(b) a POS-to-issuer connection;
(c) either connection alternatively; or
(d) both connections as components of the claimed one-to-many or many-to-many architecture.
This ambiguity is particularly material because claim 23 separately requires the enhanced data message to be transmitted to the issuer computing system via the PIN debit network.
Accordingly, the boundaries of the claimed network topology are not reasonably clear.
Claim 27 is therefore indefinite under 35 U.S.C. 112(b).
IV. Claim 37
Claim 37 contains substantially the same “one-to-many or many-to-many network configurations that connects” language as claim 27. Accordingly, claim 37 is rejected under 35 U.S.C. 112(b) for substantially the same reasons set forth above with respect to claim 27.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 23–42 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception without reciting additional elements sufficient to integrate the judicial exception into a practical application or amount to significantly more than the judicial exception.
For purposes of examination, independent claims 23, 33, and 40 are representative because the claims recite substantially corresponding method, system, and computer-readable-medium implementations of the same underlying transaction-processing concept.
Step 1 — Statutory Category
Claim 23 recites a computer-implemented method and therefore falls within the statutory category of a process.
Claim 33 recites a system comprising processors and a non-transitory computer-readable medium and therefore falls within the statutory category of a machine.
Claim 40 recites a non-transitory computer-readable medium storing executable instructions and therefore falls within the statutory category of a manufacture.
Accordingly, claims 23, 33, and 40 satisfy Step 1 and are analyzed under Step 2A of the Alice/Mayo framework.
Step 2A, Prong One — The Claims Recite a Judicial Exception
Independent claim 23 recites, inter alia:
receiving payment vehicle data associated with a payment vehicle tendered by a user;
determining whether a credit transaction includes enhanced data requiring alternate routing;
in response to determining that alternate routing is required, splitting the credit transaction into an authorization request message and an enhanced data message; transmitting the authorization request message to an issuer via an acquirer and card network; transmitting the enhanced data message to the issuer via a PIN debit network; and matching the authorization request message and enhanced data message using a common identifier for processing the credit transaction.
These limitations, considered under their broadest reasonable interpretation, describe the processing and authorization of a payment transaction between a merchant/POS, acquirer, card network, and issuer.
The claimed concept therefore recites a certain method of organizing human activity, namely a commercial interaction and fundamental economic practice involving processing, routing, and authorizing a financial transaction.
Payment processing is an activity relating directly to commercial interactions between a purchaser, merchant, acquirer, payment network, and issuing institution. Determining how transaction information should be routed, forwarding transaction information to the appropriate financial institution, associating related transaction information, and determining whether the transaction should be authorized are integral portions of that commercial interaction.
The claim additionally recites acts of determining whether information satisfies a routing condition and matching two sets of transaction information according to a common identifier. To the extent these limitations encompass evaluating information according to specified criteria and associating information having a common identifier, such limitations additionally constitute mental processes involving evaluation and judgment.
Accordingly, claim 23 recites an abstract idea comprising the commercial interaction of processing and authorizing a payment transaction, together with evaluation and matching of transaction information.
Independent claims 33 and 40 recite substantially the same abstract transaction-processing operations in system and computer-readable-medium form, respectively. Merely claiming the same abstract process in different statutory categories does not alter the character of the underlying judicial exception.
Therefore, claims 23, 33, and 40 recite a judicial exception.
Step 2A, Prong Two — The Judicial Exception Is Not Integrated Into a Practical Application
The claims are next evaluated as a whole to determine whether the additional elements integrate the judicial exception into a practical application.
The additional elements of claim 23 include: a POS computing system; an issuer computing system; an acquirer computing system; a card network;
a PIN debit network; and electronic transmission of transaction messages between the recited systems.
These elements merely provide the technological environment in which the abstract payment-processing activity is performed.
The POS computing system performs the ordinary functions of receiving payment information, determining routing, generating or separating transaction information, and transmitting information.
The acquirer computing system and card network perform their ordinary intermediary functions of conveying authorization information between a merchant/POS and issuer.
The issuer computing system receives transaction information, associates corresponding transaction information, processes the transaction, and generates transaction responses.
Likewise, the PIN debit network is used as an additional communication channel for conveying enhanced transaction information.
The claims do not recite a technological improvement to the operation of the POS computing system, issuer computing system, acquirer computing system, card network, or PIN debit network itself.
Rather, the recited computing systems and networks are used as tools for implementing the underlying commercial transaction.
The limitation requiring the credit transaction to be “split” into an authorization request message and an enhanced data message does not, as presently claimed, specify a new message protocol, packet structure, network protocol, encryption mechanism, routing algorithm, network-control technique, or other technological mechanism that improves computer or network functionality.
Similarly, routing the authorization request over a card-network path while routing enhanced transaction information through a PIN debit network merely specifies which communication channels carry different portions of the commercial transaction information.
The subsequent matching of the messages using a common identifier likewise constitutes data association performed in furtherance of processing the underlying payment transaction.
Thus, viewed individually and as an ordered combination, the additional elements merely apply the abstract commercial transaction-processing concept using computing systems and communication networks as tools.
The claims therefore do not integrate the judicial exception into a practical application.
Accordingly, independent claims 23, 33, and 40 are directed to the judicial exception.
Step 2B — The Claims Do Not Recite Significantly More
The claims are next considered to determine whether any additional element, or combination of additional elements, amounts to significantly more than the judicial exception.
The POS computing system, issuer computing system, acquirer computing system, processors, computer-readable storage medium, card network, and PIN debit network perform their respective ordinary data-processing, storage, and communication functions.
The ordered combination likewise merely implements the abstract payment-processing scheme electronically by: receiving payment information; determining routing requirements;
separating transaction information; transmitting transaction information through selected networks; matching corresponding information; and processing the financial transaction.
No additional element or ordered combination is recited with sufficient specificity to transform the abstract commercial transaction into a patent-eligible technological application.
Accordingly, independent claims 23, 33, and 40 do not recite an inventive concept sufficient to amount to significantly more than the judicial exception.
Dependent Claim 24
Claim 24 further recites queuing the authorization request message until the enhanced data message is received and processing the authorization request upon receipt of the enhanced data message.
The additional limitation merely delays processing one portion of transaction information until related transaction information becomes available.
This amounts to collecting related information before completing the underlying financial transaction and does not improve the operation of the computer or network itself.
Accordingly, claim 24 does not integrate the judicial exception into a practical application or provide significantly more.
Claim 25
Claim 25 recites generating an authorization response based on the matched authorization request and enhanced data and transmitting the response to the POS through the acquirer and card network. Generating and communicating approval or denial information is part of the underlying commercial transaction and merely completes the financial authorization process.
Accordingly, claim 25 does not add significantly more.
Claim 26
Claim 26 recites the card network relaying authorization request and response messages between the acquirer and issuer.
The limitation merely uses the card network as an information-transmission intermediary in performing the commercial transaction.
Accordingly, claim 26 does not provide significantly more.
Claim 27
Claim 27 recites a one-to-many or many-to-many PIN debit network configuration and use of the PIN debit network as an out-of-band communication network supporting the enhanced data message.
The recited network topology and out-of-band transmission merely provide a communication environment for conveying information used in the underlying financial transaction.
The claim does not recite a particular improvement to network architecture, network operation, bandwidth utilization, network security, latency, fault tolerance, or computer functionality.
Accordingly, claim 27 does not integrate the abstract idea into a practical application or amount to significantly more.
Claim 28
Claim 28 recites determining whether a user response is required based upon enhanced data and transmitting a response request to the POS through the PIN debit network.
Determining whether additional information should be requested from a customer and requesting such information constitutes further interaction in processing the commercial transaction.
The PIN debit network merely provides the communication mechanism.
Accordingly, claim 28 does not add significantly more.
Claim 29
Claim 29 recites receiving a user response and transmitting the response to the issuer through the PIN debit network. Receiving and forwarding information from the customer constitutes data gathering and communication performed in furtherance of the financial transaction. Accordingly, claim 29 does not provide significantly more.
Claim 30
Claim 30 recites transmitting the authorization request message and enhanced data message in parallel. Parallel transmission merely specifies the timing with which the respective transaction messages are communicated and does not, as claimed, improve the operation of the underlying communication networks.
Accordingly, claim 30 does not provide significantly more.
Claim 31
Claim 31 recites that the enhanced data message includes an identifier corresponding to a transaction identifier in the authorization request message.
Providing corresponding identifiers merely facilitates association of information relating to the same financial transaction. Accordingly, claim 31 does not integrate the abstract idea into a practical application or provide significantly more.
Claim 32
Claim 32 specifies that the enhanced data may include a loyalty account identifier, SKU data, promotional offer data, financial offer data, payment-card application data, or credit-line-increase data. These limitations merely specify particular commercial information to be processed during the transaction.
Loyalty information, product information, promotional offers, financial offers, credit applications, and credit-line information themselves concern commercial interactions.
Accordingly, claim 32 further limits the abstract commercial subject matter but does not provide significantly more.
Claims 34–39
Claims 34–39 recite substantially corresponding limitations to claims 24–29 in system form. For substantially the same reasons stated above, the recited queuing, authorization response generation, card-network relaying, out-of-band PIN debit communication, requesting user responses, and transmitting user responses merely implement the abstract financial transaction using generic computing and communication components.
Accordingly, claims 34–39 do not integrate the judicial exception into a practical application and do not amount to significantly more.
Claims 41–42
Claims 41 and 42 recite substantially corresponding limitations to claims 24 and 25 in computer-readable-medium form.
The storage of instructions on a non-transitory computer-readable medium for causing processors to perform the otherwise abstract transaction-processing operations does not alter the eligibility analysis.
Accordingly, claims 41 and 42 do not amount to significantly more than the judicial exception.
Claims 23–42 recite the abstract idea of processing and authorizing a financial transaction, including determining transaction-routing requirements, routing related transaction information through different financial networks, associating the separately transmitted information, obtaining additional transaction information where necessary, and generating an authorization result.
The foregoing constitutes a certain method of organizing human activity, particularly a commercial interaction/fundamental economic practice involving payment processing.
The additional POS computing system, acquirer computing system, issuer computing system, card network, PIN debit network, processors, and computer-readable media merely implement the abstract commercial process using computer and network technology as tools.
These claims do not recite a specific improvement to computer functionality or payment-network technology, do not integrate the judicial exception into a practical application, and do not recite additional elements that amount to significantly more than the judicial exception.
Therefore, claims 23–42 are rejected under 35 U.S.C. §101 as being directed to a judicial exception without significantly more.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 23–42 are rejected under 35 U.S.C. 103 as being unpatentable over US 2013/0091057 A1 (“Tomchek”) in view of Hirka et al. (US 2013/0304643 A1, hereinafter “Hirka”), and further in view of US 2013/0232068 A1 (“Leyva”).
With respect to claim 23, Tomchek teaches a computer-implemented method comprising:
receiving payment vehicle data associated with a payment vehicle tendered by a user; Tomchek teaches processing a payment transaction initiated by a cardholder with a merchant using an enhanced payment card, receiving an authorization request including a card identifier associated with the card, and identifying the transaction based upon the card identifier (¶¶[0024]-[0026]; claims 30, 34);
determining whether the transaction includes enhanced data; Tomchek teaches identifying a transaction as involving an enhanced payment card based upon comparison of a card identifier, adding a product code identifying the enhanced transaction, and obtaining an addendum file containing enhanced transaction data (¶¶[0024]-[0026]; claims 30-35);
providing an authorization request message; Tomchek teaches receiving and transmitting an authorization request associated with the payment transaction, including the card identifier and product code (¶¶[0025]-[0026]; claims 30, 35);
providing enhanced transaction data separately from the authorization request; Tomchek teaches an addendum file containing enhanced transaction data, including goods information, financing terms, promotion codes and line-item SKU data, which is communicated separately in connection with the transaction (¶¶[0024]-[0026]; claims 31-33);
transmitting the authorization request to an issuer through the payment-card processing infrastructure; Tomchek teaches merchant/acquirer/interchange/issuer processing of the authorization request (¶¶[0025]-[0026]); and
transmitting enhanced transaction data to the issuer; Tomchek teaches transmitting the clearing message/addendum containing enhanced transaction data to the issuer for application of promotional programs, financing programs and other transaction processing (¶¶[0024]-[0026]; claims 31-33).
Tomchek does not expressly disclose: determining that the enhanced data requires alternate routing; transmitting the authorization request through an acquirer/card-network path while transmitting enhanced data through a PIN debit network; using the PIN debit network as the alternate path; issuer-side matching of the separately transmitted authorization and enhanced-data messages; or using corresponding/common transaction information to associate the messages.
Hirka teaches a financial-processing network capable of accessing multiple accounts associated with a payment card and using additional transaction information to determine the appropriate account and routing path.
Hirka teaches transaction information originating at a POS and traversing merchant/acquirer/network/issuer processing components (¶¶[0020]-[0024], [0031]-[0032]).
Hirka further teaches alternate transaction routes and dynamically selecting among financial-processing routes based upon transaction/account information (¶¶[0032]-[0034]).
in particular, Hirka teaches that selection of a credit account ordinarily results in routing through a credit interchange, whereas selection of a debit account results in routing through a debit network (¶[0034]). Thus, Hirka teaches using different existing financial-network paths according to transaction information.
Leyva expressly teaches the missing two-message architecture.
Leyva teaches receiving purchase information associated with a transaction, identifying Leyva data, creating a pseudo authorization message containing enhanced data, and separately creating an ordinary authorization request (¶¶[0006]-[0007], [0028]-[0035]).
The ordinary authorization request is transmitted from the merchant toward the issuer through gateway/vendor/processor components, while the pseudo authorization message carrying Leyva information travels to the issuer through a different path that bypasses those components (¶¶[0028]-[0035], Figs. 2-3).
Leyva further teaches that the issuer matches the pseudo authorization message with a corresponding authorization request and stores the pseudo authorization message in an Leyva queue (¶[0035]).
The issuer compares transaction-related fields including time received, merchant, transaction account number and transaction amount to determine whether the two messages correspond to the same transaction (¶¶[0044]-[0046], Fig. 5).
The issuer thereafter merges the authorization request and pseudo authorization message into an enhanced authorization message and makes an authorization determination using the combined information (¶¶[0039]-[0041], [0046]-[0047]).
Thus, Leyva expressly supplies the claimed concept of separately transmitting ordinary authorization information and enhanced information and subsequently associating those separately received messages at the issuer.
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify Tomchek's enhanced-payment transaction architecture according to Hirka and Leyva.
Tomchek already recognizes the desirability of supplying enhanced transaction information in addition to ordinary authorization information. Hirka teaches that existing financial-processing systems provide different transaction-routing paths, including conventional credit-interchange and debit-network routing. Leyva expressly teaches the benefit of transmitting enhanced transaction information separately from the ordinary authorization request over a different path and thereafter correlating the two communications at the issuer.
A person of ordinary skill therefore would have been motivated to transmit Tomchek's conventional authorization information through its ordinary card-network route while transmitting Tomchek's enhanced transaction information over Hirka's available debit-network route according to Leyva's separate-path technique. Doing so would permit enhanced information to reach the issuer without requiring the conventional authorization path to carry information it was not configured to process, while preserving conventional authorization processing.
Leyva itself recognizes this problem by explaining that conventional merchant infrastructure may be incapable of receiving, processing, or transmitting Leyva data and therefore routes the enhanced data separately.
Once the separately transmitted messages arrive at the issuer, Leyva expressly teaches matching corresponding messages and merging their information before making the authorization decision. The combination therefore represents use of known alternate financial-network routing and separate enhanced-data communication techniques to improve a known enhanced-payment system according to their established functions, yielding the predictable result of delivering both conventional and enhanced transaction information to the issuer for combined processing. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007). Accordingly, claim 23 is unpatentable over Tomchek in view of Hirka and Leyva.
Claim 24 further requires: queuing, by the issuer computing system, the authorization request message until the enhanced data message is received; and
processing the authorization request message upon receiving the enhanced data message.
Tomchek does not expressly disclose this limitation.
Hirka is not relied upon for this limitation.
Leyva expressly teaches an issuer-side enhanced authorization queue. The issuer receives a pseudo authorization message, stores it in the Leyva queue, receives an authorization request, polls the Leyva queue for the corresponding pseudo authorization message, locates the corresponding message, merges the authorization request and pseudo authorization message, and thereafter performs the authorization decision (¶¶[0035]-[0041], Fig. 4).
Leyva therefore expressly teaches holding one component of the transaction pending availability and matching of its corresponding separately received message before combined processing.
Although Leyva expressly queues the enhanced/pseudo message rather than necessarily the authorization request itself, reversing which of two asynchronously arriving related messages is temporarily buffered would have been an obvious implementation choice dependent upon which message arrives first. The predictable purpose remains synchronization of the separately received transaction messages before combined processing.
Accordingly, claim 24 is unpatentable over Tomchek in view of Hirka and Leyva.
Claim 25 further requires: generating an authorization response message based on the matched authorization request message and enhanced data message; and
transmitting the authorization response to the POS through the acquirer and card network.
Tomchek teaches generation and return of an authorization response from the issuer through the conventional payment-card infrastructure (¶¶[0025]-[0026]; claims 30, 35-36).
Leyva more particularly teaches merging the matched authorization request and pseudo authorization message, using the resulting Leyva message to determine whether to approve or deny the transaction, and transmitting an authorization response indicating approval or denial back toward the merchant (¶¶[0039]-[0041], [0046]-[0047]). Accordingly, claim 25 is unpatentable.
Claim 26 Tomchek teaches conventional merchant/acquirer/interchange/issuer authorization routing and return of the authorization response (¶¶[0025]-[0026]).
Hirka similarly teaches POS/merchant/acquirer/network/issuer processing, including merchant acquirer 415, association/network 420 and issuer/member processor 425 (¶¶[0031]-[0032]).
Leyva further teaches authorization requests passing through gateway 140, vendor 150 and processor 160 to issuer 180, with the authorization response returned through corresponding payment-processing infrastructure (¶¶[0028]-[0031], [0041]).
Accordingly, the references teach relaying authorization requests and responses between the merchant/acquirer side and issuer through the conventional payment network, and claim 26 is unpatentable.
Claim 27 further requires a PIN debit network having one-to-many or many-to-many configurations and operating as an out-of-band network for the enhanced-data message.
Tomchek does not expressly disclose this limitation.
Hirka teaches distinct credit and debit transaction-routing infrastructures and specifically teaches that selection of a credit account ordinarily results in routing through a credit interchange while selection of a debit account results in routing through a debit network (¶[0034]).
Leyva teaches the complementary concept of transmitting enhanced transaction information through a second path that bypasses the conventional merchant/gateway/vendor/processor authorization path (¶¶[0028], [0032]-[0035], Fig. 3).
It would have been obvious to use Hirka's known debit-network path as Leyva's second/out-of-band path for Tomchek's enhanced transaction data, thereby leaving the ordinary authorization request on the conventional card-network path.
The references do not expressly use the phrase “one-to-many or many-to-many” for the network configuration. However, Hirka's network architecture interconnecting POS, merchant, acquirer, network and multiple account/issuer processing resources renders such multi-endpoint financial-network implementation an obvious network configuration. Accordingly, claim 27 is unpatentable.
Claim 28 requires determining whether a user response is required based on enhanced data and transmitting a response request to the POS through the PIN debit network.
Tomchek teaches enhanced transaction data supporting promotional programs, financing programs and offers (¶¶[0024]-[0026]; claims 31-33).
Hirka teaches obtaining user input at the POS, including account selections, transaction selections and PIN information, and communicating that information through the financial-processing network (¶¶[0020]-[0024], [0043]).
Leyva teaches that the separately routed enhanced-data communication may contain additional information used by the issuer in determining transaction authorization and may include requests for additional services/information (¶¶[0048]-[0052]).
It would therefore have been obvious, where processing the enhanced information requires additional customer input, to request that input over the same bidirectional alternate communication infrastructure used for the enhanced-data exchange.
Accordingly, claim 28 is unpatentable.
With respect to Claim 29 Hirka teaches receiving user-selected transaction/account information and PIN information at the POS and transmitting that information downstream through the financial-processing infrastructure (¶¶[0020]-[0024], [0043]).
In view of Hirka's debit-network route and Leyva's separate enhanced-data communication path, it would have been obvious to return the requested user response through the same alternate/debit-network path. Accordingly, claim 29 is unpatentable.
Claim 30 requires the authorization request and enhanced-data message to be transmitted in parallel.
Leyva expressly describes two separate transaction paths: purchase/authorization information proceeds through the merchant authorization path while Leyva information proceeds through the second path toward the issuer (¶¶[0028]-[0035], Figs. 2-3).
Neither Tomchek nor Leyva requires completion of one transmission before commencement of the other. Given two independent communication paths carrying complementary information for the same transaction, it would have been obvious to transmit the messages concurrently to reduce overall authorization latency and permit both messages to become available at the issuer as soon as practicable. Accordingly, claim 30 is unpatentable.
Claim 31 requires the enhanced-data message to include an identifier corresponding to a transaction identifier in the authorization request.
Leyva expressly teaches that the pseudo authorization message may contain information also contained in the authorization request, including transaction account number and other transaction information (¶¶[0032]-[0033]).
The issuer matches the two messages by comparing corresponding fields, including time received, merchant, transaction account number and transaction amount (¶¶[0044]-[0046], Fig. 5).
Leyva further teaches Leyva data containing an information identifier (¶[0052]).
Thus, Leyva teaches corresponding identifying transaction information in separately transmitted messages for associating them with the same transaction. Using an expressly designated common transaction identifier instead of or in addition to the corresponding account/merchant/time/amount fields would have been an obvious implementation of Leyva's expressly disclosed message-correlation technique. Accordingly, claim 31 is unpatentable.
With respect to Claim 32 Tomchek expressly teaches enhanced transaction data comprising information describing goods, identifying characteristics of goods, financing terms, promotion codes and line-item SKU data (¶[0024]; claims 31-33).
Tomchek further teaches using the enhanced data to apply existing promotional and financing programs and to offer new promotional or financing programs to the cardholder (¶[0026]; claim 31).
Thus, Tomchek expressly teaches SKU data, promotional-offer information and financial-offer information and renders obvious closely related loyalty/account/application/credit information used to administer such payment-card programs.
Accordingly, claim 32 is unpatentable.
Claim 33 recites the system counterpart of claim 23. Tomchek teaches a computer-based enhanced-payment system having processors, storage and network communications for receiving authorization requests, identifying enhanced transactions, communicating enhanced data and processing authorization responses (¶¶[0024]-[0026]; claims 39-44).
Tomchek therefore teaches:
one or more processors and computer-readable storage; receiving payment vehicle information for a credit transaction; identifying an enhanced payment transaction;
providing an authorization request; providing enhanced transaction data separately from the authorization request; transmitting authorization information through conventional payment-processing infrastructure; and communicating enhanced transaction data to the issuer (¶¶[0024]-[0026]; claims 39-44).
Tomchek does not expressly teach the claimed card-network/PIN-debit-network split or issuer-side matching.
Hirka teaches dynamically selecting between conventional credit-interchange and debit-network routes according to transaction/account information (¶¶[0031]-[0034]).
Leyva teaches creating separate authorization and enhanced-data messages, transmitting them along separate paths to the issuer, matching the messages at the issuer, merging them and performing the authorization decision using their combined information (¶¶[0028]-[0041], [0044]-[0047], Figs. 2-5).
It would have been obvious to modify Tomchek's processor-based enhanced-payment system with Hirka's alternate credit/debit routing and Leyva's separate-path message processing for substantially the reasons stated with respect to claim 23.
All three references address computerized processing of payment transactions between merchant/POS environments and financial institutions. Tomchek teaches ordinary authorization plus enhanced transaction information; Hirka teaches existing alternative financial-network paths; and Leyva teaches separating ordinary and enhanced information into different communications, routing them separately, correlating them at the issuer and using the combined information for authorization.
Combining the teachings would predictably improve Tomchek by permitting enhanced information to bypass limitations of the conventional authorization path while preserving conventional card-network authorization processing. Each known component would perform its established function, and the combination would yield the predictable result of a dual-path enhanced-payment transaction system. KSR. Accordingly, claim 33 is unpatentable over Tomchek in view of Hirka and Leyva.
With respect to Claim 34 Leyva expressly teaches issuer-side storage of a separately received transaction message in an enhanced authorization queue, polling the queue for the corresponding message, matching the messages, merging them and thereafter performing the authorization determination (¶¶[0035]-[0041], Fig. 4). As explained for claim 24, buffering whichever corresponding message arrives first until the other becomes available is an obvious synchronization implementation. Accordingly, claim 34 is unpatentable.
With respect to Claim 35 Tomchek teaches issuer authorization responses (¶¶[0025]-[0026]). Leyva expressly teaches determining authorization from the merged authorization/enhanced message and returning an approval/denial response through the conventional processing infrastructure (¶¶[0039]-[0041], [0046]-[0047]).
Accordingly, claim 35 is unpatentable.
With respect to Claim 36 Tomchek and Hirka teach conventional acquirer/card-network/issuer relaying of transaction authorization information (Tomchek ¶¶[0025]-[0026]; Hirka ¶¶[0031]-[0032]).
Accordingly, claim 36 is unpatentable.
With respect to Claim 37 Hirka teaches debit-network routing as an alternative to credit-interchange routing (¶[0034]), while Leyva teaches separately routing enhanced information over a second path bypassing the ordinary authorization-processing path (¶¶[0028], [0032]-[0035]).
For the reasons stated for claim 27, use of Hirka's debit network as the second/out-of-band enhanced-data path would have been obvious. Accordingly, claim 37 is unpatentable.
With respect to Claim 38 Tomchek teaches enhanced transaction information supporting promotional and financial programs; Hirka teaches obtaining customer selections/PIN information at the POS; and Leyva teaches separate issuer communications containing additional transaction information and service requests (Tomchek ¶¶[0024]-[0026]; Hirka ¶¶[0020]-[0024], [0043]; Leyva ¶¶[0048]-[0052]). Accordingly, requesting additional customer input required by the enhanced-data processing would have been obvious, and claim 38 is unpatentable.
With respect to Claim 39 Hirka teaches POS receipt and downstream communication of customer account-selection and PIN information (¶¶[0020]-[0024], [0043]). Returning requested user information through the alternate/debit path used for the enhanced-data interaction would have been an obvious use of that communication channel.
Accordingly, claim 39 is unpatentable.
With respect to Claim 40 that recites the computer-readable-medium counterpart of claim 23.
Tomchek expressly claims computer-readable storage media containing instructions implementing its enhanced-payment-card transaction functionality (claims 45-49) and teaches computerized implementation of the transaction-processing system.
Leyva likewise expressly describes computer systems having processors, memory, storage media and network interfaces for implementing the disclosed separate-path authorization processes (¶¶[0068]-[0074], Fig. 6).
Tomchek teaches the underlying authorization and enhanced-data operations; Hirka teaches credit-interchange/debit-network routing alternatives; and Leyva teaches separate authorization/enhanced-data messages, separate communication paths, issuer-side matching, merging and authorization based upon the combined information.
It would have been obvious to embody the combined Tomchek/Hirka/Leyva transaction-processing functionality as processor-executable instructions stored on non-transitory computer-readable media because each reference implements its payment-processing operations through programmed computer systems.
A person of ordinary skill would have been motivated to program Tomchek's enhanced-payment system to employ Hirka's available debit-network route for separately communicated enhanced information according to Leyva's separate-path architecture. The modification would predictably permit enhanced information to reach the issuer independently of the conventional authorization path and then be correlated with the authorization request for combined processing.
This constitutes applying known routing and message-correlation techniques to a known computerized enhanced-payment system according to their established functions and would have yielded predictable results. KSR.
Accordingly, claim 40 is unpatentable over Tomchek in view of Hirka and Leyva.
With respect to Claim 41 Leyva expressly teaches an enhanced authorization queue, storage of one separately received transaction message, polling for the corresponding authorization message, matching, merging and subsequent authorization processing (¶¶[0035]-[0041], Fig. 4).
For the reasons stated regarding claims 24 and 34, buffering the first-arriving related message pending receipt of the second is an obvious implementation of the disclosed asynchronous message-correlation system. Accordingly, claim 41 is unpatentable.
With respect to Claim 42 Tomchek teaches generation and return of an issuer authorization response through the payment-processing infrastructure (¶¶[0025]-[0026]).
Leyva more specifically teaches matching the authorization request and enhanced pseudo authorization message, merging the messages into enhanced authorization Leyva message, making the authorization determination using the combined information, and transmitting an authorization response indicating approval or denial (¶¶[0039]-[0041], [0044]-[0047], Figs. 4-5).
Accordingly, claim 42 is unpatentable.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROKIB MASUD whose telephone number is (571)270-5390. The examiner can normally be reached Mon-Fri 8:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Fahd Obeid can be reached at 571-270-3324. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ROKIB MASUD/Primary Examiner, Art Unit 3627
