Secure Axcess L.L.C. v. HP Enterprise Services, LLC, No. 6:2015cv00208 - Document 107 (E.D. Tex. 2016)

Court Description: MEMORANDUM OPINION AND ORDER. The Court ADOPTS the claim constructions as set forth in this Order. Signed by Magistrate Judge K. Nicole Mitchell on 11/07/16. (mll, )

Download PDF
Secure Axcess L.L.C. v. HP Enterprise Services, LLC Doc. 107 IN THE UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF TEXAS TYLER DIVISION SECURE AXCESS LLC, Plaintiff, v. HP ENTERPRISE SERVICES, LLC, Defendant. § § § § § § § § § § § CASE NO. 6:15-CV-208-RWS-KNM MEMORANDUM OPINION AND ORDER This Memorandum Opinion construes the disputed claim terms in United States Patent Nos. 6,172,990 (“the ’990 Patent”) and 6,108,713 (“the ’713 Patent”), asserted in this suit by Plaintiff Secure Axcess LLC. On July 21, 2016, the parties presented oral arguments on the disputed claim terms at a Markman hearing. Based on the analysis stated herein, the court resolves the parties’ claim construction disputes and ADOPTS the constructions set forth below. BACKGROUND Plaintiff Secure Axcess LLC (“Secure Axcess”) alleges that HP Enterprise Services, LLC’s (“HP”) network switches and controllers infringe the two asserted patents. The patentsin-suit generally relate to programmable network components. APPLICABLE LAW Claim Construction “It is a ‘bedrock principle’ of patent law that ‘the claims of a patent define the invention to which the patentee is entitled the right to exclude.’” Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc) (quoting Innova/Pure Water Inc. v. Safari Water Filtration Sys., 1 Dockets.Justia.com Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). The Court examines a patent’s intrinsic evidence to define the patented invention’s scope. Id. at 1313–1314; Bell Atl. Network Servs., Inc. v. Covad Commc’ns Group, Inc., 262 F.3d 1258, 1267 (Fed. Cir. 2001). Intrinsic evidence includes the claims, the rest of the specification, and the prosecution history. Phillips, 415 F.3d at 1312–13; Bell Atl. Network Servs., 262 F.3d at 1267. The Court gives claim terms their ordinary and customary meaning as understood by one of ordinary skill in the art at the time of the invention. Phillips, 415 F.3d at 1312–13; Alloc, Inc. v. Int’l Trade Comm’n, 342 F.3d 1361, 1368 (Fed. Cir. 2003). Claim language guides the Court’s construction of claim terms. Phillips, 415 F.3d at 1314. “[T]he context in which a term is used in the asserted claim can be highly instructive.” Id. Other claims, asserted and un-asserted, can provide additional instruction because “terms are normally used consistently throughout the patent.” Id. Differences among claims, such as additional limitations in dependent claims, can provide further guidance. Id. “[C]laims ‘must be read in view of the specification, of which they are a part.’” Id. (quoting Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995), aff’d, 517 U.S. 370, 116 S.Ct. 1384, 134 Led.2d 577 (1996)). “[T]he 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.’” Id. (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)); see also Teleflex, Inc. v. Ficosa N. Am. Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). In the specification, a patentee may define his own terms, give a claim term a different meaning than the term would otherwise possess, or disclaim or disavow the claim scope. Phillips, 415 F.3d at 1316. Although the Court generally presumes that terms possess their 2 ordinary meaning, this presumption can be overcome by statements of clear disclaimer. See SciMed Life Sys., Inc. v. Advanced Cardiovascular Sys., Inc., 242 F.3d 1337, 1343-44 (Fed. Cir. 2001). This presumption does not arise when the patentee acts as his own lexicographer. See Irdeto Access, Inc. v. EchoStar Satellite Corp., 383 F.3d 1295, 1301 (Fed. Cir. 2004). The specification may also resolve ambiguous claim terms “where the ordinary and accustomed meaning of the words used in the claims lack sufficient clarity to permit the scope of the claim to be ascertained from the words alone.” Teleflex, Inc., 299 F.3d at 1325. For example, “[a] claim interpretation that excludes a preferred embodiment from the scope of the claim ‘is rarely, if ever, correct.” Globetrotter Software, Inc. v. Elam Computer Group Inc., 362 F.3d 1367, 1381 (Fed. Cir. 2004) (quoting Vitronics Corp., 90 F.3d at 1583). But, “[a]lthough the specification may aid the court in interpreting the meaning of disputed language in the claims, particular embodiments and examples appearing in the specification will not generally be read into the claims.” Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir. 1988); see also Phillips, 415 F.3d at 1323. The prosecution history is another tool to supply the proper context for claim construction because a patentee may define a term during prosecution of the patent. Home Diagnostics Inc. v. LifeScan, Inc., 381 F.3d 1352, 1356 (Fed. Cir. 2004) (“As in the case of the specification, a patent applicant may define a term in prosecuting a patent”). The well- established doctrine of prosecution disclaimer “preclud[es] patentees from recapturing through claim interpretation specific meanings disclaimed during prosecution.” Omega Eng’g Inc. v. Raytek Corp., 334 F.3d 1314, 1323 (Fed. Cir. 2003). The prosecution history must show that the patentee clearly and unambiguously disclaimed or disavowed the proposed interpretation during prosecution to obtain claim 3 allowance. Middleton Inc. v. 3M Co., 311 F.3d 1384, 1388 (Fed. Cir. 2002); see also Springs Window Fashions LP v. Novo Indus., L.P., 323 F.3d 989, 994 (Fed. Cir. 2003) (“The disclaimer . . . must be effected with ‘reasonable clarity and deliberateness.’”) (citations omitted). “Indeed, by distinguishing the claimed invention over the prior art, an applicant is indicating what the claims do not cover.” Spectrum Int’l v. Sterilite Corp., 164 F.3d 1372, 1378–79 (Fed. Cir. 1988) (quotation omitted). “As a basic principle of claim interpretation, prosecution disclaimer promotes the public notice function of the intrinsic evidence and protects the public’s reliance on definitive statements made during prosecution.” Omega Eng’g, Inc., 334 F.3d at 1324. Although “less significant than the intrinsic record in determining the legally operative meaning of claim language,” the Court may rely on extrinsic evidence to “shed useful light on the relevant art.” Phillips, 415 F.3d at 1317 (quotation omitted). Technical dictionaries and treatises may help a court understand the underlying technology and the manner in which one skilled in the art might use claim terms, but such sources may also provide overly broad definitions or may not be indicative of how the term is used in the patent. Id. at 1318. Similarly, expert testimony may aid the Court in determining the particular meaning of a term in the pertinent field, but “conclusory, unsupported assertions by experts as to the definition of a claim term are not useful.” Id. Generally, extrinsic evidence is “less reliable than the patent and its prosecution history in determining how to read claim terms.” Id. ANALYSIS I. Agreed Terms The parties have submitted the following agreements (Doc. No. 85, Ex. A): Term Agreed Construction “a network layer” (’990 Patent) “a layer responsible for routing data between nodes in a network, and for 4 initiating, maintaining and terminating a communication link between users connected to the nodes” “a transport layer” (’990 Patent) “a layer responsible for performing data transfers within a particular level of service quality” “a presentation layer” (’990 Patent) “a layer responsible for translating, converting, compressing and decompressing data being transmitted across a medium” “an application layer” (’990 Patent) “a layer that provides users with suitable interfaces for accessing and connecting to a network” In light of the parties’ agreements on the proper construction of these terms, the Court hereby ADOPTS these constructions. II. Disputed Terms in the 990 Patent1 The ’990 Patent, titled “Media Access Control Micro-RISC Stream Processor and Method for Implementing the Same,” was filed on November 12, 1997, and issued on January 9, 2001. The Abstract states: Disclosed are methods and apparatus for processing packet data received from a physical layer. The processing is performed in-line while streaming packets to an upper layer. The method includes loading an instruction set for custom programming the processing of packet data received from the physical layer. Determining a type of packet data received from the physical layer. Identifying a first word location in the packet data based on the contents of the instruction set. Examining the packet data received from the physical layer at the first identified word location. The method further includes storing an element indicative of information contained in the first identified word location into a data structure, and appending the data structure to the packet data before the packet is streamed to the upper layer. The methods and apparatus also have direct applicability to reducing a CPU’s work load during transmissions of data over a network. HP originally requested leave to file a Motion for Summary Judgment of Indefiniteness as to the terms “data part” and “packet parts data structure.” Doc. No. 88. The Court granted this request. Doc. No. 93. However, HP did not file a Motion for Summary Judgment and did not brief the indefiniteness issues. 1 5 a. “performed…in line” (Claim 13) Plaintiff’s Proposed Construction Plain and ordinary meaning. No construction necessary. Defendant’s Proposed Construction “performed…on-the-fly at line rate without slowing down data transfer rates” The phrase “performed . . . in-line” appears in the preamble of claims 1 and 13.2 “Whether a preamble should be treated as a claim limitation is determined on the facts of each case in light of the claim as a whole and the invention described in the patent.” Storage Tech. Corp. v. Cisco Sys., Inc., 329 F.3d 823, 832 (Fed. Cir. 2003). The preamble is limiting in claims 1 and 13 because the specification emphasizes that processing “in-line while streaming packets to an upper layer” is a key benefit of the invention. See, e.g., ’990 Patent at 11:21-26 (“It is important to realize that packet data processing occurring in micro-RISC stream processor 114b rapidly generates the user defined data structures in an in-line manner (i.e., without slowing down data transfer rates) to advantageously append the defined data structures to the packets being streamed to upper layers.”); id. at 6:21-25 (“Also disclosed are methods for user programmable in-line processing (e.g., parsing) of receive and transmit packet data while performing high speed streaming of packet data in or out of the media access control layer.”) (emphasis added). The prosecution history similarly supports the conclusion that the preamble is limiting. In distinguishing a prior art reference (Frantz), the patentee argued that “Frantz fails to teach or suggest performing such processing while packets are being streamed through the processor.” Doc. No. 94, Ex. A at 3 (emphasis in original). The reference to “such processing” was the recited limitation of “performed in-line while packet data is being streamed through the 2 The term “in-line” also appears in the body of claim 13. 6 processor.” Similarly, in distinguishing a different prior art reference (Marshall), the patentee explained that “Marshall fails to teach or suggest performing such processing while packets are being streamed to the physical media.” Doc. No. 94, Ex. B at 3 (emphasis in original). Again, the reference to “such processing” was the recited limitation of “performed in-line while packet data is being streamed to the physical media.” Here, the reference to “such processing while packets are being streamed” shows the patentee’s reliance on the preamble element to distinguish the invention over the prior art. See Storage Tech, 329 F.3d at 835 (finding the preamble limiting because the applicants relied upon the preamble element in distinguishing the invention over the prior art). The crux of the parties’ remaining dispute is whether the term “in-line” requires two limitations which HP seeks to impose: (1) processing on-the-fly at line rate; and (2) processing without slowing down data transfer rates. The portion of the specification that HP cites to for support of the “on-the-fly at line rate” limitation does not include the disputed term “in-line.” See Id. at 4:59-63. Likewise, that portion of the specification is not a clear and unambiguous statement defining the term “in-line,” because it refers to two processors: a “micro-risc processor” and a “host CPU.” Id. at 4:49-63. Furthermore, “on-the-fly at line rate” is another technical term that will not add clarity. Thus, HP’s “on-the-fly at line rate” limitation is rejected. However, HP’s “without slowing down data transfer rates” limitation finds support in the specification. The specification explicitly states “in an in-line manner (i.e. without slowing down data transfer rates).” Id. at 11:23–24 (emphasis added). The Federal Circuit has found that “i.e.” defines the meaning of a term. Abbot Labs v. Novopharm Ltd., 323 F.3d 1324, 1330 (Fed. Cir. 2003); see also Tidel Engineering L.P. v. Fire King Intern., Inc., 613 F. Supp. 2d 823, 829 (E.D. Tex. Jan. 6, 2009). Furthermore, in describing the problems with the prior art, the 7 specification states “[b]y way of example, when Ethernet network speeds are accelerated to gigabit levels, the host CPU will generally be required to spend more time processing packet data and less time performing other CPU processing tasks. As a result, the host CPU will tend to experience many more processing interrupts which may hamper packet transmission and receiving operations.” ‘990 Patent at 3:16-21. The specification further states that “there is a need for methods and apparatuses for media access control layer processing that is well suited to increase transmit and receive packet processing rates while reducing a host CPU’s processing burden.” Id. at 3:55-58. The specification also repeatedly states that the CPU is no longer required to “laboriously” scan/analyze each packet, which results in fewer CPU interrupts. Id. at 16:2-11; 20:19-24; 20:40-43; 21:21-29; 21:1-10. Similarly, the specification states that “[t]he methods and apparatus also have direct applicability to reducing a CPU’s work load during transmissions of data over a network.” Id. at Abstract. Given the identified problems of CPU interrupts and CPU processing burden, a person of ordinary skill in the art would understand “performed…in-line” to mean “performed . . . without slowing down data transfer rates.” Secure Axcess argues that no construction is necessary and that the plain and ordinary meaning “simply denoted a piece-by-piece analysis, such as parsing.” Doc. No. 92 at 5; 990 Patent at 6:21-25. The specification does not use the phrase “piece-by-piece,” and the phrase does not add clarity. Moreover, the specification states that the micro-RISC processor can perform more than “parsing.” 990 Patent at 7:63-67 (“Once network flow managing FIFO Tx controller 110 performs any requested processing based on received control information, microRISC stream processor 114a is suited to performs various user programmable packet processing, parsing, filtering and encapsulation operations.”) (emphasis added). Because the 8 “in-line” feature was described as an important advantage over the prior art, the plain and ordinary meaning will likely not resolve the dispute. Furthermore, “in-line” is a coined phrase in this context and does not have a general meaning, further supporting that construction is necessary. Therefore, the Court construes the term “performed…in-line” to mean “performed . . . without slowing down data transfer rates.” b. “an instruction set for custom programming” / “instruction set” (Claims 1, 2, and 5) Plaintiff’s Proposed Construction Plain and ordinary meaning. No construction necessary. Defendant’s Proposed Construction “a completely customizable and configurable user defined software parameters [for]” The crux of the parties’ dispute is whether the term “instruction set” is limited to “a completely customizable and configurable user defined software parameters.” HP believes the term is so limited, while Secure Axcess opposes this limitation. Doc. No. 92 at 7; Doc. No. 94 at 9. Secure Axcess contends that “an instruction set is simply a set of machine instructions that a processor recognizes and can execute.” Doc. No. 92 at 7 (citing Declaration of Christian Hurt (“Hurt Decl.”), Ex. A (1997 Microsoft Press Computer Dictionary 3d.), at 254; id. at Ex. B (1997 Novell’s Dictionary of Networking), at 279). This dictionary definition provides a starting point for the construction of “instruction set.” However, if the processor can execute the instructions, then the processor necessarily recognizes the instructions as well, thus making it redundant to include the term “recognizes” in the construction. Indeed, the Novell’s Dictionary of Networking defines “instruction set” as “[a] set of machine language instructions that a processor executes.” Doc. No. 92 at 7 (citing Declaration of Christian Hurt (“Hurt Decl.”), Ex. B (1997 Novell’s Dictionary of Networking), 9 at 279). Therefore, the starting definition for this term is a “set of machine instructions that a processor can execute.” The issue is whether further limitations should be imposed. HP seeks to impose two limitations on this term: (1) that it is “completely customizable and configurable” and (2) that it is “user defined.” Secure Axcess argues that the claims do not require these limitations, but rather merely require the instruction set to perform an operation: “custom programming the processing of packet data.” Doc. No. 92 at 7. Secure Axcess contends that HP’s limitations only relate to features of embodiments of the invention, not to statements that define the invention. Doc. No. 92 at 8. As to the first limitation, the claims do not require the instruction set to include “completely customizable and configurable” software parameters. HP has not pointed to evidence supporting this language. Indeed, during the claim construction hearing, HP agreed to drop this limitation from its proposed construction. As to the second limitation, the claims do require the instruction set to be “user defined.” The specification repeatedly states that the instruction set is user defined or user programmed. For example, the specification states that “the user may configure a software instruction set designating the type of parsing to be performed on in-coming packet data, as well as the type of data structure to build and append to respective packets through the use of a graphical user interface (GUI).” ’990 Patent at 11:13–17 (emphasis added). Referring to Figure 3A, the specification states that “because a user is able to program the type of processing to be performed in micro-RISC stream processor 114b, the user is preferably directed to define a software instruction set identifying the type of data structure to build, as well as the content of the data structures. 10 To achieve this, the user preferably implements a graphical user interface (GUI) 300 that provides a list of choices for ease of programming.” Id. at 12:34–40 (emphasis added).3 Thus, the term “instruction set” must be “user defined” when read in the context of the specification. Secure Axcess’s argument opposing this limitation is divorced from the specification because it removes the user from defining the instruction. Bell Commc’ns Research, Inc. v. Vitalink Commc’ns Corp., 55 F.3d 615, 621 (Fed. Cir. 1995) (“[I]t is legal error to construe a claim by considering it in isolation. A claim must be read in view of the specification of which it is a part”). Therefore, the Court construes the term “an instruction set for custom programming” / “instruction set” to mean “user defined set of machine instructions that a processor can execute.” c. “data structure” (Claims 1, 3, 5, 6, 13, 15, and 19) Plaintiff’s Proposed Construction Plain and ordinary meaning. No construction necessary. Defendant’s Proposed Construction “a plurality of fully configurable user defined fields” The parties dispute whether the term “data structure” is limited to “a plurality of fully configurable user defined fields.” Secure Axcess argues that the plain and ordinary meaning of a “data structure” is simply a way of organizing data in a computer. Doc. No. 92 at 12 (citing Hurt Decl., Exh. A, at 133 (1997 Microsoft Press Computer Dictionary 3d.)). HP believes the term Additionally, referring to Figure 4A, the specification states that “[t]he method begins at a step 402 where a user defined software instruction set is loaded into micro-RISC stream processor 114b for programming the processing performed on packet data being received from SUPERMAC controller Rx 120.” Id. at 16:15-17 (emphasis added); see also id. at 15:50-53 (“However, if the user wants to modify the processing set in the software instruction set input through GUI 300 of FIG. 3A, the received packets will be processed in accordance with those new parameters.”) (emphasis added); id. at 15:57-59 (“Accordingly, micro-RISC stream processor 114b will operate on different packets in accordance with the specific microcode programmed by the user.”); id. at 18:17-21 (“After the user programs in the type of data structure format and the desired positions of interest for the received packets in step 420, the method will proceed to a step 422 where the desired instruction set programmed by the user is compiled to create compiled microcode.”). 3 11 should be limited when viewed in light of the specification. Doc. No. 94 at 14. Secure Axcess is correct that claim 6 indicates that “data structures” may include “pointer data structures,” “flag data structures,” and “field data structures,” among others. Doc. No. 92 at 9. Secure Axcess is also correct that the claims do not literally limit the data structures to “a plurality of . . . fields,” because claim 18 recites a “flag data structure,” which may be a single bit (i.e., one field). ’990 Patent at 27:4-6. Thus, HP’s construction should be rejected because it requires a “plurality of fully configurable user defined fields,” while the intrinsic evidence merely requires at least one field. In describing a “field data structure” embodiment, the specification states that “the field data structure constructed for a packet F may be any number of user defined bit field combinations.” ’990 Patent at 20:60-62. The language HP points to is in the context of the “field data structure” or multi-bit fields disclosed in Figure 7A and 7B. This is just one type of “data structure” disclosed in the specification. Moreover, the words “fully configurable” do not appear in the intrinsic evidence. Thus, HP has not shown adequate support for these limitations. However, the “field” in the term “data structure” must be user defined. Secure Axcess concedes that the specification discloses customizable and user-defined data structures, but argues that it does so only in connection with embodiments and is thus insufficient to limit the term “data structure” to that one type of data structure. Doc. No. 92 at 10. As with the term “instruction set,” previously discussed, this argument is divorced from the specification because it removes the requirement of a “user defined” data structure. Bell Commc’ns Research, Inc., 55 F.3d at 621. The specification repeatedly states that the data structure is user defined or user programmed. For example, in describing a “pointer data structure” the specification states “[a]s shown in FIG. 5A, a user may program a data structure for a packet A to include a pointer to the 12 start of an IP header, a pointer to the start of a TCP header, a pointer to the start of an SMTP header, a pointer to the start of an application header and a data portion.” ’990 Patent at 19:6267 (emphasis added). Likewise, in describing a “hashed data segment” the specification states that “[i]n still another example, FIG. 5D shows a data structure for a packet D that may be programmed to include only hashed data.” Id. at 20:11-13 (emphasis added).4 The specification also states that “[o]ne particular advantage of the present invention is that host CPU interrupts are minimized because each transferred packet is pre-processed by a micro-rise processor that is programmed to build and appended custom data structures to each transferred packet.” Id. at 4:49-53 (emphasis added). The specification further states that “[a]gain, by having the data structure composed of a plurality of user defined fields, the host CPU is freed from having to scan and search the entire packet to locate the desired information, which may be distributed throughout the packet.” Id. at 21:2-6 (emphasis added). Therefore, the Court construes the term “data structure” to mean “at least one user defined field.” d. “packet data segment data structure” (Claim 6) Plaintiff’s Proposed Construction Plain and ordinary meaning. No construction necessary. Defendant’s Proposed Construction “a portion of packet data stored as a plurality of fully configurable user defined fields” Additionally, in describing a “flag data structure”, the specification states “FIG. 6A shows a data structure for a packet F which has been programmed by a user to include a plurality of flags in accordance with one embodiment of the present invention.” Id. at 20:25-27 (emphasis added). Likewise, in describing a “field data structure” the specification states “FIGS. 7 A and 7B show yet another type of data structure that may be defined by the user in accordance with one embodiment of the present invention. In this example, the data structure may include a plurality of bits grouped into multi-bit fields as shown in FIG. 7A.” Id. at 20:50-54 (emphasis added). Finally, the specification states “[a]s shown, packet 802 is streamed out of micro-RISC stream processor 114b, including an appended index 804 which represents the user defined data structure having either pointers, data, hash data, or a combination thereof.” Id. at 21:37-41 (emphasis added). 4 13 The only dispute is the construction of the “data structure” portion of this term. The arguments pertaining to the construction of “data structure” have already been addressed in the preceding section, and the parties agree that “data structure” should have the same meaning in this phrase. Doc. No. 92 at 12; Doc. No. 94 at 17. Thus, the Court will not separately construe “data structure” in this term. The parties also agree that the “packet data segment” portion of the term should be construed as “a portion of packet data stored as a data structure.” Doc. No. 92 at 12; Doc. No. 94 at 17. Therefore, the Court construes the term “packet data segment data structure” to mean “a portion of packet data stored as a data structure.” e. “hashed data segment data structure” (Claim 6) Plaintiff’s Proposed Construction Plain and ordinary meaning. No construction necessary. Defendant’s Proposed Construction “a portion of compressed packet data stored as a plurality of fully configurable user defined fields” This disputed term also includes the term “data structure,” which has been construed above. The parties offer no new arguments for the construction of the “data structure” portion of this term, and they agree that “data structure” should have the same meaning in this phrase. Doc. No. 92 at 12; Doc. No. 94 at 17. The remaining dispute is whether “hashed data” is limited to “a portion of compressed packet data.” Both parties agree that compressed data is stored in the “hashed data segment data structure,” but HP argues that the compressed data is limited to packet data. Doc. No. 94 at 17-18. Secure Axcess argues that the claims do not necessarily limit compressed data to packet data, as opposed to including other types of data. Doc. No. 92 at 12. Secure Axcess argues that the claims recite both a “hashed data segment data structure” 14 (claim 6) and a “hashed packet parts data structure” (claim 17). Id. at 12-13. Because of this difference, Secure Axcess concludes that the “hashed data segment data structure” is not limited to one that stores packet data. Id. at 13. HP does not substantively address this claim differentiation argument. The claims indicate that the “hashed data segment data structure” is not limited to one that stores “packet” data. Tandon Corp. v. U.S. Int’l Trade Comm’n, 831 F.2d 1017, 1023 (Fed. Cir. 1987) (“There is presumed to be a difference in meaning and scope when different words or phrases are used in separate claims”). The specification also discloses both compressed data and compressed packet data as constituting hashed data. See, e.g., ’990 Patent at 11:30-36 (“This is because the user defined data structure may be programmed to store pointers to portions within the packet data that may be of interest to upper layer protocols, or portions of data (hashed or compressed data) that may be quickly read and processed without having to spend CPU bandwidth to scan and process the entire packet.”) (emphasis added); id. at 14:33-40 (“In another example, if the user desires to construct a data structure that includes hashed data (i.e., compressed packet data . . . . ”) (emphasis added); id. at 17:62-67 (“As described above, in a preferred embodiment, the user will preferably program in the desired type of data structure which may be, for example, a pointer data structure, a data structure having portions of packet data, a data structure having hashed data (i.e., compressed), or a combination thereof.”) (emphasis added); id. at 20:11-15 (“In still another example, FIG. 5D shows a data structure for a packet D that may be programmed to include only hashed data. As is well known in the art, hashed data refers to compression data…”) (emphasis added). Here, the claims and the specification disclose both compressed data and compressed packet data as constituting hashed data. Thus, hashed data should not be limited to compressed 15 “packet” data. Therefore, the Court construes the term “hashed data segment data structure” to mean “a portion of compressed data stored as a data structure.” III. Disputed Terms in the 713 Patent The ’713 Patent, titled “Media Access Control Architectures and Network Management Systems,” was filed on April 24, 1997, and issued on August 22, 2000. The Abstract states: Disclosed is a media access controller for transferring data along a computer network. The media access controller includes a transmit media access controller that is configured to process out-going packet data received from an upper layer for transmission to a physical layer. A receive media access controller that is configured to process in-coming packet data received from the physical layer for transmission to the upper layer. A transmit multi-packet queue FIFO for receiving the out-going packet data from the upper layer before being passed to the transmit media access controller. A receive multi-packet queue FIFO for receiving the incoming packet data that is received by the receive media access controller. The media access controller further including a media access controller manager interfacing with the transmit and receive media access controllers. The media access controller manager being responsible for managing the flow of packet data through the transmit and receive mum packet queue FIFOs. a. “a parallel event processor” (Claims 2, 3, 4, 24, and 25) Plaintiff’s Proposed Construction Plain and ordinary meaning. Not construction necessary. Alternatively, “a processor capable of processing parallel events” Defendant’s Proposed Construction “a processor containing at least a packet buffer, command and status registers, statistical counters, programmable counters, and a micro-RISC processor” The dispute is whether the recited “parallel event processor” requires all of the circuit elements depicted in the parallel event processor disclosed in Figure 2. Secure Axcess argues that the plain and ordinary meaning of “a parallel event processor” is “a processor capable of processing parallel events.” Doc. No. 92 at 13. Secure Axcess contends that HP’s construction seeks to improperly limit the claims to an embodiment. Id. at 15. HP argues that the ’713 Patent 16 provides only one disclosure for the components of the parallel event processor, and therefore the claims should be limited to that one embodiment. Doc. No. 94 at 20-21; ’713 Patent at 12:20–43. The independent claims do not recite the circuit components included in HP’s construction. Instead, a number of these circuit elements are recited as separate limitations in dependent claims. See e.g., ’713 Patent at dependent claim 3 (reciting “a packet buffer”); dependent claim 8 (reciting “statistical counters”); dependent claim 4 (reciting “programmable counters”); dependent claim 6 (reciting “a micro-RISC processor”). Moreover, Figure 2 (and its description) does not contain the definitional language required to limit the claimed parallel event processor, as HP contends. Instead, the specification indicates that those components are an exemplary embodiment. ’713 Patent at 5:65-67 (“FIG. 2 is an architectural diagram of a flow based media access controller (MAC) in accordance with one embodiment of the present invention.”). The Federal Circuit has “expressly rejected the contention that if a patent describes only a single embodiment, the claims of the patent must be construed as being limited to that embodiment.” Info-Hold, Inc. v. Applied Media Techs. Corp., 783 F.3d 1262, 1267 (Fed. Cir. 2015) (quoting Liebel-Flarsherim Co. v. Medrad, Inc., 358 F.3d 898, 906 (Fed. Cir. 2004) (citations and quotations omitted)); TomTom, Inc. v. Adolph, 790 F.3d 1315, 1328 (Fed. Cir. 2015) (“[T]his court has repeatedly cautioned against importing limitations from an embodiment into the claims.”) (collecting cases). Moreover, the specification does not require all of the proposed circuit elements to be included in the embodiment illustrated in Figure 2. ’713 Patent at 10:66-11:2 (stating that the micro-RISC processor is only “preferably contained within a parallel event processor (PEP) 17 124”) (emphasis added). The recited “parallel event processor” may include the circuit elements included in Defendant’s construction, but does not necessarily need to require them. Therefore, the Court construes the term “a parallel event processor” to mean “a processor that may include a packet buffer, command and status registers, statistical counters, programmable counters, and a micro-RISC processor.” b. “internal stream processor” (Claim 5) Plaintiff’s Proposed Construction Plain and ordinary meaning. No construction necessary. Alternatively, “a processor capable of processing packet data transferred between a controller and a multi-queue device” Defendant’s Proposed Construction “internal micro-RISC stream processor operating in an in-line manner for modifying data stream characteristics” There are two disputes as to this term: whether the recited “internal stream processor” (1) is limited to a “micro-RISC” processor; and (2) must operate in “an in-line manner.” The intrinsic evidence does not limit the “internal stream processor” to a “micro-RISC” processor. Claim 5 does not require a micro-RISC-based processor, and the specification does not disclaim non-RISC-based systems or define the claims as limited to RISC-based systems. The patentee knew how to claim a RISC-based system, but declined to do so in claim 55. More importantly, during prosecution, the patentee explicitly stated that “some of the claim terms have been broadened” by replacing the term “micro-RISC stream processor” with the term “stream processor.” Doc No. 94, Ex. 4 at 7 (Response to Non-Final Rejection, at 6). Thus, the “internal stream processor” is not limited to a “micro-RISC” processor. The “internal stream processor” must operate in an “in-line” manner, however, “in-line” Compare claim 5 (reciting a “first internal stream processor” with no RISC-based components) with claim 6 (claim a “first internal micro-RISC stream processor” that interacts with another RISC-based processor). 5 18 must be construed to clarify the term for the jury. The ’713 Patent expands on the meaning of “in-line” by providing examples and discussing the deficiencies in the prior art. The specification states that “there is a need for methods and apparatuses for media access control (MAC) layer processing that will allow for in-line packet-by packet processing of data information and control information to modify a packet’s characteristics while it is being processed for transmission or reception.” ’713 Patent at 4:44–49 (emphasis added). The specification further states that “[b]roadly speaking, the present invention fills these needs by providing methods and apparatuses for a high speed media access controller used to process packet data and control information in an in-line packet-by packet manner.” Id. at 4:56–59 (emphasis added). The specification also states that “[a]n invention is described for a high speed Ethernet media access control layer integrated circuit core and method for processing packet data in an inline packet-by-packet manner that allows simultaneous processing of data information and associated control signals.” Id. at 7:38-42 (emphasis added). Thus, “in-line packet-by-packet” means simultaneous or parallel processing of data information and associated control signals. The specification emphasizes “the advantages associated with processing control and data in parallel, it is useful to realize that while data is being processed, control information may be received to modify data processing without having to wait for data to be completely processed.” Id. at 17:54-58. These descriptions inform the scope of the claims because they describe the entirety of the invention as allowing simultaneous or parallel processing of data information and associated control signals. See Verizon Servs. Corp. v. Vonage Holdings Corp., 503 F.3d 1295, 1308 (Fed. Cir. 2007) (“When a patent thus describes the features of the ‘present invention’ as a whole, this description limits the scope of the invention”). Likewise, the patentee emphasized 19 the word “while” to avoid prior art. Doc. No. 94, Ex. 4 at 9) (“Wakeman fails to teach or suggest transmit and receive media access controllers whose processing is alterable by control information received while processing.”) (emphasis in original). Secure Axcess’s alternative construction does not provide any additional clarity because it is redundant in light of the existing claim language. See ’713 Patent at claim 5 (“a first internal stream processor for processing packet data being transferred between the transmit multi-queue device and the transmit media access controller, the first internal stream processor also being configured to process packet data being transferred between the receive media access controller and the receive multi-queue device”) (emphasis added). Therefore, the Court construes the term “internal stream processor” to mean “a processor capable of allowing simultaneous or parallel processing of data information and associated control signals.” c. “transmit multi-packet queue device for device receiving” / “receive multi-packet queue device for receiving” (Claims 2 and 5) “transmit multi-packet queue device for receiving” Plaintiff’s Proposed Construction Plain and ordinary meaning. No construction necessary Defendant’s Proposed Construction “transmit device capable of receiving, storing, and transmitting on a first in, first out basis” “receive multi-packet queue device for receiving” Plain and ordinary meaning. No construction necessary “receive device capable of receiving, storing, and transmitting on a first in, first out basis” Term The parties dispute whether the recited “multi-packet queue devices” are limited to ones that operate on “a first in, first out basis.” HP argues that “first in, first out” is the only sequence of operation described in the specification. Doc. No. 94 at 27. Secure Axcess counters that nothing in the claim language requires processing to be on a first-in, first out basis, but rather it 20 merely “requires the device to provide a multi-packet queue, however that queue is processed, and perform the claimed operation.” Doc. No. 92 at 19. Secure Axcess argues that HP is improperly attempting to limit the term to the preferred embodiment. Id. The parties do not appear to dispute that it is widely understood that FIFO means first in, first out. Doc. No. 94 at 26. HP argues that its construction only requires the “transmit multipacket queue device” to be capable of receiving, storing, and transmitting on a first in, first out basis. Id. at 27. According to HP, their construction does not limit the device from performing other operations, including those highlighted by Secure Axcess. Id. Secure Axcess points to at least three teachings in the specification that demonstrate that processing is not required to be performed on a first-in, first-out basis. First, Secure Axcess contends that specification “details that the FIFO Tx can be programmed to prioritize the different types of data being transferred across the network, such as audio, video, or graphics.” Doc. No. 92 at 19 (citing ’713 Patent at 8:55-57). In that instance, Secure Axcess explains that the FIFO Tx does not simply receive, store, and transmit packets on a first in, first out basis, but instead indicates that some packets take priority over others. Id. Second, Secure Axcess contends that the specification teaches that “the device can skip over or hold particular packets.” Id. (citing ’713 Patent at 8:57-62). That processing is also not on a first in, first out basis, because skipping or holding packets can change the order. Third, the specification teaches that “the ability to modify the processing parameters of packets buffered in the FIFO Tx is a ‘powerful feature.’” Id. (citing ’713 Patent at 9:24–38). Thus, the recited “multi-packet queue devices” are not limited to ones that operate on “a first in, first out basis.” Additionally, during prosecution the patentee amended the claims and stated that “some of the claim terms have been broadened. Specifically, the phrase ‘multi-queue device’ has been 21 substituted for ‘FIFO device’. . . .” Doc. No. 97 at 10 (citing Doc. No. 94, Ex. 3 at 7 (Response to Non-Final Rejection, at 6)). This is further evidence that the “multi-packet queue devices” are not limited to ones that operate on “a first in, first out basis.” Therefore, the Court construes “transmit multi-packet queue device for device receiving” / “receive multi-packet queue device for receiving” to have its plain and ordinary meaning. CONCLUSION For the foregoing reasons, the Court hereby ADOPTS the above claim constructions for the patents-in-suit. For ease of reference, the Court’s claim interpretations are set forth in a table in Appendix A. So ORDERED and SIGNED this 7th day of November, 2016. 22 APPENDIX A Terms, Phrases, or Clauses 990 “performed…in-line” Court’s Construction “performed . . . without slowing down data transfer rates” 990 “an instruction set for custom programming” / “instruction set” “user defined set of machine instructions that a processor can execute” 990 “data structure” “at least one user defined field” 990 “packet data segment data structure” “a portion of packet data stored as a data structure 990 “hashed data segment data structure” “a portion of compressed data stored as a data structure” 713 “a parallel event processor” “a processor that may include a packet buffer, command and status registers, statistical counters, programmable counters, and a micro-RISC processor” 713 “internal stream processor” “a processor capable of allowing simultaneous or parallel processing of data information and associated control signals” 713 “transmit multi-packet queue device for device receiving” / “receive multi-packet queue device for receiving” Plain and ordinary meaning 23

Some case metadata and case summaries were written with the help of AI, which can produce inaccuracies. You should read the full case before relying on it for legal research purposes.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.