July 9, 2013 appellate brief by Gemalto against Google, Motorola Mobility, Samsung, and HTC, seeking reversal of district court's dismissal of lawsuit accusing Android of infringing embeded JAVA-related patents
July 9, 2013 appellate brief by Gemalto against Google, Motorola Mobility, Samsung, and HTC, seeking reversal of district court's dismissal of lawsuit accusing Android of infringing embeded JAVA-related patents
July 9, 2013 appellate brief by Gemalto against Google, Motorola Mobility, Samsung, and HTC, seeking reversal of district court's dismissal of lawsuit accusing Android of infringing embeded JAVA-related patents
FOR THE FEDERAL CIRCUIT _______________________________________________________________ GEMALTO S.A., Plaintiff-Appellant, v.
HTC CORPORATION, HTC AMERICA, INC., EXEDEA, INC., GOOGLE, INC., MOTOROLA MOBILITY, LLC (also known as Motorola Mobility, Inc.), SAMSUNG ELECTRONICS CO., LTD., and SAMSUNG TELECOMMUNICATIONS AMERICA , LLC, Defendants-Appellees, _______________________________________________________________
Appeal from the United States District Court for the Eastern District of Texas in Case No. 10-CV-0561, Chief Judge Leonard Davis. _______________________________________________________________
NON-CONFIDENTIAL BRIEF FOR PLAINTIFF-APPELLANT GEMALTO S.A. _______________________________________________________________
Robert A. Cote MCKOOL SMITH P.C. One Bryant Park, 47th Floor New York, New York 10036 (212) 402-9400 Dirk D. Thomas MCKOOL SMITH P.C. 1999 K Street, Suite 600 Washington, DC 20006 (202) 370-8302
J oel L. Thollander MCKOOL SMITH P.C. 300 W. 6th Street, Suite 1700 Austin, TX 78701 (512) 692-8735
Attorneys for Plaintiff-Appellant Gemalto S.A. J uly 9, 2013
NON-CONFIDENTIAL Case: 13-1397 Document: 34 Page: 1 Filed: 07/09/2013 i CERTIFICATE OF INTEREST
Counsel for Gemalto S.A. certifies the following:
1. The full name of every party represented by me is:
Gemalto S.A.
2. The name of the real party in interest represented by me is:
Gemalto S.A.
3. All parent corporations and any publicly held companies that own 10 percent or more of the stock of the party represented by me is:
Gemalto N.A.
4. The names of all law firms and the partners or associates that appeared for the party represented by me in the trial court or are expected to appear in this Court are:
McKool Smith P.C.: Robert Auchter, Samuel F. Baxter, Todd Bellaire, Robert A. Cote, Holly E. Engelmann, Laurie L. Fitzgerald, Shahar Harel, Pierre J . Hubert, Radu A. Lelutiu, Christopher J . Mierzejewski Kevin Schubert, Geoffrey L. Smith, J oel L. Thollander, Dirk D. Thomas.
Case: 13-1397 Document: 34 Page: 2 Filed: 07/09/2013 ii TABLE OF CONTENTS
CERTIFICATE OF INTEREST................................................................................i
TABLE OF AUTHORITIES....................................................................................v
STATEMENT OF RELATED CASES................................................................. viii
I. STATEMENT OF J URISDICTION...............................................................1 II. STATEMENT OF THE ISSUES....................................................................1 III. STATEMENT OF THE CASE.......................................................................2 IV. STATEMENT OF FACTS..............................................................................7 A. The Parties.............................................................................................7 B. The Patents-in-Suit................................................................................8 C. The Prosecution History........................................................................9 D. The Patents Do Not Require that All Memory For Storing Converted Applications Be On-Chip and Claim Embodiments that Store Converted Applications in a Mix of On-Chip and Off-Chip Memory. ..............................................................................................11 E. The Patents Do Not Require that the Memory Used by the Processor to Execute Converted Applications Include the Non-Volatile (Permanent) Memory Located Off-Chip..................................................................14 F. The Patents Disclose and Claim Embedded Systems for Non-Smartcard Embodiments.........................................16 G. The Processors Powering Devices that Embody the Claimed Inventions Need Not Be Microcontrollers. ..........................18 H. Gemaltos Inventions Have Had a Dramatic Impact on the World of Mobile Computing........................................18 Case: 13-1397 Document: 34 Page: 3 Filed: 07/09/2013 iii I. Years After the Inventors Managed to Deploy J ava Within the Resource-Constrained Environment of an Embedded System, Googles Android Team Found Itself Vexed by the Same Problem...........................................19 J . The Operation of the Embedded Systems in the Accused Android Smartphones...........................................................21 K. The Markman and Summary J udgment Orders..................................25 V. SUMMARY OF ARGUMENT.....................................................................27 VI. STANDARD OF REVIEW...........................................................................31 VII. ARGUMENT.................................................................................................32 A. The District Court Erred in Granting Summary J udgment of Noninfringement Based on Its Incorrect Constructions of the Claim Terms Programmable Device, Integrated Circuit Card, and Microcontroller..............................................................32 1. The broader term programmable device is not coextensive with the narrower term microcontroller......................................................................32 2. The all program memory limitation should not have been imported into the claims. ..................................37 B. Even if Its Constructions for the Relevant Claim Terms Were Correct (And They Are Not), The District Court Erred in Granting Summary J udgment on Gemaltos Doctrine of Equivalents Arguments. ..........................................................................................45 VIII. CONCLUSION AND RELIEF REQUESTED.............................................48
Case: 13-1397 Document: 34 Page: 4 Filed: 07/09/2013 iv TABLE OF AUTHORITIES Page(s) CASES Absolute Software, Inc. v. Stealth Signal, Inc., 659 F.3d 1121 (Fed. Cir. 2011) ..........................................................................31 Accent Packaging, Inc. v. Leggett & Platt, Inc., 707 F.3d 1318 (Fed. Cir. 2013) ...........................................................................3 Am. Med. Sys., Inc. v. Biolitec, 618 F.3d 1354 (Fed. Cir. 2010) .........................................................................35 Anderson v. Liberty Lobby, Inc., 477 U.S. 242 (1986)............................................................................................31 Brilliant Instruments, Inc. v. GuideTech, LLC, 706 F.3d 1342 (Fed. Cir. 2013) ...................................................................46, 47 Brookhill-Wilk 1, LLC v. Intuitive Surgical, Inc., 334 F.3d 1294 (Fed. Cir. 2003) .........................................................................42 Burke, Inc. v. Bruno Indep. Living Aids, Inc., 183 F.3d 1334 (Fed. Cir. 1999) .........................................................................32 Crown Packaging Tech., Inc. v. Rexam Bev. Can Co., 559 F.3d 1308 (Fed. Cir. 2009) ....................................................................30, 45 Cybor Corp v. FAS Techs., Inc., 138 F.3d 1448 (Fed. Cir. 1998) ..........................................................................31 Deere & Co. v. Bush Hog, LLC, 703 F.3d 1349 (Fed. Cir. 2012) ...................................................................passim Gemalto S.A. v. HTC Corp., 2012 U.S. Dist. LEXIS 89764 (J une 28, 2012 E.D. Tex.) ..................................5 Golight, Inc. v. Wall-Mart Stores, Inc., 355 F.3d 1327 (Fed. Cir. 2004) .........................................................................42 Grober v. Mako Products, Inc., 686 F.3d 1335 (Fed. Cir. 2012) .........................................................................41 Case: 13-1397 Document: 34 Page: 5 Filed: 07/09/2013 v Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111 (Fed. Cir. 2004) .........................................................................35 In re Rambus Inc., 694 F.3d 42 (Fed. Cir. 2012) .............................................................................41 Intl Visual Corp. v. Crown Metal Mfg. Co., 991 F.2d 768 (Fed. Cir. 1993) ...........................................................................32 Kara Tech. Inc. v. Stamps.com, 582 F.3d 1341 (Fed. Cir. 2009) .........................................................................36 Kress Corp. v. Alexander Servs., 1998 U.S. App. LEXIS 12742 (Fed. Cir. J une 15, 1998) ..................................42 Nazomi Commcns, Inc. v. ARM Holdings, PLC, 403 F.3d 1364 (Fed. Cir. 2005) .........................................................................28 On-Line Techs., Inc. v. Bodenseewerk Perkin-Elmer GmbH, 386 F.3d 1133 (Fed. Cir. 2004) .........................................................................39 Phillips v. AWH Corp., 415 F. 3d 1303 (Fed. Cir. 2005) .................................................................passim Retractable Techs., Inc. v. Becton, Dickinson & Co., 653 F.3d 1296 (Fed. Cir. 2011) ...................................................................40, 45 Schindler Elevator Corp. v. Otis Elevator Co., 593 F.3d 1275 (Fed. Cir. 2010) ..........................................................................31 The Gillette Co. v. Energizer Holdings, Inc., 405 F.3d 1367 (Fed. Cir. 2005) .........................................................................36 STATUTES & RULES 28 U.S.C. 1295(a) ...................................................................................................1 28 U.S.C. 1331........................................................................................................1 28 U.S.C. 1338........................................................................................................1 28 U.S.C. 2107(a) ...................................................................................................1
Case: 13-1397 Document: 34 Page: 6 Filed: 07/09/2013 vi FED. R. APP. P. 4(a)....................................................................................................1 FED. R. CIV. P. 56(a).................................................................................................31
STATEMENT CONCERNING CONFIDENTIAL MATERIAL
Pursuant to Fed. Cir. R. 28(d)(1)(B) and 30(h)(1)(B), Gemalto S.A. states as follows: The material that has been deleted on pages 4, 19, 20, and 21 of this brief includes matter that was designated as Confidential-Attorneys Eyes Only by Defendants in the district court. The deleted portions reflect the substance of certain communications among Google Inc. employees concerning the design of the Android operating system and other information Defendants consider sensitive. Case: 13-1397 Document: 34 Page: 7 Filed: 07/09/2013 vii STATEMENT OF RELATED CASES
Pursuant to FED. CIR. R. 47.5, Plaintiff-Appellant Gemalto S.A. (Gemalto) states as follows: (a) There have been no other previous appeals in this case; and (b) There are no cases pending in this or any other court that will directly affect or be directly affected by this Courts decision in the pending appeal. Case: 13-1397 Document: 34 Page: 8 Filed: 07/09/2013
I. STATEMENT OF JURISDICTION The U.S. District Court for the Eastern District of Texas had jurisdiction over the actions giving rise to this appeal under 28 U.S.C. 1331 and 1338(a). The U.S. Court of Appeals for the Federal Circuit has jurisdiction over this appeal under 28 U.S.C. 1295(a). The notice of appeal from the final judgment entered on April 16, 2013 was timely filed under FED. R. APP. P. 4(a) and 28 U.S.C. 2107(a) on May 3, 2013. J A1; J A180-82. II. STATEMENT OF THE ISSUES Issue 1: Whether the district court erred in granting summary judgment of noninfringement on the basis of three misconstrued termsmicrocontroller, integrated circuit card, and programmable devicewhen, in construing each of these claim terms to require all program memory on a single semiconductor substrate, the court excluded a claimed embodiment; effected unsupported disclaimers of claim scope; and subjected these terms of varying breadth to the same overly restrictive limitation found nowhere in the intrinsic record. Issue 2: Whether, assuming arguendo that the district court correctly construed the claims to require all program memory on a single semiconductor substrate, the court nevertheless erred in granting summary judgment of noninfringement under the doctrine of equivalents when Gemalto presented unrebutted evidence establishing that, in the accused devices, at least 97 percent of the program code to be executed is present in on-chip memory during execution. Case: 13-1397 Document: 34 Page: 9 Filed: 07/09/2013 2 III. STATEMENT OF THE CASE In 1996, four computer scientists working in Texas for Gemaltos predecessor, Schlumberger, solved a problem then thought to be unsolvable: running applications developed using the J ava programming languagea language designed for desktop computerswithin the resource-constrained computing environment of a smartcard, smartphone, or other system whose functions are controlled by an embedded processor. See J A92(7:43)-J A98(19:36). 1 The inventors thereby enabled the makers of embedded systems generally, including makers of programmable devices such as smartcards and smartphones, to leverage the community of tens of thousands of J ava application developers. J A660. Because J ava is the most popular programming language in the mobile world, J A659, Gemaltos J ava conversion technology has playedand continues to playan essential role in the rapid growth of the smartcard and smartphone industries. J A349; J A723. As described and claimed in the patents-in-suitU.S. Patent Nos. 6,308,317 (the 317 Patent); 7,117,485 (the 485 Patent); and 7,818,727 (the 727 Patent)Gemaltos inventions claim the conversion of J ava applications from a compiled form comprising hundreds of class files to a converted form comprising a single class file suitable for execution by a processor operating within the resource-
1 The three patents-in-suit share a common specification. For the sake of simplicity, citations herein are to the specification of the 317 Patent. Case: 13-1397 Document: 34 Page: 10 Filed: 07/09/2013 3 constrained computing environment of the device in which it is embedded. J A67 (Fig. 2); J A68 (Fig. 3); J A92(7:43)-J A98(19:36). While the patents disclosure draws upon the inventors extensive work with smartcards, Gemaltos inventions are not limited to that particular embodiment of an embedded system. Recognizing the importance and broad applicability of their new technology, the inventors obtained patent protection covering the use of their J ava conversion techniques in any embedded systemincluding, in particular, smartcards and mobile phones having embedded processors (today known as smartphones). J A86 (Fig. 22) (showing an embedded processor for a mobile phone); J A92(7:60-65) (In other embodiments, the microcontroller, memory and communicator are mounted within telecommunication equipment). The claims of the patents-in-suit are thus directed to various embedded system embodiments, including programmable devices generally and integrated circuit cards to be embedded in other devices to control their operation. In addition, there are also claims directed to a microcontroller, which as described in the patent specification is one embodiment of an embedded processor that may be used in the claimed inventions, whether as part of an integrated circuit card or as a stand-alone component embedded to control a programmable device. Gemalto filed this suit in October 2010, alleging that Defendants manufacture, sale, importation, and promotion of Android smartphones infringe Case: 13-1397 Document: 34 Page: 11 Filed: 07/09/2013 4 the patents-in-suit. J A247-58. Critically, Defendants do not dispute here that their accused smartphones make use of the patents J ava conversion technology to solve problems resulting from the resource-constraints inherent to these mobile devices. J A261 (All your J ava code [is] compiled by the J ava compiler and .class files are output. The dx tool converts the .class files to Dalvik byte code (i.e., a single executable file)); J A262-63
Instead, Defendants seek to avoid accounting for their use of this technology on the ground that the processor chips embedded in their resource-constrained devices can access larger amounts of memory than was typicalaccording to the specificationin 1996. J A272-73. In particular, Defendants argue that (1) the processor chips embedded in their accused Android devices make use of external, off-processor chip memory (in addition to the on-processor chip memory) to store the converted application instructions when power to the device is turned off; and (2) embodiments that rely on such external memory fall outside the scope of the claims. Id. Nothing in the patents or their prosecution history, however, disclaims such use of any off-chip memoryin fact the patents expressly cover embodiments in which a portion of the memory is located in the processor, and the rest is located external to it. J A90 (4:13-14); J A98 (claim 4). CONFIDENTIAL MATERIAL OMITTED Case: 13-1397 Document: 34 Page: 12 Filed: 07/09/2013 5 The magistrate judge nevertheless construed the claims to exclude such embodiments. In particular, the magistrate construed: (1) microcontroller as a single semiconductor substrate [i.e., a single chip] integrating electronic circuit components that includes a central processing unit and all program memory making it suitable for use an embedded system; (2) integrated circuit card as a card containing a single semiconductor substrate having a central processing unit and all program memory; and (3) programmable device as having the same meaning and scope as the term microcontroller. J A27; J A31; J A33 (emphasis added); Gemalto S.A. v. HTC Corp., No. 6:10-CV-561, 2012 U.S. Dist. LEXIS 89764 (J une 28, 2012 E.D. Tex.). Gemalto filed timely objections to these constructions, showing that there was no basis to narrow the claims with the location-restricting all program memory limitationlanguage that was found nowhere in the intrinsic record. J A298-302. But the district court summarily overruled those objections and adopted the magistrates constructions in August 2012. J A16. Defendants then moved for summary judgment of noninfringement. J A266. Again, Defendants did not dispute that their accused Android smartphones practice the J ava conversion techniques claimed in the patents-in-suit; they simply argued that these devices do not meet the imported all program memory limitation for microcontroller, integrated circuit card, and programmable device because a Case: 13-1397 Document: 34 Page: 13 Filed: 07/09/2013 6 portion of the memory used in the Android smartphones to store program instructions when not being executed by the processor chip is external to the processor. J A272-73. The magistrate agreed with Defendants, and recommended the entry of summary judgment on the basis of this location-restricting all program memory limitation found in the claims as construed. J A7-12. The ruling extended to cover Gemaltos arguments under the doctrine of equivalents, which rest on the uncontested fact that, when in use, the program instructions executed by an Android smartphone are present in the memory of the phones embedded processor chip 97 percent of the timesuch that only three percent of the time is there a need for the on-chip memory controller to retrieve an instruction from off- chip memory for execution by the processor. J A12-14. Gemalto again filed timely objections to the magistrates summary recommendation, and the district court again overruled those objections in summary fashion. J A2-3. Final judgment was entered on April 16, 2013, and this appeal followed. J A1; J A180-82. Case: 13-1397 Document: 34 Page: 14 Filed: 07/09/2013 7 IV. STATEMENT OF FACTS A. The Parties. Plaintiff Gemalto is the worlds leading provider of digital security solutions, which are incorporated in myriad types of devices, smartcards, smartphones, passports, government-issued ID cards, and other embedded systems. J A247-48. More than one billion people worldwide use Gemaltos products and services for telecommunications, financial services, e-government, identity and access management, multimedia content, digital rights management, IT security, mass transit and many other embedded system applications. Id. Gemalto has a long tradition of innovation and invests heavily in research and development. J A247. Gemalto holds all rights, title, and interest to the patents-in-suit. J A251-52. Defendants Google, Inc. (Google); HTC Corporation, HTC America, Inc., and Exedea, Inc. (collectively, HTC); Motorola Mobility, LLC (Motorola); and Samsung Electronics Co., Ltd., and Samsung Telecommunications America, LLC (collectively, Samsung) are some of the worlds largest technology companies. Defendant Google is the developer of the accused Android operating system and the Android software development kit that allows Google and the other Defendants to convert J ava applications for use in Android smartphones. J A248. Google also develops, sells, and markets its own brand of Android smartphones. J A249. The remaining Defendants develop, sell, and market Android smartphones using the Android operating system, and the J ava applications included with their Case: 13-1397 Document: 34 Page: 15 Filed: 07/09/2013 8 smartphones have been converted using the Android software development kit. J A249-51. B. The Patents-in-Suit. The patented technology at issue in this case was developed in the mid- 1990s by Gemaltos corporate predecessor, Schlumberger, at its Austin research and development facility. J A349-53. The inventions enable the use of high-level programming languages, such as the ubiquitous J ava programming language, in embedded systems. J A92(7:43)-J A98(19:36). The six asserted embedded system claimsclaims 1, 4, and 5 of the 317 Patent (integrated circuit card); claims 38 and 39 of the 485 Patent (integrated circuit card); and claim 3 of the 727 Patent (programmable device)require a converted application created using a two-step process for transforming applications written in a high-level programming language into a form that can be executed by the embedded processor of the claim using a virtual machine (referred to in the claim as an interpreter). In the first step, applications are compiled into a compiled form comprising hundreds of class files suitable for use in desktop computers. J A17-18. Applications in class format are then fed into a class file converter, which, using various optimization and conversion techniques recited in the claims and described in the specification, consolidates and compresses the files to produce a single class file of converted byte codes suitable Case: 13-1397 Document: 34 Page: 16 Filed: 07/09/2013 9 for use in embedded systems. This converted form is then loaded to or stored in the memory of the embedded processor chip for execution by the processor, as described and claimed in Gemaltos patents. J A17-18. The virtual machine, which is also loaded to on-chip memory, is then used by the embedded processor to interpret the converted byte codes into native program instructions for execution by the embedded processor. In converting hundreds of class files into a single class file, the technology taught by the patents-in-suit drastically minimizes computing resources consumed by both the J ava applications and the virtual machine (the interpreter) that allows the processor to interpret them for execution, see J A92(7:43)-J A98(19:36), making these applications suitable for use in the resource-constrained computing environments of embedded systems, such as the Android smartphones. In this way, Gemaltos patented J ava conversion technology enables embedded, resource- constrained computing platforms to enjoy programming capabilities previously only available to desktop computers. J A89(1:55-61). C. The Prosecution History. The novelty of Gemaltos inventions lies in the conversion techniques taught in the specification and recited in the claimsnot the type of embedded processor used in practicing those conversion techniques, let alone whether that processor has all of its memory for storing program instructions on-chip. Indeed, during the Case: 13-1397 Document: 34 Page: 17 Filed: 07/09/2013 10 prosecution of the patents-in-suit, the applicants explained that the claimed conversion techniques enabled the deployment of J ava in embedded systems generally, not just in smartcards or smartphones: Embedded systems using microcontrollers can also gain many of the[] advantages [detailed in the specification] for downloading new applications, high level program development, and rapid prototyping by making use of this invention. J A90(4:4-8); J A92 (7:60-65) (In other embodiments, the microcontroller, memory and communicator are mounted within telecommunication equipment); J A86 (Fig. 22) (showing an embedded processor for a mobile phone). The applicants also emphasized that the embedded processor maybut need notbe a microcontroller, thereby making clear that the embedded systems practicing the inventions can be powered by any type of embedded processor. J A90(4:12-13). Indeed, the summary of the invention and patent claims themselves refer to integrated circuit card[s] and programmable device[s] as comprising, among other things, generic processor[s] (not just microcontroller[s]). J A98- 102, 105-08 (317 Patent, claims 1, 4-11, 13-15, 22, 24, 25, 30, 31, 55, 64, 84-86, 93, and 94); J A178-79 (727 Patent, claims 1-7, 10, 12, 14, and 16-18). In discussing the benefits afforded by their inventions, the applicants also explained what they believed to be the differences between microprocessors for desktop computers and microcontrollers in existence in the mid-1990s. Case: 13-1397 Document: 34 Page: 18 Filed: 07/09/2013 11 J A89(1:62-2:10). In particular, the applicants noted that a typical microprocessor had access to relatively large external memory, such that it could run unconverted J ava code on a desktop computer, while a typical microcontroller that is, a type of processor chip used to control an embedded system such as a smartcard or mobile phone (today known as a smartphone)usually had access to a much smaller memory, thereby benefitting from the claimed optimization and conversion techniques. Id. The provisional application to which the patents-in-suit claim priority further defined a microprocessor as a central processing unit without any memory. J A370 (emphasis added). The applicants defined a microcontroller, in contrast, as comprising a central processing unit, memory and other functional elements on a single chip. Id. (emphasis added). While the applicants definition of microcontroller thus makes clear that the processor chip contains memory, the definition makes no reference to program memory or all program memory, nor does it provide that all memory for storing program instructions must reside on the microcontroller chip. D. The Patents Do Not Require that All Memory For Storing Converted Applications Be On-Chip and Claim Embodiments that Store Converted Applications in a Mix of On-Chip and Off- Chip Memory. Nothing in the intrinsic record evidences an intention by the applicants to limit the claims such that all memory for storing an applications program Case: 13-1397 Document: 34 Page: 19 Filed: 07/09/2013 12 instructions be on the processor chip (on-chip memory). In addition, nothing in the intrinsic record disclaims embodiments that use a mix of on-chip and off-chip memory, with memory located external to the processor chip (i.e., off-chip memory) to store such instructions. To the contrary, the claims and specification show that the applicants expressly intended to cover such mixed embodiments. The specification expressly provides that a portion of the memory utilized by devices embodying the claimed inventions may be located external to the processor chip. J A90(4:13-14) ([A]t least a portion of the memory may be located in the processor). And this disclosure in the specification carries into the claims. In particular, claim 1 of the 317 Patent provides:
* * *
J A98 (emphasis added). Claim 4, which depends from claim 1, recites in turn: Case: 13-1397 Document: 34 Page: 20 Filed: 07/09/2013 13
Id. (emphasis added). It is thus clear that the patent applicants intended to cover embodiments of their inventions utilizing memory located both in the processor chip and external to the processorthat is, a mix of on-chip and off-chip memoryto store applications derived through the conversion techniques taught by the patents. The applicants intent to claim embodiments making use of external memory for application instructions reflects a commercial realitythroughout the 1990s (and into the present day) microcontrollers were and are regularly designed to use a mix of on-chip and off-chip (external) memory to store program instructions. For instance: A patent filed in 1996 by a well-known chip manufacturer notes that [a] microcontroller is typically coupled to one or more external memory devices which store software programs . [T]he microcontroller fetches the instructions and data from the external memory . J A425(1:39-44) (emphasis added). A patent filed in 1995 by a Motorola affiliate provides that: the microcontroller must be able to fetch part of the program off-chip. J A446(1:18-25, 2:40-43) (emphasis added). A 1987 datasheet published by a Motorola affiliate notes that Motorola microcontrollers are designed to work with [a]pplications requiring external memory. J A450 (emphasis added). A 1996 datasheet published by a Motorola affiliate notes that a microcontroller can access external peripheral and memory devices. J A475 (emphasis added). Case: 13-1397 Document: 34 Page: 21 Filed: 07/09/2013 14 A 1997 datasheet published by a Motorola affiliate notes that microcontrollers are designed to use external EEPROMs or RAMs. J A539 (emphasis added). E. The Patents Do Not Require that the Memory Used by the Processor to Execute Converted Applications Include the Non- Volatile (Permanent) Memory Located Off-Chip. The applicants also did not disclaim any particular type of memory to be used by the processor for execution of the converted applicationswhether permanent or non-volatile memory, e.g., ROM or EEPROM, or volatile-memory, e.g., RAM. Indeed, the specification discusses both volatile and non-volatile (i.e., permanent) memory: There are generally three different types of memory used: random access memory (RAM), read only memory (ROM), and electrically erasable programmable only memory (EEPROM). . . . Each kind of memory is suitable for different purposes. Although ROM is the least expensive, it is suitable only for data that is unchanging, such as operating system code. EEPROM is useful for storing data that must be retained when power is removed, but is extremely slow to write. RAM can be written and read at high speed, but is expensive and data in RAM is lost when power is removed. J A89(2:11-34). Nothing in the asserted claims requires that processors powering embodiments of the invention include on-chip the permanent (i.e., non-volatile) memory used to store program instructions when power to the device is turned off. There is thus no disclaimer of devices that, like the Android smartphones, load Case: 13-1397 Document: 34 Page: 22 Filed: 07/09/2013 15 program instructions from the off-chip permanent memory to the on-chip memory (volatile memory, called cache memory) for execution by the processor. Indeed, the patents describe and generically claim memory for storing the converted applications on-chip, see, e.g., J A98 (claim 1), but there is nothing to indicate that the type of storing contemplated has to include any permanent memory storage too. Moreover, the language in nearly every independent claim recites, without limitation, that the purpose of the memory is to stor[e] the converted applications for execution by the claimed embedded processor, see, e.g., J A98 (claim 1) (emphasis added)a completely different purpose than that of non- volatile (permanent) memory, which is used to store programs when power to a device is turned off. Thus, there is no disclaimer to justify the district courts further narrowing of the all program memory limitation in the summary judgment ruling, wherein the district court held that the on-chip memory the Android smartphones use for execution is not all program memory. J A9-10 (on-chip memory space only temporarily holding program instructions loaded from off-chip main memory does not constitute all program memory necessary for execution. Also necessary for execution is [off-chip] memory space permanently holding all program instructions.). The district courts ruling ignores both the intrinsic record, including the patent specification and claims, and the extrinsic record, which Case: 13-1397 Document: 34 Page: 23 Filed: 07/09/2013 16 shows that microcontrollers (a widely-used form of embedded processor at the time of the invention) regularly retrieve program instructions from external, off- chip memory. F. The Patents Disclose and Claim Embedded Systems for Non- Smartcard Embodiments. The examples used in the specification to illustrate the teachings of the patents understandably draw upon the inventors extensive work with the devices that were the focus of their immediate effortsthat is, smartcards. But the claims allowed by the PTO, including all of the claims asserted by Gemalto in this action, are not limited to the smartcard environment. Instead, as noted, these claims are more broadly directed to microcontrollers; integrated circuit card[s] (claims 1, 4 and 6 of the 317 Patent and claims 38 and 39 of the 485 Patent); and programmable device[s] (claim 3 of the 727 Patent) that take advantage of Gemaltos conversion technology. The specification likewise includes several figures that show embodiments of the claimed inventions, including: Figure 21, which shows a microcontroller 210 embedded in a smartcard, J A86; J A92(7:28-29): Case: 13-1397 Document: 34 Page: 24 Filed: 07/09/2013 17
Figure 22, which shows an embedded microcontroller 210 providing the claimed J ava conversion technology to a mobile telephone (today called a smartphone), J A86; J A92(7:30-32):
Figure 25, which shows a circuit card with an embedded microcontroller 210 to control another device, J A88; J A92(7:37-38):
Case: 13-1397 Document: 34 Page: 25 Filed: 07/09/2013 18 G. The Processors Powering Devices that Embody the Claimed Inventions Need Not Be Microcontrollers. Consistent with the applicants desire not to limit the scope of their inventions to particular embedded systems, the patents make clear that the claimed processor may be a microcontroller, but may also be something more generic. J A90(4:12-13) (The processor may be a microcontroller); J A98 (claim 3) (3. The integrated circuit card of claim 1 wherein the processor comprises a microcontroller.). Indeed, numerous claims of the patents-in-suit, including the asserted claims, do not recite microcontroller[s], but rather other form factors integrated circuit card[s] and programmable device[s]that comprise, among other things, generic embedded processor[s]. J A98-102, J A105-08 (317 Patent, claims 1, 4-11, 13-15, 22, 24, 25, 30, 31, 55, 64, 84-86, 93, and 94); J A178-79 (727 Patent, claims 1-7, 10, 12, 14, and 16-18). H. Gemaltos Inventions Have Had a Dramatic Impact on the World of Mobile Computing. Gemaltos inventions were immediately met with extraordinary industry acclaim. For good reasonas the former CEO of the company that created J ava (Sun Microsystems) recognized, [f]itting J ava technology inside smart cards was like playing golf in a telephone booth. J A643. In addition to receiving numerous accolades, Gemaltos inventions also spawned the adoption of a new specification for J ava-based smartcards, which has since been implemented in billions of Case: 13-1397 Document: 34 Page: 26 Filed: 07/09/2013 19 devices sold around the world. J A349. Thanks to the patents-in-suit, smartcards have become the most widely sold general purpose computer in the world. Id. Virtually all of Gemaltos competitors have taken a license to the patents-in-suit. J A648. I. Years After the Inventors Managed to Deploy Java Within the Resource-Constrained Environment of an Embedded System, Googles Android Team Found Itself Vexed by the Same Problem. In the mid 2000s, Defendant Google
J A261 (All your J ava code [is] compiled by the J ava compiler and .class files are output. The dex tool converts the .class files to Dalvik byte code.).
J avaand Gemaltos patented conversion technology that allows Android smartphones to run J ava applicationsremains critical to Androids success. Indeed, Google management continues to believe that the technical alternatives to J ava all suck. J A723. J. The Operation of the Embedded Systems in the Accused Android Smartphones. In moving for summary judgment, Defendants did not dispute that the accused Android smartphones utilize Gemaltos patented J ava conversion technology. J A261 (All your J ava code [is] compiled by the J ava compiler and .class files are output. The dex tool converts the .class files to Dalvik byte code.). Each of the accused smartphones is powered by a circuit card, i.e., a motherboard, with an embedded processor chip that controls the phone and runs J ava applications. The motherboard of a representative accused smartphone (the Motorola Droid Pro) is shown below: CONFIDENTIAL MATERIAL OMITTED Case: 13-1397 Document: 34 Page: 29 Filed: 07/09/2013 22
Embedded processor chips like those utilized in the accused Android smartphones are the 21st century equivalent of microcontrollers. J A725. Each of the processor chips in the accused Android smartphones employs a modified Harvard architecture, in which a CPU in the processor chip employs separate and exclusive memory space for application program instructions and data. J A713. The processor chips of the accused Android smartphones maintain in them a separate and distinct instruction cache and data cache for the CPU of the processor to use at the lowest cache level (called L1 cache). Id. The L1 instruction cache is the only memory from which the CPU of the processor executes program instructions. Id. Cache memory is high-speed RAM that is contained on the same semiconductor substrate as the CPU. Id. This is the case with the processor chip in each of the accused Android smartphones. Id. Further, the cache memory in each
MotorolaDroidPro Processorchip (SystemonaChip(SoC)) Case: 13-1397 Document: 34 Page: 30 Filed: 07/09/2013 23 of these processor chips contains both a level 1 (L1) instruction cache and a level 1 (L1) data cache. Id. The CPU of the processor exclusively fetches and executes instructions from the L1 instruction cache. J A713-14. The cache memory also includes a unified level 2 (L2) data cache that stores both program instructions, converted byte codes, and other data needed by the processor. J A713. The L2 data cache is also located on the same semiconductor substrate as the CPU in the processor. Id. When the CPU in the accused Android smartphones seeks to fetch a program instruction for execution, it does so by sending the fetch request to the L1 instruction cache. J A713-14. If the particular program instruction resides in the L1 instruction cache, the L1 instruction cache will immediately provide the program instruction to the CPU of the processor. Id. If the particular program instruction does not reside in the L1 instruction cache of the processor at that point, the cache controller will determine if the program instruction resides in the L1 data cache or the L2 data cache. Id. If the program instruction resides in the L1 data cache or the L2 data cache, a block of instructions including the requested instruction will be moved from the L1 data cache or the L2 data cache to the L1 instruction cache so that it can be provided to the processors CPU. Id. From the L1 instruction cache, the requested instruction will then be provided to the CPU for execution. Id. Case: 13-1397 Document: 34 Page: 31 Filed: 07/09/2013 24 If the program instruction does not reside in the L1 or L2 data cache, the cache controller will retrieve a block of instructions from the off-chip main system memory (off-chip RAM or separate flash memory) also embedded in the circuit board of the Android smartphones. J A714. The cache controller will place a copy in both the L2 data cache and the L1 instruction cache. Id. The requested instruction is then provided from the L1 instruction cache to the CPU for execution. Id. Significantly, when the CPU attempts to fetch a program instruction from the L1 instruction cache, that program instruction resides in the L1 instruction cache or the L2 cache at least 97% of the time. J A718; J A731-32. This is undisputed and was confirmed through testing of the accused Android smartphones, as explained in a detailed declaration submitted with Gemaltos opposition to Defendants motion for summary judgment. J A726-33. And the result is not surprising: for efficiency reasons the cache controllers are designed to minimize off-chip memory fetch and access during execution. J A718. Thus, again, the accused Android smartphones are designed such that any particular program instruction called or requested by the CPU of the processor will already reside in the on-chip cache memory at least 97% of the time. Id.; J A731- 32. The accused Android smartphones thus use embedded systems and run converted J ava applications. J A719. And they further operate in a resource- Case: 13-1397 Document: 34 Page: 32 Filed: 07/09/2013 25 constrained environmentcompared to traditional desktop platforms, the accused smartphones have limited computing power, smaller amounts of memory, smaller amounts of semi-permanent storage, constraints in power consumption, and less to offer in terms of operator interfaces. Id. As a result, these Android smartphones (and the integrated circuit cards embedded therein) would not offer the application flexibility of traditional computing platforms without Gemaltos conversion technology. Id. Many standard desktop computing applications, for example, such as word processing, spreadsheets, graphics presentation, publishing, and photo/video manipulation, will not run or cannot be run effectively on the Android smartphones without the patented J ava conversion technology. Id. K. The Markman and Summary Judgment Orders Notwithstanding the intrinsic evidence demonstrating an intent to claim embodiments that use a mix of on- and off-chip memory, the district court construed the terms microcontroller, integrated circuit card, and programmable device so as to exclude embodiments making any use of off-chip program memory. That is, the court construed the terms: (1) microcontroller as a single semi-conductor substrate integrating electronic circuit components that includes a central processing unit and all program memory making it suitable for use as an embedded system; (2) integrated circuit card as a card containing a single semiconductor substrate having a central processing unit and all program Case: 13-1397 Document: 34 Page: 33 Filed: 07/09/2013 26 memory; and (3) programmable device as having the same meaning and scope of microcontroller. J A27; J A31; J A33. It is undisputed that the terms program memory and all program memory, found in each of these constructions, do not appear anywhere in the patents or the prosecution history. Nor were these terms proposed by any of the parties in this case. J A22; J A28; J A31. They were instead adopted by the magistrate judge during the initial claim construction determination. J A27; J A31; J A33. Perhaps recognizing the powerful intrinsic evidence regarding embodiments with a mix of on- and off-chip memory, the magistrate explained in the Markman order that the construction does not prevent a microcontroller from accessing any external memory . Under the Courts construction, a microcontroller may access off chip memory to store and retrieve data stored in a static RAM. J A26. The courts rulings on summary judgment, however, made clear that these constructions exclude embodiments making any use of off-chip memory to store any portion of the application instructions converted with the patented techniques. J A8-10. In the February 25, 2013 Report and Recommendation, adopted by the district court on April 14, 2013, the magistrate judge held that by virtue of the fact that Defendants devices store program instructions off-chip and access those off- chip instructions to run the accused applications, they [do] not literally infringe. Case: 13-1397 Document: 34 Page: 34 Filed: 07/09/2013 27 J A12. The magistrate rejected Gemaltos argument that the cache memory of the accused Android smartphones met the limitation in question, holding that memory space only temporarily holding program instructions does not constitute all program memory necessary for execution. J A 9-10. The magistrate also rejected Gemaltos doctrine of equivalents (DOE) arguments. In support of those arguments, Gemalto submitted a declaration from its patent-infringement expert opining thatbased on the tests that had been performedthe accused Android smartphones satisfied the all program memory limitation under the doctrine of equivalents. That is, Gemaltos expert opined that having the necessary program instructions in on-chip memory 97% of the time was insubstantially different from having those program instructions in on-chip memory 100% of the time. J A12-14. The magistrate judge rejected Gemaltos DOE arguments reasoning that the accused devices on-chip memory cannot meet the all program memory limitation by equivalence, reasoning that because the all program memory limitation was structural in nature it could not be met either literally or by equivalenceby on-chip volatile memory. J A12-13. V. SUMMARY OF ARGUMENT In granting summary judgment of noninfringement, the district court committed three legal errors. Case: 13-1397 Document: 34 Page: 35 Filed: 07/09/2013 28 First, the court erred in equating the broad term programmable device with microcontroller, a facially narrower term that is one of the preferred embodiments disclosed in the specification. This Courts precedent holds that, absent clear and unmistakable evidence to the contrary, it is inappropriate to confine the scope of a patent claim to an embodiment discussed in the specification. Phillips v. AWH Corp., 415 F. 3d 1303, 1323 (Fed. Cir. 2005) (noting that although the specification often describes very specific embodiments of the invention, we have repeatedly warned against confining the claims to those embodiments) (citing Nazomi Commcns, Inc. v. ARM Holdings, PLC, 403 F.3d 1364, 1369 (Fed. Cir. 2005) (claims may embrace different subject matter than is illustrated in the specific embodiments in the specification)). The error in the district courts construction of programmable device as microcontroller is particularly glaring given that (1) the programmable device claims do not recite a microcontroller limitation; instead they recite a generic embedded processor, a term that, according to the specification maybut need notbe a microcontroller; and (2) during the prosecution history, the PTO examiner understood the programmable device claims to be a broader recitation than the integrated circuit card and microcontroller claims of the 317 Patent. Second, the district court erred in importing the location-restricting all program memory limitation into its constructions for the claim terms integrated Case: 13-1397 Document: 34 Page: 36 Filed: 07/09/2013 29 circuit card and microcontroller. The court effectively determined that the applicants disclaimed any embodiment of their inventions making use of memory external to the processor to store the converted application program instructions. That determination, however, is at odds with the entirety of the evidentiary record. Indeed, embodiments that utilize off-chip memory to store applications are specifically claimed in claim 4 of the 317 Patent, which Gemalto is asserting in this lawsuit. Furthermore, the district courts claim construction order acknowledged that embodiments of the invention may in fact utilize external memory, and there is nothing in the patents disclosure or the prosecution history that evidences an intent by the patent applicants to disclaim embedded systems that utilize off-chip memory to store applications (as opposed to data). Indeed, to the contrary, the claims themselves expressly cover embodiments whose embedded processors rely on external memory to store applications. Moreover, the uncontroverted evidence shows that throughout the 1990s (and even to the present day) microcontrollers were and are regularly designed to use external memory to store application program instructions for this purpose. Case: 13-1397 Document: 34 Page: 37 Filed: 07/09/2013 30 Third, even if the district courts constructions for the terms microcontroller, integrated circuit card, and programmable device were correctthough they are notthe court nevertheless erred in granting summary judgment of noninfringement under the doctrine of equivalents (DOE). Gemaltos summary judgment evidence demonstrated that at least 97% of the time the CPU calls for program instructions to be executed, those instructions are already present in the on-chip cache memory of the accused smartphones processor chips. Gemaltos expert further opined that, in this context, 97% of the time represented an insubstantial difference from 100% of the time. This testimony created an issue of fact for the jury to resolve. Crown Packaging Tech., Inc. v. Rexam Bev. Can Co., 559 F.3d 1308, 1312 (Fed. Cir. 2009). Contrary to the magistrates conclusion, Gemaltos DOE arguments do not contravene the all- elements rule and do not implicate claim vitiation. The DOE, by its very nature, assumes that some element is missing from the literal claim language. Deere & Co. v. Bush Hog, LLC, 703 F.3d 1349, 1356 (Fed. Cir. 2012). There is no dispute that the accused Android smartphones contain on-chip memory, and that the program instructions to be executed for an application will be located in the on- chip cache 97%or virtually allof the time. A jury should have been allowed to consider and resolve the DOE issue, and the district courts decision to short- circuit this factual inquiry at summary judgment should be overturned as just the Case: 13-1397 Document: 34 Page: 38 Filed: 07/09/2013 31 type of impermissible shortcut this Court rejected in Deere. Id. ([c]ourts should be cautious not to shortcut th[e DOE] inquiry by identifying a binary choice in which an element is either present or not present). VI. STANDARD OF REVIEW The district courts claim constructions and summary judgment orders on noninfringement are subject to de novo review in this Court. 2 Cybor Corp v. FAS Techs., Inc., 138 F.3d 1448, 1454-55 (Fed. Cir. 1998) (en banc) (claim construction); Schindler Elevator Corp. v. Otis Elevator Co., 593 F.3d 1275, 1281 (Fed. Cir. 2010) (noninfringement). A summary judgment order can stand only if the record shows that there is no genuine dispute as to any material fact and [that Defendants are] entitled to judgment as a matter of law. FED. R. CIV. P. 56(a). In reviewing a summary judgment order, this Court resolv[es] reasonable factual inferences in favor of the patentee. Absolute Software, Inc. v. Stealth Signal, Inc., 659 F.3d 1121, 1130 (Fed. Cir. 2011). In other words, Gemaltos summary judgment evidence is to be believed, and all justifiable inferences are to be drawn in [its] favor. Anderson v. Liberty Lobby, Inc., 477 U.S. 242, 255 (1986).
2 Gemalto is aware that Cybor will be the subject of en banc review in Lighting Ballast Control v. Philips Electronics North America. Even if this Court were to apply a different and more deferential standard of review to the district courts claim construction order, the courts constructions in this case remain indefensible because they are clearly erroneous and clearly contrary to established precedent. Case: 13-1397 Document: 34 Page: 39 Filed: 07/09/2013 32 VII. ARGUMENT A. The District Court Erred in Granting Summary Judgment of Noninfringement Based on Its Incorrect Constructions of the Claim Terms Programmable Device, Integrated Circuit Card, and Microcontroller. The district court held that each of these terms of varying breadth was subject to the same narrowing limitation of claim scopefound nowhere in the claims or the specificationrequiring that any programmable device, integrated circuit card, or microcontroller practicing Gemaltos J ava conversion techniques include all program memory on a single semiconductor substrate. J A27; J A31; J A33. The court thus effectively concluded that Gemaltos patents disclaim any embedded-system embodiment that utilizes off-chip memory to store program instructions. J A12. That conclusion is in error, and both the claim constructions and summary judgments flowing from it must be reversed. See Burke, Inc. v. Bruno Indep. Living Aids, Inc., 183 F.3d 1334, 1338 (Fed. Cir. 1999) (Summary judgment should ordinarily be vacated or reversed if it is based on a claim construction that this court determines to be erroneous.); Intl Visual Corp. v. Crown Metal Mfg. Co., 991 F.2d 768, 772 (Fed. Cir. 1993). 1. The broader term programmable device is not coextensive with the narrower term microcontroller. In its construction for the term programmable device, the district court expressly found that a programmable device is a microcontroller, see J A33, thereby equating the programmable device claims of the 727 Patent with one of Case: 13-1397 Document: 34 Page: 40 Filed: 07/09/2013 33 the preferred embodiments disclosed in the specification. For several reasons, this construction was clear error. First, the district courts construction runs afoul of this Courts admonition that, absent a clear expression of intent to the contrary, it is inappropriate to confine claims to specific embodiments discussed in the specification. Phillips, 415 F.3d at 1323 (noting that although the specification often describes very specific embodiments of the invention, we have repeatedly warned against confining the claims to those embodiments) (citing Nazomi Commcns, 403 F.3d at 1369 (claims may embrace different subject matter than is illustrated in the specific embodiments in the specification)). Here, there is nothing in the specification or the prosecution history that manifests an intent by the applicants to equate the term programmable device with the term microcontroller. Second, while the district court noted that [b]ecause programmable device is not a term of art and has no plain and ordinary meaning, it is particularly important to construe the term in the context of the intrinsic record, J A32, it does not follow that programmable device should be construed as microcontroller. For one thing, as the district court acknowledged, the specification does not [even] use the term programmable device. Id. For another, the programmable device claims of the 727 Patent do not in fact recite a microcontroller; they recite a generic embedded processor, and the specification itself makes clear that Case: 13-1397 Document: 34 Page: 41 Filed: 07/09/2013 34 the processor element recited in the programmable device claims need not be a microcontroller. J A90(4:12-13) ([T]he processor may be a microcontroller.). The error in the district courts construction is thus particularly strikingat bottom, the district court equated programmable device with something even narrower than the processor limitation recited in the programmable device claims, completely ignoring the specifications admonition that the processor need not be a microcontroller. Third, the prosecution history underscores the common sense conclusion that the programmable device claims of the 727 Patent were intended to be broader than the microcontroller and integrated circuit claims of the 317 Patent. In particular, during the prosecution of the programmable device claims, the Examiner initially rejected those claims on the ground of non-statutory double patenting. J A737, J A751. In so doing, the Examiner observed that the present claims are merely considered a broader recitation of claims 1-86 of the 317 Patent, J A751, which includes scores of microcontroller and integrated circuit card claims. While the patent applicants ultimately overcame the double-patenting rejection by filing a terminal disclaimer, the intrinsic evidence leaves no doubt that the programmable device claims were understood by both the patent applicants and the PTO to have a broader scope than the microcontroller claims of the 317 Patent. Case: 13-1397 Document: 34 Page: 42 Filed: 07/09/2013 35 Fourth, by turning to a preferred embodiment to construe a claim term that is facially broader than all of the embodiments discussed in the specification, the district court overlooked this Courts directive that the words of the claims themselves define the scope of the patented invention. Phillips, 415 F. 3d at 1313 (emphasis added) (quoting Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). Here, the district court had to go no further than the claims themselves to find a proper construction. That is because, when considered in the context in which it is used in the asserted claims, programmable devicefound in a preambleis nothing but a descriptive name for the invention that is fully set forth in the bodies of the claims. Am. Med. Sys., Inc. v. Biolitec, 618 F.3d 1354, 1359 (Fed. Cir. 2010). Take, for instance, claim 3 of the 727 Patent, which reads: A programmable device comprising: a memory, and ; a processor; the memory comprising: an interpreter; and at least one application loaded in the memory J A178. In context, it is clear that programmable device is nothing but a convenient label for the invention as a whole. Am. Med. Sys., 618 F.3d at 1359 (finding such a term does not impose a claim limitation). A person of ordinary skill Case: 13-1397 Document: 34 Page: 43 Filed: 07/09/2013 36 in the art would understand that any device that meets the limitations set forth in the body of the claim falls within the scope of the 727 Patent. Fifth, it makes no sense that the patent applicants would go through the trouble of prosecuting two separate patents that claim, in strikingly different language, subject matter that is virtually identical. Nor does it make sense that the patent applicantswho are employees of a sophisticated multinational corporation that holds thousands of patentswould choose to limit the scope of their revolutionary inventions to one preferred embodiment (a microcontroller) when the patents teach that the optimization techniques are useful for any embedded processor or embedded device embodying it. See J A90(4:12-13) ([T]he processor may be a microcontroller.). Indeed, as this Court noted in Phillips, persons of ordinary skill in the art rarely would confine their definitions of terms to the exact representations depicted in the embodiments. 415 F.3d at 1323; see also The Gillette Co. v. Energizer Holdings, Inc., 405 F.3d 1367, 1371 (Fed. Cir. 2005) (a patentee typically claims broadly enough to cover less preferred embodiments as well as more preferred embodiments); Kara Tech. Inc. v. Stamps.com, 582 F.3d 1341, 1348 (Fed. Cir. 2009) (the patentee is entitled to the full scope of his claims, and [the Court should] not limit him to [the] preferred embodiment or import a limitation from the specification into the claims.) (citations omitted). Case: 13-1397 Document: 34 Page: 44 Filed: 07/09/2013 37 In sum, Gemalto respectfully submits that, if it is to be construed at all, the term programmable device should be held to mean a device that can execute a computer program. 2. The all program memory limitation should not have been imported into the claims. The district court construed the claim terms microcontroller and programmable device as a single semiconductor substrate integrating electronic circuit components that includes a central processing unit and all program memory making it suitable for use as an embedded system. J A27. 3 The court further construed integrated circuit card as a card containing a single semiconductor substrate having a central processing unit and all program memory. J A31. As clarified by the magistrate judge in the context of the courts ruling on summary judgment, the all program memory limitation precludes embodiments that use off-chip memory to store any portion of the application instruction code converted with the patented techniques, and instead requires application instruction code to be stored in permanent on-chip memory. J A8-10.
3 Prior to the district courts resolution of the summary judgment motions, Gemalto dropped the remaining asserted claim reciting a microcontroller. But because the district courts constructions of integrated circuit card and programmable device turn on and adopt the critical analysis and language of the courts microcontroller construction, J A31; J A33, that analysis and language must be addressed in this appeal. Case: 13-1397 Document: 34 Page: 45 Filed: 07/09/2013 38 This claim construction issue thus boils down to a straightforward questiondid the patentees disclaim devices that use off-chip memory to store any portion of the application instruction code? Gemalto respectfully submits that there is nothing in the evidentiary record that indicates a desire by the applicants to disclaim such embodiments. In fact, the opposite is true. First, the claims themselves confirm the absence of a disclaimer. Indeed, embodiments that rely on off-chip memory to store program instructions are specifically claimed. In particular, claim 4 of the 317 Patent, which Defendants acknowledge contemplates the use of external memory, see J A762-63, depends from claim 1 and recites that only a portion of the memory of claim 1 need reside in the processor chip. J A98. In turn, claim 1, which provides the antecedent basis for claim 4, recites a memory storing an application derived [from the patented conversion technology]. Id. (emphasis added). In other words, the patents expressly contemplate the use of memory external to the processor chip for purposes of storing application[s]and indeed, claim devices that utilize such external storage memory. This recitation of the claimed invention, which expressly defines the on-chip memory as holding less than all of the program instructions, cannot be reconciled with the district courts conclusion that Gemaltos patents do not cover devices that utilize memory located external to the processor chips to store program instructions. At bottom, the district courts Case: 13-1397 Document: 34 Page: 46 Filed: 07/09/2013 39 constructions for microcontroller and integrated circuit card fail to account for an embodiment expressly claimed in the patents disclosure. As such, these constructions cannot stand under this Courts precedent. Accent Packaging, Inc. v. Leggett & Platt, Inc., 707 F.3d 1318, 1326 (Fed. Cir. 2013) (We have held that a claim interpretation that excludes a preferred embodiment from the scope of the claim is rarely, if ever, correct.) (quoting On-Line Techs., Inc. v. Bodenseewerk Perkin-Elmer GmbH, 386 F.3d 1133, 1138 (Fed. Cir. 2004)). Second, the specification provides that implementations of the inventions include devices whose memory may be stored off chip. J A90(4:13-14 ([a]t least a portion of the memory may be located external to the processor)). The district court itself recognized this, when it acknowledged that its construction[s] do[] not prevent a microcontroller from accessing any external memory. J A26 (emphasis added). But while the district court held that embodiments of the claimed inventions may utilize external memory for some purposes (such as storing data), but not others (such as storing applications), there is nothing in the specification that draws a distinction between what can and what cannot be stored in external memory. Similarly, while the district court sought to ground the all program memory limitation in the distinction drawn in the specification between typical microprocessors, which usually have a relatively large external memory, and typical microcontrollers, which usually have a much smaller Case: 13-1397 Document: 34 Page: 47 Filed: 07/09/2013 40 memory, J A25, the distinction in question concerns solely the size of the microcontrollers memory, not its location. Indeed, it is no more correct to say that, because it has less memory than a microprocessor, all of the microcontrollers memory must reside on the same semiconductor substrate or on chip than to say that, because it is typically smaller than a mansion, an apartment must have only one room. Take a typical microcontroller with 2.0 KB of RAM. If 1.0 KB is placed on chip and the remainder is placed off chip or external to the semiconductor substrate, the microcontrollers memory is still 2.0 KB, i.e., small by comparison to a microprocessors, and that limited memory, cf. J A25, will still render the microcontroller unable to run J ava applications without utilizing Gemaltos inventions. In any event, the law is clear thatabsent clear and unmistakable statements that evidence an intent to limit the scope of the claims themselveslimitations from the specification should not be imported into the claims. See Phillips, 415 F.3d at 1320 (noting that reading a limitation from the written description into the claims is one of the cardinal sins of claim construction) (quoting SciMed Life Sys., 242 F.3d at 1340); Retractable Techs., Inc. v. Becton, Dickinson & Co., 653 F.3d 1296, 1306 (Fed. Cir. 2011). Here, there is nothing in the specification that amounts to expressions of manifest exclusion or restriction, representing a clear disavowal of claim scope concerning devices that rely on external memory to Case: 13-1397 Document: 34 Page: 48 Filed: 07/09/2013 41 store program instructions, id., and thus the district court committed error in limiting the claims. 4
Third, nothing in the prosecution history contravenes the patents disclosure. There is certainly nothing that comes close to the clear and unmistakable standard that is required by this Courts precedent. Grober v. Mako Products, Inc., 686 F.3d 1335, 1341 (Fed. Cir. 2012). The district court did not find otherwise, and its citation to portions of the prosecution history that highlighted the differences in typical memory requirements between embedded systems and traditional computing systems, J A24-25, do not amount to a disclaimer. Again, these statements simply explain the utility of the applicants inventions, and were not intended to limit the claims. The law is clear that merely highlighting the objective of a patent applicants invention does not result in a finding of disclaimer. In re Rambus Inc., 694 F.3d 42, 47 (Fed. Cir. 2012) (This court agrees with the Board that the specification does not restrict the invention to single chip memory devices.
4 Moreover, even if the disclosure in the specification concerning the differences between microprocessors and microcontrollers amounts to a disclaimer (and Gemalto respectfully submits that it does not), such a disclaimer should have no impact on the integrated circuit card claims. Those claims do not recite a microcontroller; rather, they recite a generic embedded processor, and the specification makes clear that the processor need not be a microcontroller. J A90 (4:12-13). Thus, correct or not, the construction for microcontroller should have no impact on claims that recite a different limitation. See Phillips, 415 F.3d at 1320 (noting that reading a limitation from the written description into the claims is one of the cardinal sins of claim construction) (quoting SciMed Life Sys., 242 F.3d at 1340). Case: 13-1397 Document: 34 Page: 49 Filed: 07/09/2013 42 There are no words of manifest exclusion or clear disavowals of multichip devicesthere are only preferred embodiments and goals of the invention that are better met by [certain preferred embodiments]. The specification language shows only that the invention can be carried out with [a preferred embodiment], it does not require the invention to be so performed.) (emphasis added); Golight, Inc. v. Wall-Mart Stores, Inc., 355 F.3d 1327, 1330-31 (Fed. Cir. 2004) (the patentees description of particular advantage[s] of the invention cannot limit the claims); Brookhill-Wilk 1, LLC v. Intuitive Surgical, Inc., 334 F.3d 1294, 1301 (Fed. Cir. 2003) (The objective described is merely one of several objectives that can be achieved through the use of the invention; the written description does not suggest that the invention must be used only in a manner to attain that objective.). Fourth, the district courts decision to limit the claims and exclude devices powered by embedded processors that rely on external memory to store program instructions is particularly striking given that it makes no commercial sense. The uncontroverted evidence establishes that throughout the 1990s (and even today) microcontrollers were regularly designed to use external memory to store program instructions. See supra at 12. As this Court has noted, in an unpublished decision, common sense should not be left on the side of the road during claim construction. Kress Corp. v. Alexander Servs., 1998 U.S. App. LEXIS 12742, *18 (Fed. Cir. J une 15, 1998) (unpublished). On the record before the Court, it makes Case: 13-1397 Document: 34 Page: 50 Filed: 07/09/2013 43 no sense that the patent applicants would wish to disclaim the very types of hardware to which persons of ordinary skill in the art would turn to make commercial embodiments of the inventions taught by the patents. Fifth, there is no basis for the district courts conclusion that the claims Gemalto has asserted against Defendants can be infringed only by devices that permanently store program instructions in on-chip memory. J A12-13. As noted, the specification discusses both volatile and non-volatile memory, see J A89(2:11-34), and the claims do not specify that the embodiments of the invention must be powered by processors that use non-volatile on-chip memory. Indeed, the type of memory the claimed embodiments processors must carry on-chipbe it RAM, ROM, or EEPROMis nowhere even discussed in the asserted claims. Moreover, purpose of the memory claimed in the asserted claims is to stor[e] the converted applications for execution by the claimed processor. See, e.g., J A98 (claim 1) (emphasis added). Storing for execution and storing permanently, however, are two different things, and it is undisputed that all the program instructions executed by the accused Android devices embedded processors are indeed stored in on-chip memory during execution. As this Court recently explained, courts called upon to protect hard-earned intellectual property rights should strive to capture the scope of the actual invention, rather than strictly limit the scope of claims to disclosed embodiments or Case: 13-1397 Document: 34 Page: 51 Filed: 07/09/2013 44 allow the claim language to become divorced from what the specification conveys is the invention. Retractable Techs., 653 F.3d at 1305. Here, the district courts claim construction and grant of summary judgment dramatically limited the claims to a scope significantly narrower than they unambiguously recite. Because the evidentiary record demonstrates that the applicants intended to claim embodiments of their inventions that rely on memory external to the processor chip to store program instructions, the Court should overturn the district courts constructions and interpret those terms as Gemalto requests. In particular, (1) microcontroller should be interpreted as a single semi-conductor substrate integrating electronic circuit components that includes a central processing unit and memory making it suitable for use as an embedded system; and (2) integrated circuit card should be interpreted as a card containing a single semiconductor substrate having a central processing unit and memory. 5
5 Gemalto acknowledges that the constructions for integrated circuit card and microcontroller Gemalto pursued in its Objections to the Markman Order retained references to program memory (as opposed to just memory). However, to avoid any potential ambiguities concerning the meaning of the term program memory, Gemalto respectfully submits that the Court adopt constructions that refer to just memory without the modifier program. Alternatively, Gemalto respectfully requests that the term program memory be defined as memory from which the embedded processor executes instructions. Case: 13-1397 Document: 34 Page: 52 Filed: 07/09/2013 45 B. Even if Its Constructions for the Relevant Claim Terms Were Correct (And They Are Not), The District Court Erred in Granting Summary Judgment on Gemaltos Doctrine of Equivalents Arguments. Even if the district courts constructions for microcontroller, integrated circuit card, and programmable device were correct (and they are not), such that the accused Android smartphones do not literally have all [their] program memory on the single semiconductor substrate that includes the CPU, the district court still committed error by entering summary judgment of noninfringement. As noted, the accused Android smartphones execute 100% of the program instructions from on-chip cache memory, and 97% of the time the instruction code to be executed for a given application is stored in the on-chip cache memory (either the L1 instruction cache, the L1 data cache, or the L2 data cache) before it is requested or needed by the CPU. J A718; J A731-32. Whether this scenario represents an insubstantial difference from having 100% of program instructions stored in and executed from on-chip memory 100% of the time is a question of fact for the jury to decide. Crown Packaging, 559 F.3d at 1312. The district courts decision to short-circuit this inquiry pre-trial was contrary to this Courts precedent. As this Court recently confirmed, Courts should be cautious not to shortcut this [DOE] inquiry by identifying a binary choice in which an element is present or not present. Deere, 703 F.3d at 1356-57 (reasonable jury could have found that indirect contact and direct contact are insubstantially different). Indeed, in Case: 13-1397 Document: 34 Page: 53 Filed: 07/09/2013 46 GuideTech, this Court reversed a district courts summary disposition of a DOE argument on strikingly similar facts: the accused infringer successfully demonstrated that the accused devices did not literally infringe two of the patents- in-suit because, as construed by the district court, those patents required that the capacitors installed outside of, and in parallel to, a first current circuit, whereas the accused devices had a capacitor installed within the first current circuit. Brilliant Instruments, Inc. v. GuideTech, LLC, 706 F.3d 1342, 1346-47 (Fed. Cir. 2013). Even though this Court agreed that there was no literal infringement, it held that the district court had improperly granted summary judgment on the patentees DOE arguments, and reversed and remanded the case for trial. Relying on Deere, the Court observed: Everyone agrees that the capacitor in the accused device is not located in exactly the same place as the claimed capacitor, but is the change in location an insubstantial difference? We conclude that, viewing all factual inferences in favor of [the patent holder] [there is] a genuine issue of material fact which precludes summary judgment. Id. at 1348 (emphasis added). Here, as was the case in GuideTech, Defendants persuaded the district court to grant them summary judgment based solely on the fact that the memory that permanently stores program instructions when not needed by the embedded processor or microcontroller is located off chip. J ust as this Court held in GuideTech, however, the location of the storage memory cannot be case-dispositive. That is because the extent to which the accused Android Case: 13-1397 Document: 34 Page: 54 Filed: 07/09/2013 47 smartphones reliance on a combination of on-chip execution and off-chip storage memory is different from having all program instructions stored on chip all the time should be left for the jury. Id. As was the case in Deere and GuideTech, the equivalents analysis does not vitiate the all program memory limitation because the antithesis or opposite of all (100%) is none (0%), not virtually all (97%). GuideTech, 706 F.3d at 1347 (The vitiation test cannot be satisfied merely by noting that the equivalent substitute is outside the claimed limitations literal scope. Rather, vitiation applies when one of skill in the art would understand that the literal and substitute limitations are not interchangeable, not insubstantially different, and when they do not perform substantially the same function in substantially the same way, to accomplish substantially the same result.). Furthermore, the district court appears to have concluded thateven in the context of an equivalence inquirythe all program memory limitation can be met only by permanent, as opposed to volatile cache memory. See J A10-12. Gemalto respectfully submits that this conclusion is at odds with the evidence. Again, there is no indication that the patent applicants intended that embodiments of the claimed inventions use only non-volatile memory on chip with the processor. J A89(2:11-34). As such, the district courts conclusion that, as a matter of law, volatile cache memory can never be equivalent to program memory is unsupported. Case: 13-1397 Document: 34 Page: 55 Filed: 07/09/2013 48 VIII. CONCLUSION AND RELIEF REQUESTED For all of these reasons, this Court should: reverse the district courts construction of the terms microcontroller, integrated circuit card, and programmable device; adopt Gemaltos proposed constructions of those terms; and reverse the summary judgments of noninfringement based on those terms. This Court should then vacate the final judgments and remand this litigation to the district court for further proceedings. Case: 13-1397 Document: 34 Page: 56 Filed: 07/09/2013 49 Respectfully submitted,
Dirk D. Thomas MCKOOL SMITH P.C. 1999 K Street, Suite 600 Washington, DC 20006 (202) 370-8302
/s/ Robert A. Cote Robert A. Cote MCKOOL SMITH P.C. One Bryant Park, 47th Floor New York, New York 10036 (212) 402-9400
J oel L. Thollander MCKOOL SMITH P.C. 300 W. 6th Street, Suite 1700 Austin, TX 78701 (512) 692-8735
Case: 13-1397 Document: 34 Page: 58 Filed: 07/09/2013 IN THE UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF TEXAS TYLER DIVISION
GEMALTO S.A.,
Plaintiff,
vs.
HTC CORPORATION, et al,
Defendants.
CASE NO. 6:10cv561 LED-JDL
JURY DEMANDED
FINAL JUDGMENT
Pursuant to this Courts Order Granting Summary Judgment of Non-infringement as to all claims (Doc. No. 443), the Court hereby enters final judgment. It is therefore ORDERED, ADJUDGED and DECREED that the parties take nothing and that all pending motions are DENIED AS MOOT. All costs are to be borne by the party that incurred them. It is further ORDERED, ADJUDGED and DECREED that all claims, counterclaims, and third-party claims in the instant suit be DISMISSED in their entirety. The Clerk of the Court is directed to close this case.
__________________________________ LEONARD DAVIS UNITED STATES DISTRICT JUDGE So ORDERED and SIGNED this 16th day of April, 2013. Case 6:10-cv-00561-LED-JDL Document 444 Filed 04/16/13 Page 1 of 1 PageID #: 13315 JA000001 Case: 13-1397 Document: 34 Page: 59 Filed: 07/09/2013
1 IN THE UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF TEXAS TYLER DIVISION
GEMALTO S.A.,
Plaintiff,
vs.
HTC CORPORATION, et al,
Defendants.
CASE NO. 6:10cv561 LED-JDL
JURY DEMANDED
ORDER ADOPTING REPORT AND RECOMMENDATION OF UNITED STATES MAGISTRATE JUDGE
The above entitled and numbered civil action was referred to United States Magistrate Judge John D. Love pursuant to 28 U.S.C. 636. The Report and Recommendation of the Magistrate Judge (Report), which contains his proposed findings of fact and recommendation for the disposition of such action, has been presented for consideration (Doc. No. 433). The Magistrate Judge recommends granting Defendants 1 Motion for Summary Judgment of Non- Infringement (Doc. No. 306). Plaintiff Gemalto S.A. (Gemalto) filed objections to the Report (Doc. No. 437), Defendants have filed a Response (Doc. No. 440), and Plaintiff has filed a Reply (Doc. No. 442). Upon review of the submissions, the Court is of the opinion that the findings and conclusions of the Magistrate Judge are correct. Therefore, the Court hereby adopts the Report of
1 Moving Defendants are: Exedea, Inc., Google Inc., HTC America Inc., HTC Corporation, Motorola Mobility LLC, Samsung Electronics Co., LTD., Samsung Telecommunications America LLC (collectively Defendants). Case 6:10-cv-00561-LED-JDL Document 443 Filed 04/15/13 Page 1 of 2 PageID #: 13313 JA000002 Case: 13-1397 Document: 34 Page: 60 Filed: 07/09/2013
2 the United States Magistrate Judge as the findings and conclusions of this Court. Accordingly, all objections are overruled and Defendants Motion for Summary Judgment is GRANTED.
__________________________________ LEONARD DAVIS UNITED STATES DISTRICT JUDGE So ORDERED and SIGNED this 15th day of April, 2013. Case 6:10-cv-00561-LED-JDL Document 443 Filed 04/15/13 Page 2 of 2 PageID #: 13314 JA000003 Case: 13-1397 Document: 34 Page: 61 Filed: 07/09/2013 1
IN THE UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF TEXAS TYLER DIVISION
GEMALTO, S.A.,
Plaintiff,
vs.
HTC CORPORATION, et al.,
Defendants.
No. 6:10-cv-561 LED-JDL
JURY DEMANDED
REPORT AND RECOMMENDATION OF UNITED STATES MAGISTRATE JUDGE
Before the Court is Defendants 1 Motion for Summary Judgment of Non-Infringement (Doc. No. 306) (MTN.). Plaintiff Gemalto S.A. (Gemalto) has filed Response (Doc. No. 328) (RESP.), to which Defendants have filed a Reply (Doc. No. 339) (Reply) and Gemalto filed a Sur-Reply (Doc. No. 349) (S-REPLY). The Court heard argument on February 12, 2013. For the reasons stated below, the Court RECOMMENDS that Defendants Motion be GRANTED. BACKGROUND Gemalto alleges Defendants infringe certain claims of the following patents: U.S. Patent No. 6,308,317 (the 317 Patent); U.S. Patent No. 7,117,485 (the 485 Patent); and U.S. Patent No. 7,818,727 (the 727 patent) (collectively patents-in-suit). (Doc. No. 1, at 2). Presently, Gemalto alleges Defendants directly infringe claims 1, 4, and 5 of the 317 Patent, and claims 38 and 39 of the 485 Patent. (Doc. No. 399, at 612). 2 Gemalto further alleges Defendants indirectly infringe claim 3 of the 727 Patent. Id. The patents-in-suit are all titled
1 Moving Defendants are: Exedea, Inc., Google Inc., HTC America Inc., HTC Corporation, Motorola Mobility LLC, Samsung Electronics Co., LTD., and Samsung Telecommunications America LLC (collectively Defendants). The moving Defendants are the only remaining Defendants in the instant action. 2 Claims 1, 4, and 5 of U.S. Patent No. 6,308,317; claims 38 and 39 of U.S. Patent No. 7,117,485; and claim 3 of U.S. Patent No. 7,818,727 are the six asserted claims represented by Gemalto as proceeding to trial. (Doc. No. 413). Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 1 of 12 PageID #: 13054 JA000004 Case: 13-1397 Document: 34 Page: 62 Filed: 07/09/2013 2
Using a High Level Programming Language with a Microcontroller, and they share the same specification and named inventors. The patents-in-suit are generally directed towards methods of implementing a high level programming language such as Java on resource constrained devices such as smartcards; specifically, they disclose a method of compiling Java source code such that the Java Card applet uses less byte code than a traditional Java applet. The disclosed method conserves memory and allows the application to run within the constrained environment on the smartcard. Claim 1 of the 317 patent is representative of the asserted claims and is set forth below: An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the terminal; a memory storing: an application derived from a program written in a high level programming language format wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form, the converting step comprising: recording all jumps and their destinations in the original byte codes; performing a conversion operation selected from the group: converting specific byte codes into equivalent generic byte codes; modifying byte code operands from references using identifying strings to references using unique identifiers; and renumbering byte codes in the compiled form to equivalent byte codes in an instruction set supported by an interpreter on the integrated circuit card; and relinking jumps for which the destination address is affected by the conversion operation; and an interpreter operable to interpret such an application derived from a program written in a high level programming language format; and a processor coupled to the memory, the processor configured to use the interpreter to interpret the application for execution and to use the communicator to communicate with the terminal.
317 Patent at 19:38-67 (Claim 1). Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 2 of 12 PageID #: 13055 JA000005 Case: 13-1397 Document: 34 Page: 63 Filed: 07/09/2013 3
Claim 1 of the 317 Patent is an independent claim from which claims 4 and 5 depend, and is related to independent claim 38 of the 485 Patent, from which claim 39 depends. Claim 1 of the 317 Patent and claim 38 of the 485 Patent are the only independent claims for which Gemalto alleges direct infringement. These claims, and their dependents, claim an integrated circuit card. (hereinafter integrated circuit card claims.). LEGAL STANDARD Summary judgment is proper if the movant shows that there is no genuine dispute as to any material fact and the movant is entitled to judgment as a matter of law. FED.R.CIV.P. 56(a); Celotex Corp. v. Catrett, 477 U.S. 317, 322 (1986). The standard for summary judgment in a patent case is no different. Nike Inc. v. Wolverine World Wide, Inc., 43 F.3d 644, 646 (Fed. Cir. 1994) (summary judgment is appropriate in a patent case, as in other cases, when there is no genuine issue as to any material fact and the moving party is entitled to judgment as a matter of law.). The determination of infringement requires a two-step analysis. First, the court construes the claims at issue to determine the scope and meaning at claim construction; next, the court compares the construed claims of the patent against the accused products. See, e.g., Business Objects, S.A. v. Microstrategy, Inc., 393 F.3d 1366, 1371 (Fed. Cir. 2004); Pitney Bowes, Inc. v. HewlettPackard Co., 182 F.3d 1298, 1304 (Fed. Cir. 1999). Importantly, claim construction is a question of law, whereas infringement is a question of fact. See Franks Casing Crew and Rental Tools, Inc. v. Weatherford Intl, Inc., 389 F.3d 1370, 1376 (Fed. Cir. 2004). Therefore, summary judgment of non-infringement can only be granted if, after viewing the alleged facts in the light most favorable to the non-movant, there is no genuine issue whether the accused device is encompassed by the claims. Pitney Bowes, 182 F.3d at 1304. Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 3 of 12 PageID #: 13056 JA000006 Case: 13-1397 Document: 34 Page: 64 Filed: 07/09/2013 4
DISCUSSION I. Literal Infringement As stated above, Gemalto alleges Defendants directly infringe claims 1, 4, and 5 of the 317, and claims 38 and 39 of the 485 patent. [W]hoever without authorization makes, uses, offers to sell, or sells any patented invention, within the United States or imports into the United States any patented invention during the term of the patent therefor [directly] infringes the patent. 35 U.S.C. 271(a) (2000). The plaintiff bears the burden of establishing, by a preponderance of the evidence, that the accused device directly infringes one or more claims of the patent. Advanced Cardiovascular Sys., Inc. v. Scimed Life Sys., Inc., 261 F.3d 1329, 1336 (Fed. Cir. 2001). Literal infringement requires that each and every limitation set forth in a claim appear in an accused product. Franks Casing Crew & Rental Tools, Inc. v. Weatherford Int'l, Inc., 389 F.3d 1370, 1378 (Fed. Cir. 2004). A. The Courts Claim Construction The Courts Markman Order leaves no genuine issue of material fact with respect to infringement. The Court construed integrated circuit card as a card containing a single semiconductor substrate having a central processing unit and all program memory. CLAIM CONSTRUCTION ORDER at 15 (Doc. No. 242). The parties presented a dispute as to the inclusion of all program memory, and the Court resolved the dispute in reference to the Courts construction of microcontroller, which presented essentially the same dispute. Id. at 12. In construing the term microcontroller, the Court found that while microcontrollers may access external components as argued by Plaintiff, all program memory necessary for execution of the compressed application must be located on the microcontroller. Id. at 8. The Court further stated Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 4 of 12 PageID #: 13057 JA000007 Case: 13-1397 Document: 34 Page: 65 Filed: 07/09/2013 5
that a microcontroller need only possess sufficient memory to run the Java code and [it] may access off chip memory to store and retrieve data stored in a static RAM. Id. at 10. Gemalto now presents a theory that cache memory of a microprocessor can satisfy the all program memory limitation. RESP. at 3. Defendants contend that summary judgment is proper because Gemaltos theory is without merit, as it contradicts the plain language of the Courts claim construction. MTN. at 16. This cache memory argument presented by Gemalto is entirely new to the Court and was not raised as a dispute during claim construction. Through its experts declaration, Gemalto contends that cache memory of a microprocessor meets the claim limitation by temporarily storing program instructions for program execution on-chip. Id. at 11 14. Defendants maintain that cache memory of a microprocessor cannot be all program memory as set forth in the Courts claim construction because if that were the case, a microcontroller could access any amount of off-chip memory and would therefore not be constrained by the amount of memory it can hold. MTN. at 16. This dispute regarding the Courts claim construction serves as the basis for Defendants instant motion. Although Gemaltos infringement theory as to cache memory is new, the fundamental dispute raised has already been resolved by the Court through its claim construction. In the context of the Courts construction, all program memory means memory permanently holding all program instructions necessary for execution of the compressed application, which includes main memory storage for application code (e.g., compiled Java byte code). CLAIM CONSTRUCTION ORDER at 8; see, e.g., 317 Patent 2:816; 2634 (noting that the microcontroller has built-in memory including: random access memory (RAM), read only memory (ROM), and electrically erasable programmable read only memory (EEPROM), and that because of the physical characteristics of a microcontroller being located on a single chip, it Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 5 of 12 PageID #: 13058 JA000008 Case: 13-1397 Document: 34 Page: 66 Filed: 07/09/2013 6
has considerably less memory than a microprocessor; a microcontroller typically has a small RAM of 0.1 to 2.0K, 2K to 8K of EEPROM, and 8K56K of ROM; [i]n a microcontroller, the amount of each kind of memory available is constrained by the amount of space on the integrated circuit used for each kind of memory). Cache memory temporarily holds instructions on-chip for quick execution. See, e.g., BOLDT DECL. at 7 ([c]ache memory operates at very high speed and provides the CPU on the microprocessor with on-chip access to relatively small blocks of data[c]ache memory on the microprocessors is volatile and loses its data when power is removed); SMITH DECL. at 15 (having the on-chip memory allows for the faster execution of because the speed of the L1 instruction cache compared to the slower access times of off-chip system memory). Gemaltos expert acknowledges that cache memory does not hold all program instructions and may need to access off-chip main memory to execute the application. Id. at 6 (If the particular program instruction resides in the L1 instruction cache, the L1 instruction cache will immediately provide the program instruction to the CPU[i]f the particular program instruction does not reside in the L1 instruction cache at that point, the cache controller will determine if the program instruction resides in the L2 cache[i]f the program instruction does not reside in the L2 cache, the cache controller will retrieve a block of instructions including the requested instruction from the off- chip main system memory (off-chip RAM or separate flash memory) and place a copy in the level 2 cache and in the level 1 instruction cache.) (emphasis added). In essence, there is no dispute that cache memory only temporarily holds program instructions loaded from main memory located off-chip. Pursuant to the Courts claim construction, however, on-chip memory space only temporarily holding program instructions loaded from off-chip main Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 6 of 12 PageID #: 13059 JA000009 Case: 13-1397 Document: 34 Page: 67 Filed: 07/09/2013 7
memory does not constitute all program memory necessary for execution. Also necessary for execution is memory space permanently holding all program instructions. Recognizing that cache memory at times must retrieve off-chip program instructions, Gemaltos expert characterizes these program instructions as data. SMITH DECL. at 6. Presumably, such a characterization is made in light of the Courts statement in its Markman Order that the microcontroller may access off chip memory to store and retrieve data stored in a static RAM. CLAIM CONSTRUCTION ORDER at 10. However, this characterization of data is not consistent with the Courts claim construction. Under the Courts construction, the code of an application program (i.e. program instructions, such as Java byte code) is expressly distinguished from data used by the application program. Id. at 810; see 317 Patent 16: 14; 18: 1324 (distinguishing data from applications.). Gemaltos argument vitiates the Courts construction by asserting on the one hand all program instructions (i.e. all application program code necessary for execution) need only be temporarily stored on-chip in the L1 cache, and on the other hand, when they are not, they are not program instructions. In making this argument, Gemaltos expert has re-construed all program memory to constitute only the temporary program instruction storage memory space provided by the L1 cache, from which the program instructions are fetched for execution by the CPU. SMITH DECL. at 7 (it is my opinion that the only memory that constitutes program memory is the L1 instruction cache). Gemaltos expert contends that main memory, where the program instructions are permanently stored, is not program memory because the CPU never directly executes from main memory. SMITH DECL. at 7. This interpretation impermissibly recasts the Courts construction to merely require memory space from which the CPU fetches program instructions for execution and not memory space where program instructions are permanently stored. Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 7 of 12 PageID #: 13060 JA000010 Case: 13-1397 Document: 34 Page: 68 Filed: 07/09/2013 8
Through its argument, Gemalto invites the Court to accept the following logic: the only memory from which the CPU fetches program instructions at the time of program execution is the L1 cache; therefore, the only memory that can constitute program memory is the L1 cache; accordingly, because all program memory is on-chip in L1 cache, the all program memory claim limitation is satisfied. Such an approach manufactures an infringement theory by circumventing the Courts unambiguous claim construction order. See CLAIM CONSTRUCTION ORDER at 8 (all program memory necessary for execution of the compressed application must be located on the microcontroller.). The Courts construction does not state that a memory space becomes program memory when program instructions are located on-chip and fetched by the CPU for execution. The Courts construction and supporting analysis make clear that all program memory necessary for execution necessarily includes main memory where program instructions are permanently stored and are accessed for loading into a temporary memory space that is in turn accessed by the CPU in fetching program instructions. Further, the Courts analysis does not support a view that program instructions stored in off-chip main memory are data and thus off-chip main memory merely serves as data memory rather than program memory. Accordingly, the Courts claim construction resolved this matter. B. Accused Devices As to the Defendants accused devices, there is no real dispute raised regarding their operation. Rather, as addressed above, the parties dispute lies in their disagreement regarding the Courts claim construction. As the premise of the instant motion, Defendants argue that their accused devices do not contain all program memory on a single semiconductor substrate because they require off chip memory to run the accused Dalvik and Android applications. MTN at 1415, 22. This memory includes ROM, EEPROM, and RAM memory. Id. at 15. Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 8 of 12 PageID #: 13061 JA000011 Case: 13-1397 Document: 34 Page: 69 Filed: 07/09/2013 9
Gemalto does not dispute this, but rather argues that Defendants engage in syllogism by contending the accused devices do not infringe because they can make use of external memory. RESP. at 19. However, by storing program instructions off-chip in main memory, the undisputed operation of Defendants accused devices does not meet the claim limitation for integrated circuit card requiring a single semiconductor substrate having a central processing unit and all program memory. Therefore, by virtue of the fact that Defendants devices store program instructions off-chip and access those off-chip instructions to run the accused applications, they cannot literally infringe. II. Doctrine of Equivalents To support a finding of infringement under the doctrine of equivalents (DOE), a patentee must either: (1) demonstrate an insubstantial difference between the claimed invention and the accused product or method; or (2) satisfy the function, way, result test. Aquatex Industries, Inc. v. Techniche Solutions, 479 F.3d 1320, 1326 (Fed. Cir. 2007) (citing Graver Tank & Mfg. v. Linde Air Prods. Co., 339 U.S. 605, 608, 70 S.Ct. 854, 94 L.Ed. 1097 (1950)). Thus, the proper inquiry for the Court is whether an asserted equivalent represents an insubstantial difference from the claimed element, or whether the substitute element matches the function, way, and result of the claimed element. Deere & Co. v. Bush Hog, LLC, 703 F.3d 1349, 1356 (Fed. Cir. 2012), quoting Warner-Jenkinson Co. v. Hilton Davis Chem. Co., 520 U.S. 17, 40 (1997). If no reasonable jury could find equivalence, then the court must grant summary judgment of no infringement under the doctrine of equivalents. Deere, 703 F.3d at 1356. For the reasons stated above as to why Gemaltos cache memory argument is not viable for literal infringement, Gemaltos argument for infringement under the doctrine of equivalents similarly cannot withstand summary judgment. Gemalto states that 97% of the time the Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 9 of 12 PageID #: 13062 JA000012 Case: 13-1397 Document: 34 Page: 70 Filed: 07/09/2013 10
instruction code to be executed for a given application is stored in the on-chip cache memory before it is requested or needed by the CPU and argues that that scenario represents an insubstantial difference. RESP. at 22. If 100% execution on the cache does not satisfy the claim limitation, 97% cannot. This argument similarly fails under the Courts construction, as described above. Further, Gemaltos argument fails to comply with the all-elements rule and vitiates the all program memory requirement of the integrated circuit card limitation. By arguing that the temporary storage of program instructions on-chip in cache memory is insubstantially different from permanent storage of program instructions on-chip in a main memory, Gemalto ignores the Courts claim construction. The Courts claim construction establishes a specific structural requirement that defines an integrated circuit card as used in the patents-in-suit. To permit that requirement to be satisfied based not on where the memory structure permanently holding the program instructions (i.e. all program memory) is located, but rather on where the program instructions can be temporarily held, reads the integrated circuit card limitation, as construed by the Court, completely out of the claim. Set against the Courts construction of the integrated circuit card limitation, the cache memory of Defendants devices cannot be merely an insubstantial difference. As such, Gemaltos theory of equivalence is impermissible. Warner- Jenkinson Co. v. Hilton Davis Chem. Co., 520 U.S. 17, 39 n. 8 (1997) (under the particular facts of a caseif a theory of equivalence would entirely vitiate a particular claim element, partial or complete judgment should be rendered by the court); DePuy Spine, Inc. v. Medtronic Sofamor Danek, Inc., 469 F.3d 1005, 1017 (Fed. Cir. 2006) (in certain instances, the all elements rule forecloses resort to the doctrine of equivalents because, on the facts or theories presented in a case, a limitation would be read completely out of the claim i.e., the limitation Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 10 of 12 PageID #: 13063 JA000013 Case: 13-1397 Document: 34 Page: 71 Filed: 07/09/2013 11
would be effectively removed or vitiated.); Moore U.S.A. Inc. v. Standard Register Company, 229 F.3d 1091, 1106 (Fed. Cir. 2000) ([s]econd, it would defy logic to conclude that a minoritythe very antithesis of a majoritycould be insubstantially different from a claim limitation requiring a majority, and no reasonable juror could find otherwise.). III. Indirect Infringement Indirect infringement requires a showing of direct infringement. Met-Coil Systems Corp. v. Korners Unlimited, Inc., 803 F. 2d 684, 687 (Fed. Cir. 1986) (Absent direct infringement of the patent claims, there can be neither contributory infringement nor inducement of infringement). Accordingly, because the Court finds no direct infringement of the patents-in- suit, summary judgment is also proper with respect to Gemaltos indirect claims. 3
Defendants accused devices do not meet a limitation of each claim that Gemalto asserts; therefore, the Court RECOMMENDS GRANTING Defendants Motion for Summary Judgment of Non-Infringement. CONCLUSION The Court has interpreted the asserted claims of the patents-in-suit to require a single semiconductor substrate with a central processing unit and all program memory. For the reasons explained herein, none of the accused devices meet this limitation either literally or under the doctrine of equivalents. Therefore, the Court recommends GRANTING Defendants Motion. Within fourteen (14) days after receipt of the Magistrate Judges Report, any party may serve and file written objections to the findings and recommendations contained in the Report. A
3 Gemalto asserts indirect infringement of claim 3 of the 727 Patent. (Doc. No. 399, at 612). Claim 3 of the 727 Patent discloses a programmable device. 727 Patent at 19: 1226. The Court found that a programmable device is a microcontroller and therefore construed the terms in the same manner, requiring a single semiconductor substrate integrating electronic circuit components that includes a central processing unit and all program memory making it suitable for use as an embedded system. CLAIM CONSTRUCTION ORDER at 1617 (emphasis added). For the reasons discussed herein, the Court has resolved this dispute and finds Gemaltos argument is without merit. Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 11 of 12 PageID #: 13064 JA000014 Case: 13-1397 Document: 34 Page: 72 Filed: 07/09/2013 12
partys failure to file written objections to the findings, conclusions and recommendations contained in this Report within fourteen (14) days after being served with a copy shall bar that party from de novo review by the district judge of those findings, conclusions and recommendations and, except on grounds of plain error, from appellate review of unobjected-to factual findings and legal conclusions accepted and adopted by the district court. Douglass v. United States Auto. Assn, 79 F.3d 1415, 1430 (5th Cir. 1996). Case 6:10-cv-00561-LED-JDL Document 433 Filed 02/25/13 Page 12 of 12 PageID #: 13065 JA000015 Case: 13-1397 Document: 34 Page: 73 Filed: 07/09/2013 .
SIGNED this 19th day of December, 2011. So ORDERED and SIGNED this 25th day of February, 2013. 1
IN THE UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF TEXAS TYLER DIVISION
GEMALTO S.A.,
Plaintiff,
vs.
HTC CORPORATION, et al.,
Defendants.
CASE NO. 6:10-CV-561 LED-JDL
ORDER The above entitled civil action was referred to United States Magistrate Judge John D. Love pursuant to 28 U.S.C. 636. The Memorandum Opinion and Order of the Magistrate Judge (Doc. No. 242) (Opinion), which contains his construction of the disputed terms in the patents-in-suit 1 has been presented for consideration. Plaintiff Gemalto S.A. (Gemalto) has objected to the Opinion under Federal Rule of Civil Procedure 72(a) (Doc. No. 244). Defendants responded (Doc. No. 245). Gemaltos objections largely reassert its arguments set forth in the claim construction briefing. The Court is not persuaded it should disturb the Magistrate Judges ruling. Accordingly, the Court overrules Gemaltos objections and ADOPTS the Opinion of the United States Magistrate Judge as the opinion of this Court.
1 The Opinion construes the disputed terms in U.S. Patent Nos. 6,308,317; 7,117,485; and 7,818,727. __________________________________ LEONARD DAVIS UNITED STATES DISTRICT JUDGE So ORDERED and SIGNED this 9th day of August, 2012. Case 6:10-cv-00561-LED-JDL Document 251 Filed 08/09/12 Page 1 of 1 PageID #: 6277 JA000016 Case: 13-1397 Document: 34 Page: 74 Filed: 07/09/2013 1
IN THE UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF TEXAS TYLER DIVISION
GEMALTO S.A.,
Plaintiff,
vs.
HTC CORPORATION, et al.,
Defendants.
CASE NO. 6:10-CV-561 LED-JDL
MEMORANDUM OPINION AND ORDER This claim construction opinion construes the disputed claim terms in U.S. Patent Nos. 6,308,317 (the 317 patent); 7,117,485 (the 485 patent); and 7,818,727 (the 727 patent) 1
(collectively, the patents-in-suit). The patents-in-suit all share the same title, Using a High Level Programming Language with a Microcontroller. On May 3, 2012, the Court held a claim construction hearing to construe the disputed terms. For the reasons stated herein, the Court adopts the constructions set forth below. OVERVIEW OF THE PATENTS The patents-in-suit are generally directed towards methods of implementing a high level programming language such as Java on resource constrained devices such as smartcards. The patents-in-suit disclose a method of compiling Java source code such that the Java Card applet uses less byte code than a traditional Java applet. This process conserves memory, which is a necessity of operating in resource constrained devices like smartcards. The patents describe a Java application with Java source code files that are compiled to produce application class files.
1 The 727 patent is a continuation of the 485 patent which is a continuation of the 317 patent, which claims priority to U.S. provisional application ser. No. 60/029,057. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 1 of 47 PageID #: 6122 JA000017 Case: 13-1397 Document: 34 Page: 75 Filed: 07/09/2013 2
These application class files are then fed into a card class file converter, which consolidates and compresses the files to produce a single class file, which is then loaded to the smart card microcontroller. In other words, the patents-in-suit teach a method for converting Java byte codes into byte codes that minimize the computing resources consumed by the application and the Java Virtual Machine so that the application can run within the constrained environment of a smartcard. Claim 1 of the 317 patent is representative of the asserted claims: An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the terminal; a memory storing: an application derived from a program written in a high level programming language format wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form, the converting step comprising: recording all jumps and their destinations in the original byte codes; performing a conversion operation selected from the group: converting specific byte codes into equivalent generic byte codes; modifying byte code operands from references using identifying strings to references using unique identifiers; and renumbering byte codes in the compiled form to equivalent byte codes in an instruction set supported by an interpreter on the integrated circuit card; and relinking jumps for which the destination address is affected by the conversion operation; and an interpreter operable to interpret such an application derived from a program written in a high level programming language format; and a processor coupled to the memory, the processor configured to use the interpreter to interpret the application for execution and to use the communicator to communicate with the terminal. CLAIM CONSTRUCTION PRINCIPLES It is a bedrock principle of patent law that the claims of a patent define the invention to which the patentee is entitled the right to exclude. Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (quoting Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 2 of 47 PageID #: 6123 JA000018 Case: 13-1397 Document: 34 Page: 76 Filed: 07/09/2013 3
381 F.3d 1111, 1115 (Fed. Cir. 2004)). The Court examines a patents intrinsic evidence to define the patented inventions scope. Id. at 1313-1314; Bell Atl. Network Servs., Inc. v. Covad Commcns Group, Inc., 262 F.3d 1258, 1267 (Fed. Cir. 2001). Intrinsic evidence includes the claims, the rest of the specification and the prosecution history. Phillips, 415 F.3d at 1312-13; Bell Atl. Network Servs., 262 F.3d at 1267. The Court gives claim terms their ordinary and customary meaning as understood by one of ordinary skill in the art at the time of the invention. Phillips, 415 F.3d at 1312-13; Alloc, Inc. v. Intl Trade Commn, 342 F.3d 1361, 1368 (Fed. Cir. 2003). Claim language guides the Courts construction of claim terms. Phillips, 415 F.3d at 1314. [T]he context in which a term is used in the asserted claim can be highly instructive. Id. Other claims, asserted and unasserted, can provide additional instruction because terms are normally used consistently throughout the patent. Id. Differences among claims, such as additional limitations in dependent claims, can provide further guidance. Id. [C]laims must be read in view of the specification, of which they are a part. Id. (quoting Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995)). [T]he specification is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term. Id. (quoting Vitronics Corp.v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)); Teleflex. Inc. v. Ficosa N. Am. Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). In the specification, a patentee may define his own terms, give a claim term a different meaning that it would otherwise possess, or disclaim or disavow some claim scope. Phillips, 415 F.3d at 1316. Although the Court generally presumes terms possess their ordinary meaning, this presumption can be overcome by statements of clear disclaimer. See SciMed Life Sys., Inc. v. Advanced Cardiovascular Sys., Inc., 242 F.3d Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 3 of 47 PageID #: 6124 JA000019 Case: 13-1397 Document: 34 Page: 77 Filed: 07/09/2013 4
1337, 1343-44 (Fed. Cir. 2001). This presumption does not arise when the patentee acts as his own lexicographer. See Irdeto Access, Inc. v. EchoStar Satellite Corp., 383 F.3d 1295, 1301 (Fed. Cir. 2004). The specification may also resolve ambiguous claim terms where the ordinary and accustomed meaning of the words used in the claims lack sufficient clarity to permit the scope of the claim to be ascertained from the words alone. Teleflex, Inc., 299 F.3d at 1325. For example, [a] claim interpretation that excludes a preferred embodiment from the scope of the claim is rarely, if ever, correct. Globetrotter Software, Inc. v. Elam Computer Group Inc., 362 F.3d 1367, 1381 (Fed. Cir. 2004) (quoting Vitronics Corp., 90 F.3d at 1583). But, [a]lthough the specification may aid the court in interpreting the meaning of disputed language in the claims, particular embodiments and examples appearing in the specification will not generally be read into the claims. Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir. 1988); see also Phillips, 415 F.3d at 1323. The prosecution history is another tool to supply the proper context for claim construction because a patentee may define a term during prosecution of the patent. Home Diagnostics Inc. v. LifeScan, Inc., 381 F.3d 1352, 1356 (Fed. Cir. 2004) (As in the case of the specification, a patent applicant may define a term in prosecuting a patent). The well- established doctrine of prosecution disclaimer preclud[es] patentees from recapturing through claim interpretation specific meanings disclaimed during prosecution. Omega Engg Inc. v. Raytek Corp., 334 F.3d 1314, 1323 (Fed. Cir. 2003). The prosecution history must show that the patentee clearly and unambiguously disclaimed or disavowed the proposed interpretation during prosecution to obtain claim allowance. Middleton Inc. v. 3M Co., 311 F.3d 1384, 1388 (Fed. Cir. 2002). Indeed, by distinguishing the claimed invention over the prior art, an Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 4 of 47 PageID #: 6125 JA000020 Case: 13-1397 Document: 34 Page: 78 Filed: 07/09/2013 5
applicant is indicating what the claims do not cover. Spectrum Intl v. Sterilite Corp., 164 F.3d 1372, 1378-79 (Fed. Cir. 1988) (quotation omitted). As a basic principle of claim interpretation, prosecution disclaimer promotes the public notice function of the intrinsic evidence and protects the publics reliance on definitive statements made during prosecution. Omega Engg, Inc., 334 F.3d at 1324. Although, less significant than the intrinsic record in determining the legally operative meaning of claim language, the Court may rely on extrinsic evidence to shed useful light on the relevant art. Phillips, 415 F.3d at 1317 (quotation omitted). Technical dictionaries and treatises may help the Court understand the underlying technology and the manner in which one skilled in the art might use claim terms, but such sources may also provide overly broad definitions or may not be indicative of how terms are used in the patent. Id. at 1318. Similarly, expert testimony may aid the Court in determining the particular meaning of a term in the pertinent field, but conclusory, unsupported assertions by experts as to the definition of a claim term are not useful. Id. Generally, extrinsic evidence is less reliable than the patent and its prosecution history in determining how to read claim terms. Id. The patent in suit may contain means-plus-function limitations that require construction. Where a claim limitation is expressed in means-plus-function language and does not recite definite structure in support of its function, the limitation is subject to 35 U.S.C. 112 6. Braun Med., Inc. v. Abbott Labs., 124 F.3d 1419, 1424 (Fed. Cir. 1997). In relevant part, 112 mandates that such a claim limitation be construed to cover the corresponding structure . . . described in the specification and equivalents thereof. Id. (citing 35 U.S.C. 112 6. ). Accordingly, when faced with means-plus-function limitations, courts must turn to the written Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 5 of 47 PageID #: 6126 JA000021 Case: 13-1397 Document: 34 Page: 79 Filed: 07/09/2013 6
description of the patent to find the structure that corresponds to the means recited in the [limitations]. Id. Construing a means-plus-function limitation involves two inquiries. The first step requires a determination of the function of the means-plus-function limitation. Medtronic, Inc. v. Advanced Cardiovascular Sys., Inc., 248 F.3d 1303, 1311 (Fed. Cir. 2001). Once a court has determined the limitations function, the next step is to determine the corresponding structure disclosed in the specification and equivalents thereof. Medtronic, 248 F.3d at 1311. A structure is corresponding only if the specification or prosecution history clearly links or associates that structure to the function recited in the claim. Id. Moreover, the focus of the corresponding structure inquiry is not merely whether a structure is capable of performing the recited function, but rather whether the corresponding structure is clearly linked or associated with the [recited] function. Id. DISCUSSION I. Hardware Terms a. microcontroller 2
Plaintiffs Proposed Construction Defendants Proposed Construction a device designed specifically for embedded applications that includes a central processing unit, memory and other functional elements on a single semiconductor substrate, or integrated circuit a single semiconductor substrate or integrated circuit designed specifically for embedded applications that includes a central processing unit, memory and other functional elements, and that does not require external memory to function properly; not a microprocessor
There are two key disputes with regards to the microcontroller term: (1) to what extent a microcontroller may access external memory and (2) whether the preamble of claim 1 of the 485 patent 3 is limiting.
2 The term microcontroller is found in the 317 patent at claims 58, 59, 62, 63, 65-69, 73, 75, 77-79, 81, 87-89, 91, and 92; and the 485 patent at claims 1, 2, 6-11, 14, 16, 18, 20-22, and 25. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 6 of 47 PageID #: 6127 JA000022 Case: 13-1397 Document: 34 Page: 80 Filed: 07/09/2013 7
i. Courts Construction of Microcontroller The parties agree that a microcontroller includes a central processing unit, memory, and other functional elements on a single semiconductor substrate or integrated circuit. See, e.g., PLAINTIFFS OPENING CLAIM CONSTRUCTION BRIEF (Doc. No. 163) (PLAINTIFFS BRIEF ) at 13; DEFENDANTS RESPONSIVE CLAIM CONSTRUCTION BRIEF (Doc. No. 180) (RESPONSE) at 6. At the Claim Construction Hearing, the Court proposed that microcontroller should be construed as a single semiconductor substrate integrating electronic circuit components that includes a central processing unit and all program memory making it suitable for use as an embedded system. Although Defendants originally proposed a construction that included language defining microcontroller as not a microprocessor, Defendants agreed at the Claim Construction Hearing that the Courts proposed construction was proper. MARKMAN TRANSCRIPT at 22:11-13. Plaintiff contends that the specification defines microcontroller as including a central processing unit, memory, and other functional elements, all on a single semiconductor substrate or integrated circuit (e.g., a chip). 317 patent at 2:2-5. Further, Plaintiff argues that the specification affirmatively states a microcontroller requires external components: [d]ue to the small number of external components required and their small size, microcontrollers . . . . PLAINTIFFS BRIEF at 14 (quoting 317 patent at 2:35-36) (alterations as in PLAINTIFFS BRIEF). Thus, for Plaintiff, a microcontroller need not house all program memory because a microcontroller is required to have external components.
3 In its briefing, Plaintiff argues that the preamble of Claim 7 of the 485 patent should not be limiting. PLAINTIFFS BRIEF at 13 n.6. However, at the Claim Construction Hearing, the parties agreed the preamble of claim 7 of the 485 patent is not limiting but disputed whether the preamble of claim 1 of the 485 patent is limiting. See CLAIM CONSTRUCTION HEARING TRANSCRIPT (Doc. No. 214) (MARKMAN TRANSCRIPT) at 76. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 7 of 47 PageID #: 6128 JA000023 Case: 13-1397 Document: 34 Page: 81 Filed: 07/09/2013 8
The Court finds that while microcontrollers may access external components as argued by Plaintiff, all program memory necessary for execution of the compressed application must be located on the microcontroller. This construction finds support both in the specification and the extrinsic evidence cited by both parties. Looking first to the specification, the patents-in-suit teach that unlike microprocessors, microcontrollers have limited access to memory: Microcontrollers differ from microprocessors in many ways. For example, a microprocessor typically has a central processing unit that requires certain external components (e.g., memory, input controls and output controls) to function properly. A typical microprocessor can access from a megabyte to a gigabyte of memory, and is capable of processing 16, 32, or 64 bits of information or more with a single instruction. In contrast to the microprocessor, a microcontroller includes a central processing unit, memory and other functional elements, all on a single semiconductor substrate, or integrated circuit (e.g., a chip). As compared to the relatively large external memory accessed by the microprocessor, the typical microcontroller accesses a much smaller memory. A typical microcontroller can access one to sixty-four kilobytes of built-in memory, with sixteen kilobytes being common. 317 patent at 1:62 2:10 (emphasis added); see also id. at 2:26-34 (noting that because of the physical characteristics of a microcontroller being located on a single chip, it has considerably less memory than a microprocessor); id. at 2:14-16 (In a microcontroller, the amount of each kind of memory available is constrained by the amount of space on the integrated circuit used for each kind of memory). Additionally, the specification teaches that prior to the 317 patent, Java platforms generally operated on microprocessor-based computers, with access to relatively large amounts of memory and hard disc storage space. 317 patent at 1:55-57. The patentee addressed the problem of fitting the operating system, application code, and a Java Virtual Machine to interpret the Java byte codes into machine code on the microcontroller. PLAINTIFFS BRIEF at 3. Indeed, the CEO of Sun Microsystems, the creator of the Java programing language, characterized the problem as fitting Java technology inside smartcards was like playing golf in a phone booth. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 8 of 47 PageID #: 6129 JA000024 Case: 13-1397 Document: 34 Page: 82 Filed: 07/09/2013 9
EX. B TO PLAINTIFFS BRIEF, JAVACARD TECHNOLOGY GROWS UP SMART, (DOC. NO. 163-3); PLAINTIFFS BRIEF at 3. Thus, an interpretation of microcontroller that permits access to off chip memory would eviscerate the distinction between operating high level programming language on an integrated circuit card or microcontroller and the conventional platforms that existed at the time of the invention. This understanding is further supported by arguments made in the prosecution history. The applicants repeatedly distinguished between existing microprocessor systems that had the ability to run high level languages at the time of the invention and microcontrollers such as smartcards or integrated circuit cards. For example, in their appeal brief to the Board of Patent Appeals and Interferences, the applicants conceded that the steps to compile and run Java were well known in the prior art. See Ex. E to RESPONSE (Doc. No. 180-5) (485 PROSECUTION HISTORY) at GEM3763. However, [a]t the time of the invention, the typical Java Virtual Machine required over 1MB of memory. Id. at GEM3766. In contrast, a typical microcontroller at the time of filing only had approximately 0.1 to 2.0 KB of RAM, 2 to 8KB of EEPROM, and 8 to 56K ROM. 317 patent at 2:26-34. Moreover, the patentee highlighted this distinction in arguments made to the Patent Office during the Reexamination of the 317 patent: [U]sing Java as an example, providing Java technology onto smart cards would be very challenging due to the size constrains of smart cards as constrained to the minimum requirements of Java. The Java run time environment, the JRE, requires a system that has a minimum 32 MB of memory, 125 of free disk space. However, in 1996 smart cards only had 512 bytes, not kilobytes or megabytes, just 512 bytes of RAM and 4K bytes of EEPPROM. EX. G. to RESPONSE (Doc. No. 180-7) (REEXAM EXERPTS) at GEM4515. Thus, for the patentee, one of the key aspects of the invention disclosed in the patents-in-suit is its ability to operate in an environment with a finite amount of memory. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 9 of 47 PageID #: 6130 JA000025 Case: 13-1397 Document: 34 Page: 83 Filed: 07/09/2013 10
Lastly, interpreting microcontroller to require all program memory to be located on the chip is supported by the extrinsic evidence. Plaintiffs own evidence, The Microcontroller Idea Book, explains that a microcontroller is limited by the amount of memory it can hold: To make a complete computer, a microprocessor requires memory for storing data and programs, and input/output (I/P) interfaces for connecting external devices like keyboards and displays.
In contrast, a microcontroller is a single-chip computer because it contains memory and I/O interfaces in addition to the CPU. Because the amount of memory and interfaces that can fit on a single chip is limited, microcontrollers tend to be used in smaller systems that require little more than the microcontroller and a few support components. JAN AXELSON, THE MICROCONTROLLER IDEA BOOK 2 (1997) (Doc. No. 163-13) (MICROCONTROLLER IDEA BOOK). Plaintiff argues that the specification and extrinsic evidence show that microcontrollers may use external memory. See PLAINTIFFS BRIEF at 14 (quoting 317 patent at 2:35-36) (In fact the specification affirmatively states a microcontroller requires external components: [d]ue to the small number of external components required and their small size, microcontrollers ); PLAINTIFFS REPLY TO DEFENDANTS RESPONSIVE CLAIM CONSTRUCTION BRIEF (Doc. No. 189) (REPLY) at 3. The Courts construction does not, however, prevent a microcontroller from accessing any external memory. Under the Courts construction, a microcontroller need only possess sufficient memory to run the Java code 4 in accordance with the patentees invention. For example, a microcontroller may access off chip memory to store and retrieve data stored in a static RAM. See REPLY at 3 (citing Ex. BB, THE MICROCONTROLLER IDEA BOOK, at 24). 5
4 The Court uses Java code throughout the opinion only as an example of a high level programming language implemented on the microcontroller and does not intend to limit the claims to only Java embodiments. 5 Plaintiff also relies heavily on various unrelated patents that describe microcontroller. See PLAINTIFFS BRIEF at 14 n.8. In construing microcontroller, the Court has considered these references, but nevertheless finds that a person having ordinary skill in the art would interpret microcontroller as written in the 317 patent and its progeny as described above. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 10 of 47 PageID #: 6131 JA000026 Case: 13-1397 Document: 34 Page: 84 Filed: 07/09/2013 11
Furthermore, Plaintiffs arguments that the specification qualifies its description of microcontrollers as only typical microcontrollers and therefore should not limit microcontroller is similarly unavailing. As explained above, neither the specification nor the extrinsic record supports the conclusion that a microcontroller can function with program memory located off chip. In conclusion, the Court construes microcontroller as a single semiconductor substrate integrating electronic circuit components that includes a central processing unit and all program memory making it suitable for use as an embedded system. ii. The Preamble of Claim 1 of the 485 Patent is Limiting Defendants argue that the preamble of claim 1 of the 485 patent is limiting. See RESPONSE at 10; MARKMAN TRANSCRIPT at 76:16-22. Generally, a preamble is considered limiting when it recites essential structure or steps, or if it is necessary to give life, meaning and vitality to claims or counts. Catalina Marketing Intl. v. Coolsavings.com, Inc., 289 F.3d 801, 808 (Fed. Cir. 2002) (quoting Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1309 (Fed. Cir. 1999)); Kropa v. Robie, 187 F.2d 150, 1952 (C.C.P.A. 1951). Moreover, clear reliance on the preamble during prosecution to distinguish the claimed invention from the prior art transforms the preamble into a claim limitation because such reliance indicates use of the preamble to define, in part, the claimed invention. Catalina Marketing Intl, 182 F.3d at 808. However, a preamble is not limiting where a patentee defines a structurally complete invention in the claim body and uses the preamble only to state a purpose or intended use for the invention. Id. (quoting Rowe v. Dror, 112 F.3d 473, 478 (Fed. Cir. 1997)). As explained above in the context of the Courts construction of microcontroller, the patentee repeatedly emphasizes in both the specification and the prosecution history, that a key Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 11 of 47 PageID #: 6132 JA000027 Case: 13-1397 Document: 34 Page: 85 Filed: 07/09/2013 12
aspect of the invention was the ability to fit a high level programming language such as Java on resource constrained devices such as a microcontroller. See, e.g., 485 PROSECUTION HISTORY at GEM3725 (Applicants recognized the difficulty in operating Java (or other high level language) programs within the limited resources of an integrated circuit card or other microcontroller). Thus, the Court finds that the term microcontroller as used in the preamble of claim 1 of the 485 patent breathes life and meaning into the claim and is therefore limiting. b. integrated circuit card 6
Plaintiffs Proposed Construction Defendants Proposed Construction an integrated circuit containing a central processing unit, memory and other functional elements on a base a card containing a central processing unit, memory and other functional elements, all on a single semiconductor substrate or integrated circuit, that does not require external memory to function properly; not a microprocessor system; OR a card containing a microcontroller The essential dispute between the parties is whether the integrated circuit card must contain all program memory and whether the integrated circuit card is a card or can also be a base. At the Claim Construction Hearing, the Court proposed a card containing a single semiconductor substrate having a central processing unit and all program memory. Defendants agreed with the Courts construction; however, Plaintiff objected based on the Courts inclusion of the all program memory limitation and the Courts limiting of integrated circuit card to a card. First, Plaintiffs arguments regarding all program memory are essentially the same as they were in the context of microcontroller. The Court rejects Plaintiffs arguments for the reasons discussed above. Further, the specification discloses an integrated circuit card that includes a communicator and a memory that stores an interpreter and first instructions of a first
6 The term integrated circuit card is found in the 317 patent at claims 1, 4-11, 13-15, 22, 24, 25, 30, 31, 55, 64, 84-86, 93, & 94; and the 485 patent at claims 38, 39, 40, 42, and 43. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 12 of 47 PageID #: 6133 JA000028 Case: 13-1397 Document: 34 Page: 86 Filed: 07/09/2013 13
application. 317 patent at 5:31-33. The integrated circuit card also includes a processor that is coupled to the memory and is configured to use the interpreter to execute the first instructions to communicate with the terminal via the communicator. Id. at 5:36-40. Thus, the integrated circuit card contains the memory necessary to execute the condensed high level program. Second, Plaintiff seeks to read the word card out of the claims by interpreting integrated circuit card as an integrated circuit . . . on a base. The plain language of the term integrated circuit card requires a card. This is supported by the specification which repeatedly refers to an integrated circuit card as a card. See, e.g., 317 patent at 18:62 19:4 (Fig. 21 shows an integrated circuit card, or smart card, which includes a microcontroller 210 that is mounted to a plastic card 212. The plastic card 212 has approximately the same form factor as a typical credit card); id. at 2:35-41 (noting that microcontrollers frequently are used in integrated circuit cards, such as smart cards and that these include both contact-based and contactless cards); id. at 2:55-60 (integrated circuit cards include debit cards); id. at 7:57-59 (In some embodiments, the microcontroller, memory and communicator are embedded in a plastic card that has substantially the same dimensions as a typical credit card). Plaintiff argues that an integrated circuit card need not be a card at all, but may be a base. Plaintiff relies on the following portion of the specification to support its conclusion that an integrated circuit card may actually be a base rather than a card: In some embodiments, the microcontroller, memory and communicator are embedded in a plastic card that has substantially the same dimensions as a typical credit card. In other embodiments, the microcontroller, memory and communicator are mounted within bases other than a plastic card, such as jewelry (e.g., watches, rings or bracelets), automotive equipment, telecommunication equipment (e.g., subscriber identity module (SIM) cards), security devices (e.g., cryptographic modules) and appliances. 317 patent at 7:57-65. Specifically, Plaintiff argues that [t]he elements of an integrated circuit card do not have to be mounted on a plastic card or in the case of a microcontroller a single Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 13 of 47 PageID #: 6134 JA000029 Case: 13-1397 Document: 34 Page: 87 Filed: 07/09/2013 14
semiconductor substrate: [i]n other embodiments, mounted within bases other than a plastic card. PLAINTIFFS BRIEF at 16 (quoting 317 patent at 7:59-62) (alterations within quotation in original). However, as Defendants point out, when read in context with the surrounding language, this portion of the specification merely shows that microcontrollers can be used in embodiments not embedded in a plastic card. Thus, while a microcontroller may be mounted on other surfaces, this portion of the specification does little to persuade the Court that an integrated circuit card need not be a card. Rather, an integrated circuit card must have its components on a single semiconductor substrate. See 317 patent at 2:35-37 (Due to the small number of external components required and their small size, microcontrollers frequently are used in integrated circuit cards, such as smart cards). Lastly, Plaintiff argued at the Claim Construction Hearing that an integrated circuit card is intended to be broader than simply a microcontroller. In support, Plaintiff points to portions of the specification that generally describe an integrated circuit card as including a processor that is coupled to the memory and including other functional elements. See, e.g., 317 patent at 5:36-40. In other words, Plaintiff argues that an integrated circuit card is merely a base with a processor on it. However, Plaintiff concedes in its opening claim construction brief that the Integrated Circuit Card Claims . . . narrowly refer to a specific type of device that includes a microcontroller and can use high level programming language i.e., an integrated circuit card, as shown in the embodiment in Figure 21. PLAINTIFFS BRIEF at 27-28 (citing 317 patent at 18:65 19:4); see also 317 patent at Fig. 21 (depicting an integrated circuit card as a card); PLAINTIFFS BRIEF at 28 (The prosecution history shows that the 317 patent was always prosecuted as including two classes of claims: a broad set directed to microcontrollers on devices generally, and a narrower set directed to microcontrollers on integrated circuit cards Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 14 of 47 PageID #: 6135 JA000030 Case: 13-1397 Document: 34 Page: 88 Filed: 07/09/2013 15
specifically). Accordingly, the Court rejects Plaintiffs invitation to construe integrated circuit card broadly and construes integrated circuit card as a card containing a single semiconductor substrate having a central processing unit and all program memory. c. programmable device 7
Plaintiffs Proposed Construction Defendants Proposed Construction This term does not need construction. To the extent that the term is construed, it should be given its plain and ordinary meaning, such as: a device that can execute a computer program integrated circuit card or other device controlled by a microcontroller; not a microprocessor-based system At the Claim Construction Hearing, the Court suggested that programmable device should be construed the same way as microcontroller, i.e., a programmable device is a single semiconductor substrate integrating electronic circuit components that includes a central processing unit and all program memory making it suitable for use as an embedded system. Defendants agreed with the Courts proposed construction; however, Plaintiff argued that a programmable device is a device that can execute a computer program. For the reasons stated below, the Court adopts its proposed construction. 8
Plaintiffs chief argument is that while the specification may describe microcontrollers rather than broader programmable devices, the patentee was permitted to claim the genus of programmable devices of which microcontroller is a species. PLAINTIFFS BRIEF at 16-17. Thus, for Plaintiff, [t]he invention disclosed relates to conversion of byte codes and the invention is applicable to other programmable devices, not just the preferred embodiment such as microcontrollers. PLAINTIFFS BRIEF at 17. To support this argument, Plaintiff relies on Federal Circuit case law interpreting 28 U.S.C. 112, the written description requirement.
7 The term programmable device is found in the 727 patent at claims 1-7, 10, 12, 14, and 16-18. 8 The parties also dispute whether the preamble of claim 3 of the 727 patent is limiting. For the same reasons discussed in the context of microcontroller, the Court finds the preamble of the 727 patent limiting. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 15 of 47 PageID #: 6136 JA000031 Case: 13-1397 Document: 34 Page: 89 Filed: 07/09/2013 16
While Plaintiff may be correct that disclosure of a species may be sufficient written description support for a later claimed genus including that species, that argument presupposes that a person having ordinary skill in the art would understand programmable device in light of the specification as broader than microcontroller. PLAINTIFFS BRIEF at 16-17; REPLY at 5. Because programmable device is not a term of art and has no plain and ordinary meaning, it is particularly important to construe the term in the context of the intrinsic record. See Network Commerce, Inc. v. Microsoft Corp., 422 F.3d 1353, 1360-61 (Fed. Cir. 2005). While in the abstract, a programmable device may simply be a device that can execute a computer program as argued by Plaintiff, the specification does not support such a broad disclosure. Although the specification does not use the term programmable device, the patents-in-suit contemplate a microcontroller that has the ability to be programmed using a high level language: In other embodiments, the above-described techniques are used with a microcontroller (such as the processor 12) [sic] may control devices (e.g., part of an automobile engine) other than an integrated circuit card. In these applications, the microcontroller provides a small platform (i.e., a central processing unit, a memory, both of which are located on a semiconductor substrate) for storing and executing high level programming languages. Most existing devices and new designs that utilize a microcontroller could use this invention to provide the ability to program the microcontroller using a high level language, and application of this invention to such devices is specifically included.
317 patent at 18:31-42 (emphasis added). Furthermore, as explained above in the context of microcontrollers and integrated circuit cards, the patentee repeatedly distinguished the invention from high level programming language operating on traditional microprocessors. Thus, programmed device must be narrower than simply a device that can execute a computer program. Because programmable device is not a term of art, the only embodiments disclosed in the patents-in-suit use microcontrollers, and the patentee repeatedly distinguished the Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 16 of 47 PageID #: 6137 JA000032 Case: 13-1397 Document: 34 Page: 90 Filed: 07/09/2013 17
invention from generic microprocessors, the Court finds that a programmable device is a microcontroller. Accordingly, the Court construes programmable device as a single semiconductor substrate integrating electronic circuit components that includes a central processing unit and all program memory making it suitable for use as an embedded system. d. resource constraints 9
Plaintiffs Proposed Constructions Defendants Proposed construction computing resources that are limited when compared to conventional computing platforms, such as microprocessor-based desktop and personal computers Alternatively, limits on computing resources imposed by the physical characteristics of the device Alternatively, insufficient computing resources to run the application in the compiled form more efficiently than in a converted form Alternatively, a fixed amount of memory and/or processing resources on the device Alternatively, computing resources that are limited as compared to typical desktop computers. Indefinite
Over the course of the claim construction process, Plaintiff has proposed no less than five different constructions for the term resource constraints. Defendants, on the other hand, have consistently argued that the phrase is indefinite. For the reasons set forth below, the Court rejects Plaintiffs proposals and construes the phrase a set of resource constraints as insufficient memory to run the compiled application source program in an unconverted form. i. Plaintiffs Proposals
9 The term resource constraints is found in the 317 patent at claims 65, 78, 91 & 92; the 485 patent at claims 7 & 21; and the 727 patent at claims 3 & 17. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 17 of 47 PageID #: 6138 JA000033 Case: 13-1397 Document: 34 Page: 91 Filed: 07/09/2013 18
In its initial claim construction briefing, Plaintiff argued that resource constraints should be construed as computing resources that are limited when compared to conventional computing platforms, such as microprocessor-based desktop computers. See PLAINTIFFS BRIEF at 17. In response to Plaintiffs initial construction, Defendants countered that [o]ne of ordinary skill would not know what limited computing resources means, which resources should be compared to those of conventional computing platforms, or how many resources would avoid the resource constraints limitations. RESPONSE at 16-17. Defendants also criticized Plaintiffs proposal on the grounds that the scope changes over time, i.e., it is based on how one of ordinary skill in the art would understand memory constraints by comparison to conventional computing platforms today. Id. In response, Plaintiff stated [u]pon review of Defendants briefing, Gemalto better understood why Defendants asserted confusion as to the original construction making assessments at different times and the use of labels (e.g., personal computer) can lead to complexities. PLAINTIFFS OPPOSITION TO MSJ OF INVALIDITY FOR INDEFINITENESS (Doc. No. 191) (RESPONSE TO MSJ) at 2. Accordingly, Plaintiff proposed an alternative construction for resource constraints: limits on computing resources imposed by the physical characteristics of the device. Id. at 3. Again, Defendants argued that Plaintiffs proposal was ambiguous. Specifically, Defendants argued that one of ordinary skill in the art would not know why physical characteristics such as size should be considered to evaluate limits on computing resources, or even which device matters for purposes of resource constraints. DEFENDANTS REPLY IN SUPPORT OF MSJ OF INVALIDITY FOR INDEFINITENESS (Doc. No. 201) (MSJ REPLY) at 2. Defendants also argued that the specification focuses on resource constrained integrated circuits, not generic devices as Plaintiff asserts. Id. at 2. Moreover, Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 18 of 47 PageID #: 6139 JA000034 Case: 13-1397 Document: 34 Page: 92 Filed: 07/09/2013 19
because the Plaintiff advanced an alternative claim construction based on previously undisclosed expert testimony, the Court permitted Defendants to depose Plaintiffs expert and submit a supplemental brief based on the experts deposition. See APRIL 30, 2012 ORDER (Doc. No. 199); DEFENDANTS SUPPLEMENTAL BRIEF IN SUPPORT OF MSJ (Doc. No. 234) (SUPP. MSJ BRIEF); PLAINTIFF GEMALTO S.A.S RESPONSE TO DEFENDANTS SUPP. BRIEF (Doc. No. 237) (RESPONSE TO SUPP. MSJ BRIEF). After the Claim Construction Hearing, and at the behest of the Court, Plaintiff filed a supplemental brief putting forth an additional alternative construction, arguing that resource constraints should be construed as a fixed amount of memory and/or processing resources on the device. See PLAINTIFFS SUPPLEMENTAL CLAIM CONSTRUCTION BRIEF (Doc. No. 248) (SUPP. CC BRIEF) at 2. Plaintiff included yet another proposal, partly returning to its original construction, arguing that resource constraints should be construed as computing resources that are limited as compared to typical desktop computers. Id. Despite its earlier proposals, Plaintiff requests the Court to adopt one of these two constructions. RESPONSE TO SUPP. MSJ BRIEF at 2. However, both proposals are flawed because they fail to adequately define the metes and bounds of the term. Plaintiffs first final alternative construction, a fixed amount of memory and/or processing resources on the device is more ambiguous than the term it seeks to define. Plaintiff argues that unlike microprocessor based platforms such as desktop computers, microcontroller based platforms are not expandable, meaning that additional memory or a faster processor may not be easily added. SUPP. CC BRIEF at 1. However, Plaintiffs proposal provides no explanation as to what it means for memory and/or processing resource to be fixed. The ambiguity is highlighted by a series of hypothetical question posed by Defendants: Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 19 of 47 PageID #: 6140 JA000035 Case: 13-1397 Document: 34 Page: 93 Filed: 07/09/2013 20
What does it mean for memory and/or processing resources to be fixed? Is it memory or speed when shipped? Does it mean memory or speed cannot be improved? If a user can increase memory on a smartphone with a microSD card, is the memory not fixed? Also, what is the device to look to? Is it the microcontroller itself or what device the microcontroller may be mounted in?
RESPONSE TO SUPP. CC BRIEF at 3 n.3. Moreover, this proposal improperly focuses on the physical characteristics of an unidentified device at the exclusion of the application/execution environment. As will be explained in more detail below in the context of the Courts construction, the patentee described the constraints of various platforms in relation to executing high level programming language such as Java. Plaintiffs second final alternative construction, computing resources limited as compared to typical desktop computers, is flawed by Plaintiffs own admission. See RESPONSE TO MSJ at 2 (noting that making assessments at different times and the use of labels (e.g., personal computer) can lead to complexities and confusion); see also MARKMAN TRANSCRIPT at 60:3-9 (In our initial construction, we said, limits on computing resources as compared to a desktop computer or a personal computer. And the and the defendants pointed out, and I think rightfully so, that while that is typically the case youre putting labels on something. What is a desktop computer, what is a personal computer as your comparison point). Like Plaintiffs initial proposed construction, which Plaintiff concedes utilizes ambiguous comparison points, Plaintiffs second final alternative construction relies on the label of typical desktop computers. Furthermore, as Defendants point out, the point of comparison is ambiguous because at any given time, desktop computers, cell phones, smart phones, laptops, and tablets of many different vintages are in use. DEFENDANTS RESPONSE TO SUPP. CC BRIEF (Doc. No. 223) (RESPONSE TO SUPP. CC BRIEF) at 2. Thus, if a competitor wished to determine whether a Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 20 of 47 PageID #: 6141 JA000036 Case: 13-1397 Document: 34 Page: 94 Filed: 07/09/2013 21
smartphone was resource constrained, it would have no guidance as to what year or model desktop computer it should compare to. See id. Further, Plaintiff provides no guidance as to how limited the resources must be in comparison or to which computing resources it should be applied. Accordingly, the Court rejects Plaintiffs second final alternative construction. ii. The Courts Construction Instead of adopting any of Plaintiffs proposed constructions, the Court construes a set of resource constraints as insufficient amount of memory to run the compiled application source program in an unconverted form. Looking first to the specification, the patents-in-suit describe the invention in terms of the execution environment for a Java application called a Java Virtual Machine (JVM) that interprets byte codes of a compiled Java application loaded onto a platform. See 317 patent at 1:15-35. The specification explains that [c]onventional platforms that support Java are typically microprocessor-based computers, with access to relatively large amounts of memory and hard disk storage space. Id. at 1: 55-57. These microprocessor-based implementations frequently are used in desktop in personal computers. Id. at 1:58-59. The patentee explained that, in contrast to traditional microprocessor based platforms that can access from a megabyte to a gigabyte of memory, microcontroller and integrated circuit platforms can only access one to sixty-four kilobytes. Id. at 1:66 2:10. The specification further explains, [i]n order for a Java application to run on a specific platform, a Java virtual machine implementation must be written that will run within the constraints of the platform, and a mechanism must be provided for loading the desired Java application on the platform, again keeping within the constraints of the platform. Id. at 1:49-54. Further, the specification describes the constraints of the platform exclusively in terms of reduced memory capacity. See 317 patent at 1:55 2:10 (describing various types of memory Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 21 of 47 PageID #: 6142 JA000037 Case: 13-1397 Document: 34 Page: 95 Filed: 07/09/2013 22
capacity in microcontroller and microprocessor based platforms). Specifically, the specification describes the memory capacity of microprocessor based platforms and microcontroller based platforms in the context of their capacity for the Java application and the JVM. Id; see also supra pp 7-10 (discussing memory capacity of microcontrollers). Thus, the Java application and the JVM for interpreting the compiled byte code form of the Java application must be written such that they can fit into the available memory of the platform. However, due to the constraints of microcontroller and integrated circuit platforms, Java could not fit on the available memory. In order to fit a high level programming language onto platforms like microcontrollers and integrated circuit cards, the patents-in-suit teach compiling a high level program language before converting the compiled programming language into a minimized, i.e., converted, form. Thus, the application must be converted in order to fit within the resource constraints of the platform. It therefore follows that a set of resource constraints means insufficient amount of memory to run the compiled application source program in an unconverted form. Additionally, the Courts construction is supported by the claim language itself. For example, claim 65 of the 317 patent recites: A microcontroller having a set of resource constraints and comprising: a memory, and an interpreter loaded in memory and operable within the set of resource constraints, the microcontroller having: at least one application loaded in the memory to be interpreted by the interpreter, wherein the at least one application is generated by a programmable environment comprising: a) a compiler for compiling application source programs written in high level language source code form into a compiled form, and b) a converter for post processing the compiled form into a minimized form suitable for interpretation within the set of resource constraints by the interpreter, wherein the converter comprises means for translating from the byte codes in the compiled form to byte codes in a format suitable for interpretation by the interpreter by: b.l) recording all jumps and their destinations in the original byte codes; Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 22 of 47 PageID #: 6143 JA000038 Case: 13-1397 Document: 34 Page: 96 Filed: 07/09/2013 23
b.2) performing a conversion operation selected from the group: b.2.1) converting specific byte codes into equivalent generic byte codes b.2.2) modifying byte code operands from references using identifying strings to references using unique identifiers; and b.2.3.) renumbering byte codes in the compiled form to equivalent byte codes in an instruction set supported by an interpreter on the integrated circuit card; and b.3) relinking jumps for which the destination address is affected by the conversion operation. 317 patent at Claim 65 (showing claim as modified by reexamination) (emphasis added). The claim lays out an application and an interpreter operating within a set of resource constraints on a microcontroller platform. Particularly, step b identifies a a converter for post processing the compiled form into a minimized form suitable for interpretation within the set of resource constraints by the interpreter. This language suggests that a compiled form that is not converted into a minimized (or converted) form, is not suitable for interpretation within the set of resource constraints by the interpreter. 10 In other words, the unconverted or unminimized form of the code requires more memory than is available on the microcontrollers and integrated circuits described in the patents-in-suit. Accordingly, the Court finds that a set of resource constraints means insufficient amount of memory to run the compiled application source program in a unconverted form. Defendants argue that to the extent there could be a definite construction of resource constraints, it would be in reference to a device that does not have the resources to run programs written in a high level language, such as Java, in 1997. SUPP. RESPONSE at 3. In support,
10 All of the asserted claims that include the term resource constraints also include converting steps. The claims identify the result of the converting step as either a minimized form or a second intermediate code. Compare 317 patent at claim 65; 485 patent at claim 7; and 727 patent at claim 3 with 317 patent at claim 78, 88, 91 & 92; 485 patent at claim 21; and 727 patent at claim 17. Nevertheless, the minimized form and the second intermediate code are both the result of the converting step, i.e. are converted forms. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 23 of 47 PageID #: 6144 JA000039 Case: 13-1397 Document: 34 Page: 97 Filed: 07/09/2013 24
Defendants rely on passages in the specification and the prosecution history purportedly limiting the invention to the Java embodiments. Id. (citing, e.g., REEXAM EXCERPTS at GEM4515-16 (using Java as an example, providing Java technology onto smart cards would be very challenging due to the size constraints of smart cards as contrasted to the minimum requirements of Java.)). While Defendants are correct that the patents-in-suit often describe the problem the inventors were attempting to solve in the context of Java or other high level programming languages, it does not follow that resource constraints must be defined in reference to Java or high level programming language. As Defendants themselves point out, the question is what resources are required to run a particular program in an unconverted form. See id. at 3 (quoting 317 patent at 1:55:-59). Moreover, as explained above in the context of high level programming language, the claims themselves dictate the execution environment of the claimed program applications. Thus, the Court declines to define resource constraints with reference to Java or a high level programming language. Moreover, Defendants argue that the Courts construction does not provide definite metes and bounds for the term because it could result in a device having a set of resource constraints in reference to one program while not having a set of resource constraints in reference to a second program SUPP. RESPONSE at 2. However, as noted above, the point of comparison is not between two unrelated programs, but between a converted application and the unconverted form of that same application. Further, the definiteness standard is one of reasonableness under the circumstances and a construction need only be as precise as the subject matter allows. See, e.g., Orthokinetics, Inc. v. Safety Travel Chairs, Inc., 806 F.2d 1565, 1576 (Fed. Cir. 1986); Shatterproof Glass Corp., 758 F.2d at 624. Moreover, defining resource constraints as insufficient memory to run the compiled application source program in an Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 24 of 47 PageID #: 6145 JA000040 Case: 13-1397 Document: 34 Page: 98 Filed: 07/09/2013 25
unconverted form provides a workable objective standard from which a person having ordinary skill in the art can determine the scope of the claim. Cf. Datamize, LLC v. Plumtree Software, LLC, 417 F.3d 1342, 1351 (Fed. Cir. 2005) (finding the term aesthetically pleasing indefinite because it failed to provide a workable objective standard). Lastly, Plaintiff suggests that the Courts construction is flawed because it focuses on a platforms mere capability to run a program at the exclusion of platforms that may be able to run the program, just not suitab[ly]. See SUPP. BRIEF at 2. However, Plaintiff fails to provide any support from the disclosures for a maximizing efficiency of programs on microcontrollers or integrate circuits. Instead, as explained above, the patentee focused on microcontrollers and integrated circuits inability to run Java based programming. II. Software Related Terms
a. high level language / high level programming language 11
Plaintiffs Proposed Construction Defendants Proposed Construction programing language that must be compiled and interpreted before it can be executed by a computer programming language that must be compiled or interpreted before it can be executed by a computer
The dispute between the parties focuses on the term in relation to the program languages execution environment. Defendants argue that the plain and ordinary meaning of high level programming language permits the programming language to be compiled or interpreted before it can be executed by a computer. RESPONSE at 22. Plaintiff appears to concede that, in the abstract, a high level programming language can be compiled or interpreted before execution; however, Plaintiff argues that in the context of the patents-in-suit, a high level programming language must be compiled and interpreted. See PLAINTIFFS BRIEF at 4; RESPONSE at 22.
11 The term high level language or high level programming language are found in the 317 patent at claims 1, 5, 31, 35, 64, 65, 84-86, 93, & 94; the 485 patent at claims 7, 38, 40, & 42; and the 727 patent at claim 3. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 25 of 47 PageID #: 6146 JA000041 Case: 13-1397 Document: 34 Page: 99 Filed: 07/09/2013 26
The parties dispute over the proper execution environment is resolved by the claim language itself. As Plaintiff points out, every claim of the patents-in-suit is directed towards a programming language that is first compiled into a compiled form and then converted into an interpreted form. See REPLY at 6. For example, claim 1 of the 317 patent requires An integrated circuit card comprising
a memory storing:
an application derived from a program written in a high level programming language format wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form...
an interpreter operable to interpret such an application derived from a program written in a high level programming language format; and a processor coupled to the memory, the processor configured to use the interpreter to interpret the application for execution and to use the communicator to communicate with the terminal. 317 patent at claim 1 (emphases added). Thus, the claim language itself requires that a high level programming language is both compiled and interpreted before execution. This is further supported by the specification, which describes high level languages that must be both compiled and interpreted. See 317 patent at 18:47-64 (Regardless of the source of the class files, the above description applies to languages other than Java to generate codes to be interpreted) (emphasis added). Thus, the Court finds no construction necessary because the claims fully identify the execution environment of the high level language program. b. class file format 12 and application having a class file format 13
Term Plaintiffs Proposed Construction Defendants Proposed Construction
12 The term class file format is found in the 317 patent at claims 58, 63, 67, & 87; the 485 patent at claims 1, 6, & 9; and the 727 patent at claims 1, 2, & 5. 13 The term application having a class file format is found in the 317 patent at claims 58, 63, &87; the 485 patent at claims 1, 6, & 9; and the 727 patent at claim 1. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 26 of 47 PageID #: 6147 JA000042 Case: 13-1397 Document: 34 Page: 100 Filed: 07/09/2013 27
class file format a file format containing byte codes that are instructions for a virtual machine a file format containing byte codes that are instructions for a hypothetical computer or a virtual machine application having a class file format a program whose compiled form is in a class file format No construction necessary. The parties agree that class file format relates to a file format containing byte codes; however, the parties dispute whether these files contain instructions for a virtual machine or a hypothetical computer. Defendants characterize the dispute as whether byte codes must be executed on a virtual machine (Plaintiff) or whether they can be executed on real computers as well (Defendants). RESPONSE at 26. Defendants argue that class file format should be construed to permit execution on a hypothetical computer because, as a technical matter, byte codes may be directly executed by real machines operating Java Optimized processors. The Court, however, finds it unnecessary to include either virtual machine or hypothetical computer in its construction of class file format because each of the claims clearly specifies the execution environment, i.e., that the compiled byte code instructions must be interpreted before execution by the processor. See, e.g., 317 patent at claim 1 (an interpreter operatable to interpret). Thus, the Court construes class file format as a file format containing byte codes. Plaintiff asks the Court to construe application having a class file format as a program whose compiled form is a class file format. Having construed class file format, the Court finds further construction unnecessary. Plaintiffs proposal rewrites the claims which plainly describe an application having class file format as an applications form before compiling, i.e. when it is written in a high level programming language. For example, claim 58 of the 317 patent recites a derivative application derived from an application having a class file format wherein the application is derived from an application having a class file format by first Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 27 of 47 PageID #: 6148 JA000043 Case: 13-1397 Document: 34 Page: 101 Filed: 07/09/2013 28
compiling the application having a class file format into a compiled form. Similarly, claim 2 of the 317 patent states that the high level programming language format comprises a class file format. While Plaintiff may be correct that the specification teaches that an application [having a class file format] is a program written in a high level programming language that when compiled is compiled into class files containing byte codes, that is not what the claims recite. PLAINTIFFS BRIEF at 9. Thus, the Court declines Plaintiffs invitation to rewrite the claims and therefore finds no construction necessary. c. compiling and compiled form 14
Term Plaintiffs Proposed Construction Defendants Proposed Construction compiling transforming a program written in a high level programming language into class files containing byte codes transforming a program written in a high level programming language from source code to object code or byte code compiled form class files containing byte codes No construction necessary The dispute between the parties is whether the term compiling should be limited to transforming program source code to byte code or should also permit transforming program source code to object code. Plaintiff does not dispute that the plain and ordinary meaning of compiling includes transforming program code into either object code or byte code; however, Plaintiff argues that compiling, as disclosed in the specification and claimed in the patents-in- suit, is limited to byte code. Defendants argue that limiting the result of compiling to class file embodiments by excluding object code from the construction of compiling is flawed. Defendants primarily argue that this (1) imports limitations from the specification into the claims and (2) is directly at odds with the claims because some independent claims that require compiling explicitly
14 The terms compiling or compiled form are found in the 317 patent at claims 1, 31, 64-68, 73, 84-88, & 91- 94; the 485 patent at claims 1, 7-10, 14, 16, 21, 24, & 38-43; and the 727 patent at claims 1, 3-6, 10, 12, 17, & 20. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 28 of 47 PageID #: 6149 JA000044 Case: 13-1397 Document: 34 Page: 102 Filed: 07/09/2013 29
require the inclusion of a class file format, but others do not. RESPONSE at 24. Plaintiff argues that compilers that compile an application programming language into object code are transforming the program into codes that are directly executable by a specific computing platform and thus are not interpretable by a virtual machine as required by the claims. PLAINTIFFS BRIEF at 5-6. Defendants further argue that the patentee confirmed that compiling is a term of art of Computer Science meaning To transform a program written in a high level programming language from source code to object code while prosecuting the 485 patent. RESPONSE at 24 (quoting Ex. E. to RESPONSE (Doc. No. 180-5)); see Home Diagnostics, Inc., 381 F.3d at 1356 (noting that a patentee may define a term during prosecution). The Court is presented with the unique situation where Defendants are attempting to hold the patentee to a broad definition of a claim term in prosecution, rather than attempting to show disclaimer. In this case, the applicants defined compiling broadly while distinguishing the claimed invention from a piece of prior art that did not disclose any form of compiling. Thus, the distinguishing feature of the claimed invention was not that it specifically compiled source code to object code, but that it compiled at all. To the extent that the prosecution history lends credence to Defendants arguments, it is outweighed by specific language in the claims and the specification describing a system for compiling program source code into only byte code, not object code. See Phillips, 415 F.3d at 1314 (To begin with, the context in which a term is used in the asserted in the claim can be highly instructive). The claim language itself describes the compiling operation as one that produces an intermediate representation derived from the source code that is thereafter interpreted for execution. See, e.g., 317 patent at claim 1 ( . . . a memory storing: an application derived Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 29 of 47 PageID #: 6150 JA000045 Case: 13-1397 Document: 34 Page: 103 Filed: 07/09/2013 30
from a program written in a high level programming language format wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form and then converted the compiled form into a converted form ). Thus, the claim language itself limits compiling to intermediate code. The claim language does not, however, describe the compiling operation as one that produces an object code that can be directly executed. This understanding is reinforced by the specification, which only discusses compiling in the context of byte codes. See, e.g., 317 patent at 1:24-34 (When a Java application is written, it is compiled into Class files containing byte codes that are instructions for a hypothetical computer called a Java Virtual Machine . . . . The Java virtual machine for the selected platform is run, and interprets the byte codes in the class file, thus effectively running the Java application) (emphasis added); id. at 18:47-64. Lastly, Defendants arguments that including class file format in the construction of compiling creates redundancies in the claims is well taken but can be remedied by simply not including the phrase class files. Thus, the Court finds that the term compiled, when read in the context of the claims, the specification, and the prosecution history means transforming program source code to byte code. Construing compiling as such captures the meaning of compiling as disclosed in the patents-in-suit without the risk of adding redundancy by including class files in the construction. Having construed compiling, the Court sees no further need to construe compiled form. d. converting and converted form 15
Term Plaintiffs Proposed Construction Defendants Proposed Construction converting post processing the byte codes of the compiled form into a converted form No construction necessary
15 The terms converting or converted form are found in the 317 patent at claims 1, 31, 58, 64, 78, 84-88, & 91-94; the 485 patent at claims 1, 21, 38, & 42; and the 727 patent at claims 1, 10, 17, & 20. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 30 of 47 PageID #: 6151 JA000046 Case: 13-1397 Document: 34 Page: 104 Filed: 07/09/2013 31
converted form Byte codes interpretable by a different virtual machine than the compiled form No construction necessary Plaintiff argues that both converting and converted form need to be construed to prevent Defendants from improperly expand[ing] the scope of these claims terms . . . or otherwise confus[ing] the jury in support of their validity challenge. PLAINTIFFS BRIEF at 9-10. Because the asserted claims make clear that program written in a high level programming language is first compiled into byte codes and then converted to converted form, Plaintiff argues that converting should be interpreted as post processing the byte codes from the compiled form into a converted form. Id. at 10. In contrast, Defendants argue that converting has no special meaning and is readily understandable by a jury in the context of the claims themselves. The Court agrees with Defendants. In light of the Courts construction of compiling as transforming program source code to byte code, Plaintiffs construction merely restates what the claim clearly sets forth. For example, inclusion of postprocessing is unnecessary because the claims specify that converting takes place after compiling. 317 patent at claim 1 ( wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form .); PLAINTIFFS BRIEF at 9-10. Thus, Plaintiff is correct that when read in the context of all the claims, it is clear that the converting must occur after the generation of byte codes (compilation) and is therefore a post-processing step of the byte codes form the compiled form into the converted form. REPLY at 9. However, because the meaning of converted is clear from the claim language, the Court finds that no construction is necessary. Plaintiff seeks to introduce three limitations to converted form: (1) byte codes, (2) virtual machines, and (3) the notion that the compiled form be interpretable by a different Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 31 of 47 PageID #: 6152 JA000047 Case: 13-1397 Document: 34 Page: 105 Filed: 07/09/2013 32
virtual machine. First, limiting converted form to byte codes or virtual machines runs afoul of the doctrine of claim differentiation. While some claims require that the converted form be in byte code format, other claims do not. Compare 485 patent at claim 10 with id. at claim 14 ((The microcontroller of claim 10 wherein the compiled form is in a byte code format . . .). Furthermore, some claims require that the converted form be interpreted by a virtual machine whereas others require the converted form to be interpreted by an interpreter. Compare 727 patent at claim 17 with id. at claim 3. Thus, the Court declines to introduce byte codes or virtual machine into the construction of converted form. Plaintiffs construction also introduces a limitation that contrasts byte codes of the compiled form and byte codes of the converted form by requiring them to be interpreted by different virtual machines. As an initial matter, the Court is not persuaded that this contrast provides any relevant or meaningful guidance, particularly in light of the Courts construction of compiling. Furthermore, as Defendants point out, only six[] of the twenty-four asserted independent claims suggest that the compiled form need be interpretable at all, let alone the compiled form be interpreted by a different virtual machine than the converted form. RESPONSE at 29. Thus, the Court declines to introduce the additional limitations suggested by Defendants. Accordingly, the Court finds that converted form requires no construction. e. byte codes 16 and virtual machines 17
Term Plaintiffs Proposed Construction Defendants Proposed Construction byte codes/byte code format program instructions interpretable by a virtual machine No construction necessary virtual machine/ programs used to interpret byte No construction necessary
16 The terms byte codes or bye code format are found in the 317 patent at claims 1, 31, 58, 64, 65, 78, 84-88, & 91-94; the 485 patent at claims 14, 24, & 38-43; and the 727 patent at claims 10, & 20. 17 The terms virtual machine or intermediate code virtual machine are found in the 317 patent at claims 1, 31, 58, 64, 65, 78, 84-88, & 91-94; the 485 patent at claim 21; and the 727 patent at claim 17. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 32 of 47 PageID #: 6153 JA000048 Case: 13-1397 Document: 34 Page: 106 Filed: 07/09/2013 33
intermediate virtual machine codes Plaintiff argues that byte codes must be construed to assist the trier of fact and avoid confusion. Plaintiff draws support for its construction from specific embodiments disclosed in the specification that describe byte codes as instructions for a hypothetical computer called a Java Virtual Machine. PLAINTIFFS BRIEF at 7-8 (quoting 317 patent at 1:26-27). Plaintiff further argues that because the invention is not limited to a Java virtual machine, byte codes should only be limited to program instruction interpreted by a virtual machine. Id. at 8. Defendants argue that that Plaintiffs construction draws an improper distinction between codes executed on a virtual machine and codes executed on a real machine. For Defendants, the term byte codes is readily understandable to a lay jury, i.e. byte codes are codes in byte format that correspond to an instruction for a computer, either real or virtual. RESPONSE at 25. While the Court agrees with Defendants that Plaintiffs construction is overly limiting, the Court is of the opinion that a jury would benefit from a construction of byte codes. Plaintiffs attempt to insert the type of platform configuration the byte codes are interpreted for execution in is an extraneous limitation beyond the mere meaning of the terms themselves. Thus, whether the byte code instructions are executed by a real or virtual machine is not a property of the codes themselves. Accordingly, the Court construes byte codes as program instructions that are interpreted before execution. Similarly, the Court construes virtual machine as program used to interpret byte code. 18 See 317 patent at 1:33-35 (The Java virtual machine . . . interprets the byte codes in the class file, thus effectively running the Java Applications). f. specific byte code and generic byte code 19
18 Defendants do not meaningfully contest Plaintiffs proposed construction for virtual machine. 19 The term generic byte codes or specific byte codes is found in the 317 patent at claims 1, 31, 58, 64, 65, 78, 84-87, 91, & 94; the 484 patent at claims 14, 24, 39, 41, 43; and the 727 patent at claims 10 & 20. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 33 of 47 PageID #: 6154 JA000049 Case: 13-1397 Document: 34 Page: 107 Filed: 07/09/2013 34
Term Plaintiffs Proposed Construction Defendants Proposed Construction specific byte code a byte code with built-in argument or operand smaller byte codes generic byte code a byte code with a separate, accompanying argument or operand larger byte codes for the same operation
The parties dispute appears to be limited to whether Plaintiffs use of argument or operand is likely to confuse a lay jury. See RESPONSE at 29. Defendants argue that their constructions captures the essence of this element without introducing a potentially confusing concept. Id; REPLY at 10. However, Defendants do not argue that Plaintiffs proposed constructions are incorrect. The Court finds that Plaintiffs proposed constructions present a more accurate reading of the terms to one of ordinary skill in the art and would be understandable to a lay jury. Accordingly the Court construes specific byte code as a byte code with a built-in argument or operand and generic byte code as a byte code with a separate, accompanying argument or operand. See 317 patent at 10:40-44 (noting that specific byte code such as ILOAD_0 is replaced with an argument 0). g. terminal 20
Plaintiffs Proposed Construction Defendants Proposed Construction a device that communicates with the integrated circuit card or microcontroller System, external to the microcontroller or ICC system, that communicates with the microcontroller or ICC system
The essential dispute between the parties is whether the terminal must be a system separate from the microcontroller or integrated circuit card. See PLAINTIFFS BRIEF at 30; RESPONSE at 20-22. For the reasons set forth below, the Court finds that a terminal must be separate from the microcontroller or the circuit card and therefore construes terminal as a
20 The term terminal is found in the 317 patent at claims 1, 10, 25, 30, 31, 40, 55, 59, 62, 64, 84-86, 93, & 94; and the 485 patent at claims 2, 38, 40, & 42. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 34 of 47 PageID #: 6155 JA000050 Case: 13-1397 Document: 34 Page: 108 Filed: 07/09/2013 35
system, external to the integrated circuit card or microcontroller, that communicates with the ICC or microcontroller. This construction is supported by the specification which consistently recites a terminal that communicates with the integrated circuit card, which suggests that the terminal is separate from the integrated circuit card. 317 patent at 4:59-64. Furthermore, the specification lists examples of terminals that are all external to the system that contains the integrated circuit card or microcontroller: Terminals can be automated teller machines (ATMS), point-of-sale terminals, door security systems, toll payment systems, access control systems, or any other system that communicates with an integrated circuit card or microcontroller. Id. at 8:15-19. Plaintiff relies on this same portion of the 317 specification for the argument that terminals can be . . . any other system that communicates with an integrated circuit card or microcontroller. PLAINTIFFS BRIEF at 30; RESPONSE at 21. However, as Defendants highlight, this language supports the notion that a terminal is a separate system by emphasizing that terminals can be any other systems, i.e. not the same system. Accordingly, the Court construes terminal as a system, external to the integrated circuit card or microcontroller, that communicates with the integrated circuit card or microcontroller. III. Means Plus Function Claims
a. attributes 21
Plaintiffs Proposed Construction Defendants Proposed Construction This term does not need construction. To the extent that the term is construed, it should be given its plain and ordinary meaning, such as: information in a class file Data structures having the following general format: attibute_info { u2 attribute_name_index; u4 attribute _length; u1 info[attribute_length];
21 The term terminal is found in the 317 patent at claims 1, 10, 25, 30, 31, 40, 55, 59, 62, 64, 84-86, 93, & 94; and the 485 patent at claims 2, 38, 40, & 42. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 35 of 47 PageID #: 6156 JA000051 Case: 13-1397 Document: 34 Page: 109 Filed: 07/09/2013 36
}
The essential dispute between the parties is whether the term attributes should be construed as part of a means-plus-function element. See RESPONSE at 30. Claim 66 reads: The microcontroller of claim 65, wherein the compiled form includes attributes, and the converter comprises a means for including attributes required by the interpreter while not including the attributes not required by the interpreter. 317 patent at claim 66. Because the term attributes is introduced before the means-plus-function limitation in claim 66, it is not part of the means- plus-function limitations. Accordingly, the Court declines to adopt Defendants construction limiting attributes to the specific structure disclosed in the specification. One of ordinary skill in the art would understand that in the Java programming language, one of the basic sections in a class file is attributes, which give general information about the particular class defined by the file. Accordingly, the Court construes attributes as information in a class file. b. means for translating 22
The parties agree that means for translating is a means-plus-function element governed by 35 U.S.C. 112 6 but disagree over what constitutes the function. Plaintiff argues that the function is means for translating from the byte codes in the compiled form to byte code in a format suitable for interpretation by the interpreter, and the remainder of the claim, steps b.1 through b.3 recite the structure. Defendants, on the other hand, argue that the recited function encompasses steps b.1. through b.3. As will be explained in more detail below, the Court finds that the means for translating terms are not means-plus-function terms governed by 112 6 because the claims recite the complete structure for means for translating.
22 The entirety of the disputed means for translating terms and the parties proposed constructions are set forth in Appendix A to this Order. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 36 of 47 PageID #: 6157 JA000052 Case: 13-1397 Document: 34 Page: 110 Filed: 07/09/2013 37
As an initial matter, although the parties agree to a particular claim construction, the Court is not obligated to accept a construction that is contrary to law. See Rodime PLC v. Seagate Tech., Inc., 174 F.3d 1294, 1302 (Fed. Cir. 1999) (noting that a partys concession that a term is governed by 112 6 does not relieve the court of its responsibility to interpret the claims as a matter of law). Moreover, it is bedrock law that [m]eans-plus-function claiming applies only to purely functional limitations that do not provide the structure that performs the recited function. Phillips, 415 F.3d at 1311 (citing Watts v. XL Sys. Inc., 232 F.3d 877, 880-81 (Fed.Cir.2000)). Although there is a rebuttable presumption that 112 6 applies [i]f the word means appears in a claim element in association with a function, that presumption does not apply where the claim language itself provides the structure that performs the recited function. Micro Chem., Inc. v. Great Plains Chem., Co., 194 F.3d 1250, 1257 (Fed. Cir. 1999) (citations omitted); see also Callicrate v. Wadsworth Mfg., Inc., 427 F.3d 1361, 1368 (Fed. Cir. 2005) (same). Thus, where a claim recites a function, but then goes on to elaborate sufficient structure, material, or acts within the claim itself to perform entirely the recited function, the claim is not in means-plus-function format. Sage Products, Inc. v. Devon Indus., Inc., 126 F.3d 1420, 1427-28 (Fed. Cir. 1997) (citing Cole v. Kimberly-Clark Corp., 102 F.3d 524 (Fed. Cir. 1996)). With respect to computer-implemented inventions, i.e. software based inventions, the Federal Circuit has been particularly cautious to avoid purely functional claiming. See Aristocrat Techs. Australia Pty Ltd. v. Intl Gaming Tech., 521 F.3d 1328, 1333 (Fed. Cir. 2008) (Because general purpose computers can be programmed to perform very difference tasks in very different ways, simply disclosing a computer as the structure designed to perform a particular function does not . . . [comply with] section 112 paragraph 6); Altiris, Inc. v. Symantec Corp. 318 F.3d Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 37 of 47 PageID #: 6158 JA000053 Case: 13-1397 Document: 34 Page: 111 Filed: 07/09/2013 38
1363, 1376 (Fed. Cir. 2003) (noting that the term commands is equivalent to software which does not connote adequate structure). As a result, the patentee is required to disclose adequate structure in the form of an algorithm. See Aristocrat Techs. Australia Pty Ltd., 521 F.3d at 1333 (finding an algorithm adequate structure for a computer implemented means-plus-function limitation). The corresponding structure to a computer implemented means for term may be disclosed in the form of a step-by-step procedure for implementing the recited function as an algorithm, in prose, or in flow-chart form. See Ergo Licensing, LLC v. CareFusion 303, Inc., 673 F.3d 1361, 1365 (Fed. Cir. 2012) (citing Typhoon Touch Tech., Inc. v. Dell, Inc., 659 F.3d 1376, 1385 (Fed. Cir. 2011)). In this case, the disputed term, means for translating is presumed to be governed by 112 6 because it uses the phrase means for. As shown below, means for is immediately followed by a clearly defined function, translating from the byte codes in the compiled form to byte codes in a format suitable for interpretation by the interpreter. The claim language signals the end of the recited function and beginning of the structure of the term by the word by: 23
A microcontroller having a set of resource constraints operable within the set of resource constraints and comprising: A memory, and An interpreter loaded in memory and operable within the set of resource constraints, the microcontroller having: at least one application loaded in the memory . . . wherein the at least one application is generated by a programmable environment comprising: (a) A compiler . . . (b) A converter . . . wherein the converter comprises means for translating from the byte codes in the compiled form to byte codes in a format suitable for interpretation by the interpreter by: b.1) recording all jumps and their destinations in the original byte codes;
23 The Court notes that the recited steps are not identical in all three iterations of the means for translating claims. However, all three iterations of the means for translating claims include the word by signifying the end of the recited function and the beginning of the recited structure. See 727 patent at claim 10; 485 at claim 14. Moreover, both the other means for translating claims patent recite complete algorithms as a series of steps. They differ only in their numbering.
b.2) performing a conversion operation selected from the group: b.2.1) converting specific byte codes into equivalent generic byte codes; b.2.2) modifying byte code operands from references using identifying strings to references using unique identifiers; and b.2.3.) renumbering byte codes in the compiled form to equivalent byte codes in an instruction set supported by an interpreter on the integrated circuit card; and b.3) relinking jumps for which the destination address is affected by the conversion operation. 317 patent at claim 65. Thus, the claims recite a structurally complete means for translating because they recite a programmable environment 24 and include all the necessary algorithmic steps to perform the means for translating function. One of ordinary skill in the art would understand programmable environment as including a processor for executing commands or instructions. Specifically, while not explicitly reciting a processor for performing the recited steps of the means for translating limitation, the claims clearly contemplate a programmable environment that includes a processor for executing the compiler and the converter where the converter includes the means for translating. See, e.g., 317 C1 patent at 3:45 (claim 65) (a converter for post processing). The patentees recitation of a step-by-step procedure for performing the means for translating function, i.e., steps b.1 through b.3, provides even greater detail and clarity than the algorithm found sufficient in Typhoon Touch Technologies. In Typhoon Touch Technologies v. Dell, Inc., the Federal Circuit found that the specification adequately disclosed the structure for the term means for cross-referencing. 659 F.3d at 1386. Specifically, the Court found that the patents recitation of [c]ross-referencing entails the matching of entered responses with a library of possible responses, and, if a match is encountered, displaying the fact of the match,
24 The 485 patent and the 727 patent recite a programming environment, which also necessarily includes a processor. See 485 patent at claim 7; 727 patent at claim 3. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 39 of 47 PageID #: 6160 JA000055 Case: 13-1397 Document: 34 Page: 113 Filed: 07/09/2013 40
otherwise alerting the user, or displaying information stored in memory fields associated with the library entry was sufficient structure under 112 6. In this case, the claim clearly lays out steps b.1 through b.3 for performing the recited function that are executed by implied processor in the programmable environment and therefore recite adequate structure. See Aristocrat Tech. Australia Pty Ltd., 521 F.3d at 1338 (quoting WMS Gaming, Inc. v. Intl Gaming Tech., 184 F.3d 1339, 1349 (Fed. Cir. 1999) (patentee was required to disclose the algorithm that transforms the general purpose microprocessor to a special purpose computer programmed to perform the disclosed algorithm.); cf. Altiris, Inc., 318 F.3d at 1376 (rejecting plaintiffs argument that commands provided sufficient structure because commands (i.e., software) is so broad as to give little indication of the particular structure used here and is described only functionally, one must still look to the specification for an adequate understanding of the structure of that software.). Indeed, Plaintiff requests the Court to hold that the corresponding structure is a computer programmed to perform the algorithm/steps explicitly set forth in the claims. Id. at 24. However, as noted above, if the corresponding structure is set forth in the claims as advocated by Plaintiffs, the claim term cannot fall under 112 6 and is therefore not a means- plus-function claim. See Cole v. Kimberly-Clark Corp., 102 F.3d 524, 531 (Fed. Cir. 1996) (To invoke this statute [112 6], the alleged means-plus-function claim element must not recite a definite structure which performs the described function.). Thus, for the reasons stated above, the Court finds that means for translating is not a means-plus-function term governed by 112 6. Beyond that finding, however, the Court declines to construe means for translating. CONCLUSION Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 40 of 47 PageID #: 6161 JA000056 Case: 13-1397 Document: 34 Page: 114 Filed: 07/09/2013 41
For foregoing reasons, the Court adopts the constructions set forth above. . ___________________________________ JOHN D. LOVE UNITED STATES MAGISTRATE JUDGE So ORDERED and SIGNED this 28th day of June, 2012. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 41 of 47 PageID #: 6162 JA000057 Case: 13-1397 Document: 34 Page: 115 Filed: 07/09/2013 42
Appendix A Disputed Term Plaintiffs Proposed Construction Defendants Proposed Construction Courts Construction means for translating from the byte codes in the compiled form to byte codes in a format suitable for interpretation by the interpreter by: b.1) recording all jumps and their destinations in the original byte codes; b.2) performing a conversion operation selected from the group: b.2.1) converting specific byte codes into equivalent generic byte codes; b.2.2) modifying byte code operands from references using identifying strings to references using unique identifiers; and b.2.3.) renumbering byte codes in the compiled form to equivalent byte codes in an instruction set supported by an interpreter on the integrated circuit card; This limitation is governed by 112, 6. RECITED FUNCTION: translating from the byte codes in the compiled form to byte codes in a format suitable for interpretation by the interpreter CORRESPONDING STRUCTURE: computer programmed to perform the algorithm of: b.1) recording all jumps and their destinations in the original byte codes; b.2) performing a conversion operation selected from the group: b.2.1) converting specific byte codes into equivalent generic byte codes; b.2.2) modifying byte code operands from references using identifying strings to references using unique identifiers; and b.2.3.) renumbering byte codes in the compiled form to equivalent byte codes in an instruction set supported by an interpreter on the integrated circuit card; and Indefinite This limitation is not governed by 112 6.
Disputed Term Plaintiffs Proposed Construction Defendants Proposed Construction Courts Construction and b.3) relinking jumps for which the destination address is affected by the conversion operation.
317 Patent, Claim 65 b.3) relinking jumps for which the destination address is affected by the conversion operation. Alternatively, should the Court conclude that the algorithm steps are part of the recited function, rather than the corresponding structure as Gemalto proposes, Gemalto identifies the following portions of the specification as part of the corresponding structure for those steps: recording step: column 10:16-17, 22-26; converting specific step: column 10:35-44; modifying step: column 10:52- 54, 57-61; renumbering step: column 11:4- 10, 18-23; relinking step: column 11:36-41. means for translating from the byte codes in the compiled form to byte codes in a format suitable for interpretation by the interpreter by: using at least one step in a process including the This limitation is governed by 112, 6. RECITED FUNCTION: translating from the byte codes in the compiled form to byte codes in a format suitable for interpretation by the interpreter CORRESPONDING Indefinite This limitation is not governed by 112 6. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 43 of 47 PageID #: 6164 JA000059 Case: 13-1397 Document: 34 Page: 117 Filed: 07/09/2013 44
Disputed Term Plaintiffs Proposed Construction Defendants Proposed Construction Courts Construction steps: a) recording all jumps and their destinations in the original byte codes; b) converting specific byte codes into equivalent generic byte codes or viceversa; c) modifying byte code operands from references using identifying strings to references using unique identifiers; and d) renumbering byte codes in the compiled form to equivalent byte codes in the format suitable for interpretation; and relinking jumps for which destination address is effected by conversion step a), b), c), or d)
485 Patent, Claim 14 25
STRUCTURE: computer programmed to perform the algorithm of: using at least one step in a process including the steps: a) recording all jumps and their destinations in the original byte codes; b) converting specific byte codes into equivalent generic byte codes or viceversa; c) modifying byte code operands from references using identifying strings to references using unique identifiers; and d) renumbering byte codes in the compiled form to equivalent byte codes in the format suitable for interpretation; and relinking jumps for which destination address is effected by conversion step a), b), c), or d) Alternatively, should the Court conclude that the algorithm steps are part of the recited function, rather than the corresponding structure as Gemalto proposes, Gemalto identifies the following portions of the specification as part
25 Claim 14 depends on Claim 10 which depends on Claim 7 which recites an application generated by a programming environment. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 44 of 47 PageID #: 6165 JA000060 Case: 13-1397 Document: 34 Page: 118 Filed: 07/09/2013 45
Disputed Term Plaintiffs Proposed Construction Defendants Proposed Construction Courts Construction of the corresponding structure for those steps: recording step: column 10:16-17, 22-26; converting specific step: column 10:35-44; modifying step: column 10:52- 54, 57-61; renumbering step: column 11:4- 10, 18-23; relinking step: column 11:36-41. means for translating from the byte codes in the compiled form to byte codes in a format suitable for interpretation by the interpreter by: recording all jumps and their destinations in the original byte codes: converting the compiled form using at least one step in a process including the steps: a) converting specific byte codes into equivalent generic byte codes or viceversa; b) modifying byte code operands from references This limitation is governed by 112, 6. RECITED FUNCTION: translating from the byte codes in the compiled form to byte codes in a format suitable for interpretation by the interpreter CORRESPONDING STRUCTURE: computer programmed to perform the algorithm of recording all jumps and their destinations in the original byte codes: converting the compiled form using at least one step in a process including the steps: a) converting specific byte codes into equivalent generic byte codes or vice versa; Indefinite This limitation is not governed by 112 6.
Disputed Term Plaintiffs Proposed Construction Defendants Proposed Construction Courts Construction using identifying strings to references using unique identifiers; and c) renumbering byte codes in the compiled form to equivalent byte codes in the format suitable for interpretation; and relinking jumps for which destination address is effected by conversion step a), b), or c)
727 Patent, Claim 10 26
b) modifying byte code operands from references using identifying strings to references using unique identifiers; and c) renumbering byte codes in the compiled form to equivalent byte codes in the format suitable for interpretation; and relinking jumps for which destination address is effected by conversion step a), b), or c) Alternatively, should the Court conclude that the algorithm steps are part of the recited function, rather than the corresponding structure as Gemalto proposes, Gemalto identifies the following portions of the specification as part of the corresponding structure for those steps: recording step: column 10:16-17, 22-26; converting specific step: column 10:35-44; modifying step: column 10:52- 54, 57-61;
26 Claim 10 depends on Claim 6 which depends on Claim 3 which recites an application generated by a programming environment. Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 46 of 47 PageID #: 6167 JA000062 Case: 13-1397 Document: 34 Page: 120 Filed: 07/09/2013 47
Disputed Term Plaintiffs Proposed Construction Defendants Proposed Construction Courts Construction renumbering step: column 11:4- 10, 18-23; relinking step: column 11:36-41.
Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 47 of 47 PageID #: 6168 JA000063 Case: 13-1397 Document: 34 Page: 121 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 1 of 45 JA000064 (12) United States Patent Wilkinson et ai. (54) USING A HIGH LEVEL PROGRAMMING LANGUAGE WITH A MICROCONTROLLER (75) Inventors: Timothy J. Wilkinson, London (GB); Scott B. Guthery, Belmont, MA (US); Ksheerabdhi Krishna; Michael A. Montgomery, both of Cedar Park, TX (US) (73) Assignee: Schlumberger Technologies, Inc., Austin, TX (US) ( *) Notice: Subject to any disclaimer, the term of this patent is extended or adjusted under 35 U.S.c. 154(b) by 0 days. (21) Appl. No.: 08/957,512 (22) Filed: Oct. 24, 1997 Related U.S. Application Data (60) Provisional application No. 60/029,057, filed on Oct. 25, 1996. (51) Int. CI? ...................................................... G06F 13/00 (52) U.S. CI. ................................................................... 717/5 (58) Field of Search .................................. 395/705; 717/5 (56) References Cited U.S. PATENT DOCUMENTS 3/1981 3/1987 10/1988 1/1989 10/1989 11/1991 3/1993 4/1995 3/1996 7/1996 8/1996 8/1996 4,256,955 4,650,975 * 4,777,355 4,797,543 4,877,947 5,064,999 5,195,130 5,406,380 5,500,517 * 5,537,474 * 5,544,086 5,550,919 5,590,197 5,604,802 5,613,012 5,650,761 * 12/1996 2/1997 3/1997 7/1997 Giraud et al. ........................ 235/380 Kitchener ............................. 235/375 Takahira. Watanabe ............................. 235/492 Mori ..................................... 235/381 Okamoto et al. .................... 235/379 Weiss et al. ........................... 379/98 Teter .. ... ... ... .... ... ... ... ... ... ...... 358/332 Cagliostro ............................ 235/486 Brown et al. .. ... ... ... ... .... ... ..... 380/23 Davis et al. ......................... 364/408 Kowalski . ... .... ... ... ... ... ... .... .... 380/23 Chen et al. . ... ... ... ... .... ... ... ..... 380/24 Holloway . ... .... ... ... ... ... ... .... .... 380/24 Hoffman et al. ..................... 382/115 Gomm et al. ........................ 235/381 111111111111111111111111111111111111111111111111111111111111111111111111111 US006308317Bl (10) Patent No.: US 6,308,317 Bl Oct. 23, 2001 (45) Date of Patent: 5,689,565 11/1997 Spies et al. . ... ... .... ... ... ... ... ..... 380/25 5,692,132 11/1997 Hogan .................................. 395/227 5,734,150 3/1998 Brown et al. ........................ 235/381 5,742,756 * 4/1998 Dillaway et al. .................... 713/200 5,761,306 6/1998 Lewis ..................................... 380/21 5,768,419 6/1998 Gundlach et al. .............. 395/187.01 5,811,771 9/1998 Dethloff ............................... 235/380 5,815,657 * 11/1998 Williams et al. .................... 713/200 5,841,866 * 11/1998 Bruwer et al. ......................... 380/23 5,844,218 * 12/1998 Kawan et al. ....................... 235/380 5,889,941 * 3/1999 Tushie et al. ........................ 713/200 5,915,226 * 6/1999 Martineau ............................ 455/558 5,923,884 * 7/1999 Peyret et al. ......................... 395/712 FOREIGN PATENT DOCUMENTS 0829828 A1 0889393 A2 0427465 A2 2191029 A 2261973 A WO 98/19237 3/1998 (EP). 1/1999 (EP). 5/1999 (EP). 12/1987 (GB). 6/1993 (GB). 5/1998 (WO). OTHER PUBLICATIONS Rodley, Writing Java Applets, Corolis Group Books, Chap- ter 1. Apr. 15, 1996. * Kung et aI., Developing an Object-Oriented Software Test- ing and Maintaincane Enviroment, Oct. 1995, pp. 75-87.* Cheng et aI., Securing the Internet Protocol, Sep. 1995, p. 257.* (List continued on next page.) Primary Examiner-Mark R. Powell Assistant Examiner-John Q. Chavis (74) Attorney, Agent, or Firm-Pehr B. Jansson; Danita J. M. Maseles (57) ABSTRACT An integrated circuit card is used with a terminal. The integrated circuit card includes a memory that stores an interpreter and an application that has a high level program- ming language format. A processor of the card is configured to use the interpreter to interpret the application for execu- tion and to use a communicator of the card to communicate with the terminal. 87 Claims, 23 Drawing Sheets ,-__ --=-< Modify byte codes? PASS 4. Modify Java byte codes to Card JVM byte codes PASS 5 Readjust Jumps ,68 Case: 13-1397 Document: 34 Page: 122 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 2 of 45 JA000065 US 6,308,317 Bl Page 2 OlliER PUBLICATIONS Sandhu et aI., Authentication,Access Control, and Audit, Mar. 1996, pp. 241-243.* Gosling, Audio/Video Sequence of Invited Presentations, May, 1996, pp. 1-4.* Blundon, The Center of the universe is a database, Jul. 1996, pp.1-5.* Wingfield et aI., News: Java Brews Trouble for Microsoft, Nov. 1995, pp. 1-2.* o 427 465 A3-Examiner's search report for 0 427 465 A2 May 15, 1991. o 356 237 A3-Examiner's search report for 0 356 237 A2 Feb.28, 1990. PCT International Search Report dated Mar. 15, 1999. PCT International Search Report, Dec. 29,1998, 7 pages. PCT/US97/1899-Search Report. * cited by examiner Case: 13-1397 Document: 34 Page: 123 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 3 of 45 JA000066 u.s. Patent 16\ Oct. 23, 2001 Sheet 1 of 23 Integrated Circuit Card Card Java Virtual Machine 12a\ 12b\ (Card JVM) Communicator Terminal Communicator Terminal FIGURE 1 US 6,308,317 Bl Case: 13-1397 Document: 34 Page: 124 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 4 of 45 JA000067 u.s. Patent Card Class File (contains Classes A, B, and C) Oct. 23, 2001 Sheet 2 of 23 Card Loader FIGURE 2 28 US 6,308,317 Bl 22 Java Application Development Environment Card Class File Converter Integrated Circuit Card 26 10 Case: 13-1397 Document: 34 Page: 125 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 5 of 45 JA000068 u.s. Patent Oct. 23, 2001 Card Class File (contains Classes A, B, and C) 26 Sheet 3 of 23 Card Class File Converter FIGURE 3 US 6,308,317 Bl String To 10 Input Map String To 10 Output Map 30 Case: 13-1397 Document: 34 Page: 126 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 6 of 45 JA000069 u.s. Patent Oct. 23, 2001 Acclication Class Files ~ I Class File Information 41 Class File Information 42 t"\ Class Constant Pool - Contains all the strings corresponding to Fields methods and Class names referred to in the Java program 43 r.. Class, field, Interface and Method Information 44 i\ Attribute Information r+-Source File Attribute f+-Constant Value Attribute Code Attribute I+-Exceptions Attribute I+-Line Number Table Attribute I+-Local Variable Table Attribute I+-Optional Vendor Attributes \.. 24a Sheet 4 of 23 US 6,308,317 Bl / 24 Card Class File r 2 7 46 f-- ~ Card Class File Informationl Optimized Card Class ir- 47 Constant Pool where 1--1- each string is replaced by an ID Card Class, Card Field, ir- f--'t Card Interface and Card 48 Method Information Card Attribute Information Ir 49 .- f-+ Code Attribute (optionally translated) I- I; 24b,c r 45 .1 Eliminated I FIGURE 4 Case: 13-1397 Document: 34 Page: 127 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 7 of 45 JA000070 u.s. Patent Oct. 23, 2001 Sheet 5 of 23 US 6,308,317 Bl 51a Select A Classfile 51b Compact Constant Pool 51c Check For Unsupported Features 51d Discard Unnecessary Parts YES Modify The byte codes 56 Gather All Constant Pool Entries and Modified byte codes Generate Card Class File and String to 10 map (if required) 57 27 Flag Errors and Stop Conversion FIGURE 5 Case: 13-1397 Document: 34 Page: 128 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 8 of 45 JA000071 u.s. Patent Oct. 23, 2001 Sheet 6 of 23 US 6,308,317 Bl PASS 1: List all jumps and their destinations 62 NO PASS 2: Convert specific byte codes into generic byte codes PASS 3: Relink References 65 NO YES PASS 4: Modify Java byte codes to Card JVM byte codes PASS 5: Readjust Jumps FIGURE 6 Case: 13-1397 Document: 34 Page: 129 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 9 of 45 JA000072 u.s. Patent 0: 1 : 2: 3: 4: / I LOAD_O I LOAD_1 IFNE 1: BIPUSH 5 Oct. 23, 2001 70 --- --- Sheet 7 of 23 0: --------_ 1: --- --- 2: ... - ... - 3 --..... 4: 5: 6: FIGURE 7 US 6,308,317 Bl /72 I LOAD 0 ILOAD 1 IFNE 2: BIPUSH 5 Case: 13-1397 Document: 34 Page: 130 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 10 of 45 JA000073 u.s. Patent C\I co , <::> co "'- J: (J) => a.. OJ ~ .. 0 Cl ...J Oct. 23, 2001 co ~ ~ >< Q) "'C C "'-" lC) M Sheet 8 of 23 US 6,308,317 Bl o 0 o 0 o 0 co w 0:: ~ 0 C) - 0 c.. u. ..... CO ~ c m ..... en C\I c ~ 0 ~ Q) C) (J Q) Q) ..... '+= C en - en m (J o 0 o 0 o 0 Case: 13-1397 Document: 34 Page: 131 Filed: 07/09/2013 C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 1
F i l e d
1 0 / 2 2 / 1 0
P a g e
1 1
o f
4 5 J A 0 0 0 0 7 4 94 INVOKESTATIC INVOKESTATIC 89 (index) 13 (index) -- o 0 0 89 90 91 92 o 0 0 o 0 0 13 14 15 16 0 0 0 o 0 0 rethoj main I (V)V I I 0 0 0 Flag (ref) (ref) ) 42 o 0 0 r ~ ~ g 1 F0011 FFF31 I 0 0 0 477 Class file Constant Pool Card Class file Constant Pool FIGURE 9 d . rJl . ~ ~ ..... ~ = ..... o /") :-'" N ~ ~ N C C '""'" 'JJ. =-
~ ..... \C o ...., N ~ e rJ'l 0'1 ~ Q 00 ~ I--" ""-l ~ I--" Case: 13-1397 Document: 34 Page: 132 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 12 of 45 JA000075 u.s. Patent Oct. 23, 2001 Sheet 10 of 23 0: 1 : 2: 3: 4: 5: 6: / 100 ALOAD43 0 ILOAD 21 1 IFNE 1542: BIPUSH 16 5 FIGURE 10 0: 1 : 2: 3: 4: 5: 6: US 6,308,317 Bl ;1 02 ALOAD 51 0 ILOAD 50 1 IFNE 27 2: BIPUSH 49 5 Case: 13-1397 Document: 34 Page: 133 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 13 of 45 JA000076 u.s. Patent Oct. 23, 2001 Sheet 11 of 23 US 6,308,317 Bl / 112 I LOAD 8 o 0 0 V- 114 --------- --------- o --------- o - - - -0- - - - - --------- 5 --------- --------- --------- o 0 0 Word-Based Operand Stack FIGURE 11 / 116 I LOAD_B ~ 8 II 118 0 0 0 5 0 0 0 Byte-Based Operand Stack Case: 13-1397 Document: 34 Page: 134 Filed: 07/09/2013 C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 1
F i l e d
1 0 / 2 2 / 1 0
P a g e
1 4
o f
4 5 J A 0 0 0 0 7 7 10 Integrated Circuit Card 28 r 120 / / "\ 7 "\ \ Loading I I I \ Card II I And Loader Execution Control I I \ - -;---
I Card Operating System Card File System FIGURE 12 124 I I I I d . rJl .
.....
= ..... 0 /") :-'" N
N C c '""'" 'JJ. =-
..... '""'" N 0 ...., N
e rJ'l 0'1
Q 00
I--" ""-l
I--" Case: 13-1397 Document: 34 Page: 135 Filed: 07/09/2013 C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 1
F i l e d
1 0 / 2 2 / 1 0
P a g e
1 5
o f
4 5 J A 0 0 0 0 7 8 Card File System 126 124 Card JVM Integrated Circuit Card 10 14 136 134 Integrated Circuit Card Driver , , Communicator Driver Terminal 132 12b 14 1 1 .1 Communicator Terminal FIGURE 13 d . rJl . ~ ~ ..... ~ = ..... o /") :-'" N ~ ~ N C C '""'" 'JJ. =-
~ ..... '""'" o ...., N ~ e rJ'l 0'1 ~ Q 00 ~ I--" ""-l ~ I--" Case: 13-1397 Document: 34 Page: 136 Filed: 07/09/2013 C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 1
F i l e d
1 0 / 2 2 / 1 0
P a g e
1 6
o f
4 5 J A 0 0 0 0 7 9 -----------------_. 144c RAM Heap ______ -- -------- ----- j -EEPROM Heap 1468 System Stack 148\ I File System V- 147 VM Stack /141a 1 LOADABLE APPLCATION A 1 144a f /141b System Variables I ~ LOADABLE APPLCATION B I ~ 144b /141C Card RAM \. 141 L...-- 1 LOADABLE CLASS LIBRARY I Card ROM / 140 EEPROM Program Area Card EEPROM "-142 Loading And Execution Control 1\.120 I FIXED APPLICATION I '-- ~ Instruction Dispatch Loop 1"- 150 149""\ ~ 140a Run - Time Instruction 16...1 145J' Support Support L. I CLASS LIBRARY I ~ 1 6 5 d "- 140b Card JVM 1 148.../ r Card Operating System 122 ROM Program Area I Ir 149 149 r 149 FIGUR E 14 d . rJl . ~ ~ ..... ~ = ..... o /") :-'" N ~ ~ N C C '""'" 'JJ. =-
~ ..... '""'" o ...., N ~ e rJ'l 0'1 ~ Q 00 ~ I--" ""-l ~ I--" Case: 13-1397 Document: 34 Page: 137 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 17 of 45 JA000080 u.s. Patent Oct. 23, 2001 Execution Control Find Entry point class ID/method ID Interpret method Report Success Sheet 15 of 23 152 153 NO FIGURE 15 US 6,308,317 Bl Stop Card JVM and send Error to terminal Case: 13-1397 Document: 34 Page: 138 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 18 of 45 JA000081 u.s. Patent Oct. 23, 2001 Sheet 16 of 23 US 6,308,317 Bl 160 Set VM stack Parameters Set Card JVM program Counter YES 163 Handle native method NO Place return value on VM Stack 1658""\ Prepare for branch Retrieve next byte code/type information 165b Check VM stack state (Pass 3 security checks) 165c Execute byte code 165d Set VM stack state 165e 165f Retire the byte code FIGURE 16 Case: 13-1397 Document: 34 Page: 139 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 19 of 45 JA000082 u.s. Patent Oct. 23, 2001 Sheet 17 of 23 a byte code 172 execute bytecode NO Report Success FIGURE 17 US 6,308,317 Bl Stop Card JVM and Send error to terminal Case: 13-1397 Document: 34 Page: 140 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 20 of 45 JA000083 u.s. Patent Oct. 23, 2001 Sheet 18 of 23 US 6,308,317 Bl 160 Set VM stack Parameters Set Card JVM program Counter YES NO 163 Handle native method Place return value on VM Stack Retrieve next byte code 165b Execute byte code 165d FIGURE 18 Case: 13-1397 Document: 34 Page: 141 Filed: 07/09/2013 C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 1
F i l e d
1 0 / 2 2 / 1 0
P a g e
2 1
o f
4 5 J A 0 0 0 0 8 4 126 126X\ 126y\ Card Card Application Application X y / 190 \ 1908\ / 190b"\ / Identity Identity A B FIGURE 19 126Z\ Card Application Z / 190C\ Identity C J d . rJl . ~ ~ ..... ~ = ..... o /") :-'" N ~ ~ N C C '""'" 'JJ. =-
~ ..... '""'" \C o ...., N ~ e rJ'l 0'1 ~ Q 00 ~ I--" ""-l ~ I--" Case: 13-1397 Document: 34 Page: 142 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 22 of 45 JA000085 u.s. Patent Oct. 23, 2001 Sheet 20 of 23 US 6,308,317 Bl 200 '\ Card ;126Z Run Program C Application Z r 190c Identity Enter PIN of A C , , , , , , Access Not , , , Allowed ,," , , , , , 204"\ , j{" 202"\ Other Identity Files C's Files FIGURE 20 Case: 13-1397 Document: 34 Page: 143 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 23 of 45 JA000086 u.s. Patent Oct. 23, 2001 Sheet 21 of 23 US 6,308,317 Bl 10 FIGURE 21 220 210 FIGURE 22 Case: 13-1397 Document: 34 Page: 144 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 24 of 45 JA000087 u.s. Patent Oct. 23, 2001 Sheet 22 of 23 US 6,308,317 Bl FIGURE 23 240 FIGURE 24 Case: 13-1397 Document: 34 Page: 145 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 25 of 45 JA000088 u.s. Patent Oct. 23, 2001 Sheet 23 of 23 US 6,308,317 Bl It) N W 0:: :::J (!) - LL Case: 13-1397 Document: 34 Page: 146 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 26 of 45 JA000089 US 6,308,317 B1 1 USING A HIGH LEVEL PROGRAMMING LANGUAGE WITH A MICROCONTROLLER Under 35 U.S.c. 119(e), this application claims benefit of prior U.S. provisional application Serial No. 60/029,057, filed Oct. 25, 1996. 2 processing 16,32, or 64 bits of information or more with a single instruction. In contrast to the microprocessor, a micro- controller includes a central processing unit, memory and other functional elements, all on a single semiconductor substrate, or integrated circuit (e.g., a "chip"). As compared to the relatively large external memory accessed by the microprocessor, the typical micro controller accesses a much smaller memory. A typical microcontroller can access one to sixty-four kilobytes of built-in memory, with sixteen kilo- A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 10 bytes being very common. There are generally three different types of memory used: random access memory (RAM), read only memory (ROM), and electrically erasable programmable read only memory (EEPROM). In a microcontroller, the amount of each kind BACKGROUND OF THE INVENTION This invention relates in general to the field of programming, and more particularly to using a high level programming language with a smart card or a microcontrol- ler. 15 of memory available is constrained by the amount of space on the integrated circuit used for each kind of memory. Typically, RAM takes the most space, and is in shortest supply. ROM takes the least space, and is abundant. EEPROM is more abundant than RAM, but less than ROM. Each kind of memory is suitable for different purposes. Software applications written in the Java high-level pro- 20 gramming language have been so designed that an applica- tion written in Java can be run on many different computer brands or computer platforms without change. This is accomplished by the following procedure. When a Java application is written, it is compiled into "Class" files containing byte codes that are instructions for a hypothetical computer called a Java Virtual Machine. An implementation of this virtual machine is written for each platform that is supported. When a user wishes to run a particular Java application on a selected platform, the class files compiled from the desired application is loaded onto the selected platform. The Java virtual machine for the selected platform Although ROM is the least expensive, it is suitable only for data that is unchanging, such as operating system code. EEPROM is useful for storing data that must be retained when power is removed, but is extremely slow to write. 25 RAM can be written and read at high speed, but is expensive and data in RAM is lost when power is removed. A micro- processor system typically has relatively little ROM and EEPROM, and has 1 to 128 megabytes of RAM, since it is 30 is run, and interprets the byte codes in the class file, thus effectively running the Java application. 35 system that serves as a large writable, non-volatile storage area at a lower cost than EEPROM. However, a microcon- troller typically has a small RAM of 0.1 to 2.0 K, 2K to 8K of EEPROM, and 8K-56K of ROM. Due to the small number of external components required and their small size, microcontrollers frequently are used in integrated circuit cards, such as smart cards. Such smart cards come in a variety of forms, including contact-based Java is described in the following references which are hereby incorporated by reference: (1) Arnold, Ken, and James Gosling, "The Java Programming Language," Addison-Wesley, 1996; (2) James Gosling, Bill Joy, and Guy Steele, "The Java Language Specification," Sun Microsystems, 1996, (web site: http://java.sun.com/doc/ language_specification); (3) James Gosling and Henry McGilton, "The Java Language Environment: A White Paper," Sun Microsystems, 1995 (web site: http:// java.sun.com/doc/language_environmentl); and (4) Tim Lindholm and Frank Yellin, "The Java Virtual Machine Specification," Addison-Wesley, 1997. These texts among many others describe how to program using Java. 40 cards, which must be inserted into a reader to be used, and con tactless cards, which need not be inserted. In fact, microcontrollers with contactless communication are often embedded into specialized forms, such as watches and rings, effectively integrating the functionality of a smart card in an 45 ergonomically attractive manner. In order for a Java application to run on a specific platform, a Java virtual machine implementation must be 50 written that will run within the constraints of the platform, and a mechanism must be provided for loading the desired Java application on the platform, again keeping within the constraints of this platform. Conventional platforms that support Java are typically 55 microprocessor-based computers, with access to relatively large amounts of memory and hard disk storage space. Such microprocessor implementations frequently are used in desktop and personal computers. However, there are no conventional Java implementations on micro controllers, as 60 would typically be used in a smart card. Because of the constrained environment, applications for smart cards are typically written in a low level programming language (e.g., assembly language) to conserve memory. The integrated circuit card is a secure, robust, tamper- resistant and portable device for storing data. The integrated circuit card is the most personal of personal computers because of its small size and because of the hardware and software data security features unique to the integrated circuit card. The primary task of the integrated circuit card and the microcontroller on the card is to protect the data stored on the card. Consequently, since its invention in 1974, inte- grated circuit card technology has been closely guarded on these same security grounds. The cards were first used by French banks as debit cards. In this application, before a financial transaction based on the card is authorized, the card user must demonstrate knowledge of a 4-digit personal identification number (PIN) stored in the card in addition to being in possession of the card. Any information that might Microcontrollers differ from microprocessors in many ways. For example, a microprocessor typically has a central processing unit that requires certain external components (e.g., memory, input controls and output controls) to func- tion properly. A typical microprocessor can access from a megabyte to a gigabyte of memory, and is capable of 65 contribute to discovering the PIN number on a lost or stolen card was blocked from public distribution. In fact, since nobody could tell what information might be useful in this Case: 13-1397 Document: 34 Page: 147 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 27 of 45 JA000090 US 6,308,317 B1 3 regard, virtually all information about integrated circuit cards was withheld. Due to the concern for security, applications written for integrated circuit cards have unique properties. For example, each application typically is identified with a particular owner or identity. Because applications typically are written in a low-level programming language, such as assembly language, the applications are written for a particular type of microcontroller. Due to the nature of low level programming languages, unauthorized applications may access data on the integrated circuit card. Programs written for an integrated circuit card are identified with a particular identity so that if two identities want to perform the same programming function there must be two copies of some portions of the application on the microcontroller of the integrated circuit card. Integrated circuit card systems have historically been closed systems. An integrated circuit card contained a dedi- cated application that was handcrafted to work with a specific terminal application. Security checking when an integrated circuit card was used consisted primarily of making sure that the card application and the terminal application were a matched pair and that the data on the card was valid. As the popularity of integrated circuit cards grew, it 4 high level languages such as Java and Eiffel, using powerful mainstream program development tools. New applications can be quickly proto typed and downloaded to a smart card in a matter of hours without resorting to soft masks. Embed- ded systems using microcontrollers can also gain many of these advantages for downloading new applications, high level program development, and rapid prototyping by mak- ing use of this invention. Implementations of the invention may include one or 10 more of the following. The high level programming lan- guage format of the application may have a class file format and may have a Java programming language format. The processor may be a micro controller. At least a portion of the memory may be located in the processor. 15 The application may have been processed from a second application that has a string of characters, and the string of characters may be represented in the first application by an identifier (e.g., an integer). The processor may be also configured to receive a request from a requester (e.g., a processor or a terminal) to access an 20 element (e.g., an application stored in the memory, data stored in the memory or the communicator) of the card, after receipt of the request, interact with the requester to authen- ticate an identity of the requester, and based on the identity, selectively grant access to the element. 25 became clear that integrated circuit card users would be averse to carrying a different integrated circuit card for each integrated circuit card application. Therefore, multiple coop- erating applications began to be provided on single provider 30 integrated circuit cards. Thus, for example, an automated teller machine (ATM) access card and a debit card may coexist on a single integrated circuit card platform. Nevertheless, this was still a closed system since all the applications in the terminal and the card were built by one 35 provider having explicit knowledge of the other providers. The memory may also store an access control list for the element. The access control list furnishes an indication of types of access to be granted to the identity, and based on the access control list, the processor selectively grants specific types of access (e.g., reading data, writing data, appending data, creating data, deleting data or executing an application) to the requester. The application may be one of a several applications stored in the memory. The processor may be further con- figured to receive a request from a requester to access one of the plurality of applications; after receipt of the request, determine whether said one of the plurality of applications The paucity of information about integrated circuit cards-particularly information about how to communicate with them and how to program them-has impeded the general application of the integrated circuit card. However, the advent of public digital networking (e.g., the Internet and the World Wide Web) has opened new domains of applica- tion for integrated circuit cards. In particular, this has lead to complies with a predetermined set of rules; and based on the determination, selectively grant access to the requester to said one of the plurality of applications. The predetermined 40 rules provide a guide for determining whether said one of the plurality of applications accesses a predetermined region of the memory. The processor may be further configured to authenticate an identity of the requester and grant access to a need to load new applications on the card that do not have explicit knowledge of the other providers, but without the 45 possibility of compromising the security of the card. However, typically, this is not practical with conventional cards that are programmed using low level languages. said one of the plurality of applications based on the identity. The processor may be also configured to interact with the terminal via the communicator to authenticate an identity; determine if the identity has been authenticated; and based on the determination, selectively allow communication between the terminal and the integrated circuit card. SUMMARY OF THE INVENTION In general, in one aspect, the invention features an inte- grated circuit card for use with a terminal. The integrated circuit card includes a memory that stores an interpreter and an application that has a high level programming language format. A processor of the card is configured to use the interpreter to interpret the application for execution and to use a communicator of the card to communicate with the terminal. Among the advantages of the invention are one or more of the following. New applications may be downloaded to a smart card without compromising the security of the smart card. These applications may be provided by different com- panies loaded at different times using different terminals. Security is not compromised since the applications are protected against unauthorized access of any application code or data by the security features provided by the Java virtual machine. Smart card applications can be created in 50 The communicator and the terminal may communicate via communication channels. The processor may also be configured to assign one of the communication channels to the identity when the processor allows the communication between the terminal and the integrated circuit card. The 55 processor may also be configured to assign a session key to the assigned communication channel and use the session key when the processor and the terminal communicate via the assigned communication channel. The terminal may have a card reader, and the communi- 60 cator may include a contact for communicating with the card reader. The terminal may have a wireless communication device, and the communicator may include a wireless trans- ceiver for communicating with the wireless communication device. The terminal may have a wireless communication 65 device, and the communicator may include a wireless trans- mitter for communicating with the wireless communication device. Case: 13-1397 Document: 34 Page: 148 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 28 of 45 JA000091 US 6,308,317 B1 5 In general, in another aspect, the invention features a method for use with an integrated circuit card and a terminal. The method includes storing an interpreter and at least one application having a high level programming language for- mat in a memory of the integrated circuit card. A processor of the integrated circuit card uses the interpreter to interpret the at least one application for execution, and the processor uses a communicator of the card when communicating between the processor and the terminal. 6 municate with the terminal and a memory that stores a first application that has been processed from a second applica- tion having a string of characters. The string of characters are represented in the first application by an identifier. The integrated circuit card includes a processor that is coupled to the memory. The processor is configured to use the inter- preter to interpret the first application for execution and to use the communicator to communicate with the terminal. In general, in another aspect, the invention features a In general, in another aspect, the invention features a smart card. The smart card includes a memory that stores a Java interpreter and a processor that is configured to use the interpreter to interpret a Java application for execution. 10 method for use with an integrated circuit card and a terminal. The method includes processing a second application to create a first application. The second application has a string of characters. The string of characters is represented by an identifier in the second application. An interpreter and the In general, in another aspect, the invention features a microcontroller that has a semiconductor substrate and a memory located in the substrate. A programming language interpreter is stored in the memory and is configured to implement security checks. A central processing unit is located in the substrate and is coupled to the memory. 15 first application are stored in a memory of the integrated circuit card. A processor uses an interpreter to interpret the first application for execution. In general, in another aspect, the invention features a microcontroller that includes a memory which stores an application and an interpreter. The application has a class file format. A processor of the microcontroller is coupled to the memory and is configured to use the interpreter to interpret the application for execution. Implementations of the invention may include one or 20 more of the following. The interpreter may be a Java byte code interpreter. The security checks may include establish- ing firewalls and may include enforcing a sandbox security model. In general, in another aspect, the invention features a smart card that has a programming language interpreter stored in a memory of the card. The interpreter is configured 25 In implementations of the invention, the microcontroller may also include a communicator that is configured to communicate with a terminal. In general, in another aspect, the invention features a method for use with an integrated circuit card. The method to implement security check. A central processing unit of the card is coupled to the memory. In general, in another aspect, the invention features an integrated circuit card that is used with a terminal. The card includes a communicator and a memory that stores an interpreter and first instructions of a first application. The first instructions have been converted from second instruc- tions of a second application. The integrated circuit card includes a processor that is coupled to the memory and is configured to use the interpreter to execute the first instruc- tions and to communicate with the terminal via the com- municator. 30 includes storing a first application in a memory of the integrated circuit card, storing a second application in the memory of the integrated circuit card, and creating a firewall that isolates the first and second applications so that the second application cannot access either the first application 35 or data associated with the first application. In general, in another aspect, the invention features an integrated circuit card for use with a terminal. The integrated circuit card includes a communicator that is configured to communicate with the terminal, a memory and a processor. 40 The memory stores applications, and each application has a high level programming language format. The memory also stores an interpreter. The processor is coupled to the memory and is configured to: a.) use the interpreter to interpret the applications for execution, b.) use the interpreter to create a Implementations of the invention may include one or more of the following. The first and/or second applications may have class file format(s). The first and/or second applications may include byte codes, such as Java byte codes. The first instructions may be generalized or renum- bered versions of the second instructions. The second instructions may include constant references, and the first instructions may include constants that replace the constant references of the second instructions. The second instruc- tions may include references, and the references may shift 50 location during the conversion of the second instructions to the first instructions. The first instructions may be relinked 45 firewall to isolate the applications from each other, and c.) use the communicator to communicate with the terminal. to the references after the shifting. The first instructions may include byte codes for a first type of virtual machine, and the second instructions may include byte codes for a second 55 type of virtual machine. The first type is different from the second type. In general, in another aspect, the invention features a method for use with an integrated circuit card. The method includes converting second instructions of a second appli - 60 cation to first instructions of a first application; storing the first instructions in a memory of the integrated circuit card; and using an interpreter of the integrated circuit card to execute the first instructions. In general, in another aspect, the invention features an 65 integrated circuit for use with a terminal. The integrated circuit card has a communicator that is configured to com- Other advantages and features will become apparent from the following description and from the claims. BRIEF DESCRIPTION OF THE DRAWING FIG. 1 is a block diagram of an integrated card system. FIG. 2 is a flow diagram illustrating the preparation of Java applications to be downloaded to an integrated circuit card. FIG. 3 is a block diagram of the files used and generated by the card class file converter. FIG. 4 is a block diagram illustrating the transformation of application class file(s) into a card class file. FIG. 5 is a flow diagram illustrating the working of the class file converter. FIG. 6 is a flow diagram illustrating the modification of the byte codes. FIG. 7 is a block diagram illustrating the transformation of specific byte codes into general byte codes. FIG. 8 is a block diagram illustrating the replacement of constant references with constants. Case: 13-1397 Document: 34 Page: 149 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 29 of 45 JA000092 US 6,308,317 B1 7 FIG. 9 is a block diagram illustrating the replacement of references with their updated values. FIG. 10 is a block diagram illustrating renumbering of original byte codes. FIG. 11 is a block diagram illustrating translation of original byte codes for a different virtual machine architec- ture. FIG. 12 is a block diagram illustrating loading applica- tions into an integrated circuit card. FIG. 13 is a block diagram illustrating executing appli- cations in an integrated circuit card. FIG. 14 is a schematic diagram illustrating memory organization for ROM, RAM and EEPROM. 8 communicator 12b. The terminal communicator 12b is a communications device capable of establishing a commu- nications channel between the integrated circuit card 10 and the terminal 14. Some communication options include con- tact card readers, wireless communications via radio fre- quency or infrared techniques, serial communication protocols, packet communication protocols, ISO 7816 com- munication protocol, to name a few. The terminal 14 can also interact with applications run- 10 ning in the integrated circuit card 10. In some cases, different terminals may be used for these purposes. For example, one kind of terminal may be used to prepare applications, different terminals could be used to download the FIG. 15 is a flow diagram illustrating the overall archi- 15 tecture of the Card Java virtual machine. applications, and yet other terminals could be used to run the various applications. Terminals can be automated teller machines (ATMs), point-of-sale terminals, door security FIG. 16 is a flow diagram illustrating method execution in the Card Java virtual machine with the security checks. FIG. 17 is a flow diagram illustrating byte code execution 20 in the Card Java virtual machine. systems, toll payment systems, access control systems, or any other system that communicates with an integrated circuit card or microcontroller. The integrated circuit card 10 contains a card Java virtual machine (Card JVM) 16, which is used to interpret appli- cations which are contained on the card 10. FIG. 18 is a flow diagram illustrating method execution in the Card Java virtual machine without the security checks. FIG. 19 is a block diagram illustrating the association between card applications and identities. FIG. 20 is a block diagram illustrating the access rights of a specific running application. FIG. 21 is a perspective view of a microcontroller on a smart card. FIG. 22 is a perspective view of a microcontroller on a telephone. FIG. 23 is a perspective view of a microcontroller on a key ring. Referring to FIG. 2, the Java application 20 includes three 25 Java source code files Ajava 20a, B.java 20b, and c.java 20c. These source code files are prepared and compiled in a Java application development environment 22. When the Java application 20 is compiled by the development envi- ronment 22, application class files 24 are produced, with 30 these class files Aclass 24a, B.class 24b, and C.class 24c corresponding to their respective class Java source code 20a, 20b, and 20c. The application class files 24 follow the standard class file format as documented in chapter 4 of the Java virtual machine specification by Tim Lindholm and FIG. 24 is a perspective view of a microcontroller on a 35 Frank Yellin, "The Java Virtual Machine Specification," Addison-Wesley, 1996. These application class files 24 are fed into the card class file converter 26, which consolidates and compresses the files, producing a single card class file 27. The card class file 27 is loaded to the integrated circuit ring. FIG. 25 is a perspective view of a microcontroller on a circuit card of an automobile. DETAILED DESCRIPTION OF IRE PREFERRED EMBODIMENTS Referring to FIG. 1, an integrated circuit card 10 (e.g., a smart card) is constructed to provide a high level, Java- based, multiple application programming and execution environment. The integrated circuit card 10 has a commu- nicator 12a that is configured to communicate with a ter- minal communicator 12b of a terminal 14. In some embodiments, the integrated circuit card 10 is a smart card with an 8 bit microcontroller, 512 bytes of RAM, 4K bytes of EEPROM, and 20K of ROM; the terminal communicator 12b is a conventional contact smart card reader; and the terminal 14 is a conventional personal computer running the Windows NT operating system supporting the personal computer smart card (PC/SC) standard and providing Java development support. In some embodiments, the microcontroller, memory and communicator are embedded in a plastic card that has substantially the same dimensions as a typical credit card. In other embodiments, the microcontroller, memory and com- municator are mounted within bases other than a plastic card, such as jewelry (e.g., watches, rings or bracelets), automotive equipment, telecommunication equipment (e.g., subscriber identity module (SIM) cards), security devices (e.g., cryptographic modules) and appliances. The terminal 14 prepares and downloads Java applica- tions to the integrated circuit card 10 using the terminal 40 card 10 using a conventional card loader 28. Referring to FIG. 3, the card class file converter 26 is a class file postprocessor that processes a set of class files 24 that are encoded in the standard Java class file format, optionally using a string to ID input map file 30 to produce 45 a Java card class file 27 in a card class file format. One such card class file format is described in Appendix A which is hereby incorporated by reference. In addition, in some embodiments, the card class file converter 26 produces a string to ID output map file 32 that is used as input for a 50 subsequent execution of the card class file converter. In some embodiments, in order for the string to ID mapping to be consistent with a previously generated card class file (in the case where multiple class files reference the same strings), the card class file converter 26 can accept 55 previously defined string to ID mappings from a string to ID input map file 30. In the absence of such a file, the IDs are generated by the card class file converter 26. Appendix B, which is hereby incorporated by reference, describes one possible way of implementing and producing the string to ID 60 input map file 30 and string to ID output map file 32 and illustrates this mapping via an example. Referring to FIG. 4, a typical application class file 24a includes class file information 41; a class constant pool 42; class, fields created, interfaces referenced, and method infor- 65 mation 43; and various attribute information 44, as detailed in aforementioned Java Virtual Machine Specification. Note that much of the attribute information 44 is not needed for Case: 13-1397 Document: 34 Page: 150 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 30 of 45 JA000093 US 6,308,317 B1 9 this embodiment and is eliminated 45 by the card class file converter 26. Eliminated attributes include SourceFile, ConstantValue, Exceptions, LineNumberTable, LocalVariableTable, and any optional vendor attributes. The typical card class file 27 as described in Appendix A is derived from the application class files 24 in the following manner. The card class file information 46 is derived from the aggregate class file information 41 of all application class files 24a, 24b, and 24c. The card class file constant pool 47 is derived from the aggregate class constant pool 42 10 of all application class files 24a, 24b, and 24c. The card class, fields created, interfaces referenced, and method infor- mation 48 is derived from the aggregate class, fields created, interfaces referenced, and method information 43 of all application class files 24a, 24b, and 24c. The card attribute 15 information 49 in this embodiment is derived from only the code attribute of the aggregate attribute information 44 of all application class files 24a, 24b, and 24c. 10 SourceFile, ConstantValue, Exceptions, LineNumberTable, and LocalvariableTable may be safely discarded 45. The only attribute that is retained is the Code attribute. The Code attribute contains the byte codes that correspond to the methods in the Java class file 24a. Modifying the byte codes 54 involves examining the Code attribute information 44 for each method in the class file, and modifying the operands of byte codes that refer to entries in the Java class file constant pool 42 to reflect the entries in the card class file constant pool 47. In some embodiments, the byte codes are also modified, as described below. To avoid dynamic linking in the card, all the information that is distributed across several Java class files 24a, 24b, and 24c that form the application 24, are coalesced into one card class file 27 by the process shown in the flowchart in FIG. 5. The first class file to be processed is selected 51a. The constant pool 42 is compacted 51b in the following manner. All objects, classes, fields, methods referenced in a Java class file 24a are identified by using strings in the constant pool 42 of the class file 24a. The card class file converter 26 compacts the constant pool 42 found in the Java class file 24a into an optimized version. This compaction is achieved by mapping all the strings found in the class file 30 constant pool 42 into integers (the size of which is micro- controller architecture dependent). These integers are also referred to as IDs. Each ID uniquely identifies a particular object, class, field or method in the application 20. Therefore, the card class file converter 26 replaces the 35 strings in the Java class file constant pool 42 with its corresponding unique ID. Appendix B shows an example application HelloSmartCard.java, with a table below illus- trating the IDs corresponding to the strings found in the constant pool of the class file for this application. The IDs 40 used for this example are 16-bit unsigned integers. Modifying the byte codes 54 involves five passes (with two optional passes) as described by the flowchart in FIG. 6. The original byte codes 60 are found in the Code attribute 44 of the Java class file 24a being processed. The first pass 61 records all the jumps and their destinations in the original byte codes. During later byte code translation, some single byte code may be translated to dual or triple bytes. FIG. 7 20 illustrates an example wherein byte code ILOAD_O is replaced with two bytes, byte code ILOAD and argument O. When this is done, the code size changes, requiring adjust- ment of any jump destinations which are affected. Therefore, before these transformations are made, the original byte 25 codes 60 are analyzed for any jump byte codes and a note made of their position and current destination. The program code fragment marked "B" in Appendix D shows how these jumps are recorded. Appendix D is hereby incorporated by Next, the card class file converter 26 checks for unsup- ported features 51c in the Code attribute of the input Java class file 24a. The Card JVM 16 only supports a subset of the full Java byte codes as described in Appendix C, which 45 is hereby incorporated by reference. Hence, the card class file converter 26 checks for unsupported byte codes in the Code attribute of the Java class file 24a. If any unsupported byte codes are found 52, the card class file converter flags an error and stops conversion 53. The program code fragment 50 marked "A" in APPENDIX D shows how these spurious byte codes are apprehended. Another level of checking can be performed by requiring the standard Java development environment 22 to compile the application 20 with a '-g' flag. Based on the aforementioned Java virtual machine 55 specification, this option requires the Java compiler to place information about the variables used in a Java application 20 in the LocalVariableTable attribute of the class file 24a. The card class file converter 26 uses this information to check if the Java class file 24a references data types not supported by 60 the Java card. reference. Once the jumps are recorded, if the optional byte code translation is not being performed 62, the card class file converter 26 may proceed to the third pass 64. Otherwise, the card class file converter converts specific byte codes into generic byte codes. Typically, the translated byte codes are not interpreted in the Card JVM 16 but are supported by converting the byte codes into equivalent byte codes that can be interpreted by the Card JVM 16 (see FIG. 7). The byte codes 70 may be replaced with another seman- tically equivalent but different byte codes 72. This generally entails the translation of short single specific byte codes such as ILOAD_O into their more general versions. For example, ILOAD_O may be replaced by byte code ILOAD with an argument O. This translation is done to reduce the number of byte codes translated by the Card JVM 16, consequently reducing the complexity and code space requirements for the Card JVM 16. The program code fragment marked "c" in Appendix D shows how these translations are made. Note that such translations increase the size of the resulting byte code and force the re-computation of any jumps which are affected. In the third pass 64, the card class file converter rebuilds constant references via elimination of the strings used to denote these constants. FIG. 8 shows an example wherein the byte code LDC 80 referring to constant "18" found via an index in the Java class file 24a constant pool 42 may be translated into BIPUSH byte code 82. In this pass the card class file converter 26 modifies the operands to all the byte codes that refer to entries in the Java class file constant pool 42 to reflect their new location in the card class file constant pool 47. FIG. 9 shows an example wherein the argument to a byte code, INVOKESTATIC 90, refers to an entry in the Java class file constant pool 42 that is modified to reflect the new location of that entry in the card class file constant pool Next, the card class file converter 26 discards all the unnecessary parts 51c of the Java class file 24a not required for interpretation. A Java class file 24a stores information pertaining to the byte codes in the class file in the Attributes section 44 of the Java class file. Attributes that are not required for interpretation by the card JVM 16, such as 65 47. The modified operand 94 shows this transformation. The program code fragment marked "D" in Appendix D shows how these modifications are made. Case: 13-1397 Document: 34 Page: 151 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 31 of 45 JA000094 US 6,308,317 B1 11 Once the constant references are relinked, if the optional byte code modification is not being performed, the card class file converter may proceed to the fifth and final pass 67. 12 ating system 122. In the preferred embodiment, the boot- strap loader is written in Java, and the integrated circuit card 10 includes a Java virtual machine to run this application. A Java implementation of the loading and execution control 120 is illustrated in Appendix E which is hereby incorpo- rated by reference. The loading and execution control 120 receives the card class file 26 and produces a Java card application 126x stored in the card file system 126 in the EEPROM of the integrated circuit card 10. Multiple Java Otherwise, the card class file converter modifies the original byte codes into a different set of byte codes sup- ported by the particular Card JVM 16 being used. One potential modification renumbers the original byte codes 60 into Card JVM 16 byte codes (see FIG. 10). This renum- bering causes the byte codes 100 in the original byte codes 60 to be modified into a renumbered byte codes 102. Byte code ILOAD recognized by value 21 may be renumbered to be recognized by value 50. This modification may be done for optimizing the type tests (also known in prior art as Pass 10 card applications 126x, 126y, and 126z can be stored in a single card in this manner. The loading and execution control 120 supports commands whereby the terminal 14 can select which Java card application to run immediately, or upon the next card reset. 3 checks) in the Card JVM 16. The program code fragment marked "E" in Appendix D shows an implementation of this 15 embodiment. This modification may be done in order to reduce the program space required by the Card JVM 16 to interpret the byte code. Essentially this modification regroups the byte codes into Card JVM 16 byte codes so that byte codes with similar operands, results are grouped together, and there are no gaps between Card JVM 16 byte codes. This allows the Card JVM 16 to efficiently check Card JVM 16 byte codes and validate types as it executes. Referring to FIG. 13, upon receiving a reset or an execu- tion command from the loading and execution control 120, the Card Java Virtual Machine (Card JVM) 16 begins execution at a predetermined method (for example, main) of the selected class in the selected Java Card application 126z. In some embodiments, the card class file converter modi- fies the original byte codes 60 into a different set of byte codes designed for a different virtual machine architecture, 20 The Card JVM 16 provides the Java card application 126z access to the underlying card operating system 122, which provides capabilities such as I/O, EEPROM support, file systems, access control, and other system functions using native Java methods as illustrated in Appendix F which is 25 hereby incorporated by reference. as shown in FIG. 11. The Java byte code ILOAD 112 intended for use on a word stack 114 may be replaced by Card JVM 16 byte code ILOAD_B 116 to be used on a byte stack 118. An element in a word stack 114 requires allocat- 30 ing 4 bytes of stack space, whereas an element in the byte stack 118 requires only one byte of stack space. Although this option may provide an increase in execution speed, it risks losing the security features available in the original byte codes. 35 Since the previous steps 63, 64 or 66 may have changed the size of the byte codes 60 the card class file converter 26 has to relink 67 any jumps which have been effected. Since the jumps were recorded in the first step 61 of the card class 40 file converter 26, this adjustment is carried out by fixing the jump destinations to their appropriate values. The program code fragment marked "F" in Appendix D shows how these jumps are fixed. The selected Java card application 126z communicates with an appropriate application in the terminal 14 using the communicator 12a to establish a communication channel to the terminal 14. Data from the communicator 12a to the terminal 14 passes through a communicator driver 132 in the terminal, which is specifically written to handle the com- munications protocol used by the communicator 12a. The data then passes to an integrated circuit card driver 134, which is specifically written to address the capabilities of the particular integrated circuit card 10 being used, and provides high level software services to the terminal application 136. In the preferred embodiment, this driver would be appro- priate PC/SC Smartcard Service Provider (SSP) software. The data then passes to the terminal application 136, which must handle the capabilities provided by the particular card application 126z being run. In this manner, commands and responses pass back and forth between the terminal appli- cation 136 and the selected card application 126z. The terminal application interacts with the user, receiving com- The card class file converter now has modified byte codes 68 that is equivalent to the original byte codes 60 ready for loading. The translation from the Java class file 24a to the card class file 27 is now complete. 45 mands from the user, some of which are passed to the selected Java card application 126z, and receiving responses from the Java card application 126z, which are processed and passed back to the user. Referring to FIG. 14, the Card JVM 16 is an interpreter Referring back to FIG. 5, if more class files 24 remain to be processed 55 the previous steps 51a, 51b, 51c, 52 and 54 are repeated for each remaining class file. The card class file converter 26 gathers 56 the maps and modified byte codes for the classes 24 that have been processed, places them as 50 that interprets a card application 126x. The memory resources in the micro controller that impact the Card JVM 16 are the Card ROM 140, Card RAM 141 and the Card EEPROM 142. The Card ROM 140 is used to store the Card an aggregate and generates 57 a card class file 27. If required, the card class file converter 26 generates a string 55 to ID output map file 32, that contains a list of all the new IDs allocated for the strings encountered in the constant pool 42 of the Java class files 24 during the translation. Referring to FIG. 12, the card loader 28 within the terminal 14 sends a card class file to the loading and 60 execution control 120 within the integrated circuit card 10 using standard ISO 7816 commands. The loading and execu- tion control 120 with a card operating system 122, which provides the necessary system resources, including support for a card file system 124, which can be used to store several 65 card applications 126. Many conventional card loaders are written in low level languages, supported by the card oper- JVM 16 and the card operating system 122. Card ROM 140 may also be used to store fixed card applications 140a and class libraries 140b. Loadable applications 141a, 141b and libraries 141c may also be stored in Card RAM 141. The Card JVM 16 interprets a card application 141a, 141b, or 140a. The Card JVM 16 uses the Card RAM to store the VM stack 144a and system state variables 144b. The Card JVM 16 keeps track of the operations performed via the VM stack 144a. The objects created by the Card JVM 16 are either on the RAM heap 144c, in the EEPROM heap 146a, or in the file system 147. All of the heap manipulated by the Card JVM 16 may be stored in the Card RAM 141 as a RAM Heap 144c, or it may be distributed across to the Card EEPROM 142 as a Case: 13-1397 Document: 34 Page: 152 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 32 of 45 JA000095 US 6,308,317 B1 13 EEPROM Heap 146a. Card RAM 141 is also used for recording the state of the system stack 148 that is used by routines written in the native code of the microcontroller. The Card JVM 16 uses the Card EEPROM 142 to store application data either in the EEPROM heap 146a or in the file system 147. Application data stored in a file may be manipulated via an interface to the card operating system 122. This interface is provided by a class library 140b stored in Card ROM 140, by a loadable class library 141c stored in Card EEPROM 142. One such interface is described in Appendix F. Applications and data in the card are isolated by a firewall mechanism 149. To cope with the limited resources available on microcontrollers, the Card JVM 16 implements a strict subset of the Java programming language. Consequently, a Java application 20 compiles into a class file that contains a strict subset of Java byte codes. This enables application programmers to program in this strict subset of Java and still maintain compatibility with existing Java Virtual Machines. The semantics of the Java byte codes interpreted by the Card JVM 16 are described in the aforementioned Java Virtual Machine Specification. The subset of byte codes interpreted by the Card JVM 16 can be found in Appendix C. The card class file converter 26 checks the Java application 20 to ensure use of only the features available in this subset and converts into a form that is understood and interpreted by the Card JVM 16. In other embodiments, the Card JVM 16 is designed to interpret a different set or augmented set of byte codes 116. Although a different byte code set might lead to some performance improvements, departing from a strict Java subset may not be desirable from the point of view of security that is present in the original Java byte codes or compatibility with mainstream Java development tools. All Card JVM 16 applications 126 have a defined entry point denoted by a class and a method in the class. This entry point is mapped in the string to ID input map 30 and assigned by the card class file converter 26. Classes, meth- ods and fields within a Java application 20 are assigned IDs by the card class file converter 26. For example, the ID corresponding to the main application class may be defined as FOOl and the ID corresponding to its main method, such as "mainOV" could be defined as F002. The overall execution architecture of the Card JVM is described by the flowchart in FIG. 15. Execution of the Card JVM 16 begins at the execution control 120, which chooses a card application 126z to execute. It proceeds by finding and assigning an entry point 152 (a method) in this card application for the Card JVM 16 to interpret. The Card JVM 16 interprets the method 153. If the interpretation proceeds successfully 154, the Card JVM 16 reports success 155 returning control back to the execution control 120. If in the course of interpretation 153 the Card JVM 16 encounters an unhandled error or exception (typically a resource limitation or a security violation), the Card JVM 16 stops 156 and reports the appropriate error to the terminal 14. An essential part of the Card JVM 16 is a subroutine that handles the execution of the byte codes. This subroutine is described by the flowchart in FIG. 16. Given a method 160 it executes the byte codes in this method. The subroutine starts by preparing for the parameters of this method 161. This involves setting the VM stack 144a pointer, VM stack 144a frame limits, and setting the program counter to the first byte code of the method. Next, the method flags are checked 162. If the method is flagged native, then the method is actually a call to native 14 method code (subroutine written in the microcontroller's native processor code). In this case, the Card JVM 16 prepares for an efficient call 163 and return to the native code subroutine. The parameters to the native method may be passed on the VM stack 144a or via the System stack 148. The appropriate security checks are made and the native method subroutine is called. On return, the result (if any) of the native method subroutine is placed on the VM stack 144a so that it may be accessed by the next byte code to be 10 executed. The dispatch loop 164 of the Card JVM 16 is then entered. The byte code dispatch loop is responsible for preparing, executing, and retiring each byte code. The loop terminates when it finishes interpreting the byte codes in the method 15 160, or when the Card JVM 16 encounters a resource limitation or a security violation. If a previous byte code caused a branch to be taken 165 the Card JVM prepares for the branch 165a. The next byte code is retrieved 165b. In order to keep the cost of process- 20 ing each byte code down, as many common elements such as the byte code arguments, length, type are extracted and stored. To provide the security offered by the security model of 25 the programming language, byte codes in the class file must be verified and determined conformant to this model. These checks are typically carried out in prior art by a program referred to as the byte code verifier, which operates in four passes as described in the Java Virtual Machine Specifica- 30 tion. To offer the run-time security that is guaranteed by the byte code verifier, the Card JVM 16 must perform the checks that pertain to the Pass 3 and Pass 4 of the verifier. This checking can be bypassed by the Card JVM 16 if it can be guaranteed (which is almost impossible to do) that the byte 35 codes 60 interpreted by the Card JVM 16 are secure. At the minimum, code security can be maintained as long as object references cannot be faked and the VM stack 144a and local variable bounds are observed. This requires checking the state of the VM stack 144a with respect to the byte code 40 being executed. To enforce the security model of the programming language, a 256-byte table is created as shown in Appendix G which is hereby incorporated by reference. This table is indexed by the byte code number. This table contains the 45 type and length information associated with the indexing byte code. It is encoded with the first 5 bits representing type, and the last 3 bits representing length. The type and length of the byte code is indexed directly from the table by the byte code number. This type and length is then used for 50 checking as shown in Appendix H which is hereby incor- porated by reference. In Appendix H, the checking process begins by decoding the length and type from the table in Appendix G which is hereby incorporated by reference. The length is used to increment the program counter. The type is 55 used first for pre-execution checking, to insure that the data types on the VM stack 144a are correct for the byte code that is about to be executed. The 256 bytes of ROM for table storage allows the original Java byte codes to be run in the Card JVM 16 and minimizes the changes required to the 60 Java class file to be loaded in the card. Additional Java byte codes can be easily supported since it is relatively easy to update the appropriate table entries. In other embodiments, as shown in FIG. 10, the Java byte codes in the method are renumbered in such a manner that 65 the byte code type and length information stored in the table in Appendix H is implicit in the reordering. Appendix H is hereby incorporated by reference. Consequently, the checks Case: 13-1397 Document: 34 Page: 153 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 33 of 45 JA000096 US 6,308,317 B1 15 16 To isolate data and applications in the integrated circuit card 10 from each other, the integrated circuit card 10 relies on the firewall mechanism 149 provided by the Card JVM 16. Because the Card JVM implements the standard pass 3 and pass 4 verifier checks, it detects any attempt by an application to reference the data or code space used by another application, and flag a security error 156. For example, conventional low level applications can cast non- reference data types into references, thereby enabling access that must be performed on the state of the VM stack 144a and the byte code being processed does not have to involve a table look up. The checks can be performed by set of simple comparisons as shown in Appendix I which is hereby incorporated by reference. This embodiment is preferable when ROM space is at a premium, since it eliminates a 256-byte table. However adding new byte codes to the set of supported byte codes has to be carefully thought out since the new byte codes have to fit in the implicit numbering scheme of the supported byte codes. In another embodiment, the Card JVM 16 chooses not to perform any security checks in favor of Card JVM 16 execution speed. This is illustrated in the flowchart in FIG. 18. The flow chart in FIG. 18 is the same as that of FIG. 16 with the security checks removed. This option is not desir- able from the point of view of security, unless it can be guaranteed that the byte codes are secure. 10 to unauthorized memory space, and violating security. With this invention, such an attempt by a card application 126z to use a non-reference data type as a reference will trigger a security violation 156. In conventional Java, this protected application environment is referred to as the sandbox 15 application-interpretation environment. The Card JVM 16 may enforce other security checks as well. If the byte code may reference a local variable, the Card JVM 16 checks if this reference is valid, throwing an error if it is not. If the reference is valid, the Card JVM 16 20 stores the type of the local variable for future checking. The VM stack 144a pointer is checked to see if it is still in a valid range. If not an exception is thrown. The byte code number is checked. If it is not supported, an exception is thrown. 25 Finally, the byte code itself is dispatched 165d. The byte codes translated by the Card JVM 16 are listed in Appendix C. The semantics of the byte codes are described in the aforementioned Java Virtual Machine Specification with regard to the state of the VM stack 144a before and after the 30 dispatch of the byte code. Note also that some byte codes (the byte codes, INVOKESTATIC, INVOKESPECIAL, INVOKENONVIRTUAL and INVOKEVIRTUAL) may cause reentry into the Card JVM 16, requiring processing to begin at the entry of the subroutine 161. FIG. 17 shows the 35 flowchart of the byte code execution routine. The routine is given a byte code 171 to execute. The Card JVM 16 executes 172 the instructions required for the byte code. If in the course of executing the Card JVM 16 encounters a resource limitation 173, it returns an error 156. This error is returned 40 to the terminal 16 by the Card JVM 16. If the byte code executes successfully, it returns a success 175. After execution, the type of the result is used to set the VM stack 144a state correctly 165e, properly flagging the data types on the VM stack 144a. The byte code information 45 gathered previously 165b from the byte code info table is used to set the state of the VM stack 144a in accordance with the byte code that just executed. In other embodiments, setting the output state of the VM stack 144a with respect to the byte code executed is sim- 50 plified if the byte code is renumbered. This is shown in Appendix I which is hereby incorporated by reference. In yet another embodiment, the Card JVM 16 may bypass setting the output state of the VM stack 144a in favor of Card JVM 16 execution speed. This option is not desirable 55 from the point of view of security, unless it can be guaran- teed that the byte codes are secure. After the byte code has been executed, the byte code is retired 165[. This involves popping arguments off the VM stack 144a. Once byte code processing is completed, the 60 loop 164 is repeated for the next byte code for the method. Once the dispatch loop 164 terminates, the VM stack 144a is emptied 166. This prevents any object references filtering down to other Card JVM 16 invocations and breaking the Card JVM's 16 security. Termination 167 of the 65 byte code dispatch loop 164 indicates that the Card JVM 16 has completed executing the requested method. However, these firewall facilities do not work indepen- dently. In fact, the facilities are overlapping and mutually reinforcing with conventional access control lists and encryption mechanisms shown in the following table: Acess Control Virtual Lists Machine Encryption Data access access only data to Protection control to own another before namespace program operation encrypted Program access execution data Protection control only on encrypted in before correct program's execution types namespace Communication access channel only mutually Protection control on controls authenticated channels in own parties can namespace communicate Taken together, these facilities isolate both data and applications on the integrated circuit card 10 and ensure that each card application 126 can access only the authorized resources of the integrated circuit card 10. Referring to FIG. 19, card applications 126x, 126y, 126z can be endowed with specific privileges when the card applications 126 execute. These privileges determine, for example, which data files the card applications 126 can access and what operations the card applications 126 can perform on the file system 147. The privileges granted to the card applications 126 are normally set at the time that a particular card application 126z is started by the user, typically from the terminal 14. The integrated circuit card 10 uses cryptographic identi- fication verification methods to associate an identity 190 (e.g., identities 190a, 190b and 190c) and hence, a set of privileges to the execution of the card application 126. The association of the specific identity 190c to the card appli- cation 126z is made when the card application 126z begins execution, thus creating a specific running application 200, as shown in FIG. 20. The identity 190 is a unique legible text string reliably associated with an identity token. The identity token (e.g., a personal identification number (PIN) or a RSA private key) is an encryption key. Referring to FIG. 20, in order to run a specific card application 126z, the identity 190c of the card application 126z must be authenticated. The identity 190c is authenti- cated by demonstrating knowledge of the identity token associated with the identity 190c. Therefore, in order to run the card application 126z, an agent (e.g., a card holder or Case: 13-1397 Document: 34 Page: 154 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 34 of 45 JA000097 US 6,308,317 B1 17 another application wishing to run the application) must show that it possesses or knows the application's identity- defining encryption key. 18 tion is accomplished by including in the identity authenti- cation process the exchange of a one-time session key 209 between the a card application 126z and the terminal appli- cation 136. The key 209 is then used to encrypt subsequent traffic between the authenticating terminal application 136 and the authenticated card application 126z. Given the one-time session key 209, a rogue terminal application can neither "listen in" on an authenticated communication between the terminal 14 and the integrated circuit card 10, One way to demonstrate possession of an encryption key is simply to expose the key itself. PIN verification is an example of this form of authentication. Another way to demonstrate the possession of an encryption key without actually exposing the key itself is to show the ability to encrypt or decrypt plain text with the key. 10 nor can the rogue terminal application "spoof' the card application into performing unauthorized operations on its behalf. Thus, a specific running application 200 on the integrated circuit card 10 includes a card application 126z plus an authenticated identity 190c. No card application 126 can be run without both of these elements being in place. The card application 126z defines data processing operations to be performed, and the authenticated identity 190c determines 15 on what computational objects those operations may be performed. For example, a specific application 126z can only access identity C's files 202 in the file system 147 associated with the specific identity 190c, and the specific card application 126z cannot access other files 204 that are 20 associated with identities other than the specific identity 190c. Encryption and decryption of card/terminal traffic can be handled either by the card operating system 122 or by the card application itself 126z. In the former case, the commu- nication with the terminal 14 is being encrypted transpar- ently to the application, and message traffic arrives decrypted in the data space of the application. In the latter case, the card application 126z elects to perform encryption and decryption to provide an extra layer of security since the application could encrypt data as soon as it was created and The integrated circuit card 10 may take additional steps to ensure application and data isolation. The integrated circuit 25 card 10 furnishes three software features sets: authenticated- would decrypt data only when it was about to be used. Otherwise, the data would remain encrypted with the session key 209. Thus, the application firewall includes three mutually reinforcing software sets. Data files are protected by authenticated-identity access control lists. Application execution spaces are protected by the Card JVM 16. Com- munication channels are protected with one-time session identity access control lists; a Java-based virtual machine; and one-time session encryption keys to protect data files, application execution, and communication channels, respec- tively. Collectively, for one embodiment, these features sets provide the application data firewalls 149 for one embodi- ment. The following discusses each software feature set and then shows how the three sets work together to insure application and data isolation on the integrated circuit card 10. An access control list (ACL) is associated with every computational object (e.g., a data file or a communication channel) on the integrated circuit card 10 that is be protected, i.e., to which access is to be controlled. An entry on an ACL (for a particular computational object) is in a data format referred to as an e-tuple: type:identity:permissions The type field indicates the type of the following identity (in the identity field), e.g., a user (e.g., "John Smith"), or a group. The permissions field indicates a list of operations (e.g., read, append and update) that can be performed by the identity on the computational object. As an example, for a data file that has the ACL entry: USER:AcmeAirlines:RAU, 30 encryption keys 209. In other embodiments, the above-described techniques are used with a microcontroller (such as the processor 12) may control devices (e.g., part of an automobile engine) other than an integrated circuit card. In these applications, the 35 microcontroller provides a small platform (i.e., a central processing unit, and a memory, both of which are located on a semiconductor substrate) for storing and executing high level programming languages. Most existing devices and new designs that utilize a microcontroller could use this 40 invention to provide the ability to program the microcon- troller using a high level language, and application of this invention to such devices is specifically included. The term application includes any program, such as Java applications, Java applets, Java aglets, Java servlets, Java 45 commlets, Java components, and other non-Java programs that can result in class files as described below. Class files may have a source other than Java program files. Several programming languages other than Java also have compilers or assemblers for generating class files from their respective source files. For example, the programming language Eiffel can be used to generate class files using Pirmin Kalberer's "J-Eiffel", an Eiffel compiler with JVM byte code generation (web site: http://www.spin.ch/ -kalberer/jive/index.htm). An Ada 95 to Java byte code any application whose identity is "AcmeAirlines" can read 50 ("R"), append ("A") and update ("U") the data file. In addition, the ACL may be used selectively to permit the creation and deletion of data files. Furthermore, the ACL may be used selectively to permit execution of an applica- tion. 55 translator is described in the following reference (incorporated herein by reference): Taft, S. Tucker, "Pro- gramming the Internet in Ada 95", proceedings of Ada Europe '96, 1996. Jasmin is a Java byte code assembler that can be used to generate class files, as described in the Whenever a computational object is accessed by a run- ning application 200, the access is intercepted by the Card JVM 16 and passed to the card operating system 122, which determines if there is an ACL associated with the object. If there is an associated ACL, then the identity 190c associated with the running application 200 is matched on the ACL. If the identity is not found or if the identity is not permitted for the type of access that is being requested, then the access is denied. Otherwise, the access is allowed to proceed. 60 following reference (incorporated herein by reference): Referring to FIG. 13, to prevent the potential problems 65 due to the single data path between the integrated circuit card 10 and the terminal 14, communication channel isola- Meyer, Jon and Troy Downing, "Java Virtual Machine", O'Reilly, 1997. Regardless of the source of the class files, the above description applies to languages other than Java to generate codes to be interpreted. FIG. 21 shows an integrated circuit card, or smart card, which includes a microcontroller 210 that is mounted to a plastic card 212. The plastic card 212 has approximately the Case: 13-1397 Document: 34 Page: 155 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 35 of 45 JA000098 US 6,308,317 B1 19 same form factor as a typical credit card. The communicator 12a can use a contact pad 214 to establish a communication channel, or the communicator 12a can use a wireless com- munication system. 20 2. The integrated circuit card of claim 1, wherein the high level programming language format comprises a class file format. 3. The integrated circuit card of claim 1 wherein the processor comprises a microcontroller. 4. The integrated circuit card of claim 1 wherein at least a portion of the memory is located in the processor. In other embodiments, a microcontroller 210 is mounted into a mobile or fixed telephone 220, effectively adding smart card capabilities to the telephone, as shown in FIG. 22. In these embodiments, the microcontroller 210 is mounted on a module (such as a Subscriber Identity Module (SIM)), for insertion and removal from the telephone 220. In other embodiments, a microcontroller 210 is added to a key ring 230 as shown in FIG. 23. This can be used to secure access to an automobile that is equipped to recognize the identity associated with the microcontroller 210 on the key ring 230. 5. The integrated circuit card of claim 1 wherein the high level programming language format comprises a Java pro- 10 gramming language format. 15 Jewelry such as a watch or ring 240 can also house a microcontroller 210 in an ergonomic manner, as shown in FIG. 24. Such embodiments typically use a wireless com- munication system for establishing a communication channel, and are a convenient way to implement access 20 control with a minimum of hassle to the user. 6. The integrated circuit card of claim 1, wherein the application has been processed from a second appli- cation having a plurality of program elements, at least one being a string of characters, and wherein in the first application the string of characters is replaced with an identifier. 7. The integrated circuit card of claim 6, wherein the identifier comprises an integer. 8. The integrated circuit card of claim 1 wherein the processor is further configured to: receive a request from a requester to access an element of the card; after receipt of the request, interact with the requester to authenticate an identity of the requester; and based on the identity, selectively grant access to the element. 9. The integrated circuit card of claim 8, wherein the requester comprises the processor. FIG. 25 illustrates a microcontroller 210 mounted in an electrical subsystem 252 of an automobile 254. In this embodiment, the micro controller is used for a variety of purposes, such as to controlling access to the automobile, 25 (e.g. checking identity or sobriety before enabling the igni- tion system of the automobile), paying tolls via wireless communication, or interfacing with a global positioning system (GPS) to track the location of the automobile, to name a few. 30 10. The integrated circuit card of claim 8, wherein the requester comprises the terminal. While specific embodiments of the present invention have been described, various modifications and substitutions will become apparent to one skilled in the art by this disclosure. Such modifications and substitutions are within the scope of the present invention, and are intended to be covered by the 35 appended claims. What is claimed is: 1. An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the 40 terminal; a memory storing: an application derived from a program written in a high level programming language format wherein the application is derived from a program written in a 45 high level programming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form, the converting step including at least one step selected from a group consisting of 50 recording all jumps and their destinations in the original byte codes; converting specific byte codes into equivalent generic byte codes or vice-versa; modifying byte code operands from references using 55 identifying strings to references using unique identifiers; and 11. The integrated circuit card of claim 8, wherein the element comprises the application stored in the memory, and once access is allowed, the requester is configured to use the application. 12. The integrated circuit card of claim 8, wherein the element comprises another application stored in the memory. 13. The integrated circuit card of claim 8, wherein the element includes data stored in the memory. 14. The integrated circuit card of claim 8 wherein the element comprises the communicator. 15. The integrated circuit card of claim 8, wherein the memory also stores an access control list for the element, the access control list furnishing an indication of types of access to be granted to the identity, the processor further configured to: based on the access control list, selectively grant specific types of access to the requester. 16. The integrated circuit card of claim 15 wherein the types of access include reading data. 17. The integrated circuit card of claim 15 wherein the types of access include writing data. 18. The integrated circuit card of claim 15 wherein the types of access include appending data. 19. The integrated circuit card of claim 15 wherein the types of access include creating data. renumbering byte codes in a compiled format to equivalent byte codes in a format suitable for interpretation; and 20. The integrated circuit card of claim 15 wherein the 60 types of access include deleting data. an interpreter operable to interpret such an application derived from a program written in a high level programming language format; and a processor coupled to the memory, the processor con- figured to use the interpreter to interpret the application for execution and to use the communicator to commu- nicate with the terminal. 21. The integrated circuit card of claim 15 wherein the types of access include executing an application. 22. The integrated circuit card of claim 1, wherein the application is one of a plurality of applications stored in the 65 memory, the processor is further configured to: receive a request from a requester to access one of the plurality of applications; Case: 13-1397 Document: 34 Page: 156 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 36 of 45 JA000099 US 6,308,317 B1 21 after receipt of the request, determine whether said one of the plurality of applications complies with a predeter- mined set of rules; and based on the determination, selectively grant access to the requester to said one of the plurality of applications. 23. The integrated circuit card of claim 22, wherein the predetermined rules provide a guide for determining whether said one of the plurality of applications accesses a predetermined region of the memory. 24. The integrated circuit card of claim 22, wherein the 10 processor is further configured to: authenticate an identity of the requester; and grant access to said one of the plurality of applications based on the identity. 25. The integrated circuit card of claim 1, wherein the 15 processor is further configured to: interact with the terminal via the communicator to authen- ticate an identity; and determine if the identity has been authenticated; and based on the determination, selectively allow communi- cation between the terminal and the integrated circuit card. 20 26. The integrated circuit card of claim 25, wherein the communicator and the terminal communicate via commu- 25 nication channels, the processor further configured to assign one of the communication channels to the identity when the processor allows the communication between the terminal and the integrated circuit card. 27. The integrated circuit card of claim 26, wherein the 30 processor is further configured to: assign a session key to said one of the communication channels, and use the session key when the processor and the terminal communicate via said one of the communication chan- 35 nels. 28. The integrated circuit card of claim 1, wherein the terminal has a card reader and the communicator comprises a contact for communicating with the card reader. 29. The integrated circuit card of claim 1, wherein the 40 terminal has a wireless communication device and the communicator a wireless transceiver for communicating with the wireless communication device. 30. The integrated circuit card of claim 1, wherein the terminal has a wireless communication device and the 45 communicator comprises a wireless transmitter for commu- nicating with the wireless communication device. 22 renumbering byte codes in a compiled format to equivalent byte codes in a format suitable for inter- pretation; and using a processor of the integrated circuit card to use the interpreter to interpret the application for execution; and using a communicator of the card when communicating between the processor and the terminal. 32. The method of claim 31, wherein the high level programming language format comprises a class file format. 33. The method of claim 31, wherein the processor comprises a microcontroller. 34. The method of claim 31, wherein at least a portion of the memory is located in the processor. 35. The method of claim 31, wherein the high level programming language format comprises a Java program- ming language format. 36. The method of claim 31, wherein the application has been processed from a second appli- cation having a plurality of program elements, at least one being a string of characters, further comprising: replacing the string of characters in the first application with an identifier. 37. The method of claim 36, wherein the identifier includes an integer. 38. The method of claim 31, further comprising: receiving a request from a requester to access an element of the card; after receipt of the request, interacting with the requester to authenticate an identity of the requester; and based on the identity, selectively granting access to the element. 39. The method of claim 38, wherein the requester com- prises the processor. 40. The method of claim 38, wherein the requester com- prises the terminal. 41. The method of claim 38, wherein the element com- prises the application stored in the memory, further com- prising: once access is allowed, using the application with the requester. 42. The method of claim 38, wherein the element com- prises another application stored in the memory. 43. The method of claim 38, wherein the element includes data stored in the memory. 44. The method of claim 38, wherein the element com- prises the communicator. 31. A method for use with an integrated circuit card and a terminal, comprising: 45. The method of claim 38, wherein the memory also 50 stores an access control list for the element, the access control list furnishing an indication of types of access to be granted to the identity, further comprising: storing an interpreter operable to interpret programs derived from programs written in a high level program- ming language and an application derived from a program written in a high level programming language format in a memory of the integrated circuit card wherein the application is derived from a program 55 written in a high level programming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form, the converting step including at least one step selected from a group consisting of recording all jumps and their destinations in the origi- nal byte codes; converting specific byte codes into equivalent generic byte codes or vice-versa; 60 modifying byte code operands from references using 65 identifying strings to references using unique iden- tifiers; and based on the access control list, using the processor to selectively grant specific types of access to the requester. 46. The method of claim 45, wherein the types of access include reading data. 47. The method of claim 45, wherein the types of access include writing data. 48. The method of claim 45, wherein the types of access include appending data. 49. The method of claim 45, wherein the types of access include creating data. 50. The method of claim 45, wherein the types of access include deleting data. 51. The method of claim 45, wherein the types of access including executing an application. Case: 13-1397 Document: 34 Page: 157 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 37 of 45 JA000100 US 6,308,317 B1 23 52. The method of claim 31, wherein the application is one of a plurality of applications stored in the memory, further comprising: receiving a request from a requester to access one of the applications stored in the memory; upon receipt of the request, determining whether said one of the plurality of applications complies with a prede- termined set of rules; and 24 60. The microcontroller of claim 59, wherein the terminal has a card reader and the communicator comprises a contact for communicating with the card reader. 61. The microcontroller of claim 59, wherein the terminal has a wireless communicator and a wireless transceiver for communicating with the wireless communication device. 62. The microcontroller of claim 59, wherein the terminal has a wireless communication device and the communicator based on the determining, selectively granting access to the said one of the plurality of applications. comprises a wireless transmitter for communicating with the 10 wireless communication device. 53. The method of claim 52, wherein the predetermined rules provide a guide for determining whether said one of the plurality of applications accesses a predetermined region of the memory. 54. The method of claim 52, further comprising: authenticating an indentity of the requester; and based on the indentity, granting access to said one of the plurality of applications. 15 55. The method of claim 31, further comprising: communicating with the terminal to authenticate an iden- 20 tity; determining if the identity has been authenticated; and based on the determining, selectively allowing commu- nication between the terminal and the integrated circuit card. 56. The method of claim 55, further comprising: communicating between the terminal and the processor via communication channels; and 25 assigning one of the communication channels to the 30 identity when the allowing allows communication between the card reader and the integrated circuit card. 57. The method of claim 56, further comprising: assigning a session key to said one of the communication channels; and using the session key when the processor and the terminal communicate via said one of the communication chan- nels. 58. A microcontroller comprising: a memory storing: a derivative application derived from an application having a class file format wherein the application is derived from an application having a class file format 35 40 63. The microcontroller of claim 58, wherein the class file format comprises a Java class file format. 64. An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the terminal; a memory storing: applications, each application derived from applica- tions having a high level programming language format, and an interpreter operable to interpret applications derived from applications having a high level programming language format wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form, the converting step including at least one step selected from a group consisting of recording all jumps and their destinations in the original byte codes; converting specific byte codes into equivalent generic byte codes or vice-versa; modifying byte code operands from references using identifying strings to references using unique identifiers; and renumbering byte codes in a compiled format to equivalent byte codes in a format suitable for interpretation; and a processor coupled to the memory, the processor con- figured to: a.) use the interpreter to interpret the applications for execution, b.) use the interpreter to create a firewall to isolate the applications from each other, and c.) use the communicator to communicate with the terminal. by first compiling the application having a class file format into a compiled form and then converting the 45 compiled form into a converted form, the converting step including at least one step selected from a group consisting of 65. A microcontroller having a set of resource constraints 50 and comprising: recording all jumps and their destinations in the origi- nal byte codes; converting specific byte codes into equivalent generic byte codes or vice-versa; modifying byte code operands from references using identifying strings to references using unique iden- tifiers; and renumbering byte codes in a compiled format to equivalent byte codes in a format suitable for interpretation, and 55 an interpreter configured to interpret applications derived from applications having a class file format; 60 and a processor coupled to the memory, the processor con- figured to use the interpreter to interpret the derivative application for execution. 59. The microcontroller of claim 58, further comprising: 65 a communicator configured to communicate with a ter- minal. a memory, and an interpreter loaded in memory and operable within the set of resource constraints, the micro controller having: at least one application loaded in the memory to be interpreted by the interpreter, wherein the at least one application is generated by a programming environ- ment comprising: a) a compiler for compiling application source pro- grams written in high level language source code form into a compiled form, and b) a converter for post processing the compiled form into a minimized form suitable for interpretation within the set of resource constraints by the interpreter, wherein the converter comprises means for translating from the byte codes in the compiled form to byte codes in a format suitable for interpre- tation by the interpreter by: Case: 13-1397 Document: 34 Page: 158 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 38 of 45 JA000101 US 6,308,317 B1 25 a) using at least one step in a process including the steps: a.1) recording all jumps and their destinations in the original byte codes; a.2) converting specific byte codes into equiva- lent generic byte codes or vice-versa; a.3) modifying byte code operands from refer- ences using identifying strings to references using unique identifiers; and aA) renumbering byte codes in the compiled 10 form to equivalent byte codes in the format suitable for interpretation; and b) relinking jumps for which destination address is effected by conversion step a.1, a.2, a.3, or aA. 66. The microcontroller of claim 65, wherein the com- 15 piled form includes attributes, and the converter comprises a means for including attributes required by the interpreter while not including the attributes not required by the inter- preter. 20 accepts as input the compiled form in the standard Java class file format and produces output in a form suitable for interpretation by the interpreter. 68. The microcontroller of claim 65 wherein the compiled 25 form includes associating an identifying string for objects, classes, fields, or methods, and the converter comprises a means for mapping such strings to unique identifiers. 69. The microcontroller of claim 68 wherein each unique identifier is an integer. 30 70. The microcontroller of claim 68 wherein the mapping of strings to unique identifiers is stored in a string to identifier map file. 71. The microcontroller of claim 65 where in the high level language supports a first set of features and a first set 35 of data types and the interpreter supports a subset of the first set of features and a subset of the first set of data types, and wherein the converter verifies that the compiled form only contains features in the subset of the first set of features and only contains data types in the subset of the first set of data 40 types. 72. The microcontroller of claim 65 wherein the applica- tion program is compiled into a compiled form for which resources required to execute or interpret the compiled form exceed those available on the microcontroller. 73. The microcontroller of claim 65 wherein the compiled 45 form is designed for portability on different computer plat- forms. 26 76. The microcontroller of claim 75 wherein the step of loading in a secure manner comprises the step of: verifying that the loading identity has permission to load applications onto the microcontroller. 77. The microcontroller of claim 75 wherein the step of loading in a secure manner comprises the step of: encrypting the application to be loaded using a loading key. 78. A method of programming a micro controller having a memory and a processor operating according to a set of resource constraints, the method comprising the steps of: inputting an application program in a first programming language; compiling the application program in the first program- ming language into a first intermediate code associated with the first programming language, wherein the first intermediate code being interpretable by at least one first intermediate code virtual machine; converting the first intermediate code into a second inter- mediate code, wherein the step of converting com- prises: at least one of the steps of: a) recording all jumps and their destinations in the original byte codes; b) converting specific byte codes into equivalent generic byte codes or vice-versa; c) modifying byte code operands from references using identifying strings to references using unique identifiers; and d) renumbering byte codes in a compiled format to equivalent byte codes in a format suitable for interpretation; and relinking jumps for which destination address is effected by conversion step a), b), c), or d); wherein the second intermediate code is interpretable within the set of resource constraints by at least one second intermediate code virtual machine; and loading the second intermediate code into the memory of the microcontroller. 79. The method of programming a micro controller of claim 78 wherein the step of converting further comprises: associating an identifying string for objects, classes, fields, or methods; and mapping such strings to unique identifiers. 80. The method of claim 79 wherein the step of mapping comprises the step of mapping strings to integers. 81. The method of claim 80 wherein the step of loading 74. The microcontroller of claim 65 wherein the inter- preter is further configured to determine, during an inter- pretation of an application, whether the application meets a security criteria selected from a set of rules containing at least one rule selected from the set: not allowing the application access to unauthorized por- tions of memory, 50 the second intermediate code into the memory of the micro- controller further comprises checking the second interme- diate code prior to loading the second intermediate code to verify that the second intermediate code meets a predefined integrity check and that loading is performed according to a not allowing the application access to unauthorized microcontroller resources, wherein the application is composed of byte codes and checking a plurality of byte codes at least once prior to execution to verify that execution of the byte codes does not violate a security constraint. 75. The microcontroller of claim 65 wherein at least one application program is generated by a process including the steps of: 55 security protocol. 82. The method of claim 81 wherein the security protocol requires that a particular identity must be validated to permit loading prior to the loading of the second intermediate code. 83. The method of claim 81 further characterized by 60 providing a decryption key and wherein the security proto- col requires that the second intermediate code is encrypted using a loading key corresponding to the decryption key. 84. An integrated circuit card for use with a terminal, comprising: prior to loading the application verifying that the appli - 65 cation does not violate any security constraints; and loading the application in a secure manner. a communicator configured terminal; a memory storing: to communicate with the Case: 13-1397 Document: 34 Page: 159 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 39 of 45 JA000102 US 6,308,317 B1 27 an application derived from a program written in a high level programming language format wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form, the converting step including the steps of: modifying byte code operands from references using identifying strings to references using unique identifiers; 10 recording all jumps and their destinations in the original byte codes; converting specific byte codes into equivalent generic byte codes or vice-versa; and renumbering byte codes in a compiled format to 15 equivalent byte codes in a format suitable for interpretation; and an interpreter operable to interpret such an applica- tion derived from a program written in a high level programming language format; and 20 a processor coupled to the memory, the processor con- figured to use the interpreter to interpret the application for execution and to use the communicator to commu- nicate with the terminal. 85. A method for use with an integrated circuit card and 25 a terminal, comprising: storing an interpreter operable to interpret programs derived from programs written in a high level program- 30 format in a memory of the integrated circuit card wherein the application is derived from a program written in a high level programming language format 35 form, the converting step including: modifying byte code operands from references using identifying strings to references using unique iden- tifiers; recording all jumps and their destinations in the origi _ 40 nal byte codes; converting specific byte codes into equivalent generic byte codes or vice-versa; and i: 45 pretation; using a processor of the integrated circuit card to use the interpreter to interpret the application for execution; and using a communicator of the card when communicating between the processor and the terminal. 86. An integrated circuit card for use with a terminal, comprising: 50 a communicator configured to communicate with the 55 terminal; 28 a memory storing: applications, each application derived from applica- tions having a high level programming language format, and an interpreter operable to interpret applications derived from applications having a high level programming language format wherein the appli- cation is derived from a program written in a high level programming language format by first com- piling the program into a compiled form and then converting the compiled form into a converted form, the converting step including the steps of: modifying byte code operands from references using identifying strings to references using unique identifiers; recording all jumps and their destinations in the original byte codes; converting specific byte codes into equivalent generic byte codes or vice-versa; and renumbering byte codes in a compiled format to equivalent byte codes in a format suitable for interpretation; and a processor coupled to the memory, the processor con- figured to: a.) use the interpreter to interpret the applications for execution, b.) use the interpreter to create a firewall to isolate the applications from each other, and c.) use the communicator to communicate with the terminal. 87. A microcontroller comprising: a memory storing: a derivative application derived from an application hav- ing a class file format wherein the application is derived from an application having a class file format by first compiling the application having a class file format into a compiled form and then converting the compiled form into a converted form, the converting step includ- ing: recording all jumps and their destinations in the origi- nal byte codes; converting specific byte codes into equivalent generic byte codes or vice-versa; and renumbering byte codes in a compiled format to equivalent byte codes in a format suitable for interpretation, and an interpreter configured to interpret applications derived from applications having a class file format; and a processor coupled to the memory, the processor con- figured to use the interpreter to interpret the derivative application for execution. * * * * * Case: 13-1397 Document: 34 Page: 160 Filed: 07/09/2013 (12) EX PARTE REEXAMINATION CERTIFICATE (6546th) United States Patent (10) Number: US 6,308,317 C1 Wilkinson et al. (45) Certificate Issued: Dec. 2,2008 (54) USING A HIGH LEVEL PROGRAMMING 5,457,799 A 1011995 Srivastava LANGUAGE WITH A MICROCONTROLLER 5,469,572 A 1111995 Taylor 5,590,331 A 1211996 Lewis et al. (75) Inventors: Timothy J. Wilkinson, London (GB); Scott B. Guthery, Belmont, MA (US); Ksheerabdhi Krishna, Cedar Park, TX (US); Michael A. Montgomery, Cedar Park, Tx (US) (73) Assignee: Schlumberger Technologies, Inc., Austin, TX (US) Reexamination Request: No. 901008,178, Sep. 29, 2006 Reexamination Certificate for: Patent No.: 6,308,317 Issued: Oct. 23,2001 Appl. No.: 08/957,512 Filed: Oct. 24,1997 Related U.S. Application Data (60) Provisional application No. 601029.057, filed on Oct. 25, 1996. (51) I n t C1. W6F 9/46 (2006.01) W6 F 9 / 4 4 (2006.01) W6F 9/455 (2006.01) W6F 9/45 (2006.01) W 7F 7/10 (2006.01) H04L 29/06 (2006.01) ......................... (52) U.S. C1. 7171139; 7171141; 7171146 .................. (58) Weld of Classification Search 7171139, 71715, 141, 146 See application file for complete search history. (56) References Cited U.S. PATENT DOCUMENTS 5,367,685 A 1111994 Gosling 5,668,999 A 911997 Gosling 5,915,226 A 611999 Martineau 5,923,884 A 711999 Peyret et al. OTHER PUBLICATIONS "Java Intermediate Bytecodes", ACM SIGPLAN Workshop, IR '95, J. Gosling, 1995 ACM.* W.M. McKeeman, Peephole Optimization, Communications of the ACM, vol. 8, No. 7 (Jul. 1965), pp. 4 4 3 4 . Leon Presser and John R. White, Linkers and Loaders, Com- puting Surveys, vol. 4, No. 3 (Sep. 1972), pp. 15 1. Jerome H. Saltzer and Michael D. Schroeder, The Protection of Information in Computer Systems, Communications of the ACM, vol. 17, No. 7 (Jul. 1974), Glossary, Section 1I.C. W.M. Waite, Assembly and Linkage, in EL. Bauer and J. Eickel, eds., Compiler Construction: An Advanced Course (2d ed. 1976), pp. 339-342 , Springer-Verlag, Berlin. W.M. Waite, Optimization, in EL. Bauer and J. Eickel, eds., Compiler Construction: An Advanced Course (2d ed. 1976), pp. 551-600, Springer-Verlag, Berlin. P.M. Lewis 11, D.J. Rosenkrantz, R.E. Steams, Compiler Design Theory (1976), pp. 559-568, Addison-Wesley, Reading. B.W. Kernighan and M.D. McIlroy, UNM Programmer's Manual, Bell Telephone laboratories, Inc., Murray Hill (7th ed., 1979), Sections LD(l), MEM(4), and A.OUT(5). (Continued) Primary Examiner-Fred Fems (57) ABSTRACT An integrated circuit card is used with a terminal. The inte- grated circuit card includes a memory that stores an inter- preter and an application that has a high level programming language format. A processor of the card is configured to use the interpreter to interpret the application for execution and to use a communicator of the card to communicate with the terminal. Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 40 of 45 JA000103 111111 1111111111111111111111111111111111111111111111111111111111111 US006308317C 1 (12) EX PARTE REEXAMINATION CERTIFICATE (6546th) United States Patent Wilkinson et al. (54) USING A IDGH LEVEL PROGRAMMING LANGUAGE WITH A MICRO CONTROLLER (75) Inventors: Timothy J. Wilkinson, London (GB); Scott B. Guthery, Belmont, MA (US); Ksheerabdhi Krishna, Cedar Park, TX (US); Michael A. Montgomery, Cedar Park, TX (US) (73) Assignee: Schlumberger Technologies, Inc., Austin, TX (US) Reexamination Request: No. 90/008,178, Sep. 29, 2006 Reexamination Certificate for: Patent No.: 6,308,317 Issued: Oct. 23, 2001 Appl. No.: 081957,512 Filed: Oct. 24, 1997 Related U.S. Application Data (60) Provisional application No. 60/029,057, filed on Oct. 25, 1996. (51) Int. CI. G06F 9146 G06F91445 G06F91455 G06F9145 G07F 7110 H04L29106 (2006.01) (2006.01) (2006.01) (2006.01) (2006.01) (2006.01) (52) U.S. Cl ......................... 7171139; 717/141; 7171146 (58) Field of Classification Search .................. 717/139, (56) 717/5, 141, 146 See application file for complete search history. References Cited U.S. PATENT DOCUMENTS 5,367,685 A 1111994 Gosling (10) Number: US 6,308,317 Cl (45) Certificate Issued: Dec. 2, 2008 5,457,799 A 5,469,572 A 5,590,331 A 5,668,999 A 5,915,226 A 5,923,884 A 1011995 Srivastava 1111995 Taylor 1211996 Lewis et aI. 911997 Gosling 611999 Martineau 7/1999 Peyret et aI. aTHER PUBUCATIONS "Java Intermediate Bytecodes", ACM SIGPLAN Workshop, IR '95, J. Gosling, 1995 ACM.* W.M. McKeeman, Peephole Optimization, Communications of the ACM, vol. 8, No.7 (Jul. 1965), pp. 443-444. Leon Presser and John R. White, Linkers and Loaders, Com- puting Surveys, vol. 4, No.3 (Sep. 1972), pp. 151. Jerome H. Saltzer and Michael D. Schroeder, The Protection of Information in Computer Systems, Communications of the ACM, vol. 17, No.7 (Jul. 1974), Glossary, Section II.C. W.M. Waite, Assembly and Linkage, in EL. Bauer and 1. Eickel, eds., Compiler Construction: An Advanced Course (2d ed. 1976), pp. 339-342, Springer-Verlag, Berlin. W.M. Waite, Optimization, in EL. Bauer and J. Eickel, eds., Compiler Construction: An Advanced Course (2d ed. 1976), pp. 551-600, Springer-Verlag, Berlin. P.M. Lewis II, 0.1. Rosenkrantz, R.E. Stearns, Compiler Design Theory (1976), pp. 559-568, Addison-Wesley, Reading. B.W. Kemighan and M.D. McIlroy, UNIX Programmer's Manual, Bell Telephone laboratories, Inc., Murray Hill (7th ed., 1979), Sections LD(I), MEM(4), andA.OUT(5). (Continued) Primary Examiner-Fred Ferris (57) ABSTRACT An integrated circuit card is used with a terminal. The inte- grated circuit card includes a memory that stores an inter- preter and an application that has a high level programming language format. A processor of the card is configured to use the interpreter to interpret the application for execution and to use a communicator of the card to communicate with the terminal. Case: 13-1397 Document: 34 Page: 161 Filed: 07/09/2013 US 6,308,317 C1 Page 2 OTHER PUBLICATTONS A.S. Tanenbaum et al., Using Peephole Optimization on Intermediate Code, ACM Transactions on Programming Languages and Systems, vol. 4, No. 1 (Jan. 1982), pp. 26-35. Andrew S. Tanenbaum, Structured Computer Organization (3d ed. 1990), pp. 397428, Prentice Hall, Englewood Cliffs. ISOIIEC standard 7816-4 (1st ed. 1995). Patrice Peyret, Application-Enabling Card Systems with Plug-and-Play Applets, 1996 Smart Card Convention, Quality Marketing, Peterborough, U.K. (Feb. 1996), pp. 51-71. Tim Lindholm and Frank Yellin, The Java Virtual Machine Specification, (1st ed., Sep. 1996), Chapters 2-16, 9, Add- ison-Wesley, Reading. Leon Presser and John R. White, Linkers and Loaders, Com- puting Surveys, vol. 4, No. 3 (Sep. 1972), p. 151. W.M. Waite, Assembly and Linkage, In EL. Bauer and J. Eickel, eds., Compiler Construction: An Advanced Course (26 ed. 1976), pp. 339-342. P.M. Lewis 11, D.J. Rosenkrantz, R.E. Steams, Compiler Design Theory (1976), pp. 559-568. B.W. Kernighan and M.D. McIlroy, UNIX Programmer's Manual, Bell Telephone Laboratories, Inc., Murray Hill (7th ed., 1979), Section LD(l), MEM(4), and A.OUT(5). Andrew S. Tanenbaum et al., Using Peephole Optimization on Intermediate Code, ACM Transactions on Programming Languages and Systems, vol. 4, No. 1 (Jan. 1982), pp. 26-35. Andrew S. Tanenbaum, Structured Computer Organization (3d ed. 1990), pp. 397-428. Patrice Peyret, Application-Enabling Card Systems with Plug-and-Play Applets, 1996 Smart Card Convention, Peterborough, UK (Feb. 1996), pp. 5 1-71. Tim Lindholm and Frank Yellin, The Java Virtual Machine Specification, Addison-Wesley, (1st ed., Sep. 1996), Chap- ters 1, 2, 3 and 9. * cited by examiner Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 41 of 45 JA000104 US 6,308,317 Cl Page 2 OTHER PUBLICATIONS A.S. Tanenbaum et al., Using Peephole Optimization on Intermediate Code, ACM Transactions on Programming Languages and Systems, vol. 4, No. 1 (Jan. 1982), pp. 26-35. Andrew S. Tanenbaum, Structured Computer Organization (3d ed. 1990), pp. 397-428, Prentice Hall, Englewood Cliffs. ISOIlEC standard 7816-4 (1st ed. 1995). Patrice Peyret, Application-Enabling Card Systems with Plug-and-Play Applets, 1996 Smart Card Convention, Quality Marketing, Peterborough, U.K. (Feb. 1996), pp. 51-71. Tim Lindholm and Frank Yellin, The Java Virtual Machine Specification, (1st ed., Sep. 1996), Chapters 2-16, 9, Add- ison-Wesley, Reading. Leon Presser and John R. White, Linkers and Loaders, Com- puting Surveys, vol. 4, No.3 (Sep. 1972), p. 151. W.M. Waite, Assembly and Linkage, In F.L. Bauer and J. Eickel, eds., Compiler Construction: An Advanced Course (2d ed. 1976), pp. 339-342. P.M. Lewis II, D.J. Rosenkrantz, R.E. Stearns, Compiler Design Theory (1976), pp. 559-568. B.W. Kernighan and M.D. McIlroy, UNIX Programmer's Manual, Bell Telephone Laboratories, Inc., Murray Hill (7th ed., 1979), Section LD(I), MEM(4), andA.OUT(5). Andrew S. Tanenbaum et al., Using Peephole Optimization on Intermediate Code, ACM Transactions on Programming Languages and Systems, vol. 4, No. 1 (Jan. 1982), pp. 26-35. Andrew S. Tanenbaum, Structured Computer Organization (3d ed. 1990), pp. 397-428. Patrice Peyret, Application-Enabling Card Systems with Plug-and-Play Applets, 1996 Smart Card Convention, Peterborough, UK (Feb. 1996), pp. 51-71. Tim Lindholm and Frank Yellin, The Java Virtual Machine Specification, Addison-Wesley, (1st ed., Sep. 1996), Chap- ters 1,2,3 and 9. * cited by examiner Case: 13-1397 Document: 34 Page: 162 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 42 of 45 JA000105 US 6,308,317 C1 1 EX PARTE REEXAMINATION CERTIFICATE ISSUED UNDER 35 U.S.C. 307 mE PATENT IS HEREBY AMENDED AS INDICATED BELOW. 5 Matter enclosed in heavy brackets [ ] appeared in the patent, but has been deleted and is no longer a part of the patent; matter printed in italics indicates additions made 10 to the patent. AS A RESULT OF REEXAMINATION, IT HAS BEEN DETERMINED THAT: Claims 1, 31, 58, 64, 65, 78 and 84-87 are determined to be patentable as amended. 15 Claims 2-30, 32-57,59-(;3, 66-77 and 79-83, dependent 20 on an amended claim, are determined to be patentable. New claims 88-94 are added and determined to be patent- able. 1. An integrated circuit card for use with a terminal, com- 25 prising: a communicator configured to communicate with the ter- minal; a memory storing: 30 an applicaton derived from a program written in a high level programming language format wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form and 35 then converting the compiled form into a converted form, the converting step [including at least one step selected from a group consisting of] comprising: recording all jumps and their destinations in the original byte codes; 40 performing a conversion operation selectedfrom the group: converting specific byte codes into equivalent generic byte codes [or vice-versa]; modifying byte code operands from references using 45 identifying strings to references using unique identifiers; and renumbering byte codes in [a compiled format] the compiled form to equivalent byte codes in [a for- mat suitable for interpretation] an instruction set 50 supported by an interpreter on the integrated cir- cuit card; and relinking jumps for which the destination address is affected by the conversion operation; and an interpreter operable to interpret such an application 55 derived from a program written in a high level pro- gramming language format; and a processor coupled to the memory, the processor config- ured to use the interpreter to interpret the application for execution and to use the communicator to commu- 60 nicate with the terminal. 31. A method for use with an integrated circuit card and a terminal comprising: storing an interpreter operable to interpret programs derived from programs written in a high level program- 65 ming language and an application derived from a pro- gram written in a high level programming language for- 2 mat in a memory of the integrated circuit card wherein the application is derived from a program written in a high level programming language format by first com- piling the program into a compiled form and then con- verting the compiled form into a converted form, the converting step [including at least one step selected from a group consisting of] comprising: recording all jumps and their destinations in the origi- nal byte codes; performing a conversion operation selected from the group: converting specific byte codes into equivalent generic byte codes [or vice-versa]; modifying byte code operands from references using identifying strings to references using unique identi- fiers; and renumbering byte codes in [a compiled format] the compiled form to equivalent byte codes in [a format suitable for interpretation] an instruction set sup- ported by an interpreter on the integrated circuit card; and relinking jumps for which the destination address is affected by the conversion operation; and using a processor of the integrated circuit card to use the interpreter to interpret the application for execution; and using a communicator of the card when communicating between the processor and the terminal. 58. A microcontroller comprising: a memory storing: a derivative application derived from an application having a class file format wherein the application is derived from an application having a class file format by first compiling the application having a class file format into a compiled form and then converting the compiled form into a converted form, the converting step [including at least one step selected from a group consisting of] comprising: recording all jumps and their destinations in the origi- nal byte codes; performing a conversion operation selected from the group: converting specific byte codes into equivalent generic byte codes [or vice-versa]; modifying byte code operands from references using identifying strings to references using unique identi- fiers; and renumbering byte codes in [a compiled format] the compiled form to equivalent byte codes in [a format suitable for interpretation] an instruction set sup- ported by an interpreter on the integrated circuit card,and relinking jumps for which the destination address is affected by the conversion operation; and an interpreter configured to interpret applications derived from applications having a class file format; and a processor coupled to the memory, the processor config- ured to use the interpreter to interpret the derivative application for execution. 64. An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the ter- minal; a memory storing: applications, each application derived from applica- tions having a high level programming language format, and Case: 13-1397 Document: 34 Page: 163 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 43 of 45 JA000106 US 6,308,317 Cl 3 an interpreter operable to interpret applications derived from applications having [high lever-programming language format wherein [the] each application is derived from a program written in a high level pro- gramming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form, the con- verting step [including at least one step selected from a group consisting of] comprising: recording all jumps and their destinations in the 10 original byte codes; performing a conversion operation selectedfrom the group: converting specific byte codes into equivalent generic byte codes [or vice-versa]; modifying byte code operands from references using 15 identifying strings to references using unique identifiers; and renumbering byte codes in [a compiled format] the compiled form to equivalent byte codes in [a for- mat suitable for interpretation] an instruction set 20 supported by an interpreter on the integrated eir- cuit card; and relinking jumps for which the destination address is affected by the conversion operation; and a processor coupled to the memory, the processor config- 25 ured to: a.) use the interpreter to interpret the applications for execution, b.) use the interpreter to create a firewall to isolate the applications from each other, and 30 c.) use the communicator to communicate with the ter- minal. 65. A microcontroller having a set of resource constraints and comprising: a memory, and 35 an interpreter loaded in memory and operable within the set of resource constraints, the microcontroller having: at least one application loaded in the memory to be interpreted by the interpreter, wherein the at least one application is generated by a programmable environ- 40 ment comprising: a) a compiler for compiling application source pro- grams written in high level language source code form into a compiled form, and b) a converter for post processing the compiled form 45 into a minimized form suitable for interpretation within the set of resource constraints by the interpreter, whrein the converter comprises means for translating from the byte codes in the compiled form to byte codes in a format suitable for interpreta- 50 tion by the interpreter by: [a) using at least one step in a process including the steps: a] b.l) recording all jumps and their destina- tions in the original byte codes; b.2)performing a conversion operation selectedfrom 55 the group: [a.2] b.2.1) converting specific byte codes into equivalent generic byte codes[or vice-versa]; [a.3] b.2.2) modifying byte code operands from references using identifying strings to refer- 60 ences using unique identifiers; and [a.4] b.2.3.) renumbering byte codes in [the com- piled format] the compiled form to equivalent byte codes in [a format suitable for interpretation]an instruction set supported by 65 an interpreter on the integrated eircuit card; and 4 b.3) relinking jumps for which the destination address is [effected] affected by the conversion [step a.l, a.2, a. 3, or a.4] operation. 78. A method of programming a microcontroller having a memory and a processor operating according to a set of resource constraints, the method comprising the steps of: inputting an application program in a first programming language; compiling the application program in the first program- ming language into a first intermediate code associated with the first programming language, wherein the first intermediate code being interpretable by at least one first intermediate code virtual machine; converting the first intermediate code into a second inter- mediate code, wherein the step of converting com- prises: [at least one of the steps of: a)] recording all jumps and their destinations in the original byte codes; performing a conversion operation selected from the group: [b)] converting specific byte codes into equivalent generic byte codes [or vice-versa]; [c)] modifying byte code operands from references using identifying strings to references using unique identifiers; and [d)] renumbering byte codes in [a compiled format] the compiled form to equivalent byte codes in [a format suitable for interpretation] an instruction set supported by an interpreter on the integrated circuit card; and relinking jumps for which the destination address is [effected] affected by the conversion [step a), b), c), or d)] operation; wherein the second intermediate code is interpretable within the set of resource constraints by at least one second intermediate code virtual machine; and loading the second intermediate code into the memory of the microcontroller. 84. An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the ter- minal; a memory storing: an application derived from a program written in a high level programming language format wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form, the converting step including the steps of: recording all jumps and their destinations in the original byte codes; modifying byte code operands from references using identifying strings to references using unique identifiers; [recording all jumps and their destinations in the original byte codes;] converting specific byte codes into equivalent generic byte codes [or vice-versa]; [and) renumbering byte codes in [a compiled format] the compiledform to equivalent byte codes in [a format suitable for interpretation] an instruction set sup- ported by an interpreter on the integrated circuit card; and adjusting jump destinations that are affected by at least one of the steps of modifying byte code Case: 13-1397 Document: 34 Page: 164 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 44 of 45 JA000107 US 6,308,317 Cl 5 operands, converting specific byte codes into equivalent generic byte codes, or renumbering byte codes; and an interpreter operable to interpret such an applica- tion derived from a program written in a high level 5 programming language format; and a processor coupled to the memory, the processor config- ured to use the interpreter to interpret the application for execution and to use the communicator to commu- nicate with the terminal. 10 85. A method for use with an integrated circuit card and a terminal, comprising: storing an interpreter operable to interpret programs derived from programs written in a high level program- ming language and an application derived from a pro- 15 gram written in a high level programming language for- mat in a memory of the integrated circuit card wherein the application is derived from a program written in a high level programming language format by first com- piling the program into a compiled form and then con- 20 verting the compiled form into a converted form, the convcrting step including: recording all jumps and their destinations in the origi- nal byte codes; modifying byte code operands from references using 25 identifying strings to references using unique identi- fiers; [recording all jumps and their destinations in the origi- nal byte codes;] converting specific byte codes into equivalent generic 30 byte codes [or vice-versa]; [and] renumbering byte codes in [a compiled format] the compiledform to equivalent byte codes in [a format suitable for interpretation] an instruction set sup- ported by an interpreter on the integrated circuit 35 card; and adjusting jump destinations that are affected by at least one of the steps of modifying byte code operands, converting specific byte codes into equivalent generic byte codes, or renumbering byte codes; and 40 using a processor of the integrated circuit card to use the interpreter to interpret the application for execution; and using a communicator of the card when communicating 45 between the processor and the terminal. 86. An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the ter- minal; 50 a memory storing: applications, each application derived from applica- tions having a high level programming language format, and an interpreter operable to interpret applications 55 derived from applications having a high level pro- gramming language format wherein the applica- tion is derived from a program written in a high level programming language format by first com- piling the program into a compiled form and then 60 converting the compiled form into a converted form, the converting step including the steps of: recording all jumps and their destinations in the original byte codes; modifying byte code operands from references 65 using identifying strings to references using unique identifiers; 6 [recording all jumps and their destinations in the original byte codes;] converting specific byte codes into equivalent generic byte codes [or vice-versa]; [and] renumbering byte codes in [a compiled format] the compiled form to equivalent byte codes in [a format suitable for interpretation] an instruction set supported by an interpreter on the integrated circuit card; and adjusting jump destinations that are affected by at least one of the steps of modifying byte code operands, converting specific byte codes into equivalent generic byte codes or vice versa, and renumbering byte codes; and a processor coupled to the memory, the processor config- ured to: a.) use the interpreter to interpret the applications for execution, b.) use the interpreter to create a firewall to isolate the applications from each other, and c.) use the communicator to communicate with the ter- minal. 87. A microcontroller comprising: a memory storing: a derivative application derived from an application hav- ing a class file format wherein the application is derived from an application having a class format by first com- piling the application having a class file format into a compiled form and then converting the compiled form into a converted form, the converting step including: recording all jumps and their destinations in the origi- nal byte codes; converting specific byte codes into equivalent generic byte codes [or vice-versa]; [and] renumbering byte codes in [a compiled format] the compiled form to equivalent byte codes in [a format suitable for interpretation,] an instruction set sup- ported by an interpreter on the integrated circuit card; and adjusting jump destinations that are affected by at least one of the steps of converting specific byte codes into equivalent generic byte codes and renumbering byte codes; and an interpreter configured to interpret applications derived from applications having a class file format; and a processor coupled to the memory, the processor config- ured to use the interpreter to interpret the derivative application for execution. 88. A method of programming a microcontroller having a memory and a processor operating according to a set of resource constraints, the method comprising the steps of" inputting an application program in a first programming language; compiling the application program in the first program- ming language into a first intermediate code associated with the first programming language, wherein the first intermediate code being interpretable by at least one first intermediate code virtual machine; converting the first intermediate code into a second inter- mediate code, wherein the step of converting com- prises: recording all jumps and their destinations in the origi- nal byte codes; modifying byte code operands from references using identifying strings to references using unique identi- fiers; and Case: 13-1397 Document: 34 Page: 165 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-1 Filed 10/22/10 Page 45 of 45 JA000108 US 6,308,317 C1 7 renumbering byte codes in the compiled form to equivalent byte codes in an instruction set sup- ported by an interpreter on the integrated circuit; and relinking jumps for which the destination address is affected by the conversion operation; wherein the second intermediate code is interpretable within the set of resource constraints by at least one second intermediate code virtual machine; and loading the second intermediate code into the memory of 10 the microcontroller. 89. The method of programming a microcontroller of claim 88 wherein the step of converting further comprises: associating an identifying string for objects. classes, fields. or methods; and mapping such strings to unique 15 identifiers. 90. The method of claim 89 wherein the step of mapping comprises the step of mapping strings to integers. 91. A method of programming a microcontroller having a memory and a processor operating according to a set of 20 resource constraints, the method comprising the steps of inputting an application program in a first programming language; compiling the application program in the first program- 25 ming language into a first intermediate code associated with the first programming language, wherein the first intermediate code being interpretable by at least one first intermediate code virtual machine; converting the first intermediate code into a second inter- 30 mediate code, wherein the step of converting com- prises: 8 relinking jumps for which the destination address is affected by the conversion operation; wherein the second intermediate code is interpretable within the set of resource constraints by at least one second intermediate code virtual machine; and loading the second intermediate code into the memory of the microcontroller. 93. An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the ter- minal; a memory storing: an application derived from a program written in a high level programming language format wherein the application is derivedfrom a program written in a high level programming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form, the converting step comprising: recording all jumps and their destinations in the original byte codes; performing a conversion operation including modi- fying byte code operands from references using identifying strings to references using unique identifiers; and relinking jumps for which the destination address is affected by the conversion operation; and an interpreter operable to interpret such an application derived from a program written in a high level pro- gramming language format; and a processor coupled to the memory, the processor config- ured to use the interpreter to interpret the application for execution and to use the communicator to communi- cate with the terminal. recording all jumps and their destinations in the origi- nal byte codes; performing a conversion operation comprising; modifying specific byte codes into equivalent generic byte codes; and 94. An integrated circuit card for use with a terminal, 35 comprising: relinking jumps for which the destination address is affected by the conversion operation; wherein the second intermediate code is interpretable 40 within the set of resource constraints by at least one second intermediate code virtual machine; and loading the second intermediate code into the memory of the microcontroller. 92. A method of programming a microcontroller having a 45 memory and a processor operating according to a set of resource constraints. the method comprising the setps of inputting an application program in a first programming language; compiling an application program in the first program- 50 ming language into afirst intermediate code associated with the first programming language, wherein the first intermediate code being interpretable by at least one first intermediate code virtual machine; 55 converting the first intermediate code into a second inter- mediate code. wherein the step of converting com- prises: recording all jumps and their destinations in the origi- nal byte codes; performing a conversion operation comprising: renumbering byte codes in the compiled form to equivalent byte codes in an instruction set sup- ported by an interpreter on the integrated circuit card; and 60 a communicator configured to communicate with the ter- minal; a memory storing: an application derived from a program written in a high level programming language format wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form and then converting the compiled form into a converted form, the converting step comprising: recording all jumps and their destinations in the original byte codes; performing a conversion operation including: converting specific byte codes into equivalent generic byte codes; and renumbering byte codes in the compiled form to equivalent byte codes in an instruction set sup- ported by an interpreter on the integrated cir- cuit card; and relinking jumps for which the destination address is affected by the conversion operation; and an interpreter operable to interpret such an application derived from a program written in a high level pro- gramming language format; and a processor coupled to the memory, the processor config- ured to use the interpreter to interpret the application for execution and to use the communicator to communi- cate with the terminal. * * * * * Case: 13-1397 Document: 34 Page: 166 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 1 of 36 JA000109 (12) United States Patent Wilkinson et al. (54) USING A HIGH LEVEL PROGRAMMING LANGUAGE WITH A MICROCONTROLLER (75) Inventors: Timothy J. Wilkinson, London (GB); Scott B. Guthery, Belmont, MA (US); Ksheerabdhi Krishna, Cedar Park, TX (US); Michael A. Montgomery, Cedar Park, TX (US) (73) Assignee: Axalto SA, Montrouge (FR) ( *) Notice: Subject to any disclaimer, the term of this patent is extended or adjusted under 35 U.S.c. 154(b) by 643 days. (21) Appl. No.: 10/037,390 (22) Filed: Oct. 23, 2001 (65) Prior Publication Data US 2003/0023954 Al Jan. 30, 2003 (51) Int. Cl. G06F 9/45 (2006.01) (52) U.S. Cl. ...................................................... 717/139 (58) Field of Classification Search ................ 717/139, (56) 7171118; 235/492,441 See application file for complete search history. References Cited U.S. PATENT DOCUMENTS 5,500,517 A * 311996 Cagliostro .................. 235/486 YES Patent Lens enabling INNOVATION 111111111111111111111111111111111111111111111111111111111111111111111111111 FR JP US007117485B2 (10) Patent No.: US 7,117,485 B2 Oct. 3, 2006 (45) Date of Patent: 5,663,553 A * 5,679,945 A * 5,748,964 A * 5,915,226 A * 5,923,884 A * 6,223,984 Bl * 6,308,317 Bl * 9/1997 Aucsmith ................... 235/492 10/1997 Renner et al. .... ... ....... 235/492 5/1998 Gosling ...................... 717/126 6/1999 Martineau ................... 455/558 7/1999 Peyret et al. ............... 717/167 5/2001 Renner et al. .............. 235/380 10/2001 Wilkinson et al. .......... 717/139 FOREIGN PATENT DOCUMENTS 2667 171 61-204741 A 9/1990 9/1986 OTHER PUBLICATIONS Rodley, J., Writing Java Applets, Apr. 15, 1996, Corolis Group, p. 3-19.* Fryer, Microsoft Computer Dictionary, 1997, Microsoft Press, 3,d Ed., p. 498. * * cited by examiner Primary Examiner-John Chavis (74) Attorney, Agent, or Firm-Pehr Jansson (57) ABSTRACT An integrated circuit card is used with a terminal. The integrated circuit card includes a memory that stores an interpreter and an application that has a high level program- ming language format. A processor of the card is configured to use the interpreter to interpret the application for execu- tion and to use a communicator of the card to communicate with the terminal. 44 Claims, 23 Drawing Sheets 164 Check VM stack state (Pass 3 security checks) Execute byte code Set VM stack state Retire the byte code Case: 13-1397 Document: 34 Page: 167 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 2 of 36 JA000110 u.s. Patent 16\ Oct. 3, 2006 Sheet 1 of 23 Integrated Circuit Card Card Java Virtual Machine (Card JVM) 12B\ Communicator 12b" Terminal Communicator Terminal FIGURE 1 Patent Lens enabling INNOVATION US 7,117,485 B2 Case: 13-1397 Document: 34 Page: 168 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 3 of 36 JA000111 u.s. Patent Card Class File (contains Classes A, B, and C) Oct. 3, 2006 Sheet 2 of 23 Card Loader FIGURE 2 28 Patent Lens enabling INNOVATION US 7,117,485 B2 22 Java Application Development Environment Card Class File Converter Integrated Circuit Card 26 10 Case: 13-1397 Document: 34 Page: 169 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 4 of 36 JA000112 u.s. Patent Oct. 3, 2006 Card Class File (contains Classes A, B, and C) 26 Sheet 3 of 23 Card Class File Converter FIGURE 3 Patent Lens enabling INNOVATION US 7,117,485 B2 String To 10 Input Map String To 10 Output Map Case: 13-1397 Document: 34 Page: 170 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 5 of 36 JA000113 u.s. Patent Oct. 3, 2006 ADolication Class Files
Class File Information 4 1
Class File Information 42 Class Constant Pool - Contains all the strings corresponding to Fields methods and Class names referred to in the Java program 43 t\ Class, field, Interface and Method Information 44 i\ Attribute Information ,...Source File Attribute I+-Constant Value Attribute Code Attribute \+-Exceptions Attribute \+-Line Number Table Attribute I+-Local Variable Table Attribute Vendor Attributes .'\.. 24a Patent Lens enabling INNOVATION Sheet 4 of 23 US 7,117,485 B2 r 24 Card Class File ;2 7 46 Card Class File Information Optimized Card Class Ir 47 Constant Pool where each string is replaced by an 10 Card Class, Card Field, Card Interface and Card Ir 48 Method Information Card Attribute Information lr 49 .-- f-+ Code Attribute (optionally translated) II 24b,c r 45 Eliminated I FIGURE 4 Case: 13-1397 Document: 34 Page: 171 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 6 of 36 JA000114 Patent Lens enabling INNOVATION u.s. Patent Oct. 3, 2006 Sheet 5 of 23 US 7,117,485 B2 51a Select A Crassfile 51b Compact Constant Pool 51c Check For Unsupported Features Discard Unnecessary Parts Modify The byte codes 56 Gather All Constant Pool Entries and Modified byte cod es Generate Card Class File and String to 10 map (if required) 57 27 Flag Errors and Stop Conversion FIGURE 5 Case: 13-1397 Document: 34 Page: 172 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 7 of 36 JA000115 Patent Lens enabling INNOVATION u.s. Patent Oct. 3, 2006 Sheet 6 of 23 US 7,117,485 B2 PASS 1: List all jumps and their destinations 62 NO PASS 2: Convert specific byte codes into generic byte codes PASS 3: Relink References 65 NO YES PASS 4: Modify Java byte codes to Card JVM byte codes PASS 5: Readjust Jumps FIGURE 6 Case: 13-1397 Document: 34 Page: 173 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 8 of 36 JA000116 u.s. Patent 0: 1 : 2: 3: 4: / I LOAD_O I LOAD_1 IFNE 1: BIPUSH 5 Oct. 3, 2006 Sheet 7 of 23 70 --- --- --- --- FIGURE 7 --- 0: 1 : --- 2: - - - - _ 3: -- 4: 5: 6: Patent Lens enabling INNOVATION US 7,117,485 B2 / 72 ILOAD 0 I LOAD 1 IFNE 2: BIPUSH 5 Case: 13-1397 Document: 34 Page: 174 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 9 of 36 JA000117 Patent Lens enabling INNOVATION u.s. Patent Oct. 3, 2006 Sheet 8 of 23 US 7,117,485 B2 ~ I (J) :::> co a. ~ OJ ,.Ill- o 0 o 0 o 0 co w 0:: :: 0 (!) - 0 u. c... +-' ..-.. ~ X (1) '-' "'0 CO "')
c: CO ... en c 0 C 0 --I 0- "-" LO M I-. (1) 0) Q) ... t) Q) - t+= C en - en m - () o 0 o 0 o 0 Case: 13-1397 Document: 34 Page: 175 Filed: 07/09/2013 h t t p : / / w w w . p a t e n t l e n s . n e t / C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 2
F i l e d
1 0 / 2 2 / 1 0
P a g e
1 0
o f
3 6 J A 0 0 0 1 1 8 90 94 I NVOKESTATIC I NVOKESTATIC 89 (index) 13 (index) o 0 0 89 90 91 92 o 0 0 o 0 0 13 14 15 16 0 0 0 o 0 0 IMetho1 main I (V)V I I 0 0 0 Flag (ref) (ref) ) 42 o 0 0 ~ f ~ g ~ FOOl I FFF31 1 0 0 0 477 Class file Constant Pool Card Class file Constant Pool FIGURE 9 e . rJ'l . "'C ~ ~ ~ =
o (') .... ~ ( H N o o 0\ 1JJ =- ('D ('D ..... \0 o .... N (H d rJ1 ",-.....1 """"" """"" -.....1 ~ QO Ul = N ;? .... ro ::::l .... rt) ::::l VI Case: 13-1397 Document: 34 Page: 176 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 11 of 36 JA000119 u.s. Patent Oct. 3, 2006 Sheet 10 of 23 I 100 0: 1 : 2: 3: 4: 5: 6: ALOAD43 0 ILOAD 21 1 IFNE 1542: BIPUSH 16 5 FIGURE 10 0: 1 : 2: 3: 4: 5: 6: Patent Lens enabling INNOVATION US 7,117,485 B2 I 102 ALOAD 51 0 ILOAD 50 1 IFNE 272: BIPUSH 49 5 Case: 13-1397 Document: 34 Page: 177 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 12 of 36 JA000120 Patent Lens enabling INNOVATION u.s. Patent Oct. 3, 2006 Sheet 11 of 23 US 7,117,485 B2 ;- 112 I LOAD 8 o 0 0 V- 114 ---------- --------- o r--------- o r--------- o r--------- 5 f---------- r--------- r--------- o 0 0 Word-Based Operand Stack FIGURE 11 ;- 116 ILOAD B ~ 8 r 118 0 0 0 5 0 0 0 Byte-Based Operand Stack Case: 13-1397 Document: 34 Page: 178 Filed: 07/09/2013 h t t p : / / w w w . p a t e n t l e n s . n e t / C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 2
F i l e d
1 0 / 2 2 / 1 0
P a g e
1 3
o f
3 6 J A 0 0 0 1 2 1 Card Loader 10 28 120 Loading And Execution Control Integrated Circuit Card Card Operating System Card File System FIGURE 12 124 e . 7Jl . ~ ~ ~ ~ =
o (') .. ( H N o o 0\ \F.J =- ('t) ('t) ..... ~ N o .... N (H cj rfl ",--...1 I--' I--' --...1 ~ QO U'I t= N \J OJ rl ro ::::::l rl h) ::::::l Vl Case: 13-1397 Document: 34 Page: 179 Filed: 07/09/2013 h t t p : / / w w w . p a t e n t l e n s . n e t / C a s e
o (') .... ",(H N o o 0\ 1JJ =- ('D ('D ..... .... (H o -. N (H d rJ1 ",-.....1 """"" """"" -.....1 ~ QO Ul = N ~ ; ? !!:. .... ro ::::l .... rt) ::::l VI Case: 13-1397 Document: 34 Page: 180 Filed: 07/09/2013 h t t p : / / w w w . p a t e n t l e n s . n e t / C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 2
F i l e d
1 0 / 2 2 / 1 0
P a g e
1 5
o f
3 6 J A 0 0 0 1 2 3 - - -- --------------- --- - 144c RAM Heap ______ -- -------- -----.i "EEPROM Heap 146a System Stack 148 \ I File System V- 147 VM Stack / 141a L LOADABLE APPLCATION A 1 t 144a " System 1 r 141b Variables LOADABLE APPLCATION B 1 'C 144b r 141c Card RAM \.- 141 1 LOADABLE CLASS LlBRARyl Card ROM r 140 EEPROM Program Area Card EEPROM "-142 Loading And Execution Control 1\..120 FIXED APPLICATION I - Instruction Dispatch Loop '- 150 149, 140a Run - Time Instruction 16.J 145.../ Support Support I CLASS LIBRARY 1
""-140b Card JVM t 148../ I Card Operating System 122 ROM Program Area --- r 149 V 149 V 1 49 FIGUR E 14 e . 7Jl . ""d
= o (') :-+-
N o o 0'1 rFl =- ('D ('D ..... ....
o .... N (H d rJl -....l ';..... """'" -....l ):.. QO Ul co N
!C rt ro ::::l rt r ro ::::l Vl Case: 13-1397 Document: 34 Page: 181 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 16 of 36 JA000124 u.s. Patent Oct. 3, 2006 Execution Control Find Entry point class 10/method 10 Interpret method Report Success Patent Lens enabling INNOVATION Sheet 15 of 23 US 7,117,485 B2 152 153 NO FIGURE 15 Stop Card JVM and send Error to terminal Case: 13-1397 Document: 34 Page: 182 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 17 of 36 JA000125 Patent Lens enabling INNOVATION u.s. Patent Oct. 3, 2006 Sheet 16 of 23 US 7,117,485 B2 160 Set VM stack Parameters Set Card JVM program Counter YES 163 Handle native method NO Place return value on VM Stack YES Retrieve next byte code/type information 165b Check VM stack state (Pass 3 security checks) 165c Execute byte code 165d Set VM stack state 165e 165{ Retire the byte code FIGURE 16 Case: 13-1397 Document: 34 Page: 183 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 18 of 36 JA000126 u.s. Patent Oct. 3, 2006 Sheet 17 of 23 a byte code 172 execute bytecode YES 175 Report Success FIGURE 17 NO Patent Lens enabling INNOVATION US 7,117,485 B2 Stop Card JVM and Send error to terminal Case: 13-1397 Document: 34 Page: 184 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 19 of 36 JA000127 Patent Lens enabling INNOVATION u.s. Patent Oct. 3, 2006 Sheet 18 of 23 US 7,117,485 B2 160 Set VM stack Parameters Set Card JVM program Counter YES NO 163 Handle native method Place return value on VM Stack Retrieve next byte code 165b Execute byte code 165d FIGURE 18 Case: 13-1397 Document: 34 Page: 185 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 20 of 36 JA000128 Patent Lens enabling INNOVATION u.s. Patent Oct. 3, 2006 Sheet 19 of 23 US 7,117,485 B2 c: 0 ~ "'O:t:: s... ell . ~ ell .2 N C:() ()o.. Q.) 0.. ~ ::!2 <!: ~ ~ N () <0 a (\J 0) .,-. ~ c: ~ 0 >- "'0:0:1 - s... ell :0:1 ell .2 >- Cal ()o. Q.) 0.. ~ ::!2
( ( eS C (\J 0) ~ .,-. c: ~ 0 >- "'O:t:: - s...(lS :t:: S . ~ >< C<!: ()o. Q) 0.. :E
( ~ ( ( <0 ~ CO a c (\J 0) ~ (\J ~ 0) .,-. ~ Case: 13-1397 Document: 34 Page: 186 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 21 of 36 JA000129 Patent Lens enabling INNOVATION u.s. Patent Oct. 3, 2006 Sheet 20 of 23 US 7,117,485 B2 200 \ Card I;,126Z Run Program C Application Z !j190C Identity Enter PIN of A C ... / .- ... ... / Access Not / / .- Allowed /" " " / .- " 204\ / 202\ ~ ;- Other Identity Files C's Files FIGURE 20 Case: 13-1397 Document: 34 Page: 187 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 22 of 36 JA000130 Patent Lens enabling INNOVATION u.s. Patent Oct. 3, 2006 Sheet 21 of 23 US 7,117,485 B2 10 FIGURE 21 220 210 FIGURE 22 Case: 13-1397 Document: 34 Page: 188 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 23 of 36 JA000131 Patent Lens enabling INNOVATION u.s. Patent Oct. 3, 2006 Sheet 22 of 23 US 7,117,485 B2 230 FIGURE 23 210 240 FIGURE 24 Case: 13-1397 Document: 34 Page: 189 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 24 of 36 JA000132 u.s. Patent Oct. 3, 2006 Sheet 23 of 23 Patent Lens enabling INNOVATION US 7,117,485 B2 It) N W t: ::l (!) - u. Case: 13-1397 Document: 34 Page: 190 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 25 of 36 JA000133 Patent Lens enabling INNOVATION US 7,117,485 B2 1 USING A HIGH LEVEL PROGRAMMING LANGUAGE WITH A MICROCONTROLLER A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. Under 35 U.S.c. 119(e), this application claims benefit of prior u.s. provisional application Ser. No. 60/029,057, filed Oct. 25, 1996. BACKGROUND OF THE INVENTION This invention relates in general to the field of program- ming, and more particularly to using a high level program- ming language with a smart card or a microcontroller. Software applications written in the Java high-level pro- gramming language have been so designed that an applica- tion written in Java can be run on many different computer brands or computer platforms without change. This is accomplished by the following procedure. When a Java application is written, it is compiled into "Class" files containing byte codes that are instructions for a hypothetical computer called a Java Virtual Machine. An implementation of this virtual machine is written for each platform that is supported. When a user wishes to run a particular Java application on a selected platform, the class files compiled from the desired application is loaded onto the selected platform. The Java virtual machine for the selected platform is run, and interprets the byte codes in the class file, thus effectively running the Java application. Java is described in the following references which are hereby incorporated by reference: (1) Aruold, Ken, and James Gosling, "The Java Programming Language," Addi- son-Wesley, 1996; (2) James Gosling, Bill Joy, and Guy Steele, "The Java Language Specification," Sun Microsys- terns, 1996, (web site: http://java.sun.com/doc/languag- e_specification); (3) James Gosling and Henry McGilton, "The Java Language Environment: A White Paper," Sun Microsystems, 1995 (web site: http://java.sun.com/doc/lan- guage_environmentl); and (4) Tim Lindholm and Frank Yellin, "The Java Virtual Machine Specification," Addison- Wesley, 1997. These texts among many others describe how to program using Java. In order for a Java application to run on a specific platform, a Java virtual machine implementation must be written that will run within the constraints of the platform, and a mechanism must be provided for loading the desired Java application on the platform, again keeping within the constraints of this platform. 10 2 single instruction. In contrast to the microprocessor, a micro- controller includes a central processing unit, memory and other functional elements, all on a single semiconductor substrate, or integrated circuit (e.g., a "chip"). As compared to the relatively large external memory accessed by the microprocessor, the typical micro controller accesses a much smaller memory. A typical micro controller can access one to sixty-four kilobytes of built-in memory, with sixteen kilo- bytes being very common. There are generally three different types of memory used: random access memory (RAM), read only memory (ROM), and electrically erasable programmable read only memory (EEPROM). In a microcontroller, the amount of each kind of memory available is constrained by the amount of space 15 on the integrated circuit used for each kind of memory. Typically, RAM takes the most space, and is in shortest supply. ROM takes the least space, and is abundant. EEPROM is more abundant than RAM, but less than ROM. Each kind of memory is suitable for different purposes. 20 Although ROM is the least expensive, it is suitable only for data that is unchanging, such as operating system code. EEPROM is useful for storing data that must be retained when power is removed, but is extremely slow to write. RAM can be written and read at high speed, but is expensive 25 and data in RAM is lost when power is removed. A micro- processor system typically has relatively little ROM and EEPROM, and has 1 to 128 megabytes of RAM, since it is not constrained by what will fit on a single integrated circuit device, and often has access to an external disk memory 30 system that serves as a large writable, non-volatile storage area at a lower cost than EEPROM. However, a micro con- troller typically has a small RAM of 0.1 to 2.0 K, 2K to 8K of EEPROM, and 8K -56K of ROM. Due to the small number of external components required 35 and their small size, micro controllers frequently are used in integrated circuit cards, such as smart cards. Such smart cards come in a variety of forms, including contact-based cards, which must be inserted into a reader to be used, and contactless cards, which need not be inserted. In fact, 40 microcontrollers with contactless communication are often embedded into specialized forms, such as watches and rings, effectively integrating the functionality of a smart card in an ergonomically attractive mamler. Because of the constrained environment, applications for 45 smart cards are typically written in a low level programming language (e.g., assembly language) to conserve memory. The integrated circuit card is a secure, robust, tamper- resistant and portable device for storing data. The integrated circuit card is the most personal of personal computers 50 because of its small size and because of the hardware and software data security features unique to the integrated circuit card. The primary task of the integrated circuit card and the microcontroller on the card is to protect the data stored on the card. Consequently, since its invention in 1974, inte- grated circuit card technology has been closely guarded on these same security grounds. The cards were first used by French banks as debit cards. In this application, before a financial transaction based on the card is authorized, the card Conventional platforms that support Java are typically microprocessor-based computers, with access to relatively 55 large amounts of memory and hard disk storage space. Such microprocessor implementations frequently are used in desktop and personal computers. However, there are no conventional Java implementations on microcontrollers, as would typically be used in a smart card. 60 user must demonstrate knowledge of a 4-digit personal identification number (PIN) stored in the card in addition to being in possession of the card. Any information that might contribute to discovering the PIN number on a lost or stolen Microcontrollers differ from microprocessors in many ways. For example, a microprocessor typically has a central processing unit that requires certain external components (e.g., memory, input controls and output controls) to func- tion properly. A typical microprocessor can access from a 65 megabyte to a gigabyte of memory, and is capable of processing 16, 32, or 64 bits of information or more with a card was blocked from public distribution. In fact, since nobody could tell what information might be useful in this regard, virtually all information about integrated circuit cards was withheld. Case: 13-1397 Document: 34 Page: 191 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 26 of 36 JA000134 Patent Lens enabling INNOVATION US 7,117,485 B2 3 Due to the concem for security, applications written for integrated circuit cards have unique properties. For example, each application typically is identified with a particular owner or identity. Because applications typically are written in a low-level programming language, such as assembly language, the applications are written for a particular type of microcontroller. Due to the nature of low level programming languages, unauthorized applications may access data on the integrated circuit card. Programs written for an integrated circuit card are identified with a particular identity so that if two identities want to perform the same programming function there must be two copies of some portions of the application on the micro controller of the integrated circuit card. Integrated circuit card systems have historically been closed systems. An integrated circuit card contained a dedi- cated application that was handcrafted to work with a specific terminal application. Security checking when an integrated circuit card was used consisted primarily of making sure that the card application and the tenninal application were a matched pair and that the data on the card was valid. As the popularity of integrated circuit cards grew, it became clear that integrated circuit card users would be averse to carrying a different integrated circuit card for each integrated circuit card application. Therefore, multiple coop- erating applications began to be provided on single provider integrated circuit cards. Thus, for example, an automated teller machine (ATM) access card and a debit card may coexist on a single integrated circuit card platform. Never- theless, this was still a closed system since all the applica- tions in the tenninal and the card were built by one provider having explicit knowledge of the other providers. 4 can be quickly prototyped and downloaded to a smart card in a matter of hours without resorting to soft masks. Embed- ded systems using micro controllers can also gain many of these advantages for downloading new applications, high level program development, and rapid prototyping by mak- ing use of this invention. Implementations of the invention may include one or more of the following. The high level programming lan- guage fonnat of the application may have a class file fonnat 10 and may have a Java programming language fonnat. The processor may be a microcontroller. At least a portion of the memory may be located in the processor. The application may have been processed from a second application that has a string of characters, and the string of 15 characters may be represented in the first application by an identifier (e.g., an integer). The processor may be also configured to receive a request from a requester (e.g., a processor or a terminal) to access an element (e.g., an application stored in the memory, data 20 stored in the memory or the communicator) of the card, after receipt of the request, interact with the requester to authen- ticate an identity of the requester, and based on the identity, selectively grant access to the element. The memory may also store an access control list for the 25 element. The access control list fumishes an indication of types of access to be granted to the identity, and based on the access control list, the processor selectively grants specific types of access (e.g., reading data, writing data, appending 30 data, creating data, deleting data or executing an application) to the requester. The paucity of information about integrated circuit cards-particularly information about how to communicate 35 with them and how to program them-has impeded the general application of the integrated circuit card. However, the advent of public digital networking (e.g., the Intemet and the World Wide Web) has opened new domains of applica- tion for integrated circuit cards. In particular, this has lead to 40 a need to load new applications on the card that do not have explicit knowledge of the other providers, but without the possibility of compromising the security of the card. How- ever, typically, this is not practical with conventional cards that are programmed using low level languages. 45 The application may be one of a several applications stored in the memory. The processor may be further con- figured to receive a request from a requester to access one of the plurality of applications; after receipt of the request, determine whether said one of the plurality of applications complies with a predetennined set of rules; and based on the determination, selectively grant access to the requester to said one of the plurality of applications. The predetermined rules provide a guide for determining whether said one of the plurality of applications accesses a predetennined region of the memory. The processor may be further configured to authenticate an identity of the requester and grant access to said one of the plurality of applications based on the identity. The processor may be also configured to interact with the tenninal via the communicator to authenticate an identity; determine if the identity has been authenticated; and based on the determination, selectively allow communication between the terminal and the integrated circuit card. SUMMARY OF THE INVENTION In general, in one aspect, the invention features an inte- grated circuit card for use with a tenninal. The integrated 50 circuit card includes a memory that stores an interpreter and The communicator and the terminal may communicate via communication charmels. The processor may also be configured to assign one of the communication chaunels to the identity when the processor allows the communication between the terminal and the integrated circuit card. The processor may also be configured to assign a session key to the assigned communication chaunel and use the session key an application that has a high level programming language format. A processor of the card is configured to use the interpreter to interpret the application for execution and to use a communicator of the card to communicate with the 55 terminal. Among the advantages of the invention are one or more of the following. New applications may be downloaded to a smart card without compromising the security of the smart card. These applications may be provided by different com- panies loaded at different times using different tenninals. Security is not compromised since the applications are protected against unauthorized access of any application code or data by the security features provided by the Java virtual machine. Smart card applications can be created in high level languages such as Java and Eiffel, using powerful mainstream program development tools. New applications when the processor and the tenninal communicate via the assigned communication charmel. The terminal may have a card reader, and the communi- 60 cator may include a contact for communicating with the card reader. The terminal may have a wireless communication device, and the communictor may include a wireless trans- ceiver for communicating with the wireless communication device. The tenninal may have a wireless communication 65 device, and the communicator may include a wireless trans- mitter for communicating with the wireless communication device. Case: 13-1397 Document: 34 Page: 192 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 27 of 36 JA000135 Patent Lens enabling INNOVATION US 7,117,485 B2 5 In general, in another aspect, the invention features a method for use with an integrated circuit card and a terminal. The method includes storing an interpreter and at least one application having a high level programming language for- mat in a memory of the integrated circuit card. A processor of the integrated circuit card uses the interpreter to interpret the at least one application for execution, and the processor uses a communicator of the card when communicating between the processor and the terminal. In general, in another aspect, the invention features a 10 smart card. The smart card includes a memory that stores a Java interpreter and a processor that is configured to use the interpreter to interpret a Java application for execution. In general, in another aspect, the invention features a microcontroller that has a semiconductor substrate and a 15 memory located in the substrate. A programming language interpreter is stored in the memory and is configured to implement security checks. A central processing unit is located in the substrate and is coupled to the memory. 6 application that has been processed from a second applica- tion having a string of characters. The string of characters are represented in the first application by an identifier. The integrated circuit card includes a processor that is coupled to the memory. The processor is configured to use the inter- preter to interpret the first application for execution and to use the communicator to communicate with the terminal. In general, in another aspect, the invention features a method for use with an integrated circuit card and a terminal. The method includes processing a second application to create a first application. The second application has a string of characters. The string of characters is represented by an identifier in the second application. An interpreter and the first application are stored in a memory of the integrated circuit card. A processor uses an interpreter to interpret the first application for execution. In general, in another aspect, the invention features a microcontroller that includes a memory which stores an application and an interpreter. The application has a class file format. A processor of the microcontroller is coupled to the memory and is configured to use the interpreter to interpret the application for execution. Implementations of the invention may include one or 20 more of the following. The interpreter may be a Java byte code interpreter. The security checks may include establish- ing firewalls and may include enforcing a sandbox security model. In implementations of the invention, the micro controller may also include a communicator that is configured to 25 communicate with a terminal. In general, in another aspect, the invention features a smart card that has a progranlilling language interpreter stored in a memory of the card. The interpreter is configured to implement security check. A central processing unit of the card is coupled to the memory. In general, in another aspect, the invention features an 30 integrated circuit card that is used with a terminal. The card includes a communicator and a memory that stores an interpreter and first instructions of a first application. The first instructions have been converted from second instruc- tions of a second application. The integrated circuit card 35 includes a processor that is coupled to the memory and is configured to use the interpreter to execute the first instruc- tions and to communicate with the terminal via the com- municator. In general, in another aspect, the invention features a method for use with an integrated circuit card. The method includes storing a first application in a memory of the integrated circuit card, storing a second application in the memory of the integrated circuit card, and creating a firewall that isolates the first and second applications so that the second application cannot access either the first application or data associated with the first application. In general, in another aspect, the invention features an integrated circuit card for use with a terminal. The integrated circuit card includes a communicator that is configured to communicate with the terminal, a memory and a processor. The memory stores applications, and each application has a high level programming language format. The memory also 40 stores an interpreter. The processor is coupled to the memory and is configured to: a.) use the interpreter to interpret the applications for execution, b.) use the interpreter to create a firewall to isolate the applications from each other, and c.) use the communicator to communicate with the terminal. Implementations of the invention may include one or more of the following. The first and/or second applications may have class file format(s). The first and/or second applications may include byte codes, such as Java byte codes. The first instructions may be generalized or renum- bered versions of the second instructions. The second 45 instructions may include constant references, and the first instructions may include constants that replace the constant references of the second instructions. The second instruc- tions may include references, and the references may shift location during the conversion of the second instructions to 50 the first instructions. The first instructions may be relinked to the references after the shifting. The first instructions may include byte codes for a first type of virtual machine, and the second instructions may include byte codes for a second type of virtual machine. The first type is different from the 55 second type. In general, in another aspect, the invention features a method for use with an integrated circuit card. The method includes converting second instructions of a second appli- cation to first instructions of a first application; storing the 60 first instructions in a memory of the integrated circuit card; and using an interpreter of the integrated circuit card to execute the first instructions. Other advantages and features will become apparent from the following description and from the claims. BRIEF DESCRIPTION OF THE DRAWING FIG. 1 is a block diagram of an integrated card system. FIG. 2 is a flow diagram illustrating the preparation of Java applications to be downloaded to an integrated circuit card. FIG. 3 is a block diagram of the files used and generated by the card class file converter. FIG. 4 is a block diagram illustrating the transformation of application class file( s) into a card class file. FIG. 5 is a flow diagram illustrating the working of the class file converter. FIG. 6 is a flow diagram illustrating the modification of the byte codes. FIG. 7 is a block diagram illustrating the transformation of specific byte codes into general byte codes. In general, in another aspect, the invention features an integrated circuit for use with a terminal. The integrated circuit card has a communicator that is configured to com- municate with the terminal and a memory that stores a first FIG. 8 is a block diagram illustrating the replacement of 65 constant references with constants. FIG. 9 is a block diagram illustrating the replacement of references with their updated values. Case: 13-1397 Document: 34 Page: 193 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 28 of 36 JA000136 Patent Lens enabling INNOVATION US 7,117,485 B2 7 FIG. 10 is a block diagram illustrating renumbering of original byte codes. FIG. 11 is a block diagram illustrating translation of original byte codes for a different virtual machine architec- ture. FIG. 12 is a block diagram illustrating loading applica- tions into an integrated circuit card. FIG. 13 is a block diagram illustrating executing appli- cations in an integrated circuit card. FIG. 14 is a schematic diagram illustrating memory organization for ROM, RAM and EEPROM. FIG. 15 is a flow diagram illustrating the overall archi- tecture of the Card Java virtual machine. FIG. 16 is a flow diagram illustrating method execution in the Card Java virtual machine with the security checks. FIG. 17 is a flow diagram illustrating byte code execution in the Card Java virtual machine. FIG. 18 is a flow diagram illustrating method execution in the Card Java virtual machine without the security checks. FIG. 19 is a block diagram illustrating the association between card applications and identities. FIG. 20 is a block diagram illustrating the access rights of a specific running application. FIG. 21 is a perspective view of a micro controller on a smart card. FIG. 22 is a perspective view of a micro controller on a telephone. FIG. 23 is a perspective view of a micro controller on a key ring. FIG. 24 is a perspective view of a micro controller on a ring. FIG. 25 is a perspective view of a micro controller on a circuit card of an automobile. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Referring to FIG. 1, an integrated circuit card 10 (e.g., a smart card) is constructed to provide a high level, Java- based, multiple application programming and execution environment. The integrated circuit card 10 has a commu- nicator 12a that is configured to communicate with a ter- minal communicator 12b ofa terminal 14. In some embodi- ments, the integrated circuit card 10 is a smart card with an 8 quency or infrared techniques, serial communication proto- cols, packet communication protocols, ISO 7816 communication protocol, to name a few. The terminal 14 can also interact with applications run- ning in the integrated circuit card 10. In some cases, different terminals may be used for these purposes. For example, one kind of terminal may be used to prepare applications, different terminals could be used to download the applica- tions, and yet other terminals could be used to run the 10 various applications. Terminals can be automated teller machines (ATMs), point-of-sale terminals, door security systems, toll payment systems, access control systems, or any other system that communicates with an integrated circuit card or micro controller. 15 The integrated circuit card 10 contains a card Java virtual machine (Card JVM) 16, which is used to interpret appli- cations which are contained on the card 10. Referring to FIG. 2, the Java application 20 includes three Java source code files A.java 20a, B.java 20b, and c.java 20 20e. These source code files are prepared and compiled in a Java application development environment 22. When the Java application 20 is compiled by the development envi- ronment 22, application class files 24 are produced, with these class files A.class 24a, B.class 24b, and C.class 24e 25 corresponding to their respective class Java source code 20a, 20b, and 20e. The application class files 24 follow the standard class file format as documented in chapter 4 of the Java virtual machine specification by Tim Lindholm and Frank Yellin, "The Java Virtual Machine Specification," 30 Addison-Wesley, 1996. These application class files 24 are fed into the card class file converter 26, which consolidates and compresses the files, producing a single card class file 27. The card class file 27 is loaded to the integrated circuit 35 card 10 using a conventional card loader 28. Referring to FIG. 3, the card class file converter 26 is a class file postprocessor that processes a set of class files 24 that are encoded in the standard Java class file format, optionally using a string to ID input map file 30 to produce a Java card class file 27 in a card class file format. One such 40 card class file format is described in Appendix A which is hereby incorporated by reference. In addition, in some embodiments, the card class file converter 26 produces a string to ID output map file 32 that is used as input for a subsequent execution of the card class file converter. In some embodiments, in order for the string to ID mapping to be consistent with a previously generated card class file (in the case where multiple class files reference the same strings), the card class file converter 26 can accept previously defined string to ID mappings from a string to ID 8 bit microcontroller, 512 bytes of RAM, 4K bytes of 45 EEPROM, and 20K of ROM; the terminal communicator 12b is a conventional contact smart card reader; and the terminal 14 is a conventional personal computer running the Windows NT operating system supporting the personal computer smart card (PC/SC) standard and providing Java development support. 50 input map file 30. In the absence of such a file, the IDs are generated by the card class file converter 26. Appendix B, which is hereby incorporated by reference, describes one possible way of implementing and producing the string to ID input map file 30 and string to ID output map file 32 and In some embodiments, the microcontroller, memory and communicator are embedded in a plastic card that has substantially the same dimensions as a typical credit card. In other embodiments, the microcontroller, memory and com- municator are mounted within bases other than a plastic card, such as jewelry (e.g., watches, rings or bracelets), automotive equipment, telecommunication equipment (e.g., subscriber identity module (SIM) cards), security devices (e.g., cryptographic modules) and appliances. The terminal 14 prepares and downloads Java applica- tions to the integrated circuit card 10 using the terminal communicator 12b. The terminal communicator 12b is a communications device capable of establishing a commu- nications chaunel between the integrated circuit card 10 and the terminal 14. Some communication options include con- tact card readers, wireless communications via radio fre- 55 illustrates this mapping via an example. Referring to FIG. 4, a typical application class file 24a includes class file information 41; a class constant pool 42; class, fields created, interfaces referenced, and method infor- mation 43; and various attribute information 44, as detailed 60 in aforementioned Java Virtual Machine Specification. Note that much of the attribute information 44 is not needed for this embodiment and is eliminated 45 by the card class file converter 26. Eliminated attributes include SourceFile, Con- stantValue, Exceptions, LineNumberTable, Localvariable- 65 Table, and any optional vendor attributes. The typical card class file 27 as described in Appendix A is derived from the application class files 24 in the following mauner. The card Case: 13-1397 Document: 34 Page: 194 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 29 of 36 JA000137 Patent Lens enabling INNOVATION US 7,117,485 B2 9 class file infonnation 46 is derived from the aggregate class file information 41 of all application class files 24a, 24b, and 24c. The card class file constant pool 47 is derived from the aggregate class constant pool 42 of all application class files 24a, 24b, and 24c. The card class, fields created, interfaces 5 referenced, and method information 48 is derived from the aggregate class, fields created, interfaces referenced, and method infonnation 43 of all application class files 24a, 24b, and 24c. The card attribute infonnation 49 in this embodi- ment is derived from only the code attribute of the aggregate 10 attribute infonnation 44 of all application class files 24a, 24b, and 24c. 10 Modifying the byte codes 54 involves exammmg the Code attribute infonnation 44 for each method in the class file, and modifYing the operands of byte codes that refer to entries in the Java class file constant pool 42 to reflect the entries in the card class file constant pool 47. In some embodiments, the byte codes are also modified, as described below. Modifying the byte codes 54 involves five passes (with two optional passes) as described by the flowchart in FIG. 6. The original byte codes 60 are found in the Code attribute 44 of the Java class file 24a being processed. The first pass 61 records all the jumps and their destinations in the original byte codes. During later byte code translation, some single byte code may be translated to dual or triple bytes. FIG. 7 15 illustrates an example wherein byte code ILOAD_O is replaced with two bytes, byte code ILOAD and argument O. When this is done, the code size changes, requiring adjust- ment of any jnmp destinations which are affected. Therefore, before these transfonnations are made, the original byte To avoid dynamic linking in the card, all the infonnation that is distributed across several Java class files 24a, 24b, and 24c that form the application 24, are coalesced into one card class file 27 by the process shown in the flowchart in FIG. 5. The first class file to be processed is selected 51a. The constant pool 42 is compacted SIb in the following manner. All objects, classes, fields, methods referenced in a Java class file 24a are identified by using strings in the constant pool 42 of the class file 24a. The card class file converter 26 compacts the constant pool 42 found in the Java class file 24a into an optimized version. This compaction is achieved by mapping all the strings found in the class file 25 constant pool 42 into integers (the size of which is micro- controller architecture dependent). These integers are also referred to as IDs. Each ID uniquely identifies a particular object, class, field or method in the application 20. There- fore, the card class file converter 26 replaces the strings in the Java class file constant pool 42 with its corresponding unique ID. Appendix B shows an example application HelloSmartCard.java, with a table below illustrating the IDs corresponding to the strings found in the constant pool of the class file for this application. The IDs used for this example are 16-but unsigned integers. Next, the card class file converter 26 checks for unsup- ported features Sic in the Code attribute of the input Java class file 24a. The Card NM 16 only supports a subset of the full Java byte codes as described in Appendix C, which is hereby incorporated by reference. Hence, the card class file converter 26 checks for unsupported byte codes in the Code attribute of the Java class file 24a. If any unsupported byte codes are found 52, the card class file converter flags an error and stops conversion 53. The program code fragment marked "A" in APPENDIX D shows how these spurious byte codes are apprehended. Another level of checking can 20 codes 60 are analyzed for any jump byte codes and a note made of their position and current destination. The program code fragment marked "B" in Appendix D shows how these jumps are recorded. Appendix D is hereby incorporated by reference. Once the jumps are recorded, if the optional byte code translation is not being perfonned 62, the card class file converter 26 may proceed to the third pass 64. Otherwise, the card class file converter converts specific byte codes into generic byte codes. Typically, the translated 30 byte codes are not interpreted in the Card JVM 16 but are supported by converting the byte codes into equivalent byte codes that can be interpreted by the Card JVM 16 (see FIG. 7). The byte codes 70 may be replaced with another seman- tically equivalent but different byte codes 72. This generally 35 entails the translation of short single specific byte codes such as ILOAD_O into their more general versions. For example, ILOAD_O may be replaced by byte code ILOAD with an argument O. This translation is done to reduce the nnmber of byte codes translated by the Card JVM 16, consequently 40 reducing the complexity and code space requirements for the Card JVM 16. The program code fragment marked "C" in Appendix D shows how these translations are made. Note that such translations increase the size of the resulting byte code and force the re-computation of any jumps which are 45 affected. be perfonned by requiring the standard Java development environment 22 to compile the application 20 with a '-g' flag. Based on the aforementioned Java virtual machine 50 specification, this option requires the Java compiler to place information about the variables used in a Java application 20 In the third pass 64, the card class file converter rebuilds constant references via elimination of the strings used to denote these constants. FIG. 8 shows an example wherein the byte code LDC 80 referring to constant "18" found via an index in the Java class file 24a constant pool 42 may be translated into BIPUSH byte code 82. In this pass the card class file converter 26 modifies the operands to all the byte codes that refer to entries in the Java class file constant pool 42 to reflect their new location in the card class file constant pool 47. FIG. 9 shows an example wherein the argument to a byte code, INVOKESTATIC 90, refers to an entry in the in the LocalVariableTable attribute of the class file 24a. The card class file converter 26 uses this infonnation to check if the Java class file 24a references data types not supported by 55 the Java card. Java class file constant pool 42 that is modified to reflect the new location of that entry in the card class file constant pool 47. The modified operand 94 shows this transformation. The 60 program code fragment marked "D" in Appendix D shows how these modifications are made. Next, the card class file converter 26 discards all the unnecessary parts SIc of the Java class file 24a not required for interpretation. A Java class file 24a stores infonnation pertaining to the byte codes in the class file in the Attributes section 44 of the Java class file. Attributes that are not required for interpretation by the card NM 16, such as SourceFile, ConstantValue, Exceptions, LineNumberTable, and LocalvariableTable may be safely discarded 45. The only attribute that is retained is the Code attribute. The Code 65 attribute contains the byte codes that correspond to the methods in the Java class file 24a. Once the constant references are relinked, if the optional byte code modification is not being perfonned, the card class file converter may proceed to the fifth and final pass 67. Otherwise, the card class file converter modifies the original byte codes into a different set of byte codes sup- ported by the particular Card NM 16 being used. One Case: 13-1397 Document: 34 Page: 195 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 30 of 36 JA000138 Patent Lens enabling INNOVATION US 7,117,485 B2 11 potential modification renumbers the original byte codes 60 into Card NM 16 byte codes (see FIG. 10). This renum- bering causes the byte codes 100 in the original byte codes 60 to be modified into a renumbered byte codes 102. Byte code ILOAD recognized by value 21 may be renumbered to 5 be recognized by value 50. This modification may be done for optimizing the type tests (also known in prior art as Pass 3 checks) in the Card NM 16. The program code fragment marked"E" in Appendix D shows an implementation of this embodiment. This modification may be done in order to 10 reduce the program space required by the Card NM 16 to interpret the byte code. Essentially this modification regroups the byte codes into Card JVM 16 byte codes so that byte codes with similar operands, results are grouped together, and there are no gaps between Card NM 16 byte 15 codes. This allows the Card NM 16 to efficiently check Card JVM 16 byte codes and validate types as it executes. In some embodiments, the card class file converter modi- fies the original byte codes 60 into a different set of byte codes designed for a different virtual machine architecture, 20 as shown in FIG. 11. The Java byte code ILOAD 112 intended for use on a word stack 114 may be replaced by Card JVM 16 byte code ILOAD_B 116 to be used on a byte stack 118. An element in a word stack 114 requires allocat- ing 4 bytes of stack space, whereas an element in the byte 25 stack 118 requires only one byte of stack space. Although this option may provide an increase in execution speed, it risks losing the security features available in the original byte codes. Since the previous steps 63, 64 or 66 may have changed 30 the size of the byte codes 60 the card class file converter 26 has to relink 67 any jumps which have been effected. Since the jumps were recorded in the first step 61 of the card class file converter 26, this adjustment is carried out by fixing the jump destinations to their appropriate values. The program 35 code fragment marked "F" in Appendix D shows how these jumps are fixed. The card class file converter now has modified byte codes 68 that is equivalent to the original byte codes 60 ready for loading. The translation from the Java class file 24a to the 40 card class file 27 is now complete. Referring back to FIG. 5, if more class files 24 remain to be processed 55 the previous steps 51a, SIb, SIc, 52 and 54 are repeated for each remaining class file. The card class file converter 26 gathers 56 the maps and modified byte codes 45 for the classes 24 that have been processed, places them as an aggregate and generates 57 a card class file 27. If required, the card class file converter 26 generates a string to ID output map file 32, that contains a list of all the new IDs allocated for the strings encountered in the constant pool 50 42 of the Java class files 24 during the translation. Referring to FIG. 12, the card loader 28 within the terminal 14 sends a card class file to the loading and execution control 120 within the integrated circuit card 10 using standard ISO 7816 commands. The loading and execu- 55 tion control 120 with a card operating system 122, which provides the necessary system resources, including support for a card file system 124, which can be used to store several card applications 126. Many conventional card loaders are written in low level languages, supported by the card oper- 60 ating system 122. In the preferred embodiment, the boot- strap loader is written in Java, and the integrated circuit card 12 application 126x stored in the card file system 126 in the EEPROM of the integrated circuit card 10. Multiple Java card applications 126x, 126y, and 126z can be stored in a single card in this manner. The loading and execution control 120 supports commands whereby the terminal 14 can select which Java card application to run immediately, or upon the next card reset. Referring to FIG. 13, upon receiving a reset or an execu- tion command from the loading and execution control 120, the Card Java Virtual Machine (Card NM) 16 begins execution at a predetermined method (for example, main) of the selected class in the selected Java Card application 126z. The Card NM 16 provides the Java card application 126z access to the underlying card operating system 122, which provides capabilities such as I/O, EEPROM support, file systems, access control, and other system functions using native Java methods as illustrated in Appendix F which is hereby incorporated by reference. The selected Java card application 126z communicates with an appropriate application in the terminal 14 using the communicator 12a to establish a communication charmel to the terminal 14. Data from the communicator 12a to the terminal 14 passes through a communicator driver 132 in the terminal, which is specifically written to handle the com- munications protocol used by the communicator 12a. The data then passes to an integrated circuit card driver 134, which is specifically written to address the capabilities of the particular integrated circuit card 10 being used, and provides high level software services to the terminal application 136. In the preferred embodiment, this driver would be appro- priate Pc/SC Smartcard Service Provider (SSP) software. The data then passes to the terminal application 136, which must handle the capabilities provided by the particular card application 126z being run. In this marmer, commands and responses pass back and forth between the terminal appli- cation 136 and the selected card application 126z. The terminal application interacts with the user, receiving com- mands from the user, some of which are passed to the selected Java card application 126z, and receiving responses from the Java card application 126z, which are processed and passed back to the user. Referring to FIG. 14, the Card NM 16 is an interpreter that interprets a card application 126x. The memory resources in the microcontroller that impact the Card JVM 16 are the Card ROM 140, Card RAM 141 and the Card EEPROM 142. The Card ROM 140 is used to store the Card JVM 16 and the card operating system 122. Card ROM 140 may also be used to store fixed card applications 140a and class libraries 140b. Loadable applications 141a, 141b and libraries 141c may also be stored in Card RAM 141. The Card NM 16 interprets a card application 141a, 141b, or 140a. The Card JVM 16 uses the Card RAM to store the VM stack 144a and system state variables 144b. The Card JVM 16 keeps track of the operations performed via the VM stack 144a. The objects created by the Card JVM 16 are either on the RAM heap 144c, in the EEPROM heap 146a, or in the file system 147. All of the heap manipulated by the Card JVM 16 may be stored in the Card RAM 141 as a RAM Heap 144c, or it may be distributed across to the Card EEPROM 142 as a EEPROM Heap 146a. Card RAM 141 is also used for recording the state of the system stack 148 that is used by routines written in the native code of the microcontroller. The Card JVM 16 uses the Card EEPROM 142 to store 10 includes a Java virtual machine to run this application. A Java implementation of the loading and execution control 120 is illustrated in Appendix E which is hereby incorpo- rated by reference. The loading and execution control 120 receives the card class file 26 and produces a Java card 65 application data either in the EEPROM heap 146a or in the file system 147. Application data stored in a file may be manipulated via an interface to the card operating system Case: 13-1397 Document: 34 Page: 196 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 31 of 36 JA000139 Patent Lens enabling INNOVATION US 7,117,485 B2 13 122. This interface is provided by a class library 140b stored in Card ROM 140, by a loadable class library 141c stored in Card EEPROM 142. One such interface is described in Appendix F. Applications and data in the card are isolated by a firewall mechanism 149. 14 the native method subroutine is placed on the VM stack 144a so that it may be accessed by the next byte code to be executed. The dispatch loop 164 of the Card JVM 16 is then entered. 5 The byte code dispatch loop is responsible for preparing, executing, and retiring each byte code. The loop terminates when it finishes interpreting the byte codes in the method 160, or when the Card NM 16 encounters a resource To cope with the limited resources available on micro- controllers, the Card NM 16 implements a strict subset of the Java programming language. Consequently, a Java appli- cation 20 compiles into a class file that contains a strict subset of Java byte codes. This enables application program- 10 mers to program in this strict subset of Java and still maintain compatibility with existing Java Virtual Machines. The semantics of the Java byte codes interpreted by the Card JVM 16 are described in the aforementioned Java Virtual Machine Specification. The subset of byte codes interpreted limitation or a security violation. If a previous byte code caused a branch to be taken 165 the Card NM prepares for the branch 165a. The next byte code is retrieved 165b. In order to keep the cost of process- ing each byte code down, as many common elements such as the byte code arguments, length, type are extracted and 15 stored. by the Card JVM 16 can be found in Appendix C. The card class file converter 26 checks the Java application 20 to ensure use of only the features available in this subset and converts into a form that is understood and interpreted by the Card JVM 16. In other embodiments, the Card NM 16 is designed to interpret a different set or augmented set of byte codes 116. Although a different byte code set might lead to some performance improvements, departing from a strict Java subset may not be desirable from the point of view of security that is present in the original Java byte codes or compatibility with mainstream Java development tools. To provide the security offered by the security model of the programming language, byte codes in the class file must be verified and determined conformant to this model. These checks are typically carried out in prior art by a program 20 referred to as the byte code verifier, which operates in four passes as described in the Java Virtual Machine Specifica- tion. To offer the run-time security that is guaranteed by the byte code verifier, the Card JVM 16 must perform the checks that pertain to the Pass 3 and Pass 4 of the verifier. This 25 checking can be bypassed by the Card NM 16 if it can be guaranteed (which is almost impossible to do) that the byte codes 60 interpreted by the Card NM 16 are secure. At the minimum, code security can be maintained as long as object All Card JVM 16 applications 126 have a defined entry point denoted by a class and a method in the class. This entry 30 point is mapped in the string to ID input map 30 and assigned by the card class file converter 26. Classes, meth- ods and fields within a Java application 20 are assigned IDs references cannot be faked and the VM stack 144a and local variable bounds are observed. This requires checking the state of the VM stack 144a with respect to the byte code being executed. To enforce the security model of the programming lan- guage, a 256-byte table is created as shown in Appendix G which is hereby incorporated by reference. This table is indexed by the byte code number. This table contains the by the card class file converter 26. For example, the ID corresponding to the main application class may be defined 35 as Fool and the ID corresponding to its main method, such as "main( )V" could be defined as F002. The overall execution architecture of the Card NM is described by the flowchart in FIG. 15. Execution of the Card JVM 16 begins at the execution control 120, which chooses a card application 126z to execute. It proceeds by finding and assigning an entry point 152 (a method) in this card application for the Card JVM 16 to interpret. The Card JVM 16 interprets the method 153. If the interpretation proceeds successfully 154, the Card JVM 16 reports success 155 returning control back to the execution control 120. If in the course of interpretation 153 the Card NM 16 encounters an unhandled error or exception (typically a resource limitation or a security violation), the Card JVM 16 stops 156 and reports the appropriate error to the terminal 14. An essential part of the Card JVM 16 is a subroutine that handles the execution of the byte codes. This subroutine is described by the flowchart in FIG. 16. Given a method 160 type and length information associated with the indexing byte code. It is encoded with the first 5 bits representing type, and the last 3 bits representing length. The type and 40 length of the byte code is indexed directly from the table by the byte code number. This type and length is then used for checking as shown in Appendix H which is hereby incor- porated by reference. In Appendix H, the checking process begins by decoding the length and type from the table in 45 Appendix G which is hereby incorporated by reference. The length is used to increment the program counter. The type is used first for pre-execution checking, to insure that the data types on the VM stack 144a are correct for the byte code that is about to be executed. The 256 bytes of ROM for table 50 storage allows the original Java byte codes to be run in the Card JVM 16 and minimizes the changes required to the Java class file to be loaded in the card. Additional Java byte codes can be easily supported since it is relatively easy to it executes the byte codes in this method. The subroutine starts by preparing for the parameters of this method 161. 55 This involves setting the VM stack 144a pointer, VM stack 144a frame limits, and setting the program counter to the first byte code of the method. update the appropriate table entries. In other embodiments, as shown in FIG. 10, the Java byte codes in the method are renumbered in such a manner that the byte code type and length information stored in the table in Appendix H is implicit in the reordering. Appendix H is hereby incorporated by reference. Consequently, the checks Next, the method flags are checked 162. If the method is flagged native, then the method is actually a call to native method code (subroutine written in the microcontroller's native processor code). In this case, the Card NM 16 prepares for an efficient call 163 and return to the native code subroutine. The parameters to the native method may be passed on the VM stack 144a or via the System stack 148. The appropriate security checks are made and the native method subroutine is called. On return, the result (if any) of 60 that must be performed on the state of the VM stack 144a and the byte code being processed does not have to involve a table look up. The checks can be performed by set of simple comparisons as shown in Appendix I which is hereby incorporated by reference. This embodiment is preferable 65 when ROM space is at a premium, since it eliminates a 256-byte table. However adding new byte codes to the set of supported byte codes has to be carefully thought out since Case: 13-1397 Document: 34 Page: 197 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 32 of 36 JA000140 Patent Lens enabling INNOVATION US 7,117,485 B2 15 the new byte codes have to fit in the implicit numbering scheme of the supported byte codes. 16 reference data types into references, thereby enabling access to unauthorized memory space, and violating security. With this invention, such an attempt by a card application 126z to use a non-reference data type as a reference will trigger a security violation 156. In conventional Java, this protected application environment is referred to as the sandbox appli- cation-interpretation environment. In another embodiment, the Card JVM 16 chooses not to perform any security checks in favor of Card JVM 16 execution speed. This is illustrated in the flowchart in FIG. 18. The flow chart in FIG. 18 is the same as that of FIG. 16 with the security checks removed. This option is not desir- able from the point of view of security, unless it can be guaranteed that the byte codes are secure. However, these firewall facilities do not work indepen- dently. In fact, the facilities are overlapping and mutually 10 reinforcing with conventional access control lists and encryption mechanisms shown in the following table: The Card JVM 16 may enforce other security checks as well. If the byte code may reference a local variable, the Card JVM 16 checks if this reference is valid, throwing an error if it is not. If the reference is valid, the Card JVM 16 stores the type of the local variable for future checking. The VM stack 144a pointer is checked to see if it is still in a valid 15 range. If not an exception is thrown. The byte code number is checked. If it is not supported, an exception is thrown. Finally, the byte code itself is dispatched 165d. The byte codes translated by the Card NM 16 are listed in Appendix C. The semantics of the byte codes are described in the 20 aforementioned Java Virtual Machine Specification with regard to the state of the VM stack 144a before and after the dispatch of the byte code. Note also that some byte codes (the byte codes, INVOKE STATIC, INVOKESPECIAL, INVOKENONVIRTUAL and INVOKEVIRTUAL) may 25 cause reentry into the Card NM 16, requiring processing to begin at the entry of the subroutine 161. FIG. 17 shows the flowchart of the byte code execution routine. The routine is given a byte code 171 to execute. The Card JVM 16 executes 172 the instructions required for the byte code. If in the 30 course of executing the Card NM 16 encounters a resource limitation 173, it returns an error 156. This error is returned to the terminal 16 by the Card NM 16. If the byte code executes successfully, it returns a success 175. Access Control Virtual Lists Machine Encryption Data access access only data to Protection control to own another before narnespace program operation encrypted Program access execution data Protection control only on encrypted in before correct program's execution types narnespace Communication access channel only mutnally Protection control on controls authenticated channels in own parties can narnespace communicate Taken together, these facilities isolate both data and applications on the integrated circuit card 10 and ensure that each card application 126 can access only the authorized resources of the integrated circuit card 10. Referring to FIG. 19, card applications 126x, 126y, 126z can be endowed with specific privileges when the card applications 126 execute. These privileges determine, for example, which data files the card applications 126 can access and what operations the card applications 126 can perform on the file system 147. The privileges granted to the card applications 126 are normally set at the time that a After execution, the type of the result is used to set the 35 VM stack 144a state correctly 165e, properly flagging the data types on the VM stack 144a. The byte code information gathered previously 165b from the byte code info table is used to set the state of the VM stack 144a in accordance with the byte code that just executed. 40 particular card application 126z is started by the user, typically from the terminal 14. In other embodiments, setting the output state of the VM stack 144a with respect to the byte code executed is sim- plified if the byte code is renumbered. This is shown in Appendix I which is hereby incorporated by reference. In yet another embodiment, the Card NM 16 may bypass 45 setting the output state of the VM stack 144a in favor of Card JVM 16 execution speed. This option is not desirable from the point of view of security, unless it can be guaran- teed that the byte codes are secure. After the byte code has been executed, the byte code is 50 retired 165/ This involves popping arguments off the VM stack 144a. Once byte code processing is completed, the loop 164 is repeated for the next byte code for the method. Once the dispatch loop 164 terminates, the VM stack 144a is emptied 166. This prevents any object references 55 filtering down to other Card JVM 16 invocations and breaking the Card NM's 16 security. Termination 167 of the byte code dispatch loop 164 indicates that the Card JVM 16 has completed executing the requested method. To isolate data and applications in the integrated circuit 60 card 10 from each other, the integrated circuit card 10 relies on the firewall mechanism 149 provided by the Card JVM 16. Because the Card NM implements the standard pass 3 and pass 4 verifier checks, it detects any attempt by an application to reference the data or code space used by 65 another application, and flag a security error 156. For example, conventional low level applications can cast non- The integrated circuit card 10 uses cryptographic identi- fication verification methods to associate an identity 190 (e.g., identities 190a, 190b and 190c) and hence, a set of privileges to the execution of the card application 126. The association of the specific identity 190c to the card appli- cation 126z is made when the card application 126z begins execution, thus creating a specific running application 200, as shown in FIG. 20. The identity 190 is a unique legible text string reliably associated with an identity token. The identity token (e.g., a personal identification number (PIN) or a RSA private key) is an encryption key. Referring to FIG. 20, in order to run a specific card application 126z, the identity 190c of the card application 126z must be authenticated. The identity 190c is authenti- cated by demonstrating knowledge of the identity token associated with the identity 190c. Therefore, in order to run the card application 126z, an agent (e.g., a card holder or another application wishing to run the application) must show that it possesses or knows the application's identity- defining encryption key. One way to demonstrate possession of an encryption key is simply to expose the key itself. PIN verification is an example of this form of authentication. Another way to demonstrate the possession of an encryption key without actually exposing the key itself is to show the ability to encrypt or decrypt plain text with the key. Case: 13-1397 Document: 34 Page: 198 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 33 of 36 JA000141 Patent Lens enabling INNOVATION US 7,117,485 B2 17 Thus, a specific running application 200 on the integrated circuit card 10 includes a card application 126z plus an authenticated identity 190c. No card application 126 can be rnn without both of these elements being in place. The card application 126z defines data processing operations to be performed, and the authenticated identity 190c determines on what computational objects those operations may be performed. For example, a specific application 126z can only access identity C's files 202 in the file system 147 associated with the specific identity 190c, and the specific 10 card application 126z cannot access other files 204 that are associated with identities other than the specific identity 190c. The integrated circuit card 10 may take additional steps to ensure application and data isolation. The integrated circuit 15 card 10 furnishes three software features sets: authenticated- 18 nor can the rogue terminal application "spoof' the card application into performing unauthorized operations on its behalf. Encryption and decryption of card/terminal traffic can be handled either by the card operating system 122 or by the card application itself 126z. In the former case, the commu- nication with the terminal 14 is being encrypted transpar- ently to the application, and message traffic arrives decrypted in the data space of the application. In the latter case, the card application 126z elects to perform encryption and decryption to provide an extra layer of security since the application could encrypt data as soon as it was created and would decrypt data only when it was about to be used. Otherwise, the data would remain encrypted with the session key 209. Thus, the application firewall includes three mutually reinforcing software-sets. Data files are protected by authen- ticated-identity access control lists. Application execution spaces are protected by the Card JVM 16. Communication identity access control lists; a Java-based virtual machine; and one-time session encryption keys to protect data files, application execution, and communication channels, respec- tively. Collectively, for one embodiment, these features sets provide the application data firewalls 149 for one embodi- ment. The following discusses each software feature set and then shows how the three sets work together to insure application and data isolation on the integrated circuit card 10. 20 channels are protected with one-time session encryption keys 209. An access control list (ACL) is associated with every computational object (e.g., a data file or a communication channel) on the integrated circuit card 10 that is be pro- tected, i.e., to which access is to be controlled. An entry on an ACL (for a particular computational object) is in a data format referred to as an e-tuple: In other embodiments, the above-described techniques are used with a micro controller (such as the processor 12) may control devices (e.g., part of an automobile engine) other 25 than an integrated circuit card. In these applications, the microcontroller provides a small platform (i.e., a central processing nnit, and a memory, both of which are located on a semiconductor substrate) for storing and executing high 30 type:identity:permissions The type field indicates the type of the following identity (in the identity field), e.g., a user (e.g., "John Smith"), or a 35 group. The permissions field indicates a list of operations (e.g., read, append and update) that can be performed by the identity on the computational object. As an example, for a data file that has the ACL entry: invention to provide the ability to program the microcon- troller using a high level language, and application of this invention to such devices is specifically included. The term application includes any program, such as Java applications, Java applets, Java aglets, Java servlets, Java commlets, Java components, and other non-Java programs that can result in class files as described below. Class files may have a source other than Java program USER:AcmeAirlines:RAU, any application whose identity is "AcmeAirlines" can read ("R"), append ("A") and update ("U") the data file. In addition, the ACL may be used selectively to permit the creation and deletion of data files. Furthermore, the ACL may be used selectively to permit execution of an applica- tion. 40 files. Several programming languages other than Java also have compilers or assemblers for generating class files from their respective source files. For example, the progrannning language Eiffel can be used to generate class files using Pirmin Kalberer's "J-Eiffel", an Eiffel compiler with JVM 45 byte code generation (web site: http:// www.spin.ch-kalberer/jive/index.htm). An Ada 95 to Java byte code translator is described in the following reference (incorporated herein by reference): Taft, S. Tucker, "Pro- gramming the Internet in Ada 95", proceedings of Ada Whenever a computational object is accessed by a run- ning application 200, the access is intercepted by the Card JVM 16 and passed to the card operating system 122, which determines if there is an ACL associated with the object. If there is an associated ACL, then the identity 190c associated with the running application 200 is matched on the ACL. If the identity is not found or if the identity is not permitted for the type of access that is being requested, then the access is denied. Otherwise, the access is allowed to proceed. 50 Europe '96, 1996. Jasmin is a Java byte code assembler that can be used to generate class files, as described in the following reference (incorporated herein by reference): Meyer, Jon and Troy Downing, "Java Virtual Machine", O'Reilly, 1997. Regardless of the source of the class files, 55 the above description applies to languages other than Java to generate codes to be interpreted. Referring to FIG. 13, to prevent the potential problems due to the single data path between the integrated circuit card 10 and the terminal 14, communication channel isola- tion is accomplished by including in the identity authenti- cation process the exchange of a one-time session key 209 60 between the a card application 126z and the terminal appli- cation 136. The key 209 is then used to encrypt subsequent traffic between the authenticating terminal application 136 and the authenticated card application 126z. Given the one-time session key 209, a rogue terminal application can 65 neither "listen in" on an authenticated communication between the terminal 14 and the integrated circuit card 10, FIG. 21 shows an integrated circuit card, or smart card, which includes a micro controller 210 that is mounted to a plastic card 212. The plastic card 212 has approximately the same form factor as a typical credit card. The commnnicator 12a can use a contact pad 214 to establish a communication channel, or the communicator 12a can use a wireless com- munication system. In other embodiments, a microcontroller 210 is mounted into a mobile or fixed telephone 220, effectively adding smart card capabilities to the telephone, as shown in FIG. 22. In these embodiments, the micro controller 210 is mounted Case: 13-1397 Document: 34 Page: 199 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 34 of 36 JA000142 Patent Lens enabling INNOVATION US 7,117,485 B2 19 on a module (such as a Subscriber Identity Module (SIM)), for insertion and removal from the telephone 220. In other embodiments, a micro controller 210 is added to a key ring 230 as shown in FIG. 23. This can be used to secure access to an automobile that is equipped to recognize the identity associated with the micro controller 210 on the key ring 230. 20 a) a compiler for compiling application source programs written in high level language source code form into a compiled form, and b) a converter for post processing the compiled form into a minimized form suitable for interpretation within the set of resource constraints by the interpreter. Jewelry such as a watch or ring 240 can also house a microcontroller 210 in an ergonomic manner, as shown in FIG. 24. Such embodiments typically use a wireless com- 10 munication system for establishing a communication chan- nel, and are a convenient way to implement access control with a minimum of hassle to the user. S. The micro controller of claim 7, wherein the compiled form includes attributes, and the converter comprises a means for including attributes required by the interpreter while not including the attributes not required by the inter- preter. 9. The microcontroller of claim 7 wherein the compiled form is in a standard Java class file format and the converter FIG. 25 illustrates a micro controller 210 mounted in an electrical subsystem 252 of an automobile 254. In this embodiment, the microcontroller is used for a variety of purposes, such as to controlling access to the automobile, (e.g. checking identity or sobriety before enabling the igni- tion system of the automobile), paying tolls via wireless commnnication, or interfacing with a global positioning system (GPS) to track the location of the automobile, to name a few. While specific embodiments of the present invention have been described, various modifications and substitutions will become apparent to one skilled in the art by this disclosure. Such modifications and substitutions are within the scope of the present invention, and are intended to be covered by the appended claims. What is claimed is: 1. A micro controller comprising: a memory storing; a derivative application derived from an application having a class file format wherein the application is derived from an application having a class file format by first compiling the application having a class file format into a compiled form and then converting the compiled form into a converted form, and accepts as input the compiled form in the standard Java class 15 file format and produces output in a form suitable for interpretation by the interpreter. 10. The microcontroller of claim 7 wherein the compiled form includes associating an identifying string for objects, classes, fields, or methods, and the converter comprises a 20 means for mapping such strings to unique identifiers. 11. The microcontroller of claim 10, wherein each unique identifier is an integer. 12. The micro controller of claim 10 wherein the mapping of strings to unique identifiers is stored in a string to 25 identifier map file. 13. The micro controller of claim 7 where in the high level language supports a first set of features and a first set of data types and the interpreter supports a subset of the first set of features and a subset of the first set of data types, and 30 wherein the converter verifies that the compiled form only contains features in the subset of the first set of features and only contains data types in the subset of the first set of data types. 14. The micro controller of claim 10 wherein the compiled 35 form is in a byte code format and the converter comprises means for translating from the byte codes in the compiled form to byte codes in a format suitable for interpretation by the interpreter by: an interpreter configured to interpret derivative appli- cations in the converted form and derived from 40 applications having a class file format; and using at least one step in a process including the steps: a) recording all jumps and their destinations in the origi- nal byte codes; a processor coupled to the memory, the processor con- figured to use the interpreter to interpret the derivative application for execution. b) converting specific byte codes into equivalent generic byte codes or vice-versa; 2. The microcontroller of claim 1, further comprising: a 45 commnnicator configured to communicate with a terminal. c) modifying byte code operands from references using identifYing strings to references using unique identifi- ers; and 3. The micro controller of claim 2, wherein the terminal has a card reader and the communicator comprises a contact for commnnicating with the card reader. 4. The micro controller of claim 3, wherein the terminal 50 has a wireless communicator and a wireless transceiver for d) renumbering byte codes in the compiled form to equivalent byte codes in the format suitable for inter- pretation; and relinking jumps for which destination address is effected by conversion step a), b), c), or d). commnnicating with the wireless communication device. 5. The micro controller of claim 3, wherein the terminal has a wireless commnnication device and the commnnicator comprises a wireless transmitter for commnnicating with the wireless commnnication device. 6. The micro controller of claim 1, wherein the class file format comprises a Java class file format. 7. A micro controller having a set of resource constraints and comprising: a memory, and an interpreter loaded in memory and operable within the set of resource constraints, the microcontroller having; 15. The micro controller of claim 7 wherein the applica- tion program is compiled into a compiled form for which resources required to execute or interpret the compiled form 55 exceed those available on the microcontroller. 16. The microcontroller of claim 7 wherein the compiled form is designed for portability on different computer plat- forms. 17. The microcontroller of claim 7 wherein the interpreter 60 is further configured to determine, during an interpretation of an application, whether the application meets a security criteria selected from a set of rules containing at least one rule selected from the set: at least one application loaded in the memory to be interpreted by the interpreter, wherein the at least one 65 application is generated by a programming environ- not allowing the application access to nnauthorized por- tions of memory, not allowing the application access to nnauthorized micro controller resources, ment comprising: Case: 13-1397 Document: 34 Page: 200 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 35 of 36 JA000143 Patent Lens enabling INNOVATION US 7,117,485 B2 21 wherein the application is composed of byte codes and checking a plurality of byte codes at least once prior to execution to verifY that execution of the byte codes does not violate a security constraint. 18. The micro controller of claim 7 wherein at least one application program is generated by a process including the steps of: prior to loading the application verifYing that the appli- cation does not violate any security constraints; and loading the application in a secure manner. 19. The microcontroller of claim 18 wherein the step of loading in a secure manner comprises the step of: verifYing that the loading identity has permission to load applications onto the micro controller. 10 20. The microcontroller of claim 18 wherein the step of 15 loading m a secure manner comprises the step of: encrypting the application to be loaded using a loading key. 21. A method of progranm1ing a microcontroller having a memory and a processor operating according to a set of 20 resource constraints, the method comprising the steps of: inputting an application program in a first progranm1ing language; compiling the application program in the first program- ming language into a first intermediate code associated 25 with the first programming language, wherein the first intermediate code being interpretable by at least one first intermediate code virtual machine; 22 27. The method of claim 25 further characterized by providing a decryption key and wherein the security proto- col requires that the second intermediate code is encrypted using a loading key corresponding to the decryption key. 28. A micro controller operable to execute derivative pro- grams which are derivatives of programs written in an interpretable programming language having a memory and an interpreter, the microcontroller comprising: (a) the micro controller operating within a set of resource constraints including the memory being of insufficient size to permit interpretation of programs written in the interpretable programming language; and (b) the memory containing an interpreter operable to interpret the derivative programs written in the deriva- tive of the interpretable language wherein a derivative of a program written in the interpretable progranm1ing language is derived from the compiled version of a program written in the interpretable progranm1ing lan- guage by applying a conversion of the compiled ver- sion including applying at least one rule selected from a set of rules including: (1) mapping strings to identifiers; (2) performing security checks prior to or during inter- pretation; (3) performing structural checks prior to or during interpretation; and (4) performing semantic checks prior to or during interpretation. converting the first intermediate code into a second inter- mediate code; wherein the second intermediate code is 30 interpretable within the set of resource constraints by at least one second intermediate code virtual machine; and 29. The micro controller of claim 28 wherein the deriva- tive programs are class files or derivatives of class files. 30. The micro controller of claim 28 further comprising: the memory containing less than 1 megabyte of storage. 31. The micro controller of claim 28 wherein the security 35 checks the micro controller is further comprising: loading the second intermediate code into the memory of the microcontroller. (c) logic to receive a request from a requester to access one of a plurality of derivative programs; 22. The method of programming a microcontroller of claim 21 wherein the step of converting further comprises: associating an identifying string for objects, classes, fields, or methods; and mapping such strings to unique 40 identifiers. 23. The method of claim 22 wherein the step of mapping comprises the step of mapping strings to integers. (d) after receipt of the request, determine whether the one of a plurality of derivative programs compiles with a predetermined set of rules; and ( e) based on the determination, selectively grant access to the requester to the one of the plurality of applications. 32. The microcontroller of claim 31, wherein the prede- termined rules are enforced by the interpreter while the 24. The method of claim 21 wherein the step of converting comprises at least one of the steps of: a) recording all jumps and their destinations in the origi- nal byte codes; b) converting specific byte codes into equivalent generic byte codes or vice-versa; 45 derivative program is being interpreted by determining whether the derivative program has access rights to a particular part of memory the derivative program is attempt- ing to access. c) modifYing byte code operands from references using 50 identifying strings to references using unique identifi- ers; d) renumbering byte codes in a compiled format to equivalent byte codes in a format suitable for interpre- tation; and e) relinking jumps for which destination address is effected by conversion step a), b), c), or d). 55 25. The method of claim 21 wherein the step of loading the second intermediate code into the memory of the micro- controller further comprises checking the second interme- 60 diate code prior to loading the second intermediate code to verify that the second intermediate code meets a predefined integrity check and that loading is performed according to a security protocol. 26. The method of claim 25 wherein the security protocol 65 requires that a particular identity must be validated to permit loading prior to the loading of the second intermediate code. 33. The micro controller of claim 28 further wherein the microcontroller is configured to perform at least one security check selected from the set having the members: (a) enforcing predetermined security rules while the derivative program is being interpreted, thereby pre- venting the derivative program from accessing unau- thorized portions of memory or other unauthorized micro controller resources, (b) the interpreter being configured to check each byte- code at least once prior to execution to determine that the bytecode can be executed in accordance with pre- execution and post-execution checks, and (c) the derivative program is checked prior to being loaded into the micro controller to verify the integrity of the derivative program and loading is performed according to a security protocol. 34. The micro controller of claim 33 wherein the security protocol requires that a particular identity must be validated to permit loading a derivative program onto a card. Case: 13-1397 Document: 34 Page: 201 Filed: 07/09/2013 http://www.patentlens.net/ Case 6:10-cv-00561-LED Document 1-2 Filed 10/22/10 Page 36 of 36 JA000144 Patent Lens enabling INNOVATION US 7,117,485 B2 23 35. The microcontroller of claim 33 further comprising a decryption key wherein the security protocol requires that a derivative program to be loaded is encrypted using a loading key corresponding to the decryption key. 24 using a communicator of the card when communicating between the processor and the terminal. 41. The method of claim 40 wherein the converting step further comprises: recording all jumps and their destinations in the original byte codes; converting specific byte codes into equivalent generic byte codes or vice-versa; and 36. The micro controller of claim 28 wherein the micro- controller is configured to provide cryptographic services selected from the set including encryption, decryption, sign- ing, signature verification, mutual authentication, transport keys, and session keys. 37. The microcontroller of claim 28 further comprising a file system and wherein the micro controller is configured to provide secure access to the file system through a means selected from the set including: 10 renumbering byte codes in a compiled format to equivalent byte codes in a format suitable for interpretation. (a) the microcontroller having access control lists for authorizing reading from a file, writing to a file, or 15 deletion of a file, (b) the micro controller enforcing key validation to estab- lish the authorized access to a file, and (c) the micro controller verifYing card holder identity to establish the authorized access to a file. 38. An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the terminal; a memory storing: 20 25 an application derived from a program written in a high level programming language format wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form and 30 then converting the compiled form into a converted form, the converting step including modifying byte code operands from references using identifying strings to references using unique identifiers; and an interpreter operable to interpret such a derivative 35 application in the converted form and derived from a program written in a high level progranlilling language format; and a processor coupled to the memory, the processor con- figured to use the interpreter to interpret the application 40 for execution and to use the communicator to commu- nicate with the terminal. 39. The integrated circuit card of claim 38 wherein the converting step further comprises: recording all jumps and their destinations in the original 45 byte codes; converting specific byte codes into equivalent generic byte codes or vice-versa; and 42. An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the terminal; a memory storing: applications, each application derived from applica- tions having a high level programming language format, and an interpreter operable to interpret applications derived from applications having a high level progranlilling language format wherein the appli- cation is derived from a program written in a high level programming language format by first com- piling the program into a compiled form and then converting the compiled form into a converted form, the converting step including modifying byte code operands from references using identi- fYing strings to references using unique identifi- ers; and a processor coupled to the memory, the processor con- figured to: a.) use the interpreter to interpret the applications for execution, b.) use the interpreter to create a firewall to isolate the applications from each other, and c.) use the communicator to communicate with the terminal. 43. The integrated circuit card of claim 42 wherein the interpreter is further operable to interpret applications derived using a converting step including: recording all jumps and their destinations in the original byte codes; converting specific byte codes into equivalent generic byte codes or vice-versa; and renumbering byte codes in a compiled format to equivalent byte codes in a format suitable for interpretation. renumbering byte codes in a compiled format to equivalent byte codes in a format suitable for interpretation. 50 44. A micro controller operable to execute derivative pro- grams which are derivatives of programs written in an interpretable programming language having a memory and an interpreter, the microcontroller comprising: 40. A method for use with an integrated circuit card and a terminal, comprising: storing an interpreter operable to interpret programs derived from programs written in a high level program- ming language and an application derived from a 55 program written in a high level programming language format in a memory of the integrated circuit card wherein the application is derived from a program written in a high level programming language format by first compiling the program into a compiled form 60 and then converting the compiled form into a converted form, the converting step including modifYing byte code operands from references using identifYing strings to references using unique identifiers; and using a processor of the integrated circuit card to use the 65 interpreter to interpret the application for execution; and the micro controller operating within a set of resource constraints including the memory being of insufficient size to permit interpretation of programs written in the interpretable programming language; and the memory containing an interpreter operable to interpret the derivative programs written in the derivative of the interpretable language wherein a derivative of a pro- gram written in the interpretable programming lan- guage is derived from a compiled form of the program written in the interpretable programming language by performing a conversion including mapping strings to identifiers. * * * * * Case: 13-1397 Document: 34 Page: 202 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 1 of 35 JA000145 (12) United States Patent Wilkinson et al. (54) USING A HIGH LEVEL PROGRAMMING LANGUAGE WITH A MICROCONTROLLER (75) Inventors: Timothy J. Wilkinson, London (GB); Scott B. Guthery, Belmont, MA (US); Ksheerabdhi Krishna, Cedar Park, TX (US); Michael A. Montgomery, Cedar Park, TX (US) (73) Assignee: Gemalto Inc., Austin, TX (US) ( *) Notice: Subject to any disclaimer, the term of this patent is extended or adjusted under 35 U.S.c. 154(b) by 1016 days. This patent is subject to a tenninal dis- claimer. (21) Appl. No.: 11/537,156 (22) Filed: Sep.29,2006 (65) (63) Prior Publication Data US 200S/0115117 Al May 15, 200S Related U.S. Application Data Continuation of application No. 10/037,390, filed on Oct. 23, 2001, now Pat. No. 7,117,4S5, which is a continuation of application No. OS/957,512, filed on Oct. 24,1997, now Pat. No. 6,30S,317. Execution Control Interpret method Report Success 111111111111111111111111111111111111111111111111111111111111111111111111111 NO US007818727B2 (10) Patent No.: US 7,818,727 B2 *Oct. 19,2010 (45) Date of Patent: (60) Provisional application No. 601029,057, filed on Oct. 25, 1996. (51) Int. Cl. G06F 9/45 (2006.01) (52) U.S. Cl. ...................................................... 717/139 (5S) Field of Classification Search .................. 717/139 See application file for complete search history. (56) References Cited U.S. PATENT DOCUMENTS 6,308,317 Bl * 10/2001 Wilkinson et al. .......... 717/139 2005/0097550 Al * 5/2005 Schwabe et al. ............ 717/178 2008/0282238 Al * 1112008 Meijeretal. ................ 717/162 * cited by examiner Primary Examiner-John Chavis (74) Attorney, Agent, or Firm-Pehr B. Jansson; The Jansson Firm (57) ABSTRACT An integrated circuit card is used with a tenninal. The inte- grated circuit card includes a memory that stores an inter- preter and an application that has a high level programming language format. A processor of the card is configured to use the interpreter to interpret the application for execution and to use a communicator of the card to communicate with the tenninal. 20 Claims, 23 Drawing Sheets ~ - - - - - L - 126z Card Application 155 Case: 13-1397 Document: 34 Page: 203 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 2 of 35 JA000146 u.s. Patent Oct. 19,2010 Sheet 1 of23 US 7,818,727 B2 Integrated Circuit Card 10 " 16\ Card Java Virtual Machine (Card JVM) 12a Communicator 14\ 12b"\ Terminal Communicator Terminal FIGURE 1 Case: 13-1397 Document: 34 Page: 204 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 3 of 35 JA000147 u.s. Patent Oct. 19,2010 Card Class File (contains Classes A, B, and C) Sheet 2 of23 Card Loader FIGURE 2 28 US 7,818,727 B2 22 Java Application Development Environment Card Class File Converter Integrated Circuit Card 26 10 Case: 13-1397 Document: 34 Page: 205 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 4 of 35 JA000148 u.s. Patent Oct. 19,2010 Card Class File (contains Classes A, 8, and C) 26 Sheet 3 of23 Card Class File Converter FIGURE 3 US 7,818,727 B2 String To 10 Input Map String To 10 Output Map Case: 13-1397 Document: 34 Page: 206 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 5 of 35 JA000149 u.s. Patent Oct. 19,2010 Application Class Files
Class File Information 4 1 Class File Information 42 Class Constant Pool - Contains all the strings corresponding to Fields methods and Class names referred to in the Java program 43 Class, field, Interface and Method Information 44 Attribute Information r+-Source File Attribute Value Attribute Code Attribute Attribute +-Line Number Table Attribute I+-Local Variable Table Attribute r+-Optional Vendor Attributes \.. 24a Sheet 4 of23 US 7,818,727 B2 r 24 Card Class File r2 - +I Card Class File Information Optimized Card Class r Constant Pool where -c. each string is replaced by an 10 Card Class, Card Field, r Card Interface and Card I Method Information Card Attribute Information r Code Attribute r r+ (optionally translated) y 24b,c r 45 Eliminated I FIGURE 4 7 46 47 48 49 Case: 13-1397 Document: 34 Page: 207 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 6 of 35 JA000150 u.s. Patent Oct. 19,2010 Sheet 5 of23 US 7,818,727 B2 51a Select A Classfile 51b Compact Constant Pool 51c Check For Unsupported Features 51d Discard Unnecessary Parts YES Modify The byte codes 56 Gather All Constant Pool Entries and Modified byte codes Generate Card Class File and 57 String to 10 map (if required) Flag Errors and Stop Conversion 27 FIGURE 5 Case: 13-1397 Document: 34 Page: 208 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 7 of 35 JA000151 u.s. Patent Oct. 19,2010 Sheet 6 of23 US 7,818,727 B2 PASS 1: List all jumps and their destinations 62 NO PASS 3: Relink References 65 NO PASS 4: Modify Java byte codes to Card JVM byte codes PASS 5: Readjust Jumps FIGURE 6 Case: 13-1397 Document: 34 Page: 209 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 8 of 35 JA000152 u.s. Patent 0: 1 : 2: 3: 4: ;- I LOAD_O I LOAD_1 IFNE 1: BIPUSH 5 Oct. 19,2010 Sheet 7 of23 70 - -- --- --- FIGURE 7 --- 0: 1 : --- 2: - - - - _ 3: -- 4: 5: 6: US 7,818,727 B2 ;72 I LOAD 0 ILOAD 1 IFNE 2: BIPUSH 5 Case: 13-1397 Document: 34 Page: 210 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 9 of 35 JA000153 u.s. Patent ~ c co ~ I (J) :::> a... - OJ 0 Cl -l Oct. 19,2010 co ~ A ~ ..-... x (]) -C c: .- --- L() C") Sheet 8 of23 o o o co ('f) o o o 0 0 0 CO ~ L- <D C) (]) +oJ C - 0 0 0 US 7,818,727 B2 co W c:::: :J 0 (!) - 0 u. (L ...... C 11 CO ...... en c 0 U Q) i+= CJ) CJ) CO U Case: 13-1397 Document: 34 Page: 211 Filed: 07/09/2013 C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 3
F i l e d
1 0 / 2 2 / 1 0
P a g e
1 0
o f
3 5 J A 0 0 0 1 5 4 90 INVOKESTATIC INVOKESTATIC : 89 (index) 13 (index) 1 o 0 0 89 90 91 92 o 0 0 o 0 0 13 14 15 16 0 0 0 o 0 0 main I (V)V I I 0 0 0 Flag (ref) (ref) ) 42 o 0 0 F0011 FFF31 I 0 0 0 477 Class file Constant Pool Card Class file Constant Pool FIGURE 9
7Jl .
=
o (') :-+- ....
N o .... o rFJ =- ('D ('D ..... '-CI o .... N (.H d rJl -....l 00 """'" QO
N -....l = N Case: 13-1397 Document: 34 Page: 212 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 11 of 35 JA000155 u.s. Patent Oct. 19,2010 Sheet 10 of 23 I 100 0: 1 : 2: 3: 4: 5: 6: ALOAD43 0 ILOAD 21 1 IFNE 1542: SIPUSH 16 5 FIGURE 10 0: 1 : 2: 3: 4: 5: 6: US 7,818,727 B2 / 102 ALOAD 51 0 ILOAD 50 1 IFNE 272: SIPUSH 49 5 Case: 13-1397 Document: 34 Page: 213 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 12 of 35 JA000156 u.s. Patent Oct. 19,2010 / 112 ILOAD 8 o a 0 11- 114 --------- --------- o --------- o --------- o --------- 5 --------- - - - - - - - - - o 0 0 Word-Based Operand Stack Sheet 11 of 23 US 7,818,727 B2 / 116 I LOAD_B .. 8 v- 118 a a a 5 0 0 a Byte-Based Operand Stack FIGURE 11 Case: 13-1397 Document: 34 Page: 214 Filed: 07/09/2013 C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 3
F i l e d
1 0 / 2 2 / 1 0
P a g e
1 3
o f
3 5 J A 0 0 0 1 5 7 Card Loader 10 28 120 Loading And Execution Control Integrated Circuit Card Card Operating System Card File System FIGURE 12 124 ~ 7Jl . ~ ~ ~ ~ =
o (') :-+- .... ~ ' - C I N o .... o rFJ =- ('D ('D ..... .... N o .... N (.H d rJl -....l 00 """'" QO ~ N -....l = N Case: 13-1397 Document: 34 Page: 215 Filed: 07/09/2013 C a s e
o (') :-+- .... ~ ' - C I N o .... o rFJ =- ('D ('D ..... .... (.H o .... N (.H d rJl -....l 00 """'" QO ~ N -....l = N Case: 13-1397 Document: 34 Page: 216 Filed: 07/09/2013 C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 3
F i l e d
1 0 / 2 2 / 1 0
P a g e
1 5
o f
3 5 J A 0 0 0 1 5 9 - - ---------------------. 144c RAM Heap ______ - - - - - - - - - - -- -- -j "EEPROM Heap 146a System Stack 148\ I File System V 147 VM Stack /141a I LOADABLE APPLCATION A I 144a _f /141b Il System : LOADABLE APPLCATION B I Variables "-- 144b /141C Card RAM "-- 141 LOADABLE CLASS LIBRARY I Card ROM ;' 140 EEPROM Program Area Card EEPROM "-142 Loading And Execution Control \-120 APPLICATION I L-- I nstruction Dispatch Loop * \..150 149\, \. 140a Run - Time Instruction 16 J 145..1 Support Support I CLASS LIBRARY I \..165d \.. 140b Card JVM i 148 J I Card Operating System 122 ROM Program Area /149 1/149 Ir 149 FIGU RE 14
7Jl .
=
o (') :-+- ....
N o .... o rFJ =- ('D ('D ..... .... .j;o. o .... N (.H d rJl -....l 00 """'" QO
N -....l = N Case: 13-1397 Document: 34 Page: 217 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 16 of 35 JA000160 u.s. Patent Oct. 19,2010 Execution Control Find Entry point class 10/method 10 Interpret method Report Success Sheet 15 of 23 152 153 NO FIGURE 15 US 7,818,727 B2 Stop Card JVM Case: 13-1397 Document: 34 Page: 218 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 17 of 35 JA000161 u.s. Patent Oct. 19,2010 Sheet 16 of 23 US 7,818,727 B2 160 Set VM stack Parameters Set Card JVM program Counter YES 163 Handle native method NO Place return value on VM Stack Finished interpreting method? ~ " ' - - - - - , 1658\ Prepare for branch Retrieve next byte code/type information 165b Check VM stack state (Pass 3 security checks) 165c Execute byte code 165d Set VM stack state 165e 165f Retire the byte code FIGURE 16 Case: 13-1397 Document: 34 Page: 219 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 18 of 35 JA000162 u.s. Patent Oct. 19,2010 Sheet 17 of 23 171 a byte code 172 execute bytecode YES 175 Report Success FIGURE 17 NO US 7,818,727 B2 Stop Card JVM and Send error to terminal Case: 13-1397 Document: 34 Page: 220 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 19 of 35 JA000163 u.s. Patent Oct. 19,2010 Sheet 18 of 23 US 7,818,727 B2 160 Set VM stack Parameters Set Card JVM program Counter YES 163 Handle native method NO Place return value 0 n VM Stack YES Retrieve next byte code 165b Execute byte code 165d FIGURE 18 Case: 13-1397 Document: 34 Page: 221 Filed: 07/09/2013 C a s e
6 : 1 0 - c v - 0 0 5 6 1 - L E D
D o c u m e n t
1 - 3
F i l e d
1 0 / 2 2 / 1 0
P a g e
2 0
o f
3 5 J A 0 0 0 1 6 4 126 \ 126X\ 126y\ Card Card Application Application X y / 190 \ 190a\ 7 190b\ / Identity Identity A B FIGURE 19 1262\ Card Application Z / 190C\ Identity C --- I I ! ~ 7Jl . ~ ~ ~ ~ =
o (') :-+- .... ~ ' - C I N o .... o rFJ =- ('D ('D ..... .... '-CI o .... N (.H d rJl -....l 00 """'" QO ~ N -....l = N Case: 13-1397 Document: 34 Page: 222 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 21 of 35 JA000165 u.s. Patent Oct. 19,2010 Sheet 20 of 23 US 7,818,727 B2 200 \ Card V 126Z Run Program C Application Z V190C Identity Enter PIN of A C , , , , , , Access Not , .- , Allowed .-'- .- .- , / , 204\ .- 202\ If .- Other Identity Files C's Files FIGURE 20 Case: 13-1397 Document: 34 Page: 223 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 22 of 35 JA000166 u.s. Patent Oct. 19,2010 Sheet 21 of 23 US 7,818,727 B2 10 FIGURE 21 220 210 FIGURE 22 Case: 13-1397 Document: 34 Page: 224 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 23 of 35 JA000167 u.s. Patent Oct. 19,2010 Sheet 22 of 23 US 7,818,727 B2 FIGURE 23 240 FIGURE 24 Case: 13-1397 Document: 34 Page: 225 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 24 of 35 JA000168 u.s. Patent Oct. 19,2010 Sheet 23 of 23 US 7,818,727 B2 It) N W 0:: ::) (!) - LL Case: 13-1397 Document: 34 Page: 226 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 25 of 35 JA000169 US 7,818,727 B2 1 USING A HIGH LEVEL PROGRAMMING LANGUAGE WITH A MICROCONTROLLER CROSS REFERENCE TO RELATED APPLICATIONS This application is a continuation application, under 35 U.S.c. 120, of application Ser. No. 10/037,390, filed Oct. 23,2001, now U.S. Pat. No. 7,117,485, which is a continua- tion application, under 35 U.S.c. 120, of application Ser. No. 08/957,512, filed Oct. 24, 1997, now U.S. Pat. No. 6,308, 317, which, under 35 U.S.c. 119( e), claims benefit of prior U.S. provisional application Ser. No. 601029,057, filed Oct. 25,1996. RESERVATION OF COPYRIGHTS A portion of the disclosure of this patent document con- tains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduc- tion by anyone of the patent document or the patent disclo- sure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. BACKGROUND OF THE INVENTION This invention relates in general to the field of program- ming, and more particularly to using a high level program- ming language with a smart card or a micro controller. Software applications written in the Java high-level pro- gramming language have been so designed that an application written in Java can be run on many different computer brands or computer platforms without change. This is accomplished by the following procedure. When a Java application is writ- ten, it is compiled into "Class" files containing byte codes that are instructions for a hypothetical computer called a Java Virtual Machine. An implementation of this virtual machine is written for each platform that is supported. When a user wishes to run a particular Java application on a selected plat- form, the class files compiled from the desired application is loaded onto the selected platform. The Java virtual machine for the selected platform is run, and interprets the byte codes in the class file, thus effectively running the Java application. 2 tional Java implementations on microcontrollers, as would typically be used in a smart card. Microcontrollers differ from microprocessors in many ways. For example, a microprocessor typically has a central processing unit that requires certain external components (e.g., memory, input controls and output controls) to function properly. A typical microprocessor can access from a mega- byte to a gigabyte of memory, and is capable of processing 16, 32, or 64 bits of information or more with a single instruction. 10 In contrast to the microprocessor, a microcontroller includes a central processing unit, memory and other functional ele- ments, all on a single semiconductor substrate, or integrated circuit (e.g., a "chip"). As compared to the relatively large external memory accessed by the microprocessor, the typical 15 microcontroller accesses a much smaller memory. A typical microcontroller can access one to sixty-four kilobytes of built-in memory, with sixteen kilobytes being very common. There are generally three different types of memory used: random access memory (RAM), read only memory (ROM), 20 and electrically erasable progranlillable read only memory (EEPROM). In a micro controller, the amount of each kind of memory available is constrained by the amount of space on the integrated circuit used for each kind of memory. Typically, RAM takes the most space, and is in shortest supply. ROM 25 takes the least space, and is abundant. EEPROM is more abundant than RAM, but less than ROM. Each kind of memory is suitable for different purposes. Although ROM is the least expensive, it is suitable only for data that is unchanging, such as operating system code. 30 EEPROM is useful for storing data that must be retained when power is removed, but is extremely slow to write. RAM can be written and read at high speed, but is expensive and data in RAM is lost when power is removed. A microproces- sor system typically has relatively little ROM and EEPROM, 35 and has 1 to 128 megabytes of RAM, since it is not con- strained by what will fit on a single integrated circuit device, and often has access to an external disk memory system that serves as a large writable, non-volatile storage area at a lower cost than EEPROM. However, a microcontrollertypically has 40 a small RAM of 0.1 to 2.0 K, 2K to 8K of EEPROM, and 8K-56K of ROM. Java is described in the following references which are 45 hereby incorporated by reference: (1 ) Arnold, Ken, and James Gosling, "The Java Programming Language," Addison-Wes- ley, 1996; (2) James Gosling, Bill Joy, and Guy Steele, "The Java Language Specification," Sun Microsystems, 1996, (web site: http://java.sun.com/doc/language_specification); 50 (3) James Gosling and Henry McGilton, "The Java Language Environment: A White Paper," Sun Microsystems, 1995 (web site: http://java.sun.com/doc/language_environment/); and Due to the small number of external components required and their small size, micro controllers frequently are used in integrated circuit cards, such as smart cards. Such smart cards come in a variety of forms, including contact-based cards, which must be inserted into a reader to be used, and contact- less cards, which need not be inserted. In fact, microcontrol- lers with contactless communication are often embedded into specialized forms, such as watches and rings, effectively inte- grating the functionality of a smart card in an ergonomically attractive mauner. Because of the constrained environment, applications for smart cards are typically written in a low level progranlilling language (e.g., assembly language) to conserve memory. (4) Tim Lindholm and Frank Yellin, "The Java Virtual Machine Specification," Addison-Wesley, 1997. These texts 55 among many others describe how to program using Java. In order for a Java application to run on a specific platform, a Java virtual machine implementation must be written that will run within the constraints of the platform, and a mecha- nism must be provided for loading the desired Java applica- 60 tion on the platform, again keeping within the constraints of this platform. Conventional platforms that support Java are typically microprocessor-based computers, with access to relatively large amounts of memory and hard disk storage space. Such 65 microprocessor implementations frequently are used in desk- top and personal computers. However, there are no conven- The integrated circuit card is a secure, robust, tamper- resistant and portable device for storing data. The integrated circuit card is the most personal of personal computers because of its small size and because of the hardware and software data security features unique to the integrated circuit card. The primary task of the integrated circuit card and the microcontroller on the card is to protect the data stored on the card. Consequently, since its invention in 1974, integrated circuit card technology has been closely guarded on these same security grounds. The cards were first used by French banks as debit cards. In this application, before a financial transaction based on the card is authorized, the card user must Case: 13-1397 Document: 34 Page: 227 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 26 of 35 JA000170 US 7,818,727 B2 3 demonstrate knowledge of a 4-digit personal identification number (PIN) stored in the card in addition to being in pos- session of the card. Any infonnation that might contribute to discovering the PIN number on a lost or stolen card was blocked from public distribution. In fact, since nobody could tell what information might be useful in this regard, virtually all information about integrated circuit cards was withheld. 4 data by the security features provided by the Java virtual machine. Smart card applications can be created in high level languages such as Java and Eiffel, using powerful mainstream program development tools. New applications can be quickly prototyped and downloaded to a smart card in a matter of hours without resorting to soft masks. Embedded systems using micro controllers can also gain many of these advan- tages for downloading new applications, high level program development, and rapid prototyping by making use of this invention. Implementations of the invention may include one or more of the following. The high level programming language for- mat of the application may have a class file format and may have a Java programming language format. The processor may be a micro controller. At least a portion of the memory may be located in the processor. Due to the concern for security, applications written for integrated circuit cards have unique properties. For example, each application typically is identified with a particular owner 10 or identity. Because applications typically are written in a low-level programming language, such as assembly lan- guage, the applications are written for a particular type of microcontroller. Due to the nature of low level programming languages, unauthorized applications may access data on the 15 integrated circuit card. Programs written for an integrated circuit card are identified with a particular identity so that if two identities want to perfonn the same programming func- tion there must be two copies of some portions of the appli- cation on the micro controller of the integrated circuit card The application may have been processed from a second application that has a string of characters, and the string of characters may be represented in the first application by an 20 identifier (e.g., an integer). Integrated circuit card systems have historically been closed systems. An integrated circuit card contained a dedi- cated application that was handcrafted to work with a specific terminal application. Security checking when an integrated circuit card was used consisted primarily of making sure that 25 the card application and the tenninal application were a matched pair and that the data on the card was valid. As the popularity of integrated circuit cards grew, it became clear that integrated circuit card users would be averse to carrying a different integrated circuit card for each 30 integrated circuit card application. Therefore, multiple coop- erating applications began to be provided on single provider integrated circuit cards. Thus, for example, an automated teller machine (ATM) access card and a debit card may coex- ist on a single integrated circuit card platform. Nevertheless, 35 this was still a closed system since all the applications in the terminal and the card were built by one provider having explicit knowledge of the other providers. The paucity ofinfonnation about integrated circuit cards- particularly information about how to communicate with 40 them and how to program them-has impeded the general application of the integrated circuit card. However, the advent of public digital networking (e.g., the Internet and the World Wide Web) has opened new domains of application for inte- grated circuit cards. In particular, this has lead to a need to 45 load new applications on the card that do not have explicit knowledge of the other providers, but without the possibility The processor may be also configured to receive a request from a requester (e.g., a processor or a terminal) to access an element (e.g., an application stored in the memory, data stored in the memory or the communicator) of the card, after receipt of the request, interact with the requester to authenticate an identity of the requester, and based on the identity, selectively grant access to the element. The memory may also store an access control list for the element. The access control list furnishes an indication of types of access to be granted to the identity, and based on the access control list, the processor selectively grants specific types of access (e.g., reading data, writing data, appending data, creating data, deleting data or executing an application) to the requester. The application may be one of a several applications stored in the memory. The processor may be further configured to receive a request from a requester to access one of the plural- ity of applications; after receipt of the request, detennine whether said one of the plurality of applications complies with a predetennined set of rules; and based on the detenni- nation, selectively grant access to the requester to said one of the plurality of applications. The predetermined rules provide a guide for detennining whether said one of the plurality of applications accesses a predetennined region of the memory. The processor may be further configured to authenticate an identity of the requester and grant access to said one of the plurality of applications based on the identity. of compromising the security of the card. However, typically, this is not practical with conventional cards that are pro- grammed using low level languages. SUMMARY OF THE INVENTION The processor may be also configured to interact with the tenninal via the communicator to authenticate an identity; 50 determine if the identity has been authenticated; and based on the determination, selectively allow communication between the tenninal and the integrated circuit card. In general, in one aspect, the invention features an inte- grated circuit card for use with a terminal. The integrated circuit card includes a memory that stores an interpreter and an application that has a high level programming language format. A processor of the card is configured to use the inter- preter to interpret the application for execution and to use a communicator of the Among the advantages of the invention are one or more of the following. New applications may be downloaded to a smart card without compromising the security of the smart card. These applications may be provided by different com- panies loaded at different times using different tenninals. Security is not compromised since the applications are pro- tected against unauthorized access of any application code or The communicator and the terminal may communicate via communication channels. The processor may also be config- 55 ured to assign one of the communication charmels to the identity when the processor allows the communication between the terminal and the integrated circuit card. The processor may also be configured to assign a session key to the assigned communication charmel and use the session key 60 when the processor and the tenninal communicate via the assigned communication charmel. The tenninal may have a card reader, and the communica- tor may include a contact for communicating with the card reader. The tenninal may have a wireless communication 65 device, and the communicator may include a wireless trans- ceiver for communicating with the wireless communication device. The terminal may have a wireless communication Case: 13-1397 Document: 34 Page: 228 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 27 of 35 JA000171 US 7,818,727 B2 5 device, and the communicator may include a wireless trans- mitter for communicating with the wireless communication device. In general, in another aspect, the invention features a method for use with an integrated circuit card and a terminal. The method includes storing an interpreter and at least one application having a high level programming language for- mat in a memory of the integrated circuit card. A processor of the integrated circuit card uses the interpreter to interpret the at least one application for execution, and the processor uses 10 a communicator of the card when communicating between the processor and the terminal. In general, in another aspect, the invention features a smart card. The smart card includes a memory that stores a Java interpreter and a processor that is configured to use the inter- 15 preter to interpret a Java application for execution. In general, in another aspect, the invention features a microcontroller that has a semiconductor substrate and a memory located in the substrate. A programming language interpreter is stored in the memory and is configured to imp le- 20 ment security checks. A central processing unit is located in the substrate and is coupled to the memory. Implementations of the invention may include one or more of the following. The interpreter may be a Java byte code interpreter. The security checks may include establishing fire- 25 walls and may include enforcing a sandbox security model. In general, in another aspect, the invention features a smart card that has a programming language interpreter stored in a memory of the card. The interpreter is configured to imple- ment security check. A central processing unit of the card is 30 coupled to the memory. In general, in another aspect, the invention features an integrated circuit card that is used with a terminal. The card includes a communicator and a memory that stores an inter- preter and first instructions of a first application. The first 35 instructions have been converted from second instructions of 6 cation that has been processed from a second application having a string of characters. The string of characters are represented in the first application by an identifier. The inte- grated circuit card includes a processor that is coupled to the memory. The processor is configured to use the interpreter to interpret the first application for execution and to use the communicator to communicate with the terminal. In general, in another aspect, the invention features a method for use with an integrated circuit card and a terminal. The method includes processing a second application to cre- ate a first application. The second application has a string of characters. The string of characters is represented by an iden- tifier in the second application. An interpreter and the first application are stored in a memory of the integrated circuit card. A processor uses an interpreter to interpret the first application for execution. In general, in another aspect, the invention features a microcontroller that includes a memory which stores an application and an interpreter. The application has a class file format. A processor of the microcontroller is coupled to the memory and is configured to use the interpreter to interpret the application for execution. In implementations of the invention, the micro controller may also include a communicator that is configured to com- municate with a terminal. In general, in another aspect, the invention features a method for use with an integrated circuit card. The method includes storing a first application in a memory of the inte- grated circuit card, storing a second application in the memory of the integrated circuit card, and creating a firewall that isolates the first and second applications so that the sec- ond application cannot access either the first application or data associated with the first application. In general, in another aspect, the invention features an integrated circuit card for use with a terminal. The integrated circuit card includes a communicator that is configured to communicate with the terminal, a memory and a processor. The memory stores applications, and each application has a high level programming language format. The memory also a second application. The integrated circuit card includes a processor that is coupled to the memory and is configured to use the interpreter to execute the first instructions and to communicate with the terminal via the communicator. Implementations of the invention may include one or more 40 stores an interpreter. The processor is coupled to the memory and is configured to: a.) use the interpreter to interpret the applications for execution, b.) use the interpreter to create a firewall to isolate the applications from each other, and c.) use of the following. The first and/or second applications may have class file format(s). The first and/or second applications may include byte codes, such as Java byte codes. The first instructions may be generalized or renumbered versions of 45 the second instructions. The second instructions may include constant references, and the first instructions may include constants that replace the constant references of the second instructions. The second instructions may include references, and the references may shift location during the conversion of 50 the second instructions to the first instructions. The first instructions may be relinked to the references after the shift- ing. The first instructions may include byte codes for a first type of virtual machine, and the second instructions may include byte codes for a second type of virtual machine. The 55 first type is different from the second type. In general, in another aspect, the invention features a method for use with an integrated circuit card. The method includes converting second instructions of a second applica- tion to first instructions of a first application; storing the first 60 instructions in a memory of the integrated circuit card; and using an interpreter of the integrated circuit card to execute the first instructions. the communicator to communicate with the terminal. Other advantages and features will become apparent from the following description and from the claims. BRIEF DESCRIPTION OF THE DRAWING FIG. 1 is a block diagram of an integrated card system. FIG. 2 is a flow diagram illustrating the preparation of Java applications to be downloaded to an integrated circuit card. FIG. 3 is a block diagram of the files used and generated by the card class file converter. FIG. 4 is a block diagram illustrating the transformation of application class file( s) into a card class file. FIG. 5 is a flow diagram illustrating the working of the class file converter. FIG. 6 is a flow diagram illustrating the modification of the byte codes. FIG. 7 is a block diagram illustrating the transformation of specific byte codes into general byte codes. In general, in another aspect, the invention features an integrated circuit for use with a terminal. The integrated cir- cuit card has a communicator that is configured to communi- cate with the terminal and a memory that stores a first appli- FIG. 8 is a block diagram illustrating the replacement of 65 constant references with constants. FIG. 9 is a block diagram illustrating the replacement of references with their updated values. Case: 13-1397 Document: 34 Page: 229 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 28 of 35 JA000172 US 7,818,727 B2 7 FIG. 10 is a block diagram illustrating renumbering of original byte codes. FIG. 11 is a block diagram illustrating translation of origi- nal byte codes for a different virtual machine architecture. FIG. 12 is a block diagram illustrating loading applications into an integrated circuit card. FIG. 13 is a block diagram illustrating executing applica- tions in an integrated circuit card. 8 The terminal 14 can also interact with applications running in the integrated circuit card 10. In some cases, different terminals may be used for these purposes. For example, one kind of terminal may be used to prepare applications, differ- ent terminals could be used to download the applications, and yet other terminals could be used to run the various applica- tions. Terminals can be automated teller machines (ATMs), point-of-sale terminals, door security systems, toll payment systems, access control systems, or any other system that FIG. 14 is a schematic diagram illustrating memory orga- nization for ROM, RAM and EEPROM. FIG. 15 is a flow diagram illustrating the overall architec- ture of the Card Java virtual machine. 10 communicates with an integrated circuit card or micro con- troller. FIG. 16 is a flow diagram illustrating method execution in the Card Java virtual machine with the security checks. FIG. 17 is a flow diagram illustrating byte code execution 15 in the Card Java virtual machine. FIG. 16 is a flow diagram illustrating method execution in the Card Java virtual machine without the security checks. The integrated circuit card 10 contains a card Java virtual machine (Card JVM) 16, which is used to interpret applica- tions which are contained on the card 10. Referring to FIG. 2, the Java application 20 includes three Java source code filesA.java 20a, B.java 20b, and c.java 20e. These source code files are prepared and compiled in a Java application development environment 22. When the Java application 20 is compiled by the development environment FIG. 19 is a block diagram illustrating the association between card applications and identities. FIG. 20 is a block diagram illustrating the access rights of a specific running application. FIG. 21 is a perspective view of a microcontroller on a smart card. 20 22, application class files 24 are produced, with these class files A.class 24a, B.class 24b, and C.class 24e corresponding to their respective class Java source code 20a, 20b, and 20e. The application class files 24 follow the standard class file FIG. 22 is a perspective view of a microcontroller on a 25 telephone. FI G. 23 is a perspective view of a micro controller on a key ring. format as documented in chapter 4 of the Java virtual machine specification by Tim Lindholm and Frank Yellin, "The Java Virtual Machine Specification," Addison-Wesley, 1996. These application class files 24 are fed into the card class file converter 26, which consolidates and compresses the files, producing a single card class file 27. The card class file 27 is FIG. 24 is a perspective view of a micro controller on a ring. FIG. 25 is a perspective view of a microcontroller on a circuit card of an automobile. 30 loaded to the integrated circuit card 10 using a conventional card loader 28. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Referring to FIG. 3, the card class file converter 26 is a class file postprocessor that processes a set of class files 24 that are encoded in the standard Java class file format, optionally 35 using a string to ID input map file 30 to produce a Java card class file 27 in a card class file format. One such card class file Referring to FIG. 1, an integrated circuit card 10 (e.g., a smart card) is constructed to provide a high level, Java-based, multiple application programming and execution environ- ment. The integrated circuit card 10 has a communicator 12a that is configured to communicate with a terminal communi - 40 cator 12b of a terminal 14. In some embodiments, the inte- grated circuit card 10 is a smart card with an 8 bit microcon- troller, 512 bytes of RAM, 4K bytes of EEPROM, and 20K of ROM; the terminal communicator 12b is a conventional con- tact smart card reader; and the terminal 14 is a conventional 45 personal computer running the Windows NT operating sys- tem supporting the personal computer smart card (PC/SC) standard and providing Java development support. In some embodiments, the microcontroller, memory and communicator are embedded in a plastic card that has sub- 50 stantially the same dimensions as a typical credit card. In other embodiments, the microcontroller, memory and com- municator are mounted within bases other than a plastic card, such as jewelry (e.g., watches, rings or bracelets), automotive equipment, telecommunication equipment (e.g., subscriber 55 identity module (SIM) cards), security devices (e.g., crypto- graphic modules) and appliances. The terminal 14 prepares and downloads Java applications to the integrated circuit card 10 using the terminal communi- cator 12b. The terminal communicator 12b is a communica- 60 format is described in Appendix A which is hereby incorpo- rated by reference. In addition, in some embodiments, the card class file converter 26 produces a string to ID output map file 32 that is used as input for a subsequent execution of the card class file converter. In some embodiments, in order for the string to ID mapping to be consistent with a previously generated card class file (in the case where multiple class files reference the same strings), the card class file converter 26 can accept previously defined string to ID mappings from a string to ID input map file 30. In the absence of such a file, the IDs are generated by the card class file converter 26. Appendix B, which is hereby incorpo- rated by reference, describes one possible way of implement- ing and producing the string to ID input map file 30 and string to ID output map file 32 and illustrates this mapping via an example. Referring to FIG. 4, a typical application class file 24a includes class file information 41; a class constant pool 42; class, fields created, interfaces referenced, and method infor- mation 43; and various attribute information 44, as detailed in aforementioned Java Virtual Machine Specification. Note that much of the attribute information 44 is not needed for this embodiment and is eliminated 45 by the card class file con- verter 26. Eliminated attributes include SourceFile, Con- stantValue, Exceptions, LineNumberTable, LocalVariable- Table, and any optional vendor attributes. The typical card class file 27 as described in Appendix A is derived from the application class files 24 in the following mauner. The card tions device capable of establishing a communications chan- nel between the integrated circuit card 10 and the terminal 14. Some communication options include contact card readers, wireless communications via radio frequency or infrared techniques, serial communication protocols, packet commu- nication protocols, ISO 7816 communication protocol, to name a few. 65 class file information 46 is derived from the aggregate class file information 41 of all application class files 24a, 24b, and 24e. The card class file constant pool 47 is derived from the Case: 13-1397 Document: 34 Page: 230 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 29 of 35 JA000173 US 7,818,727 B2 9 10 aggregate class constant pool 42 of all application class files 24a, 24b, and 24c. The card class, fields created, interfaces referenced, and method information 48 is derived from the aggregate class, fields created, interfaces referenced, and method information 43 of all application class files 24a, 24b, 5 and 24c. The card attribute information 49 in this embodiment Modifying the byte codes 54 involves five passes (with two optional passes) as described by the flowchart in FIG. 6. The original byte codes 60 are found in the Code attribute 44 of the Java class file 24a being processed. The first pass 61 records all the jumps and their destinations in the original byte codes. During later byte code translation, some single byte code may is derived from only the code attribute of the aggregate attribute information 44 of all application class files 24a, 24b, and 24c. be translated to dual or triple bytes. FIG. 7 illustrates an example wherein byte code ILOAD_O is replaced with two bytes, byte code ILOAD and argument O. When this is done, 10 the code size changes, requiring adjustment of any jump destinations which are affected. Therefore, before these trans- formations are made, the original byte codes 60 are analyzed for any jump byte codes and a note made of their position and current destination. The program code fragment marked "B" To avoid dynamic linking in the card, all the information that is distributed across several Java class files 24a, 24b, and 24c that form the application 24, are coalesced into one card class file 27 by the process shown in the flowchart in FIG. 5. The first class file to be processed is selected 51a. The con- stant pool 42 is compacted SIb in the following manner. All objects, classes, fields, methods referenced in a Java class file 24a are identified by using strings in the constant pool 42 of the class file 24a. The card class file converter 26 compacts the constant pool 42 found in the Java class file 24a into an optimized version. This compaction is achieved by mapping 20 all the strings found in the class file constant pool 42 into integers (the size of which is micro controller architecture dependent). These integers are also referred to as IDs. Each 15 in Appendix D shows how these jumps are recorded. Appen- dix D is hereby incorporated by reference. Once the jumps are recorded, if the optional byte code translation is not being performed 62, the card class file converter 26 may proceed to the third pass 64. Otherwise, the card class file converter converts specific byte codes into generic byte codes. Typically, the translated byte codes are not interpreted in the Card NM 16 but are supported by converting the byte codes into equivalent byte codes that can be interpreted by the Card NM 16 (see FI G. 7). ID uniquely identifies a particular object, class, field or method in the application 20. Therefore, the card class file converter 26 replaces the strings in the Java class file constant pool 42 with its corresponding unique ID. Appendix B shows an example application HelloSmartCard.java, with a table below illustrating the IDs corresponding to the strings found in the constant pool of the class file for this application. The IDs used for this example are 16-bit unsigned integers. Next, the card class file converter 26 checks for unsup- ported features SIc in the Code attribute of the input Java class file 24a. The Card NM 16 only supports a subset of the full Java byte codes as described in Appendix C, which is hereby incorporated by reference. Hence, the card class file converter 26 checks for unsupported byte codes in the Code attribute of the Java class file 24a. If any unsupported byte codes are found 52, the card class file converter flags an error and stops conversion 53. The program code fragment marked "A" in APPENDIX D shows how these spurious byte codes are apprehended. Another level of checking can be performed by requiring the standard Java development environment 22 to compile the application 20 with a '-g' flag. Based on the aforementioned Java virtual machine specification, this option requires the Java compiler to place information about the variables used in a Java application 20 in the LocalVari- ableTable attribute of the class file 24a. The card class file converter 26 uses this information to check if the Java class file 24a references data types not supported by the Java card. Next, the card class file converter 26 discards all the unnec- essary parts SIc of the Java class file 24a not required for interpretation. A Java class file 24a stores information per- taining to the byte codes in the class file in the Attributes section 44 of the Java class file. Attributes that are not required for interpretation by the card JVM 16, such as SourceFile, ConstantValue, Exceptions, LineNumberTable, and Local- VariableTable may be safely discarded 45. The only attribute that is retained is the Code attribute. The Code attribute con- tains the byte codes that correspond to the methods in the Java class file 24a. ModifYing the byte codes 54 involves examining the Code attribute information 44 for each method in the class file, and modifYing the operands of byte codes that refer to entries in the Java class file constant pool 42 to reflect the entries in the card class file constant pool 47. In some embodiments, the byte codes are also modified, as described below. 25 The byte codes 70 may be replaced with another semantically equivalent but different byte codes 72. This generally entails the translation of short single specific byte codes such as ILOAD_O into their more general versions. For example, ILOAD _ 0 may be replaced by byte code ILOAD with an 30 argument O. This translation is done to reduce the number of byte codes translated by the Card JVM 16, consequently reducing the complexity and code space requirements for the Card JVM 16. The program code fragment marked "C" in Appendix D shows how these translations are made. Note that 35 such translations increase the size of the resulting byte code and force the re-computation of any jumps which are affected. In the third pass 64, the card class file converter rebuilds constant references via elimination of the strings used to denote these constants. FIG. 8 shows an example wherein the 40 byte code LDC 80 referring to constant "18" found via an index in the Java class file 24a constant pool 42 may be translated into BIPUSH byte code 82. In this pass the card class file converter 26 modifies the operands to all the byte codes that refer to entries in the Java class file constant pool 42 45 to reflect their new location in the card class file constant pool 47. FIG. 9 shows an example wherein the argument to a byte code, INVOKESTATIC 90, refers to an entry in the Java class file constant pool 42 that is modified to reflect the new loca- tion of that entry in the card class file constant pool 47. The 50 modified operand 94 shows this transformation. The program code fragment marked "D" in Appendix D shows how these modifications are made. Once the constant references are relinked, if the optional byte code modification is not being performed, the card class 55 file converter may proceed to the fifth and final pass 67. Otherwise, the card class file converter modifies the origi- nal byte codes into a different set of byte codes supported by the particular Card NM 16 being used. One potential modi- fication renumbers the original byte codes 60 into Card JVM 60 16 byte codes (see FIG. 10). This renumbering causes the byte codes 100 in the original byte codes 60 to be modified into a renumbered byte codes 102. Byte code ILOAD recognized by value 21 may be renumbered to be recognized by value 50. This modification may be done for optimizing the type tests 65 (also known in prior art as Pass 3 checks) in the CardJVM 16. The program code fragment marked "E" in Appendix D shows an implementation of this embodiment. This modifi- Case: 13-1397 Document: 34 Page: 231 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 30 of 35 JA000174 US 7,818,727 B2 11 12 selected class in the selected Java Card application 126z. The Card JVM 16 provides the Java card application 126z access to the underlying card operating system 122, which provides capabilities such as I/O, EEPROM support, file systems, access control, and other system functions using native Java methods as illustrated in Appendix F which is hereby incor- porated by reference. cation may be done in order to reduce the program space required by the Card JVM 16 to interpret the byte code. Essentially this modification regroups the byte codes into Card JVM 16 byte codes so that byte codes with similar operands, results are grouped together, and there are no gaps 5 between Card JVM 16 byte codes. This allows the Card JVM 16 to efficiently check Card JVM 16 byte codes and validate types as it executes. In some embodiments, the card class file converter modi- fies the original byte codes 60 into a different set of byte codes designed for a different virtual machine architecture, as shown in FIG. 11. The Java byte code ILOAD 112 intended for use on a word stack 114 may be replaced by Card NM 16 byte code ILOAD_B 116 to be used on a byte stack 118. An element in a word stack 114 requires allocating 4 bytes of 15 stack space, whereas an element in the byte stack 118 requires only one byte of stack space. Although this option may pro- vide an increase in execution speed, it risks losing the security features available in the original byte codes. The selected Java card application 126z communicates with an appropriate application in the terminal 14 using the 10 communicator 12a to establish a communication charmel to the terminal 14. Data from the communicator 12a to the Since the previous steps 63, 64 or 66 may have changed the 20 size of the byte codes 60 the card class file converter 26 has to relink 67 any jumps which have been effected. Since the jumps were recorded in the first step 61 of the card class file converter 26, this adjustment is carried out by fixing the jump destinations to their appropriate values. The program code 25 fragment marked "F" in Appendix D shows how these jumps are fixed. The card class file converter now has modified byte codes 68 that is equivalent to the original byte codes 60 ready for loading. The translation from the Java class file 24a to the card 30 class file 27 is now complete. Referring back to FIG. 5, if more class files 24 remain to be processed 55 the previous steps 51a, SIb, SIc, 52 and 54 are repeated for each remaining class file. The card class file converter 26 gathers 56 the maps and modified byte codes for 35 the classes 24 that have been processed, places them as an aggregate and generates 57 a card class file 27. If required, the card class file converter 26 generates a string to ID output map file 32, that contains a list of all the new IDs allocated for the strings encountered in the constant pool 42 of the Java class 40 files 24 during the translation. Referring to FIG. 12, the card loader 28 within the terminal terminal 14 passes through a communicator driver 132 in the terminal, which is specifically written to handle the commu- nications protocol used by the communicator 12a. The data then passes to an integrated circuit card driver 134, which is specifically written to address the capabilities of the particu- lar integrated circuit card 10 being used, and provides high level software services to the terminal application 136. In the preferred embodiment, this driver would be appropriate Pc/SC Smartcard Service Provider (SSP) software. The data then passes to the terminal application 136, which must handle the capabilities provided by the particular card appli- cation 126z being run. In this mauner, commands and responses pass back and forth between the terminal applica- tion 136 and the selected card application 126z. The terminal application interacts with the user, receiving commands from the user, some of which are passed to the selected Java card application 126z, and receiving responses from the Java card application 126z, which are processed and passed back to the user. Referring to FIG. 14, the CardJVM 16 is an interpreter that interprets a card application 126x. The memory resources in the micro controller that impact the Card JVM 16 are the Card ROM 140, Card RAM 141 and the Card EEPROM 142. The Card ROM 140 is used to store the Card JVM 16 and the card operating system 122. Card ROM 140 may also be used to store fixed card applications 140a and class libraries 140b. Loadable applications 141a, 141b and libraries 141c may also be stored in Card RAM 141. The Card NM 16 interprets a card application 141a, 141b, or 140a. The Card JVM 16 uses the Card RAM to store the VM stack 144a and system state variables 144b. The Card NM 16 keeps track of the opera- tions performed via the VM stack 144a. The objects created by the Card NM 16 are either on the RAM heap 144c, in the EEPROM heap 146a, or in the file system 147. All of the heap manipulated by the Card JVM 16 may be stored in the Card RAM 141 as a RAM Heap 144c, or it may be distributed across to the Card EEPROM 142 as a EEPROM 14 sends a card class file to the loading and execution control 120 within the integrated circuit card 10 using standard ISO 7816 commands. The loading and execution control 120 with 45 a card operating system 122, which provides the necessary system resources, including support for a card file system 124, which can be used to store several card applications 126. Many conventional card loaders are written in low level lan- guages, supported by the card operating system 122. In the preferred embodiment, the bootstrap loader is written in Java, and the integrated circuit card 10 includes a Java virtual machine to run this application. A Java implementation of the loading and execution control 120 is illustrated in Appendix E which is hereby incorporated by reference. The loading and 55 execution control 120 receives the card class file 26 and Heap 146a. Card RAM 141 is also used for recording the state 50 of the system stack 148 that is used by routines written in the native code of the micro controller. The Card JVM 16 uses the produces a Java card application 126x stored in the card file system 126 in the EEPROM of the integrated circuit card 10. Multiple Java card applications 126x, 126y, and 126z can be stored in a single card in this marmer. The loading and execu- 60 tion control 120 supports commands whereby the terminal 14 can select which Java card application to run immediately, or upon the next card reset. Card EEPROM 142 to store application data either in the EEPROM heap 146a or in the file system 147. Application data stored in a file may be manipulated via an interface to the card operating system 122. This interface is provided by a class library 140b stored in Card ROM 140, by a loadable class library 141c stored in Card EEPROM 142. One such interface is described in Appendix F. Applications and data in the card are isolated by a firewall mechanism 149. To cope with the limited resources available on microcon- trollers, the Card JVM 16 implements a strict subset of the Java progranlilling language. Consequently, a Java applica- tion 20 compiles into a class file that contains a strict subset of Java byte codes. This enables application programmers to Referring to FIG. 13, upon receiving a reset or an execution command from the loading and execution control 120, the Card Java Virtual Machine (Card JVM) 16 begins execution at a predetermined method (for example, main) of the 65 program in this strict subset of Java and still maintain com- patibility with existing Java Virtual Machines. The semantics of the Java byte codes interpreted by the Card JVM 16 are Case: 13-1397 Document: 34 Page: 232 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 31 of 35 JA000175 US 7,818,727 B2 13 described in the aforementioned Java Virtual Machine Speci- fication. The subset of byte codes interpreted by the Card JVM 16 can be found in Appendix C. The card class file converter 26 checks the Java application 20 to ensure use of only the features available in this subset and converts into a 5 form that is understood and interpreted by the Card JVM 16. In other embodiments, the Card NM 16 is designed to interpret a different set or augmented set of byte codes 116. Although a different byte code set might lead to some perfor- mance improvements, departing from a strict Java subset may 10 not be desirable from the point of view of security that is present in the original Java byte codes or compatibility with mainstream Java development tools. All Card JVM 16 applications 126 have a defined entry point denoted by a class and a method in the class. This entry 15 point is mapped in the string to ID input map 30 and assigned by the card class file converter 26. Classes, methods and fields within a Java application 20 are assigned IDs by the card class file converter 26. For example, the ID corresponding to the main application class may be defined as FOOl and the ID 20 corresponding to its main method, such as "main( )V" could be defined as F002. 14 verified and determined conformant to this model. These checks are typically carried out in prior art by a program referred to as the byte code verifier, which operates in four passes as described in the Java Virtual Machine Specification. To offer the run-time security that is guaranteed by the byte code verifier, the Card JVM 16 must perform the checks that pertain to the Pass 3 and Pass 4 of the verifier. This checking can be bypassed by the Card NM 16 if it can be guaranteed (which is almost impossible to do) that the byte codes 60 interpreted by the Card JVM 16 are secure. At the minimum, code security can be maintained as long as object references cannot be faked and the VM stack 144a and local variable bounds are observed. This requires checking the state of the VM stack 144a with respect to the byte code being executed. To enforce the security model of the programming lan- guage, a 256-byte table is created as shown in Appendix G which is hereby incorporated by reference. This table is indexed by the byte code number. This table contains the type The overall execution architecture of the Card JVM is described by the flowchart in FIG. 15. Execution of the Card JVM 16 begins at the execution control 120, which chooses a card application 126z to execute. It proceeds by finding and assigning an entry point 152 (a method) in this card applica- tion for the Card NM 16 to interpret. The Card NM 16 interprets the method 153. If the interpretation proceeds suc- cessfully 154, the Card NM 16 reports success 155 returning control back to the execution control 120. If in the course of interpretation 153 the Card JVM 16 encounters an unhandled error or exception (typically a resource limitation or a security violation), the Card NM 16 stops 156 and reports the appro- priate error to the terminal 14. and length information associated with the indexing byte code. It is encoded with the first 5 bits representing type, and the last 3 bits representing length. The type and length of the byte code is indexed directly from the table by the byte code number. This type and length is then used for checking as shown in Appendix H which is hereby incorporated by refer- 25 ence. In Appendix H, the checking process begins by decod- ing the length and type from the table inAppendix G which is hereby incorporated by reference. The length is used to incre- ment the program counter. The type is used first for pre- execution checking, to insure that the data types on the VM 30 stack 144a are correct for the byte code that is about to be executed. The 256 bytes of ROM for table storage allows the original Java byte codes to be run in the Card NM 16 and minimizes the changes required to the Java class file to be loaded in the card. Additional Java byte codes can be easily An essential part of the Card JVM 16 is a subroutine that handles the execution of the byte codes. This subroutine is described by the flowchart in FIG. 16. Given a method 160 it executes the byte codes in this method. The subroutine starts 35 supported since it is relatively easy to update the appropriate table entries. by preparing for the parameters of this method 161. This 40 involves setting the VM stack 144a pointer, VM stack 144a frame limits, and setting the program counter to the first byte code of the method. Next, the method flags are checked 162. If the method is flagged native, then the method is actually a call to native 45 method code (subroutine written in the microcontroller's native processor code). In this case, the Card JVM 16 pre- pares for an efficient call 163 and return to the native code subroutine. The parameters to the native method may be passed on the VM stack 144a or via the System stack 148. The 50 appropriate security checks are made and the native method subroutine is called. On return, the result (if any) of the native method subroutine is placed on the VM stack 144a so that it may be accessed by the next byte code to be executed. The dispatch loop 164 of the Card JVM 16 is then entered. 55 The byte code dispatch loop is responsible for preparing, executing, and retiring each byte code. The loop terminates when it finishes interpreting the byte codes in the method 160, or when the Card JVM 16 encounters a resource limitation or a security violation. If a previous byte code caused a branch to be taken 165 the Card JVM prepares for the branch 165a. The next byte code 60 In other embodiments, as shown in FIG. 10, the Java byte codes in the method are renumbered in such a mauner that the byte code type and length information stored in the table in Appendix H is implicit in the reordering. Appendix H is hereby incorporated by reference. Consequently, the checks that must be performed on the state of the VM stack 144a and the byte code being processed does not have to involve a table look up. The checks can be performed by set of simple com- parisons as shown in Appendix I which is hereby incorporated by reference. This embodiment is preferable when ROM space is at a premium, since it eliminates a 256-byte table. However adding new byte codes to the set of supported byte codes has to be carefully thought out since the new byte codes have to fit in the implicit numbering scheme of the supported byte codes. In another embodiment, the Card JVM 16 chooses not to perform any security checks in favor of Card NM 16 execu- tion speed. This is illustrated in the flowchart in FIG. 18. The flow chart in FIG. 18 is the same as that of FIG. 16 with the security checks removed. This option is not desirable from the point of view of security, unless it can be guaranteed that the byte codes are secure. The Card JVM 16 may enforce other security checks as well. If the byte code may reference a local variable, the Card JVM 16 checks if this reference is valid, throwing an error if it is not. If the reference is valid, the Card NM 16 stores the type of the local variable for future checking. The VM stack is retrieved 165b. In order to keep the cost of processing each byte code down, as many common elements such as the byte code arguments, length, type are extracted and stored. To provide the security offered by the security model of the programming language, byte codes in the class file must be 65 144a pointer is checked to see if it is still in a valid range. If not an exception is thrown. The byte code number is checked. If it is not supported, an exception is thrown. Case: 13-1397 Document: 34 Page: 233 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 32 of 35 JA000176 US 7,818,727 B2 15 Finally, the byte code itself is dispatched 165d. The byte codes translated by the Card NM 16 are listed in Appendix C. The semantics of the byte codes are described in the afore- mentioned Java Virtual Machine Specification with regard to the state of the VM stack 144a before and after the dispatch of the byte code. Note also that some byte codes (the byte codes, INVOKESTATIC, INVOKESPECIAL, INVOKENONVIR- TUAL and INVOKEVIRTUAL) may cause reentry into the Card JVM 16, requiring processing to begin at the entry of the subroutine 161. FIG. 17 shows the flowchart of the byte code execution routine. The routine is given a byte code 171 to execute. The Card JVM 16 executes 172 the instructions required for the byte code. If in the course of executing the Card NM 16 encounters a resource limitation 173, it returns an error 156. This error is returned to the terminal 16 by the Card NM 16. If the byte code executes successfully, it returns a success 175. After execution, the type of the result is used to set the VM stack 144a state correctly 165e, properly flagging the data types on the VM stack 144a. The byte code information gathered previously 165b from the byte code info table is used to set the state of the VM stack 144a in accordance with the byte code that just executed. In other embodiments, setting the output state of the VM stack 144a with respect to the byte code executed is simplified if the byte code is renumbered. This is shown in Appendix I which is hereby incorporated by reference. 16 Access Control Virtual Lists Machine Encryption Data access access only data to Protection control to own another before narnespace program operation encrypted 10 Program access execution data Protection control only on encrypted in before correct program's execution types narnespace Communication access channel only mutnally Protection control on controls authenticated 15 channels in own parties can narnespace communicate Taken together, these facilities isolate both data and appli- cations on the integrated circuit card 10 and ensure that each 20 card application 126 can access only the authorized resources of the integrated circuit card 10. Referring to FIG. 19, card applications 126x, 126y, 126z can be endowed with specific privileges when the card appli- cations 126 execute. These privileges determine, for example, 25 which data files the card applications 126 can access and what operations the card applications 126 can perform on the file system 147. The privileges granted to the card applications 126 are normally set at the time that a particular card appli- cation 126z is started by the user, typically from the terminal 30 14. In yet another embodiment, the Card NM 16 may bypass setting the output state of the VM stack 144a in favor of Card JVM 16 execution speed. This option is not desirable from the point of view of security, unless it can be guaranteed that the 35 byte codes are secure. The integrated circuit card 10 uses cryptographic identifi- cation verification methods to associate an identity 190 (e.g., identities 190a, 190b and 190c) and hence, a set of privileges to the execution of the card application 126. The association of the specific identity 190c to the card application 126z is made when the card application 126z begins execution, thus creating a specific ruuning application 200, as shown in FIG. 20. The identity 190 is a unique legible text string reliably After the byte code has been executed, the byte code is retired 165/ This involves popping arguments off the VM stack 144a. Once byte code processing is completed, the loop 164 is repeated for the next byte code for the method. Once the dispatch loop 164 terminates, the VM stack 144a is emptied 166. This prevents any object references filtering down to other Card JVM 16 invocations and breaking the Card JVM's 16 security. Termination 167 of the byte code dispatch loop 164 indicates that the Card JVM 16 has com- pleted executing the requested method. To isolate data and applications in the integrated circuit card 10 from each other, the integrated circuit card 10 relies on the firewall mechanism 149 provided by the Card JVM 16. Because the Card JVM implements the standard pass 3 and pass 4 verifier checks, it detects any attempt by an application 40 associated with an identity token. The identity token (e.g., a personal identification nnmber (PIN) or a RSA private key) is an encryption key. Referring to FIG. 20, in order to run a specific card appli- cation 126z, the identity 190c of the card application 126z 45 must be authenticated. The identity 190c is authenticated by demonstrating knowledge of the identity token associated with the identity 190c. Therefore, in order to run the card application 126z, an agent (e.g., a card holder or another application wishing to run the application) must show that it 50 possesses or knows the application's identity-defining encryption key. to reference the data or code space used by another applica- tion, and flag a security error 156. For example, conventional low level applications can cast non-reference data types into 55 references, thereby enabling access to unauthorized memory space, and violating security. With this invention, such an attempt by a card application 126z to use a non-reference data type as a reference will trigger a security violation 156. In 60 conventional Java, this protected application environment is referred to as the sandbox application-interpretation environ- One way to demonstrate possession of an encryption key is simply to expose the key itself. PIN verification is an example of this form of authentication. Another way to demonstrate the possession of an encryption key without actually exposing the key itself is to show the ability to encrypt or decrypt plain text with the key. Thus, a specific ruuning application 200 on the integrated circuit card 10 includes a card application 126z plus an authenticated identity 190c. No card application 126 can be run without both of these elements being in place. The card application 126z defines data processing operations to be performed, and the authenticated identity 190c determines on what computational objects those operations may be per- ment. However, these firewall facilities do not work indepen- dently. In fact, the facilities are overlapping and mutually reinforcing with conventional access control lists and encryp- tion mechanisms shown in the following table: 65 formed. For example, a specific application 126z can only access identity C's files 202 in the file system 147 associated with the specific identity 190c, and the specific card applica- Case: 13-1397 Document: 34 Page: 234 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 33 of 35 JA000177 US 7,818,727 B2 17 tion 126z cannot access other files 204 that are associated with identities other than the specific identity 190c. The integrated circuit card 10 may take additional steps to ensure application and data isolation. The integrated circuit card 10 furnishes three software features sets: authenticated- identity access control lists; a Java-based virtual machine; and one-time session encryption keys to protect data files, application execution, and commnnication channels, respec- tively. Collectively, for one embodiment, these features sets provide the application data firewalls 149 for one embodi- 10 ment. The following discusses each software feature set and then shows how the three sets work together to insure appli- cation and data isolation on the integrated circuit card 10. An access control list (ACL) is associated with every com- putational object (e.g., a data file or a communication chan- 15 nel) on the integrated circuit card 10 that is be protected, i.e., to which access is to be controlled. An entry on an ACL (for a particular computational object) is in a data format referred 18 Thus, the application firewall includes three mutually rein- forcing software sets. Data files are protected by authenti- cated-identity access control lists. Application execution spaces are protected by the Card JVM 16. Communication channels are protected with one-time session encryption keys 209. In other embodiments, the above-described techniques are used with a micro controller (such as the processor 12) may control devices (e. g., part of an automo bile engine) other than an integrated circuit card. In these applications, the micro- controller provides a small platform (i.e., a central processing unit, and a memory, both of which are located on a semicon- ductor substrate) for storing and executing high level pro- gramming languages. Most existing devices and new designs that utilize a micro controller could use this invention to pro- vide the ability to program the microcontroller using a high level language, and application of this invention to such devices is specifically included. to as an e-tuple: type:identity:permissions The term application includes any program, such as Java 20 applications, Java applets, Java aglets, Java servlets, Java commlets, Java components, and other non-Java programs that can result in class files as described below. The type field indicates the type of the following identity (in the identity field), e.g., a user (e.g., "John Smith"), or a group. The permissions field indicates a list of operations (e.g., read, append and update) that can be performed by the identity on 25 the computational object. As an example, for a data file that has the ACL entry: USER:AcmeAirlines:RAU, Class files may have a source other than Java program files. Several progrannning languages other than Java also have compilers or assemblers for generating class files from their respective source files. For example, the programming lan- guage Eiffel can be used to generate class files using Pirmin Kalberer's" J -Eiffel", an Eiffel compiler with JVM byte code generation (web site: http://www.spin.chl-kalberer/jive/in- any application whose identity is "AcmeAirlines" can read ("R"), append ("A") and update ("U") the data file. In addi- tion, the ACL may be used selectively to permit the creation and deletion of data files. Furthermore, the ACL may be used selectively to permit execution of an application. 30 dex.htm). An Ada 95 to Java byte code translator is described in the following reference (incorporated herein by reference): Taft, S. Tucker, "Programming the Internet in Ada 95", pro- ceedings of Ada Europe' 96, 1996. Jasmin is a Java byte code assembler that can be used to generate class files, as described Whenever a computational object is accessed by a running application 200, the access is intercepted by the Card JVM 16 and passed to the card operating system 122, which deter- mines ifthere is anACL associated with the object. If there is an associatedACL, then the identity 190c associated with the running application 200 is matched on theACL. If the identity 35 in the following reference (incorporated herein by reference) Meyer, Jon and Troy Downing, "Java Virtual Machine", O'Reilly, 1997. Regardless of the source of the class files, the above description applies to languages other than Java to is not found or if the identity is not permitted for the type of 40 access that is being requested, then the access is denied. Otherwise, the access is allowed to proceed. Referring to FIG. 13, to prevent the potential problems due generate codes to be interpreted. FIG. 21 shows an integrated circuit card, or smart card, which includes a micro controller 210 that is mounted to a plastic card 212. The plastic card 212 has approximately the same form factor as a typical credit card. The commnnicator 12a can use a contact pad 214 to establish a communication to the single data path between the integrated circuit card 10 and the terminal 14, commnnication channel isolation is accomplished by including in the identity authentication pro- cess the exchange of a one-time session key 209 between the 45 channel, or the communicator 12a can use a wireless com- munication system. In other embodiments, a microcontroller 210 is mounted into a mobile or fixed telephone 220, effectively adding smart card capabilities to the telephone, as shown in FIG. 22. In these embodiments, the micro controller 210 is monnted on a module (such as a Subscriber Identity Module (SIM)), for insertion and removal from the telephone 220. a card application 126z and the terminal application 136. The key 209 is then used to encrypt subsequent traffic between the authenticating terminal application 136 and the authenticated 50 card application 126z. Given the one-time session key 209, a rogue terminal application can neither "listen in" on an authenticated communication between the terminal 14 and the integrated circuit card 10, nor can the rogue terminal application "spoof' the card application into performing unauthorized operations on its behalf. In other embodiments, a microcontroller 210 is added to a key ring 230 as shown in FIG. 23. This can be used to secure 55 access to an automobile that is equipped to recognize the identity associated with the micro controller 210 on the key ring 230. Encryption and decryption of card/terminal traffic can be handled either by the card operating system 122 or by the card application itself126z. In the former case, the communication with the terminal 14 is being encrypted transparently to the application, and message traffic arrives decrypted in the data space of the application. In the latter case, the card application 126z elects to perform encryption and decryption to provide Jewelry such as a watch or ring 240 can also house a microcontroller 210 in an ergonomic manner, as shown in 60 FIG. 24. Such embodiments typically use a wireless commu- nication system for establishing a communication channel, and are a convenient way to implement access control with a minimum of hassle to the user. an extra layer of security since the application could encrypt data as soon as it was created and would decrypt data only 65 when it was about to be used. Otherwise, the data would remain encrypted with the session key 209. FIG. 25 illustrates a micro controller 210 monnted in an electrical subsystem 252 of an automobile 254. In this embodiment, the micro controller is used for a variety of pur- poses, such as to controlling access to the automobile, (e.g. Case: 13-1397 Document: 34 Page: 235 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 34 of 35 JA000178 US 7,818,727 B2 19 checking identity or sobriety before enabling the ignition system of the automobile), paying tolls via wireless commu- nication, or interfacing with a global positioning system (GPS) to track the location of the automobile, to name a few. While specific embodiments of the present invention have been described, various modifications and substitutions will become apparent to one skilled in the art by this disclosure. Such modifications and substitutions are within the scope of the present invention, and are intended to be covered by the appended claims. We claim: 1. A programmable device comprising: a memory, a non-volatile memory and a processor; the non-volatile memory storing: 10 an application for the programmable device obtained from 15 an application having a class file format wherein the application for the programmable device is obtained from the application having a class file format by first compiling the application having a class file format into a compiled form and then converting the compiled form 20 into a converted form, and 20 contains features in the subset of the first set of features and only contains data types in the subset of the first set of data types. 10. The programmable device of claim 6 wherein the com- piled form is in a byte code format and the converter com- prises means for translating from the byte codes in the com- piled form to byte codes in a format suitable for interpretation by the interpreter by: recording all jumps and their destinations in the original byte codes: converting the compiled form using at least one step in a process including the steps: a) converting specific byte codes into equivalent generic byte codes or vice-versa; b) modifying byte code operands from references using identifying strings to references using unique identi- fiers; and c) renumbering byte codes in the compiled form to equivalent byte codes in the format suitable for inter- pretation; and relinking jumps for which destination address is effected by conversion step a), b), or c). an interpreter configured to interpret applications in the converted form; and the processor coupled to the memory, the processor con- figured to use the interpreter to interpret the application for the programmable device for execution. 11. The programmable device of claim 3 wherein the appli- cation program is compiled into a compiled form for which 25 resources required to execute or interpret the compiled form exceed those available on the micro controller. 2. The progranlillable device of claim 1, wherein the class file format comprises a Java class file format. 3. A programmable device comprising: a memory, and a processor; the memory comprising: an interpreter; and 30 at least one application loaded in the memory to be interpreted by the interpreter, wherein the at least one 35 application is generated by a programming environ- ment comprising: a) a compiler for compiling application source programs written in high level language source code form into a compiled form, and 40 12. The programmable device of claim 3 wherein the com- piled form is designed for portability on different computer platforms. 13. The programmable device of claim 3 wherein the inter- preter is further configured to determine, during an interpre- tation of an application, whether the application meets a security criteria selected from a set of rules containing at least one rule selected from the set: not allowing the application access to unauthorized por- tions of memory, not allowing the application access to unauthorized micro- controller resources, wherein the application is composed of byte codes and checking a plurality of byte codes at least once prior to execution to verify that execution of the byte codes does not violate a security constraint. b) a converter for post processing the compiled form into a minimized form suitable for interpretation within the set of resource constraints by the interpreter. 4. The progranlillable device of claim 3, wherein the com- piled form includes attributes, and the converter comprises a means for including attributes required by the interpreter while not including the attributes not required by the inter- preter. 14. The programmable device of claim 3 wherein at least one application program is generated by a process including 45 the steps of: prior to loading the application verifying that the applica- tion does not violate any security constraints; and loading the application in a secure mauner. 5. The programmable device of claim 3 wherein the com- piled form is in a standard Java class file format and the converter accepts as input the compiled form in the standard Java class file format and produces output in a form suitable for interpretation by the interpreter. 15. The progranlillable device of claim 14 wherein the step 50 ofloading in a secure marmer comprises the step of: verifYing that the loading identity has permission to load applications onto the microcontroller. 6. The programmable device of claim 3 wherein the com- piled form includes associating an identifYing string for 55 objects, classes, fields, or methods, and the converter com- prises a means for mapping such strings to unique identifiers. 7. The progranlillable device of claim 6 wherein each unique identifier is an integer. S. The programmable device of claim 6 wherein the map- 60 ping of strings to unique identifiers is stored in a string to identifier map file. 9. The programmable device of claim 3 where in the high level language supports a first set of features and a first set of data types and the interpreter supports a subset of the first set 65 of features and a subset of the first set of data types, and wherein the converter verifies that the compiled form only 16. The progranlillable device of claim 14 wherein the step ofloading in a secure marmer comprises the step of: encrypting the application to be loaded using a loading key. 17. A method of progranlilling a programmable device having a memory and a processor operating according to a set of resource constraints, the method comprising the steps of: inputting an application program in a first progranlilling language; compiling the application program in the first program- ming language into a first intermediate code associated with the first progranlilling language, wherein the first intermediate code being interpretable by at least one first intermediate code virtual machine; converting the first intermediate code into a second inter- mediate code by performing at least one operation to Case: 13-1397 Document: 34 Page: 236 Filed: 07/09/2013 Case 6:10-cv-00561-LED Document 1-3 Filed 10/22/10 Page 35 of 35 JA000179 US 7,818,727 B2 21 replace a construct in the first intennediate code with an equivalent construct in the second intermediate code; wherein the second intennediate code is interpretable within the set of resource constraints by a second inter- mediate code virtual machine; and loading the second intennediate code into the memory of the programmable device. 18. The method of programming a programmable device of claim 17 wherein the step of converting further comprises: associating an identifYing string for objects, classes, fields, 10 or methods; and mapping such strings to unique identi- fiers. 19. The method of claim 18 wherein the step of mapping comprises the step of mapping strings to integers. 20. The method of claim 17 wherein the step of converting 15 comprises the steps of: 22 recording all jumps and their destinations in the original byte codes; converting the compiled fonn using at least one step in a process including the steps: a) converting specific byte codes into equivalent generic byte codes or vice-versa; b) modifying byte code operands from references using identifying strings to references using unique identi- fiers; c) renumbering byte codes in a compiled fonnat to equivalent byte codes in a fonnat suitable for inter- pretation; and relinking jumps for which destination address is effected by conversion step a), b), or c). * * * * * Case: 13-1397 Document: 34 Page: 237 Filed: 07/09/2013
CERTIFICATE OF SERVICE I, Daniela Lattes, hereby certify that on J uly 9, 2013, I caused one copy of the documents listed below:
NON-CONFIDENTIAL BRIEF FOR PLAINTIFF-APPELLANT GEMALTO S.A.
to be filed by CM/ECF with: Clerk of Court United States Court of Appeals for the Federal Circuit 717 Madison Place, N.W. Washington, D.C. 20439 Tel: (202) 275-8000 Fax: (202) 275-9678
and to be served via electronic mail pursuant to Fed. Cir. R. ECF-9(b) on the following: HTC Corporation, HTC America Inc., Exedea, Inc., Google, Inc., Motorola Mobility LLC, Samsung Electronics Co., Ltd., Samsung Telecommunications America, LLC:
Charles Kramer Verhoeven Quinn Emanuel Urquhart & Sullivan, LLP. 50 California Street, 22nd Floor San Francisco, CA 94111 Phone : (415) 875-6301 Fax: (415) 875-6700 Email:charlesverhoeven@quinnemanuel.com; QE-Gemalto@quinnemanuel.com
Kristin J. Madigan Quinn Emanuel Urquhart & Sullivan, LLP. 50 California Street, 22nd Floor San Francisco, CA 94111 Phone : (415) 875-6600 Fax: (415) 875-6700 Email:kristinmadigan@quinnemanuel.com Case: 13-1397 Document: 34 Page: 238 Filed: 07/09/2013
David A. Perlson Quinn Emanuel Urquhart & Sullivan, LLP. 50 California Street, 22nd Floor San Francisco, CA 94111 Phone : (415) 875-6600 Fax: (415) 875-6700 Email:davidperlson@quinnemanuel.com
Antonio R. Sistos Quinn Emanuel Urquhart & Sullivan, LLP. 50 California Street, 22nd Floor San Francisco, CA 94111 Phone : (415) 875-6600 Fax: (415) 875-6700 Email:antoniosistos@quinnemanuel.com
Joseph Milowic III Quinn Emanuel Urquhart & Sullivan, LLP. 51 Madison Avenue, 22nd Fl New York, NY 10010 Phone : (212) 849-7000 Fax: (212) 849-7100 Email:josephmilowic@quinnemanuel.com
Robert Wilson Quinn Emanuel Urquhart & Sullivan, LLP. 51 Madison Avenue, 22nd Fl New York, NY 10010 Phone : (212) 849-7000 Fax: (212) 849-7100 Email:robertwilson@quinnemanuel.com
I declare that I am employed by McKool Smith P.C. at whose direction the service was made.
Executed on J uly 9, 2013, at New York.
/s/ Daniela Lattes Daniela Lattes MCKOOL SMITH P.C. One Bryant Park, 47th floor New York, New York 10036 212.402.9499 (t) 212.402.9444 (f) dlattes@mckoolsmith.com Case: 13-1397 Document: 34 Page: 240 Filed: 07/09/2013
CERTIFICATE OF COMPLIANCE
I certify that the foregoing NON-CONFIDENTIAL BRIEF FOR PLAINTIFF-APPELLANT GEMALTO S.A.: 1. complies with the type-volume limitation of Fed. R. App. P. 32(a)(7)(B). This brief contains 9,830 words, excluding the parts of the brief exempted by Fed. R. App. P. 32(a)(7)(B)(iii) and Fed. Cir. R. 32(b). Microsoft Word 2003 was used to calculate the word count; and 2. complies with the typeface requirements of Fed. R. App. P. 32(a)(5) and the type style requirements of Fed. R. App. P. 32(a)(6). This brief has been prepared in proportionally-spaced typeface using Microsoft Word 2003 in 14-point Times New Roman type style.
Dated: J uly 9, 2013
Respectfully submitted,
/s/ Robert A. Cote Robert A. Cote MCKOOL SMITH P.C. One Bryant Park, 47th Floor New York, New York 10036 (212) 402-9400