JP2001042987A - Form shortcut for application program of small foot print device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable entry into a form displayed by an application program executed on a small foot print device by displaying a list wherein an input character string can be selected in response to the operation of a user interface control and arranging the character string that a user selects in an input field. SOLUTION: The application program displays an input field for making a user to perform input or requesting the input (S610). For example, a web browser displays an input field of the HTML form. The user operates a user interface control (S612). In response to the operation by the user, the system displays a list of input character strings which are generated in advance. The user selects a character string from the displayed list (S614). The application program inserts the selected character string into a proper input field (S616).

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates generally to computer application programs and small footprint devices. More specifically, the present invention relates to a form displayed in an application program running on the small footprint device, for example, H displayed in a web browser program.
Includes systems and methods for filling out TML forms.

[0002]

The field of "high performance" small footprint devices is growing and changing rapidly. Small footprint devices include handheld computers, personal digital assistants (PDAs), mobile phones, global positioning system (GPS) receivers, game consoles, and many more such devices. These devices are becoming more intelligent and interconnected. Sun Microsystem
ms Jini ^™ and other technologies and OpenServ
ice Gateway Initiative (OS
Initiatives such as GI) extend the traditional concept of computer networks to include small footprint devices.

[0003] This increase in device interconnects has created a need for new ways of integrating computing services with new types of computing services and inter-device and intra-device based services. A "service" is an entity implemented within or accessible to a device that can be used by a person, application, or another service. The concept of services is broad and can be considered on a number of different scales. For example, services include well-known network-based services such as shared printing, e-mail, telephony, and the like. Services include energy management services that can control the power consumption of devices in the local network, diagnostic services that allow devices to send information to service technicians when an error occurs, and health professionals. There are also lesser known examples, such as health monitoring services that provide immediate notification of an emergency.

[0004] Services also include executable modules or applications located within a local machine or device. For example, a local application program uses a service to
It can communicate with TP servers, HTML render engine services, bookmark services, user interface services, and the like. In this example, an application program can use these services together to implement a web browser program.

[0005] Today, it is becoming more common to run many services and applications together on a single small footprint device. However, as memory, processing power and other resources are typically very limited on small footprint devices, a dedicated lightweight service / application containment framework achieves the desired service and application integration It is necessary for Containment
The framework is designed for any kind of small footprint
It is also desirable to be flexible and extensible enough to provide a framework for any type of service and application for the device. A further goal is that the containment framework
It may be to be compatible and integrated with off-device services, such as services available to devices in an ^iTM network. The containment framework described herein achieves the goals described above.

[0006] Lightweight containment frameworks are small footprint devices, such as personal digital assistants, high performance mobile phones, that can execute multipurpose application programs of the type traditionally associated with desktop computing environments. it can. For example, Su
Per available from Microsystems
The Sonal Applications suit is built around one embodiment of the containment framework. Personal Application
ns suit is Personal Applicati
ons Browser, Personal Appl
ications Email Client and P
Includes an integrated set of compact, memory-efficient applications, such as the personal Organizer.

[0007]

SUMMARY OF THE INVENTION A web browser, e-mail and web browser running on a small footprint device
Users of application programs, such as clients, often encounter problems not related to these same programs on other computer systems, such as desktop computers. For example, the display features of a typical small footprint device may be small compared to the display monitor of a desktop computer system, thereby causing problems when trying to display documents such as web pages. Sometimes.

Another problem often encountered with small footprint devices is related to program entry. For example,
Many small footprint devices do not have a convenient full-featured character input system such as a keyboard.
There are various approaches that can be taken to provide a solution to this problem. One way is to provide special input hardware that is attached to a small footprint device that allows for a convenient full-featured character input system. However, this approach can be expensive and may not meet the goals of small size and portability of some small footprint devices, such as high-performance mobile phones and personal data assistants.

For commonly used types of inputs, other approaches can be taken to handle program inputs for small footprint devices. SUMMARY OF THE INVENTION The present invention relates to an input solution that allows a user to create and store a set of input strings, so that it is easy to use and uses a small footprint device application program from a small footprint device application program. Through an available user interface, the user can select a program entry from this list of strings. Commonly used inputs are commonly used to fill out forms such as names, addresses, or any other type of input string that the user wishes to create.

[0010]

SUMMARY OF THE INVENTION The present invention includes a solution to the problem of program entry of an application program for a small footprint device. According to the present invention, a user can create and store a list of input strings for later use. As described below, this input list can be generated in various ways. In that case, with an application program running on the small footprint device, the user can select program inputs from this input list. To enable this input selection, the application program must be accessible to the user of the small footprint device.
Interface can be used.

Using various types of application programs that can or can require user input, the user can select from a list of input strings. For example, using a web browser application program, a user can select a string for an input field of an HTML form from a list. In this example, the web browser can place a user interface widget or control next to the HTML form field. This user interface control may be any of various types, such as buttons, pop-up lists, and the like. For example, if the control is a button, the user clicks the button, the web browser can display a list box of strings, and the user can select one of the strings. The web browser can then place the selected string into a form field.

The user interface that allows the user to select an input from an input list can use a variety of forms appropriate to the particular small footprint device or application program. The application / service containment framework running on the small footprint device described below allows applications / services to be built from various modules. For example, the containment framework can be used to implement the user interface of one application in another module. A suitable user interface can then be used for the different small footprint devices. As a result, applications and services running within the containment framework may depend on a suitable user interface module or other type of module implementing the input system described above.

The input system and method can be used for different types of applications and services for different types of inputs. For example, the user can use HTML
An input can be selected from an input list using a web browser to fill out forms or other markup language forms, such as XLM-derived markup languages. Also, the user can select an e-mail address from the input list using an e-mail client, and use the personal organizer to select various types of input, such as name, address, and scheduled tasks, from the input list. .

