throbber
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`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

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