MXPA00006480A - Apparatus and method for automated aggregation and delivery of electronic personal information or data - Google Patents

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

Info

Publication number
MXPA00006480A
MXPA00006480A MXPA/A/2000/006480A MXPA00006480A MXPA00006480A MX PA00006480 A MXPA00006480 A MX PA00006480A MX PA00006480 A MXPA00006480 A MX PA00006480A MX PA00006480 A MXPA00006480 A MX PA00006480A
Authority
MX
Mexico
Prior art keywords
end user
information
provider
personal information
storage
Prior art date
Application number
MXPA/A/2000/006480A
Other languages
Spanish (es)
Inventor
Freishtat Gregg
Burson Robert
Ulberg Dima
Parnas Leon
Rajan Palaniswamy
Kaib Paul
Original Assignee
Verticalone Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Verticalone Corporation filed Critical Verticalone Corporation
Publication of MXPA00006480A publication Critical patent/MXPA00006480A/en

Links

Abstract

A system for delivering personal information according to the present invention includes a user store (360) including end user data, a provider store (310) including information provider data, a personal information store (280) including personal information (375) and a processor that communicates with these data stores. The processor selects an end user for personal information aggregation. The processor connects with one or more information providers. The processor then proceeds to retrieve personal information for the selected end user from the connected information providers. This retrieval is based on end user data associated with the selected end user and provider data associated with the connected information providers. The retrieved personal information (375) is stored in the personal information store (280).

Description

