US20150234482A1

Movatterモバイル変換

Info

Publication number: US20150234482A1
Application number: US14/631,614
Authority: US
Inventors: Steve Jobs; Anthony M. Fadell; Jonathan P. Ive
Original assignee: Apple Inc
Current assignee: Apple Inc
Priority date: 2005-01-07
Filing date: 2015-02-25
Publication date: 2015-08-20
Also published as: CN101120413B; CN101120413A; HK1151125A1; US8259444B2; US7856564B2; US7889497B2; US8993866B2; US11442563B2; US20090172542A1; US7536565B2; US10534452B2; US20190025943A1; US20130035778A1; HK1151126A1; US20060153040A1; US7865745B2; US20060155914A1; US7593782B2; US20110090645A1; HK1109951A1

Abstract

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 13/566,977, filed Aug. 3, 2012 entitled “HIGHLY PORTABLE MEDIA DEVICE” by Jobs et al., which is a continuation of U.S. patent application Ser. No. 12/979,283, filed Dec. 27, 2010 (now U.S. Pat. No. 8,259,444, issued Sep. 4, 2012) entitled “HIGHLY PORTABLE MEDIA DEVICE” by Jobs et al., which is a continuation of U.S. patent application Ser. No. 11/830,746, filed Jul. 30, 2007 (now U.S. Pat. No. 7,889,497, issued Feb. 15, 2011) entitled “HIGHLY PORTABLE MEDIA DEVICE” by Jobs et al., which is a continuation of U.S. patent application Ser. No. 11/212,313 filed Aug. 24, 2005 (now U.S. Pat. No. 7,593,782, issued Sep. 22, 2009) entitled “HIGHLY PORTABLE MEDIA DEVICE” by Jobs et al., which claims priority to U.S. Provisional Patent Application No. 60/642,276, filed Jan. 7, 2005, and entitled “PORTABLE MEDIA DEVICE AND IMPROVED PLAYLIST PROCESSING ON MEDIA DEVICES”, each of which are hereby incorporated herein by reference in their entirety.

BACKGROUND

1. Field of the Invention

The present invention relates to media devices and, more specifically, to portable media players that store and utilize digital media assets.

2. Description of the Related Art

Today, USB drives, also referred to as Flash drives or keychain drives, are popular portable data storage devices. A USB drive can be used in place of other storage mediums such as floppy disks, CDs, DVDs, zip drive disks, etc. In most cases, the USB drive is a plug and play device that includes Flash memory for storing data and a USB connector for connecting to a host device. While these devices work well, they are limited in the operations that they can perform. These devices are only configured for storing and transporting stored data (similar to other portable storage mediums) and therefore they do not include processing components, batteries for powering the processing components, or a user interface that enable users to communicate with the processing components.

Portable media players, also referred to as MP3 players, are also popular today. Portable media players can be grouped into three different categories: those with removable media storage, such as CD or DVD players; those with internal hard drives; and those that store media in non-volatile memory. Each category of portable media player has advantages and drawbacks in terms of size, functionality, battery life, and media storage capabilities.

Those portable media players that store media in non-volatile memory are commonly referred to as Flash MP3 players or Flash media players. Flash media players are often smaller than other types of portable media players. One problem common to many conventional Flash media players is that their small size often results in difficult-to-use media player controls. Although conventional Flash media players typically incorporate a display so that a user can navigate through the media files that are stored on the device, the display adds to the size, weight and power consumption. Even with a display, the media player controls are often not user friendly.

Another common problem with conventional Flash media players is bulky batteries, which are typically required to provide a reasonably long battery life before having to recharge the player or replace the player's batteries. Conventionally, media player designs have been made larger in order to accommodate improved user controls, batteries, and/or a display.

As portable media players have become more popular, there has been an increased demand for improved media player design. Thus, there remains a need for media players having improved user controls, small sizes, and longer battery life.

SUMMARY

Broadly speaking, the invention relates to a media device and methods for operating a media device. The invention is particularly suitable for use with portable media players.

According to one aspect of the invention, a media device can also function as a solid-state drive for data storage. The solid-state drive can store not only media content for media items that can be played or otherwise presented by the portable media device but also data unrelated to media content.

In one embodiment, the form factor of the portable media device is hand-held or smaller. The portable media device may, for example, be small and lightweight enough to be carried in one hand, worn, or placed in a pocket. Although the form factor is generally small and hand-held (or palm-sized), the configuration of the device can vary widely. Some examples of configurations for the form factor are: an elongated stick, a memory stick, a memory drive (e.g., USB drive), etc. In one implementation, the portable media player has no display (display screen).

In another embodiment, the portable media device can use one or more status indicators. The indicators can be audio or visual. As an example, the status indicators can be implemented by dedicated light sources, such as light emitting diodes (LEDs). The indicators can provide visual feedback to a user.

In another embodiment, the portable media device can include a peripheral bus connector that enables the portable media device to removably and easily connect to a peripheral bus port operatively coupled to a host device, such as a personal computer. The portable media device can, therefore, communicate with the host device without using cables or other support devices, i.e., plugs directly into the host device. By way of example, the portable media device may share media files with the host device (or vice versa).

In another embodiment, the portable media device can include a battery and, more particularly, a rechargeable battery. In most cases, the battery serves to power components of the portable media device. In some cases, the battery can be recharged via a peripheral bus.

In yet another embodiment, the portable media device can include one or more input devices so that the portable media device can interact with a user. The input devices may, for example, include switches (e.g., slider switch, buttons, etc.) for controlling media operations or mode/state of the portable media device. In one particular implementation, a slider switch is used to select a media play mode.

According to another aspect of the invention, a portable media device has the capability to store media device status information in persistent memory before powering down. Thereafter, when the portable media device is again powered up, the stored media player status information can be retrieved and utilized.

According to still another aspect of the invention, a method allows a media device to form and/or traverse a media asset playlist in an efficient manner. The media asset playlist can, for example, pertain to a media asset continuous playlist or a media asset shuffle playlist.

The invention can be implemented in numerous ways, including as a method, system, device, apparatus, or computer readable medium. Several embodiments of the invention are discussed below.

As a portable media player, one embodiment of the invention includes at least: a non-volatile memory that stores a plurality of digital media assets and data files; a media player control interface that enables a user of the media player to select at least one of the media assets to be presented; and a controller operatively connected to the memory and the media player control interface. The controller operates in one of a media mode and a data mode. In the media mode, the controller operates to play the selected at least one media asset. In the data mode, the controller operates to store and retrieve data with respect to the memory.

As a portable electronic device in the form of an elongated stick that plugs into a peripheral port on a host computing device, one embodiment of the invention includes at least: a housing; a peripheral bus connector extending out an end of the housing and being configured for insertion into the peripheral port of the host computing device; a non-volatile electronic memory device disposed within the housing and configured to store data; and a media module disposed within the housing and configured to provide media operations on the portable electronic device, the media module cooperating with the non-volatile electronic memory device to retrieve media data therefrom, and the media module presenting the media data to a user of the portable electronic device. The portable electronic device is capable of operating as a removable storage device when connected to the host computing device, and is capable of operating as a media device when disconnected from the host computing device.

As a media player, one embodiment of the invention comprises: a non-volatile memory that stores a plurality of digital media assets; a multi-position switch configured to select a media play mode; a media player control interface that enables a user of the media player to select at least one of the media assets to be presented; and a controller operatively connected to the memory, the multi-position switch and the media player control interface. The controller operates to present the selected at least one media asset as well as to present a next media asset to be presented in accordance with the media play mode.

As a portable electronic device having a Flash memory drive for storing data and a USB connector for engaging a host device, one embodiment of the invention includes at least: a media module configured to provide media operations on the portable electronic device; an on-board battery for powering the media module; and an I/O system including a sliding switch for adjusting an operational mode of the media module. Additionally, the portable electronic device lacks a display and has a hand-held form factor.

As a portable electronic device having a plurality of operational modes, one embodiment of the invention includes at least: a memory device for storing data; a peripheral bus connector for directly connecting the portable electronic device to a port of a host device; and a sliding switch for selecting an operational mode of the portable electronic device from the plurality of operational modes of the portable electronic device.

As a portable electronic device, one embodiment of the invention includes at least: a USB connector for directly connecting the portable electronic device to a port of a host device; a media module configured to provide media operations on the portable electronic device; and an I/O system. Additionally, the portable electronic device lacks a display screen.

Other aspects and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings which illustrate, by way of example, the principles of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:

FIG. 1 is a diagram of a portable media device according to one embodiment of the invention.

FIGS. 2A and 2B are perspective diagrams of a portable media device according to one embodiment of the invention.

FIG. 3 shows the media device plugged into a port located on a laptop computer.

FIGS. 4 and 5 illustrate a media device seated within a user's hand.

FIG. 6 is a diagram of a control input device according to one embodiment.

FIG. 7 is a block diagram of a media device according to one embodiment of the invention.

FIG. 8 is a block diagram of a media management system according to one embodiment of the invention.

FIGS. 9A and 9B are block diagrams of a top surface of a media device according to one embodiment of the invention.

FIG. 9C is a block diagram of a second surface of the media device shown inFIGS. 9A and 9B according to one embodiment of the invention.

FIGS. 10A and 10B are diagrams illustrating user controls for a portable media device according to one embodiment of the invention.

