`
`———————
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`———————
`
`Google LLC,
`Petitioner
`
`v.
`
`RFCyber Corp.
`
`U.S. Patent No. 9,189,787
`IPR2021-00955
`_____________________
`
`DECLARATION OF STEPHEN GRAY,
`UNDER 37 C.F.R. § 1.68 IN SUPPORT OF PETITION FOR
`INTER PARTES REVIEW
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 1 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`IPR of U.S. 9,189,787
`
`TABLE OF CONTENTS
`Introduction ......................................................................................... 4
`I.
`Qualifications and Professional Experience ........................................ 9
`II.
`III. Level of Ordinary Skill in the Art ..................................................... 11
`IV. Relevant Legal Standards .................................................................. 12
`V.
`Background of Smart Card Technology for Mobile Phones............. 17
`A. Memory Smart Cards and Microprocessor Smart Cards ......... 18
`B.
`The Smart Card Operating System .......................................... 21
`C.
`Smart Card Specifications ........................................................ 22
`1.
`GlobalPlatform Specifications ................................................. 22
`2.
`EMV Specifications ................................................................. 24
`D.
`Smart Card Initialization and Personalization ......................... 25
`E.
`Prior Art NFC-Enabled Mobile Phone Payments .................... 31
`VI. The ’787 Patent ................................................................................. 33
`A. Overview of the ’787 Patent ..................................................... 33
`1.
`Portable Device ........................................................................ 34
`2.
`Midlet ....................................................................................... 34
`3.
`E-Purse Applet ......................................................................... 35
`4.
`Emulator ................................................................................... 35
`5.
`Smart Card Module .................................................................. 35
`B.
`Prosecution History of the ’787 Patent .................................... 37
`VII. Claim Construction ............................................................................ 39
`A.
`“emulator” ................................................................................ 40
`
`
`
`2
`
`
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 2 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`IPR of U.S. 9,189,787
`
`
`VIII. Ground 1: The challenged claims are obvious over the combination of Staib
`and Chan ............................................................................................ 40
`A.
`Summary of Staib ..................................................................... 40
`B.
`Summary of Chan ..................................................................... 43
`C.
`Reasons to Combine Staib and Chan ....................................... 47
`D. Detailed Analysis ..................................................................... 53
`IX. Conclusion ....................................................................................... 148
`
`
`
`3
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 3 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`I, Stephen Gray, do hereby declare as follows:
`INTRODUCTION
`
`I.
`
`IPR of U.S. 9,189,787
`
`
`
`1. My name is Stephen Gray, and I have been retained by counsel for
`
`GOOGLE LLC (“Google” or “Petitioner”) as a technical expert in connection with
`
`the proceedings identified above. I submit this declaration in support of Google’s
`
`Petition for Inter Partes Review of U.S. Patent No. 9,189,787 (“the ’787 Patent”).
`
`2.
`
`I am being compensated for my work in this matter at my accustomed
`
`hourly rate. I am also being reimbursed for reasonable and customary expenses
`
`associated with my work and testimony in this investigation. My compensation is
`
`not contingent on the results of my study, the substance of my opinions, or the
`
`outcome of this matter.
`
`3.
`
`I have been asked to provide my opinions regarding whether any of
`
`claims 1-2, 4-12, and 14-19 (“Challenged Claims”) are unpatentable as they would
`
`have been obvious to a person having ordinary skill in the art (“POSITA”). It is my
`
`opinion that the Challenged Claims would have been obvious to a POSITA at the
`
`time of alleged invention, in light of the prior art.
`
`4.
`
`In the preparation of this Declaration, I have reviewed the following,
`
`each of which is a type of material that experts in my field would reasonably rely
`
`upon when forming their opinions:
`
`a.
`
`the ’787 Patent, GOOG-1001;
`
`
`
`4
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 4 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`IPR of U.S. 9,189,787
`
`
`
`b.
`
`c.
`
`the prosecution history of the ’787 Patent, GOOG-1002;
`
`U.S. Patent Application Pub. No. 2005/0222961 to Staib et al.
`
`(“Staib”), GOOG-1005;
`
`d.
`
`U.S. Patent No. 7,628,322 to Holtmanns et al. (“Holtmanns”),
`
`GOOG-1006;
`
`e.
`
`U.S. Patent No. 6,481,632 to Wentker et al. (“Wentker”),
`
`GOOG-1007;
`
`f.
`
`g.
`
`U.S. Patent No. 6,005,942 to Chan et al. (“Chan”), GOOG-1008;
`
`U.S. Patent No. 7,669,233 to Pesonen (“Pesonen”), GOOG-
`
`1009;
`
`h.
`
`U.S. Patent No. 6,367,011 to Lee et al. (“Lee”), GOOG-1010;
`
`i. Wolfgang Rankl & Wolfgang Effing, Smart Card Handbook
`
`(Kenneth Cox trans., John Wiley & Sons Ltd., 3d ed. 2002)
`
`(“Smart Card Handbook”), GOOG-1011;
`
`j.
`
`Junko Yoshida, “Chip Makers Still Uncertain of Plunge into
`
`NFC,” Electronic Engineering Times 6 (Nov. 15, 2004)
`
`(“Yoshida”), GOOG-1017;
`
`k.
`
`Philips Semiconductors, Functional Specification: Standard
`
`Card IC MF1 IC S70, Revision 3.1 (Oct. 2002) (describing
`
`MIFARE 1K smart card), GOOG-1018;
`
`
`
`5
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 5 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`IPR of U.S. 9,189,787
`
`
`
`l.
`
`Eric Longo & Jeff Stapleton, PKI Note: Smart Cards, PKI
`
`Forum Newsletter, Apr. 6, 2002, GOOG-1019;
`
`m. Marijke Sas, “Mifare in Action,” Card Technology Today, Mar.
`
`2003, p. 10, GOOG-1020;
`
`n.
`
`U.S. Patent No. 7,350,717 to Conner et al. (“Conner”), GOOG-
`
`1021;
`
`o.
`
`Philips Semiconductor, SmartMX: P5CD036: Secure Dual
`
`Interface PKI Smart Card Controller Revision 1.1, Aug. 27,
`
`2004, GOOG-1022;
`
`p.
`
`Press Release, GlobalPlatform Leads the Way to Cross-Industry
`
`Standardization with Open Platform Version 2.1 (May 16,
`
`2001), at https://globalplatform.org/latest-news/globalplatform-
`
`leads-the-way-to-cross-industry-standardization-with-open-
`
`platform-version-2-1/ (last visited Mar. 24, 2021) (“Press
`
`Release, GlobalPlatform”), GOOG-1023;
`
`q.
`
`GlobalPlatform, Card Specification Version 2.1.1 (Mar. 2003),
`
`GOOG-1024;
`
`r.
`
`GlobalPlatform, Guide to Common Personalization Version 1.0
`
`(Mar. 2003), GOOG-1025;
`
`
`
`6
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 6 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`IPR of U.S. 9,189,787
`
`
`
`s.
`
`Smart Card Alliance, Near Field Communication (NFC) and
`
`Transit: Applications, Technology and Implementation
`
`Considerations (Feb. 2012) (“Smart Card Alliance”), GOOG-
`
`1026;
`
`t.
`
`GlobalPlatform, Concise Guide to Worldwide Implementations
`
`of GlobalPlatform Technology (Feb. 4, 2006) (“GlobalPlatform
`
`Implementation Overview”), GOOG-1027;
`
`u.
`
`Yukari Iwatani Kane, “DoCoMo Launches Phones that Could
`
`Replace Wallets,” Reuters (June 16, 2004), GOOG-1028;
`
`v.
`
`Yukari Iwatani Kane, “DoCoMo Mobile Phones to Double as
`
`Train Pass,” Reuters (Feb. 22, 2005), GOOG-1029;
`
`w.
`
`“JR East to Expand Functions of Mobile Suica Service,” Japan
`
`Econ. Newswire Plus (Sept. 5, 2006), GOOG-1030;
`
`x.
`
`Press Release, PR Newswire Europe, Nokia Ventures
`
`Organization, Nokia Announces the World's First NFC Enabled
`
`Mobile Product for Contactless Payment and Ticketing (Feb. 9,
`
`2005), GOOG-1031;
`
`y.
`
`Ummear Ahmad Khan, Contactless Payment with Near Field
`
`Communication: An Empirical Study in Ubiquitous Computing
`
`
`
`7
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 7 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`IPR of U.S. 9,189,787
`
`
`
`Context (May 2, 2006) (Master thesis, University of OSLO,
`
`Dept. of Informatics), GOOG-1032;
`
`z.
`
`Press Release, Business Wire, Royal Philips Electronics,
`
`Technology Simplifies Travel for Consumers (Apr. 19, 2006),
`
`GOOG-1033; and
`
`aa.
`
`any other document cited in this Declaration.
`
`5.
`
`In forming the opinions expressed within this declaration, I have
`
`considered:
`
`a. the documents listed above; and
`
`b. my own knowledge and experience, including my work experience
`
`in the field of mobile payment techniques, as described below.
`
`6.
`
`I am over 18 years of age and, if I am called upon to do so, I am
`
`competent to testify as to the matters set forth herein. I am willing to provide
`
`testimony about the opinions provided in this declaration if asked to do so.
`
`7.
`
`Although I have attempted to organize the information presented in this
`
`declaration into helpful sections and/or divisions, my opinions are supported by the
`
`information in the declaration in its entirety.
`
`8.
`
`Unless otherwise noted, all emphasis in any quoted material has been
`
`added.
`
`
`
`8
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 8 of 148
`
`
`
`Declaration of Stephen Gray
`
`II. QUALIFICATIONS AND PROFESSIONAL EXPERIENCE
`9. My qualifications and professional experience are described in my
`
`IPR of U.S. 9,189,787
`
`
`
`curriculum vitae, a copy of which can be found in Exhibit 1004. The following is a
`
`brief summary of my relevant qualifications and professional experience.
`
`10. Throughout my career, I have designed, developed, and deployed
`
`computing systems and products related to payment systems. As such, I have
`
`acquired expertise and am an expert in the areas of distributed computing
`
`architecture and design, distributed data management, web-based commerce,
`
`payment techniques, and various programming languages used in the development
`
`of those systems and products.
`
`11. My professional experience demonstrates my expertise with systems
`
`developed to operate in World Wide Web computing environments deployed over
`
`the Internet. For example, in the 1998 to 2000 time period, I served as the CTO for
`
`Sicommnet: an e-Commerce Internet start-up. The firm developed a product that
`
`specialized in procurement for public agencies over the Internet. For another
`
`example, in the 2001-2002 time period, I was the Chief Technology Officer of
`
`Networld Exchange Inc. In both assignments, I was responsible for the design,
`
`development, and deployment of a suite of products that delivered e-Commerce
`
`functions. These functions were provided over the Internet and included product
`
`catalog information display, purchase and/or purchase order creation, order delivery
`
`
`
`9
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 9 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`to fulfillment systems, order status reporting, and interoperability with third party
`
`IPR of U.S. 9,189,787
`
`inventory and pricing systems. The products that I had responsibility for utilized
`
`protocols and technologies common for web-based systems.
`
`12. Additionally, as my curriculum vitae shows, I have performed a
`
`detailed analysis of the competitive environment for retail point-of-sale hardware
`
`and software systems. This analysis included technology, marketing, compensation,
`
`and back office interface issues. I also led the design of an image-assisted remittance
`
`processing system using IBM system components and Sybase relational database in
`
`a client/server architecture for TRW. Additionally, I designed an object-oriented
`
`front end to the database so that the UNIX platform could execute Sybase
`
`applications.
`
`13. My practical experience regarding mobile device computing software
`
`includes development at NTN Communication of a multiplayer game system
`
`operating over mobile phones where issues of data synchronization, event handling,
`
`and centralized control of distributed devices were required. I have been retained in
`
`several matters relating to mobile computing software. For example, I have been
`
`retained in patent and copyright matters involving touch screen user interface
`
`operations on mobile phones, Internet protocol implementation on mobile phones,
`
`and data synchronization between centralized servers and distributed computing
`
`devices.
`
`
`
`10
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 10 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`IPR of U.S. 9,189,787
`
`14.
`
`
`In addition, on several occasions, I have served as an expert witness
`
`where web and Internet protocols and technology analysis were required to render
`
`an opinion. These matters include HyVee v. Inmar Inc., Diet Goal Innovations v.
`
`Chipotle, et al., Enfish, LLC v. Microsoft Corp., et al., Optimize Technology
`
`Solutions, LLC v. Staples, Inc., et al., and others.
`
`15.
`
`In summary, I have extensive familiarity with the field of electronic
`
`payment techniques and mobile computing, and, as I have worked in this field since
`
`the early 2000s, I am familiar with what the state of this field was at the relevant
`
`time of the ’787 Patent and before.
`
`III. LEVEL OF ORDINARY SKILL IN THE ART
`16.
`
`I understand that the level of ordinary skill may be reflected by the prior
`
`art of record and that a person of ordinary skill in the art (“POSITA”) to which the
`
`claimed subject matter pertains would have the capability of understanding the
`
`scientific and engineering principles applicable to the pertinent art.
`
`17.
`
`I understand there are multiple factors relevant to determining the level
`
`of ordinary skill in the pertinent art, including (1) the levels of education and
`
`experience of persons working in the field at the time of the invention, (2) the
`
`sophistication of the technology, (3) the types of problems encountered in the field,
`
`and (4) the prior art solutions to those problems.
`
`18. For purposes of this Declaration, I have been asked to assume an
`
`
`
`11
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 11 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`effective filing date for all claims of the ’787 Patent of September 24, 2006. A
`
`IPR of U.S. 9,189,787
`
`POSITA on and before September 24, 2006 would have had a working knowledge
`
`of mobile payment techniques pertinent to the ’787 Patent, including art describing
`
`mobile payment techniques. A POSITA would have had a bachelor’s degree in
`
`computer science, computer engineering, or an equivalent, and one year of
`
`professional experience relating to mobile payments. Lack of professional
`
`experience can be remedied by additional education, and vice versa.
`
`19. For purposes of this Declaration, in general, and unless otherwise noted,
`
`my statements and opinions, such as those regarding my experience and the
`
`understanding of a POSITA generally (and specifically related to the references I
`
`consulted herein), reflect the knowledge that existed in the field at least as early as
`
`September 24, 2006. Unless otherwise stated, when I provide my understanding and
`
`analysis below, it is consistent with the level of a POSITA on or before the effective
`
`filing date of the ʼ787 Patent.
`
`IV. RELEVANT LEGAL STANDARDS
`20. As already noted, I have been asked to provide my opinions regarding
`
`the validity of the Challenged Claims of the ’787 Patent.
`
`21.
`
`I am not an attorney. In preparing and expressing my opinions and
`
`considering the subject matter of the ’787 Patent, I am relying on certain basic legal
`
`principles that counsel have explained to me. These principles are discussed below.
`
`
`
`12
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 12 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`IPR of U.S. 9,189,787
`
`22.
`
`
`I understand that prior art to the ʼ787 Patent includes patents and printed
`
`publications in the relevant art that predate at least September 24, 2006.
`
`23.
`
`I understand that a claim is unpatentable if it is either anticipated or
`
`rendered obvious by the prior art.
`
`24.
`
`I have been informed by counsel that a patent claim is unpatentable as
`
`anticipated if each element of that claim is present either explicitly or inherently in
`
`a single prior art reference. I have also been informed that, to be an inherent
`
`disclosure, the prior art reference must necessarily disclose the limitation, and the
`
`fact that the reference might possibly practice or contain a claimed limitation is
`
`insufficient to establish that the reference inherently teaches the limitation.
`
`25.
`
`I have been informed that a claimed invention is unpatentable for
`
`obviousness if the differences between the invention 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 to which the subject matter pertains.
`
`I have also been informed by counsel that the obviousness analysis takes into
`
`account factual inquiries including the level of ordinary skill in the art, the scope and
`
`content of the prior art, and the differences between the prior art and the claimed
`
`subject matter.
`
`26.
`
`It is my understanding that the teachings of two or more references may
`
`be combined, if such a combination would have been obvious to one having ordinary
`
`
`
`13
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 13 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`skill in the art. In determining whether a combination based on either a single
`
`IPR of U.S. 9,189,787
`
`reference or multiple references would have been obvious, it is appropriate to
`
`consider whether:
`
` the teachings of the prior art references disclose known concepts combined
`
`in familiar ways;
`
` a person of ordinary skill in the art could implement a predictable variation,
`
`and would see the benefit of doing so;
`
` the claimed elements represent one of a limited number of known design
`
`choices, and would have a reasonable expectation of success by those
`
`skilled in the art;
`
` a person of ordinary skill would have recognized a reason to combine
`
`known elements in the manner described in the claim;
`
` there is some teaching or suggestion in the prior art to make the
`
`modification or combination of elements claimed in the patent; and
`
` the innovation applies a known technique that had been used to improve a
`
`similar device or method in a similar way.
`
`27.
`
`I have also been informed that one of ordinary skill in the art has
`
`ordinary creativity and is not an automaton. I also understand that in considering
`
`obviousness, it is important not to use the benefit of hindsight derived from the patent
`
`being considered.
`
`
`
`14
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 14 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`IPR of U.S. 9,189,787
`
`28.
`
`
`I have been informed by counsel that the Supreme Court has recognized
`
`several rationales for combining references or modifying a reference to show
`
`obviousness of claimed subject matter. Some of these rationales include the
`
`following: (a) combining prior art elements according to known methods to yield
`
`predictable results; (b) simple substitution of one known element for another to
`
`obtain predictable results; (c) use of a known technique to improve a similar device
`
`(method, or product) in the same way; (d) applying a known technique to a known
`
`device (method, or product) ready for improvement to yield predictable results; (e)
`
`choosing from a finite number of identified, predictable solutions, with a reasonable
`
`expectation of success; and (f) some teaching, suggestion, or motivation in the prior
`
`art that would have led one of ordinary skill to modify the prior art reference or to
`
`combine prior art reference teachings to arrive at the claimed invention.
`
`29. While it may be helpful to identify a reason for a combination, I
`
`understand that there is no rigid requirement to find an express teaching, suggestion,
`
`or motivation to combine within the references. When a product is available, design
`
`incentives and other market forces can prompt variations of it, either in the same
`
`field or a different one. If a POSITA can implement a predictable variation,
`
`obviousness likely bars its patentability. For the same reason, if a technique has been
`
`used to improve one device and a POSITA would recognize that it would improve
`
`similar devices in the same way, using the technique would have been obvious. I
`
`
`
`15
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 15 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`understand that a claimed invention is obvious if a POSITA would have had reason
`
`IPR of U.S. 9,189,787
`
`to combine multiple prior art references or add missing features to reproduce the
`
`alleged invention recited in the claims.
`
`30.
`
`I have also been informed by counsel and understand that obviousness
`
`does not require physical combination of components, or bodily incorporation, of
`
`one device into another. Instead, obviousness considers what the combined teachings
`
`would have suggested to a POSITA at the time of the alleged invention.
`
`31.
`
`I have also been informed by counsel and understand that certain
`
`factors, which a Patent Owner has the burden to show, may support or rebut the
`
`obviousness of a claim. I understand that such secondary considerations include,
`
`among other things, commercial success of the patented invention, skepticism of
`
`those having ordinary skill in the art at the time of invention, unexpected results of
`
`the invention, any long-felt but unsolved need in the art that was satisfied by the
`
`alleged invention, the failure of others to make the alleged invention, praise of the
`
`alleged invention by those having ordinary skill in the art, and copying of the alleged
`
`invention by others in the field. I understand that there must be a nexus—a
`
`connection—between any such secondary considerations and the alleged invention.
`
`I also understand that contemporaneous and independent invention by others is a
`
`secondary consideration tending to show obviousness.
`
`32. The analysis in this Declaration is in accordance with the above-stated
`
`
`
`16
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 16 of 148
`
`
`
`Declaration of Stephen Gray
`
`legal principles.
`
`IPR of U.S. 9,189,787
`
`
`
`V. BACKGROUND OF SMART CARD TECHNOLOGY FOR MOBILE
`PHONES
`
`33. A smart card is a type of identification card with an integrated circuit
`
`(IC) embedded in the card for storing and processing data, which can be
`
`transmitted to a card reader via physical contacts on the surface of the card or, in a
`
`contactless card (discussed further below), via a contactless interface, e.g., using
`
`electromagnetic fields. GOOG-1011, 18, 21, 93.
`
`34. The use of contactless smart cards experienced rapid growth in the
`
`1990s. Id. at 7. An important advantage of smart cards over magnetic-stripe cards
`
`is that data on a smart card can be protected against unauthorized access and
`
`manipulation. Id. at 18. Magnetic-stripe cards, in use since the early 1970s, are
`
`limited data cards without any on-board intelligence. The data encoded on the
`
`magnetic stripe is static, meaning once it is written on the stripe during
`
`personalization and the card is issued, it is unchanged until the card is expired and
`
`reissued. Id. at 2-3. This data is read by the point-of-sale (“POS”) device or reader
`
`at the time a transaction is conducted. Because this data never changes while the
`
`card is active, it is susceptible to “skimming” attacks and such cards are easily
`
`counterfeited, particularly for use in unattended transactions. Id. at 969.
`
`35.
`
`In contrast, the data on a smart card can be accessed only after
`
`authentication, which is performed either by hardwired logic or by an operating
`
`
`
`17
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 17 of 148
`
`
`
`Declaration of Stephen Gray
`
`system on the card. As a result, confidential data can be written to the card and
`
`IPR of U.S. 9,189,787
`
`
`
`stored in a manner that prevents that data from ever being read from outside the
`
`card. Such confidential data can be processed only internally by the chip’s
`
`processing unit. Id. at 18-19.
`
`36. Many smart cards are the size and shape of an ordinary magnetic-
`
`stripe credit card. However, by the time RFCyber had filed its earliest patent
`
`application in 2006, smart cards also had been implemented in portable devices,
`
`such as mobile phones, for example, as a subscriber identity module (SIM) card, a
`
`universal integrated chip card (UICC), or a universal SIM (USIM) card attached to
`
`a Near Field Communication (NFC) chip or interface of a mobile handset. See,
`
`e.g., GOOG-1009, 1:34-2:42 (discussing prior art smart cards with secure element
`
`chips “in wireless devices such as mobile phones”); GOOG-1005, ¶¶38-39, 43
`
`(describing a mobile phone with an external security module, such as a USIM,
`
`attached to the phone’s NFC interface); GOOG-1017 (discussing interface between
`
`a mobile handset’s NFC chip and SIM card).
`
`A. Memory Smart Cards and Microprocessor Smart Cards
`37. Smart cards can be divided into two groups: memory cards and
`
`microprocessor cards. GOOG-1011, 6-8.
`
`38. Memory cards are used for data storage and identification
`
`applications. Id. at 8, 19-20. The MIFARE Classic smart card is an example of a
`
`
`
`18
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 18 of 148
`
`
`
`Declaration of Stephen Gray
`
`contactless memory card with read/write and NFC capability. GOOG-1018
`
`IPR of U.S. 9,189,787
`
`
`
`(describing MIFARE 1K smart card); GOOG-1019, 6. First introduced in 1994, the
`
`MIFARE Classic smart card had a hardwired logic chip in which commands were
`
`executed without the need for an on-chip processor. By 2003, MIFARE Classic
`
`cards were widely deployed in mass transit systems and for building access and
`
`employee identification cards. GOOG-1020.
`
`39. Microprocessor cards contain a processor and typically also contain
`
`mask ROM (which contains the chip’s operating system and is identical for all of
`
`the chips in a production run), EEPROM (the chip’s non-volatile memory, where
`
`data and program code can be written to and read under the control of the operating
`
`system), RAM (the processor’s volatile, working memory), and a serial I/O port for
`
`communication to and from the chip. The processor is needed for the enhanced
`
`security required by applications that manipulate or compare data, such as public
`
`key infrastructure (“PKI”) data encryption, Java applets, and electronic purses (i.e.,
`
`stored value cards). GOOG-1011 at 20-21.
`
`40. The SmartMX smart card family, introduced in 2002, is an example of
`
`a microprocessor card with a contactless interface. GOOG-1022, 2. From its
`
`earliest implementation, the SmartMX card architecture provided cryptographic
`
`coprocessors for DES, triple-DES, AES, RSA, and ECC encryption. It also was
`
`designed to support propriety (sometimes called “native”) operating systems as
`
`
`
`19
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 19 of 148
`
`
`
`Declaration of Stephen Gray
`
`well as open-platform solutions, such as Java Card Global Platform.
`
`IPR of U.S. 9,189,787
`
`
`
`41. The SmartMX card also could be configured to emulate the MIFARE
`
`interface. In this mode, a portion of the non-volatile EEPROM memory on the chip
`
`could be accessed by a MIFARE Classic operating system that offered the same
`
`command set and functionality as the MIFARE Classic hardwired logic chip. The
`
`SmartMX card thus offered backward compatibility to support existing reader
`
`infrastructure based on the MIFARE Classic functionality. See GOOG-1022, 2-3.
`
`42. An advantage to the SmartMX card’s dual interface was that it could
`
`emulate the MIFARE interface while at the same time running other contactless
`
`transmission protocols implemented by the user operating system. In this way,
`
`microprocessor-based applications—such as EMV credit, debit, and stored-value
`
`applications—could run on the same card with a transit application using the
`
`MIFARE emulation mode, without interference. See id.
`
`43. All data that passes between the smart card and a terminal or reader is
`
`packaged as an Application Protocol Data Unit (“APDU”). The APDU is like a
`
`digital envelope carrying data. There are two types of APDUs: command APDUs,
`
`which are sent by the reader to the card; and response APDUs, which are sent by
`
`the card to the reader. Every command APDU sent to the card will receive a
`
`corresponding response APDU from the card. GOOG-1011, 421-425.
`
`
`
`20
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 20 of 148
`
`
`
`Declaration of Stephen Gray
`
`
`IPR of U.S. 9,189,787
`
`
`
`The Smart Card Operating System
`
`B.
`44. Like a desktop computer or mobile phone, a microprocessor smart
`
`card runs an operating system. The primary functions of the card operating system
`
`are to control memory access and manage the security functions of the card.
`
`45. Smart card operating systems can be either proprietary or open source.
`
`Examples of open-source operating systems in use by 2003 include Sun
`
`Microsystems’ Java Card operating system, the Multi-Application Operating
`
`System (“Multos”), and Microsoft Windows for Smart Cards. Id. at 302, 322.
`
`46. The Java Card operating system quickly gained popularity. Because
`
`Java was already widely used for programming internet and PC applications, the
`
`Java Card operating system was easy to use. Another advantage was that it offered
`
`write once, run anywhere functionality, meaning that compiled Java code can run
`
`on all platforms that support Java without the need for recompilation.
`
`47. Specifically, programs written in Java are translated into Java
`
`bytecode by a compiler. Java bytecode is simply processor-independent object
`
`code. In a manner of speaking, bytecode is a program consisting of machine
`
`instructions for a virtual Java processor. This processor does not actually exist;
`
`instead, it is simulated by the target processor. This simulation takes place in the
`
`Java Card virtual machine, which is the actual interpreter. The Java Card virtual
`
`machine thus is a simulation of the Java processor on an arbitrary target system.
`
`
`
`21
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 21 of 148
`
`
`
`Declaration of Stephen Gray
`
`The target processor in turn naturally uses native code. The main advantage of this
`
`IPR of U.S. 9,189,787
`
`arrangement is that only the Java Card virtual machine, which is programmed in
`
`native code, has to be ported to a particular target processor. Once this has been
`
`done, the Java bytecode will run on the new system. The Java Card operating
`
`system thus provided for downloading and running Java applets, which are smart
`
`card applications written in Java and executed by the Java Card virtual machine.
`
`Id. at 305, 307-311.
`
`Smart Card Specifications
`
`C.
`48. By the early 2000s, the smart card industry had recognized the need
`
`for an open standard that would provide for inter-operable smart cards across a
`
`variety of hardware and software platforms. To provide greater standardization,
`
`several industry organizations, including GlobalPlatform and EMVCo, released
`
`relevant smart card specifications in the early 2000s.
`
`1. GlobalPlatform Specifications
`
`49.
`
`In 2001, the cross-industry organization GlobalPlatform released the
`
`Open Platform Card Specification version 2.1 (later called GlobalPlatform Card
`
`Specification 2.1), followed by the GlobalPlatform Card Specification 2.1.1 in
`
`2003. GOOG-1023. These specifications were designed to be implemented on
`
`smart cards running any operating system and were widely used for loading and
`
`managing Java-based applications with the Java Card operating system. GOOG-
`
`
`
`22
`
`
`
`
`
`GOOG-1003
`GOOGLE LLC v. RFCYBER CORP. / Page 22 of 148
`
`
`
`Declaration of Stephen Gray
`
`1011, 290.
`
`IPR of U.S. 9,189,787
`
`
`
`50. The Open Platform specification defines the basic architecture of a
`
`multiapplication smart card (i.e., a smart card capable of running multiple
`
`applications). As shown in the figure below, the Java runtime environment forms
`
`the foundation for all applications and provides a hardware-independent interface
`
`and storage space for the data and programs of the various applications.
`
`GOOG-1011, Fig. 5.38 at 291
`(“Basic architecture and components of Open
`Platform”)
`51. As shown in this figure, the card manager is built on top of this
`
`foundation. The card manager can be though