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

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