Trials@uspto.gov
`571-272-7822
`
`Paper 9
`Date: July 10, 2023
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`v.
`FINTIV, INC.,
`Patent Owner.
`
`IPR2023-00399
`Patent 9,208,488 B2
`
`
`
`
`
`
`
`
`
`Before MICHAEL R. ZECHER, GEORGE R. HOSKINS, and
`JULIET MITCHELL DIRBA, Administrative Patent Judges.
`DIRBA, Administrative Patent Judge.
`
`
`
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`
`
`571-272-7822
`
`Paper 9
`Date: July 10, 2023
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner,
`v.
`FINTIV, INC.,
`Patent Owner.
`
`IPR2023-00399
`Patent 9,208,488 B2
`
`
`
`
`
`
`
`
`
`Before MICHAEL R. ZECHER, GEORGE R. HOSKINS, and
`JULIET MITCHELL DIRBA, Administrative Patent Judges.
`DIRBA, Administrative Patent Judge.
`
`
`
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`On December 22, 2022, Apple Inc. (“Petitioner”) filed a Petition
`requesting inter partes review of claims 1–22 of U.S. Patent No. 9,208,488
`B2 (Ex. 1001, “the ’488 patent”). Paper 2 (“Pet.”). Fintiv, Inc. (“Patent
`Owner”) filed a Preliminary Response. Paper 6 (“Prelim. Resp.”).1
`An inter partes review may not be instituted unless “the information
`presented in the petition . . . and any response . . . shows that there is a
`reasonable likelihood that the petitioner would prevail with respect to at least
`1 of the claims challenged in the petition.” 35 U.S.C. § 314(a).
`Having reviewed the parties’ papers and the evidence of record, we
`determine that Petitioner has shown a reasonable likelihood it will prevail in
`establishing the unpatentability of at least one challenged claim.
`Accordingly, we institute an inter partes review.
`
`I. BACKGROUND
`A. Related Matters
`The parties indicate that the ’488 patent has been asserted in Fintiv,
`Inc. v. PayPal Holdings, Inc., 6:22-cv-00288 (W.D. Tex.). Pet. 1; Paper 4
`(Patent Owner Mandatory Notices), 1.
`Petitioner also identifies IPR2023-00398, in which Petitioner
`challenges claims 1–22 of U.S. Patent No. 10,438,196, which is related to
`the ’488 patent. Pet. 1. Concurrently with this Decision, we issue a decision
`instituting an inter partes review in that proceeding.
`
`B. The Petition’s Asserted Ground
`Petitioner asserts the following ground of unpatentability (Pet. 5–83):
`
`1 Although the Preliminary Response was filed on April 12, 2023, one day
`after its deadline, we accorded it a filing date of April 11, 2023. Paper 7.
`
`2
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`
`Claim(s) Challenged 35 U.S.C. 2 §
`
`Reference(s)/Basis
`
`1–22
`
`103(a)
`
`Dill3, Vadhri4, Akashika5
`
`In support, Petitioner relies on the testimony of Henry Houh, Ph. D.
`(Ex. 1003). Patent Owner relies on the testimony of Michael I. Shamos,
`Ph.D. (Ex. 2001) to support the arguments in its Preliminary Response.6
`
`C. The ’488 Patent
`The ’488 patent is titled “Using a Mobile Wallet Infrastructure to
`Support Multiple Mobile Wallet Providers,” and the application leading to
`this patent was filed on November 19, 2012, claiming priority to an
`application filed on November 21, 2011. Ex. 1001, codes (22), (54), (60).
`The ’488 patent is directed to “performing a transaction using a third
`party mobile wallet.” Ex. 1001, code (57). Figure 1 (reproduced below)
`“illustrates a monetary transaction system architecture in which
`embodiments [of the ’488 patent] . . . may operate.” Id. at 2:64–65.
`
`
`2 The Leahy-Smith America Invents Act (“AIA”), Pub. L. No. 112-29, 125
`Stat. 284, 285–88 (2011), revised 35 U.S.C. § 103 effective March 16, 2013.
`Because the challenged patent was filed before March 16, 2013, we refer to
`the pre-AIA version of § 103.
`3 US 2009/0265272 A1, published Oct. 22, 2009 (Ex. 1005).
`4 US 2010/0133334 A1, published Jun. 3, 2010 (Ex. 1006).
`5 US 2009/0217047 A1, published Aug. 27, 2009 (Ex. 1007).
`6 Most of Patent Owner’s citations to Exhibit 2001 refer to the wrong
`paragraphs of Dr. Shamos’s declaration. To provide guidance to the parties,
`we have attempted to locate, consider, and (as appropriate) address the
`paragraphs of Exhibit 2001 that are germane to the issues discussed.
`However, the Board is not obligated to search the record for evidence to
`support a party’s arguments, and the parties should assume that the Board
`will not do so in its final written decision.
`
`3
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`
`
`
`As shown above, Figure 1 provides an exemplary platform functional
`architecture that includes (among other things) integration tier 101,
`notification services 102, service connectors 103, payment handler 105,
`security services 106, authorization services 107, database 108, rules engine
`109, channels 111, notifications 112, third party systems 113, and processor
`121. Id. at 9:45–46, Fig. 1. “Integration tier 101 is configured to manage
`mobile wallet sessions and maintain integrity of financial transactions,” and
`it can include “communication mechanisms to accept messages from
`channels 111.” Id. at 9:46–51; see also id. at Fig. 1 (showing various
`channels 111 including, for example, “Web,” “POS [point of sale],”
`“iphone,” and “Android”). “Notification services 102 is configured to send
`various notifications through different notification channels 112, such as, for
`
`4
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`example, Short Message Peer-to-Peer (‘SSMP’) for Short Messaging Service
`(‘SMS’) and Simple Mail Transfer Protocol (‘SMTP’) for emails.” Id. at
`9:57–62. “Service connectors 103 are a set of connectors configure[d] to
`connect to 3rd party systems 113.” Id. at 9:64–65. “Payment handler 105 is
`configured to wrap APIs[7] of different payment processors, such as, for
`example, banking accounts, credit/debit cards or processor 121,” and
`“exposes a common API to facilitate interactions with many different kinds
`of payment processors.” Id. at 10:4–9. “Security services 106 are
`configured to perform subscriber authentication” (id. at 10:10–11), and
`“[a]uthorization services 107 are configured to perform client authorization,
`such as, for example, using a database-based Access Control List (‘ACL’)
`table” (id. at 10:11–14). Database 108 manages accounts, transaction
`histories, and customer profiles (id. at 10:15–21), and rules engine 109
`“enforce[s] business constraints, such as, for example, transactions and
`platform license constraints” (id. at 10:24–26). Finally, “[t]ransaction
`processor 121 is configured to manage financial accounts and transactions,”
`and it “can be used to hold, load, withdraw and deposit funds to mobile
`wallet accounts.” Id. at 10:30–33.
`
`D. Challenged Claims
`Petitioner challenges claims 1–22 of the ’488 patent. Of these,
`claims 1, 11, and 22 are independent, and for purposes of this Decision,
`claim 1 is representative. Claim 1 recites:
`[1.0] A computing system for facilitating management of a
`mobile wallet, including:
`
`
`7 The ’488 patent does not appear to define “API.” We understand it to
`mean “Application Program Interface.” See Ex. 1006 ¶ 48.
`
`5
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`[1.1] one or more processors;
`[1.2] system memory;
`[1.3] [A] an integration tier configured to manage mobile wallet
`sessions with a mobile device and [B] including web services
`communication mechanisms for interfacing with a mobile
`wallet application installed on a hardware SIM[8] card [C] as
`well as with a plurality of different device types over a plurality
`of different communication channels, [D] the integration tier
`being configured to receive binary and text messages from the
`mobile device;
`[1.4] [A] a notification services engine configured to interface
`with the integration tier and [B] to send Short Message Peer-to-
`Peer (SSMP) messages, Short Messaging Service (SMS)
`messages and Simple Mail Transfer Protocol (SMTP) messages
`over the different communication channels to different devices,
`[C] including the mobile device, to interface with the mobile
`wallet application installed on the hardware SIM card;
`[1.5] [A] service connectors that are each configured to connect
`the computing system to a different third party system, [B] each
`of the service connectors being configured as a separate module
`for integrating a corresponding external service to the
`computing system;
`[1.6] a payment handler that exposes a common API for
`interacting with different payment processors;
`[1.7] a security services engine that performs subscriber
`authentication utilizing a database-based Access Control List
`(ACL);
`[1.8] a rules engine configured to enforce constraints on
`financial transactions performed with the mobile wallet
`application, the mobile wallet application being associated with
`a mobile wallet account; and
`[1.9] one or more computer-readable storage media having
`stored thereon computer-executable instructions that are
`
`8 According to the ’488 patent, SIM refers to “subscriber identity module.”
`Ex. 1001, 6:58–67.
`
`6
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`executable by the one or more processors to cause the
`computing system to perform a transaction for a customer using
`the mobile wallet which is owned by another entity than the
`customer, comprising the following:
`[1.10] [A] the computing system receiving
`communication from an agent terminal over one of a
`plurality of communication channels connected to the
`cloud-based transaction platform, [B] the agent
`communication indicating that a customer desires to
`perform a transaction comprising a mobile wallet
`transaction using a third party mobile wallet, [C] the
`mobile wallet transaction comprising at least one of a
`mobile wallet transfer in which funds are transferred
`from the mobile wallet of the customer to a third party
`mobile wallet, a mobile wallet withdrawal in which funds
`are withdrawn from the third party mobile wallet and
`provided to the customer, or a mobile wallet deposit in
`which funds are deposited into the third party mobile
`wallet;
`[1.11] the computing system sending the agent
`communication to the third party mobile wallet platform;
`[1.12] [A] the computing system determining whether the
`mobile wallet transaction comprises the mobile wallet
`withdrawal and [B] when the mobile wallet transaction is
`determined to comprise the mobile wallet withdrawal,
`generating and providing a perishable withdrawal code to
`the consumer, which is presented to the agent terminal to
`facilitate processing of the mobile wallet withdrawal;
`[1.13] the computing system receiving communication
`from the third party mobile wallet platform confirming
`processing of the transaction, the transaction comprising
`at least one of the mobile wallet transfer, the mobile
`wallet withdrawal or the mobile wallet deposit; and
`[1.14] the computing system sending communication to
`the agent terminal over one of a plurality of
`communication channels connected to the cloud-based
`
`7
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`transaction platform, the communication indicating
`confirmation of the processing of the transaction.
`Ex. 1001, 23:25–24:32 (reference numbers and letters added to show
`reference designations used by Petitioner).
`
`II. ANALYSIS
`A. Legal Standards
`“In an [inter partes review], the petitioner has the burden from the
`onset to show with particularity why the patent it challenges is
`unpatentable.” Harmonic Inc. v. Avid Tech., Inc., 815 F.3d 1356, 1363 (Fed.
`Cir. 2016) (citing 35 U.S.C. § 312(a)(3) (requiring inter partes review
`petitions to identify “with particularity . . . the evidence that supports the
`grounds for the challenge to each claim”)). This burden of persuasion never
`shifts to the patent owner. Dynamic Drinkware, LLC v. Nat’l Graphics, Inc.,
`800 F.3d 1375, 1378 (Fed. Cir. 2015).
`The legal question of obviousness is resolved on the basis of
`underlying factual determinations including (1) the scope and content of the
`prior art; (2) any differences between the claimed subject matter and the
`prior art; (3) the level of ordinary skill in the art; and (4) when in evidence,
`objective evidence of nonobviousness.9 Graham v. John Deere Co. of Kan.
`City, 383 U.S. 1, 17–18 (1966). One seeking to establish obviousness based
`on more than one reference also must articulate sufficient reasoning with
`rational underpinnings to combine teachings. See KSR Int’l Co. v. Teleflex
`Inc., 550 U.S. 398, 418 (2007).
`
`
`9 The current record does not include allegations or evidence of objective
`indicia of nonobviousness.
`
`8
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`B. Level of Ordinary Skill in the Art
`Petitioner asserts that the level of ordinary skill in the art corresponds
`to “a bachelor’s degree in electrical engineering, computer science, or
`equivalent training, and approximately two years of work experience in
`software development with a basic knowledge of accounting.” Pet. 4.
`Petitioner also asserts that an ordinary artisan “would have had a working
`knowledge of mobile payment systems and techniques pertinent to the ’488
`patent,” and that a “[l]ack of work experience can be remedied by additional
`education, and vice versa.” Id. at 3–4 (citing Ex. 1003 ¶¶ 21–23).
`At this stage, Patent Owner does not address the level of ordinary skill
`in the art. See Prelim. Resp.
`For purposes of this Decision, we determine that a person of ordinary
`skill in the art would have had “a bachelor’s degree in electrical engineering,
`computer science, or equivalent training, and approximately two years of
`work experience in software development with a basic knowledge of
`accounting” and “working knowledge of mobile payment systems and
`techniques,” as Petitioner proposes. Pet. 3–4. We are satisfied that this
`definition generally comports with the level of skill necessary to understand
`and implement the teachings of the ’488 patent and the asserted prior art.
`See Ex. 1003 ¶ 22; Ex. 2001 ¶ 35 (agreeing with this articulation of the level
`of ordinary skill).
`To the extent the level of ordinary skill in the art is in dispute or
`makes a material difference in the obviousness analysis, the parties should
`brief their respective positions in this regard during trial.
`
`9
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`
`C. Claim Construction
`We interpret claim terms using “the same claim construction standard
`that would be used to construe the claim in a civil action under 35 U.S.C.
`282(b).” 37 C.F.R. § 42.100(b). Under the principles set forth by our
`reviewing court, the “words of a claim ‘are generally given their ordinary
`and customary meaning,’” as would have been understood by a person of
`ordinary skill in the art in question at the time of the invention. Phillips v.
`AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc) (quoting
`Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)).
`Petitioner proposes a construction for a phrase found in some of the
`dependent claims (i.e., “debiting the third party mobile wallet by the
`specified amount of funds”), but asserts that no other terms or phrases
`require a specific construction for this proceeding. Pet. 4–5. Patent Owner
`presents several claim construction arguments that apply to all claims.
`Prelim. Resp. 7–13. We address each of these arguments to provide
`guidance to the parties for the upcoming trial. If either party disagrees with
`our analysis, it should explain its position at trial.10
`
`1. “mobile device”
`All independent claims recite a “mobile device.” Patent Owner
`contends that the claimed “mobile device” is a “physical device that is
`mobile, such as a phone or tablet.” Prelim. Resp. 8–10 (citing Ex. 1001,
`11:14–16, 12:7–12; Ex. 2001 ¶ 38). According to Patent Owner, the Board
`
`
`10 The parties must comply with the Board’s procedural requirements when
`presenting arguments. See, e.g., PTAB Consolidated Trial Practice Guide
`73–75 (Nov. 2019) (“TPG”), available at https://www.uspto.gov/
`TrialPracticeGuideConsolidated.
`
`10
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`should construe this term in this proceeding because “the Petition (through
`its mappings) has implicitly raised the possibility that a ‘mobile device’ need
`not be a physical device, and need not even be mobile.” Id. at 8–9 (citing
`Pet. 21, 32).
`At this stage, we agree with Patent Owner’s understanding of the term
`“mobile device,”11 but we disagree that its construction leads to a deficiency
`in Petitioner’s contentions concerning Dill. As Patent Owner correctly notes
`(Prelim. Resp. 9), the Petition refers to “mobile device 125, 130” (Pet. 32;
`see also id. at 41, 58, 75), where Dill describes mobile wallets 125, 130
`(e.g., Ex. 1005 ¶ 53, Fig. 9). But, when discussing the first instance of the
`term “mobile device,” the Petition contends that Dill teaches depositing
`funds “using the sender’s mobile device configured to run the sender’s
`mobile wallet 125.” Pet. 21–22; see also id. at 6 (arguing that Dill’s “mobile
`device can execute a mobile wallet application” (quoting Ex. 1005 ¶ 10;
`citing Ex. 1005 ¶ 5)). As a result, the most reasonable understanding of the
`Petition is that the words “mobile device 125, 130” (e.g., id. at 32) refer to
`Dill’s description of a mobile device executing a mobile wallet application
`that maintains mobile wallet 125, 130. Consequently, we do not agree that
`the Petition is premised on an understanding of the term “mobile device”
`that is materially different from the one articulated by Patent Owner.
`For completeness and to help guide the parties’ efforts during trial,
`and based on the present record, we agree with Patent Owner’s positions that
`Dill’s mobile wallets 125, 130 are not themselves devices per claim 1, and
`
`
`11 Patent Owner’s construction generally accords with the term’s plain and
`ordinary meaning and is supported by the Specification. See, e.g., Ex. 1001,
`11:14–16, 12:7–12 (identifying a phone and a tablet as examples).
`
`11
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`that Dill’s mobile network operator 120 is not mobile per claim 1. See
`Prelim. Resp. 9–10.
`
` “mobile wallet application”
`2.
`Each independent claim recites a “mobile wallet application.” Patent
`Owner contends that the “mobile wallet application” is a “wallet application
`installed on a SIM card or elsewhere on a mobile device.” Prelim. Resp. 10–
`11.
`
`In this proceeding, we need not address Patent Owner’s proposed
`construction of this term. It does not matter whether a “mobile wallet
`application” as a general matter must be “installed on a SIM card or
`elsewhere on a mobile device” (Prelim. Resp. 10) because each claim of the
`’488 patent includes an additional limitation that specifically requires the
`“mobile wallet application” to be “installed on the hardware SIM card.”
`Ex. 1001, 23:43–44 (claim 1), 26:41–43 (claim 11), 29:17–19 (claim 22).
`
`3. “mobile wallet” and “debiting the third party mobile wallet
`by the specified amount of funds”
`The term “mobile wallet” appears in every claim, usually in the
`context of a larger term, such as “mobile wallet sessions,” “mobile wallet
`application,” or “third party mobile wallet.” The phrase “debiting the third
`party mobile wallet by the specified amount of funds” appears only in
`dependent claims 8–10 and 19–21.
`Petitioner does not propose a construction for the term “mobile
`wallet,” but does construe the phrase found in the dependent claims. Pet. 4–
`5. Specifically, Petitioner asserts that an ordinary artisan “would have
`understood ‘debit the mobile wallet by the specified amount of funds’ []
`include[s] ‘transferring the specified amount of funds from the stored value
`
`12
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`on a mobile device.’” Id. at 5 (emphasis omitted). According to Petitioner,
`“‘stored value’ in mobile wallets is well-known and refers to a value stored
`on a mobile device (such as in secure memory).” Id. (citing Ex. 1003 ¶ 45).
`Petitioner further contends that the ’488 patent refers to this type of mobile
`wallet account. Id. at 4–5 (citing Ex. 1001, 2:32–36, 9:9–19; Ex. 1003
`¶¶ 43–45).
`Patent Owner responds that Petitioner’s proposal is an indirect
`construction of the term “mobile wallet” that limits it to a stored value
`account. Prelim. Resp. 15–16 (emphasis omitted). In addition, Patent
`Owner argues that the Petition is deficient because Petitioner fails to show
`that Dill discloses this type of mobile wallet. Id. at 16; see id. at 16–18
`(arguing that Dill’s mobile wallets 125, 130 instead reside within the mobile
`network operator).
`On this record, we preliminarily determine that the term “mobile
`wallet” is a stored value account or prepaid access account that allows its
`owner to pay for goods and services. This construction is based on the
`Specification’s express definition of this term:
`The term “mobile wallet” or “mobile wallet account”
`refers to a stored value account or prepaid access account (PPA)
`that allows the owner (or “subscriber”) to pay for goods and
`services on the mFS platform from his or her mobile wallet
`account.
`Ex. 1001, 9:9–13; see id. at 6:30–35 (“mFS” refers to “mobile financial
`services”). Our construction is also consistent with the construction recently
`adopted by a district court. See Fintiv, Inc. v. PayPal Holdings, Inc., 6:22-
`cv-00288, Dkt #60 (W.D. Tex.) (claim construction order; included in the
`record as Exhibit 3002). At this stage, we discern no need to construe the
`larger phrase identified by Petitioner.
`
`13
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`We disagree with Patent Owner’s argument that the Petition is
`deficient (see Prelim. Resp. 16–18) for two reasons. First, Patent Owner’s
`argument is premised on a misunderstanding of the construction advanced
`by Petitioner. Patent Owner assumes that Petitioner seeks to limit the term
`“mobile wallet” to a stored value account on a mobile device (see id. at 15–
`16), but at most, Petitioner contends that a “mobile wallet” “include[s]” a
`stored value account on a mobile device (Pet. 5 (emphasis added)).
`Petitioner does not require the “mobile wallet” to be a stored value account.
`As a result, we do not agree that Petitioner needs to show that Dill discloses
`a stored value account.
`Second, on this record, we determine that Petitioner has sufficiently
`shown that Dill discloses the claimed “mobile wallet.” See also infra
`§ II.E.1.a, c, i. We observe that Patent Owner does not address the proper
`construction of the term “mobile wallet” or argue that Petitioner fails to
`make a sufficient showing for the “mobile wallet” actually required by the
`claims. See Prelim. Resp. 16–18. This is particularly notable because the
`district court provided its construction for the term “mobile wallet” several
`months before Patent Owner filed the Preliminary Response.12 We apply
`our construction of the term “mobile wallet” in our analysis below.
`
`4. “third party mobile wallet”
`Each independent claim recites a “third party mobile wallet.” Patent
`Owner contends that the “third-party mobile wallet” is a “mobile wallet
`
`
`12 Although the district court issued its order on January 9, 2023, Patent
`Owner did not submit that order to the Board with its Preliminary Response,
`as instructed by our Trial Practice Guide. See TPG 47 (“Parties should
`submit a prior claim construction determination by a federal court or the ITC
`in an AIA proceeding as soon as that determination becomes available.”).
`
`14
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`provided by a provider other than the provider of the cloud-based
`transaction platform.” Prelim. Resp. 12–13 (citing Ex. 1001, 7:3–7, 6:51–
`54, 17:51–63; Ex. 2001 ¶¶ 45–47).
`We generally agree with Patent Owner’s understanding of the term
`“third party mobile wallet.” The Specification provides an express
`definition for this term:
`With respect to the entire description of FIG. 6, and as
`explained above, the term “mobile wallet” encompasses not
`only mobile wallets owned or managed by the mobile wallet
`platform, but also third party mobile wallets owned by third
`party mobile wallet providers or managed by third party mobile
`wallet platforms. In contrast, the term “third party mobile
`wallet” refers only to third party mobile wallets owned by third
`party mobile wallet providers or managed by third party mobile
`wallet platforms. Accordingly, cloud based transaction
`platform 601 may manage and process transactions using
`mobile wallets 605, which may be mobile wallets owned by
`cloud-based transaction platform 601 or mobile wallets owned
`by a third party mobile wallet provider.
`Ex. 1001, 17:51–63 (emphasis added); see also id. at 7:3–7 (providing
`corollary definition for a “third party” mobile wallet application). Thus, for
`purposes of this Decision, we preliminarily determine that a “third party
`mobile wallet” must be owned or managed by an entity different than the
`one that owns or manages the “computing system” recited in the claims.
`Patent Owner’s proposed construction uses slightly different language
`than our construction: Patent Owner refers to “provid[ing]” the wallet
`(rather than owning or managing it) and to the “cloud-based transaction
`platform” (rather than the “computing system”). We have altered the
`construction for three reasons: (1) the Specification’s definition refers to
`entities that “own[]” or “manage[]” the wallets, (2) the independent claims
`focus on the components and operation of the “computing system,” and
`
`15
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`(3) the independent claims refer to the “cloud-based transaction platform”
`only twice (and only in the context of the “plurality of communication
`channels connected to the cloud-based transaction platform”). Nevertheless,
`we understand Patent Owner’s proposed construction to be substantially the
`same as our construction for purposes of evaluating Patent Owner’s
`arguments. In particular, even if we adopted the specific language used in
`Patent Owner’s proposed construction, we would still determine that
`Petitioner sufficiently shows that Dill teaches or suggests a third party
`mobile wallet for the reasons provided below (see infra § II.E.1.j).
`In sum, we preliminarily construe the term “third party mobile wallet”
`as a mobile wallet that is owned or managed by an entity different than the
`one that owns or manages the “computing system” recited in the claims. We
`apply this construction in our analysis of the claims; however, as we explain
`below, we determine that Petitioner sufficiently shows that Dill teaches or
`suggests a third party mobile wallet. See infra § II.E.1.j.
`
`D. Summary of Asserted Prior Art References
`
`1. Dill (Ex. 1005)
`Dill generally relates to “financial transfers” and, in particular, “to
`financial transfers utilizing a unique identifier to facilitate flexible payment
`options for the transaction.” Ex. 1005 ¶ 2. Figure 9 of Dill, reproduced
`below, illustrates an “exemplary system for making financial transfers
`according to one embodiment.” Id. ¶ 25.
`
`16
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`
`
`Figure 9, reproduced above, illustrates system 100 that includes, among
`other things, sender 105 initiating a money transfer transaction (e.g.,
`payment) to recipient 110 via mobile wallet application 121 of mobile
`network operator 120. Id. ¶¶ 49, 54; see id. ¶ 100 (stating that system 100 in
`Figure 9 “can comprise a system as described above with reference to
`[Figure 1] and can include some or all of the same components and may
`
`17
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`perform some or all of the same functions”). Money transfer facilitator
`14013 receives the money transaction information from mobile wallet
`application 121 via mobile network 115. Id. ¶ 100. Money transfer
`facilitator 140 is coupled to financial transfer network 155 such that it is
`capable of transferring money in accordance with the money transfer
`transaction between source account 165 in sender’s financial institution 160
`and destination account 175 in recipient’s financial institution 170. Id. ¶ 49.
`
`2. Vadhri (Ex. 1006)
`Vadhri generally relates to “value holding accounts” and, in
`particular, “to systems and methods for accessing a value holding account”
`that “may hold anything considered valuable.” Ex. 1006 ¶¶ 1, 2. Figure 5 of
`Vadhri, reproduced below, illustrates a network diagram of “a client-server
`system, within which example embodiments may be deployed.” Id. ¶ 8.
`
`
`13 Money transfer facilitator 140 includes two components that are both
`labeled using the same numerical identifier—transfer options module 145
`and mobile application 145. Ex. 1005 ¶¶ 50, 101, 102, Fig. 9.
`
`18
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`
`
`Figure 5, reproduced above, illustrates client-server system 500 that includes
`networked system 502 that manages payment services between various
`applications and accounts. Id. ¶¶ 47–50. Networked system 502 includes,
`among other things, “Application Program Interface (API) server 514” that
`provides a “programmatic interface” between programmatic client 508 (e.g.,
`a “seller application” such as “eBay”) executing on client machine 512 and
`“marketplace and payment applications 520 and 522” hosted by application
`server 518. Id. ¶¶ 48, 50, 52.
`
`19
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`
`3. Akashika (Ex. 1007)
`Akashika generally relates to “a service providing system, a service
`providing server and an information terminal device.” Ex. 1007 ¶ 3. More
`specifically, Akashika is directed to an access control system that promotes
`secure communications by protecting sensitive data such as “electronic
`money or important personal information.” Id. ¶¶ 7, 9. In one embodiment,
`Akashika discloses an “area management server” that includes “an access
`control list generation section generating an access control list.” Id. ¶ 17.
`Figure 3 of Akashika, reproduced below, illustrates “an area
`management server according to [one] embodiment.” Ex. 1007 ¶ 29.
`
`
`Figure 3, reproduced above, illustrates certificate authority server 100, area
`management server 200, and service providing server 300. Id. ¶¶ 51, 52, 57,
`58. Area management server 200 includes, among other things, “access
`
`20
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`control list generation section 208 [that] generates an access control list”
`identifying “the scope of . . . access right[s]” to client device 400 (not
`reproduced in Figure 3 above). Id. ¶ 60. The access control list identifies
`“[t]he access right[s]” (e.g., “read permission, write permission, restriction
`on frequency of access”) permitted for a secure area. Id. ¶ 62.
`
`E. Obviousness Ground Based on Dill, Vadhri, and Akashika
`Petitioner contends that the subject matter of claims 1–22 would have
`been obvious over Dill, Vadhri, and Akashika. Pet. 5–83. Patent Owner
`argues that Petitioner’s showing with respect to independent claims 1, 11,
`and 22 is insufficient, particularly in Petitioner’s reliance on Dill. Prelim.
`Resp. 15–35.
`We have considered the parties’ arguments and the evidence
`presented at this stage, and we address them in the context of representative
`claim 1. For the reasons explained below, we determine that Petitioner has
`met the standard for institution by demonstrating a reasonable likelihood that
`it will prevail in showing that the subject matter of claim 1 would have been
`obvious over the combination of Dill, Vadhri, and Akashika. As a result, we
`institute inter partes review.
`
`1. Independent Claim 1
`
`a) Element 1.0
`The preamble of claim 1 is: “A computing system for facilitating
`management of a mobile wallet, including . . . .” Ex. 1001, 23:25–26
`(element 1.0). Petitioner contends that, to the extent the preamble is
`limiting, Dill discloses it. Pet. 16–17. According to Petitioner, Figure 9 of
`Dill illustrates system 100 that includes money transfer facilitator 140,
`
`21
`
`
`
`IPR2023-00399
`Patent 9,208,488 B2
`which manages financial transactions that use mobile wallets 125, 130. Id.
`(citing Ex. 1005 ¶¶ 5, 59, 100, Fig. 9; Ex. 1003 ¶¶ 70–76).
`At this stage, Petitioner has made a sufficient showing that Dill
`teaches the claim’s preamble.14 Patent Owner’s Preliminary Response does
`not allege any deficiencies in this portion of the Petition.
`
`b) Elements 1.1 & 1.2
`Claim 1 recites “one or more processors” (Ex. 1001, 23:27 (element
`1.1)) and “system memory” (id. at 23:28 (element 1.2)). For these elements,
`Petitioner points to Dill’s central processing units 210 (as the claimed
`“processors”) and
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
