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 .
Information Disclosure Statement
The Information Disclosure Statements filed 02/05/2026 and 02/23/2026 have been considered. Initialed copies of the forms PTO-1449 are enclosed herewith.
Acknowledgements
This Office Action addresses the response filed on 02/10/2026.
Claims 1, 6 and 10 were amended.
Claim 11 was canceled.
Claims 1-10 and 12-14 are pending and were examined.
Broadest Reasonable Interpretation of the Amended Claims
The claims were amended on 02/10/2026 to recite the following language1:
PNG
media_image1.png
568
813
media_image1.png
Greyscale
Therefore, the claims were amended to substitute a “request message” to “information”, followed by the description of the “information”, i.e. “identifying… format…”. The description of the “information is considered non-functional descriptive material and is insufficient to modify the steps/functions of “receiving” and “determining”. In addition, it appears the non-functional descriptive material language attempts to further describe capabilities/non-capabilities of the sender (i.e. merchant server), by describing characteristics of a format that the server does not support. This language is insufficient to further limit the step/function of receiving information, as it merely describes what the information is not/does not comprise. In other words, the claims attempt to further limit received information by what the information could have been. This would be the equivalent of the real world analog of receiving a letter identifying a reply format supported by the sender (i.e. a printed return form), which is different form a data format that is not supported by the sender (i.e. telepathy). Therefore, the negative description of information contents is insufficient to further modify the step of “receiving”, as it recites what the mobile device processor did not receive. When looking at the newly introduced language reciting what is actually received (i.e. information), this is further described as a format that requires “counter information”. The claims, however, do not further rely on this “counter information” as part of the steps/functions later handled by the mobile device processor, therefore this language is also considered non-functional descriptive material, as it merely describes the “information”. Therefore, one of ordinary skill in the art would reasonably interpret the broadest reasonable interpretation of the steps/functions of “receiving” and “determining” as encompassing:
“receiving, by the mobile device processor via the receive/transmit circuitry from the merchant server, information identifying a data format;
determining, by the mobile device processor based on the received information identifying a data format, a particular mobile payment cardlet….”
Further, with respect to the function/step of generating, the claims require the generation of “an ISO format 1 response”, followed by a recitation of what the response “comprises” (i.e. a primitive data object with a tag equal to DEF). This language is directed to the description of the contents of a response. Specifically, while the response is further employed by the claims in the step/function of “transmitting”, the transitional term “comprising” is synonymous with “including,” “containing,” or “characterized by,” and is inclusive or open-ended and does not exclude additional, unrecited elements or method steps. Emphasis added. See, e.g., Mars Inc. v. H.J. Heinz Co., 377 F.3d 1369, 1376, 71 USPQ2d 1837, 1843 (Fed. Cir. 2004) and MPEP 2111.03. Since the transmitting step is based upon the data as a whole (i.e. ISO format 1 response), the language recited in the step/function of “generating” merely describes the contents of the message and are insufficient to differentiate a prior art method or apparatus requiring the generation and transmission of a response. While those are addressed in the claim rejections for compact prosecution purposes, this effort shouldn’t be understood as giving patentable weight to language that should be granted none.
Claim Objections
Claim 2 is objected to because of the following informalities: Claim 2 recites “the remote payment data”. Examiner interprets the language as remote payment data since “remote payment data” is not recited by the independent claims. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3, 4, 7, 8, 12 and 13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 3, 7 and 12 recite the language “the partial set of data inputs” in line 1. There is insufficient antecedent basis for this language in the claims. Examiner notes the language "partial set of data inputs" removed in the latest amendment raises a clarity issue in the dependent claims, as one of ordinary skill in the art would not be able to reasonably determine what the antecedent basis for "the partial set of data inputs" is. Dependent claims 4, 8 and 13 are also rejected since they depend on claims 3, 7 and 12, 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, 2, 5, 6, 9, 10 and 14 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Pirzadeh et al. (US 2011/0078081 A1), hereinafter Pirzadeh, in view of Hammad et al. (US 2016/0379101 A1), hereinafter Hammad.
With respect to claims 1, 6 and 10, Pirzadeh teaches payment-enabled mobile device operable to facilitate a payment transaction with a merchant server, comprising: an input/output device; receive/transmit circuitry; a memory; a secure element; and a mobile device processor operably connected to the input/output device, to the receive/transmit circuitry, to the memory and to the secure element; system for facilitating a payment transaction between a payment- enabled mobile device of a user and a merchant server comprising: a merchant server; and a payment-enabled mobile device operably connected to the merchant, the payment-enabled mobile device comprising a mobile device processor operably connected to an input/output device, receive/transmit circuitry, a memory, and a secure element; and a method for operating a payment-enabled mobile device to facilitate a payment transaction with a merchant server (Mobile payment application architecture) comprising:
receiving, by a mobile device processor of a payment-enabled mobile device via an input/output device from a user, a payment transaction request associated with purchasing at least one of a good or a service from a merchant (see Fig. 3, mobile payment application 304, UI 320, "User Interface application 320 enables a consumer to conduct a mobile payment transaction using mobile device 302 and may enable a payment processing network or issuer to perform certain data processing or data transfer operations that are part of managing the consumer's payment account using mobile device 302 and may enable a payment processing network or issuer to perform certain data processing or data transfer operations that are part of managing the consumer's payment account. In conducting a mobile payment transaction, user interface application 320 may provide a user interface to enable a consumer to conduct a payment application", paragraph [0054]; "user interface may be activated or otherwise made available to the consumer by means of a user interface or other method of permitting the consumer to perform an operation that launches or activates the mobile payment application or payment application user interface.", paragraph [0080]);
transmitting, in response to the payment transaction request by the mobile device processor via receive/transmit circuitry, a payment transaction initiation message directly to a merchant server of the merchant (see paragraph [0032]: "Contactless element 206 is capable of transferring and receiving data using a data transfer element which implements a near field communications capability 212, typically in accordance with a standardized protocol or data transfer mechanism (identified as ISO 14443/NFC in the figure). Near field communications capability 212 is a short-range communications capability; examples include the ISO 14443 standard, RFID, Bluetooth™, infra-red, or other data transfer capability that can be used to exchange data between the mobile device 202 and a device reader or point of sale terminal 230, which is typically located at a Merchant's place of business. Thus, mobile device 202 may be capable of communicating and transferring data and/or control instructions via both cellular network 222 and near field communications capability 212);
receiving, by the mobile device processor via the receive/transmit circuitry from the merchant server, information identifying ... a data format supported by the merchant server (see paragraph [0021]: "the inventive architecture provides a set of Application Protocol Data Unit interfaces (APDU, which are data packets exchanged between an applet and a host application that is executing the applet) for interaction with the payment application to enable that application to access and utilize the functionality of the architecture's modules as part of conducting a mobile payment transaction." paragraph [0022] In some embodiments, the inventive architecture" ; Paragraph [0058]: "Embodiments of the invention may provide one or more of the following ways to conduct a mobile contactless payment transaction using a contactless interface"; paragraph [0059]: "The manner in which a payment device reader and the consumer mobile device interact may depend on the capabilities of the reader"; paragraph [0060]: "After a mobile device capable of a contactless payment transaction is detected or otherwise discovered in the field, in some implementations the reader attempts to read the PPSE, which is a prioritized directory of supported payment applications accessible over the contactless interface. The device reader can indicate to the payment device what contactless payment transaction support modes are available (where either or both of MSD and qVSDC are typically supported)");
generating, by the mobile device processor using the particular mobile payment cardlet, an ISO format 1 response comprising a primitive data object with a tag equal to DEF; and (see paragraph [0060]: "Processing of a mobile payment transaction can then be determined by an appropriate data path within the inventive architecture (which may determine the behavior of the payment application (element 320 of FIG. 3) installed on and being executed by the mobile device). As noted, embodiments of the invention can support the MSD and qVSDC processing paths (among others) where the MSD path is for regions or device readers in which a magnetic stripe data is utilized to provide the device data and the qVSDC path is for regions or device readers in which an embedded chip is utilized to provide the device data"; [0061] In some embodiments, the following commands may be supported by the inventive architecture: [0062] Select (by name), as defined by ISO/IEC 7816-4 allows the selection of a particular payment application corresponding to a certain cardholder account which returns, among other information, the card's processing data object list. See also paragraph [0006]: "because of the growing interest in such cards, standards have been developed that govern the operation and interfaces for contactless smart cards, such as the ISO 14443 standard"); and
transmitting, by the mobile device processor via the receive/transmit circuitry, the ISO format 1 response to the merchant server to process the payment transaction. (see "Data read from the payment device is provided to the merchant's transaction processing system and then to the acquirer, which is typically a bank or other institution that manages the merchant's account. The data provided to the acquirer may then be provided to a payment processing network that is in communication with data processors that process the transaction data to determine if the transaction should be authorized by the network, and assist in the clearance and account settlement functions for the transaction. The authorization decision and clearance and settlement portions of the transaction may also involve communication and/or data transfer between the payment processing network and the bank or institution that issued the payment device to the consumer (the issuer).", paragraph [0004]; authorization message/settlement services, paragraph [0079]).
Although Pirzadeh discloses the selection of a particular payment application corresponding to a certain cardholder account which returns, among other information, the card's processing data object list (see paragraphs [0060]-[0063]), Pirzadeh does not explicitly disclose a method, mobile device and system comprising: the data format supported by the merchant server is an alternative data format supported by the merchant server that is different from a first data format that is not supported by the merchant server, wherein the alternative date format requires counter information and the first data format supports a full data cryptogram;. determining, by the mobile device processor based on the received information identifying the alternative data format, a particular mobile payment cardlet to utilize from a plurality of mobile payment cardlets available in a secure element of the payment-enabled mobile device.
While some of this language represents non-functional descriptive material and is therefore not given patentable weight, in the interest of compact prosecution and assuming weight was to be given to the non-functional descriptive material recitations above, Hammad discloses a method, mobile device and system (Dynamic authentication system and methods for use with legacy terminals) comprising:
the data format supported by the merchant server is an alternative data format supported by the merchant server that is different from a first data format that is not supported by the merchant server, wherein the alternative date format requires counter information and the first data format supports a full data cryptogram; (see paragraph [0021]: “In the EMV mode, the chip solution uses additional data elements including data from the terminal to calculate cryptographic values (cryptograms) that are intended to protect and secure the transaction but nevertheless require the development of a new path to deliver the additional data. It is for that reason that the EMV implementation requires more significant changes on the merchant and the acquirer infrastructure to support the EMV mode. The MSD mode uses what is usually being referred to as the dCVV (dynamic Card Verification Value) while the EMV mode uses the notion of the Cryptogram. The majority or the contactless infrastructure deployed in the US is based on the MSD mode and hence as the U.S. migrates to EMV, the payments infrastructure will need to continue to support contactless MSD for some period of time to allow acceptance of existing contactless cards and devices, while adding support for contactless ENW. Generally speaking, contactless EMV cards are also known as chip cards.”; paragraph [0028]: “In one embodiment, the present invention provides a method and communication device with an emulated mag stripe capability. Information is transmitted in the mag stripe data indicating that the communication device has chip capability as well. This information is used by a server on the back-end (acquirer, issuer, network) to take advantage of that chip capability. For example, additional fields can be used for security measures and communication over the telecommunications network with the device can be performed to provide a more secure communication with a terminal. In one embodiment, the additional information is provided in the service code, using a unique 3 digit code other than 2xx.”; See also paragraphs [0022]-[0027] for server capabilities. See provisional 62/186,166 paragraphs [004]-[011]).
determining, by the mobile device processor based on the received information identifying the alternative data format, a particular mobile payment cardlet to utilize from a plurality of mobile payment cardlets available in a secure element of the payment-enabled mobile device; (see paragraph [0045]: “User device 202 will receive the challenge from the telecommunication network (step 232). The received challenge will be provided to the payment application, which will then pull the requested data from memory, which may be in a secure element (step 234). Alternately, the challenge may require the dynamic generation of data. A response (236) is sent over telecommunication network 230 to issuer computer 206. Issuer computer 206 will then compare the response to the stored, appropriate answer (238). Issuer computer will then send an authorization message upon a favorable comparison (240). The authorization message will authorize a transaction if there's a match, otherwise an authorization fail message will be sent. Upon receiving the authorization message, merchant terminal 204 will indicate on a display or otherwise whether authorization was successful or failed (step 242).”; See provisional, 62/186,166, fig. 2, paragraphs [014]-[018]).
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 emulated mag stripe capability of the communication device as disclosed by Hammad in the method, mobile device and system of Pirzadeh, the motivation being to increase security by using additional fields for security measures and providing a more secure communication (see Hammad, paragraph [0028]).
With respect to the BRI of the claims, Examiner notes that claims 1, 6 and 10 recite “information identifying an alternative data format supported by the merchant server that is different from a first data format that is not supported by the merchant server, wherein the alternative date format requires counter information and the first data format supports a full data cryptogram”; “ISO format 1 response comprising a primitive data object with a tag equal to DEF”, language directed to non-functional descriptive material. See MPEP 2111.05.
With respect to claim 2, the combination of Pirzadeh and Hammad teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Pirzadeh discloses a method further comprising: packaging, by the merchant server, the remote payment data in an authorization response; and transmitting, by the merchant server, the authorization response to an acquirer financial institution (see paragraph [0004]: “Consumer payment devices are used by millions of people worldwide to facilitate various types of commercial transactions. In a typical transaction involving the purchase of a product or service at a merchant location, the payment device is presented at a point of sale terminal ("POS terminal") located at a merchant's place of business. The POS terminal may be a card reader or similar device that is capable of accessing data stored on the payment device, where this data may include identification or authentication data, for example. Data read from the payment device is provided to the merchant's transaction processing system and then to the acquirer, which is typically a bank or other institution that manages the merchant's account. The data provided to the acquirer may then be provided to a payment processing network that is in communication with data processors that process the transaction data to determine if the transaction should be authorized by the network, and assist in the clearance and account settlement functions for the transaction. The authorization decision and clearance and settlement portions of the transaction may also involve communication and/or data transfer between the payment processing network and the bank or institution that issued the payment device to the consumer (the issuer).”). 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 claims 5, 9 and 14, the combination of Pirzadeh and Hammad teaches all the subject matter of the method, mobile device and system as described above with respect to claims 1, 6 and 10. Furthermore, Hammad discloses a method, mobile device and system wherein the mobile payment cardlet is personalized such that at least an Application Primary Account Number (PAN) and an Application PAN sequence number are returned in a command response (see Fig. 4A, paragraph [0049]: “FIG. 4A illustrates a sample mag stripe track 2 layout, as modified by an embodiment of the present invention. A PAN field 402 includes the Primary Account Number, or a token. This is followed by an expiration date field 404. Next is a 3 digit service code 406. In one embodiment, the service code begins with a 3, or another number other than 1 or 2. Alternately, the last two digits of the service code can be used to indicate chip capability. Issuer discretionary data field 408 follows. This includes a dCVV, APC, or other dynamic value.”; (see fig. 4A of provisional Application)).
Claims 3, 4, 7, 8, 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Pirzadeh (US 2011/0078081 A1), in view of Hammad (US 2016/0379101 A1), and in view of Hayhow (US 2015/0073995 A1).
With respect to claims 3, 7 and 12, the combination of Pirzadeh and Hammad teaches all the subject matter of the method, mobile device and system as described above with respect to claims 1, 6 and 10. The combination of Pirzadeh and Hammad does not explicitly teach a method, mobile device and system wherein the partial set of data inputs includes at least a first data field set to a default value.
However, Hayhow discloses a method, mobile device and system (System and method for authorizing a financial transaction) wherein the partial set of data inputs includes at least a first data field set to a default value (see format comprises the predetermined authorization amount which is hexadecimal zero, paragraph [0044]).
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 alternative response generation technique as disclosed by Hayhow in the method, mobile device and system of Pirzadeh and Hammad, the motivation being to allow processing of a transaction when the actual authorization amount is unknown at first (see Hayhow, paragraph [0044]). Regarding the BRI of the claims, Examiner notes that claims 3, 7 and 12 recite “wherein the partial set of data inputs includes at least a first data field set to a default value”, 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 claims 4, 8 and 13, the combination of Pirzadeh, Hammad and Hayhow teaches all the subject matter of the method, mobile device and system as described above with respect to claims 3, 7 and 12. Hayhow further discloses a method, mobile device and system (System and method for authorizing a financial transaction) wherein the default value is zero (see format comprises the predetermined authorization amount which is hexadecimal zero, paragraph [0044]). Regarding the BRI of the claims, Examiner notes that claims 4, 8 and 13 recite “wherein the default value is zero”, 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.
Response to Arguments/Amendments
Claim Objections
Applicant’s amendments and arguments (see remarks, page 9, filed on 02/10/2026), with respect to the objection have been fully considered. Examiner finds Applicant's arguments persuasive in view of the submitted amendments, therefore the objection was withdrawn.
Claim rejections - 35 USC § 101
Applicant’s amendments and arguments (see remarks, pages 10-20, filed on 02/10/2026), with respect to the rejection of claims 1-10 and 12-14 under 35 USC § 101 as being directed to an abstract idea have been fully considered. Examiner finds Applicant's arguments persuasive in view of the submitted amendments, therefore the rejection was withdrawn. Examiner agrees with Applicant's arguments regarding step 2A, prong two as described in pages 18-20. The rejection under 35 USC § 101 has been withdrawn in view of the claim amendments.
Claim rejections - 35 USC § 112(a)
Applicant’s amendments and arguments (see remarks, pages 9 and 10, filed on 02/10/2026), with respect to the rejection of claims 1-10 and 12-14 under 35 USC § 112(a) have been fully considered. Examiner finds Applicant's arguments persuasive in view of the submitted amendments, therefore the rejection was withdrawn.
Claim rejections - 35 USC § 103
Applicant’s amendments and arguments (see remarks, pages 21-26, filed on 02/10/2026), with respect to the rejection of claims 1-10 and 12-14 under 35 USC § 103 have been fully considered , but are moot because the arguments do not apply to the references being used in the current rejection of the amended claims.
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 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
1 Exemplary claim 1
Prosecution Insights