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 .
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.
Claim(s) 1-2, 4-7, 9-13, 15-18, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Towstopiat et al., US 2015012122 A1 (hereafter referred to as Towstopiat) in view of Reutova et al., 11876675 B2 (hereafter referred to as Reutova).
Claim 12, Towstopiat teaches an electronic device, comprising a memory and a processor, the memory having executable code stored therein, the processor, when executing the executable code, implementing acts comprising:
in response to a flow switching verification request for a target system sent by a user (request to determine status of migration based on recovery plans. Flow switching = site migration. Verification request = requesting status of recovery plans. See p. 37, “An administrator of cloud computing system 300, or other user, interacts with user device 325 to define one or more disaster recovery plans, to monitor hosts 235, to execute one or more disaster recovery plans, and/or to monitor the execution of one or more disaster recovery plans.” And p. 42, “FIG. 5 is an exemplary map user interface (UI) 500 for displaying disaster recovery plan execution by cloud computing system 300 (shown in FIG. 3).”), performing, by an initiation server (p. 42, “cloud computing system 300”), a target operation corresponding to the flow switching verification request for the target system (p. 41, “map user interfaces and/or animated progress indicators, described below with reference to FIGS. 5, 6, and 7, may be generated at least partially by management server 320 and transmitted by management server 320 (shown in FIG. 3) to user device 325 for display to a user.” The mapping of progress indicators.), and
triggering a target event for a verification server that corresponds to the flow switching verification request (p. 44, “The detected transfer may include a transfer of individual computing nodes, a transfer of one or more business units, and/or an execution of a disaster recovery plan that results in the transfer of multiple business units and the computing nodes associated therewith.”); and
in response to the target event, driving, by the verification server, a user interface test for the target system (p. 45, “In some embodiments, user device 325 detects at 410 the transfer by receiving a notification of the transfer from management server 320.” ), obtaining a sequence of a plurality of services of the target system triggered to be accessed through the user interface test (p. 46, “During performance of the transfer, user device 325 displays at 415 a first animated progress indicator 512 in first region 504 representing termination of one or more computing nodes at first site 3101. User device 325 also displays at 420, simultaneous to the display of first animated progress indicator 512, a second animated progress indicator 514 in second region 506 representing initiation of the computing nodes at second site 3102.”) and a plurality of pieces of first computer room information corresponding to the plurality of services respectively (p. 46, “termination of one or more computing nodes at first site 3101”) ;
obtaining second computer room information corresponding to a domain name of a target domain triggered to be accessed through the user interface test (p. 88, “At least a portion of the functionality of the various elements illustrated in the figures may be performed by other elements in the figures, or an entity (e.g., processor, web service, server, application program, computing device, etc.) not shown in the figures.” The portion of display for the sites including web services of the second site. See p. 46, “a second animated progress indicator 514 in second region 506 representing initiation of the computing nodes at second site 3102.” );
determining a verification result corresponding to the flow switching verification request (p. 81, “As shown in FIG. 9, successful transfer arrows 902 indicate that two business units have been successfully transferred from a source site to a target site. A failed transfer arrow 904 indicates that an error occurred during the transfer of another business unit from the source site to the target site, and a recovery plan 906 corresponding to the failed transfer is graphically distinguished from waiting and completed recovery plans in recovery plan list 812.”) based on the sequence (“recovery plan”), the first computer room information (source location) and the second computer room information (target location). Towstopiat does not specifically teach the recovery plan test is a user interface test (Towstopiat teaches p. 80, “Testing a recovery plan is similar to executing the recovery plan, but one or more steps, such as terminating the computing nodes at the source site, may be omitted.” But Towstopiat teaches the similarity of the recovery plan to testing the recovery plan.). However, in the same field of endeavor, Reutova teaches user interface test for testing (column 4, lines 59-61; “This interface in some embodiments includes a graphical user interface (GUI) that provides a view of the logical network components being defined, reviewed, and deployed through the third manager. This interface in some embodiments also includes an application programming interface (API) through which the logical network components can be defined, reviewed, and deployed.” And column 15, lines 67 and column 16, line 1; “As mentioned above, selection of the next control 1615 in FIG. 16 directs the migration wizard to move to the next pane in the migration plan, which is the test pane 2300 illustrated in FIG. 23. Ideally the user creates a test plan for their organization, but general suggestions for testing are provided through the test pane 2300.”).
Reutova motivations “the migration wizard to move to the next pane in the migration plan, which is the test pane 2300 illustrated in FIG. 23. Ideally the user creates a test plan for their organization, but general suggestions for testing are provided through the test pane 2300. These suggestions in some embodiments include the following: (1) review any warnings that were generated during migration, (2) test the 1:1 cloud account mapping that the user specified in plan step 1, (3) test a sample or all of the impacted cloud templates and deployments, (4) examine mapped network virtualization load balancers, networks, and security groups to verify that they are configured as expected, (5) provision and destroy applications by deploying cloud templates and confirming that the applications land on the correct endpoint and that they are functional, and (6) monitor previously deployed applications to verify that they are functioning as intended.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify Towstopiat by incorporating user interface testing from Reutova for the testing framework using a variation of the recovery plans. The motivation would have been to correctly deploy services by reviewing the migrated services.
Claim 1 teaches a method for verifying system flow switching comprising steps similar to the operations of claim 12 above. Claim 1 is rejected on a similar rationale.
Claim 10, the method of claim 1, further comprising, sending, by the verification server, the verification result to the user after the verification result is confirmed.
Claim 11 teaches a non-transitory computer-readable storage medium, having a computer program stored thereon, the computer program, when executed in a computer, causing the computer to perform acts comprising similar to the operations of claim 12 above. Claim 11 is rejected on a similar rationale.
Claim 13, Towstopiat-Reutova teaches the electronic device of claim 12, wherein driving, by the verification server, a user interface test for the target system, obtaining a sequence of a plurality of services of the target system triggered to be accessed through the user interface test and a plurality of pieces of first computer room information corresponding to the plurality of services respectively (from claim 12) comprises:
sending, by the verification server, a first scenario corresponding to the user interface test to an interface test server (Towstopiat, p. 80, “Testing a recovery plan is similar to executing the recovery plan, but one or more steps, such as terminating the computing nodes at the source site, may be omitted.” The first scenario is without the step of terminating the recovery site.);
determining and performing, by the interface test server, an interface test task based on the first scenario (Towstopiat, p. 80, “…the methods described herein may be used to monitor an execution of one or more disaster recovery plans, as described above, and/or to monitor a test of one or more disaster recovery plans. Testing a recovery plan is similar to executing the recovery plan,…”);
sending, by the interface test server, an identifier of a log record of the target system generated through the user interface test to a log analysis server (Towstopiat, p. 52, “In addition to error message 532, map UI 500 may include a history report button 534. In response to selection of history report button 534, user device 325 displays a history report including detailed log generated during the transfer process. The history report provides information that is helpful in troubleshooting errors.” And p. 50, “In addition to error message 532, map UI 500 may include a history report button 534. In response to selection of history report button 534, user device 325 displays a history report including detailed log generated during the transfer process. The history report provides information that is helpful in troubleshooting errors.”); and
determining, by the log analysis server, the sequence composed of the plurality of services and the plurality of pieces of first computer room information corresponding to the plurality of services based on the identifier and a system log of the target system (Towstopiat, p. 52, “In addition to error message 532, map UI 500 may include a history report button 534. In response to selection of history report button 534, user device 325 displays a history report including detailed log generated during the transfer process.” The transfer process is detailed in the log records and the errors are determined from the log records. See p. 44, “The detected transfer may include a transfer of individual computing nodes, a transfer of one or more business units, and/or an execution of a disaster recovery plan that results in the transfer of multiple business units and the computing nodes associated therewith.”), and
sending the sequence and the first computer room information to the verification server (Towstopiat, p. 39, “A master recovery plan may specify that one or more individual recovery plans are to be executed in a particular sequence and/or in parallel. Disaster recovery plans (e.g., master and/or individual recover plans), business units, and/or associations between VMs 235 and business units, may be stored by management server 320 and/or by user device 325.” And p. 80 “The methods described herein may be used to monitor an execution of one or more disaster recovery plans, as described above, and/or to monitor a test of one or more disaster recovery plans. Testing a recovery plan is similar to executing the recovery plan, but one or more steps, such as terminating the computing nodes at the source site, may be omitted.” The test of the recovery plan includes first site information.).
Claim 2 teaches a method for verifying system flow switching comprising steps similar to the operations of claim 13 above. Claim 2 is rejected on a similar rationale.
Claim 15, Towstopiat-Reutova teaches the electronic device of claim 12, the acts further comprising:
in response to the target event, driving, by the verification server, an interface access test for the target system, and wherein determining a verification result corresponding to the flow switching verification request based on the sequence, the first computer room information and the second computer room information (per claim 12) comprises:
determining the verification result corresponding to the flow switching verification request according to the sequence, the first computer room information, the second computer room information, and a test result of the interface access test (Towstopiat, p. 80, “In such embodiments, DR progress UI 800 may graphically distinguish a recovery plan test from a recovery plan execution. For example, graphical elements (e.g., directional arrow 814 and/or second animated progress indicator 822) within DR progress UI 800 may be displayed in a unique color when a recovery plan is being tested.” And p. 81, “As shown in FIG. 9, successful transfer arrows 902 indicate that two business units have been successfully transferred from a source site to a target site. A failed transfer arrow 904 indicates that an error occurred during the transfer of another business unit from the source site to the target site, and a recovery plan 906 corresponding to the failed transfer is graphically distinguished from waiting and completed recovery plans in recovery plan list 812.”).
Claim 4 teaches a method for verifying system flow switching comprising steps similar to the operations of claim 15 above. Claim 4 is rejected on a similar rationale.
Claim 16, Towstopiat-Reutova teaches the electronic device of claim 15, wherein driving, by the verification server, an interface access test for the target system (per claim 12) comprises:
sending, by the verification server, an event type of the target event and a second scenario corresponding to the interface access test to the configuration server (Towstopiat, p. 50, “When user device 325 determines at 425 that the transfer is no longer in progress, if the transfer is determined at 428 to be not completely successful (e.g., one or more errors or warnings have been reported by management server 320), user device 325 displays at 430 the errors and/or warnings encountered during the transfer. For example, user device 325 may display at 430 an error message 532 in map UI 500 describing an error reported by management server 320 with respect to the transfer.”);
determining, by the configuration server, an interface test task based on the event type and the second scenario (Towstopiat, The event type is successful or unsuccessful, so the second scenario is successful. And p. 80, “the methods described herein may be used to monitor an execution of one or more disaster recovery plans, as described above, and/or to monitor a test of one or more disaster recovery plans. Testing a recovery plan is similar to executing the recovery plan, but one or more steps, such as terminating the computing nodes at the source site, may be omitted.”), and invoking an interface test server to perform the interface test task (p. 76, “As the recovery plans are executed, DR progress UI 800 is updated to indicate the status (e.g., waiting, executing, complete, and/or failed) of steps within the recovery plans. For example, the termination and/or initiation of each computing node and/or business unit may be considered a step in a recovery plan.” Invoking test plan is interpreted as test task.); and
sending, by the interface test server, a test result of the interface test task to the verification server (Towstopiat, p. 80, “In such embodiments, DR progress UI 800 may graphically distinguish a recovery plan test from a recovery plan execution. For example, graphical elements (e.g., directional arrow 814 and/or second animated progress indicator 822) within DR progress UI 800 may be displayed in a unique color when a recovery plan is being tested.”).
Claim 5 teaches a method for verifying system flow switching comprising steps similar to the operations of claim 16 above. Claim 5 is rejected on a similar rationale.
Claim 17, Towstopiat-Reutova teaches the electronic device of claim 15, wherein determining the verification result corresponding to the flow switching verification request according to the sequence, the first computer room information, the second computer room information, and a test result of the interface access test (per claim 12 above) comprises:
determining a first verification result based on whether expected computer room information corresponding to a respective service in the sequence after the target operation matches the first computer room information corresponding to the respective service (Towstopiat, p. 49, “User device 325 may also display in map UI 500 a directional arrow 530 from the geographic location of the source site to the geographic location of the target site. User device 325 continues displaying at 415 first animated progress indicator 512 and displaying at 420 second animated progress indicator 514, updating the indicated progress, as long as user device 325 determines at 425 that the transfer is still in progress.”);
determining a second verification result based on whether expected computer room information corresponding to the domain name after the target operation matches the second computer room information (Towstopiat, p. 49, “User device 325 may also display in map UI 500 a directional arrow 530 from the geographic location of the source site to the geographic location of the target site. User device 325 continues displaying at 415 first animated progress indicator 512 and displaying at 420 second animated progress indicator 514, updating the indicated progress, as long as user device 325 determines at 425 that the transfer is still in progress.”); and
determining the verification result corresponding to the flow switching verification request based on the first verification result, the second verification result, and the test result (Towstopiat, p. 51, “For example, a green color may show the recovery steps that have completed (e.g., which VMs 235 are powered on and running at the destination recovery site) and/or a first individual recovery plan (e.g., "NYC--Plan 001" within recovery plans 544) that has been successfully completed.” “Red may also be used for the arrow from "Washington, D.C." to "Toronto" to indicate existence of the error. A red color may also appear in a horizontal progress bar to illustrate that an error occurred at a specific point within the fourth individual recovery plan (e.g., "DC--Plan 003"). A red error icon may also be shown in the error message, along with a red error badge in the recovery icon to illustrate "Recovery Incomplete" within the error message.”).
Claim 6 teaches a method for verifying system flow switching comprising steps similar to the operations of claim 17 above. Claim 6 is rejected on a similar rationale.
Claim 18, Towstopiat-Reutova teaches the electronic device of claim 12, wherein the flow switching verification request comprises a post-flow-switching verification request , and
wherein in response to a flow switching verification request for a target system sent by a user, performing, by an initiation server, a target operation corresponding to the flow switching verification request for the target system, and triggering a target event for a verification server that corresponds to the flow switching verification request (per claim 12) comprises:
receiving the post-flow-switching verification request sent by the user (Towstopiat, p. 39, “A disaster recovery plan may include a master recovery plan that, in turn, includes one or more individual recovery plans. For example, a first individual recovery plan may specify that some, or all, computing nodes and/or business units at first site 3101 are to be transferred to second site 3102. A second individual recovery plan may specify that some other computing nodes or business units at first site 3101 are to be transferred to third site 3103.”);
performing a flow switching operation for the target system (Towstopiat, p. 39, performing the first individual recovery plan.); and
triggering a post-flow-switching verification event for the verification server according to the post-flow-switching verification request (Towstopiat, after the first individual recovery plan, see p. 80, “DR progress UI 800 may graphically distinguish a recovery plan test from a recovery plan execution. For example, graphical elements (e.g., directional arrow 814 and/or second animated progress indicator 822) within DR progress UI 800 may be displayed in a unique color when a recovery plan is being tested.”).
Claim 7 teaches a method for verifying system flow switching comprising steps similar to the operations of claim 18 above. Claim 7 is rejected on a similar rationale.
Claim 20, Towstopiat-Reutova teaches the electronic device of claim 12, wherein the flow switching verification request comprises a pre-flow-switching verification request (Towstopiat, p. 80, “the methods described herein may be used to monitor an execution of one or more disaster recovery plans, as described above, and/or to monitor a test of one or more disaster recovery plans. Testing a recovery plan is similar to executing the recovery plan, but one or more steps, such as terminating the computing nodes at the source site, may be omitted.”), and
wherein in response to a flow switching verification request for a target system sent by a user, performing, by an initiation server, a target operation corresponding to the flow switching verification request for the target system, and triggering a target event for a verification server that corresponds to the flow switching verification request ( per claim 12) comprises:
receiving the pre-flow-switching verification request sent by the user (Towstopiat, p. 39, “A disaster recovery plan may include a master recovery plan that, in turn, includes one or more individual recovery plans. For example, a first individual recovery plan may specify that some, or all, computing nodes and/or business units at first site 3101 are to be transferred to second site 3102. A second individual recovery plan may specify that some other computing nodes or business units at first site 3101 are to be transferred to third site 3103.”);
performing a null operation for the target system (Towstopiat, p. 80, “Testing a recovery plan is similar to executing the recovery plan, but one or more steps, such as terminating the computing nodes at the source site, may be omitted.”); and
triggering a pre-flow-switching verification event for the verification server according to the pre-flow-switching verification request (p. 39, “In this scenario, user device 320 detects at 410 the transfer(s) resulting from each individual recovery plan. Representing execution of the first recovery plan, user device 325 displays at 415 animated progress indicator 512 in first region 504, which corresponds to the source (first site 3101), and displays at 420 animated progress indicator 514 in second region 506, which corresponds to the target (second site 3102).”).
Claim 9 teaches a method for verifying system flow switching comprising steps similar to the operations of claim 20 above. Claim 9 is rejected on a similar rationale.
Claim(s) 3 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Towstopiat and Reutova as applied to claim 1 and 12 above, and further in view of Baturin et al., US 11005949 B1 (hereafter referred to as Baturin).
Claim 14, Towstopiat-Reutova teaches the electronic device of claim 12, wherein obtaining the second computer room information corresponding to the domain name of the target domain triggered to be accessed through the user interface test (per claim 12) comprises:
sending computer room information of the second computer room to the verification server (See Figure 8, p. 73, “FIG. 8 is a disaster recovery (DR) progress UI 800 that may be presented individually and/or integrated with a map UI (e.g., map UI 500, shown in FIG. 5).” “Accordingly, both first site 3101 and second site 3102 are source sites, and third site 3103 is a target site.” And p. 74, “In DR progress UI 800, recovery plans are displayed in a recovery plan list 812 and are graphically distinguished from each other based on status (e.g., executing, idle, and failed).”).
Towstopiat-Reutova does not specifically teach sending a data fetch request to a data fetch server, the data fetch server obtaining and parsing a network data packet generated through the user interface test based on the data fetch request to obtain the domain name of the target domain; and sending, the data packet fetch service, the domain name to a configuration server, the configuration server determining a second computer room corresponding to the domain name based on a pre-configured mapping relationship between domain names and computer rooms. However, in the same field of endeavor, Baturin teaches sending a data fetch request to a data fetch server, the data fetch server obtaining and parsing a network data packet generated through the user interface test based on the data fetch request to obtain the domain name of the target domain (column 4, lines 1-14; “According to an exemplary embodiment, migration is performed with the help of a special tool—the migrator.” “Migration of services is implemented as follows. The migrator creates configuration of the web sites and the mail service on the target server; the migrator copies files and mail messages from the source to the target server; the migrator creates databases (if replication is not available) on the target server;”); and
sending, the data packet fetch service, the domain name to a configuration server, the configuration server determining a second computer room corresponding to the domain name based on a pre-configured mapping relationship between domain names and computer rooms (column 4, lines 10-20; “the migrator creates DNS zones with DNS records pointing to the target server.” Transfer information including the target domain. Interacting with the migration tool as a data fetch server. “Then, the end-user of a domain or the administrator confirms that site works well on the target server. Content synchronization is started, and the migrator synchronizes new files from the source to the target server. The migrator performs a DNS switch by setting a DNS zone on the source server as slave to the DNS zone on the target server.” The second location is the target server location.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Towstopiat-Reutova by incorporating mapping of domain names to target location from Baturin to provide effectiveness. The motivation would be to provide seamless incorporation of host name mapping in the servers of the new site.
Claim 3 teaches a method for verifying system flow switching comprising steps similar to the operations of claim 14 above. Claim 3 is rejected on a similar rationale.
Claim(s) 8 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Towspotiat and Reutova as applied to claim 2 and 12 above, and further in view of Gupta et al., USPN 10970110 B1 (hereafter referred to as Gupta).
Claim 19, Towstopiat-Reutova teaches the electronic device of claim 12, wherein the flow switching verification request comprises a flow switching recovery verification request, and wherein in response to a flow switching verification request for a target system sent by a user, performing, by an initiation server, a target operation corresponding to the flow switching verification request for the target system, and triggering a target event for a verification server that corresponds to the flow switching verification request (claim 12) comprises:
receiving the flow switching recovery verification request sent by the user (column 12, lines 42-45, 50-55; “A migration workflow is configured so that the migration manager 304 may determine the correct API requests and/or the order of those API requests so that the migration commands 316 sent to the services and resource 310 are performed in the correct order.” “Based on the migration workflow 314, the migration manager 304 may begin generating migration commands 316 to be sent to the services and resources 310 associated with the migration.”);
performing a flow switching rollback operation for the target system (column 14, lines 48-43; “while the migration continues to prepare the target 410, the migration manager may determine that the migration is not likely to succeed as described above. At this determination, the migration manager may cancel the migration and perform any rollback necessary to return the system to a known state.”); and
triggering a flow switching recovery verification event for the verification server according to the flow switching recovery verification request (column 14, lines 65-67 and column 15, line 1; “If it is not the case that the target is prepared 412, the migration manager may begin a rollback 424 and, after the rollback may resume the virtual machine instance at the source 426.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify … by incorporating rollback mechanisms from Gupta into the management workflows into the migration plans of Towstopiat-Reutova to improve stability. The motivation would have to increase system robustness after migrations.
Claim 8 teaches a method for verifying system flow switching comprising steps similar to the operations of claim 19 above. Claim 8 is rejected on a similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Joukov et al., US 20120204149 A1, teaches an automated migration testing based on comparing discovered server and software configuration before and after migration, taking into account desired changes from a migration design.
Sudheer, US 20250103350 A1, teaches a method for configuring a workflow to create or manage a specified environment. The operations can include receiving an input including a first set of parameters associated with one or more environments other than the specified environment and a second set of parameters associated with the specified environment. The operations can further include generating a payload based on the input and validating the generated payload.
Kommula et al., US 20210195806 A1, teaches the resource utilization analyzer 108 also determines the quantity or amount of available/free resources in the server rooms 103a-d to determine the number of workloads or VMs that can be migrated to and executed in each room 103a-d. The resource utilization analyzer 108 forwards this information to the workload authorizer 110 for further processing.
Wakeman et al., US 20160191365 A1, teaches at block 86, when the migration window is open, the system begins migration by entering the Server ID, Cabinet, and Cab Unit Data in the Destination Data Center 14 for each server and device that is being migrated to Destination Data Center 14. At block 87, the system verifies the data again, such as by using the analyze tool described in connection with block 83 (as well as with analyze button 242 described further in connection with FIG. 2), to ensure that the server information in Destination Data Center 14 has not changed.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PATRICE L WINDER whose telephone number is (571)272-3935. The examiner can normally be reached M-F 10am-6pm.
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, KAMAL B DIVECHA can be reached at (571)272-5863. 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.
/Patrice L Winder/Primary Examiner, Art Unit 2453
Prosecution Insights