HK1074893A - Method and system of facilitating automatic login to a web site using an internet browser - Google Patents

Description

Method and system for facilitating automatic login of web site using internet browser

no marking

no marking

no marking

Cross reference to related applications

This application is a Continuation-In-Part application Of U.S. patent application 09/429,585 filed On 28.10.1999 (containment-In-Part), and is a Continuation-In-Part application Of U.S. patent application 10/015,816 filed On 1.11.2001, entitled "Method and System Of marketing On-Line Shopping Using An Internet Browser", both Of which are now pending (pending). This application also claims priority from the filing of U.S. provisional patent application 60/331,565 on 16/11/2001.

Technical Field

The present invention relates to a method and system for adding functionality to an internet browser interface.

Background

When accessing the Internet (i.e., the world Wide Web, network, etc.), typically, an Internet user initiates or activates a browser software program, e.g., Netscape Navigator, via a computer^TMOr Microsoft Internet Explorer^TM. A browser program (also referred to herein as a browser) establishes a link between a user's computer and the internet (e.g., via a modem and an Internet Service Provider (ISP)), and provides a textual and graphical user interface, i.e., a browser interface, that has a predetermined appearance and functionality, neither of which is currently significantly changeable by an internet user. Thus, the browser interface remains relatively static as an internet user browses the internet, moves from website to website, from application to application, or from HTML (hypertext markup language) page to HTML page.

Limited control of the browser interface is currently available through executable software programs that can, for example, add function buttons to the browser interface. However, additional functionality is added to the browser interface when the browser is initially activated, and remains stationary thereafter. Thus, a browser displaying a browser interface modified as just described is not able to dynamically download information from an internet site and customize when the browser is initialized or the user browses the internet. Such a modified browser interface also does not provide plug-ins and interfaces with access to various browser Application Programming Interfaces (APIs). Therefore, there is a need for: methods are provided for modifying a browser interface and for providing a browser interface that overcome the shortcomings of the prior art described above.

When accessing a particular website, a user may have to enter a user identifier and password before being allowed to access data via the website specific to the user. For example, most financial institutions, investment companies, and other service providing entities, including, but not limited to, online shopping websites, allow a user (or a customer of the entity) to access his or her account via the internet. For obvious reasons, the user is required to enter certain user-specific information before gaining access to the user's account. For example, to establish an online account, a user may be required to provide certain user-specific information, such as a user identifier and password. Once the user-specific information is provided, and the online account is established, the user may only have access to his or her online account, which provides the user-specific information as part of the login process.

It is not uncommon for users to maintain multiple online accounts (involving multiple financial institutions, investment companies, and other service providing entities) that are accessible through multiple websites. Although it is conceivable that the user could use the same login identifier and password for each of the multiple web sites, such practice is not recommended. In fact, it is a preferred, recommended practice to use a different login identifier and password for each online account. This will increase the security of the user's online accounts if someone happens to obtain one of the user's login identifier and password, reducing the likelihood of unauthorized access to these accounts. However, there is a problem of its own in using different login identifiers and passwords for each online account; it is not trivial to remember each login identifier and password.

There is also a need for users to obtain information from one or more websites without having to navigate to each website. Further, there is a need for a simple, quick use of an internet browser to obtain such information.

Disclosure of Invention

The present invention relates to a method and system for adding functionality to an internet browser interface. In one embodiment of the invention, the added functionality may facilitate automatic login to a website using an internet browser. In another embodiment, the added functionality may allow the user to perform various tasks using an Internet browser, such as, but not limited to, performing various tasks necessary to browse one or more web pages, or to obtain information desired by the user from one or more web pages or websites.

According to an embodiment of the invention, computer code is transmitted from the server to the user's computer, which adds specific functionality to the user's Internet browser. Thus, the present invention provides dynamic control of an Internet browser interface that allows a user to selectively add buttons and/or toolbars to the browser interface and add features and functionality to the browser. In a preferred embodiment, the computer code allows the user to modify a browser interface that selectively adds interface objects to the Internet browser interface. The interface object may include a button that may be added to the browser interface as part of an existing toolbar or as part of a new toolbar added to the browser interface. This button allows the user to access the merchant list and also adds an auto-login feature to the browser. Access to the merchant list allows the user to add merchants, edit merchants, and select merchants, which are used for automatic login. Once the button is added to the browser interface, the user can click on the added button, generally referred to herein as an auto-login button, and gain access to a drop-down menu that displays one or more merchants as a merchant list. By selecting one of the merchants on the merchant list, the functionality added to the browser in accordance with the present invention will cause the user to automatically log into the selected merchant and cause the user's browser to navigate to the merchant's website. The process is essentially transparent to the user and is initiated when the user selects a merchant from the merchant list.

Preferably, the automatic login functionality provided in accordance with the present invention uses a secure login process that requires the user to enter a security key before the automatic login process for the selected merchant is complete. If the user has not entered a security key during a particular internet session, or if the user entered a security key during a session, but a predetermined amount of time has elapsed since the time the security key was entered, the user will be prompted to enter a security key as part of the automatic login process. The automatic login process will only be performed after the correct security key is entered. The secure login process described above may be performed by the secure server or the user's computer.

If the user has securely logged onto the secure server during an Internet session, a secure cookie may be transmitted from the secure server and stored on the user's computer. If the secure cookie is present on the user's computer and valid (i.e., it has not expired, for example), when the user selects a merchant from the merchant list, the computer code transmits the secure cookie to the secure server as part of the first request. The security server receives the request and determines whether it contains a security cookie, which is valid. If the first request contains a valid security cookie, the security server transmits an acknowledgement to the computer code, which in turn transmits a second request to the provisioning server (which may be the same or different from the security server, depending on design choice). The second request includes a user identifier and a merchant identifier. When the provisioning server receives the second request, it compares the user identifier and merchant identifier with the database entry to determine if there is a match. If a match is found, the provisioning server transmits a certificate request to another server, which may be a secure server. The other server includes a secure database having a plurality of data for a plurality of users. The data for each user is identified by a user identifier and may include a login identifier and a password for each of a plurality of merchants, each of the plurality of merchants having an associated merchant rule file. Each database entry contains a login identifier, a password, and a merchant rules file, which entry may also be referred to herein as a certificate. Once the credentials associated with the merchant selected by the user are determined, the other server transmits the credentials to the user's computer. Upon receipt of the credentials, computer code provided in accordance with the present invention causes the user's browser to navigate to a predetermined web page, such as a login web page, for the selected merchant, and automatically fills in any fields on the web page necessary for the user to login and access the user's account. Furthermore, the process is transparent to the user. If the automatic login is successful, the merchant web page (which typically follows the successful login) will be transmitted through the merchant's server and displayed in the user's browser window.

Thus, by selecting a merchant from a list of merchants, a user is able to automatically navigate and log into the merchant's web page and access the user's account.

As used herein, the terms "control" and "controllable" refer to, for example, but not limited to, adding, removing, and modifying an Internet browser interface. An internet browser interface, as referred to herein, refers to a visual or audible presentation presented to a browser user through which the user interacts with the browser. The term "customized" (and variations thereof) may also be used herein to describe the controllability provided in accordance with the present invention. As used herein, the term "dynamic control" (and variations thereof) refers to a method by which a portion of an Internet browser interface (i.e., an interface object) can be selectively added, displayed, and periodically changed or updated.

A browser, as used herein, is given its usual, industry-recognized meaning, typically referring to a software program that provides an interface to the world wide web or the internet. Browsers allow internet users to browse the internet, establish connections to various internet sites (also referred to herein as web sites), and view web pages provided by content providers at the various internet sites. In particular, browsers have the ability to invoke ActiveX controls or plug-ins through internet sites. Browsers also allow internet users to navigate between internet sites, i.e., surf the web. The browser provides a browser interface to the internet user in a format determined by the provider of the browser software program. Typically, the browser interface defines the layout (e.g., color, size, number and location) and functionality that the browser provides to the internet user. The browser interface may include a first parent window, which typically defines the general size, color, and layout of the browser interface, and contains window control buttons (e.g., minimize, close, etc.). The browser interface may also include a second parent window (which may be a child of the first parent window), and one or more windows that depend on the second parent window. The second parent window and the windows dependent thereon may provide, for example, various information (advertisements, coupons, news, HTML links, etc.) and functions (toolbars, drop-down menus, plug-ins, applications, etc.) to the internet user.

An ActiveX control, as used herein, refers to a tool for linking desktop applications to the Internet, based on industry-recognized, Microsoft-developed specifications. A plug-in, as used herein, refers to a type of program that is developed for use with Netscape browsers and is integrated with a larger application (e.g., a browser software program) to add specific functionality or capabilities to the larger application. The ActiveX controls and plug-ins referred to herein as described above can be used with any internet browser.

As used herein, the term "internet site (or website)" refers to a location on the internet, which is defined by an internet address or URL (uniform or universal resource locator). As used herein, the term "Internet web page" refers to a collection of hypertext markup language (HTML) commands provided at an Internet site that provide formatting information for text, images, and functions to create a hypertext document that can be displayed on the Internet user's computer display through a browser. For example, an internet user enters a URL to establish a connection to an internet site that provides HTML commands to the user's browser so that the web page of the internet site can be displayed on the user's computer display. The browser interprets the HTML commands embedded within the web page and uses the HTML commands to format text and images for the web page.

The present invention provides advantages to internet users, internet content providers and Internet Service Providers (ISPs). For an internet user, the present invention provides a method of dynamically controlling or customizing the user's internet browser interface. Internet users can now customize browser interfaces so that each time a user accesses the internet using a browser, user-defined information and/or functionality (collectively referred to herein as information) will be displayed at the browser interface. For example, the user may include bookmarks, address books and phone books, personal financial information, personalized news, and various functions, such as available through ActiveX controls and plug-ins.

Additionally, if an internet user has an account with a content provider, the browser may now dynamically display the user's specific account information on the browser interface. Currently, an internet user can only access specific account information of the user when connecting to the internet site of the content provider. The user must return to the content provider's site to receive updated account information. Once the user leaves the internet site, the account information is no longer displayed on the browser interface. The present invention provides a method of dynamic control, and a dynamically controllable browser interface, that allows an internet user to display and continually update information and/or functionality specific to the user on the browser interface.

For a content provider, the present invention ensures that an internet user (via a browser) automatically establishes a connection to the content provider's internet site each time the user accesses the internet using the browser. Thus, once an internet user causes the browser to execute (e.g., by selecting a browser icon), the browser automatically establishes a connection to the content provider's internet site to load the user's customized browser interface information. The present invention may also periodically and automatically prompt the user's browser to connect to the content provider's internet site while the browser is active and while the user is surfing the web. In one embodiment, a content provider may provide internet users access to a program for controlling a browser interface. Once an Internet user accesses the control program to customize the user's browser interface, the user's browser may automatically establish a connection to the content provider each time the user accesses the Internet. Thus, in contrast to currently available browsers that establish a connection to an internet site only when a user enters a URL (or otherwise physically acts to cause a connection to be established, say, by selecting a link or advertising banner), the present invention automatically establishes a connection to a content provider upon browser initialization, independent of any home page selections preprogrammed into the browser, whether this be an internet user or a browser vendor's selection. Once the initial connection is established, the content provider may load the internet user's computer with user-specific information and/or functionality to display a browser interface to the user.

In addition, the content provider may also periodically cause the browser to automatically reconnect to the content provider's Internet site to update, download, or otherwise transfer new information and/or functionality for the Internet user's browser interface. For example, if an internet user subscribes to a content provider's email service, the internet user's email messages received by the content provider may be automatically transmitted to the internet user even though the user is "surfing" elsewhere. When the user's browser executes, the user's browser initially establishes a connection to the content provider's internet site, and the information transmitted by the content provider to the internet user includes instructions for the browser to periodically reconnect to the content provider's internet site. Thus, regardless of the number of internet sites visited by the user, and regardless of which particular internet site the user is currently visiting, a connection back to the content provider's internet site will be automatically established at intervals determined by the content provider; these reconnections are transparent to the internet user except when the user receives notification from the content provider (i.e., new mail arrives). Thus, the browser interface may be dynamically controlled while the internet user surfs the web. For ISPs, the benefit is at least as great as for content providers.

Initially, the internet user's browser interface must be customized using a software program, which may be provided by the content provider or ISP, or may be available on the user's computer. The software program, hereinafter referred to as computer code, control program or program for control (and variations thereof), changes the way the user's browser works. More specifically, the control program downloads or creates library files on the internet user's computer. The library file may be, for example, a Dynamic Link Library (DLL) (for Windows operating system) that creates a shell (or shells) within the browser into which various information and/or functionality may be loaded as an ActiveX control or plug-in. The library file contains ActiveX controls or plug-in functions that define interface objects to add to the browser interface in accordance with the present invention. When an internet user launches or activates a browser, a library file is opened and the ActiveX control or plug-in code contained therein is made available to the browser and integrated into the browser interface, causing the interface object to be displayed on the browser interface. The shell (or shells) will remain open as long as the browser is active, typically as long as the user surfs the web, the library file, and, in turn, the shell (or shells). Thus, the information and/or functionality for customizing the browser interface and loading into the shell remains active even as the user moves from internet site to internet site. As used within the context herein, the term "information and functionality" refers to any information, data, and/or software driven functionality that may be contained by or part of a library file.

