• HQ H277148
• Nov 18, 2016

• Type : 19 U.S.C. § 1337; Unfair Competition Bert C. Reiser • HTSUS :
•  Revoked by:   H284032     Related:   H259071; H067500; H121519; H025822; H242026; H226615   

OT:RR:BSTC:IPR H277148 DAX/AEB

Latham & Watkins LLP
555 Eleventh Street, N.W., Suite 1000
Washington, D.C. 20004-1304


 RE: Ruling Request; U.S. International Trade Commission; Limited Exclusion Order; Investigation No. 337-TA-944; Certain Network Devices, Related Software and Components Thereof

Dear Mr. Reiser:

This ruling letter is issued in response to your submission, dated June 27, 2016, that included Exhibits A – C (Duda Decl., Instructions for Testing, and Arista User Manual) (Arista Ruling Request), as well as your supplemental letters of July 22, 2016 that included Exhibit D (Second Duda Decl.) (Arista Supplement I); August 12, 2016 that included Exhibit E (Third Duda Decl.) (Arista Supplement II); September 19, 2016 that included Exhibit F (Fourth Duda Decl.) (Arista Supplement III); and September 26, 2016 that included Exhibit G (Fifth Duda Decl.) (Arista Supplement IV); on behalf of Arista Networks, Inc. (“Arista”), in which you requested an administrative ruling, pursuant to 19 C.F.R. § 177, whether certain Arista network devices (“switches”) running the re- designed version 4.16.6M of its Extensible Operating System (“EOS Redesign”) are subject to the limited exclusion order (“LEO”) issued by the U.S. International Trade Commission (“Commission” or “ITC”) that resulted from the above-referenced investigation.

As a preliminary matter, it has long been the position of U.S. Customs and Border Protection (“Customs” or “CBP”) and the Treasury Department, to further the sound administration of the Customs and related laws, that “persons engaging in any transaction affected by those laws fully understand the consequences of that transaction prior to its consummation” and, for this reason, CBP “will give full and careful consideration to written requests from importers and other interested parties for rulings or information setting forth, with respect to a specifically described transaction, a definitive interpretation of applicable law, or other appropriate information.” 19 C.F.R. § 177.1(a); see also Proposed Revision Relating to Issuance of Administrative Rulings by Headquarters Office, Notice of Proposed Rulemaking, 40 Fed. Reg. 2437 (January 13, 1975) and Issuance of Administrative Rulings by Headquarters Office, Final Rule, 40 Fed. Reg. 31929 (July 30, 1975) (promulgating this provision of 19 C.F.R. § 177 as it appears, unchanged, in the current edition of the Customs regulations).

“Generally, a ruling may be requested under the provisions of this part only with respect to prospective transactions—that is, transactions which are not already pending before a Customs Service office by reason of arrival, entry, or otherwise.” Id. Additionally, “[n]o ruling letter will be issued with regard to transactions or questions which are essentially hypothetical in nature or in any instance in which it appears contrary to the sound administration of the Customs and related laws to do so.” 19 C.F.R. § 177.7(a). Moreover, “[n]o ruling letter will be issued with respect to any issue which is pending before the United States Court of International Trade, the United States Court of Appeals for the Federal Circuit, or any court of appeal therefrom.” 19 C.F.R. § 177.7(b) (emphasis added).

Notably, on September 23, 2016, Arista filed its opening brief with the U.S. Court of Appeals for the Federal Circuit (“Federal Circuit”) under 19 U.S.C. § 1337(c) and 28 U.S.C. § 1295(a)(6), appealing, inter alia, the Commission’s Final Determination (and related Commission Opinion) of June 23, 2016, which resulted in the limited exclusion order at issue directing the exclusion from entry of Arista switches covered by certain patent claims. See Arista Networks, Inc v. U.S. International Trade Commission, Court No. 16-2563. Importantly for purposes of this ruling letter, the Federal Circuit appeal involves the Commission’s Final Determination, resulting from the investigation under section 337, that a violation of this section exists based on the legacy products accused and found to infringe the relevant patent claims included in the limited exclusion order. The Commission’s Final Determination whether there is a violation of section 337 by those legacy products involves an issue that is separate and distinct from the administration of the exclusion order by Customs1 and its authority, under 19 C.F.R. §§ 177 or 174, to determine whether an unadjudicated article may be entered into the United States in light of an exclusion order (particularly where the article in question is a new or modified product or one that allegedly is not subject to exclusion from entry for some other reason or development, such as a license or patent exhaustion defense).

CBP has repeatedly adhered to the position that appealing a Commission Final Determination to the Federal Circuit does not foreclose CBP from ruling on the admissibility of products that were not adjudicated during the investigation at the Commission. See CBP HQ Ruling H259071 at 8 (dated December 10, 2014) (“CBP has issued ruling letters during the pendency of appeals at the Federal Circuit that


 1 Notwithstanding the above, a Commission Final Determination, of course, is binding as to those legacy products found to infringe and whose compulsory exclusion, if they attempted entry, would not be a protestable decision under 19 U.S.C. § 1514(a)(4) and, as such, would not require or receive an administrative ruling or protest decision from Customs. involve a final determination of the Commission because, although the general matter was on appeal, the particular issue before the Federal Circuit [involving the legacy products found to infringe] was not the subject of the administrative ruling.”) (emphasis added); see also CBP HQ Ruling H067500 (dated August 5, 2009).

Since, as noted above, Arista’s appeal of the Commission’s Final Determination does not involve switches running the EOS Redesign, the subject of this ruling request is not an issue pending before the Federal Circuit and, consequently, CBP is not precluded under 19 C.F.R. § 177.7(b) from ruling on the admissibility of the redesigned switches, just as it would not be precluded from issuing a protest decision under 19 C.F.R. § 174 based on an application for further review challenging an exclusion from entry.

As for another preliminary matter, Arista has requested confidential treatment in connection with this ruling request for certain information from its submissions, claiming that the disclosure of such information would likely cause substantial harm to its competitive position and, on this basis, seeks to have the information in question redacted from any ruling that is published in accordance with 19 U.S.C. § 1625(a). Disclosure of information related to administrative rulings under 19 C.F.R. § 177 is governed by 31 C.F.R. § 1, 19 C.F.R. § 103, and 19 C.F.R. § 177.8(a)(3). See 19 C.F.R. § 177.10(a). Moreover, the determination whether to include or redact information within a published ruling is guided by various federal laws—and the relevant standards for their application—that involve confidentiality and disclosure, to include the Freedom of Information Act (“FOIA”) (5 U.S.C. § 552), the Trade Secrets Act (18 U.S.C. § 1905), and the Privacy Act of 1974 (5 U.S.C. § 552a). See CBP HQ Ruling H121519 at 1 (dated February 8, 2011).

Congress enacted FOIA to overhaul the earlier public-disclosure section of the Administrative Procedure Act that gradually became more “a withholding statute than a disclosure statute.” Milner v. Dep't of the Navy, 562 U.S. 562, 565 (quoting EPA v. Mink, 410 U.S. 73, 79 (1973). Accordingly, there is a strong presumption in favor of disclosure, which is consistent with the purpose as well as the plain language of the Act. United States Dep't of State v. Ray, 502 U.S. 164, 173 (1991). Thus, FOIA mandates that an agency disclose certain information unless it falls within one of nine exemptions. Milner, at 565. These exemptions are “explicitly made exclusive,” EPA, at 79, and must be “narrowly construed,” FBI v. Abramson, 456 U.S. 615, 630 (1982).

