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 2101
`DECLARATION OF MARKUS JAKOBSSON
`IN SUPPORT OF PATENT OWNER’S PRELIMINARY RESPONSE
`
`06943-00002/10335942.2
`
`USR Exhibit 2101
`
`
`________________
`
`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 2101
`DECLARATION OF MARKUS JAKOBSSON
`IN SUPPORT OF PATENT OWNER’S PRELIMINARY RESPONSE
`
`06943-00002/10335942.2
`
`USR Exhibit 2101
`
`
`
`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-00812, 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, and 37-38 (“Challenged Claims”) are
`
`obvious in view of U.S. Patent No. 5,930,767 (Ex. 1131, “Reber”) and U.S. Patent
`
`No. 6,000,832 (Ex. 1132, “Franklin”) under 35 U.S.C. § 103.
`
`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/10335942.2
`
`USR Exhibit 2101, 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. 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
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, 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.
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 3
`
`
`
`10. Agari is a cybersecurity company that develops and 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.
`
`11.
`
`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.
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 4
`
`
`
`12.
`
`I have additionally served as a member of the fraud advisory board at
`
`LifeLock (an identity theft protection company); a member of the technical
`
`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.
`
`13.
`
`I have authored five books and over 100 peer-reviewed publications,
`
`and have been a named inventor on over 100 patents and patent applications.
`
`14. 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.
`
`15.
`
`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/10335942.2
`
`USR Exhibit 2101, Page 5
`
`
`
`16.
`
`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.
`
`17. 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/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/ot computer science and two years of work or
`
`research experience in related fields.
`
`18.
`
`I have reviewed the declaration of Dr. Victor Shoup, including his
`
`opinions regarding the Person of Ordinary Skill in the Art. Ex. 1102 at ¶¶ 61-62.
`
`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. Shoup’s proposal.
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 6
`
`
`
`19.
`
`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 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.
`
`20.
`
`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.
`
`Obviousness
`
`21.
`
`I understand that to obtain a patent, a claimed invention must have, as
`
`of the priority date, been nonobvious in view of prior art in the field. I understand
`
`that an invention is obvious when the differences between the subject matter
`
`sought to be patented and the prior art are such that the subject matter as a whole
`
`would have been obvious at the time the invention was made to a person having
`
`ordinary skill in the art.
`
`22.
`
`I understand that to prove that prior art, or a combination of prior art,
`
`renders a patent obvious, it is necessary to: (1) identify the particular references
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 7
`
`
`
`that singly, or in combination, make the patent obvious; (2) specifically identify
`
`which elements of the patent claim appear in each of the asserted references; and
`
`(3) explain how the prior art references could have been combined to create the
`
`inventions claimed in the asserted claim.
`
`23.
`
`I understand that a patent composed of several elements is not proved
`
`obvious merely by demonstrating that each of its elements was, independently,
`
`known in the prior art, and that obviousness cannot be based on the hindsight
`
`combination of components selectively culled from the prior art to fit the
`
`parameters of the patented invention.
`
`24.
`
`I also understand that a reference may be said to teach away when a
`
`person of ordinary skill, upon reading the reference, would be discouraged from
`
`following the path set out in the reference, or would be led in a direction divergent
`
`from the path that was taken by the applicant. Even if a reference is not found to
`
`teach away, I understand its statements regarding preferences are relevant to a
`
`finding regarding whether a skilled artisan would be motivated to combine that
`
`reference with another reference.
`
`2. My Understanding of Claim Construction Law
`
`25.
`
`I understand that in this inter partes review the claims must be given
`
`their broadest reasonable interpretation, but that interpretation must be consistent
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 8
`
`
`
`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.
`
`26.
`
`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. 1101 at 3:5-
`
`27. As one non-exclusive example, the system, referred to as a Universal Secure
`
`Registry (USR) 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 Ex. 1101 at 3:44-54. As another example, the USR system may
`
`be used by a patient to supply “insurance data, medical history data, and other
`
`appropriate medical information to a medical provider, once that medical provider
`
`has been established as an authorized recipient [of such data].” See Ex. 1101 at
`
`3:55-60. Other non-financial applications are also described such as, but not
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 9
`
`
`
`limited to, using the USR system to provide job application information to select
`
`potential employers authorized by the job applicant. See Ex. 1101 at 10:58-66.
`
`27.
`
`FIG. 1 depicts one possible embodiment of the USR system:
`
`28.
`
`The USR 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. Ex. 1101 at 7:11-13; 7:40-41. Each entry 30 may contain
`
`different types of information such as, but not limited to, validation information,
`USR Exhibit 2101, Page 10
`06943-00002/10335942.2
`
`
`
`access information, publicly available information, address information, credit card
`
`information, medical information, job application information, and/or tax
`
`information. Ex. 1101 at 7:57-63. “The validation information [32] is information
`
`about the user of the database to whom the data pertains and is to be used by the
`
`USR software 18 to validate that the person attempting to access the information is
`
`the person to whom the data pertains or is otherwise authorized to receive it.” Ex.
`
`1101 at 8:10-14. In particular, the validation information 32 contains information
`
`that enables the USR software 18 to validate a person that has presented the system
`
`with a one-time nonpredictable code uniquely associated with the user. See Ex.
`
`1101 at 8:17-35. The access information 34 allows “different levels of security to
`
`attach to different types of information stored in the entry 30” so that the user can
`
`specify which particular individuals or companies can have access to what specific
`
`data such as credit card numbers, medical information, and tax information. See
`
`Ex. 1101 at 8:62-9:11.
`
`29.
`
`FIG. 8 depicts one possible embodiment of using the USR system “to
`
`purchase goods or services from a merchant without revealing to the merchant
`
`account information relating to the person’s bank or credit card.” Ex. 1101 at 9:46-
`
`50.
`
`30. 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
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 11
`
`
`
`secret code into their electronic ID device (any type of electronic device that may
`
`be used to obtain access to the USR database (Ex. 1101 at 8:45-47)), 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 USR. Ex. 1101 at 12:24-26. The USR
`
`may then determine whether the code received is valid, and if valid, accesses from
`
`the USR database the user’s actual credit card information. Ex. 1101 at 12:27-29.
`
`The USR next transmits to the credit card company the credit card number, the
`
`store number, and the purchase amount. Ex. 1101 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. Ex. 1101 at 12:40-43. The credit card company
`
`notifies the USR the transaction result and the USR may in turn notify the
`
`merchant. Ex. 1101 at 12:43-46.
`
`31. Hence, the USR system provides a 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, 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
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 12
`
`
`
`number. Advantageously, the USR 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. As another example, a
`
`user may 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.
`
`B.
`
`32.
`
`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.
`
`IV. OVERVIEW OF THE ASSERTED PRIOR ART REFERENCES
`
`A.
`
`Ex. 1131 –Reber
`
`33. Reber can most accurately be described as a personalized version of
`
`the bar-code checkout system used in stores, and which was common at the time of
`
`the patent’s filing. In particular, Reber discloses a method and system to
`
`authenticate a user “in a transaction based upon machine readable data read by a
`
`data reader at the end user’s location.” Ex. 1131, Reber at 2:24-26. Figure 8 is an
`
`example of the data reader and the network access apparatus at the user location
`
`(Ex. 1131, Reber).
`
`34. As expressly disclosed in Reber, the invention’s improvement over
`
`the prior art was to use a bar code reader rather than existing PIN based systems.
`USR Exhibit 2101, Page 13
`06943-00002/10335942.2
`
`
`
`Id. at 1:48-56 (drawback of prior art’s substitution of PIN for a credit card number
`
`was user having to remember multiple PINs, and PIN can be intercepted), 2:29-31
`
`(time varying bar code for authentication reduces likelihood of interception),
`
`11:23-32 (bar codes relieve user of recalling PIN). This feature is so critical to
`
`Reber that every independent claim in Reber requires that both entities to a
`
`transaction utilize bar codes. See, e.g., Ex. 1131, Reber at Cl. 1 (“first data element
`
`read by a bar code reader . . . indicating a first party of a transaction,” “second data
`
`element read from the member by the bar code reader . . . indicating a second party
`
`to the transaction”).
`
`35.
`
`In a first embodiment, Reber transmits first and second data elements
`
`(“transaction data”) to a local authentication computer 20 or a remote
`
`authentication computer 64 that approves or disapproves the transaction by
`
`comparing the second data element (i.e., the purchaser’s identity) to entries in its
`
`database to determine the authenticity of the transacting party. See Ex. 1131, Reber
`
`at 4:63-5:27. In the first embodiment, the transaction data’s first data element
`
`indicates the item being purchased. Ex. 1131, Reber at 2:58-59. “After approving
`
`the transaction, the computer 20 creates a record of the transaction . . . that
`
`includes data representative of the date of the transaction, the time of the
`
`transaction, the party initiating the transaction, the item, a party associated with the
`
`item, and a charge amount for the transaction.” Ex. 1131, Reber at 5:33-38.
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 14
`
`
`
`36.
`
`In a second embodiment, the authentication computer 64 approves or
`
`denies a transaction between a first party merchant and a second party user based
`
`on the second data element. Ex. 1131, Reber at 5:45-6:40. By contrast to the first
`
`embodiment, in the second embodiment the transaction data’s first data element
`
`indicates the first party merchant. Ex. 1131, Reber at 5:48-50. Notably, in neither
`
`embodiment does Reber disclose that information used to authenticate the user at
`
`the computer 20 or computer 64 is provided to a third party.
`
`B.
`
`37.
`
`Ex. 1132 –Franklin
`
`Franklin can most accurately be described as a backwards compatible
`
`modification of the credit card payment method, in which static credit card
`
`numbers are replaced by time-varying credit card numbers. Specifically, Franklin’s
`
`invention uses a digital “commerce card” assigned by an issuing institution to a
`
`user in place of a typical credit card. See Ex. 1132, Franklin at Abstract, 2:8-10.
`
`This invention was an improvement over prior art because of the ease of
`
`integration into existing merchant and banking systems. Id. at 1:55-64 (new model
`
`“should not usurp these systems, nor require merchants to change their existing
`
`practices”), 1:65-67 (“The inventors have developed a card-based online
`
`commerce system that improves security and integrates with existing card
`
`verification and settlement systems.”). Thus, a merchant would not have to change
`
`its prior practices, i.e., it continued to submit a customer’s credit card information
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 15
`
`
`
`as it always had, such as to the issuing bank. See Ex. 1132, Franklin at 2:43-46
`
`(“merchant handles the proxy transaction number according to traditional
`
`protocols, including seeking authorization from the issuing institution to honor the
`
`card number.”).
`
`V.
`
`CLAIM CONSTRUCTION
`
`38.
`
`I understand that Petitioner has identified six terms that they allege
`
`require construction. Pet. at 12-16. Their construction for these terms do not impact
`
`my opinion in this declaration.
`
`39.
`
`Petitioner does not provide an express construction of “third party” in
`
`its Petition, but in my opinion, a POSITA would understand that “third party”
`
`should be construed to mean “a party other than the entity, the provider, and the
`
`secure registry.”
`
`A.
`
`40.
`
`“Third Party” (All Challenged Claims)
`
`I understand that all four independent claims of the ’539 patent recite
`
`the term “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 “third party” should be construed to mean “a party
`
`other than the entity, the provider, and the secure registry.”
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 16
`
`
`
`41. 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. 1101
`
`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.
`
`42. My opinion is also consistent with the specification, where the third
`
`party to whom account identifying information, such as a credit card or bank
`
`account number, is sent to is a party that is not the user entity, provider, or the
`
`secure registry. For example, FIGS. 7, 8, and 9, and the corresponding written
`
`description, all describe how the secure registry accesses and then transmits the
`
`user’s credit card or bank account number to the credit card company (CCC) or
`
`bank, respectively. Ex. 1101 at 11:61-65; 12:29-31; 13:3-7; FIG. 7 (708); FIG. 8
`
`(808); FIG. 9 (908). The examples described with respect to FIGS. 7, 8, and 9 also
`
`include a user entity, a provider (a merchant in the given examples), and a secure
`
`registry that perform different functions from the 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
`
`parties that receive the account identifying information from the secure registry.
`
`See id.
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 17
`
`
`
`VI. REBER AND FRANKLIN FAIL TO RENDER OBVIOUS ANY
`CLAIM OF THE ‘539 PATENT
`
`43.
`
`In my opinion, Petitioner has not shown that the claims of the ’539
`
`patent are invalid for a variety of reasons.
`
`A. A POSITA Would Not Combine Reber And Franklin
`
`44.
`
`I understand that Petitioner’s sole ground asserts the Challenged
`
`Claims are obvious in view of Reber and Franklin. However, in my opinion,
`
`Petitioner has failed to show a POSITA would combine these references. See
`
`Petition at 23-31. Reber is a personalized version of the bar-code checkout system
`
`used in stores, whereas Franklin is a backwards compatible modification of the
`
`credit card payment method, in which static credit card numbers are replaced by
`
`time-varying credit card numbers. Reber and Franklin are very different from one
`
`another and would not have inspired a POSITA to combine them. Indeed, Reber’s
`
`introduction of new hardware (a bar code reader) completely disrupts the existing
`
`financial transaction landscape, while Franklin expressly discloses its desire to
`
`keep such existing systems intact and unaffected. A POSITA would find these
`
`references are clearly at odds with one another based on such a fundamental
`
`difference in their approaches such that they cannot be reconciled and combined.
`
`1.
`
`Franklin Teaches Away From Reber
`
`45.
`
`I understand that a reference may be said to teach away when a person
`
`of ordinary skill, upon reading the reference, would be discouraged from following
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 18
`
`
`
`the path set out in the reference, or would be led in a direction divergent from the
`
`path that was taken by the applicant. I further understand that if the disclosure
`
`criticizes, discredits, or otherwise discourages the solution claimed, then the
`
`disclosure teaches away and does not demonstrate obviousness. I further
`
`understand that even if a reference is not found to teach away, its statements
`
`regarding preferences are relevant to a finding regarding whether a skilled artisan
`
`would be motivated to combine that reference with another reference.
`
`46. Reber’s invention authenticates a user in a transaction based upon
`
`machine readable data read by a data reader such as a bar code reader. Ex. 1131,
`
`Reber at 2:24-26. This was the invention’s improvement over the prior art because
`
`Reber believed the prior art was fundamentally handicapped due to its reliance on
`
`personal identification numbers (PINs). Ex. 1131, Reber at 1:48-56 (drawback of
`
`prior art’s substitution of PIN for a credit card number was user having to
`
`remember multiple PINs and PIN can be intercepted), 2:29-31 (time varying bar
`
`code for authentication reduces likelihood of interception), 11:23-32 (bar codes
`
`relieve user of burden of recalling PIN).
`
`47.
`
`In contrast, Franklin’s invention uses a digital “commerce card”
`
`assigned by an issuing bank to a user in place of a typical credit card. Ex. 1132,
`
`Franklin at 2:1-11. Franklin touts that one of the major advantages of its invention
`
`is the ease of integration into existing merchant and banking systems. Ex. 1132,
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 19
`
`
`
`Franklin at 2:39-46. Similarly, Franklin impresses upon the reader how any such
`
`transaction system should not disrupt existing card network systems and
`
`merchants. Franklin states:
`
`A further concern that any new online commerce model should integrate
`well with existing proprietary card network systems. There are well-
`established systems that verify credit card purchases and subsequently settle
`accounts. These systems and associated protocols are entrenched in the
`merchant and banking communities and experience a high level of
`acceptance and trust. A new online commerce model should not usurp these
`systems, nor require merchants to change their existing practices to
`implement completely different systems and protocols.
`
`Ex. 1132, Franklin at 1:55-64. Thus, in Franklin’s approach a merchant would not
`
`have to change its existing practices or hardware and instead it would continue to
`
`submit a customer’s card information as it always had, such as to the issuing bank.
`
`See Ex. 1132, Franklin at 2:39-46.
`
`48. While I understand that Petitioner argues that “Reber and Franklin
`
`provide teachings, suggestions, and motivations to combine the two references,”
`
`(Petition at 28-30), in my opinion, a POSITA would find that Franklin teaches
`
`away from Reber for several reasons.
`
`49.
`
`First, as discussed above, Franklin explicitly emphasizes that one of
`
`the advantages of its system is that it integrates into existing merchant and banking
`
`systems without requiring any changes. Ex. 1132, Franklin at 1:55-64 (new model
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 20
`
`
`
`“should not usurp these systems, nor require merchants to change their existing
`
`practices”), 1:65-67 (“The inventors have developed a card-based online
`
`commerce system that improves security and integrates with existing card
`
`verification and settlement systems.”). Thus, a merchant would not have to
`
`change its prior practices, i.e., it continued to submit a customer’s credit card
`
`information as it always had, such as to the issuing bank. See Ex. 1132, Franklin at
`
`2:43-46 (“merchant handles the proxy transaction number according to traditional
`
`protocols, including seeking authorization from the issuing institution to honor the
`
`card number.”). Reber, in direct contrast, replaces existing payment schemes with a
`
`new system that requires additional hardware (e.g., bar code reader) to scan the
`
`user’s information, which is not backwards compatible with existing systems and
`
`requires substantial modification in the merchant’s and card network system’s
`
`protocol. See Ex. 1131, Reber at 3:4-65; FIGS. 1 and 8.
`
`50.
`
`Second, Reber implements anonymity by protecting the user identifier
`
`with a time-varying bar code. See, e.g, Ex. 1131, Reber at 2:29-31 (“To reduce the
`
`likelihood of unauthorized interception of a personal identification code, a time-
`
`varying bar code is used to authenticate the end user.”). Petitioner’s expert admits
`
`this: “Reber describes a system for conducting secure financial transactions
`
`anonymously by utilizing proxy information representing a user.” Ex. 1102, at ¶77
`
`(emphasis added). While Franklin includes the user name in the computation of the
`
`06943-00002/10335942.2
`
`USR Exhibit 2101, Page 21
`
`
`
`temporary credit card number replacement number, Franklin does not suggest
`
`removing or replacing the user name in the input form. In fact, as noted above,
`
`Franklin argues that one must not require merchants to change their existing
`
`practices, which would also include receiving the name and billing address of the
`
`payer, which is standard practice. See Ex. 1132, Franklin at 1:55-64 (“A further
`
`concern is that any new online commerce model should integrate well with
`
`existing proprietary card network systems. There are well-established systems that
`
`verify credit card purchases and subsequently settle accounts. These systems and
`
`associated protocols are entrenched in the merchant and banking communities and
`
`experience a high level of acceptance and trust. A new online commerce model
`
`should not usurp these systems, nor require merchants to change their existing
`
`practices to implement completely different systems and protocols.”). Petitioner’s
`
`expert admits this as well: “Franklin explicitly discloses providing an anonymous
`
`proxy card number to a merchant, which the merchant treats as if it were an actual
`
`card number. Ex-1132 Franklin at 2:38-46 (‘To the merchant, the transaction
`
`number is treated the same as any regular credit card number. The merchant
`
`handles the proxy transaction number according to traditional protocols, including
`
`seeking authorization from the issuing institution to honor the card number.’)” Ex.
`
`1102, at ¶165.
`
`2.
`
`06943-00002/10335942.2
`
`Petitioner’s Reasons Why A POSITA Would Combi
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
