Patent Publication Number: US-7899959-B2

Title: Method of loading software in mobile and desktop environments

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims the benefit under 35 U.S.C. §119(a) of U.K. Patent Application No. GB0701493.9, filed Jan. 26, 2007, which is incorporated herein by reference. 
     TECHNICAL FIELD 
     This invention relates to methods for loading software in a desktop environment that allows connectivity with mobile and network resources. In particular, the invention relates to methods for providing a mobile device with a software loader that allows the desktop environment to download application software from a network resource or from the mobile device. The invention provides methods of interconnecting mobile phones, laptop or desktop computers and/or the Internet. 
     BACKGROUND ART 
     It is well known to provide desktop software applications that allow a mobile phone device to be connected and to share data and functionality. Such applications are typically provided on CD-ROM or can be downloaded from the Internet. Once installed, it is necessary to configure the desktop software application and mobile phone to allow them to communicate with each other since, at the time the application is installed in the desktop environment, it does not ‘know’ which mobile phone is to be connected. 
     The functionality of the software applications is well known, including storage of phone numbers and other contact details, sending and receiving SMS or email messages, and downloading or uploading media resources such as ringtones, photographs or movies, music files and the like. However, configuration of the software applications to connect to and interact with a particular mobile phone has been problematic, especially where a BLUETOOTH wireless connection is used as the communication channel. The limited memory available to the mobile phone prevents its use as a source of large software files and the large number of devices that use BLUETOOTH make identification of a particular device difficult. 
     It is an object of the invention to provide a method for installing application software that does not suffer from the disadvantages of the previous systems discussed above. 
     DISCLOSURE OF THE INVENTION 
     This invention comprises a method of providing connectivity between a mobile device, a desktop computing device and network resources, comprising:
         providing the mobile device with loader software that can be installed in the desktop computing device to instruct it to download application software from a remote resource, for example a network resource or from the mobile device, and that can provide configuration data to the application software;   using the mobile device to detect all desktop computing devices with which the mobile device can communicate;   using the mobile device to select one of the desktop computing devices on which the application software is to be installed;   transmitting the loader software to the desktop computing device;   using the desktop computing device to run the loader software and direct it to a network resource or the mobile device to download application software and install it using configuration data relating to the mobile device such that the installed application software can be run to provide functionality and connectivity between the mobile device, the desktop computing device and/or network resources.       

     The mobile device can be a mobile phone or other such wireless handheld device, PDA, or the like. The desktop computing device can be a laptop or other personal computer or the like. The network resources are preferably Internet resources but can also include private, local area or intranet networks. 
     The loader software is typically a small executable file handled by the operating system used by the phone, for example JAVA software file. The loader software can also include data identifying the mobile device so that the application software can be automatically configured to connect only to the originating mobile device. 
     Connection between the mobile device and the desktop computing device is preferably achieved using a BLUETOOTH wireless connection. Infrared and direct cable connections are also possible. 
     Connection between the mobile device and the desktop computing device is preferably achieved using Bluetooth. Infrared and direct cable connections are also possible. 
     The step of detecting desktop computing devices preferably includes displaying all such devices so as to allow easy selection of the desired device by a user. 
     By using the mobile device to provide both installer software and, optionally, configuration data, the task of loading the software on the desktop device is made convenient and more secure. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows a schematic of the various parts of the system to which the method of the application applies. 
         FIG. 2  shows a schematic of the desktop application. 
         FIG. 3  shows the basic elements of the communication between the mobile phone and the desktop client. 
     
    
    
     MODE(S) FOR CARRYING OUT THE INVENTION 
     This invention provides a convenient manner to allow users of mobile devices such as mobile phones to configure system comprising the phone  10  and a desktop computer  12  (laptop, personal pc, etc.) to interact and provide contact to the Internet  14  ( FIG. 1 ). 
     The basic components of the system comprise a phone client application, a loader application, an installer application, a web service application, a desktop client application, a desktop service application, a file manager service application and an interface manager application. The various applications are written in an appropriate language, e.g. JAVA language (J2ME) or C++ language depending on requirements. 
     The phone client application is a JAVA (J2ME) client on the phone  10  that is responsible for the distribution of the system on handsets. The J2ME client contains a small WINDOWS executable file that is downloaded to the desktop computer  12  and installs the full desktop application system  16  (see  FIG. 2 ). 
     In use, the phone client application is pre-programmed into the phone handset when it is initialised. When it is desired to install the desktop applications on a specific computer, a connection  18  is made between the handset  10  and the computer  12  in question. In its simplest form, this connection can be a cable such as a USB cable directly connecting the desktop computer and handset. Another convenient way to connect the two devices is by means of a BLUETOOTH wireless connection. The first step is for the phone handset to identify the desktop computer or computers to which it either is connected (cable) or can connect (BLUETOOTH wireless connection). Using the phone handset to identify the desktop computer makes the selection process simpler since there are generally fewer desktop computers within range of a phone handset than there are phone handsets within range of a desktop computer. This, combined with the fact that most handsets have relatively non-distinctive names (e.g. ‘Motorola Phone’) means that it can be difficult for the desktop computer to uniquely identify a phone handset to which it is to be connected, whereas the reverse situation is less likely to be the case. 
     Once the target desktop computer  12  has been identified on the handset, it can then be instructed to transmit the loader application via the link  18 , for example by a BLUETOOTH wireless connection OBEX push command. 
     The loader application contains an executable file which runs automatically when installed on the desktop computer to download the full installer application from a specified website  20  via the computer&#39;s connection  22  to the Internet  14 . Once the loader application is transferred to the desktop computer, the user starts the installation process (clicks on program icon). The loader downloads the install application package from a centralised web server, or from the mobile phone handset and then auto-runs and install the full application software suite. 
     Due to the small size of the loader software, and due to the increasing size of memory in mobile phone handsets, it is also possible for the loader software to be resident on the memory in the handset, and for the loader to download the install application package from the mobile phone handset instead of from a centralised web server. 
     The loader application also writes handset device details to the desktop registry so that the fully installed service knows which handset device to connect to. 
     In one preferred embodiment, the loader is a small J2ME application including a simple WINDOWS/MAC executable file that is pre-installed on the handset. 
     It is desirable to keep the loader as small as possible. This is because of memory limitations on mobile phones and also because of speed of data transfer over BLUETOOTH wireless connections. Also, this allows the loader software to be loaded onto any mobile phone handset, and where it finds the main software depends on the type of handset. For this reason the client pulls the full setup from a centralised web server or from the mobile phone handset rather than containing any setup information itself. 
     The payload for BLUETOOTH wireless distribution is a small WINDOWS application that displays a dialog box with a gauge on it detailing time left as the file downloads. Once the file has been successfully downloaded it is copied to a temporary setup directory and is run autonomously by the loader software. 
     The user runs the application and is presented with a list of BLUETOOTH enabled desktop computers within the proximity. 
     The user selects the preferred destination and initiates the download of the loader executable file. Security keys are requested/exchanged and the embedded loader is transferred to the desktop computer. 
     The loader J2ME client utilises two key areas of the JSR 82 (BLUETOOTH) specification, BLUETOOTH Search and OBEX Transfer, which must be installed on the handset device for the system to work correctly. 
     The loader must first locate desktop/laptop computers in the network neighbourhood that are capable of receiving the payload, which it does by means of the BLUETOOTH search. This is an important functionality of the loader because there can be numerous devices responding to such search requests because of the penetration of BLUETOOTH technology in all manner of devices. It is therefore important to identify only devices that are capable of receiving and running the payload. 
     This is accomplished by utilising the device search and enquiry section of JSR 82. BLUETOOTH searches respond with a number of information fields that uniquely identify devices. The fields that are used by the loader are: DEVICE_NAME—A simple human readable description of the device name (not unique). 
     DEVICE_ADDRESS—A unique binary address for the specified device. 
     DEVICE_CLASS—A bitmask identifying the type of device (e.g. 1=phone, 2=smartphone, 3=computer, etc.). In some cases this field can contain more information such as the type of computer (laptop or desktop for instance) however, this information is not required by the loader as it is only interested in devices of major type ‘computer’. 
     This is accomplished by utilising the device search and enquiry section of JSR 82. Bluetooth searches respond with a number of information fields that uniquely identify devices. The fields that are used by the loader are: 
     DEVICE_NAME—A simple human readable description of the device name (not unique). 
     DEVICE_ADDRESS—A unique binary address for the specified device. 
     DEVICE_CLASS—A bitmask identifying the type of device (e.g. 1=phone, 2=smartphone, 3=computer, etc.). In some cases this field can contain more information such as the type of computer (laptop or desktop for instance) however, this information is not required by the loader as it is only interested in devices of major type ‘computer’. 
     Once all the devices have been found they are filtered out for just computers and are placed in a list from which the user can select. 
     The physical transfer of the file is handled by the JSR 82 OBEX layer. There are a number of issues at the remote end that must be handled by the client before, during, and after transfer. These revolve around different manufacturers of BLUETOOTH devices and how they handle file downloads. For instance if the user is running a device that is compatible with the MICROSOFT drivers they must first run a piece of software that allows file transfer via BLUETOOTH wireless connections. A WIDCOMM device will allow the loader application to transfer the payload without prompting the user, but, the user must then navigate to the temporary download directory created during the transfer. 
     To handle this, the user is presented with a number of different options on the phone to identify the remote end driver set. The J2ME client presents the user with a number of differing graphical wizards that guide the user through a step by step process of identifying the remote BLUETOOTH driver set. Once the remote driver set is understood the user can be guided through the download process covering areas such as: 
     Where to find the downloaded file; and 
     How to initiate the download process on the computer. 
     The loader utilises JSR 82 to handle BLUETOOTH communications. In particular it uses the OBEX API to transfer the payload application. 
     The user runs the loader application from the desktop that is pre-programmed to download a specific file from a specific web server or from the handset. The loader can be configured to connect to any server and request any file. 
     Once the requested file is (normally a single executable that runs an INSTALLSHIELD setup package or a WINDOWS MSI package) completely downloaded the loader application runs the downloaded file. 
     The installer application is responsible for installing the desktop client and service application and the file manager application and interface manager application on the desktop computer within its operating system environment. For example, in a WINDOWS OS environment, the service applications are installed as WINDOWS Services. 
     The desktop applications, when fully installed, include a desktop client, residing on the desktop computer  12 , is the central tool in the system. This can be written in a language such as J2SE (JAVA), integrating with a web service and the main desktop services to control the flow of information through the system. The desktop client also integrates with mail handling software such as MICROSOFT OUTLOOK&#39;s interface manager to handle contact and event management in the system. 
     Typical functions of the desktop client include: 
     Contacts: Add, Edit, Delete, Copy, Backup, Business Card look and feel, additional fields for OUTLOOK: Share, Merge (MICROSOFT OUTLOOK and OUTLOOK EXPRESS); 
     Text Messages: Delete, Copy, Backup, Reply, Send; 
     Events: Add, Edit, Delete, Copy, Backup, Share; 
     Documents: Add, Edit, Delete, Copy, Backup, Share; 
     Photos: Add, Edit, Delete, Copy, Backup, Share; 
     Music—Add, Edit, Delete, Copy, Backup; 
     Videos: Add, Edit, Delete, Copy, Backup, Share; 
     Ring-tones: Add, Delete, Copy, Backup, Purchase; 
     Wallpaper (Images): Add, Edit, Delete, Copy, Backup, Purchase; 
     RSS Feeds: enumeration of RSS feeds from around the world, with embedded IE (MICROSOFT INTERNET EXPLORER) viewer; 
     Internet Radio Station: Internet radio stations from around the world embedded into the viewer; 
     Phone Information: Call history, Call Cost, Battery Life, Phone home page for more information about phone; 
     Groups: Add, Edit, Delete, Copy, Backup; 
     User Registration and Profiling: Large registration page for customer information repository; Credit Card Registration; 
     Device Profile—Setup and locate devices to attach to communicate with; 
     Voice Calls—Dial, Answer, Hang-up, Ignore; 
     Purchase—Download and purchase ring-tones and wallpaper securely using SSL. 
     The desktop applications also include a desktop service application DS that runs continuously whilst the computer is switched on. The DS can be written, for example, in C++ for maximum speed and efficiency as it has to deal with potentially large amounts of data in a relatively seamless and fast manner. The core functionality of the desktop service is to act as a conduit between the desktop client described above and the mobile phone  10 . 
       FIG. 3  highlights the main functional components of the DS, comprising communications modules  24  for communication with the mobile handset, e.g. serial communications module  24   a , WIDCOMM BLUETOOTH module  24   b , MICROSOFT BLUETOOTH module  24   c ; a communication path manager  26 ; and interface parser/processor  28 ; main application processing logic  30  and a WINSOCK manager  32  for communication with the desktop client. 
     The DS uses three protocols: 
     A bespoke socket communications protocol that allows clients connected via socket (connection oriented TCP streamed socket) to send and receive data; 
     An AT command set as laid out by the GSM standards committee; and 
     Synchronisation mark-up language allowing file and object transfer. 
     The desktop service is responsible for maintaining connectivity to the phone. The service auto detects BLUETOOTH wireless or cable connection and connects on the first available channel. Every command sent to this service is interpreted and turned into a command that the phone understands. The service is installed as a background task and runs when the PC is booted up and only stops when the PC is shut down. 
     The file manager service application is installed as a background task similar to the main service application. This application monitors any changes made to the My Documents directory of the desktop computer for the current user. When files change it identifies if the file is a known type (Music, Video, Audio etc.) and then performs the appropriate action. The main use of this service is to generate thumbnails on the fly of images that are added/modified in this directory. 
     The OUTLOOK interface manager is a simple DLL that communicates using MAPI with MICROSOFT OUTLOOK to store and manage contacts and Events. The DLL has a JNI wrapper around it for integration with the desktop client. 
     Encryption can be applied to the various applications in the usual manner to improve system security. 
     A web service is provided as part of the Internet resource  14 ,  20  accessed by the desktop application described above. The software applications providing the web service can be written in PHP, for example. The web service is a fully functional web farm of high availability servers  20  that manage user content and information. All information is stored securely on raided fibre channel storage and can be accessed at anytime through a web interface residing on the desktop application system  16 . The web service  20  provides scripts for the desktop client to call to access the data for the specific user. The web service stores all its information in a clustered SQL server database. Typical functions include: 
     Contacts—Add, Edit, Delete, Copy, Backup, additional fields for Microsoft Outlook; 
     Text Messages—Delete, Copy, Backup; 
     Events—Add, Edit, Delete, Copy, Backup, Share; 
     Documents—Add, Edit, Delete, Copy, Backup, Share; 
     Photos—Add, Edit, Delete, Copy, Backup, Share, Search, Browse; 
     Music—Add, Edit, Delete, Copy, Backup; 
     Videos—Add, Edit, Delete, Copy, Backup, Share, Search, Browse; 
     Ring-tones—Add, Delete, Copy, Backup, Purchase; 
     Wallpaper (Images)—Add, Edit, Delete, Copy, Backup, Purchase; 
     RSS Feeds—enumeration of RSS feeds from around the world, with embedded IE (MICROSOFT INTERNET EXPLORER) viewer; 
     Internet Radio Station—Internet radio stations from around the world embedded into the viewer; 
     Groups—Add, Edit, Delete, Copy, Backup; 
     User Registration and Profiling—Large registration page for customer information repository, Credit Card Registration; 
     My Home Page—Public web page; 
     User Control Panel—Object management (Events, Contacts, etc.); 
     Publish Control—Allow users to publish to public domain; 
     Online Store—Allow purchase of Ring-tones and Wallpaper; 
     Payment Gateway Integration—Integration with payment gateway provided by banking or other financial service company; 
     SSL Certification—Secured SSL domain and logos; 
     Application Download—Download of INSTALLSHIELD for main application; 
     Additional Web-space—basic default storage capacity, option to purchase further storage space; 
     Admin Control Panel—Publish, Ban, Content Management, RSS feed management, Radio station management. 
     The handset includes a corresponding service as part of the system which handles the normal phone functions and other system functionality: 
     Contacts—Add, Edit, Delete, Copy, Additional fields for specific device; 
     Text Messages—Delete, Copy, Backup, Send, Receive; 
     Events—Add, Edit, Delete, Copy; 
     Photos—Add, Edit, Delete, Copy; 
     Music—Add, Edit, Delete, Copy; 
     Videos—Add, Edit, Delete, Copy; 
     Ring-tones—Add, Delete, Copy; 
     Wallpaper (Images)—Add, Edit, Delete, Copy; 
     Device Searching—Query devices in neighbourhood (BLUETOOTH and Cable) and feed results back to desktop client; 
     Stack Integration—MICROSOFT, WIDCOMM, etc.; 
     Call History Log and Additional Phone Information—Call History, Call Duration; 
     Call Handling—Dial, Hangup, Ignore; 
     Profile Logon—Specify how to connect to phone from desktop client. 
     The J2ME handset client is responsible for naming the payload application when it is delivered to the remote computer. JSR 82 allows software to identify its own device address. BLUETOOTH device address are 12 digits long and are read in six pairs of two, e.g. 23:ab:12:0e:6f:8c. 
     Assuming a base name of the loader payload is loader.EXE. The J2ME client takes the device address and appends it to the end of the loader name. Using the above example the name of the file that is transferred will be loader23ab120e6f8c.EXE. 
     All of the applications are capable of identifying the name of the running application (itself) and the first job of the loader is to read the application name and break it up into its constituent components and write the device address into a configuration file on the hard-disk. The software then knows the address of the device that sent the payload and therefore does not need the user to go through a complex setup procedure to locate the remote device (phone) again because it already knows it. 
     For organisations that use proxy gateways for internet connectivity, the loader must respond to these settings and offer a dialog box for username and password entry. The main website will also store the download in a secure directory that will require an additional username and password that can be hard coded into the application. 
     Additional functionality may also be provided to the system. The J2ME client has BLUETOOTH connectivity built in that can be easily extended to provide additional support on mobile devices. Some sample applications include securing and synchronising personal data between desktop software and mobile phone; updating and synchronising EPG (electronic program guide) for mobile TV viewing from desktop and transfer to mobile phone, and providing in depth user support and help guides.