FIG. 11 is a flow diagram of a media player power-down process according to one embodiment of the invention.

FIG. 12 is flow diagram of a media player power-on process according to one embodiment of the invention.

FIG. 13 is a flow diagram of a media asset shuffle playlist traversal process according to one embodiment of the invention.

FIGS. 14A and 14B are flow diagrams of a media asset list traversal process according to one embodiment of the invention.

FIGS. 15A and 15B are illustrations of an exemplary media asset playlist arrangement according to one embodiment of the invention.

FIGS. 16A and 16B show an exemplary timeline that illustrates a series of states in a media player according to one embodiment of the invention.

DETAILED DESCRIPTION

In general, the invention relates to a media device and methods for operating a media device. The invention is particularly suitable for use with portable media players.

Embodiments of various aspects of the invention are discussed below with reference toFIGS. 1-16B. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments.

FIG. 1 is a diagram of aportable media device100 according to one embodiment of the invention. Themedia device100 is a portable device including hardware for providing media and data capabilities. Theportable media device100 can couple to a host device such as a computer in order to transfer data between themedia device100 and the host device. In one embodiment, themedia device100 is plug and play device. The term plug and play (PnP) generally refers to functionality that gives users the ability to plug a device into a host device and have the host device recognize the device with little or no user input.

As shown inFIG. 1, themedia device100 includes ahousing102 that encloses internally the components of themedia device100. Themedia device100 also includes anaccessible connector104 that extends out of thehousing102. Theconnector104 is capable of plugging into a corresponding port on the host device in order to allow communications (e.g., data transfer) between themedia device100 and the host device. Theconnector104 may be widely varied. In one embodiment, theconnector104 is a peripheral bus connector, such as a USB or FIREWIRE connector. These type of connectors include both power and data functionality, thereby allowing both power delivery and data communications to occur between themedia device100 and the host device when themedia device100 is connected to the host device. In some cases, the host device powers themedia device100.

Themedia device100 also includes amemory device106 for storing data. The data can be transferred back and forth between themedia device100 and the host device when themedia device100 is attached to the host device. The data may include media files (e.g., audio tracks), data files, and/or the like. Thememory device106 may be widely varied. In one particular embodiment, thememory device106 is non-volatile memory, such as solid-state memory (e.g., Flash memory). Solid-state memory has many advantages over other types of memory devices. One advantage of the solid-state memory is that it tends to be very robust because there are no moving parts to break or skip (e.g., embodiment as an integrated circuit chip). Another advantage of solid-state memory is that the memory device tends to be small and lightweight and therefore lends itself to the portability of themedia device100.

In one embodiment, themedia device100 includes amedia module108 for controlling media operations on the media device. The media can, for example, be audio, video, images and/or the like. Themedia module108 may, for example, be used to present (e.g., play) media on themedia device100. Hence, themedia device100 can be considered a media player. Themedia module108 cooperates with thememory device106 to store and retrieve media data. For example, themedia module108 may access thememory device106 to obtain or deliver media data such as audio tracks (e.g., songs) and/or images (e.g., photos).

In one embodiment, themedia device100 includes an on-board battery110 for providing power to themedia device100. The on-board battery110 can, for example, power themedia device100 so that themedia device100 can be fully portable and operate when disconnected from any host device. The on-board battery110 may be a fixed charged battery that needs to be replaced from time to time or the on-board battery may be a rechargeable battery. By way of example, the on-board battery110 may be an alkaline battery, NiCad battery, Lithium Ion battery, or other type of battery. Rechargeable batteries are typically preferred over fixed charged batteries since they rarely have to be replaced (ease of use). In some cases, the rechargeable battery can be charged through the power functionality of theconnector104 when theconnector104 is operatively coupled to the port of a host device.

In one embodiment, themedia device100 includes one ormore input devices112. Theinput devices112 are configured to transfer data from the outside world into themedia device100. Theinput devices112 can, for example, be used to make selections or issue commands for themedia device100. By way of example, theinput devices112 may be selected from buttons, switches, keypads, wheels, joysticks, joy pads, touch screens, touch pads, track balls, and/or the like.

In one particular implementation, theinput device112 is embodied as a sliding switch that slides between various positions in order to change the state or mode of themedia device100. For example, in the case in which themedia device100 provides playing of audio tracks (e.g., music or songs), the sliding switch may include an off position, a shuffle play mode position, and a continuous play mode position. When the sliding switch is in the off position, the audio functionality of themedia device100 is turned off. When in the continuous play mode position, themedia device100 plays audio tracks in some predetermined order (e.g., alphabetically by composer or song title). When in the shuffle play mode position, themedia device100 randomly selects a group of audio tracks and then plays the audio tracks in the selected order.

In another implementation, theinput device112 is embodied as one or more clickable buttons that may be clicked in order to control some aspect of themedia device100. For example, in the case of themedia device100 that includes audio functionality, the clickable buttons may correspond to commands such as previous, next, volume up, volume down and play/pause.

In one embodiment, themedia device100 includes one ormore output devices114. Theoutput devices114 are configured to transfer data from themedia device100 to the outside world. Theoutput devices114 can, for example, be used to output audio or visual information to the user. Theoutput devices114 may be selected from speakers, audio jacks, indicators and/or the like.

Although conventional media devices mandate use of displays (display screens), such as liquid crystal displays (LCDs), for user interaction, themedia device100 advantageously need not include such a display. In one particular implementation, themedia device100 does not include a display, but includes (i) an audio jack for supplying audio output to a headset or external speakers and (ii) one or more indicators that provide user feedback and/or status of the media device. For example, the indicators may inform the user when aparticular input device112 has been actuated or may inform the user of status of battery life. By eliminating a display, themedia device100 can not only have a small form factor and be highly portable, but also reduce power consumption of the media device and therefore extend the life of thebattery110. As a result, themedia device100 can be used for longer periods of time without recharging or changing the on-board battery110.

The position of the I/

O devices

112 and114 relative to thehousing102 may be widely varied. For example, the I/

O devices

112 and114 may be placed at any external surface of thehousing102 that is accessible to a user during manipulation of the media device100 (e.g., top, side, front, or back).

In one implementation, theinput devices112 are generally positioned at locations that allow for one-handed operation of theinput device112, and more particularly at locations that allow manipulation with a single finger while holding themedia device100 with one hand. In one particular implementation, theinput devices112 are placed at an upper half of thehousing102. Theinput devices112 can therefore be actuated by a thumb of a user's hand when themedia device100 is held by the fingers and palm of the user's hand. Theoutput devices114 are typically placed at locations that allow access thereto when themedia device100 is held in the user's hand. Theoutput devices114 may, for example, be placed above theinput devices112 so that they can be accessed when the user is manipulating theinput devices112. By orienting the I/

O devices

112 and114 in this manner, themedia device100 does not have to be constantly repositioned in order to effectively utilize the I/

O devices

112 and114. For example, undesirable repositioning may be necessary if buttons are placed in a row from the top to bottom of the device.

It should be noted that the various embodiments, implementations or features described above can be used separately or in combination. For example, themedia device100 including theconnector104 and thememory device106 may only be configured with one of the embodiments described above (e.g., only an input device112). Alternatively, themedia device100 including theconnector104 and thememory device106 may be configured with two or more of the embodiments described above (e.g., aninput device112 and an output device114). Alternatively, themedia device100 including theconnector104 and thememory device106 may integrate all the embodiments described above. By way of example, themedia device100 may integrate the functionality of theaccessible connector104, thememory device106, themedia module108, thebattery110 and the various I/

O devices

112 and114 into a single all-in-one unit, i.e., all the elements are contained within or positioned on thehousing102 of themedia device100. As a result, no support devices are needed (such as attachable battery packs or I/O devices) when operating themedia device100 away from a host device, i.e., themedia device100 is capable of both storing data as well as controlling, playing and outputting media when on the go. It should be emphasized that in this implementation, theconnector104 is accessible or exposed since its not plugged into any support devices. As such, the user can easily plug theconnector104 into a host device or other device (e.g., a dock, holder, battery pack, or lanyard). Themedia device100 can also include a cover that removably attaches to and covers theconnector104.

Alternatively or additionally, themedia device100 may include imaging components for capturing and viewing images. In cases such as these, themedia device100 may act like a camera.

FIGS. 2A and 2B are perspective diagrams of aportable media device200 according to one embodiment of the invention. Themedia device200 can represent one implementation of themedia device100 illustrated inFIG. 1. Themedia device200 is in the form of an elongated stick that can be easily held in one hand. Theportable media device200 combines the functionality of a media player with a memory device so that theportable media device200 is capable of both presenting (e.g., playing) media (e.g., music) and storing various data files when on the go. The memory device can be used to store data files and media data (such as songs and playlists), and the media player can be used to play the media data stored in memory and in accordance with a playlist.

Typically, themedia device200 acts like a storage device (data can be transferred to and from the media device200) when connected to a host device, and acts as a media player when removed from the host device (songs can be played). Alternatively or additionally, themedia device200 may act like a media player when connected to a host device (i.e., can be used to drive playing of music on the host device). It should be emphasized that all the components needed to support these devices when removed from the host device are contained within or positioned on themedia device200. No other support devices are needed to operate the components of the media device200 (e.g., contains a battery and I/O devices).

