You are on page 1of 241

2013-1397

UNITED STATES COURT OF APPEALS


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













CONFIDENTIAL MATERIAL OMITTED
Case: 13-1397 Document: 34 Page: 27 Filed: 07/09/2013
20






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.).


CONFIDENTIAL MATERIAL OMITTED
Case: 13-1397 Document: 34 Page: 28 Filed: 07/09/2013
21



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

Attorneys for Plaintiff-Appellant
Gemalto S.A.
Case: 13-1397 Document: 34 Page: 57 Filed: 07/09/2013

McKool 886752v5

ADDENDUM

















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.

Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 38 of 47 PageID #:
6159
JA000054
Case: 13-1397 Document: 34 Page: 112 Filed: 07/09/2013
39

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.

Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 42 of 47 PageID #:
6163
JA000058
Case: 13-1397 Document: 34 Page: 116 Filed: 07/09/2013
43

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.

Case 6:10-cv-00561-LED-JDL Document 242 Filed 06/28/12 Page 45 of 47 PageID #:
6166
JA000061
Case: 13-1397 Document: 34 Page: 119 Filed: 07/09/2013
46

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

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
4

o
f

3
6
J
A
0
0
0
1
2
2
Card File System
10
126
209
124
Integrated Circuit Card
FIGURE 13
14
136
134
. (
Integrated Circuit
,
,
Card Driver
132
Communicator
Driver
Terminal
Communicator
Terminal
12b
e
.
rJ'l
.
"'C
~
~
~
=

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

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
4

o
f

3
5
J
A
0
0
0
1
5
8
Card File System
10
126
124
Card JVM
Integrated Circuit Card
FIGURE 13
14
136
;134
Integrated Circuit
Card Driver
1 L 132
Communicator
Driver
Terminal
Communicator
Terminal
12b
~
7Jl
.
~
~
~
~
=

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


Case: 13-1397 Document: 34 Page: 239 Filed: 07/09/2013

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


Attorney for Plaintiff-Appellant
Gemalto S.A.


Case: 13-1397 Document: 34 Page: 241 Filed: 07/09/2013

You might also like