DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,363,154. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 1 is generic to all that is recited in claim 1 of U.S. Patent No. 12,363,154. That is, claim 1 of U.S. Patent No. 12,363,154 falls entirely within the scope of claim 1 or, in other words, claim 1 is anticipated by claim 1 of U.S. Patent No. 12,363,154.
Specifically, claim 1 of U.S. Patent No. 12,363,154 recites A computer-implemented method comprising (“A computer-implemented method comprising”):
executing, by an information technology (IT) and security operations application, a playbook built with a playbook editor that allows configuring of function blocks with an interface that comprises a playbook canvas that allows addition and interrelation of the function blocks to define a series of operations to be performed responsive to identification of an incident in an IT environment, wherein each function block of the function blocks corresponds to computer program source code that is executed upon encountering the function block during execution of the playbook (“executing, by an information technology (IT) and security operations application, a playbook including a plurality of function blocks, wherein the plurality of function blocks collectively defines a series of operations to be performed responsive to identification of an incident in an IT environment, wherein each function block of the plurality of function blocks includes computer program source code that is executed upon encountering the function block during execution of the playbook, and wherein the plurality of function blocks includes a custom code function block that includes source code provided by a user of the IT and security operations application”);
monitoring, by the IT and security operations application, execution of each of the function blocks to obtain a plurality of playbook run statistics for the playbook (“monitoring, by the IT and security operations application, execution of each of the plurality of function blocks to obtain a plurality of playbook run statistics for the playbook”); and
causing display of a report with the playbook editor indicating the plurality of playbook run statistics (“causing display of a report indicating the plurality of playbook run statistics”).
Similarly, the following claims are rejected on the ground of nonstatutory double patenting as being unpatentable over the following corresponding claims of U.S. Patent No. 12,363,154.
Claims of the Instant Application
Claims of U.S. Patent No. 12,363,154
Claims of the Instant Application
Claims of U.S. Patent No. 12,363,154
1
1
11
11
2
2
12
12
3
3
13
13
4
4
14
14
5
5
15
15
6
6
16
16
7
7
17
17
8
8
18
18
9
9
19
19
10
10
20
5
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 5, 9, 11, 15, 16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bienkowski (US 9,336,115), and further in view of Drake (US 10,795,649).
Regarding claims 1, 11 and 16, Bienkowski teaches A computer-implemented method comprising:
executing, by an information technology (IT) (a technical computing environment (TCE) 220, see Fig. 2 and col. 2, lines 42-43), a playbook built with a playbook editor that allows configuring of function blocks with an interface that comprises a playbook canvas that allows addition (see col. 3, lines 13-16: “TCE 220 may include, for example, a user interface that provides a code editor portion that permits a user to input program code (e.g., textual program code, graphical program code, etc.)”. And see col. 5, line 66-col. 6, line 10: “The execution parameter may include a partition parameter that specifies a manner in which the program code is to be partitioned, in some implementations. For example, client device 210 may partition the program code into different portions. A portion of program code (sometimes referred to herein as a program code portion) may refer to a portion of a program, such as one or more lines of program code, a string of one or more characters of program code, a set of strings of program code, a block of program code, a function, a method, a script, an object, or the like. The partition parameter may specify a level at which the program code is to be partitioned, such as a line level, a function level, a block level, etc.”. And see col. 9, lines 58-60 and Fig. 5B: “assume that the user … selects to partition the program code at the block/function level”. And see col. 12, lines 56-60 and Fig. 7B: “Assume that the user has input an option to partition code at the function level, and thus the program code included in the Func function is included in a single program code partition, as shown by reference number 715.” And see col. 13, lines 25-42 and Fig. 7F: “As shown in FIG. 7E, assume that client device 210 finishes executing the first six partitions (e.g., up through H2i=inv(vpa(H2))). … As shown by reference number 750, assume that client device 210 is currently executing a seventh partition, shown as Func(x, y). As shown in FIG. 7F, and by reference number 755, assume that client device 210 finishes executing the seventh partition”. And see col. 14, lines 24-26 and Fig. 7B: “As shown by reference number 820, the function Func(x, y) includes three lines of program code, shown as z=x+y, z=z*z, and disp(z).” The Examiner interprets the function Func(x, y) including three lines of program code as wherein each function block of the function blocks corresponds to computer program source code that is executed upon encountering the function block during execution of the playbook. The Examiner interprets the seven code partitions including Func(x, y) (a function block) in the code editor of the technical computing environment (TCE) 220 shown in Fig. 7F as a playbook built with a playbook editor that allows configuring of function blocks with an interface that comprises a playbook canvas that allows addition );
monitoring, by the IT (see col. 11, lines 46-50 and Fig. 6: “As further shown in FIG. 6, process 600 may include generating a performance characteristic associated with executing the program code portion (block 650). For example, client device 210 may generate and/or measure a performance characteristic based on executing the program code portion.” And see col. 7, lines 13-31: “A performance characteristic may include, …an amount of time that client device 210 takes to execute a program code portion (e.g., an amount of time between when client device 210 begins executing the code portion and when client device 210 finishes executing the code portion), an amount of computing resources consumed by client device 210 while executing a program code portion (e.g., an amount of processing power, an amount of memory, an amount of disk space, a quantity of processor cores used, etc.), or the like.” And see col. 13, lines 25-44 and Fig. 7F reproduced below: “As shown in FIG. 7E, assume that client device 210 finishes executing the first six partitions (e.g., up through H2i=inv(vpa(H2))). … Furthermore, client device 210 measures and displays performance characteristics for each partition, … As shown by reference number 750, assume that client device 210 is currently executing a seventh partition, shown as Func(x, y). As shown in FIG. 7F, and by reference number 755, assume that client device 210 finishes executing the seventh partition, and then generates and displays performance characteristics associated with the seventh partition.”
PNG
media_image1.png
671
922
media_image1.png
Greyscale
The Examiner interprets performance characteristics associated with the seven code partitions taught by Bienkowski, wherein a performance characteristic may include an amount of time that client device 210 takes to execute a program code portion and an amount of computing resources consumed by client device 210 while executing a program code portion, as a plurality of playbook run statistics for the playbook. The Examiner interprets measuring performance characteristics associated with the seven code partitions taught by Bienkowski as monitoring, by the IT ); and
causing display of a report with the playbook editor indicating the plurality of playbook run statistics (see col. 13, lines 25-44 and Fig. 7F reproduced below: “As shown in FIG. 7E, assume that client device 210 finishes executing the first six partitions (e.g., up through H2i=inv(vpa(H2))). … Furthermore, client device 210 measures and displays performance characteristics for each partition, … As shown by reference number 750, assume that client device 210 is currently executing a seventh partition, shown as Func(x, y). As shown in FIG. 7F, and by reference number 755, assume that client device 210 finishes executing the seventh partition, and then generates and displays performance characteristics associated with the seventh partition.”).
Bienkowski differs from claims 1, 11 and 16 in that it fails to teach that the application executing the playbook is also a security operations application. Bienkowski also fails to teach that the playbook is performed responsive to identification of an incident in an IT environment.
However, Drake discloses executing, by an information technology (IT) and security operations application (see col. 6, lines 7-12: “An OAR platform generally enables users to connect disparate collections of security and IT applications in users' IT environments and to automate tasks typically performed manually by system administrators and other users in response to identification of various types of IT-related incidents.”), a playbook (see Abstract: “Techniques are described for enabling users to add custom code function blocks and multi-prompt blocks to customizable playbooks that can be executed by an orchestration, automation, and response (OAR) platform.”). Drake further teaches that the playbook is to be performed responsive to identification of an incident in an IT environment (see col. 1, lines 16-20: “the creation of digital playbooks used to automate operations performed at disparate information technology (IT) related assets and related to incidents within a computing environment”).
Both Bienkowski and Drake teach a playbook comprising function blocks defining a series of operations to be performed. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let the playbook of Bienkowski be a playbook executed by an information technology (IT) and security operations application responsive to identification of an incident in an IT environment, as taught by Drake. It would have been obvious because monitoring and displaying a plurality of playbook run statistics is in no way dependent on what the playbook does, and the playbook could be performed in response to identification of an incident in an IT environment to achieve the predictable results of gaining insight into the execution of the security playbook by displaying a plurality of security playbook run statistics.
Additionally, Bienkowski differs from claims 1, 11 and 16 in that it fails to teach that the playbook canvas allows interrelation of the function blocks.
Drake discloses a playbook built with a playbook editor that allows configuring of function blocks with an interface that comprises a playbook canvas that allows addition and interrelation of the function blocks to define a series of operations to be performed responsive to identification of an incident in an IT environment (see col. 11, lines 41-55: “As illustrated in FIG. 3, a visual playbook editor interface 300 includes a playbook canvas 302 initially including two nodes corresponding to a start block 304 and an end block 306, respectively, where those nodes represent a start and end point for execution of the playbook being designed. In the illustrated example, the visual playbook editor interface 300 further displays an example dialog box 308 instructing a user to select the start block 304 and to create an edge or connection originating from the start block 304 to add a new block to the playbook. As described in more detail below, the visual playbook editor interface 300 enables users to add various types of blocks to a playbook including, for example, playbook blocks, decision blocks, filter blocks, action blocks, format blocks, prompt blocks, task blocks, and API blocks.”).
Both Bienkowski and Drake teach building a playbook using function blocks. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the playbook canvas of Bienkowski by letting it allow interrelation of the function blocks as taught by Drake. It would have been obvious because Drake teaches the following benefit of a playbook canvas that allows addition and interrelation of the function blocks: “the OAR platform 102 displays a visual playbook editor interface including a graphical canvas on which users can add nodes representing operations to be performed during execution of the playbook, where the operations are implemented by associated source code that can be automatically generated by the visual playbook editor, and connections or edges among the nodes defining an order in which the represented operations are performed upon execution.” (col. 11, lines 31-39).
Regarding claims 5, 15 and 20, Bienkowski further teaches receiving input requesting to enable generation of the plurality of playbook run statistics for the playbook; adding, by the IT and security operations application, source code to the playbook used to generate the plurality of playbook run statistics; and wherein monitoring execution of each of the function blocks includes executing the source code used to generate the plurality of playbook run statistics (sed Col. 1, lines 64-67 and Fig. 1A: “assume that the user interacts with an input mechanism, shown as an “Evaluate Code Performance” menu item, to cause the client device to perform a live evaluation of program code performance”. And see col. 5, lines 17-27: “As shown in FIG. 4, process 400 may include receiving an indication to evaluate performance of program code execution (block 410). For example, client device 210 may receive (e.g., via user input and/or input from another device) an indication to evaluate performance of program code execution. In some implementations, a user may interact with a user interface, provided via TCE 220 executing on client device 210, to provide input to evaluate performance of program code execution. In some implementations, the user may provide input to toggle between evaluating performance and executing program code without evaluating performance.”).
Regarding claim 9, Bienkowski further teaches wherein monitoring execution of each of the function blocks to obtain a plurality of playbook run statistics for the playbook includes:
collecting, based on execution of source code included in the playbook, first playbook run statistics (see col. 13, lines 25-44 and Fig. 7F reproduced above: “As shown in FIG. 7E, assume that client device 210 finishes executing the first six partitions (e.g., up through H2i=inv(vpa(H2))). … Furthermore, client device 210 measures and displays performance characteristics for each partition);
collecting, based on operation of a playbook execution engine executing the playbook, second playbook run statistics (see col. 13, lines 25-44 and Fig. 7F reproduced above: “As shown in FIG. 7F, and by reference number 755, assume that client device 210 finishes executing the seventh partition, and then generates and displays performance characteristics associated with the seventh partition”); and
storing the first playbook run statistics and the second playbook run statistics in a database (see col. 13, lines 44-49 and Fig. 7F reproduced above: “As shown by reference number 760, after client device 210 has finished executing all partitions, client device 210 may compare performance characteristics associated with the different partitions, and may provide an indication of a partition that that took the longest time to execute, that consumed the most resources, etc.”).
Claims 2, 12 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Bienkowski (US 9,336,115), further in view of Drake (US 10,795,649), and further in view of Wilms (US 2005/0187991).
Regarding claims 2, 12 and 17, Bienkowski further teach wherein the plurality of playbook run statistics includes block-specific statistics for a function block of the function blocks (see col. 13, lines 25-44 and Fig. 7F reproduced below: “As shown in FIG. 7E, assume that client device 210 finishes executing the first six partitions (e.g., up through H2i=inv(vpa(H2))). … Furthermore, client device 210 measures and displays performance characteristics for each partition, … As shown by reference number 750, assume that client device 210 is currently executing a seventh partition, shown as Func(x, y). As shown in FIG. 7F, and by reference number 755, assume that client device 210 finishes executing the seventh partition, and then generates and displays performance characteristics associated with the seventh partition.”).
Bienkowski modified in view of Drake fails to teach wherein the block-specific statistics include at least one of: a number of database queries executed by the function block, an average latency of the database queries executed by the function block, a number of bytes transmitted via Hypertext Transfer Protocol (HTTP) requests sent by the function block, a number of bytes transmitted via HTTP requests received by the function block, an average amount of time between HTTP requests sent by the function block and corresponding HTTP requests received by the function block, a number of HTTP requests sent by the function block, a number of times the function block is executed, a number of times the function block completed successfully, or a number of times the function block failed.
However, Wilms discloses wherein the block-specific statistics include at least one of: a number of database queries executed by the function block, an average latency of the database queries executed by the function block, a number of bytes transmitted via Hypertext Transfer Protocol (HTTP) requests sent by the function block, a number of bytes transmitted via HTTP requests received by the function block, an average amount of time between HTTP requests sent by the function block and corresponding HTTP requests received by the function block, a number of HTTP requests sent by the function block, a number of times the function block is executed, a number of times the function block completed successfully, or a number of times the function block failed (see [0032] If archived ETL task status table is queried directly, additional reports to aid in monitoring and auditing ETL tasks are generated. Examples of queries that are performed against the accumulated ETL task execution statuses in archived warehouse metadata which is not easily, if at all, discernable from a query of operational metadata comprise: … steps requiring a retry and number of retries necessary to achieve status at completion”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let the block-specific statistics taught by Bienkowski modified in view of Drake include at least one of: a number of database queries executed by the function block, an average latency of the database queries executed by the function block, a number of bytes transmitted via Hypertext Transfer Protocol (HTTP) requests sent by the function block, a number of bytes transmitted via HTTP requests received by the function block, an average amount of time between HTTP requests sent by the function block and corresponding HTTP requests received by the function block, a number of HTTP requests sent by the function block, a number of times the function block is executed, a number of times the function block completed successfully, or a number of times the function block failed, as taught by Wilms. It would have been obvious because a person of ordinary skill has good reason to pursue the known options within his or her technical grasp.
Claims 3, 4, 6, 13, 14, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bienkowski (US 9,336,115), further in view of Drake (US 10,795,649), and further in view of Krauss (US 8,271,959).
Regarding claims 3, 13 and 18, Bienkowski further teach wherein executing the playbook is a first run of the playbook.
Bienkowski modified in view of Drake fails to teach wherein the method further comprises: executing, by the IT and security operations application, a plurality of runs of the playbook including the first run; obtaining playbook run statistics for each run of the plurality of runs of the playbook; and wherein the report includes an average of one or more of the playbook run statistics for the plurality of runs.
In the same field of endeavor, Krauss discloses wherein the method further comprises: executing, by the IT (see col. 5, lines 34-47: “Typically execution data for a function of the CPUT 140 is collected and presented in the aggregate. That is, the execution data collected from each execution of a selected function is aggregated with execution data from prior executions of the function. Conventional analysis tools do not evaluate each execution of a function so as to be able to identify particular function executions that exhibit abnormal or varying execution behavior. In other words, providing aggregated execution data reflecting all executions of a function during operation of the instrumented CPUT does not indicate that, in some cases, the function performed well, while in other cases the function performed poorly. Instead, one may only look to averages, e.g., the total runtime of the function required "X" cycles for "Y" executions or calls.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Bienkowski modified in view of Drake by letting the method further comprise: executing, by the IT … application, a plurality of runs of the playbook including the first run; obtaining playbook run statistics for each run of the plurality of runs of the playbook; and wherein the report includes an average of one or more of the playbook run statistics for the plurality of runs, as disclosed by Krauss. It would have been obvious because doing so predictably achieves the commonly understood benefit of eliminating noises in playbook run statistics. When Bienkowski is modified in view of Drake and Krauss as described above, it would teach wherein the method further comprises: executing, by the IT and security operations application, a plurality of runs of the playbook including the first run; obtaining playbook run statistics for each run of the plurality of runs of the playbook; and wherein the report includes an average of one or more of the playbook run statistics for the plurality of runs.
Regarding claims 4, 14 and 19, Bienkowski further teach wherein executing the playbook is a first run of the playbook, wherein the playbook run statistics are first playbook run statistics associated with the first run of the playbook.
Bienkowski modified in view of Drake fails to teach wherein the method further comprises: executing, by the IT and security operations application, a plurality of runs of the playbook; obtaining playbook run statistics for each run of the plurality of runs of the playbook; and wherein the report displays the first playbook run statistics and an average of one or more of the playbook run statistics for the plurality of runs of the playbook.
In the same field of endeavor, Krauss discloses wherein the method further comprises: executing, by the IT displays (see col. 5, lines 34-47: “Typically execution data for a function of the CPUT 140 is collected and presented in the aggregate. That is, the execution data collected from each execution of a selected function is aggregated with execution data from prior executions of the function. Conventional analysis tools do not evaluate each execution of a function so as to be able to identify particular function executions that exhibit abnormal or varying execution behavior. In other words, providing aggregated execution data reflecting all executions of a function during operation of the instrumented CPUT does not indicate that, in some cases, the function performed well, while in other cases the function performed poorly. Instead, one may only look to averages, e.g., the total runtime of the function required "X" cycles for "Y" executions or calls.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Bienkowski modified in view of Drake by letting the method further comprise: executing, by the IT … application, a plurality of runs of the playbook including the first run; obtaining playbook run statistics for each run of the plurality of runs of the playbook; and wherein the report displays … an average of one or more of the playbook run statistics for the plurality of runs of the playbook, as disclosed by Krauss. It would have been obvious because doing so predictably achieves the commonly understood benefit of eliminating noises in playbook run statistics. When Bienkowski is modified in view of Drake and Krauss as described above, it would teach wherein the method further comprises: executing, by the IT and security operations application, a plurality of runs of the playbook; obtaining playbook run statistics for each run of the plurality of runs of the playbook; and wherein the report displays the first playbook run statistics and an average of one or more of the playbook run statistics for the plurality of runs of the playbook.
Regarding claim 6, Bienkowski modified in view of Drake fails to teach receiving, via the report, selection of a function block of the function blocks; and displaying playbook run statistics specific to the function block.
In the same field of endeavor, Krauss discloses receiving, via the report, selection of a function block of the plurality of function blocks; and displaying playbook run statistics specific to the function block (see col. 13, lines 36-38: “the call graph 800 includes two nodes 805 and 810 representing different executions of the function baz3( ).” And see col. 13, lines 58-65: “Execution information for the call graph 800 can be displayed in a variety of different ways. Such information can be displayed, for example, within the nodes themselves, within pop-up style windows or balloons that can be displayed responsive to a pointer hovering over or selecting a node, or within a different window that dynamically changes the information displayed as the user selects different nodes of the call graph.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Bienkowski modified in view of Drake by adding the step of receiving, via the report, selection of a function block of the function blocks; and displaying playbook run statistics specific to the function block, which are taught by Krauss. It would have been obvious because doing so predictably achieves the commonly understood benefit of reducing clutter of the report by only displaying playbook run statistics specific to a selected function block.
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Bienkowski (US 9,336,115), further in view of Drake (US 10,795,649), and further in view of Hahn (US 10,664,535).
Regarding claim 7, Bienkowski modified in view of Drake fails to teach receiving, by the IT and security operations application, an application programming interface (API) request for the plurality of playbook run statistics, wherein the API request identifies the playbook; and sending a response including the plurality of playbook run statistics.
However, Hahn teaches receiving, by the IT and security operations application (see Abstract: “Once a customer has started monitoring log files, the customer can be notified that an actionable condition can exist, such as an alarm condition wherein metrics exceeded acceptable limits.”), an application programming interface (API) request for the plurality of playbook run statistics (see col. 2, lines 7-10: “A log data service is described for a multi-tenant environment that allows customers to access system, application and custom log files associated with virtual machine instances that are executing.” The Examiner interprets “log files associated with virtual machine instances that are executing” as the plurality of playbook run statistics. And see col. 2, lines 47-49, 57-64 and Fig. 1: “Upon receiving a request to view source-level log data (e.g., through selection of a UI button), a UI script 130 can be executed. …The UI script can automatically generate a request 148, such as an API request, that is transmitted over a network (not shown in FIG. 1) to a service provider, shown generally at 150. The service provider 150 can include one or more server computers for receiving the API request, searching through log data in a storage 160, and generating one or more API responses 170.”), wherein the API request identifies the playbook (see col. 2, line 66-col. 3, line 2: “Using information in the request 148, such as a log group identifier, the metric filter, and the start and end times, the service provider 150 can extract the source-level log data from the storage 160.”); and sending a response including the plurality of playbook run statistics (see col. 3, lines 11-15 and Fig. 1: “For each event found, the service provider 150 can begin to generate the API response including the events matching the metric filter. Once the service provider 150 has completed the request, the response 170 is transmitted back to the client device 110.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Bienkowski modified in view of Drake by adding the steps of receiving, by the IT and security operations application, an application programming interface (API) request for the plurality of program run statistics, wherein the API request identifies the program; and sending a response including the plurality of program run statistics, which are taught by Hahn. It would have been obvious because APIs can reduce operational costs by automating time-consuming tasks like pulling reports.
Regarding claim 8, Bienkowski modified in view of Drake fails to teach receiving, by the IT and security operations application, an application programming interface (API) request for the plurality of playbook run statistics, wherein the API request identifies the playbook, and wherein the API request includes one or more request parameters indicating at least one of: a filter identifying a list of function blocks of the playbook, a list of playbook run identifiers associated with the playbook, or a time range of playbook executions; generating filtered playbook run statistics based on the one or more request parameters; and sending a response including the filtered playbook run statistics.
However, Hahn teaches receiving, by the IT and security operations application (see Abstract: “Once a customer has started monitoring log files, the customer can be notified that an actionable condition can exist, such as an alarm condition wherein metrics exceeded acceptable limits.”), an application programming interface (API) request for the plurality of playbook run statistics (see col. 2, lines 7-10: “A log data service is described for a multi-tenant environment that allows customers to access system, application and custom log files associated with virtual machine instances that are executing.” The Examiner interprets “log files associated with virtual machine instances that are executing” as the plurality of playbook run statistics. And see col. 2, lines 47-49, 57-64 and Fig. 1: “Upon receiving a request to view source-level log data (e.g., through selection of a UI button), a UI script 130 can be executed. …The UI script can automatically generate a request 148, such as an API request, that is transmitted over a network (not shown in FIG. 1) to a service provider, shown generally at 150. The service provider 150 can include one or more server computers for receiving the API request, searching through log data in a storage 160, and generating one or more API responses 170.”),
wherein the API request identifies the playbook (see col. 2, line 66-col. 3, line 2: “Using information in the request 148, such as a log group identifier, the metric filter, and the start and end times, the service provider 150 can extract the source-level log data from the storage 160.”);
and wherein the API request includes one or more request parameters indicating at least one of: a filter identifying a list of function blocks of the playbook, a list of playbook run identifiers associated with the playbook, or a time range of playbook executions (see col. 5, lines 18-22: “the client 390 can transmit a request, such as an API request, including a group name, a stream name, a time range (e.g., start and end times), a metric filter, etc., in order to obtain the source-level log data stored in the data base 350.”);
generating filtered playbook run statistics based on the one or more request parameters (see col. 2, line 66-col. 3, line 2: “Using information in the request 148, such as a log group identifier, the metric filter, and the start and end times, the service provider 150 can extract the source-level log data from the storage 160.”); and
sending a response including the filtered playbook run statistics (see col. 3, lines 11-15 and Fig. 1: “For each event found, the service provider 150 can begin to generate the API response including the events matching the metric filter. Once the service provider 150 has completed the request, the response 170 is transmitted back to the client device 110.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Bienkowski modified in view of Drake by adding the steps of receiving, by the IT and security operations application, an application programming interface (API) request for the plurality of program run statistics, wherein the API request identifies the program; and wherein the API request includes one or more request parameters indicating at least one of: a filter identifying a list of function blocks of the playbook, a list of playbook run identifiers associated with the playbook, or a time range of program executions; generating filtered program run statistics based on the one or more request parameters; and sending a response including the filtered program run statistics, which are taught by Hahn. It would have been obvious because APIs can reduce operational costs by automating time-consuming tasks like pulling reports and including request parameters in the API request helps a user retrieve only statistics that the user is interested in.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Bienkowski (US 9,336,115), further in view of Drake (US 10,795,649), and further in view of Thomas (US 2017/0063920).
Regarding claim 10, Bienkowski modified in view of Drake fails to teach executing, by a playbook execution engine, a function block of the function blocks, wherein executing the function block includes initiating interactions with a computing device or service that is external to the IT and security operations application; and wherein playbook run statistics for the function block reflect the interactions with the computing device or service.
In the same field of endeavor, Thomas teaches executing, by a playbook execution engine (see [0065] and Fig. 1: “Real-time trigger event feeds of actionable items can be directly accepted by the activation component 116 in various formats to initiate pre-configured workflows.”), a function block of the function blocks, wherein executing the function block (see [0129] and Fig. 15E reproduced below: “The menu 1544 may also include pre-planned action display 1576. The pre-planned action display 1576 may include actions or groups of actions that, as part of an approved cyber-security policy, are associated with certain types of cyber-security threats”. The Examiner interprets actions 1576 displayed in Fig. 15E as a function block) includes initiating interactions with a computing device or service that is external to the IT and security operations application (see [0040] and Fig. 1: “The activation component 116 is configured to respond to manual triggers and/or triggers received from the mediation component 108 by controlling and/or managing disparate network elements to mitigate cyber-security threats”. And see [0067] and Fig. 1: “A cyber-security system in accordance with embodiments discussed herein may employ an activation component 116 having flow-through functionality. As used herein, "activation" is the process of managing multiple, disparate network elements with a common, high-level command or API interface”. As shown in Fig. 1, the “Controlled Systems” used to mitigate cyber-security threats are external to the Cyber Data Management Node, which is interpreted by the Examiner as “the data intake and query system”. And see [0100] and Fig. 11: “In operation 1112, …In the event of an external attack, the mediation module 108 may trigger the activation module 116 to instantly reconfigure the network perimeter 712 and firewalls to stop the attack all in machine speed.” The Examiner interprets the network perimeter 712 as a computing device or service that is external to the IT and security operations application).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Bienkowski modified in view of Drake by adding the step of executing, by a playbook execution engine, a function block of the function blocks, wherein executing the function block includes initiating interactions with a computing device or service that is external to the IT and security operations application, which is taught by Thomas. It would have been obvious because doing so predictably achieves the commonly understood benefit of securing a network perimeter. When such a modification is made, Bienkowski modified in view of Drake and Thomas would teach executing, by a playbook execution engine, a function block of the function blocks, wherein executing the function block includes initiating interactions with a computing device or service that is external to the IT and security operations application; and wherein playbook run statistics for the function block reflect the function block's interactions with the computing device or service.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHIMEI ZHU whose telephone number is (571)270-7990. The examiner can normally be reached 10am-6pm Monday-Friday.
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 at 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 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.
/ZHIMEI ZHU/ Examiner, Art Unit 2495
Prosecution Insights