APPARATUS AND METHOD FOR AUTOMATED AGGREGATION AND SUPPLY OF TRANSACTIONS INVOLVING INFORMATION OR PERSONAL DATA ELECTRONICS DESCRIPTION OF THE INVENTION This application claims the benefit, in accordance with 35 U.S.C. § 119 (e), the Provisional North American Patent Application of Applicants Series No. 60 / 105,917, filed October 28, 1998, entitled "Apparatus and Method for Automated Aggregation and Delivery of and The invention relates to an apparatus and process for automated aggregation and provision of electronic personal information or data (PI). The invention also relates to the automation of transactions involving electronic Pl. Doing a review of the last five years, it is evident that as the impact won by the Internet, consumers demanded applications or services that would make their experience in the simplest, easiest to use and most satisfactory line. The development of successful Internet sites has corresponded with a number of topics that have been developed during the last years. When this evolution is carefully analyzed there is a logical development of the digital economy that emerges. Prior to 1994, the Internet: it was not a mass media, in part, due to existing technologies (FTP, Archie, Usenet, and Gopher where it was not user friendly and the end user was required to do all the work ( for example the end user would have to learn from an existing data source, find the address, navigate to the destination and download the information.) The other consumers started to access the Internet, the Search Systems were created to solve this issue of usability With the advent of commercial Search Systems, additional content could be easily added to the Internet and the end user had a means to find and access this information Consumers required better tools than Search Systems to organize and access This variety of generic content, the driving technologies were explored and, eventually, the portal strategy was adopted successfully. as an efficient way for consumers to easily access a variety of content sources in a simple and easy-to-use format. As the volume of available online content continues to grow exponentially, portals are now confronted with the need to make different types of content available to different consumers with different preferences and tastes. The success of the phenomenon of Internet portals and destination sites has demonstrated the importance of creatively and intelligently adding, organizing and presenting the mass of information available on the Internet. Search systems, portals and destination sites They have Internet strategies based on the frequency, duration and quality of the end user who visits their sites. For this reason, the destination sites and portals are continually looking for content and / or technologies that drive quality traffic to your site 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 shows the current process of the online acquisition Pl 100. The end user first selects an information provider site in step 110. The end user proceeds to step 120 by assigning and registering the internet address of the user. selected information provider. This stage can be achieved in several ways with different levels of complexity. A simple means to perform this stage is the use of a personal or favorite brand considering that it assigns a first time information provider that can involve significant time and effort when executing online searches. In step 130, the end users are connected to the Web server or the selected information provider using the specific connection protocol of the site. This protocol usually involves verification of the identity of the end user using a username and password or other means of verification, the acquisition of verification data from "cookies" that reside in the end user's system or a combination of requested data and "cookie" data. The end user continues in step 140 by browsing through the web pages on the information provider's website until the desired information is located. During this process, the end user is frequently required to visit DOCO websites or no use for the end user whose objectives are simply to acquire the particular PI resident on the website. Finally in step 150 the user is presented with the desired Pl. The entire process 100 is repeated for each individual piece of Pl that is desired by the end user. Under this PI access model, the end user can visit each information provider separately, track the potentially different identity verification data for each one, use a different user input at each site, and possibly scroll through a significant number. of web pages of fill. Figure 4 illustrates in graphic form the architecture of this current access process. The bad user 210 uses the client computer 220 to access each Pl 250 Web site through the Internet 230. This current model has several significant deficiencies. The end user must connect to each site separately. Each site has its own graphical user interface. Each site requires the user to stay and return. Each site visited wishes to retain the end user's focus as little as possible. There is no real aggregation of the Pl; Multiple accesses simply allow sequential access to particular pieces of? I. A partial solution to these problems has recently evolved in the form of the Dortal sites. Generic portal sites add resources in categories and provide links to sites that cover topics within those categories, ianoo and Excite are examples of generic portal sites. These sites facilitate the horizontal aggregation of generic content; horizontal aggregation refers to the aggregation of access Pl within a category of particular information provider such as banks or service companies. Some portal site allows individual end users a limited ability to select and configure different generic Pl. The generic PI refers to the PI of interests for the particular end user that does not require verification of specific identity to obtain it. For example, an end user owns to be interested in forecasting the weather for their local area. This information could be integrated into a portal oagma without requiring verification of the identity of the particular end user receiving this PI. The individualized oortal page provides a significant benefit to users who are looking for aggregate PL. However, the current portal pages do not generally provide the PI that requires identity verification such as the end user's stock portfolio or bancapo account statement. Also, these pages do not facilitate transactions using Pl. Ba or current technology, the aggregation Pl available on the Internet requires significant discomfort in terms of time, effort and learning curve. An end user who wants to access his Pl needs to visit individually a variety of information provider sites, each with its own requirements, graphical user interface and connection protocol. In the present invention, a network computer is used to facilitate end user access, handling and transactions involving electronic PL associated with the particular end user such as a stock portfolio, local weather, sports scoreboards, account statements banking or other pertinent information or data. In accordance with the present invention, the relevant PI for the particular end user is added to the computer on the network. This information or data is provided to the end user in a unified manner by a variety of selectable delivery platforms such as facsimile, computer customer, phone, conventional mail, email, sorter, other wireless device, Web page or channel or other supply vehicle. The present invention also facilitates a variety of electronic transactions involving Pl such as stock transactions, retail acquisitions, check payment, bank account fund transfers or. other transactions. A system for supplying personal information in accordance with the present invention includes a user storage that includes end-user data, a provider storage that includes information from the provider's data, a storage of personal information that includes personal information. and a processor that communicates with those data stores. The processor supports the aggregation of personal information. The processor selects an end user for the aggregation of personal information. Once the end user is selected, the processor connects with one or more information providers. The processor then proceeds to retrieve personal information for the selected end user from the connected information providers. This recovery is based on the end user data associated with the selected end user and the provider data associated with the connected information providers. The recovered personal information is stored in personal recovery storage. In an aspect of the present invention, the Network computer alternatively referred to as the main computer, is used to distribute, store and retrieve electronic information associated with the particular end user. In a particular modality, the information is personal information such as the stock portfolio, the local climate, sports scores, bank account balances or other pertinent information or data. According to this aspect, the relevant PI for the particular end user is added on the main computer. The main computer transmits the aggregated data to a client computer associated with the end user or individual for whom the PI was added. Preferably, the aggregated data is transmitted to the customer's computer as "cookie" data and stored as such by the customer's computer. In some modalities, the aggregated data is encoded before transmission. The Host computer receives a per.cion concerning the aggregated data. The source of the request is preferably the client's computer, although other suitable device sources are contemplated within the scope of the present invention. The main computer receives the aggregated data from the client's computer, preferably as "cookie" data. If they are encoded, the aggregated data is decoded. The main computer proceeds to attend the request to generate a result of the request. The result of the request can be provided on a variety of platforms, preferably a Web page. Alternatively, the result could be provided to a telephone, an e-mail destination, a facsimile or other printing device, directly to a Web browser, a third computer, a wireless device or another suitable supply platform. In another modality of this aspect, the specialized software may exist in the client's computer by means of which it requests the requests that refer to the aggregate data transmitted by. The main computer can be serviced on the customer's confudora. Such specialized software would include any description software if appropriate. In another aspect of the present invention, the electronic information from disparate sources is dynamically combined with style preferences determined from widely disparate sources to generate a compatible electronic document. In a form of this aspect, the electronic plan associated with the particular user such as the stock portfolio, the local climate, sports markers, account statements or other information or pertinent data that combine with the content of the d? Str? Buyer and provider to provide the content of the generated document. The style information is accumulated according to the preferences of the end user and the distributor and the style information of the supplier. An adaptive compatible electronic document is generated by applying the combined style information to the combined content. This generated document can be supplied to the end user in a unified manner by a variety of selected delivery platforms such as facsimile, client computer, wireless device, personal organizer, telephone, sorter, Web page or channel or other supply vehicle. A system for adaptively dynamically generating compatible electronic documents in accordance with this aspect of the present invention includes a style merger unit, a content unit, and a process unit, which may be included on the computer network of the present invention. The style merger unit accommodates the style information of one or more style providers and dynamically merges the accumulated style information. The content merger unit accumulates the information contained in one or more content providers and dynamically fuses the accumulated content information. The processor receives the merged style and content information and generates an adaptively compatible electronic document through the application. dynamics of the received style report towards the content of recycled information The generated page can be issued to a variety of supply platforms. In another aspect, a main computer programs the collection of information associated with one or more end users from one or more providers of information. The host computer is in communication with the user data storage to store the data associated with the users and a storage information provider to store the data associated with the information providers and includes a processor. For each end user, a profile of previous access times, times of connection <;? on, it is kept in the user's data storage. For each information provider, a profile of the update times and the criteria are maintained in the storage of the information provider. Updating times and criteria may be stored with respect to all information provided by each information provider, or updates and criteria may be stored with respect to each piece of information provided by each information provider. For a selected information provider, the processor of the host computer determines an update time for the information stored by the selected information provider and a set of end users whose information could be modified by an update at that time of update. The main computer processor generates a predicted connection time for each end user in the given set of end users and each generated connection time returns to a predetermined interval. The processor of the main computer classifies the determined set of end users according to the predicted connection time or the diverted connection time and yields a:? Me collection for each end user based on each connection time deviated or predicted of the end user. II processor of the main computer, in a modality of this aspect, can also collect the information for each end user in the set determined from the information provider selected in the collection time assigned to each end user. In another embodiment of this aspect, the processor of the main computer determines the set of end users whose information can be modified by an update at the determined update time by first selecting the end users configured to receive the information from the information provider. selected and eliminate those end users not configured to receive the information subject to update at the time of certain update. The processor of the main computer can also eliminate the end users of the set that do not meet the criteria or update conditions to update associated with the information provider or the information subject to update at the time of the given update. The main computer processor can generate a predicted connection time for each end user in the determined set based on the connection time profiles stored in the user storage. For each end user in the given set, a determination is made as to whether the connection time profile of the end user matches a predetermined confidentiality threshold. If the profile meets this threshold, a predicted connection time is assigned based on the profile If the profile does not meet this threshold, a predicted connection time is assigned corresponding to the current day and time. the principal computer's processor for each end user based on its predicted connection time In one embodiment of this aspect, the collection time assigned to each end user corresponds to their predicted connection time offset generated as a predetermined interval. In a further embodiment of this aspect, the main computer processor allocates collection times for each end user based not only on their predicted connection time but also on the expected network activity.The processor of the host computer executes first a distribution adjustment through time to generate a polynomial function that allows the determin the number of end users subject to collection during a specific period. Then determine a network activity curve of the Network activity associated with the same selected information provider. An inverse of the predetermined activity curve is generated. So, an integral coupling algorithm is executed using the generated polmommal function and the generated inverse of the network activity curve. Finally, collection times are assigned for each end user to redistribute the peak collection time the zero time was born to equalize The adjustment of distribution over time. In a further aspect of the present invention, electronic actions involving personal information (PI) associated with an end user are automatically executed for the end user. An end user will have a variety of electronic PLs associated with it such as stock portfolio, local weather, sports scoreboards, bank account statements or other relevant information or data. In one embodiment of this aspect, an end user storage contains the end user data associated with an end user and records that correlate the actuator events with responses associated with the end user. A main computer processor accesses the records associated with the end user. For each record accessed, the main computer determines if the driving event in the record has occurred and if so, executes the response correlated with the trigger event that is determined to occur. The execution of the response may involve the provision of a notification of the occurrence of the driving event towards a specified delivery platform such as a wireless device, a facsimile, a telephone, a printing device, a sorter, a Web page residing in the Web server an email system or other suitable supply vehicle. Instead, or in addition to this, for such notification, the host computer can automatically execute a transaction that involves the personal information associated with the end user. In an additional modality of this aspect, the automated execution of such a transaction will involve the main computer accessing records related to the information provider based on the response indicated in the accessed end user record in which the driving event was determined so that happen The main computer connects to a computer from the information provider indicated by the accessed data associated with the information provider. The host computer then executes a transaction script on the connected information providing computer based on the associated data accessed with the information provider, the response indicated in the end user record in which the driving event was determined to occur and the end user data from the storage of the end user. In another aspect of the present invention, a host computer monitors the interactions between the end users and the providers of personal information by means of an intermediate computer. Interactions will generally fall into two categories: requests for the provision of personal information and requests for transactions involving personal information. The main computer communicates with a personal information storage to store the personal information associated with the end users and an accounting storage to store the accounting data associated with the intermediate computer. The main computer includes a processor. The main computer processor receives requests that refer to the personal information associated with an end user from the intermediate computer and the services of the request based on the personal information associated with the end user in the storage of personal information. The main computer processor updates the accounting data associated with the intermediate computer. The main computer processor can update the accounting data in a variety of ways. First, the processor of the main computer can increase an isuario ditch for each new user of the intermediate computer during a selected period. ? Then, the main computer's processor can count the interactions executed through the intermediate computer. Third, the main computer processor can, when the service request is a request to execute a transaction, increase a total commission based on the service request. Finally, the main computer processor can use any combination of these forms to use the accounting data associated with the intermediate computer. i The processor of the main router generates invoices to the intermediate computer based on the updated accounting data. The processor of the main computer can generate such invoices on a periodic basis. In a further embodiment of this aspect, the processor of the host computer can provide the generated invoices to a selected destination such as an email destination, a printing device, a Web page resident in a Web server, an Internet client, a telephone and a facsimile.
In another mode of this aspect, the intermediate computer has a count associated with it. The processor of the main computer can load this account before generating an invoice so that the invoice generated only reflects the additional income beyond the amount indicated by the account of the intermediate computer. The amount owed can be based on the updated accounting data associated with the intermediate computer using any of the aforementioned update types. Another aspect of the present invention is a system / method for automated access to personal information associated with an end user, wherein personal information is stored on an additional information provider. A representation of the personal information and a link that corresponds to the personal information stored in the personal information are presented to the end user by means of a client computer. Upon activation of the link, the client's computer is automatically propelled to the personal information provider who presents the user through the client's computer with a page about the personal information provider. In a modality of this aspect, a request is transferred to the client. The downloaded application initiates a connection between the computer of the customer and the provider of personal information. The application navigates through the pages about the personal mfoi nation provider until it reaches personal information. "anally, the application presents the person information to the user on the customer's computer.The application can be generated with any data associated with the end user and associated with the personal information of such data that can be transmitted to the application. associated with the personal information provider may include a navigation script to guide the request towards personal information.The data associated with the end user may include any data necessary to perform navigation through the navigation script. In this regard, a message that includes any necessary user data and personal information provider data is transmitted to the client's computer, causing the client's computer to automatically connect to the end user within the personal information provider, carrying this information. way to the end user to a po page In a preferred embodiment of this aspect, the message comprises a page containing a form, which includes the connection information which, when opened by the software on the client's computer, redirects the client's computer to a post-office page. Connection . In a further aspect of this aspect, the client's computer is propelled towards personal information by connecting to the personal information provider, navigating to the personal information about the personal information provider, presenting the personal information to the end user through the client. The client's computer and approximate the subsequent interactions between the client's computer and the personal information provider for a given assignment 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 process diagram of the current process that end users execute to access the Pl available through the Internet. Figure 2 is a block diagram of the components that could be used to implement the present invention. Figure 3 is a block diagram of the components of the Pl system. Figure 4 is a diagram of the current Pl access architecture. Figure 5 is a diagram of an architecture that supports Pl access using an intermediate Web site. Figure 6 is a cookie architecture / client cache memory diagram. Figure 7 is a flow chart for accessing pages underlying the particular Pl through the traditional process of the Figure and by means of trampoline technology. Figure 8 illustrates the integration model for Dynamic generation of HTML pages. Figure 9 shows the process of operation time for the dynamic generation of the HTML page. Figure 10 illustrates a process for automated applet interaction using a modified Java virtual machine. Figure 11 is a flowchart exemplifying an intermediate website transaction structure. A preferred embodiment of the invention will now be described in detail. Referring to the drawings, similar numbers indicate similar parts through the views. As used in the present description and through the claims that follow, the meaning of "a", "one" and "the" includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein and through the claims that follow, the meaning of "in" includes "in" and "over" unless the content specifically determines otherwise. At no time, the u _ > Final years will have to connect to a large number of different websites, each with separate access codes, security, rules, software and "feel and look" -only to obtain the information currently obtained by checking a place- the mailbox of mail at the end of the route. The Internet will fundamentally change the way in which end users will access personal information (Pl) and perform e-commerce as familiar as using an ATM. The "personal information" is composed of all the data that the information providers have that is specific or unique to each person such as monthly invoices, bank statements, investment information, health care benefits, email, voice and fax messages, 401 (k) holds or potentially any other information relevant to a particular end user. The present invention will alleviate several of the problems with the current PI acquisition methods by automatically adding the PI, not only the generic PI as added by portals but also the PI specified for the end user that requires identity verification for access. In one embodiment, the invention automates the acquisition of Pl and the 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 that operates the client software 270 which in a particular mode could be an explorer of the general network such as the Navigator or the Communicator (Netscape). The client computer 220 uses Internet 230 to access a Pl 240 system operating in a main system of Pl 290. The system pl 2-JO examines the stored Pl 280 for updated data. Any obsolete Pl items are renewed by directly acquiring the Pl from the Web site of the particular information provider 250 operating in the computer system of the provider 260 accessed through the Internet 230. The Pl 240 system stores the Pl renewed in its storage 280 and provides the Pl to a selected destination, in this case via Internet 230 to the client's computer 220 which displays the information for the end user 210 using the client software 270. The Pl 240 system renews all obsolete Pl in a similar manner before directing the PL added to the storage 280 / to the delivery destination, the client computer 220 in this case. The Pl 2'0 system can renew the Pl sequentially or in parallel. Po. For example, the end user's checking account status will be updated through your bank's website, your e-mail from the particular e-mail site, ^ or portfolio information from your broker's site and your invoice. electricity supply from the site of your electricity company. Figure 3 shows a block diagram of the components of the Pl 240 system. The Pl 240 system is composed of storage and processing components. JOS three components of primary storage are the storage Pl 280, the storage of provider Pl 310 the user storage 360. The first storage component of the system of Pl 2 ^ 0 is the storage Pl 280. The storage Pl 280 contains each of the individual Pl records 375; the Pl associated with a particular end user is added from the Pl of the other end users. The Pl system also uses a vendor storage 310 that maintains the general parameters associated with the particular PI providers. The general parameters of a PI provider define the types of verification data needed and all the procedures that will be followed to obtain access to 2b Private PI provider. Each PI provider also records the contents of the PI types provided by the PI provider and the types of transactions supported by the provider. Along with the type of Pl, 3 the transaction, the record also contains the additional documents and procedures necessary to expedite the Pl or execute the transaction. A 360 user storage is also necessary to maintain the configuration and verification of the information that relates to the particular end users. For each end user, the selected Pl suppliers, the Pl and the transactions with registered with the verification data necessary to acquire the Pl or execute the transaction from the supplier of Pl. The storage of Pl 280 can be implemented in a variety of ways. Referring to Figure 2, the storage of Pl 280 may comprise a database residing in the main system Pl 290. Under this approach, the Pl for each individual end user 210 is stored as a separate record or object 375 in the database. In yet another embodiment, the Pl for each end user 210 could be stored in a separate file 375, thus executing the task of segregating Pl from different users at the file level. In addition, or as an alternative, the PI associated with each end user 210 may reside on its client computer 220 using the "cookie" technology as specified in D. Kpstol v L. Montulli, "HTTP State Management Mechanism", Request For Comments (RFC) .109, February 1997, (available in .j / _. Fc / .21 'which is expressly incorporated herein by reference.) The Pl associated with the end user 210 would be stored as "cookies". 375. This implementation mechanism provides the consistent support for segregating the PI associated with an end user 375 from the PI associated with all the other end users, using this method as a substitute for centralized storage provides a security layer against the unauthorized access As an additional measure, Pl data stored in "cookies" could be stored in a coded format Figure 6 provides a typical implementation diagram of Pl 280 ut storage Ilizando The technology of "cookie"; the references in the following description are also made to Figure 3 with respect to the internal works of the Pl 240 system. When an attempt is made to access the Pl by an end user 220 directly or ugh an intermediate Web server, the component Access / Transaction of Pl 340 of the Pl 240 system would retrieve the stored Pl 375 from the storage of Pl 280. Ba or this approach, the stored Pl 375 would be received directly from the "cookies" sent by the client's computer 220 to the "bad" user 210. The pass / fail component of Pl 340 would execute any necessary decoding, any updates would be obtained ugh the direct access of the PI 250 ovens. The supply of Fl 350 would provide the mechanism for updating the Pl 280 storage as well as for the transmission of the requested Pl to the end user 210, directly e to t? _aves of an intermediate Web site. The supply component of Pl 350 would place the updated Pl in the storage of Pl 280 replacing the outdated "cookies" of Pl 375 stored on the client's computer 220. The supply component of DI 350 would also handle any coding if necessary. The third-party component of Pl 350 would also be responsible for transmitting the requested Pl. In a preferred embodiment, the storage of Pl 280 would be implemented using this architecture based on "cook." The storage of "360" may be "implemented in a variety of ways." Referring to FIG., the user storage 360 may comprise a database that resides on the Main system Pl 290. Under this approach, the personal configuration data for each individual final user 210 is stored as a separate record or object in the database . As an alternative, the end-user data could be distributed in a manner similar to the "cookie'Vcache described architecture with respect to the storage of Pl 280. In a preferred embodiment, user storage 360 could be implemented at Through the personal information configuration (PIC) files, the PIC files store a personal profile such as name, address and social security number in a coded and secure way for each end user.PIC files facilitate the automatic registration of users final LO? the information providers by means of the end user configuration component 330. This component will read the PIC file and, using the personal information retrieved, relocate the registration templates for the selected providers and then instruct the user to record the The information required is based on the profile, if necessary. pleta, the registration is automatically completed. Next, the end user configuration component 330 completes any form of supplier registration, obtains responses and updates the end user's PIC. The four primary processing components access and manipulate the data in the three storages. The processing components must be executed in a single processor, such as the file server computer system based on a class Perr_u'm (MM_, POR, II, III, etc.) central processing unit or in equivalent, or multiple processors. These four processing components are the base-line configurator component 320, the end-user configuration component 330, the access / transaction component 340, and ^ 1 supply component Pl 350 as seen in Figure 3. Configurator component of the Base Line 320 provides the inferred by which the new Pl providers selected by the user are added to the system. Component 320 can be implemented in a variety of ways including trial and error followed by manual recording of semiautomated conficuracion, trial and error information (automated location of the Hypertext Markup Language (HTML) <; FORM > elements, functions of Javascppt and Java applets) followed by the manual registration of the configuration information or, preferably, the configuration for example (executing the protocol in a simulated Web client where the simulated Weo client automatically generates a list of required data and a list of stages in the access process). These processes would be used in two levels: the first level that is the set of data and stages required for the general access to the gold supplier of particular Pl and the second level that is the set of additional data and stages required to access each particular piece cl ^ Pl on the gold site of Pl. The oase 320 line configuration component can be triggered independently when a new PI provider is added to the system, or it can be triggered as a result of an access / transaction component failure of Pl 340 potentially indicating a change in the requirements of access for failed access. This subsequent warning will most likely result when the access / transaction component of Pl 340 has made a comparison between the requirements supplied by the test storage 310 both from the general to the PI provider and the specific to the PI or transaction and the data from rinal user supplied by the user storage 360 after searching for the end-user verification by means of an end user request to confirm the required access data previously recorded by means of the end user configuration component 330 and found as inconsistency. When an inconsistency is determined, updates to the tester storage 320 are made to bring the provider data into compatibility with the current access / transaction requirements.
The end-user configuration component 330 allows an end-user to select configure PI and transactions of interest towards the specific user. This information c-configuration is stored in user storage 360. When a user is only partially subscribed. To the system according to the invention, the system allows the user to select the types and sources of Pl and / or desired transactions. First, the system requests permission from the end user to act on its behalf to obtain any selected PI and to execute any authorized transactions. Next, the system provides the user with a list of the known information providers and the types of Pl provided and the transactions supported by the provider of the particular PI from the storage of Proveedo. 302. The system requests the verification data necessary to access each selected PI provider and the additional data required by the particular PIs and / or desired transactions from that PI provider. assuming that the end user is already a registered user with the selected PI provider or the PI particlar provider does not require prior registration, the data provided by the end user is placed in user storage 360. A method to obtain any data of cookie would be serious so that the end user accesses every accessed JJ Pl Obviously using the Pl 240 system as a gold server? imo. The Pl 240 system would pass the cookie data to the Pl provider's site with the Web page requests to obtain the Pl or execute the request and with the end user's permission it retains a copy of the cookie data in its storage record 360. An alternate means of cookie data would be a direct download of the cookie information from the end user's computer. In a preferred embodiment, no cookie is necessary when a user is already registered with a provider. All that is necessary is the verification data for the connection. The end user does not have the requisite information because he is not a registered user of a selected PI provider, the component configures user 330 to indicate to the user the necessary information to register the end user with the provider of Pl and execute the registration procedure required by the supplier of Pl. A simulated Web client could execute this process automatically supplying the access data as required and sending any necessary cookie data. The manner in which such a simulated client registers the end user depends significantly on the interaction method used on the website of the provider Pl. If the Web site uses HTML forms and the common application bridge (OGI) interface, the end user configures the 330 component that can formulate a uniform resource locator (URL) to reproduce the effect of the current form and present this. UPL to the simulated Web client. The use of a URL to imitate an HTML profile is equivalent to manually registering the data in the Web element ^ FORMS > . See Kerven, Foust, Zakour, HTML 3.2 Plus How-To, Waite Group Press, 1997, p. 559-569. If the website uses a combination of HTML forms and Javascppt functions, a simulated Web client with a modified Javascript interpreter can effectively register the user through the following end-user registration process for the particular PI provider. The registration process to be followed would be obtained from the registration of the particular PI provider in the storage of provider 320. The interpreter Javascppt in the simulated Web client would follow this procedure and provide the data provided to the end user. A similar process could be used if the provider's website registration process Pl 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 by the particular provider Pl in storage 320. The byte code interpreter would supply the previously registered data by the end user instead of requiring the interactive input of the end user. If the provider's website Pl uses a combination of forms, scppts and e ^ olets, the above individual procedures 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 different functional components of the Pl 240 system and the Java applet available through the provider's Web servers. 250. The templates for interacting with particular applets could reside in the storage of the Provider 310. The specific input data used by such templates could be stored in the storage of User 360. When a functional component such as the end user configures 330 or the components Access / transaction 340 require automated communication with a Java aoolet or a Web server provider 250, the modified Java VM facilitate this interaction. FIGURE 10 illustrates a process that uses such Java VM modified to achieve automated interaction. The functional component that requires the interaction identifies the provider and the particular applet on that provider with which the component needs to interact in step 1010. In step 1020, the component accesses the 3b template necessary for interacting with the applet from the storage of the Provider 310. Proceeding to step 1030, the component accesses the storage of User 360 to obtain the required data or the page. Modified Java VM interprets the applet in step 1040 and instead of requiring the interactive input or a user as in a normal Java applet run, it expects input from or to the interactive functional component of the Pl system. In step 1050, the functional component supplies the input data to the modified Java VM according to the accessed template \ the recovered data and receives the output data from < according to the template accessed. Steps 1040 and 1050 are repeated while the additional entry to or exit from the applet continues. Upon termination of the applet, the functional component continues with its own processing in step 1060. A successful registration may result in the display of the registration information to the end user for future reference. In addition, the end user configuration component 330 stores the requisite access verification data for the provider Pl and the additional data required to access the selected PI or the transaction in the user storage 360. In a preterm mode of such registration automated, any necessary cookie data would be accepted and stored as necessary by the configuration component of us_ _? of? n_ 1 330. In many cases, the cookie contents are specifics of the transfer and therefore of a useful scarce long piuco. The cookies generated during the registration process are used only during the registration process and discarded after the registration is completed. A failed record could result from several situations. First the final user who tries to legislate with the provider of ~ 'I does not qualify for registration; for example, an end user who tries to register with a bank with which the firal user does not maintain an account and where Pe ne only allows access to account holders. Then, the end user may have incorrect or incorrect information provided. For example, a bancapo registration process may require a social registration number, an access code, a bancapa account number and the maiden name of the mother who is the end user; If the user registers an incorrect social security number, the registration process fails. Finally, the provider PI pi ede have altered the registration procedure for your website. In this situation, following the process provided by the storage of the Provider 320 would produce a failed registration. In this case of a registry failure, the final user could be presented with the data provided micially to the system for re-registration. The system could then ask the end user for double verification to correct the information and correct the re-sending of the data if an error was found, a second error resulting from the submission of identical requirements. it can generate an error message presented to the user fi '~ al stating that the end user is not eligible purely to access the selected PI from the selected PI provider or that an alteration of the Fl provider may have caused an error in the This second failure could also trigger a warning that suggests the need to potentially reconfigure the reg_stro for the supplier of Pl in the storage of Proveedc 320. Currently, the user storage 360 would contain a record for each end user. described above could be a database record, one or more cookies or a file such as PIC. Each record would identify the selected PI providers along with the necessary general access records and also under each PI provider would be a PI List supplied and the transactions supported by the particular PI provider for the user 1 wrong along with the Additional data, if any, necessary to access that PI or execute that transaction. Specifically, the duplicate information tul as an end user name would be stored centrally once in the record. The end user configuration component 330 also allows the user to select one or more delivery destinations. A destination is the end-user computer as exemplified by the client computer 220 operating the client software 270 in FIGURE 2; however, a computer is not the only destination contemplated by the present invention. A destination for PI delivery could include facsimile, email, telephone, conventional mail, sorter, other wireless device such as a Palm Pilot, Web page, web browser or other delivery mechanism. indirect IP access by the end user using a Web site as an intermediary, however, such indirect access does not require the end user to specify a delivery destination unless additional delivery options are desired. End user configuration 330 may occur through direct access to the Pl system via the Internet as contemplated by the client computer 220 operating the client software 270 in FIGURE 2, however, the alternative methods of Access is also viabLes, for example, .1 user can access indirectly to the Pl system through the iN of a Welfare site. ntermed o A telephone interface to allow access to the end user configuration component is an alternative. With reference to FI "JRA 3, the access / transaction component Pl 340 discounts the updating, acquisition and transaction of the PLC 240 system functionality. The access / transaction component Pl 340 is responsible for accessing and storing the Pl user and execute the transactions authorized by the end user. When the access or update is necessary for a selected user, the access / transaction component Pl! 40 combines the parcr information of the storage of the Provider 320 and the storage of the directory 360 to update the user's plan in the storage of Pl 280. For each piece of Pl that requires access or update, the access / transaction component of Pl 340 looks for the access procedure and the information needed for the particular Pl in the storage of provider 320. The verification and access data is found in user storage 360. The access / transaction component Pl 340 uses this information to connect to the Pl provider's website through the Internet and to access the Pl. When multiple pieces of Pl require updating or access, access can occur in series or in parallel. Required transactions would be supported in a similar manner. For each transaction, the access / transaction component Pl 340 combines information from the storage of Provider 320 \ user storage 360 to execute the requested transaction. The access / transaction component Pl 340 looks for the transaction procedure and information necessary for the particular transaction in the Provider storage. Verification and access data are in user storage. The access / transaction component Pl 340 uses this information to execute the transaction through the Internet from the website of the provider of Pl. A simulated Web client can execute access or access or transaction processes automatically by providing access and verification data as necessary. The manner in which a client accesses the Pl or executes the transactions depends significantly on the interaction method used on the website of the provider Pl. If the Web site uses HTML forms and common bridge inferred (CGI) applications, the Pl 340 access / transaction component can formulate a Uniform Resource Locator (RL) to reproduce the current usage effect and present this URL to the simulated Web client. Using a URL to match an HTML form is equivalent to manually registering your data in the < FORM > of the Web See Kerven, Foust, Zakour, HTML 3.2 Plus How-To, Waite Group Press, 1997, p. 559-569. If the website uses a combination of HTML forms and Javascppt functions, a simulated Web client with a modified Javascript interpreter could effectively register the? I or execute the transaction following the access / transaction process of Pl for the particular Pl or the transaction respectively. The process of access or transaction to be followed would be obtained from the particular Pl record or the transaction in the Vendor 320 container. The Javascppt interpreter in the simulated Web client will follow this procedure and supply it with the data found in the 360 user storage. A similar process could be used if the PI provider on the website uses a Java applet. A Web client with a modified Java byte code interpreter could effectively access the PI or execute the transactions following the stored process for the particular PI or transaction in the 320 Provider storage. The byte code interpreter will supply the data from user storage 360 instead of requiring interactive input from the end user. If the provider's website uses a combination of forms, scppts and applets, the previous individual procedure could be used in communication to achieve the desired access. In a preferred embodiment of such automated access or transactions, any necessary cookie data would be accepted and stored as necessary by the access / transaction component of Pl 340. In many cases, the cookie data is specific to the transfer and therefore to the little long-term utility. The generated cookies are only used during those functions, they are discarded once the operation or the transaction operation is completed. In order to provide the personal information to an end user quickly after the connection, it is necessary that the access / transaction component of Pl 340 select an end user for data collection before connection to the end user. One approach to this solution is to update the entire Pl of the end user provided that the end user, directly and through an intermediary Web site, requests access to their Pl. Another approach would be to update the entire PI of the end-user supplied by a particular provider, provided that the PI of that provider was requested. Therefore, the action of connecting within the system by an end user effectively selects its end user for the immediate Fl update. However, this approach can result in the inefficient iso of the resources of the Pl 240 system. Given the large number of potential users and providers, and the objective of providing the most • possible data, another modality? Ncl? \ E an algorithm developed to optimize the: program in which the end users are selected for recclection of data from a provider. These algorithm factors in the provider's update policy, the user's connection habits and the account characteristics of the provider-user. The appropriate application or algorithm should ensure that the Pl is collected as infrequently as possible for a given user, thus minimizing the consumption of system resources. On the next occasion of updating the provider and the next expected user connection, they can be identified in a precise manner, and a model can be created that will allow a smarter collection. Instead of collecting data from all the users of one provider at a time when you update your site, the collection can be dispersed over time based on the expected connection times of the users and the activity profiles of the network. For example, s_ provider A updates his site on Friday night and a large number of users of that provider are not expected to connect again until Monday morning, the collection load can be distributed for several days. This has the sale to minimize the peak load of the Pl 240 system, as well as the supplier's bandwidth consumption by the Pl 240 system. To achieve this optimization, the Pl 240 system must maintain and rethink the models of each provider and user. Such data can be maintained in the storage of the provider 310 and the storage of the user 360 respectively. Each time a user uses the Pl 240 system, the time and date can be captured. Once a sufficient number of connection hours are accumulated, they can be analyzed with respect to the day of the month, day of the week and day of the day. These are used in a model to predict the next expected user connection. The model is then tested and refined with subsequent connections to a measurable degree of reliability that is established. Once a high degree of confidentiality is determined, the user model is incorporated into the adaptive collection scheduler. Until a high level of confidentiality is reached for a particular end user, one of the aforementioned collection approaches can be used. Each provider updates its site based on the oolitica driven by its unique resources and its business model. For any adaptive programmer to work with, each provider's policy must be modeled. In some cases, the policy is self-evident. In others, it must be determined empirically. [A provider policy will most likely fall into one of the following categories: Type I. Periodically updated for all The users . Type II. Regularly updated in relation to each user. Type III Updated in a pseudo-random way. The following three approaches can be used based on the type of provider. Type I Provider Policy Programming Algorithm.
I. Assume users with a model "without confidentiality" that has an immediate connection time. I. Sort users chronologically based on their predicted connection time. 3. Diverts the expected connection time for all users. 4. Execute a density curve that fits along the time limits to obtain a polynomial function that can be used to determine the number of user accounts to collect during a given time.
. Execute an integral coupling algorithm with the inverse of the activity curve of the Network for the period in question in order to adjust the distribution curve, d. If possible, redistribute the peak collection time to time 0 to standardize the distribution curve. 7. Assign collection times to the users classified according to the distribution curve. 3. Monitor the time and collect the user account when appropriate. Type II. Supplier Policy Programming Algorithm. For each provider that falls into this category, an attribute of the user must be identified that determines when the personal information is updated. In some cases, the user may need to be consulted for information. In others, it can be determined from the information collected. If the attribute can not be established for a user by these means, the provider's site can be monitored daily for changes in personal information until a pattern is established. Since this is a uniform and natural distribution of accounts updated by a provider for a given day, a user account can be collected one hour before its expected connection time. As in the type I algorithm, users with a non-confidential model should be collected immediately. Type III Provider Policy Programming Algorithm This type of policy is the most difficult of all, that the provider updates a user account in a non-deterministic way, a decision must be made for each provider for the critical degree of information regarding to user. For those highly critical providers, each user account must be collected daily, perhaps even more frequently. For those less critical suppliers, user accounts should be collected less frequently and possibly when the overall activity of the system is low. The supply component Pl 3a0 is responsible for formatting and supplying the PI to the end user. The supply will usually occur only after the update of the entire PI. The PI will be supplied to one or more destinations (eg facsimile, telephone, sorter, Web browser, e-mail, etc.) as specified in the 360 user storage except when the PI is accessed through an intermediate Web site. When the destination is not an intermediate Web site, the provisioning component Pl 350 executes all the necessary formatting to deliver the Pl to the appropriate destinations. For example, when the destination is a Web browser, the PI will be formatted as an HTML document, or when the destination is a telephone, the PI will be forwarded for synthesis and voice transmission. In the case of an intermediate Web site, the Pl is supplied in a format that is configurable by the intermediate Web site. FIGURE 5 illustrates a possible mode of the current invention using an intermediate Web site. A final user 210 uses a client computer 220 to access an intermediate Web site 510 through the Internet 230. The end user 210 connects to the intermediate Web site 510. The intermediate Web site 510 contacts the system Pl 240 to _raves from Internet 230 and directly receives the updated end user's Pl as required from the Pl 250 provider Web sites. The intermediate Web site 310 receives the Pl, it incorporates it into sagins according to its particular formatting style and graphic user interface / provides these pages to the end user 210. The use of the Pl 240 system is transparent to the end user. In addition, an intermediate Web site 510 serving the aggregated PI to an end user 210 may, and most likely, simultaneously serve as a PI provider. In another embodiment, this -ormate occurs through an HTML generation system. dynamic that combines the information of style and distribution from a variety of sources. The supply component Pl >; 50 generates HTML pages in a dynamic way. These pages are customized based on a number of style factors (such as color of color, forehead color, font size, color and style, page layout, etc.) and a variety of sources and Content from a variety of sources. Information providers, distributors, the end user, the supply component of? I30 or any combination of those sources or other relevant sources can provide the personalization factors used in the generation of the page. Finally, each HTML page must be filled with data. The data used in such pages may originate from sources such as information providers, distributors, the end user, the PI 350 supply component or any combination of those sources, or other relevant sources. The solution _ equerida is a system that represents a generic algorithm to execute such HTML generation in run time. The style and content can be provided in a suitable format such as the Extensible Stylesheet Language (XSL), as specified by W3C at http: // www. 3. org / TR / WD-xsl /, which is expressly incorporated herein by reference in its entirety, and / or the E'tensible Markup Language (XML) as specified by W3C at http: //www.w3 .org / TR / REC-xml, which is expressly incorporated herein by reference in its entirety or any other suitable formatting standard. The key requirements for such a system are the complete encapsulation of the domain of the problem and the efficiency of the running time. In the preferred embodiments, the solution is based on the following basic model as illustrated in FIGURE 8: 1. Six sets of personalization factors are identified: The content of the distributor 810, the content of the provider 820, the style specification 830, the style specification of provider 840, the user-specific content 850 and the specific style of user 860. 2 Each set of customization factors 810-S60 is considered as a separate, independent entry required for the run time system 870 that executes dynamic page generation. 3. Each entry 810-860 will be in the form of an XML stream. 4. Output 880 will be in the form of an HTML stream.
. The dynamic page generation system 870 would produce the valid output 880 for each set of six valid entries 810-860. FIGURE 9 illustrates a real run time sequence of the input processing of such system 870: 1. The content of the distributor 810 is combined with the content of the provider 820 and with the user-specific content 850 to produce a full content specification. 930 mediating the content merge link 910. The 830 distributor style is combined with the 840 vendor style and the 860 user-specific style to produce a full 940 style specification using the 920 content merge unit. 3. The style specification 9'0 is applied by the 950 style applicator to the content specification 930 in order to produce the resulting page 880. In order to fully encapsulate the domain of the problem, the following requirements should be placed on the system 870: Each XML entry 810-860 is a valid XML stream. 2. All content specifications 810, 820 and 850 are valid with respect to the same Document Type Definition. 3. All style specifications 830, 840 and 860 are valid with respect to the same Document Type Definition (such as XSL DTD stagnation). The 910 v 920 combination units whose task it is to take two or more XML streams and produce a combined XML output must be able to produce such output for any valid set of XML entries. Another method for executing this task would be to format the Pl as HTML elements with predefined CLASS attributes. The intermediate Web site that receives these elements could include them dynamically in the page sent to the final user of the Pl. Pages that incorporate these elements could include the ethyl information associated with the predefined CLASS set. The cascading style sheet convention of level 1 could be used to implement such configuration capability. See Kerven, Foust, Zakour, HTML 3.2 Plus HOW-To, Waite Group Press, 1997, p. 651-693; Walsh, "An Introduction to Cascadmg Style Sheets," World Wide Web Journal, Wmter 1997, p. 147-156. This option requires minimal programmatic support through the intermediate Web site, although the flexibility of the Web sites is restricted to a certain degree in the presentation of it. Pl to the end user. Alternatively, an intermediate Web site could develop an application that uses a standardized programming (API) inferior to directly access the Pl data. In this case the Pl 350 supply component could be diverted or potential used as the component responsible for In this model, the intermediate site could be responsible for all the formatting decisions with respect to the original PI data.This implementation option requires additional programmatic support through the intermediate Web site although it allows Greater reliability in the use of the original PI The ability to use an intermediate Web site to provide Pl is of significant utility This capability allows an end user already familiar with an existing PI provider to access not only the Pl associated with the Private Pl provider. But all the Pl of all the other suppliers with the convenience of a to be inferred from common user, that is, the Web site cte existing supplier. In this situation, the request for Pl originates directly with the website of the intermediate PI provider and indirectly from the end user. Security measures would restrict access to the authorized intermediate Web site. This mecada could include verification of the end user and the intermediate Web site. In addition, verification of the association between the end user and the particular intermediate website should also be required for additional security. In addition, the use of an intermediate Web site also supports a novel transaction model. In this transaction model, the intermediary site fully subsidizes or compensates the Pl system administrator for the services provided to the end user. These transactions are facilitated through the audit and tracking capabilities of the Pl system. These capabilities allow the calculation of rights per user, rights per transaction, rights for access or some combi ^ acion d ^ the same to be determined. Determined values could be directly loaded ^ 1 intermec Web site _ c. Alternatively, such values could be credited to an initial monthly fee charged to the Web site with any rights beyond the minimum directly addressed to the intermediate Web site, FIGURE 11 shows a flowchart of a typical process. According to the described model, the intermediate website pays a minimum monthly fee in step 1110. In step 1120, the system "I audits and tracks the use of the end user through the intermediary website." Audited use is used to determine a fee on a per user, per access, per transaction or combination basis In step 1130, this audited amount is charged to the rights paid in step 1110. In step 1140, the intermediate website is loaded to Any rights in excess of the minimum fee payment Often an end user may require access to the underlying Web page generated by the provider of a particular piece of Pl. The supply can deliver not only the Pl but also an access point directly to the provider's page that provides that Pl. The access point can take the form of an inculus, a shape button or some other interactive access mechanism. Such an access point significantly improves the efficiency of access to the underlying page of the end user as shown in FIGURE 7. In the traditional process 100 for accessing the DI, the end user must proceed through numerous intermediate pages that require a variety of frequently tedious interactions before reaching the desired page. The end user must first identify the provider 110. Next, the end user must locate the web address of the provider 120. Then, the user requests the connection page of the provider 130. If the end user does not remember the information of the provider. requirement, this information must be found, or the desired information will remain inaccessible through the Web. The end user then browses the provider's website 140. This often authorizes a visit to the provider's home page 710 followed by the observation of a variety of intermediate pages on the provider's site 720. The end user may have to return several times to the homepage 710 or accidentally exit the system by completely forcing a second connection 140 before finally locating the desired information 150. Using the trampoline technology, the complete process 750 is streamlined at the simple click of an access point. The supply component of the Pl system provides an access point to the sub-supplier's page together with the PI. As a consequence, r-end user only needs to execute an individual interaction with the presentation page Pl 760. This interaction immediately executes the requirement interactions with the website to the provider to take the user to the desired underlying Web page L50. In a modality, this trampoline technology could be implemented using a Java applet. With respect to FIGURE 2, the applet could be downloaded from the Pl Host 290 by the end-user client software 27, usually a J ^ by explorer executed locally by the end user's computer 220. The applet would drive the software from client 270 to the desired page. rpal applet could recover the procedures and data to drive the client software from the storage of Provider 310 and the storage of User 360. In an additional mode, the system Pl 240 could act as a server pro * - _mo directly accessing the storage of the client. Provider 310 and the storage of 360 user as required. When the system Pl 240"ecibe the request to jump to the source of a particular piece of Pl, the system executes the necessary actions to navigate to the necessary page and sends the desired page to the computer of the final isuario 220. Additional interactions with the page pi eclen requires the additional approximation of the Pl 240 system as the cookie data that may reside in the Pl Host 290 accumulate. This mode is limited to the use in the handling of standard HTTP traffic instead of the secure HTTP traffic. preferred, the trampoline provides the end user with the automated connection within the site of the provider Pl 250 and allows the end user 210 to navigate through the client software 270. This automated connection could be achieved through the use of protocol redirection Hypertext Transfer Protocol (HTPP) Upon receipt of a trampoline access request from the end user 210 or more of the client software 270, the Pl Host 290 requests the connection page of the Pl 250 provider site directed by the trampoline access. The Pl 240 system operating on the Pl Host 290 receives this connection page and makes a connection request by accessing the appropriate data in the storage of Provider 310 and the storage of User 360. The connection request is embedded in the HTTP redirect which is sent to the client software 270. The client software 270 is redirected to the target PI provider site 250 and the end user 210 is automatically connected within this site. Alternatively, this functionality can be implemented by means of a Java apple as described above. In addition, the Pl 240 system can generate a Javascppt page containing the connection request: - relevant ion instead of an HTTP reclirection. The Javascript page can be returned to the client software 270. This page could then be executed by the client software 270 to achieve the automated connection. The system Pl 240 of FIGURE 3 may also include a processing component 370 of the site monitor. This component systematically monitors the Web sites of the provider Pl supported for the changes. This component improves the ability of the system to identify alterations in the website procedures of the PI provider, the data requirements and the cookie requirements. This component increases the efficiency of the system by providing or supplanting alteration identification by means of feedback from the access / transaction component of Pl 340. An additional embodiment of the present invention can support localized manipulation of Pl. This could be achieved when the client software 270 that operates on the client computer 220 in FIGURE 2 is a specialized Web client instead of a Web client such as Netscape. This specialized client can use the Web channel technology to automate the download of local Pl and update processes. When the storage of Pl is implemented through the aforementioned cookie architecture, this specialized client can provide direct local access to the stored PI. In another embodiment, the Pl 240 system of FIGURE 3 can support the PI providers supported by the system as well as the specific PI providers of the particular end users. In this mode, an inal user is not limited to the Pl available from the suppliers of Pl present in the storage of Provider 310. For an end user to add the PI provided by an unsupported PI provider, the end user you must access the base line 320 configuration component and create a configuration for the unsupported Pl provider. The provider Pl and the configuration Pl together with the access verification data would be stored together with the user record in the user storage 360. An additional embodiment of the present invention supports the inclusion of Pl transaction procedures and access requirements in the Storage 310 of FIGURE 3. The end-user-specific information necessary to perform such a repeat transaction with the user record in the user storage 360. The functionality of the access / transaction component Pl 340 could be expanded to support the performance of the transactions. This additional functionality could be supported in a manner similar to the above described procedure with respect to access performance using a simulated Web client. An additional feature of this invention would include automated or semi-automated account management by providing actuator events to automatically micromance a transaction. For example, with reference to FIGURE 2, an end user 210 could be able to keep his accounts in .mea through the Pl 240 system. If a information provider has the ability to receive online payments, the Pl 240 system could support the complete or partial automation of such transactions. If there is a billing due date for a certain information provider, the Pl 240 system could signal that information and send the email to the end user 210 notifying him of his invoice due date. Therefore, the user will not have to verify each of their suppliers individually for the expiration date information.
The Pl 240 system could also automate payments in a limited range of the amount of fatimation for providers that allow payments on their Web servers 260, then sending an email to the user with payment notification. The acquisition of expiration date could be achieved using the access / transaction component of Pl 340 observed in FIGURE 3. The expiration date information would be available to the end user through any means of delivery supported by the supply component of Pl 350. The access / transaction component Pl 340 will use the standard e-commerce invoice payment methods to pay the user's invoices to the supplier if he selects it. Once the invoice is paid, then an email notification will be sent to the user with the provider information and payment information. The user can specify the range of the amount stored in user storage 360 that will be paid automatically. If the invoice exceeds the amount specified by the user, then the Pl system will simply send an email notification to the user instead of paying the invoice automatically. The modalities described above are given as illustrative examples only. It will be readily appreciated that many deviations can be made from the specific embodiment and described in this specification without departing from the invention. Accordingly, the scope of the invention will be determined by the following claims instead of being limited by the modalities specifically described above.

