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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06/12/2026 has been entered.
Claims 1-54 have been cancelled.
Claims 55-76 have been newly added.
Response to 103
Applicant’s arguments filed on 06/12/2026 have been fully considered and are persuasive but are moot in view of new grounds of rejections. The arguments do not apply to the current art being used. For detail see the rejection below.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 55-61, 63-66, 69-74 and 76 is/are rejected under 35 U.S.C. 102 (a)(2) as being anticipated by PIRI et al (hereinafter PIRI) (US 20230063417) based on provisional filling date 08/24/2021 (The examiner notes that the specific portion relied upon from the published reference is actually supported by the reference’s provisional filing date as per MPEP 2136.03 III).
Regarding claim 55 and 76 PIRI teaches a tangible, non-transitory computer-readable medium storing instructions of a mobile authenticator application that, when executed by one or more processors of a mobile device, cause the mobile device to perform operations comprising: (PIRI on [0022] teaches computer-readable memory storing instructions executed by a processor);
A Mobile-device implemented method, comprising (PIRI on [0003] teaches computing device such as smartphone performing operations);
advertising, to a relying computing device, an authentication service provided by the mobile authenticator application (PIRI on Fig 2 block 115, 125 and text on [0056 and 0059-0062] teaches companion device 115 which may be a smartphone running authenticator 125 which provides authentication service. Further teaches the companion devices 115 can be configured to run an authenticator application 125 that can register a user 105 with a given relying party application 120 on computing device 110 (i.e., relying device). See on [0063] teaches the credentials belong to the user and are managed by an authenticator 125, with which the relying party application 120 interacts through the WebAuthn API 205);
establishing, with the relying computing device, a cross-device authentication session over a local wireless transport (PIRI on [0063] teaches the credentials belong to the user and are managed by an authenticator 125, with which the relying party application 120 interacts through the WebAuthn API 205 (i.e., broadly interpreted as cross-device authentication session as specification does not have specific definition for the term) using network 140 which may be local area network. See on [0060 and 0077] teaches the computing device 110 and the authenticator communicate with each other using physical or virtual device over local wireless network such as Bluetooth, WiFi etc. See also Fig 3A-3B and associated text discloses cross device authentication between authenticator and relying device);
wherein: the relying computing device configures a virtual authenticator interface exposed to an application or operating-system authentication component based on the advertised authentication service (PIRI on [0062-0066] teaches enable communication with the authenticator 125 on the companion device 115 using the virtual assistant device 235 being introduced as an authentication standard compatible device. The virtual assistant device 235 can be installed on computing device 110, and, in some embodiments, the virtual assistant device 235 can be implemented at a physical device 220. Further teaches the physical device 220 and virtual device driver 225 provide an authenticator interface that can be recognized by the operating system (OS) software protocol 215 as a proper implementation (e.g. meet WebAuthn requirements) to serve the authentication requests. See also Fig 3A-3B and text on [0071-0075] teaches the WebAuthn API 205 is used to send an authentication request 305 initiated by the relying party application 120 to the physical device 220 through a standard transport such as USB. The virtual driver 225 as part of virtual assistant device 235 receives the authentication request 305, sent by a relying party application 120 on a computing device 110 using WebAuthn API 205);
the virtual authenticator interface comprises a software-implemented virtual Universal Serial Bus human-interface-device interface or a software-implemented virtual Universal Serial Bus chip-card interface on the relying computing device (PIRI on [0062-0066] teaches enable communication with the authenticator 125 on the companion device 115 using the virtual assistant device 235 being introduced as an authentication standard compatible device. The virtual assistant device 235 can be installed on computing device 110, and, in some embodiments, the virtual assistant device 235 can be implemented at a physical device 220. Further teaches the physical device 220 and virtual device driver 225 provide an authenticator interface that can be recognized by the operating system (OS) software protocol 215 as a proper implementation (e.g. meet WebAuthn requirements) to serve the authentication requests. See also Fig 3A-3B and text on [0071-0075] teaches the WebAuthn API 205 is used to send an authentication request 305 initiated by the relying party application 120 to the physical device 220 through a standard transport such as USB. The virtual driver 225 as part of virtual assistant device 235 receives the authentication request 305, sent by a relying party application 120 on a computing device 110 using WebAuthn API 205. See on [0043] teaches USB is a hardware protocol and a software protocol. USB Interfaces that reference HID do use the HID USB software protocol and use the HID (human interface device) drivers to communicate with hardware devices. A virtual device driver is a software device driver that emulates hardware and other devices so that multiple applications can access hardware interrupt channels, hardware resources, and memory without causing conflicts. A virtual HID driver, for example, can be installed on an operating system of a computing device to simulate a standard authenticator on a USB interface to receive the authentication request);
the software-implemented virtual Universal Serial Bus human-interface- device interface or the software-implemented virtual Universal Serial Bus chip-card interface reports to an operating system of the relying computing device as an available authenticator device (PIRI on [0062-0066] teaches enable communication with the authenticator 125 on the companion device 115 using the virtual assistant device 235 being introduced as an authentication standard compatible device. The virtual assistant device 235 can be installed on computing device 110. Further teaches the physical device 220 and virtual device driver 225 provide an authenticator interface that can be recognized by the operating system (OS) software protocol 215 as a proper implementation (e.g. meet WebAuthn requirements) to serve the authentication requests. See also Fig 3A-3B and text on [0071-0075] teaches the WebAuthn API 205 is used to send an authentication request 305 initiated by the relying party application 120 to the physical device 220 through a standard transport such as USB. See on [0043] teaches USB is a hardware protocol and a software protocol. USB Interfaces that reference HID do use the HID USB software protocol and use the HID (human interface device) drivers to communicate with hardware devices. A virtual device driver is a software device driver that emulates hardware and other devices so that multiple applications can access hardware interrupt channels, hardware resources, and memory without causing conflicts. A virtual HID driver, for example, can be installed on an operating system of a computing device to simulate a standard authenticator on a USB interface to receive the authentication request);
and the application or operating-system authentication component executes on the relying computing device and communicates with the mobile device through the software-implemented virtual Universal Serial Bus human-interface-device interface or the software-implemented virtual Universal Serial Bus chip-card interface (PIRI on [0056 and 0066] teaches computing device 110 running relying application 120 and operating system software protocol 215 which communicates with smartphone 115 using USB);
receiving, from the relying computing device via the cross-device authentication session, command data repackaged by the relying computing device from authentication protocol packets received by the relying computing device through the virtual authenticator interface (PIRI Fig 3A-3B and text on [0072-0075] teaches the WebAuthn API 205 is used to send an authentication request 305 initiated by the relying party application 120 to the physical device 220 through a standard transport such as USB, which then forward the authentication request 315 to a previously paired companion device 115 holding an authenticator 125. Further teaches the virtual driver 225 as part of virtual assistant device 235 receives the authentication request 305, sent by a relying party application 120 on a computing device 110 using WebAuthn API 205. The assistant service 230 or the virtual driver 225 inside the virtual assistant device 235 then establishes a secure connection with the companion device 115, and forwards the authentication request 315 to be processed on the authenticator 125);
verifying a user locally at the mobile device (PIRI on [0073] teaches the authenticator 125 processes the request, provides a response 320 and replies it back to the physical device 220 as the authentication response 325. The authenticator 125 can implement different operations such as authentication (i.e., verifying user at device 115), registration, and other authenticator operations such as setting passwords, and so on. See on [0069 and 0071] teaches user verification that is taking place or managing on the authenticator 125 itself.);
after verifying the user locally, generating authenticator response data for a public-key authentication request corresponding to the command data using a private key of a credential protected by the mobile device (PIRI Fig 3A-3B and text on [0069 and 0071] teaches in the authentication ceremony, a user 105 and the user's authenticator work in concert to cryptographically prove to a relying party application 120 (and to the reply party web server) that the user controls the credential private key of a public key credential previously-registered as the result of the registration request. Note that this includes a test of user presence or user verification that is taking place or managing on the authenticator 125 itself. Further on [0076] teaches the authentication request 305 can be a login carrying relying party application information, randomly generated data, optionally public credential information expecting to receive a response that is cryptographically signed by previously generated private key pair on the authenticator a registration request carrying relying party application information, user information, and randomly generated data expecting to receive a response from a verified authenticator that includes public key cryptography information about the registered credential that can later be used to verify the login request, or any other operations supported by the standard authentication protocol);
and transmitting the authenticator response data to the relying computing device via the cross-device authentication session for return through the virtual authenticator interface to the application or operating-system authentication component (PIRI on [0073-0076] teaches the authenticator 125 processes the request, provides a response 320 and replies it back to the physical device 220 as the authentication response 325 which then forwards to the relying device 110. The authenticator 125 can implement different operations such as authentication (i.e., verifying user at device 115), registration, and other authenticator operations such as setting passwords, and so on.).
Regarding claim 56 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the virtual authenticator interface comprises a virtual Universal Serial Bus human- interface-device interface (PIRI on [0043] teaches USB is a hardware protocol and a software protocol. USB Interfaces that reference HID do use the HID USB software protocol and use the HID (human interface device) drivers to communicate with hardware devices. A virtual device driver is a software device driver that emulates hardware and other devices so that multiple applications can access hardware interrupt channels, hardware resources, and memory without causing conflicts. A virtual HID driver, for example, can be installed on an operating system of a computing device to simulate a standard authenticator on a USB interface to receive the authentication request).
Regarding claim 57 PIRI teaches all the limitations of claim 56 above, PIRI further teaches wherein the virtual Universal Serial Bus human-interface-device interface reports to the relying computing device as a FIDO2 authenticator (PIRI on [0041-0043] teaches USB interface coupled through FIDO2 authenticator).
Regarding claim 58 PIRI teaches all the limitations of claim 57 above, PIRI further teaches wherein the command data comprises Client to Authenticator Protocol command data (PIRI on [0042] teaches using a Client-to-Authenticator Protocol (CTAP).)
Regarding claim 59 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the application or operating-system authentication component comprises a WebAuthn component (PIRI on [0040-0042] WebAuth component).
Regarding claim 60 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the virtual authenticator interface comprises a virtual smart-card reader or a virtual Universal Serial Bus chip-card interface (PIRI on [0043] teaches USB is a hardware protocol and a software protocol. USB Interfaces that reference HID do use the HID USB software protocol and use the HID (human interface device) drivers to communicate with hardware devices. A virtual device driver is a software device driver that emulates hardware and other devices so that multiple applications can access hardware interrupt channels, hardware resources, and memory without causing conflicts. A virtual HID driver, for example, can be installed on an operating system of a computing device to simulate a standard authenticator on a USB interface to receive the authentication request).
Regarding claim 61 PIRI teaches all the limitations of claim 60 above, PIRI further teaches wherein the command data comprises smart-card command data (PIRI Fig 3A-3B and text on [0072-0075] teaches the WebAuthn API 205 is used to send an authentication request 305 initiated by the relying party application 120 to the physical device 220 through a standard transport such as USB, which then forward the authentication request 315 to a previously paired companion device 115 holding an authenticator 125).
Regarding claim 63 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the application or operating-system authentication component comprises an operating- system logon service (PIRI on [0069-0072] teaches login or registration service. Further teaches the physical device 220 then establishes a wireless secure communication connection with the companion device).
Regarding claim 64 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the relying computing device comprises a workstation (PIRI on [0058] teaches the computing devices 110 can include, for example tablets, PCs (personal computers), laptops, gaming consoles, or the like. The various devices in the environment can support different features, functionalities, and capabilities. For example, some devices 110 can support touch controls, gesture recognition, and voice commands, while others may enable a more limited user interface. Some devices may support video consumption and Internet browsing, while other devices may support more limited media handling and network interface features).
Regarding claim 65 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the local wireless transport comprises Bluetooth, Wi-Fi, near-field communication, optical communication, or sound-wave communication (PIRI on [0060 and 0077] teaches the computing device 110 and the authenticator communicate with each other using physical or virtual device over local wireless network such as Bluetooth, WiFi etc. See also Fig 3A-3B and associated text discloses cross device authentication between authenticator and relying device).
Regarding claim 66 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the instructions further cause the mobile device to advertise an authentication service discoverable by the relying computing device before the cross-device authentication session is established (PIRI on [0067] teaches the physical device 220 that receives the authentication requests through the OS software protocol 215 is configured to detect a nearby companion device 115 using RSSI signal monitoring to connect to the companion device 115, and exchange the authentication requests/responses over a wireless personal network 245 such as Bluetooth Low Energy protocol with the authenticator 125 on the companion device 115).
Regarding claim 69 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the private key is not transmitted to the relying computing device (PIRI on [0069 and 0071] teaches the user controls the private key).
Regarding claim 70 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the public-key authentication request comprises a challenge, and the authenticator response data comprises a signature over the challenge (PIRI on [0070] teaches the relying party application 120 registers a user the first time by sending a registration request to the authenticator, and receiving a response that is signed by the authenticator 125. Subsequently, when the relying party application 120 logs into the registered user, the relying party sends a login request and receives a login response that is signed by the same authenticator 125).
Regarding claim 71 PIRI teaches all the limitations of claim 70 above, PIRI further teaches wherein the authenticator response data includes an indication that the user was verified locally at the mobile device (PIRI on [0073-0076] teaches the authenticator 125 processes the request, provides a response 320 and replies it back to the physical device 220 as the authentication response 325 which then forwards to the relying device 110. The authenticator 125 can implement different operations such as authentication (i.e., verifying user at device 115), registration, and other authenticator operations such as setting passwords, and so on.).
Regarding claim 72 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the instructions cause the mobile device to select the credential from a plurality of credentials based on an identifier included in the command data (Avetisov on [0088] teaches the authentication application 120 may provide an identifier to the TEE 103, and the TEE may return a shared key by which the authentication application 120 and TEE 103 can securely exchange data over a channel for the duration of the session. In some embodiments, the shared key generated by the TEE 103 is based on the identifier. See on [0102-0103] teaches the relying party server 145 may transmit information about access attempt to the authentication server 155. The forwarded information may include the one or more identifiers determined from the UID repository 160 to correspond to the access attempt, in addition to information received from, or determined about, the client device 135. In turn, the relying party server 145 may receive an authentication result from the authentication server 155. The authentication result indicates whether the user of the client device 135 successfully authenticated with the authentication server 155 (e.g., via the mobile device 101). Further teaches the relying party server 1345 may also determine whether a password or other credential received from the client device 135 matches a corresponding credential stored in association with a user identifier or device identifier within the UID repository 160)
Regarding claim 73 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the mobile authenticator application supports both FIDO2-compatible command data and smart-card-compatible command data received from the relying computing device (PIRI on [0042] teaches when using WebAuthn API to access an authenticator from a browser application to perform authentication compliant with FIDO Alliances standards including FIDO 2.0, FIDO 2.1, and etc., it is possible for the computing device to be coupled to the authenticator through an interface, such as Universal Serial Bus (USB), using a Client-to-Authenticator Protocol (CTAP)).
Regarding claim 74 PIRI teaches all the limitations of claim 55 above, PIRI further teaches wherein the command data comprises authentication-protocol packet data repackaged by the relying computing device from packets received through the virtual authenticator interface (PIRI on [0042] teaches when using WebAuthn API to access an authenticator from a browser application to perform authentication compliant with FIDO Alliances standards including FIDO 2.0, FIDO 2.1, and etc., it is possible for the computing device to be coupled to the authenticator through an interface, such as Universal Serial Bus (USB), using a Client-to-Authenticator Protocol (CTAP)).
Claim Rejections - 35 USC § 103
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 62, 67, 68 and 75 are rejected under 35 U.S.C. 103 as being unpatentable over PIRI et al (hereinafter PIRI) (US 20230063417) in view of Avetisov et al (hereinafter Avetisov) (US 20200067907)
Regarding claim 62 PIRI teaches all the limitations of claim 60 above, PIRI fails to explicitly teach certificate-based credential, however Avetisov from analogous art teaches wherein the credential comprises a certificate-based smart-card credential (Avetisov on [0164-0165] teaches certificate-based credential).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Avetisov into the teaching of PIRI by using certificate-based credential. One would be motivated to do so in order to perform authentication and authorize the user to access resource based on certificate-based credential (Avetisov [0165]).
Regarding claim 67 PIRI teaches all the limitations of claim 55 above, PIRI fails to explicitly teach wherein verifying the user locally comprises verifying a biometric or a personal identification number at the mobile device, however Avetisov from analogous art teaches verifying a biometric or a personal identification number at the mobile device (Avetisov on [0047-0049] teaches biometric of PIN code verification).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Avetisov into the teaching of PIRI by performing biometric authentication of the user. One would be motivated to do so in order to perform authentication and authorize the user to access resource based biometric authentication (Avetisov [0040]).
Regarding claim 68 PIRI teaches all the limitations of claim 55 above, PIRI fails to explicitly teach wherein the private key is protected by a trusted execution environment, secure element, or secure storage of the mobile device, however Avetisov from analogous art teaches wherein the private key is protected by a trusted execution environment, secure element, or secure storage of the mobile device (Avetisov on [0062] teaches storing private key in trusted execution environment).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Avetisov into the teaching of PIRI by securely storing private key. One would be motivated to do so in order protect the private key from unauthorized access (Avetisov [0040]).
Regarding claim 75 PIRI teaches all the limitations of claim 55 above, PIRI further teaches
wherein the authentication service is a locally discoverable authentication service advertised over the local wireless transport (PIRI on [0067] teaches the physical device 220 that receives the authentication requests through the OS software protocol 215 is configured to detect a nearby companion device 115 using RSSI signal monitoring to connect to the companion device 115, and exchange the authentication requests/responses over a wireless personal network 245 such as Bluetooth Low Energy protocol with the authenticator 125 on the companion device 115);
wherein the virtual authenticator interface is a virtual device interface configured by the relying computing device to report to the application or operating-system authentication component as an attached authenticator device (PIRI on [0043] teaches USB is a hardware protocol and a software protocol. USB Interfaces that reference HID do use the HID USB software protocol and use the HID (human interface device) drivers to communicate with hardware devices. A virtual device driver is a software device driver that emulates hardware and other devices so that multiple applications can access hardware interrupt channels, hardware resources, and memory without causing conflicts. A virtual HID driver, for example, can be installed on an operating system of a computing device to simulate a standard authenticator on a USB interface to receive the authentication request).
wherein the authentication-protocol packets comprise authenticator-protocol command packets received through the virtual device interface (PIRI Fig 3A-3B and text on [0072-0075] teaches the he WebAuthn API 205 is used to send an authentication request 305 initiated by the relying party application 120 to the physical device 220 through a standard transport such as USB, which then forward the authentication request 315 to a previously paired companion device 115 holding an authenticator 125. Further teaches the virtual driver 225 as part of virtual assistant device 235 receives the authentication request 305, sent by a relying party application 120 on a computing device 110 using WebAuthn API 205. The assistant service 230 or the virtual driver 225 inside the virtual assistant device 235 then establishes a secure connection with the companion device 115, and forwards the authentication request 315 to be processed on the authenticator 125);
wherein the command data encapsulates at least a portion of the authenticator-protocol command packets for transmission over the local wireless transport (PIRI Fig 3A-3B and text on [0072-0075] teaches the he WebAuthn API 205 is used to send an authentication request 305 initiated by the relying party application 120 to the physical device 220 through a standard transport such as USB, which then forward the authentication request 315 to a previously paired companion device 115 holding an authenticator 125. Further teaches the virtual driver 225 as part of virtual assistant device 235 receives the authentication request 305, sent by a relying party application 120 on a computing device 110 using WebAuthn API 205. The assistant service 230 or the virtual driver 225 inside the virtual assistant device 235 then establishes a secure connection with the companion device 115, and forwards the authentication request 315 to be processed on the authenticator 125);
wherein the private key is (PIRI on [0069 and 0071] teaches the user controls the private key);
and wherein the authenticator response data comprises response packet data corresponding to the authenticator-protocol command packets for return through the virtual device interface (PIRI on [0073-0076] teaches the authenticator 125 processes the request, provides a response 320 and replies it back to the physical device 220 as the authentication response 325 which then forwards to the relying device 110. The authenticator 125 can implement different operations such as authentication (i.e., verifying user at device 115), registration, and other authenticator operations such as setting passwords, and so on).
PIRI fails to explicitly teach wherein the private key is protected by secure storage of the mobile device and is not transmitted to the relying computing device, however Avetisov teaches wherein the private key is protected by secure storage of the mobile device and is not transmitted to the relying computing device (Avetisov on [0062] teaches storing private key in trusted execution environment).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Avetisov into the teaching of PIRI by securely storing private key. One would be motivated to do so in order protect the private key from unauthorized access (Avetisov [0040]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOEEN KHAN whose telephone number is (571)272-3522. The examiner can normally be reached 7AM-5PM EST M-TH Alternate Fridays.
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, Shewaye Gelagay can be reached on (571)272-4219. 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.
/MOEEN KHAN/ Primary Examiner, Art Unit 2436
Prosecution Insights