DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 29 January 2026 has been entered. Applicant amended claims 1, 10, and 19 and previously cancelled claims 7 and 16. Accordingly, claims 1-6, 8-15, and 17-22 remain pending.
Response to Arguments
Applicant's arguments, filed 08 January 2026, regarding the 35 USC 103 rejection, have been fully considered but they are not persuasive.
Applicant’s remarks:
However, nowhere does Conikee discloses or otherwise renders obvious the features "executing the applying and annotating steps using a platform-agnostic and programming-language-agnostic annotation injector module configured to orchestrate data exchange among heterogeneous system components; accessing one or more external configuration or data files that are independent of the source code and define annotation behavior, wherein the one or more configuration or data files are expressed in a machine-readable format; wherein applying the artificial intelligence or machine learning algorithm further comprises identifying, from the source code, words, phrases, and syntactic or semantic patterns associated with confidential and sensitive information using one or more trained machine learning models; wherein the one or more trained machine learning models are generated using at least one of pattern-matching algorithms, dictionaries, linguistic corpora, lexical resources, or natural language processing (NLP) libraries" as now generally recited in claims 1, 10, and 19.
Examiner’s remarks:
This is not persuasive. Paragraph 79 of Conikee discloses executing language runtime agent. Paragraphs 25 and 83 of Conikee further disclose instrumenting of the runtime agent may be specifically configured in accordance to the code base of an application. The code profile may be converted to a runtime model of the code that can be used to instruct an agent on what aspects to instrument (monitor and/or regulate). Instrumenting the runtime agent may include analyzing the code profile and thereby identifying a subset of data flows related to sensitive data. Paragraph 17 further discloses managing different customer application (heterogeneous system component) and paragraph 63 reveals that selection of application code elements and how they are analyzed can differ depending on the application itself. Figure 2 and paragraph 27 further reveals accessing sensitive data policy (external data files, these data files are independent of the source code and define annotation behavior for detecting sensitive data). The sensitive data policy no, of a preferred embodiment, functions as a language library to help identify and evaluate sensitive data within the application code. The sensitive data policy may provide a language model used in interpreting semantics of the application code. The sensitive data policy preferably includes a dictionary of semantically loaded terms that can indicate sensitive data. The sensitive data policy is preferably a structured text file of different sensitive data terms and their characterizations. The sensitive data policy preferably includes an exhaustive list of terms or word tokens, phrases, and other language elements that define a framework for how sensitive data may be indicated. Paragraphs 62 and 69 of Conikee further disclose processing a semantic description of data in an application may include applying natural language processing and/or using machine learning techniques. A machine learning model can be built based on training data relating to natural language semantics and their “sensitivity” classification. Also, see rejection below.
Applicant’s remarks
Nowhere does Raviv, Bettin, and Dande disclose or otherwise renders obvious the features "executing the applying and annotating steps using a platform-agnostic and programming- language-agnostic annotation injector module configured to orchestrate data exchange among heterogeneous system components; accessing one or more external configuration or data files that are independent of the source code and define annotation behavior, wherein the one or more configuration or data files are expressed in a machine-readable format; wherein applying the artificial intelligence or machine learning algorithm further comprises identifying, from the source code, words, phrases, and syntactic or semantic patterns associated with confidential and sensitive information using one or more trained machine learning models; wherein the one or more trained machine learning models are generated using at least one of pattern-matching algorithms, dictionaries, linguistic corpora, lexical resources, or natural language processing (NLP) libraries" as now generally recited in claims 1, 10, and 19.
Examiner’s remarks: This is not persuasive please see remarks above and rejection below.
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-6, 10-15, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Conikee et al US 20190171846 (hereinafter Conikee), in view of Raviv et al US 20190213355 (hereinafter Raviv), and in further view of Bettin et al US 20230025341 (hereinafter Bettin).
As to claim 1, Conikee teaches a method for protecting sensitive information by utilizing one or more processors along with allocated memory (abstract and Figure 4 disclose method for monitoring and protecting sensitive data. Paragraph 102 discloses the system and method are implemented via instructions stored in memory and executed by a processor), the method comprising:
receiving source code associated with an application …. (Figures 1 and 2, and paragraph 25 reveal application code is received by the code semantic engine and the code profile. The code semantic engine and the code profile are part of the system, which accordingly to paragraph 102 is implemented via software instructions stored in memory and executing by a processor. Paragraphs 19 and 21 disclose the method detects sensitive data during development stages);
parsing the source code to identify a field declaration (paragraph 14 discloses the system inspect the context of data in the code and the language used to name and described the data; paragraph 61 discloses processing a semantic description of data in an application code. Paragraph 41 discloses the code semantics engine of a preferred embodiment functions to identify sensitive data from semantic aspects of the application. The semantic aspects preferably include comments, code documentation (e.g. inline code commentary), and function and variable names);
comparing the identified field declaration with a list of prestored declarations known to be associated with confidential and sensitive information data (Conikee: paragraph 14 discloses the system inspect the context of data in the code and the language used to name and described the data; paragraph 61 discloses processing a semantic description of data in an application code. Paragraph 65 discloses processing a semantic description of data in an application code preferably also includes tokenizing code relating to data and matching the tokenized code elements to a sensitive data policy, wherein a sensitive data policy may function as dictionary of sensitive data language elements. Paragraph 66 discloses matching tokenized code elements to a sensitive data policy is preferably a component of processing a semantic description of data in an application code; and outputting a result of comparison);
outputting a result of comparison (Conikee: paragraph 41 discloses the code semantics engine of a preferred embodiment functions to identify sensitive data from semantic aspects of the application. The semantic aspects preferably include comments, code documentation (e.g. inline code commentary), and function and variable names. Paragraphs 50-51 disclose the sensitive data policy preferably specifies sensitive terms in a corresponding tokenized (tokenization is performed in the code semantic engine, see Figure 2) format and the scoring process of the code semantics engine preferably assesses semantic processing of the code across various aspects to output a sensitive data score. The sensitive data score is preferably dependent on the type of the sensitive data which may be assessed by the code semantics engine);
identifying, in response to parsing and the result of the comparison, variables or fields in the source code that include the sensitive information data (paragraph 14 discloses the system inspect the context of data in the code and the language used to name and described the data, which include identifying variables, classes, associated data structures, functions, comments, and other aspects as defined in a code base. Paragraph 61 discloses processing a semantic description of data in an application code, see also paragraphs 65-66 disclose as a result of the matching/result of the comparison, result in detection of data objects as being sensitive data);
applying artificial intelligence or machine learning algorithm to the source code to automatically identify variables that contain the sensitive information data based on the identified variables or fields and annotating accordingly (paragraphs 29, 62-63 and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names. Paragraph 45 discloses using natural language processing techniques and a default dictionary of indicative terms, sensitive data types may be identified by their name. Tagging directives may be used to mark data as sensitive. Sensitive data may additionally be characterized with a sensitive data score. Paragraph 64 discloses tagging sensitive data element/object as sensitive), wherein each annotation is [an indication] that data associated with corresponding annotation is confidential and sensitive information that should not be published, logged, or printed (paragraphs 45 and 64 disclose the tag data indicates sensitive data. Paragraph 86 reveals a security event can be triggered [such as detection of sensitive data] and a corresponding response taken [see paragraph 57, 90, and 97] to detect execution flows that may expose vulnerabilities such as logging sensitive data. Paragraph 97 discloses enforcement could be automatically invoked by the method to obfuscate the credit card number before writing to the log);
executing the applying and annotating steps using a platform-agnostic and programming- language-agnostic annotation injector module configured to orchestrate data exchange among heterogeneous system components (paragraph 79 discloses executing language runtime agent and this runtime agent is performed during the applying and annotating step. The runtime agent track and monitor the data and execution flow. Paragraphs 25 and 83 further disclose instrumenting of the runtime agent may be specifically configured in accordance to the code base of an application. The code profile may be converted to a runtime model of the code that can be used to instruct an agent on what aspects to instrument (monitor and/or regulate). Instrumenting the runtime agent may include analyzing the code profile and thereby identifying a subset of data flows related to sensitive data. Paragraph 17 discloses managing different customer application (heterogeneous system component) and paragraph 63 reveals that selection of application code elements and how they are analyzed can differ depending on the application itself. Figure 2 and paragraph 27 reveal accessing sensitive data policy (external data files, these data files are independent of the source code and define annotation behavior for detecting sensitive data);
accessing one or more external configuration or data files that are independent of the source code and define annotation behavior (figure 2 and paragraph 27 reveal accessing sensitive data policy (external data files, these data files are independent of the source code and define annotation behavior for detecting sensitive data). The sensitive data policy functions as a language library to help identify and evaluate sensitive data within the application code. The sensitive data policy may provide a language model used in interpreting semantics of the application code. The sensitive data policy preferably includes a dictionary of semantically loaded terms that can indicate sensitive data. The sensitive data policy is preferably a structured text file of different sensitive data terms and their characterizations. The sensitive data policy preferably includes an exhaustive list of terms or word tokens, phrases, and other language elements that define a framework for how sensitive data may be indicated. Paragraph 27 reveals the sensitive data policy includes a dictionary of semantically loaded terms that can indicate sensitive data. The sensitive data policy is preferably a structured text file of different sensitive data terms and their characterizations. The sensitive data policy preferably includes an exhaustive list of terms or word tokens, phrases, and other language elements that define a framework for how sensitive data may be indicated),
wherein the one or more configuration or data files are expressed in a machine-readable format (paragraph 27 reveals the sensitive data policy functions as a language library to help identify and evaluate sensitive data within the application code. The sensitive data policy is a structured text file of different sensitive data terms and their characterizations. A structured text file is machine readable);
wherein applying the artificial intelligence or machine learning algorithm further comprises identifying, from the source code, words, phrases, and syntactic or semantic patterns associated with confidential and sensitive information using one or more trained machine learning models (paragraphs 62 and 69 disclose processing a semantic description of data in an application may include applying natural language processing and/or using machine learning techniques. A machine learning model can be built based on training data relating to natural language semantics and their “sensitivity” classification. Paragraph 27 reveal accessing sensitive data policy (external data files, these data files are independent of the source code and define annotation behavior for detecting sensitive data). The sensitive data policy, of a preferred embodiment, functions as a language library to help identify and evaluate sensitive data within the application code. The sensitive data policy may provide a language model used in interpreting semantics of the application code. The sensitive data policy preferably includes a dictionary of semantically loaded terms that can indicate sensitive data. The sensitive data policy is preferably a structured text file of different sensitive data terms and their characterizations. The sensitive data policy preferably includes an exhaustive list of terms or word tokens, phrases, and other language elements that define a framework for how sensitive data may be indicated);
wherein the one or more trained machine learning models are generated using at least one of pattern-matching algorithms, dictionaries, linguistic corpora, lexical resources, or natural language processing (NLP) libraries (paragraphs 62 and 69 disclose processing a semantic description of data in an application may include applying natural language processing and/or using machine learning techniques. A machine learning model can be built based on training data relating to natural language semantics and their “sensitivity” classification); and
automatically updating the source code with the annotation (paragraphs 45-46, 69, and 72 discloses tagging directives may be used to mark data as sensitive in the application code. Paragraph 57 reveals the identifying sensitive data preferably includes processing a semantic description of data in an application code and characterizing the sensitive data. Monitoring flow of the data during application runtime preferably includes identifying and characterizing sensitive data through data usage, updating the characterization of the sensitive data, and enforcing security measures on the data. The method may function in identifying and characterizing sensitive data prior to and during an application runtime and aid in monitoring and protecting the sensitive data); and
automatically updating the database or the code editor with the updated source code so that changes made to the source code would be permanently implemented during compiling and deploying of the application (paragraph 86 reveals a security event can be triggered [such as detection of sensitive data] and a corresponding response taken [see paragraph 57, 90, and 96-97] to detect execution flows that may expose vulnerabilities such as logging sensitive data. Paragraph 96 reveals automatically responding to vulnerabilities. Paragraph 97 discloses responding to vulnerabilities may include automatically augmenting handling of sensitive data such as a runtime agent may be configured to implement supplemental sensitive data handling transformations or operations by obfuscating the data or obfuscating sections of the data. Paragraph 96 of Conikee discloses adding or modifying terms in a security code policy that may be stored in a database (see paragraphs 3 and 27). Paragraph 69 reveals an editable policy text/configuration file included with the source code of an application project can serve as input for the sensitive data policy. A runtime agent can be implemented in a code editor, and in Conikee paragraph 97, the runtime agent is configured to implement supplemental sensitive data handling transformations or operations and the handling operations may alternatively be changes to process in the application code (thus updating the application code). Paragraph 69 of Conikee also reveals a developmental tool can facilitate developer labeling of sensitive data objects within their coding environment. In one example a UI may be integrated into the development IDE that enables a convenient mechanism for labeling/classifying sensitive data, wherein annotations within the code itself may follow a pre-defined format or standard. These may be detected and (automatic) processed to apply the sensitive data directives. The labeling data can be used within that application directly. Additionally, the labeling data may be collected and used collectively across multiple applications (source codes) in training a machine learning classification model for automatic classification of sensitive data. Thus, the developer utilizes the code editor for updating/labeling the code, wherein a code editor is type of developer tool);
Conikee does not teach an application being developed from a database or a code editor; wherein each annotation is a hint that data associated with corresponding annotation is confidential and sensitive information.
Raviv teaches wherein each annotation is a hint that data associated with corresponding annotation is confidential and sensitive information (paragraph 292 discloses a configuration file can be used to annotate sensitive data in a code and a class annotated hints sensitive information).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive with Raviv’s teachings that an annotation hints sensitive information to signal to the editor or the debugger that the annotated variable/field in the code pertains to sensitive information and further distinguish between data that are not sensitive. Thus such annotations improve the debugger process and allow the system to predict future values of sensitive variables (paragraph 292 of Conikee).
The combination of Conikee in view of Raviv does not teach, but Bettin teaches an application being developed from a database or a code editor (paragraph 34 discloses a software program being developed within the code editor).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive in view of Raviv’s teachings that an annotation hints sensitive information with Bettin’s teachings of code editor to allow a compiler of the editor to compile the application within a development environment into an intermediate representation, wherein the system then analyzes/checks the compiled results/intermediate representation to ensure the source code of the application will execute properly when the source code is executed during runtime (paragraph 1 of Bettin).
As to claim 2, the combination of Conikee in view of Raviv and Bettin teaches wherein the sensitive information data includes one or more of the following data: name, address, phone number, social security number, credit card information, bank account, email address, customer spending data, customer health data, automated teller machine usage data, customer location data, trading positions, employee information data, and sensitive company data (Conikee: paragraph 28 discloses sensitive data include credit card security codes, passwords, payment data (e.g., credit card data, billing information, bank account numbers, etc.), PII (e.g., first name, last name, address, social security number, date of birth, username/login ID, taxpayer identification number, employer identification number, etc.), medical (e.g., electronic medical record, electronic hospital record, patient, systolic, cholesterol, etc.)).
As to claim 3, the combination of Conikee in view of Raviv and Bettin teaches wherein in automatically annotating the identified sensitive information data (as disclosed in claim 1 above), and the method further comprising: marking a field or data element in the source code (Conikee: paragraphs 29, 62-63 and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names. Paragraph 45 discloses using natural language processing techniques and a default dictionary of indicative terms, sensitive data types may be identified by their name. Tagging directives may be used to mark data as sensitive. Sensitive data may additionally be characterized with a sensitive data score. Paragraph 64 discloses tagging sensitive data element/object as sensitive); and stating that the marked field or the data element should not be written in plain text or any human readable format prior to or during compilation and/or deployment of the application (Conikee: paragraphs 45 and 64 disclose the tag data indicates sensitive data. Paragraph 86 reveals a security event can be triggered [such as detection of sensitive data] and a corresponding response taken [see paragraph 57, 90, and 97] to detect execution flows that may expose vulnerabilities such as logging sensitive data. Paragraph 97 discloses enforcement could be automatically invoked by the method to obfuscate the credit card number before writing to the log).
As to claim 4, the combination of Conikee in view of Raviv and Bettin teaches wherein in parsing the source code, the method further comprising: checking the way fields are declared in the source code (Conikee: paragraph 14 discloses the system inspect the context of data in the code and the language used to name and described the data; paragraph 61 discloses processing a semantic description of data in an application code. Paragraphs 29, 62-63, and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names).
As to claim 5, the combination of Conikee in view of Raviv and Bettin teaches wherein in identifying sensitive information data, the method further comprising: applying the artificial intelligence or machine learning algorithm to identify words, phrases, and patterns from the source code that are known to be associated with confidential and sensitive information (Conikee: paragraphs 29, 62-63 and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names. Paragraph 45 discloses using natural language processing techniques and a default dictionary of indicative terms, sensitive data types may be identified by their name. Tagging directives may be used to mark data as sensitive. Sensitive data may additionally be characterized with a sensitive data score. Paragraph 64 discloses tagging sensitive data element/object as sensitive).
As to claim 6, the combination of Conikee in view of Raviv and Bettin teaches wherein in automatically annotating the identified sensitive information data, and the method further comprising: masking, hashing, not publishing or encrypting the identified sensitive information data (Conikee: paragraph 86 reveals a security event can be triggered [such as detection of sensitive data] and a corresponding response taken [see paragraph 57, 90, and 97] to detect execution flows that may expose vulnerabilities such as logging sensitive data. Paragraph 97 discloses enforcement could be automatically invoked by the method to obfuscate the credit card number before writing to the log. Paragraph 97 discloses responding to vulnerabilities may include automatically augmenting handling of sensitive data such as a runtime agent may be configured to implement supplemental sensitive data handling transformations or operations by obfuscating the data or obfuscating sections of the data; enforcement could be automatically invoked by the method to obfuscate the credit card number before writing to the log. These handling operations may be additional processes to those specified in the application code. The handling operations may alternatively be changes to process in the application code. For example, encrypting sensitive data with one form of encryption process may be changed to a second encryption process for enhanced encryption. These changes may be made during runtime, but could additionally or alternatively be implemented within the application code prior to execution and/or deployment).
As to claim 10, Conikee teaches a system for protecting sensitive information (abstract and Figure 4 disclose system and method for monitoring and protecting sensitive data), the system comprising:
a processor (paragraph 102 discloses the system and method are implemented via instructions stored in memory and executed by a processor);
a memory operatively connected to the processor via a communication interface, the memory storing computer readable instructions, when executed, cause the processor (paragraph 102 discloses the system and method are implemented via instructions stored in memory and executed by a processor. The instructions can be executed by computer-executable components (processor) integrated with the application, applet, host, server, network, website, communication service, communication interface, hardware/firmware/software elements of a user computer) to:
receive source code associated with an application …(Figures 1 and 2, and paragraph 25 reveal application code is received by the code semantic engine and the code profile. The code semantic engine and the code profile are part of the system, which accordingly to paragraph 102 is implemented via software instructions stored in memory and executing by a processor. Paragraphs 19 and 21 disclose the method detects sensitive data during development stages);
parse the source code to identify field declaration (paragraph 14 discloses the system inspect the context of data in the code and the language used to name and described the data; paragraph 61 discloses processing a semantic description of data in an application code. Paragraph 41 discloses the code semantics engine of a preferred embodiment functions to identify sensitive data from semantic aspects of the application. The semantic aspects preferably include comments, code documentation (e.g. inline code commentary), and function and variable names);
compare the identified field declaration with a list of prestored declarations known to be associated with confidential and sensitive information data (Conikee: paragraph 14 discloses the system inspect the context of data in the code and the language used to name and described the data; paragraph 61 discloses processing a semantic description of data in an application code. Paragraph 65 discloses processing a semantic description of data in an application code preferably also includes tokenizing code relating to data and matching the tokenized code elements to a sensitive data policy, wherein a sensitive data policy may function as dictionary of sensitive data language elements. Paragraph 66 discloses matching tokenized code elements to a sensitive data policy is preferably a component of processing a semantic description of data in an application code; and outputting a result of comparison);
output a result of comparison (Conikee: paragraph 41 discloses the code semantics engine of a preferred embodiment functions to identify sensitive data from semantic aspects of the application. The semantic aspects preferably include comments, code documentation (e.g. inline code commentary), and function and variable names. Paragraphs 50-51 disclose the sensitive data policy preferably specifies sensitive terms in a corresponding tokenized (tokenization is performed in the code semantic engine, see Figure 2) format and the scoring process of the code semantics engine preferably assesses semantic processing of the code across various aspects to output a sensitive data score. The sensitive data score is preferably dependent on the type of the sensitive data which may be assessed by the code semantics engine);
identify in response to parsing and the result of comparison, variables or fields in the source code that include the sensitive information data (paragraph 14 discloses the system inspect the context of data in the code and the language used to name and described the data, which include identifying variables, classes, associated data structures, functions, comments, and other aspects as defined in a code base. Paragraph 61 discloses processing a semantic description of data in an application code, see also paragraphs 65-66 disclose as a result of the matching/result of the comparison, result in detection of data objects as being sensitive data);
apply artificial intelligence or machine learning algorithm to the source code to automatically identify variables that contain the sensitive information data based on the identified variables or fields and annotating accordingly (paragraphs 29, 62-63 and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names. Paragraph 45 discloses using natural language processing techniques and a default dictionary of indicative terms, sensitive data types may be identified by their name. Tagging directives may be used to mark data as sensitive. Sensitive data may additionally be characterized with a sensitive data score. Paragraph 64 discloses tagging sensitive data element/object as sensitive), wherein each annotation is [an indication] that data associated with corresponding annotation is confidential and sensitive information that should not be published, logged, or printed (paragraphs 45 and 64 disclose the tag data indicates sensitive data. Paragraph 86 reveals a security event can be triggered [such as detection of sensitive data] and a corresponding response taken [see paragraph 57, 90, and 97] to detect execution flows that may expose vulnerabilities such as logging sensitive data. Paragraph 97 discloses enforcement could be automatically invoked by the method to obfuscate the credit card number before writing to the log);
execute the applying and annotating steps using a platform-agnostic and programming- language-agnostic annotation injector module configured to orchestrate data exchange among heterogeneous system components (paragraph 79 discloses executing language runtime agent. The runtime agent is performed during the applying and annotating steps. The runtime agent track and monitor the data and execution flow. Paragraphs 25 and 83 further disclose instrumenting of the runtime agent may be specifically configured in accordance to the code base of an application. The code profile may be converted to a runtime model of the code that can be used to instruct an agent on what aspects to instrument (monitor and/or regulate). Instrumenting the runtime agent may include analyzing the code profile and thereby identifying a subset of data flows related to sensitive data. Paragraph 17 discloses managing different customer application (heterogeneous system component) and paragraph 63 reveals that selection of application code elements and how they are analyzed can differ depending on the application itself. Figure 2 and paragraph 27 reveal accessing sensitive data policy (external data files, these data files are independent of the source code and define annotation behavior for detecting sensitive data);
access one or more external configuration or data files that are independent of the source code and define annotation behavior (figure 2 and paragraph 27 reveal accessing sensitive data policy (external data files, these data files are independent of the source code and define annotation behavior for detecting sensitive data). The sensitive data policy, of a preferred embodiment, functions as a language library to help identify and evaluate sensitive data within the application code. The sensitive data policy may provide a language model used in interpreting semantics of the application code. The sensitive data policy preferably includes a dictionary of semantically loaded terms that can indicate sensitive data. The sensitive data policy is preferably a structured text file of different sensitive data terms and their characterizations. The sensitive data policy preferably includes an exhaustive list of terms or word tokens, phrases, and other language elements that define a framework for how sensitive data may be indicated. Paragraph 27 reveals the sensitive data policy includes a dictionary of semantically loaded terms that can indicate sensitive data. The sensitive data policy is preferably a structured text file of different sensitive data terms and their characterizations. The sensitive data policy preferably includes an exhaustive list of terms or word tokens, phrases, and other language elements that define a framework for how sensitive data may be indicated),
wherein the one or more configuration or data files are expressed in a machine-readable format (paragraph 27 reveals the sensitive data policy functions as a language library to help identify and evaluate sensitive data within the application code. The sensitive data policy is a structured text file of different sensitive data terms and their characterizations. A structured text file is machine readable);
wherein applying the artificial intelligence or machine learning algorithm further comprises identifying, from the source code, words, phrases, and syntactic or semantic patterns associated with confidential and sensitive information using one or more trained machine learning models (paragraphs 62 and 69 disclose processing a semantic description of data in an application may include applying natural language processing and/or using machine learning techniques. A machine learning model can be built based on training data relating to natural language semantics and their “sensitivity” classification. Paragraph 27 reveal accessing sensitive data policy (external data files, these data files are independent of the source code and define annotation behavior for detecting sensitive data). The sensitive data policy, of a preferred embodiment, functions as a language library to help identify and evaluate sensitive data within the application code. The sensitive data policy may provide a language model used in interpreting semantics of the application code. The sensitive data policy preferably includes a dictionary of semantically loaded terms that can indicate sensitive data. The sensitive data policy is preferably a structured text file of different sensitive data terms and their characterizations. The sensitive data policy preferably includes an exhaustive list of terms or word tokens, phrases, and other language elements that define a framework for how sensitive data may be indicated);
wherein the one or more trained machine learning models are generated using at least one of pattern-matching algorithms, dictionaries, linguistic corpora, lexical resources, or natural language processing (NLP) libraries (paragraphs 62 and 69 disclose processing a semantic description of data in an application may include applying natural language processing and/or using machine learning techniques. A machine learning model can be built based on training data relating to natural language semantics and their “sensitivity” classification); and
automatically update the source code with the annotation (paragraphs 45-46, 69, and 72 discloses tagging directives may be used to mark data as sensitive in the application code. Paragraph 57 reveals the identifying sensitive data preferably includes processing a semantic description of data in an application code and characterizing the sensitive data. Monitoring flow of the data during application runtime preferably includes identifying and characterizing sensitive data through data usage, updating the characterization of the sensitive data, and enforcing security measures on the data. The method may function in identifying and characterizing sensitive data prior to and during an application runtime and aid in monitoring and protecting the sensitive data); and
automatically update the database or the code editor with the updated source code so that changes made to the source code would be permanently implemented during compiling and deploying of the application (paragraph 86 reveals a security event can be triggered [such as detection of sensitive data] and a corresponding response taken [see paragraph 57, 90, and 96-97] to detect execution flows that may expose vulnerabilities such as logging sensitive data. Paragraph 96 reveals automatically responding to vulnerabilities. Paragraph 97 discloses responding to vulnerabilities may include automatically augmenting handling of sensitive data such as a runtime agent may be configured to implement supplemental sensitive data handling transformations or operations by obfuscating the data or obfuscating sections of the data. Paragraph 96 of Conikee discloses adding or modifying terms in a security code policy that may be stored in a database (see paragraphs 3 and 27). Paragraph 73 reveals the sensitive data policy may function as a dictionary of terms, phrases and the code policy is user editable. Paragraph 69 reveals an editable policy text/configuration file included with the source code of an application project can serve as input for the sensitive data policy. It is the interpretation of the examiner that a runtime agent can be implemented in a code editor, and in Conikee paragraph 97, the runtime agent is configured to implement supplemental sensitive data handling transformations or operations and the handling operations may alternatively be changes to process in the application code (thus updating the application code).Paragraph 69 reveals a developmental tool can facilitate developer labeling of sensitive data objects within their coding environment. In one example a UI may be integrated into the development IDE that enables a convenient mechanism for labeling/classifying sensitive data, wherein annotations within the code itself may follow a pre-defined format or standard. These may be detected and (automatic) processed to apply the sensitive data directives. The labeling data can be used within that application directly. Additionally, the labeling data may be collected and used collectively across multiple applications (source codes) in training a machine learning classification model for automatic classification of sensitive data. Thus, the developer utilizes the code editor for updating/labeling the code, wherein a code editor is type of developer tool).
Conikee does not teach an application being developed from a database or a code editor; wherein each annotation is a hint that data associated with corresponding annotation is confidential and sensitive information.
Raviv teaches wherein each annotation is a hint that data associated with corresponding annotation is confidential and sensitive information (paragraph 292 discloses a configuration file can be used to annotate sensitive data in a code and a class annotated hints sensitive information).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive with Raviv’s teachings that an annotation hints sensitive information to signal to the editor or the debugger that the annotated variable/field in the code pertains to sensitive information and further distinguish between data that are not sensitive. Thus such annotations improve the debugger process and allow the system to predict future values of variables (paragraph 292 of Conikee).
The combination of Conikee in view of Raviv does not teach, but Bettin teaches an application being developed from a database or a code editor (paragraph 34 discloses a software program being developed within the code editor).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive in view of Raviv’s teachings that an annotation hints sensitive information with Bettin’s teachings of code editor to allow a compiler of the editor to compile the application within a development environment into an intermediate representation, wherein the system then analyzes/checks the compiled results/intermediate representation to ensure the source code of the application will execute properly when the source code is executed during runtime (paragraph 1 of Bettin).
As to claim 11, the combination of Conikee in view of Raviv and Bettin teaches wherein the sensitive information data includes one or more of the following data: name, address, phone number, social security number, credit card information, bank account, email address, customer spending data, customer health data, automated teller machine usage data, customer location data, trading positions, employee information data, and sensitive company data (Conikee: paragraph 28 discloses sensitive data include credit card security codes, passwords, payment data (e.g., credit card data, billing information, bank account numbers, etc.), PII (e.g., first name, last name, address, social security number, date of birth, username/login ID, taxpayer identification number, employer identification number, etc.), medical (e.g., electronic medical record, electronic hospital record, patient, systolic, cholesterol, etc.)).
As to claim 12, the combination of Conikee in view of Raviv and Bettin teaches wherein in automatically annotating the identified sensitive information data (see claim 1 above), and the method further comprising: marking a field or data element in the source code (Conikee: paragraphs 29, 62-63 and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names. Paragraph 45 discloses using natural language processing techniques and a default dictionary of indicative terms, sensitive data types may be identified by their name. Tagging directives may be used to mark data as sensitive. Sensitive data may additionally be characterized with a sensitive data score. Paragraph 64 discloses tagging sensitive data element/object as sensitive); and stating that the marked field or the data element should not be written in plain text or any human readable format prior to or during compilation and/or deployment of the application (Conikee: paragraphs 45 and 64 disclose the tag data indicates sensitive data. Paragraph 86 reveals a security event can be triggered [such as detection of sensitive data] and a corresponding response taken [see paragraph 57, 90, and 97] to detect execution flows that may expose vulnerabilities such as logging sensitive data. Paragraph 97 discloses enforcement could be automatically invoked by the method to obfuscate the credit card number before writing to the log).
As to claim 13, the combination of Conikee in view of Raviv and Bettin teaches wherein in parsing the source code, the method further comprising: checking the way fields are declared in the source code (Conikee: paragraph 14 discloses the system inspect the context of data in the code and the language used to name and described the data; paragraph 61 discloses processing a semantic description of data in an application code. Paragraphs 29, 62-63, and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names).
As to claim 14, the combination of Conikee in view of Raviv and Bettin teaches wherein in identifying sensitive information data, the method further comprising: applying the artificial intelligence or machine learning algorithm to identify words, phrases, and patterns from the source code that are known to be associated with confidential and sensitive information (Conikee: paragraphs 29, 62-63 and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names. Paragraph 45 discloses using natural language processing techniques and a default dictionary of indicative terms, sensitive data types may be identified by their name. Tagging directives may be used to mark data as sensitive. Sensitive data may additionally be characterized with a sensitive data score. Paragraph 64 discloses tagging sensitive data element/object as sensitive).
As to claim 15, the combination of Conikee in view of Raviv and Bettin teaches wherein in automatically annotating the identified sensitive information data, and the method further comprising: masking, hashing, not publishing or encrypting the identified sensitive information data (Conikee: paragraph 86 reveals a security event can be triggered [such as detection of sensitive data] and a corresponding response taken [see paragraph 57, 90, and 97] to detect execution flows that may expose vulnerabilities such as logging sensitive data. Paragraph 97 discloses enforcement could be automatically invoked by the method to obfuscate the credit card number before writing to the log. Paragraph 97 discloses responding to vulnerabilities may include automatically augmenting handling of sensitive data such as a runtime agent may be configured to implement supplemental sensitive data handling transformations or operations by obfuscating the data or obfuscating sections of the data; enforcement could be automatically invoked by the method to obfuscate the credit card number before writing to the log. These handling operations may be additional processes to those specified in the application code. The handling operations may alternatively be changes to process in the application code. For example, encrypting sensitive data with one form of encryption process may be changed to a second encryption process for enhanced encryption. These changes may be made during runtime, but could additionally or alternatively be implemented within the application code prior to execution and/or deployment).
As to claim 19, Conikee teaches a non-transitory computer readable medium configured to store instructions (paragraph 102 discloses the system and method are implemented via instructions stored in memory and executed by a processor) for protecting sensitive information (abstract and Figure 4 disclose system and method for monitoring and protecting sensitive data), the system comprising:
receiving source code associated with an application (paragraphs 19 and 21 disclose the method detects sensitive data during development stages. Figures 1 and 2, and paragraph 25 reveal application code is received by the code semantic engine and the code profile. The code semantic engine and the code profile are part of the system, which accordingly to paragraph 102 is implemented via software instructions stored in memory and executing by a processor );
parsing the source code to identify a field declaration (paragraph 14 discloses the system inspect the context of data in the code and the language used to name and described the data; paragraph 61 discloses processing a semantic description of data in an application code. Paragraph 41 discloses the code semantics engine of a preferred embodiment functions to identify sensitive data from semantic aspects of the application. The semantic aspects preferably include comments, code documentation (e.g. inline code commentary), and function and variable names);
comparing the identified field declaration with a list of prestored declarations known to be associated with confidential and sensitive information data (Conikee: paragraph 14 discloses the system inspect the context of data in the code and the language used to name and described the data; paragraph 61 discloses processing a semantic description of data in an application code. Paragraph 65 discloses processing a semantic description of data in an application code preferably also includes tokenizing code relating to data and matching the tokenized code elements to a sensitive data policy, wherein a sensitive data policy may function as dictionary of sensitive data language elements. Paragraph 66 discloses matching tokenized code elements to a sensitive data policy is preferably a component of processing a semantic description of data in an application code; and outputting a result of comparison);
outputting a result of comparison (Conikee: paragraph 41 discloses the code semantics engine of a preferred embodiment functions to identify sensitive data from semantic aspects of the application. The semantic aspects preferably include comments, code documentation (e.g. inline code commentary), and function and variable names. Paragraphs 50-51 disclose the sensitive data policy preferably specifies sensitive terms in a corresponding tokenized (tokenization is performed in the code semantic engine, see Figure 2) format and the scoring process of the code semantics engine preferably assesses semantic processing of the code across various aspects to output a sensitive data score. The sensitive data score is preferably dependent on the type of the sensitive data which may be assessed by the code semantics engine);
identifying in response to parsing and the result of comparison, variables or fields in the source code that include the sensitive information data (paragraph 14 discloses the system inspect the context of data in the code and the language used to name and described the data, which include identifying variables, classes, associated data structures, functions, comments, and other aspects as defined in a code base. Paragraph 61 discloses processing a semantic description of data in an application code, see also paragraphs 65-66 disclose as a result of the matching/result of the comparison, result in detection of data objects as being sensitive data);
applying artificial intelligence or machine learning algorithm to the source code to automatically identify variables that contain the sensitive information data based on the identified variables or fields and annotating accordingly (paragraphs 29, 62-63 and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names. Paragraph 45 discloses using natural language processing techniques and a default dictionary of indicative terms, sensitive data types may be identified by their name. Tagging directives may be used to mark data as sensitive. Sensitive data may additionally be characterized with a sensitive data score. Paragraph 64 discloses tagging sensitive data element/object as sensitive), wherein each annotation is [an indication] that data associated with corresponding annotation is confidential and sensitive information that should not be published, logged, or printed (paragraphs 45 and 64 disclose the tag data indicates sensitive data. Paragraph 86 reveals a security event can be triggered [such as detection of sensitive data] and a corresponding response taken [see paragraph 57, 90, and 97] to detect execution flows that may expose vulnerabilities such as logging sensitive data. Paragraph 97 discloses enforcement could be automatically invoked by the method to obfuscate the credit card number before writing to the log);
executing the applying and annotating steps using a platform-agnostic and programming- language-agnostic annotation injector module configured to orchestrate data exchange among heterogeneous system components (paragraph 79 discloses executing language runtime agent. The runtime agent is performed during the applying and annotating steps. The runtime agent track and monitor the data and execution flow. Paragraphs 25 and 83 further disclose instrumenting of the runtime agent may be specifically configured in accordance to the code base of an application. The code profile may be converted to a runtime model of the code that can be used to instruct an agent on what aspects to instrument (monitor and/or regulate). Instrumenting the runtime agent may include analyzing the code profile and thereby identifying a subset of data flows related to sensitive data. Paragraph 17 discloses managing different customer application (heterogeneous system component) and paragraph 63 reveals that selection of application code elements and how they are analyzed can differ depending on the application itself. Figure 2 and paragraph 27 reveal accessing sensitive data policy (external data files, these data files are independent of the source code and define annotation behavior for detecting sensitive data);
accessing one or more external configuration or data files that are independent of the source code and define annotation behavior (figure 2 and paragraph 27 reveal accessing sensitive data policy (external data files, these data files are independent of the source code and define annotation behavior for detecting sensitive data). The sensitive data policy, of a preferred embodiment, functions as a language library to help identify and evaluate sensitive data within the application code. The sensitive data policy may provide a language model used in interpreting semantics of the application code. The sensitive data policy preferably includes a dictionary of semantically loaded terms that can indicate sensitive data. The sensitive data policy is preferably a structured text file of different sensitive data terms and their characterizations. The sensitive data policy preferably includes an exhaustive list of terms or word tokens, phrases, and other language elements that define a framework for how sensitive data may be indicated. Paragraph 27 reveals the sensitive data policy includes a dictionary of semantically loaded terms that can indicate sensitive data. The sensitive data policy is preferably a structured text file of different sensitive data terms and their characterizations. The sensitive data policy preferably includes an exhaustive list of terms or word tokens, phrases, and other language elements that define a framework for how sensitive data may be indicated),
wherein the one or more configuration or data files are expressed in a machine-readable format (paragraph 27 reveals the sensitive data policy functions as a language library to help identify and evaluate sensitive data within the application code. The sensitive data policy is a structured text file of different sensitive data terms and their characterizations. A structured text file is machine readable);
wherein applying the artificial intelligence or machine learning algorithm further comprises identifying, from the source code, words, phrases, and syntactic or semantic patterns associated with confidential and sensitive information using one or more trained machine learning models (paragraphs 62 and 69 disclose processing a semantic description of data in an application may include applying natural language processing and/or using machine learning techniques. A machine learning model can be built based on training data relating to natural language semantics and their “sensitivity” classification. Paragraph 27 reveal accessing sensitive data policy (external data files, these data files are independent of the source code and define annotation behavior for detecting sensitive data). The sensitive data policy, of a preferred embodiment, functions as a language library to help identify and evaluate sensitive data within the application code. The sensitive data policy may provide a language model used in interpreting semantics of the application code. The sensitive data policy preferably includes a dictionary of semantically loaded terms that can indicate sensitive data. The sensitive data policy is preferably a structured text file of different sensitive data terms and their characterizations. The sensitive data policy preferably includes an exhaustive list of terms or word tokens, phrases, and other language elements that define a framework for how sensitive data may be indicated);
wherein the one or more trained machine learning models are generated using at least one of pattern-matching algorithms, dictionaries, linguistic corpora, lexical resources, or natural language processing (NLP) libraries (paragraphs 62 and 69 disclose processing a semantic description of data in an application may include applying natural language processing and/or using machine learning techniques. A machine learning model can be built based on training data relating to natural language semantics and their “sensitivity” classification); and
automatically updating the source code with the annotation (paragraphs 45-46, 69, and 72 discloses tagging directives may be used to mark data as sensitive in the application code. Paragraph 57 reveals the identifying sensitive data preferably includes processing a semantic description of data in an application code and characterizing the sensitive data. Monitoring flow of the data during application runtime preferably includes identifying and characterizing sensitive data through data usage, updating the characterization of the sensitive data, and enforcing security measures on the data. The method may function in identifying and characterizing sensitive data prior to and during an application runtime and aid in monitoring and protecting the sensitive data); and
automatically updating the database or the code editor with the updated source code so that changes made to the source code would be permanently implemented during compiling and deploying of the application (paragraph 86 reveals a security event can be triggered [such as detection of sensitive data] and a corresponding response taken [see paragraph 57, 90, and 96-97] to detect execution flows that may expose vulnerabilities such as logging sensitive data. Paragraph 96 reveals automatically responding to vulnerabilities. Paragraph 97 discloses responding to vulnerabilities may include automatically augmenting handling of sensitive data such as a runtime agent may be configured to implement supplemental sensitive data handling transformations or operations by obfuscating the data or obfuscating sections of the data. Paragraph 96 of Conikee discloses adding or modifying terms in a security code policy that may be stored in a database (see paragraphs 3 and 27). Paragraph 73 of Conikee reveals the sensitive data policy may function as a dictionary of terms, phrases and the code policy is user editable. Paragraph 69 of Conikee reveals an editable policy text/configuration file included with the source code of an application project can serve as input for the sensitive data policy. It is the interpretation of the examiner that a runtime agent can be implemented in a code editor, and in Conikee paragraph 97, the runtime agent is configured to implement supplemental sensitive data handling transformations or operations and the handling operations may alternatively be changes to process in the application code (thus updating the application code).Paragraph 69 of Conikee also reveals a developmental tool can facilitate developer labeling of sensitive data objects within their coding environment. In one example a UI may be integrated into the development IDE that enables a convenient mechanism for labeling/classifying sensitive data, wherein annotations within the code itself may follow a pre-defined format or standard. These may be detected and (automatic) processed to apply the sensitive data directives. The labeling data can be used within that application directly. Additionally, the labeling data may be collected and used collectively across multiple applications (source codes) in training a machine learning classification model for automatic classification of sensitive data. Thus, the developer utilizes the code editor for updating/labeling the code, wherein a code editor is type of developer tool).
Conikee does not teach an application being developed from a database or a code editor; wherein each annotation is a hint that data associated with corresponding annotation is confidential and sensitive information.
Raviv teaches wherein each annotation is a hint that data associated with corresponding annotation is confidential and sensitive information (paragraph 292 discloses a configuration file can be used to annotate sensitive data in a code and a class annotated hints sensitive information).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive with Raviv’s teachings that an annotation hints sensitive information to signal to the editor or the debugger that the annotated variable/field in the code pertains to sensitive information and further distinguish between data that are not sensitive. Thus such annotations improve the debugger process and allow the system to predict future values of variables (paragraph 292 of Conikee).
The combination of Conikee in view of Raviv does not teach, but Bettin teaches an application being developed from a database or a code editor (paragraph 34 discloses a software program being developed within the code editor).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive in view of Raviv’s teachings that an annotation hints sensitive information with Bettin’s teachings of code editor to allow a compiler of the editor to compile the application within a development environment into an intermediate representation, wherein the system then analyzes/checks the compiled results/intermediate representation to ensure the source code of the application will execute properly when the source code is executed during runtime (paragraph 1 of Bettin).
As to claim 20, the combination of Conikee in view of Raviv and Bettin teaches wherein the sensitive information data includes one or more of the following data: name, address, phone number, social security number, credit card information, bank account, email address, customer spending data, customer health data, automated teller machine usage data, customer location data, trading positions, employee information data, and sensitive company data (Conikee: paragraph 28 discloses sensitive data include credit card security codes, passwords, payment data (e.g., credit card data, billing information, bank account numbers, etc.), PII (e.g., first name, last name, address, social security number, date of birth, username/login ID, taxpayer identification number, employer identification number, etc.), medical (e.g., electronic medical record, electronic hospital record, patient, systolic, cholesterol, etc.)).
Claim(s) 8-9, 17-18, and 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Conikee et al US 20190171846 (hereinafter Conikee), in view of Raviv et al US 20190213355 (hereinafter Raviv), in further view of Bettin et al US 20230025341 (hereinafter Bettin), and in further view of Dande et al US 20230367636 (hereinafter Dande).
As to claim 8, the combination of Conikee in view of Raviv and Bettin teaches all the limitations recited in claim 1 above, but does not teach further comprising: determining that the result of comparison is a value that is less than a configurable threshold value; and determining that the identified field declaration does not include confidential and sensitive information data based on determining that the result of comparison is a value that is less than the configurable threshold value.
Dande teaches further comprising: determining that the result of comparison is a value that is less than a configurable threshold value; and determining that the identified field declaration does not include confidential and sensitive information data based on determining that the result of comparison is a value that is less than the configurable threshold value (paragraph 106 discloses the obfuscation engine compares the percentage (result/score) of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector with a threshold percentage (e.g., 90%, 95%, etc.). If the percentage of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector exceeds the threshold percentage, the obfuscation engine determines that the word matches or corresponds to the keyword (or the word is among the keywords). Otherwise, the obfuscation engine determines that the word does not match (when the percentage if less than the threshold percentage) or correspond to the keyword. If it is determined that the word matches the keyword, the obfuscation engine determines that the word is among the confidential information. Otherwise, the obfuscation engine determines that the word is not among the confidential information).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive in view of Raviv’s teachings that an annotation hints sensitive information and Bettin’s teachings of code editor with Dande’s teachings of determination whether field pertains to sensitive information to improve the detection of identifying confidential information and prevent confidential information from being exposed (paragraph 2 of Dande).
As to claim 9, the combination of Conikee in view of Raviv and Bettin teaches all the limitations recited in claim 1 above, and further teaches automatically annotating the identified field declaration as the identified sensitive information data (Conikee: paragraphs 29, 62-63 and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names. Paragraph 45 discloses using natural language processing techniques and a default dictionary of indicative terms, sensitive data types may be identified by their name. Tagging directives may be used to mark data as sensitive. Sensitive data may additionally be characterized with a sensitive data score. Paragraph 64 discloses tagging sensitive data element/object as sensitive).
The combination of Conikee in view of Raviv and Bettin does not teach further comprising: determining that the result of comparison is a value that is equal to or more than the configurable threshold value; determining that the identified field declaration includes confidential and sensitive information data based on determining that the result of comparison is a value that is equal to or more than the configurable threshold value.
Dande teaches further comprising: determining that the result of comparison is a value that is equal to or more than the configurable threshold value; determining that the identified field declaration includes confidential and sensitive information data based on determining that the result of comparison is a value that is equal to or more than the configurable threshold value (paragraph 106 discloses the obfuscation engine compares the percentage (result/score) of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector with a threshold percentage (e.g., 90%, 95%, etc.). If the percentage of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector exceeds the threshold percentage, the obfuscation engine determines that the word matches or corresponds to the keyword (or the word is among the keywords). Otherwise, the obfuscation engine determines that the word does not match (when the percentage if less than the threshold percentage) or correspond to the keyword. If it is determined that the word matches the keyword, the obfuscation engine determines that the word is among the confidential information. Otherwise, the obfuscation engine determines that the word is not among the confidential information).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive in view of Raviv’s teachings that an annotation hints sensitive information and Bettin’s teachings of code editor with Dande’s teachings of determination whether field pertains to sensitive information to improve the detection of identifying confidential information and prevent confidential information from being exposed (paragraph 2 of Dande).
As to claim 17, the combination of Conikee in view of Raviv and Bettin teaches all the limitations recited in claim 10 above, but does not teach further comprising: determining that the result of comparison is a value that is less than a configurable threshold value; and determining that the identified field declaration does not include confidential and sensitive information data based on determining that the result of comparison is a value that is less than the configurable threshold value.
Dande teaches further comprising: determining that the result of comparison is a value that is less than a configurable threshold value; and determining that the identified field declaration does not include confidential and sensitive information data based on determining that the result of comparison is a value that is less than the configurable threshold value (paragraph 106 discloses the obfuscation engine compares the percentage (result/score) of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector with a threshold percentage (e.g., 90%, 95%, etc.). If the percentage of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector exceeds the threshold percentage, the obfuscation engine determines that the word matches or corresponds to the keyword (or the word is among the keywords). Otherwise, the obfuscation engine determines that the word does not match (when the percentage if less than the threshold percentage) or correspond to the keyword. If it is determined that the word matches the keyword, the obfuscation engine determines that the word is among the confidential information. Otherwise, the obfuscation engine determines that the word is not among the confidential information).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive in view of Raviv’s teachings that an annotation hints sensitive information and Bettin’s teachings of code editor with Dande’s teachings of determination whether field pertains to sensitive information to improve the detection of identifying confidential information and prevent confidential information from being exposed (paragraph 2 of Dande).
As to claim 18, the combination of Conikee in view of Raviv and Bettin teaches all the limitations recited in claim 10 above, and further teaches automatically annotating the identified field declaration as the identified sensitive information data (Conikee: paragraphs 29, 62-63 and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names. Paragraph 45 discloses using natural language processing techniques and a default dictionary of indicative terms, sensitive data types may be identified by their name. Tagging directives may be used to mark data as sensitive. Sensitive data may additionally be characterized with a sensitive data score. Paragraph 64 discloses tagging sensitive data element/object as sensitive).
The combination of Conikee in view of Raviv and Bettin does not teach further comprising: determining that the result of comparison is a value that is equal to or more than the configurable threshold value; determining that the identified field declaration includes confidential and sensitive information data based on determining that the result of comparison is a value that is equal to or more than the configurable threshold value.
Dande teaches further comprising: determining that the result of comparison is a value that is equal to or more than the configurable threshold value; determining that the identified field declaration includes confidential and sensitive information data based on determining that the result of comparison is a value that is equal to or more than the configurable threshold value (paragraph 106 discloses the obfuscation engine compares the percentage (result/score) of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector with a threshold percentage (e.g., 90%, 95%, etc.). If the percentage of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector exceeds the threshold percentage, the obfuscation engine determines that the word matches or corresponds to the keyword (or the word is among the keywords). Otherwise, the obfuscation engine determines that the word does not match (when the percentage if less than the threshold percentage) or correspond to the keyword. If it is determined that the word matches the keyword, the obfuscation engine determines that the word is among the confidential information. Otherwise, the obfuscation engine determines that the word is not among the confidential information).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive in view of Raviv’s teachings that an annotation hints sensitive information and Bettin’s teachings of code editor with Dande’s teachings of determination whether field pertains to sensitive information to improve the detection of identifying confidential information and prevent confidential information from being exposed (paragraph 2 of Dande).
As to claim 21, the combination of Conikee in view of Raviv and Bettin teaches all the limitations recited in claim 19 above, but does not teach further comprising: determining that the result of comparison is a value that is less than a configurable threshold value; and determining that the identified field declaration does not include confidential and sensitive information data based on determining that the result of comparison is a value that is less than the configurable threshold value.
Dande teaches further comprising: determining that the result of comparison is a value that is less than a configurable threshold value; and determining that the identified field declaration does not include confidential and sensitive information data based on determining that the result of comparison is a value that is less than the configurable threshold value (paragraph 106 discloses the obfuscation engine compares the percentage (result/score) of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector with a threshold percentage (e.g., 90%, 95%, etc.). If the percentage of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector exceeds the threshold percentage, the obfuscation engine determines that the word matches or corresponds to the keyword (or the word is among the keywords). Otherwise, the obfuscation engine determines that the word does not match (when the percentage if less than the threshold percentage) or correspond to the keyword. If it is determined that the word matches the keyword, the obfuscation engine determines that the word is among the confidential information. Otherwise, the obfuscation engine determines that the word is not among the confidential information).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive in view of Raviv’s teachings that an annotation hints sensitive information and Bettin’s teachings of code editor with Dande’s teachings of determination whether field pertains to sensitive information to improve the detection of identifying confidential information and prevent confidential information from being exposed (paragraph 2 of Dande).
As to claim 22, the combination of Conikee in view of Raviv and Bettin teaches all the limitations recited in claim 19 above, and further teaches automatically annotating the identified field declaration as the identified sensitive information data (Conikee: paragraphs 29, 62-63 and 69 disclose processing a semantic description of data in an application code may include applying natural language processing and/or using machine learning classification model in the application code. Using machine learning techniques, the identification is based on language elements. Language elements preferably include data element names in the application code and code documentation. Data element names within the application code may include variables and variable object names. Paragraph 45 discloses using natural language processing techniques and a default dictionary of indicative terms, sensitive data types may be identified by their name. Tagging directives may be used to mark data as sensitive. Sensitive data may additionally be characterized with a sensitive data score. Paragraph 64 discloses tagging sensitive data element/object as sensitive).
The combination of Conikee in view of Raviv and Bettin does not teach further comprising: determining that the result of comparison is a value that is equal to or more than the configurable threshold value; determining that the identified field declaration includes confidential and sensitive information data based on determining that the result of comparison is a value that is equal to or more than the configurable threshold value.
Dande teaches further comprising: determining that the result of comparison is a value that is equal to or more than the configurable threshold value; determining that the identified field declaration includes confidential and sensitive information data based on determining that the result of comparison is a value that is equal to or more than the configurable threshold value (paragraph 106 discloses the obfuscation engine compares the percentage (result/score) of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector with a threshold percentage (e.g., 90%, 95%, etc.). If the percentage of the numerical values in the first vector that correspond or match counterpart numerical values in the second vector exceeds the threshold percentage, the obfuscation engine determines that the word matches or corresponds to the keyword (or the word is among the keywords). Otherwise, the obfuscation engine determines that the word does not match (when the percentage if less than the threshold percentage) or correspond to the keyword. If it is determined that the word matches the keyword, the obfuscation engine determines that the word is among the confidential information. Otherwise, the obfuscation engine determines that the word is not among the confidential information).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Conikee’s teachings of marking the data in the code as sensitive in view of Raviv’s teachings that an annotation hints sensitive information and Bettin’s teachings of code editor with Dande’s teachings of determination whether field pertains to sensitive information to improve the detection of identifying confidential information and prevent confidential information from being exposed (paragraph 2 of Dande).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FELICIA FARROW whose telephone number is (571)272-1856. The examiner can normally be reached M - F 7:30am-4:00pm (EST).
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 (571)270-5143. 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.
/F.F/Examiner, Art Unit 2437
/ALI S ABYANEH/Primary Examiner, Art Unit 2437