WO2002045034A2 - Transaction execution system and method with user proxy and middleware - Google Patents

Abstract

A transaction execution system has a plurality of member institutions, a number of transaction execution machines (TEMs), and a processing and routing system with translator to connect and process information between the member institutions and the TEMs. Each of the TEMs contains an identification device, a user interface and optionally a material device. When a customer uses one of the TEMs, the user interface is subsequently modified behave as though it were connected directly to all of the functionalities desired to be used by the user at one or more institutions, regardless of transport protocol, authorization protocol or other transaction automation system elements for the duration of the customer's transaction or provides the user the ability to conduct transaction involving accounts held at more than one institution.

Description

TRANSACTION EXECUTION SYSTEM AND METHOD WITH USER PROXY AND MIDDLEWARE

. The present invention relates to transaction execution systems.

BACKGROUND OF THE INVENTION

Automated Transaction Execution Systems, Generally

Banks and similar financial institutions have used automated teller machines, otherwise known as ATMs, for many years as transaction execution machines. Initially, each traditional institution installed its own ATMs ("captive ATMs") at bank branches and later at other locations. These captive ATMs initially varied in level of functionality, but over time evolved to provide more services at lower costs, greater convenience, and greater access to the customers. The services typically offered by captive ATMs include cash withdrawals, limited transfers between some customer accounts, the ability to deposit items of value such as cash or cheques, and checking of account balances in accordance to the generating parameters of a single financial institution. One disadvantage of this ATM system is that each institution has only a limited number of physical ATM locations with which to service a broad customer base. Another is the limited transaction set available.

Institutions have also begun to use captive ATMs to obtain data on customer habits, and to customize the behavior or options offered by a captive ATM based on how the institution wishes to treat a selected customer group or specific customer. A key to offering these value- added and /or differentiating services has been the ability of the traditional financial institutional to control the behavior of the captive ATMs used by its customers. The control is typically accomplished by the financial institution owning and /or operating, and defining many or all aspects of the logic, presentation, communications, performance, appearance, electronic transactions, paper transactions, cash type, denominations, and many other aspects of the captive ATM operation. The disadvantage of this system is the limited coverage of a customer base, dependent on the number and location of the ATMs, with the associated costs of establishing and maintaining a network of captive ATMs.

Transactions on "Foreign" Machines

As ATM usage grew, certain traditional institutions saw advantages in providing their customers with access to additional ATMs not owned by themselves. Regional or national consortia were created amongst cooperating traditional institutions, as well as amongst independent providers, to provide user access to each other's ATMs by their respective customers. Because of the need for technical simplicity and compatibility, these cooperative ventures tended to be based on the lowest common denominator of ATM capability, typically cash withdrawal from one or a limited number of generically defined account types, typically "savings" and "chequing". Additional features included balance inquiry and/or inter-account transfers for similar generically defined accounts. Examples of these consortia are "Interac", "Visa Plus Network", "MasterCard Cirrus Network", and "Star /Honor" systems. These particular networks were primarily interested in the basic functionality of cash withdrawal in local currency, by using internationally recognized credit or bank cards in a large number of locations. Unfortunately, the full complement of transactions ordinarily provided by captive ATMs are not typically accessible by customers using ATMs not owned by a customer's institution. Another disadvantage of the consortium branch system is that ATMs are always driven by one "host" institution, by which the transactions provided to customers of other "guest" institutions are controlled. Accordingly, this ownership model may not give "guest" institutions adequate control on how the captive ATMs provide services to their customers.

"White Label" Suppliers

As the usage of ATMs grew and the networks used to exchange ATM transaction information between traditional institutions became more widely accessible, so an opportunity arose for ATMs not owned by any single financial institution, commonly known in the industry as "White Label" ATMs. White Label ATMs were attractive to retail merchants and similar enterprises, because customers able to withdraw cash on a merchant's premises would be more likely to enter the premises and or spend more money while on the premises if a cash withdrawal were made or available. One disadvantage is that these White Label ATMs have only a limited functionality, even as compared to captive ATMs controlled by single institutions.

Presently in the art, there is a proliferation of limited service ATMs. Full service is only available from captive ATMs, controlled by the traditional institution issuing the access means such as a transaction card. These "full services" do not access more than the Customer's home institution's transaction functionality. Very limited services at White Label ATMs are available at a very large number of other locations by means of the many interconnected financial transaction networks. "Virtual Banking"

While the importance and numbers of both full service or captive ATMs, ATM consortia, and White Label ATMs have been growing, the importance and desirability of traditional bricks-and-mortar bank branches has been declining. New "virtual" banks have been created that are based on a very limited traditional branch network, sometimes with no physical branch network at all. These virtual banks typically use the Internet, a telephone call center, and/or a telephone interactive voice response system to conduct transactions with their customers. However, for any transaction requiring physical interaction between the virtual banks and their customers, such as the withdrawal of cash, the virtual banks have had to rely on the general ATM network. The access of virtual institutions to the established ATM network is through the lowest common denominator functionality, which is owned by traditional institution competitors, or by White Label ATM providers and/or operators. These virtual banks would like to position themselves as leaders in technology, convenience, and low cost transactions, but existing access to current networks' ATM is restricted in terms of the transaction types permitted to customers of "foreign" institutions. These available transaction types are typically fixed by the operator of the network by which the ATM is controlled. Furthermore, there is very little in the way of providing these virtual banks with any control over the interface during their customers' interaction with existing systems. The virtual banks have to rely on the visual presentation and transaction capabilities provided by a general ATM network or a captive ATM's controlling institution.

For additional transaction types, such as the issuance of a certified cheque, or the deposit of funds via cheque or other negotiable paper instruments, the virtual institution is typically restricted to using the post mail system, or using the premises or facilities of another more traditional bank. Examples of this practice are PC Financial offering additional transaction types through CIBC terminals, and MBanx making similar arrangements available through the terminals of the Bank of Montreal. This procedure can be costly, cumbersome, and slow compared to the service level such virtual banks wish to provide, and which their customers expect. These virtual banks are able to control the remote interface and interaction with their customers when dealing with the customers by telephone or by the internet, but must subject their customers to the image and advertising of competing traditional institutions when their customers use the ATMs controlled by a single traditional institution. When their customers use White Label ATMs, those customers are typically provided with less functionality, such as cash withdrawal, and with no opportunity available to those institutions to control presentation of the transaction with those customers. "Web-based" Remote Banking

In the recent past, traditional financial institutions have begun to offer remote banking services to customers, both individual and corporate, by telecommunications means. In particular, a limited variety of information and transaction sets may be accessed by computer via web browser. Such transactions cannot, of course, include the physical delivery (in either direction) of items of value such as cheques or money, and typically include such transactions as:

-account queries (balances, recent and historical transaction statements)

-inter-account transfers

-loan application, processing, authorization and funding (to specific user accounts) -loan and bill payment

Financial institutions have used computer communications for many years to connect with their retail customers, both individuals and businesses and are now providing these and more added services to a broader number of their customers via added web-based channels. While some have suggested that the importance of the ATM channel may decline with the increasing prevalence of other channels (including banking via devices such as internet banking, graphically through wireless PDAs, and by voice or graphically through cell phones) financial institutions continue to show an interest in providing services through this channel. Indeed, many financial institutions and ATM manufacturers and software developers have continued to invest in making new services available through the ATM channel. Often this is proposed to be done through a 'web-enabled' ATM, where the ATM supports traditional financial functions in a conventional way, and offers additional functions through some other more flexible interface.

While traditional ATM transactions are commonly supported in existing financial transaction networks, and these networks provide defined and well-understood interfaces to the back-end computer systems of financial institutions, enabling new transactions and transaction types on an ATM typically requires either extending the capability of these interfaces or creating new interfaces to a financial institution's back-end banking systems. Both approaches typically require significant time and money, making it difficult for financial institutions to take advantage of the increasing capabilities of the ATM channel.

By enabling such web-based banking and financial transaction services, the financial institutions provide a second limited subset of functions, which may partially overlap the functions provided by the legacy or inter-bank "consortia" financial transaction systems (such as "interac", see above). These newer web-browser-accessible transactions and services are typically provided by the financial institution putting up various web-pages which tie to the particular institution's internal back-office and database management systems.

For now, we will use the term "TEM" to refer to a Transaction Execution Machine, which is any machine on which or through the operation of which, a transaction can be executed with an institution. An ATM, for example, is a TEM (but a TEM may not be an ATM, since, for example, a browser-configured computer capable of performing web-based banking, would also be a TEM).

Existing Approaches to Service Expansion

One approach to expand system capabilities has been to use the traditional, existing interface between the TEM, network and financial institution for existing transactions, and simply connecting the 'web-enabled' capability of the TEM to a financial institution's web site. The TEM may be connected to the same web site as used by the bank's customers using the web banking site conventionally, or to a special web site or server that provides pages for display that are more suited to the display capabilities and other user interface elements of the TEM, and which may be different from those normally used by a consumer at a web banking site over the web. Using an existing web site does not use the unique capabilities, yet is subject to the limitations of the ATM channel, while creating a special web site duplicates effort in creating and maintaining similar web sites, and thus this approach is complex and inefficient.

Another approach has been to create special interfaces to back-end banking systems, either directly, (typically necessitating many complex interfaces to older, less flexible, poorly understood legacy systems), or alternatively through one or more application servers that a financial institution may use to exchange data between its web server and the back-end systems. This approach is not only costly and time consuming, but also often requires extensive access to very limited key resources within the institution with expertise in legacy systems or other unique bank infrastructure.

This invention takes a conceptually different approach, described below, to address these and other shortcomings in prior methodologies. SPECIFIC DISCUSSION OF THE PRIOR ART

Preliminary Discussion of Prior Art

There seem to be three logical segments of prior art in this area. One is typified by the

Citicorp and Citibank, and the continuations-in-part the Diebold family of patents and applications (see below) having to do with web-enabled ATMs handling proprietary or legacy communications protocols such as ISO8583 or Diebold 911/912 ™, or other state-based and secure transaction-controlling protocols. The other has to do with database management systems which use user profiles to locate and display information from a variety of databases (this might be called "meta search" or "personalization" methods). The third area of interest seems to be the translation of information from one format to another for useful display and interaction purposes, and here might be included recent (late 1999) commercial services such as "i-web", "phone.com", and some Palm Pilot (™) applications which allow the browsing of certain classes of conventional web-pages and sites by cell-phone or PDA using a much less rich display and processing technology on the user's browsing machine (for example, a cell-phone's or a PDA's mono-chrome or grey scale small screen and on-board processor rather than the desk-top or lap-top computer the web-page or site was designed for).

In the web-enabled ATM arena, there are a variety of translator means whereby communications to and from legacy banking or financial institution transaction systems can be correlated and transposed, on the fly during a transaction or transaction set with a user, by a modern, programmable, computer-based TEM such that the display and interface component of the TEM is functionally worked as a web-enabled browser or similarly operated interface and the legacy transaction system receives and sends data in form and format, sequence and type, that conform to expected legacy transaction protocols, while a part of the TEM provides the essential translations. Of course, in such a system, the communications will of necessity be only as "rich" as the least common denominator of the two sets of functions (user interface or legacy system enablement). Additionally, There is a great deal of difficulty technically in matching or correcting web-based and legacy based transaction components to function adequately, as expected by both bank, system, and user, or at all.

In the computer meta-search engines and other similar user-profile-driven information- gathering and displaying systems, information about a user is obtained and kept, and then used for purposes of customizing or personalizing search terms and results filters to search multiple databases and provide personalized reports, tailored to the user's profile of interest. Some examples are: US5819284, to provide a custom newspaper/screensaver from data from disparate databases on a scheduled basis to provide custom news reports or sports reports to a user; see also 4745559 which describes the same kind of thing (custom reports on a subscription sort of basis) in higher level terms. Of course, the meta-searching of multiple databases is useful in providing reports, and would be interesting in the TEM realm to provide reports compiled from personalized searches of a variety of source databases, such as searches of a variety of bank-provided web-pages or query-answering portals for account information (transaction history, balances, etc) for a number of user accounts (and perhaps across more than one financial institution), but the subset of currently available information would not be adequate to fulfill expectations of either customers or providers of TEM and ATM -based services. For instance, there would be no interactivity with the bank's web-based banking pages (only query and report), and there is no mechanism for dispensing or accepting cash or instruments of value at the TEM and accounting therefore.

In the "intermodal" interface translation arena, the main goals are to provide as much of a conventional web-page's utility (display, information, interactivity, and other features) to a user of the web-page (or site or similar thing) when access (and communication) is by way of a different mode or device or platform than the web-page was designed to accommodate. An example of such a service might be Gadgetspace Inc.'s "Mobilemediary" ™ software middleware system, which essentially handles the translation of communications between a user's platform and a provider's web-page to enable that user to access as many features of that web-page as that user's platform can display. Translation may include more than stripping of graphics or revision of page command language and formatting instructions, but can also include, as an example,, the replacement of a drop-down menu (useful on a conventional computer display but not useful on a cell-phone's display) into a numbered "pick list" useful and operable on a cellphone display and keyboard (a very limited interface set).

The following specific references to prior patent art are inserted to show both "state of the art" and to explain the technical area of interest to perceive a fuller discussion of the operation, concept and advantages of this invention.

Citicorp US Patent No. 5,933,816 entitled "System and Method for Delivering Financial Services"

