DETAILED ACTION
1. Claims 1-4, 6-11, 13-17, 19-23 are pending in this examination.
Notice of Pre-AIA or AIA Status
2.1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2.2. 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.
Response to Arguments
3. Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Claim Rejections - 35 USC § 103
4.1. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
4.2. Claims 1-3, 7-10, 14-16 and 20-23 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 6701342 issued to Bartz et al (“Bartz”) in view of US Patent Application No. 20190294818 to Barday et al (“Barday”), and further in view of US Patent Application No. 20180137465 to Batra et al (“Batra”).
As per claim 1, Bartz discloses a system for controlling and minimizing risk associated with technical controls implemented in a data sensitive system against cyberattack, comprising:
at least one processor; and at least one non-transitory computer-readable medium containing instructions that, when executed by the system, cause the (col. 4, 4-45, he DMS 1 is also capable of obtaining measurement information from various network backbone resources such as, for example, routers 6, and from point-of-presence (POP) resources such as, for example, terminal server 7, router 8 and modem bank 9. The DMS 1 is also capable of collecting measurement data from client premises equipment 10 and 11 (9) The Firehunter monitoring and measurement tools utilize agents to gather measurements associated with the performance, availability and other quality levels of services being provided to customers. Each agent is comprised of (1) tests that determine which measurements the agents should take, and (2) an agent controller that determines which tests the agents are to run, how frequently the agents are to run those tests and where the agents are to send the collected measurements data. There are two types of agents, namely, those that take "active" measurements and those that take "passive" measurements. "Active" measurements create a stimulus in order to measure the response of a service to that stimulus. For example, an agent might emulate a client and interact with the server associated with the client. On the other hand, "passive" measurements monitor log files and system utilities to gather additional information available only at a server. The passive measurements are gathered by using an agent that resides on the machine from which measurements are being obtained. As an agent collects measurement samples, it sends them to the DMS 1 at intervals defined by the service model.);
sending the processed operational data to a [device] (col. 5, lines 1-25, 50-67, The DMS 1 processes the collected measurement data to determine whether resources of the system model are operating properly and, if not, which resources are not operating properly. The views 12, 13 and 14 correspond to views of the service model represented by the resources shown in FIG. 1. These views can be used by a manager of the service to determine whether resources of the service are operating properly, to determine where problems may be occurring in the service and to plan actions to ensure that the service is operating properly (11) As stated above, the quality of service level (QoS) that is to be provided to a given customer is defined by certain terms that are set forth in a service level agreement (SLA) associated with the customer. The QoS measurement data relating to SLAs is stored on a time basis in the DMS 1 database (not shown). The QoS measurement data corresponding to any SLA can be processed by the SLA management tool of the present invention, which is a software tool that preferably resides on the DMS 1. The SLA management tool of the present invention is capable of processing the QoS measurement data and of generating SLA reports that enable the ISP to determine whether or not a particular SLA has been violated, … The SLO 28 characterizes the criteria (e.g., the condition and time specifications) that determine when a measurement violates the SLO 28. Conditions of these criteria will be described below in detail. (14) The condition specification (Condition Spec.) 32 of the SLO 28 corresponds to the condition that a measurement is compared against to determine if the SLO 28 has been violated. Conditions can be defined as static, variable, or variable envelope. Variable conditions are founded on baseline statistics that are collected by the DMS 1 to determine "normal", or historical, behavior for the particular measurement at various times of the day for each day of the week);
(col. 13, lines 10-67, SLAs and SLA reports can be configured by a user using the SLA user interface, such as a GUI 105. The SLAs and reports can be configured by making entries in various menus provided to the user by the SLA GUI 105. Alternatively, the SLAs and SLA reports may be configured by using a text editor to enter the appropriate SLA, SLO, and report information. Similar to a GUI 105, the SLA command line interface 106 may be utilized interactively or by scripts to generate SLA compliance reports. The SLA manager 100 then computes the compliance and outputs the corresponding report with measurement data to a file or to the user interface. The SLA reports may be displayed in a variety of formats (e.g., HTML or comma-separated values) by various tools (e.g., web browsers, spreadsheets, or third-party reporting applications, etc.). SLA Reports can also be stored away to a file for later viewing and processing… The measurement manager 102 and the baseline manager 103 retrieve the information requested by the SLA manager and provide the information to the SLA manager 100. The compliance checker 104 of the SLA manager then utilizes this information to evaluate the SLOs and to perform the SLA expression calculations to determine SLA compliance. The SLO and SLA calculations are stored in the SLA database and are used to generate the SLA reports. All of the measurement data, baseline data, SLO compliance results and SLA compliance results are stored in the SLA database on a time basis. This enables all of this data to be correlated to a single instant in time or a particular period of time. The manner in which the SLOs and the SLAs are calculated by the compliance checker 115 in accordance with the preferred embodiment will now be described in detail with reference to FIGS. 2, 8A and 8B. The first step in the process is to determine the SLA calculation overall reporting period, as indicated by block 121. The reporting period is the period of time over which SLA compliance will be evaluated. The reporting period is then sliced into n number of conformance periods 25 (FIG. 2), as indicated by block 122. The SLA expression is then parsed and the individual tokens associated with the SLO(s) are put into internal tables (not shown), as indicated by block 123. Each SLO is then computed in turn, also see claim 1, also see col. 13, lines 10-50).
Bartz does not explicitly disclose however in the same field of endeavor, Barday discloses technical controls installed in a data sensitive system (abstract),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bartz with the teaching of Barday by including the feature of a data sensitive in order for Bartz’s system to auditing one or more responses to one or more data subject access requests received by a particular entity, according to particular embodiments: (1) one or more computer processors; and (2) computer memory operatively coupled to the one or more processors. In any embodiment described herein, the one or more processes are adapted for: (1) receiving a plurality of data subject access requests via a plurality of webforms on respective computing devices from a plurality of data subject access requestors; (2) automatically determining a type of each data subject access request, the determined type of data subject access request being selected from a group consisting of: (a) a request to delete personal data of the requestor that is being stored by a particular organization; (b) a request to provide, to the requestor, personal data of the requestor that is being stored by the particular organization; (c) a request to update personal data of the requestor that is being stored by the particular organization; and (d) a request to opt out of having the particular organization use the requestor's personal information in one or more particular ways; (3) determining, based at least partially on the determined type of each data subject access request, a workflow that is to be used to process each request; (4) facilitating the processing of each of the plurality of data subject access requests via the workflow; (5) providing a data subject access request compliance portal; (6) receiving an audit request, via the data subject access request compliance portal, to audit compliance, by the particular entity with one or more data subject access request requirements, the audit request comprising one or more request parameters; (7) perform the audit based on the one or more request parameters; (8) generate a report of one or more results of the audit; and (9) provide the report to a privacy officer associated with the particular entity (Barday, [0005]).
Furthermore, Bartz discloses fault detection, and notification as describe above, Bartz and Barday do not explicitly disclose however in the same field of endeavor, Batra discloses processor configured as a node in a blockchain network, wherein the
blockchain network stores a smart contract; sending the processed operational data to the smart contract ([0035], identifying a metric configuration associated with a smart contract stored in a blockchain 512 on a blockchain designated server 520. An auditor may enact an operation that causes the contract to be retrieved 524 to identify the terms 526 and/or metrics 528, such as current operating conditions including any of the supply chain terms described. The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance. Any subsequent actions or contract terms 534…, also see figs. 6b-6c and assocites texts, abstract);
detecting, based on the smart contract and processed operational data, a fault in the operation of one or more technical controls; responsive to detecting fault, sending signals to one or more devices ([0034]-[0035], the contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance. Any subsequent actions or contract terms 534, which, for example, can be identified as being a potential hazard, are noted and included in an additional monitoring operation. An event may be logged 535 from a supply chain member, such as a carrier, custodian, etc. The event may be a change in plans or other event. The event may cause a failure or alert to be created 536. The alert may be transmitted 538 to the blockchain server 520 and the contract member who is registered to receive such alerts may receive a notification of the contract violation 539…, also see fig.5 and associated texts,)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bartz with the teaching of Barday by including the feature of a fault in order for Bartz’s system to verifying the proof of compliance and fulfilled obligations to avoid future disputes. A blockchain configuration may be used to store smart contracts. One example method of operation may include one or more of identifying a metric configuration associated with a smart contract stored in a blockchain, logging an event which is part of the metric configuration, determining whether the event supports requirements of the smart contract, determining whether a smart contract policy in the smart contract matches a system policy, and updating the smart contract on the blockchain when the requirements of the smart contract are supported by the event and the smart contract policy matches the system policy (Batra, abstract).
As per claim 2, the combination of Bartz, Barday and Batra discloses the system of claim 1, wherein the operations further comprise generating the smart contract (Bartz, col. 5, lines 60-67, to col 6, lines 1-25).
As per claim 3, the combination of Bartz, Barday and Batra discloses the system of claim 2, wherein generating the smart contract comprises feeding contract data into one or more of: a machine learning model; or a business rules engine (Bartz, col. 5, lines 1-10, col. 13, lines 10-25, col. 12, lines 63-67).
As per claim 7, the combination of Bartz, Barday and Batra discloses the system of claim 1, wherein the results data comprise one or more of: a status of the smart contract; an operational data expectation; technical controls tracking data; or technical controls statistical data (Bartz, col. 13, lines 36-67).
As per claim 21, the combination of Bartz, Barday and Batra discloses the system of claim 1, wherein processing the operational data comprises one or more of: validating the operational data; performing data sanitization on the operational data; or parsing the operational data (Batra, [0034-[0035], fig. 6 and associated texts). The motivation regarding the obviousness of claim 1 is also applied to claim 21.
Claims 8-10, 14-16 and 20-23 are rejected for similar reasons as stated above.
4.3. Claims 4, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Bartz, Barday and Batra as applied to claim above, and in view of US Patent Application No. 20100114531 to Korn et al (“Korn”).
As per claim 4, the combination of Bartz, Barday and Batra discloses the invention as described above. Bartz, Barday and Batra do not explicitly disclose however, In the same field of endeavor, Korn discloses the system of claim 3, wherein contract data comprises one or more of: a contract; a template; a first library, wherein the first library contains a mapping of a set of operational data expectations to one or more products and services capable of satisfying the set of operational data expectations and a mapping of the set of operational data expectations to one or more frameworks; or a second library, wherein the second library contains acceptable operational data values for a set of operational data expectations.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bartz with the teaching of Korn/ Batra/ Barday by including the feature of expectations, in order for Bartz’s system to identifying occurrence of an SLA violation in a computing system that is providing services under the SLA. A technique for evaluating service level agreement (SLA) violations occurring in a computing system with agreed-upon model for exemptions is provided. The technique includes storing in a memory a model of the SLA and identifying occurrence of an SLA violation in a computing system that is providing services under the SLA. Based on the stored model, the technique further determines if the SLA violation is exempted from a penalty (Korn, abstract).
Claims 11 and 17, are rejected for similar reasons as stated above.
4.4. Claims 6, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bartz, Barday and Batra as applied to claim above, and in view of US Patent Application No. 20150312215 to Kher et al (“Kher”).
As per claim 6, the combination of Bartz, Barday and Batra discloses the invention as described above. Bartz, Barday and Batra do not explicitly disclose however, In the same field of endeavor, Kher discloses the system of claim 1, wherein the second signals comprise instructions to the one or more devices to perform one or more of: instructing an owner device to automatically adjust a bill to the provider; sending a notification to a provider device detailing the fault; instructing an insurer device to automatically adjust pricing and availability of insurance based on the detected fault or the results data; notifying an owner device of the adjustment; or notifying a vendor device of the adjustment (Kher, [0100]-[0104]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bartz with the teaching of Kher/ Batra/ Barday by including the feature of adjustment, in order for Bartz’s system to convert the request into network technical requirements that may specify needs such as, but not limited to, a specific network bandwidth, a minimized network cost, a minimized operator cost, a minimized total delay, an optimized bandwidth, an optimized reliability, a maximized end-to-end throughput, a guaranteed minimum average bandwidth, a maximum transmission delay or some combination thereof (Kher,[0016]).
Claims 13 and 19, are rejected for similar reasons as stated above.
5.1. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure as the prior art discloses many of the claim features (See PTO-form 892).
5.2. a). US Patent Application No. 20180124080 to Christodorescu et al., discloses various embodiments include methods of protecting a computing device within a network from malware or other non-benign behaviors. A computing device may monitor inputs and outputs to a server, derive a functional specification from the monitored inputs and outputs, and use the functional specification for anomaly detection. Use of the derived functional specification for anomaly detection may include determining whether a behavior, activity, web application, process or software application program is non-benign. The computing device may be the server, and the functional specification may be used to determine whether the server is under attack. In some embodiments, the computing device may constrain the functional specification with a generic constraint, detect a new input-output pair, determine whether the detected input-output pair satisfies the constrained functional specification, and determine that the detected input-output pair is anomalous upon determining that the detected input-output pair (or request-response pair) satisfies the constrained functional specification.
Conclusion
6. 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 HARUNUR RASHID whose telephone number is (571)270-7195. The examiner can normally be reached 9 AM to 5PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
HARUNUR . RASHID
Primary Examiner
Art Unit 2497
/HARUNUR RASHID/Primary Examiner, Art Unit 2497