The subject of this invention relates to the communications industry. Specifically, the present invention is directed to mobile telephones and more particularly to the ability to transfer the data contents of a mobile telephone memory to some other digital device. Examples of such data include phone number directories and pictures, among others.
Mobile telephones have been in existence for some time. Initially, these devices were limited to audio messaging typical of telephony communications. More recently other services and functions have emerged for use on a mobile, or cellular telephones. These services include text messaging, pictures, GPS location and Internet browsing.
One consequence of these emerging services, driven by accelerating technology, is the need for users to update their equipment. This trend has been exacerbated by cellular service providers who offer incentives to upgrade. Of course the reason for this is to encourage the user to spend more time on the air, thus increasing the revenue of the service provider, but the result is that a user will have certain data stored on his/her present cell phone that will need to be transferred to a the new phone or, more likely, have to be reentered.
Although some cellular service providers currently provide a method for accomplishing such a data transfer, the solution is specific to a device and typically performed only at a provider's store. Thus if the user upgrades or changes to a non-compatible device, the transfer method is useless. Each of the plethora of cell phone manufacturers provides unique connections to their phones, both physical and electrical. Thus while a user may buy a newer phone from the same manufacturer, the interconnect method will likely be different, again rendering the data transfer method useless.
Also present in the prior art are solutions that enable a user to backup their cell phone data to the cellular service providers network which over time is very expensive to the consumer because of the repeating monthly service charge and once using the service, locks in the consumer with that particular service provider. Other solutions include software and cable solutions that are PC centric and difficult to use because of the non-standard cell phone driver requirements needed to run software on a PC, for example SnapSync™ from FutureDial, Sunnyvale, Calif.), and other devices such the Mobile Whiz from i. Tech Dynamic Limited, Hong Kong, because of the products limited features, network specific cell phone support (GSM cell phone only), and non-functional form factor. Each of these has limitations. For example, backing up to a network diminishes the portability of the data and requires a network capable cell phone. In some cases, the network that is used is not compatible with others phones or networks, severely limiting viability of data back-up. With the use of network solutions as well as the other solutions above, data portability and ease of use is a problem.
A further problem with the prior art is that there is no way to simply back up the data contained in the cell phone memory. Thus if the user drops the phone and breaks it, or, as is sometimes the case, simply looses the device, all the data contained in the cell phone memory is lost. Contemporary digital devices such as PCs, MP3 players and PDAs all have a method for storing data in an external medium to protect against such exigencies.
Because of the rather large number of cell phone manufacturers, coupled to the even wider variety of interconnect configurations, users who are upgrading or changing equipment are at a distinct economic and functional disadvantage, since they will necessarily have to purchase the requisite accessories as well as the phone. What is needed is a method and apparatus whereby a user can make a single purchase of an accessory that will adapt to a plurality of cell phones, allowing them to reuse the transfer capability again and again thereby providing a significant functional advantage to the consumer.
What would be even more advantageous would be a method and apparatus that allowed the transfer of data from a cell phone to some other digital device, for example a PDA (Personal Digital Assistant) or PC (Personal Computer). In this way the user could maintain current data on a plurality of digital devices without having to use a multitude of interconnect methods. The capability to store the data from a cell phone in an external medium provides the additional advantage of allowing for back up of critical data.
The method and apparatus of the present invention provide a cell phone user with the ability to transfer the data contents of a cell phone to a PC for editing or backup. Several advantages derive from the present invention as discussed in detail below.
The method and apparatus of the present invention provide a means for users to transfer the data contents of a cell phone memory to a PC. The apparatus of the present invention comprises a low complexity digital device having two I/O (Input/Output) connectors, one for the user's cell phone and one for connecting to the PC. Central to the apparatus of the present invention is an Inter-device Data Transfer Processor (IDTP) which contains the necessary hardware and software to automatically move the data contents of a cell phone memory to a PC using a two step process.
The process for transferring data from a cell phone to a PC is accomplished in two steps. Which step is accomplished first depends upon whether the data is being transferred from the cell phone to the PC or vice-versa. Because of the automatic nature of the software response of the method of the present invention coupled to the physical configuration of the hardware of the apparatus of the present invention, only one connection may exist at any time.
Assuming that the user wishes to transfer data from his/her cell phone to a PC, the user simply plugs the apparatus of the present invention into his/her cell phone using the appropriate connector. The IDTP senses power from the cell phone and automatically turns on, doing an internal check to see that all functions are operating properly. Once the internal check is complete the self contained software initiates a loop that waits for the user to enter a command via one of a plurality of buttons. For example, the user may depress the Backup button, signaling the self contained software to commence fetching data from the memory of the cell phone. The data are copied from the cell phone memory to the memory of the apparatus where they remain until the user takes some further action.
Once the data from the cell phone are stored in the memory of the apparatus of the present invention, the user disconnects the cell phone and connects the apparatus to a PC, for example by way of a USB connection. Since the IDTP senses that power from the cell phone has been lost, the apparatus of the present invention shuts down. However, upon connecting to the PC, the IDTP again senses power and accomplishes the power on steps as stated above.
Since the data from the cell phone were stored in the non-volatile memory of the apparatus of the present invention, they are now ready to be transferred to the PC. The user simply launches an application program on the PC and follows the procedures for operation of the program to transfer the data from the memory of the apparatus to the memory of the PC. The application program contains the necessary functionality to edit data. By way of example, a user can modify existing data, add new data or delete existing data.
Once done the user reverses the process, updating the memory of the apparatus and then updating the cell phone memory. In this way the user may transfer data contents from a cell phone to a PC using a single apparatus and alternately connecting the apparatus to the cell phone or the PC.
As can be seen, the method and apparatus of the present invention offer a distinct economic and efficient benefit to the user. This and other features and advantages of the present invention are discussed in detail below in conjunction with the drawings and figures attached.
As described briefly above, the method and apparatus of the present invention provide a user with the ability to transfer the data contents of the memory of a cell phone to another cell phone or to any of a plurality of other target digital devices.
An IDTP 110 contains a CPU 120, Memory 200 and User Controls 300, Cell Phone I/O 140 and Device I/O 130. Note that Memory 200 is actually comprised of two separate memories: flash memory containing phone book data and program memory containing the O/S (Operating System) software 205 and Phone Handler software 210. Also note that while Memory 200 is shown as a separate item, it is actually part of the CPU integrated circuit device. User Controls 300, Memory 200 and CPU 120 communicate via Address Bus 122 and Data Bus 124. As with the Bus I/O 126, these operate in the conventional manner thus are not discussed in detail to aid in clarity, however, lack of such a detailed discussion is not an implied limitation on the scope of the invention.
User Controls 300 consist of a series of buttons, for example, an Update Button and a Backup button. User Indicators (not shown) consist of a series of LEDs (Light Emitting Diodes) that inform the user of the status of the various steps in the transfer process. The reader will recognize that more or fewer buttons/indicators may be present without departing from the spirit of the invention, thus the scope of the invention is limited only by the claims.
Cell Phone I/O 140 connects to Manufacturer's Attribute Adapter (MAA) 500 and then to the user's cell phone 550 via the normal cell phone I/O connector. MAA 500 is contained within IDTP 110. The purpose for separating the Cell Phone I/O 140 and the MAA 500 is to allow a plurality of MAA modules to be interfaced with a single, universal Cell Phone I/O. In the preferred embodiment, MAA 500 is a small printed circuit board that connects to the Cell Phone I/O via well understood connector means. One advantage of the apparatus of the present invention is the ability for the manufacturer to adapt to a wide variety of cell phones simply by changing the MAA 500.
Device I/O 130 connects to Target Device 450 via interconnect 415. In a preferred embodiment of the apparatus of the present invention the connection between the Device I/O 130 and the Target Device 450 is made using a USB (Universal Serial Bus) scheme. It will also be understood, however, that the interconnect could be any of a multitude of interconnects, for example, a serial, parallel, infrared (IR) or even a wireless connection such as 802.11b without departing from the spirit of the invention, thus the use of the USB connection should not be read as a limitation on the scope of the invention. Thus another advantage of the present invention is that the user has the ability to connect to a wide variety of target devices simply by changing the Device I/O Adapter 400.
Turning now to Target Device 450, in a preferred embodiment of the present invention the target device is a PC. Contained within Target Device 450 is Application Program 455. As described in detail below, this program allows the user to manipulate data transferred from or destined for a cell phone. While the target device in the preferred embodiment is a PC, it will be recognized that other target devices could be used as long as the Application Program 455 is able to execute on the target device, thus the use of a PC in the preferred embodiment should not be viewed as a limitation on the scope of the invention.
Referring to
Beginning with
If the device connected at 1015 is a phone, the process determines if the power from the cell phone is good at Phone Power OK? decision 1025. If the power is good the process proceeds to the diagnostic routine via connector 11040. If the supplied power is not good, the process ends at the End step 1060. Several circumstances will cause the process to end at other points in the flow, thus connector 71050 attaches to the End step 1060 ending the process.
After the CPU check is completed the CPU OK? decision 1110 is executed. If the self check failed the No branch is followed causing the red LED to illuminate at Red LED On step 1180. The process then passes to the End step (1060 of
At Initiate Process Variables step 1130 the software variables associated with the transfer process are set to their initial values and at Initiate Program Counters step 1135 the various event counters are set to their initial values. These include but are not limited to such variables as memory location pointers and loop counters. Those familiar with the art will recognize that such variables/counters are required for proper operation of a software program. Since these variables and counters are common and used in the customary fashion they are not discussed in detail with the exception of those used specifically for the data transfer operations.
At Phone? decision 1140 the method of the present invention determines if the device attached to the apparatus is a cell phone. If it is not, the No path is followed to the USB application program running on the target device via connector 81145. This part of the process is discussed in detail below in conjunction with
If the communication link to the cell phone passed, the Yes path is followed to the Fetch Manufacturer's Code step 1160. The code is checked at Valid Code? decision 1165. This step is used to determine if the cell phone connected to the apparatus of the present invention is valid. If not, the No path is followed to Red LED On step 1180 and the process ends via connector 71050. If the code is valid, the Yes path passes control of the process to the Main routine in
Turning now to
If a cell phone is still attached, the Button Press? decision 1205 is entered. Here the method of the present invention determines if the user has pressed one of the function buttons on the apparatus of the invention. If no buttons have been pressed, the process follows the No path and returns to the Unplug? decision 1200. The process continues in this loop until the user takes some action.
If the user has pressed a button the process enters the 2 Second Delay Counter step 1210 where the process waits two seconds and then proceeds to the 2 Seconds? decision 1215. If two seconds has not passed the process loops back to the 2 Second Delay Counter step 1210 and reenters the 2 Seconds? decision 1215. The process will loop on these steps until two seconds have passed at which time the Yes path will be followed causing the process to enter the Blink Green Light step 1220. The purpose of the two second loop is to de-bounce the button press. The green LED is flashed so that the user receives visual feedback that the button press was successful.
Once the green LED is flashing the process enters the Backup? decision 1225. Here the method of the present invention determines which of the two buttons have been pressed. If the Update button has been depressed the No branch will be followed leading to the Update routine via connector 41230. Conversely, if the Backup button has been depressed the Yes path is followed leading to the Backup routine via connector 31235.
Referring to
The Set Memory Pointer to 1st Record step 1300 ensures that the data backup will start with the first record in the cell phone memory. Next the process enters the Set Retry Counter to 1 step 1305 resets the retry counter to the proper value to begin the data transfer. At Last Record? decision 1310 the method of the present invention determines if the most recently transferred record is the last record in the cell phone memory. If it is not, the No path is followed leading to the Fetch Next Record step 1320. Next the process enters the Transfer OK? decision 1340 to determine if the data in the currently transferred record was passed correctly. While not shown for clarity, this is accomplished using contemporary methods.
If the record was transferred successfully the record counter is incremented at Increment Record Counter step 1345 and the process returns to the Last Record decision 1310. This loop is repeated until all records have been transferred. Once the last record has been passed the Yes path out of the Last Record decision 1310 is followed leading to the Transfer OK? decision 1315. This decision is used to determine that all records have been successfully passed. If they have, the Yes path leads to the Green LED On step 1325 and then returns to the Main routine via connector 51335. The green LED on solid informs the user that the transfer operation was successful. If all the records were not successfully transferred the No path is followed out of Last Record decision 1315. In this case the red LED is turned on at Red LED On step 1330 informing the user that a problem exists with the transfer. Again the process returns to the Main routine via connector 51335.
Returning to Transfer OK? decision 1340, and assuming that a particular record did not pass successfully, the No path leads to the Retry=3? decision 1350. If the retry count has not exceeded three, the retry counter is incremented at Increment Retry Counter 1360 and the record is again fetched at Retry Fetch step 1365. From here the process returns to the Transfer OK? decision 1340 to determine if the record passed successfully on the most recent try. This loop repeats three times. If the record fails to pass correctly after three tries the Retry=3? decision 1350 yields a true result sending control out the Yes branch to the Turn Red LED On step 1355. Since there exists a fatal result, the method of the present invention passed control to the End step 1060 in
Referring now to
If the record was transferred successfully the record counter is incremented at Increment Record Counter step 1445 and the process returns to the Last Record decision 1410. This loop is repeated until all records have been transferred. Once the last record has been passed the Yes path out of the Last Record decision 1410 is followed leading to the Transfer OK? decision 1415. This decision is used to determine that all records have been successfully passed. If they have, the Yes path leads to the Green LED On step 1425 and then returns to the Main routine via connector 61435. The green LED on solid informs the user that the transfer operation was successful. If all the records were not successfully transferred the No path is followed out of Last Record decision 1415. In this case the red LED is turned on at Red LED On step 1430 informing the user that a problem exists with the transfer. Again the process returns to the Main routine via connector 61435.
Returning to Transfer OK? decision 1440, and assuming that a particular record did not pass successfully, the No path leads to the Retry=3? decision 1450. If the retry count has not exceeded three, the retry counter is incremented at Increment Retry Counter 1460 and the record is again fetched at Retry Fetch step 1465. From here the process returns to the Transfer OK? decision 1440 to determine if the record passed successfully on the most recent try. This loop repeats three times. If the record fails to pass correctly after three tries the Retry=3? decision 1450 yields a true result sending control out the Yes branch to the Turn Red LED On step 1455. Since there exists a fatal result, the method of the present invention passed control to the End step 1060 in
Returning to
In
Again looking at the Attached? decision 1510 and assuming that the apparatus of the present invention is properly connected to an active USB port on the PC, the Yes path is followed sending control of the process to the Run Auto Download step 1530. The process advances to the USB Upload/Download routine,
For now assume that the auto download has been successful. The process returns to the Edit? decision 1550 via connector 131625. This step is required because the initial download is automatic. Once the download is complete the user decides whether to edit the data or to execute an upload of modified data. If the user does not wish to edit the data, control passes to the Save? decision 1540 and then via the No branch the flow proceeds to the Quit? decision 1515. If the user does wish to edit the data, the process enters the USB Edit routine,
At the Quit? decision 1515 the application program determines if the user wishes to exit the program and end the transfer session. If the user does wish to exit the Yes path is followed leading to the End Application & Exit step 1518 and then to the End step 1060 of
Looking at
Returning to
Referring now to
At Transfer OK? decision 1670 the method of the present invention determines that the data were transferred successfully. If not the No path is followed leading to connector 71050 and then to the End step 1060 of
Looking now at connector 101535, and recalling that at the Run Auto Download step 1530 of
At Download OK? decision 1620 the method of the present invention determines that the data were transferred successfully. If not the No path is followed leading to connector 71050 and then to the End step 1060 of
The Add icon 2015 is used to add new data to the data listing to be saved to the apparatus of the present invention. Clicking on this icon activates the edit function and adds a new line to the bottom of the data list. Clicking on the Edit icon 2020 allows the user to edit existing data in the data list. The required user actions are common to editing methods and are not discussed in detail. However, it will be recognized that such actions as mousing, key entry and the like are used in the customary way. The Exit icon 2030 is used to exit the PC application and end the transfer of data to the apparatus.
The fields of the data list are comprised of a record Count 2050, Name 2060, Number/Email 2070, Type 2080 and Store To 2090. Looking at line two in the data list, an example of a complete data record is shown by the dotted line. The record count 2052 for this entry is 2. The data represent a user named Sandy Smith 2062 with a phone number of 5553232 2072. This particular phone number has a type of Main 2082 and is to be stored at a location on the phone 2092. Each of the other entries in the data list are comprised of similar fields which make up complete records.
Looking now at
As can been seen from the above discussion, the method and apparatus of the present invention provide the user with significant advantages over the existing art. These advantages include both economic savings and efficiency gains.
A first advantage of the present invention is the ability of a user to transfer data from and to a cell phone. Thus if the user wishes to change to a new phone, the data stored on the previous phone may be saved and transferred relieving the user of the need to reenter the data.
A second advantage of the present invention is the ability to backup the data stored in a cell phone to the apparatus of the present invention. Once stored within the memory of the apparatus of the present invention the user may simply leave it there for backup or, if desired, transfer the data to a PC for further manipulation or storage.
A third advantage of the present invention is the ability of a user to edit the contents of a cell phone memory in a user friendly data editing environment. Such an environment in a preferred embodiment is a PC. Having this ability allows the addition, deletion or modification of cell phone data without the clumsy and difficult mechanism provided by the limited function of the keypads of cell phones.
A fourth advantage of the present invention is the auto download upon launch of PC application. By accomplishing the transfer of data from the apparatus of the present invention to the temporary program memory of the PC resident application program, the data automatically populate the user screen making the operation efficient and user friendly.
This non-provisional utility patent application claims priority filing from provisional application No. 60/569110 filed May 10, 2004.
Number | Date | Country | |
---|---|---|---|
60569110 | May 2004 | US |