HK1074682A - Online shopping using browser, wallet, and key - Google Patents

Description

Online shopping using browser, wallet and key

Cross reference to related applications

This application is a Continuation-In-Part (containment-In-Part) of currently pending U.S. patent application 09/429,585 filed on 28.10.1999.

Technical Field

The present invention relates to a method and system for facilitating online shopping using an internet browser.

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 physical link to the internet (e.g., through a modem and Internet Service Provider (ISP)), and provides a textual and graphical user interface, i.e., a browser interface, that has a predetermined look and function, neither of which is currently significantly changeable by internet users. Thus, when an Internet user browses the Internet, the user moves from web site to web site, and thenThe browser interface remains relatively static as one moves programmatically to applications or from HTML (hypertext markup language) pages to HTML pages.

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.

The proliferation of internet sites has made it increasingly difficult for content providers (e.g., owners of internet sites) to attract internet users to spend as much time as possible on a particular internet site. Of course, the content provider may want the internet user to spend the most time on his or her own internet site, or to ensure that the internet user will return to the content provider's website; such a condition is commonly referred to in the art as stickiness (tack). Many business models for internet site providers are based, at least in part, on advertising revenue. The greater the likelihood that a user will stay at or return to an internet site, the greater the likelihood that the user will see an advertisement displayed by that site. Thus, the internet site provider can receive more revenue from the advertisements on the web page.

Content providers also want the greater the number of internet users who access their web sites, the better. In short, internet content providers wish to attract as many internet users as possible to visit their websites and to stay on their websites for as long an amount of time as possible; both of which are not possible with the existing internet browser.

Among the many benefits of the internet, online shopping has unique advantages over traditional shopping. Clearly, these features of online shopping can save shoppers time and money by easily accessing a large number of commercial web sites, browsing their respective products, comparing prices and placing orders in a relatively short amount of time at home or in the office. In addition, shoppers who have difficulty visiting many stores (due to weather, lack of stores nearby, or other reasons) can now easily see an almost unlimited number of stores and merchandise with only their fingertips.

