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 05/23/2025 has been entered.
Response to Arguments
The present office action is responsive to communications on 05/23/2025. Claims 1 and 19 have been amended. Claim 2 is cancelled. Claims 1 and 3-20 are currently pending. Applicant’s amendments to the claims and arguments have overcome each and every objection, and rejections that were previously forth in the Final Office Action mailed on 03/27/2025.
Applicant’s arguments filed on 05/23/2025, with respect to rejection of claims 1-2, 7, 9, 12-13, and 19 under 35 USC 103, as seen in pages 8-11, over Biddle et al. (US-20190114167-A1) in view of Yang et al. (US-20210286895-A1) and Bishop III et al. (US-20230177201-A1) have been fully considered and are persuasive, specifically with the amended limitation of the programming statement. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Lev Ran et al. (US-20220131865-A1), Linga et al. (US-20210256089-A1), and Palazzo et al. (US-20160255105-A1)
Claim Objections
Claims 1 and 3-20 are objected to because of the following informalities:
Claims 1/12: The claim language beginning “wherein the programming statement at least one of (i) accesses personally identifiable information of an end user of the software application or (ii) accesses privileged data of a device associated with the end user” is grammatically defective and improperly formatted. This constitutes a minor claim objection under the formality requirements for claim language. The examiner objects to the present wording because the insertion of “at least one of” disrupts the antecedent/verb relationship and creates ambiguity in the claim’s grammatical structure. This is a formal objection to be corrected by amendment and is not a substantive rejection of patentability.
Applicant is requested to amend the claim to correct the grammar and clarify the intended relationship between the subject (“the programming statement”), the verb, and the listed alternatives. Examples of acceptable amended phrasing include, without limitation:
“wherein the programming statement accesses one or more of: (i) personally identifiable information of an end user of the software application; and (ii) privileged data of a device associated with the end user.”
“wherein the programming statement is configured to access one or more of: (i) personally identifiable information of an end user of the software application; and (ii) privileged data of a device associated with the end user.”
Any equivalent amendment that corrects the grammatical construction and clearly defines the scope of the limitation will overcome this objection. Please submit proposed claim language in response to this Office communication.
Claims 3-11 and 13-20 directly or indirectly depend from the objected claims 1 and 12. Accordingly, the foregoing minor claim formality objection is also raised against dependent claims 3-11 and 13-20, as they incorporate the objected language by reference. Applicant may overcome the objection as to the dependent claims either by amending the base claims (1 and/or 12) to correct the objected language or by amending the dependent claims to remove or properly rephrase the objected language. Any amendment that properly corrects the grammatical/formatting defect in the objected language will overcome the objection for all affected dependent claims.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 3-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
The claims recite, inter alia, determining that a protected data element access does not have a match in a database of registered protected data elements and, responsive to determining that no match exists, “approving or disapproving a use of the at least one protected data element in accordance with a preference of the end user of the software application.” The written description requirement mandates that the specification reasonably convey to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date. Possession must be shown for the claimed invention as a whole, including the specific “no-match” decision logic and control flow recited in the claims.
The specification describes systems and methods in which, upon determining that a protected data element access does not match an entry in a database of registered protected data elements, the access is treated as not authorized and a developer-centric registration and approval workflow is initiated. The disclosed workflow includes generating a notification to a developer account, requesting additional information regarding the access (such as purpose, permission, or intended use), generating an approval process, and conditionally updating the database based on the outcome of that approval process prior to committing the code element.
The specification also describes that approved uses of protected data elements may be customized for individual end users, and gives examples where different users allow or disallow specific uses of their data. However, this disclosure relates to how approved uses and policies are defined and stored in the database, not to a control flow in which an initial “no-match” outcome itself is resolved by directly approving or disapproving a particular protected data element access “in accordance with a preference of the end user.” The specification does not describe, either expressly or inherently, a system in which an end-user preference is consulted responsive to a no-match determination to immediately approve or disapprove that access, as now claimed.
Accordingly, the claims recite a decision mechanism in which a “no match” outcome is resolved by approving or disapproving the use in accordance with an end-user preference, rather than by the disclosed developer notification and registration/approval workflow. The originally filed specification does not reasonably convey possession of this particular claimed control flow or authorization mechanism as of the filing date, and the limitation was added by amendment without supporting written description.
Therefore, claims 1 and 12 lack adequate written description support for the limitation requiring approving or disapproving a protected data element use, responsive to a no-match determination, in accordance with an end-user preference, and are rejected under 35 U.S.C. § 112(a).
The written description issue is properly raised under 35 U.S.C. § 112(a) because the claims, as amended during prosecution (see claims received 12/16/2024 and subsequently 05/27/2025), now recite subject matter that is not supported by the specification as originally filed. Upon renewed examination following the RCE, it was determined that the originally filed specification does not describe or contemplate the previously amended and claimed authorization decision based on an end-user preference responsive to a no-match determination, and the rejection is therefore properly made under §112(a).
Claims 3-11 and 13-20 directly or indirectly depend from the rejected claims 1 and 12. Accordingly, the foregoing rejection under 35 U.S.C. § 112(a) is also raised against dependent claims 3-11 and 13-20, as they incorporate the rejected language by reference. Applicant may overcome the rejection as to the dependent claims either by amending the base claims (1 and/or 12) to remove the unsupported language.
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 1, 3-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claims 1 and 12:
Applying the Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 110 USPQ2d 1976 (2014) and Mayo Collaborative Services v. Prometheus Labs., Inc., 566 U.S. 66, 101 USPQ2d 1961 (2012) framekwork:
Step 1: Statutory category determination.
The claim is drawn to a method (process). It falls within a statutory category under 35 U.S.C. § 101.
Step 2A, Prong 1: Identify judicial exception(s) with citations to PEG groupings
The claim(s) recite(s) the following abstract idea grouping:
B. Mental processes (observations, evaluations, determinations) that can be performed in the mind or with pen and paper:
“receiving a request to add a code element to a codebase for a software application.” (Perceiving and acknowledging a request is a cognitive act of observing and noting a communication. A human reviewer can read a message (e.g., an email or pull request) and mentally register that a request to add code has been made.)
“prior to adding the code element to the codebase, scanning the code element using an automated scan.” (“Scanning” a code element is equivalent to reading the text of code. A human can manually review the code line-by-line to look for particular patterns, which is an act of observation and evaluation.)
“the scan comprises at least one query that is configured to identify, in the code element, at least one protected data element access …” (Applying a “query” here is functionally applying a rule or checklist to the code. A human can mentally apply predefined criteria (e.g., “does this line access sensitive data?”) and identify instances by reading and marking up the code—an evaluation that can be performed with pen and paper.)
“detecting, by the scan of the code element, a programming statement of the code element that contains the at least one protected data element access, wherein the programming statement at least one of (i) accesses personally identifiable information of an end user of the software application or (ii) accesses privileged data of a device associated with the end user” (“Detecting” is recognizing or noticing a match to the criteria. A human can mentally flag a programming statement when it fits the rule being applied (e.g., a call that touches sensitive data), which is an act of identification. Determining whether a statement accesses PII or privileged device data is a classification judgment based on reading the code and recognizing known sensitive fields or APIs. This is a cognitive categorization that can be done by a human using a reference list.)
“searching a database of registered protected data elements for approved uses of the at least one protected data element access, wherein the database comprises relationships between protected data elements and code elements that access or use the protected data elements, and wherein the approved uses are customized for individual end users of the software application.” (“Searching” for approved uses can be performed by consulting a paper registry or spreadsheet, then cross-referencing the identified protected data element against recorded relationships and user-specific permissions. This is a look-up and comparison task that a human can do with notes and tables—an evaluative mental activity.)
“determining that the programming statement of the at least one protected data element access does not have a match in the database of registered protected data elements.” (Concluding that there is “no match” is a mental comparison outcome reached after review of the registry/records. A human makes this determination by checking entries and deciding no corresponding approval exists—an evaluative judgment.)
“responsive to determining that the programming statement does not have a match in the database, approving or disapproving a use of the at least one protected data element in accordance with a preference of the end user of the software application.” (“Approving or disapproving” is a decision based on policy or user preference. A human reviewer can decide whether to permit use according to documented preferences, which is classic decision-making in the mind.)
These are data-gathering and analysis determinations (receive, scan/analyze, detect/identify, search, determine,response) of the type found abstract in cases like Electric Power Group (collecting/analyzing information) and SAP v. InvestPic (data analysis), regardless of automation.
Step 2A, Prong 2: Analyze integration into a practical application
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because:
There is no recitation of a particular machine or specific computer architecture beyond generic components. The “automated scan” and “database” are claimed at a high level without technical detail of how they improve computer functionality (e.g., no specific static analysis pipeline, AST/IR transformations, finite automata constructions, concurrency control, cache/memory utilization improvements, or protocol-level enforcement mechanisms).
The pre-commit timing (“prior to adding the code element to the codebase”) is a mere field-of-use constraint and data processing context, not a technological transformation.
The steps of “receiving,” “scanning,” “detecting,” “searching,” “determining,” and “approving/disapproving” are extra-solution data processing and decision steps that simply apply the abstract authorization scheme to conventional software development workflow. They do not effect a transformation of an article, and do not impose meaningful limits beyond implementing the abstract idea on a computer.
Although the specification discusses benefits (traceability and auditability), the claim does not recite any concrete mechanism that improves computer performance or security at a technical level (contrast Finjan/Enfish claims). The “approved uses customized for individual end users” is a business rule, not a technical improvement to computer function.
Step 2B: Assess whether additional elements are significantly more:
The claim’s additional elements (generic “automated scan,” “query,” “database search,” “approval/disapproval according to user preferences,” and pre-commit timing) do not amount to “significantly more” than the abstract ideas.
Well-Understood, Routine, Conventional (WURC) analysis under Berkheimer:
The specification itself characterizes implementation using conventional, generic computing components and environments. See, e.g., Spec ¶¶ [00066]-[00075] (generic computer system 700, processor 702, memory 704/706, network interface 708, storage 740, general-purpose machine-readable media), indicating routine computer implementation.
The “queries” used to scan code elements rely on conventional techniques such as “string matching, regular expression matching, or tokenized pattern matching” (Spec ¶ [00040]). These are standard static/dynamic code analysis techniques widely used in the art, and the spec presents them as examples, not as novel improvements to computing technology.
Generic database searching and comparing metadata for matches (Spec ¶¶ [00042], [00064], [00077]-[00079]) are conventional data operations.
The claim lacks any non-conventional arrangement or an improvement to the functioning of the computer itself. There is no recited transformation of data into a new type of computer security object or enforcement mechanism that improves technology, nor any particular machine constraints.
On this record, the additional elements, viewed individually and in combination, are WURC activity that does not add “significantly more.”
Accordingly, the claim amounts to no more than applying the identified abstract ideas using generic computer functions, failing Prong 2.
Regarding claim 3:
Claim 3 depends from claim 1 and adds generating and sending a notification to a developer account that the protected data element access is not authorized. This limitation simply recites post-solution activity of presenting the results of the abstract evaluation (authorization status) to a user, which is a form of transmitting and displaying information long held to be abstract. The claim does not recite any particular improvement in how notifications are generated or delivered at a technical level, but instead uses generic computer messaging as a tool to communicate an abstract result, which is a conventional function that fails to integrate the abstract idea into a practical application or supply an inventive concept.
Regarding claim 4:
Claim 4 further recites requesting, from the developer account, additional information (purpose, citation to permission, intended use) and generating an approval process based on that additional information. These limitations are additional information-gathering, evaluation, and approval steps that fall within abstract ideas such as organizing human activity, managing permissions, and processing business or compliance information. The claim does not specify any particular technical mechanism for generating or executing the “approval process” beyond generic computer implementation and therefore merely automates an abstract review workflow using routine computer functions, which does not improve computer technology and does not amount to significantly more than the abstract idea.
Regarding claim 5:
Claim 5 adds inserting data relating to the protected data element access and its purpose/citation/intended use into the database and then committing the code element into the codebase. Storing information in a database and updating a code repository are basic data storage and transaction operations that constitute generic computer functions and are well-understood, routine, and conventional in the field of software development. These operations merely record the outcome of the abstract authorization decision and then proceed with a conventional commit operation, without any specific improvement to database technology, data structures, or version-control mechanisms, and therefore do not integrate the abstract idea into a practical application or provide an inventive concept.
Regarding claim 6:
Claim 6 recites, based on a response from the developer account, denying insertion of the additional information into the database and at least temporarily preventing the committing of the code element into the codebase. These are straightforward control-flow decisions (write data or not; commit or not) that are abstract decision-making steps implemented on a generic computer. Temporarily blocking a commit based on an approval response reflects a conventional access-control or gating operation and does not change how the computer or code repository functions at a technological level; it merely uses known mechanisms to enforce an abstract policy decision, which fails to amount to a practical application or inventive concept.
Regarding claim 7:
Claim 7 specifies that the query comprises a “priority level” used to determine whether to generate a notification, what type of notification to generate, or the level of detail in the notification. Assigning priority levels to events and using those levels to filter, categorize, or format notifications is a common information-management practice and thus falls within abstract concepts of organizing and presenting information. The claim does not recite any particular data structures, scheduling mechanisms, or improvements to notification technology; it simply applies a conventional prioritization scheme to the already abstract notification step, which remains generic post-solution activity and does not meaningfully limit the judicial exception.
Regarding claim 8:
Claim 8 adds that generating and sending the notification comprises filtering queries by the priority level such that notifications below a threshold are not sent. Filtering alerts or messages based on thresholds is a routine, conventional function of generic computer systems and user-notification frameworks. The claim merely automates the human practice of ignoring low-priority events and does not recite any specific technical improvement (e.g., specialized filtering hardware or non-conventional data structures), so it only adds further abstract information-filtering to the underlying abstract idea and fails to provide “significantly more” under Step 2B.
Regarding claim 9:
Claim 9 recites that searching the database comprises generating a comparison of metadata and determining whether an entry matches the protected data element access. Comparing metadata from a query to metadata stored in a database in order to find a match is a fundamental database operation and constitutes generic data analysis that is an abstract mental process when performed manually and routine when implemented on a generic computer. The claim does not specify any particular data structure, indexing scheme, or improvement to database search technology, and thus merely uses conventional database lookup techniques to implement the abstract authorization concept, which does not integrate the exception into a practical application or add an inventive concept.
Regarding claim 10:
Claim 10 specifies that the query is configured to identify various forms of permission declarations, sensitive data models, references, declarations, uses, classes, APIs, utility functions, and invocations. These limitations simply enumerate different types of code artifacts and access patterns to be checked, which reflects the abstract mental process of reviewing code to locate particular patterns or semantics, implemented with routine static or dynamic analysis on a generic computer. Listing additional categories of items to be searched does not change the nature of the claim from abstract information analysis and does not recite any unconventional scanning algorithm or computer improvement, so the added detail remains part of the abstract idea and lacks an inventive concept.
Regarding claim 11:
Claim 11 recites comparing the protected data element access to a purpose of use stored in the database, determining a match, and committing the code element into the codebase. Matching a requested use to a stored purpose and then allowing an action is an abstract authorization or policy‑enforcement decision that can be performed mentally and is therefore a judicial exception when implemented generically. Committing the code element after a match is a conventional follow‑on action that merely reflects the outcome of the abstract evaluation and relies on standard version‑control functionality, which is insufficient to integrate the abstract idea into a practical application or supply an inventive concept.
Regarding claim 13:
Claim 13, depending from system claim 12, merely specifies that the protected data element comprises personally identifiable information or privileged device data. Identifying particular content types or categories of data to which the abstract policy‑evaluation idea is applied does not change the character of the claim from abstract, because it simply limits the field of use to certain data and does not recite any technological improvement in how that data is processed. The claim therefore only adds field‑of‑use and data‑classification limitations that are insufficient to integrate the abstract idea into a practical application or provide an inventive concept.
Regarding claim 14:
Claim 14 adds that the processing device generates a notification to the developer account including an indication that the protected data element is not authorized. As with method claim 3, this is merely the presentation and transmission of the result of the underlying abstract authorization decision, implemented using generic messaging functionality of a conventional processing device. The claim does not improve the operation of the computer or network; instead, it uses the computer as a tool to convey an abstract result, which is insufficient to transform the judicial exception into eligible subject matter.
Regarding claim 15:
Claim 15 recites requesting, from a developer account, additional information (purpose of use, citation, intended use) and generating an approval process using the protected data element and the additional information. These steps amount to collecting and analyzing information and creating a workflow for approval, which fall squarely within abstract ideas such as managing permissions and organizing human activity. The limitations do not specify any improved computer functionality, particular machine architecture, or unconventional data structure, and therefore reflect routine, conventional computer implementation of an abstract approval scheme that does not provide significantly more than the judicial exception.
Regarding claim 16:
Claim 16 adds inserting the protected data element and its purpose/citation/intended use into the database and committing the code element into the codebase. These are standard database‑update and code‑commit operations that constitute generic computer activities widely recognized as well‑understood, routine, and conventional. Recording the result of an approval and performing a commit after approval are merely extra‑solution activities that follow from the abstract decision‑making and do not recite any specific advance in database or version‑control technology, thus failing to integrate the abstract idea into a practical application or provide an inventive concept.
Regarding claim 17:
Claim 17 specifies that, based on a response from the developer account, the system denies insertion of an entry for the protected data element into the database and at least temporarily prevents a commit. This reflects straightforward conditional logic and access control that are abstract decision‑making steps implemented using generic computer capabilities. Temporarily blocking database updates or commits is a conventional result of policy enforcement and does not recite any unconventional technical mechanism or improvement to the functioning of the computer system, so the claim remains directed to an abstract idea without an inventive concept.
Regarding claim 18:
Claim 18 adds that the processing device is further caused to receive, by a machine learning model, a set of training queries and protected data elements, and to train the model to generate at least one query based on a data set including at least one protected data element. Training a machine‑learning model on input/output pairs to generate queries is itself an abstract mathematical and data‑processing operation, analogous to using algorithms to generate rules from data, which falls within the category of mathematical concepts and mental processes. The claim does not recite any particular model architecture, training technique, or improvement to machine‑learning technology or computer functionality; rather, it uses conventional ML as a tool to automate the identification of query patterns for the same underlying abstract policy‑evaluation idea, which does not integrate the exception into a practical application or provide an inventive concept.
Regarding claim 19:
Claim 19 recites, for the system of claim 12, generating a comparison of metadata for each database entry with metadata of the protected data element and determining if at least one entry matches. As with method claim 9, this is a basic metadata comparison and lookup operation that constitutes generic data processing and database searching, which is abstract when claimed at this level of generality. The claim does not specify any unconventional data structures, indexing strategies, or improvements to how computers perform searches; it simply applies routine comparison functions to support the abstract authorization decision and therefore does not integrate the abstract idea into a practical application or supply an inventive concept.
Regarding claim 20:
Claim 20 specifies that the query is configured to identify various items such as sensitive permission declarations, runtime requests, variables, data models, references, declarations, uses, classes, APIs, utility functions, and invocations. These limitations parallel claim 10 and merely enumerate different forms of code constructs and access points to be examined, reflecting the abstract process of reviewing and classifying code artifacts for policy compliance. The claim does not recite any particular scanning algorithm, parsing technique, or improved representation of code; instead, it uses conventional code‑analysis capabilities of a generic computer to carry out the same abstract idea, and thus fails to integrate the exception into a practical application or provide an inventive concept under Step 2B.
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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1, 9, 12-13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lev Ran et al. (US-20220131865-A1) in view of Yang et al. (US-20210286895-A1) and Linga et al. (US-20210256089-A1).
With respect to claim 1, Lev Ran teaches a method comprising: receiving a request to add a code element to a codebase for a software application; (¶0078: Figure 3 shows a method for checking permissions computability between a configuration management system and orchestration system of a computing cluster. At 301, a user makes a change in a code file, which defined a configuration and/or in a configuration file (for example, adds a line, deletes a line or modifies line of code) and submits the change in a form of a change request, containing one or more files. );
prior to adding the code element to the codebase, scanning the code element using an automated scan; (¶0078: The submitted change request starts a change review flow, where changes in code files and configuration files are tested both automatically by running CI/CS tests and by checked by other users, which review the changes to verify the changes are accurate. );
detecting, by the scan of the code element, a programming statement of the code element that contains the at least one protected data element access, (¶0078: At 302, the permission checks agent 207, identifies a request to approve the change (e.g., the permission checks agent identifies the change request) was submitted in at least one file of the computing cluster.);
wherein the programming statement at least one of (i) accesses personally identifiable information of an end user of the software application or (ii) accesses privileged data of a device associated with the end user; (¶0078: At 303, the permission checks agent 207 retrieves from a repository 208 of the configuration management system 201 an identity of the user for performing the change.);
Lev Ran does not disclose:
the scan comprises at least one query that is configured to identify, in the code element, at least one protected data element access;
However, Yang teaches the scan comprises at least one query(¶0027: For example, program 150 utilizes static application security testing tools (SAST) that scan millions of lines of code to automatically identify critical vulnerabilities, such as buffer overflows, structured query language (SQL) injection, cross-site scripting, etc.) that is configured to identify, in the code element, at least one protected data element access; (¶0027: Accordingly, program 150 identifies one or more instances of confidential information ¶0026: In an embodiment, confidential information includes one or more of the following: API keys, database connection strings, IP addresses, certificates, encryption keys, Oauth tokens, certificates, privacy enhanced mail (PEM) files, passwords, personal data, environment variables, and passphrases.).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings in view of Yang with regards to an automated scan, querying, and a protected data element to the method of Lev Ran in order to centralize security which increases protection of code (Yang: ¶0001 &0010).
Lev Ran in view of Yang does not disclose:
searching a database of registered protected data elements for approved uses of the at least one protected data element access,
wherein the database comprises relationships between protected data elements and code elements that access or use the protected data elements, and
wherein the approved uses are customized for individual end users of the software application;
determining that the programming statement of the at least one protected data element access does not have a match in the database of registered protected data elements; and
responsive to determining that the programming statement does not have a match in the database,
approving or disapproving a use of the at least one protected data element in accordance with a preference of the end user of the software application.
However, Linga teaches searching a database of registered protected data elements for approved uses of the at least one protected data element access, (¶0059: Referring to Figure 1A , the network 100 includes an enterprise network 110 which represents a location where one or more user managed devices 102 may attempt to access 112 a code repository on a local enterprise server 104 and/or a remote code repository server 120 to access stored code. The credentials 106 may be based on a user profile or other credential management procedure, and may be stored in a database where the access permissions are identified and granted/denied. The code access attempts 112 may also be forwarded to a code repository server 120 in the cloud and permissions may be applied based on the stored credentials 106. );
wherein the database comprises relationships between protected data elements and code elements that access or use the protected data elements, and(¶0065: As further seen in Figure 1E illustrates limited access code access recording and management operation. The example includes accessing code segment ‘A’ 132 and performing a read, write, and save operation to both sub-portions including block ‘A’ 142 and block ‘B’ 144. The example also includes attempting a copy operation to block ‘A’ 142, which is flagged by the code repository server 120, which in this example is enforcing the limited access rights, however, any device could enforce the rights including an agent operating on the user device 102. The copy operation is not permitted in this example. Once the permitted and non-permitted actions are completed, the datastore 140 may store the access time, date, user profile, device profile, actions attempted, actions successful, actions rejected, etc.);
wherein the approved uses are customized for individual end users of the software application; (¶0069: According to one example, one specific function may be select a limited portion of the code which is properly accessed and authorized based on a user profile permission or other governing criteria. Further the code access and application of permissions/restrictions associated with user profile/ user device, the code may have selective access (customized for individual end users) applied to certain code blocks segments based on the rights, status, and/or other credentials associated with the user profiles or user devices accessing the code.);
determining that the programming statement of the at least one protected data element access does not have a match in the database of registered protected data elements; and (¶0062-0063: In one example of tracking code and code events, a code copy may be known to exist in a code repository based on a data file directory and/or data files containing the code in a particular at a particular storage location. In one example of tracking code and code “copy” permissions, a code copy may be detected between an enterprise repository and a data file directory and/or data files containing the code at a particular storage location.);
responsive to determining that the programming statement does not have a match in the database, approving or disapproving a use of the at least one protected data element in accordance with a preference of the end user of the software application. (¶0125: As seen in Figure 6D, the process may include identifying a user profile with limited access privileges to code and identifying whether credentials are required to perform one or more code events to code based on a status of code 692. The process may also include monitoring the one or more code events and determining sensitive code is included in the one or more code events, such as code identified by metadata or by other data attributes of the code and identifying the one or more user profiles has limited access privileges to the code, the process may also include comparing received commands to permitted commands associated with the limited access, and revoking the token associated with user profile responsive to identifying the received command is not permitted (approving or disapproving).);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings in view of Linga to the method of Lev Ran in view of Yang in order to provide a fundamental level of code access without permitting any unnecessary rights or privileges to the code development personnel and to prevent malicious access (Linga : ¶0002-0004).
With respect to claim 9, the combination of Lev Ran in view of Yang and Linga teaches the method of claim 1 (see rejection of claim 1 above) wherein searching the database of registered protected data elements for the protected data element access comprises: generating a comparison of metadata in the database of registered protected data elements with corresponding metadata of the protected data element access; and (Linga ¶0090-0091: As seen in Figure 4A, illustrates an example user interface of a code audit process for detecting code instances on a network. 400 illustrates a user interface with a summary of reporting operations, which demonstrates the results of a scan/search/audit operation(s) that attempted to identify all instances and related information of use, modification and storage of the code. );
determining, using the comparison, whether at least one entry in the database of registered protected data elements matches the protected data element access. (Linga ¶0090-0092: The code auditing/reporting results 400 may be realized by a server or devices which are configured to track instances of metadata or control data, such as: times, dates, locations, user profiles, egress operations, copying operations, modifying operations, deleting operations, etc., associated with the code. For example, generated alerts 402 may include secrets identified 404, such as tokens used, private data, egress actions 406, such as policy violations, unauthorized actions, new public and private repositories 408 identified as storing the code, etc.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings in view of Linga of searching the database to the method of Lev Ran in view of Yang in order to provide a fundamental level of code access without permitting any unnecessary rights or privileges to the code development personnel and to prevent malicious access (Linga : ¶0002-0004).
With respect to claim 12, Lev Ran teaches a system comprising: at least one memory device; and a processing device, operatively coupled to the at least one memory device, to: (¶0077: Figure 2 shows a system for checking permission compatibility between a configuration system and an orchestration system of a computing cluster, according to some embodiments of the present disclosure. The configuration system 201, includes a permission checks agent 207, which is a code executed by a server with at least one processor 209, which identifies a change that was made in a code file 203 defining a configuration of the computing cluster or in a configuration file, by a user.);
receive a request to add a code element to a codebase for a software application; (¶0078: The submitted change request starts a change review flow, where changes in code files and configuration files are tested both automatically by running CI/CS tests and by checked by other users, which review the changes to verify the changes are accurate. );
detect, by the scan of the code element, a programming statement of the code element that contains at least one protected data element access, (¶0078: At 302, the permission checks agent 207, identifies a request to approve the change (e.g., the permission checks agent identifies the change request) was submitted in at least one file of the computing cluster.);
wherein the programming statement at least one of (i) accesses personally identifiable information of an end user of the software application or (ii) accesses privileged data of a device associated with the end user; (¶0078: At 303, the permission checks agent 207 retrieves from a repository 208 of the configuration management system 201 an identity of the user for performing the change.);
Lev Ran does not disclose:
scan the code element using a scan that comprises a query that is customized to identify a protected data element;
However, Yang teaches scan the code element using a scan (¶0027: For example, program 150 utilizes static application security testing tools (SAST) that scan millions of lines of code to automatically identify critical vulnerabilities, such as buffer overflows, structured query language (SQL) injection, cross-site scripting, etc.) that comprises a query that is customized to identify a protected data element; (¶0027: Accordingly, program 150 identifies one or more instances of confidential information ¶0026: In an embodiment, confidential information includes one or more of the following: API keys, database connection strings, IP addresses, certificates, encryption keys, Oauth tokens, certificates, privacy enhanced mail (PEM) files, passwords, personal data, environment variables, and passphrases.).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings in view of Yang with regards to an automated scan, querying, and a protected data element to the method of Lev Ran in order to centralize security which increases protection of code (Yang: ¶0001 &0010).
Lev Ran in view of Yang does not disclose:
search a database of registered protected data elements for approved uses of the protected data element, wherein the database comprises relationships between protected data elements and code elements that access or use the protected data elements, and wherein the approved uses are customized for individual end users of the software application; and
in response to determining that the programming statement of the protected data element does not have a match in the database of registered protected data elements, approve or disapprove a use of the at least one protected data element in accordance with a preference of a-the end user of the software application.
However, Linga teaches search a database of registered protected data elements for approved uses of the protected data element, (¶0059: Referring to Figure 1A , the network 100 includes an enterprise network 110 which represents a location where one or more user managed devices 102 may attempt to access 112 a code repository on a local enterprise server 104 and/or a remote code repository server 120 to access stored code. The credentials 106 may be based on a user profile or other credential management procedure, and may be stored in a database where the access permissions are identified and granted/denied. The code access attempts 112 may also be forwarded to a code repository server 120 in the cloud and permissions may be applied based on the stored credentials 106. );
wherein the database comprises relationships between protected data elements and code elements that access or use the protected data elements, and (¶0065: As further seen in Figure 1E illustrates limited access code access recording and management operation. The example includes accessing code segment ‘A’ 132 and performing a read, write, and save operation to both sub-portions including block ‘A’ 142 and block ‘B’ 144. The example also includes attempting a copy operation to block ‘A’ 142, which is flagged by the code repository server 120, which in this example is enforcing the limited access rights, however, any device could enforce the rights including an agent operating on the user device 102. The copy operation is not permitted in this example. Once the permitted and non-permitted actions are completed, the datastore 140 may store the access time, date, user profile, device profile, actions attempted, actions successful, actions rejected, etc.);
wherein the approved uses are customized for individual end users of the software application; and (¶0069: According to one example, one specific function may be select a limited portion of the code which is properly accessed and authorized based on a user profile permission or other governing criteria. Further the code access and application of permissions/restrictions associated with user profile/ user device, the code may have selective access (customized for individual end users) applied to certain code blocks segments based on the rights, status, and/or other credentials associated with the user profiles or user devices accessing the code.);
in response to determining that the programming statement of the protected data element does not have a match in the database of registered protected data elements, (¶0062-0063: In one example of tracking code and code events, a code copy may be known to exist in a code repository based on a data file directory and/or data files containing the code in a particular at a particular storage location. In one example of tracking code and code “copy” permissions, a code copy may be detected between an enterprise repository and a data file directory and/or data files containing the code at a particular storage location.); approve or disapprove a use of the at least one protected data element in accordance with a preference of a-the end user of the software application. (¶0125: As seen in Figure 6D, the process may include identifying a user profile with limited access privileges to code and identifying whether credentials are required to perform one or more code events to code based on a status of code 692. The process may also include monitoring the one or more code events and determining sensitive code is included in the one or more code events, such as code identified by metadata or by other data attributes of the code and identifying the one or more user profiles has limited access privileges to the code, the process may also include comparing received commands to permitted commands associated with the limited access, and revoking the token associated with user profile responsive to identifying the received command is not permitted (approving or disapproving).);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings in view of Linga to the method of Lev Ran in view of Yang in order to provide a fundamental level of code access without permitting any unnecessary rights or privileges to the code development personnel and to prevent malicious access (Linga : ¶0002-0004).
With respect to claim 13, the combination of Lev Ran in view of Yang and Ling teaches the method of claim 12 (see rejection of claim 12 above) wherein the protected data element comprises personally identifiable information of an end user of the software application or privileged data of a device associated with the end user. (Lev Ran ¶0077-0080: As seen in Figure 2, once the permission checks agent 207, identifies there was a change in a file, which defined a configuration, the permission checks agent 207 retrieves from repositories 208, the user name or identity and the files that have been affected by the change that was made by the user.);
With respect to claim 19, the combination of Lev Ran in view of Yang and Linga teaches the method of claim 12 (see rejection of claim 12 above) wherein to search a database of registered protected data elements for the protected data element, the processing device is further caused to: generate a comparison of a metadata of each entry in the database of registered protected data elements with corresponding metadata of the protected data element; (Linga ¶0090-0091: As seen in Figure 4A, illustrates an example user interface of a code audit process for detecting code instances on a network. 400 illustrates a user interface with a summary of reporting operations, which demonstrates the results of a scan/search/audit operation(s) that attempted to identify all instances and related information of use, modification and storage of the code. );
and determine, using the comparison, if at least one entry in the database of registered protected data elements matches the protected data element. (Linga ¶0090-0092: The code auditing/reporting results 400 may be realized by a server or devices which are configured to track instances of metadata or control data, such as: times, dates, locations, user profiles, egress operations, copying operations, modifying operations, deleting operations, etc., associated with the code. For example, generated alerts 402 may include secrets identified 404, such as tokens used, private data, egress actions 406, such as policy violations, unauthorized actions, new public and private repositories 408 identified as storing the code, etc.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings in view of Linga of searching the database to the method of Lev Ran in view of Yang in order to provide a fundamental level of code access without permitting any unnecessary rights or privileges to the code development personnel and to prevent malicious access (Linga : ¶0002-0004).
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Lev Ran et al. (US-20220131865-A1) in view of Yang et al. (US-20210286895-A1), Linga et al. (US-20210256089-A1), and Carranza et al. (US-20190318366-A1).
With respect to claim 3, the combination of Lev Ran in view of Yang and Linga teaches the method of claim 1 (see rejection of claim 1 above) does not teach further comprising generating and sending a notification to a developer account associated with the request to commit the code element, wherein the notification comprises an indication to the developer account that the protected data element access is not authorized for inclusion in the software application.
Although in ¶0078 of Lev Ran discloses generating and receiving notification associated with request to commit the code element and wherein the notification comprises the protected data element access is not authorized for inclusion in the software application, but the prior art does not explicitly include the limitation of sending the notification to the developer account associated with the request to the commit the code element. However, Carranza teaches further comprising generating and sending a notification to a developer account associated with the request to commit the code element, wherein the notification comprises an indication to the developer account that the protected data element access is not authorized for inclusion in the software application. (¶0014-0015: When compliance tools find an issue the software commit, the developer receives a notification due to a detected compliance issue. ¶0081:As seen in Figure 1, In some examples, the compliance tool 108 may detect the use of a library that has been blacklisted by company “X” (e.g., the software is known to have certain security vulnerabilities, small maintainer based with few and/or irregular updates, etc.) and notify the CI platform 106 (related to the developer 102) that the build has failed security compliance check.).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings in view of Carranza with regards to the notification to the method of Lev Ran in view of Yang and Linga order to reduce the legal risks and security risks a company may encounter if a developer implements con-compliant software into a system (Carranza ¶0019).
With respect to claim 14, the combination of Lev Ran in view of Yang and Ling teaches the method of claim 12 (see rejection of claim 12 above) but does not disclose wherein the processing device is further caused to generate a notification to a developer account that is associated with the request to commit the code element and the notification includes an indication to the developer account that the protected data element is not authorized for inclusion in the software application.
Although in ¶0078 of Lev Ran discloses generating and receiving notification associated with request to commit the code element and wherein the notification comprises the protected data element access is not authorized for inclusion in the software application, but the prior art does not explicitly include the limitation of sending the notification to the developer account associated with the request to the commit the code element. However, Carranza teaches wherein the processing device is further caused to generate a notification to a developer account that is associated with the request to commit the code element and the notification includes an indication to the developer account that the protected data element is not authorized for inclusion in the software application. (¶0014-0015: When compliance tools find an issue the software commit, the developer receives a notification due to a detected compliance issue. ¶0081:As seen in Figure 1, In some examples, the compliance tool 108 may detect the use of a library that has been blacklisted by company “X” (e.g., the software is known to have certain security vulnerabilities, small maintainer based with few and/or irregular updates, etc.) and notify the CI platform 106 (related to the developer 102) that the build has failed security compliance check.).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings in view of Carranza with regards to the notification to the method of Lev Ran in view of Yang and Linga order to reduce the legal risks and security risks a company may encounter if a developer implements con-compliant software into a system (Carranza ¶0019).
Claims 4-6 are rejected under 35 U.S.C. 103 as being unpatentable over Lev Ran et al. (US-20220131865-A1) in view of Yang et al. (US-20210286895-A1), Linga et al. (US-20210256089-A1), Carranza et al. (US-20190318366-A1), and Watson et al. (US-20210216658-A1) .
With respect to claim 4, the combination of Lev Ran in view of Yang, Linga, and Carranza teaches the method of claim 3 (see rejection of claim 3) but does not disclose further comprising: requesting, from the developer account, additional information relating to the protected data element access, the additional information including at least one of a purpose of the protected data element access, a citation to a source of permission to use the protected data element access, or an intended use of the protected data element access; and generating an approval process for the protected data element access based on the additional information.
However, Watson teaches requesting, from the developer account, additional information relating to the protected data element access, the additional information including at least one of a purpose of the protected data element access, a citation to a source of permission to use the protected data element access, or an intended use of the protected data element access; (¶0051: As seen in Figure 4, if approver 406 disapproves access, reports, or digital artifacts at any point, data escrow system 408 can provide feedback (providing additional information) to requester 404 about any rules about the protected data so that requester 404 can modify the request and try again. For example, before requesting access to run the program that builds a learning model to analyze x-rays, the requester 404 can use requester interface 412 to determine how to access to certain kinds of protected patient x-ray records or other healthcare or medical information (such as intended use)) and generating an approval process for the protected data element access based on the additional information (¶0051: Data escrow system 408 can request approval 426 of the report from approver 406, receive approval 426 in response, and then provide the report 428 to requester 404. In addition to the report, digital artifacts (additional information) may have been created while the program ran on the protected data.)
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Watson with regards to an additional information the method of Lev Ran in view of Yang, Linga, and Carranza in order to efficiently manage data protection risks such as when approving protected data element access in relations with data protection compliance (Watson: ¶0006).
With respect to claim 5, the combination of Lev Ran in view of Yang, Linga, Carranza, and Watson teaches the method of claim 4 (see rejection of claim 4 above) further comprising: inserting data relating to the protected data element access and at least one of the purpose, the citation, or the intended use of the protected data element access into the database of registered protected data elements; (Watson ¶0051: Once approval 422 is received by data escrow system 408 from approver 406, then the data escrow system 408 can run the program on the protected data on behalf of the requester 404. As a result of running the program on the protected data, a report can be created by data escrow system 408 about the results. . Data escrow system 408 can send a record 436 to data owner 402 about how and what data was accessed (inserting additional data) by running the x-ray analysis model on the protected data that can be used for compliance by a health care organization.); and committing the code element into the codebase. (Lev Ran ¶0101- 104: Program instructions to identify a request to approve at least one change in at least one file defining a configuration of the computing cluster; program instructions to acquire a denial response or an approval response received in response to a query provisioned to the orchestration system, the query is for rights to change the at least one file using the identity of the user; in response to the approval response, program instructions to enter the approval response, into the configuration management system for confirming the checking permissions compatibility is approved; and in response to the denial received, program instructions to send a message to the configuration management system, the message is indicative that the checking permissions compatibility is not approved.);
Although Lev Ran does teach the approval committing the code element into the codebase but the prior art does not disclose the requirements of approval which is through inserting the data relating to the protected data element access. Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Watson with regards to inserting data relating to the protected data element access to the method of Lev Ran in view of Yang, Linga, and Carranza in order to efficiently manage data protection risks and data compliance such as facilitating the approval requests to the system (Watson: ¶0005-0006).
With respect to claim 6, the combination of Lev Ran in view of Yang, Linga, Carranza, and Watson teaches the method of claim 4 (see rejection of claim 4 above) further comprising: based on a response received from the developer account, denying insertion of the additional information relating to the protected data element access into the database of registered protected data elements; (Watson: ¶0040-0041: As seen in Figure 3, ff the central controller receives a disapproval, then method 300 ends at block 330. The central controller can notify the requester of the disapproval using the requester interface.).
and at least temporarily preventing the committing of the code element into the codebase. (Watson: ¶0051: If disapproval is received, then the requester 404 can make a different or modified request to access protected data 418 (indicating a temporary preventing system action (request)).
Although, Watson does not explicitly teaches temporarily preventing the committing the code element into the codebase but it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the substitute the teachings of Watson with regards to temporarily preventing request from happening by allowing requester to return an modified request to temporarily preventing the committing of code element since both are related to temporary prevention of a request actions.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Lev Ran et al. (US-20220131865-A1) in view of Yang et al. (US-20210286895-A1), Linga et al. (US-20210256089-A1), and Palazzo et al. (US-20160255105-A1) .
With respect to claim 7, the combination of Lev Ran in view of Yang and Linga teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the query comprises at least one of: a priority level usable to determine at least one of (i) whether to generate a notification; or (ii) a type of notification to generate; or (iii) an output level of detail that determines how much information about the protected data element access is included in the notification.
However, Palazzo teaches wherein the query comprises at least one of: a priority level usable to determine at least one of (i) whether to generate a notification; or (ii) a type of notification to generate; or (iii) an output level of detail that determines how much information about the protected data element access is included in the notification. (¶0010: Based upon receiving a response to the query, creating a security alert (or updating or amending a prior security alert) based on the response to the query and the security event data; assigning a priority to the security alert based on comparing the response to the query with a predetermined response database; and transmitting the security alert and the assigned priority to a computing system associated with security personnel (e.g. a security analyst) associated with the data communication network.).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Palazzo with regards to an query comprising at least one of a priority level the method of Lev Ran in view of Yang and Linga in order to detect suspicious activity and potential security breach (Palazzo: ¶0008).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Lev Ran et al. (US-20220131865-A1) in view of Yang et al. (US-20210286895-A1), Linga et al. (US-20210256089-A1), Palazzo et al. (US-20160255105-A1), Palazzo et al. (US-20160255105-A1), Carranza et al. (US-20190318366-A1), and Goenka et al. (US-20220078151-A1).
With respect to claim 8, the combination of Lev Ran in view of Yang, Linga, and Palazzo teaches the method of claim 7 (see rejection of claim 7 above) but does not disclose further comprising generating and sending a notification to a developer account associated with the request to commit the code element, wherein generating and sending the notification to the developer account comprises: filtering the queries by the priority level such that notifications for queries having a priority level below a threshold priority level are not sent to the developer account.
However, Carranza teaches further comprising generating and sending a notification to a developer account associated with the request to commit the code element, (¶0088: The inference program of Figure 6 may be repeated when the example CI platform 106 (in relations to the developer 102) receives a notification from the compliance tool 108 that a compliance issue has been detected in a new project commit.)
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings in view of Carranza with regards to the notification to the method of Lev Ran in view of Yang, Linga, and Palazzo in order to reduce the legal risks and security risks a company may encounter if a developer implements con-compliant software into a system (Carranza ¶0019).
Lev Ran in view of Yang, Linga, Palazzo, and Carranza does not disclose:
wherein generating and sending the notification to the developer account comprises: filtering the queries by the priority level such that notifications for queries having a priority level below a threshold priority level are not sent to the developer account.
However, Goenka wherein generating and sending the notification to the developer account comprises: filtering the queries (¶0028: In response, the method queries the databases to predict whether the incoming notification is high or low priority) by the priority level such that notifications for queries having a priority level (¶0008: For receiving a priority indicator in response to the querying; logic, executed by the processor, for determining that the priority indicator indicates a high priority; and logic, executed by the processor, for generating a second notification in response to determining that the priority indicator indicates a high priority.) below a threshold priority level (¶0033: In one embodiment, the method determines if the number of high priority records exceeds a fixed threshold. If so, the method ignores the low priority records and flags the incoming notification as a high priority notification. ) are not sent to the developer account. (¶0033: As illustrated in Figure 2, the priority indicator and query results (228) are transmitted to a decision engine (230). The decision engine (230) analyzes the priority indicator and determines whether to return an ignore flag (234) or return a notification (232). In one embodiment, if the decision engine determines that the priority indicator indicates a low priority notification, the decision engine (230) may ignore the notification.).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the substitute the teachings of Goenka with regards to filtering queries by priority levels to the method of Lev Ran in view of Yang, Linga, Palazzo, and Carranza in order to improve the usability notifications and to efficiently manage queries within the system (Goenka: ¶0005 &0050).
Claim 10, 11, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lev Ran et al. (US-20220131865-A1) in view of Yang et al. (US-20210286895-A1), Linga et al. (US-20210256089-A1), and Durand et al. (US-20230177201-A1).
With respect to claim 10, the combination of Lev Ran in view of Yang and Linga teaches method of claim 9 (see rejection of claim 9 above) but does not disclose wherein the at least one query is configured to identify at least one of a sensitive permission declaration, a run-time request for permission to access a protected data element, an access to a variable having a variable name that matches a name of a protected data element, a sensitive data model that stores one or more protected data elements, a reference to a sensitive data model, a declaration of a sensitive data model, a use of a sensitive data model, a class that instantiates a sensitive data model as a local variable or parameter, a sensitive application programming interface (API) that accesses one or more protected data elements, a utility function that transitively invokes a sensitive API, or an invocation of a sensitive API.
However, Durand teaches wherein the at least one query is configured to identify at least one of a sensitive permission declaration, a run-time request for permission to access a protected data element, an access to a variable having a variable name that matches a name of a protected data element, a sensitive data model that stores one or more protected data elements, a reference to a sensitive data model, a declaration of a sensitive data model, a use of a sensitive data model, a class that instantiates a sensitive data model as a local variable or parameter, a sensitive application programming interface (API) that accesses one or more protected data elements, a utility function that transitively invokes a sensitive API, or an invocation of a sensitive API. (Durand: ¶0189 & 0191-0195: An action may be performed in association with the resource and may, for example, be identified by a type of API call, a library call, a program, process, series of steps, a workflow, or some other such action. It should be noted that the key value (in the example, the current time) may be compared not only against literal values, but policy variables as well (variable have a variable name that matches a name of protected data element) . Various other types of condition operators may exist, which may be used for comparing string conditions, numeric conditions, Boolean conditions, binary conditions (e.g., testing values in binary format), IP address conditions (e.g., testing values against a specific IP address or range of IP addresses), and more. Conditions may, furthermore, include quantifiers. For example, a string condition may include an operator such as “StringEquals” that compares whether two strings are equal,).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings with of Durand regards to query is to configured to identify at least one of the sensitive permission declarations to the method of Lev Ran in view of Yang and Linga in order to improve security of the system and exposure of sensitive data via the benefit of compliance (Durand: ¶00155).
With respect to claim 11, the combination of Lev Ran in view of Yang and Linga teaches method of claim 9 (see rejection of claim 9 above) wherein determining, using the comparison, whether at least one entry in the database of registered protected data elements matches the protected data element access comprises: (Linga: ¶0087: The information is used to identify a location as acceptable or unacceptable in which case the code will be locked and unobtainable. The process also includes identifying a previous code location from the metadata associated with the code and updating code storage repository information based on the current code location, and determining whether the current code location is associated with code access privileges which match the previous code location. The code access and development privileges may vary depending on the current location data stored in the code log metadata.);
committing the code element into the codebase. (Lev Ran: ¶0084: Another example is “GitHub Actions” which could also be used to run various tooling on GitHub infrastructure. In both modes, the call includes needed information about a specific commit, such as the commit identifier, branch being merged, etc. The information is sufficient to access the repository and retrieve the relevant change set (or entire branch/pull request, if so desired).);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings in view of Linga of searching the database to the method of Lev Ran in view of Yang in order to provide a fundamental level of code access without permitting any unnecessary rights or privileges to the code development personnel and to prevent malicious access (Linga : ¶0002-0004).
Lev Ran in view of Yang and Linga does not disclose:
comparing the protected data element access to a purpose of use of the protected data element access stored in the database; determining that the protected data element access matches the purpose of use of the protected data element access stored in the database; and
However, Durand comparing the protected data element access to a purpose of use of the protected data element access stored in the database; (¶0066: As seen in Figure 3, Request context may be used to determine applicable policies, which may be evaluated in the context of the system call 310 to determine whether or not access to OS resource 312 should be granted.)
determining that the protected data element access matches the purpose of use of the protected data element access stored in the database; (¶0067: The query to the policy database 322 may be a request comprising information sufficient to determine a specific operating system context, such as an identifier associated with a mainframe workload that the operating system is being used to run.)
Although, Lev Ran and Linga teaches committing the code element into the codebase when certain requirements are fulfilled and the limitation of matching of protected data elements in a database but the combination does not disclose the method of fulfillment through determining the protected data element matching the purpose of the use of the protected data element access in the database . Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings with of Durand regards to determining that the protected data element access matches the purpose of use of the protected element accessed stored in the database to the method of Lev Ran in view of Yang and Linga in order to determine whether or not access to the resources of the system should be granted and to evaluate whether the user making the request has sufficient rights (Durand: ¶0066).
With respect to claim 20, the combination of Lev Ran in view of Yang and Linga teaches the method of claim 12 (see rejection of claim 12 above) does not disclose wherein the query is configured to identify at least one of a sensitive permission declaration, a run-time request for permission to access a protected data element, an access to a variable having a variable name that matches a name of a protected data element, a sensitive data model that stores one or more protected data elements, a reference to a sensitive data model, a declaration of a sensitive data model, a use of a sensitive data model, a class that instantiates a sensitive data model as a local variable or parameter, a sensitive application programming interface (API) that accesses one or more protected data elements, a utility function that transitively invokes a sensitive API, or an invocation of a sensitive API.
However, Durand teaches wherein the query is configured to identify at least one of a sensitive permission declaration, a run-time request for permission to access a protected data element, an access to a variable having a variable name that matches a name of a protected data element, a sensitive data model that stores one or more protected data elements, a reference to a sensitive data model, a declaration of a sensitive data model, a use of a sensitive data model, a class that instantiates a sensitive data model as a local variable or parameter, a sensitive application programming interface (API) that accesses one or more protected data elements, a utility function that transitively invokes a sensitive API, or an invocation of a sensitive API. (Durand: ¶0189 & 0191-0195: An action may be performed in association with the resource and may, for example, be identified by a type of API call, a library call, a program, process, series of steps, a workflow, or some other such action. It should be noted that the key value (in the example, the current time) may be compared not only against literal values, but policy variables as well (variable have a variable name that matches a name of protected data element) . Various other types of condition operators may exist, which may be used for comparing string conditions, numeric conditions, Boolean conditions, binary conditions (e.g., testing values in binary format), IP address conditions (e.g., testing values against a specific IP address or range of IP addresses), and more. Conditions may, furthermore, include quantifiers. For example, a string condition may include an operator such as “StringEquals” that compares whether two strings are equal,).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings with of Durand regards to query is to configured to identify at least one of the sensitive permission declarations to the method of Lev Ran in view of Yang and Linga in order to improve security of the system and exposure of sensitive data via the benefit of compliance (Durand: ¶00155).
Claim 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Lev Ran et al. (US-20220131865-A1) in view of Yang et al. (US-20210286895-A1), Linga et al. (US-20210256089-A1), and Watson et al. (US-20210216658-A1).
With respect to claim 15, the combination of Lev Ran in view of Yang and Linga teaches the method of claim 12 (see rejection of claim 12 above) but does not disclose wherein the processing device is further caused to: request, from a developer account, additional information relating to the protected data element, the additional information including at least one of a purpose of use of the protected data element, a citation to a source of permission to use the protected data element, or an intended use of the protected data element; and generate an approval process using the protected data element and the additional information.
However, Watson teaches wherein the processing device is further caused to: request, from a developer account, additional information relating to the protected data element, the additional information including at least one of a purpose of use of the protected data element, a citation to a source of permission to use the protected data element, or an intended use of the protected data element; and (¶0051: As seen in Figure 4, if approver 406 disapproves access, reports, or digital artifacts at any point, data escrow system 408 can provide feedback (providing additional information) to requester 404 about any rules about the protected data so that requester 404 can modify the request and try again. For example, before requesting access to run the program that builds a learning model to analyze x-rays, the requester 404 can use requester interface 412 to determine how to access to certain kinds of protected patient x-ray records or other healthcare or medical information (such as intended use)) generate an approval process using the protected data element and the additional information. (¶0051: Data escrow system 408 can request approval 426 of the report from approver 406, receive approval 426 in response, and then provide the report 428 to requester 404. In addition to the report, digital artifacts (additional information) may have been created while the program ran on the protected data.)
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Watson with regards to an additional information the method of Lev Ran in view of Yang and Linga in order to efficiently manage data protection risks such as when approving protected data element access in relations with data protection compliance (Watson: ¶0006).
With respect to claim 16, the combination of Lev Ran in view of Yang, Linga, and Watson teaches the method of claim 15 (see rejection of claim 15 above) wherein the processing device is further caused to: insert the protected data element and at least one of the purpose, the citation, or intended use of the protected data element into the database of registered protected data elements; (Watson ¶0051: Once approval 422 is received by data escrow system 408 from approver 406, then the data escrow system 408 can run the program on the protected data on behalf of the requester 404. As a result of running the program on the protected data, a report can be created by data escrow system 408 about the results. . Data escrow system 408 can send a record 436 to data owner 402 about how and what data was accessed (inserting additional data) by running the x-ray analysis model on the protected data that can be used for compliance by a health care organization.) and commit the code element into the codebase. (Lev Ran ¶0101- 104: Program instructions to identify a request to approve at least one change in at least one file defining a configuration of the computing cluster; program instructions to acquire a denial response or an approval response received in response to a query provisioned to the orchestration system, the query is for rights to change the at least one file using the identity of the user; in response to the approval response, program instructions to enter the approval response, into the configuration management system for confirming the checking permissions compatibility is approved; and in response to the denial received, program instructions to send a message to the configuration management system, the message is indicative that the checking permissions compatibility is not approved.);
Although Lev Ran does teach the approval committing the code element into the codebase but the prior art does not disclose the requirements of approval which is through inserting the data relating to the protected data element access. Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Watson with regards to inserting data relating to the protected data element access to the method of Lev Ran in view of Yang, Linga, and Carranza in order to efficiently manage data protection risks and data compliance such as facilitating the approval requests to the system (Watson: ¶0005-0006).
With respect to claim 17, the combination of Lev Ran in view of Yang, Linga , and Watson teaches the method of claim 15 (see rejection of claim 15 above) wherein the processing device is further caused to: based on a response received from the developer account, deny insertion an entry for the protected data element into the database of registered protected data elements; (Watson: ¶0040-0041: As seen in Figure 3, ff the central controller receives a disapproval, then method 300 ends at block 330. The central controller can notify the requester of the disapproval using the requester interface.) and at least temporarily prevent a commit of the code element into the codebase. (Watson: ¶0051: If disapproval is received, then the requester 404 can make a different or modified request to access protected data 418 (indicating a temporary preventing system action (request)).
Although, Watson does not explicitly teaches temporarily preventing the committing the code element into the codebase but it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the substitute the teachings of Watson with regards to temporarily preventing request from happening by allowing requester to return an modified request to temporarily preventing the committing of code element since both are related to temporary prevention of a request actions.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Lev Ran et al. (US-20220131865-A1) in view of Yang et al. (US-20210286895-A1), Linga et al. (US-20210256089-A1), and Nguyen et al. (US-20230316138-A1).
With respect to claim 18, the combination of Lev Ran in view of Yang and Linga teaches the method of claim 12 (see rejection of claim 12 above) wherein the processing device is further caused to: receive, by a machine learning model, a set of training queries and a set of training protected data elements; and train the machine learning model to generate at least one query based on a data set including at least one protected data element.
However, Nguyen teaches wherein the processing device is further caused to: receive, by a machine learning model, a set of training queries and a set of training protected data elements; and (¶0040: Specifically, the training data module 210 includes data that is used to establish relationships between known queries and corresponding responses. Based on this relationship, a new query can be received and a response generated. The training data module 210 can include information sources, profile information, past conversations (including queries and responses), and a set of queries.)
train the machine learning model to generate at least one query based on a data set including at least one protected data element. (0040: As seen in Figure 2, To generate responses to queries, each machine learning model implemented by the chat bot module 230 is trained by the machine learning technique training module 220 based on training data.)
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Nguyen with regards to a machine learning model the method of Lev Ran in view of Yang and Linga in order to a reduce redundancy and efficiently manage the of processing queries (Nguyen: ¶0003 & 0012).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR P VU whose telephone number is (703)756-1218. The examiner can normally be reached MON - FRI (7:30 - 5:00).
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.
/T.P.V./ Examiner, Art Unit 2437
/ALEXANDER LAGOR/ Supervisory Patent Examiner, Art Unit 2437