WO2004092979A2

WO2004092979A2 - Assisted text entry

Info

Publication number: WO2004092979A2
Application number: PCT/US2004/011126
Authority: WO
Inventors: Adam Berger; Richard Romero
Original assignee: Nokia, Inc.
Priority date: 2003-04-11
Filing date: 2004-04-09
Publication date: 2004-10-28
Also published as: WO2004092979A3

Abstract

A communication being sent through a communication network from a source to a user process is intercepted, the communication including a text field to be filled in by a user. Text for filling in the text field is provided based on pre-stored information, and the communication and the fill text are delivered to the user process.

Description

ASSISTED TEXT ENTRY

BACKGROUND

This description relates to assisted text entry.

Manual text entry on many Internet-enabled mobile devices is cumbersome and frustrating because the devices are too small to accommodate full-size QWERTY keyboards. Mobile phones, for example, typically offer only a Bell-style (9-key) keypad. The keypad is suitable for typing phone numbers but less so for entering text, because each of the numeric keys is ambiguously associated with more than one of the letters of the alphabet. The ambiguity must be overcome to enter a series of intended letters. One technique for manually overcoming the ambiguity is to require a user to tap multiple times on a single key to represent a letter.

Other techniques have been used to eliminate the ambiguity while reducing the number of keystrokes required of the user. The "T9" algorithm (see United States patents 6,307,549, 6,392,640, 6,307,548, 6,286,064, 6,011,554, and 5,818,437) predicts the intended completion of a partially typed word when a numeric key is pressed, using one or more of the previously-typed letters, the system's built-in knowledge of common words, a model of letter cooccurrence statistics, and the words the user typed in previous sessions.

For example, if, after entering the letter Q, the user types the '8' key, which indicates T, U, or V, an English-based predictive text input system would select 'TJ.' Using the T9 algorithm, typing the message "Text input is easy" on a Bell keypad (211) requires only 18 keystrokes instead of the conventional

35. Other predictive text entry schemes (see United States patents 6,223,059, 6,392,640, 6,219,731, and 6,370,518) have also been proposed.

Although predictive text entry systems can mitigate the burden of user input on Bell keypads, the T9 and similar algorithms do not lessen that burden on other input devices, for example, on the handwriting recognition unit on

PocketPC units, the "Graffiti" system used in PalmOS devices, and miniature QWERTY keyboards like those used in RTM Blackberry and Treo Handspring devices.

In addition to software-based predictive input techniques, hardware-based man-machine interfaces, such as speech recognition, projected or "virtual" keyboards, and wearable keyboards (e.g. gloves with sensors), would allow for easier text input when a keyboard is not present (e.g., in some mobile phones or PDAs) or practical (e.g., in dashboard-mounted systems).

Typical Internet-enabled mobile devices-mobile phones, PDAs, wireless wrist watches, portable organizers, and dashboard-mounted terminals, for example-can communicate with remote servers (e.g. web, mail, and application servers) via wireless communication protocols such as GRPS, CDMA, 802.1 lb, and Bluetooth. The form factors of such mobile devices are diverse and this diversity is predicted to increase. They also tend to be less capable than personal computers. A typical mobile device has a screen of just a few square inches, communicates with the Internet using slow and unreliable network connections (even the most recently-introduced 3G networks are still markedly slower than typical wireline networks, which carry at least lOMB/s), handles only a small set of document and file formats, and has minimal persistent storage capacity. Compared with a traditional PC, a mobile device typically comes with only a narrow set of applications. Few mobile phones, for instance, are equipped with software required to render a Microsoft PowerPoint file or a document in Adobe PDF format. One application common to almost all Internet-enabled devices is an HTTP application (sometimes called a web browser or a user agent). Even within this common thread there are differences: some mobile web browsers can render HTML, while others are limited to XHTML or WML.

As shown in figure 1, as users of Internet-enabled mobile devices access information on the Internet, they often encounter web pages that contain one or more text entry boxes (10, 12, 14). Filling out these text fields may be tedious. As shown in figure 1, a text entry box may be part of a form 16 that is embedded in an HTML web page 18 served from a popular e-commerce site.

As shown in figure 2, some PC-based browsers (e.g., Microsoft Internet Explorer, 30) offer an "auto-complete" feature that stores previously filled-in text fields. When a user returns to the form again, the browser prompts the user with the previously-typed entries. Next to the text entry field 32 called "Please enter your Member ID," the user typed an ^ch' 34, and the browser displayed a list of suggested entries 36 that begin with the 'h' previously typed into this field. There also exist more sophisticated mechanisms for avoiding text entry on PCs. The Gator Corporation's (www.gator.com) eWallet is a plug-in component to PC-based web browsers that remembers form information for the purpose of pre-filling web forms that are being displayed within the web browser window. Mozilla can store a user's name, address, phone number, credit card, and other personal information and pre- fill this information into any web form which prompts for it. When an algorithm suggests the wrong word to be filled into a text field, the user clears the algorithmically filled-in entry, usually by pressing a 'clear' or 'back' button, and then types the intended value.

These conveniences are generally not available on Internet-enabled mobile devices. Browsers on smaller devices do not generally support auto- completion, either to keep the complexity of the browser application low or because the graphical user interface capabilities offered by the operating system of such devices offer no way to the browsers to prompt the user with a menu of suggested text entries.

