WO2002025497A1 - System for automated data entry of resident data - Google Patents

Abstract

The present invention is a resident data entry system (Figure 4) for automated data entry of data values stored on, or in a memory accessible by, a user's computer (i.e. 'resident data'). The system preferably includes, as an example, an electronic device executing a resident data system program code (400) for initially storing and subsequently recalling the resident data. Resident data may relate to a specific user and include the name, address, telephone number, and e-mail address of the user (412,414,416 and 418). In a B2B scenario, the resident data may include business data (420) useful in generating and maintaining commonly used documents. Resident data may be menu driven (410), defaulted into fields, or entered by other manners.

Description

SYSTEM FOR AUTOMATED DATA ENTRY OF RESIDENT DATA

Cross Reference to Related Applications

This application claims the benefit of priority from U.S. Provisional Application Serial

Number 60/233549, filed September 19, 2000.

Field of the Invention

The present invention relates generally to computer systems and electronic devices. More specifically, the invention relates to the automated storage and entry of data on such systems and devices.

Background of the Invention

Personal computers ("PCs") have become a commonplace tool of automation for business and personal users, hi most settings, whether it be a "Fortune 500" company, a university, a government agency, or a home office, increasingly portable wired and wireless electronic devices are used as an individual's interface to software applications and data necessary to accomplish business and/or personal objectives. The general perception, and apparent reality, is that the use of such devices allow a user to accomplish more tasks in a shorter period of time, and does so with increased accuracy. While great efficiencies have been realized to date, computer and software makers continue to develop improved hardware and software aimed at achieving still greater efficiencies.

To a large and ever increasing degree, electronic devices, such as PCs, are networked with other devices, such as other PCs, servers, databases, and so on, as a means of accessing remote applications and data and of communicating and exchanging information with others. In one type of business or organizational setting, such a network may be a private "intranet", accessible only by a designated group of users. However, in another type of business or organizational setting, or in a personal user setting, the network may be the Internet and/or world wide web (the "Web"). The Internet and Web are particularly useful when a business or organization seeks to remotely transact business with clients, customers, or members, as examples. For instance, in a consumer to business scenario a retail business may have a Web site that any customer may access to order products, often referred to as shopping "on-line". In such a case, a user accesses the retailer's Web site, selects one or more products (e.g., books, theater tickets, apparel and so on) for purchase and then, typically, inputs his name, shipping address, phone number, and credit card information to complete the transaction.

In another setting, a user may access an organization's Web site to establish an account, membership, or some other affiliation with that organization, e.g., to join on-line. To do so, the user is typically required to input certain personal information (e.g., name, address, phone number and so on). This personal information may also include credit card information used to pay the membership dues of that organization, if any. There are numerous examples of organizations that a user may j oin in this manner. h yet another setting, a user may seek to add personal information to an on-line database, which is accessible by others. For example, many universities now have on-line alumni databases. A user-alumnus may access such a database through his or her university's Web site to add or update personal information (e.g., name, address, phone number, business address, and business phone number) in the on-line alumni database. Other popular databases include internet phonebooks (business and personal), and search engine, auction, subscription and contest databases.

The number and type of on-line organizations which require or invite the input of information are too numerous to mention, and they continue to grow. Despite the efficiencies offered by computer systems and on-line services, when a user transitions from an input screen of a Web site of one such organization to an input screen of a Web site of another such organization, the user's information must be re-entered.

Beyond Web-based applications, other applications may also require input of data already stored, such as network account-based applications and newly loaded applications. In a business to business scenario, a company may repeatedly generate a plurality of documents as part of its normal course of business, such as requests for proposals, purchase orders, and invoices. This type of document generation and related project and account management often results in repetitive entry of data into related documents. For instance, for a given project, a user may have to generate a request for proposal, contract, purchase orders and invoices, possibly using different applications, h a typical setting, the same data (e.g., contract number, names and addresses of the parties and so on) must be entered anew in each document, which is quite time consuming. Additionally, entry of resident data is likely to become an increasingly important issue, That is, an increasing amount of types of electronic devices invite or require the input of user related data. For example, handheld devices like cell phones, pagers, and electronic organizers continue to add user interactive functionality, including e-mail and Web-based functionality. Additionally, traditionally non-interactive devices are becoming increasingly interactive. For example, applications now exist that allow interactive Web access through a television and in some cases household appliances may remotely accessed and controlled. Summary of the Invention

The invention is a resident data entry system for automated storage and subsequent entry of data values on, or in a memory accessible by, an electronic device. The invention may be applied to any of a variety of electronic devices, such as a personal computer (PC), terminal, or workstation. Furthermore, with the migration of e-mail and other video and text messaging to hand-held devices, the resident data entry system may also be applied to cell phones, pagers, electronic organizers, e-mail stations, or other such devices, as examples, where the functionality of such devices dictates repeated entry of data. Additionally, to the extent that user interaction functionality is merged with other electronic devices, such as the combination of Web access and television, household appliances and automobiles, the present invention may similarly be applied to those other electronic devices.

The resident data entry system includes a resident data entry program code that is hosted on or accessible by an electronic device, e.g., a user's PC. The resident data entry program code includes an engine (and logic) that provide functionality for storing data in memory that is related to a user or an organization, depending on the context within which the resident data entr - system is applied. Once stored, either locally or remotely, the data is referred to as "resident" data or data values. Subsequently, the resident data entry system selectively recalls the resident data to facilitate the automated entry of such data into the input fields of application files or database systems. The resident data is preferably personal or business data, but may be any type of data, depending on the embodiment. Personal data may include home or office user data, such as an individual's name, address, e-mail address, and telephone number, as examples. Business related resident data may include project, contract, or account data, as examples. Regardless of the embodiment, resident data preferably includes data that is frequently requested by local and/or remote applications or systems, e.g., on-line shopping, document production or project management applications.

As will be appreciated by those skilled in the art, the resident data entry system may be used in a variety of architectures. For example, a user's electronic device may be a "standalone" device, with or without access to a network. That is, in a home setting, the user's computer may be a PC that selectively accesses the Internet and Web via an Internet service provider (ISP). In such a case, the resident data is preferably stored in memory local to the user's PC. As another example, the user's PC may be one of many PCs in an organization's intranet. In such a case, the user may have an account on the intranet as a "client", wherein the user is required to login to the network, and the resident data may be located on an intranet account server and associated with that client or user, as part of that user's account information. In another example, the resident data may be organizational data, rather than user data, that is stored on an intranet account server and associated with the organization's accounts. Additionally, a network may be configured to have a user login to an account server (i.e., enter the network) from any of a variety of local or remote devices and, thereby, gain access to resident data, h such cases, the resident data entry system program code can be hosted on a network server, the user's computer, or some combination thereof. Additionally, the user's computer and network may be configured such that the user can gain access to the Web via a gateway on the intranet, and vice versa. As will be appreciated by those skilled in the art, the resident data entry system may be employed in a variety of network configurations and may be account-based or platform-based, as examples, without departing from the spirit and scope of the present invention.

