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 . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-16 and 19-21 are cancelled.
Claims 17-18 and 22 are pending.
Response to Arguments
Applicant’s arguments, see page 10, filed 08/05/2026, with respect to Claim 17 have been fully considered and are persuasive. The objection of 05/05/2026 has been withdrawn.
Applicant’s arguments, see page 10, filed 08/05/2026, with respect to Claim 17-18 and 22 have been fully considered and are persuasive. The rejection under 35 USC § 112(a) of 05/05/2026 has been withdrawn.
Applicant’s arguments, see page 10, filed 08/05/2026, with respect to Claim 17-18 and 22 have been fully considered and are persuasive. The rejection under 35 USC § 112(b) of 05/05/2026 has been withdrawn.
Applicant’s argues on page 12 “Rangaiah does not disclose "modifying the software code on a client device into a modified code", as required in the claimed invention… “
Examiner respectfully disagree because “modifies code” could be interpreted broadly. Claims does not recite how code is being modified. Thus, claim limitations are interpreted as the broadest interpretation. Rangaiah disclose portion of the header of the file replaced with a dummy string to create modified version of the program in cited paragraph [0020] which satisfies the claimed functions. Additionally, Rangaiah discloses creating a hash of modified version of the program file using cryptographic hashing algorithms see cited para [0011] and [0020].
Applicant’s argument with respect to amended limitation of “sending the hash based on the modified code to a server without sending the software code or the modified code,” is moot in view of a new ground of rejection.
Applicant’s argument with respect to amended limitation of “receive an input variable; pass the input variable through a series of functions of software code to generate a result value, wherein each function changes a value of the input variable and wherein the series of functions is selected based on at least one condition associated with execution of the software code; send the input variable and the result value to a server for comparing the result value with a value calculated by the server from the input variable; and receive, from the server, a response indicating whether the result value matches the value calculated by the server and whether to continue transactions using the software code.” is moot in view of a new ground of rejection.
Applicant's arguments filed 08/05/2026 have been fully considered but they are not persuasive.
Applicant's amendments/arguments filed on 08/05/2026 have been fully considered.
With respect to rejection of claim under 35 USC 101, Applicant asserts,
Regarding Claim 17:
“These are operations performed on software code by networked computer devices. A person cannot practically perform in the human mind the claimed modification of software code on a client device, generation of a hash dependent on the modified code, network transmission of that hash, server-side comparison against a stored list, and electronic control of transactions. The fact that a person may conceptually understand that two values can be compared does not convert the claimed computer-security process into a mental process… The claims do not merely recite "comparing information" or "making a decision." They recite a particular client-server process for authenticating modified software code and controlling software transactions….”.
Examiner respectfully disagrees. The limitation of “modifying the software code…; creating a hash…; sending hash…to the server…; comparing the hash…to at least one hash on the predetermined list of hashes…; determining that the hash based on the modified code does not match with at least one hash on the predetermined list of hashes, sending a negative response; determining that the hash based on the modified code does match with at least one hash on the predetermined list of hashes on the server, sending a positive response” could be a mental process and perform by human using pen and paper. For example, a human could perform all the limitations of claim 17 using pen and paper. A person can modify a software code and compute manual hash of that code.
Regarding Claim 18:
Applicant argues: “Claim 18 requires that the predetermined list of hashes be created from simulated modifications to the software code. As described in the Specification, different modifications may be simulated, hashes may be generated for the resulting modified versions, and those hashes may be stored for later verification. These are computer operations involving software transformation, hash generation, and server-side storage, not mental steps”.
Examiner respectfully disagrees. The limitation of claim 18 is merely citing how predetermined list of hashes are created. It is considered as mental process which a human could also perform using pen and paper.
Regarding Claim 22:
“Claim 22 likewise does not recite a mental process. The claim requires processor-executable instructions that cause a client device to pass a variable through a series of software functions that change the variable's value to generate a result value, wherein the series of functions is selected based on at least one condition associated with execution of the software code, send the input variable and the result value to a server for comparing result value with a value calculated by the server from the input variable, and receive a response indicating whether the result value matches the value calculated by the server for controlling whether transactions using the software code continue…. This process requires execution of software functions, condition-dependent routing of variables, client-server communication, server-side evaluation, and electronic transaction control. It is not practically performable in the human mind and is therefore not a mental process.”
Examiner respectfully disagrees. The limitation of claim 22 merely directed toward a software code in which a variable fed through series functions where function could be any routine, method, operations of mathematical function/operation and the compare end result with the initial value of the variable. These limitations can be done by a human using pen and paper. A human can write a code or steps of instruction in such way that variable keep changing its value until on condition satisfied. Ex. By using conditional operators (if…else loop or while loop) of software coding a person can achieved claimed function.
The limitation does not integrate the abstract idea into a practical application because it does not impose meaningful limits on practicing the abstract idea. Additionally, the limitation implement an abstract idea using a generic computer component and generic algorithm to compute a hash and does not effect an improvement in improvement in computer functionality or another technology, and therefore fails to satisfy 35 USC 101 under the Alice farmwork.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 17-18 and 22 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
The claims when analyzed under 2019 Revised Patent Subject Matter Eligibility Guidance, are directed to abstract idea. Claim 17 for example, recites a method and, therefore, is a process. The claim recites the limitation of: "verifying software code..,”; modifying the software code on a client device…;"creating a hash based on the modified code”; “sending the hash based on the modified code to a server”; “comparing the hash based on the modified code to at least one hash on a predetermined list of hashes on the server”; …” sending a negative response to the client device to stop any transactions”; “…sending a positive response to the client device to proceed with any transactions”. These limitations, under broadest reasonable interpretation are directed performance of the limitation in a human mind or using pen and paper by a human. That is, nothing in the claim element precludes the step from practically being performed in the mind. For example, the claim encompasses a human simply "verifying software code..,”; modifying the software code on a client device…;"creating a hash based on the modified code”; “sending the hash based on the modified code to a server”; “comparing the hash based on the modified code to at least one hash on a predetermined list of hashes on the server”; ” in response to determining that the hash based on the modified code does not match with at least one hash on the predetermined list of hashes on the server, sending a negative response to the client device to stop any transactions”; “in response to determining that the hash based on the modified code does match with at least one hash on the predetermined list of hashes on the server, sending a position response to the client device to proceed with any transactions”.
Thus, the claim recites a mental process when analyzed under step 2A prong 1.
Claim is further analyzed in step 2A prong 2, to evaluate whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This evaluation is performed by identifying whether there are any additional elements recited in the claim beyond the judicial exception, and evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. However, each of the remaining limitation ("a server"), (“Client device”) appears to be generic computer functions which do not constitute meaningful limitations that would amount to significantly more than the abstract idea. The combination of these additional element is no more than generic computer functions. Thus, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limitations on practicing the abstract idea.
Claim is additionally analyzed under Step 2B to evaluates whether the claim as a whole amount to significantly more than the recited exception, whether any additional element, or combination of additional elements, adds an inventive concept to the claim. When claims evaluated under step 2B, it is no more than what is well-understood, routine, conventional activity in the field. The specification does not provide any indication anything other than a generic computer component. The mere verifying software code…; modifying the software code on a client device…; creating a hash based on the modified code; sending the hash based on the modified code to a server; comparing the hash based on the modified code to at least one hash on a predetermined list of hashes on the server; in response to determining that the hash based on the modified code does not match with at least one hash on the predetermined list of hashes on the server, in response to determining that the hash based on the modified code does not match with at least one hash on the predetermined list of hashes on the server, sending a negative response to the client device to stop any transactions; in response to determining that the hash based on the modified code does match with at least one hash on the predetermined list of hashes on the server, sending a position response to the client device to proceed with any transactions is a well-understood, routing and conventional function when it is claimed in a merely generic manner as it is here.
Regarding Dependent claims 18 do not cure the deficiency of the independent claims and are directed to abstract idea when analyzed under 2019 Revised Patent Subject Matter Eligibility Guidance.
Regarding Claim 18,
Claim 18, recites a method and, therefore, is a process. The claim recites the limitation of: "…the predetermined list of hashes on the server are created from simulating modification to the software code" These limitations, under broadest reasonable interpretation are directed performance of the limitation in a human mind or using pen and paper by human. That is, nothing in the claim element precludes the step from practically being performed in the mind. For example, the claim encompasses a human simply "…the predetermined list of hashes on the server are created from simulating modification to the software code". Thus, the claim recites a mental process when analyzed under step 2A prong 1.
Claim is further analyzed in step 2A prong 2, to evaluate whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This evaluation is performed by identifying whether there are any additional elements recited in the claim beyond the judicial exception, and evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. However, each of the remaining limitation ("the server") appears to be generic computer functions which do not constitute meaningful limitations that would amount to significantly more than the abstract idea. The combination of these additional element is no more than generic computer functions. Thus, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limitations on practicing the abstract idea.
Claim is additionally analyzed under Step 2B to evaluates whether the claim as a whole amount to significantly more than the recited exception, whether any additional element, or combination of additional elements, adds an inventive concept to the claim. When claims evaluated under step 2B, it is no more than what is well-understood, routine, conventional activity in the field. The specification does not provide any indication anything other than a generic computer component. The mere the predetermined list of hashes on the server are created from simulating modification to the software code is a well-understood, routing and conventional function when it is claimed in a merely generic manner as it is here.
Regarding Independent claim 22,
Claim 22, recites a method and, therefore, is a process. The claim recites the limitation of: "receive a variable; pass the variable through a series of functions that change a value of the variable; send the variable and the value to a server; receive a confirmatory response…" These limitations, under broadest reasonable interpretation are directed performance of the limitation in a human mind or using pen and paper by human. That is, nothing in the claim element precludes the step from practically being performed in the mind. For example, the claim encompasses a human simply "receive a variable; pass the variable through a series of functions that change a value of the variable; send the variable and the value to a server; receive a confirmatory response…". Thus, the claim recites a mental process when analyzed under step 2A prong 1.
Claim is further analyzed in step 2A prong 2, to evaluate whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This evaluation is performed by identifying whether there are any additional elements recited in the claim beyond the judicial exception, and evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. However, each of the remaining limitation ("A non-transitory computer-readable medium") and (“a processor”) appears to be generic computer functions which do not constitute meaningful limitations that would amount to significantly more than the abstract idea. The combination of these additional element is no more than generic computer functions. Thus, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limitations on practicing the abstract idea.
Claim is additionally analyzed under Step 2B to evaluates whether the claim as a whole amount to significantly more than the recited exception, whether any additional element, or combination of additional elements, adds an inventive concept to the claim. When claims evaluated under step 2B, it is no more than what is well-understood, routine, conventional activity in the field. The specification does not provide any indication anything other than a generic computer component. The mere receive a variable; pass the variable through a series of functions that change a value of the variable; send the variable and the value to a server; receive a confirmatory response… is a well-understood, routing and conventional function when it is claimed in a merely generic manner as it is here.
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) 17 is rejected under 35 U.S.C. 103 as being unpatentable over Rangaiah et al. (U.S. PGPub. No. 2020/0372183 A1) (hereinafter “Rangaiah”) in view of Miller (U. S. Pat. No. 10,897,361 B1) (hereinafter “Miller”) and further in view of Waldspurger et al. (U. S. Pat. No. 7,984,304 B1 (hereinafter “Waldspurger”)
Regarding Claim 17, Rangaiah teaches:
modifying the software code on a client device into a modified code (Rangaiah: [0020], the program file 310 may be modified by replacing one or more portions of the header 320 with a defined alphanumeric string. For example, referring to FIG. 3B, shown is a modified program file 312 with a modified header 321, in which header portion 326 (shown in FIG. 3A) has been replaced with a dummy string 340 [0035], the modified version of the program 120 may have a header portion that is replaced by a fixed dummy string. For example, the modified version of the program 120 may be a program archive file (e.g., a JAR file) including a manifest file that specifies a dummy software version number (e.g., a fixed JDK version number);
creating a hash based on the modified code (Rangaiah: [0011], a client device may generate a first hash based on a modified version of all or a portion of a program file. [0020], the hash function applied to the first hash 125 may include one or more cryptographic hashing algorithms such as Message Digest 5 (MD5), Secure Hashing Algorithm 256 (SHA-256), SHA-512, SHA3-224, and so forth);
Rangaiah does not explicitly disclose:
sending the hash based on the modified code to a server without sending the software code or modified code
However, in an analogous art, Miller teaches:
sending the hash based on the modified code to a server without sending the software code or modified code (Miller: [Col 10, lines 22-23], (62) At step 9, hash validator 130 sends the computed hash to server 120)
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Rangaiah’s method of modifying program files and generating hash based on modified version of the program file by applying Miller’s method of sending computed hash to the server in order to comparing hashes of data items and verifying the authenticity of the data)
The Rangaiah in view of Miller does not explicitly disclose:
A method of verifying software code using modified hashes, the method comprising:
comparing the hash based on the modified code to at least one hash on a predetermined list of hashes on the server; in response to determining that the hash based on the modified code does not match with at least one hash on the predetermined list of hashes on the server, sending a negative response to the client device to stop any transactions; and in response to determining that the hash based on the modified code does match with at least one hash on the predetermined list of hashes on the server, sending a position response to the client device to proceed with any transactions.
However, in an analogous art, Waldspurger teaches:
A method of verifying software code using modified hashes, the method comprising (Walspurger: [Col 1, lines 9-10], detection of unauthorized, altered or potentially malicious executable code [Col 23, lines 18-19], The generated hash value could then be matched to the white list (=predetermined list)):
comparing the hash based on the modified code to at least one hash on a predetermined list of hashes on the server (Waldspurger: [Col 16, lines 57-63], This value is then compared, for example by a comparison or matching module 256, against either a "white" list 143, or a "black" list 144, or both, stored in an ID database 142 located either in the local memory 140 of the user's system, or in some other system, such as in a remote server 710 with which the user's system is communicating, or in a combination of storage locations. [Col 24, lines 18-20], then look up hashVal(p.sub.curr) in a database such as the ID database 142 or just the white list 143. [Col 27, lines 18-20], the ID database 142 contains hash values for pages of a set of known programs);
in response to determining that the hash based on the modified code does not match with at least one hash on the predetermined list of hashes on the server (Waldspurger: [Col 18, lines 20-22], (99) If the hash value of the current page is found in the black list 144 (=It means it not found in whitelist), then it is assumed at least temporarily that it is not safe to execute the current instruction),
sending a negative response to the client device to stop any transactions (Waldspurger: [Col 4, lines 14-18], (26) Any, of any combination, of a wide range of responses (=negative response) may be generated in the case that the validation condition is not satisfied. Examples of responses include: suspending execution of a software entity (=stop any transaction) with which the current memory block is associated; posting a message to a user, system administrator, or other predetermined recipient).
and in response to determining that the hash based on the modified code does match with at least one hash on the predetermined list of hashes on the server (Waldspurger: [col3 ,lines 4-11], , a "white list" is made available to the verification engine. Accordingly, at least one validation entry is included in the set of reference values corresponding to at least one identifying value for predetermined contents of a known, valid memory block. The validation condition is then that the identifying value of the current memory block matches any validation entry in the set of reference values. [Col 23, lines 18-19], The generated hash value could then be matched to the white list (=predetermined list)),
sending a positive response to the client device to proceed with any transactions (Waldspurger: [Col 2, lines 66-67], The identifying value of the current memory block is then compared with a set of reference values. If the identifying value satisfies a validation condition, then execution of the current instruction by the processor is allowed. [Col 11, lines 65-67], (54) Moreover, it should be possible to associate with a page, in either a hardware or a software structure, some indication (=positive response) of whether the code on that page is "safe," "valid," "permissible," etc.)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Rangaiah in view of Miller by applying the well-known technique as disclosed by Waldspurger of detection of unauthorized, altered or potentially malicious executable code by comparing hashed with hashes in the white list in order to detection of unauthorized, altered or potentially malicious executable code (Waldspurger: [Col 1, lines 9-10])
Claim(s) 18 is rejected under 35 U.S.C. 103 as being unpatentable over Rangaiah et al. (U.S. PGPub. No. 2020/0372183 A1) (hereinafter “Rangaiah”) in view of Miller (U. S. Pat. No. 10,897,361 B1) (hereinafter “Miller”) and Waldspurger et al. (U. S. Pat. No. 7,984,304 B1 (hereinafter “Waldspurger”); and further in view of (Kamada et al. (U. S. PGPub. No. 2006/0150246 A1) (hereinafter “Kamada”)
Regarding Claim 18, Rangaiah in view of Miller and Waldspurger teaches:
The method of claim 17 (see rejection of claim 17 above),
Rangaiah in view of Waldspurger does not explicitly disclose:
wherein the predetermine list of hashes on the server are created from simulating modifications to the software code.
However, in an analogous art, Kamada teaches:
wherein the predetermine list of hashes on the server are created from simulating modifications to the software code (Kamada: [0076], the server 1 applies a one-directional function to a specified program to compute a hash value that is to be used as expected hash value… In this way, the server 1 prepares (=created) as many entries as the number of specified necessary programs and also an expected hash table. [0075], An expected hash table is a list of the specified programs that the server 1 authorizes the client terminal 2 to execute and includes sets of the program ID of a specified program and an expected hash value. The program ID is an ID specific to the program. Examiner’s Note: Server 1 is preparing multiple entries of specified program and expected hash value, which is constitute as expected hash table list, therefore para [0076] [0075] fulfil the claimed limitation “the predetermine list of hashes on the server are created.)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Rangaiah in view of Miller and Waldspurger by applying the well-known technique as disclosed by Kamda of server is prepare and storing multiple entries of specified programs and expected hash value. The motivation is that the server can suspend the service for the purpose of security if it is found that any unauthorized program is being driven on the device (Kamada: [0003])
Claim(s) 22 is rejected under 35 U.S.C. 103 as being unpatentable over Jakubowski (U. S. Pat. No. 7,080,257 B1) (hereinafter “Jakubowski”) and further in view of Ciet et al. (U. S. Pat. No. 8,094,813 B2) (hereinafter “Ciet”) and Giuliani et al. (U. S. Pat. No. 10,284,591 A1) (hereinafter “Giuliani”)
Regarding Claim 22, Jakubowski teaches:
A non-transitory computer-readable medium (Jakubowski: [Col 3, lines 49-55], the protected digital goods may be stored on a computer-readable medium 108 (e.g., CD-ROM, DVD, floppy disk, etc.) and physically distributed in some manner, such as conventional vendor channels or mail. The protected goods may alternatively be downloaded over a network (e.g., the Internet) as streaming content or files 110) comprising instructions executable by a processor to (Jakubowski: [Col 4, lines 22-31], (18) The client 104 has a secure processor 140, memory 142 (e.g., RAM, ROM, Flash, hard disk, CD-ROM, etc.)…(19) The client 104 runs an operating system 150, which is stored in memory 142 and executed on the secure processor 140):
receive an input variable (Jakubowski: [Col 9, lines 16-26], (60) One implementation of computing checksum S(f) is as follows: Start with x=x.sub.0)
pass the input variable through a series of functions of software code (Jakubowski: [Col 9, lines 16-26], (60) One implementation of computing checksum S(f) is as follows: Start with x=x.sub.0 (=input variable) Cks:=f(x.sub.0) XOR x.sub.0 For i=1 to K do x.sub.i:=g(f(x.sub.i-1)) Cks +=f(x.sub.i) XOR x.sub.i End for (61) The resulting checksum S(f) is the initial value x.sub.0, along with the value Cks, or (x.sub.0, Cks). Notice that the output of one iteration is used to compute the input of the next iteration) to generate a result value (Jakubowski: [Col 8, lines 40-44], given a function f, the tool computes a checksum S(f) (=result value) such that: (54) (1) If f is not changed, S(f) can be verified to be correct. (55) (2) If f is changed to f', S(f') .noteq. S(f) with extremely high probability), wherein each function changes a value of the input variable).
and receive, from the server, a response indicating whether the result value matches the value calculated by the server (Jakubowski: Col 10, lines 16-21], (69) When the client executes the digital good, the client-side evaluator 152 comes across the checkpoint and calls the verification function. If the checksums match, the digital good is assumed to be authentic; otherwise, the client is alerted (=response) that the digital good is not authentic and may be an illicit copy) and whether to continue transactions using the software code (Jakubowski: [Col 4, lines 52-61], (21) In the event that the client detects some tamper activity, the secure processor 140 acting alone, or together with the operating system 150, may decline to execute the suspect digital code. For instance, the client may determine that the software product is an illicit copy because the evaluations performed by the evaluator 152 are not successful. In this case, the evaluator 152 informs the secure processor 140 and/or the operating system 150 of the suspect code and the secure processor 140 may decline to run that software product)
Jakubowski does not explicitly disclose:
send the input variable and the result value to a server for comparing the result value with a value calculated by the server from the input variable;
However, in an analogous art, Ciet teach:
send the input variable and the result value to a server (Ciet: [Col 6, lines 15-20], The server receives server input data (=input variable) 404. The server performs a server modulus transformation on the server input data to obtain a result (=result value) 406. The server performs a plain operation on the result based on a server operation value to obtain server output data 408) for comparing the result value with a value calculated by the server from the input variable (Ciet: [Col 6, lines 33-41], (29) After both the server and the client have obtained their respective output data, either one can check if the output data match 422. In that case, either the server or the client transmits the output data to the other… [Col 6, lines 39-41), The device that checks the output data can authenticate the input data if the server output data matches the client output data 424)
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Jakubowski’s method of computing checksum by providing input x to the function “XOR” by applying Ciet’s method of comparing two output data to authenticate the input data if both output matched. The motivation is to prevent malicious or mischievous individuals with enough time and resources can reverse engineer critical portions of the object code (Ciet: [Col 1, lines 27-29])).
Jakubowski in view of Ciet does not explicitly disclose:
wherein the series of functions is selected based on at least on condition associated with execution of the software code
However, in an analogous art, Giuliani teaches:
wherein the series of functions is selected based on at least on condition associated with execution of the software code (Giuliani: [Col 10, lines 45-48], (41) Flow proceeds to decision operation 306 where a determination is made as to whether an alert of suspicious behavior is triggered based on execution of the one or more memory checks performed during the stack walk processing. [Col 10, lines 54-58], If decision operation 306 determines that no alert of suspicious behavior is triggered, then flow proceeds to operation 308 where execution of code (e.g., a payload) associated with an invoked function is allowed);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Jakubowski in view of Ciet by applying the well-known technique as disclosed by Giuliani of allowing execution of code of function if condition is satisfied in decision operation. The motivation is to provide anti-exploit system and method in order to prevent software exploits from executing code (Giuliani: [Col 1, lines 23-24]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to a disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Kulakowski et al. (U. S. PGPub. No. 2013/0298255 A1): Systems and methods for protecting data being sent between a client and a server include the capability of defining programmable processing steps that are applied by the server when protecting the data and the same steps are applied by the client when unprotecting the data. The programmable processing steps can be defined uniquely for each client, and the programmable processing steps are selected from a number of functions using sequencing data that defines the processing steps. The programmable processing steps allow for each client to process encrypted data in a different manner and the programmable processing steps are defined by what is called a digital rights management (DRM) Sequencing Key, and as such the system and method introduces a key-able DRM whereby each DRM message can be processed in a unique (or pseudo unique) manner.
Dolbeau et al. (U. S. Pat. No. 11,307,883 B2): This invention relates to a method of optimization of a computer program, comprising: a first step (S.sub.11, S.sub.12, S.sub.13, S.sub.14) of determination of a call of a function having at least one input parameter, said call corresponding to a first criterion according to which said input parameter is inside an interval substantially smaller than the range of possible values for said input parameter, and to a second criterion corresponding to a desired accuracy for said call; a second step (S.sub.2) of automatic generation of an executable code for implementing said function, minimizing execution time for said input parameter being within said interval and compliant with said desired accuracy; a third step (S.sub.3) of replacing the existing code implementing said function by the executable code generated at said second step.
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 RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached at 5712705143. 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.
/R.D./Examiner, Art Unit 2437
/ALI S ABYANEH/Primary Examiner, Art Unit 2437
