CTNF 18/997,891 CTNF 94439 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. 12-151 AIA 26-51 12-51 Status of Claims This is a first office action on the merits, in response to the claims filed on January 23, 2025 and further in response to the response to Election/Restriction filed on March 26, 2026. Claims 1-20 are pending. Claim 20 has been withdrawn. Claims 1-19 have been examined. Drawings Objections Drawings filed on 01/23/2025, Fig. 8 is objected to because of the following informalities: “INPUT COMONENT 810”. The phrase “COMONENT” is misspelled. Appropriate correction is required. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 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-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of transmitting, receiving, and generating transaction data without significantly more. Examiner has identified claim 13 as the claim that represents the claimed invention presented in independent claims 1 and 13. In the instant case, claims 1-12 are directed to a method, and claims 13-19 are directed to a system comprising at least one processor. Therefore, these claims fall within the four statutory categories of invention. (Step 1: YES) . Claim 13 is directed to a system comprising at least one processor programmed or configured to, which performs a series of steps: “transmit a public key to a merchant system , the public key of a payment device provider system ; receive a request for a prepaid amount from a user device of a user; in response to receiving the request, generate a cryptogram based on a payment device of the user, the prepaid amount, and a private key corresponding to the public key of the payment device provider system , the public key and the private key forming a public-private key pair associated with the payment device provider system ; and transmit the cryptogram to the user device , the cryptogram configured to authenticate the user device during an electronic payment transaction initiated by the user device with a merchant system ” These series of steps describe the abstract idea of transmitting, receiving, and generating transaction data (with the exception of the bold italicized terms above) , which correspond to “Certain Methods of Organizing Human Activity”: commercial interactions because it describes a process for carrying out a commercial interaction between parties that involves communicating data needed to complete a transaction to the parties. The system limitations, e.g., at least one processor, a merchant system, a payment device provider system, a user device, a payment device and a cryptogram do not necessarily restrict the claim from reciting an abstract idea. Thus, claim 13 recites an abstract idea. (Step 2A-Prong 1: YES) . This judicial exception is not integrated into a practical application because the additional elements of claim 13 such as at least one processor, a merchant system, a payment device provider system, a user device, a payment device and a cryptogram are no more than simply applying the abstract idea using generic computer elements. Specifically, the at least one processor, merchant system, payment device provider system, user device and payment device perform the steps or functions of: “transmit a public key to a merchant system, the public key of a payment device provider system; receive a request for a prepaid amount from a user device of a user; in response to receiving the request, generate a cryptogram based on a payment device of the user, the prepaid amount, and a private key corresponding to the public key of the payment device provider system, the public key and the private key forming a public-private key pair associated with the payment device provider system; and transmit the cryptogram to the user device, the cryptogram configured to authenticate the user device during an electronic payment transaction initiated by the user device with a merchant system.” The additional elements listed above are all recited at a high level of generality and under their broadest reasonable interpretation comprises a generic computing arrangement. The presence of a generic computer arrangement is nothing more than to implement the claimed invention (MPEP 2106.05(f)). The additional element of claim 13 such as “cryptogram” describes a type of data, which fails to recite patent-eligible subject matter as it simply recites a type of data included in the abstract ideas. Therefore, the recitations of additional elements do not meaningfully apply the abstract idea and hence do not integrate the abstract idea into a practical application. Thus, claim 13 does not integrate the abstract idea into a practical application. (Step 2A-Prong 2: NO). Claim 13 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements of claim 13 such as at least one processor, a merchant system, a payment device provider system, a user device and a payment device limitations are recited at a high level of generality in that it results in no more than simply applying the abstract idea using generic computer elements. The additional element of claim 13 such as “cryptogram” describes a type of data, which fails to recite patent-eligible subject matter as it simply recites a type of data included in the abstract ideas. The additional elements when considered separately and as an ordered combination do not amount to add significantly more as these limitations provide nothing more than to simply apply the exception in a generic computer environment. Thus, claim 13 is not patent eligible. (Step 2B: NO) . Similar arguments can be extended to the independent claim 1 and hence, claim 1 is rejected on similar grounds as claim 13. Regarding dependent claims Dependent claims 2-12 and 14-19 have also been considered for subject matter eligibility. However, these claims also fail to recite patent-eligible subject matter for the following reasons: Claims 2 and 14 recite: “The computer-implemented method of claim 1, further comprising: receiving, with the merchant system , a transaction request from the user device , the transaction request comprising an account identifier corresponding to the payment device and the cryptogram , the transaction request associated with the electronic payment transaction and a transaction amount; and in response to receiving the cryptogram, the merchant system: determining the payment device provider system based on at least one of the account identifier corresponding to the payment device and the cryptogram ; validating the cryptogram based on the public key of the payment device provider system ; and transmitting a confirmation message to the user device indicating that the electronic payment transaction has been approved” further define the abstract idea that is present in their respective independent claims 1 and 13; and thus, correspond to “Certain Methods of Organizing Human Activity”, grouping of abstract ideas. The additional elements of claims 2 and 14 such as a merchant system, user device, payment device and payment device provider system are recited at a high level of generality such that they amount to no more than instructions to apply the exception using generic computer components. The additional element of claims 2 and 14 such as “cryptogram” describes a type of data, which fails to recite patent-eligible subject matter as it simply recites a type of data included in the abstract ideas. Therefore, the identified additional elements fail to recite a practical application or significantly more than the abstract idea. Claims 3 and 15 recite: “The computer-implemented method of claim 2, wherein the cryptogram is validated without the merchant system communicating with the payment device provider system ” further define the abstract idea that is present in their respective independent claims 1 and 13; and thus, correspond to “Certain Methods of Organizing Human Activity”, grouping of abstract ideas. The additional elements of claims 3 and 15 such as a merchant system and payment device provider system are recited at a high level of generality such that they amount to no more than instructions to apply the exception using generic computer components. The additional element of claims 3 and 15 such as “cryptogram” describes a type of data, which fails to recite patent-eligible subject matter as it simply recites a type of data included in the abstract ideas. Therefore, the identified additional elements fail to recite a practical application or significantly more than the abstract idea. Claims 4 and 16 recite: “The computer-implemented method of claim 2, further comprising the merchant system : determining that the transaction amount is less than or equal to the prepaid amount, wherein the cryptogram is validated at least partially based on the transaction amount being less than or equal to the prepaid amount” further define the abstract idea that is present in their respective independent claims 1 and 13; and thus, correspond to “Certain Methods of Organizing Human Activity”, grouping of abstract ideas. The additional element of claims 4 and 16 such as a merchant system is recited at a high level of generality such that they amount to no more than instructions to apply the exception using generic computer components. The additional element of claims 4 and 16 such as “cryptogram” describes a type of data, which fails to recite patent-eligible subject matter as it simply recites a type of data included in the abstract ideas. Therefore, the identified additional elements fail to recite a practical application or significantly more than the abstract idea. Claims 5 and 17 recite: “The computer-implemented method of claim 2, further comprising: in response to receiving the request, causing, with at least one processor , the prepaid amount to be automatically debited from a payment device provider system account associated with the user before initiation of the electronic payment transaction” further define the abstract idea that is present in their respective independent claims 1 and 13; and thus, correspond to “Certain Methods of Organizing Human Activity”, grouping of abstract ideas. The additional elements of claims 5 and 17 such as at least one processor and a payment device provider system are recited at a high level of generality such that they amount to no more than instructions to apply the exception using generic computer components. Therefore, the identified additional elements fail to recite a practical application or significantly more than the abstract idea. Claims 6 and 18 recite: “The computer-implemented method of claim 5, further comprising: receiving, with at least one processor , a clearing request comprising the account identifier corresponding to the payment device , the cryptogram , and a settlement amount and/or the transaction amount; determining, with at least one processor , that the transaction amount is less than the prepaid amount by a difference; and causing, with at least one processor , the difference to automatically be credited to the payment device provider system account associated with the user” further define the abstract idea that is present in their respective independent claims 1 and 13; and thus, correspond to “Certain Methods of Organizing Human Activity”, grouping of abstract ideas. The additional elements of claims 6 and 18 such as at least one processor and a payment device are recited at a high level of generality such that they amount to no more than instructions to apply the exception using generic computer components. The additional element of claims 6 and 18 such “cryptogram” describes a type of data, which fails to recite patent-eligible subject matter as it simply recites a type of data included in the abstract ideas. Therefore, the identified additional elements fail to recite a practical application or significantly more than the abstract idea. Claims 7 and 19 recite: “The computer-implemented method of claim 2, wherein the request is generated and transmitted by the user device in response to receiving a message from the merchant system comprising the transaction amount, the transaction amount equal to the prepaid amount” further define the abstract idea that is present in their respective independent claims 1 and 13; and thus, correspond to “Certain Methods of Organizing Human Activity”, grouping of abstract ideas. The additional elements of claims 7 and 19 such as a user device and merchant system are recited at a high level of generality such that they amount to no more than instructions to apply the exception using generic computer components. Therefore, the identified additional elements fail to recite a practical application or significantly more than the abstract idea. Claim 8 recites: “The computer-implemented method of claim 2, wherein the request is automatically generated and transmitted by the user device prior to initiation of the electronic payment transaction, the transaction amount different from the prepaid amount” further define the abstract idea that is present in its respective independent claim 1; and thus, correspond to “Certain Methods of Organizing Human Activity”, grouping of abstract ideas. The additional element of claims 8 such as a user device is recited at a high level of generality such that they amount to no more than instructions to apply the exception using generic computer components. Therefore, the identified additional elements fail to recite a practical application or significantly more than the abstract idea. Claim 9 recites: “The computer-implemented method of claim 1, wherein the cryptogram is generated by a module of a transaction processing system of a transaction service provider ” further define the abstract idea that is present in its respective independent claim 1; and thus, correspond to “Certain Methods of Organizing Human Activity”, grouping of abstract ideas. The additional elements of claim 9 such as a module of a transaction processing system and transaction service provider are recited at a high level of generality such that they amount to no more than instructions to apply the exception using generic computer components. The additional element of “cryptogram” describes a type of data, which fails to recite patent-eligible subject matter as it simply recites a type of data included in the abstract ideas. Therefore, the identified additional elements fail to recite a practical application or significantly more than the abstract idea. Claim 10 recites: “The computer-implemented method of claim 9, wherein the module is a component of a unified service orchestration layer hosted by the transaction processing system , the unified service orchestration layer comprising a plurality of application programming interfaces (APIs) configured to facilitate communication with at least one third party system via the unified service orchestration layer ” further define the abstract idea that is present in its respective independent claim 1; and thus, correspond to “Certain Methods of Organizing Human Activity”, grouping of abstract ideas. The additional elements of claim 10 such as a module, unified service orchestration layer, transaction processing system, application programming interfaces (APIs) and at least one third party system are recited at a high level of generality such that they amount to no more than instructions to apply the exception using generic computer components. Therefore, the identified additional elements fail to recite a practical application or significantly more than the abstract idea. Claim 11 recites: “The computer-implemented method of claim 10, wherein the at least one third party system comprises at least one of a third party data service provider system , a bank identification number (BIN) sponsor system , an issuer system , a transaction processing system , or any combination thereof” further define the abstract idea that is present in its respective independent claim 1; and thus, correspond to “Certain Methods of Organizing Human Activity”, grouping of abstract ideas. The additional elements of claim 11 such as least one third party system, a third party data service provider system, a bank identification number (BIN) sponsor system, an issuer system and a transaction processing system are recited at a high level of generality such that they amount to no more than instructions to apply the exception using generic computer components. Therefore, the identified additional elements fail to recite a practical application or significantly more than the abstract idea. Claim 12 recites: “The computer-implemented method of claim 10, wherein the user device communicates with the module using an application generated by the payment device provider system using a software development kit (SDK) comprising an interface with the unified service orchestration layer ” further define the abstract idea that is present in its respective independent claim 1; and thus, correspond to “Certain Methods of Organizing Human Activity”, grouping of abstract ideas. The additional elements of claims 12 such as a user device, module, payment device provider system, software development kit (SDK), interface and unified service orchestration layer are recited at a high level of generality such that they amount to no more than instructions to apply the exception using generic computer components. Therefore, the identified additional elements fail to recite a practical application or significantly more than the abstract idea. Thus, claims 1-19 are not patent-eligible . Claim Rejections - 35 USC § 112 07-30-02 AIA 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. 07-34-01 AIA Claim s 2-4, 7, 14-16 and 19 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 pre-AIA the applicant regards as the invention. Claims 1 and 13 recites, transmitting, with at least one processor, a public key to a merchant system (line 2 of claim 1); claim further recites: transmitting, with at least one processor, the cryptogram to the user device, …. with a merchant (line 13 of claim 1). However, dependent claim 2 recites, “[t]he computer-implemented method of claim 1, further comprising: receiving, with the merchant system (line 2 of claim 2), a transaction request from the user device,…” which renders the claims indefinite. It is unclear to a person of ordinary skill in the art, whether “ the merchant system” (line 2 of claim 2) recited in claim 2 is referring to line 2 of claim 1 “ a merchant system” or if it is referring to line 13 of claim 1 “ a merchant system ”. Appropriate correction is required. Claims 2-4, 7, 14-16 and 19 recites the language “ the merchant system ” similar to that discussed above in connection with claim 2. Accordingly, claims 2-4, 7, 14-16 and 19 are rejected under a similar rationale as claim 2. Statement Regarding Prior Art for claims 1-19 Regarding claims 1 and 13: Meshkati et al. (US 20160012432 A1) discloses: [the terminal manufacturer may configure the payment terminal 150 with a public cryptographic key (disposed within a X.509 digital certificate)] , with at least one processor, a public key (e.g., public cryptographic key that is associated with the private cryptographic key of the credential processing server 300) […], the public key of a payment device provider system (Meshkati [0042]: The terminal manufacturer may configure the payment terminal 150 with a public cryptographic key (disposed within a X.509 digital certificate) of the credential processing server 300 to thereby allow the payment terminal 150 to validate a payment pre-authorization credential received from a mobile device 200; [0053]: The computer processing system 306 may include one or more microprocessors 308…The computer-readable medium 310 maintains an asymmetric cryptographic key pair (comprising a private cryptographic key, and a corresponding public cryptographic key that is disposed within a X.509 digital certificate), a merchant profile database 312, and an account holders database 314), (Fig. 1); receiving, with at least one processor, a request for a prepaid amount from a user device of a user (Meshkati [0072]: at step S402 the pre-authorization credential request procedure 218 transmits to the credential processing server 300 a pre-authorization credential request requesting a payment pre-authorization credential from the credential processing server 300.), (see Fig. 4a); in response to receiving the request, generating, with at least one processor, a [single-use payment pre-authorization credential] based on a [user's financial account (e.g. one datum)] , the prepaid amount, and a private key (e.g., cryptographic key) corresponding to the public key of the payment device provider system, the public key and the private key forming a public-private key pair associated with the payment device provider system (Meshkati [0081]: at step S408 the pre-authorization credential generator 318 generates a single-use payment pre-authorization credential from a cryptographic key and at least one datum (e.g. the transaction counter, the account number of the device user's financial account) that is associated with the device user. The single-use payment pre-authorization credential is uniquely associated with the device user's financial account and pre-authorizes electronic payment from the financial account; [0082]; The pre-authorization credential generator 318 may generate the single-use payment pre-authorization credential from a message authentication code that is generated from another unpredictable number and the current date, and from the pre-authorized payment amount, account number and transaction counter that are associated with the device user's financial account in the account holders database 314 (collectively “Credential Authorization Data”); [0053]: The computer processing system 306 may include one or more microprocessors 308 and a computer-readable medium 310...The computer-readable medium 310 maintains an asymmetric cryptographic key pair (comprising a private cryptographic key, and a corresponding public cryptographic key that is disposed within a X.509 digital certificate ), a merchant profile database 312, and an account holders database 314); and transmitting, with at least one processor, the cryptogram to the user device, the cryptogram configured to authenticate the [electronic payment] initiated by the user device with a merchant system (Meshkati [0086]: The credential processing server 300 may transmit the payment pre-authorization credential and the signed pre-authorized payment amount to the mobile device 200 over the encrypted communications channel via the mobile communications network 120, at step S410; [0095]: The payment initiation procedure 220 of the mobile device 200 determines the authorized communication mode from the received mode authorization code, requests the payment pre-authorization credential and the signed pre-authorized payment amount from the self-contained computing environment 210 (if not transmitted to the mobile device 200 at step S418), and provides the payment terminal 150 with the payment pre-authorization credential and the signed pre-authorized payment amount via the authorized communications mode, at step S420. Therefore, for example, if the mode authorization code authorized delivery of the payment pre-authorization credential to the payment terminal 150 as a 2-D bar code, the payment initiation procedure 220 would generate a 2-D bar code from the payment pre-authorization credential and the signed pre-authorized payment amount, and would display the 2-D bar code on the display device 202 of the mobile device 200, thereby allowing the bar code to be scanned via the payment credential reader. If the mode authorization code authorized delivery of the payment pre-authorization credential via manual input to the payment terminal 150, the payment initiation procedure 220 would generate a code sequence from the payment pre-authorization credential and the signed pre-authorized payment amount, and would display the code sequence on the display device 202 of the mobile device 200, thereby allowing the code sequence to be manually input into the payment terminal 150 via the input device thereof). However, Meshkati does not disclose, neither singly nor in combination all of the specific combination of claims limitations which includes: transmitting, with at least one processor, a public key to a merchant system, the public key of a payment device provider system; in response to receiving the request, generating, with at least one processor, a cryptogram based on a payment device of the user, the prepaid amount, and a private key corresponding to the public key of the payment device provider system, the public key and the private key forming a public-private key pair associated with the payment device provider system; and transmitting, with at least one processor, the cryptogram to the user device, the cryptogram configured to authenticate the user device during an electronic payment transaction initiated by the user device with a merchant system. Regarding claims 1 and 13: Radu et al. (US 20230298038 A1) discloses: […] receiving, with at least one processor, a request for a prepaid amount from a user device of a user (Radu [0081]: a payment token stored in the digital device wallet 412 is sent from the payment device 411 to the merchant system 42); in response to receiving the request, generating, with at least one processor, a cryptogram […] (Radu [0082]: after receiving the payment token, the merchant requests payment credentials from the digital wallet 43. The payment token is sent from the merchant system 42 to the digital wallet 43. The payment token is then verified by the digital wallet 43. After verifying the payment token, a transaction cryptogram is generated by the digital wallet 43), the prepaid amount (Radu [0083]: the transaction cryptogram comprises transaction information required to complete the transaction, The transaction information comprises the payment amount associated with the transaction and/or the time at which the transaction was initiated, The transaction information may comprise a maximum payment amount for which the cardholder provides their consent), and a private key corresponding to the public key of the payment device provider system, the public key and the private key forming a public-private key pair associated with the payment device provider system (Radu [0083]: the transaction cryptogram may comprise a digital signature. The digital signature may be generated using a private key or a symmetric key. The private or symmetric key may be held by the digital wallet 43, the payment system 41, for example by a secure element of the payment device 411, or by an external server in communication with a point-of-sale device; [0086]: in examples in which the payment network 44 acts as a token service provider, the transaction cryptogram may be decrypted by the payment network 44. In examples in which the transaction cryptogram comprises a digital signature generated using a private key, the corresponding public key may be held by the payment network 44); and […] the cryptogram configured to authenticate the user during an electronic payment transaction initiated by the user device with a merchant system (Radu [0084]: The cryptogram may form part of authentication data communicated using a Universal Cardholder Authentication Field™ [UCAF] in a 3D-Secure protocol. For example, the cryptogram may form part of an Accountholder Authentication Value [AAV] used in the Mastercard™ SecureCode™ protocol). However, Radu does not disclose, neither singly nor in combination all of the specific combination of claims limitations which includes: transmitting, with at least one processor, a public key to a merchant system, the public key of a payment device provider system; receiving, with at least one processor, a request for a prepaid amount from a user device of a user; in response to receiving the request, generating, with at least one processor, a cryptogram based on a payment device of the user; and transmitting, with at least one processor, the cryptogram to the user device, the cryptogram configured to authenticate the user device during an electronic payment transaction initiated by the user device with a merchant system. Accordingly, prior arts do not disclose, neither singly nor in combination all of the specific combination of claims limitations which includes: transmitting, with at least one processor, a public key to a merchant system, the public key of a payment device provider system; receiving, with at least one processor, a request for a prepaid amount from a user device of a user; in response to receiving the request, generating, with at least one processor, a cryptogram based on a payment device of the user, the prepaid amount, and a private key corresponding to the public key of the payment device provider system, the public key and the private key forming a public-private key pair associated with the payment device provider system; and transmitting, with at least one processor, the cryptogram to the user device, the cryptogram configured to authenticate the user device during an electronic payment transaction initiated by the user device with a merchant system. Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure are the following: PICKERING et al. (US 20210334806 A1) discloses, tamper-proofing and secure identity validation techniques in a transaction processing system and secure electronic payment techniques are disclosed. A tamper-proof transaction processing device is provided and comprises at least two different strength adhesives to secure parts of the device together and a housing comprising at least a first and second protective layer. An electronic component comprising a secure element chip storing unique information relating to the chip is located between the first and second protective layer in the housing. In another aspect, a transaction processing system includes a payment instrument that is configured to approve only negative value and/or zero value transaction requests. Another aspect provides an identity card checking system and method where the identity card is brought into proximity of a data processing device and identity information is displayed on the screen of the data processing device for the period of time while the card is in proximity. Lakka et al. (US 20190108515 A1) discloses, systems and methods are provided for authenticating users to payment accounts in connection with transactions. An exemplary method includes receiving, by at least one computing device, an authentication request for a transaction associated with a payment account where the authentication request includes a token associated with the payment account and a cryptogram, and mapping the token to a primary account number (PAN) for the payment account. The method also includes validating the cryptogram, generating a directory server nonce (DSN) for the authentication request, and transmitting the DSN and the account number to an access control server (ACS) associated with an issuer of the payment account. The method further includes, in response to an issuer authentication value (IAV), compiling an accountholder authentication value (AAV) including the IAV, the DSN and an amount of the transaction, and transmitting the AAV to one of a merchant and a server. KINAGI (US 20180006821 A1) discloses, an access device can provide access device data to a mobile communication device. The communication device generates a token request including the access device data and communication device data and sends the token request to a server computer. The server computer returns a token and a token cryptogram to the mobile communication device. The token and the cryptogram may be used in a transaction. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAHED ALI whose telephone number is (571)270-1085. The examiner can normally be reached 8:00 - 5:00 M-F. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached on (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /JAHED ALI/ Examiner, Art Unit 3699 Application/Control Number: 18/997,891 Page 2 Art Unit: 3699 Application/Control Number: 18/997,891 Page 3 Art Unit: 3699 Application/Control Number: 18/997,891 Page 4 Art Unit: 3699 Application/Control Number: 18/997,891 Page 5 Art Unit: 3699 Application/Control Number: 18/997,891 Page 6 Art Unit: 3699 Application/Control Number: 18/997,891 Page 7 Art Unit: 3699 Application/Control Number: 18/997,891 Page 8 Art Unit: 3699 Application/Control Number: 18/997,891 Page 9 Art Unit: 3699 Application/Control Number: 18/997,891 Page 10 Art Unit: 3699 Application/Control Number: 18/997,891 Page 11 Art Unit: 3699 Application/Control Number: 18/997,891 Page 12 Art Unit: 3699 Application/Control Number: 18/997,891 Page 14 Art Unit: 3699 Application/Control Number: 18/997,891 Page 15 Art Unit: 3699 Application/Control Number: 18/997,891 Page 16 Art Unit: 3699 Application/Control Number: 18/997,891 Page 17 Art Unit: 3699 Application/Control Number: 18/997,891 Page 18 Art Unit: 3699 Application/Control Number: 18/997,891 Page 19 Art Unit: 3699 Application/Control Number: 18/997,891 Page 20 Art Unit: 3699 Application/Control Number: 18/997,891 Page 21 Art Unit: 3699
Prosecution Insights