The resident data entry program code may be implemented in hardware, software, firmware, or some combination thereof. To the extent that the program code is implemented in software, it may be coded in any of a variety of programming languages. The resident data entry system program code includes means to define a set of resident data elements corresponding to the information to be stored. In a personal application, the data elements include user related data, such as the user's name, home address, home telephone number, and so on. The resident data elements may also include business related user data elements, such as name of the user's employer and business address, telephone number, e-mail address, Web site uniform resource locator (URL), and so on. h a business context, the resident data elements may include elements useful in the conduct of business, such as contract, account, and management data elements. The set of data elements may or may not be predefined and once defined they may or may not be editable, e.g., added, deleted, or edited, to satisfy the needs of a particular user or organization. Resident data values may be stored and subsequently updated in a variety of manners, i one form, the user executes the resident data entry program code (or enables the resident data entry system) and inputs data using a resident data entry system user interface. In another form, the resident data entry system automatically stores data as it is first entered by the user into the input data fields of an application, this latter form, the resident data entry system analyzes the data entry (or input) fields and data entry requests or code of a software application with which the user is interacting to predict or determine the nature of the requested data on a field-by-field basis. If a resident data value is not already stored for a given resident data element, when a value is input into a field, the resident data entry system selectively puts a copy of the user's input into a resident data database as a resident data value, preferably with the user's validation. Of course, these manners of entering resident data values may be provided together or independently and in either case a set of user interface screens may be provided for reviewing and editing the resident data values. hi one form, the resident data elements may be related to contexts. The contexts provide a manner of entering (and subsequently viewing and editing) a set of related resident data values. For example, contexts may be defined as Who, What Where, When and Why, where each context collects or displays (if already collected) a different subset of resident data values associated with a larger set of resident data values, as discussed below in the business-to-business (B2B) example. The contexts are defined in executable files of a standard format, in accordance with conventional programming principles. Additionally, for each context, a Web browser form (or page, or screen) is defined. The engine of the resident data entry system processes the forms, which in turn call the context files, to store, edit, and view resident data values.

In a B2B example, the data gathered using the context-based Web forms facilitate the preparation of business documents. Generally, the Who context and screen relate to the identification and contact information of a particular individual or organization. The What context and screen relate to identification and related information concerning a certain relationship or transaction. The Wϊiere context and screen provide information identifying a geographical location related to a project, for example. The When context and screen provide information identifying key dates related to a project. And, the Why context and screen provide information identifying key information and notes related to a project. The definitions of contexts and screens may be changed depending on the application of the resident data entry system. With the resident data values stored in the resident data database, the resident data values may be selectively written into various documents, such as RFPs, POs and PRs. Use of the context forms, which are typically not part of the documents, continue to provide a manner of reviewing and editing existing resident data values and storing new resident data values.

Preferably, entry of a data value in one field of a form, causes all other fields in all other related forms to automatically be updated with corresponding data values.

The process of writing resident data values into specific input data fields of an application may be accomplished by operator selection or initiation or by automatically writing in "default" ' values. The capability for the user selection of resident data values may be provided as either an alternative or companion to the capability to automatically write resident data default values into the input fields. In the case where resident data values are entered in response to operator selection, a menu of items corresponding to resident data elements maybe presented to the user as a function of the user's selection of an input field. The user's selection of an item from the menu then causes the writing of a corresponding resident data value into the selected input field. As examples, the rendering of a menu and subsequent selection of resident data values maybe accomplished by manipulation of the computer's mouse or a "hot-key". For data elements to be written into input data fields automatically as default values, the resident data entry system analyzes the input data fields of the application to determine or predict which resident data element corresponds to each field and, therefore, which resident data value should be written into the input data field. This process continues for each field for which the resident data entry system has corresponding data. The resident data entry system may be selectively disabled, in the event that the user does not want data automatically written into input fields, and then subsequently enabled. Additionally, resident data maybe stored for each individual in a group (i.e., a set of data values for each individual), wherein identification of a current user from the group causes that user's resident data to be used, h a business scenario, resident data may be stored for each client, account, project, contract or other useful manner, or with some combination thereof.

Brief Description of the Drawings

The foregoing and other objects of this invention, the various features thereof, as well as the invention itself, may be more fully understood from the following description, when read together with the accompanying drawings, described:

FIG. 1 is a block diagram of a Web application and a software structure of a resident data entry system, in accordance with the present invention.

FIG. 2A is diagrammatic view of a simplified computer architecture, having a personal computer that includes the resident data entry system linked to a remote Web application server via the Internet and the Web.

FIG. 2B is a diagrammatic view of the personal computer of FIG. 2 A, as part of a network including a plurality of electronic devices, linked to the Web application server of FIG. 2 A via the Internet and the Web.

FIG. 3 is a block diagram depicting one embodiment of the resident data entry system of FIG. 1.

FIG. 4 is a user-based class diagram depicting typical classes and corresponding data which may be included in the resident data entry system of FIG. 3.

FIG. 5A-5D is a set of user interface screens for an on-line shopping application with which the resident data entry system of FIG. 3 maybe used.

FIG. 6 is block a diagram depicting a context based embodiment of the resident data entry system of FIG. 3.

FIG. 7A through FIG. 11 is a set of user interface screens relating to the context-based embodiment of FIG. 6.

For the most part, and as will be apparent when referring to the figures, when an item is used unchanged in more than one figure, it is identified by the same alphanumeric reference indicator in all figures.

Detailed Description of the Preferred Embodiments

