FINDINGS OF FACT AND RULINGS OF LAW AFTER A BENCH TRIAL ON INVENTORSHIP
STEARNS, D.J.
The court held a three-day bench trial confined to a single issue: Is Peter Schulter an inventor of United States Patent No. 7,231,430 (the '430 patent)? Based on the credible testimony and exhibits offered at trial, and the stipulations of the parties, I make the following findings of fact.
FINDINGS OF FACT
Background
1. Plaintiff Egenera, Inc., is a Delaware corporation with its principal place of business in Boxborough, Massachusetts. Stipulated Facts (SF) ¶ 2.
2. On September 6, 2000, Egenera made an employment offer to Peter Schulter. SF ¶ 3. Schulter accepted and joined Egenera on October 2, 2000. SF ¶ 5.
3. On April 20, 2001, Egenera filed U.S. Provisional Application No. 60/285,296 (the '296 provisional). SF ¶ 13. Schulter is listed as an inventor on the provisional application. SF ¶ 14.
4. On January 4, 2002, Egenera filed non-provisional U.S. Patent Application No. 10/038,353 (the '353 application). SF ¶ 15. The '353 application claims priority to the '296 provisional. SF ¶ 16.
5. On June 12, 2007, the '430 patent issued from the '353 application. SF ¶ 19.
6. Upon issue, the '430 patent listed Vern Brownell, Pete Manca, Ben Sprachman, Paul Curtis, Ewan Milne, Max Smith, Alan Greenspan, Scott Geng, Dan Busby, Edward Duffy, and Schulter as the inventors. SF ¶ 20.
7. The '430 patent is directed to solving problems encountered in the manual configuration, deployment, and maintenance of enterprise and application servers, see '430 patent, col. 1, ll. 21-58, and discloses "a processing platform from which virtual systems may be deployed through configuration commands," id. col. 2, ll. 45-47. The patent sets out 4 system claims and 4 method claims.
Claim 1 is representative:
1. A platform for automatically deploying at least one virtual processing area network, in response to software commands, said platform comprising:
a plurality of computer processors connected to an internal communication network;
at least one control node in communication with an external communication network and in communication with an external storage network having an external storage address space, wherein the at least one control node is connected to the internal communication network and thereby in communication with the plurality of computer processors, said at least one control node including logic to receive messages from the plurality of computer processors, wherein said received messages are addressed to the external communication network and to the external storage network and said at least one control node including logic to modify said received messages to transmit said modified messages to the external communication network and to the external storage network;
configuration logic for receiving and responding to said software commands, said software commands specifying (i) a number of processors for a virtual processing area network (ii) a virtual local area network topology defining interconnectivity and switching functionality among the specified processors of the virtual processing area network, and (iii) a virtual storage space for the virtual processing area network, said configuration logic including logic to select, under programmatic control, a corresponding set of computer processors from the plurality of computer processors, to program said corresponding set of computer processors and the internal communication network to establish the specified virtual local area network topology, and to program the at least one control node to define a virtual storage space for the virtual processing area network, said virtual storage space having a defined correspondence to a subset of the external storage address space of the external storage network; and
wherein the plurality of computer processors and the at least one control node include network emulation logic to emulate Ethernet functionality over the internal communication network.
8. Defendant Cisco Systems, Inc., is a California corporation with its principal place of business in San Jose, California. SF ¶ 1.
9. On August 5, 2016, Egenera filed this Complaint against Cisco, asserting infringement of three patents, including the '430 patent.1 See Compl. (Dkt #1).
10. On April 28, 2017, Cisco filed an IPR petition with the PTAB objecting to the '430 patent. SF ¶ 22. In the petition, Cisco argued, inter alia, that the '430 patent was obvious over several references, including U.S. Patent No. 7,089,293 (Grosner). SF ¶ 23. According to Cisco, the Grosner patent is entitled to a priority date of November 2, 2000. SF ¶ 24.
11. Manca, Egenera's then-CEO, contacted Schulter in June and July of 2017. SF ¶ 25. Manca told Schulter that, upon review, he had concluded that the '296 provisional application was based solely on an Egenera document dated September 29, 2000. Tr. Day 1 (Schulter) at 105:17-20. Because this document predated Schulter's October 2, 2000, start date with Egenera, Manca told Schulter that he had not contributed to and was therefore not an inventor of the claims of the '430 patent. Tr. Day 1 (Schulter) at 104:7-105:20; see also Tr. Day 3 (Manca) at 91:12-24 (describing the conception analysis).
12. On August 15, 2017, Schulter signed a declaration agreeing to remove himself as an inventor of the '430 patent, stating that he "[had] been erroneously named." SF ¶ 26; JX 7 at 14.
13. Schulter did not review any documents before signing the declaration; his decision to withdraw as an inventor of the '430 patent was based solely on Manca's representations. Tr. Day 1 (Schulter) at 107:8-24.
14. Egenera responded to Cisco's IPR petition on August 16, 2017. SF ¶ 27. In its response, Egenera maintained that the claims of the '430 patent were not obvious over the alleged prior art. SF ¶ 28. Egenera also contended that Grosner was not prior art to the '430 patent because the claims of the '430 patent had been conceived by September 29, 2000 — before Grosner (and before Schulter's employment by Egenera). SF ¶ 29.
15. By September 8, 2017, all of the other inventors of the '430 patent had also signed declarations agreeing or not disagreeing with removing Schulter as an inventor of the '430 patent. SF ¶ 30. One of the inventors, Max Smith, spoke to Schulter prior to giving his assent to the removal because of his unease "related to being sure we did the right thing." Tr. Day 3 (Smith) at 61:9-20. Smith did not independently review the relevant documents. Id. at 61:21-24. Brownell, Busby, and Greenspan spoke only to Manca prior to agreeing to remove Schulter, and did not review any documents. Tr. Day 3 (Manca) at 109:23-110:20 (clip from Brownell deposition), 111:4-22 (clip from Busby deposition), 112:2-23 (clip from Greenspan deposition).
16. At that time, all of the '430 inventors (including Schulter) were represented by Egenera's counsel at Egenera's expense, and almost all were either employed by Egenera or were paid consultants for Egenera and Egenera's counsel. Tr. Day 2 (Geng) at 146:20-23 (CTO and EVP of engineering at Egenera); JX 39-40, 42 (Busby, Duffy, Greenspan were still employed by Egenera), 65-66 (Schulter joint representation and consulting agreements), 72-73 (Smith joint representation and consulting agreements), 79-84 (Brownell joint representation agreement, Sprachman joint representation and consulting agreements, Milne joint representation agreement, and Curtis joint representation and consulting agreements). At the time of the trial, Schulter still owned Egenera stock. Tr. Day 1 (Schulter) at 149:25-150:3. Smith believed that a surviving term of his employment agreement with Egenera bound him in perpetuity to assist Egenera in defending the '430 patent. Tr. Day 3 (Smith) at 63:7-17.
17. Egenera petitioned the Patent and Trademark Office (PTO) on September 11, 2017, to remove Schulter as an inventor of the '430 patent. SF ¶ 31.
18. On January 16, 2018, the PTO granted Egenera's petition and removed Schulter as an inventor of the '430 patent.2 SF ¶ 32.
19. The court issued its claim construction rulings on February 5, 2018. See Dkt #85. The court construed "logic to modify said received messages to transmit said modified messages to the external communication network and to the external storage network" as a means-plus-function limitation. Id. at 11-17. The function of the limitation is to "modify said received messages to transmit said modified received messages to the external communication network and to the external storage network." Id. at 17. The structure is "virtual LAN server 335, virtual LAN proxy 340, and physical LAN driver 345" and equivalents for messages to the external communications network, and "storage configuration logic 605" and equivalents for messages to the external storage network. Id. at 18-19. The excerpted portion of figure 3B is illustrative. Id. at 19.
20. In August of 2018, Cisco moved for summary judgment, asserting, inter alia, that the '430 patent is invalid because of the omission of Schulter as an inventor. See Dkt #141. According to Cisco's motion, Schulter conceived of the VLAN Proxy, one of the structures underlying the "logic to modify said received messages to transmit said modified messages to the external communication network" limitation. See Dkt #143 at 9-13.
21. Egenera cross-moved for summary judgment, contending, inter alia, that Schulter was not an inventor of the '430 patent. See Dkt #135. In the alternative, Egenera argued that the remedy for nonjoinder of an inventor is a correction of the patent, not its invalidation. See Dkt #162 at 18-19.
22. The court denied the cross motions on inventorship, and held that under the doctrine of judicial estoppel, having successfully persuaded the PTO to remove Schulter, Egenera could not now reinstate Schulter as an inventor of the '430 patent. See Egenera, Inc. v. Cisco Sys., Inc., 348 F.Supp.3d 99, 101-102 (D. Mass. 2018). This bench trial followed in January of 2019.
The Inventive Process
23. Egenera was founded in March of 2000 to develop a product called the Interframe platform, later renamed Bladeframe. Tr. Day 2 (Geng) at 149:2-22, 151:18-24.
24. Development of the Interframe/BladeFrame, Egenera's sole product at the time, was a highly collaborative effort based on regular meetings throughout the summer and fall of 2000. Tr. Day 2 (Geng) at 154:11-17; Tr. 3 (Manca) at 74:6-18; Tr. Day 1 (Schulter) at 84:9-17.
25. By June of 2000, Egenera had hired Sprachman, Busby, Brownell, Milne, Manca, Curtis, and Geng. JX 74.
26. In June of 2000, Milne and Curtis co-authored a document entitled "The Egenera Interframe: A New Architecture" (the June Specification). SF ¶ 6; see also JX 13.
27. The June Specification disclosed a system with "two basic modules." JX 13 at 2.
Interframe Controller modules (IFC modules) perform I/O processing and system management functions, but do not run application software. All of the external I/O [(Input/Output)] interfaces are connected to the IFC modules. Application Processor modules (AP modules) run application software, but do not contain any I/O interfaces other than the interface card for the system interconnect. Application Processors are able to perform I/O operations via a message-passing interface to the Interframe Controllers. External network interfaces on the Interframe Controllers forward incoming TCP/IP traffic to the Application Processors by examining the fields in the packet header to route the packet to the appropriate destination.
Id. (trademark designations omitted). The IFC modules connect to the outside world through "2 redundant external network interface cables (Gigabit Ethernet or equivalent) and [] 2 redundant SAN cables (Fiber Channel)." Id. at 5.
28. The June Specification lists as a "Functional Requirement"
[a] distributed network implementation that allows AP nodes with no physical network interface to utilize the network interfaces on the IFC nodes. The IFC nodes must be able to multiplex network traffic from several AP nodes onto one physical network interface, and demultiplex the incoming network traffic and send it to the appropriate AP nodes. Some packet filtering logic will be required.
Id. at 9.
29. In July of 2000, Egenera hired Greenspan, Duffy, and Smith. JX 74. At that time, with the exception of Schulter, all of the inventors of the '430 patent had been recruited. See id.
30. Smith, in his role as the Chief Architect, see Tr. Day 3 (Smith) at 33:8-10, authored a document entitled "Egenera Interframe I/O Architecture" (The September Specification), dated September 29, 2000. SF ¶ 7; see also JX 15.
31. The September Specification memorialized the then-current state of the Interframe architecture and set out working goals for the team during Smith's upcoming month-long vacation. JX 23 at 12, Tr. Day 3 (Smith) at 34:10-35:9, Tr. Day 3 (Manca) at 74:25-76:8.
32. The September Specification, in the "Overview" section, explained that "Application nodes of an Egenera Interframe system have none of the conventional I/O devices usually found on personal computers[.]... Instead, they have only two 112 megabyte/second Giganet connections, one to each of the Interframe's two Giganet switches, through which connections may be established to all other nodes of the Interframe." JX 15 at 1. "The two Interframe controller nodes perform all actual I/O on behalf of the entire system." Id.
[T]he Interframe administrator can configure simulated Ethernet interfaces on specific application nodes, together with simulated connections among them or to a simulated router for interconnecting to the external network. When an application node requests transmission of a network packet, the network driver in the node's operating system kernel determines whether the packet is destined for another application node within the Interframe or for the external network. Packets destined for another application node are sent directly to that node through the Interframe's Giganet switch. Packets destined for the external network are forwarded through the Giganet switch to one of the Interframe controller nodes, where I/O logic forwards the packet out onto the actual external network interface. Inbound packets arriving from the external network are routed by I/O logic on the Interframe controller node through the Interframe's Giganet switch to the proper application node, where the network driver in that node's operating system kernel in turn delivers them to their ultimate recipient.
Id. at 1-2.
33. In the "Network I/O" section, the September Specification states that
[a]t the present time, the architecture does not permit the simulation of bridges or routers in this simulated network topology, other than the four edge routers which interface to the high-speed external network. Also at this time, the architecture does not permit the simulation of an Ethernet segment originating within the Egenera Interframe system and terminating outside the Interframe. Network traffic destined external to the Interframe must be routed through one of the four simulated routers.
JX 15 at 3.
34. In the subsection "Giganet Internal Network" — "Simulated Ethernet I/O over Giganet," the September Specification explains that
[s]imulation of an Ethernet segment connecting two nodes of the Egenera Interframe is accomplished by establishing a redundant Virtual Interface connection pair between those nodes through the Giganet switch.... To the Ethernet driver in the operating system kernel, the redundant Virtual Interface connection pair looks exactly like a physical Ethernet network interface card. At the time our Giganet driver code establishes the Virtual Interface pair, it assigns to the pair an Ethernet 48-bit Media Access Control (MAC) address, much as a hardware manufacturer would have provided for a real card. Our simulated MAC addresses, however, need only be unique within a single Egenera Interframe system, as none of our simulated Ethernet segments depart the confines of the system. The format of a simulated MAC address is (to be specified, but will include the node number, a Virtual Interface connection number, and a special code reserved by the IETF for designating private MACs). The simulated MAC addresses allow the Ethernet driver to use the normal Address Resolution Protocol (ARP) to construct routing tables for the kernel's Internet Protocol (IP) stack.
JX 15 at 6.
35. In the subsection "Giganet External Network" — "Simulated Routers," the September Specification explains that
[a]ll the external network traffic generated by the application nodes must be routed through the four Gigabit Ethernet interfaces on the Interframe controller nodes. Application nodes have no other access to the external network. In order for an application node to access the external network, the Egenera administrator must configure a simulated network interface card on the node and configure simulated cabling between that card and a simulated router on an Interframe controller node. The administrator must then configure routing rules for that router which will determine how incoming and outgoing network traffic applicable to that node is handled by the router. The four simulated routers are a resource shared by all application nodes, and no individual application node can be allowed to completely or independently specify all the routing rules.
JX 15 at 8. An immediately following parenthetical flags the "[n]eed to specify more exactly the form of the routing rules, how and by whom they are defined, and what rules are legal." Id.
36. Schulter joined Egenera on October 2, 2000, and took over the design of the network modules of the Interframe after Smith left on vacation. Tr. 3 (Smith) at 48:23-49:6.
37. At the time Schulter joined Egenera, he had sixteen years of experience working with various networking standards. Tr. Day 1 (Schulter) at 83:4-9. According to his September 2001 employee review, Schulter's "breadth and depth of experience in this area is unparalleled in the organization. [He] essentially trained a significant portion of the group in many of the key concepts of networking like routing, broadcast domains, bridges and VLANS." JX 58 at 1.
38. The same review describes Schulter as
the key designer and architect for networking on the Bladeframe.... H[is] contribution did not just include the design and architecture, [Schulter] also wrote almost the entire networking implementation — this included the VeRN server, the arp server, the veth drive, vlan support, service cluster support, fail-over and load balancing support, MAC address generation, DHCP support, network security and routing just to name a few.
JX 58 at 1; see also Tr. Day 1 (Geng) at 62:17-23.3 Schulter's "ability to instantly contribute to the product architecture was a great asset for the company." JX 58 at 2. "Within two weeks of arriving at Egenera, he had written an architecture document for the networking subsystem." Id.
39. Schulter completed the first two drafts of the document called "Interframe Network Architecture" on October 9 and October 17, 2000, respectively. SF ¶¶ 9-10.
40. The third draft of "Interframe Network Architecture" was dated November 7, 2000 (November Specification). SF ¶ 11; see also JX 22.
41. The November Specification explains that
[a] virtual LAN in an Interframe is the logical equivalent to a physical network. A virtual LAN will provide the necessary connectivity between application processors, and between application processors and the outside network connections. Because virtual LANs are assembled by interconnecting Interframe components (both hardware and software) with virtual circuits to provide the necessary connectivity and management, it will be possible to create a virtually unlimited number of VLANs. Each VLAN represents single broadcast domain. A VLAN can be a "local" VLAN that is private to the Interframe and does not allow any direct external traffic flow, or an "open" VLAN that allows unrestricted traffic flow between the internal VLAN members and an external network.
JX 22 at 7.
42. The November Specification further explains that
[t]he VLAN ARP [(Address Resolution Protocol)] server is the central service that controls and manages the VLANs. The VLAN ARP service provides all the Giganet specific VI management necessary to create IP connectivity between applications processors, or between application processors and the outside world.
The VLAN ARP Server is primarily a layer 2 bridge that serves to relay packets between connected devices within the broadcast domain. That is, it will function primarily as a data link layer bridge, but it will still require some knowledge of the layer 3 (IP) configuration. This will be required for efficient movement of packets between the internal nodes and an external network, and for establishing the physical connections between internal nodes. To do this, the VLAN ARP Server will also have to intercept ARP requests and replies so that it can manage both the 2 and layer 3 connectivity.
JX 22 at 15.
When the VLAN ARP Server receives an ARP request from an external node it will relay the request to all internal nodes. The correct node will then compose the reply and send the reply back to the requestor through the VLAN Server. The VLAN Proxy will take care of any MAC address translation on outgoing requests.
Id. at 21.
43. The November Specification further states that the role of the VLAN Proxy is
the basic co-ordination of the physical network resources among all the application processors that have virtual interfaces to the physical network. It's [sic] primary function is to bridge the internal VLANs to the external network by converting MAC addresses between those of the internal (Giganet based MACs) and the external (Gigabit Ethernet MAC). It will also serialize access to the physical device through a transmission queue, and co-ordinate the allocation and removal of MAC addresses, especially multicast addresses, on the physical network device. For packets arriving from the outside world, it will work along with the packet filter to move packets to the appropriate ARP server for relay to the correct internal node(s).
When the LAN Proxy receives any outgoing ARP packet from a VLAN ARP server, it replace [sic] the internal Giganet based MAC address with the MAC address of the physical Ethernet device as the source MAC address. The source IP address of the internal node will not be changed. It will then send this packet to the physical Ethernet device for transmission.
When the VLAN Proxy receives any incoming ARP packet it hand [sic] the packet to the VLAN ARP server to which it is attached. The VLAN ARP Server will then perform normal ARP processing on the packet.
When the VLAN Proxy receives an outgoing packet, it will replace the source MAC address with that of the physical Ethernet interface. It will then queue the packet to the physical Ethernet driver.
When an IP packet arrives, the IP address will be extracted and the packet will be given to the appropriate VLAN ARP server to relay to the correct internal node.
JX 22 at 21-22.
44. The November Specification illustrates the Interframe network architecture as shown in the following schematic.4 JX 22 at 32.
45. During the week ending November 17, 2010, Smith returned from vacation and "spent a lot of time with [] Schulter to understand his proposed network I/O architecture." JX 23 at 42.
46. Through the week ending December 1, 2000, Smith "continued studying [Schulter]'s network I/O architecture proposal, and participated in its second review meeting. Again the review was not completed, and we will reconvene it again next Tuesday. We are continuing to make good progress in converging on a design we feel good about." JX 23 at 50.
47. In the week ending December 8, 2010, Smith "participated in the final review session of [Schulter]'s network I/O architecture. We feel that we have converged on a good design." JX 23 at 56.
The Patent Process
48. When Egenera filed the '353 application on January 4, 2002, SF ¶ 15, the specification incorporated much of the November Specification's description of the VLAN Proxy.
'353 Application, JX 3 at 31-32 Nov. Specification, JX 22 at 21-22
Virtual LAN Proxy 5.2 The LAN Proxy
The virtual LAN Proxy 430 The LAN Proxy performs the basic
performs the basic coordination of co-ordination of the physical
the physical network resources network resources among all the
among all the processors that have application processors that have
virtual interfaces to the external virtual interfaces to the physical
physical network 125. It bridges network. It's [sic] primary function
virtual LAN server 335 to the is to bridge the internal VLANs to
external network 125. When the the external network by converting
external network 125 is running in MAC addresses between those of the
filtered mode the Virtual LAN Proxy internal (Giganet based MACs) and
430 will convert the internal virtual the external (Gigabit Ethernet
MAC addresses from each node to MAC). It will also serialize access to
the single external MAC assigned to the physical device through a
the system 100. When the external transmission queue, and co-ordinate
network 125 is operating in the allocation and removal
unfiltered mode no such MAC of MAC addresses, especially
translation is required. The Virtual multicast addresses, on the physical
LAN Proxy 430 also performs network device. For packets
insertion and removal of IEEE arriving from the outside world, it
802.lQ Virtual LAN ID tagging will work along with the packet filter
information, and demultiplexing to move packets to the appropriate
packets based on their VLAN Ids. It ARP server for relay to the correct
also serializes access to the physical internal node(s).
Ethernet interface 129 and co-ordinates
the allocation and removal When the LAN Proxy receives any
of MAC addresses, such as multicast outgoing ARP packet from a VLAN
addresses, on the physical network. ARP server, it replace [sic] the
internal Giganet based MAC address
When the external network 125 is with the MAC address of the
running in filtered mode and the physical Ethernet device as the
virtual LAN Proxy 430 receives source MAC address. The source IP
outgoing packets (ARP or address of the internal node will not
otherwise) from a virtual LAN server be changed. It will then send this
335, it replace [sic] the internal packet to the physical Ethernet
format MAC address with the MAC device for transmission.
address of the physical Ethernet
device 129 as the source MAC
address. When the External When the VLAN Proxy receives any
Network 125 is running in incoming ARP packet it hand [sic]
unfiltered mode no such the packet to the VLAN ARP server
replacement is required. to which it is attached. The VLAN
ARP Server will then perform
When the virtual LAN Proxy 430 normal ARP processing on the
receives incoming ARP packets, it packet. When the VLAN Proxy
moves the packet to the virtual LAN receives an outgoing packet, it will
server 335 which handles the packet replace the source MAC address
and relays the packet on to the with that of the physical Ethernet
correct destination(s). If the ARP interface. It will then queue the
packet is a broadcast packet then the packet to the physical Ethernet
packet is relayed to all internal driver.
nodes on the Virtual LAN. If the
packet is a unicast packet the packet When an IP packet arrives, the IP
is sent only to the destination node. address will be extracted and the
The destination node is determined packet will be given to the
by the IP address in the ARP packet appropriate VLAN ARP server to
when the External Network 125 is relay to the correct internal node.
running in filtered mode, or by the
MAC address in the Ethernet header
of the ARP packet (not the MAC
address is the ARP packet).
49. Likewise, the '353 application included figures nearly identical to the illustration of network components in the November Specification.
50. The original claims of the '353 application did not recite the "logic to modify" limitation. See JX 3 at 48-52.
51. The PTO three times rejected Egenera's pending claims as anticipated by prior art. See JX 3 at 112-115 (November 2005 rejection), 153-155 (June 2006 rejection); and 183-184 (October 2006 rejection).
52. After each rejection, Egenera amended the claims, but did not add the "logic to modify" limitation until the February 2007 Supplemental Amendment. See JX 3 at 125-129 (January 2006 claims); 142-146 (March 2006 claims); 162-172 (September 2006 claims); 187-191 (January 2007 claims); 204-205 (February 2007 claims).
53. In the Supplemental Amendment, Egenera's remarks were directly solely the "logic to modify" limitation. See JX 3 at 209. Egenera identified four sections of the specification as supporting the functionality of modifying messages destined for the external communications network; these included the Virtual LAN Proxy section that mirrored the November Specification. Id. According to the remarks, the VLAN Proxy "will convert the internal virtual MAC addresses from each node to the single external MAC addresses; it also inserts IEEE 802.1Q virtual LAN ID tagging information." Id.
54. Egenera did not disclose to the PTO any prior art relevant to the addition of the "logic to modify" limitation. Tr. Day 1 (Schulter) at 159:9-13; see also JX 3 at 203-210.
55. On April 11, 2007, the PTO issued a Notice of Allowability. JX 3 at 218.
State of Networking Art and the "Logic to Modify" Structures
56. Because Egenera chose to use a Giganet-based circuit-switching internal network, its internal protocols5 are incompatible with the protocols of Ethernet-based external pack-switching networks. Tr. Day 2 (Jeffay) at 20:13-21. Consequently, some mechanism was necessary to facilitate communication between internal and external networks. Tr. Day 3 (Manca) at 83:20-84:6.
57. A router could perform the translation between the Egenera internal network and the Ethernet external network. Tr. Day 3 (Manca) at 84:7-8.
58. The September Specification proposed a "simulated router" as the interface between the internal and external networks. JX 15 at 1, 3, 8.
59. Others in the art in the 2000-2001 time period working on ways to address the same problem also adopted traditional VLAN switch router-like solutions. Tr. Day 3 (Jones) at 140:13-22.
60. A router is a layer 3 device.6 Tr. 2 (Jeffay) at 41:9-12; Tr. 1 (Schulter) at 143:2-9.
61. In the November Specification, for an internal message to reach the external network, it must make its way through the VLAN ARP Server (later renamed the VLAN Server in the '340 patent), the VLAN Proxy, and the physical LAN drivers, in that order. JX 22 at 21-22, 32.
62. In the fall of 2000, "VLAN Server" and "VLAN Proxy" were not well-known structures or commonly used networking terms. Tr. Day 1 (Schulter) at 98:7-99:6 ("There were no other VeRNs out there."); Tr. Day 2 (Jeffay) at 14:2-12, 27:11-12. Egenera's chief architect, Smith, had not heard of a "virtual LAN server" or a "virtual LAN proxy" prior to his work at Egenera. Tr. Day 3 (Smith) at 58:21-24.
63. The VLAN Server of the '430 patent
effectively act[s] as a data link layer bridge in that it moves packets between the external Ethernet driver 345 and internal processors and performs no IP processing. However, unlike like [sic] a data link layer bridge, the server cannot always rely on distinctive layer two addresses from the external network to internal nodes and instead the connection may use layer 3 (IP) information to make the bridging decisions.
'430 patent, col. 15, ll. 15-23; see also JX 22 at 15 ("The VLAN ARP Server is primarily a layer 2 bridge that serves to relay packets between connected devices within the broadcast domain. That is, it will function primarily as a data link layer bridge, but it will still require some knowledge of the layer 3 (IP) configuration.").
64. A data link layer bridge is a device that ordinarily operates only at layer 2. Tr. 2 (Jeffay) at 28:13-22; see also Tr. 3 (Geng) at 27:21-25.
65. Because it can view and access layer 3 IP information, the VLAN Server of the '430 patent is not a standard data link layer bridge. See Tr. Day 1 (Schulter) at 94:2-12 (agreeing that the VLAN Server was "special purpose"); 96:23-25 (not "an off-the shelf component"). Schulter created the VLAN Server by combining and modifying different aspects of numerous existing standards. Id. at 97:1-98:6.
66. Schulter chose to use a modified data link layer bridge in the Interframe/Bladeframe because it minimized latency and was faster and more efficient than routing at layer 3. Tr. Day 1 (Schulter) at 92: 4-7, and 92:23-93:6. "[Schulter]'s idea to implement a bridge at the data link layer to minimize latency and to use a large packet size for internal traffic has been a resounding win for performance." JX 58 at 3.
67. In the 2000 time period, a person of ordinary skill in networking would have understood a "proxy" to refer to "an intermediary device between two elements that does something on behalf of one element," Tr. Day 1 (Schulter) at 121:23-25, often a go-between representing computers on an internal network to an external network, presenting a single network address to the external network. Id. at 124:9-22; JX 64 at 363.
68. The VLAN Proxy "convert[s] the internal virtual MAC address from each node to the single external MAC address assigned to the system 100." '430 patent, col. 18, ll. 42-44. The VLAN Proxy did not present a single network IP address to the external network. Tr. Day 1 (Schulter) at 156:19-24.
69. In addition to MAC address conversion, the VLAN Proxy "also performs insertion and removal of IEEE 802.1Q Virtual LAN ID tagging information, and demultiplexing packets based on their VLAN Ids." '430 patent, col. 18, ll. 47-49. The manipulation of IEEE 802.1Q Virtual LAN IDs enables the Interframe/Bladeframe-specific conception of VLAN to extend outside the system and interoperate with external VLANS compliant with the IEEE 802.1Q standard. Tr. Day 2 (Jeffay) at 29:18-30:23, 44:20-45:5.
70. A "garden variety" proxy in the fall of 2000 would not perform the functions of MAC address translation and VLAN ID tagging. Tr. Day 2 (Jeffay) at 30:24-31:4. The VLAN Proxy is "a custom solution to a fairly unique problem they had in the design of this system." Id. at 31:5-7. As late as July of 2001, drafts of Egenera's BladeFrame Administrator's Guide characterized the VLAN Proxy as "mysterious." JX 60 at 1-21; JX 61 at 1-21.
71. Placing the VLAN Proxy as a gateway between the physical drivers and the VLAN Server "prevents the control node from using the external connection in any way that interfere with the operation of the virtual LANs and improves security and isolation of user data, i.e., an administrator may not `sniff' any user's packets." '430 patent, col. 19, ll. 24-28.
72. The tripartite structures illustrated in figure 3B of the '430 patent — that messages from the Interframe/Bladeframe platform must pass through the VLAN Server, the VLAN Proxy, and physical LAN drivers, in that order, to reach the external network — was not known in the fall of 2000. Tr. Day 2 (Jeffay) at 14:2-12; Tr. Day 3 (Jones) at 140:14-22; JX 58 at 3 (characterizing Schulter's "virtualization of network resources [as] a leading edge design").
73. Smith agreed that nothing in his September Specification resembles the VLAN Proxy section of the November Specification or of the '430 patent. Day 2 (Jeffay) at 46:18-22 (Smith deposition clip).
RULINGS OF LAW
74. A patent is presumed valid. 35 U.S.C. § 282. A defendant must meet "the high bar" of "the clear and convincing standard ... to rebut the presumption of validity." Commil USA, LLC v. Cisco Sys., ___ U.S. ___, 135 S.Ct. 1920, 1929, 191 L.Ed.2d 883 (2015).
75. Failure to name all of the correct inventors of a claimed invention "renders a patent invalid." In re VerHoef, 888 F.3d 1362, 1365 (Fed. Cir. 2018) (citation omitted). A party seeking to invalidate a patent for nonjoinder "must meet the heavy burden of proving its case by clear and convincing evidence." Nartron Corp. v. Schukra U.S.A., Inc., 558 F.3d 1352, 1356 (Fed. Cir 2009) (citation omitted).
76. "Inventorship is a question of law" premised on factual findings. Vapor Point LLC v. Moorhead, 832 F.3d 1343, 1348 (Fed. Cir. 2016). The "determination of whether a person is a joint inventor is fact specific and no bright-line standard will suffice in every case." Falana v. Kent State Univ., 669 F.3d 1349, 1357 (Fed. Cir. 2012).
77. A person is "a joint inventor only if he contributes to the conception of the claimed invention." Eli Lilly & Co. v. Aradigm Corp., 376 F.3d 1352, 1359 (Fed. Cir. 2004).
Conception is the touchstone of inventorship, the completion of the mental part of invention. It is "the formation in the mind of the inventor, of a definite and permanent idea of the complete and operative invention, as it is hereafter to be applied in practice." Conception is complete only when the idea is so clearly defined in the inventor's mind that only ordinary skill would be necessary to reduce the invention to practice, without extensive research or experimentation.
Burroughs Wellcome Co. v. Barr Labs., Inc., 40 F.3d 1223, 1227-1228 (Fed. Cir. 1994) (citaitons omitted).
78. "An idea is definite and permanent when the inventor has a specific, settled idea, a particular solution to the problem at hand, not just a general goal or research plan he hopes to pursue." In re VerHoef, 888 F.3d at 1366 (emphasis in original) (citation omitted).
79. For a joint invention,
each of the joint inventors need not "make the same type or amount of contribution" to the invention. Rather, each needs to perform only a part of the task which produces the invention. On the other hand, one does not qualify as a joint inventor by merely assisting the actual inventor after conception of the claimed invention. One who simply provides the inventor with well-known principles or explains the state of the art without ever having "a firm and definite idea" of the claimed combination as a whole does not qualify as a joint inventor.... Furthermore, a co-inventor need not make a contribution to every claim of a patent. A contribution to one claim is enough. Thus, the critical question for joint conception is who conceived, as that term is used in the patent law, the subject matter of the claims at issue.
Ethicon, Inc. v. U.S. Surgical Corp., 135 F.3d 1456, 1460 (Fed. Cir. 1998) (citations omitted).
80. "The contributor of any disclosed means of a means-plus-function claim element is a joint inventor as to that claim." Winbond Elecs. Corp. v. Int'l Trade Comm'n, 262 F.3d 1363, 1372 (Fed. Cir. 2001), quoting Ethicon, 135 F.3d at 1463, corrected on unrelated grounds, 275 F.3d 1344.
81. "Because [conception] is a mental act, courts require corroborating evidence of a contemporaneous disclosure that would enable one skilled in the art to make the invention." Burroughs Wellcome, 40 F.3d at 1228.
82. Because inventorship is a question of law premised on contemporaneous corroboration of conception, the court rejects Egenera's suggestion that an alleged inventor's disclaimer is by itself dispositive. See Egenera's Proposed Findings of Fact and Conclusions of Law, Dkt #218 ¶ 7.
ULTIMATE FINDINGS OF FACT AND RULINGS OF LAW
83. The evidence clearly and convincingly demonstrates that Schulter is an inventor of the '430 patent. Schulter conceived of the tripartite structure — the VLAN Server connected to the VLAN Proxy connected to physical LAN drivers — underlying the "logic to modify" claim limitation. See Winbond, 262 F.3d at 1372.
a. Of the Egenera team, Schulter was the most experienced in networking and at the time, Egenera considered him "the key designer and architect for networking on the Bladeframe." Findings of Fact (FOF) ¶¶ 37-38.
b. Schulter's November Specification is the earliest reference documenting the tripartite structure underlying the "logic to modify" claim limitation. FOF ¶¶ 48-49, 73.
c. Schulter designed the network I/O architecture of the November Specification while Smith was away on a month-long vacation. FOF ¶¶ 36, 45.
d. Smith's September Specification does not corroborate the conception of the tripartite structure such that a person of ordinary skill in the art would be able to implement the structures. See Burroughs Wellcome, 40 F.3d at 1228. Smith proposed a single structure — a "simulated router" — as the interface between the internal Interframe/Bladeframe network and external Ethernet networks. FOF ¶ 35. Smith's September Specification expressly "[did] not permit the simulation of bridges ... other than the four edge routers which interface to the high-speed external network," id. ¶ 33, whereas the VLAN Server was primarily a layer 2 data-link bridge, id. ¶ 42. Nothing in the September Specification resembled the VLAN Proxy. Id. ¶ 73. When Egenera added the "logic to modify" limitation during the prosecution of the '430 patent, it pointed to Schulter's VLAN Proxy, inter alia, as the support for modification of messages destined for the external communications network. Id. ¶ 53.
e. The tripartite structure was not "simply a reduction to practice of [Smith]'s broader concept" of a "simulated router." Ethicon, 135 F.3d at 1463. According to contemporary documentation, Smith, after returning from vacation, spent several weeks studying and trying to understand Schulter's new network I/O proposal. FOF ¶¶ 45-46. While Smith's "simulated router" was a layer 3 solution, id. ¶ 60, the VLAN Server was primarily a layer 2 bridge, id. ¶ 42. Schulter chose a data-link bridge over a router because it was more efficient and minimized latency. Id. ¶ 66. Likewise, the September Specification "[did] not permit the simulation of an Ethernet segment originating within the Egenera Interframe system and terminating outside the Interframe," id. ¶ 33, whereas the VLAN Proxy's ability to manipulate IEEE 802.1Q Virtual LAN ID tags enabled the internal VLANS to interoperate with external VLANS, id. ¶ 69. Interposing the VLAN Proxy between the physical LAN drivers and the VLAN Server also improved system security.7 Id. ¶ 71.
f. Schulter's tri-partite structure did not simply reflect "well-known principles or [] the state of the art." Ethicon, 135 F.3d at 1460. Others in the same timeframe adopted traditional solutions similar to the "simulated router" of the September Specification. FOF ¶ 59. VLAN Server and VLAN Proxy were not common networking components or terms at the time of the invention. Id. ¶ 62. The tripartite structure was a custom solution created by combining and modifying aspects from many existing standards, did not include "off-the shelf" components, and was unique at the time of its creation. Id. ¶¶ 65, 62, 59, 70. At the time, Egenera hailed Schulter's network virtualization as a "leading edge design." Id. ¶ 72. Drafts of the Egenera's BladeFrame Administrator's Guide characterized the VLAN Proxy as "mysterious." Id. ¶ 70. Egenera also did not submit any prior art to the PTO in connection with its amendment adding the "logic to modify" limitation. Id. ¶ 54.
g. The court does not credit Schulter's and the other inventors' post-hoc protestations that Schulter did not jointly conceive the '430 patent. Contemporary records reflect that it was Schulter who conceived of the tripartite structure underlying the "logic to modify" limitation. FOF ¶ 83a-f. The inventors' interests are aligned with Egenera. Id. ¶¶ 11, 16. The inventors' historical revisionism was precipitated by an attempt to swear behind the prior art raised in the IPR. Id. ¶¶ 10-17. None of the inventors other than Manca, who served as Egenera's CEO at the time, reviewed any of the relevant documents before agreeing to join the campaign to remove Schulter as an inventor. Id. ¶¶ 13, 15. Smith felt unease over whether what they were doing was right, but believed he was obliged by his employment contract with Egenera to defend the '430 patent. Id. ¶¶ 15-16.
84. Because Egenera is foreclosed from reinstating Schulter as an inventor, Egenera, 348 F.Supp 3d at 101-102, and the '430 patent fails to name all of the correct inventors by omitting Schulter, the '430 patent is invalid, In re VerHoef, 888 F.3d at 1365.
ORDER
The Clerk will enter judgment for Cisco and close the case.
SO ORDERED.