US Patent No. 5,933,816 ('816) by Citicorp Development Center, Inc. relates to the provision with a single banking institution's many international branches of location-specific and customer-specific interfaces. Generally, the '816 patent teaches a delivery system for financial services capable of providing uniformity across the various remote devices which might be used to access a single bank's system in a variety of locales, in a way that the customer is presented with a consistent and familiar interface. These interfaces are provided by re- useable segmented scalable computer coding means, rules based upon locale of bank branch or customer (relating to banking regulations, currency denominations, rules with respect to deposits and withdrawals limits, and the like), and rules based upon local language with the ability to interconnect ATMs and other transaction devices (including legacy systems) to a variety of the single bank's computers in a variety of different locales to provide a growing variety of financial services to the bank's customers. By providing re-usable common application code bases for remote devices, the '816 proposes to decrease time-to-implement, testing time, and errors. These teachings provide a modular software approach to support a variety of computing devices with interfaces with which the single bank's customer has some familiarity. The Citibank's method is single-bank-centric and its inventive software enablement is conceptually different.

Discussion of Diebold, Incorporated Family of HTML-Enabled ATM Systems

There is some discussion in the prior art, in particular within a family of ATM applications made by Diebold ( Canadian Patent Nos. 2,271,209 /210 /212-216 /218-220 /222- 224 /394 and 686) which is useful. The disclosures of these patents teach integrating legacy captive ATM systems into a modern network of ATM and similar transaction machines operating over TCP/IP. These systems provide means of interacting with legacy driver computer systems and legacy ATMs interposing a translation system between the legacy and the modern elements of the network. These applications provide a user-centric system for incorporation into legacy or traditional captive ATM systems to provide for personalization of the user experience with a single institution.

Legacy or traditional captive ATM systems operate on the basis of a network of ATM machines which are made to behave like dumb terminals with attached peripherals and sensors, connected to a driver computer which controls the presentation, transaction logic and sequence, peripheral functionality, and transaction authorizations, and records ATM activity for later accounting purposes. Typically, such captive systems utilize proprietary communications languages and tecliniques such as Diebold 911/912. One disadvantage with this system is that typically no institution other than the single ATM controlling institution has any direct control over the ATM, and communications with so-called foreign institutions are done through a transaction protocol previously agreed to. These almost always follow a paradigm of "request/response" in a sequential manner, with a multiplicity of small communications in the captive ATM's intranet and between the ATM driver computer and the foreign institution. The subject matter of these transactions deal only with the financial aspects of the transactions, and not with the look and feel of the interface between the customer and the ATM during the transaction, nor with any ability to repurpose or take advantage of the institution's web-based systems. The protocols, languages, and the structure of the system impose many of the limitations in cross-institutional functionality as discussed above.

In one disclosure (Diebold '218), the legacy ATM driver computer issues and receives instructions and information in proprietary format. An http server machine is interposed between the legacy driver computer and the target ATM (which is a web-enabled ATM), and the interposed server machine incorporates a database lookup translation means and communicates translated driver computer information and instructions to the web-enabled ATM over http. In another variant (Diebold '224), a legacy-enabled ATM receives and transmits information via legacy protocols in formats designed to be accepted and acted upon from a legacy driver computer, and responsive thereto. The ATM refers to a further http server to obtain graphical user interface elements particular to that user and from there to that user's preferences. In Diebold '686 there is reference to an HTML-enabled ATM in operative connection with a "home http server", which takes the place of the legacy driver computer and provides connection with the home institution's back-office operations or with "foreign" institutions.

However, in all Diebold information management systems provided, the ATM obtains the user identity, goes to a user-related home address to pull information with respect to the user and the user's preferences, and provides a user-centric, personalized interface and logic at the ATM during the user's transaction session. These Diebold systems focus on providing a user-centric interface which has similar cross-institutional functionality deficiencies as discussed above, pertaining to bank-centric models. In addition, these Diebold systems uses a large number of user information "pages" and "addresses", which can generate a great deal of traffic over the network, which typically requires relatively large amounts of secure and accessible storage to accomplish, and as well could result in difficulties providing institution- specific branding where there may be multiple institutions related somehow to one user identity and address. Additionally, there are no flexible, multi-institutional, mixed web-and legacy-accomplished transactions or transaction systems contemplated.

Additionally, in the Bank-centric and user-centric models discussed above, a user is usually only provided with means of dealing with one institution at a time on an ATM, which does not address performing inter-institutional transactions by a customer. The above systems may provide these transactions as a part of the single ATM-controlling institution's functionality, but this is limited to its captive ATMs. The provision throughout the Diebold descriptions of user-centric data and communications models have numerous disadvantages, which include the need to keep a large number of addresses and volume of information current, accessible, and secure within the system in order that the user-centric locations are useful. Additionally, the systems disclosed are "chatty" and require a large number of inter-component communications steps that could be problematic on low-bandwidth or high-latency communications links or processing machines. As well, the paradigm of user-centricity may provide for personalization of certain transaction types but limit the utility of the entire system.

CITIBANK US PATENT NO. 5,963,647

US Patent No. 5,963,647 by Citibank Development Center, Inc. teaches a method and system of transferring funds from a bank account to an anonymous individual. These funds are transferred from the account to a cash access file accessible by use of a set of securely provided codes, which may then be used at any (enabled) ATM to obtain cash (in the source or the recipient's local currency) securely and anonymously. This system provides accounting at the time of cash withdrawal, as well as status enquiries, and cancellation/repudiation. One disadvantage with this system is that cross-institutional functionality, during the same transaction session, is not provided. Furthermore, fund transfers between accounts must be accomplished through an extra intermediate account, and do not reference the user's identity. There is no mention or contemplation of multi-institution or multi-format communication in background through middleware.

It is apparent from the above that there is a need for a transaction execution system that enables financial institutions to provide branded ATM services to their customers with a broad geographic coverage, which may not be economically feasible or technically possible without sharing the implementation costs of the ATM deployment amongst a number of institutions for any but the largest institutions. There is also a disadvantage of prior ATM systems arising from the limited number of full service ATM locations available to any one financial institution.

ATMs not part of any particular "captive ATM network", such as "White Label" ATMs, cannot provide the "full service" capability available on a captive system ATM to a member institution's customers. This situation is undesirable and less than optimal for operators of non- captive ATMs, since fewer transactions and fewer transaction types can be conducted at their terminals, thus reducing their utility and derived revenue.

There is a need to provide to "virtual banks" a means of interacting with their customers by issuing and receiving physical value items (such as coupons, bank drafts, certification process, deposits) as well as their more usual "electronic banking by PC or phone" services at a multiplicity of ATM locations . It is apparent from the prior art and practice that there is limited cross-institutional functionality in any ATM which limitations are dictated by the structure of the traditional ATM network and inter-network consortia systems of operation (e.g. Interac's hobbled sub-set of transaction types) and the protocols and paradigms they employ.

It is an object of this invention to provide a transaction execution system, method, apparatus and business method, in which the above shortcomings and disadvantages are obviated or mitigated, or in which the above-described needs are addressed.

SUMMARY OF THE INVENTION

In no case, except perhaps in the "intermodal" interface translation arena and then only amongst variants of SGML or page-description methods (such as HTML and variants to run handheld devices), do any of the prior art methods found combine information in middleware from various differing types of sources responsive to user profile information using automatic "user proxies" in software, configured to transact series of communications relatively simultaneously to effect, in a transparent way, a desired transaction on several different banking systems. This invention aims to do (at least) that.

With respect to the "intermodal" interface translation arena, we don't think the producers of the translators ever thought of using the system in this way. There were always two sides, a web site and a device. They were frequently interfacing to bank web sites (though as far as we know always with the banks' co-operation, but this may not have been universally true), so the difference is on the device side - ATM instead of PDA. There are a couple of pretty important differences.

First, the intermodal translator providers don't deal with the unique security aspects of traditional ATMs. That is, they never anticipated the secure handling of PINs and IDs - they were really just 'clipping' both the content and the transaction down to the limited capabilities of the device they were targeting. In our case, the device probably has as many (or more) capabilities than the web site would (for example, in ours the ATM could include an audio interface that was not present on the PDA or anticipated on the web site, but we would still be able to make it part of the transaction.

Second, our initial implementation was to use the 'clipped' web pages from the intermodal species of translating middleware directly on the ATM. While this worked after a fashion, there were: (1) latency issues since whole frames or screens were being served up (and where they weren't serving up much to a PDA, since the transaction was being stripped down to the PDA screen and capabilities, they were having to serve up much more to the typical web-enabled ATM); and

(2) content matching issues (of the type best characterized as paradigm differences) where instead of the ATM being in control of the transaction as it is under our model (and is not under the legacy 911/912 type models), the intermodal middleware had states and really wanted to treat the ATM as only a browser (that, as a PDA browser would not, did not have states either).

This does not fit the transaction-oriented behaviour of an ATM, and it is difficult to present to the user a transaction that looks identical to one that would not have gone through the web.

What we found was that we really had to use XML (or our proprietary extensions on 8583 data messages) to communicate the pure transaction request/response data with the Intelligent Router (or "IR", which is our name for the translator piece of this invention), and that an agent on the IR would then communicate with the intermodal translator systems.

Finally, there was the issue that what the intermodal systems sent to our system wasn't necessarily in the graphical format the FI wanted - we have gone to some lengths to ensure that the institution can completely control the customer experience just with the ATM content - when it was served by intermodal middleware direct to the ATM screen, then the content would have to be updated and synchronized in two places.

What this shows is that the pure intermodal web-type presentation from the middleware directly to the user screen on the ATM does not work as well as a system that recognizes:

(1) the ATM is still in control of the screens and screen logic, not the middleware;

(2) ideally the transaction from the ATM is stripped down to its essentials so that the request and response only contain transaction data, not graphical elements, and is more efficient; (3) the graphical elements are all determined at the ATM, not by the middleware, which only provides the rawest and cleanest of transaction data; (4) the GS model doesn't anticipate or easily accommodate the most accepted means of identification at the ATM (card and PIN); and, (5) (where supported by the institution, because it does require some accommodation on the web site) intermodal systems tend to use a session-based approach with a single login (even a single login for every transaction, but driving a whole series of screens at the FI to accomplish it, where in the critical transaction step(s) our invention can provide an atomic transaction that includes the ID and PIN as part of the request (perhaps the equivalent of filling out a web- based form with card, PIN (encrypted according to industry standard practice as elsewhere described), and transaction details.

Hence the middleware is being used to create a transaction interface that looks a lot like an 8583 type message interface that has a lot more capability in terms of transaction types for use with an intelligent ATM, not a clipped down web site suitable for a dumb terminal PDA. The technology is similar (just adds one layer onto intermodal translator systems), but the actual purpose and application is quite novel and unexpected.

A. New Approach

A better approach is to use the financial institution investments that have already been made in both web banking sites and existing financial transaction network connectivity, combining these with a new approach to create a flexible, low cost, quickly implemented interface to proprietary, public or shared ATM channels with the further benefit that minimizes dependence on scarce resources with legacy systems knowledge.

This invention uses one or more TEMs that have the capability of providing at least one non-traditional transaction type (that is not typically supported by existing financial transaction networks, and generally lying outside the scope of ISO 8583 transaction standard messages), a financial transaction network (whether owned and operated by a bank or another party), and at least one financial institution with a web site of a type that may be used for consumer web banking. For any transaction that can be supported by the existing network, such as cash withdrawals, account to account transfers and similar transactions dependent upon the capabilities of the network, the ATM may communicate with the financial institution via the existing or "legacy" network. Typically this is only required for cash withdraw requests that depend on a wider transaction and business infrastructure to settle that makes using a new and different message system and business infrastructure less attractive, or for deposits or withdrawals of physical things of value. Note that dispensing and receipting physical items of value are types of transactions not capable of performance exclusively within a user's own personal computer, or in fact, at other than a dispense/receipt equipped ATM. This does not, however, preclude the dispensing of things of value which are informational or capable of being produced at a non-ATM site such as by printing of a ticket with special coding or "loading" a smart card or other item with data which permits recognition of value through data interchange elsewhere or later, or the exchange of information as a part of a series of steps to arrange for the dispense or receipt of value (such as the Paypal.com ™ scenario or the American Express ™ anonymous and remote cash transfer systems being deployed in the early 21^s' century).

For other transactions, especially all types other than cash withdraw requests, whether of a type supported by existing networks or of an entirely new type or purpose, but of a type that is or can be supported by the bank's web-banking site, the TEM communicates with a middleware piece (called here a "translator" or the "systems", which includes by this definition, the translator), and the translator communicates with one or more public or private web sites that can present bank information to customers, and /or obtain information for the bank from the customers, and/or permit customers to conduct some forms of transactions. The translator includes the capability to accept and forward data for collection, a request from the TEM for data from one or more of the web sites, or a request from the TEM for a transaction involving one or more of the web sites. The translator has sufficient information through configuration or other information supplied regarding the web site or sites, or alternatively the additional or alternative capability to search, parse or otherwise determine the necessary approach to optionally log in or otherwise identify the user to all needed web-sites, (the customer at the TEM), optionally activate the correct sequence of web screens to send the data to the financial institution, obtain required information from the financial institution, and /or initiate a transaction with the institution.

In one embodiment, the translator and system includes in addition to the previously described capability, or as an alternative to that capability, the capability for one or more of the financial institution web sites and /or the translator to optionally recognize one or a group or segment of customers or an individual customer, and initiate a transmission of data or a request for a transaction from the financial institution to the TEM, whether or not the customer would have had the capability, the intention or the desire to obtain the data or initiate the transaction.

In another version of the invention, the customer is known to one or more of the web sites with which the TEM interacts. For example, the customer may have a conventional web login, token, biometric identification or other means, or a combination thereof, useful to identify and authenticate the users to the web site using a terminal connected to a network which is or is similar to the world wide web or a more restricted intranet. All, or alternatively a subset or superset, of the information sent to or obtained from the web site or sites, or transactions available via conventional login to the site. The ability to do the translation of a user's identity from a tradition ATM identifier (card plus PIN) to the logins necessary for the web site(s) is key.

There are at least two variants:

(1) the card/Pin (or other similar indicia including biometric etc. that could be used in future) ID is verified and used to unlock the logins /passwords to get to the site(s). (In a sub-variant, these IDs could be different from the IDs normally used by the cardholder when accessing the site through a traditional computer, enabling the FI within its existing infrastructure to differentiate whether it was a transaction at a computer or at an ATM - this could be important in billing the cardholder differently depending on the channel that was used for the transaction. Further, the cardholder might never know what these IDs and passwords were, which would allow a bank to use the system for ATM access, but still prevent a cardholder from using the FI's web site directly (say in the case where the FI charged separately for web access); and

(2) the user supplies the login information as part of the ATM session directly. For example, the 'login ID' could be the card number, a portion of the card number, or the card number plus some other non-human-readable information from the card (card issue number, expiry, etc.), or a combination, and the PIN number could be the password. [There is another important variant here, as the PIN is typically encrypted within the keypad and the unencrypted PIN is not available for transmission to a web site as a login. However, this invention includes a system where the so-called 'security zone' that normally exists between the ATM and the switch authorizing cash withdraw transactions is preserved - the Intelligent Router intercepts a message containing a request that will go to the web site, and the IR is able to access the same encryption unit normally used by the switch (they are all part of the same network infrastructure on the switch provider's premises normally), and the encryption unit includes one new master key for each required security zone from the switch to the participating institutions (or translator centers, where they are operated separately from the switch). The IR is therefore able to get the PIN translated using existing and well-accepted security measures into a new security zone set up for other non- cash transactions. Whether or not the PIN is used as a web-site login, the encrypted PIN could be sent along with the message(s) to the FI's back end systems (through the web site), and verified as part of the transaction sequence. The advantage of this approach is that it makes these transactions 'atomic' for the bank's web site in the same way cash withdraw transactions are atomic - the security information rides with each transaction request, and is verified with each request - there is no 'open door' left by someone having once logged in and created a session where everything is possible.

In another version, the translator accesses more than one web site, where each one of at least two web sites is from a related institution or business. In still another, the translator accesses more than one web site, where each one of at least two web sites is from an unrelated institution or business. In a further version, the customer accesses financial data via a conventional transaction with an institution or institutions, while one or more web sites are used to present, modify, transact or gather data, and are from another institution or another entity with whom the customer could interact on a data or transactional basis via networks such as the public web or private intranet, and even though the institution and other entity are separate to a greater or lesser degree, the experience of the customer is such that the available data, requested data, and /or transactions proposed appear to be integrated, substantially integrated or otherwise related.

In a further embodiment, the system through the middleware component includes all the capabilities and advantages that XML or other self-defining data path or communications definition might provide, whether using XML from the TEM to translator, translator to web site or financial institution, or both.

In another embodiment relating to business processes, the translator is operated by part of the financial transaction network, eliminating the need for the institution to own or rent the translator, and optionally eliminating any need for the financial institution to change or maintain the configuration of the translator to obtain or place the necessary information from or to the web site as the web site is changed by or on behalf of the financial institution. The translator may service multiple device types, multiple device owners, multiple financial transaction networks, and multiple financial institutions. Further, the system may include links to related or other web sites of potential interest to the user or the displays of which are useful to the institution, such as news sites, to get automatically updated attractor screens, or retail web sites to give retailers on whose premises the TEMs may be located some of the advertising advantages financial institutions conventionally enjoy. Finally, it may also be used by third parties that wish to easily and quickly use the ATM channel and don't want to invest in a costly interface to their back-end systems - if a customer can do it on the web, they can do it at a TEM connected to this system, with translator. The above arrangements generally assume that the system is created by, or for the benefit, or with the co-operation, of one or more financial institutions. It is to be understood that the translator and at least one or more of the available interactions can exist and be accomplished without the explicit permission, or even co-operation, of the financial institution. The customer gets the benefit of some or all of available 'web banking' services via the TEM together with traditional financial transactions, through the middleware's 'stand-in' or 'proxy' functionality in background

The invention thus encompasses situations where a consumers' own TEM usage is paid for directly by the customer, or partly or completely by some other third party such as an advertiser or the TEM's owner or merchant on whose premises the TEM is located, and may be done in combination with other services being offered by one or more of their financial institutions that may be partly or completely paid for by those financial institutions or any of them.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features of the preferred embodiments of the invention will become more apparent in the following detailed description in which reference is made to the appended drawings wherein:

Figure 1 is a schematic of a dynamically branded transaction execution system;

Figure 2 is a transaction execution machine (TEM) of Figure 1;

Figure 3 is a user interface of the TEM of Figure 2; Figure 4 is an alternative embodiment of Figure 1;

Figure 5 is an alternative embodiment of Figure 1;

Figure 6 is an alternative embodiment of Figure 1;

Figure 7 is a schematic representation of a TEM display of Figure 2 emulating hardwired buttons; and Figure 8 is a representation of a screen-shot during a macro-account transaction using the system of Figure 1.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Requirements for translator in system to operate in a multi-institution, multi-network transaction system according to this invention:

(a) at least one "legacy" system, most likely the TEM-owning institution or an Electronic Funds Transfer system (such as an "Authorizing Authority"), if such system is required to effect the transaction set proposed by the user at the TEM (now, for example, to deal with physical things of value such as money dispenses or deposits);

(b) at least one web-based banking system (which could be operated by or for any institution) and as many as is required to effect the transaction series proposed by the user at the TEM;

(c) one account which is accessible by each of those two systems, if the middleware "translator" is to accomplish a transaction between two systems which could not be accomplished on either system acting alone:

-for other cases, such as making multiple enquiries and transactions during a single session, but where the transactions and enquiries are not related, no common account is required and the translator can accomplish the transactions proposed without reliance upon a relationship between one system and another during a session;

-as well, a transaction series across multiple accounts may be accomplished using translator means where at least one account is accessible by both of two such systems and a second account is accessible across one of such systems and a third system, and the end-result of the transaction series which is desired is effected between the first account on the first system and the third account on the third system (which is not directly related to the first, but only related to the second system).

-It can be seen that the "chain" of related accounts may extend beyond two or three systems, provided there is a link between systems which can be utilized.

Typically, a EFT system operator will require the user to be both identified and authenticated using card or other indicia and PIN or other security device.

Typically, a web-based system will require the user to be both identified (userid) and authenticated (password).

(The transaction series required to execute the transaction proposed by the user, of course, requires identification and authentication of the user, and that might be the only step requiring transaction with a legacy system. Alternatively, a legacy system may be required to access two accounts in a chain of transactions without being required to dispense or accept deposit of articles of value) .

Preferredly, the provision of identification (card) and authentication (PIN) indicia to the TEM can be used to automatically cause the middleware to provide the identification (userid) and authentication (password) to the web-based banking systems and, if required, identification (card number or mag-stripe contents) and authentication (PIN) required by other legacy systems required to accomplish the transaction series proposed by the user at the TEM. This might be accomplished by: 5

1. the user could pre-enroll with the middleware (or at a data store accessible to the middleware) so that the middleware could using one identification and authentication pair obtain access to and use of the other identification / authentication information;

.0

2. an institution providing a transaction system, whether web-based or legacy, could accept the identification/ authentication pieces provided at the TEM by the user as a suitable substitute for its usual identification/authentication means;

15 3. the middleware could pass through to the user system requests for user identification and authentication during a transaction series and capture same during the transactions, and either:

-store the same in a user database of identities, identification and authentication information, and external systems for later reuse; or _0 -not store the same, providing no re-usable convenience;

4. an institution could permit the middleware to access the institution's user databases to seek identification and authentication information respecting the user accessing the TEM based upon information provided by that user to the

15 TEM (such as cross-referencing a credit card number from a mag-card at the

TEM to the card-issuing bank's database which is capable of finding that user's web-based banking identity and accounts by using that card number), and permitting the middleware to then use the found data to identify and authenticate the transactions required with that institution's legacy or web-based

30 systems as part of the user's proposed transaction series.

Overlapping or common "accounts" in this system may include ordinary customer- accessible institutional accounts, but may also include inter-system clearing mechanisms such as electronic bill-paying and transfer accounts operated under Canadian Payment Systems or 5 similar funds transfer or clearing systems permitting inter-system transfers and settlements.

When a user proposes a transaction which requires a series of sub-transactions amongst more than one system due to the lack of capability within a single system to effect the transaction (such as between account Al at system A and account B2 at system B, where system A has accounts Al and A2, and system B has accounts B3 and B2, and where accounts A2 and B2 are the same account), there may be more than one series of interac account transactions which might have the same net effect as the transaction proposed by the user (for example a transaction between accounts Al and C4 where the accounts within the accessible systems (A, B, and C) are Al, A2, B2, B3, C2, C3, and C4, with B2, C2, and A2 are the same account, and B3, C3 are the same account, two series possible to effect a Al to C4 transaction are: Al to B2 to B3 to C3 to C4 or Al to C2 to C4. The translator may use any method of selecting a transaction series to effect the proposed transaction desired by the user, and may do so automatically responsive to pre-set or programmed optimum-seeking parameters or by presenting choices to the user, or by any combination of those methods.

It should be apparent that this system may include more than one transaction system provided by a single institution (for example a legacy-based cash dispense and a web-based banking funds transfer), or may include a single system operated by a consortium of institutions, and so is not necessarily limited by the number of institutions or systems in its various embodiments.

In order to practice this invention, first is deployed a computer system comprising processor(s), memory, storage, and suitable inputs and outputs connected to a network which is connected to a TEM and to at least one institution's web-banking systems or legacy financial authorization system, but more typically to at least one of each type of system, and which execution system, including translator, may reside at any point in said network (including in the network standing alone, in the TEM, in the financial system's web-servers, in the financial system's legacy or back-end systems, or distributed amongst those places) and having system and applications software programmed to function as set out below.

Said system is configured with software which is capable of performing the following tasks: -accepting input from a user, for example by keyboard, camera, microphone, card-reader, touch-screen or any combination of conventional or unconventional means, as relayed to the system from the TEM's interface.

-utilizing said information to accept instructions from the user to perform a financial transaction (which may be part of a series of transactions in one or more sessions), which transaction may be a transaction which could not ordinarily be performed using either the financial institution's legacy transaction system or the financial system's web-based banking system, alone. -here, where we refer to legacy systems, we mean systems such as (by example and not by limitation) those using state-based or other proprietary communications and transaction authorizing systems such as ISO 8583 or Diebold 911/913.

-when we refer to web-based banking systems we refer to both consumer and commercial remote banking systems provided to a bank's customers to permit, for example, account and transaction history queries, inter-account funds transfers, automatic and incidental electronic bill payments, and the like, and we include here reference as well to securities trading and margin accounts, line of credit tracking and facilitation accounts, and similar things provided by all manner of institutions.

To use an example by way of description of an embodiment, a user identifies himself to a TEM and enters a passcode or otherwise effects the identification in an acceptably secure manner to the systems involved; the TEM provides an interface and input devices which permits the user to request a transaction; in this example the user chooses to withdraw $500 cash from his securities margin account at his broker institution from the TEM; the broker cannot authorize the withdrawal of cash from the TEM, not having pre-arranged funds transfer and settlement and authorization mechanisms with the operator of the TEM (the "ATM driver") and the authorizing authority of the TEM's dispense functions; the TEM can itself or can direct the translator and execution systems to access a legacy financial transaction consortium (such as " interac" and others), which permits a limited variety of transactions such as funds withdrawal from either a chequing account or a savings account at any one of a number of institutions who are members of the particular transaction consortium system; the user may be prompted to choose from a list of member financial institutions or the user's choice of institution to use in the funds dispense transaction may have formed part of the user's profile available in storage to the system; the system opens a browser connection to the web-based banking system operated by the user's broker, and responsive to the user's request to withdraw $500.00, instructs said web- based system to move $500.00 from the broker account to the user's banking institution's account from which the cash withdrawal will be made according to the TEM's legacy "interac" system; there may be more than one web-page and more than one user action required to perform that transfer of funds, and the middleware in the translator portion effects those steps automatically through pre-programmed instructions (in essence becoming a "proxy" for the user); there may in fact be a requirement to simultaneously or nearly simultaneously perform authorization and authentication and other steps using another browser-based banking system with the user's financial institution through which the funds are being first deposited in order that the withdrawal might be authorized, which would involve at least another preprogrammed user "proxy"; additionally, and once the funds transfer from broker account to chequing account has been effected, the system acts to cause legacy transaction instructions and state-declarations to be transmitted and received in appropriate formats and sequences, to and from the "interac" or similar system, in order that that system can instruct the TEM to dispense the $500.00 cash; the TEM will also provide user-interface displays to provide the user with status reports and queries with responses available during the steps in the transaction in order that variances from the proposed transaction and reports that the transaction can or cannot proceed can be presented; the TEM, once authorized, dispenses cash and perhaps a printed transaction verification; additionally, the TEM provides internal record-keeping functions ordinary to TEMs of its class. Thus, it is possible with no new or customized reprogramming to either the institution's existing web-based customer transaction system or to the legacy financial authorization system, or by the consortium, to provide a more fully-capable TEM transaction set using existing infrastructure.

As will be plain to one familiar with financial institution transaction automation systems and programming, there are a variety of legacy and web-based or similar communications and transaction systems which can be linked and operated in such a system using an automated middleman, or "middleware" to link, aggregate, and act as user proxy, to provide secure, authenticated, complex and new transactions and transaction types and sessions to TEM users while neither requiring extraordinary user inputs or inconvenience, nor requiring extensive or expensive programming, system development, intra-institutional agreement, or other effort, using existing infrastructure, and permitting the integration and aggregation of multi-system transactions transparently to the user(s) of the TEM and system.

It should also be apparent that more than one sub-transaction can be in process at any given point in time, and that some of the subtransactions can in fact be performed later (after the user-session ends at the TEM) provided the proxy-appointing means survives the withdrawal of identification and authentication means at the TEM by the user. For example, using the example where $500.00 cash is withdrawn from the user's broker's account (above), if the user had a $500.00 balance (or sufficient credit within the authorizing authority's system to permit a cash withdrawal of $500.00 from any of user's accounts accessible by the TEM), the cash dispense could proceed without the completion of the other sub-transactions making up the user's proposed transaction ($500.00 cash from broker account), and those sub-transactions could proceed in parallel with the cash withdraw, or at a different time than the cash withdrawal authorization and instructions. The system, through translator and proxy instructions and communications (even absent the user and user's identification and authentication means, those having been given once), could proceed to access user's web-based banking system accounts maintained with user's broker (for example) and instruct in an authorized way the transfer of $500.00 from the broker account to the user's chequing account (the account from which cash was dispensed, and which second transactions causes the series of subtransactions to effect, on a "net" basis, the transaction proposed by the user in the first place. The same holds true for multi-step transaction series of over 2 steps, over more than one institution, and with more than one (logical) route and sequence available for "net" execution of the user's proposed transaction (which, it can be appreciated, can be executed in an order and at times chosen from the orders and times possible either by the TEM, the system, the user, a set of user-provided rules or wishes or instructions, or any combination of those things, and which sequence and timing might also be flexible in order to route around problems with an account, a communications link, a web-page, an account balance, an institution, the capabilities of the TEM, the capabilities or down-time of a legacy or a web-based banking system required, or some combination of those things). Additionally, the sequence and timing of execution of sub- transactions can be modified to reflect transaction pricing, exchange rate fluctuations, or other cost items. Further, the transaction sequence and timing might be adjusted to optimize overall system and translator performance, or for a variety of other reasons, or for any sensible combination of such reasons. As well, it may be that the system and its included translator /middleware calculates all permutations of possible sub-transaction sequences and event timing and provides a method of permitting the user to choose amongst those methods or to rank amongst the possible permutations (and then saves those choice results to affect either ranking of permutations in a next user-proposed transaction using the system or to form a default routing, sequencing, and timing program for execution of sub-transactions to execute the user's proposed transaction at the TEM.

Finally, it may be possible for a user, using such an enabled TEM on such a system, to give instructions along the lines of "standing orders" or "repeat" cycles, to effect periodic executions of a user-proposed transaction (which might include a series of subtransactions to be organized by the system and translator with defaults and fall-backs to different accounts if, for instance, exchange rates or account balances were lower than some pre-determined level).

Some examples of such a series of periodic executions might be to transfer $X from one of user's broker accounts or user's line of credit accounts (accessible to the system) to the account of a third party, or to pay a periodic loan payment such as a car or mortgage loan payment. While means of instructing pre-authorized payment schemes exist, none exist to effect such transactions over a series of institutions and using rules and other methods for optimization. Recall that the definition of TEM may include more than an automatic teller machine, and can also include other forms of interface with the system (such as by PDA over wireless, or personal computer via conventional connection with the web or telephone systems).

An embodiment of the present invention generally provides a method and system for operating a transaction terminal, also known as a "transaction execution machine" (TEM). The TEMs can be incorporated into a transaction execution system that connects the TEMs by a routing and processing system to various financial institutions. The TEMs can assume "multiple personalities" responsive to user inputs and institutional inputs or may be determined by predetermined specifications (or branding elements) of a customer selected institution during a transaction session. The execution system provides for the TEM apparatus and for a system that includes such dynamically branded TEMs.

A TEM is a machine with a purpose of effecting a transaction between a user of the machine and an institution, where the TEM interacts with the user through input/ output sub- components. The TEM and the institution are coupled by communication and configuration systems.

A TEM can include a variety of known devices, predictable devices, and those which may arise in future. Known devices which are capable of being TEMs when properly configured as part of the system disclosed include (by example and not by limitation) the following: ATMs; personal computers with browsers and web access; web-TV (™ Microsoft Corporation) and similar devices; browser-enabled cell-phones, PDAs; various automated bank machines, two-way pagers; portable computers with wired or wireless web or communications access; kiosks such as touch-screen /interactive information-displaying kiosks with communications means; any of the above, either with or without printing, sheet dispensing, scanning, or depository or other similar "legacy ATM" typical capabilities. The TEMs could also be a variety of automated cash machines, automated bank machines, point of purchase devices, kiosks, and other devices with a means to receive ID from or of a user and to subsequently perform or execute a transaction. When used herein, "TEM" or Transaction Execution Machine, shall have this meaning.

The TEMs can include a browser, and the configuration spoken of including branding, which is accomplished by supplying to the browser system in the TEM instructions and data in forms like documents with embedded tags, but which are in fact anything capable of being handled by a browser, including by example and not by way of limitation, applets, data and instructions capable of being handled by plug-ins to a browser, and the like. Content may be rendered by the browser to provide an interface to the user at the TEM by being converted into a display and interface, while the TEM may be controlled by data and instructions sent to it which are otherwise handled by the browser or its plug-in applications or mini-apps or applets or the like, such as instructions to permit recognition of a touch-screen input device, means of accomplishing the dispensing of cash and the consequent recording of machine states and events or transactions, the operation or engagement of peripheral devices at the TEM, the communication of TEM states, and the like. Thus, the user interface provided by the configured TEM is anything renderable by at least one browser, including but not limited to faceless browsers or a browser with no skin, streaming audio or video, or other data-type plug-ins, players or components such as QuickTime (TM Apple Computers), Shockwave (TM Macromedia), Flash (TM), Realaudio (TM Real Corp), and the like.

In one example, an ATM deployer, merchant or the operator of the system could enable a user to express a language or currency preference from a range of available choices, and the system can display all the TEM's functionality in the language or currency of that user's selected choice. Further, the system can record the preferences expressed by the user as entered either at the TEM or through some other means or at some other time, and recall those preferences to modify and personalize the TEM experience. The interface elements can be predetermined by the associated institutions, and /or the TEM customers, during setup and operation of the system or during particular stages of a transaction session.

In order to use the system of the multi-personality TEMS, each institution with which the user wishes to interact must be determined. In order to determine the desired institutions, some information must be provided. This information can take any of several very distinct forms:

(a) physical machine readable indicia presented by the user. This would include, but not be limited to, smart or other cards and cheques; (b) biometric information about the user. This could include (without limitation) measurable physiological identifiers such as voice-print, fingerprint, iris scans and the like; or (c) some indicia transmitted, such as by infrared, RF, phone (call a number on the TEM) or otherwise to the TEM at the user's direction or on the user's behalf.

It is also possible for a user to begin using the system by allowing the user to make a selection using the user interface provided by the TEM such as by a choice on its wait state interface. This would usually be by making selections on a touch screen on the TEM, or by using a keypad, keyboard or buttons on the TEM.

Physical indicia presented by a user would at this date most commonly be a card such as a credit card or bank issued card. Such a card can have either a magnetic strip that carries the necessary information or it can be a chip card or smart card, which has on-card storage that contains within it the necessary information, or alternatively or additionally, the card might contain a bar code or other machine-readable information. In some cases a single card may contain or carry information in several forms such as both on a magnetic strip or bar code and within the storage of a chip on the card. In such a case the source of information read will depend upon the capabilities of the TEM. For example a card may have both a magnetic strip and a bar code, and when the card is used in a TEM that is part of the system described herein, the magnetic strip may be read. When that same card is used at a point-of-sale checkout of a merchant the bar code on the card may be read by an optical scanner at the till.

For brevity, where we use the words "smart card" it shall be taken to mean either a memory-only chip card or a chip card that has both memory and computing capability, as either can work for the system, methods and apparatus described herein.

Where the indicia is physical, the user presents it to the TEM. Usually this involves inserting a card into a card reader on the TEM. Such card readers can take several forms: where the user swipes the card through a reader, motorized readers that retract the card inside the machine to read them, or ones where the user manually inserts the card and it stays accessible to the user. All of these types of readers are suitable for magnetic cards while only the last two are suitable for reading chip or smart cards. The motorized readers are common in full function automated bank machines and high end kiosks, while the swipe and manual insert schemes are more common in low end ATMs, cash dispensers, smart display phones, most kiosks and portable devices.

Once the user has presented the card, some or all of the information on the card is read in order to determine an institution with which the user desires to interact. This information can take a variety of forms including a URL, a BIN, a UN or a unique number or string. The information may actually be two or more pieces of information which when taken together are unique for purposes of identifying the institution, and may be provided in one or more steps.

For example, if the operator of a system, as described herein, were to assign unique numbers to its member institutions on a country by country basis, and member institutions issued their members items which had both this number and the country code in the form of a bar code on the item, then the member institutions could provide for their users to use the system by using the bar coded item to provide a unique reference to a member institution, at least within the context of that particular system.

If the customer's desired member institution is identified by the customer presenting a smart card to the TEM where said card contains identifiers for several institutions, then the user is first presented with and makes a selection from a branded display of all institutions represented on the card that are members of the said transaction system. Another way that a user can obtain the branded interface of the desired institution is to make a selection from the wait state TEM interface indicating a wish to manually select an institution. The user could be prompted using a variety of approaches to arrive at a desired unique institution. This could be through a series of narrowing questions, a search by name, a series of selections from a series of more and more zoomed-in topic maps or geographic maps, or by manually entering institution identification numbers such as its BIN, UN or routing number. The branding of that desired institution would then be presented assuming such institution was a member of the system. Typically, the user would then be required by the institution to provide further information for identity and authentication.

In a transaction execution system as defined herein, some or all of the TEMs may include a user identification system for automatically identifying said user's desired institution by a method that first involves biometric identification of the user. The biometric information about the user will be captured at the TEM and will then be compared with entries in the biometric databases of each member institution that supports such method of identification of a user. For example if the biometric identification method is an iris scan, then the user's iris scan only needs to be searched in institutions that have iris scans for some of their customers. In this example, to speed the matching it may be desirable to scan every institution's iris databases in parallel. If only one match is found then the branding of the institution in whose database the match was found will be presented. If more than one match is found, then the system could present to the user on the display of the TEM a pick list of all the matching institutions from which the user could make a selection to proceed. Where there are several possible institutions for a particular user, of a subset of the matching institutions' essential branding elements of those institutions could be displayed, such as a small logo and color scheme, in order to assist the user in making a choice. Having selected the desired institution, the branding of that institution would be presented. The relating of institution to branding location and the presentation of that branding would be done using methods and systems previously described.

It may be desirable to improve the performance of biometric matching by having a consolidated set of biometric databases maintained at a single location accessible by the TEM directly or through some intermediary system.

Please note the examples at the be beginning of this description having to do with identification and authorization. Where "card" and "PIN" are used, other indicia or security methods may logically be substituted. Also, the "I & A" function may itself be included as logical "transaction" or "sub-transaction" set, and may be done in middleware by the system using a user's proxy or proxies provided by the translator. The transaction execution system described herein can be operatively connected to one or more traditional or legacy transaction networks, so that when users presents indicia that indicates a desired institution which is not a member institution of the system, the user's transactions can be supported to the extent possible by operatively communicating with the desired non-member institution over traditional transaction networks. In this case, the transaction would not be branded and the available transaction types would be limited to those supported by the particular traditional transaction network (such as Interac, Cirrus or Honor/Star).

In other cases an institution may be a member or participant in the system but only connected via a traditional transaction network. In this case, a session can be branded using content created by or for the member and served from any of: the TEM; communications and routing systems; or a service provider on behalf of the institution.

In the transaction execution system described herein, the user interface of the TEM can include the ability for a user to communicate directly with a representative of a desired member institution from said TEM. This direct interaction can begin at a point in the session when the institution requires human interaction for reasons of authenticity related to loss control, for customer service reasons, to deal with complex requests or direct interaction. This can be done with audio conferencing or direct interaction audio and video conferencing. The display of the TEM can be used, if suitable, to display the image of the customer service representative. The use of the audio conferencing simply requires that the TEM contain a suitable microphone and speaker.

This representative can be situated as part of said processing and routing system, at a location of said member institution or at a location of a service provider acting on behalf of the said member institution.

By allowing each transaction execution machine to control its own peripherals such as printers, currency dispensers, depositories, keyboards, screens, and the like responsive to programming embedded in documents provided for or routed by a router /switch, and to report activities and states back through the same router /switch, it is provided, in addition to "dynamic branding" and "customer macro-accounts", functionality on the network, preferably at the router /switch, which provides for translation and buffering and interpretation services which allow operability of the TEMs which use and expect information and programming via XML over TCP/IP, and legacy transaction authorization systems which use and expect responses via proprietary message formats and protocols such as Diebold 911/912. Conversely, by routing state information from legacy ATMs to the router /switch, functionality on the network, preferably at the router /switch, provides for the translation and buffering and interpretation services which allow operation of the legacy ATMs which use and expect communications and instructions via proprietary message formats and protocols such as Diebold 911/912 by either legacy transaction authorization systems or by more modern transaction authorization and accounting systems which use and expect information and content via XML. (Diebold 911/912 is merely an example of a legacy system in these discussions).

By providing the interpretation, buffering, and translation services for communication between legacy authorization and control systems, legacy ATMs, modern web-enabled TEMs and modern web-enabled institutions at the router /switch, translation, buffering, interpretation and emulation databases, and the required processing and data co-ordination may occur at a more powerful and capable computer site than at a limited capacity TEM, and it also becomes possible to provide transaction execution with legacy transaction authorization instructions without problems which occur co-ordinating branding information with transaction information if those two disparate types of things are provided directly to the TEM in their own formats to and from different sources.

For other transactions, especially all types other than cash withdraw requests, whether of a type supported by existing networks or of an entirely new type or purpose, but of a type that is or can be supported by the bank's web-banking site, the TEM communicates with a middleware piece (called here a "translator"), and the translator communicates with one or more public or private web sites that can present bank information to customers, and/or obtain information for the bank from the customers, and/or permit customers to conduct some form of transactions. The translator includes the capability to accept and forward data for collection, a request from the TEM for data from one or more of the web sites, or a request from the TEM for a transaction involving one or more of the web sites. The translator has sufficient information through configuration or other information supplied regarding the web site or sites, or alternatively the additional or alternative capability to search, parse or otherwise determine the necessary approach to optionally log in or otherwise identify the user to all needed web-sites, (the customer at the TEM), optionally activate the correct sequence of web screens to send the data to the financial institution, obtain required information from the financial institution, and /or initiate a transaction with the institution.

In a further embodiment, the translator and system includes in addition to the previously described capability, or as an alternative to that capability, the capability for one or more of the financial institution web sites and /or the translator to optionally recognize one or a group or segment of customers or an individual customer, and initiate a transmission or data or a request for a transaction from the financial institution to the TEM, whether or not the customer would have had the capability, the intention or the desire to obtain the data or initiate the transaction.

In another version of the invention, the customer is known to one or more of the web sites with which the TEM interacts. For example, the customer may have a conventional web login, token, biometric identification or other means, or a combination thereof, useful to identify and authenticate the users to the web site using a terminal connected to a network which is or is similar to the world wide web or a more restricted intranet. All, or alternatively a subset or superset, of the information sent to or obtained from the web site or sites, or transactions available via conventional login to the site

In another version, the translator accesses more than one web site, where each one of at least two web sites is from a related institution or business. In still another, the translator accesses more than one web site, where each one of at least two web sites is from an unrelated institution or business. In a further version, the customer accesses financial data via a conventional transaction with an institution or institutions, while one or more web sites used to present, modify, transact or gather data, is from another institution or another entity with whom the customer could interact on a data or transactional basis via networks such as the public web or private intranet, and even though the institution and other entity are separate to a greater or lesser degree, the experience of the customer is such that the available data, requested data, and/or transactions appear to be integrated, substantially integrated or otherwise related.

In a further embodiment, the system through the middleware component includes all the capabilities and advantages that XML or other self-defining data path or communications definition might provide, whether using XML from the ATM to translator, translator to web site or financial institution, or both.

In another embodiment relating to business processes, the translator is operated by part of the financial transaction network, eliminating the need for the institution to own or rent the translator, and optionally eliminating any need for the financial institution to change or maintain the configuratio of the translator to obtain or place the necessary information from or to the web site as the web site is changed by or on behalf of the financial institution. The translator may service multiple device types, multiple device owners, multiple financial transaction networks, and multiple financial institutions. Further, the system may include links to related or other web sites of potential interest to the user or the displays of which are useful to the institution, such as news sites, to get automatically updated attractor screens, or retail web sites to give retailers on whose premises the TEM may be located some of the advertising advantages financial institutions conventionally enjoy. Finally, it may also be used by third parties that wish to easily and quickly use the ATM channel and don't want to invest in a costly interface to their back-end systems - if a customer can do it on the web, they can do it at an a TEM connected to this system.

The above arrangements generally assume that the system is created by, or for the benefit, or with the co-operation, of one or more financial institutions. It is to be understood that the translator and at least one or more of the available interactions can exist and be accomplished without the explicit permission, or even co-operation, of the financial institution. The customer gets the benefit of some or all of available 'web banking' services via a TEM together with traditional financial transactions, through the middleware's 'stand-in' or 'proxy' functionality in background

The translator performs the function of changing the data or transaction in one or more of the following dimensions: interface type, format, organization, protocol, message flow, and data quantity; from an interface convenient and suitable for use at the TEM and in integrating data or transactions or otherwise combining the transactions or data with data definitions; control flows; locally stored or obtained data, card-based data, remotely obtained data from sources other than the financial institution and/or other information or display elements; identification; graphical presentation; and branding information such as color, logos, and the user interface experience known in the industry as the ook and feel' on the TEM or ATM side; to an interface convenient and suitable for accessing information sources such as financial institution web sites.

In one embodiment, the translator includes several element types: (1) one or more web interface elements providing bi-directional translation of data from one or more web site formats to a common, simplified format by separating, reducing or translating the required data elements of the web site to 'bare' data free of other graphical or other elements that are not relevant to the transaction or data ultimately required or available, typically with one such element for each web site to be accessed; (2) one or more optional web control elements capable of tracking state information of the web site as though the translator were a 'phantom' user of the web site and capable of navigating through the various pages comprising the site in order to obtain data from or place data into the web site, activate controls and otherwise interact with the site in a manner similar to that used by a human through a web browser as if the translator were the user, or the user's proxy, with the object of reducing, changing or eliminating the knowledge or steps that the system, TEM or customer might otherwise have to possess or execute in order to obtain the bare information desired, where typically multiple simultaneous proxies of this nature exist with each 'proxy' corresponding to a single phantom user, and optionally where multiple phantom users or proxies may substantially simultaneously correspond to a single user; (3) one or more device interface elements that can translate, reformat the 'bare' data, communicate and present or obtain device-friendly data to or from multiple models, types and capabilities of TEM, varying in such elements responsive to TEM capacities, such as: graphical display resolution, communications bandwidth available, local storage available, touch screen, audio interface and many other elements existing and contemplated on TEMs that may vary from one TEM to another, and more broadly to or from multiple types and models of other devices that may be used for financial transactions, including those most like conventional ATMs in their security capabilities such as PIN-based point of sale devices, and more broadly still other devices that may be used for financial transactions such as different models and manufacturers of PDAs and cell phones, where typically there is one element for each device type; (4) a mapping element that determines or controls the mapping or routing of information and requests originating from a device such as an ATM and arriving via a device interface to one or more web interface or web control elements, based on predetermined rules or configurations, or determined by algorithm from information supplied via the device interface; (5) optionally a management element that maintains information based on devices, financial institutions, users, or some combination thereof such as login IDs, passwords, URLs such that the user can log in or otherwise identify themselves to the TEM and/or translator, and the translator can use that identity to access institution- or customer-specific information without the customer needing to enter, or optionally even to know (where, for example, the information is set up by the institution) further transaction interactions or details; and (6) optionally a billing element that tracks the usage of various elements and resources of the translator such as to be able to separate out the usage of the translator by multiple parties that may be tracked, reported and/or billed on independently.

A further embodiment is the above translator where the management element uses the card number to determine the right web sites (web interfaces), user IDs, and passwords for the cardholder or user. A narrower but useful embodiment is with or without the card where the customer supplies an identifier or password, and more narrowly and specifically the PIN number, and this is the key used to unlock the web site access data allowing login and interaction with the web sites for that customer (or more probably cardholder), via user provided, institution-provided, or other security means such as encrypted keys, transaction PL , site passwords and login ID's, and the like.

A further system differentiator from some existing web implementations is for the translator to provide or facilitate, beyond the web site login (whether present or not) including the PIN block from the ATM in the message to the web site, and including a box either in front of the web site (possibly the translator itself) or the capability within the web site (though it means a co-operating financial institution and web site customization) to pass the PIN number all the way to the banking web site, and have the web site transactions validated not because there was a conventional web login (which might or might not have been done), but because the card and PIN was actually validated. This approach brings ATM-type security to web-style transactions conducted on the ATM, through the facilitation of the translator.

In another version, the translator includes the capability to translate display elements, transaction information or data from one human readable language or currency to another. The language and /or currency used at the TEM may be determined by the financial institution, network, or TEM, based on previously known or newly detected information about the user; or alternatively determined by the user at the time of the interaction by interaction with the system through the user interface by means of an explicit selection, or explicitly by coding of card or other indicia, or by the cross referencing of card or indicia coding with one or more databases where the user or other controlling party has stored information on such preferences or settings appropriate to the user.

In another implementation, the choices provided to the user via the user interface at the TEM are determined based on some information detectable by the TEM or translator from any information about the user, including card, other indicia, such as photo identification, analysis of spoken information. In one specific implementation, the information is in the form of a BIN from the user's provided card, and based on the known national origins of that BIN and the subset of languages used in that national market and that information drives languages and/or currency displayed at the TEM responsive to the translator. In other implementations, the information translated may be other than human readable language and may deal with, for example, transaction event sequencing, progress displays, prompts or other elements of the user's interaction.

In another implementation, the translator includes the capability to reduce human readable information from the web site to coded data that is subsequently decoded at the TEM and used to control some element of the customer interaction, or alternatively re-translated by the translator or TEM into human readable form which may be in the same language as the original information or in another human readable language or form. In a further implementation, the translator or TEM has the capability to encode information or requests from the TEM into information, codes or tokens that are not directly human readable and which are optionally independent of the human language used by the user and/or the web site, and the TEM or translator has the capability to translate the codes to the language required by the web site or legacy system. These coding and decoding sequences, logically, include but are not limited to encryption and verification means such as by PKL.

In various of the traditional ATMs provided by a number of suppliers, there is provided in an array at points around the display screen of the ATM a number of hard-wired buttons.

The display is variable to indicate the functionality of each of said buttons, which may be different at different stages during a series of transaction steps during a user's session interacting with the ATM.

When a TEM is provided with suitable touch-screen video display as a peripheral, said display may be configured by a portion of the information (for example by way of HTML documents, tags, applets, or the like) by means of which the TEM is configured, such that a portion of said screen is made to emulate the hard-wired buttons on a traditional ATM, in order that a member institution's pre-existing branding information having to do with the way it deals with its captive traditional ATM may be emulated, using a embodiment of this invention as an example, at a web-enabled, browser-competent TEM connected via the routing and switching means to said mstitution and to branding.

Device capabilities of the operative TEM within a session can be previously known by the institution or sent at the beginning of each session, in order to tailor the user interface and branding elements presented by the TEM to the capability, screen size, peripheral enablement, consumable supply, ma ines state and the like provided at the TEM.

At or near a transaction session's start, a TEM could communicate to the system and its participants, including the translator, its capabilities and optionally, the state of its consumables, to permit optimum utilization. The institution can query the TEM at any time during a connection in a session, to obtain device capabilities or status, status of consumable supplies on hand at TEM, data collected by or at the TEM, or the like, as desired.

During operation of the transaction execution system, the TEM could be waiting in a mode that can be called an idle or wait state. In this state no user is directly using the TEM. A user wishing to make use of the TEM would first provide information to the TEM that would then be used to determine the institution with which the user wished to interact. The TEM would then be operatively coupled with that institution so that the user could conduct a transaction session with the institution. The user would conduct a transaction session with that institution where throughout the session the content displayed to the user was content specific to that institution and was complete with all aspects of the brand of that institution appropriate to the capabilities and location of that TEM. At the end of the session the TEM would return to the idle state where it would await another user. A next user could conduct a session with a different institution and would then experience an entirely different set of content and branding. The TEMs preferably have an open and flexible system of presenting content, and facilitate providing a variety of branded content of a plurality of institutions.

When initiating a transaction session of the TEM with a selected institution, the term "operatively coupled" could include, for example:

the identification and the provision of communications facilities, direct or indirect, between them or between one of them and an agent of the other of them, with or without a persistent physical circuit; and

coupling might in some circumstances involve identification and communication provision between or amongst more than two entities; and

coupling. may be between the user of a TEM and some component of a desired institution's branding elements, however provided; and

coupling may mean the system acting as if a coupling described above had actually taken place.

The TEMs would be coupled via any means that can provide or be made to provide reliable data transmission over a network. The network would connect the TEMs with the desired member institution, service providers acting on behalf of institutions, and with authorities responsible for accounting for items of value within the TEMs and with organizations responsible for the operation and maintenance of the TEM.

Institutions that could be coupled to the TEMs and thereby make use of the dynamically branded system described herein include; all manner of financial institutions, merchants that wish to develop relationships with their customers particularly by way of loyalty systems, government organizations that issue identification or permits or licenses, and any other organization that wishes to provide a means of interacting with its customers or members at a variety of access points in a way that the institution would have control over the image and functionality presented to the user. So, throughout this document, where the term "institution" is used, it shall be taken to mean any such type of organization, institution, company, government agency, merchant and the like, including for example, banks, credit unions, savings and loan companies, finance companies, insurance providers and brokers, credit card issuers, securities brokerage firms, trust companies, mutual fund companies, wealth management companies, lottery organizations, motor vehicle agencies, mortgage companies, government licensing bodies, airlines, cooperatives, associations, charities, and as well any type of financial institution, merchant, service provider or retailer.

While the institutions are coupled to the TEMs, the execution system may process forms of documents that include tags or instructions embedded therein in addition to legacy transactions (if any) and said documents may be in several forms and from several sources, handled by the translator nearly simultaneously. The most common current types of tag-based documents are referred to as HTML ("Hypertext Markup Language"), which is a variant of a more generic type of Standardized General Markup Language ("SGML"). SGML includes other variants such as XML (extensible Markup Language). XML has been developed primarily focused on the transmission of inter-computer understandable data and data structures, with some capability of description of presentation elements.

In software implementations of systems using current 'web' technology, collections of images, branding elements, machine instructions and data are often referred to as 'documents'. Documents tend to represent a logical subdivision of a larger set of related instructions or data, and frequently include the capability to reference data in other documents or pass control to instructions in other documents. These documents are more specifically files containing elements in some standardized arrangement such that the file elements can be interpreted and the instructions implicit in the file contents can be acted upon by the interpreter to set or control the appearance, data, transaction flow and many other elements. In the context of dynamic branding, a 'document' may indeed be such a collection conforming to widely utilized document standards such as HTML. However, it will be readily understood by those skilled in the art that these collections may be of some less common type or may even be unique to a specific implementation of the system, and that the 'document' may not necessarily contain directly human-interpretable elements such as text, but that a 'document; can consist of any set of instructions, data or any combination thereof, including elements such as software routines, directly executable computer code, transportable or platform independent code, data elements, tokens, variables, and any other item used in the control of a software process, such that the contents of all or part of the 'document' can be interpreted, read or executed by the system such that the system may act upon them to control, configure or influence its operation, capabilities or appearance. The term 'documents' in the context of this system description may be conveniently considered to include all conventional and widely standardized collections commonly called documents, such as HTML files containing or referencing java code, in order to aid in the understanding of the system using widely familiar paradigms. However, the term as it applies to the present transaction execution system includes, as well the broadest range of any arrangement, sequence or collection of instructions, data or code that forms a logical subdivision of the intended system behaviour. While this example assumes the conventional usage of the term URL, it will be readily apparent to one skilled in the art using the term URL as defined in the context of the dynamic branding system that the URL could be any form of reference or pointer to the instructions, code or data or any other representation of initial set of branding information to be acted upon by the TEM.

XML provides means of describing data through data type definitions, which while human-readable, also lend themselves to be machine-processed. XML data descriptions begin to represent data types in a model useful to understanding and being dealt with in a particular type of business. XML documents may be thought of as "data-driven" and not "transaction- driven", and in essence are themselves "self-describing data". XML formatted documents are very useful in providing device-independent machine-to-machine data communications with hyper-linking capability, and thus XML is currently the most useful of the tag-based languages for TEMs and would be an efficient means of describing data across multiple systems. It is to be understood, however, that reference herein to and of the terms HTML, XML, or SGML or to documents with embedded instructions or tags is to be considered as a reference to each applicable member of that general group, and as such are interchangeable where to do so would be sensible and apparent to one skilled in the art.

Http and TCP, when its use is implied or assumed, are to be understood as including other similar or functionally equivalent transport and document delivery protocols, such as but not limited to Wireless Access Protocol, or WAP, and said terms may be interchanged when to do so would be sensible to one skilled in the art. Likewise, Wireless Markup Language, or WML, is to be interchangeable with XML (as elsewhere defined), where to do so would be similarly sensible.

A user's card may contain an actual reference to a document. A well-standardized scheme exists for specifying the document, location of the document, and the protocol for accessing the document. This scheme is called a Uniform Resource Locator or URL. An example of the form of a URL is:

http: / /brand.autobranch.com:80/startingpoint.html

Where the "http://" portion specifies the protocol for accessing the information, which in this example is the "Hyper Text Transfer Protocol" commonly used for transferring web documents such as HTML and XML. The "brand.autobranch.com" segment is the name of the logical location of the computer that is accessed. That name is converted into an actual IP address by using the domain name system (DNS) which provides translation of names to IP addresses on the world wide web. The "startingpoint.html" in this example is the name of document that is to be retrieved. The ":80" portion of our example is the port to be used on the computer being accessed. As many protocols have a default port, this portion can be and is often omitted from a URL. So in our example, if a user presented a card that contained the above example URL, the TEM would look up the address for the domain "brand.autobranch.com" and then use the "http" protocol to send an http request to that address using the port number specified, "80". The request would ask for the document "startingpoint.html". To provide for dynamic branding, that document would contain various elements of the branding of the institution that provided the indicia that pointed to that URL. The branding elements would be in the set of documents of the starting document along with all related documents and files referable from that first document.

While "URL" (Uniform Resource Locator), as described by the Internet Engineering Task Force in the document RFC 1738, is the common term for expressing a complete reference to a net-based resource, those skilled in the art will appreciate that this could also be a "URI" (Uniform Resource Identifier) as described in RFC 2396 or a "URN" (Uniform Resource Name) as described in RFC 2141 and therefore throughout this document where the term "URL" is used it is to be taken to mean any one of these or similar terms that describe a similarly complete reference to a resource.

In addition to embodiments relying upon URL standard addressing means to locate elements of this invention, it will be apparent that "URL" can as easily be replaced, were to do so would be sensible, with words such as "location", "stored source", "pointer", "starting point", "reference", "entry point" or other words, where such infers a complete reference useful for access, retrieval, or a starting point reference to a collection of machine interpretable instructions, code, or data in any form.

An organization that has never issued cards before may find the actual provision of a URL as part of the information stored on its new user cards to be a desirable approach. While having a URL on each card makes access to the starting point for the branding of that institution straightforward, the drawbacks are several, particularly for institutions and organizations that have previously issued cards. There are an enormous number of existing cards in use by consumers which do not currently have URLs on them. The cost of reissuing or recoding cards can be significant. Another drawback is that there is no well-accepted standardized location for storing a URL on a smart card or on a magnetic card nor even for indicating that one is present. Also, a URL can be a significant size in comparison to the total amount of data storage possible on a magnetic strip or bar-codable surface area of a card. So, while it would be possible to construct a system that could use URLs stored on indicia, many aspects of such a system could be proprietary to that system, and there are some disadvantages or impediments to its implementation.

The indicia may alternatively contain a numeric representation which can be manipulated to become or refer to a URL which references desired branding information of a member institution.

Cards issued by financial institutions routinely and almost universally contain a Bank Identification Number (BIN). A table can be maintained that contains BINs and the URL associated with each particular BIN. This table can be stored within the TEM itself or can be accessible for lookup over a network connection. When the table is stored at the TEM, the copy on each TEM must be updated from time-to-time as new member institutions are added or the URL for a particular BIN is changed. Where the table is not stored on the TEM but is accessible for a lookup over a network, then responses to frequently used BINs might be cached in a variety of fashions on the TEM or in the system in order to improve system performance.

A more general approach than using a BIN would be to use the Issuer Identification Number (UN) as described in ISO 7812 for magnetic cards and ISO 7816 for smart cards. These specifications describe the format used for almost all magnetic cards issued worldwide and for many smart cards. The specifications and related policy and system of registration bodies provide a method of having the Issuer Identification Numbers assigned in a way that each is unique on a worldwide basis. The UN therefore provides an ideal key for a lookup table or other similar mechanism for relating a user-provided UN to an associated URL pointing to branding elements.

Other forms of physical ID that the user could provide that could include the necessary information include:

a bar code attached to an a item such as a tag on a key chain;

a proximity device such as are frequently used to control building access;

some other form of token or identification capable of being machine read or recognized by the TEM.

Any of these could contain or represent an IIN and optionally additional useful information. Another way that a user could provide useful instantiating information to a translator system is to enter a cheque or other MICR-encoded material of the desired institution into the TEM ("MICR" means Magnetic Ink Character Recognition). This would require that the TEM had the ability to read the machine readable coding on the cheque. This coding includes a bank routing number that is unique at least over large regions. Since such a system is likely to be deployed on a global basis, the bank routing codes may not be unique. If that were the case for a particular routing code on a user cheque, then the system could present to that user on the display of the TEM a selection of all the institutions matching that cheque's routing code and the user could make a selection from that list before proceeding. A subset of the branding elements of those matching institutions could be displayed, such as a small version of a logo and color scheme, in order to assist such user choice. In the vast majority of cases this intermediate step that requires the user to pick the institution from a list would not be necessary, and the user would be taken directly to the opening screen branded for the desired institution. The cheque or other MICR-encoded material so presented to the TEM could either be returned to the user or kept in the TEM for later secure disposal.

Another way that necessary identification information to identify the user to the TEM can be provided to the TEM by sending the information from a portable device that is in the user's possession to the TEM. When the portable device is in close proximity to the TEM it can be temporarily operatively connected to the TEM to provide the identification information which indicates the desired institution.

Such portable device would have the identification information within it because it contained a smart card chip with the information, or it had a card reader of its own and a user has inserted a card, or the portable device itself had previously been provided by the desired institution with the information pre-stored in it, or the information might at some time have been manually or otherwise entered into the device, or entered into the device by some other means.

The operative connection between the portable device and TEM might be provided by means of a short distance infrared connection. Infrared capabilities are now common in portable devices such as hand-held computers, personal digital assistants, cell phones, PCS phones and other wireless phones and devices.

The operative connection could also be provided by a short distance radio frequency connection between the portable device and the TEM, such as Apple Computer's "Airport" (™) or Lucent Technologies' similar 802.11 'Orinoco" (™) wireless networking systems or by a technology known as "Bluetooth" ("Bluetooth" is a ™ of TelefonaktieboLaget L M Ericsson, Sweden).

In a further embodiment, TEMs can be used as access points for general web browsing by portable devices that are in the near vicinity. Since some TEMs will be equipped with suitable connections to the public internet these TEMs, when also equipped with wireless means, such as Bluetooth, can support users with portable device that simply need an internet access point to perform such activities as email sending and receiving, and general web surfing or some subsets of web-based banking transactions. This capability would preferably only be deployed on TEMs that have sufficient network capacity that they can support such additional users without degrading the performance experienced by users who are using the TEM to conduct transaction sessions with their institution. The TEM should preferably limit the number of such sessions that it will allow to be conducted simultaneously to be appropriate for the capacity of its network connection. The payment facilities of the system can be used to allow these users to be charged for such uses of the TEM as an access point. When the portable user first connects to the TEM in this fashion, the TEM or the routing and processing portion of the system, will present a screen where the user will be advised of the charges for such general web use and will be asked to provide a means of payment before proceeding. The means of payment can be a credit card, bank debit card, transfer of value electronically or any other means of payment supported by the system that the TEM is connected to and that the user has. Payment means can also include the user first conducting a transaction session with their institution in order to pre-authorize a transfer for the use of the general browsing capabilities enabled through the wireless access to the TEM. At conclusion of the user's web session being conducted through the TEM, the payment means previously indicated by the user will be charged for the session. Optionally an electronic receipt for the session can be provided to the user, by email or otherwise. Users that wish to use such facilities frequently can enroll with the system to speed the logon and payment setup process by prepaying into an account that will be debited with each such session as they use it. In an alternate payment model such use of a TEM as an access point could be supported by advertisement that users could agree to see as the bargain for being able to receive this free wireless internet access. The system can increase the value to advertisers by providing information on the location of the TEM that user is using. Advertisements appropriate for the demographic served by the establishment where the TEM is located would be presented. Further, where appropriate and the user has provided necessary consent with respect to local privacy laws, the system can use its knowledge about the user to further assist advertisers in presenting advertisements and offerings that will most likely be of interest to the user. Any valid web content including by example (and not by limitation): XML, HTML,

WML, gif, jpegs, and applets; could be supported in this scheme. Even content that is supported by a plug-in program for a browser could be supported in this manner. This could include such content forms as Shockwave and Flash from Macromedia Corp, Real Audio and Real Video from Real Corp, PDF document format from Adobe Systems Inc., and the like.

For brevity, as previously discussed, when the term "XML" is used it shall be taken to include or to be any one of, or all of as appropriate, and which would be understood by someone skilled in the art, HTML, XML, WML, SGML or any other similar "document and tag" based language including, where appropriate, further content types including portable code that these documents can refer to or contain.

An example list of traditional transactions that can be implemented in this system between a user and an institution could include actions such as: - account balance and history queries and reports; deposit of cheques or money, issue of receipts, addition to user account balance; cash withdrawal, receipt issue, deduction from user account balance; inter-account transfers and bill payments; receipt issue, corresponding account balance adjustments; and - like transactions.

In regards to general applications of the multi-personality system, the group of parties capable of being "institutions" is growing, and thus the identity of the "user" grows commensurately to also include those new institutions' customers or those with whom those old and new institutions will transact. The number of available types of transactions also grows commensurate with the addition of new types of parties, but as well with the addition and invention of new types of interactions between users and institutions and the invention and introduction of new types of enablements of TEM capabilities. It is therefore to be inferred here that "transactions" include all such interactions between such users and such institutions as would be understood or inferable by one skilled in the art and possessed of the common general knowledge and information in this area of social or commercial interaction. Some examples of new "transaction" types might be:

transfer of loyalty points inter-party; - redemption of air miles or other non-currency value items for goods and services; bids, offers and acceptance of novel contract formations, including as well, reverse auction methods; on-line catalogue purchasing; on-line fund or value transfers and donations, information browsing, query, search, and provision; on-line advertisements or survey; - interactive storytelling;

ICQ and chat between parties or groups; and the like.

The translator can be configured to permit as complete control of the TEM and the connection between the TEM and institution or the agents of the institution as though the institution defined, engineered and implemented the system. This is generally the default case where a single institution deploys captive ATMs. The transaction execution system disclosed herein can provide this type of control on the part of the institution even though the TEMs are not captive, while importantly preserving the segregation, co-operation and inter-institution security and confidentiality of the branding, control and content specific to each participating institution.

Due in part to the potential number and variety of institutions that can interact with the transaction execution system and translator, there are many techniques familiar to those skilled in the art for caching information or at least the most frequently used information which could be employed to improve overall system performance and particularly the refresh rate at the user interface.

When the indicia was first read at the interface, likely only a portion of the indicia was used to identify the institution. The balance of the indicia would also have been read and could have been saved and later made available to a desired identified institution for identification and authentication of the user. This can be done in several ways. When the URL of the desired institution is accessed the additional information available from the indicia can be transmitted as part of the request for a first document. This can allow the first document and/or subsequent documents returned by the institution to be variably modified based on the additional data that was sent with the request.

The additional data from the indicia might also or alternatively be made available to software in the TEM or the translator in the form of variables that can be substituted into a document that is received or can be used to guide the processing of a document received. Such variable processing of the document could be accomplished with JavaScript, Java applets, vb script [NOTE: "Java" is a trade-mark of Sun Microsystems Inc. and "vb" is a short-form of "Visual Basic" a trade-mark of Microsoft Corporation] or other such portable languages or scripts, or some combination of these and other similar techniques. This making available of additional indicia data to the content of the browser is a capability useful in personalizing the content to be specific to the user or class of user, and in improving performance of the system as experienced by the user, and to assist the institution in presenting information in the manner which it desires. Some examples of the use of this additional data when so made available are: presentation in a preferred language and/or dialect; presentation in a way that assists users with particular conditions such as very poor or non-existent vision; an identification of the user by name or number; an indication of some group that the user is part of, such as a gold card club; provision of particular currency information.

In one embodiment, the TEM may capture and cache a user's personal preferences at that machine to speed transactions at that machine at a next session (caching most current branding and user interaction information) and, depending upon local storage and machine enablement, may temporarily or semi-permanently store certain user preference or other user- related information to speed transactions from a user perspective while maintaining the institutions' branding aspect (this is responsive to statistical analysis of user behavior known to those skilled in the art that suggest that users of ATMs utilize 2 or at most 3 ATMs for the vast majority of their transactions).

Caching may take place systematically as well, if desired, providing for system-wide date capture for system performance monitoring and management, as well as other uses which will be apparent to the skilled reader in this art.

Having reached institution, one of the first things that an institution may then do is to authenticate the user. This could be done so that the institution has the confidence that it is truly the user that is present at the TEM and not just someone who has found their indicia. In order to do this the institution may request a user id and password from the user. If the supposed identity of the user was contained in the additional data on the indicia then the user may simply be asked for a password. In the case of banks and other financial institutions, the user would often be asked to, at some early stage in the branded transaction session, provide a Personal Identification Number (PIN) which is simply a short numeric password.

One of the advantages of the system described herein is that the timing within the session when user authentication takes place, or if it takes place at all, is optionally under the control of the selected institution. Selected institutions may authenticate at the beginning of the transaction, or only when the user first attempts to access certain information, or only when the user is requesting to do some transaction of value. Further, for particularly important or high value transactions, the institution might seek additional information to assure itself of the authenticity of the user and to prevent repudiation. The institution could also choose to require that for certain transaction types, or for high value transactions, the user use a TEM with particular capabilities such as one equipped with a camera or signature pad, or biometric measuring devices, or different pass phrases or keys.

A number of techniques well known to those skilled in the art are available for encryption of passwords or of other session information, or of both, to be transmitted across the network connected to the TEM, or to be stored on the TEM or the server/router to which the TEM's connected and including the translator and its storage and memory. Similarly well known techniques such as with a public key and private key encryption infrastructure can also be applied to encrypting all information that flows to or from the TEM and translator or such parts as are desirable. Such techniques can be variably employed during parts of a session between a user and an institution, at the control of the institution, or alternatively, as required by the system operator or in co-operation between the systems' various participants.

The authorizing authority would typically be the organization responsible for accounting for, tracking, and replenishing these items of value at that particular TEM (or a group of such TEMs). In systems of traditional bank ATMs and White Label ATMs, this would often be called the party that was "driving" the ATM, or the "ATM driver".

When a request for such a dispense of an item of value is received at such a TEM, the TEM will transmit this request to an authorizing authority responsible for that TEM. Within this system there may be multiple authorizing authorities but a particular TEM would preferably only have one authorizing authority associated with its dispense functions. That authorizing authority would likely further communicate the request to an institution that must agree to ultimately approve and fund the requested transaction. That ultimate approver is typically the institution that holds the account that will be charged for the dispense about to be performed. It is possible that another organization may be allowed to approve such requests on behalf of that ultimate approver. One type of such alternate approval is referred to as "stand-in" approval and may be conducted by the authorizing authority or automatically by prior arrangement, typically in circumstances where the authorizing network is down or the authorizing institution cannot be reached. It is to be understood that this discussion holds for the receipt at a depository provided at the TEM and managed and accounted for by the TEM's authorizing authority, which will follow a similar logical transaction series, for example instead of changing a user's account, adding to it to deal with said deposit in accordance with the institution's rules.

The format of the dispense request from the authorizing authority to the ultimate approver might be in any one of a variety of formats or mechanisms that may have been established between the authorizing authority and the ultimate approver. That format may be different from the format in which that authorizing authority received the request from the TEM, and it would in that case be the responsibility of the authorizing authority to translate as necessary between the different formats and schemes.

The common scheme in use to obtain authorization from the ultimate approver varies from industry to industry and even by institution within an industry. Within the banking community, for example, requests for authorization and approval is often done using a derivative of the ISO 8583 standard.

It is preferable for the TEM to transmit authorization requests to the authorizing authority in the form of ISO 8583 messages. One approach is for the authorization requests and related responses to be sent between the TEM and authorizing authority in a form where the message numbers, fields within messages, field contents and the meaning of all these are in compliance with or similar to the ISO 8583 standard but the encoding, representation and other aspects of the form and format of the data is in a document conforming to the XML standard. Such documents can be exchanged between the TEM and authorizing authority using the http or secure http (https) protocol, or any other communications protocol that can be made to work.

If the request is authorized, then one document is next accessed by the browser, and if the request is declined then an alternate document is accessed by the browser.

The appropriate document to be accessed, based upon the response to the request for authorization, may have been communicated to the TEM within a prior document accessed by the browser as part of its configuration.

Further, there can be multiple documents that could be accessed, where the one next accessed is dependant upon a results code contained in the response to said dispense authorization request. Additionally, the results code and other information contained in such a response can be made available to browser software on the TEM in a way that it can be substituted into the next page to be displayed, or used in processing the next page.

If the TEM fails to receive a response to a request for authorization within a certain period of time, then the software in the TEM can cause the browser to load a document where the URL of said document was supplied in a previous document. Again, a variable indicating that this "timeout" has occurred will be made available in the browser to control desired subsequent parts of that user transaction session. Since in a dynamically branded transaction execution system, there are a multitude of member institutions and a multitude of TEM owners, it is preferable to charge fees to the member institution based upon the use of TEMs by their customers. The system of this invention could track usage and account for and charge for use. If TEMs were to be leased to institutions for the duration of sessions, they could be charged a lease fee.

The revenue from the various fees, including the difference on sale and repurchase, could be distributed amongst the providers of the system and some or all of: the operator of the communication systems; the entity on whose premises the TEM is located; the entity that owns the TEM; the entity responsible for the maintenance of the TEM; and the operator of the routing and switching means.

The system can be made to track the usage of consumable items within the TEM including such items as paper, currency, coupons, general usage counters, ink, toner and the like, as well as other resource utilization such as screen display time, number of transactions, communications usage by time or volume, or otherwise, for billing, audit and maintenance purposes including predictive maintenance. One method of doing this is for the TEM to track its usage during each session and then at the end of the session transmit this information to the servers of the organization responsible for billing for the use of the system. This information could also be sent practically simultaneously to all properly interested parties so that they can perform their own reconciliation, audit and billing and other functions using that information. These other interested parties would include at least one of the owner of the TEM, the institution that conducted a transaction, the system's billing organization^", the operator of the routing and switching means, and the operator of the TEM. Subsets of the information could be provided as appropriate to preserve commercial confidentiality and user privacy. For example the maintenance operator for a TEM could be interested in knowing the total paper usage within a TEM so equipped but may not have a need to know which institutions accounted for what usage, or which users transacted with the TEM.

Alternatively, usage information could be stored in the TEM or elsewhere in the system for a period of time and then, periodically or upon request, communicated to the appropriate parties.

The system can differentially charge or credit its participants for each service provided, or can allocate various priority uses to TEMs at various times or locations. Additionally, the system may reallocate resources or may re-configure available TEM capabilities, or otherwise tailor the available transaction sets to balance resource utilization by Institutions and their users, and further, can differentially charge for its actions and services based upon usage, location, time, resource utilization and otherwise.

In addition, the system can accomplish or encourage optimum TEM and system utilization without restricting the transactions performed by the user by making information about the charges associated with any particular branding actions at any particular time and location available to the branding content (provided by the institution) immediately in advance of the content causing the configuration of the TEM, and at multiple and repeated points during the session whenever the branding content requests the then-current status, including causing some transaction element to displayed, such that the branding content may make certain transaction types, data or options available only to selected users at selected times or locations, based upon that information and the branding content's embedded instructions dealing with that subject-matter.

The system may charge differently for various permutations of services and benefits provided, such as (but not limited to) the encryption and logging of certain types of transaction data, which might bear a higher charge than unencrypted or un-logged transactions or data.

It was described previously how a portable device in operative connection to the TEM could be the source of identifying information necessary to begin a branded session on the TEM with an institution. In a further embodiment of the system the portable device could also be used to conduct all or part of the actual session with the institution, with the portable device using the TEM as a connection point to make use of the TEM's network connections in order to be able to communicate with the desired institution. A user could use the input capabilities, typically a set of keys or buttons, on the portable device to make entries and indicate selections.

The member institution's system could be displayed on the portable device to the extent appropriate to that device and as permitted or desired by that institution. All or a part of the provided transaction may be accomplished on the portable device or on the portable device and the TEM, dependent upon user requirements and user capabilities. Of course, privacy concerns would be dealt with in the accessibility or view-ability of information on these various devices to ensure optional user experience.

A number of users with portable devices might simultaneously use a TEM in this fashion. Further, these users of portable devices can be using the TEM substantially simultaneously with a user using the TEM directly.

One approach to support conducting transmissions on portable devices, is for the TEM to contain one or more browsers where one browser accesses a first XML document at the URL associated with said desired member institution as indicated by the portable user and said document and any documents and files to which said document points contain the transaction of said desired institution, and said branding is presented to the user on the portable device.

Translation of the content to a format supported at the portable device can be done in a variety of ways:

(a) a translator in the TEM can perform the translation or "clipping";

(b) a translator in the member institution can provide a set of contents suitable for the interface of the portable;

(c) the member institution's custom programming can perform the translation or "clipping"; or

(d) a translator in the processing and routing system can provide a service to do those things in (a) through (c) above.

A second approach to conducting transactions directly on portable devices is for the TEM to simply act as a network access point and data router so that the session at the transport level (e.g. TCP or WDP) is taking place between the portable and, as appropriate, the processing system and the desired institution. A second TEM with no network connection of its own could use wireless means to obtain its operative connections through another TEM which does have operative network connections for communication with member institutions and authorizing authorities.

A further embodiment of the multi-personality transaction system is in conjunction with a loyalty system or systems. The system can generate information that is useful to such loyalty systems. A user may present a loyalty card or similar indicia as discussed herein that will allow them to use the system to interact with the provider of that loyalty system for a variety of purposes including: seeing their account status; viewing transaction history; viewing points balance; seeing available awards or offers; requesting particular awards or merchandise; locating participating merchants.

The system as described herein can make use of Customer Relationship Management systems and can generate information that is useful for these systems. The system can capture and make data available to data mining applications. These activities could be limited to the extent necessary and formed in ways that are in accordance to the appropriate legal jurisdiction and in compliance with the agreements with the various participants. Also anticipated is that the system may have information about a particular user that would be useful to an institution. The information could come from several sources including one or more of: a CRM system, a data mining system, history of past use by the user, information previously provided by user themselves (for example information entered by the user at an associated web site, described herein.), information obtained from other sources. This information may be made available to the institution in a way that allows the institution to tailor what they present to the user. This information may be made available in variables in the TEM in a way that they can be read by the content of the institution as it is executing on the TEM. Alternatively, it can be made available such that during the session the institution can make a query requesting this information and this information would be returned in the response to this query. The technological form of storing this information, querying it and responding to these queries could take many forms that will be evident to those skilled in the art. The methods could be by way of example but not limited to: LDAP, message queues, Java beans (TM Sun Microsystems Inc.), various middleware or APIs.

Another embodiment of the multi-personality transaction system is for advertising or other informational purposes. During "standby" mode, in a wait site, when the TEM is not being utilized by a user to perform a transaction, it will be configured to display content which is not necessarily provided by or for a member institution, and which is not "branding" content in the sense disclosed here. Rather, in standby mode, the TEM may be configured in accordance with instructions provided by means of the router /switch, which may be stored at the TEM, at the router /switch, or elsewhere on the system pending its retrieval by the TEM. Such standby mode configurations can include, by way of example, advertising for member institutions or others, information kiosk-style functionality such as merchant catalogue browser, location/map service, product demonstration information, product or service specifications, in- store location query and mapping response, coupon or other value item dispensing which does not require the identity of the user or of a user account, direction-giving, reference to other locations or services, passive or interactive other displays such as games, contests, questionnaires or surveys, or the like. From the configured activities in standby mode available by operation of a dynamically branded TEM system as disclosed here, it may be seen that there are a variety of services the revenue from which the TEM owner, the member institutions, the router /switch provider and the network provider can share or otherwise deal with.

When a system-included TEM is used by a customer of a non-member institution, screens and other branding information in such a generic mode may not be specific to an individual institution, and the generic mode can still utilize the fundamental aspects of the dynamic branding system to increase the utility of the transaction session. In one example, an

ATM deployer, merchant or the operator of the system could enable a user to express a language preference from a range of available choices, and the system can display all the "generic" functionality (without specific branding) in the language of the user's choice. Further, the system can record the preferences expressed by the user as entered either at the TEM or through some other means or at some other time, and recall those preferences to modify the TEM's configuration.

The system as described wherein can be used where, without identifying a desired institution of the user, said user may use a TEM as an information kiosk. This is done simply by making a choice of one of the selections available on the "idle" or standby screen of the TEM. The content for the various segments of information or services available on this kiosk mode can be stored within the TEM or may be stored on a server accessible over a network, as is appropriate for the nature, timeliness and size of the content and or the capabilities of the TEM. Some or all of these information kiosk selections can be made unavailable at times when the TEM is being heavily used or to otherwise optimize the TEM's use.

Another embodiment of the present invention, is in conjunction with users having a multiple of card-based or otherwise accessible accounts or relationships, such as financial institution, credit card, debit card, loyalty card, frequent flier card, discount card, and other accounts or relationships maintained by a variety of institutions, some of which may be member institutions.

It is proposed that, by operation of the configurable TEM system with router /switch, network, translator and configuration systems, a user could provide the user's information for more than one user account (for example, swiping a card for each account), and that information (including, by example, an electronically replicable representation of the magnetic card medium's stored information) would be stored by the system such that, when desired, the user could make user's identity known (for example, swiping any of the cards for any of the stored accounts, or by providing other user identification such as an identity number or token issued by and recognizable to the system) to a system-enabled TEM and be provided with a listing of that user's accounts or relationship, from which listing the user could choose which account or relationship to proceed with to perform a transaction series.

It may be that no password or PIN information for any account would be stored on the system, such that the only component of the typical user-system transaction which would have been stored for future automated use (essentially by emulation of the information part of the transaction) would be the initial card-swipe (or similar) information providing step of the transaction, thus the security provided by the PIN system (or other equivalent) would not be compromised, although such an alternative is possible. In one embodiment, the account inputting portion of the set-up of this "macro-account" would include the step of issuing a new card or other physical medium upon which the user's identity (useful to the system) would be issued. This new physical medium might be by way of mag-card, smart-card, bar-coded card, RF-enabled smart-card, or other token or device. Alternatively, a user might be issued a number or manually re-keyable or enterable indicia. Alternatively, a user might be measured in some biometric sense (such as voice-print, retinal scan, thumb or finger print, or other identifying way, or in some combination), which when recognized later would provide for display of a "pick-list" of enabled user accounts or institution relationships at a TEM.

In another embodiment, from the pick-list provided to the user, more than one user account might be chosen with which the user might interact. This would, for example, enable a traditional style of value withdrawal from a first account, the storage or buffering of the value withdrawn, and the subsequent deposit of the value to a second account or a plurality of other accounts. At some steps during this "macro-account" interactive function, there may be branding by the institution with whom each account is kept. The second account might consist of a variety of value recipients such as a cash withdrawal of a portion of the value, a bill- payment with a portion of the value, the printing of a ticket, receipt, coupon, voucher or other thing of value in exchange for a portion of the value, the wiring of funds for a portion of the value, or the printing of a cashier's cheque or draft payable to a third party or to "bearer" or a traveler's cheque style of instrument for a further portion of the value. As can be seen, these examples and others, in many combinations and permutations, can serve as the basis of a new and improved use of a TEM suitably configured, to deal with the "unbanked" as well as the "multi-banked" end-user, in particular if the first thing of value is cash or some provable value instrument recognizable by the TEM for its receipt to the credit of the depositing user (or to the credit of the single anonymous transaction session).

The system could also allow value transfer to emerging payment systems such as Paypal — http://www.paypal.com.

In another embodiment, from the multi-account inter-account transaction display, two or mores users might transfer value from one account of one user to another account of another user. This might be accomplished by allowing a first user to enter a multi-account session by card-swipe, macro-account submission, or otherwise identifying the user and the desired account, and the desire to enter a multi-user multi-account session, and the subsequent entry of a second user's account and user identification to the system, with the other transaction steps being essentially as set out in the single-user inter-account value transaction. As well as the macro identity, which can provide for the identification of a user to the system, and of that user's various accounts at member and non-member institutions, the system, method and apparatus described herein may also provide the capability at the TEM for a user to perform during a single transaction session a variety of transactions including the withdrawal from a user account at one institution and the subsequent deposit at that user's account at another institution (or another user's account at any institution), which may as well provide as a benefit the instant acceptance of the said deposit without any holding or clearance process or time delay by the recipient institution, by additional example, by guarantee of the system operator to the recipient institution of the funds or value, since said operator would have obtained authorization or cash from the institution from whose account the value was initially withdrawn.

In a further embodiment, the multi-personality transaction system could have a web site associated with it. The uses of this web site could include one or more of the following: A user enrolling themselves to the web site and related system (this may have to be completed at a TEM that provides additional user identification capabilities such as a signature pad, a camera to capture the users image, biometric id capability, depending upon the use).

A user viewing and printing previous transaction conducted at TEMs in the system.

A user setting and changing preferences for use when the user is using a TEM that is part of this system.

A user placing certain restrictions on their information or its use.

A user finding the location of publicly accessible TEMs including locating just the ones with a particular capability, such as signature pad or depository, that the user intends to use.

A user enrolling and setting up a macro account (also known macro identity) as described herein.

A user setting up transactions, including without limitation, purchases, large transfers, service cancellations, service enrolment, which require the user to later complete them by authorizing them when present at a TEM suitably configured for the level of authorization security needed for the particular type of transaction.

In a further embodiment of the system, a portable TEM can be used to setup a transaction that is meant to be completed at a later time at another TEM which has more capabilities. For example, a user may request to receive cash or to deposit an item when they are at a TEM that does not have the ability to dispense cash or receive such deposit of a physical item. The user can be provided with a receipt or code or other means such that later when the user is at a TEM that did have requisite cash dispensing or deposit taking capability they could use this receipt or code or other means to receive the cash or otherwise complete the transaction. Another example of why a user may be required to complete a transaction at a TEM with additional capability, is that an institution may wish to finalize a transaction only when additional means of identification is provided such as by way of capturing an image of the user, signing and then depositing a form printed on the TEM, entering a signature on a signature pad, authenticating the user by some biometric means, or authenticating the user by other means.

Referring to Figure 1, a transaction execution system 8 includes a plurality of transaction execution machines, hereafter referred to as TEMs 10, connected to a processing and routing system 12. The switch system 12 interconnects the TEMs 10 with a plurality of member institutions 14, including but not limited to financial institutions such as banks and brokerage houses, and non-financial institutions such as merchant organizations and individual outlets thereof. A database 13 can be used by the TEMs 10 for required information. Alternatively, the router 12 may also have access to a database 13a containing the information. This however, depends on the latency and bandwidth of the link to the TEM 10.

The TEM 10, shown in Figure 2, includes an identification device 16 (preferably a card reader), a user interface 18, and a material device 20 for providing and optionally receiving materials to and from a customer (not shown) respectively, such as but not limited to cash withdrawals and deposits, cheques, coupons cards or stored value cards, a plurality of transactions requiring a proximity of physical media or storage devices to the system 8, product information and advertising, plus any other transactions and communication to the maximum extent permitted by the technology and capability of the member institutions 14 to which the balance of system 8 is ultimately connected. The plurality of transactions may not necessarily involve a transfer of a physical entity, for example money could be transferred to a stored value card. A data storage module 15 may be used to keep on site transaction records and may also be used to store the identity and/or functionality of the user interface 18 defined by the member institutions 14.

The user interface 18 of the preferred embodiment, shown in Figure 3, is used to communicate desired information between the customer using the TEM 10 and any of the member institutions 14 sharing the transaction execution system 8. Different forms of communication include a display 22 and a keypad, touch pad 24 or touch screen, or any combination of user input devices known in the art for the entering of numerical information, non-numerical information, and the selection of presented options, including by measurement of user biometrics at or available to the TEM. In addition, an audio system 26, a video system 28, and/or a keyboard 30 may also be included if desired. The user interface 18 facilitates the dynamic branding of the TEM 10 with the identity and or functionality defined by the member institutions 14 or other businesses at any given time. Multiple displays may be used in the TEM 10, some of which may be dedicated as a static sign similar to those in conventional captive ATMs.

In operation of the transaction execution system 8, the user's desired institutions, is first identified based on identification information obtained from the user by the identification device 16, which in the case of a card reader is accomplished by entering a card in the device 16. The TEM 10 uses the identification information to connect by the switch system 12 to the member institutions 14 thus coupled. The user interface 18 is subsequently modified according to identity and/or functionality to a full service transaction machine. The TEM 10 preferably provides the full service desired by that customer. Once the customer is finished a transaction session, the TEM 10 can revert to a standby mode, or wait state, and is ready for interaction with another customer. During this standby mode a user may, with or without providing identification or being identified, use the TEM 10 as an information kiosk, if desired.

In an additional embodiment, the customer may through the user interface 18 create a macro account which relates the user to two or more institutions 14 of which the user is a customer or participant. The user may subsequently conduct a macro account transaction whereby the customer can access a plurality of accounts from different member institutions 14 as though each of the accounts were all held at one combined institution. The user can conduct transfers of value between an account at one institution and a second account at a second institution. The term macro account and macro identity are interchangeable herein.

Another embodiment of the present invention is a macro function that allows transactions between cards and/or accounts belonging to different people, such as between spouses and friends. It is not necessary that both people be at the same TEM at the same time. The design and behavior of the user interface 18 may be tailored to the needs of the customer.

This may be done by institutions 14 or also by the routing system 12 or by the TEM 10. The system 8 may also provide tailoring for macro users and generic users in addition to the tailoring supplied by member institutions 14. Examples of this additional system tailoring include: a tailored system identity that could be one, or a combination of more than one of the user's identities with individual member institutions 14; the case where the system 8 provides information about itself or its member institutions, to any person who is not known at that stage to be a customer of any member institution 14. In a further embodiment, shown in Figure 4, a plurality of external devices 30 may be connected to the execution system 8. The devices 30 can include but are not limited to a portable TEM such as a cell phone, a lap top, or a personal computing device, a third party transaction system, or the like. The overall character of the transactions on the external device 30, where it is a TEM 10, as well as the type and the number of possible transactions thereon is only limited by the capabilities of the user interface 18 of such device 30. A connection 32 between the device 30 and system 12 is accomplished preferably by a modem, wireless connection, or the like. The connection 32 can also be made via the internet, private intranet, through many associated networks, or any other communications device, or combination of devices, capable of facilitating the required data transfer. This embodiment allows the user to conduct a plurality of transactions from a location chosen by the customer on an interface controlled and branded at the direction of a member institution 14.

In another embodiment, shown in Figure 5, the execution system 8 contains TEMs 10 connected by the router 12 to a plurality of traditional financial transaction networks 32. The networks 32 and device 30 in turn are connected to member financial institutions 14A. This arrangement provides for the execution system 8 to be connected to already existing or newly established networks 32, rather than directly to individual member institutions 14A, to effect desired transactions on TEMs 10 with selective numbers of such institutions 14A.

In a further embodiment shown in Figure 6, a number of TEMs 10A, 10B, 10C, 10D and 10E are operatively connected by the routing and processing system 12 to member institutions

14A, 14B and 14C. The TEMs 10A, 10B and 10C are connected to the routing and processing system 12 by means of a network 40. Additional TEMs 10D and 10E are on a differently configured network 45 and are preferably connected to the same routing and processing system 12. The routing and processing system 12 is further connected by means of a third network 50 to member institutions 14A and 14B and to member institution 14C by means of the a fourth network 55. The routing and processing system 12 can perform routing and, as necessary, translation between TEMs 10A, 10B and 10C on network 40, where it is for example a wireless WAP based network, and the member institutions 14A, 14B and 14C on network 50 which is for example an IP based intranet. It should be noted that more than one router 12 can be used in the system 8, if desired.

In a separate example, the same Figure 6 can be used to illustrate that if network 45 were an IP based network and the network 50 were also an IP based network, the networks are the same type and data flowing between one TEM 10E and one member institution 14B would merely need to be routed and may not need to be translated. If the database 13A contained the table for relating institution identifiers to member institution information locators being URLs, then TEM 10E could provide this data in a request to the routing and processing system 12 which would respond with the URL for the transaction information of member institution 14B, which could be at that same member institution 14B. The session between 10E and 14B would then proceed where only the packet based routing capability of 12 would be used during the session. However, if that same TEM 10E was to begin a session with member institution 14C, which can only perform transaction by means of an network 55 of a different type, by way of example only in a legacy consortium system using ISO 8583 messages over an X.25 network, part of its transaction could be served by the routing and processing system 12and the session would proceed as follows. The TEM 10E would send a request to the routing and processing system 12 containing the identification for member institution 14C. The routing and processing system 12 would respond with a URL, which for member institution 14C's transaction system is in this example located within storage at router 12. The TEM 10E would then begin the session with router 12 and router 12 would, where necessary, convert transaction requests to ISO 8583 and send them via X.25 on network 55 to institution 14C. Responses from member institution 14C received over network 55 by system 12 would be translated to XML over TCP/IP to be sent over network 45 to TEM 10E.

In a further embodiment, also represented in Figure 5, the execution system 8 is connected to one or more Authorizing Authorities 31. Each Authorizing Authority is responsible for managing the items of value in one or more TEMs 10. A given type of item of value (for example cash) in a given TEM 10 is typically managed by the Authorizing Authority 31. The TEM 10 can receive authorization for transactions involving items of value either by a connection from the Authorizing Authority 31 to the relevant institution, or by using the connections that the system router 12 has with all parties.

The branding content within the TEM 10 initiates a transaction request for the dispensing of an item of value from the TEM 10. The TEM 10 determines that the transaction requires approval by an Authorizing Authority 31. The TEM 10 creates a message based on the transaction request and sends the message to the system router 12. The system router 12 determines which Authorizing Authority 31 is responsible for approving transactions of that type from that specific TEM 10. The system router and its translatorl2 translates the message if necessary to a format appropriate to the Authorizing Authority 31, and sends the message to the Authorizing Authority 31. The Authorizing Authority 31 determines which institution 14 with which to authorize the transaction.

The Authorizing Authority 31 can have a direct or indirect connection to the institution 14A, and the Authorizing Authority 31 may translate the request if necessary to a message and/or format appropriate to the institution 14A and send the request to the institution 14A. The institution 14A determines whether the request will be accepted, modified, or denied. The institution 14A sends the response back to the Authorizing Authority 31. The Authorizing Authority translates the response if necessary, and in turn accepts, accepts with modifications, or denies the transaction, sending a response to the system router 12. The system router 12 translates the response if necessary, and sends the response to the TEM 10.

In yet another example, as shown in Figure 5, instructions within a translator in the TEM 10 can initiate a transaction request for the dispensing of an item of value from the TEM 10. The TEM 10 determines that the transaction requires approval by an Authorizing Authority 31. The TEM 10 creates a message based on the transaction request and sends the message to the system router 12. The system router 12 determines which Authorizing Authority 31 is responsible for approving transactions of that type from that specific TEM 10. The system router 12 translates the message if necessary to a format appropriate to the Authorizing Authority 31, and sends the message to the Authorizing Authority 31. The Authorizing Authority 31 determines which institution with which to authorize the transaction.

The Authorizing Authority 31 translates the request if necessary to a message and /or format appropriate to the system router 12, and sends the request to the system router 12 directed to the institution 14A. The system router 12 translates the request if necessary to a message and/or format appropriate to one of the plurality of financial transaction networks 32 that connect directly or indirectly to the desired institution 14A. The transaction network 32 routes the request to the institution 14A. The institution 14A determines whether the request will be accepted, modified, or denied. The institution 14A sends the response back to the financial transaction network 32. The financial transaction network 32 sends the response to the system router 12 directed to the Authorizing Authority 31. The system router 12 translates the response if necessary to a message and/or format appropriate to the Authorizing Authority 31. The Authorizing Authority 31 translates the response if necessary, and in turn accepts, accepts with modifications, or denies the transaction, sending a response to the system router 12 directed to the initiating TEM 10. The system router 12 translates the response if necessary, and sends the response to the TEM 10. This alternative provides a way to reduce or eliminate the multiple connections between many or every of the plurality of Authorizing Authorities 31 and the plurality of financial transaction networks 32 and institutions 14.

In a further embodiment, the transaction execution system 8 is used by virtual institutions, such as virtual banks and or merchant organizations that do not have traditional brick-and-mortar locations. This allows these virtual institutions to have, in effect, multiple TEMs 10 provided by the system 8, tailored to the needs of the individual virtual institutions. In an additional embodiment, the customer may through the user interface 18 create a macro account which relates the user to two or more institutions 14 during the same transaction session, of which the user is a customer or participant. The user may subsequently conduct a macro account transaction whereby the customer can access a plurality of accounts from different member institutions 14 as though each of the accounts were all held at one combined institution. The user can conduct transfers of value between an account at one institution and a second account at a second institution. The term macro account and macro identity are interchangeable herein.

A macro function can allow transactions between cards and /or accounts belonging to different people, such as between spouses and friends. It is not necessary that both people be at the same TEM 10 at the same time.

Referring to Figure 8, the transaction might be sequentially done, or the representation of the transaction on the TEM's display (22) might include sub-components (310, 320, 330) of the display (22) to the user which were branded, surrounded or contextually inter-related by a representation of a multi-brand, multi-account transaction scheme (such as -in a metaphorical sense- by animated arrows (310) or other indication of "movement" of "value representations" from one "account location" (320) to another (330) in Drawing Fig. 8.

The design and behavior of the user interface 18 may be tailored to the needs of the customer. This may be done by institutions 14 or also by the routing system 12 or by the TEM 10. The system 8 may also provide tailoring for macro users and generic users in addition to the tailoring supplied by member institutions 14. Examples of this additional system tailoring include: a tailored system identity that could be one, or a combination of more than one of the user's identities with individual member institutions 14; the case where the system 8 provides information about itself or its member institutions, to any person who is not known at that stage to be a customer of any member institution 14.

It should be noted that one benefit of the present invention is that member institutions

14 can provide customer access to full service TEMs 10 over a large shared network of dynamically branded TEMs 10, while preserving the ability of each member institution 14 to control, brand, and benefit fro their customers interaction with the system 8. The system 8, in addition to financial transactions, can also be used with other types of transactions including the issuing of royalty coupons, product information, and the gathering of data for loyalty or other marketing cross-marketing or commercial purposes. This customer data, collected by specific member institutions 14, or by the routing system 12, could be shared with other member institutions 14, or others, if desired. Although the invention has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art without departing from the spirit and scope of the invention as outlined in the claims appended hereto.

Claims

We Claim:

1. A TEM system comprising:

- a TEM including capability of providing one transaction type outside of the scope of transaction types supported by legacy financial networks as well as one transaction type within said scope

-a financial institution including a web site useable by its customers for consumer web banking and legacy ATM network facilities

- a financial transaction network operatively connecting said TEM and said financial institution including a translator with:

- capability to accept and forward data for collection, a request from the TEM for data from said web site or a request from the TEM for a transaction involving said web site in order to effect transaction types outside of said scope

- capability to intermediate communication between said TEM and said legacy financial network facilities to effect said transaction types within said scope

2. A TEM system as in claim 1, with the additional capability provided in said system to log in or otherwise identify a TEM user and to provide from within said system user id and password, card mag-stripe and PIN and similar disparate types of identification and authentication steps as required by each of the transaction types within and outside the said scope as needed without further incidental input from said user

3. A TEM system as in claim 1, with the added capability either within the financial institution's said web site or within said translator or within a combination of those things, to recognize said TEM user, either as an individual or a member of a predefined group of individuals, the recognition of which individual or predefined group provides information to the system which is used to cause the TEM to initiate a transaction or communication by the TEM to the TEM user without request or further input by said user.

4. A TEM system as in claim 1 where a TEM user is known to said financial institution's web site and is identified and authenticated at the TEM to said web site by use of one set of identifiers (such as conventional web login, token, card and PIN, userid and password, biometric identification or other known identification means), and where said web site includes other sets of identifiers (such as electronic or digital representations of conventional web login, token, card and PIN, userid and password, biometric identification, or other known identification means), and where said web site can be caused by said translator to provide said one of said other sets of identifiers as appropriate to a step in a transaction being carried out on said TEM by said user without said user being required to provide said other identifier set.

5. A TEM system as in claims 1, 2, 3 and 4 where said translator accesses more than one web site, each of which is from an unrelated institution and the second of which may be from other than a financial institution, the transaction performed at the TEM for said user including a compilation of one or more of: traditional ATM transaction, web-based banking information, web-based banking transaction, and non-banking informational display.

6. A TEM system as in claim 5 where said non-banking informational display is provided by a web site accessed by said translator responsive to either the TEM system or to said user's inputs to present, modify, transact or gather data, whether or not said financial institution and said accessed web site are related in any other way.

7. A TEM system as in claims 1 through 6 where the transaction series performed at the TEM for the user provides an experience to the user with transaction type, data requests, data

' and information provided to and by user, and transactions proposed and done by and for user appear to be integrated.

8. A TEM system as in claim 1 where said translator includes XML or other self-defining data path or communications definition capabilities, whether in information transactions or relations between TEM and translator, translator and web-site, translator and financial institution, or any combination of those transactions or relations.

9. A business process where a TEM system as in any of claims 1 through 8 is provided, where the operation of the translator is done by the financial institution or for the financial institution (for example by a consortium such as Interac, Star, Ficanex or similar entity).

10. A business process where a TEM system as in any of claims 1 through 8 is provided by a party independent of the transactional information provided at the TEM to a user for a fee.

11. A business process provided in either of claims 9 or 10 where a fee is paid by one of: the financial institution, the web-site provider, the TEM provider, or the user, or a combination of those parties, or by a third party advertiser or party controlling the physical location or access to the TEM.

12. A TEM system as in claim 4 where said system knows the user by reason of the user having previously enrolled with the translator, providing the identification and authentication information required by the translator either in a formal enrolment step or by the translator having captured said identification and authentication information coupled with and related to said user's identity in one or more previous transactions (including prior steps in an instant transaction series).

13. A TEM system described in either claim 4 or claim 12 where the system's knowledge of the user and of the user's identification and authentication information which is useful to other systems in the provision of a series of transactions is provided by said translator to facilitate that series of transactions at the TEM for the user on a variety of different systems including one or more of: a transaction within the said scope (of transaction types supported by legacy financial networks), a transaction outside the said scope, information retrieval or transactions with websites or third parties regardless of said scope.

14. A TEM system described in any of claims 1 through 8 or 10 through 13 where the financial institution causes its systems or web sites to accept identification and authentication provided at the TEM in substitution for the financial institution's ordinarily or usually required authentication and identification information.

15. A translator within a TEM system to operate a multi-institution, multi-network transaction system, said TEM system including:

- a legacy ATM system where such system is required to effect a transaction set proposed by a user at said TEM

- a web-based banking system where such system is required to effect a transaction set proposed by a user at said TEM

- one user account accessible by each of those two systems where the translator is to aid in accomplishing a transaction between said two systems which could not be accomplished using either system alone, but otherwise no such overlapping account is required

- a series of overlapping accounts, that is a series of sets of two systems sharing at least one account where a third (and further iterations along the same conceptual basis) system shares an account with one of the systems in the prior set of two systems sharing an account between them (thus linking, through as series of linked sets, a chain or larger set of systems) where a desired transaction between one account in one system and another account in another system with no inter-system shared account may be accomplished in a series of related transaction steps.

16. A system as in claim 15 where the provision of identification and authentication indicia appropriate to a first system served by the translator-enabled TEM system to the TEM is used to automatically cause the translator to provide different but appropriate identification and authentication indicia to a different system as required by said different system to accomplish a transaction series proposed by the user at the TEM by either:

- the user having pre-enrolled either consciously directly with the translator as an independent process or by behavior during prior transactions involving the user, identification and authentication information captured and stored by the translator in the translator or into a data store accessible to the translator so that the translator can use one identification and authentication information pair to obtain access to and use of the other identification and authentication information required

- the institution providing a transaction system to the translator-enabled TEM system (whether web-based banking or legacy in format) which accepts the identification /authentication information first provided by the user at the TEM as a suitable substitute for a usual identification/ authentication means, which will require access by the translator to information with regard to acceptable substitution identification and authentication pieces

- an institution permitting the translator, using different user identification and authentication information of the user's, to access the institution's databases of users and identification/ authentication information to retrieve and use that institution's user's information to access that institution's transaction systems and permitting the translator to use the found data to identify and authenticate the transactions required with that institution's systems as part of the user's proposed transactions at the TEM

17. The use of a TEM system by a user which system is provided by any of claims 1 to 16 inclusive

18. The provision by any combination of the following parties of a TEM system to a user provided by the TEM system claimed in claims 1 through 16, said parties being: a financial institution, a network switch or router or translator operator, a consortium of financial institutions, the agent of a financial institution, a communications system provider, an ATM or TEM owner, and an ATM or TEM operator.

19. Computer readable medium for providing codes for directing a TEM system described in claim 1 to: - accept and forward data for collection, a request from the TEM for data from said web site or a request from the TEM for a transaction involving said web site in order to effect transaction types outside of said scope

- intermediate communication between said TEM and said legacy financial network facilities to effect said transaction types within said scope