throbber
Trials@uspto.gov
`571–272–7822
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Paper 8
`
`
` Entered: September 4, 2014
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`MASTERCARD INTERNATIONAL INCORPORATED,
`Petitioner,
`
`v.
`
`JOHN D’AGOSTINO,
`Patent Owner.
`
`
`Case IPR2014–00543
`Patent 8,036,988
`
`
`
`Before SALLY C. MEDLEY, KARL D. EASTHOM, and
`KALYAN K. DESHPANDE, Administrative Patent Judges.
`
`DESHPANDE, Administrative Patent Judge.
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`
`I.
`INTRODUCTION
`MasterCard International Incorporated (“Petitioner”) filed a corrected
`Petition requesting an inter partes review of claims 1–38 of
`U.S. Patent No. 8,036,988 (Ex. 1001, “the ’988 patent”). Paper 1 (“Pet.”).
`John D’Agostino (“Patent Owner”) timely filed a Preliminary Response. Paper 7
`(“Prelim. Resp.”). We have jurisdiction under 35 U.S.C. § 314, which provides
`that an inter partes review may not be instituted “unless . . . there is a reasonable
`likelihood that petitioner would prevail with respect to at least 1 of the claims
`challenged in the petition.” 35 U.S.C. § 314.
`Upon consideration of the Petition and the Preliminary Response, we
`determine that Petitioner has established that there is a reasonable likelihood that
`Petitioner would prevail in showing the unpatentability of claims 1–38 of the ’988
`patent. Accordingly, we institute an inter partes review of these claims.
`A. Related Proceedings
`Petitioner identifies the following related district court proceeding involving
`the ’988 Patent and in which Petitioner is a party: D’Agostino v. MasterCard, Inc.,
`Case No. 1:13–cv–00738 (D. Del. filed Apr. 26, 2013). Pet. 59.
`Petitioner also identifies the ’988 patent as the subject of Ex Parte
`Reexamination proceeding No. 90/012,517. Pet. 1, 59.
`In related proceeding IPR2014–00544, Petitioner seeks review of U.S.
`Patent No. 7,840,486 B2, to which the ’988 patent claims priority. Pet. 59.
`Petitioner previously sought a covered business method patent review of the ’988
`patent in proceeding CBM2013–00057, but we denied institution of review. Id. at
`11–13; Mastercard Int’l Inc. v. D’Agostino, case CBM2013–00057 (PTAB Mar. 7,
`2014)(Paper 9). Specifically, we had denied institution of review because
`Petitioner had not demonstrated that Cohen or Flitcroft qualifies as prior art under
`
`
`
`2
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`Section 18(a)(1)(C) of the AIA, because neither Cohen nor Flitcroft was published
`prior to the effective filing date of the ’988 patent. Mastercard Int’l Inc. v.
`D’Agostino, case CBM2013–00057, slip op. at 13-14 (PTAB Mar. 7, 2014).
`B. The ’988 Patent
`The ’988 patent discloses a method and system of performing secure credit
`card purchases. Ex. 1001, Abstract. The method and system increase overall
`security by minimizing access to credit card numbers, without having to
`substantially deviate from existing credit card transaction practices. Id. at 1:19–29.
`Figure 3 of the ’988 patent is reproduced below:
`
`
`Figure 3, depicted above, schematically represents a secure credit card
`transaction system, where the customer–to–merchant contact is by phone or in
`person. As shown above in Figure 3, customer 54 receives promotional
`information from merchant 56, either by telephone 60 or in person 62. Ex. 1001,
`7:30–35. Customer 54 then contacts custodial authorizing entity 64, by either
`telephone 66’ or computer 45’, for authorization. Id. at 7:35–43. After confirming
`
`
`
`3
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`authorization, authorizing entity 64 establishes details of the anticipated transaction
`to determine a payment category, and then issues a transaction code to the
`customer. Id. at 7:43–46. The customer can utilize the transaction code to
`consummate a transaction within the defined parameters of the payment category,
`and the merchant can obtain verification and subsequent payment utilizing the
`transaction code only. Id. at 7:46–55.
`C. Illustrative Claims
`Petitioner challenges claims 1–38 of the ’988 patent. Pet. 13–59. Claims 1
`and 21 are illustrative of the claims at issue and are reproduced below:
`1.
`A method of performing secure credit card purchases, said
`method comprising:
`a) contacting a custodial authorizing entity having custodial
`responsibility of account parameters of a customer’s account that is
`used to make credit card purchases;
`b) supplying said custodial authorizing entity with at least
`account identification data of said customer’s account;
`c) defining at least one payment category to include at least
`limiting a number of transactions to one or more merchants, said one
`or more merchants limitation being included in said payment category
`prior to any particular merchant being identified as one of said one or
`more merchants;
`d) designating said payment category;
`e) generating a transaction code by a processing computer of
`said custodial authorizing entity, said transaction code reflecting at
`least the limits of said designated payment category to make a
`purchase within said designated payment category;
`f) communicating said transaction code to a merchant to
`consummate a purchase with defined purchase parameters;
`g) verifying that said defined purchase parameters are within
`said designated payment category; and
`h) providing authorization for said purchase so as to confirm at
`least that said defined purchase parameters are within said designated
`payment category and to authorize payment required to complete the
`purchase.
`
`
`
`4
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`
`
`21. A method for implementing a system for performing secure
`credit card purchases, the method comprising:
`a) receiving account information from an account holder
`identifying an account that is used to make credit card purchases;
`b) receiving a request from said account holder for a transaction
`code to make a purchase within a payment category that at least limits
`transactions to a single merchant, said single merchant limitation
`being included in said payment category prior to any particular
`merchant being identified as said single merchant;
`c) generating a transaction code utilizing a processing computer
`of a custodial authorizing entity, said transaction code associated with
`said account and reflecting at least the limits of said payment
`category, to make a purchase within said payment category;
`d) communicating said transaction code to said account holder;
`e) receiving a request to authorize payment for a purchase using
`said transaction code;
`f) authorizing payment for said purchase if said purchase is
`within said payment category.
`
`D. The Alleged Grounds of Unpatentability
`The information presented in the Petition sets forth proposed grounds of
`unpatentability of claims 1–38 of the ’988 patent under 35 U.S.C. §§ 102, 103 as
`follows (see Pet. 13–59):
`
`Reference(s)
`
`Basis
`
`Challenged Claims
`
`Cohen1
`Cohen and
`Musmanno2
`Flitcroft3
`
`§ 102(e)
`
`§ 103
`
`§ 102(e)
`
`1–10, 15–25, 27–33,
`and 35–38
`11–14, 26, and 34
`1–10, 15–25, 27–33,
`and 35–38
`
`
`1 U.S. Patent No. 6,422,462 B1 (Ex. 1004) (“Cohen”).
`2 U.S. Patent No. 5,826,243 (Ex. 1006) (“Musmanno”).
`3 U.S. Patent No. 6,636,833 B1 (Ex. 1005) (“Flitcroft”).
`5
`
`
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`
`Reference(s)
`
`Basis
`
`Challenged Claims
`
`Flitcroft and
`Musmanno
`
`§ 103
`
`11–14, 26, and 34
`
`Cohen
`
`Flitcroft
`
`§ 103
`
`§ 103
`
`1–10, 15–25, 27–33,
`and 35–38
`1–10, 15–25, 27–33,
`and 35–38
`II. ANALYSIS
`A. Claim Construction
`In an inter partes review, claim terms in an unexpired patent are interpreted
`according to their broadest reasonable construction in light of the specification of
`the patent in which they appear. 37 C.F.R. § 42.100(b); Office Patent Trial
`Practice Guide, 77 Fed. Reg. 48,756, 48,764–66 (Aug. 14, 2012). Claim terms are
`given their ordinary and customary meaning, as would be understood by one of
`ordinary skill in the art in the context of the entire disclosure. In re Translogic
`Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). A claim term will not be given
`its ordinary and customary meaning, however, when an inventor acts as his or her
`own lexicographer, defining the term in the specification with reasonable clarity,
`deliberateness, and precision. Renishaw PLC v. Marposs Societa’ per Azioni, 158
`F.3d 1243, 1249 (Fed. Cir. 1998).
`1.
`“generating a transaction code”
`Independent claims 1, 17, 19, 21, and 22 recite “generating a transaction
`code.” Petitioner proposes this limitation means “creating a code usable as a
`substitute for a credit card number in a purchase transaction, the number pre–coded
`to be indicative of a specific credit card account.” Pet. 13 (citation omitted).
`Patent Owner proposes the limitation means “producing a code that is usable in
`substitution for a credit card number in a purchase transaction, the code being
`
`
`
`6
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`indicative of a customer account and a payment category.” Prelim. Resp. 4–5.
`The ’988 patent specification discloses that “the transaction code is pre–coded to
`be indicative of a specific credit card account.” Ex. 1001, 6:32–37. The ’988
`patent, however, does not define specifically “generating a transaction code” to be
`indicative of a payment category, as argued by Patent Owner; rather, the
`specification explicitly states that a designated payment category is preferable. See
`Prelim. Resp. 4–5; Ex. 1001, 6:29–30. Accordingly, we construe “generating a
`transaction code,” under the broadest reasonable construction, to mean “creating
`[or producing] a code [that is] usable as a substitute for a credit card number in a
`purchase transaction, the [transaction code is] pre–coded to be indicative of a
`specific credit card account,” as argued by both Petitioner and Patent Owner. Pet.
`13 (citation omitted).
`2.
`“defining at least one payment category”
`Independent claim 1 recites “defining at least one payment category.”
`Claim 1 further recites the payment category includes “limiting a number of
`transactions to one or more merchants” and “said one or more merchants limitation
`being included in said payment category prior to any particular merchant being
`identified as one of said one or more merchants.” Independent claims 17, 19, 21,
`and 22 recite similar limitations. Petitioner argues that “defining at least one
`payment category” means “‘specifying the type of limitation (or limitations) that
`are available to be applied to a transaction code in order to limit its use.’” Pet. 13–
`14 (citation omitted). Patent Owner does not propose a definition for this
`limitation.
`Although the ’988 patent provides several examples of types of payment
`categories, the ’988 patent does not define specifically “defining at least one
`payment category.” For example, the ’988 patent describes that payment
`
`
`
`7
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`categories include “a single transaction involving a specific dollar amount for a
`purchase within a specific time period” or “a single transaction . . . [with] a
`maximum limit or a dollar amount.” Ex. 1001, 3:56–61. Accordingly, under the
`broadest reasonable interpretation, we agree with Petitioner that this limitation
`means “specifying the type of limitation (or limitations) that are available to be
`applied to a transaction code in order to limit its use.” Pet. 13–14 (citation
`omitted).
`
`3.
`“one or more merchants” and “a number of transactions”
`Independent claim 1 recites “one or more merchants” and “a number of
`transactions.” Independent claims 17, 19, 21, and 22 recite similar limitations. In
`CBM2013–00057, we previously construed these limitations of the ’988 patent to
`mean “one or more transactions, where the number of transactions is limited to a
`finite number” and “one merchant up to a plurality of merchants, where the
`number of merchants is a finite number,” respectively. Mastercard Int’l Inc. v.
`D’Agostino, Case CBM2013-00057, slip op. at 8–9 (PTAB March 7, 2014).
`Petitioner and Patent Owner accept these constructions, and we maintain these
`constructions for this case. Pet. 14; Prelim. Resp. 6–7.
`4. “one or more merchants limitation being included in said payment category
`prior to any particular merchant being identified as one of said one or more
`merchants” and “single merchant limitation being included in said payment
`category prior to any particular merchant being identified as a single merchant”
`Independent claims 1, 17, 19, and 22 recite “one or more merchants
`limitation being included in said payment category prior to any particular merchant
`being identified as one of said one or more merchants.” Independent claim 21
`similarly recites “single merchant limitation being included in said payment
`category prior to any particular merchant being identified as a single merchant.”
`Petitioner proposes “prior to any particular merchant being identified,” as recited
`
`
`
`8
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`in each of these limitations, means “‘prior to the identification of a particular
`merchant for the particular transaction(s) or purchase(s) in said payment
`category.’” Pet. 14. Patent Owner argues that “said one or more merchants
`limitation being included in said payment category prior to any particular merchant
`being identified as one of said one or more merchants” and “single merchant
`limitation being included in said payment category prior to any particular merchant
`being identified as a single merchant” mean “including a limit in a payment
`category that limits transactions to one or more merchants before any particular
`merchant is identified as the one or more merchants.” Prelim. Resp. 5–6.
`The ’988 patent describes that a merchant or merchants can be identified
`prior to the generation of the transaction code, such that the transaction code is
`pre–coded with the merchant’s or merchants’ identification. Ex. 1001, 6:31–37.
`Subsequently, a customer can disclose the transaction code to a merchant or
`merchants. Id. at 6:63–67. We interpret the merchant to whom the customer
`discloses the transaction code as the recited “particular merchant.” In other words,
`the merchant with whom the customer is transacting is the particular merchant.
`We further interpret, under the broadest reasonable interpretation, the “one or more
`merchants limitation” and the “single merchant limitation” to mean any group,
`category, or type of merchant, where the “particular merchant” is a subset of the
`“one or more merchants limitation” or the “single merchant limitation.” As such,
`the limitation “one or more merchants limitation being included in said payment
`category prior to any particular merchant being identified as one of said one or
`more merchants” and “single merchant limitation being included in said payment
`category prior to any particular merchant being identified as a single merchant”
`means any group, category, or type of merchant is included in the payment
`category prior to the customer selecting a particular merchant for a transaction.
`
`
`
`9
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`These two limitations, however, are distinguished from each other because the
`“one or more merchants” allows for one or multiple merchants as any group,
`category, or type of merchant, whereas “single merchant” allows for only one
`merchant. Prelim. Resp. 5–6.
`B. Claims 1–10, 15–25, 27–33, and 35–38 – Anticipation by Cohen
`Petitioner contends that claims 1–10, 15–25, 27–33, and 35–38 are
`unpatentable under 35 U.S.C. § 102(e) as anticipated by Cohen. Pet. 15–31.
`1. Cohen (Ex. 1004)
`Cohen describes a system of disposable credit card numbers, where the
`credit card numbers are generated for a one–time, single transaction basis, after
`which they are disposed of, or thrown away. Ex. 1004, 2:34–37. In general, a user
`dials into her credit card company and provides the ordinary credit card number
`and verification data, and may further indicate the transaction for which the
`customized credit card number will be used. Id. at 3:41–53. The user then is
`provided with a disposable or customized credit card number for a single or limited
`range use. Id.
`For example, an employee’s credit card may be authorized to purchase a
`computer system, thereby transforming the credit card to a customized credit card
`that is valid for only that particular type of purchase. Id. at 8:24–35. The card also
`can be customized for use in a particular store or a particular chain of stores. Id.
`2. Analysis
`The evidence set forth by Petitioner indicates there is a reasonable likelihood
`that Petitioner would prevail in showing that claims 1–10, 15–25, 27–33, and 35–
`38 are unpatentable under 35 U.S.C. § 102(e) as anticipated by Cohen. Pet. 15–32.
`For example, independent claim 1 recites a “method of performing secure credit
`card purchases.” Petitioner argues that Cohen discloses “provid[ing] improved
`
`
`
`10
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`credit cards and methods for credit card transactions . . . provid[ing] methods and
`apparatus for secure transmission of credit card information.” Pet. 16 (quoting Ex.
`1004, 1:48–62). Claim 1 further recites the following:
`a) contacting a custodial authorizing entity having custodial
`responsibility of account parameters of a customer’s account that is
`used to make credit card purchases;
`b) supplying said custodial authorizing entity with at least account
`identification data of said customer’s account; . . .
`d) designating said payment category;
`e) generating a transaction code by a processing computer of said
`custodial authorizing entity, said transaction code reflecting at least
`the limits of said designated payment category to make a purchase
`within said designated payment category.
`Petitioner argues that Cohen describes that after an account holder contacts her
`credit card company that verifies her identity, the account holder is provided with a
`transaction code number to be used for a single or limited range of transactions,
`where the transactions can be indicated in advance of receiving the transaction
`code number. Pet. 16–18 (citing Ex. 1004, 2:35–43, 3:28–52, 8:25–46). Claim 1
`further recites:
`c) defining at least one payment category to include at least limiting a
`number of transactions to one or more merchants, said one or more
`merchants limitation being included in said payment category prior to
`any particular merchant being identified as one of said one or more
`merchants.
`Petitioner argues that Cohen discloses that “[t]he card can also be
`customized for particular uses or groups of uses” and further discloses that
`the card can be valid for a particular type of charge, such as computer
`hardware or software stores, or a particular store or a particular chain of
`stores. Pet.17 (citing Ex. 1004, 7:66–67, 8:25–46). Petitioner specifically
`argues that Cohen discloses that the card can be valid for only a particular
`chain of restaurants or a type of store, such as a clothing store. Id. Based on
`11
`
`
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`our construction of this limitation above, we are persuaded Petitioner has
`made a sufficient showing that Cohen describes this limitation. Claim 1 also
`recites:
`f) communicating said transaction code to a merchant to consummate
`a purchase with defined purchase parameters;
`g) verifying that said defined purchase parameters are within said
`designated payment category; and
`h) providing authorization for said purchase so as to confirm at least
`that said defined purchase parameters are within said designated
`payment category and to authorize payment required to complete the
`purchase.
`Petitioner argues Cohen discloses that a user communicates the disposable credit
`card number to a vendor, and the vendor verifies the transaction and obtains an
`authorization code from the credit card company authorizing the purchase. Id. at
`18–19 (citing Ex. 1004, 5:36–49). We are persuaded by Petitioner’s arguments.
`
`Patent Owner argues that the Petition impermissibly combines separate,
`distinct embodiments of Cohen to satisfy independent claim 21. Prelim. Resp. 19–
`22. Patent Owner specifically argues that these separate and distinct embodiments
`of Cohen are delineated by the phrases “[i]n one embodiment” and “[i]n
`accordance with the present invention, in one embodiment of the present
`invention.” Id. at 21. Patent Owner further argues that
`Mastercard relies on several custom-use credit card embodiments of
`Cohen to teach that a transaction code can be customized for certain
`uses. And then relies on separate single-use credit card of Cohen to
`allegedly show that a single-use credit card inherently teaches limiting
`a transaction code to a single merchant without first identifying the
`single merchant.
`
`Id.
`
`We are not persuaded by this argument. As discussed in the Petition,
`Cohen discloses a single-use credit card and Cohen further discloses that the
`
`
`
`12
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`credit card can be customized with other limits, including limiting use to a
`certain store or single merchant. Pet. 27 (citing Ex. 1004, 8:42–46). The
`Petition relies on Cohen’s disclosure of a “certain store” to describe a
`“single merchant.” See id. As such, Patent Owner’s argument does not
`rebut Petitioner’s challenge of unpatentability of claim 21. Furthermore,
`Patent Owner fails to specifically identify the “multiple distinct
`embodiments” relied upon by the Petition. Patent Owner only sets forth the
`conclusory argument that Cohen discloses “[i]n one embodiment” and “[i]n
`accordance with the present invention, in one embodiment of the present
`invention” without specifically identifying the distinct features of each
`embodiment and the Petition’s impermissible reliance on the combination of
`these embodiments. Accordingly, we are not persuaded by Patent Owner’s
`argument.
`
`In addition, Patent Owner argues that Cohen fails to disclose limiting
`“transactions to a single merchant, said single merchant limitation being included
`in said payment category prior to any particular merchant being identified as a
`single merchant,” as recited in claim 21. Prelim. Resp. 22–23 (citation and
`emphasis omitted). Patent Owner specifically argues that Cohen’s single-use
`credit card cannot be used for transactions with a single merchant because it is
`deactivated after its first use, and, therefore, is not being used for a plurality of
`transactions. Id.
`As discussed above in construing the claims, we construe the disputed
`limitation to mean any group, category, or type of merchant is included in the
`payment category prior to the customer selecting a particular merchant for a
`transaction. Cohen discloses that a card can be valid only at a certain store, groups
`of stores, or types of stores. Pet. 16–17; Ex. 1004, 8:42–46. Cohen discloses that
`
`
`
`13
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`the card can be valid for purchase on a particular day or for up to a designated
`purchase limit. Ex. 1004, 8:42–46. Although Cohen discloses a single-use credit
`card, Cohen further discloses a card that can be used at a certain store for a set
`amount or for a set time period. Accordingly, we are not persuaded by Patent
`Owner’s argument.
`
`Further, Patent Owner argues that Cohen fails to disclose
`“designating/selecting a payment category that places limitations on a transaction
`code before the transaction code is generated,” as recited in claims 1 and 17 and as
`similarly recited in independent claims 19, 21, and 22. Prelim. Resp. 23–26.
`Patent Owner specifically argues that Cohen describes customizing the use of a
`card after the number is generated, and, therefore, fails to disclose including
`limitations on the use of the transaction code before the step of generating the
`transaction code. Prelim. Resp. 25–26. We are not persuaded by this argument.
`Cohen discloses that “a user dials into her credit card company before making a
`transaction, and . . . is provided with a disposable or customized number.” Ex.
`1004, 3:42–49. Cohen further discloses that “a user can indicate in advance of
`purchase, on the telephone call with the credit card company, what the single use
`or the customized credit card number is to be used for.” Id. at 3:50–53.
`Accordingly, on this record, we are persuaded by Petitioner’s assertion that Cohen
`discloses “designating/selecting a payment category that places limitations on a
`transaction code before the transaction code is generated.”
`
`Patent Owner argues that Cohen fails to disclose “limiting use to one or
`more merchants before any particular merchant is identified as the one or more
`merchant,” as recited in claim 21. Prelim. Resp. 26–28. Patent Owner specifically
`argues that Petitioner relies on Cohen’s disclosure of a “type of charge, e.g.,
`customizing use of a credit card so that it can only be used for clothing [] or
`
`
`
`14
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`computer hardware or software stores” or limiting use to a particular chain of
`stores to describe “limiting use to one or more merchants,” where one or more
`merchants means “‘one merchant up to a plurality of merchants, where the number
`of merchants are a finite number.’” Prelim. Resp. 26–27 (quoting Pet. 17;
`Mastercard Int’l Inc. v. D’Agostino, Case CBM2013-00057, slip op. at 9 (PTAB
`March 7, 2014)). Patent Owner further argues that “[a]dmittedly limiting use to a
`particular chain of stores could be a limit to one or more merchants . . . .
`[; however,] limiting use to a particular chain certainly requires identification of a
`particular chain before the limit can be made.” Prelim. Resp. 27–28. We are not
`persuaded by this argument. As argued by Petitioner, and admitted by Patent
`Owner, Cohen discloses the card can be customized for use in a particular store or
`in a chain of stores, such as a particular restaurant or a particular chain of
`restaurants. Pet. at 17 (citing Ex. 1004, 7:66–67, 8:25–46); Prelim. Resp. 27–28.
`Although customizing the card such that it is used at a type of store or a chain of
`stores requires identification of the type or chain of stores, it does not require
`identification of the particular store. Rather, it designates one or more merchants
`for which the card can be used, and the user subsequently identifies a particular
`merchant. Accordingly, we are not persuaded by Patent Owner’s argument.
`C. Claims 11–16, 24, and 34 – Obviousness over Cohen and Musmanno
`Petitioner contends that claims 11–16, 24, and 34 are unpatentable under
`35 U.S.C. § 103 as obvious over Cohen and Musmanno. Pet. 32–36.
`1. Musmanno (Ex. 1006)
`Musmanno discloses a data processing method and apparatus for directing
`an account management system that incorporates master accounts with a plurality
`of nested subaccounts having a specific subset of individual properties. Ex. 1006,
`1:5–10. Each subaccount is directed to a specific goal, such as monthly household
`
`
`
`15
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`expenses, long–term investment strategies, and other financial goals. Id. at 3:5–9.
`Funds are deposited into the master account or into a specific subaccount. Id. at
`5:40–43. Upon request, the system will transfer funds from a specific account to a
`destination account. Id. at 5:47–49. Funds can be transferred on a periodic basis.
`Id. at 5:27–32. For example, as illustrated in Figure 3, funds can be transferred
`from Master Account 20 to Mortgage Subaccount 310, Car Subaccount 320, and
`Tuition Subaccount 330 every fourteen days and an automatic transfer of funds to
`Master Account 20 from Mortgage Subaccount 310 and Car Subaccount 320 on
`the twenty-eighth day of each month. Id. at 5:53–59.
`2. Analysis
`The evidence set forth by Petitioner indicates there is a reasonable likelihood
`that Petitioner would prevail in showing that claims 11–16, 24, and 34 are
`unpatentable under 35 U.S.C. § 103 as obvious over Cohen and Musmanno. Pet.
`32–36. For example, claim 11 recites the method of claim 1 and further recites:
`defining at least one payment category to include using said
`transaction code for at least two purchases for a repeating transaction
`at a fixed amount payable at each of a fixed number of time intervals.
`Petitioner argues that Cohen discloses claim 1, as discussed above, and
`further discloses that Cohen’s transaction code can be used repeatedly for a range
`of dates or a series of dates. Pet. 34 (citing Ex. 1004, 7:44–62). Petitioner further
`argues that Musmanno discloses that a predetermined amount from a master
`account is transferred to at least two subaccounts at a fixed time interval. Id.
`(citing Ex. 1006, 5:53–59). Petitioner also argues that applying the repeating
`transaction steps of Musmanno to the transaction code generation steps of Cohen
`would not change the respective functions of each step and such a combination
`would have yielded the predictable result of the ability to use Cohen’s transaction
`code for repeating transactions for a fixed amount at fixed intervals. Id. at 33–34
`
`
`
`16
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`(citing Ex. 1008 ¶ 69). Based on these arguments and the supporting evidence, we
`are persuaded that there is a reasonable likelihood Petitioner would prevail in
`demonstrating that claim 11 would have been obvious over Cohen and Musmanno.
`We are similarly persuaded that there is a reasonable likelihood Petitioner would
`prevail in demonstrating that claims 12–14, 26, and 34 would have been obvious
`over Cohen and Musmanno. Id. at 32-36.
`Patent Owner argues that the Petition does not identify the difference
`between the cited prior art and claims, and further does not articulate a rationale for
`why a person of ordinary skill in the art would have modified Cohen and
`Musmanno to meet the claims. Prelim. Resp. 28–32. Patent Owner specifically
`argues that Petitioner’s rationale only indicates that Cohen and Musmanno are
`analogous art and such a rationale is insufficient for a showing of obviousness.
`Prelim. Resp. 30. We are not persuaded by this argument. Petitioner argues that
`[b]oth references address methods for facilitating financial
`transactions. Cohen’s method for employing a transaction code that is
`limited in use to transactions at selected vendors is a specific example
`of facilitating secure financial transactions. Cohen at 2:32-43.
`Musmanno similarly addresses a system for managing financial
`business transactions and fund transfers between various accounts.
`Musmanno at 1:5-10. More specifically, Musmanno discloses the use
`of repeating transactions, paid over a fixed number of payment
`intervals, between accounts. Id. at 5:26-31. Applying the repeating
`transaction techniques of Musmanno to the transaction code methods
`of Cohen with no change in their respective functions would have
`yielded predicable results: the use of a transaction code for repeating
`transactions. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 416
`(2007) (“The combination of familiar elements according to known
`methods is likely to be obvious when it does no more than yield
`predictable results.”). Thus, these references in their similar purpose
`of dealing with financial transactions and services, and overlapping
`teachings, confirm a motivation to combine Cohen and Musmanno
`
`
`
`17
`
`

`

`Case IPR2014–00543
`Patent No. 8,036,988
`
`
`and, as demonstrated below, should render these claims invalid. See
`Exh. 1008, Grimes Dec. at ¶ 69.
`Pet. 33–34. Petitioner argues that Musmanno discloses the repeating transactions
`technique that Cohen does not disclose. Id. Petitioner further contends that the
`combination of Musmanno’s repeating transactions technique to Cohen’s
`transaction codes, without any change to their respective functions, would yield
`predictable results. Id. Therefore, Petitioner has set forth a sufficient rationale to
`modify Cohen and Musmanno and has not presented only arguments illustrating
`that Cohen and Musmanno are analogous.
`D. Claims 1–10, 15–25, 27–33, and 35–38 – Obviousness over Cohen or
`Flitcroft
`Petitioner also contends that claims 1–10, 15–25, 27–33, and 35–38 are
`unpat

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket