Field of the Invention

[0001] This invention relates to methods and systems for providing to information relating to an identity (ID) candidate.

Background of the Invention

[0002] The identity of an ID candidate may conventionally be verified using a token, such as a card or badge, that is presented to an ID checker for verification. The token may carry a code, such as a barcode, that carries information about the ID candidate. The token may carry biometric data, such as a photograph of the ID candidate, so as to bind the token to the ID candidate. However, such conventional systems are prone to fraud, since the token may be stolen or counterfeited. They are also inflexible, in that the information they provide is static. Often, they are only designed for a single purpose.

[0003] Patent publication WO-A-2013/153355 (McKenzie) discloses a method of verifying permission to use a payment system, where the customer presents a communication device to a merchant, who extracts account information from the device, and sends a request for identification verification information to be sent to the device, or to an alternate display. The merchant can then compare the identification verification information to the customer to determine if the customer is authorised to use the account.

[0004] Patent publication US-A-2009 D106150 (eBay) discloses a system where an individual may prepare a token authorising a requesting party to obtain access to specified information associated with the individual. Summary of the Invention

[0005] According to one aspect of the present invention, there is provided a computer implemented method of providing candidate information, the method comprising: obtaining a challenge code from a verification service at a first device associated with an ID candidate; capturing the challenge code from the first device at a second device associated with an ID checker; verifying the challenge code between the second device and the verification service and, if the challenge code is verified, providing the candidate information from the verification service, such that the candidate information is accessible to the ID checker. Preferably, the information is provided securely from the verification service, which is trusted to provide reliable information.

[0006] Preferably, the challenge code does not contain candidate information pertaining to the ID candidate, so that candidate information cannot be obtained by the ID checker without reference to the verification service. This allows the verification service to determine the extent of information that can be provided, to authenticate ID checkers and to distinguish between ID checkers based on various criteria including degree of trustworthiness of the ID checker, value to verification service, etc.

[0007] In one embodiment, the candidate information is provided to the first device. In another embodiment, the candidate information is provided to the second device only after approval is provided from the first device. The first device may be informed of what candidate information is requested, and the identity and/or status of the ID checker, before giving approval. Either embodiment allows the ID candidate to control what information is released to the ID checker.

[0008] In some embodiments, the ID checker may specify, on the second device, what information is required. The specified information may be a binary or 'yes/no' check against a criterion specified by the ID checker. This provides a flexible ID verification service in which only the information that is needed may be requested and provided.

[0009] In some embodiments, a validation code may be provided to both the first and second devices, and may be displayed on both devices so that the identification process may be validated as genuine by the ID candidate or the ID checker. The validation code may include a graphical image, for ease of comparison between the two devices and/or to make the service more attractive.

[0010] There may be provided a mobile device, a mobile gateway, a system and associated computer programs arranged to carry out the above method. In particular, software applications on the mobile gateway, or the first or second device, which enable one or more of the above methods, are believed to be novel and inventive.

Brief Description of the Drawings

[0011] There now follows, by way of example only, a detailed description of embodiments of the present invention, with reference to the figures identified below.

Figure 1 is a block diagram showing the main components of an ID verification system according to embodiments of the invention.

Figure 2 is a diagram of an ID verification method in a first embodiment of the invention.

Figures 3a to 3h are screenshots from a mobile device of an ID checker in the first embodiment.

Figures 4a to 4e are screenshots from a mobile device of an ID candidate in the first embodiment.

Figure 5 is a diagram of an ID verification method in a second embodiment of the invention.

Figure 6 is a screenshot of an approval request on the mobile device of an ID candidate in the second embodiment.

Figure 7 is a screenshot of a candidate information display on the mobile device of an ID checker in the second embodiment.

Figure 8 is a diagram of a mobile device for use in embodiments of the invention.

Figure 9 is a diagram showing details of a computer system for use in embodiments of the invention.

Detailed Description of Embodiments of the Invention Technical Architecture

[0012] Referring to Figure 1, an ID verification system according to embodiments of the invention comprises a first wireless or mobile device 1 having an ID candidate application la, and a second wireless or mobile device 8 having an ID checker application 8a. The mobile devices 1, 8 communicate over a network 3, such as a wireless or mobile network and/or Internet with a mobile gateway 4, preferably using a secure protocol such as Secure Sockets Layer (SSL). The mobile gateway 4 provides a verification service to an I D checker relating to an ID candidate, as described in more detail below.

[0013] The mobile devices 1, 8 are of a type that is known per se, such as an iOS™, Blackberry™ or Android™ based smartphone, a 'feature' phone, a personal digital assistant (PDA), a tablet computer, or any processor-powered device with suitable input and display means. I n some embodiments, the mobile devices 1, 8 need not have a voice telephony function. In some embodiments, the device 8 need not be mobile, but may be a desktop computer or a point-of-sale (POS) terminal, for example. It is preferred that the mobile device 1 of the I D candidate is mobile, but in some embodiments this may not be essential.

[0014] I n a client-server version of the system, the devices 1, 8 may comprise clients and the mobile gateway 4 may comprise a server. Alternatively, the devices 1, 8 may comprise terminals in the network 3.

[0015] The network 3 may comprise a terrestrial cellular network such as a 2G, 3G or 4G network, a private or public wireless network such as a WiFi™-based network and/or a mobile satellite network or the Internet. It will be appreciated that a plurality of, and preferably a large number of mobile devices 1, 8 are operable concurrently within the system.

[0016] The mobile gateway 4 also has access to a database 7 including I D and registration data of ID candidates and, optionally, ID checkers. The candidate data may include personal data (such as name, date of birth), biometric data (such as photograph, fingerprint, iris scan), contact data (for example address, email address, telephone number), and social data (for example club membership number, Facebook profile data, previous transaction records). The candidate data for each ID candidate may be captured and verified during an ID candidate registration process, for example using official records, statements, or documents. Additionally, some data may be provided by the ID candidate without verification by the verification service and may be flagged as unverified, when stored on the database 7 and preferably when subsequently provided to an ID checker.

ID Candidate Registration

[0017] The ID candidate application la is preferably registered with the mobile gateway 4 during setup of the ID candidate application la on the mobile device 1, and is associated with the ID and registration data of an ID candidate. Registration may involve setting up one or more cryptographic keys for secure communication between the ID candidate application la and the mobile gateway 4. The key(s) may be generated from a passcode entered by the user during setup. The passcode may be a PIN, graphical passcode and/or biometric data such as a fingerprint or iris scan. The passcode may be modified by the user after setup.

[0018] In the specific embodiments described below, a user (i.e. the ID candidate or the ID checker) is required to enter the passcode as part of an authentication process. The passcode may be entered as a numeric or alphanumeric input, a graphical input such as a signature or gesture, or a biometric input. Preferably, the passcode is validated remotely, for example by generating a cryptographic key from the passcode, which key is used to sign a message sent to the mobile gateway 4 and/or a challenge sent by the mobile gateway 4. The mobile gateway 4 only responds as described in the embodiments below if the resulting signature is validated. If not, the mobile gateway 4 may prompt the application la, 8a to request the passcode again. The mobile gateway 4 may block access by the application la, 8a if it presents an invalid signature more than a predetermined number of times. In this way, the authentication process is made resistant to 'brute force' attacks.

[0019] Alternatively the passcode may be validated locally against a passcode stored in a local secure area of the mobile device 1, 8. If the passcode is validated, then the user application la, 8a is enabled to operate, for example as described in the specific embodiments below. This enablement may include access to locally stored cryptographic key(s) for secure communication with the mobile gateway 4. Introduction

[0020] The following embodiments involve an ID verification process in which an ID candidate is required to authorise provision of candidate information to an ID checker, by displaying a challenge code which is scanned by the ID checker and used to access the required candidate information via the mobile gateway 4.

[0021] The ID candidate may for example be requesting membership or entry to a club with a minimum age requirement. Therefore, the ID candidate is not necessarily required to provide full candidate information, but only the candidate information required by the ID checker. The information may be a simple 'yes/no' answer to an ID- related question posed by the ID checker, such as 'is the candidate over 18?', or may be specific information without reference to a question, such as the candidate's date of birth.

First Embodiment

[0022] Figures 2 and 3a to 3h illustrate a verification system and method in a first embodiment of the present invention. In this embodiment, the identity of the ID checker is not validated, so security measures are included which protect against the misuse of candidate data by the ID checker.

[0023] Before the ID verification process proceeds, the ID candidate downloads and registers the ID candidate application la to the first device la, and the ID checker downloads and registers the ID checker application 8a to the second device 8. The ID candidate application la and the ID checker application 8a may be discrete applications, or may be integrated within a mobile application having additional functionality, such as a mobile wallet or mobile merchant application respectively. However, the present invention is not limited to verification in the context of mobile payments. Instead of using the applications la, 8a, embodiments of the invention may be implemented in a generic application, such as a browser. Challenge code Verification

[0024] At step SI, the ID candidate is authenticated to the ID candidate application, for example by entering a PIN as illustrated in Figure 4a. The PIN may be verified as described above.

[0025] At step S2 the ID candidate application la sends a secure request for a challenge code, including a unique ID, to the mobile gateway 4. The unique ID preferably represents the specific instance of the ID candidate application, for example as set up during registration. Alternatively, the unique ID may be a code identifying the mobile device, such as an IMEI number.

[0026] The mobile gateway 4 generates a challenge code at step S3, for example using a hardware security module (HSM). The challenge code may be a reference code randomly or pseudo-randomly generated for each session, and preferably carries no information about the ID candidate. At step S4, the mobile gateway 4 stores the challenge code in a record in the database 7; the record or the challenge code itself may also include the device ID and validity information, such as an expiry time and/or a location of the ID candidate application la when sending the secure request.

[0027] At step S5, the mobile gateway 4 sends the challenge code over a secure connection to the ID candidate application la. At step S6, the ID candidate application la displays the challenge code in machine-readable form, as shown for example in Figure 4b. The machine-readable form may be a bar code or two-dimensional code, and is preferably a quick-response (QR) code, for example as defined in standard ISO/IEC 18004:2006. Other forms of machine-readable code may be used, such as machine-readable text, images and/or audio code.

[0028] The challenge code may be converted to the machine readable form by the mobile gateway 4 before sending to the ID candidate application la, or may be converted to machine readable form by the ID candidate application la. Alternatively or additionally, the challenge code may be displayed or otherwise output in human- readable form, so that the ID checker can manually enter the challenge code.

[0029] Before scanning the challenge code and sending the challenge code to the mobile gateway 4 for verification, the ID checker specifies what candidate data is to be verified; this may be specified for each session, but is preferably specified during registration and/or configuration of the ID checker application 8a, since the ID checker is likely to require the same specification for multiple candidates. The specification may be cached in the mobile gateway 4 to ease future re-use.

[0030] A sample specification process is illustrated in Figures 3b to 3d. As illustrated in Figure 3b, the ID checker application 8a presents to the ID checker a menu to select what type of information is required for the ID candidate, such as:

• whether an age requirement is met

• a membership number, such as a merchant membership number

· photo

• full name

• date of birth

• postal address

[0031] The ID checker makes a selection from the menu. For some menu options, such as the age requirement, a sub-menu is required to specify the requirement. For example, as shown in Figure 3c, the ID checker may select from a menu of age requirements, such as:

• below 12

• below 16

· over 16

• customised selection

In the case of the customised selection, the ID checker may select from a further menu, with the following options:

• is below...

· is over ...

and the specific age may be selected from a list of relevant ages.

The ID checker application 8a may allow the ID checker to specify combinations of information and/or criteria, such as 'Is the candidate over 18 and a UK citizen?' or 'Is the candidate under 18 and if so, what is their age?', for example by selecting multiple options from a menu or by using a natural language query. [0032] To begin an ID checking session, the ID checker application 8a prompts the ID checker to start scanning a challenge code, as shown in Figure 3e. At step S7, the ID checker captures the challenge code into the ID checker application 8a, using for example a camera or scanner 16 integrated with the mobile device 8. Alternatively, the challenge code may be read by the ID checker and manually entered into the ID checker application. Other means of capture may be used, depending on the form of the challenge code.

[0033] At step S8, the ID checker application 8a sends the scanned code and the unique ID to the mobile gateway 4. Validation, Provision of Information and Acknowledgement

[0034] At step S9, the mobile gateway 4 validates the scanned code, for example by checking against the challenge code previously stored in the database 7, or by verifying a digital signature within the scanned code. Validation may further include checking the validity of the scanned code, for example by checking whether the current time is before a specified expiry time, and/or by checking whether the scanned code is sent from a location in proximity to a specified location for the challenge code.

[0035] If the scanned code is verified, the mobile gateway 4 obtains the requested candidate information for the corresponding ID candidate and sends the requested information to the ID candidate application la, at step SlOa.

