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 Application No. 18/899,421 filed on 09/27/2024.
Claims 1-20 have been examined and are pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 10/14/2024, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
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.
Claim(s) 1-2, 4-5, 8-9, 11-12, 15-16, and 18-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Rungta et al. (US 2019/0278928; Hereinafter “Rungta”).
Regarding claim 1, Rungta teaches a method comprising:
obtaining, from a template machine executing on a computing environment, a template machine configuration setting comprising a security rule with a template machine rule value (Rungta: Para. [0047], A template creation API may enable the client to submit or program one or more templates 114 comprising virtual computing resource definitions and other parameters that the resource allocation system 120, and/or other systems of the computing resource service provider 199, use to allocate, configure, and deploy virtual computing resource instances into the virtual computing environment 100. [client submitting one or more templates comprising virtual computing resource definitions meets template machine executing on a computing environment limitation; security model, information in the relevant templates and security policies meets security rule with a template rule value limitation] Para. [0071], One or more definitions 302, 304, 306 may be included in the template, and each may provide parameters to be included in the configuration of resources created and/or launched from the template 300. Para. [0039], The security assessment system 106, based on the security model 190, information in the relevant template(s) 114 and security policy (or policies) 116, and the results of security assessments performed on user data, determines whether the proposed configuration of a requested virtual resource 142 satisfies client-provided security requirements before and after provisioning and deployment of the virtual resource 142.);
customizing, by a processing device, a benchmark security configuration based on the template machine rule value to produce a customized security configuration (Rungta: Para. [0040], In one embodiment, the security model 190 may be a “master” security model that describes all checks the security assessment system 106 can perform, and the instructions 194 or a separately stored data structure for each client account may identify the desired checks and user parameter/value pairs for the associated client. In another embodiment, a unique security model 190 containing the customer-specific information (i.e., checks selected by the client; user values submitted by the client) may be created and stored for each client account. Para. [0020], Para. [0041], The resource check record 192A may additionally contain one or more parameters having stored values that are provided by the client (e.g., via the administrator interface 108); these parameter/value pairs can be used by the security assessment system 106 while performing the check, in order to customize performance of the check for certain target virtual resources and/or end user accounts. For example, if the check of the resource check record 192A tests whether unsecure ports into a virtual machine instance are open, the user-provided values may identify certain port numbers that do or do not need to be checked. Para. [0046]); and
utilizing the customized security configuration, performing a configuration assessment of a computing machine executing in the computing environment to test a compliance of the computing machine (Rungta: Para. [0094], At step 410, the system may perform the security assessment, which identifies any parameter or other aspect of the proposed configuration and security policy of the virtual resource instance that violates a predetermined security requirement. If all of the security requirements are met (e.g., security checks are passed), the system can continue the deployment process by proceeding to step 420.).
Regarding claim 2, Rungta teaches the method of claim 1, wherein the benchmark security configuration comprises the security rule with a benchmark rule value, the customizing further comprising:
determining that the template machine rule value is not equal to the benchmark rule value (Rungta: Para. [0085], Conditions may, furthermore, include quantifiers. For example, a string condition may include an operator such as “StringEquals” that compares whether two strings are equal, and a similar operator may include a quantifier such that “StringEqualsIfExists” may be used to compare two strings when the key value exists in the context of an evaluation. Para. [0020], Such evaluation may include comparing configuration parameters of the instance to a set of evaluation parameters embodying a proper configuration, such as a “security best practices” configuration.); and
updating the security rule with the template machine rule value in response to determining that the template machine rule value is not equal to the benchmark rule value (Rungta: Para. [0082], As a second example, an action element described as “Action”: “iam:*AccessKey*” may refer to actions supported by an identity and access management service in connection with access keys of a service—illustrative examples may include actions related to creating an access key (e.g., a “CreateAccessKey” action may exist), deleting an access key (e.g., “DeleteAccessKey”), listing access keys (e.g., “ListAccessKeys”), and updating an existing access key (e.g., “UpdateAccessKey”). Para. [0050], A security settings API may enable the client to add parameters, change values for existing parameters, and otherwise modify configurations of the virtual computing environment 100 and corresponding virtual networks and virtual computing resources, in order to change or improve those aspects of the configurations that interact with security policies 112 or otherwise affect the security of the client's resources and data. For example, the client may be able to add, remove, or modify access control lists, authorized user profiles, security groups, and the like. [access key value may update when condition in permission is evaluated and determined to be false]).
Regarding claim 4, Rungta teaches the method of claim 2, further comprising:
obtaining computing machine configuration settings corresponding to the computing machine (Rungta: Para. [0033], The client may further input other configuration settings that the system may later use to perform security assessments of virtual computing resources in accordance with the present disclosure.), wherein the computing machine configuration settings comprise the security rule with a computing machine rule value (Rungta: Para. [0065], A security model 254 may include the model 190 of FIG.1 or its discrete components such as the various defined security checks and instructions for performing the checks, as well as additional information related to the security model. User data 256 may include user account data, user profile information, user-submitted and/or derived user preferences, user-submitted configuration settings, results from previous security assessments related to the user or user account, and the like. For example, the user data 256 may identify a subset of the checks defined in the security model 254, which the user wants performed on one or more types of virtual resources available for deployment in the network-accessible services system 210. Para. [0060], For example, a system administrator may use a setting represented in a user interface to increase the capacity (i.e., the maximum number of instances) in the active pool 240 during peak hours. In some embodiments, virtual machine instances in the active pool 240 can be configured based on a predetermined set of configurations, such as virtual machine images that incorporate settings pertaining to the tiered limits. The predetermined set of configurations can correspond to various types of virtual machine instances; for example, the active pool 240 can be configured to hold up to the limit of each type of virtual machine instance. The active pool manager can optimize types and numbers of virtual machine instances in the active pool 240 based on one or more metrics related to current or previous launch requests.); and
determining whether the computing machine rule value violates the security rule based on the template machine rule value (Rungta: Para. [0051], to determine validity, the security assessment system 106 may simply retrieve the security assessment results from the user data store 180 and make the comparison to a stored threshold. In other embodiments, the validity comparison may be made in advance and the security assessment system 106 may retrieve the results of the comparison. In still other embodiments, the security assessment system 106 may send the security assessment result(s) to the corresponding resource allocation system 120, or another service, within a computing environment 100, which service may then make the comparison to the stored threshold(s). Para. [0066]).
Regarding claim 5, Rungta teaches the method of claim 4, further comprising: in response to determining that the computing machine rule value violates the security rule based on the template machine rule value, sending a notification indicating that the computing machine is in non-compliance of the customized security configuration (Rungta: Para. [0098], At step 448, the system may create a notification containing any of the information obtained regarding the failure of the configuration and/or security policy to pass the security checks, and at step 450 the system may deliver the notification to the client user, such as by storing the notification in a usage log or sending an email, push notification, or other alert containing the notification to a client user device. Subsequently, the client user may access the system (e.g., via the administrator user interface) and correct the errors reported in the notification.).
Regarding claims 8-9, Claims 8-9 are rejected under the same rational as claims 1-2, respectively.
Regarding claims 11-12, Claims 11-12 are rejected under the same rational as claims 4-5, respectively.
Regarding claims 15-16, Claims 15-16 are rejected under the same rational as claims 1-2, respectively.
Regarding claims 18-19, Claims 18-19 are rejected under the same rational as claims 4-5, respectively.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claim(s) 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rungta et al. (US 2019/0278928; Hereinafter “Rungta”) in view of Aravamudan et al. (US 2025/0391523; Hereinafter “Aravamudan”).
Regarding claim 6, Rungta teaches the method of claim 1, wherein the benchmark security configuration comprises the security rule with a benchmark rule value. Rungta does not explicitly teach the method further comprising: determining whether the security rule comprises an ambiguous rule value parameter that corresponds to more than one set of allowable contiguous values; and inhibiting the benchmark rule value from being updated in response to determining that the security rule comprises the ambiguous rule value parameter.
In an analogous art, Aravamudan teaches the method further comprising: determining whether the security rule comprises an ambiguous rule value parameter that corresponds to more than one set of allowable contiguous values (Aravamudan: Para. [0114], With continued reference to FIG. 2, as a non-limiting example, a private data element e.g., a sequence of social security numbers associated with a customer within database 212 may be replaced, by secure tokenization module, with a series of “X's” or a random set of numbers, effectively obscuring the private data element. Further, secure tokenization module may be configured to add a pre-defined amount of random noise to plurality of private data elements 216 through noise addition or differential privacy as described in further detail below. As a non-limiting example, plurality of private data elements 216 may be altered while overall statistical properties of the database 212 may be maintained. Secure tokenization module may add a random value, for example, and without limitation, within a range of −2 or +2 years to each age entry within database 212. Para. [0123], With continued reference to FIG. 2, as a non-limiting example, a distance measure between an obfuscated “age” attribute of 34 years and an original “age” attribute of 30 years may be 4 years (in this case, the distance measure may be an absolute difference). For obfuscation process, as described in further detail below, processor 204 may determine that any first distance measure of at least 3 years may be sufficient to obscure the original age. [separate continuous values may include a value X, a value X ≥ |
±
3
|] Para. [0119]); and
inhibiting the benchmark rule value from being updated in response to determining that the security rule comprises the ambiguous rule value parameter (Aravamudan: Para. [0129], In some cases, deidentification parameter 244 may include specific rule or thresholds for altering data, such as, without limitation, level of generalization, suppression noise addition required, privacy protection level, and/or the like. As a non-limiting example, deidentification parameter may specify all private data elements associated with direct identifiers (e.g., names, SSN, and the like) within plurality of private data elements 224 be removed and all private data elements associated with quasi-identifiers (e.g., zip codes, dates of birth, and the like) within plurality of private data elements 224 be aggregated or partially suppressed. An “obfuscation parameter,” for the purpose of this disclosure, is a degree or manner in which private data elements are transformed or disguised to conceal its original state. In one embodiment, obfuscation parameter 248 may determine one or more maximum allowable changes to private data element to maintain the desired utility for its intended application subsequent to the obfuscation as described herein. In some cases, obfuscation parameter 248 may include a specification or an implementation of obfuscation algorithms to be applied (e.g., data masking, pseudonymization, synthetic data generation, and/or the like) and the extent to which these algorithms should alter plurality of private data elements 224. [deidentification parameter and obfuscation parameters may include thresholds or limits for distance measures that determine maximum allowable changes to data elements in order to maintain utility])
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Aravamudan with the system and method of Rungta to include the method further comprising: determining whether the security rule comprises an ambiguous rule value parameter that corresponds to more than one set of allowable contiguous values; and inhibiting the benchmark rule value from being updated in response to determining that the security rule comprises the ambiguous rule value parameter because this functionality provides specific obfuscation parameters that create thresholds for determining maximum and minimum allowable changes to data elements in order to maintain utility (Aravamudan: Para. [0129]).
Regarding claim 13, Claim 13 is rejected under the same rational as claim 6.
Regarding claim 20, Claim 20 is rejected under the same rational as claim 6.
Claim(s) 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Rungta et al. (US 2019/0278928; Hereinafter “Rungta”) in view of Rao et al. (US 2024/0256677; Hereinafter “Rao”).
Regarding claim 3, Rungta teaches the method of claim 2. Rungta does not explicitly teach further comprising: adding a visual indicator to the security rule in response to the updating; and displaying the customized security configuration with the security rule and the visual indicator on a display.
In an analogous art, Rao teaches further comprising: adding a visual indicator to the security rule in response to the updating (Rao: Para. [0085], Upon a user selection of a computing aspect impact level representation 708a-b, an updated user interface may be presented to the user that may include additional information not shown in FIG. 7, such as, but not limited to, the computing aspect impact level (e.g., as a quantitative or qualitative value), one or more security vulnerabilities associated with the selected computing aspect impact level representation, one or more computing components or software components associated with the platform that is further associated with the computing aspect impact level (e.g., an indication of the software/hardware components causing the computing aspect impact level to be determined as is), security vulnerability details (e.g., type of vulnerability, attack vector of the vulnerability, date of discovery, system-provided comments related to the security vulnerability, assessment stage, etc.), inherent risks associated with the computing aspect impact level representation, residual risks associated with the computing aspect impact level representation, mitigation measures associated with the computing aspect, or other information that may be associated with the selected graphical element.); and displaying the customized security configuration with the security rule and the visual indicator on a display (Rao: Para. [0086], Upon determining which computing aspects are high-impact computing aspects, process 600 can then update the graphical layout to only include a graphical representation of each high-impact computing aspects of the set of high-impact computing aspects and a graphical representation of the respective high-impact computing aspect impact level. Para. [0086], In some implementations, process 600 can update the graphical layout to include high-impact computing-aspect-specific impact levels. For example, to improve the user experience, process 600 can update the graphical layout to include a graphical representation of high-impact computing aspects of the set of computing aspect impact levels.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Rao with the system and method of Rungta to include further comprising: adding a visual indicator to the security rule in response to the updating; and displaying the customized security configuration with the security rule and the visual indicator on a display because this functionality provides updating of a graphical interface with high impact computer security aspects to enable a user to quickly identify which aspects are most impacted by security vulnerabilities (Rao: Para. [0086]).
Regarding claim 10, Claim 10 is rejected under the same rational as claim 3.
Regarding claim 17, Claim 17 is rejected under the same rational as claim 3.
Allowable Subject Matter
Regarding Claims 7 and 14, Claims 7 and 14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims including dependent claims 6 and 13.
The following is an Examiner’s statement of reasons for allowance:
The closest prior art includes Rungta et al. (US 2019/0278928; Hereinafter “Rungta”) in view of Aravamudan et al. (US 2025/0391523; Hereinafter “Aravamudan”) in view of Rao et al. (US 2024/0256677; Hereinafter “Rao”). However, none of Rungta, Aravamudan, and Rao, teaches or suggests, alone or in combination, the particular combination of steps or elements as recited in dependent claims 7 and 14. For example, none of the cited prior art teaches or suggest the steps of “adding a visual indicator to the security rule in response to determining that the security rule comprises the ambiguous rule value parameter; and displaying the customized security configuration with the security rule and the visual indicator on a display.” As a result, the claims are allowable over the cited prior art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Application Publication No. US 2016/0352780 by Lang et al.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Nelson Giddins whose telephone number is (571)272-7993. The examiner can normally be reached on Monday - Friday, 9:00 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached at (571) 270-5440. 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.
/NELSON S. GIDDINS/ Primary Examiner, Art Unit 2437
Prosecution Insights