Blaze Mobile, Inc.

Patent Trials and Appeals Board

Mar 16, 2022

IPR2021-01529 (P.T.A.B. Mar. 16, 2022)

Trials@uspto.gov Paper 14 571-272-7822 Date: March 16, 2022 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD SAMSUNG ELECTRONICS, CO. LTD., Petitioner, v. BLAZE MOBILE, INC.,1 Patent Owner. IPR2021-01529 Patent 10,699,259 B2 Before HYUN J. JUNG, MIRIAM L. QUINN, and NATHAN A. ENGELS, Administrative Patent Judges. JUNG, Administrative Patent Judge. DECISION Denying Institution of Inter Partes Review 35 U.S.C. § 314 1 We omit Michelle Fisher because, although Michelle Fisher is listed as Patent Owner in Patent Owner’s filings (Papers 5, 7, 9, 10, 12), an assignment at Reel/Frame 053450/0778 recorded on August 10, 2020 indicates that Michelle Fisher assigned “the entire right, title and interest” in the ’259 patent to Blaze Mobile, Inc. IPR2021-01529 Patent 10,699,259 B2 2 I. INTRODUCTION A. Background and Summary Samsung Electronics, Co. Ltd. (“Petitioner”) filed a Petition (Paper 1, “Pet.”) requesting institution of an inter partes review of claims 1-24 and 27-33 of U.S. Patent No. 10,699,259 B2 (Ex. 1001, “the ’259 patent”). Blaze Mobile, Inc. (“Patent Owner”) filed a Preliminary Response (Paper 9, “Prelim. Resp.”). Under 35 U.S.C. § 314, 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.” Upon consideration of the Petition and Preliminary Response and for the reasons explained below, we determine that Petitioner has not shown a reasonable likelihood of prevailing with respect to at least one of the challenged claims. Thus, we do not institute an inter partes review of claims 1-24 and 27-33 of the ’259 patent. B. Real Parties in Interest Petitioner identifies Samsung Electronics Co., Ltd. and Samsung Electronics America, Inc. as real parties in interest. Pet. 2. Patent Owner identifies Blaze Mobile, Inc. and Michelle Fisher as real parties in interest. Paper 12, 1. C. Related Matters The parties identify Samsung Elecs. Co. v. Blaze Mobile Inc., 21-cv- 02989-EJD (N.D. Cal.) as a related matter. Pet. 2; Paper 12, 1. Patent Owner also identifies IPR2021-01530, IPR2021-01570, and a pending patent application as related matters. Id. at 1-2. IPR2021-01529 Patent 10,699,259 B2 3 D. The ’259 Patent (Ex. 1001) The ’259 patent issued on June 30, 2020 from an application filed on March 21, 2016, which is the latest in a series of continuation applications, the earliest of which was filed on November 30, 2007. Ex. 1001, codes (22), (45), (63), 1:7-9. The ’259 patent “relates to data communications and wireless devices.” Ex. 1001, 1:25-26. Figure 1 of the ’259 patent is reproduced below. Figure 1 is “a block diagram of a communication system including a wireless mobile communication device and a management server.” Ex. 1001, 2:17-19. Communication system 100 includes mobile communication device 102, point-of-sale device 104, and management server 106. Id. at 2:39-41. Communication device 102 can include a mobile application “that permits a user of the mobile communication device 102 to conduct payment transactions.” Id. at 2:41-45. Authorizations for payment transactions made through point of sale device 104 are sent to an issuer authorization, such as management server 106 through mobile communication device 102. Id. at 2:61-65. The issuer authorization, such as a bank, approves or disapproves the transaction. Id. at 2:65-3:2. IPR2021-01529 Patent 10,699,259 B2 4 According to the ’259 patent, a “potential benefit of having payment authorizations flow through the mobile communication device 102 is that sensitive user information (e.g. account numbers, pin numbers, and/or identity information) need only be sent from the mobile communication device 102 directly to an issuer authorization” and “[s]uch operation reduces the potential for identity theft and/or fraudulent purchases made through a point of sale device.” Ex. 1001, 3:2-10. Mobile application 200 is provided to mobile communication device 102 through, for example, management server 106. Ex. 1001, 3:14- 17, Fig. 2. Mobile application 200 can be a Mobile Wallet application, and “is configured to send requests to the management server for artifacts based on user input, e.g., received though a keypad (not shown) of the mobile communication device 102.” Id. at 3:18-19, 3:25-29. The requested artifacts from management server 106 can include “advertisements, receipts, tickets, coupons, media, content, and so on.” Id. at 3:34-38. Figure 4 of the ’259 patent is reproduced below. IPR2021-01529 Patent 10,699,259 B2 5 Figure 4 is “a block diagram of a communication system including a wireless mobile communication device and an online store.” Ex. 1001, 2:26-28. Communication system 400 includes mobile communication device 402, personal computer (“PC”) 404, online store 406, and core (or datastore) 408. Id. at 5:63-66. At interaction (1), a user or customer using, for example, mobile communication device 402, browses an online store website’s online store application 410 and finds an item to purchase. Ex. 1001, 5:66-6:3. The IPR2021-01529 Patent 10,699,259 B2 6 purchase can be made through a midlet application or POS midlet 412 on mobile communication device 402. Id. at 6:3-5. At interaction (2), “when the user chooses to purchase with the mobile communication device 402, the online store application 410 sends the transaction information for authorization to the POS vendor plugin (e.g., MCD POS plugin 414)” that “is installed in the merchant’s online store.” Ex. 1001, 6:16-24. At interaction (3), “the POS vendor plugin formats, encrypts, and cryptographically signs the purchase authorization request which is sent via a secure SSL link (e.g., HTTPS, Bluetooth, IR, USB, or other suitable protocol) established by the browser/web application 416 back to the mobile communication device 402.” Ex. 1001, 6:24-29. “POS midlet 412 is a component of the mobile wallet application that executes . . . payment authorization protocol between itself and the SE payment applications on the mobile communication device 402 (interaction (4)),” and “[t]he results of the request are sent back to the POS vendor plugin.” Id. at 6:32-38. At interaction (5), “POS midlet 412 then forwards the properly formatted authorization request to a payment entity (e.g., issuer authorization 418) for authorization, and “[t]he results of the request are then sent back to the POS component of the mobile wallet.” Ex. 1001, 6:39-43. At interaction (6), “POS midlet 412 then forwards the results back to the MCD POS plugin 414 to complete the purchase.” Ex. 1001, 6:43-45. “The MCD POS plugin 414 then forwards the purchase transaction information to the management server 408 for later customer viewing (interaction (7)).” Id. at 6:45-48. IPR2021-01529 Patent 10,699,259 B2 7 At interaction (8), “users (or customers) will then be able to query the management server 408 and immediately obtain purchase information, either by phone or PC.” Ex. 1001, 6:48-51. E. Illustrative Claim The ’259 patent includes claims 1-35, of which Petitioner challenges claims 1-24 and 27-33. Of the challenged claims, claims 1, 7, and 13 are independent, and reproduced below is claim 1. 1. A method for processing a transaction, comprising: maintaining a non-browser based application in a mobile device memory included in a mobile device, wherein the non- browser based application is a mobile operating system platform based mobile application with a graphical user interface which includes a graphical icon that is preinstalled or downloaded and installed on the mobile device, wherein the non-browser based application only generates a non-browser based application generated screen, the non-browser based application generated screen corresponding to a specific screen or area of the non- browser based application, the mobile device comprising the mobile device memory, a mobile device display, a mobile device processor, and a mobile device wireless radio interface, a mobile device wireless fidelity (Wi-Fi) interface that supports voice and data interactions through a first wireless communication channel device using at least one of GSM and CDMA; receiving, at the non-browser based application generated screen, a list of products from a remote management server for display using the non-browser based application; receiving, at the non-browser based application generated screen, an identification of one or more products selected from the list of products from non-browser based application generated screen, wherein the non-browser based application generated screen receives the identification of the one or more products selected from the list of products through user input via the mobile device display; sending, from the non-browser based application generated screen, the identification of one or more products to the remote management server; IPR2021-01529 Patent 10,699,259 B2 8 receiving a transaction purchase request from the non- browser based application generated screen, wherein the non- browser based application generated screen receives the transaction purchase request from the user via the mobile device display; sending, from the non-browser based application generated screen, the transaction purchase request to the remote management server; receiving user input login information including an identification code associated with the user from the non-browser based application generated screen, wherein the non-browser based application receives the user input login information through user input via the mobile device display; sending, from the non-browser based application generated screen, the user input login information to the remote management server; and receiving information authenticating the user associated with the user input login information from the remote management server and further wherein the remote management server receives a transaction verification from a transaction server which processes the transaction using a payment method that corresponds to the identification code associated with the user, wherein the payment method is stored at the remote management server; wherein the transaction verification indicates that the transaction has processed, and receiving, at the mobile device, the one or more products from the remote management server. Ex. 1001, 7:49-8:44. F. Asserted Prior Art and Proffered Testimonial Evidence Petitioner identifies the following references as prior art in the asserted grounds of unpatentability: Name Reference Exhibit Shore-II US 2002/0059100 A1, published May 16, 2002 1014 Shore-I US 2003/0149662 A1, published Aug. 7, 2003 1005 Angelica US 2007/0150601 A1, published June 28, 2007 1006 Mazur US 2007/0266130 A1, published Nov. 15, 2007 1007 Knight WO 2007/129081 A1, published Nov. 15, 2007 1008 IPR2021-01529 Patent 10,699,259 B2 9 Petitioner provides a Declaration of Dr. Sandeep Chatterjee. Ex. 1003. G. Asserted Grounds Petitioner asserts that claims 1-24 and 27-33 are unpatentable on the following grounds. Pet. 6. Claims Challenged 35 U.S.C. § Reference(s)/Basis 1-18, 24, 27, 33 103(a)2 Shore-I 1-18, 23, 24, 27, 32, 33 103(a) Shore-I, Angelica 19, 28 103(a) Shore-I, Angelica, Mazur 20, 21, 29, 30 103(a) Shore-I, Angelica, Knight 22, 31 103(a) Shore-I, Angelica, Shore-II II. ANALYSIS A. Legal Standards In inter partes reviews, the petitioner bears the burden of proving unpatentability of the challenged claims, and the 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). To prevail in an inter partes review, the petitioner must support its challenges by a preponderance of the evidence. 35 U.S.C. § 316(e) (2018); 37 C.F.R. § 42.1(d) (2019). Petitioner contends that the challenged claims of the ’259 patent are unpatentable under § 103(a). Pet. 6. A claim is unpatentable under § 103(a) if the differences between the claimed subject matter and the prior art are 2 The relevant sections of the Leahy-Smith America Invents Act (“AIA”), Pub. L. No. 112-29, 125 Stat. 284 (Sept. 16, 2011), took effect on March 16, 2013. “For purposes of this Petition only, Petitioner uses November 30, 2007 . . . as the priority date of the ’259 patent,” and states that “[a]ll citations to the applicable statutes . . . refer to the pre-AIA version.” Pet. 4 n.1. IPR2021-01529 Patent 10,699,259 B2 10 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 between the claimed subject matter and the prior art; (3) the level of skill in the art; and (4) where in evidence, so-called secondary considerations. Graham v. John Deere Co., 383 U.S. 1, 17-18 (1966). When evaluating a combination of teachings, we must also “determine whether there was an apparent reason to combine the known elements in the fashion claimed by the patent at issue.” KSR, 550 U.S. at 418 (citing In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006)). Whether a combination of elements produces a predictable result weighs in the ultimate determination of obviousness. Id. at 416-417. B. Level of Ordinary Skill in the Art Petitioner asserts that one of ordinary skill in the art “would have had a B.S. in Computer Engineering or a related field, and two or more years of industry or research experience in data communications, wireless devices, and/or mobile payment systems.” Pet. 12 (citing Ex. 1003 ¶¶ 34-37). Petitioner also argues that “[a]dditional relevant education may compensate for less experience, and vice-versa.” Id. (citing Ex. 1003 ¶¶ 34-37). Patent Owner responds that, “[f]or purposes of this preliminary response,” one of ordinary skill in the art “at the time of the invention would have had a bachelor’s degree in computer engineering or a similar discipline, and approximately two years of experience designing mobile applications for wireless devices.” Prelim. Resp. 9. IPR2021-01529 Patent 10,699,259 B2 11 We note that the parties’ proposed level of ordinary skill regarding education and number of years of experience are substantially the same but differ on what the experience should be in. Pet. 12; Prelim. Resp. 9. Based on the preliminary record, we adopt Petitioner’s asserted level of ordinary skill only to determine whether there is a reasonable likelihood that Petitioner would prevail with respect to at least one of the claims challenged in the Petition. This level of skill in the art is consistent with the disclosure of the ’259 patent and the prior art of record. See In re GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995). C. Claim Construction In an inter partes review based on a petition filed on or after November 13, 2018, the claims are construed 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), including construing the claim in accordance with the ordinary and customary meaning of such claim as understood by one of ordinary skill in the art and the prosecution history pertaining to the patent. 37 C.F.R. § 42.100(b) (2021); see Phillips v. AWH Corp., 415 F.3d 1303, 1312-13 (Fed. Cir. 2005) (en banc). “Petitioner submits that the Board does not need to construe any claim term to evaluate the prior art in this Petition.” Pet. 14. Petitioner, however, argues that, if “non-browser based application” and “receive/receiving . . . the one or more products from the remote management server” were to be construed, then certain statements made during prosecution should be considered. Id. at 12-15. According to Petitioner, “[t]o the extent . . . statements during prosecution impose requirements on the terms discussed above, however, IPR2021-01529 Patent 10,699,259 B2 12 those requirements are met by the prior art and thus no particular interpretation of any claim term is required to find the claims obvious in view of the prior art.” Pet. 14-15 (citing Ex. 1003 ¶ 61). Petitioner also asserts that “[c]ertain claims of the ’259 Patent may be indefinite for reciting both an apparatus and a method of using that apparatus.” Id. at 15. Patent Owner responds that Petitioner has the burden to set forth how the challenged claims are to be construed but has not provided any claim interpretation. Prelim. Resp. 9-10 (citing Pet. 12-14), 13. Patent Owner, thus, argues that institution should be denied. Id. at 10 (citing 37 C.F.R. § 42.104(b)(4)), 13. Patent Owner also responds that the cited statements made during prosecution are neither disclaimers nor disavowals of claim scope. Id. at 10-13. Because determining whether Petitioner shows a reasonable likelihood of prevailing does not depend on a particular interpretation for any claim term, we determine that no claim term requires express interpretation. Realtime Data, LLC v. Iancu, 912 F.3d 1368, 1375 (Fed. Cir. 2019) (“The Board is required to construe ‘only those terms that . . . are in controversy, and only to the extent necessary to resolve the controversy.’”) (quoting Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999)). D. Asserted Obviousness Based on Shore-I or Shore-I Combined with Angelica 1. Shore-I (Ex. 1005) Shore-I relates “particularly to conducting point of sale transactions using a portable electronic device equipped with wireless communications capabilities.” Ex. 1005 ¶ 1. Shore-I’s “apparatus, systems and methods . . . wirelessly pay for purchases, electronically interface with financial IPR2021-01529 Patent 10,699,259 B2 13 accounting systems, and electronically record and wirelessly communicate authorization transactions using Personal Digital Assistant (PDA)” and “intelligent handheld cellular and other wireless telephones.” Id. ¶ 8. Reproduced below is Figure 1a of Shore-I. Figure 1a is a diagram showing exemplary relationships between major networked nodes. Ex. 1005 ¶ 11. PDA 700 can have wireless interface 705 and can communicate with Point of Purchase (“POP”) terminal or Point of Sale (“POS”) terminal 710, Automated Teller Machine 740, personal computer (“PC”) 760, and POP eTicket client 790. Id. ¶¶ 61-64, 71, 79, 82. PDA 700 can “hold electronic authorization certificates, or eTickets, to use for particular service or attend a particular entertainment IPR2021-01529 Patent 10,699,259 B2 14 event.” Id. ¶ 64. POP terminal 710 can communicate with Automated Clearing House (“ACH”) server 720. Id. ¶¶ 65, 71. PC 760 can also “communicate with the Immtec server host 750 via communications link 755,” and “Immtec” can “apply equally to any host server system embodying the present invention.” Ex. 1005 ¶ 67. “The Immtec server would hold initialization data for the PDA device,” and “initialization data would contain encrypted registration data specific to each PDA device which, in the exemplary embodiment, would be maintained at the Immtec host site.” Id. ¶ 69. “A server computer or set of server computers would be provided by a Server System with which to provide the interface for the payment system aspect of the invention (referred to herein as the ‘PDA Pay system’) and the authorization transaction interface system (referred to herein as ‘ticketdownload.com’ and/or as the ‘ticketdownload.com system’ and/or as the ‘eTicket System’).” Ex. 1005 ¶ 101. Shore-I states that “[t]he systems administrator of both of these systems is referred to herein as ‘Immtec.’” Id. “The PDA Pay and eTicket/mewallet™ System PDA software would be installed in the customer’s PDA.” Ex. 1005 ¶ 117. “The PDA Pay and eTicket System would be programmed to utilize any Internet browser/interface software already present on the client and server computers.” Id. ¶ 114. When the PDA is used with a POP terminal, it “would utilize the existing infrastructure presently in place for debit card/credit card transactions,” and “[t]he PDA would act in a manner similar to that of a credit card, debit card or check.” Id. ¶ 134. For communication between the wireless PDA and Internet online merchants, “[t]he wireless PDA would use the same protocols as an Internet-capable wireless phone,” and “the Internet online merchant would have a web site that would work IPR2021-01529 Patent 10,699,259 B2 15 with wireless Internet protocols.” Id. ¶ 163. “The User would choose a PDAPay & eTicket System icon via pen pad, keypad or voice 201.” Id. ¶ 139. Shore-I’s “System would provide a web site, referred to herein as ‘Ticketdownload.com’” that “would offer the ability to download electronic tickets to a personal computer or a wireless-modem-equipped PDA.” Ex. 1005 ¶ 184. “The System software would provide for storage of electronic tickets (‘eTickets’) in the storage devices configured with the user’s personal computer and PDA” and “would provide for transmission of eTickets at the request of the user via the PDA’s infrared interface to an infrared interface at a point of ticket use (e.g., air terminal, train terminal, boat terminal, theatre, cinema, museum, etc.).” Id. “The ticketdownload.com software engine would interface with all licensed ticket brokers, airlines, theaters, travel agencies, etc.,” and “eTickets would be purchased through the ticketdownload.com Internet site or directly from any licensed ticket agency or merchant.” Ex. 1005 ¶ 185. “In the exemplary embodiment . . . , Ticketdownload.com would not be a ticket broker web site but would instead be a portal through which merchants and ticket brokers are provided the opportunity to offer downloadable eTickets to customers using the PDA Pay & eTicket/mewallet™ System,” and “would work transparently to the user/ticket purchaser when utilized by a licensed merchant.” Id. “[T]he User/Customer (or simply, ‘Customer’) would search an online merchant's database for desired tickets 400,” and “[t]he Merchant would display available ticket(s) and prices according to the customer's request 401.” Ex. 1005 ¶ 186. “[T]he Merchant would be licensed to provide a link IPR2021-01529 Patent 10,699,259 B2 16 for the Merchant’s customers to the PDA Pay & eTicket/mewallet™ System to download eTickets.” Id. Ticketdownload.com can request the User or Customer to supply payment information through the Merchant’s system or directly. Ex. 1005 ¶ 191. Ticketdownload.com can subsequently request an approval code for the transaction from a credit card or debit card clearinghouse. Id. ¶ 195. If the eTicket is transmitted to the PDA, then software in the PDA would receive and store the eTicket in the PDA’s memory. Id. ¶ 200. Shore-I further describes an embodiment that uses a “Directed Purpose” device, such as a “PayStick” that is similarly configured to conduct mobile payment transactions. Id. ¶¶ 319, 327. 2. Angelica (Ex. 1006) Angelica is directed to improving mobile payment systems through a “non-browser model for the processing of electronic transactions” that includes a mobile device that uses a “software program other than a conventional internet browser” to conduct online transactions. Ex. 1006, Abstract, ¶¶ 9, 50. Angelica states that “a broader non-browser model for the processing of electronic transactions has the greater future potential as a way of doing business” because “a dedicated piece of resident software with its own internet communication capabilities can be configured to always be definitively identified according to its user by a server system function it contacts.” Ex. 1006 ¶ 9. Angelica also states that “with no limitation on its custom capabilities, billing information can be stored for the instantaneous at will use of the user of the client system as to any product or service the server system might make available.” Id. ¶ 10. IPR2021-01529 Patent 10,699,259 B2 17 “[B]y entering the non-browser realm the server application can send the application whatever custom headers and raw data it may choose, formatted any way it likes for its own purposes, just as long as the request and response meet the minimum requirements of one of the internet communication protocol, in this case HTTP,” and “[i]n the case of a privately dedicated electronic communication system we escape even this last limitation.” Ex. 1006 ¶ 30. “Another significant advantage is that by the method,” Angelica creates its “own lines of communication, a dedicated conduit not dependent of the vagaries of email communication.” Id. ¶ 38; see also id. ¶ 40 (stating that an “ultimate power of the method” arises from “a resident and dedicated communications outpost, prominently featured on the client system”). In Angelica’s method and system, “a client system, either fixed by a wired network connection or mobile, first establishes a path of electronic communication between itself and a server system, most optimally using a custom software program dedicated for this purpose.” Ex. 1006 ¶ 12. “In making this connection, the client system identifies itself in a unique way to the server system,” and “[a]s part of this established relationship the client system receives media content on a recurrent basis from the server system.” Id. “Incorporated into the media content supplied by the server are functions for the client system to take direct action with respect to that content,” such as “placing orders for items both tangible and intangible.” Ex. 1006 ¶ 13. “If billing information or contact information is required, it can be submitted on a one time basis, or for convenience stored at the client or server end for subsequent repeated use.” Id. Figure 4 of Angelica is reproduced below. IPR2021-01529 Patent 10,699,259 B2 18 Figure 4 shows a screen show of an embodiment applied to a music radio application. Ex. 1006 ¶ 17. During a radio type audio feed, Angelica provides a custom program interface that, when a new song begins playing at 402, a direct action function appears in the visible program interface to buy that track at 404. Id. ¶ 43. To fulfill any order transaction, billing information could be stored at the client system or at the server system. Id. ¶ 44. By storing billing information for recurrent use, Angelica can create “a built-in customer user base for any future transaction.” Id. ¶ 45. 3. Claim 1 Petitioner argues with citations to Shore-I and declarant testimony that Shore-I teaches all the limitations of claim 1. Pet. 18-25, 30-51. In particular, Petitioner argues that “Shore-I teaches a ‘mobile device,’ such as ‘palm computers, intelligent handheld cellular and other wireless telephones, and other personal handheld electronic devices.’” Id. at 19 (citing Ex. 1005 ¶¶ 8, 83, Fig. 2). For the recited “non-browser based application,” Petitioner argues that “Shore-I teaches a ‘PDA Pay and eTicket/mewallet’ software application (‘PDA Pay application’) ‘for storing many types of data[,] IPR2021-01529 Patent 10,699,259 B2 19 including for example, electronic tickets (‘eTickets’)[,] banking information[,] credit card information[,] and medical information.” Id. at 20 (alterations in original) (citing Ex. 1005 ¶¶ 0115, 116). a) “receiving, at the non-browser based application generated screen, a list of products from a remote management server for display using the non-browser based application” Turning to the recited step quoted above, Petitioner argues that “Shore-I teaches sending a list of products (e.g., electronic tickets or ‘eTickets’) from a remote management server (e.g., Immtec, shown in blue in annotated Figure 1a) to a non-browser based application (e.g., the PDA Pay and eTicket/mewallet application, installed on PDA 700, shown in green) for display using that application.” Pet. 31 (citing Ex. 1005, Fig. 1a); see also Ex. 1012 (Claim Listing), 1 (labeling this step as “1.2”). Reproduced below is Petitioner’s annotated figure from Shore-I. Petitioner’s annotated figure is Figure 1a of Shore-I with a green box around PDA 700 and a blue box around Immtec server 750. Pet. 31. IPR2021-01529 Patent 10,699,259 B2 20 Petitioner argues that “Shore-I teaches a ‘remote management server’ called ‘Immtec’ (or ‘Immtec Server Host’), which is a ‘host server system’ that encompasses a ‘server computer or set of server computers.’” Id. (citing Ex. 1005 ¶¶ 65, 101, Fig. 1a). Petitioner also contends that the Immtec server provides an interface for Shore-I’s payment system and authorization transaction interface system, communicates with a mobile device, generates and distributes eTickets, and authenticates each transaction. Id. at 31-32 (citing Ex. 1005 ¶¶ 75, 101, 159, 182, 262, 263, Fig. 1f). Petitioner further contends that a new user must synchronize a new mobile device with the Immtec server. Id. at 32 (citing Ex. 1005 ¶¶ 265-272). For “receiving . . . a list of products,” Petitioner argues that “Shore-I teaches receiving a list of products (e.g., eTickets) from a remote management server (e.g., Immtec) at a non-browser based application (e.g., the PDA Pay and eTicket/mewallet application) for display using the non- browser based application.” Pet. 32. Petitioner points to Shore-I’s teachings regarding Ticketdownload.com and argues that it is an authorization transaction interface system that “‘offer[s] the ability to download electronic tickets to a personal computer or a wireless-modem-equipped PDA.’” Id. at 32-33 (citing Ex. 1005 ¶¶ 101, 184, 185). Petitioner argues that “Shore-I teaches that a user would ‘search an online merchant’s database for desired tickets’ and the merchant would ‘display available ticket(s) and prices according to the customer’s request 401.” Id. at 33-34 (emphasis in original) (citing Ex. 1005 ¶ 186, Fig. 12a). Petitioner also argues that one of ordinary skill in the art “would have understood that the list of eTickets available for purchase is sent from the management server (e.g., Immtec server) because Shore-I teaches that the Immtec server interfaces with the ticketdownload.com system and serves as IPR2021-01529 Patent 10,699,259 B2 21 the ‘system administrator.’” Pet. 34 (citing Ex. 1003 ¶ 106; Ex. 1005 ¶ 101). Petitioner further argues that Shore-I teaches that “the ticketdownload.com software would ‘work transparently to the user/ticket purchaser when utilized by a licensed merchant,’ such that it would have been obvious to a [person of ordinary skill in the art] that the Immtec server host that is the administrator of ticketdownload.com sends the list of eTickets to the user.” Id. at 34 (citing Ex. 1003 ¶ 106; Ex. 1005 ¶ 185, Figs. 12a-d). Petitioner additionally argues that “Shore-I teaches that a list of eTicket options is sent from the management server (e.g., Immtec) to the PayStick, which [is] an example of a mobile device configured with the PDA Pay application and capable of performing payment transactions without Internet connection.” Pet. 34. Petitioner contends that the Paystick would receive a list of electronic tickets and display the list on an LCD screen, and that the Immtec server would receive requests from a merchant’s point of purchase device and communicate instructions to fulfill the requests. Id. at 34-35 (citing Ex. 1005 ¶¶ 372, 376, 396). According to Petitioner, one of ordinary skill in the art “would have understood that the System Server (e.g., Immtec Server) would send the list of eTickets to the PayStick through the POS interface.” Id. at 35 (citing Ex. 1003 ¶ 107; Ex. 1005 ¶¶ 377-379). Petitioner also contends that Shore-I teaches that similar steps can be performed on a PDA mobile device instead of the Paystick. Id. (citing Ex. 1005 ¶ 341). b) Patent Owner’s Responsive Arguments Patent Owner responds that the Immtec server does not teach a “remote management server.” Prelim. Resp. 29. Specifically, for the first receiving step of claim 1, Patent Owner argues that, “[i]n Shore-I, no such list of products is received from the Immtec server” because “a IPR2021-01529 Patent 10,699,259 B2 22 User/Customer . . . would search an online merchant’s database for desired tickets 400,” the “Merchant would display available ticket(s) and prices according to the customer’s request 401,” and “[t]he licensed Merchant’s site would prompt the Customer with a choice to purchase ticket(s) or not 402.” Id. at 29-30 (emphases in original) (quoting Ex. 1005 ¶¶ 186, 187). Patent Owner, thus, argues that list of available tickets is received from a Merchant or Merchant’s site. Id. at 30 (citing Ex. 1005 ¶¶ 186, 187). In Patent Owner’s view, the Immtec server is an interface for an authorization transaction interface system, referred to as Ticketdownload.com in Shore-I, and “ticketdownload.com is merely ‘a portal’ for merchants, and not ‘a ticket broker web site.’” Prelim. Resp. 30 (citing Ex. 1005 ¶¶ 101, 185). Patent Owner argues that ticketdownload.com “does not provide a list of available tickets; instead, the merchant does.” Id. Patent Owner also argues that “ticketdownload.com “would work transparently [i.e., unbeknownst] to the user/ticket purchaser when utilized by a licensed merchant,” further demonstrating that the merchant, and not the Immtec server, lists available tickets.” Id. (emphasis in original) (citing Ex. 1005 ¶ 185). Patent Owner additionally argues that “the Petition does not identify any disclosure in Angelica that allegedly corresponds to the claimed ‘remote management server.’” Id. at 30-31 (citing Pet. 31-35). c) Insufficient Evidentiary Support for Petitioner’s Argument Claim 1 requires “receiving, at the non-browser based application generated screen, a list of products from a remote management server for display using the non-browser based application.” Ex. 1001, 8:1-4. As pointed out by Patent Owner, Petitioner does not argue with sufficient IPR2021-01529 Patent 10,699,259 B2 23 evidentiary support that Shore-I’s Immtec server teaches the recited “remote management server.” Pet. 31-35. The cited portions of Shore-I do not indicate that the asserted non- browser based application receives a list of products from the Immtec server. In connection with Figure 1a, paragraph 65 of Shore-I states that “[t]he POP eTicket terminal would communicate with a POP ticket server 780 via communications link 785” and that “[t]he ticket server would hold the database of issued, redeemed, or outstanding eTickets which would be used to verify an eTicket.” Ex. 1005 ¶ 65; see also Pet. 31 (citing Ex. 1005 ¶ 65). This cited portion does not teach that the asserted non-browser based application receives a list of products from the Immtec server. Figure 1a also does not show any communication between Immtec server host 750 and PDA 700. Ex. 1005, Fig. 1a. In describing Figure 1f, Shore-I describes exemplary communication events that include request 1013 from PC 1010 to ticket server 1000 and request 1003 from ticket server 1000 to Immtec ticket server 1060. Ex. 1005 ¶ 75; see also Pet. 32 (citing Ex. 1005 ¶ 75). “The Immtec ticket server would then generate and send 1063 the eTicket to the ticket server” and “then send a copy of the eTicket certificate 1066 to the POP ticket server.” Ex. 1005 ¶ 75. “The ticket server would then send the eTicket certificate 1006 to the PC client” that “would then send the eTicket certificate 1016 to the PDA purchase object 1020 hosted by the PDA 700,” and “[t]he PDA purchase object would then store the eTicket certificate.” Id. Paragraph 75 of Shore-I describes sending eTicket certificate 1066 via a PC client to PDA 700, but it does not indicate that the asserted non-browser based application receives a list of products from the Immtec server. IPR2021-01529 Patent 10,699,259 B2 24 Shore-I also describes “[a] server computer or set of server computers would be provided by a Server System with which to provide the interface for the payment system aspect of the invention (referred to herein as the ‘PDA Pay system’) and the authorization transaction interface system (referred to herein as ‘ticketdownload.com’ and/or as the ‘ticketdownload.com system’ and/or as the ‘eTicket System’).” Ex. 1005 ¶ 101; see also Pet. 32 (citing Ex. 1005 ¶ 101). Shore-I also describes that “[t]he systems administrator of both of these systems is referred to herein as ‘Immtec.’” Ex. 1005 ¶ 101. Shore-I further describes ticketdownload.com in relation to licensed online merchants. Ex. 1005 ¶¶ 183-201. In particular, Shore-I states that its “System would provide a web site, referred to herein as ‘Ticketdownload.com’” that “would offer the ability to download electronic tickets to a personal computer or a wireless-modem-equipped PDA.” Id. ¶ 184; see also Pet. 33 (citing Ex. 1005 ¶¶ 184-186). “The System software would provide for storage of electronic tickets (‘eTickets’) in the storage devices configured with the user’s personal computer and PDA” and “would provide for transmission of eTickets at the request of the user via the PDA’s infrared interface to an infrared interface at a point of ticket use.” Ex. 1005 ¶ 184. “The ticketdownload.com software engine would interface with all licensed ticket brokers,” and “eTickets would be purchased through the ticketdownload.com Internet site or directly from any licensed ticket agency or merchant.” Ex. 1005 ¶ 185. In one embodiment, “Ticketdownload.com would not be a ticket broker web site but would instead be a portal through which merchants and ticket brokers are provided the opportunity to offer downloadable eTickets to customers using the PDA Pay & IPR2021-01529 Patent 10,699,259 B2 25 eTicket/mewallet™ System.” Id. “The ticketdownload.com software would work transparently to the user/ticket purchaser when utilized by a licensed merchant.” Id. A “User/Customer (or simply, ‘Customer’) would search an online merchant’s database for desired tickets 400,” and “[t]he Merchant would display available ticket(s) and prices according to the customer’s request 401.” Ex. 1005 ¶ 186, Figs. 12a-12d. “[T]he Merchant would be licensed to provide a link for the Merchant’s customers to the PDA Pay & eTicket/mewallet™ System to download eTickets.” These relied-upon portions of Shore-I do not expressly teach that the asserted non-browser based application receives a list of products from the Immtec server itself. Instead, relevant to the limitation, these paragraphs describe purchasing through ticketdownload.com, not the asserted non- browser based application, and the user searching an online merchant’s database, not searching a list of products received from the Immtec server on the asserted non-browser based application. Ex. 1005 ¶¶ 185, 186. Shore-I also expressly describes that the merchants offer downloadable eTickets on ticketdownload.com, not the Immtec server, to customers using the PDA Pay & eTicket/mewallet System. Id. ¶ 185. To the extent that Petitioner is arguing Shore-I teaches the limitation because the Immtec server is the systems administrator for ticketdownload.com, and, thus, a list of products is received by way of the Immtec server, Shore-I does not describe what, if any involvement, the systems administrator or Immtec has when a user searches an online merchant’s database or when merchants offer downloadable eTickets on ticketdownload.com. See Ex. 1005 ¶¶ 185, 186. Petitioner also does not point to any part of Shore-I that describes the involvement of the Immtec IPR2021-01529 Patent 10,699,259 B2 26 server, other than generating a ticket certificate after purchasing. Pet. 32 (citing Ex. 1005 ¶ 75); Ex. 1005 ¶ 75, Fig. 1f (showing request for eTicket passing through Immtec server 1060 but not showing how a list of available tickets are received at PDA 700 before the request can be made); see also id. ¶ 73 (“The user could use the browser to order a ticket from the ticket broker.”). Other cited portions describe the Immtec server receiving a micropayment from a transaction (Ex. 1005 ¶¶ 159, 182), the Immtec server receiving user’s data (id. ¶ 262), the system servers validating and adding data to a database (id. ¶ 263), and the PDA synchronizing with the Immtec server via a connection with a PC (id. ¶¶ 265-272); see also Pet. 31-32 (citing Ex. 1005 ¶¶ 159, 182, 262, 263, 265-272). Petitioner also relies on portions of Shore-I describing its Directed Purpose System, which can be a PayStick, when used with a point of sale device. Pet. 34-35 (citing Ex. 1005 ¶¶ 341, 377-379); Ex. 1005 ¶¶ 341, 377-379. None of these additionally relied-upon portions of Shore-I provide evidentiary support for Petitioner’s assertion that the asserted non-browser based application receives a list of products from the Immtec server. Petitioner’s declaration testimony does not explain further the arguments or evidence presented in the Petition and does not cite or provide additional evidence beyond that already in the Petition and discussed above. See Ex. 1003 ¶¶ 103-108; see also Prelim. Resp. 26 (responding that declarations that repeat verbatim arguments from a petition are not helpful). Other than Shore-I and the declarant testimony, Petitioner does not provide additional evidence for the first receiving step of claim 1. See Pet. 31-35. IPR2021-01529 Patent 10,699,259 B2 27 d) Alternative Combination with Angelica Petitioner alternatively argues that, “[t]o the extent Patent Owners contend that Shore-I by itself does not render obvious the ‘non-browser based application’ and/or ‘non-browser based application generated screen’ limitations, Shore-I in combination with Angelica renders them obvious.” Pet. 25 (citing Ex. 1003 ¶ 89). According to Petitioner, “Angelica discloses methods and systems for conducting online transactions, . . . using a mobile device that includes a dedicated software” and “Angelica expressly discloses that the software program is a non-browser based program.” Id. at 25-26 (citing Ex. 1006, Abstract, ¶¶ 9, 12, 13, 30, 33, 50, Fig. 5). Petitioner also contends that one of ordinary skill in the art would have been motivated to improve Shore-I’s online payment system by incorporating Angelica’s non-browser based application software installed on a mobile device-to the extent that concept is not already taught by Shore-I-because such an application operates better in the offline environments described in Shore-I (e.g., when the mobile device is used at a point-of-sale without internet connection.). Pet. 28 (citing Ex. 1006 ¶¶ 9, 30). Petitioner further contends that the proposed combination would have involved routine implementation to achieve predictable results and would have been the application of a known concept to a known system with predictable results. Id. at 27-29 (Ex. 1003 ¶¶ 93-102; Ex. 1005 ¶ 1; Ex. 1006 ¶ 9). Petitioner additionally contends that, because Shore-I does not specify how to implement an application on a mobile device to conduct online transactions, one of ordinary skill in the art “would have been motivated to look for ways to implement a non-browser based application on a mobile device used for online transactions” and “would have recognized that [Angelica] teaches exactly the type of non-browser based ‘interface IPR2021-01529 Patent 10,699,259 B2 28 software’ described in Shore-I.” Pet. 29-30 (citing Ex. 1003 ¶ 97; Ex. 1005 ¶¶ 105, 114, 163, 335; Ex. 1006 ¶¶ 9, 13, 49, 137-147, 183-201). Patent Owner responds that Shore-I combined with Angelica fails to teach a “non-browser based application,” Petitioner has failed to show a motivation to combine Shore-I and Angelica, and Petitioner has not shown a reasonable expectation of success in combining Shore-I and Angelica. Prelim. Resp. 22-29. Petitioner’s proposed combination of Shore-I and Angelica does not address the deficiency of the first receiving step of claim 1 discussed above. See Pet. 25-30. Specifically, the proposed combination does not address “receiving . . . a list of products from a remote management server for display using the non-browser based application.” See id. 4. Independent Claim 7 Independent claim 7 recites a “mobile device for processing a transaction.” Ex. 1001, 8:58-9:60. The mobile device of claim 7 includes a mobile device wireless interface configured to “receive, at the non-browser based application generated screen, a list of products from a remote management server for display using the non-browser based application.” Id. at 9:11-14. Petitioner refers to its arguments for the first receiving step of claim 1 for this limitation of claim 7. Pet. 54 (referring to arguments for “Element 1.2” for “Element 7.3”); Ex. 1015, 1 (labeling claim 1’s first receiving step as “1.2”), 2 (labeling claim 7’s first receive limitation as “7.3”). Because Petitioner merely refers to the same arguments that fail to show that Shore-I alone or Shore-I combined with Angelica teaches or suggests that the asserted non-browser based application receives a list of products from the Immtec server, we determine that Petitioner fails to show IPR2021-01529 Patent 10,699,259 B2 29 that Shore-I alone or Shore-I combined with Angelica also fails to teach all the limitations of independent claim 7. 5. Independent Claim 13 For the non-transitory computer readable medium for processing a transaction of claim 13, Petitioner refers again to its arguments for claim 1 without any additional arguments or citations to record evidence. Pet. 56- 57. Claim 13 requires “computer code for receiving, at the non-browser based application generated screen, a list of products from the remote management server for display using the non-browser based application generated screen.” Ex. 1001, 10:29-32. For the limitation quoted above, Petitioner refers to the arguments for claim 1’s “receiving, at the non-browser based application generated screen, a list of products from a remote management server for display using the non-browser based application.” Pet. 56; Ex. 1015, 1 (labeling claim 1’s first receiving step as “1.2”), 4 (labeling the limitation quoted above from claim 13 as “13.2”). Because Petitioner merely refers to the same arguments that fail to show that Shore-I alone or Shore-I combined with Angelica teaches or suggests that the asserted non-browser based application receives a list of products from the Immtec server, we determine that Petitioner fails to show that Shore-I alone or Shore-I combined with Angelica also fail to teach all the limitations of independent claim 13. 6. Dependent Claims 2-6, 8-12, 14-18, 23, 27, 32, and 33 Petitioner challenges dependent claims 2-6, 14, 15, 18, and 24 as unpatentable over Shore-I alone or Shore-I combined with Angelica with citations to the record. Pet. 51-54, 57-60. For claims 8-12, Petitioner refers to its arguments for claims 2-6. Id. at 55. For claims 16 and 17, IPR2021-01529 Patent 10,699,259 B2 30 Petitioner refers to its arguments for claims 16 and 17. Id. at 59. For claims 27 and 33, Petitioner refers to its arguments for claims 18 and 24. Id. at 60. In a separate challenge, Petitioner argues with citations to the record that claims 23 and 32 would have been obvious in view of Shore-I and Angelica. Id. at 60-62. Patent Owner states that, “because Petitioner has failed to establish that any independent claims are obvious, a fortiori, it has failed to establish that any of the dependent claims are obvious over the art in Ground 1.” Prelim. Resp. 31 (emphases in original). Patent Owner also responds similarly for dependent claims 23 and 32. Id. at 31-32. For the reasons discussed above for the independent claims, Petitioner fails to show that Shore-I alone or Shore-I combined with Angelica teaches or suggests all the limitations of dependent claims 6, 14, 15, 18, 23, 24, and 32 and, thus, fails to show that Shore-I or Shore-I combined with Angelica would have rendered obvious these claims. E. Remaining Challenges Petitioner also challenges claims 19 and 28 as unpatentable over Shore-I, Angelica, and Mazur; claims 20, 21, 29, and 30 as unpatentable over Shore-I, Angelica, and Knight; and claims 22 and 31 as unpatentable over Shore-I, Angelica, and Shore-II. Pet. 62-73. Patent Owner responds that Petitioner does not rely on Mazur, Knight, or Shore-II to cure any of the deficiencies of Shore-I or Angelica. Prelim. Resp. 32-33. Patent Owner also argues that the claims challenged in the remaining grounds are not obvious because Petitioner fails to show that claims 1 and 7 would have been obvious in view of Shore-I and Angelica. Id. IPR2021-01529 Patent 10,699,259 B2 31 Petitioner argues that one of ordinary skill in the art would have been motivated to combine Shore-I and Angelica with either “Mazur’s specific teaching of the mobile device monitoring for access to the wireless network and automatically reconnecting when the wireless network is available” (Pet. 63), “Knight’s specific teaching of generating an alert and requesting retransmission if a digital file has not been received from the server within a certain period of time” (id. at 67), or Shore-II’s teaching of a “management server [that] sends a digital artifact (e.g., an advertisement) to the non- browser application generated screen on the mobile device based on geographical location of the mobile device” (id. at 72). Petitioner’s arguments that Shore-I and Angelica further combined with one of Mazur, Knight, or Shore-II would have rendered obvious claims 19-22 and 28-31 do not further address the limitation we discussed above for claim 1, and Petitioner’s proposed modifications do not remedy the deficiencies of Petitioner’s arguments with respect to that claim. Thus, for the reasons discussed above for the independent claims, Petitioner fails to show that Shore-I and Angelica further combined with one of Mazur, Knight, or Shore-II teach or suggest all the limitations of dependent claims 19-22 and 28-31 and, therefore, fails to show that the proposed combinations of references would have rendered obvious these claims. III. CONCLUSION For the reasons above, Petitioner does not show that there is a reasonable likelihood that it would prevail with respect to at least one of the challenged claims. IPR2021-01529 Patent 10,699,259 B2 32 IV. ORDER In consideration of the foregoing, it is hereby: ORDERED that the Petition is denied, and no inter partes review is instituted. FOR PETITIONER: Todd Friedman Jon R. Carter Bao Nguyen KIRKLAND & ELLIS LLP todd.friedman@kirkland.com carterj@kirkland.com bnguyen@kirkland.com FOR PATENT OWNER: Stephen Underwood Jason C. Linger GLASER WEIL FINK HOWARD AVCHEN & SHAPIRO LLP sunderwood@glaserweil.com jlinger@glaser.com