When a user initially activates the browser, the library file also causes the browser to establish a connection to the content provider's internet site. The content provider's internet site will load the information and/or functionality for the interface object into the user's computer for use in the browser and display to the browser interface. If, for example, the user has an account with a content provider, the information and/or functionality loaded by the content provider may be specific to the Internet user. As another alternative, the content provider may load general information and/or functionality if, for example, the user does not have an account with the content provider (i.e., it is a guest).

The present invention uses Object Linking and Embedding (OLE) in-process (in-process) servers to control information and/or functionality of a browser interface. Using ActiveX controls or browser plug-ins contained within library files, each referred to herein as a Browser Interface Overlay (BIO) library, virtually any information and/or functionality available to the ActiveX controls or plug-ins can be added to the browser interface using the present invention. The library file (via the BIO library) thus contains the code necessary to customize, i.e., add, delete and/or modify the browser interface.

Once an internet user accesses the control program and customizes the operation of the user's browser, the customized browser interface is displayed when the browser is activated. In contrast to prior art browser modification methods, the present invention provides a method and browser interface that can be dynamically controlled. As internet users surf the web, updated or changed information and/or functionality may be transmitted to the browser and displayed on the browser interface while maintaining the information and/or functionality of the browser interface customized. Thus, whenever a user is surfing the web using a browser, the internet user may automatically receive up-to-date information, such as stock quotes, emails, new headlines, on any internet site on the user's browser interface.

The present invention also provides a method and system that facilitates online shopping by modifying a browser interface to provide shopping assistant buttons and functions. The modified browser interface provided in accordance with the present embodiment of the present invention simplifies online shopping by creating a wallet for each shopper or user. The wallet is stored in a database on a secure server, accessible, usable, or modifiable only by the user, and associated only with the user-provided security keys. The wallet contains user-provided information that can be ported directly to a supported merchant checkout web page. Thus, when a user is shopping online at a merchant's website supported, and wants to purchase particular goods and/or services from the merchant, the present invention provides the user with access to his/her wallet and facilitates the porting of the data contained within the wallet to quickly and effortlessly fill out the merchant's order form provided on the merchant's checkout webpage.

In yet another embodiment of the present invention, an automatic login function may be added to the internet browser. The steps of adding the auto-entry interface object to the browser interface are the same as described above with respect to various other embodiments of the present invention. Therefore, these steps do not have to be repeated for this embodiment. The auto-login interface object adds various functionality to the browser, such as, but not limited to, access to a list of merchants and the ability to revise, add, and/or remove merchants from the list, as well as the ability to automatically login to a selected merchant website. It should be noted that although "merchant site" is referred to herein in connection with the present embodiment, the present invention is applicable to any website on which a user may establish an online account, which may require the user to enter a login account, password, and/or other user data to access the user's account through the website.

Other objects and features of the present invention will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the invention, for which reference should be made to the appended claims.

Drawings

The drawings are illustrative only, and wherein like reference characters denote like elements throughout the several views:

FIG. 1 depicts a prior art Internet browser interface;

FIG. 2 depicts a view of an Internet browser interface including interface objects within a browser toolbar in accordance with one embodiment of the present invention;

FIG. 3 depicts a view of an Internet browser interface having an interface toolbar that includes interface objects in accordance with one embodiment of the present invention;

FIG. 4 depicts a view of an Internet browser interface having an interface toolbar including a plurality of interface objects, in accordance with one embodiment of the present invention;

FIG. 5 is a flow chart of a method of controlling an Internet browser interface according to one embodiment of the present invention;

6-9 are flow diagrams of a method of controlling and displaying an Internet browser interface in accordance with various embodiments of the present invention;

FIG. 10 is a schematic block diagram of a computer connected to the Internet on which the present invention may be implemented;

FIG. 11 is an exemplary screen shot of an Internet browser interface having a shopping assistant button in accordance with one embodiment of the present invention;

FIG. 12 is an exemplary screen shot of a wallet establishing web page according to one embodiment of the present invention;

FIG. 13 is an exemplary screenshot of a wallet data entry web page according to one embodiment of the present invention;

FIG. 14 is an exemplary screen shot of a wallet summary web page according to one embodiment of the invention;

FIG. 15 is an exemplary screen shot of a security key window in accordance with one embodiment of the present invention;

fig. 16 is an exemplary screen shot of a wallet information window in accordance with one embodiment of the present invention;

FIG. 17 is an exemplary screen shot of a supported merchant checkout web page according to one embodiment of the invention;

18A-18B are flow diagrams of a method for automatically logging a user onto a merchant web site in accordance with one embodiment of the present invention; and

fig. 19 is a schematic diagram of a system for facilitating automatic user login to a merchant web site in accordance with an embodiment of the present invention.

Detailed Description

The present invention relates to a method and system that facilitates automatic login to a website using an internet browser. According to one embodiment of the invention, computer code is transmitted from the server to the user's computer, which adds specific functionality to the user's Internet browser. The present invention thus provides dynamic control of an internet browser interface that enables a user to selectively add buttons and/or toolbars to the browser interface and add features and functionality to the browser. In a preferred embodiment, the computer code enables a user to modify a browser interface that selectively adds interface objects to an Internet browser interface. The interface object may include a button that may be added to the browser interface, as part of an existing toolbar, or as part of a new toolbar added to the browser interface. This button allows the user to access the merchant list and also adds an auto-login feature to the browser. Access to the merchant list allows the user to add merchants, edit merchants, and select merchants for automatic login. Once the button is added to the browser interface, the user can click on the added button, generally referred to herein as an auto-login button, and gain access to a drop-down menu that displays one or more merchants as a merchant list. By selecting one of the merchants on the merchant list, the functionality added to the browser in accordance with the present invention will cause the user to automatically log into the selected merchant and cause the user's browser to navigate to the merchant's website. The process is essentially transparent to the user and is initiated when the user selects a merchant from the merchant list.

The present invention also provides a method and system that facilitates online shopping by modifying a browser interface to provide shopping assistant buttons and functions. The modified browser interface provided in accordance with the present embodiment of the present invention simplifies online shopping by creating a wallet for each shopper or user. The wallet is stored in a database on a secure server, accessible, usable or modifiable only by the user, and associated only with the user-provided security keys. The wallet contains user-provided information that can be ported directly to a supported merchant checkout web page. Thus, when a user is shopping online at a merchant's website supported, and wants to purchase particular goods and/or services from the merchant, the present invention provides the user with access to his/her wallet and facilitates the porting of data contained within the wallet to quickly and effortlessly fill out the merchant's order form provided on the merchant's check-out webpage.

Referring now in detail to the drawings, FIG. 10 is a block diagram of a computer 50, the computer 50 being connected to the Internet 90, on which the present invention may be implemented. Computer 50 includes an internal bus 64 that facilitates communication of information between the various devices of computer 50, as well as communication of the computer with external devices and systems via a communication interface 68. Processor 66 is coupled to bus 64 for processing information within computer 50. Computer 50 also includes a main memory 60, such as a Random Access Memory (RAM) or other equivalent dynamic memory storage device, coupled to bus 64 for receiving and storing instructions transmitted from processor 66. Main memory 60 may also be used to temporarily store variables or other intermediate information during execution of instructions by processor 66. A Read Only Memory (ROM)62 is also connected to bus 64 for storing static data and instructions, which are used by processor 66. As part of computer 50, various input and output devices are provided, including, but not limited to, a display 54 (e.g., a Cathode Ray Tube (CRT), Liquid Crystal Display (LCD), etc.), an input device 56 such as a keyboard, and a cursor control device 58 such as a mouse or a trackball. Data storage device 52, e.g., disk drive and diskette, CD-ROM drive and CD-ROM, or other equivalent devices and data storage media, is connected to bus 64 for communicating with processor 66, main memory 60 and communication interface 68. Preferably, the storage device 52 has stored thereon an operating system 70 and an Internet browser software program 72. As will be discussed in more detail below, library files 74 may also be stored on the data storage device 52. As used herein, the term "computer" is intended to be used in its broadest sense and is not limited to any physical size or configuration, or any architectural configuration. Rather, the term "computer," as used herein, is intended to encompass any device capable of sending and/or receiving digital data, storing and/or retrieving digital data, processing digital data, and connecting to a network in any manner and using any means (e.g., the Internet). The computer may be any style, size and configuration of computer including, but not limited to, a server, workstation, desktop computer, laptop computer, internet appliance, notebook computer, Personal Digital Assistant (PDA), internet enabled cellular telephone or other now known or later developed device. The computer includes some or all of the following components: a central processing unit (CPU or processor) operable in conjunction with software (e.g., an operating system, application programs, etc.), a Hard Disk Unit (HDU), permanent memory (e.g., ROM), temporary memory (e.g., RAM), removable data storage devices (e.g., CD-ROM, floppy disk drives, etc.), input devices (e.g., keyboard, mouse, trackball, etc.), output devices (e.g., monitor or display), and I/O devices (e.g., modem, infrared transmitter/receiver, wireless (cellular) transmitter/receiver, etc.). Those skilled in the art will appreciate that a computer may contain some or all of these components in addition to those not listed.

Computer 50 may be connected to the Internet 90 through a communication interface 68 over transmission media including, but not limited to, coaxial cables, copper wire and fiber optic cables. Communication between the computer 50 and the internet 90 may also be via a wireless or cellular interface. The communication interface 68 facilitates two-way communication between the computer 50 and another electronic device or system, such as a server computer (not shown) provided by the content provider 100, 200.

An internet user (not shown) using computer 50 may gain access to the internet 90, which causes browser 72 to execute, thereby opening a communication link between communication interface 68 of computer 50 and internet site 130 of content provider 100 through Internet Service Provider (ISP) 80. The browser 72 provides the computer display 54 with a browser interface 20 (see, for example, FIG. 1) having the layout (e.g., color, size, number, location) and functionality of the windows 30, which are predetermined within the browser 72 for the browser vendor. The content provider 100 transmits the internet content to the computer 50 for display into the content window 32 of the browser interface 20.

The first internet content provider 100 may provide access to the program 120 to internet users to control the browser 72 and the browser interface 20, in accordance with one embodiment of the present invention. When executed by a user, the control program 120 downloads or creates a library file 74, such as a Dynamic Link Library (DLL), on the data storage device 52 of the Internet user's computer 50. Preferably, the library file 74 contains ActiveX control or plug-in functionality. Thereafter, when an internet user accesses the internet using the browser 72, the browser 72 opens the library file 74 and, preferably, automatically establishes a connection to the content provider's internet site 130. In response to the connection established by the browser 72, the content provider loads the information and/or functionality data into a shell that operates within the browser, created by the library file 74. For example, if the user has an account with the content provider 100, customized information and/or functionality may be loaded into the library file 74. If the user does not have an account number, more general information and/or functionality may be loaded.

According to various embodiments of the present invention, data may be transmitted between computers (e.g., between a server and a user or client computer) as described in more detail herein. The present invention contemplates that such data transfers (or transmissions/receptions, downloads/uploads, etc.) may be accomplished in any manner, using any medium or means now known or later developed.

Basically, the library file 74 opens a shell (or shells) within the browser 72 that contains ActiveX controls or plug-in code that can control the internet browser 72 and the browser interface 20. When loaded with an ActiveX control or plug-in, the library files 74 preferably contain functions, objects, data and other software, generally referred to herein as information, which can be used to control the browser 72 and browser interface 20. The present invention ensures that the library file 74 (and shell) is not closed when the internet user moves from the internet site 130 to the internet site 230. Thus, when an internet user disconnects from an internet site that has an ActiveX control or plug-in loaded and connects to another internet site, the information and/or functionality provided through the ActiveX control or plug-in is not lost.

Referring next to FIG. 1, a prior art Internet browser interface 20 is depicted having a plurality of windows, each providing various functionality to Internet users. Browser interface 20 may include a first parent window 30, which typically defines the general size, color, and layout of the browser interface, and contains window control buttons 28 for that window 30 (e.g., minimize, close, etc.). Browser interface 20 may also include, within first parent window 30, a second parent window 36 (a child window of the first parent window), and one or more child windows 38 that are dependent on the second parent window. Typically, second parent window 36 and child window 38 define information and/or functionality that will assist internet users when accessing and browsing the internet. For example, second parent window 36 and dependent thereon window 38 may provide a toolbar, drop down menu, plug-in, application, and the like.

For example, three windows 38 provided at the top (in the figure) of the interface 20 define three toolbars 22, which may include a plurality of interface controls 24, such as drop-down menus, function buttons (e.g., stop, back, forward, home, etc.), and combinations of function buttons and windows (e.g., search buttons and windows). The uppermost toolbar 22 provides a plurality of drop down menus 24; the middle toolbar 22 provides a plurality of function buttons 24; while the lowermost toolbar 22 provides a drop down menu and window 26(URL address window). A content window 32 is also provided as part of the interface 20 within which content from the internet content provider 100 (see, e.g., fig. 10) may be displayed. The internet user can turn on and off any of the lower three (on the figure) toolbars 22 using a View toolbar object 24 (drop down menu) provided within the second toolbar 22. However, it is not currently possible for an internet user to add, delete or modify the browser interface 20.

