trials@uspto.gov
`571-272-7822
`
`
`
`
`
`
`
`IPR2014-00543, Paper No. 27
`IPR2014-00544, Paper No. 21
`June 4, 2015
`
`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)
`Case IPR2014-00544 (Patent 7,840,486)
`____________
`
`Held: May 12, 2015
`____________
`
`
`
`BEFORE SALLY C. MEDLEY, KARL D. EASTHOM, and
`KALYAN K. DESHPANDE, Administrative Patent Judges.
`
`
`
`
`The above-entitled matter came on for hearing on Tuesday, May 12,
`2015, commencing at 1:01 p.m., at the U.S. Patent and Trademark
`Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`
`
`
`571-272-7822
`
`
`
`
`
`
`
`IPR2014-00543, Paper No. 27
`IPR2014-00544, Paper No. 21
`June 4, 2015
`
`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)
`Case IPR2014-00544 (Patent 7,840,486)
`____________
`
`Held: May 12, 2015
`____________
`
`
`
`BEFORE SALLY C. MEDLEY, KARL D. EASTHOM, and
`KALYAN K. DESHPANDE, Administrative Patent Judges.
`
`
`
`
`The above-entitled matter came on for hearing on Tuesday, May 12,
`2015, commencing at 1:01 p.m., at the U.S. Patent and Trademark
`Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`ROBERT C. SCHEINFELD, ESQUIRE
`
`
`HENRY CHEN, ESQUIRE
`
`
`Baker Botts, L.L.P.
`
`
`30 Rockefeller Plaza
`
`
`New York, New York 10112-4498
`
`
`
`
`ON BEHALF OF PATENT OWNER:
`
`
`STEPHEN J. LEWELLYN, ESQUIRE
`
`
`WILLIAM R. BREES, ESQUIRE
`
`
`Maxey Law Offices, PLLC
`
`
`100 Second Avenue South
`
`
`Suite 401 North
`
`
`St. Petersburg, Florida 33701
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` 2
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`
`
`
`
`
`
`
`
` P R O C E E D I N G S
`
`- - - - -
`
`JUDGE DESHPANDE: Good afternoon, everyone. We're
`
`here for the hearing for IPR2014-00543 and IPR2014-00544,
`
`Mastercard v. John D'Agostino.
`
`I'm Judge Deshpande. To my right is Judge Medley. To my
`
`left is Judge Easthom. Let's have the parties' appearances. Who do
`
`we have for Petitioner?
`
`MR. SCHEINFELD: Robert Scheinfeld, Baker Botts.
`
`MR. CHEN: Henry Chen, Baker Botts.
`
`MR. LEWELLYN: Stephen Lewellyn for D'Agostino.
`
`MR. BREES: William Brees for D'Agostino.
`
`JUDGE DESHPANDE: Great. Thank you and welcome to
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`the Patent Trial and Appeal Board. We set forth the procedure for
`
`15
`
`today's hearing in our hearing order, but just to remind everybody,
`
`16
`
`each party will have 60 minutes to present arguments. You may
`
`17
`
`allocate your time per case as you see fit. Petitioner has the burden of
`
`18
`
`proof, so Petitioner will argue first. Petitioner may reserve rebuttal
`
`19
`
`time. Subsequently, Patent Owner may present arguments.
`
`20
`
`We remind each party that under no circumstances are they
`
`21
`
`to interrupt the other party. If you have objections, please state so
`
`22
`
`during your time to speak. I will keep track of time and I'll give
`
`23
`
`counselors' warning as they're approaching their time limit. Does
`
`24
`
`anyone have any questions about today's procedure?
`
`
`
`
`
` 3
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`
`MR. LEWELLYN: No, Your Honor.
`
`JUDGE DESHPANDE: Okay. Petitioner, you may present
`
`your arguments first.
`
`MR. SCHEINFELD: Good afternoon, Your Honors.
`
`MR. CHEN: If I could ask, could we get a little help on the
`
`audio-visual equipment? It should be set up.
`
`MR. SCHEINFELD: Sorry, Your Honor, would that be
`
`acceptable?
`
`JUDGE DESHPANDE: Sure.
`
`MR. SCHEINFELD: Thank you.
`
`MR. CHEN: I think it's working. It's just going to take a
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`second or two.
`
`13
`
`MR. SCHEINFELD: I'll proceed, if that's okay. I'd like to
`
`14
`
`reserve 20 minutes for rebuttal, if that's okay.
`
`15
`
`16
`
`JUDGE DESHPANDE: Okay.
`
`MR. SCHEINFELD: What I'd like to do first, Your Honor,
`
`17
`
`is to address a motion to exclude. Patent Owner submitted a
`
`18
`
`declaration of Edward Gussin that we believe should be excluded
`
`19
`
`from this proceeding under Rule 702 in the case law that covers expert
`
`20
`
`testimony.
`
`21
`
`We believe that Rule 702 in the Sundance case made clear
`
`22
`
`that an expert needs knowledge, expertise, skill, experience, training
`
`23
`
`in the pertinent art and here that's not the case, Your Honor. The
`
`24
`
`pertinent art is secure credit card -- credit cards and we don't believe
`
`25
`
`that Mr. Gussin has that particular experience. In fact, he has no
`
`
`
`
`
` 4
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`experience in the financial industry, no experience with credit cards or
`
`transaction codes or payment categories, no experience in the
`
`pertinent art and we believe that's required under Rule 702 in the case
`
`law.
`
`In fact, if you look at Gussin's declaration -- that would
`
`be -- I want to see if I could use this. This is Exhibit Number 2007,
`
`Your Honor, I'm about to show you, that I thought I was about to
`
`show you. It's not coming up.
`
`Regardless, I think I'll proceed and just say that, for
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`example, Mr. Gussin opines in paragraph 38 of his declaration that at
`
`11
`
`most merchant type limit creates an indeterminable numerical limit on
`
`12
`
`a number of merchants with a number greater than one and, similarly,
`
`13
`
`he opines in paragraph 50, Cohen's merchant type limitation, e.g.,
`
`14
`
`limitation to an entire industry of merchants does not fall within this
`
`15
`
`meaning because it does not create a limit to a reasonable, finite
`
`16
`
`number of merchants.
`
`17
`
`We believe that Mr. Gussin has no basis to make these
`
`18
`
`opinions, no basis to make any of the opinions that he sets forth in his
`
`19
`
`declaration because he lacks the fundamental expertise and experience
`
`20
`
`in the pertinent art and, therefore, his declaration should be excluded.
`
`21
`
`I'd like to proceed to claim construction. If you could just
`
`22
`
`show slide 24. There you go. Okay. If we could turn to slide 24. I'm
`
`23
`
`going to start with generating a transaction code in the next line.
`
`24
`
`We believe the Board's construction of this code in its
`
`25
`
`Institution Order was correct. Patent Owner argues that this term
`
`
`
`
`
` 5
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`needs to be indicative of not just a specific credit card number, but
`
`also a payment category. We believe that's incorrect. We believe the
`
`specification is clear that it could be either, that it's preferable, the
`
`specification at column 6, lines 33 to 37, which states, more
`
`specifically, the transaction code is pre-coded to be indicative of a
`
`specific credit card account, preferably a merchant or merchant's
`
`identification and a designated payment category.
`
`We believe the specification makes it clear that the payment
`
`category not be included or referenced in the transaction code and
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`that's just a preference and not a requirement, particularly in any
`
`11
`
`claim. Also, Claim 5 of D'Agostino makes it clear -- if you go to the
`
`12
`
`next line -- that -- which reads, the method of Claim 1 further
`
`13
`
`comprising generated transaction code which reflects at least one of a
`
`14
`
`plurality of said payment categories. Here, we think claim
`
`15
`
`differentiation makes clear that Claim 1 does not require the
`
`16
`
`transaction code to reflect a payment category.
`
`17
`
`I'd like to move on into the next term. Unless the Board has
`
`18
`
`any questions, I'll move on to the next term. Defining at least one
`
`19
`
`payment category.
`
`20
`
`JUDGE EASTHOM: Counsel, we're talking about the '988
`
`21
`
`patent; is that correct?
`
`22
`
`23
`
`MR. SCHEINFELD: Yes.
`
`JUDGE EASTHOM: I thought in step E of Claim 1 it says,
`
`24
`
`said transaction code reflecting at least the limits of said designated
`
`25
`
`payment category. Are you saying it doesn't have to reflect the --
`
`
`
`
`
` 6
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`MR. SCHEINFELD: I'm sorry, where are you, Your Honor,
`
`'988, Claim 1?
`
`JUDGE EASTHOM: Yes, step E, Claim 1, yes. So it says,
`
`a transaction code -- said transaction code reflecting at least the limits
`
`of said designated payment category.
`
`MR. SCHEINFELD: I'm at Claim 1, step B, supplying said
`
`custodial authorizing entity with at least account identification data of
`
`said customer's account at '988, Claim 1? I'm sorry, maybe it's --
`
`JUDGE EASTHOM: I was at step E. Did you have step C?
`
`10
`
`MR. SCHEINFELD: Step E. Oh, generating a transaction
`
`11
`
`code.
`
`12
`
`JUDGE EASTHOM: And then said transaction code
`
`13
`
`reflecting --
`
`14
`
`MR. SCHEINFELD: Reflecting at least the limits of said
`
`15
`
`designated payment category to make a purchase within said
`
`16
`
`designated payment category?
`
`17
`
`JUDGE EASTHOM: Right. I thought your argument was
`
`18
`
`that the code doesn't indicate a payment category. Is that --
`
`19
`
`MR. SCHEINFELD: The code itself need not be construed
`
`20
`
`to include the payment category. There are other limitations in the
`
`21
`
`claim that affect the term transaction code, but the term transaction
`
`22
`
`code need not reflect the payment category and the clause that you
`
`23
`
`read, Your Honor, it's not saying that the transaction code needs to
`
`24
`
`reflect the payment category. It says that the transaction code needs
`
`25
`
`to reflect the limits of said payment category.
`
`
`
`
`
` 7
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`JUDGE EASTHOM: What is that talking about, is that a
`
`number?
`
`MR. SCHEINFELD: That's a fair question. That's a very
`
`fair question. I think it is a number. I think it is -- it's not clear, but
`
`our interpretation of that is that it's at the top end of what the payment
`
`category can be. It's the top end. So if the payment category is
`
`purchases up to a thousand dollars or purchases with clothing stores,
`
`purchases at, you know, computer stores --
`
`JUDGE EASTHOM: Number of merchants?
`
`MR. SCHEINFELD: It's the top number. It's the limit.
`
`JUDGE EASTHOM: A limit. Okay.
`
`JUDGE DESHPANDE: When you say top number, are we
`
`13
`
`talking about limiting the number of transactions or the top number
`
`14
`
`for the number of merchants?
`
`15
`
`MR. SCHEINFELD: As this is construed, as this language
`
`16
`
`is used in this claim, again, I come back to what the limit of the
`
`17
`
`payment category is. So if the payment category is clothing stores,
`
`18
`
`then it would be the number of clothing stores that fall within that --
`
`19
`
`JUDGE DESHPANDE: When I'm reading this claim, I'm
`
`20
`
`construing this limitation to reference back to limitation C that says
`
`21
`
`limiting a number of transactions to one or more merchants. So under
`
`22
`
`that I'm reading that as the limit, but I'm asking the question as when
`
`23
`
`in that limitation where it says limiting a number of transactions to
`
`24
`
`one or more merchants, are we limiting the number of transactions or
`
`25
`
`are we limiting the number of merchants?
`
`
`
`
`
` 8
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`
`MR. SCHEINFELD: It's unclear.
`
`JUDGE EASTHOM: But the limits in step B refers back to
`
`whatever --
`
`MR. SCHEINFELD: Step E.
`
`JUDGE DESHPANDE: Step E.
`
`JUDGE EASTHOM: Step E. Does that refer back to the
`
`limits of step C in your view?
`
`MR. SCHEINFELD: Yes. Because the antecedent basis
`
`that's used in the term the, so that would refer back to at least limiting
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`a number of transactions to one or more merchants.
`
`11
`
`JUDGE EASTHOM: So it's either referring to the number
`
`12
`
`of transactions or the number of merchants according to I think Judge
`
`13
`
`Deshpande's question.
`
`14
`
`15
`
`MR. SCHEINFELD: Right, that's correct.
`
`JUDGE DESHPANDE: The next clause in there says, said
`
`16
`
`one or more merchants limitation. Does that suggest that since it's a
`
`17
`
`one or more merchants limitation that we're limiting the number of
`
`18
`
`merchants?
`
`19
`
`MR. SCHEINFELD: Yes, it does. I mean, that's the
`
`20
`
`payment category. You're limiting the ability of the cardholder to use
`
`21
`
`the card at a certain number of merchants, right.
`
`22
`
`I'll move on, then, to defining at least one payment category.
`
`23
`
`Up here, slide 27, here, the Patent Owner is arguing that this needs to
`
`24
`
`specify the actual limit or limits of a payment category. Again, it's
`
`25
`
`similar in that the -- this is a limit of the -- this is not required by
`
`
`
`
`
` 9
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`the -- for the construction of payment category. Instead, it's the
`
`transaction code reflects the limits as the claim reveals, but the term
`
`defining at least one payment category itself doesn't need to specify
`
`the actual limit. It's not the broadest reasonable construction.
`
`And, also, as we point out in our papers, Claim 38, claim
`
`differentiation would indicate or require actually that because Claim
`
`38 is talking about the limits of the transactions that are occurring that
`
`that claim that the definition of defining at least one payment category
`
`need not itself specify the actual limit.
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`JUDGE EASTHOM: Is that important with respect to
`
`11
`
`Cohen? Why is that a --
`
`12
`
`MR. SCHEINFELD: I don't think it's terribly important
`
`13
`
`with respect to Cohen. I think it's important in the sense that they
`
`14
`
`offered a construction that is wrong and it's not based on -- you know,
`
`15
`
`it's not proper. So it's important to us, as the Petitioner, to get the
`
`16
`
`claim constructions correct here in the -- hopefully in light of the
`
`17
`
`event that there is litigation down the road, but I don't believe that this
`
`18
`
`particular term is necessarily crucial in connection with Cohen.
`
`19
`
`The next term may be, that particular merchant. Here, we
`
`20
`
`believe as the Board found in its Institution Decision that a particular
`
`21
`
`merchant needs to be tethered to the transaction that the claims are
`
`22
`
`talking about, that the Board got it right that a particular merchant
`
`23
`
`needs to be the merchant with whom the customer is transacting.
`
`24
`
`On the other hand, the Patent Owner is offering a
`
`25
`
`construction that is not only untethered or tied to the claim, but
`
`
`
`
`
` 10
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`anything that's disclosed in the specification it's offering a
`
`construction for a particular merchant that "a specific merchant with
`
`whom a customer can engage in a purchase transaction". That can be
`
`any merchant anytime, anywhere.
`
`It could be the merchant downstairs with whom I could buy
`
`something with cash. It could be the merchant unrelated to any
`
`particular payment category, anything that the claim requires, and
`
`that's why in the context of the claim, particular merchant should be
`
`construed as the Board has already construed it. We also think that
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`the only way to give the word particular meaning is to make sure it's
`
`11
`
`tied to the transaction that's referenced in the claim. Otherwise, the
`
`12
`
`word particular has no real meaning there.
`
`13
`
`And we do believe the file history and the comments that the
`
`14
`
`Patent Owner made in distinguishing some of the art in connection
`
`15
`
`with the parent application supports this view.
`
`16
`
`One or more merchants and single-merchant limitation. One
`
`17
`
`or more merchants, the Board we think got it right that it is any group
`
`18
`
`category or type of merchant is included in the payment category prior
`
`19
`
`to the customer selecting a particular merchant for a transaction. We
`
`20
`
`think that's right.
`
`21
`
`The Board further qualified its construction in the 543
`
`22
`
`decision correctly that one or more merchants allow for one or
`
`23
`
`multiple merchants as any group category or type of merchant. For
`
`24
`
`the single-merchant limitation, we believe the Board got it right here
`
`25
`
`as well.
`
`
`
`
`
` 11
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`It's a little complicated here, because in one of the Board's
`
`decisions on the 543 Institution Decision in connection with the '988
`
`patent, the Board made it clear that single merchant allows for only
`
`one merchant and that qualification doesn't appear in the other
`
`Institution Decision, but we think it's fair to read the Board's
`
`qualification in the 543 decision in connection with the construction
`
`of single-merchant limitation for the other patent.
`
`There are other additional terms that we think are necessary
`
`for the Board to construe, to consider construction, and that is
`
`10
`
`defining a payment category before generating a code. The Patent
`
`11
`
`Owner has argued that the term -- that the claims require the definition
`
`12
`
`of a payment category before the code is generated. We believe that's
`
`13
`
`not correct, that that's not a requirement of the claim.
`
`14
`
`Even though they're listed in that order, we don't believe the
`
`15
`
`claim requires that the payment category be defined before generating
`
`16
`
`the code. We think the patent specification makes clear that it's an
`
`17
`
`option so that the patent specification does not require such a narrow
`
`18
`
`reading.
`
`19
`
`So if you look at, for example, in the patent specification,
`
`20
`
`column 6, lines 6 to 7, and 34 to 36, at line 6, such additional
`
`21
`
`information where the cardholder presents or supplies information to
`
`22
`
`the authorizing entity may preferably include the identification of a
`
`23
`
`merchant or merchants involved, but it's not a requirement to get a
`
`24
`
`transaction code.
`
`
`
`
`
` 12
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`And then later on in column 6, line 32, more specifically, the
`
`transaction code is pre-coded to be indicative of a specific credit card
`
`account, preferably a merchant or merchant identification and a
`
`designated payment category, selected from the plurality of
`
`predetermined payment categories as set forth above.
`
`So we think the specification makes clear that it's a
`
`preference to define a payment category and then generate the code.
`
`We also think that claim differentiation supports the view that this is
`
`not a requirement. If you looked at --
`
`10
`
`JUDGE DESHPANDE: Before we get to Claim 2, how do
`
`11
`
`we reconcile limitation C, D and E if there's no implicit order there?
`
`12
`
`13
`
`MR. SCHEINFELD: In Claim 1 or Claim 21?
`
`JUDGE DESHPANDE: Claim 1. In Claim 1 we're
`
`14
`
`generating the transaction code and the transaction code reflects the
`
`15
`
`limits of the designated payment category limitation. D is where the
`
`16
`
`payment category is designated and limitation C is where the payment
`
`17
`
`category is defined. If we don't have a defined category, how can we
`
`18
`
`generate a code based on a payment category if we don't know what it
`
`19
`
`is?
`
`20
`
`MR. SCHEINFELD: The transaction code is reflecting the
`
`21
`
`limits, the limits of the designated payment category, not necessarily
`
`22
`
`the payment category.
`
`23
`
`JUDGE DESHPANDE: But we would still need to know
`
`24
`
`the limits of the designated payment category.
`
`
`
`
`
` 13
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`MR. SCHEINFELD: In this claim in that, that's correct, but
`
`that's not just claim construction. That's just -- that's the -- well, that's
`
`fair to consider it for claim construction, but, again, it's not the
`
`designated payment category that needs to be reflected in the code.
`
`And our view is further supported by Claim 2 and Claim 5.
`
`Claim 2 talks about a temporal limitation to this claim. The Patent
`
`Owner, the inventor, and their attorney knew how to claim a temporal
`
`limitation. When it wanted to have a sequence, it says so. The claim
`
`say -- Claim 2 says, comprising the step of designating at least one of
`
`10
`
`said one or more merchants subsequent to generating said transaction
`
`11
`
`code. That's not in Claim 1 and that's why it's in Claim 2.
`
`12
`
`And the same thing with Claim 5. Claim 5 says, the method
`
`13
`
`of Claim 1 further comprising generating a transaction code which
`
`14
`
`reflects at least one of a plurality of said payment categories. So there
`
`15
`
`you have a code. There you have a code, transaction code necessarily
`
`16
`
`reflecting a plurality of payment categories, whereas, before it didn't
`
`17
`
`have to. In Claim 1 it didn't have to. It has -- it has the limits.
`
`18
`
`JUDGE EASTHOM: Can you walk us through -- so, in
`
`19
`
`other words, you're contending that someone would pick up the phone
`
`20
`
`and exchange a credit card number and obtain a certain number of
`
`21
`
`transactions say, but they wouldn't get the number of transactions.
`
`22
`
`The bank, the entity that's selling this particular item would send back
`
`23
`
`a code and then later specify the number of transactions for that code
`
`24
`
`or is that --
`
`
`
`
`
` 14
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`MR. SCHEINFELD: Well, as disclosed in Cohen, the
`
`customer picks up the phone and says, I want to limit my card to -- it
`
`goes both ways. I want to limit my card to clothing stores and you get
`
`your code. I want a code and I want to limit it to clothing stores. It
`
`can work both ways. There are only two ways to do it. Cohen
`
`reflects and discloses both ways.
`
`JUDGE DESHPANDE: I think the question is what way do
`
`the claims require us to do it, even though if -- even if we suggest
`
`Cohen does it both ways, what way does Claim 1 require we do it?
`
`10
`
`MR. SCHEINFELD: Claim 1 doesn't require either way. It
`
`11
`
`doesn't require that you define the payment category before the
`
`12
`
`transaction code. You could get the transaction code, which reflects
`
`13
`
`the limits of a payment category, but not necessarily the payment
`
`14
`
`category itself. That's Claim 1 and then Claim 2 --
`
`15
`
`JUDGE DESHPANDE: How would we know what the
`
`16
`
`limits of the payment category are in order to generate the transaction
`
`17
`
`code without knowing what the payment category is?
`
`18
`
`MR. SCHEINFELD: I know that the most I could use this
`
`19
`
`card for is 10 stores and then, okay, I'm going to issue a transaction
`
`20
`
`code that sets that limit. Now I'm going to say -- and I'm only going
`
`21
`
`to use this for clothing stores and then I'm going to have a transaction
`
`22
`
`code that reflects the limits of that payment category and move on.
`
`23
`
`So, I mean, it's a hypothetical and it's fair to raise it, but I do
`
`24
`
`think there's -- that given the context of the claim and the other claims
`
`25
`
`that follow it when there is a temporal limitation that it's fair to -- that
`
`
`
`
`
` 15
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`the claim not be construed to require a payment category, a
`
`transaction code.
`
`And, you know, I'll also point out, Claim 21. Claim 21(b)
`
`says, I want to -- I'm requesting. I'm requesting a transaction code to
`
`make a purchase within a payment category that at least limits the
`
`transactions. So there there's no definition of the payment category
`
`before the transaction code.
`
`The customer is calling up and say, I'm requesting a
`
`transaction code and I want it, you know, to make a purchase within a
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`payment category, but it doesn't mean that the payment category is
`
`11
`
`first defined and then the code is generated, but that's construction.
`
`12
`
`You know, that's our view. You know, we don't believe that there is a
`
`13
`
`sequential requirement for Claim 1 or Claim 21, particularly in view
`
`14
`
`of the claims that follow it, Claims 2 and Claims 5, but, regardless,
`
`15
`
`Cohen discloses both ways.
`
`16
`
`And if you go to 487, Henry. You'll see -- and this is, by the
`
`17
`
`way, where the CRU got its decision wrong where there was no
`
`18
`
`analysis of this particular paragraph. Column 3, lines 40 to 55.
`
`19
`
`Where a customer dials -- calls up a credit card company and is
`
`20
`
`provided with a code, a transaction code, or a card number, a
`
`21
`
`disposable customized number, and it also says, in one embodiment a
`
`22
`
`user can indicate in advance of the purchase on a telephone call with
`
`23
`
`the credit card company what the single use or customized credit card
`
`24
`
`is to be used for. Does that -- and then the card with that limit is
`
`25
`
`shipped to the cardholder. So, here, you have a situation where the
`
`
`
`
`
` 16
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`payment category is defined before the card code is shipped to the
`
`cardholder.
`
`But beyond that, beyond this disclosure here, which the
`
`Board correctly relied on in its Institution Decision, I think there's -- I
`
`think it's worth it to draw this, if this is going to work.
`
`JUDGE EASTHOM: Was our Institution Decision
`
`published before the CRU’s?
`
`MR. SCHEINFELD: Yes, it was. I'm going to have to read
`
`it, sorry. So I think what the CRU didn't consider, or at least there's
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`no indication that it considered it, and it's not -- and this particular
`
`11
`
`paragraph was not reflected in the Institution Decision. We think it's a
`
`12
`
`very important one and that's on column 3, lines 36 to 66, and this is
`
`13
`
`referenced in our reply brief.
`
`14
`
`15
`
`16
`
`17
`
`JUDGE MEDLEY: Did you say 36?
`
`MR. SCHEINFELD: I said 56.
`
`JUDGE MEDLEY: 56. Thank you.
`
`MR. SCHEINFELD: Column 3, line 56 to 66. So, here, in
`
`18
`
`another embodiment in Cohen, a user could be provided, each month
`
`19
`
`or each year, with a set of disposable, one time only, or customized,
`
`20
`
`limited use, numbers and/or cards, which are printed on the credit card
`
`21
`
`statement for use during the next month or year, or which are mailed
`
`22
`
`to the user. With respect to the disposable card, the user is instructed
`
`23
`
`that, after use of the number once, the number may not be used again.
`
`24
`
`And here's the kicker here, so with respect to the customized
`
`25
`
`card, the card that's limited by use, the cards can either be preset for
`
`
`
`
`
` 17
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`certain uses, or the cards can be ready and waiting in the user's office
`
`or home for setting to the desired use when the user is ready.
`
`So the last clause clearly, or the cards can be ready and
`
`waiting in the user's office or home for setting to the desired use when
`
`the user is ready, the code is sent to the user and when the user is
`
`ready, he picks up the phone and says, I have this code, I have this
`
`card, I want to limit it to clothing stores. That's clearly that option.
`
`But the first option is just the opposite. With respect to the
`
`customized card, the cards can either be preset for certain uses. In this
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`case the card is preset with a payment category and then the
`
`11
`
`transaction code is issued, and that's exactly what -- assuming the
`
`12
`
`Board construes the claim as requiring a payment category defined
`
`13
`
`first before generating a code, that's exactly what Cohen discloses.
`
`14
`
`So in this column, column line -- column 3, lines 40 to 55,
`
`15
`
`and then 55 to 57, anticipates the claims of D'Agostino, particularly
`
`16
`
`because they show defining a payment category both ways before and
`
`17
`
`after generating a code.
`
`18
`
`JUDGE EASTHOM: So in your view you're saying that
`
`19
`
`Claim 1 must be read to have both options, otherwise, Claim 2 doesn't
`
`20
`
`further limit Claim 1.
`
`21
`
`MR. SCHEINFELD: That's correct. And I'll add that Claim
`
`22
`
`2 shows that when the inventor wanted to have a sequence or a
`
`23
`
`temporal limitation in a particular order, he knew how to do it. They
`
`24
`
`knew how to claim it and that's Claim 2. They didn't do that for
`
`
`
`
`
` 18
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`Claim 1 and that's why, you know, I believe that Claim 2 has that
`
`option.
`
`But, you know, again, you know, regardless, Cohen
`
`discloses both ways of doing this, but it is important to get claim
`
`construction correct. I mean, there's no question about it and I think
`
`that in this particular case, claim -- you know, Claim 1 is not -- need
`
`not have that sequence requirement option.
`
`JUDGE EASTHOM: So you're contending basically that
`
`one of skill in the art or the patentholder here had possession of this
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`idea that they could send out a code and then manipulate the
`
`11
`
`parameters that the code defines after the code has already been sent
`
`12
`
`out. In other words --
`
`13
`
`14
`
`MR. SCHEINFELD: That's correct.
`
`JUDGE EASTHOM: And do you have any basis for that in
`
`15
`
`the patent that it says that that --
`
`16
`
`MR. SCHEINFELD: Well, yeah, I mean, in the D'Agostino
`
`17
`
`patent that I -- in the D'Agostino patent?
`
`18
`
`19
`
`JUDGE EASTHOM: Right.
`
`MR. SCHEINFELD: Yeah. I mean, I do in the sense of the
`
`20
`
`language that I read earlier, which talks about the transaction code
`
`21
`
`preferably reflecting the payment category, meaning that it not
`
`22
`
`necessarily reflect the payment category, and that's in the
`
`23
`
`specification. So according to the spec, it could be both ways.
`
`24
`
`With that, I'll move on to the single-merchant limitation.
`
`25
`
`Thank you for your patience with this. I appreciate it.
`
`
`
`
`
` 19
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`JUDGE EASTHOM: We do have paper copies of
`
`similar -- most of the material and also on-line copies, so I don't know
`
`if that helps you with your presentation.
`
`MR. SCHEINFELD: I'm good to go. This is -- if you could
`
`go to slide 37, Henry.
`
`So the single-merchant limitation, the Patent Owner is
`
`spending a lot of time with and I anticipate will when he stands up
`
`here. There are three components to the single-merchant limitation.
`
`One is that the payment category need to be for a single merchant.
`
`10
`
`And the other that the Patent Owner -- the second that the Patent
`
`11
`
`Owner requires or argues is required by the claim.
`
`12
`
`13
`
`JUDGE EASTHOM: Is this Claim 21?
`
`MR. SCHEINFELD: Claim 21. Claim 21 in the '988 and
`
`14
`
`all the claims in the other patent are single-merchant limitations.
`
`15
`
`So for Claim 21 in the '988 patent, he's arguing that because
`
`16
`
`there's a phrase here transactions that the claim necessarily requires
`
`17
`
`that the cardholder be able to perform more than one transaction with
`
`18
`
`a single merchant. That's the second component to the
`
`19
`
`single-merchant limitation.
`
`20
`
`The third component is that the single merchant cannot be
`
`21
`
`identified until later that -- you know, that the single merchant needs
`
`22
`
`to be defined prior to any particular merchant being identified. So
`
`23
`
`those are the three components.
`
`24
`
`You know, I'd like to address again claim construction first
`
`25
`
`because I think it's important to address claim construction before you
`
`
`
`
`
` 20
`
`
`
`IPR2014-00543 (Patent 8,036,988)
`IPR2014-00544 (Patent 7,840,486)
`
`talk about anticipation. In here the phrase, the Patent Owner is
`
`arguing that the single merchant limitation, and particularly this Claim
`
`21 requires that the payment category be limited to a plurality of
`
`transactions to a single merchant. We think that's wrong.
`
`We think that Claim 21 does not require multiple
`
`transactions with a single merchant. We think that the claim itself
`
`makes that clear. Because the Claim 21(b) says, receiving a request
`
`from said accountholder for a transaction code to make a purchase.
`
`So that's one purchase and then in paragraphs (e) and (f), receiving a
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`request to authorize payment for a purchase using said transaction
`
`11
`
`code. Again, singular, purchase is singular.
`
`12
`
`And then 21(f) being authorizing payment for said purchase,
`
`13
`
`one purchase, if said purchas
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