Claims (28)

  1. CLAIMS 1. A system for delivering personal information from at least one provider and information to at least one end user characterized in that it comprises: (a) a user storage to store the end user data associated with each end user; (b) a provider storage to store the information provider data associated with each information provider; (c) a storage of personal information to store personal information associated with each end user; (d) a processor in communication with the user storage, the storage of the provider and the storage of personal information, to execute the steps of: (i) connecting with at least one information provider; (ii) for a selected end user, retrieve the personal information for the selected end user from at least one connected information provider based on the end-user data associated with the selected end user and information provider data associated with one or more connected information providers; and (iii) store the personal information recovered in the storage of personal information.
  2. 2. The system in accordance with the claim 1, characterized in that the processor executes the additional step of monitoring the information providers for the changes.
  3. The system according to claim 1, characterized in that the processor executes the additional step of updating the provider storage to conform to the requirements of the information provider.
  4. The system according to claim 1, characterized in that the processor executes the additional step of executing a transaction for the selected end user with a selected information provider based on the end user data associated with the selected end user and the information provider data associated with the selected information provider.
  5. The system according to claim 4, characterized in that the processor automatically executes the transaction execution step according to the end user data in the user storage.
  6. The system according to claim 1, characterized in that the processor executes the additional step of issuing the personai information associated with the selected end user from the storage of personal information.
  7. 7. The system in accordance with the claim 6, characterized in that the transmission stage executed by the processor issues the personal information to a delivery platform specified in the end user data associated with the selected end user.
  8. 8. The system in accordance with the claim 7, characterized in that the specified delivery platform is selected from the group consisting of email, facsimile, pager, telephone, wireless device, ftp server, Web server, gopher server and Web client.
  9. 9. The system according to claim 6, characterized in that the processor emits the personal information by means of a global network site.
  10. The system according to claim 9, characterized in that the processor issuing stage outputs the personal information as a Web page formatted for the world network site.
  11. The system according to claim 9, characterized in that the stage of the issuance of the processor emits the personal information as it was formatted in the Web elements to the site of the world network.
  12. 12. The system according to claim 9, characterized in that the emission stage transmits personal information data to the world network site.
  13. The system according to claim 1, characterized in that the processor connection stage executes the following sub-steps: (A) accessing the end user data associated with the selected end user; (B) identify the information providers identified in the end user data accessed; and (C) establish a communication link with each of the identified information providers.
  14. 14. A method for delivering personal information to at least one end user from at least one information provider comprising the steps of: (a) connecting with at least one information provider; (b) for a selected user, retrieve the personal information for the selected end user from at least one connected information provider based on the end user data associated with the selected end user and the provider data associated with one or more connected information providers; and (c) store the personal information retrieved in a personal information storage.
  15. 15. The method according to claim 14, characterized in that it also comprises the step of monitoring the information providers for the changes.
  16. The method according to claim 14, characterized in that it also comprises the step of updating the provider storage to comply with the requirements of the information provider.
  17. 17. The method according to claim 14, characterized in that it further comprises the step of executing a transaction for the selected end user with a selected information provider based on the accessed end user and the access information provider associated with the selected information provider.
  18. 18. The method of compliance with the claim 17, characterized in that the execution stage is activated according to the access user data accessed.
  19. 19. The method according to claim 14, characterized in that it also comprises the step of issuing the personal information accessed with the end user selected from the storage of personal information.
  20. 20. The method according to claim 19, characterized in that the transmission stage transmits the personal information to a delivery platform specified in the access user data accessed.
  21. The method according to claim 20, characterized in that the specified delivery platform is selected from the group consisting of e-mail, facsimile, pager, telephone, wireless device, ftp server, Web server, gopher server and Web client. .
  22. 22. The method according to claim 19, characterized in that the emission stage emits the personal information through a site in the world network.
  23. 23. The method according to claim 22, characterized in that the issuing stage issues the personal information as a Web page formatted for the world network site.
  24. 24. The method of compliance with the claim 22, characterized in that the issuing stage issues the personal information as Web elements formatted for the world network site.
  25. 25. The method according to claim 22, characterized in that the transmission stage transmits personal information data to the global network site.
  26. 26. The method according to claim 14, characterized in that the connection stage comprises the sub-steps of: (i) accessing the end user data associated with the selected end user; (ii) identify the information providers identified in the end user data accessed; and (iii) establish a communication link with each of the identified information providers.
  27. 27. A computer readable digital storage device that stores executable instructions which cause a processor to deliver 'personal information by executing the steps that are characterized by: (a) connecting with at least one information provider; (b) for a selected user, retrieve the personal information for the selected end user from at least one connected information provider based on the end user data associated with the selected end user with the selected end-user data and information provider with connected information providers; and (c) store the personal information retrieved in a personal information storage.
  28. 28. The storage device according to claim 27, characterized in that it also stores executable instructions for executing the connection stage by executing the sub-stages comprising: (i) accessing the user data; end associated with the selected end user; (ii) identify the information providers specified in the end user data accessed; and (iii) establish a communication link with each of the identified information providers.