[0036] At step SlOb, the ID candidate application la displays the requested information, as shown for example in Figure 4c. The ID candidate can then decide whether or not to show the requested information to the ID checker, thus ensuring that the ID candidate retains control over the use of their information. If the ID candidate allows it, the ID checker reads the information from the ID candidate's device 1 at step 10c, and may then take whatever action is necessary based on that information.

[0037] Optionally, a digital photograph and/or biometric information of the ID candidate may be sent with the requested information and may be displayed with the requested information on the candidate device 1, so that the ID checker can confirm the identity of the candidate. The photograph and/or biometric information may be sent automatically, or only if requested by the ID checker.

[0038] Either party may wish to check that the verification process that has just taken place is genuine, and is therefore given the option of requesting a validation code, such as a one-time (OT) code, as shown in Figures 3f and 4d. If the screen of either of the mobile devices 1, 8 is tapped, a request is sent from the respective mobile device 1, 8 to the mobile gateway 4, at step SlOd. In response to the request, the mobile gateway 4 generates the validation code at step SlOe, and at step SlOf sends the same validation code for display by both the ID candidate application la and the ID checker application 8a. Alternatively, the validation code may be provided at an earlier stage, for example when providing the requested candidate information, without the need for a separate request.

[0039] The validation code may be displayed as a code and/or as graphical image, as shown in Figures 4d and 3g respectively. In this case, the graphical image comprises a line of differently coloured blocks, which can be easily compared visually between the two displays. Alternatively, as shown in Figures 4di and 3gi respectively, the coloured blocks may be displayed in a multi-dimensional configuration, such as a 3D and/or time-variant configuration. The individual blocks could be squares, circles or triangles, but preferably not a mixture of these, to avoid over-complexity. To assist colour-blind users, a code in the form of a numerical or alphanumeric text string may be displayed either inside the boxes, or outside the boxes, or optionally when a corresponding button is clicked. Alternatively or additionally, the validation code may be output as an audio (e.g. musical) and/or sensory (e.g. vibration) signal, for example to assist visually impaired users.

[0040] The ID candidate application la and the ID checker application 8a may give the option for the ID candidate and the ID checker respectively to repeatedly request a new validation code, which is displayed on both mobile devices 1, 8. Additionally or alternatively, the validation code may comprise an image randomly selected from a set of images accessed by the mobile gateway 4, as shown for example in Figures 4dii and 3gii respectively. At least some of the set of images may have been previously selected or provided by the ID candidate or the ID checker, so as to personalise the service. Further images may be requested and displayed on both mobile devices 1, 8, as illustrated for example in Figures 4diii and 3giii.

[0041] The ID checker compares the displayed validation codes and if satisfied that they match, may accept the candidate information as valid. Optionally, the ID checker may confirm the match in the ID checker application 8a, which then sends a confirmation message to the mobile gateway 4, at step SlOg. At step Sll, in response to the confirmation message, the mobile gateway 4 sends an acknowledgement message to the ID candidate application la and/or the ID checker application 8a, which may be displayed as shown for example in Figure 3h, 4e. The acknowledgement message may comprise an email, SMS or other message addressed using the registered contact details of the respective parties. The acknowledgement message may be used to confirm that the candidate information was accepted by the ID checker, and may contain a reference code that can be used for audit purposes. The acknowledgement message may also be sent even if the ID checker does not confirm the match, but may record the fact that no match was confirmed.

Second Embodiment

[0042] A second embodiment of the invention will now be described, as a variant of the first embodiment. Similar steps to those of the first embodiment use the same reference numerals, and their description is not repeated. Likewise, similar screenshots to those in the first embodiment are not repeated.

[0043] In the second embodiment, the ID checker is required to register the ID checker application 8a and the identity of the ID checker is verified by the verification service before the ID checker application can be used. The method of the second embodiment is therefore more secure than that of the first embodiment, and some security measures may therefore be omitted. Instead of sending the candidate information to the ID candidate, the ID candidate is asked to approve the specific candidate information requested by the ID checker, before this candidate information is sent to the ID checker. The display of matching validation code codes is also not required in the second embodiment. [0044] The verification process of the second embodiment, as shown in Figure 5, proceeds in a similar way to that of the first embodiment up to step S9, except that the ID checker is required to log in to the ID checker application, for example as shown at step lb before scanning the challenge code at step S7, and before specifying what candidate information is requested. As in the first embodiment, the specification may be configured during or after registration of ID checker application. Configuration of the specification may be locked, for example using a master passcode, to prevent misuse by unauthorised personnel. The specification may be cached to ease future re-use.