Exemption 4 of FOIA, which is especially relevant here, provides that FOIA does not apply to matters that are “trade secrets and commercial or financial information obtained from a person and privileged or confidential.” 5 U.S.C. § 552 (b)(4); see also Chrysler Corp. v. Brown, 441 U.S. 281, 291 (1979). Furthermore, it is worth noting that, as a general matter, the proscriptions of the Trade Secrets Act are “at least co-extensive with Exemption 4 of FOIA . . . [such that], unless another statute or a regulation authorizes disclosure of the information, the Trade Secrets Act requires each agency to withhold any information it may withhold under Exemption 4 of the FOIA.” Venetian Casino Resort, LLC v. EEOC, 530 F.3d 925, 932 (D.C. Cir. 2008) (quoting Canadian Comm. Corp. v. Air Force, 514 F.3d 37, 39 (D.C. Cir. 2008) (emphasis added); see also Dow Chem. Co. v. United States, 476 U.S. 227, 234, n. 2 (1986) (“Dow's fear that EPA might disclose trade secrets revealed in these photographs appears adequately addressed by federal law prohibiting such disclosure generally under the Trade Secrets Act, 18 U.S.C. § 1905, and the Freedom of Information Act, 5 U.S.C. § 552(b)(4).”).

That said, “Congress did not design the Freedom of Information Act exemptions to be mandatory bars to disclosure.” Chrysler Corp., 441 U.S. at 293, 294 (“We therefore conclude that Congress did not limit an agency's discretion to disclose information when it enacted the FOIA.”) (emphasis added); see also GTE Sylvania v. Consumers Union of United States, 445 U.S. 375, 378, n. 2 (1980) (“The theory of the so-called ‘reverse Freedom of Information Act’ suit, that the exemptions to the Act were mandatory bars to disclosure and that therefore submitters of information could sue an agency under the Act in order to enjoin release of material, was squarely rejected in Chrysler Corp.”).

The test, for administrative rulings under 19 C.F.R § 177, to determine whether certain information is confidential (and therefore properly redacted from any published ruling) is identical to the federal government-wide standard for disclosure under FOIA Exemption 4 as it relates to the likelihood of substantial harm to the competitive position of the person submitting the information and requesting that it be withheld from publication. As with FOIA, the basic objective of administrative rulings under 19 C.F.R. § 177 favors disclosure to provide notice to interested persons of the reasons for the agency’s position and its decision-making process. See Chrysler Corp., 441 U.S. at 290, n. 10 (“We observed in Department of Air Force v. Rose that ‘disclosure, not secrecy, is the dominant objective of the Act.’ The legislative history is replete with references to Congress' desire to loosen the agency's grip on the data underlying governmental decisionmaking.”) (internal citation omitted). Notably, under 19 C.F.R. § 177.8(a)(3) referenced above, there is a general presumption that “[n]o part of the ruling letter, including names, addresses, or information relating to the business transactions of private parties, shall be deemed to constitute privileged or confidential commercial or financial information or trade secrets exempt from disclosure pursuant to the Freedom of Information Act, as amended (5 U.S.C. 552), unless, as provided in §?177.2(b)(7), the information claimed to be exempt from disclosure is clearly identified and the reasons for the exemption are set forth.”

In turn, 19 C.F.R. § 177.2(b)(7) provides that “[i]nformation which is claimed to constitute trade secrets or privileged or confidential commercial or financial information regarding the business transactions of private parties the disclosure of which would cause substantial harm to the competitive position of the person making the request (or of another interested party), must be identified clearly and the reasons such information should not be disclosed, including, where applicable, the reasons the disclosure of the information would prejudice the competitive position of the person making the request (or of another interested party) must be set forth.”

Significantly, § 177.2(b)(7) was added to this section through rulemaking (T.D. 75-186, 40 Fed. Reg. 31929, July 30, 1975) that promulgated a final rule based on a previous notice of proposed rulemaking (40 Fed. Reg. 2437, January 13, 1975) where the text as proposed did not contain (b)(7) or any other provision addressing the treatment of putative confidential business information. The “substantial harm to a competitive position” standard adopted in § 177.2(b)(7) to handle confidentiality issues is identical to that standard for FOIA Exemption (b)(4) contemporaneously established by the U.S. Court of Appeals for the District of Columbia Circuit (“D.C. Circuit”) in National Parks & Conservation Asso. v. Morton, 498 F.2d 765 (D.C. Cir. 1974). See N.H. Right to Life v. HHS, 136 S. Ct. 383; 193 L. Ed. 2d 412; 2015 U.S. LEXIS 7169 (2015) (Thomas, J., dissenting from denial of the petition for writ of certiorari). In 1974, a year before the promulgation of the Customs final rule, the D.C. Circuit construed the word “confidential” in Exemption 4 and determined that commercial information is “confidential” if disclosure would “cause substantial harm to the competitive position of the person from whom the information was obtained.” National Parks, at 770; see also N.H. Right to Life, 136 S. Ct. at 384. The D.C. Circuit later elaborated that, when applying this test, there was no need to show actual competitive harm and that actual competition and the likelihood of substantial competitive injury sufficed. See Public Citizen Health Research Group v. FDA, 704 F.2d 1280, 1291 (D.C. Cir. 1983); see also N.H. Right to Life, at id. Accordingly, to overcome the strong presumption in favor of disclosure, ruling requesters seeking confidential treatment must prove (1) they actually face competition, and that (2) substantial competitive injury would likely result from disclosure. See Gov't Accountability Project v. FDA, 2016 U.S. Dist. LEXIS 114927, at *15 (D.C. Cir. 2016). Conclusory and generalized allegations of substantial competitive harm are unacceptable and will not support a ruling requester’s efforts to withhold certain information from publication. See Public Citizen Health Research Group, at id.

There is no dispute that Arista faces actual competition and therefore the relevant analysis will focus on the second prong above. See Certain Network Devices, Related Software and Components Thereof, Inv. No. 337-TA-944, Commission Opinion (“Comm’ Op.”) at 58 (June 2016); see also Complainant Cisco Systems, Inc.’s Written Submission in Response to the Commission’s Determination to Review In-Part a Final Initial Determination of a Violation of Section 337 (Brief on Review/Remedy) at 92, Doc ID 580457 (dated May 5, 2016) (“Even assuming that Arista’s products may be used in those spaces [scientific or medical], alternative networking technologies exist, including those supplied by Cisco and others in the industry. See, e.g., Vander Veen Tr. 1220:15–19 (recognizing Arista and Cisco are competitors); CX-10C (Leonard WS) at Q/A 81 (listing other competitors)….Other suppliers can also meet any minor increase in consumer demand caused by the Commission’s remedies. Competitors range from hardware manufacturers to software-defined networking providers. Arista identifies at least seven other companies as its direct competitors: Cisco, Brocade Communications Systems, Dell, Hewlett-Packard, Juniper Networks, IBM, and VMWare.”).

As suggested above, the relevant Customs regulations not only mirror the general presumption in favor of disclosure but also place the burden on the person requesting confidentiality to demonstrate that such information qualifies. See generally FCC v. Schreiber, 381 U.S. 279 (1965) (upholding a rule requiring public disclosure except where the proponents of a request for confidential treatment have established their burden to justify that such information should not be disclosed). Moreover, the provisions of the Customs regulations that place the burden on the ruling requester to establish, during the administrative proceeding, that the information at issue constitutes confidential business information is consistent with the burden the government must satisfy in an action brought against it under FOIA challenging the position an agency has taken not to disclose information pursuant to one or more of the exemptions. See 5 U.S.C. § 552(a)(4)(B); see also United States Department of Justice v. Landano, 508 165, 171 (1993) (“The Government bears the burden of establishing that the exemption applies.”).

This line of inquiry is further illuminated by the “general right to inspect and copy public records and documents” that courts have historically recognized, including in patent cases involving highly sensitive information. Apple Inc. v. Samsung Elecs. Co., 727 F.3d 1214, 1221 (Fed. Cir. 2013) (quoting Nixo n v. W a rne r Comm c’ns, In c. , 435 U.S. 589 (1978)). The nature of this right, rooted in the common law, is not conditioned on a proprietary interest in the information, see Nixon, at 597, although certainly there are instances where an interest in the information may rise to or approach such a level. Instead, the only interest necessary to compel access to such information is found in the “citizen's desire to keep a watchful eye on the workings of public agencies.” Nixon, at 597-98. This consideration is particularly warranted in regard to the ex parte administrative rulings under 19 C.F.R. § 177 where a person who believes a ruling is incorrect (legally or factually), may seek to have it modified or revoked under 19 C.F.R. § 177.12.

Therefore, a determination whether to grant a request for confidential treatment must balance the likelihood of substantial harm to a competitive position against the need to provide the greatest amount of transparency possible to the agency’s decision-making process. In light of the above, a request for confidential treatment of information submitted in connection with a ruling requested under 19 C.F.R. § 177 faces a strong presumption in favor of disclosure and the person seeking this treatment must overcome that presumption with a request that is narrowly tailored and supported by evidence establishing a likelihood of substantial harm to a competitive position that outweighs the general history and public policy—embedded in FOIA, the common law, and the relevant Customs regulations—favoring transparency and disclosure. To that end, any request for confidential treatment must provide a particularized showing of the specific harm that will result if certain information is disclosed. Broad, unsubstantiated allegations of harm without specific examples articulating reasons for the harm will not suffice.

Notwithstanding the above, it is well recognized by the Federal Circuit and among various federal district courts that, in civil actions arising under the patent laws, “source code requires additional protections to prevent improper disclosure because it is often a company’s most sensitive and most valuable property . . . (noting that source code might represent a company's ‘most sensitive and confidential property’ and that, in ‘U.S. litigation, extreme measures are ordered to protect [its] confidentiality’). As a result, district courts regularly provide for additional restrictions on discovery to account for the unique characteristics of source code.” Drone Techs., Inc. v. Parrot S.A., 2016 U.S. App. LEXIS 17643 at *35, n. 13 (Fed. Cir. 2016) (internal citations omitted).

Recognizing the significance of source code that is understood in district court actions and Commission investigations under section 337, any source code that forms a part of the administrative record for an ex parte ruling request under 19 C.F.R. § 177 will not be subject to disclosure without permission of submitter. Nevertheless, as at least one district court has acknowledged, “[s]oftware [patent] cases present unique challenges for the parties and the courts because, prior to discovery, plaintiffs usually only have access to the manifestation of the defendants' allegedly infringing source code and not the code itself. From this manifestation, plaintiffs must somehow divine whether the defendants' code infringes. Although defendants vigorously and rightly guard their source code, until plaintiffs have access to it, plaintiffs are typically unable to give highly specified infringement contentions.” American Video Graphics, L.P. v. Electronic Arts, Inc. 359 F. Supp. 2d 558, 560 (E.D. Tex. 2005). Therefore, as noted above, requests for confidential treatment in the context of section 337 exclusion order-based rulings under 19 C.F.R. § 177, especially those involving software running on a particular device, must be narrowly tailored, fully supported by evidence showing a likelihood of substantial harm to a competitive position, and still permit a description of the device’s operation.

Based on the framework above, the information for which Arista has established a likelihood of substantial harm to its competitive position if disclosed (or consists of information that was redacted from the public version of the agency record at the Commission) has been bracketed for redaction from the published ruling but otherwise has been described or identified to the greatest extent allowed throughout this ruling (including, whenever possible, with citations referencing the confidential agency record at the Commission from Inv. No. 337-TA-944). Dark blue brackets (e.g., [ ]) signify information that was redacted by the Commission under 19 C.F.R. § 201.6, while red brackets (e.g., [ ]) signify information that has been redacted from the submissions to CBP.

FACTS:

The Commission instituted Investigation No. 337-TA-944 on January 27, 2015, based on a complaint filed on behalf of Cisco Systems, Inc. (“Cisco”). See 80 Fed. Reg. 4314- 15 (Jan. 27, 2015). Cisco alleged violations of section 337 of the Tariff Act of 1930 (19 § 1337) by reason of infringement of various claims of U.S. Patent No. 7,162,537 ('537 patent); U.S. Patent No. 8,356,296 ('296 patent); U.S. Patent No. 7,290,164 ('164 patent); U.S. Patent No. 7,340,597 ('597 patent); U.S. Patent No. 6,741,592 ('592 patent); and U.S. Patent No. 7,200,145 ('145 patent).

On February 2, 2016, the presiding Administrative Law Judge (“ALJ”) issued his final initial determination (“ALJ ID”), finding that the '537, '592 and '145 patents were infringed by the accused switches. See ALJ ID at 292. On April 11, 2016, the Commission determined to review the final initial determination in-part. See 81 Fed. Reg. 42375-76 (June 29, 2016). On June 23, 2016, the ITC affirmed the ALJ ID in-part and issued the LEO, directing that “[n]etwork devices, related software and components thereof that infringe one or more of 1, 2, 8-11, and 17-19 of the '537 patent; claims 6, 7, 20, and 21 of the '592 patent; and claims 5, 7, 45, and 46 of the '145 patent that are manufactured abroad by or on behalf of, or imported by or on behalf of, Respondent, or its affiliated companies, parents, subsidiaries, licensees, or other related business entities, or its successors or assigns, are excluded from entry for consumption into the United States, entry for consumption from a foreign trade zone, or withdrawal from a warehouse for consumption, for the remaining terms of the patents, except under license of the patent owner or as provided by law, and except for service, repair, or replacement articles imported for use in servicing, repairing, or replacing network devices under warranty or service contracts, for identical articles, that existed as of the date of this Order.”

Independent claims 1, 10, and 19 of the '537 patent read as follows:

A method for reducing computational overhead in a centralized database system by externally managing router data in conjunction with a centralized database subsystem, said database subsystem operatively coupled for communication with a plurality of router subsystems one of which is a first managing subsystem, comprising:

transmitting a management registration request by said first managing subsystem to said database subsystem, said registration request indicating router configuration data for which said first managing subsystem is requesting to provide external management services, said router configuration data managed by said database system and derived from configuration commands supplied by a user and executed by a router configuration subsystem before being stored in said database;

receiving said management registration request by said database subsystem; and

registering said first managing subsystem for external management by said database subsystem.

A program storage device readable by a machine, tangibly embodying a program of instructions executable by the machine to perform a method for reducing computational overhead in a centralized database system by externally managing router data in conjunction with a centralized database subsystem, said database subsystem operatively coupled for communication with a plurality of router subsystems one of which is a first managing subsystem, said method comprising:

transmitting a management registration request by said first managing subsystem to said database subsystem, said registration request indicating router configuration data for which said first managing subsystem is requesting to provide external management services, said router configuration data managed by said database system and derived from configuration commands supplied by a user and executed by a router configuration subsystem before being stored in said database;

receiving said management registration request by said database subsystem; and

registering said first managing subsystem for external management by said managing subsystem.  In a router device having a processor and memory, a router operating system executing within said memory comprising:

a database subsystem;

a plurality of client subsystems, each operatively coupled for communication to said database subsystem, one of said client subsystems configured as a managing subsystem to externally manage router data upon issuing a management request to said database subsystem; and

a database operatively coupled to said database subsystem, said database configured to store router configuration data and delegate management of router configuration data to a management subsystem that requests to manage router configuration data, said router configuration data managed by said database system and derived from configuration commands supplied by a user and executed by a router configuration subsystem before being stored in said database.

Independent claims 6, 20, and 21 of the '592 patent read as follows:

6. A switch, comprising:

a promiscuous port for receiving incoming packets from an external network, and for transmitting outgoing packets to said external network; and

a plurality of isolated ports, a selected isolated port of said plurality of isolated ports connected to a selected private network, said selected isolated port receiving packets from said selected private network and transmitting packets onto said selected private network, said selected isolated port exchanging packets with said promiscuous port through a path inside said switch, and said isolated port not exchanging packets with another isolated port.

A switch implementing virtual local area networks (VLANs) in a computer network, comprising:

a first isolated port assigned to a user to receive said user's packet from an external circuit connected to said first isolated port; and

a selected promiscuous port to receive said packet through an isolated VLAN, said packet to be transferred to an external circuit connected to said promiscuous port, said isolated VLAN configured as a one way connection from all isolated ports to all promiscuous ports and also configured to prevent any other isolated port from receiving said user's packets from said isolated VLAN, said all promiscuous ports also connected via a one way primary VLAN to said all isolated ports.

A switch implementing virtual local area networks (VLANs) in a computer network, comprising:

a plurality of community ports, including a first community port assigned to a user to receive said user's packet from an external circuit connected to said first community port; and

a plurality of promiscuous ports connected to external circuits to receive said packet through a community VLAN, all other community ports connected to said community VLAN also receiving said packet, but not any other ports of said switch, said community VLAN configured as a one way connection from all community ports in said community VLAN to all promiscuous ports, said all promiscuous ports also connected via a one way primary VLAN to all community ports.

Independent claims 5, 7, 45, and 46 of the '145 patent read as follows:

5. A router, comprising:

a port connected to a shared network; a plurality of user ports; a first VLAN from the port connected to the shared network to the plurality of user ports, the first VLAN to receive packets from the shared network and transferring them to a designated user port, the first VLAN to reject packets from the user ports;

a second VLAN from the plurality of user ports, the second VLAN to receive packets from the user ports and transferring them to the port connected to the shared network, the second VLAN to prevent transfer of packets from one of the user ports to other user ports, and the second VLAN also to reject packets from the shared network, in order to separate packet traffic of different users.

7. A router, comprising:

one or more promiscuous ports; one or more isolated ports; one or more community ports;

a primary VLAN, the primary VLAN to receive packets from outside of the router through the one or more promiscuous ports and to transfer the packets to a selected one of the one or more isolated ports and to transfer the packets to the one or more community ports, the primary VLAN to reject packets from the one or more isolated ports and to reject packets from the one or more community ports;

an isolated VLAN, the isolated VLAN to receive packets from outside of the router through an isolated port of the one or more isolated ports and to transfer the packets to the one or more promiscuous ports, the isolated VLAN to prevent transfer of the packets from the isolated port to another isolated port of the one or more isolated ports, and the isolated VLAN to prevent transfer of the packets from the isolated port to the one or more community ports, and the isolated VLAN to reject packets from the one or more promiscuous ports; and

a community VLAN, the community VLAN to receive packets from outside of the router at a community port of the one or more community ports and to transfer the packets to the one or more promiscuous ports and to transfer the packets to any other community ports, the community VLAN to prevent transfer of packets to the one or more isolated ports, the community VLAN to reject packets from the one or more promiscuous ports. A computer readable medium containing executable program instructions for operating a router, the executable program instructions comprising program instructions configured to:

establish a first VLAN from a port connected to a shared network to a plurality of user ports, the first VLAN to receive packets from the shared network and to transfer them to one or more of the user ports, the first VLAN to reject any packets received from the user ports;

establish a second VLAN from the plurality of user ports, the second VLAN to receive packets from the user ports and to transfer them to the port connected to the shared network, the second VLAN to prevent transfer of packets from one of the user ports to other user ports, and the second VLAN also to reject packets from the shared network, to thereby separate packet traffic of different users.

A computer readable medium containing executable program instructions for operating a router, the executable program instructions comprising program instructions configured to:

establish a primary VLAN, the primary VLAN to receive packets from outside of the router through the one or more promiscuous ports and to transfer the packets to one or more community ports, the primary VLAN to reject packets received from the one or more community ports; and

establish a community VLAN, the community VLAN to receive packets from outside the router on a community port of the one or more community ports and to transfer the packets to the one or more promiscuous ports and to transfer the packets to any other community ports of the one or more community ports, the community VLAN rejecting packets received from the one or more promiscuous ports.

T he ‘5 37 Pa ten t

The subject matter of the `537 patent, as indicated in the abstract, pertains to a method and system in a router device for externally managing router configuration data in conjunction with a centralized database subsystem, wherein the centralized database provides external management registration and unregistration for various managing router subsystems associated with that database system.


 Figure 2 above shows a diagram of an internetwork operating system in accordance with the ‘537 patent. In this figure, examples of subsystem applications appear in the various blocks, with the centralized database subsystem appearing as “sysDB”2 in block 26 and the centralized database as the “sysDB TREE” in block 42. During the investigation at the ITC, the ALJ ID referred to the centralized database of the accused products as “Sysdb” in addition to identifying sysDB in the ‘537 patent as both a “centralized database” and a “database subsystem” while the Commission Opinion interpreting both Sysdb and sysDB as referencing the “same thing,” namely a centralized database. See ALJ ID at 6, 9, 14; Comm’ Op. at 8, FN 10. While the ‘537 patent claims refer to “database” and “database subsystem” as separate terms in the claim limitations, the relationship between the two can be expressed the way in which both occupy the same structure as shown in block 26 of Figure 4, as depicted below.




The invention’s external management provides modularity and independence of the various subsystems of the router device. See `537 patent at Col. 4. Router devices, as a general matter, are responsible for carrying information packets between a network of coupled devices. See `537 patent at Col. 1, ll. 19-22. To control this task, a user can employ a configuration subsystem to configure the routing device’s operations. Id. at ll, 22-25. To perform that configuration, the configuration subsystem determines the affected client subsystem based on the information in the user’s configuration command. Id. at ll, 30-35. In the prior art, however, the client subsystems often had multiple dependencies between each other requiring client subsystems to consistently access each other’s information before having the necessary data to propagate a user’s input task with responsibilities shared among several subsystems. Id. at ll, 37 – 47. Compounding this issue was the difficulty encountered when either a central database retained all the needed information or when all the data was kept outside a central database, leading to heavier burdens on the central database in the former and non- modular external components in the latter. Id. at Col. 2 ll, 58 – 64, Col. 3 ll, 7 – 12. As such, the ‘537 patent claimed a method and system for external data management by client subsystems of router configuration data in a centralized database system. Specifically, subsystems can send a registration request to sysDB to externally manage


 2 CBP will use “sysDB” when referring to the ‘537 patent and “Sysdb” when referring to a feature of the Arista switches. that configuration data. Id. at Col. 5, ll. 18-25. In doing so, the request indicates what router configuration data is requested from what part (or “tuple”) of the sysDB tree, if the externally managed data is to be stored in the sysDB and, if so, when the data in the sysDB would expire, and the address where sysDB can get the externally managed data. Id. at ll. 18 – 32. In response to the request, sysDB provides whatever non- expired data exists in its cache to the address that the requesting subsystem specified and sets up the tuple to be externally managed. Id. at ll. 32 – 40. This exchange of information is illustrated below in Figure 5 and occurs through interaction between the sysDB’s external managing unit and the requesting subsystem’s local managing unit, illustrated above in Figure 4. Id. at ll. 8 – 11.




Claims 1, 10, and 19 of the '537 patent capture the above with the following terms:

A method for reducing computational overhead in a centralized database system by externally managing router data in conjunction with a centralized database subsystem, said database subsystem operatively coupled for communication with a plurality of router subsystems one of which is a first managing subsystem, comprising:

transmitting a management registration request by said first managing subsystem to said database subsystem, said registration request indicating router configuration data for which said first managing subsystem is requesting to provide external management services, said router configuration data managed by said database system and derived from configuration commands supplied by a user and executed by a router configuration subsystem before being stored in said database;

receiving said management registration request by said database subsystem; and

registering said first managing subsystem for external management by said database subsystem.  A program storage device readable by a machine, tangibly embodying a program of instructions executable by the machine to perform a method for reducing computational overhead in a centralized database system by externally managing router data in conjunction with a centralized database subsystem, said database subsystem operatively coupled for communication with a plurality of router subsystems one of which is a first managing subsystem, said method comprising:

transmitting a management registration request by said first managing subsystem to said database subsystem, said registration request indicating router configuration data for which said first managing subsystem is requesting to provide external management services, said router configuration data managed by said database system and derived from configuration commands supplied by a user and executed by a router configuration subsystem before being stored in said database;

receiving said management registration request by said database subsystem; and

registering said first managing subsystem for external management by said managing subsystem.

In a router device having a processor and memory, a router operating system executing within said memory comprising:

a database subsystem;

a plurality of client subsystems, each operatively coupled for communication to said database subsystem, one of said client subsystems configured as a managing subsystem to externally manage router data upon issuing a management request to said database subsystem; and

a database operatively coupled to said database subsystem, said database configured to store router configuration data and delegate management of router configuration data to a management subsystem that requests to manage router configuration data, said router configuration data managed by said database system and derived from configuration commands supplied by a user and executed by a router configuration subsystem before being stored in said database.

ALJ Claim Constructions For T h e ‘5 37 Patent

Claims 1, 10, and 19 have many claim limitations in common and differ only in the way that the invention has been claimed (namely, and respectively, a method claim, machine-readable instructions, and an apparatus claim). See ALJ ID at 65. As such, the ALJ’s claim construction of disputed claim terms grouped the analogous claim limitations, underlined above, of each claim and applied the same construction to each grouping of analogous claim limitations.

First, the ALJ construed the analogous claim limitations, "externally managing router data" (claims 1 and 10)/"externally manage router data" (claim 19)/"external management" (claims 1and10)/"management of” (claim 19). In deciding that the plain and ordinary meaning of these claim terms should apply, the ALJ determined that the rest of the claim language illuminates what is needed for external management including what data is managed, where the data is, and how a subsystem becomes a “managing subsystem.” See ALJ ID at 56. For example, the ALJ noted that claim 1 “teaches that ‘external management’ involves a ‘first managing subsystem’ that ‘indicat[es] router configuration data’ that it will manage outside the centralized database system by ‘transmitting a management registration request.’” Id.

Second, the Initial Determination examined "management registration request" (claims 1 and 10)/"management request” (claim 19). The ALJ here construed both of these terms to mean “a request to register to provide external management services.” Id. at 57. In articulating how this request proceeds, the ALJ cited to the specification noting that a “managing subsystem” transmits a “management registration request” to “register to externally manage router configuration data.” See `537 patent at Col. 5, ll. 18 – 22; Col. 10, ll. 45 – 47 (“At box 100, a managing subsystem 48 (via local managing unit 52) issues a management registration request to the sysDB 26 for external management services.”).

The ALJ next construed the term “router configuration data” in claims 1, 2, 10, 11, and 19, as a limitation to be understood by a person having ordinary skill in the art in light of the specification and claims. See ALJ ID at 58. In other words, as the claim language teaches “router configuration data” as data “derived from configuration commands supplied by a user and executed by a router configuration subsystem before being stored in said database," that language would be sufficient for a person having ordinary skill in the art to understand the meaning of the term. Id.; ‘537 at Col. 18, ll. 35 – 39. The ALJ also noted that the specification indicated that router configuration data could include of any type of “router data” known in the art. Id. at 59; ‘537 at Col. 3, ll. 64 – Col. 4, l. 11.

Since the invention involves numerous components which could all function as some kind of database – database system, database subsystem, managing subsystem – in the “said database” limitation of both claims 1 and 10, the ALJ first needed to resolve whether the term itself was indefinite, resolving that the term was actually definite. See ALJ ID at 60. To support this conclusion, the ALJ noted the clarity of the claims and specification in articulating that the centralized database subsystem’s job is "receiving said management registration request" and "registering said first managing subsystem for external management," whereas the centralized database system's role is, among other things, storing router configuration data.” Id. As such, the ALJ construed “said database” to mean the database system. Id.

As to the preamble’s “reducing computational overhead in a centralized database system" in claims 1 and 10, the ALJ first determined that this term was limiting, based largely on the Complainant’s patent prosecution history which – unsuccessfully – argued to the Patent Office’s Examiner that the term was indeed limiting. Id. at 61 – 62. The ALJ then construed the term to mean reducing the amount of computation in a centralized database system. Id. at 63. Finally, the claim terms "said router configuration data managed by said database system and derived from configuration commands supplied by a user and executed by a router configuration subsystem before being stored in said database" (in claims 1, 10, and 19) are the only claim terms whose construction was contested, construed, and upheld before the Commission. Id. at 64; Comm’ Op. at 8 – 10. The dispute mostly concerned whether the data to be stored were “configuration commands” or “configuration data.” See ALJ ID at 64. Consistent with the ALJ, the Commission relied on the specification and held that the term requires storage of router configuration data, not the configuration commands. See Comm’ Op. at 9. In taking this position, the Commission also relied on the prosecution history which distinguished the claimed invention from the prior art specifically by stating that the prior art did not execute commands before storing the resulting configuration data in the database. Id. at 9 – 10.

Upon construing these claims, the ALJ’s read-on analysis upheld by the Commission found infringement, both directly and indirectly, of ‘537 patent claims 1, 2, 8-11, and 17- 19 by Arista’s accused legacy products, namely the 7010, 7048, 7050, 7050X, 7150, 7250X, 7280E; 7300, 7300X, and 7500E series switches, as well as the component parts of such switches, which all run Arista’s “Extensible Operating System” or “EOS.” See ALJ ID at 14, 64 – 81, 87-89; Comm’ Op. at 11, 24. At EOS’s heart is Sysdb which holds the complete “state” of the system and interfaces with numerous subsystems called “agents.” See ALJ ID at 14. The state refers to a piece of data stored in Sysdb and identified by a pathname; an example of state is the temperature of the switch. See Arista Glossary, Arista Supplement IV. An agent is a subsystem coupled to EOS’s Sysdb and responsible for handling or managing a particular feature or set of features; e.g. an LED Driver for managing LED data. See ALJ ID at 66.

Legacy Products

In the legacy products, EOS was a router operating system on router devices with a processor and memory in which EOS ran and where the EOS processes were further found to “exchange state through an in-memory database.” See ALJ ID at 65. The ALJ found these features to satisfy the “In a router device…within said memory comprising:” limitation of claim 19. Id. Also in the legacy product, the Sysdb interacted with its agents through “mounting” akin to the patent’s teaching of the “database subsystem” as the Sysdb part that receives the management registration request from an external subsystem and registers the subsystem for external management. Id. at 65 – 66. In this manner, Sysdb satisfied the claim limitation of “a database subsystem” in claim 19. Id. at 65. Further, as each agent in the legacy product generally handled a particular feature or set of related features (e.g. MLAG agent manages MLAG data) and was coupled to EOS’s Sysdb for such handling, the ALJ found the EOS agents to satisfy the “plurality of client subsystems, each operatively coupled for communication to said database subsystem” limitation of claim 19. Id. at 66. With respect to that coupling, the complainant’s expert, upon whom the ALJ relied, described the agents meeting that coupling limitation as “the EOS agents that connect to Sysdb.” ITC Complainant’s Exhibit 0007C at Q/A 128. [ .] See ALJ ID at 66, FN 23. [ .] Id. at 66, FN 23. [ .] Id. The ALJ found the EOS agents externally managed data by [ ] the data in Sysdb, since an agent [ .] Id. In the legacy product, [

.] Id. at 67 – 68. In this manner, the legacy product’s [

.] Id. at 69. As such, the legacy product’s agent activity read onto the claim 19 limitation of “one of said client subsystems configured as a managing subsystem to externally manage router data.” Id. at 66.

The management request, or [ ], that the agent sent to Sysdb indicated the [ .] Id. at 69 – 70. The ALJ found that functionality to satisfy “upon issuing a management request to said database subsystem” limitation of claim 19.3 Id. at 70. The legacy product’s Sysdb included a [ ]; further, the [ .] Id. This arrangement satisfied the “database operatively coupled to said database subsystem, said database configured to store router configuration data” in claim 19. Id. In the legacy products, Sysdb processed write-mount requests and allowed the requesting agent to externally manage data, specifically router configuration data described further below. Id. at 70 – 71. The ALJ found this functionality to satisfy claim 19’s limitation requiring the database’s configuration to “delegate management of router configuration data to a management subsystem that requests to manage router configuration data.” Id.

With respect to router configuration information, the legacy products [

.] Id. at 71. The [ .] Id. at 71 – 72. As such, the [


 3 [

] See ITC Complainant’s Exhibit 0007C at Q/A 129. .] Id. The [

.] Id. at 72. The ALJ found that this [

] met the claim limitation for “router configuration data managed by said database system and derived from configuration commands supplied by a user and executed by a router configuration subsystem before being stored in said database.” Id. at 71 – 72.

EOS Redesign

First and foremost, Arista purports to have removed the [ ] from the agents to Sysdb found to infringe the ‘537 patent. Arista Ruling Request at 4. To effect this change, Arista claimed that the agents will no longer send to Sysdb [ ] that specify the details of what the agent wishes to mount. Id. at 13, 16. Instead, the EOS Redesign will start agents with every [ ] the agent could need in place (except for the CLI agent which will retain its [ ]), as opposed to the ad-hoc request-based method used in the legacy products. Id. at 16, 17. The EOS Redesign achieves this end with a program called “ProcMgr” (short for Process Manager) which starts and stops agents. Id. at 17. ProcMgr starts and stops EOS agents, but cannot mount state from Sysdb, read data from Sysdb, or write data to Sysdb. Arista Supplement I at 2, 4. Further, ProcMgr does not use the AttrLog communications protocol that all EOS agents use to communicate with Sysdb, nor does ProcMgr have a [ ] profile, a [ ] of its own, or access to the [ ] profile or [ ] table of any EOS agent. Id. at 4.

Once ProcMg knows to start an agent, ProcMgr issues a [ ] command which includes the agent’s name to another process, [ ] which then creates a connection to Sysdb and passes information from the [ ] command to Sysdb. Arista Ruling Request at 17. As a side note, to communicate with Sysdb – including sending [ ], or any other communications – an agent must first be connected to Sysdb by a socket. Arista Supplement I at 2. After the connection is made, [ ] sends data about the connection back to ProcMgr. Arista Ruling Request at 17. [ ] command’s full message forward to Sysdb reads as,

[

] Id. at 18. As such, Arista claimed that only the name of the agent was passed from [ ] to Sysdb. Id. at 18. According to Arista, the [ ] command is always sent before the agent has been started, and so before the agent exists. Id. The representative data processing in the EOS Redesign is pictured below. Id. at 17. 

[ ]

Next, for each of the over eighty EOS agents, Arista claims to have created a profile with every [ ] the agent may need or want; the profile identifies those potential mounts to Sysdb. Id. at 19. Once Sysdb receives the [ ] command with the agent’s name, Sysdb reads the profile and populates Sysdb’s [ ] table copy with the mounts. Id. At that point, Sysdb writes the table into the socket [ ] made in the prior step, along with a copy of all the state that was mounted. Id. at 19-20. As the agent usually does not yet exist, the agent does not read the connection’s other end. Id. at 19. Linux then puts the data Sysdb sent (including the [ ] table, or a portion thereof) into a kernel socket buffer, where the data remains until the agent exists and can read the data at the connection’s end. Id. Linux is an open source operating system based in part on the Unix operating system. Id. at FN 9. These steps can be illustrated as follows:

[ ] Once the Sysdb connection is made, the agent can be started and pre-loaded with the [ ] table. Id. at 20. Next, as in the legacy product, ProcMgr processes the code to start the agent using the standard Linux socket mechanism to send data from Sysdb to the agent and back. Id. Before the agent starts, the [ ] table data will remain in the kernel buffer associated with the socket connection between Sysdb and the agent and then get retrieved by the agent with standard Linux system calls when the agent starts. Id. These calls will read any data from the kernel and are begun once the agent is apprised there is some kind of data in the kernel awaiting the agent. Id. at 20 – 21. Sysdb does not act in response to such calls or get notice of such calls. These steps can be seen illustrated in the following: 

[ ]

As to the process of reading data from the kernel buffer, the agent – which is a process as understood in the Linux context – causes the Linux kernel to copy data from the kernel buffer to the process’s own buffer when the agent reads data from a socket. Arista Supplement II at 2. The agent reads this data out of the socket through a “read system call.” Id. Generally, read system calls have only three parameters: the identity of the socket that the process will read, the address of the process buffer to which the data will be copied, and the maximum data that can be retrieved. Id. Once the agent makes the read system call, the Linux kernel checks for data in the buffer associated with the designated socket connection and copies the data from the kernel buffer to the process’s buffer if so, and indicates there is no data if not. Id. Upon copying the data to the process’s buffer, the kernel buffer will also indicate the number of bytes copied, after which the data will no longer be available in the kernel buffer. Id. However, the kernel cannot receive that system call until after Sysdb has made a complete pass over the [ ] profile, updating its own internal records to reflect that Sysdb has established the mounts, before Sysdb writes any of the state (including the [ ] table) to the socket and so before the [ ] table or any other state is placed in the kernel buffer. Arista Supplement II at 5. In other words, the agent will not issue a read system call to the kernel without all mounts being in place and Sysdb initiating writing [ ] tables to the socket. Id. Relatedly, there is no address (or function) that Sysdb may use to get router data, as Sysdb never requested data copies from agents. Arista Supplement III at 15. Additionally, there is no evidence from the record at the Commission during Inv. No. 337-TA-944 indicating that the read system call was either accused by the complainant or even considered by the ITC as satisfying the “upon issuing a management request to said database subsystem” limitation of claim 19.

As to the CLI agent, the EOS Redesign will only allow the [ ] or [ ] flags on mount requests to read as true for the CLI agent, meaning the mount request will be for a [ ]; [ ] would set [ ] to false and allow the database’s state to change. Arista Ruling Request at 21. Arista also programmed the EOS Redesign to have Sysdb shut down the socket connection should an agent be modified to permit the agent to send a [ ] to Sysdb. Id. at 22. To evidence these purported changes, Artista has provided CBP with samples, software, switch-testing instructions, and programs for observing the EOS Redesign’s behavior as described above. Id. at 22 – 25. As for the non-infringement arguments concerning the ‘592 and ‘145 patents, Arista claims to have removed in its entirety from switches running the EOS Redesign the PVLAN feature that was found to infringe and has not substituted any functionality in its place. Id. at 26. Furthermore, Arista has taken steps to stop its customers from configuring specific port types claimed in the patents. Id.

ISSUE:

Whether Arista switches running the EOS Redesign are covered by the asserted claims of the `537, `592, and `145 patents and therefore falls within the scope of the Commission’s limited exclusion order from Investigation No. 337-TA-944, such that they would be excluded from entry for consumption into the United States.

LAW AND ANALYSIS:

Determining patent infringement requires two steps. Advanced Steel Recovery, LLC v. X-Body Equip., Inc., 808 F.3d 1313, 1316 (2015). The first is to construe the limitations of the asserted claims and the second is to compare the properly construed claims to the accused product. Id. To establish literal infringement, every limitation recited in a claim must be found in the accused product whereas, under the doctrine of equivalents, infringement occurs when there is equivalence between the elements of the accused product and the claimed elements of the patented invention. Microsoft Corp. v. GeoTag, Inc., 817 F.3d 1305, 1313 (Fed. Cir. 2016). One way to establish equivalence is by showing, on an element-by-element basis, that the accused product performs substantially the same function in substantially the same way with substantially the same result as each claim limitation of the patented invention, which is often referred to as the function-way-result test. See Intendis GmbH v. Glenmark Pharms., Inc., 822 F.3d 1355, 1361 (Fed. Cir. 2016).

The ultimate construction of a claim limitation is a legal conclusion, as are interpretations of the patent’s intrinsic evidence (the patent claims, specifications, and prosecution history). UltimatePointer, L.L.C. v. Nintendo Co., 816 F.3d 816, 822 (Fed. Cir. 2016) (citing Teva Pharms. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 841, 190 L. Ed. 2d 719 (2015); see also Multilayer Stretch Cling Film Holdings, Inc. v. Berry Plastics Corp., 831 F.3d 1350, 1357 (Fed. Cir. 2016) (“Claim construction is a question of law, reviewed de novo, but any extrinsic fact-finding by the district court in the course of claim construction is reviewed for clear error.”). Infringement, involving the comparison of the claims to the accused product, is a question of fact. Apple Inc. v. Samsung Elecs. Co., Ltd., 2016 U.S. App. LEXIS 18225, at *7 (Fed. Cir. 2016) (en banc).

The scope and meaning of the asserted claims is determined by looking to the words of the claims themselves, the specification, the prosecution history, and if necessary, any relevant extrinsic evidence. Advanced Steel Recovery, 808 F.3d at 1315-17. Moreover, claim terms are generally given their ordinary and customary meaning, which is the meaning they would have to a person of ordinary skill in the art at the time of the invention. Poly-America, L.P. v. API Indus., Inc., 2016 U.S. App. LEXIS 18486, at *9 (Fed. Cir. 2016) (citing Phillips v. AWH Corp., 415 F.3d 1303, 1312-13 (Fed. Cir. 2005) (en banc)). “Importantly, the person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification.” UltimatePointer, 816 F.3d at 822 (quoting Phillips, 415 F.3d at 1313); see also Retractable Techs., Inc. v. Becton, 653 F.3d 1296, 1305 (Fed. Cir. 2011) (“It is axiomatic that the claim construction process entails more than viewing the claim language in isolation.”). In particular, “the specification ‘is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term.’” Phillips, at 1313 (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)). However, while claims are read in view of the specification for which they are a part, it is improper to read limitations from the embodiments in the specification into the claims. Hill-Rom Servs. v. Stryker Corp., 755 F.3d 1367, 1371 (Fed. Cir. 2014).

Accordingly, the ordinary and customary meaning of the claim language generally controls unless the patentee acts as his own lexicographer and provides a special definition for a particular claim term or the patentee disavows the ordinary scope of a claim term either in the specification or during prosecution. InterDigital Communs., LLC v. U.S. In t’l T rade Com m ’n , 690 F.3d 1318, 1324 (Fed. Cir. 2012); see also Hill-Rom Servs., 755 F.3d at 1371 (“There are only two exceptions to this general rule: 1) when a patentee sets out a definition and acts as his own lexicographer, or 2) when the patentee disavows the full scope of the claim term either in the specification or during prosecution.") (quoting Thorner v. Sony Computer Entm't Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir. 2012)).

The standards for finding lexicography and disavowal are "exacting." Pacing Techs., LLC v. Garmin Int'l, Inc., 778 F.3d 1021, 1024 (Fed. Cir. 2015). “To act as a lexicographer, a patentee must ‘clearly set forth a definition of the disputed claim term’ and ‘clearly express an intent to define the term.’” Id. (quoting Thorner, 669 F.3d at 1365. “Similarly, disavowal requires that ‘the specification [or prosecution history] make[] clear that the invention does not include a particular feature.’” Id. (quoting SciMed Life Sys. Inc. v. Advanced Cardiovascular Sys., Inc., 242 F.3d 1337, 1341 (Fed. Cir. 2001). For example, disavowal or disclaimer has been found based on “clear and unmistakable statements by the patentee that limit the claims, such as ‘the present invention includes . . .’ or ‘the present invention is . . .’ or ‘all embodiments of the present invention are . . . .’” Id. (citing Regents of Univ. of Minn. v. AGA Med. Corp., 717 F.3d 929, 936 (Fed. Cir. 2013); Honeywell Int'l, Inc. v. ITT Indus., Inc., 452 F.3d 1312, 1316-19 (Fed. Cir. 2006); SciMed Life Sys., Inc., 242 F.3d at 1343-44).

Ultimately, "[t]he only meaning that matters in claim construction is the meaning in the context of the patent," Trs. of Columbia Univ. v. Symantec Corp., 811 F.3d 1359, 1363 (Fed. Cir. 2016), and “[l]egal error arises when a court relies on extrinsic evidence that contradicts the intrinsic record.” Ruckus Wireless, Inc. v. Innovative Wireless Solutions, LLC, 824 F.3d 999, 1003 (Fed. Cir. 2016) (citing Lighting Ballast Control LLC v. Philips Elecs. N. Am. Corp., 790 F.3d 1329, 1338 (Fed. Cir. 2015), cert. denied by Universal Lighting Techs., Inc. v. Lighting Ballast Control, LLC, 2016 U.S. LEXIS 1155 (U.S., Feb. 29, 2016). Therefore, "[t]he construction that stays true to the claim language and most naturally aligns with the patent's description of the invention will be, in the end, the correct construction." Papst Licensing GmbH & Co. KG v. Fujifilm Corp., 778 F.3d 1255, 1261 (Fed. Cir. 2015) (quoting Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998), adopted by Phillips, 415 F.3d at 1316).

Lastly, only those claim terms that are disputed must be construed and only to the extent necessary to resolve the dispute. See O2 Micro Int'l Ltd. v. Beyond Innovation Tech. Co., 521 F.3d 1351, 1362 (2008) (“We, however, recognize that district courts are not (and should not be) required to construe every limitation present in a patent's asserted claims”). Rather, “[c]laim construction is a matter of resolution of disputed meanings and technical scope, to clarify and when necessary to explain what the patentee covered by the claims, for use in the determination of infringement.” Id. (quoting U.S. Surgical Corp. v. Ethicon, Inc., 103 F.3d 1554, 1568 (Fed. Cir. 1997); see also Van d e rlan d e In du s. Nede rla n d BV v. U.S. In t’l T rade Comm ’n , 366 F.3d 1311, 1323 (Fed. Cir. 2004).

Under section 337 of the Tariff Act of 1930, as amended, 19 U.S.C. § 1337, the Commission has authority to conduct investigations into imported articles that allegedly infringe United States patents and impose remedies if the accused articles are found to be infringing. See 19 U.S.C. § 1337(a)(1)(B), (b)(1), (d), (f), (i). 19 U.S.C. § 1337(d), in particular, empowers the Commission to direct the exclusion from entry of articles found to infringe the asserted patents. When the Commission determines there is infringement and thus a violation of section 337, it generally issues one of two types of exclusion orders: (1) a limited exclusion order or (2) a general exclusion order. See Fuji Ph o to Film Co., Ltd . v. U.S. Int’l T ra d e Comm ’n , 474 F.3d 1281, 1286 (Fed. Cir. 2007).

Both types of orders direct CBP to bar infringing products from entering the country. See Yingbin-Nat u re (Gua n gd on g) W oo d Ind u s. Co. v. U.S. In t’l T rade Comm ’n , 535 F.3d 1322, 1330 (Fed Cir. 2008). “A limited exclusion order is ‘limited’ in that it only applies to the specific parties before the Commission in the investigation. In contrast, a general exclusion order bars the importation of infringing products by everyone, regardless of whether they were respondents in the Commission's investigation.” Id. A general exclusion order is appropriate only if two exceptional circumstances apply. See Kyo ce ra W ire le ss Corp. v. U.S. In t’l T rade Comm ’n , 545 F.3d 1340, 1356. A general exclusion order may only be issued if (1) “necessary to prevent circumvention of a limited exclusion order,” or (2) “there is a pattern of violation of this section and it is difficult to identify the source of infringing products.” 19 U.S.C. § 1337(d)(2); see also Kyocera, 545 F.3d at 1356 (“If a complainant wishes to obtain an exclusion order operative against articles of non-respondents, it must seek a GEO [general exclusion order] by satisfying the heightened burdens of §§ 1337(d)(2)(A) and (B).”).

In addition to the action taken above, the Commission may issue an order under 19 U.S.C. § 1337(i) directing CBP to seize and forfeit articles attempting entry in violation of an exclusion order if their owner, importer, or consignee previously had articles denied entry on the basis of that exclusion order and received notice that seizure and forfeiture would result from any future attempt to enter articles subject to the same. An exclusion order under § 1337(d)—either limited or general—and a seizure and forfeiture order under § 1337(i) apply at the border only and are operative against articles presented for customs examination or articles conditionally released from customs custody but subject to a timely demand for redelivery. See 19 U.S.C. §§ 1337(d)(1) (“The Commission shall notify the Secretary of the Treasury of its action under this subsection directing such exclusion from entry, and upon receipt of such notice, the Secretary shall, through the proper officers, refuse such entry.”) and (i)(3) (“Upon the attempted entry of articles subject to an order issued under this subsection, the Secretary of the Treasury shall immediately notify all ports of entry of the attempted importation and shall identify the persons notified under paragraph (1)(C).”); see also ClearCorrect Operating, L L C v. U.S. In t’l T rad e Com m ’n , 810 F.3d 1283, 1295 (Fed. Cir. 2015) (“This section [1337(i)] permits the Commission to exclude ‘articles’ from importation into the United States; however, it is difficult to see how one could physically stop electronic transmissions at the borders under the current statutory scheme…. A construction of the term ‘articles’ that includes electronically transmitted digital data is also not reasonable when applied to Section 337(i)(3). This section reads, ‘[u]pon the attempted entry of articles subject to an order issued under this subsection, the Secretary of the Treasury shall immediately notify all ports of entry of the attempted importation and shall identify the persons notified under paragraph (1)(C).’ Not only can an electronic transmission not be su b ject to a n ‘at te mp ted e n try’ th rou gh a ‘po rt of e n try,’ it a lso ca nn o t be int e rcep ted a t a ‘po rt of e ntry’ a s co n tem p la te d in the sta tu te .”) (emphasis added).

Significantly, unlike district court injunctions, the Commission can issue a general exclusion order that broadly prohibits entry of articles that infringe the relevant claims of an asserted patent without regard to whether the persons importing such articles were parties to, or were related to parties to, the investigation that led to issuance of the general exclusion order. See Va stfa me Cam e ra, L td . v. U.S. In t’l T rade Comm ’n , 386 F.3d 1108, 1114 (Fed. Cir. 2004). The Commission also has recognized that even limited exclusion orders have broader applicability beyond just the parties found to infringe during an investigation. See Certain GPS Devices and Products Containing Same, Inv. No. 337-TA-602, Comm’ Op. at 17, n. 6, Doc ID 317981 (Jan. 2009) (“We do not view the Court’s opinion in Kyocera as affecting the issuance of LEOs [limited exclusion orders] that exclude infringing products made by respondents found to be violating Section 337, but imported by another entity. The exclusionary language in this regard that is traditionally included in LEOs is consistent with 19 U.S.C. § 1337(a)(1)(B) - (D) and 19 U.S.C. § 1337(d)(1).”).

However, this is not the only difference between district court injunctions under section 283 of the Patent Act and Commission exclusion orders under section 337 of the Tariff Act. For example, the traditional test for injunctive relief, used by district courts in accordance with the Supreme Court’s eBay Inc. v. MercExchange, L.L.C., 547 U.S. 388 (2006), “does not apply to Commission remedy determinations under Section 337.” Spansion, In c. v. U.S. In t’l T rade Com m ’n , 629 F.3d 1331, 1359 (Fed. Cir. 2010). This difference between exclusion orders under Section 337 and injunctions under the Patent Act follows “the long-standing principle that importation is treated differently than domestic activity.” Id. at 1360 (citing United States v. 12 200-Ft. Reels of Super 8mm Film, 413 U.S. 123 (1973) (“Import restrictions and searches of persons or packages at the national borders rest on different considerations and different rules of constitutional law from domestic regulations. The Constitution gives Congress broad, comprehensive powers ‘to regulate Commerce with foreign Nations.’ Art. I, § 8, cl. 3.”); see also Buttfield v. Stranahan, 192 U.S. 470 (1904) (“As a result of the complete power of Congress over foreign commerce, it necessarily follows that no individual has a vested right to trade with foreign nations, which is so broad in character as to limit and restrict the power of Congress to determine what articles of merchandise may be imported into this country and the terms upon which a right to import may be exercised. This being true, it results that a statute which restrains the introduction of particular goods into the United States from considerations of public policy does not violate the due process clause of the Constitution.”) (emphasis added).

Moreover, in the district courts, the criteria for adjudicating a violation of an injunction against future infringement by a party whose legacy products have already been adjudged to infringe requires application of the colorable differences test. TiVo Inc. v. Echostar Corp., 646 F.3d 869, 876 (Fed. Cir. 2011) (en banc). Under this test, if new or redesigned products are so different from the product previously found to infringe (focusing not on differences randomly chosen between the two but on the specific features of the product found to infringe in the earlier infringement trial), such that they raise a fair ground of doubt as to the wrongfulness of the defendant's conduct, the new or redesigned products are deemed to be more than colorably different from the legacy one adjudged to be infringing and violation of the injunction at this point would not be the appropriate consideration. Instead, a new trial would be required to litigate the infringement question. Id. at 881-83. The initial inquiry under the colorable differences test, therefore, focuses on whether the modification in question is significant. Id.

Exclusion orders, however, apply to any articles—new, modified, or otherwise—that are “covered by” the patent claims included in the exclusion order. See Certain Optical Disk Controller Chips and Chipsets, Inv. No. 337-TA-506, Comm’ Op. at 56-57, USITC Pub. 3935, Doc ID 287263 (July 2007) ("The Commission's long-standing practice is to direct its remedial orders to all products covered by the patent claims as to which a violation has been found, rather than limiting its orders only to those specific models selected for the infringement analysis...[W]hile individual models may be evaluated to determine importation and infringement, the Commission's jurisdiction extends to all models of infringing products that are imported at the time of the Commission's determination and to all such products that will be imported during the life of the remedial orders."). The Commission has confirmed that this requires CBP to employ the traditional two-step test for patent infringement, and not the colorable differences test from TiVo, when administering a Commission exclusion order under section 337 to determine whether an imported article, or one at issue in a ruling request, is within the scope of that exclusion order. See Certain Sleep-Disordered Breathing Treatment Systems and Components Thereof, Inv. No. 337-TA-879, Advisory Opinion at 10, n. 2, Doc ID 539875 (Aug. 2014); see also Certain Erasable Programmable Read Only Memories, Inv. No. 337-TA-276 Enforcement Proceeding Comm’ Op. at 11, Doc ID 43536 (Aug. 1991) (“The Commission has always issued its orders in terms of ‘infringing’ products, and has always intended them, as in this case, to prohibit to future importation or sale of products which were not specifically adjudged infringing in the violation proceeding, but do in fact infringe. The Commission has consistently issued exclusion orders coextensive with the violation of section 337 found to exist. Thus, in cases where the violation found involves infringement of patent claims, the Commission has consistently ordered the exclusion of articles which infringe the relevant patent claims.”) (emphasis added).

Notwithstanding the above, the question remains whether the term “covered by” in an exclusion order requires CBP, during its administration, to determine whether there is infringement of the relevant patent claims under the doctrine of equivalents (“DOE” or “doctrine”). As mentioned above, “a product or process that does not literally infringe the express terms of a patent claim may nonetheless be found to infringe if there is 'equivalence' between the elements of the accused product or process and the claimed elements of the patented invention." Duramed Pharms., Inc. v. Paddock Labs., Inc., 644 F.3d 1376, 1390 (Fed. Cir. 2011) (quoting Warner-Jenkinson Co. v. Hilton Davis Chem. Co., 520 U.S. 17 (1997).

However, the DOE has never been applied by CBP during its administration of an exclusion order, leading either to the refusal of an article from entry (other than, for example, one that the Commission previously determined, in the first instance during its investigation, to violate section 337 based on a DOE finding) or to a decision, under the authority within 19 C.F.R. §§ 177 or 174, that an article is covered by a patent claim through the DOE and, as such, subject to exclusion from entry. The ex parte nature of CBP decision-making under these regulatory provisions is less than ideally suited for application of the doctrine. This is further compounded by the unique features of section 337 highlighted above and below (particularly in respect of the shifted burden to establish admissibility following issuance of an exclusion order); the lack of a Commission record with findings of fact on the precise issue, especially with regard to the function-way-result test; and the concomitant resort, that inevitably would follow, to prosecution history estoppel as a defense to infringement or legal limitation on the application of the DOE. Moreover, it is not even clear that the Commission intends for CBP to apply this doctrine during its administration of an exclusion order.

Accordingly, for these reasons, CBP will not extend the doctrine of equivalents when administering an exclusion order pursuant to section 337 except where the Commission found infringement, in the first instance, under this doctrine or, in those cases when the Commission has found the asserted patents only to be literally infringed, where there is clear and convincing evidence that a modified article manufactured or imported by a named respondent identified in the exclusion order fails the function-way-result test based on the administrative record before CBP. This approach is consistent with Commission precedent regarding the scope and reach of its exclusion orders. See Certain Ground Fault Circuit Interrupters and Products Containing the Same, Inv. No. 337-TA-615, Comm’ Op. at 27-28, Doc ID 321819 (March 2009) (“The Commission's practice is consistent with Federal Circuit law, which provides that the Commission's infringement determinations with respect to the adjudicated products are effective for the purposes of the exclusion order against different models presented for importation at a future date if the re is a ‘ close identity between the relevant features of an accused device and the device determined to be infringing.’ Correspondingly, the exclusion order would not apply to products not adjudicated to be infringing, and not having such a ‘close identity,’ thus alleviating respondents' concerns, unless infringement is established by other means.”) (emphasis added) (internal citations omitted). CBP, therefore, will not extend the doctrine when determining admissibility except where this “close identity” is found and only in those instances mentioned above where the Commission itself has found a violation of section 337 by applying the doctrine or when, based on clear and convincing evidence from the administrative record before CBP, in connection with the articles of a named respondent.

Lastly, despite the well-established principle that “the burden of proving infringement generally rests upon the patentee,” Medtronic, Inc. v. Mirowski Family Ventures, LLC, 134 S. Ct. 843; 187 L. Ed. 2d 703; 2014 U.S. LEXIS 788 (2014), the Commission has held that Medtronic is not controlling precedent and does not overturn its longstanding practice of placing the burden of proof on the party who, in light of the issued exclusion order, is seeking to have an article entered for consumption. See Certain Sleep- Disordered Breathing Treatment Systems and Components Thereof, Inv. No. 337-TA- 879, Advisory Opinion at 6-11. In particular, the Commission has noted that “[t]he Federal Circuit has upheld a Commission remedy which effectively shifted the burden of proof on infringement issues to require a company seeking to import goods to prove that its product does not infringe, despite the fact that, in general, the burden of proof is on the patent to prove, by a preponderance of the evidence, that a given article does infringe the patent in question.” Certain Integrated Circuit Telecommunication Chips, Inv. No. 337-TA-337, Comm’ Op. at 21, n. 14, USITC Pub. 2670, Doc ID 217024 (Aug. 1993), citing Se a led Air Corp. v. U.S. In t’l T rade Comm ’n , 645 F.2d 976, 107-08 (C.C.P.A. 1981) (emphasis in original).

This approach is supported by Federal Circuit precedent. See Hyundai Elecs. Indus. Co. v. U.S. Int'l Trade Comm'n, 899 F.2d 1204, 1210 (Fed. Cir. 1990) (“Indeed, we have recognized, and Hyundai does not dispute, that in an appropriate case the Commission can impose a general exclusion order that binds parties and non-parties alike and effectively shifts to would-be importers of potentially infringing articles, as a condition of entry, the burden of establishing noninfringement. The rationale underlying the issuance of general exclusion orders—placing the risk of unfairness associated with a prophylactic order upon potential importers rather than American manufacturers that, vis-a-vis at least some foreign manufacturers and importers, have demonstrated their entitlement to protection from unfair trade practices—applies here [in regard to a limited exclusion order] with increased force.”) (emphasis added, internal citation omitted). Accordingly, the burden is on Arista to establish that the network devices at issue do not infringe one or more of claims 1, 2, 8-11, and 17-19 of the '537 patent; claims 6, 7, 20, and 21 of the '592 patent; or claims 5, 7, 45, and 46 of the '145 patent.

Arista ’s Cla im Con structio n A rgu me n t For The `537 Patent

Arista raises a number of arguments for why its switches running the EOS Redesign are not covered by the claims of the `537 patent. Arista argues, for example, that while there are many agents provided as part of the EOS Redesign, none of them meet the “managing subsystem” limitation of claims 1, 10, and 19. In particular, Arista argues that these agents do not send any communication to Sysdb that may be considered a “management [registration] request” and furthermore that any communication sent from ProcMgr or [ ] cannot be considered such a “request” because the claims require that such a request issue from a router subsystem (as used in claims 1 and 10) or a client subsystem (as used in claim 19) that is, as it appears in the former, a first managing subsystem or, as it appears in the latter, that is configured as a managing subsystem. In other words, in Arista’s view, the proper construction for the claim terms “router subsystems” or “client subsystems” would exclude ProcMgr and [ ].

As noted above, claim terms are generally given their ordinary meaning as understood by persons skilled in the art at the time of the invention. Phillips v. AWH Corp., 415 F.3d 1303, 1312-13 (Fed. Cir. 2005) (en banc). During the investigation at the Commission, the ALJ determined that, in view of the expert testimony, a person having ordinary skill in the art of the `537 patent is a person with a Bachelor of Science degree in computer science, computer engineering, electrical engineering, or a closely related field, along with at least 2-3 years of experience working in the field of network devices or computer networks. The ALJ also construed the claim terms in dispute, as mentioned above. However, the disputed claims terms did not include “router subsystems” (claims 1 and 10) or “client subsystems” (claim 19) and, consequently, the Commission has not established a binding interpretation of these terms to be applied with regard to this question of law during administration of the exclusion order. See ALJ ID at 33, n. 10 (citing Va n de rla n de I n d u s. Nede rla n d B V v. U.S. In t’l T rade Co mm ’n , 366 F.3d 1311), and 54, n. 20 (“This initial determination addresses only the disputed claim terms identified by the parties as needing construction.”).

The term “router subsystems” only appears three times in the `537 patent, once in the abstract with reference to those that are “managing router subsystems” and then again in the preamble of claim 1 (the method claim) and of claim 10 (the machine-executable instructions claim) within the phrase “a plurality of router subsystems.” `537 patent at col. 15, ln. 26, and Col. 16, lns. 51-52.

The term “client subsystems” also appears in the abstract interchangeably with the term “router subsystems.” However, unlike the latter, the written description is replete with references to “client subsystems” and the term is recited in claim 19 (the apparatus claim) within the phrase “a plurality of client subsystems.” `537 patent at col. 18, ln. 24. Arista’s proposed construction for both terms is “subsystems that access or externally manage data stored in the database subsystem.” Arista Supplement IV at 1. Arista believes this construction is compelled by the intrinsic evidence, and in particular the claim language itself when, for example, claim 19 recites “a plurality of client subsystems, each operatively coupled for communication to said database subsystem, one of said client subsystems configured as a managing subsystem to externally manage router data upon issuing a management request to said database subsystem….” Id. (emphasis in the submission). Arista also points to the specification in support of its proposed construction, arguing that the Abstract and Summary of the Invention organize subsystems into “two main categories relevant to the claimed invention, namely the database or the ‘other subsystems’ which access data from the database.” Id. at 2.

As an initial point, the general presumption in patent law is that different terms in patent claims have different meanings. See Chi. Bd. Options Exch., Inc. v. Int'l Sec. Exch., LLC, 677 F.3d 1361, 1369 (Fed. Cir. 2012); see also CAE Screenplates, Inc. v. Heinrich Fiedler GmbH & Co. KG, 224 F.3d 1308, 1317 (Fed. Cir. 2000) ("In the absence of any evidence to the contrary, we must presume that the use of these different terms in the claims connotes different meanings."). Despite the usage of different terms in the `537 patent (router as opposed to client subsystems), there is evidence that these terms are synonymous and do not have a different meaning or scope. The use of the terms interchangeably in the Abstract, the lack of any reference in the specification to “router subsystems” outside of the claims compared with the exclusive use of “client subsystems” in the written description, the common association of both terms with the centralized database system, and the similar context in which they appear in their respective claims (e.g., “a plurality of” and that the phrase “one of which is a first managing subsystem” from claim 1 is equated with “configured as a managing subsystem” from claim 19) all indicate that the terms are interchangeable and that the general presumption is overcome. Finally, the administrative record at the Commission does not contain a finding that the scope of the separate independent claims differs in a significant way other than the type of claim involved (i.e., method as opposed to an apparatus claim) and, if anything, suggests their close correspondence. See ALJ ID at 65 (“Asserted claim 19 is an independent claim, as are asserted claims 1 and 10. Claim 1 is a method claim, claim 10 is directed to machine-executable instructions, and claim 19 is an apparatus claim. Many of the method steps of claim 1 recite limitations similar to those recited in claim 19. The same holds true with the machine-executable instructions recited in claim 10. Therefore, this initial determination will analyze claim 19 before analyzing claims 1 and 10 (and their associated dependent claims).”) (emphasis added). For these reasons, the same construction will be adopted for both terms and the use or reference to either in this determination is understood to include and apply to the other.

Another issue requiring resolution is whether, at least for purposes of claims 1 and 10, use of the term “router subsystems” in the preamble is limiting. See CBP HQ Ruling H025822 at 13 (dated November 23, 2009) (“Because the disputed term appears in the preamble to claim 1, we must first determine whether it is in fact a separate limitation.”) (citation omitted). “In general, a preamble is construed as a limitation ‘if it recites essential structure or steps, or if it is necessary to give life, meaning, and vitality’ to the claim." Symantec Corp. v. Computer Associates International, Inc., 522 F.3d 1279, 1288 (Fed. Cir. 2008) (quoting Catalina Mktg. Int'l, Inc. v. Coolsavings.com, Inc., 289 F.3d 801, 808 (Fed. Cir. 2002). “A preamble is not limiting, however, ‘where a patentee defines a structurally complete invention in the claim body and uses the preamble only to state a purpose or intended use for the invention.’” Id. “Absent clear reliance on the preamble in the prosecution history, or in situations where it is necessary to provide antecedent basis for the body of the claim, the preamble ‘generally is not limiting.’” Id.

In claims 1 and 10, the term appears in the phrase “a plurality of router subsystems one of which is a first managing subsystem” where, in the body, the claims continue to identify and claim the features of the “first managing subsystem.” Accordingly, it is determined that this term in the preamble of claims 1 and 10 is a limitation because it does not simply provide context for what is being described in the body of the claims and is not merely duplicative of those limitations but instead recites essential structure that requires the “first managing subsystem” to be selected from the “plurality of router subsystems.” However, even if this term is not a limitation, the synonymous term “client subsystems” is clearly a limitation that appears in the body of claim 19. As the ALJ found during the investigation with respect to a separate claim limitation that was in dispute, the appearance of a term in the body settles any potential dispute about limitations within the asserted patent claims. See ALJ ID at 65 (“The phrase ‘external management’ appears in the preambles of claims 1 and 10, and in the body of claim 19. Although the parties disagree on whether the phrase ‘external management’ in the preambles of claims 1 and 10 is a limitation, that dispute is overshadowed by that fact that ‘external management’ is a requirement present in the body of those claims.”). With these initial points established, the analysis may turn to the construction of the claim terms “client subsystems” and “router subsystems.”

Starting with representative language from the claim itself, claim 19 recites “a plurality of client subsystems, each operatively coupled for communication to said database subsystem, one of said client subsystems configured as a managing subsystem to externally manage router data….” `537 patent at col. 18, lns. 25-28 (emphasis added). This establishes that “client subsystems” are external to the claimed database subsystem and also operatively coupled to it for communication.

Consistent with the above, the specification states that “[i]n its most general terms, the method of the invention comprises software routines and algorithms which are generally provided as part of an operating system which is executed in a router device. The operating system software which is also known as internetwork operating system (IOS) comprises a plurality of subsystems, each of which perform functions for the router.” `537 patent at col. 3, lns. 56-62. The description above is against the backdrop of the prior art, where the specification notes that a router operating system in a router device from the prior art is understood to “provide the basic command functions for the routing device as well as various subsystem components which provide specific functions or routines provided by the routing device.” Id. at col. 1, lns. 14-18. In particular, the specification recognizes that “router devices [in the prior art] typically include a plurality of client subsystems which manage specific functions….” Id. at col. 1, lns. 37-38. The reference to the term “client subsystems” to describe prior art devices indicates that a person of ordinary skill would be familiar with the term as used in the `537 patent and understand that it refers to those components of the IOS that perform and manage specific functions for the router device.

Moreover, with respect to the method of the invention, the specification further provides that “[o]ne of the subsystems provided by the IOS is a centralized database system (sysDB). The sysDB executes as a subsystem component in the router and provides a centralized storage and retrieval facility for configuration information required by other subsystems of the IOS.” `537 patent at col. 3, lns. 63-67. The patent specification, therefore, describes sysDB as a subsystem provided by the IOS and distinguishes it from the other subsystems that are external to it. The sysDB subsystem is operatively coupled to these other subsystems of the IOS to provide transactional services. See `537 patent at col. 5, lns. 50-51. This arrangement is depicted below in Figure 2 from the `537 patent which shows various exemplary client subsystems (including a config subsystem 28, an Internet Protocol (IP) subsystem 30, an Ethernet subsystem 32, a dialer subsystem 34, an authentication (AAA) subsystem 36, and a point-to-point protocol (PPP) subsystem 38), each of which is operatively coupled for communication to the centralized database system (sysDB 26). See `537 patent at col. 7, lns. 46-55.




Arista’s proposed construction of “router subsystems” and “client subsystems” attempts to limit these terms to subsystems that access or externally manage data stored in the database subsystem (sysDB) as opposed to interpreting these subsystems, in light of description above from the specification and the representative language of claim 19, as software routines that perform a function for the router and are external to the sysDB but operatively coupled to it for communication, and where at least one of the client subsystems is configured as a managing subsystem that registers for external data managing services with the sysDB by transmitting a managing registration request. The claim language and the specification from above clearly establish that the “managing subsystem” which issues the management request to the database subsystem indicating the router configuration data to be externally managed must be selected from the client subsystems of the operating system.

This does not mean, of course, that every client subsystem must have the ability to externally manage router configuration data. Some client subsystems, as Arista points out, only have the ability to access such data. See Arista Supplement IV at 2; see also `537 patent at col. 5, lns. 4-7 (“The external managing unit [within sysDB] carries out the operating of registering and unregistering subsystems for external data managing services. The external managing unit further carries out the operation of providing transaction access to such externally managed data to client subsystems requesting such data.”). The `537 patent, thus, describes some client subsystems that are configured as managing subsystems with the ability to externally manage router configuration data and also describes other client subsystems that can only access the data.

However, it does not follow to conclude from this, as Arista does, that, in order to qualify as a client subsystem under the `537 patent, the subsystem must have either the ability to externally manage router configuration data or be able to access to the same. In other words, the fact that the `537 patent describes client subsystems with these features does not establish that, in the absence of these features, a software routine performing a function for the router cannot be considered a “router subsystem” or “client subsystem.” This is particular the case in light of the language of the claim and description from the specification cited above where the focus is on client subsystems as software routines that are part of the operating system executed on the router device that perform functions for the router and that are external to the database subsystem. The limitation Arista attempts to read into these claim terms—mandating that a software routine cannot be a client subsystem unless it is configured to externally manage router data or access such data—is not supported by the intrinsic evidence. Also, Arista has not argued, and there is no evidence for such a position, that the claim terms “router subsystems” and “client subsystems” have departed from their plain and ordinary meaning to one skilled in the art through lexicography or disavowal. As noted above, the standards for finding either are exacting and the patentee must have either clearly set forth a definition of the disputed claim term other than its plain and ordinary meaning while clearly expressing an intent to redefine the term or made clear that the invention does not include a particular feature. As the intrinsic evidence concerning the `537 patent does not support such a finding, the plain meaning of “router subsystems” and “client subsystems” must control.

While the other limitations in claims 1, 10, and 19 provide additional information regarding what is required of the claimed router and client subsystems and, more generally, for a router device to practice the invention of the `537 patent (including that, as noted above, one of the client subsystems must be configured as a managing subsystem to externally manage router configuration data upon issuing a management request to the database subsystem), this does not mean that further construction is needed for these terms from what has been established above. Accordingly, it is determined that a person skilled in the art would understand that “router subsystems” and “client subsystems” mean “software routines provided as part of an operating system run or otherwise executed on a router device that perform functions for the router and that are external to the database subsystem but operatively coupled for communication with it.”

Arista ’s Non -Infringemen t Argum e nts For T he ‘5 37 P ate nt

In addition to its claim construction argument discussed above, Arista makes two primary arguments for finding non-infringement of switches running the Redesigned EOS. First, that it has removed the [ ] that were found to satisfy the “management registration request” and the “management request” limitations in claims 1, 10, and 19. The second argument is that Arista has designed away from the operating system in the legacy products found to infringe that initiated [ ] on an ad hoc, dynamic, request-based basis (and where the agent would request a [ ] only when and if it actually needed one) to a static, pre-loaded approach that avoids, in Arista’s view, anything that could arguably be considered a [ ] or, more importantly, a “management [registration] request” that is transmitted from the agent to Sysdb. Arista Ruling Request at 16. This was achieved, according to Arista by pre-loading all possible [ ] whether the agent needs them or not. Id. Arista Ruling Request, Ex. A, Duda Decl. at ¶21.

As for the first argument, Arista claims to have eliminated the ability of the agents to transmit either [ ] to Sysdb by preventing changes in the agent’s [ ] from being transmitted to Sysdb, whether those changes were [ ], and thus removing the ability to transmit [ ]. Id. at ¶21. The removal of the ability for all non-CLI agents to send [ ] can be seen using a program called “altracer.” Id. at ¶21. Arista developed altracer before institution of the investigation at the Commission to enable its engineers to monitor the communication between EOS agents and Sysdb. Id. Prior to implementation of the redesign, altracer would show the various agents transmitting [ ] by sending messages containing updates to [ ].

This can be seen in the following example provided by Arista showing an excerpt from an altracer report for an agent in the legacy EOS called [ ]:

[

[

]

]

In this depiction the text “[ ]” shows that this is an altracer report being printed to the display [ ] and that it is tracing messages from the [ ] to Sysdb that send updates [ ], which is the [ ]—the entity to which [ ] are sent. Thus, altracer is depicting the transmission of [ ] from the agent to Sysdb, which are the same [ ] found by the Commission to practice the “management request” limitation of the claims.

However, when altracer is used with switches running the Redesigned EOS, it shows that this functionality has been removed.

[

]

In other words, Arista performed the same trace to show any communications from the [ ] agent to the [ ] of Sysdb and, except for read mount requests from CLI, no communication occurred. The evidence above supports a finding that the functionality specifically found to meet the “management [registration] request” during the investigation at the Commission has been removed from Arista’s modified switches. However, the question still remains whether Arista has carried its burden to establish, under its second argument referenced above, that switches running the Redesign EOS employing the “static, pre-loaded approach” are not covered by the patents at issue. Turning to that argument, claims 1, 10, and 19 all require that a plurality of router subsystems (as used in claims 1 and 10) or a plurality of client subsystems (as used in claim 19) have a first managing subsystem or one that is configured as a managing subsystem, respectively, and that the managing subsystem is responsible for issuing the claimed management request to the database subsystem (sysDB) in order to externally manage router configuration data. Moreover, as Arista points out, the claims require the client subsystem that is configured as the managing subsystem be the subsystem outside of sysDB that does the external management. This is consistent with the findings at the Commission. See Comm’n Op. at 13; see also ALJ ID at 66. Accordingly, the agent that transmits a communication that could otherwise satisfy the “management [registration] request” limitation would have to be the agent that actual externally manages the router configuration data in question. Moreover, Arista argues that the agents from the EOS Redesign not only send no communications to Sysdb that may be considered a management request, but that these agents do not exist when there is a communication sent by ProcMgr through [ ] to Sysdb, and therefore that the agents in the redesign cannot meet the managing subsystem limitation.

With this in mind, CBP will consider two scenarios. In the first scenario, CBP has analyzed the relevant limitations with a view to whether it would be appropriate to consider ProcMgr or [ ] as a client subsystem. The second scenario considers whether, in light of the claim limitations, it would be appropriate to consider of ProcMgr and [ ] combined with the EOS agents forming a client and managing subsystem.

Claim 19’s preamble lists a “processor”, “memory”, and a “router operating system” executed within the memory. In the legacy products, Arista’s products were router devices with a processor, memory, and a router system within that memory. See ALJ ID at 65. Consistent with the legacy products, the Redesign EOS will be used in switches and their components, which will necessarily include these same features for their network operations. Arista Ruling Request at 1-2. See ALJ ID at 6. As such, both the legacy products and Redesign EOS include the elements recited in claim 19’s preamble.

Moving forward to the first claim limitation, claim 19 requires a “database subsystem.” The ID described this limitation as the part of the centralized database (i.e. “sysDB”) that receives the external subsystem’s management registration request and registers the subsystem for external management. See ALJ ID at 6, 65. In the legacy products, the ALJ found the portion of Arista’s Sysdb that dealt with the external subsystem [ ] to satisfy the “database subsystem” limitation. See ALJ ID at 65. [

.] In the Redesign EOS, the software includes a Sysdb structure that purportedly already has all the write-mount permissions written into the agent profiles that identify all the potential mounts for an agent, before the agent exists and has the capacity to make a write- mount request. Arista Ruling Request at 19. The Redesign EOS therefore has a component of Sysdb responsible for “mounting” and therefore satisfies the “database subsystem” limitation.

Next, claim 19 requires a “plurality of client subsystems” (i.e. agents) that are “operatively coupled for communicating to” Sysdb’s mounting component. The ID established that the legacy EOS had numerous “agents”, each of which was operatively coupled to EOS’s Sysdb. See ALJ ID at 66. In the Redesign EOS, the agents – once they come into existence – receive from a kernel socket buffer the mount profiles in Sysdb by means of a socket connection between Sysdb and the agent. Arista Ruling Request at 19-20.

With respect to ProcMgr itself, as noted earlier, ProcMgr cannot mount state from Sysdb, read data from Sysdb, or write data to Sysdb. Arista Supplement I at 4. Further, ProcMgr does not use the AttrLog communications protocol that all EOS agents use to communicate with Sysdb, nor does ProcMgr have a [ ] profile, a [ ] table of its own, or access to the [ ] profile or [ ] table of any EOS agent. Id. at 4. As such, ProcMgr could not meet the client subsystem limitation of claim 19 as described above. Given the inability of both the agent and ProcMgr to act as a client subsystem, and no facts showing how their combination physically allows transaction access, there does not appear to be a conceivable way in which both together could somehow satisfy the claim limitation of a client subsystem.

Claim 19 also requires that at least one of the agents be “configured as a managing subsystem to externally manage router data.” In the legacy EOS, the ID found that when [

.] See AL ID at 66 – 67. In the Redesign EOS, it is clear that the agents – by means of having their [ ] sent through a buffer – still receive at least the very same [ ] to be the only entity who can manage the data in Sysdb. Arista Ruling Request at 19-20. As such, the Redesign EOS still has at least one agent “configured as a managing subsystem to externally manage router data” as required in claim 19.

The agents in claim 19 must also externally manage router data “upon issuing a management request” to Sysdb’s mounting component. The EOS legacy product satisfied the management registration request by having the agents send a [ ] to Sysdb that indicated [ .] See AL ID at 69-70. The ALJ determined that “router configuration data” did not require a construction. See ALJ ID at 58-59. In reaching that decision, the ID cited to the specification which described the wide range of data that could fall such an information category, as described below. See ALJ ID at 59.

The configuration information stored on the sysDB may include, for example, Internet protocol (IP) addresses, Ethernet configurations, subnet masks, default routes, protocol configuration, name server information, user and password data, access levels, and other router data as is known in the art.  U.S. Patent No. 7,162,537 at col.3, ln. 67 - col. 4, ln. 5; see also col. 6, ln. 66- col. 7, ln. 3.

The ALJ further found that [

.] See ALJ ID at 69-70. The patent further fleshes out the bounds of this request in a fairly involved manner indicating the “tuple” (or portion of Sysdb) the agent wishes to manage, whether the data is cached, how long before such cached data will time-out, and a look-up address where Sysdb can get data from the agent. See `537 patent at col.9, ln. 62 - col. 10, ln. 10. In the Redesign EOS, the agent (once the agent exists) reads the [ ] data from the buffer once a general purpose call is activated for the agent to read any data in the buffer, after an agent is made aware that there is some data waiting in the buffer. Arista Ruling Request at 20. Even if one concludes that the agent’s call is a request and that the buffer is an extension of the database subsystem, there is no router configuration information in the system call. A system call only has three parameters: the identity of the socket that the process will read, the address of the process buffer to which the data will be copied, and the maximum data that can be retrieved. Arista Supplement II at 2. Again, as stated by the Federal Circuit in Vitronics and reaffirmed in Phillips, claims must be read in light of the specification, of which they are a part, since the specification “is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term.” Phillips, 415 F.3d at 1315 (citing Vitronics, 90 F.3d at 1582); see also Standard Oil Co. v. Am. Cyanamid Co., 774 F.2d 448, 452 (Fed. Cir. 1985) (“The specification is, thus, the primary basis for construing the claims.”). Applying those authorities, the record supports a finding that no router configuration information – or any data that could fall under the broad definition of router data cited to in the specification – is contained in the general call from the agent to the buffer. As such, the Redesign EOS does not meet the “upon issuing a management request” limitation by virtue of the interaction between the agent and the buffer. In arguing that ProcMgr was not acting as a managing subsystem making a management request – as described in the claim 19 limitations above – Arista indicates that “the [ ] command does not identify or indicate any router configuration data of any kind.” Arista Ruling Request at 17. The only data appearing in the [ ] command relevant to the agent is the agent’s name, and similar to the system call there is no evidence on the record showing how the name of the agent could act as the router configuration data. Id. at 19. For instance, the record does not contain examples of agents that can write agent names as a state to Sysdb, share such information as a variable data point with other agents, or update its own local copy of data with the changed name of an agent. Further, ProcMgr is incapable of writing to Sysdb, and hence incapable of the external management that is the whole purpose of an agent. Arista Supplement I at 2, 4. Therefore, even if [ ] was a request and did include router configuration information, that information could not be something ProcMgr requests to provide external services for as ProcMgr cannot write to Sysdb to provide such services. Also, the agent once started is programmed to not issue [ ], except for the CLI agent which only has write disabled), and Sysdb is programmed to sever the connection to any agent re-programmed to issue a [ ]. As such, the Redesign EOS does not meet the “management request” claim limitation of claim 19 based on the agent’s interaction with the kernel buffer, or ProcMgr’s [ ] command to Sysdb. Therefore, the EOS Redesign does not infringe claim 19 nor any of claim 19’s dependent claims. Claims 1 and 10 also have this “management request” claim limitation through language requiring a “management registration request,” and for the same reasons, the Redesign EOS does not meet that limitation. As such, the Redesign EOS infringes neither claim 1, claim 10, nor any of those claims’ dependent claims.

Finally, the administrative record supports a finding that the Arista switches running the Redesign EOS have differences that are not insubstantial when compared, on a limitation-by-limitation basis, with the relevant patent claims such that it cannot be said that the modified switches perform “substantially the same function in substantially the same way to obtain the same result as the claim limitation.” MD Millipore Corp. v. AllPure Techs., Inc., 768 F.3d 1196, 1202 (Fed. Cir. 2014) (citation omitted). Specifically, agents in the EOS Redesign do not have the ability to send [ ], as they did in the legacy products, and more to the point, they do not send a communication to Sysdb to register for external management. Instead, ProcMgr through [ ] issues a [ ] command to Sysdb and does this before the agent, that ultimately will externally manage the corresponding router configuration data, exists. Additionally, the router configuration data, for which the agent in question seeks registration for external management, is not identified—as taught in the `537 patent—by indicating a specific node or tuple in the sysDB tree but instead through the engineering efforts to determine previously every [ ] that the agent may need or want through the “profiles” Arista has created for each agent that identify these potential [ ]. See Arista Ruling Request, Ex. A, Duda Decl. at ¶29. Accordingly, instead of the request-based process in the EOS of the legacy products in which [ ] were established ad hoc and on an as-needed basis, the EOS Redesign has moved to the static, pre-loaded approach described explained above. Accordingly, the administrative record does not contain the clear and convincing evidence necessary to determine that a modified article of a named respondent from an exclusion order performs substantially the same function in substantially the same way to obtain the same result as the claim limitation at issue that requires a client subsystem configured as a managing subsystem to issue a management request to the database subsystem in order to externally manage router data.

Arista ’s Non -Infringement Arguments For The ‘592 a nd ‘ 145 Patents

As an initial point, CBP is aware that the Commission has instituted a formal enforcement proceeding pursuant to Commission Rule 210.75(b), 19 C.F.R. § 210.75(b), based on a complaint Cisco filed on August 26, 2016, to determine whether Arista is in violation of the Commission’s cease and desist order issued on June 23, 2016. See Commission Notice, 81 Fed. Reg. 68455 (October 4, 2016). Notably, Cisco has not alleged infringement of the ’592 and ’145 patents by the EOS Redesign in its enforcement complaint, at least not as of the time of this ruling. See Complainant Cisco Systems, Inc.’s Enforcement Complaint, Doc ID 589164 at 12, n. 1 (dated August 26, 2016) (“Discovery may demonstrate that Arista’s continuing marketing and sale of its products also violates the Limited Exclusion Order and Cease and Desist Order with respect to the ’592 and ’l45 patents; Cisco reserves its right to amend this Complaint to add allegations of infringement relating to those patents.”).

Moreover, according to Arista, “[t]he design changes [in the EOS Redesign] relevant to the ’592 and ’145 patents are uncomplicated and unmistakably bring Arista’s switches into compliance.” Arista Ruling Request at 26. During the investigation, the Commission found infringement of these two patents based on functionality in the legacy products for configuring Private VLANs (“PVLANs”) with specific types of ports. Id. In response, Arista asserts that it has completely removed PVLANs from the EOS Redesign and that its customers can no longer configure the specific port types claimed in the patents. Id.

The ‘592 and ‘145 patents, the latter being a continuation of the former and both sharing the same specification, are entitled “Private VLANs.” ALJ ID at 20. As found by the ALJ during the investigation at the Commission, “[a] computer network is a system to enable communication among devices, typically computers that are connected to the network.” Id. at 19. A common form that a computer network can take is called a Local Area Network or “LAN” and the acronym “VLAN” stands for “Virtual Local Area Network,” which may be thought of as a LAN within a LAN. Id. at 19-20.

The two patents at issue (referred to as the “Private VLAN Patents”) are “directed toward mechanisms for separating users’ traffic on a networking device using port and VLAN technologies.” Id. at 20. The Private VLAN Patents overcame certain disadvantages in the prior art by providing special types of ports and VLANs for separating the traffic of users on a single LAN. Id. at 20-21. “Specifically, the Private VLAN Patents introduce three new types of VLANs (referred to in some claims as a ‘primary VLAN,’ an ‘isolated VLAN,’ and a ‘community VLAN) that interact with three new types of ports (referred to in some claims as ‘promiscuous ports,’ ‘isolated ports,’ and ‘community ports’). Id. at 21 (emphasis added). “The Private VLAN Patents teach that these new VLANs and the corresponding port types work together to separate user traffic on a LAN, while making it easy to add and manage users new to the network.” Id.

With respect to the ports identified above, the ALJ found that, in one particular embodiment of the Private VLAN Patents, “promiscuous ports receive packets from the Internet, and transmit them to user devices, such as servers, through isolated and community ports. By contrast, isolated and community ports receive packets from the user devices and transmit them out to the Internet through promiscuous ports.” Id. at 21. While an isolated port can transfer packets to a promiscuous port, it cannot do so with another isolated port. Id. at 22. In contrast with the above, a community port is part of a “community” of ports and can make transfers to any other port from in its community, while not being able (at least directly) to exchange packets with ports outside of the community. Id.

As for the VLANs, the ALJ found that a primary VLAN “connects some or all of the promiscuous ports with some or all of the isolated and community ports.” Id. at 22. For this reason, packets received at a promiscuous port from the Internet can be transferred to isolated and community ports using a primary VLAN. Id. A primary VLAN therefore serves as a one-way connection from a promiscuous port to isolated or community ports. Id. “In contrast to a primary VLAN, an isolated VLAN is a VLAN that connects the isolated ports to some or all of the promiscuous ports. Like a primary VLAN, an isolated VLAN is also a one-way connection, but in this instance is directed from the isolated ports to the promiscuous ports; an isolated VLAN cannot transfer packets to other isolated ports or community ports.” Id. “Finally, a community VLAN is used to connect the community ports to each other and to the promiscuous ports.” Id. at 23. A community VLAN, therefore, can receive packets from a community port and transfer them to other “community” ports as well as the promiscuous port but cannot send packets to an isolated port. Id.

In Arista’s view of the ALJ’s findings above, the ’592 and ’145 patents claim variants of the same invention, which involves the organization of a switch into an architecture with a “primary VLAN” containing a “promiscuous port” (i.e., a port that is enabled to communicate with all of the other ports in the switch) and two other types of “secondary VLANs” that are subordinate to the primary VLAN. See Arista Ruling Request at 26-27. The two types, referenced above, consist of “isolated” VLANs that contain “isolated ports” (i.e., ports that can communicate only with the promiscuous port of the primary VLAN, but not with any other ports) or “community” VLANs containing “community ports” (i.e., ports that can communicate with all other ports included within the same community as well as with the promiscuous port, but not any others). Id.

The nature of the claimed architecture may be illustrated as follows:




See Arista Ruling Request at 27. As shown in the figure above, the primary VLAN (illustrated by the blue lines) can communicate using every port on the switch while the community VLAN (illustrated by the green lines) can communicate with the other community ports and also with the promiscuous port. Id. at 27-28.

Prior to the redesign, the legacy products included functionality which permitted users to configure PVLANs. In particular, an Arista switch user could enter commands into Arista’s CLI, such as the one below.




See Arista Ruling Request at 29 (citing to Arista’s prior technical user guides and Ex. C, CX-0075 at p. 778).

Arista notes that the commands “vlan 25” and “private-vlan isolated primary vlan 5” would be used to configure VLAN 25 to be a secondary VLAN (of type isolated) with an associated primary VLAN of 5. See Ex. A, Duda Decl. at ¶51. The user could then see whether the VLANs had been properly configured using the “show vlan private-vlan” command which would result in the table at the bottom of the figure above, showing VLAN 5 as “Primary,” VLAN 25 as “Secondary,” and VLAN 25 as being an “isolated” type private VLAN. Id.; see also Ex. B, Instructions for Testing Arista Switches at Steps 63-72.

The ALJ, according to Arista, held that this PVLAN functionality infringed all the asserted claims of the Private VLAN Patents through the use of ports to create the primary and secondary VLANs and, following this, the ALJ then mapped each claim limitation for each asserted claim to this same functionality. See Arista Ruling Request at 29; see also ALJ ID at 172-195 (“In particular each Accused Private VLAN Product contains the elements of the claim inventions, including promiscuous ports and associated primary VLANs, isolated ports and associated isolated VLANs, and community ports and associated community VLANs.”).

Arista claims that it has removed the PVLAN feature from its switches completely and has not installed any alternative design in its place. See Arista Ruling Request, Ex. A, Duda Decl. at ¶49, 52. According to Arista, only a small percentage of Arista’s customers wanted or used the PVLAN feature and it was not integral to any other capabilities of the switch. Id. at ¶52. For this reason and based on the Commission’s finding of infringement with respect to the Private VLAN Patents, Arista contends that it has removed all PVLAN functionality without exception or replacement. Arista further argues that the removal of the PVLAN functionality is established by the screen capture below:

[

]

Describing the above, Arista points out that “if a user of Arista’s modified version of EOS attempts to configure a switch to have a primary PVLAN or secondary isolated or community VLANs, the attempt will fail and the user will be told the prior commands are [‘ ] See Arista Ruling Request, Ex. A, Duda Decl. at ¶54. Similarly, “the same is true for the [ ] command—there are no longer any PVLANs to show, and so the command fails as [ ] Id. Arista concludes that, without PVLANs, “there can be no primary VLANs, secondary VLANs, community or isolated ports, or community or isolated VLANs” and the EOS Redesign cannot be found to infringe the Private VLAN Patents.

The proffered evidence above, along with the reasonable inferences that may be drawn from the Commission’s institution of the formal enforcement proceeding without an infringement allegation of the Arista switches running the EOS Redesign with respect to the Private VLAN Patents, supports a finding that the infringing functionality has been removed and that Arista has carried its burden to establish that the articles in question are not covered by the patents at issue and therefore do not, on this basis, fall within the scope of the LEO resulting from ITC Inv. No. 337-TA-944.  HOLDING:

The Arista Redesign EOS at issue is not covered by claims 1, 2, 8-11, and 17-19 of the '537 patent; claims 6, 7, 20, and 21 of the '592 patent; or claims 5, 7, 45, and 46 of the '145 patent. Therefore, the switches in question are not within the scope of the ITC’s limited exclusion order in Investigation No. 337-TA-944, and may be entered for consumption into the United States.

This decision is limited to the specific facts set forth herein. If Arista manufactures or imports switches that differ from the embodiment described above, or if future importations vary from the facts stipulated to herein, this decision shall not be binding on CBP as provided for in 19 C.F.R. § 177.2(b)(1), (2), and (4), and § 177.9(b)(1) and (2).

Moreover, this ruling letter, if found to be in error or not in accord with the current views of CBP, may be modified or revoked by a separate interpretative ruling under Part 177 of the Customs Regulations. See 19 C.F.R. § 177.12. When CBP undertakes review to determine if an issued ruling letter is in error based on a request from a person outside of CBP, the burden to establish that the ruling letter is incorrect, either legally or factually, falls on the person seeking to have that ruling letter modified or revoked. See CBP HQ Ruling H242026 at 6 (dated June 24, 2013) (“CBP does not require a compelling reason to revoke a prior ruling, even if there has been reliance on the ruling in question. Instead, the standard for CBP modification or revocation requires establishment that the prior ruling was issued in error or that it is not in accord with the current views of the agency. See 19 C.F.R. Part 177.12(a); see also International Custom Products, 549 F. Supp. 2d [1384,] 1394-95 [(Ct. Int’l Trade, 2008)]. With this framework provided, the decision now turns to the question of whether [the person requesting revocation] has established that HQ H226615 was issued in error.”).

Modification or revocation of a CBP administrative ruling must be carried out in accordance with the notice procedures set forth in 19 C.F.R. § 177.12(b) or (c), except as otherwise provided for in § 177.12(d). Specifically, under § 177.12(b), CBP may modify or revoke an administrative ruling that has been in effect for less than 60 calendar days by simply giving written notice of the modification or revocation to the person to whom the original ruling was issued. A ruling under Part 177 is immediately effective upon its issuance unless the ruling itself provides otherwise. See 19 C.F.R. § 177.9(a) (“Generally, a ruling letter is effective on the date it is issued and may be applied to all entries which are unliquidated, or other transactions with respect to which the Customs Service has not taken final action on that date.”); see also 19 C.F.R. § 177.10(e).

However, when contemplating the issuance of an administrative ruling that would modify or revoke a prior ruling that has been in effect for 60 or more calendar days, CBP must follow the notice and comment procedures of 19 U.S.C. § 1625(c)(1), as implemented by 19 C.F.R. § 177.12(b)(1)-(3). See Int'l Custom Prods. v. United States, 748 F.3d 1182, 1185 (Fed. Cir. 2014) (“Section 1625(c)(1) requires Customs to follow multiple procedural requirements when issuing an ‘interpretive ruling or decision’ that would ‘modify . . . or revoke a prior interpretive ruling or decision which has been in effect for at least 60 days.’ In particular, Customs must publish the proposed ruling or decision in the Customs Bulletin, provide a comment period of at least 30 days after such publication, and publish the final decision in the Customs Bulletin within 30 days after the close of the comment period.”) (internal citations omitted). The effective date of a modifying or revoking ruling is governed by 19 C.F.R. § 177.12(e).

Lastly, the publication and issuance requirements set forth in 19 C.F.R. § 177.12(b) and (c) do not apply when a CBP position is “modified, revoked or otherwise materially affected by operation of law or by publication pursuant to other legal authority or by other appropriate action taken by Customs in furtherance of an order, instruction or other policy decision of another governmental agency or entity pursuant to statutory or delegated authority.” 19 C.F.R. § 177.12(d)(1).

CBP is aware that the Commission has instituted a formal enforcement proceeding pursuant to Commission Rule 210.75(b), 19 C.F.R. § 210.75(b), based on a complaint Cisco filed on August 26, 2016, to determine whether Arista is in violation of the Commission’s cease and desist order issued on June 23, 2016, with respect to the ’537 patent. See Commission Notice, 81 Fed. Reg. 68455 (October 4, 2016). The complaint confirms that the formal enforcement proceeding involves Arista switches running the re-designed version 4.16.6M of its Extensible Operating System. See Complainant Cisco Systems, Inc.’s Enforcement Complaint at 12, Doc ID 589164 (dated August 26, 2016) (“Exemplary Covered Products include the Arista switches, including at least the 7010, 7048, 7050, 7060, 7150, 7250, 7260, 7280, 7300, 7320, and 7500 series models and/or Arista EOS, including at least version 4.16.6M and later.”). As with any determination of the Commission under section 337, as amended, and Part 210 of Subchapter C in Chapter II from Title 19 of the Code of Federal Regulations, if this formal enforcement proceeding results in findings of fact or conclusions of law that conflicts with this ruling letter or is contrary to this ruling in any other way, the ruling will be modified or revoked accordingly by operation of law and CBP will carry out the agency action mandated by that determination.

Sincerely,
CHARLES R STEUART


Digitally signed by CHARLES R STEUART
DN: c=US, o=U.S. Government, ou=Department of Homeland Security, ou=CBP, ou=People, cn=CHARLES R STEUART, 0.9.2342.19200300.100.1.1=0385765165.CBP Date: 2016.11.18 19:04:51 -05'00'
Charles R. Steuart, Chief Intellectual Property Rights Branch
GLOSSARY OF TECHNICAL TERMS4

Agent: In EOS, an agent is a process that performs a specific function, is independent of other agents and subsystems, and has read or write access to state in Sysdb.

[ ]: In Arista’s redesigned EOS, [ ] is the process that establishes new socket connections with Sysdb.

[ ] Command: In Arista’s redesigned EOS, ProcMgr sends a [ ] command to [ ], before starting a new agent, to instruct [ ] to establish a socket connection to Sysdb for future use by that agent. The [ ] command includes the name of the agent that will ultimately use the socket connection. Its
purpose is not to request that Sysdb [ ] any state, and it does not specifically identify any particular state by pathname.

Mount (noun): In EOS, a mount is an ongoing relationship between Sysdb and an agent in which Sysdb sends the agent updates when Sysdb’s authoritative copy of the mounted state changes.

Mount (verb): In Arista’s EOS, mounting is the process by which an agent is given a local copy of state from Sysdb and the ability to read or (possibly) write that state, as well as a commitment from Sysdb to send the agent updates to the state. For both read and write mounts, Sysdb sends an initial copy of the state to the agent following registration (see below). In addition, for a write mount, when the agent’s local copy of the state changes, the agent sends an update back to Sysdb, allowing Sysdb to update the authoritative copy of the state (which will lead to Sysdb sending updates to any other agents that have read mounted that state).

[ ] Profile: In Arista’s redesigned EOS, a [ ] profile is a part of Sysdb’s built-in configuration that identifies the pathnames of all state that Sysdb will mount for a given agent, as well as whether the mount is a [ .]

[ ]: In Arista’s EOS, a mount request is a request sent by an agent to Sysdb that identifies specific state by pathname and specifies whether that state should be read mounted or write mounted. In Arista’s redesigned EOS, [

.]

Pathname: In Arista’s EOS, a pathname is an identifier for specific state in Sysdb. For example, /arp/virtualSubnets is the pathname for state used by the Fhrp agent.



4 This glossary of terms was included as part of Arista Supplement III. The definitions above have not necessarily been adopted by CBP and, where there is any conflict with this ruling letter, are expressly rejected. Instead, the terms have been included here mainly to provide additional information and further confirmation of the positions Arista has taken in connection with its ruling request.
Process: In Arista’s EOS, a process is a Linux process running in its own address space. Each agent, for example, is a process.

Process Manager (ProcMgr): In Arista’s EOS, Process Manager is the process that starts, stops, monitors, and restarts agents.

Registration: The '537 patent describes registration as the process of recording in the centralized database that specific data will be externally managed by a managing subsystem. As discussed in previous submissions, registration is completed in the centralized database. See, e.g., Sept. 19 Letter at 17-18; '537 patent at Fig. 5 and accompanying description.

State: In Arista’s EOS, state is a piece of data stored in Sysdb and identified by a pathname. An example of state is the temperature of the switch.

Subsystem: The '537 patent describes subsystems as “components which provide specific functions or routines provided by the routing device.” '537 patent at 1:14-18. See, discussion of “unit” below.

Sync: In Arista’s EOS, sync is the portion of the mount process that occurs after registration where Sysdb sends to an agent a copy of the data mounted by the agent.

Sysdb: In Arista’s EOS, Sysdb is the database that stores the authoritative copy of all state in EOS.

Unit: The '537 patent uses the term “unit” to refer to a component that performs a portion of a subsystem’s specific functions or routines. As explained above, the patent never refers to components of subsystems as “subsystems” and always uses other terminology, such as “unit.” For example, Figure 4 depicts an “external managing unit” in the database subsystem and a “local managing unit” in the managing subsystem. See also '537 patent at claims 21, 22. The patent defines its sysDB as the centralized database subsystem, see id. at 3:64, and explains that “sysDB further includes an external managing unit,” see id. at 4:66, 9:34-35. To the extent that the external managing unit is coupled for communication to “other subsystems,” those other subsystems are not within sysDB and instead provide router configuration data externally. See id. at 4:66-5:2; see also id. at 9:36-37.