Opinion
Case No. 12-cv-01484-WHO
10-24-2013
ARIBA, INC., Plaintiff, v. COUPA SOFTWARE INC., Defendant.
CLAIM CONSTRUCTION ORDER
Re: Dkt. Nos. 44, 49, 68
INTRODUCTION
Plaintiff Ariba, Inc. filed this action on March 23, 2013, alleging that defendant Coupa Software, Inc. infringes United States Patent No. 7,117,165 ("the '165 Patent"), which relates to a software system for electronic procurement. Dkt. No. 1. Presently before the Court are the parties' memoranda concerning construction of the disputed terms in the '165 Patent. Having fully considered the parties' arguments and submissions, the Court construes the disputed language of the '165 Patent as set forth below.
The Court DENIES Ariba's motion for leave to file a supplement claim construction brief, filed after the claim construction hearing. Dkt. No. 68. The supplemental brief raises arguments that could have been raised in Ariba's opening or reply briefs. Ariba's disagreement with a tentative view expressed by the Court during the claim construction hearing is not grounds for reopening claim construction briefing.
BACKGROUND
The '165 Patent, entitled Operating Resource Management System, claims a system for electronic procurement. It was filed in October 1999, issued on October 3, 2006 and is assigned to Ariba. Ariba asserts that Coupa directly and indirectly infringes claims 1-9, 13-18, and 20-45 of the '165 Patent.
LEGAL STANDARD
Claim construction is a matter of law for the court's determination. Markman v. Westview Instr., Inc., 517 U.S. 370, 372 (1996). In order to construe claim terms, "the trial court must determine the meaning of any disputed words from the perspective of one of ordinary skill in the pertinent art at the time of filing." Chamberlain Grp., Inc. v. Lear Corp., 516 F.3d 1331, 1335 (Fed. Cir. 2008).
The words of a claim "are generally given their ordinary and customary meaning." Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (citations omitted). But the ordinary and customary meaning of a claim term cannot be determined in a vacuum. Intrinsic evidence—the claims, specification, and the prosecution history of the patent—"is the primary tool to supply the context for interpretation of disputed claim terms." V-Formation, Inc. v. Benetton Grp. SpA, 401 F.3d 1307, 1310 (Fed. Cir. 2005); Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996) ("It is well-settled that, in interpreting an asserted claim, the court should look first to the intrinsic evidence of record, i.e., the patent itself, including the claims, the specification and, if in evidence, the prosecution history.").
The "specification necessarily informs the proper construction of the claims." Phillips, 415 F.3d at 1316. It "is the single best guide to the meaning of a disputed term, and . . . acts as a dictionary when it expressly defines terms used in the claims or when it defines terms by implication." Id. at 1321 (quotations omitted). However, "[t]hat claims are interpreted in light of the specification does not mean that everything expressed in the specification must be read into all the claims." Raytheon Co. v. Roper Corp., 724 F.2d 951, 957 (Fed. Cir. 1983). "The claim, not the specification, measures the invention." Id. (citation omitted). For example, "merely because the specification only describes one embodiment is not a sufficient reason to limit the claims to that embodiment." Altiris, Inc. v. Symantec Corp., 318 F.3d 1363, 1372 (Fed. Cir. 2003). Nonetheless, "claims must be construed so as to be consistent with the specification." Phillips, 415 F.3d at 1316.
The Federal Circuit has acknowledged "that there is sometimes a fine line between reading a claim in light of the specification, and reading a limitation into the claim from the specification." Decisioning.com, Inc. v. Federated Dep't Stores, Inc., 527 F.3d 1300, 1307 (Fed. Cir. 2008) (internal citations omitted). The Federal Circuit instructs that "attempting to resolve that problem in the context of the particular patent is likely to capture the scope of the actual invention more accurately than either strictly limiting the scope of the claims to the embodiments disclosed in the specification or divorcing the claim language from the specification, and, thus, that there can be no magic formula or catechism for conducting claim construction." Id. at 1307-08 (citing Phillips, 415 F.3d at 1323-24). Consequently, courts "must read the specification in light of its purposes in order to determine whether the patentee is setting out specific examples of the invention to accomplish those goals, or whether the patentee instead intends for the claims and the embodiments in the specification to be strictly coextensive." Decisioning.com, Inc, 527 F.3d at 1308 (internal citations omitted). The court's focus is on "understanding how a person of ordinary skill in the art would understand the claim terms." Id.
"In most situations, an analysis of the intrinsic evidence alone will resolve any ambiguity in a disputed claim term." Vitronics Corp., 90 F.3d at 1583. In those circumstances, it is improper to rely on extrinsic evidence, such as dictionaries, treatises, and expert testimony. Id. If the intrinsic evidence fails to resolve any ambiguity in the claim language, the court may rely on extrinsic evidence. Id. While extrinsic evidence may guide the meaning of a claim term, such evidence is less reliable than intrinsic evidence. See Phillips, 415 F.3d at 1318-19.
CONSTRUCTIONS
1. order generating means for deciding between at least one of a purchase card module, a direct order module, and a purchase order module to submit the requisition for fulfillment by a supplier (Claim 1)
| Ariba's proposed construction | Coupa's proposed construction |
| Function: Deciding between a set of ordering modules, the set including at least one purchase card module, one direct order module, and one purchase order module, where the chosen module or modules is/are used as part of the process to submit an order for one or more line items. | Function: A computer choosing only one module to submit the requisition for fulfillment by a supplier, wherein the computer chooses from among at least a purchase card module, a direct order module, and a purchase order module |
| Structure: [1] "For each fully approved requisition, [the system] verifies whether a p-card can be used for this purchase: Ensure that the supplier accepts p-cards. If not, chooses a different ordering module." '165 Patent at 20:5-9. [2] "[The system] [c]hecks that the transfer method has been designated for direct order in the item template. If neither the purchase order (PO) or DO order module has been designated in the item template then the supplier profile will be checked for the transfer method. If the supplier profile indicates direct order, then that is the method. Otherwise, it is treated as a PO." Id. at 21:7-14. See also id. at 4:49-59 ("When a requisition is completed, the system will check the requisition to determine which suppliers are involved, determine the preferred method of ordering for those suppliers, and use that method for transmitting the requisition to the supplier. The pieces of the system used to transfer orders for fulfillment are known as the ordering modules 130 (FIG. 1) (see also, FIG. 7). There are three ordering modules 702 (see FIG. 7): a Purchasing Card module, a Direct Order module, and a Purchase Order module."). | Structure: There is insufficient structure under Blackboard, 574 F.3d at 1371 to support the recited function. |
| Court's construction | |
| Function: Deciding between a set of ordering modules to submit the requisition for fulfillment by a supplier, where the set of ordering modules includes at least one purchase card module, one direct order |
| module, and one purchase order module |
| Structure: [1] "For each fully approved requisition, [the system] verifies whether a p-card can be used for this purchase: Ensure that the supplier accepts p-cards. If not, chooses a different ordering module." '165 Patent at 20:5-9. [2] "[The system] [c]hecks that the transfer method has been designated for direct order in the item template. If neither the purchase order (PO) or DO order module has been designated in the item template then the supplier profile will be checked for the transfer method. If the supplier profile indicates direct order, then that is the method. Otherwise, it is treated as a PO." '165 Patent at 21:7-14. |
The parties agree that this term is a means-plus-function term, governed by 35 U.S.C. Section 112(f). To construe a means-plus-function term, a court must first identify the function of the limitation. Altiris, Inc., 318 F.3d at 1375. "The court next ascertains the corresponding structure in the written description that is necessary to perform that function." Id. "Structure disclosed in the specification is 'corresponding' structure only if the specification or prosecution history clearly links or associates that structure to the function recited in the claim." Id. (quotation omitted).
"[I]f one employs means-plus-function language in a claim, one must set forth in the specification an adequate disclosure showing what is meant by that language." Blackboard, Inc. v. Desire2Learn, Inc., 574 F.3d 1371, 1382 (Fed. Cir. 2009) (citation omitted). "If the specification does not contain an adequate disclosure of the structure that corresponds to the claimed function, the patentee will have failed to particularly point out and distinctly claim the invention as required by the second paragraph of section 112, which renders the claim invalid for indefiniteness." Id. (internal quotation omitted).
A. Function
The parties dispute whether the function of the 'order generating means' is to choose one or more of the ordering modules (the purchase card module, direct order module, and purchase order module) or whether the function is to choose only one module.
As the words of a claim are to be "given their ordinary and customary meaning," Phillips, 415 F.3d at 1312, the Court finds the language of the claim itself dispositive: "order generating means for deciding between at least one of a purchase card module, a direct order module, and a purchase order module." '165 Patent at 27:16-18. The ordinary and customary meaning of "at least one" is one or more. Construing the claim as allowing for "only one," as Coupa proposes, would impermissibly ignore the plain and ordinary language of the claim itself.
Coupa argues that the specification discloses that the system chooses only one module for any given order. While that may be true, that is beside the point. This claim relates to choosing as many ordering modules as are required for any given requisition. A single requisition may require more than one ordering module, for example if a requisition contains several items which must be fulfilled by two different suppliers, of which one has a purchase card relationship with the ordering company, and the other a direct order relationship.
For the reasons stated above, the Court construes the term as "deciding between a set of ordering modules to submit the requisition for fulfillment by a supplier, where the set of ordering modules includes at least one purchase card module, one direct order module, and one purchase order module."
B. Structure
Ariba argues that "the specification delineates a two-part algorithm within the portion of the specification entitled "Ordering Modules" that is clearly linked to the identified function of choosing at least one ordering module for each line item in a requisition record." Dkt. No. 44 at 9. Coupa responds that "[b]ecause the patent does not specify how the claimed function is performed, i.e., it fails to disclose the specific algorithm for making the decision, it has failed to disclose sufficient corresponding structure." Dkt. No. 49 at 24.
Page citations to the docket are to ECF page numbers.
The Court agrees that the specification discloses sufficient structure corresponding to the "order generating means" function. The specification discloses a two-part algorithm wherein
i) "For each fully approved requisition, [the system] verifies whether a p-card can be used for this purchase: Ensure that the supplier accepts p-cards. If not, chooses a different ordering module." '165 Patent at 20:5-9.If the supplier does not accept a p-card
ii) The system "[c]hecks that the transfer method has been designated for direct
order in the item template. If neither the purchase order (PO) or DO order module has been designated in the item template then the supplier profile will be checked for the transfer method. If the supplier profile indicates direct order, then that is the method. Otherwise, it is treated as a PO." Id. at 21:7-14.
The specification does not need to recite a "highly detailed description of the algorithm;" rather "a description of the function in words may disclose, at least to the satisfaction of one of ordinary skill in the art, enough of an algorithm to provide the necessary structure under § 112, ¶ 6." Typhoon Touch Technologies, Inc. v. Dell, Inc., 659 F. 3d 1376, 1386 (Fed. Cir. 2011). Here, the specification sufficiently describes an algorithm where the system determines whether a purchase card module can used for a purchase and, if so, uses it; if not, the system checks whether the supplier has been approved for a direct order module and if so, uses it; otherwise the system uses the purchase order module. The Court accordingly construes this term as having the function described in the specification of the '165 Patent at columns 20:5-9 and 21:7-14.
2. deciding between at least one of a purchase card module, a direct order module, and a purchase order module to submit the electronic requisition form for fulfillment (claims 35 and 41)
| Ariba's proposed construction | Coupa's proposed construction |
| [Ariba argues that is not a mean-plus-function term] Deciding between a set of ordering modules, the set including at least one purchase card module, one direct order module, and one purchase order module, where the chosen module or modules is/are used as part of the process to prepare an order for one or more line items. | Function: A computer choosing only one module to submit the electronic requisition form for fulfillment, wherein the computer chooses from among at least a purchase card module, a direct order module, and a purchase order module. |
| Structure: There is insufficient structure under Blackboard Inc. v. Desire2Learn Inc., 574 F.3d 1371 (Fed. Cir. 2009), to support the recited function. | |
| Court's construction | |
| Function: Deciding between a set of ordering modules to submit the electronic requisition form for fulfillment, where the set of ordering modules includes at least one purchase card module, one direct order module, and one purchase order module | |
| Structure: [1] "For each fully approved requisition, [the system] verifies whether a p-card can be used for this purchase: Ensure that the supplier accepts p-cards. If not, chooses a different ordering module." '165 Patent at 20:5-9. [2] "[The system] [c]hecks that the transfer method has been designated for direct order in the item template. If neither the purchase order (PO) or DO order module has been designated in the item template then the supplier profile will be checked for the transfer method. If the supplier profile |
| indicates direct order, then that is the method. Otherwise, it is treated as a PO." Id. 21:7-14. |
The parties dispute whether this term is governed by 35 U.S.C. Section 112(f). Coupa argues that the term is governed by Section 112(f) because it is identical to the concededly means-plus-function term in Claim 1, only without the "order generating means for" language. Ariba counters that it does not matter that this term mirrors a means-plus-function claim because "each claim must be independently reviewed" to determine if it is subject to Section 112(f).
There is a presumption that terms that do not contain the "means for" language are not subject to Section 112(f). DePuy Spine, Inc. v. Medtronic Sofamor Danek, Inc., 469 F.3d 1005, 1023 (Fed. Cir. 2006). That presumption "can be rebutted by showing that the claim element recites a function without reciting sufficient structure for performing that function." Id.; Mas-Hamilton Grp. v. LaGard, Inc., 156 F.3d 1206, 1213 (Fed. Cir. 1998) ("Although such a presumption is helpful in beginning the claim construction analysis, it is not the end of the inquiry. In the instant case, even though the catch phrase is not used, the limitation's language does not provide any structure. The limitation is drafted as a function to be performed rather than definite structure or materials.").
The Court finds that the presumption against applying Section 112(f) has been rebutted in this case, not because the term mirrors the means-plus-function term in Claim 1 but because the term "deciding between at least one of a purchase card module, a direct order module, and a purchase order module to submit the electronic requisition form for fulfillment" recites a function—deciding between the modules—without reciting sufficient structure for performing that function. As is the case with the term in Claim 1, the structure corresponding to this function is found in the specification.
Having determined that this term is subject to Section 112(f), the Court sees no reason to construe this term any differently from the nearly identical term addressed above, aside from the differences in the claims themselves. Indeed, Ariba and Coupa proposed functions for this term that are largely identical to their proposed functions for the "order generating means" term.
This term refers to submitting "the electronic requisition form for fulfillment" whereas the 'order generating means' term refers to submitting "the requisition for fulfillment by a supplier."
Ariba's proposed construction uses the word "prepare," while its proposed construction of the "order generating means" term uses the word "submit:" "Deciding between a set of ordering modules, the set including at least one purchase card module, one direct order module, and one purchase order module, where the chosen module or modules is/are used as part of the process to prepare an order for one or more line items." Ariba does not address this difference. In any event, the different is immaterial as the Court does not import this phrase into the construction of either term.
3. approval path determining means, responsive to the requisition record [and] to approval rules in an approval rules database, for determining an approval path for the requisition record, among various ones of a plurality of possible approvers, required to approve the requisition record based on the commentary entry (claim 1)
The "and" is missing from the claim. The Court agrees with Ariba that this is a typographical error. See Hoffer v. Microsoft Corp., 405 F.3d 1326, 1331 (Fed. Cir. 2005) ("When a harmless error in a patent is not subject to reasonable debate, it can be corrected by the court, as for other legal documents.").
| Ariba's proposed construction | Coupa's proposed construction |
| Function: Determining which approvers need to approve the requisition record, and in what order | Function: The phrase "responsive to the requisition record to approval rules in an approval rules database" is unintelligible, and therefore invalid as indefinite. To the extent that phrase is not indefinite, the function is: "in response to the requisition record to approval rules in an approval rules database, determining which approvers need to approve the requisition record, and in what order, wherein the approvers and order is determined based on the commentary entry." |
| Structure: When a request is submitted, approval software (approval engine 110 in FIG. 1; step 322 in FIG. 3; approval flow software 602 of the System Environment 404, in FIG. 6) inspects the approval rules of the company, [and] decides who needs to approve the request . . . ." '165 Patent at 4:18-22 (emphasis added). An example of this structure is shown in Fig. 3c in the following portion: | Structure: There is insufficient structure under Blackboard Inc. v. Desire2Learn Inc., 574 F.3d 1371 (Fed. Cir. 2009), to support the recited function. |
| Image materials not available for display. See also id. at 10:61-63. | |
| Court's construction | |
| Function: Determining which approvers need to approve the requisition record, and in what order | |
| Structure: When a request is submitted, approval software (approval engine 110 in FIG. 1; step 322 in FIG. 3; approval flow software 602 of the System Environment 404, in FIG. 6) inspects the approval rules of the company, [and] decides who needs to approve the request . . . ." '165 Patent at 4:18 22. |
The parties agree that this term is subject to Section 112(f).
A. Function
The parties agree that the function of this term is "determining which approvers need to approve the requisition record, and in what order." The parties dispute whether, as Coupa argues, the function also includes "in response to the requisition record to approval rules in an approval rules database, determining which approvers need to approve the requisition record, and in what order, wherein the approvers and order is determined based on the commentary entry."
The Court finds that the portion of the construction that the parties agree on is appropriate. The phrase "in response to the requisition record [and] to approval rules in an approval rules database" is unwarranted as it goes beyond the function of the term and touches on its structure.
This proposed construction incorporates the typographical error (omission of "and") addressed in footnote 5.
--------
The phrase "wherein the approvers and order is determined based on the commentary entry" is also unwarranted. The parties dispute what "based on the commentary entry" refers to. Ariba argues that it explains "what the approvers do after the path has been determined" and is "unrelated to the determination of the approval path." Dkt. No. 44 at 14. In contrast, Coupa argues that the commentary entry "determines the approval path." Dkt. No. 49 at 22. The Court agrees with Ariba that "based on the commentary entry" modifies "approvers," not "approval path determining means." The specification makes clear that the commentary entry helps approvers approve or deny a requisition; it does not inform the approval path and does not limit the approval-path-determining-means function:
Any employee who handles a requisition, be it requester or approver, can add commentary or attach documents to the requisition, helping everyone who sees it to better understand the requisition. The ability to comment and explain can go a long way toward making requisitions understandable to approvers, allowing them to provide feedback to requesters, and help them make a decision about whether to approve the request.'165 Patent at 10:01-09.
For the reasons stated, the Court construes the function of this term as "determining which approvers need to approve the requisition record, and in what order."
B. Structure
Ariba argues that the "specification describes an algorithm for determining the approval path for each requisition record: the system
(1) checks a set of system-specific if-then statements—"approval rules"; and thenDkt. No. 44 at 15. Coupa responds that the structure is indefinite because "the patent does not disclose how such 'approval software' works, does not disclose the software's specific algorithms as required by law, nor does it disclose any set of approval rules or even how the approval rules are inspected by the 'approval software.'" Dkt. No. 49 at 28. In its reply brief, Ariba counters that "[w]hile the [approval] rules themselves may vary, the algorithm applying these rules is sufficiently defined." Dkt. No. 51 at 17.
(2) applies these conditional statements to determine who needs to approve a requisition, and in what order."
The Court finds that there is sufficient structure disclosed in the specification. The specification discloses that "[w]hen a request is submitted, approval software . . . inspects the approval rules of the company, decides who needs to approve the request, and notifies the first required approvers." '165 Patent at 4:18-22. The specification elsewhere explains that "[a]pproval rules are the conditions that a company uses to decide which approvers are required for a particular requisition." Id. at 5:59-61. The specification notes that "an approval rule may be expressed as a set of conditional expressions, such as 'If the amount of this purchase is over $25,000 and it is for software, then the Information Systems department must approve the purchase.'" Id. at 5:66-6:3. The specification thus describes more than a just an "outcome," as Coupa argues; it describes a means for achieving that outcome.
The authority cited by Coupa does not warrant a finding that there is insufficient structure to support the function. In Blackboard, Inc. v. Desire2Learn, Inc., 574 F.3d 1371, 1384 (Fed. Cir. 2009), the Federal Circuit reviewed a patent claiming an internet-based educational support system. The patent claimed a function of assigning different levels of access to data files on the system based on a user's role in a course. Id. at 1382. The patent holder claimed that the structure that performed the function of assigning different levels of access was a software feature known as the "access control manager" or "ACM." The patent holder explained that
the access control manager assigns an access and control level for the quiz file based on a user's course role by creating an access control list. The access control list created by the access control manager associates user roles with the levels for course data files. For example, it might provide that teachers can create, view, and edit a quiz, while students can only submit a completed quiz.Id. at 1382-83. The Federal Circuit found insufficient structure. The court explained that the "'access control manager' is simply an abstraction that describes the function of controlling access to course materials, which is performed by some undefined component of the system. The ACM is essentially a black box that performs a recited function. But how it does so is left undisclosed." Id. at 1383. The court concluded that the patent "describes an outcome, not a means for achieving that outcome." Id. at 1384 (quotation omitted).
In Net MoneyIN, Inc. v. VeriSign, Inc., 545 F.3d 1359, 1365-67 (Fed. Cir. 2008) the Federal Circuit found that there was insufficient structure to support the function of "generating an authorization indicia in response to queries containing a customer account number and amount." The patent owner argued that the disclosure of a "bank computer" in the specification was sufficient structure because "a person skilled in the art would know that such a computer would be programmed to compare account data and amount data to those data structures and generate an authorization indicia if credit were available." Id. at 1366-67. The court rejected this argument because there was "no dispute in this case that the specification fails to disclose an algorithm by which a general purpose bank computer 'generates an authorization indicia.'" Id. at 1367 (internal punctuation omitted).
Unlike Blackboard, Inc. and Net MoneyIN, Inc., the '165 Patent describes a means for "determining which approvers need to approve the requisition record, and in what order"-the function at issue. The specification describes that "when a request is submitted, approval software . . . inspects the approval rules of the company, decides who needs to approve the request, and notifies the first required approvers, preferably by e-mail, that there is a requisition waiting for their attention." '165 Patent at 4:18-24. This is adequate as it "recites in prose the algorithm to be implemented by the programmer." Typhoon Touch Technologies, Inc., 659 F.3d at 1386. Disclosure of specific approval rules is not necessary as approval rules will, by design, vary between companies. Nor is a highly detailed description of the algorithm necessary. See id. ("a description of the function in words may disclose, at least to the satisfaction of one of ordinary skill in the art, enough of an algorithm to provide the necessary structure under § 112, ¶ 6").
4. approval path handling means for guiding the requisition record along the determined approval path, wherein the approval path handling means generates a global approval indication based on the commentary entry and in response to the requisition record successfully traversing the approval path" (Claim 1)
| Ariba's proposed construction | Coupa's proposed construction |
| Function: Guiding the requisition record along the determined approval path. | Function: Guiding the requisition record along the determined approval path, and generating a global approval indication based on the commentary entry and in response to the requisition record successfully traversing the approval path. |
| Structure: Software that, for each approver, marks the requisition record as approved or rejected or modified, and, if necessary, passes the requisition record to the next required approver. This structure is shown in Fig. 3C of the '165 Patent: | Structure: There is insufficient structure under Blackboard Inc. v. Desire2Learn Inc., 574 F.3d 1371 (Fed. Cir. 2009), to support the recited function. |
| Image materials not available for display. | |
| Court's construction | |
| Function: Guiding the requisition record along the determined approval path. | |
| Structure: An approval will trigger any notifications specified in the business rules for this company, mark the request as approved for this approver, and add the request to the incoming folder for the next approver in the approval chain. '165 Patent at 11:28-32. | |
| When an approver denies a requisition, the system sends an e-mail notification to the requester, and stops any further approval requests in this serial approval chain. If the requester does nothing in response to a notification of denial, the request will eventually time out. If the requester modifies the request and resubmits it, the system starts the approval process again. '165 Patent at 11:35-41. | |
| This structure is shown in Fig. 3C of the '165 Patent: | |
| Image materials not available for display. |
The parties agree that this term is subject to Section 112(f).
Function:
The parties agree that the function of this term is "guiding the requisition record along the determined approval path." Coupa argues that the function also includes "and generating a global approval indication based on the commentary entry and in response to the requisition record successfully traversing the approval path." The Court agrees with Ariba that the disputed language, which follows the "wherein" clause in the term, is the inherent result of "guiding the requisition record along the determined approval path," and therefore does not limit that function. See Griffin v. Bertina, 285 F.3d 1029, 1034 (Fed. Cir. 2002) (wherein clauses limited patent claims because clauses were not the inherent result of performing the claimed steps); Cf Lockheed Martin Corp. v. Space Sys./Loral, Inc., 324 F.3d 1308, 1319 (Fed. Cir. 2003) ("The function is properly identified as the language after the "means for" clause and before the "whereby" clause, because a whereby clause that merely states the result of the limitations in the claim adds nothing to the substance of the claim.").
Structure:
Ariba argues that the "specification discloses an algorithm for moving the requisition along the approval path in response to action taken by each successive approver." Dkt. No. 44 at 18. In support, Ariba cites a structure shown in Figure 3 c, reproduced in the chart above. Ariba concludes that the structure is "software that, for each approver, marks the requisition record as approved or rejected or modified, and, if necessary, passes the requisition record to the next required approver." Coupa responds that Ariba's proposed structure is indefinite because "it does not state how the requisition is guided along a path." Dkt. No. 49 at 26.
The Court need not determine whether Ariba's proposed structure is indefinite because the specification elsewhere provides structure corresponding to the function of "guiding the requisition record along the determined approval path." The specification explains that "[a]n approval will trigger any notifications specified in the business rules for this company, mark the request as approved for this approver, and add the request to the incoming folder for the next approver in the approval chain." '165 Patent at 11:28-32. The specification further explains that "[w]hen an approver denies a requisition, the system sends an e-mail notification to the requester, and stops any further approval requests in this serial approval chain. If the requester does nothing in response to a notification of denial, the request will eventually time out. If the requester modifies the request and resubmits it, the system starts the approval process again." Id. at 11:35-41. Because that structure is clearly linked to the function of "guiding the requisition record along the determined approval path," it corresponds to that function. See Altiris, Inc., 318 F.3d at 1375 (structure disclosed in the specification corresponds to the function "if the specification or prosecution history clearly links or associates that structure to the function recited in the claim"). The Court construes the structure accordingly.
5. Purchase Order Module (Claims 1, 35 and 41)
| Ariba's proposed construction | Coupa's proposed construction |
| Software for ordering operating resources without a direct order agreement. | An ordering module that transmits a fully approved requisition to an ERP system, for generating a purchase order. |
| Court's construction | |
| An ordering module that transmits a requisition to an ERP system, for generating a purchase order |
The parties dispute whether the Purchase Order Module necessarily transmits a requisition to an Enterprise Resource Planning ("ERP") system, which in turn generates the purchase order (as Coupa proposes), or whether the Purchase Order Module can also include a "standalone embodiment" that generates a purchase order when the patented system is not integrated with an ERP system (as Ariba argues). The parties also dispute whether the Purchase Order Module must transmit a "fully approved requisition."
A patent specification "acts as a dictionary when it expressly defines terms used in the claims or when it defines terms by implication." Phillips, 415 F.3d at 1321. The specification of the '165 Patent defines Purchase Order Module under a heading labeled Ordering Modules. '165 Patent at 19:25. The specification states:
The purchase order module is an ordering module whose case results in a purchase requisition in the ERP system. The system transmits the requisition to the ERP adapter, as an ERP requisition. Once the requisition is in the ERP, the Purchasing Agent can manipulate it with standard ERP operations to complete the process. For example, the agent typically autocreates a purchase order from the requisition, prints it out, an [sic] sends it to the supplier for fulfillment.Id. at 21:26-34. Elsewhere the specification explains that once requisitions are in the ERP "they are converted into Purchase Orders on the ERP system." Id. at 23:52-56. The specification thus distinguishes the Purchase Order Module from the Direct Order Module, addressed below, on the basis that the Purchase Order Module transmits requisitions into the ERP where they are converted into purchase orders and then sent to the supplier, whereas the Direct Order Module communicates directly with a supplier without storing the requisition in an ERP system. It would be improper to construe this term in a manner that blurs this distinction. See, e.g., AFG Indus., Inc. v. Cardinal IG Co., Inc., 239 F.3d 1239, 1249 (Fed. Cir. 2001) ("We conclude that the trial court erred by adopting a claim construction that does not distinguish between layers and interlayers. The primary error in the trial court's claim construction is that it eliminates the distinction between these terms that is set forth in the written description of the patent itself."); Bd. of Regents of the Univ. of Texas Sys. v. BENQ Am. Corp., 533 F.3d 1362, 1368 (Fed. Cir. 2008) (specification confirmed that claim terms were not coextensive in scope).
While the last sentence in the block quote above could be read to suggest that the agent might do something other than create a purchase order from a requisition, the name of the module, its differentiation from the Direct Order Module and the definition in the specification support Coupa's argument that the Purchase Order Module transmits the requisition to the ERP, which in turn generates a purchase order.
Ariba argues that "Coupa's proposed construction would improperly limit PO module to a single, disclosed embodiment (the ERP embodiment) while excluding another disclosed embodiment (the standalone embodiment)." Dkt. No. 44 at 25. Ariba is correct that the specification later describes a standalone embodiment where the system is not connected to an ERP. See id. at 26:30-40 (describing "features of the system that are available only to provide basic functionality when the system is stand-alone: when there is no ERP adapter present") (emphasis added). But just because the specification describes a standalone embodiment does not mean that a standalone embodiment is necessarily claimed. Indeed, the Federal Circuit has noted that "[o]ur precedent is replete with examples of subject matter that is included in the specification, but is not claimed." TIP Sys., LLC v. Phillips & Brooks/Gladwin, Inc., 529 F.3d 1364, 1373 (Fed. Cir. 2008). Unlike the language relating to the standalone embodiment, the definition in the specification concerning the Purchase Order Module expressly notes that the Purchase Order Module "results in a purchase requisition in the ERP system." '165 Patent at 21:26-27. Accordingly, it appears that the Purchase Order Module is not employed in the standalone embodiment.
Ariba argues that adding the limitation "fully approved requisition" into the term is incorrect as "Claim 1 nowhere mentions acting on a "fully approved requisition." Dkt. No. 44 at 22-23. The Court agrees. While, as Ariba admits, the specification states that an "ordering module is the piece of the system that takes a fully approved requisition and submits it for fulfillment," there is no reason to import this limitation into the claim term. '165 Patent at 19:26-27.
6. Direct Order Module (Claims 1, 35 and 41)
| Ariba's proposed construction | Coupa's proposed construction |
| An ordering module that supports (but does not require) communication of orders directly between the buyer and supplier without storing the requisition in an ERP system, and wherein any such order is based on a direct order agreement. | An ordering module that transmits a fully approved requisition directly to a supplier based on a direct order agreement, without storing the requisition in an ERP system or generating a purchase order. |
| Court's construction | |
| An ordering module that transmits a requisition directly to a supplier for fulfillment based on a direct order agreement between the company and the supplier, without storing the requisition in an ERP system |
The parties agree that the Direct Order Module is used where there is a direct order agreement with a supplier and communicates directly with a supplier without storing the requisition in an ERP system. Ariba argues, however, that the Direct Order Module supports, but does not require, these features. The parties also dispute whether i) the Direct Order Module submits a requisition to the supplier or whether requisition and order are interchangeable such that the direct order module can submit either a requisition or an order, and ii) whether the Direct Order Module does not generate a purchase order.
The specification states that a "direct order module is an ordering module that supports communication of orders directly between the buyer and supplier, without storing the requisition in an ERP system." '165 Patent at 20:64-67. This definition employs both the terms requisition and order and is thus not helpful in determining which of the two is communicated to the supplier. In the same section regarding direct orders, the specification explains that "[i]f there is a direct order agreement with a supplier, then the system . . . . [t]ransmits the requisition directly to the supplier via fax or e-mail." Id. at 21:4-5, 21:15-16. Consistent with that, Claim 35 discloses "transmitting the electronic requisition form directly to at least one of the plurality of suppliers based on a direct order agreement between a company employing the user and the at least one supplier." Id. at 30:8-11. As noted above, direct orders are differentiated from those in the Purchase Order Module that go through the ERP system and result in a purchase order. The Court therefore concludes that the Direct Order Module transmits a requisition, not an order, to the supplier.
The Court rejects Ariba's proposal that the Direct Order Module "supports (but does not require)" communicating orders directly to the supplier. This language is inconsistent with the specification. Indeed, the specification unambiguously states that the Direct Order Module "transmits the requisition directly to the supplier." Id. at 21:15; 30:8-11. The phrase "supports (but does not require)" is also confusing as Ariba has not explained what the Direct Order Module would do other than place orders directly with the supplier.
The Court sees no reason to import the phrase "without . . . generating a purchase order" into the term. The Court's construction sufficiently distinguishes a Direct Order Module from a Purchase Order Module.
7. Electronic Requisition Form (Claims 35 and 41)
| Ariba's proposed construction | Coupa's proposed construction |
| An electronic form for requesting goods or services. | An electronic form that constitutes a request for approval to purchase goods or services, and lacks a purchase order number and terms and conditions of an offer. |
| Court's construction | |
| An electronic form containing purchasing decision information provided by the user |
The parties dispute whether a requisition is always a request for approval to purchase goods or whether it can be transmitted directly to a supplier for fulfillment, in which case it functions as an order. Ariba argues that the terms "requisition" and "order" are used interchangeably in the specification (Dkt. No. 44 at 22-29), and that in Claims 35 and 41 the Electronic Requisition Form "actually orders goods . . . and is not a 'request for approval' to make that purchase." Dkt. No. 49 at 18. Under Ariba's proposed construction, an Electronic Requisition Form is "any electronic form that is used for requesting goods or services," which could include a purchase order. Id. (emphasis added). Coupa counters that the patent distinguishes between a requisition form and a purchase order, and "[t]he only time that the patent discloses transmitting a requisition to a supplier is in the context of a 'direct order,' not a 'purchase order.'" Dkt. No. 49 at 18.
The term Electronic Requisition Form is only used in Claims 35 and 41. Claim 35 discloses "querying a user with a plurality of purchasing decision questions via a user interface on a client device, wherein the user is to reply to each question by selecting one or more requisition information selections via the user interface." '165 Patent at 29:60-64. The claim then discloses "generating automatically an electronic requisition form based on the selected requisition information." 29:66-67 (emphasis added). The Electronic Requisition Form, then, is an electronic form automatically generated by the system containing purchasing decision information provided by the user.
The parties' proposed constructions, however, focus on what happens to the Electronic Requisition Form after it is generated. Coupa asserts that Ariba's construction is "an attempt to ensnare Coupa's product." Dkt. No. 49 at 17. If that is the case, the Court assumes that Coupa's construction is equally an attempt to avoid ensnaring its product. In any event, the Court is not convinced that either party's construction will aid the jury's understanding of this claim term. Ariba's construction states the alleged purpose of the form, but does not explain the content of the form or how it is created. Coupa's construction states what the form is not and adds a limitation—request for approval—unsupported by the claims.
As noted above, the claims disclose that an Electronic Requisition Form is an electronic form automatically generated by the system containing purchasing decision information provided by the user. Construing the term accordingly will aid the jury's understanding of the claim. The Court's constructions of Direct Order Module and Purchase Order Module address how orders are communicated to suppliers.
CONCLUSION
For the reasons discussed above, the Court construes the disputed terms of the ''165 Patent as follows:
1. "order generating means for deciding between at least one of a purchase card module, a direct order module, and a purchase order module to submit the requisition for fulfillment by a supplier" is a means-plus-function limitation, in which the function is "deciding between a set of ordering modules to submit the requisition for fulfillment by a supplier, where the set of ordering modules includes at least one purchase card module, one direct order module, and one purchase order module." The corresponding structure is "[1] For each fully approved requisition, [the system] verifies whether a p-card can be used for this purchase: Ensure that the supplier accepts p-cards. If not, chooses a different ordering module. [2] [The system] [c]hecks that the transfer method has been designated for direct order in the item template. If neither the purchase order (PO) or DO order module has been designated in the item template then the supplier profile will be checked for the transfer method. If the supplier profile indicates direct order, then that is the method. Otherwise, it is treated as a PO." '165 Patent at 20:5-9, 21:7-14.
2. "deciding between at least one of a purchase card module, a direct order module, and a purchase order module to submit the electronic requisition form for fulfillment" is a means-plus-function limitation, in which the function is "deciding between a set of ordering modules to submit the electronic requisition form for fulfillment, where the set of ordering modules includes at least one purchase card module, one direct order module, and one purchase order module." The corresponding structure is "[1] For each fully approved requisition, [the system] verifies whether a p-card can be used for this purchase: Ensure that the supplier accepts p-cards. If not, chooses a different ordering module. [2] [The system] [c]hecks that the transfer method has been designated for direct order in the item template. If neither the purchase order (PO) or DO order module has been designated in the item template then the supplier profile will be checked for the transfer method. If the supplier profile indicates direct order, then that is the method. Otherwise, it is treated as a PO." '165 Patent at 20:5-9, 21:7-14.
3. "approval path determining means, responsive to the requisition record and to approval rules in an approval rules database, for determining an approval path for
the requisition record, among various ones of a plurality of possible approvers, required to approve the requisition record based on the commentary entry" is a means-plus-function limitation, in which the function is "determining which approvers need to approve the requisition record, and in what order." The corresponding structure is "when a request is submitted, approval software (approval engine 110 in FIG. 1; step 322 in FIG. 3; approval flow software 602 of the System Environment 404, in FIG. 6) inspects the approval rules of the company, [and] decides who needs to approve the request." '165 Patent at 4:18-22.
4. "approval path handling means for guiding the requisition record along the determined approval path, wherein the approval path handling means generates a global approval indication based on the commentary entry and in response to the requisition record successfully traversing the approval path" is a means-plus-function limitation, in which the function is "guiding the requisition record along the determined approval path." The corresponding structure is "an approval will trigger any notifications specified in the business rules for this company, mark the request as approved for this approver, and add the request to the incoming folder for the next approver in the approval chain. When an approver denies a requisition, the system sends an e-mail notification to the requester, and stops any further approval requests in this serial approval chain. If the requester does nothing in response to a notification of denial, the request will eventually time out. If the requester modifies the request and resubmits it, the system starts the approval process again." '165 Patent at 11:28-32, 11:35-41. This structure is shown in Fig. 3C of the '165 Patent.
5. "Purchase Order Module" is "an ordering module that transmits a requisition to an ERP system, for generating a purchase order."
6. "Direct Order Module" is "an ordering module that transmits a requisition directly to a supplier for fulfillment based on a direct order agreement between the company and the supplier, without storing the requisition in an ERP system."
7. "Electronic Requisition Form" is "an electronic form containing purchasing decision information provided by the user."
IT IS SO ORDERED.
____________
WILLIAM H. ORRICK
United States District Judge