Fig. 2-4 depict an internet browser 20 configured in accordance with various embodiments of the present invention. In fig. 2, the browser interface 20 includes an interface object 40 defined for an ActiveX control or plug-in that is loaded into the library file 74 by the content provider 100. The interface object 40 includes a drop-down menu 44 and is displayed within the browser toolbar 22 along with the interface controls (i.e., browser toolbar object) 24 provided by the browser 72. In FIG. 3, the interface object 40 includes an interface object toolbar 42 and a drop down menu 44, which are displayed as a separate window 48 within the browser interface 20. In FIG. 4, the interface object 40 includes an interface toolbar 42 that includes a plurality of drop down menus 44 and a search window 46 that are displayed in a separate box 48 within the browser interface 20. Interface object 40, in accordance with various embodiments of the present invention, may include substantially any type of information and/or functionality available through a browser. Thus, without limitation, interface object 40 may include drop-down menus, toolbars and drop-down menus, textual information (e.g., advertisements, coupons, etc.), textual and/or audio information (e.g., textual advertisements with accompanying sounds), textual, audio, and/or image (animated or non-animated) information, video and audio, and so forth.

The various embodiments of the inventive internet browser interface 20 depicted in fig. 2-4 are merely illustrative, non-limiting examples of the present invention. Variations to the browser interface 20 described may be made in accordance with the teachings provided herein.

Referring next to fig. 5, there is depicted a method of controlling an internet browser interface 20, generally designated 500, in accordance with an embodiment of the present invention. At step 510, an Internet user accesses control program 120 through Internet site 130, ISP80 or the user's computer 50. When executed by an internet user, the control program 120 provides the user with the ability to thereafter control the user's internet browser interface 20, as discussed in more detail below. At step 520, the control program 120 downloads or creates a library file 74 containing ActiveX control or plug-in code defining interface objects on the Internet user's computer 50. Each time an Internet user launches or activates the browser 72, the library file 74 is opened, and a connection to a predetermined Internet website 110 is automatically established, the Internet website 110 is preferably configured to communicate with the Internet user's computer 50, the ActiveX control or plug-in code of the interface object, as indicated at steps 530 and 540. Basically, is the open library file 74 in browser 72? ) An outer shell is provided within which functionality provided by ActiveX controls or plug-ins can be added to the browser interface 20. Neither the library file 74 nor the shell will close until the browser 72 is closed. At step 550, an interface object 40 is created that will be displayed within the browser interface 20; the information and/or functionality of the interface object 40 is defined by an ActiveX control or plug-in. According to various embodiments of the present invention, browser 72 maintains display interface object 40 within browser interface 20 as long as the user continues to surf the web or browser 72 is activated, as indicated by step 560. Thus, the functionality added to browser 72 and browser interface 20 in accordance with the present invention is not lost while the Internet user is surfing the Internet.

The present invention provides various embodiments for controlling the browser 72 and the browser interface 20, described generally above with reference to FIG. 5, each of which will now be described in detail.

With continuing reference to FIG. 6 and with continuing reference to FIG. 10, a description will now be provided of one embodiment of a method for controlling and displaying the browser 72 and browser interface 20, generally designated 600, in accordance with the present invention. For purposes of FIG. 6, and for purposes of the discussion to be referred to below, a library file 74 has been downloaded or created on the Internet user's computer 50, as discussed herein. At step 610, the Internet user launches or activates the browser 72 to initiate access to the Internet 90. At step 620, the library file 74 is opened and a connection to a predetermined content provider is automatically established, as indicated at step 630. The content provider transmits the functionality defined by the ActiveX control or plug-in code of the BIO library to the user's computer 50 to create an interface object 40 that can be added to the browser interface 20. The interface object 40 is displayed on the internet browser interface 20 as indicated by step 640. When an internet user roams the internet 90, the functionality of the interface object 40, as defined by the ActiveX control or plug-in code, remains within the browser interface 20 regardless of the number or type of internet sites accessed by the user and persists throughout the user's access to the internet 90 using the browser software program 72. When an internet user moves from one internet site to another, as indicated by step 650, the present invention determines whether the interface object 40 is still alive after the movement; whether browser 72 still displays it on browser interface 20, as indicated by step 652. If the interface object 40 is no longer displayed within the browser interface 20 (in other words, it has been deleted from the browser interface 20, or terminated), the interface object 40 is redrawn, as indicated by step 660. If the user moves from one internet site to another while the interface object 40 remains alive and continues to be displayed within the browser interface 20, the present invention also determines whether the browser 72 is active at step 654; this is because the interface object 40 is displayed within the browser interface 20 only when the browser 72 is operating. If the browser 72 is inactive, the interface object 40 is terminated and the library file 74 is closed, as indicated by step 670. If the browser 72 remains active, the present invention continues to ensure that the interface object 40 is displayed within the browser interface 20 at step 652. The present invention monitors the status of the interface object 40 as the internet user moves between or among internet sites and ensures that the browser 72 displays it on the browser interface 20 during the user's roaming of the internet 90.

According to the embodiment depicted in FIG. 6, the present invention ensures that when an Internet user leaves the Internet site 130, the browser 72 displays the interface object 40 on the browser interface 20, whereupon the BIO library is initially invoked and loaded onto the user's computer 50. For example, when the user launches or activates the browser 72, a connection is automatically created to a first, predetermined Internet site 130, which is maintained by the first content provider 100, and the BIO library is loaded onto the user's computer 50. The browser 72 may then access the functionality provided by the BIO library through the shell created by the library file 74. The functionality of the interface object 40 will continue to be presented within the browser interface 20 when the internet user connects to a second internet site 230 maintained by a second content provider 200. In this embodiment, the present invention prevents the browser 72 or operating system 70 of the computer 50 from disabling the functionality of the BIO library by uninstalling the library file 74 when the connection to the first Internet site 130 is terminated.

For example, when the browser 72 initially connects to an internet site 130, the site 130 transmits the functional information in the form of ActiveX control software code as a BIO library to the internet user's computer 50, which is loaded into the library file 74. When the connection to the first internet site 130 is terminated, if the operating system 70 or browser 72 does not explicitly instruct the library file 74 to close or uninstall, the library file 74 will remain loaded even after the connection to the first internet site 130 is closed, providing the desired functionality to the interface object 40 within the browser interface 20. Keeping the library files 74 loaded as the internet user moves between internet sites enables loading of data, functions and objects within the library files 74 from outside the loaded ActiveX control (which is transmitted to the internet user 50 only by the first internet site 130). Any data or objects created within the library file 74, outside of the ActiveX control, will remain loaded and continue to work within the browser interface 20 as long as the library file 74 remains loaded.

To keep the library file 74 open during surfing, a global object, object A, is created in the program heap of the Internet user's computer 50, rather than in the heap of calling functions, after the browser 72 connects to the Internet site 130 and before the connection is terminated. Thus, the global object remains alive when the calling function is completed. The global object may be created with the C + + new operator or by declaring a global object in a global declaration. In either case, the global object will remain alive when the connection between the browser 72 and the first internet site 130 is terminated.

The global variable thus defined remains active after the ActiveX control provided by the first internet site 130 has closed, i.e., after the initial connection to the first internet site 130 has been terminated. Once the global object is created, an interface is created using the global object. The interface will serve, for example, to delete, replace, and/or add functionality to browser 72 and browser interface 20. The interface may be created as part of the global object or a new interface object 40 may be assigned by the global object. For example, an interface object 40 may be created by, for example, creating an interface object window 48 within the browser window 38 (see, e.g., fig. 3 and 4) and adding it as a child window to the browser interface 20. As another alternative, the browser interface 20 may be modified directly by, for example, adding or modifying a browser toolbar 22 or a browser toolbar object 24 within the browser interface 20. Yet another alternative is to create an interface toolbar 42 that is separate from the browser interface 20, as depicted in fig. 4.

In addition, a pointer is required for controlling the browser 72 and instructing the browser 72 to establish a connection to a predetermined internet site 130. Preferably, the pointer is stored globally so that it is accessible to any function or object within the library file 74 that sends a command to the browser 72. In Microsoft Internet Explorer, for example, the pointer may be created using IWebBrower, IWebBrower2, or IWebBrowerApp Object Link and Embed (OLE) interface commands. The pointer may be created using a Microsoft base class library (MFC), for example, using a GetClientSite member of the COleControl class, to obtain the pointer from the first Internet site 130, i.e., the Internet site hosting the BIO library. GetClientSite is used as the entry point for the browser 72 to communicate with the BIO library. The GetContainer member of the IOleClientSite class returned from the previous step may be used to fetch the pointer of the container (container) of the BIO library. The container of the BIO library is the container within which the ActiveX controls are loaded. Generally, the Internet browser interface 20 includes a number of sections, including a browser toolbar 22 and a content window 32. Browser 72 creates a document object for each web page visited by an internet user, which contains all the data that appears on a particular web page. The document object is also a container of the BIO library. Thus, a document object may also be referred to as a container of the BIO library.

The querymenterface member of the ioecontainer class returned from the previous step may be used to retrieve a pointer to the IServiceProvider interface, which may be used to locate any other interface rendered by browser 72. Finally, the QueryService member of the IServiceProvider class returned from the previous step may be used to get a pointer to the IWebBrowerApp, IWebBrower, or IWebBrower2 interface, depending on the particular interface provided by the browser 72 calling the BIO library.

In an alternative embodiment, the present invention may be used to modify the entire browser window 30. If the entire browser window 30 is modified as opposed to integrating the interface object 40 into an existing browser window 38, the entire class of the modified browser window 30 may be subclassed, or, alternatively, the particular browser window 38 may be subclassed. As used herein, the term sub-typing a window, also referred to as hooking a window, refers to replacing the original browser window message handling process with a user-defined window message handling process to handle all messages sent to the window. For example, the window may be subclassed using the CWnd:. SubclassWindow () function of Microsoft basic class library (MFC). As another alternative, the window may be sub-classified by calling the SetWindowLong function (a Microsoft Windows function) and passing the GWWNDPROC parameter (a Microsoft Windows constant). The pointer returned by the SetWindowLong function call may be saved to the original browser window message handling process for the subsateded window. This enables the BIO library to intercept all messages passed to windows 30 or 38, and the BIO library can interpret commands from interface controls 24, including buttons, menus, etc. provided for browser 72, or from interface objects 40, added for the BIO library in accordance with the present invention.

User-defined window message handling procedures, which are provided for the BIO library and which replace the original browser window message handling procedures, referred to herein as BIO procedures. Messages (e.g., commands) intended for browser 72 may be intercepted and modified using the BIO process with browser 72, or the BIO process may transmit an alternative or new message (e.g., a message handler of interface object 40) to browser 72.

The present invention also ensures that interface objects 40 are not deleted from the browser interface 20. For example, some internet browsers 72 redraw the entire browser interface 20 when an internet user accesses a new web site. After such an internet movement by the user, the interface object 40 will be deleted from the browser interface 20 and will therefore not be displayed on the browser interface 20, although the global variables may still be working. To prevent this from happening, the BIO process may intercept messages from the browser 72 redrawing the browser interface 20 and redraw the interface object 40 immediately after redrawing the browser interface 20. As another alternative, interface object 40 may be periodically tested for presence within browser interface 20, and if not present within browser interface 20, interface object 40 may be redrawn. Preferably, such periodic testing occurs at intervals of less than about one second.

As an example of the embodiment described above (described in FIG. 6), the ActiveX control is loaded as a BIO library and adds menu items (and functions) to the browser interface 20. The present invention creates an ActiveX control that dynamically creates a new global object, object a, that creates a new menu object (which may be an interface object 40) with the required functionality to be added to the browser interface 20. Instructions may be used (for example): AfxGetMainWnd () - > GetMenu () - > appendix (), to add the menu object 40 to the browser interface 20, where the added menu of the browser interface 20 will include a pop-up menu, pointing to the menu object 40. The browser interface window will then be subsumed and process the messages of the menu object 40 processed by the BIO process, as well as the messages passed to the browser interface 20 of the message handler of the browser 72. When the internet user disconnects from the first internet site 130 (e.g., leaves the web page containing the ActiveX control), the ActiveX control will close, but the global object will remain in the program heap and continue to provide the desired functionality to the browser interface 20.

Instead of a subclass browser window to which the interface object 40 is added, object A, or one of its descendants, may retain ownership of the interface object 40. In this way, a message handler for the interface object 40 may be created. For example, in addition to using the SetOwner function of the Microsoft base class library to set ownership of the interface object 40 to object A or one of its descendants, the interface object 40 may be added to the browser toolbar 22 in accordance with the embodiments of the present invention described above.

