Opinion
CASE NO. 6:15-CV-493-JRG-KNM
08-10-2017
SCVNGR, INC. d/b/a LEVELUP, v. DAILYGOBBLE, INC. d/b/a RELEVANT
MEMORANDUM OPINION AND ORDER
This Order construes disputed claim terms in United States Patent No. 8,639,619 ("the '619 Patent"). On July 12, 2017, the parties presented oral arguments on disputed terms at a Markman hearing. Based on the analysis stated herein, the Court resolves the parties' claim construction disputes and ADOPTS the constructions set forth below.
BACKGROUND
Plaintiff asserted United States Patent No. 8,639,619 ("the '619 Patent") but accepted a Rule 68 Offer of Judgment prior to any claim construction hearing or any claim construction briefing, and the Court entered a Final Judgment as to Defendant's infringement of Claims 1-2, 4-10, and 12-14. See Doc. No. 88; see also Doc. No. 90, Jan. 14, 2016 Final Judgment. Plaintiff now asserts that Defendant has violated the Final Judgment and the injunction set forth therein and is therefore in contempt.
The '619 Patent, titled "Secure Payment Method and System," issued on January 28, 2014, and bears an earliest priority date of July 13, 2012. The Abstract states:
Representative embodiments of a server-based method of facilitating payment by a user registered with the server include, at the server, generating and storing, for the user, a code readable by a merchant device, transmitting the code to a mobile device of the user, facilitating provision of information characterizing a payment instrument from the user to a payment-processing entity without storing the data at the server, receiving, from the payment-processing entity, a token indicative of the
payment instrument but not encoding data that would enable use of the instrument, associating the token with the user, receiving, from a merchant, the code and a payment amount, matching the received code to the user and retrieving the token associated with the user, and providing the token and the payment amount to the payment-processing entity to facilitate completion of a transaction between the user and the merchant.
APPLICABLE LAW
Claim Construction
"It is a 'bedrock principle' of patent law that 'the claims of a patent define the invention to which the patentee is entitled the right to exclude.'" Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc) (quoting Innova/Pure Water Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). The Court examines a patent's intrinsic evidence to define the patented invention's scope. See id. at 1313-14; see also Bell Atl. Network Servs., Inc. v. Covad Commc'ns Group, Inc., 262 F.3d 1258, 1267 (Fed. Cir. 2001). Intrinsic evidence includes the claims, the rest of the specification, and the prosecution history. See Phillips, 415 F.3d at 1312-13; see also Bell Atl. Network Servs., 262 F.3d at 1267. The Court gives claim terms their ordinary and customary meaning as understood by one of ordinary skill in the art at the time of the invention. See Phillips, 415 F.3d at 1312-13; see also Alloc, Inc. v. Int'l Trade Comm'n, 342 F.3d 1361, 1368 (Fed. Cir. 2003).
Claim language guides the Court's construction of claim terms. Phillips, 415 F.3d at 1314. "[T]he context in which a term is used in the asserted claim can be highly instructive." Id. Other claims, asserted and un-asserted, can provide additional instruction because "terms are normally used consistently throughout the patent." Id. Differences among claims, such as additional limitations in dependent claims, can provide further guidance. Id.
"[C]laims 'must be read in view of the specification, of which they are a part.'" Id. (quoting Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995), aff'd, 517 U.S. 370 (1996)). "[T]he specification 'is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term.'" Id. (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)); accord Teleflex, Inc. v. Ficosa N. Am. Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). In the specification, a patentee may define his own terms, give a claim term a different meaning than the term would otherwise possess, or disclaim or disavow the claim scope. Phillips, 415 F.3d at 1316.
Although the Court generally presumes terms possess their ordinary meaning, this presumption can be overcome by statements of clear disclaimer. See SciMed Life Sys., Inc. v. Advanced Cardiovascular Sys., Inc., 242 F.3d 1337, 1343-44 (Fed. Cir. 2001). This presumption does not arise when the patentee acts as his own lexicographer. See Irdeto Access, Inc. v. EchoStar Satellite Corp., 383 F.3d 1295, 1301 (Fed. Cir. 2004).
The specification may also resolve ambiguous claim terms "where the ordinary and accustomed meaning of the words used in the claims lack sufficient clarity to permit the scope of the claim to be ascertained from the words alone." Teleflex, Inc., 299 F.3d at 1325. For example, "[a] claim interpretation that excludes a preferred embodiment from the scope of the claim 'is rarely, if ever, correct.'" Globetrotter Software, Inc. v. Elan Computer Group Inc., 362 F.3d 1367, 1381 (Fed. Cir. 2004) (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1583 (Fed. Cir. 1996)). But, "[a]lthough the specification may aid the court in interpreting the meaning of disputed language in the claims, particular embodiments and examples appearing in the specification will not generally be read into the claims." Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir. 1988); accord Phillips, 415 F.3d at 1323.
The prosecution history is another tool to supply the proper context for claim construction because a patentee may define a term during prosecution of the patent. Home Diagnostics Inc. v. LifeScan, Inc., 381 F.3d 1352, 1356 (Fed. Cir. 2004) ("As in the case of the specification, a patent applicant may define a term in prosecuting a patent."). The well-established doctrine of prosecution disclaimer "preclud[es] patentees from recapturing through claim interpretation specific meanings disclaimed during prosecution." Omega Eng'g, Inc. v. Raytek Corp., 334 F.3d 1314, 1323 (Fed. Cir. 2003).
The prosecution history must show that the patentee clearly and unambiguously disclaimed or disavowed the proposed interpretation during prosecution to obtain claim allowance. See Middleton Inc. v. 3M Co., 311 F.3d 1384, 1388 (Fed. Cir. 2002); see also Springs Window Fashions LP v. Novo Indus., L.P., 323 F.3d 989, 994 (Fed. Cir. 2003) ("The disclaimer . . . must be effected with 'reasonable clarity and deliberateness.'") (citations omitted). "Indeed, by distinguishing the claimed invention over the prior art, an applicant is indicating what the claims do not cover." Spectrum Int'l v. Sterilite Corp., 164 F.3d 1372, 1378-79 (Fed. Cir. 1988) (quotation omitted). "As a basic principle of claim interpretation, prosecution disclaimer promotes the public notice function of the intrinsic evidence and protects the public's reliance on definitive statements made during prosecution." Omega Eng'g, Inc., 334 F.3d at 1324.
Although "less significant than the intrinsic record in determining the legally operative meaning of claim language," a court may rely on extrinsic evidence to "shed useful light on the relevant art." Phillips, 415 F.3d at 1317 (quotation omitted). Technical dictionaries and treatises may help a court understand the underlying technology and the manner in which one skilled in the art might use claim terms, but such sources may also provide overly broad definitions or may not be indicative of how the term is used in the patent. Id. at 1318. Similarly, expert testimony may aid the Court in determining the particular meaning of a term in the pertinent field, but "conclusory, unsupported assertions by experts as to the definition of a claim term are not useful." Id. Generally, extrinsic evidence is "less reliable than the patent and its prosecution history in determining how to read claim terms." Id.
ANALYSIS
I. Agreed Claim Terms
The parties have not submitted any agreed-upon constructions. See Doc. No. 178, June 30, 2017 Joint Claim Construction Statement and Chart.
II. Disputed Claim Terms
A. "code"
In the parties' June 30, 2017 Joint Claim Construction Statement, "LevelUp . . . objects to Relevant's inclusion of new proposed constructions for the terms 'code' and 'token' for the first time in its responsive claim construction brief." Doc. No. 178 at 2. Plaintiff further asserted, however, that "Relevant's new proposed constructions are nothing more than an attempt to recast its argument that the Court should add an additional, unstated limitation to the claim requiring that the 'code' and 'token' elements utilize [sic, cannot utilize] the same data values." Id. Plaintiff thus did not appear to argue that it has not had an opportunity to address Defendant's arguments in this regard. Moreover, Plaintiff further addressed these arguments at the July 12, 2017 hearing.
Plaintiff argues that "[b]ecause the claims of the '619 patent do not require any form of value, let alone the same or different values, to be used in the claimed 'code' and 'token' data elements, this Court should reject Relevant's proposal to add a requirement to the claim that the elements store different numeric string values." Doc. No. 164 at 8. Plaintiff also argues that "the specification of the '619 patent contradicts Relevant's position." Id. Finally, Plaintiff argues that in the prosecution history cited by Defendant, neither the patentee nor the examiner stated that the "code" and the "token" must be unique values. Id. at 9-10.
As to the term "code" specifically, Plaintiff argues that because "there is also no dispute that the [accused] LPQ-2 system employs a data element corresponding to the claimed 'code,' which Relevant's documentation refers to as the 'code,'" "the Court need not further construe the term 'code' to determine infringement." Doc. No. 164 at 12. Alternatively, Plaintiff proposes a construction but urges that "[t]he claims of the '619 patent do not require any particular form, format, or value for the data stored within the 'code' element." Id.
Defendant responds (with reference to Claim 1, for example) that "it would make no sense to say 'the code is generated by the server' and 'stored on the server' and then 'the code is received from the payment-processor.'" Doc. No. 172 at 8. Moreover, Defendant argues that the last limitation in Claim 1, "providing the code or token alone does not enable completion of the transaction," would have "no meaning whatsoever" if the "code" and the "token" were identical. Id. at 9. Defendant further argues that the specification and the prosecution history are consistent with Defendant's interpretation. Id. at 10-14. Finally, Defendant submits that "[g]iven the clear requirement that the terms 'code' and 'token' be different values and have entirely different functions," Defendant's proposal "is supported by the specification." Id. at 20.
The Summary section of the specification discloses: "In various embodiments, the present invention facilitates secure mobile payments by distributing storage of the transaction-enabling data elements, including the customer's identity and information about the payment instrument, among unrelated parties." '619 Patent at 2:17-21. Disclosed embodiments utilize "a code readable by a merchant device." Id. at 2:45.
On one hand, the specification discloses that "the present invention is not limited to any particular form of code." Id. at 6:28-31. Likewise, the specification discloses that a user can be identified through any of several different types of codes and communication mechanisms:
The code may be a QR code, a bar code, a radio-frequency identification, a near-field-communication signal, an audio signal, and/or an infrared signal. Additionally, the code may be a seed code that can further generate a unique "mature" code readable by a merchant device. The code may be reset, by the server, after a predetermined period of time or upon receiving a request, by the server, from the user.Id. at 2:58-64 & 8:57-61.
* * *
For example, the method of identifier transferred from the customer to the merchant may be irrelevant. The transfer may include a scan of a bar code, a scan of a QR code, a NFC scan, an audio transmission, a video transmission, an IR transmission, a manual input of a code, and so forth.
On the other hand, the claims distinctly recite both a "code" and a "token" within each independent claim. Claim 1 of the '619 Patent, for example, recites (emphasis added):
1. A server-based method of facilitating payment by a user registered with a server, the method comprising, at the server:
using a processor to generate, for the user, a code and store the code in a memory;
transmitting, via a communication module, the code to a mobile device of the user;
transferring information characterizing a payment instrument from the user to a payment-processing entity utilizing a server routing or a redirect client-side script without storing the payment-characterizing information at the server after completion of the registration;
receiving, from the payment-processing entity via the communication module, a token encoding the user's account-identifying information;
using the processor to computationally associate the token with the user;
receiving, from a merchant device via the communication module, the code and a payment amount;
using the processor to match the received code to the user and retrieve the token associated with the user; and
providing the token and the payment amount to the payment-processing entity, via the communication module, to cause completion of a transaction between the user and the merchant,
wherein providing the code or token alone does not enable completion of the transaction.
These distinct recitals of a "code" and a "token" in the same claim weigh in favor of finding that the "code" and the "token" must be distinct from one another. See Becton, Dickinson & Co. v. Tyco Healthcare Grp., LP, 616 F.3d 1249, 1254 (Fed. Cir. 2010) ("Where a claim lists elements separately, the clear implication of the claim language is that those elements are distinct components of the patented invention.") (citation and internal quotation marks omitted); see also Bancorp Servs., LLC v. Hartford Life Ins. Co., 359 F.3d 1367, 1373 (Fed. Cir. 2004) ("the use of both terms in close proximity in the same claim gives rise to an inference that a different meaning should be assigned to each"); CAE Screenplates, Inc. v. Heinrich Fiedler GmbH & Co. KG, 224 F.3d 1308, 1317 (Fed. Cir. 2000) ("In the absence of any evidence to the contrary, we must presume that the use of these different terms in the claims connotes different meanings."). Further, there is no evidence that the patentee used the terms "code" and "token" interchangeably. See Baran v. Med. Device Techs., Inc., 616 F.3d 1309, 1316 (Fed. Cir. 2010).
Such a reading is particularly reinforced by the final limitation of above-reproduced Claim 1, which recites that "providing the code or token alone does not enable completion of the transaction." Plaintiff has argued that this last limitation requires merely that neither the code nor the token contains an account number that can be used to complete a credit card transaction. Doc. No. 164 at 7; see, e.g., '619 Patent at 2:50-52 ("receiving, from the payment-processing entity, a token indicative of the payment instrument but not encoding data that would enable use of the instrument"). The context of the claim, however, as set forth above, is that both the code and the token must be used in order to complete a transaction. Thus, the final limitation of the claim does not pertain to what each of the code and the token can contain but, instead, underscores that both are required in order to complete a transaction.
The parties have also discussed prosecution history in which the patentee distinguished the "Carlson '08" reference, United States Patent Application Publication No. 2008/0319905, which issued as United States Patent No. 8,229,852. The patentee asserted:
Additionally, the Examiner equates the pseudo account identifier [in Carlson '08] to both the code and information characterizing a payment instrument recited in claim 1. Claim 1, however, requires the code to be created for a user, and the code is used to retrieve the token associated with the user; payment-characterizing information specifies the user's payment instrument. By contrast, the pseudo account identifier in Carlson '08 allows the merchant to process a transaction without having knowledge of the customer's real account information; it does not identify the customer for purposes of finding a corresponding token, but instead avoids the need to use anything like a token altogether. Accordingly, the pseudo account identifier is completely irrelevant to the code generated for the user recited in claim 1.Doc. No. 172, Ex. B, Aug. 20, 2013 Response to Non-Final Office Action at 6 (emphasis modified). The patentee's reliance upon a "token" distinct from the "code" should be given effect in the Court's construction. See Typhoon Touch Techs., Inc. v. Dell, Inc., 659 F.3d 1376, 1381 (Fed. Cir. 2011) ("The patentee is bound by representations made and actions that were taken in order to obtain the patent.").
Such a reading is also consistent with the Notice of Allowability in which the examiner stated that the Carlson '08 reference "does not teach or suggest, either by itself or in combination with others, generating a token (separate and distinct from the previously generated code) in a server characterizing the payment instrument . . . ." Doc. No. 172, Ex. B, Nov. 18, 2013 Notice of Allowability at 2; see Salazar v. Procter & Gamble Co., 414 F.3d 1342, 1347 (Fed. Cir. 2005) ("Although unilateral statements by an examiner do not give rise to a clear disavowal of claim scope by an applicant, it does not necessarily follow that such statements are not pertinent to construing claim terms. Statements about a claim term made by an examiner during prosecution of an application may be evidence of how one of skill in the art understood the term at the time the application was filed.").
Thus, the claim language and the prosecution history demonstrate that the "code" and the "token" must be distinct from one another. But although the "code" and the "token" therefore must be identified, constructed, or handled differently or must otherwise be distinguishable from one another, a dispute remains as to whether the "code" and the "token" must have different data values.
Plaintiff urged at the July 12, 2017 hearing that the "code" and the "token" can have the same data value because the data value is irrelevant to the operation of the claimed system. Instead, Plaintiff argued, the claims require merely that a "code" is used by an intermediary to retrieve a "token," and the "token" is sent by the intermediary to the payment processor. In making this argument, Plaintiff acknowledged that the preamble of Claim 1 is limiting at least inasmuch as it requires that the recited method steps are performed "at the server." Defendant appears to agree. See Doc. No. 172 at 24 ("It is clear from the language of the claims that all of the steps of the method of Claim 1 are performed by the server."). Likewise, Claim 8 recites that the server has a processor configured to provide the token to a payment processor.
On balance, Plaintiff has demonstrated that even if the "code" and the "token" have the same data value, the "code" and the "token" may nonetheless be distinguishable by the purposes they serve and the manners in which they are used. The final limitation of Claim 1 is not inconsistent with such an interpretation because the recited steps involve both a "code" and a "token," such that the steps cannot all be carried out with only the "code" alone or only the "token" alone. Also of note as to this final limitation of Claim 1, the claim recites no entity that provides both the "code" and the "token" to another entity. As a result, each of the "code" and the "token" may be distinguishable from each other, at least in part, by which entity is providing the "code" or the "token" rather than necessarily having a different data value for each.
Defendant argued at the July 12, 2017 hearing that the specification contains no disclosure that the purposes of the claimed invention can be achieved by virtue of the payment processor knowing that the token is being provided by the payment intermediary. As Plaintiff acknowledged at the hearing, however, Claim 1 requires that the recited step of "providing the token and the payment amount to the payment-processing entity" is performed "at the server." Thus, the use of an intermediary to provide the token to the payment processor is expressly required by the claim. See also '619 Patent at Fig. 4A.
Finally, Defendant has not sufficiently justified its proposal that a "code" must be "associated with the user's identifying information only" and not any other data. Although the specification discloses, for example, that "the QR code merely identifies the user" (id. at 7:37-38), this is a specific feature of particular disclosed embodiments that should not be imported into the claims. See Phillips, 415 F.3d at 1323.
The Court therefore hereby construes "code" to mean "a data element that is associated with the user's identifying information and that is distinct from the token."
B. "token"
| Plaintiff's Proposed Construction | Defendant's Proposed Construction |
|---|---|
| No construction required.Alternatively:"a data element referring to a datarecord stored at a payment processingentity server" | "a data value that identifies the paymentinstrument, but which does not identify the userand is unique from the code" |
Plaintiff argues that because "there is no dispute that the [accused] LPQ-2 system employs a data element corresponding to the 'token' element of the '619 patent claim," "this Court need not further construe the term 'token' in order to determine infringement." Doc. No. 164 at 10-11. Alternatively, Plaintiff proposes a construction but urges that "[n]either the claims nor the specification require any particular form, format, or value for the data stored within the 'token' element." Id. at 11.
Defendant responds that "[t]he specification makes plain that a 'token' 'identifies the payment instrument, but which [sic] does not identify a User U.'" Doc. No. 172 at 22 (quoting '619 Patent at 6:49-54) (emphasis Defendant's).
As discussed above, the "code" and the "token" must be distinct from one another but need not necessarily have different data values. Further, the Summary section of the specification is consistent with Defendant's proposal that a "token" does not identify a user:
In various embodiments, the present invention facilitates secure mobile payments by distributing storage of the transaction-enabling data elements, including the customer's identity and information about the payment instrument, among unrelated parties. Because the customer's data is stored by multiple parties, unauthorized access to the records of any single party in the transaction flow will not enable a thief to "spoof" the user's identity and initiate transactions under his name. In addition, the customer's information may be distributed so that various parties directly involved in a payment transaction receive no information about the customer's information stored by other parties. The parties that are involved in a payment transaction thereby cannot store any payment-relevant information transmitted from other parties. For example, in a "triple blind" payment system, none of the paying party (i.e., the customer), the party receiving the payment (i.e., the merchant), or the party facilitating the payment (i.e., the identity and payment manager) possesses both the customer's identity and the underlying payment instrument (e.g., a credit-card or debit-card number) or any data that could be used to reverse engineer or "spoof" the instrument. Accordingly, the customer's identity and privacy is highly secure and the possibility of financial losses for the customer is minimized during a mobile-payment transaction.'619 Patent at 2:17-40; see id. at 6:52-54 (quoted above) & 7:63-8:1 (similar regarding "triple-blind payment system").
On balance, Defendant has demonstrated that a "token," in the context of the specification and the claimed invention, does not identify the user. See, e.g., Verizon Servs. Corp. v. Vonage Holdings Corp., 503 F.3d 1295, 1308 (Fed. Cir. 2007) (finding that disclosures describing "the features of the 'present invention' as a whole" can limit the scope of the claims); VirnetX, Inc. v. Cisco Sys., Inc., 767 F.3d 1308, 1318 (Fed. Cir. 2014) (noting that "the Summary of the Invention gives primacy to these attributes").
Finally, Plaintiff has referred to Defendant's documentation that refers to the accused system using a "token" (see Doc. No. 139 at Ex. 9), but this is extrinsic evidence and therefore, to whatever extent it is relevant, it is less probative than how the term "token" is used in the patent-in-suit. See Phillips, 415 F.3d at 1317 ("while extrinsic evidence can shed useful light on the relevant art, we have explained that it is less significant than the intrinsic record in determining the legally operative meaning of claim language") (citations and internal quotation marks omitted).
The Court therefore hereby construes "token" to mean "a data element that identifies the payment instrument, does not identify the user, and is distinct from the code."
C. "payment processing entity"
In the parties' June 30, 2017 Joint Claim Construction Statement, "LevelUp objects to Relevant's inclusion of th[is] proposed construction[] for the first time in a responsive claim construction brief, to which LevelUp had no opportunity to respond, and because the proposed construction[s] ha[s] no bearing on LevelUp's pending motion for contempt sanctions concerning Relevant's LPQ-2 System." Doc. No. 178 at 1-2. "Defendant contends that inclusion of the additional terms [is] appropriate to resolving all outstanding claim construction issues. Defendant does not oppose Plaintiff filing a limited Responsive claim construction brief on the additional terms or incorporating by reference Plaintiff's claim construction arguments in its June 21, 2017 Reply Contempt Brief." Doc. No. 178 at 2 (citing Doc. No. 174). At the July 12, 2017 hearing, Plaintiff presented additional responsive argument on the merits.
Defendant argues that the claims and the specification refer to a "payment processing entity" as both authenticating and actually performing a payment transaction. Doc. No. 172 at 23. At the July 12, 2017 hearing, Plaintiff responded that Defendant is attempting to limit this term to "direct" payment processors, thereby excluding "indirect" payment processors. Plaintiff also presented argument on this issue in its Reply in Support of Second Renewed Motion for Contempt Sanctions. See Doc. No. 174 at 4-6.
The specification discloses "direct" and "indirect" payment processing entities as well as a "third-party payment gateway":
The payment server 110 may be operated by a payment-processing entity responsible for authenticating and actually performing the payment transaction. For example, a so-called "direct" payment processor represents the financial-processing backend provider to credit-card issuers and payment services such as PAYPAL. An "indirect" payment processor is an independent entity processing transactions for multiple payment services and maintains its own records and data.'619 Patent at 4:44-52 (emphasis added); see id. at 6:45-7:10 ("third-party payment gateway"); see also id. at 7:16-18 ("the management server 106 uses the stored token to initiate the payment transaction through the third-party payment gateway 320").
In light of these disclosures, Defendant has not demonstrated that the claims or the specification attribute any significance to whether the "payment processing entity" actually carries out a transaction itself or instead directs another entity to do so.
The Court therefore hereby expressly rejects Defendant's proposed construction. No further construction is necessary. See U.S. Surgical Corp. v. Ethicon, Inc., 103 F.3d 1554, 1568 (Fed. Cir. 1997) ("Claim construction is a matter of resolution of disputed meanings and technical scope, to clarify and when necessary to explain what the patentee covered by the claims, for use in the determination of infringement. It is not an obligatory exercise in redundancy."); see also O2 Micro Int'l Ltd. v. Beyond Innovation Tech. Co., 521 F.3d 1351, 1362 (Fed. Cir. 2008) ("[D]istrict courts are not (and should not be) required to construe every limitation present in a patent's asserted claims."); Finjan, Inc. v. Secure Computing Corp., 626 F.3d 1197, 1207 (Fed. Cir. 2010) ("Unlike O2 Micro, where the court failed to resolve the parties' quarrel, the district court rejected Defendants' construction."); ActiveVideo Networks, Inc. v. Verizon Commcn's, Inc., 694 F.3d 1312, 1326 (Fed. Cir. 2012); Summit 6, LLC v. Samsung Elecs. Co., 802 F.3d 1283, 1291 (Fed. Cir. 2015).
Having thus rejected Defendants' proposed construction, the Court does not reach Plaintiff's additional argument that "Relevant's proposed construction of the phrase 'payment processing entity' is further improper because it would exclude . . . the infringing LPQ-1 system." Doc. No. 174 at 5; see Doc. No. 88; see also Doc. No. 90, Jan. 14, 2016 Final Judgment.
The Court therefore hereby construes "payment processing entity" to have its plain meaning.
D. "transferring information characterizing a payment instrument"
In the parties' June 30, 2017 Joint Claim Construction Statement, the parties presented the same comments for this term as for the term "payment processing entity" (addressed above). See Doc. No. 178 at 1-2. Likewise, at the July 12, 2017 hearing, Plaintiff presented oral arguments on this term. --------
Defendant argues that "[i]t is clear from the language of the claims that all of the steps of the method of Claim 1 are performed by the server." Doc. No. 172 at 24. Defendant urges: "The 'server' recited in the preamble of the claim serves antecedent basis for the server recited in the body of the claim. Furthermore, the preamble makes clear that the claimed method steps must occur 'at the server.'" Id.
As to Defendant's proposal of "by the server," Plaintiff acknowledged (during discussion of the above-addressed "code" and "token" terms) that the preamble phrase "at the server" is a limitation such that the steps of Claim 1 are performed at the recited server.
At the July 12, 2017 hearing, Plaintiff argued that Defendant's proposal of "transmitting" should be rejected because "transmitting" is narrower than "transferring." Figure 4A and the accompanying written description disclose data passing directly from the user device to the payment processor:
To register the payment instrument, the user first issues a registration request to the identity manager (step 412). Upon receiving the request, the identity manager responds with a registration form (e.g., in the form of a web page) in which the user can enter information about the payment instrument (step 414). A client-side script accompanies the registration form and, when executed, the script causes the user-entered data to be submitted directly to a third-party payment processor's gateway (step 416).'619 Patent at 8:18-27 (emphasis added). The Court therefore rejects Defendant's proposal that the intermediate server must itself transmit the payment instrument information. Instead, consistent with the above-reproduced disclosure, the intermediate server can effect the transfer without itself transmitting the information to the payment processor.
The Court therefore hereby construes "transferring information characterizing a payment instrument" to mean "transferring, by the server, information characterizing a payment instrument."
E. Order of Steps in Claim 1
| Plaintiff's Proposed Construction | Defendant's Proposed Construction |
|---|---|
| The Court should not read-in an unstatedrequirement that claim steps be performedin order. | Relevant proposes that this Court construe Claim1 as requiring steps (a-h) to occur sequentially, orin the alternative steps (a-b), (c-d-e), and (f-g-h) tooccur sequentially, with (f-g-h) occurring after thecompletion of all steps (a-e). |
Plaintiff argues: "In the '619 patent specification, not only is there no statement that the order of steps is important, the specification expressly describes that the invention is not intended to be limited to any 'ordered' recitation of steps." Doc. No. 164 at 13-14 (citing '619 Patent at 11:16-18). Plaintiff further argues: "The step of 'receiving . . . a token . . .' from the payment-processing entity ensures, or confirms, that the transaction server (i.e., LevelUp) has established the proper 'associat[ion]' between user and token. So long as that proper association is established, claim 1 of the '619 patent is agnostic and silent as to whether the token is stored by the transaction server before or after receiving it in a confirming communication from the payment processing entity." Doc. No. 164 at 14.
Defendant responds that "[t]he claim language of Claim 1 of the '619 Patent makes clear that an inherent order exists and the steps must be performed in the order recited, as each step refers back to material recited in the preceding step . . . ." Doc. No. 172 at 15.
As a threshold matter, Plaintiff has argued that Defendant's assertion that Claim 1 requires an order of steps is untimely. Doc. No. 164 at 13. No claim construction proceedings or briefing occurred prior to the present claim construction briefing, and Plaintiff has had opportunities to address Defendant's argument in Plaintiff's opening claim construction brief and at the July 12, 2017 hearing. Further, although Plaintiff argues that it did not have an opportunity to conduct discovery regarding Defendants' asserted order of steps (Doc. No. 164 at 3 n.2), Plaintiff has not shown with particularity what discovery it would have undertaken or how such discovery would have been probative, particularly in light of the primacy of the claim language and the specification during claim construction. Thus, to whatever extent Plaintiff is requesting that Defendant's proposed construction be stricken, Plaintiff's request is hereby denied.
"As a general rule, '[u]nless the steps of a method [claim] actually recite an order, the steps are not ordinarily construed to require one.'" Mformation Techs., Inc. v. Research in Motion Ltd., 764 F.3d 1392, 1398 (Fed. Cir. 2014) (quoting Interactive Gift Express, Inc. v. Compuserve, Inc., 256 F.3d 1323, 1342 (Fed. Cir. 2001)). Courts apply a two-part test to determine whether a particular order of steps in a method claim is required: "First, we look to the claim language to determine if, as a matter of logic or grammar, they must be performed in the order written," and "[i]f not, we next look to the rest of the specification to determine whether it directly or implicitly requires such a narrow construction." Altiris, Inc. v. Symantec Corp., 318 F.3d 1363, 1369-70 (Fed. Cir. 2003) (citation omitted). Here, the specification discloses that "various forms of the flows shown above may be used, with steps re-ordered, added, or removed." '619 Patent at 11:16-18.
Nonetheless, Claim 1 of the '619 Patent recites (emphasis added; steps lettered for ease of reference):
1. A server-based method of facilitating payment by a user registered with a server, the method comprising, at the server:
[a] using a processor to generate, for the user, a code and store the code in a memory;
[b] transmitting, via a communication module, the code to a mobile device of the user;
[c] transferring information characterizing a payment instrument from the user to a payment-processing entity utilizing a server routing or a redirect client-side script without storing the payment-characterizing information at the server after completion of the registration;
[d] receiving, from the payment-processing entity via the communication module, a token encoding the user's account-identifying information;
[e] using the processor to computationally associate the token with the user;
[f] receiving, from a merchant device via the communication module, the code and a payment amount;
[g] using the processor to match the received code to the user and retrieve the token associated with the user; and
[h] providing the token and the payment amount to the payment-processing entity, via the communication module, to cause completion of a transaction between the user and the merchant,
wherein providing the code or token alone does not enable completion of the transaction.
Defendant has not demonstrated that all of the recited steps must be performed in the order recited, but the plain language of the claim nonetheless requires several orderings of steps "as a matter of logic." Mformation, 764 F.3d at 1398.
Step (b) recites "transmitting . . . the code" generated in step (a), so step (a) must be performed before step (b).
Step (c) refers to "transferring information characterizing a payment instrument from the user to a payment-processing entity," and step (d) refers to receiving, from the payment-processing entity, "a token encoding the user's account-identifying information." At the July 12, 2017 hearing, Defendant argued that the antecedent basis for "the user's account-identifying information" in step (d) is the "information characterizing a payment instrument" in step (c). Defendant argued that this antecedent basis demonstrates that step (c) must occur before step (d). Further, Defendant urged that if step (c) is not thereby found to provide antecedent basis for step (d), then step (d) renders the claim indefinite because of lack of antecedent basis.
On balance, the implicit antecedent basis for "the user's account-identifying information" in step (d) is the "information characterizing a payment instrument" in step (c). See Energizer Holdings Inc. v. Int'l Trade Comm'n, 435 F.3d 1366, 1371 (Fed. Cir. 2006) (holding that "an anode gel comprised of zinc as the active anode component" provided implicit antecedent basis for "said zinc anode"); see also Nichia Corp. v. Everlight Ams., Inc., 855 F.3d 1328, 1335-36 (Fed. Cir. 2017) ("We recognize that, in some patents, a distinction between terms may imply a difference in meaning, but this is no hard-and-fast rule."). This information must be transferred in step (c) before a token encoding that information can be received in step (d). See Mformation, 764 F.3d at 1398. Thus, step (c) must be performed before step (d).
Step (e) recites "associat[ing] the token" received in step (d), so step (d) must be performed before step (e). Plaintiff appears to argue that the objectives of the patent could be achieved without this required order of steps (see Doc. No. 164 at 14), but Plaintiff's argument is unavailing because "using the processor to computationally associate the token with the user" in step (e) requires the token to have been received, and the token is received in step (d). See Mformation, 764 F.3d at 1398; see also Mantech Envtl. Corp. v. Hudson Envtl. Servs., Inc., 152 F.3d 1368, 1376 (Fed Cir. 1998) ("the sequential nature of the claim steps is apparent from the plain meaning of the claim language").
Step (f) recites "receiving . . . the code" generated in step (a), so step (a) must be performed before step (f).
Step (g) refers to "the received code" (received in step (f)) and "the token associated with the user" (received in step (d) and associated in step (e)), so steps (d), (e), and (f) must be performed before step (g).
Step (h) refers to the "token" received in step (d) and the "payment amount" received in step (f), so steps (d) and (f) must be performed before step (h).
Defendant has not demonstrated that any other particular orderings of steps are required. Defendant has cited disclosures regarding other orderings of steps in the specification. See '619 Patent at 5:50-7:41, Fig. 4A & Fig. 4B. These specific features of particular disclosed embodiments should not be imported into the claim. See Phillips, 415 F.3d at 1323.
The Court therefore hereby construes Claim 1 to require the orderings of steps set forth above.
CONCLUSION
The Court hereby ADOPTS the above claim constructions for the patent-in-suit. For ease of reference, the Court's claim interpretations are set forth in a table in Appendix A.
So ORDERED and SIGNED this 10th day of August, 2017.
/s/_________
K. NICOLE MITCHELL
UNITED STATES MAGISTRATE JUDGE
APPENDIX A
Terms, Phrases, or Clauses Court's Construction "code" "a data element that is associated with the user's identifying information and that is distinct from the token" "token" "a data element that identifies the payment instrument, does not identify the user, and is distinct from the code" "payment processing entity" Plain meaning "transferring information characterizing a payment instrument" "transferring, by the server, information characterizing a payment instrument" Order of Steps in Claim 1 Step (a) must be performed before step (b). Step (c) must be performed before step (d). Step (d) must be performed before step (e). Step (a) must be performed before step (f). Steps (d), (e), and (f) must be performed before step (g). Steps (d) and (f) must be performed before step (h).