[0045] At step SlOi of the second embodiment, the mobile gateway 4 sends a message to the ID candidate application la, indicating what information has been requested and seeking approval from the ID candidate. For example, as shown in Figure 6, the message indicates that the full name, date of birth, and postal address of the ID candidate have been requested, together with the registered name of the ID checker ('ABC Gym' in this case). The ID candidate may select 'Yes' or 'No' to approve or disapprove this request, and a message indicating approval or disapproval is sent to the mobile gateway 4 at step SlOii. Where multiple items of information are requested, the candidate may individually approve or disapprove each item.

[0046] If disapproved altogether, the ID verification process is terminated and a message indicating disapproval may be sent by the mobile gateway 4 to the ID checker application 8a. If approved, the mobile gateway 4 obtains the requested and approved candidate information from the database 7 at step SlOiii, and at step SlOiv sends the requested information to the ID checker application 8a for display, as shown for example in Figure 7. The information may include a reference code.

[0047] At step Sll, the mobile gateway 4 sends acknowledgement messages to the ID checker application 8a and the ID candidate application la. These may be similar to the acknowledgement messages sent in step Sll in the first embodiment, and may include the reference code, for audit purposes.

[0048] In this embodiment, the requested information may be sent to the ID checker in an electronic format, either at step SlOiv or Sll. For example, verified Candidate information for one or more ID candidates may be sent to the ID checker for importing into a database.

Alternative Embodiments and Applications

[0049] In the above embodiments, a photograph or other biometric data of the ID candidate and/or the ID checker may be retrieved and provided as part of the verification process. Where biometric data of the ID candidate is provided, it may not be necessary to require the ID candidate to be authenticated with the mobile device 1, as the biometric data allows the identity of the ID candidate to be verified.

[0050] The challenge code may be passed from the ID candidate device 1 to the ID checker device 8 by means other than displaying and scanning a machine-readable code. For example, a short-range point-to-point wireless or radio-based communication technology such as Bluetooth, Near-Field Communication (NFC), UltraWideBand (UWB), WiFi Direct, or any P2P wireless and radio technologies that can have their transmission power lowered (such as 3G, 3.5G, 4G, WiFi, WiMax) may be used. Transfer of the challenge code over a wireless connection may be initiated by 'bumping' the devices 1, 8 together, or by selecting an option within the candidate application la or the checker application 8a.

[0051] Instead of passing the challenge code from the ID candidate device 1 to the checker device 8, the challenge code may be requested by the checker device 8 and passed to the candidate device 1. The challenge code sets up a session between the candidate device 1 and the checker device 8, regardless of the direction in which the challenge code passes.

[0052] In some applications, such as law-enforcement, the ID Checker may be enabled to override the ID candidate restrictions for certain ID attributes. For example, in a variant of the second embodiment, disapproval of certain items at step SlOb may be overridden at step 10c. In another variant, at step SlOb the ID Candidate could select an option to provide deliberately incorrect data or to render the service inoperable, for example for a given time, if the ID candidate is under duress. [0053] The verification service could be enhanced by providing a reputation score or rating as candidate information, and allowing the ID checker to add to the rating. For example, a tradesman (ID candidate) may assert that the last 20 business dealings were rated well by those customers (ID Checkers), with the verification service ensuring that the ratings come from registered ID checkers. Optionally, the verification service may provide to the current ID checker contact details of the previous ID checkers who provided a rating for the ID candidate and who gave permission for their contact details to be disclosed, [both parties could have reputation scores]

[0054] Instead of a dedicated ID checker or ID candidate application, a browser such as mobile web browser may be used. The candidate data may be sent to a mobile web page by sending a secure token with confirmed attributes to the web page, for example using Security Assertion Markup Language (SAML).

[0055] In a commerce environment, the verification service may be extended to allow the ID checker to provide details of goods or services to be paid for if the ID candidate meets the required identification criteria (e.g. over 18) and the ID candidate can elect to approve payment when approving the release of the ID data . The ID checker may be notified of payment made & optionally, delivery details provided by the verification service.

[0056] The above embodiments are described by way of example, and alternative embodiments which may become apparent to the skilled person on reading the above description may nevertheless fall within the scope of the claims.