With continuing reference to fig. 7 and with continuing reference to fig. 10, a description will now be provided of an alternative embodiment of a method of controlling and displaying a browser interface 20, generally designated 700, in accordance with the present invention. For purposes of FIG. 7, and for purposes of the discussion to follow, a library file 74 has been created on the Internet user's computer 50, as discussed herein. At step 710, the Internet user launches or activates the browser 72 to access the Internet 90. At step 720, the library file 74 is opened on the user's computer 50 and a connection to the predetermined Internet site 130 is automatically established, as indicated at step 730. At step 740, the content provider transmits the functionality defined by the ActiveX control or plug-in code of the BIO library to the user's computer 50 (i.e., to the library file 74) to create the interface object 40, which may be displayed on the browser interface 20 using a continuous loop to control the display of the interface object 40. The interface object 40 may be deleted (i.e., its function terminated) only when the persistent loop is terminated. As the Internet user roams the Internet 90, the functionality of the interface object 40, as defined by the ActiveX control or plug-in code, remains within the browser interface 20 regardless of the number or type of Internet sites accessed by the user, and persists as long as the browser 72 remains activated and the Internet user accesses the Internet using the browser software program. When an internet user moves from one website to another, as indicated by step 750, the present invention determines whether the interface object 40 is still alive after the movement, in other words, whether the browser interface 20 is still displaying it, as indicated by step 752. If the browser 72 no longer displays the interface object 40 within the browser interface 20, the interface object 40 is redrawn, as indicated by step 760. If the interface object 40 remains alive and continues to be displayed in the browser interface 20 after the user moves from one web site to another, the present invention also determines whether the browser 72 is active at step 754; this is because the browser 72 displays the interface object 40 within the browser interface 20 only when the browser 72 is operating. If the browser 72 is inactive, the interface object 40 is terminated and the library file 74 is closed, as indicated by step 770. If the browser 72 remains active, the present invention determines whether the persistence loop has been terminated at step 756. If the loop has been terminated, the interface object 40 is also terminated, as indicated by step 770. If a loop is still being executed, the present invention determines if the interface object 40 is still displayed within the browser interface 20, as indicated by step 752.

The embodiment of the invention described in figure 7 prevents the active x control from unloading, which freezes the operation of the library file 74 (into which the active x control code is loaded), even when the operating system 70 or browser 72 generates an instruction to unload or terminate the library file 74. Since the library file 74 is frozen and the uninstall is never finished, all data, functions and objects created by the ActiveX control within the library file 74 will survive and work after the library file 74 is instructed to uninstall.

In some operating systems 70 and/or browsers 72, the BIO library will be closed when the ActiveX control is no longer present at the Internet site. This may also occur when an internet user moves from an internet site with an ActiveX control, such as internet site 130 in fig. 10, to another internet site without an ActiveX control, such as internet site 230 in fig. 10. In order for the interface object 40 to continue operating without the presence of an ActiveX control, the BIO library (and library file 74) must be prevented from closing.

To accomplish this, a pointer is created that is used to control the browser 72. Preferably, the pointer is stored globally so that it is accessible to any function or object within the library file 74 that may need to send a command to the browser 72. In Microsoft Internet Explorer, for example, the pointer may be created using the IWebBrower, IWebBrower2, or IWebBrowerAppelE interface commands. To do this using the Microsoft base class library, GetClientSite members of the COleControl class (for communicating with the BIO library) may be used to obtain a pointer to the Internet site of the BIO library (i.e., the Internet site that provides the ActiveX control). The GetContainer member of the IOleClientSite class returned from the previous step can be used to get a pointer to the container of the BIO library. The pointer to the IServiceProvider interface may be taken using the QueryInterface member of the ioecontainer class returned from the previous step. The IServiceProvider interface is used to easily find any other interface presented by the browser 72. The QueryService member of the IServiceProvider class returned in the previous step may be used to retrieve a pointer to the IWebBrower app, IWebBrower or IWebBrower2 interface depending on the interface presented by the version of browser 72 calling the BIO library.

To prevent the library file 74 from closing, its operation is stopped before it can be terminated. To freeze or halt the operation of the library file 74, a continuous program loop may be created and executed that terminates only when the BIO library is to be unloaded, at which time the program loop also pumps the message queue. The message loop is referred to herein as a message pump, which may be created in the loop using, for example, PeerMessage, GetMessage, TranslateMessage, and DispatcMessage commands. The following provides exemplary C + + code to implement a message pump:

  　while(m_Continue)　　{　　   if(PeekMessage(&msg，NULL，0，0，PM_NOREMOVE)！＝0)　　   {　　       GetMessage(&msg，NULL，0，0)；　　       TranslateMessage(&msg)；　　       DispatchMessage(&msg)；　　   }　　}

where m _ Continue is a Boolean variable used to indicate when a loop is stopped, and PeekMessage, GetMessage, TranslateMessage, and DispatcMessage are all Windows functions. If m _ Continue equals false, the loop will end, thus ending the message pump. The MSG parameter is a reference to the Windows MSG structure.

The message pump preferably operates in such a way that it checks whether any messages are waiting in the message queue using the PeekMessage function. If there is a message, the message pump uses the GetMessage function to grab the message from the message queue and uses the TranslateMessage function to translate the message from the dummy message to a character message. Finally, the message pump sends the message to the original window message handler that should receive the message using the DispatcMessage function.

The built-in capabilities of the operating system 70 may also be used to build a message pump to pump a message queue. For example, using a command such as the MFC command CWnd:: MessageBox ("my module", MB _ OK), a modal dialog or message box serves this purpose well and can be used to provide the required freezing or stopping of operations on the library file 74.

The ActiveX control will not terminate as long as the message pump executes a continuous loop, even when the internet user accesses other internet sites.

The embodiment of the invention described in fig. 7 performs in the same manner (e.g., sub-typing, message processing, etc.) as the embodiment of fig. 6 described above.

For both of the above-described embodiments (of fig. 6 and 7), it is preferable, although not necessary, to provide the exit function for the interface object 40 so that object a and all of its descendants will be closed. Possible exemplary scenarios for invoking the exit function include intercepting a message to close the browser window during the BIO, or periodically looking for the browser window and, if it is not found, terminating the ActiveX control.

Referring next to fig. 8, yet another embodiment of the method of the present invention is depicted, generally designated 800. For purposes of FIG. 8, and for purposes of the discussion to be referred to below, a library file 74 has been created on the Internet user's computer 50, as discussed herein. At step 810, an Internet user launches or activates the browser 72 to access the Internet 90. At step 820, the library file 74 is opened on the user's computer 50 and a connection to a predetermined Internet site 130 (see, e.g., FIG. 10) is automatically established, as indicated at step 830. At step 832, a new browser interface is created that is a copy of the initial browser interface provided by browser 72. At step 840, a Function Window (Function Window) is created, which represents the original browser interface in which the plug-in's functionality was initially loaded.

Fig. 8A depicts the steps, generally designated 840, of creating a function window in accordance with the present embodiment of the invention. At step 842, a handle to the initial browser interface window is determined. The initial browser interface window, now the function window, is hidden and/or invalidated at step 844 so that it cannot be closed, which would otherwise result in a BIO library crash. At step 846, a pointer is created that is used to control the browser 72. Finally, at step 848, a new browser interface window is created that the internet user can use to continue roaming the internet.

Referring again to FIG. 8, and beginning with step 850, the browser interface can now be controlled, which first subcategorizes any browser windows, or any windows used by the browser, which will be controlled, and thereafter adds, deletes and/or modifies windows, as described in more detail below. The initial browser window message handling process is replaced by a BIO process. In step 860, the present invention determines whether any new browser windows have been opened, i.e., windows that may not have been subclassed in accordance with the present invention or may not have been controlled. If new windows have been opened, the present invention determines whether interface objects 40 are to be added to these new windows in step 870. If not, the present invention determines if the Internet user would like to close browser 72, as indicated by step 880. If so, the present invention closes all browser windows, including the function window, at step 890. If the user does not want to close browser 72, as determined in step 880, the present invention returns to step 860 and again determines whether a new browser window has been opened.

With continued reference to fig. 8, 8A and 10, the above-described embodiments of the present invention will now be discussed in more detail. When the content provider 100 loads an ActiveX control via the internet site 130, the code for the ActiveX control is loaded therein, typically in response to the browser 72 establishing a connection to the web site 130 and invoking the ActiveX control, causing the library file 74 located on the user's computer to open and create a shell within the browser 72. If the operating system 70 or browser 72 explicitly instructs the library file 74 containing the ActiveX control to uninstall or close when the ActiveX control is closed (when the user terminates the connection to the internet site 130), any data, functions or objects created outside of the ActiveX control, inside the library file 74 will be destroyed when the library file 74 is uninstalled. To prevent the library file 74 from unloading, the browser 72 is prevented from closing the ActiveX control until instructed to do so. If the ActiveX control is never instructed to close, the library file 74 is never unloaded.

One preferred method of accomplishing this is to hide and/or invalidate the original browser interface window that loaded the ActiveX control and create a new copy of that window, within which the internet user can continue working and roaming the internet. Since the initial browser interface is preferably hidden and/or disabled, the ActiveX control cannot be closed until the library file 74 is displayed, enabled, or the initial browser interface window, i.e., the window in which the library file 74 is loaded, is closed.

The above-described method of fig. 8 preferably loads the BIO library within the browser 72 as a standard ActiveX control using, for example, < object > tags, typically contained within the web page 130, or as Band objects, as described by the Microsoft Internet explorer4.x software development kit. This instructs the browser 72 to initialize and run a library file 74 containing the code for the BIO library.

The first time the BIO library is initialized and called, a function window is created that keeps the BIO library open by keeping the session itself open with the ActiveX control when the internet user accesses other internet web sites 210, i.e., other web pages. The function window also makes it possible for a browser window that does not have a copy of the open BIO library to access the OLE interface of browser 72.

To create the function window, the initial browser interface window (i.e., the window that loads the BIO library) is preferably hidden and/or invalidated. This may be accomplished by determining the handle of the initial browser interface window, which begins with the handle of the BIO library. To obtain the initial browser interface window handle from the handle of the BIO library, the GetParent function (Windows function) is continuously called until the current value of the function call represents the next level of the desktop window. For example, executing a statement such as "m _ Handle ═ gethandle" in a loop, where the value of m _ Handle is initially equal to the value of the Handle to the BIO library, and will eventually return a Handle to the original browser interface window, may provide the desired functionality and results.

The next step is to hide and/or invalidate the initial browser interface window (now referred to as the function window) so that the internet user cannot close the function window (e.g., by closing the browser 72), thereby causing the BIO library to uninstall and remove the functionality provided by the BIO library from the browser interface 20. To hide the initial browser interface window from the user and/or to disable the browser window from user-driven events, a WM _ SHOWFOW and/or WM _ ENABLE message (both Windows constants) may be sent to the initial browser interface window, taking values to hide and/or disable the browser window. For example, a PostMessage or SendMessage function (existing Windows function) may be used to send a message to the initial browser interface window, which uses the browser window handle. As another alternative, the ShowWindow and EnabloWindow functions (existing Windows functions) may be used to achieve the same result.

A pointer is created to control the browser 72. Preferably, the pointer is stored globally so that it is accessible to any function or object within the library file 74 that sends a command to the browser 72. In Microsoft Internet Explorer, for example, the pointer may be created using the IWebBrower, IWebBrower2, or IWebBrowerApp OLE interface. To do this using the Microsoft base class library, a GetClientSite member of the COleControl class may be used, which serves as the entry point to the browser 72 to communicate with the BIO library and obtain a pointer to the Internet site of the BIO library, i.e., the Internet site hosting the ActiveX control. The GetContainer member of the IOleClientSite class returned from the previous step can be used to fetch the pointers to the BIO libraries. The pointer of the IServiceProvider interface can be obtained by using the QueryInterface member of the IOLeContainer class returned in the previous step; preferably, the IServiceProvider interface is used to find any other interface presented by the browser 72. The QueryService member of the IServiceProvider class returned in the previous step may be used to fetch a pointer to the IWebBrower app, IWebBrower or IWebBrower2 interface depending on the interface presented by the browser 72 version calling the BIO library.

Finally, because the browser window that was previously used to create the function window has been hidden and/or deactivated, a new browser window is created that the Internet user can use to continue surfing the web and continue to access a variety of different Internet sites. Preferably, any of the IWebBrower, IWebBrower2 or IWebBrower app OLE interfaces is used to create a new browser window, say, the navigator or navigator 2 member using the OLE interface. As another alternative, a WM _ COMMAND message may be sent to browser 72 in response to any such COMMAND that browser 72 may use to open a new browser window, such as a new window COMMAND or an open COMMAND in a new window, and so forth. Dynamic Data Exchange (DDE) support provided by browser 72 may also be used to open a new window.

The BIO library now has to control various browser interface features and functions. The first step is to subclass any browser window, or any window used by a browser (i.e., a child window), which is to be controlled in accordance with the present invention. A BIO window message handling procedure, hereinafter referred to as BIO procedure, is used instead of the original window message handling procedure.

Once a browser window, or any of its child windows, has been sub-typed, it is possible to add a menu to the sub-class, which uses the GetMenu function to obtain a pointer to the browser window menu. Once the pointer to the handle of the menu is obtained, menu functions, such as ModifyMenu, AppendMenu, InsertMenu, and the like, may be used to add any desired menu to the browser window. The BIO process used to subclass the BIO window must process any commands that are assigned to the menu. The menu must not be created using the same command identifier as contained in the browser.

