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 .
Acknowledgements
This Office Action addresses the response filed on 04/08/2026.
Claim 1 was amended.
Claims 8-20 were previously withdrawn.
Claims 1-20 are pending.
Claims 1-7 were examined.
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-7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
According to MPEP 2106 II, It is essential that the broadest reasonable interpretation (BRI) of the claim be established prior to examining a claim for eligibility. Further, MPEP 2103 I C establishes that the subject matter of a properly construed claim is defined by the terms that limit the scope of the claim when given their broadest reasonable interpretation. It is this subject matter that must be examined. Regarding the independent claims, claim 1 recites “ first device token identifying the first session and the mobile device”; “a customer token identifying a user”; “the second device token identifying the mobile device and a second session that is subsequent to the first session”; “the identifier associated with the user and the request”; “the identifier generated by the computing system”; “an existing identifier stored by the computing system in association with the request during the first session”, language directed to non-functional descriptive material. See MPEP 2111.05. Lastly, claim 1 recites “receiving… based on authentication of the first session using the first device token”; “receiving… based on a comparison of the received identifier with an existing identifier stored by the computing system in association with the request during the first session” , language directed to contingent limitations. The broadest reasonable interpretation of a system (or apparatus or product) claim having structure that performs a function, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) (precedential) for an analysis of contingent claim limitations in the context of both method claims and system claims. See also MPEP 2111.04. With respect to the Eligibility Step 1 of the Alice/Mayo two-part test of the subject matter eligibility analysis (see MPEP 2106), in the instant case, claims 1-7 are directed to a mobile device. Therefore, these claims fall within the four statutory categories of invention.
Following step 2A, prong one of the analysis, the language of the independent claims reciting an abstract idea are marked in bold below:
a. enabling access to the client application during a first session based on a first device token identifying the first session and the mobile device and a customer token identifying a user;b. receiving a second device token from a computing system during the first session, the second device token identifying the mobile device and a second session that is subsequent to the first session;c. receiving, by the client application during the first session, a request to execute a transaction;d. receiving, by the client application during the first session, an identifier from the computing system, the identifier associated with the user and the request, the identifier generated by the computing system in response to receiving the request and based on authentication of the first session using the first device token; ande. receiving, by the client application during the first session and based on a comparison of the received identifier with an existing identifier stored by the computing system in association with the request during the first session, an approval for the request
Therefore, the portions highlighted in bold above recite access control and information retrieval, which is an abstract idea grouped within the certain methods of organizing human activity and mental processes grouping of abstract ideas in prong one of step 2A. The claims are grouped within certain methods of organizing human activity because the steps recited describe the commercial or legal interaction of allowing access to a resource. Additionally, the claims are also grouped within mental processes because the steps recited describe collecting information, analyzing it, and displaying certain results of the collection and analysis, which is a concept that can be performed in the human mind or by pen and paper. In situations like this where a series of steps recite judicial exceptions, examiners should combine all recited judicial exceptions and treat the claim as containing a single judicial exception for purposes of further eligibility analysis. See MPEP 2106.04 and 2106.05(II). Thus, the language identified in the certain methods of organizing human activity and mental processes groupings were considered as a single abstract idea. Accordingly, the claims recite an abstract idea.
With respect to step 2A, prong two of the analysis, this judicial exception is not integrated into a practical application. Specifically, with respect to using mobile device, processing circuit, memory to perform the recited steps/functions, these additional elements performs the steps or functions such as: “enabling… access…”, “receiving… token…”, “receiving… request…”, “receiving… identifier…”, “receiving… approval…”. These additional elements are recited at a high-level of generality such that it represents no more than mere instructions to apply the exception using a generic computer component, which only serves to use computers as a tool to perform the abstract idea. Therefore, these elements do not integrate the abstract idea into a practical application because they require no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional element of a computing system amount to generally link the use of the judicial exception to a particular technological environment or field of use. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, following the analysis of step 2A, prong two, the claims are still directed to an abstract idea.
With respect to step 2B of the analysis, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional computer elements, such as mobile device, processing circuit, memory, computing system. The mobile device, processing circuit, memory perform the steps/functions of “enabling… access…”, “receiving… token…”, “receiving… request…”, “receiving… identifier…”, “receiving… approval…”, and amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept beyond the abstract idea of access control and information retrieval. The additional element of a computing system amounts to generally linking the use of the judicial exception to a particular technological environment or field of use. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions that 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 access control and information retrieval. Therefore, the independent claims are not eligible.Examiner notes that, for elements recited in the dependent claims which were previously analyzed as additional elements of the independent claims above (i.e. mobile device, processing circuit, memory), the assessment of these elements under step 2A and step 2B for the dependent claims is inherited from the analysis of the independent claims and omitted for brevity, unless noted by Examiner below. Dependent claims 2-7 further recite the following additional language, in which elements which merely further define the identified abstract idea are marked in bold below:
f) wherein the approval for the request is provided via a user interface displayed on the mobile device during the first session; wherein the user interface includes an optical code, the operations further comprising: providing, by the mobile device via the user interface, the optical code to a code scanner of a recipient. g) wherein: the identifier is a tokenized card number comprising a plurality of digits; at least four digits of the tokenized card number match an actual credit card number of the user; and at least one of the plurality of digits other than the at least four digits do not match the actual credit card number of the user. h) wherein the tokenized card number comprises a first issuer identification number that identifies the computing system. i) wherein the actual credit card number comprises a second issuer identification number different from the first issuer identification number of the tokenized card number. j) wherein the mobile device communicates with a recipient computer system via a network, the operations further comprising: transmitting, by the mobile device via the network, the identifier to the recipient computer system. k) wherein the mobile device communicates with a recipient computer system via a near-field communication (NFC), the operations further comprising: generating, by the mobile device during the first session, a code including the identifier; and transmitting, by the mobile device via NFC, the code to the recipient computer system.
With respect to the eligibility analysis of claim 3, the claim recites item g) above, which do not introduce additional elements/functions. The additional language merely represents statements directed to non-functional descriptive material by describing what the identifier is. Those statements are insufficient to significantly alter the eligibility analysis.
With respect to the eligibility analysis of claim 4, the claim recites item h) above, which do not introduce additional elements/functions. The additional language merely represents statements directed to non-functional descriptive material by describing what the number comprises and description of this data content. Those statements are insufficient to significantly alter the eligibility analysis.
With respect to the eligibility analysis of claim 5, the claim recites item i) above, which do not introduce additional elements/functions. The additional language merely represents statements directed to non-functional descriptive material by describing what the number comprises and description of this data content. Those statements are insufficient to significantly alter the eligibility analysis.
Therefore, the additional language g) - i) of dependent claims 3 - 5 do not alter the analysis provided with respect to independent claim 1. In other words, the claims do not introduce additional elements that would alter the analysis with respect to Steps 2A or 2B above in any meaningful way. Therefore, these dependent claims are also ineligible.
With respect to claim 2, the claim recites item f) above, language directed to non-functional descriptive material by describing what the approval is and what the user interface "includes". Those statements are insufficient to significantly alter the eligibility analysis. Item f) above introduces the additional elements/functions of providing… code…. This language further elaborates the abstract idea of access control and information retrieval identified in the analysis of independent claim 1. Therefore, this language does not significantly alter the analysis with respect to the independent claim 1. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer. Examiner notes the additional elements/functions are part of the mental process of collecting information, analyzing it, and displaying certain results of the collection and analysis.
With respect to the eligibility analysis of claim 6, Item j) above introduces the additional elements/functions of transmitting… identifier…. This language further elaborates the abstract idea of access control and information retrieval identified in the analysis of independent claim 1. Therefore, this language does not significantly alter the analysis with respect to the independent claim 1. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer. Examiner notes the additional elements/functions are part of the mental process of collecting information, analyzing it, and displaying certain results of the collection and analysis.
With respect to the eligibility analysis of claim 7, Item k) above introduces the additional elements/functions of generating… and… transmitting… code…. This language further elaborates the abstract idea of access control and information retrieval identified in the analysis of independent claim 1. Therefore, this language does not significantly alter the analysis with respect to the independent claim 1. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer. Examiner notes the additional elements/functions are part of the mental process of collecting information, analyzing it, and displaying certain results of the collection and analysis. Examiner further notes the recitation of near-field communications (NFC) in the claim does not go beyond generally linking the use of the judicial exception to a particular technological environment.
Therefore, while the additional language f), j) and k) of dependent claims 2, 6 and 7 slightly modify the analysis provided with respect to independent claim 1, these additional elements/functions are insufficient to render the dependent claims eligible, as detailed above. Therefore, these dependent claims are also ineligible.
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 1-7 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 applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 was amended to recite: “receiving, by the client application during the first session, an identifier from the computing system, the identifier associated with the user and the request, the identifier generated by the computing system in response to receiving the request and based on authentication of the first session using the first device token”. It is unclear by the claim language whether the language “in response to receiving the request and based on authentication of the first session using the first device token” refers to “receiving” (i.e. “receiving… in response to receiving the request and based on authentication of the first session using the first device token”), or whether it refers to “generated by the computing system” (i.e. “generated by the computing system in response to receiving the request and based on authentication of the first session using the first device token”). Examiner notes that while it appears the language is directed to describing the manner the identifier is generated, the "request" is required by the claims to be received by the client application. Therefore, another reasonable interpretation would be that the identifier is received in response to receiving the request. This duality renders the scope of the newly introduced language unclear, as it is unclear whether the newly introduced language is supposed to modify the step of "receiving" or is supposed to further describe the "identifier". For purposes of Examination, Examiner adopts the latter. Dependent claims 2-7 are also rejected since they depend on claim 1.
Claim 1 is indefinite because it is unclear to one of ordinary skill in the art whether Applicants are claiming the subcombination of a “mobile device” or the combination of a “mobile device” and “computing system”. If it is Applicants’ intent to claim only the subcombination, the body of the claims must be amended to remove any positive recitation of the combination. If it is Applicants’ intent to claim the combination, the preamble of the claim must be amended to be consistent with the language in the body of the claim. For the latter, Examiner recommends claiming a “system”. The claims were amended to recite "receiving, by the client application during the first session and based on a comparison of the received identifier with an existing identifier stored by the computing system in association with the request during the first session, an approval..." The introduction of a "computing system" as a modifier of the receiving step renders the scope of the claim unclear. Particularly, it is unclear whether the "receiving" step is performed by the client application alone (i.e. based on a comparison performed by the client application with data stored by a computing system) or whether it requires both the client application and the "computing system" (i.e. the comparison performed by the computing system, as the claims now require "an existing identifier stored by the computing system"). This duality renders the scope of the claims unclear. Dependent claims 2-7 are also rejected since they depend on claims 1, respectively.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1 and 3-7 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Laracey et al. (US 2015/0186871 A1), hereinafter Laracey in view of Gaddam et al. (US 2014/0194097 A1) , hereinafter Gaddam.
With respect to claim 1, Laracey teaches a mobile device comprising: a processing circuit comprising a processor coupled to a memory (see Fig. 1, mobile device 102, paragraph [0018]) (NFC mobile wallet processing systems and methods) comprising:
enabling access to the client application during a first session based on a first device token identifying… the mobile device and a customer token identifying a user (see registration process, first device token, i.e. customer identifier Fig. 3, 302, paragraph [0053]: “The registration process 300 of FIG. 3 begins when a customer first (at 302) interacts with a registration server (which may be a component of, or related to, transaction management system 230 of FIG. 2) to initiate a registration process… A customer identifier or other unique record (or records) may be established in a database and may be used to uniquely identify the customer. The customer identifier may be an alphanumeric identifier assigned by the transaction management system 230 or may be information based on or provided by the customer (e.g., such as a mobile phone number or identifier associated with a mobile device 202).”; mobile device identifier, Fig. 3, 304, paragraph [0054]: “Processing continues at 304 where the customer establishes an account. In some embodiments, the account creation includes providing contact and identifying information associated with the customer, as well as information identifying one or more mobile device(s) from which the customer wishes to make transactions. Each mobile device 202 may, for example, be identified by its phone number and/or other unique identifier(s) (such as a hardware serial number, an ASIN, a UUID in the case of an iPhone, a component serial number such as a CPU serial number, a unique identifier created from a series of configuration settings on the device, or the like). In some embodiments, where the customer registers from a browser on their mobile device, or by first downloading a payment application having a registration module onto their mobile device, the system may capture unique identifying information associated with the mobile device (e.g., such as a hardware serial number, an ASIN, a UUID or other device identifiers).”; paragraph [0070]: “…At 310, the customer is prompted to download and install an application on their mobile device. The application allows the customer to operate their mobile device to quickly and easily conduct payment transactions pursuant to the present invention...”; Examiner interprets the first session spans from registering/downloading and installing an application as disclosed in conjunction with Fig. 3, to receiving a payment authorization response Fig. 6, step 622.);
receiving a second device token from a computing system during the first session, the second device token identifying the mobile device and a second session that is subsequent to the first session (see paragraph [0021]: “…the transaction management system 130 may provide one or more checkout tokens to the mobile device 102 so that additional checkout tokens may be cached or otherwise stored for use on the mobile device 102 such as in the case where, at the time of transaction, the user is unable to connect from their mobile device 102 to the transaction management system 130. In some embodiments, it is possible to retrieve checkout tokens at any time and in any quantity..." See also paragraph [0020]: "The checkout token may be, for example, a transaction identifier, a checkout token, a session identifier, a wallet identifier, a user identifier, or the like...”; paragraph [0100]: "... In some embodiments the delivery of one or more checkout token to the mobile device 202 could happen in advance of any payment transaction being conducted the customer, and the checkout tokens could be stored on the mobile device and one or more pending transaction records would be created in the transaction management system 230”);
receiving, by the client application during the first session, a request to execute a transaction (see paragraph [0071]: “Once a customer has established an account and registered one or more payment accounts (and, optionally, one or more loyalty, reward or other accounts and/or information about desired offers and discounts) with the transaction management system, the customer may utilize the system of the present invention to conduct purchase transactions at merchants that support transactions of the present invention.”; paragraph [0020]: “A user operating the mobile device 102 approaches a point of transaction to conduct a transaction. The user interacts with a payment application on the mobile device 102 to initiate a transaction (or to otherwise prepare to conduct a transaction). For example, the user (or a point of sale clerk on behalf of the user) may select an option to "pay with NFC," "pay with mobile" or the like, or the user may simply tap their phone on the terminal to initiate a transaction after seeing a prompt on the terminal to do so or receiving a prompt from the point of sale clerk. The payment application may optionally then prompt the user to authenticate themselves (e.g., using a password, fingerprint recognition module on the mobile device, iris scan, voiceprint or other techniques some of which are described in our co-pending and commonly assigned applications). The authentication process may occur between the mobile device 102 and the transaction management system 130 over a communication link 114...: Fig. 5, steps 502-506, paragraphs [0090] and [0091]);
receiving, by the client application during the first session, an identifier from the computing system, the identifier associated with the user and the request, the identifier generated by the computing system in response to receiving the request and based on authentication of the first session using the first device token (see checkout token, paragraph [0020]: "...Once the user (and the mobile device 102 in some embodiments) have successfully been authenticated to the transaction management system 130, an identifier (referred to herein as the "checkout token") is provided to the mobile device 102 from the transaction management system 130. The checkout token may be, for example, a transaction identifier, a checkout token, a session identifier, a wallet identifier, a user identifier, or the like. In some embodiments, the "checkout token" (whether it be a transaction, session, wallet, or user identifier) is formatted such that it may be processed or routed using the payment network 116...”; paragraph [0028]: “The checkout token included in the message is extracted and used by the transaction management system 130 to find a match with an existing identifier associated with an active mobile wallet session (established when the user operated the mobile device to perform the initial authentication)..."; Fig. 5, step 510, paragraph [0092]: “Processing continues at 510 if the authentication processing is successful (that is, if the customer and the device have successfully been identified by the transaction management system 230), where the transaction management system 230 assigns, generates or otherwise provides a checkout token for use in the transaction to the mobile device 202... In some embodiments, the checkout token may be generated and delivered to the mobile device 202 at any time in advance of the customer conducting an actual transaction, and the checkout token in these embodiments would be stored on the mobile device 202. Processing at 510 may also include processing by the transaction management system 230 to create a pending transaction record in a transaction queue for use in conducting the transaction.”); and
receiving, by the client application during the first session and based on a comparison of the received identifier with an existing identifier stored by the computing system in association with the request during the first session, an approval for the request (see paragraph [0045]: "In general, however, the checkout token 210 is used by the transaction management system 230 to match a payment request from a mobile device 202 with a payment authorization request from the merchant 208 to complete a payment transaction using information stored at, or accessible to, the transaction management system 230.”; paragraph [0051]: "...Once the availability of funds is confirmed, the transaction management system then sends a merchant payment authorization response message to the merchant 208 so the transaction can be completed at the point of sale 212, and a customer payment authorization response message to the customer's mobile device 202.”).
Laracey does not explicitly disclose a mobile device comprising: the first device token identifying the first session.
However, Gaddam discloses a mobile device (Method of device authentication and application registration in a push communication framework) comprising:
the first device token identifying the first session (see paragraph [0044]: “…Each connection session is identified by a unique session ID identifier. The mobile device 201 stores data associated with each session for use by the push client 215. The session ID can be a universally unique identifier generated by a time-based generator, and having an associated session lifetime indicating the time period during which the session ID remains valid. Data associated with the session includes the session ID and session lifetime, as well as other session data such as connection or communication parameters, and/or device or network parameters used in the connection session. If push client 215 determines that an existing connection matches the registration request, the push client 215 may send a registration confirmation message to application 213 including the session ID for the connection session.”; paragraph [0047]: “In particular, the push server 203 authenticates the mobile device 201 using the one or more mobile device identifiers received in the authentication request. ..."; paragraph [0048]: “Upon successful authentication of the mobile device 201 and validation of the application 213, the push server registers a session for the mobile device 201 at step 309. The registration includes generating and assigning a session ID identifier, and an associated session lifetime indicating a pre-specified period of time for which the session will be valid. The push server 203 maintains a database of all connection sessions currently supported for all mobile devices 201. Upon registration of the session, the push server 203 stores in its database the session ID identifier and data associated with the session, such as the session lifetime and the one or more mobile device identifiers (e.g., an MDN and/or hardware ID) received as part of the authentication and registration request. In general, a session ID is associated with a mobile device 201… in some examples, a different session ID may be associated with each application 213 running on the mobile device 201 and requiring a persistent push data connection, such that multiple session IDs may be associated with one mobile device 201.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the mobile device identifier association with the session ID during registration as disclosed by Gaddam in the mobile device of Laracey, the motivation being to avoid the need for repeating the device authentication if the connection needs to be re-established (see Gaddam, paragraph [0018]).
With respect to the BRI of the claim, Examiner notes that claim 1 recites “ first device token identifying the first session and the mobile device”; “a customer token identifying a user”; “the second device token identifying the mobile device and a second session that is subsequent to the first session”; “the identifier associated with the user and the request”; “the identifier generated by the computing system”; “an existing identifier stored by the computing system in association with the request during the first session”, language directed to non-functional descriptive material. See MPEP 2111.05. Lastly, claim 1 recites “receiving… based on authentication of the first session using the first device token”; "receiving… based on a comparison of the received identifier with an existing identifier stored by the computing system in association with the request during the first session” , language directed to contingent limitations. The broadest reasonable interpretation of a system (or apparatus or product) claim having structure that performs a function, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) (precedential) for an analysis of contingent claim limitations in the context of both method claims and system claims. See also MPEP 2111.04.
With respect to claim 3, the combination of Laracey and Gaddam teaches all the subject matter of the mobile device as described above with respect to claim 1. Furthermore, Laracey discloses a mobile device wherein: the identifier is a tokenized card number comprising a plurality of digits; at least four digits of the tokenized card number match an actual credit card number of the user; and at least one of the plurality of digits other than the at least four digits do not match the actual credit card number of the user (see paragraph [0093]: “... in some embodiments, the checkout token may be formatted as a PAN and passed in a field of a message typically used for a PAN in a payment transaction (although as discussed herein, the checkout token may be formatted in other ways and included in other fields of a message).”; paragraph [0076]: “In some embodiments, the checkout token is received by the NFC reader in a field of a standard NFC message format, such as in a field designated for carrying information such as a PAN. As described further herein, the checkout token, in some embodiments, may be formatted as a PAN, allowing the merchant system 209 to process the message using standard processing methods (e.g., without requiring additional or modified software). For example, in some embodiments, the checkout token may be presented in the message received over the NFC communication link as a 16 digit PAN which may then be used to identify that the transaction is a mobile payment transaction pursuant to the present invention and to route a merchant payment authorization request message to the transaction management system 230.”; paragraph [0080]: “In addition, the payment switch is also typically responsible for creating and managing reporting and settlement information so that the merchant 208 can keep track of the payment instruments that were used to pay for the goods associated with a particular in store purchase transaction. The payment switch might create a report specifying that for point of sale transaction 123 on Mar. 5, 2015 at store number 12, Visa credit card number 1111333355557777 with expiration of 2/18 was used to pay for the transaction...”; paragraph [0081]: “As a result, in embodiments where a merchant's payment switch is used to make the routing determination of the present invention, although the PAN used as a checkout token might conform to the specification for a payment card PAN (such as a debit card PAN or a credit card PAN), ultimately the authorization for the payment may be completed using a completely different payment account identifier than the PAN used for the checkout token. This may be the case because the payment switch upon reading the PAN - say it is 4111333355557777 which could be a PAN for a VISA credit card - might discover that this PAN falls within the range of PANs designated for use with the present invention, and that the PAN and all information associated with the PAN including pending transaction details should be routed to the transaction management system 230.”). Regarding the BRI of the claim, Examiner notes that claim 3 recites “the identifier is a tokenized card number comprising a plurality of digits; at least four digits of the tokenized card number match an actual credit card number of the user; and at least one of the plurality of digits other than the at least four digits do not match the actual credit card number of the user”, language directed to non-functional descriptive material. See MPEP 2111.05. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 4, the combination of Laracey and Gaddam teaches all the subject matter of the mobile device as described above with respect to claim 3. Furthermore, Laracey discloses a mobile device wherein the tokenized card number comprises a first issuer identification number that identifies the computing system (see paragraph [0049]: “After the merchant 208 receives the checkout token from the mobile device 202 (via the NFC communication link between the mobile device 202 and the NFC reader), the merchant 208 transmits a merchant payment authorization request message to the transaction management system 230 over a network 220. Pursuant to some embodiments, the routing of the message to the transaction management system 230 includes mapping to or identifying the transaction management system 230 by using the checkout token (e.g., based on the BIN, PAN or other information in or associated with the checkout token received from the mobile device 202). The transaction management system 230 matches the customer payment authorization request (received from the mobile device 202 over network 201) with the merchant payment authorization request (received from the merchant 208 over network 220) by using the checkout token 210”). Regarding the BRI of the claim, Examiner notes that claim 4 recites “wherein the tokenized card number comprises a first issuer identification number that identifies the computing system”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 5, the combination of Laracey and Gaddam teaches all the subject matter of the mobile device as described above with respect to claim 4. Furthermore, Laracey discloses a mobile device wherein the actual credit card number comprises a second issuer identification number different from the first issuer identification number of the tokenized card number (see paragraph [0080, Visa credit card number Visa credit card number 1111333355557777 ; paragraph [0081] Pan for Visa credit card 4111333355557777 ). Regarding the BRI of the claim, Examiner notes that claim 5 recites “wherein the actual credit card number comprises a second issuer identification number different from the first issuer identification number of the tokenized card number.”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 6, the combination of Laracey and Gaddam teaches all the subject matter of the mobile device as described above with respect to claim 1. Furthermore, Laracey discloses a mobile device wherein the mobile device communicates with a recipient computer system via a network, the operations further comprising: transmitting, by the mobile device via the network, the identifier to the recipient computer system (see Fig. 5, step 512, paragraph [0093]: “Processing continues at 512 where the customer presents (or "taps") the mobile device 202 to an NFC reader at the merchant 208. Pursuant to some embodiments, information is transmitted from the mobile device 202 to the NFC reader over an NFC communication interface, and the information may include the checkout token. In some embodiments, the checkout token is passed to the NFC reader in a message formatted pursuant to an NFC payment scheme (such as the Visa.RTM. Paywave, Discover.RTM. "Zip", or the MasterCard.RTM. PayPass schemes). Further, in some embodiments, the checkout token may be formatted as a PAN and passed in a field of a message typically used for a PAN in a payment transaction (although as discussed herein, the checkout token may be formatted in other ways and included in other fields of a message)”). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 7, the combination of Laracey and Gaddam teaches all the subject matter of the mobile device as described above with respect to claim 1. Furthermore, Laracey discloses a mobile device wherein the mobile device communicates with a recipient computer system via a near-field communication (NFC), the operations further comprising: generating, by the mobile device during the first session, a code including the identifier; and transmitting, by the mobile device via NFC, the code to the recipient computer system (see Fig. 5, step 512, paragraph [0093]: “Processing continues at 512 where the customer presents (or "taps") the mobile device 202 to an NFC reader at the merchant 208. Pursuant to some embodiments, information is transmitted from the mobile device 202 to the NFC reader over an NFC communication interface, and the information may include the checkout token. In some embodiments, the checkout token is passed to the NFC reader in a message formatted pursuant to an NFC payment scheme (such as the Visa.RTM. Paywave, Discover.RTM. "Zip", or the MasterCard.RTM. PayPass schemes). Further, in some embodiments, the checkout token may be formatted as a PAN and passed in a field of a message typically used for a PAN in a payment transaction (although as discussed herein, the checkout token may be formatted in other ways and included in other fields of a message)”).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Laracey (US 2015/0186871 A1), in view of Gaddam (US 2014/0194097 A1), in view of Labrou (US 2005/0187873 A1).
With respect to claim 2, the combination of Laracey and Gaddam teaches all the subject matter of the mobile device as described above with respect to claim 1. Furthermore, Laracey discloses a mobile device wherein the approval for the request is provided via a user interface displayed on the mobile device during the first session, (see Figs. 8C and 8D, paragraph [0125]: "...The user interface of FIG. 8C shows the customer the details 850 of the just-completed transaction including any loyalty rewards, rebate amount or the like earned from the transaction (shown at 854 as a savings amount). The user interface also shows a region 856 where coupons, advertisements, or other offers sourced from advertising and offer management networks may be presented to the customer. Once the customer is done viewing the transaction details, the customer may click on a button 852 to navigate away from the screen and to return to the home page of the payment application or to a thank you page such as the page 858 shown in the user interface of FIG. 8D”).
The combination of Laracey and Gaddam does not explicitly disclose a mobile device comprising: wherein the user interface includes an optical code, the operations further comprising: providing, by the mobile device via the user interface, the optical code to a code scanner of a recipient.
However, Labrou discloses a mobile device (Wireless wallet) comprising:
wherein the user interface includes an optical code, the operations further comprising: providing, by the mobile device via the user interface, the optical code to a code scanner of a recipient (see Fig. 7B, display screen 714, paragraph [0129]: “According to an aspect of the described embodiment herein, the wireless wallet application 108 running on the mobile phone 106 receives receipt related information, as shown in the display screen image 712, which according to an aspect of the embodiment is in the form of a barcode image on a computer display screen, as shown in a barcode image 714 displayed on the mobile phone display screen 106, after every successful purchase and stores these receipts on the mobile phone 106 for further reference and reuse (e.g., to be displayed on a display screen of the mobile phone wireless wallet 106 and read from the computer displayed barcode image by a barcode reader 315 to gain physical access to the paid service at a physical merchant service spot, such as a cinema point of sale (POS) 315). The transaction receipt related information could be remotely stored and retrievable...").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the receipt related information display as a barcode as disclosed by Labrou in the mobile device of Laracey and Gaddam, the motivation being to provide further reference and reuse (e.g., to be displayed on a display screen of the mobile phone wireless wallet and read from the computer displayed barcode image by a barcode reader to gain physical access to the paid service at a physical merchant service spot, such as a cinema point of sale) (see Labrou, paragraph [0129]).
Response to Arguments/Amendments
Double Patenting
Applicant’s amendments and arguments (see remarks, page 8, filed on 04/08/2026), with respect to the objections of claims 1 and 3-6 have been fully considered and are persuasive, therefore the rejection was withdrawn.
Claim rejections - 35 USC § 101
Applicant’s amendments and arguments (see remarks, pages 8-11, filed on 04/08/2026), with respect to the rejection of claims 1-7 under 35 USC § 101 as being directed to an abstract idea have been fully considered but are not persuasive. Applicant asserts “that claim 1 is not directed to a certain method of organizing human activity. Instead, claim 1 relates to a technical solution by reciting "a mobile device" with "a processing circuit comprising a processor coupled to a memory storing a client application," in which the processing circuit may perform operations...”. Examiner respectfully disagrees. With respect to arguments directed to structural characteristics of the "mobile device", Examiner notes this element was treated as an additional element, evaluated under steps 2A and 2B. With respect to the abstract idea grouping, Examiner respectfully disagrees. It appears Applicant places undue weight to the BRI of "enabling access...". The BRI of the limitation encompasses allowing (i.e. enabling) access to a resource (i.e. an application), which describes a commercial or legal interaction. Therefore, Examiner is unpersuaded by Applicant's arguments regarding the abstract idea grouping. Applicant further asserts “(the claimed features) are not features that can be practically performed in the human mind (e.g., an observation, evaluation, judgement, or opinion)”. Examiner respectfully disagrees. With respect to the abstract idea grouping under mental process, Examiner notes the claims further recite receiving multiple types of information, which is the equivalent of collecting information, grouped under mental processes. Receiving information is a concept that can be performed by the human mind or by pen and paper. Therefore, Examiner is unpersuaded by Applicant's arguments, especially in view of the Broadest Reasonable Interpretation of the claims clearly stated in the analysis. The amended claims do not offer significantly more than the abstract idea itself, therefore the claims are still rejected under 35 USC § 101 as further detailed above.
Claim rejections - 35 USC § 103
Applicant’s amendments and arguments (see remarks, pages 11-14, filed on 04/08/2026), with respect to the rejection of claims 1-7 under 35 USC § 103 have been fully considered , but are moot because the arguments do not apply to the reference being used in the current rejection of the amended claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Tippett (US 2012/0054491 A1) discloses re-authentication in client-server communications, including establishing a subsequent session without the need for re-sending credentials.
Hammad (US 2014/0074637 A1) discloses cloud-based virtual wallet NFC apparatuses, methods and systems, including generating a time-limited, session specific transaction bounding token.
Pierlot et al. (US 2008/0159318 A1) disclose system and method for extending sessions, including issuing a new session token.
Kumar et al. (US 2002/0169984 A1) disclose session management for wireless e-commerce, including generating respective wireless session identifiers upon receipt of initial requests from the wireless communication devices and provides the wireless session identifiers to an application program.
Fosmark et al. (US 9,642,005 B2) disclose secure authentication of a user using a mobile device, including a mobile device identifying a the session identifier (e.g. the identifier for the entity data processing system) from a message to find the user identifier associated with that entity data processing system from a previous registration.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDUARDO D CASTILHO whose telephone number is (571)270-1592. The examiner can normally be reached Mon-Fri 8-5.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698
Prosecution Insights