Some of the limitations of a mobile device can be mitigated by a mediating network element, which we will call a "proxy," situated between the mobile device and the rest of the Internet. One can think of the proxy as a high- capacity remote appendage to the mobile device, handling storage and document rendering on behalf of the mobile device.

The proxy may provide functions on behalf of a mobile Internet-enabled device, including converting a file from its original format (e.g. Adobe PDF) to a format compatible with the target device (e.g. WML), resizing images embedded inside documents so the images fit the display of the target device, and abbreviating words and phrases for a target device's small screen to maximize the density of information on the display.

Although a proxy can operate at many possible levels (e.g. on TCP or even IP packets), implementing a proxy on top of the HTTP protocol provides several advantages. The proxy has access to entire documents at the application layer (OSI level 7) which allows for higher-order operations that require the entire document, such as rearranging the document so that the main content appears first. Implementations of an HTTP-based proxy include an application server (e.g., BEA's WebLogic) or a web server coupled with a Java servlet engine (e.g., Apache or JServ).

Some web browsers — articularly PC-based browsers like Microsoft Internet Explorer — may be configured to route all communication through an external web proxy. In this case, we say that the web browser and the proxy are

"tightly coupled." The web browser redirects all GET requests to the proxy. The proxy fetches the web resource on behalf of the browser, and serves the document to the browser, performing some computation (caching, processing the document, etc.) in the process. When the user selects a link from the delivered web page, that request is also routed (as are all requests) through the proxy.

Tightly-coupled web proxies have been used with PCs for many different purposes. Some Web proxies like the Squid Project (www.squid-cache.org) improve caching, thereby reducing access latency, across a population of Internet users with overlapping document access patterns. Proxies like Anonymizer (www.anonymizer.com) shield a user's personal information from a web server by introducing a mediating layer which effectively "masks" the user's identity from the origin web server. Proxies like Rabbit (http://rabbit-proxy.sourceforge.net/) increase the effective bandwidth between the web client and server by compressing the web content before the client receives it.

If the browser does not support this type of tightly-coupled proxy configuration, the proxy and web browser may instead be configured as "loosely coupled." In the loosely coupled case, the user of the browser must explicitly key in the URL of the proxy each time a web session begins. The user may also store this URL as a bookmark in his browser, when the browser supports persistently-stored URLs. After the user indicates a request for the proxy URL, the browser issues a GET request to the proxy, and the proxy responds by serving to the browser a web page containing a menu of options, one of which is "visit URL." The user types the URL he wishes to visit into this form. The browser submits the form to the proxy. The proxy fetches the URL, transforms the web page, performs some (optional) computation, and serves the transformed web page to the browser. The transformation step must include prepending the URL for the proxy onto each URL embedded in the document. Without this prepending step, when the user selected a link from the served web page, the GET request would not be routed to the proxy, but instead would be routed directly to the URL in the hyperlink.

This invention applies to both loosely- and tightly-coupled web proxies. A distinction between these configurations will not henceforth be made unless necessary. Note that most mobile browsers deployed today do not support tightly-coupled proxies .

To summarize, some duties that a web proxy handles with respect to an incoming request include (a) copying into a newly-formed HTTP request all HTTP headers from the user device's HTTP request, (b) sending the new HTTP request to the remote web server, (c) receiving the file from remote web server, and (d) modifying all URLs within the received HTML file so that they point to the proxy. The rewritten HTTP attribute pairs include <img src="URL"> and <a href="URL"> and <form action="URL">. In this way, the subsequent requests from the user device are re-directed to the proxy.

The proxy also adjusts HTTP cookies to ensure the user device and the web server can exchange them. The proxy resets the cookie's domain and path when the remote web server returns them. For mobile data access, a web proxy can provide a variety of benefits:

The effective bandwidth of communication to the user device can be increased by arranging for the proxy to trim unnecessary information from the original document received from the server before transmitting it to the mobile device over its relatively slower connection. As mentioned earlier, the proxy could resize large images in the document to fit the display or abbreviate text to increase the density of information on the small screen. The proxy also could remove from the document embedded comments and invisible revision- history information. As much as a 100:1 compression factor maybe achievable.

Document incompatibilities may also be handled. Using a proxy server, a mobile device user can access a file that has a format incompatible with his device. The proxy will fetch the requested file from the origin server, convert it to a compatible format, then transmit it back to the mobile device.

The proxy has no memory constraints and can be as powerful as budget and technology permit. It is in fact possible to deploy a cluster of machines operating in parallel as a single proxy. A proxy with a large memory capacity could partition documents that exceed the mobile device's memory capacity in order to compensate for the device's memory limitations. The proxy would deliver the first segment to the mobile device, while it caches the other segments until the user requests them.

The proxy may automatically reformat the requested document so that the user may conveniently access and view it on a mobile device's small screen. The proxy could parse the document, discover the location of its 'main content,' and reorder it with the main content first. Some of these techniques are described in more detail in United States patent applications and patents numbers 09/745,290, filed December 20, 2000, 60/238,424, filed October 10, 2000, 60/235,557, filed September 27, 2000, 09/745,289, filed December 20, 2000, and 09/851,404, filed May 8, 2001, which are incorporated here by reference.

SUMMARY

In general, in one aspect, the invention features a method that includes intercepting a communication being sent through a communication network from a source to a user process, the communication including a text field to be filled in by a user, providing text for filling in the text field based on pre- stored information, and delivering the communication and the fill text to the user process.

Implementations of the invention may include one or more of the following features. The fill text is provided at a location on the network different from the location of the user process. The text field is filled with the fill text before being delivered. The communication comprises a file, e.g., a mark-up language page, and the user process comprises a browser. The text field is part of a form. The pre-stored information is associated with the user process. The pre-stored information is associated with a type of information that is to be entered into the text field. The fill text is not determined based on the source of the communication. The pre-stored information is associated with a source of the communication. The source comprises a web page.

The pre-stored information is stored in a repository, e.g., in a database. The database comprises entries each of which associates a key related to a text field of a communication with a text entry for the text field. The key comprises a user id and a form field label. The key also includes a domain identifier and a form identifier. Encryption is used to protect the pre-stored information.

The pre-stored information is associated with a user of the user process. The pre-stored information is derived from the user, e.g., by the user entering the information into a text field of a communication. The entered information is derived from the communication as the communication is being delivered. The entered information is cached at the device running the user process and the pre-stored information is derived from the entered information at a time after the communication is delivered from the device. The information is entered by the user in text fields of communications sent to the user process. The fill text comprises identifying information about a user of the user process.

The providing of fill text is performed by a proxy server. The proxy server also provides other services for the user with respect to the communication. The pre-stored information is held in a database associated with the proxy server. The user process runs on a wireless device. The user process runs on a hand-held device. The communication is delivered using an HTTP protocol. The communication comprises an electronic message. The pre-stored information includes a body of fill texts. The body of fill texts includes fill texts for different fields. The body of fill texts includes fill texts for different users of user processes. At least some of the text fills are grouped and encryption is applied to the group. There are multiple alternative fill texts for a given text field and a choice among the alternative fill texts is provided to the user.

In general, in another aspect, the invention features, a method that includes (a) pre-storing, at a proxy server, fill texts associated with different users of handheld or wireless devices; intercepting web pages that are being served to the users; (b) for each of the web pages, identifying the users to whom they are being served and text fields to be completed in forms included in the web pages; (c) for at least some of the text fields and some of the users, identifying ones of the pre-stored fill texts; (d) filling the text fields using the identified fill texts; and (e) delivering the web pages with the filled text fields to the handheld or wireless devices of the users.

In general, in another aspect, the invention features a medium bearing a data structure capable of configuring a machine to enable a using process to identify fill text to be inserted into text fields in a communication, the data structure comprising fill text entries and information associated with each of the fill text entries, the associated information sufficient to identify text fields for which the respective fill entries are suitable. In some implementations the data structure comprises a database and the associated information comprises keys of the database. The fill text entries may comprise text strings associated with user processes.

In general, in another aspect the invention features a method that includes (a) intercepting a communication sent from a user process, (b) identifying text fills included in text fields of the communication by the user process, and (c) storing each of the text fills and associated information about the context of the text fields in which the text fills are included, the context and the text fills being stored in a form that enables use of the text fills for filling text fields in other communications based on the contexts of the other communications.

Implementations of the invention may include one or more of the following features. The contexts comprise the identities of at least one of the fields, the user process, and the communications. The contexts are stored in a database and keys of the database are based on the contexts.

In general, in another aspect, the invention features a method comprising enabling a user to enter, on a user device, text fills for text fields of communications, storing the text fills at a device separate from the user device, and enabling a user to manage, from the user device, the text fills stored on the separate device.

In general, in another aspect, the invention features, a method comprising initializing a repository of text fills for text fields by downloading text fills from a device of a user, the text fills from the user device having been generated by an assisted text entry process running on the user device.

Implementations of the invention may include one or more of the following features. The repository of text fills for text fields is initialized from more than one user device of the user. The repository text fills are updated based on text fills entered by the user on the user device following the initializing.

In general, in another aspect, the invention features a system that includes a proxy containing a set of text fill entries and running a process to use selected ones of the fill entries to complete text fields of communications directed from a source to a user process running on a user device, and a user device running a user process to receive and send the communications to and from the source.

In general, in another aspect, the invention features a proxy server that includes a repository of text fill entries associated with a user of a device served by the proxy server, and a proxy process to complete text fields of communications passing from a source through the proxy to the device, using text fill entries that are associated with the user and are suitable for the text fields.

Other advantages and features will become apparent from the following description and from the claims.

DESCRIPTION

Figure 1 shows handheld devices.

Figures 2 and 9 show web pages.

Figure 3 is a block diagram of a system to assist text entry.

Figures 4, 5, and 7 are flow charts.

Figure 6 shows a handheld device.

Figure 8 shows an uploading process.

If an agent could guess what a user is likely to type into an input text field of a form and speculatively— before the page is delivered to the user— pre-fill the text field with that value, the user would be spared the effort of entering the text on the mobile device. The user would only need to indicate (e.g., by selecting the 'submit' button of the form) that the form is finished. The user could hit the 'clear' or 'backspace' key on the device to erase an incorrectly pre-filled text entry. Although no algorithm could always correctly predict what a user might wish to type into a given text field, if the accuracy were sufficiently high, then the user could be spared, in the aggregate, a significant number of keystrokes. As shown in figure 3, such an agent can be provided in the form of a (loosely- or tightly-coupled) proxy 40 that operates as an intermediary on behalf of a mobile Internet-enabled device 42, fetching web and email content 44 on behalf of the device. The proxy stores (in a database 46) form entries 47 that are typed, e.g., into a field 45 of a form 49, and submitted by the mobile device user. On subsequent accesses by the same user to that same or similar forms 51, the proxy pre-fϊlls the text entry fields 53 on the form using the previously-typed values. The result is a substantial aggregate reduction in keystrokes required on the mobile device.

The proxy-based approach has many benefits. For example, a user has access to his stored form data from any browser on any device. When the loosely- coupled configuration is used, no special software or capabilities are required for the user device. Any browser can be supported without requiring provisioning, upgrades, or installation of new software on the device.

The proxy maintains a repository (for example, database 46 or any other persistent storage mechanism) of stored form entries and consults the repository when processing a web page for delivery to the user over HTTP. If the proxy finds a matching entry in the repository, the proxy pre-fills the text fields in the form with the stored information. The proxy also updates the repository whenever a user fills out and submits a web form via the proxy.

The database may be implemented as an associative map between keys 61 and values 63. The key is a unique identifier for a specific form text field, and the value is a stored entry for that text field.

As time passes and a user continues to use the proxy, he will gradually build up a profile on the proxy, consisting of the most recently-typed values for every text field he encounters. The larger the profile, the more likely that the proxy will be able to pre-fill a text field of a web page accessed by the user.

The form-predicting capability of the proxy is made available to all of a user's devices that have been configured to use the proxy. Imagine Alice has a PDA, a mobile phone, a laptop, and a PC. She can access www.booksforsale.com on her laptop and fill out a form to order a book. Later, she can visit www.booksforsale.com using her mobile phone and order a different book. Remembering that Alice had previously filled out the form on this site, the proxy will pre-fill her zip code, phone number, and so on-minimizing the amount of typing Alice needs to perform on the phone in order to fill out the form.

The user agents that use the proxy need not be running on mobile devices. The agents could be operating on any kind of device that is capable of HTTP- based communication (whether wired or wireless) with the proxy.

A mobile phone equipped with a predictive input system, such as T9, can coexist well with a proxy-based text pre-fill system. When the proxy doesn't pre-fill a text entry or pre-fills it incorrectly, the predictive input technology will assist the user to manually enter the correct value.

Although figure 3 shows the proxy as a distinct unit from the origin server and from the user device, the proxy could be associated with or part of the server or the browser or other equipment or nodes located on a communication network. While the use of the proxy is especially effective with mobile devices of reduced capability, the user devices could be workstations or other devices of any level of capability. As shown in figure 4, the preconditions for the proxy to fill in a form for a user are that the proxy has been initialized and the mobile device user has connected to the proxy and authenticated himself by typing his userid and password. Then the steps are:

1. The proxy receives from the user agent a request for a web page.

2. The proxy submits an HTTP GET request to the web server.

3. The proxy receives the document back from origin web server

4. The proxy reformats the document for rendering on the user agent. This includes rewriting embedded URLs in the case that the proxy is loosely coupled.

5. The proxy searches for text entry fields within the document- specifically, elements in the HTML file named "input" with the attribute "type" set to the value "text". Only elements with the 'value' attribute not set, or set to the empty string, are considered. For example:

For each such text field discovered, the proxy:

a. computes a key, which we will denote by K, for the text field. The key is intended to distinguish this text field from all other stored text fields in the database. One method for computing a key is set forth later.

b. submits to the database a query for a record associated with the key K. If an entry is found in the database, the found string is assigned to the "value" attribute of this <input> element. Suppose, for instance, that the key was bound to the value "bovik" in the database. Then the element above would be rewritten by the proxy as:

6. The proxy transmits the document to the mobile device via HTTP.

Note that Step 5 only considers input elements with no 'value' binding. The 'value' binding is a mechanism for web site creators to themselves offer a suggested value for the text field. User agents will pre-fill the text input field with this value. In some embodiments, the proxy could allow the web site suggested binding to take precedence.

The proxy also can provide the user the ability to update stored entries in the database, subject to the preconditions that the proxy has been initialized, the mobile device user has connected to the proxy and authenticated himself by typing his userid and password, the previous algorithm ("pre-fill form") has executed, and the proxy has transmitted to the mobile device via HTTP a form, possibly containing pre-filled values (if a match was found in the database). As shown in figure 5, the steps of the update process are:

1. The proxy receives from user agent an HTTP POST request, containing a filled-out form.

2. For each text field in the submitted form, the proxy:

a. extracts the typed value V corresponding to that text input field.

b. computes the key K for the text input field. c adds the pair (K, V) to the remembered form entries table in the database. If there was already an entry with the key K, this entry is overwritten with the new value V.

To operate correctly in performing form fill-in, the proxy must be able to distinguish different text-entry fields in web pages that are received from the servers, including those within a given form, those in different forms on the same web site, and those on different web sites. Examples of confusions that can occur include the following:

Scenario 1 : Alice visits www.acme.com and is prompted to type her password to log in. The proxy stores this typed entry in the database, using Alice's userid ("alice") as a database key. Subsequently, Alice visits www.xyz.com and is prompted to enter her zip code in order to be able to enter the site. The proxy consults the database, finds the stored text field associated with the key "alice," and pre-fills the zip-code text field with that value which is actually Alice's password for www.acme.com. Because the database key is just a userid, the key is not specific enough to distinguish among the many different text forms a user may encounter on the Internet.

Scenario 2: Alice visits www.acme.com and is prompted to type her password for that web site to log in. The proxy stores this typed entry in the database, using as a key a concatenation of Alice's userid on the proxy ("alice") and the label, "password," associated with this text input field in the web page. Subsequently, Alice visits www.xyz.com and is prompted to enter her password for that web site, which happens to be different from her password for www.acme.com. She types the new value (the password for xyz), and the proxy stores the new password in the database, associated with the key "alice, password," thus overwriting the old entry. Now, when Alice re- visits www.acme.com, the proxy will pre-fill the password text entry field with the value she typed for www.xyz.com. A database key consisting of just a userid and the form field label is still not specific enough to distinguish among the many different text forms a user may encounter on the Internet.

To avoid collisions of different form entries in the proxy's database of remembered form entries, the database key of each text field entry must distinguish it from all other text field entries.

One key that satisfies these considerations (and doesn't suffer the limitations exposed by the above two scenarios) is Key = userid + [domain name of web site containing the form] + DELIMITER + [name of form containing the text entry field] + DELIMITER + [name of text entry input field]. "DELIMITER" denotes a character or sequence of characters that is known not to be present elsewhere in the key, e.g., a newline ("\n").

In some embodiments, the form entries stored in the database (on disk) will be encrypted. Otherwise, personal information— e.g., login credentials for a bank web site— would be accessible to anyone with the ability to access the database. The database keys will also be encrypted. Otherwise, a third party who had access to the database would be able to learn potentially sensitive information about which web sites and forms individual users accessed.

A straightforward extension would be to apply private-key encryption (e.g., TripleDES) to each (key, value) pair in the database. Rather than storing the (key, value) pair in plaintext, the proxy would apply an encryption function e() to each element of the pair and then store the encrypted pair. When querying the database for the existence of a key K, the proxy would compute the encrypted version e(K) of K and query the database for the presence of e(K). The database would then return an encrypted value e(V), which the proxy would decrypt to get V.

The private key value (for encryption and decryption) should reside on an access-controlled part of the disk or, for higher security, be manually entered at the console by the administrator every time the proxy initializes— in which case the private key is never stored on disk, but only exists in RAM.

This arrangement would require one or more invocations of the computationally expensive encryption/decryption procedure for each text field a user encounters. A more computationally efficient encryption mechanism is to have all of the (key, value) pairs for a user encapsulated into a single object O. This object would be stored in encrypted form in the database. The database would be an associative map from userid to encrypted object in which there would exist at most one object for each registered proxy user. When a user authenticates to the proxy, the proxy reads from the database the encrypted object e(O) for that user. The proxy decrypts e(O) to get O, and then unwraps O to get all the stored form entries for that user. When the user logs out or his session otherwise terminates, the proxy updates O based on the activity in the current session, and (if necessary) encrypts O and writes it back to the database. In that way, there would be only one decryption and one encryption procedure during a user session.

We now outline the analogs to the pre-filling of forms and the updating of stored form values when the form information is encrypted and encapsulated.

The process of loading a user state from an encrypted database has the preconditions that the proxy has been initialized and the mobile device user has connected to the proxy and authenticated himself by typing his userid and password. The process includes the following steps: 1. The proxy issues a query to the database to fetch from the form entry table the encrypted object e(O) for the user.

2. The proxy applies the private encryption key (previously read from disk, during initialization) to the encrypted object to get O.

3. The proxy unwraps O to get an associative map from key to text form entry:

i. (key, stored text entry)

ii. (key, stored text entry)

iii. (key, stored text entry)

iv.

4. The proxy stores these form entries in memory and marks the user as "clean".

5. If the user visits a web site containing a text entry, the proxy consults the in-memory list to see if the text field can be pre-filled.

The process of updating stored values in an encrypted DB has the preconditions that the proxy is initialized, the mobile device user has connected to the proxy and authenticated himself by typing his userid and password, the previous algorithm has been executed, and the proxy has transmitted to the mobile device via HTTP a form, possibly containing pre- filled values (if a match was found in the database). The process includes the following steps: 1. The proxy receives from the user agent an HTTP POST request, containing a filled-out form.

2. For each text field in the submitted form, the proxy:

a. extracts the typed value V corresponding to that text field

b. computes the key K for the text field

c. adds the pair (K, V) to the "remembered form entries" table in memory. The user is marked as 'dirty.' If there was already an entry with the key K, this entry is overwritten with the new value V.

3. When the user logs out or his session otherwise terminates, the proxy flushes the in-memory list of form entries. If the list was marked as "dirty," it is encapsulated into a single object O, encrypted into e(O), and written back to the database.

The above two algorithms make use of a dirty/clean flag for an active user to determine whether that user's set of stored text entries needs to be updated based on the user's activity in the current session. If the user didn't interact with any forms, his database entry need not be updated.

The examples described above allow for a single stored entry per text input field. If a user types into a form field a value that differs from the value stored by the proxy, the proxy will replace the old value with the just-typed value.

The proxy could store multiple values per input field by associating with each key in the database a list of form values, rather than a single value. When the user requests a web page containing a form for which the proxy has stored more than one value, the proxy will insert a menu (as shown in figure 6) for the user to select from among the stored values. The menu includes an option for the user to enter a new value. If the user enters a new value, that value is stored in the remembered form entries table along with the other entries.

Although many different policies could be implemented for ordering the stored values in the menu, one good way would use a last-in, first-out LLFO ordering in which the most recently-typed value would appear first in the menu.

In the techniques described above, the user's text entry is assisted only for visits to a web site that the user has already visited. The proxy could also pre- fill a text field that appears on a site never before accessed by the user.

Each user would have an identity including, for example, first name, last name, phone number, street address, and zip code. These and similar elements are universal in the sense that an individual will likely type the same phone number into every form he encounters, no matter from which website the form is received.

The proxy stores the universal entries separately from the site-specific text entries and supplies the universal entries as default values in any text entry for a text entry field that has an appropriate name that would not otherwise be pre-filled by the proxy.

The database table of stored, site-specific and form-specific text entries are thus augmented by a second table that contains the universal text form entries. A list of entries in the second table might include (alice, zip)-15213; (bob, phone)-412-555-1212; (alice, first)-Alice; (bob, last)-Smith. The first part of each entry identifies the userid and the name of the field that will receive the universal text. The second part of each entry contains the universal text. For example, when a form being sent to alice from any website contains a field called "zip," if there is no site-specific entry for that field, the proxy fills the field with "15213."

Suppose the user visits www.acme.com and types "4125551212" in the text field labeled "phone." The proxy will store two entries in the database:

1. a site-specific key (userid + www.acme.com + input-field-name + ....), along with the value "4125551212," stored in the 'site-specific' table

2. a site-independent key (userid + input-field-name), along with the value "4125551212," stored in the 'site-independent' table

Figure 7 illustrates the steps of a process for updating a two-table database in responds to the submission of a filled-in form by a user agent.

Now suppose the same user later visits www.booksforsale.com and the web page returned by that web server contains a form with a text input field named "phone." In attempting to pre-fill that text field, the proxy will first consult the site-specific table for a key matching (userid + www.booksforsale.com + "phone"). Failing to find a match there, the proxy will then consult the site- independent table for a key named (userid + "phone"). Finding the value "4125551212", the proxy assigns the value "4125551212"to the attribute "value" of the <input> element.

The order of operation— the precedence— is important. The form entry-finding algorithm should consult the site-specific table first, and only failing to find a match there, consult the site-independent table subsequently. One could think of the two tables as a level- 1 and level-2 cache. A key should store an entry in the second table only when the input field name is found within a reserved, fixed list of keywords. This list might include "phone, zip, lastname, firstname," and so on. Restricting stored entries to a set of reserved field names reflects the fact that many HTML authors use generic, non-specific variables as input field names. For example, an HTML author might use the field name 'h' for 'height', and another might use 'h' for 'home phone.'

A new user could be enabled to populate the proxy with a set of form entries by a bootstrapping feature. Otherwise, the user would have to visit many web sites containing forms before the proxy will have built up a substantial collection of stored form entries which it can suggest to the user.

The proxy can be made aware, in advance of a user's first need for text entry assistance of web text entries typed recently by the user. As explained earlier, many PC-based browsers (e.g., Internet Explorer and Netscape) remember previously-entered text form information on behalf of the user, and use this information to prompt the user with suggested values for text forms that appear in web pages.

A new proxy user would typically already have one or more PC browsers that are storing form entry information on the user's behalf. This information would be transmitted from this PC web browser (or browsers) to the proxy. The proxy would then incorporate the received data into the repository of remembered text entries for the user. In this way, the proxy would, all at once, learn a user's profile.

In one example implementation of this concept, shown in figure 8, a standalone program, running on the PC 70, would examine the data structure(s) used to store the PC browser's form entry information. The manner in which this information is stored depends on the make and model of the browser. The standalone program could be made compatible with all popular makes and models of PC browsers, including all recent versions of Microsoft Internet Explorer, Netscape Navigator, and Opera. The standalone program would store the extracted information in a form that the proxy knows how to parse. One such form might be (key, value) pairs, where:

Key=Domain name of site + DELIMITER + form name + DELIMITER + name of text input element

Value=typed value

For example,

Key=www.booksforsale.com + DELIMITER +"orderform" + DELIMITER + "booktitle"

Value- 'Java in 21 days"

After this information is saved to a file on the PC, the user launches the web browser on the same PC and connects to the URL of the proxy. The user authenticates successfully. He then navigates, via the web-based menu options presented by the proxy, to a menu option corresponding to "upload external text form information." The proxy then transmits a web page containing a form to the PC. The form includes a dialog box (the HTML which implements this contains <input type- ile"...>). Presented with this prompt, the user enters the name of the file written to disk by the standalone program. The browser on the PC then uploads this file 72 from the PC to the proxy 74 using HTTP or HTTPS. The proxy incorporates 76 this form-entry information into its existing site-specific table. The proxy may implement several different precedence rules:

1. more recent form entry information-whether uploaded from a PC or generated by observation on the proxy—has precedence over older form entry information.

2. older form entry information has precedence over newer form entry information.

3. form entries uploaded from a PC have precedence over form entries established on the proxy by observation.

4. form entries established on the proxy by observation have precedence over form entries uploaded from a PC.

The bootstrapping information could originate from more than one PC of the user and the proxy would aggregate the information in the database.

Not only can form completions be transmitted from the PC to the proxy, but entries which reside only on the proxy can be transmitted to the PC. Therefore, one can think of this bootstrapping technique as a synchronization activity between the PC and the proxy. The entries could be synchronized from the proxy to more than one PC of a given user.

The described synchronization technique is a one-time, user-initiated action. Immediately after the synchronization, the PC and the proxy may store identical form information, but over time their repositories will diverge as the user employs the PC or the proxy selectively. A daemon program could be constantly executing on the PC to assure that the synchronization remains up- to-date. On a regular basis— each time the web browser is opened, for instance- -the daemon contacts the proxy and initiates the two-way synchronization process. A daemon program may be installed on every PC that the user employs, so that synchronization between each PC and the proxy is maintained.

The bootstrapping process can occur anytime, not just initially. A user could employ the system for several months and then one day decide to upload the form completions stored on his PC browser to the server. This use is not a bootstrapping so much as an augmentation of the proxy's stored form entries. In this case, the uploaded entries would be added to those already stored on the proxy.

A user may wish to query the proxy, typically from a PC, to access and manipulate the list of form entries stored on his behalf, for example, for the following reasons.

A user may in certain circumstances wish to instruct the proxy to forget certain remembered form entries. Consider the following scenario. Alice accesses (using a browser via the proxy) her bank's web site, where she enters her credentials and checks her account balance. The entire transaction is, of course, mediated by the proxy. After Alice authenticates herself, the proxy stores, on her behalf, the userid/password she typed. Now suppose Bob asks to borrow Alice's mobile device. Alice should direct the proxy to clear its memory of that form entry. Otherwise, Bob could access Alice's account information by visiting her bank's web site where the proxy would already have filled in Alice's userid/password in the login screen.

In another example, suppose that Alice moves her residence, from zip code 27410 to zip code 15217. If Alice is an active web user, there maybe several web forms into which she has entered her zip code. It would be useful for her to be able to update all the remembered entries in a single session, simply by interacting with a form which lists the stored form entries. Otherwise, Alice could only achieve the same result less conveniently by accessing the individual web sites one by one, editing the text pre- filled by the proxy, and submitting the updated form. The proxy would, upon receipt of each form, take note of the updated form entry and record that new value in the database.

One way to offer users the ability to view, edit, and selectively remove items from the list of form entries stored by the proxy on their behalf would be to have the proxy offer to authenticated users a menu option for accessing stored form information. When the user selects this option, the proxy queries the database to determine the list of stored form entries. From this list, the proxy generates an HTML form 70 (figure 9) in which the individual stored form values 72 may be edited. This form is then transmitted to the user. The user fills it out and submits it back to the proxy (using an HTTP POST request). The proxy analyzes the POST to. see if any of the values have been edited, and makes the appropriate changes in the database.

Using the form shown in figure 9, a user may alter the stored text value for a specific input field, and inform the proxy not to store (and never to pre-fill) a text value for a form.

Among the advantages of the invention are one or more of the following.

Because the proxy is located centrally (e.g., associated with or independent of the content servers) and is accessed by a communication link, a user can access his stored text-form data entries from any browser on any Internet- enabled device that can communicate with the proxy. The proxy occupies a zero footprint, that is, the proxy does not require any additional processing or storage capacity of the user device beyond what would normally be required to receive, process, and render any incoming Internet information. No additional software or data must be stored or run on the user device. For the same reason, no provisioning or upgrading features need be available on the user device and no time or processing or storage capacity of the user device need be devoted to provisioning or upgrading.

Other implementations are within the scope of the following claims.

The proxy could be arranged to condition the automated fill-in of one text field on information known to the proxy about user fill-in of another field. If a user typed VISA in one box, the proxy could choose the user's VISA account number (rather than a MasterCard number) for automated fill-in in a related box.

The information that is used to pre-fill text fields need not be information obtained from the user but could be generated in other ways. For example, a form entry field with the attribute 'name' equal to "date" could be pre-filled to today's date, rather than the text typed by the user in their last interaction with the form.

The text to be used for fill-in need not actually be filled in to the text field in the proxy, but could be delivered to the user agent for insertion into the text field on the user device. For example, the proxy could insert a new attribute into the input field, for example "suggested-value," which certain browsers would recognize and (depending on how the user has configured the browser) display or not display.

Claims

1. A method comprising

intercepting a communication being sent through a communication network from a source to a user process, the communication including a text field to be filled in by a user,

providing text for filling in the text field based on pre-stored information , and

delivering the communication and the fill text to the user process.

2. The method of claim 1 in which the fill text is provided at a location on the network different from the location of the user process.

3. The method of claim 1 also including filling in the text field with the fill text before the communication and fill text are delivered.

4. The method of claim 1 in which the communication comprises a file.

5. The method of claim 4 in which the communication comprises a mark- up language page and the user process comprises a browser.

6. The method of claim 1 in which the text field is part of a form.

7. The method of claim 1 in which the pre-stored information is associated with the user process.

8. The method of claim 1 in which the pre-stored information is associated with a type of information that is to be entered into the text field.

9. The method of claim 8 in which the text that is provided for filling in is not determined based on the source of the communication that is being sent to the user process.

10. The method of claim 1 in which the pre-stored information is associated with a source of the communication that is being sent to the user process.

11. The method of claim 10 in which the source comprises a web page.

12. The method of claim 1 in which the pre-stored information is stored in a repository.

13. The method of claim 12 in which the pre-stored information is stored as a database.

14. The method of claim 13 in which the database comprises entries each of which associates a key related to a text field of a communication with a text entry for the text field.

15. The method of claim 14 in which the key comprises a user id and a form field label.

16. The method of claim 15 in which the key also includes a domain identifier and a form identifier.

17. The method of claim 1 also including using encryption to protect the pre-stored information.

18. The method of claim 1 in which the pre-stored information is associated with a user of the user process.

19. The method of claim 18 in which the information is derived from the user.

20. The method of claim 19 in which the information is derived from the user by the user entering the information.

21. The method of claim 19 in which the information is entered by the user into a text field of a communication.

22. The method of claim 21 in which the entered information is derived from the communication as the communication is being delivered from the user process.

23. The method of claim 21 in which the entered information is cached at the device running the user process and the pre-stored information is derived from the entered information at a time after the communication is delivered from the source.

24. The method of claim 20 in which the information is entered by the user in text fields of communications sent to the user process.

25. The method of claim 1 in which the fill text comprises identifying information about a user of the user process.

26. The method of claim 1 in which the providing of fill text is performed by a proxy server.

27. The method of claim 26 in which the proxy server also provides other services for the user with respect to the communication.

28. The method of claim 26 in which the pre-stored information is held in a database associated with the proxy server.

29. The method of claim 1 in which the user process runs on a wireless device.

30. The method of claim 1 in which the user process runs on a hand-held device.

31. The method of claim 1 in which delivering the communication comprises using an HTTP protocol.

32. The method of claim 1 in which the communication comprises an electronic message.

33. The method of claim 1 in which the pre-stored information includes a body of fill texts.

34. The method of claim 33 in which the body of fill texts includes fill texts for different fields.

35. The method of claim 33 in which the body of fill texts includes fill texts for different users of user processes.

36. The method of claim 33 in which at least some of the text fields are grouped and encryption is applied to the group.

37. The method of claim 1 also including multiple alternative fill texts for a given text field and in which a choice among the alternative fill texts is provided to the user.

38. A method comprising

pre-storing at a proxy server, fill texts associated with different users of handheld or wireless devices, intercepting web pages that are being served to the users,

for each of the web pages, identifying the users to whom they are being served and text fields to be completed in forms included in the web pages,

for at least some of the text fields and some of the users, identifying ones of the pre-stored fill texts,

filling the text fields using the identified fill texts, and

delivering the web pages with the filled text fields to the handheld or wireless devices of the users.

39. A medium bearing a data structure capable of enabling a process to identify fill text to be inserted into text fields in a communication, the data structure comprising fill text entries and information associated with each of the fill text entries, the associated information sufficient to identify text fields for which the respective fill entries are suitable.

40. The medium of claim 39 in which the data structure comprises a database and the associated information comprises keys of the database.

41. The medium of claim 39 in which the fill text entries comprise text strings associated with user processes.

42. A method comprising

intercepting a communication sent from a user process,

identifying text fills included in text fields of the communication by the user process, storing each of the text fills and associated information about the context of the text fields in which the text fills are included, the context and the text fills being stored in a form that enables use of the text fills for filling text fields in other communications based on the contexts of the other communications.

43. The method of claim 41 in which the contexts comprise the identities of at least one of the fields, the user process, and the communications.

44. The method of claim 41 in which the contexts are stored in a database and keys of the database are based on the contexts.

45. A method comprising

enabling a user to enter, on a user device, text fills for text fields of communications,

storing the text fills at a device separate from the user device, and

enabling a user to manage, from the user device, the text fills stored on the separate device.

46. The method of claim 45 in which enabling a user to enter text fills includes enabling the user to enter text fills in text fields of communications.

47. The method of claim 45 in which enabling a user to manage the text fills the using the text fills

48. A method comprising

initializing a repository of text fills for text fields by downloading text fills from a device of a user, the text fills from the user device having been generated by an assisted text entry process running on the user device.

49. The method of claim 48 in which the repository of text fills for text fields is initialized from more than one user device of the user.

50. The method of claim 48 also including updating the repository text fills based on text fills entered by the user on the user device following the initializing.

51. A system comprising

a proxy containing a set of text fill entries and running a process to use selected ones of the fill entries to complete text fields of communications directed from a source to a user process running on a user device, and

a user device running a user process to receive and send the communications to and from the source.

52. A proxy server comprising

a repository of text fill entries associated with a user of a device served by the proxy server, and

a proxy process to complete text fields of communications passing from a source through the proxy to the device, using text fill entries that are associated with the user and suitable for the text fields.