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 .
This action is responding to application papers dated 12/12/2023.
Claims 93-112 are pending in the application.
The information disclosure statement filed on 12/11/2024 has been considered.
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 93-112 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Specifically, claims 93-112 are directed to an abstract idea.
Per claim 93, the claim is directed to an idea of itself, mental processes that can be performed in the human mind, or by a human using a pen and paper. The steps of transforming a source code input can be pure mental process because a developer can convert/obfuscate code input manually using a pen and paper through observation, evaluation, judgment, opinion, Under Prong 1.
Under Prong 2, the additional limitations, the steps of providing the transformed source code to the third-party GAI, receiving, and presenting the response are mere data gathering for the mental steps and outputting the result which are insignificant extra solution activity, using a generic learning algorithm and computer component (HID) described at a high level of generality for applying or performing the abstract idea and do not indicate any integration of the abstract idea into a practical application as the mental steps are merely applied with a generic computing component(s). See MPEP see MPEP 2106.05(f) /2106.05(h). The GAI is a third-party GAI used as a mere tool to process the query and return a response. Therefore, the additional limitations do not integrate the abstract idea into a practical application. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components or insignificant extra solution activities (e.g. processors, devices, program instructions), then it falls within the "Mental Processes" grouping of abstract ideas (2019 PEG step 2A, Prong 1: Abstract idea grouping? Yes, Mental Process). At most, the steps of providing, receiving and presenting the response are not found to include anything more than what is well-understood, routine, conventional activity in the field. In this case, it is noted that the claimed extra-solution of data gathering and outputting/displaying is acknowledged to be a well-understood, routine, conventional activity court recognized as WURC examples in MPEP 2106.05(d)(ll), for example, data gathering and retrieving, storing data, updating, transmitting, and displaying a result - Symantec, Versata Dev, Content extraction, Electric Power Group). Insignificant extra solution activities or mere instructions to apply an exception using generic computer components cannot provide an inventive concept. Viewing the limitations individually and as a combination, the additional elements merely perform data gathering, transmitting, presenting/displaying and perform the mental steps using generic computing components as tools without integrating the abstract idea into a practical application. For at least these reasons, claim 93 is not patent eligible.
Per claims 94-106, these claims are directed to the same idea itself as in claim 93, reciting details of the mental steps (reverse transforming using a symbols store, mapping, excluding, retaining, replacing) and insignificant extra solution activity such as presenting, and generic computing components (using artificial intelligence, text-to-speech engine, image processor which are used as mere available tools) without adding any other additional element that is significantly more. Therefore, the claims are rejected for the same reasons as in claim 93.
Per claim 107, the claim is directed to an idea of itself, mental processes that can be performed in the human mind, or by a human using a pen and paper. The steps of sanitizing a source code input, using a transformation symbols store to reverse transform can be pure mental process because a developer can convert/obfuscate code input manually using a pen and paper through observation, evaluation, judgment, opinion, Under Prong 1.
Under Prong 2, the additional limitations, the steps of providing sanitized source code access, sending the sanitized source code input and presenting the code are insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(g). The additional limitations, non-transitory computer-readable storage media and a processor, a generic learning algorithm and computer component (HID) described at a high level of generality for applying or performing the abstract idea and do not indicate any integration of the abstract idea into a practical application as the mental steps are merely applied with a generic computing component(s). See MPEP see MPEP 2106.05(f) /2106.05(h). The GAI is a third-party GAI used as a mere tool to process the query and return a response. Therefore, the additional limitations do not integrate the abstract idea into a practical application. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components or insignificant extra solution activities (e.g. processors, devices, program instructions), then it falls within the "Mental Processes" grouping of abstract ideas (2019 PEG step 2A, Prong 1: Abstract idea grouping? Yes, Mental Process). At most, the steps of providing, receiving and presenting the response are not found to include anything more than what is well-understood, routine, conventional activity in the field. In this case, it is noted that the claimed extra-solution of data gathering, transmitting, and outputting/displaying is acknowledged to be a well-understood, routine, conventional activity court recognized as WURC examples in MPEP 2106.05(d)(ll), for example, data gathering and retrieving, storing data, updating, transmitting, and displaying a result - Symantec, Versata Dev, Content extraction, Electric Power Group). Insignificant extra solution activities or mere instructions to apply an exception using generic computer components cannot provide an inventive concept. Viewing the limitations individually and as a combination, the additional elements merely perform data gathering, presenting/displaying and perform the mental steps using generic computing components as tools without integrating the abstract idea into a practical application. For at least these reasons, claim 107 is not patent eligible.
Per claims 108-110, these claims are directed to the same idea itself as in claim 107, reciting details of the mental steps and insignificant extra solution activity such as storing, and generic computing components (IDE plugin) without adding any other additional element that is significantly more. Therefore, the claims are rejected for the same reasons as in claim 93.
Per claims 111-112, these claims are directed to the same idea itself as in claims 107-110, reciting the same mental steps and insignificant extra solution activity and generic computing components (hardware platform) without adding any other additional element that is significantly more. Therefore, the claims are rejected for the same reasons as in claim 107-110.
Claim Objections
Claims 96, 100 and 108 are objected to because of the following informalities: per claims 96 and 108, ‘a’ is missing before “volatile memory.” Per claim 100, “API” needs to be spelled out first. Appropriate correctio is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 94-97 and 107-112 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 94 recites the limitation “the reverse-transformed response.” There is insufficient antecedent basis for this limitation in the claim. Interpretation: the response including the reverse transformed modified transformed source code.
Claims 96, 97 recite the limitation “the transformations symbols store.” There is insufficient antecedent basis for this limitation in the claim. Interpretation: the transformation symbols store.
Claim 107 recites the limitation “the reverse transformed source code.” There is insufficient antecedent basis for this limitation in the claim. Interpretation: the reverse transformed source code response.
Claim 111 recites the limitation “the reverse transformed source code.” There is insufficient antecedent basis for this limitation in the claim. Interpretation: the reverse transformed source code response.
Per claims 95, 108-110, and 112, these claims are rejected because they depend from claims 94, 107 and 111 respectively.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 93-95, 98-102, 104, 107, 109-112 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sharma et al. (WO2022103382, hereafter Sharma, published 5/2022).
93. A method of providing protected access to a third-party generative artificial intelligence (GAI) for software development, comprising:
transforming a source code input (a transformed source code) via a one-way transform, wherein an enterprise has a proprietary interest in the source code input, and wherein the one-way transform is not internally reversible (Sharma, see at least [0014] preserving privacy in leveraging organization- specific remediation knowledge for flaw remediation across organizations; [0015] Deidentification therefore can be performed at the level of individual constructs in source code... Code deidentification is achieved through determining potentially identifying portions of a fix collected from an organization’s program code indicated in the associated structural context representation and removing, obfuscating, or otherwise modifying the potentially identifying code at one of several stages before the fix is presented as a suggestion … Deidentification can occur either before training of the fix suggestion model(s) or during prediction. When deidentification is implemented before training, flaws and corresponding fixes can be preprocessed to deidentify sensitive code while preparing the flaws and fixes to be used as training data …without compromising organizational privacy; [0016] [0018] To allow for training with the multi-organization training data without exposing proprietary information … modifies program code which is potentially identifying of its source organization, or the owning/controlling organization of the software project that is the source of the program code. … or obfuscating the code element; 0019]; [0103]; [0027]; [0028]; [0050] At block 507, the remediation service generates a vector representation of the structural context representation. Generating the vector representation allows the structural context to be fed or input into a machine learning model; Note that obfuscating code secures the code against both reverse engineering and side channel attacks, therefore, it is one way transformation that is not internally reversible).
providing the transformed source code to the third-party GAI, in association with a query for the third-party GAI, wherein the third-party GAl is controlled by a party other than the enterprise (Sharma, see at least [0015] Deidentification can occur either before training of the fix suggestion model(s) or during prediction. When deidentification is implemented before training, flaws and corresponding fixes can be preprocessed to deidentify sensitive code while preparing the flaws and fixes to be used as training data …without compromising organizational privacy; [0016]; [0018] The agent 117 communicates or inputs the flaws to the remediation service 119 to obtain potential fixes output by one or more of trained models 127. The remediation service 119 includes the trained models 127, a repository 123 of multi-organization flaw/fix training data, and a model trainer 125 …To allow for training with the multi-organization training data without exposing proprietary information, the model trainer 125 utilizes a code de-identifier 126; Note that the models are not utilized by an organization and user and provides a code fix service, therefore they are considered a third party).
receiving from the third-party GAl a response to the query; and presenting the response to a human user via a human interface device (HID) (Sharma, see at least [0019] The agent 117 can update the scan results 115A to include the suggested fixes 135. The agent 117 can pass the suggested fixes 135 in association with the corresponding remaining flaws to the software development tool 105 instance being used by the developer 101. The agent 117 may have its own user interface and present the suggested fixes 135 itself; Note that the suggested fixes for the query are presented to a user, that is, via a HID).
94. The method of claim 93, wherein the response includes a modified transformed source code, and further comprising using a transformation symbols store to reverse transform the modified transformed source code (a modified source code input) and presenting the reverse-transformed response to the human user via the HID (Sharma, see at least [0004]; [0006; [0008] Figure 5 is a flowchart of example operations for training a fix suggestion pipeline that generates deidentified code flaw fix suggestions; [0015]; [0083] At block 815, the remediation service stores an association between an indication of the source code construct and an indication of its deidentified representation; [0028] At stage D …The repository 239 stores mappings between modified and original versions of program code determined to be potentially identifying of its source organization. …By storing mappings between original and deidentified flaw/fix information, if a deidentified fix is suggested for a flaw appearing in code belonging to its source organization (i.e., the fix is an intra-organization fix), the original representation(s) of the deidentified portion(s) of the fix can be presented instead of the deidentified representation to facilitate understanding of suggested fixes by users consuming the suggestions and incorporation of the suggested fixes into the software project if an intra- organization fix suggestion is selected; note that the stored mappings enable presenting the original representation of the deidentified portion (reversed transformation)).
95. The method of claim 94, wherein the transformation symbols store comprises mappings to reverse the one-way transform (Sharma, see at least [0015]; [0083] At block 815, the remediation service stores an association between an indication of the source code construct and an indication of its deidentified representation; [0028] At stage D …The repository 239 stores mappings between modified and original versions of program code determined to be potentially identifying of its source organization. …By storing mappings between original and deidentified flaw/fix information, if a deidentified fix is suggested for a flaw appearing in code belonging to its source organization (i.e., the fix is an intra-organization fix), the original representation(s) of the deidentified portion(s) of the fix can be presented instead of the deidentified representation to facilitate understanding of suggested fixes by users consuming the suggestions and incorporation of the suggested fixes into the software project if an intra- organization fix suggestion is selected; note that the stored mappings enable presenting the original representation of the deidentified portion (reverse transformation)).
98. The method of claim 93, wherein transforming the source code input comprises replacing function calls, variable names, scope names, and literals with values that do not have human-perceptible meaning (Sharma, see at least [0013]; [0034]; [0068] At block 614, the remediation service determines if the deidentified fix satisfies at least a first organization specificity criterion. Some fix suggestions originating from an organization’s program code, such as those utilizing proprietary or internal libraries, may be of limited utility to external organizations. The remediation service may address this by limiting inter-organizational fixes based on at least a first criterion for organization specificity. Organization specificity refers to the specificity of a fix to its source organization. For instance, a fix which includes one or more proprietary or internal code units would have a higher specificity to its source organization, while a fix in which deidentification was limited to obfuscating/removing names given to variables, standard data types, etc. ... to limit fix suggestions to intra-organization fixes; [0035], by obfuscating the source code or replacing the source code with a generic identifier (e.g., an identifier representing the type of the source code construct), to generate a deidentified representation of the source code; Note that which code element/unit is considered proprietary or sensitive information to be protected is a mere design choice by its organization/owner, not a technical requirement and obfuscated/deidentified code do not have human perceptible meaning).
99. The method of claim 93, wherein transforming the source code input comprises excluding system calls from transformation (Sharma, see at least [0013]; [0015], Potentially identifying code can include program code which does not correspond to known or publicly accessible code units/elements, such as standard libraries or open source libraries, or naming conventions used by an organization. After potentially identifying code is determined based on the structural context representation associated with a fix, the determined code can be modified in a manner which does not impact the overall structure of the program code of the fix; that is, the structure underlying the structural context representation is unchanged as a result of deidentification of the fix; [0034]; [0068] At block 614, the remediation service determines if the deidentified fix satisfies at least a first organization specificity criterion. Some fix suggestions originating from an organization’s program code, such as those utilizing proprietary or internal libraries, may be of limited utility to external organizations. The remediation service may address this by limiting inter-organizational fixes based on at least a first criterion for organization specificity. Organization specificity refers to the specificity of a fix to its source organization. For instance, a fix which includes one or more proprietary or internal code units would have a higher specificity to its source organization, while a fix in which deidentification was limited to obfuscating/removing names given to variables, standard data types, etc. ... to limit fix suggestions to intra-organization fixes; Note that which code element/unit is considered proprietary or sensitive information to be protected is a mere design choice by its organization/owner, not a technical requirement and the name of a system call itself are not obfuscated which will make the system crash as the OS will not understand the obfuscation mapping).
100. The method of claim 93, wherein transforming the source code input comprises excluding from transformation scope names, variables, parameters, default values, members, and function calls that belong to an external API or framework (Sharma, see at least [0013]; [0015], Potentially identifying code can include program code which does not correspond to known or publicly accessible code units/elements, such as standard libraries or open source libraries, or naming conventions used by an organization. After potentially identifying code is determined based on the structural context representation associated with a fix, the determined code can be modified in a manner which does not impact the overall structure of the program code of the fix; that is, the structure underlying the structural context representation is unchanged as a result of deidentification of the fix; [0018]; [0026] Criteria can include type, origin, and/or other features of source code constructs that potentially render the construct identifying of its source organization. For instance, the rules 221 may dictate that source code constructs which do not correspond to publicly accessible code elements/units (e.g., open source code units, standard code units, etc.) should be considered potentially identifying. Alternatively or in addition, the rules 221 may indicate that naming conventions, such as names assigned to variables, classes, routines/subroutines, or other constructs, are potentially identifying features. [0034]; [0042], the rules or criteria may indicate that program code that does not correspond to an open source code unit(s) or standard code unit(s) and/or naming conventions are to be considered program code that is potentially identifying of its source. [0068] At block 614, the remediation service determines if the deidentified fix satisfies at least a first organization specificity criterion. Some fix suggestions originating from an organization’s program code, such as those utilizing proprietary or internal libraries, may be of limited utility to external organizations. The remediation service may address this by limiting inter-organizational fixes based on at least a first criterion for organization specificity. Organization specificity refers to the specificity of a fix to its source organization... to limit fix suggestions to intra-organization fixes; Note that which code element/unit is considered proprietary or sensitive information to be protected is a mere design choice by its organization/owner, not a technical requirement).
101. The method of claim 93, wherein transforming the source code input comprises retaining numerical values (Sharma, see at least [0027] code may be modified by determining a generic identifier indicative of the type of the respective construct and replacing the construct with the generic identifier. As another example, code may be modified through obfuscation, such as by replacing the code with a string of randomly generated characters … Deidentification of potentially identifying code at the level of individual source code constructs represented in the AST diff 207 preserves of structure of the flaw/fix data 227, as the code de-identifier 126 does not modify the structure of the AST diff 207 when deidentifying the source code—that is, the AST diff 207 and deidentified AST diff 233 have the same structure. [0028]; [0049] where the modifying removes the potentially identifying information included therein (e.g., through obfuscation, removal and optional replacement with a generic identifier or placeholder, etc.; Note that the structure is preserved and mappings are retained for the deidentification indicating retained numerical values).
102. The method of claim 101, further comprising providing a strict mode to replace numerical values ((Sharma, see at least [0027] code may be modified by determining a generic identifier indicative of the type of the respective construct and replacing the construct with the generic identifier. As another example, code may be modified through obfuscation, such as by replacing the code with a string of randomly generated characters … Deidentification of potentially identifying code at the level of individual source code constructs represented in the AST diff 207 preserves of structure of the flaw/fix data 227, as the code de-identifier 126 does not modify the structure of the AST diff 207 when deidentifying the source code—that is, the AST diff 207 and deidentified AST diff 233 have the same structure. [0028]; [0049] where the modifying removes the potentially identifying information included therein (e.g., through obfuscation, removal and optional replacement with a generic identifier or placeholder, etc.; [0058] originated from program code belonging to or controlled by an organization. However, training data can also include program code retrieved from public repositories, such as open source repositories. … thus are not associated with an owning/controlling organization, deidentification operations described at block 505 can be omitted; Note that performing deidentification/obfuscation for proprietary and identified code for deidentification to protect corresponds to replacing numerical values in a strict mode).
104. The method of claim 93, wherein providing the one-way transform comprises using artificial intelligence within the one-way transform (Sharma, see at least [0018] To allow for training with the multi-organization training data without exposing proprietary information … modifies program code which is potentially identifying of its source organization, or the owning/controlling organization of the software project that is the source of the program code. … or obfuscating the code element; 0019]; [0103]; [0027]; [0028]; [0050] At block 507, the remediation service generates a vector representation of the structural context representation. Generating the vector representation allows the structural context to be fed or input into a machine learning model; [0015]; [0016]; [0018] The agent 117 communicates or inputs the flaws to the remediation service 119 to obtain potential fixes output by one or more of trained models 127; Note that obfuscating code secures the code against both reverse engineering and side channel attacks, thereof, it is one way transformation that is not internally reversible).
107. One or more tangible, nontransitory computer-readable storage media having stored thereon executable instructions to provide sanitized source code access to a generative artificial intelligence (GAI) for software development, the instructions, when executed to instruct a processor to: sanitize a source code input via a transform, wherein the transform is not internally reversible (Sharma, see at least [0014] preserving privacy in leveraging organization- specific remediation knowledge for flaw remediation across organizations; [0015] Deidentification therefore can be performed at the level of individual constructs in source code... Code deidentification is achieved through determining potentially identifying portions of a fix collected from an organization’s program code indicated in the associated structural context representation and removing, obfuscating, or otherwise modifying the potentially identifying code at one of several stages before the fix is presented as a suggestion … Deidentification can occur either before training of the fix suggestion model(s) or during prediction. When deidentification is implemented before training, flaws and corresponding fixes can be preprocessed to deidentify sensitive code while preparing the flaws and fixes to be used as training data …without compromising organizational privacy; [0016] [0018] To allow for training with the multi-organization training data without exposing proprietary information … modifies program code which is potentially identifying of its source organization, or the owning/controlling organization of the software project that is the source of the program code. … or obfuscating the code element; 0019]; [0103]; [0027]; [0028]; [0050] At block 507, the remediation service generates a vector representation of the structural context representation. Generating the vector representation allows the structural context to be fed or input into a machine learning model; Note that obfuscating code secures the code against both reverse engineering and side channel attacks, therefore, it is one way transformation that is not internally reversible).
send the sanitized source code input to the GAl with a query for the Gal (Sharma, see at least [0015] Deidentification can occur either before training of the fix suggestion model(s) or during prediction. When deidentification is implemented before training, flaws and corresponding fixes can be preprocessed to deidentify sensitive code while preparing the flaws and fixes to be used as training data …without compromising organizational privacy; [0016]; [0018] The agent 117 communicates or inputs the flaws to the remediation service 119 to obtain potential fixes output by one or more of trained models 127. The remediation service 119 includes the trained models 127, a repository 123 of multi-organization flaw/fix training data, and a model trainer 125 …To allow for training with the multi-organization training data without exposing proprietary information, the model trainer 125 utilizes a code de-identifier 126).
receive a response from the GAl with a transformed source code response; use a transformation symbols store to reverse transform the transformed source code response; and present the reverse transformed source code to a human user via a human interface device (HID) (Sharma, see at least [0019] The agent 117 can update the scan results 115A to include the suggested fixes 135. The agent 117 can pass the suggested fixes 135 in association with the corresponding remaining flaws to the software development tool 105 instance being used by the developer 101. The agent 117 may have its own user interface and present the suggested fixes 135 itself; [0008] Figure 5 is a flowchart of example operations for training a fix suggestion pipeline that generates deidentified code flaw fix suggestions; [0015]; [0083] At block 815, the remediation service stores an association between an indication of the source code construct and an indication of its deidentified representation; [0028] At stage D …The repository 239 stores mappings between modified and original versions of program code determined to be potentially identifying of its source organization. …By storing mappings between original and deidentified flaw/fix information, if a deidentified fix is suggested for a flaw appearing in code belonging to its source organization (i.e., the fix is an intra-organization fix), the original representation(s) of the deidentified portion(s) of the fix can be presented instead of the deidentified representation to facilitate understanding of suggested fixes by users consuming the suggestions and incorporation of the suggested fixes into the software project if an intra- organization fix suggestion is selected; note that the stored mappings enable presenting the original representation of the deidentified portion (reversed transformation) and the suggested fixes for the query are presented to a user, that is, via a HID).
109. The one or more tangible, nontransitory computer-readable storage media of claim 107, wherein the instructions are further to provide a lazy mode, wherein selected symbols are not sanitized (Sharma, see at least [0027] code may be modified by determining a generic identifier indicative of the type of the respective construct and replacing the construct with the generic identifier. As another example, code may be modified through obfuscation, such as by replacing the code with a string of randomly generated characters … Deidentification of potentially identifying code at the level of individual source code constructs represented in the AST diff 207 preserves of structure of the flaw/fix data 227, as the code de-identifier 126 does not modify the structure of the AST diff 207 when deidentifying the source code—that is, the AST diff 207 and deidentified AST diff 233 have the same structure. [0028]; [0049] where the modifying removes the potentially identifying information included therein (e.g., through obfuscation, removal and optional replacement with a generic identifier or placeholder, etc.; [0058] originated from program code belonging to or controlled by an organization. However, training data can also include program code retrieved from public repositories, such as open source repositories. … thus are not associated with an owning/controlling organization, deidentification operations described at block 505 can be omitted; Note that omitting deidentification/obfuscation for certain code such as open sources corresponds to a lazy mode).
110. The one or more tangible, nontransitory computer-readable storage media of claim 107, wherein the instructions are further to provide an integrated development environment (IDE) plugin to interact with the GAI (Sharma, see at least [0016] a remediation service 119 as communicating with a pipeline integrated agent … The CI pipeline 107 is implemented with a software development tool 105. An agent 117 can be program code integrated into the software development tool 105 or invoked from the software development tool 105, for example via an application programming interface (API)).
111. A computing apparatus for sanitizing source code within an enterprise, comprising: a hardware platform comprising a processor circuit and a memory; and instructions encoded within the memory to instruct the processor circuit to: use a one-way transform to sanitize a source code input (a sanitized source input), wherein the one-way transform is not internally reversible (Sharma, see at least [0014] preserving privacy in leveraging organization- specific remediation knowledge for flaw remediation across organizations; [0015] Deidentification therefore can be performed at the level of individual constructs in source code... Code deidentification is achieved through determining potentially identifying portions of a fix collected from an organization’s program code indicated in the associated structural context representation and removing, obfuscating, or otherwise modifying the potentially identifying code at one of several stages before the fix is presented as a suggestion … Deidentification can occur either before training of the fix suggestion model(s) or during prediction. When deidentification is implemented before training, flaws and corresponding fixes can be preprocessed to deidentify sensitive code while preparing the flaws and fixes to be used as training data …without compromising organizational privacy; [0016] [0018] To allow for training with the multi-organization training data without exposing proprietary information … modifies program code which is potentially identifying of its source organization, or the owning/controlling organization of the software project that is the source of the program code. … or obfuscating the code element; 0019]; [0103]; [0027]; [0028]; [0050] At block 507, the remediation service generates a vector representation of the structural context representation. Generating the vector representation allows the structural context to be fed or input into a machine learning model; Note that obfuscating code secures the code against both reverse engineering and side channel attacks, therefore, it is one way transformation that is not internally reversible).
send the sanitized source code to a third-party GAI, with a query for the third-party Gal (Sharma, see at least [0015] Deidentification can occur either before training of the fix suggestion model(s) or during prediction. When deidentification is implemented before training, flaws and corresponding fixes can be preprocessed to deidentify sensitive code while preparing the flaws and fixes to be used as training data …without compromising organizational privacy; [0016]; [0018] The agent 117 communicates or inputs the flaws to the remediation service 119 to obtain potential fixes output by one or more of trained models 127. The remediation service 119 includes the trained models 127, a repository 123 of multi-organization flaw/fix training data, and a model trainer 125 …To allow for training with the multi-organization training data without exposing proprietary information, the model trainer 125 utilizes a code de-identifier 126);
receive a response from the third-party GAI, including a transformed source code response; use a transformation symbols store to reverse transform the transformed source code response; and present the reverse transformed source code to a human user via a human interface device (HID) (Sharma, see at least [0019] The agent 117 can update the scan results 115A to include the suggested fixes 135. The agent 117 can pass the suggested fixes 135 in association with the corresponding remaining flaws to the software development tool 105 instance being used by the developer 101. The agent 117 may have its own user interface and present the suggested fixes 135 itself; [0008] Figure 5 is a flowchart of example operations for training a fix suggestion pipeline that generates deidentified code flaw fix suggestions; [0015]; [0083] At block 815, the remediation service stores an association between an indication of the source code construct and an indication of its deidentified representation; [0028] At stage D …The repository 239 stores mappings between modified and original versions of program code determined to be potentially identifying of its source organization. …By storing mappings between original and deidentified flaw/fix information, if a deidentified fix is suggested for a flaw appearing in code belonging to its source organization (i.e., the fix is an intra-organization fix), the original representation(s) of the deidentified portion(s) of the fix can be presented instead of the deidentified representation to facilitate understanding of suggested fixes by users consuming the suggestions and incorporation of the suggested fixes into the software project if an intra- organization fix suggestion is selected; Note that the stored mappings enable presenting the original representation of the deidentified portion (reversed transformation) and the suggested fixes for the query are presented to a user, that is, via a HID).
112. The computing apparatus of claim 111, further comprising instructions encoded within the memory to instruct the processor circuit to provide an integrated development environment (IDE), comprising an input window to interact with the third-party GAI (Sharma, see at least [0016] a remediation service 119 as communicating with a pipeline integrated agent … The CI pipeline 107 is implemented with a software development tool 105. An agent 117 can be program code integrated into the software development tool 105 or invoked from the software development tool 105, for example via an application programming interface (API); [0019] The agent 117 can pass the suggested fixes 135 in association with the corresponding remaining flaws to the software development tool 105 instance being used by the developer 101. The agent 117 may have its own user interface and present the suggested fixes 135 itself).
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 96, 97, and 108 are rejected under 35 U.S.C. 103 as being unpatentable over Zvenigorodsky (US20170351847).
Per claim 96:
Sharma does not explicitly teach storing the transformations symbols store only in volatile memory. Zvenigorodsky teaches storing the transformations symbols store only in volatile memory (abstract, The de-obfuscation call de-obfuscates obfuscated data values during runtime; claim 20, wherein the accessing, identifying, removing, de-obfuscating, and returning of data values occurs on a volatile memory of the computing device, such that the de-obfuscated data values are not preserved on the volatile memory and the obfuscated data value are preserved on a non-volatile electronic data store of the computing device). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Sharma’s code fix system with Zvenigorodsky’s volatile memory to modify Sharma’s system to combine the volatile memory storage, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development. Combining Zvenigorodsky’s functionality with that of Sharma results in a system that allow a volatile memory utilization. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to ensure that the mapping symbols to the protected code are not preserved on the volatile memory (abstract, The de-obfuscation call de-obfuscates obfuscated data values during runtime; claim 20, wherein the accessing, identifying, removing, de-obfuscating, and returning of data values occurs on a volatile memory of the computing device, such that the de-obfuscated data values are not preserved on the volatile memory and the obfuscated data value are preserved on a non-volatile electronic data store of the computing device).
Per claim 97:
Sharma further discloses storing the transformations symbols store on an enterprise-controlled memory, wherein the enterprise-controlled memory is controlled by an enterprise with a proprietary interest in the source code input (Sharma, see at least [0028] The repository 239 stores mappings between modified and original versions of program code determined to be potentially identifying of its source organization … By storing mappings between original and deidentified flaw/fix information… if an intra-organization fix suggestion is selected; [0083] At block 815, the remediation service stores an association between an indication of the source code construct and an indication of its deidentified representation).
Sharma does not explicitly teach that the memory is a volatile memory. Zvenigorodsky teaches storing on a volatile memory (abstract, The de-obfuscation call de-obfuscates obfuscated data values during runtime; claim 20, wherein the accessing, identifying, removing, de-obfuscating, and returning of data values occurs on a volatile memory of the computing device, such that the de-obfuscated data values are not preserved on the volatile memory and the obfuscated data value are preserved on a non-volatile electronic data store of the computing device). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Sharma’s code fix system with Zvenigorodsky’s volatile memory to modify Sharma’s system to combine the volatile memory storage, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development. Combining Zvenigorodsky’s functionality with that of Sharma results in a system that allow a volatile memory utilization. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to ensure that the mapping symbols to the protected code are not preserved on the volatile memory (abstract, The de-obfuscation call de-obfuscates obfuscated data values during runtime; claim 20, wherein the accessing, identifying, removing, de-obfuscating, and returning of data values occurs on a volatile memory of the computing device, such that the de-obfuscated data values are not preserved on the volatile memory and the obfuscated data value are preserved on a non-volatile electronic data store of the computing device).
Per claim 108, it is the media version of claim 96, and is rejected for the same reasons set forth in connection with the rejection of claim 96 above.
Claim 103 is rejected under 35 U.S.C. 103 as being unpatentable over Duan (CN 113760294).
Per claim 103:
Sharma teaches the one-way transformation for a local device. Sharma does not explicitly teach providing transformation as a background service. Duan teaches providing transformation as a background service (Duan, see at least fig. 1 and associated texts, the background service module is used for according to the confusion rule, obfuscating the source code, obtaining confusion cod; claim 8, a configuration centre; a background service module; a front end service module and a database; the configuration centre is used for configuring the confusion rule; the background service module is used for according to the confusion rule, obfuscating the source code, obtaining confusion code; the front end service module is used for visualizing the confusion process). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Sharma’s code fix system with Duan’s background service to modify Sharma’s system to combine the background service, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development. Combining Duan’s functionality with that of Sharma results in a system that allows running the transformation in the background. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to ensure a seamless security integration for productivity and efficiency (Duan, see at least fig. 1 and associated texts, the background service module is used for according to the confusion rule, obfuscating the source code, obtaining confusion cod; claim 8, a configuration centre; a background service module; a front end service module and a database; the configuration centre is used for configuring the confusion rule; the background service module is used for according to the confusion rule, obfuscating the source code, obtaining confusion code; the front end service module is used for visualizing the confusion process).
Claims 105 and 106 are rejected under 35 U.S.C. 103 as being unpatentable over Tsabba et al. (US10671806, hereafter Tsabba).
Per claim 105:
Sharma does not explicitly teach providing a text-to-speech engine to enable audio interaction with the third-party GAL. However, it is a well-known feature available in the industry. Tsabba teaches providing a text-to-speech engine to enable audio interaction with the third-party GAL (Tsabba, see at least Fig. 37-38 and associated texts, Speech APIsConvert speech to text or text to speech, translate text or audio, or add speaker recognition to your app, and Cognitive Services). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Sharma’s code fix system with Tsabba’s text-to-speech engine to modify Sharma’s system to combine the text-to-speech feature, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development or machine learning. Combining Tsabba’s functionality with that of Sharma results in a system that allows a text-to-speech interaction. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to enhance accessibility and efficiency (Tsabba, see at least Fig. 37-38 and associated texts, Speech APIsConvert speech to text or text to speech, translate text or audio, or add speaker recognition to your app, and Cognitive Services).
Per claim 106:
Sharma does not explicitly teach providing an image processor to track eye or head movement and to provide contextual hints based on an area of a screen a user views. However, Tsabba teaches providing an image processor to track eye or head movement and to provide contextual hints based on an area of a screen a user views (Tsabba, see at least Fig. 72 and associated texts, S The iris recognition must be passed positively to allow a user to use their eye movements to navigate the form using eye commands to create the form and/or fill in the form. The eye commands can move for example a textbox element on the form to a user desired position. The eye command can be used to select a form input element and the voice command to make the input audibly when filling out the form). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Sharma’s code fix system with Tsabba’s body movement recognition engine to modify Sharma’s system to combine the text-to-speech feature, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development or machine learning. Combining Tsabba’s functionality with that of Sharma results in a system that provides a hands-free interaction method. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to enhance accessibility, speed and efficiency (Tsabba, see at least Fig. 72 and associated texts, S The iris recognition must be passed positively to allow a user to use their eye movements to navigate the form using eye commands to create the form and/or fill in the form. The eye commands can move for example a textbox element on the form to a user desired position. The eye command can be used to select a form input element and the voice command to make the input audibly when filling out the form).
Examiner’s Note
The Examiner has pointed out particular references contained in the prior art of record within the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20250245302 is related to code obfuscation;
Priyanshu et al. is related to input regurgitation and prompt induced sanitization;
US20240319970 is related to using a large language model to generate executable code in a manner that preserves privacy and confidentiality of proprietary data;
US20240386103 is related to signing LLM prompt with a secret;
US20240354586 is related to mitigating Intellectual property leakage.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to INSUN KANG whose telephone number is (571)272-3724. The examiner can normally be reached M-TR 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, Chat Do can be reached at 571-272-3721. 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.
/INSUN KANG/ Primary Examiner, Art Unit 2193