[0014]

Other objects and advantages of the present invention are:
It will become apparent from a reading of the following detailed description and a review of the accompanying drawings.

FIG. 1—Creating an Input String FIG. 1 shows the process of entering and storing an input string for later use in an application program.
Note that FIG. 1 illustrates one embodiment of a process for creating and storing an input string. Other embodiments are possible in which various steps are added, combined, modified, or omitted.

In step 600 of FIG. 1, a user requests a session for inputting an input character string. For example, the session can be started on a small footprint device running applications and services within a lightweight containment framework. The containment framework can include service modules that manage the creation and storage of input strings used by other modules of the framework. This kind of application /
The service containment framework is described in detail below.

The session launched in step 600 of FIG. 1 can later be launched from a system other than a small footprint device containing an application that uses the input string. For example, a user can launch this session from a desktop computer system that has a more convenient mechanism for entering strings. The list of input strings can later be downloaded to a small footprint device, or the small footprint device can dynamically access the list of input strings via a network or wireless connection.

The session started in step 600 can take various other embodiments besides the above embodiment. For example, the session can be launched in response to some other event other than a user request, for example, as part of an installation procedure. The session launched in step 600 can be launched from within a particular application program or can be associated with a particular application program. Using the session launched in step 600, the user can edit a previously stored input string.

At step 602, the system provides a user interface to a user entering an input string.
This user interface can take various forms appropriate for the particular system. For example, in a desktop computer system, the user interface may be a standard graphical user interface in which windows are presented and the user can enter strings via a keyboard. For small footprint devices, the input mechanism of the device may be more limited. For example, a keyboard may not be present. In such a case, the system presents a list of strings so that the user can select characters using any available input means, such as buttons, trackballs, and the like. The means for inputting the input string may take various other forms suitable or possible for other systems. For example, in one embodiment, the user writes an input string using a touch pen and the system converts it into digital text.

At step 604, the user proceeds to step 60
One or more input character strings are input via the user interface shown in FIG. The user can enter any of the various types of character strings commonly used in forms such as names, addresses, email addresses, credit card numbers, and the like. In one embodiment, these strings can be stored in a secure manner, for example, the strings can be encrypted, or the system can employ other available security measures. In one embodiment, the user may be restricted to entering a limited number of commonly used strings. In other embodiments, the user can enter an unlimited number of strings according to the available memory space. In one embodiment, the user assigns a priority to the string, for example, defining the order in which the string appears in the selection list of the application program,
By defining separate input strings for different applications, the input strings can be classified in various ways.

At step 606, the system stores the input character string entered at step 604 by the user. The string is stored in a format that can be accessed later by the application / service. The string can be stored in the memory of the small footprint device where the input string will be used later. If the input creation session is performed on another system, either download the input list immediately to the small footprint device where it is used, store the list and download it to the small footprint device later, It is possible to dynamically access the input list later from a small footprint device, and so on.

FIG. 2—Input Character String Used in Application Program FIG. 2 shows a process of inputting to an application program or service using an input character string created in advance. Note that FIG. 2 illustrates one embodiment of a process that uses a list of input strings. Other embodiments are possible in which various steps are added, combined, modified, or omitted.

At step 610, the application program displays an input field that prompts the user for input or requires input. This input field can be displayed in any of a variety of types of applications. For example, a web browser can display an HTML form input field, an e-mail client can display a dialog box or screen with an e-mail address input field, and a personal organizer can display a telephone number input field. .

At step 610, the application:
Display a user interface control or widget that allows the user to select a string from pre-created input strings. This user interface control may be any of a variety of types, such as buttons, pop-up lists, etc., appropriate for the particular application or system. For example, the control may be a drop-down list that the user can click to display a list of strings.

The user interface control that activates the list of input strings can have the look and feel and arrangement appropriate for the particular application or system. For example, in one embodiment, the application may place another control beside or near each displayed input field. In another embodiment, the application can display a single user interface control or widget that can be manipulated by the user to select the input string of the currently selected input field.

At step 612, the user operates the user interface controls described above. For example,
The user can touch a particular portion of the display with a touch pen or finger, or use a trackball or arrow keys to position the cursor on the control and press a button. In response to the user's operation, the system displays a list of previously created input strings. The list can be displayed in any of a variety of ways. For example, the list can be displayed in the form of a drop-down list where the user scrolls to select a particular string.

At step 614, the user proceeds to step 61
A character string is selected from the input character string list displayed in step 2.

At step 616, the application program inserts the character string selected at step 614 into an appropriate input field. The application program can easily display the text of the selected string in the input field. The operation of inserting the selected character string involves various other operations appropriate to the particular application.

FIG. 3-HTML Form Quick Cut FIG. 3 shows an HTML form or XML in a web browser using a list of pre-created input strings.
Fig. 7 shows the processing of inputting other markup language forms such as an L-derived markup language form. Note that FIG. 3 illustrates one embodiment of a process for using a list of input strings in a web browser. Other embodiments are possible in which various steps are added, combined, modified, or omitted.

As small footprint devices become more interconnected with other devices and networks, it has become increasingly desirable to enable small footprint devices to execute applications such as web browsers. A lightweight application / service containment framework that enables small footprint devices to run applications such as web browsers is described in detail below. In many cases, it is necessary or desirable to modify the application in a particular way to make the application usable or more convenient in a small footprint device. As mentioned above, one particular problem involves user input. FIG. 3 illustrates one embodiment of the user input solution described herein applicable to form input in a web browser. One embodiment of this user input solution for web form input is called "quick cut".

Forms such as HTML forms are very common on web pages. The following HTML code is an example of an HTML form. <FORM action = "http://somesite.com/prog/adduser" method = "post"><P> First name: <INPUT type = "text" name = "firstname"><BR> Last name: <INPUT type = "text" name = "lastname"><BR> email: <INPUT type = "text" name = "email"><BR><BR><INPUT type = "submit" value = "Send"><INPUT type = "reset"></P></FORM>

