SCVNGR, Inc. v. DailyGobble, Inc.

Filing 186

MEMORANDUM OPINION AND ORDER. The Court hereby ADOPTS the claim constructions for the patent-in-suit as set forth in this order. Signed by Magistrate Judge K. Nicole Mitchell on 8/10/2017. (rlf)

IN THE UNITED STATES DISTRICT COURT
FOR THE EASTERN DISTRICT OF TEXAS
TYLER DIVISION
SCVNGR, INC. d/b/a LEVELUP,
v.
DAILYGOBBLE, INC. d/b/a RELEVANT

§
§
§
§
§
§

CASE NO. 6:15-CV-493-JRG-KNM

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
Page 1 of 22

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
Page 2 of 22

(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.

Page 3 of 22

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.

Page 4 of 22

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”
Plaintiff’s Proposed Construction

Defendant’s Proposed Construction

No construction required.

“a data value that is associated with the user’s
identifying information only and is unique from
and contains no information about the token”1

Alternatively:
“a data element referring to a user data
record stored at the claimed server”

Doc. No. 164 at 12; Doc. No. 178, Ex. A at 1 & 4. This term appears throughout the claims of the
patent-in-suit.
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

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.
1

Page 5 of 22

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.

Page 6 of 22

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 nearfield-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.
***
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.
Id. at 2:58–64 & 8:57–61.
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,
Page 7 of 22

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.
Page 8 of 22

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

Page 9 of 22

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”

Page 10 of 22

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.

“a data value that identifies the payment
instrument, but which does not identify the user
and is unique from the code”

Alternatively:
“a data element referring to a data
record stored at a payment processing
entity server”

Doc. No. 164 at 10; Doc. No. 172 at 21; Doc. No. 178, Ex. A at 2 & 5. This term appears
throughout the claims of the patent-in-suit.
Page 11 of 22

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 “tripleblind payment system”).
Page 12 of 22

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 patentin-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”
Plaintiff’s Proposed Construction

Defendant’s Proposed Construction

LevelUp objects to the late inclusion of “an entity responsible for authenticating and
these terms, raised for the first time in actually performing a payment transaction”
Relevant’s responsive claim construction
brief. LevelUp had no opportunity to
respond, and the terms have no bearing on
the pending motion.2
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
2

Page 13 of 22

Doc. No. 172 at 23; Doc. No. 178, Ex. A at 2 & 5.
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 financialprocessing 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.

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.
Page 14 of 22

The Court therefore hereby expressly rejects Defendant’s proposed construction. 3 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).
The Court therefore hereby construes “payment processing entity” to have its plain
meaning.
D. “transferring information characterizing a payment instrument”
Plaintiff’s Proposed Construction

Defendant’s Proposed Construction

LevelUp objects to the late inclusion of “transmitting, by the server, information
these terms, raised for the first time in characterizing a payment instrument”
Relevant’s responsive claim construction
brief. LevelUp had no opportunity to
respond, and the terms have no bearing on
the pending motion.4

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.
3

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.
4

Page 15 of 22

Doc. No. 172 at 24; Doc. No. 178, Ex. A at 2.
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 userentered 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.

No. 178 at 1–2. Likewise, at the July 12, 2017 hearing, Plaintiff presented oral arguments on this
term.
Page 16 of 22

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 unstated Relevant proposes that this Court construe Claim
requirement that claim steps be performed 1 as requiring steps (a-h) to occur sequentially, or
in order.
in the alternative steps (a-b), (c-d-e), and (f-g-h) to
occur sequentially, with (f-g-h) occurring after the
completion of all steps (a-e).
Doc. No. 164 at 13; Doc. No. 178, Ex. A at 7.
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 paymentprocessing 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

Page 17 of 22

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;
Page 18 of 22

[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 clientside 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.

Page 19 of 22

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).

Page 20 of 22

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.

Page 21 of 22

APPENDIX A
Court’s Construction

Terms, Phrases, or Clauses
“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 “transferring, by the server, information
payment instrument”
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).

Page 22 of 22