The present invention is a resident data entry system for initial storage and retrieval of commonly used data, referred to as "resident" data, which is subsequently entered into input fields of, for example, on-line application files. The resident data is stored on or accessible by a user's computer and is comprised of a group of data elements and corresponding data element values. Resident data may be an individual's (or user's) personal data, including a name, home address, and home telephone number. Resident data may also be user related business data that includes a user's name, business address, and Web site address of the company for whom the user works and the user's job title, e-mail address, and office phone number, as examples. Business data may also include data primarily oriented toward the business's projects, accounts, contracts, and so forth, thereby facilitating more efficient business conduct. Other types of resident data may also be defined.

In the preferred embodiment, the resident data entry system is comprised of one or more wired or wireless electronic devices hosting resident data entry system program code. Typical devices include, but are not limited to, a personal computer ("PC"), personal digital assistant (PDA), cellular telephone, pager, and portable e-mail device, hi short, the resident data entry system program code may be included in any electronic device or computer wherein repeated entry of data is possible. For illustrative purposes, the resident data entry system program code is executed by a PC to initially store the resident data and to subsequently selectively write specific resident data values into corresponding input data fields of other application files, such as forms and documents. Examples of such applications include any of a variety of network or Web-based applications which prompt for user or business data to accomplish on-line shopping, registration, subscription, procurement, project management, database management or other tasks. In a typical environment, the user interacts with such applications via a Web browser, which processes the code downloaded to the user's device using the browser's "virtual machine". The resident data entry system also interfaces with non- Web applications, to facilitate the automatic input of resident data into input fields of those applications. For example, when installing a new application, a user is often prompted to input his/her name, address, e-mail address, telephone number, a product registration number. In many instances, the application transmits this data to the maker of the application the next time the user goes "on-line". Much of this information may have been entered by the user in other instances many times before. However, in accordance with the present invention, once a user has initially entered data values (e.g., user and/or business data) corresponding to resident data elements, the resident data entry system relieves that user of having to retype such information when subsequently prompted to do so. In a procurement or project management context, efficiencies are realized with respect to inputting data to be used in the preparation of various types of forms and documents by alleviating the need to retype resident data into those forms and documents. Such documents may include requests for proposal (RFPs), invoices, purchase requisitions (PRs), purchase orders (POs), company datasheets and so on. These documents may be part of a document management system to which the resident data entry system is interfaced.

One embodiment of a software architecture 100 comprising a typical Web-enabled device and a resident data entry system program code 150 is shown in FIG. 1. The components collectively referred to as 105 maybe resident on a Web-enabled device, such as a PC, which then interfaces to a network (e.g., the Web). As is customary, the PC functions under the control of an operating system 110 that provides basic services to applications executed by the PC. An example of one such operating system is MS-DOS®, preferably running a Windows 98® environment, by Microsoft Corporation, of Redmond, WA. To facilitate an interface with the Web, a Web browser 120, such as Internet Explorer® by Microsoft Corporation, is included in the architecture and facilitates access by the PC to any of a variety of Web sites and their applications 130 via communications link 135. Web browser 120 and resident data entry system program code 150 each interface with operating system 110 for basic services, as is common for applications running on a PC. The resident data entry system program code 150 interfaces with Web browser 120 via an application program interface (API) 155. API 155 allows the resident data entry system program code 150 to communicate (i.e., exchange messages and data) with

Web browser 120, and thereby with Web application software downloaded from Web application 130 to Web browser 120 (i.e., the PC) via link 135. Other APIs may also be provided to facilitate communication between the resident data entry system code 150 and other applications. Application program interfaces are well known in the art and not discussed in detail herein.

Once data corresponding to data elements is entered into the system, the resident data entry system program code 150 writes, via OS 110, the user data to database (DB) 140 as data values, thus storing the data as resident data. Database 140 maybe either local or remote to the PC or part of a database management system, but if remote, DB 140 must be accessible by resident data entry system program code 150. The actual location of DB 140 maybe a function of whether the resident data entry system is hardware-based or account-based, as will be discussed with respect to the resident data entry system's applicability to a variety of computer architectures. A simplified computer architecture 200 is shown in FIG. 2 A, as an example. In such an architecture, the resident data entry system program code 150 is stored and executed on a user's PC 210. hi this "standalone" architecture, PC 210 includes the components 105 of FIG. 1. PC 210 accesses a Web application server 230 (which hosts Web application 130) via the Internet and Web, as indicated by communication link 135. Those skilled in the art will appreciate that communication link 135 of FIG. 2 A may include a plurality of communication devices and linlcs, which are substantially transparent to the user of PC 210. The resident data entry system stores data values to local memory of PC 210 and selectively copies resident data (or data values) from memory to corresponding input fields of other application files (e.g., an on-line shopping Web application or document production application). As shown in FIG. 2B, PC 210 may be one of many electronic devices linked over a network 250, such as a local area network (LAN), a wide area network (WAN) an extranet, or an intranet. Electronic devices may also include such devices as a cell phone 212, laptop PC 214, PDA 216 and server 218. hi network 250, server 218 acts as a gateway for devices 210, 212, 214 and 216 to access other networks, such as the Internet and Web via a communication link 220. For example, PC 210 accesses Web application server 230 via server (i.e., gateway) 218 and link 220. hi such an architecture, the resident data entry system may be used to automatically enter data values into input fields of Web, network, or device-based applications.

Network 250 may be a client-server architecture, in which case a user may login to a server (e.g., server 218) on the network to gain access to network applications, hi a client-server architecture, the resident data entry system program code 150 (and API 155, see FIG. 1) and the resident data itself may be stored and executed (in the case of code 150) on server 218, rather than on PC 210, or they may be distributed on some combination of computers within the network. If the user is required to login to a server, the specific resident data may be part of a specific user's client file (or account) on the server. In such a case, a specific user may login to his account at server 218 from either of devices 210, 212, 214 or 216, and have access to his resident data, regardless of the device used. Therefore, the resident data entry system is employed in an account-based manner, rather than a hardware-based manner (as described with respect to the architecture of FIG. 2A). As with the standalone architecture of FIG. 2A, when the user is presented with a prompt for resident data by an application, the resident data entry system is used to facilitate the automatic entry of resident data into corresponding input fields of the application. Therefore, in a network architecture, the resident data entry system facilitates automated data entry regardless of where on the network the resident data entry program code and resident data actually reside. A set of public, organization, and business data may also be accessible over network 250 as resident data, in addition to the user's data.

An exemplary structure for the resident data entry system 300 is shown in the block diagram of FIG. 3. Although, as will be appreciated by those skilled in the art, the resident data entry system may be implemented in other types of structures. As shown, the resident data entry system 300 includes program code 150, API 155 and resident data DB 140 of FIG. 1. Program code 150 embodies an engine 310 that access a set of rules, among other things, stored in rules DB 320 and performs the basic control and processing of resident data system 300. Engine 310 accesses the rules in rules DB 320 for initially storing data and, in one embodiment, for subsequently analyzing prompts and requests for the input of data by an application, as described with respect to FIG. 4 through FIG. 9. In a B2B setting, engine 310 also manages the entry of resident data into Web-based forms and documents, as described with respect to FIG. 6. The resident data entry system may be used with Web-based application 130 accessed via browser 135 and API 155. Additionally, beyond its use with Web applications, the resident data entry system may be used with other (non- Web) applications, such as application 360, which is interfaced via a corresponding API 365.

Data may be entered into DB 140 in a variety of manners. For example, resident data may be directly entered into the resident data entry system by a user, in one embodiment. In this embodiment, the resident data entry system 300 may include a user interface 350. Data may be entered via user interface 350, read by a read/write module 340, and written by a database read/write module 330 into resident data DB 140, under the control of engine 310. The resident data may be subsequently edited via user interface 350. The user interface may be a Web browser interface that provides forms for gathering, reviewing, editing, and deleting resident data, as described with respect to FIG. 6 through FIG. 11. The resident data entry system 300, additionally or alternatively, maybe configured to automatically detect entry of an input field of an application program and to copy the input data into the resident data DB 140 as a corresponding resident data value, if no such resident data value has been previously stored. For example, if the user is interacting with Web application 130 through Web browser 135, engine 310 (via API 155) analyzes the Web page code, such as hyper text markup language (HTML) input tags and associated variable names, to determine the nature of the data to be input into each Web page input data field. As an example, a HTML line of code prompting for the input of a user's first name may be:

<INPUT TYPE = "text" NAME = "firstname">. This line of HTML code is analyzed by engine 310, which determines that an input of type "text" is requested and that the variable name associated with the text is firstname. hi accordance with known text parsing and analysis algorithms, engine 310 determines that this line of HTML code is prompting the user to input a first name. Similar analysis is performed for other types of resident data. If the user's first name has not yet been stored as resident data, the user enters a name in the input field of the application and the resident data entry system stores the entered name as the data value of a data element (e.g., firstname)' corresponding to the user's first name in resident DB 140. Also, using known parsing techniques, a user's input may be parsed and stored as a plurality of data values. For example, the name "John Smith" may be input as a full name and subsequently parsed, wherein "John" is stored as a value for the data element firstname, "Smith" is stored as lastname, and "John Smith" is stored as fullname.

Once there is resident data stored in DB 140, the data values may be edited by subsequent entry in the input fields of an application and operator initiated storing of subsequent data values or by redefining the data values using user interface 350.

The resident data entry system 300 may be configured to automatically write the data values into data fields as default values, hi this embodiment, resident data entry system 300 performs substantially the same analysis of the HTML code and input fields as previously described with respect to the automatic storage of resident data values. However, upon determining that an input field is prompting the user for input of a first name, the resident data entry system passes a copy of the user's first name from the resident data DB 140 to Web application 130. The resident data entry system 300 may actually pass a pointer to the resident data database location of the user's first name and the application may subsequently "get" a copy of the user's first name from that location, in accordance with known programming principles. Using the previous HTML code example, Web application 130 writes, as a proposed or default value, a corresponding resident data value into the input field for the variable firstname. The user may over-write the default value, if desired. This process continues for each input field within the Web page. In a different embodiment, the resident data entry system may also include the user selectable functionality as an alternative or companion to the default entry functionality. Assuming that resident data exists in resident data DB 140, the data values may be written to the input fields of an application in one or more of a variety of ways. In one form, the resident data is entered into a user selected input field of an application in response to user selection of a data element from resident data DB 140 (e.g., by selection of a data element from a drop-down list), h this form, the resident data entry system need not provide any automated analysis of code or any other determination of the nature of the data to be input into an input field, but need only provide a means for the user to select resident data to be written into a selected input field. As one example, the user selects an input field, opens a menu of resident data items corresponding to the resident data elements and values in resident data DB 140, and selects an item from the list to be written into the input field. User selection causes the generation of a request for a data value. Engine 310 services the request and passes either of a pointer to or a copy of the requested data value in resident data DB 140, which is then passed to the application (e.g., application 130). Additionally, related resident data values may be defaulted into corresponding fields on the same page or form, and on related pages and forms. As examples, the present invention may be applied in an e-commerce (or other on-line) setting, either consumer-based (e.g., consumer to business) or commercially-based, such as B2B. In either setting, a basic object oriented design (OOD) approach is preferred, wherein an object model is defined to include a set of resident data elements, and wherein specific instances of objects include or refer to corresponding resident data values. One particular advantage of an OOD approach is that it lends itself to storing resident data for multiple users and entities in a flexible, yet structured way. As will be appreciated by those skilled in the art, the object (or class) definitions described herein may be expanded or otherwise altered and additional classes or subclasses maybe created to represent any of a variety of commonly input information. Accordingly, the resident data entry system may include any of a wide variety of possible resident data elements and values. Additionally, objects may exist which store "hidden" data, such as information identifying particular versions, configurations, or other properties of the software and/or hardware of the user's computer or data derived from previously stored resident data values.

FIG. 4 through FIG. 5D show a consumer-based e-commerce embodiment, wherein a user interacts with a third party Web-based on-line shopping application. FIG. 4 shows a generic user-based class structure for an OOD approach corresponding to this embodiment. As will be appreciated by those skilled in the art, class 400 is simplified, for illustrative purposes, to include only a subset of data which may typically be stored as resident data. User_Data class 400 includes two subclasses, one for home data and one for business data, i.e., homedata 410 and businessdata 420. The resident data entry system may also be configured to allow a user to designate only a subset of resident data values to be accessed (e.g., only home data, only business data, or no credit card data). These subclasses contain further subclasses which store specific user data, e.g., name, address, and telephone number. While the resident data entry system is described with respect to storing and writing data for a single user, the resident data entry system may also be configured to store and write data for a group of users. That is, User_Data class 400 can be instantiated five times to create a different object corresponding to each of five users, with no inherent limit of users implied in the program structure, hi such a case, resident data is stored with respect to each single user from the group of users. For example, if a family of five people all share the same PC at home, five different sets of resident data may be stored, one per user. During operation, a user identifies itself to the resident data entry system. Thereafter, all resident data corresponds to that user. Therefore, when a member of the family uses the PC and is prompted to input resident data, that user first selects his name from a group of the five users. hi FIG. 4, the subclass homedata 410 includes subclasses which represent a user's full name, home address, telephone number, and home internet information, i.e., fullname 412, homeaddress 414, hometel 416, and homenet 418, respectively. Fullname 412 contains character variables (i.e., data elements) for firstname, middlename, and lastname. For a specific user John B. Smith, when a User_Data object 400 is created, firstname = "John", middlename = "B.", and lastname = "Smith". Similarly, subclass homeaddress 414 includes character variables streetname, citytown, statename, and zipcode. Also, hometel 416 includes variables for various user home telephone numbers, such as voicetel, faxtel, celltel, and pagertel. Finally, subclass homenet 418 includes a variable email for the user's home e-mail address and a variable website for the user's home Web site address. A corresponding set of subclasses exist in the subclass businessdata 390, including businessname 392, businessaddress 394, businesstel 396, and businessnet 398.

FIG. 5A shows a typical user interface (or Web page form) 500 of a Web site used for online shopping, in a consumer-based e-commerce embodiment. User interface 500 includes the name of the retailer, "Store ABC" 502, an order summary section 510, a method of payment section 530, and address sections 550 and 570. A "Submit" button 590 is included so that when all required input fields have been completed, an additional user operation (i.e., mouse clicking on the "Submit" button) is required to place the order. As can be seen by the order section 510, the user has ordered "Product p-1" and "1 Year Service Plan, s-1", for an "Order Total" of

$575.00. hi this example, the user may then select a payment method, either credit card, COD, or the option of being billed. The user's name is required in payment section 430 in the form of first name 532, middle initial 534, and last name 536. The address section provides for entries of home address 550 and business address 570. In the home address section, a street field (i.e., "Line 1") 552 relates to the residential street information of the user. Input fields for the city, state and zip code 554, telephone number 556, fax number 558, home e-mail address 560, and home Web site address 562 of the user are also provided. Business section 570 includes input fields similar to those provided in the home address section 550. The OOD class structure of FIG. 4 allows for each of these types of items to be stored as resident data values and may also be configured to include at least some credit card data, although a user may prefer not to have any credit card data stored as resident data.

FIG. 5B shows the user interface 500 for Store ABC when accessed by a device including the resident data entry system, which provides the user with mechanisms (e.g., drop-down lists or pop-up menus) to facilitate selection of resident data items to be written into selected fields. For example, in the payment method section 530, the user has selected the first name input field 532, as indicated by the vertical prompt line 533 (typically flashing) in that field, hi this embodiment, pop-up menu 535 is rendered by right clicking the mouse after selecting a field. Although, other approaches could be used to render pop-up menu 535, such as by manipulation of a "hot key" or a macro or menu item included in the window of the Web browser or application being used. The user selection and menu approach may be the sole approach to entering data or may be included as companion functionality to the default value functionality described with respect to the embodiment of FIG. 5D. The user selection functionality is particularly useful when a user desires to input resident data into an application file for which resident data cannot automatically be defaulted into input fields, e.g., application files for which the code associated with an input field can not be parsed.

In this example, it is assumed that only personal user data is included in resident data entry system DB 140. Therefore, no business user menu items are shown in menu 535. However, the resident data entry system may be configured to allow the user to operate in one of various modes (e.g., personal, business, combined), hi such a case, selecting a mode enables or disables certain resident data elements from being accessed.

Placement of cursor 539 proximate to one of the items in the pop-up menu of items 535 highlights that item. In this example, pop-up menu 535 only includes objects created from the subclass homedata 410 of FIG. 4. If screen 500 were being used in a B2B context, menu 535 could include objects created from the subclass businessdata 420, or from other classes. In this case, under the menu item "Full Name", the menu item "First" 537 is highlighted by cursor 539. When the user clicks on the highlighted item "First" 537, the resident data value corresponding to the user's first name will be written into field 532 at prompt 533, in this case "John". If the field called for the full name of the user, the user would highlight and select "Full Name" from menu 535 and, as an example, "John B. Smith" would be entered into the field. That is, the resident data value "John B. Smith" corresponds to the resident data element fullname embodied in object 412 of FIG. 4. hi this embodiment, the resident data entry system 300 is configured to combine data elements and values, when appropriate. The user continues to migrate through the input data fields, selecting a field and then selecting an item from pop-up menu 535 to input resident data, as needed. Once all relevant data is entered into the Web page, the user clicks on the Submit button 590 to place an order.

FIG. 5C shows user interface 500, similar to that of FIG. 5B, but wherein the resident data entry system is configured to generate a different pop-up menu. In this embodiment, pop-up menu 535' is comprised of a series of expandable lists. The expandable lists in this embodiment include Full Name, Home Add., Home Tel, and Home Net. As before, these menu items correspond to the subclasses of subclass homedata 480 of FIG. 4. By manipulating an arrowhead 541 proximate to a given list item, that list item can be selectively expanded and contracted by the user. For example, by mouse clicking on arrowhead 541, the subordinate sub- list items for item Full Name are made visible or hidden, i.e., the sub-list is expanded or contracted. These types of expandable lists are known in the art and not discussed in detail herein. The primary benefit of such expandable and contractible lists is that they allow a user to manage how much of the underlying window is occluded by a list, e.g., list 535'.

As previously discussed, the resident data entry system 300 may also be configured to analyze the code or tags associated with the input data entry fields of an application, Web page, or form to determine what data is to be entered by the user. In accordance with rules 320, the resident data entry system passes corresponding data element values (or pointers to the data elements) to the application, page or form. As a result, data element values from the resident data database 140 are written into the input data fields of the application as default values, as previously described. The capability to automatically write in default values is preferably provided as a companion to the operator selection and input capability described with respect to FIG. 5B through FIG. 5C. FIG. 5D relates to such an embodiment, wherein user interface 500 has had resident data written into input fields as default values by the resident data entry system. With the order summary section 510 already completed (as in FIG. 5 A), the user has selected a payment method in payment method section 530 by selecting the "Credit Card" radio button 538. Upon selection of Credit Card radio button 538, the user maybe prompted to input his name and the resident data entry system automatically writes default values into the fields for first name 532, middle initial 534, last name 536, in this case using "John B. Smith" from the previous example. If an object existed that contained such information, credit card type 540, credit card number 546, expiration date month 542, and year 544 would also be input as default data values. Otherwise, the user manually inputs these items. Assuming that the user has indicated to the resident data entry system that he is doing non-business related shopping, the resident data entry system 300 has only written default values into the home address section 550 of the Web page. This information includes the user's street address 552, city, state and zip code 554, home telephone number 556 and fax number 558, wherein John B. Smith's home address is: 12 Main Street, Boston, MA 99999. The resident data entry system has also written in the home e-mail address 560 (i.e., jsmith@anyISP.com) and home Web site address 562 (i.e., www.anyISP.com/jsmith) of the user. The business address section 570 remains blank. The user accepts the defaulted information by clicking "Submit" button 590. The user may edit any of the default data before clicking "Submit", as previously discussed. A B2B embodiment is described with respect to FIG. 6 through FIG. 11, which incorporates the same principles discussed with respect to the embodiment of FIG. 4 through FIG. 5D. In this embodiment, the object model is referred to as a W⁵ ™ object model (W⁵ is a trademark of Environmental Networks International, hie. of Newton, MA), or context space object model (CTXOM). As will be discussed below, "W⁵" refers to Who, What, Where, When and Why notions represented as contexts in these models. There are three basic concepts to be considered with respect to the CTXOM: context space, database, and documents. Context space is processed in conjunction with DB 140 of data values, to provide users with an efficient way to create and manage documents on a network. Using W⁵ contexts, documents may be prepared, manipulated, stored and transferred electronically and then, if desired, printed. Each document may represent or incorporate one or more concepts, such as a company datasheet, user profile, PR, RFP, PO, invoice, and other B2B e-commerce related documents, for example. In the preferred form, documents are created and managed by filling out on-line context-based forms embodying resident data elements, which facilitates the reviewing, editing or deleting of resident data values. hi the preferred form, each context, i.e., Who, What, Where, When, and Why, is defined within an executable file of a known type (e.g., XML). Contexts may be independent of each other or contained within other contexts, as a sub-context of a given parent context. As a way of establishing a relationship, a header of a sub-context file may contain a pointer to its parent context file. The header can also define a relationship to particular functions of an application related to a context related form. Additionally, a header can contain some general parameters, such as a link to a database, e.g., DB 140. Sub-contexts inherit parameters defined in the header of the parent context, however any parameter can be redefined in a sub-context. A context can refer to a data source (e.g., DB 140), wherein the reference can be defined as a standard SQL statement for a relational database, or as a reference to some alternative source of data (e.g., a third party system). A context file may contain data fields, wherein each data field within a context file represents a source of data values for a particular data element of a document. A data field definition may contain the following attributes: a) Field Name - a unique identifier of a given field b) Data Type - such as a string, number, date, image c) Data Reference - an expression to access value(s) from the data source d) Default Value - such as a single value or a list of values e) Field Type - type of visual (on-screen) representation of an element, such as an input box, text area, checkbox, radio button, or drop down list