FIG. 4 shows the displayed structure of this form. This form has three input fields for the user to enter a first name, last name, and email address. Such forms can be displayed in a web browser program running on a small footprint device. For example, S
un Microsystems Inc. Per
Sonal Applications Browse
r can display such a form.

However, as mentioned above, it would be impossible, inconvenient and time-consuming for a user of a small footprint device to enter text in these input fields. Thus, as shown in FIG. 5, a web browser can place a user interface or widget beside each of the text fields. The user can then operate the user interface controls to select an input string for the corresponding input field. As mentioned above, these user interface controls may be located in other areas. For example, to save display space,
The browser can place a single user interface on the display that can be manipulated to place text in any input field.

When the user operates the user interface controls, the browser can display a list of previously created input strings as described above for FIG. FIG. 6 illustrates one embodiment where a drop-down list pops up near a control operated by a user. The browser can display a stored set of input strings or various subsets of the strings. For example, the browser may display a list of strings that are displayed with a tag in the browser, or “email”
A subset of the string can be displayed based on the label of a particular input field, such as a string that is a valid email address for an input field labeled as. FIG. 7 shows that the user can send an e-mail from the list shown in FIG.
Shows the display after selecting an address and the browser inserting the email address into the input field.

Small Footprint Device Application / Service Containment Framework A modular application / service framework may be necessary to implement the above input solution for small footprint device applications. Applications / services running on small footprint devices can be built from various modules using the containment framework described below. For example, the user interface of one application can be implemented in another module using the containment framework. The appropriate user interface module can then be used for different footprint devices.

FIG. 8-Hardware Architecture Block Diagram FIG. 8 is a block diagram illustrating the hardware architecture of a typical small footprint device. As used herein, a small footprint device is a hardware device that includes computing resources, such as a processor and system memory, but typically includes one or more of these resources. There are limitations that are significantly greater than those of a typical desktop computer. For example, a small footprint device can have less than 2 megabytes of memory, while a typical desktop system can have more than 64 megabytes of memory. Also, a typical small footprint device may be a typical desktop computing device in terms of either processor type and / or processor speed.
It will have significantly less processing power than the system. For example, a personal digital assistant device may have a 16 MHz processor, while a typical desktop system may have a processor speed of 100 MHz or more. Also, typical small footprint devices have a display size that is significantly smaller than the display screen of a desktop computing system. For example, the display screen of a handheld computer is typically smaller than the display screen of a desktop monitor.

It should be noted that the specific numerical values given here are exemplary only and are used for comparison. For example, a personal digital assistant with more than 8 megabytes of memory may still be a small footprint device, but this device has more than the typical number of 2 megabytes of memory mentioned above. .

The small footprint device is constrained by the types of resources other than the memory, processor and display size resources described above, as compared to a typical desktop computing system. There is. For example, a typical small footprint device may not have a hard disk, may not have a network connection, may have an intermittent network connection, or may have a wireless network. Or have a connection.

Many small footprint devices are portable and / or small, as compared to desktop computers, but are not necessarily so. Also,
Many small footprint devices are also primarily or exclusively battery powered. Also, small footprint devices are typically
It may have a more limited or narrower range of possibilities than a computing system. Small footprint devices include, but are not limited to, the following examples. A handheld computer, a wearable device (eg, a wristwatch computer), a personal digital assistant (PDA),
"High-performance" mobile phones, set-top boxes, game consoles, global positioning system (GPS) units, electronic textbook devices, and the like. With the rapid emergence of new classes of consumer devices, it is not possible to provide an exhaustive list of small footprint devices. However, the term "small footprint device" is intended to include devices that can be reasonably included within the spirit and scope of the above term.

FIG. 8 is a block diagram of a typical small footprint device. Note that the small footprint device can have a variety of different architectures as desired. Hardware elements that are not necessary for understanding the operation of the present invention have been omitted for simplicity.

As shown in FIG. 8, the small footprint device includes a processor 100. The processor 100 has x
It can be of any of a variety of types, including 86 processors. For example, the Pentium® class, the PowerPC® processor, and other low power processors, or processors developed specifically for small footprint devices. Processor 100 may have various clock speeds, including clock speeds similar to those found in desktop computer class processors, as well as low speeds, such as 16 MHz.

As shown in FIG. 8, this device is
The memory 102 is included. The system memory 102 stores the RA
Various types of memory can be included, including M or ROM. A typical small footprint device may have a very small memory storage capacity compared to a typical desktop computer system.

The small footprint device can also include one or more input mechanisms. Input mechanism 104
Is shown in FIG. The input mechanism 104 can be any of a variety of types suitable for a particular device. For example, the input mechanism can be a keypad, mouse, trackball, touch pen, microphone, and the like.

The small footprint device can also include one or more display mechanisms. The display 106 is shown in FIG. However, small footprint devices may not include a display, or may include another type of output mechanism, such as audio speakers. Display mechanism 106 can be any of a variety of types appropriate for a particular device. The display mechanism for a typical small footprint device, such as a smart phone, may be small compared to the display of a desktop computer system.

FIG. 9-Hardware / Software Hierarchy Diagram FIG. 9 is a typical hierarchy of hardware / software layers included in a system executing applications and services within the containment framework. This diagram is exemplary, and various layers may be added, combined, or omitted as appropriate for a particular device or implementation.

The base layer in FIG. 9 is the device hardware layer 120, which contains the hardware resources needed to support the software system, such as a processor and system memory. In one embodiment, the hardware of the small footprint device, such as the example small footprint device hardware of FIG. 8, implements the hardware layer 120 of FIG. However, in other embodiments, the hardware layer 120 can be implemented with other types of devices. For example, smart
For example, a device such as a card that has greater resource constraints than a typical small footprint device.