An interface object toolbar 42 may be added to the browser interface 20 that obtains a handle to the window (hereinafter referred to as a frame handle) to which the interface object toolbar 42 will be added using standard Windows functions. Typically, the window will be a BIO window, or frame window, which is a sub-window of the BIO window. Thereafter, a window is created with the frame handle as the parent window. For example, to add a dialog box (which is a form of a toolbar) as interface object 40, Create an object of or derived from the cdialogab type (a Microsoft base class), and call its Create method using the frame handle. If a resource, such as an image, toolbar, dialog box, etc., is used and the browser 72 does not share the same resource with the BIO library, the browser's resource is temporarily replaced with the BIO library resource before any data can be loaded from the BIO library resource. The BIO library resource may then be replaced with the original resource of the browser.

When new browser windows are opened, it may be desirable to add interface objects 40 to these new windows. A timer may be created that uses the SetTimer Windows function that will call a user-defined function that will check each child window of the desktop window using the FindWindowEx function (Windows function) to find Windows with the same class name as the function window. For a browser window that has not been modified, i.e., has no interface object 40, the necessary handle may be obtained and the same changes made as the original BIO window.

Finally, when an internet user wants to close browser 72, it must be determined whether all browser windows are closed except for the function window, and if all other browser windows are closed, the function window must also be closed. This can be done by listening for WM _ CLOSE messages (Windows constants) during BIO message processing, or by setting a timer to periodically decide how many browser Windows are open. To CLOSE the primitive window, a WM _ CLOSE message may be sent to the window.

Referring next to fig. 9, there is depicted another alternative embodiment of a method, generally designated 900, for controlling and displaying an internet browser interface 20 in accordance with the present invention.

Steps 910, 920 and 930 are substantially the same as the embodiment of fig. 6-8 described above. At step 940, a new browser interface window is created, and the initial browser interface window is hidden and/or invalidated, referred to as a function window. The plug-in determines the handle of the initial browser interface window, hides and/or invalidates the window, and creates a new browser interface window that is available to the internet user. At step 950, all browser windows are sub-typed, after which the browser interface can be controlled, as indicated at step 960, for all open windows. In step 962, the invention determines whether any new browser windows have been opened, in which case the invention returns to step 960. If a new browser interface window is not open, step 962 proceeds to step 964 to determine if the Internet user wants to close the browser. Before closing the function windows, all windows must be closed, as determined in step 966. If all windows are closed, then the function window is closed, as indicated in step 970. Otherwise, step 966 returns to step 964.

In yet another alternative embodiment of the present invention, the present invention provides a method for controlling an Internet browser interface that uses a browser plug-in to control the functions of the invoked browser 72 and to retain the functions of the plug-in after the user leaves the Internet site 130 where the plug-in is loaded.

When a browser plug-in is loaded into an internet user's computer 50 in response to the browser 72 establishing a connection to an internet site 130 and invoking the plug-in, the library file 74 creates a shell within the browser 72 into which the plug-in's code can be loaded. If the operating system 70 or browser 72 explicitly instructs the library file 74 to uninstall when the plug-in is closed, any data, functions or objects created outside the plug-in, within the library file 74 will be destroyed when the library file 74 is uninstalled. To prevent the library file 74 from being uninstalled, the browser 72 is prevented from closing the plug-in until the browser 72 receives an instruction to close the plug-in. If plug-in shutdown is never instructed, the library file 74 is never instructed to be unloaded. This can be accomplished by hiding and/or invalidating the original browser window that loaded the plug-in, and by creating a new copy of that window, the internet user can continue to use it to access and roam the internet. Since the initial browser window is preferably hidden and/or invalidated, the plug-in cannot be closed until the library file 74 is selected for display, validated, or the initial browser window onto which the plug-in is loaded is closed.

For example, a browser plug-in is loaded within the browser 72 as a standard plug-in, preferably using an < Embed > tag on the web page 110 (see, e.g., FIG. 10) that instructs the browser 72 to initialize and load the library file 74 containing the plug-in code (i.e., the BIO library).

The first time the BIO library is initialized and called, a function window is created that hides and/or invalidates the original browser window, thereby preventing the BIO library from uninstalling, which keeps the session itself open with the plug-in. The function window also makes it possible for a browser window that does not have a copy of the open BIO library to access a built-in Application Programming Interface (API) for the plug-in (i.e., functionality made available to Internet users via the browser interface 20 via the plug-in functionality), such as that provided by Netscape Navigator and Microsoft Internet Explorer.

Preferably, a function window is created that hides and/or invalidates the initial browser window (within which the plug-in resides) when the browser 72 first calls the plug-in. To accomplish this, the plug-in must first determine the handle of the initial browser window. The window member of the NPWindow structure, which is a handle to the plug-in window (NPWindow and NPP _ SetWindow are part of the APIs for plug-ins, Netscape and Internet Explorer) is passed from the browser 72 to the BIO library as the second parameter of the NPP _ SetWindow function. To obtain the initial browser window handle from the window member, the getpoint function (Windows function) is continuously called until the current value of the function call represents the next level of the desktop window. For example, executing a statement such as "m _ Handle ═ gethandle" in a loop, where the value of m _ Handle is initially equal to the value of the Handle of the NPWindow structure, and will eventually return a Handle to the original browser window, may provide the desired functionality and result.

Thereafter, the original browser window is hidden and/or invalidated so that the internet user cannot close the function window, resulting in a BIO library crash. To hide the initial browser window from the user and/or to invalidate the window from user-driven events, a WM _ SHOWFOW and/or WM _ ENABLE message (both Windows constants) may be sent to the initial browser window, valued as hidden and/or to invalidate the browser window. This may be accomplished, for example, by using a PostMessage or SendMessage function (Windows function) to send a message to the initial browser window, which uses the browser window handle. As another alternative, the ShowWindow and EnableWindow functions (Windows functions) may be used to achieve the same result.

The final step is to create a new browser window that the internet user can use to continue surfing the web after the initial browser window has been hidden and/or deactivated. Any of the following Netscape and Internet Explorer plug-in API functions may be called, for example: this is achieved with NPN _ GetURL, NPN _ PostURL, NPN _ GetURLNotify, NPN _ PostURLNotify, where the target parameter is set to _ new, _ blank, or any window name not already present. The NPP parameters of the above functions are NPP structures, which the browser 72 provides to the plug-in of the function window. Another way to do this is to send a WM _ COMMAND message to browser 72 in response to any COMMAND that browser 72 can use to open a new browser window, e.g., a new window COMMAND or an open COMMAND in a new window. Dynamic Data Exchange (DDE) support provided by the browser may also be used to open a new window. The NPN _ GetURL, NPN _ PostURL, NPN _ GetURLNotify, NPN _ PostURLNotify, and NPP structures are part of the APIs for plug-ins of Netscape and Internet Explorer, WM _ COMMAND is a Windows constant.

The BIO library may now control the features and functions of the browser 72. The first step is to subclass any browser window, or any window used by a browser (collectively referred to as a BIO window), which is to be controlled in accordance with the present invention.

Once the browser window, or any of its child Windows, has been sub-typed, it is possible to add a menu to the browser interface 20 that uses the GetMenu function (Windows function) to obtain a pointer to the browser window menu. Once the pointer to the handle of the menu is obtained, menu functions, such as ModifyMenu, appendix menu, InsertMenu, etc. (Windows functions), can be used to add any desired menu to the browser window. The BIO process used to subclass the BIO window must process any command assigned to the menu, not create the menu using the same command identifier as contained in browser 72.

Alternatively, or in addition, an interface object toolbar 42 may be added to the browser interface 20 that obtains a handle to a window (hereinafter referred to as a frame handle) to which the toolbar 42 will be added using standard Windows functions; typically, the window will be a BIO window, or frame window, which is a sub-window of the BIO window. Thereafter, a window is created with the frame handle as the parent window. For example, to add a dialog box (which is a form of a toolbar) as interface object 40, an object of or derived from the CDialogBar type (a Microsoft base class) may be created, and the frame handle used when its Create method is invoked. If a resource, such as an image, toolbar, dialog box, etc., is used and the browser 72 does not share the same resource with the BIO library, the browser's resource is temporarily replaced with the BIO library resource before any data can be loaded from the BIO library resource. The BIO library resource may then be replaced with the original resource of the browser.

When new browser windows are opened, interface objects 40 may be added to these new windows. This may be accomplished by creating a timer that uses the SetTimer (Windows function) that will call a user-defined function that will check each child window of the desktop window using the FindWindowEx function (Windows function) to find Windows with the same class name as the function window. For new windows that do not already have an interface modified, i.e., do not contain an interface object 40, the necessary handles may be obtained and the same changes made to these windows as the original BIO window.

Finally, when an Internet user wishes to close browser 72, it must be determined whether all browser windows are closed, except for function windows, and if they are, the function windows may be closed. This can be done, for example, by listening for WM _ CLOSE messages (Windows constant) during the BIO window message processing, or by setting a timer to periodically check the number of open browser Windows. The primitive window may be closed by sending a WM _ CLOSE message to it.

In accordance with the present invention, a BIO library (i.e., a plug-in) may be loaded whose functionality is automatically provided within the browser interface 20, i.e., without requiring the user to actively access a particular Internet site, i.e., to browse the web page calling the plug-in. For example, Netscape has a key in its Windows registry identified as auto start (auto start). Upon activation, Netscape loads all OLE controls listed in the auto-launch key. By placing a reference or call to the library file 74 (and thus to the BIO library and plug-in, which define the interface object 40) within the auto-launch key, the library file can be loaded each time the user launches or activates the Netscape browser. Instructions for creating an instance of the interface object 40 within the browser interface 20, and instructions for the browser 72 to establish a connection to a predetermined internet site 130, may be contained within the library file 74. Using this technique, the user does not have to choose to access a particular Internet site 130 to load the BIO library. It is desirable to keep the library file 74 open at least until a plug-in can be loaded within the browser 72 for display and access through the browser interface 20. One way to do this is to increase the reference count associated with the library file 74 so that when Netscape unloads the OLE control listed in the auto-launch key, the library file 74 will not be unloaded because it has a higher number of references.

The library file 74 may be loaded as a plug-in, using the DDE to periodically look up the netscape DDE server, using a timer or a loop. When browser 72 receives a return from the Netscape DDE server, Netscape is ready to receive the command and can load the plug-in. The DDE may then be used to send a command to the browser 72, such as WWW _ OPENURL, which will cause the plug-in to load, as discussed herein.

Another method for hiding the Netscape plug-in window for the BIO library is to remove it from the taskbar (i.e., where the Windows "Start" button is located) and place it out of view. One way to remove it from the taskbar is to call SetWindowLong and change the window style of the plug-in window to a toolbox window. The toolbox window is not displayed within the sidebar. The Netscape plug-in window can be placed off-screen by calling MoveWindow and providing coordinates that are not within the viewable range of the user's desktop.

The BIO window message handler used to replace the original browser message handler must know which window a message is intended for and how the BIO window message handler will act upon receiving the message. One preferred way to do this is to create a mapping table that links one piece of information to another. For the present invention, a mapping table is preferably used that links the window handle to a structure containing important information for the window. For example, when the BIO library adds an interface object 40 to a new browser window, a new entry is created within the mapping table that links the handle of the BIO window to a structure containing information useful for the BIO window. Preferably, one of the information contained in the structure is an original window message handling procedure of the browser for the BIO window. It is necessary to maintain the browser's original window message handling process so that if the BIO window message handling process does not know how to handle a message, it can pass the message to the browser's original window message handling process.

When a message is received by the BIO Window message handling process, the first parameter passed to the process is the handle of the window that receives the message. To obtain a structure containing all the window-specific data, a lookup is performed in the mapping table using the window handle as a key. The returned structure will contain all saved window specific information, such as the original window message handling process.

The present invention changes the way browser 72 operates when controlling browser interface 20. Almost all things an internet user can do with a browser work by sending a message to a window or sub-window of the browser. The objects or windows that send messages include menus, buttons, combo boxes, and almost anything else that an internet user can directly interact with, such as interface controls. For example, a message may be divided into four components: 1) preparing a handle to a window that receives the message; 2) the msg value of the message; 3) wParam, the use of which generally depends on the msg value; and 4) lParam, the value of which is also typically dependent on the msg value.

For example, clicking a button within a browser window may send a message to the browser window's window message handler containing WM _ COMMAND, which is a Windows constant, msg value. The two low bytes of the wParam variable within the message will be a number that identifies which button was pressed.

By subclassing the windows or sub-windows of the browser, as described above, any messages that the user interactively sends with any interface control can be intercepted. Once a message is intercepted, the BIO window message handling process may interpret and react to it. If the functionality of the interface control remains unchanged (i.e., the invention does not add, delete, or modify), the message may be passed back to the original window message handling process. In this way, substantially all interface controls present within the browser 72 may be controlled. In addition, interface controls may be added to the browser interface 20 and assigned a command identifier (which is passed within wParam). Thereafter, the BIO window message handling process may interpret wParam and provide the functionality of the interface control to be loaded. In addition, functionality can be removed that simply leaves the inventive window message handling process nothing when a command identifier associated with an interface control to be removed from the browser is received. In this way, the command is prevented from passing to the original message handling process of the browser window.

