i2 Technologies, Inc. et al v. Oracle Corporation et al, No. 6:2009cv00194 - Document 257 (E.D. Tex. 2011)
Court Description: MEMORANDUM OPINION AND ORDER. Oracle's Summary Judgment Motion 164 is DENIED. The Court interprets the claim language in this case in the manner set forth in this Order. Signed by Judge Leonard Davis on 01/21/11. cc:attys 1-21-11(mll, )
Download PDF
<![CDATA[
i2 Technologies, Inc. et al v. Oracle Corporation et al Doc. 257 IN THE UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF TEXAS TYLER DIVISION i2 TECHNOLOGIES, INC. and i2 TECHNOLOGIES US, INC. § § § Plaintiffs, § § vs. § § ORACLE CORPORATION and ORACLE § AMERICA, INC. § § Defendants. CASE NO. 609 CV 194 PATENT CASE MEMORANDUM OPINION AND ORDER This Memorandum Opinion and Order construes the terms in United States Patent Nos. U.S. Pat. No. 5,983,194 (the “’194 patent”); U.S. Pat. No. 7,085,729 (the “’729 patent”); and U.S. Pat. No. 7,062,540 (the “’540 patent”).1 Oracle’s Summary Judgment Motion (Docket No. 164) is DENIED. APPLICABLE LAW “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., Inc., 381 1 During the November 17, 2010 motions hearing, i2 informed the Court it was no longer asserting the 7,065,499 patent and claims 1, 2, 4 8, 9, 10, 11, 12 of the ’l56 patent. See Docket No. 156. The 5,930,156 patent was subsequently withdrawn from the case. Docket No. 250. 1 Dockets.Justia.com F.3d 1111, 1115 (Fed. Cir. 2004)). In claim construction, courts examine the patent’s intrinsic evidence to define the patented invention’s scope. See id.; C.R. Bard, Inc. v. U.S. Surgical Corp., 388 F.3d 858, 861 (Fed. Cir. 2004); Bell Atl. Network Servs., Inc. v. Covad Commc’ns Group, Inc., 262 F.3d 1258, 1267 (Fed. Cir. 2001). This intrinsic evidence includes the claims themselves, the specification, and the prosecution history. See Phillips, 415 F.3d at 1314; C.R. Bard, Inc., 388 F.3d at 861. Courts give claim terms their ordinary and accustomed meaning as understood by one of ordinary skill in the art at the time of the invention in the context of the entire patent. Phillips, 415 F.3d at 1312–13; Alloc, Inc. v. Int’l Trade Comm’n, 342 F.3d 1361, 1368 (Fed. Cir. 2003). The claims themselves provide substantial guidance in determining the meaning of particular claim terms. Phillips, 415 F.3d at 1314. First, a term’s context in the asserted claim can be very instructive. Id. Other asserted or unasserted claims can also aid in determining the claim’s meaning because claim terms are typically used consistently throughout the patent. Id. Differences among the claim terms can also assist in understanding a term’s meaning. Id. For example, when a dependent claim adds a limitation to an independent claim, it is presumed that the independent claim does not include the limitation. Id. at 1314–15. “[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) (en banc)). “[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)); Teleflex, Inc. v. Ficosa N. Am. Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). This is true because 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 2 claim scope. Phillips, 415 F.3d at 1316. In these situations, the inventor’s lexicography governs. Id. Also, the specification may 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. But, “‘[a]lthough the specification may aid the court in interpreting the meaning of disputed claim language, particular embodiments and examples appearing in the specification will not generally be read into the claims.’” Comark Commc’ns, Inc. v. Harris Corp., 156 F.3d 1182, 1187 (Fed. Cir. 1998) (quoting 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 patent applicant may also define a term in prosecuting 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.”). Although extrinsic evidence can be useful, it is “‘less significant than the intrinsic record in determining the legally operative meaning of claim language.’” Phillips, 415 F.3d at 1317 (quoting C.R. Bard, Inc., 388 F.3d at 862). 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 technical dictionaries and treatises may provide definitions that are too broad or may not be indicative of how the term is used in the patent. Id. at 1318. Similarly, expert testimony may aid a court in understanding the underlying technology and determining the particular meaning of a term in the pertinent field, but an expert’s conclusory, unsupported assertions as to a term’s definition is entirely unhelpful to a court. Id. Generally, extrinsic evidence is “less reliable than the patent and its prosecution history in determining how to read claim terms.” Id. 3 Summary judgment shall be rendered when the pleadings, depositions, answers to interrogatories, and admissions on file, together with the affidavits, if any, show that there is no genuine issue as to any material fact and that the moving party is entitled to judgment as a matter of law. FED . R. CIV . P. 56(c); Celotex Corp. v. Catrett, 477 U.S. 317, 323-25 (1986); Ragas v. Tenn. Gas Pipeline Co., 136 F.3d 455, 458 (5th Cir. 1998). An issue of material fact is genuine if the evidence could lead a reasonable jury to find for the non-moving party. Anderson v. Liberty Lobby, Inc., 477 U.S. 242, 248 (1986). In determining whether a genuine issue for trial exists, the court views all inferences drawn from the factual record in the light most favorable to the nonmoving party. Id.; Matsushita Elec. Indus. Co. v. Zenith Radio, 475 U.S. 574, 587 (1986). Invalidity for indefiniteness is a question of law that is reviewed de novo. Exxon Research & Eng’g Co. v. United States, 265 F.3d 1371, 1376 (Fed. Cir. 2001). A patent is sufficiently definite to satisfy the statutory requirement if one skilled in the art would understand the bounds of the claim when read in light of the specification. Id. at 1375. To respect the presumption of validity, a claim should only be held indefinite after reasonable efforts at construction prove futile. Id. Unless there is evidence of culpability or intent to deceive by delaying formal correction, a court should not invalidate a patent based on an obvious administrative error. Hoffer v. Microsoft Corp., 405 F.3d 1326, 1331 (Fed. Cir. 2005). ’194 PATENT The ’194 patent is directed to coordination planning between separate factories in a product manufacturing and supply chain network using the concept of demands and responses to communicate between multiple parties. The ’194 patent identifies the problem with “conventional planning systems” as “unable efficiently to maintain a plan for a factory accurately reflecting all 4 orders received from customers, the present state of raw materials and inventory and the parts available from other factories from which the factory receives parts.” ’194 patent at 1:36-41. To solve this problem, the patent provides a methodology for factories to exchange supply and demand information. ’194 patent at 1:14-16 (“planning coordination systems for coordinating separate factory planning systems and a method of operation”). Each factory has its own planning coordination system, which receives and processes demands and responses communicated by the planning coordinating systems of the other factories in the network. As shown and described in connection with Fig. 1: A planning coordination system (30) and method are provided that automatically coordinate a planning system (32) associated with a first factory (28) with separate planning systems (16, 24, 40) of a plurality of factories (12, 20, 36) in a manufacturing chain. The planning coordination system (30) communicates with the planning system (32) of the first factory (28) and communicates with separate planning coordination systems (14, 38) of the other factories (12, 36) with which the first factory (28) has demand and supply part relationships. ’194 patent at Abstract. Fig. 2 describes the operation of a planning coordination system: A planning coordination system coordinates each factory in the factory network. Each planning coordination system processes demands and responses received from other factories [step 50], communicates demands and responses to other factories [step 52], and waits for other factories to communicate new demands and responses [step 54] until a termination condition occurs [step 56]. ’194 patent at 7:32-37. “planning coordination protocol”/“a planning coordination system for providing a protocol to coordinate” The claim term “planning coordination protocol” occurs in the preamble of Claim 1, and “a planning coordination system for providing a protocol to coordinate” occurs in the preamble of Claim 9 of the ’194 patent. The parties dispute whether the preamble is limiting and whether the 5 claimed invention is limited to actions between each factory’s planning coordination system. i2 argues that the preamble is not a limitation and does not need to be construed. In the alternative, i2 proposes “a set of conventions for planning coordination” and “a planning coordination system providing a framework to coordinate.” i2 argues that statements in the ’194 patent’s prosecution explain the term: “The claims have been amended to make clear that the invention involves a unique iterative demand/response protocol. This demand/response protocol is an exchange of demands and responses that occurs between planning coordination systems, not between planning systems.” ’194 prosecution history, Jan. 11, 1999 Response at 10-11. Oracle reasons that the plain meaning of “protocol” is a set of rules governing some action and this action is planning coordination between each factory’s planning coordination system. Oracle proposes “a set of rules governing the interaction between each factory’s planning coordination system” and “a computer system that follows a set of rules governing the interaction between each factory’s planning coordination system.” Oracle points to Figure 1 and its description for the requirement that each factory have its own planning coordination system. ’194 patent at Fig. 1, 2:3539 (“FIG. 1 illustrates a factory network, indicated generally at 8, having a plurality of coordinated factories each utilizing a planning coordination system”); see also id. at 4:58-61. The preambles in Claims 1 and 9 are limiting because they set forth the environment for the computer-implemented method. Contrary to Oracle’s contentions, the claims do not specify that “each” factory in the manufacturing chain necessarily has a “planning coordination system,” and the claim term is not limited to the preferred embodiment in Figure 1. ’194 patent at 3:17-19 (“The number of factories and relationships between them illustrated in FIG. 1 is not intended to limit the scope of the present invention.”). The term “protocol” is a general, understandable term. i2’s 6 construction uses ambiguous terms “conventions” and “framework” to replace “protocol” that do not help to define the claim term. The plain language of the term is understandable; therefore, “planning coordination protocol” and “a planning coordination system for providing a protocol to coordinate” do not require construction. “planning system” The parties dispute whether the “planning system” can be manual or if it is limited to a computer system. i2 proposes “a manual or automatic system for generating a plan or schedule for a manufacturing process,” while Oracle proposes “a computer system for a factory that generates an output plan for that factory.” i2 argues that the specification provides that a planning system can either manually or automatically generate plans or schedules. In support, i2 references the “Background of the Invention” section, which provides “[a] planning system can range from a manually prepared plan or schedule to a plan or schedule automatically generated by a software application operating on a computer system.” ’194 patent at 1:19-24. Oracle argues the ’194 patent finds “conventional planning systems” problematic because they are “unable efficiently to maintain a plan for a factory accurately reflecting all orders received from customers, the present state of raw materials and inventory and the parts available from other factories from which the factory receives parts.” Id. at 1:36-41. Oracle’s proposed construction is consistent with the teachings of the ’194 patent. The specification discusses manual planning only as a background predicate for a planning coordination system, and in the context of the claimed “computer-implemented method” a manual system is precluded. However, as proposed by i2, the specification also supports that a planning system 7 includes of the output of a “schedule,” but i2’s proposed inclusion of “manufacturing process” is unnecessary because the claim specifies “factory in a manufacturing chain.” The Court construes “planning system” as “a computer system for a factory that generates an output plan or schedule for that factory.” “predetermined termination condition” The term “predetermined termination condition” appears in claims 1 and 9 of the ’194 patent. i2 proposes “a condition that completes the coordination activity,” while Oracle proposes “a condition defined before iterative processing begins that, upon its occurrence, will cause the iterative processing to stop.” The parties’ arguments focus on the word “predetermined.” i2 argues the specification supports its construction in stating that “if a termination condition has occurred, then the planning coordination system is completed with coordination activity.” ’194 patent at 5:59-61. i2 also contends that Oracle improperly imports limitations into the claims, specifically arguing that “iterative processing begins” and “the iterative processing to stop” upon the occurrence of the termination condition is unsupported by the specification and contrary to the plain language of Claims 1 and 9 where the “predetermined termination condition” is the result of the exchange of demands and responses. See id. at 10:18-20, 11:27-29. Oracle argues that a plain reading requires that the “predetermined termination condition” is defined in advance and stops the iterative processing. In support, Oracle references Figure 2 and the specification which teaches a termination condition “terminate[s] iterations of processing demand and response communications from other factories.” Fig. 2; 8:30-32; see also 5:58-6:6, 7:32-44, 9:11-29. Oracle additionally cites inventor testimony to support its argument. Oracle also contends i2’s construction does not define the word “predetermined,” only construes “termination condition,” 8 and does not take into account that the “termination condition” terminates the iterative processing, not just the “coordination activity.” i2’s construction fails to give meaning to “predetermined” and “the coordination activity,” which introduces another operational concept into the claim, is vague. Oracle’s proposed construction is consistent with the specification. See id. at Fig. 2; 8:30-32. Also, Oracle’s construction is properly supported by the plain language of claim, which itself states that the processing that is subject to termination is iterative. See id. at 10:18-20. The Court construes the term “predetermined termination condition” as “a condition defined before iterative processing begins that, upon its occurrence, will cause the iterative processing to stop.” “planning capability data” The term “planning capability data” appears in claims 1 and 9 of the ’194 patent. i2 proposes “data used by the planning system that reflects a factory’s capacity,” while Oracle contends the term is indefinite. i2 argues the specification and explanatory statements made during the ’194 patent’s prosecution support the definition and construction of this term. i2 also argues the plain language and intrinsic record sufficiently provide one of ordinary skill in the art an understanding of the term. In contrast, Oracle argues the term is not a known term of art and cannot be understood by one of ordinary skill in the art based upon the intrinsic evidence. Oracle notes the term does not appear in the specification and contends that i2 cannot equate “capacity” with “capability” because one of skill in the art recognizes “capacity data” as a term of art but would not recognize “planning capacity data” as a term of art. The intrinsic record provides sufficient support for the term “planning capability data.” The “Background” portion of the specification discusses “planning system” and gives an example of the 9 RHYTHM MPPS product. The specification also describes that a planning system operates to produce a plan or schedule for product manufacture. Those plans and schedules would inherently include the production “capability data” used by the planning system. While the phrase may be somewhat awkward, when set against the background of the specification, the phrase would indicate to one of skill in the art what i2’s construction says: “data used by planning system that reflects a factory’s capacity.” Oracle does not appear to suggest that the terms “planning” and “data” are not understandable but only “capability” in the context of the phrase “planning capability data” is indefinite. However, contrary to Oracle’s contention, there is a basis to equate “capability” with “capacity.” Oracle’s argument that considering the terms to be synonymous is precluded because the phrase “planning capacity data” is a term of art overlooks that a patentee can be his own lexicographer and may modify terms of art to other equivalent expressions. Such appears to have been the case when the claims were amended to include the phrase and the term “capability” was used rather than “capacity.” This is supported by the specification, which provides: The independence of the demand/response data from planning capacity data is consistently evident through the description from the very limited definition of “demand data” and of “response data” . . . It is obvious from the description that the invention operates with only this limited demand/response data. The invention does not use planning capacity data, which would reflect a factory’s capacity other than what it actually promises in the form of a response. ’194 prosecution history, Jan. 11, 1999 Response at 11-12 (emphasis added). Oracle’s Summary Judgment Motion, Docket No. 164, is DENIED. The Court construes “planning capability data” as “data used by the planning system that reflects a factory’s capacity.” 10 “the exchange of demands and responses is independent of planning capability data” “[T]he exchange of demands and responses is independent of planning capability data” appears in claims 1 and 9 of the ’194 patent. i2 proposes “the exchange of demands and responses does not use planning capability data other than what is promised in the form of a response” while Oracle contends that the exchange of demands and responses does not use “planning capability data.” i2 argues its construction is based on explanatory statements made during the prosecution of the ’194 patent that confirm the invention does not use planning capacity data and its constrcuction recognizes a relationship between promises in the responses to demands and the capacity of a factory. ’194 prosecution history, Jan. 11, 1999 Response at 11-12. i2 argues that Oracle’s construction is overly limiting by requiring “iteration of processing” and that no planning data be exchanged. Oracle contends that term is indefinite because of “planning capability data.” In the alternative, Oracle argues that the “exchange of demands and responses” must be independent of “planning capability data used by the planning system[s].” In support, Oracle cites the specification, which states “The planning coordination system is independent and separate from the planning system. The planning system maintains the output plan, and the planning coordination system addresses communicating demands and responses.” ’194 patent at 8:40-44. In addition, Oracle contends that i2’s arguments to distinguish the prior art support that the planning coordination system communicates only demands and responses and is independent from the planning system. ’194 prosecution history, Jan. 11, 1999 Amendment at 5 (“The only data that is communicated and shared is demand/response data.”); see also id. at 11 (“The claims further recite the independence of the demand-response protocol from the planning system.”). 11 The term “independent” must be given effect, and the parties agree that it means “does not use.” i2, however, suggests an exception that would impermissibly allow use of planning capability data. i2’s construction includes an ambiguous equivocation in “other than what is promised in the form of a response.” The inclusion of the additional language does not follow from the prosecution history, and there is no exception being referenced. See ’194 prosecution history, Jan. 11, 1999 Amendment at 5, 11. Instead, the remarks mean that planning capacity (capability) data is not used, and a factory’s capacity is reflected only in what is promised in the form of a response. Id. i2’s inclusion of “other than what is promised in the form of a response” is unsupported. Oracle’s proposed construction adopts language that is otherwise in the claim and places a limitation on the iterative processing recited in the claim that is not indicated by the claim language. An exchange of planning capability data is not precluded; only the exchange of the recited demands and responses cannot be based on planning capability data. The Court construes “the exchange of demands and responses is independent of planning capability data” as “the exchange of demands and responses does not use planning capability data.” “the communication system and the processing system are iteratively operable” The term “the communication system and the processing system are iteratively operable” appears in claim 9 of the ’194 patent. i2 proposes “the communication system and the processing system are capable of repeating the exchange of demands and responses and the processing of demands and responses,” while Oracle proposes “automatically repeating the steps of the communication system and the processing system.” The parties dispute whether the communication and processing system are capable of repeating or automatically repeating. 12 i2 argues that Oracle’s proposed construction improperly imposes method step limitations on an apparatus claim. i2 also argues that Oracle’s construction would implicitly require i2 to prove the automatic repeating of certain method steps to prove infringement. Oracle argues i2’s construction reads out “iteratively” from the claim, which has the plain meaning of “repeating.” Oracle contends the specification supports that the planning coordination system must “automatically coordinate” the planning systems. See ’194 at Abstract. Oracle also cites Fig. 2, which depicts the planning coordination system goes through “iterations of processing demand and response communications from other factories” until a termination condition occurs. See ’194 at Fig. 2, 8:30-3. Oracle also argues the prosecution history links “automatically” to “iterative.” See Jan. 6, 1997 Response at 16; Jan. 11, 1999 Response at 4-5. Oracle’s proposed construction improperly adds a requirement of “automatically” iteratively operable, which is not supported by the specification or prosecution history. See ’194 prosecution history, Jan. 11, 1999 Response at 10-11 (when adding the “iteratively operable” language to the claims, the applicant explained that “[t]he claims have been amended to make clear that the invention involves a unique iterative demand/response protocol. This demand/response protocol is an exchange of demands and responses that occurs between planning coordination systems, not between planning systems.”). Moreover, claim 9, which does not require the communication and processing system be “automatically” repeating is differentiated by claim 10, which includes an automatic requirement. See ’194 patent at 11:51-54 (“iteratively repeating communicating demands and communicating responses such that demand and supply information is automatically communicated between factories”). The Court construes “the communication system and the processing system are iteratively operable” as “the communication system and the processing system 13 are capable of repeating the exchange of demands and responses and the processing of demands and responses.” ’729 PATENT The ’729 patent discloses a system for managing available to promise (“ATP”) products, which are available products that are not already promised to another customer. The ’729 patent’s proposed solution to the problems with “traditional methods for demand management” is to provide a software system that models the actors in the sales transaction by use of a “supplier model,” a “seller model,” and a “customer model,” as illustrated in Figure 1. ’729 patent at 3:65-4:11, 6:1-19. The patent describes an approach that “pre-computes” the amount of product available for each seller to promise to customers and controls the distribution of the allocated supply throughout the sales organizations. ’729 patent at 2:15-23, 4:36-47, 7:45-53. “hierarchy of at least two seller models” The term “hierarchy of at least two seller models” appears in claims 1, 12, and 23 of the ’729 patent. i2 proposes “organization of at least two seller models,” while Oracle proposes “a multi-level organization of sellers structured in parent-child relationships that allow a parent to use an allocation itself or assign it to its children.” i2 argues that a hierarchy is simply an organization with members. See ’729 patent at 4:36-37 (“Sellers can form a hierarchy. Each seller can be a member of another seller, called its ‘organization.’”). i2 contends Oracle’s proposal improperly limits the term “hierarchy” to a particular type of hierarchy involving parent-child relationships and a particular allocation strategy. i2 also argues the specification teaches allocating down to members of the hierarchy – it is not required. See ’729 patent at 15:19-21 (“[T]he allocations at organizations can be allocated down to members.”); see also 15:30-31. 14 Oracle argues i2’s construction is overly general and gives no effect to the meaning of “hierarchy.” When read in view of the specification, the term defines a multi-level organization. See ’729 patent at Fig. 4 (a “product group hierarchy,” which also has a multi-level “tree” structure) and Fig. 8B (illustrating a hierarchy including an “organization” and its “members”); 7:45-47 (“A seller is committed to anything its sub-sellers commit to. However, a seller can commit to additional, beyond what the sub-sellers commit to.”). The plain and ordinary meaning of an organization according to rank supports a hierarchical seller-subseller relationship and allocation requirements. Moreover, the specification supports Oracle’s construction of hierarchy as a multi-level organization that allows a seller to control the supply allocations. See id. at 4:36-40 (“Sellers can form a hierarchy. Each seller can be a member of another seller, called its ‘organization.’ Allocations can be made to any level in the hierarchy. Sellers can use allocations to themselves or any of their organizations, depending upon allocation policies of the seller hierarchy.”). The Court construes “hierarchy of at least two sellers models” as “a multi-level organization of seller models structured in a seller–subseller relationship that allow a seller to use an allocation itself or assign it to its sub-seller.” “seller, supplier, and customer models” The terms “seller model,” “supplier model,” and “customer models” appear in claims 1, 12, and 13 of the ’729 patent. i2 proposes “model of a seller,” “model of a supplier,” and “model of a customer,” respectively. Oracle proposes “a model of a seller, distinct from the supplier model and customer model,” “a model of a supplier, distinct from the seller model and customer model,” and “a model of a customer, distinct from the seller model and supplier model,” respectively. 15 i2 argues that Oracle improperly imposes a “distinct” requirement that is not supported by the claim language or the specification. i2 contends that Oracle must point to reference in the claim that justifies the “distinct from” limitation. Oracle argues the claim language itself directs that the models must be distinct. Oracle cites the specification for support that each model is distinct from one another and performs a different function. See ’729 patent at 6:1-19 (describing Figure 1: seller model 50 receives “customer request 62” from site 34 (i.e., the customer model), while seller model 50 also receives from site 22 (i.e., the supplier model) a “promise 54 to seller 50 that the item can be delivered as requested by request 52”); see also 4:22-32, 2:61-64, 3:65-67, 4:3-6, 6:29-39. Oracle contends the specification is consistent—there the seller, supplier, and customer models are always described as distinct from one another. Oracle’s arguments are consistent with the specification. The claim language internally sets forth that the models are “distinct.” For example, claim 1 recites that the models are “operable to indicate to” the other models. This sets the models apart from each other and renders them “distinct.” The Court construes the terms “seller model,” “supplier model,” and “customer models” as “a model of a seller, distinct from the supplier model and customer model,” “a model of a supplier, distinct from the seller model and customer model,” and “a model of a customer, distinct from the seller model and supplier model,” respectively. “available to promise” The term “available to promise” appears in claim 2 of the ’729 patent. i2 proposes “quantity of product that is scheduled to be available for delivery to a customer,” while Oracle proposes “product produced, based on forecast orders, and available to meet future customer demand.” 16 i2 argues its definition is directly provided by the specification: “ATP consists of quantities of products with associated dates that the products are scheduled to be available for delivery to the customer.” ’729 patent at 2:29-31. Oracle argues the specification expressly defines “available to promise” to require forecast orders. Oracle contends the specification requires that “available to promise” “must” be built based on forecast orders and made available to meet future demand. Id. at 2:24-31(“To better meet customer demand, the manufacturer must build product and/or intermediate items before receiving customer orders. This production is based on projections called ‘forecast orders.’ A product produced based on these forecast orders is referred to as ‘available to promise’ or ‘ATP.’”). i2’s construction mimics the definition provided by the specification. Oracle’s definition is overly limiting and improperly imports from the specification how “available to promise” is derived. The Court defines the term “available to promise” as “quantity of product that is scheduled to be available for delivery to a customer.” “seller” and “supplier” The term “seller” appears in claims 1, 12, and 23 and “supplier” appears in claims 1, 3, 5, 7, 9, 12, 14, 16, 18, 20, 23, 25, 27, 29, and 31 of the ’729 patent. i2 proposes “an entity that sells at least one product” and “an entity that supplies at least one product,” respectively. Oracle proposes “an entity that sells at least one product from a supplier to customers” and “an entity that supplies at least one product to customers and promises supply to seller,” respectively. i2 contends a construction is unnecessary because both terms have a common, plain and ordinary meaning that is easily understood by the jury. i2 argues Oracle’s proposals are incorrect because they imply a requirement of multiple customers and discrete transactions between two 17 separate parties. i2 argues that a “supplier” could also supply products to other suppliers and a “seller” does not sell only to customers. Oracle contends the dispute is whether a single entity can be both a seller and a supplier. Oracle argues its constructions track the claim language, which requires the supplier models to “indicate to the seller models . . . promised supply of the product” and that the product supplied by the supplier fills “customer orders for the product through each seller.” See ’729 patent at claims 1, 12, and 23. Oracle argues that a “supplier” both “promises supply to sellers” and “supplies at least one product to customers.” Id. at 2:64-67 (“The forecast requests receive promises . . . to provide product allocation to the [seller] organization, and the product allocation is available to the sellers to promise to actual customer requests.”). Likewise, the specification supports that a “seller” is an entity that sells at least one product from a supplier to customers. Id. at 4:26-32 (“Sellers may take requests from one site or multiple sites for items supplied by one site or several different sites. It manages the requests and promises made between those sites. A seller can act as an agent of the supplying site and make promises for those sites. Sellers can manage requests and promises for one product or many products. Products can be defined for certain customer(s) . . .”). In light of i2’s issue with the plural “customers” in Oracle’s construction, Oracle offers to replace “to customers” with “to at least one customer.” i2’s constructions are overly broad and do not give context to the seller and supplier roles provided by the intrinsic evidence. Oracle’s constructions define what a term must mean at a minimum; they do not limit what other transactions the “seller” or “supplier” may undertake. As Oracle points out, the claim language itself dictates the reading of the terms. The Court construes “seller” and “supplier” as “an entity that sells at least one product from a supplier to at least one 18 customer” and “an entity that supplies at least one product to at least one customer and promises supply to seller,” respectively. ’540 PATENT The ’540 patent is directed to remote monitoring and managing applications being run within various computing domains. The architecture of the system is shown in Figure 2, where each domain 30 is coupled to a network through a firewall and runs applications 42 under the direction of agents 72. See ’540 patent at Figure 2. A monitoring and management portal 20 is coupled to the network and can access each of the domains. Id. The portal permits a user to receive information from the domains, monitor the applications, and transmit commands to domains to manage the applications. Id. at 4:63-5:7. “command is for initiating monitoring” The term “command is for initiating monitoring” appears in claim 24 of the ’540 patent. i2 proposes plain and ordinary meaning or alternatively “instruction is for commencing monitoring.” Oracle proposes “instruction from the management portal to an agent is for commencing monitoring.” i2 contends the language is plain and easily understood. i2 argues that Oracle improperly includes a requirement that the instruction be applied to a dedicated agent, which is inconsistent with the specification that discloses multiple types of commands for initiating monitoring. i2 also argues that Oracle’s construction is redundant of the claim language. See ’540 patent at claim 24 (requiring that the command be executed “using a monitor within the agent,” and that “the monitor [be] operable to interface with the particular corresponding application”). Oracle argues the claim language requires that the command be generated at a management portal. Id. at 11:36-37. Further, the prosecution history shows that the language was being construed 19 to distinguish the prior art’s disclosure of only local administrative control, thus requiring that the portal be outside of a domain. July 28, 2005 Response at 12-13. Oracle also argues the disclosed embodiment (Fig. 2) shows that the management portal is outside the domain. See id. at Figs. 2 & 3, 4:47-48; 7:37-41; 7:48- 51. Oracle’s proposed construction is already embraced within claim 24’s other limitations that specify a command is (1) generated at a management portal coupled to a network and (2) communicated from a communication layer to an agent associated with an application being monitored. Oracle presumes a dispute about the portal being outside of domains having computers that execute applications. The claim, however, sets forth firewall requirements that serve to locate the portal relative to the domain. Oracle’s construction is redundant and presents no dispute. i2 is correct that no construction is required. CONCLUSION For the foregoing reasons, the Court interprets the claim language in this case in the manner set forth above. For ease of reference, the Court’s interpretations of the claims are set forth in a table as Appendix A. So ORDERED and SIGNED this 21st day of January, 2011. __________________________________ LEONARD DAVIS UNITED STATES DISTRICT JUDGE 20 Appendix A ’194 PATENT Agreed Terms CLAIM TERM COURT’S CONSTRUCTION response [Claims 1, 2, 5, 9] an answer to a demand processing is iterative [Claims 1] automatically repeating the processing Disputed Terms CLAIM TERM COURT’S CONSTRUCTION planning coordination protocol [Claim 1] plain and ordinary meaning/no construction required a planning coordination system for providing a protocol to coordinate [Claim 9] plain and ordinary meaning/no construction required planning system [Claims 1, 2, 9] a computer system for a factory that generates an output plan for that factory pre-determined termination condition [Claims 1, 9] a condition defined before iterative processing begins that, upon its occurrence, will cause the iterative processing to stop planning capability data [Claims 1, 9] data used by the planning system that reflects a factory’s capacity the exchange of demands and responses is independent of planning capability data used by the planning system[s] [Claims 1, 9] the exchange of demands and responses does not use planning capability data 21 CLAIM TERM the communication system and the processing system are iteratively operable [Claim 9] COURT’S CONSTRUCTION the communication system and the processing system are capable of repeating the exchange of demands and responses and the processing of demands and responses ’729 PATENT Agreed Term CLAIM TERM commitment level [claims 1, 12, 23] COURT’S CONSTRUCTION an amount of product that a seller is willing to commit to selling Disputed Terms CLAIM TERM COURT’S CONSTRUCTION hierarchy of at least two seller models [claims 1, 12] / at least two sellers in a hierarchy using corresponding seller models [claim 23] a multi-level organization of seller models structured in a seller–subseller relationship that allow a seller to use an allocation itself or assign it to its sub-seller seller model [Claims 1, 12, 23] a model of a seller, distinct from the supplier model and customer model supplier model [Claims 1, 12, 23] a model of a supplier, distinct from the seller model and customer model customer model [Claims 1, 12, 23] a model of a customer, distinct from the seller model and supplier model available to promise [Claim 1, 2, 3, 8, 12-14, 19, 23-25, 30] quantity of product that is scheduled to be available for delivery to a customer 22 CLAIM TERM COURT’S CONSTRUCTION seller [Claims 1, 12, and 23] an entity that sells at least one product from a supplier to at least one customer supplier [Claims 1, 3, 5, 7, 9, 12, 14, 16, 18, 20, 23, 25, 27, 29, and 31] an entity that supplies at least one product to at least one customer and promises supply to seller ’540 PATENT Agreed Terms CLAIM TERM COURT’S CONSTRUCTION domain [Claims 24, 30,31] bounded collection of computers monitor [Claim 24] a managed object used to monitor or manage specific corresponding applications or portions of such applications Disputed Term CLAIM TERM command is for initiating monitoring [Claim 24] COURT’S CONSTRUCTION plain and ordinary meaning/no construction required ’207 PATENT Agreed Terms CLAIM TERM COURT’S CONSTRUCTION an analytical processing application [Claim 1] an application that analyzes or processes data query object [Claims 1, 2] a representation of a data request which includes functions to operate on said data request 23 CLAIM TERM COURT’S CONSTRUCTION translating the query object into a textual query [Claim 1] converting from the data format of the query object to the different data format of the textual query data warehouse [Claim 1] one or more databases textual query / textual queries [Claim 1] text based data request multi-dimensional cursor [Claim 1] software element for retrieving multidimensional data, where a dimension is, for example, customer, product or time 24
]]>
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.
