`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`APPLE INC.,
`
`Petitioner,
`
`
`v.
`
`
`FINTIV, INC.,
`
`Patent Owner.
`
`
`
`
`
`Case IPR2022-00976
`U.S. Patent No. 9,892,386
`
`
`
`
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`
` Page(s)
`
`I.
`
`INTRODUCTION ........................................................................................... 1
`
`II.
`
`THE ’386 PATENT AND THE CHALLENGED CLAIMS .......................... 3
`
`A. Overview of the ’386 Patent .................................................................. 3
`
`B.
`
`C.
`
`The ’386 Prosecution History ............................................................... 6
`
`Challenged Claims of the ’386 Patent ................................................... 7
`
`III. A PERSON HAVING ORDINARY SKILL IN THE ART ........................... 7
`
`IV. OVERVIEW OF THE ALLEGED PRIOR ART ............................................ 7
`
`A. Dill et al. U.S. 2009/0265272, Ex. APPL-1005 (“Dill”) ...................... 7
`
`B. Vadhri U.S. 2010/0133334, Ex. APPL-1006 (“Vadhri”) ...................11
`
`C. Akashika et al. U.S. 2009/0217047, Ex. APPL-1007 (“Akashika”)...13
`
`D. Hansen U.S. 2004/0230527, Ex. APPL-1008 (“Hansen”) ..................14
`
`E.
`
`Liao U.S. 7,865,141, Ex. APPL-1009 (“Liao”) ..................................17
`
`V.
`
`RESPONSE TO PETITION GROUNDS 1-2 ...............................................18
`
`A.
`
`Legal Standard .....................................................................................18
`
`B. Dill, in Combination with Vadhri, Akashika, and Hansen Fails
`to Teach or Suggest Every Limitation Recited in the Challenged
`Claims ..................................................................................................20
`
`C.
`
`Claim 1 Would Not Have Been Obvious in View of Dill, Vadhri,
`Akashika, and Hansen (Ground 1) ......................................................21
`
`1.
`
`2.
`
`Limitation 1.1.1: “an integration tier operable to manage
`mobile wallet sessions” .............................................................23
`
`Limitation 1.1.2: “the integration tier also including a
`communication application programming interface (API)
`
`i
`
`
`
`and other communication mechanisms to accept messages
`from channels” ..........................................................................25
`
`Limitation 1.2: “notification services operable to send
`notifications through different notification channels
`including one or more of short message peer-to-peer,
`short-message services and simple mail transfer
`protocol emails” ........................................................................25
`
`Limitation 1.4: “database services operable to store
`financial transaction details, store customer profiles,
`and manage money containers” ................................................26
`
`Limitation 1.6: “a rules engine operable to gather financial
`transaction statistics and use the gathered financial
`transaction statistics to enforce constraints including
`transaction constraints” .............................................................27
`
`Limitation 1.9.2: “the funds being deposited by a
`subscriber at the agent branch using a mobile device
`configured to run a monetary transaction system
` application” ..............................................................................29
`
`Limitation 1.10.5: “committing a pending transaction
`through the business process services” .....................................30
`
`Limitation 1.10.6: “wherein the integration tier
`communicates a transaction commitment request to
`the business process services” ..................................................31
`
`Limitation 1.10.7: “receiving a confirmation from the
`business process services that the pending transaction
`has been committed” .................................................................31
`
`3.
`
`4.
`
`5.
`
`6.
`
`7.
`
`8.
`
`9.
`
`10. Limitation 1.10.8: “sending, through the notification
`services, a receipt notification to the mobile device” ...............32
`
`11. Limitation 1.10.9: “upon receiving a confirmation of
`commitment from the business process services,
`committing the pending transaction to the database
`services” ....................................................................................33
`
`ii
`
`
`
`12. Limitation 1.11.4: “applying with the rules engine,
`velocity rules” ...........................................................................34
`
`13. Limitation 1.11.5: “creating with the database services
`a new pending transaction history record” ...............................35
`
`14. Limitation 1.11.8: “updating, using the database services,
`a pending transaction history record to reflect the funds” ........37
`
`D.
`
`Claim 3 Would Not Have Been Obvious Over Dill in View
`of Vadhri, Akashika, and Hansen (Ground 1); Claim 2 Would
`Not Have Been Obvious Over Dill in View of Vadhri, Akashika,
`Hansen, And Liao (Ground 2) .............................................................38
`
`E.
`
`Limitations in Claims 2 and 3 that are Identical or Similar to
`Claim 1 ................................................................................................38
`
`F.
`
`Limitations Unique to Claim 3 (Ground 1) .........................................41
`
`1.
`
`Limitation [3.10.1]: “wherein the monetary transaction
`system is implemented to transfer funds using the mobile
`device configured to run a monetary transaction system
`application, including performing the following steps:” ..........41
`
`G. Limitations Unique to Claim 2 (Ground 2) .........................................41
`
`1.
`
`2.
`
`Limitation [2.6]: “a mobile device configured to run a
`monetary transaction system application” ................................41
`
`Limitation [2.12.1]: “wherein the monetary transaction
`system is implemented to withdraw funds at an agent
`branch using the mobile device configured to run a
`monetary transaction system application, including
`performing the following steps:” ..............................................42
`
`VI.
`
`INSTITUTION SHOULD BE DENIED UNDER THE FINTIV FACTORS
` .......................................................................................................................43
`
`A.
`
`Fintiv Factor 1 Weighs Against Institution Because a Stay
`Has Not Been Granted in the Related District Court Case
`and There is No Evidence that a Stay Would Be Granted
`if this IPR Proceeding was Instituted ..................................................44
`
`iii
`
`
`
`B.
`
`C.
`
`D.
`
`E.
`
`F.
`
`Fintiv Factor 2 Weighs Against Institution Because the Parallel
`District Court Proceeding Has a Trial Date Likely to Be Scheduled
`Close to, if Not Prior to, the Projected Statutory Deadline for the
`Board’s Final Written Decision...........................................................46
`
`Fintiv Factor 3 Weighs Against Institution Because the Parties
`Will Have Invested Significant Effort in the Parallel Proceeding
`by the Time the Board’s Institution Decision is Due ..........................49
`
`Fintiv Factor 4 is Neutral Against Institution Because There is
`Unknown Amount of Overlap Between the Parallel Proceeding
`and This IPR ........................................................................................50
`
`Fintiv Factor 5 is Neutral Against Institution Because the
`Petitioner Is Not the Same as or Related to the Defendants
`in the Parallel Proceeding ....................................................................51
`
`Fintiv Factor 6 Weighs Against Institution Because There
`Are No Other Circumstances that Favor Institution and the
`Merits of Petitioner’s Challenges Are Weak ......................................51
`
`VII. CONCLUSION ..............................................................................................53
`
`
`
`
`
`
`
`iv
`
`
`
`PATENT OWNER’S EXHIBIT LIST
`
`Description
`Declaration of Dr. Michael I. Shamos, Ph.D., dated August 24,
`2022 (“Shamos”)
`First Amended Complaint for Patent Infringement, Dkt. 20,
`Fintiv, Inc. v. PayPal Holdings, Inc, Civil Action No. 6:22-cv-
`00288-ADA, dated June 24, 2022 (“FAC”)
`Plaintiff Fintiv, Inc.’s Initial Disclosure of Asserted Claims,
`Accused Instrumentalities, and Infringement Contentions, dated
`June 23, 2022 (“Fintiv’s Preliminary Infringement
`Contentions”)
`Fintiv’s Preliminary Infringement Chart for U.S. Patent No.
`9,892,386 – Exhibit C to Plaintiff Fintiv, Inc.’s Initial
`Disclosure of Asserted Claims, Accused Instrumentalities, and
`Infringement Contentions, dated June 23, 2002
`Resume of Michael Ian Shamos
`U.S. Court, Statistics and Reports, U.S. District Court for the
`Eastern District of Texas, Judicial Caseload Profile (March
`2022),
`available
`at
`https://www.uscourts.gov/statistics-
`reports/federal-court-management-statistics-march-2022
`Joint Motion to Enter Agreed Scheduling Order, Dkt. 28, Fintiv,
`Inc. v. PayPal Holdings, Inc, Civil Action No. 6:22-cv-00288-
`ADA, dated August 17, 2022
`U.S. Patent No. 9,892,386 Claims Appendix
`
`Exhibit
`2001
`
`2002
`
`2003
`
`2004
`
`2005
`2006
`
`2007
`
`2008
`
`
`
`
`
`
`v
`
`
`
`I.
`
`INTRODUCTION
`
`The Petition challenges claims 1-3 (“Challenged Claims”) of U.S. Patent No.
`
`9,892,386 (“’386 Patent,” Ex. APPL-1001) under two grounds of unpatentability.
`
`The Board should deny the institution of Inter Partes Review of the ’386 Patent for
`
`at least the following reasons.
`
`Institution should be denied under the Board’s precedential orders in Apple v.
`
`Fintiv (IPR2020-00019, Paper 11, Order on Supplemental Briefing on Discretionary
`
`Denial) as institution of this IPR would cause the parties and the Board to incur
`
`significant inefficiencies and wasted efforts based on the overlap of issues with
`
`previously filed district court litigation involving the ’386 Patent. Notably, trial in
`
`that district court action is tentatively scheduled within close proximity in the
`
`projected deadline to issue a final written decision in this IPR.
`
`Furthermore, the Petitioner has not met its burden of showing that the cited
`
`references disclose or render obvious each and every element of any Challenged
`
`Claim for at least the following reasons:
`
`(1) U.S. Patent Application Publication No. 2009/0265272 (“Dill,” Ex.
`
`APPL-1005), which is the primary reference relied upon in Grounds 1-2 of the
`
`Petition, does not disclose a method that includes a “monetary transaction system
`
`for conducting monetary transactions between transaction system subscribers and
`
`other entities,” as claimed.
`
`
`
`
`
`(2) The proposed combination of Dill and U.S. Patent Application
`
`Publication No. 2010/0133334 (“Vadhri,” Ex. APPL-1006), U.S. Patent Application
`
`Publication No. 2009/0217047 (“Akashika,” Ex. APPL-1007), and U.S. Patent
`
`Application Publication No. 2004/0230527 (“Hansen,” Ex. APPL-1008), in
`
`Ground 1 does not cure the deficiencies of Dill. Like Dill, Vadhri, Akashika, and
`
`Hansen, either alone or in combination, does not teach a “monetary transaction
`
`system for conducting monetary
`
`transactions between
`
`transaction system
`
`subscribers and other entities,” as claimed.
`
`(3) The proposed combination of Dill and Vadhri, Akashika, Hansen, and
`
`U.S. Patent No. 7,865,141 (“Liao,” Ex. APPL-1009), in Ground 2 does not cure the
`
`deficiencies of Dill. Like Dill, Vadhri, Akashika, Hansen, and Liao, either alone or
`
`in combination, does not teach a “monetary transaction system for conducting
`
`monetary transactions between transaction system subscribers and other entities,” as
`
`claimed.
`
`For these reasons and, as discussed more fully herein, institution should be
`
`denied because Petitioner has not met its burden in showing that the cited references
`
`disclose or render obvious each and every feature of any Challenged Claim.
`
`2
`
`
`
`II. THE ’386 PATENT AND THE CHALLENGED CLAIMS
`
`A.
`
` Overview of the ’386 Patent
`
`The ’386 Patent relates to a mobile financial services (mFS) transaction
`
`system comprising subscribers and agents. (Ex. APPL-1001 at 1:54-61; Ex. 2001,
`
`Declaration of Dr. Michael I. Shamos, Ph.D. (“Shamos”) at ¶ 36). Agents register
`
`subscribers and deposit funds into, and withdraw funds from, the system under
`
`direction from subscribers. Ex. APPL-1001 at 6:25-41. A subscriber has a mobile
`
`wallet application running on a mobile device, through which the subscriber interacts
`
`with the system. Ex. APPL-1001 at 6:42-7:9. An agent has an account in a partner
`
`bank, which holds the agent’s funds. Ex. APPL-1001 at 8:57-9:4.
`
`As described in the specification, the mFS transaction system is implemented
`
`using the concepts of “eMoney” in conjunction with an “mFS platform” and a
`
`“mobile wallet.” Further, the mFS platform is configured with functionality of
`
`managing the “balance of mobile wallet accounts, agent accounts, and the accounts
`
`of any other program participant,” as well as the functionality of handling “balance
`
`inquiries, credits, debits, and transaction roll-backs.” Ex. APPL-1001 at 9:54-58. In
`
`the specification, eMoney is defined as:
`
`“The mFS platform manages the balance of mobile wallet accounts for each
`subscriber as value is transferred from one mobile wallet to another (e.g. from
`a subscriber's mobile wallet to an agent's mobile wallet in payment for goods
`or services). This value is referred to herein as ‘eMoney’.” Ex. APPL-1001 at
`8:13-18 (emphasis added).
`
`3
`
`
`
`The relationship among various parties to a transaction is illustrated in Fig. 2
`
`of the ’386 Patent, relied on by Petitioner and reproduced below:
`
`The above Fig. 2 does not depict an agent expressly although the ’386 Patent
`
`discloses that Entity 222 may be an agent. Ex. APPL-1001 at 14:51-64. An
`
`exemplary use of an agent to add money to a subscriber’s account is shown in Fig.
`
`
`
`3:
`
`4
`
`
`
`
`
`A subscriber to the system of the ’386 Patent may be unbanked, that is, need
`
`not have a bank account to send or receive money. Ex. APPL-1001 at 1:53-61;
`
`12:51-13:2. For example, in Fig. 3 an unbanked subscriber can bring cash to an
`
`agent branch (301) and the agent branch can add funds to the eMoney Balance in the
`
`subscriber’s mobile wallet (303).
`
`Monetary Transaction System 210 has multiple components, further
`
`illustrated in Fig. 1:
`
`The system permits subscriber-to-subscriber transfers, as shown in Fig. 17B:
`
`
`
`5
`
`
`
`
`
`Fig. 17B is explained in Ex. APPL-1001 at 26:4-27. Not shown expressly in
`
`Fig. 17B is the involvement of transaction system 210, which verifies that
`
`Subscriber A has sufficient funds to make a transfer, debits Subscriber A’s mobile
`
`wallet (mWallet) by $DC, adds $DC to Subscriber B’s wallet by sending a “System
`
`Generated SMS.” To engage in transactions, the subscriber’s mobile device hosts a
`
`mobile wallet application that may reside on a SIM card or in the device’s memory.
`
`Ex. APPL-1001 at 12:58-65.
`
`In sum, Claim 1 is drawn to a system allowing a subscriber to deposit funds
`
`into an account. (Shamos at ¶ 43). Claim 2 is drawn to a system allowing a subscriber
`
`to withdraw funds from an account. (Id.) Claim 3 is drawn to a system allowing a
`
`subscriber to transfer funds to a recipient. (Id.)
`
`B.
`
`The ’386 Prosecution History
`
`The ’386 prosecution was uneventful and took only 20 months. The Examiner
`
`considered 541 separate references, including Petitioner’s primary reference, Dill,
`
`6
`
`
`
`but did not issue a single prior art rejection. There were two rejections based on
`
`§ 101, and these were overcome by minor amendments to the claims.
`
`C. Challenged Claims of the ’386 Patent
`
`Petitioner challenges independent Claims 1, 2, and 3. (Ex. 2008, Claims
`
`Appendix).
`
`III. A PERSON HAVING ORDINARY SKILL IN THE ART
`
`A POSITA as of the effective filing date of the ’386 Patent would have had a
`
`bachelor’s degree in electrical engineering, computer science, or equivalent training,
`
`and approximately two years of work experience in software development involving
`
`monetary transaction systems. (Shamos at ¶ 34). Lack of work experience can be
`
`remedied by additional education, and vice versa. (Id.) Appropriate experience
`
`could substitute for education.
`
`IV. OVERVIEW OF THE ALLEGED PRIOR ART
`
`A. Dill et al. U.S. 2009/0265272, Ex. APPL-1005 (“Dill”)
`
`Dill is entitled “Money Transfers Utilizing a Unique Receiver Identifier.” It
`
`discloses a transaction system whereby mobile device users can send and receive
`
`money.
`
`Dill teaches a financial transfer system for “utilizing a unique identifier to
`
`facilitate flexible payment options for the transaction.” (Ex. APPL-1005 at
`
`Abstract). Specially, in some embodiments of Dill’s money transfer system, a
`
`money transfer can be initiated via an agent of a money transfer facilitator or a
`
`7
`
`
`
`mobile wallet application by a sender providing an identifier for the transaction to a
`
`recipient. (Id.) In turn, the recipient uses the identifier, in combination with
`
`functionality of a mobile wallet application of a mobile device, to request or “pull”
`
`the money transfer to an account associated with the mobile wallet application. (Id.)
`
`In other embodiments of Dill’s money transfer system, a transaction request (e.g., a
`
`payment request) initiated from the mobile wallet application by the sender (and
`
`validated by the recipient’s mobile wallet application) is processed by an application
`
`hosted by the money transfer facilitator. (Id. at [0008]). As a result of fulfilling the
`
`transaction request, at least one or a plurality of destination accounts for the money
`
`transaction is credited as indicated by the transaction request. (Id.) In particular, Dill
`
`emphasizes the improved flexible payment option feature of the money transfer
`
`system that allows that “the recipient can receive the transfer to the mobile wallet
`
`account even if the sender does not know that such a delivery is available.” (Id. at
`
`[0004]).
`
`An exemplary Dill architecture is shown in its Fig. 9, relied on by Petitioner
`
`and reproduced below.
`
`8
`
`
`
`
`
`It is immediately apparent from Fig. 9 that the mobile devices used by Sender
`
`105 and Recipient 110 do not host mobile wallets. (Shamos at ¶ 48). Their respective
`
`M-wallets 125 and 130 reside with the Mobile Network Operator (MNO) 120. (Id.)
`
`In fact, Dill discloses that parties access the transaction system not necessarily
`
`through a mobile application running on their mobile devices, but instead by visiting
`
`a website of a money transfer facilitator:
`
`For example, a sender 105 can access the services of the money
`transfer facilitator 140 via a web site of the money transfer facilitator
`140 and initiate a money transfer from a source account 165 owned by
`the sender 105. Ex. APPL-1005 at [0051].
`
`9
`
`
`
`The money transfer transaction may be initiated from a retail agent
`location of a money transfer facilitator (such as Western Union), from
`a web site of the money transfer facilitator, from a telephone money
`transfer service of the money transfer facilitator, from a mobile money
`transfer send, a kiosk, an ATM or from other channels. Ex. APPL-
`1005 at [0033].
`
`Dill does not disclose that any wallet at all resides on the user’s mobile device.
`
`(Shamos at ¶ 49).
`
`In Dill, possessors of M-wallets need associated bank accounts, e.g., in
`
`financial institutions 160 and 170. Dill discloses that it is possible for a sender who
`
`has no bank account to send money to a subscriber by using cash at an agent. Such
`
`a scenario is illustrated in Dill Fig. 4 and described at [0071]. However, in such a
`
`scenario the sender does not have an M-Wallet. (Shamos at ¶ 50).
`
`Dill also discloses that a subscriber who has an M-Wallet can send money to
`
`a recipient who does not have an M-Wallet by transferring money to an agent and
`
`sending a message to the recipient to pick up cash at the agent. (Shamos at ¶ 51).
`
`This is illustrated in Dill Fig. 3 and described at [0066]. In such a scenario, the
`
`recipient does not have an M-Wallet. (Shamos at ¶ 51).
`
`There is no possibility in Dill for an unbanked sender to send money to an
`
`unbanked recipient because at least one of the parties must have an M-Wallet and
`
`therefore must have an account at a financial institution. (Shamos at ¶ 52). By
`
`contrast, in the ’386 Patent, neither sender nor recipient is required to have an
`
`account at a financial institution. (Id.)
`
`10
`
`
`
`B. Vadhri U.S. 2010/0133334, Ex. APPL-1006 (“Vadhri”)
`
`Vadhri is entitled “System and Method to Allow Access to a Value Holding
`
`Account.”
`
`An exemplary architecture of Vadhri is shown in its Fig. 5, relied on by
`
`Petitioner and reproduced below.
`
`
`
`11
`
`
`
`A key component in Vadhri is Account Access Card 513, as shown in Fig. 5.
`
`Vadhri makes clear that, while Account Access Card 513 is not necessarily a credit
`
`card, it is nevertheless a physical card:
`
`Various example embodiments include a credit card from which a
`temporary card number may be requested and displayed so that the
`temporary card number can be used to purchase goods and/or
`services. The credit card may include a traditional 16-digit credit card
`number and associated expiration date that can be used for account
`identification and/or account verification. As used herein, a credit card
`is an example of an account access object. It may be noted that the
`present subject matter is not limited to a credit cards and credit card
`accounts, any type of value holding account may be associated with an
`account access object. Example account access objects may include
`financial instruments such as check cards, gift cards, credit cards,
`charge cards, debit cards or any other physical object. Ex. APPL-
`1006 at [0013].
`
`That is, the user must possess a physical card in order to access their account.
`
`(Shamos at ¶ 56). No such physical card is disclosed in Dill, and Petitioner does not
`
`explain how Dill and Vadhri could be combined without a physical card, so any
`
`combination of Dill and Vadhri would require a physical card. (Id.) There is no
`
`physical card in the ’386 Patent. (Id.)
`
`Petitioner does not explain why a POSITA, even if somehow motivated to
`
`combine Dill with Vadhri, would discard the physical card and include only the
`
`hindsight features relied on by Petitioner, namely application programming
`
`interfaces (APIs) and secure, perishable codes. (Shamos at ¶ 57).
`
`12
`
`
`
`C. Akashika et al. U.S. 2009/0217047, Ex. APPL-1007 (“Akashika”)
`
`Akashika is entitled “Service Providing System, Service Providing Server and
`
`Information Terminal Device.”
`
`An exemplary architecture of Akashika is shown in its Fig. 1, reproduced
`
`below.
`
`
`
`The Petition cites Akashika for the proposition that “it was known to secure
`
`financial transactions by using an access control list.” Pet. at 7. However, essential
`
`to security in Akashika is the “secure chip 500,” also referred to as “secure memory.”
`
`(Shamos at ¶ 60). Akashika contains the following disclosure:
`
`A service providing system is provided, which includes a client device
`capable of accessing a tamper-resistant secure memory, an area
`management server managing memory area of the secure memory and
`a service providing server providing service that uses the secure
`memory to the client device, and which improves the security at the
`
`13
`
`
`
`time of sending an access control list provided by the area
`management server and an instruction set provided by the service
`providing server to the client device by using a digital signature and a
`certificate. Ex. APPL-1007 at Abstract.
`
`Further, Akashika discloses:
`
`The area management server may be provided with an access control
`list generation section generating an access control list (ACL) in
`which a memory area of the secure chip, access to which is permitted
`to the client device, is described, a signature generation section
`generating a first digital signature, by using the first encryption key,
`from the second decryption key obtained from the service providing
`server and the access control list and a certificate generation section
`generating a service providing server certificate that includes the
`second decryption key, the access control list and the first digital
`signature. Ex. APPL-1007 at [0012].
`
`In order to achieve the security of Akashika, any combination of Dill and
`
`Akashika would require a secure chip and digital signatures, which are completely
`
`absent from the ’386 Patent, which achieves security without either a secure chip or
`
`digital signatures. (Shamos at ¶ 62).
`
`Petitioner does not explain why a POSITA, even if somehow motivated to
`
`combine Dill with Akashika, would discard the secure chip and digital signatures
`
`and borrow only the hindsight feature relied on by Petitioner, namely an access
`
`control list. (Shamos at ¶ 63).
`
`D. Hansen U.S. 2004/0230527, Ex. APPL-1008 (“Hansen”)
`
`Hansen is entitled “Authentication for Online Money Transfer.” It discloses
`
`“a method for processing a transaction where the transaction is initiated by a payor
`
`online, but paid to a payee in-person.” Ex. APPL-1008 at Abstract. It does not
`
`14
`
`
`
`disclose mobile wallets and has bears no relation to either Dill or the ’386 Patent.
`
`(Shamos at ¶ 64). It does disclose manual verification of a transaction if a computed
`
`risk level is exceeded, a feature that is not disclosed or claimed in the ’386 Patent.
`
`(Id.)
`
`Petitioner asserts that Hansen “shows that it was known to utilize velocity
`
`limits in authorizing a mobile transaction.” Pet. at 7. However, Hansen is not drawn
`
`to mobile transactions. (Shamos at ¶ 65). It does include transactions initiated by
`
`telephone, and it is possible that such a telephone might be mobile, but Hansen does
`
`not disclose any particular screening of transactions based on their manner of
`
`initiation, and does not call out velocity checking as a method specifically useful in
`
`mobile transactions. (Id.)
`
`An exemplary architecture of Hansen is shown in its Fig. 1A, relied on by
`
`Petitioner and reproduced below.
`
`15
`
`
`
`
`
`Petitioner does not explain why a POSITA, even if somehow motivated to
`
`combine Dill with Hansen, would discard all the other teachings of Hansen and
`
`borrow only the hindsight feature relied on by Petitioner, namely utilizing velocity
`
`limits. (Shamos at ¶ 67). Nevertheless, in Hansen, if velocity limits are exceeded,
`
`there is no teaching not to proceed with the transaction, as there is in the ’386 Patent.
`
`(Id.) Instead, Hansen proceeds to a manual process:
`
`Where this payor 110 has sent more than two thousand dollars in the
`last thirty days, the amount velocity check is triggered and requires
`manual validation of the transaction in Step 444. If over S2,000, the
`payor is referred to retail location. Ex. APPL-1008 at [0061].
`
`16
`
`
`
`Therefore, while Hansen discloses velocity checking, it does not disclose
`
`terminating a transaction if the velocity check generates suspicion. (Shamos at ¶
`
`68).
`
`E.
`
`Liao U.S. 7,865,141, Ex. APPL-1009 (“Liao”)
`
`Liao is entitled “Chipset for Mobile Wallet System.”
`
`An exemplary architecture of Liao is shown in its Fig. 3, relied on by
`
`Petitioner and reproduced below.
`
`Liao is drawn to contactless payments, in particular those involving a
`
`
`
`contactless reader 220:
`
`The present invention relates to a chipset for a mobile wallet system,
`and more particularly, to a chipset implemented into a SIM card in a
`communication terminal, e.g., a mobile phone, in communication with
`a contactless reader. Ex. APPL-1009 at 1:17-20.
`
`The ’386 Patent is not drawn to contactless payments and does not mention
`
`them. (Shamos at ¶ 72). Dill is also not drawn to contactless payments. (Id.)
`
`17
`
`
`
`Combining Liao with Dill would involve adding a contactless chip to a mobile
`
`device. (Id.) Petitioner does not explain why a POSITA, even if somehow motivated
`
`to combine Dill with Liao, would discard all the other teachings of Liao and borrow
`
`only the hindsight feature relied on by Petitioner, namely adding a contactless chip
`
`and allowing “a mobile wallet subscribe to withdraw funds.” (Shamos at ¶ 72).
`
`V. RESPONSE TO PETITION GROUNDS 1-2
`
`The Board should decline to review the Petition under 35 U.S.C. § 314(a)
`
`because, as set forth in more detail below, Petitioner has not shown by a
`
`preponderance of the evidence that it will prevail with respect to any challenged
`
`claims.
`
`A. Legal Standard
`
`Under 35 U.S.C. § 103, the question is whether the claimed subject matter
`
`would have been obvious to a POSITA at the time the invention was made. To
`
`assess the issue, the scope and content of the alleged prior art are to be determined;
`
`differences between the alleged prior art and the claims at issue are to be ascertained;
`
`and the level of ordinary skill in the pertinent art resolved. Graham v. John Deere
`
`Co., 383 U.S. 1, 17 (1966). Secondary considerations such as commercial success,
`
`long felt but unsolved needs, and failure of others should also be considered. (Id. at
`
`35-36).
`
`18
`
`
`
`A reference must be considered for all that it teaches, including disclosures
`
`that diverge and teach away from the invention at hand as well as disclosures that
`
`point toward and teach the invention. In re Dow Chem. Co., 837 F.2d 469, 426 (Fed.
`
`Cir. 1988). It is improper to take statements in the alleged prior art out of context
`
`and give them meanings they would not have had to a person of ordinary skill having
`
`no knowledge of the claimed invention. In re Wright, 866 F.2d 422 (Fed. Cir. 1989).
`
`Each Graham factor must be addressed before a conclusion of obviousness
`
`can be reached. In re Cyclobenzaprine Hydrochloride Extended-Release Capsule
`
`Patent Litig., 676 F.3d 1063, 1077 (Fed. Cir. 2012). Importantly, the obviousness
`
`inquiry must be taken without any “hint of hindsight,” Star Scientific, Inc. v. R.J.
`
`Reynolds Tobacco Co., 655 F.3d 1364, 1375 (Fed. Cir. 2011), so as to avoid
`
`“reconstruction by using the patent in suit as a guide through the maze of prior art
`
`references, combining the right references in the right way so as to achieve the result
`
`of the claims in suit.” In re NTP, Inc., 654 F.3d 1279, 1299 (Fed. Cir. 2011) (internal
`
`citation omitted).
`
`Conclusory allegations regarding obviousness are insufficient to establish a
`
`reasonable likelihood of unpatentability in an IPR petition. Sony Corp. of Am. v.
`
`Network-1 Sec. Sols., Inc., IPR2013-00092, Paper No. 21 at 19, 28 (P.T.A.B. May
`
`24, 2013).
`
`19
`
`
`
`The Petitioners “must show some reason why a person of ordinary skill in the
`
`art would have thought to combine particular available elements of knowledge, as
`
`evidenced by the prior art, to reach the claimed invention.” Heart Failure Tech., LLC
`
`v. Cardiokinetix, Inc., IPR2013-00183, Paper No. 12 at 9 (P.T.A.B. July 31, 2013).
`
`Regardless of whether a patent is being challenged based on a combination of
`
`references or a single reference, the party challenging the patent must show both (1)
`
`a “motivation” to arrive at the claimed arrangement, and (2) a “reasonable
`
`expectation of success.” In re Stepan Co., 868 F.3d 1342, 1346 (Fed. Cir. 2017).
`
`The Federal Circuit has cautioned that “[t]he inventor’s own path itself never leads
`
`to a conclusion of obviousness; that is hindsight.” Otsuka Pharm. Co. v. Sandoz,
`
`Inc., 678 F.3d 1280, 1296 (Fed. Cir. 2012). Thus, it is improper to rely on the patent
`
`itself as a roadmap for combining prior-art elements “like separate pieces of a simple
`
`jigsaw puzzle.” InTouch Techs., Inc. v. VGO Commc’ns, Inc., 751 F.3d 1327, 1349
`
`(Fed. Cir. 2014).
`
`B. Dill, in Combination with Vadhri, Akashika, and Hansen Fails to
`Teach or Suggest Every Limitation Recited in the Challenged
`Claims
`
`Petitioner asserts in Ground 1 of the Petition that the quadruple combination
`
`of Dill, Vadhri, Akashika, and Hansen renders obvious independent claims 1, and 3.
`
`As explained below, claims 1 and 3 would not have been obvious in view of Dill,
`
`Vadhri, Akashika, and Hansen. (Shamos at ¶73.) Furthermore, there would have been
`
`20
`
`
`
`no reason to combine Dill with Vadhri, Akashika, and Hansen in the manner chosen
`
`by Petitioner based purely on hindsight. (Id.)
`
`Further, the alleged “combination” of the four references is not a true
`
`combination at all. (Shamos at ¶74.) At no point does Petitioner explain which
`
`structures from any of the references would be combined with which structures from
`
`any other reference, or how they would be combined to yield