DETAILED ACTION
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 .
Information Disclosure Statements
The information disclosure statement (IDS) submitted on July 21, 2025 (for which the timing fee was paid), the IDS submitted on November 5, 2025 (for which the timing fee was paid), and the IDS submitted on December 10, 2025 (for which the first timing statement was made). It is noted that not all copies of the required references accompanied these IDS statements, but have been included with the present 892. The submissions are therefore in compliance with the provisions of 37 CFR 1.97(b)(3) and have been considered by the Examiner, except that any foreign documents were only considered with respect to the statement of relevance represented by any English translations of the Abstracts of the subject foreign documents.
Drawings
The drawings are again objected to because the lines, numbers, and letters are not durable, clean, black, sufficiently dense and dark, and uniformly thick and well-defined in Figures 1, 3A through 3C, 5A through 5M, 6D, 6H, 6J, 7A through 7C, 9A through 9J, 10A through 10I, 11A through 11C, 12A, 12B, 13A through 13E, 14A through 14C, 15A through 15C, and 17A. The cited Figures include grayscale which cause the lines, numbers, and letters to not be durable, clean, black, sufficiently dense and dark, and uniformly thick and well-defined. Additionally, drawings must be black and white (monochrome) except when another form (grayscale or color) is the only practicable medium for illustrating the claimed invention. For the cited Figures, black and white drawings are sufficient to illustrate the claimed invention. Black and white drawings should be created and filed in monochrome, black only, no gray.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office Action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended”. If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. The replacement sheet(s) should be labeled “Replacement Sheet” in the page header (as per 37 CFR 1.84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not accepted by the Examiner, the Applicant will be notified and informed of any required corrective action in the next Office Action. If a response to the present Office Action fails to include proper drawing corrections, corrected drawings or arguments therefor, the response can be held NON-RESPONSIVE and/or the application could be ABANDONED since the objections/corrections to the drawings are no longer held in abeyance.
Amendments
The present Office Action is based upon the original patent application filed on March
30, 2023 as modified by the preliminary amendment filed on March 30, 2023, in which claims 1-55 were canceled, and claims 56-75 were added, and as further modified by the Amendment filed October 10, 2025, in which claims 56-68, 71-72, and 75 are canceled, and new claims 76 to 106 are added. Claims 69-70, 73-74, and 76-106 are therefore pending in the present application.
Claim Objection
Claim 84 is objected to for a minor informality, as follows:
Claim 84, line 16, recites “second electronic device configured to”, which should read “second electronic device is configured to”.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre‐AIA 35 U.S.C. § 102 and § 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre‐AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same
under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness
rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under
35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 69, 70, 73, 74, 76 to 82, and 84 to 106 are rejected under 35 U.S.C. § 103 as unpatentable over U.S. Patent No. 11,347,834 to Marchand et al. (“the Marchand reference”), in view of Hintze et al., CORMORANT: Ubiquitous Risk-Aware Multi-Modal Biometric Authentication across Mobile Devices, Proc. ACM Interact. Mob. Wearable Ubiquitous Technol., Vol. 3, No. 3, Article 85 (September 2019) (“the Hintze reference”), for the following reasons.
Independent claim 69, as amended, is directed to a “first electronic device” comprising a “memory configured to store instructions” and “one or more processors coupled to the memory” and “configured to” perform the recited method steps.
In this regard, the Marchand reference discloses (at col. 4, lines 28-47; col. 5, lines 60-65; Figure 1), the following:
Aspects and implementations of the disclosure are directed to an automated sign-in into a first screen device. A first-screen device may be a network-connected television device (“smart TV”)—which is a first electronic device, over-the-top (OTT) streaming devices, set top boxes, Blu-ray players, operator boxes, etc. An operating system runs on a first-screen device and may provide a platform for applications to be hosted by the first-screen device. Applications can be preloaded on the first-screen device and/or installed on the first-screen device via an application distribution platform. Applications running on a first-screen device can provide access to platforms via a network for one or more of media-sharing, making purchases, social networking, playback of media items, etc. A user can sign into and perform account authentication in an application hosted by a first-screen device to access playlists saved to an account, make purchases via an account, access a social network corresponding to an account, etc. Signing in and account authentication on first-screen devices is typically a laborious process for a user.
. . . .
FIG. 1 illustrates an example system architecture 100, in accordance with one implementation of the disclosure. The system architecture 100 includes application distribution server 110, first-screen device 120, authentication server 130, local network 140, a network 150, a data store 160, and a second-screen device 170.
In particular, the architecture of the communication system 10 of Figure 1 of the instant application is essentially identical to that of the system architecture 100 of Figure 1 of the Marchand reference. The first screen device, such as a smart TV, would necessarily include a memory configured to store instructions, and one or more processors coupled to the memory and configured to perform the recited method steps.
Accordingly, the Marchand reference discloses or at least suggests the limitations of a “first electronic device” comprising a “memory configured to store instructions” and “one or more processors coupled to the memory” and “configured to” perform the recited method steps.
Still further, claim 69, as amended, recites the further limitations of “receiv[ing] a first operation by a user” and “perform[ing] a local authentication in response to the first operation”.
It is first noted that the instant specification admits (at paragraph [0055]) that the order or sequence of any method steps is not limited, since it admits the following:
[0055] The terms “first” and “second” mentioned below are merely intended for a purpose of description, and shall not be understood as an indication or implication of relative importance or implicit indication of a quantity of indicated technical features. Therefore, a feature limited by “first” and “second” may explicitly or implicitly include one or more features. In the descriptions of the embodiments of this application, unless otherwise specified, “a plurality of” means two or more. A method procedure . . . may include more or fewer steps, and a specific sequence of the steps may not be limited. The method procedure . . . is merely an example, and should not be construed as a limitation on this embodiment of this application.
Thus, the applicant essentially admits that the sequence or order of steps or the first, second, and/or third designations are not limiting—and are therefore not patentable distinctions as to the prior art.
With respect to “receiv[ing] a first operation by a user” and “perform[ing] a local authentication in response to the first operation”, the instant application (at paragraphs [0343]-[0345]) states the following:
[0343] S301: A first electronic device receives a first operation.
[0344] In this embodiment of this application, the first electronic device may be the electronic device 100 in the foregoing embodiments. In some embodiments, the first operation may be a voice instruction received by the electronic device 100 in the foregoing voice control scenarios. . . . [The] first operation may be a casting operation received by the electronic device 100 in the foregoing casting control scenarios. [The] first operation may be that a user taps an option 401A of an electronic device 200 shown in FIG. 9B. [The] first operation may be a touch operation indirectly received by the electronic device 100 by using [(namely, a user)] the electronic device 200 in Casting control scenarios 2 to 4. It should be noted that, after receiving a touch operation of the user, the electronic device 200 may send a touch parameter of the touch operation to the electronic device 100, and the electronic device 100 determines a trigger event corresponding to the touch operation, and further performs a corresponding response operation. For example, the first operation may be that the user taps an icon 404C of Music in a casting window 403 shown in FIG. 10A.
[0345] S302: In response to receiving the first operation, the first electronic device detects whether a local authentication result of the first electronic device is that authentication succeeds.
Thus, the operation includes, for example, a user using a voice instruction input to the
electronic device, such as, for example, a smartphone, or tapping the electronic device/smartphone to determine whether the local authentication succeeds by providing access to the user.
With respect to “perform[ing] a local authentication in response to the first operation”, the instant application discloses (at paragraphs [0062]-[0064]) the following:
[0062] . . . Local continuous authentication means that an electronic device may continuously perform identity authentication on a user within a detection range by using a technical means such as facial recognition, iris recognition, or screen touch behavior recognition. In addition to authentication manners such as facial recognition, fingerprint recognition, and screen touch behavior recognition, in this embodiment . . . , identity authentication may be continuously performed on the user in another authentication manner, for example, fingerprint recognition, gait recognition, and heart rate recognition. In this embodiment of this application, single identity authentication may also be referred to as local authentication. A local authentication result may be an authentication result obtained after an electronic device performs identity authentication in one or more authentication manners such as facial recognition, fingerprint recognition, and screen touch behavior recognition, and is used to represent whether identity authentication succeeds. In this embodiment of this application, identity authentication information may include a local authentication result, or may include biometric feature information collected by the electronic device in one or more authentication manners such as facial recognition, fingerprint recognition, and screen touch behavior recognition. In some embodiments, the electronic device may periodically perform local continuous authentication, and a result of one time of local authentication may include whether the local authentication succeeds, or may include a timestamp of the local authentication.
[0063] For example, an electronic device 100 prestores biometric feature information 1 of a user 1, and the biometric feature information 1 is used to verify an identity of the user 1. During local continuous authentication, when a matching degree between biometric feature information 1 and biometric feature information collected by the electronic device 100 by using a technical means such as facial recognition, fingerprint recognition, or screen touch behavior recognition reaches a preset threshold 1, the electronic device 100 may determine that local authentication of the user 1 succeeds. For example, the preset threshold 1 is equal to 90%.
[0064] It should be noted that, in some embodiments, after the user performs screen unlocking, the electronic device may perform local continuous authentication. When the user enters a locked application or a locked application function, if identity authentication in local continuous authentication of the electronic device succeeds, the electronic device can enter the application or the application function without a need to receive an unlocking operation of the user in an unlocking interface of the application or the application function.
Thus, as best understood with respect to the limitation of “perform[ing] a local authentication in response to the first operation”, this limitation is understood to encompass, for example, local authentications using a first authentication, such as, for example, facial recognition, fingerprint recognition, or screen touch behavior recognition (as well as a second authentication, such as, for example, facial recognition, fingerprint recognition, or screen touch behavior recognition).
Claim 69, as amended, recites the further limitations of “perform[ing] cross-device authentication using a second electronic device connected to the first electronic device when a local authentication result indicates that the local authentication fails”, and “obtain[ing] a cross-device authentication result of the cross-device authentication”.
That is, the authentication server 130 would only generate an authentication code for the first-screen device if the user has been authenticated. Otherwise, if the user has not been authenticated, an authentication code will not be generated, which means that the first local authentication has failed, so that the first-screen (and necessarily its first application) is necessarily locked and/or otherwise unavailable to the user.
In this regard, the Marchand reference specifically discloses (at col. 7, line 53 to col. 8, line 11; and Figure 1) the following:
Authentication server 130 may include a user authentication manager 132. User authentication manager 132 may receive a request from a first-screen device 120 for user authentication for automated user login into a first application 602 hosted by the first-screen device 120. The user authentication manager 132 may generate an authentication code 114 and transmit the authentication code 114 to the first-screen device 120. The user authentication manager 132 may store the authentication code 114 in data store 160. Subsequently, the user authentication manager may receive the authentication code 114 from the second-screen device 170 and perform user authentication for the automated user login into the first application 602 hosted by the first-screen device 120. The user authentication manager 132 may compare the authentication code 114 received from the second-screen device 170 with the authentication code 114 stored in the data store 160 [from the first screen-device] to determine that the authentication codes [of the first-screen device and the second-screen device] match. The user authentication manager 132 may receive an indication of an account from the second-screen device 170 and may perform the user authentication for the automated user login into the account in the first application 602.
Thus, the Marchand reference discloses cross-device authentication, since it discloses that a user authentication manager may generate an authentication code 114 that is transmitted to the first-screen device 120, and that the user authentication manager requests and receives the authentication code 114 from the second-screen device 170 to perform user authentication for a user to access the first-screen device 120.
That is, the first screen device uses a requested authentication code from the second-screen device to authenticate access for the user of the first-screen device. In particular, a cross-device authentication result is obtained for the cross-device authentication, since the user authentication manager compares the authentication code 114 of the second-screen device 170 with the stored authentication code 114 (from the first screen-device) to determine that the authentication codes [of the first-screen device and the second-screen device] match to allow access to the first-screen device—based on the authentication code of the second-screen device.
Accordingly, the Marchand reference discloses the further limitations of “perform[ing] cross-device authentication using a second electronic device connected to the first electronic device when a local authentication result indicates that the local authentication fails”, and “obtain[ing] a cross-device authentication [(that is, an authentication result of the second electronic device)] result of the cross-device authentication [(that is, authentication result of the second electronic device)]”.
Still further, claim 69, as amended, recites the limitation of “detect[ing] a distance between the first electronic device and the second electronic device”, and further recites the further limitation of “execut[ing] an instruction corresponding to the first operation when the cross-device authentication result indicates that the cross-device authentication succeeds and the distance is less than a preset distance”.
To the extent that the Marchand reference may not explicitly disclose, the further limitation of “detect[ing] a distance between the first electronic device and the second electronic device”, and the further limitation of “execut[ing] an instruction corresponding to the first operation when the cross-device authentication result indicates that the cross-device authentication succeeds and the distance is less than a preset distance”, the following is submitted:
In this regard, the Hintze reference discloses (at page 85:5, 4th paragraph; page 85:7, 1st paragraph), multi-modal (that is, a local authentication, including multiple (e.g., first, as well as second) authentications) cross-device (that is, multiple (e.g., first and second electronic devices) authentication, as follows:
For estimating the distance between devices, different techniques and signals can be used, for instance GPS, WiFi, GSM, UWB, and Bluetooth [3, 29, 69]. . . .
. . . .
[The] authentication . . . on both devices are [not] taken into account . . . as their distance exceeds a certain threshold. . . .
Still further, the Hintze reference discloses (at pages 85:1, 1st paragraph-85:2, paragraphs 5-9), multi-modal (that is, a local authentication, including multiple (e.g., first, as well as second) authentications) cross-device (that is, multiple (e.g., first and second electronic devices) authentication, as follows:
We present . . . an approach to significantly reduce the manual burden of mobile user verification through risk-aware, multi-modal biometric, cross-device authentication. Transparent behavioral and physiological biometrics like gait, voice, face, and keystroke dynamics are used to continuously evaluate the user’s identity without explicit interaction. The required level of confidence in the user’s identity is dynamically adjusted based on the risk of unauthorized access derived from signals like location, time of day and nearby devices. Authentication results are shared securely with trusted [multiple] devices to facilitate cross-device authentication for co-located devices.
. . . .
Approaches towards multi-modal biometric authentication systems proposed so far usually operate on a single device [62] only. With the increasing number of different interconnected devices owned and used by a single individual, it seems desirable to extend the scope [of multi-modal biometric authentication systems] . . . . to leverage contextual and biometric information gathered within a group of trusted devices to increase both security and usability. . . .
In this paper, we . . . present . . . a novel approach towards risk-aware, multi-modal biometric, cross-device continuous user authentication across multiple trusted mobile devices. . . .
• . . . dynamically combining explicit and implicit authentication mechanisms with continuous risk estimation, shared securely across a group of trusted devices to significantly reduce explicit authentication overhead and increase security at the same time.
• . . . fuse authentication scores in a set of dynamic biometrics across different devices, taking risk, uncertainty, and device distance into account.
• . . . dynamic authentication approaches that measures security and usability precisely and facilitates the comparison with conventional authentication measures . . . .
Thus, biometrics (by a user) like gait, voice, face, and/or keystroke are used to continuously evaluate the user’s identity using explicit and/or implicit input operations, such as, for example, gait (movement), voice, face, and/or keystroke, etc., so as to provide multi-modal (multiple) authentications based on multiple biometrics across multiple trusted mobile devices. Accordingly, the Hintze reference discloses multiple trusted mobile devices—which necessarily includes a first electronic device and a second electronic device.
Still further, the Hintze reference plainly discloses that the distance is measured between the first and second devices using, for example, GPS, WiFi, or Bluetooth, and that there is no cross-authentication as the distance exceeds a threshold—which means that there is cross-authentication when the distance is less than the threshold. It is well known that if the distance is too great between the devices there is no cross-authentication, since a connection cannot be made by Bluetooth, for example.
Still further, it is noted that fusing authentication scores in a set of dynamic biometrics across different devices means that at least two authentication tests must satisfy an authentication (access) threshold, as disclosed by the Hintze reference (at page 85:7, paragraphs 1-3, paragraphs 1-3; and sections 4.1-4.2 at pages 85:8-85:10).
Accordingly, the Hintze reference discloses or at least suggests the limitations of
“receiv[ing] a first operation by a user” and “perform[ing] a local authentication in response to the first operation”.
The Marchand and Hintze references are in the same field of endeavor as the claimed subject matter since they each concern user authentications systems for at least first and second (multiple) electronic devices. Accordingly, a person having ordinary skill in the art would consider the Hintze reference for including the capability of providing for receiving a first operation by a user, and performing a local authentication in response to the first operation.
It is therefore the case that it would have been obvious to a person having ordinary skill in the art before the effective date filing date of the claimed invention to modify the primary Marchand reference, based on the teachings, motivations and/or suggestions of the secondary Hintze reference, so as to include the capability of providing for receiving a first operation by a user, and performing a local authentication in response to the first operation.
Thus, the Hintze reference discloses the use of distance between the electronic devices and executing an instruction when the distance is not less than some threshold (preset) (at pages 85:5-85:7), as follows:
Since people increasingly carry and use multiple devices simultaneously, the third pillar of CORMORANT is to leverage authentication and risk information established on a single device on other devices belonging to the same user. To that end, a secure, end-to-end encrypted communication between trusted devices is established. The confidence and risk measurements of individual plugins are periodically broadcast within the group, along with location information. This allows, for instance, for a device to be accessible if it is in close proximity to a device that has successfully established the user’s identity. For estimating the distance between devices, different techniques and signals can be used, for instance GPS, WiFi, GSM, UWB, and Bluetooth [3, 29, 69]. . . .
3.2 Example Scenario For a better understanding, we illustrate how the proposed system would function using a short practical example, with fig. 1 depicting the system state over time: A CORMORANT user is walking to a café, carrying an idle notebook in their backpack as well as a mobile phone in their pocket. A gait recognition plugin is active on the phone and identifies the walking user with a certain confidence. Reaching the café at t5min, the user sits down at a table, opening their notebook. The notebook discovers the trusted phone in close proximity and therefore utilizes the authentication confidence provided by the gait authentication plugin running on the phone, instantly allowing access without prompting for explicit authentication. Working on the notebook, a keystroke dynamics authentication plugin provides implicit authentication, starting at t6min after the plugin has collected enough information to report its confidence in the user’s presence. With authentication scores being frequently exchanged between devices and their relative distance constantly monitored, the phone now utilizes the confidence continuously reported by the keystroke dynamics plugin on the notebook.
. . . .
At t11min, the remote authentication plugins on both devices are no longer taken into account for computing the overall confidence as their distance exceeds a certain threshold. The phone now relies on the gait authentication plugin alone. Since the user is not constantly walking in the café, the confidence estimation of the gait authentication is lower compared to the confidence earlier in the example. The notebook now has no active authentication plugin and the overall confidence decays over time.
At t13min, the notebook is stolen from the table by an opportunistic thief walking out of the café unnoticed. Due to the constant decay of the overall confidence estimation, the score level of the notebook is below the current access threshold, so the thief is unable to access the device automatically, without interaction required by the genuine user.
Upon returning to the table, the user notices that their notebook has been stolen and removes the stolen device from the group of trusted devices. Since the overall confidence is below the access threshold, the user is challenged with an explicit authentication using their fingerprint at time t15min to increase the overall confidence over the threshold level.
The Marchand and Hintze references are in the same field of endeavor as the claimed subject matter since they each concern user authentications systems for at least first and second (multiple) electronic devices. Accordingly, a person having ordinary skill in the art would consider the Hintze reference for including the capability of detecting a distance between the first electronic device and the second electronic device, and executing the first instruction corresponding to the first operation when the distance is less than a first preset distance.
It is therefore the case that it would have been obvious to a person having ordinary skill in the art before the effective date filing date of the claimed invention to modify the primary Marchand reference, based on the teachings, motivations and/or suggestions of the secondary Hintze reference, so as to include the capability of detecting a distance between the first electronic device and the second electronic device, and executing the first instruction corresponding to the first operation when the distance is less than a first preset distance.
Thus, the Marchand and Hintze references disclose or at least suggest the further limitations of the limitation of “detect[ing] a distance between the first electronic device and the second electronic device”, and further recites the further limitation of “execut[ing] an instruction corresponding to the first operation when the cross-device authentication result indicates that the cross-device authentication succeeds and the distance is less than a preset distance”.
As further regards the claim 69 limitation of “execut[ing] an instruction corresponding to the first operation when the cross-device authentication result indicates that the cross-device authentication succeeds and the distance is less than a preset distance”, authentication information (the authentication code) is received from the second electronic device (the second-screen device), and when the authentications match, access is allowed to the first-screen device—based on the authentication code of the second-screen device, so that an instruction is necessarily executed corresponding to the operation (voice, touch, etc.) when the authentication (third) succeeds (by matching the first authentication).
Accordingly, claim 69, as amended, is unpatentable over the Marchand reference in view of the Hintze reference for the foregoing reasons.
Claim 70, as amended, depends from claim 69, and it recites the further limitations in which the “one or more processors are further configured to”: “send, to the second electronic device connected to the first electronic device, a second request message requesting to obtain identity authentication information of the second electronic device”, “receive, from the second electronic device, a second response message comprising the identity authentication information”, and in which “obtaining the cross-device authentication result [(that is, an authentication result of the second electronic device)] comprises generating the cross-device authentication result [(that is, authentication result of the second electronic device)] based on the identity authentication information”.
In this regard, as explained above as to the Marchand reference (and claim 69),
requested authentication information (an authentication code, which is identity authentication information) is received from the first electronic device (the first-screen device), and requested authentication information (another authentication code, which is identity authentication information) is received from the second electronic device (the second-screen device). When the authentication codes (identity authentication information) match, a cross-device authentication generated based on the identity authentication information (in response to authenticating the first operation), and access is allowed to the first-screen device—based on the authentication code of the second-screen device, so that an instruction is necessarily executed corresponding to the operation (voice, touch, etc.) when the cross-device authentication (third) succeeds (by matching the first authentication).
In short, the Marchand reference discloses or at least suggests the further limitations in which the “processor is further configured to”: “send, to the second electronic device connected to the first electronic device, a second request message requesting to obtain identity authentication information of the second electronic device”, “receive, from the second electronic device, a second response message comprising the identity authentication information”, and in which “obtaining the cross-device authentication result [(that is, an authentication result of the second electronic device)] comprises generating the cross-device authentication result [(that is, authentication result of the second electronic device)] based on the identity authentication information”.
Accordingly, claim 70 is unpatentable over the Marchand reference in view of the Hintze reference for the same reasons as claim 69, and for the further foregoing reasons.
Claim 73, as amended, depends from claim 70, and it recites the further limitations in which the “memory is further configured to store preset information”, and in which the “one or more processors are further configured to”: “match the identity authentication information of the user with the preset information”, and “identify, based on a matching result, whether the local authentication result indicates that the local authentication succeeds”.
In this regard, the Marchand reference specifically discloses (at col. 7, line 53 to col. 8, line 11; and Figure 1) the following:
Authentication server 130 may include a user authentication manager 132. User authentication manager 132 may receive a request from a first-screen device 120 for user authentication for automated user login into a first application 602 hosted by the first-screen device 120. The user authentication manager 132 may generate an authentication code 114 and transmit the authentication code 114 to the first-screen device 120. The user authentication manager 132 may store the authentication code 114 . . . . Subsequently, the user authentication manager may receive the authentication code 114 from the second-screen device 170 and perform user authentication for the automated user login into the first application 602 hosted by the first-screen device 120. The user authentication manager 132 may compare the authentication code 114 received from the second-screen device 170 with the authentication code 114 stored in the data store 160 [from the first screen-device] to determine that the authentication codes [of the first-screen device and the second-screen device] match. The user authentication manager 132 may receive an indication of an account from the second-screen device 170 and may perform the user authentication for the automated user login into the account in the first application 602.
That is, the authentication server 130 would only generate an authentication code for
the first-screen device if the user has been authenticated, in which case once the second-screen device obtains an authentication code, the authentication codes can be compared to establish a further authentication when the codes match. Otherwise, if the user has not been authenticated, an authentication code will not be generated, which means that the first local authentication has failed, so that the first-screen (and necessarily its first application) is necessarily locked and/or otherwise unavailable to the user.
It is first noted that any biometric systems, which are well known, necessarily require a preset or reference biometric data—identity information—to match exactly or within a threshold (e.g., face or fingerprint matches may never be exact) to the currently obtained or measured biometric data—identity information. Thus, a first authentication succeeds when the matching result is the same as or greater than a first preset threshold.
Still further and in particular, the Hintze reference discloses (at page 85:8-10) the following:
4.1 Max Weighted Score Threshold Fusion We developed a max weighted score threshold algorithm, which is simple to implement and computationally efficient. Each individual plugin is assigned a static weight (W ). On every tick, all co-located trusted devices, including the device running the algorithm, are iterated and all active confidence plugins are queried for the highest confidence value. Confidence results from remote devices are adjusted by a remote factor, allowing to put less trust in those devices. Risk-plugins are queried on the local device for the maximum risk value.
The previous confidence is degenerated by a constant component as well as a risk dependent component. The constant factor can be configured independently for different device types (e.g., smartphone vs notebook) as well as whether the device is actively used or idle (D-act vs. D-idle ). It ensures that confidence erodes over time if not reinforced. The risk-dependent component ensures the level of confidence required corresponds to the current risk assessment. This is achieved by subtracting the current risk multiplied by a constant α-risk from the previous confidence.
The algorithm compares the maximum of the current confidence and the degenerated previous confidence against a constant threshold and grants access to the device if the confidence is equal or greater than the threshold. Algorithm 1 specifies the max weighted score threshold fusion algorithm in detail.
. . . .
The algorithm compares the current mean confidence against a constant threshold and grants access to the device if the mean confidence is equal or greater. Algorithm 2 specifies the mean weighted score threshold fusion algorithm in detail.
Thus, the Marchand and Hintze references disclose or at least suggest the further limitations in which the “memory is further configured to store preset information”, and in which the “one or more processors are further configured to”: “match the identity authentication information of the user with the preset information”, and “identify, based on a matching result, whether the local authentication result indicates that the local authentication succeeds”.
The Marchand and Hintze references are in the same field of endeavor as the claimed subject matter since they each concern user authentications systems for at least first and second (multiple) electronic devices. Accordingly, a person having ordinary skill in the art would consider the Hintze reference for including the capability of providing for matching the identity authentication information of a user with the preset information, and identifying, based on a matching result, whether the local authentication result indicates that the local authentication succeeds.
It is therefore the case that it would have been obvious to a person having ordinary skill in the art before the effective date filing date of the claimed invention to modify the primary Marchand reference, based on the teachings, motivations and/or suggestions of the secondary Hintze reference, so as to include the capability of providing for matching the identity authentication information of a user with the preset information, and identifying, based on a matching result, whether the local authentication result indicates that the local authentication succeeds.
Accordingly, claim 73 is unpatentable over the Marchand reference in view of the Hintze reference for the same reasons as claims 70 and 69, and for the further foregoing reasons.
Claim 74 depends from claim 69, and it recites the further limitations in which the “first operation is one of” “[A] a screen unlocking operation, [B] an application unlocking operation, or [C] an operation performed on a functional control in an application”.
Since the claim is in the form of alternative elements, namely A, B, or C, only one of the claim elements needs to be established to satisfy the claim.
In particular, the Marchand reference specifically discloses (at col. 7, line 53 to col. 8, line 11; col. 9, lines 5-40; col. 10, lines 3-43; and Figure 1) the following:
Authentication server 130 may include a user authentication manager 132. User authentication manager 132 may receive a request from a first-screen device 120 for user authentication for automated user login into a first application 602 hosted by the first-screen device 120. The user authentication manager 132 may generate an authentication code 114 and transmit the authentication code 114 to the first-screen device 120. The user authentication manager 132 may store the authentication code 114 in data store 160. Subsequently, the user authentication manager may receive the authentication code 114 from the second-screen device 170 and perform user authentication for the automated user login into the first application 602 hosted by the first-screen device 120. The user authentication manager 132 may compare the authentication code 114 received from the second-screen device 170 with the authentication code 114 stored in the data store 160 [from the first screen-device] to determine that the authentication codes [of the first-screen device and the second-screen device] match. The user authentication manager 132 may receive an indication of an account from the second-screen device 170 and may perform the user authentication for the automated user login into the account in the first application 602.
. . . .
In the example shown in FIG. 1, first-screen device 120 may include a first application login component 122, a device identifier component 124, a message component 126, a prompt component 128, and a data store 129.
First application login component 122 may manage requests to login to a first application hosted by the first-screen device 120, receive the authentication code 114, and receive credentials to login to the first application. Device identifier component 124 may receive and send SSDP messages for the second-screen device 170 to identify the first-screen device. The message component 126 may receive, generate, and send messages (e.g., DIAL URL request, DIAL URL response, messages of another type of protocol, etc.) to transfer the authentication code 114 to the second-screen device 170. Prompt component 128 may display prompts and receive user input.
. . . .
In the example shown in FIG. 1, second-screen device 170 may include a second application login component 172, a device identifier component 174, a message component 176, a prompt component 178, and a data store 179.
Second application login component 172 may login to a second application hosted by the second-screen device 170. Device identifier component 174 may send and receive SSDP messages to identify the first-screen device 120 as being on the same network (e.g., local network 140) as the second-screen device 170. The message component 176 may send, receive, and decode messages (e.g., DIAL URL request, DIAL URL response, messages of another type of protocol, etc.) to determine the authentication code 114. Prompt component 178 may provide a prompt, receive user input indicating user acceptance of user authentication for the automated login of the first application hosted by the first-screen device 120, and transmit the authentication code to the authentication server 130.
Thus, the Marchand reference discloses that a user authentication manager may generate an authentication code 114 that is transmitted to the first-screen device 120. Importantly, the user authentication manager requests and receives the authentication code 114 from the second-screen device 170 to perform user authentication for a user to access—that is., unlocking the screen—the first-screen device 120.
That is, the first screen device uses a requested authentication code from the second-
screen device to authenticate access—that is, unlocking the screen—for the user of the first-screen device. In particular, the user authentication manager compares the authentication code 114 of the second-screen device 170 with the stored authentication code 114 (from the first screen-device) to determine that the authentication codes [of the first-screen device and the second-screen device] match to allow access—that is, unlocking the screen—to the first-screen device, based on the authentication code of the second-screen device.
Thus, the Marchand reference discloses or at least suggests the further limitations in which the “first operation is one of” “[A] a screen unlocking operation, [B] an application unlocking operation, or [C] an operation performed on a functional control in an application”.
Accordingly, claim 74 is unpatentable over the Marchand reference in view of the Hintze reference for the same reasons as claim 69, and for the further foregoing reasons.
Claim 76 depends from claim 73, and it further recites the limitations in which the “one or more processors are further configured to execute the instructions to”: “compare a matching degree in the matching result and a preset threshold”, and “identify that the local authentication result is that the authentication fails when the matching degree is not greater than the preset threshold”.
It is first noted that any biometric systems, which are well known, necessarily require a preset or reference biometric data—identity information—to match exactly or within a threshold (e.g., face or fingerprint matches may never be exact) to the currently obtained or measured biometric data—identity information. Thus, a first authentication succeeds when the matching result is the same as or greater than a first preset threshold.
In this regard, the Hintze reference discloses (at page 85:8-10) the following:
4.1 Max Weighted Score Threshold Fusion We developed a max weighted score threshold algorithm, which is simple to implement and computationally efficient. Each individual plugin is assigned a static weight (W ). On every tick, all co-located trusted devices, including the device running the algorithm, are iterated and all active confidence plugins are queried for the highest confidence value. Confidence results from remote devices are adjusted by a remote_factor, allowing to put less trust in those devices. Risk-plugins are queried on the local device for the maximum risk value.
The previous confidence is degenerated by a constant component as well as a risk dependent component. The constant factor can be configured independently for different device types (e.g., smartphone vs notebook) as well as whether the device is actively used or idle (D-act vs. D-idle ). It ensures that confidence erodes over time if not reinforced. The risk-dependent component ensures the level of confidence required corresponds to the current risk assessment. This is achieved by subtracting the current risk multiplied by a constant α-risk from the previous confidence.
The algorithm compares the maximum of the current confidence and the degenerated previous confidence against a constant threshold and grants access to the device if the confidence is equal or greater than the threshold. Algorithm 1 specifies the max weighted score threshold fusion algorithm in detail.
. . . .
The algorithm compares the current mean confidence against a constant threshold and grants access to the device if the mean confidence is equal or greater. Algorithm 2 specifies the mean weighted score threshold fusion algorithm in detail.
Thus, the Hintze reference discloses or at least suggests the further the limitations in which the “one or more processors are further configured to execute the instructions to”: “compare a matching degree in the matching result and a preset threshold”, and “identify that the local authentication result is that the authentication fails when the matching degree is not greater than the preset threshold”.
The Marchand and Hintze references are in the same field of endeavor as the claimed subject matter since they each concern user authentications systems for at least first and second (multiple) electronic devices. Accordingly, a person having ordinary skill in the art would consider the Hintze reference for including the capability of providing the capability of “compar[ing] a matching degree in the matching result and a preset threshold”, and “identify[ing] that the local authentication result is that the authentication fails when the matching degree is not greater than the preset threshold”.
It is therefore the case that it would have been obvious to a person having ordinary skill in the art before the effective date filing date of the claimed invention to modify the primary Marchand reference, based on the teachings, motivations and/or suggestions of the secondary Hintze reference, so as to include the capability of “compar[ing] a matching degree in the matching result and a preset threshold”, and “identify[ing] that the local authentication result is that the authentication fails when the matching degree is not greater than the preset threshold”.
Accordingly, claim 76 is unpatentable over the Marchand reference in view of the Hintze reference for the same reasons as claims 69, 70, and 73, and for the further foregoing reasons.
Claim 77 depends from claim 70, and it recites the further limitations in which the
“identity authentication information comprises any one or more of [A] face information, [B] fingerprint information, [C] voiceprint information, [D] iris information, or [E] screen touch behavior information”.
Since the claim is in the form of A, B, C, D, or E, only one of the claim elements needs to be established.
In this regard, the Hintze reference discloses (at pages 85:1, 1st paragraph-85:2, paragraphs 5-9), multi-modal (that is, a local authentication, including multiple (e.g., first, as well as second) biometric authentications) cross-device (that is, multiple (e.g., first and second electronic devices) authentication, as follows:
We present . . . an approach to significantly reduce the manual burden of mobile user verification through risk-aware, multi-modal biometric, cross-device authentication. Transparent behavioral and physiological biometrics like gait, voice, face, and keystroke dynamics are used to continuously evaluate the user’s identity without explicit interaction. The required level of confidence in the user’s identity is dynamically adjusted based on the risk of unauthorized access derived from signals like location, time of day and nearby devices. Authentication results are shared securely with trusted [multiple] devices to facilitate cross-device authentication for co-located devices.
. . . .
Approaches towards multi-modal biometric authentication systems proposed so far usually operate on a single device [62] only. With the increasing number of different interconnected devices owned and used by a single individual, it seems desirable to extend the scope [of multi-modal biometric authentication systems] . . . . to leverage contextual and biometric information gathered within a group of trusted devices to increase both security and usability. . . .
In this paper, we . . . present . . . a novel approach towards risk-aware, multi-modal biometric, cross-device continuous user authentication across multiple trusted mobile devices. . . .
Thus, biometrics like gait, voice, face, and/or keystroke are used to continuously evaluate the user’s identity using explicit and/or implicit input operations, such as, for example, gait (movement), voice (voiceprint) information, face information, and/or keystroke, etc., so as to provide multi-modal (multiple) authentications based on multiple biometrics across multiple trusted mobile devices. Thus, the Hintze reference discloses multiple trusted mobile devices—which necessarily includes a first electronic device and a second electronic device. It is noted that fusing authentication scores in a set of dynamic biometrics across different devices means that at least two authentication tests must satisfy an authentication (access) threshold, as disclosed by the Hintze reference (at page 85:7, paragraphs 1-3; and sections 4.1-4.2 at
pages 85:8-85:10).
In particular, biometric information, including voice information (voiceprint), face information, and keystroke dynamics information are used to continuously evaluate the user’s identity without explicit interaction.
The Marchand and Hintze references are in the same field of endeavor as the claimed subject matter since they each concern user authentications systems for at least first and second (multiple) electronic devices. Accordingly, a person having ordinary skill in the art would consider the Hintze reference for including the capability of providing that identity authentication information includes [A] face information or [C] voiceprint information.
It is therefore the case that it would have been obvious to a person having ordinary skill in the art before the effective date filing date of the claimed invention to modify the primary Marchand reference, based on the teachings, motivations and/or suggestions of the secondary Hintze reference, so as to include the capability of providing that identity authentication information includes [A] face information or [C] voiceprint information.
Thus, the Hintze reference discloses or at least suggests the further limitations in which
the “identity authentication information comprises one or more of” “[A] face information, [B] fingerprint information, [C] voiceprint information, [D] iris information, or [E] screen touch
behavior information”.
Accordingly, claim 77 is unpatentable over the Marchand reference in view of the Hintze reference for the same reasons as claims 70 and 69, and for the further foregoing reasons.
Claim 78 depends from claim 69, and it recites the further limitation that the “first electronic device and the second electronic device log in to a same user account”.
In this regard, the Marchand reference discloses (at col. 7, lines 34-40), the following:
[I]f the user of the first-screen device 120 is the same as the user of the second screen device 170, the first application and the second application may be linked to the same account on the content platform (e.g., once the first application and the second application are installed on the first-screen device 120 and the second screen device 170 respectively).
Accordingly, the Marchand reference discloses or at least suggests the further limitation in which the “processor is further configured to enable the first electronic device and the second electronic device to log in to a same user account”.
Accordingly, claim 78 is unpatentable over the Marchand reference in view of the Hintze reference for the same reasons as claim 69, and for the further foregoing reasons.
Claim 79 depends from claim 78, and it recites the further limitation that the “user account is one of an [A] instant messaging account, [B] an email account, or [C] a mobile phone number”. Only one of the alternate elements is required to meet the limitations of claim 79, so as to satisfy claim 79.
In this regard, the Marchand reference discloses (at col. 23, line 58 to col. 24, line 10; and col. 25, lines 11 to 25) that the user account can include an email account.
Accordingly, claim 79 is unpatentable over the Marchand reference in view of the Hintze reference for the same reasons as claims 78 and 69, and for the further foregoing reasons.
Claims 80 and 81 depend from claim 78 and 69, respectively, and it recites the further limitation in which a “manner of the local authentication and a manner of the cross-device authentication are different”.
In this regard, the Hintze reference discloses (at pages 85:1, 1st paragraph-85:2, paragraphs 5-9), multi-modal (that is, a local authentication, including multiple (e.g., first, as well as second) authentications) cross-device (that is, multiple (e.g., first and second electronic devices) authentication, as follows:
We present . . . an approach to significantly reduce the manual burden of mobile user verification through risk-aware, multi-modal biometric, cross-device authentication. Transparent behavioral and physiological biometrics like gait, voice, face, and keystroke dynamics are used to continuously evaluate the user’s identity without explicit interaction. The required level of confidence in the user’s identity is dynamically adjusted based on the risk of unauthorized access derived from signals like location, time of day and nearby devices. Authentication results are shared securely with trusted [multiple] devices to facilitate cross-device authentication for co-located devices.
. . . .
Approaches towards multi-modal biometric authentication systems proposed so far usually operate on a single device [62] only. With the increasing number of different interconnected devices owned and used by a single individual, it seems desirable to extend the scope [of multi-modal biometric authentication systems] . . . . to leverage contextual and biometric information gathered within a group of trusted devices to increase both security and usability. . . .
In this paper, we . . . present . . . a novel approach towards risk-aware, multi-modal biometric, cross-device continuous user authentication across multiple trusted mobile devices. . . .
• . . . dynamically combining explicit and implicit authentication mechanisms with continuous risk estimation, shared securely across a group of trusted devices to significantly reduce explicit authentication overhead and increase security at the same time.
• . . . fuse authentication scores in a set of dynamic biometrics across different devices, taking risk, uncertainty, and device distance into account.
• . . . dynamic authentication approaches that measures security and usability precisely and facilitates the comparison with conventional authentication measures . . . .
Thus, biometrics (by a user) like gait, voice, face, and/or keystroke are used to continuously evaluate the user’s identity using explicit and/or implicit input operations, such as, for example, gait (movement), voice, face, and/or keystroke [(which are different manners of authentication)] etc., so as to provide multi-modal (multiple) authentications based on multiple biometrics across multiple trusted mobile devices. Accordingly, the Hintze reference discloses multiple trusted mobile devices—which necessarily includes a first electronic device and a second electronic device.
It is noted that fusing authentication scores in a set of dynamic biometrics across different devices means that at least two authentication tests must satisfy an authentication (access) threshold, as disclosed by the Hintze reference (at page 85:7, paragraphs 1-3, paragraphs 1-3; and sections 4.1-4.2 at pages 85:8-85:10).
Accordingly, the Hintze reference discloses or at least suggests the limitations of
in which a “manner of the local authentication and a manner of the cross-device authentication are different”.
Accordingly, claims 80 and 81 are unpatentable over the Marchand reference in view of the Hintze reference for the same reasons as claims 78 and 69, and for the further foregoing reasons.
Claim 82 depends from claim 69, and like claim 80 it recites the further limitation in
which the “first electronic device is connected to send, to the second electronic device using one or more of [A] a Wi-Fi communication protocol, [B] an ultra-wideband (UWB) communication protocol, [C] a Bluetooth communication protocol, [D] a ZIGBEE communication protocol, or [E] a Near-Field Communication (NFC) protocol”. Since the claim is in the form of A, B, C, D, or E, only one of the claim elements needs to be established.
In this regard, the Marchand reference specifically discloses (at col. 9, lines 5-40; col. 10, lines 3-43; and Figure 1) the following:
Local network 140 may be a computing network that provides . . . communication channels between first-screen device 120 and second-screen device 170. In one example, local network 140 may be a peer-to-peer network that does not rely on a pre-existing network infrastructure (e.g., access points, switches, routers) and first-screen device 120 and second-screen device 170 may replace the networking infrastructure to route communications between the user devices. Local network 140 may be a wireless network that is self-configuring and enables first-screen device 120 and second-screen device 170 to contribute to local network 140 and dynamically connect and disconnect from local network 140 (e.g., ad hoc wireless network). In another example, local network 140 may be a computing network that includes networking infrastructure that enables user devices to communicate with other user devices . . . . [L]ocal network 140 may be based on any wireless or wired communication technology and may connect a first user device directly or indirectly (e.g., involving an intermediate user device) to a second user device. The wireless communication technology may include Bluetooth®, Wi-Fi®, infrared, ultrasonic, or other technology. The wired communication may include universal serial bus (USB), Ethernet, RS 232, or other wired connection. The local network 140 may be an individual connection between two devices or may include multiple connections.
Network 150 may be a public network that provides first-screen device 120 and second-screen device 170 with access to application distribution server 110, authentication server 130, and other [publicly] available computing devices. Network 150 may include one or more wide area networks (WANs), local area networks (LANs), wired networks (e.g., Ethernet network), wireless networks (e.g., an 802.11 network or a Wi-Fi network), cellular networks (e.g., a Long Term Evolution (LTE) network), routers, hubs, switches, server computers, and/or a combination thereof.
Accordingly, the Marchand reference discloses or at least suggests the further limitations in which the “first electronic device is connected to send, to the second electronic device using one or more of [A] a Wi-Fi communication protocol, [B] an ultra-wideband (UWB) communication protocol, [C] a Bluetooth communication protocol, [D] a ZIGBEE communication protocol, or [E] a Near-Field Communication (NFC) protocol”.
Accordingly, claim 82 is unpatentable over the Marchand reference in view of the Hintze reference for the same reasons as claim 69, and for the further foregoing reasons.
Independent claim 84 is to an “electronic device system” (as disclosed by each of the
Marchand and Hintze references) comprising (like independent claim 69) a “first electronic device” configured to recite the recited steps essentially like those of the first electronic device of claim 69.
It is noted that claim 84 further recites the limitations in which the “cross-device authentication result is a second local authentication result of the second electronic device”, and in which the “second electronic device [is] configured to send cross-device authentication information of the cross-device authentication to the first electronic device”.
In this regard, the Marchand reference discloses (at col. 15, line 7 to col. 16, line 14) the following:
The second-screen device 170 may send (310) a first SSDP message to the first-screen device 120 over a network (e.g., local network 140). In some implementations, the second-screen device 170 broadcasts the first SSDP message (e.g., a first SSDP broadcast message) over the network. In some implementations, the second-screen device periodically sends (310) the first SSDP message to determine whether there is a first-screen device 120 communicably coupled to the same network as the second-screen device 170. In some implementations, the second-screen device periodically sends (310) the first SSDP message to determine whether there is a first-screen device 120 executing a first application that corresponds to a second application executing on the second-screen device 170 and that is communicably coupled to the same network as the second-screen device 170 (e.g., the first and second applications have functionalities to facilitate automated user login into a first application by user input via the second application). In some implementations, the second-screen device 170 sends (310) the first SSDP message in response to launching the second application on the second-screen device 170. In some implementations, the second-screen device 170 sends (310) the first SSDP message in response to receiving user input via the second application. The first-screen device 120 may send (312) a second SSDP message to the second-screen device 170 in response to receiving the first SSDP message (e.g., detecting the first SSDP broadcast message). The first-screen device 120 may send (312) the second SSDP message to provide a confirmation (e.g., that the first-screen device 120 is communicably coupled to the same network as the second-screen device 170, that the first-screen device 120 is executing the first application corresponding to the second application, etc.). The second-screen device 170 may identify (314) the first-screen device 120 (e.g., as being communicably coupled to the same network, as executing a first application that corresponds to the second application, etc.) in response to receiving the second SSDP message.
The second-screen device 170 may send (316) a first message (e.g., DIAL Application Status HTTP request, DIAL URL request) to the first-screen device 120 over the network. In some implementations, the second-screen device 170 sends (316) the first message to determine whether any identified first-screen devices 120 are requesting user authentication. In some implementations, the second-screen device 170 sends (316) the first message in response to identifying (314) the first-screen device. In some implementations, the second-screen device 170 periodically sends (316) the first message to any first-screen device that the second-screen device 170 has identified. The first-screen device 120 may generate (318) a message (e.g., DIAL Application Status HTTP request response, DIAL URL message) including the authentication code (e.g., generate a DIAL URL and append the authentication code to the DIAL URL) in response to receiving the first message. The first-screen device 120 may send (320) the message to the second-screen device 170 over the network in response to generating the message. In some implementations, the first-screen device 120 broadcasts the message and any second-screen device may receive (e.g., detect) the message. In some implementations, the first-screen device 120 sends (320) the message to the second-screen device 170 that sent (316) the first message. The first-screen device 120 may send (320) the message to the second-screen device 170 to provide a confirmation that the first-screen device 120 is requesting user authentication. The second-screen device 170 may determine (322) the first application is requesting user authentication for the automated user login in response to receiving the message. In some implementations, the second-screen device 170 determines (322) the first application is requesting user authentication by decoding the message and identifying the authentication code. The second-screen device 170 may present (324) a prompt for user input indicating user acceptance of the automated user login in response to determining the first application is requesting user authentication.
In some implementations, the second application hosted by the second-screen device 170 is logged into one or more accounts (e.g., the second-screen device previously sent login credentials corresponding to the one or more accounts to the authentication server 130 to sign into the second application via the one or more accounts) and the second-screen device 170 presents (324) a prompt including a corresponding acceptance element for each of the one or more accounts. The user may select (e.g., click on) one of the acceptance elements corresponding to an account to indicate user acceptance of the automated user login into the first application via the account. In some implementations, the second-screen device 170 presents (324) a prompt for user input for the user to enter login credentials (e.g., username and password) via the second application (e.g., the user has not logged into the second application).
The second-screen device 170 may receive (326) the user input indicating the user acceptance of the automated user login in response to presenting the prompt. In some implementations, the user input is selecting an acceptance element corresponding to an account (e.g., user input choosing an account to grant the first application to use that account). In another element, the user input is entering of a username and/or password. In some implementations, the user input is a biometrics identifier (e.g., a thumbprint, a fingerprint, an eye scan, etc.).
The second-screen device 170 may send (328) the authentication code from the message to the authentication server 130 in response to receiving the user input. The authentication server 130 may generate credentials in response to receiving the authentication code. In some implementations, the credentials may be login information to log into the first application hosted by the first-screen device. In some implementations, the credentials may be login information corresponding to an account indicated in the user input to log into first application hosted by the first-screen device.
The first-screen device 120 may send (332) a second request for the user authentication for the automated user login into the authentication server 130 (e.g., into the first application hosted by the first-screen device 120). In one implementation, the first-screen device periodically sends the request for the user authentication to the authentication server 130 after receiving (302) the user input and prior to receiving credentials. In some implementations, the second request is the same as the first request sent (304) by the first-screen device 120. The authentication server 130 may send (334) the credentials to the first-screen device 120 to perform the user authentication for the automated user login into the first application.
As explained above, the Marchand reference discloses that the first and second applications have functionalities to facilitate automated user login into a first application by user input via the second application. This means that the first application is necessarily locked since the user login must be passed to login into the first application.
Still further, the Marchand reference discloses that the second-screen device 170 sends (316) the first message to determine whether any identified first-screen devices 120 are requesting user authentication—so that such first-screen devices and their first applications are necessarily locked if user authentications are being requested, after which the first application is locked at least until the first authentication succeeds.
Also, as explained above, the Marchand reference specifically discloses (at col. 7, line 53 to col. 8, line 11; and Figure 1) the following:
Authentication server 130 may include a user authentication manager 132. User authentication manager 132 may receive a request from a first-screen device 120 for user authentication for automated user login into a first application 602 hosted by the first-screen device 120. The user authentication manager 132 may generate an authentication code 114 and transmit the authentication code 114 to the first-screen device 120. The user authentication manager 132 may store the authentication code 114 . . . . Subsequently, the user authentication manager may receive the authentication code 114 from the second-screen device 170 and perform user authentication for the automated user login into the first application 602 hosted by the first-screen device 120. The user authentication manager 132 may compare the authentication code 114 received from the second-screen device 170 with the authentication code 114 stored in the data store 160 [from the first screen-device] to determine that the authentication codes [of the first-screen device and the second-screen device] match. The user authentication manager 132 may receive an indication of an account from the second-screen device 170 and may perform the user authentication for the automated user login into the account in the first application 602.
That is, while the second authentication based on the second authentication code is being performed, the first-screen (and necessarily its first application) is necessarily locked
and/or otherwise unavailable to the user.
Accordingly, the Marchand reference discloses or at least suggests the limitations in which the “cross-device authentication result is a second local authentication result of the second electronic device”, and in which the “second electronic device [is] configured to send cross-device authentication information of the cross-device authentication to the first electronic device”.
Accordingly, claim 84 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claim 69, and for the further foregoing reasons.
Claim 85 depends from claim 84, and it recites further limitations like those of claim 73.
Accordingly, claim 85 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 84 and 73, and for the further foregoing reasons.
Claim 86 depends from claim 85, and it recites further limitations like those of claim 77.
Accordingly, claim 86 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 85, 84 and 77, and for the further foregoing reasons.
Claim 87 depends from claim 85, and it recites further limitations like those of claim 76.
Accordingly, claim 87 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 85 and 76, and for the further foregoing reasons.
Claim 88 depends from claim 84, and it recites further limitations like those of claim 74.
Accordingly, claim 88 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 84 and 74, and for the further foregoing reasons.
Claim 89 depends from claim 84, and it recites further limitations like those of claim 78.
Accordingly, claim 89 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 84 and 78, and for the further foregoing reasons.
Claim 90 depends from claim 89, and it recites further limitations like those of claim 79.
Accordingly, claim 90 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 89, 84 and 79, and for the further foregoing reasons.
Claim 91 depends from claim 89, and it recites further limitations like those of claim 81.
Accordingly, claim 91 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 89 and 81, and for the further foregoing reasons.
Claim 92 depends from claim 84, and it recites further limitations like those of claim 81.
Accordingly, claim 92 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 84 and 81, and for the further foregoing reasons.
Claim 93 depends from claim 84, and it recites further limitations like those of claim 82.
Accordingly, claim 93 is unpatentable over the Marchand reference in view of the Hintze
reference for essentially the same reasons as claims 84 and 82, and for the further foregoing reasons.
Claim 94 depends from claim 84, and it recites further limitations like those of claim 83.
Accordingly, claim 94 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 84 and 83, and for the further foregoing reasons.
Claim 95 depends from claim 84, and it recites further limitations like those of claim 70.
Accordingly, claim 95 is unpatentable over the Marchand reference in view of the Hintze
reference for essentially the same reasons as claims 84 and 70, and for the further foregoing reasons.
Independent claim 96 includes limitations like those of claim 69, except that claim 96 is to a method, rather than a first electronic device.
Accordingly, claim 96 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claim 69, and for the further foregoing reasons.
Claim 97 depends from claim 96, and it recites further limitations like those of claim 83.
Accordingly, claim 97 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 96 and 83, and for the further foregoing reasons.
Claim 98 depends from claim 96, and it recites further limitations like those of claim 70.
Accordingly, claim 98 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 96 and 70, and for the further foregoing reasons.
Claim 99 depends from claim 98, and it recites further limitations like those of claim 73.
Accordingly, claim 99 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 98 and 73, and for the further foregoing reasons.
Claim 100 depends from claim 99, and it recites further limitations like those of claim 74.
Accordingly, claim 100 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 99 and 74, and for the further
foregoing reasons.
Claim 101 depends from claim 99, and it recites further limitations like those of claim 76.
Accordingly, claim 101 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 99 and 76, and for the further foregoing reasons.
Claim 102 depends from claim 98, and it recites further limitations like those of claim 77.
Accordingly, claim 102 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 98 and 77, and for the further foregoing reasons.
Claim 103 depends from claim 96, and it recites further limitations like those of claim 78.
Accordingly, claim 103 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 96 and 78, and for the further foregoing reasons.
Claim 104 depends from claim 96, and it recites further limitations like those of claim 79.
Accordingly, claim 104 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 96 and 79, and for the further foregoing reasons.
Claim 105 depends from claim 96, and it recites further limitations like those of claim
81.
Accordingly, claim 105 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 96 and 81, and for the further foregoing reasons.
Claim 106 depends from claim 96, and it recites further limitations like those of claim 82.
Accordingly, claim 106 is unpatentable over the Marchand reference in view of the Hintze reference for essentially the same reasons as claims 96 and 82, and for the further foregoing reasons.
Claim 83 is rejected under 35 U.S.C. § 103 as unpatentable over U.S. Patent No. 11,347,834 to Marchand et al. (“the Marchand reference”), in view of Hintze et al., CORMORANT: Ubiquitous Risk-Aware Multi-Modal Biometric Authentication across Mobile Devices, Proc. ACM Interact. Mob. Wearable Ubiquitous Technol., Vol. 3, No. 3, Article 85 (September 2019) (“the Hintze reference”), and further in view of RFC8628 - OAuth 2.0 Device Authorization Grant - August 2019 (“the OAuth reference”) for the following reasons.
Claim 83 depends from claim 69, and like claim 80 it recites the further limitations in which the “one or more processors are further configured to send, to the second electronic device, a first request message to request to obtain a local authentication result of the second electronic device”, in which “obtaining the cross-device authentication result comprises” “receiving, from the second electronic device, a first response message comprising the cross-device authentication result”, and in which the “cross-device authentication result is the local authentication result of the second electronic device”.
The further limitation of claim 83 essentially corresponds to an OAuth 2.0 Device Authorization Grant, as disclosed by the OAuth reference. In particular, the Abstract of the OAuth reference discloses that the OAuth 2.0 Device Authorization Grant is an extension to the OAuth 2.0 protocol that allows Internet-connected devices with limited input capabilities or no suitable browser to obtain user authorization for accessing protected resources. This is for devices like smart TVs, media consoles, digital picture frames, and printers. The authorization flow, sometimes referred to as the "device flow," instructs the user to review the authorization request on a secondary device, such as a smartphone, which has the necessary input and browser capabilities to complete the user interaction. The device authorization grant is not intended to replace browser-based OAuth in native apps on capable devices like smartphones.
In particular, the OAuth reference specifically discloses (at pages 3-5) the following:
1. Introduction
This OAuth 2.0 [RFC6749] protocol extension enables OAuth clients to
request user authorization from applications on devices that have
limited input capabilities or lack a suitable browser. Such devices
include smart TVs, media consoles, picture frames, and printers,
which lack an easy input method or a suitable browser required for
traditional OAuth interactions. The authorization flow defined by
this specification, sometimes referred to as the "device flow",
instructs the user to review the authorization request on a secondary
device, such as a smartphone, which does have the requisite input and
browser capabilities to complete the user interaction.
The device authorization grant is not intended to replace browser-
based OAuth in native apps on capable devices like smartphones.
Those apps should follow the practices specified in "OAuth 2.0 for
Native Apps" [RFC8252].
The operating requirements for using this authorization grant type
are:
(1) The device is already connected to the Internet.
(2) The device is able to make outbound HTTPS requests.
(3) The device is able to display or otherwise communicate a URI and
code sequence to the user.
(4) The user has a secondary device (e.g., personal computer or
smartphone) from which they can process the request.
As the device authorization grant does not require two-way
communication between the OAuth client on the device and the user
agent (unlike other OAuth 2 grant types, such as the authorization
code and implicit grant types), it supports several use cases that
cannot be served by those other approaches.
Instead of interacting directly with the end user’s user agent (i.e.,
browser), the device client instructs the end user to use another
computer or device and connect to the authorization server to approve
the access request. Since the protocol supports clients that can’t
receive incoming requests, clients poll the authorization server
repeatedly until the end user completes the approval process.
Denniss, et al. Standards Track [Page 3]
RFC 8628 OAuth 2.0 Device Grant August 2019
The device client typically chooses the set of authorization servers
to support (i.e., its own authorization server or those of providers
with which it has relationships). It is common for the device client
to support only one authorization server, such as in the case of a TV
application for a specific media provider that supports only that
media provider’s authorization server. The user may not yet have an
established relationship with that authorization provider, though one
can potentially be set up during the authorization flow.
+----------+ +----------------+
| |>---(A)-- Client Identifier --->| |
| | | |
| |<---(B)-- Device Code, ---<| |
| | User Code, | |
| Device | & Verification URI | |
| Client | | |
| | [polling] | |
| |>---(E)-- Device Code --->| |
| | & Client Identifier | |
| | | Authorization |
| |<---(F)-- Access Token ---<| Server |
+----------+ (& Optional Refresh Token) | |
v | |
: | |
(C) User Code & Verification URI | |
: | |
v | |
+----------+ | |
| End User | | |
| at |<---(D)-- End user reviews --->| |
| Browser | authorization request | |
+----------+ +----------------+
Figure 1: Device Authorization Flow
The device authorization flow illustrated in Figure 1 includes the
following steps:
(A) The client requests access from the authorization server and
includes its client identifier in the request.
(B) The authorization server issues a device code and an end-user
code and provides the end-user verification URI.
(C) The client instructs the end user to use a user agent on another
device and visit the provided end-user verification URI. The
client provides the user with the end-user code to enter in
order to review the authorization request.
Denniss, et al. Standards Track [Page 4]
RFC 8628 OAuth 2.0 Device Grant August 2019
(D) The authorization server authenticates the end user (via the
user agent), and prompts the user to input the user code
provided by the device client. The authorization server
validates the user code provided by the user, and prompts the
user to accept or decline the request.
(E) While the end user reviews the client’s request (step D), the
client repeatedly polls the authorization server to find out if
the user completed the user authorization step. The client
includes the device code and its client identifier.
(F) The authorization server validates the device code provided by
the client and responds with the access token if the client is
granted access, an error if they are denied access, or an
indication that the client should continue to poll.
. . . .
3. Protocol
3.1. Device Authorization Request
This specification defines a new OAuth endpoint: the device
authorization endpoint. This is separate from the OAuth
authorization endpoint defined in [RFC6749] with which the user
interacts via a user agent (i.e., a browser). By comparison, when
using the device authorization endpoint, the OAuth client on the
device interacts with the authorization server directly without
presenting the request in a user agent, and the end user authorizes
the request on a separate device. This interaction is defined as
follows.
The client initiates the authorization flow by requesting a set of
verification codes from the authorization server by making an HTTP
"POST" request to the device authorization endpoint.
Accordingly, the Marchand reference, in view of the Hintze reference, and in view of the OAuth reference discloses or at least suggests the further limitations in which the “one or more processors are further configured to send, to the second electronic device, a first request message to request to obtain a local authentication result of the second electronic device”, in which “obtaining the cross-device authentication result comprises” “receiving, from the second electronic device, a first response message comprising the cross-device authentication result”, and in which the “cross-device authentication result is the local authentication result of the second electronic device”.
The Marchand reference, the Hintze reference, and the OAuth reference are analogous references since they each concern local authentication and cross-authentication using first and
second electronic devices.
A person having ordinary skill in the art would be motivated to combine the OAuth reference and its authentication protocols to obtain the efficiencies of the authentication protocols.
Accordingly, claim 83 is unpatentable over the Marchand reference, in view of the Hintze reference, and in view of the OAuth reference for the same reasons as claim 69, and for the further foregoing reasons.
Response to Arguments
Applicant’s arguments with respect to the pending claims have been considered but are moot because of the new grounds of rejection that are attributable to the new amendments. (See M.P.E.P. FP 7.38). While not repeated here in the Response Section, the new grounds of rejection provided above are referenced here as necessary.
In summary, Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims somehow define a patentable invention without specifically pointing out how the language of the claims are patentably distinguished from the references. Still further, applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which they think the claims present in view of the state of the art disclosed by the references cited or the rejections made. Further, they do not specifically explain how the amendments avoid such references or rejections.
Finally, the Amendment and Remarks do not refute or even address any of the specific arguments, explanations, and facts presented as to the claims in the Office Action.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's
disclosure.
US-20140108506-A1 to Borzycki, ORCHESTRATION FRAMEWORK FOR CONNECTED DEVICES
US-20170026617-A1 to Wang, METHOD AND APPARATUS FOR REAL-TIME VIDEO INTERACTION BY TRANSMITTING AND DISPLAYING USER INTERFACE CORREPSONDING TO USER INPUT
US-20190090976-A1 to Wade, SYSTEM AND METHOD FOR ENHANCED DATA ANALYSIS WITH SPECIALIZED VIDEO ENABLED SOFTWARE TOOLS FOR MEDICAL ENVIRONMENTS
US-20190222570-A1 to Krishan, METHOD AND SYSTEM FOR PERFORMING USER AUTHENTICATION
US-20190273607-A1 to Van Der Velden, SYSTEM FOR DIGITAL IDENTITY AUTHENTICATION AND METHODS OF USE IN HEALTHCARE
US-20190347181-A1 to Cranfill, USER INTERFACES FOR CONTROLLING OR PRESENTING DEVICE USAGE ON AN ELECTRONIC DEVICE
US-20200402052-A1 to Sloane, EDGE-NODE TOUCHLESS AUTHENTICATION ARCHITECTURE DIAGRAM
US-20210118077-A1 to Kuta, PERSONAL SECURITY MONITORING
US-11256392-B2 to Ponnusamy, UNIFIED INTERFACES FOR PAIRED USER COMPUTING DEVICES
US-20220239513-A1 to Swierk, SYSTEM AND METHOD FOR OPERATING AN INTELLIGENT FACE FRAMING MANAGEMENT SYSTEM FOR VIDEOCONFERENCING APPLICATIONS
US-11546391-B2 to Ponnusamy, TELECONFERENCING INTERFACES AND CONTROLS FOR PAIRED USER COMPUTING DEVICES
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner
should be directed to AARON C. DEDITCH whose telephone number is (571) 272-4780. The examiner can normally be reached Monday through Thursday at 8:00 am to 6:30 pm.
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, Rafael Perez-Gutierrez can be reached on (571) 272-7915. 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.
/Aaron C. Deditch/Examiner, Art Unit 2642
/Rafael Pérez-Gutiérrez/Supervisory Patent Examiner, Art Unit 2642
2/6/2026