Mobile Device Details

[0057] Figure 8 shows further details of one example of either of the mobile devices 1, 8 comprising at least a processor 10, including for example hardware and an application platform, running the application la, 8a, and connected to memory or other form of data storage facility such as flash drive 13 storing local data 14. The application platform may be a mobile operating system such as iOS™, Android™, Blackberry OS, Windows-based OS, or other embedded OS such as Open Embedded Build system, Symbian OS, Contiki, FreeBSD, and TinyOS. The application la, 8a may comprise program code, which can be loaded or downloaded onto the mobile device 1, 8.

[0058] The mobile device 1, 8 has a display 11 and a manual input device 12, which may be integrated with the display as a touchscreen, and/or provided as a keypad. An alternative or additional input device may be used, such as a trackball, trackpad, motion sensor or mouse. The mobile device 1, 8 may include or be connected to a camera or scanner 16 for capturing optical images and/or codes. The mobile device 1, 8 may include or be connected to a printer (not shown) for printing the challenge code, the candidate information, an acknowledgement and/or a receipts

[0059] The mobile device 1, 8 includes a network interface 15 to the network 3. The mobile device 1, 8 may also include an NFC interface 17.

Computer Details

[0060] The mobile gateway 4 may be implemented by computer systems such as computer system 1000 as shown in Figure 9. Embodiments of the present invention may be implemented as programmable code for execution by such computer systems 1000. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures.

[0061] Computer system 1000 includes one or more processors, such as processor 1004. Processor 1004 may be any type of processor, including but not limited to a special purpose or a general-purpose digital signal processor. Processor 1004 is connected to a communication infrastructure 1006 (for example, a bus or network). Various software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures.

[0062] Computer system 1000 also includes a main memory 1008, preferably random access memory (RAM), and may also include a secondary memory 610. Secondary memory 1010 may include, for example, a hard disk drive 1012 and/or a removable storage drive 1014, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. Removable storage drive 1014 reads from and/or writes to a removable storage unit 1018 in a well-known manner. Removable storage unit 1018 represents a floppy disk, magnetic tape, optical disk, etc., which is read by and written to by removable storage drive 1014. As will be appreciated, removable storage unit 618 includes a computer usable storage medium having stored therein computer software and/or data.

[0063] In alternative implementations, secondary memory 1010 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1000. Such means may include, for example, a removable storage unit 1022 and an interface 1020. Examples of such means may include a removable memory chip (such as an EPROM, or PROM, or flash memory) and associated socket, and other removable storage units 1022 and interfaces 1020 which allow software and data to be transferred from removable storage unit 1022 to computer system 1000. Alternatively, the program may be executed and/or the data accessed from the removable storage unit 1022, using the processor 1004 of the computer system 1000.

[0064] Computer system 1000 may also include a communication interface 1024. Communication interface 1024 allows software and data to be transferred between computer system 1000 and external devices. Examples of communication interface 1024 may include a modem, a network interface (such as an Ethernet card), a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communication interface 1024 are in the form of signals 1028, which may be electronic, electromagnetic, optical, or other signals capable of being received by communication interface 1024. These signals 1028 are provided to communication interface 1024 via a communication path 1026. Communication path 1026 carries signals 1028 and may be implemented using wire or cable, fibre optics, a phone line, a wireless link, a cellular phone link, a radio frequency link, or any other suitable communication channel. For instance, communication path 1026 may be implemented using a combination of channels. [0065] The terms "computer program medium" and "computer usable medium" are used generally to refer to media such as removable storage drive 1014, a hard disk installed in hard disk drive 1012, and signals 1028. These computer program products are means for providing software to computer system 1000. However, these terms may also include signals (such as electrical, optical or electromagnetic signals) that embody the computer program disclosed herein.

[0066] Computer programs (also called computer control logic) are stored in main memory 1008 and/or secondary memory 1010. Computer programs may also be received via communication interface 1024. Such computer programs, when executed, enable computer system 1000 to implement embodiments of the present invention as discussed herein. Accordingly, such computer programs represent controllers of computer system 1000. Where the embodiment is implemented using software, the software may be stored in a computer program product and loaded into computer system 1000 using removable storage drive 1014, hard disk drive 1012, or communication interface 1024, to provide some examples.

[0067] Alternative embodiments may be implemented as control logic in hardware, firmware, or software or any combination thereof.