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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 29 April 2026 has been entered.
Priority
This application is a continuation of US S.N. 16/702,395 with a filing date of 03 December 2019. Therefore, the effective filing date of the claims is 03 December 2019.
Response to Arguments
Applicant’s arguments, see pages 9-10, filed 28 April 2026, with respect to the rejection(s) of claim(s) 21, 28, and 35 under 35 U.S.C. 103 have been fully considered and are persuasive in light of the new claim amendments. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Mattson et al. (US 2017/0237766 A1), Tarkkala et al. (US 2007/0011453 A1), Wardman et al. (US 2020/0201981 A1), and Pike (US 2016/0212139 A1) for claim 21, and Mattson et al. (US 2017/0237766 A1), Tarkkala et al. (US 2007/0011453 A1), Wardman et al. (US 2020/0201981 A1), Pike (US 2016/0212139 A1), and Bartholomay et al. (US 2014/0137188 A1) for claims 28 and 35.
See the 35 U.S.C. 103 section below for a detailed analysis.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 28-40 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 28, line 4—“cause the client computer to:” with lines 17-20—"sandbox user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different proof of work values” was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
The specification, at multiple points, e.g., Paragraphs 17, 22, 26, and 64, discloses that the trust server performs an action, where the action may comprise sandboxing user interactions. The specification does not disclose that the client computer has anything to do with the sandboxing of the user interactions and the sandboxing of the user interactions by the client computer would not be an inherent procedure. Therefore, claim 28 fails to comply with the written description requirement.
Claim 35 includes similar language and is similarly analyzed.
Claims 29-34 and 36-40 are additionally rejected for being dependent on at least one rejected base claim.
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.
Claims 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Mattson et al. (US 2017/0237766 A1) in view of Tarkkala et al. (US 2007/0011453 A1) in view of Wardman et al. (US 2020/0201981 A1) and further in view of Pike (US 2016/0212139 A1).
Regarding claim 21, Mattson teaches a method comprising:
receiving, at a client computer, e.g., client device 102 (Fig. 1, el. 102), a work function, e.g., In step 11, security server computer 104 serves code to client device 102, wherein the served code may include code for implementing the selected countermeasures, such as proof of work code, code to monitor to the execution of the origin server computer system code to ensure it is not being interfered with by malicious code, or other countermeasures (Fig. 1, el. 11, 104; Para. 112); in step 426, the intermediary computer serves the content and one or more countermeasures to the client computer, and logs the results or signals of the observations of the client computer (Fig. 4, el. 426; Para. 160); in step 3, security server computer 104 serves the tests to client device 102 (Fig. 1, el. 3; Para. 101); in step 408, the security intermediary server computer serves the selected tests and the requested content to the requesting client computer (Fig. 4, el. 408; Para. 151);
executing a particular session on the client computer, wherein the particular session calculate different proof of work values repeatedly by processing different inputs using the work function, the different inputs being received from a service connected to the particular session…, e.g., executing countermeasures at the client computer and sending the results to the security server, wherein the process of selecting and sending countermeasures may be repeated each time the client device makes a request (Para. 113, 128, 129); one or more additional countermeasures can be sent with subsequently requested content (Para. 114); wherein the countermeasures are Proof of Work code and may be associated with a network configuration, device, browser, user, malware, attack, website, content, or one or more characteristics of the client computer (Para. 66, 88, 89, 112); a hash generating function (Para. 79);
sending the different proof of work values to a trust server, e.g., security server computer 104 (Fig. 1, el. 104); executing countermeasures at the client computer and sending the results to the security server, wherein the process of selecting and sending countermeasures may be repeated each time the client device makes a request (Para. 113, 128, 129); one or more additional countermeasures can be sent with subsequently requested content (Para. 114);
…;
…trust values for the particular session that are determined according to the different proof of work values, e.g., the values of signals received back from a first round of testing may affect whether a second round is performed, where if the first signal(s) indicate that the device is low-risk, then a second round may be avoided, but if they indicate that the device is high-risk, then a second round may be performed (Para. 107).
Mattson does not clearly teach executing different sessions concurrently on the client computer, wherein the different sessions calculate different proof of work values repeatedly by processing different inputs using the work function, the different inputs being received from a service connected to the different sessions, the different inputs being specifically associated with the different sessions and distinguishing individual sessions from other sessions executing concurrently on the client computer;
receiving, from the trust server, feedback for the different sessions;
updating the calculations of the different proof of work values by the different sessions based at least on the feedback;
sandboxing user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different proof of work values; and
wherein the feedback varies resource utilization for respective sessions by increasing resource utilization by relatively less trustworthy sessions and decreasing resource utilization by relatively more trustworthy sessions.
Tarkkala teaches …wherein the particular session calculate…proof of work value…by processing different inputs using the work function, the different inputs being received from a service connected to the particular session, the different inputs being specifically associated with the particular session and distinguishing individual sessions from other sessions…on the client computer, e.g., receiving, by a verifier V, the proof-of-work P(w)-proof of work value- and the input sets M and A from the prover (Para. 120, 121); wherein the prover computes a bitstring s as a result of a pseudo-random function h-work function- being applied on the created data set A-particular inputs-, applies a mapping function m-work function- for mapping an arbitrary bitstring to a problem instance, solves the problem instance, and generates the proof-of-work for the solving of the problem instance (Para. 116, 117, 119); wherein the created data set A may include an identifier for the prover P, an identifier for the verifier V, a salt S_1, and auxiliary data such as a timestamp and/or a message to be sent to verifier V (Para. 113); prover P derives a computationally hard problem from some set identifying a session q between prover P and verifier V (Para. 134).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson to include the different inputs being received from a service connected to the particular session, the different inputs being specifically associated with the particular session and distinguishing individual sessions from other sessions on the client computer, using the known method of computing, by the prover, a bitstring s as a result of a pseudo-random function h being applied on the created data set A, applying a mapping function m for mapping an arbitrary bitstring to a problem instance, solving the problem instance, and generating the proof-of-work for the solving of the problem instance, as taught by Tarkkala, in combination with the Proof of Work system of Mattson, for the purpose of establishing a trusted relationship between unknown communication parties in whatever environment with a respective architecture, (Tarkkala-Para. 109), while also ensuring that the proof-of-work is sufficiently fresh (Tarkkala-Para. 132).
Mattson in view of Tarkkala does not clearly teach executing different sessions concurrently on the client computer, wherein the different sessions calculate different proof of work values repeatedly by processing different inputs using the work function, the different inputs being received from a service connected to the different sessions, the different inputs being specifically associated with the different sessions and distinguishing individual sessions from other sessions executing concurrently on the client computer;
receiving, from the trust server, feedback for the different sessions; and
updating the calculations of the different proof of work values by the different sessions based at least on the feedback;
sandboxing user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different proof of work values; and
wherein the feedback varies resource utilization for respective sessions by increasing resource utilization by relatively less trustworthy sessions and decreasing resource utilization by relatively more trustworthy sessions.
Wardman teaches receiving, at a client computer, e.g., client system 102 (Fig. 1, el. 102), a work function, e.g., once it receives the challenge problem 120, client system 102 may generate a proposed solution 124 by executing program code to solve the challenge problem 120, wherein this program code may be provided to client system 102 (Fig. 1, el. 120, 124; Para. 30);
executing different sessions concurrently on the client computer, wherein the different sessions calculate different proof of work values repeatedly by processing different inputs using the work function, the different inputs being received from a service, e.g., service 112 (Fig. 1, el. 112), connected to the different sessions, the different inputs being specifically associated with the different sessions and distinguishing individual sessions from other sessions executing concurrently on the client computer, e.g., computer system 352 is running multiple VMs 358 simultaneously, wherein this may allow a malicious third-party to scale their attacks, attempting to access the service 112 using the multiple emulated computer systems at the same time, wherein each of the VMs 358 may be configured to attempt to access the same account (e.g., user account 315) with the same service (e.g., service 112) (Fig. 3B, el. 352, 358; Para. 53);
server computer system 110 may select a challenge problem 120 and send it to the VM 358A, and once VM 358A generates a proposed solution 124 and provides it to the server computer system 110, system 110 may compare the performance of the challenge problem 120 by VM 358A to the computational performance data 400 (Para. 58);
server computer system 110 may select a challenge problem 120 that has a level of difficulty 122 that is commensurate with the technical capabilities of client system 102, as indicated by the reported technical features, wherein server computer system 110 may select the problem 120 such that the level of difficulty 122 increases as the reported technical capabilities of the client system 102 increase (Para. 28);
given their frequent use for malicious activity, however, the detection of an emulated computer system may trigger server computer system 110 to implement additional authentication or security challenges (Fig. 1, el. 110; Para. 35);
server computer system 110 may instead (or additionally) select multiple challenge problems for client system 102 to solve based on its technical feature (Para. 41);
sending the different proof of work values to a trust server, e.g., server computer system 110 (Figs. 1, 2, el. 110);
Client system 102 may then, at 136, send a challenge response 126, including the proposed solution 124, to the server computer system 110 (Fig. 1, el. 124, 126, 136; Para. 30);
receiving, from the trust server, feedback for the different sessions, e.g., given their frequent use for malicious activity, however, the detection of an emulated computer system may trigger server computer system 110 to implement additional authentication or security challenges (Fig. 1, el. 110; Para. 35);
server computer system 110 may instead (or additionally) select multiple challenge problems for client system 102 to solve based on its technical feature (Para. 41);
server computer system 110 may send the client system 102 one or more additional challenge problems once the server computer system determines that the client system 102 is an emulated computer system (Para. 46); and
updating the calculations of the different proof of work values by the different sessions based at least on the feedback, e.g., server computer system 110 may select a challenge problem 120 and send it to the VM 358A, and once VM 358A generates a proposed solution 124 and provides it to the server computer system 110, system 110 may compare the performance of the challenge problem 120 by VM 358A to the computational performance data 400 (Para. 58);
server computer system 110 may instead (or additionally) select multiple challenge problems for client system 102 to solve based on its technical feature (Para. 41);
server computer system 110 may send the client system 102 one or more additional challenge problems once the server computer system determines that the client system 102 is an emulated computer system (Para. 46);
…trust values for the different sessions that are determined according to the different proof of work values, e.g., server computer system 110 may select one or more challenge problems for the client system 102 to solve, and authentication module 116 may determine whether to authenticate the client system 102 based on its performance on the selected challenge problem(s) (Para. 25),
wherein the feedback varies resource utilization for respective sessions by increasing resource utilization by relatively less trustworthy sessions and decreasing resource utilization by relatively more trustworthy sessions, e.g., the determination that a client system 102 is an emulated system may not, by itself, result in the requesting user being denied access to service 112, and instead, detection that the client system is an emulated computer system may instead trigger additional authentication operations to be performed (Para. 25);
given their frequent use for malicious activity, however, the detection of an emulated computer system may trigger server computer system 110 to implement additional authentication or security challenges (Fig. 1, el. 110; Para. 35);
after determining that the client system 102 is a malicious user attempting to access the service 112, server computer system 110 may select additional, computationally intensive challenge problems for the client system 102 to solve, wherein these additional challenge problems may be computationally intensive or unsolvable such that, when it attempts to generate a proposed solution, the client system 102 may be required to perform vast amounts of computational work (Para. 46).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson in view of Tarkkala to include executing different sessions concurrently on the client computer, wherein the different sessions calculate different proof of work values repeatedly by processing different inputs using the work function, the different inputs being received from a service connected to the different sessions, the different inputs being specifically associated with the different sessions and distinguishing individual sessions from other sessions executing concurrently on the client computer; receiving, from the trust server, feedback for the different sessions; and updating the calculations of the different proof of work values by the different sessions based at least on the feedback; trust values for the different sessions that are determined according to the different proof of work values, and wherein the feedback varies resource utilization for respective sessions by increasing resource utilization by relatively less trustworthy sessions and decreasing resource utilization by relatively more trustworthy sessions, using the known method of having a client system with multiple VMs concurrently executing sessions for a service, having each VM solve a challenge problem, and having each VM solve an additional problem based on a determination by the server of whether the VM is an emulated system and whether the emulated system is operated by a malicious user, as taught by Wardman, in combination with the Proof of Work system of Mattson in view of Tarkkala, for the purpose of improving data security for both the web service and its users, thereby improving the functioning of the service as a whole (Wardman-Para. 22).
Mattson in view of Tarkkala in view of Wardman does not clearly teach sandboxing user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different proof of work values.
Pike teaches sandboxing user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different…values, e.g., initially, there are six sessions S1-S6 established with the applications 150, and corresponding connections C1-C6 (Para. 54);
to isolate high risk session S3, the other sessions (S1, S2, S4, S5, S6) can be moved from frontend server 130A to anther frontend server 130B to be protected against the data being compromised by a higher risk session S3 or connection, and the higher risk session time extends beyond what is normally allowed and further security actions are taken against the sessions: analytics are processed against it, packets recorded, deeper monitoring starts, the connection/session are terminated with full source data to trace and track what happened or was happening, and dynamic access control lists (ACLs) are put in place for the higher risk session S3 to be blocked from performing any type of broad search, scan, or download of larger datasets, and connections to databases 140 can also be removed or limited all depending on the risk factor of the session (Para. 55).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson in view of Tarkkala in view of Wardman to include sandboxing user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different proof of work values, using the known method of isolating a high risk session out of a plurality of active sessions, as taught by Pike, in combination with the Proof of Work system of Mattson in view of Mattson in view of Tarkkala in view of Wardman, for the purpose of detecting a hacker or to prevent a hacker from successfully completing a hack by analyzing data from the session (Pike-Para. 34).
Regarding claim 22, Mattson in view of Tarkkala in view of Wardman in view of Pike teaches the method of claim 21, wherein the feedback causes the relatively less trustworthy sessions to perform relatively more complex proof of work calculations than the relatively more trustworthy sessions, e.g., the determination that a client system 102 is an emulated system may not, by itself, result in the requesting user being denied access to service 112, and instead, detection that the client system is an emulated computer system may instead trigger additional authentication operations to be performed (Wardman-Para. 25);
given their frequent use for malicious activity, however, the detection of an emulated computer system may trigger server computer system 110 to implement additional authentication or security challenges (Wardman-Fig. 1, el. 110; Para. 35);
after determining that the client system 102 is a malicious user attempting to access the service 112, server computer system 110 may select additional, computationally intensive challenge problems for the client system 102 to solve, wherein these additional challenge problems may be computationally intensive or unsolvable such that, when it attempts to generate a proposed solution, the client system 102 may be required to perform vast amounts of computational work (Wardman-Para. 46).
Regarding claim 23, Mattson in view of Tarkkala in view of Wardman in view of Pike teaches the method of claim 21, wherein the feedback causes the relatively less trustworthy sessions to compute proof of work values more frequently than the relatively more trustworthy sessions, e.g., server computer system 110 may instead (or additionally) select multiple challenge problems for client system 102 to solve based on its technical feature, and server computer system 110 may select the challenge problem 120 based on other factors, such as those indicative of a level of risk associated with the access request (Wardman-Para. 41);
after determining that the client system 102 is a malicious user attempting to access the service 112, server computer system 110 may select additional, computationally intensive challenge problems for the client system 102 to solve, wherein these additional challenge problems may be computationally intensive or unsolvable such that, when it attempts to generate a proposed solution, the client system 102 may be required to perform vast amounts of computational work (Wardman-Para. 46).
Claims 25 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Mattson in view of Tarkkala in view of Wardman in view of Pike and further in view of Bartolucci et al. (US 2020/0389292 A1).
Regarding claim 25, Mattson in view of Tarkkala in view of Wardman in view of Pike teaches the method of claim 21.
Mattson in view of Tarkkala in view of Wardman in view of Pike does not clearly teach wherein the work function is a cryptocurrency mining work function.
Bartolucci teaches wherein the work function is a cryptocurrency mining work function, e.g., the proof-of-work blockchain may require miners to solve a cryptographic problem, wherein in Bitcoin, the miners 104 find a nonce such that a block header hashes, with SHA-256, to a number that is less than a value defined by the current difficultly, wherein the hashing power required for the proof-of-work algorithm means that a transaction is considered practically irreversible after a certain number of blocks have been mined on top of it (Fig. 1, el. 104; Para. 65).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson in view of Tarkkala in view of Wardman in view of Pike to include wherein the work function is a cryptocurrency mining work function, using the known method of utilizing miners to compute hashes for a proof-of-work blockchain, as taught by Bartolucci, in combination with the Proof of Work system of Mattson in view of Tarkkala in view of Wardman in view of Pike, for the purpose of controlling the locking/unlocking of resources on a blockchain, which provides enhanced security for the user (Bartolucci-Para. 17).
Regarding claim 26, Mattson in view of Tarkkala in view of Wardman in view of Pike teaches the method of claim 21.
Mattson further teaches wherein the work function computes hashes…, the different proof of work values comprising the hashes, e.g., the countermeasure may be a proof of work challenge, such as a hash generating function (Para. 79).
Mattson in view of Tarkkala in view of Wardman in view of Pike does not clearly teach wherein the work function computes hashes according to a blockchain.
Bartolucci teaches wherein the work function computes hashes according to a blockchain, the different proof of work values comprising the hashes, e.g., the proof-of-work blockchain may require miners to solve a cryptographic problem, wherein in Bitcoin, the miners 104 find a nonce such that a block header hashes, with SHA-256, to a number that is less than a value defined by the current difficultly, wherein the hashing power required for the proof-of-work algorithm means that a transaction is considered practically irreversible after a certain number of blocks have been mined on top of it (Fig. 1, el. 104; Para. 65).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson in view of Tarkkala in view of Wardman in view of Pike to include wherein the work function computes hashes according to a blockchain, the different proof of work values comprising the hashes, using the known method of utilizing miners to compute hashes for a proof-of-work blockchain, as taught by Bartolucci, in combination with the Proof of Work system of Mattson in view of Tarkkala in view of Wardman in view of Pike, for the purpose of controlling the locking/unlocking of resources on a blockchain, which provides enhanced security for the user (Bartolucci-Para. 17).
Claim 27 is rejected under 35 U.S.C. 103 as being unpatentable over Mattson in view of Tarkkala in view of Wardman in view of Pike and further in view of Colangelo (US 2019/0303448).
Regarding claim 27, Mattson in view of Tarkkala in view of Wardman in view of Pike teaches the method of claim 21.
Mattson in view of Tarkkala in view of Wardman in view of Pike does not clearly teach wherein the trust server selectively increases a view count for a video based at least on the calculations.
Colango teaches wherein the trust server, e.g., media embedding system 130 (Fig. 4, el. 130), selectively increases a view count for a video based at least on the calculations, e.g., the media embedding system 130 may report 422 a content item view to the content provider 120, wherein the media embedding system 130 analyzes 422 the event data to determine whether the user input was provided by a person or a computer-implemented bot, and thereby determine if the content item was viewed by a person, wherein if the media embedding system 130 determines the user to be a person based on the behavioral information, the media embedding system 130 may report 422 a view of a media content item to the content provider 120, and wherein if the media embedding system 130 determines the user is likely a bot, the view may not be reported to the content provider 120 (Fig. 4, el. 120, 130, 422; Para. 73).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson in view of Tarkkala in view of Wardman in view of Pike to include wherein the trust server selectively increases a view count for a video based at least on the calculations, using the known method of tracking the number of views of media content items, determining whether user input was provided by a person or a bot, and reporting/not reporting the view based on the determination, as taught by Colangelo, in combination with the method of frustrating ratings or results manipulation using Proof of Work of Mattson in view of Tarkkala in view of Wardman in view of Pike, for the purpose of obtaining more accurate viewing statistics.
Claims 28-30 and 35-37 are rejected under 35 U.S.C. 103 as being unpatentable over Mattson in view of Tarkkala in view of Wardman in view of Pike and further in view of Bartholomay et al. (US 2014/0137188 A1).
Regarding claim 28, Mattson teaches a client computer, e.g., client device 102 (Fig. 1, el. 102), comprising:
a processor, e.g., processor 710 (Fig. 7, el. 710); and
a memory, e.g., memory 720/storage device 730 (Fig. 7, el. 720, 730), having computer-executable instructions stored thereupon which, when executed by the processor, cause the client computer to:
receive a work function, e.g., In step 11, security server computer 104 serves code to client device 102, wherein the served code may include code for implementing the selected countermeasures, such as proof of work code, code to monitor to the execution of the origin server computer system code to ensure it is not being interfered with by malicious code, or other countermeasures (Fig. 1, el. 11, 104; Para. 112); in step 426, the intermediary computer serves the content and one or more countermeasures to the client computer, and logs the results or signals of the observations of the client computer (Fig. 4, el. 426; Para. 160); in step 3, security server computer 104 serves the tests to client device 102 (Fig. 1, el. 3; Para. 101); in step 408, the security intermediary server computer serves the selected tests and the requested content to the requesting client computer (Fig. 4, el. 408; Para. 151);
execute a particular session on the client computer, wherein the particular session calculate different proof of work values repeatedly by processing different inputs using the work function, the different inputs being received from a service connected to the particular session…, e.g., executing countermeasures at the client computer and sending the results to the security server, wherein the process of selecting and sending countermeasures may be repeated each time the client device makes a request (Para. 113, 128, 129); one or more additional countermeasures can be sent with subsequently requested content (Para. 114); wherein the countermeasures are Proof of Work code and may be associated with a network configuration, device, browser, user, malware, attack, website, content, or one or more characteristics of the client computer (Para. 66, 88, 89, 112); a hash generating function (Para. 79);
send the different proof of work values to a trust server, e.g., security server computer 104 (Fig. 1, el. 104); executing countermeasures at the client computer and sending the results to the security server, wherein the process of selecting and sending countermeasures may be repeated each time the client device makes a request (Para. 113, 128, 129); one or more additional countermeasures can be sent with subsequently requested content (Para. 114);
…;
…trust values for the particular session that are determined according to the different proof of work values, e.g., the values of signals received back from a first round of testing may affect whether a second round is performed, where if the first signal(s) indicate that the device is low-risk, then a second round may be avoided, but if they indicate that the device is high-risk, then a second round may be performed (Para. 107).
Mattson does not clearly teach to cause the client computer to: execute different sessions concurrently on the client computer, wherein the different sessions calculate different proof of work values repeatedly by processing different inputs using the work function, the different inputs being received from a service connected to the different sessions, the different inputs being specifically associated with the different sessions and distinguishing individual sessions from other sessions executing concurrently on the client computer;
receive, from the trust server, feedback for the different sessions; and
update the calculations of the different proof of work values by the different sessions based at least on the feedback;
sandbox user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different proof of work values,
wherein the feedback varies resource utilization for respective sessions by increasing resource utilization by relatively less trustworthy sessions and decreasing resource utilization by relatively more trustworthy sessions.
Tarkkala teaches to: …wherein the particular session calculate…proof of work value…by processing different inputs using the work function, the different inputs being received from a service connected to the particular session, the different inputs being specifically associated with the particular session and distinguishing individual sessions from other sessions…on the client computer, e.g., receiving, by a verifier V, the proof-of-work P(w)-proof of work value- and the input sets M and A from the prover (Para. 120, 121); wherein the prover computes a bitstring s as a result of a pseudo-random function h-work function- being applied on the created data set A-particular inputs-, applies a mapping function m-work function- for mapping an arbitrary bitstring to a problem instance, solves the problem instance, and generates the proof-of-work for the solving of the problem instance (Para. 116, 117, 119); wherein the created data set A may include an identifier for the prover P, an identifier for the verifier V, a salt S_1, and auxiliary data such as a timestamp and/or a message to be sent to verifier V (Para. 113); prover P derives a computationally hard problem from some set identifying a session q between prover P and verifier V (Para. 134).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson to include the different inputs being received from a service connected to the particular session, the different inputs being specifically associated with the particular session and distinguishing individual sessions from other sessions on the client computer, using the known method of computing, by the prover, a bitstring s as a result of a pseudo-random function h being applied on the created data set A, applying a mapping function m for mapping an arbitrary bitstring to a problem instance, solving the problem instance, and generating the proof-of-work for the solving of the problem instance, as taught by Tarkkala, in combination with the Proof of Work system of Mattson, for the purpose of establishing a trusted relationship between unknown communication parties in whatever environment with a respective architecture, (Tarkkala-Para. 109), while also ensuring that the proof-of-work is sufficiently fresh (Tarkkala-Para. 132).
Mattson in view of Tarkkala does not clearly teach to cause the client computer to: execute different sessions concurrently on the client computer, wherein the different sessions calculate different proof of work values repeatedly by processing different inputs using the work function, the different inputs being received from a service connected to the different sessions, the different inputs being specifically associated with the different sessions and distinguishing individual sessions from other sessions executing concurrently on the client computer;
receive, from the trust server, feedback for the different sessions; and
update the calculations of the different proof of work values by the different sessions based at least on the feedback;
sandbox user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different proof of work values,
wherein the feedback varies resource utilization for respective sessions by increasing resource utilization by relatively less trustworthy sessions and decreasing resource utilization by relatively more trustworthy sessions.
Wardman teaches to: receive a work function, e.g., once it receives the challenge problem 120, client system 102 may generate a proposed solution 124 by executing program code to solve the challenge problem 120, wherein this program code may be provided to client system 102 (Fig. 1, el. 120, 124; Para. 30);
execute different sessions concurrently on the client computer, wherein the different sessions calculate different proof of work values repeatedly by processing different inputs using the work function, the different inputs being received from a service, e.g., service 112 (Fig. 1, el. 112), connected to the different sessions, the different inputs being specifically associated with the different sessions and distinguishing individual sessions from other sessions executing concurrently on the client computer, e.g., computer system 352 is running multiple VMs 358 simultaneously, wherein this may allow a malicious third-party to scale their attacks, attempting to access the service 112 using the multiple emulated computer systems at the same time, wherein each of the VMs 358 may be configured to attempt to access the same account (e.g., user account 315) with the same service (e.g., service 112) (Fig. 3B, el. 352, 358; Para. 53);
server computer system 110 may select a challenge problem 120 and send it to the VM 358A, and once VM 358A generates a proposed solution 124 and provides it to the server computer system 110, system 110 may compare the performance of the challenge problem 120 by VM 358A to the computational performance data 400 (Para. 58);
server computer system 110 may select a challenge problem 120 that has a level of difficulty 122 that is commensurate with the technical capabilities of client system 102, as indicated by the reported technical features, wherein server computer system 110 may select the problem 120 such that the level of difficulty 122 increases as the reported technical capabilities of the client system 102 increase (Para. 28);
given their frequent use for malicious activity, however, the detection of an emulated computer system may trigger server computer system 110 to implement additional authentication or security challenges (Fig. 1, el. 110; Para. 35);
server computer system 110 may instead (or additionally) select multiple challenge problems for client system 102 to solve based on its technical feature (Para. 41);
send the different proof of work values to a trust server, e.g., server computer system 110 (Figs. 1, 2, el. 110);
Client system 102 may then, at 136, send a challenge response 126, including the proposed solution 124, to the server computer system 110 (Fig. 1, el. 124, 126, 136; Para. 30);
receive, from the trust server, feedback for the different sessions, e.g., given their frequent use for malicious activity, however, the detection of an emulated computer system may trigger server computer system 110 to implement additional authentication or security challenges (Fig. 1, el. 110; Para. 35);
server computer system 110 may instead (or additionally) select multiple challenge problems for client system 102 to solve based on its technical feature (Para. 41);
server computer system 110 may send the client system 102 one or more additional challenge problems once the server computer system determines that the client system 102 is an emulated computer system (Para. 46); and
update the calculations of the different proof of work values by the different sessions based at least on the feedback, e.g., server computer system 110 may select a challenge problem 120 and send it to the VM 358A, and once VM 358A generates a proposed solution 124 and provides it to the server computer system 110, system 110 may compare the performance of the challenge problem 120 by VM 358A to the computational performance data 400 (Para. 58);
server computer system 110 may instead (or additionally) select multiple challenge problems for client system 102 to solve based on its technical feature (Para. 41);
server computer system 110 may send the client system 102 one or more additional challenge problems once the server computer system determines that the client system 102 is an emulated computer system (Para. 46);
…trust values for the different sessions that are determined according to the different proof of work values, e.g., server computer system 110 may select one or more challenge problems for the client system 102 to solve, and authentication module 116 may determine whether to authenticate the client system 102 based on its performance on the selected challenge problem(s) (Para. 25),
wherein the feedback varies resource utilization for respective sessions by increasing resource utilization by relatively less trustworthy sessions and decreasing resource utilization by relatively more trustworthy sessions, e.g., the determination that a client system 102 is an emulated system may not, by itself, result in the requesting user being denied access to service 112, and instead, detection that the client system is an emulated computer system may instead trigger additional authentication operations to be performed (Para. 25);
given their frequent use for malicious activity, however, the detection of an emulated computer system may trigger server computer system 110 to implement additional authentication or security challenges (Fig. 1, el. 110; Para. 35);
after determining that the client system 102 is a malicious user attempting to access the service 112, server computer system 110 may select additional, computationally intensive challenge problems for the client system 102 to solve, wherein these additional challenge problems may be computationally intensive or unsolvable such that, when it attempts to generate a proposed solution, the client system 102 may be required to perform vast amounts of computational work (Para. 46).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson in view of Tarkkala to include to: execute different sessions concurrently on the client computer, wherein the different sessions calculate different proof of work values repeatedly by processing different inputs using the work function, the different inputs being received from a service connected to the different sessions, the different inputs being specifically associated with the different sessions and distinguishing individual sessions from other sessions executing concurrently on the client computer; receive, from the trust server, feedback for the different sessions; and update the calculations of the different proof of work values by the different sessions based at least on the feedback, trust values for the different sessions that are determined according to the different proof of work values, wherein the feedback varies resource utilization for respective sessions by increasing resource utilization by relatively less trustworthy sessions and decreasing resource utilization by relatively more trustworthy sessions, using the known method of having a client system with multiple VMs concurrently executing sessions for a service, having each VM solve a challenge problem, and having each VM solve an additional problem based on a determination by the server of whether the VM is an emulated system and whether the emulated system is operated by a malicious user, as taught by Wardman, in combination with the Proof of Work system of Mattson in view of Tarkkala, for the purpose of improving data security for both the web service and its users, thereby improving the functioning of the service as a whole (Wardman-Para. 22).
Mattson in view of Tarkkala in view of Wardman does not clearly teach to cause the client computer to: sandbox user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different proof of work values.
Pike teaches …the client computer…, e.g., client (Fig. 1, el. 105A, 105B);
Network 110 can include wireless networks (Fig. 1, el. 110; Para. 38);
the session/connection manager module 152 can be located elsewhere in the system, such as in the router 115, firewall 120, load balancer 125, or backend server 135 (Fig. 1, el. 115, 120, 125, 135, 152; Para. 39);
FIG. 8 is a flowchart of a method for session/connection splitting security, according to an embodiment. The flowchart can represent operations of the session/connection manager module 152 that typically occur after the flowchart of FIG. 7 (Fig. 8; Para. 73);
in step 870, if the session/connection duration has reached the intermediate security time limit, security is increased to security tier D 208, and during security tier D 208, advanced security actions defined by a set of advanced security rules are triggered and applied to the application session/connection, where the advanced security actions are applied by executing advanced security actions against the application session/connection (Fig. 8, el. 870; Para. 78);
to: sandbox user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different…values, e.g., initially, there are six sessions S1-S6 established with the applications 150, and corresponding connections C1-C6 (Para. 54);
to isolate high risk session S3, the other sessions (S1, S2, S4, S5, S6) can be moved from frontend server 130A to anther frontend server 130B to be protected against the data being compromised by a higher risk session S3 or connection, and the higher risk session time extends beyond what is normally allowed and further security actions are taken against the sessions: analytics are processed against it, packets recorded, deeper monitoring starts, the connection/session are terminated with full source data to trace and track what happened or was happening, and dynamic access control lists (ACLs) are put in place for the higher risk session S3 to be blocked from performing any type of broad search, scan, or download of larger datasets, and connections to databases 140 can also be removed or limited all depending on the risk factor of the session (Para. 55).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson in view of Tarkkala in view of Wardman to: sandbox user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different proof of work values, using the known method of isolating a high risk session out of a plurality of active sessions, as taught by Pike, in combination with the Proof of Work system of Mattson in view of Mattson in view of Tarkkala in view of Wardman, for the purpose of detecting a hacker or to prevent a hacker from successfully completing a hack by analyzing data from the session (Pike-Para. 34).
Mattson in view of Tarkkala in view of Wardman in view of Pike does not clearly teach to cause the client computer to: sandbox user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different proof of work values.
Bartholomay teaches a WiFi Access point function and WiFi router function can be integrated into an end user device (Para. 363).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson in view of Tarkkala in view of Wardman in view of Pike to cause the client computer to: sandbox user interactions in less than all of the different sessions executing concurrently on the client computer based at least on trust values for the different sessions that are determined according to the different proof of work values, using the known method of integrating a router function into the user device, as taught by Bartholomay, in combination with the teachings of Mattson in view of Mattson in view of Tarkkala in view of Wardman in view of Pike where the session manager function may be integrated within the router, for the purpose of enabling the session sandboxing to be performed at the client device, thereby providing more control over what data is received by and sent by the client device.
Regarding claim 29, Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay teaches the client computer of claim 28, wherein the feedback causes the relatively less trustworthy sessions to perform relatively more complex proof of work calculations than the relatively more trustworthy sessions, e.g., the determination that a client system 102 is an emulated system may not, by itself, result in the requesting user being denied access to service 112, and instead, detection that the client system is an emulated computer system may instead trigger additional authentication operations to be performed (Wardman-Para. 25);
given their frequent use for malicious activity, however, the detection of an emulated computer system may trigger server computer system 110 to implement additional authentication or security challenges (Wardman-Fig. 1, el. 110; Para. 35);
after determining that the client system 102 is a malicious user attempting to access the service 112, server computer system 110 may select additional, computationally intensive challenge problems for the client system 102 to solve, wherein these additional challenge problems may be computationally intensive or unsolvable such that, when it attempts to generate a proposed solution, the client system 102 may be required to perform vast amounts of computational work (Wardman-Para. 46).
Regarding claim 30, Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay teaches the client computer of claim 28, wherein the feedback causes the relatively less trustworthy sessions to compute proof of work values more frequently than the relatively more trustworthy sessions, e.g., server computer system 110 may instead (or additionally) select multiple challenge problems for client system 102 to solve based on its technical feature, and server computer system 110 may select the challenge problem 120 based on other factors, such as those indicative of a level of risk associated with the access request (Wardman-Para. 41);
after determining that the client system 102 is a malicious user attempting to access the service 112, server computer system 110 may select additional, computationally intensive challenge problems for the client system 102 to solve, wherein these additional challenge problems may be computationally intensive or unsolvable such that, when it attempts to generate a proposed solution, the client system 102 may be required to perform vast amounts of computational work (Wardman-Para. 46).
Regarding claim 35, the claim is analyzed with respect to claim 28.
Regarding claim 36, the claim is analyzed with respect to claim 29.
Regarding claim 37, the claim is analyzed with respect to claim 30.
Claims 32, 33, 39, and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay and further in view of Bartolucci.
Regarding claim 32, Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay teaches the client computer of claim 28.
Mattson in view of Tarkkala in view of Wardman in view of Wardman in view of Pike in view of Bartholomay does not clearly teach wherein the work function is a cryptocurrency mining work function.
Bartolucci teaches wherein the work function is a cryptocurrency mining work function, e.g., the proof-of-work blockchain may require miners to solve a cryptographic problem, wherein in Bitcoin, the miners 104 find a nonce such that a block header hashes, with SHA-256, to a number that is less than a value defined by the current difficultly, wherein the hashing power required for the proof-of-work algorithm means that a transaction is considered practically irreversible after a certain number of blocks have been mined on top of it (Fig. 1, el. 104; Para. 65).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay to include wherein the work function is a cryptocurrency mining work function, using the known method of utilizing miners to compute hashes for a proof-of-work blockchain, as taught by Bartolucci, in combination with the Proof of Work system of Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay, for the purpose of controlling the locking/unlocking of resources on a blockchain, which provides enhanced security for the user (Bartolucci-Para. 17).
Regarding claim 33, Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay teaches the client computer of claim 28.
Mattson further teaches wherein the work function computes hashes…, the different proof of work values comprising the hashes, e.g., the countermeasure may be a proof of work challenge, such as a hash generating function (Para. 79).
Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay does not clearly teach wherein the work function computes hashes according to a blockchain.
Bartolucci teaches wherein the work function computes hashes according to a blockchain, the different proof of work values comprising the hashes, e.g., the proof-of-work blockchain may require miners to solve a cryptographic problem, wherein in Bitcoin, the miners 104 find a nonce such that a block header hashes, with SHA-256, to a number that is less than a value defined by the current difficultly, wherein the hashing power required for the proof-of-work algorithm means that a transaction is considered practically irreversible after a certain number of blocks have been mined on top of it (Fig. 1, el. 104; Para. 65).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay to include wherein the work function computes hashes according to a blockchain, the different proof of work values comprising the hashes, using the known method of utilizing miners to compute hashes for a proof-of-work blockchain, as taught by Bartolucci, in combination with the Proof of Work system of Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay, for the purpose of controlling the locking/unlocking of resources on a blockchain, which provides enhanced security for the user (Bartolucci-Para. 17).
Regarding claim 39, the claim is analyzed with respect to claim 32.
Regarding claim 40, the claim is analyzed with respect to claim 33.
Claim 34 is rejected under 35 U.S.C. 103 as being unpatentable over Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay and further in view of Colangelo (US 2019/0303448).
Regarding claim 34, Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay teaches the client computer of claim 28.
Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay does not clearly teach wherein the trust server selectively increases a view count for a video based at least on the calculations.
Colango teaches wherein the trust server, e.g., media embedding system 130 (Fig. 4, el. 130), selectively increases a view count for a video based at least on the calculations, e.g., the media embedding system 130 may report 422 a content item view to the content provider 120, wherein the media embedding system 130 analyzes 422 the event data to determine whether the user input was provided by a person or a computer-implemented bot, and thereby determine if the content item was viewed by a person, wherein if the media embedding system 130 determines the user to be a person based on the behavioral information, the media embedding system 130 may report 422 a view of a media content item to the content provider 120, and wherein if the media embedding system 130 determines the user is likely a bot, the view may not be reported to the content provider 120 (Fig. 4, el. 120, 130, 422; Para. 73).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay to include wherein the trust server selectively increases a view count for a video based at least on the calculations, using the known method of tracking the number of views of media content items, determining whether user input was provided by a person or a bot, and reporting/not reporting the view based on the determination, as taught by Colangelo, in combination with the method of frustrating ratings or results manipulation using Proof of Work of Mattson in view of Tarkkala in view of Wardman in view of Pike in view of Bartholomay, for the purpose of obtaining more accurate viewing statistics.
Allowable Subject Matter
Claim 24 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claims 31 and 38 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), 1st paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
The prior art of record fails to disclose the combination of features as claimed and arranged by applicant when read in light of the specification. In this case, the allowance subject matter is based on the combination of the limitations in each of claims 24, 31, and 38 and not on any single limitation.
The cited references do not alone or in an obvious combination teach “wherein the different inputs comprise unique user identifiers interleaved with video data streamed by the service to the client computer” of claim 24 in combination with the remaining limitations claim 24.
Claims 31 and 38 include similar limitations and are similarly analyzed.
Mattson et al. (US 2017/0237766 A1) discloses executing countermeasures at the client computer and sending the results to the security server, wherein the process of selecting and sending countermeasures may be repeated each time the client device makes a request (Para. 113, 128, 129).
Tarkkala et al. (US 2007/0011453 A1) discloses the prover computes a bitstring s as a result of a pseudo-random function h-work function- being applied on the created data set A, applies a mapping function m for mapping an arbitrary bitstring to a problem instance, solves the problem instance, and generates the proof-of-work for the solving of the problem instance (Para. 116, 117, 119).
However, the cited references do not alone or in an obvious combination teach “wherein the different inputs comprise unique user identifiers interleaved with video data streamed by the service to the client computer” of claim 24 in combination with the remaining limitations claim 24.
Additional relevant prior art:
Kushwaha et al. (US 10,091,235 B1)—Kushwaha discloses By refusing to perform the Layer 7 DPI and/or sandboxing on computing sessions that pose little risk to the organization and/or its network in this way, security module 112 may be able to improve resource consumption and/or efficiency within the network (Col. 11, lines 38-42).
Meriac (US 2017/0237770 A1)—Meriac discloses mitigating a power-denial of service attack on a first device by a second device (Abstract).
Caragea (US 2019/0068561 A1)—Caragea discloses multiple sessions may be carried out concurrently within a single VM, for example by multiple instances of a browser (as in tabbed browsing), or by distinct applications running at the same time (Para. 70).
Feng et al. (US 2011/0231913 A1)—Feng discloses proof-of-work puzzles prevent an adversary from using a single computer to participate in concurrent ticket purchasing campaigns since solving simultaneous proof-of-work puzzles simply slows down the solution of each rather than providing an advantage (Para. 90).
Juels et al. (US 7,197,639 B1)—Juels discloses a server imposes a task, such as a puzzle, to a client. The input data for the puzzle includes an encrypted version of seed data, wherein the seed data includes information identifying the server, the client, the session, and the date and time the puzzle expires (Col. 17, lines 12-42).
The additional relevant prior art also do not alone or in an obvious combination teach the aforementioned limitations in combination with the remaining limitations of each respective independent claim.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
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, Yin-Chen Shaw can be reached at (571) 272-8878. 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.
04 June 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498
Prosecution Insights