As shown inFIGS. 2A and 2B, theportable media device200 includes ahousing202 that defines the shape or form of thedevice200. That is, the contour of thehousing202 may embody the outward physical appearance of themedia device200. Thehousing202 also encloses and supports internally various electrical components of the media device200 (including integrated circuit chips and other circuitry). By way of example, the electrical components may include a processor, memory, battery, I/O control circuitry and the like. In some cases, the electrical components are positioned on a substrate or carrier such as a Printed Circuit Board (PCB). The substrate or carrier provides a structure for carrying the electrical components during assembly and supporting them when assembled inside thehousing202. By way of example, themedia device200 including the housing and internal components may be assembled similarly to the invention disclosed in U.S. patent application Ser. No. 10/884,172, filed Jul. 2, 2004 and entitled “HANDHELD COMPUTING DEVICE,” which is herein incorporated by reference.

Themedia device200 also includes aperipheral bus connector204 that extends out a bottom end of thehousing202. Theperipheral bus connector204 is configured for insertion into a port so that data may be transferred between themedia device200 and a host device (seeFIG. 3). Theperipheral bus connector204 may be used to upload or download media, or other data to and from themedia device200. For example, theperipheral bus connector204 may be used to download songs, playlists, audio books, ebooks, and the like into a memory device within themedia device200. Theperipheral bus connector204 may also serve as the interface for powering and charging themedia device200. In some cases, a cover or cap may be provided to cover and protect theconnector204 and to provide a smooth continuous surface (uniform appearance) with the rest of thehousing202. Theperipheral bus connector204 may, for example, correspond to a USB connector.

As shown, the cross-section of thehousing202 is typically slightly larger than the cross-section of theconnector204, and the length of thehousing202 is typically configured so that themedia device200 can be easily held in a user's hand while providing enough storage for the internal components (seeFIGS. 4 and 5). By keeping the cross-section to a minimum, themedia device200 tends not to interfere with other connectors when they are connected to the host device along with themedia device200. As should be appreciated, many ports are closely stacked or laid out in a line on the side or back of the host device (seeFIG. 3). Furthermore, smaller sizes typically mean that themedia device200 can be placed in a pocket, around the user's neck or on a key chain, making for easy transportability. By way of example, and not by way of limitation, thehousing202 may have a thickness of about 9 mm, a width of about 25 mm, and a length of about 85 mm.

Themedia device200 also includes anaudio jack206 that allows audio information to be output from themedia device200. Theaudio jack206 can, for example, receive an audio plug connected to a speaker or a headset (e.g., earphones).

Themedia device200 also includes aclickable button actuator208 located on one side of thehousing202 and a slidingmodal switch214 located on an opposite side of thehousing202. Each of these

input devices

208 and214 allows a user to interact with themedia device200, i.e., provide user inputs. Theclickable button actuator208 provides playback controls for the media player aspect of themedia device200, while the slidingmodal switch214 provides a means for switching between various modes of the media player. More generally, theclickable button actuator208 is a control input device.

To elaborate, theclickable button actuator208 is located in a top region on the front side of thehousing202. Theclickable button actuator208 includes a plurality of peripheral buttons210 that surround acenter button212. In one particular embodiment, theclickable button actuator208 has a circular arrangement. In the case of a media player, the peripheral buttons210 may correspond to previous, next, volume up and volume down, and thecenter button212 may correspond to play/pause. Moreover, press and hold of thecenter button212 can correspond to shuffle. The peripheral buttons210 may be separate devices that each provide their own clicking action or they may be integrated into a single device that provides a plurality of clicking actions. If the latter, the single device can be divided into a plurality of independent and spatially distinct button zones. The button zones represent regions of the single device that may be tilted or depressed relative to thehousing202 in order to implement a distinct clicking action.

Although not shown, in one embodiment, the clicking actions are arranged to actuate one or more movement indicators contained inside thehousing202. That is, a particular button orbutton zone210,212 moving from a first position (e.g., upright) to a second position (e.g., depressed) is caused to actuate a movement indicator. The movement indicators are configured to detect movements (e.g., a clicking action) and to send signals corresponding to the movements to a controller of themedia device200. By way of example, the movement indicators may be switches, sensors and/or the like. In most cases, there is a movement indicator for each button orbutton zone210,212.

As shown inFIG. 2A, the slidingmodal switch214 is located in a top region on the backside of thehousing202. The slidingmodal switch214 includes a movingmember216 capable of translating between three positions in order to adjust the state or mode of themedia device200. In the illustrated embodiment, the movingmember216 moves between atop position218A, which turns off the media player, amiddle position218B, which sets the media player in a shuffle mode, and abottom position218C, which sets the media player in a continuous play mode. As illustrated inFIG. 2A, the movingmember216 can, for example, be flush with thehousing202. In most cases, the movingmember216 is slideably retained within arecess219 on the back surface of thehousing202. In one example, the movingmember216 may include tabs on each of its sides that are trapped inside a channel at the sides of therecess219. In another example, the movingmember216 may include a channel that receives tabs at the sides of therecess219. In yet another example, the movingmember216 may include a flange on its bottom surface that slides in a channel located in the bottom surface of therecess219. In all of these cases, the movingmember216 is configured to actuate one or more movement indicators. The movement indicators are configured to detect movements of the movingmember216 during the sliding action and to send signals corresponding to the movements to a controller of themedia device200. In some cases, detents may be provided at each position in order to inform a user when the movingmember216 is located at each of the positions. The detents, or other means, may provide force feedback and/or auditory signals, such as clicking sounds, to its user.

In one embodiment, the

input device

208 and214 for themedia device200 are provided only on a front or back surface of thehousing202 for themedia device200. In such an embodiment, there are no input devices on the sides of themedia device200. Advantageously, accidental inputs can reduced and the sides of themedia device200 can be used to grip and hold themedia device200.

Themedia device200 does not include a display, but does however include one or more indicators that indicate events associated with themedia device200. By way of example, the events may relate to signals, conditions or status of themedia device200. In one embodiment, the indicators, which can include light sources such as light emitting diodes (LED), are typically normally not illuminated but are illuminated for a limited duration when an event occurs. Furthermore, the indicator may turn on and off (e.g., blink) or cycle with increasing or decreasing intensity, and in some cases may even change colors in order to provide more detailed information about the event that is being monitored. In general, the indicators can also be referred to as status indicators or media device status indicators.

The indicators may be conventional indicators that typically include a small clear plastic insert, which is located in front of the LED, and which is inserted within an opening in the housing thus causing it to exist at the surface of the housing. The LED itself may also be placed in the opening in the housing rather than using an insert. Alternatively, the indicator can be configured not to break the surface of the housing. In this configuration, the light source is disposed entirely inside the housing. The indicator can be configured to illuminate a portion of the housing thereby causing the housing to change its appearance, i.e., change its color. By way of example, a change in color may indicate a change in status of themedia device200. During operation, an indicator light appears on the surface of thehousing202 when the indicator is on, and it disappears from the surface of thehousing202 when the indicator is off. One advantage of this type of indicator is that there is no trace of the indicator when the indicator is off. In other words, the indicator can be perceived only when the indication (e.g., indicator light) is turned on. Furthermore, the indicator avoids substantial breaks, lines, pits or protrusions in the surface of thehousing202, which are aesthetically unpleasing and degrade the look of themedia device200. Example of indicators of this type are disclosed in greater detail in U.S. patent application Ser. No. 10/773,897, filed Feb. 6, 2004 and entitled “ACTIVE ENCLOSURE FOR COMPUTING DEVICE,” which is herein incorporated by reference.

In the illustrated embodiment, themedia device200 includes a condition orcontrol indicator220 and astatus indicator222. Thecontrol indicator220 is located on the front side of thehousing202 above theclickable button actuator208. Thecontrol indicator220 is configured to alert or inform a user when a selection has been made via theinput device208. That is, thecontrol indicator220 provides user feedback so that the user knows that a selection has been successfully made. Because thecontrol indicator220 is positioned above theinput device208, the control indicator can always be seen by the user even when selections are being made via the input device208 (seeFIG. 4). In this particular embodiment, thecontrol indicator220 is a hidden indicator that illuminates a small portion of thehousing202 about thecontrol indicator220 rather than protruding through the surface of thehousing202.

Thestatus indicator222, on the other hand, is located on the back side of thehousing202 below themodal input device214. Thestatus indicator222 is configured to alert the user to a particular status, particularly the life of the battery of themedia device200. Thestatus indicator222 can, for example, be illuminated green when the battery is fully charged, yellow when the battery is low, and red when the battery is dangerously low. Thestatus indicator222 can also flash on and off (blink) when the battery is critically low. Thestatus indicator222 may be an always-on indicator that always presents status information, or it may be an on-call indicator that only presents status information when prompted by the user. In the latter case (which is shown inFIG. 2A), abutton224 may be provided to activate thestatus indicator222. When the user presses thebutton224, thestatus indicator222 presents the status information for some predetermined amount of time (e.g., a few seconds).