As a general rule, there is no direct relationship between contexts and documents. Instead, one or more contexts can be applied to a document dynamically, i.e., at runtime. That is, some or all elements of such documents may be defined as references to context data fields. As a result, these elements are provided with suggested lists of values, or single values, that are obtained from the associated data fields of the corresponding contexts.

The CTXOM can be implemented in several different ways, either programmatically, or with appropriate middleware. The preferred implementation makes use of standard XML format for the definition of the contexts, as XML files. FIG. 6 illustrates an implementation 600 generally, as it can be applied to the a B2B e-commerce application. In this example, it is assumed that the user works with a set of standard documents 620, such documents may include RFPs, POs, PRs, company datasheets, invoices, and so on. The user may be required to create and prepare such documents repeatedly in the course of conducting business, often populating the documents with existing or resident data.

The documents are represented electronically and populated with resident data entered and reviewable through corresponding context related forms 610. The forms 610 can be implemented as Web pages using different known techniques. For example, forms 610 may include Who 612, What 614, WJiere 616, When 618, and Why 620 forms. The documents 620, in electronic form, may include RFP 621, PO 622, PR 623, invoice 624, and company datasheet 625. These documents may also be populated with other information from DB 650, such as format and standard document content information (e.g., often used clauses). Those skilled in the art will appreciate that these document types are provided for illustrative purposes only and are in no manner intended to limit the scope of the present invention. As an example, forms 610 may be implemented as active server pages (ASPs), which refer to the appropriate contexts 630 via engine 310, as shown in FIG. 6. hi this example, the contexts 630 include the Who, What, Where, When and Why contexts represented as the files who.xml 632, what.xml 634, where.xml 636, why.xml 638, and when.xml 640. Forms are rendered on display screens to provide a mechanism to input new resident data and to review and update existing resident data. When a form is completed with new resident data values, those values are stored in DB 140 through the execution of the appropriate context file 630. The resident data is populated into documents 620 by engine 310. The documents (and the forms) can be converted to a printable format, such as an Adobe PDF format by Adobe Systems, Inc. of San Jose, CA, and then printed as a hard copy, or sent electronically to a customer or provider. As an example, a Who context provides information related to the customer and/or provider of a given transaction. A Who context definition in XML format (i.e., who.xml) for use within a corresponding ASP is:

