DETAILED ACTION
Detailed Action
Response to Arguments
Applicant’s arguments filed April 09, 2026 have been fully considered. After further consideration, the prior art of record still reads on Applicant’s claim language.
Applicant asserts Wen’s efficiency focus is architecturally incompatible with the “state-heavy” and “computationally expensive” operations of Wang (decryption) and Hastings (protocol-specific parsing). Accordingly, the primary reference Wen “teaches away” from the proposed combination.
In response, The Examiner respectfully disagrees and asserts the legal standard for “Teaching Away” is not met. Under well-established Federal Circuit precedent, a reference “teaches away” from a combination only when it “criticize[s], discredit[s], or otherwise discourage[s]” the claimed solution. In re Gurley, 27 F.3d 551, 553 (Fed. Cir. 1994). A reference that merely focuses on a different problem, or that prefers a different embodiment, does not teach away from a combination. Meiresonne v. Google, Inc., 849 F.3d 1379, 1382 (Fed. Cir. 2017); Syntex (U.S.A.) LLC v. Apotex, Inc., 407 F.3d 1371, 1380 (Fed. Cir. 2005) (“a reference does not teach away if it merely expresses a general preference for an alternative invention but does not criticize, discredit, or otherwise discourage investigation into the invention claimed”); In re Fulton, 391 F.3d 1195, 1201 (Fed. Cir. 2004) (finding no teaching away where the prior art was simply silent on the claimed feature). The Examiner asserts Applicant has not identified a single passage in Wen that criticizes, discredits, or discourages the integration of SSL/TLS decryption or deep packet inspection into the hypervisor. Wen’s emphasis on efficiency is a design goal, not a prohibition. An efficiency goal is not equivalent to a warning against adding security inspection. See MPEP § 2145(1V)(A).
The Examiner further asserts Wen itself explicitly teaches decryption - fatally undermining the “Teaching Away” argument. Applicant’s foundational premise - that Wen is a “thin, stateless” hypervisor inherently opposed to encryption operations - is directly contradicted by Wen’s own specification. This is not a matter of inference; it is explicit disclosure:
Wen [0024]: “the network processor can be configured to perform any or a combination of data encryption, data decryption, and data acceleration.”
Wen [0042]: “integrated hypervisor 304 can be configured to negotiate security key and other information with VPN gateway 314 to provide transparent encryption service to the VMs 302.”
A reference cannot “teach away” from an operation it affirmatively and specifically teaches. The teaching-away argument collapses entirely when measured against these disclosures.
The Examiner further asserts Wen expressly contemplates hardware offload, resolving the “State-Heavy” concern. Applicant’s characterization of Wang’s decryption as too “state-heavy” for the hypervisor ignores Wen’s explicit architectural solution:
Wen [0038]: “integrated hypervisor 204 can be operatively coupled with a network processor to which processing of the unified threat management layer can be offloaded.”
Wen [0035]: “integrated hypervisor 204 can further be configured to offload various processing tasks to an application specific integrated circuit (ASIC) to achieve high performance.”
Wang’s session key management and Hastings’ stream parsing are precisely the categories of processing that Wen’s own architecture contemplates offloading to a dedicated network processor or ASIC. One of ordinary skill in the art reading Wen would immediately recognize that the offload path resolves the performance concern raised by Applicant. Applicant’s argument ignores half of Wen’s disclosure.
The Examiner further asserts Wen already contains stateful operations of equal complexity. The core of Applicant’s argument is that stateful, complex processing is incompatible with Wen’s hypervisor. However, Wen’s own UTM layer already includes:
Wen [0039]: “anti-virus, and intrusion prevention system services”
Antivirus scanning requires buffer management, signature-pattern matching across multi-packet streams, and heuristic analysis - all of which are stateful, computationally intensive operations. IPS is inherently stateful, requiring session table maintenance and payload reassembly. If the Applicant’s argument were correct, Wen’s own disclosed IPS and AV functions would be incompatible with Wen’s hypervisor - a result that Wen’s inventors plainly did not intend. The argument is self-defeating. See MPEP § 2143(1)(E) (applying a known technique to improve similar devices in the same way).
Applicant asserts decryption and structural validation are “blocking” operations creating a latency chokepoint at the hypervisor; and complex parsing logic in the hypervisor presents a “Security Risk to the Root of Trust.’’
In response, The Examiner respectfully disagrees and asserts the “Latency Chokepoint” argument is refuted by Wang’s own design goals. In addition, Applicant mischaracterizes Wang as a performance burden. Wang’s stated purpose is the precise opposite:
Wang [0014]: “there is a need for methods and systems that facilitate faster SSL inspection without the overhead associated with traditional SSL man-in-the-middle inspection devices.”
Wang [0007]: Wang’s method operates by “bypassing the TCP stack,” specifically to eliminate socket API overhead and reduce processing latency.
Wang [0024]: “the efficiency is improved” over prior art inspection methods.
Wang is not a “processing-heavy” approach – it is an efficiency-optimized approach purpose-built to minimize overhead. Combining Wen’s ASIC/network processor offload architecture [Wen 0035, 0038] with Wang’s inherently low-overhead inline inspection methodology does not create a chokepoint; it eliminates one. Furthermore, the “blocking” concern is an architectural implementation choice – not a patent claim limitation. The claim is directed to a functional product, not a specific performance threshold. See MPEP § 2115 (functional claim language).
In addition, The Examiner asserts the “Root of Trust” security risk argument is both unsupported and legally insufficient. First, this argument constitutes unsupported attorney argument. The Examiner asserts Attorney arguments cannot take the place of evidence. In re Geisler, 116 F.3d 1465, 1470 (Fed. Cir. 1997); MPEP § 2145(1) (“Mere arguments or conclusory statements... are not considered a rebuttal sufficient to overcome a prima facie case of obviousness.”). Applicant has submitted no declaration under 37 CFR 1.132, no expert testimony, and no technical publication establishing that Wang’s decryption or Hastings’ parsing introduces a security vulnerability when implemented in Wen’s hypervisor architecture. Second, Wen already places architecturally complex, security-critical code (IPS/AV engines) directly within the hypervisor [Wen 0039]. If hypervisor-resident security code were inherently a root-of-trust risk, Wen’s own invention would be defective. Applicant cannot simultaneously assert Wen is a valid and effective security platform and that adding analogous security processing to it constitutes an unacceptable risk. Third, Wen’s para-virtualization API [Wen 0034] provides a controlled, well-defined software interface between the UTM functions and the VMs. This architectural isolation mechanism specifically limits the attack surface of the hypervisor’s security components, addressing the concern Applicant’s representative raises.
Applicant asserts The Examiner provides no reasoned basis beyond a “generalized search for security” for why a person of ordinary skill in the art would burden Wen’s hypervisor with Wang’s and Hastings’ processing tasks. The combination would lead to instability and unacceptable latency, and there is no reasonable expectation of success.
In response, The Examiner respectfully disagrees and asserts the motivation is specific and problem-driven - not generalized. Under KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007), a court “must ask whether the improvement is more than the predictable use of prior-art elements according to their established functions.” The motivation here is not merely “security” – it is a specific, traceable chain of problem and solution:
Problem: Wen’s UTM/IPS/AV layer [Wen 0039] is blind to encrypted traffic (SSL/TLS), which constitutes the dominant fraction of modern network traffic. One of ordinary skill in the art building Wen’s system in the relevant timeframe would recognize this as a critical and specific functional gap.
Solution: Wang [0014, 0024] solves exactly this problem with low overhead, purpose-built inline SSL inspection. Wang’s method provides the cleartext payload that Wen’s inspection functions require to operate.
Extension: Hastings identifies a specific, documented class of attack (malware tunneling commands through upper-layer protocol fields. e.g., DNS exfiltration) [Hastings Background 0041] that bypasses standard IPS/AV inspections. Hastings’ protocol-specific data model validation extends Wen’s UTM to detect this documented attack class.
This is a specific, problem-solution motivation, not a generalized desire for security. See In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006) (“there must be some articulated reasoning with some rational underpinning to support the legal conclusion of obviousness”); MPEP § 2143(1)(A)-(G). Applicable KSR Rationale - MPEP § 2143(I)(A): “Combining prior art elements according to known methods to yield predictable results.’’ Wen provides the platform: Wang provides the decryption module; Hastings provides the deep inspection module. All three are known security components deployed within the same technological context (network security appliances). Their combination yields the predictable result of a hypervisor capable of inspecting encrypted, application-layer traffic. Applicable KSR Rationale - MPEP § 2143(I)(E): “Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results.” Wang’s inline SSL inspection is a known technique applied to improve Wen’s known hypervisor security platform, yielding the predictable result of encrypted-traffic visibility.
The Examiner further asserts Wen and Wang share a common assignee - substantially negating the “No Motivation” argument. A significant and undisputed fact in the record is that Wen (US 2016/0378529 Al) and Wang (US 2015/0113264 Al) are assigned to the same entity, Fortinet, Inc. This is not a trivial observation. When one of ordinary skill in the art is employed by or aware of an organization that has concurrently developed and patented both a hypervisor security platform (Wen) and an inline SSL inspection method (Wang), the combination of those two proprietary technologies is a direct commercial and engineering incentive. KSR, 550 U.S. at 421 (“One of ordinary skill is also a person of ordinary creativity, not an automaton”). The common assignee relationship is strong, objective evidence that the combination was not only obvious but commercially contemplated.
The Examiner further asserts the reasonable expectation of success standard is satisfied. The legal standard requires only a reasonable expectation of success - not a guarantee. Pfizer, Inc. v. Apotex, Inc., 480 F.3d 1348, 1364 (Fed. Cir. 2007); MPEP § 2143.02. The proposed combination does not involve unpredictable chemistry, novel biological interactions, or first-of-kind engineering. It involves the integration of three known, commercially deployed software security modules (hypervisor UTM, inline SSL decryptor, and DPI engine) within a well-understood network security appliance context. One of ordinary skill in the art with experience in network security architecture would have every reasonable expectation that assembling these modules - all from the same commercial vendor - would produce a functional system.
Applicant asserts NIST 800-207 is a “high-level conceptual framework” that provides no technical instruction on integrating SSL decryption or schema validation into a hypervisor and therefore cannot bridge technical gaps between Wen, Wang, and Hastings.
In response, The Examiner respectfully disagrees and asserts NIST Section 3.2 describes the hypervisor-as-PEP architecture specifically. Contrary to Applicant’s characterization, NIST does provide architectural guidance directly relevant to the claimed system. NIST Section 3.2.1 (Device Agent/Gateway-Based Deployment) describes an architecture in which a software agent deployed on or near enterprise assets acts as a Policy Enforcement Point (PEP) that mediates all access requests. The Wen hypervisor, positioned between VMs and the network, is architecturally identical to this PEP description. NIST did not merely provide philosophy - it provided a specific deployment model that maps directly onto Wen’s hypervisor architecture. In addition, The Examiner specifically asserts, least-privileged access, per-session trust verification, continuous re-evaluation, device posture assessment, user identity checks, BYOD access control, and cloud deployment - were well-known, authoritatively documented requirements in the art at the time of filing. Under KSR, 550 U.S. at 418, the motivation to combine requires only “a reason that would have prompted a person of ordinary skill in the relevant field to combine the elements.” NIST provides exactly and specifically that reason for each ZINA-related limitation: it establishes the industry mandate and documented need for those features, and it identifies them as the required components of a compliant zero-trust security architecture.
The Examiner further asserts NIST is prior art that establishes the state of the art for policy limitations. NIST SP 800-207 (August 2020) is a published Special Publication of the National Institute of Standards and Technology, a Federal agency operating under the Department of Commerce. It constitutes prior art as a “printed publication” under 35 U.S.C. § 102(a)(l). Its Tenets 1-7 establish that the features recited in the dependent claims were not novel at the time of filing - they were the industry-standard requirements for a zero-trust system. One of ordinary skill in the art designing a compliant security product would necessarily reference NIST SP 800-207 to ensure their product’s feature set satisfied these established requirements.
Applicant assert’s the rejection is a classic hindsight reconstruction using the application as a “blueprint” to cherry-pick features from “disparate fields” - virtualization management (Wen), session synchronization (Wang), and data leak protection (Hastings). None of the cited references suggest the integrated synergy claimed.
In response, The Examiner respectfully disagrees and asserts the references are not from disparate fields. Applicant characterizes Wen, Wang, and Hastings as references from three “disparate fields.” This characterization is factually incorrect. All three references reside in the same technical field (network security appliances/ unified threat management) and share overlapping CPC classification under the H04L 63/xx subclass (Network Security Protocols). Wen and Wang are co-assigned to Fortinet, Inc., a single commercial entity that develops and markets network security products. Hastings is a Fortinet patent directed to the FortiGate product’s DLP engine. These are not disparate academic fields - they are three components of the same commercial product family.
The Examiner further asserts KSR expressly rejects the requirement that references suggest their own combination. The Supreme Court in KSR explicitly and unambiguously rejected the rigid “teaching, suggestion, or motivation” (TSM) test as the sole measure of obviousness: “[R]igid [TSM] application... does not correctly set out the law.” KSR, 550 U.S. at 415. “When there is a design need or market pressure to solve a problem and there are a finite number of identified, predictable solutions, a person of ordinary skill has good reason to pursue the known options within his or her technical grasp.” KSR, 550 U.S. at 421.The argument that the references do not “suggest the integrated synergy claimed” is precisely the TSM argument KSR foreclosed. The question is not whether the references jointly suggest the specific architecture of the claims. The question is whether one of ordinary skill in the art would have had reason and capability to combine them. As demonstrated above - that showing has been made.
The Examiner further asserts the hindsight label does not eliminate the obviousness case because the hindsight argument is a conclusion, not a legal analysis. Every multi-reference obviousness rejection can be labeled ‘“hindsight” by the applicant. The test is whether the Examiner has provided specific, articulated rationale grounded in the references themselves - not whether the result resembles the claims. In re Kahn, 441 F.3d at 988. The Examiner has provided that specific rationale. The prima facie case is unrebutted.
Applicant asserts Claims 2 – 30 are patentable by virtue of their dependency from Claim 1, and independently, the specific limitations of the dependent claims - including rotated cryptographic keys, specific device identity verification, and dynamic creation of encrypted tunnels to a ZTNA application gateway - are neither taught nor suggested by the cited art.
In response, The Examiner respectfully disagrees and asserts dependency argument fails upon maintenance of Claim 1. The Applicant’s argument for Claims 2-30 rests entirely and exclusively on the patentability of independent Claim 1. Because the rejection of Claim 1 is maintained in full for the reasons set forth above, Claims 2-30 remain unpatentable by virtue of their dependency therefrom. See MPEP § 2143. In addition, Applicant specifically identified three categories of limitations as allegedly untaught. Each is addressed below with specific reference citations:
“A series of rotated cryptographic keys”:
Wang directly teaches the SSL/TLS session key framework in which keys are negotiated per session and per connection [Wang 0005: “session keys are generated on both the client and the server based on some random data and shared secrets”]. Wang [0146] specifically discloses the handling of cipher suite transitions between SSL sessions: “If the cipher suites or the TCP sequence numbers of SSL sessions 1 and 2 are not the same, then the encrypted raw packet... is amended.” This describes the scenario in which cryptographic key material is rotated between sessions - a direct teaching of key rotation. Furthermore, Wang [0025] describes session key re-negotiation via the TLS handshake, which is the mechanism by which key rotation is implemented in practice. A “series of rotated keys” is the natural and necessary result of Wang’s per-session key framework.
“Specific device identity verification”:
NIST SP 800-207 explicitly and specifically teaches device identity verification as a mandatory component of zero-trust policy. NIST Tenet 4 states: “Access to resources is determined by dynamic policy - including the observable state of client identity, application/service, and the requesting asset... device characteristics such as software versions installed, network location, time/date of request, previously observed behavior, and installed credentials.” NIST Section 3.3 further discusses device-specific policies, and NIST Assumption 2 explicitly addresses BYOD environments where device identity and ownership must be specifically verified before access is granted. This is not a general reference to “security” - it is specific teaching of device identity verification as a required policy enforcement step.
“Dynamic creation of encrypted tunnels to a ZTNA application gateway”:
Wen [0042] explicitly teaches on-demand creation of encrypted VPN/IPSec tunnels: “integrated hypervisor 304 can be configured to negotiate security key and other information with VPN gateway 314 to provide transparent encryption service to the YMs.” The word “negotiate” describes a dynamic, per-connection process - not a pre-established static tunnel. NIST Tenet 3 independently requires “access to individual enterprise resources is granted on a per-session basis,” which directly mandates that tunnels be created dynamically (on-demand per session). not statically. The combination of Wen’s VPN negotiation mechanism with NIST’s per-session mandate provides complete teaching of dynamic tunnel creation to a ZTNA application gateway.
In addition, The Examiner notes that Applicant bas not presented any objective indicia of non-obviousness (secondary considerations) in the Amendment and Response. No evidence of commercial success, long-felt but unsolved need, failure of others, or unexpected results has been submitted. See MPEP § 2145(1); Graham v. John Deere Co., 383 U.S. 1, 17-18 (1966). The Examiner therefore proceeds on the basis that no such evidence exists in the record.
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.
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.
Claims 1 – 30 are rejected under 35 U.S.C. 103 as being unpatentable over Wen (US Pub. No. 20160378529) in view of Wang (US Pub. No. 2015/0113264 A1) in view of Hastings (US Patent No. 9225734 B1) in view of NIST (NIST Special Publication 800-207: Zero Trust Architecture, 2020).
Per claim 1, Wen (US Pub. No. 20160378529) suggests a product for securing communications of a plurality of networked computing devices, the product comprising a non-transitory computer-readable storage medium (see Wen para 0045 and 0057) having computer-readable program code embodied therein (see Wen para 0045 and 0057), the computer-readable program code executable by a processor (see Wen para 0045 and 0057) to perform communication management operations, the communication management operations comprising: i) intercepting (reads on the integrated hypervisor intercepts data flow/packets, see Wen para 0035 – 0039) a first network packet (reads on data flow/packets, see Wen para 0035 – 0039) at a hypervisor (reads on hypervisor, see Wen para 0035 – 0039 and Figure 2 block 204) to obtain a first payload with a higher-than-OSI layer three portion (The Examiner construes this to be an obvious if not necessary limitation of the prior art’s disclosure of performing IPS/AV services because one of ordinary skill in the art would consider it within the realm of conventional computer science to obtain the complete payload at OSI Layer 4 or higher (Layers 4-7) because AV scanning fundamentally requires the actual, complete data (the payload) to analyze its full contents and context for malicious signatures or behavior, see Wen para 0035 – 0039) and a destination port number (reads on necessarily obtaining a destination port number during providing port scanning and firewall service, see Wen para 0039. The Examiner asserts one of ordinary skill in the art would know it is within the conventional operation of a firewall/port scanning operation to use the destination port number because that is the only place in the packet where port is represented. In addition, port scanning and firewall policy are L3/L4 operations that absolutely require parsing the IP header for destination IP and parsing the L4 header for the destination port), the destination port number assigned to a destination port on one of the plurality of networked computing devices (reads on Wen’s multi-VM/multi-host Figure 3 architecture where the hypervisor obtained destination port is by definition identifying a port on one of those VMs or external hosts/plurality of network computing devices, see Wen Figure 3 and para 0035 – 0039). The prior art of record does not explicitly state ii) decrypting, with a single-use cryptographic key, at least a portion of the first higher-than-OSI layer three portion of the first payload to obtain one or more first packet parameters; iii) confirming that the first payload conforms to at least one of a data model pre-assigned to the destination port number based on a comparison of the one or more first packet parameters with one or more first expected values; iv) after confirmation that the first payload conforms to the data model for the destination port, forming a second network packet comprising a second payload and at least one of a local program identification code or a data model identification code; and v) executing at least one instruction to send the second network packet to network security software on the destination port on the one of the plurality of networked computing devices via a zero-trust network access (ZTNA).
[0024] In an aspect, the integrated hypervisor can be operatively coupled with a network processor that is offloaded the processing of the unified threat management layer. In another aspect, the network processor can be configured to perform any or a combination of data encryption, data decryption, and data acceleration.
[0035] According to one embodiment, integrated hypervisor 204 can intercept data flow of VMs 202 by this para-API and can be configured to provide UTM (intrusion prevention system (IPS)/anti-virus (AV) and/or virtual private network (VPN)) services. Integrated hypervisor 204 can further be configured to offload various processing tasks to an application specific integrated circuit (ASIC) to achieve high performance. In an aspect therefore, integrated hypervisor 204 can be configured to provide at least one of a firewall service, an Internet Protocol Security (IPSec) service, a Virtual Private Network (VPN) service, a load balancing service, an intrusion detection and prevention system (IDS/IPS), a Unified Threat Management (UTM) service, data loss prevention (DLP) systems, Proxy/Gateway services, and other security services.
[0036] With reference to FIG. 2, integrated hypervisor 204 can be configured to receive packets from one or more NIC(s) 206 that interface with external network 208 such as the Internet.
[0037] Aspects of the present disclosure therefore relate to a system incorporating at least one VM 202 that is managed by an integrated hypervisor 204, wherein integrated hypervisor 204 includes a hypervisor that is integrated with a unified threat management (UTM) layer such that the integrated hypervisor intercepts data flow of the at least one VM and provides network security using the unified threat management layer.
[0038] In an aspect, integrated hypervisor 204 can be operatively coupled with a network processor to which processing of the unified threat management layer can be offloaded. In another aspect, the network processor can be configured to perform any or a combination of data encryption, data decryption, and data acceleration.
[0039] In another aspect, integrated hypervisor 204 can be configured to intercept and scan data flows between the at least one VM and Internet 208. Integrated hypervisor 204 can further be configured to, based on the unified threat management layer, provide any or a combination of packet security, port scanning, prevention of network attacks, load balancing, prevention of denial of service attacks, packet filtering, flow control, packet monitoring, anti-virus, and intrusion prevention system services. In an exemplary implementation, integrated hypervisor 204 can intercept and scan data flows between one or more VMs that integrated hypervisor 204 is coupled with, and, based on the unified threat management layer, provides any or a combination of packet security, port scanning, prevention of network attacks, load balancing, prevention of denial of service attacks, packet filtering, flow control, packet monitoring, anti-virus, and intrusion prevention system services.
[0042] According to one embodiment, virtualization architecture of the present disclosure can be operatively coupled with a VPN gateway 314 and/or a remote VPN client 316 through an external network such as Internet 310, wherein the VPN gateway 314 can be operatively coupled with one or more hosts such as 312-1 and 312-2. In an aspect, integrated hypervisor 304 can be configured to negotiate security key and other information with VPN gateway 314 to provide transparent encryption service to the VMs 302 installed on it. In another aspect, remote VPN gateway 314 can be a network controller and can be configured to implement one or more VPN protocols such as Internet Protocol Security (IPSec). In another aspect, integrated hypervisor 304 can utilize data encryption and decryption acceleration feature of the network processor 308 to provide high performance VPN service with little system CPU overhead.
Wang (US Pub. No. 2015/0113264 A1) is relied upon to teach
ii) decrypting (reads on decrypting an encrypted packet to get plain data, see Wang para 0045, 0143 and 0147), with a single-use cryptographic key (reads on the obvious single-use cryptographic key modern, secure implementations of protocols like TLS, IKE, and IKEv2 almost exclusively use ephemeral DH/ECDH (DHE/ECDHE) to ensure forward secrecy, see Wang para 0045 and 0147. The Examiner asserts ephemeral session keys, as a standard in TLS 1.2 are used for one session and one session only), at least a portion of (reads on the encrypted raw packet data that when decrypted produces the plain text, see Wang Figure 6 block 640. The Examiner asserts one of ordinary skill in the art would know the specific bits that get turned into plain text are the encrypted SSL/TLS payload contained within the raw packet) the first higher-than-OSI layer three portion of the first payload (reads on the encrypted payload, see Wang Figure 6 and para 0143. The Examiner asserts one of ordinary skill in the art would know the encrypted payload is the same as the encrypted application layer data residing above layer 3/4) to obtain (reads on the inherent obtaining that accompanies the scanning, see Wang claim 1) one or more first packet parameters (reads on the plain data/text, see Wang para 0143); iv) after confirmation (reads on if the scan passed the inspection policies, see Wang para 0144 and Figure 6 block 660. The Examiner asserts Wang establishes a conditional gate where the packet processing only happens after this confirmation) that the first payload (reads on the encrypted payload, see Wang Figure 6 and para 0143) conforms to the data model (reads on passing the scan based on the inspection policies for port 443/SSL, see Wang para 0126 and 0144. The Examiner construes the claimed data model to be reasonably scoped as Wang’s inspection policies because these polices define the model/what the payload should or should not contain) for the destination port (reads on port 443, see Wang para 0126), forming a second network packet (reads on composing a new encrypted packet, see Wang Figure 6 block 670) comprising a second payload (reads on the same data re-encrypted with session 2 key/cipher suite, see Wang Figure 6 block 670 and para 0146) and at least one of a local program identification code (The Examiner construes the modified TCP sequence number to be the functional equivalent of a local program identification code for a packet within a specific session, see Wang para 0146).
[0038] The phase "security protocol" generally refers to a cryptographic protocol or encryption protocol that performs a security-related function and/or applies cryptographic methods. Security protocols are commonly used for secure application-level data transport. Examples of security protocols include, but are not limited to, SSL, TLS, Internet Key Exchange (IKE), IP Security (IPSec), Kerberos and Point-to-Point Protocol (PPP). The following documents are hereby incorporated by reference in their entirety for all purposes: [0039] Request for Comments (RFC) 6101, entitled "The Secure Sockets Layer (SSL) Protocol Version 3.0" and dated August 2011; [0040] RFC 5246, entitled "The Transport Layer Security (TLS) Protocol Version 1.2" and dated August 2008; [0041] RFC 4306, entitled "Internet Key Exchange (IKEv2) Protocol" and dated December 2005; [0042] RFC 6071, entitled "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap" and dated February 2011; [0043] RFC 4120, entitled "The Kerberos Network Authentication Service (V5)" and dated July 2005; and [0044] RFC 1661, entitled "The Point-to-Point Protocol (PPP)" and dated July 1994.
[0045] FIG. 2 illustrates exemplary handshake process units of an inline SSL inspection system in accordance with an embodiment of the present invention. An SSL session (e.g., SSL session 1 and SSL session 2) can be separated into two phases according to the SSL protocol. One phase is the handshake/key-exchange phase in which asymmetric cryptography is used to negotiate symmetric cryptographic keys. Depending on different key exchange algorithms, such as RSA, Diffie-Hellman (DH), Elliptic Curve DH (ECDH), session keys are generated on both the client and the server based on some random data and shared secrets. The other phase is the application data transmission phase in which application data encrypted by session keys are transmitted between the SSL client and SSL server. FIG. 2 illustrates process units of a security device (e.g., firewall 220) controlling the handshake phases of two SSL sessions between the security device and an SSL client 210 and an SSL server 230.
[0143] At block 640, the inspection module decrypts the encrypted raw packet to produce plain data using the session key between the SSL client and the firewall.
[0144] At block 650, the inspection module scans the plain data based on its inspection policies. If the scan fails, then the inspection module informs the kernel to drop the packet. If the scan passed, the procedure continues with block 660.
[0146] If the cipher suites or the TCP sequence numbers of SSL sessions 1 and 2 are not the same, then the encrypted raw packet of SSL session 1 is amended or a new encrypted packet is composed at block 670. Here, if the cipher suites in SSL session 1 and 2 are the same while the TCP sequence numbers of SSL sessions 1 and 2 are not matched, then the TCP sequence number of the encrypted raw packet of SSL session 1 in the TCP/IP stack can be revised to the TCP sequence number of the SSL session 2. The checksum field of the raw packet of SSL session 1 can be re-calculated and revised if the TCP sequence number is amended. If the encrypted raw packet is not allowed to be amended in the TCP/IP stack, then a TCP packet header with the TCP sequence number of SSL session 2 can be created and the created TCP header and the data field of the encrypted raw packet of SSL session 1 can be synthesized together to form a composed encrypted packet. If the cipher suite of the SSL sessions 1 and 2 are not the same, then plain data decrypted from the encrypted raw packet of SSL session 1 can be re-encrypted to create a new encrypted packet for transmission in SSL session 2. The amended raw packet, the composed encrypted packet or the new encrypted packet is then transmitted at block 680.
[0147] While embodiments of the present invention are described above in connection with the SSL protocol, it is to be understood that similar security protocols that provide communication security over the Internet, such as TLS, IKE, IKEv2, IPSec, Kerberos, Point to Point Protocol and the like, may also be the subject of inline inspection consistent with the embodiments described herein. Similarly, security protocols that use asymmetric cryptography for authentication of key exchange and symmetric encryption for confidentiality may also be the subject of inline inspection in the manner described herein.
1. A method comprising: receiving, by a security device, an encrypted raw packet from a first network appliance; buffering the encrypted raw packet in a buffer; accessing, by an inspection module of the security device, the encrypted raw packet from the buffer; decrypting the encrypted raw packet, by the inspection module, to produce plain text; and scanning, by the inspection module, the plain text.
PNG
media_image1.png
1180
760
media_image1.png
Greyscale
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to incorporate the inline inspection method teachings of Wang that decrypts SSL/TLS traffic to provide plain text to an inspection module (see Wang para 0013 – 0014) into the integrated hypervisor that provides unified threat management services, including antivirus and intrusion prevention into the system of Wen (see Wen para 0039) to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Wen explicitly aims to increase the efficiency of virtualization architecture by integrating security services like antivirus and IPS directly into the hypervisor (see Wen para 0008 and 0039) and Wang provides the necessary cleartext payload that Wen’s UTM layer requires to function/scan for viruses, while maintaining the performance goals central to Wen. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Wang would have yielded predictable results and resulted in an improved system. It would have been recognized that implementing Wang’s inline decryption to improve Wen’s hypervisor security by enabling inspection of encrypted traffic would have yielded the predictable result of a hypervisor capable of inspecting encrypted payloads. The motivation to combine the references is applied to all claims below this heading.
Hastings (US Patent No. 9225734 B1) is relied upon to teach
iii) confirming that the first payload conforms (The Examiner construes this to be a necessary limitation of using the protocol decoder, request decoder and field extractor to parse a packet. The Examiner asserts Hastings is a security reference that is looking for signs that a protocol payload structure is being abused and the successful use of protocol decoder, request decoder and field extractor is at least an implicit confirming that the payload conforms to the protocol structure, see Hastings col. 8 lines 28 – 59 and col. 11 lines 11 – 24) to at least one of a data model (reads on data structure defined by the corresponding protocol, see Hastings col. 11 line 62 – col. 12 line 11) pre-assigned to the destination port number (reads on the protocol may be determined by the destination port of the data packet, see Hastings col. 8 lines 28 – 37) based on a comparison of the one or more first packet parameters (reads on the content extracted from the specific fields of the packet, see Hastings Figure 4 block 408 and Figure 5 block 503 and col. 9 lines 29 – 45) with one or more first expected values (reads on matching/comparing key words or regular expressions, see Hastings col. 12 lines 12 – 39).
[col. 8 lines 28 – 37]
The data packet is analyzed by protocol decoder 301 to identify an upper layer protocol with which the data packet is associated. In one embodiment, the upper layer protocol may include any protocol residing in OSI layers five or above. The protocol of the data packet may be determined by the destination port of the data packet. For example, if the destination port is 53, the upper layer protocol of the data packet may be determined to be the DNS protocol. If the destination port is 21, the upper layer protocol of the data packet may be determined to be FTP.
[col. 9 lines 29 – 45]
Next, a field extractor 303 may be used for parsing one or more fields of the request or command that are identified by request decoder 302. In network communication, each request or command has a format that is defined by the corresponding protocol. The request or command may contain a header and a data portion. The header and data portion may have multiple fields that may have a fixed or variable length. Based on each protocol, requests or commands that have or do not enough space to carry sensitive information and requests or commands that have fields that may be utilized for data leakage may be identified. Therefore, field extractor 303 may extract one or more fields that may contain enough space for hiding sensitive information from a request based on the corresponding protocol of the data packet. For example, a DNS packet may be parsed based on various Requests for Comments (RFCs), for example, defining the DNS protocol. Table 1 shows the structure of a DNS query message header.
[col. 11 lines 11 – 24]
At block 405, the gateway may determine if the identified requests or commands should be scanned for data leakage. Usually, a few requests/commands of a protocol may contain parameters or fields that have enough space for carrying sensitive information although these requests/commands are not designed for transmission of messages or files. The gateway may maintain a list of these requests/commands for each upper layer protocol. The list may be predefined or configurable by the network administrator through a control panel interface, for example. Table 3 provides a non-limiting list of exemplary requests/commands that are not specifically defined for transmission of messages or files but which may nonetheless be misused by malware to send sensitive information out of a network.
[col. 11 line 62 – col. 12 line 11]
At block 407, one or more particular fields that may be utilized for carrying sensitive information may be extracted from the request/command by a protocol parser based on the data structure defined by the associated protocol. The particular fields may include, but is not limited to, the fields listed in Table 3 and a dedicated protocol parser may be used for analyzing the data packet and extracting one or more particular fields of a request/command of an upper layer protocol. In some embodiments, if the data packet at issue is encrypted, it may be decrypted by a decryption unit before extracting the field. For example, if the request is secured with secure sockets layer (SSL), the data packet may be first decrypted by an SSL proxy. Then, the decrypted data packet may be processed to identify the request/command of the data packet and a particular field may be extracted from the decrypted data packet.
[col. 12 lines 12 – 39]
At block 408, the request/command or a particular field of the request is scanned by the DLP engine for any sensitive information. Key words or regular expressions of sensitive information may be defined and stored in sensors of the gateway by the network administrator. The DLP engine may detect data leak by matching the request or a field of the request with key words or regular expressions of the sensors. One or more additional or alternative data identification methodologies (predefined or defined or configurable by the network administrator) may be used in place of or to supplement regular expressions and key words including, but not limited to, content registration, contextual analysis, lexicons, extended regular expressions, meta data tags, Bayesian analysis, statistical analysis, machine learning and the like. If no match is found by the DLP engine (meaning no sensitive or confidential information has been identified to be contained within the data packet at issue), the data packet is passed by the gateway at block 409. If a match is found in the request (meaning sensitive or confidential information has been identified to be contained within the data packet at issue), an action associated with the corresponding sensor by the network administrator is taken by the gateway. For example, the data packet may be dropped or a warning message identifying the detected data leakage may be sent to the network administrator. Additionally or alternatively, an event and/or the data packet or a portion thereof may be recorded in a log for further inspection.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the hypervisor platform that has access to decrypted payloads teachings of the prior art of record (see Wen para 0008, 0039 and Wang para 0013 – 0014) by integrating the deep packet inspection/data model validation that inspects upper layer protocols/Layers 5 – 7 by parsing fields based on the protocol’s data model/structure (see Hastings col. 8 lines 28 – 59, col. 11 lines 11 – 24, col. 11 line 62 – col. 12 line 39) to enhance the intrusion prevention capabilities explicitly claimed by Wen to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known deep packet inspection and data model validation logic taught by Hastings would have yielded predictable results and resulted in an improved system. While Wen discloses general intrusion prevention and packet filtering (see Wen para 0039), Hastings provides a specific, robust methodology for implementing these protections against sophisticated threats, resulting in an improved system that uses all available known in the art techniques to improve the security for upper-layer protocols anomalies. The resulting system provides the hypervisor as the ideal location and the ideal state of decrypted packets to perform the deep packet inspection taught by Hastings. One of ordinary skill in the art would be motivated to apply Hastings’ protocol-specific parsing/validating against a data model to the payloads intercepted by Wen. This combination does not change the function of Hastings’ method; but rather, it simply moves the inspection point to Wen’s hypervisor. The result is predicable – a hypervisor security system with enhanced detection capabilities for upper-layer protocol analysis. The motivation to combine the references is applied to all claims below this heading.
NIST (NIST Special Publication 800-207: Zero Trust Architecture, 2020) is relied upon to teach
v) executing at least one instruction (reads on the PA sending configuration commands to the PEP, where the commands instruct the PEP to establish the connection enabling the sending of the packet to its destination, see NIST Figure 2 and Section 3:Subsection: Policy Administrator and Policy enforcement point) to send the second network packet (reads on the sending of encrypted application data sent over the newly created channel after the initial request was authorized, see NIST Section 3.2.1 and Figure 3) to network security software (reads on the gateway that resides at the destination/in front of the resource and listens on a specific port configured by the PA, see NIST Section 3.2.1) on the destination port (reads on the gateway as the termination point for the connection which is functionally equivalent to listening on the port the client connects to, see NIST Section 3.2.1) on the one of the plurality of networked computing devices (reads on the resource that hosts the application/service being accessed, see NIST Abstract, Section 2, Section 2.1 and 3.2.1) via a zero-trust network access (ZTNA) (reads on the secure communications channel established by the policy enforcement point to connect the subject to the resource, see NIST Section 3.2.1 and Figure 3).
[Abstract]
Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. A zero trust architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and workflows. Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established. Zero trust is a response to enterprise network trends that include remote users, bring your own device (BYOD), and cloud-based assets that are not located within an enterprise owned network boundary. Zero trust focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource. This document contains an abstract definition of zero trust architecture (ZTA) and gives general deployment models and use cases where zero trust could improve an enterprise’s overall information technology security posture.
PNG
media_image2.png
1590
818
media_image2.png
Greyscale
PNG
media_image3.png
1540
800
media_image3.png
Greyscale
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the technically advanced inspection teachings of the prior art of record (see Hastings col. 8 lines 28 – 59, col. 11 lines 11 – 24, col. 11 line 62 – col. 12 line 39 and Wen para 0008, 0039 and Wang para 0013 – 0014) by integrating the industry standard security policy teachings of NIST (see NIST Abstract, Section 2.1) to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that the security product of the prior art of record is only as effective as the policies it enforces and updating the enforcement logic to align with Zero Trust/the dominant modern security paradigm is a routine optimization that ensures the product remains commercially viable and effective against modern threats that NIST specifically addresses. It would have been recognized that implementing the Zero Trust security paradigm is not an invention of a new architecture, but the application of the prior art device to the specific architectural role/PEP described by NIST, yielding the predictable result of a Zero Trust compliant virtualized environment. The motivation to combine the references is applied to all claims below this heading.
Per claim 2, the prior art of record further suggests, wherein the ZTNA comprises an access control policy that conducts user and device checks (reads on access to resources is determined by dynamic policy including the observable state of client identity and the requesting asset, see NIST Section 2.1 Tenet 4 and 6 and Section 3.1.3 and 3.2.1) for every application session for users (reads on access to individual enterprise resources is granted on a per-session bases, see NIST Section 2.1 Tenet 3), including remote users(see NIST Section 2.1, Section 2.2 Assumption 6 and Section 4.1).
Per claim 3, the prior art of record further suggests wherein the ZTNA employs least-privileged access(see NIST Section 2.1 Tenet 3).
Per claim 4, the prior art of record further suggests wherein the ZTNA continuously verifies the trust for all applications (see NIST Section 2.1 Tenet 6).
Per claim 5, the prior art of record further suggests wherein the ZTNA revokes access based on changes in user behavior or app behavior (reads on access to resources is determined based on behavioral attributes, see NIST Section 2.1 Tenet 4 and Section 3).
Per claim 6, the prior art of record further suggests wherein the ZTNA conducts a higher than OSI layer three inspection of all traffic (see the combination of Hastings col. 8 lines 28 - 37 and Wang para 0038. The Examiner asserts SSL/TLS operate at layer 6).
Per claim 7, the prior art of record further suggests wherein the access control policy conducts a higher than OSI layer three and lower than OSI layer seven inspection of all traffic (see the combination of Hastings col. 8 lines 28 - 37 and Wang para 0038. The Examiner asserts SSL/TLS operate at layer 6).
Per claim 8, the prior art of record further suggests wherein the ZTNA verifies the user (see NIST Section 2.1 Tenet 6, Tenet 4 and Abstract).
Per claim 9, the prior art of record further suggests wherein the ZTNA confirms the security level of the user device (see NIST Section 2.1 Tenet 5).
Per claim 10, the prior art of record further suggests, wherein the ZTNA detects and blocks malware (reads on confirming the device security posture and detecting and blocking malware via AV/IPS, see NIST Section 2.1 Tenet 5 and Wen para 0035 and 0039. The Examiner asserts the combination of references has the Wen hypervisor acting as the ZTNA PEP, and its inherent AV/malware blocking capability is one of the posture/security checks the NIST framework calls for).
Per claim 11, the prior art of record further suggests wherein the ZTNA provides application access control for users (reads on zero trust focusses on protecting resources and user accounts, see NIST Section 1, Section 2.1 Tenet 3, 4, 6 and Abstract), including remote users (see NIST Section 2.1, Section 2.2 Assumption 6 and Section 4.1).
Per claim 12, the prior art of record further suggests wherein the access control includes role-based access control (reads on access policies based on subject attributes/privileges, see NIST Section 3.3).
Per claim 13, the prior art of record further suggests wherein the ZTNA conducts user and device checks for applications (reads on zero trust focusses on protecting resources and user accounts, see NIST Section 1, Section 2.1 Tenet 3, 4, 6 and Abstract) in a data center or in a cloud (reads on cloud services, see NIST Section 2.2 Assumption 4, Section 4.1 and Section 4.2).
Per claim 14, the prior art of record further suggests wherein the ZTNA employs a cloud-based architecture (reads on any enterprise environment can be designed with zero trust tenets including hosting PE/Pas as a cloud service, see NIST Section 4.1 and 4.2).
Per claim 15, the prior art of record further suggests wherein the ZTNA conducts user and device checks for applications (reads on zero trust focusses on protecting resources and user accounts, see NIST Section 1, Section 2.1 Tenet 3, 4, 6 and Abstract) in a private or public cloud (reads on any enterprise environment can be designed with zero trust tenets including hosting PE/Pas as a cloud service, see NIST Section 4.1 and 4.2).
Per claim 16, the prior art of record further suggests wherein the ZTNA creates automatic, encrypted tunnels to the ZTNA application gateway (reads on the combination of references that teach the VPN gateway that transparently configures/implements secure channels for application access, see Wen para 0042 and NIST Section 2.1 Tenets 2 and 3).
Per claim 17, the prior art of record further suggests wherein the ZTNA verifies user identity, device identity, and conducts posture check prior to access (see NIST Section 2.1 Tenets 4 and 5).
Per claim 18, the prior art of record further suggests wherein the device identity verification includes verifying user identity or the policy for a user (see NIST Section 2.1 Tenet 4).
Per claim 19, the prior art of record further suggests wherein the device identity verification includes verifying whether the device is a personal device (see NIST Abstract, Section 2.2 Assumption 2, Section 3.2.3 and 7.3.2).
Per claim 20, the prior art of record further suggests wherein the device identity verification includes verifying whether devices are permitted access to the application (reads on access decisions/authorizations based on dynamic policy that includes the requesting asset/device as a factor, see NIST Section 2, 2.1 Tenet 4 and Section 3.1.1).
Per claim 21, the prior art of record further suggests wherein the application access includes (remote software application access reads on the use cases of remote users and enterprise with satellite facilities, see NIST Section 4.1), cloud access (reads on the use cases of multi-cloud, see NIST Section 4.2), and data center applications (reads on the use cases of on-premises data centers, see NIST Section 4.2).
Per claim 22, the prior art of record further suggests wherein the encrypted tunnels to the ZTNA application gateway is transparent to the user (reads on provide transparent IPSec encryption service, see Wen para 0042).
Per claim 23, the prior art of record further suggests wherein the encrypted tunnels to the ZTNA application gateway is created on demand (reads on the combination of references that teach the VPN gateway that transparently configures/implements secure channels for application access, see Wen para 0042 and NIST Section 4.1.3, 3.2.1 and 2.1 Tenets 2 and 3).
Per claim 24, the prior art of record further suggests wherein the encrypted tunnels to the ZTNA application gateway is created for access both on and off the network (reads on all encrypted application/service data flows/communication be secured/encrypted regardless of user location, see NIST Section 2.1 Tenet 2, Section 3.2.1 and 3.1.3).
Per claim 25, the prior art of record further suggests, wherein the ZTNA performs a device posture assessment (see NIST Section 2.1 Tenet 5).
Per claim 26, the prior art of record further suggests, wherein the communication management operations (reads on the combination of the integrated hypervisor that intercepts network traffic of Wen para 0035 – 0039, the logic/decision making of NIST Sections 2.1, 2.2, the decrypting and packet forming of Wang para 0045, 0126, 0143 – 0147 and sending via ZTNA of NIST Sections 2.1, 2.2, 3 and 4) further comprise conducting a higher than OSI layer three inspection on all or substantially all packets (see the combination of Hastings col. 8 lines 28 - 37 and Wang para 0038. The Examiner asserts SSL/TLS operate at layer 6).
Per claim 27, the prior art of record further suggests wherein the communication management operations (reads on the combination of the integrated hypervisor that intercepts network traffic of Wen para 0035 – 0039, the logic/decision making of NIST Sections 2.1, 2.2, the decrypting and packet forming of Wang para 0045, 0126, 0143 – 0147 and sending via ZTNA of NIST Sections 2.1, 2.2, 3 and 4) enable customizable automated incident response (reads on administrator configurable action is taken based on a detected DLP match/incident, see Hastings col. 6 line 59 – col. 7 line 3 and col. 12 lines 12 - 39).
Per claim 28, the prior art of record further suggests wherein the communication management operations (reads on the combination of the integrated hypervisor that intercepts network traffic of Wen para 0035 – 0039, the logic/decision making of NIST Sections 2.1, 2.2, the decrypting and packet forming of Wang para 0045, 0126, 0143 – 0147 and sending via ZTNA of NIST Sections 2.1, 2.2, 3 and 4) support multiple identity provider configurations (see NIST Section 3 and 4.4).
Per claim 29, the prior art of record further suggests wherein the communication management operations (reads on the combination of the integrated hypervisor that intercepts network traffic of Wen para 0035 – 0039, the logic/decision making of NIST Sections 2.1, 2.2, the decrypting and packet forming of Wang para 0045, 0126, 0143 – 0147 and sending via ZTNA of NIST Sections 2.1, 2.2, 3 and 4) identify port-based rules (see Hastings col. 10 lines 52 – 57 and col. 11 line 62 – col. 12 line 10).
Per claim 30, the prior art of record further suggests wherein the data model comprises port-based rules that are converted to application-based whitelist rules (reads on the system with “allow only” rule that starts with a port number to identify traffic and applies content-level rules, see Wen para 0039 and Hastings col. 10 lines 52 – 57 and col. 11 line 62 – col. 12 line 10).
Conclusion
The prior art of record still reads on Applicant’s claim language. 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.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is ((571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
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.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
Prosecution Insights