Using various embodiments of the present invention, an Internet user may create a browser interface 20 with user-defined interface controls, as discussed in detail above. Thereafter, any messages from the new (i.e., controlled) window will be processed in the BIO window message processing process by setting the parent window of the browser interface 20 to be a window that has been subsumed. Which can be used to add any interface object 40 to the browser interface 20, such as a toolbar, dialog bar, floating dialog, and so forth.

The following illustrative, non-limiting examples of applications are provided to further illustrate the present invention. A plug-in or ActiveX control that remains persistent as an internet user roams the internet may add an interface object 40 to the browser interface 20 that enables the user to download their "bookmarks" or "favorites" from a database located on the internet. The interface would be added directly to the browser interface and would allow the user to access the "bookmark" or "favorites" links they download, using the interface objects 40 provided by the plug-in or ActiveX control. The interface object 40 will provide functionality similar to the current "favorites" or "bookmarks" menu items and toolbars on existing browsers. The difference is that the user can access their bookmarks on any computer browser capable of hosting plug-ins or ActiveX controls, since the bookmarks will be downloaded from a database on the internet.

Revenue can also be generated with the present invention based on placing advertising "links" contained within "favorites" or "bookmarks" on the browser interface 20 through a plug-in or ActiveX control. The consumer's selection (consumer targeting) may be based on, for example, information stored in the database, such as name, age, gender, income, race, education, and geographic location, as well as preferences, such as favorites, bookmarks, or other preferences stored on the database or present on the browser 72.

An interface object 40 may be added to the browser interface 20 using a plug-in or ActiveX control that remains persistent as the user roams the internet, allowing the user to download their "address book" from a database located on the internet. Such an interface object 40 may be added directly to the interface of the browser interface 20 and will allow the user to send e-mail and retrieve saved contact information listed in their "address book".

Revenue may also be earned with the present invention based on placing an advertisement "link" contained within the "address book" on the interface object 40 of the plug-in or ActiveX control. The consumer's selection (consumer targeting) may be based on, for example, information stored in the database, such as name, age, gender, income, race, education, and geographic location, as well as preferences, such as favorites and bookmarks or other preferences stored on the database or present on the browser 72.

The present invention may use a plug-in or ActiveX control to add an edit box on the browser interface 20 that allows the user to enter a search directly within the browser without having to access a web page that allows the user to search.

In addition, even while the user is browsing different websites, a plug-in or ActiveX control that remains persistent may poll from preferred websites, or periodically search (at intervals of user, website, or program selection) for information. When polling the preferred web site, the preferred web site may send updated information to interface objects on the user's browser, such as near real-time notifications of received mail, continuous updates of stock prices, or other time sensitive information, such as news feed headlines (news feed scores), game scores for selected favorite sports teams, and so forth. If desired, the preferred web site may control the timing of polling, thereby controlling traffic on the preferred web site during peak usage periods by extending the time interval between polling.

Since the shell created by the library file, as described herein, is an environment within which applications may run or information may be displayed, any information or program may be added to the interface of the browser using the present invention. The shell is independent of the browser interface, the content of the browser, and even the content of the shell itself. In short, the housing is an adaptable functional sheet, which in the extreme, need not even be visible to the user. Thus, in use, the shell may be empty and receive its content from the website, or the shell may retrieve a plug-in, or the shell may even retrieve a new library file and learn to parse new information "on the fly" as the shell receives new content from the website or user. In this way, the present invention provides significant opportunities to direct the desired information from the preferred sites to the user, even when the user visits other sites. Of course, the more user-specific functionality a website provides with the customizable interface of the present invention, the greater the user loyalty that the website can generate.

In another embodiment of the present invention, and referring now to FIGS. 11-17, a shopping assistant button can be added to the toolbar of the Internet browser interface to facilitate online shopping at a supported merchant website. The functionality of this embodiment, including defining the shopping assistant button, is provided by computer code transmitted from the server and stored on the user's computer. Computer code monitors internet navigation of an internet browser to determine if the browser is on a supported merchant website, provides an indication for a shopping assistant button when the internet browser is on a supported merchant website, and fills in a supported merchant checkout web page.

As used herein, the term "online shopping" refers to a process by which a user of an Internet browser may purchase goods and/or services over the Internet using a computer. An online merchant (e.g., a seller of goods and/or services on the internet) may provide a website that is established on a merchant server through which a user may access one or more web pages using an internet browser. A merchant may provide a sale of various goods and/or services through one or more web pages. The shopper can view the goods, description of the services, select various goods and/or services to place into the electronic shopping cart, view the contents of the electronic shopping cart, and check out (as described in more detail below).

The browser interface 20 depicted in FIG. 11 includes an interface object 40 that includes an interface object toolbar 42, and a shopping assistant button 144 that provides various functions to the browser interface 20, including, but not limited to, the ability of a user of the browser interface 20 (the terms user and shopper are used interchangeably herein) to create and edit electronic purses (discussed in more detail below), disabling the shopping assistant button 144 (and shopping functions of the browser interface 20), listing supported merchants, querying for functionality provided with respect to the shopping assistant button 144, the drop down menu 44, and the shopping assistant button 144, and querying for assistance with respect to the use and functionality provided by the shopping assistant button 144. Shopping assistant computer code or software (e.g.,. dll or. exe files, javascript, etc.) is provided by the server and stored on the user's computer 50 and is operable in conjunction with the browser and browser interface 20 to define and provide the shopping assistant buttons 144 and other functionality provided in accordance with the present invention, as described in greater detail below.

In a preferred embodiment, the shopping assistant button 144 and the functionality provided is provided when an interface object 40 is added to the browser interface 20, as described in detail above in connection with various embodiments of the present invention. That is, when the interface object 40 is added to the browser interface 20, the shopping assistant button 144 and associated computer code are transferred or downloaded to the user's computer 50. As another alternative, the shopping assistant button 144 and functionality can be selectively added to the browser interface 20 at the request of the user, i.e., before or after the interface object 40 is added.

In at least a first example, a server 102 (which may comprise one or more computers that are located physically close to each other or physically separate from each other) (see, e.g., FIG. 10) provides a shopping assistant function in accordance with the present embodiment of the invention that is accessible when a user provides a predetermined Internet address or URL at the URL address window 26 of the browser interface 20. Preferably, the server 102 is a secure server (i.e., accessible only over a Secure Sockets Layer (SSL) connection). At the predetermined internet address, the user may access one or more web pages, at least one of which enables the user to establish a wallet in accordance with the present embodiment of the invention. Fig. 12-14 depict exemplary wallet build web pages, discussed in more detail below.

The shopping assistant computer code or software downloaded by the server 102 onto the user's computer 50 also provides a shopping assistant function, which may operate in conjunction with the browser interface 20 and the shopping assistant button 144. The shopping assistant code may be a. dll or. exe file, such as javascript, or other known type of computer code or software file. The shopping assistant code monitors the internet navigation of the internet browser, which intercepts the internet address (or domain or URL) each time the user causes the browser to navigate to a different internet address. The shopping assistant code also compares the intercepted internet address with the internet addresses of the supported merchants, which compares the intercepted address with a supported merchant file containing the internet addresses of the supported merchants. Preferably, the supported merchant files are downloaded by server 102 and stored on user's computer 50. Each time a user logs into the server 102, the server 102 compares the version of the merchant file it supports with the version stored on the user's computer 50 (e.g., the user may transmit the version information during the login process). Server 102 downloads the updated version of the supported merchant file to the user's computer if necessary. The shopping assistant code also intercepts each web page received by the browser and determines the type of web page (e.g., billing web page, merchant home page, merchandise page, etc.) by HTML code and http request header.

The shopping assistant code also defines a shopping assistant button 144 and a pull-down menu 44 and controls communications between the browser, server 102 and merchant server for online shopping.

Shopping assistant button 144 may be provided as part of interface object 40 in accordance with various embodiments of the present invention. However, to utilize and access the shopping assistant functionality, the user must first establish a wallet. As used herein, the term "wallet" refers to a file (which may be encoded or encrypted) for a user that includes information (also referred to herein as data) customized for the user, which is provided by the user and stored within a wallet database 104 provided on a data storage device (e.g., hard drive, optical disc, etc.) of a server 102 (see, e.g., fig. 10). The wallet database 106104 is structured so that information provided by the user when setting up a wallet is stored in predefined fields or field names. Similarly, the structure of the supported merchant files is organized using the same fields or field names, such that the merchant checkout web page requires the same information as provided during the wallet build process.

To establish a wallet, the user must provide specific information in response to establishing a web page for the particular wallet provided by server 102. As known to those skilled in the art, an Internet browser receives data, typically HTML data, from a server for display by the browser interface 20. Thus, reference herein to a web page served by a server refers to downloading or transferring data from the server for display by an internet browser.

Fig. 12 depicts an exemplary wallet establishing web page, generally designated 1000. The web page 1000 may be accessed, for example, by the "edit wallet" option on the drop down menu 44 of the shopping assistant button 144. By selecting a predetermined link on the wallet establishing web page 1000, say the "establish your wallet" link 1002, the server 102 downloads a wallet data entry web page 1010, for example as described in fig. 13. At the wallet data entry web page 1010, the user enters specific information in a number of fields 1012 (drop down menus or alphanumeric entries). This information may be, but is not limited to, credit card type, number, expiration date, first and last name of the user, billing address, telephone number, user ID, user password, and various other information specific to the user. When a wallet is established, each user is required to enter a security key (see, e.g., fig. 16) in addition to the user's ID and password, which is a necessary item to access and use the user's wallet. When the user completely fills out all necessary fields 1012 on the wallet data entry web page 1010, the user may select an "end" button (not shown) that sends the information entered by the user to the server 102. In response, the server 102 downloads a wallet summary webpage 1020 that includes a summary of the user's newly entered account information 1022 for review by the user before the user's wallet is finally established, as described in fig. 14. If the user information is correct, the user may select a link on wallet summary web page 1020, e.g., "click continue here.." link 1024, which causes the user information (data) to be sent to server 102 and stored in wallet database 104 on data storage device 106. During the wallet establishment process described by the party, data is transmitted between the server 102 and the user's computer 50 (see, e.g., fig. 10). For example, when the user selects the "set your wallet" link 1002, web pages 1000 (FIG. 12) and 1010 (FIG. 11) may both be sent by the server 102 for display by the user's browser interface 20. When the user has completed the necessary information on the wallet data entry web page 1010 and selects an "end" button (not shown), the user information or data may be sent to the server 102. Upon receiving user information from the user's computer 50, the server 102 may send a wallet summary web page 1020. Alternatively, server 102 may send each of the above-described web pages separately in response to a user-initiated action (e.g., when the user selects a link or button).

The server 102 may belong to a content provider 100 or other internet service provider, such as a search engine provider or ISP, collectively referred to herein as provider 100. Provider 100 selects an online merchant with which the shopping feature of the present invention may be used. The supported merchant file contains a list of all supported merchants, including their respective internet addresses. The shopping assistant computer code may use this file to determine if the user has navigated to a supported merchant web site, which compares the URL entered into the URL address window 26 (or provided by the link) with the URL contained within the supported merchant file.

Once a merchant has been selected (merchant is indicated generally as 200 in fig. 10), provider 100 determines the merchant's checkout process, including the layout of the checkout web page (see, e.g., fig. 17), and the information necessary to complete the merchant's checkout process and checkout web page. Provider 100 creates a supported merchant rules and mapping file for each selected merchant (also referred to herein as a supported merchant) that defines a plurality of merchant field names that correspond to user data required by the merchant during its checkout process with which it checks out web pages. For example, and referring to FIG. 17, a supported merchant checkout web page 2100 asks the shopper to provide billing information including, for example, payment method, credit card number, expiration date, and personal information (e.g., name, address, and phone number) of the shopper. The merchant field name corresponds to a wallet field name defined within the user's wallet. Since each merchant may require different information during its checkout process, each supported merchant rules and mapping file may contain a different merchant field name. However, all merchant field names correspond to wallet field names.

The supported merchant rules and mapping file maps wallet data (i.e., wallet field names) to the necessary merchant data (i.e., merchant field names). For example, the structure of the entries in the organizational merchant rules and mapping file that define the first name field and the last name field is as follows:

rmi_pageFields[1]＝new rmi_fieldMap(“contactFirstName”，“text”，“wallet_b_fname_first”)；

rmi_pageFields[2]＝new rmi_fieldMap(“contactLastName”，“text”，“wallet_b_fname_last”)；

where "wallet _ b _ fname _ first" is the wallet database field name for the user's name. However, in the supported merchant file, the user's name is identified as "contectfirstname". Thus, the present invention maps fields within the wallet database to fields within the supported merchant files so that each merchant order form may be automatically filled out as the user shops on the supported merchant web site.

