Case No. IPR2018-00812
`U.S. Patent No. 8,856,539
`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 2108
`DECLARATION OF MARKUS JAKOBSSON
`IN SUPPORT OF PATENT OWNER’S RESPONSE
`
`
`U.S. Patent No. 8,856,539
`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 2108
`DECLARATION OF MARKUS JAKOBSSON
`IN SUPPORT OF PATENT OWNER’S RESPONSE
`
`
`
`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 Patent
`
`Owner 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
`
`Board’s decision in IPR2018-00812 to institute review (Paper 9, “Decision”), the
`
`Petition for Inter Partes Review IPR2018-00812 (Paper 3, “Petition”) filed by
`
`Apple Inc. (“Petitioner”), U.S. Patent No. 8,856,539 (“the ’539 patent”) 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.
`
`3.
`
`I understand that the Board instituted review as to whether claims 1-3,
`
`5-8, 16-24, 26-30, and 37-38 (“Challenged Claims”) would have been 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. Decision, 5, 19. For the
`
`reasons stated herein, I conclude that the Challenged Claims would not have been
`
`obvious.1
`
`1 I understand that on August 17, 2018, prior to the Board instituting this inter
`
`partes review, the Patent Owner disclaimed claims 5-8, 17-20, and 26-30. Ex.
`
`USR Exhibit 2108, Page 1
`
`
`
`4.
`
`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.
`
`I.
`
`QUALIFICATIONS
`5.
`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. 2004.
`
`6.
`
`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 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.
`
`7.
`
`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
`
`2110. Accordingly, I understand that these claims did not exist at the time of
`
`institution and are not addressed in this Declaration.
`
`USR Exhibit 2108, Page 2
`
`
`
`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
`
`electronic payment schemes, authentication and privacy.
`
`8.
`
`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
`
`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.
`
`9.
`
`From 2004 to 2016, I held a faculty position at 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
`
`USR Exhibit 2108, Page 3
`
`
`
`group focused on online fraud and countermeasures, resulting in over 50
`
`publications and two books.
`
`10. 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.
`
`11. 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 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.
`
`12.
`
`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
`
`USR Exhibit 2108, Page 4
`
`
`
`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.
`
`13.
`
`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.
`
`14.
`
`I have authored five books and over 100 peer-reviewed publications,
`
`and have been a named inventor on over 100 patents and patent applications.
`
`15. My work has included research in the area of electronic payments,
`
`applied security, privacy, cryptographic protocols, authentication, malware, social
`
`engineering, usability and fraud.
`
`USR Exhibit 2108, Page 5
`
`
`
`II.
`
`LEGAL UNDERSTANDING
`A.
`The Person of Ordinary Skill in the Art
`16.
`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.
`
`17.
`
`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.
`
`18. 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/or computer science and two years of work or
`
`research experience in related fields.
`
`USR Exhibit 2108, Page 6
`
`
`
`19.
`
`I have reviewed the declaration of Dr. Victor Shoup, including his
`
`opinions regarding the Person of Ordinary Skill in the Art. Ex. 1102, ¶ 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 would be the same under either my or Dr. Shoup’s proposal.
`
`20.
`
`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.
`21.
`
`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
`
`22.
`
`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
`
`USR Exhibit 2108, Page 7
`
`
`
`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.
`
`23.
`
`I understand it its Petitioner’s burden to prove that the Challenged
`
`Claims would have been obvious.
`
`24.
`
`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
`
`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.
`
`25.
`
`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.
`
`26.
`
`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
`
`USR Exhibit 2108, Page 8
`
`
`
`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.
`
`Claim Construction
`
`27.
`
`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.
`The ’539 Patent Specification
`28.
`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, ’539
`
`patent 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
`
`USR Exhibit 2108, Page 9
`
`
`
`information to the merchant for fear that the credit card information may be stolen
`
`or used fraudulently. See Ex. 1101, ’539 patent at 3:44-54
`
`29.
`
`FIG. 1 depicts one embodiment of the USR system:
`
`USR Exhibit 2108, Page 10
`
`
`
`30.
`
`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, ’539 patent 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. Ex. 1101, ’539 patent 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, ’539 patent 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, ’539 patent
`
`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, ’539 patent at 8:62-9:11
`
`USR Exhibit 2108, Page 11
`
`
`
`31.
`
`FIG. 8 depicts an embodiment of using the USR system “to purchase
`
`goods or services from a merchant without providing the merchant with the user's
`
`credit card number.” Ex. 1101m ’539 patent at 12:47-50.
`
`USR Exhibit 2108, Page 12
`
`
`
`32. 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 (any type of electronic device that may
`
`be used to obtain access to the USR database (Ex. 1101, ’539 patent 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, ’539 patent 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, ’539 patent 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, ’539 patent 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, ’539 patent 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, ’539 patent at 12:43-46.
`
`33. 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
`
`USR Exhibit 2108, Page 13
`
`
`
`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. Id. 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. Id.
`
`B.
`34.
`
`The ’539 Patent Claims
`The ’539 patent has four independent claims: 1, 22, 37 and 38. All of
`
`the claims relate to communicating authentication information from an electronic
`
`ID device.
`
`C.
`35.
`
`Prosecution History of the ’539 Patent
`The ’539 patent issued on October 7, 2014 from U.S. Application No.
`
`11/768,729 (“the ’729 Application”) filed on June 26, 2007. The ’729 Application
`
`is a continuation application of U.S. Application No. 09/810,703 filed on March
`
`16, 2001, now U.S. Patent No. 7,237,117. The ’539 patent was subject to a
`
`thorough examination. See Exs. 1105-1125. During prosecution, the Applicant
`
`and the Examiners discussed the application and prior art in detail, both through
`
`paper submissions and telephonic interviews. See Exs. 1105-1124. Claim
`
`amendments were made to further distinguish the invention from the prior art.
`
`USR Exhibit 2108, Page 14
`
`
`
`Ultimately, the Examiners allowed the claims of the ’539 patent (Ex. 1125 at 5; Ex.
`
`1128 at 5.) over a large body of cited prior art. See Ex. 1101, ’539 patent at 1-3.
`
`IV. OVERVIEW OF THE ASSERTED PRIOR ART
`A.
`Reber (Ex. 1131)
`36.
`Petitioner’s primary reference (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, reproduced below, is an example of the data reader
`
`and the network access apparatus at the user location (Ex. 1131, Reber).
`
`37. 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 2108, Page 15
`
`
`
`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 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”).
`
`38.
`
`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.
`
`39. Moreover, computer 20 has personal
`
`information about
`
`the
`
`consumer/entity initiating a transaction:
`
`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
`
`USR Exhibit 2108, Page 16
`
`
`
`the transaction, the item, a party associated with the item, and a
`charge amount for the transaction.
`
`Additionally, the computer 20 can initiate an action to be
`performed based upon the transaction. Examples of actions include,
`but are not limited to, sending an item to the party, preparing an item
`for pick-up by the party, providing a service for the party, accounting
`that a bill has been paid by the party, or sending a receipt to the party.
`
`Ex. 1131, Reber at 5:33-44.
`
`40.
`
`For example, as disclosed above, computer 20 must have the
`
`consumer/entity’s name and address in order to send them an item. Under
`
`Petitioner's own construction, such information constitutes “account identifying
`
`information.” See Pet. at 16 (according to Petitioner, “the term “account
`
`identifying information” as used in the ’539 patent means “personal information
`
`about an entity such as name, address, or account number”).
`
`41.
`
`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. And like the first
`
`embodiment, Reber’s second embodiment discloses sending “account identifying
`
`information” of the second party user to the first party merchant, including “a
`
`name associated with the second party,” “an address associated with the second
`
`USR Exhibit 2108, Page 17
`
`
`
`party,” and an “electronic address associated with the second party.” Ex. 1131,
`
`Reber at 6:17-26.
`
`42. 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.
`43.
`
`Franklin (Ex. 1132)
`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 temporary transaction 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. Id.; 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. Ex. 1132, Franklin 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 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
`
`USR Exhibit 2108, Page 18
`
`
`
`protocols, including seeking authorization from the issuing institution to honor the
`
`card number.”).
`
`V.
`
`CLAIM CONSTRUCTION
`44.
`I understand that Petitioner has identified six terms that purportedly
`
`require construction. Pet., 12-17. I understand that Patent Owner contends
`
`construction of these terms is not necessary to resolve the matters raised here. I
`
`understand that the Board has agreed with Patent Owner’s position. Op. at 7.
`
`Notwithstanding the fact that Patent Owner believes that the six terms identified by
`
`the Petition do not need construction, I understand that Patent Owner contends that
`
`the below terms, which Petitioner does not proffer a construction for, should be
`
`construed as set forth below.
`
`A.
`45.
`
`“The Provider Requesting The Transaction” (Claims 1 and 22)
`Independent claims 1 and 22 of the ’539 patent each require the secure
`
`registry system receive a transaction request that includes an indication of “the
`
`provider requesting the transaction.” On the limited record and arguments before it
`
`at the institution stage, the Board stated that “[t]he claim language does not
`
`mandate that the provider ‘requesting a transaction’ play any role in generating the
`
`transaction request or passing it to the secure registry. Instead, it indicates simply
`
`that the provider desires to have the transaction completed.” Pet. at 11.
`
`USR Exhibit 2108, Page 19
`
`
`
`46.
`
`I respectfully disagree. In my opinion “the provider requesting the
`
`transaction” should be construed to mean “the provider that sent the transaction
`
`request.” Upon a review of the fuller record, including the claim language and
`
`specification, it is apparent that this construction should be adopted.
`
`47.
`
`In my opinion, the plain language of the claims strongly supports
`
`Patent Owner’s construction. For example, the claims recite that the secure
`
`registry “receive[s] a transaction request” that indicates “the provider requesting
`
`the transaction”:
`
`a 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.
`Ex. 1101 (‘539 patent) at 18:38-44 (Claim 1), 20:9-14 (Claim 22). In my opinion,
`
`one skilled in the art would understand that the provider requests the transaction by
`
`sending a transaction request. Thus, in my opinion, one skilled in the art would
`
`understand that the provider requesting the transaction refers to the provider that
`
`sent the transaction request.
`
`48. Other claim language also supports Patent Owner’s positions. For
`
`example, both claims 1 and 22 recite that the secure registry enables a transaction
`
`between a “provider” and an “entity.” Ex. 1101 (‘539 patent) at 18:28-33 (Claim
`
`1), 22:4-8 (Claim 22). The claims identify the “entity” as the party on whose
`
`USR Exhibit 2108, Page 20
`
`
`
`“behalf” the transaction is requested and the “provider” as the party “requesting the
`
`transaction.” Ex. 1101 (‘539 patent) at 18:38-44 (Claim 1), 20:9-14 (Claim 22).
`
`This language further confirms that the provider is not merely a party that desires
`
`to have the transaction completed on its behalf, but rather the provider is the party
`
`that makes the transaction request.
`
`49.
`
`I understand that at the institution stage, the Board was presented with
`
`and focused on the claim language—not the specification. I understand that the
`
`PTO determines the scope of claims not solely on the basis of the claim language,
`
`but by considering the claim language in light of the specification. When reading
`
`the claims in view of the specification, in my opinion, it is clear that Patent
`
`Owner’s construction should be adopted. The specification consistently discloses
`
`that the provider (e.g., a merchant) sends the claimed transaction request. For
`
`example, FIGS. 7-10, and the corresponding written description, all disclose that
`
`the merchant sends a transaction request that includes a time-varying code from the
`
`electronic ID device and an indication of the merchant sending the transaction
`
`request. See, e.g., Ex. 1101 (’539 patent) at 11:56-65 (“merchant transmit… (1)
`
`the code from the electronic ID device, (2) the store number”), 12:24-26 (same),
`
`12:62-13:2 (same), 13:35-40 (same); see also id. at Figs. 7-10 (steps 704, 804, 904,
`
`1002). Thus, in my opinion, the specification, like the language of the claims,
`
`USR Exhibit 2108, Page 21
`
`
`
`confirms that the provider requesting the transaction is the provider that sent the
`
`transaction request. See id.
`
`B.
`
`50.
`
`“Access Restrictions For The Provider To [Secure Data / At Least
`One Portion Of Secure Data]” (Claims 1, 22 and 37)
`Independent claims 1 and 22 of the ’539 patent each require that the
`
`secure registry determine compliance with “access restrictions for the provider to
`
`secure data.” Ex. 1101 (‘539 patent) at 18:45-50 (Claim 1), 20:16-20 (Claim 22).
`
`Similarly, Claim 37 of the ’539 patent recites “access restrictions for the provider
`
`to at least one portion of secure data.” Ex. 1101 (‘539 patent) at 22:1-4 (Claim 37).
`
`Patent Owner contends the terms “access restrictions for the provider to [secure
`
`data / at least one portion of secure data]” should be construed to mean “two or
`
`more restrictions specific to the provider that indicate what secure data may or may
`
`not be accessed.”
`
`51.
`
`The plain
`
`language of
`
`the claims supports Patent Owner’s
`
`construction. For example, the claim language indicates that the secure registry
`
`determines whether the provider requesting the transaction complies with access
`
`restrictions in place for the secure data (or portions of secure data) before the
`
`secure data is accessed/released. See Ex. 1101 (‘539 patent) 18:45-50, 20:16-20;
`
`22-1-4. In my opinion this language confirms to one skilled in the art that the
`
`“access restrictions” indicate what requested data may or may not be accessed.
`
`Further, by reciting “access restrictions” (plural) and that the access restrictions are
`
`USR Exhibit 2108, Page 22
`
`
`
`“for the provider,” the claim language makes clear that there are “two or more
`
`restrictions specific to the provider.”
`
`52.
`
`In my opinion, the specification of the ’539 patent also confirms that
`
`the claimed “access restrictions” are specific to the provider and that they are used
`
`to indicate what secure data may or may not be accessed. For example, the ’539
`
`patent discloses that “access information 34” stored in each entry 30 of the secure
`
`registry’s database 24 allows “different levels of security to attach to different
`
`types of information stored in the entry 30” so that the user can specify which
`
`providers can have access to select, specific data such as credit card numbers,
`
`medical information, and tax information. See Ex. 1001 at 8:62-9:11; FIGS. 1, 3;
`
`see also id. at 9:1-6 (“The “universal identifiers for those selected individuals,
`
`companies, organizations and/or agencies may be entered into appropriate fields in
`
`the Access information [34] to specify to the USR software 18 those individuals to
`
`whom the address information may be released.”), 14:26-33 (“Access to the
`
`address information 38 is restricted by a rule or other appropriate entry in the
`
`access information 34 of the user’s entry…”). Similarly, the specification
`
`discloses that access restrictions are specified by the user for each type of secure
`
`data entered into the secure registry, and that the access restrictions entered by the
`
`user for each type of data are subsequently used to determine whether the provider
`
`requesting the transaction “has the right to access the type of requested data.” Id.
`
`USR Exhibit 2108, Page 23
`
`
`
`11:17-28 (“For each type of data entered, the person is asked to specify the type of
`
`access restrictions and/or whom should be allowed to 25 access the advanced
`
`personal data (510).”), 10:40-47 (“The process of determining the requestor’s
`
`rights (602) typically involves validating the requestor’s identity and correlating
`
`the identity, the requested information and the access information 34 provided by
`
`the person to the USR database.”), Figs. 5-6. If the secure registry determines that
`
`the requester has rights to access the type of data requested, the secure registry
`
`instructs the database 24 to enable access to the type of requested data. Id. at
`
`10:49-52.
`
`C.
`53.
`
`“Third Party” (All Challenged Claims)
`The ’539 patent includes four independent claims
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
