DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
The present office action is responsive to communications on 05/06/2026. Claims 1, 7, 10, 12, and 20 have been amended. Claim 2 has been previously 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 01/05/2026.
Applicant’s arguments and amendments with regards to 35 USC 101 with respect to claims 1 and 3-20, as seen in page 1-8, has been considered and persuasive. Applicant’s argument and amendments with regards to 35 USC 112 with respect to claims 1 and 3-20 have been considered and persuasive. Additionally applicant’s arguments and amendments filed on 05/06/2026, 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 Lev Ran et al. (US-20220131865-A1) in view of Yang et al. (US-20210286895-A1) and Linga et al. (US-20210256089-A1) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Grillo et al. (US PGPub No. 20150205600-A1) and Koorapati et al. (US Pat No.9479567-B1).
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 Grillo et al. (US PGPub No. 20150205600-A1) in view of Koorapati et al. (US Pat No.9479567-B1).
With respect to claim 1, Grillo teaches a method comprising: receiving a request from a code developer to commit a code element to a codebase for a software application; (Abstract: Techniques for enforcing software code review are described. For example, a commit request to commit ode to a repository is received (receiving a request to commit a code element to a codebase). );
by a protected data management system, executing a pre-commit scan on the code element; (¶0014: The process of transferring the change (or the changed code) to a code repository may be termed a check-in (“commitment”) process. The check-in process may start with a request to check in (or “commit”) a code module to a code repository. In some example embodiments, preliminary tests (executing a pre-commit scan on code element) with respect to the code module are performed. );
wherein the pre-commit scan searches the code element for a protected data element access within the code element; (¶0022: Upon receiving the commit request, the review enforcement system may determine, based on the ownership file or the commit (e.g., the name of the file in the commit request),or both, that a particular guarded directory (protected data element access) is destination of the code referenced (or included) in the commit request). );
wherein the protected data element access uses or accesses a protected data element during an execution of the code element by the software application; (¶0021:In certain, each project has its own directory in the repository. Further, each directory may include a configuration file (also referred to herein as an “ownership file”) that includes the ownership data for the particular project. The ownership file may specify one or more owners and one or more paths (e.g., directories or sub-directories) guarded by the owners (protected data element access uses). );
detecting, by the pre-commit scan of the code element, that a portion of the code element contains the protected data element access; (¶0021:In certain, each project has its own director in the repository. Further, each directory may include a configuration file (also referred to herein as an “ownership file”) that includes the ownership data for the particular project. The ownership file may specify one or more owners and one or more paths (e.g., directories or sub-directories) guarded by the owners (protected data element access uses). );
prior to committing the code element to the codebase, by the protected data management system, communicating the protected data element access to an inventory management system; (¶0049: As seen in Figure 1, in response to receiving a request to commit code to the repository (codebase), the review enforcement system 102 (inventory management system) may determine a user’s identifier based on the commit request (e.g., based on metadata that pertains to the commit request, based on the user’s client device associated with the user, etc.,) (communicating the protected data element to access to an inventory management system). );
by the inventory management system, searching a database of registered protected data elements for the protected data element access; (¶0051: Figure 2 is a block diagram of certain modules of an example review enforcement system. The analysis module 203 is configured to determine, based on the ownership file (as seen in 202 ownership module - configured to access a further ownership file in the repository 107 (database)) , whether an owner provided an indication of approval of the code requested to be committed to the repository 107(registered protected data elements for protected data element access) . In various example embodiments, in order to determine whether an owner provided an indication of approval of the code, the analysis module 203 determines a code identifier (e.g., a diff identifier, an upload file identifier, etc.) based on the commit request; );
wherein the database stores relationships between protected data elements and corresponding code elements that access or use the protected data elements; (¶0043: The ownership module 202 is configured to access ownership data (e.g., an ownership file in the repository 107). The ownership file includes a directory identifier of a directory of the repository 107, and an identifier of an owner who controls committing of code to the directory (relationship between protected data elements and corresponding code element that access). The review enforcement system 102 may enforce an owner's control over the committing of code to a particular directory by logically assigning the particular directory to the owner and by requesting that any code to be committed to the particular directory undergo the owner's review. );
wherein the registered code entry stores an authorized code element registered in the database via the inventory management system; (¶0076: Figure 5 is a flowchart diagram illustrating method steps of an example method for enforcing a software code review, consistent with some example embodiments. At method operation 502, the analysis module 203 determines, using the ownership data identified based on the commit request, whether the code was reviewed by the owner. In some instances, additional data may be used to determine whether the code was reviewed by the owner. The additional data may be included in a review ticket associated with the commit request, the code, the user, the owner, or a suitable combination thereof. The additional data may be located in the review system 103 (e.g., stored as a record in the ticket database 104). If the analysis module 203 determines that the code was reviewed by the owner (wherein registered code entry stores an authorized code element registered database) , then, at method operation 503, the analysis module 203 determines whether the owner gave permission to commit the code to the repository 107 . );
Grillo does not disclose:
wherein the protected data element comprises at least one of personally identifiable information of an end user of the software application or privileged data of a device associated with the end user;
by the inventory management system, communicating the no match determination to the protected data management system; and
by the inventory management system, communicating the no match determination to the protected data management system; and
by the protected data management system, preventing the code element from being committed to the codebase in response to the request from the code developer.
However, Koorapati teaches wherein the protected data element comprises at least one of personally identifiable information of an end user of the software application or privileged data of a device associated with the end user; (¶0079-0081: A user account identifier 312 of a user account record 310 in the metadata plane 180. In some example embodiments, a user account identifier 312 is a 128-bit value. An authorized content item identifier 314 of a user account record 310 identifies a content item namespace to which a user in possession of the user account identifier 312 of the user account record 310 is authorized to access (protected data element). );
determining that the protected data element access does not have a match in the database of registered protected data elements by comparing the protected data element access to a registered code entry; (¶0102: Figure 2 is a flow diagram of process for uploading a content item to a target block server. At step 214, the metadata server 150 authorizes the commit request received from a content item synchronization agent 114-1 This authorizing may include verifying that content item namespace identifier of the owning content item namespace specified in the commit request is one of the authorized content item namespace identifier(s) 314 of the user account record 310 in the metadata plane 180 corresponding to the user account identifier in the commit request.);
by the inventory management system, communicating the no match determination to the protected data management system; and by the protected data management system, preventing the code element from being committed to the codebase in response to the request from the code developer. (¶0077: If not, then the metadata server 150 (communicating to the protected data management system, as further seen in Figure 5, shows Metadata Server (protected data management system) in communication with the Metadata Plane (inventory management system) ) may deny the commit request and return an appropriate error message to the content item synchronization agent 114-1. );
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 Koorapati of matching protected data elements to the method of Grillo in order to verify commit request is authorized and prevent unauthorized access (Koorapati : ¶0002 & ¶0081).
With respect to claim 9, the combination of Grillo in view of Koorapati 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 (Koorapati ¶0079: Figure 3 represents user account and content item namespace metadata 30 (database) stored in the metadata 180. In particular, metadata plane 180 (which is used to search as previously seen in the steps of Figure 2 when verifying the user account) can store one or more user accounts held with online content management service. Among other information, a user account record 310 can have a user account identifier 312 and one or more authorized content item namespace identifiers 314. );
determining, using the comparison, whether at least one entry in the database of registered protected data elements matches the protected data element access. (Koorapati ¶0080-0082: An authorized content item identifier 314 of a user account record 310 identifies a content item namespace to which a user in possession of the user account identifier 312 of the user account record 310 is authorized to access. Thus, a user that holds a user account with the online content management service can have access to one or more content item namespaces associated with the user account. A user can acquire possession of a user account identifier 312 by providing valid authentication credentials (e.g., a valid username and password) associated with the user account identifier 312 (using the database of registered protected data elements matches (via verifying) the protected data element access).);
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 Koorapati of searching the database of registered protected data elements to the method of Grillo in order to verify commit request is authorized and prevent unauthorized access (Koorapati : ¶0002 & ¶0081).
With respect to claim 12, Grillo a system comprising: at least one memory device; and a processing device, operatively coupled to the at least one memory device, to: (¶0095: As seen in the example computer system 700 includes a processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 701 and a static memory 703, which communicate with each other via a bus 704.);
receive a request from a code developer to commit a code element to a codebase for a software application; (Abstract: Techniques for enforcing software code review are described. For example, a commit request to commit ode to a repository is received (receiving a request to commit a code element to a codebase). );
by a protected data management system, execute a pre-commit scan on the code element; (¶0014: The process of transferring the change (or the changed code) to a code repository may be termed a check-in (“commitment”) process. The check-in process may start with a request to check in (or “commit”) a code module to a code repository. In some example embodiments, preliminary tests (executing a pre-commit scan on code element) with respect to the code module are performed. );
wherein the pre-commit scan searches the code element for a protected data element access within the code element; (¶0022: Upon receiving the commit request, the review enforcement system may determine, based on the ownership file or the commit (e.g., the name of the file in the commit request),or both, that a particular guarded directory (protected data element access) is destination of the code referenced (or included) in the commit request). );
wherein the protected data element access uses or accesses a protected data element during an execution of the code element by the software application; (¶0021:In certain, each project has its own directory in the repository. Further, each directory may include a configuration file (also referred to herein as an “ownership file”) that includes the ownership data for the particular project. The ownership file may specify one or more owners and one or more paths (e.g., directories or sub-directories) guarded by the owners (protected data element access uses). );
detect, by the pre-commit scan of the code element, that a portion of the code element contains the protected data element access; (¶0021:In certain, each project has its own director in the repository. Further, each directory may include a configuration file (also referred to herein as an “ownership file”) that includes the ownership data for the particular project. The ownership file may specify one or more owners and one or more paths (e.g., directories or sub-directories) guarded by the owners (protected data element access uses). );
prior to committing the code element to the codebase, by the protected data management system, communicate the protected data element access to an inventory management system; (¶0049: As seen in Figure 1, in response to receiving a request to commit code to the repository (codebase), the review enforcement system 102 (inventory management system) may determine a user’s identifier based on the commit request (e.g., based on metadata that pertains to the commit request, based on the user’s client device associated with the user, etc.,) (communicating the protected data element to access to an inventory management system). );
by the inventory management system, search a database of registered protected data elements for the protected data element access; (¶0051: Figure 2 is a block diagram of certain modules of an example review enforcement system. The analysis module 203 is configured to determine, based on the ownership file (as seen in 202 ownership module - configured to access a further ownership file in the repository 107 (database)) , whether an owner provided an indication of approval of the code requested to be committed to the repository 107(registered protected data elements for protected data element access) . In various example embodiments, in order to determine whether an owner provided an indication of approval of the code, the analysis module 203 determines a code identifier (e.g., a diff identifier, an upload file identifier, etc.) based on the commit request; );
wherein the database stores relationships between protected data elements and corresponding code elements that access or use the protected data elements; (¶0043: The ownership module 202 is configured to access ownership data (e.g., an ownership file in the repository 107). The ownership file includes a directory identifier of a directory of the repository 107, and an identifier of an owner who controls committing of code to the directory (relationship between protected data elements and corresponding code element that access). The review enforcement system 102 may enforce an owner's control over the committing of code to a particular directory by logically assigning the particular directory to the owner and by requesting that any code to be committed to the particular directory undergo the owner's review. );
wherein the registered code entry stores an authorized code element registered in the database via the inventory management system; (¶0076: Figure 5 is a flowchart diagram illustrating method steps of an example method for enforcing a software code review, consistent with some example embodiments. At method operation 502, the analysis module 203 determines, using the ownership data identified based on the commit request, whether the code was reviewed by the owner. In some instances, additional data may be used to determine whether the code was reviewed by the owner. The additional data may be included in a review ticket associated with the commit request, the code, the user, the owner, or a suitable combination thereof. The additional data may be located in the review system 103 (e.g., stored as a record in the ticket database 104). If the analysis module 203 determines that the code was reviewed by the owner (wherein registered code entry stores an authorized code element registered database) , then, at method operation 503, the analysis module 203 determines whether the owner gave permission to commit the code to the repository 107 . );
Grillo does not disclose:
wherein the protected data element comprises at least one of personally identifiable information of an end user of the software application or privileged data of a device associated with the end user;
determine that the protected data element access does not have a match in the database of registered protected data elements by comparing the protected data element access to a registered code entry;
by the inventory management system, communicate the no match determination to the protected data management system; and by the protected data management system, prevent the code element from being committed to the codebase in response to the request from the code developer.
However, Koorapati wherein the protected data element comprises at least one of personally identifiable information of an end user of the software application or privileged data of a device associated with the end user; (¶0079-0080: A user account identifier 312 of a user account record 310 in the metadata plane 180. In some example embodiments, a user account identifier 312 is a 128-bit value. An authorized content item identifier 314 of a user account record 310 identifies a content item namespace to which a user in possession of the user account identifier 312 of the user account record 310 is authorized to access (protected data element). );
determine that the protected data element access does not have a match in the database of registered protected data elements by comparing the protected data element access to a registered code entry; (¶0102: Figure 2 is a flow diagram of process for uploading a content item to a target block server. At step 214, the metadata server 150 authorizes the commit request received from a content item synchronization agent 114-1 This authorizing may include verifying that content item namespace identifier of the owning content item namespace specified in the commit request is one of the authorized content item namespace identifier(s) 314 of the user account record 310 in the metadata plane 180 corresponding to the user account identifier in the commit request.);
by the inventory management system, communicate the no match determination to the protected data management system; and by the protected data management system, prevent the code element from being committed to the codebase in response to the request from the code developer. (¶0077: If not, then the metadata server 150 (communicating to the protected data management system, as further seen in Figure 5, shows Metadata Server (protected data management system) in communication with the Metadata Plane (inventory management system) ) may deny the commit request and return an appropriate error message to the content item synchronization agent 114-1. );
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 Koorapati of matching protected data elements to the method of Grillo in order to verify commit request is authorized and prevent unauthorized access (Koorapati : ¶0002 & ¶0081).
With respect to claim 13, the combination of Koorapati in view of Grillo 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. (Koorapati ¶0079-0081: A user account identifier 312 of a user account record 310 in the metadata plane 180. In some example embodiments, a user account identifier 312 is a 128-bit value. An authorized content item identifier 314 of a user account record 310 identifies a content item namespace to which a user in possession of the user account identifier 312 of the user account record 310 is authorized to access (protected data element).);
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 Koorapati of the protected data element to the method of Grillo in order to verify commit request is authorized and prevent unauthorized access (Koorapati : ¶0002 & ¶0081).
With respect to claim 19, the combination of Grillo in view of Koorapati 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; (Koorapati ¶0079: Figure 3 represents user account and content item namespace metadata 30 (database) stored in the metadata 180. In particular, metadata plane 180 (which is used to search as previously seen in the steps of Figure 2 when verifying the user account) can store one or more user accounts held with online content management service. Among other information, a user account record 310 can have a user account identifier 312 and one or more authorized content item namespace identifiers 314. );
and determine, using the comparison, if at least one entry in the database of registered protected data elements matches the protected data element. (Koorapati ¶0080-0082: An authorized content item identifier 314 of a user account record 310 identifies a content item namespace to which a user in possession of the user account identifier 312 of the user account record 310 is authorized to access. Thus, a user that holds a user account with the online content management service can have access to one or more content item namespaces associated with the user account. A user can acquire possession of a user account identifier 312 by providing valid authentication credentials (e.g., a valid username and password) associated with the user account identifier 312 (using the database of registered protected data elements matches (via verifying) the protected data element access).);
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 Koorapati of searching the database of registered protected data elements to the method of Grillo in order to verify commit request is authorized and prevent unauthorized access (Koorapati : ¶0002 & ¶0081).
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Grillo et al. (US PGPub No. 20150205600-A1) in view of Koorapati et al. (US Pat No.9479567-B1) and Carranza et al. (US-20190318366-A1).
With respect to claim 3, the combination of Grillo in view of Koorapati 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.
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 Grillo in view of Koorapati 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).
With respect to claim 14, the combination of Grillo in view of Koorapati 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.
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 Grillo in view of Koorapati 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).
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 Grillo in view of Koorapati 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 Grillo in view of Koorapati 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 Grillo in view of Koorapati, 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. (Grillo ¶0020: Using ownership data that identifies an owner who controls committing of code to a directory, the review enforcement system determines whether the owner did or did not provide an indication of approval of the code to be committed to the repository.);
Although Grillo 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 Grillo in view of Koorapati 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 Grillo in view of Koorapati, 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 Grillo et al. (US PGPub No. 20150205600-A1) in view of Koorapati et al. (US Pat No.9479567-B1) and Palazzo et al. (US-20160255105-A1) .
With respect to claim 7, the combination of Grillo in view of Koorapati teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein pre-commit scan executes a query comprising 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.
It is noted that Grillo discloses pre-commit scan (as seen in rejection of claim 1) , but Grillo does not teach a query. However, Palazzo teaches wherein the query comprising 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 Grillo in view of Koorapati 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 Grillo et al. (US PGPub No. 20150205600-A1) in view of Koorapati et al. (US Pat No.9479567-B1), 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 Grillo in view of Koorapati 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 Grillo in view of Koorapati 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).
Grillo in view of Koorapati, 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 Grillo in view of Koorapati, 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 Grillo et al. (US PGPub No. 20150205600-A1) in view of Koorapati et al. (US Pat No.9479567-B1) and Durand et al. (US-20230177201-A1).
With respect to claim 10, the combination of Grillo in view of Koorapati 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 Grillo in view of Koorapati 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 Grillo in view of Koorapati 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: (Koorapati ¶0080-0082: An authorized content item identifier 314 of a user account record 310 identifies a content item namespace to which a user in possession of the user account identifier 312 of the user account record 310 is authorized to access. Thus, a user that holds a user account with the online content management service can have access to one or more content item namespaces associated with the user account. A user can acquire possession of a user account identifier 312 by providing valid authentication credentials (e.g., a valid username and password) associated with the user account identifier 312 (using the database of registered protected data elements matches (via verifying) the protected data element access).);
committing the code element into the codebase. (Grillo: ¶0020: Using ownership data that identifies an owner who controls committing of code to a directory, the review enforcement system determines whether the owner did or did not provide an indication of approval of the code to be committed to the repository.);
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 Koorapati of searching the database of registered protected data elements to the method of Grillo in order to verify commit request is authorized and prevent unauthorized access (Koorapati : ¶0002 & ¶0081).
Grillo in view of Koorapati 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, Grillo in view of Koorapati 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 Grillo in view of Koorapati 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 Grillo in view of Koorapati 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.
It is noted that Grillo discloses pre-commit scan (as seen in rejection of claim 1), but Grillo does not teach a query. 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. (¶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 Grillo in view of Koorapati 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 Grillo et al. (US PGPub No. 20150205600-A1) in view of Koorapati et al. (US Pat No.9479567-B1) and Watson et al. (US-20210216658-A1).
With respect to claim 15, the combination of Grillo in view of Koorapati 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 Grillo in view of Koorapati 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 Grillo in view of Koorapati 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. (Grillo: ¶0020: Using ownership data that identifies an owner who controls committing of code to a directory, the review enforcement system determines whether the owner did or did not provide an indication of approval of the code to be committed to the repository.);
Although Grillo 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 Grillo in view of Koorapati 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 Grillo in view of Koorapati 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 Grillo et al. (US PGPub No. 20150205600-A1) in view of Koorapati et al. (US Pat No.9479567-B1) and Nguyen et al. (US-20230316138-A1).
With respect to claim 18, the combination of Grillo in view of Koorapati 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 Grillo in view of Koorapati in order to a reduce redundancy and efficiently manage the of processing queries (Nguyen: ¶0003 & 0012).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Meli et al. (How bad can it git? characterizing secret leakage in public GitHub repositories. In NDSS. (Year: 2019)) teaches the analysis of secret leakage on GitHub and detection of secret leakage.
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
/MENG LI/ Primary Examiner, Art Unit 2437
Prosecution Insights