`PATENT TRIAL & APPEAL BOARD
`
`
`John D’Agostino
`In re Patent of:
`U.S. Patent No.: 7,840,486
`Issue Date:
`November 23, 2010
`Application No.: 11/252,009
`Filing Date:
`October 17, 2005
`Title:
`System and Method for Performing Secure Credit Card
`Transactions
`
`DECLARATION OF DR. JACK D. GRIMES, Ph.D.
`
`
`
`I, Jack D. Grimes, Ph.D., declare as follows:
`
`(1)
`
`I have written this Declaration at the request of MasterCard International
`
`Incorporated (“MasterCard”). In forming my opinions, I rely on my knowledge
`
`and experience in the field and on documents and information referenced in this
`
`Declaration.
`
`(2)
`
`I reside at 5025 Wine Cellar Drive, Sparks, NV. I am an independent
`
`consultant. I have prepared this Declaration for consideration by the Patent Trial
`
`and Appeal Board. I am over eighteen years of age and I would otherwise be
`
`competent to testify as to the matters set forth herein if I am called upon to do so.
`
`I.
`
`BACKGROUND AND QUALIFICATIONS
`
`(3)
`
`I earned B.S. and M.S. degrees in Electrical Engineering, and a Ph.D.
`
`degree in Electrical Engineering (with a minor in Computer Science), all from
`
`
`
`1
`
`MasterCard, Exh. 1008, p. 1
`
`
`
`
`
`Iowa State University. I also earned an M.S. degree in Experimental Psychology
`
`from the University of Oregon. I have been active in several professional societies
`
`and have worked in the computer and electronics field for over forty (40) years
`
`including teaching at two universities. Details of my education and work
`
`experience are set forth in my curriculum vitae, which is attached as Appendix A.
`
`(4)
`
`From 1996 until 1999, I worked at Visa International (“Visa”) and was
`
`Senior Vice President for Technology, Architecture & Strategy. My
`
`responsibilities included developing the strategies for Visa in chip card technology,
`
`management of large-scale software projects, and the evaluation of investments in
`
`technology companies. My duties included management of two technology and
`
`strategy groups containing over 30 people. One group provided chip card and
`
`related technology development for new products and services, including SET
`
`(Secure Electronic Transactions over the Internet). The other group was
`
`responsible for the global network and processing architecture strategy to replace
`
`the then current VisaNet services, providing credit card authorization and
`
`settlement. I also served as an internal consultant on Internet payment systems.
`
`(5)
`
`I have reviewed United States Patent No. 7,840,4861 (“the ’486 patent”)
`
`to D’Agostino. I have also reviewed the publications cited within this declaration
`
`
`1 John D’Agostino, “System and Method for Performing Secure Credit Card
`Transactions,” U.S. Patent No. 7,840,486, issued November 23, 2010 (Exh. 1001).
`
`
`
`2
`
`MasterCard, Exh. 1008, p. 2
`
`
`
`
`
`and referenced in the covered business method patent review petition submitted
`
`herewith.
`
`II.
`
`STATE OF THE ART
`
`(6) The technology for performing secure credit card purchases in connection
`
`with remote commercial transactions was well known by the year 1999.
`
`Credit Card Fraud
`
`(7) There are many well-known ways that an unauthorized user can obtain
`
`your name, credit card number and expiration date. Credit cards have become so
`
`widely used that fraud is a major problem and concern for most cardholders.
`
`(8)
`
`In attended, point-of-sale (POS) transactions, the cardholder’s signature
`
`is compared to the signature printed on the credit card. This provides
`
`authentication that the person utilizing the credit card is, in fact, the cardholder. In
`
`Europe, where chip cards are common, attended transactions typically require the
`
`entry of a PIN at the point-of-sale.
`
`(9) However, these solutions do not work for “remote transactions,” such as
`
`on-line purchases using the Internet or for transactions over the telephone. In this
`
`case, the customer’s signature cannot be verified and there is no PinPad to provide
`
`for the entry of a PIN.
`
`(10) As a result, in remote transactions, the opportunity exists for an
`
`unauthorized user to provide a stolen credit card number with accompanying info
`
`
`
`3
`
`MasterCard, Exh. 1008, p. 3
`
`
`
`
`
`to conduct a purchase transaction. For example, for Internet transactions, it is
`
`difficult to differentiate between an unauthorized user and the true cardholder
`
`based on the credit card information provided for a transaction. The fraudulent
`
`transaction can only be identified later (e.g., if the cardholder realizes that a
`
`fraudulent transaction has occurred).
`
`(11) To address the problem of credit card fraud, several solutions were
`
`proposed, including the technology disclosed by U.S. Patent No. 6,422,462 to
`
`Cohen (Exh. 1004, “Cohen”), and by U.S. Patent No. 6,636,833 to Flitcroft et al.
`
`(Exh. 1005, “Flitcroft”).
`
`(12) One well-known solution to credit card fraud is creating a limited-use
`
`credit card that is restricted to a single use. (See Cohen at C2:35-43; Flitcroft at
`
`C6:53-56) Each of these single use cards has a unique card number that is
`
`different from to the master credit card account number. That way, if the card
`
`number and accompanying info is subsequently stolen, that card number cannot be
`
`used for a second purchase. After the card is used, it may be discarded.
`
`(13) Another well-known solution to credit card fraud is creating a limited-use
`
`credit card with restrictions on its usage, such as limiting the dollar amount,
`
`limiting the frequency of use, or limiting the merchant category where the card
`
`may be used – such as for airline tickets or for clothing stores, etc. (See Cohen at
`
`C7:66-8:46; Flitcroft at C8:2-10). These limited use cards also have numbers that
`
`
`
`4
`
`MasterCard, Exh. 1008, p. 4
`
`
`
`
`
`are different from the master credit card account number. That way, the limited-
`
`use card number cannot be used for purchases that are inconsistent with the
`
`restrictions on its usage.
`
`Repeating Credit Card Transactions
`
`(14) It was well known in the art at the time the patent was filed that you can
`
`call your bank and set up a repeating payment account to pay for reoccurring
`
`charges, e.g., on a monthly basis for your health club. For example, U.S. Patent
`
`No. 5,283,829 to Anderson (Exh. 1011, “Anderson”) discloses that various
`
`banking institutions offer their subscribers the option of automatically paying
`
`monthly reoccurring charges (such as car notes, insurance premiums, mortgages,
`
`etc.) via automatic funds transfer (Anderson at C1:57:63).
`
`(15) It was also well known in the art at the time the patent was filed that
`
`these repeating payments could be set-up and charged to a credit card account. For
`
`example, U.S. Patent No. 6,064,987 to Walker (Exh. 1010, “Walker”) discloses the
`
`use of credit cards for “installment plans” in which a user can set up a repeating
`
`transaction with a credit card to make payments at various time intervals, such as
`
`once a month. (See Walker at C1:66-2:10; C4:25-32; C4:37-40).
`
`III. LEVEL OF ORDINARY SKILL IN THE ART
`
`(16) The level of ordinary skill in the art of the ’486 Patent is a person having
`
`a B.S. degree in Electrical Engineering or Computer Science, or the equivalent
`
`
`
`5
`
`MasterCard, Exh. 1008, p. 5
`
`
`
`
`
`experience, with at least three years of experience in credit card payment
`
`technologies, including experience in existing, accepted remote credit card
`
`transaction practices in 1999, such as methods of performing secure credit card
`
`purchases of goods and services which reduces the risk of potential fraud and theft
`
`by eliminating unauthorized access to a consumer’s private credit card information.
`
`(17) Based on my experience, I have an understanding of the capabilities of a
`
`person of ordinary skill in the art. I have supervised and directed many such
`
`persons over the course of my career. Further, I had those capabilities myself at
`
`the time the patent was filed.
`
`IV. MATERIALS CONSIDERED
`
`(18) In developing my opinions below relating to the ’486 Patent, I have
`
`considered the following materials:
`
`• Exhibit 1001 – U.S. Patent No. 7,840,486
`
`• Exhibit 1002 – File History for U.S. Patent No. 7,840,486
`
`• Exhibit 1003 – File History for U.S. Reexamination No. 90/012,517
`
`• Exhibit 1004 – U.S. Patent No. 6,422,462 (“Cohen”)
`
`• Exhibit 1005 – U.S. Patent No. 6,636,833 (“Flitcroft”)
`
`• Exhibit 1006 – U.S. Patent No. 5,826,243 (“Musmanno”)
`
`• Exhibit 1007 – Complaint in D’Agostino v. MasterCard, Inc. et al. (13-cv-
`
`0738)
`
`
`
`6
`
`MasterCard, Exh. 1008, p. 6
`
`
`
`
`
`• Exhibit 1009 – Excerpts from Random House Webster’s Unabridged
`
`Dictionary, Second Edition (“Random House Webster”)
`
`• Exhibit 1010 – U.S. Patent No. 6,064,987 (“Walker”)
`
`• Exhibit 1011 – U.S. Patent No. 5,283,829 (“Anderson”)
`
`• Exhibit 1012 – ISO 8583 Financial Transaction Card Originated Messages –
`
`Interchange Message Specifications (1992) (“ISO 8583”)
`
`IV. CLAIM CONSTRUCTION
`
`(19) In proceedings before the USPTO, I understand that claims of a patent
`
`are to be given their broadest reasonable interpretation in view of the specification
`
`from the perspective of one skilled in the art. I understand that a different standard
`
`is used in district court proceedings. In comparing the claims of the ’486 Patent to
`
`the known prior art, I have carefully considered the ’486 Patent, and the ’486
`
`patent file history based upon my experience and knowledge in the field.
`
`(20) The claim limitation “generating [a/said] transaction code” may be
`
`construed, consistent with its plain and ordinary meaning, to mean “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.” This
`
`
`
`7
`
`MasterCard, Exh. 1008, p. 7
`
`
`
`
`
`construction is consistent with the disclosure of the term in the ’486 Patent. (See
`
`Exh. 1001, ’486 Patent at Abstract; C3:43-48; C6:19-38; C6:63-7:1).2
`
`(21) The claim limitation “defining at least one payment category” may be
`
`construed, consistent with its plain and ordinary meaning, to mean “specifying the
`
`type of limitation (or limitations) that are available to be applied to a transaction
`
`code in order to limit its use.” This construction is consistent with the disclosure
`
`of the term in the ’486 Patent. (See Exh. 1001, ’486 Patent at C2:67-3:3; C3:48-
`
`4:2; C4:20-24; C7:2-8; C7:56-8:43).
`
`(22) The claim limitation “particular merchant” may be construed, consistent
`
`with its plain and ordinary meaning, to mean “a specific merchant with whom a
`
`customer can engage in the purchase transaction.” This construction is consistent
`
`with the disclosure of the term in the ’486 Patent. (See Exh. 1001, ’486 Patent at
`
`C3:67-4:2; C4:8-13; C4:44-49).
`
`(23) The claim limitation “verifying that said defined purchase parameters are
`
`within said designated payment category” may be construed, consistent with its
`
`plain and ordinary meaning, to mean “ascertaining that any limitation associated
`
`with the designated payment category is satisfied.” This construction is consistent
`
`2 To the extent the Board does not accept this construction of “generating [a/said]
`transaction code,” I understand that the Board may instead construe this term to
`mean “creating a code usable as a substitute for a credit card number in a purchase
`transaction.”
`
`
`
`8
`
`MasterCard, Exh. 1008, p. 8
`
`
`
`
`
`with the disclosure of the term in the ’486 Patent. (See Exh. 1001, ’486 Patent at
`
`C4:8-13; C7:8-24) This construction is also consistent with the dictionary
`
`definition of the word “verify.” (See Exh. 1009, Random House Webster at 2114).
`
`(24) The claim limitation “promotional material” may be construed, consistent
`
`with its plain and ordinary meaning, to mean “any information about the product
`
`that facilitates the purchase transaction.” (See Exh. 1001, ‘486 Patent at 3:7-12;
`
`5:36-48; 7:25-38).
`
`V. DISCUSSION OF RELEVANT PRIOR ART
`
`(25) In proceedings before the USPTO, I understand that the claims of an
`
`unexpired patent are to be given their broadest reasonable interpretation in view of
`
`the specification from the perspective of one skilled in the field. It is my
`
`understanding that the ’486 patent has not expired. In comparing the claims of the
`
`’486 patent to the known prior art, I have carefully considered the ’486 patent, and
`
`the ’486 patent file history based upon my experience and knowledge in the
`
`relevant field.
`
`(26) I am informed that the ’486 patent is a continuation of U.S. Patent
`
`Application No. 10/037,007, filed on November 9, 2001, which is a continuation-
`
`in-part of U.S. Patent Application No. 09/213,745, filed on January 15, 1999.
`
`(27) It is my understanding that claims may be found invalid as anticipated. I
`
`understand this to mean that a claim is invalid if there is a single prior art reference
`
`
`
`9
`
`MasterCard, Exh. 1008, p. 9
`
`
`
`
`
`that discloses each limitation of the claim either expressly or inherently. I
`
`understand a limitation to be inherently disclosed if one of ordinary skill in the art
`
`would read the reference and understand that the limitation is necessarily present in
`
`the reference.
`
`(28) It is my understanding that a patent claim can be found unpatentable as
`
`obvious where the differences between the subject matter sought to be patented
`
`and the prior art are such that the subject matter as a whole would have been
`
`obvious at the time the invention was made to one of ordinary skill in the art.
`
`U.S. Patent No. 6,422,462 to Cohen
`
`(29) I’ve been asked to consider whether claims 1-15 and 22-30 of the ’486
`
`patent are invalid as anticipated under 35 U.S.C. § 102 by U.S. Patent No.
`
`6,422,462 to Cohen (Ex. 1004, “Cohen”). I have reviewed, had input into, and
`
`agree with the claim charts in the accompanying petition showing that each
`
`element of claims 1-15 and 22-30 is invalid as anticipated by Cohen.
`
`(30) I have read and I understand Cohen. Cohen teaches a secure method for
`
`engaging in credit card transactions, which limits the transactions to selected
`
`vendors. Cohen at C2:32-43. Cohen discloses a credit card holder contacting their
`
`credit card company, verifying their identity, and then receiving a transaction code
`
`number to be used for a limited number of transactions. Cohen at C3:41-48. The
`
`credit card holder can determine and customize the use of the transaction code
`
`
`
`10
`
`MasterCard, Exh. 1008, p. 10
`
`
`
`
`
`number. Cohen at C3:49-52. After the credit card holder has received the
`
`transaction code number, they can use the number with a merchant as a substitute
`
`for a regular credit card number, and the merchant can validate the transaction code
`
`number with the credit card company. Cohen at C5:35-39. The credit card
`
`company can validate the transaction code number, or deny the transaction if the
`
`number is used for anything other than the pre-determined use indicated by the
`
`credit card holder. Cohen at C5:44-49.
`
`(31) Cohen discloses a “payment category…limiting…purchases to a single
`
`merchant.” Cohen discloses a transaction code number that is limited in use to a
`
`one-time transaction with one merchant: “The card could even [be] customized for
`
`use in a particular store itself...” (Cohen at C8:25-34). “[I]n one
`
`embodiment…[t]hese credit cards or credit card numbers are generated for a one
`
`time, single transaction basis, after which they are disposed of, or thrown away.
`
`The numbers can be used…to effect a single transaction.” (Cohen at C2:35-43). A
`
`credit card number that is customized for a one-time use, to execute a single
`
`transaction, is by definition limited to purchases with a single merchant.
`
`(32) Cohen discloses: “said single merchant limitation being included in said
`
`payment category prior to any particular merchant being identified as said single
`
`merchant”. Cohen discloses that the transaction code could be limited to a single
`
`transaction: “in one embodiment…[t]hese credit cards or credit card numbers are
`
`
`
`11
`
`MasterCard, Exh. 1008, p. 11
`
`
`
`
`
`generated for a one time, single transaction basis” and subsequently “[a]fter a one
`
`time use of the credit card number, the number is deactivated.” (Cohen at C2:35-
`
`43). A one-time use transaction code can only be used at one merchant, therefore
`
`the transaction code is inherently limited to a one merchant. This limitation to a
`
`single merchant occurs before the transaction code is used – and in effect, before
`
`the particular merchant is identified. Therefore, the single-use transaction code as
`
`disclosed by Cohen is inherently limited to a single merchant before any particular
`
`merchant is identified.
`
`(33) Cohen discloses a “ transaction code [reflecting/associated with]…the
`
`limits of said payment category.” Cohen discloses that “[a] customized credit card
`
`could be issued to the user which is only valid for use for that particular type of
`
`charge … such that if the employee tries to use it for anything else in excess of that
`
`authorized, the charge will be declined.” (Cohen at C8:25-32) Cohen’s disclosure
`
`of declining authorization inherently shows that the transaction code reflects and is
`
`associated with the limits on use.
`
`(34) Cohen discloses “the step of designating said single merchant subsequent
`
`to generating said transaction code.” Cohen discloses that the user “accesses one
`
`of his or her disposable credit cards” and then “the user transmits his or her credit
`
`card information to the vendor.” (Cohen at C5:29-37). By transmitting the
`
`
`
`12
`
`MasterCard, Exh. 1008, p. 12
`
`
`
`
`
`transaction code (i.e. the disposable credit card number) to the vendor, the user is
`
`designating the vendor as the single merchant.
`
`(35) Cohen discloses “said step of verifying that said defined purchase
`
`parameters correspond to said selected payment category further identifies said
`
`merchant as said single merchant.” Cohen discloses that the merchant seeks
`
`verification of the purchase parameters: “Upon use of the card, the information
`
`regarding the transaction is transmitted to the credit card company, as is known in
`
`the art.” (Cohen at C13:66-14:1). “That vendor then verifies the transaction and
`
`obtains an authorization code from the credit card company authorizing the
`
`purchase, as is currently standard practice with credit card transactions … Upon
`
`receiving the request for verification, the credit card company notes the identity of
`
`the vendor.” (Cohen at C5:35-49). Cohen inherently discloses that when the
`
`merchant seeks verification of the purchase parameters, the merchant is identified
`
`as the single merchant by the information contained in the transaction messaging.
`
`(See ISO 8583 at 1, 3-4, 23, 34)
`
`(36) Cohen discloses “[designating/designation of] a merchant as said
`
`merchant.” Cohen discloses that the merchant seeks verification of the purchase
`
`parameters: “Upon use of the card, the information regarding the transaction is
`
`transmitted to the credit card company, as is known in the art.” (Cohen at C13:66-
`
`14:1). “That vendor then verifies the transaction and obtains an authorization code
`
`
`
`13
`
`MasterCard, Exh. 1008, p. 13
`
`
`
`
`
`from the credit card company authorizing the purchase, as is currently standard
`
`practice with credit card transactions … Upon receiving the request for
`
`verification, the credit card company notes the identity of the vendor.” (Cohen at
`
`C5:35-49). Cohen inherently discloses that when the merchant seeks verification
`
`of the purchase parameters, the merchant is designated as the single merchant by
`
`the information contained in the transaction messaging. (See ISO 8583 at 1, 3-4,
`
`23, 34)
`
`(37) Cohen discloses “utilizing a processing computer of a custodial
`
`authorizing entity.” Cohen discloses that the transaction code is generated by the
`
`custodial authorizing entity using a processing computer: “[A] software program
`
`can be provided to customize and/or activate the card.” (Cohen at C12:51-52).
`
`Cohen’s disclosure of a software program to customize the card would inherently
`
`disclose the use of a processing computer to execute the software program. It
`
`would be impossible to implement a software program without a processing
`
`computer to execute the software program code.
`
`(38) Cohen discloses “communicating promotional information of offered
`
`subject matter to the customer by the merchant.” Cohen discloses: “[m]any of the
`
`embodiments herein could be used in conjunction with a policy by the credit card
`
`company (or by the main cardholder or the user) in which purchases from Internet
`
`transactions, for example (or purchases over unsecure networks), are only accepted
`
`
`
`14
`
`MasterCard, Exh. 1008, p. 14
`
`
`
`
`
`if made in conjunction with a disposable or customized credit card number.”
`
`(Cohen at C3:34-39) One of ordinary skill in the art would understand that the
`
`display of promotional material is typically used in purchases from Internet
`
`transactions. For example, when a product is sold on a website, an image of the
`
`product or a list of the product features can be displayed by the merchant website
`
`to promote the sale of the product.
`
`U.S. Patent No. 6,636,833 to Flitcroft et al.
`
`(39) I’ve been asked to consider whether claims 1-15 and 22-30 of the ’486
`
`patent are invalid as anticipated under 35 U.S.C. § 102 by U.S. Patent No.
`
`6,636,833 to Flitcroft et al. (Exh. 1005, “Flitcroft”). I have reviewed, had input
`
`into, and agree with the claim charts in the accompanying petition showing that
`
`each element of claims 1-15 and 22-30 is invalid as anticipated by Flitcroft.
`
`(40) I have read and I understand Flitcroft. Flitcroft discloses a secure method
`
`for implementing limited-use credit card numbers that can only be used for
`
`transactions at limited merchants. Flitcroft at C1:11-13; C6:53-60.
`
`(41) Flitcroft discloses that an account holder can contact an authorizing entity
`
`and request a transaction code number for use in making credit card transactions in
`
`a secure manner. Flitcroft at C14:12-13. The limited-use transaction code number
`
`could restrict the permissible transactions, such as for purchases with one or more
`
`merchants. Flitcroft at C6:53-56. The transaction code number could also be
`
`
`
`15
`
`MasterCard, Exh. 1008, p. 15
`
`
`
`
`
`restricted to purchases with a single merchant. Flitcroft at Abstract. After the
`
`limitation on the number of permissible merchants with which the transaction code
`
`can be used is established, the customer can then use the transaction code to make
`
`a purchase. Flitcroft at C5:5-14. The authorizing entity will verify the purchase if
`
`it is within the use-limits of the payment categories permitted for the transaction
`
`code. Flitcroft at C5:5-14.
`
`(42) Flitcroft discloses a “payment category…limiting…purchases to a single
`
`merchant.” Flitcroft discloses a transaction code number that can be used a single
`
`time with one merchant: “This plan provides security against fraud because it is
`
`locked to a single merchant” Flitcroft at C16:53-54. “A credit card system is
`
`provided which has the added feature of providing additional limited-use credit
`
`card numbers and/or cards. These numbers and/or cards can be used for a single
`
`transaction” Flitcroft at Abstract. “The term ‘limited-use’ credit card number is
`
`used to encompass…the embodiment in which the credit card is designated for a
`
`single use.” Flitcroft at C6:53-56. A single use transaction code can only be used
`
`for a purchase with a single merchant.
`
`(43) Flitcroft discloses: “said single merchant limitation being included in
`
`said payment category prior to any particular merchant being identified as said
`
`single merchant”. Flitcroft discloses a limited-use transaction a code that could be
`
`restricted in use with a single merchant, but no particular merchant is identified
`
`
`
`16
`
`MasterCard, Exh. 1008, p. 16
`
`
`
`
`
`until the card is used for the first time: “When the limited-use number is limited to
`
`a specific merchant, the merchant can be…determined by first use.” Flitcroft at
`
`C16:57-59. “[W]herein use of the limited-use credit card number is valid for
`
`transactions with a specific merchant as determined by a first use.” Flitcroft at
`
`C28:23-25. Therefore, the transaction code is limited to a single merchant before
`
`any particular merchant is identified by the use of the transaction code.
`
`(44) Flitcroft discloses a “transaction code [reflecting/associated with]…the
`
`limits of said payment category.” Flitcroft discloses “a first exemplary
`
`embodiment, which pertains to a credit card technique involving: …assigning at
`
`least one credit card number from the pool of credit card numbers to be a limited-
`
`use credit card number which is deactivated upon a use-triggered condition
`
`subsequent.” Flitcroft at C4:60-5:1. Flitcroft’s disclosure of a “limited-use credit
`
`card number” and deactivating the limited-use credit card number inherently shows
`
`that the credit card number (i.e. transaction code) reflects and is associated with the
`
`limits on use.
`
`(45) Flitcroft discloses “the step of designating said single merchant
`
`subsequent to generating said transaction code.” Flitcroft discloses that “[t]he
`
`step of processing the transaction includes:… determin[ing] whether to deactivate
`
`the limited-use credit card number based on whether a limited-use event pertaining
`
`to the use of the limited-use credit card number has occurred.” Flitcroft at C5:38-
`
`
`
`17
`
`MasterCard, Exh. 1008, p. 17
`
`
`
`
`
`43. By using the transaction code (i.e. the limited-use credit card number) to
`
`perform a limited-use event with a vendor, the user is designating the vendor as the
`
`single merchant.
`
`(46) Flitcroft discloses “said step of verifying that said defined purchase
`
`parameters correspond to said selected payment category further identifies said
`
`merchant as said merchant.” Flitcroft discloses that the merchant seeks
`
`verification of the purchase parameters: “Processing systems for handling limited
`
`use cards perform a number of functions including…Provide authorization to the
`
`merchant if valid and within the limitations for specified number and associated
`
`account.” Flitcroft C23:12-23. Flitcroft inherently discloses that when the
`
`merchant seeks verification of the purchase parameters, the merchant is identified
`
`as the single merchant by the information contained in the transaction messaging.
`
`(See ISO 8583 at 1, 3-4, 23, 34)
`
`(47) Flitcroft discloses “[designating/designation of] a merchant as said
`
`single merchant.” Flitcroft discloses that the user uses the transaction code for a
`
`purchase transaction: “single use credit cards could then be used … for ‘card
`
`present’ trade where each card would be ‘swiped’ in the normal manner.” Flitcroft
`
`at C8:14-18. The merchant then seeks verification of the purchase parameters.
`
`“Processing systems for handling limited use cards perform a number of functions
`
`including … Verify that the transaction falls within limitations placed on the
`
`
`
`18
`
`MasterCard, Exh. 1008, p. 18
`
`
`
`
`
`specific number.” Flitcroft at C23:12-17. Flitcroft inherently discloses that when
`
`the user uses the transaction code and the merchant seeks verification of the
`
`purchase parameters, the merchant is designated as the single merchant by the
`
`information contained in the transaction messaging. (See ISO 8583 at 1, 3-4, 23,
`
`34)
`
`(48) Flitcroft discloses “communicating promotional information of offered
`
`subject matter to the customer by the merchant.” Flitcroft discloses: “[t]hese
`
`[limited-use] numbers can be accessed for use on the Internet or for use over the
`
`phone/mail order. (Step 610). The numbers must therefore be able to be inserted
`
`directly into a web page (step 612), or printed out/copied from screen for use in
`
`other ways. (Step 614). The limited-use number can be copied, printed, pasted via
`
`the clipboard (or equivalent) or dragged-and-dropped on to a web page.” Flitcroft
`
`at 21:36-43. One of ordinary skill in the art would understand that the display of
`
`promotional material is typically used in purchases from Internet transactions. For
`
`example, when a product is sold on a website, an image of the product or a list of
`
`the product features can be displayed by the merchant website to promote the sale
`
`of the product.
`
`U.S. Patent No. 5,826,243 to Musmanno et al.
`
`(49) I have read and I understand Musmanno. Musmanno discloses a
`
`management system for a master account and multiple sub-accounts that can direct
`
`
`
`19
`
`MasterCard, Exh. 1008, p. 19
`
`
`
`
`
`repeating expenses, such as car and mortgage payments. Musmanno at C2:40-47;
`
`C3:5-18; C5:26-31.
`
`(50) I’ve been asked to consider whether claims 16-21 of the ’486 patent are
`
`invalid as obvious under 35 U.S.C. § 103 over Cohen in view of U.S. Patent No.
`
`5,826,243 to Musmanno et al. (Exh. 1006, “Musmanno”). I have reviewed, had
`
`input into, and agree with the claim charts in the accompanying petition showing
`
`that each element of claims 16-21 is invalid as obvious over Cohen in view of
`
`Musmanno.
`
`(51) Both Cohen and Musmanno are directed to solving the same problem,
`
`i.e., the process of facilitating financial transactions between various accounts.
`
`Cohen discloses a limited-use transaction code that can only be employed for
`
`transactions at a predetermined number of vendors. Cohen at C1:48-62.
`
`Musmanno discloses a management system for controlling financial transactions,
`
`including managing fund transfers between multiple accounts. Musmanno at C1:5-
`
`10. Musmanno also discloses the application of recurring transactions between
`
`various accounts. Musmanno at C5:26-31. It would have been obvious to a person
`
`of ordinary skill in the art to apply the repeating transactions disclosed in
`
`Musmanno to the transaction code disclosed in Cohen. The combination would
`
`have yielded predicable results – a transaction code that could be used for
`
`repeating transactions. Thus, a person of ordinary skill in the art would have a
`
`
`
`20
`
`MasterCard, Exh. 1008, p. 20
`
`
`
`
`
`clear motivation to combine Cohen and Musmanno to achieve these predictable
`
`results.
`
`(52) I’ve been asked to consider whether claims 16-21 of the ’486 patent are
`
`invalid as obvious under 35 U.S.C. § 103 over Flitcroft in view of Musmanno. I
`
`have reviewed, had input into, and agree with the claim charts in the accompanying
`
`petition showing that each element of claims 16-21 is invalid as obvious over
`
`Flitcroft in view of Musmanno.
`
`(53) Both Flitcroft and Musmanno address the same problem, i.e., a method
`
`for facilitating financial transactions between various accounts. Flitcroft discloses
`
`a secure transaction code that is limited in use to transactions at a predetermined
`
`number of merchants. Flitcroft at Abstract, C1:11-13, C6:53-60. Musmanno
`
`discloses a management system for controlling financial transactions, including
`
`managing fund transfers between multiple accounts. Musmanno at C1:5-10.
`
`Musmanno also discloses the application of recurring transactions between various
`
`accounts. Musmanno at C5:26-31. It would have been obvious to a person of
`
`ordinary skill in the art to apply the repeating transactions disclosed in Musmanno
`
`to the transaction code disclosed in Flitcroft. The combination would have yielded
`
`predicable results – a transaction code that could be used for repeating transactions.
`
`Thus, a person of ordinary skill in the art would have clear a motivation to
`
`combine Flitcroft and Musmanno to achieve these predictable results.
`
`
`
`21
`
`MasterCard, Exh. 1008, p. 21
`
`
`
`
`
`(54) Musmanno discloses “a repeating transaction.” Musmanno discloses the
`
`use of a repeating transaction to pay for various purchase transactions, such as
`
`mortgage payments, car payments and tuition payments: “[T]he accounts have
`
`been set up to have an automatic transfer of funds from the Master Account 20 to
`
`the Mortgage Subaccount 310, the Car Subaccount 320 and the Tuition Subaccount
`
`330 every 14 days and an automatic transfer of funds to the Master Account 20
`
`from the Mortgage Subaccount 310 and the Car Subaccount 320 on the 28th day of
`
`each month.” Musmanno at C5:53-59. It would have been obvious a person of
`
`skill in the art to employ repeating transactions for credit card accounts. It was
`
`well known in