<?xml version="1.0" ?>

<who xmlns:dt="urn:schemas-microsoft-com:datatypes"> <ctxheader ctxname="WHO" ctxid="101" parentname="root" parentid="100" />

<ctxsource dstmt="SELECT"> <dsource>GUSER</dsource> <dfields> <df fname="fullname" fexpr="fullname" />

<df fname="firstname" fexpr="firstname" /> <df fname- 'lastname" fexpr="lastname" /> <df fname=" email" fexpr=" email" /> <df fname- 'phone" fexpr="phone" />

<df fname="phonext" fexpr="phonext" /> <df fhame="fax" fexρr="fax" />

<df fname=" address" fexpr=" ddress 1 + ' ' + address2" /> <df fhame="city" fexpr="city" /> <dffname="state" fexpr="state" />

<df fname- 'zipcode" fexpr="zip" /> <df fname- 'country" fexpr="country" /> </dfields>

<dfilter oρerator="OR"> <key ktype="number" kname- 'status" kvalue="l " />

</dfilter>

<dorder>ORDER BY fullname</dorder> </ctxsource> </who> Table 1 - Who.xml Definition

This XML file contains two top-level nodes with the names ctxheader and ctxsource. The first node represents a context header, and contains identification of the Who context and its position in the context space. The second node describes how this context provides data to the corresponding ASP. This node contains four sub-nodes with the names dsource, dfields, dfilter and dorder. Besides being a base for building the corresponding SQL statement to extract data from DB 140, these sub-nodes contain other sub-elements, technically called attributes and sub- nodes, that provide all information needed to supply data values to data elements in a document (e.g., RFP, PO) that will apply this context. Sub-nodes and attributes in any XML document can be nested indefinitely, as long as the document remains well-formed. The notion of being well-formed is extremely important to provide standardization of XML-based documents, and to the ability to understand and process the XML-based documents by many industry-standard engines, including database systems, Web browsers, communication software, and so on. That is, a well formed XML-based document is able to represent arbitrary hierarchical structures in a fully standardized manner. Consequently, it is possible to build complex context definitions, as needed by a particular application. Similar to the Who context, XML-based context files are also formed for the What, Where, When, and Wliy contexts. hi the preferred form, this context file is used within a context Web page to enter and review resident data. The following listing shows a fragment of Visual Basic (NB) Script code used in an ASP page that declares application of the Who context:

