UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`APPLE INC.,
`
`Petitioner,
`
`
`v.
`
`
`FINTIV, INC.,
`
`Patent Owner.
`
`
`
`
`
`Case No. IPR2022-00976
`U.S. Patent N o . 9,892,386
`
`
`
`
`
`PATENT OWNER’S RESPONSE
`
`
`
`
`
`
`
`
`
`
`

`

`TABLE OF CONTENTS
`
`
`
`I.
`
`INTRODUCTION ................................................................................. 1
`
`II.
`
`OVERVIEW OF THE ’386 Patent ....................................................... 1
`
`III. The ’386 PATENT SPECIFICATION AND CLAIMS ....................... 3
`
`A. Overview Of Monetary Transaction System .............................. 3
`
`B.
`
`C.
`
`Architecture Of Monetary Transaction System .......................... 7
`
`Staged Commitment Process Used By The Monetary
`Transaction System ..................................................................... 9
`
`D. Details Of Business Process Services Component ...................11
`
`E.
`
`The Claims Of The ’386 Patent ................................................13
`
`IV. CLAIM CONSTRUCTION ................................................................15
`
`A.
`
`B.
`
`C.
`
`D.
`
`E.
`
`“Committing” A Pending Transaction ......................................16
`
`“At Least One Of Executing Financial Transactions,
`Auditing Financial Transactions, Invoking Third-Party
`Services, Handling Errors, And Logging Platform
`Objects” (Claims 1-3) ...............................................................19
`
`“Auditing Financial Transactions” ...........................................21
`
`“Error Handling” .......................................................................22
`
`“Logging” Platform Objects .....................................................23
`
`V. DESCRIPTION OF DILL ...................................................................24
`
`VI. THE PETITION HAS NOT MET ITS BURDEN FOR
`GROUND 1 ...............................................................................26
`
`A. Dill Fails To Teach The Deposit Transaction Recited In
`Claim 1 ......................................................................................26
`
`B.
`
`Dill Fails To Teach Or Suggest A Monetary Transaction
`System That Receives “A Communication Message From
`The Mobile Device ... Indicating That The Subscriber
`Desires To Deposit A Specified Amount Of Funds Into
`The Subscriber’s Account” .......................................................30
`
`
`
`i
`
`

`

`C.
`
`Dill Fails To Teach The Staged Commitment Process
`Recited In Claim 1 ....................................................................33
`
`D. Dill Fails To Teach The Claimed Business Process
`Services .....................................................................................38
`
` The Petition Fails To Map Dill To Auditing A Financial Transaction
`....................................................................................................... 38
`
` The Petition Fails To Map Dill To Handling Errors .......................... 40
`
` The Petition Fails To Map Dill To Logging Platform Objects .......... 41
`
`VII. THE PETITION HAS NOT MET ITS BURDEN FOR
`GROUND 2 ...............................................................................43
`
`A. Dill Fails To Contemplate The Withdrawal Transaction In
`Claim 2 ......................................................................................43
`
`B.
`
`C.
`
`Dill Fails To Teach The Staged Commitment Process In
`Claims 2-3 .................................................................................44
`
`Dill Fails To Teach The Claimed Business Process
`Services .....................................................................................44
`
`VIII. CONCLUSION ...................................................................................45
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ii
`
`

`

`TABLE OF AUTHORITIES
`
` Page(s)
`
`Federal Cases
`
`Fintiv, Inc. v. Paypal Holding, Inc.,
`6:22-CV-00288-ADA (W.D. Tex. 2022), Dkt. 60 ............................................. 24
`
`Nevro Corp. v. Boston Sci. Corp.,
`955 F.3d 35 (Fed. Cir. 2020) .............................................................................. 12
`
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) .......................................................................... 15
`
`Renishaw Pub. Ltd. Co. v. Marposs Societa’ Per Azioni,
`158 F.3d 1243 (Fed. Cir. 1998) .......................................................................... 15
`
`SuperGuide Corp. v. DirecTV Enters.,
`358 F.3d 870 (Fed. Cir. 2004) ............................................................................ 19
`
`
`
`
`
`
`
`
`
`iii
`
`

`

