IPR2018-00812
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`Patent Owner
`________________
`
`Case IPR2018-00812
`U.S. Patent No. 8,856,539
`________________
`
`PATENT OWNER’S EXHIBIT 2113
`DECLARATION OF MARKUS JAKOBSSON
`IN SUPPORT OF PATENT OWNER’S REPLY TO OPPOSITION OF
`CONDITIONAL MOTION TO AMEND
`
`USR Exhibit 2113
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`Patent Owner
`________________
`
`Case IPR2018-00812
`U.S. Patent No. 8,856,539
`________________
`
`PATENT OWNER’S EXHIBIT 2113
`DECLARATION OF MARKUS JAKOBSSON
`IN SUPPORT OF PATENT OWNER’S REPLY TO OPPOSITION OF
`CONDITIONAL MOTION TO AMEND
`
`USR Exhibit 2113
`
`
`
`IPR2018-00812
`
`1.
`
`I have been retained on behalf of Universal Secure Registry LLC
`
`(“Patent Owner”) in connection with the above-captioned inter partes review
`
`(IPR). I have been retained to provide my opinions in support of USR’s Reply to
`
`Opposition of Conditional Motion to Amend. I am being compensated for my time
`
`at the rate of $625 per hour. I have no interest in the outcome of this proceeding.
`
`2.
`
`In preparing this declaration, I have reviewed and am familiar with the
`
`Petition for IPR2018-00812, U.S. Patent No. 8,856,539 (hereinafter “’539 patent”),
`
`and its file history, and all other materials cited and discussed in the Petition
`
`(including all prior art references cited therein) and all other materials cited and
`
`discussed in this Declaration including the Conditional Motion to Amend, Paper 21
`
`(“Motion”) and Petitioner’s Opposition to the Conditional Motion to Amend, Paper
`
`29 (“Op.”).
`
`3.
`
`The statements made herein are based on my own knowledge and
`
`opinion. This Declaration represents only the opinions I have formed to date. I may
`
`consider additional documents as they become available or other documents that
`
`are necessary to form my opinions. I reserve the right to revise, supplement, or
`
`amend my opinions based on new information and on my continuing analysis.
`
`USR Exhibit 2113, Page 1
`
`
`
`IPR2018-00812
`
`I.
`
`QUALIFICATIONS
`
`4.
`
`My qualifications can be found in my Curriculum Vitae, which
`
`includes my detailed employment background, professional experience, and list of
`
`technical publications and patents. Ex. 2102.
`
`5.
`
`I am currently the Chief of Security and Data Analytics at Amber
`
`Solutions, Inc., a cybersecurity company that develops home and office automation
`
`technology. At Amber, my research studies and addresses abuse, including social
`
`engineering, malware and privacy intrusions. My work primarily involves
`
`identifying risks, developing protocols and user experiences, and evaluating the
`
`security of proposed approaches.
`
`6.
`
`I received a Master of Science degree in Computer Engineering from
`
`the Lund Instituted of Technology in Sweden in 1993, a Master of Science degree
`
`in Computer Science from the University of California at San Diego in 1994, and a
`
`Ph.D. in Computer Science from the University of California at San Diego in 1997,
`
`specializing in Cryptography. During and after my Ph.D. studies, I was also a
`
`Researcher at the San Diego Supercomputer Center, where I did research on
`
`authentication and privacy.
`
`7.
`
`From 1997 to 2001, I was a Member of Technical Staff at Bell Labs,
`
`where I did research on authentication, privacy, multi-party computation, contract
`
`exchange, digital commerce including crypto payments, and fraud detection and
`
`USR Exhibit 2113, Page 2
`
`
`
`IPR2018-00812
`
`prevention. From 2001 to 2004, I was a Principal Research Scientist at RSA Labs,
`
`where I worked on predicting future fraud scenarios in commerce and
`
`authentication and developed solutions to those problems. During that time I
`
`predicted the rise of what later became known as phishing. I was also an Adjunct
`
`Associate Professor in the Computer Science department at New York University
`
`from 2002 to 2004, where I taught cryptographic protocols.
`
`8.
`
`From 2004 to 2016, I held a faculty position at the Indiana University
`
`at Bloomington, first as an Associate Professor of Computer Science, Associate
`
`Professor of Informatics, Associate Professor of Cognitive Science, and Associate
`
`Director of the Center for Applied Cybersecurity Research (CACR) from 2004 to
`
`2008; and then as an Adjunct Associate Professor from 2008 to 2016. I was the
`
`most senior security researcher at Indiana University, where I built a research
`
`group focused on online fraud and countermeasures, resulting in over 50
`
`publications and two books.
`
`9. While a professor at Indiana University, I was also employed by
`
`Xerox PARC, PayPal, and Qualcomm to provide thought leadership to their
`
`security groups. I was a Principal Scientist at Xerox PARC from 2008 to 2010, a
`
`Director and Principal Scientist of Consumer Security at PayPal from 2010 to
`
`2013, a Senior Director at Qualcomm from 2013 to 2015, and Chief Scientist at
`
`Agari from 2016 to 2018. Agari is a cybersecurity company that develops and
`
`USR Exhibit 2113, Page 3
`
`
`
`IPR2018-00812
`
`commercializes technology to protect enterprises, their partners and customers
`
`from advanced email phishing attacks. At Agari, my research studied and
`
`addressed trends in online fraud, especially as related to email, including problems
`
`such as Business Email Compromise, Ransomware, and other abuses based on
`
`social engineering and identity deception. My work primarily involved identifying
`
`trends in fraud and computing before they affected the market, and developing and
`
`testing countermeasures, including technological countermeasures, user interaction
`
`and education.
`
`10.
`
`I have founded or co-founded several successful computer security
`
`companies. In 2005 I founded RavenWhite Security, a provider of authentication
`
`solutions, and I am currently its Chief Technical Officer. In 2007 I founded
`
`Extricatus, one of the first companies to address consumer security education. In
`
`2009 I founded FatSkunk, a provider of mobile malware detection software; I
`
`served as Chief Technical Officer of FatSkunk from 2009 to 2013, when FatSkunk
`
`was acquired by Qualcomm and I became a Qualcomm employee. In 2013 I
`
`founded ZapFraud, a provider of anti-scam technology addressing Business Email
`
`Compromise, and I am currently its Chief Technical Officer. In 2014 I founded
`
`RightQuestion, a security consulting company.
`
`11.
`
`I have additionally served as a member of the fraud advisory board at
`
`LifeLock (an identity theft protection company); a member of the technical
`
`USR Exhibit 2113, Page 4
`
`
`
`IPR2018-00812
`
`advisory board at CellFony (a mobile security company); a member of the
`
`technical advisory board at PopGiro (a user reputation company); a member of the
`
`technical advisory board at MobiSocial dba Omlet (a social networking company);
`
`and a member of the technical advisory board at Stealth Security (an anti-fraud
`
`company). I have provided anti-fraud consulting to KommuneData (a Danish
`
`government entity), J.P. Morgan Chase, PayPal, Boku, and Western Union.
`
`12.
`
`I have authored five books and over 100 peer-reviewed publications,
`
`and have been a named inventor on over 100 patents and patent applications.
`
`13. My work has included research in the area of applied security,
`
`privacy, cryptographic protocols, authentication, malware, social engineering,
`
`usability and fraud.
`
`II.
`
`LEGAL UNDERSTANDING
`
`A.
`
`14.
`
`The Person of Ordinary Skill in the Art
`
`I understand that a person of ordinary skill in the relevant art (also
`
`referred to herein as “POSITA”) is presumed to be aware of all pertinent art, thinks
`
`along conventional wisdom in the art, and is a person of ordinary creativity—not
`
`an automaton.
`
`15.
`
`I have been asked to consider the level of ordinary skill in the field
`
`that someone would have had at the time the claimed invention was made. In
`
`deciding the level of ordinary skill, I considered the following:
`
`USR Exhibit 2113, Page 5
`
`
`
`• the levels of education and experience of persons working in the
`
`IPR2018-00812
`
`field;
`
`• the types of problems encountered in the field; and
`
`• the sophistication of the technology.
`
`16. A person of ordinary skill in the art relevant to the ’539 patent at the
`
`time of the invention would have a Bachelor of Science degree in electrical
`
`engineering and/or computer science, and three years of work or research
`
`experience in the fields of secure transactions and encryption, or a Master’s degree
`
`in electrical engineering and/or computer science and two years of work or
`
`research experience in related fields.
`
`17.
`
`I am well-qualified to determine the level of ordinary skill in the art
`
`and am personally familiar with the technology of the ’539 Patent. I was a person
`
`of at least ordinary skill in the art at the time of the priority date of the ’539 patent
`
`in 2001. Regardless if I do not explicitly state that my statements below are based
`
`on this timeframe, all of my statements are to be understood as a POSITA would
`
`have understood something as of the priority date of the ’539 patent.
`
`B.
`
`18.
`
`Legal Principles
`
`I am not a lawyer and will not provide any legal opinions.
`
`USR Exhibit 2113, Page 6
`
`
`
`IPR2018-00812
`
`19.
`
`Though I am not a lawyer, I have been advised that certain legal
`
`standards are to be applied by technical experts in forming opinions regarding the
`
`meaning and validity of patent claims.
`
`20.
`
`I have been informed and understand that if the Board should accept
`
`Petitioner’s arguments and cancel any of the original issued claims of the ’539
`
`patent, Patent Owner has made a conditional motion to amend to substitute the
`
`canceled claim(s) with corresponding proposed amended claims 39-47, as set forth
`
`in Section III of Ex. 2107 (my declaration in support of Patent Owner’s
`
`Conditional Motion to Amend).
`
`21.
`
`I have been informed and understand that to permit the proposed
`
`substitute claims to be entered, Patent Owner must show, among other things, that
`
`the substitute claims are supported by the written description of the original
`
`disclosure of the patent, as well as any patent application to which the claim seeks
`
`the benefit of priority in this proceeding.
`
`22.
`
`I have been informed by counsel and understand that to satisfy the
`
`written description requirement, the substitute claims must be disclosed in
`
`sufficient detail such that one skilled in the art can reasonably conclude that the
`
`inventor had possession of the claimed invention as of the filing date sought. I
`
`understand that the Patent Owner can show possession of the claimed invention by
`
`USR Exhibit 2113, Page 7
`
`
`
`IPR2018-00812
`
`pointing to such descriptive means as words, structures, figures, diagrams, and
`
`formulas that fully set forth the claimed invention.
`
`23.
`
`I have been informed by counsel and understand that incorporation by
`
`reference is a method by which material from one or more documents may be
`
`integrated into a host document. I understand that material incorporated by
`
`reference is considered part of the written description of the patent that can be used
`
`to show possession of the claimed invention.
`
`24.
`
`I have been informed by counsel and understand that to permit the
`
`proposed substitute claims to be entered, Patent Owner must show, among other
`
`things, that the substitute claims do not introduce new subject matter.
`
`25.
`
`I understand that new matter is any addition to the claims without
`
`support in the original disclosure.
`
`26.
`
`I have been informed by counsel and understand that to permit the
`
`proposed substitute claims to be entered, Patent Owner must show, among other
`
`things, the substitute claims do not broaden the scope of the original claims.
`
`27.
`
`I understand that claims in dependent form are construed to include all
`
`the limitations of the claim incorporated by reference into the dependent claim and
`
`further limit the claim incorporated by reference.
`
`28.
`
`It has been explained to me by counsel for the Patent Owner that in
`
`proceedings before the USPTO, the claims of an unexpired patent are to be given
`
`USR Exhibit 2113, Page 8
`
`
`
`IPR2018-00812
`
`their broadest reasonable interpretation in view of the specification from the
`
`perspective of one having ordinary skill in the relevant art at the time of the
`
`invention. I have considered each of the claim terms using the broadest reasonable
`
`interpretation standard.
`
`III. RESPONSIVE ARGUMENTS TO OPPOSITION
`
`A.
`
`29.
`
`Limitations 39[b], 44[a], 47[b]: “from the provider”
`
`I understand that Petitioner contends that Reber alone or in
`
`combination with Franklin discloses the limitation “from the provider.” I
`
`respectfully disagree.
`
`30.
`
`Petitioner first argues that Reber alone discloses this limitation
`
`because a “POSITA would have found it obvious to configure Reber’s transaction
`
`request to include a first data element containing information about a
`
`merchant/provider…and a second data element containing a time-varying code
`
`corresponding to an entity.” Op. at 4-5 (citing Ex. 1131, Reber at 5:17-19 (first
`
`embodiment), 5:45-59 (second embodiment)). However, Petitioner’s Opposition
`
`provides no motivation to combine Reber’s first and second embodiments with one
`
`another. Instead, Petitioner attempts to incorporate by reference arguments
`
`allegedly made in the Petition and POR Reply. Op. at 5 n.2. I have been informed
`
`that the Rules expressly prohibit this practice.
`
`USR Exhibit 2113, Page 9
`
`
`
`IPR2018-00812
`
`31.
`
`Petitioner next argues that the combination of Reber and Franklin
`
`discloses this limitation. Op. at 5-6. Petitioner provides just two sentences for its
`
`proposed combination that fail to explain what the proposed combination actually
`
`is or why a POSITA would be motivated to make it. See id. Indeed, Petitioner
`
`merely contends that Franklin discloses that a “merchant…submits a request for
`
`authorization…including a proxy transaction number…to the issuing bank front-
`
`end…for processing in conjunction with a third party.” Id. (citing Ex. 1132,
`
`Franklin at 11:33-49, 12:30-32). Petitioner also argues that “[a] POSITA would
`
`have been motivated to combine the disclosures of Reber and Franklin to arrive at
`
`these claim limitations for the same reasons set forth in the Petition and discussed
`
`in Apple’s reply brief.” Op. at 6 (citing Petition at 23-31, 33-35; POR Reply at
`
`§ II(A)(4)).
`
`32.
`
`In its POR Reply, Petitioner argues that it would be obvious to a
`
`POSITA to modify Reber’s first message transmitted from computer 20 to
`
`computer 64 (see Ex. 1131, Reber at 5:17-27) to additionally include an indication
`
`of the provider because Franklin’s acquiring bank verifies that the merchant is a
`
`valid merchant. See Reply at 22-23. Thus, Petitioner attempts to import
`
`functionality of a bank into Reber’s computer 64. However, I believe this
`
`contradicts Petitioner’s prior reliance on computer 64 as merely being an
`
`“intermediary” between the database and third party financial institution, and not a
`
`USR Exhibit 2113, Page 10
`
`
`
`IPR2018-00812
`
`financial institution itself. See POR Reply at 15. In attempting to show that the
`
`prior art satisfies the third party limitation (“account identifying information is
`
`provided to a third party to enable or deny the transaction with the provider”),
`
`Petitioner eliminates computer 64’s role as a financial institution and assigns that
`
`responsibility to a third party as purportedly taught by Franklin. See POR Reply at
`
`15-19. Thus, according to Petitioner, computer 64 is not an acquiring bank or any
`
`other party related to financial institutions that would be incentivized in the same
`
`way to validate a merchant’s identity like Franklin. In my opinion, a POSITA
`
`would not look to Franklin to make such a modification to Reber.
`
`B.
`
`33.
`
`Limitations 39[c] and 46[b]: “time value”
`
`I understand that Petitioner contends that Reber alone or in view of
`
`Franklin renders obvious the limitations “the transaction request including a time
`
`value representative of when the time-varying multicharacter code was generated”
`
`and “extract the time value from the transaction request” (referred to herein as
`
`“time value limitations”). Op. at 6; MTA at B1, B3 (39[c], 46[b]). I believe
`
`Petitioner fails to show that the references disclose these limitations for a number
`
`of reasons.
`
`34.
`
`Petitioner argues that “Reber alone renders this limitation obvious.”
`
`Op. at 7. However, I believe this contention is unsupported because it’s based on
`
`incorrect mischaracterizations of what the prior art discloses. Specifically,
`
`USR Exhibit 2113, Page 11
`
`
`
`IPR2018-00812
`
`Petitioner first contends that Reber’s “transaction data…may contain
`
`information sufficient for either the computer 20…or the computer 64…to
`
`generate transaction records that include, for instance, the date and time of the
`
`transaction.” Op. at 6 (emphasis added) (citing Ex. 1131, Reber at 5:33-38).
`
`However, in my opinion Reber never discloses that the transaction data contains
`
`information sufficient to generate a record that includes a date and time of the
`
`transaction. See Ex. 1131, Reber at 5:33-38. Instead, the cited section of Reber
`
`states that after computer 20 has approved the transaction, computer 20 creates a
`
`record of the already-approved transaction, including data representative of the
`
`date and time of the approved transaction. See id. Thus, Petitioner is wrong when it
`
`asserts that a “POSITA would have understood that to generate such a record, time
`
`information could [] be ‘extracted’ from the transaction data.” Op. at 6. Instead, I
`
`believe a POSITA would conclude that computer 20 creates a date/time record
`
`based on when it approved the transaction, which would be some time after the
`
`transaction data was created and would not be known to the user at the time the
`
`transaction data was created.
`
`35.
`
`Petitioner further argues that “Because the time-varying second data
`
`element is generated concurrent with the time of the transaction, the second data
`
`element could include ‘a time value representative of when the time-varying
`
`multicharacter code was generated.’” Op. at 6-7. But in my opinion Reber does not
`
`USR Exhibit 2113, Page 12
`
`
`
`IPR2018-00812
`
`disclose that its second data element is generated concurrent with the time of the
`
`transaction.1 Moreover, even if it were, Reber does not disclose that the time the
`
`second data element is generated is included with the transaction data. See, e.g.,
`
`Ex. 1131, Reber at 2:58-4:62.
`
`36.
`
`Petitioner next argues that Franklin in combination with Reber
`
`discloses the time value limitations. But Petitioner’s proffered reasoning for why a
`
`POSITA would combine Reber and Franklin is inaccurate and irrelevant. First,
`
`Petitioner argues that “[a] POSITA would have been motivated to combine
`
`Franklin’s known technique of extracting a time value from a received code with
`
`Reber’s code-based transaction system to generate a data record based on received
`
`information.” Op. at 8 (emphasis added). This is not true. I believe Franklin does
`
`not teach extracting a time value from the received code (i.e., MAC value
`
`embedded within the received transaction number). Instead, Franklin’s issuing
`
`bank simply receives the transaction date and time as part of transaction-specific
`
`1 I believe the cited portions of Reber (3:4-8, 3:20-25) say nothing about
`
`the time-varying second data element being generated concurrent with the time of
`
`the transaction. Instead, a POSITA would understand that they discuss how
`
`transaction data is generated at the user location 24 using a data reader 30, and how
`
`a network access apparatus can generate transaction data.
`
`USR Exhibit 2113, Page 13
`
`
`
`IPR2018-00812
`
`data that the merchant provides to it along with the transaction number having the
`
`embedded MAC value. See Ex. 1132, Franklin 5:61-63, 9:40-43, 11:33-36.
`
`37.
`
`Indeed, in my opinion it would prove nearly impossible to extract the
`
`transaction date and time from the received MAC since a POSITA would know
`
`that a MAC is generated using a one-way function, such as a hash function.
`
`Consistent with this, Franklin discloses that the MAC is “preferably” generated
`
`using a hash function that receives as its input the transaction-specific data, such
`
`as the transaction date and time. See Ex. 1132, Franklin at 9:59-67; see also id. at
`
`5:28-36, 6:3-7. Hash functions are one-way functions where the output cannot
`
`reasonably be used to reversibly determine the input values. For this reason, the
`
`issuing bank’s MAC coding and comparator unit 82 in Franklin goes through the
`
`process of deriving a test MAC from the same input values used to generate the
`
`received MAC to make a comparison; the MAC coding and comparator unit 82
`
`does not and cannot “extract” the time value from the received MAC directly, as
`
`Petitioner alleges. See Ex. 1132, Franklin at 12:17-26.
`
`38. Moreover, Franklin explains that the MAC is generated “as a function
`
`of the private key, customer-specific data (e.g., card-holder's name, account
`
`number, etc.) and transaction(cid:173)specific data (e.g., transaction amount, merchant
`
`ID, goods ID, time, transaction date, etc.)” Ex. 1132, Franklin at Abstract. In
`
`my opinion, a POSITA would know that this corresponds to an input that is
`
`USR Exhibit 2113, Page 14
`
`
`
`IPR2018-00812
`
`significantly longer than what can be represented in 4 to 6 decimal digits. See
`
`Ex. 1132, Franklin at 8:1-4, 9:65-67. Thus, as the input is longer than the output,
`
`the generation of the MAC corresponds to a many-to-one function, meaning that it
`
`is not only computationally impossible to extract a time value from the MAC code,
`
`but also theoretically impossible.
`
`39.
`
`This impossibility presents a problem for Petitioner’s motivation to
`
`combine argument, which is wholly premised on the purported advantages of being
`
`able to extract time information from the received code itself. Op. at 8.
`
`(“Incorporating the time information into Reber’s one-time code would have
`
`increased efficiency since it would have eliminated the need to separately receive
`
`time data with the transaction.”). But as discussed above, in Franklin the time data
`
`(e.g., “transaction time” and “transaction date”) is received separately from the
`
`transaction number containing the MAC: “The authorization request contains [1]
`
`the transaction number and [2] the transaction-specific data,” where the latter
`
`includes the time data. Ex. 1132, Franklin at 5:61-63, 9:40-43; see also id. at
`
`11:33-38. And, as also discussed above, Franklin’s one-way function based, MAC
`
`generation scheme makes it not just practically infeasible, but also theoretically
`
`impossible to extract the time data (or any other input data) from the MAC value
`
`itself. Thus, Petitioner’s proffered reason to combine Reber and Franklin to
`
`achieve this claim limitation—increased efficiency by eliminating the need to
`
`USR Exhibit 2113, Page 15
`
`
`
`IPR2018-00812
`
`separately receive time data and instead “incorporating the time information into
`
`Reber’s one-time code”—is meritless. Consequently, Petitioner fails to establish
`
`why a POSITA would combine Reber and Franklin.
`
`C.
`
`Limitations 39[e]-[f] and 44[d]-[e]: “validate an identity of the
`provider and then execute a restriction mechanism…”
`
`40.
`
`I understand that Petitioner contends that Reber alone or in view of
`
`Franklin renders obvious the limitation “validate an identity of the provider and
`
`then execute a restriction mechanism….” Op. at 8; MTA at B1-B3 (39[e]-[f],
`
`44[d]-[e]). I respectfully disagree.
`
`41.
`
`First, Petitioner fails to provide a thorough, meaningful analysis of the
`
`purported unpatentability of this claim limitation. Petitioner’s entire discussion of
`
`this limitation consists of repeated, generalized statements about what a POSITA
`
`would have understood based on Reber’s discussion of a user sending a merchant a
`
`PIN instead of a card number to prevent “interception” of the card number from
`
`eavesdroppers, (Ex. 1131, Reber at 1:46-49, 2:29-32), and Franklin’s discussion of
`
`dishonest merchants’ unauthorized re-use of credit card numbers. Ex. 1132,
`
`Franklin at 1:39-54. I believe a POSITA would understand that these portions of
`
`Reber and Franklin do not disclose a secure registry that both validates an identity
`
`of a provider and then executes a restriction mechanism to determine compliance
`
`with any access restrictions for the provider to secure data.
`
`USR Exhibit 2113, Page 16
`
`
`
`IPR2018-00812
`
`42.
`
`Petitioner argues that a “POSITA would have found it obvious to use
`
`the received transaction data of Reber to ensure both that the merchant is
`
`trustworthy…and is entitled to access the data needed to conduct the transaction,”
`
`and that “[b]ecause the only data the computer 64 receives about the transaction is
`
`the transaction data (i.e., Reber’s first data element [indication of the provider]
`
`and second data element [time-varying multicharacter code]), a POSITA would
`
`have further understood that the determination of compliance could be made based
`
`on only that received transaction data.” Op. at 9. I respectfully disagree. As
`
`Petitioner already admitted, Reber does not disclose that its computer 64 (alleged
`
`“secure registry”) determines whether a provider has complied with any access
`
`restrictions. See Petition at 36 (“Reber does not expressly mention any restriction
`
`mechanism to determine if the provider has complied with any access
`
`restrictions.”). Moreover, Petitioner’s arguments are flawed because the issue is
`
`not whether Reber’s computer 64 “could” believe a merchant is “trustworthy” or
`
`“entitled to access the data needed to conduct the transaction.” Op. at 9. Instead,
`
`the issue is whether Reber teaches or discloses that its computer 64 validates the
`
`identity of a provider and then, after such validation, executes a restriction
`
`mechanism to determine compliance with access restrictions for the provider to
`
`secure data. A POSITA would understand that Reber’s computer 64 does not.
`
`USR Exhibit 2113, Page 17
`
`
`
`IPR2018-00812
`
`43.
`
`In its Petition, Apple argued that mere merchant validation, as
`
`described in Franklin, satisfied the claim limitation “executing a restriction
`
`mechanism to determine compliance with access restrictions….” Petition at 37
`
`(“Franklin also expressly discloses checking to ensure that the merchant has
`
`complied with access restrictions—and is therefore a valid merchant.”) (citing to
`
`Ex. 1132, Franklin at 11:38-47 (“The acquiring bank validates the authorization
`
`request by verifying that the merchant is a valid merchant...”)). Substitute claims
`
`39 and 44, however, draw an explicit distinction between provider validation and
`
`access restriction compliance by requiring both and specifying that the secure
`
`registry “validate[s] an identity of the provider and then executes a restriction
`
`requirement to determine compliance with any access restrictions….” MTA at B1-
`
`B3. Petitioner’s flawed analysis treats these two different requirements as one and
`
`the same, and ignores the fact that this limitation would subject even a valid
`
`merchant to different access restrictions that limit the merchant’s ability to have
`
`certain information accessed by a third party to perform a transaction.2
`
`2 As I previously explained in my deposition, a gas station may be a valid
`
`merchant that is authorized to submit credit card transactions to a bank. However,
`
`the gas station may be subject to an access restriction that does not allow it to
`
`USR Exhibit 2113, Page 18
`
`
`
`IPR2018-00812
`
`D.
`
`44.
`
`Limitations 47[f], [g]: “public ID code”
`
`I understand that Petitioner alleges that Reber in view of Franklin
`
`further in view of Schutzer renders obvious the limitations “the information
`
`including account identifying information that includes a public ID code that
`
`identifies a financial account number associated with the entity” and “provide the
`
`account identifying information to a third party that uses the public ID code to
`
`obtain the financial account number associated with the entity to enable or deny the
`
`transaction” (referred to herein as “public ID code limitations”). Op. at 15. I
`
`believe this is incorrect.
`
`45.
`
`Petitioner’s flawed reasoning as to the unpatentability of the public ID
`
`code limitations begins with a series of misstatements concerning Reber’s
`
`teachings (emphasized below):
`
`Once the one-time code is validated, the secure registry can
`“direct” a third party to credit and debit accounts associated
`with a financial transaction. Because the direction to credit or
`debit a particular account is passed to a third party, a POSITA
`would have understood that the identifying information, such as
`an account number, must be transmitted over a network
`connection, such as Reber’s electronic network 22. In
`
`submit more than one transaction per day for a given card totaling more than $500.
`
`See Ex. 1137, Jakobsson Depo. 363:4-364:12.
`
`USR Exhibit 2113, Page 19
`
`
`
`IPR2018-00812
`
`Reber…the account number that is passed to the third party is
`the user’s actual account number.
`Op. at 16 (citations omitted). Thus, Petitioner incorrectly asserts that Reber’s
`
`computer 64 (alleged “secure registry”) directs a third party to credit or debit an
`
`account and that Reber’s computer 64 transmits an account number to a third party
`
`for crediting or debiting of the account. Petitioner relies on 6:25-28 of Reber for its
`
`misplaced contentions (Op. at 5, 16), but I believe a POSITA would understand
`
`that this portion of Reber says nothing about a third party or that computer 64
`
`transmits account numbers to a third party. See Ex. 1131, Reber at 6:25-28; see
`
`also Ex. 1137, Jakobsson Depo. Trans. at 434:11-18 (As to the meaning of 6:25-28
`
`of Reber, I testified that the 6:17-18 provides context and makes it “very
`
`clear…The direction is not the third party. The direction must be the computer
`
`performing the task or directing a portion of the computer [64].”)
`
`46. Next, I understand that Petitioner argues that Schutzer’s “alternate
`
`card number” is the claimed “public ID code” because it “is used in place of a
`
`user’s actual credit card number in order to protect sensitive data during
`
`transmission (including transmissions over encrypted payment networks).” Op. at
`
`16. I believe Petitioner fails to acknowledge one critical shortcoming here with
`
`Schutzer: Schutzer’s alternate card number flows from the user 2 to the merchant
`
`4, and then to the card’s issuing bank 8 (via the merchant bank 6). Ex. 1130,
`
`Schutzer at [0026]-[0027], FIGS. 1, 2. Notably, the issuing bank’s server 14 does
`USR Exhibit 2113, Page 20
`
`
`
`IPR2018-00812
`
`not transmit the alternate card number to a third party. See, e.g., id. Indeed,
`
`Schutzer’s issuing bank server 14 does not need to since server 14 is already tasked
`
`with linking the alternate card number to the user’s actual card number and
`
`authorizing the transaction. Id.
`
`47.
`
`In applying the teachings of Schutzer to Reber, I believe a POSITA
`
`would at best understand that the transaction data transmitted from the end user 26
`
`to computer 20 (alleged merchant) or computer 64 (alleged secure registry) would
`
`include an alternate card number in place of the end user’s 26 real card number,
`
`and that Reber’s computer 64 would link this alternate card number to the real card
`
`number before authorizing the transaction. See Ex. 1131, Reber at 4:63-6:28, FIG.
`
`1. This makes sense because, like Schutzer, Reber already discloses that computer
`
`64 (alleged secure registry) is tasked with authorizing the transaction after it
`
`authenticates the end user’s 26 second data element. Id. at 6:17-18 (“The computer
`
`64 authenticates the second data element to allow or disallow the transaction.”).
`
`48.
`
`Petitioner, however, proposes modifying Reber in view of Schutzer in
`
`a radically different (and unsupportable) way. I understand that Petitioner argues
`
`Schutzer would motivate a POSITA to introduce a third party into Reber, and that
`
`Reber’s computer 64 (alleged secure registry)—which is already tasked with
`
`authenticating the end user’s second data element and approving the transaction—
`
`would transmit Schutzer’s alternate card number to the third party for the third
`
`USR Exhibit 2113, Page 21
`
`
`
`IPR2018-00812
`
`party to obtain a real account number and enable the transaction. See Op. at 16-17.
`
`But I believe that to support its motivation to combine argument, Petitioner
`
`mischaracterizes Schutzer. Specifically, Petitioner wrongly contends that “Schutzer
`
`teaches an ‘alternate account number’…that is used in place of a user’s actual
`
`credit card number in order to protect sensitive data during trans
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