As shown in FIG. 9, the operating system layer 122 is located next to the hardware layer. As is well known to those skilled in the art, an operating system acts as an interface layer between device hardware and software running on the device, and is a manager of low-level tasks such as I / O, memory management, etc. Serve as a function. The operating system 122 of FIG. 9 can be any particular operating system that supports the higher layers of FIG. The operating system 122 may be small and efficient, suitable for use with, or specifically written for, small footprint devices. For example, operating system 122 may be a Sun Microsystem
The operating system can be a JavaOS operating system available from Microsoft Corporation.

In one embodiment, the containment framework is implemented as one or more Java ^™ classes in a Java ^™ application environment.
As shown in FIG. 9, Java ^™ virtual machine layer 124 and J
The ava ^™ application programming interface (API) class library layer 126 is the next upper layer of the operating system. These two
Both layers are Java ^™ application environment or Java
a Create a ^TM platform. A class that implements the containment framework can be built using the Java ^™ library 126 and can be compiled into bytecode. This bytecode is
An instruction to be executed on the Java ^™ virtual machine 124,
Interact with operating system 122 and / or device hardware 120.

In one embodiment, the containment framework is implemented in a PersonalJava Java ^™ application environment. This is a highly scalable, modular and configurable design of the Java
a ^TM platform that requires minimal system resources. PersonalJav
a ^™ is a Java ^™ virtual machine and a Java ^™ AP
Core and optional API, including a subset of I
And class libraries. In addition, Person
nalJava ^™ API is a dedicated version of Java
a ^TM abstract window tooli
Includes specific features required by consumer applications in resource-constrained environments, such as t (AWT). The PersonalJava ^™ AWT library is tuned for the look and feel of consumer products, provides graphics and windowing capabilities, supports low-resolution displays and alternative input devices (for devices without a mouse and keyboard) Via the extended event model).

Referring again to FIG. 9, the containment framework 128 is shown as the next layer above the Java ^™ platform layer. As mentioned above, containment
The framework 128 can be based on other platforms. As described in detail below, the containment framework 128 manages program modules, for example, by allowing module registration, lookup, instance tracking, and the like. Modules can provide various services. Containment framework 128 allows modules to request other modules to use their services. An application can be implemented as a module that uses the services of another module. Thus, the containment framework 128 provides a lightweight and extensible service and application framework, allowing applications to coexist and share a modular code base.

This type of scalable architecture allows multiple program modules to cooperate and is an important development for small footprint devices. Small footprint devices have historically been limited to relatively narrow applications. For example, mobile phones were typically used for telephony and a few other applications. However, as various technologies are developed and small footprint devices become "more sophisticated" and can have general-purpose processors, larger display screens, etc., they are used in small footprint devices It has become desirable to extend the range of applications.

This containment framework is:
Applications and services of the type generally associated with a desktop computing environment may be able to work together on small footprint devices in a manner that desktop computer users are accustomed to. As shown in FIG. 9 and described above, the services and applications 130 running on the small footprint device can be implemented as modules built on the containment framework layer 128. For example, Sun Microsystem
Personal Appli available from ems
The cation suit is constructed using one embodiment of the containment framework 128. Per
The Sonal Application Suite is
It includes an integrated set of applications such as browsers, e-mail clients, and personal organizers.

FIG. 9 also illustrates the ability of some embodiments of the containment framework 128 to integrate off-device services 132 with on-device applications / services 130. For example, the containment framework 128 provides a small footprint
An interface between the device and a network such as a Jini network can be provided. The small footprint device system can register its services for use by other devices or clients in the network. The containment framework may also allow services and applications within the small footprint device to look up and use services provided by other network devices. Integrating the services of a small footprint device with network services is discussed in greater detail below with respect to FIG.

FIG. 10-11: Exemplary Network Devices and Service Federation FIG. 10 is an exemplary network,
Small footprint devices that run applications / services within the framework are connected to a local service based network. In the example shown, a smart phone 134 utilizing the containment framework 144 is connected to the network.
In the figure, a printer 130 and an Internet-enabled television 132 are also connected to the network.
In this example, it is assumed that the printer 130 and television 132 devices are operable to export services to the network and possibly use the services of other devices on the network. For example, a printer can export its print service 138, and Internet TV can look up and use the print service to print web pages. To facilitate federation of devices and services in this manner, a lookup service 136 is located on the network. Lookup service 136 may reside on another device, such as a network server.

Federation of devices and services can be implemented in various ways. For example,
J available from Sun Microsystems
The ini ^™ technology includes components and programming models that enable a distributed system of the type of FIG. In one embodiment, the local network of FIG. 10 can be a Jini ^™ network, and printer 130 and Internet television 132
It can be an ini ^™ enabled device. Each device is operable to find a Jini ^™ network lookup service and register the service provided by the device with the lookup service. The lookup service maps an interface that indicates the functionality provided by the service to a set of objects that implement the service.

A device or other service provider can first find an appropriate lookup service using a "discovery" protocol to add that service to service federation. FIG.
1 is a discovery process. As shown,
Provider 164, for example, printer 130 of FIG.
Can broadcast a request on the local network to make the lookup service identify itself.

After the service provider 164 has located the lookup service 160, the service provider 164 can register the service with the lookup service 160 using a “join” protocol. FIG. 12 shows the joining process. service·
Provider 164 can create a service object that clients can use to invoke the service. As in FIG. 12, the service object of the provided service is then looked up, along with a service attribute or descriptor containing information about the type and name of the provided service, by a lookup service 160.
Can be loaded. For example, in the Jini ^™ network, the printer 130 of FIG.
A service object can be created that includes the Java ^™ programming interface for service 138. The printer 130 then looks up
The "register" method of service 136 can be invoked to pass this service object along with attributes specifying that the service 138 being registered is a print service, print resolution, possible paper size, and the like.

