`________________________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________________
`APPLE INC.,
`Petitioner
`v.
`SMARTFLASH LLC,
`Patent Owner.
`________________________
`Case CBM2014-001021
`Patent 8,118,221 B2
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`DECLARATION OF JONATHAN KATZ, PH.D. IN SUPPORT OF
`PATENT OWNER’S RESPONSE TO PETITION
`
`
`
`
`
`1 Case CBM2014-00103 has been consolidated with the instant proceeding.
`
`
`
`1
`
`Smartflash - Exhibit 2028
`Apple v. Smartflash
`CBM2014-00102
`
`Page 1
`
`
`
`I, Jonathan Katz, hereby declare:
`
`1.
`
`I am currently a Professor in the Department of Computer Science at
`
`the University of Maryland where, among other things, I teach classes in the
`
`area of cybersecurity, conduct research in this field, and supervise graduate-
`
`student research. I am also currently the Director of the Maryland
`
`Cybersecurity Center (MC2), as part of which I interact regularly with the
`
`cybersecurity industry and oversee faculty conducting research in various
`
`sub-fields of cybersecurity including cryptography, network security, and
`
`mobile-phone security. I received my Ph.D. (with distinction) in Computer
`
`Science from Columbia University in 2002.
`
`2. My curriculum vitae is attached hereto as Appendix A, and the list of
`
`cases in which I have been an expert in the last five years is attached hereto
`
`as Appendix B. I additionally have experience in computer programming.
`
`3.
`
`I have been retained by Smartflash LLC to provide an expert opinion
`
`in CBM2014-00102, -00106, -00108 and -00112.
`
`4.
`
`I have reviewed the material shown in Appendix C in preparing this
`
`declaration.
`
`
`
`
`
`2
`
`Page 2
`
`
`
`I.
`
`5.
`
`Grounds for Review
`
`I understand that on September 30, 2014 the Patent and Trial Appeal
`
`Board (PTAB) of the U.S. Patent and Trademark Office (USPTO) issued a
`
`Decision to institute a Covered Business Method (CBM) Review of U.S.
`
`Patent No. 8,118,221 (the ‘221 patent). Decision at 1. The PTAB further
`
`consolidated the proceedings of CBM2014-00102 and CBM2014-00103 into
`
`the current proceeding. Decision at 24.
`
`6.
`
`I understand that the PTAB instituted a review of claims 1, 2, and 11-
`
`14 on three different grounds. I understand that the PTAB held that the
`
`Petition (hereinafter “the 00102 Petition”) in CBM2014-00102 had shown
`
`that it was more likely than not that claims 1, 11 and 12 are unpatentable,
`
`pursuant to 35 U.S.C. § 103, over the combination of U.S. Patent No.
`
`5,530,235 (“Stefik ‘235”) and U.S. Patent No. 5,629,980 (“Stefik ‘980”).
`
`Decision at 24. I understand that the PTAB held that the 00102 Petition had
`
`shown that it was more likely than not that claims 2, 13 and 14 are
`
`unpatentable, pursuant to 35 U.S.C. § 103, over the combination of Stefik
`
`‘235, Stefik ‘980, and European Patent Application, Publication No.
`
`EP0809221A2 (“Poggio”). Decision at 24. I understand that the PTAB held
`
`that the Petition (hereinafter “the 00103 Petition”) in CBM2014-00103 had
`
`shown that it was more likely than not that claims 1, 2 and 11-14 are
`
`
`
`3
`
`Page 3
`
`
`
`unpatentable, pursuant to 35 U.S.C. § 103, over U.S. Patent No. 5,915,019
`
`(“Ginter”). Decision at 24. I also understand that the 00102 and 00103
`
`Petitions raised a number of other grounds of unpatentability, but that the
`
`“trial is limited to the grounds identified above.” Decision at 24. My
`
`opinions in this declaration are limited to the instituted grounds.
`
`
`
`II.
`
`7.
`
`Legal Standards and Claim Construction
`
`It has been explained to me that the standard for patentability under 35
`
`U.S.C. § 103 is that of “obviousness” and that obviousness is a question of
`
`law based on underlying factual findings, including: (1) the scope and
`
`content of the prior art; (2) the differences between the claims and the prior
`
`art; (3) the level of ordinary skill in the art; and (4) objective considerations
`
`of nonobviousness. I further understand that examples of objective
`
`considerations of nonobviousness (or “secondary considerations”) include:
`
`(1) the invention's commercial success, (2) long felt but unresolved needs,
`
`(3) the failure of others, (4) skepticism by experts, (5) praise by others, (6)
`
`teaching away by others, (7) recognition of a problem, and (8) copying of
`
`the invention by competitors.
`
`8.
`
`I also understand that the PTAB uses the “preponderance of the
`
`evidence” standard such that a Petition must show that any claim asserted to
`
`
`
`4
`
`Page 4
`
`
`
`be unpatenable is proven to be unpatentable by a “preponderance of the
`
`evidence.” I take that to mean that the 00102 and 00103 Petitions must
`
`prove that it is more likely than not that each challenged claim is
`
`unpatentable.
`
`9.
`
`I understand that the factors considered in determining the ordinary
`
`level of skill in the art include the level of education and experience of
`
`persons working in the field; the types of problems encountered in the field;
`
`and the sophistication of the technology. I believe that one of ordinary skill
`
`in the art would have had a bachelor’s degree in electrical engineering or its
`
`equivalent, or at least 5 years of experience in manufacturing or engineering,
`
`with significant exposure to the digital content distribution and/or e-
`
`commerce industries.
`
`10. Based on my industry and teaching experience, and based on my
`
`review of the state of the art at the time of the filing of the patent, I believe
`
`that I would qualify as an expert in the area of data storage and access
`
`systems such that I am qualified to opine on what those of ordinary skill in
`
`the art would have understood at the time of the filing of the patent and what
`
`he/she would or would not have been motivated to do.
`
`11. Petitioner has alleged that “payment data” should be construed to
`
`mean “data representing payment made for requested content data” and is
`
`
`
`5
`
`Page 5
`
`
`
`distinct from “access control data.” See, for example, 000102 Petition at 22.
`
`However, I believe that “payment data” in the context of the ‘221 patent
`
`should be interpreted to mean “data that can be used to make payment for
`
`content.” I understand that in interpreting “payment data” (and all the other
`
`terms of the patent), the PTAB uses a “broadest reasonable interpretation”
`
`standard. I have done so in coming to the opinions set forth herein.
`
`12. For example, the ‘221 patent, col. 20, lines 59-62, states “payment
`
`data for making a payment … is received from the smart Flash card by the
`
`content access terminal and forwarded to an e-payment system.” That is, the
`
`“payment data” is for making a payment. Further, in Figure 12c of the ‘221
`
`patent, step S54 reads “PAYMENT FOR SCHEME OWNER RECEIVED
`
`FROM CARD BY CONTENT ACCESS TERMINAL AND
`
`FORWARDED TO e-PAYMENT SYSTEM.” Step S55 then reads
`
`“PAYMENT RECORD DATA RECEIVED FROM e-PAYMENT
`
`SYSTEM BY CONTENT ACCESS TERMINAL AND FORWARDED TO
`
`CARD.” Both of those steps precede step S56 which recites “PAYMENT
`
`RECORD DATA, PURCHASE REQUEST AND CARD REGISTRATION
`
`DATA TRANSMITTED TO SCHEME OWNER.” Thus, “payment data” is
`
`not “data representing payment made for requested content data,” as
`
`payment has not yet been made when the payment data of step S54 is
`
`
`
`6
`
`Page 6
`
`
`
`sent. Therefore, I believe Petitioner’s requested claim construction for
`
`“payment data” should not be adopted, and “payment data” should be
`
`interpreted to mean “data that can be used to make payment for content.”
`
`
`
`III. Claims 1 and 12 of the ‘221 patent
`
`13.
`
`Independent claim 1 of the ‘221 patent recites:
`
`1. A data access terminal for retrieving data from a data
`supplier and providing the retrieved data to a data carrier, the
`terminal comprising:
`a first interface for communicating with the data supplier;
`a data carrier interface for interfacing with the data
`carrier;
`a program store storing code implementable by a
`processor; and
`a processor, coupled to the first interface, to the data
`carrier interface and to the program store for implementing the
`stored code, the code comprising:
`code to read payment data from the data carrier and to
`forward the payment data to a payment validation system;
`code to receive payment validation data from the
`payment validation system;
`code responsive to the payment validation data to retrieve
`data from the data supplier and to write the retrieved data into
`the data carrier.
`
`
`
`
`
`7
`
`Page 7
`
`
`
`14.
`
`Independent claim 12 recites:
`
`12. A method of providing data from a data supplier to a data carrier,
`
`the method comprising:
`
`reading payment data from the data carrier;
`
`forwarding the payment data to a payment validation system;
`
`retrieving data from the data supplier; and
`
`writing the retrieved data into the date carrier.
`
`
`
`
`
`B. Overview of Features of Stefik ‘235 and ‘Stefik ‘980
`
`15. As described in Stefik ‘235, col. 7, lines 35-42, “The file information
`
`for a document is comprised of a ‘contents file’ and a ‘description file.’ The
`
`contents file is stored independently from the description file. The ‘contents’
`
`file is a stream of addressable bytes whose format depends completely on
`
`the computer based system used to play, display or print the document. The
`
`description file contains the usage rights for the document and a pointer to
`
`the document in the content part.”
`
`16. Stefik ‘980 describes “Finally, in the usage rights language, various
`
`‘things’ will need to interact with each other. For example, an instance of a
`
`usage right may specify a bank account, a digital ticket, etc. Such things
`
`
`
`8
`
`Page 8
`
`
`
`need to be identified and are specified herein using the suffix ‘-ID.’” Col.
`
`19, lines 5-9.
`
`
`
`C. Obviousness in Light of Stefik ‘235 and Stefik ‘980
`
`17. The Decision held that “Petitioner does not persuasively establish it is
`
`more likely than not that either Stefik ’980 or Stefik ’235 discloses a system
`
`using repositories in the same form and order as in claims 1, 11, 12, and 32.”
`
`Decision at 14.
`
`18. However, the Decision further held “In light of the arguments and
`
`evidence, Petitioner has established that it is more likely than not that claims
`
`1, 11, and 12 are unpatentable as obvious over the combined teachings of
`
`Stefik ’235 and Stefik ’980. See ’102 Pet. 41–69.” Decision at 15. For the
`
`reasons set forth below, I do not believe that the 00102 Petition has shown
`
`that it is more likely than not that Stefik ‘235 and Stefik ‘980, either alone or
`
`in combination, would have rendered obvious claims 1, 11, and 12 to one of
`
`ordinary skill in the art, as of the earliest foreign and domestic priority dates
`
`of the ‘221 patent.2
`
`
`2 For the purposes of this declaration, it does not matter whether a priority
`
`date of Oct. 25, 1999 or Oct. 25, 2000 is used.
`
`
`
`9
`
`Page 9
`
`
`
`1.
`
`Claims 1 and 11
`
`19.
`
`In its analysis of claim 1, the 00102 Petition is inconsistent with
`
`regard to those elements of Stefik that it alleges correspond to the “data
`
`carrier” of the ‘221 patent. In the context of “code to read payment data
`
`from the data carrier and to forward the payment data to a payment
`
`validation system,” the 00102 Petition alleges on page 54:
`
`Stefik discloses transaction functions performed by a processor (e.g.,
`
`processor element 1201) implementing code (e.g., software
`
`instructions utilized by the processor element 1201) including
`
`encrypted forwarding (transmission) of payment data read from the
`
`data carrier (e.g., a repository such as a DocuCard) to a payment
`
`validation system (e.g., a credit server). The payment data forwarded
`
`to the payment validation system (e.g., a credit server) includes
`
`transaction identifiers, identifiers for repositories involved in the
`
`transaction, and lists of charges for the transaction.
`
`20. Still in the context of “code to read payment data from the data carrier
`
`and to forward the payment data to a payment validation system” in claim 1,
`
`the 00102 Petition later alleges on page 56 that the data carrier is “(e.g.,
`
`removable card).” It is unclear whether the 00102 Petition is alleging that
`
`this is the same as the DocuCard that it identified earlier.
`
`
`
`10
`
`Page 10
`
`
`
`21.
`
`In the context of “code responsive to the payment validation data to
`
`retrieve data from the data supplier and to write the retrieved data into the
`
`data carrier,” the 00102 Petition first alleges that “Stefik discloses a data
`
`access terminal (e.g., processing element 1201) carrying out a repository
`
`transaction in which it retrieves data from a data supplier (e.g., storage
`
`system 1207) and writes (e.g., transmits) the data to a data carrier (e.g., other
`
`repository communicating through external interface 1206).” 00102 Petition
`
`at 59 - 60. Thus, the data carrier to which the data is allegedly written is not
`
`alleged to be either of the “repository such as a DocuCard” referenced as the
`
`data carrier on page 54, nor is it alleged to be “a removable card” referenced
`
`as the data carrier on page 56. When the 00102 Petition page 60 later
`
`alleges that the “data access terminal (e.g., first repository) then writes (e.g.,
`
`transmits) the data to a data carrier (e.g., third repository) when acting as a
`
`data provider,” it is again indicating that the data carrier to which the data is
`
`allegedly written is not alleged to be either the “repository such as a
`
`DocuCard” referenced as the data carrier on page 54, nor “a removable card”
`
`referenced as the data carrier on page 56.
`
`22.
`
`In the context of “code to read payment data from the data carrier and
`
`to forward the payment data to a payment validation system,” the 00102
`
`Petition on page 54 does not specify which DocuCard is being read from and
`
`
`
`11
`
`Page 11
`
`
`
`which is acting as a data carrier, only that “transaction identifiers, identifiers
`
`for repositories involved in the transaction, and lists of charges for the
`
`transaction” are read from it. Nor does the 00102 Petition identify what the
`
`“transaction identifiers, identifiers for repositories involved in the
`
`transaction, and lists of charges for the transaction” are.
`
`23. Page 55 of the 00102 Petition also cites col. 6, line 63 - col. 7, line 2
`
`of Stefik ‘235 as disclosing “In this case, the user of the DocuCard is
`
`logging onto the DocuCard. This logging in process may also activate credit
`
`accounts.” Page 56 later alleges “Stefik discloses that logging in and
`
`activating a credit account grants access to read (e.g., retrieve) payment data
`
`(e.g., bank and credit account information) that is stored on the data carrier
`
`(e.g., removable card) and assign fees against the account associated with
`
`the payment data.” However, there is no disclosure of what it means to
`
`“activate credit accounts,” and neither the 00102 Petition nor Mr.
`
`Wechselberger clearly define what this is supposed to mean, let alone show
`
`how “logging in and activating a credit account grants access to read (e.g.,
`
`retrieve) payment data (e.g., bank and credit account information) that is
`
`stored on the data carrier (e.g., removable card).”
`
`24. Moreover, with respect to assigning payments, col. 6, line 66 - col. 7,
`
`line 2 of Stefik ‘235 also states “The user on the DocuCard now uses the
`
`
`
`12
`
`Page 12
`
`
`
`user interface to assign payment of any fees associated with the transaction
`
`to be executed, step 303. The fees may be assigned to either the user of the
`
`DocuCard or to the owner of the repository.” This, however, does not mean
`
`that any payments are actually made at that point or even that any fees are
`
`yet known. As shown in Figure 3, cited by the 00102 Petition on page 55,
`
`step 303 is “User Assigns Payment of Fees.” This, however, happens before
`
`step 304 (“User Selects Desired Function”) and step 305 (“User Selects
`
`Desired Document”). As such, no fee information is known in step 303
`
`because no document or function has yet been selected that might incur a
`
`fee. The 00102 Petition alleges that “Bank account information is later
`
`transmitted along with fee charges to a payment system (e.g., credit server).”
`
`Page 56. However, this does not allege that such bank account information
`
`is read from the DocuCard that the user just logged into, nor that it is
`
`identical to the Petition’s alleged “payment data read from the data carrier
`
`(e.g., a repository such as a DocuCard).” Page 54.
`
`25. Thus, I do not believe that the 00102 Petition has shown that it is
`
`more likely than not that Stefik ‘235 and Stefik ‘980, either alone or in
`
`combination, renders obvious claim 1 (and its dependent claims 2 and 11).
`
`
`
`
`
`13
`
`Page 13
`
`
`
`2.
`
`Claim 12
`
`26. The 00102 Petition makes similar arguments with respect to claim 12.
`
`In the step “reading payment data from the data carrier,” the 00102 Petition
`
`identifies the data carrier as both “a repository such as a DocuCard” and “a
`
`removable card”. Page 65. However, with respect to “writing the retrieved
`
`data into the data carrier,” the data carrier is identified as (1) a “requesting
`
`repository” (page 68) (2) a “repository communicating with the processing
`
`element” (page 69), or (3) a “second repository” (page 69). Thus, the data
`
`carrier in the “reading” and “writing” steps are not alleged to be the same.
`
`27. Thus, I do not believe that the 00102 Petition has shown that it is
`
`more likely than not that Stefik ‘235 and Stefik ‘980, either alone or in
`
`combination, renders obvious claim 12 (and its dependent claims 13 and 14).
`
`
`
`D. Obviousness of Claims 2, 13, and 14 in Light of Stefik ‘235,
`
`Stefik ‘980, and Poggio
`
`28. Claim 2 depends from claim 1 and further includes “code to transmit
`
`at least a portion of the payment validation data to the data supplier or to a
`
`destination received from the data supplier.” Page 74 of the 00102 Petition
`
`cites to Stefik ‘980 when it alleges that “Stefik discloses sending a portion of
`
`payment validation data (e.g., billing information) to a destination when
`
`
`
`14
`
`Page 14
`
`
`
`document requests are serviced.” However, with respect to claim 1, pages
`
`57-58 of the 00102 Petition allege that “Stefik discloses making the receipt
`
`of payment validation data by the data access terminal (e.g., acceptance of
`
`assigned fees).” The 00102 Petition does not disclose how “billing
`
`information” corresponds to “acceptance of fees” or vice versa, so the 00102
`
`Petition is using “payment validation data” inconsistently such that this
`
`limitation of claim 2 is not taught.
`
`29. The 00102 Petition cites to Stefik ‘980 when it alleges that “Stefik
`
`further discloses examples in which the credit server to which both
`
`repositories in a transaction report the validation data (e.g., billing
`
`information) is an integrated component of a data supplier (e.g., the first of
`
`the repositories).” Page 74. The 00102 Petition further alleges that Stefik
`
`‘980 7:33-36 teaches “Once the digital work has been transmitted to
`
`repository 2, repository 1 and 2 each generate billing information for the
`
`access which is transmitted to a credit server, step 108.” Page 74.
`
`30. However, Stefik ‘980 does not disclose that there is a “credit server to
`
`which both repositories in a transaction report the validation data.” The
`
`sentence immediately after 7:33-36 makes clear that each repository
`
`transmits billing information to a separate credit server by stating “Such
`
`double billing reporting is done to insure against attempts to circumvent the
`
`
`
`15
`
`Page 15
`
`
`
`billing process.” This is confirmed by 17:51-61 which, as the 00102 Petition
`
`even cites, states “For example, when a digital work is copied by one
`
`repository to another for a fee, credit servers coupled to each of the
`
`repositories will report the transaction to the billing clearinghouse. This is
`
`desirable in that it insures that a transaction will be accounted for in the
`
`event of some break in the communication between a credit server and the
`
`billing clearinghouse.” As the undisclosed billing information is not sent to
`
`the same credit server by both repositories, Stefik does not teach the
`
`limitation of claim 2.
`
`31.
`
`In its analysis of claim 2, the 00102 Petition (pages 74-75) alleges that
`
`Poggio discloses that “The data access terminal (e.g., virtual vending
`
`machine) transmits payment validation data (e.g., indication from the
`
`electronic banking network signifying successful completion of the payment
`
`transaction) received from the payment validation system (e.g., electronic
`
`banking network) to a data supplier (e.g., web server; vending information
`
`database),” but does not supply any analysis of how this is shown.
`
`Moreover the citations provided in the 00102 Petition (5:45-47; Fig. 7; 9:56-
`
`10:25; 10:35-37; 10:41-53; 10:54-11:3; 11:13-18) and the text of Mr.
`
`Wechselberger’s declaration do not show how Poggio teaches that an
`
`indication from the electronic banking network signifying successful
`
`
`
`16
`
`Page 16
`
`
`
`completion of the payment transaction that is received from the payment
`
`validation system (e.g., electronic banking network) is transmitted to a data
`
`supplier (e.g., web server; vending information database). The 00102
`
`Petition page 75 similarly provides no additional evidence of where the
`
`alleged teachings are found when it references “Poggio’s advantageous
`
`explicit teachings of a virtual vending machine that connects vendors while
`
`ensuring that vendors are compensated for content (including by providing
`
`them with payment confirmation).”
`
`32. Thus, the 00102 Petition has not shown that it is more likely than not
`
`that claim 2 is obvious in light of the proposed combination of Stefik ‘235,
`
`Stefik ‘980, and Poggio.
`
`33. Claim 13 depends from clam 12 and further recites “receiving
`
`payment validation data from the payment validation system” and
`
`“transmitting at least a portion of the payment validation data to the data
`
`supplier.” Claim 14 depends from claim 13.
`
`34. With respect to “transmitting at least a portion of the payment
`
`validation data to the data supplier,” the 00102 Petition cites the same
`
`portions of Stefik ‘980 and Poggio discussed above with reference to claim
`
`2. Thus, for the reasons described earlier, the 00102 Petition has not shown
`
`
`
`17
`
`Page 17
`
`
`
`that it is more likely than not that claims 13 and 14 are obvious in light of
`
`the proposed combination of Stefik ‘235, Stefik ‘980, and Poggio.
`
`
`
`
`
`E.
`
`Obviousness in Light of Ginter
`
`
`
`1.
`
` Claims 1 and 11
`
`35. With respect to “code to read payment data from the data carrier and
`
`to forward the payment data to a payment validation system,” page 51 of the
`
`00103 Petition cites “audit information” as corresponding to the claimed
`
`payment data.
`
`36. Footnote 18 on page 52 of the 00103 Petition alleges that “To the
`
`extent it is argued that Ginter’s forwarding of audit information does not
`
`necessarily reflect payment for a currently-requested VDE content object,
`
`Ginter at a minimum renders this obvious. Ginter discloses paying for VDE
`
`content objects with ‘real-time debits from bank accounts.’” However, in
`
`the context of Ginter, the audit information is for tracking post-usage
`
`information, not current purchase information. As discussed in the
`
`paragraph crossing cols. 161 and 162, “the clearinghouse may analyze the
`
`contained audit information to determine whether it indicates misuse of the
`
`applicable VDE object 300,” which indicates the tracked usage has already
`
`occurred. Thus, the 00103 Petition has not shown that such post-usage
`
`
`
`18
`
`Page 18
`
`
`
`information to determine whether an applicable VDE object 300 is being
`
`misused corresponds to “payment data” as claimed. Also, to change from
`
`post-usage tracking to pre-purchase processing would change the principle
`
`upon which Ginter works, which I understand indicates nonobviousness.
`
`37. With respect to “code to receive payment validation data from the
`
`payment validation system,” page 55 of the 00103 Petition alleges that “an
`
`administrative response” corresponds to the “payment validation data” and
`
`cites “163:38-61.” Because of the quote that follows, I believe the 00103
`
`Petition intended to cite “162:38-61”. If the 00103 Petition intends that
`
`citation to show that the “administrative response” in 162:38-61 is a
`
`response to the sending of the audit information, it is not.3 As the 00103
`
`
`3 It appears that the 00103 Petition must intend the administrative response
`
`to relate to the audit information as the explanation of the next limitation
`
`(“code responsive to the payment validation data to retrieve data from the
`
`data supplier and to write the retrieved data into the data carrier”) states
`
`“responsive to the payment validation data (e.g., an administrative response
`
`confirming that the transmitted audit information has been validated).” Page
`
`57. It also states in footnote 24 on page 58 “To the extent it is argued that
`
`Ginter’s VDE content object is in some respect not explicitly retrieved
`
`
`
`19
`
`Page 19
`
`
`
`Petition, page 71 even quotes, 162:38-61 relates to “the end user's request
`
`for additional budget and/or permission pertaining to VDE object 300”
`
`which is not post-usage tracking but budgeting for future. It also contradicts
`
`the assertion in footnote 22 on page 55 of the 00103 Petition that a “POSITA
`
`would have understood Ginter’s disclosure of receiving an administrative
`
`response to be a disclosure of receiving data indicating that the payment
`
`validation system has validated the purchase of a VDE content object”
`
`because audit information in Ginter is post-usage. Because of this post-
`
`usage versus pre-purchase distinction, it also would not have been obvious
`
`to use pre-purchase processing, as the principle of operation would have to
`
`be changed.
`
`38.
`
`If the 00103 Petition intended the “administrative response” to relate
`
`to the responsive administrative objects discussed in 162:38-61, that section
`
`does not describe purchases, nor does the 00103 Petition explain why absent
`
`the disclosure of purchases an administrative reply itself would render a
`
`purchase obvious. For example, administrative responses can also be used
`
`in audits, as described above, which are not indicative of purchases either.
`
`
`responsive to Ginter’s administrative response confirming that the
`
`transmitted audit information has been validated.”
`
`
`
`20
`
`Page 20
`
`
`
`39. With respect to “code responsive to the payment validation data to
`
`retrieve data from the data supplier and to write the retrieved data into the
`
`data carrier,” as described above, the cited section (162:38-61) does not
`
`relate to audit information, as alleged, or disclose this limitation. Moreover,
`
`although footnote 24 on page 58 states “To the extent it is argued that
`
`Ginter’s VDE content object is in some respect not explicitly retrieved
`
`responsive to Ginter’s administrative response confirming that the
`
`transmitted audit information has been validated, Ginter at minimum renders
`
`this obvious. Ginter discloses that VDE content objects may be paid for
`
`using ‘real-time debits from bank accounts,’” the 00103 Petition ignores that
`
`“real-time debits” and post-usage audits in Ginter operate using different
`
`principles. It similarly ignores those same pre- and post-usage principles
`
`when it alleges in footnote 24 on page 58 that a “POSITA would have
`
`understood that applying Ginter’s teaching of requiring ‘that sufficient credit
`
`from an authorized source must be confirmed as available’ before a
`
`transaction occurs, when applied to the real-time debit system also disclosed
`
`in Ginter, at minimum renders obvious retrieving data responsive to Ginter’s
`
`administrative response confirming that the transmitted audit information
`
`has been validated.”
`
`
`
`21
`
`Page 21
`
`
`
`40. Thus, I do not believe that the 00103 Petition has shown that it is
`
`more likely than not that Ginter renders obvious claim 1 (and its dependent
`
`claims 2 and 11).
`
`2.
`
`Claim 2
`
`41. Claim 2 depends from claim 1 and further includes “code to transmit
`
`at least a portion of the payment validation data to the data supplier or to a
`
`destination received from the data supplier.”
`
`42. Page 61 of the 00103 Petition alleges that Ginter teaches “transmitting
`
`at least a portion of payment validation data (e.g., the administrative
`
`response) to the data supplier (e.g., external object repository).” The 00103
`
`Petition then cites to 63:34-41, 20:23-29 and 184:34-40 (page 62), but does
`
`not describe how the cited text corresponds to “administrative responses” or
`
`transmitting at least a portion of the administrative responses to the data
`
`supplier or to a destination received from the data supplier.
`
`43. The 00103 Petition appears to recognize that the limitation in question
`
`is not disclosed and asserts that to “the extent it is argued that a portion of
`
`Ginter’s administrative response is in some respect not explicitly transmitted
`
`to Ginter’s external object repository, Ginter at a minimum renders this
`
`obvious.” Footnote 28, page 62. The footnote then discusses “real-time
`
`debits from bank accounts,” but that ignores that the administrative
`
`
`
`22
`
`Page 22
`
`
`
`responses discussed with respect to claim 1 were for post-usage audit
`
`information, not “real-time debits from bank accounts.” Thus, the 00103
`
`Petition is changing the principle of operation of Ginter.
`
`44. Footnote 28 also confuses “real-time debits from bank accounts” and
`
`“sufficient credit from an authorized source” in that the cited portions are
`
`discussing different embodiments, one using credit and the other using real-
`
`time debit. Thus, again the 00103 Petition is changing the principle of
`
`operation in hindsight having used the claims as a model.
`
`45. Thus, the 00103 Petition has not shown that it is more likely than not
`
`that claim 2 is obvious over Ginter.
`
`
`
`3.
`
`Claim 12
`
`46. With respect to “reading payment data from the data carrier” and
`
`“forwarding the payment data to a payment validation system”, the 00103
`
`Petition alleges at pages 66 and 68 that the payment data corresponds to
`
`“audit information,” where Ginter discloses that “the clearinghouse may
`
`analyze the contained audit information to determine whether it indicates
`
`misuse of the applicable VDE object 300.” Paragraph crossing cols. 161 and
`
`162.
`
`
`
`23
`
`Page 23
`
`
`
`47. However, the 00103 Petition has not shown that such post-usage
`
`information to determine whether an applicable VDE object 300 is being
`
`misused corresponds to “payment data” as claimed. Nor has the 00103
`
`Petition shown that it would have been obvious to change the principle of
`
`operation of Ginter by changing from post-usage tracking to any pre-
`
`purchase processing.
`
`48. Thus, I do not believe that the 00103 Petition has shown that it is
`
`more likely than not that Ginter renders obvious claim 12 (and its dependent
`
`claims 13 and 14).
`
`
`
`4.
`
`Claims 13 and 14
`
`49. Claim 13 depends from clam claim 12 and further recites “receiving
`
`payment validation data from the payment validation system” and
`
`“transmitting at least a portion of the payment validation data to the data
`
`supplier.” Claim 14 depends from claim 13. With respect to the limitation
`
`“transmitting at least a portion of the payment validation data to the data
`
`supplier,” page 72 of the 00103 Petition cites the same arguments discussed
`
`above with respect to claim 2. Thus, for the reasons described earlier, the
`
`00103 Petition has not shown that it is more likely than not that claims 13
`
`and 14 are obvious in light of Ginter.
`
`
`
`24
`
`Page 24
`
`
`
`
`
`50.
`
`I hereby acknowledge that any willful false statement made in this
`
`declaration is punishable under 18 U.S.C. 1001 by fine or imprisonment of
`
`not more than five (5) years, or both.
`
`
`
`
`
`
`
`Executed this 26th day of February, 2015.
`
`____________________________
`
`
`
`
`
`
`
`
`
`Jonathan Katz, Ph.D.
`
`
`
`25
`
`Page 25
`
`
`
`
`
`
`
`
`APPENDIX A
`
`APPENDIX A
`
`Page 26
`
`Page 26
`
`
`
`Jonathan Katz
`Department of Computer Science and UMIACS
`University of Maryland
`jkatz@cs.umd.edu
`
`Education
`
`Ph.D. (with distinction), Computer Science, Columbia University, 2002
`Dissertation: Efficient Cryptographic Protocols Preventing “Man-in-the-Middle” Attacks
`Advisors: Z