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
Applicant’s argument regarding the 103 rejection have been considered and they are moot because they do not apply to the new ground of rejection with the combination of the new reference.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claims 1, 10, the claims recite the phrase “the Domain Name Server (DNS) information” which is not defined. There is insufficient antecedent basis in the claims. Dependent claims 2-9, 11-18 are rejected as well.
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.
Claims 1-6, 8-15, 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Raman (US 10903999) in view of Head (US 20150350912) further in view of Vasudevan (US 20210204152).
Regarding claim 10, Raman discloses a system for classifying obfuscated traffic flows in a computer network (figs. 4-6), the system comprising:
a packet processing engine configured to receive at least one packet from an obfuscated traffic flow (fig. 6, col. 13, 2nd para., receiving a request from a client with the request including an authentication token as a request header, wherein the authentication token includes a first encryption key, a second encryption key, and a timestamp (step 602));
an analysis module configured to determine a pattern in a header of the at least one packet that relates to an obfuscation of a payload of the traffic flow, wherein determining the pattern determines whether there is a key or nuance in the header or other signature (fig. 6, decrypting the authentication token with a private key of the server to obtain/determine the first encryption key, the second encryption key, or a layer obfuscation of a payload, and the timestamp (step 604));
an obfuscation module configured to remove the obfuscation of the payload (col. 13, fig. 6, decrypting the authentication token with a private key of the server to obtain the first encryption key, the second encryption key, and the timestamp (step 604); decryption of the payload is to remove the obfuscation of the payload); and
a classification module configured to classify the obfuscated traffic flow (fig. 6, validating the request based on the first encryption key and the timestamp, and, if valid, decrypting payload of the request with the second encryption key (step 606)).
Raman only discloses analyzing the packet header information such as the first encryption key, Raman does not explicitly disclose to determine a pattern in a header of the at least one packet that relates to an obfuscation of a payload of the traffic flow.
Head discloses to determine a pattern in a header of the at least one packet that relates to an obfuscation of a payload of the traffic flow (Head, [0106], a flow may be defined as a set of packets whose headers match a given pattern of bits; the given pattern of bits used for a flow definition may include more fields (e.g., 10 or more) in the packet headers. Header parsing describes how to interpret a packet based upon a well-known set of protocols. Some protocol fields are used to build a match structure (or key) that will be used in packet classification (e.g., a first key field could be a source media access control (MAC) address, and a second key field could be a destination MAC address. Here, since packets are already encrypted, as taught by Raman, the encrypted packet header and payload being parsed is related to an obfuscation of a payload of the traffic flow).
Head also discloses to classify the obfuscated traffic flow (Head, [0106], the model for processing packets includes header parsing, packet classification, and making forwarding decisions).
It would have been obvious to a person of ordinary skill in the art before the time of effective filing to combine the teachings of classifying traffic based on header information as given by Raman with the teachings of matching certain pattern in the traffic classification given by Head. The motivation for doing so would have been to efficiently forward packets based on the classification of the packets using the header information (Head, [0107]).
Raman discloses, col. 10, a combination of encryption approaches to both protect data and prevent replay attacks, therefore, as DNS information can be considered as data, DNS information can be encrypted as well. To further support this,
Vasudevan discloses wherein the Domain Name Server, DNS, information is encrypted (Vasudevan, [0061][0066], in some situations, classification based on only metrics like the domain name server (DNS), may be unreliable, because the networking systems are increasingly moving toward encrypting this information. That is, the DNS information is encrypted).
It would have been obvious to a person of ordinary skill in the art before the time of effective filing to combine the teachings of classifying traffic based on header information as given by Raman with the teachings of classification of packets with the DNS information being encrypted given by Vasudevan. The motivation for doing so would have been to ensure robustness of the system and to improve accuracy of classification (Vasudevan, [0009]).
Claim 1 is rejected similarly with claim 10.
Regarding claims 2 and 11, Raman and Head disclose the system of claim 10 wherein the analysis module is further configured to:
re-evaluate the packet to determine whether there is any further layer of obfuscation (Raman, col. 2, 2nd para., using a private key to obtain or evaluate the first encryption key, the second encryption key, the timestamp, and validate the request based on the first encryption key and the timestamp, and, if valid, decrypt payload of the request with the second encryption key. That is, extracting all the layer or fields in the header and validating and decrypting the payload using the layer components. Head, [0106], header parsing describes how to interpret a packet based upon a well-known set of protocols (by examining all the fields in the header)),
the obfuscation module is configured to remove any further layer of obfuscation until the payload of the packet is no longer obfuscated (Raman, col. 2, 2nd para., using a private key to obtain the first encryption key, the second encryption key, the timestamp, and validate the request based on the first encryption key and the timestamp, and, if valid, decrypt payload of the request with the second encryption key. That is, extracting/removing all the layer or fields in the header, validating and decrypting the payload using the layer components (or removing all the obfuscation of the payload). Head, [0106], header parsing describes how to interpret a packet based upon a well-known set of protocols (by examining or removing all the fields in the header and the payload)).
Regarding claims 3 and 12, Raman and Head disclose the method of claim 11 wherein the analysis module is configured to determine whether the payload comprises clear text when re-evaluating the packet (Raman, col. 2, 1st para., decrypting the payload, checking a payload hash to the payload to determine if there has been a modification of the payload or clear text. Head, [0106], header parsing describes how to interpret a packet based upon a well-known set of protocols).
Regarding claims 4 and 13, Raman and Head disclose the system of claim 10,
wherein the obfuscation module is configured to determine if the obfuscation is a XOR byte by byte or constant number obfuscation (Raman, col. 13, 2nd para., the authentication token includes a first encryption key, a second encryption key, and a timestamp. That is the number of obfuscation is 3. Head, [0106], the given pattern of bits used for a flow definition may include more fields (e.g., 10 or more) in the packet headers. I his case, the number of obfuscation is 10 or more).
It is noted that the applicant uses selective language in this claim and the examiner is only showing one of the claimed options.
Regarding claims 5 and 14, Raman and Head disclose the system of claim 10 wherein the analysis module is configured to determine a key in the header to be used to remove the layer of obfuscation (Raman, col. 2, 2nd para., using a private key to obtain the first encryption key, the second encryption key, the timestamp; decrypting the payload using the second encryption key).
Regarding claims 6 and 15, Raman and Head disclose the system of claim 10 wherein the classification module is configured to apply traffic policies to the obfuscated traffic flow based on the classification of the traffic flow (Raman, col. 5, 1st para., col. 10, 2nd para., security and policy enforcement; the device 300 intercepts and evaluates all Internet traffic; allowed traffic is tunneled to the cloud services such as in the security cloud 408, whereas the rest of the traffic is denied as per enterprise policies. For the dynamic traffic forwarding tunnels to authorized services, depending upon the evaluation, the device 300 splits the traffic into the different tunnel to individual cloud services such as in the security cloud 408. Head, [0062], performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening).
Regarding claims 8 and 17, Raman, Vasudevan and Head disclose the system of claim 10, wherein the traffic flow is an Internet Engineering Task Force (IETF) QUIC traffic flow (Vasudevan, [0066], newer transport layer protocols like QUIC, as well as other techniques such as DNS over HTTPS (DoH) and SNI encryption, can hide or encrypt connection information such as DNS).
Regarding claims 9 and 18, Raman and Head disclose the system of claim 10 wherein the analysis module is configured to compare the pattern of the header to known obfuscation signatures (Head, [0106], a flow may be defined as a set of packets whose headers match a given pattern of bits).
Claims 7, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Raman, Head and Vasudevan further in view of Pan (US 20210112002).
Regarding claims 7 and 16, Raman, Vasudevan and Head disclose the system of claim 10,
Raman, Vasudevan and Head do not explicitly disclose wherein the obfuscation module is configured to remove any padding between sections of the packet to determine the full payload.
Pan discloses wherein the obfuscation module is configured to remove any padding between sections of the packet to determine the full payload (Pan, [0118], remove preambles and padding, and provide packet content for processing by higher layers).
It would have been obvious to a person of ordinary skill in the art before the time of effective filing to combine the teachings of classifying traffic based on header information as given by Raman and Head with the teachings of removing padding to determine the payload given by Pan. The motivation for doing so would have been to follow a conventional approach in packet transmission system by removing/adding padding in the packet header.
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 ZHENSHENG ZHANG whose telephone number is (571)270-1985. The examiner can normally be reached Monday-Thursday 8:00am-6: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, Michael Thier can be reached at 571-272-2832. 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.
/ZHENSHENG ZHANG/Primary Examiner, Art Unit 2474