Tracking Method and Apparatus

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright fights whatsoever.

1. Field of the Invention

The present invention relates to methods and apparatus for tracking personal and business information and specifically to computer software and hardware optimized for easy use in tracking information.

2. Description of the Related Art

The tracking of information occurs in many different fields and environments. For example, tracking is required for financial information, for mileage information, for inventory information and for many other purposes.

In the financial information field, computer programs, such as Quicken.RTM., Managing Your Money.TM., Microsoft Money.TM., or Simply Money.TM., help users to track financial transactions using a computer. These computer programs are designed to work the same way that users tend to manage their finances at a desk where bills are gathered and paid and where finances are otherwise kept in order. These programs satisfy the needs of users that enter batches of transactions serially for the same account.

By way of example and for batch processing of a checking account, users typically enter all check transactions for the account at one time. Transactions for other accounts tend to be entered at some other time. Computer programs designed for such batch processing use a multi-line "register" metaphor for data entry. With such a "register" metaphor, a user picks the account register, such as a checking account register, from a list of accounts and then remains in that account register to enter a series of account transactions. The user enters data for one transaction into one line of the multi-line register, saves it, and then returns to the next "line" in the register where the user enters the next transaction for the same account. The sequencing method is from line to line in a multi-line register for a single account. Such methods are optimized to allow users to select the account for a series of transactions and then enter each of the transactions for that account. Such methods frequently require a number of steps preceding selecting an account for any register entry and hence are not designed for easy switching between accounts.

While the register metaphor works well for desktop batch-entry of data, the register method of tracking data is burdensome where transactions are not entered in batches. In the mobile environment, for example, tracking based upon batch methods tends to be inefficient. Mobile devices such as DOS-based palmtop computers, for example, Hewlett-Packard HP95LX or HP100LX palmtop computers, can track finances using desktop financial programs with register metaphors that are cumbersome when ease of account switching is important.

In the mobile environment, users move frequently from one merchant to another and often switch from one type of payment instrument to another. For example, a user may use cash as the payment instrument for a cash account at a gas station, may use a check as the payment instrument for a checking account at a grocery store, and may use a credit card as the payment instrument for a charge account at a restaurant. In such a mobile environment, users need to track account transactions quickly and therefore need to switch quickly and easily between payment instruments or accounts.

In light of this background, there is a need for improved transaction tracking.

The present invention is a tracking method and apparatus for use with a computer including a processor for executing code, input/output devices for providing data, memory for storing account data and a display. In operation, a plurality of transaction images are displayed on the computer display. In response to selection of one of the transaction images, a corresponding entry sequence is executed. The execution causes a display of one or more entry fields for receiving transaction data in response to the execution of the entry sequence. The transaction data is entered in response to the entry sequence and the entry fields displayed. The transaction data entered is stored in an account store corresponding to the selected one of the transaction images. Each account has a plurality of fields for data. The entry fields presented by the entry sequence are only the ones necessary for the particular transaction as determined by the selected transaction image and the corresponding entry sequence.

In one embodiment, the present invention is a financial tracking method for a computer that includes a "Wallet", a representation of images of transaction instruments (such as credit cards, cash, checks or other payment instruments) displayed in a visual representation of a wallet, thereby using a wallet metaphor for tracking financial data. The images identify the accounts the user is tracking. For example, the "cash" image represents tracking a cash account; the "check" image represents tracking a checking account, and one or more "credit card" images represent tracking of one or more credit card accounts. Users may configure the "wallet" images to match the types and number of accounts to be tracked.

The wallet provides the ability to select from among wallet images to provide an easy method for selecting and switching between accounts, and this method is particularly useful in mobile and other single account transaction environments.

The selection of an image, in accordance with the present invention, also selects a predetermined transaction entry sequence by which transaction data is entered by the user. The transaction entry sequence automatically steps the user through a sequence to access one or more fields using only a preselected subset of the full set of fields associated with the account.

