System for standardizing updates of data on a plurality of electronic devices

FIELD OF THE INVENTION

[0003] The present invention relates generally to the communication of data to handheld devices and relates particularly to a system and method for ensuring that a number of different devices contain and access the same stored information.

BACKGROUND

General State of the Art

[0004] The recent proliferation of electronic devices for recreation, information management and communication has taken routine computing power far away from the desk-bound personal computer. People in all walks of life are using such devices in the home, in the office, in factories, out in the field, and on the road. There are a diverse range of possible applications of such devices, including communication, business, navigation, entertainment, and even the management of basic household chores. The innovation rate continues to accelerate at a rapid pace—driven by end-user demand and the proliferation of new devices, standards, and protocols. Whereas today many users only access a single device for a single task, in the foreseeable future, users will want multiple functionality across many devices in their possession.

[0005] Although devices in use and those that can be envisaged come in all shapes and sizes, they present similar challenges for the people who make them and for the providers who offer services for them. This is because there are many attributes the devices share. Inside a typical device can be found hardware, and, interfacing with the user, the devices utilize various software components and often a complex operating system. Accordingly, there is potential for a single comprehensive infrastructure to be developed to enable a plethora of such devices to be upgraded, configured, and managed in a standardized manner. With standardization comes a greater desirability, reliability, and interoperability to meet the ever-increasing demands of end users.

[0006] Although cell phones, personal digital assistants, game stations, and car navigation systems are being used by a steadily increasing population of users, the level of user sophistication is not increasing significantly. Customers prefer to avail themselves of the advanced features of these devices without wanting the effort of configuring each new device for themselves. The user community is evolving into one that wants to take an idea, such as a list of frequently-dialed numbers, from one device to another but does not want to be distracted by the operating details of every device, nor the logistical complication of ensuring maximum consistency in their own data on all the available devices.

[0007] Furthermore, devices now becoming available are rarely single-function devices. Increasing the number of functions of a device only increases the level of personalization that is possible. Correspondingly, users are coming to expect unified access to their own data wherever they are—independent of what device they are using or what service they are connected to. Ideally, access to data should not depend on a user's location, as determined by which network a user has “roamed” into.

[0008] Accordingly, common problems associated with a world populated with a multitude of individual devices include: updating functionality on devices after sale, and preserving user-specific settings when coping with changes of location or device. These problems are preferably addressed by the companies that provide services and those that supply the devices rather than by the individual users. End users merely want devices that are easy to use, reliable, and enhanceable in a straightforward way.

[0009] Traditional service providers as well as large organizations such as airlines, banks, and a vast number of other enterprises, offer services to their customers and end users through devices. They want to increase their revenue from both existing and new services. They need to adopt ever more flexible ways of retaining existing customers and attracting new ones while continuing to add more services.

[0010] Device manufacturers want to upgrade existing devices with new software components more efficiently, and replace existing devices with new devices in such a way that time is not lost in transferring over a user's settings. The simpler it becomes for end users to upgrade and extend their usage, the more likely it is that those end users will buy new devices more frequently. Device manufacturers are also vying to sell additional devices to their installed customer base, for example a complex cell phone for business use and a simpler one for personal use. Along with service providers, device manufacturers want the flexibility to add new services, even to existing devices.

[0011] Thus, to successfully deploy, service, and maintain a plethora of devices, service providers and device manufacturers must be able to update them and add functionality to them after they have been sold. Such a capability not only preserves data, thereby enhancing its value to the user, but may also extend a device's useful lifetime. But such a task is complex not just because of the number of different types of devices currently available but because of the burgeoning number of individual users. Although a pair of devices may be identical, no two users are alike. So, vendors must get not just data to and from the device, but they must ensure user-specific or location-specific preferences are updated or maintained from one device to another, including when devices are replaced or upgraded. In short, vendors need flexible software component management, robust data management, and effective preference/configuration management.

[0012] Ultimately, then, end users want more device choices, more freedom to control preferences, more access to their data, and more personalization. At the same time, end users also want less hassle, less time spent reconfiguring preferences, and fewer worries about access to personal preferences while roaming and upgrading. Service providers want to be able to obtain more revenue from existing and new services, greater levels of customer retention, and more ways to improve the customer relationship. To achieve this, service providers want to minimize the overheads and time associated with deploying device upgrades, and want to spend less time on activities that are beyond their area of expertise. Device manufacturers want to be able to easily upgrade existing devices, sell more devices, and offer more services to gain a competitive advantage. Such gains will serve to optimize the product-development cycle time.

End User Expectations

[0013] Specific problems associated with personal devices such as cell phones are that end-users do not want to be troubled with the need to reset preferences every time they roam into a different network. Similarly, when upgrading an existing phone or purchasing a second phone, the user does not want to reset their preferences from scratch and reenter a phone book. Such personal trends run up against the technological trend that cell phones, for example, are getting more powerful with an increasing number of features that require either the end user or a service provider to configure.

[0014] With a large number of options such as SMS, MMS, wireless internet (WAP), fast internet access, “Bluetooth” connectivity, SyncML, transparent access to data such as e-mail, contacts, and calendar—even delivered through a corporate firewall, personalized ring tones and melodies, greater freedom to roam, and many others, cell phones are far from being fixed-function devices. Service providers and device manufacturers have to provide the appropriate device and preference functionality because users continue to demand more of their mobile devices.