<% call ctxInit("WHO") call ctxAddField("fullname") call ctxAddField("firstname") call ctxAddField("lastname") call ctxAddField("email") call ctxAddField("phone") call ctxAddField("fax") call ctxAddField("address") call ctxAddField("city") call ctxAddField("state") call ctxAddField("ziρ") call ctxAddFilter("AΝD", "company", session("company"), "char") call ctxSelect("fullname", "John B. Smith") call ctxApply()

%>

Table 2 - Declaring Application Of Who Context In A Web Page

This code consists of a series of functions called from the Web page. As is shown in FIG. 6, the functions are directed to and executed by engine 310, which uses the context definitions 630 to extract a set of resident data values and to deliver the set to the calling Web page (i.e., forms

610). The first line of this code contains a call to initial function ctxInit("WHO") that initiates the process of applying the Who context. The last line contains a call to another base function ctxApplyO that completes this process. Between these two calls there are other lines of code with calls to additional functions. Some of these functions, such as ctxAddField("fullname") declare the use of particular field on the given page. Another function is ctxAddFilter("AND", "fullname", session("username"), "char"), which creates an additional custom filter. This filter is added to the standard context definition in such a way as to extend or reduce the set of values delivered from the context. Another function ctxSelect("fullname", "John B. Smith") is used to select an initial set of resident data values, hi this example the first set of values is bound to a person named "John B. Smith". As will be appreciated by those skilled in the art, there are other functions shown that can modify the behavior of the standard Who context.

