Israel L'Heureux et al.Download PDFPatent Trials and Appeals BoardAug 29, 201914197019 - (D) (P.T.A.B. Aug. 29, 2019) Copy Citation UNITED STATES PATENT AND TRADEMARK OFFICE UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www.uspto.gov APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO. 14/197,019 03/04/2014 ISRAEL L'HEUREUX 0013C1 3920 99476 7590 08/29/2019 Mark D. Alleman 12550 SW Iron Mountain Blvd. Portland, OR 97219 EXAMINER RAZA, MUHAMMAD A ART UNIT PAPER NUMBER 2449 NOTIFICATION DATE DELIVERY MODE 08/29/2019 ELECTRONIC Please find below and/or attached an Office communication concerning this application or proceeding. The time period for reply, if any, is set in the attached communication. Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the following e-mail address(es): mark.alleman@gmail.com michael@andriconsulting.com patents@andriconsulting.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ Ex parte ISRAEL L‘HEUREUX and MARK D. ALLEMAN ___________ Appeal 2017-011609 Application 14/197,019 Technology Center 2400 ____________ Before MAHSHID D. SAADAT, ERIC B. CHEN, and CARL L. SILVERMAN, Administrative Patent Judges. CHEN, Administrative Patent Judge. DECISION ON APPEAL Appeal 2017-011609 Application 14/197,019 2 This is an appeal under 35 U.S.C. § 134(a) from the final rejection of claims 21 and 24–40. Claims 1–20, 22, and 23 have been cancelled. We have jurisdiction under 35 U.S.C. § 6(b). An oral hearing scheduled for June 25, 2019 was waived. We reverse. STATEMENT OF THE CASE Appellants’ invention relates a network appliance configured to receive from a client device, via a client-side wide area network, an HTTP non-compliant request stream including HTTP non-compliant requests. The network appliance is further configured to translate the HTTP non-compliant requests of the HTTP non-compliant request stream into HTTP compliant requests of an HTTP compliant request stream, and to forward the HTTP compliant request stream including the HTTP compliant requests to server devices via a server-side local area network. (Abstract.) Claim 21 is exemplary, with disputed limitations in italics: 21. A network communications system, comprising: a network appliance including a processor configured to: receive from a client device via a client-side wide area network, a non-compliant request stream including multiple non-compliant requests formatted according to a non-compliant application level protocol that is non-compliant with RFC 1945/HTTP/1.0 and RFC 2616/HTTP/1.1 at least because the non-compliant application level protocol multiplexes the multiple non-compliant requests of the client device over an application level protocol specified number of client-side TCP connections between the client-device and the network appliance; translate the multiple non-compliant requests of the non- compliant request stream from the non-compliant application level protocol into multiple compliant requests of a compliant Appeal 2017-011609 Application 14/197,019 3 request stream formatted according to a compliant application level protocol that is compliant with one of RFC 1945/HTTP/1.0 and RFC 2616/HTTP/1.1, by demultiplexing the multiple noncompliant requests from the application level protocol specified number of client-side TCP connections to a programmatically specified number of persistent server-side TCP connections, the application level protocol specified number being less than the programmatically specified number; forward the compliant request stream including the multiple compliant requests to one or more server devices via the persistent server-side TCP connections on a server-side local area network; receive a compliant response stream including multiple compliant responses from the one or more server devices via the persistent server-side TCP connections on the server-side local area network, the multiple compliant responses being responsive to the multiple compliant requests, the multiple compliant responses formatted according to the compliant application level protocol that is compliant with one of RFC 1945/HTTP/1.0 and RFC 2616/HTTP/1.1; translate the multiple compliant responses of the compliant response stream into multiple non-compliant responses of a non-compliant response stream formatted according to the non-compliant application level protocol that is non-compliant with RFC 1945/HTTP/1.0 and RFC 2616/HTTP/1.1 by multiplexing the multiple compliant responses for the client device from the programmatically specified number of persistent server-side TCP connections to the application level protocol specified number of client-side TCP connections between the client device and the network appliance; and forward the non-compliant response stream including the multiple non-compliant responses to the client device via the client-side TCP connections on the client-side wide area network; Appeal 2017-011609 Application 14/197,019 4 the processor of the network appliance executing a translator module and an application delivery controller module, the translator module including one or more of: a rewriter module configured to modify one or more of a URL, a header, or a data payload of the non- compliant request stream or the non-compliant response stream; a protocol module configured to select the non- compliant application level protocol from a plurality of protocols supported by the network appliance; a stream decomposer configured to translate the non-compliant request stream into the compliant request stream; a stream recomposer configured to translate the compliant response stream into the non-compliant response stream; and a rules engine configured to instruct one or more of the rewriter module of the translator module, protocol module, stream decomposer, or stream recomposer to perform respective actions in accordance with the one or more rules upon satisfaction of a respective condition associated with each rule; the application delivery controller module including one or more of: a rewriter module configured to modify one or more of a URL, a header, or a data payload of the compliant request stream or the compliant response stream; a load balancer module configured to load balance the forwarded compliant requests of the compliant request stream among a plurality of server devices including the one or more server devices; a multiplexer/demultiplexer module configured to multiplex one or more of the compliant requests of the client device with one or more other compliant requests of one or more other client devices, and demultiplex one or more of the compliant responses for the client device Appeal 2017-011609 Application 14/197,019 5 from one or more other compliant responses for one or more other client devices; and a rules engine configured to instruct one or more of the rewriter module of the application delivery controller, load balancer module, or multiplexer/demultiplexer module to perform respective actions in accordance with the one or more rules upon satisfaction of a respective condition associated with each rule. Claims 21 and 24–40 stand rejected under 35 U.S.C. § 112(a) as failing to comply with the written description requirement. Claims 21 and 24–40 stand rejected under 35 U.S.C. § 112(b) as indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention. Claims 21 and 24–40 stand rejected under 35 U.S.C. § 103 as unpatentable over Zilbershtein (US 2008/0008211 A1; Jan. 10, 2008), Watson (US 2011/0222404 A1; Sept. 15, 2011), and Christenson (US 2008/0114882 A1; May 15, 2008). ANALYSIS § 112(a) Rejection We are persuaded by Appellants’ arguments (App. Br. 17) that the functional limitations recited in independent claims 21 and 35 comply with the written description requirement under 35 U.S.C. § 112(a). The Examiner found that “[e]ven original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently Appeal 2017-011609 Application 14/197,019 6 identify how the invention achieves the claimed function.†(Final Act. 5.) In particular, the Examiner found the following: Applicant does not even disclose a representative number of species (i.e., algorithms or steps/procedures) in the specification for the claimed genus for achieving the functionality “translate the multiple non-compliant requests of the non-compliant request stream from the non-compliant application level protocol into multiple compliant requests of a compliant request stream . . . translate the multiple compliant responses of the compliant response stream into multiple non-compliant responses of a non-compliant response stream formatted according to the non-compliant application level protocol†(Id. at 7–8.) We do not agree with the Examiner’s findings. Figure 2 of Appellants’ Specification illustrates a flow diagram for an exemplary network communications method 200 (¶ 19), which includes steps 210 to 224 (¶¶ 21–29). In one embodiment, network communications method 200 can be executed on network appliance 110, as illustrated in Figure 1. (¶ 19.) Moreover, Appellants’ Specification discloses that Figures 3 and 4 illustrate different embodiments of network appliances 310 and 410, respectively. (¶¶ 7–8, 31, 45.) Thus, because the Specification discloses that network communications method 200, an algorithm, can be executed on either of network appliances 110, 310, and 410, three separate embodiments, the Specification provides written description support for the functional limitations recited in independent claims 21 and 34. See Ariad Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1349 (Fed. Cir. 2010) (en banc) (“the specification must demonstrate that the applicant has made a generic invention that achieves the claimed result and do so by showing that the applicant has invented species sufficient to support a claim to the functionally-defined genus.â€) Appeal 2017-011609 Application 14/197,019 7 Accordingly, we are persuaded by Appellants’ arguments that Furthermore, the specification and drawings provide numerous examples of algorithms and steps/procedures of which the claimed subject matter represents a specific implementation. . . . Within each step of FIG. 2, numerous examples and alternatives are provided. . . . FIGS. 3 and 4, and associated description disclose how the algorithm of FIG. 2 may be implemented within a network appliance in a variety of different ways, including with respect to the SPDY protocol and other enhanced protocols. . . . FIGS. 3 and 4 represent different algorithms having different steps/procedures that may depend, for example, on the type of non-compliant algorithm that is being translated. (App. Br. 17.) Thus, we do not agree with the Examiner that the Specification fails to provide written description support for the functional limitations recited in independent claim 21. Accordingly, we do not sustain the rejection of independent claim 21 under 35 U.S.C. § 112(a). Claims 24–34 depend from claim 21. Therefore, we do not sustain the rejection of claims 24–34 under 35 U.S.C. § 112(a) for the same reasons discussed with respect to independent claim 21. Independent claim 35 recites limitations similar to those discussed with respect to independent claim 21. Claims 36–40 depend from claim 21. Therefore, we do not sustain the rejection of claims 36–40 under 35 U.S.C. § 112(a) for the same reasons discussed with respect to independent claim 21. § 112(b) Rejections First, we are persuaded by Appellants’ arguments (Reply Br. 3) that the limitation “wide area network,†as recited in independent claim 24, Appeal 2017-011609 Application 14/197,019 8 complies with 35 U.S.C. § 112(b) by particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. With respect to independent claim 24, the Examiner found that “the term ‘wide area network’ is a relative term which renders the claim indefinite.†(Ans. 5 (emphasis omitted).) In particular, the Examiner found that “[t]he term ‘wide area network’ is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.†(Id.) We do not agree. In reference to Figure 1, Appellants’ Specification discloses the following: Network appliance 110 may facilitate network communications between client devices 170 and server devices 160 via respective client-side wide area network 140 and server-side local area network 150. As one example, network appliance 110 may connect thousands of client devices to hundreds of server devices of a server farm. (¶ 10 (emphasis added).) Thus, Appellants’ Specification discloses that communication distances between client devices 170 in wide area network (WAN) 140 are determined relative to communication distances between server devices 160 in local area network (LAN) 150. In other words, one of ordinary skill would understand that the geographical area for devices in a WAN (e.g., client devices 170) are determined relative to the geographical area for devices in a LAN (e.g., server devices 160).1 1 One relevant definition of “WAN†(or “wide area networkâ€) is “[a] geographically widespread network, one that relies on communications capabilities to link the various network segments,†such that “[a] WAN can Appeal 2017-011609 Application 14/197,019 9 Accordingly, we are persuaded by Appellants’ arguments that The claim language itself also establishes a network topology defining the LAN as the network between the network appliance and the server, and the WAN as the network between the client and the network appliance. As one of ordinary skill in the art would appreciate, LANs connect computers in a close physical area and enable higher communication speeds and lower latency, while WANs connect computers across greater distances than LANs and have lower communication speeds and higher latency. (Reply Br. 3.) Thus, we do not agree with the Examiner that the limitation “wide area network†is indefinite. Second, we are persuaded by Appellants’ arguments (Reply Br. 3) that the limitation “non-compliant application level protocol,†as recited in independent claim 24, complies with 35 U.S.C. § 112(b) by particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. With respect to independent claim 24, the Examiner found that “the term ‘non-compliant application level protocol’ is not a well-known term in that art.†(Ans. 6 (emphasis omitted).) In particular, the Examiner found that “[t]he term ‘non-compliant application level protocol’ is a subjective term coined by the appellant to obfuscate the claim language to prevent relevant prior art from being discovered†(id.) and “appellant fails to be one large network, or it can consist of a number of linked LANs (local area networks).†MICROSOFT® COMPUTER DICTIONARY 561 (5th ed. 2002). Likewise, one relevant definition of “LAN†(or “local area networkâ€) is “[a] group of computers and other devices dispersed over a relatively limited area and connected by a communications link that enables any device to interact with any other on the network.†(Id. at 304.) Appeal 2017-011609 Application 14/197,019 10 describe or mention in the specification what constitute or is meant by ‘non- compliant application level protocol’†(id. at 7). We do not agree. Independent claim 24 recites “a non-compliant application level protocol that is non-compliant with RFC 1945/HTTP/1.0 and RFC 2616/HTTP/1.1†(emphasis added). Appellants’ Specification discloses the following: The Hypertext Transfer Protocol (HTTP) is a commonly used application level protocol for communicating on the Internet within the Transmission Control Protocol (TCP) transport layer of the Internet Protocol Suite. Recent advancements in application level protocols within the TCP framework, such as SPDY, HTTP-MPLEX, and other enhanced application level protocols may not be supported by HTTP compliant servers. (¶ 2 (emphasis added).) Thus, according to Appellants’ Specification, examples of more advanced application level protocols, which are not supported by HTTP servers, are SPDY and HTTP-MPLEX. One of ordinary skill in the art would interpret the claim language “a non-compliant application level protocol†as an application level protocol that is not supported by an HTTP compliant server, for example, RFC 1945/HTTP/1.0 and RFC 2616/HTTP/1.1. Accordingly, because Appellants’ Specification provides an explanation of compliant (and non-compliant) application level protocols, those skilled in the art would understand what is claimed when the claim is read in light of the Specification. See Power-One, Inc. v. Artesyn Techs., Inc., 599 F.3d 1343, 1350 (Fed. Cir. 2010). Accordingly, we are persuaded by Appellants’ arguments that “[t]he term ‘non-compliant’ does not introduce vagueness into the claims because the exact manner of non-compliance is recited on the face of the claim.†(Reply Br. 3.) Appeal 2017-011609 Application 14/197,019 11 Thus, we do not agree with the Examiner that the limitation “non- compliant application level protocol†is indefinite. Last, we are persuaded by Appellants’ arguments (App. Br. 20–21) that the limitations “application level protocol specified number of TCP connections†and “programmatically specified number of TCP connections,†as recited in independent claim 24, complies with 35 U.S.C. § 112(b) by particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. With respect to independent claim 24, the Examiner found that “the term ‘programmatically specified number of TCP connections’ is . . . coined by the appellant and it is a subjective term with subjective meaning†and “[t]he term ‘programmatically specified number of TCP connections’ is completely subjective.†(Ans. 12.) We do not agree. Appellants’ Specification discloses the following: In at least some implementations, network appliance 110 may be configured to demultiplex multiple responses for multiple clients from a response stream received from a server device from the programmatically specified number of persistent server-side TCP connections to the application level protocol specified number of client-side TCP connections. Network appliance 110 may be further configured to multiplex multiple responses for an individual client device over the application level protocol specified number of client-side TCP connections. As one example, the SPDY application level protocol may specify only a single client-side TCP connection for receiving responses from network appliance 110. (¶ 12 (emphasis added).) In at least some implementations, the one or more HTTP compliant requests of the HTTP compliant request stream may be sent to the one or more server devices over a programmatically specified number of TCP connections . . . . Appeal 2017-011609 Application 14/197,019 12 Furthermore, in at least some implementations, multiple HTTP compliant requests of multiple client devices may be multiplexed over a given TCP connection with a server device as will be described in greater detail with reference to FIGS. 3 and 4. (¶ 24 (emphasis added).) Accordingly, Appellants’ Specification discloses that the recitation of “application level protocol specified number of TCP connections†is in reference to the client-side TCP connection and provides one example as a single TCP connection for the SPDY application level protocol. (¶ 14.) Similarly, Appellants’ Specification discloses that the recitation of “programmatically specified number of TCP connections†is in reference to the server-side TCP connection. (¶ 24.) Accordingly, because Appellants’ Specification provides an explanation of “application level protocol specified number of TCP connections†and “programmatically specified number of TCP connections,†those skilled in the art would understand what is claimed when the claim is read in light of the Specification. See Power-One, 599 F.3d 1343 at 1350. Accordingly, we are persuaded by Appellants’ arguments that: The phrase “application level protocol specified number†on the client side of the network appliance is used to distinguish from the “programmatically specified number†of TCP connections on the server side of the network appliance. The claims further provide that this application level protocol specified number is less than the programmatically specified number. (App. Br. 20–21.) Thus, we do not agree with the Examiner that the limitations “application level protocol specified number of TCP connections†and “programmatically specified number of TCP connections†are indefinite. Appeal 2017-011609 Application 14/197,019 13 Accordingly, we do not sustain the rejection of independent claim 21 under 35 U.S.C. § 112(b). Claims 24–34 depend from claim 21. Therefore, we do not sustain the rejection of claims 24–34 under 35 U.S.C. § 112(b) for the same reasons discussed with respect to independent claim 21. Independent claim 35 recites limitations similar to those discussed with respect to independent claim 21. Claims 36–40 depend from claim 21. Therefore, we do not sustain the rejection of claims 36–40 under 35 U.S.C. § 112(b) for the same reasons discussed with respect to independent claim 21. § 103 Rejection We are persuaded by Appellants’ arguments (App. Br. 26; see also Reply Br. 3–4) that the combination of Zilbershtein, Watson, and Christenson would not have rendered obvious independent claim 21, which includes the limitation “receive from a client device via a client-side wide area network a non-compliant request stream.†The Examiner found that the bidirectional gating of Zilbershtein between low parallelity devices in a network (e.g., client LANs 170B and 170C) and a remote server with a higher parallelity capability (e.g., WAN server 110), corresponds to the limitations receive from a client device via a client-side wide area network, a non-compliant request stream . . . . . . . translate the multiple non-compliant requests of the non- compliant request stream from the non-compliant application level protocol into multiple compliant requests of a compliant request stream . . . . . . forward the compliant request stream including the multiple compliant requests to one or more server devices via the Appeal 2017-011609 Application 14/197,019 14 persistent server-side TCP connections on a server-side local area network. (Final Act. 13–14.) In particular, the Examiner found that “wide area network (WAN) and local area network (LAN) [are] merely . . . networks providing connections between devices†and “the use of WAN and LAN in a particular orientation by the appellant is completely subjective and merely a design choice without any impact on the functionality in view of the specification.†(Ans. 23.) We do not agree with the Examiner’s findings. Zilbershtein relates to “translation of data between protocols with different degrees of parallelity.†(¶ 2.) Zilbershtein explains that “[i]n an exemplary embodiment of the invention, there is provided a method for bidirectional gating between low parallelity devices in a network and a remote server with a higher parallelity capability.†(¶ 25.) In particular, Figure 1 of Zilbershtein “illustrates communication between WAN server 110 and client LANs 170B and 170C.†(¶ 93.) Moreover, Zilbershtein explains that “low parallelity protocols are inefficient over WAN links and are prone to timeouts and/or repeat requests†and “[a]s a result, use of low parallelity protocols over a WAN link is undesirable.†(¶ 95.) Although the Examiner cited to the low parallelity devices of Zilbershtein in a network, for example, client LANs 170B and 170C, the Examiner has provided insufficient evidence to support a finding that Zilbershtein teaches the limitation “receive from a client device via a client- side wide area network a non-compliant request stream†(emphasis added). In particular, because Zilbershtein explains that that “low parallelity protocols are inefficient over WAN links†due to timeouts and repeat requests (¶ 95), the Examiner has not demonstrated that the substitution of Appeal 2017-011609 Application 14/197,019 15 WAN link for the low parallelity devices of Zilbershtein is “design choice without any impact on the functionality†(Ans. 23). On this record, the Examiner has not shown that Zilbershtein teaches the limitation “receive from a client device via a client-side wide area network a non-compliant request stream.†In addition, Watson and Christenson do not cure the above noted deficiencies of Zilbershtein. Thus, we are persuaded by Appellants’ arguments, as follows: Zilbershtein discourages the use of low parallelity protocols over a WAN link by disclosing that the “use of low parallelity protocols over a WAN link is undesirableâ€. Yet, this is the approach described by claim 21. The claimed subject matter, when considered in its entirety provides that the lesser number of TCP connections are used on the WAN and the greater TCP connections are used on the LAN. (App. Br. 29 (emphasis omitted); see also Reply Br. 3–4.) Accordingly, we do not sustain the rejection of independent claim 21 under 35 U.S.C. § 103. Claims 24–34 depend from independent claim 21. We do not sustain the rejection of claims 24–34 under 35 U.S.C. § 103 for the same reasons discussed with respect to independent claim 21. Independent claim 35 recites limitations similar to those discussed with respect to independent claim 21. We do not sustain the rejection of claim 35, as well as dependent claims 36–40, for the same reasons discussed with respect to claim 21. DECISION The Examiner’s decision rejecting claims 21 and 24–40 under 35 U.S.C. § 112(a) is reversed. Appeal 2017-011609 Application 14/197,019 16 The Examiner’s decision rejecting claims 21 and 24–40 under 35 U.S.C. § 112(b) is reversed. The Examiner’s decision rejecting claims 21 and 24–40 under 35 U.S.C. § 103 is reversed. REVERSED Copy with citationCopy as parenthetical citation