`PATENT OWNER’S EXHIBIT LIST
`PATENT OWNER’S EXHIBIT LIST
`
`2001|Declaration of Dr. Michael I. Shamos, Ph.D., dated August 24, 2022
`E
`xX.
`Ex. 2001 Declaration of Dr. Michael I. Shamos, Ph.D., dated August 24, 2022
`
`002|First Amended Complaint for Patent Infringement, Dkt. 20, Fintiv,
`x. 2
`E
`Ex. 2002 First Amended Complaint for Patent Infringement, Dkt. 20, Fintiv,
`Inc. v. PayPal Holdings, Inc, Civil Action No. 6:22-cv00288-ADA,
`Inc. v. PayPal Holdings, Inc, Civil Action No. 6:22-cv00288-ADA,
`dated June 24, 2022 (“FAC’’)
`dated June 24, 2022 (“FAC”)
`003|Plaintiff Fintiv, Inc.’s Initial Disclosure of Asserted Claims, Accused
`x. 2
`E
`Ex. 2003 Plaintiff Fintiv, Inc.’s Initial Disclosure of Asserted Claims, Accused
`Instrumentalities, and Infringement Contentions, dated June 23, 2022
`Instrumentalities, and Infringement Contentions, dated June 23, 2022
`(‘Fintiv’s Preliminary Infringement Contentions”)
`(“Fintiv’s Preliminary Infringement Contentions”)
`
`
`Ex. 2004|Fintiv’s Preliminary Infringement Chart for U.S. Patent No.
`Ex. 2004 Fintiv’s Preliminary Infringement Chart for U.S. Patent No.
`9,892,386 — Exhibit C to Plaintiff Fintiv, Inc.’s Initial Disclosure of
`9,892,386 – Exhibit C to Plaintiff Fintiv, Inc.’s Initial Disclosure of
`Asserted Claims, Accused Instrumentalities, and Infringement
`Asserted Claims, Accused Instrumentalities, and Infringement
`Contentions, dated June 23, 2002
`Contentions, dated June 23, 2002
`Ex. 2005|Resume of Michael Ian Shamos
`Ex. 2005 Resume of Michael Ian Shamos
`
`United Kingdom, Open CompanyLtd, 1996. Ex. 2011|Definition of auditing from Auditing: Principles and Techniques,
`
`Ex. 2006|U.S. Court, Statistics and Reports, U.S. District Court for the
`Ex. 2006 U.S. Court, Statistics and Reports, U.S. District Court for the
`Eastern District of Texas, Judicial Caseload Profile (March 2022),
`Eastern District of Texas, Judicial Caseload Profile (March 2022),
`available at https://www.uscourts. gov/statisticsreports/federal-court-
`available at https://www.uscourts.gov/statisticsreports/federal-court-
`management-statistics-march-2022
`management-statistics-march-2022
`
`007|Joint Motion to Enter Agreed Scheduling Order, Dkt. 28, Fintiv, Inc.
`x. 2
`E
`Joint Motion to Enter Agreed Scheduling Order, Dkt. 28, Fintiv, Inc.
`Ex. 2007
`v. PayPal Holdings, Inc, Civil Action No. 6:22-cv-00288- ADA,
`v. PayPal Holdings, Inc, Civil Action No. 6:22-cv-00288- ADA,
`dated August 17, 2022
`dated August 17, 2022
`
`U.S. Patent No. 9,892,386 Claims Appendix
`x. 2
`E
`Ex. 2008 U.S. Patent No. 9,892,386 Claims Appendix
`
`
`Ex. 2009|Declaration of Dr. Michael I. Shamos, Ph.D., dated February 10,
`x. 2
`Ex. 2009 Declaration of Dr. Michael I. Shamos, Ph.D., dated February 10,
`2023
`2023
`
`
`Ex. 2010|Definition of “commitment”, “rollback” and “transaction” from “
`xX.
`Ex. 2010 Definition of “commitment”, “rollback” and “transaction” from “
`Distributed Transaction Processing: Reference Model, Version 3,
`Distributed Transaction Processing: Reference Model, Version 3,
`United Kingdom, Open Company Ltd, 1996.
`
`Ex. 2011 Definition of auditing from Auditing: Principles and Techniques,
`Pearson Education, 2006
`Pearson Education, 2006
`
`Ex. 2012|Definition of error handling from Kingsley-Hughes, Adrian, et al.,
`Ex. 2012 Definition of error handling from Kingsley-Hughes, Adrian, et al.,
`VBScript Programmer’s Reference, United Kingdom, Wiley, 2007
`VBScript Programmer’s Reference, United Kingdom, Wiley, 2007
`
`
`
`
`iv
`
`

`