Once the Web page has announced an application of the Who context, other aspects of the invention are involved in displaying the resident data values on the page and how those resident data values can be selected and modified by a user. Below is fragment of simplified HTML code corresponding to the Who Web page (see FIG. 7A and FIG. 7B), defining the layout of the corresponding fields on the Web page. <table> <tr> <td>Full Name</td>

<td><%call ctxField("fullname")%> <a href="#" onclick- 'myMenu.open();"

<img border="0" align- 'absmiddle" src- Vimages/selectarrow.gif' width- '12" height="20"></a </td>

</tr> <tr>

<td>Full Name</td>

<td><%call ctxField("firstname")%></td> </tr>

<tr>

<td>Full Name</td>

<td><%call ctxField("lastname")%x/td> </tr> </table>

Table 3 - HTML Code With Calls To Functions Implemented By Engine 310 This code contains a definition of a HTML table with three fields: fullname, firstname, lastname. Other fields can be presented in a similar way. What is important, is that these fields are defined by calling functions implemented by engine 310, such as ctxField("fulhιame"). As a result of this call, an input box is created and filled with the value obtained from the Who context. If an initial value is requested call ctxSelect("fullname", "John B. Smith") of Table 2 is executed and the corresponding field receives the requested value, and all other fields will obtain the related values.

FIG. 7A through FIG. 11 are representative Web-based screens of the preferred B2B embodiment, which are presented to a user for entry and review of resident data. These screens correspond to the five Who, What, Where, When, and Why contexts discussed above. Preferably, these screens allow a user to gather data necessary for preparing typical forms and documents, as is shown in FIG. 6. Each screen includes a set of hotlinks (e.g., hotlinks 710 of FIG. 7A) that allow a user to transition between screens for each context or to generate a "combined" screen that displays all contexts simultaneously, h most situations, all five screens are linked or related, so that a change in a field in one context screen causes corresponding changes in the other context screens.

FIG. 7A and FIG. 7B are representative Web-based display screens 700 related to the Who context, represented as form 612 in FIG. 6. Generally, the Who context and screen relate to the identification and contact information of a particular individual or organization. Who screen 700 includes a context identification label 702, for basic informational purposes. A set of fields, consistent with the files of Tables 1-3 above, are also included. A full name field 712, i.e., fullname field of Tables 1-3, allows entry of a person's full name. A first name field 714 and last name field 716 are also included. When the full name "John B. Smith" is entered in full name _, field 712, the first name "John" is automatically entered in first name field 714 and the last name "Smith" is automatically entered in last name field 716. An e-mail address field 718, telephone and fax number fields 720 and 722, and address fields 724 are also included. hi the preferred form, an entry in the full name field 712 causes all other fields of screen 700 to be dynamically populated, in accordance with the flow of FIG. 6. This entry may be accomplished by typing, copying, or otherwise manually entering an input into field 712. hi addition, there is a small image button 713 adjacent to the full name field 712, which is programmed to call myMenu.open() function (see Table 3) in such a way that upon a "click" a drop-down list containing alternative resident data values for this field is rendered. FIG. 7B shows Who context display screen 700 with image button 713 having been clicked and a drop down list 726 having been rendered. If the user selects a new value (i.e., other than current value "John B. Smith") from drop down list 726, all other fields on screen 700 will be dynamically filled with resident data values corresponding to the selected user. Also, "SANE" button 730 and "DELETE" button 732 may be included. SANE button 730 allows new resident data values or edits to existing resident data values to be saved to DB 140. DELETE button 732 allows resident data values to be deleted from DB 140. The ability to save new values, edit existing values, and delete existing values may require certain privileges not possessed by all users.

FIG. 8 is a representative screen 800 relating to the Wliat context. Generally, the What context and screen relate to identification and related information concerning a certain relationship or transaction. What screen 800 includes a context identification label 802, for basic informational purposes. A contract name field 812 identifies a transaction name. In this case, the transaction name is a "B2B Procurement", i.e., a business to business transaction. A button 813 is provided to allow a drop-down list to be rendered identifying a selectable list of contracts by name. Selecting a contract from the list causes all other fields in What screen 800 to be updated. Field 814 includes a contract number "Proj-001", associated with the contract name, as is customary in commercial settings. A contract type field 816 identifies contract number "Proj- 001" as a "Commercial" contract. A project site field 818 and a description field 820 are also provided. Project start and end date fields, 822 and 824, are included, along with a point of contact field 826 to identify, for example, a project manager "John B. Smith", which is the individual identified in the Who context screen 700 of FIG. 7A and FIG. 7B. An e-mail address field 828 and an office field 830 are also included for "John B. Smith". Where an organization has multiple offices, such as in Massachusetts, California, and New York, the office field 830 identifies the office of the contact person in field 826.

FIG. 9 is a representative J^Tzere screen 900 relating to the Where context. Generally, the Where context and screen provide information identifying a geographical location related to a project (i.e., "Business to Business Procurement Portal") identified in a project title field 912. Scroll buttons 911 allow a user to scroll through project title field 912, when the project title is so long as to not be fully displayed within field 912. Where screen 900 includes a context label 902, for basic informational purposes. Click button 913 allows a drop-down list of selectable project titles to be rendered within screen 900. Selection of a project title from the drop-down list causes all fields in this screen to be update with information corresponding to the selected project title. Address line fields 914, city field 916, state field 918 and zip code field 920 are also included to display the geographic location of interest. Other fields may also be included, such as a country field. The geographic location indicated in the Where screen 900 may display any relevant location, such as a location for delivery of goods, conduct of services, and so on. Additionally, in other embodiments, the Where screen 900 (or a set of such screens) may provide geographic information for a variety of locations related to the same project. FIG. 10 is a representative When screen 1000 relating to the Wlien context. Generally, the

When context and screen provide information identifying key dates related to a project identified in a project title field 1012. Scroll buttons 1011 allow a user to scroll through project title field 1012, when the project title is so long as to not be fully displayed within field 1012. In this case, project title "Business to Business Procurement Portal" has been maintained from its selection in the previous Where screen 900. When screen 1000 includes a context identification label 1002, for basic informational purposes. Click button 1013 allows a drop-down list of selectable project titles to be rendered within screen 1000. Selection of a project title from the drop-down list causes all fields in this screen to be update with information corresponding to the selected project title. A project start date field 1014 and an end date field 1016 are included. A proposal due date field 1018 is also included, which is particularly applicable during the source selection phase of a project (e.g., when several potential suppliers are responding to an RFP with the submission of a proposal), i this embodiment, a field 1020 for today's date is included, which is particularly useful for informing a user of a hard copy print out of this screen of the currency of the information on the print out. FIG. 11 is a representative Why screen 1100 relating to the Why context. Generally, the

