METHOD AND APPARATUS FOR AN INFORMATION APPLICATION PROGRAMMING INTERFACE
FIELD OF THE INVENTION The present invention relates to a method and apparatus for an information application programming interface (API) , and more particularly to a robust client-side portal application driven by a server-side user-created profile which dynamically generates customized content and functionality based upon user specified preferences.
Subscribers of Internet Service Providers (ISP's) and other Web-based Application Servers are expecting, and in fact demanding, that applications and other, services provided by their ISP/ s and application servers be more personalized and easier to use. That is, a subscriber wants to be able to readily see the information which he or she- has a preference for and be able to easily navigate through such information. In today's Internet marketplace, dissatisfied subscribers can easily change their Internet Service Provider or application server in the blink of an eye. Competition for subscriber loyalty has accordingly become fierce, with each new ISP and application server continually offering newer and more features to the subscriber. The increased competition and relatively low rate of subscriber loyalty has resulted in a high rate of turnover, or M churn", of subscribers. ISP's and the other web-based application servers have recognized this threat to -their businesses and have begun attempting to address the underlying -issues .
Initially, ISP's and application servers are attempting to analyze what it takes to create subscriber loyalty. For instance, in U.S. Patent No. 5,787,253, issued
July 28, 1998 to McCreery et al . , an apparatus and' method of analyzing Internet activity is presented. According to this patent, an Internet activity analyzer is arranged such that it receives a stream of data packets passing along the network medium. The packet of data is filtered and decoded and recompiled into concatenated transaction data which may then be stored. The translated data provides a high level informational profile regarding the network activity. However, while such analysis of the Internet activity may give an indication as to what a subscriber prefers, it does not help the ISP or application server in preventing the subscriber from leaving for another ISP and/or application server.
Accordingly, the ISP' s and other web-based application servers are utilizing what are known as application programming interfaces (API) to help monitor resources and unify multiple mechanisms for their servers. For instance, in U.S. Patent No. 6,026,440, issued February 15, 2000 to Shrader et al . , an account manager plug-in for a web server has' an API . The plug-in includes program coding for establishing sets of one or more monitored resources and for defining threshold rules for at least one of the sets of monitored resources. Thus as web transactions occur at ■ the web server, the account manager plug-in is responsive to a monitored resource exceeding a condition of a threshold rule. In this way, the web server may be responsive to some of the needs of the subscriber, however, this does not allow for presentation of information in a easy and readily accessible way. to the subscriber. Yet another patent utilizing an API is U.S. Patent
No. 6,026,426, issued February 15, 2000, to Badovinatz et al . , which relates to an API .that unifies a plurality of mechanisms into a single framework. The API includes a mechanism for communicating between members of a process group of related processes, and a mechanism for synchronizing the related processes of the process group. In this manner, processes may be effectively managed, however, again, presentation of
information to the subscriber is not effectively increased in a satisfactory manner to ensure subscriber loyalty.
Thus as can be seen, a need remains for an information application programming interface which will allow for increased performance and personalization, and which has a vpush" capability for subscriber personal preference information.
SUMMARY OF THE INVENTION Accordingly, the present invention provides for a method and apparatus for an intelligent information application programming interface (API) . Upon user/client registration with an information API computer server such as PortalVision, an informational/pref rence profile of the user/client is created, continually monitored, updated and stored on the server. The informational/preference profile can then be utilized when the user/client surfs the net" by the user's ISP and/or third-party application s.ervers . Profile- utilization includes integration of user preference information into the ISP's or third-party s .products and/or services. In this manner then, the web page content provided to the user is tailored to the user's preferences. Security is maintained by requiring user registration with the information application programming interface computer server. Such security can comprise a
Internet ID/password combination which the user is required to enter each time he or she begins Internet usage. Utilization of the user's informational/preference profile by the user's ISP and/or third-party application server can then be based upon proper authentication of the ID/password combination by the ISP and/or third-party application server with the information application programming interface computer server. In this manner then, the present invention allows the user to maintain overall access control to his or her informational/preference profile while still providing unlimited global access and response when so- desired.
The present invention, including its features and
advantages, will become more apparent from the following detailed description with reference to the accompanying drawings .
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 illustrates an architecture schematic for providing a robust client-side portal application driven by a server-side user-created profile, according to an embodiment of the present invention.
Figure 2 illustrates a flow chart of a method by which user preference information may be integrated into a client-side portal application, according to an embodiment of the present invention.
Figure 3 illustrates a communication flow chart of a method and apparatus for an information application programming interface, according to an embodiment of the present invention.
Figure 1 through 3 illustrate a method and apparatus for an intelligent information application interface which is capable of providing a robust-client side application, which application is driven by the user's informational/preference profile continuously updated and stored on the server-side.
Referring to Figure 1, an architectural schematic of an apparatus for providing a robust client-side portal application driven by a server-side user-created profile is shown. The portal application (e.g., a web-browser) resides on a user/client's computer 1. The user/client, through computer 1 and the resident portal application, enters/surfs the Internet/World-Wide-Web network 5 through their respective connection means 2 (which may include, but is not limited to, analog modems, ISDN, DSL technologies, broadband cable technologies, and/or wireless) passing through the ISP/data network 8 and may interact with such entities as the user/
client's Internet Service Provider (ISP) Services 3 or a third-party application Service/server 4. Such interaction is monitored by the PortalVision information application programming interface (API) computer server 6 and stored in an Internet User Data Repository 7 (also hereinafter referred to as a cache and/or memory) .
Currently, user network presence authentication occurs at the time the user requests access to ISP/data network 8 and subsequently Internet Access 5. This authentication is handled by the particular Internet Service Provider 3 the user 1 belongs to using an authentication database 9. Once the user is authorized, he or she is then seamlessly authenticated against the PortalVision Services 6 to gain access to their user data contained within the Internet User Data Repository 7. This process requires two sets of user authentication data. One such data ste resides within the ISP authentication database 9 and the other set at the PortalVision computer server 6 and Internet User Data Repository 7. Ideally, the ISP's could eliminate their user database 9 and rely solely on authentication services being- handles through the PortalVision. Services through the use of the PortalVision API.
Monitoring of the user/client's network interaction-, including both networks 5 and 8, which may be, but is not limited to, a functionality such as λλweb surfing", * chatting", λmessaging" , and/or downloading" , may be accomplished a number of ways. For instance, the user/client may be logged into ISP 3 or third-party application server 4 through the information API computer server 6, in which case the computer server 6 may monitor the transmission of the data through the server. Alternatively, where the user/client is logged-in directly to the ISP 3 or third-party application server 4, the ISP 3 or third-party application server 4 may send/link such user/client interaction information through the information API to computer server 6. It is to be understood, of course, that other such methods may be utilized to monitor user/client interaction on network 5 and such means are not to be limited
to those herein disclosed. Furthermore, it is also to be understood, of course, that the portal application, and/or the means by which the user/client connects to the network 5, need not be limited to being resident on computer 1, and that such application may reside on the network 5 itself or on some other entity (not shown) .
All interaction between computer 1, computer server 6, ISP 3 and application server 4 via networks 5 and 6 is by communication means 2. Communication means 2 may be any known or heretofore known communication means, such as, for instance, by hard-wired or wireless means. Further, it is to be understood, that the user/client's access to the Internet/World-Wide-Web network 5 need not be limited solely to a computer, and may instead be any means capable of transmitting, receiving and possible storage of data. For instance, such alternate access means may be by a portable telephone or pocket organizer.
Lastly, the apparatus of the present invention -includes appropriate storage capability for the applications and/or programs . User/client computer 1 has a cache/memory/ database 10 for storage of user/client applications and data, > while information API computer server 6 also has a cache/ memory 7 for applications and programs, as well as storage of the user/client's informational/preference profile. Computer server 6 may thus store, update and retrieve user preference profile information from cache 7 and may supply this information through network 5, via communication means 2, to ISP 3 and application server 4. It is to be understood, of course, that such data storage capability is not to be limited to that shown herein, and that data storage may instead, or in conjunction with, reside in other entities not shown.
Referring now to Figure 2, a flow chart of a method by which the user/client informational/preference profile may be integrated into a client-side portal application is shown. In step 10, registration of potentially involved parties with the information application programming interface (API) computer server occurs. Registration involves signing up for
the service, entering of necessary information (e.g., such as the uniform resource locator of an ISP, an e-mail account address, etc.), and possibly entering initial basic information for the user/client's informational/preference profile. For instance, a computer user/client will register with the information API computer server, such as Portal Vision, indicating that he or she desires that their Internet/ World-Wide-Web Λ surfing" and/or interaction be based upon an informational/preference profile either entered during the registration process or to be built, or even upon a combination of the two. In this manner then, the user/client will always receive, and thus be able to see and easily navigate, information which that user/client feels is pertinent to him or her, regardless of what website is visited. Furthermore, it is also possible in this step for the user/client's Internet Service Provider and/or third-party application server to register with the API computer server. In the case of an ISP and/or third-party application server registering with the information API computer server, the ISP and/or -third-party application server ϊs availing itself of the capability of providing personalized information .and/or services to the user/client. It is to be understood, then, that at a minimum only one of the potential parties need register with the information API computer server. In step 20, a registered user's surfing interaction is monitored such that the user's informational/preference profile is built. After initial registration and informational/preference profile input, an informational/ preference profile is built essentially from the user's surfing habits, that is, what information is repeatedly requested and/or which websites are repeatedly visited. It is to be understood, of course, that as the user's informational/ preference profile is being built and monitored, that the information API computex server may also retrieve from storage any previously built and/or monitored informational/preference profiles.
Accordingly, in step 30, as the user/client
continues to surf the Internet and the information API computer server continues to monitor and/or retrieve that user preference profile, in step 30 the informational/preference profile is stored and/or updated in the information API computer server cache/memory/database. Thus, the above steps allow for a user preference profile that is fluid, that is, as the user's preferences and/or surfing habits evolve and/or change over time, the informational/preference profile changes as well. As the informational/preference profile has been built, monitored, and updated as the case may be in previous •Internet/World-Wide-Web interactions, in step 40 the information API computer server will receive a log-in contact. Such log-in contact may come from any one of the various parties which has previously registered with the information API computer server. For instance, if the user/client has himself or herself registered with the information API computer server, the user/client may log directly into the information API computer server. Alternatively, the- user/client, whether or nor registered with the information
API computer server, may log into the Internet/Worl.d-Wide-Web through the user/client's Internet Service Provider or third- party application server. In this case then, the ISP or third-party application server will send a log-in contact to - the information API computer server. Such ISP or third-party application server log-in contact is a request for the user/client's informational/preference profile. Thus, it is to be understood, of course, that such log-in contact is not to be limited in the manner in which it occurs, and that a user/client may initially log into any Internet portal and/or may log into one Internet portal but visit others through engineered/embedded links. Thus, each website which the user/client then visits will contact the PortalVision information API computer server with a log-in contact. Thus, upon a user/client's interaction with the
Internet and the subsequent log-in contact with the information -API computer server, either directly from the
user/client or from the user/client's ISP or a third-party application server, in. step 50 security measures are implemented. Security measures may consist of a firewall or other known authentication procedure. For instance, if the user/client logs into the user/client' s Internet Service
Provider, the user/client is required to enter an ID/password combination for ISP access. The user/client's ISP then contacts the information API computer server transmitting such security information to the information API computer server. Alternatively, entering of a security key may be required, or a check of a pre-registered λwhite" list can be conducted. - Thus, in this manner then the information API computer server knows, based on a security check and/or the previous user/client and/or ISP registration that the user is authenticated. The same procedure holds true whether the user/client interacts with the Internet directly through the user/client's ISP, or through the information API computer server or third-party application server. The above security measures- thus allow an ISP or third-party application server to rely on the-, information API computer, server for authentication -and eliminates the necessity for -,them to develop and maintain a user database o their own.
In step 60 then, once security authentication has occurred, the information API computer server retrieves from its cache/memory the user informational/preference profile. Further in this step, the information API computer server continues to monitor the user/client's Internet interaction, noting any changes in the user's habits, requested/viewed information and/or website visits. In step 70 then, any such new information is updated and stored into the user/client' s informational/preference profile in the information API computer server cache/memory.
Upon log-in contact to the information API computer server, either directly- by the user/client or through the client's ISP and/or third-party application server, in step 80 the user informational/preference profile is integrated into the viewed web-page that the user/client is currently
visiting. Such integration can take a number of forms. For instance, the informational/preference profile can be integrated into the viewed web-page so that the user/client receives customized news feeds, e-mail/address book/calender 5. formats and updates, message boards and chat sessions, shopping searches/updates, and 'wallet" options. Furthermore, the informational/preference profile can be integrated into other -services such as e-commerce sales and map-requests. In an e-commerce situation it is particularly handy as the user/ 0 client's various credit card and shipping information is automatically integrated without having to have the user/ client re-type such information each time. Lastly, the information API computer server can instantly update the web pages being viewed by the user/client and/or update the user/ 5 client's resident applications. Such updating can occur as the computer server monitors the user/client's access bandwidth and makes decisions on the availability and speed with which such updating downloads can occur. In this manner then, the computer server can install new software features, 0 system- updates and bug fixes without -, interruption in the user/client'.s experience.. '..-- ;
Referring now to Figure 3, and as can be seen from the above, due to the possible methods by which integration and updating/storing/retrieval of the user/client 5 • informational/preference profile can occur, a communication flow chart for the information application programming interface is shown.
A user/client 100 can log into the PortalVision information API computer server 200 with log-in contact 0 message 101. Alternatively, it is to be understood that user 100 may log into ISP 300 with log-in contact message 102 or may log into a third-party server 400 with log-in contact message 103. In this manner then, user/client 100 is not limited to which website and/or computer server the user/client logs into.
Upon completion of the appropriate log-in contact message, a security measure is implemented. Such security
measure can be user 100 sending an ID/password combination to computer server 200 in security authentication message 110. As stated above, however, should user/client 100 have logged into ISP 300 or third-party computer server 400, then ISP 300 and/or third-party server 400 will send security authentication messages 310 and 410, respectively, to information API computer server 200. The computer server 200 will then check the ID/password combination received against that previously stored in its cache/memory. Such previous storing can, of course, have occurred during user/ISP/third- party server registration. It is to be understood, of course, that other security methods may be utilized, the intent being that the authentication of the user/client Internet/World- Wide-Web interaction occur. Likewise, a user's * friend" 500 may desire to retrieve and/or have sent to him/her profile information (e.g., address book information) of the user. In such a case a log-in contact from friend 500 may be received in log-in ' contact message 510. In such -'a case as this, the friend 500 may or may not have user 100's 'ID/password combination.
Accordingly, the computer server 2-00 -will internally check its registration 'white" list to ensure - that user 100 has placed friend 500 on the 'okay to receive" informational/preference profile information. Having authenticated through a security measure the validity of the informational/preference profile request from the ISP 300, third-party server 400 and/or friend 500, the computer server 200 will retrieve the informational/preference profile from its cache/memory. It will then send the profile for integration into the viewed web page of the ISP 300, third-party server 400 and/or friend 500 in informational/ preference profile message 220. Integration then occurs. In the case where the client/user 100 is viewing a web page being serviced by the ISP 300" or third-party server 400, this is sent to the user/client 100 in web page message 320 or 420, respectively.
Thus, as can be seen, the present invention allows
for increased performance and personalization of a website or application provided by a user/client's ISP or third-party application server. Furthermore, it allows a capability to 'push" user/client preference information from a central storage location to the user/client application side in essence giving the user/client 'presence" on the network. Furthermore, the present invention allows for continuous monitoring, updating, storage and retrieval of that profile. In the foregoing description, the method and apparatus of the present invention have been described with reference to a number of examples that are not to be considered limiting. Rather, it is to be understood and expected that variations in the principles of the method and apparatus herein disclosed may be made by one skilled in the art and it is intended that such modifications, changes, and/or substitutions are to be included within the scope of • the present invention as set forth in the appended claims. . The specification and the drawings are accordingly to be regarded in an illustrative rather than in a restrictive ■ ' sense.