The experience of online shopping is relatively rapid. The shopper can navigate from the commercial website to the commercial website, browse through the merchandise, select the merchandise and place it in an electronic shopping cart, all of which can be accomplished with a few mouse clicks. However, the checkout process is still relatively time consuming and labor intensive. Once the shopper completes the shopping process, the checkout process may be initiated by selecting a "checkout" option on the merchant website. Typically, the shopper then needs to enter various personal data including name, billing and shipping address, credit card number, etc. The shopper must repeatedly provide this information to each supplier to complete each online shopping transaction, which increases the likelihood of errors (during the shopper's providing the information) and slows the processing of the online shopping process.

Disclosure of Invention

The present invention relates to a method of dynamically controlling an internet browser interface and a dynamically controllable browser interface. In embodiments of the present invention, a shopping assistant button and shopping assistant functionality are incorporated into a browser interface and provide a user (e.g., an online shopper) with a quicker and more accurate online shopping process.

The invention also relates to a method for increasing the number of times an internet user accesses a particular internet site, and to a method for increasing the access time of an internet user at a particular internet site.

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) may be selectively displayed and periodically changed or updated while a browser displaying the interface object is activated.

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, and view web pages provided by content providers at 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 (a child window of the first parent window), and one or more windows dependent on the second parent window (i.e., child windows). The second parent window and the windows dependent thereon may provide, for example, various information (e.g., advertisements, coupons, news, HTML links, etc.) and functionality (i.e., 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" refers to a location (i.e., a node) on the internet that 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 and provides 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 hypertext markup language (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 (e.g., investment portfolio, news headlines, bookmarks, address book, etc.) 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 connect the user's browser to the content provider's internet site while the browser is active, i.e., 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 the control program or programs 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, thereby 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.

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; and

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

Detailed Description

The present invention relates to a method of controlling and displaying an internet browser interface, and a controllable internet browser interface. According to the present invention, the browser interface may be customized using a control software program provided by an internet content provider, ISP, or resident in the internet user's computer. The control software program enables an internet user, content provider or ISP to customize and control the information and/or functionality of the user's browser and 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 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 the communication of information (i.e., digital data) between the various devices of computer 50, as well as the 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 (i.e., browser).

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 (i.e., customer) 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 control or plug-in code that can control (i.e., add, delete and/or modify) 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 the control program 120 through the Internet site 130, ISP 80 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 (i.e., to the library file 74) 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 (if the user is no longer surfing the web), 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 windows can be sub-typed using the CWnd: SubclassWindow () function of Microsoft base class library (MFC). As another alternative, the window may be sub-classified by calling the SetWindowLong function (a Microsoft Windows function) and passing the GWK _ WNDPROC 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 such an occurrence, the BIO process may intercept messages (e.g., commands) from the browser 72, redraw 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 (i.e., object a) 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 (i.e., it is deleted from the browser interface 20 or terminated), 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 IWebBrowerApp OLE 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 commands such as the MFC commands CWnd: MessageBox ("my modal", MB _ OK), the schema 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, <0 object > tags, typically contained within the web page 130, or as Band objects, as described by the Microsoft Internet Explorer 4.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 must now add/delete/modify (i.e., 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 (i.e., add, delete and/or modify) 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 plug-in may now control (i.e., add/delete/modify) 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 the browser 72 operates when controlling the browser interface 20, i.e., adding, deleting, or modifying browser interfaces. 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)1Param, 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 (i.e., toolbar) 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 navigates the browser 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 the wallet summary webpage 1020, e.g., "click here continue … …" link 1024, which causes the user information (data) to be sent to the server 102 and stored in the wallet database 104 on the 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 (moving from one website to another), the shopping assistant code intercepts the URL of each internet site the user navigates to 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 (e.g., after a predetermined time) 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 functionality 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 navigates the browser 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.

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 (58)

1. A method for facilitating online shopping by a shopper at a supported merchant web site, the shopper having a computer with an internet browser installed thereon, said method comprising the steps of:

(a) sending code to the computer to add a shopping assistant button in the internet browser toolbar;

(b) creating a wallet for the shopper in a database of the server, the wallet secured by a first security key previously received from the shopper;

(c) receiving a second security key from the shopper;

(d) comparing the first and second security keys;

(e) and if the first and second security keys are the same, sending the wallet to a computer.

2. A method as recited by claim 1, further comprising the step of providing a supported merchant rules and mapping file for a supported merchant, wherein step (a) further comprises sending computer code to automatically fill out a check-out web page of a supported merchant web site using the wallet and the supported merchant rules and mapping file.

3. The method of claim 1, wherein the shopping assistant button comprises a drop down menu.

4. The method of claim 1, wherein the step (b) comprises:

transmitting web page information for display through an internet browser;

receiving shopper data entered by a shopper in a web page; and

at least a portion of the shopper data is stored in the database as a wallet.

5. The method of claim 1, wherein step (a) further comprises: computer code is sent to monitor internet navigation by the internet browser by obtaining an internet address for each internet site to which the internet browser is caused to navigate.

6. A method as recited by claim 5, further comprising the step of providing a supported merchant rules and mapping file for a supported merchant, wherein step (a) further comprises sending computer code to automatically fill out a check-out web page of a supported merchant web site using the wallet and the supported merchant rules and mapping file.

7. The method of claim 1, further comprising the step of providing a supported merchant rules and mapping file for a supported merchant, wherein step (a) further comprises sending computer code to determine if a merchant web site is a supported merchant web site.

8. The method of claim 7, wherein step (a) further comprises: a determination is made as to whether a merchant web site is a supported merchant web site by comparing the internet address of each internet site to which the internet browser is caused to navigate to the supported merchant data file.

9. The method of claim 7, wherein the computer code provides an indication of a shopping assistant button when an internet browser accesses a supported merchant web site.

10. The method of claim 1, wherein step (a) further comprises: sending computer code to acquire each webpage received by the browser, and determining the webpage type through HTML code and an http request header in the acquired webpage.

11. The method of claim 1, wherein step (e) comprises transmitting a secure cookie to the computer.

12. An internet browser interface displayable by an internet browser on a computer display, comprising:

a toolbar; and

a shopping assistant button in said toolbar defined by computer code operable with a computer processor for:

acquiring an internet address of each internet site to which the internet browser is caused to navigate;

determining whether a website to which the internet browser is caused to navigate is a supported merchant website; and

if the website is a supported merchant website, automatically filling out a checkout webpage of the supported merchant website using the wallet and supported merchant rules and mapping files.

13. An internet browser interface as recited by claim 12, wherein said determining step includes determining whether a web site to which the internet browser is caused to navigate is a supported merchant web site by comparing the internet address of each internet site to which the internet browser is caused to navigate to the supported merchant data file.

14. An internet browser interface as recited by claim 12, wherein said shopping assistant button includes a drop down menu.

15. An internet browser interface as recited by claim 12, wherein said computer code is further operable with the processor to add a toolbar and a shopping assistant button to said internet browser interface.

16. The internet browser interface of claim 12, wherein the shopping assistant button provides an indication when the internet browser is caused to navigate to a supported merchant web site.

17. An internet browser interface as recited by claim 12, wherein the computer code is further operable with the processor to retrieve each web page received by the browser and determine the web page type from HTML code and an http request header in the retrieved web page.

18. A system for facilitating online shopping by a shopper having a computer with an internet browser, said system comprising:

a server, comprising:

a data storage device containing a database; and

a processor operable with software to:

sending shopping assistant computer codes and adding a shopping assistant button for a toolbar of an Internet browser;

receiving wallet data, the wallet data including a first security key from a shopper, and creating a wallet for the shopper in a database, the wallet secured by the first security key;

receiving a second security key from the shopper;

comparing the first and second security keys;

and if the first and second security keys are the same, sending the wallet to a computer.

19. The system of claim 18, wherein the server is a secure server.

20. A system as recited by claim 18, wherein the processor is further operable with software to provide a supported merchant rules and mapping file when a shopper navigates an internet browser to a supported merchant web site, and the shopping assistant code can automatically fill out a check-out web page of a supported merchant web site using the wallet and the supported merchant rules and mapping file.

21. A method for facilitating online shopping by a shopper at a supported merchant web site, said shopper having a computer with an internet browser installed therein, said method comprising the steps of: sending computer code to add a shopping assistant button in the internet browser, wherein the computer code is capable of obtaining an internet address for each internet site to which the internet browser is caused to navigate, determining whether a website to which the internet browser is caused to navigate is a supported merchant website, and if the website is a supported merchant website, automatically filling out a check-out web page for the supported merchant website using a wallet and supported merchant rules and mapping files.

22. The method of claim 21, wherein said transmitting step further comprises transmitting computer code to add a shopping assistant button and a toolbar of the internet browser.

23. The method of claim 21, wherein the shopping assistant button further provides an indication when the internet browser is caused to navigate to a supported merchant web site.

24. The method of claim 21, wherein the computer code determines whether a web site to which the internet browser is caused to navigate is a supported merchant web site by comparing the internet address of each internet site to which the internet browser is caused to navigate to the supported merchant data file.

25. A method of dynamically controlling an internet browser interface displayable by a browser on a computer display, a file located in a computer data storage device and defining a shopping assistant interface object, said method comprising the steps of:

(a) when a user of a computer and a browser starts the browser, opening a file;

(b) establishing connection between the browser and a preset Internet site;

(c) receiving information defining all or part of shopping assistant interface objects from a preset Internet site into a file;

(d) displaying a shopping assistant interface object on a computer display along with an internet browser interface when the browser is started; and

(e) when the browser is started, the file is prevented from closing.

26. The method of claim 25, further comprising the steps of:

(f) periodically establishing connection between the browser and a preset Internet site; and

(g) additional information defining all or a portion of the shopping assistant interface object is received from a predetermined internet site into a file.

27. The method of claim 25, wherein step (e) further comprises executing a program loop to prevent file closure.

28. The method of claim 27, further comprising the step of terminating the program loop when the browser is no longer active.

29. The method of claim 25, wherein the step (b) comprises automatically establishing a connection between the browser and a preset internet site.

30. A method as recited by claim 25, wherein the file contains computer code for obtaining an internet address for each internet site to which the internet browser is caused to navigate, determining whether a website to which the internet browser is caused to navigate is a supported merchant website, and if the website is a supported merchant website, automatically filling out a check-out web page for the supported merchant website using the wallet and supported merchant rules and mapping file.

31. The method of claim 25, wherein the file contains computer code for adding a shopping assistant button and a toolbar of the internet browser.

32. The method of claim 25, wherein the file contains computer code for providing an indication when the internet browser is caused to navigate to a supported merchant web site.

33. A method as recited by claim 25, wherein the file contains computer code for determining whether a web site to which the internet browser is caused to navigate is a supported merchant web site by comparing the internet address of each internet site to which the internet browser is caused to navigate to the supported merchant data file.

34. A method for making an internet browser access a predetermined internet site, the method comprising the steps of:

(a) providing a file on the computer including definitions of shopping assistant interface objects and instructions for the internet browser; and

(b) after the computer user launches the internet browser, the internet browser is automatically caused to establish a connection with a predetermined internet site in response to the instructions in the file.

35. The method of claim 34, further comprising the step of receiving information defining all or a portion of the shopping assistant interface object from a predetermined internet site into a file.

36. A method as recited by claim 34, wherein the file contains computer code for obtaining an internet address for each internet site to which the internet browser is caused to navigate, and determining whether a website to which the internet browser is caused to navigate is a supported merchant website, and if the website is a supported merchant website, automatically filling out a check-out web page for the supported merchant website using the wallet information and supported merchant rules and mapping file.

37. The method of claim 34, wherein the file contains computer code for adding a shopping assistant button and a toolbar of the internet browser.

38. The method of claim 34, wherein the file contains computer code for providing an indication when the internet browser is caused to navigate to a supported merchant web site.

39. A method as recited by claim 34, wherein the file contains computer code for determining whether a web site to which the internet browser is caused to navigate is a supported merchant web site by comparing the internet address of each internet site to which the internet browser is caused to navigate to the supported merchant data file.

40. An internet browser interface displayable by an internet browser on a computer display, comprising an ActiveX control shopping assistant interface object displayed through the browser interface when the browser is started, which provides a link to a predetermined internet site, independently of the internet site to which the computer is connected through the browser.

41. The internet browser interface of claim 40, wherein the ActiveX control shopping assistant interface object causes an internet browser to establish a connection with a predetermined internet site.

42. An internet browser interface displayable by an internet browser on a computer display, comprising a plug-in shopping assistant interface object displayed through the browser interface when the browser is started, which provides a link with a predetermined internet site, independently of the internet site to which the computer is connected through the browser.

43. The internet browser interface of claim 42, wherein the plug-in shopping assistant interface object causes the internet browser to establish a connection with a predetermined internet site.

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

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

(b) such that files used to display user toolbar and shopping assistant interface objects that are part of the internet browser may be downloaded through a preset internet site.

45. The method of claim 44 wherein the file contains an ActiveX control.

46. The method of claim 44, wherein the file comprises a plug-in.

47. The method of claim 44, wherein the shopping assistant interface object is a toolbar button.

48. A method as recited by claim 44, wherein the file contains computer code for obtaining an Internet address for each Internet site to which the Internet browser is caused to navigate, determining whether a website to which the Internet browser is caused to navigate is a supported merchant website, and if the website is a supported merchant website, automatically filling out a check-out webpage for the supported merchant website using a wallet and supported merchant rules and mapping file.

49. The method of claim 44, wherein the file contains computer code for adding a shopping assistant button and a toolbar of the Internet browser.

50. A method as recited by claim 44, wherein the file contains computer code for providing an indication when the Internet browser is caused to navigate to a supported merchant web site.

51. A method as recited by claim 44, wherein the file contains computer code for determining whether a web site to which the Internet browser is caused to navigate is a supported merchant web site by comparing the Internet address of each Internet site to which the Internet browser is caused to navigate to the supported merchant data file.

52. A system for controlling an internet browser interface displayable by an internet browser on a computer display, the system comprising:

a server including a program accessible to a computer user via the Internet for controlling the Internet browser interface; and

a file downloadable to a computer by the server for controlling the internet browser interface, wherein the downloadable file, when the internet browser is launched, causes a user toolbar and a shopping assistant interface object to be added to the browser interface and displayed on the computer display as part of the browser interface, regardless of the internet site to which the computer is connected via the internet browser.

53. The system of claim 52, wherein the shopping assistant interface object contains an ActiveX control.

54. The system of claim 52, wherein the shopping assistant interface object comprises a plug-in.

55. A system as recited by claim 52, wherein the file contains computer code for obtaining an Internet address for each Internet site to which the Internet browser is caused to navigate, determining whether a website to which the Internet browser is caused to navigate is a supported merchant website, and if the website is a supported merchant website, automatically filling out a check-out webpage for the supported merchant website using a wallet and supported merchant rules and mapping file.

56. The system of claim 52, wherein the file contains computer code for adding a shopping assistant button and a toolbar of the internet browser.

57. A system as recited by claim 52, wherein said file contains computer code for providing an indication when the Internet browser is caused to navigate to a supported merchant web site.

58. A system as recited by claim 52, wherein said file contains computer code for determining whether a web site to which the Internet browser is caused to navigate is a supported merchant web site by comparing the Internet address of each Internet site to which the Internet browser is caused to navigate to the supported merchant data file.