Referring toFIGS. 4 and 5, themedia device200 is comfortably seated within a user's hand270 (and removed from any host device). As shown inFIG. 4, thecontrol input device208 can be easily manipulated by thethumb272 of thehand270 while thefingers274 andpalm276 of thehand270 holds themedia device200. By way of example, the user may move theirthumb272 over any of the various buttons of thecontrol input device208 without repositioning theirhand270, and more particularly theirfingers274. As shown inFIG. 5, themodal switch214 as well as thestatus button224 can be easily manipulated by thethumb272 of thehand270 while the rest of the hand holds themedia device200. By way of example, the user may use theirthumb272 to move the slidingmodal switch214 to any of its various positions as well as to select thestatus button224.

Referring toFIG. 6, thecontrol input device208 according to one embodiment will be described in greater detail. As shown, thecontrol input device208 includes amovable platform230 that tilts relative to thehousing202. In some cases, theplatform230 is movably coupled to thehousing202 and in other cases thehousing202 movably restrains a floating platform230 (as shown). Theplatform230 generally includes a cosmetic ortactile layer232 that is attached to the top surface of arigid plate234. Thecosmetic layer232 protrudes though an opening236 in thehousing202, and provides a tactile surface for actuating the various peripheral buttons of thecontrol input device208. In the illustrated embodiment, thecosmetic layer232 includes a rounded top surface.

Thecontrol input device208 further includes one or moremechanical switches238 disposed between theplatform230 and thehousing202 in order to generate input signals based on movements of theplatform230. Themechanical switches238 are typically placed in locations that correspond to the various button zones. Each of the button zones includes a distinctmechanical switch238 located underneath the button zone. Themechanical switches238 includeactuators240 that cause input signals to be generated when depressed. Tilting theplatform230 in the region of themechanical switch238 compresses theactuator240, thereby causing an input signal to be generated. In most cases, theactuators240 are spring biased so that they extend away from themechanical switch238 and bias theplatform230 in the upright position. Themechanical switches238 may be attached to thehousing202 or to theplatform230. In the illustrated embodiment, themechanical switches238 are attached to the backside of theplatform230. As such, themechanical switches238 and more particularly theactuators240 act as legs for supporting theplatform230 in its upright position within the housing202 (i.e., the actuators rest on the housing or some component mounted to the housing). By way of example, themechanical switches238 may correspond to tact switches, such as dome switches packaged for SMT.

As mentioned above, theplatform230 is movably restrained within a cavity242 provided in thehousing202. In essence, theplatform230 floats in space relative to thehousing202 while still being constrained thereto (the platform is not attached to the housing). As shown, theplatform230 is surrounded by side walls, a top wall and bottom wall of thehousing202. The side walls are configured to substantially prevent movements in the x and y directions as well as rotations about the z axis (e.g., excluding a small gap that allows a slight amount of play in order to prevent theplatform230 from binding with the housing during the tilting action). The top and bottom walls, however, are configured to allow movement (although limited) in the z direction as well as rotation about the x and y axis in order to provide the tilting action. That is, while the top and bottom walls and may constrain theplatform230 to the cavity242, they also provide enough room for theplatform230 to tilt in order to depress theactuator240 of the mechanical switches238. Furthermore, the spring force provided by themechanical switches238 places the top surface of theplatform230 into mating engagement with the bottom surface of the top wall of the housing202 (e.g., upright position).

During operation, a user simply presses on the top surface of theplatform230 in the location of the desired button zone in order to activate themechanical switches238 disposed underneath theplatform230 in the location of the button zones. When activated, themechanical switches238 generate input signals that may be used by themedia device200. To activate themechanical switch238, a force provided by a finger works against the spring force of theactuator240 until themechanical switch238 is activated. Although theplatform230 essentially floats within the cavity of thehousing202, when the user presses on the desired button zone over one side of theplatform230, the opposite side contacts the top wall (opposite the press) thus causing theplatform230 to pivot about the contact point. In essence, the platform pivots about four different axes.

Furthermore, abutton cap244 is disposed between thecosmetic layer232 and the top side of therigid plate234. A top portion of thebutton cap244 is configured to protrude through an opening in thecosmetic layer232 while a flange portion is retained in a space formed between thecosmetic layer232 and therigid plate234. The top portion of thebutton cap244 may be pushed to activate afifth switch246 located underneath thebutton cap244. Thefifth switch246 may be attached to thehousing202 and pass through openings in therigid plate234 andcosmetic layer232. When assembled, theactuator248 of thefifth switch246 forces thebutton cap244 into an upright position via a spring element similar to the other switches238.

It should be noted that the particular implementation described inFIG. 6 is not a limitation and that thecontrol input device208 can be configured in a variety of different ways. U.S. patent application Ser. No. 10/643,256, filed Aug. 18, 2003 and entitled “MOVABLE TOUCHPAD WITH ADDED FUNCTIONALITY,” describes several embodiments of control input devices that may be used, including control input devices with touch sensitive components, and is hereby incorporated herein by reference.

FIG. 7 is a block diagram of amedia device700 according to one embodiment of the invention. Themedia device700 includes aprocessor702 that pertains to a microprocessor or controller for controlling the overall operation of themedia device700. Themedia device700 stores media data pertaining to media items in afile system704 and acache706. Thefile system704 is, typically, a solid-state storage medium. As an example, the solid-state storage medium can be FLASH memory. Thefile system704 typically provides high capacity storage capability for themedia device700. Thefile system704 can store not only media data but also non-media data. When themedia device700 operates in a media play mode, thefile system704 can store and retrieve media files. In the media play mode, themedia device700 can be considered a media player. Alternatively, when themedia device700 operates in a data mode, thefile system704 can store and retrieve data files. In the data mode, themedia device700 can be referred to as a FLASH drive or USB drive. However, since the access time to thefile system704 is relatively slow, themedia device700 can also include acache706. Thecache706 is, for example, Random-Access Memory (RAM) provided by semiconductor memory. The relative access time to thecache706 is substantially shorter than for thefile system704. However, thecache706 does not have the large storage capacity of thefile system704. Further, thefile system704, when active, consumes more power than does thecache706. The power consumption is often a concern when themedia device700 is a portable media player that is powered by a battery (not shown). Themedia device700 also includes aRAM720 and a Read-Only Memory (ROM)722. TheROM722 can store programs, utilities or processes to be executed in a non-volatile manner. TheRAM720 provides volatile data storage, such as for thecache706.

Themedia device700 also includes one or moreuser input devices708 that allow a user of themedia device700 to interact with themedia device700. For example, theuser input devices708 can take a variety of forms, such as buttons, keypads, dials, switches, etc. Adata bus711 can facilitate data transfer between at least thefile system704, thecache706, theprocessor702, and theCODEC712.

In one embodiment, themedia device700 serves to store a plurality of media assets (e.g., songs, photos, etc.) in thefile system704. When a user desires to have themedia device700 play a particular media asset, the user operates theuser input device708 to select a media player mode. Then, using theuser input device708, the user can play the next available media asset. Theprocessor702, upon receiving a selection of a particular media item, supplies the media data (e.g., audio file) for the particular media item to a coder/decoder (CODEC)712. TheCODEC712 then produces analog output signals for aspeaker714. Thespeaker714 can be a speaker internal to themedia device700 or external to themedia device700. For example, headphones or earphones that connect to themedia device700 would be considered an external speaker.

Additionally, the media player may be set to a specific media play mode, according to some embodiments of the invention. The mode selection is typically made using theuser input device708, such as a switch or button. Two typical media play modes are a continuous play mode and a shuffle play mode. Generally, in the shuffle play mode, the media player plays through a list of media assets in a random order, while in the continuous play mode, the media player plays through the list of media assets according to a default order. The default order for the list of media assets can, for example, be (i) alphabetically ordered by song name, (ii) ordered by track position on an album, or (iii) ordered by date loaded onto the media player. In one embodiment of the invention, the media play mode is selected using a three-position switch, which allows a user of the media player to select between off, continuous play mode, and shuffle play mode.

Themedia device700 also includes a network/bus interface716 that couples to adata link718. The data link718 allows themedia device700 to couple to a host computer. The data link718 can be provided over a wired connection or a wireless connection. In the case of a wireless connection, the network/bus interface716 can include a wireless transceiver. In one embodiment, themedia device700 can include a peripheral bus connector coupled to the network/bus interface. Examples of a peripheral bus connector are a USB connector or a FireWire® connector.

It should be noted thatFIG. 7 does not indicate that themedia device700 includes a display (display screen). Although a conventional media player requires a display to enable a user to interface with the media player, themedia device700 shown inFIG. 7 does not include a display. By not providing a display, the media player is able to be smaller and lighter than conventional media players. Abattery720 that powers the various components of the media device700 (at least when not attached to a host computer (or peripheral bus)) is also able to be smaller since power consumption is reduced. Thebattery720 can be rechargeable and charged by acharge circuit722 using power available from the peripheral bus.

In one embodiment, to facilitate user interaction with the media device700 (which lacks a display), theuser input device708 can include at least a shuffle switch. The shuffle switch enables a user to shuffle the media assets (e.g., songs) being played by themedia device700. Theuser input device708 can also include a control input device that allows a user to signal a request to play, pause, next forward, next back, disable control inputs temporarily, and reshuffle the media assets.

