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
Claims 1-16 are presented for examination.
Claim 17 is cancelled.
Continued Examination Under 37 CFR 1.114
3. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/03/2026 has been entered.
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.
3. Claims 1-16 are rejected under 35 U.S.C. 103 as being unpatentable over BAREKET et al hereafter BAREKET (US pat. App. Pub. 20220045854) and in view of Christensen et al hereafter Christensen (US pat. App. Pub. 20110145572).
4. As per claim 1, BAREKET discloses a method for preventing malicious network traffic, the method comprising: providing, by a key generation appliance, a client key to a client device; receiving, by a control appliance, a data packet intended for an application server from the client device (paragraphs: 7-9, and 27-28); determining, by the control appliance, whether the data packet comprises the client key (paragraphs: 53, and 55); forwarding the data packet, by the control appliance, to the application server in response to a determination that the data packet comprises the client key; and blocking the data packet, by the control appliance, in response to a determination that the data packet does not comprise the client key (paragraphs: 56, and 58-59). Although, BAREKET mentions that if the data packet does not comprise the client key then the data packeted is not going to pass the gateway device. In the same field of endeavor, Christensen more specifically discloses blocking the data packet (paragraphs: 13-14).
Accordingly, it would been obvious to one of ordinary skill in the network security art before the effective filing date of the claimed invention to have incorporated Christensen’s teachings of blocking the data packet with the teachings of BAREKET, for the purpose of effectively protecting the data packet from any unauthorized intruders.
5. As per claim 2, BAREKET discloses the method, wherein determining whether the data packet comprises the client key, comprises: determining whether the client key comprised by the data packet is valid (paragraphs: 45-46).
6. As per claim 3, BAREKET discloses the method, wherein determining whether the data packet comprises the client key, comprises: determining, based on a time stamp of the client key, whether the client key comprised by the data packet has not expired (paragraphs: 81, 85, and 88).
7. As per claim 4, BAREKET discloses the method, wherein the client key provided to the client device is a first client key, and wherein determining whether the data packet comprises the client key, comprises: determining whether the data packet comprises the first client key or a second client key derivable from the first client key (paragraphs: 5, and 25-26).
8. As per claim 5, BAREKET discloses the method, wherein determining whether the data packet comprises the client key, comprises at least one of: a) determining, whether a previous data packet previously received from the client device comprises the first client key; and determining whether the data packet comprises the second client key; or b) determining, whether a previous data packet previously received from the client device comprises the second client key; and determining whether the data packet comprises a third client key different from the second client key, wherein the third client key is derivable from the first client key (paragraphs: 41, 43, and 47).
9. As per claim 6, BAREKET discloses the method, wherein determining whether the data packet comprises the client key, comprises: determining, whether the client key comprised by the data packet is associated with at least one of the client device or a user of the client device (paragraphs: 71-72, and 77).
10. As per claim 7, BAREKET discloses the method, wherein determining whether the data packet comprises the client key, comprises: determining, whether the data packet comprises the client key at a predetermined position within the data packet (paragraphs: 89, and 91).
11. As per claim 8, BAREKET discloses the method, further comprising: receiving, by the key generation appliance, an authentication key, wherein the authentication key is indicative of an authentication of at least one of the client device or a user of the client device; and providing, by the key generation appliance, the client key to the client device in response to at least one of the receipt or a validation of the received authentication key (paragraphs: 99, and 101-102).
12. As per claim 9, BAREKET discloses the method, further comprising: receiving, by the key generation appliance, a platform key associated with the client device; and providing, by the key generation appliance, the client key to the client device in response to at least one of the receipt or a validation of the received platform key (paragraphs: 10, 16, and 20).
13. As per claim 10, BAREKET discloses the method, further comprising: receiving, by an authentication appliance, user credentials of a user of the client device; and transmitting, by the authentication appliance, an authentication key to at least one of the key generation appliance or to the user device in response to at least one of the receipt of the user credentials or a validation of the received user credentials (paragraphs: 27-28, and 48).
14. As per claim 11, BAREKET discloses the method, further comprising: receiving by the control appliance, a plurality of data packets intended for the application server from the client device; determining, by the control appliance, whether multiple of the plurality of data packets comprise the client key; and at least one of: a) forwarding, by the control appliance, all of the data packets of the multiple data packets that comprise the client key to the application server; b) blocking, by the control appliance, all of the data packets of the multiple data packets that do not comprise the client key (paragraphs: 57-59).
15. As per claim 12, BAREKET discloses the method, further comprising: blocking, by the control appliance, all of the data packets of the multiple data packets that do not comprise the client key; and forwarding the remaining data packets of the plurality of data packets to the application server (paragraphs: 61-63).
16. As per claim 13, BAREKET discloses an apparatus for preventing malicious network traffic, the apparatus comprising: a control appliance; and a key generation appliance (paragraphs: 103-105).
17. As per claim 14, BAREKET discloses a system for preventing malicious network traffic, the system comprising: the apparatus; an authentication appliance, wherein the authentication appliance is configured to: receive user credentials of a user of the client device; and transmit an authentication key to the key generation appliance in response to at least one of the receipt of the user credentials or a validation of the received user credentials (paragraphs: 107, 110, and 111).
18. As per claim 15, BAREKET discloses the system, further comprising at least one of: the application server; or the client device (paragraphs: 78-79).
19. As per claim 16, BAREKET discloses the system a computer program stored in a non-volatile memory, the computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method (paragraphs: 78-79).
Conclusion
20. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD W REZA whose telephone number is (571)272-6590. The examiner can normally be reached on Monday-Friday 8:30-5:30 ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Cathy Thiaw can be reached on 571-270-1138. 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).
/MOHAMMAD W REZA/Primary Examiner, Art Unit 2407