To record a transaction for a financial account, the user selects (with a pen-like device, stylus or other I/O input) an image of a transaction instrument corresponding to the account to be charged. The present invention then displays a visual representation of a "receipt" with transaction fields to enable entry of information for the transaction, such as the date, the amount of the expense, the merchant, a description of the expense, the category into which the expense falls (such as "clothing", "transportation" or "dining"), and, if the expense is a business transaction, which trip, client or project applies to the expense. Next, the "receipt", or more specifically the entered transaction information, is recorded in the account store. When done with a transaction, the computer program returns to the wallet display to again display the transaction images so that the user can repeat the process to record another transaction for the same or for another account.

The present invention makes it easy for users to record single transactions or small batches of transactions where there is frequent switching between accounts. The present invention uses a simple visual interface, such as a "wallet", that is easy to learn, easy to use, and easy to remember how to use, thereby making the entry of transaction data fast and simple.

The foregoing and other objects, features and advantages of the invention will be apparent from the following detailed description in conjunction with the drawings.

FIG. 1 depicts a block diagram of a personal digital assistant or other computer which stores tracking software in memory.

FIG. 2 is a block diagram representation of the tracking software of the present invention.

FIG. 3 depicts the operation of the present invention interactively with a point of sale (POS) terminal.

FIG. 4 depicts further details of the sequencing of the point of sale transaction of FIG. 3.

FIG. 5 depicts a screen representation of the wallet metaphor for displaying transaction images.

FIG. 6 depicts a screen representation of the "receipt" form for displaying transaction data entry fields.

FIG. 7 depicts a block diagram representation of a computer in combination with external devices.

In FIG. 1, a block diagram of a personal digital assistant or other computer 5 is shown for executing the tracking method of the present invention. The computer 5 of FIG. 1 includes a conventional processor 10, input/output (I/O) devices 11, memory 12 and display 13. The memory 12 stores the operating system 16 for the computer 5, executable computer software 14 which implements the tracking method of the present invention and includes the account store 15 where account transaction data is stored. Preferably the computer of FIG. 1 is a small lightweight portable hand-held computer.

FIG. 2 depicts a block diagram representation of the transaction software 14 executed by the FIG. 1 system. In FIG. 2, the transaction image display code 23 is, for example, the software which causes the display 13 of FIG. 1 to concurrently display a plurality of transaction images I1, I2, . . . , In. The transaction images are, for a financial transaction example, images of credit cards, cash, bank cards or other instruments that are useful for making or authorizing payment. Specifically, the transaction image I1 may be an image of a VISA card, the image I2 may be a check image that represents checks drawn against a bank checking account and the transaction image In may be an American Express card image. Any number of such transaction instruments may be depicted by the image display code 23 of FIG. 2. For each image displayed by the display code 23, a corresponding account exists under control of the transaction account store code 26. The store code 26 causes account data to be stored in the memory 12 of the computer of FIG. 1. In FIG. 2, the account codes AC1, AC2, . . . , ACn are part of store code 26 and correspond to the transaction images I1, I2, . . . , In, respectively. For each image I1, I2, . . . , In created by display code 23 there exists transaction entry sequence code ES1, ES2, . . . , ESn, respectively.

Similarly, for each of the transaction entry sequence codes ES1, ES2, . . . , ESn there exists one or more sequences of display fields under control of display code 25 including the display sequences S1, S2, . . . , Sn, respectively.

In FIG. 2, transaction selector code 21 exists for selecting one of the images I1, 12, . . . , In in FIG. 2. The selector code 21 is of the type that receives an I/O input from I/O devices 11 in the FIG. 1 system for selection of one of the images I1, 12, . . . , In. For example, a stylus, a pointer, a mouse, a voice activator, a keyboard, a network link, telephone link, a terminal, a host computer or any other user controllable input can be employed as an I/O device 11.

In a similar manner, the data entry code 22 of FIG. 2 is for receiving input from a numerical pad, keyboard or any other I/O device 11 of the FIG. 1 computer system.

