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 .
Status of Claims
This office action is in response to the claim amendments filed on December 30, 2025.
Claims 1-20 are pending.
Claims 1-20 have been examined.
Response to Arguments
With respect to Claim Rejections - 35 USC § 103
Regarding independent claims 1 and 11: Applicant is of the opinion prior art fails to disclose, see Applicant’s arguments pages 14-16.
Applicant argues: Hosp does not disclose delimiter operands with the server-side operational semantics recited, nor does it disclose integrating item-level scans by a second mobile device or signaling a merchant premises' security system upon server confirmation.
Applicant’s arguments with respect to independent claims 1 and 11 have been considered. The Examiner, however, respectfully disagrees.
Firstly, Applicant failed to argue specific positively claim limitations. At best, Applicant states “Hosp does not disclose delimiter operands with the server-side operational semantics recited, nor does it disclose integrating item-level scans by a second mobile device or signaling a merchant premises' security system upon server confirmation.” Additionally, Applicant should submit an argument under the heading “Remarks” pointing out disagreements with the examiner’s contentions. Applicant must also discuss the references applied against the claims, explaining how the claims avoid the references or distinguish from them.
Additionally, with respect to amended claim languages, these limitations do not limit the functionality of the claimed backend payment processing computer server because these limitations are outside the scope of the claimed backend payment processing computer server. Furthermore, these limitations fall outside the scope of the claimed invention because it recites operation not performed by the claimed backend payment processing computer server. Therefore, these limitations have limited patentable weight since the steps/functions are not positively tied with any structure element of the claimed backend payment processing computer server. And with respect to the method claim 11, these limitations are not positively recited functional step and hence receive limited patentable weight. See 103 rejections below for detail explanations. Accordingly, this ground of rejection is maintained.
Furthermore, Applicant’s arguments with respect to claims 1-20 have been considered but are moot in view of new grounds of rejection initiated by applicant’s amendment to the claims.
With respect to Claim Rejections - 35 USC § 101
Applicant argues, see Applicant’s arguments pages 10-14.
The Examiner, however, respectfully disagrees. As a preliminary matter, the Examiner follows the 2019 Patent Eligibility Guidance (“2019 PEG”) which is a synthesis of the case law of Alice and its progeny. Additionally, the reasoning for this rejection is the same as was laid out in the Office Action Non-Final Rejection, dated 07/31/2025 (hereinafter, “Office Action”). Furthermore, while Applicant has amended the claim to recite additional subject matter, for example, the amended claim limitations recite, the tokenized transaction data set generated by the first mobile communication device; using the network communication system, receive, from the second mobile communication device or the point-of-sale terminal, item purchase data of one or more items for purchase, the item purchase data generated by the second mobile communication device by scanning the one or more items for purchase using a scanner or an optical or wireless reading device of the second mobile communication device; and point-of-sale terminal, wherein the at least one of the second mobile communication device and the point-of-sale terminal processes a transaction upon receiving the transaction confirmation data set, and wherein after receipt of the confirmation data set, the second mobile communication device wirelessly transmits the transaction confirmation data set to an automated security system in the merchant premises to allow a purchaser possessing the second mobile device to leave the merchant premises with the one or more items for purchase without setting off alarms of the automated security system, further describe the abstract idea of processing electronic transactions and categorized as a part of organizing human activity.
Applicant further argues that, [u]nder Step 2A Prong Two of the USPTO Subject Matter Eligibility Test, Applicant submits that the amended claim 1 constitutes patent eligible subject matter as the claimed features practically integrate computer implemented logical processes for payment adjudication into a practical application (i.e., a secure cashier-less checkout data message interaction between specially configured devices) that provides an improvement to payment flows and the integration of point-of-sale and security devices. See Applicant’s arguments pages 12-13.
The Examiner however, respectfully disagrees, the claims also fail to recite a practical application of the abstract ideas. According to the 2019 PEG, the additional claim elements are considered when determining whether the claim recites a practical application, such as a technological improvement, of the abstract idea. However, the amendments fail to introduce any such additional elements. Therefore, this analysis is the same as the analysis laid out in the Office Action.
The claims also fail to recite significantly more than the abstract idea. According to the 2019 PEG, the additional elements, when considered individually and as a combination, are analyzed to determine whether the claims recite significantly more than the abstract idea. However, the amended claims fail to recite any new additional elements. As noted in the Office Action, the additional elements serve to implement the abstract idea in a computing environment.
Furthermore, the amended claims recite, the tokenized transaction data set generated by the first mobile communication device; using the network communication system, receive, from the second mobile communication device or the point-of-sale terminal, item purchase data of one or more items for purchase, the item purchase data generated by the second mobile communication device by scanning the one or more items for purchase using a scanner or an optical or wireless reading device of the second mobile communication device; and point-of-sale terminal, wherein the at least one of the second mobile communication device and the point-of-sale terminal processes a transaction upon receiving the transaction confirmation data set, and wherein after receipt of the confirmation data set, the second mobile communication device wirelessly transmits the transaction confirmation data set to an automated security system in the merchant premises to allow a purchaser possessing the second mobile device to leave the merchant premises with the one or more items for purchase without setting off alarms of the automated security system. These limitations do not limit the functionality of the claimed backend payment processing computer server because these limitations are outside the scope of the claimed backend payment processing computer server. Furthermore, these limitations fall outside the scope of the claimed invention because it recites operation not performed by the claimed backend payment processing computer server. Therefore, these limitations have limited patentable weight since the steps/functions are not positively tied with any structure element of the claimed backend payment processing computer server. And with respect to the method claim 11, these limitations are not positively recited functional step and hence receive limited patentable weight. Hence, it does not appear that the amended claim limitations, would result in any improvement to the recited technology. Therefore, the amended claim limitations do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. See detail rejection below. Accordingly, this ground of rejection is maintained.
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 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-10 are directed to a system comprising at least one processor, and claims 11-20 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
The claims recite an abstract idea of processing electronic transactions. Specifically, the claims recite:
via the network communication system, receive from a second mobile communication …, a tokenized transaction data set comprising data representing an authorized transaction value, a delimiter operand for limiting the tokenized transaction data set, a location reference denoting an external memory location where transaction payment data is stored, a merchant identifier, and at least one secure identifier associated with a transaction payment account, the tokenized transaction data set generated by the first mobile communication …;
using the tokenized transaction data set for adjudication of a payment transaction between the second mobile communication … and the point-of- sale terminal located at a merchant premises associated with the merchant identifier, wherein the delimiter operand is configured to control the adjudication of the payment transaction by the backend payment processing computer server, the delimiter operand interpretable as at least one of single, multi-use, elapsed time, transaction limit, or date use delimiters;
using the network communication system, receive from the point-of-sale terminal associated with the merchant identifier, a merchant transaction data set comprising data representing at least:
a transaction payment data securely obtained from the external memory location associated with the location reference; and
the merchant identifier associated with the point-of-sale terminal;
using the network communication system, receive, from the second mobile communication … or the point-of-sale terminal, item purchase data of one or more items for purchase, the item purchase data generated by the second mobile communication … by scanning the one or more items for purchase using a scanner or an optical or wireless reading … of the second mobile communication …;
using at least one of the tokenized transaction data set, the item purchase data, and the merchant transaction data set, authorize completion of the payment transaction and generate a transaction confirmation data set upon verifying that: the payment transaction satisfies limitation logic in the delimiter operand; and
using the network communication system, route the transaction confirmation data set to at least one of the second mobile communication … and the point-of-sale terminal, wherein the at least one of the second mobile communication … and the point-of-sale terminal processes a transaction upon receiving the transaction confirmation data set, and wherein after receipt of the confirmation data set, the second mobile communication … wirelessly transmits the transaction confirmation data set to an automated security system in the merchant premises to allow a purchaser possessing the second mobile … to leave the merchant premises with the one or more items for purchase without setting off alarms of the automated security system, which is grouped within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP 2106.04(a)) because it describes a process for carrying out a commercial interaction between parties that involves communicating data needed to complete a transaction to the parties. Accordingly, the claims recite an abstract idea (See MPEP 2106.04).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106.04(a or d)), the additional element(s) of the claim(s) such as at least one processor merely use(s) a computer as a tool to perform an abstract idea. Specifically, the at least one processor perform(s) the steps or functions of:
via the network communication system, receive from a second mobile communication device, a tokenized transaction data set comprising data representing an authorized transaction value, a delimiter operand for limiting the tokenized transaction data set, a location reference denoting an external memory location where transaction payment data is stored, a merchant identifier, and at least one secure identifier associated with a transaction payment account, the tokenized transaction data set generated by the first mobile communication device;
using the tokenized transaction data set for adjudication of a payment transaction between the second mobile communication device and the point-of- sale terminal located at a merchant premises associated with the merchant identifier, wherein the delimiter operand is configured to control the adjudication of the payment transaction by the backend payment processing computer server, the delimiter operand interpretable as at least one of single, multi-use, elapsed time, transaction limit, or date use delimiters;
using the network communication system, receive from the point-of-sale terminal associated with the merchant identifier, a merchant transaction data set comprising data representing at least:
a transaction payment data securely obtained from the external memory location associated with the location reference; and
the merchant identifier associated with the point-of-sale terminal;
using the network communication system, receive, from the second mobile communication device or the point-of-sale terminal, item purchase data of one or more items for purchase, the item purchase data generated by the second mobile communication device by scanning the one or more items for purchase using a scanner or an optical or wireless reading device of the second mobile communication device;
using at least one of the tokenized transaction data set, the item purchase data, and the merchant transaction data set, authorize completion of the payment transaction and generate a transaction confirmation data set upon verifying that: the payment transaction satisfies limitation logic in the delimiter operand; and
using the network communication system, route the transaction confirmation data set to at least one of the second mobile communication device and the point-of-sale terminal, wherein the at least one of the second mobile communication device and the point-of-sale terminal processes a transaction upon receiving the transaction confirmation data set, and wherein after receipt of the confirmation data set, the second mobile communication device wirelessly transmits the transaction confirmation data set to an automated security system in the merchant premises to allow a purchaser possessing the second mobile device to leave the merchant premises with the one or more items for purchase without setting off alarms of the automated security system.
The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (See MPEP 2106.05(a)), the claims do not apply the abstract idea with, or by use of, a particular machine (See MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (See MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106.05), the additional element(s) of using at least one processor to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of processing electronic transactions. As discussed above, taking the claim elements separately, the at least one processor perform(s) the steps or functions of:
via the network communication system, receive from a second mobile communication device, a tokenized transaction data set comprising data representing an authorized transaction value, a delimiter operand for limiting the tokenized transaction data set, a location reference denoting an external memory location where transaction payment data is stored, a merchant identifier, and at least one secure identifier associated with a transaction payment account, the tokenized transaction data set generated by the first mobile communication device;
using the tokenized transaction data set for adjudication of a payment transaction between the second mobile communication device and the point-of- sale terminal located at a merchant premises associated with the merchant identifier, wherein the delimiter operand is configured to control the adjudication of the payment transaction by the backend payment processing computer server, the delimiter operand interpretable as at least one of single, multi-use, elapsed time, transaction limit, or date use delimiters;
using the network communication system, receive from the point-of-sale terminal associated with the merchant identifier, a merchant transaction data set comprising data representing at least:
a transaction payment data securely obtained from the external memory location associated with the location reference; and
the merchant identifier associated with the point-of-sale terminal;
using the network communication system, receive, from the second mobile communication device or the point-of-sale terminal, item purchase data of one or more items for purchase, the item purchase data generated by the second mobile communication device by scanning the one or more items for purchase using a scanner or an optical or wireless reading device of the second mobile communication device;
using at least one of the tokenized transaction data set, the item purchase data, and the merchant transaction data set, authorize completion of the payment transaction and generate a transaction confirmation data set upon verifying that: the payment transaction satisfies limitation logic in the delimiter operand; and
using the network communication system, route the transaction confirmation data set to at least one of the second mobile communication device and the point-of-sale terminal, wherein the at least one of the second mobile communication device and the point-of-sale terminal processes a transaction upon receiving the transaction confirmation data set, and wherein after receipt of the confirmation data set, the second mobile communication device wirelessly transmits the transaction confirmation data set to an automated security system in the merchant premises to allow a purchaser possessing the second mobile device to leave the merchant premises with the one or more items for purchase without setting off alarms of the automated security system.
These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of processing electronic transactions. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Regarding dependent claims:
Claims 2 and 12 recite: The backend payment processing computer server of claim 1, wherein the at least one processor is configured to cause the computer server to: upon receipt from the point-of-sale terminal of the merchant transaction data set: generate a merchant transaction notification data set; and route the merchant transaction notification data set to the point-of-sale terminal associated with the merchant identifier, the merchant transaction notification data set comprising data representing at least: an identifier associated with the first mobile communication device.
Claims 3 and 13 recite: The backend payment processing computer server of claim 1, wherein the delimiter operand is implemented as a single-use delimiter encoded in one or more EMV-compliant data elements, the backend payment processing computer server authorizing only a first authorization attempt associated with the single-use delimiter.
Claims 4 and 14 recite: The backend payment processing computer server of claim 1, wherein the delimiter operand is implemented as a value-cap delimiter comprising a remaining-amount field encoded in one or more EMV-compliant data elements, the backend payment processing computer server decrementing the remaining-amount field by the authorized transaction value and rejecting authorization when the authorized transaction value exceeds the remaining-amount field.
Claims 5 and 15 recite: The backend payment processing computer server of claim 1, wherein the tokenized transaction data set comprises data interpretable as instructions associated with the completion of the payment transaction.
Claims 6 and 16 recite: The backend payment processing computer server of claim 1, wherein the at least one processor is configured to cause the backend payment processing computer server to: prior to generating the transaction confirmation data set, use the network communication system to route the transaction confirmation data set to a second mobile communication device, the transaction confirmation data set comprising a request for user validation of the payment transaction.
Claims 7 and 17 recite: The backend payment processing computer server of claim 6, wherein the at least one processor is configured to cause the backend payment processing computer server to: authorize the completion of the payment transaction upon receipt from the second mobile communication device of a transaction validation data set in response to the request for user validation.
Claims 8 and 18 recite: The backend payment processing computer server of claim 1, wherein the at least one processor is configured to cause the backend payment processing computer server to: prior to generating the transaction confirmation data set, upon determining that the authorized transaction value exceeds a predefined threshold, use the network communication system to route the transaction confirmation data set to the second mobile communication device, the transaction confirmation data set comprising a request for user validation of the payment transaction.
Claims 9 and 19 recite: The backend payment processing computer server of claim 8, wherein the at least one processor is configured to cause the backend payment processing computer server to: authorizing completion of the payment transaction upon receipt from the second mobile communication device of a transaction validation data set in response to the request for user validation.
Claims 10 and 20 recite: The backend payment processing computer server of claim 1, wherein the at least one processor is configured to cause the backend payment processing computer server to: prior to generating the transaction confirmation data set, use the network communication system to route to the first mobile communication device, a request for user verification; and authorize the completion of the payment transaction upon receipt from the first mobile communication device of a correct user verification in response to the request for user verification.
Dependent claims 2-10 and 12-20 further describe the abstract idea of processing electronic transactions. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 4 and 14 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 4, recites, “wherein the delimiter operand is implemented as a value-cap delimiter comprising a remaining-amount field encoded in one or more EMV-compliant data elements, the backend payment processing computer server decrementing the remaining-amount field by the authorized transaction value and rejecting authorization when the authorized transaction value exceeds the remaining-amount field” however, the originally-filed specification is silent with respect to any algorithm or flow chart to describe how the delimiter operand is implemented as a value-cap delimiter comprising a remaining-amount field encoded in one or more EMV-compliant data elements is performed. The originally-filed specification discloses, see paragraph [0058]: In some embodiments, the generation and/or provision of unique payment information, including for example limited or unlimited payment authorizations, to a mobile or other communication device may be performed for each transaction. So, for example, payment information may be unique for each transaction process, and accordingly may be valid or otherwise authorized for only one transaction. Alternatively, such authorizations and information may be provided with the suitable flags or other delimiters identifying them as good for use in multiple transactions. For example, a pre-authorized payment token may be provided with a purchase value or cap, the token being good for multiple transactions, with the value or cap being decremented accordingly upon completion of each transaction, until the value is fully or sufficiently exhausted (e.g., until the value of the token falls to zero or beneath a minimum pre-defined threshold). However, the originally-filed specification fails to disclose how the delimiter operand is implemented as a value-cap delimiter comprising a remaining-amount field encoded in one or more EMV-compliant data elements is performed. For these reasons, the originally-filed specification fails to adequately describe claims 4 and 14.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5, 11-13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Kevin Laracey (US 20140149293 A1, “Laracey”) in view of HOSP et al. (US 20150073999 A1, “HOSP”).
Regarding claims 1 and 11: Laracey discloses: A backend payment processing computer server configured for transaction adjudication, the backend payment processing computer server comprising (see Figs. 1 and 5 and related text):
a network communication system for electronic communications between the backend payment processing computer server with a first mobile communication device and a point-of- sale terminal (see Figs. 1 and 5 and related text); and
at least one processor (see paragraphs [0024]-[0026] and [0095]-[0097] and Figs. 1 and 5);
the at least one processor configured to cause the backend payment processing computer server to (see paragraphs [0024]-[0026] and [0095]-[0097] and Figs. 1 and 5):
via the network communication system, receive from a second mobile communication device, a tokenized transaction data set (Laracey [0033]: The token is used, as will be described further herein, to link messages from the mobile device 102 and the merchant 108, and the transaction management system 130, so that transactions pursuant to the present invention may be accomplished. After capture of the token, the mobile device 102 transmits the token to the transaction management system 130 in a customer transaction lookup request message (over communication path 114)) comprising data representing [an authorized transaction value, a delimiter operand (e.g., one or more rules based on any number of factors) for limiting the tokenized transaction data set, a merchant identifier, and at least one secure identifier associated with a transaction payment account] and [a location reference denoting an external memory location where transaction payment data is stored] (Laracey [0021]: the token may be used to determine the user's location on its own or in conjunction with geolocation capabilities on the user's device…the point of interaction executing transactions on behalf of the user, such as automatically performing a pre-authorization on a payment instrument for a predetermined amount so that a gas station pump (point of interaction) is ready for them to begin pumping gas, or to prompt a bartender to automatically begin preparing a particular drink or have kitchen staff begin preparing the user's favorite meal; [0059]: In some embodiments, no values from the token itself may be needed to determine the appropriate transaction management system 130 to use. For example, the mobile device 102 or merchant 108 may follow one or more rules based on any number of factors, such as the time of day, day of week, current transaction volume at a point of interaction, dollar amount of a purchase, or any other factor to determine which transaction management system 130 to use; [0039]: the mobile device 102 never stores, sends or receives actual payment credentials. Instead, the mobile device 102 stores or has access to a proxy associated with actual payment credentials, and the proxy is used to identify a desired payment account for use in a given transaction. The proxy is transmitted to the transaction management system 130 (or, in some embodiments, to a wallet issuer) in a customer payment authorization request message and the transaction management system 130 (or, in some embodiments, to a wallet issuer) uses the proxy to lookup or identify the actual payment credentials associated with the selected account), (see paragraphs [0033]-[0034], [0039], [0021] and [0059] and Fig. 1);
Examiner’s Note: with respect to the claim language, “a tokenized transaction data set comprising data representing an …, and at least one secure identifier associated with a transaction payment account” this is nonfunctional descriptive material as it only describes data values, while the data values are not used to perform any of the recited method steps/functions. Therefore, it has been held the nonfunctional descriptive material will not distinguish the invention from the prior art in term of patentability. See MPEP 2111.05 and MPEP 2106.01.
Furthermore, Examiner’s Note: with respect to amended claim language, “the tokenized transaction data set generated by the first mobile communication device”. This limitation does not limit the functionality of the claimed backend payment processing computer server because this limitation is outside the scope of the claimed backend payment processing computer server. Furthermore, this limitation falls outside the scope of the claimed invention because it recites operation not performed by the claimed backend payment processing computer server. Therefore, this limitation has limited patentable weight since step of “tokenized transaction data set generated by the first mobile communication device” is not positively tied with any structure element of the claimed backend payment processing computer server. And with respect to the method claim 11, this limitation is not positively recited functional step and hence receive limited patentable weight.
using the tokenized transaction data set for adjudication of a payment transaction between the second mobile communication device and the point-of- sale terminal located at a merchant premises associated with the merchant identifier, wherein the delimiter operand is configured to control the adjudication of the payment transaction by the backend payment processing computer server, the delimiter operand interpretable as at least one of single, multi-use, elapsed time, transaction limit, or date use delimiters (Laracey [0033]: The token is used, as will be described further herein, to link messages from the mobile device 102 and the merchant 108, and the transaction management system 130, so that transactions pursuant to the present invention may be accomplished; [0038]: Once the payment authorization message from the customer's mobile device is received, the transaction management system 130 (or, in some embodiments, a wallet issuer or other entity as will be described further below) creates an authorization approval request message for transmission through one or more payment processing networks (not shown in FIG. 1) to cause the authorization, clearing and settlement of funds for the transaction. This request message includes information from the merchant payment authorization request such as the amount of the transaction, or at least a pointer or reference to the relevant merchant payment authorization request (received from the merchant 108) and a payment account identifier identifying the payment account selected by the customer and previously stored in the transaction management system 130 (and identified by a proxy or other identifier received from the mobile device); [0059]: In some embodiments, no values from the token itself may be needed to determine the appropriate transaction management system 130 to use. For example, the mobile device 102 or merchant 108 may follow one or more rules based on any number of factors, such as the time of day, day of week, current transaction volume at a point of interaction, dollar amount of a purchase, or any other factor to determine which transaction management system 130 to use), (see paragraphs [0033], [0038] and [0059] and Fig. 1);
using the network communication system, receive from the point-of-sale terminal associated with the merchant identifier, a merchant transaction data set comprising data representing at least (Laracey [0075]: the merchant 208 transmits a merchant payment authorization request message to the transaction management system 230 over a network 220;), (see paragraphs [0038] and Fig. 1):
a transaction payment data securely obtained from the external memory location associated with the location reference (Laracey [0038]: This request message includes information from the merchant payment authorization request such as the amount of the transaction, or at least a pointer or reference to the relevant merchant payment authorization request (received from the merchant 108) and a payment account identifier identifying the payment account selected by the customer and previously stored in the transaction management system 130 (and identified by a proxy or other identifier received from the mobile device)), (see paragraphs [0038] and Fig. 1); and
the merchant identifier associated with the point-of-sale terminal (see paragraph [0038] and [0067]);
using the network communication system, receive, from [the point-of-sale terminal (e.g., a networked point of sale system), item purchase data of one or more items for purchase (see paragraphs [0028]);
Examiner’s Note: with respect to amended claim language, “the item purchase data generated by the second mobile communication device by scanning the one or more items for purchase using a scanner or an optical or wireless reading device of the second mobile communication device”. This limitation does not limit the functionality of the claimed backend payment processing computer server because this limitation is outside the scope of the claimed backend payment processing computer server. Furthermore, this limitation falls outside the scope of the claimed invention because it recites operation not performed by the claimed backend payment processing computer server. Therefore, this limitation has limited patentable weight since step of “the item purchase data generated by the second mobile communication device by scanning the one or more items for purchase using a scanner or an optical or wireless reading device of the second mobile communication device” is not positively tied with any structure element of the claimed backend payment processing computer server. And with respect to the method claim 11, this limitation is not positively recited functional step and hence receive limited patentable weight.
using at least one of the tokenized transaction data set, the item purchase data, and the merchant transaction data set, authorize completion of the payment transaction and generate a transaction confirmation data set upon verifying that: the payment transaction satisfies limitation logic in the delimiter operand (Laracey [0038]: The authorization approval processing is performed using standard financial authorization processing over one or more authorization networks (e.g., such as the VISANET.RTM. network operated by Visa, Inc., an Automated Clearing House system such as NACHA, or the like, referred to in FIGS. 2, 3 5, and 6 below simply as "payment processing")), (see paragraphs [0038] and [0059] and Fig. 1); and
using the network communication system, route the transaction confirmation data set to at least one of the second mobile communication device and the point-of-sale terminal (Laracey [0047]: The transaction management system 130, upon receipt of an authorization response from the payment processing systems, causes a confirmation response message to be transmitted to the merchant 108 (a confirmation response may also be transmitted to the mobile device 102)), (see paragraph [0047] and Fig. 1).
Examiner’s Note: with respect to amended claim language, “wherein the at least one of the second mobile communication device and the point-of-sale terminal processes a transaction upon receiving the transaction confirmation data set, and wherein after receipt of the confirmation data set, the second mobile communication device wirelessly transmits the transaction confirmation data set to an automated security system in the merchant premises to allow a purchaser possessing the second mobile device to leave the merchant premises with the one or more items for purchase without setting off alarms of the automated security system”. This limitation does not limit the functionality of the claimed backend payment processing computer server because this limitation is outside the scope of the claimed backend payment processing computer server. Furthermore, this limitation falls outside the scope of the claimed invention because it recites operation not performed by the claimed backend payment processing computer server. Therefore, this limitation has limited patentable weight since step of “second mobile communication device and the point-of-sale terminal processes a transaction” is not positively tied with any structure element of the claimed backend payment processing computer server. And with respect to the method claim 11, this limitation is not positively recited functional step and hence receive limited patentable weight.
As indicated above, Laracey discloses, a location reference denoting an external memory location where transaction payment data is stored and transmitting the location reference denoting an external memory location where transaction payment data is stored (Laracey [0039]: the mobile device 102 never stores, sends or receives actual payment credentials. Instead, the mobile device 102 stores or has access to a proxy associated with actual payment credentials, and the proxy is used to identify a desired payment account for use in a given transaction. The proxy is transmitted to the transaction management system 130 (or, in some embodiments, to a wallet issuer) in a customer payment authorization request message and the transaction management system 130 (or, in some embodiments, to a wallet issuer) uses the proxy to lookup or identify the actual payment credentials associated with the selected account).
Laracey does not specifically disclose, the token includes the reference data (i.e., proxy associated with actual payment credentials) for the transaction payment data.
However, for compact persecution and clarity purpose, the Examiner cites HOSP to specifically disclose: the token includes the reference data for the transaction payment data (HOSP [0060]: In an embodiment, a token is a data packet (i.e. portion of data) which corresponds to a payment account, such as, for example, a bank account. The token may include a reference or identifier of the payment account and thereby correspond with the payment account. In an embodiment, the token may not include any details of the account, for example, an account number, an account holder's details (e.g. name or address), the amount of funds in the account).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Laracey with HOSP to include tokenization functions of HOSP, such as generating a token including a reference or identifier of the payment account to enhance transaction/payment data security.
Regarding claims 2 and 12: Laracey and HOSP, discloses the limitations of claim 1 above.
Laracey further discloses: The backend payment processing computer server of claim 1, wherein the at least one processor is configured to cause the computer server to: upon receipt from the point-of-sale terminal of the merchant transaction data set:
generate a merchant transaction notification data set (see paragraph [0029]); and
route the merchant transaction notification data set to the point-of-sale terminal associated with the merchant identifier, the merchant transaction notification data set comprising data representing at least: an identifier associated with the first mobile communication device (see paragraphs [0029]-[0030] and [0097 and Figs. 1 and 5).
Regarding claims 3 and 13: Laracey and HOSP, discloses the limitations of claim 1 above.
Laracey further discloses: The backend payment processing computer server of claim 1, wherein the delimiter operand is implemented as a single-use delimiter encoded in one or more EMV-compliant data elements (e.g., standard financial authorization processing), the backend payment processing computer server authorizing only a first authorization attempt associated with the single-use delimiter (see paragraphs [0030], [0038] [0051] and [0059]).
Alternatively, HOSP discloses: wherein the delimiter operand is implemented as a single-use delimiter (HOSP [0060]: The token may include a reference or identifier of the payment account and thereby correspond with the payment account. In an embodiment, the token may not include any details of the account, for example, an account number, an account holder's details (e.g. name or address), the amount of funds in the account. Accordingly, the token cannot be used by a malicious party to extract unlimited funds. However, the token may be used by a party in possession of the token to remove certain funds from the account. In an embodiment, a given token may be used only a certain number of times to extract funds, e.g. one time or two times).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Laracey with HOSP to include tokenization functions of HOSP, such as generating a token including a reference or identifier of the payment account to enhance transaction/payment data security.
Regarding claims 5 and 15: Laracey and HOSP, discloses the limitations of claim 1 above.
Laracey further discloses: The system of claim 1, wherein the tokenized transaction data set comprises data interpretable as instructions associated with the completion of the payment transaction (Laracey [0020]: the transaction management system performs the matching using, at least in part, a token (such as a checkout token or ATM token). Once the pending transaction information is matched with the user information, further processing may be performed to allow selection or identification of an appropriate or desired payment account to be used to complete the transaction), (see paragraphs [0045] and [0059]).
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Kevin Laracey (US 20140149293 A1, “Laracey”) in view of HOSP et al. (US 20150073999 A1, “HOSP”) further in view of Soghoian et al. (US 20090198617 A1 “Soghoian”).
Regarding claims 4 and 14: Laracey and HOSP, discloses the limitations of claim 1 above.
Laracey further discloses: The backend payment processing computer server of claim 1, wherein the delimiter operand is implemented as a value-cap delimiter comprising a remaining-amount field […], the backend payment processing computer server […] authorized transaction value (e.g., availability of funds) and rejecting authorization when the authorized transaction value exceeds the remaining-amount field (Laracey [0057]: The token may be encoded to include both an identifier and a token value, and the identifier may be used as a parameter in a web service call made by the mobile device 102 to retrieve the path to the appropriate transaction management system 130a-n.) (see paragraphs [0035], [0059]).
As indicated above, Laracey discloses, a token may be issued for use in a transaction in a number of different ways and authorizing the transaction for the token. Laracey doesn’t explicitly disclose, decrementing the remaining-amount field by the authorized transaction value.
However, Soghoian discloses, , decrementing the remaining-amount field by the authorized transaction value (see claim 6 paragraphs [0024]-[0025]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Laracey and HOSP with to well-known tokenization and payment transaction function, such as deducting the used amount from the token to enhance transaction security and user experience.
Claims 6, 7, 9, 10, 16, 17, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kevin Laracey (US 20140149293 A1, “Laracey”) in view of HOSP et al. (US 20150073999 A1, “HOSP”) further in view of Scipioni et al. (US 20140006280 A1, “Scipioni”).
Regarding claims 6 and 16: Laracey and HOSP, discloses the limitations of claim 1 above.
Laracey doesn’t explicitly disclose, however, Scipioni discloses: The system of claim 1, wherein the at least one processor is configured to cause the system to:
prior to generating the transaction confirmation data set, use the network communication system to route the transaction confirmation data set to a second mobile communication device, the transaction confirmation data set comprising a request for user validation of the payment transaction (Scipioni [0041]: the second user device 300 is still displaying the payment request page 400, but payment authorization system provider device has provided, over the network to the second user device 300, the payment request page 400 with an obtaining authorization section 400c that explains to the second user that the payment account identifier is associated with another user device and an attempt to authorize use of the payment account is being performed), (see paragraphs [0040]-[0041] and Figs. 1, 4b, and 4c).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Laracey and HOSP with Scipioni to include payment authorization functions of Scipioni, such as communicating additional authorization data with a second device to enhance payment transaction security.
Regarding claims 7 and 17: Laracey and HOSP, discloses the limitations of claim 1 above.
Laracey doesn’t explicitly disclose, however, Scipioni discloses: The system of claim 6, wherein the at least one processor is configured to cause the system to:
authorize the completion of the payment transaction upon receipt from the second mobile communication device of a transaction validation data set in response to the request for user validation (Scipioni [0043]: the method 100 proceeds to block 108 where authorization is received from the first user device; [0044]: the payment authorization system provider device may provide, over the network to the first user device 200, an authorization confirmation 408 confirming the authorization of the second user and associated second user device 300 to make a payment according to the payment request using the payment account), (see paragraphs [0043]-[0044] and [0047] and Figs. 1 and 4b).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Laracey and HOSP with Scipioni to include payment authorization functions of Scipioni, such as communicating additional authorization data with a second device to enhance payment transaction security.
Regarding claims 9 and 19: Laracey and HOSP, discloses the limitations of claim 1 above.
Laracey doesn’t explicitly disclose, however, Scipioni discloses: The system of claim 8, wherein the at least one processor is configured to cause the system to:
authorizing completion of the payment transaction upon receipt from the second mobile communication device of a transaction validation data set in response to the request for user validation (Scipioni [0047]: Subsequent to verifying any user devices, security codes, and/or other authorizations discussed above, the payment authorization system provider device may then send instructions to make a payment using the payment account. In an embodiment, the payment authorization system provider device is an account provider device, and the account provider device sends an instruction that results in a payment being made from the payment account to a payee account of a payee which whom the second user was making the purchase from. In another embodiment, the payment authorization system provider device is a payment service provider device, and the payment service provider device sends an instruction to an account provider device that results in a payment being made from the payment account to a payee account of a payee which whom the second user was making the purchase from. Furthermore, the payment authorization system provider device may provide, over the network to the second user device 300, a purchase completed page 410 that includes a purchase details section 410a having the details of the purchase made using the payment account, and a purchase completed indication 410b.), (see paragraphs [0043]-[0044] and [0047] and Figs. 1 and 4b).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Laracey and HOSP with Scipioni to include payment authorization functions of Scipioni, such as communicating additional authorization data with a second device to enhance payment transaction security.
Regarding claims 10 and 20: Laracey and HOSP, discloses the limitations of claim 1 above.
Laracey doesn’t explicitly disclose, however, Scipioni discloses: The system of claim 1, wherein the at least one processor is configured to cause the system to:
prior to generating the transaction confirmation data set, use the network communication system to route to the mobile communication device, a request for user verification (Scipioni [0042]: in this embodiment, the payment authorization system provider device also provides, over the network to the first user device 200, an authorization request 404 that includes payment request information 404a, along with an authorize pad 404b (e.g., the pin pad in the illustrated embodiment that allows the first user to enter a security code), (see paragraphs [0042] and Fig. 4C); and
authorize the completion of the payment transaction upon receipt from the mobile communication device of a correct user verification in response to the request for user verification (see paragraphs [0042] and [0047] and Fig. 4).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Laracey and HOSP with Scipioni to include payment authorization functions of Scipioni, such as communicating additional authorization data with a second device to enhance payment transaction security.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kevin Laracey (US 20140149293 A1, “Laracey”) in view of HOSP et al. (US 20150073999 A1, “HOSP”) in view of Scipioni et al. (US 20140006280 A1, “Scipioni”) further in view of Jeremiah Joseph (US 20140040129 A1, “Akin”).
Regarding claims 8 and 18: Laracey and HOSP, discloses the limitations of claim 1 above.
Laracey doesn’t explicitly disclose, however, Akin discloses: The system of claim 1, wherein the at least one processor is configured to cause the system to:
prior to generating the transaction confirmation data set, upon determining that the authorized transaction value exceeds a predefined threshold, use the network communication system to route the transaction confirmation data set to a second mobile communication device, the transaction confirmation data set comprising a request for user validation of the payment transaction (Akin [0005]: The payment provider can facilitate authentication of the purchaser, determine if the purchaser is authorized to make the purchase (can determine that the purchaser has not exceeded a deposited amount, e.g., for a debit card or gift card, or has not exceeded a credit limit, for example), and can facilitate the transfer of money from the purchaser to a merchant so as to pay the merchant for the purchased product; [0033]: The payment server 130 can verify that the child is authorized make the purchase by determining that the purchase will not cause an account balance limit (such as for a debit card or a gift card) or a credit limit (such as for a credit card) to be exceeded; [0048]: Approval of the parent for the child to purchase the product can be requested by the child if the purchase transaction is not automatically approved by the payment server 130 because the purchase exceeds a predefined limit, as discussed herein.), (see paragraphs [0030] and Fig. 2).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Laracey, HOSP and Scipioni with Akin to include additional payment authorization functions, such as communicating additional authorization request with a second device to enhance payment transaction security.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAHED ALI whose telephone number is (571)270-1085. The examiner can normally be reached 8:00 - 5:00 M-F.
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, Neha Patel can be reached on (571) 270-1492. 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.
/JAHED ALI/Examiner, Art Unit 3699
Prosecution Insights