Referring now to fig. 15-17, an exemplary checkout process will now be described. Since different merchants may have different checkout processes and provide different checkout web pages, the following description is merely illustrative and is not intended to limit the scope or otherwise define the invention. Additionally, the following description does not track the entire online shopping process (which may also vary from merchant to merchant), but is simply a checkout process, which generally begins after the user selects a "checkout" or other similar button on the merchant web page.

When a user launches their internet browser, the interface object 40 automatically establishes a connection between the user's computer 50 and the server 102. Server 102 downloads various user data to user's computer 50. The user may cause the internet browser to navigate to any internet address by entering the address within a URL address window (see, e.g., fig. 11), or by selecting a link on a web page. Regardless of how the browser is caused to navigate the internet, the shopping assistant code intercepts the URL of each internet site that the user navigates and compares the URL to the supported merchant data file. If a match is found, the shopping assistant code provides a user-perceptible indicator, such as a yellow circle, on the shopping assistant button 144 indicating that the user has navigated to the supported merchant web site. The shopping assistant code also requests the server 102 to download a file containing the merchant's rules and mapping data and providing details of the merchant's checkout process.

The shopping assistant code also intercepts each web page received by the browser to determine the type of web page, e.g., billing web page, email address request, credit card information request, etc., by looking at the HTML code and http request header. This information is obtained during the provider selection of a merchant and creation of a supported merchant data file. Using the merchant's rules and mapping file, the shopping assistant code is able to determine how a particular page is provided and how the user's information should be provided within that page.

If the shopping assistant code determines that the user's wallet is necessary for a particular page, it opens the security key window 3000 in the user's browser interface 20, requesting the user to enter the Security Key (SK) in the data entry window 3020, as described in FIG. 15. Once the user enters SK and selects the "continue" button 3030, the user's computer 50 securely transmits the security key, preferably using https, to the server 102. The server 102 compares the user data (e.g., ID and SK) to data within the user's wallet that was previously stored on the wallet database 106. If the data matches, the SK is verified, and the server 102 sends an authentication to the shopping assistant code; if the data does not match, a rejection is sent. Authentication may be provided as a wallet information window 3100, for example, as described in fig. 16. When the server 102 successfully authenticates to the SK, a "security cookie" is sent to the secure server over SSL, and when the "security cookie" is set, the user starts an online shopping session using his/her wallet. The "secure cookie" will actively expire, preferably valid for no more than one (1) hour.

If the user wants to continue the checkout process using the shopping assistant function of the present invention, the user may select the "continue" button 3130. If the user wants to check out using the merchant's check-out process, the user may select the "cancel" button 3140. When the user selects the "continue" button 3130, the shopping assistant code retrieves the user's wallet from the wallet database 104 on the server 102 and automatically fills out the merchant's checkout web page 2100, as described in FIG. 17. The server 102 securely sends the user's wallet, preferably using https. The user's wallet, and the user's personal data, need not be stored on the user's data storage device 52, but rather, need only be stored in a temporary memory (also referred to herein as main memory or RAM)60, for use by and in connection with the shopping assistant code and functions of the present embodiment of the invention. The user's data may automatically expire or may be purged from memory 60 when the user closes the browser.

Depending on the type of web page that the browser displays, the shopping assistant code provides the appropriate user data to the web page from the user's wallet (temporary data in RAM). For example, if the shopping assistant code determines that the web page is a "billing address" web page, the user's billing address data will be copied from RAM to fill in fields within the billing address web page and ultimately sent to the merchant's server. During the checkout process, the shopping assistant code operates in conjunction with the merchant rules and mapping file and the user's wallet to automatically provide the user data required by the various merchants to checkout the web page.

The wallet database 106 may contain only wallet data or, alternatively, wallet data and other data within the database. While it is preferred that the wallet be used by and in conjunction with the shopping assistant button 144 and functionality, the wallet may also be used by other applications besides shopping assistants, such as bill payment, shopping without shopping assistants, and in conjunction with essentially any online transaction that requires the user to enter personal data. The wallet provides secure transmission and processing of the user's data and allows the user to use the data in conjunction with various online transactions without unnecessarily compromising the security of the data.

Once the user has established a wallet, the functionality provided in accordance with the present embodiment of the invention is now open to the user as a user's online store. Preferably, the online shopping function is open for use in connection with supported merchants, regardless of which internet site the user connects to (via an internet browser). Thus, the user need not be connected to the provider's internet site, or even the supported merchant's website. The shopping assistant code handles all communications between the user (the user's computer 50), the server 102, the wallet database 104, and the merchant's internet site and checkout web pages.

According to another embodiment of the present invention, a party other than provider 102 may add a button 44 (i.e., an interface object) to a browser interface toolbar, such as interface object toolbar 42 (see, e.g., fig. 4). For example, a link may be provided on a corporate website so that visitors to the website can add a button 44 to their interface object toolbar 42 that will provide a single click link from the browser interface 20 to the corporate website. Since adding the company button to the interface object toolbar 42 enables the user to return to the company's website, the company or any entity that maintains the website, from any other website by clicking a mouse, the provider 100 may be sponsored. Thus, adding the company button to the browser interface (i.e., toolbar 42) establishes an affinity between the user and the company's website. The company sponsor designs the buttons (e.g., appearance (single click button or drop down menu), icons, etc.) and provides the button design and URL data to the provider 100 for integration into the database maintained by the provider and association with the browser interface. In this way, a company sponsor may have buttons defined in the provider database.

The present invention also allows for the installation of a browser interface toolbar 42 and company buttons 44 within the browser interface 20 if a visitor to the company's website wants to install company buttons within their browser interface 20, but does not have a browser interface toolbar 42 installed. On the other hand, a company button 44 may be added to the toolbar 22 of the browser interface 20 or may be added as a button 44 of the interface object toolbar 42.

The present invention may also be used as a teaching tool. For example, the interface object toolbar 42 may include a plurality of buttons 44 that may be caused to change color, flash, highlight, etc. to direct the user's attention to the button or the function provided by the button.

The present invention may also allow a provider or company sponsor to notify users of specific attributes of the provider or company sponsor when the users visit a competitive website. For example, when a user visits an automobile website, the corresponding provider attribute (e.g., provider automobile) will be highlighted to alert the user that the feature is available on the provider website. Software may be provided on the user's computer to intercept the URL each time the user causes the browser to navigate to a website. The intercepted URL may be compared to a file containing multiple URLs for provider attributes.

Importantly, the user's computer alone determines which web site the user navigates to at any particular time. Thus, no information about the user's activities on the internet is sent to any server.

Generally, two steps are required to add a merchant to the user's merchant list. First, the user must establish the online account of the merchant through the web page of the merchant. In doing so, the user may be requested to enter a user login identifier, a password, and an account number. Once the merchant accepts the data, an online account is established for the user. Second, the user must link the online merchant account to data within the secure database for the user. For example, a user may access a web page through which a merchant may be selected and data specific to the user and merchant (e.g., the user's login identifier, password, account number, etc.) entered. This data may then be validated (by communicating with the merchant web site) and stored to a secure database for the user. This step(s) may be performed using another web page (i.e., a web page that may not be associated with the merchant). Once these two steps are completed, the user may add merchants to the merchant list and effect automatic login to the user's account at a particular merchant by simply selecting a merchant from the merchant list.

Each time a user activates (launches) his/her browser, computer code provided in accordance with the present invention will automatically communicate with a predetermined internet site to obtain data specific to that user. The retrieved data can be used, in whole or in part, to provide functionality to the browser and to add interface objects to the browser interface. Thus, the retrieved data will define an auto-login interface object, including the most current merchant list.

