Connected, Limited Device
`Configuration
`
`Specification Version 1.0a
`
`Java 2 Platform Micro Edition
`
`Sun Microsystems, Inc.
`901 San Antonio Road
`Palo Alto, CA 94303 USA
`650 960-1300
`fax 650 969-9131
`
`1.0a, May 19, 2000
`
`Ericsson Ex. 2014, Page 1
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`J2ME(TM) Connected Limited Device Configuration (CLDC) ("Specification")
`
`Version: 1.0a
`Status: FCS
`Release: May 19, 2000
`
`Copyright 2000 Sun Microsystems, Inc.
`901 San Antonio Road, Palo Alto, California 94303, U.S.A.
`All rights reserved.
`
`NOTICE
`
`The Specification is protected by copyright and the information described therein may be protected by one or
`more U.S. patents, foreign patents, or pending applications. Except as provided under the following license, no
`part of the Specification may be reproduced in any form by any means without the prior written authorization of
`Sun Microsystems, Inc. ("Sun") and its licensors, if any. Any use of the Specification and the information
`described therein will be governed by the terms and conditions of this license and the Export Control and General
`Terms as set forth in Sun's website Legal Terms. By viewing, downloading or otherwise copying the Specification,
`you agree that you have read, understood, and will comply with all of the terms and conditions set forth herein.
`
`Sun hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right
`to sublicense), under Sun's intellectual property rights that are essential to practice the Specification, to internally
`practice the Specification solely for the purpose of creating a clean room implementation of the Specification that:
`(i) includes a complete implementation of the current version of the Specification, without subsetting or
`supersetting; (ii) implements all of the interfaces and functionality of the Specification, as defined by Sun, without
`subsetting or supersetting; (iii) includes a complete implementation of any optional components (as defined by
`Sun in the Specification) which you choose to implement, without subsetting or supersetting; (iv) implements all
`of the interfaces and functionality of such optional components, without subsetting or supersetting; (v) does not
`add any additional packages, classes or interfaces to the "java.*" or "javax.*" packages or subpackages (or other
`packages defined by Sun); (vi) satisfies all testing requirements available from Sun relating to the most recently
`published version of the Specification six (6) months prior to any release of the clean room implementation or
`upgrade thereto; (vii) does not derive from any Sun source code or binary code materials; and (viii) does not
`include any Sun source code or binary code materials without an appropriate and separate license from Sun. The
`Specification contains the proprietary information of Sun and may only be used in accordance with the license
`terms set forth herein. This license will terminate immediately without notice from Sun if you fail to comply with
`any provision of this license. Upon termination or expiration of this license, you must cease use of or destroy the
`Specification.
`
`TRADEMARKS
`
`No right, title, or interest in or to any trademarks, service marks, or trade names of Sun or Sun's licensors is
`granted hereunder. Sun, Sun Microsystems, the Sun logo, Java, the Java Coffee Cup logo, and JMX are trademarks
`or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
`
`DISCLAIMER OF WARRANTIES
`
`THE SPECIFICATION IS PROVIDED "AS IS". SUN MAKES NO REPRESENTATIONS OR WARRANTIES,
`EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY,
`FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT THAT THE CONTENTS OF THE
`SPECIFICATION ARE SUITABLE FOR ANY PURPOSE OR THAT ANY PRACTICE OR IMPLEMENTATION OF
`
`Please
`Recycle
`
`Ericsson Ex. 2014, Page 2
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADE SECRETS OR
`OTHER RIGHTS. This document does not represent any commitment to release or implement any portion of the
`Specification in any product.
`
`THE SPECIFICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS.
`CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION THEREIN; THESE CHANGES WILL BE
`INCORPORATED INTO NEW VERSIONS OF THE SPECIFICATION, IF ANY. SUN MAY MAKE
`IMPROVEMENTS AND/OR CHANGES TO THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN
`THE SPECIFICATION AT ANY TIME. Any use of such changes in the Specification will be governed by the then-
`current license for the applicable version of the Specification.
`
`LIMITATION OF LIABILITY
`
`TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR
`ANY DAMAGES, INCLUDING WITHOUT LIMITATION, LOST REVENUE, PROFITS OR DATA, OR FOR
`SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND
`REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO ANY FURNISHING,
`PRACTICING, MODIFYING OR ANY USE OF THE SPECIFICATION, EVEN IF SUN AND/OR ITS LICENSORS
`HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
`
`You will indemnify, hold harmless, and defend Sun and its licensors from any claims arising or resulting from: (i)
`your use of the Specification; (ii) the use or distribution of your Java application, applet and/or clean room
`implementation; and/or (iii) any claims that later versions or releases of any Specification furnished to you are
`incompatible with the Specification provided to you under this license.
`
`RESTRICTED RIGHTS LEGEND
`
`U.S. Government: If this Specification is being acquired by or on behalf of the U.S. Government or by a U.S.
`Government prime contractor or subcontractor (at any tier), then the Government's rights in the Software and
`accompanying documentation shall be only as set forth in this license; this is in accordance with 48 C.F.R. 227.7201
`through 227.7202-4 (for Department of Defense (DoD) acquisitions) and with 48 C.F.R. 2.101 and 12.212 (for non-
`DoD acquisitions).
`
`REPORT
`
`You may wish to report any ambiguities, inconsistencies or inaccuracies you may find in connection with your use
`of the Specification ("Feedback"). To the extent that you provide Sun with any Feedback, you hereby: (i) agree that
`such Feedback is provided on a non-proprietary and non-confidential basis, and (ii) grant Sun a perpetual, non-
`exclusive, worldwide, fully paid-up, irrevocable license, with the right to sublicense through multiple levels of
`sublicensees, to incorporate, disclose, and use without limitation the Feedback for any purpose related to the
`Specification and future versions, implementations, and test suites thereof.
`
`(LFI#85555/Form ID#011801)
`
`Please
`Recycle
`
`Ericsson Ex. 2014, Page 3
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`Contents
`
`Preface
`
`x
`
`1.
`
`Introduction and Background 1-1
`
`2. Goals, Requirements and Scope
`
`2-1
`
`2.1 Goals
`
`2-1
`
`2.1.1 Dynamic delivery of Java applications and content
`
`2-1
`
`2.1.2
`
`Targeting 3rd party application developers
`
`2-2
`
`2.2 Requirements
`
`2-2
`
`2.2.1 Hardware requirements
`
`2-2
`
`2.2.2
`
`2.2.3
`
`Software requirements
`
`2-3
`
`J2ME requirements
`
`2-3
`
`2.3
`
`Scope
`
`2-4
`
`3. High-level Architecture and Security 3-1
`
`3.1 Virtual machine environment
`
`3-1
`
`3.2 The concept of a Java Application 3-2
`
`3.3 Application management
`
`3-2
`
`3.4
`
`Security 3-3
`
`3.4.1
`
`Low-level virtual machine security 3-3
`
`3.4.2 Application-level security 3-4
`
`Contents
`
`iv
`
`Ericsson Ex. 2014, Page 4
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`3.4.3 Other security areas
`
`3-5
`
`4. Adherence to the Java Language Specification 4-1
`
`4.1 No floating point support
`
`4-1
`
`4.2 No finalization 4-2
`
`4.3 Error handling limitations
`
`4-2
`
`5. Adherence to Java Virtual Machine Specification 5-1
`
`5.1 No floating point support
`
`5-1
`
`5.2
`
`Features eliminated because of library changes or security concerns
`
`5-3
`
`5.2.1
`
`Java Native Interface (JNI)
`
`5.2.2 User-defined class loaders
`
`5-3
`
`5-3
`
`5.2.3
`
`5.2.4
`
`5.2.5
`
`Reflection 5-4
`
`Thread groups and daemon threads
`
`5-4
`
`Finalization 5-4
`
`5.2.6 Weak references
`
`5-4
`
`5.2.7
`
`Errors
`
`5-5
`
`5.3 Classfile verification 5-5
`
`5.3.1 Off-device pre-verification and runtime verification with stack
`maps
`5-5
`
`5.4 Classfile format and class loading 5-11
`
`5.4.1
`
`5.4.2
`
`Supported file formats
`
`5-11
`
`Public representation of Java applications and resources
`
`5-11
`
`5.4.3 Classfile lookup order
`
`5-12
`
`5.4.4
`
`5.4.5
`
`5.4.6
`
`Implementation optimizations
`
`5-12
`
`Preloading/prelinking (“ROMizing”)
`
`5-13
`
`Future classfile formats
`
`5-13
`
`6. CLDC Libraries
`
`6-1
`
`6.1 Overview 6-1
`
`6.1.1 General goals
`
`6-1
`
`v
`
`Connected, Limited Device Configuration • May 19, 2000
`
`Ericsson Ex. 2014, Page 5
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`6.1.2 Compatibility 6-2
`
`6.2 Classes inherited from J2SE 6-2
`
`6.2.1
`
`System classes
`
`6-3
`
`6.2.2 Data type classes
`
`6-3
`
`6.2.3 Collection classes
`
`6-3
`
`6.2.4
`
`Input/output classes
`
`6-4
`
`6.2.5 Calendar and time classes
`
`6-4
`
`6.2.6 Additional utility classes
`
`6-5
`
`6.2.7
`
`6.2.8
`
`6.2.9
`
`Exception and error classes
`
`6-5
`
`Internationalization 6-6
`
`Property support
`
`6-7
`
`6.3 CLDC-specific classes
`
`6-8
`
`6.3.1
`
`6.3.2
`
`Background and motivation 6-8
`
`The Generic Connection framework 6-8
`
`6.3.3 No implementations provided at the configuration level
`
`6-10
`
`6.3.4 Design of the Generic Connection framework 6-10
`
`6.3.5 Additional remarks
`
`6-14
`
`6.3.6
`
`Examples
`
`6-14
`
`A. Appendices A-1
`
`Contents
`
`vi
`
`Ericsson Ex. 2014, Page 6
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`vii
`
`Connected, Limited Device Configuration (cid:127) May 19, 2000
`
`Ericsson Ex. 2014, Page 7
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`Figures
`
`FIGURE 3-1
`
`High-level architecture 3-1
`
`FIGURE 6-1
`
`Connection interface hierarchy
`
`6-11
`
`Figures
`
`viii
`
`Ericsson Ex. 2014, Page 8
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`ix
`
`Connected, Limited Device Configuration (cid:127) May 19, 2000
`
`Ericsson Ex. 2014, Page 9
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`Preface
`
`This document, Connected, Limited Device Configuration Specification, defines the
`Connected, Limited Device Configuration (CLDC) of Java™ 2 Micro Edition (J2ME™).
`
`A configuration of J2ME specifies the subset of Java programming language features
`supported, the subset of functionality of the configuration’s Java virtual machine,
`the networking, security, installation and possibly other core platform APIs
`supported, all to support a certain group of embedded consumer products.
`
`The Connected, Limited Device Configuration is the basis for one or more profiles. A
`profile of J2ME defines additional sets of APIs and features for a particular vertical
`market, device category or industry. Configurations and profiles are more exactly
`defined in the related publication, Configurations and Profiles Architecture Specification,
`Java 2 Platform Micro Edition (J2ME), Sun Microsystems, Inc.
`
`Who Should Use This Specification
`
`The audience for this document is the Java Community Process (JCP) expert group
`(JSR-30) defining this configuration, device manufacturers who want to build small
`Java-enabled devices, and content developers who want to write Java applications
`for small, resource-constrained, connected devices.
`
`How This Specification Is Organized
`
`The topics in this specification are organized as follows:
`
`Preface
`
`x
`
`Ericsson Ex. 2014, Page 10
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`Chapter 1, “Introduction and Background,” provides a context for the CLDC
`Specification, and lists the names of the companies that have been involved in the
`specification work.
`
`Chapter 2, “Goals, Requirements and Scope,” defines the goals, special
`requirements and scope of this specification.
`
`Chapter 3, “High-level Architecture and Security,” defines the high-level
`architecture of the CLDC, and discusses its security features.
`
`Chapter 4, “Adherence to the Java Language Specification,” defines the variances
`from the standard Java programming language required by the CLDC configuration.
`
`Chapter 5, “Adherence to Java Virtual Machine Specification,” defines the
`variances from the standard Java virtual machine required by the CLDC
`configuration.
`
`Chapter 6, “CLDC Libraries,” defines the specific Java APIs required by the CLDC
`configuration.
`
`Appendix , “Appendices,” is a pointer to a number of appendices that accompany
`this specification.
`
`Related Literature
`The Java Language Specification by James Gosling, Bill Joy, and Guy L. Steele.
`Addison-Wesley, 1996, ISBN 0-201-63451-1
`The Java Virtual Machine Specification (Java Series), Second Edition by Tim Lindholm
`and Frank Yellin. Addison-Wesley, 1999, ISBN 0-201-43294-3
`Configurations and Profiles Architecture Specification, Java 2 Platform Micro Edition
`(J2ME), Sun Microsystems, Inc.
`Java 2 Platform: Micro Edition, A White Paper, Sun Microsystems, Inc.
`
`The K Virtual Machine (KVM), A White Paper, Sun Microsystems, Inc.
`
`xi
`
`Connected, Limited Device Configuration (cid:127) May 19, 2000
`
`Ericsson Ex. 2014, Page 11
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`Modification History
`
`TABLE P-1 Modification History
`
`Version
`
`1.0
`
`1.0a
`
`Description
`
`CLDC Specification 1.0 Final Release
`
`Updated the copyright page. No other changes.
`
`Preface
`
`xii
`
`Ericsson Ex. 2014, Page 12
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`xiii
`
`Connected, Limited Device Configuration (cid:127) May 19, 2000
`
`Ericsson Ex. 2014, Page 13
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`1
`
`Introduction and Background
`
`This document specifies the Connected, Limited Device Configuration (CLDC) of
`Java™ 2 Platform, Micro Edition (J2ME™). The goal of this work is to define a
`standard, minimum-footprint Java platform for small, resource-constrained,
`connected devices characterized as follows:
`I 160 kB to 512 kB of total memory budget available for the Java platform (see
`Section 2.2.1, “Hardware requirements”.)
`I a 16-bit or 32-bit processor
`I low power consumption, often operating with battery power
`I connectivity to some kind of network, often with a wireless, intermittent
`connection and with limited (often 9600 bps or less) bandwidth
`
`Cell phones, two-way pagers, personal digital assistants (PDAs), organizers, home
`appliances, and point of sale terminals are some, but not all, of the devices that
`might be supported by this specification.
`
`This J2ME configuration specification defines the minimum required complement of
`Java technology components and libraries for small connected devices. Java
`language and virtual machine features, core libraries, input/output, networking and
`security are the primary topics addressed by this specification.
`
`This specification is the result of the work of a Java Community Process (JCP) expert
`group JSR-30 consisting of a number of industrial partners. The following companies
`(in alphabetical order) have been involved in the definition of CLDC:
`I America Online
`I Bull
`I Ericsson
`I Fujitsu
`I Matsushita
`I Mitsubishi
`I Motorola
`I Nokia
`I NTT DoCoMo
`I Oracle
`
`Chapter 1
`
`Introduction and Background
`
`1-1
`
`Ericsson Ex. 2014, Page 14
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`I Palm Computing
`I RIM
`I Samsung
`I Sharp
`I Siemens
`I Sony
`I Sun Microsystems
`I Symbian
`
`CLDC is core technology that will be used as the basis for one or more profiles. A
`J2ME profile defines a more comprehensive and focused Java platform for a
`particular vertical market, device category or industry.
`
`For definitive information about J2ME configurations and profiles, refer to
`Configurations and Profiles Architecture Specification, Java 2 Platform Micro Edition
`(J2ME), Sun Microsystems, Inc. Some information about Java 2 Micro Edition,
`configurations and profiles is provided in Appendix 1. That appendix also provides
`information on KVM, a Java virtual machine that can be used to run the Connected,
`Limited Device Configuration.
`
`1-2
`
`Connected, Limited Device Configuration (cid:127) May 19, 2000
`
`Ericsson Ex. 2014, Page 15
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`2
`
`Goals, Requirements and Scope
`
`2.1
`
`Goals
`
`The high-level goal for the Connected, Limited Device Configuration (CLDC) is to
`define a standard, minimum-footprint Java™ platform for small, resource-
`constrained, connected devices. The devices targeted by the CLDC have the
`following general characteristics:
`I 160 kB to 512 kB of total memory budget available for the Java platform (see
`Section 2.2.1, “Hardware requirements”.)
`I a 16-bit or 32-bit processor
`I low power consumption, often operating with battery power
`I connectivity to some kind of network, often with a wireless, intermittent
`connection and with limited (often 9600 bps or less) bandwidth
`
`Typically, these target devices are manufactured in very large quantities (hundreds
`of thousands or even millions of units), meaning that manufacturers are usually
`extremely cost-conscious and interested in keeping the per-unit costs as low as
`possible.
`
`2.1.1
`
`Dynamic delivery of Java applications and
`content
`Based on the feedback from the CLDC expert group, one of the greatest benefits of
`Java technology in the small device space is the dynamic, secure delivery of
`interactive content and applications over different kinds of networks to small client
`devices. Unlike in the past, when small devices such as cell phones and pagers
`usually came with a hard-coded feature set, device manufacturers are increasingly
`looking for solutions that allow them to build extensible devices that support rich,
`
`Chapter 2 Goals, Requirements and Scope
`
`2-1
`
`Ericsson Ex. 2014, Page 16
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`2.1.2
`
`2.2
`
`2.2.1
`
`dynamic, interactive content from 3rd party content providers and developers. With
`the recent introduction of Internet-enabled cell phones, communicators and pagers,
`this transition is already underway. One of the main goals of this CLDC Specification
`is to take this transition several steps further by allowing the use of the Java
`programming language as the standard platform for secure delivery of dynamic
`content for these extensible next-generation devices.
`
`Targeting 3rd party application developers
`The focus on dynamically delivered Java applications means that this specification is
`intended not just for hardware manufacturers and their system programmers, but
`also for 3rd party application developers. In fact, we assume that once small Java-
`enabled devices become commonplace, the vast majority of application developers
`for these devices will be 3rd party developers rather than device manufacturers
`themselves.
`
`This trend has certain implications for the Java platform features and APIs to be
`included in this specification. First, the specification shall include only high-level
`libraries that provide sufficient programming power for the 3rd party application
`developer. For instance, the networking APIs to be included in CLDC should
`provide the programmer with meaningful high-level abstractions, such as the ability
`to transfer whole files, applications or web pages at once, rather than require the
`programmer to know about the details of specific network transmission protocols.
`Second, we emphasize the importance of generality and portability. The CLDC
`Specification shall not focus on any specific device category or vertical market.
`
`Requirements
`
`Hardware requirements
`CLDC is intended to run on a wide variety of small devices ranging from wireless
`communication devices such as cellular telephones and two-way pagers to personal
`organizers, point-of-sale terminals and even home appliances. The underlying
`hardware capabilities of these devices vary considerably, and therefore the CLDC
`Specification does not impose any specific hardware requirements other than memory
`requirements.
`
`This specification assumes that the virtual machine, the configuration libraries, the
`profile libraries and the applications must all fit within a total memory budget of
`160-512 kilobytes. More specifically, we assume that:
`
`2-2
`
`Connected, Limited Device Configuration (cid:127) May 19, 2000
`
`Ericsson Ex. 2014, Page 17
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`I 128 kilobytes of non-volatile1 memory is available for the Java virtual machine
`and CLDC libraries.
`I at least 32 kilobytes of volatile2 memory is available for the Java runtime and
`object memory.
`
`The ratio of volatile to non-volatile memory in the total memory budget varies
`considerably depending on the target device and the role of the Java platform in the
`device. If the Java platform is used strictly for running system applications that have
`been built in a device, then applications can be prelinked and a very limited amount
`of volatile memory will be needed. If the Java platform is used for running
`dynamically downloaded content, then devices will need a higher ratio of volatile
`memory.
`
`2.2.2
`
`Software requirements
`
`2.2.3
`
`Like the hardware capabilities, the system software in CLDC devices varies
`considerably. For instance, some of the devices may have a full-featured operating
`system that supports multiple, concurrent operating system processes and a
`hierarchical file system. Many other devices may have extremely limited system
`software with no notion of a file system. Faced with such variety, CLDC makes
`minimal assumptions about the system software available in CLDC devices.
`
`Generally, this specification assumes that a minimal host operating system (see
`Section 3.1, “Virtual machine environment”) or kernel is available to manage the
`underlying hardware. This host operating system must provide at least one
`schedulable entity to run the Java virtual machine. The host operating system does
`not need to support separate address spaces or processes, nor must it make any
`guarantees about the real-time scheduling or latency behavior.
`
`J2ME requirements
`CLDC is defined as a Java 2 Micro Edition (J2ME™) configuration. This has certain
`important implications for the CLDC Specification:
`I A J2ME configuration shall only define a minimum complement or the “lowest
`common denominator” of Java technology. All the features included in a
`configuration must be generally applicable to a wide variety of devices. Features
`1. The term non-volatile is used to indicate that the memory is expected to retain its contents between the user
`turning the device “on” or “off”. For the purposes of this specification, it is assumed that non-volatile memory
`is usually accessed in read mode, and that special setup may be required to write to it. Examples of non-
`volatile memory include ROM, Flash and battery-packed SDRAM. Actual memory technology is outside the
`scope of this specification.
`2. The term volatile is used to indicate that the memory is not expected to retain its contents between the user
`turning the device “on” or “off”. For the purposes of this specification, it is assumed that volatile memory can
`be read and written to directly without any special setup. The most common type of volatile memory is
`DRAM.
`
`Chapter 2 Goals, Requirements and Scope
`
`2-3
`
`Ericsson Ex. 2014, Page 18
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`specific to a certain vertical market, device category or industry should be defined
`in a profile rather than in CLDC. This means that the scope of CLDC is limited and
`must generally be complemented by profiles.
`I Since the goal of the configuration is to guarantee portability and interoperability
`between various kinds of resource-constrained devices, the configuration shall not
`define any optional features. This limitation has a significant impact on what can be
`included in the configuration and what should not be included. The more
`domain-specific functionality must be defined in profiles rather than in CLDC.
`
`For further information on the rules and guidelines for defining J2ME configurations
`and profiles, refer to Configurations and Profiles Architecture Specification, Java 2
`Platform Micro Edition (J2ME), Sun Microsystems, Inc.
`
`Note that the absence of optional features in CLDC does not preclude the use of
`various implementation-level optimizations. For instance, at the implementation level
`alternative execution techniques (e.g., JIT compilation) or class representation
`techniques can be used, as long as the observable user-level semantics of the
`implementation remain the same as defined by the CLDC Specification.
`
`2.3
`
`Scope
`
`Based on the decisions of the JSR-30 expert group, this CLDC Specification will
`address the following areas:
`I Java language and virtual machine features
`I Core Java libraries (java.lang.*, java.util.*)
`I Input/output
`I Networking
`I Security
`I Internationalization
`
`This CLDC Specification shall not address the following features:
`I Application life-cycle management (application installation, launching, deletion)
`I User interface functionality
`I Event handling
`I High-level application model (the interaction between the user and the
`application)
`
`These features can be addressed by profiles implemented on top of the CLDC.
`
`The CLDC expert group is intentionally trying to keep small the number of areas
`addressed by CLDC. It seems better to restrict the scope of CLDC in order not to
`exceed the strict memory limitations or to exclude any particular device category.
`Future versions of this CLDC Specification might address additional areas.
`
`2-4
`
`Connected, Limited Device Configuration (cid:127) May 19, 2000
`
`Ericsson Ex. 2014, Page 19
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`The rest of this specification is organized as follows. It starts with a discussion of the
`high-level architecture of a typical CLDC environment. Then, it compares the Java
`language and virtual machine features of a Java virtual machine (JVM) supporting
`CLDC to a conventional Java environment. Finally, it details the Java libraries
`included in CLDC.
`
`Chapter 2 Goals, Requirements and Scope
`
`2-5
`
`Ericsson Ex. 2014, Page 20
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`2-6
`
`Connected, Limited Device Configuration (cid:127) May 19, 2000
`
`Ericsson Ex. 2014, Page 21
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`3
`
`High-level Architecture and
`Security
`
`This chapter discusses the high-level architecture of a typical CLDC environment.
`This discussion serves as a starting point for more detailed specification in later
`chapters.
`
`Profiles
`
`CLDC Libraries
`
` Java Virtual Machine
` Java Virtual Machine
`
`Host Operating System
`
`FIGURE 3-1 High-level architecture
`
`3.1
`
`Virtual machine environment
`
`The high-level architecture of a typical CLDC device is illustrated in FIGURE 3-1. At
`the heart of a CLDC implementation is the Java Virtual Machine, which, apart from
`specific differences defined later in this specification, is compliant with the Java
`Virtual Machine Specification and Java Language Specification. The virtual machine
`typically runs on top of a host operating system that is outside the scope of CLDC.
`
`Chapter 3
`
`High-level Architecture and Security
`
`3-1
`
`Ericsson Ex. 2014, Page 22
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`On top of the virtual machine are the Java libraries. These libraries are divided into
`two categories:
`
`1. those defined by the Connected, Limited, Device Configuration, and
`
`2. those defined by profiles
`
`3.2
`
`The concept of a Java Application
`
`Throughout this specification, the term Java application is used to refer to a collection
`of Java classfiles containing a single, unique method main that identifies the
`launchpoint of the application. As specified in Java Virtual Machine Specification
`(JVMS), §5.2, §2.17.1, the method main must be declared public, static and void,
`as shown below:
`public static void main(String[] args)
`
`A JVM supporting CLDC starts the execution of a Java application by calling the
`method main.
`
`3.3
`
`Application management
`
`Many small, resource-constrained devices do not have a file system or any other
`standard mechanism for storing dynamically downloaded information on the
`device. Therefore, a CLDC implementation shall not require that Java classes
`downloaded from an external source are stored persistently on the device. Rather,
`the virtual machine might just load the classfiles and discard them after loading.
`
`However, in many potential CLDC devices it is beneficial to be able to execute the
`same Java applications several times without having to download the applications
`over and over again. This is particularly important if applications are being
`downloaded over a wireless network, where the user could incur high downloading
`expenses.
`
`We assume that a device implementing CLDC has capabilities for managing the Java
`applications that have been stored in the device. At the high level, application
`management refers to the ability to:
`I inspect existing Java applications stored on the device
`I select and launch Java applications
`I delete existing Java applications (if applicable)
`
`3-2
`
`Connected, Limited Device Configuration (cid:127) May 19, 2000
`
`Ericsson Ex. 2014, Page 23
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`Due to significant variations and feature differences among potential CLDC devices,
`the details of application management are highly device-specific and
`implementation-dependent. Consequently, application management capabilities are
`often written in the C programming language or some other low-level programming
`language specific to the host operating system. The actual details regarding
`application management are outside the scope of CLDC Specification.
`
`3.4
`
`Security
`
`3.4.1
`
`One of the greatest promises of the Java platform is the ability to dynamically
`deliver interactive content and applications in a secure way to client devices over
`different kinds of networks.
`
`Unfortunately, the total amount of code devoted to security in Java 2 Standard
`Edition far exceeds the memory budget available for a Java virtual machine
`supporting CLDC. Therefore, some compromises are necessary when defining the
`security model for the CLDC. Our general guideline for defining the security model
`for CLDC has been to keep things simple, and allow for more comprehensive
`security solutions in later versions of this CLDC Specification.
`
`The focus in this specification is on two areas:
`
`1. low-level virtual machine security, and
`
`2. application-level security.
`
`Low-level virtual machine security
`In this specification, low-level virtual machine security means that a Java application
`executed by the virtual machine must not be able to harm the device in which it is
`running. In a standard Java virtual machine implementation, this constraint is
`guaranteed by the Java classfile verifier, which ensures that the Java bytecodes and
`other items stored in Java classfiles cannot contain references to invalid memory
`locations or memory areas that are outside the Java object memory (the Java heap).
`The role of the classfile verifier is to ensure that classfiles loaded into the virtual
`machine shall not execute in any way that is not allowed by the Java Virtual
`Machine Specification.
`
`As will be explained in more detail in Section 5.3, “Classfile verification,” this CLDC
`Specification requires that a JVM supporting CLDC must be able to reject invalid
`classfiles. This can be guaranteed by utilizing the verification technology defined in
`Section 5.3.1.
`
`Chapter 3
`
`High-level Architecture and Security
`
`3-3
`
`Ericsson Ex. 2014, Page 24
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`3.4.2
`
`Application-level security
`
`Even in a standard Java environment, the security provided by the classfile verifier
`is limited. The verifier can only guarantee that the given program is a valid Java
`program, and nothing more. There are still several other potential security threats
`that will go unnoticed by the verifier. For instance, access to external resources such
`as the file system, printers, infrared devices or the network is beyond the scope of
`the verifier.
`
`To provide controlled access to external resources from Java applications, a J2SE or
`J2EE environment provides the concept of a security manager. A security manager is
`called whenever the various parts of a Java application or the Java runtime system
`need access to a protected resource. J2SE provides a very comprehensive security
`model consisting of formal notions of permissions, access controllers, and security
`policies.
`
`Unfortunately, the J2SE security model is too memory-consuming to be included in a
`CLDC device that allows only a few hundred kilobytes of total memory budget.
`Therefore, a simpler solution is needed.
`
`3.4.2.1
`
`Sandbox model
`
`A JVM supporting CLDC provides a simple “sandbox” security model. By a sandbox
`we mean that a Java application must run in a closed environment in which the
`application can only access th