The operation of the tracking as executed by the FIG. 2 code occurs as follows. When the computer system of FIG. 1 is turned on or is otherwise initialized, the tracking code 14 in the memory 12 of FIG. 1 automatically executes image code 23 to display the transaction images I1, 12, . . . , In of FIG. 2. In this mode, the display waits until a user through the transaction instrument selector code 21 (through an I/O device 11 of FIG. 1) selects one of the images I1, I2, . . . , In. The selected one of the images causes entry into one of the transaction sequence codes ES1, ES2, . . . , ESn which corresponds to the selected one of the images. Assuming that the 12 image is selected, the ES2 transaction entry sequence code is then executed. The transaction entry sequence code ES2 causes one or more transaction display fields (or sequences of fields) S2 to be displayed. Depending on the complexity of the transaction, the display field S2 may include different fields S2,1, S2,2, . . . , S2, M2, which is a total of M2 fields where M2 may be any integer. For simple transactions, M2 may be only one or other small number so that only a small subset of fields are sequenced for transaction entry. Upon display of a transaction display field by code 25, corresponding to the transaction entry sequence code 24, data entry code 22 is executed, to receive transaction data for the transaction. Upon execution of data entry code 22, the information is stored into the corresponding transaction accounts by store code 26. In the case of the 12 image selection, in the embodiment of FIG. 2, the entry sequence code ES2, the display field code S2, and the account store code AC2 are selected and executed.

In FIG. 2, the one-to-one correlation of the I, ES, S and AC codes is for convenience. In other embodiments, one or more of the modules ES, S and AC can be combined using standard programming techniques so that a one-to-one correlation among the I, ES, S and AC codes is not required.

In FIG. 3, a modification to the code of FIG. 2 is shown where the transaction data entry code 22 is expanded to access the transaction data directly from a point of sale (POS) computer. Such a POS terminal can be one of the I/O devices 11 of FIG. 1. The POS terminal may transfer data to the computer of FIG. 1 in any conventional manner.

In operation, upon display of the transaction form by the code 25, the transaction data entry code 22 tests, in test code 30, to determine if the transaction data is available from the POS terminal. If available, a yes output is directed to the entry code 31 for entering the transaction data directly into the form from the POS terminal. If the test code 30 determines that the transaction data is not available from the POS terminal, then a no output connects to the user transaction data entry code 32. The code 32 enters the data directly from the user using a user actuated I/O device 11 of FIG. 1. For either transaction data entry by the POS code 31 or the User code 32, the validity of the entered data is tested in the data valid test code 33. If the entered code is not detected as valid, then a no output returns control to the user input code 32 for entry or correction of entered data. If the entered data is valid, the data test code 33 passes control to the form saving code 34 which saves the data into the form. Thereafter, processing continues as previously described in FIG. 2 where the store transaction data code 26 stores the code into an appropriate one of the store accounts AC of FIG. 2.

The POS transaction data entry code 31 of FIG. 3 is shown in further detail in FIG. 4.

In FIG. 4, when the test code 30 of FIG. 3 has determined that a POS terminal is available for transaction data entry, the code of FIG. 4 is executed. In FIG. 4, the Need/Password code 41 checks to see if a password is needed. If yes, the send password code 42 provides the password. If the password or any other information requires decryption, the decryption code 43 executes the decryption. Next, the read amount code 44 reads the amount of the transaction. Next, the merchant present code 45 detects whether or not a merchant identifier is available and if yes, the read merchant code 46 provides the read merchant identifier. The Standard Industry Code (SIC) code 47 determines whether or not an SIC code is available. If so, the read SIC code 48 provides the SIC code. With the data entry as provided in FIG. 4, the store into form memory 49 code stores the data into the form for testing for validity by the test code 33 of FIG. 3.

The FIG. 4 embodiment is only one embodiment where certain predetermined fields associated with an account are automatically supplied through the entry sequencing. These automatic operations of FIG. 3 and FIG. 4 greatly simplify the operations required by a user.

The terms used in connection with transaction tracking are defined as follows:

Account

A store of transactions (together with accumulated totals and other information). Examples of accounts are financial accounts, inventory accounts, mileage accounts and category accounts. Examples of financial accounts are bank accounts, credit-card accounts (Visa, Master Card, gasoline company, American Express, and so on) cash accounts, brokerage accounts, loan accounts, and other asset or liability accounts. Examples of category accounts are clothing accounts, food accounts and restaurant accounts.

Transaction

An operation that identifies a transfer in connection with an account. A transaction typically has the following attributes, Date, Amount, Account, Type.

Financial Transaction

