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
The instant application having Application No. 18/337,380 is presented for examination by the examiner. Claims 1, 9, and 17 are amended. Claims 21-23 are added. Claims 1, 3-9, 11-17, and 19-23 are pending.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 9, and 17 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 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 of this title, 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, 4, 6, 8, 9, 12, 14, 16, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over USP 10,348,767 to Lee et al., hereinafter Lee in view of USP 7,197,622 to Torkelsson et al., hereinafter Torkelsson and in view of USP Application Publication 2009/0241170 to Kumar et al., hereinafter Kumar.
As per claims 1, 9, and 17, Lee teaches a method comprising steps of:
intercepting client application information (col. 71, lines 19-22 and 25);
identifying if the application is a known application based on an application catalog [on the whitelist; col. 71, lines 27-28], and
collecting known information of the application from the application catalog [authorized signatures; col. 71, line 29 ];
sending the application information [signature] to an enforcement node [controller] of a cloud-based system in a first packet [col. 71, lines 29 and 26-33].
Lee is silent in explicitly teaching sending, in subsequent packets, only an application Identification (ID) instead of a full application information, wherein the application ID is used for policy enforcement, wherein the enforcement node caches full application context from the first packet, and the application ID comprises a unique hash calculated to represent the application information, the application ID being used to lookup the cached application context for zero trust policy enforcement by the enforcement node.
Torkelsson teaches sending, in subsequent packets, only an application Identification (ID) [CID in compressed header; col. 2, lines 38-41] instead of a full application information, wherein the application ID is used for policy enforcement, wherein the enforcement node caches full application context from the first packet [full packet header sent initially and stored in memory; col. 2, lines 27 and 38-39], and the application ID comprises a unique hash calculated to represent the application information [CID derived by hashing the header; col. 3, lines 7-9], the application ID being used to lookup the cached application context for zero trust policy enforcement by the enforcement node [col. 2, lines 40-45]. Once Lee has authorized the application identifier there is no need to keep sending it. In fact, Lee does employ tokens dynamically to inform both the client and server sides of a communication (col. 39, lines 18-21). The hash value generated from taken the content values of the header of the initial packet is similar to a token in that it is unique and can be understood by both sides in Torkelsson. Presence of this value is crucial to authentication and security of the tunnel in Lee. The use of the compressed header containing the CID of Torkelsson is essentially a type of token that also saves overhead. The application identifier in Lee does not change therefore it could be captured in the compressed header value CID of Torkelsson. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
Lee and Torkelsson are silent in explicitly teaching wherein the application information comprises application identity information including at least one of a file name, a file path, an executable signature, and a code signing certificate, and wherein the unique hash is calculated based on the application identity information. On the other hand, Kumar teaches wherein the application information comprises application identity information including at least one of a file name, a file path, an executable signature, and a code signing certificate (0033), and wherein the unique hash is calculated based on the application identity information (0065 and 0066). Kumar places a digital signature (formed from a hash) of application information (0066) into the header of a packet (0087) for securing data transmission related to applications. Like Torkelsson, the full context of application is registered and then a compressed hash is included in each packet to compare against the registered context. The hashed identifier of the application information could have been used in the combined system of Lee and Torkelsson with the predictable result of authorizing registered application during a monitored session. The claim is obvious because one of ordinary skill in the art can substitute methods known before the effective filing date which produce predictable results. Substituting hashed data of the application for the context identifier which are to be authorized is predictable because both are non-changing fields and thus checking the hash remains a valid way to make sure application have not changed.
As per claim 4 and 12, the combined system of Lee, Kumar, and Torkelsson teaches calculating and sending a unique hash to represent the application ID in the subsequent packets [Torkelsson: CID derived by hashing the header; col. 3, lines 7-9].
As per claims 6, 14, and 19, the combined system of Lee, Kumar, and Torkelsson teaches full application information is only sent once [Lee: to authenticate application; col. 71, lines 20-25], thereby avoiding a possibility of overload associated network connections and reducing bandwidth usage during subsequent communication [Jeong: 0089, 0101, 0102]
As per claims 8, 16, and 20 Lee teaches the steps are performed by a connector associated with the cloud-based system, wherein the connector is on-premises [controller is local to the endpoints; col. 78, lines 35-40].
Claims 3, 5, 11, and 13, are rejected under 35 U.S.C. 103 as being unpatentable over Lee, Kumar, and Torkelsson as applied to claims 1 and 9, and further in view of USP Application Publication 2012/0291103 to Cohen.
As per claims 3 and 11, Lee, Kumar, and Torkelsson are silent in explicitly teaching continuously receiving updates of known applications for the application catalog [whitelist]. On the other hand, Cohen teaches updating whitelists of application that are deemed safe by a crowdsource (see Cohen’s claim 1). If implementing a whitelist, it should be fixed because new applications need to be included in order to maintained the desired functionality afforded by whitelist. Updating them as taught by Cohen yield this predictable result. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
As per claim 5 and 13, the Lee, Kumar, and Torkelsson are silent in explicitly teaching the application catalog is built dynamically by crowdsourcing know applications through digital experience monitoring services. Cohen teaches the application catalog is built dynamically by crowdsourcing know applications through digital experience monitoring services (0017). Cohen explicitly teaches one-way whitelists can be created. They can be generated and updated via crowdsourced data structure. Lee uses whitelists and using a crowdsourced whitelist that can be updated is an obvious way to incorporate the feature and maintain the functionality as new applications are created. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Lee, Kumar, and Torkelsson as applied to claims 1 and 9, and further in view of NPL entitled “RFC 9146 Connection Identifier for DTLS 1.2”, hereinafter RFC 9146, published March 2002.
As per claim 7 and 15, Lee, Kumar, and Torkelsson are silent in explicitly teaching the first packet is sent through a Datagram Transport Layer Security (DTLS) tunnel to the enforcement node. Lee already teaches generating a TCP/UDP tunnel once a request is authorized [table Q, step 3627c]. RFC 9146 teaches adding an opaque CID to the header of DTLS (section 4). This is the type of reserved header used for to hold the application ID of the combined system of Lee, Kumar, and Torkelsson. One of ordinary skill in the art can substitute one known protocol for another. Substituting a DTLS tunnel for the TCP tunnel is predictable and still affords security between the applications. The claim is obvious because one of ordinary skill in the art can substitute methods known before the effective filing date which produce predictable results.
Claims 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Lee, Kumar, and Torkelsson as applied to claims 1, 9, and 17 and further in view of RFC 9146 and USP Application Publication 2011/0179484 to Tuvell et al., hereinafter Tuvell.
As per claims 21-23, Lee, Kumar, and Torkelsson are silent in explicitly teaching the first packet is sent through a Datagram Transport Layer Security (DTLS) tunnel with reserved packet headers, and wherein the application ID sent in the subsequent packets is a 64-bit hash included in the reserved packet headers. Lee already teaches generating a TCP/UDP tunnel once a request is authorized [table Q, step 3627c]. RFC 9146 teaches adding an opaque CID to the reserved packet header of DTLS (section 4). This is the type of reserved header used for to hold the application ID of the combined system of Lee, Kumar, and Torkelsson. One of ordinary skill in the art can substitute one known protocol for another. Substituting a DTLS tunnel for the TCP tunnel is predictable and still affords security between the applications. The claim is obvious because one of ordinary skill in the art can substitute methods known before the effective filing date which produce predictable results.
Tuvell teaches the application ID sent in the subsequent packets is a 64-bit hash (0058). Tuvell teaches short hashes are easier to compare. The combined system of Lee, Kumar, Torkelsson already hash application information and place it into packet headers. Tuvell similarly hashes application information (0125 and 0127). Tuvell teaches creating a 64-bit application hash. RFC 9146 has reserved bits that can easily accommodate a 64-bit hash as its opaque CID. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results. Using a 64-bit hash as the opaque Cid of a DTLS packet does not produce any unpredictable result. The same type of data is being hashed and is placed into a suitable protocol which can carry the unique hash in a header as intended. The only change is the size of the hash and protocol used.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL R. VAUGHAN whose telephone number is (571)270-7316. The examiner can normally be reached on Monday - Thursday, 7:30am - 5:00pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL R VAUGHAN/
Primary Examiner, Art Unit 2431
Prosecution Insights