Abstract:
A new peripheral architecture is provided that allows a UI document to be embedded into a peripheral. The UI document is sent to a portable media player when the peripheral is plugged into the portable media player. The portable media player interprets this UI document to allow a user to interact with the accessory. The peripheral does not interpret this UI document but it does respond to interactions with the portable media player as the portable media player interprets the documents in response to user interactions.

Description:
CROSS REFERENCE TO RELATED APPLICATION 
       [0001]    This application is related to U.S. patent application Ser. No. 11/502,071, entitled “Graphical user interface engine for embedded systems,” filed on Aug. 9, 2006, which is a continuation of U.S. Pat. No. 7,100,118, which are commonly assigned and incorporated herein by reference. 
     
    
     FIELD OF INVENTION 
       [0002]    This invention relates to smart peripherals for portable media players. 
       DESCRIPTION OF RELATED ART 
       [0003]    A portable media player is a hard disk or flash memory based electronic device capable of storing and playing files in one or more media formats. Since October 2004, iPod sales have dominated the market for digital music players in the United States. The success of the iPod has created demand for fashionable accessories, such as protective “skins,” powered speakers, remote controls, and etc. for the iPod. In fact, a large peripheral market is a significant advantage that Apple has over its competition. 
         [0004]    In general, there are two classes of accessories: (1) passive accessories, and (2) interactive accessories. The majority of the accessories are passive accessories that either have no electronic content, such as “skins” and cases, or they contain electronics that cannot carry on an interactive dialog with the end user through the user interface that is built-in to the iPod. Examples of passive electronic accessories are headphones and amplified speaker systems—they just passively receive the analog audio signal from the headphone jack. If these devices have features that require user interaction, other than volume control and play list navigation, then they must have their own independent controls. 
         [0005]    A small number of interactive accessories do exist. Examples are the Nike+iPod Sport Kit, Apple Radio Remote, and the Griffin iTrip. All of these accessories interact with the user through the user interface that is built into the iPod. All of these accessories are sophisticated enough to require extra user interaction beyond the user interaction that is already built into the standalone iPod software. However, the high cost of building the required user interface (UI) into these accessories would price them out of the market. So, the accessory developer must either build a cheaper, less functional man machine interface, or figure out a way to use the iPod&#39;s UI. 
         [0006]    The only available method for tapping into the existing iPod UI is to write and install a unique application program onto the iPod. The additional program would need to be installed on the iPod prior to plugging in the accessory. Unfortunately, the Apple iPod is a closed platform. Thus, third party accessory developers are not able to develop add-on programs for the iPod. Rightly so, Apple uses this closed platform strategy to protect its market leading iPod intellectual property. Using the current technology, Apple has to internally develop the application and they have to distribute it packaged with the iPod firmware in new iPods. For older iPods, their firmware must be updated with the UIs for new interactive peripherals. 
         [0007]    While this approach does protect Apple, it doesn&#39;t protect the accessory manufacturer. This is because the application is included with the iPod software even if an iPod customer does not buy the accessory. For example, a manufacturer could build a peripheral interface to a treadmill that mimics the data sent by the Nike+ accessory. The treadmill would appear to work just like a Nike+ shoe because the Nike application written by Apple is already shipped for free with every iPod. 
         [0008]    Other disadvantages to Apple&#39;s current approach are: (1) it is a huge drain on Apple&#39;s engineering resources since they have to personally develop every application, (2) this limits the number of interactive accessories that can be produced because third party developers cannot participate in the development, and (3) Apple&#39;s market leading position could be at danger to an open platform just as history shows that the open PC platform took away Apple&#39;s lead in the computer industry. 
         [0009]    While the iPod has been discussed above, similar issues apply to all portable media players in general. Thus, what is needed is a new peripheral architecture that allows portable media player manufacturers to protect their internal software and intellectual property, but that is open enough to allow third party accessory designers to program the UI application for their devices. Furthermore, the IP and the market for the accessory should also be protected to encourage a proliferation of third party accessories. 
       SUMMARY 
       [0010]    In one embodiment of the invention, a new peripheral architecture is provided that allows a UI document to be embedded into a peripheral. The UI document is sent to a portable media player when the peripheral is plugged into the portable media player. The portable media player interprets this UI document to allow a user to interact with the accessory. The peripheral does not interpret this UI document but it does respond to interactions with the portable media player as the portable media player interprets the documents in response to user interactions. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]      FIG. 1  is a diagram illustrating a conventional portable media player connected to an interactive peripheral. 
           [0012]      FIG. 2  is a block diagram of a conventional peripheral architecture for a portable media player. 
           [0013]      FIG. 3  is a block diagram of a smart peripheral architecture for a portable media player in one embodiment of the invention. 
           [0014]      FIG. 4  is a method for the smart peripheral architecture of  FIG. 3  in one embodiment of the invention. 
           [0015]      FIG. 5  is a block diagram of a smart peripheral architecture for a portable media player in one embodiment of the invention. 
       
    
    
       [0016]    Use of the same reference numbers in different figures indicates similar or identical elements. 
       DETAILED DESCRIPTION 
       [0017]      FIG. 1  illustrates a portable media player  102  connected to an interactive peripheral, which includes a wireless receiver  104  and a wireless sensor  106 . As described above, a portable media player may have a closed platform so that the UI for the interactive peripheral has to be developed internally by portable media player manufacturer and packaged with the portable media player firmware in new portable media players. On older portable media players, their firmware must be updated to provide the UI for the interactive peripheral. 
         [0018]      FIG. 2  is a block diagram of a conventional peripheral architecture for portable media player  102 . Portable media player  102  includes a microcontroller  202  that executes a portable media player firmware to perform the various device functions. The firmware includes a UI program  204  that defines the appearance and the functionality of the UI, including features specific to peripheral devices, and a display control  206  that draws the UI on a display (not shown). As described above, the firmware must be updated so UI program  204  can provide the additional UI for interactive peripheral  104 / 106 . A peripheral interface  207  couples portable media player  102  to interactive peripheral  104 / 106 . 
         [0019]    Interactive peripheral  104 / 106  includes a microcontroller  208  that executes a peripheral firmware  210  to perform the various device functions. Peripheral firmware  210  controls and monitors peripheral hardware  212  to perform the various device functions. A host interface  214  is coupled with peripheral interface  207  to interface interactive peripheral  104 / 106  and portable media player  102 . Peripheral firmware  210  is also responsible for communication with UI program  204  on portable media player  102  via host interface  214   
         [0020]      FIG. 3  is a block diagram of a smart peripheral architecture for portable media player  302  in one embodiment of the invention. Portable media player  302  includes a microcontroller  303  that executes (1) firmware  304 , including display control, and (2) a UI presentation program  305 . Based on a UI document  316  from smart peripheral  306 , UI presentation program  305  generates a UI for smart peripheral  306  and writes the UI to the display control. UI presentation program  305  receives user inputs and exchanges information (e.g., variables and function calls) with smart peripheral  306  and firmware  304  as defined by UI document  316 . In response to the user inputs and the exchanged information, UI presentation program  305  updates the UI and modifies the operations of smart peripheral  306  and portable media player  302 . Smart peripheral  306  stores UI document  316  in memory and communicates UI document  316  to portable media player  302  when they are connected. Thus, portable media player  302  does not need to be preconfigured or updated with the UI for smart peripheral  306 . 
         [0021]    In one embodiment, UI presentation program  305  communicates directly with smart peripheral  306  through peripheral interface  207 . In another embodiment, UI presentation program  305  communicates with smart peripheral  306  through firmware  304 , which includes the various drivers for communicating with the display and peripheral interface  207 . 
         [0022]    In one embodiment of the invention, UI presentation program  305  is software that emulates the functions of a GUI processor chip described in U.S. application Ser. No. 11/502,071 and U.S. Pat. No. 7,100,118, while UI document  316  is a GUI document described in U.S. application Ser. No. 11/502,071 and U.S. Pat. No. 7,100,118. The GUI processor chip is available as the Amulet Graphical OS chip from Amulet Technologies of Santa Clara, Calif. In such an embodiment, UI presentation program  305  has a library storing executable codes that define the appearances and the functions of graphic user interface (GUI) objects. UI document  316  includes non-executable codes that identify the graphic user interface (GUI) objects (also known as “widgets”) that make up the UI, their parameter attributes (e.g., source of inputs, destination of outputs, and update rates), and their layout in the UI. UI presentation program  305  parses UI document  316  to determine the GUI objects, their parameter attributes, and the layout of the GUI objects. UI presentation program  305  then generates the UI from the executable codes for the GUI objects in the library. 
         [0023]    Widgets can be divided into control and view widgets. Control widgets are input objects, like function buttons, sliders, radio buttons, and other similar UI objects used to control portable media player  302  or smart peripheral  306 . For instance, a function button can send information to firmware  304  or smart peripheral  306  every time it receives an input from a user (i.e., a user event). Some control widgets are invisible such as “timer widgets” and “alarm widgets.” For instance, an “alarm widget” could send information to smart peripheral  306  each time firmware  304  changes a specific variable. 
         [0024]    View widgets are output objects, like bargraphs, numeric fields, string fields, and similar UI objects to display information from firmware  304  of portable media player  302  or smart peripheral  306 . For instance, a bargraph can request information from firmware  304  or smart peripheral  306  and update the bargraph with the information. 
         [0025]      FIG. 4  is a flowchart of a method  400  for the smart peripheral architecture of  FIG. 3  in one embodiment of the invention. The actions of portable media player  302  are presented in the left column while the actions of smart peripheral  306  are presented in the right column. 
         [0026]    In steps  402  and  404 , portable media player  302  and smart peripheral  306  are connected. This occurs when the user plugs smart peripheral  306  into portable media player  302  or when the user turns on the two devices when they are already connected. Note that the connection can be wired or wireless. 
         [0027]    In step  406 , smart peripheral  306  sends UI document  316  to portable media player  302 . 
         [0028]    In step  408 , portable media player  302  receives the UI document  316  from smart peripheral  306  and provides it to UI presentation program  305 . 
         [0029]    In step  410 , UI presentation program  305  generates the UI based on UI document  316 . Specifically, UI presentation program  305  parses UI document  316  to determine the layout and the functionality of the UI and then generates the UI accordingly. 
         [0030]    In step  412 , UI presentation program  305  receives user inputs through the UI as described in UI document  316 . The user inputs may be commands to modify the operations of portable media player  302  or smart peripheral  306 . Note that the user can provide the user inputs through physical input devices or GUI objects on a touch screen, which are then provided directly to UI presentation program  305  or through firmware  304 . 
         [0031]    UI presentation program  305  also exchanges information with firmware  304  and smart peripheral  306  as described in UI document  316 . The exchanged information may be variables from firmware  304  or smart peripheral  306  to be displayed on the UI. For example, firmware  304  may provide the song name and the song time to be displayed on the UI. 
         [0032]    The exchanged information may also be commands to modify the operations of portable media player  302  or smart peripheral  306 . These commands may originate from user events or portable media player events. For example, UI presentation program  305  may need to control smart peripheral  306  in a particular manner when firmware  304  informs UI presentation program  305  that it has reached the end of a song. Note that UI presentation program  305  may communicate directly with smart peripheral  306  or through firmware  304 . 
         [0033]    In step  414 , smart peripheral  306  exchanges information with UI presentation program  305 . As described above, smart peripheral  306  may send variables for display in the UI or commands to modify the operation of portable media player  302 . Furthermore, smart peripheral  306  may receive commands from UI presentation program  305  to modify the operation of smart peripheral  306 . 
         [0034]    In step  416 , UI presentation program  305  updates the UI in response to the user inputs from the user and the information from firmware  304  and smart peripheral  306 . If necessary, UI presentation program  305  modifies the operations of portable media player  302  in response to the information. Step  416  loops back to step  412  to continuously update the UI and interact with the user and smart peripheral  306 . 
         [0035]    In step  418 , smart peripheral  306  processes the information received from portable media player  302 . If necessary, smart peripheral  306  modifies its operations in response to the information. Step  418  loops back to step  414  to continue its interaction with portable media player  302 . 
         [0036]    Note that portable media player  302  may remove or cache UI document  316  when smart peripheral  306  is disconnected. 
         [0037]      FIG. 5  is a block diagram of a smart peripheral architecture for portable media player  502  in one embodiment of the invention. Portable media player  502  is similar to portable media player  302  except that it uses a microprocessor  503  without UI presentation program  305 , which has been replaced with a GUI processor  504  described in U.S. application Ser. No. 11/502,071 and U.S. Pat. No. 7,100,118. GUI processor  504  performs the same function as UI presentation program  305  so that method  400  of  FIG. 4  described above also applies to portable media player  502 . 
         [0038]    Various other adaptations and combinations of features of the embodiments disclosed are within the scope of the invention. Numerous embodiments are encompassed by the following claims.