An operation that identifies an actual transfer of money in connection with a financial account. A financial transaction typically has the following attributes, Date, Amount, Account, Type (check, charge, payment, transfer, withdrawal, deposit, etc.) The following are typically optional attributes, Cleared Status (reconciled, uncleared), Category/Purpose, Merchant/Description, Memo and Business Expense.

Account Store

A store for storing multiple transactions for an account. Each transaction is typically for only one account. Each account has a balance or total, which is the sum of the amounts of the transactions in that account. Once recorded in the account store, each transaction can be subsequently edited or deleted.

Transaction Image

A display object having a visual representation (image) that is recognizable as a symbol for identifying a transaction, an account, an attribute of an account or other information relating to an account. The visual representations are displayed as icons, buttons, or other similar likenesses. Each transaction image is controllable by the user, that is, the user can select or create a custom image and can locate the image in the display. Selecting a transaction image activates a transaction entry sequence.

Examples of transaction images are transaction instruments and category images.

A transaction instrument is a transaction image that is recognizable as the physical means for enacting a financial transaction. Transaction instruments are likenesses of cash, credit cards, debit cards, checks, ATM cards and other instruments.

A category image is a transaction image that is recognizable as a category such as food, clothing, auto or business.

Wallet

Visual representation of Transaction Instrument images for one or more financial accounts on the same display. The images are selectable/configurable by the user. As an example, a "wallet" may include images for six credit cards, one check, and cash displayed in a visual representation of a wallet, thereby forming a wallet metaphor.

Transaction Entry Sequence

The data entry for a transaction is controlled by a transaction entry sequence whereby entry fields are displayed via a screen form, window, dialog or other display field using any I/O device such as a keyboard, touchscreen, pen, stylus, mouse, voice, an external device such as a point of sale (POS) terminal, network link, telephone link, host computer or any other device that inputs data to each field displayed in sequence. The sequence of display fields is a function of account type as selected by the transaction image. For each transaction image, there is a display sequence of the fields with appropriate attributes, and associated prompts, corresponding to the transaction. As an example, a check image or form has a "check number" field together with "date" and "amount" fields. The charge image form (for credit/debit cards) has a "merchant" field together with "date" and "amount" fields. Some forms share attributes with other forms, but typically as a minimum all forms have "amount" (quantity) and "date".

Entering Transaction Data

1) Select transaction image from wallet;

2) If >1 account for this image (e.g. check transaction image), choose relevant account from the possible/available accounts. Any approach is valid, such as last-used, first-in, list alphabetically, or configurable by user

3) Select appropriate form, based on account type and transaction image.

4) Initialize with default values as a function of account type and transaction image.

5) Accept user inputs

6) Upon confirmation, enter transaction into transaction store.

Viewing

The process of performing calculations and logic to display information about transactions in an account and balances and other information about the account. A view may be for any single transaction showing all the information that was originally entered. Optionally, a view may list other information such as the reconciled balance, the total of all transactions that have been marked as reconciled. Optionally, a view may list transactions or totals of transactions for some or all accounts. Optionally, a view may list transactions or totals of transactions grouped by an attribute, such as category.

Examples of viewing operations that are performable with the computer and software include the following:

Viewing Account Balances

1) Query account store for a list of accounts

2) For each account, compute balance as follows:

where a.sub.i =mount of transaction i in the account of n transactions

3) Display accounts and balances in appropriate format, as tabular data, fist of icons and associated amounts, etc.

Viewing Transaction Lists

For each account or any other attribute, the wallet can display the transactions it comprises in a list on-screen or in printed form.

1) Choose the account or other attribute to list

2) Build transaction fist as follows: ##STR1## 3) Display/pit transactions from preceding list Editing Transaction Data

1) View transaction list

2) Select transaction to edit

3) Using type and account as entered in the transaction store, choose appropriate form

4) Display form, with same values as entered in transaction store.

5) Accept user inputs

6) Upon confirmation, reenter transaction into transaction store.

Deleting Transaction Data

1) View transaction list

2) Select transaction to delete

3) Using type and account as entered in transaction store, choose appropriate form.

4) Display form, with same values as entered in transaction store

5) Accept delete command

6) Upon confirmation, delete transaction from transaction store.

--OR--

1) View transaction list

2) Select transaction to delete