FIG. 8 is a block diagram of amedia management system800 according to one embodiment of the invention. Themedia management system800 includes ahost computer802 and amedia player804. The media player can be, for example, themedia player700 ofFIG. 7. Thehost computer802 is typically a personal computer. The host computer, among other conventional components, includes amanagement module806, which is a software module. Themanagement module806 provides for centralized management of media assets (and/or playlists) not only on thehost computer802 but also on themedia player804. More particularly, themanagement module806 manages those media assets stored inmedia storage808 associated with thehost computer802. Themanagement module806 also interacts with amedia database810 to store media information associated with the media assets stored inmedia storage808. Some embodiments also include afile manager815, which provides for management of other data files (i.e., non-media asset files) on both thehost computer802 and themedia player804.

The media information pertains to characteristics or attributes of the media assets. For example, in the case of audio or audiovisual media, the media information can include one or more of: title, album, track, artist, composer and genre. These types of media information are specific to particular media assets. In addition, the media information can pertain to quality characteristics of the media assets. Examples of quality characteristics of media assets can include one or more of: bit rate, sample rate, equalizer setting, volume adjustment, start/stop and total time.

Further, in some embodiments, themanagement module806 also interacts with thehost computer802 to transfer data files (i.e., non-media asset files stored on thehost computer802, typically on the host computer's hard drive) to and frommedia storage808. Alternately, in some embodiments, data files may be transferred to and fromoptional data storage809, which may be physically and/or logically combined with or separate frommedia storage808. It is understood that a data file includes any data that is capable of being stored in a file system, which includes all file types. Typical data files include text documents, executable files, and graphics files. Alternately, in some embodiments, themanagement module806 does not directly access data files. Rather, the user transfers files back and forth to/from or deletes files from themedia player804 using thefile manager815, on the host computer, where the media player appears, for example, as a disk drive or removable storage medium.

Thedata storage809 and/or themedia storage808 can utilize one or more directories (e.g., folders) in the host computer's file system (e.g., on a hard drive, not shown). As is conventional, data stored on thedata storage809 can be assessed by afile manager815. In addition, in one embodiment, media assets stored in themedia storage808 can also be accessed by thefile manager815. Thefile manager815 can be, for example, a file explorer, such as a “Finder” application which is part of Apple Computer's operating system.

Still further, thehost computer802 includes a play module812. The play module812 is a software module that can be utilized to play certain media assets stored inmedia storage808. In some embodiments, the play module812 can also be used to play media assets stored outside ofmedia storage808, such as media assets stored indata storage820 on themedia player804.

Thehost computer802 also includes acommunication module814 that couples to acorresponding communication module816 within themedia player804. A connection or link818 removeably couples the

communication modules

814 and816. In one embodiment, the connection or link818 is a cable that provides a data bus, such as a FIREWIRE® bus or USB bus, which is well known in the art. In another embodiment, the connection or link818 is a wireless channel or connection through a wireless network. In still another embodiment, the connection or link818 is a USB connection established by direct coupling of a USB connector on themedia player804 to a USB slot on thehost computer802. In this embodiment, themedia player804 is directly inserted into a USB slot on thehost computer802 without using a cable. Hence, depending on implementation, the

communication modules

814 and816 may communicate in a wired or wireless manner.

Themedia player804 also includesmedia storage820 that stores media assets within themedia player804. Optionally,media storage820 can also store data files indata storage821. The media assets or data files being stored tomedia asset storage820 ordata storage821 are typically received over the connection or link818 from thehost computer802. More particularly, themanagement module806 sends all or certain of those media assets or data files residing inmedia storage808 orfile storage809 over the connection or link818 tomedia storage820 orfile storage821 within themedia player804. Additionally, the corresponding media information for the media assets that is also delivered to themedia player804 from thehost computer802 can be stored in amedia database822. In this regard, certain media information from themedia database810 within thehost computer802 can be sent to themedia database822 within themedia player804 over the connection or link818. Still further, playlists identifying certain of the media assets can also be sent by themanagement module806 over the connection or link818 tomedia storage820 or themedia database822 within themedia player804.

Furthermore, themedia player804 includes aplay module824 that couples tomedia storage820 and themedia database822. Theplay module824 is a software module that can be utilized to play certain media assets stored inmedia storage820.

Hence, in one embodiment, themedia player804 has limited or no capability to manage media assets or data files on themedia player804. However, themanagement module806 within thehost computer802 can indirectly manage the media assets residing on themedia player804. For example, to “add” a media asset to themedia player804, themanagement module806 serves to identify the media asset to be added to themedia player804 frommedia storage808 and then causes the identified media asset or data to be delivered to themedia player804. As another example, to “delete” a media asset from themedia player804, themanagement module806 serves to identify the media asset to be deleted frommedia storage808 and then causes the identified media asset to be deleted from themedia player804. As still another example, if changes (i.e., alterations) to characteristics of a media asset were made at thehost computer802 using themanagement module806, then such characteristics can also be carried over to the corresponding media asset on themedia player804. In one implementation, the additions, deletions and/or changes occur in a batch-like process during synchronization of the media assets on themedia player804 with the media assets on thehost computer802.

Alternately, in some embodiments, data storage on themedia player804 is designatedfile storage821 and is combined with or physically and/or logically separate frommedia storage820. As discussed above, in some embodiments, themanagement module806 is normally not involved in transferring data betweenfile storage809 on thehost computer802 andfile storage821 on themedia player804. In these embodiments, thefile manager815 running on thehost computer802 can be used to manage the transfer of data betweenfile storage809 andfile storage821. For example, when using thefile manager815, themedia player804 appears as a USB drive and data files are accessed as if themedia player804 was a conventional USB drive.

In another embodiment, themedia player804 has limited or no capability to manage playlists on themedia player804. However, themanagement module806 within thehost computer802 through management of the playlists residing on the host computer can indirectly manage the playlists residing on themedia player804. In this regard, additions, deletions or changes to playlists can be performed on thehost computer802 and then be carried over to themedia player804 when delivered thereto.

As previously noted, synchronization is a form of media management. The ability to automatically initiate synchronization was also previously discussed above and in the related application noted above. Still further, however, the synchronization between devices can be restricted so as to prevent automatic synchronization when the host computer and media player do not recognize one another.

In one implementation, the host computer can utilize an application resident on the host computer to permit utilization and provide management for playlists. One such application is iTunes®, produced by Apple Computer, Inc. of Cupertino, Calif.

Another embodiment of the invention relates to a portable media device, such as a portable media player, having one or more status indicators. The status indicators can provide useful user feedback, which is particularly useful when the portable device lacks a display screen (display), such as a LCD display. The status indicators can be audio or visual.

FIGS. 9A and 9B are block diagrams of atop surface901 of amedia device900 according to one embodiment of the invention. Themedia device900 is, for example themedia device100 ofFIG. 1 or themedia device200 shown inFIGS. 2A and 2B. Themedia device900 has a mediadevice status indicator903 to indicate an associated media device status. According to the embodiment shown, the mediadevice status indicator903 is a visual media device status indicator. For example, the visual status indicator can be implemented by one or more LEDs. If more than one LED is used, the one or more LEDs can have different colors to indicate different media device states. The one or more LEDs can be placed such that they are located in close proximity to each other so it appears to a user that asingle status indicator903 changes color as the media device status changes. Themedia device900 shown also has auser control panel905, which can be one or more switches, buttons, joysticks, touchpads, etc. In one embodiment, theuser control panel905 is thecontrol input device208 illustrated inFIG. 2A. In some embodiments, thestatus indicator903 may be integral with one or more user controls (not shown) located on theuser control panel905.

Additionally, one embodiment of the invention includes an integral peripheral bus connector907 and a rechargeable battery (not shown). The rechargeable battery can be charged when theportable media device900 is connected to a peripheral bus via the peripheral bus connector907. As noted above, a USB connector or a FireWire® connector are examples of a peripheral bus connector. In some embodiments, aremovable cap909 can be used to protect and/or conceal the peripheral bus connector907.

In one embodiment of the invention, two LEDs of different colors are used as the mediadevice status indicator903. In this embodiment, a first color LED is used to give a user visual feedback corresponding to the user operating one or more user controls. A second color is used to give the user visual feedback that themedia device900 is being charged. The first color LED can blink once each time a user operates a first user control (e.g., a volume control) on theuser control panel905. If a second user control (e.g., a play/pause control) on theuser control panel905 is operated, then the first color LED blinks steadily while the selected action continues. According to this embodiment, the second color LED, which emits a different color than the first color LED, blinks steadily while themedia device900 is charging, for example, when themedia device900 is plugged into a peripheral bus capable of supplying power to themedia device900.

FIG. 9C is a block diagram of asecond surface925 ofmedia device900 shown inFIGS. 9A and 9B according to one embodiment of the invention. Themedia device900 has amedia status indicator929 to indicate an associated media device status. According to the embodiment shown, the mediadevice status indicator929 is a visual media device status indicator. For example, the visual status indicator can be implemented by one or more LEDs. If more than one LED is used, the one or more LEDs can have different colors to indicate different media device states. In one embodiment, the one or more LEDs are placed such that they are located in close proximity to each other so it appears to a user that asingle status indicator929 changes color as the media device status changes. Themedia device900 shown also has auser control panel927, which can be one or more switches, buttons, joysticks, touchpads, etc. In one embodiment, theuser control panel927 is thecontrol input device208 illustrated inFIG. 2A. In one embodiment, thestatus indicator929 may be integral with one or more user controls located on theuser control panel927. For example, thestatus indicator222 discussed above with reference toFIG. 2A can be considered integral with thebutton224.

In one embodiment of the invention, three LEDs of different colors are used to implement the mediadevice status indicator929. In this embodiment, each of the three colors of LED is used to give a user visual feedback corresponding to a different battery condition. In order to conserve battery life, in some embodiments, the mediadevice status indicator929 is activated by a user control (not shown), such that themedia device indicator929 operates for a short period of time (e.g., 5 seconds) after the user operates the user control.

For example, in one embodiment, the first color LED lights up to indicate that a battery that powers themedia device900 is mostly charged. Over time, as themedia device900 is operated, the battery discharges to a first predetermined voltage indicative of a partially charged battery. Accordingly, the first color LED switches off and second color LED lights up to indicate to the user that the battery has partially discharged. As the battery continues to discharge to a second predetermined voltage, the second color LEDs switches off and a third color LED lights up to indicate to the user that the battery is mostly discharged. Finally, when the battery is almost completely discharged, a single LED (of any color) blinks steadily to indicate to the user that themedia device900 is preparing to shut down because the battery level is insufficient to continue operating themedia device900. Thereafter, the media device status indicator ceases to give any indication (i.e., none of the LEDs light up) indicating to the user that the battery is substantially completely discharged and must be recharged before themedia device900 can be used again.

FIGS. 10A and 10B are diagrams illustrating user controls for aportable media device1000 according to one embodiment of the invention.

FIG. 10A illustrates afirst control surface1002 of themedia device1000, which contains a three-position switch1004. The three-position switch1004 can be switched between anoff position1006, a shuffleplay mode position1008, and a continuousplay mode position1010. The shuffleplay mode position1008 can correspond to a media device shuffle play mode as discussed above in reference toFIG. 7 and again below in reference toFIGS. 13-16. Generally, in the shuffle play mode, the media device plays through a group of media assets in a random order. The continuousplay mode position1010 can correspond to a media device continuous play mode, wherein the media device plays through the list of media assets according to a default order. Theoff position1006 allows a user to power off theportable media device1000. The three-position switch1004 is shown in the shuffleplay mode position1008. In one embodiment of the invention, the three-position switch1004 is located on theuser control panel927 ofFIGS. 9A and 9B. In another embodiment of the invention, the three-position switch1004 can be implemented as the slidingmodal switch214 ofFIG. 2B.

FIG. 10B illustrates asecond control surface1020 of themedia device1000, which contains a set of media device controls1050. These media device controls1050 include a volume upcontrol1022, a volume downcontrol1024, a pause/play control1026, a next/fast forward control1028, and a previous/rewind control1030. In one embodiment of the invention, the media device controls1050 are located on theuser control panel905 ofFIGS. 9A and 9B. In some embodiments of the invention, the set of media device controls1050 can be implemented as theclickable button actuator208 illustrated inFIG. 2A. Further, in some embodiments, one or more of the media device controls are overloaded such that it has more than one function. For example, the pause/play control1026 can function as a hold button, disabling the media device controls to prevent accidental control inputs (e.g., when the media device is in a pocket). In this embodiment, the pause/play control is pressed and held down for a predetermined period of time (e.g., 3 seconds) to initiate the media device control hold. To cancel the hold, the pause/play control1026 is pressed and held in the same manner as used to initiate the media device control hold.

Another aspect of the invention relates to a portable media player with the capability of storing media player status information in persistent memory before powering down. Thereafter, when the portable media player is again powered up, the stored media player status information can be retrieved and utilized. In effect, the portable media player can remember where it was playing media assets when turned off, so that when later turned on it can play the media assets from where it left off.

FIG. 11 is a flow diagram of a media player power-downprocess1100 according to one embodiment of the invention. The media player power-downprocess1100 is, for example, performed by a media player. For example, the media player can be the

media device

100,200,700 or900 illustrated inFIGS. 1,2A,2B,7 and9A-9C. More generally, the media player can be practiced with any media player with persistent memory storage capabilities. In one embodiment, the persistent memory is non-volatile memory, such as FLASH memory. For example, thefile system704 inFIG. 7 can provide persistent storage.

The media player power-downprocess1100 begins with adecision1101 that determines if a power off request has been received. The power off request can originate from a user action or a system command. An example of a user action is operating an off switch. Alternatively, if the power off request comes from a system command, the command may be the result of a user-set preference, such as after a predetermined period of inactivity or a low battery condition.

Once a power off request has been received, the media player power offprocess1100 determines1102 media player status information from the media player. For example, the media player status information can be determined by a processor operating the media player, such as theprocessor702 shown inFIG. 7. For example, the media player status information can be considered state information of the media player. The state information characterizes the state of the media player so that the media player can later resume playing from the same (or substantially the same) state. The media player status information includes, but is not limited to, one or more of: the current media asset being presented (e.g., played) (i.e., media asset pointer), the current position in the media asset (e.g., elapsed time in current media asset) (i.e., media asset position), media player volume, media player pause status, and current media asset playlist. In some embodiments, a media asset playlist validity indicator (described below) is also stored. The media player status information can be represented by status indicators. Table 1 contains an exemplary list of media player status information status indicators, as well as exemplary variable names and sample values.

TABLE 1

Status Indicator	Variable Name	Sample Values

Current Playlist	Playlist_pointer (pp)	{continuous, shuffle}
Current Media Asset	Media_asset_pointer	Pointer to memory
	(map)	location
Current Media Asset	Media_asset_position	Time
Position	(pos)
Current Media Player	Volume_level (vol)	Volume Level
Volume
Current Media Player	Pause_status (ps)	{pause, play}
Pause Status
Current Playlist Validity	Valid_list_flag (v?)	{valid, invalid}

Next, media player status information is stored 1103 in persistent memory of the media player. For example, the media player status information can be stored in memory of the media player, such as FLASH memory or other non-volatile memory. Subsequently, the media player is powered off1105. The media player power-downprocess1100 is then complete and ends.

FIG. 12 is flow diagram of a media player power-onprocess1200 according to one embodiment of the invention. The media player power-onprocess1200 restores the media player to a state that is substantially the same as when the media player status information was stored. In one embodiment, the media player is restored to the media player state that existed at the time the media player was powered off, such as according to the media player power-downprocess1100 ofFIG. 11. The media player power-onprocess1200 is, for example, performed by a media player. For example, the media player can be the

media device

100,200,700 or900 illustrated inFIGS. 1,2A,2B,7 and9A-9C.

The media player power-onprocess1200 begins with adecision1201, which determines if a power on request has been made. The power on request can originate from a user action or a system command. An example of a user action is operation of an on switch to issue a power on request. If the power on request comes from a system command, the command can, for example, be the result of connection of the media player to a host computer.

After the media player status information has been retrieved1203, the media player is configured1205 according to the retrieved media player status information. In one embodiment, the media player is configured1205 such that it is the same or substantially the same state as it was when the media player status information was stored in persistent memory. Finally, the media player presents1207 one or more media assets according to the media player status information. Thereafter, the media player power-onprocess1200 ends.

Still another aspect of the invention relates to a method for traversing a media asset playlist. The method includes the presentation of one or more media assets in one or more media asset playlists, including at least a media asset continuous playlist and a media asset shuffle playlist. Further, the method describes the circumstances under which a new media asset shuffle playlist is created. These methods are well suited for performance on portable media devices where resources or power is often limited.

FIG. 13 is a flow diagram of a media asset shuffleplaylist traversal process1300 according to one embodiment of the invention. This embodiment is used to traverse a media asset shuffle playlist using a media player, for example, the

media device

100,200,700 or900 illustrated inFIGS. 1,2A,2B,7 and9A-9C. The media asset shuffle playlist (“shuffle playlist”) is one type of media asset playlist. For example, the media asset shuffle playlist represents a shuffled version of a media asset playlist. In some embodiments of the invention the media asset shuffle playlist is a randomly generated playlist that has been generated locally on the media player. Other embodiments may randomly generate a playlist on a host computer such as thehost computer802 ofFIG. 8.

The media asset shuffleplaylist traversal process1300 begins with adecision1301 that determines if a presentation request has been received. The presentation request can be a user request or a system request. As noted above, a presentation operation is used by a media player to present (e.g., play) a media asset. Besides presenting a media asset, other common operations supported by a media player include fast forwarding or rewinding through a media asset, and skipping forward to a next media asset or backward to a previous media asset. If a presentation request has not been received, the media asset shuffleplaylist traversal process1300 waits until a presentation request is received. On the other hand, if a presentation request has been received, adecision1303 determines if a shuffle playlist exists. If thedecision1303 determines that there is no existing shuffle playlist, a shuffle playlist is created1311. Following thecreation1311 of the shuffle playlist, a media asset from the shuffle playlist is retrieved1313. The retrieved media asset is typically the first media asset of the shuffle playlist, if the shuffle playlist has been newly created. Next, the retrieved media asset is presented1315 (e.g., played) on the media asset player. After the retrieved media asset from the shuffle playlist is presented1315, the media asset shuffleplaylist traversal process1300 returns to thedecision1303 and subsequent blocks. Note that, according to some embodiments of this invention, “presenting” a media asset means using the media device to output audio. However, presenting can also include at least operations commonly associated with a typical media player, including fast forwarding or rewinding through a media asset, and skipping forward to a next asset or backward to a previous media asset.

Alternatively, when thedecision1303 determines that a shuffle playlist does exist, the shuffle playlist is obtained1307. For example, the shuffle playlist can be obtained1307 can by retrieving a pointer to the shuffle playlist or a current media asset in the shuffle playlist. Next,decision1309 determines if the obtained shuffle playlist is valid. In one embodiment, the validity of a shuffle playlist can be indicated by a flag or other indicator stored in the media player. Ifdecision1309 determines that the shuffle playlist is not valid, the media asset shuffleplaylist traversal process1300 creates1311 a shuffle playlist and then continues to block1313 and subsequent blocks as discussed above. On the other hand, ifdecision1309 determines that the shuffle playlist is valid, the media assetshuffle traversal process1300 continues directly to block1313 and subsequent blocks.

Although the media asset shuffleplaylist traversal process1300 applies to a shuffle playlist, it should be understood that the media asset shuffleplaylist traversal process1300 can also be applied to other types of playlist. Additionally, in some embodiments of the invention, the status of the media asset shuffle playlist is stored upon a power-down process such as, for example, the media player power-downprocess1100 ofFIG. 11. Further, in some embodiments of the invention, the status of the media asset shuffle playlist is retrieved during a power on process, such as the media player power-onprocess1200 ofFIG. 12.

FIGS. 14A and 14B are flow diagrams of a media assetlist traversal process1400 according to one embodiment of the invention. The media assetlist traversal process1400 is, for example, performed by a media player, for example, the

media device

100,200,700 or900 illustrated inFIGS. 1,2A,2B,7 and9A-9C.

Following theretrieval1407 of the first or next media asset on the media asset shuffle playlist, the retrieved media asset is presented1409 (e.g., played). Next, adecision1411 determines if the media player has been switched to a continuous mode, where the continuous mode is associated with a media asset continuous playlist. For example, the media player can be switched to a continuous mode by using an input device, such as a switch. Typically, according to some embodiments, to activate the continuous mode, a user manually switches a switch of the media player to continuous mode setting, possibly because the user no longer wishes to listen to the currently selected shuffle playlist. A media asset continuous playlist according to one embodiment of the invention is described below in reference toFIGS. 15A and 15B.

Ifdecision1411 determines that the media player has been switched to a continuous mode, then the media asset shufflelist creation process1400 continues to other processing associated with traversal of a media asset continuous playlist. Otherwise,decision1413 determines if a user of the media player makes a request that the media player create1403 a new media asset shuffle playlist. The user request is, according to some embodiments of the invention, initiated by operating a media player control. A dedicated media player control can be used or an existing media player control can be overloaded so as to function to make the new media asset shuffle playlist request. In some embodiments of the invention, a media player control, for example the pause/play control1026 ofFIG. 10, is overloaded such that, if it is pressed several times in rapid succession, a request to create1403 a new media asset shuffle playlist is made. In some embodiments, the creation of a new shuffle playlist is initiated by pressing the media player control 3 times in rapid succession, for example 3 times in 2 seconds.

If thedecision1413 determines that the user has made a request to create a new media asset shuffle playlist, the media asset playlist validity indicator is set1417 to ‘invalid’. On the other hand, if the user does not request the creation of a new media asset shuffle playlist, thendecision1413 directs the media asset shuffleplaylist creation process1400 todecision1415 and subsequent blocks. Thedecision1415 determines if the end of the shuffle playlist has been reached, whereupon the media asset playlist validity indicator is set1417 to ‘invalid’. Alternately, if the end of the shuffle playlist has not been reached, the media assetlist traversal process1400 returns to block1407 and subsequent blocks. Next, regardless of how theblock1417 is reached, following theblock1417 the media asset shufflelist creation process1400 returns to block1401 and subsequent blocks.

More particularly, whendecision1411 determines that the media player has been switched to continuous mode,decision1455 determines if a media player has reached a transition between media assets (e.g., the end of a song). If so, the media asset playlist validity indicator is set1457 to ‘invalid’. Alternatively, if a transition is not reached while the media player is playing in continuous mode, then the media assetlist traversal process1400 continues todecision1463 and subsequent blocks. Atdecision1463, a determination is made whether the media player has been switched to continuous mode. If the media player has been switched to continuous mode, the media asset list traversal process1450 returns to decision1402 of the media assetshuffle playlist process1400. On the other hand, if the media player has not been switched to shuffle mode,decision1463 directs the media asset list traversal process1450 todecision1455 and subsequent blocks. Note that, according to this embodiment, if the user switches the media player back to shuffle mode before a media asset transition is reached, the media asset playlist validity indicator is not set to ‘invalid’.

Next, the first or next media asset on the media asset continuous playlist is retrieved1459 and presented1461. According to one embodiment of the invention, if the media player has just been switched to continuous mode from shuffle mode, for example beforedecision1411 ofFIG. 14A, then the media player retrieves1459 and presents1461 the first media asset on the media asset continuous playlist. However, if the media asset continuous playlist has been partially traversed (e.g., some media assets on the media asset shuffle playlist have already been presented1461) then the next media asset on the media asset playlist will be retrieved1407. Thereafter, the media assetlist traversal process1400 continues todecision1463 and subsequent blocks.

According to some embodiments of the invention, if the end of the media asset continuous list is reached, the media assetlist traversal process1400 starts over at the first media asset on the media asset continuous list. However, in other embodiments, anoptional decision1465 is added. Ifdecision1465 determines that the end of the media asset continuous list has been reached, then the media assetlist traversal process1400 ends. Otherwise, according to these embodiments, the media assetlist traversal process1400 continues todecision1455 and subsequent blocks.

FIGS. 15A and 15B are illustrations of an exemplary media asset playlist arrangement according to one embodiment of the invention. In some embodiments of the invention, the media asset playlists are stored in persistent memory. In other embodiments, the media asset playlists are stored in volatile memory. The playlist arrangement is suitable for use with a portable media player, for example the

media device

100,200,700 or900 illustrated inFIGS. 1,2A,2B,7 and9A-9C.

FIG. 15A illustrates a mediaasset playlist arrangement1500 where amedia asset playlist1501 contains continuous playlist mediaasset data entries1503. The mediaasset data entries1503 containpointers1505 tomedia assets1507 which are located inmedia storage1509. Themedia storage1509 is, for example, themedia storage820 in themedia player804 ofFIG. 8. Additionally, a playlist pointer (pp)1511 and a media asset pointer (map)1513 are shown. Theplaylist pointer1511 serves to keep track of the currently selected playlist. In some embodiments, operating a media player control, such as a switch, alters theplaylist pointer1511 to point to another playlist.FIG. 15 shows a single playlist stored in theplaylist storage1502. However, multiple playlists are used in some embodiments (seeFIG. 15B). Themedia asset pointer1513 points to thecurrent media asset1507 being presented (e.g., played).

In the embodiment shown inFIG. 15, themedia asset playlist1501 is a continuous media asset playlist (cont_PL). The continuousmedia asset playlist1501 is typically a playlist where media assets are arranged in a particular, non-random order. For example, thecontinuous media playlists1501 can be arranged by artist, author, album, or in alphabetical order. Alternatively, the continuousmedia asset playlist1501 may be arranged in a user specified order. Typically, the continuousmedia asset playlist1501 is static (i.e., unchanging). However, in some embodiments themedia asset playlist1501 may be altered using a media management application running on a host computer, for example, themanagement module206 running on thehost computer202 ofFIG. 2.

As noted above, themedia asset pointer1513 points to the currently selected media asset data entry1503 (designated CPL_x inFIG. 15). When themedia asset playlist1501 is traversed, themedia asset pointer1513 moves to the next continuous playlist mediaasset data entry1503 in themedia asset playlist1501 upon completion of presenting of themedia asset1507 pointed to be the pointer1505 (e.g., after a song has finished playing). For example, themedia asset playlist1501 can be traversed by a media asset playlist traversal process. The typical media asset playlist traversal process begins at the first continuous playlist mediaasset data entry1503 in the playlist and traverses themedia asset entries1503 sequentially from the start of the media asset playlist (designated CPL_1 inFIG. 15) to the end of the media asset playlist (designated CPL_n inFIG. 15). Note that a person of ordinary skill in the art would understand that the order of themedia assets1507 in the media store is not important. Accordingly,FIG. 15 shows themedia assets1507 organized in a different order than the continuous playlist mediaasset data entries1503.

One example of presenting amedia asset1507 using the mediaasset playlist arrangement1500 involves a media player accessing the particular playlist mediaasset data entry1503 that themedia asset pointer1513 is currently pointing to. Next, thepointer1505 associated with the continuous playlist mediaasset data entry1503 is followed to locate themedia asset1507.

FIG. 15B illustrates a mediaasset playlist arrangement1550 according to one embodiment of the invention. The descriptions given for1501-1509 inFIG. 15 also apply toFIG. 15B. Additionally,FIG. 15B shows a mediaasset shuffle playlist1551 stored inplaylist storage1502. The media asset shuffle playlist1551 (shuffle_PL) contains shuffle playlist mediaasset data entries1553 which containpointers1555 to continuous playlist mediaasset data entries1503. Note that this arrangement of pointers is merely one way to describe a shuffle playlist and is intended to be for illustrative purposes only. Those skilled in the art of computer programming will understand that there are many ways to implement a shuffle playlist and that this description is intended to be exemplary.

As discussed above with reference toFIG. 15, the playlist pointer (pp)1511 is also shown inFIG. 15B. InFIG. 15B, theplaylist pointer1511 points to the mediaasset shuffle playlist1551. However, theplaylist pointer1511 may point to any playlist (as indicated by the dotted line andplaylist pointer1511′). In some embodiments, operating a media player control, such as a switch, causes theplaylist pointer1511 to be moved to point to another playlist. By way of example, either of the two playlists shown inFIG. 15B (shuffle_PL and cont_PL) may be selected by operating a media player control. In one implementation, the media player control can be a multi-position switch with at least a ‘shuffle’ and a ‘continuous’ position.

Further, themedia asset pointer1513 points to the currently selected media asset data entry1553 (designated SPL_y inFIG. 15B). When the mediaasset shuffle playlist1551 is traversed, themedia asset pointer1513 moves to the next shuffle playlist mediaasset data entry1553 in themedia asset playlist1551 upon completion of presenting themedia asset1507 corresponding to the currently selected media asset data entry1553 (e.g., after a song has finished playing). For example, the mediaasset shuffle playlist1551 can be traversed by the media asset shuffleplaylist traversal process1300 ofFIG. 13. However, in general, a typical media asset playlist traversal process begins at the first shuffle playlist mediaasset data entry1553 in the playlist and traverses the shuffle playlist mediaasset data entries1553 sequentially from the start of the media asset shuffle playlist (designated SPL_1 inFIG. 15) to the end of the media asset shuffle playlist (designated SPL_n inFIG. 15).

One example of presenting amedia asset1507 using the mediaasset playlist arrangement1550 involves a media player accessing the particular shuffle playlist mediaasset data entry1553 that themedia asset pointer1513 is currently pointing to. Next, thepointer1555 associated with the shuffle playlist mediaasset data entry1553 is followed to the continuous playlist mediaasset data entry1503. Subsequently, thepointer1505 associated with the continuous playlist mediaasset data entry1503 is followed to themedia asset1507, which is presented according to the capabilities of the media player.

Note further, in a typical media asset shuffle playlist creation process such as, for example, the media asset shuffleplaylist creation process1400 ofFIG. 14, thepointer1555 associated with a particular shuffle playlist mediaasset data entry1553 will usually point to a different continuous playlist mediaasset data entry1503 whenever a new media shuffle playlist is created. By way of example (and without restricting the scope of the invention), it is possible to view the creation of a new media asset shuffle playlist in the context of the description ofFIG. 15B as a reshuffling of thepointers1555.

FIGS. 16A and 16B show anexemplary timeline1600 that illustrates a series of states in a media player according to one embodiment of the invention. Indicated times on the timeline (labeled T_n, where n is an integer) each correspond with asnapshot1601 of a set of state variables and a media asset playlist. The state variables (media player status information, such as media player state indicators) shown inFIGS. 16A and 16B, as well as exemplary playlists, are shown and discussed above with reference to Table 1 andFIGS. 11-14B,15A and15B. These examples demonstrate the traversal of different media asset playlists using a media player, for example themedia player100 depicted inFIG. 1. Further, these examples includesample snapshots1601 of state variables stored or utilized by the power on and power down processes described inFIGS. 11 and 12.

Table 2 shows a list of state variables and associated abbreviations for each. Values for each state variable are shown onFIGS. 16A and 16B for eachsnapshot1601.

	TABLE 2

	pp	Playlist pointer
	map	Media asset pointer
	pos	Media asset position
	vol	Volume
	ps	Play status
	v?	Playlist validity indicator

Further, at each time T_non the timeline, a mediaasset shuffle playlist1603 is shown. The mediaasset shuffle playlist1603 can have the features of the mediaasset shuffle playlist1551 ofFIG. 15B. However, for ease of illustration, each media asset label shown is anactual media asset1607 rather than a pointer to a media asset. Themedia assets1607 are shown out of sequence to simulate the random ordering of the media asset shuffle playlist. A media asset pointer (map)1605 is shown as well. Themedia asset pointer1605 indicates thecurrent media asset1607 being played.

As noted above in reference toFIG. 15B, ashuffle playlist1603 can be associated with acontinuous playlist1609. As discussed above in reference toFIG. 15, the order of media assets on the continuous playlist is typically not alterable by an operator of the media player. Therefore, for the purposes ofFIGS. 16A and 16B, it is assumed that the continuous playlist does not change regardless of how often theshuffle playlist1603 changes.

The timeline begins at T₀, with an initial media player state being ‘off’. At T₀, all state variables are stored in persistent memory.

At T₁, the media player is powered on and switched to shuffle mode. Upon loading the state variables in thesnapshot1601 shown for T₁, the media player begins to traverse the shuffle playlist shown at T₁. Specifically the media player starts at a point 30 seconds into media asset MA_d. This indicates that, at some T_Pbefore T₀, the media player was powered off after playing 30 seconds of the media asset MA_d, and that the state variables indicating the media player status at T_Pwere stored before the media player was powered off.

At T₂, 30 seconds after T₁, a user sets the media player to continuous mode. The value of the playlist pointer (pp) is changed to cont_PL, indicating that thecontinuous playlist1609 is now selected. However, the media player continues to present (play) themedia asset1607 that themedia asset pointer1605 was pointing at (MA_d) on theshuffle playlist1603 until the end of themedia asset1607 is reached.

At time T₃, a transition is reached at the end of media asset MA_d. Hence, the current media shuffle playlist becomes invalid and the playlist validity indicator is set to ‘invalid’. Further, since the media player was set to continuous mode at T₂, MA_e (thenext media asset1607 on the continuous playlist1609), is presented, rather than MA_b, which was thenext media asset1607 on the now-invalid shuffle playlist.

Note that, if the media player remains in continuous mode, the continuous playlist is traversed sequentially (MA_f, MA_g, etc.).

One minute into playing of the media asset MA_e, at time T₄, the user of the media player switches the media player back to shuffle mode. Accordingly, the playlist pointer is set back to shuffle_PL.

At time T₅, a transition is reached at the end of media asset MA_e. Since the media player is in shuffle mode, the media player attempts to traverse the shuffle playlist. However, the playlist validity indicator was set to ‘invalid’ at T₃, so a new shuffle playlist1611 (shuffle_PL′) is created. Thus, thenew shuffle playlist1611 is created and the media asset pointer is moved to MA_c, which is afirst media asset1607 on thenew shuffle playlist1609.

Timeline

1600 continues onFIG. 16B. Between time T₅and time T₆, theshuffle playlist1611 is traversed normally (i.e., media assets on the shuffle playlist are presented in sequence). Thus, at time T₆, themedia asset pointer1607 has moved such that it now points to MA_f, as shown. Also, at time T₆, the user once again switches the media player to continuous mode, so the playlist pointer is changed to point to cont_pl. However, before the end of MA_f is reached, the user switches the media player back to shuffle mode at time T₇. Therefore, since the transition at the end of MA_f was never reached, theshuffle playlist1611 remains valid, as indicated by the playlist validity indicator. Accordingly, at time T₈, themedia asset pointer1605 moves to the MA_i, thenext media asset1607 on theshuffle playlist1611.

At time T₉, the user requests a new shuffle playlist. The new shuffle playlist request causes theshuffle playlist1611 to be invalidated, as indicated by setting the validity indicator to ‘invalid’. When the next transition (between MA_i and MA_x) is reached at time T₁₀, a new shuffle playlist1613 (shuffle_PL″) is created and themedia asset pointer1605 is set point to MA_d, which is thefirst media asset1607 on thenew shuffle playlist1613.

Finally, at time T₁₁, the user powers off the media player. Before the media player powers off, it saves the current state variables as media asset status indicators in persistent memory (seeFIG. 12).

Examples of ornamental designs for a media device, such as those illustrated inFIGS. 2A and 2B, are provided in (i) U.S. Design patent application Ser. No. 29/220,035, filed Dec. 23, 2004, entitled “ELECTRONIC DEVICE,” which is hereby incorporated herein by reference; (ii) U.S. Design patent application Ser. No. 29/220,120, filed Dec. 23, 2004, entitled “ELECTRONIC DEVICE,” which is hereby incorporated herein by reference; and (iii) U.S. Design patent application Ser. No. 29/220,038, filed Dec. 23, 2004, entitled “ELECTRONIC DEVICE,” which is hereby incorporated herein by reference.

Although the media items (or media assets) of emphasis in several of the above embodiments were audio items (e.g., audio files or songs), the media items are not limited to audio items. For example, the media items can alternatively pertain to videos (e.g., movies) or images (e.g., photos).

The various aspects, features, embodiments or implementations of the invention described above can be used alone or in various combinations.

The methods of this invention can be implemented by software, hardware or a combination of hardware and software. The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system, including both transfer and non-transfer devices as defined above. Examples of the computer readable medium include read-only memory, random-access memory, CD-ROMs, Flash memory cards, DVDs, magnetic tape, optical data storage devices, and carrier waves. The computer readable medium can also be distributed over network-coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

The many features and advantages of the present invention are apparent from the written description and, thus, it is intended by the appended claims to cover all such features and advantages of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, the invention should not be limited to the exact construction and operation as illustrated and described. Hence, all suitable modifications and equivalents may be resorted to as falling within the scope of the invention.