After the service provider 164 combines the service with the lookup service 160, other network clients request the service,
Can be used. The process of requesting a service is called a lookup, and is shown in FIG. After discovering the lookup service, the client 162
The service description can be used to request a service from the lookup service 160. Lookup service 160 attempts to match the description provided by the requester to the service coupled to the lookup service. Lookup service 1
60 may use the service provider 164 during the binding process.
This matching can be performed using the service attributes sent from. If a match is found, lookup service 160 provides the appropriate service object to client 162. For example, a Java ^™ interface for the requested service can be provided to client 162.

After the client 162 receives the service object from the lookup service, the client can invoke the service. FIG.
4 is a process for calling a service. When the service is invoked, the client 162 and the service provider 164 can communicate with each other directly. Any of a variety of interaction protocols can be used for this communication. For example, the protocol used
Java ^™ Remote Method Invoc
(RMI), CORBA, DCOM, etc. The service object that the client receives from the lookup service is, for example, R
By calling the MI method, you can call back to the code located at the service provider, or execute locally to provide the requested service, or combine these approaches. Can be used.

As shown in FIG. 10, the lookup service 136 for the local network can also operate as a gateway to an external network such as the Internet 154. Thus, the service-based distributed computing model can be extended to include clients and services located outside the local network. For example, Open
n ServiceGateway Initiati
ve (OSGI) using technology developed for
This type of distributed computing system can be implemented.

This type of service sharing between different networks and the Internet allows new types of applications to be developed. For example, a merchant can use an Internet service to record data about a particular customer, and an advertising service provider can use this data to determine which local network the consumer device is connected to, etc. , Context-specific advertisements can be placed on consumer devices. For example, a customer may enter a shopping mall and connect a personal digital assistant (PDA) to the shopping mall's local network via a wireless connection.
An Internet-based customer data service can be coupled to a look-up service for a shopping mall network to provide information about a particular customer who has just connected to the mall network. The service operating within the shopping mall network then uses this data, along with other factors such as the customer's current location within the mall, time, etc., to generate personalized advertisements and the customer's PD.
A.

Many other service examples based on the network of FIG. 10 are possible. For example, a network-enabled consumer device in a home can use services provided by a power company to manage power consumption in the home via the Internet, and a security service provider can use a network service. Home or specific devices can be monitored via the service, owners can be notified immediately when assets are compromised, and health service providers can communicate with medical devices to help patients Can be monitored remotely.

In the example given above, devices can transparently connect to the network, integrate network services with device resident services, and export device resident services for use by network clients. Suppose you can. The containment framework described herein is necessary for integrating services and applications of small footprint devices, such as personal digital assistants, handheld computers, and high-performance mobile phones, with network service federation. An interface can be provided.

As shown in FIG. 10 and described in more detail below, the containment framework 144 includes:
It has a lookup service 146 of its own type. The lookup service 146 in the containment framework 144 can operate in a manner similar to the local network lookup service described above, and utilizes a discovery, combining, lookup, and service invocation process. . For example, the personal organizer application 152 can utilize various services such as a calendar service, a contact list service, a bookmark service (not shown). The personal organizer application 152 can obtain references to communicate with these services via the containment framework lookup service 146.

Containment Framework 144
Finds its own lookup service 146 in FIG.
Local network lookup service 1
36 and can be integrated into an off-device lookup service. Thus, off-device services, such as print service 138 and web service 140, can be transferred to the containment framework applications / services 148, 150 and 1
It can be enabled at 52 and vice versa. For example, the personal organizer application 152 may use the print service to include the containment framework lookup service 1
46 can be requested. The containment framework lookup service 146 can first search for an on-device print service. If this is not found, the containment framework lookup service 146 can request a print service from the network lookup service 136. The service object for the print service 138 can then be returned to the personal organizer 152. The interface 142 between on-device services / applications and off-device services is shown in FIG. Details of how to implement on-device / off-device service integration are detailed below.

As mentioned above, a client of a service can itself be a service to other clients. For example, the e-mail client "application" 150 of the smart phone of FIG. For example, if a malfunction occurs, the printer 130 of FIG. 10 may request an e-mail service to enable transmission of diagnostic information to a service technician. If the network lookup service 136 cannot find a network-based email service, the email service can be requested from the smart phone 134 via the interface 142. The service object of the email application / service 150 running on the containment framework 144 can be passed to the requesting printer client 130. In this example, printer client 130 may communicate directly with email application / service 150 to send an email containing diagnostic information to a printer service technician. The e-mail application / service 150 can send the e-mail immediately if it can find the e-mail server service, or later when the mobile phone user connects to a different network. This e-mail can be sent when a new service becomes available.

Although the above description makes reference to particular protocols and programming models, such as Jini ^™ technology, it should be noted that these particular technologies are merely exemplary. For example, applications and services within the containment framework can be integrated with clients, services, devices, networks, etc. that use various types of standards, protocols, and programming models. These standards, protocols, and programming models include:
Jini ^™ , CORBA, COM / DCOM, Blue
tooth, CAL, CEBus, HAVi, Home
API, HomePNA, HomePnP, Home
RF, VESA, etc., but are not limited thereto.

FIG. 15—Containment Framework Block Diagram FIG. 15 is an abstract block diagram illustrating the basic architecture of the containment framework environment. As described above, the containment framework provides a containment system for applications and services. These applications and services are managed in the system as units called modules. The containment framework is lightweight, and in one embodiment, the modules can interact with a single framework manager that performs all module management. This manager is referred to herein as a central framework instance. In one embodiment, the central framework instance is Java
a Can be implemented as an instance of a ^TM class. FIG. 15 shows the central framework instance 17
0, and the code and data it contains / manages. Note that FIG. 15 illustrates one embodiment of the containment framework. Other embodiments may use different architectures and / or be implemented in different programming languages or software environments. For example, the module management / containment performed by central framework instance 170 of FIG. 15 may be performed by multiple objects or components in other embodiments.