Referring next to fig. 18A-18B, a preferred embodiment of the auto-login method of the present invention will now be discussed in detail. The method described in fig. 18A-18B, and discussed in detail below, considers an auto-entry interface object to have been added to a browser interface, as described in detail above. The method also contemplates that computer code that provides automatic login (and other) functionality in accordance with the present invention has been transferred to the user's computer and is operable in conjunction with its processor and in conjunction with the user's internet browser. At step 1810, the user selects a merchant from a list of merchants provided through an auto-login interface object, which may include buttons and drop-down menus. At step 1820, computer code (also referred to as a client) causes the browser to open a hidden window in which an auto-logon process will be performed. The computer code also transmits a first request to a server, preferably a secure server, that includes the merchant identifier and a cookie, as described in FIG. 19 and discussed in more detail below. At step 1822, the security server receives the first request and determines whether the cookie is a secure cookie. If the cookie is not a secure cookie, the user has not yet securely logged in for the current Internet session, or a predetermined amount of time has elapsed since the user securely logged in. In either case, at step 1830, the security server transmits one or more web pages (which are opened within the user's browser as new browser windows) to the user's browser, prompting the user to enter specific data to securely log in. One of the data that the user must enter is a security key, which the security server receives and determines if it is the correct and/or valid security key for the user at step 1832. If an incorrect security key is entered, the security server determines if the user has attempted to reenter the security key more than a predetermined number of times at step 1834. If the user has exceeded the allowed number of retries, the secure login process will terminate (terminated by the secure server) and the user's browser will return to display the web page displayed prior to the user selecting a merchant from the merchant list of the auto-login interface object (button), step 1850. If the user has not exceeded the number of allowed retries and has not selected to cancel the secure login process, the user may attempt to re-enter the security key at step 1836; at step 1832, the security server again determines whether the correct security key has been entered. If, after a predetermined number of attempts, the correct security key has not been entered, or the user chooses to terminate the secure login process by selecting a cancel button, the secure login process will terminate (terminated by the secure server) and the user's browser will return to the web page displayed prior to the user selecting a merchant from the merchant list in the auto-login interface object (button), step 1850.

If the user successfully enters the correct security key, the security server transmits an approval message to the computer code, step 1840, which will then transmit a second request 1842 to the provisioning server requesting the credentials of the user specific to the selected merchant. The second request may include the user identifier and the merchant identifier, which may be interpreted by the provisioning server to locate the user and the user's credentials within the database. If the provisioning server matches the second request to a database entry, the provisioning server will transmit the user's credentials (e.g., login identifier and password for the merchant, website identifier (e.g., URL) for the merchant, and merchant rules file) to the user's computer. The computer code receives the credentials and causes the user's browser to navigate to the merchant's web site (as determined by the URL) and automatically fills in the login fields with the user's login identifier and password and according to the merchant rules file, thereby enabling the user to automatically login to the merchant's web site.

Computer code provided in accordance with the present invention performs the automatic login process described above in a transparent manner. In addition, the present invention provides the ability to control the browser interface, and thus the navigation of the user, in such a way that the rules for controlling navigation (in this case, in the case of automatic logging into the merchant's website) can be changed at the server side without changing at the client side. The present invention may advantageously utilize a Document Object Model (DOM) available to the browser to implement rule changes as described in the claims. That is, after the user selects a merchant from the merchant list, the computer code performs an automatic login process without further input from the user (except in the case where the user is not securely logged in). With continued reference to FIGS. 18A-18B, the automatic registration performed by computer code provided in accordance with the present invention will be discussed in greater detail. At step 1844, the computer code determines whether it has received a certificate as a response to the second request. If not, the computer code generates an error message, which is displayed by the user's browser, step 1860. Thereafter, the computer code causes the hidden window (opened at step 1820) to close and causes the auto-login process to terminate. The display within the browser then returns to the web page displayed before the user selects the merchant from the merchant list. If the computer code has received a certificate, as determined in step 1844, the computer code launches another hidden window to perform the remainder of the auto-login process in step 1870. At any time prior to completion of the auto-login process, the user may cancel the process by selecting an appropriate button of the computer code display, such as a cancel button displayed when the computer code performs the auto-login process. If the user chooses to cancel the automatic login process, at step 1872, the computer code will close all hidden windows opened during the process and the display of the browser returns to the web page displayed before the user selected the merchant from the merchant list. If the user does not manually terminate the auto-login process, the computer code may cancel the process if a predetermined amount of time has elapsed before the process is completed. For example, after receiving the credentials, the computer code may not be able to cause the browser to navigate to the merchant web site due to device or network issues. In this case, the computer code will terminate the auto-login process, step 1874, and display an error message to the user: auto-login cannot be completed, step 1878. At this point, the computer code may provide the user with an opportunity to again attempt the auto-login process, step 1878, at which point the process returns to step 1844 and proceeds as described herein.

If the computer code determines that the auto-login process has not automatically timed out, step 1874, then the computer code determines whether it has received a login confirmation from the merchant website, step 1876. To do this, the computer code evaluates the HTML data received within the hidden window and looks for a predetermined word, words, message or other indicator that the login to the merchant's website has been successful. For example, after the user successfully logs in, the merchant website may display a message. The message may be included as part of a merchant rules file that is transmitted by the provisioning server to the computer code as part of the certificate. In this way, the computer code can determine whether the automatic login has been successful. If successful, the computer code displays the web page from the merchant web site within the main browser window, step 1890, effectively causing the user's browser to navigate to the merchant web site and directly to the web page for the user's account.

Referring next to FIG. 19, there is depicted a system for facilitating automatic login of a user to a website. The system includes a server, which may be a stand-alone server, or multiple servers 1900, 1920, 1940, as a daily matter of design choice. In a preferred embodiment, the system includes a server having a data storage device and having software stored thereon. The software transmits computer code to the user's computer to add automatic login functionality to the user's internet browser, as described in detail herein.

In the embodiment depicted in FIG. 19, security server 1900 performs a secure login process in conjunction with computer code. Security server 1900 has a database with a plurality of user data and corresponding security key information. The secure server 1900 may receive a cookie from the user and determine whether the cookie is a secure cookie with a valid security key. If so, the secure server 1900 may transmit a confirmation or authentication to the user code on the user's computer.

The offer server 1920 has a database with a plurality of user data, including merchant login and password data, and merchant rule data, for each merchant, provided by the user. When the computer code on the user computer receives an acknowledgement or authentication from the secure server, the computer code sends a second request to the provisioning server, including a cookie, having a user identifier and a merchant identifier. The provisioning server determines whether there is a match between the user identifier and the merchant identified in the database on the provisioning server and, if so, transmits the certificate to the user's computer. In a preferred embodiment, the credentials include a user login identifier, a password, and a merchant rules file, all of which are specific to a particular merchant. The computer code uses the credentials to cause the user's browser to navigate to the merchant's website and to a login web page on the site to automatically fill in login fields (login identifier and password) and effect login according to the merchant rules file (e.g., selecting a "login" or other similar button). At this point, the user's computer may connect to the merchant's server 1940 via the Internet. Once the computer code determines that the auto-login has been successful, the browser displays the merchant web page for the user's account.

It will be apparent to those skilled in the art, and in light of the disclosure provided herein, that various embodiments of the invention can be implemented using software provided on a user's computer and on various servers.

It should be appreciated that the present invention may be implemented using any number of computer technologies. For example, while various embodiments are disclosed in conjunction with the Internet, the present invention may be used on any computer network, including, for example, a wide area network. Similarly, the user computer 50 may be any device that may be connected to a network including, for example, a personal digital assistant, a web-enabled cellular telephone, a fixed telephone that dials into the network, a mobile computer, a personal computer, an Internet appliance, and so forth. Further, the servers described herein may be of any type, running any software, and the software modules, objects, and plug-ins described herein may be written in any programming language. Finally, the databases and storage devices described herein may use any storage technology, including, for example, local computer memory, network storage, and any known storage medium, such as magnetic (media) or optical (media).

Thus, while there have been shown and described and pointed out fundamental novel features of the invention as applied to preferred embodiments thereof, it will be understood that various omissions and substitutions and changes in the form and details of the disclosed invention may be made by those skilled in the art without departing from the spirit of the invention. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.

Claims (63)

1. A method of facilitating automatic login of a user to a website using an internet browser and a computer, the method comprising the step of transmitting computer code to the computer to add an automatic login function to the browser, which function uses user data to automatically login the user to the website.

2. A method as recited by claim 1, wherein said transmitting step comprises transmitting computer code to add a button that adds an automatic login function to the browser enabling a user to access a merchant list and automatically log into a merchant's website on the merchant list by selecting the merchant from the merchant list.

3. The method of claim 2, wherein the button provides access to the merchant list through a drop down menu.

4. A method as recited by claim 2, wherein the computer code facilitates automatic transmission of the request to the server when the user selects a merchant from the merchant list.

5. The method of claim 4, wherein the request comprises a secure cookie.

6. The method of claim 4, wherein the request comprises a first request and a second request comprising a user identifier and a merchant identifier.

7. The method of claim 6, wherein the first request comprises a secure cookie.

8. The method of claim 1, wherein the computer code monitors the browser for internet navigation by intercepting an internet address of each internet site to which the browser is caused to navigate.

9. A method as recited by claim 2, wherein the computer code determines whether a merchant is a supported merchant.

10. A method as recited by claim 1, wherein the computer code provides an indicator when causing the browser to navigate to a supported merchant web site.

11. The method of claim 2, further comprising the steps of:

receiving a first request from a user;

determining whether the first request is a secure request;

transmitting a response to the user if the first request is a secure request; and

transmitting a secure login web page to the user for display by the Internet browser if the first request is not a secure request.

12. The method of claim 11, wherein the determining step comprises determining whether the first request contains a secure cookie.

13. The method of claim 11, further comprising the steps of:

receiving a second request that requires user credentials; and

transmitting the user credentials to the user.

14. The method of claim 13, wherein the user credentials are stored on a server, and wherein the user credentials are at least one of a login identifier and a password, and wherein the user credentials are specific to a merchant and a website of the merchant.

15. The method of claim 13, wherein the second request includes at least one of a user identifier and a merchant identifier.

16. The method of claim 14, wherein the user credentials comprise a merchant rules file for the selected merchant.

17. An internet browser interface that can be displayed on a computer display by an internet browser, a user of the browser can modify the browser interface to add functionality to enable a user to automatically log the user into a website using user data.

18. An internet browser interface as recited by claim 17, wherein said functionality is provided by computer code operable in conjunction with a processor of said computer.

19. An internet browser interface as recited by claim 18, wherein said functionality is provided by computer code operable in conjunction with a processor of the computer for adding an auto-login button to the browser interface that adds an auto-login functionality to the browser enabling a user to access a merchant list and automatically log into a merchant's website on the merchant list by selecting the merchant from the merchant list, and wherein said button provides access to the merchant list.

20. An internet browser interface as recited by claim 19, wherein the computer code facilitates automatic transmission of a request to a server when a user selects a merchant from the merchant list.

21. The internet browser interface of claim 20, wherein the request comprises a secure cookie.

22. An internet browser interface as recited by claim 20, wherein the request includes a first request and a second request that include a user identifier and a merchant identifier.

23. The internet browser interface of claim 22, wherein the first request contains a secure cookie.

24. An internet browser interface as recited by claim 18, wherein said computer code is further operable in conjunction with said processor to monitor internet navigation of said browser by intercepting an internet address of each internet site to which said browser is caused to navigate.

25. An internet browser interface as recited by claim 18, wherein said computer code is further operable in conjunction with said processor to determine if a merchant web site is a supported merchant web site.

26. An internet browser interface as recited by claim 19, wherein said computer code is further operable in conjunction with said processor of said computer to:

transmitting a first request;

transmitting a second request that requires user credentials; and

receiving the user credentials.

27. An internet browser interface as recited by claim 26, wherein said user credentials are stored on a server, and wherein said user credentials are at least one of a login identifier and a password, and wherein said user credentials are specific to a merchant and a website of said merchant.

28. The internet browser interface of claim 26, wherein the first request contains a secure cookie.

29. An internet browser interface as recited by claim 28, wherein the second request includes at least one of a user identifier and a merchant identifier.

30. An internet browser interface as recited by claim 29, wherein the user credentials include a merchant rules file for the selected merchant.

31. A system for facilitating automatic login of a user to a website using an internet browser and a computer, wherein user data is necessary to login to the website, the system comprising:

a server connectable to the internet, comprising:

a data storage device; and

a processor operable in conjunction with software stored on the data storage device for transmitting computer code to the user's computer for adding an automatic login function to the browser, wherein the computer code adds an automatic login function to the browser that uses user data to automatically log the user into the website.

32. A system as recited in claim 31, wherein the computer code adds a button to the browser that adds an automatic login function to the browser enabling a user to access a merchant list and automatically log into a merchant's website on the merchant list by selecting the merchant from the merchant list.

33. The system of claim 32, wherein the button provides access to the merchant list through a drop down menu.

34. A system as recited by claim 32, wherein said computer code facilitates automatic transmission of a request to a server when a user selects a merchant from said merchant list.

35. The system of claim 34, wherein the request comprises a secure cookie.

36. The system of claim 35, wherein the request comprises a first request and a second request comprising a user identifier and a merchant identifier.

37. The system of claim 36, wherein the first request comprises a secure cookie.

38. The system of claim 34, wherein the processor is further operable in conjunction with software to determine whether the request includes a secure cookie.

39. The system of claim 31, wherein the computer code monitors the browser for internet navigation by intercepting an internet address of each internet site to which the browser is caused to navigate.

40. A system as recited by claim 39 wherein said computer code determines if the merchant web site is a supported merchant web site.

41. The system of claim 31, wherein the server is a secure server.

42. The system of claim 32, wherein the processor is further operable in conjunction with software to:

receiving a first request from a user;

determining whether the first request is a secure request;

transmitting a response to the user if the first request is a secure request; and

transmitting a secure login web page to the user for display by the Internet browser if the first request is not a secure request.

43. The system of claim 42, wherein the processor is further operable in conjunction with software to determine whether the first request contains a secure cookie.

44. The system of claim 42, wherein the processor is further operable in conjunction with software to:

receiving a second request that requires user credentials; and

transmitting the user credentials to the user.

45. The system of claim 44, wherein user credentials are stored on a server, and wherein the user credentials are one or more of a login identifier and a password, and wherein the user credentials are specific to a merchant and a website of the merchant.

46. The system of claim 44, wherein the second request includes at least one of a user identifier and a merchant identifier.

47. A system as recited by claim 45 wherein the user credentials include a merchant rules file for the selected merchant.

48. A method of controlling an internet browser interface, said interface being displayable by an internet browser on a display of a computer, said internet browser enabling a user of said computer and internet browser to access and browse the internet and receiving and displaying on said computer display one or more web pages from one or more internet sites, including displaying web pages from predetermined internet sites, said internet browser having at least one internet browser toolbar having at least one toolbar button providing predetermined functionality to said user of said computer and internet browser, said method comprising the steps of:

(a) providing access to a program at the predetermined internet site for controlling the internet browser interface; and

(b) enabling the predetermined internet site to download a file for display as part of the internet browser interface, the user toolbar opening additional functionality to the user such that, upon display of the user toolbar, the user toolbar remains displayed regardless of the internet site to which the internet browser is caused to navigate, and the additional functionality remains open to the user, wherein the file adds an auto-login functionality to the browser that uses user data to automatically log the user in to the website.

49. The method of claim 48 wherein the user toolbar includes interface objects and is customizable by the user to provide user-selected functionality within the user toolbar.

50. The method of claim 48 wherein the file comprises an ActiveX control.

51. The method of claim 48, wherein the file comprises a plug-in.

52. The method of claim 49, wherein the interface object is a toolbar button.

53. A method as defined in claim 49, wherein the interface object is a search window that enables the user to initiate a search on the predetermined Internet site regardless of which Internet site the computer is connected to through the browser at the time the search is initiated.

54. The method of claim 48, wherein the predetermined Internet site maintains user-specific information for a plurality of users, including users of the computer and Internet browser, the method further comprising the steps of: enabling the predetermined internet site to download information specific to the user of the computer and internet browser defining all or part of the user toolbar, and wherein all or part of the display of the user toolbar is dependent on the information specific to the user of the computer and internet browser downloaded for the predetermined internet site.

55. The method of claim 54, further comprising the step of: enabling the predetermined internet site to download additional information specific to the user of the computer and internet browser that defines all or part of the user toolbar, and wherein all or part of the display of the user toolbar depends on the downloaded information.

56. An internet browser interface displayable on a display of a computer by an internet browser, the internet browser facilitating connection between the computer and one or more internet sites, the one or more internet sites including a predetermined internet site, the internet browser having at least one internet browser toolbar opening a predetermined function to a user of the computer and internet browser, the internet browser further facilitating display of one or more web pages from one or more internet sites on the computer display including display of web pages from the predetermined internet site, the internet browser interface including a user toolbar which, when the internet browser is activated, regardless of which internet site the computer is connected to through the browser, is displayed as part of the internet browser interface and with the internet browser toolbar, wherein the user toolbar opens additional functionality to the user as part of the internet browser such that upon display of the user toolbar remains displayed regardless of the internet site to which the internet browser is caused to navigate and the additional functionality remains open to the user, wherein the additional functionality adds an auto-login functionality to the browser that uses user data to automatically log the user into the website.

57. An internet browser interface as recited by claim 56, wherein said user toolbar includes interface objects and is customizable by said user.

58. An internet browser interface as recited by claim 57, wherein said interface object is a toolbar button.

59. An internet browser interface as recited by claim 57, wherein said interface object is a search window that enables the user to initiate a search on said predetermined internet site regardless of which internet site the computer is connected to through the internet browser at the time the search is initiated.

60. An internet browser interface as recited by claim 57, wherein said interface object includes an ActiveX control that allows user customization of said interface object.

61. An internet browser interface as recited by claim 57, wherein said interface object includes a plug-in control that allows user customization of said interface object.

62. An internet browser interface as recited by claim 57, wherein said predetermined internet site maintains user-specific information for a plurality of users, including users of said computers and internet browsers, wherein when said internet browser is first activated, said interface object causes said internet browser to establish a connection to said predetermined internet site and receive information from said predetermined internet site, said information being specific to said users of said computers and internet browsers, and wherein all or part of said user toolbar depends on said information received from said predetermined internet site, specific to said users of said computers and internet browsers.

63. An internet browser interface as recited by claim 62, wherein when said internet browser is activated, said interface object causes said internet browser to periodically re-establish a connection to said predetermined internet site to receive additional information from said predetermined internet site, said additional information being specific to a user of said computer and internet browser, and wherein all or part of said user toolbar depends on said received information and additional information.