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 .
Response to Amendment
This action is in response to the communications and remarks filed on 04/10/2026. Claims 1, 4-5, 14 have been amended. Claims 1-20 have been examined and are pending.
Response to Arguments
Acknowledgement to applicant’s amendment to claims 4 and 14 have been noted. The claim has been reviewed, entered and found obviating to previously raised objection for minor informalities. Objection to the claims is hereby withdrawn.
Acknowledgement to applicant's amendment to claims 1-11 have been noted. The claim has been reviewed, entered and found obviating to previously raised rejection under 35 USC 101. Rejection under 35 USC 101 to claims 1-11 is hereby withdrawn.
Applicants’ arguments in the instant Amendment, filed on 04/10/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant’s arguments: “Claims 1 and 12 are rejected, under 35 U.S.C. 102(a)(1), as being allegedly anticipated by Trentini US PG Publication 20200396243 Al. Applicant respectfully traverses in view of the following. Claim 1 recites a hardware collection engine to collect requests and responses of one or more API calls associated to an application, as claimed. In contrast, Trentini discloses a risk assessment computer system for calculating a risk score of an entity (see Trentini, paragraph 24) by capturing network flow traffic produced by user logins (see Trentini, paragraph 29) using a sensor that extracts the data through mirror port ingestion (see Trentini, paragraph 32). The authentication engine constructs digital signatures, e.g., signatures of known MFA logins, either time series or network flow, can be constructed from a query of the network traffic metadata (see Trentini , paragraph 33). The authentication engine may generate and submit the query to the database (see Trentini, paragraph 33) where the query may filter digital signatures stored with the database and return a total number of bytes sent and/or received during the MFA login communication session (see Trentini, paragraph 34). The MFA user logins may be in the form of flow series data
index in the x-axis versus total bytes in the y-axis and where each MFA login session can depict a time to enter the MFA code received at the user device (see Trentini, paragraph 35)… Applicant respectfully submits that network traffic may be through a non-API means, e.g., web browsing, file transfers, streaming data, network protocols, etc. As such, a mere disclosure of network traffic, as disclosed by Trentini does not necessarily teach or suggest that they are from one or more API calls in the claimed fashion. As such, Trentini fails to teach or suggest a hardware collection engine to collect requests and responses of one or more API calls associated to an application, as
claimed.”
The Examiner disagrees with the Applicant’s argument. Trentini discloses a a hardware collection engine to collect requests and responses of one or more API calls associated to an application, as claimed. First, the specification describes how an API call can be made during authentication and authorization, access control, encryption, input validation, and sanitization, rate limiting and throttling, error handling, monitoring and logging, and regular security audits and testing might be vulnerable to security risk [specification, para 0003]. “Such request and response may correspond to one or more API calls including initial authentication, authorization, and/or one or more Hyper Text Transfer Protocol (HTTP) requests and responses made afterward… may include data related to an API source, API endpoint, the parameters sent in an API request, the cookie used in the request, the detailed information sent in the request body (e.g., user id, token id, etc), the status code of the API response, the parameters received from response header, all detailed content received from the response body including business-specific content, PII” [specification, para 0006].
Trentini does describes a risk assessment system that attempts to capture, collect network flow traffic metadata and extract data through mirror port ingestion. Trentini also insulates an entity against remote attacks by implementing a Multi-Factor Authentication (MFA) login events platform that protect and prevent unauthorized access and attacks to sensitive data; where the assessment system tracks responses transmitted by sensor 804 via a software agent and deep packet inspection; where the transfer of data (i.e. authentication responses to risk assessment computer system) of the cloud may occur over HTTPS using JSON payload format [Abstract, Fig. 10 and paras 0028-0035, 0070-0072 and 0086-0087].
As such, respectfully submits that Trentini does disclose the limitation of “…hardware collection engine to collect requests and responses of one or more API calls associated to an application;” where throughout Trentini teaches inherent controls utilized APIs for its authentication and authorization, access control via HTTP request and response methods. More importantly, Trentini is from the same field of endeavor supporting traffic logging (e.g. anomaly detection) and vulnerability analysis; the rejection below cited to Trentini will be maintained.
Applicant’s arguments: “Moreover, independent Claim 1 recites a hardware API sequence engine to: combine one or more features extracted from the collected requests and responses, wherein the one or more features are associated with login behavior, API request content and behavior, API object accessing content and behavior, and API response content and behavior, as claimed. Accordingly, the features are associated with 1) login behavior, 2) API request content, 3) API object accessing content, and 4) API response content… Accordingly, Trentini is generically directed to activity between user device and risk assessment computer system. In fact, as discussed above, Trentini fails to explicitly teach or suggest API requests/responses, etc. As such, Trentini fails to explicitly teach or suggest that the one or more features are associated with login behavior, API request content and behavior, API object accessing content and behavior, and API response content and behavior, as claimed.”
The Examiner disagrees with the Applicant’s argument. The Examiner respectfully submits that Trentini also discloses a hardware API sequence engine to: combine one or more features extracted from the collected requests and responses, wherein the one or more features are associated with login behavior…Trentini discloses how the MFA login signatures and associated processes of a user device assessing a user device, which are analyzed and compared to determine individual user behavior and infrastructure to determine network delays due to cited differences. The process of determining for classifying logon signatures use an aggregate series of logins over a sample time period. [Trentini, paras 0036-0037 and 0041]. As such; the rejection below cited to Trentini will be maintained.
Applicant’s arguments: “Independent Claim 1 further recites a hardware API sequence engine to: encode the combined one or more features via a neural network based embedding model to create a behavior fingerprint of each of the one or more login sessions, as claimed. In contrast, Trentini discloses a risk assessment computer system for calculating a risk score of an entity where the system includes a metadata engine, authentication engine, signature calculation engine, a reference model engine, and a classification engine (see Trentini, paragraph 24). Trentini discloses that the signature calculation engine to calculate an average digital signature, e.g., digital signatures used in the calculation of an average signature may be used to generate an MFA reference model representative of typical MFA login (see Trentini, paragraph 38). Trentini further discloses that the reference model engine generates an MFA reference model, e.g., mapping of sample signatures onto the candidate reference generated from signature calculation engine (see Trentini, paragraph 53).
Accordingly, Trentini discloses generating and calculating digital signature and using the MFA reference model. Nowhere does Trentini teach or suggest a hardware API sequence engine to: encode the combined one or more features via a neural network based embedding model to create a behavior fingerprint of each of the one or more login sessions, as claimed.
As such, Trentini fails to anticipate independent Claim 1. Claim 12 is also patentable over Trentini for similar reasons that Claim 1 is patentable. As such, allowance of Claims 1 and 12 is earnestly solicited.”
The Examiner disagrees with the Applicant’s argument. The Examiner respectfully submits that Trentini does disclose encode the combined one or more features via a neural network based embedding model to create a behavior fingerprint of each of the one or more login session. First, Examiner interpreted the mapping function as an analogous transformation method to the instant application. Examiner cited to paras 0024, 0038, and 0053 and Fig. 1 which shows how the signature calculation engine 114 maps the sample signatures indicative of various captured user behavior(s) in an multi-factor authentication (MFA) reference model 702 and the non-MFA reference model 704. As such; the rejection below cited to Trentini will be maintained [See also, Trentini para 0051].
Applicant’s arguments: “Claims 2-4, 6-14 and 16-20 are rejected, under 35 U.S.C. 103, as being allegedly unpatentable over Trentini US PG Publication 20200396243 A1, in view of Moriarty et al, hereinafter ("Moriarty"), US PG Publication 20220019670 A1. Moriarty fails to remedy the failures of Trentini with respect to independent claims. Claims 2-4, 6-14, and 16-20 depend from their respective independent claims and are patentable by virtue of their dependency in addition to their own patentable features. As such, allowance of
Claims 2-4, 6-14 and 16-20 is earnestly solicited.”
The Examiner respectfully submits that no arguments have been presented for dependent claims 2-4, 6-14 and 16-20. As such; the rejection below cited to Trentini, in view of Moriarty will be maintained.
Applicant’s arguments: “Claims 5 and 15 are rejected, under 35 U.S.C. 103, as being allegedly unpatentable over Trentini US PG Publication 20200396243 A1, in view of Abdul Rasheed et al, hereinafter ("Abdul"), US PG Publication 20210271568 A1. Abdul fails to remedy the failures of Trentini with respect to independent claims. Claims 5 and 15 depend from their respective independent claims and are patentable by virtue of their dependency in addition to their own patentable features. As such, allowance of Claims and 15 is earnestly solicited.”
The Examiner respectfully submits that no arguments have been presented for dependent claims 5 and 15. As such; the rejection below cited to Trentini, in view of Abdul Rasheed will be maintained.
Response to Arguments
Applicant’s arguments, see pp. 17-19, filed 12/29/2025, with respect to the rejection(s) of claim(s) 1-4, 6-14, and 16-20 under 103 rejection have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Trentini US PG Publication 20200396243 A1.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1 and 12 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Trentini US PG Publication 20200396243 A1.
Regarding claims 1 and 12, Moriarty teaches a behavior analytics system for different types of Application Programming Interface (API) vulnerabilities and attacks, the behavior analytics system comprises: [Trentini Abstract and ¶¶0009-0010 and 0021-0022 0024 a risk assessment computer system 100 implemented to combine threat indicator characteristic information in real time with application behavior patterns; software inventory may be implemented as the point of intelligence for application programming interfaces (APIs) and management systems to enact controls.]; a collection engine to collect requests and responses of one or more API calls associated to an application in a protected environment made during one or more login sessions [Trentini Fig. 1 and ¶¶0024 0026 0029 0032-0035 processors, controllers…make up an engine; metadata engine 110 receive network traffic metadata from user interactions on user device 150 via network 145. The network metadata may include information associated with a series of multi-factor authentication (MFA) login events …];
an API sequence engine to:
combine one or more features extracted from the collected requests and responses, wherein the one or more features are associated with login behavior, API request content and behavior, API object accessing content and behavior, and API response content and behavior [Trentini ¶¶0040-0041 process of determining a time frame for classifying logon signatures may correspond with an estimation to determine normal patterns of usage based on human behavior and technology implementation; determining risk by using an aggregate series of logins over a sample time period…]; and encode the combined one or more features via a neural network based embedding model to create a behavior fingerprint of each of the one or more login sessions [Trentini ¶¶0024, 0038, and 0053 Fig. 1 shows a risk assessment computer system 100 comprising a signature calculation engine 114 used to generate a digital signatures for a reference model engine 116 generates an multi-factor authentication (MFA) reference model maps sample signatures from signature calculation engine 114 based on an average of varied login sessions and their respective MFA sample signatures. Fig. 7 and ¶0059 MFA reference model 702 and the non-MFA reference model 704 based on a scale of 0-1 with higher value indicative of a better match. Examiner interprets the map function as analogous to encoding the signatures for creating a reference]; a clustering engine to detect at least one of: a normal and an abnormal user behavior based on the created behavior fingerprint of each of the one or more login sessions [Trentini Fig. 1 and ¶¶0056 Classification engine 118 may be configured to use the MFA reference model and non-MFA reference model for classification of the unclassified user login data, as illustrated in FIG. 6. For example, a query of the database may return all user logins for a particular time period of interest, including MFA and non-MFA user logins and reference models. Signature calculation engine 114 may warp the yet unclassified user logins to each reference model for comparison. Once compared, the unclassified user logins may be classified to the reference model that is the best fit and match]; and a report and response engine to report the detected abnormal user behavior [detected cyber-risks assigned to an entity or individual and the risk score(s) may be calculated for all individual user devices that connect to risk assessment computer system 100 and a percentage usage may be reported back to risk assessment computer system 100 for further analysis].
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 2-4, 6-14 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Trentini US PG Publication 20200396243 A1, in view of Moriarty et al, hereinafter (“Moriarty”), US PG Publication 20220019670 A1.
Regarding claims 2 and 13, Trentini teaches claim 1 teach claim 1 as described above.
Trentini teaches the provided user behavior [Trentini ¶¶0037-0038 0051]; however, Trentini fails to explicitly teach but Moriarty teaches wherein the user is facilitated to validate the provided user behavior. [Moriarty et al 20220019670 ¶¶0016-0018 0063-0065 allows administrators to address automatically issued alerts at a management station. For example at step 416, the digitally-signed code information data set 256 is verified in step 416 by a management application 105 executing on each recipient system (e.g., each of individual endpoint information handling system/s 100 or by management information handling system 252) using a public key from the validated source of step 412]
Trentini teaches all the features of claims 1 and 12 not wherein the user is facilitated to validate the provided user behavior. Trentini teaches a detection of multi-factor authentication and non-multi-factor authentication for risk assessment. Moriarty teaches methods and systems for distribution and integration of threat indicators for information handling systems. Because both Trentini and Moriarty are from the same field of endeavor of vulnerability analysis it would have been obvious to one skilled in the art before the effective filing date of the claimed invention was made to try the optional management application of the host to take automatic preventative actions and/or issue alerts regarding the detection, as well as verify expected behavior patterns and indicators of compromise (IoCs) signature [Moriarty ¶¶0030 0045-0048 and 0065-0068].
Regarding claims 3 and 14, Trentini teaches claim 1 teach as described above.
Trentini teaches the report and response engine [Trentini ¶¶0060-0062 usage reported back]; however, Trentini fails to explicitly teach but Moriarty teaches wherein the report and response engine take a necessary action to mitigate the effects of the abnormal user behavior based on the validation of the user. [Moriarty et al 20220019670 ¶¶0066-0067 for identifications of threats or unexpected behaviors; actions may be automatically taken]
Trentini teaches all the features of claims 1 and 12 not wherein the user is facilitated to validate the provided user behavior. Trentini teaches a detection of multi-factor authentication and non-multi-factor authentication for risk assessment. Moriarty teaches methods and systems for distribution and integration of threat indicators for information handling systems. Because both Trentini and Moriarty are from the same field of endeavor of vulnerability analysis it would have been obvious to one skilled in the art before the effective filing date of the claimed invention was made to try the optional management application of the host to take automatic preventative actions and/or issue alerts regarding the detection, as well as verify expected behavior patterns and indicators of compromise (IoCs) signature [Moriarty ¶¶0030 0045-0048 and 0065-0068].
Regarding currently amended claims 4 and 14, Trentini teaches claim 1 as described above.
Trentini teaches the report and response engine [Trentini ¶¶0060-0062 usage reported back]; however, Trentini fails to explicitly teach but Moriarty teaches wherein the report and response engine automatically take a necessary action to mitigate the effects of the abnormal user behavior [[if]] in response to magnitude of associated threat [[is]] being more than a pre-defined threshold. [Moriarty et al 20220019670 ¶¶0009 0016 management station automates alerts and/or take one or more automatic predetermined actions in real time]
Trentini teaches all the features of claims 1 and 12 not wherein the report and response engine automatically take a necessary action to mitigate the effects of the abnormal user behavior [[if]] in response to magnitude of associated threat [[is]] being more than a pre-defined threshold. Trentini teaches a detection of multi-factor authentication and non-multi-factor authentication for risk assessment. Moriarty teaches methods and systems for distribution and integration of threat indicators for information handling systems. Because both Trentini and Moriarty are from the same field of endeavor of vulnerability analysis it would have been obvious to one skilled in the art before the effective filing date of the claimed invention was made to try the optional management application of the host to take automatic preventative actions and/or issue alerts regarding the detection, as well as verify expected behavior patterns and indicators of compromise (IoCs) signature [Moriarty ¶¶0030 0045-0048 and 0065-0068].
Regarding claims 6 and 15, Trentini teaches claim 1 as described above.
Trentini teaches requests and responses [See Trentini ¶¶0040-0041]; however, Trentini fails to explicitly teach but Moriarty teaches wherein the requests and responses correspond to one or more API calls made by at least one of: one or more users and services. [Moriarty ¶0044 association steps such as the expected behaviors of port, protocol, IP address connections, application programming interface (API) and system component interactions].
Trentini teaches all the features of claims 1 and 12 not wherein the requests and responses correspond to one or more API calls made by at least one of: one or more users and services. Trentini teaches a detection of multi-factor authentication and non-multi-factor authentication for risk assessment. Moriarty teaches methods and systems for distribution and integration of threat indicators for information handling systems. Because both Trentini and Moriarty are from the same field of endeavor of vulnerability analysis it would have been obvious to one skilled in the art before the effective filing date of the claimed invention was made to try the optional management application of the host to take automatic preventative actions and/or issue alerts regarding the detection, as well as verify expected behavior patterns and indicators of compromise (IoCs) signature [Moriarty ¶¶0030 0045-0048 and 0065-0068].
Regarding claims 7 and 16, Trentini teaches claim 1 teach as described above.
Trentini teaches requests and responses [See Trentini ¶¶0040-0041]; however, Trentini fails to explicitly teach but Moriarty teaches wherein the one or more API calls includes at least one of: initial authentication, authorization, and one or more Hyper Text Transfer Protocol (HTTP) requests and responses in the login session. [See Moriarty ¶0044 application requests].
Trentini teaches all the features of claims 1 and 12 not wherein the one or more API calls includes at least one of: initial authentication, authorization, and one or more Hyper Text Transfer Protocol (HTTP) requests and responses in the login session. Trentini teaches a detection of multi-factor authentication and non-multi-factor authentication for risk assessment. Moriarty teaches methods and systems for distribution and integration of threat indicators for information handling systems. Because both Trentini and Moriarty are from the same field of endeavor of vulnerability analysis it would have been obvious to one skilled in the art before the effective filing date of the claimed invention was made to try the optional management application of the host to take automatic preventative actions and/or issue alerts regarding the detection, as well as verify expected behavior patterns and indicators of compromise (IoCs) signature [Moriarty ¶¶0030 0045-0048 and 0065-0068].
Regarding claims 8 and 17, Trentini teaches claim 1 as described above.
Trentini teaches wherein the login behavior includes at least one of: Internet Protocol (IP) address, geolocation, organization, and Autonomous System Number (ASN) of the origin where a user comes from. [Trentini ¶0051 MFA login signatures from signature calculation engine 114 may be unique due to geolocation of users, application, and MFA authentication servers]
Regarding claims 9 and 18, Trentini teaches claim 1 as described above.
Trentini teaches wherein the API request content and behavior includes at least one of: API endpoints and a time-series pattern a user accesses different APIs during a particular login session. [Trentini ¶0049 DNS request being made by the client just prior to the loading of web-based login page contains a unique hostname…many disparate endpoints]
Regarding claims 10 and 19, Trentini teaches claim 1 as described above.
Trentini teaches wherein the API object accessing content and behavior includes all object types and object values that a user accesses during a particular login session. [Trentini ¶0049 both MFA and Non-MFA logons can be generated in a laboratory setting representing natural human behavior and a predetermined sample size; filters may be applied to capture all data inclusive to a type of application detected.]
Regarding claims 11 and 20, Trentini teaches claim 1 as described above.
Trentini teaches wherein the API response content and behavior includes at least one of: a response status code and a body content that a user receives during a particular login session. [Trentini ¶0051 MFA login signatures: user behaviors may affect the uniqueness of the digital signatures, including varied response times of users to receive and enter authentication codes from their mobile device to their personal computing device.]
Claim(s) 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Trentini US PG Publication 20200396243 A1, in view of Abdul Rasheed et al, hereinafter (“Abdul”), US PG Publication 20210271568 A1.
Regarding claims 5 and 15, Trentini teaches claim 1 as described above.
However, Trentini fails to explicitly teach but Abdul Rasheed teaches wherein the collection engine stores the collected requests and responses in a data lake for detailed analysis at any point of time [Abdul ¶0040 the request 162 may include one or more criteria that the data retrieval module 116 may use to query the data lake 120A for the requested data view 164. As non-limiting examples, the parameters in the request 162 may include a point-in-time for which to retrieve data, a time period for which to retrieve data, an identifier of the organization for which to retrieve data, an identifier of the data lake 120 from which to retrieve data, authentication or authorization information (e.g., a token, credentials, etc.) associated with the organization or data lake 120].
Trentini teach all the features of claims 1-4, 6-14, and 16-20 not wherein the collection engine stores the collected requests and responses in a data lake for detailed analysis at any point of time. Abdul teaches a cloud-based service may then store a logical backup of the first data source in the data lake and, in response to a query from a data warehousing system, the cloud-based service may retrieve a particular view of the backup data from the data lake and provide it to the data warehousing system. Because Abdul teaches a data lake it would have been obvious to one skilled in the art before the effective filing date of the claimed invention was made to combine the use of the signature calculation engine 114 functionality to map features of the reference model based on a machine learning (ML) model to determine risks of aggregated user login sessions as taught by Trentini to monitor the network flow traffic produced by user logins in the with data lake 120 from which to retrieve data of Abdul [Abdul ¶¶0040].
Conclusion
THIS ACTION IS MADE FINAL. 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 SAKINAH W TAYLOR whose telephone number is (571)270-0682. The examiner can normally be reached Monday-Friday, 10:45a-6:45p.
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, CATHERINE THIAW can be reached at 571-270-1138. 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.
SAKINAH WHITE-TAYLOR
Primary Examiner
Art Unit 2407
/Sakinah White-Taylor/Primary Examiner, Art Unit 2407
Prosecution Insights