DETAILED ACTION
Notice of Pre-AIA or AIA Status un
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office correspondence is in response to “Amendment and Response under 37 C.F.R. 1.111 filed on July 27, 2026 in response to a non-final office action issued on April 29, 2026.
Claims 1 – 20 are pending.
Claims 1, 10 – 12 and 20 are amended.
Claim 16 is objected to.
Claims 1 – 15, and 17 - 20 are rejected.
Applicant arguments filed on 7/27/2026 have been fully considered:
In regard to claims 1 – 9 which were interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, the applicant has adequately amended the claims so that the interpretation is no longer necessary and is withdrawn.
In regard to claims 1 – 15 and 17 – 20 which were rejected under 35 U.S.C. 103 at least one argument is persuasive to the rejection of claims from the last office action and said rejections are withdrawn, but applicant’s amendment necessitated a new search and consideration resulting in a new grounds of rejections for claims 1 – 15 and 17 - 20 under 35 U.S.C. 103. The examiner here now responds to each argument. Underlined text indicates claim language that was amended since the last office action.
In regard to claims 1 – 15 and 17 – 20 the applicant argues the prior art combination of Condry and Borghei fails to anticipate, disclose or teach:
“ and the first electronic device and the second electronic device log in to a same system account to establish a communication connection;
the first electronic device is configured to receive information sent by the second electronic device through the communication connection, wherein the information includes a security function supported by the second electronic device and a security event generated by the second electronic device,
… the first electronic device is further configured to send a first instruction to the second electronic device through the communication connection after receiving the first operation; “
The applicant states:
“ . . . It can be seen that Condry relies heavily on a central server architecture (e.g., a "security score engine" and "dashboard server") to communicate this data across a general network. Condry fails to teach or suggest the first and second electronic devices establishing a "communication connection" based on logging in to a "same system account."
Furthermore, Condry fails to teach the first electronic device receives information comprising a "security function supported by the second electronic device and a security event generated by the second electronic device" sent directly by the second device over this established communication connection. Instead, Condry teaches a user authenticating to access pre-generated score data hosted on a remote server or shared over a broad network. Condry does not disclose a mechanism where devices leverage a shared system account to establish a connection and push specific security events and functions directly between one another, bypassing centralized cloud servers. Thus, Condry fails to teach the distinguishing features of amended independent claim.
As acknowledged by the Office action, Condry fails to teach features regarding "the security risk item that exists on the second electronic device is related to user privacy." See page 11 of the Office action. Borghei is cited for teaching the privacy alerts and remote device access. . . . It can be seen that Borghei routes all of these commands and data requests through a central intermediary server, but fails to teach or suggest the first device receiving the security information or sending remediation instructions through a direct "communication connection." Because Borghei routes everything through "server 110," the server acts as a middleman for all data requests and commands. Borghei does not teach the devices leveraging a "same system account" to establish a direct connection, nor does it teach the second device sending a "security function" and "security event" directly to the first device via this connection.
Therefore, for the above reasons, Applicant submits that claim 1 as amended is not rendered obvious by the combined teaching of Condry and Borghei, and therefore is patentable and allowable over the cited prior art. Independent claims 10 and 20 recite similar features to amended claim 1 and is patentable and allowable over the cited prior art for at least the same above reasons. . . .”)
In response to the applicant’s arguments:
The applicant’s amendments substantially changed the scope of the independent claims by requiring the receiving information sent by a second electronic device through a communication connection, wherein the information includes a security function supported by the second electronic device and a security event generated by the second electronic device, wherein the first electronic device and the second electronic device log in to a same system account to establish the communication connection. The prior art combination of Condry and Borghei dies not explicitly teach the amended limitation so therefore the rejection under 35 USC 103 as being unpatentable over Condry and Borghei is withdrawn but applicant’s amendments triggered a new search and consideration of the amended claims to find new grounds of rejection under 35 USC 103 as being unpatentable over Condry et al. (U.S. 2014/0173738 A1; herein referred to as Condry) in view of Borghei (U.S. 2019/0149995 A1; herein referred to as Borghei) in further view of Chen et al. (U.S. 2022/0385531 A1; herein referred to as Chen). The prior art Chen is analogous art directed to a first device performing mobile device management onto a second device where the devices communicate directly with each other. The new rejections are described below.
The examiner recommends that the applicant review the specification for disclosure that if integrated into the independent claims would distinguish the amended claims from the cited prior art. The applicant is invited to contact the examiner for an interview to discuss how to move the prosecution forward.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
Priority
This Application is a continuation of International Application No. PCT/CN2023/109017, filed on Jul. 25, 2023, which claims priorities to Chinese Patent Application No. 202210881648.9, filed on Jul. 26, 2022 and Chinese Patent Application No. 202210999711.9, filed on Aug. 19, 2022. The applicant has provided certified priority documents and the applicant is entitled to a priority date of July 26, 2022.
35 USC § 101 Analysis – Judicial Exception
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
The claimed invention is directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception.. The claimed subject matter is integrated into a practical application under prong 2 of the Step 2A analysis as documented in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement for device security to enable a local device to receive a user operation to eliminate a security risk on the local device or another interconnected device, the claimed invention comprising method, system and device embodiments that include a first electronic device and a second electronic device, and the execution of the algorithm in which the first electronic device is configured to display a first user interface or first prompt information, where a security risk item that exists on the second electronic device is displayed on the first user interface, or the first prompt information indicates that a security risk item exists on the second electronic device, and the security risk item that exists on the second electronic device is related to user privacy. The first electronic device is further configured to receive a first operation of a user on the first user interface or the first prompt information, where the first operation is used to eliminate the security risk item that exists on the second electronic device. The first electronic device is further configured to send a first instruction to the second electronic device after receiving the first operation. The second electronic device is configured to: after receiving the first instruction, eliminate the security risk item that exists on the second electronic device. The ordered steps address problems known in the art concerning security risks involving terminal device interconnections and preventing the devices from being maliciously attacked. The claimed invention enables that the user can view on the first electronic device, the security risk item that exists on the second electronic device. When it is inconvenient for the user to perform an operation on the second electronic device, the first electronic device can receive a user operation to eliminate the security risk item that exists on the second electronic device. This ensures device security of the second electronic device, and avoids leakage of user data on the second electronic device. Therein the claimed invention is statutory under 35 USC 101.
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 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 – 15 and 17 - 20 are rejected under 35 U.S.C. 103 as being un-patentable over Condry et al. (U.S. 2014/0173738 A1; herein referred to as Condry) in view of Borghei (U.S. 2019/0149995 A1; herein referred to as Borghei) in further view of Chen et al. (U.S. 2022/0385531 A1; herein referred to as Chen).
In regard to claim 1, Condry teaches A device security processing system, wherein the system comprises a first electronic device and a second electronic device (e.g. see Fig. 1 plurality of end-user host devices) (see ¶ [0011] “ . . . FIG. 1 is a simplified block diagram illustrating an example computing system 100 including end-user host devices 105, 110, 115, 120 for which corresponding security scores can be generated. The security scores can be based on security postures determined for the host devices 105, 110, 115, 120. . . .”), wherein the first electronic device comprises a first processor and a first memory, the second electronic device comprises a second processor and a second memory (see Fig. 2 ¶¶ [0023-0024] “ . . . in the example of FIG. 2, a simplified block diagram 200 is shown illustrating host devices 205, 210 utilizing a security score engine 215 in connection with the generation of use-based risk scores for each of a plurality of respective host devices (e.g., 205, 210). In one implementation, host devices 205, 210 can include processors (e.g., 222, 224), memory elements (e.g., 225, 226), display devices (e.g., 228, 230), among other hardware and software components. For instance, in one example, host devices 205, 210 can include respective sets of applications (e.g., 232, 234), operating systems, and other software programs installed or otherwise used by the host device 205, 210. Additionally, each host device can include and utilize one or more security tools (e.g., 235, 236) implemented either in whole or in part on the host device (e.g., 205, 210) or on remote computing devices, such as on networks utilized by the host devices. . . .”) ,
the first electronic device is configured to
display a first user interface (e.g. security dashboard) or first prompt information, wherein a security risk item (e.g. .risk score for each device) that exists on the second electronic device is displayed on the first user interface (see ¶ [0014] “ . . . A security posture generated by a security score engine for a particular host device can be utilized by a security dashboard engine to generate a presentation for display on the host device (or another device). The security dashboard, in some implementations, can present risk scores associated with each of a plurality of different uses of the host device, thereby providing the user with use-based risk scores and a risk assessment to which the user can relate, such as one tied to the way the user sees and uses their computing device. Instances of a security dashboard engine can be provided to a plurality of different host devices and host device types (e.g., 105, 110, 115, 120) through a security dashboard server (e.g., 130) . . .”) , or the first prompt information indicates that the security risk item exists on the second electronic device (see ¶ [0018] “ . . . Graphical display devices and user interfaces, supported by computer processors of the host devices, can further allow a user to view and interact with graphical user interfaces of applications and other programs provided in system 100, including user interfaces and graphical representations of programs interacting with applications hosted within the host devices, as well as graphical user interfaces associated with remote servers, etc. Moreover, while system devices may be described in terms of being used by one user, this disclosure contemplates that many users may use one computer or that one user may use multiple computers . . “).,
the first electronic device is further configured to receive a first operation of a user on the first user interface or the first prompt information (see ¶ [0033] “ . . . score data, including use-based score data, can be consumed or used by security dashboard engines 242, 244 installed on or otherwise used by respective host devices 205, 210. In some instances, score data may include security posture data indicating attributes of a host device relevant to host device security. In other instances, score data may include an aggregate security score or other non-use-based risk score, while in still other implementations, score data may include use-based risk scores, including security scores for each of a plurality of potential uses of the host device. Score data can be generated by a security score engine 215 and communicated to a host device over a network 180. Access to the score data at a host device can be limited to authorized client devices, and in some instances, limited to the host device for which the security score data applies. In other instances, score data for a first host device can be accessed by a second host device, for instance, based on authentication of a user to the other, first host device's score data, among other examples. In still other implementations, at least a portion of security dashboard engine can be hosted by a server device remote from a user host device, serving the security dashboard engine as a service to client devices, including host devices for which security score data and security dashboard presentation are generated . . .”), wherein the first operation is used to eliminate the security risk item that exists on the second electronic device (see ¶ [0039] “ . . . In addition to INFO buttons (e.g., 310) or other controls providing more detailed views of a use-based risk score, security dashboard 300a can further include additional controls, such as controls (e.g., 315, 318) adapted to launch potential remedies to identified deficiencies, vulnerabilities, and risks associated with a particular host device use. For instance, selection of a FIX button 315 for a Social Media use can cause a presentation of a listing of potential remedies for risk determined in connection with the Social Media use. For instance, selection of FIX button 315 can present a listing of potential countermeasures that can be activated, installed, downloaded, or otherwise used, at the request of the user, to mitigate against vulnerabilities and threats associated with Social Media use. In some instances, countermeasures can be selected and downloaded, activated, or otherwise deployed directly from the presented listing of potential remedies presented in response to selection of FIX button 315. In other instances, selection of FIX button 315 can itself automate selection and deployment of one or more countermeasures without further intervention by the user. In either instance, countermeasures can be automatically identified that have been previously determined to potentially address those vulnerabilities and other attributes of the host device (e.g., as identified in the related security posture data) relating to a particular host device use . . .”);
the first electronic device is further configured to send a first instruction to the second electronic device (e.g. countermeasures) (see ¶ [0040] “ . . . deployment of countermeasures and other potential remedies, for instance based on selection of FIX button 315, can result in the dynamic improvement of the use-based risk facing a host device. Indeed, in response to deploying one or more countermeasures related to a particular use, the corresponding use-based risk score for the host device can also be improved and reflected in presentations of use-based risk scores in a security dashboard. For instance, selection of FIX buttons 315 and 320, corresponding to Social Media use and Online Banking uses, can result in the deployment of countermeasures addressing respective weaknesses of the host device relating to these two uses and thereby also result in the improvement of corresponding use-based risk scores as shown in the evolution of score indicators 320a, 320b, 325a, 325b shown in FIGS. 3A-3B. . . .”); and
the second electronic device is configured to: after receiving the first instruction, eliminate the security risk item (e.g. remedies) that exists on the second electronic device (see ¶ [0042] (“ . . . users, in response to being presented with use-based risk scores, can utilize a security dashboard generated by a security dashboard engine 242, 244 to launch one or more remedies for sub-standard security scores for some uses of the host device. Host device attributes that are identified as negatively impacting a particular use's security score for a host device can be mapped to known countermeasures and other remedies identified and catalogued, for example, using a risk resolution engine 252. Such countermeasures can be further filtered based on the countermeasures' and remedies' compatibility with the host device in question. Such mappings and filters can be performed, in some implementations at security score engine 215. Remedy data 260 indicating the identified countermeasures and remedies can be communicated to the security dashboard engine, for instance, in response to a user selection of a security dashboard control, such as, for example, a FIX button (e.g., 315, 318). In some instances, available countermeasure data that could potentially apply to a particular host device can, instead, be communicated together with score data, security posture data, or other data used by the security dashboard engine (e.g., 242, 244) in the rendering of a security dashboard including use-based risk scores for a particular host device, among other techniques. Countermeasure and remedy information can also include information or instructions for use in developing automated requests to deploy the countermeasure on the host device (e.g., based on a selection of a corresponding FIX button by a user), or to provide instructions to a user for implementing the presented countermeasures. . . .”)
Condry fails to explicitly teach,
However Borghei teaches , and the security risk item that exists on the second electronic device is related to user privacy (see Fig. 5B ¶ [0100] “ . . . FIG. 5B illustrates an exemplary user interface that allows a user to intervene before location information of mobile device 500b is transmitted. Various security commands can require mobile device 500b to transmit location information to a server (e.g., server 110). To protect the privacy of a user of mobile device 500b, mobile device 500b can warn the user that a transmission of location information is imminent. The warning can include a voice warning (e.g., a ring tone being played), a physical warning (e.g., mobile device 500b vibrates), or a display warning, or all of the three combined. A warning message can be displayed in a messaging area 542 on a touch-sensitive display screen 502b. The user can be given a period of time to respond. The warning message can include information on who is requesting the location information as well as a countdown to the time when the location information will be sent . . .”);
It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system for proactively securing client devices by proactively determining whether the device is associated with a security risk and the level of the security risk, wherein, the device can transmit coordinates of its current geographic location to another device on the network, and to protect privacy of authorized users of the device, the transmission can be disabled by entering a password, and If multiple failed password attempts are detected, the device can determine that the device is currently being operated by an unauthorized user, and can proactively increase a security level of the device so that under the increased security level, files or other content stored on the device can be selectively protected, as taught by Borghei, into a method and system for collecting security scores for a plurality of client devices where each device has a security dashboard where remedies and countermeasures can be deployed to address the security risks for the devices, as taught by Condry, Such incorporation provides a system where devices can communicate security risks to each other and the devices can proactively deploy certain remedies to remove a risk from a given device.
The combination of Condry and Borghei fails to explicitly teach,
However Chen teaches
and the first electronic device and the second electronic device log in to a same system account to establish a communication connection (see Chen ¶ ¶ [0106-0107] “ . . . After obtaining the authorized login account information and the device information list bound to the authorized login account information, the IT administrator of the enterprise may obtain the to-be-managed device list based on the device information list. The to-be-managed device list may include all the identifiers in the device information list, or may include some identifiers in the device information list. In other words, the IT administrator can choose to manage some or all of the mobile devices that are purchased in batches. The IT administrator may configure the authorized login account information and the to-be-managed device list on the first electronic device. The first electronic device may be one (for example, any one or a specified one) of the mobile devices purchased by the enterprise in batches, or the first electronic device may not be one of the mobile devices purchased in batches. This is not specifically limited in this embodiment. Then, the first electronic device may send, to the first server, a request message that carries the authorized login account information and the to-be-managed device list, to apply for deployment of the MDM service. For example, the first electronic device is a tablet, and the second electronic device is a mobile phone. An enterprise purchases 1,000 Huawei phones for enterprise employees to use. In addition, during the purchase, a device vendor grants authorized login account information and a device information list (where the device information list includes IEMIs of the 1,000 Huawei phones) bound to the authorized login account information to an IT administrator of the enterprise. The IT administrator configures the authorized login account information and a to-be-managed device list on the tablet. For example, the to-be-managed device list includes the IEMIs of the 1,000 Huawei phones. Then, the tablet may send, to the first server, a request message that carries the IEMIs of the 1,000 Huawei phones and the authorized login account information, to request to deploy an MDM service on the tablet, so as to perform management and device system upgrade on the 1,000 Huawei phones. . . .”)
receive information sent by the second electronic device through the communication connection (see Chen ¶ [0007] “ . . . the first electronic device can provide the MDM service. The first electronic device establishes a wireless peer-to-peer (P2P) connection to the second electronic device, or the first electronic device and the second electronic device access a same local area network. The first electronic device provides the MDM service for the second electronic device, to implement management and device system upgrade of the second electronic device. . . .”) , wherein the information includes a security function supported by the second electronic device (see Chen ¶ [0047] “ . . . After the first electronic device 101 successfully applies for deployment of the MDM service, when the at least one second electronic device 102 and the first electronic device 101 are in a same local area network or establish a wireless peer-to-peer (P2P) connection, the first electronic device 101 can provide the MDM service, for example, that may include a management service and a system upgrade service, for the second electronic device 102, to implement management and device system upgrade of the least one second electronic device 102. In this embodiment, management implemented by the first electronic device 101 may include at least one of the following: device management, network management, security management, email management, content management, application management, and the like.. . ..”) and a security event generated by the second electronic device (see Chen ¶ ¶ [0111-0112] “ . . . obtain a service policy for at least one second electronic device. The service policy may include one or more of the following policies: a management policy, a configuration policy, and an upgrade policy. The management policy may include at least one of the following: a device management policy, a network management policy, a security management policy, an email management policy, a content management policy, an application management policy, and the like. The configuration policy may include a desktop wallpaper setting policy, a startup animation setting policy, a ringtone setting policy, and the like. ,
through the communication connection (see Chen Fig. 1 ¶ [0065] “ . . . the first electronic device 101 may establish a wireless P2P connection to the second electronic device 102 by using the wireless communication module 160 included in the first electronic device 101, or access a same local area network with the second electronic device 102. For another example, in some embodiments of this application, with reference to FIG. 1, the second electronic device 102 may establish a wireless P2P connection to the first electronic device 101 by using the wireless communication module 160 included in the second electronic device 102, or access a same local area network with the first electronic device 101 . . .”)
It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system where a first electronic device sends a request message including an identifier of at least one second electronic device to a first server. The first electronic device receives a DM service APP from the first server and installs the DM service APP. After the DM service APP is installed, the first electronic device can provide the MDM service. The first electronic device provides the MDM service for the second electronic device, to implement management and device system upgrade of the second electronic device, as taught by Chen, into a method and system for collecting security scores for a plurality of client devices where each device has a security dashboard where remedies and countermeasures can be deployed to address the security risks for the devices, and so proactively securing client devices by proactively determining whether the device is associated with a security risk and the level of the security risk, wherein, the device can transmit coordinates of its current geographic location to another device on the network, and to protect privacy of authorized users of the device, the transmission can be disabled by entering a password, and If multiple failed password attempts are detected, the device can determine that the device is currently being operated by an unauthorized user, and can proactively increase a security level of the device so that under the increased security level, files or other content stored on the device can be selectively protected, as taught by the combination of Condry and Borghei. Such incorporation enables one client device to manage the security activities of a second security device.
In regard to claim 2, the combination of Condry, Borghei and Chen teaches wherein the first electronic device is further configured to: after sending the first instruction to the second electronic device (see Condry ¶ [0040] as described for the rejection of claim 1 and is incorporated herein) , stop displaying, on the first user interface, the security risk item that exists on the second electronic device, or stop displaying the first prompt information (e.g. dismiss the security alert) (see Borghei ¶ [0063] “ . . . before sending the security alert to the user, server 110 can perform an independent analysis of security risks based on the security status and security event received from mobile device 106, to confirm or dismiss the security alert. . . .”).
The motivation to combine Borghei with Condry and Chen is described for the rejection of claim 1 and is incorporated herein. Additionally, Borghei provides the function to remove a displayed security alert once the security risk has been successfully removed.
In regard to claim 3, the combination of Condry, Borghei and Chen teaches wherein the second electronic device is further configured to send a second instruction to the first electronic device after eliminating the security risk item (e.g. updating the risk score) that exists on the second electronic device (see Condry ¶ [0044] “ . . . a secure communication manager 255 (in connection with a device manager 254 managing authentication to the corresponding host device (e.g., 205, 210)) can communicate directly with hardware based secure communication components of the host device to communicate and send updates to score data (e.g., 268, 270) for the respective host device. . . .”); and
the first electronic device is further configured to: after receiving the second instruction, stop displaying, on the first user interface, the security risk item that exists on the second electronic device, or stop displaying the first prompt information (see Condry ¶ [0045] “ . . . security score data of a host device can be maintained securely on the host device and provided to other devices in transactions with the host device to assist the other devices in appreciating risks associated with the host device and transactions involving the host device. . . .”)
In regard to claim 4, the combination of Condry, Borghei and Chen teaches wherein the security risk item that exists on the second electronic device further comprises one or more items (see Corday ¶ [0037] “ . . . While the examples of FIGS. 3A and 3B show score indicators that quantize a specific use-based risk score into one of a fixed set of potential indicators (e.g., "Excellent," "Good," "Warn," "Risky" uses, etc.), in other implementations, other representations of use-based risk scores can be included in an example security dashboard. For instance, presentation of a precise score value (e.g., on a scale of 0-10 or 0-100) can be presented along with a color (e.g., green, yellow, red) indicating whether the precise numerical score represents a generally safe, mixed, or risky use of the host device. In any event, a variety of user-friendly conventions can be employed to quickly and simply represent use-based risk profiles of a host device to its user to thereby guide the user in their use of the host device as well as in their management of the host device's security. . .”) , and the first operation conducted on the first electronic device is an operation of eliminating a first item comprised in the security risk item that exists on the second electronic device (e.g. selection of the FIX button) (see Corday ¶ [0039] “ . . . in addition to INFO buttons (e.g., 310) or other controls providing more detailed views of a use-based risk score, security dashboard 300a can further include additional controls, such as controls (e.g., 315, 318) adapted to launch potential remedies to identified deficiencies, vulnerabilities, and risks associated with a particular host device use. For instance, selection of a FIX button 315 for a Social Media use can cause a presentation of a listing of potential remedies for risk determined in connection with the Social Media use. For instance, selection of FIX button 315 can present a listing of potential countermeasures that can be activated, installed, downloaded, or otherwise used, at the request of the user, to mitigate against vulnerabilities and threats associated with Social Media use. . . .”) ; and
the second electronic device is further configured to: after receiving the first instruction, eliminate the first item that exists on the second electronic device (see Corday ¶ [0039] “ . . . countermeasures can be selected and downloaded, activated, or otherwise deployed directly from the presented listing of potential remedies presented in response to selection of FIX button 315. In other instances, selection of FIX button 315 can itself automate selection and deployment of one or more countermeasures without further intervention by the user. In either instance, countermeasures can be automatically identified that have been previously determined to potentially address those vulnerabilities and other attributes of the host device (e.g., as identified in the related security posture data) relating to a particular host device use. . . .”)
In regard to claim 5. the combination of Condry, Borghei and Chen teaches wherein the security risk item that exists on the second electronic device comprises one or more items (see Corday ¶ [0037] “ . . . While the examples of FIGS. 3A and 3B show score indicators that quantize a specific use-based risk score into one of a fixed set of potential indicators (e.g., "Excellent," "Good," "Warn," "Risky" uses, etc.), in other implementations, other representations of use-based risk scores can be included in an example security dashboard. For instance, presentation of a precise score value (e.g., on a scale of 0-10 or 0-100) can be presented along with a color (e.g., green, yellow, red) indicating whether the precise numerical score represents a generally safe, mixed, or risky use of the host device. In any event, a variety of user-friendly conventions can be employed to quickly and simply represent use-based risk profiles of a host device to its user to thereby guide the user in their use of the host device as well as in their management of the host device's security. . .”), and the first operation conducted on the first electronic device is an operation of eliminating all the one or more items comprised in the security risk item that exists on the second electronic device (e.g. FIX button) (see Corday ¶ [0039] “ . . . In addition to INFO buttons (e.g., 310) or other controls providing more detailed views of a use-based risk score, security dashboard 300a can further include additional controls, such as controls (e.g., 315, 318) adapted to launch potential remedies to identified deficiencies, vulnerabilities, and risks associated with a particular host device use. For instance, selection of a FIX button 315 for a Social Media use can cause a presentation of a listing of potential remedies for risk determined in connection with the Social Media use. For instance, selection of FIX button 315 can present a listing of potential countermeasures that can be activated, installed, downloaded, or otherwise used, at the request of the user, to mitigate against vulnerabilities and threats associated with Social Media use. In some instances, countermeasures can be selected and downloaded, activated, or otherwise deployed directly from the presented listing of potential remedies presented in response to selection of FIX button 315. In other instances, selection of FIX button 315 can itself automate selection and deployment of one or more countermeasures without further intervention by the user. In either instance, countermeasures can be automatically identified that have been previously determined to potentially address those vulnerabilities and other attributes of the host device (e.g., as identified in the related security posture data) relating to a particular host device use. . . .”) ; and
the second electronic device is further configured to: after receiving the first instruction, eliminate all the one or more items comprised in the security risk item that exists on the second electronic device (see ¶ [0042] (“ . . . users, in response to being presented with use-based risk scores, can utilize a security dashboard generated by a security dashboard engine 242, 244 to launch one or more remedies for sub-standard security scores for some uses of the host device. Host device attributes that are identified as negatively impacting a particular use's security score for a host device can be mapped to known countermeasures and other remedies identified and catalogued, for example, using a risk resolution engine 252. Such countermeasures can be further filtered based on the countermeasures' and remedies' compatibility with the host device in question. Such mappings and filters can be performed, in some implementations at security score engine 215. Remedy data 260 indicating the identified countermeasures and remedies can be communicated to the security dashboard engine, for instance, in response to a user selection of a security dashboard control, such as, for example, a FIX button (e.g., 315, 318). In some instances, available countermeasure data that could potentially apply to a particular host device can, instead, be communicated together with score data, security posture data, or other data used by the security dashboard engine (e.g., 242, 244) in the rendering of a security dashboard including use-based risk scores for a particular host device, among other techniques. Countermeasure and remedy information can also include information or instructions for use in developing automated requests to deploy the countermeasure on the host device (e.g., based on a selection of a corresponding FIX button by a user), or to provide instructions to a user for implementing the presented countermeasures. . . .”)
In regard to claim 6, the combination of Condry, Borghei and Chen teaches wherein the first electronic device is further configured to display a second user interface (e.g. security status) before displaying the first user interface (see Borghei ¶ [0042] “ . . . Providing the security status to the requester can include displaying the security status and an explanation how the security status is derived on a display screen, as well as displaying the retrieved security parameters on the display screen. . . .”) ,
wherein the second user interface comprises a device option of the first electronic device and a device option of the second electronic device (see Borghei ¶ [0081] “ . . . FIGS. 4A-4B illustrate exemplary user interfaces through which a user can remotely access security information of a mobile device. For convenience, the features of FIGS. 4A-4B will be described in reference to server 110 that can provide the user interfaces, user computer 134 that can display the interfaces, and mobile device 106. . . .”) ,
the device option of the first electronic device comprises a security level indicator of the first electronic device, indicating a security status of the first electronic device, wherein the security status of the first electronic device comprises any one of a high risk, a medium risk, a low risk, and no risk (see Condry ¶ [0037] “ . . . While the examples of FIGS. 3A and 3B show score indicators that quantize a specific use-based risk score into one of a fixed set of potential indicators (e.g., "Excellent," "Good," "Warn," "Risky" uses, etc.), in other implementations, other representations of use-based risk scores can be included in an example security dashboard. For instance, presentation of a precise score value (e.g., on a scale of 0-10 or 0-100) can be presented along with a color (e.g., green, yellow, red) indicating whether the precise numerical score represents a generally safe, mixed, or risky use of the host device. In any event, a variety of user-friendly conventions can be employed to quickly and simply represent use-based risk profiles of a host device to its user to thereby guide the user in their use of the host device as well as in their management of the host device's security. . . .”) , and
the device option of the second electronic device comprises a security level indicator of the second electronic device, indicating a security status of the second electronic device, wherein the security status of the second first electronic device comprises any one of the high risk, the medium risk, the low risk, and no risk (see Condry ¶ [0038] “ . . . , a security dashboard can further include interactive controls that assist users in better understanding the basis and nature of the security status of their device, as well as the potential remedies and improvements that can be employed to improve the use-based risk profile of their device. In one example, an "INFO" button (e.g., 310) can be presented corresponding to a particular use-based risk score of the host device. For example, in this case, a user can select INFO button 310 corresponding to a Safe Web Browsing use category to prompt the presentation of additional information or windows including information describing the security profile of Safe Web Browsing in more detail. For instance, selection of an INFO button (e.g., 310) can present a description of the types of risks and threats that can potentially afflict a category of device usage generally, as well as breakdown the specific attributes of the particular host device leading to the generated use-based score. As an example, as shown in the screenshot of FIG. 3C, selection of the INFO button 310 for Safe Web Browsing can result in the presentation of a detailed view 330 showing the more technical description of configurations and attributes of the host device relevant to the security of using the host device for web browsing (and otherwise hidden or abstracted in the presented security dashboard). Visual effects and other indicators (e.g., 335, 340) can be presented within the listing 330 calling attention to those host device attributes that contribute negatively (or positively) to the use-base risk score for the particular use (e.g., web browsing, ecommerce, etc.). Presentation of a detailed view of the attributes and sub-systems of the host device can allow a more experienced or confident user to view a more traditional attribute-focused security assessment to better understand and consider the technical aspects underlying a use-based risk score. Additional information, such as information from outside sources, can be linked to through one or more of the user interfaces, such as links presented beside each element in the listing 330. For example, a user can gain additional knowledge concerning one or more of the host device attributes considered in the determination of a use-based risk score by clicking on a corresponding link (e.g., 342), among other mechanisms and examples. For instance, returning to the examples of FIGS. 3A-3B, in some implementations, detailed information presented in connection with the selection of the INFO button 310 can include information describing the types of risks inherent in a particular host device use, the types of threats, attacks, and damage that can result, as well as some of the general techniques and tools that can be applied to avoid or counter these risks. Such information can be provided to serve an educational purpose, assisting users in understanding what types of configurations, programs, networks, user behaviors, etc. make a particular type of computer use risky. . . .”) ; and
the first electronic device is further configured to: receive and respond to a second operation of the user on the device option of the second electronic device on the second user interface, and display the first user interface (see Condry ¶ [0049] “ . . . From security posture data for the host device, the current status of each host device attribute can be identified, such as an identification of version of a particular application, patch, or security tool, its availability, and whether the particular attribute, software, tool, etc. is active or not. From this information, the respective attributes can be scored relative to the particular host device use, for instance, based on each attribute's relative importance to the host device's security during the use (i.e., the degree to which the particular attribute can potentially positively or negatively influence the security of the host device during the use). The score components of the subset of identified host device attributes can then be compiled to generate a composite use-based risk score (e.g., 505) for the particular use of the host device (e.g., ecommerce, online banking, email, web browsing, etc.). Such attributes, as described in security posture data for instance, can be re-used in the generation of other use-based risk scores as well as aggregate security scores for the host device, among other examples . . .”).
The motivation to combine Borghei with Condry and Chen is described for the rejection of claim 1 and is incorporated herein. Additionally, Borghei provides a first user interface to authenticate the user before assessing further risk to the device.
In regard to claim 7, the combination of Condry, Borghei and Chen teaches wherein the first electronic device is further configured to: display second prompt information after receiving the first operation (see Condry ¶ [0042] “ . . . users, in response to being presented with use-based risk scores, can utilize a security dashboard generated by a security dashboard engine 242, 244 to launch one or more remedies for sub-standard security scores for some uses of the host device. Host device attributes that are identified as negatively impacting a particular use's security score for a host device can be mapped to known countermeasures and other remedies identified and catalogued, for example, using a risk resolution engine 252 . . .”) , wherein the second prompt information comprises a first control (see Condry ¶ [0042] “ . . . Such countermeasures can be further filtered based on the countermeasures' and remedies' compatibility with the host device in question. Such mappings and filters can be performed, in some implementations at security score engine 215. Remedy data 260 indicating the identified countermeasures and remedies can be communicated to the security dashboard engine, for instance, in response to a user selection of a security dashboard control, such as, for example, a FIX button (e.g., 315, 318) . . . “) , and the second prompt information indicates whether to eliminate the security risk item that exists on the second electronic device (see Condry ¶ [0042] “ . . . In some instances, available countermeasure data that could potentially apply to a particular host device can, instead, be communicated together with score data, security posture data, or other data used by the security dashboard engine (e.g., 242, 244) in the rendering of a security dashboard including use-based risk scores for a particular host device, among other techniques. Countermeasure and remedy information can also include information or instructions for use in developing automated requests to deploy the countermeasure on the host device (e.g., based on a selection of a corresponding FIX button by a user), or to provide instructions to a user for implementing the presented countermeasures. Indeed, in some instances, a single click of a FIX button (or other similar control) can prompt the automated selection of a particular remedy or countermeasure (such as a remedy identified as having the best reputation or highest effectiveness (e.g., from a neutral assessment of countermeasures) or even countermeasures of particular preferred or default vendors) in response to the selection of the button . . .”); and
receive and respond to a fifth operation on the first control, and send the first instruction to the second electronic device (see Condry ¶ [0042] “ . . . In other instances, users can be presented with a menu of available countermeasures (e.g., generated from remedy data 260) that could be deployed to improve a host device's particular use-based risk score, and selection of a particular one of the countermeasures can cause the particular countermeasure to be deployed, among other examples. . . .”)
In regard to claim 8, the combination of Condry and Borghei teaches wherein the second electronic device is further configured to send the second instruction to the first electronic device after eliminating the security risk item that exists on the second electronic device (see Condry ¶ [0048] “ . . . Turning to FIG. 5, a chart 500 is shown representing an example of security score data processed to generate a particular use-based risk score. Security score data (e.g., 445), such as security posture data describing identified attributes of the host device determined to affect its security, such as through a mapping of attributes to known vulnerabilities and countermeasures, as well as values indicating the seriousness, importance, effectiveness, and overall relevance of the mapped attributes to the security of the host device. Such information can be utilized to generate security scores. For instance, in the example of FIG. 5, security posture data has been identified listing host device attributes identified as potentially affecting or otherwise germane to the security of the host device. Further, a subset of these attributes can be identified as pertaining to security of or risk associated with a particular one of a set of potential uses of the host device. Such identified attributes can include the presence of anti-malware software on the host device, encryption on the host device, patches installed on the host device, anti-theft, firewall applications, system recovery status, among other attributes and examples. . . .”) ;
the first electronic device is further configured to display third prompt information after receiving the second instruction, wherein the third prompt information comprises a second control, and the third prompt information indicates whether to cancel elimination of the security risk item that exists on the second electronic device (see Condry ¶ [0049] “ . . . From security posture data for the host device, the current status of each host device attribute can be identified, such as an identification of version of a particular application, patch, or security tool, its availability, and whether the particular attribute, software, tool, etc. is active or not. From this information, the respective attributes can be scored relative to the particular host device use, for instance, based on each attribute's relative importance to the host device's security during the use (i.e., the degree to which the particular attribute can potentially positively or negatively influence the security of the host device during the use). The score components of the subset of identified host device attributes can then be compiled to generate a composite use-based risk score (e.g., 505) for the particular use of the host device (e.g., ecommerce, online banking, email, web browsing, etc.). Such attributes, as described in security posture data for instance, can be re-used in the generation of other use-based risk scores as well as aggregate security scores for the host device, among other examples. . . .”); and
the first electronic device is further configured to: after receiving and responding to a sixth operation on the second control, determine to eliminate the security risk item that exists on the second electronic device (see Condry ¶ [0050] “ . . . an aggregate security score can be generated for a host device 410 based on security data collected at security tools (e.g., 415, 420) and the host device 410, including the same security data used to calculate use-based risk scores for the host device. Further, in other instances, security score data, such as a security posture for the host device, or even a plurality of use-based risk scores can be used to calculate an aggregate security score for the device. As shown in the example screenshot of FIG. 3D, a representation 350 of the overall health of the device can be presented in connection with a security dashboard also adapted to present representations of use-based risk scores for the host device. An aggregate security score (e.g., 355) for a host device can be represented so as to offer a user with a quick and easy-to-understand representation of the host device's overall security. In some implementations, the security score can be based on the host device's health relative to all other host devices monitored or scored using, for instance, a common security score server system or other system. For example, a mean or median security profile can be determined for a plurality of host devices and an aggregate security score generated from collected host device attributes can indicate the respective host device's security relative to the average host device monitored by the system (for which attributes are known), among other examples. . . .”)
In regard to claim 9, the combination of Condry, Borghei and Chen teaches wherein eliminating the security risk item that exists on the second electronic device further comprises enabling a security function supported by the second electronic device (see Borghei ¶ [0086] “ . . . User interface 400a can include pushbutton 404 that allows the user to secure mobile device 106. Pushbutton 404 can active a second user interface that enables the user to select various levels of secure operation modes. The user can select a secure operation mode that the user feels most appropriate for the situation, for example, based on the location of mobile device 106. In some implementations, pushbutton 404 can cause server 110 to set mobile device 106 to an autonomous secure operation mode . . .”) , eliminating a security risk event generated by the second electronic device in first duration (see Borghei ¶ [0087] “ . . . FIG. 4B illustrates exemplary user interface 400b that accept various user commands to perform various actions when a high-risk security event has occurred. In some implementations, viewing of user interface 400b can be limited to a user of an investigative organization. User interface 400b can include map 408b for displaying a current position of mobile device 106 (e.g., at circle 410b). User interface 400b can further include controls (e.g., pushbuttons) 412, 414, and 416. Controls 412, 414, 416 can be used to activate tracking functions on mobile device 106. . . .”), and performing a security protection suggestion for the second electronic device (see Borghei ¶ [0088] “ . . . , pushbutton 412 can activate a user interface in which the a suspicious act, and reason why the act is suspicious, is displayed. An act is suspicious if server 110 or mobile device 106 has determined that mobile device 106 has high security risk related to the act (e.g., by a combination of factors that mobile device is located in a high crime area, has made suspicious phone calls, the caller's voice signature does not match any of authorized users, etc.). Pushbutton 414 can activate a user interface in which a list of phone numbers that mobile device has called recently, the duration of each phone call, and the geographic area of the destination number. The geographic area can be indicated by the area code of the destination number. In the user interface where the list of phone numbers is displayed, the user can select a phone number and listen to a snippet of the phone call or view a transcript of the snippet. Pushbutton 416 can active a user interface where images and video clips captured by mobile device 106 can be displayed. The user interface can also include controls for activating functions for playing the recorded ambient audio. . . “).
The motivation to combine Borghei with Condry and Chen is described for the rejection of claim 1 and is incorporated herein. Additionally, Borghei provides functions for the electronic devices that will suggest and execute the remedies to the risk using particular pushbuttons from the user interface.
In regard to claim 10, Condry teaches A device security processing method (see ¶ [0062] “ . . . subject matter of the present disclosure includes methods, software, computer executable instructions, and systems capable of performing such tasks as collecting attribute data of an endpoint computing device describing attributes of the endpoint computing device, communicating the attribute data to a security score generator, and receiving security score data for the endpoint computing device . . “) , comprising:
displaying, by the first electronic device(e.g. see Fig. 1 plurality of end-user host devices) (see ¶ [0011] “ . . . FIG. 1 is a simplified block diagram illustrating an example computing system 100 including end-user host devices 105, 110, 115, 120 for which corresponding security scores can be generated. The security scores can be based on security postures determined for the host devices 105, 110, 115, 120. . . .”), a first user interface (e.g. security dashboard) or first prompt information based on the information (see ¶ [0014] as described for the rejection of claim 1 and is incorporated herein) ,
wherein a security risk item that exists on the second electronic device is displayed on the first user interface, or the first prompt information indicates that the security risk item exists on the second electronic device(see ¶ [0084] as described for the rejection of claim 1 and is incorporated herein) ,
wherein the first electronic device and the second electronic device belong to a device security processing system (see Fig. 1 as described above);
receiving, by the first electronic device, a first operation of a user on the first user interface or the first prompt information(see ¶ [0033] as described for the rejection of claim 1 and is incorporated herein) , wherein the first operation is used to eliminate the security risk item that exists on the second electronic device (see ¶ [0039] as described for the rejection of claim 1 and is incorporated herein); and
sending, by the first electronic device, a first instruction (e.g. countermeasures) to the second electronic device (see ¶ [0040] as described for the rejection of claim 1 and is incorporated herein) , wherein the first instruction indicates the second electronic device to eliminate (e.g. remedies) the security risk item that exists on the second electronic device (see ¶ [0042] as described for the rejection of claim 1 and is incorporated herein).
Condry fails to explicitly teach,
However Borghei teaches , and the security risk item that exists on the second electronic device is related to user privacy (see Fig. 5B ¶ [0100] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Borghei with Condry is described for the rejection of claim 1 and is incorporated herein.
The combination of Condry and Borghei fails to explicitly teach,
However Chen teaches
receiving, by a first electronic device, information sent by a second electronic device through a communication connection (see Chen ¶ [0007] as described for the rejection of claim 1 and is incorporated herein), wherein the information includes a security function supported by the second electronic device(see Chen ¶ [0047] as described for the rejection of claim 1 and is incorporated herein) and a security event generated by the second electronic device(see Chen ¶ ¶ [0111-0112] as described for the rejection of claim 1 and is incorporated herein) , wherein the first electronic device and a second electronic device log in to a same system account to establish the communication connection(see Chen ¶ ¶ [0106-0107] as described for the rejection of claim 1 and is incorporated herein) ;
through the communication connection (see Chen Fig. 1 ¶ [0065] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Chen with the combination of Condry and Borghei is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 11, the combination of Condry Borghei, and Chen teaches wherein after sending the first instruction to the second electronic device (see Condry ¶ [0040] as described for the rejection of claim 1 and is incorporated herein), the method further comprises:
stopping displaying, by the first electronic device on the first user interface , the security risk item that exists on the second electronic device, or stopping displaying the first prompt information (e.g. dismiss the security alert) (see Borghei ¶ [0063] as described for the rejection of claim 2 and is incorporated herein).
The motivation to combine Borghei with Condry and Chen is described for the rejection of claim 2 and is incorporated herein.
In regard to claim 12, the combination of Condry, Borghei, and Chen teaches wherein after sending the first instruction to the second electronic device, the method further comprises:
receiving, by the first electronic device, a second instruction sent by the second electronic device, wherein the second instruction indicates that the second electronic device has eliminated the security risk item (e.g. updating the risk score) that exists on the second electronic device (see Condry ¶ [0044] as described for the rejection of claim 3 and is incorporated herein) ; and
in response to the second instruction, stopping displaying, by the first electronic device on the first user interface, the security risk item that exists on the second electronic device, or stopping displaying the first prompt information (see Condry ¶ [0045] as described for the rejection of claim 3 and is incorporated herein).
In regard to claim 13, the combination of Condry, Borghei and Chen teaches wherein the security risk item that exists on the second electronic device further comprises one or more items (see Corday ¶ [0037] as described for the rejection of claim 4 and is incorporated herein), and the first operation conducted on the first electronic device is an operation of eliminating a first item comprised in the security risk item that exists on the second electronic device (e.g. selection of the FIX button) (see Corday ¶ [0039] as described for the rejection of claim 4 and is incorporated herein)
In regard to claim 14, the combination of Condry, Borghei and Chen teaches wherein the security risk item that exists on the second electronic device further comprises one or more items(see Cordry ¶ [0037] as described for the rejection of claim 5 and is incorporated herein), and the first operation conducted on the first electronic device is an operation of eliminating all the one or more items comprised in the security risk item that exists on the second electronic device (e.g. FIX button) (see Corday ¶ [0039], ¶ [0042] as described for the rejection of claim 5 and is incorporated herein)
In regard to claim 15, the combination of Condry, Borghei, and Chen teaches wherein before displaying by the first user interface, the method further comprises: displaying, by the first electronic device, a second user interface (e.g. security status) (see Borghei ¶ [0042] as described for the rejection of claim 6 and is incorporated herein) ,
wherein the second user interface comprises a device option of the first electronic device and a device option of the second electronic device (see Borghei ¶ [0081] as described for the rejection of claim 6 and is incorporated herein)],
wherein the device option of the first electronic device comprises a security level indicator of the first electronic device, indicating a security status of the first electronic device, wherein the security status of the first electronic device comprises any one of a high risk, a medium risk, a low risk, and no risk (see Condry ¶ [0037] as described for the rejection of claim 6 and is incorporated herein) , and
wherein the device option of the second electronic device comprises a security level indicator of the second electronic device, indicating a security status of the second electronic device, wherein the security status of the second electronic device comprises any one of the high risk, the medium risk, the low risk, and no risk (see Condry ¶ [0038] as described for the rejection of claim 6 and is incorporated herein); and
wherein displaying the first user interface further comprises: receiving and responding to, by the first electronic device, a second operation of the user on the device option of the second electronic device on the second user interface, and displaying the first user interface (see Condry ¶ [0049] as described for the rejection of claim 6 and is incorporated herein).
The motivation to combine Borghei with Condry and Chen is described for the rejection of claim 6 and is incorporated herein.
In regard to claim 17, the combination of Condry, Borghei, and Chen teaches wherein sending the first instruction to the second electronic device after receiving the first operation further comprises:
displaying, by the first electronic device, second prompt information after receiving the first operation (see Condry ¶ [0042] as described for the rejection of claim 7 and is incorporated herein) , wherein the second prompt information comprises a first control (see Condry ¶ [0042] as described for the rejection of claim 7 and is incorporated herein), and the second prompt information indicates whether to eliminate the security risk item that exists on the second electronic device(see Condry ¶ [0042] as described for the rejection of claim 7 and is incorporated herein) ; and
receiving and responding to, by the first electronic device, a fifth operation on the first control, and sending the first instruction to the second electronic device (see Condry ¶ [0042] as described for the rejection of claim 7 and is incorporated herein)
In regard to claim 18, the combination of Condry, Borghei and Chen teaches wherein after sending the first instruction to the second electronic device, the method further comprises:
receiving, by the first electronic device, the second instruction sent by the second electronic device, wherein the second instruction indicates that the second electronic device has eliminated the security risk item that exists on the second electronic device (see Condry ¶ [0048] as described for the rejection of claim 8 and is incorporated herein) ;
displaying, by the first electronic device, third prompt information after receiving the second instruction, wherein the third prompt information comprises a second control, and the third prompt information indicates whether to cancel elimination of the security risk item that exists on the second electronic device(see Condry ¶ [0049] as described for the rejection of claim 8 and is incorporated herein) ; and
determining, by the first electronic device after receiving and responding to a sixth operation on the second control, to eliminate the security risk item that exists on the second electronic device (see Condry ¶ [0050] as described for the rejection of claim 8 and is incorporated herein)
In regard to claim 19, the combination of Condry, Borghei, and Chen teaches wherein eliminating the security risk item that exists on the second electronic device further comprises enabling a security function supported by the second electronic device (see Borghei ¶ [0086] as described for the rejection of claim 9 and is incorporated herein), eliminating a security risk event generated by the second electronic device in first duration (see Borghei ¶ [0087] as described for the rejection of claim 9 and is incorporated herein) , and performing a security protection suggestion for the second electronic device (see Borghei ¶ [0088] as described for the rejection of claim 9 and is incorporated herein).
The motivation to combine Borghei with Condry and Chen is described for the rejection of claim 9 and is incorporated herein.
In regard to claim 20, Cordry teaches A first electronic device (e.g. see Fig. 1 plurality of end-user host devices) (see ¶ [0011] “ . . . FIG. 1 is a simplified block diagram illustrating an example computing system 100 including end-user host devices 105, 110, 115, 120 for which corresponding security scores can be generated. The security scores can be based on security postures determined for the host devices 105, 110, 115, 120. . . .”), comprising:
one or more processors (see ¶ [0016]” . . . Further, servers, clients, network elements, systems, and computing devices (e.g., 105, 120, 125, 130, 135, 140, etc.) can each include one or more processors, . . “) ;
one or more memories coupled to the one or more processors, configured to store computer program code comprising computer instructions for execution by the one or more processors (see ¶ [0016] “ . . . computer-readable memory, and one or more interfaces, among other features and hardware. Servers can include any suitable software component or module, or computing device(s) capable of hosting and/or serving software applications and services (e.g., security score server 125, dashboard server 130, and security tool providers 135, 140, etc.), including distributed, enterprise, or cloud-based software applications, data, and services. For instance, in some implementations, a security score server 125 or other sub-system of computing system 100 can be a cloud-implemented system configured to remotely host, serve, or otherwise manage data, software services and applications interfacing, coordinating with, dependent on, or used by other services and devices in system 100. In some instances, a server, system, subsystem, or computing device can be implemented as some combination of devices that can be hosted on a common computing system, server, server pool, or cloud computing environment and share computing resources, including shared memory, processors, and interfaces . . .”), to enable the first electronic device to perform-:
displaying, by the first electronic device(e.g. see Fig. 1 plurality of end-user host devices), a first user interface (e.g. security dashboard) or first prompt information(see ¶ [0014] as described for the rejection of claim 1 and is incorporated herein), wherein a security risk item that exists on the second electronic device is displayed on the first user interface, or the first prompt information indicates that a-the security risk item exists on the second electronic device (see ¶ [0084] as described for the rejection of claim 1 and is incorporated herein) ,
receiving, by the first electronic device, a first operation of a user on the first user interface or the first prompt information based on the information (see ¶ [0033] as described for the rejection of claim 1 and is incorporated herein), wherein the first operation is used to eliminate the security risk item that exists on the second electronic device(see ¶ [0039] as described for the rejection of claim 1 and is incorporated herein); ; and
sending, by the first electronic device, a first instruction(e.g. countermeasures) to the second electronic device (see ¶ [0040] as described for the rejection of claim 1 and is incorporated herein) , wherein the first instruction indicates the second electronic device to eliminate (e.g. remedies) the security risk item that exists on the second electronic device (see ¶ [0042] as described for the rejection of claim 1 and is incorporated herein).
Condry fails to explicitly teach,
However Borghei teaches , and the security risk item that exists on the second electronic device is related to user privacy (see Fig. 5B ¶ [0100] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Borghei with Condry is described for the rejection of claim 1 and is incorporated herein.
The combination of Condry and Borghei fails to explicitly teach,
However Chen teaches
receiving information sent by a second electronic device through a communication connection (see Chen ¶ [0007] as described for the rejection of claim 1 and is incorporated herein), wherein the information includes a security function supported by the second electronic device(see Chen ¶ [0047] as described for the rejection of claim 1 and is incorporated herein) and a security event generated by the second electronic device(see Chen ¶ ¶ [0111-0112] as described for the rejection of claim 1 and is incorporated herein) , wherein the first electronic device and the second electronic device log in to a same system account to establish the communication connection (see Chen ¶ ¶ [0106-0107] as described for the rejection of claim 1 and is incorporated herein) ;
through the communication connection (see Chen Fig. 1 ¶ [0065] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Chen with the combination of Condry and Borghei is described for the rejection of claim 1 and is incorporated herein.
Allowable Subject Matter
Claim 16 is objected to as being dependent upon a rejected base claims 10 and 15, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
In regard to claim 16, , the combination of Condry and Borghei teaches wherein after displaying the second user interface, and before displaying the first user interface, the method further comprises:
receiving and responding to, by the first electronic device, a third operation of the user on the second user interface, and displaying a third user interface, wherein a security risk item that exists on the first electronic device and the security risk item that exists on the second electronic device are displayed on the third user interface;
receiving, by the first electronic device, a fourth operation of the user on the third user interface, wherein the fourth operation is used to eliminate the security risk item on the first electronic device and the security risk item that exists on the second electronic device; and
in response to the fourth operation, eliminating, by the first electronic device, the security risk item that exists on the first electronic device, and sending a third instruction to the second electronic device, wherein the third instruction indicates the second electronic device to eliminate the security risk item that exists on the second electronic device.
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action
Applicant's amendment (e.g. new claim 19) 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 extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
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, John A. Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES N FIORILLO/Primary Examiner, Art Unit 2444