[0015] Furthermore, the next generation of cell phones will be enhanced with PalmOS, Symbian, J2ME, WindowsCE, and other similar advanced operating systems to let service providers and end users download new software modules on their own. Similarly, personal digital assistants (PDA's) will have “Bluetooth”, infrared, wireless Ethernet (802.11a, 802.11b or 802.11g), or other connections to communicate with other electronic devices and to enable wireless access to the Internet and other networks from the PDA. Users will expect automatic configuration, so they simply achieve seamless access when they connect. Accordingly, software component management, data management, and preference/configuration management will become vital to make this efficient.

[0016] Correspondingly, the next generation of screen phones—whether based on traditional analog/digital circuit switched technology, or VoIP packet-switch technology—will offer an enhanced set of services that offer much more than a phone call. It is anticipated that end users will have access to voice and video conferencing while checking e-mail, contacts, calendar, stock quotes, news, and weather. Clearly, when presented with so many options, swift and easy upgrade of data and preferences will be desirable, if not essential. entertainment devices provide another arena in which standardization of upgrades and user references is likely to become important. Users of game consoles want to connect with a community of players so that they can compete, post scores, get hints and tips while playing, read game reviews, and generally share their experiences with other players around the world. Constant upgrades to game software and devices will be needed to satisfy these end users. But hey will not be satisfied if they have to perform the upgrades themselves.

[0017] Similarly, televisions, set-top devices, personal video recorders, digital audio players such as MP3 players, and home audio systems have become devices with greatly enhanced functionality—including the ability to communicate with one another. The home entertainment center will soon comprise a number of separate but connected devices, enabling a variety of digital media to be shared throughout the house and among friends. The number of device upgrades required to achieve such a level of connectivity is likely to be more than any end user will be willing to make.

[0018] Many devices currently available can be referred to as “productivity devices.” For example, car navigation systems are already in widespread use. Car command centers can soon expect to be able to alert drivers to real-time traffic and construction delays. Plus, the ability to access e-mail, calendar, and address book from an in-car device will assist in improving productivity even when on the move. Even so, such facilities will benefit from transparent synchronized updates of individual users' preferences and data.

[0019] Internet terminals and “web pads” will, before long, offer very easy ways to perform standard functions such as internet browsing, e-mail transmission, calendar, as well as provide basic document creation tools such as word processors and spreadsheets. These systems and other systems with similar capabilities will serve as enhancements or extensions to PC's, without actually replacing PC's but will benefit enormously from synchronized update of preferences.

[0020] Daily life is also becoming more and more influenced by a category of devices known as “controller devices,” for example, cable routers, high-end appliances such as refrigerators, and alarm systems. Such devices typically take two forms: they are either the unseen black boxes that control certain critical daily functions; or they are the part of larger appliances that give the user functionality control. In both cases, these devices are converging towards other electronic devices in their capabilities, are becoming connected to the rest of the digital world and are communicating with other like devices. This convergence presents a challenge to service providers and device manufacturers not only because of the software management required, but also because these controllers have very long life cycles. With these long life cycles comes the need to enhance the controller devices while they are in use.

[0021] Today, these devices are hardware-intensive products that supply a single function. But as with personal devices, they are becoming more service-driven. Telemetry is one technology that allows the shift from product/device to product/service. Telemetry is a growing trend across a variety of devices that enables vendors to determine and analyze problems on working devices, fix the problems, and make adjustments to prevent the problems from recurring. As these devices get more user-specific and in need of constant upgrades, their complexity increases and the likelihood that they will benefit from a means for simplifying the upgrade process also increases. Telemetry is already being seen in cars, airplanes, and elevators today. Its application is likely to spread to phones, alarm systems, and “white goods” appliances.

[0022] In essence, people are wanting increasing levels of control, preferably from any where, on any device. Whether it is to control what their children can and cannot access on the internet and view on television or whether they want to control when their heater turns on and off, such levels of control require complex software component management, data management, and preference/configuration management.

[0023] Many household appliances, such as refrigerators, dishwashers, ovens, and washing machines, have not required network connections or software modules hitherto. In the future, the refrigerator, for instance, will be smart enough to monitor its own contents. But, in general, people simply want to buy a refrigerator that will be reliable and will last. Vendors, then, must somehow retain a customer relationship throughout a long product life cycle, so customers will want to purchase add-on services and retain brand loyalty. Using telemetry, service providers or device manufacturers can monitor devices such as a refrigerator, send data to their servers, analyze the data, modify the software, and prevent future problems. In a similar way, the car controller system monitoring the engine, fuel pump, etc., is not only interacting through the dashboard with the driver, but also can communicate with a service technician in real time.

[0024] This approach is far more cost-effective than sending a service technician out to the home each month to do the monitoring. In order for this monitoring to be carried out centrally and to be able to provide more comprehensive usage information, it would be useful to be able to update the state of the device easily. Such a capability would also benefit end users, who can have the same information at their disposal.

[0025] Communication controllers such as routers are specific devices for which end users and service providers both want more functionality, including features such as firewall, virtual private network, parental controls, anti-virus protection, and other services. The devices have got to run all the time, be secure, and enable access from any where, on any device. End users prefer the simplest interface possible, for example, selecting an internet service provider or paying a monthly fee, without worrying about its maintenance. That leaves the regular upgrading of the firewall, virtual private network, parental controls, and anti-virus protection to the service provider. The service provider would also like to monitor the device itself. For all of these tasks, the preference/configuration management and data delivery management demands are immense.

[0026] Phone system users in the home and in business want features such as conferencing, unified messaging, voice mail, routing, and forwarding without wanting to spend inordinate amounts of time setting preferences. They also want personalized features such as ring tones, melodies, and a specified number of rings before the phone switches to voice mail. And they expect their preferences to remain the same whether they upgrade or replace a device, or want to tie-in with their other devices. Organizations want to audit phone usage in order to negotiate better rates. Service providers and device manufacturers want to offer these services while monitoring reliability and usage. Basically, this is complex and difficult to manage with existing technologies.

[0027] The home or residential gateway is the single point where users connect all their communication systems, entertainment systems, alarm systems, heating and ventilation systems, and Instabus/X10 electrical systems. New standards for monitoring, controlling, and unifying these gateways are arising so users can turn on the house lights as they pull into the driveway, adjust the heat using their cell phone so it is ideal when they arrive, and check the status of all their systems while they are on vacation. The proliferation of new devices is nearly matched by the number of new protocols—resulting in a preference/configuration challenge for service providers and device manufacturers.

[0028] There has been a proliferation of wireless standards from 802.11a, 802.11b, and 802.11g to “Bluetooth” and HomeRF protocols. With multiple access points throughout the home or office, users add not only PC's but also PDA's, Web pads, and entertainment devices after the fact. Aside from the obvious compatibility problems, there is the matter of security: no one wants their neighbor or competitor using their wireless access points. Since end users do not want to manage and upgrade the device themselves, the responsibility falls to the service providers or device manufacturers to handle these complex demands.

[0029] Instabus or X10 systems must communicate with sensors and switches and aggregate a variety of devices. And a single alarm system must work with multiple monitoring devices—motion sensors, door and window sensors, glass-breaking sensors—and be accessed and operated from any where. The need for software component management, data management, and preference/configuration management is substantial.

[0030] In most large organizations, certain devices have to be up and running continuously. Planned downtime must be kept to a bare minimum. Unplanned downtime has severe negative consequences. This presents an enormous challenge to organizations because these devices are often in distant locations. Such devices must be centrally administered and managed—and the ability to update to new models while existing devices continue to be deployed is vital. These tend to be single-model devices, which means that any change affects a great number of devices. Thus, the organization's economic efficiency depends upon the way it manages these devices. Such devices are often referred to as “Vertical Solution” devices.

[0031] Organizations, service providers, and device manufacturers have been creating vertical solution devices such as banking terminals, cash registers, and industrial controllers for years. But the above challenges have forced them to commit precious time and resources to building homegrown solutions for device, preferences, and data management, which is not their core area of expertise.

[0032] From self-service terminals and dialog terminals to machine controllers, industry-specific devices are deployed by organizations and operated by customers or employees who may not be technically savvy. Ease of use and reliability are critical, because these devices are essential to the well-being of the organization. They play a key role in customer satisfaction, product and service delivery time, and overall productivity.

[0033] Banking terminals are examples of self-service terminals that originally provided customers the ability to deposit and withdraw money. As with all other computing devices, the functionality and features of these terminals continue to grow. Each branch wants to offer its own promotions and serve customers in a more personalized fashion. Location-based services—even non-banking services—greatly enhance the customer experience while directly benefitting the organization. Branches can target promotions depending on a customer's net worth. Or, they can base offers on whatever the interest rate happens to be on that given day. This requires continuous two-way communication with headquarters, so corporate data must be accessed and sent immediately. And if the terminal is not operating, it has a significant effect on customer satisfaction, which directly affects customer loyalty.

[0034] Check-in terminals are fast becoming a familiar sight in airports, rental car agencies, and at events such as movies and concerts. They need to be simple, because the end user does not want to read complicated instructions just to get tickets. They must also be reliable, because their purpose is to decrease the time spent in line and enhance customer satisfaction. The devices' feature sets must be able to change seamlessly and be easily customized so that airlines, for instance, can target promotions toward frequent fliers or alter promotions quickly as demands change.

[0035] Large chain stores and restaurants—and even some individually owned establishments—feature rather sophisticated cash registers, as well as other examples of “dialog terminals.” These devices are constantly altered to account for new products, prices, and customer-loyalty promotions. They also must accommodate ever-changing connectivity with bar-code and credit-card readers. And they must also be easily self-serviced by employees who have not been trained with the requisite computing skills.

[0036] Mobile data units are used by delivery companies such as Federal Express and United Parcel Service, transportation providers, rental car companies, and field-service personnel to improve customer satisfaction and productivity through two-way connectivity to headquarters. On the road, on the train, in the hospital, or at the construction site, these devices help keep people connected. This requires flexible connectivity—for example, Bluetooth on the road and Wi—Fi (e.g., 802.11b) at the home base. It is desirable for these devices to be seamlessly upgraded in real time, thereby extending the product life cycle.

[0037] Finally, industrial machines such as printing presses and assembly lines are reconfigured for the job at hand, whether that is a new print run or a new automobile model. As critical as these machines are to an organization's earnings, the operators tend to know their machines, not the computing backbone necessary to run them. This can be problematic since these machines can be among an organization's biggest investments—and if they stop working, the organization stops earning money. Ultimately it would be desirable to have access to a software infrastructure that allows the organizations or device manufacturers to build solutions that provide the ability to modify settings in real time and add new feature sets to improve productivity automatically.

[0038] Given the above background, what is needed in the art are solutions that give service providers easy and reliable methods to improve, customize, and distinguish their services relative to competing service providers.

SUMMARY OF THE INVENTION

[0039] In accordance with the invention, inside the apparatus of the present invention, all managed devices are represented to the system by a virtual device, also called surrogate. This virtual device is a permanently available node regardless of whether the associated devices are connected to the system. This arrangement allows the system to exchange information with a device in a similar manner to a permanently available node inside a network. It is not important to any of the components inside the software system or any connected external system whether a device is currently reachable or not. The concept of a surrogate gives rise to an easily understood and less complex software architecture for building solutions for mobile devices and internet appliances. Solutions can use background processing, caching of data, and/or converting data to meet the requirements of a device. Even a required transaction process can be realized more simply.

[0040] The system of the present invention is to be contrasted with existing systems, where a log of the interactions between the system and a given device must be stored and, when a device is to be re-accessed, all control data and the data for the exchange process are potentially available at a well defined point in the right format. In existing systems, the availability of the data depends on the system capacity. The present invention will permit much faster updates, even on low bandwidth connections, because most of the data interaction between a device and the software system will have already been processed by the system prior to its transmittal to the device. The invention also allows the transfer of only selected parts of information to and from devices when requested. A reason for this could be a limited amount of time for the data transmission or even limited capacities on a device.

[0041] When a device connects to the system, the data exchange communication brings the newest information from a device to the system and vice versa. There may also be a situation where not all changes from a device go directly through the software system. For example, there may be cases where this data is stored in the surrogate until related processes are executed in the background. Such cases may arise when a back-end (e.g., a data source such as LDAP or an IMAP server) is unavailable or when the amount of time required to push the changes from the device through the entire system is greater than the device's connection time

[0042] It is to be understood that, the surrogate is not required to be a complete emulation of the existing physical devices. Furthermore different surrogates can provide unified access to completely different devices. It is up to the surrogate to supply the infrastructure with information about how to exchange device specific data. Preferably, the surrogate is not implemented as a single component inside the apparatus of the present invention. It is more appropriately considered to be a concept which uses different software components to provide the overall functionality.

[0043] Accordingly, the present invention provides an apparatus for standardizing data on two or more electronic devices, comprising: an intermediate server on which is stored a plurality of characterizations, wherein the plurality of characterizations includes a separate characterization for each of the two or more electronic devices; and a service provider that offers one or more back-end software modules to at least one of the two or more electronic devices, and wherein each of the one or more back-end software modules has data associated with it; wherein: a notification module stored on the intermediate server detects a change in the data associated with one of the one or more back-end software modules; as a result of an interaction with one of the two or more electronic devices, the intermediate server receives the change in the data associated with one of the one or more back-end software modules and creates an updated characterization for the one of the two or more electronic devices.

BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Additional objects and features of the invention will be more readily apparent from the following detailed description and appended claims when taken in conjunction with the drawings, in which:

[0045]
FIG. 1 illustrates a system that supports surrogate data delivery in accordance with one embodiment of the present invention.

[0046]
FIG. 2 illustrates exemplary processing steps for delivering data using a surrogate data delivery mechanism in accordance with one embodiment of the present invention.

[0047]
FIG. 3 illustrates a layout for a job management system within a surrogate server.

[0048]
FIG. 4 illustrates an electronic device in accordance with one embodiment of the present invention.

[0049] Like reference numerals refer to the same element throughout the several views of the drawings.

DETAILED DESCRIPTION OF THE INVENTION

[0050]
FIG. 1 illustrates a system 10 that is operated in accordance with one embodiment of the invention. System 10 includes one or more electronic devices 12, an intermediate server 60, a service provider 32, and one or more back-end software modules 36. Each device 12 is an electronic device that is capable of communicating with intermediate server 60. Service provider 32 is an electronic service such as an internet service provider. As illustrated in FIG. 1, each of the electronic devices 12 are connected to intermediate server 60. Such a connection may be through a network 2 (not shown). The connection of devices 12 to intermediate server 60 (optionally, through network 2 [not shown]) is typically a wireline connection (e.g., a connection comprising metallic wire conductors and/or optical fibers).

[0051] The electronic devices 12 are not typified by any particular type of connection. The electronic devices can be connected to intermediate server 60 by a wireline connection and/or a wireless connection (e.g., a connection comprising electromagnetic waves such as RF, infrared, laser, visible light, and acoustic energy). More information about exemplary electronic devices is found below in the section entitled “Exemplary electronic devices.”

[0052] Representative service providers 32 include, but are not limited to, Deutsche Telekom (Bonn Germany), Yahoo! (Sunnyvale, Calif.), AmericaOnline, AT&T Broadband (Denver, Colo.), Microsoft Network (Redmond, Wash.), Sprint (Kansas City, Mo.), FedEx Corporation (Memphis, Tenn.), and OnStar (http://www.onstar.com/flash.html). Back-end software modules 36 are software applications that are offered as services to users of device 12. Exemplary back-end software modules 36 include software application such as stock tracking programs, address programs, E-mail programs, and accounting programs. Available back-end software modules include, but are not limited to applications such as Microsoft Exchange Server (Redmond, Wash.) and Lightweight Directory Access Protocol (LDAP) servers. LDAP is designed to run directly over a TCP/IP stack. (See http://www.kingsmountain.com/ldapRoadmap.shtml#background). Another example of an available back-end software module is an Internet Message Access Protocol (IMAP) server. An IMAP server provides a method of accessing electronic mail or bulletin board messages that are kept on a (possibly shared) mail server (see http://www.imap.org). Yet another example of available back-end software modules 36 include Yahoo! Addressbook, Calendar, etc. (Sunnyvale, Calif.). An additional exemplary back-end software module is an Oracle Database (Redwood City, Calif.).

[0053] Although the network topology shown in FIG. 1 illustrates a service provider 32 that is external to intermediate server 60, the invention is not limited to such a topology. In fact, in some embodiments of the present invention, server provider 32 is a software module that is hosted by intermediate server 60. Furthermore, in some embodiments of the present invention, back-end software modules 36 are hosted by intermediate server 60. Each back-end software module 36 may have one or more associated data structures 38 for storage of data such as addresses, stock quotes, accounting information, or user preferences. In embodiments in which service provider 32 is not hosted by intermediate server 60, the service provider 32 host (not shown) and intermediate server 60 are connected by a communications network 39. Communications network 39 is a local area network (LAN), wide area network (WAN), metropolitan area network (MAN), an Intranet, the Internet, or any combination of such networks.

[0054] Communication of data between computers within a network and between computers in different networks is handled by a hierarchy of protocols each of which simplifies a stage in the communication process (see for example, Computer Networks, A Systems Approach, Peterson, L. L. and Davie, B. S., Morgan Kaufmann, Inc., 1996, incorporated herein by reference).

[0055] Intermediate server 60 includes standard server components including a central processing unit 16, high speed random access memory 18 for storing program modules and data structures, a network interface 20 for coupling intermediate server 60 to other computers via communication network 39, a disk controller 25 for controlling non-volatile storage 27, and one or more busses 22 that interconnect these components.

[0056] Communication network 39 optionally includes one or more routers or switches. A switch is a layer 2 network device that selects a path or circuit for sending a unit of data to its next destination, where layer 2 refers to a the second layer in the International Organization for Standardization Reference Model of Open System Interconnection (ISO OSI Model). It will be appreciated, however, that a switch may also include the function of a router, which is a layer 3 device or program that can determine the route and specifically what adjacent network point the data should be sent. For more information on switches and routers, see Peterson and Davie, Computer Networks, 1996, Morgan Kaufmann Publishers, Inc, San Francisco Calif.

[0057] Optionally, intermediate server 60 includes user input/output device 24. User input/output device 24 includes one or more user input/output components such as a mouse 26, display 28, and keyboard 30.

[0058] Random access memory 18 includes a number of modules and data structures that are used in accordance with the present invention. However, it will be appreciated that a portion of any of the modules and/or data structures stored in random access memory 18 may, in fact, be stored in non-volatile form on non-volatile storage 27. In a typical embodiment, memory 18 includes an operating system 40. Operating system 40 includes procedures for handling various basic system services and for performing hardware dependent tasks. In one embodiment, operating system 40 includes procedures for handling various basic system services and for performing hardware dependent tasks.

[0059] Memory 18 includes service provider communication module 42. Service provider communication module 42 communicates with service provider 32. The protocol that service provider communication module 42 uses to communicate with service provider 32 will depend on the exact specifications of service provider 32.

[0060] Memory 18 optionally includes notification module 44. Notification module 44 is used to track whether thee is a change in the state of data 38. When such a change occurs, notification module 44 informs service provider communication module 42. The action taken by module 42 when such a notification occurs is application specific, and will be discussed in more detail below.

[0061] Memory 18 further includes device communication module 46. Module 46 communicates with devices 12. Module 46 works in conjunction with device DNA database 52 in order to accomplish this task. DNA database 52 includes a device DNA record 102 (also called a “characterization”) for each device 12 in system 10. Each device DNA record 102 is characterized by an account 54. Each account 54 corresponds to a separate end-user of system 10 and includes all devices 12 registered to the end-user. There is a one to one correspondence between each device 12 in system 10 and a corresponding device DNA 102 record. In one embodiment, each device 12 is uniquely represented by a separate device DNA record 102 in DNA database 52. In such embodiments, each device DNA record 102 (“characterization”) tracks information about the corresponding device 12. This device information preferably includes, but is not limited to, hardware characteristics of the device, such as display capabilities, memory capabilities, user preferences, a description of software applications that are loaded on the device, and a characterization of the data that is present on the device. Further details of device DNA can be found in U.S. provisional patent application docket no. 11114-003-888, entitled “SYSTEM AND METHOD FOR MANAGING A PLURALITY OF ELECTRONIC DEVICES”, filed on even date herewith and which is incorporated herein by reference in its entirety. An embodiment of the present invention that details how device DNA database 52 is populated is described in the section entitled “Exemplary DNA database” below.

[0062] Memory 18 further includes data transformation module 48. Data transformation module 48 is used to convert data received from service provider 32, such as portions of data 38, into a form of data that can be delivered to the targeted device 12. Data transformation module 48 in conjunction with characterizations such as device DNA 102 provides a number of advantages to system 10 that are not found in known systems. First, system 10 can be used in network topologies in which a user has registered one or more devices 12 with intermediate server 60. A device 12 is registered with intermediate server 60 when intermediate server 60 has a characterization, such as device DNA 102, that represents the device. An example where a single user has multiple devices 12 registered with intermediate server 60 is found in FIG. 1. In FIG. 1, devices 12-1-1, 12-1-2, . . . , 12-1-X, belong to user 1, devices 12-2-1, 12-2-2, etc. belong to user 2, and so forth. Thus, in network topologies in which a user has registered one or more devices 12, data transformation module 48 can customize data that is intended for a particular user. In particular, transformation module 48 can customize the data to each of the devices registered by that user, using the characterization, or device DNA 102, of each device. Another advantage of system 10 is that there is no requirement for a device 12 to be connected to intermediate server 60. Device communication module 46 tracks whether or not a device 12 is in communication with intermediate server 60. When a connection is formed, device communication module 46 maximizes the productivity of the connection using the transformed data 50 that has been stored for the device by data transformation module 48.

[0063] Finally, memory 18 includes a conflict resolution manager 49. Conflict resolution manager 49 is used to resolve conflicts in data associated with a given user. Conflicts arise when multiple updates to the same data item occur at various places. For example, consider the case where a device 12 is a PDA such as a “Palm Pilot” and back-end software module 36 is a Microsoft Exchange Server (See http://www.microsoft.com/exchange/default.asp). On the Palm you might change the private phone number of your colleague, while on the Exchange Server, the entry for the colleague gets a new office phone number by the administrator of the Exchange server. When synchronizing, there will be a conflict because the same address book entry was edited at different locations. Advantageously, conflict resolution module 49 determines that, although both addresses were changed, the conflict could be resolved because the changes affect different fields (private phone, office phone). In addition, when a conflict differs from the previous example in the sense that the conflict cannot be resolved automatically, conflict detection module 49 prompts the user to decide which entry is valid. Because of the advantageous architecture of system 10, this conflict resolution request can be stored by data transformation module as the separate data 50 associated with each device associated with the user. Thus, the configuration request prompt (e.g., a customized interactive query that is provided to the end-user in order to solicit a reply to a question) that is stored in the data 50 associated with the user's cell phone will have a different format from the same configuration request prompt that is stored in the data 50 associated with the user's PDA. Furthermore, device communication module 46 will erase redundant prompts from data records 50 when the user answers the configuration prompt using any registered device 10. To illustrate, conflict resolution manager 49 determines that there is a conflict in the data associated with the user that cannot be automatically resolved. Conflict resolution manager 49 sends a conflict request to data transformation module 48. Data transformation module 48 stores a conflict request formatted to the specifications of the user's PDA in a data record 50 that is associated with the user's PDA. Transformation module stores a second conflict request formatted to the specification of the user's cell phone in a data record 50 that is associated with the user's cell phone, e.g., data record 2. When the user calls in to the server 60 using the cell phone and answers the configuration prompt, device communication module 46 erases the configuration request from the data record associated with the user's palm. In one embodiment of the present invention, conflict resolution manager 49 is designed to detect conflicts between software modules that are, or may be, installed on an electronic device 12. More specifically, the conflict module 49 defines software modules needed to provide a particular service subscribed to by a user and available through a corresponding electronic device 12 and defines dependencies and conflicts between services, between services and components, and between services and hardware components (e.g., the size of memory 608 [FIG. 4]). Using this information, in conjunction with a characterization such as device DNA 102, the conflict module 49 determines whether a software module to be installed on an electronic device 12 will operate successfully. If not, the conflict module 49 modifies the device DNA 102 such that this software module is not installed until the conflict module 49 determines that the software module will operate successfully. A change in such a determination usually results from software and/or hardware changes on the corresponding electronic device 12 (e.g., a conflicting software module is removed and/or memory 608 [FIG. 4] is expanded).

[0064] In one embodiment of the present invention, service provider 32 creates an account for each user (e.g., corporate entity or individual) who uses the services provided by the service provider 32. The account typically specifies information such as usernames and passwords, authorized users, service level, and services subscribed to (e.g., a given account may provide access to only a subset of the services provided by a given service provider 32). An account preferably specifies one or more electronic devices 12 used in conjunction with the account. For example, a given account may indicate that a PDA and a cell phone (two types of electronic devices 12) may be used to access services provided by service provider 32 (through intermediate server 60). The account preferably includes, therefore, information that can be used to identify and/or contact an electronic device 12 (e.g., a telephone number of a cell phone) corresponding to the account. Additionally, service provider 32 preferably provides a means for modifying the account. In some embodiments, a web-based interface is provided to permit a user to add, remove, or modify one or more services (back-end software module 36) and electronic devices 12 corresponding to the account. More specifically, in some embodiments, an electronic device 12 is configured to access only a subset of services (back-end software module 36) otherwise available to or through a corresponding account. This account information is passed on to intermediate server 60, which incorporates this information into the device DNA database 52 (FIG. 1).

[0065] An electronic device 12 typically includes the following components: a network interface, a processor, a user interface, a memory, and a bus, which interconnects the aforementioned components. The network interface couples the electronic device 12 to the intermediate server 60. The precise structure of this component is governed by how the electronic device communicates with the intermediate server 60 (e.g., wireless or wireline). The processor executes various software modules maintained in the device 12 memory. The user interface enables a user to interact with the electronic device 12 and typically includes components such as a keyboard, touch pad screen/display, microphone, and speakers.

[0066] Exemplary Data Delivery Processing Steps

[0067] Now that the representative architecture of a data delivery system 10 in accordance with one embodiment of the present invention has been disclosed, processing steps in accordance with system 10 will be disclosed using FIG. 2 as a reference. The exemplary processing steps shown in FIG. 2 illustrate the advantages of optional notification module 44. Module 44 is used to detect a change in the state of the data 38 associated with a back-end software module 36. There are many different mechanisms for detecting such changes. For instance, a notification from the back-end system could be realized with a trigger in an SQL database system. Accordingly, in step 202, notification module 44 detects a change in data associated with back-end software module 36. A back-end software module 36 that is an E-mail program serves to illustrate this processing step. A change in the state of data 38 in this case would arise when the E-mail program receives an E-mail message intended for the user. Another example is a back-end software module 36 that is a voice mail server. A change in the state of data 38 in this instance would be the receipt of a voice mail intended for the user by module 36 and the storage of the voice mail in data 38. Yet another example is the case in which back-end software module is a stock tracking service. When an alert, triggered by a predefined change in a stock or commodity price arises, the state of data 38 will change. Alternatively, the module 36 will communicate directly to notification module 44. When a change in the state of data 38 occurs or back-end module 36 directly notifies notification module, server 60 will trigger service provider communication module 42 to interact with back-end software module 36 to query data 36 and/or to respond to a notification provided by module 36 (FIG. 2, step 204).

[0068] In processing step 206, back-end software module 36 provides data requested by device communication module 46. It will be appreciated by those of skill in the art that there are alternative methods for performing steps 204 and 206. Indeed, a notification from back-end software module 36 to notification module 44 and/or service provider communication module 42 may include all the necessary data. Therefore, in such instances, processing steps 204 and 206 are merged into a single step. In processing step 208, data transformation module 48 transforms data received from back-end software module 36 in accordance with characterizations such as device DNA 102 of the devices associated with the targeted user. This transformed data is then stored in the data records 50 that are associated with the devices of the targeted user (step 210).

[0069] To understand the advantages of step 208, consider the case in which the data requested by device communication module 46 in step 206 is an E-mail message that has two attachments, a sound attachment and an image attachment. In this scenario, the user has registered four devices with intermediate server 60. The first device has an E-mail program that supports image and sound files. In this case, data transformation module 48 reviews the device DNA 102 associated with the first device and stores the E-mail, complete with attachments, in a data record 50 that is associated with the first device. The second device that the targeted user has registered with server 60 has an E-mail program that supports image but not sound files. In this case, data transformation module 49 reviews the device DNA 102 associated with the second device, discovers that the E-mail program does not support sound, and stores the E-mail message, without the sound attachment, in a data record 50 that is associated with the second device. The third device that the targeted user has registered with server 60 has an E-mail program that does not support image or sound. In this case, the E-mail message is stored without attachments in a data record 50 associated with the third device. The fourth device that the user has registered with server 60 does not include E-mail capabilities. Data transformation module 48 ascertains this from the device DNA 102 associated with the fourth device. In this instance, data transformation module may convert the E-mail to voice mail or some other capability that the fourth device has, such as paging or some form of text messaging capability and store the converted E-mail in a data record 50 that is associated with the fourth device.

[0070] One of skill in the art will appreciate the many advantages that data transformation module 48 provides. For example, module 48 may be used to intelligently edit E-mail messages for devices that have limited E-mail capability. In another example, transformation module 48 may be used to provide a user with the best possible services on any given device 12 that is used by a user to connect to server 60.

[0071] At some point, a user opens a connection to server 60 using a registered device 12, as shown in FIG. 2, step 212. When this occurs, device communication module 46 checks to determine whether there is any outstanding data, requests for data, or user prompts that need to be communicated to device 12. Typically this is done by reviewing the data records 50 that are associated with the device 12. In one example, the data records 50 that are associated with the device may include a conflict resolution request, an E-mail message and/or a user preferences update. A user preferences update will be stored in the data record 50 associated with the device 12 when the user has updated preferences in another device that the same user has registered with intermediate server 60. In this example, device communication module sends the conflict resolution request, the E-mail message and/or the user preference update to the device 12 (step 214). In step 216, relevant transformed data is reviewed by the user with the device 12. For example, in the example provided above, the E-mail message and the conflict resolution request are made available to the user. However, the user preference update is typically not displayed to the user. In some embodiments, the user is presented with an alert that system preferences are about to be changed. Further, the user is given the option to cancel this request.

[0072] The processing steps disclosed in FIG. 2 provide just one case scenario in which system 10 (FIG. 1) is used. Many other scenarios are possible and indeed likely to arise using system 10. In one embodiment, intermediate server 60 serves as a data delivery mechanism system and/or a front end to a service provider 32. In such embodiments, intermediate server 60, and in particular the modules 42, 44, 46, and/or 49 as well as data structures 50 and/or 102 enhance the capabilities of service provider 32 with minimal program coding requirements.

[0073] Intermediate Server Architecture

[0074] A preferred embodiment of the architecture of the intermediate server 60 is described with respect to FIG. 3. Stored on the intermediate server is a job manager 301 that interfaces between the characterizations, such as device DNA records 102, other software application components 308 and a protocol adapter 305. The protocol adapter communicates with devices 12 via a protocol such as “syncML” or SOAP. It is to be understood that the apparatus of the present invention is not to be limited to the precise protocol used by the protocol adapter 305. Indeed the protocol adapter may be capable of communicating with devices 12 via more than one protocol.

[0075] Software application components 308 preferably comprise software applications for various management functions. In particular, software application components 308 include, but are not limited to, software configuration management tools (SCM) 313, at least one preference manager 311 and at least one data manager 309. Software configuration management tools 313 handle the synchronization of software programs loaded on devices 12 with other devices 12 and with the service provider 32 (shown in FIG. 1). Preference management tools such as a preference manager 311 control the synchronization of user preferences loaded on devices 12 with other devices 12 and with the service provider 32. Data management tools such as data manager 309 manage the synchronization of user data loaded on devices 12 with other devices 12 and with the service provider 32.

[0076] The job manager 301 preferably comprises one or more job management utilities that are dedicated to specific tasks. Such job management utilities are software modules internal to the job manager. For example, a job controller 303 carries out functions such as job creation and deletion, and a job tracker 307 handles job scheduling, tracking and rollback.

[0077] In particular, there are two principal scenarios where a job manager becomes important. In one circumstance, a service provider wishes to update a large number of similar devices in the same way and over a short period of time. For example, a cellular phone company wishes to make available to all holders of a particular model of cellphone a new ringing tone. In such a situation the job manager needs to be able to keep track of which devices have received the update as well as those that have not been reached and on which the update is yet to have been installed.

[0078] In another circumstance, a series of updates must be delivered to a single device over a period of time. In certain cases, these updates may be complex and time-consuming and must all be completed. Accordingly, a job manager finds utility in tracking those updates that have been successfully delivered and, if the device is disconnected before all the updates can be delivered, monitoring when the device is reconnected so that the remaining updates can be delivered.

[0079] Surrogate Job Management Description

[0080] The intermediate server 60, often referred to as a “surrogate,” preferably characterizes an operation on characterizations, such as device DNA data, as a “job.” Such jobs are preferably controlled by a job management module, as described herein above. A job can be thought of as a logical transaction from a device's view and may contain one or more distinct operations, or tasks. Operations themselves are presented as discrete instructions or sets of instructions. Jobs may be initiated by a device or by the server.

[0081] One example of a job is: when the device downloads a service, the job is not completed until all the files are downloaded. For a SyncML device, a job is defined to be all of the messages in a package that need to be performed by the intermediate server. When a SyncML package contains several SyncML messages, the job is not finished for the device until the package is completed. Another example of a job is a server initiated task that will be executed by the server itself or a client device. For example, a change from an external server that needs to be propagated to the device the next time the device is connected. Operations within a job may be required to execute in a given order or may execute in random order, according to the overall nature of the job. In fact, for operations initiated by a device, the intermediate server may not be able to impose an order of execution.

[0082] From a device's viewpoint, the definition of a job is typically protocol dependent. Thus, the interpretation of a job is preferably the responsibility of the protocol adapter 305. The manner in which application components can formulate instructions for the job manager also depends upon the nature of the operation. There are principally two kinds of operation that can be defined in instructions to the job manager: an operation against an application component; and an operation that a device needs to complete.

[0083] Operations against application components can be formatted reasonably pragmatically. A typical operation can be described with the some or all of the following parameters: Job Id.; Security Token; User Id.; Device Id.; Name of target application component; Name of the command; and Parameters for the command. Other optional parameters may also be employed.

[0084] As a consequence of such an operation, a set of instructions may be created that needs to be executed within the context of the current job. These instructions may have to be executed immediately, or can be deferred until the end of the job. However, this functionality should not be abused by the application component to schedule a job for convenience. The idea of a job is that operations within a job are logically grouped together, so that if any operation has failed, the intermediate server can rollback other operations safely. By scheduling tasks that do not logically belong to the same job, harm may be caused to another job that could have otherwise executed successfully. The same principle applies to the job manager. While a device is connected, the job manager needs to examine pending jobs for the device in question and must try to execute the jobs within the context of other current jobs, for example one that has been initiated by the device itself. The pending jobs may fail or are preferably delayed. The Job manager should not permit pending jobs to adversely affect a current job or one another.

[0085] In the case of device operation, it is preferred to delegate all the responsibility to the device. Instructions delivered to the job manager will then simply comprise a directive that it should wait for the device to acknowledge the completion of some task.

[0086] Jobs Initiated by a Device

[0087] In the case of job creation, it is preferred that a new job can only be created if there are no old jobs pending. It is further preferred that a new job is not created if it would be in conflict with any pending jobs.

[0088] Deciding whether two jobs conflict with each other can be difficult. For example, can a new user download a new service before the previous service download is finished? In such a circumstance, it is preferred that the SCM is responsible for deciding if there is a conflict for sure. However, since SCM only maintains a record of the currently perceived device state, it does not know the exact status of the immediately previous download. One simplified solution to this difficulty is that the “data type” can be partitioned into two kinds: data: one sort has no inter-relationship and the other sort does have an inter-relationship. Accordingly jobs which address databases that maintain data with an inter-relationship must be serialized. For example, SCM data, most likely, contains inter-relationships, so that a new job that alters SCM data preferably cannot be created until a previous job is completed.

[0089] Accordingly, before a job can be created, the job manager will call relevant application components to see if a new job can be created against them. Once an application component returns an affirmative response, the application must decide whether it needs to remember that a job has been created for it. For an application to decide whether two jobs conflict with each other, it can simply return an appropriate indication, in the affirmative or in the negative, depending on what type of data it supports and whether there is a pending job. Alternatively, the application can carry out some intelligent checking based on the nature of the two jobs.

[0090] In certain cases, a job can target a single component, e.g., type of data source such as an address book or an e-mail server, but it may require multiple components to accomplish this. This is further discussed herein below. A separate matter is whether a job can target multiple components in the first place. The main problem with multiple components is that all of the components need to understand the “language” the client is using. Furthermore, simple cascading of multiple jobs to the same device by the job manager may not guarantee that the jobs are correctly handled.

[0091] On the other hand, job execution typically involves the interpretation of one or more protocol specific commands and dispatching those commands from the protocol adapter to the job manager then to the server component. Once a command is executed, the job manager needs to interpret the result and takes appropriate action to complete the request.

[0092] In the example of a download service, when the SCM finishes execution of the download command, a list of actions is returned to the job manager. Using a specific example in which a user starts to subscribe to a particular e-mail service but for which the appropriate e-mail software is not installed on the user's device. In this case, actions may include:

[0093] Response sent back to the client;

[0094] List of files to be downloaded by the device before the job is completed for the client;

[0095] A notification that the job has been completed;

[0096] List of actions to be taken by the server once the device has completed the download;

[0097] Notification to the preference manager so that updated preferences can be sent out to different devices used by the user; and

[0098] Callback to SCM for post processing, followed by termination of the job.

[0099] The last of these, callback to the SCM, comprises for example, miscellaneous tasks that the SCM may need to carry out to clean up the job. The notification to the preference manager may, alternatively, occur as part of a separate job, or after the post-processing operations have been carried out.

[0100] Furthermore, job tracking preferably is handled by the job manager. Job tracking involves maintaining enough information to resume a previously interrupted job or to rollback a terminated job. The protocol adapter, job manager, and server components, all preferably utilize some level of job tracking. For the protocol adapter, it is desirable to keep track of the status of device commands so that it can perform protocol specific recovery when a job is interrupted. The Job manager preferably keeps track of all the actions it has performed on the server component, or the most recent actions, up to a predefined number. Server components preferably remember what action they have performed for each command from the job manager. Ideally, it is preferable to have a single infrastructure for job tracking.

[0101] There are many possible ways to terminate a job. A job can complete naturally, thereby terminating itself. Or, a job maybe canceled by the device before it is completed. Usually, the server can't cancel a job without the device's consent. A job can also be interrupted by a communication problem. In such a situation, the next time the device connects, the server is preferably able to support two capabilities. First, if the device intends to resume the job, the server needs to be able to resume the job from the last, e.g., most recent interruption. Determining the point from which to resume is usually the sole responsibility of the protocol adapter. Second, if the device starts a new job, the server is preferably able to determine the state of the device and take proper actions to re-synchronize the device state with server's stored perceived device state. To achieve such a re-synchronization, usually requires some cooperation between the job manager and the server components to properly rollback the actions performed for this job.

[0102] Whether a server can unilaterally cancel a job is usually a protocol dependent issue. Assuming that the server can cancel a job if the job is inactive for an extended period of time, the job manager should preferably be able to guarantee that, the next time the device connects, the protocol adapter can tell unambiguously that this job has been canceled and thus that the device can be informed of the cancellation in a proper manner.

[0103] By contrast, rolling back a previously executed command is preferably the responsibility of the job manager and the application components called by the job manager. Since rollback usually means to undo a previously completed operation, the job manager preferably supplies enough information to the application components to carry this out. It is possible that the job manager will not be able to supply enough information for a specific command executed by a specific application component. In such circumstances, the application component preferably keeps track of enough information so that it could rollback the previous operations.

[0104] Jobs Initiated by the Server

[0105] There are certain operations that resemble a job but which are not handled by the job manager. For example, a service provider has changed the definition of a service and subscribing users need to be upgraded accordingly. Or, a service provider has changed the definition of a package and subscribing users need to be notified. Another example is whereby a change from an external server needs to be propagated to all the relevant devices owned by a particular user.

[0106] If these tasks are considered to be viable jobs, there are two straightforward ways these types of problems can be solved. Either SCM can schedule a job for each device or SCM can schedule a single job for all devices. Both approaches have drawbacks, however. The first approach requires creating a huge number of jobs in a short period of time which can lead to a lot of system clutter. The second approach means, most likely, that the job will never be totally removed from the system, e.g., completed because one or two stray devices may never have been reached. Any variation of these types of solutions will most likely also be unsatisfactory in the sense that it would either consume too much resource or it would be very difficult to decide whether and when a job is truly finished. As a consequence, such tasks should be treated on a case by case basis. A sub-category of these type of jobs includes jobs that have unspecified numbers of targets but which have expiration dates. A good example is a news feed. The Job manager can generically manage jobs with a description like “send this news to every user who subscribes to this news category until 8:00 pm today.” This sort of scenario does not apply to the SCM case described herein above, in which it is implied that SCM needs to solve the problem within its own application.

[0107] Accordingly, it is preferable to impose on the server a limitation that the number of jobs created by any task must not exceed or have the potential of exceeding a pre-defined limit. Consistent with such a constraint, a job preferably has a well-defined number of targets or must have an expiration time.

[0108] In general, server initiated jobs have several characteristics that are different from device initiated jobs, as follows:

[0109] The job is created by some application server component;

[0110] Job creation will always be successful.

[0111] The job may not be executed until the next time the device is connected.

[0112] The job may be executed within the context of a job initiated by the device.

[0113] To illustrate these points, when a data manager (DM) receives a change from the external server, the DM will call the job manager to create a job. The creation of the job will always be successful since the DM need not consult any other component to decide whether this job can be created. When the device connects, the job manager will call the DM to see if it can complete this job at this time. The DM will execute this job and formulate the proper response to job manager. The job manager will incorporate this response with the responses from other components and send them back to the device.

[0114] It is important to note that, other than the creation of the job, for the case of a server initiated job, the execution, status tracking, termination, and rollback are still performed the same way as in the case of a job that is initiated by a device.

[0115] Exemplary Electronic Devices

[0116] Referring to FIG. 4, an electronic device 12 typically includes the following components: a network interface 601, a processor 602, a user interface 606, a memory 608, and a bus 610, which interconnects the aforementioned components. The network interface 601 couples he electronic device 12 to intermediate server 60 (FIG. 1). The precise structure of this component is governed by how the electronic device communicates with the intermediate server 60 (e.g., wireless or wireline). Processor 602 executes various software modules maintained in memory 608 as described in more detail below. User interface 606 enables a user to interact with the electronic device 12 and typically includes components such as a keyboard, touch pad screen/display, microphone, and speakers.

[0117] Memory 608, which typically includes high speed random access memory as well as non-volatile storage such as disk storage, stores an operating system 612, a client module 614, one or more software modules 616, device settings 626, device preferences 628, and shared-memory 630 managed by the operating system 612.

[0118] Operating system 612 includes procedures for handling various basic system services and for performing hardware dependent tasks. Operating system 612 also provides software modules 614 and 616 with access to system resources, such as the memory 608 and user interface 606.

[0119] Client module 614 enables the intermediate server 60 to manage the electronic device 12. More specifically, client module 614 can receive and process data from intermediate server 60. For example, intermediate server 60 may transmit a software module and an instruction to install the software module to the electronic device 12. Client module 614, in communication with the intermediate server 60, receives the software module and initiates the installation of the software module. Client module 614 also has access to the shared-memory 630, device preferences 628, device settings, and software modules 616, including the settings 617, preferences 618, and data 619 of the software modules 616. Accordingly, client module 614 is capable of modifying, adding, or deleting all or some aspect of each. Client module 614 may also transmit some or all of the device preferences 628, device settings 616, and software modules 616, including the settings 617, preferences 618, and data 619 of the software modules 616 to the intermediate server 60 and/or a service provider 32.

[0120] Client module 614 preferably communicates with intermediate server 60 using an efficient protocol. In particular, the protocol preferably operates effectively over both wireless and wireline networks, is adaptable to the capabilities of each type of electronic device 12 described herein, and supports a wide variety of transport protocols. In some embodiments of the present invention, client module 614 comprises a SyncML stack (see, for example, http://www.syncml.org).

[0121] Software modules 616 include all manner of applications found in electronic devices 12. An exemplary software module 12 is an E-mail program. E-mail programs in general include settings 617, preferences 618, and data 619. Settings 617 and preferences 618 are similar concepts and include, for example, limitations on the size of a corresponding address book and interface preferences. As indicated above, data 619 may comprise an address book or other information.

[0122] Device settings 626 may control how the electronic device 12 interacts with intermediate server 60. Each of the software modules 616, therefore, access intermediate server 60 in a manner defined by the device settings 626. Similarly, the device preferences 628 may preselect certain options when such options are presented to the electronic device 12. For example, when a software module 616 is being installed, it may default to a particular language as defined by the device preferences 628. And the shared-memory may be used by the software modules 616, operating system 612, and/or the client module 614 to store information independently or under the direction of a user.

[0123] Persons skilled in the art recognize that the precise make up of the electronic device 12 depends upon its nature. For example, some electronic devices 12 are more complex than others. The more complex a electronic device is, the more likely it is that the electronic device 12 includes components not found in more simplistic electronic devices 12. Generally, all that is required by the present invention is a means for communicating with the intermediate server 60, elements manageable by the intermediate server 60, and a means for managing the manageable elements (e.g., client module 614). The range of electronic devices 12 includes, but is not limited to, handheld computers, laptops, routers, switches, domestic appliances such as refrigerators and heating systems, wearable computers, personal digital assistants, cellular telephones, pagers, electronic note-pads or palm-top computers, electronic books (“e-books”), smart-cards, cameras, dicta phones, cycle computers, pedometers, GPS devices, automobile navigation systems, electronic toys, games, or other amusement devices, home gateway appliances such as “OSGI”, and home security controllers. Such electronic devices also include devices that are considered to be wearable, such as wristwatch computers and heart-rate monitors.

Exemplary Device DNA Database

[0124] Referring to FIG. 1 for exemplary network topology, one embodiment of the present invention includes a device definitions database in memory 18 (not shown). Device definitions database describes electronic devices 12 in detail. More specifically, the device definitions database comprises a device record for each of the electronic devices 12 in system 10. The device records preferably include fixed hardware descriptions, removable hardware descriptions, and operating system descriptions of the electronic devices 12. The device records also preferably include information such as typical device configurations, supported software modules, feature sets, and hardware limitations. For example, if a particular version of an electronic device 12 (e.g., a hand held computer) only has a monochrome display, this fact is included in a corresponding device record. As described in more detail below, each device record includes information that enables the creation of device DNA 102 for a corresponding electronic device 12. The device definitions database is preferably updated as new electronic devices 12 become available.

[0125] One embodiment of the present invention includes a software modules database in memory 18 (not shown). The software modules database comprises software modules. More specifically, the software modules database includes a software module record for each software module that may be required by the electronic devices 12 described in the device definitions database. In other words, the software modules database includes all software modules required by the services offered by a service provider 32 (FIG. 1). The software modules database preferably includes software modules such as e-mail programs, games, dynamic link libraries, and virtual machines and software modules such as patches and/or upgrades that modify the first type of software modules. The software modules database is preferably updated as new software modules become available.

[0126] One embodiment of the present invention includes a software definitions database in memory 18 (not shown). The software definitions database comprises a plurality of software definition records that include descriptions of the software modules stored in the software modules database. Each software definition record preferably describes software module (e.g., other software modules required for execution) and hardware requirements of a corresponding software module. For example, if a given software module requires one or more other software modules for execution, a list of these software modules is included in the software definition record. Additionally, memory usage and processor speed requirements, for example, may also be included in the software definition record. The software definitions database is preferably updated as new software modules are added to, deleted from, or modified in the software modules database.

[0127] In alternate embodiments, the software modules database and the software definitions database are combined. In these embodiments, each record of the database includes a software module and corresponding description.

[0128] The device DNA database 52 (FIG. 1) includes a device DNA 102 for each electronic device 12 that interacts with the intermediate server 60. More specifically, the device DNA database 52 includes one or more record 102 for each account 54 created by the service provider 32 and forwarded to the intermediate server 60. Each of these records 54 includes a sub-record 102 (device DNA) for each electronic device 12 corresponding to the account. Included in a sub-record is detailed information about the corresponding electronic device 12. For example, device DNA 102 for a given electronic device 12 includes information such as a fixed hardware description, a removable hardware description (including whether a given removable hardware component was ever attached), a list of software modules included on the electronic device 12, software module settings and preferences, a description of the data for each of the software modules (but preferably not the data itself), data source settings, a list of users who can use the electronic device 12, the device specific configuration for each service on the device (e.g., the location of the mail server), and device specific mappings of data sources (e.g., which address book entries are stored on which device for a specific user). Descriptions of the data typically identify when the data was last changed, periods in which the data did not change, how many entries are included (in the case of a list or database), the size of the data, and/or a general description of the data.

[0129] In one embodiment of the present invention, device DNA 102 is uploaded to intermediate server 60 from an electronic device 12 in order to update a corresponding device DNA entry 102. Additionally, the device DNA 102 may be updated by the service provider 32 (e.g., when a user, through the service provider 32, adds or removes a service supplied by one or more electronic devices 12 corresponding to the user's account). The device DNA 102 of a given account 54 may also be changed in a manner that corresponds to changes made to another device DNA 102 within the same account 54.

[0130] A service provider 32 typically provides a defined number of services. Additionally, an electronic device 12 may include software modules and data unrelated to the services provided by a service provider 32. In preferred embodiments of the present invention, information pertaining to such software modules and data is not included in the device DNA. Instead, such information is preferably excluded entirely from the device DNA or included only to the extent that it affects software modules, data, etc., corresponding to a service provided by a service provider 32. For example, if the software definitions database indicates that a first software module (e.g., a software module not included in the software module database) conflicts with a second software module (e.g., a software module included in the software module database), the device DNA 102 may reflect that the first software module is installed on a corresponding electronic device 12.

EXAMPLES

Example 1

[0131] An exemplary system that illustrates the apparatus of the present invention is the VerdiSoft Crosspoint Server (VCS), which is a single infrastructure that enables software component management, data management, and preference/configuration management.

[0132] VCS handles the complicated software component management, data management, and preference/configuration management capabilities that disparate handheld devices require. VCS thereby enables service providers and device manufacturers to concentrate on their own specialities, such as developing new products and services, or improve existing ones. Using VCS, organizations can improve customer satisfaction, enhance productivity, and therefore increase their earnings. End users obtain, easy to update, reliable devices that maintain their overall functionality but are more readily transportable.

[0133] VCS contains a number of pre-set configurations that enable it to recognize the characteristics of a multitude of disparate devices, thereby reducing deployment time for service providers and manufacturers. It recognizes the individual DNA of every device, for the lifetime of the device, from the time of its manufacture until its reconfiguration with new preferences by the end-user, and further through routine use. VCS remains scalable no matter how far ahead upgrades are desired. Whether the operating system of the device is customized, or one of the mainstream proprietary operating systems such as PalmOS, J2ME, WindowsCE, Linux, or VxWorks, VCS provides mobility, personalization, and enables the efficient delivery of telemetry services.

[0134] The VCS software is independent of device, protocol and operating system. VCS software is scalable to millions of devices and enables ahead-of-time delivery thereby permitting a service provide to offer customers new services, fixes, and upgrades before they are aware of them or before the device has been turned on. A user can choose a general pre-configured foundation, or more device-specific building blocks.

Example 2

Sample Job Employed by Job Manager

[0135] Using the example of download services, sample instructions for the job manager can be written in XML without any inference that such a protocol is limiting. Note that this XML is not generated by the software control manager (SCM). The SCM just fetches the XML instructions from somewhere and passes it back to Job manager. This means that it is the responsibility of job manager to fill in the necessary runtime parameters when executing the job.

[0136] Sample XML for a job that has 3 tasks, one for the server, one for a device and a further task for the server:

1<Tasks ordered = “yes”><Task type= “server”><id>1 </id><Target>DM</Target><Command>add</Command><Param type= “String”>email</Param></Task><Task type= “device”><id>2</id><Command>acknowledge<Command></Task><Task type= “server”><Target>SCM</Target><Command>endJob</Command></Task></Tasks>

[0137] While the present invention has been described with reference to a few specific embodiments, the description is illustrative of the invention and is not to be construed as limiting the invention. Various modifications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the appended claims.

Number	Date	Country
60363876	Mar 2002	US
60363802	Mar 2002	US
60363810	Mar 2002	US
60363877	Mar 2002	US

System for standardizing updates of data on a plurality of electronic devices

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

US Classifications

International Classifications

Abstract

Description

Claims

RELATED APPLICATIONS

Provisional Applications (4)