3) Accept delete command

4) Upon confirmation, delete transaction from transaction store.

Wallet Metaphor--FIG. 5

One example of the wallet metaphor is shown in FIG. 5. On the left side of FIG. 5 transaction instruments of the I1, 12, . . . , In type in FIG. 2 are shown in a wallet metaphor. In the wallet metaphor the images shown are for a Great Western (GW) checking account where the transaction instrument is a representation of a check, a Citibank account where the transaction instrument is a representation of a VISA card, and an AMEX account where the transaction instrument is a representation of an AMEX card, a cash account where the transaction instrument is a representation of a $1 bill, another money account where the transaction instrument is a representation of a $1 bill and a Master Card account where the transaction instrument is a representation of a Master Card. In operation, in order to select a transaction with the GW checking account, a stylus or other selection instrument is used to probe the check transaction instrument which appears in the upper left hand corner of the wallet metaphor. With such a selection of the check transaction instrument, the receipt of FIG. 6 is displayed.

In FIG. 6, a receipt having display fields is shown. In the receipt of FIG. 6, only the "$" field, the "Pay To" field and the "Memo" field are sequenced in order for entry of the transaction data. The "Chk No." field and the "Date" field (May 10, 1994) are automatically fried in typically without need for user operation.

In FIG. 7, the computer 5 of FIG. 1 is shown with the additional inclusion of an external device, such as a point of sale terminal, interface 38 or device 37, such as a host computer. The interface 38 is for connecting to the device, such as point of sale terminal, 39 for the purpose of exchanging information between computer 5 and device 39. Such connection may be through wireless transmission or through any other convenient way of transferring information.

One example of a computer code listing for the tracking of FIG. 2 is included in the CODE LISTING below. In the CODE LISTING, the elements 21, 22, 23, 24, 25, and 26 of FIG. 2 are identified in greater detail as follows:

Element 21--TX Image Selector

In the wallet display, transaction images I1, 12, . . . , In are set up for display by the function MSG.sub.-- ADD.sub.-- ACCOUNT.sub.-- CARDS by code element 23 of FIG. 2. This function sets up objects with images and associated transaction forms. When the transaction images are touched or otherwise selected, the operating system (OS), in response to the I/O sense module's detection of an input, calls the specified function, MSG.sub.-- REQUEST.sub.-- OPEN.sub.-- ACCOUNT. This function in response to the selected transaction image calls MSG.sub.-- SELECT.sub.-- NEW.sub.-- TRANSACTION to get the appropriate transaction slip, which comprises the corresponding one of the Transaction Entry Sequences (24) and the corresponding one or ones of the Transaction Display Fields (25). The operating system 16 of FIG. 1 includes a module for sensing I/O inputs from I/O devices 11.

Element 22--TX Data Entry

The entry sequence presents some or all of the attributes a transaction may have, as appropriate for the selected transaction. For each attribute, them is a set of user interface elements, that constitute a display field, that respond to input to receive the associated attribute's value. Typically, the entry sequence defines the data entry fields, then retrieves the values at the end of the sequence. Each form has a function MSG.sub.-- TRANSACTION.sub.-- FORM.sub.-- INITIALIZE (translip1.goc, translip2.goc, tforms1.goc, check2.goc, receipt.goc, bankslip1.goc, bankslip2.goc), which links the user elements for each attribute including the I/O device 11 elements and the display 13 elements. MSG.sub.-- SETUP.sub.-- PICKERS (tforms1.goc) attaches icon-based pickers for each attribute (for example, "checking" and "misc" in FIG. 6), as appropriate, operating system code responds to mouse, pen, keyboard, or other input to operate the user elements including I/O devices 11 and display 13 of FIG. 1. The pickers receive a message from the system when an item is selected, MSG.sub.-- PICK.sub.-- ICON, which calls the picker's selection handler, such as MSG.sub.-- USE.sub.-- PAYEE for the payee picker, or MSG.sub.-- USE.sub.-- MONEYBAG for accounts and categories. The amount editor is a system-provided module for modifying or entering "amount" data. The date picker is a module for modifying the "date" data. The "Memo" field uses a system provided module to receive text input from the system as well.

Element 23--Transaction Image Display

