An Apple patent (number 20110219024) for a persistent state database for operating system services has appeared at the US Patent & Trademark Office.

Per the patent, a database is used to store user interface state information. The database is accessed by a key having a service ID field, a caller ID field, and a caller context ID field. The caller context ID is used to identify the context in the application program from which the user interface is called. In this manner, the system can differentiate between calls from different portions of the application program which can have different user expectations of the desirable user interface state. The inventors are Yan Arrouye, Sean J. Findley and Keith L. Mortensen.

Here's Apple's background and summary of the invention: "A computer's operating system typically provides a variety of different services that are called upon by clients, e.g. application programs and other processes, to perform functions that may relate to hardware components of the computer system, or other software programs. For instance, the file system permits a client to retrieve files from a local hard disk drive to open them within an application program, as well as store them back on the disk drive when they are closed. Another example of an operating system service is a color picker, which enables a client to vary colors which are displayed on a computer monitor and/or printed on a printer.

"Many operating system services require, or at least permit, a client to provide input which determines how the function of the service is to be carried out. For instance, when a file is to be opened in an application program, the client is provided with a choice of available storage locations, and files within that location, from which to select. Similarly, a color picker may provide sliders, or other types of control elements, which enable the user to adjust the colors on a display.

"These types of services typically have a user interface associated with them, via which the user can provide the necessary input. Other types of operating system services may not require explicit user input, and therefore normally do not have a corresponding user interface. For instance, the operating system may want to keep track of a user name and password for a server, to provide for automatic reconnection.

"One example of a user interface that is provided when an application program issues a call to open or save files comprises a visual display of a directory and its contents. The user selects a file to be operated on by the application program, by clicking on a representation of the file in the visual display of the user interface. Typically, information concerning the directory displayed in the user interface is stored when the access to the operating system service terminates, e.g. the user exits the user interface. The next time the application program calls that service, the operating system causes the user interface to display the most-recently stored directory.

"There are many operating system services which are called by multiple different clients. For instance, the file system service may be called by a text editing portion of a word processor, and then called by the dictionary portion of the same word processor, or by an entirely different application program. When the text portion of the word processor calls the file system again, its user interface will display the contents of the last directory that had been accessed.

"Thus, if the most recent call to the file system was from the dictionary portion of the word processor, the user interface might display a list of dictionary files. The user must then manipulate the user interface so that it displays the directory containing the desired text files. This can be a time-consuming annoyance to the user.

"Additionally, when a desired directory is displayed to the user, the display typically occurs at a default location in the directory. For example, if files are displayed in alphabetical order, the files which initially appear are those whose names begin with A, B, C, etc. Consequently, a user may have to scroll down the user interface to find a previously selected object. If a directory contains a long list of files this can take some time.

"It is desired to provide an improved method and apparatus for storing state information relating to operating system services across invocations of the services, to ensure correct operation of services, as well as to make the access to such services more convenient for the client.

"The present invention generally relates to a method and system for storing state information relating to shared service programs. A database stores information which preserves the state of a particular operating system service for each client which calls that service. Thus, whenever a client accesses the service, it will be returned to the same state that existed when it last exited that service, even if other clients had accessed the service in the meantime and left it in a different state. The stored information is external to the clients which utilize the services, so that changes to the services can be implemented without affecting the clients.

"In a preferred embodiment of the invention, the state information which is stored for each client-service pair includes as much information as possible which relates to the client's interaction with that service. For example, the state of a file system service might include the directory which was last accessed by the client, together with various parameters that define the user interface for that service, such as the size and location of a dialog window. Additional information along these lines can include position of a scroll button for the window, so that the client is returned to the same position in the directory where it exited the previous time, rather than a default position such as the top of a list.

"The state information is stored under the control of the shared service or the operating system, rather than the application program. The application program need not be modified to provide changes to the state information storing process. The application program, however, can provide context information to affect the storing of the state information indirectly.

"Preferably, the database is accessed by a key. The key includes a caller ID field indicating the application program or other client, a service ID field indicating the shared service program and a caller context ID field which may contain context information provided by the client.

"The caller context ID field in the key allows different states to be stored for different contexts in an application. For example, the same service could be called by the text editing portion of a word processor, and the dictionary portion of the word processor. When the text portion of the word processor calls the service, the user interface will be set up with the state information corresponding to the state of the service which existed the last time the text portion of the word processor called the service. This avoids the annoyance of the user interface showing a directory of dictionary files when one wants to open a text file. The use of the caller context ID field allows two or more different states to be stored; one for each context of the application program.

"In a preferred embodiment of the present invention, the key to the database also has a service context ID field. The service context ID field allows different versions of the shared service program to store different types of state data. A first version of a shared service interface might store the user interface state information in a certain manner. An upgrade to the shared service program can modify the way state information is stored. However, entries to the database may have already been made using the first version of the shared service program. The service context ID allows the upgraded shared service program to determine how the state data is stored in the database; the old way or the new way."

-- Dennis Sellers