As shown in FIG. 15, the central framework instance 170 includes data 182 representing the modules currently loaded in the system. The containment framework architecture is non-hierarchical. Thus, loaded modules can be represented as a flat list or array of modules. This non-hierarchical system helps keep the core containment framework code and the modules running within the framework small. Java
Systems that use hierarchical components, such as the Beans ^™ component, can provide the attendant benefits, but these benefits come from the burden of more complex management systems that require more system resources. Can be However, the containment framework provides a mechanism for non-hierarchical modules to gain many of the benefits of a hierarchical containment system. This mechanism is described below with reference to FIGS.

As shown in FIG. 15, in one embodiment, the central framework instance 170 includes publicly accessible methods 178 that modules can invoke. These methods can be divided into abstract groups. For example, a group of methods 172 may include a lookup method. Lookup methods implement the lookup service functionality described above. The module can pass the module descriptor to the lookup method of the central framework instance 170 to locate a particular service module. The containment framework look-up process is described below with respect to FIG. Another group of framework methods 174 may include methods for loading and unloading modules. After finding the service module, the client module can request the central framework instance 170 to load the service module and return a reference to the loaded module. The client module can then invoke this service. When the client has finished using the service module, it can call a framework method to release the service module. Although described as different groups, dividing methods into lookup and load / unload groups may be only a conceptual division. For example, in one embodiment, a lookup method may load a matching module and return a reference to the matching module.

FIG. 15 also shows system data 180 called framework metadata. This can include data 182 describing the list of loaded modules and other data describing the state of the system. Methods 176 of another abstract group of the central framework instance 170 include reflection and
Methods can be included. Reflection methods are slightly different from other groups of methods because they provide direct access to core metadata 180.
A special class of modules, called system modules, can invoke reflection methods to gain access to metadata 180. Regular modules cannot access the metadata 180.

After receiving a reference to core system data 180, the system module may use or modify the data in any desired manner. Thus, the containment framework is significantly extensible. The central framework instance 170 can keep itself small and can add system modules to implement functionality not yet enabled by the central framework instance 170. For example, a system module may enable integration between applications / services operating within the containment framework and services based on external networks, as described above with respect to FIGS.

In this example, such a system module can be written as a second lookup service according to the protocol and programming model of the external network. For example, in a Jini ^™ network, a system module can be written that discovers the Jini ^™ network lookup service, combines the network lookup service, and registers itself as a second lookup service. . When a network client requests a service, the network lookup service can invoke the lookup service implemented by the system module. The system module can attempt to find a service module in the containment framework that matches the description of the requested service. If a match is found, the system module can perform the necessary steps to export this service module to the network client. this is,
This is because the system module has full access to the system module list and metadata. For example, the system module loads and registers the matched service module into the system,
An interface to the newly loaded module, such as the ava ^™ interface, can be returned to the requestor.

FIGS. 16 and 17-Simulating a Hierarchical Environment It is often desirable to establish a hierarchical context for a module. For example, several service modules of the same type may exist in the system, but each may exhibit slightly different behavior. In a hierarchical containment system, requests for services by a module can be filtered through the parent or containing module of the requesting module, allowing a reference to a particular service module to be returned to the requestor. . Hierarchical containment
It also has other inherent advantages. For example, the ability to easily distribute and store data across a hierarchy of modules. However, as noted above, a complete implementation of a hierarchical containment system can be very expensive in terms of required system resources, such as memory and processing power. Containment frameworks can provide developers and applications with mechanisms that provide many of the benefits of hierarchical containment, but typically do not have the high overhead involved.

For example, in one embodiment,
The framework allows a module to register itself as a module request listener for other modules. For example, module A may register itself as a request listener for module B. This is done, for example, by calling the AddRequestListener method of the central framework instance. Subsequently, when module B invokes a method of the central framework instance to find a particular service, the central framework instance checks for module B's module request listener. In this case, the central framework instance finds module A as a request listener and asks module A to provide the requested service module to module B.

FIG. 16 and FIG.
5 is an exemplary use of a module request listener in a framework. FIG. 16 is a desired conceptual module hierarchy of the print service. As shown, two print service modules 192 and 194, print service A and print service B, are encapsulated within print manager module 190. For example, two print services 19
2 and 194 can be printed in different locations,
It can have different resolution and color capabilities, etc.
Either of these print service modules can satisfy a print service lookup request by another module. However, a print manager that selects and returns a particular print service
It may be desirable to use modules. For example, print manager 190 may select a print service based on which client module makes a print request, or print manager may enter desired print service characteristics for a user. You can display a dialog box asking you to

Although the containment framework utilizes a non-hierarchical containment model, the hierarchy of FIG. 16 can be implemented. This is done by registering the print manager module 190 as a module request listener for a client module that can request print services. FIG.
Example module 198 that can operate within the system
It is. As mentioned earlier, these modules can themselves use other modules as services. According to the non-hierarchical model of the containment framework, the modules are shown arranged in a single-layer layout without using a specific module hierarchy.

In this example, web browser module 196 may be operable to make a print request, for example, to print a web page. As shown in FIG. 17, the print manager module 190 can be registered as a module request listener of the web browser module 196. Upon receiving a print service request from the web browser 196, the containment framework lookup service causes the web browser module 196
Print manager registered as a request listener for
The module 190 can be found and the print manager module 190 can be requested to provide the print service module to the web browser requestor 196. Then print
The manager module 190 can return a reference to the print service module A 192 or the print service module B 194, or
The print manager module 190 can present a dialog box to the user to determine which print service module to return. Thus, the desired module hierarchy of FIG. 16 can be implemented for non-hierarchical modules of the containment framework.

