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 .
DETAILED ACTION
This Office Action is in response to the Amendment filed 01/12/2026. In the instant amendment, claims 1, 10 and 11 were amended; claims 1, 10 and 11 are independent claims. Claims 1-19 are pending in this application. THIS ACTION IS MADE FINAL.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 10 and 11 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 (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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2 and 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over Chieu et al (“US 20130247136) and further in view of Parthasarathi et al (“Parthasarathi,” US 20220417215).
Regarding claim 1, Chieu discloses a method for collecting evidence from a private computing infrastructure, comprising: (Chieu, [0013]-[0014], [0045] describe the automated validation of configuration and compliance in managed cloud servers…remotely access a target server to discover configuration settings; compliance evidence)
initiating an evidence collection over the established at least one secure tunnel,
wherein initiating the evidence collection; (Chieu, [0049]-[0052] describe API keybasedActivationRequest/<reqID>/<OSPlatform/<serverHostName> to initiate an activation process for a given server which initiates the evidence-collection workflow; [0058], Internal processing of the server activation request will start as soon as the “keybasedServiceActivationRequest” request is received by the engine 410. Step 7 includes creating an activation record in its local database, checking the remote connection to the VM using the engine's private key as the credential for a shared admin ID, and initiating a separate background process for server activation; FIG 4 Step 6 describes keybased-ServerActivationRequest-initiation call, FIG 5, Step 518 initiate activation with timeout, [0014], the automation engine will collect and correlate the discovered information from the target server with that from other back-end tools, and use the resulting information as evidences to answer and compose a set of checklist questions for activation validation)
and collecting raw data of evidence from the user system, via the first tunnel of the at least one secure tunnel, (Chieu, [0014], the automation engine will collect and correlate the discovered information from the target server with that from other back-end tools, and use the resulting information as evidences; [0045], Scripts are executables to be executed in VMs, and these scripts are responsible for performing various tasks in order to collect configuration and security settings of the VM as evidences for answering corresponding checklist questions; [0058], the corresponding activation scripts for the image type of the VM will be retrieved, copied and executed in the VM to return the results of evidences; FIG 4, Step 8 Copy and Execute Scripts on VM and return results/FIG 5, Step 526 get evidence results/FIG 6, Step 602, remotely access a target cloud server to discover at least one configuration setting of the target cloud server, [0013], an automation system utilizes sets of executable scripts to discover the various configuration and security settings in the servers [raw configuration/security data which is the raw data of evidence]; [0047], a remote, password-less, key-based secure-shell mechanism is implemented in the cloud provisioning environment; [0058], Once the connection to VM is verified, the corresponding activation scripts for the image type of the VM will be retrieved, copied and executed in the VM to return the results of evidences in step 8)
Chieu fails to explicitly disclose establishing at least one secure tunnel with a user system within the private computing infrastructure through an agent that is deployed at the private cloud infrastructure having the user system, wherein the agent is configured to open and manage the access of the established at least one secure tunnel; further comprises fetching tunnel details; accessing the user system via a first tunnel of the at least one secure tunnel, wherein the first tunnel is active and identified from the fetched tunnel details; via the first tunnel of the at least one secure tunnel.
However, in an analogous art, Parthasarathi discloses establishing at least one secure tunnel with a user system within the private computing infrastructure through an agent that is deployed at the private cloud infrastructure having the user system, (Parthasarathi, Abstract describes a request may be transmitted to create a secure tunnel between the edge device and the cloud-based management plane. The edge device may receive and use a set of credentials to trigger a web-socket tunnel from the edge device to the cloud-hosted management plane; [0021], tunnel 116 (e.g., a secure tunnel) is generated from the edge device 104 to the cloud service 106, [0030], the tunnel 116, which may be a transport layer security (TLS) tunnel that opens from the edge device 104 to the cloud service; [0037], The tunnel 116 (e.g., web-socket tunnel) is triggered from the edge device 104 to the cloud service 116 using the credentials 306 published by the cloud service 106; [0038], multiple different tunnels 116 may extend between different edge devices 104; FIG 4A, Step 406 Establish, from the edge device to a cloud service associated with the request, a secure tunnel; [0032] establish a connection 210 via the remote tunnel 116)
wherein the agent is configured to open and manage the access of the established at least one secure tunnel; (Parthasarathi, [0021], tunnel 116 (e.g., a secure tunnel) is generated from the edge device 104 to the cloud service 106, for example upon receipt of an instruction from a node manager 118, [0024], a local or on-premise server associated with the edge device and also communicatively coupled to the cloud-hosted management system may be configured to listen only at localhost addresses [0031], The node manager 118 may be a server, for example, configured to listen only at localhost addresses and the node manager 118 may be in communication with the cloud service, such as through a network, and may also enable local control or execution of various node commands [0036], These credentials 306 may be pulled or otherwise acquired at the node 108 via the manager 118, which may be connected and managed at the cloud service 106. For example, the manager 118 may periodically monitor or watch for different commands or signals and then pull information down from the cloud service 106; FIG 1 and/or FIG 3 show manager 118 is deployed inside the private remote location 110 [private cloud] alongside edge devices 104; [0032], [0034], [0039], FIG 6 describe manage the access of the established at least one secure tunnel)
further comprises fetching tunnel details (Parthasarathi, [0033], To provide the user device 102 with access to the edge device 104, a unique DNS URL may be generated and provided 212 at the EMS API 202, which may return 214 that URL to the user device 102 where the URL is the tunnel detail used to identify the specific active tunnel; [0026], Upon establishment of the tunnel, a unique DNS URL may be generated and then users may be provided access through a browser (e.g., secure shell access), in order to access the edge device; [0024], Moreover, for embodiments that establish the tunnel as a web-socket tunnel, multiple sessions can be multiplexed, and a separate log or registry can be maintained for each SSH session where the registry refers to tunnel details data structure that can be fetched; [0038], multiple different tunnels 116 may extend between different edge devices 104, where different edge devices 104 may also be part of different nodes 108 where this establishes that tunnel details must be fetched/looked up to pick the right one; FIG 2, steps 212/214 & [0033] describe provide unique DNS URL to return URL to the user device [fetching/returning tunnel details])
accessing the user system via a first tunnel of the at least one secure tunnel,
wherein the first tunnel is active and identified from the fetched tunnel details; (Parthasarathi, [0033], the user device 102 may now access the edge device 104 via a portal, such as a browser. The user device 102 may now communicate with the edge device 104, which may include transmitting an instruction 216 via the tunnel 116 ; [0034], the tunnel 116 may remain active for periods of time; [0038], a single tunnel 116 is established to the cloud service 106, but it should be appreciated that multiple different tunnels 116 may extend between different edge devices 104, where different edge devices 104 may also be part of different nodes 108 and/or at different remote locations 110. However, in various embodiments, a given edge device 104 may only be associated with a single tunnel 116; [0039], the management plane 302 may be used to audit activity for given tunnels 116, FIG 2, Step 216 describes the instruction is sent via tunnel 116 to edge device 104)
via the first tunnel of the at least one secure tunnel, (Parthasarathi, [0023] Once a web-socket connection is successfully created, the one or more cloud services establishes a secure connection, such as (without limitation) a secure shell protocol (SSH) connection to the device using a certification)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Parthasarathi with the method/system of Chieu to include establishing at least one secure tunnel with a user system within the private computing infrastructure through an agent that is deployed at the private cloud infrastructure having the user system, wherein the agent is configured to open and manage the access of the established at least one secure tunnel; further comprises fetching tunnel details; accessing the user system via a first tunnel of the at least one secure tunnel, wherein the first tunnel is active and identified from the fetched tunnel details; via the first tunnel of the at least one secure tunnel. One would have been motivated to provide providing configuration functionalities for edge and remote devices through a cloud-management system (Parthasarathi, [0017])
Regarding claim 2, Chieu and Parthasarathi disclose the method of claim 1.
Chieu further discloses upon collection of raw data (Chieu, [0058], Step 10 includes final checklist composition including answers and evidence to all questions, storing the information in a database, updating the successful activation status, and uploading the results to a back-end checklist repository 428. Also, update of local activation status can occur once the validation process is completed successfully; FIG 5, Steps 526, 530, 532 describe get evidence results to get activation status to service activation passed or failed [collection of raw data])
Parthasarathi further discloses comprising: terminating the access via the first tunnel upon collection of raw data; (Parthasarathi, [0034], the user device 102 may also close tunnels, for example, once operations are complete. The user device 102 may transmit a closure request 218 to the node 108, for example to the node manager 118, via the EMS API 202. The node 108 may receive a closure instruction 220 from the EMS API 202 and then transmit instructions 222 to the edge device 104. In this manner, tunnels 116 may be kept open for periods of time as needed, but may also be directly or periodically purged; [0039], the management plane 302 may be used to handle timeouts or otherwise end connections. For example, one or more rules 308 may be used to determine whether a connection should be reset or otherwise ended; FIG 2, step 218-222 describes a closure request to closure instruction to instructions for tunnel termination/FIG 6, step 614 describes execute one or more remedial actions; [0044] describes remedial action as a termination of the connection; FIG 6, step 612 describes a compliance check loop that can lead to a remedial action which can be a termination)
and purging the fetched tunnel details of the access, (Parthasarathi, [0034], In this manner, tunnels 116 may be kept open for periods of time as needed, but may also be directly or periodically purged; [0039], For example, one or more rules 308 may be used to determine whether a connection should be reset or otherwise ended. The rules 308 may correspond to different periods of time (e.g., requirements to re-establish a connection after a given period of time) or may be associated with providing updated credential or token information; [0024], the tunnel (e.g., web-socket tunnel) is managed by the cloud services layer, so timeouts are handled out of band, which provides applications running in the edge device additional security; [0026], Upon establishment of the tunnel, a unique DNS URL may be generated and then users may be provided access through a browser (e.g., secure shell access), in order to access the edge device).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Parthasarathi with the method/system of Chieu to include comprising: terminating the access via the first tunnel upon collection of raw data; and purging the fetched tunnel details of the access. One would have been motivated to provide providing configuration functionalities for edge and remote devices through a cloud-management system (Parthasarathi, [0017])
Regarding claim 10, claim 10 is directed to a non-transitory computer readable medium. Claim 10 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding claim 11, claim 11 is directed to a system. Claim 11 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding claim 12, claim 12 is directed to the system of claim 11. Claim 12 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Chieu et al (“US 20130247136) in view of Parthasarathi et al (“Parthasarathi,” US 20220417215) and further in view of Kapoor et al (“Kapoor,” US 20220232025).
Regarding claim 3, Chieu and Parthasarathi disclose the method of claim 1.
Chieu and Parthasarathi fail to explicitly disclose further comprising: storing the raw data of the evidence in at least a portion of a data store, wherein the portion of the data store is dedicated to a tenant of the private computing infrastructure.
However, in an analogous art, Kapoor discloses further comprising: storing the raw data of the evidence in at least a portion of a data store, wherein the portion of the data store is dedicated to a tenant of the private computing infrastructure, (Kapoor describes further comprising: storing the raw data of the evidence [0587], [0174] in at least a portion of a data store [0199], wherein the portion of the data store is dedicated to a tenant [0560] of the private computing infrastructure [0628]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kapoor with the method/system of Chieu and Parthasarathi to include further comprising: storing the raw data of the evidence in at least a portion of a data store, wherein the portion of the data store is dedicated to a tenant of the private computing infrastructure. One would have been motivated to detecting anomalies in a network environment (Kapoor, [0223]).
Regarding claim 13, claim 13 is directed to the system of claim 11. Claim 13 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Chieu et al (“US 20130247136) in view of Parthasarathi et al (“Parthasarathi,” US 20220417215) and further in view of Murray et al (“Murray,” US 20240291824).
Regarding claim 4, Chieu and Parthasarathi disclose the method of claim 1.
Chieu and Parthasarathi fail to explicitly disclose wherein initiating the evidence collection is based on any one of: a predetermined schedule and an on-demand request.
However, in an analogous art, Murray discloses wherein initiating the evidence collection is based on any one of: a predetermined schedule and an on-demand request, (Murray describes wherein initiating the evidence collection [0082] is based on any one of: a predetermined schedule [0062] and an on-demand request, [0143], [0134]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Murray with the method/system of Chieu and Parthasarathi to include wherein initiating the evidence collection is based on any one of: a predetermined schedule and an on-demand request. One would have been motivated to managing user access levels to computing software applications based on user state changes detected via integration with a third-party system (Murray, [0004]).
Regarding claim 14, claim 14 is directed to the system of claim 11. Claim 14 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Chieu et al (“US 20130247136) in view of Parthasarathi et al (“Parthasarathi,” US 20220417215) and further in view of Satish et al (“Satish,” US 11,416,561).
Regarding claim 5, Chieu and Parthasarathi disclose the method of claim 1.
Chieu and Parthasarathi fail to explicitly disclose wherein the evidence includes at least one of: a policy, a standard operation procedure, an audit trail, an audit log, a training record, an incident response plan, a change management policy, a risk assessment, a third-party agreement, and a user system configuration.
However, in an analogous art, Satish discloses wherein the evidence includes at least one of: (Satish, Col. 16, Lines 62-67; Col. 17, Lines 1-2 describes evidence)
a policy, (Satish, Col. 17, Lines 36-37 describes modifying data retention policies)
a standard operation procedure, (Satish, Col. 14, Lines 15-17, standard operating procedures)
an audit trail,
an audit log,
a training record,
an incident response plan,
a change management policy,
a risk assessment,
a third-party agreement,
and a user system configuration
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Satish with the method/system of Chieu and Parthasarathi to include wherein the evidence includes at least one of: a policy, a standard operation procedure, an audit trail, an audit log, a training record, an incident response plan, a change management policy, a risk assessment, a third-party agreement, and a user system configuration. One would have been motivated to provide identification of evidence within an information technology operations platform based on data related to incidents within a computing environment (Satish, Col. 1, Lines 16-21).
Regarding claim 15, claim 15 is directed to the system of claim 11. Claim 15 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Chieu et al (“US 20130247136) in view of Parthasarathi et al (“Parthasarathi,” US 20220417215) and further in view of Bethlehem et al (“Bethlehem,” US 20110251992).
Regarding claim 6, Chieu and Parthasarathi disclose the method of claim 1.
Chieu and Parthasarathi fail to explicitly disclose further comprising: receiving a query from the agent for a network configuration at the query; and causing the agent to activate at least one secure tunnel of the at least one established secure tunnel based on the network configuration at the query.
However, in an analogous art, Bethlehem discloses further comprising: receiving a query from the agent for a network configuration at the query; (Bethlehem describes further comprising: receiving a query [0262] from the agent [0033] for a network configuration [0238] at the query [0262]).
and causing the agent to activate at least one secure tunnel of the at least one established secure tunnel based on the network configuration at the query, (Bethlehem describes and causing the agent [0033] to activate at least one secure tunnel [0135] of the at least one established secure tunnel [0137] based on the network configuration [0238] at the query [0262])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bethlehem with the method/system of Chieu and Parthasarathi to include further comprising: receiving a query from the agent for a network configuration at the query; and causing the agent to activate at least one secure tunnel of the at least one established secure tunnel based on the network configuration at the query. One would have been motivated to extend network resources for in and out of the workplace access (Bethlehem, [0002]).
Regarding claim 16, claim 16 is directed to the system of claim 11. Claim 16 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Chieu et al (“US 20130247136) in view of Parthasarathi et al (“Parthasarathi,” US 20220417215) and further in view of Sundararajan et al (“Sundararajan,” US 20210112034).
Regarding claim 7, Chieu and Parthasarathi disclose the method of claim 1.
Chieu and Parthasarathi fail to explicitly disclose wherein establishing the at least one secure tunnel further comprises: assigning a range of ports of the at least one secure tunnel to the private computing infrastructure; receiving credentials for the user system; and storing the assigned range of ports and the received credentials.
However, in an analogous art, Sundararajan discloses wherein establishing the at least one secure tunnel further comprises: assigning a range of ports of the at least one secure tunnel to the private computing infrastructure; (Sundararajan describes wherein establishing the at least one secure tunnel [0031] further comprises: assigning a range of ports [0092], [0069] of the at least one secure tunnel [0031] to the private computing infrastructure [0117])
receiving credentials for the user system; (Sundararajan describes receiving credentials [0040] for the user system [0077])
and storing the assigned range of ports and the received credentials, (Sundararajan [0041] and storing the assigned range of ports [0092], [0069] and the received credentials [0040])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sundararajan with the method/system of Chieu and Parthasarathi to wherein establishing the at least one secure tunnel further comprises: assigning a range of ports of the at least one secure tunnel to the private computing infrastructure; receiving credentials for the user system; and storing the assigned range of ports and the received credentials.. One would have been motivated to enable Wide Area Network (WAN) optimization in a WAN fabric or overlay network (Sundararajan, [0001]).
Regarding claim 17, claim 17 is directed to the system of claim 11. Claim 17 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Chieu et al (“US 20130247136) in view of Parthasarathi et al (“Parthasarathi,” US 20220417215) and further in view of Sivaswamy et al (“Sivaswamy,” US 20230139329).
Regarding claim 8, Chieu and Parthasarathi disclose the method of claim 1.
Chieu and Parthasarathi fail to explicitly disclose wherein the established at least one secure tunnel is utilized for a plurality of accesses to the user system.
However, in an analogous art, Sivaswamy discloses wherein the established at least one secure tunnel is utilized for a plurality of accesses to the user system, (Sivaswamy describes wherein the established at least one secure tunnel [0015] is utilized for a plurality of accesses [0026] to the user system [0074]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sivaswamy with the method/system of Chieu and Parthasarathi to include wherein the established at least one secure tunnel is utilized for a plurality of accesses to the user system. One would have been motivated to dynamically configuring a virtual private network (VPN) protocol of a VPN tunnel (Sivaswamy, [0003]).
Regarding claim 18, claim 18 is directed to the system of claim 11. Claim 18 is similar in scope to claim 8 and is therefore rejected under similar rationale.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Chieu et al (“US 20130247136) in view of Parthasarathi et al (“Parthasarathi,” US 20220417215) and further in view of Cella et al (“Cella,” US 20230206329).
Regarding claim 9, Chieu and Parthasarathi disclose the method of claim 1.
Chieu and Parthasarathi fail to explicitly disclose further comprising: determining a compliance state for the user system based on the collected raw data of the evidence with respect to at least one framework.
However, in an analogous art, Cella discloses further comprising: determining a compliance state for the user system based on the collected raw data of the evidence with respect to at least one framework, (Cella describes further comprising: determining a compliance state [2173] for the user system [0150] based on the collected raw data [2476] of the evidence [3931] with respect to at least one framework [0228])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Cella with the method/system of Chieu and Parthasarathi to include further comprising: determining a compliance state for the user system based on the collected raw data of the evidence with respect to at least one framework. One would have been motivated to facilitate user purpose in a computing architecture (Cella, [0003]).
Regarding claim 19, claim 19 is directed to the system of claim 11. Claim 19 is similar in scope to claim 9 and is therefore rejected under similar rationale.
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 JAMES J WILCOX whose telephone number is (571)270-3774. The examiner can normally be reached M-F: 8 A.M. to 5 P.M..
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, Luu T. Pham can be reached at (571)270-5002. 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.
/JAMES J WILCOX/Examiner, Art Unit 2439
/RODERICK TOLENTINO/Primary Examiner, Art Unit 2439
Prosecution Insights