RFCyber Corp.

Patent Trials and Appeals Board

Dec 14, 2021

IPR2021-00978 (P.T.A.B. Dec. 14, 2021)

Trials@uspto.gov Paper 10 571-272-7822 Date: December 14, 2021 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD SAMSUNG ELECTRONICS AMERICA, INC. and SAMSUNG ELECTRONICS CO., LTD., Petitioner, v. RFCYBER CORP., Patent Owner. IPR2021-00978 Patent 8,448,855 B1 Before PATRICK R. SCANLON, KEVIN W. CHERRY, and KRISTI L. R. SAWERT, Administrative Patent Judges. SAWERT, Administrative Patent Judge. DECISION Denying Institution of Inter Partes Review 35 U.S.C. § 314 IPR2021-00978 Patent 8,488,855 B1 2 I. INTRODUCTION Samsung Electronics America, Inc. and Samsung Electronics Co., Ltd. (“Petitioner”) filed a petition to institute inter partes review of claims 1-17 of U.S. Patent No. 8,448,855 B1 (Ex. 1001, “the ’855 patent”). Paper 2 (“Pet.”). RFCyber Corp. (“Patent Owner”) filed a Preliminary Response. Paper 6 (“Prelim. Resp.”). On our authorization, Petitioner filed a Reply to Patent Owner’s Preliminary Response. Paper 8 (“Reply”). Patent Owner filed a Sur-Reply. Paper 9 (“Sur-Reply”). We have authority under 35 U.S.C. § 314 to determine whether to institute an inter partes review. The standard for instituting an inter partes review is set forth in 35 U.S.C. § 314(a), which provides that an inter partes review may not be instituted unless “there is a reasonable likelihood that the petitioner would prevail with respect to at least 1 of the claims challenged in the petition.” After considering the Petition, the Preliminary Response, the Reply, the Sur-Reply, and the evidence of record, we determine the information presented does not show a reasonable likelihood that Petitioner would prevail in establishing the unpatentability of at least one of the challenged claims of the ’855 patent. Accordingly, we do not institute an inter partes review of all challenged claims of the ’855 patent on the grounds asserted in the Petition. II. BACKGROUND A. Related Matters The parties identify the following district-court proceedings as related matters involving the ’855 patent: RFCyber Corp. v. Google LLC, No. 2:20- cv-00274 (EDTX); RFCyber Corp. v. LG Electronics, Inc., No. 2:20-cv- 00336 (EDTX); and RFCyber Corp. v. Samsung Electronics Co., 2:20-cv- IPR2021-00978 Patent 8,488,855 B1 3 00335 (EDTX) (consolidated with No. 2:20-cv-00274). Pet. 2-3; Paper 4, 1-2 (Patent Owner’s Mandatory Notices). The parties also identify the following Board proceedings involving the same parties and related patents: IPR2021-00979 (U.S. Patent No. 8,118,218 B2 (“the ’218 patent”)); IPR2021-00980 (U.S. Patent No. 9,189,787 B1 (“the ’787 patent”)); and IPR2021-00981 (U.S. Patent No. 9,240,009 B2 (“the ’099 patent”)). Pet. 4; Paper 4, 1-2. The parties also identify the following Board proceedings involving the ’855 patent or related patents, filed by petitioner Google LLC: IPR2021-00954 (the ’855 patent); IPR2021-00955 (the ’787 patent); IPR2021-00956 (the ’009 patent); IPR2021-00957 (the ’218 patent); PGR2021-00028 (U.S. Patent No. 10,600,046 B2); and PGR2021-00029 (challenging U.S. Patent No. 10,600,046 B2). Pet. 3; Paper 4, 1. The proceedings in IPR2021- 00954, IPR2021-00955, IPR2021-00956, and IPR2021-00957 were terminated without a decision on institution on October 20, 2021. See, e.g., IPR2021-00954, Paper 12. The proceeding in PGR2021-00029 was terminated on November 16, 2021. PGR2021-00029, Paper 16. B. Real Parties in Interest Petitioner identifies its real party in interest as Samsung Electronics America, Inc. and Samsung Electronics Co., Ltd. Pet. 2. Patent Owner identifies RFCyber Corp. as its real party in interest. Paper 4, 1. C. Overview of the ’855 patent The ’855 patent relates to commerce over networks, and more specifically, to a method and apparatus for funding an electronic purse (“e- purse”) for use in portable devices configured for both electronic commerce IPR2021-00978 Patent 8,488,855 B1 4 (“e-commerce”) and mobile commerce (“m-commerce”). Ex. 1001, code (57), 1:15-19. The ’855 patent states that there is a “need for a mechanism in devices, especially portable devices, functioning as an electronic purse (e- purse) to be able to conduct transactions over an open network with a payment server without compromising security.” Id. at 1:42-46. Although closed systems-such as smart card technology-existed, they were “difficult to be expanded into other areas such as e-commerce and m-commerce” because “stored values and transaction information are stored in data storage of each tag that is protected by a set of keys,” which keys must be “delivered to the card for authentication before data can be accessed during a transaction.” Id. at 1:31-37. According to the ’855 patent, this required delivery of keys “makes systems using such technology difficult to be expanded to an open environment such as the Internet for e-commerce and cellular networks for m-commerce as the key delivery over a public domain network causes security concerns.” Id. at 1:37-41. The ’855 patent purports to overcome the limitations of the prior art by providing a system for funding an e-purse stored on a portable device. The e-purse allows for transactions “over an open network with a payment server without compromising security.” Id. at 1:58-62. IPR2021-00978 Patent 8,488,855 B1 5 Figure 2, reproduced below, provides a schematic view of one embodiment of the ’855 patent. FIG. 2 shows an exemplary architecture diagram 200 according to one embodiment of the ’855 patent. Ex. 1001, 3:3-4. As shown in Figure 2, a portable device is pre-loaded with smart card module 202 comprising an emulator 208, an e-purse applet 206, and a purse manager midlet 204. Id. at 4:66-5:52. The portable device may be a cellphone that is “near field communication (NFC) enabled” and includes an RFID interface “that allows the cellphone to act as a tag.” Id. at 4:67-5:2. The purse management midlet 204 “is a software component” that “acts as an agent to facilitate communications between an e-purse applet 206 and one or more payment network and servers 210 to conduct transactions.” Id. at 5:14-19. The e-purse applet 206 is built on a global platform and “acts IPR2021-00978 Patent 8,488,855 B1 6 as a gatekeeper to regulate or control the data exchange.” Id. at 4:51-53, 5:7-9. The emulator 208 is “a hardware device or a program that pretends to be another particular device or program that other components expect to interact with.” Id. at 4:43-46. In one embodiment of the ’855 patent, a user may fund the e-purse from a bank account by a process conducted via the m-commerce path shown in Figure 2. Id. at 7:18-30. Figure 4C, reproduced below, “shows an exemplary block diagram 450 of related blocks interacting with each other to achieve the process” of funding the e-purse. Id. at 7:21-30. FIG. 4C “shows an exemplary block diagram of related blocks interacting with each other to achieve the process” of financing an e-purse according to one embodiment of the ’855 patent. Ex. 1001, 3:15-20. The user 432 enters a personal identification number (PIN), which, if valid, activates the purse manager midlet 434. Id. at 7:28-33. The purse manager midlet “communicates with the e-purse applet 436 for a response that is then sent to the payment network and server 440.” Id. at 7:40-43. The payment network and server 440 “verifies that the response is from an authorized e-purse originally issued therefrom with a SAM module 444.” Id. at 7:64-67. “After the response is verified, the payment network and IPR2021-00978 Patent 8,488,855 B1 7 server 440 sends a request to the [user’s] financing bank 442.” Id. at 7:67- 8:3. Upon receiving authorization from the financing bank, “the server 440 will either reject the request or form a network response to be sent to the midlet 434.” Id. at 8:3-8. “The e-purse verifies the authenticity (e.g., in APDU format) and sends commands to the emulator 438 and updates the transaction logs.” Id. at 8:9-11. According to the ’855 patent, “[b]y now, the e-purse finishes the necessary steps and returns a response to the midlet 434 that forwards an (APDU) response in a network request to the payment server 440.” Id. at 8:11-14. D. The Challenged Claims Petitioner challenges claims 1-17 of the ’855 patent. Pet. 6. Of the challenged claims, claims 1 and 9 are independent. Ex. 1001, 8:45-9:9, 9:37-10:16. Claim 1, reproduced below, is illustrative of the subject matter recited in the challenged claims. 1. A method for funding an e-purse, the method comprising: receiving a PIN from a user of a portable device, wherein the portable device is a near field communication (NFC) enabled device that includes a card module; initiating a request from a midlet embedded in the portable device after the PIN is verified, wherein the midlet sends the request to an e-purse applet; causing the e-purse applet to compose a response to the request; sending the response by the e-purse applet over a wireless network to a server administrating the e-purse, the server configured to verify the response against an account in a financial institution across a network, a fund transfer request is initiated by the server to the financial institution when the response is successfully verified; IPR2021-00978 Patent 8,488,855 B1 8 receiving commands from the server in responding to the fund transfer request; and causing an emulator in the portable device to update a transaction log after an authenticity of the commands is verified by the e-purse applet wherein the e-purse in the portable device has been personalized by operations including: establishing an initial security channel between the card module and an e-purse security authentication module (SAM) external to the card module to install and personalize the e-purse applet in the card module, and creating a security channel on top of the initial security channel to protect subsequent operations of the card module with the e-purse SAM, wherein any subsequent transactions with the e-purse are conducted over the security channel. Id. at 8:45-9:9. E. Evidence Petitioner submits the following evidence: Evidence Exhibit No. Declaration of Gerald W. Smith 1003 Dua, US 2006/0165060 A1 (published July 27, 2006) (“Dua”) 1004 GlobalPlatform, Card Specification, Version 2.1.1 (March 2003) (“GlobalPlatform”) 1006 Philips Semiconductors SmartMX, P5CT072, Secure Dual Interface PKI Smart Card Controller, Rev. 1.3 (Oct. 4, 2004) (“Philips”) 1012 Davis, et al., WO98/49658 (published Nov. 5, 1998) (“Davis”) 1025 IPR2021-00978 Patent 8,488,855 B1 9 F. Asserted Grounds of Unpatentability Petitioner asserts the following grounds of unpatentability: Claim(s) Challenged 35 U.S.C. § Reference(s) 1, 9, 10 1031 Dua, Davis 1, 3, 4, 7-10, 12, 13, 16, 17 103 Dua, Davis, GlobalPlatform 2, 5, 6, 11, 14, 15 103 Dua, Davis, Philips 2, 5, 6, 11, 14, 15 103 Dua, Davis, GlobalPlatform, Philips Pet. 6. Patent Owner disputes Petitioner’s asserted grounds of unpatentability. See generally Prelim. Resp. III. PATENTABILITY ANALYSIS Petitioner contends that claims 1-17 of the ’855 patent are unpatentable under 35 U.S.C. § 103 as obvious over various combinations of Dua, Davis, GlobalPlatform, and Philips. Pet. 6. A patent claim is unpatentable under 35 U.S.C. § 103(a) if the differences between the claimed subject matter and the prior art are such that the subject matter, as a whole, would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). The 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 1 The Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284 (2011) (“AIA”), amended 35 U.S.C. § 103. The ’855 patent claims benefit of a September 24, 2006, filing date, which is before the effective date of the applicable AIA amendments. Ex. 1001, code (63). Petitioner does not contest the ’855 patent’s priority date. Pet. 6. Thus, we refer to the pre-AIA version of 35 U.S.C. § 103. Our decision would be the same were we to apply the AIA version of the statute. IPR2021-00978 Patent 8,488,855 B1 10 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.2 Graham v. John Deere Co., 383 U.S. 1, 17-18 (1966). “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 Patent Owner. See Dynamic Drinkware, LLC v. Nat’l Graphics, Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015) (discussing the burden of proof in inter partes review). We organize our patentability analysis into four sections. First, we address the level of ordinary skill in the art. Second, we address claim construction. Third, we provide an overview of the asserted references. And fourth, taking account of the information presented, we consider whether the Petition satisfies the threshold requirement for instituting an inter partes review under 35 U.S.C. § 314(a). A. Level of Ordinary Skill in the Art We consider the asserted grounds of unpatentability in view of the understanding of a person of ordinary skill in the art. In assessing the level of ordinary skill in the art, various factors may be considered, including the “type of problems encountered in the art; prior art solutions to those 2 Patent Owner does not present arguments or evidence of secondary considerations in its Preliminary Response. Therefore, secondary considerations do not constitute part of our analysis herein. IPR2021-00978 Patent 8,488,855 B1 11 problems; rapidity with which innovations are made; sophistication of the technology; and educational level of active workers in the field.” In re GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995) (quoting Custom Accessories, Inc. v. Jeffrey-Allan Indus., Inc., 807 F.2d 955, 962 (Fed. Cir. 1986)). “[O]ne or more factors may predominate.” Id. Relying on the declaration testimony of Mr. Smith, Petitioner contends that an ordinarily skilled artisan for the ’855 patent “would have been knowledgeable regarding mobile payment methods and systems pertinent to the ’855 patent.” Pet. 11-12 (citing Ex. 1003 ¶¶ 27-28). Petitioner also contends that an ordinarily skilled artisan “would have had at least a bachelor’s degrees [sic] in computer science, computer engineering, electrical engineering or an equivalent, and one year of professional experience relating to mobile payment technology,” and that “[l]ack of professional experience could be remedied by additional education, and vice versa.” Id. at 11-12 (citing Ex. 1003 ¶¶ 27-28). Patent Owner states that it “utilizes Petitioner’s proposed level of skill in the art,” but only for its Preliminary Response. Prelim. Resp. 8. Based on this record, we adopt Petitioner’s articulation of the level of ordinarily skill in the art, which is consistent with the ’855 patent and the asserted prior art, and we apply it in our obviousness evaluations below. See Okajima v. Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001) (the prior art, itself, can reflect appropriate level of ordinary skill in art). B. Claim Construction Next, we turn to claim construction. In interpreting the claims of the ’855 patent, we “us[e] the same claim construction standard that would be used to construe the claim[s] in a civil action under 35 U.S.C. [§] 282(b).” IPR2021-00978 Patent 8,488,855 B1 12 37 C.F.R. § 42.100(b). The claim construction standard includes construing claims in accordance with the ordinary and customary meaning of such claims as would have been understood by one of ordinary skill in the art and the prosecution history pertaining to the patent. See id.; Phillips v. AWH Corp., 415 F.3d 1303, 1312-14 (Fed. Cir. 2005) (en banc). Petitioner contends that all claim terms, except “emulator” and “midlet,” should have their plain and ordinary meaning. Pet. 12. As to the claim terms “emulator” and “midlet,” Petitioner contends that the ’855 patent expressly defines those terms “so those definitions are controlling.” Id. (quoting Ex. 1001, 4:42-46, 5:17). Patent Owner argues that “claim construction is not required to resolve any issues” at this point in the proceeding. Prelim. Resp. 8. Having considered the record, we determine that no express claim construction is necessary for any claim terms. See Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017) (holding that only claim terms in controversy need to be construed, and only to the extent necessary to resolve the controversy (citing Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999))). C. The Prior Art Before turning to Petitioner’s asserted grounds of unpatentability, we provide brief summaries of the asserted references. 1. Dua (Ex. 1004) Dua is a published U.S. patent application entitled “Method and Apparatus for Managing Credentials Through a Wireless Network.” Ex. 1004, code (54). Dua discloses a “system and methodology for conducting financial and other transactions using a wireless device.” Id. at IPR2021-00978 Patent 8,488,855 B1 13 code (57). Dua’s wireless device includes a “wallet application” that receives, stores, manages, and transmits multiple payment, identification, and other confidential information electronically. Id. ¶ 41. Card issuers like banks or merchants can develop custom “extensions” which are installed in the wallet application and stored in an embedded smart card. Id. ¶¶ 289, 295. One example of an extension is a stored-value card extension for paying subway fare. Id. ¶¶ 290, 293. The stored value card extension “need[s] to be programmed” to support “over-the-air reload,” i.e., wireless funding of the e-purse. Id. ¶ 293. 2. GlobalPlatform (Ex. 1006) GlobalPlatform Card Specification version 2.1.1 describes the “[s]pecifications that shall be implemented on GlobalPlatform smart cards.” Ex. 1006, 16. GlobalPlatform describes its own security architecture and commands for use in installing and personalizing applications on GlobalPlatform cards. Ex. 1006, 65-67, 88-90. GlobalPlatform is a “hardware-neutral,” “vendor-neutral,” and “Application independent” “chip card standard,” which “provides a common security and card management architecture.” Ex. 1006, 16; Ex. 1008, 290. “GlobalPlatform is intended to run on top of any secure, multi-application card runtime environment” including Java Card. Ex. 1006, 16 (§1), 29 (§3.1). GlobalPlatform specifies the card architecture, security architecture, Life Cycle models for smart cards and their Applications, the Card Manager, Security Domains for key management and establishing Secure Channels. Ex. 1003 ¶¶ 51-63. GlobalPlatform describes sequences of commands for installing, personalizing, and deleting applications on multi-application smart cards. Ex. 1006, 65-67, 88-90. IPR2021-00978 Patent 8,488,855 B1 14 3. Philips (Ex. 1012) Philips is a short form specification describing a Secure PKI Smart Card Controller for the SmartMX (Memory eXtension) multiple interface option platform. Ex. 1012, 1. The Smart Card Controller can be used as data memory and program memory. Id. According to Philips, “[t]he interface technology is well established in all products of the MIFARE® interface platform.” Id. at 2. “Compatibility with existing MIFARE® reader infrastructure and the optional free of charge emulation modes of MIFARE® 1K and MIFARE® 4K enable fast system integration and backward compatibility of standard MIFARE® and ProX family based cards.” Id. 4. Davis (Ex. 1025) Davis is a published PCT patent application entitled “Internet Payment and Loading System Using Smart Card.” Ex. 1025, code (54). Davis “relates to a payment system and a value loading system for a smart card using an open network such as the Internet.” Id. at 3:6-8. Figure 4 of Davis is reproduced below. FIG. 4 shows “an architecture and system for payment over the Internet using a store-value card.” Ex. 1025, 12:13-14. IPR2021-00978 Patent 8,488,855 B1 15 Figure 4 shows architecture 200 for making payments over the Internet using a smart card, such as a smart card having stored-value capability. Id. at 12:13-14, 13:15-17. Architecture 200 includes internet 202, client terminal 204, payment server 206, and merchant server 208. Id. at 13:19-20. Client terminal 204 interfaces with card reader 210, which accepts stored-value card 5. Id. at 13:28-31. Client terminal 204 includes client code module 224 and card reader module 226. Id. at 15:25. Client code module 224 controls communication between client terminal 204, card reader 210, payment server 206, and merchant server 208, and is also responsible for controlling displays to a user and interaction between card 5 and card reader 210. Id. at 15:28-37. Client terminal 204 communicates with stored-value card 5, bank server 860, and load server 862 for loading value onto stored-value card 5. Id. at 35:4-8, Fig. 17. Host security module 864 contains encryption keys for generating signatures that provide security for the transaction. Id. at 35:32-34, Fig. 17. A consumer accesses bank server 860 via client terminal 204 to download value onto stored-value card 5, and client terminal 204 communicates with load server 862 to receive authorization for the load. Id. at 36:7-11. Once the bank has downloaded value to card 5, a corresponding amount of funds is transferred from the bank to the card issuer. Id. at 36:13- 14. IPR2021-00978 Patent 8,488,855 B1 16 Figure 17, reproduced below, shows architecture 850 for loading value onto a smart card over the Internet. Id. at 36:22-24. FIG. 17 “illustrates a system for loading value onto a stored- value card according to one embodiment” of Davis. Ex. 1025, 13:6-7. Architecture 850 includes client terminal 204, load server 862, host security module 864, and bank server 860. Id. at 36:25-28. To load value onto stored-value card 5, a user accesses a bank server Internet site through a “suitable web browser” on client terminal 204. Id. at 37:1-2. The bank server 860 sends a request for card information (e.g., current card balance and maximum card balance) to the client terminal 204, which in turn “reads the current card balance, currency, and other card information via card reader 210 and returns the balance to bank server 860.” Id. at 37:4-6. After verifying sufficient funds are available, the bank server 860 sends information (including the port and IP address of the load server 862) to the requesting client browser. Id. at 37:7-18. According to Davis, this transfer of information “triggers the activation of the client code module (in this IPR2021-00978 Patent 8,488,855 B1 17 example a Java applet) in the client terminal.” Id. at 37:17-18. Further exchange of information between the client terminal and bank server includes the amount the user wishes to load onto the stored-value card, and a debit request from the bank server. Id. at 37:19-26. Next, “the client terminal interacts with stored-value card 5 to obtain card information” and combines responses from the card to build a “load request message” suitable for transmission over the Internet to the load server 862. Id. at 37:27-30. Davis states that “[t]he client terminal emulates a variety of host security module 864 commands to receive responses from these commands from the stored-value card” and “stored-value card and the security module are physically separated from one another” for security. Id. at 37:31-34. The load request message includes such information as a first card signature (“S1”), card number, expiry date, and load amount. Id. at 38:3-5. According to Davis, that “the client terminal emulates a security module and gathers all the responses for transmission into one load request message” provides for “secure[] and reliabl[e]” operation “in this environment.” Id. at 38:1-3. Further, that “all of this information is prepackaged into a single load request message” minimizes “the number of messages exchanged between the stored-value card and the security module over the Internet.” Id. at 38:9-11. Using the IP address obtained from the bank server, the client terminal 204 sends the load request message to the load server 862. Id. at 38:11-13. The load server “processes the load request in conjunction with [the] associated host security module 864.” Id. at 38:13-15. For example, the host security module 864 sends a “load command” including an “issuer security module signature (termed S2)” to the load server. Id. at 38:15-17. IPR2021-00978 Patent 8,488,855 B1 18 According to Davis, S2 “is a value that uniquely identifies and validates the security module to prove to store-value card 5 that the incoming load command is a valid command from a real security module.” Id. at 38:17-19. The load server 862 sends the received load command (including S2) to the client terminal 204, which in turn “passes the load command to stored-value card 5 which verifies the signature, loads itself by the load value, and also generates a load success message, a second stored-value card signature (termed S3), and a result code indicating success or failure of the load.” Id. at 38:23-28. Davis states that stored-value card 5 then sends the load success message (including S3) to the client terminal 204, which “packages the load success message along with the card signature and sends them back to the load server 862.” Id. at 38:30-35. The load server then communicates with the host security module to “verify the received stored-value card signature (S3).” Id. at 38:35-36. According to Davis, “the security module is able to validate that a received stored-value card signature is in fact a valid one by comparing the received stored-value card signature with a generated expected value.” Id. at 39:1-4. Further, “[a] successful comparison indicates that a load success message received from the stored-value card is in fact a valid success message and that the stored-value card has been loaded.” Id. at 39:4-6. In this case, the security module 864 sends a “confirmation” message back to the load server 862, id. at 39:6-7, and the load server, in turn, “creates a confirmation message including the transaction identifier and sends this message to the client terminal in encrypted form, id. at 40:13-15. Davis states that, “[b]y sending this confirmation message in encrypted form, the confirmation message may be IPR2021-00978 Patent 8,488,855 B1 19 forwarded to the bank server by way of the client terminal without fear of tampering.” Id. at 40:15-17. In addition to forwarding the confirmation message to the bank server, the client terminal 204 may also “post a message to the user informing that the load has been completed.” Id. at 40:21-22. “At this point,” Davis states, “a successful load of the user’s card has occurred (assuming all is well).” Id. at 40:33. D. Alleged Ground of Unpatentability Over Dua and Davis Petitioner contends that claims 1, 9, and 10 of the ’855 patent are unpatentable under 35 U.S.C. § 103(a) as obvious over Dua in view of Davis. Pet. 17-45. In particular, Petitioner contends that the combination of Dua and Davis teaches or suggests each and every limitation of the challenged claims, and that an ordinarily skilled artisan would have had a reason to combine the disclosures of the prior art. Id. Patent Owner opposes. Prelim. Resp. 9-16. In particular, Patent Owner argues that Petitioner has failed to show that the prior art teaches or suggests a server that initiates a fund transfer request to a financial institution, as required by all the challenged claims. Id. Independent claim 1 recites that “a fund transfer request is initiated by the server to the financial institution when the response is successfully verified.” Ex. 1001, 8:58-60. Similarly, independent claim 9 recites “initiating a fund transfer request by a server with a financial institution administering the e-purse when the response is successfully verified.” Id. at 9:42-44. We focus our analysis below on this limitation because it is dispositive for this Decision. IPR2021-00978 Patent 8,488,855 B1 20 1. Petitioner’s arguments Petitioner contends that “Dua and Davis render this limitation obvious.” Pet. 34. To begin, Petitioner contends that, although “Dua mentions ‘an over-the air reload tool,’” for reloading its stored value card extension (“SVCE”), “the details of how to load value into the SVCE are not provided by Dua.” Id. at 17. Petitioner contends that it would have been obvious for an ordinarily skilled artisan to look to “existing over-the-air reload techniques to implement Dua’s reload,” such as Davis’s. Id. (citing Ex. 1003 ¶¶ 83-88, 122-124, 128; Ex. 1008, 686). Petitioner contends that “Davis details how to load a stored-value card, including detailing the interactions between the ‘card,’ the ‘client terminal,’ and a ‘load server.’” Id. at 18 (citing Ex. 1025, 35:4-41:30). Petitioner presents the following annotated illustration in which Petitioner superimposes parts of Davis’s architecture for loading value onto a smart card onto Dua’s overall system architecture. Id. at 19. IPR2021-00978 Patent 8,488,855 B1 21 Specifically, Petitioner contends that an ordinarily skilled artisan “knew that implementing Davis’s value loading technique in Dua would merely require programming the wallet application to initiate a request for data from Dua’s stored-value card to obtain ‘card information in order to build a LRM [load request message] for later transmission to [a] load server.’” Id. at 20 (quoting Ex. 1025, 37:27-29 (second brackets in original); Ex. 1003 ¶¶ 133-134; Ex. 1008, 686). Petitioner also contends that “it was obvious to send Davis’s LRM from the wallet application to [Dua’s] WCM [wireless credential manager] using a secure SIP channel to signal the issuer and a financial institution (e.g., a bank) that the user wishes to load currency on the stored-value card and to provide a mechanism for the network entities to authenticate the card and validate the transaction.” Id. at 21 (citing Ex. 1003 ¶¶ 135-136; Ex. 1008, 683). Petitioner contends that “it was apparent to allow the WCM to act as a load server as described in Davis because it was an available resource for processing data and is engaged in secure communication with the wallet application.” Id. (citing Ex. 1025, FIG. 17; Ex. 1003 ¶ 137; Ex. 1004 ¶ 46). Petitioner further contends that an ordinarily skilled artisan would have “sen[t] the ‘first card signature’ from Dua’s WCM to Dua’s issuer card management system (hereinafter ‘ICMS’) to allow for authentication of the smart card,” id. (citing Ex. 1003 ¶ 138), because Davis teaches that “‘the load server can build a network message and switch the request to a remote authentication server’ thus allowing the verification of the stored-value card signature,” id. (quoting Ex. 1025, 41:8-14, 23-24). According to Petitioner, this step would be “similar to Dua’s PIN verification for accounts marked as IPR2021-00978 Patent 8,488,855 B1 22 being secured by a PIN in the issuer’s systems, in which the PIN is sent from the WCM to the ICMS.” Id. (citing Ex. 1004 ¶¶ 406-410). Petitioner contends that the WCM “would have been configured to verify the response” from the ICMS “against an account in a financial institution (the user’s account with the stored-value card credential issuer).” Id. at 22 (citing Ex. 1004 ¶¶ 406-410). And, once verified, “it was obvious to send the ‘load amount’ and ‘current card balance’ information from the load request received by Dua’s WCM to the ICMS to allow the system to verify sufficient funds availability and to ensure that the new card balance is properly updated as part of the process of issuing a ‘load command’ from the load server/WCM.” Id. (citing Ex. 1003 ¶ 141). Finally, Petitioner contends that an ordinarily skilled artisan “would cause Dua’s SVCE to update its value during a load process by receiving commands-e.g., in the form of Davis’s load command-passed from Dua’s wallet application to the SVCE, thus permitting the card to verify that the commands issued from an authorized network entity, load itself with the value, and generate a load success message.” Id. at 23 (citing Ex. 1025, 38:23-29; Ex. 1003 ¶ 143; Ex. 1008, 694-697). Turning to the disputed claim limitation, Petitioner contends that, “[a]fter Dua’s SVCE is verified as being associated with a valid account and verified using S1, it was obvious that ‘a fund transfer request is initiated by the server to the financial institution when the response is successfully verified’ based on Dua in view of Davis.” Id. at 34 (quoting claim 1). In particular, Petitioner contends that “[o]nce Dua’s WCM receives a ‘load request’ including the ‘load amount’ and ‘current card balance,’ the WCM needs to send that information to a server/service that manages accounts IPR2021-00978 Patent 8,488,855 B1 23 because the WCM itself does not engage in financial transactions directly.” Id. at 34 (citing Ex. 1003 ¶ 190; Ex. 1008, 683, 687-688). Petitioner contends that an ordinarily skilled artisan “would have understood that Dua’s ICMS has access to user accounts.” Id. (citing Ex. 1004 ¶¶ 406, 410, 422, FIG. 8; Ex. 1003 ¶ 191). “Therefore,” Petitioner contends, “after the WCM receives an indication that the ‘load request’ is verified, it was obvious to send additional information identifying the credential and for the request to the ICMS, thus allowing the WCM to initiate the fund transfer request to the financial institution/bank.” Id. (citing Ex. 1003 ¶¶ 182-188). 2. Patent Owner’s arguments Patent Owner criticizes Petitioner’s reliance on Dua’s WCM as the claimed “server” initiating a fund transfer request to the financial institution. See Prelim. Resp. 9-12. In particular, Patent Owner argues that Petitioner “identifies no portion of Dua disclosing the WCM initiating a fund transfer request,” and that, instead, “Dua uses its WCM, at most, to approve an already-initiated transaction request.” Id. at 12. Patent Owner also argues that Petitioner “identifies no portion of Dua’s ICMS that can make fund transfer requests, as opposed to approving payment requests generated by a [point of sale].” Id. As to Davis, Patent Owner argues that this reference “similarly does not disclose a ‘server administering the e-purse’ such that ‘a fund transfer request is initiated by the server to the financial institution’ as required.” Id. Patent Owner argues that, in Davis, “[t]he only requests to transfer funds are made by the client terminal directly to the bank server.” Id. at 13 (citing Ex. 1025, 36:25-30). Patent Owner argues that Petitioner’s proposed modification of Dua’s WCM to act as Davis’s load server and initiate a fund transfer request, “goes IPR2021-00978 Patent 8,488,855 B1 24 against the teachings of both Dua and Davis.” Id. at 14-15. Dua, Patent Owner argues, “expects payment requests to come from a point-of-sale system,” and Davis “uses its client terminal to send reload requests to a bank server.” Id. Patent Owner argues that “other than its expert’s conclusory opinions,” Petitioner provides no evidence that an ordinarily skilled artisan “would have been motivated to ignore both Dua’s and Davis’s preferred payment methods to change the WCM to initiate the fund transfer request.” Id. at 16 (citing Pet. 34) (footnote omitted). 3. Analysis After considering the parties’ respective argument and evidence, we determine that Petitioner has not sufficiently shown for institution that the combination of Dua and Davis teaches or suggests “a fund transfer request is initiated by the server to the financial institution when the response is successfully verified,” as recited in independent claim 1, or “initiating a fund transfer request by a server with a financial institution administering the e- purse when the response is successfully verified,” as recited in independent claim 9. As explained above, Petitioner maps Dua’s wireless device comprising a wallet application (with stored value card extension) to Davis’s portable device comprising a client terminal (with a stored-value card). See Pet. 19-20 (“First, [an ordinarily skilled artisan] would have known both Dua and Davis describe analogous portable device configurations in which a client terminal, like Dua’s wallet application, communicates with a stored- value card that can be implemented in software.”). Petitioner also maps Dua’s wireless credential manager (WCM) and issuer card management system (ICMS) to Davis’s load server and remote authentication server, IPR2021-00978 Patent 8,488,855 B1 25 respectively. Id. at 20-21 (stating that “it was apparent to allow the WCM to act as a load server as described in Davis” and that an ordinarily skilled artisan “would pass Davis’s first card signature (S1) from the WCM to the ICMS to validate the card and prevent fraud”). Although Petitioner contends that “it was obvious” for the WCM to initiate the fund transfer request to a financial institution, Pet. 34, Petitioner presents insufficient evidence as to why this would have been obvious to an ordinarily skilled artisan at the time of the ’855 patent based on the combined teachings of Dua and Davis. Petitioner states only in a conclusory manner that, “after the WCM receives an indication that the ‘load request’ is verified, it was obvious to send additional information identifying the credential and for the request to the ICMS, thus allowing the WCM to initiate the fund transfer request to the financial institution/bank.” Id. (citing Ex. 1003 ¶¶ 182-188). In Davis, however, the client terminal, rather than the load server, initiates the fund transfer request to the financial institution/bank. See Ex. 1025, 37:1-26; Fig. 17.3 Davis teaches that the client terminal packages information from both the bank server and the stored-value card to build a load request message to be sent to the load server. Id. at 37:16-18, 27-30. Davis teaches that, “[a]s all of this information is prepackaged into a single load message request, the number of messages exchanged between the stored-value card and the security module over the Internet is minimized.” Id. at 38:8-10. Davis further teaches that the “client terminal emulates a security module and gathers all the responses for transmission into one load 3 In Dua, the point-of-sale terminal initiates the fund transfer request. Ex. 1008 ¶ 405. IPR2021-00978 Patent 8,488,855 B1 26 request message” to provide for “secure[] and reliabl[e]” operation “in this environment.” Id. at 38:1-3. Petitioner has not explained with sufficient clarity and detail how or why an ordinarily skilled artisan would have bypassed Davis’s client terminal to use the load server/WCM to initiate a fund transfer to the financial institution. For example, to support its statement that it would have been obvious to allow “the WCM to initiate the fund transfer request to the financial institution/bank,” Petitioner cites only to paragraphs 182-188 of Mr. Smith’s declaration. See Pet. 34 ((citing Ex. 1003 ¶¶ 182-188). But none of these paragraphs address the claim limitation of “a fund transfer request is initiated by the server to the financial institution when the response is successfully verified.” Compare Ex. 1003 ¶¶ 182-188, with id. at ¶¶ 189-191). In any event, Mr. Smith merely repeats Petitioner’s statement that “after the WCM receives an indication that the ‘load request’ is verified, it would have been known to send the remainder of the information to the ICMS, thus allowing the WCM to initiate the fund transfer request to the financial institution.” Ex. 1003 ¶ 191. In addition, neither Petitioner nor Mr. Smith acknowledges Davis’s teachings with respect to the different functions of the load server and the client terminal. See Pet. 34; Ex. 1003 ¶ 189-191. For example, Davis teaches that the client terminal packages information from both the stored- value card and the bank server into a single load message request for security and efficiency, and that the stored-value card and the security module are also physically separated from one another for security. Ex. 1025, 37:31-38:11. Petitioner does not explain with sufficient clarity and detail why an ordinarily skilled artisan would have nevertheless IPR2021-00978 Patent 8,488,855 B1 27 programed the load server/WCM to perform these functions of Davis’s client terminal. For these reasons, we determine that Petitioner has not established sufficiently for institution that the combination of Dua and Davis teaches or suggests the disputed claim limitation in independent claims 1 and 9. Claim 10 depends from claim 9. Petitioner’s arguments and evidence with respect to claim 10 do not cure the deficiencies noted above with respect to claim 9. E. Alleged Ground of Unpatentability Over Dua, Davis, and GlobalPlatform Petitioner contends that claims 1, 3, 4, 7-10, 12, 13, 16, and 17 of the ’855 patent are unpatentable under 35 U.S.C. § 103(a) as obvious over Dua in view of Davis and GlobalPlatform. Pet. 45-66. We determine that Petitioner has not established sufficiently for institution that the combination of Dua and Davis teaches or suggests the disputed claim limitation in independent claims 1 and 9. See Pet. 47 (stating that Dua and Davis discloses the claimed limitation “for the reasons provided above”). Of the remaining challenged claims, claims 3, 4, 7, and 8 depend (either directly or indirectly) from claim 1, and claims 10, 12, 13, 16, and 17 depend (either directly or indirectly) from claim 9. Petitioner’s arguments and evidence with respect to these challenged claims do not cure the deficiencies noted above with respect to claims 1 and 9. Accordingly, Petitioner has not demonstrated a reasonable likelihood of prevailing in its challenge to claims 1, 3, 4, 7-10, 12, 13, 16, and 17 of the ’855 patent for obviousness over Dua in view of Davis and GlobalPlatform. F. Alleged Ground of Unpatentability Over Dua, Davis, and Philips Petitioner contends that claims 2, 5, 6, 11, 14, and 15 of the ’855 patent are unpatentable under 35 U.S.C. § 103(a) as obvious over Dua in IPR2021-00978 Patent 8,488,855 B1 28 view of Davis and Philips. Pet. 66-71. Claims 2, 5, and 6 depend (either directly or indirectly) from claim 1, and claims 11, 14, and 15 depend (either directly or indirectly) from claim 9. Petitioner’s arguments and evidence with respect to these challenged claims do not cure the deficiencies noted above with respect to claims 1 and 9. Accordingly, Petitioner has not demonstrated a reasonable likelihood of prevailing in its challenge to claims 2, 5, 6, 11, 14, and 15 of the ’855 patent for obviousness over Dua in view of Davis and Philips. G. Alleged Ground of Unpatentability Over Dua, Davis, GlobalPlatform, and Philips Petitioner contends that claims 2, 5, 6, 11, 14, and 15 of the ’855 patent are unpatentable under 35 U.S.C. § 103(a) as obvious over Dua in view of Davis, GlobalPlatform, and Philips. Pet. 66-71. Claims 2, 5, and 6 depend (either directly or indirectly) from claim 1, and claims 11, 14, and 15 depend (either directly or indirectly) from claim 9. Petitioner’s arguments and evidence with respect to these challenged claims do not cure the deficiencies noted above with respect to claims 1 and 9. Accordingly, Petitioner has not demonstrated a reasonable likelihood of prevailing in its challenge to claims 2, 5, 6, 11, 14, and 15 of the ’855 patent for obviousness over Dua in view of Davis, GlobalPlatform, and Philips. IV. CONCLUSION For the foregoing reasons, we determine that that the information presented in the Petition does not establish a reasonable likelihood of success in proving that at least one claim of the ’855 patent is unpatentable. Thus, we do not institute an inter partes review of the challenged claims. IPR2021-00978 Patent 8,488,855 B1 29 V. DISCRETIONARY ISSUES Because we deny institution on the merits, we do not reach the discretionary issues raised by Patent Owner. See Prelim. Resp. 17-25. VI. ORDER Accordingly, it is ORDERED that the Petition is denied. IPR2021-00978 Patent 8,488,855 B1 30 FOR PETITIONER: Heath J. Briggs Andrew R. Sommer GREENBERG TRAURIG, LLP briggsh@gtlaw.com sommera@gtlaw.com FOR PATENT OWNER: Vincent J. Rubino Peter Lambrianakos Enrique W. Iturralde Richard Cowell FABRICANT LLP vrubino@fabricantllp.com plambrianakos@fabricantllp.com eiturralde@fabricantllp.com rcowell@fabricantllp.com