Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
DETAILED ACTION
Applicant filed an amendment on 1/20/26. Claims 1-20 were pending. Claims 1 and 11 have been amended, claims 4-5 and 14-15 have been canceled. Thus claims 1-3, 6-13, and 16-20 are pending. After careful consideration of applicant amendment, the examiner finds them to be moot in view of new grounds of rejection. This action is a Final Rejection.
Claim Objections
Claims 1, 9, 10,11, 19 and 20 are objected to because of the following informalities: see below. Appropriate correction is required.
Claims 1, 9, 10, 11 and 19,20 as argued and amended highlight the cryptogram and the initial cryptogram. However, “an initial cryptogram” is followed by the initial cryptogram, then a cryptogram…. Then the cryptogram, and in claim 9 the cryptogram. After the initial cryptogram, the cryptogram is based on the initial cryptogram. However, there is no explanation of “based on” and thus, as claimed there are basically cryptograms. Applicant should clarify the relationship between the initial and the cryptogram since they are based on each other but, no Distington is made. Further the initial cryptogram appears to not be used beyond creating the cryptogram.
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-3,6-13,16-20 are rejected under 35 U.S.C. 101 because they are directed to an abstract idea without more rejected
Claims 1, 11 are independent and of acceptable statutory classes, ie method and computer of an issuer which is interpreted as a system.
Claims 1 contains the following abstract elements;
receiving, by an issuer … of an issuer, an authorization request message for a payment transaction between a payment device and a merchant,
wherein the authorization request message includes data presented to a … of the merchant from the …, the data identifying a payment account issued by the issuer,
wherein the … includes a contactless element that communicates and transfers data using a wireless communications technology, and a memory that stores a payment application; after completion of the payment transaction between the … and the merchant, determining, by the …, that an issuer update is required for the payment device;
wherein the issuer update includes one or more of configuring a function of the …, enabling a function of the …, or disabling a function of …;
receiving, by the …, an initial cryptogram from …; generating, by the … based on the initial cryptogram, a cryptogram for confirming an authenticity of the issuer; and transmitting, by the …, the cryptogram and an issuer update message to the …., wherein the issuer update message includes a script or a command to be executed on the ….
The technical elements include “issuer computer”, “payment device”, and by amendment, “device reader”
Here conducting a payment transaction between an issuer computer and payment device with a device reader amounts to no more than mere instructions to “apply” the exception to using a generic computing component. The additional elements when considered separately or as an ordered combination do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea without a practical application. Thus the claimed elements are not integrated into a practical application. The claims do not include elements that are sufficient to amount to significantly more, known as inventive concept to the exception as discussed above with respect to integration into a practical application. Applicant specification contains server computers, wireless networks and web servers, 0036, in regards to 0070, it appears that the computing elements might be generic.
The dependent claims 2,3,6-10,12-13,16-20 are rejected because they do not directly add more to the abstract idea. However, it is noted that claims 9, and 2 may contain some additional elements that might in combination with a more technical claim recitation become eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3,6-13, 16-20 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over
US Patent Publication 20080082452 to Wankmueller in view of US Patent to Bishop 9031800.
As per claim 1 Wankmueller discloses; A method of conducting a payment transaction, comprising:
receiving, by an issuer computer of an issuer,
an authorization request message for a payment transaction between a payment device and a merchant, W(0075-6) wherein the authorization request message includes data presented to a device reader of the merchant from the payment device, the data identifying a payment account issued by the issuer, wherein (0018, 0042, 0056 the account holder verification requires a payment account number)
wherein the payment device includes a contactless element W(0076)
that communicates and transfers data using a wireless communications technology,
and a memory that stores a payment application; after completion of the payment transaction between the payment device and the merchant,
) receiving, by the issuer computer, W(0009-12, issuer update is basically where the issuer is contacted to check balance or verify the card) an initial cryptogram from payment device; generating, by the issuer computer based on the initial cryptogram, a cryptogram for confirming an authenticity of the issuer; and transmitting, by the issuer computer, the cryptogram and an issuer update message to the payment device. W(0062, 0083) wherein the issuer update message includes a script or a command to be executed on the payment device.
W(0042, or is a choice of one)
Here Wankmueller does not explicitly disclose an issuer update message which Bishop teaches;
determining, by the issuer computer, that an issuer update is required for the payment device;
wherein the issuer update includes one or more of configuring a function of the payment device, enabling a function of the payment device, or disabling a function of the payment device
( “or” is a choice)
Bishop(Col. 23 lines 10-25, , provide instructions to update the transaction device… it can be in real time… for the next transaction)
It would therefore have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine the payment technologies of Wankmueller with the updating features of Bishop for the motivation of “managing multiple types of accounts” (col. 1 lines 45-50)
Claim 11 is similar to claim 1.
As per claims 2,12 Wankmueller discloses; The method of claim 1, wherein performing the issuer update further includes one or more of setting a value of a counter, accessing data stored in the payment device, updating a payment application on the payment device or resetting the payment application on the payment device. Wankmueller(or is a choice of one broadly, 0088, counter)
As per claims 3, 13, Wankmueller discloses;
The method of claim 1, wherein the issuer update is performed to complete the payment transaction. Wankmueller(fig. 1 S110)
As per claims 6, 16 Wankmueller discloses;
The method of claim 1, wherein the payment device includes a mobile communication device.
W(0056)
As per claims 7, 17 Wankmueller discloses; The method of claim 1, wherein the authorization request message includes data presented to a device reader of the merchant from the payment device, the data identifying a payment account issued by the issuer.
W(0056)
As per claims 8, 18 Wankmueller discloses;
The method of claim 1, further comprising: processing the payment transaction using a payment account issued by the issuer; generating an authorization response message including a result of processing the payment transaction; and transmitting the authorize response message to the merchant.
W(0023)
As per claims 9, 19, Wankmueller discloses; The method of claim 1, wherein the cryptogram and the issuer update message are transmitted to the payment device through a wireless communications network. W(0057)
As per claims 10,20 Wankmueller discloses; The computer of claim 11, wherein the cryptogram and the issuer update message are transmitted to the payment device via a device reader of the merchant.
W(0062-3)
Response to Arguments
Applicant filed an amendment on 1/20/26. Claims 1-20 were pending. Claims 1 and 11 have been amended, claims 4-5 and 14-15 have been canceled. Thus claims 1-3, 6-13, and 16-20 are pending. After careful consideration of applicant amendment, the examiner finds them to be moot in view of new grounds of rejection. This action is a Final Rejection.
Claims 1-3,6-13, 16-20 are rejected under 35 U.S.C. § 101 for allegedly being directed to non- statutory subject matter.
Prong 1 of the Step 2A
According to the January 2019 Guidance, under Prong 1 of the Step 2A analysis, the Examiner is first required "to identify the specific limitation(s) in the claims... that... recite an abstract idea." The Examiner is then required to determine whether those identified limitations fall within the subject matter grouping of abstract ideas enumerated in Section I of the guidelines.
Applicant notes the Office Action fails identify the subject matter grouping of abstract ideas enumerated in Section I of the 2019 guidelines.
Applicant submits that in prong one of step 2A, as indicated in the "Reminders on Evaluating Subject Matter Eligibility of Claims under 35 USC 101" dated August 4, 2025 (hereinafter "Reminders Memo", which is directed to technology centers 2100, 2600 and 3600, a claim does not recite a mental process when it contains limitation(s) that cannot practically be performed in the human mind, for instance when the human mind is not equipped to perform the claim limitation(s).
Specifically the feature of "generating a cryptogram for confirming an authenticity of the issuer" sending the issuer update is clearly not a human activity or a commercial interaction. Human analog cannot transmit a cryptogram and scripts to the payment device through a communication network. For example, the human analog cannot simply communicate with a device in a room by wirelessly communicating with the device. The only way a human analog
can detect the presence of a device is by seeing/touching the device, which does not use a wireless communication technology. Similarly, the human analog cannot transmit an issuer update to the device and execute a script on the device to configure a function of the payment device. In addition, the human analog cannot create and transmit a cryptogram to the device. These steps simply cannot be practically performed in the human mind or by a human analog. Accordingly, Applicant submits that the claimed limitations cannot practically be performed in the human mind.
Here arguments that a process cannot be performed “in the human mind” are not persuasive if they might be performed in this manner impractically. Thus even though it’s not realistic, it might be theoretically possible.
Prong 2 of the Step 2A
In prong two of step 2A, we look to whether the claims as a whole are integrated into a practical application.
A claim is not "directed to" a judicial exception if the judicial exception is integrated into a practical application of that exception. See 2019 PEG.
As indicated in the October 2019 Subject Matter Eligibility update:
An important consideration to evaluate when determining whether the claim as a
whole integrates a judicial exception into a practical application is whether the claimed invention improves the functioning of a computer or other technology. The courts have
not provided an explicit test for this consideration. However, MPEP 2106.04(a) and
2106.05(a) provide a detailed explanation of how to perform this analysis. In short,first
the specification should be evaluated to determine if the disclosure provides sufficient
details such that one of ordinary skill in the art would recognize the claimed invention as
providing an improvement. The specification need not explicitly set forth the
improvement, but it must describe the invention such that the improvement would be
apparent to one of ordinary skill in the art. Conversely, if the specification explicitly sets
forth an improvement but in a conclusory manner (i.e., a bare assertion of an
improvement without the detail necessary to be apparent to a person of ordinary skill in
the art), the examiner should not determine the claim improves technology. Second, if the
specification sets forth an improvement in technology, the claim must be evaluated to
ensure that the claim itself reflects the disclosed improvement. That is, the claim includes
the components or steps of the invention that provide the improvement described in the
specification. The claim itself does not need to explicitly recite the improvement
described in the specification (e.g., "thereby increasing the bandwidth of the channel").
Here, the functionality should be highlighted in the claim, ie in this case increasing bandwith for example.
As indicated in the Reminders Memo, the analysis in Step 2A Prong Two considers the claim as a whole. The way in which the additional elements use or interact with the exception may integrate the judicial exception into a practical application. Accordingly, the additional limitations should not be evaluated in a vacuum, completely separate from the recited judicial exception.
Practical application arguments are generally not persuasive for a business method type process. In this case credit card approval or authorization could have been done manually. Adapting it to a computer does not necessarily overcome 35 USC 101.
Further, in computer-related technologies, examiners can conclude that claims are eligible in Step 2A Prong Two by finding that a claim reflects an improvement to the functioning of a computer or to another technology or technical field, integrating a recited judicial exception into a practical application of the exception. The examiner is reminded to consult the specification to determine whether the disclosed invention improves technology or a technical field, and evaluate the claim to ensure it reflects the disclosed improvement. The specification does not need to explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art. The claim itself does not need to explicitly recite the improvement described in the specification.
Examiners are reminded that if it is a "close call" as to whether a claim is eligible, they should only make a rejection when it is more likely than not (i.e., more than 50%) that the claim is ineligible under 35 U.S.C. 101. A rejection of a claim should not be made simply because an examiner is uncertain as to the claim's eligibility. In order to make a rejection of a claim under any of the statutory bases (i.e., 35 U.S.C. 101, 102, 103, 112), unpatentability must be established by a preponderance of the evidence.
Applicant submits the specification describes the invention such that the improvement would be apparent to one of ordinary skill in the art.
According to embodiments of the claimed invention, an issuer computer performs an
issuer update on a payment device. The method according to embodiments of the invention may include a pre-tap operation where a payment device is tapped to a terminal, a consumer interaction responsive to the pre-tap operation, a subsequent payment tap operation involving the payment device and the terminal, and an issuer update on the payment device to complete the payment transaction. As explained at paragraph [0058] of the present application, the issuer update may occur by requesting that the user tap the payment device to the terminal once more. Conventional systems directed to processing payment transactions are not concerned with providing issuer updates to the payment device.
According to the embodiments of the present application, when the payment device
interacts with the device reader, it is determined whether an issuer update is desired. An issuer update is a process requested or required by an issuer in which data is provided by the issuer
Here the examiner is not persuaded that this invention is a close call. In regards to the pretap and post tap, these elements are not claimed. Also the invention is not an improvement of the computer technology.
(such as an update or correction to transaction data, for example), or a script is provided by the issuer for execution by the device reader, the payment application installed on the payment device, or the payment device. If the issuer update involves the issuer providing data, then the data may be for the purpose of updating, synchronizing or reconciling an account record stored in the payment device. In such a case, the device reader or POS terminal may be used to transfer the data to the payment device by communication using the near field communications or another short range communications capability. If the issuer update involves communication of a command or script that causes execution of an operation on or by the payment application or payment device, then the command or script may be transferred to the device reader or POS terminal and executed by the device reader or POS terminal. The command or script may be for the purpose of setting or re-setting a counter, configuring or re-configuring a function of the payment application or payment device, or updating software on the device, for example. See Specification, [0057].
Here the link to a short range communication capacity may not necessarily overcome a rejection by tying the invention to another field.
In addition, the issuer generates a cryptogram to authenticate or otherwise identify the issuer, and/or to provide a means for associating the transmitted data with the appropriate transaction record that is stored in the payment device. The issuer provided data, command, instruction, script, or other form of information is received by the payment device and may be used to update transaction data stored in the payment device or cause the execution of a function or operation by the payment application or the payment device, for example. In the case of a function or operation being executed, the function or operation may be executed by the device reader or POS terminal, by the payment application, or by the payment device. See Specification, [0058]. Thus, the claimed invention ensures that the payment application stored on the payment device is up-to-date with issuer requirements and/or data. This is an important practical application given the rise in fraud, security hack and identity theft.
Further, the claims reflect the disclosed technical improvement. For example, claim 1 recites:
Here some concerns with the cryptogram/initial cryptogram were identified by objection. It’s not clear that using a cryptogram would be sufficient.
receiving, by an issuer computer of an issuer, an authorization request message for a payment transaction between a payment device and a the authorization request message includes data presented to a devic merchant from the payment device, the data identifying a payment account issued by the
issuer, wherein the payment device includes a contactless element that communicates and
transfers data using a wireless communications technology, and a memory that stores a
payment application;
after completion of the payment transaction between the payment device and the merchant, determining, by the issuer computer, that an issuer update is required for the payment device, wherein the issuer update includes one or more of configuring a
function of the payment device, enabling a function of the payment device, or disabling a
function of the payment device;
receiving, by the issuer computer, an initial cryptogram from payment device;
generating, by the issuer computer based on the initial cryptogram, a cryptogram for confirming an authenticity of the issuer; and
transmitting, by the issuer computer, the cryptogram and an issuer update message to the payment device, wherein the issuer update message includes a script or a
command to be executed on the payment device.
Applicant submits that the claims, when taken as a whole, recite features that improve the functioning of user devices as payment device that is used in contactless payments. For proper and secure functioning of the user device as a payment device, the device needs to be updated regularly. The claims recite a method for providing an issuer update to the payment device that is presented to a device reader of a merchant upon completing a transaction between the payment
device and the merchant. As further provided in Ex Parte Desjardins, Appeal No. 2024-000567 (PTAB September 26, 2025, Appeals Review Panel Decision) (precedential) "Examiners and panels should not evaluate claims at such a high level of generality" that potentially meaningful technical limitations are dismissed without adequate explanation. See revisions to the fourth and
fifth paragraphs of MPEP §2106.05(a).
Here the functioning of the devices is not improved but the payment process is approved.
Furthermore, the provision of an issuer update to a payment device problem only exists in the network communications of computers. This is not a problem that occurs within a "brick and
mortar" context, as identified in DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014). In DDR, the court identified that problem related to network communications, and since there would not a "brick and mortar" equivalent to the problem, the court deemed the claim not to be directed to an abstract idea. In a "brick and mortar" context, the interaction is betweenPage 11 of 15
people, and an issuer update may be provided on the transaction device by the user bringing the transaction device to the issuer's location. The issuer may then update the information on the transaction device. The transaction device may not be used before the issuer update is applied.
The technical problem is the transmission of the issuer update to the payment device
without requiring the payment device to be physically present at the issuer location. The relevant issue is here not whether or not an issuer update is provided, but how is ensured or provided that the issuer update reaches the payment device.
To address this technical problem, embodiments a technical solution that enables an
Issuer to provide a consumer payment device containing a contactless element with transaction data or to initiate an update process, without requiring that a consumer maintain communication between the payment device and a device reader or terminal for an extended period of time.
These features do not address a challenge in business as the problem is not whether the
issuer update is provided to the user. Rather, Applicant's claimed features recite a solution to the technical problem of communicating an issuer update to a payment device without requiring the physical presence of the payment device at issuer location.
The claims therefore clearly provide for an "application" that is "practical." As such, any alleged abstract idea is clearly "integrated into a practical application" and the claims are also be patent eligible under Step 2A - Prong 2.
DDR was directed to an improvement in software technology which is not the case here.
Step 2B
Applicant further submits that the claim elements clearly "add[] a specific limitation other than what is well-understood, routine and conventional in the field" or "add[] unconventional steps that confine the claim to a particular useful application." As explained in Berkheimer v. HP Inc. (Appeal No. 2017-1437) (Fed. Cir. 2018):
The second step of the Alice test is satisfied when the claim limitations "involve more than performance of 'well understood, routine, [and] conventional activities previously known to the industry."' Content Extraction, 776 F.3d at 1347-48 (quoting Alice, 134 S. Ct. at 2359). The question of whether a claim element or combination of elements is well-understood, routine and conventional to a skilled artisan in the relevant field is a question of fact. Any fact, such as thisPage 12 of 15
one, that is pertinent to the invalidity conclusion must be proven by clear and convincing
evidence. See Microsoft Corp. v. i4i Ltd. P'ship, 564 U.S. 91, 95 (2011)....
Here, the claims involve more than performance of "well understood, routine, [and] conventional activities previously known to the industry."
The foregoing features of Applicant's claim 22 are not conventionally used in providing an issuer update to the payment device. Conventional systems may eventually provide (update) information reflecting the transaction to the user of the payment device. Such information is provided in the conventional way of providing a statement of account, typically in paper form, summarizing the transaction together with other transactions, e.g., occurring during a month's time. Other type of issuer updates may require the payment device to be physically present at the issuer location.
The transmission of the issuer update using wireless communication technologies also need to overcome the additional technical problem of the communication time. For example, in the case of a transaction that uses a contactless element, a device reader or point of sale terminal is typically expected to be in communication with the contactless element for only a short period of time; for example, enough time for it to be recognized by the reader and to provide data needed to initiate or conduct a portion of the transaction. However, this means that the consumer payment device and device reader or point of sale terminal may not be in communication long enough for an issuer or payment processor to process the transaction data and provide the processed data to the device reader for transfer to the consumer device. It may also mean that the payment device and device reader or terminal are not in communication when the Issuer or payment processor desires to perform an update to cause a command or function to be executed on the payment device, such as for resetting a counter, configuring a function of the payment application or payment device, etc. Specification, [0009]. Another issue for a payment transaction system or process in which data or a configuration command or instruction is provided by an issuer or payment processor involves ensuring that the received data, command, or instruction is from an authorized party, and that the payment device properly associates the received information with the transaction or application to which the information applies. See Specification, [0010].
At least the combination of these limitations forms an "inventive concept" and hence constitutes "significantly more" under Step 2B. For at least these reasons, the Applicant respectfully requests withdrawal of the § 101 rejection of the pending claims.
Here inventive concept is in the eyes of the interpreter and in this case inventive concept should be an improvement in the technology itself.
§ 102 Rejections
Applicant respectfully submits that Wankmueller fails to disclose
(1) after completion of the payment transaction between the payment device and the merchant, determining, by the issuer computer, that an issuer update is required for the payment device, wherein the issuer update includes one or more of configuring a function of the payment device, enabling a function of the payment device, or disabling a function of the payment device; (2) receiving, by the issuer computer, an initial cryptogram from payment device; (3) generating, by the issuer computer based on the initial cryptogram, a cryptogram for confirming an authenticity of the issuer; and
(4) transmitting, by the issuer computer, the cryptogram and an issuer update message to the payment device, wherein the issuer update message includes a script or a command to be executed on the payment device,
as recited in Applicant's amended claim 1.
In the Office Action, the Examiner asserts "the issuer update is basically where the issuer is contacted to check balance or verify the card." Applicant submits that the amendments to claims 1 and 11 clarify the issuer update as including "a script or a command to be executed on the payment device".
Accordingly, the Examiner's interpretation of the term is no longer applicable.
Wankmueller is entirely silent about the issuer (of the account) generating a cryptogram authenticating the issuer, based on a cryptogram provided by the payment device, that will be sent to the payment device along with the issuer update to prove that the update the coming from the genuine issuer, and the payment device can trust and execute the issuer update.
Here in regards to issuer generating a cryptogram, see 0063. However, in regards to issuer update message, the examiner offers Bishop rendering applicant argument to be generally moot in view of updated grounds of rejection. This action is a Final Rejection.
Conclusion
Mobile phone based RFID architecture for secure electronic Payments using RFID credit cards IEEE 2007
Mobile Payment Solution — Symbiosis Between Banks, Application Service Providers and Mobile Network Operators, IEEE, 2009
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 BRUCE I EBERSMAN whose telephone number is (571)270-3442. The examiner can normally be reached 8:00 am - 5:00 pm Monday-Friday.
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, Michael W Anderson can be reached at 571-270-0508. 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.
/BRUCE I EBERSMAN/Primary Examiner, Art Unit 3693