Abstract:
The present disclosure relates to a system and method for remotely operating one or more peripheral devices of a wireless device using a server and client architecture. In one aspect, the system may comprise a wireless device that includes a processor, a memory, a peripheral device, and a server adapted to communicate with the peripheral device; and a removable media device that includes a memory, a processor, and a client adapted to communicate with the server of the wireless device. In another aspect, the method may comprise the steps of emulating a hardware interface on a removable media device; mapping a peripheral device of a wireless device to the interface; mapping a processor of the media device to the peripheral device; wrapping and sending hardware commands from a client of the media device to a server of the wireless device; and executing the commands on the peripheral device.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority to U.S. Provisional Patent Applications Ser. Nos. 61/206,454, 61/206,453, and 61/206,427, filed Jan. 30, 2009, and U.S. Provisional Patent Application Ser. No. 61/206,797, filed Feb. 4, 2009, the disclosures of which are incorporated herein by reference. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention relates to a system and method for operating the hardware of a wireless device from a remote media device using a server and client architecture. 
       BACKGROUND OF THE INVENTION 
       [0003]    Current wireless device designs have all the software layers running on the handset main processor with the telephony hardware, radio hardware, Bluetooth, Audio Codec, WiFi, GPRS, display screen, camera hardware, and associated software applications. The application and the runtime environment are dependent on the particular handset hardware architecture. Accordingly, all applications and run-time environments of the device are likely not portable or compatible among devices with different hardware architectures. 
       SUMMARY OF THE INVENTION 
       [0004]    Embodiments of the present invention include a system and method where the application software, runtime environment, telephony frameworks (including those for making calls and short messages), and embedded operating system of a wireless device may be controlled remotely from the device hardware via a high speed interface (including but not limited to USB or MMIC) from a removable media device which may be a system-on-chip in any form factor, including but not limited to an MMC, SD, micro SD, SIM, SAM, or USB dongle form factor. 
         [0005]    In one embodiment, the system may comprise a wireless device that includes a processor, a memory, a peripheral device, and a server adapted to communicate with the peripheral device; and a removable media device that includes a memory, a processor, and a client adapted to communicate with the server of the wireless device. In another embodiment of the present invention, the method may comprise emulating a hardware interface on a removable media device; mapping a peripheral device of a wireless device to the interface; mapping a processor of the media device to the peripheral device; wrapping and sending hardware commands from a client of the media device to a server of the wireless device; and executing the commands on the peripheral device. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]    Features and other aspects of the embodiments of the present invention are explained in the following description taken in conjunction with the accompanying drawings, wherein: 
           [0007]      FIG. 1  illustrates a typical architecture for a wireless device with a processor co-located with the interface hardware; 
           [0008]      FIG. 2  illustrates a block diagram of an embodiment of the present invention showing a server in a wireless device and a client in a removable media device; 
           [0009]      FIG. 3  illustrates a block diagram of the hardware design of the removable media device according to one embodiment of the present invention; 
           [0010]      FIG. 4  illustrates a block diagram for the communication between the wireless device and a removable media device according to one embodiment of the present invention; and 
           [0011]      FIG. 5  illustrates a prototype implementation of the client and server according to one embodiment of the present invention; and 
       
    
    
     DETAILED DESCRIPTION 
       [0012]      FIG. 1  illustrates a typical architecture for a wireless device with a processor co-located with the interface hardware. As shown in  FIG. 1 , typical architecture for a wireless device includes a processor  102  located with the rest of the interface hardware in the wireless handset  101 . The wireless device hardware may include one or more peripheral devices, including an LCD display, keypad, or touch screen  108 ; radio hardware  109  (GSM, CDMA, TD-SCDMA, etc.); an audio codec  110 ; Bluetooth  111 ; WiFi  112 ; GPS  113 ; and a camera  114 , each connected to the main processor  102  through a hardware device driver  107 . Additionally, the handset  101  may include a software application  103 , a runtime environment  104 , hardware framework  105 , and an embedded operating system kernel  106 . 
       Client-Server Architecture and Design 
       [0013]    The remaining Figures may be used to illustrate embodiments of the present invention. As shown in  FIG. 2 , one embodiment of the present invention may include a wireless device  201  having a server  205  controlling peripheral device hardware  107 - 113 , and a removable wireless device  202  that may include a client  204  containing the application  103 , runtime environment  104 , and embedded operating system  106 . The server  205  of the removable media device  202  may be connected to and communicate with the client  204  of the wireless device or handset  201  via a communication link  203 . 
         [0014]    According to one aspect of the present invention, application  103  in the removable media device  202  may request a hardware resource through the hardware framework  105 . In response, the client  204  may request that this resource be allocated to the server  205  on the wireless device  201 . The server  205  may then virtually map the device hardware  107 - 113  on the wireless device  201  for the particular resource to the processor that is located in the removable media device  202 . 
         [0015]    By using the client/server architecture, the present invention may provide compatibility and increase the portability of a software application from one wireless device to another. The wireless device  201  does not require a sophisticated processor or complex software. Rather, the wireless device  201  may simply include drivers to manage its resources and communicate with the client  204  in the removable media device  202 . 
         [0016]    In one embodiment shown in  FIG. 2 , the server  205  and the client  204  may communicate with each other via a client-server application program interface (“API”)  214 . The API  214  at the server  205  may map the device resources to the applications  103  via the client  204 . Whenever the client application  103  requests device resources, the application request is made via the API  114  to the server  205 . This eliminates the dependency of the wireless device features and the wireless applications, and with the removable media, brings the additional benefits of application portability and security. 
         [0017]    In one aspect, the hardware framework  105  of the removable media device  202  may be a library or collection of functions for a particular one or more of the hardware devices  107 - 113 . Hardware device drivers may also be present on the removable media device  202 . This aspect, however, is not necessary. The hardware framework  105  on the removable media device  202  may simply be associated with the client  204 . That is, the actual drivers used to implement the hardware devices may be located in the wireless device  201 . This configuration is discussed in greater detail below with reference to  FIG. 5 , which shows a wireless device  201  having hardware device drivers  413 - 415 . 
         [0018]    In one aspect, the client  204  of the removable media device in  FIG. 2  may be a stub application. A stub may be a small software application. The server  205  of the wireless device  201  may also be a stub application. In another aspect, the communication link  203  may be a simple or high-speed bus, such as a USB. The communication link  203  may also be a wireless connection. Further aspects include but are not limited to USB, SD, micro SD, SIM, SAM, or MMC as a communication link  203 . 
         [0019]    An OpenMoko Neo Free Runner handset may be used for the wireless device  201 , though any hardware configuration is possible. In other aspects, a Samsung S3C2443 development board may be used as the removable media device  202 . Linux may be chosen as an open source operating system for the embedded operating system  106  in one embodiment of the present invention. Other operating systems available may include but are not limited or restricted to Win CE, Symbian, or any other embedded operating system. Another aspect may include incorporation of a graphic system (such as, for example, X-Window) that may run on embedded operating system kernel  106 . Another aspect may include MatchBox as a runtime environment  104 , but any runtime environment may be used, including Android, QT, MontaVista, and Openmoko. 
         [0020]      FIG. 3  illustrates a block diagram of the hardware design of the removable media device  202 . As shown, removable media device  202  may include RAM  301 , ROM  303 , and processor  302 . Removable media device  202  may be connected to a wireless device (such as wireless device  201  in  FIG. 2 ) via communication link  203 . The removable media device  202  may have any form factor including but not limited to MMC, SD, micro SD, SIM, SAM, or USB dongle. 
       Exchanging Data and Information 
       [0021]      FIG. 4  shows the logical data exchange between the removable media device  202  and the wireless device  201  according to one embodiment of the present invention. The removable media device  202  and the wireless device  201  may communicate with one another using an Open Systems Interconnection Reference Model architecture, wherein the communication link  203  may include a transport layer  402 , network layer  403 , a data link layer  404 , and a physical layer  405 . For example, WiFi hardware  112  or hardware  406  associated with one or more other peripheral devices (e.g., LCD display, keypad or touch screen; radio hardware; an audio codec; Bluetooth; GPS; a camera; etc.) may be mapped to a client stub  204  in the removable media device  202  using a transport layer  402  of the communication link  203 . In further aspects, interface  406   b  of the communication link  203  maps the client stub  204  to the transport layer  402 , and interface  406   a  maps the transport layer  402  to the server  205 . In another aspect, interface  407   b  maps the embedded operating system  106  to the physical layer  405 , and interface  407   a  maps the physical layer  405  to a basic processor  401  of the wireless device  201 . 
         [0022]    In  FIG. 4 , the application process may start on the client side. The client application  103  may call a local client stub procedure instead of code implementing the procedure. Stubs may be compiled and linked with the client application  103  during development. Instead of containing code that implements the remote procedure, the client stub code may retrieve the required parameters from the calling application and wrap it as a TCP/IP packet and may deliver them to the communication link  203  that connects to the wireless device  201  containing the server  205 . 
         [0023]    On the wireless device  201 , the server  205  may receive the parameters from the client, and the server  205  may call the server procedure. The server  205  may call the actual procedure on the server  205  with the parameters from the client. The remote procedure may then run, possibly generating output parameters and a return value. When the remote procedure is complete, a similar sequence of steps may return the data to the client stub  204 . After the remote procedure returns its data to the server  205 , the server may encapsulate output parameters to the format required for transmission back to the client. The server  205  may return the output parameter to the client stub  204  over the communication link  203 . The client stub  204  may complete the process by accepting the data over the network and returning it to the calling function from application  103 . 
         [0024]    In further aspects, each hardware device (i.e., WiFi hardware  112  or other peripheral hardware  406 ) that is mapped may be assigned to a logical port through which it may communicate. The server  205  on the wireless device  201  may communicate the hardware configuration of a particular hardware device to the client stub  204  on the removable media device  202 . The client stub  204  may assign a logical port to each hardware device reported by the server  205 . The logical ports may start at 8889 and may decrement the port address for each next hardware device present on the wireless device  201 . The client stub  204  may inform the server  205  of the hardware device logical port assignments. 
         [0025]    In one aspect in particular, port 8889 may be assigned to map the WiFi hardware  112  from the wireless device  201  to the removable media device  202 . When an application  103  or runtime environment  104  in the removable media device  202  requests a WiFi function, such as scanning for an access point, the client stub  204  sends this command via port 8889 to the server  205  in the wireless device  201 . The server  205  may then instruct the WiFi hardware  112  to scan and return a list of access points found through the same logical port 8889. The client stub  204  may send the list of access points to the calling application  103  or runtime environment  104 . 
       Accessing Peripheral Devices 
       [0026]      FIG. 5  illustrates the flow of information from an application  103  that requests access to WiFi hardware  112  to scan for an access point. The information flow is depicted by the arrow in  FIG. 5  in the sequence identified by the bubbles numbered 1 through 6. In this embodiment of the present invention, the wireless device  201  may include one or more hardware framework server stub applications  507 - 510  running on a baseband operating system  511  and hardware devices  306 ,  109 ,  112  driven by device drivers  413 - 415 . The wireless device  201  may also include a hardware configuration module  512  for storing the configuration settings of the hardware devices  306 ,  109 , and  112 . The media device  202  may include one or more corresponding client stubs  501 - 504 . The wireless device  201  and removable media device  202  may communicate with each other through communication link  203  via USB hardware  503 ,  506  driven by USB drivers  516 ,  505 . 
         [0027]    As shown in step  521 , an application  103  may first issue a scan command to the WiFi hardware framework  105 . In step  522 , instead of the client stub WiFi framework  501  executing the procedures/codes to access the WiFi device hardware drivers—which may not be present on the removable media system-the client stub WiFi framework may encapsulate the parameters (command and data) into a TCP/IP packet and send it to the communication link  203  via the USB hardware  506 . The command and data may be stored as the payload in the TCP/IP packet sent over the communication link  203 . 
         [0028]    Step  523  may involve the removable media device  202 , which may be remotely connected to the wireless device  201  via USB CDC RNDIS/ethernet, functioning as though it is physically connected to the wireless device  201  and sending the TCP/IP packet to the wireless device  201  at a certain port number. This may be accomplished using a USB standard endpoint descriptor. 
         [0029]    In step  524 , the wireless device  201  may receive the packet and send it to the server stub WiFi framework  510  in the baseband processor of the wireless device. Each server hardware framework (e.g.,  507 - 510 ) corresponding to a particular hardware device may have its own logical port on the TCP/IP network. The logical port may be dynamically assigned during start up. The servers  507 - 510  may inform the client stubs  501 - 504  of the hardware configuration present on the wireless device  201  and their corresponding logical port numbers. The ports may be assigned according to hardware type; for example, GSM may be 8889 and WiFi may be 8888. 
         [0030]    The server  510  for the WiFi framework on the wireless device  201  may listen to TCP/IP at port number 8888, as shown in step  525 . There may be a buffer for each logical port address on a transport layer (such as transport layer  402  shown in  FIG. 4 ). The server  510  may check the buffer of a logical port address to determine if there is any data present. Once the packet is received, it may remove the encapsulation from the packet. For a framework call, the server  510  may implement the framework to call the WiFi hardware  112 . A framework may be a library of functions that implement hardware functionality, for instance, having the WiFi hardware  112  scan for an access point. 
         [0031]    Finally, in step  526 , the command may be received by the WiFi hardware  112  and executed. A result may be returned to the calling application  103  through the reverse order of information flow (i.e., from step  526  to step  525  . . . to step  521 ). A wireless device  201  may operate with the removable media device  202  as long as the server stub of server  510  may implement the parameters and API of the client stub  501 , even if, for example, the configuration of the WiFi hardware  112  is different than the corresponding hardware configuration for the removable media device  202 . 
         [0032]    The advantages of embodiments of the present invention may include one or more of the following: (1) because the wireless device does not require high processing power, and may include only the server API, there may be significant product development cost savings and/or decreased time to market; (2) wireless applications may be portable from one wireless device to any such device that contains the server API, allowing more freedom for the consumers; and (3) service providers can ensure full portability of the user interface when the consumers change wireless devices because the user interface of the new wireless device can be programmed in the removable media device. 
         [0033]    Although illustrative embodiments have been shown and described herein in detail, it should be noted and will be appreciated by those skilled in the art that there may be numerous variations and other embodiments that may be equivalent to those explicitly shown and described. For example, the scope of the present invention is not necessarily limited in all cases to execution of the aforementioned steps in the order discussed. Unless otherwise specifically stated, terms and expressions have been used herein as terms of description, not of limitation. Accordingly, the invention is not to be limited by the specific illustrated and described embodiments (or the terms or expressions used to describe them) but only by the scope of claims.