J2ME Building Blocks for
`Mobile Devices
`
`White Paper on KVM and the Connected, Limited
`Device Configuration (CLDC)
`
`Sun Microsystems, Inc.
`901 San Antonio Road
`Palo Alto, CA 94303 USA
`650 960-1300
`fax 650 969-9131
`
`May 19, 2000
`
`Ericsson Ex. 2013, Page 1
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`Copyright © 2000 Sun Microsystems, Inc.
`
`901 San Antonio Road, Palo Alto, CA 94303 USA
`
`All rights reserved. Copyright in this document is owned by Sun Microsystems, Inc.
`
`Sun Microsystems, Inc. (SUN) hereby grants to you at no charge a nonexclusive, nontransferable,
`worldwide, limited license (without the right to sublicense) under SUN's intellectual property rights that are
`essential to practice the Java 2 Platform Micro Edition, K Virtual Machine (KVM) or J2ME CLDC Reference
`Implementation technologies to use this document for internal evaluation purposes only. Other than this
`limited license, you acquire no right, title, or interest in or to the document and you shall have no right to
`use the document for productive or commercial use.
`
`RESTRICTED RIGHTS LEGEND
`
`Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g)(2)(6/87)
`and FAR 52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-1(a).
`
`SUN MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THE
`SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
`WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-
`INFRINGEMENT. SUN SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A
`RESULT OF USING, MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES.
`
`TRADEMARKS
`
`Sun, Sun Microsystems, the Sun logo, Java, PersonalJava, Java Card, Jini, JDK, and Java Embedded Server
`are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
`
`THIS PUBLICATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
`IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,
`FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
`
`THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS.
`CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE
`INCORPORATED IN NEW EDITIONS OF THE PUBLICATION. SUN MICROSYSTEMS, INC. MAY MAKE
`IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED
`IN THIS PUBLICATION AT ANY TIME.
`
`Ericsson Ex. 2013, Page 2
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`Contents
`
`1. Executive Summary 1
`
`Information Appliances and the Wireless Revolution 1
`
`Everything Connected 1
`
`Customizable, Personal Services
`
`2
`
`Java™ 2 Platform Micro Edition (J2ME™)
`
`4
`
`J2ME Configurations and Profiles
`
`4
`
`Connected, Limited Device Configuration (CLDC)
`
`7
`
`The K Virtual Machine
`
`7
`
`About this White Paper
`
`7
`
`2.
`
`Introduction to the Java 2 Platform Micro Edition, CLDC, and KVM 9
`
`Java Editions
`
`9
`
`Java 2 Platform Micro Edition (J2ME)
`
`10
`
`J2ME Building Blocks: Configurations and Profiles
`
`11
`
`J2ME Profiles
`
`12
`
`J2ME Configurations
`
`15
`
`KVM 17
`
`3. The Connected, Limited Device Configuration (CLDC)
`
`19
`
`CLDC Goals
`
`19
`
`CLDC Requirements
`
`20
`
`Contents
`
`iii
`
`Ericsson Ex. 2013, Page 3
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`CLDC Scope
`
`20
`
`Security 21
`
`Adherence to the Java Language Specification 21
`
`Adherence to the Java Virtual Machine Specification 22
`
`Classfile Verification 22
`
`Classfile Format
`
`23
`
`CLDC Libraries
`
`24
`
`Classes Inherited from J2SE 24
`
`System Classes
`
`24
`
`Data Type Classes
`
`Collection Classes
`
`24
`
`24
`
`I/O Classes
`
`25
`
`Calendar and Time Classes
`
`25
`
`Additional Utility Classes
`
`25
`
`Exception Classes
`
`25
`
`Error Classes
`
`26
`
`Limitations
`
`26
`
`CLDC-Specific Classes
`
`26
`
`General Form 26
`
`Examples
`
`27
`
`Generic Connection Framework Interfaces
`
`27
`
`4. The K Virtual Machine (KVM)
`
`29
`
`Introduction to the KVM 29
`
`Sun Implementations
`
`30
`
`Other Implementations
`
`30
`
`Compiler Requirements
`
`30
`
`Porting KVM 31
`
`iv
`
`J2ME Building Blocks for Mobile Devices • May 19, 2000
`
`Ericsson Ex. 2013, Page 4
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`Compilation Control
`
`32
`
`Virtual Machine Startup and JAM 32
`
`Class Loading 33
`
`64-Bit Support
`
`33
`
`Native Code
`
`33
`
`Event Handling 33
`
`Classfile Verification 34
`
`Java Code Compact (ROMizer)
`
`34
`
`5.
`
`Future Directions
`
`35
`
`Contents
`
`v
`
`Ericsson Ex. 2013, Page 5
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`vi
`
`J2ME Building Blocks for Mobile Devices (cid:127) May 19, 2000
`
`Ericsson Ex. 2013, Page 6
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`1
`
`Executive Summary
`
`Information Appliances and the Wireless Revolution
`Connected, personalized, intelligent information appliances are becoming
`increasingly important in our business and private lives. These appliances,
`which include devices such as cell phones, two-way pagers, personal
`organizers, screen phones, and POS terminals, have many things in common.
`But they are also diverse in features, form, and function. They tend to be
`special-purpose, limited-function devices, not the general-purpose computing
`machines we have known in the past.
`
`The number of these information appliances is increasing rapidly. For instance,
`the total number of cell phone shipments is expected to be around 350 million
`units this year alone. The total number of wireless subscribers in the world is
`expected to exceed one billion by the end of 2002 or early 2003. Compare this
`to the installed base of personal computers, which at the beginning of 2000 was
`around 311 million worldwide.
`
`Everything Connected
`
`We anticipate that within the next two to five years, the majority of new
`information appliances will be connected to the Internet. This will lead to a
`radical change in the way people perceive and use these devices. The users of
`the information appliances will want to access information—Web content,
`enterprise data, and personal data—conveniently from anywhere, any time,
`and from a variety of devices (Figure 1-1).
`
`1
`
`Ericsson Ex. 2013, Page 7
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`1
`
`Web Content
`Enterprise Data
`Personal Data
`
`Any Information
`
`Pen computer
`
`PDA
`
`Digitizer
`
`Any Device
`
`Internet
`
`Figure 1-1 Everything connected to the Internet
`
`Customizable, Personal Services
`An important consequence of the connected nature of new information
`appliances is that these devices will be much more customizable and personal
`than the appliances we have today.
`
`2
`
`J2ME Building Blocks for Mobile Devices—May 19, 2000
`
`Ericsson Ex. 2013, Page 8
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`1
`
`Unlike in the past, when devices such as cell phones came with a hard-coded
`feature set, the new devices will allow the users to customize their devices by
`downloading new services and applications from the Internet.
`
`Several wireless device manufacturers are already working on cell phones that
`allow the users to download new applications such as interactive games,
`banking and ticketing applications, wireless collaboration and so on
`(Figure 1-2).
`
`Advertise
`Advertise
`App on
`App on
`Web Page
`Web Page
`
`User
`User
`Selects
`Selects
`App
`App
`
`User
`User
`Downloads
`Downloads
`App
`App
`
`Web Page
`
`Figure 1-2 Downloading customized services
`
`Such customizability will not be limited to just communication devices such as
`cell phones or two-way pagers. For instance, it is quite realistic to imagine
`automobile engines to obtain new service updates as they become available,
`washing machines to download new washing programs dynamically,
`electronic toys to download updated game programs, and so on.
`
`The need for customizability and personalized applications requires a lot more
`from the application development platform than is available in mainstream
`small consumer devices today. With the power of a widely used, extensible
`programming platform such as the Java™ platform, the development of such
`applications and services will become significantly easier.
`
`Executive Summary—May 19, 2000
`
`3
`
`Ericsson Ex. 2013, Page 9
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`1
`
`Java™ 2 Platform Micro Edition (J2ME™)
`To meet the demand for information appliances in the rapidly developing
`consumer and embedded markets, Sun has extended the scope of Java
`technology with the introduction of Java™ 2 Platform, Micro Edition (J2ME™). The
`versatility of the Java application development environment is now enabling
`the development of many new and powerful information appliance products.
`Java technology enables users, service providers, and device manufacturers to
`take advantage of a rich portfolio of application content that can be delivered
`to the user’s device on demand, by wired or wireless connections.
`
`The main benefits of CLDC devices involve:
`• Cross-Platform
`Work is transferred between CLDC and other devices.
`(cid:127) Dynamic Content
`Content is determined by user experience, and information transfer between
`CLDC and other devices.
`Security
`(cid:127) Developer Community
`The developer talent needed for these devices already exists and is readily
`available for CLDC devices.
`
`J2ME Configurations and Profiles
`Serving the information appliance market calls for a large measure of flexibility
`in how computing technology and applications are deployed. This flexibility is
`required because of
`
`1. the large range of existing device types and hardware configurations,
`
`2. constantly improving device technology,
`
`3. the diverse range of existing applications and features, and
`
`4. the need for applications and capabilities to change and grow (often in
`unforeseen ways) in order to accommodate the future needs of the
`consumer.
`
`4
`
`J2ME Building Blocks for Mobile Devices—May 19, 2000
`
`Ericsson Ex. 2013, Page 10
`TCL et al. v Ericsson
`IPR2015-01605
`
`(cid:127)
`

`
`1
`
`Users want the ability to purchase economically-priced products with basic
`functionality and then use them with ever-increasing sophistication.
`
`In order to support this kind of flexibility and customizable deployment
`demanded by the consumer and embedded market, the J2ME architecture is
`designed to be modular and scalable. This modularity and scalability are
`defined by J2ME as three layers of software built upon the Host Operating
`System of the device:
`Java Virtual Machine. This layer is an implementation of a Java virtual
`machine that is customized for a particular device’s host operating system
`and supports a particular J2ME configuration.
`(cid:127) Configuration. The configuration is less visible to users, but is very important
`to profile implementers. It defines the minimum set of Java virtual machine
`features and Java class libraries available on a particular “category” of
`devices representing a particular “horizontal” market segment. In a way, a
`configuration defines the “lowest common denominator” of the Java
`platform features and libraries that the developers can assume to be
`available on all devices.
`Profile. The profile is the most visible layer to users and application
`providers. It defines the minimum set of Application Programming
`Interfaces (APIs) available on a particular “family” of devices representing a
`particular “vertical” market segment. Profiles are implemented “upon” a
`particular configuration. Applications are written “for” a particular profile
`and are thus portable to any device that “supports” that profile. A device
`can support multiple profiles.
`
`Executive Summary—May 19, 2000
`
`5
`
`Ericsson Ex. 2013, Page 11
`TCL et al. v Ericsson
`IPR2015-01605
`
`(cid:127)
`(cid:127)
`

`
`1
`
`The three layers built upon the Host Operating System are illustrated in
`Figure 1-3.
`
`Profiles
`
`Configuration
`
`Java Virtual Machine
`Virtual Machine
`
`Host Operating System
`
`Figure 1-3 J2ME software layer stack
`
`In J2ME, a Java virtual machine implementation and a configuration
`specification are very closely aligned. Together they are designed to capture
`just the essential capabilities of each category of device. Further differentiation
`into device families is provided with the additional APIs specified at the
`profile layer. To meet the need of new and exciting applications, profiles can be
`augmented with additional Java class libraries.
`
`Over time, as device manufacturers develop new families and/or categories of
`devices, J2ME will provide a range of profiles, configurations, and virtual
`machine technologies, each optimized for the different application
`requirements and memory footprints commonly found in the consumer and
`embedded marketplace. These will be specified through the Java Community
`Process (JCP).
`
`The J2ME architecture currently has two configurations that have been defined
`using the JCP. The Connected Device Configuration (CDC) uses the classic Java
`virtual machine, a full-featured VM that includes all the functionality of a
`
`6
`
`J2ME Building Blocks for Mobile Devices—May 19, 2000
`
`Ericsson Ex. 2013, Page 12
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`1
`
`virtual machine residing on a desktop system. This configuration is intended
`for devices with at least a few megabytes of available memory.
`
`For wireless devices and other systems with severely constrained memory
`environments, J2ME uses the Connected Limited Device Configuration (CLDC),
`discussed in more detail below.
`
`Connected, Limited Device Configuration (CLDC)
`The configuration for mobile devices or the Connected, Limited Device
`Configuration (CLDC) defines targeted Java platforms which are small,
`resource-constrained devices, each with a memory budget in the range of 160
`kB to 512 kB. The CLDC is composed of the K Virtual Machine (KVM) and core
`class libraries that can be used on a variety of devices such as cell phones, two-
`way pagers, personal organizers, home appliances, and so on. Eighteen
`companies, mostly wireless device manufacturers, have participated in the
`definition of this configuration using the Java Community Process (JCP).
`
`The K Virtual Machine
`
`About this White Paper
`
`The K Virtual Machine (KVM), a key feature of the J2ME architecture, is a
`highly portable Java virtual machine designed from the ground up for small-
`memory, limited-resource, network-connected devices such as cellular phones,
`pagers, and personal organizers. These devices typically contain 16- or 32-bit
`processors and a minimum total memory footprint of approximately 128
`kilobytes. However, the KVM can be deployed flexibly in a wide variety of
`devices appropriate for various industries and the large range of trade-offs
`among processor power, memory size, device characteristics, and application
`functionality they engender.
`
`The purpose of this white paper is to describe the current reference
`implementation of KVM along with the closely related Connected, Limited
`Device Configuration (CLDC). Chapter 2 sets the stage for this discussion by
`providing an expanded introduction to the Java 2 Micro Edition. Then, Chapter
`3 reviews the essential features of the Connected, Limited Device
`Configuration and the APIs that it defines. Chapter 4 provides more detailed
`information on KVM and on what is required when porting it to new devices.
`
`Executive Summary—May 19, 2000
`
`7
`
`Ericsson Ex. 2013, Page 13
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`1
`
`Finally, Chapter 5 briefly discusses the future directions of KVM and CLDC
`technology.
`
`8
`
`J2ME Building Blocks for Mobile Devices—May 19, 2000
`
`Ericsson Ex. 2013, Page 14
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`Java Editions
`
`2
`
`Introduction to the Java 2 Platform
`Micro Edition, CLDC, and KVM
`
`Recognizing that one size does not fit all, Sun has grouped its Java
`technologies into three editions, each aimed at a specific area of today’s vast
`computing industry:
`Java 2 Enterprise Edition (J2EE)—for enterprises needing to serve their
`customers, suppliers, and employees with solid, complete, and scalable
`Internet business server solutions.
`Java 2 Standard Edition (J2SE)—for the familiar and well-established desktop
`computer market.
`Java 2 Micro Edition (J2ME)—for the combined needs of:
`— consumer and embedded device manufacturers who build a diversity of
`information devices;
`— service providers who wish to deliver content to their customers over
`those devices; and
`— content creators who want to make compelling content for small,
`resource-constrained devices.
`
`Each Java edition defines a set of technology and tools that can be used with a
`particular product:
`Java virtual machines that fit inside a wide range of computing devices;
`libraries and APIs specialized for each kind of computing device; and
`tools for deployment and device configuration.
`
`9
`
`Ericsson Ex. 2013, Page 15
`TCL et al. v Ericsson
`IPR2015-01605
`
`(cid:127)
`(cid:127)
`(cid:127)
`(cid:127)
`(cid:127)
`(cid:127)
`

`
`2
`
`Figure 2-1 below illustrates the target markets of each edition.
`
`workstation
`
`server
`
`communicator
`
`NC
`
`PDA
`
`POS
`
`pager
`
`PC, laptop
`
`Java 2
`Enterprise
`Edition
`
`Java 2
`Standard
`Edition
`
`HotSpot
`Memory:
`
`set-top box,
`net TV
`
`screen-
`phone
`
`CDCCDC
`
`smartphone cell phone
`CLDC
`CLDC
`Java 2 Micro Edition
`Java Language
`JVM
`
`KVM
`
`10MB
`64 bit
`
`1MB 512kB
`32 bit
`
`32kB
`16 bit
`
`card
`
`Card VM
`
`8 bit
`
`Figure 2-1 Java 2 editions and their target markets
`
`Java 2 Platform Micro Edition (J2ME)
`J2ME specifically addresses the large, rapidly growing consumer space, which
`covers a range of devices from tiny commodities, such as pagers, all the way
`up to the TV set-top box, an appliance almost as powerful as a desktop
`computer. Like the “larger” Java editions, Java 2 Micro Edition maintains the
`qualities that Java technology has become known for:
`built-in consistency across products in terms of running anywhere, any time,
`on any device;
`the power of a high-level object-oriented programming language with a
`large developer base;
`portability of code;
`safe network delivery; and
`upward scalability with J2SE and J2EE.
`
`10
`
`J2ME Building Blocks for Mobile Devices—May 19, 2000
`
`Ericsson Ex. 2013, Page 16
`TCL et al. v Ericsson
`IPR2015-01605
`
`(cid:127)
`(cid:127)
`(cid:127)
`(cid:127)
`(cid:127)
`

`
`2
`
`With J2ME, Sun provides a complete end-to-end solution for creating
`dynamically extensible, networked products and applications for the consumer
`and embedded market. J2ME enables device manufacturers, service providers,
`and content creators to gain a competitive advantage and capitalize on new
`revenue streams by developing and deploying compelling new applications
`and services to their customers worldwide.
`
`At a high level, J2ME is currently targeted at two broad categories of products:
`Shared, fixed, connected information devices. In Figure 2-1, this category is
`represented by the grouping labeled CDC (Connected Device
`Configuration). Typical examples of devices in this category include TV set-
`top boxes, Internet TVs, Internet-enabled screenphones, high-end
`communicators, and automobile entertainment/navigation systems. These
`devices have a large range of user interface capabilities, memory budgets in
`the range of 2 to 16 megabytes, and persistent, high-bandwidth network
`connections, most often using TCP/IP.
`Personal, mobile, connected information devices. In Figure 2-1, this category is
`represented by the grouping labeled CLDC (Connected, Limited Device
`Configuration). Cell phones, pagers and personal organizers are examples of
`devices in this category. These devices have very simple user interfaces
`(compared to desktop computer systems), minimum memory budgets
`starting at about 128 kilobytes, and low bandwidth, intermittent network
`connections. In this category of products, network communications are often
`not based on the TCP/IP protocol suite.
`
`The line between these two product categories is fuzzy and becoming more so
`every day. As a result of the ongoing technological convergence in the
`computer, telecommunication, consumer electronics and entertainment
`industries, there will be less distinction between general-purpose computers,
`personal communication devices, consumer electronics devices and
`entertainment devices. Also, future devices are more likely to use wireless
`connectivity instead of traditional fixed or wired networks. In practice, the line
`between the two categories is defined more by the memory budget, bandwidth
`considerations, battery power consumption, and physical screen size of the
`device, rather than by its specific functionality or type of connectivity.
`
`J2ME Building Blocks: Configurations and Profiles
`While connected consumer devices such as cell phones, pagers, personal
`organizers and set-top boxes have many things in common, they are also
`diverse in form, function and features. Information appliances tend to be
`
`Introduction to the Java 2 Platform Micro Edition, CLDC, and KVM—May 19, 2000
`
`11
`
`Ericsson Ex. 2013, Page 17
`TCL et al. v Ericsson
`IPR2015-01605
`
`(cid:127)
`(cid:127)
`

`
`2
`
`J2ME Profiles
`
`special-purpose, limited-function devices. To address this diversity, an essential
`requirement for J2ME is not only small size but also modularity and
`customizability.
`
`The J2ME architecture is modular and scalable so that it can support the kinds
`of flexible deployment demanded by the consumer and embedded markets. To
`enable this, J2ME provides a range of virtual machine technologies, each
`optimized for the different processor types and memory footprints commonly
`found in the consumer and embedded marketplace.
`
`For low-end, resource-limited products, J2ME supports minimal configurations
`of the Java virtual machine and Java APIs that embody just the essential
`capabilities of each kind of device. As device manufacturers develop new
`features in their devices, or service providers develop new and exciting
`applications, these minimal configurations can be expanded with additional
`APIs or with a richer complement of Java virtual machine features. To support
`this kind of customizability and extensibility, two essential concepts are
`defined by J2ME:
`(cid:127) Configuration. A J2ME configuration defines a minimum platform for a
`“horizontal” category or grouping of devices, each with similar
`requirements on total memory budget and processing power. A
`configuration defines the Java language and virtual machine features and
`minimum class libraries that a device manufacturer or a content provider
`can expect to be available on all devices of the same category.
`Profile. A J2ME profile is layered on top of (and thus extends) a
`configuration. A profile addresses the specific demands of a certain
`“vertical” market segment or device family. The main goal of a profile is to
`guarantee interoperability within a certain vertical device family or domain
`by defining a standard Java platform for that market. Profiles typically
`include class libraries that are far more domain-specific than the class
`libraries provided in a configuration.
`
`J2ME configurations and profiles are defined through the Java Community
`Process (JCP).
`
`Application portability is a key benefit of Java technology in the desktop and
`enterprise server markets. Portability is also a critical element of the J2ME
`value proposition for consumer devices. However, application portability
`requirements in the consumer space are generally quite different from
`
`12
`
`J2ME Building Blocks for Mobile Devices—May 19, 2000
`
`Ericsson Ex. 2013, Page 18
`TCL et al. v Ericsson
`IPR2015-01605
`
`(cid:127)
`

`
`2
`
`portability requirements demanded by the desktop and server markets. In
`most cases consumer devices have substantial differences in memory size,
`networking, and user interface capabilities, making it very difficult to support
`all devices with just one solution.
`
`In general, the consumer device market is not so homogeneous that end users
`expect or require universal application portability. Rather, in the consumer
`space, applications should ideally be fully portable between devices of the
`same kind. For example, consider the following types of consumer devices:
`– cellular telephones
`– washing machines
`– intercommunicating electronic toys
`It seems clear that each of these represents a different “market segment” or
`“device family” or “application domain.” As such, consumers would expect
`useful applications to be portable within a device family. For example:
`I would expect my discount broker’s stock trading application to work on
`each of my cell phones, even though they are from different manufacturers.
`If I found a wonderful grape-juice-stain-removing wash cycle application on
`the Internet, I would be annoyed if it ran on my old brand-X washer, but not
`my new brand-Z washer.
`(cid:127) My child’s birthday party would be less enjoyable if the new robot doesn’t
`“talk to” and “play games with” the new electronic teddy bear.
`
`On the other hand, consumers don’t expect the stock application or an
`automobile service program to run on the washing machine or the toy robot. In
`other words, application portability across different device categories is not
`necessarily very important.
`
`In addition, there are important economic reasons to keep these device families
`separate. Consumer devices compete heavily on cost and convenience, and
`these factors often translate directly into limitations on physical size and
`weight, processor power, memory size, and power consumption (in battery-
`powered devices.) Consumers’ wallets will always favor devices that perform
`the desired functions, but that do not have added cost for unnecessary features.
`
`Thus, the J2ME framework provides the concept of a profile to make it possible
`to define Java platforms for specific vertical markets. A profile defines a Java
`platform for a specific vertical market segment or device category. Profiles can
`serve two distinct portability requirements:
`
`Introduction to the Java 2 Platform Micro Edition, CLDC, and KVM—May 19, 2000
`
`13
`
`Ericsson Ex. 2013, Page 19
`TCL et al. v Ericsson
`IPR2015-01605
`
`(cid:127)
`(cid:127)
`

`
`2
`
`(cid:127) A profile provides a complete toolkit for implementing applications for a
`particular kind of device, such as a pager, set-top box, cell phone, washing
`machine, or interactive electronic toy.
`(cid:127) A profile may also be created to support a significant, coherent group of
`applications that might be hosted on several categories of devices. For
`example, while the differences between set-top boxes, pagers, cell phones,
`and washing machines are significant enough to justify creating a separate
`profile for each, it might be useful for certain kinds of personal information
`management or home banking applications to be portable to each of these
`devices. This could be accomplished by creating a separate profile for these
`kinds of applications and ensuring that this new profile can be easily and
`effectively supported on each of the target devices along with its “normal”
`more device-specific profile.
`
`It is possible for a single device to support several profiles. Some of these
`profiles will be very device-specific, while others will be more application-
`specific. Applications are written “for” a specific profile and are required to use
`only the features defined by that profile. Manufacturers choose which profile(s)
`to support on each of their devices, but are required to implement all features
`of the chosen profile(s). The value proposition to the consumer is that any
`application written for a particular profile will run on any device that supports
`that profile.
`
`In its simplest terms, a profile is a contract between an application and a J2ME
`vertical market segment. All the devices in the market segment agree to
`implement all the features defined in the profile. And the application agrees to
`use only those features defined in the profile. Thus, portability is achieved
`between the applications and the devices served by that profile. New devices
`can take advantage of a large and familiar application base. Most importantly
`new, compelling applications (perhaps completely unforeseen by the original
`profile designers) can be dynamically downloaded to existing devices.
`
`At the implementation level, a profile is defined simply as a collection of Java
`APIs and class libraries that reside on top of a specified configuration and that
`provide the additional domain-specific capabilities for devices in a specific
`market segment.
`
`In our example above, each of the three families of devices (cell phones,
`washing machines, and intercommunicating toys) would be addressed by a
`separate J2ME profile. Of course, the only one of these profiles in existence at
`the current time is the MIDP, designed for cell phones and related devices.
`
`14
`
`J2ME Building Blocks for Mobile Devices—May 19, 2000
`
`Ericsson Ex. 2013, Page 20
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`2
`
`J2ME Configurations
`
`Profiles and the specific rules for defining J2ME profiles are described in more
`detail in separate specifications.
`
`In J2ME, an application is written “for” a particular profile, and a profile is
`“based upon” or “extends” a particular configuration. Thus, all of the features
`of a configuration are automatically included in the profile and may be used by
`applications written for that profile.
`
`A configuration defines a Java platform for a “horizontal” category or
`grouping of devices with similar requirements on total memory budget and
`other hardware capabilities. More specifically, a configuration:
`specifies the Java programming language features supported,
`specifies the Java virtual machine features supported,
`specifies the basic Java libraries and APIs supported.
`
`J2ME is designed so that it can be deployed in more than one configuration.
`Each configuration specifies the Java virtual machine features and a set of APIs
`that the profile implementer (and the applications using that profile) can safely
`assume to be present on all devices when shipped from the factory. Profile
`implementers must design their code to stay within the bounds of the Java
`virtual machine features and APIs specified by that configuration.
`
`In its simplest terms, a configuration is a contract between a profile
`implementer and a device’s Java virtual machine. The virtual machines of all
`the devices in the market segment agree to implement all the features defined
`in the configuration. And the profile implementers agree to use only those
`features defined in the configuration. Thus, portability is achieved between the
`profile and the devices served by that configuration. New devices can take
`advantage of existing profiles. And new profiles can be installed on existing
`devices.
`
`In our example above, each of the three profiles (for cell phones, washing
`machines, and intercommunicating toys) would most likely be built upon the
`same configuration, the CLDC. This configuration provides all the basic
`functionality to serve the needs of each of these, and perhaps many more,
`profiles.
`
`Introduction to the Java 2 Platform Micro Edition, CLDC, and KVM—May 19, 2000
`
`15
`
`Ericsson Ex. 2013, Page 21
`TCL et al. v Ericsson
`IPR2015-01605
`
`(cid:127)
`(cid:127)
`(cid:127)
`

`
`2
`
`To avoid fragmentation, there will be a very limited number of J2ME
`configurations. Currently, the goal is to define two standard J2ME
`configurations (see Figure 2-2):
`(cid:127) Connected, Limited Device Configuration (CLDC). The market consisting
`of personal, mobile, connected information devices is served by the CLDC.
`This configuration includes some new classes, not drawn from the J2SE
`APIs, designed specifically to fit the needs of small-footprint devices.
`(cid:127) Connected Device Configuration (CDC). The market consisting of shared,
`fixed, connected information devices is served by the Connected Device
`Configuration (CDC). To ensure upward compatibility between
`configurations, the CDC shall be a superset of the CLDC.
`
`J2SE
`
`Classes outside J2SE may not
`use the java.* name space
`
`CDC CLDC
`
`Figure 2-2 Relationship between J2ME configurations and Java 2 Standard Edition
`
`Figure 2-2 illustrates the relationship between CLDC, CDC and Java 2 Standard
`Edition (J2SE). As shown in the figure, the majority of functionality in CLDC
`and CDC has been inherited from J2SE. Each class inherited from J2SE must be
`precisely the same or a subset of the corresponding class in Java 2 Standard
`Edition. In addition, CLDC and CDC may introduce a number of features, not
`drawn from the J2SE, designed specifically to fit the needs of small-footprint
`devices. For further details, refer to Configurations and Profiles Architecture
`Specification, Java 2 Platform Micro Edition (J2ME), Sun Microsystems, Inc.
`The most important reason for the configuration layer of J2ME is that
`configurations and Java virtual machines are very closely related and are
`rather complex pieces of software. Small differences in a conf