`Ex. 2013 Definition of logging from Concise Oxford English Dictionary:
`Luxury Edition, United Kingdom, OUP Oxford, 2011
`
`Ex. 2014
`
`IETF RFC 2935, published September of 2000
`
`Ex. 2015 Fintiv, Inc. v. Paypal Holding, Inc., 6:22-CV-00288-ADA (W.D.
`Tex. 2022), Dkt. 60 (Claim Construction Order)
`
`Ex. 2016 U.S. Application No. 13/964,707, Response to Office Action dated
`December 14, 2014
`
`Ex. 2017 Technical Standard “Data Management: Structured Query Language
`(SQL) Version 2, p. 28
`
`
`
`
`
`v
`
`

`

`I.
`
`INTRODUCTION
`
`The Petition challenges claims 1-3 (“Challenged Claims”) of U.S. Patent
`
`No. 9,892,386 (“‘386 Patent,” Ex. 1001) under two grounds of unpatentability. The
`
`Board should find that Petitioner has failed to meet its burden of proving the
`
`unpatentability of the Challenged Claims. As discussed below, the mappings in the
`
`Petition fail to disclose multiple aspects of each of the Challenged Claims. Patent
`
`Owner’s explanations herein are supported by a further Declaration of Dr. Michael
`
`I. Shamos, an expert in the field. Ex. 2009.
`
`II. OVERVIEW OF THE ’386 Patent
`
`The ’386 Patent recognized that there were individuals who lacked access to
`
`a bank account. The specification refers to such individuals as “unbanked
`
`subscribers” and provides a “mobile wallet application” that is suitable for use by
`
`such persons. Ex. 1001, 1:58-59; 12:54-58. The specification also recognized that
`
`many unbanked subscribers at the time primarily used prepaid phones, and disclosed
`
`a mobile wallet application that was installable on both plan-based phones and
`
`prepaid mobile phones Id., 15:29-34. The mobile wallet application on the phone
`
`provided the unbanked subscriber with the ability to initiate financial transactions
`
`from his or her mobile phone, as shown in Figure 2 below.
`
`1
`
`

`

`
`
`Among other functions, the mobile wallet facilitates the transfer of “eMoney”
`
`between subscribers, one or both of which may be unbanked. Id., 17:57-59. The
`
`problem and solution were summarized during the prosecution of a parent
`
`application as follows:
`
`... While mobile wallets can be used to conduct financial
`transactions, there are many technical difficulties associated with
`conducting certain financial transactions (even electronically) that
`require technical solutions (such as those that are now claimed). By way
`of example, there are instances in which it is not practical to utilize a
`credit card (e.g., transferring money between two individuals). In some
`instances, a participant may not have access to a regular bank account
`or a credit card (e.g., an unbanked subscriber, as recited in claim 28).
`In these instances, it can be difficult to conduct financial transactions.
`
`The present invention, while it is not limited to either of the
`foregoing examples, provides computing systems and corresponding
`hardware storage devices that can be used to facilitate the transfer of
`funds, deposit funds and withdrawal funds with a user’s mobile wallet
`account, even when the subscriber/participant is an unbanked
`subscriber that does not have access to a regular bank account or credit
`
`
`
`2
`
`

`

`union ... U.S. Application No. 13/964,707, Response to Office Action
`dated December 14, 2014 at 18 (Ex. 2016).
`
`III. The ’386 PATENT SPECIFICATION AND CLAIMS
`
`A. Overview Of Monetary Transaction System
`
`The ’386 Patent describes a monetary transaction system “for conducting
`
`monetary transactions between transaction system subscribers and other entities.”
`
`Ex. 1001, 1:36-39. A mobile device of a subscriber is “configured to run a monetary
`
`transaction system application.” Id., 1:41-44. “The subscriber indicates, via the
`
`monetary transaction system application, one or more specified transactions that are
`
`to be performed using the monetary transaction system.” Id., 1:44-47. The monetary
`
`transaction system may be used for many different tasks, including “depositing funds
`
`in a mobile wallet, withdrawing funds from a mobile wallet, ... [and] transferring
`
`funds through a mobile wallet.” Id., 1:62-2:4.
`
`The ’386 Patent provides examples of monetary transactions that the
`
`subscriber may initiate using the application on the subscriber’s mobile device
`
`utilizing an agent branch. The ’386 Patent refers to one such transaction as a “cash-
`
`in,” which corresponds to a deposit transaction:
`
`Mobile wallet platform subscribers can deposit cash into their
`mobile wallet account through a process referred to herein as ‘cash-in’.
`The cash-in process is supported by mFS agents at agent branch
`locations. The agent accepts the cash from the subscriber and transfers
`the equivalent amount of eMoney to the subscriber’s mobile wallet
`account. Id., 10:27-34 (emphasis added).
`
`
`
`
`
`3
`
`

`

`Figure 14 discloses the cash-in deposit transaction, where a subscriber utilizes
`
`an agent branch to deposit cash into an account associated with the subscriber’s
`
`mobile wallet. Ex. 2009, ¶61.
`
`The ’386 Patent describes the cash deposit transaction of Figure 14 as follows:
`
`
`
`To deposit cash onto the mobile wallet, the subscriber informs
`the agent that they want to deposit a specified amount of cash (1401).
`The agent takes the cash and notifies the monetary transaction system
`210 of the deposit using their point of sale (POS) system or the agent
`mobile wallet application (1402), and the monetary transaction system
`210 credits the subscriber’s mobile wallet account (1403). ...
`
`In one embodiment, the monetary transaction system 210 is
`implemented to deposit funds into a bank or credit union account using
`
`* * *
`
`
`
`4
`
`

`

`a mobile wallet. The communications module 215 of the monetary
`transaction system 210 receives communication from an agent branch
`over a communication channel (step 1410). The agent communication
`indicates that a subscriber 205 desires to deposit a specified amount of
`funds into a bank or credit union account. The transaction processor
`216 validates the status of the bank or credit union account (step 1420),
`determines if the agent branch is authorized to deposit money (step
`1430), and performs a limit check and/or a velocity check on the bank
`or credit union account (step 1440). The monetary transaction system
`then credits the bank or credit union account with the specified amount
`of funds (step 1450), returns a notification to the agent branch
`confirming the deposit (step 1460) and notifies the subscriber that the
`specified amount of funds was deposited in the bank or credit union
`account using at least one of the communication channels connected to
`the monetary transaction system (step 1470). Accordingly, cash may be
`deposited into a bank or credit union account associated with a
`subscriber’s mobile wallet. Id., 23:55-24:36 (emphasis added).
`
`The ’386 Patent refers to an analogous withdrawal transaction as a “cash-out”:
`
`Mobile wallet platform subscribers can withdraw cash from their
`mobile wallet account through a process known as “cash-out”. The
`cash-out process is supported by mFS agents at agent branch locations.
`The subscriber transfers eMoney from their mobile wallet account to
`the agent’s eMoney account. Upon receiving the eMoney, the agent
`gives the subscriber cash from their branch cash register. Id., 10:37-44
`(emphasis added).
`
`While it may seem basic, the ’386 Patent makes clear that, in a withdrawal
`
`transaction where a subscriber is withdrawing funds from the subscriber’s account,
`
`the resulting funds are given to the subscriber (rather than some other party). Fig. 16
`
`discloses the cash-out withdrawal transaction, where a subscriber utilizes an agent
`
`branch to withdraw cash from an account associated with the subscriber’s mobile
`
`wallet. Ex. 2009, ¶63.
`
`
`
`5
`
`

`

`The ’386 Patent describes the cash withdrawal transaction of Figure 16 as
`
`
`
`follows:
`
`FIG. 16 illustrates a subscriber withdrawal at an agent branch.
`To withdraw cash at an agent branch from a (prepaid) debit card, a
`subscriber submits a withdrawal request using the mobile wallet
`application on their mobile device. ... If the subscriber has sufficient
`funds, the monetary transaction system 210 will decrement the
`subscriber’s funds from their card (1601) and transfer it to the mobile
`wallet owner’s account within the same card processor or bank. The
`agent branch (1602) then provides the withdrawn cash to the subscriber
`(1603).
`
`Accordingly, the subscriber requests a cash withdrawal from
`their own mobile wallet account via the mobile wallet application. The
`agent or agent manager verifies the withdrawal request via POS
`authorization or SMS received on agent’s phone and, once verified,
`gives cash to the subscriber. ...
`
`In one embodiment, the monetary transaction system 210 is
`implemented to withdraw funds from a bank or credit union account
`using a mobile wallet. The communication module 215 of the monetary
`
`
`
`6
`
`

`

`transaction system 210 receives a communication from a subscriber
`205 over a communication channel 111 (step 1610). The subscriber
`communication indicates that subscriber 205 desires to withdraw a
`specified amount of funds from a bank or credit union account. The
`transaction processor validates the status of the bank or credit union
`account (step 1620), determines if the balance of the bank or credit
`union account is sufficient to accommodate the requested withdrawal
`for the specified amount of funds (step 1630) and performs a limit
`check and/or a velocity check on the bank or credit union account (step
`1640).
`
`The monetary transaction system 210 then returns a secure,
`perishable withdrawal code to the subscriber 205 over at least one of
`the communication channels (step 1650) and receives a subsequent
`agent branch communication indicating that the withdrawal code has
`been presented to an agent (step 1660). The monetary transaction
`system 210 then debits the bank or credit union account by the specified
`amount of funds (step 1670), returns a notification to the agent branch
`confirming the withdrawal (1680) and notifies the subscriber that the
`specified amount of funds were withdrawn from the bank or credit
`union account using at least one of the communication channels
`connected to the monetary transaction system (step 1690). Accordingly,
`a subscriber can withdraw cash stored on their mobile wallet from an
`agent branch or a non-agent branch. Id., 24:62-25:51 (emphasis added).
`
`As is plainly evident, in the withdrawal transaction, the funds being withdrawn
`
`go to the party withdrawing the funds – rather than to an unrelated party. Ex. 2009,
`
`¶63.
`
`B. Architecture Of Monetary Transaction System
`
`Figure 1 of the ’386 Patent illustrates the architecture of the monetary
`
`transaction system, which includes, inter alia, an integration tier 101, notification
`
`services 102, service connectors 103, business process services 104, payment
`
`handler 105, database 108 and rules engine 109.
`
`
`
`7
`
`

`

`
`
`As of the priority date, a person of ordinary skill in the art (POSITA) would
`
`have understood that the components shown in Figure 1 (e.g., integration tier 101,
`
`notification services 102, service connectors 103, business process services 104,
`
`payment handler 105, database 108 and rules engine 109) corresponded to a distinct
`
`computer process. Ex. 2009, ¶59. The POSITA would have also understood that
`
`direct communication between such computer processes would have been possible
`
`only for processes that are shown as having a direct connection. For example,
`
`integration tier 101 can communicate directly with business process services 104
`
`because the two are directly connected. But integration tier 101 lacks the ability to
`
`communicate directly with rules engine 109. Ex. 2009, ¶59.
`
`
`
`8
`
`

`

`C.
`
`Staged Commitment Process Used By The Monetary Transaction
`System
`
`The ’386 Patent contemplates a staged commitment process, where the
`
`transaction is sequentially committed through various layers of the monetary
`
`transaction system during the processing of the transaction. As different aspects of
`
`the transaction are performed by different tiers or processes, the Patent discloses
`
`committing aspects of the transaction in stages. Ex. 2009, ¶¶40, 77-83.
`
`Figure 20B of the ’386 Patent shows portions of the staged transaction
`
`commitment process implemented through the architecture of Fig. 1. The color
`
`boxes were added by Patent Owner.
`
`The blue box indicates the transaction being committed through the integration tier,
`
`the red box indicates the transaction being committed through the application tier,
`
`and green box indicates the commitment of the transaction through the business
`
`
`
`
`
`9
`
`

`

`process services. Ex. 2009, ¶81. A POSITA would have understood each of these
`
`stages involves a “commitment.” Specifically, a POSITA would have understood
`
`“commitment” to be the act of saving data permanently after a tentative set of
`
`changes, rather than rolling back the changes. Ex. 2009, ¶¶39-43 (citing, Distributed
`
`Transaction Processing: Reference Model, Version 3 (Ex. 2010) and Technical
`
`Standard “Data Management: Structured Query Language (SQL) Version 2” (1996)
`
`at 28 (Ex. 2017)) and ¶81.
`
`If a given stage of processing fails to result in a “commit,” the tentative
`
`changes to the resource made during the stage are “rolled back.” The purple boxes
`
`added by Patent Owner to Figures 20C and 20E illustrate examples of such rollbacks.
`
`Ex. 2009, ¶82.
`
`
`
`
`
`10
`
`
`
`

`

`
`
`A further example of the stage transaction commitment process of
`
`the ’386 Patent is shown in Figure 21D (commit through integration tier, application
`
`tier, and business process services); Figure 21E-I (rollbacks); Figure 22C (commit
`
`through integration tier, application tier, and business process services); 22F, G, I
`
`and J (rollbacks). Ex. 2009, ¶83.
`
`D. Details Of Business Process Services Component
`
`Business process services component 104 is centrally positioned within the
`
`architecture of the monetary transaction system. The ’386 Patent explains that
`
`business process services 104 “are configured to implement business workflows,
`
`including executing financial transactions, auditing financial transactions, invoking
`
`third-party services, handling errors, and logging platform objects.” Ex. 1001, 13:
`
`25-29. Being “configured to” perform each of these functions means that the
`
`
`
`11
`
`

`

`business process services component 104 is “programmed to” perform such
`
`functions.1
`
`In the context of the ’386 Patent, “auditing financial transactions” means
`
`performing retrospective inspection and verification of financial transactions.
`
`Ex. 2009, ¶¶46-48 (citing, definition of auditing from Auditing: Principles and
`
`Techniques, Pearson Education, 2006 (Ex. 2011)). Auditing financial transactions
`
`commonly involves determining if transactions were properly entered into, and the
`
`sampling and cross-checking of records. Ex. 2009, ¶46.
`
`“Error handling” in the context of database systems (like that of
`
`the ’386 Patent) refers to procedures for responding to and recovering from errors.
`
`The rollback processes discussed above in connection with, e.g., Figures 20C and
`
`20E, are examples of “error handling.” Ex. 2009, ¶49 (citing, definition of error
`
`handling from Kingsley-Hughes, Adrian, et al., VBScript Programmer’s Reference,
`
`United Kingdom, Wiley, 2007 (Ex. 2012)) and ¶¶50-52.
`
`“Logging” platform objects in the context of the ’386 Patent means storing or
`
`recording platform objects in a log. Logging is commonly used in connection with
`
`error handling, where an error is logged to a database or file. Ex. 2009, ¶¶53-56
`
`(citing, the definition of logging from Concise Oxford English Dictionary: Luxury
`
`
`1 Nevro Corp. v. Boston Sci. Corp., 955 F.3d 35 (Fed. Cir. 2020) (“we construe
`‘configured to’ to mean ‘programmed to.’“)
`
`
`
`12
`
`

`

`Edition, United Kingdom, OUP Oxford, 2011 (Ex. 2013 – definition of logging), and
`
`(Ex. 2012, describing the logging of errors in a database or file)).
`
`E.
`
`The Claims Of The ’386 Patent
`
`Claim 1 of the ’386 Patent recites a monetary transaction system that performs
`
`a deposit transaction, where a subscriber utilizes an agent branch to deposit funds
`
`into the subscriber’s account using the subscriber’s mobile wallet application. An
`
`example of such a transaction was discussed above in connection with Figure 14 of
`
`the ’386 Patent. In the pertinent part, Claim 1 recites:
`
`an integration tier operable to manage mobile wallet sessions, the
`integration tier also including a communication application
`programming
`interface
`(API) and other communication
`mechanisms to accept messages from channels; ...
`business process services operable to implement business workflows,
`including at least one of executing financial transactions,
`auditing financial transactions, invoking third-party services,
`handling errors, and logging platform objects; ...
`wherein the monetary transaction system is implemented to deposit
`funds at an agent branch, the funds being deposited by a
`subscriber at the agent branch using a mobile device configured
`to run a monetary transaction system application, the monetary
`transaction system performing the following steps:
`receiving a communication message from the mobile device ...
`the communication message indicating that the
`subscriber desires to deposit a specified amount of funds
`into the subscriber’s account;
`validating the status of the subscriber’s account, wherein
`validating the status of the subscriber’s account
`comprises communicating from the integration tier
`to the database services to query attributes of the
`subscriber’s account;
`committing a pending transaction through the business
`process services, wherein the integration tier
`
`
`
`13
`
`

`

`communicates a transaction commitment request
`to the business process services;
`receiving a confirmation from the business process
`services that the pending transaction has been
`committed;
`sending, through the notification services, a receipt
`notification to the mobile device; and
`upon receiving a confirmation of commitment from the
`business process services, committing the pending
`transaction to the database services:
`
`
`
`
`loading the funds to the subscriber account using the payment
`handler ...
`
`
`Several aspects of Claim 1 are worthy of mention. First, Claim 1 recites that
`
`the subscriber deposits funds into the subscriber’s account. Second, Claim 1 recites
`
`a staged commitment process, where the financial transaction is committed through
`
`the integration tier and business process services, and then subsequently to the
`
`database services. Finally, Claim 1 recites that the business process services
`
`implement, inter alia, a financial transaction auditing function, an error handling
`
`function, and a function that logs platform objects.
`
`Claim 2 is analogous to Claim 1, reciting a monetary transaction system that
`
`performs a cash withdrawal transaction, where a subscriber utilizes an agent branch
`
`to withdrawal funds from the subscriber’s account using the subscriber’s mobile
`
`wallet application. Ex. 1001, 32:52-53, 60-63. An example of such a transaction was
`
`discussed above in connection with Figure 16 of the ’386 Patent. Claim 3 is
`
`
`
`14
`
`

`

`analogous to the previous claims, reciting a monetary transaction system that
`
`transfers funds from a subscriber to a recipient. Id., 34:24-25.
`
`Like Claim 1, Claims 2 and 3 each recite a staged commitment process, where
`
`the transaction is committed through the integration tier and business process
`
`services, and then subsequently to the database services. Id., 33:4-16; 34:31-42.
`
`Claims 2 and 3 also each recite that the business process services implement, inter
`
`alia, a financial transaction auditing function, an error handling function, and a
`
`function that logs platform objects. Id., 32:19-21 and 33:49-51.
`
`IV. CLAIM CONSTRUCTION
`
`In IPR proceedings, claims must be construed under Phillips v. AWH Corp.,
`
`415 F.3d 1303, 1312 (Fed. Cir. 2005). “The construction that stays true to the claim
`
`language and most naturally aligns with the patent’s description of the invention will
`
`be, in the end, the correct construction.” Renishaw Pub. Ltd. Co. v. Marposs Societa’
`
`Per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998).
`
`The totality of the claim construction analysis in the Petition is set forth below:
`
`Petitioner submits that no claim term requires construction
`beyond its ordinary and customary meaning. A POSITA would apply
`the ordinary and customary meaning to all terms in the Challenged
`Claims. (Pet., at 5).
`
`Significantly, the Petition fails to articulate the specifics of the “ordinary and
`
`customary meaning” to be ascribed to any claim terms. Absent proposing a specific
`
`definition articulating the ordinary and customary meaning to be ascribed to a claim
`
`
`
`15
`
`

`

`term, simply submitting that “no claim term requires construction beyond its
`
`ordinary and customary meaning” does little to establish the metes and bounds of
`
`the claim term. Where the meanings of terms are potentially subject to dispute, it is
`
`incumbent that the Petition set forth its construction of the metes and bounds of each
`
`such term. Here, the Petition failed to meet its burden to set forth the required claim
`
`construction analysis. See, e.g., 37 C.F.R. § 42.108(c).
`
`Specifically, a POSITA upon reading the ’386 Patent would understand the
`
`following terms to have specific meanings.
`
`A.
`
`“Committing” A Pending Transaction
`
`Claim Term
`“committing” a pending transaction
`(Claims 1-3)
`
`Patent Owner’s Proposed Construction
`saving data permanently after a set of
`tentative changes, rather than rolling
`back the tentative changes
`
`
`
`“Committing” is a concept from the database art. It does not refer to
`
`performing an act (as, “committing a murder”) and does not refer to entering into a
`
`legal commitment (as in a contract). It refers instead to finalizing data so that it can
`
`be saved permanently. Ex. 2009, ¶39. The ’386 Patent discloses the performance
`
`of financial transactions using Distributed Transaction Processing. As explained in
`
`“Distributed Transaction Processing: Reference Model, Version 3” (Ex. 2010):
`
`Distributed transaction processing provides the necessary
`mechanism to combine multiple software components into a
`cooperating unit that can maintain shared data, potentially
`spanning multiple physical processors or locations, or both. This
`enables construction of applications that manipulate data
`
`
`
`16
`
`

`

`consistently using multiple products, that can easily incorporate
`additional components, and that can be scaled by adding
`additional hardware and software components. Ex. 2010, 1.
`
`In distributed systems (like those of the ’386 Patent), different portions of a
`
`financial transaction are performed on different computers (“distributed”), and so
`
`are decomposed into individual “units of work,” each of which in the distributed
`
`system art is also referred to as a “transaction.” Ex. 2009, ¶40. More specifically,
`
`A transaction is a complete unit of work which, in general
`terms, can apply
`to many contexts. It may comprise many
`computational tasks including user interfaces, data retrieval and
`communications. A typical transaction modifies resources. The model
`described in the referenced OSI TP standards defines the term
`transaction more precisely. Ex. 2010, 3 (emphasis in original).
`
`In Distributed Transaction Processing, a transaction has the following
`
`properties that are often referred to by the acronym ACID:
`
`Atomicity
`
`The results of the transaction’s execution are
`either all committed or all rolled back.
`
`Consistency A completed transaction transforms a shared
`resource from one valid state to another valid
`state.
`
`Isolation
`
`Changes to shared resources that a transaction
`effects do not become visible outside the
`transaction until the transaction commits.
`
`Durability
`
`transaction
`from
`result
`that
`The changes
`commitment survive subsequent system or media
`failures. Ex. 2010, 3 (emphasis in original).
`
`
`
`17
`
`

`

`Ex. 2009, ¶40. In the ACID framework, each unit of work is completed when it is
`
`either “committed” or rolled back. As explained in the “Distributed Transaction
`
`Processing: Reference Model, Version 3”:
`
`Commitment
`
`Commitment is the act that ends a transaction and makes
`permanent all changes to resources specified during that
`