FIG. 18—Parcel Packaging Unit Modules can be packaged into units called parcels. This packaging serves several purposes. For example, parcels provide a convenient mechanism for managing related code and data as units. If closely related modules have static dependencies, they can be packaged together in a parcel. Parcels can be used to handle installations and upgrades in the system.

FIG. 18 shows a personal information manager (PIM).
Parcel example 2 of grouping modules together
00. In this figure, the calendar module 20
2, a contact list module 204, an appointment module 208, and a user interface module 206. Various other modules can be present in the parcel as desired. The modules of the PIM parcel 200 are used for contention services such as bookmark services and search services.
Various core service modules operating within the framework may also be used. The use of a PIM parcel can simplify the installation and upgrade of a PIM application. P
Packaging an IM module in a parcel in this way also has the advantage of development time in creating separate code units for versatile development.

Parcels also provide additional ways to provide runtime context for non-hierarchical modules. When a module is loaded into the system, the central framework instance can store metadata specifying which parcel the module belongs to, if any. The service module will later use this information for different client modules.
Services can be provided in different ways depending on the parcel to which the client belongs. For example, a client module can use a file access service module to obtain a root directory. The file access module may return different root directories to different clients depending on the parcel to which the client belongs.

FIG. 19—Module Request Flowchart FIG. 19 is a flowchart illustrating an exemplary lookup process in which the central framework instance issues a lookup request to the service module from the client module. Can be performed when received. Note that FIG. 19 is exemplary, and that the various steps may be combined, omitted, or modified. For example, as described above, a system module that customizes the lookup process can be added.

At step 300 of FIG. 19, the central framework instance receives a module lookup request from the requesting module. For example, the requesting module may specify that the central framework instance Re
The requestModule method can be invoked to pass the module descriptor of the service module being requested, as well as a reference to the requesting module itself. A reference to the requesting module can be added to the system data to keep track of the service module user. As described in more detail below, this module can be unloaded when no other module is using the module.

The module descriptor passed by the requesting module specifies various attributes for the requested module, and the framework instance can use this attribute to attempt to find a matching module. . This module descriptor can be an object that contains information such as the requested module's service type, class name, and / or service-specific attributes. The requestor can also pass the text description to the central framework instance, which can use this description to create a module descriptor object.

At step 302, the central framework
The instance checks whether the request listener module is registered for the request module. If a request listener is found, at step 304, the framework instance notifies the request listener of the request and instructs the request listener to attempt to provide a module that matches the module request descriptor.
If the request listener is able to provide a matching module, execution proceeds to step 314. Otherwise, other registered request listeners can be asked to provide the module until a match is found or there are no more request listeners.

If no request listener was found, or if none of the request listeners could provide the requested module, execution proceeds to step 306. However, in one embodiment, execution may stop after step 304 if one or more request listeners are registered for the request module, none of which could provide a matching module. At step 306, the central framework instance examines the list of modules to determine if one of the modules matches the module descriptor. If a match is found, at step 308, the framework instance checks whether the matched module is multi-instantiable. Otherwise, execution proceeds to step 314.

If step 308 finds that the matched module is multi-instantiable, the central framework instance can continue to search the module list for a match. If there are no more modules to search, execution proceeds to step 310. At step 310, the framework instance searches for a module provider module in the module list. The module providing module is a module that can provide the requested module. For example, a network lookup service can be imported as a module provider module for the containment framework.

If a module providing module is found, at step 312 the central framework instance notifies the module providing module of the request,
Directs an attempt to provide a module that matches the module request descriptor. If a match is found, execution proceeds to step 314. If the module provider fails to provide the requested module, the central framework instance may search for another module provider module and repeat step 312. If the module provider is not in the module list, or if none of the requested modules can be provided, the requester is notified that this request cannot be satisfied and execution is complete.

Step 314 includes steps 304 and 3
08 or 312. In all cases, a module matching the module request descriptor is found. In step 314, the requester is registered as a user of the matching module, and
At 6, a reference to the matched module is returned to the requestor. Any necessary initialization steps involved in loading and initializing the matched module are included in step 314.
Executed in For example, the module may be initialized when the module is loaded.
Can have methods.

As mentioned above, the flowchart of FIG. 19 is exemplary, and various embodiments may have different look-up / load scenarios. For example, a module may call a central framework method to load a service module without returning a reference to the matched module, or may ignore the request listener in some cases.

FIG. 20—Module Release Flowchart When the client module has finished using the service module, the client returns to the central framework module.
You can release this module by calling an instance method. FIG. 20 is a flowchart showing the module release process. The flowchart of FIG. 20 is exemplary, and various steps may be combined, omitted, added, or modified as needed or desired for different embodiments.

At step 330, the central framework
The instance receives a module release notification from the user module. As described above with reference to FIG.
When a user module requests a service module, the user module is added to the list of users of the service module. At step 332, the central framework instance deletes the user module to be released from the list of users of the module to be released. At step 334, the framework instance determines whether another user module is using the released module. This determination is made, for example, by checking whether another module is present in the user module list of the release module. If so, execution stops.

If no other module is using the released module, the central framework instance can attempt to unload the released module. In step 336, the framework
The instance is the CanFin of the module to be released
You can call the align method. CanF
The initialize method returns true if this module can be unloaded; otherwise, fa
Returns 1se. In step 336, the CanFinali
If the ze method returns false, execution stops. Otherwise, the Fina of the module to be released
The raise method can be called. Final
The size method can perform any steps required to unload the module, such as releasing resources. This module can then be unloaded, which can include garbage collection, etc., depending on the particular embodiment.

Although the invention has been described in conjunction with specific embodiments, it is not intended to be limited to the specific form set forth herein, but rather, that the invention be defined by the appended claims. It is intended to cover alternatives, modifications and equivalents as may be reasonably included within the spirit and scope of the invention.