The operating system has conventional routines for drawing bitmapped images. These images are selected when the wallet screen is loaded, based on which accounts and transaction images are available. This setup is done by MSG.sub.-- ADD.sub.-- ACCOUNT.sub.-- CARDS and GetCreditCard-Bitmap. The call to MSG.sub.-- ADD.sub.-- NAMED.sub.-- ICON sets up the images for display. MSG.sub.-- VIS.sub.-- DRAW actually draws them using system calls.

Element 24--Transaction Entry Sequences

The first step is to set up the transaction data structure, via MSG.sub.-- TRANSACTION.sub.-- INITIALIZE (transact.gh, translip1.goc, translip2.goc, transact1.goc). Then, the transaction display fields of the form are set up via MSG.sub.-- TRANSACTION.sub.-- FORM.sub.-- INITIALIZE, which sets up the user interface on the form. The values in the display fields are initialized by MSG.sub.-- FILL.sub.-- SLIP (translip1.goc, translip2.goc, tforms1.goc, check1.goc), which sets up each attribute, e. g. MSG.sub.-- FILL.sub.-- DATE (tforms1.goc), MSG.sub.-- FILL.sub.-- AMOUNT (tforms1.goc). MSG.sub.-- FILL.sub.-- PAYEE (tforms1.goc). The transaction entry sequence is defined by the layout and selection of transaction display fields on the form. MSG.sub.-- SETUP.sub.-- PICKERS also defines the user interface, as described above. Within the pickers, MSG.sub.-- INITIALIZE sets up the picker. When the user hits the save command, MSG.sub.-- SAVE.sub.-- SLIP (tforms2.goc) is called to gather data from the display fields using the functions MSG.sub.-- STUFF.sub.-- . . . (tforms2.goc) (MSG.sub.-- STUFF.sub.-- SLIP.sub.-- DATE (tforms2.goc), MSG.sub.-- STUFF.sub.-- SLIP.sub.-- AMOUNT (tforms2.goc), MSG.sub.-- STUFF.sub.-- SLIP.sub.-- PICKER.sub.-- ITEMS (fforms2.goc), MSG.sub.-- STUFF.sub.-- SLIP.sub.-- PAYEE (tforms2.goc)), etc. Finally, to save the transaction into the account store, MSG.sub.-- SAVE.sub.-- TO.sub.-- LIST (transact.gh, tforms2.goc, transact2.goc) invokes the storing code.

Element 25--Transaction Display Fields

Each display field is an instance of an object supported by the operating system. For each display field, the code links a bitmap (drawn by MSG.sub.-- VIS.sub.-- DRAW) or text string to be drawn and retrieves strings for each display field to be drawn. The following functions retrieve strings for display, MSG.sub.-- GET.sub.-- AMOUNT.sub.-- STRING (transact.gh), MSG.sub.-- GET.sub.-- DATE.sub.-- STRING (transact.gh), MSG.sub.-- GET.sub.-- PAYEE.sub.-- STRING (transact.gh), MSG.sub.-- GET.sub.-- TYPE.sub.-- STRING (transact.gh), MSG.sub.-- GET.sub.-- MEMO.sub.-- STRING.

Within the pickers, the icons are drawn using MSG.sub.-- VIS.sub.-- DRAW. The icons are set up by MSG.sub.-- INITIALIZE.sub.-- ACCOUNT.sub.-- ICONS, MSG.sub.-- INITIALIZE.sub.-- INCOME.sub.-- ICONS, MSG.sub.-- INITIALIZE.sub.-- EXPENSE.sub.-- ICONS. MSG.sub.-- DISPLAY.sub.-- PAYEE.sub.-- LINE draws each line of text in the payee picker screen.

Element 26--Transaction Account Store

MSG.sub.-- SAVE.sub.-- TO.sub.-- LIST (transact.gh, tforms2.goc, transact2.goc) is the main function for storing transaction data. MSG.sub.-- ADD.sub.-- TRANSACTION and MSG.sub.-- REPLACE.sub.-- TRANSACTION save a new/replace existing transaction, respectively. These functions use standard indexed file methods. ##SPC1##

While the invention has been particularly shown and described with reference to preferred embodiments thereof it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention.