Apparatus and method for automated aggregation and delivery of electronic personal information or data

ES 2 200 753 T3

DESCRIPTION

Apparatus and method for automated aggregation and provision of transactions involving personal electronic information or data.

Background of the invention

1. Field of the invention

The invention relates to an apparatus and process for automated aggregation and delivery of electronic personal information (IP) or data. The invention also relates to the automation of transactions involving electronic personal information (IP).

two. Description of Related Art

Looking back over the past five years, it is clear that as the Internet gained momentum, consumers were demanding applications or services that would make their online experience easier, easier to use, and more satisfying. The development of successful Internet Sites has corresponded with numerous themes that have been developed in the last few years. When carefully analyzed, this evolution is a logical development of the emerging digital economy.

Before 1994, the Internet was not a mass medium, in part, because existing technologies (FTP, Archie, Usenet, and Gopher) were not user-friendly and required the end user to do all the work (for example, the end user had to learn from an existing data source, look up the address, navigate to the destination, and download the information). As more users began to access the Internet, Search Engines were created to solve this utilization problem. With the advent of the commercial Search Engine, additional content could easily be added to the Internet and the end user had a means of finding and accessing this information. Consumers required better tools than Search Engines to organize and access this wealth of generic content. Push technologies were explored and eventually the portal strategy was successfully adopted as an efficient means for users to easily access a variety of content sources in a single, easy-to-use format. As the volume of content available online continues to grow exponentially, portals are now faced with the need to make different types of content available to different consumers based on their particular preferences and tastes.

The phenomenal success of Internet portals and destination sites has demonstrated the importance of creatively and intelligently aggregating, organizing, and presenting the mass of information available on the Web. Search engines, portals, and landing sites have Internet strategies based on the frequency, duration, and quality of end-user visits to their sites. For this reason, destination sites and portals are constantly looking for content and / or technologies that will drive quality traffic to their sites and keep it there. Recent trends indicate that Internet users are up to 25 times more likely to return to a site when this information is organized according to personal preferences.

Figure 1 presents the current process of acquiring 100 personal information (IP) online. The end user first selects an information provider site in step 110. The end user proceeds to step 120 by locating and entering the Internet address of the selected information provider. This stage can be carried out in various ways with varying levels of complexity. A simple means of accomplishing this step is to use a bookmark or bookmark, while locating an information provider for the first time could take significant time and effort when searching online. In step 130, end users enter the website of the selected information provider using the site-specific login protocol. This protocol usually involves verifying the identity of the end user using a username and password or other means of verification, acquiring verification data from "cookies" that reside on the end user's system, or a combination of requested data and data. of "cookies" (data files that are stored on the hard drive of the user's computer so that the user has access to the exclusive services of the system). In step 140, the end user continues browsing Web pages of the information provider's Web site until the desired information is located. During this process, the end user is often asked to visit Web pages of little or no use to the end user, the aim of which is simply to acquire the particular personal information (IP) residing on the Web site. Finally, in step 150, the end user is presented with the desired IP. The entire process 100 is repeated for each individual piece of IP desired by the end user. Under this IP access model, the end user must visit each separate information provider, potentially track different identity verification data for each, use a different user interface on each site, and possibly fight their way through a significant number. of filler web pages.

Figure 4 graphically illustrates the architecture of this current access process. End user 210 uses customer computer 220 to access each IP website 250 over the Internet 230. This current model suffers from several significant shortcomings. The end user must enter each site separately. Each separate site has its own graphical user interface (GUI). Every site wants the end user to stay and come back; each visited site wants to retain the end user's attention as long as possible. There is no true IP aggregation; multiple access simply allows sequential access to particular pieces of IP.

A partial solution to these problems has recently evolved in the form of portal sites. Generic portal sites aggregate resources into categories and provide links to sites that cover topics within those categories. Yahoo and Excite are examples of generic portal sites. These sites facilitate horizontal aggregation of generic content; Horizontal aggregation refers to the aggregation of IP access within a particular category of information provider such as banks and utility companies. Some portal sites allow an individual end user a limited ability to select and configure disparate generic IPs. Generic IP refers to personal information of interest to the particular end user that does not need to obtain specific identity verification. For example, an end user might be interested in the weather forecast for their local area. This infor2

ES 2 200 753 T3 mation could be integrated into a portal page that does not require identity verification of the particular end user who receives this IP. The individualized portal page provides a significant advantage to users looking to add generic IP. However, current portal pages generally do not provide IP that requires identity verification such as a portfolio or an end-user bank balance. Also, these pages do not facilitate transactions that use IP.

In today's technology, adding available IP over the Internet requires a significant burden in terms of time, effort, and learning curve. An end user who wants to access their IP needs to individually visit a variety of information provider sites, each with their own requirements, graphical user interface, and input protocol.

Summary of the invention

In the present invention, a computer connected to the network is used to facilitate the end user access, manipulation and transactions involving electronic IP associated with the particular end user, such as a portfolio of securities, local weather, sports scores, balances. of bank accounts or other pertinent information or data. According to the present invention, the IP related to the particular end user is added to the computer connected to the network. This information or data is supplied to the end user in a unified manner through a variety of selectable delivery platforms, such as fax, client computer, telephone, conventional mail, email, pager, other wireless device, Web page or channel or other supply vehicle. The present invention also facilitates a variety of electronic transactions involving IP, such as trading securities, small-scale purchases, paying bills, transferring funds from bank accounts, or other transactions.

A system for supplying personal information according to the present invention includes a user repository that includes end-user data, a provider repository that includes information provider data, a personal information repository that includes personal information, and a processor that communicates with these data repositories. The processor supports the aggregation of personal information. The processor selects an end user for aggregation of personal information. Once the end user is selected, the processor connects with one or more information providers. The processor then proceeds to collect personal information for the selected end user, from the connected information providers. This collection is based on end user data associated with the selected end user and vendor data associated with connected information providers. The collected personal information is stored in the personal information repository.

In one aspect of the present invention, the networked computer, alternatively referred to as the host computer, is used to distribute, store, and collect electronic information associated with the particular end user. In a particular embodiment, the information is personal information such as a stock portfolio, local weather, sports scores, bank account balances or other pertinent information or data. According to this aspect, the IP related to the particular end user is added to the central computer. The central computer transmits the added data to a client computer associated with the particular end user for whom the IP was added. Preferably, the aggregated data is transmitted to the customer's computer as "cookie" data and is stored as such by the customer's computer. In some embodiments, the aggregated data is encoded prior to transmission. The central computer receives a request concerning the aggregated data. The source of the request is preferably the client computer; however, other sources of suitable devices are contemplated within the scope of the present invention. The central computer receives the aggregated data from the customer's computer, preferably as "cookie" data. If scrambled, the aggregated data is decoded. The central computer proceeds to service the request to generate a request result. The result of the request can be delivered to a variety of platforms, preferably a web page. Alternatively, the result could be delivered to a telephone, email destination, facsimile, or other printing device, directly to a web browser, third-party computer, wireless device, or other suitable delivery platform.

In another embodiment of this aspect, there may be specialized programming on the customer's computer, whereby requests related to the aggregated data transmitted by the central computer can be served on the customer's computer. Such specialized programming would include some decoding program if appropriate.

In another aspect of the present invention, electronic information from potentially disparate sources is dynamically combined with determined style preferences from potentially disparate sources to generate a compliant electronic document. In one embodiment of this aspect, the electronic IP associated with the particular end user, such as a portfolio of stocks, local weather, sports scores, bank account balances or other pertinent information or data, is combined with the content of the distributor and provider to produce the content for the generated document. Stylistic information is accumulated from end-user preferences and from distributor and vendor style information. A compliant document is generated by applying the combined style information to the combined content. This generated document can be delivered to the end user in a unified manner through a variety of selectable delivery platforms, such as fax, client computer, wireless device, personal organizer, telephone, pager, web page or channel, or other delivery vehicle. .

A system for dynamically generating compliant electronic documents according to this aspect of the present invention includes a style merger unit, a content merger unit, and a processor, which may be included in the network computer of the present invention. The style merge unit accumulates style information from one or more style providers and dynamically merges the accumulated style information. The content merger unit accumulates content information from one or more content providers

ES 2 200 753 T3 and dynamically merges the accumulated content information. The processor receives the merged content and style information and generates a compliant electronic document by dynamically applying the received style information to the received content information. The generated page can be delivered to a variety of delivery platforms.

In another aspect, a central computer schedules the collection of information associated with one or more end users from one or more information providers hourly. The central computer is in communication with a user data repository for storing data associated with users, and with an information provider repository for storing data associated with information providers, and includes a processor.

For each end user, a profile of past times of access and entry to the system is maintained in the user data warehouse. For each information provider, a profile of update times and criteria are maintained in the information provider repository. Update times and criteria can be stored with respect to all information provided by each information provider, or update times and criteria can be stored with respect to each piece of information provided by each information provider.

For a selected information provider, the host computer processor determines an update time for the information stored by the selected information provider and a group of end users whose information could be modified by updating at that update time. The host computer processor generates a predicted login time for each end user of the given group of end users and each generated login time, delayed by a predetermined time interval. The central computer processor classifies the given group of end users according to the expected time of entry to the system or the time of entry to the system, and assigns a collection time for each end user based on each time of entry to the system, moved or intended, of the end user. In one embodiment of this aspect, the central computer processor can also collect the information for each end user of the determined group of end users from the selected information provider, at the collection time allocated to each end user.

In another embodiment of this aspect, the central computer processor determines the group of end users whose information could be modified by an update at the determined update time, first selecting end users configured to receive information from the selected information provider, and deleting the End users not configured to receive updated information within the specified update time. The central computer processor can also remove end users from the group, who do not meet the update criteria or update conditions associated with the information provider or the information subject to update in the determined update time.

The host computer processor can generate a predicted logon time for each end user in the determined group based on logon time profiles stored in the user repository. For each end user in the given group, a determination is made as to whether the end user's login time profile meets a predetermined confidence threshold. If the profile meets this threshold, an expected logon time is assigned based on the profile. If the profile does not meet this threshold, an expected logon time is assigned corresponding to the present day and time.

The central computer processor allocates a collection time for each end user, based on their expected input time. In one embodiment of this aspect, the collection time assigned to each end user corresponds to their expected time generated, on entry to the system, delayed by a predetermined interval of time.

In another embodiment of this aspect, the host computer processor allocates pickup times for each end user based not only on their expected logon time, but also on expected network activity. The central computer processor first performs an adapted distribution in time, to generate a polynomial function that allows the determination of the number of end users subjected to collection during a specified period of time. It then determines a curve of network activity, of the network activity associated with it and with the selected information provider. An inverse of the curve of the determined network activity is generated. Then it performs an integral adaptation algorithm using the generated polynomial function and the generated inverse of the network activity curve. Finally, it allocates collection times for each end user in order to redistribute the maximum collection times towards zero time to flatten the tailored distribution, over time.

In another aspect of the present invention, electronic actions involving personal information (IP) associated with an end user are automatically performed for the end user. An end user will have a variety of electronic IP associated with him, such as portfolios, local weather, sports scores, bank account balances, or other pertinent information or data. In one embodiment of this aspect, an end user repository contains end user data associated with an end user, and annotations that correlate trigger events to responses associated with the end user. Annotations associated with the end user are accessed by a central computer processor. For each annotation accessed, the host computer determines whether the annotation triggering event has occurred and, if so, executes the response correlated to the triggering event that is determined to occur.

The execution of the response may involve the provision of a notification of the presence of the triggering event to a specified delivery platform, such as a wireless device, a facsimile, a telephone, a printing device, a pager, a web page resident in a web server, email system, or other suitable delivery vehicle. Instead of, or in addition to, such notification, the central computer may automatically execute a transaction involving the personal information associated with the end user.

In another embodiment of this aspect, the execution

The automated ES 2 200 753 T3 of said transaction involves the central computer accessing the entries associated with an information provider based on the response indicated in the end user accessed entry in which the triggering event was determined to occur. The central computer connects to an information provider computer indicated by the accessed data associated with the information provider. The central computer then executes a transaction script on the connected information provider's computer, based on the accessed data associated with the information provider, on the response indicated in the accessed end-user entry in which the access was determined to occur. trigger event, and in the end user data of the end user repository.

In another aspect of the present invention, a central computer monitors interactions between end users and providers of personal information through an intermediary computer. Interactions will generally be divided into two categories: requests for the provision of personal information and requests for transactions involving personal information. The central computer communicates with a personal information repository to store personal information associated with end users, and with an account repository to store accounting data associated with the intermediary computer. The central computer includes a processor.

The central computer processor receives from the proxy computer requests concerning personal information associated with an end user and serves the request based on personal information associated with the end user in the personal information repository. The host computer processor updates the accounting data associated with the proxy computer. The central computer processor can update the accounting data in various ways. First, the host computer processor can increment a user account for each new user of the proxy computer for a selected period of time. The host computer processor can then count the interactions made through the intermediary computer. Third, the host computer processor, where the service request is a request to effect a transaction, can increase a commission of a total amount based on the request serviced. Finally, the host computer processor can use any combination of these ways to update the accounting data associated with the proxy computer.

The central computer processor generates invoices for the intermediary computer based on the updated accounting data. The central computer processor can generate such invoices on a periodic basis. In another embodiment of this aspect, the central computer processor can deliver the generated invoices to a selected destination such as an email destination, a printer device, a web page residing on a web server, an Internet client, a telephone, and a facsimile.

In still another embodiment of this aspect, the proxy computer has an account associated with it. The central computer processor can charge this account before generating an invoice so that the generated invoice reflects only the additional income that exceeds the amount indicated by the intermediary computer account. The amount charged may be based on updated accounting data associated with the intermediary computer, using any of the aforementioned update types.

Another aspect of the present invention is a system and method for automated access to personal information associated with an end user, wherein the personal information is stored at a personal information provider. A representation of the personal information, and a link corresponding to the personal information stored in the personal information, is presented to the end user through a client computer. Upon activation of the link, the client's computer is automatically taken to the personal information provider which presents the user with a page of the personal information provider through the client's computer.

In one embodiment of this aspect, an application is downloaded to the client. The downloaded application initiates a connection between the customer's computer and the personal information provider. The application navigates the pages of the personal information provider until it reaches the personal information. Finally, the application presents the personal information to the user on the client's computer. The application can be generated either with all the necessary data associated with the end user and associated with personal information, or such data can be transmitted to the application. The data associated with the personal information provider may include a navigation script to guide the application to the personal information. The data associated with the end user can include all the data necessary to perform navigation through the navigation script.

In another embodiment of this aspect, a message is transmitted to the client's computer that includes all the necessary data of the user and the personal information provider, which causes the client's computer to automatically enter the end user in the personal information provider, leaving , therefore, to the end user on a mail entry page. In a preferred embodiment of this aspect, the message comprises a page containing a form that includes login information which, when opened by programming on the customer's computer, redirects the customer's computer to a mail login page.

In yet another embodiment of this aspect, the client's computer is driven to personal information by connecting to the personal information provider, navigating to the personal information provider's personal information, presenting the personal information to the end user through the client's computer and empowering subsequent interactions between the client's computer and the personal information provider for a given session with the personal information provider.

The foregoing and other objects and advantages of the present invention will become more readily apparent when reference is made to the following description, taken in conjunction with the accompanying drawings.

Brief description of the drawings

Figure 1 is a flow diagram of the current process carried out by the end user to access IP available on the Internet.

Figure 2 is a block diagram of the com5

ES 2 200 753 T3 speakers that could be used to implement the present invention.

Figure 3 is a block diagram of the components of the IP machine.

Figure 4 is a diagram of the current IP access architecture.

Figure 5 is a diagram of an architecture that supports IP access using an intermediary website.

Figure 6 is a diagram of the associated "cookie" / client architecture.

Figure 7 is a flow chart for accessing pages that support the particular IP, through the traditional process of Figure 1 and through springboard technology.

Figure 8 represents the integration model for the dynamic generation of HTML pages (Hypertext Markup Language = Hypertext Markup Language).

Figure 9 presents the execution process in time for dynamic generation of HTML pages.

Figure 10 illustrates a process for automated app interaction using a modified Java virtual machine.

Figure 11 is a flow chart exemplifying an intermediary website transaction structure.

Detailed description of the invention

A preferred embodiment of the invention is now described in detail. With reference to the drawings, like numbers indicate like parts throughout. As used in this description and in all of the claims that follow, the meaning of "one" and "the" includes plural reference unless the context clearly indicates otherwise. Also, as used in this description and in all the claims that follow, the meaning of "in" includes "in" and "about" unless the context clearly indicates otherwise.

In no time, end users will have to enter a large number of different Websites, each with different passwords, security, rules, programming, and “look and feel”, to obtain the information currently obtained by browsing one site: the mailbox. mail at the end of the road. The Internet will fundamentally change the way the end user accesses Personal Information (IP) and will make electronic commerce as familiar as using an ATM (Asynchoronous Transfer Mode = asynchronous transfer mode). "Personal Information" is all the data that companies, information providers have, that are specific or unique for each person, such as monthly invoices, bank account balances, investment information, health care subsidy, email, voice messages and fax, 401 (k) companies, or potentially any other information relevant to an end user.

The present invention reduces some of the problems of current IP acquisition methods by automatically adding IP; not only generic IP such as the one added by portals, but also specific IP for the end user that requires identity verification for access. In one embodiment, the invention automates the IP acquisition and delivery process.

Figure 2 provides a block diagram of components that could be used to implement the present invention. The end user 210 accesses a client computer 220 running the client program 270 which, in a particular embodiment, could be a general web browser such as a Browser or Communicator (Netscape). The customer's computer 220 uses the Internet 230 network to access an IP machine 240 acting on an IP host 290. The IP machine 240 examines the stored IP 280 to refresh it. All outdated IP elements are refreshed by directly reacquiring the IP of the particular information provider's website 250, which acts on the provider's computer system 260 accessed via the internet 230. The IP machine 240 stores the fresh IP in its repository 280 and supplies the IP to a selected destination, in this case over the Internet 230, to the customer's computer 220 which presents the information to the end user 210 using the customer's program 270 . The IP machine 240 refreshes all the outdated IP in the same way before sending the added IP, both to the warehouse 280 and to the delivery destination, in this case the customer's computer 220. The IP machine 240 can refresh the IP sequentially or in parallel. For example, the end user's checking account balance could be updated through your bank website, your email from your home email site, your portfolio information from your broker site, and your electric bill from your electric company site.

Figure 3 presents a block diagram of the components of the IP machine 240. The IP machine 240 is comprised of both storage and process components. The three primary storage components are IP pool 280, IP provider pool 310, and user pool 360. The first storage component of the IP machine 240 is the IP bucket 280. IP repository 280 contains each individual IP entry 375; the IP associated with a particular end user is segregated from the IP of all other end users. The IP engine also uses a provider repository 310 that contains general parameters associated with particular IP providers. The general parameters of an IP provider define the types of verification data required and the procedures to be followed to access the particular IP provider. Each IP provider entry also contains the IP types provided by the IP provider and the transaction types supported by the provider. Along with the type of IP or transaction, the annotation also contains the additional types of data and procedures required to access the IP or execute the transaction. A 360 user repository is also required to maintain configuration and verification information concerning particular end users. For each end user, the IP providers selected by the user, the IP and the transactions are recorded along with the verification data necessary to acquire the IP or execute the transaction from the IP provider.

The IP repository 280 can be implemented in a number of ways. Referring to Figure 2, the IP repository 280 may comprise a database resident on the IP Central Computer 290. In this proposal, the IP for each individual end user 210 is stored in the database as an annotation

ES 2 200 753 T3 or separate object 375. In yet another embodiment, the IP for each end user 210 could be stored in a separate file 375, thus performing the task of segregating the IP of different users at the file level.

Additionally, or alternatively, the IP associated with each end user 210 may reside on their client computer 220 using "cookie" technology, as specified in D. Kristol and L. Montulli's document, "HTTP State Management Mechanism" , Request For Comments (RFC) 2109, February 1997 (available at http://www.ietf.org/rfc/ rfc2109.txt). The IP associated with end user 210 would be stored as IP 375 "cookies". This implementation mechanism provides inherent help in segregating the IP 375 associated with one end user from the IP associated with all other end users. Using this method as a substitute for a centralized repository, a layer of security against unauthorized access is provided. As another measure, the IP data stored in "cookies" could be stored in an encrypted format.

Figure 6 provides a diagram of a typical implementation of IP repository 280 using "cookie" technology; Reference is also made in the foregoing description to Figure 3, with respect to the internals of the IP machine 240. When an attempt is made by an end user 210 to access IP directly, or through an intermediary web server, the IP access / transaction component 340 from IP machine 240 would collect stored IP 375 from bucket 280 of IP. In this proposal, this stored IP 375 would be received directly from "cookies" sent by end user client computer 220 210. The IP access / transaction component 340 would perform any decoding if necessary. Any necessary updates would be obtained through direct access from the IP providers 250. The IP provisioning component 350 would provide the mechanism, both to update the IP repository 280, as well as to transmit the requested IP to the end user 210, directly or through an intermediary website. The IP delivery component 350 would place the updated IP in the IP repository 280, replacing the outdated IP "cookies" 375 stored in the customer's computer 220. The IP delivery component 350 would also perform any encryption if necessary. The IP provisioning component 350 would also be responsible for transmitting the requested IP. In a preferred embodiment, IP repository 280 would be implemented using this "cookie" based architecture.

User repository 360 can be implemented in several ways. Referring to Figure 2, user repository 360 may comprise a database resident on IP Central Computer 290. In this proposal, personal configuration data for each individual end user 210 is stored in the database as separate objects or annotations. In addition, or alternatively, the end user data could be distributed in a manner similar to the "cookie" / partner architecture described above with respect to the IP repository 280.

In a preferred embodiment, user repository 360 could be implemented by personal information configuration (PIC) files. PIC files (PIC = Personal Information Configuration = personal information configuration) store a personal profile such as name, address and social security number, in a secure and encrypted way for each end user. PIC files facilitate the automatic registration of end users with Information Providers through the end user configuration component 330. This component will read the PIC file and, using collected personal information, pre-arrange registration templates for selected Suppliers. Then it will instruct the user to enter the required information missing from the profile, if necessary. If the information is complete, the registration is completed automatically. The end-user configuration component 330 then completes any Provider registration form, gets responses, and updates the end-user PIC file.

The four primary process components access and manipulate the data in the three repositories. The process components can run on a single processor, such as a file server computer system based on a Pentium-type central processing unit (MMX, PRO, II, III, etc.) or an equivalent, or on multiple processors. These four process components are: the Baseline configuration component 320, the end-user configuration component 330, the IP access / transaction component 340, and the IP provisioning component 350, as seen in the Figure 3. The Baseline configuration component 320 provides the interface by which new user-selectable IP providers are added to the system. This component 320 could be implemented in various ways, including successive trial runs followed by manual entry of configuration information, semi-automated successive trial and error (automated location of Hypertext Markup Language <FORM> elements, Java script functions and apply Java), followed by manual entry of configuration information or, preferably, configuration by example (running the protocol on a simulated web client, where the simulated web client automatically generates a list of required data and a list of steps in the access process). These processes would be used at two levels: the first level being the set of data and stages necessary for general access to the particular IP provider, and the second level being the set of data and additional stages necessary to access each particular piece of IP. from the IP provider's site. The Baseline configuration component 320 may be activated independently when a new IP provider is added to the system, or it could be activated as a result of a failure of the IP / transaction access component 340 potentially indicating a change in requirements. access for failed access. This last example could be more likely where the IP / transaction access component 340 has made a comparison between requirements supplied by the provider repository 310, both general for the IP Provider and specific for the IP or transaction, and the data of the end user supplied by the 360 ​​user repository, after seeking end-user verification by end-user request to confirm required access data previously entered through end-user configuration component 330 and find a contradiction.

ES 2 200 753 T3

When a contradiction is determined, the update of the provider repository 320 is performed to bring the Provider data in accordance with the current access / transaction requirements.

The end user configuration component 330 allows an end user to select and configure IPs and transactions of interest to the specific user. This configuration information is kept in the 360 ​​user repository. When an end user initially subscribes to the system according to the present invention, the system allows the user to select desired IP types and sources and / or transactions. First, the system asks the end user for permission to act on their behalf in order to obtain any selected IP and to execute any authorized transaction. The system then provides the user with a list of known information providers and the supplied IP types and transactions supported by the particular IP provider, from the provider repository 320. The system requests the verification data necessary to access each selected IP provider and the additional data required by the particular IPs and / or desired transactions of that IP provider. Assuming that the end user is already a registered user at the selected IP provider, or that the particular IP provider does not require prior registration, the data supplied by the end user is placed in the user repository 360.

One method of obtaining any "cookie" data would be for the end user to access each previously accessed IP using the IP machine 240 as a proxy server. The IP machine 240 would pass the "cookie" data to the IP provider's site with the appropriate Web page request to obtain the IP or execute the transaction and, with the permission of the end user, retain a copy of the " cookie ”from your entry in the 360 ​​user repository. An alternative means of obtaining the "cookie" data would be a direct upload of the "cookie" information from the end user's computer. In a preferred embodiment, no "cookie" data is necessary where a user is already registered with a provider. All that is needed is the verification data to enter the system.

If the end user does not have the necessary information because he is not a registered user of a selected IP provider, the User Configuration component 330 prompts the user for the information necessary to register the end user with the IP provider and performs the procedure of registration required by the IP provider. A simulated web client could automatically carry out this process by supplying the required login details and submitting any necessary "cookie" data. The way in which such a simulated client registers the end user depends significantly on the interaction method used on the IP provider's website. If the website uses HTML forms and Common Gateway Interface applications (CGI = Common Gateway Interface), the end user configuration component 330 can formulate a Uniform Resource Locator (URL = Uniform Resource Locator) to reproduce the usage effect form and present this URL to the simulated web client. Using a URL to mimic an HTML form is equivalent to manually entering data in the <FORM> Web element. See Kerven, Foust, Zakour, HTML 3.2 Plus

How-To, Waite Group Press, 1997, pages 559-569. If the website uses a mixture of HTML forms and Java script functions, a simulated Web client with a modified Java script interpreter could effectively register the user by following the end-user registration process for the particular IP provider. The registration process to follow would be obtained from the entry of the particular IP provider in the provider repository 320. The simulated web client Java script interpreter would follow this procedure and supply the data supplied by the end user. A similar procedure could be used if the registration process on the IP provider's website uses a Java applet. A Web client with a modified Java byte code interpreter could effectively register the user by following the end user registration process stored for the particular IP provider in provider repository 320. The octet code interpreter would supply the data previously entered by the end user instead of requiring interactive input from the end user. If the IP provider's website uses a combination of forms, scripts, and applets, the individual procedures above could be used in combination to achieve the desired registration.

With reference to Figure 2 and Figure 3, a modification of the Java virtual machine (VM) could allow automated interaction between the various functional components of the IP machine 240 and the Java applet available through Web servers 250 of supplier. Templates for interacting with particular appliques could reside in vendor repository 310. Specific input data used by such templates could be stored in user repository 360. When a functional component, such as end user configuration component 330 or access / transaction component 340, requires automated communication with a Java applet on a provider Web server 250, the modified Java VM would facilitate this interaction.

Figure 10 illustrates a process that uses such a modified Java VM to achieve such automated interaction. The functional component requiring interaction identifies in step 1010 the particular vendor and applier at that vendor with which the component needs to interact. At step 1020, the component accesses the template necessary to interact with the vendor repository 310 applique. Going to step 1030, the component accesses the user repository 360 to obtain the data required by the template. The modified Java VM interprets the applet at step 1040 and, instead of requiring interactive input from a user as in normal Java applet execution, waits for input or output from or to the interactive functional component of the IP machine. . In step 1050, the functional component supplies input data to the modified Java VM according to the accessed template and collected data, and receives output data according to the accessed template. Steps 1040 and 1050 repeat as long as additional input or output to or from the fixture continues. Upon completion of the appliqué, the functional component continues with its own process in step 1060.

A successful registration could lead to filing

ES 2 200 753 T3 the registration information to the end user for future reference. In addition, the end user configuration component 330 stores in the user repository 360 the access verification data necessary for the IP provider and the additional data necessary to access the selected IP or transaction.

In a preferred embodiment of such automated registration, any necessary "cookie" data would be accepted and stored as necessary by the end user configuration component 330. In many cases, "cookie" data is session specific and therefore of little use in the long term. The “cookies” generated during the registration process are used only during the registration process and are discarded after the registration is completed.

A failed registration could result from various situations. First, the end user who tries to register with the IP provider is not qualified for registration; for example, an end user trying to register with a bank with which the end user does not maintain an account and where the bank only allows access to account holders. Afterwards, the end user may have supplied improper or incorrect information. For example, a bank registration process might require a social security number, password, bank account number, and the maiden name of the end user's mother; If the user entered an incorrect social security number, the registration process will be suspended. Finally, the IP provider may have altered the registration procedure for their website. In this situation, following the process supplied from the supplier repository 320, a failed registration would occur. In the event of any registration failure, the end user could come forward with the data initially supplied to the system for registration. The system could then ask the end user to double check the accuracy of the information provided and to correct and resubmit the data if any errors were found. A second failure resulting from the presentation of necessarily identical data could generate an error message presented to the end user, stating that either the end user is not able to access the selected IP of the selected IP provider, or that the alteration by Part of the IP provider may have caused the registration to fail. This second failure could also cause a warning suggesting the need to potentially reconfigure the annotation for the IP provider in provider pool 320.

Finally, the user repository 360 could contain an entry for each end user. As described above, this entry could be a database entry, one or more "cookies", or a file such as a personal information configuration (PIC) file. Each entry would identify the selected IP providers along with the necessary general access verification data and also under each IP provider there would be a list of supplied IPs and transactions supported by the particular IP provider of interest to the end user, along with the additional data, if any, necessary to access that IP or execute that transaction. Specifically, duplicate information, such as an end user name, would be centrally stored in the annotation once.

The end user configuration component 330 also allows the end user to select one or more delivery destinations. A destination could be the end user's computer, as exemplified by client computer 220 running client program 270 of Figure 2; however, a computer is not the only destination contemplated by the present invention. The destination for the IP delivery could include, fax, email, telephone, conventional mail, pager, other wireless device such as a "Palm Pilot (3 Com)", web page or channel, web browser or other delivery mechanism. The present invention also contemplates indirect access to IP by the user using a website as an intermediary; however, such indirect access would not require the end user to specify a delivery destination unless additional delivery options were desired.

In addition, access to the end-user configuration component 330 may occur via direct access to the IP machine over the Internet, as viewed by the client computer 220 running the client program 270 of Figure 2; however, alternative access methods are equally feasible. For example, the user could indirectly access the IP machine through the use of an intermediary website. Another alternative is a telephone interface to allow access to the end user configuration component.

Referring to Figure 3, the IP access / transaction component 340 supports the update, acquisition and transaction functions of the IP machine 240. The IP access / transaction component 340 is responsible for accessing and storing the user's IP and executing end-user authorized transactions. When access or update is needed for a selected end user, IP access / transaction component 340 combines information from provider repository 320 and user repository 360 to update the end user's IP in IP repository 280. For each piece of IP that needs access or update, the IP access / transaction component 340 looks up the access procedure and necessary information for the particular IP in the provider repository 320. The verification and access data are in the 360 ​​user repository. The IP access / transaction component 340 uses this information to connect to the IP provider's website over the Internet and access the IP. Where multiple pieces of IP need updating or access, the accesses can occur in series or in parallel.

The requested transactions would be similarly supported. For each transaction, the IP access / transaction component 340 combines information from the provider repository 320 and the user repository 360 to perform the requested transaction. The IP access / transaction component 340 searches the provider repository 320 for the transaction procedure and information necessary for the particular transaction. The verification and access data are in the 360 ​​user repository. The IP access / transaction component 340 uses this information to carry out the transaction over the Internet from the IP provider's website.

A simulated web client could automatically execute the access or transaction processes supplying access and verification data when required.

ES 2 200 753 T3 required. How such a simulated client accesses IP or executes transactions is significantly dependent on the interaction method used on the IP provider's website. If the website uses HTML forms applications and common gate interface (CGI), the IP / transaction access component 340 can formulate a uniform resource locator (URL) to reproduce the effect of actual form usage and present this URL to the simulated web client. Using a URL to mimic an HTML form is equivalent to manually entering data in the <FORM> Web element. See Kerven, Foust, Zakour, HTML 3.2 Plus How-To, Waite Group Press, 1997, pages 559-569. If the website uses a mix of HTML forms and Java script functions, a simulated web client with a modified Java script interpreter could effectively access the IP or perform the transaction by following the IP / transaction access process for the particular IP or transaction, respectively. The access or transaction process to be followed would be obtained from the annotation of the particular IP or transaction in the supplier deposit 320. The simulated web client Java script interpreter would follow this procedure and supply the data found in the user repository 360. A similar procedure could be used if the IP provider's website uses a Java applet. A Web client with a modified Java octet code interpreter could effectively access the IP or carry out transactions following the stored process for the particular IP or transaction in the provider repository 320. The octet code interpreter would supply the data from the user repository 360 instead of requiring interactive input from the end user. If the IP provider's website uses a combination of forms, scripts, and applets, the individual procedures above could be used in combination to achieve the desired registration.

In a preferred embodiment of such automated access or transaction, any necessary "cookie" data would be accepted and stored as necessary by the IP access / transaction component 340. In many cases, "cookie" data is session specific and therefore of little use in the long term. The generated “cookies” are used only during these functions and are discarded after the extraction or transaction is completed.

To quickly provide personal information to an end user after logging into the system, it is necessary for the IP access / transaction component 340 to select an end user to collect data prior to the end user input. One proposal to this solution is to update the entire IP of an end user each time the end user, directly or through an intermediary website, requests access to his IP. Another proposal would be to update all the IP of an end user supplied by a particular provider each time IP is requested from that provider. Thus, the act of logging into the system by an end user effectively selects that end user to immediately update the IP. However, this approach could result in inefficient use of the resources of the IP machine 240.

Given the large number of potential users and providers, and the goal of providing the freshest data possible, another embodiment includes an algorithm developed to optimize the schedule in which end users are selected to collect data from a provider. This algorithm includes as factors the provider's update policy, the user's login habits, and the characteristics of the user-provider account. Proper application of the algorithm would ensure that IP is collected as infrequently as possible for a given user, thus minimizing consumption of system resources.

If the next vendor update time and the next expected user input can be accurately predicted, a model can be created that enables smarter collection. Rather than collecting data for all users of a provider at once when the provider updates its site, the collection can be extended over a period of time based on expected user login times and network activity profiles. For example, if Provider A updates its site on Friday evening and it is expected that a large number of users from that provider will not log back into the system until Monday morning, the collection load can be spread across over several days. This has the advantage of minimizing, at the same time, the maximum load on the IP machine 240, as well as the consumption of the provider's bandwidth by the IP machine 240. To achieve this optimization, the IP machine 240 must maintain and debug models for each provider and each user. Such data can be kept in provider repository 3 10 and user repository 360, respectively.

Each time a user uses the IP machine 240, the time and date can be captured. Once a sufficient number of logon hours have been accumulated, they can be analyzed against the day of the month, the day of the week, and the time of day. These are used in a model to predict the next expected input from a user. The model is then tested and refined with subsequent inputs until a measurable degree of confidence is established. Once a high confidence has been determined, the user model is incorporated into the collection adaptation schedule. Until a high level of trust is reached for a particular end user, one of the above-mentioned collection approaches can be used.

Each provider updates their site based on policy governed by their unique business and resource model. For any work adjustment schedule scheduler, the policy for each provider must conform to a model. In some cases, the policy is self-evident. In others, it must be determined empirically. Most likely, a provider's policy falls into one of the following categories:

• Type I. Periodically updated for all users.

• Type II. Periodically updated with respect to each user.

• Type III. Updated pseudo-randomly.

The following three proposals can be used based on the type of provider.

Time scheduling algorithm for Type I provider policy

1. Assume that users with a "no trust" model have an immediate login time.

two. Sort users chronologically based on their expected time of entry into the system.

ES 2 200 753 T3

3. Delay the expected time of entry to the system by one hour, for all users.

Four. Produce a density curve fitted along time limits to obtain a polynomial function that can be used to determine the number of user accounts to collect during a given epoch.

5. Produce an integral adaptation algorithm with the inverse of the network activity curve during the time period in question, to fit the distribution curve.

6. If possible, redistribute the maximum collection time towards time zero to flatten the distribution curve.

7. Assign collection times to users ordered according to the distribution curve.

8. Monitor times and collect user accounts when appropriate.

Schedule scheduling algorithm for Type II provider policy

For each provider that falls into this category, a user attribute must be identified that determines when personal information is updated. In some cases, the user may need to be asked for the information. In others, it can be determined from the information collected. If the attribute cannot be set for a user by any of these means, the provider's site should be monitored daily for changes to personal information until a setting is established.

As there is a uniform natural distribution of accounts updated by a provider during a given day, a user account can be collected one hour before its expected entry time. As in the Type I algorithm, users with a "no trust" model will be picked up immediately.

Time scheduling algorithm for Type III provider policy

This type of policy is the most difficult of all. Since the provider updates a user account in a non-deterministic way, a decision must be made for each provider as to the credibility of the information relating to the user. For highly suspicious users, each user account should be collected daily, perhaps even more frequently. For less suspicious users, user accounts would be collected less frequently and possibly when overall system activity is low.

The IP provisioning component 350 is responsible for formatting and provisioning the IP to the end user. Usually the delivery only occurs immediately after updating all the outdated IP. The IP will be supplied to one or more destinations (for example, fax, telephone, pager, web browser, email, etc.) as specified in the 360 ​​user repository, except where the IP is accessed through a website. intermediary. Where the destination is not an intermediary Web site, the IP provisioning component 350 performs all the necessary formatting to serve the IP to the appropriate destinations. For example, where the destination is a web browser, the IP would be formatted as an HTML document, or where the destination is a phone, the IP would be presented for voice synthesis and transmission.

In the case of an intermediary website, the IP is supplied in a format configurable by the site

Intermediary web. Figure 5 graphically illustrates a possible embodiment of the present invention using an intermediary website. An end user 210 uses a client computer 220 to access an intermediary website 510 via the Internet 230. End user 210 enters the intermediary website 510. The intermediary Web site 510 contacts the IP machine 240 over the Internet 230 and directly receives the updated end-user IP, as needed, from the IP provider's Web sites 250. The intermediary Web site 510 receives the IP, embeds it into pages according to its particular formatting style and graphical user interface, and supplies these pages to the end user 210. The use of the IP machine 240 is transparent to the end user 210. Furthermore, an intermediary website 510 serving aggregate IP to an end user 210 can simultaneously serve as an IP provider, and most likely will.

In another embodiment, this formatting occurs through a dynamic HTML generation system that combines compositional and stylistic information from a variety of sources. The IP provisioning component 350 dynamically generates client HTML pages. These pages are customized based on numerous stylistic factors (such as background color, foreground color, font size and font, color and style, page layout, etc.) from a variety of fonts, and content. from a variety of sources. Information providers, resellers, end user, IP delivery component 350 or any combination of these sources, or other relevant sources, can provide customer adaptation factors used in page generation. Finally, each HTML page must be filled with data. The data used on such pages may come from sources such as information providers, distributors, the end user, the IP delivery component 350 or any combination of these sources, or other relevant sources. The required solution is a system that represents a generic algorithm to perform said generation of HTML pages at runtime. The style and content can be provided in any suitable format, such as the Extensible Stylesheet Language (XSL = Extensible Stylesheet Language), specified by W3C at http://www.w3.org/TR/WD-xsl/, and / or the Extensible Markup Language (XML = Extensible Markup Language) specified by W3C at http://www.w3.org/TR/REC-xml, or other suitable formatting standard. The key requirements for such a system are complete delineation of the scope of the problem and runtime performance.

In preferred embodiments, the solution is based on the following basic model depicted in Figure 8:

1. Six sets of customer adaptation factors are identified: vendor 810 content, vendor 820 content, vendor style specification 830, vendor style specification 840, user-specific content 850, and user-specific style 860.

two. Each set of 810-860 customer adaptation factors is considered a separate, independent, and necessary input for the 870 system.

ES 2 200 753 T3 run time that performs dynamic page generation.

3. Each 810-860 entry will be in the form of an XML stream.

Four. The 880 output will be in the form of an HTML stream.

5. The dynamic page generation 870 system will produce valid 880 output for each set of six valid 810-860 inputs.

Figure 9 illustrates an actual input process execution time sequence using said 870 system:

1. The distributor content 810 is combined with the vendor content 820 and user-specific content 850 to produce a complete content specification 930 by the content merger unit 910.

two. The dealer style 830 is combined with the supplier style 840 and the user specific style 860 to produce a complete specification of the 940 style using the 920 style fusion unit.

3. The style specification 940 is applied by the style applicator 950 to the content specification 930, to produce the resulting page 880.

To fully delimit the scope of the problem, the following requirements must be set on the 870 system:

1. Each 810-860 XML input is a valid XML stream.

two. All 810, 820, and 850 content specifications are valid with respect to the same Document Type Definition (DTD).

3. All 830, 840, and 860 style specifications are valid with respect to the same Document Type Definition (such as the XSL DTD standard).

Four. The merge units 910 and 920, whose task is to take two or more XML streams and produce a combined XML output, must be able to produce such output for any set of valid XML inputs.

Another method of accomplishing this task would be to format the IP as HTML elements with predefined CLASS attributes. The intermediary Web site that receives these items could dynamically include them on the page sent to the IP end user. Pages incorporating such elements might include different style information associated with the predefined CLASS set. The Level 1 cascading style sheet convention could be used to implement such configurability. See Kerven, Foust, Zakour,

HTML 3.2 Plus How-To, Waite Group Press, 1997, pages 651-693; Walsh, "An Introduction to Cascading Style Sheets," World Wide Web Journal, Winter 1997, pages 147-156. This option requires minimal programmatic support from the intermediary website, but restricts to some degree the flexibility of intermediary websites in presenting the IP to the end user.

Alternatively, an intermediary Web site could develop an application that uses a standardized Application Programming Interface (API) to directly access IP data. In this case, the IP provisioning component 350 could be bypassed or potentially used as a component responsible for serving API requests regarding data. Under this model, the intermediary website would be responsible for all formatting decisions regarding the raw IP data. This deployment option requires additional programmatic support from the broker Web site, but allows more flexibility in the use of raw IP.

The ability to use an intermediary website to supply IP is of significant use. This ability allows an end user who is already familiar with an existing IP provider to access not only the IP associated with the particular IP provider, but also all the IP of other IP providers in the convenience of a familiar user interface. user, namely the website of the existing IP provider. In this situation, the IP request would originate directly from the IP provider's intermediary website, and indirectly from the end user. Security measures would restrict access to authorized intermediary Web sites. These measures could include verification of the end user and the intermediary website. In addition, verification of the association between the end user and the particular intermediary website may also be required for added security.

In addition, the use of an intermediary website also supports a new transaction model. In this transaction model, the broker site subsidizes, or fully compensates, the administrator of the IP machine for services provided to the end user. These transactions are facilitated by the auditing and tracking capabilities of the IP machine. These capabilities allow the calculation of user fees, transaction fees, access fees, or some combination of these to be evaluated. The evaluated values ​​could be uploaded directly to the intermediary website. Alternatively, such values ​​could be charged from a minimum monthly fee charged to the intermediary website, with any fee in excess of the minimum being charged directly to the intermediary website.

Figure 11 represents a flow diagram of a typical process according to the model described. The intermediary website pays a minimum monthly fee in step 1110. In step 1120, the IP machine audits and tracks the end user usage through the intermediary website. Audited usage is used to assess a fee per user, per access, per transaction, or a combination of these. In step 1130, this audited amount is charged from the fee paid in step 1110. At step 1140, the intermediary website is charged any fees in excess of the minimum fee paid.

Frequently, an end user may require access to the underlying web page generated by the provider of a particular piece of IP. The provisioning component can supply not only the IP, but also an access point directly to the page of the supplier supplying that IP. The access point can take the form of a link, a bo12

ES 2 200 753 T3 form toner or some other interactive access mechanism.

Such an access point significantly improves the performance of accessing the underlying page by the end user, as shown in Figure 7. In the traditional process 100 to access IP, the end user must advance through numerous intermediary pages that they require a variety of often tedious interactions before reaching the desired page.

First, the end user must identify Provider 110. Next, the end user must locate the Provider's web address 120. The user then requests the entry page 130 from the Provider. If the end user does not remember the necessary information, this information must be found, or the desired information will remain inaccessible through the Web. The end user then navigates to the Provider's website 140. This frequently involves visiting the Provider 710 home page followed by viewing a variety of intermediate pages on the Provider 720 site. The end user may have to go back several times to the main page 710 or accidentally leave the system completely forcing a second entry 140 before finally locating the desired information 150.

Using springboard technology, the entire 750 process is reduced to a single click on an access point. The provisioning component of the IP machine supplies an access point for the underlying Provider page, along with the IP. As a consequence, the end user only needs to perform a single interaction with the IP presentation page 760.

This interaction immediately effects the necessary interactions with the Provider's Web site to bring the user to the desired underlying Web page 150.

In one embodiment, this springboard technology could be implemented using a Java applet. Referring to Figure 2, the applet could be downloaded from the IP Central Computer 290 via the end user's client program 270, usually a Web browser, and run locally by the end user's computer 220. The applet would lead the client's program 270 to the desired page. Said applet could collect procedures and data to direct the client's program from supplier repository 310 and user repository 360.

In another embodiment, IP machine 240 could act as a proxy server that directly accesses provider pool 310 and user pool 360 when needed. When the IP machine 240 receives the request to jump to the source of a particular piece of IP, the machine performs the necessary actions to navigate to the desired page and send the desired page to the end user's computer 220. Other interactions with the page may require additional seizure by the IP machine 240, as accumulated "cookie" data may reside on the IP Central Computer 290. This embodiment is limited to being used in handling normal HTTP traffic instead of secure HTTP traffic.

In a preferred embodiment, the springboard provides the end user with automated login to the IP Provider site 250, and allows the end user 210 to navigate through the client program 270.

This automated input could be done using a bypassed Hypertext Transfer Protocol (HTTP). Upon receiving a request for springboard access from the end user 210, through the client program 270, the IP Central Computer 290 requests from the IP Provider site 250 the entry page directed by the springboard access. IP machine 240 running on IP Central Computer 290 receives this login page and constructs a login request accessing the appropriate data in provider pool 310 and user pool 360. The input request is contained in the bypassed HTTP that is sent to the client program 270. The client program 270 is redirected to the routed IP Provider site 250, and the end user 210 is automatically entered at this site.

Alternatively, these functions could be implemented using a Java applet as described above. In addition, the IP machine 240 could generate a Java script page containing the relevant input request, rather than a bypassed HTTP. The Java script page could be returned to the client program 270. This page would then be executed by the client's 270 program to get automated input.

The IP machine 240 of Figure 3 may also include a site supervisor process component 370. This component would systematically monitor the websites of supported IP providers for changes. This component enhances the system's ability to identify alterations in IP provider Web site procedures, data requirements, and "cookie" requirements. This component increases the performance of the system by completing or supplanting the tamper identification by feedback from the IP access / transaction component 340.

Another embodiment of the present invention could support IP location manipulation. This could be accomplished where the client program 270, running on the client computer 220 of Figure 2, is a specialized Web client rather than a general Web client such as Netscape. This specialized client could use web channel technology to automate the local IP download and update processes. Where IP repository is implemented using the aforementioned "cookie" architecture, this specialized client can provide direct local access to the stored IP.

In another embodiment, the IP machine 240 of Figure 3 could support both IP providers supported by the system, as well as specific IP providers for particular end users. In this embodiment, an end user is not limited to the available IP of the IP providers present in the provider pool 310. For an end user to add IP provided by an unsupported IP provider, the end user would access the Baseline configuration component 320 and create a configuration for the unsupported IP provider. The IP provider and IP settings, along with verification and access data, would be stored in user repository 360, along with the user's annotation.

Another embodiment of the present invention supports the inclusion of IP transaction procedures

ES 2 200 753 T3 and access requirements in the provider repository 310 of Figure 3. The specific end-user information required to perform said transaction would reside in the user repository 360 with the user's annotation. The functionality of the IP access / transaction component 340 would be expanded to support the transaction function. This additional functionality could be supported in a manner similar to the procedure described above with respect to the access function using a simulated Web client. Another feature of this invention would include automated or semi-automated account management by providing trigger events to automatically initiate a transaction.

For example, referring to Figure 2, an end user 210 could maintain their accounts online through the IP machine 240. If an information provider has the ability to receive payments online, the IP machine 240 could support full or partial automation of such transactions. If there is an expiration date on an invoice for a certain information provider, the IP machine 240 could flag that information and send an email to the end user 210 notifying him of the expiration of his invoice. Therefore, the user will not have to consult individually with each of their providers regarding the information on expiration dates. The IP machine 240 could also make automated payments within a limited range of billing amount for providers that allow payments on their Web servers 260, and then send an email to the user with the payment notification.

The acquisition of expiration dates could be done using the IP access / transaction component 340 shown in Figure 3. The expiration date information would be available to the end user through any means of supply supported by the component. 350 IP supply. The IP access / transaction component 340 would use normal electronic commerce bill payment methods to pay the user's bill (s) to the provider if he / she chooses. Once the invoice is paid, an email notification will be sent to the user with the provider information and payment information. The user can specify the margin of amount stored in the 360 ​​users deposit that will be paid automatically. If the invoice exceeds the amount specified by the user, the IP machine will simply send the user an email notification instead of paying the invoice automatically.

The embodiments described above are given as illustrative examples only. It will be readily appreciated that many deviations from the specific embodiment described in this specification can be made without departing from the invention. Accordingly, the scope of the invention should be determined by the following claims, rather than being limited to the embodiments specifically described above.