Why context and screen provide information identifying key information and notes related to a project identified in a project title field 1112. Scroll buttons 1111 allow a user to scroll through project title field 1112, when the project title is so long as to not be fully displayed within field 1112. hi this case, project title "Business to Business Procurement Portal" has been maintained from its selection in the previous Where screen 900. Why screen 1100 includes a context identification label 1102, for basic informational purposes. Click button 1113 allows a dropdown list of selectable project titles to be rendered within screen 1100. Selection of a project title from the drop-down list causes all fields in this screen to be update with information corresponding to the selected project title. A description field 1114 provides the same information as provide in description field 820 of the What screen of FIG. 8, since tliese resident data values are related in DB 140 to the project title. Justification field 1116 provides a mechanism to enter and display information (e.g., "Need to upgrade Web presence ASAP!") concerning the underlying objective of the transaction or project. Notes to Approver field 1118, Notes to Buyer 1120, and Notes to Vendor field 1122 provide mechanisms to enter, display, and maintain important information to those key individuals or groups. An account field 1124 includes a mechanism for the display of a unique account identifier associated with the project title. Similarly, these fields present resident values linked to the project title, i this case the contract number "Proj-001" from field 814 of What screen 800 is used as the account number, but other identifiers could be used on other embodiments, particularly where there may be many contracts, projects or transactions associated with a given account.

The invention may be embodied in other specific forms without departing from the spirit or central characteristics thereof. For example, the resident data entry system may be selectively enabled and disabled by the user. Also, enabling of the resident data entry system may require login by the user, as a security measure. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by appending claims rather than by the foregoing description, and all changes that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

Claims

1. A resident data entry system comprising: A. a set of networked electronic devices; B. at least one memory coupled to said set of electronic devices; C. a program code executed on one or more of said set of electronic devices, said program code comprising: 1) a set of contexts and a set of data elements, wherein a subset of said data elements is associated with each of said contexts; 2) a user interface code configured to generate, for each context, a context display that includes input fields for the corresponding subset of data elements, wherein data entered into said input fields are stored as data values of said subset of data elements; 3) an engine configured to enter into the input fields of a selected context display a stored set of data values corresponding to the subset of data elements associated with said selected context.

2. The resident data entry system of claim 1, wherein said engine is configured to write at least some of said data values into at least one electronic document having a set of document input fields, as a function of a correlation between the document input fields and the set of data elements.

3. The resident data entry system of claim 2 wherein said at least one electronic document includes a plurality of electronic documents and one or more of said plurality of electronic documents is a request for proposal, purchase order, purchase requisition, invoice, or company datasheet.

4. The resident data entry system of claim 1 wherein said data values are stored with respect to a network account.

5. The resident data entry system of claim 1 wherein said electronic devices include wired and wireless devices, including one or more of a: 1) personal computer; 2) personal digital assistant; 3) application server; 4) cellular telephone; 5) workstation; or 6) terminal.

6. The resident data entry system of claim 1 wherein at least some of said electronic devices are networked via the Web and Internet.

7. The resident data entry system of claim 1 wherein said display screens are presented as Web browser forms.

8. The resident data entry system of claim 1 wherein said data elements include elements for entry of at least one of user-related data and business project data.

9. The resident data entry system of claim 1 wherein said contexts include one or more of a who context, a what context, a where context, a when context and a why context.

10. The resident data entry system of claim 1 wherein said engine is further configured to automatically enter said values into the input fields in response to a user interaction with one of said input fields.

11. A resident data entry system comprising: A. an electronic device including a display and an input mechanism, and having access to one or more applications configured to generate application files having input fields; B. a memory storage device coupled to said electronic device; C. a program code hosted on said electronic device and comprising: 1) a set of data elements; 2) interfaces to said applications; 3) a user interface code configured to generate at least one display on said electronic device having a set of data gathering fields corresponding to said data elements and configured to store in said memory data values entered into said data gathering fields and to associate said data values with corresponding ones of said data elements; 4) an engine configured to automatically export said data values to corresponding ones of said input fields of said application files.

12. The resident data entry system of claim 11 wherein said electronic device includes an interface to a network and said one or more applications includes a network based application.

13. The resident data entry system of claim 12, wherein said network is the Web.

14. The resident data entry system of claim 11 wherein said engine is configured to automatically analyze said application input fields and automatically write corresponding data values into said input data fields.

15. The resident data entry system of claim 11 wherein said user interface code is configured to selectively generate a menu of items associated with a window displaying an application file on said electronic device, wherein each menu item corresponds to at least one of said data elements, and wherein upon user selection of one of said menu items one or more corresponding of said data values are written into said input field.

16. The resident data entry system of claim 15 wherein said menu is generated in response to actuation of a hot key, mouse button, or an icon displayed on the screen of said electronic device.

17. The resident data entry system of claim 16 wherein said program code is configured to analyze entries into one or more of said application input fields and to store said entries as a one or more of said data values.

18. The resident data entry system of claim 11 wherein said data values are editable.

19. The resident data entry system of claim 11 wherein said set of data elements is user definable.

20. The resident data entry system of claim 11 wherein said set of data elements is a user- based set of data elements and said program code is configured to store a different set of data values for each of a plurality of users .

21. A method for writing resident data into a set of input fields of an application file, wherein said application file is hosted on one or more electronic devices having access to at least one memory having a set of data elements defined therein, said method including: A. storing in said memory a set of data values corresponding to said data elements; B. entering a first data value of said set of data values into a first input field of said set of input fields; C. in response to entry of said first data value, for a next input field of said set of input fields, automatically entering, if available in said memory, a next data value from said set of data values into said next input field; and D. repeating step C for substantially all of said set of input fields.

22. The method of claim 21 wherein said one or more electronic devices includes one or more of a: 1) personal computer; 2) personal digital assistant; 3) application server; 4) cellular telephone; 5) workstation; and 6) terminal.

23. The method of claim 21 wherein said one or more electronic devices includes an interface to the Web and said application file is generated by a Web-based application.

24. The method claim 21 wherein step C includes: 1) determining said next data value from said set of data values as a function of an application file code associated with said next input field; and 2) writing said next data value into said input field.

25. The method of claim 21 , wherein step A includes : 1) automatically reading said data values from data entered into a second set of input fields.

26. The method of claim 21 , wherein step B includes : 1) generating and displaying a menu of items, wherein each menu item corresponds to at least one of said data elements; 2) selecting a menu item associated with said first data value; and 3) in response to said selecting, retrieving said first data value from said memory.

27. The method of claim 21 wherein said application file is a document file.

28. The method for claim 21 wherein a plurality of contexts are defined in said memory and a subset of said data elements is associated with each context.

29. The method of claim 28 wherein said contexts include at least one of a who context, a what context, a where context, a when context, and a why context.

30. The method of claim 29, wherein step A includes: 1) for each context, generating a context user interface screen defining a set ' of resident data input fields corresponding to said subset of data elements; and 2) entering a corresponding set of data values into said resident data input fields.