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 Arguments
Applicant’s arguments with respect to claim(s) are rejected claims under 35 USC 103(a) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argued in the remark that detecting a function call made during execution of a smart contract in a virtual machine executing in a user space of a blockchain node, wherein the function call is detected by using function-boundary detection instrumentation in a kernel of an operating system on the blockchain node to identify an entrance or exit of a user-space function in the virtual machine, the user-space function corresponding to a method of the smart contract.
Examiner respectfully disagrees. Guri et al US 2018/0181752 discloses
detecting a function call made during execution of a function in a virtual machine executing in a user space of a database (Par 0063 the computer program that such imported procedures are called. Par 0075 contents of a call stack (e.g., function(s) called) associated with the kernel space (a region of main memory 104 allocated for the kernel of operating system 110, i.e. a virtual machine executing, and 0050 detects, classifies and/or neutralizes the execution of malicious code associated with a computing process executing thereon. And 0060 a procedure call (e.g., GetProcAddress) that identifies the procedure) at the time execution of the malicious code was halted 0086 database ), wherein the function call is detected by using function-boundary detection instrumentation in a kernel of an operating system on the database to identify an entrance or exit of a user-space function in the virtual machine ( 0069 Upon intercepting, i.e. detecting, such procedure calls, runtime protector 122 allows, i.e. function boundary for identify the function is entrance or exit in the call stack, the call to be completed, thereby resulting in the library module(s) being loaded at their intended addresses in main memory 104 ), the user-space function corresponding to a method of the smart contract;
detecting a function call made during execution of a smart contract in a virtual machine executing in a user space of a blockchain node (0075 contents of a call stack (e.g., function(s) called) associated with the kernel space (a region of main memory 104 allocated for the kernel of operating system 110, i.e. a virtual machine executing,) at the time execution of the malicious code was halted 0086 database ), wherein the function call is detected by using function-boundary detection instrumentation in a kernel of an operating system on the blockchain node to identify an entrance or exit of a user-space function in the virtual machine, the user-space function corresponding to a method of the smart contract.
Guri does not explicitly discloses wherein the function call is detected by using function-boundary detection instrumentation in a kernel of an operating system on the blockchain node to identify an entrance or exit of a user-space function in the virtual machine, the user-space function corresponding to a method of the smart contract.
However, Kempf discloses wherein the function call is detected by using function-boundary detection instrumentation in a kernel of an operating system on the blockchain node to identify an entrance or exit of a user-space function in the virtual machine, the user-space function corresponding to a method of the smart contract. (0036 In operation, the first server 122A receives, at operation 1, a call to a function to be performed for a smart contract, i.e. a secure layer, of a blockchain database. In some embodiments, the function to be performed is one of creating the smart contract or performing a transaction operation on the smart contract that was previously created. For example, the smart contract can represent a delegation of rights from a service hosted in the data center 108 to a tenant 102A. In other embodiments, the operations can be any operation, i.e. call to the function, that may result in a blockchain transaction or a block that is recorded, i.e. adding, in the blockchain database 130. Call to a function and the function is performed in the smart contract, this function call operation that is a blockchain transaction that is recorded, i.e. adding, in the blockchain database).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,888,966. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-20 of U.S. Patent include all the limitations of claims of the instant application 16/282959.
Instant application 18/532714
Patent No. 11,888966
1. One or more computer storage media storing computer-useable instructions that, when used by one or more computing devices, cause the one or more computing to perform operations comprising:
detecting a function call associated with one or more methods of a smart contract on a blockchain by identifying an entrance or exit of the function call in a kernel for smart contract execution on the blockchain;
adding the function call to a function call stack storing a plurality of function calls made by execution of the smart contract or a second smart contract;
identifying one or more detected high granularity metrics (HGMs) based on the plurality of function calls in the function call stack;
performing a comparison of the detected HGMs in the function call stack against one or more control rules; and
blocking execution or completion of the function call based on the comparison.
2. The one or more computer storage media of claim 1, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules comprises analyzing the detected HGMs in the function call stack to identify anomalous activity.
3. The one or more computer-storage media of claim 2, wherein analyzing the detected HGMs in the function call stack to identify anomalous activity comprises determining a deviation from one or more historical patterns.
4. The one or more computer storage media of claim 2, wherein analyzing the detected HGMs in the function call stack to identify anomalous activity comprises one or more selected from the following: detecting anomalous latencies in function call chains; detecting anomalous call counts in function call chains; and tracking call patterns to detect cyclic invocations, clustering the call patterns, creating interaction graphs across smart contracts, and analyzing the interaction graphs to identify one or more local anomalies.
5. The one or more computer storage media of claim 1, wherein the one or more control rules comprise one or more selected from the following: one or more white list rules; one or more black list rules; one or more function level dynamic HGM rules; and one or more call graph level HGM rules.
6. The one or more computer storage media of claim 1, wherein the HGMs comprise one or more selected from the following: a programmable metric; a dynamic metric that measures functional properties at an individual function level; a dynamic metric that measures function properties at a call graph level in the function call chains; a dynamic metric that measures function latencies; a dynamic metric that measures function cardinalities; and a dynamic metric that measures function counts.
7. The one or more computer storage media of claim 1, where the one or more HGMs in the function call stack are detected using Function Boundary Tracing (FBT) functionality of an extended Berkeley Packet Filter (eBPF).
8. A computer-implemented method comprising: detecting a function call made by execution of a smart contract on a blockchain by identifying an entrance or exit of the function call in a kernel for smart contract execution on the blockchain; adding the function call to a function call stack storing a plurality of function calls made by execution of the smart contract or a second smart contract; identifying one or more detected high granularity metrics (HGMs) based on the plurality of function calls in the function call stack; performing a comparison of the detected HGMs in the function call stack against one or more control rules; and blocking execution or completion of the function call based on the comparison.
9. The computer-implemented method of claim 8, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules comprises analyzing the detected HGMs in the function call stack to identify anomalous activity.
10. The computer-implemented method of claim 9, wherein analyzing the detected HGMs in the function call stack to identify anomalous activity comprises determining a deviation from one or more historical patterns.
11. The computer-implemented method of claim 9, wherein analyzing the detected HGMs in the function call stack to identify anomalous activity comprises one or more selected from the following: detecting anomalous latencies in function call chains; detecting anomalous call counts in function call chains; and tracking call patterns to detect cyclic invocations, clustering the call patterns, creating interaction graphs across smart contracts, and analyzing the interaction graphs to identify one or more local anomalies.
12. The computer-implemented method of claim 8, wherein the one or more control rules comprise one or more selected from the following: one or more white list rules; one or more black list rules; one or more function level dynamic HGM rules; and one or more call graph level HGM rules.
13. The computer-implemented method of claim 8, wherein the HGMs comprise one or more selected from the following: a programmable metric; a dynamic metric that measures functional properties at an individual function level; a dynamic metric that measures function properties at a call graph level in the function call chains; a dynamic metric that measures function latencies; a dynamic metric that measures function cardinalities; and a dynamic metric that measures function counts.
14. The computer-implemented method of claim 8, where the one or more HGMs in the function call stack are detected using Function Boundary Tracing (FBT) functionality of an extended Berkeley Packet Filter (eBPF).
15. (Currently Amended) A computer system comprising: one or more processors; and one or more computer storage media storing computer-useable instructions that, when used by the one or more processors, cause the one or more processors to perform operations comprising: detecting a function call made by execution of a smart contract on a blockchain by identifying an entrance or exit of the function call in a kernel for smart contract execution on the blockchain; adding the function call to a function call stack storing a plurality of function calls made by execution of the smart contract or a second smart contract; identifying one or more detected high granularity metrics (HGMs) based on the plurality of function calls in the function call stack; performing a comparison of the detected HGMs in the function call stack against one or more control rules; and blocking execution or completion of the function call based on the comparison.
16. The computer system of claim 15, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules comprises analyzing the detected HGMs in the function call stack to identify anomalous activity.
17. The computer system of claim 16, wherein analyzing the detected HGMs in the function call stack to identify anomalous activity comprises determining a deviation from one or more historical patterns.
18. The computer system of claim 16, wherein analyzing the detected HGMs in the function call stack to identify anomalous activity comprises one or more selected from the following: detecting anomalous latencies in function call chains; detecting anomalous call counts in function call chains; and tracking call patterns to detect cyclic invocations, clustering the call patterns, creating interaction graphs across smart contracts, and analyzing the interaction graphs to identify one or more local anomalies.
19. The computer system of claim 15, wherein the one or more control rules comprise one or more selected from the following: one or more white list rules; one or more black list rules; one or more function level dynamic HGM rules; and one or more call graph level HGM rules.
20. The computer system of claim 15, wherein the HGMs comprise one or more selected from the following: a programmable metric; a dynamic metric that measures functional properties at an individual function level; a dynamic metric that measures function properties at a call graph level in the function call chains; a dynamic metric that measures function latencies; a dynamic metric that measures function cardinalities; and a dynamic metric that measures function counts.
1. One or more computer storage medium storing computer-useable instructions that, when used by one or more computing devices, cause the one or more computing to perform operations comprising: detecting a function call associated with one or more methods of a smart contract on a blockchain by identifying an entrance or exit of the function call in a kernel for smart contract execution on the blockchain; adding the function call to a function call stack; identifying one or more detected high granularity metrics (HGMs) in the function call stack; performing a comparison of the detected HGMs in the function call stack against one or more control rules, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules comprises checking the detected HGMs in the function call stack against a set of permitted HGMs; and blocking execution or completion of the function call based on the comparison, wherein execution or completion of the function call is blocked based on determining the function call stack includes one or more detected HGMs that are not permitted under the set of permitted HGMs.
2. The one or more computer storage medium of claim 1, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules further comprises checking the detected HGMs in the function call stack against a set of prohibited HGMs.
3. The one or more computer storage medium of claim 2, wherein the set of prohibited HGMs is based on HGMs generated by execution of one or more smart contracts with known vulnerabilities.
4. The one or more computer storage medium of claim 2, wherein execution or completion of the function call is blocked based on determining the function call stack includes one or more detected HGMs that are not permitted under the set of prohibited HGMs.
5. The one or more computer storage medium of claim 1, wherein the set of permitted HGMs is based on HGMs generated by execution of one or more known acceptable smart contracts.
6. The one or more computer storage medium of claim 1, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules further comprises analyzing the detected HGMs in the function call stack to identify anomalous activity.
7. The one or more computer storage medium of claim 6, wherein the analyzing the detected HGMs in the function call stack to identify anomalous activity comprises one or more selected from the following: detecting anomalous latencies in function call chains; detecting anomalous call counts in function call chains; and tracking call patterns to detect cyclic invocations, clustering the call patterns, creating interaction graphs across smart contracts, and analyzing the interaction graphs to identify one or more local anomalies.
8. The one or more computer storage medium of claim 1, wherein the HGMs comprise one or more of: a programmable metric; a dynamic metric that measures functional properties at an individual function level; a dynamic metric that measures function properties at a call graph level in the function call chains; a dynamic metric that measures function latencies; a dynamic metric that measures function cardinalities; and a dynamic metric that measures function counts.
9. The one or more computer storage medium of claim 1, where the one or more HGMs in the function call stack are detected using Function Boundary Tracing (FBT) functionality of an extended Berkeley Packet Filter (eBPF).
10. A computer-implemented method comprising: detecting a function call associated with one or more methods of a smart contract on a blockchain by identifying an entrance or exit of the function call in a kernel for smart contract execution on the blockchain; adding the function call to a function call stack; identifying one or more detected high granularity metrics (HGMs) in the function call stack; performing a comparison of the detected HGMs in the function call stack against one or more control rules, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules comprises checking the detected HGMs in the function call stack against a set of permitted HGMs; and blocking execution or completion of the function call based on the comparison, wherein execution or completion of the function call is blocked based on determining the function call stack includes one or more detected HGMs that are not permitted under the set of permitted HGMs.
11. The computer-implemented method of claim 10, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules further comprises checking the detected HGMs in the function call stack against a set of prohibited HGMs.
12. The computer-implemented method of claim 11, wherein the set of prohibited HGMs is based on HGMs generated by execution of one or more smart contracts with known vulnerabilities.
13. The computer-implemented method of claim 11, wherein execution or completion of the function call is blocked based on determining the function call stack includes one or more detected HGMs that are not permitted under the set of prohibited HGMs.
14. The computer-implemented method of claim 10, wherein the set of permitted HGMs is based on HGMs generated by execution of one or more known acceptable smart contracts.
15. The computer-implemented method of claim 10, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules further comprises analyzing the detected HGMs in the function call stack to identify anomalous activity.
16. The computer-implemented method of claim 15, wherein the analyzing the detected HGMs in the function call stack to identify anomalous activity comprises one or more selected from the following: detecting anomalous latencies in function call chains; detecting anomalous call counts in function call chains; and tracking call patterns to detect cyclic invocations, clustering the call patterns, creating interaction graphs across smart contracts, and analyzing the interaction graphs to identify one or more local anomalies.
17. A computer system comprising: one or more processors; and one or more computer storage media storing computer-useable instructions that, when used by the one or more processors, cause the one or more processors to perform operations comprising: detecting a function call associated with one or more methods of a smart contract on a blockchain by identifying an entrance or exit of the function call in a kernel for smart contract execution on the blockchain; adding the function call to a function call stack; identifying one or more detected high granularity metrics (HGMs) in the function call stack; performing a comparison of the detected HGMs in the function call stack against one or more control rules, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules comprises checking the detected HGMs in the function call stack against a set of permitted HGMs; and blocking execution or completion of the function call based on the comparison, wherein execution or completion of the function call is blocked based on determining the function call stack includes one or more detected HGMs that are not permitted under the set of permitted HGMs.
18. The computer system of claim 17, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules further comprises checking the detected HGMs in the function call stack against a set of prohibited HGMs.
19. The computer system of claim 18, wherein execution or completion of the function call is blocked based on determining the function call stack includes one or more detected HGMs that are not permitted under the set of prohibited HGMs.
20. The computer system of claim 17, wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules further comprises analyzing the detected HGMs in the function call stack to identify anomalous activity.
“A later patent claim is not patentably distinct from an earlier patent claim if the later claim is obvious over, or anticipated by, the earlier claim. In re Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding of obviousness type double patenting where a patent application claim to a genus is anticipated by a patent claim to a species within that genus). “ ELI LILLY AND COMPANY v BARR LABORATORIES, INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3,5,8-10,12, and 15-17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kempf US 20210050989 in view of David et al US 2018/0307840 in view of Guri et al US 2018/0181752.
As per claim 1. Kempf discloses one or more computer storage media storing computer-useable instructions that, when used by one or more computing devices, cause the one or more computing to perform operations comprising:
detecting a function call made by execution of a smart contract on a blockchain by identifying an entrance or exit of the function call in a kernel for smart contract execution on the blockchain (0021 A first server of the data center receives a call to a function to be performed for a smart contract of a blockchain database, Thus system detected the call that is a function and 002 0 A call to a function of the transaction processing element result in the function being run as a service. 0022 invocations of a function can be executed in parallel. Several instances of a function can be executed in one or more runtime environment, i.e. kernel of a system or blockchain, over one or multiple servers of the data center. Wherein the system is identifying the function call by receiving the function and the function call is identifying the function call exist in the runtime environment);
adding the function call to a secure layer for storing a plurality of function calls made by execution of the smart contract or a second smart contract; (0036 In operation, the first server 122A receives, at operation 1, a call to a function to be performed for a smart contract, i.e. a secure layer, of a blockchain database. In some embodiments, the function to be performed is one of creating the smart contract or performing a transaction operation on the smart contract that was previously created. For example, the smart contract can represent a delegation of rights from a service hosted in the data center 108 to a tenant 102A. In other embodiments, the operations can be any operation, i.e. call to the function, that may result in a blockchain transaction or a block that is recorded, i.e. adding, in the blockchain database 130. Call to a function and the function is performed in the smart contract, this function call operation that is a blockchain transaction that is recorded, i.e. adding, in the blockchain database);
identifying one or more detected high granularity metrics (HGMs) based on the plurality of function calls in the function a security layer (0021 Code is fetched from the blockchain database, where the code includes a set of one or more instructions, i.e. HGMs, to be executed for implementing the function. The code is identified, i.e. identify, to fetch the function call from the blockchain database, the code has more instructions as a HGMs and 0053 The set of blocks includes the first block and each block from the set of blocks results from execution of code of one or more functions on one or more runtime environments of servers of the data center 108. Wherein the transaction block is created from the execution of the code or function in the runtime, i.e. kernel of the blockchain);
performing a comparison of the detected HGMs in the function call stack against one or more control rules (0054 Responsive to determining, i.e. comparison, that the first block is to be added to the blockchain database 130 wherein the code, i.e. HGMs of the block is compared for the function call that is executed in the kernel of the blockchain ); and
blocking execution or completion of the function call based on the comparison (0054 server failure, i.e. blocking execution, copies of the first block of the function call stored in other servers (other local storages) preserve the data ensuring high availability of the first block. Wherein the system failed the block execution of the function call to record in the blockchain).
Kempf does not explicitly disclose detecting a function call made during execution in a virtual machine executing in a user space, wherein the function call is detected by using function-boundary detection instrumentation in a kernel of an operating system to identify an entrance or exit of a user-space function in the virtual machine, the user-space function;
identifying one or more detected high granularity metrics (HGMs) based on the plurality of function calls in the function call stack;
performing a comparison of the detected HGMs in the function call stack against one or more control rules; and
blocking execution or completion of the function call based on the comparison.
However, David discloses
identifying one or more detected high granularity metrics (HGMs) based on the plurality of function calls in the function call stack (fig.5B,0012 the process map identifying permitted sequential process calls, i.e. function calls, on the controller and 0085 the stack inspection agent can identify a process from the stack in a policy graph (556) and another process that is called by the identified process (558));
performing a comparison of the detected HGMs in the function call stack against one or more control rules (0085 the stack inspection agent 520 can identify the process f1 and another process (f3) called by f1. The stack inspection agent can determine whether the sequence of process calls is permitted using the policy graph (560) 0066-0067 the process verification agent 208 can perform a comparison operation to determine whether the stored signature and the determined signature are the same); and
blocking execution or completion of the function call based on the comparison ( 0085 blocking the unpermitted process to be called/run, resetting the controller (if it can be done safely without affecting device/system operation), and/or other appropriate actions and 0012 blocking, by the security layer, operation of one or more processes on the controller in response to determining that the current sequence of process calls is not permitted).
Kempf and David are both considered to be analogous to the claimed invention because they are in the same field of function call in the secure layer.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kempf to incorporate the teachings of David and provide protect the function call of the system (par 0090).
The combination does not disclose detecting a function call made during execution in a virtual machine executing in a user space, wherein the function call is detected by using function-boundary detection instrumentation in a kernel of an operating system to identify an entrance or exit of a user-space function in the virtual machine, the user-space function;
However, Guri discloses detecting a function call made during execution in a virtual machine executing in a user space (Par 0063 the computer program that such imported procedures are called. Par 0075 contents of a call stack (e.g., function(s) called) associated with the kernel space (a region of main memory 104 allocated for the kernel of operating system 110, i.e. a virtual machine executing, and 0050 detects, classifies and/or neutralizes the execution of malicious code associated with a computing process executing thereon. And 0060 a procedure call (e.g., GetProcAddress) that identifies the procedure) at the time execution of the malicious code was halted 0086 database ), wherein the function call is detected by using function-boundary detection instrumentation in a kernel of an operating system to identify an entrance or exit of a user-space function in the virtual machine, the user-space function( 0069 Upon intercepting, i.e. detecting, such procedure calls, runtime protector 122 allows, i.e. function boundary for identify the function is entrance or exit in the call stack, the call to be completed, thereby resulting in the library module(s) being loaded at their intended addresses in main memory 104 and 0075 contents of a call stack (e.g., function(s) called) associated with the kernel space (a region of main memory 104 allocated for the kernel of operating system 110, i.e. a virtual machine executing,) at the time execution of the malicious code was halted 0086 database ). Kempf and David and Guri are both considered to be analogous to the claimed invention because they are in the same field of function call in the secure layer. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kempf to incorporate the teachings of David, including the teaching of Guri and provide protect against system (par 0090).
As per claim 2. Kempf and David and Guri discloses the one or more computer storage media of claim 1, David discloses wherein performing the comparison of the detected HGMs in the function call stack against the one or more control rules comprises analyzing the detected HGMs in the function call stack to identify anomalous activity ( fig.5B,0012 the process map identifying to detect, permitted sequential process calls, i.e. function calls, on the controller and 0085 the stack inspection agent can identify a process from the stack in a policy graph (556) and another process that is called by the identified process (558) and 0085 the stack inspection agent 520 can identify the process f1 and another process (f3) called by f1. The stack inspection agent can determine whether the sequence of process calls is permitted using the policy graph (560) 0066-0067 the process verification agent 208 can perform a comparison operation to determine whether the stored signature and the determined signature are the same ).
As per claim 3. Kempf and David and Guri discloses The one or more computer-storage media of claim 2, David discloses wherein analyzing the detected HGMs in the function call stack to identify anomalous activity comprises determining a deviation from one or more historical patterns (0056 controller 302 using a whitelist 318 that is part of a custom security policy 316 for the controller 302 to block a malicious process 306. In this example, the processes #1-#N (304a-n) are included on the whitelist 318 for the controller 302, but the process #2 has a known exploit that is used by hackers to implant a small footprint malware 308 that then, if executed, could download a larger malicious binary that may be launched as a privileged process. A whitelist security agent that is part of a security middleware layer 320b can block the small footprint malware 308 and the larger the malicious process 306 from being executed by the controller 302 because they are not included in the whitelist 318—effectively blocking the malicious process 306 and the small footprint malware 308 from being executed by the CPU 312 and used to corrupt the memory 314 (e.g., buffer overrun attack). ).
As per claim 5. Kempf and David and Guri discloses The one or more computer storage media of claim 1, David discloses wherein the one or more control rules comprise one or more selected from the following: one or more white list rules; one or more black list rules; one or more function level dynamic HGM rules; and one or more call graph level HGM rules ( 0010 a kernel level security layer that includes a whitelist of permitted processes on the controller, the whitelist being part of a custom security policy for the controller; receiving, at the security layer, a request to run a particular process; determining, by the security layer, a signature for the particular process; identifying, by the security layer, a verified signature for the process from the whitelist; determining, by the security layer, whether the particular process is permitted to be run on the controller based on a comparison of the determined signature with the verified signature from the whitelist; and blocking, by the security layer, the particular process from running on the automotive controller based on the determined signature not matching the verified signature for the process and 0015 as security policy can include, for example, a whitelist (e.g., identification of permitted processes, binaries, functions, operations), network firewall (e.g., identification of permitted network ports, IP addresses), functional graph (e.g., mapping and/or sequence of functions performed by a controller), and/or additional features that model permitted/designed behavior of the controller. Such automatic security policy generation (e.g., during build, due to static analysis (and other tools, such as simply signing on binaries to add to a whitelist)) can permit for endpoint security to be added to controllers with little to no effort on behalf of controller manufacturers/vendors, who can simply run the automated security policy generator prior to deployment in order to add endpoint security to their controller. ).
As per claims 8-10 and 12, those claims are rejected based on the same rational set forth in the claims 1-3 and 5 respectively.
As per claims 15-17 and 19, those claims are rejected based on the same rational set forth in the claims 1-3 and 5 respectively.
Claim(s) 4 ,11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kempf and David and Guri in view of Konig et al US 9,904,584.
As per claim 4. Kempf and David and Guri discloses the one or more computer storage media of claim 2, the combination fails to disclose wherein analyzing the detected HGMs in the function call stack to identify anomalous activity comprises one or more selected from the following: detecting anomalous latencies in function call chains; detecting anomalous call counts in function call chains; and tracking call patterns to detect cyclic invocations, clustering the call patterns, creating interaction graphs across smart contracts, and analyzing the interaction graphs to identify one or more local anomalies.
However, Konig discloses wherein analyzing the detected HGMs in the function call stack to identify anomalous activity comprises one or more selected from the following: detecting anomalous latencies in function call chains; detecting anomalous call counts in function call chains; and tracking call patterns to detect cyclic invocations, clustering the call patterns, creating interaction graphs across smart contracts, and analyzing the interaction graphs to identify one or more local anomalies(claim 10 wherein the computer-executable instructions further cause the processing device to: determine anomaly scores for the identified anomalous latencies; and generate a ranked list of the predicates using the anomaly scores).
Kempf and David and Guri and Konig are both considered to be analogous to the claimed invention because they are in the same field of function call.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kempf to incorporate the teachings of David, including the teaching of Guri including the teaching of Konig and provide a management of the function call of the blockchain.
As per claims 11 and 18, claims are rejected based on the same rational set forth in the claim 4.
Claim(s) 6 ,13 and 20 is rejected under 35 U.S.C. 103 as being unpatentable over Kempf and David and Guri in view of BURRIESCI et al US 2019/0147503.
As per claim 6. Kempf and David and Guri discloses The one or more computer storage media of claim 1, the combination fails to disclose wherein the HGMs comprise one or more selected from the following: a programmable metric; a dynamic metric that measures functional properties at an individual function level; a dynamic metric that measures function properties at a call graph level in the function call chains; a dynamic metric that measures function latencies; a dynamic metric that measures function cardinalities; and a dynamic metric that measures function counts.
However, Burriesci discloses wherein the HGMs comprise one or more selected from the following: a programmable metric; a dynamic metric that measures functional properties at an individual function level; a dynamic metric that measures function properties at a call graph level in the function call chains; a dynamic metric that measures function latencies; a dynamic metric that measures function cardinalities; and a dynamic metric that measures function counts ( 0064 The event detection module 230 can include instructions to cause the client device 125 to monitor one or more computing performance metrics for the client device 125. The computing performance metric can be measured or accessed, for example, by various function calls (e.g., JAVASCRIPT runtime) to obtain computing performance of the client device 125 and application programming interfaces with the application 205).
Kempf and David and Guri and BURRIESCI are both considered to be analogous to the claimed invention because they are in the same field of function call.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kempf to incorporate the teachings of David, including the teaching of Guri and including the teaching of Burriesci and provide a management of the function call of the blockchain.
As per claims 13 and 20, claims are rejected based on the same rational set forth in the claim 7.
Claim(s) 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Kempf and David and Guri in view of Shuai et al US 9,454,539.
As per claim 7, Kempf and David and Guri disclose The one or more computer storage media of claim 1, but fails to disclose where the one or more HGMs in the function call stack are detected using Function Boundary Tracing (FBT) functionality of an extended Berkeley Packet Filter (eBPF).
However, Shuai discloses where the one or more HGMs in the function call stack are detected using Function Boundary Tracing (FBT) functionality of an extended Berkeley Packet Filter (eBPF) (col 5, lines 1-15, a function Boundary Tracing probe function is inserted into DTrace tracing module for monitoring various file transactions, and the processing of transactions is done by calling some systems functions).
Kempf and David and Guri and Shuai are both considered to be analogous to the claimed invention because they are in the same field of function call.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kempf to incorporate the teachings of David, including the teaching of Guri including the teaching of Shuai and provide a management of the function call of the blockchain.
As per claim 14, this claim is rejected based on the same rational set forth in the claim 7.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/ Primary Examiner, Art Unit 2496