DETAILED ACTION
This Non-Final Office Action is in response to Application filed on 04/29/2025.
Claims 1-11 filed on 04/29/2025 are being considered on the merits.
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 .
Drawings
The drawings filed on 04/29/2025 are accepted.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 07/08/2025 have been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly an initialed and dated copy of Applicant's IDS form 1449 filed 07/08/2025 are attached to the instant Office action.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 5 and 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over O'Neill (US 20230083952 A1) in view of Linnakangas (US 10009354 B2).
Regarding claim 1, O'Neill teaches a method (Abstract “… techniques that include assessing trust in a computer network.”) comprising:
classifying, labeling, and grouping a plurality of components of a computer system (O'Neill [0002] “Example types of network entities may include network nodes (e.g., endpoint devices, intermediate network devices, etc.), network services, or other types of real or virtual entities that can be identified on a computer network. Because network entities are not trusted by default in zero-trust networking, identity and integrity checks are routinely performed on network entities, even if such entities are part of a private computer network.”, Figure 4A-B illustrates identifying and labeling different nodes and their trust relationship from the perspective of each node);
generating a mapping of trust relationships between a plurality of pairs of components (O'Neill [0034] “Techniques described herein may apply to both quantitative entities 160 and qualitative entities 170 having a trust score, and a component of the trust score may be spatial in nature. Such a trust score may be defined to some extent based on the level of trust among neighboring entities in a graph, diagram, table, or other arrangement of data.”, [0071] “…if network entity 102E has a trust score of 70, network entity 102C, which is adjacent to network entity, may view network entity as having a trust score of 70. If network entity 102C has trust score 80, then network entity 102A, which is adjacent to network entity 102C, may view network entity as having a trust score of 80. However, the trust score that network entity 102A associates with network entity 102E may be a function of the trust scores for network entity 102C, network entity 102E, and the number of intervening network entities between network entity 102A and 102E: [0072] trust score of 102A=f(trust score of 102C, trust score of 102E, count intervening entities between 102A and 102E)”, Figure 4A [0083] “…a binary trust relationship might apply such that neighbors might be classified simply as either trusted or untrusted. However, in at least some illustrations shown herein (including FIG. 4A), a continuum of trust may apply, such that network entities 102 that are more darkly shaded than other network entities 102 are considered less trusted.”) from the plurality of components by designating a first component of each pair as a trustor and a second component of each pair as a trustee (O'Neill [0003] “This disclosure describes techniques that include assessing trust in a system, and in particular, assessing the extent to which an entity in a system can trust another entity in the system. As described herein, and in a networking context, a computing system may assess the extent to which a network entity or network device can trust another entity in a computer network. Making such a determination may involve determining the distance or separation between the entities, where the distance or separation might be defined by attributes of paths between the network entities and/or intervening network devices on such paths.”, [0007] “…determining, by a computing system, a level of trust that a first network entity has for a second network entity; determining, by the computing system, a level of trust that the second network entity has for a third network entity; determining, by the computing system, that the first network entity is separated from the third network entity by the second network entity; determining, by the computing system and based on the level of trust that the first network entity has for the second network entity and further based on the level of trust that the second network entity has for the third network entity, a level of trust that the first network entity has for the third network entity; and enabling, by the computing system and based on the level of trust that the first network entity has for the third network entity, the first network entity to perform an operation with the third network entity.”, where O'Neill evaluates directional trust relationship between pair of neighboring components, [0083] and Figures 4A-B illustrate level of trust 102A (trustor) has for neighbor 102C (trustee)) and
by identifying [[a method]] associated with the trust relationship for each pair of components, a trust relationship for at least one pair of components being a verification relationship (O'Neill [0026] “Thus, the trust score for the network entity may be the result of a mathematic computation that is based on one or more of the prerequisites for the network entity, the variable factors for the network entity, and/or the reputation factors for the network entity.”, [0057] “Example types of reputation factors may include: [0058] A number of temporal intervals (e.g., weeks, days, etc.) without a reset of the network entity. [0059] A number of temporal intervals (e.g., weeks, days, etc.) without a reboot of the network entity. [0060] A number of failed log-ins. [0061] Log-in frequency. [0062] Configuration frequency. [0063] A number of protocol timeouts or other runtime data”, further in [0065], where O'Neill discloses identifying e.g. protocols timeout that maps entities and verify their trust relationship); and
analyzing security risks of the computer system (O'Neill [0005] “A computing system may use trust scores in various ways, including by performing or enabling performance of various actions based on the trust scores of the network devices or entities. For instance, in some examples, the computing system may modify traffic patterns in a computer network based on trust scores and/or trust relationships.”) and performing at least one of the following based on the analysis of the security risks:
patching a root cause of at least one security risk based on the mapping of the trust relationships; modifying a policy of the computer system to mitigate the at least one security risk; modifying a design of the computer system to mitigate the at least one security risk; modifying the computer system to shift the at least one security risk from one component of the computer system to another component of the computer system; and monitoring a root cause of the at least one security risk (O'Neill [0005] “A computing system may use trust scores in various ways, including by performing or enabling performance of various actions based on the trust scores of the network devices or entities. For instance, in some examples, the computing system may modify traffic patterns in a computer network based on trust scores and/or trust relationships.”, [0067] “…based on a trust score of a network entity being greater than a particular threshold, action system 224 may send instructions to one or more routers in computer network 100 that cause the routers to change routes in computer network 100 so that packets are not directed along routes that lead to or through the network entity.”. where O'Neill discloses enabling performance of actions including modifying traffic patterns or changing routs in the computer network based on trust score evaluation).
While O'Neill discloses “protocol timeouts” and evaluating runtime data to calculate a trust score. O'Neill does not explicitly disclose utilizing specific verification/authentication method (e.g. SSH, TLS/SSL, etc.) on the relationship edge between a pair of components.
Linnakangas discloses identifying a method associated with trust relationship for each pair component (Linnakangas Col. 1line 22-42 “The trust relationships can associate for example with access control and encryption… A network host may offer information resources, services, and applications to users or other nodes on the network. For instance, the SSH-2 (Secure Shell 2) protocol implements end-to-end encryption.”, Col. 2 line 40-46 “…detecting based at least in part on said received log information at least one security protocol related event at a first host device, the at least one security protocol related event being initiated by a second host device, and storing information for determination of a trust relationship record based on the detected at least one security protocol related event and information of the second host device.”, where a pair of devices/components are analyzed to determine trust relationship by identifying security protocols, e.g.SSH-2, etc., further in Col. 13 line 1-5)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified O'Neill to incorporate the teaching of Linnakangas to utilize the above feature, with the motivation of optimizing the discovery of access patterns, as recognized by (Linnakangas Col. 2 line 15-32).
Regarding claim 5, O'Neill in view of Linnakangas teaches the method of claim 1.
O'Neill does not explicitly disclose the limitations below.
Linnakangas discloses wherein the computer system includes at least one of a security analyst workstation, a security analyst authentication server, and a security information and event management (SIEM) server (Linnakangas Col. 2 line 38-43 “receiving at a data processing device information from at least one source of log information in the computerized system, detecting based at least in part on said received log information at least one security protocol related event at a first host device, the at least one security protocol related event being initiated by a second host device”, Col. 3 line 48-58 “Log information can be accessed, for instance, by logging remotely into a network host with sufficient user privileges, such as administrator or root privileges, using a remote access mechanism such as SSH (Secure Shell), and reading log files on the local file system. Alternatively, or in addition, log information can be obtained by receiving one or more online streams of log events that are provided by a provider. The provider can be for example an SNMP (Simple Network Management Protocol) agent, an RFC 3164 compliant syslog server or forwarding service, or some type of an SIEM (Security Information and Event Management System) such as Splunk™.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified O'Neill to incorporate the teaching of Linnakangas to utilize the above feature, with the motivation of optimizing the discovery of access patterns, as recognized by (Linnakangas Col. 2 line 15-32) and further utilizing industry standard platform SIEM to collect network data.
Regarding claim 8, O'Neill in view of Linnakangas teaches the method of claim 1.
O'Neill does not explicitly disclose the limitations below.
Linnakangas discloses wherein the method associated with the trust relationship for each pair of components includes one of:
a remote desktop protocol method,
a secure sockets layer (SSL) / transport layer security (TLS) method (Linnakangas Col. 5 line 14-20 “The security protocol can be, for example, any version of SSH (Secure Shell), any version of SSL (Secure Sockets Layer), any version of TLS (Transport Layer Security), any version of Secure Telnet, SFTP (SSH File Transfer Protocol), or FTPS (FTP over TLS/SSL), or a variant or further development of those or similar protocols without having a material impact on the applicability of the present invention.”),
a secure shell (SSH) / multi-factor authentication (MFA) method,
a temporary token method,
a X.509 certificate method,
a handshake method, and
an SHA-256 hash method.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified O'Neill to incorporate the teaching of Linnakangas to utilize the above feature, with the motivation of optimizing the discovery of access patterns, as recognized by (Linnakangas Col. 2 line 15-32).
Regarding claim 9, O'Neill in view of Linnakangas teaches the method of claim 1, wherein the mapping of the trust relationships is generated as a visualization of components stored in at least one computer file (O'Neill [0034] “…trust score may be defined to some extent based on the level of trust among neighboring entities in a graph, diagram, table, or other arrangement of data.”, where storing in such graph, diagram, table is used for generating it via the computer system).
Regarding claim 10, O'Neill in view of Linnakangas teaches the method of claim 1, wherein the mapping of the trust relationships is generated as a spreadsheet (O'Neill [0034] “…trust score may be defined to some extent based on the level of trust among neighboring entities in a graph, diagram, table, or other arrangement of data.”, where a spreadsheet is a tabular data structure).
Claims 2 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over O'Neill (US 20230083952 A1) in view of Linnakangas (US 10009354 B2) and Dennis (US 9857960 B1).
Regarding claim 2, O'Neill in view of Linnakangas teaches the method of claim 1, further comprising.
O'Neill in view of Linnakangas disclose the trust relationship, however, O'Neill in view of Linnakangas does not disclose the limitation below, emphasis in italic.
Dennis discloses redacting and encapsulating information within the generated mapping of trust relationships prior to exporting the mapping of the trust relationships (Dennis Col. 4 line 4-17 “An entity may wish to redact a particular data object, a particular data object property, and/or a particular relationship that is displayed in computer graphical user interface 100. FIG. 3 is a table that depicts an approach for identifying portions of a graph to be redacted. Referring to FIG. 3, each redaction stage 300 corresponds to one or more redaction criteria 302 and a portion of the graph to be redacted 304. Redaction criteria 302 includes access control classification 306, provenance 308, data object type 310, data object property type 312, and media type 314. Computer graphical user interface 100 may be used to identify one or more portions of a graph 102 to be redacted by the time the graph 102 is exported.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified O'Neill in view of Linnakangas to incorporate the teaching of Dennis to utilize the above feature, with the motivation of distinguishing between information to share and information to safeguard, as recognized by (Dennis Col. 1 line 23-35).
Regarding claim 11, O'Neill in view of Linnakangas teaches the method of claim 1.
O'Neill in view of Linnakangas does not explicitly disclose the limitation below.
Dennis discloses further comprising exporting the mapping of the trust relationships to a user (Dennis Col. 2 line 32-40 “After the last redaction stage, Alice may submit a request to export the graphical representation. In an embodiment, the request may cause audit data to be generated and sent to a person with the authority to approve exporting the graphical representation. For example, the audit data may be provided to Diana for approval. When Alice and/or Diana confirm exporting the graphical representation, a machine-readable representation of a redacted graph is exported to Charlie.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified O'Neill in view of Linnakangas to incorporate the teaching of Dennis to utilize the above feature, with the motivation of reviewing graphical trust representation to a user tailored at the user’s access level.
Claims 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over O'Neill (US 20230083952 A1) in view of Linnakangas (US 10009354 B2) and Stephens (US 11463444 B2).
Regarding claim 3, O'Neill in view of Linnakangas teaches the method of claim 1.
O'Neill discloses in e.g. [0095] access control based on trust relationship, however O'Neill in view of Linnakangas do not explicitly discloses privileged access manager.
Stephens discloses wherein the computer system includes a privileged access manager (Col. 1 line 33-35, “…improved technology for privileged access management (PAM), which generally involves managing elevated levels of access to resources in a computing system.”, Col. 7 line 8-14 “The on-premise authentication domain 212 shown is in a trust relationship 224 with the cloud-based PAM functionality 204, or with at least a portion thereof, such that the on-premise authentication domain 212 is a trusting entity and the cloud-based PAM functionality 204 or a portion thereof is a trusted entity.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified O'Neill in view of Linnakangas to incorporate the teaching of Stephens to utilize the above feature, with the motivation of providing improved privilege access management across different levels, as recognized by (Stephens Col. 1 line 32-42).
Claims 4 and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over O'Neill (US 20230083952 A1) in view of Linnakangas (US 10009354 B2) and Manghnani (US 11971805 B2).
Regarding claim 4, O'Neill in view of Linnakangas teaches the method of claim 1.
O'Neill in view of Linnakangas does not explicitly disclose the limitation below.
Manghnani discloses wherein the computer system includes at least one of a GitLab continuous integration and continuous deployment (Cl/CD) pipeline, an application programming interface (API) software development kit (SDK), Git Repositories, and a software product (Manghnani Col. 2 line 43-50, 64-67 and Col. 3 line 1-7 “The software developer platform 112 may be any software development platform allowing a software developer to write source code for a software development project. The software developer platform 112 may utilize a continuous integration/continuous delivery (CI/CD) pipeline to allow the developed source code to be delivered or deployed in a side car pattern with a code analytic engine of the computer system 120 described herein below…The source code management tool 114 may be a task and/or story and/or epic software development tool such as Github™, Gitlab™, or Microsoft Team Foundation Server™ (TFS). The source code management tool 114 may be an integral system within the software development platform 112 of a enterprise or user that is developing source code or software. The source code management tool 114 may provide functionality to allow teams of developers to develop code, sync the code, and or run the code and/or deploy the code in an application.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified O'Neill in view of Linnakangas to incorporate the teaching of Manghnani to utilize the above feature, with the motivation of ensuring that compromised pipeline artifacts do not introduce systemic risks into the environment.
Regarding claim 6, O'Neill in view of Linnakangas teaches the method of claim 1.
O'Neill in view of Linnakangas does not explicitly disclose the limitation below.
Manghnani discloses wherein the computer system includes at least one of a developer computer and a cloud development environment (Manghnani Col. 2 line 50-53 “The software development platform 112 may include one or more developer workstations, connectable over a network, for developing source code for a software development project.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified O'Neill in view of Linnakangas to incorporate the teaching of Manghnani to utilize the above feature, as developer devices inherently require trust environment enforced to prevent unauthorized code or breaches.
Claims 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over O'Neill (US 20230083952 A1) in view of Linnakangas (US 10009354 B2) and Chen (US 12008341 B2).
Regarding claim 7, O'Neill in view of Linnakangas teaches the method of claim 1.
O'Neill in view of Linnakangas does not explicitly disclose the limitation below.
Chen discloses wherein the computer system includes at least one of a GitHub-Hosted JavaScript Library, Python dependencies, and a product website (Chen Col. 7 line 60-65 “…the present disclosure may be used to assist programmers in their work, allowing them to generate code snippets, functions, and even entire programs, based on natural language descriptions, in several programming languages including Python, Java, C++, Ruby, and JavaScript.”, and further discloses tracing and testing utilizing “…continuous integration repositories include GitHub repositories using Travis and/or Tox frameworks, as well as pip packages within the Python Package Index (PyPI).”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified O'Neill in view of Linnakangas to incorporate the teaching of Chen to utilize the above feature, to accurately model the systemic security risk introduced by a third party during the development process.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
BURSTEIN (US 20130133023 A1) discloses dynamically mapping network trust relationships.
DEBATE (US 20190163345 A1) discloses method for operating computing device to perform trust map management in secure shell environment, involves displaying representation of trust relationship between selected entity and non-selected entity between hub region and spoke region.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BASSAM A NOAMAN whose telephone number is (571)272-2705. The examiner can normally be reached Monday-Friday 8:30 AM-5:00PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
/BASSAM A NOAMAN/Primary Examiner, Art Unit 2497
Prosecution Insights