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-00811
`U.S. Patent No. 8,856,539
`________________
`
`PATENT OWNER’S EXHIBIT 2001
`DECLARATION OF MARKUS JAKOBSSON
`IN SUPPORT OF PATENT OWNER’S PRELIMINARY RESPONSE
`
`06943-00002/10301550.3
`
`USR Exhibit 2001
`
`
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`APPLE INC.
`Petitioner,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC
`Patent Owner
`________________
`
`Case IPR2018-00811
`U.S. Patent No. 8,856,539
`________________
`
`PATENT OWNER’S EXHIBIT 2001
`DECLARATION OF MARKUS JAKOBSSON
`IN SUPPORT OF PATENT OWNER’S PRELIMINARY RESPONSE
`
`06943-00002/10301550.3
`
`USR Exhibit 2001
`
`
`
`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
`
`Preliminary Response. 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-00811, U.S. Patent No. 8,856,539, and its file history, and all
`
`other materials cited and discussed in the Petition (including the declaration of Dr.
`
`Victor Shoup) and cited and discussed in this Declaration. I understand the Petition
`
`asserts that claims 1-3, 5-8, 16-24, 26-30, 37, and 38 are anticipated by European
`
`Patent Application 1,028,401 A2 (Ex. 1030, “Schutzer”) under 35 U.S.C. § 102,
`
`and claims 12, 31, and 34 are obvious in view of Schutzer under 35 U.S.C. § 103
`
`(together “the Challenged Claims”).
`
`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.
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 1
`
`
`
`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. 2002.
`
`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
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 2
`
`
`
`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
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 3
`
`
`
`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
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 4
`
`
`
`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.
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 5
`
`
`
`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:
`
`• the levels of education and experience of persons working in the
`
`field;
`
`• the types of problems encountered in the field; and
`
`• the sophistication of the technology.
`
`16. A person of ordinary skill in the art (“POSITA”) relevant to the ’539
`
`patent at the time of the invention would have a Bachelor of Science degree in
`
`electrical engineering, 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 two years of work or research experience in related fields.
`
`17.
`
`I have reviewed the declaration of Dr. Victor Shoup, including his
`
`opinions regarding the Person of Ordinary Skill in the Art. Ex. 1002 at ¶¶ 65-66.
`
`My description of the level of ordinary skill in the art is essentially the same as that
`
`of the Dr. Shoup, except that Dr. Shoup’s description requires two years of work or
`
`research experience (as compared to three years). The opinions set forth in this
`
`Declaration response would be the same under either my or Dr. Soup’s proposal.
`
`18.
`
`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
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 6
`
`
`
`of at least ordinary skill in the art at the time of the priority date of the ’539 patent
`
`in 2006. 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.
`
`19.
`
`Legal Principles
`
`I am not a lawyer and will not provide any legal opinions. 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.
`
`1.
`
`Anticipation
`
`20.
`
`I understand that to obtain a patent, a claimed invention must have, as
`
`of the priority date, been novel and not anticipated by prior art in the field. I
`
`understand that a claim is anticipated only if each and every element in the claim is
`
`explicitly or inherently found in a single prior art reference.
`
`21.
`
`I understand that implicit and inherent disclosures of a prior art
`
`reference may be relied upon in the rejection of claims for anticipation, so long as
`
`the limitation not expressly disclosed necessarily flows from the teachings of the
`
`prior art reference. I also understand that to be an inherent disclosure the limitation
`
`must necessarily be contained in the prior art reference and the mere fact that the
`
`process, apparatus, or system described in the prior art reference might possibly or
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 7
`
`
`
`sometimes practice or contain a claim limitation is inadequate to establish that the
`
`reference inherently discloses the limitation.
`
`2. My Understanding of Claim Construction Law
`
`22.
`
`I understand that in this inter partes review the claims must be given
`
`their broadest reasonable interpretation, but that interpretation must be consistent
`
`with the patent specification. In this Declaration, I have used the broadest
`
`reasonable interpretation (“BRI”) standard when interpreting the claim terms.
`
`III. OVERVIEW OF THE ’539 PATENT
`
`A.
`
`23.
`
`The ’539 Patent Specification
`
`I have reviewed the ’539 patent. The ’539 patent provides a unique
`
`and highly secure anonymous identification system that uses a time-varying
`
`multicharacter code for both verifying the identity of an entity and also enabling
`
`transactions between the entity and a provider without requiring the entity to share
`
`personal or otherwise sensitive information with the provider. See Ex. 1001 at
`
`2:64-3:1, 3:24-27, 12:19-54. The system allows a person to purchase goods from a
`
`brick and mortar or online merchant without publicly providing credit card
`
`information to the merchant for fear that the credit card information may be stolen
`
`or used fraudulently. See id. at 3:44-54. As another example, the system allows a
`
`person seeking medical treatment to identify themselves before a medical provider,
`
`and also have the system provide insurance data, medical history data, and other
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 8
`
`
`
`medical information to the medical provider once the medical provider has
`
`established itself as an authorized recipient. See id. at 3:55-60.
`
`24. Referring to FIGS. 1 and 3 of the ’539 patent, the system’s main unit
`
`12, which may be connected to a wide area network, includes a database 24 that
`
`stores data entries 30 related to different people or entities. Id. at 7:11-13, 7:40-41.
`
`Each entry 30 may contain different types of information such as, but not limited
`
`to, validation information, access information, publicly available information,
`
`address information, credit card information, medical information, job application
`
`information, and/or tax information. Id. at 7:57-63. The validation information 32
`
`is information about the user and is used by the main unit’s software 18 to validate
`
`that the person attempting to access the information is authorized to receive it. Id.
`
`at 8:10-14. In particular, the validation information 32 contains information that
`
`enables the software 18 to validate a person that has presented the system with a
`
`one-time nonpredictable code uniquely associated with the user. See id. at 8:17-35.
`
`The access information 34 allows different levels of security to attach to different
`
`types of information stored in each entry 30 so that the user can specify which
`
`particular individuals or organizations can have access to what specific data (e.g.,
`
`credit card numbers, medical information, and tax information). See id. at 8:62-
`
`9:11.
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 9
`
`
`
`25. Referring to FIG. 8, one aspect of using the system includes the useful
`
`ability to purchase goods or services from a merchant without revealing to the
`
`merchant account information relating to the user’s credit card. Id. at 9:46-50.
`
`A user desiring to make a purchase at a merchant without providing their financial
`
`information, such as a credit or debit card number, may enter a secret code into
`
`their electronic ID device, which generates a one-time nonpredictable code that is
`
`provided to the merchant. Id. at 12:21-24. The merchant in turn may transmit the
`
`one-time nonpredictable code, a store number, and a purchase amount to the secure
`
`registry. Id. at 12:24-26. The secure registry system may then determine whether
`
`the code received is valid, and if valid, accesses from the secure registry’s database
`
`24 the user’s actual credit card information. See id. at 12:27-29. The secure registry
`
`system next transmits to the credit card company the credit card number, the store
`
`number, and the purchase amount. Id. at 12:29-31. The credit card company then
`
`processes the transaction, such as by checking the credit worthiness of the person,
`
`and either declines the card or debits the user’s account and transfers money to the
`
`merchant’s account. Id. at 12:40-43. The credit card company notifies the secure
`
`registry system the transaction result and the secure registry system may in turn
`
`notify the merchant. Id. at 12:43-46.
`
`26.
`
`Thus, the ’539 patent’s USR system provides a secure anonymous
`
`identification system that uses a time-varying multicharacter code for both
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 10
`
`
`
`verifying the identity of an entity and also enabling transactions between the entity
`
`and a provider, such as a merchant, without requiring the entity to share personal
`
`or otherwise sensitive information with the provider. In one case, this allows a user
`
`to purchase goods or services from a merchant without providing the merchant the
`
`user’s credit card number. Advantageously, the system also allows such secure
`
`transactions to be transparent to the credit card company and thus requires no or
`
`minimal cooperation from the credit card company to implement.
`
`27. Besides purchase transactions, the technology described in the ’539
`
`patent can be applied to a host of other applications that can benefit from secure
`
`identity verification systems and distributed secure data storage. As one example,
`
`such a system allows a patient to obtain medical treatment from a medical care
`
`provider without having to directly supply the medical care provider her medical
`
`history, which may not be with the patient herself. According to another example,
`
`the user may facilitate shipment of goods purchased from a merchant without
`
`having to provide the merchant their shipping address.
`
`B.
`
`28.
`
`The ’539 Patent Claims
`
`The ’539 patent includes 38 claims. Claims 1, 22, 37, and 38 are
`
`independent. I have reviewed the claims in detail.
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 11
`
`
`
`IV. OVERVIEW OF THE ASSERTED PRIOR ART REFERENCE
`SCHUTZER
`
`29.
`
`Schutzer discusses a method and system for securely performing a
`
`bankcard transaction utilizing an alternate card number. Ex. 1030, Schutzer at
`
`[0002].
`
`30. Referring to FIG. 1 of Schutzer, a user 2 desiring to make an online
`
`purchase at a merchant 4, first sends a request to her financial card’s (e.g., credit
`
`card) issuing bank 8 requesting an anonymous, alternate card number that she can
`
`use to make her purchase. See, e.g., id. at [0025], [0026]. The issuing bank 8
`
`authenticates the user and sends the user 2 the alternate card number linked to the
`
`user’s actual card number, which the user 2 then forwards to the merchant server
`
`12. See id. Alternatively, the user 2 can instruct the issuing bank 8 to send the
`
`alternate card number directly to the merchant server 12. See id. at [0028]. In
`
`another aspect, the issuing bank 8 may install software at the user’s computing
`
`device 10 that can generate the alternate card number for the user 2 after the user 2
`
`authenticates herself with the software. See id. at [0030]. After obtaining the
`
`alternate card number the user 2 sends the alternate card number to the merchant 4.
`
`See id. at [0031].
`
`31. After receiving the alternate card number, the merchant 4 sends the
`
`alternate card number to the merchant acquiring server 18 and requests
`
`authorization. See, e.g., id. at [0027], [0031]. A close review of Schutzer reveals
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 12
`
`
`
`that Schutzer does not disclose that the merchant 4 sends anything but the alternate
`
`card number to the acquiring bank server 18 with its authorization request. The
`
`acquiring bank server 18 then sends an authorization request to the issuing bank
`
`server 14 over a card association network 20. See id. at [0027], [0032]. The issuing
`
`bank server 14 includes an authorization processor 26 that receives the request,
`
`links the alternate card number to the user’s actual account for authorization, and
`
`then sends an authorization for the alternate card number to the merchant acquiring
`
`bank’s server 18 over the card association network 20. Id. at [0027]. In the case
`
`where the alternate card number was generated by software at the user’s computing
`
`device 10, the issuing bank server’s number generator 24 generates the next
`
`number in sequence synchronized to the cardholder's software 30 and links the
`
`alternate card number to the actual card number before providing the actual card
`
`number to the authorization processor 26 for authorization processing. See id. at
`
`[0032].
`
`32.
`
`The issuing bank server’s authorization processor 26 then sends the
`
`authorization to the merchant acquiring bank server 18 over the card association
`
`network 20. Id. at [0027], [0032]. The issuing bank 8 does not send the
`
`authorization directly to the merchant 4. The acquiring bank’s server 18 in turn
`
`sends the authorization for the transaction to the merchant server 12, which then
`
`completes the transaction with the user 2. Id.
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 13
`
`
`
`33.
`
`Schutzer describes how the alternate card number is generated on a
`
`per transaction basis, and as such, it can be used by the issuing bank 8 to “keep
`
`track of where (over what channel) and to whom (what merchant number was
`
`used).” Id. at [0063]. For example, if the alternate number was requested at the
`
`user’s electronic wallet 28, and supplied to the merchant 4 over the internet, “then
`
`the issuing bank 8 can identify and keep track of which purchases were made over
`
`the Internet and with which merchants.” Id.
`
`V.
`
`CLAIM CONSTRUCTION
`
`34.
`
`I understand that Petitioner has identified seven terms that they allege
`
`require construction. Pet. at 14-22. Their construction for these terms do not impact
`
`my opinion in this declaration.
`
`35.
`
`Petitioner does not provide an express construction of “the third
`
`party” in its Petition, but in applying the prior art Petitioner interprets the claim
`
`such that the secure registry system is the third party. See Pet. at 37, 51, 60, 62. In
`
`my opinion, Petitioner’s interpretation of “the third party” is contrary to the plain
`
`language of the claims and the specification of the ’539 patent.
`
`36. As explained below, in my opinion, a POSITA would understand that
`
`“the third party” should be construed to mean “a party other than the entity, the
`
`provider, and the secure registry.”
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 14
`
`
`
`A.
`
`37.
`
`“The Third Party” (All Challenged Claims)
`
`I understand that all four independent claims of the ’539 patent recite
`
`the term “the third party.” It is my opinion that, consistent with the context of the
`
`claims in which the term appears, and consistent with the specification, one skilled
`
`in the art would understand that “the third party” should be construed to mean “a
`
`party other than the entity, the provider, and the secure registry.”
`
`38. My opinion is supported by the context of the claims. For example, all
`
`four claims also recite “a secure registry,” “a provider,” and “an entity.” Ex. 1001
`
`at 18:29-60 (claim 1); 20:4-31 (claim 22); 21:25-22:13 (claim 37); 22:14-40 (claim
`
`38). If the term “third party” was interpreted as meaning any one of these other
`
`parties already recited, such as the secure registry, the term would be duplicative
`
`and effectively lose its purpose and meaning. Moreover, Petitioner’s interpretation
`
`of the third party being the secure registry would also lead to the strange result that
`
`the claims would require that the secure registry provide itself the account
`
`identifying information which it already has possession of. Such a reading would
`
`not make much sense.
`
`39. My opinion is also consistent with the specification, where the secure
`
`registry provides the account identifying information to a third party that is not one
`
`of the other existing parties (i.e., not the user, provider, or secure registry itself).
`
`For example, FIGS. 7, 8, and 9 (FIG. 7 shown below) teach that the secure registry
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 15
`
`
`
`may access and then transmit the user’s credit card or bank account number to the
`
`credit card company (CCC) or bank, respectively. Ex. 1001 at 11:61-65; 12:29-31;
`
`13:3-7; FIG. 7 (708); FIG. 8 (808); FIG. 9 (908). The processes described also
`
`include a user entity, a provider (a merchant in the given examples), and a secure
`
`registry that perform different functions from the third party CCC or bank. See id.
`
`at FIGS. 7-9. Thus, in these examples neither the CCC nor the bank is the user
`
`entity, the provider, or the secure registry, and instead the CCC and the bank are
`
`separate third parties that receive the account identifying information from the
`
`secure registry. See id.
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 16
`
`
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 17
`
`
`
`40. Consequently, it is my opinion that construing “third party” to mean “a party
`
`other than the entity, the provider, and the secure registry” is proper because it is
`
`consistent with the plain meaning of the term, the context of the claims, and also
`
`the specification.
`
`II.
`
`SCHUTZER FAILS TO ANTICIPATE ANY CLAIM OF THE ’539
`PATENT
`
`41.
`
`In my opinion, Petitioner has not shown that the claims of the ’539
`
`patent are invalid for a variety of reasons. One of these reasons affects all four
`
`independent claims, and their respective dependent claims, and is thus fatal.
`
`A.
`
`Schutzer Fails to Disclose Receiving a Transaction Request
`Including a Time-Varying Multicharacter Code and an Indication
`of the Provider (Limitations 1[b] and 22[a]).
`
`42.
`
`I understand that independent claims 1 and 22 of the ’539 patent
`
`specify that a transaction request is received that includes a time-varying
`
`multicharacter code and an indication of the provider as shown below:
`
`• “[secure registry system processor configured to] receive a transaction
`
`request including at least the time-varying multicharacter code for the
`
`entity on whose behalf a transaction is to be performed and an
`
`indication of the provider requesting the transaction.” (limitation
`
`1[b]);
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 18
`
`
`
`• “receiving a transaction request including at least the time-varying
`
`multicharacter code for an entity on whose behalf a transaction is to
`
`take place and an indication of the provider requesting the
`
`transaction.” (limitation 22[a]).
`
`Ex. 1001 at 18:39-43; 20:9-12.
`
`43.
`
`In my opinion the Petition has failed to show that Schutzer explicitly
`
`or implicitly discloses the above claim limitations.
`
`44.
`
`First, the Petition states that the same item in Schutzer, namely the
`
`alternate card number, represents both the claimed time-varying multicharacter
`
`code and an indication of the provider. Petition at 33. The Petition’s logic is that
`
`because Schutzer discusses that the issuing bank 8 may use the alternate card
`
`number to keep track of where and to whom payment was made, the alternate card
`
`number should be double counted as both the time-varying multicharacter code and
`
`the indication of the provider. Petition at 32-33 (citing Ex. 1030 ¶¶ [0031], [0032],
`
`and [0063]). I disagree and think this argument should be rejected.
`
`45.
`
`I strongly believe that the language of the claims require that the
`
`transaction request received include two different values: a time-varying
`
`multicharacter code and an indication of the provider. Ex. 1001 at 18:39-43; 20:9-
`
`12. This is evidenced to me not only because the claims recite two distinct
`
`components as being included in the transaction request, but also because the
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 19
`
`
`
`specification and drawings consistently show that two distinct values representing
`
`the time-varying multicharacter code and the indication of the provider are
`
`included in a message from the merchant to the secure registry. See, e.g., Ex. 1001
`
`at 12:24-26; 12:65-13:1; FIGS. 8, 9.
`
`46.
`
`For example, FIG. 8 of the ’539 patent clearly shows (step 804) that
`
`the merchant transmits to the secure registry (1) a code from Secure ID, (2) a store
`
`number, and (3) a purchase amount. Id. at FIG. 8 (804). The “code from Secure
`
`ID” represents the claimed time-varying multicharacter code and the “store
`
`number” represents the indication of the provider. These two items are separate
`
`and independent of one another. FIG. 9 similarly supports this conclusion. Further,
`
`the claims do not state that the transaction request received by the secure registry
`
`only includes a time-varying multicharacter code that can be used by the secure
`
`registry, in some limited cases, to track which merchant payment was made to.
`
`47.
`
`Second, even if I assume that such double counting is proper, the
`
`Petition still fails to establish that the alternate card number received at Schutzer’s
`
`issuing bank 8 from the merchant acquiring bank 6 serves as an indication of the
`
`merchant 4.
`
`48.
`
`The Petition sets forth two arguments based on inherency. Both of
`
`these inherency arguments fail because the Petitioner fails to establish that an
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 20
`
`
`
`indication of the provider necessarily results from receipt of the alternate card
`
`number at the issuing bank 8.
`
`49.
`
`Petitioner’s first inherency argument is that “because the request is
`
`ultimately sent back to the merchant, the request for authorization necessarily
`
`includes some indication of who that merchant is.” Petition at 33-34 (citing Ex.
`
`1030 ¶ [0032]) (“[A]n indication of the provider is included in the request for
`
`authorization and/or the alternate card number because the issuing bank is able to
`
`determine where to transmit its authorization signal.”). I strongly disagree.
`
`50.
`
`It is critical to note that the issuing bank 8 in Schutzer never receives
`
`the alternate card number directly from the merchant 4. Neither does it send the
`
`authorization directly to the merchant 4. Instead, the issuing bank 8 receives the
`
`alternate card number from and sends the authorization to the merchant acquiring
`
`bank 6. See Ex. 1030, Schutzer at [0027], [0032]; FIG. 2 (S6, S7); FIG. 4 (S13,
`
`S15). Since the issuing bank 8 engages only with the merchant acquiring bank 8
`
`and not the merchant 4, it may not know who the underlying merchant 4 is with
`
`whom the merchant acquiring bank 6 communicates with. It would also not
`
`necessarily obtain an indication of the merchant simply because the merchant 4
`
`and the merchant acquiring bank 6 communicate with one another. Instead, it is
`
`very possible that the issuing bank 8 only knows the identity and network address
`
`of the merchant acquiring bank 6 with which it communicates with but does not
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 21
`
`
`
`have identity information pertaining to the merchant 4 itself. Therefore, while the
`
`issuing bank 8 may know who the merchant acquiring bank 6 is, and the merchant
`
`acquiring bank 6 may know who the merchant 4 is, the issuing bank 8 does not
`
`necessarily know the identity of the merchant 4 by way of receiving the alternate
`
`card number from the merchant acquiring bank 6.
`
`51.
`
`Petitioner’s second inherency argument is that “[t]he alternate card
`
`number is also the indication of the provider… since it contains some indication of
`
`who the merchant is (such as a merchant number).” Petition at 33 (citing Ex. 1030
`
`¶ [0063]). I again disagree.
`
`52. As an initial matter it is worth noting that despite the Petition’s
`
`claims, the argument advanced by the Petition is not based on an explicit
`
`disclosure or teaching by Schutzer. See Petition at 32 (“The alternate card number
`
`transmitted with the request for authorization also expressly contains an indication
`
`of who the transacting merchant is, and therefore is an ‘indication of the
`
`provider.’” (citing Ex. 1030 ¶ [0063]) (emphasis added)). Having read and reread
`
`Schutzer and paragraph [0063] many times, I can confidently say that no explicit
`
`or express disclosure is made that that the issuing bank 8 receives an indication of
`
`the merchant when it receives the alternate card number. Thus, in my opinion the
`
`Petition’s argument that the issuing bank 8 effectively receives an indication of the
`
`06943-00002/10301550.3
`
`USR Exhibit 2001, Page 22
`
`
`
`provider when it receives the alternate card number or authorization request is
`
`based on inherency.
`
`53.
`
`I understand that the mere fact that something may result from a given
`
`set of circumstances is not sufficient to establish inherency. A close review of
`
`paragraph [0063] of Schutzer reveals that it merely discusses that the alternate card
`
`number “can be used” by the issuing bank 8 to keep track of which purchases were
`
`made with which merchants. It does not disclose that the issuing bank 8 will
`
`always know who the underlying merchant is for every single transaction simply
`
`by way of receiving the alternate card number from the merchant acquiring bank 6.
`
`As discussed below, there are situations where the issuing bank 8 may not know
`
`who the underlying merchant is when it receives the alternate card number from
`
`the merchant acquiring bank 6. This is true even if the alternate card number
`
`happens to be “generated on a per transaction basis.”
`
`54.
`
`Schutzer itself, in FIGS. 1 and 2, describes one such situation where
`
`the issuing bank 8 would not know who the underlying merchant is when it
`
`receives the alternate card number from the merchant even though the alternate
`
`card number would have been generated for only that one transaction. Referring to
`
`FIGS
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
