DETAILED ACTION
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 action is in response to the amendment filed on 12/02/2025.
Claims 1-20 are currently pending in this application. Claims 1-12 and 16-19 have been amended.
No new IDS has been filed.
Examiner’s Note
Applicants are suggested to include information from figures 7A-7C with related text into the claims to provide a better condition for an allowance.
Response to Arguments
The previous objection to claim 1 has been withdrawn in response to the applicant’s amendment/remarks.
Regarding the previous 112(b) rejections, the applicant has amended the claims and argued, in page 8 of the remarks, that “… claims 1-12 and 16-19 have been amended herewith … requests the withdrawal of the rejections …”. However, the applicant’s amendments do not overcome all of the previous rejections or/and the current amendments cause the new rejections stated in the 112 rejections section below.
Regarding the 102 rejections, the applicants amended claim 1 to include “… deploying one or more privacy agents … compute resources in one or more geographic regions … generating a risk profile by comparing the received system metric data to current privacy statements that are based on organizational privacy settings, wherein the current privacy state requirements comprises geographically specific resourcing requirements associated with the one or more geographic regions …”, and have, in pages 9 and 10 of the remarks, argued that “…the cited reference does not disclose … Trivellato indicates: policy components 418 is operatable … Trivellato, col. 26, lines 4-25 … however, Trivellato does not disclose or suggest any type of “current privacy state requirement” …” let alone “generating a risk profile by … associated with the one or more geographic regions” …. claim 1 is patentably distinct from the cited art …”
The applicant’s these arguments are not persuasive.
As taught in Trivellato, Trivellato clearly teaches that “… more accurate risk reporting that enables a user to take the most effective action on the most at risk assets as they address risks throughout the network in a prioritized manner … configured for determining a more sophisticated risk score … reflected in a single value that can be visualized to allow prioritization … enable better use of compliance and security resources within an organization …” – see col. 9, lines 15-48; and “… a network monitor device 280 which may handle gathering information about the various devices communicatively coupled to example network 200. Network monitor device 280 can perform comprehensive risk analysis of entities (e.g., devices 230-234 and 260-262) and combine risk scores (e.g., for one or more locations), as described herein, for example network 200 …” – see fig. 2 and col. 13, lines 57-67. Moreover, Trivellato further teaches that “… cause the processing device to determine a risk value for a location based on a plurality of risk values associated with a plurality of entities associated with the location. The location may be at least one of a geographic region, a plant …” – see col. 26, lines 57-62. In other words, Trivellato clearly teaches “… generating a risk profile (e.g., risk reporting) by comparing the received system metric data (e.g., gathered information of the devices of the network system 200) to current privacy statements (e.g., the compliance information used in the compliance analysis) that are based on organizational privacy settings (e.g., the compliance and security resources within the organization), wherein the current privacy state requirements (e.g., the risk value used in the compliance analysis) comprises geographically specific resourcing requirements associated with the one or more geographic regions (e.g., the risk value associated with the geographic regions – see figure 2 for regions, 290, 292, etc.) ….”.
Although, Trivellato teaches the amended limitation described above, a new reference (US 2021/0185077 A1 by Shavlik), for a compact prosecution, is added. See the 102/103 rejections below for detail.
The applicants’ arguments regarding the claims 9, 17 and dependent claims for the limitations of claim 1 described above is not persuasive and the response for the argument is similar to the response stated above for the claim 1.
Thus, the applicants’ arguments are not persuasive. Please see amended rejections below for the amended claims. This action is final.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
Claims 1 (claims 9 and 17 include similar limitations) recites:
“… one or more compute resources in one or more geographic regions, wherein the computing metrics are based on at least one of settings and functions of a respective compute resource of the one or more compute resources … privacy settings, wherein the current privacy state requirements comprise geographically specific resourcing requirements …”; however, it is not clear (1) whether “the respective compute resource” is respective to the geographic region or not (e.g., how to define the term, respective, etc.); (2) whether there are any relationship between the “resources in one geographic region” and “geographically specific resourcing” –– it is not clear to define a boundary of the limitations/components (note: for examining purpose, they are interpreted as not related to each other).
“… generating a risk profile by comparing the received system metric data to current privacy state requirements that are based on organizational privacy settings, wherein the current privacy state requirements comprise geographically specific resourcing requirements associated with the one or more geographic regions …”, however, it is not clear (1) whether comparing the system metric data and the current privacy state requirements generates the risk profile or not (or how the two data are the same or not is generating the risk profile, etc.) – or omitting necessary steps/components which cause the limitations unclear; (2) whether the organizational privacy settings is the privacy settings of the organization of the computing system (e.g., how the organization is related to the computing system, etc.) or not – it is not clear to define a boundary of the limitations/components; (3) how to define the “geographically specific” for the “resourcing requirements” – or omitting necessary component/step which causes the limitations unclear.
Claims 2-8, 10-16 and 18-20 depend from the claim 1, 9 or 17, and are analyzed and rejected accordingly.
Claims 5 and 13 recite “… explicit lists, and underlying capabilities of one or more systems receiving annotations”, however, it is not clear (1) how to define the explicit lists – it is not clear to define a boundary of the limitations; (2) whether the “one or more systems receiving annotations” is the fully managed serverless computing system or the computing system of the claim 1 or not – omitting necessary component/step which causes the limitations unclear.
Claims 6, 7, 14, 15 and 20 recite “… executing the configuration file to spin up one or more resources in compliance …”, however, it is not clear how the spin up of the configuration file can be in compliance with the requirements.
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-18 are rejected under 35 U.S.C. 103 as being unpatentable over Trivellato et al. (US 11,277,431 B2) in view of Shavlik (US 2021/0185077 A1).
As per claim 1, Trivellato teaches a computing system [see the system of fig. 1; col. 9, line 64 – col. 10, line 62], the computing system comprising: one or more processors; and one or more computer-readable media storing instructions that are executable to cause the one or more processors to perform operations [see figs. 1, 4, 10; col. 23, lines 55-67; col. 30, lines 37-65 for the hardware and/or software components performing the operations], the operations comprising:
deploying one or more privacy agents; receiving, from the one or more privacy agents, system metric data comprising compute metrics associated with one or more compute resources in one or more geographic regions, wherein the compute metrics are based on at least one of settings and functions of a respective compute resource of the one or more compute resources [abstract; figs. 1-3; col. 11, lines 20-67; col. 12, lines 1-25; col. 13, lines 57-67; col. 14, lines 57-64 of Trivellato teaches deploying one or more privacy agents (e.g., the agent gathering information associated with the device and sending it to the monitor device); receiving, from the one or more privacy agents, system metric data (e.g., agent gathered information such as operating system, version, patch level, firmware version, model, asset tag, software/application, configured active service, configured ports, MAC address, processor utilization, unique ID, computer name, account access activity, etc.) comprising compute metrics associated with one or more compute resources (e.g., the resource related to the gathered information) in one or more geographic regions (e.g., the locations/regions 290, 292, etc.), wherein the compute metrics are based on at least one of settings and functions (e.g., configuration, setting values, processes/performance, etc.) of a respective compute resource of the one or more compute resources (e.g., the resources related to the gathered information)];
generating a risk profile by comparing the received system metric data to current privacy state requirements that are based on organizational privacy setting, wherein the current privacy state requirements comprise geographically specific resourcing requirements associated with the one or more geographic regions [figs. 1-4; col. 9, lines 15-48; col. 13, lines 57-67; col. 16, lines 20-58; col. 25, lines 54-63; col. 26, lines 57-62 of Trivellato teaches generating a risk profile (e.g., risk reporting) by comparing the received system metric data (e.g., gathered information of the devices of the network system 200) to current privacy statements (e.g., the compliance information used in the compliance analysis) that are based on organizational privacy settings (e.g., the compliance and security resources within the organization), wherein the current privacy state requirements (e.g., the risk value used in the compliance analysis) comprises geographically specific resourcing requirements associated with the one or more geographic regions (e.g., the risk value associated with the geographic regions – see figure 2 for regions, 290, 292, etc.)]; and
based on the risk profile, performing an action comprising at least one of (i) causing a user interface to update to display a notification indicative of the risk profile and (ii) generating and initiating a configuration file to adjust the settings comprising one or more compute resource settings [figs. 3-9; col. 2, lines 16-18; col. 20, lines 1-42; col. 21, lines 21-24; col. 25, lines 54-63; col. 26, lines 4-25 of Trivellato teaches that based on the risk profile, performing an action comprising at least one of (i) causing a user interface to update to display a notification indicative of the risk profile (e.g., display the GUI for depicting various information) and (ii) generating and initiating a configuration file to adjust one or more compute resource settings (e.g., the remediation actions such as configured to perform operations for checking compliance status, restrict network access, signal an update system or service, etc.)].
Although, Trivellato teaching generating a risk profile/reporting using the gathered system metric data to the current privacy state requirements associated with the one or more geographic regions/locations, for the compact prosecution purpose, the teaching of Shavlik is added to describe the obviousness of the limitations, generating a risk profile by comparing the received system metric data to current privacy state requirements that are based on organizational privacy setting, wherein the current privacy state requirements comprise geographically specific resourcing requirements associated with the one or more geographic regions [figs. 4-6; par. 0032, lines 1-16; par. 0054, lines 1-20; par. 0058, lines 1-15 of Shavlik teaches generating a risk profile (e.g., profiling) by comparing the received system metric data (e.g., the data of the event logs with locations of the data) to current privacy state requirements (e.g., the physical locations and data security regulation compliance requirements or the security measures and requirements) that are based on organizational privacy setting (e.g., used by the enterprise), wherein the current privacy state requirements comprise geographically specific resourcing requirements associated with the one or more geographic regions (e.g., the locations)].
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Trivellato with the teaching of Shavlik to include the physical locations and data security regulation compliance requirements because it provides an enterprise security assessment and management service that is usable in serverless computing environments - see par. 0006 of Shavlik.
As per claim 2, Trivellato in view of Shavlik teaches the computing system of claim 1.
Trivellato further teaches wherein the system metric data comprises at least one of application metrics, resource utilization metrics, and logging metrics [col. 11, lines 61-67; col. 12, lines 1-11 of Trivellato teaches wherein the system metric data comprises at least one of application metrics, resource utilization metrics, and logging metrics (e.g., information/metric of the operating system, version, patch level, firmware version, model, asset tag, software/application, configured active service, configured ports, MAC address, processor utilization, unique ID, computer name, account access activity, etc.)].
As per claim 3, Trivellato in view of Shavlik teaches the computing system of claim 1.
Trivellato further teaches wherein generating the risk profile comprises: generating mapped log data based on the received system metric data by: obtaining the received system metric data from the one or more privacy agents, wherein the received system metric data comprises one or more annotations; indexing the received system metric data based on the one or more annotations; processing, using one or more privacy data models, the log data; and mapping data by correlating groups of data based on one or more privacy related attributes [figs. 1, 3, 4, 6; col. 2, lines 16-18; col. 12, lines 57-67; col. 16, lines 20-58; col. 20, lines 1-42; col. 21, lines 21-24; col. 23, lines 17-30; col. 25, lines 54-63; col. 26, lines 4-25; col. 28, lines 24-53 of Trivellato teaches generating the risk profile (e.g., the report including an alert, such as indicators of problems and ongoing threats and vulnerabilities, etc. or the risk value, cyber-attack risk, operational failure risk, etc.) comprises: generating mapped log data (e.g., logging or storing the compliance level, etc.) based on the received system metric data (e.g., agent gathered information such as operating system, version, patch level, firmware version, model, asset tag, software/application, configured active service, configured ports, MAC address, processor utilization, unique ID, computer name, account access activity, etc.) by: obtaining the received system metric data from the one or more privacy agents (e.g., the agent), wherein the received system metric data comprises one or more annotations (e.g., the information of the alerts); indexing (e.g., indexing type/category of alerts such as the cyber-attack likelihood, the risk value, cyber-attack risk, operational failure risk, etc.) the received system metric data based on the one or more annotations (e.g., the information of the alerts); processing, using one or more privacy data models (e.g., the PERA model), the log data; and mapping data by correlating groups of data (e.g., see the groups of data in fig. 4) based on one or more privacy related attributes (e.g., the attributes/values used to generate the alerts) – see also rejections to the claim 1].
As per claim 4, Trivellato in view of Shavlik teaches the computing system of claim 1.
Trivellato further teaches wherein the one or more privacy agents are application programming interfaces installed in at least one of (i) a cloud computing environment, (ii) a multi cloud computing environment, and (iii) an on-prem environment [fig. 1; col. 11, lines 39-48 of Trivellato teaches wherein the one or more privacy agents are application programming interfaces installed in at least one of (i) a cloud computing environment, (ii) a multi cloud computing environment, and (iii) an on-prem environment (e.g., the API installed in the cloud computing environment of fig. 1) – see also the rejections to the claim 1].
As per claim 5, Trivellato in view of Shavlik teaches the computing system of claim 1.
Trivellato further teaches wherein the current privacy state requirements are based on data comprising at least one of: onboard sub processors, legal agreements, privacy standards, organizational privacy settings and preferences, explicit lists, and underlying capabilities of one or more systems receiving annotations [col. 20, lines 1-42; col. 21, lines 21-24 of Trivellato teaches wherein the current privacy state requirements (e.g., the expected/approved configuration or the configuration standard) are based on data comprising at least one of: onboard sub processors, legal agreements, privacy standards (e.g., the configuration standard for security risk and/or the operational risk), organizational privacy settings and preferences, explicit lists (e.g., the lists use to indicate the alerts), and underlying capabilities of one or more systems receiving annotations (e.g., the information of the alerts) – see also the rejections to the claims 1 and 3].
As per claim 6, Trivellato in view of Shavlik teaches the computing system of claim 5.
Trivellato further teaches wherein the operations further comprise executing the configuration file to spin up one or more resources in compliance with the privacy state requirements [col. 12, lines 18-25, 50-56; col. 24, lines 26-34; col. 26, lines 4-16 of Trivellato teaches wherein the operations further comprise executing the configuration file (e.g., the instruction according to the policies, etc.) to spin up one or more resources in compliance with the privacy state requirements (e.g., configured to perform the operations including checking compliance status, etc.) – see also the rejections to the claim 1].
As per claim 7, Trivellato in view of Shavlik teaches the computing system of claim 6.
Trivellato further teaches wherein configuration file comprises instructions that when executed by a processor causes spin up of one or more compute resources that comply with the privacy state requirements [col. 12, lines 18-25, 50-56; col. 24, lines 26-34; col. 26, lines 4-16 of Trivellato teaches wherein configuration file comprises instructions that when executed by a processor causes spin up of one or more compute resources (e.g., the requirement or policies indicating compliance requirement) that comply with the privacy state requirements (e.g., configured to perform the operations including checking compliance status, etc.)].
As per claim 8, Trivellato in view of Shavlik teaches the computing system of claim 1.
Trivellato further teaches wherein the operations further comprise executing the configuration file to deploy infrastructure comprising at least one of central processing units, storage, technical support tool, asset inventory, and logging [col. 25, lines 54-63; col. 26, lines 4-25 of Trivellato teaches wherein the operations further comprise executing the configuration file to deploy infrastructure comprising at least one of central processing units, storage (e.g., storing the compliance level), technical support tool (the GUI depicting various information, etc.), asset inventory (e.g., the asset management view), and logging (e.g., logging the compliance level)].
Claims 9-16 are method claims that correspond to the system claims 1-8, and are analyzed and rejected accordingly.
Claims 17-20 are media claims that correspond to the system claims 1-3 and 6, and are analyzed and rejected accordingly.
Conclusion
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 MAUNG T LWIN whose telephone number is (571)270-7845. The examiner can normally be reached on Monday - Friday 10:00 am - 6:00 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, Farid Homayounmehr can be reached on 571-272-3739. 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.
/MAUNG T LWIN/Primary Examiner, Art Unit 2495