MXPA/A/2000/006480A 1998-10-28 2000-06-28 Apparatus and method for automated aggregation and delivery of electronic personal information or data MXPA00006480A (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US60/105,917 1998-10-28
US60/134,395 1999-05-17

Publications (1)

Publication Number Publication Date
MXPA00006480A true MXPA00006480A (en) 2002-05-09

Family

ID=

Similar Documents

Publication Publication Date Title
AU737572B2 (en) Apparatus and method for automated aggregation and delivery of and transactions involving electronic personal information or data
US8768833B2 (en) System and method for syndicated transactions
US8260706B2 (en) System and method for syndicated transactions
US6871220B1 (en) System and method for distributed storage and retrieval of personal information
US7490135B2 (en) Method for providing node targeted content in an addressable network
US7558795B2 (en) Method and apparatus for tracking functional states of a Web-site and reporting results to web developers
US8069407B1 (en) Method and apparatus for detecting changes in websites and reporting results to web developers for navigation template repair purposes
MXPA00006480A (en) Apparatus and method for automated aggregation and delivery of electronic personal information or data
EP1107125B1 (en) Apparatus and method for automated aggregation and delivery of and transactions involving electronic personal information or data
MXPA00005913A (en) Apparatus and method for automated aggregation and delivery of electronic personal information or data
JP2001147893A (en) Device and method for automated aggregation, device and method for delivering electronic personal information or data and transaction including electronic personal information or data
JP2001147892A (en) Device and method for automated aggregation, device and method for delivering electronic personal information or data and transaction including electronic personal information or data
JP2001142905A (en) System and method for automatically accessing personal information
AU4721000A (en) Apparatus and method for automated aggregation and delivery of and transactions involving electronic personal information or data apparatus
CA2308242A1 (en) Apparatus and method for automated aggregation and delivery of and transactions involving electronic personal information or data
AU4720900A (en) System and method for automated access to personal information
WO2001086543A1 (en) System and method for syndicated transactions
WO2001025873A9 (en) Method and apparatus for completing a form