[Brief description of the drawings]

FIG. 1 is a flowchart illustrating a process of inputting and storing a list of input character strings for later use.

FIG. 2 is a flow diagram illustrating a process for providing input to an application program or service using a list of input strings created in advance.

FIG. 3 is a flowchart illustrating a process for providing input to an HTML or XLM form in a web browser using a pre-created list of input strings.

FIG. 4 is a diagram showing a normal HTML form including an input field.

FIG. 5 illustrates the HTML form of FIG. 4 with additional user interface controls that allow a user to select an input string for an input field.

FIG. 6 shows a user for an input field corresponding to the user.
FIG. 6 is a diagram illustrating a drop-down list displayed when operating an interface control.

FIG. 7 shows the HTML form of FIG. 5 after the user has selected an input string for a field.

FIG. 8 is a block diagram illustrating the hardware architecture of a typical small footprint device.

FIG. 9 illustrates a typical hierarchy of hardware / software layers included in a system executing applications and services within the containment framework.

FIG. 10 illustrates an exemplary network in which small footprint devices executing applications / services within the containment framework are connected to a local service based network.

FIG. 11 is a diagram illustrating a search process in which a service provider searches for a lookup service.

FIG. 12 is a diagram illustrating a joining process in which a service provider registers the service with a lookup service.

FIG. 13 is a diagram illustrating a lookup process in which a client requests a service from a lookup service.

FIG. 14 is a diagram illustrating a service activation process in which a client activates a service using a service object received from a lookup service.

FIG. 15 is a block diagram showing the basic architecture of the containment framework.

FIG. 16 illustrates the use of a module request listener in a containment framework to simulate a hierarchical containment environment.

FIG. 17 illustrates the use of a module request listener in a containment framework to simulate a hierarchical containment environment.

FIG. 18 illustrates the use of parcels to group modules.

FIG. 19 illustrates a normal lookup process that can be performed when a central framework instance receives a service module lookup request from a client module.

FIG. 20 is a flowchart showing module release processing.

[Explanation of symbols]

REFERENCE SIGNS LIST 100 processor 102 memory 104 input mechanism 106 display 120 hardware 122 operating system 124 Java virtual machine 126 Java API class library 128 containment framework 130 on-device application / service 130 printer 132 internet television 132 off-device Services 134 "High Performance" Cell Phones 136 Lookup Services 140 Web Services 142 Containment Framework Interface 144 Containment Framework 146 Lookup Services 148 Web Browser 150 Email Client 152 Personal Organizer 154 Internet 160 Look Top service 162 Client 164 Service provider 190 Print manager 190 Print manager 192 Print service A 192 Print service A 194 Print service B 196 Web browser 198 Application / service module 200 Personal information manager parcel 202 Calendar module 204 Contact list module 206 User interface module 208 Appointment module

────────────────────────────────────────────────── ───

[Procedure amendment]

[Submission date] August 14, 2000 (2000.8.1)
4)

[Procedure amendment 1]

[Document name to be amended] Drawing

[Correction target item name] All figures

[Correction method] Change

[Correction contents]

FIG.

FIG. 2

FIG. 3

FIG. 4

FIG. 5

FIG. 16

FIG. 6

FIG. 7

FIG. 8

FIG. 9

FIG. 10

FIG. 11

FIG.

FIG. 13

FIG. 14

FIG.

FIG.

FIG.

FIG.

FIG.

 ────────────────────────────────────────────────── ─── Continuation of the front page (71) Applicant 591064003 901 SAN ANTONIO ROAD PALO ALTO, CA 94303, US A. (72) The Inventor John Chriswick Canada 1K 5J3 Ontario Ottawa St Andrew Street 153

Claims (9)

[Claims] 1. A method for inputting text into an input field of a computer program running on a small footprint device, comprising the steps of: creating a list of input strings by a user; Storing a user interface control near the input field by the computer program, wherein the computer program causes an input character string in response to a user operation of the user interface control by the computer program. A selectable list is displayed, the selectable list includes the list of input strings, a user selects a character string from the selectable list, and the computer program selects the character string. The character string is How to be placed in the field. 2. The method of claim 1, wherein the user creates the list of input strings using a computer program separate from the computer program of claim 1. 3. The method of claim 1, wherein the computer program is operable to display a web page, and wherein the input field is a markup language form input field. 4. The markup language is an HTM.
4. The method of claim 3, wherein L is L. 5. A markup language form comprising a user requesting the computer program to display a web page, the web page comprising a markup language form input field. The computer program locating a user interface control near the input field, the computer program analyzing the web page and detecting an input field of the markup language form. The computer program adding the user interface control to the web page beside an input field of the markup language form; Displaying the web page with the user interface control to which a ram has been added. 6. The markup language is an HTM.
The method of claim 5, wherein L is L. 7. The method according to claim 1, wherein the user is the user interface user.
The method of claim 1 wherein manipulating controls comprises a user clicking on the user interface control. 8. A system for inputting an input character string into an input field of a program executed on a small footprint device, comprising: a small footprint device including a processor and a system memory; A software execution environment stored in the software execution environment, wherein the software framework executes in the software execution environment and the software framework supports program modules executable to perform computer services. And the first built on the software framework
A first program module that allows a user to create and store a list of input strings, and a second program module built on the software framework.
A program interface for operating the second program module to display a user interface to a user of the small footprint device, the user interface including an input field, the user interface comprising: Further includes a user interface control near the input field, wherein the user interface control is responsive to a user operation of the user interface control.
A second program module capable of operating a control to display a selectable list including said list of input strings. 9. The small footprint device is a small footprint device belonging to the group consisting of a personal data assistant (PDA), a cellular phone, and a global satellite positioning system (GPS) receiver. 9. The system according to 8.