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 .
Response to Amendments / Arguments
Regarding the rejection(s) of claims under 35 USC 103:
Applicant argues that the Examiner's stated motivation to "enable secure delegation of tokens" is conclusory under KSR, and that routing tokens through Wang's intermediary merchant servers would introduce points of compromise rather than improve security. This argument is unpersuasive, because there was a stated reason in the combination, and the rebuttal that security would be “degraded” is an unsupported argument without any evidence. Further, applicant’s asserted disadvantage is true for literally everything in the world (every computer is a point of compromise, communicating with other devices is a point of compromise and increases attack surface, walking outside or going to the grocery store increases your attack surface and probability of being mugged) but, as in the case with real life, there are advantages and disadvantages to everything. And, in this case, the examiner found the advantages would lend a person of ordinary skill in the art to make the proposed modification.
Applicant argues that the alternative update flow of [0087]–[0089] cannot supply the missing limitation because the account holder must be notified and must physically present the card to an ATM or phone to receive the replacement token. This argument is unpersuasive, because "automatically without intervention of the user" modifies the server's transmission of the provisioning request message, not the downstream delivery of the token to the card. In Lopez, the notification and transmission at S352 and S362 occur without user action, and the user becomes involved only later at S366; further there is [0082], where the authorization computer requests periodic token updates decoupled from any transaction.
Applicant argues that Lopez's second token exists so the user can read it off the display and key it in for e-commerce ([0008], [0037], [0043]), so auto forwarding it to a cloud server would leave no reason for it to be displayable. This argument is unpersuasive, because Lopez's principle of operation is replacing a compromised token without reissuing the physical card, and that principle survives the proposed modification intact. Adding a forwarding path neither disables the display nor renders Lopez unsuitable for its stated purpose.
Applicant argues that S352 falls inside the authorization flow, between the authorization request (S344/S346) and the authorization response (S354), so the transaction remains unresolved and has therefore not been "conducted." This argument is unpersuasive, because it rests on an unstated construction equating "conducted" with "authorized, declined, or completed," and applicant cites no support for that narrowing. Under the broadest reasonable interpretation, the transaction is conducted when the account holder presents the card and initiates it at S342, which precedes S352.
Applicant argues that the Examiner cited Wang ¶[0091] merely for the phrase "future transactions," which does not carry the automated, periodic character of a recurring transaction. This argument is persuasive.
Applicant argues that Wang's first and second entity computers are a social networking site and a third-party merchant, so Wang never teaches a server providing a token to an application on a mobile phone that then passes it to a cloud server computer for future transactions. This is persuasive, therefore the rejection is withdrawn.
On further review the full rejection is withdrawn and now are being further rejected under Kinagi (US 20180006821 A1, referred to as Kinagi) in view of Wouters et al. (US 20190066096 A1, referred to as Wouters), in view of Spector et al. (US 10878407 B1, referred to as Spector).
DETAILED ACTION
This is a reply to the arguments filed on 09/02/2025, in which, claims 1, 5-11, 13-16, and 21-26 are pending. Claims 1, and 13 are independent. Claims 2-4, 12 and 17-20 have been cancelled.
When making claim amendments, the applicant is encouraged to consider the references in their entireties, including those portions that have not been cited by the examiner and their equivalents as they may most broadly and appropriately apply to any particular anticipated claim amendments.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 03/25/2026, 06/16/2026 and 08/21/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
Claims 1, 5-11, 13-16, and 21-26 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.
Claim 1 recites "transmitting, by the server computer to the first token requestor, a cryptogram, wherein the first token requestor uses the first token and the cryptogram to conduct a transaction with a point of sale terminal." The recited act is complete when the server computer transmits the cryptogram; what the first token requestor thereafter does with the cryptogram does not change the set of acts by which the transmitting step is performed. It therefore cannot be determined whether the recited use at a point of sale terminal is required for the method to be practiced.
To overcome this rejection, Applicant should recite the use of the cryptogram at the point of sale terminal as a separate, positively recited step of the method if that act is required, or delete the clause if it is not.
Claim 1 recites "providing, by the server computer, a second token to an application on the first token requestor, wherein the application provides the second token to a second token requestor so that the second token requestor stores the second token to conduct future transactions, and then performs another transaction using the second token." The recited act is complete when the server computer provides the second token to the application; the subsequent acts of the application and the second token requestor do not change the set of acts by which the providing step is performed, and "so that the second token requestor stores the second token" recites an intended result rather than a required act. The ambiguity is not hypothetical, as Applicant argues this clause imposes a required limitation while the structure of the claim indicates it does not.
To overcome this rejection, Applicant should recite the acts of the application and the second token requestor as separate, positively recited steps of the method if those acts are required, or delete the clause if they are not.
Claim 1 recites "and then performs another transaction using the second token." It cannot be determined which entity performs this act, as the recitation may refer to the second token requestor, the application, or the first token requestor. It is further unclear whether "another transaction" is one of the previously recited "future transactions" or a transaction in addition to them.
To overcome this rejection, Applicant should identify the entity performing this act and clarify whether the recited transaction is one of the previously recited future transactions.
Claim 1 recites "the first token" in the transmitting step. No token has been previously recited; a first token is first introduced two steps later, in "the second token being associated with a first token stored in the first token requestor." Because there is no antecedent basis for "the first token," it cannot be determined whether the two recitations refer to the same token.
To overcome this rejection, Applicant should introduce "a first token" before its first use, or amend the later recitation to "the first token."
Claim 1 recites "after the transaction is conducted and automatically without intervention of the user, transmitting, by the server computer, a provisioning request message." The only antecedent for "the transaction" appears in the wherein clause addressed in paragraph 1 above, the limiting effect of which cannot be determined. It therefore cannot be determined whether the claim requires that a transaction be conducted at all, or at what point in time the provisioning request message must be transmitted.
To overcome this rejection, Applicant should positively recite the conducting of the transaction as a step of the method, so that "the transaction" has proper antecedent basis and the timing of the transmitting step is ascertainable.
Claim 13 is further rejected under the same rationale.
Dependent claims inherit the rejections of the independent claims.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 5-11, 13-16, and 21-26 are rejected under 35 U.S.C. 103 as being unpatentable over Kinagi (US 20180006821 A1, referred to as Kinagi) in view of Wouters et al. (US 20190066096 A1, referred to as Wouters), in view of Spector et al. (US 10878407 B1, referred to as Spector).
In reference to claim 1, A method comprising: receiving, by a server computer a cryptogram request message from a first token requestor (Kinagi: [0036], [0046] and [0075]-[0077] Provides for a server computer (tokenization computer 170) receiving a request message from a requesting device, where the direct and expressly disclosed consequence of receipt is generation of a cryptogram.)
Wherein the first token requestor is a mobile phone operated by a user (Kinagi: [0021], [0052]-[0053] and [0070]-[0072] Provides for the requesting entity being a smartphone in the physical possession of and operated by user 110, expressly a mobile phone.)
responsive to receiving the cryptogram request message, transmitting, by the server computer to the first token requestor, a cryptogram, wherein the first token requestor uses the first token and the cryptogram to conduct a transaction with a point of sale terminal (Kinagi: [0042] and [0071]-[0082] Provides for the server's transmission of the cryptogram being triggered by and responsive to the request, and for the mobile device then conducting a payment transaction at a POS terminal using both the token and the cryptogram together.)
Kinagi doesn't explicitly teach after the transaction is conducted and automatically without intervention of the user, transmitting, by the server computer, a provisioning request message to an authorizing entity computer, receiving, by the server computer, a provisioning response message from the authorizing entity computer, providing, by the server computer, a second token to an application on the first token requestor, wherein the application provides the second token to a second token requestor so that the second token requestor stores the second token to conduct future transactions, and then performs another transaction using the second token, the second token being associated with a first token stored in the first token requestor, and wherein the second token requestor is an application server associated with the application, and the first token and the second token are associated with a credential. However, Wouters discloses:
after the transaction is conducted and automatically without intervention of the user, transmitting, by the server computer, a provisioning request message to an authorizing entity computer (Wouters: [0039]-[0041] Provides for the server (TSP 308) sending a digitization/provisioning request to the issuer, the authorizing entity, triggered by account use, expressly without the user's knowledge or participation.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Kinagi, which provides a method for receiving cryptogram requests from user-operated mobile phones and transmitting cryptograms that are used with tokens to conduct point-of-sale transactions, with the teachings of Wouters, which introduces automatically transmitting a provisioning request message to an authorizing entity computer after a transaction is conducted without user intervention. One of ordinary skill in the art would recognize the ability to incorporate Wouters's post-transaction automatic provisioning trigger into Kinagi's cryptogram-based transaction system to enable seamless token lifecycle management. One of ordinary skill in the art would be motivated to make this modification in order to streamline the token provisioning process by automatically initiating new token requests based on transaction activity without requiring additional user action.
Kinagi in view of Wouters doesn't explicitly teach receiving, by the server computer, a provisioning response message from the authorizing entity computer, providing, by the server computer, a second token to an application on the first token requestor, wherein the application provides the second token to a second token requestor so that the second token requestor stores the second token to conduct future transactions, and then performs another transaction using the second token, the second token being associated with a first token stored in the first token requestor, and wherein the second token requestor is an application server associated with the application, and the first token and the second token are associated with a credential. However, Wouters discloses:
receiving, by the server computer, a provisioning response message from the authorizing entity computer (Spector: Col. 8 Lines 50-65, Col. 6 lines 44-50 and Fig. 3 Provides for the authorizing entity (issuer) evaluating the provisioning request against eligibility and identity data and returning an approve/deny response, plus an activation/status message, received by the server side of the flow.)
providing, by the server computer, a second token to an application on the first token requestor, wherein the application provides the second token to a second token requestor so that the second token requestor stores the second token to conduct future transactions, and then performs another transaction using the second token (Spector: Col 14. Line 25 - 36, Col. 6, Col. 7 and Col. 16 lines 1 - 8 Provides for server computer to an application resident on the user's device to a second, distinct token-consuming entity that retains the token and thereafter transacts with it.)
the second token being associated with a first token stored in the first token requestor (Spector: Col. 5 lines 30 - 55, Col. 6 and Col. 9 lines 25 - 47 Provides for two coexisting tokens that are affirmatively associated with one another with at least one held in the device's secure element.)
wherein the second token requestor is an application server associated with the application, and the first token and the second token are associated with a credential (Spector: Fig. 3, Fig. 5 Col. 5-6 and Col. 8 lines 1-10 Provides for for a server computer that is expressly associated with the on device payment application (the Pay Server behind the Pay App), that participates in the provisioning request/response chain, and that can be the resting place for tokens held in centralized or cloud storage.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Kinagi in view of Wouters, which together provide a method for cryptogram-based point-of-sale transactions with automatic post-transaction provisioning requests to authorizing entities, with the teachings of Spector, which introduces receiving provisioning responses from authorizing entities, providing second tokens to device applications that forward them to application servers for storage and future transaction use, and maintaining associations between multiple tokens and underlying credentials. One of ordinary skill in the art would recognize the ability to incorporate Spector's comprehensive token distribution and storage framework into the combined transaction and provisioning system to enable broader token utility across multiple transaction contexts and requestors. One of ordinary skill in the art would be motivated to make this modification in order to extend the payment ecosystem beyond single-device transactions.
In reference to claim 5, The method of claim 1, wherein the cryptogram request message comprises the first token (Kinagi: [0023], [0033]-[0036]. [0068] and [0083] Provides for the tokenization computer receiving a PAN-substitute and using it as a lookup key into token record database.)
In reference to claim 6, Wherein the method further comprises: transmitting, by the server computer, the first token with the cryptogram associated with the first token to the first token requestor (Kinagai: [0037] and [0077]-[0079] Provides for the server computer transmitting a token together with a cryptogram, in a single response message, to the user's mobile phone.)
In reference to claim 7, Wherein the second token is provided to the second token requestor via an application programming interface (API) in an API response message (Spector: Col. 7 Lines 1 - 21 , Col. 5 - Col. 6, Col. 9 lines 1 - 30, and Col. 14 lines 30-36 Provides for the token being delivered by API call or service call.)
In reference to claim 8, The method of claim 1, wherein the provisioning request message that is sent to the authorizing entity computer comprises the credential (Wouters: [0039]-[0043] Provides for the server-to-issuer provisioning request expressly enumerating the user account number as a payload field, and confirms the issuer acts on that account identifier.)
In reference to claim 9, Wherein a device identifier for the first token requestor is bound to the second token (Wouters: [0041]-[0045] and [0060]-[0072] Provides for a unique device ID of the first device being the very datum the system uses to authorize and effect provisioning of a token to the second target.)
In reference to claim 10, Wherein the providing of the second token to the second token requestor is performed after the message is received by the server computer, but is not responsive to the receipt of the message by the server computer (Wouters: [0039]-[0048] Provides for token issuance that is expressly decoupled in time from the triggering event.)
In reference to claim 11, The method of claim 1,further comprising: updating, by the server computer, a token store to include the second token as mapping to the credential, an identifier identifying the first token requestor, and the first token, wherein the credential comprises a primary account number (Wouters: [0002], [0017], [0035]-[0041] and [0060]-[0072] Provides for a server-maintained, updatable token store whose records map each token number and its recipient token entity to the account number, identifying that account as a primary account number.)
In reference to claim 13, A system comprising: a server computer comprising: a processor; and; a non-transitory computer readable medium, the non-transitory computer readable medium comprising instructions, executable by the processor, to cause the processor to:: receiving, by a server computer a cryptogram request message from a first token requestor (Kinagi: [0036], [0046] and [0075]-[0077] Provides for a server computer (tokenization computer 170) receiving a request message from a requesting device, where the direct and expressly disclosed consequence of receipt is generation of a cryptogram.)
Wherein the first token requestor is a mobile phone operated by a user (Kinagi: [0021], [0052]-[0053] and [0070]-[0072] Provides for the requesting entity being a smartphone in the physical possession of and operated by user 110, expressly a mobile phone.)
responsive to receiving the cryptogram request message, transmitting, by the server computer to the first token requestor, a cryptogram, wherein the first token requestor uses the first token and the cryptogram to conduct a transaction with a point of sale terminal (Kinagi: [0042] and [0071]-[0082] Provides for the server's transmission of the cryptogram being triggered by and responsive to the request, and for the mobile device then conducting a payment transaction at a POS terminal using both the token and the cryptogram together.)
Kinagi doesn't explicitly teach after the transaction is conducted and automatically without intervention of the user, transmitting, by the server computer, a provisioning request message to an authorizing entity computer, receiving, by the server computer, a provisioning response message from the authorizing entity computer, providing, by the server computer, a second token to an application on the first token requestor, wherein the application provides the second token to a second token requestor so that the second token requestor stores the second token to conduct future transactions, and then performs another transaction using the second token, the second token being associated with a first token stored in the first token requestor, and wherein the second token requestor is an application server associated with the application, and the first token and the second token are associated with a credential. However, Wouters discloses:
after the transaction is conducted and automatically without intervention of the user, transmitting, by the server computer, a provisioning request message to an authorizing entity computer (Wouters: [0039]-[0041] Provides for the server (TSP 308) sending a digitization/provisioning request to the issuer, the authorizing entity, triggered by account use, expressly without the user's knowledge or participation.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Kinagi, which provides a method for receiving cryptogram requests from user-operated mobile phones and transmitting cryptograms that are used with tokens to conduct point-of-sale transactions, with the teachings of Wouters, which introduces automatically transmitting a provisioning request message to an authorizing entity computer after a transaction is conducted without user intervention. One of ordinary skill in the art would recognize the ability to incorporate Wouters's post-transaction automatic provisioning trigger into Kinagi's cryptogram-based transaction system to enable seamless token lifecycle management. One of ordinary skill in the art would be motivated to make this modification in order to streamline the token provisioning process by automatically initiating new token requests based on transaction activity without requiring additional user action.
Kinagi in view of Wouters doesn't explicitly teach receiving, by the server computer, a provisioning response message from the authorizing entity computer, providing, by the server computer, a second token to an application on the first token requestor, wherein the application provides the second token to a second token requestor so that the second token requestor stores the second token to conduct future transactions, and then performs another transaction using the second token, the second token being associated with a first token stored in the first token requestor, and wherein the second token requestor is an application server associated with the application, and the first token and the second token are associated with a credential. However, Wouters discloses:
receiving, by the server computer, a provisioning response message from the authorizing entity computer (Spector: Col. 8 Lines 50-65, Col. 6 lines 44-50 and Fig. 3 Provides for the authorizing entity (issuer) evaluating the provisioning request against eligibility and identity data and returning an approve/deny response, plus an activation/status message, received by the server side of the flow.)
providing, by the server computer, a second token to an application on the first token requestor, wherein the application provides the second token to a second token requestor so that the second token requestor stores the second token to conduct future transactions, and then performs another transaction using the second token (Spector: Col 14. Line 25 - 36, Col. 6, Col. 7 and Col. 16 lines 1 - 8 Provides for server computer to an application resident on the user's device to a second, distinct token-consuming entity that retains the token and thereafter transacts with it.)
the second token being associated with a first token stored in the first token requestor (Spector: Col. 5 lines 30 - 55, Col. 6 and Col. 9 lines 25 - 47 Provides for two coexisting tokens that are affirmatively associated with one another with at least one held in the device's secure element.)
wherein the second token requestor is an application server associated with the application, and the first token and the second token are associated with a credential (Spector: Fig. 3, Fig. 5 Col. 5-6 and Col. 8 lines 1-10 Provides for for a server computer that is expressly associated with the on device payment application (the Pay Server behind the Pay App), that participates in the provisioning request/response chain, and that can be the resting place for tokens held in centralized or cloud storage.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Kinagi in view of Wouters, which together provide a method for cryptogram-based point-of-sale transactions with automatic post-transaction provisioning requests to authorizing entities, with the teachings of Spector, which introduces receiving provisioning responses from authorizing entities, providing second tokens to device applications that forward them to application servers for storage and future transaction use, and maintaining associations between multiple tokens and underlying credentials. One of ordinary skill in the art would recognize the ability to incorporate Spector's comprehensive token distribution and storage framework into the combined transaction and provisioning system to enable broader token utility across multiple transaction contexts and requestors. One of ordinary skill in the art would be motivated to make this modification in order to extend the payment ecosystem beyond single-device transactions.
In reference to claim 14, Wherein the second token is bound to a device identifier associated with the first token requestor (Wouters: [0041]-[0045] and [0060]-[0072] Provides for a unique device ID of the first device being the very datum the system uses to authorize and effect provisioning of a token to the second target.)
In reference to claim 15, Wherein the message includes a request for a cryptogram for a transaction conducted using the first token, and wherein the non-transitory computer readable medium further comprises instructions which cause the processor to: transmit the cryptogram to the first token requestor in response to receiving the message (Kinagi: [0065]-[0078] and [0104] Provides for a server whose computer readable medium holds security module instructions causing processor to generate a transaction-specific cryptogram upon receipt of the request and return it to the mobile phone.)
In reference to claim 16, The system of claim 13, wherein the non-transitory computer readable medium further comprises instructions, which cause the processor to: update a token store to include the second token as mapping to the credential, a device identifier uniquely identifying the first token requestor, and the first token (Wouters: [0002], [0017], [0035]-[0041] and [0060]-[0072] Provides for a server-maintained, updatable token store whose records map each token number and its recipient token entity to the account number, identifying that account as a primary account number.)
In reference to claim 21, The method of claim 1, wherein the cryptogram request message is received by the server computer in response to a checkout request conducted by a user operating the first token requestor at a site operated by the second token requestor (Wouters: [0023]-[0030] and [0039]-[0049] Provides for a user operating a mobile device to check out at a merchant-operated site, which triggers a message flow into the issuer/TSP infrastructure.)
In reference to claim 22, The method of claim 21, wherein the application server is operated by a resource provider, the checkout request includes identification of a resource by the resource provider (Wouters: [0023] and [0039]-[0049] Provides for merchants operating e-commerce server computers that host the checkout sites and receive the tokens.)
In reference to claim 23, The method of claim 1, wherein the first token is a first payment token (Kinagi: [0030]-[0031], [0048], [0057] and [0067]-[0077] Provides for the token being expressly a payment token.)
In reference to claim 24, The method of claim 1, wherein the transaction conducted by the second token requestor is a recurring transaction (Wouters: [0037]-[0043] Provides for the second token being provisioned specifically into a merchant card-on-file system for subsequent, merchant-submitted payments made without the user re-presenting the card.)
In reference to claim 25, The method of claim 24, wherein the application server provides streaming services to the user operating the first token requestor (Wouters: [0023] and [0037]-[0041] Provides for Amazon.com and expressly contemplates "type of goods sold" as a variable merchant attribute with "online, in-app" payment capabilities.)
In reference to claim 26, The method of claim 1, further comprising: updating a token store comprising a device identifier for the first token requestor, the first token, the second token, and the credential (Wouters: [0041] and [0060]-[0072] Provides for an updatable server-side token store whose entries map token numbers to the account number and to the recipient token entity.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Applicant’s amendment necessitated the new ground(s) of rejection presented in this office action. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AIDAN EDWARD SHAUGHNESSY whose telephone number is (703)756-1423. The examiner can normally be reached on Monday-Friday from 7:30am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Nickerson, can be reached at telephone number (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/usptoautomated-interview-request-air-form.
/A.E.S./Examiner, Art Unit 2432
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
Prosecution Insights