DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
2. Applicant filed the Request for Continued Examination on 06/30/2026. Claims 8-12, 14-16, 18-25, and 27 are amended. Claims 8-27 are pending.
Claim Rejections - 35 USC § 103
3. 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.
4. 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.
5. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
6. Claim 8, 10-21, 24-27 are rejected under 35 U.S.C. 103 as being unpatentable over US20210383366A1 to DePopas et al. in view of US20140282464A1 to El-Gillani
7. As per claim 8:
DePopas et al. discloses the following limitations:
A method, comprising ([0005] “One embodiment provides a method for executing an electronic transaction using a digital wallet…”)
receiving, by a computer system and from a client module integrated within a first online platform that is executed on a user device ([0028] “…The merchant system 120 may integrate the digital wallet interface provided by the digital wallet system 140 to display the digital wallet interface on the browser 110…”, [0032] “…the SDK provided by the SDK server 210 may include classes that may expose various functions for initiating and processing the digital wallet services (e.g., an express checkout and a OTPA or two-factor authentication (2FA) functionality)…”), an indication that a user of the user device has initiated a first transaction with a first entity associated with the first online platform during a first online session between the user device and the first online platform, wherein the client module is associated with the computer system ([0042] “…The user 105 may initiate a digital wallet express checkout process by selecting a digital wallet express checkout option (e.g., a graphical ‘express checkout’ button) displayed on the browser 110…”, [0063] “ … the processing system 130 may receive, from the browser 110 (e.g., an electronic transaction browser), an express checkout request and electronic transaction information…”)
in response to receiving the indication, providing, by the computer system and via the client module, a user interface for interacting with the user ([0056] “When the user 105 presses the express checkout button 708, the digital wallet interface 220 may display a prompt to the user 105 for entering an email address…the digital wallet interface 220 may provide an express checkout window 802 of a graphical user interface 800…”)
prompting, by the computer system and via the user interface of the client module, the user for a user identifier of the user ([0042] “…the digital wallet interface 220 may display a prompt to the user 105 to request the user's 105 personal information (e.g., name, email address, a phone number, etc.) …”, [0056] “…The express checkout window 802 may include an email address input field 806 and a button 808 for continuing the express checkout. The user 105 may enter an email address in the email address input field 806…”)
determining, by the computer system, that a user profile associated with the user is present in a data store based on the user identifier ([0056] “… the digital wallet system 140 may determine whether the user 105 is enrolled in the digital wallet system 140 based on the email address received in the email address input field 806…), wherein the user profile includes first user data ([0022] “… The user enrollment may be determined based on the information (e.g., email address or phone number) that the user has provided during a previous purchase transaction…”, [0038] “…the digital wallet API provided by the API server 230 may save the user information (e.g., payment information, shipping information, email address, phone number, and/or mailing address) into a server(s) or the database(s) 240…”) obtained during a second online session between the user device and a second online platform for processing a second transaction between the user and a second entity associated with the second online platform ([0029] “…Thus, if a given user makes a purchase at merchant A, token A may be generated, but if the user makes a purchase at merchant B, even if the same payment method is used, token B may be generated…”)
performing, by the computer system, an authentication operation with the user via the client module ([0056] “…the digital wallet system 140 may perform an OTPA or 2FA with the user 105. In one embodiment, the digital wallet API may send an OTPA or 2FA code to the user 105 via the user's 105 email address or phone number stored in the digital wallet system 140. The digital wallet interface 220 may then display an OTPA or 2FA prompt 812…”, [claim 5] “…the verification request includes a one-time password authentication request or a two-factor authentication request.”)
while the authentication operation is in process ([0056] “…“the digital wallet API may send an OTPA or 2FA code to the user 105 via the user's 105 email address or phone number stored in the digital wallet system 140…”) and before the user is authenticated to access the user profile ([0038] “…At step 328, if the payment information includes a PAN, the tokenization system 160 may tokenize the payment method by generating a digital wallet token … the digital wallet API may then save the merchant token received from the merchant system 120 for later processing…”, [0039] “…the digital wallet API may initiate an OTPA or 2FA process flow…”), preparing, by the computer system, a user profile package based on the first user data ([0040] “…If the enrollment status is still pending, however, the browser 110 may display the order confirmation page at step 342… the digital wallet API may update the user's 105 digital wallet enrollment status at step 352…”)
in response to detecting that the authentication operation is complete, transmitting, by the computer system, the user profile package to the client module, wherein the client module is configured to present the first user data on the user interface ([0057] “… upon validating the OTPA or 2FA at step 908, the digital wallet interface 220 may display an order review and selection options and/or an input field(s) for indicating the method of payment to the user 105…”, [0044] “…the digital wallet API may create the user 105 response objects (e.g., name, address, payment methods, etc.)…”, [0045] “…the digital wallet interface 220 may display the order review screen with user response fields prefilled in the order review screen…”, [claim 1] “…“generating, by the digital wallet system, a graphical interface including predetermined user data…”)
updating, by the computer system, the user profile based on the second user data ([0050] “…the digital wallet API may save the shipping address received from the user 105… the digital wallet API may store the digital wallet token generated by the tokenization system 160 in the database 240…”, [0058] “…the digital wallet system 140 may create a digital wallet account for the user 105 and save the user 105 information into the digital wallet system 140 (e.g., in the database 240)…”)
generating, by the computer system, a token that encapsulates at least a portion of the first user data or the second user data for the first transaction between the user and the first entity ([0029] “…The tokenization system 160 may then tokenize the payment information received from the transaction system 150 to generate a token for authenticating and authorizing purchase transactions…”, [0057] “…the tokenization system 160 may tokenize the payment method provided by the user 105 and/or exchange a digital wallet token with a merchant specific token received from the merchant system 120…”, [claim 2] “generating, by the digital wallet system, a token based on the electronic transaction data.”)
providing, by the computer system, the token to the first online platform, wherein the token enables the first online platform to process the first transaction ([0029] “…The processing system 130 may transmit a token (e.g., a digital wallet token) generated by the tokenization system 160 to the merchant system 120, such that the merchant system 120 may store the token for future transactions… By utilizing a token, the merchant system 120 may not need to send payment information (e.g., debit or credit card information) or other sensitive data for subsequent transactions, and may instead use the token…”, [0045] “…the digital wallet token may be exchanged for the merchant specific token, which may be used for performing a payment authorization…”)
DePopas et al. does not disclose, however, El-Gillani, as shown, teaches the following limitations:
intercepting, by the computer system and using the client module, second user data provided by the user via the user interface without providing the first online platform access to the second user data ([0007] “In some embodiments, methods are provided that automatically detect and intercept user data. Once intercepted, different processing may be performed including execution of security algorithms.”, [0063] “intercepting user data for the purpose of applying a security algorithm in order to ensure WebApp server components do not have access to private user data, while leaving control data intact.”, [0158] “User data is then swapped with the tokens, block 7-3, and sent to the WebApp server in block 7-4…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for automatically detecting and intercepting user data and processing execution of security algorithms of El-Gillani (‘464, [0007]) with the teaching of DePopas et al. for executing an electronic transaction using a digital wallet that manages an express checkout request and electronic transaction data (‘366, [0006]) for intercepting user data entered on the platform's interface and forwarding to the platform (WebApp server) only tokens swapped from the user data (‘464, [0063], [0158]).
Claims 15 and 21 are rejected using the same rationale that was used for the rejection of claim 8.
As per claim 15 DePopas et al. additionally discloses the following limitations:
A non-transitory machine-readable medium having stored thereon machine-readable instructions, that when executed by a machine, causes the machine to perform operations comprising ([0007] “One embodiment provides a non-transitory computer-readable medium storing instructions for executing an electronic transaction using a digital wallet…”)
As per claim 21 DePopas et al. additionally discloses the following limitations:
A system, comprising: ([0006] “One embodiment provides a system comprising: one or more computer readable media storing instructions for executing an electronic transaction using a digital wallet; and one or more processors configured to execute the instructions to perform operations…”)
a non-transitory memory ([0070] “The computer system 1000 may include a memory 1004 that can communicate via a bus 1008… The memory 1004 is operable to store instructions executable by the processor 1002…”)
one or more hardware processors coupled with the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations comprising: ([0069] “As illustrated in FIG. 10, the computer system 1000 may include a processor 1002, e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both…”)
8. As per claim 10:
DePopas et al. discloses the following limitations:
obtaining, by the computer system, third user data from the first online platform, wherein the updating the user profile is further based on the third user data ([0037] “…the merchant system 120 may process the purchase order of user 105 by transmitting the order details and payment request data to the processing system 130…”, [0038] “…the digital wallet API provided by the API server 230 may save the user information (e.g., payment information, shipping information, email address, phone number, and/or mailing address) into a server(s) or the database(s) 240…the digital wallet API may then save the merchant token received from the merchant system 120 for later processing…”)
9. As per claim 11:
DePopas et al. discloses the following limitations:
wherein the user profile comprises financial data related to a plurality of financial instruments associated with the user, and wherein the method further comprises ([0044] “…the user 105 information retrieved by the digital wallet API may include various methods of payment that may be used to complete the purchase transaction. For example, the user 105 may use credit card accounts, bank card accounts, and loyalty point accounts…”)
presenting the plurality of financial instruments on the user interface ([0057] “…the digital wallet interface 220 may display an order review and selection options and/or an input field(s) for indicating the method of payment to the user 105…”, [claim 6] “generating and displaying, by the digital wallet system, a plurality of transaction options for completing the electronic transaction.”, [claim 7] “wherein the plurality of transaction options for completing the electronic transaction comprises at least one of payment with a credit card account, payment with loyalty points, payment by lending, or payment with a bank account.”
receiving, from the user and via the user interface, a selection of a particular financial instrument from the plurality of financial instruments, wherein the token is generated based on data associated with the particular financial instrument ([0057] “…the digital wallet system 140 may then receive the method of payment and order confirmation from the user 105…”, [0050] “…At step 538, the digital wallet API may request a tokenization of the payment method selected by the user 105. At step 540, the tokenization system 160 may generate a digital wallet token for the payment method selected by the user 105…”)
Claim 24 is rejected using the same rationale that was used for the rejection of claim 11.
10. As per claim 12:
DePopas et al. discloses the following limitations:
receiving, from a second client module integrated within the second online platform executed on the user device, a second indication that the user is accessing the second online platform associated with the second entity ([0042] “…the merchant system 120 may participate in the services provided by the digital wallet of the present disclosure…”, [0028] “…The merchant system 120 may integrate the digital wallet interface provided by the digital wallet system 140 to display the digital wallet interface on the browser 110…”, [0029] “…Thus, if a given user makes a purchase at merchant A, token A may be generated, but if the user makes a purchase at merchant B, even if the same payment method is used, token B may be generated…”)
presenting, on the user device, information from the updated user profile without requiring any input from the user ([0057] “…the digital wallet interface 220 may display an order review and selection options and/or an input field(s) for indicating the method of payment to the user 105…”, [0045] “…the digital wallet interface 220 may display the order review screen with user response fields prefilled in the order review screen…”)
11. As per claim 13:
DePopas et al. discloses the following limitations:
wherein the information is inaccessible by the second online platform ([0063] “… intercepting user data for the purpose of applying a security algorithm in order to ensure WebApp server components do not have access to private user data, while leaving control data intact.”, [0161] “…once a match is found, the associated user data is decrypted using the user's private key…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for automatically detecting and intercepting user data and processing execution of security algorithms of El-Gillani (‘464, [0007]) with the teaching of DePopas et al. for executing an electronic transaction using a digital wallet that manages an express checkout request and electronic transaction data (‘366, [0006]) for keeping the restored cleartext information only on the user device (decrypted with the user's private key) and holding only tokens and denying access to the private user data (‘464, [0063], [0161]).
Claims 17 and 26 are rejected using the same rationale that was used for the rejection of claim 13.
12. As per claim 14:
DePopas et al. discloses the following limitations:
generating a second token based on the information from the updated user profile for a third transaction conducted between the user and the second entity ([0029] “…The token may be unique per transaction, per user, and/or per merchant or organization. Thus, if a given user makes a purchase at merchant A, token A may be generated, but if the user makes a purchase at merchant B, even if the same payment method is used, token B may be generated…”, [0045] “…The digital wallet tokens may be generated when the user 105 adds payment methods and stores the payment methods in the digital wallet ‘account.’ During a payment transaction, the digital wallet token may be exchanged for the merchant specific token, which may be used for performing a payment authorization…”)
transmitting the second token to the second online platform ([0029] “…The processing system 130 may transmit a token (e.g., a digital wallet token) generated by the tokenization system 160 to the merchant system 120, such that the merchant system 120 may store the token for future transactions… The token may be unique per transaction, per user, and/or per merchant or organization…”)
Claims 18 and 27 are rejected using the same rationale that was used for the rejection of claim 14.
13. As per claim 16:
DePopas et al. discloses the following limitations:
subsequent to the updating the user profile, receiving, from a second client module integrated within the second online platform associated with the second entity, a second indication that the user is accessing the second online platform ([0042] “…the merchant system 120 may participate in the services provided by the digital wallet of the present disclosure…”, [0028] “…The merchant system 120 may integrate the digital wallet interface provided by the digital wallet system 140 to display the digital wallet interface on the browser 110…”, [0029] “…Thus, if a given user makes a purchase at merchant A, token A may be generated, but if the user makes a purchase at merchant B, even if the same payment method is used, token B may be generated…”)
authenticating the user based on the identifier of the user ([0056] “… the digital wallet API may send an OTPA or 2FA code to the user 105 via the user's 105 email address or phone number stored in the digital wallet system 140…”, [0043] “… At step 418, the digital wallet API may validate the received OTPA or 2FA code…”)
in response to the authenticating the user, providing information from the updated user profile to the second client module integrated within the second online platform for use in the second transaction between the user and the second entity ([0044] “…the digital wallet API may look up the information (e.g., shopper identification, name, addresses, payment tokens, etc.) associated with the user 105 enrolled in the digital wallet system 140…”, [0045] “…the digital wallet interface 220 may display the order review screen with user response fields prefilled in the order review screen…”, [0042] “…the merchant system 120 may participate in the services provided by the digital wallet of the present disclosure…”)
14. As per claim 19:
DePopas et al. discloses the following limitations:
wherein the user profile comprises a device identifier associated with the user, and wherein the performing the authentication operation comprises: ([0029] “…In one embodiment, an identification associated with the user 105 may be tied to the user's 105 email or a phone number…”, [0056] “…the digital wallet API may send an OTPA or 2FA code to the user 105 via the user's 105 email address or phone number stored in the digital wallet system 140…”)
transmitting a code to the device of the user based on the device identifier ([0039] “…Further, an OTPA or 2FA six digit code may be sent via a mobile text message or an email, which may be used to verify the user 105 before the user's 105 data may be used for a payment on one of the acquirer processor's processing platforms.”)
prompting, via the user interface of the client module, the user to provide an authentication code ([0040] “…the digital wallet interface 220 may then display a prompt to the user 105 to request an OTPA or 2FA code (e.g., an OTPA or 2FA six digit code sent via a mobile text message or an email) …”)
authenticating the user based on matching the authentication code received via user interface and the code transmitted to the device ([0040] “…At step 348, the digital wallet API may validate the OTPA or 2FA code. At step 350, if the OTPA or 2FA is properly validated by the digital wallet API, the digital wallet API may update the user's 105 digital wallet enrollment status at step 352…”)
15. As per claim 20:
DePopas et al. discloses the following limitations:
in response to authenticating the user, causing the client module to present the first user data on the user interface ([0057] “…upon validating the OTPA or 2FA at step 908, the digital wallet interface 220 may display an order review and selection options and/or an input field(s) for indicating the method of payment to the user 105…”, [0045] “…the digital wallet interface 220 may display the order review screen with user response fields prefilled in the order review screen…”)
16. As per claim 25:
DePopas et al. discloses the following limitations:
receiving, from a second client module integrated within the second online platform, a second indication that the user is accessing the second online platform ([0042] “…the merchant system 120 may participate in the services provided by the digital wallet of the present disclosure…”, [0028] “…The merchant system 120 may integrate the digital wallet interface provided by the digital wallet system 140 to display the digital wallet interface on the browser 110…”, [0029] “…Thus, if a given user makes a purchase at merchant A, token A may be generated, but if the user makes a purchase at merchant B, even if the same payment method is used, token B may be generated…”)
in response to authenticating the user, presenting, on the device, information from the updated user profile without requiring any input from the user ([0057] “… upon validating the OTPA or 2FA at step 908, the digital wallet interface 220 may display an order review and selection options and/or an input field(s) for indicating the method of payment to the user 105…”, [0045] “…the digital wallet interface 220 may display the order review screen with user response fields prefilled in the order review screen…”)
17. Claim 9, 22, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over US20210383366A1 to DePopas et al. in view of US20140282464A1 to El-Gillani and US20130013499A1 to Kalgi.
18. As per claim 9:
Neither DePopas et al. nor El-Gillani disclose, however, Kalgi, as shown, teaches the following limitations:
wherein the updating the user profile comprises replacing a portion of the first user data with the second user data ([0143] “…the user may be able to view and/or modify the user profile and/or settings of the user…”, [0035] “…the selections may be set as default for future preferences/transactions and may be synched to other applications and/or devices as default settings for E-Wallet transactions…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for automatically detecting and intercepting user data and processing execution of security algorithms of El-Gillani (‘464, [0007]) and system for transforming customer purchase requests triggering electronic wallet applications, via EWCP components, into electronic purchase confirmation and receipts of Kalgi (‘499, [0027]) with the teaching of DePopas et al. for executing an electronic transaction using a digital wallet that manages an express checkout request and electronic transaction data (‘366, [0006]) for modifying profile fields (user name, account number, address, etc.) and resetting stored defaults replaces previously stored profile data with the newly supplied data (‘499, [0035], [0143]).
Claim 23 is rejected using the same rationale that was used for the rejection of claim 9.
19. As per claim 22:
DePopas et al. discloses the following limitations:
obtaining third user data from a first data storage associated with the first online platform, wherein the updating the user profile is further based on the third user data ([0037] “…the merchant system 120 may process the purchase order of user 105 by transmitting the order details and payment request data to the processing system 130…”, [0038] “…the digital wallet API provided by the API server 230 may save the user information (e.g., payment information, shipping information, email address, phone number, and/or mailing address) into a server(s) or the database(s) 240…the digital wallet API may then save the merchant token received from the merchant system 120 for later processing…”)
Neither DePopas et al. nor El-Gillani disclose, however, however, Kalgi, as shown, teaches the following limitations:
determining that the user has a user account with the first online platform ([0143] “…user account of the merchant in whose store the user currently is (e.g., 1918-b) [Fig.19A, a field of the user profile])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for automatically detecting and intercepting user data and processing execution of security algorithms of El-Gillani (‘464, [0007]) and system for transforming customer purchase requests triggering electronic wallet applications, via EWCP components, into electronic purchase confirmation and receipts of Kalgi (‘499, [0027]) with the teaching of DePopas et al. for executing an electronic transaction using a digital wallet that manages an express checkout request and electronic transaction data (‘366, [0006]) for storing by the wallet profile the user's account with the current merchant (‘499, [0143]).
Response to Arguments
20. After careful consideration of applicant arguments, the examiner finds them to be not persuasive. Claims 8-27 are rejected.
Rejection under 35 USC § 101
21. Applicant is of the opinion “that the amended claimed subject matter is not directed to an abstract idea under Step 2A, Prong Two of the Mayo analysis”, recites some of amended independent claim 8 limitations:
“while the authentication operation is in process and before the user is authenticated to access the user profile, preparing, by the computer system, a user profile package based on the first user data;
in response to detecting that the authentication operation is complete, transmitting, by the computer system, the user profile package to the client module, wherein the client module is configured to present the first user data on the user interface;
intercepting, by the computer system and using the client module, second user data provided by the user via the user interface without providing the first online platform access to the second user data;
updating, by the computer system, the user profile based on the second user data;
generating, by the computer system, a token that encapsulates at least a portion of the first user data or the second user data for the first transaction between the user and the first entity”.
Amended claim 8 recites the combination of additional elements of while the authentication operation is in process and before the user is authenticated to access the user profile, the computer system is preparing a user profile package and transmitting the user profile package to the client module, and then intercepting using the client module, second user data provided by the user via the user interface without providing the first online platform access to the second user data, further, the computer system updates the user profile based on the second user data. The claim as a whole integrates the certain methods of organizing human activity” (e.g., commercial or legal interactions) into a practical application. Specifically, the additional elements recite generating a token that encapsulates at least a portion of the first user data or the second user data for the first transaction between the user and the first entity, which provides a specific improvement over prior systems, resulting in improving of processing the electronic transactions without having to access sensitive data associated with the users. Thus, the amended claim 8 is eligible because it is not directed to the recited judicial exception.
The amended independent claims 15 and 21 also recite similar limitations, thus, claims 15 and 21 are eligible because they are not directed to the recited judicial exception.
Dependent claims 9-14, 16-20, and 22-27 expand the independent claims and therefore are also eligible for the same rationale as claims 8, 15, and 21 respectively.
Rejections under 35 U.S.C. § 112(a)
22. Rejections of claims 8-27 due to amendments of claims 8, 15, and 21 are withdrawn.
Rejections under 35 U.S.C. § 112(b)
23. Rejections of claims 21-27 due to amendments of claim 21 are withdrawn.
Rejections under 35 U.S.C. § 103
24. Applicant is of the opinion that the prior art references El-Gillani and Nwokolo et al fail to teach amended claim 8 limitations “while the authentication operation is in process and before the user is authenticated to access the user profile, preparing, by the computer system, a user profile package based on the first user data; in response to detecting that the authentication operation is complete, transmitting, by the computer system, the user profile package to the client module, wherein the client module is configured to present the first user data on the user interface”.
Applicant arguments are no longer applicable because they are moot in light of the new ground of rejection.
Conclusion
25. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20130297504A1 – Nwokolo et al. – Discloses a system and method of tokenizing sensitive cardholder payment information for use in cashless transactions includes receiving a request to process a cashless transaction between a merchant and a purchaser using first payment data stored with an electronic wallet provider on behalf of the purchaser.
US20170011423A1 – Douglas et al. – Discloses systems and methods for outputting individualized targeted interaction information to a user in an environment based on detection of a device associated with the user within the environment using a plurality of sensors positioned within the environment.
US20190325445A1 – Anderson et al. – Discloses methods for facilitating financial transactions include facilitating or otherwise increasing the ease and speed of checkout processes, in particular, one or more implementations comprise an e-commerce payment facilitator that acts as an intermediary between a commerce application and a payment gateway.
US20240185284A1 - Mass et al. – Discloses a user identity management platform that manages user identity for an enterprise, such as a retail enterprise, in particular, a specific identity graph structure is provided that allows for flexible management and selection of user account information depending on the context.
US20130117185A1 – Collison et al. – Discloses a method for conducting a transaction between a merchant site and a customer's electronic device using a payment processor, wherein the merchant site is associated with a client-side application and a server-side application and the client-side application executes on the customer's electronic device.
26. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/Examiner, Art Unit 3692 /DAVID P SHARVIN/Primary Examiner, Art Unit 3692
Prosecution Insights