WO2001013259A1

WO2001013259A1 - Personal web platform service and system

Info

Publication number: WO2001013259A1
Application number: PCT/US2000/022369
Authority: WO
Inventors: Gideon Hazam; Joshua Peleg; Giora Eyran
Original assignee: Iradius. Com, Inc.
Priority date: 1999-08-13
Filing date: 2000-08-11
Publication date: 2001-02-22
Also published as: AU6907400A

Abstract

The present invention provides a method and system for the implementation of a personal web platform service (the 'Service') (150) as a web-based multi-directional focal point for a user's various digital communications. Users (157) interact with the Service (150) on different levels, for example, as an individual, a household manager, a family member or a community member. The Service (150) is a virtual network providing individuals with a unique global web identify ('Identifier') to provide focused direct access (156) to community resources without searching or surfing the web.

Description

PERSONAL WEB PLATFORM SERVICE AND SYSTEM

FIELD OF THE INVENTION

The present invention relates to online interactivity, and more particularly to a web-based personal platform service that provides customizable, personalized portable services.

BACKGROUND OF THE INVENTION

There are several major types of user focused web services or web sites available today. Existing personal services include, for example, portal services, eCommerce services, communication services, community services, personal notification services, and time management services as will be described briefly below.

Portal services provide the user with access to subjects of interest based on textual menu navigation and searching through categorized and uncategorized subsets of database information. Once the user chooses a subject, he 'drills down', or searches for relevant information. The user's own skill and judgment, employed during the 'drill down' process, determines the quality of the search. Portal services are typically content-centric and require prior knowledge to maximize content relevance for usage. eCommerce services provide the user with the facility either to buy or bid on certain merchandise. ECommerce is similar to an on-line version of a published catalog or store display. Goods purchased on-line often cost less than $50 and do not require specific attendant service, such as books, CDs, wine, perfume, software, etc. eCommerce services are still very limited in potential fulfillment of current marketplace needs and desires, and traditional shopping in the local community is still the preferred consumer choice.

Communication services are basic services available in networks, including, inter-alia, the Internet. They comprise various forms of electronic messaging and/or notification, an example of which is 'e-mail'. The standard addressing technique for such purposes is typically the same for all types of networks including Local Area, Intranet, Extranet and Internet. This standard technique generally uses the format: [user name]@[domain]. com or [user name]@[domain].net where "user name" is a combination of letters and numbers chosen by the user or assigned by the service provider, based on market availability, to be unique within that "domain". "Domain" is the name reserved for the e-mail, web or other server as a unique entity in the Internet.

Community services include, for example, an on-line version of a published magazine, where certain topics are presented from various viewpoints, including general information, product marketing, communication, commerce, advertising, etc. Community services are typically subject interest centric, and do not support physical locality.

Personal notification services provide notification based upon specific inquiry, or interest, as with, for example, an 'opt-in' service where users sign up for messaging services. Many services today notify a user with data related to a specific inquiry made by the user. These services typically use existing e-mail or similar messaging transmission. Examples of these services include stock alerts, account balance alerts, newsletter distribution, etc. Such services are neither persistent nor consolidated, thus message priority and time sensitive information may be lost. An example of an e-mail alert is Charles Schwab's™ alert service.

Alerts may be requested for changes in a security's price, earnings or volume. For example, a user could set an alert that would notify the user when a stock's price drops or rises by a given amount or percent. Through the particular service provider, such as Schwab™, the users' specific security prices and related alert thresholds may be monitored continuously throughout the day.

The service provider (for example, Schwab™ for stocks, Chase Manhattan™ for banking, etc.) may have an Alert Response System, which can be automatic, manual or a hybrid of the two, which scans the user's specific inquiry or thresholds against the existing data in the service database. When the system sees an input meeting the criteria set by the user, the system sends an e-mail message to the user. Regardless of the response, the user may continue to get such e-mail messages, as long as the system finds compliance with the users specific alert criteria.

If the user accesses his account from a foreign machine (i.e. a machine that the user does not use on a regular basis), he is required to remember his account's login details. In addition, the user risks leaving important personal data directly related to the security of his accounts on the foreign machine, in the form of a "cookie," or other configuration file maintained on the foreign machine.

Time Management services are typically linked with information management. The more efficiently information is managed, the better time is managed. People use or "visit" Internet web sites to satisfy various needs, such as to gather information, perform transactions, and other such purposes. Therefore, users often have arrangements or accounts with many providers of web-based services. Since e-mail is the current method for notification, users typically are required to provide an e-mail address when registering for accounts. In using the various services, the consumer hopes to improve his quality of life, productivity, and the quality of his decision-making processes. The users' effort spent in managing the dispersion of services and related personal information, works against the productivity desired in using the online services.

The above mentioned systems and services have disadvantages and shortcomings, including cost of management, limited portability, lack of effective locality, restricted name availability, lack of intuitive addressing, and lack of effective notification, among others.

Cost of management: In order to use various on-line services to manage personal information and coordinate daily life activities, the user may need to interact with many sites. This requires the user to register with individual services, remember complicated site-specific access information and potentially log the related information and specific services for each site. This dispersion of required information challenges the overall productivity of the user since it requires the user to remember a lot of related data and forces the user to perform tasks in a serial fashion, directly increasing the cost of management. This trend is directly opposed to the purpose and cause of better life management for service users. Existing services do not provide the level of personalization necessary for the user, or provide the consolidation and integration of all desired management features into one offering. Additionally the frequent change of e-mail address by many Internet users requires them and their contacts to continuously maintain and update information to avoid disconnection's.

'Favorites' and 'Bookmarks' typically used in web browsers to obtain access to various web sites cannot bring the user to the actual point of interaction with a given on-line service provider. The bookmarks do not provide a method to by-pass the tedious login and complex site navigation procedure. In addition, Favorites and Bookmarks are stored locally on a given machine and are thus not available when the user logs in from a foreign machine.

Limited portability: Due to a lack of security, a sophisticated user often avoids conducting sensitive personal transactions (e.g. financials, communications, etc.), from a foreign machine. In this case, true application portability, and thereby some measure of efficiency, is sacrificed. 'Cookies', Browser History, Browser Auto-completion Scripts or files stored locally on a PC, are used by many sites to store user specific personal access information, certain login procedures and preferences. Cookies and other such local access trace files may be left in machines that are available to unauthorized persons thus compromising security.

Lack of effective locality: Existing Internet services typically do not put the current integrated local community on-line. Existing Internet services typically cannot help a user solve a specific household problem, for example, a leaking roof, so that the user avoids a tedious local search process using, for example, the Yellow Pages and the local social network (word of mouth).

Restricted name availability: With existing communications services, choosing a particular user name is subject to availability. In many cases a new user joining a popular communication service will be unable to use his actual name as his service access name, especially for the more common names. Users may be forced to choose less desirable alternative names, or be assigned non-intuitive addresses, such as commonname2346@carrier.net, as is commonly done by many Internet Service Providers ("ISPs") and communication providers when commonname@carrier.net has been taken. Lack of intuitive addressing: Several disadvantages are also apparent from the perspective of a potential sender of e-mail to a communication service user. Non-intuitive addressing may cause problems for a sender who does not have an accurate spelling of his intended recipient's network communication service address. For example, John Doe II maybe assigned a network communication address of jdoe234@prodigy.net. A potential sender would not necessarily possess knowledge regarding the suffix "234".

Another issue arises from the inherent sensitivity to the top level domains, such as ".com", ".net", ".org" and ".edu". Communication service providers often employ the top level domain ".com" and people have become accustomed to its usage. However, many communication service providers also use the ".net" top level domain. Sending a message to a particular user thus requires the sender to possess knowledge of the intended recipient's entire user address. Furthermore a general disadvantage is apparent in that such standard communications techniques address individuals in a single-tier or direct manner. In many cases the potential sender knows the intended recipient's name, but not the correct spelling, or knows the intended recipient's phone number but not the recipient's e-mail address.

Furthermore, it is often difficult to effectively manage e-mail addresses in various e-mail software clients, thus making it difficult to keep track of the intended recipient's address. Senders of e-mail often experience difficulty due to the lack of intuitive addressing. Lack of effective notification: Typical communication services fail to provide the user with efficient and effective means of notification as a function of the personal importance of the received information. Current services suffer from the lack of specific channels and methods of notification and typically require the user to manually sort through large amounts of information in order to capture the truly important and significant communications.

Consider, for example, user John Doe who has a checking account with the Bank Of New York™. John wants to know whenever his checking account balance drops below $3,000. Once the BONY™ alert system notices that John's account balance has dropped below $3,000, the system sends John a direct mail to his e-mail address, jdoe234@xyzl23.com. John gets an indication from his e-mail provider, for each unread message in his e-mail box. Typically, John receives many messages in a given day. The messages may relate to various activities in which John is engaged, including other internet activities, work, push-type direct advertising, so called 'Spam' e-mail, pleasure, family & friends and other information and infotainment type services. In response to this torrent of information John must regularly log in to his e-mail service provider, access the mail server and manually process each individual mail entry in order to find out who sent each e-mail message and for what purpose. It may require significant effort just for John to identify that BONY sent a message, but John still doesn't know the purpose of the notification unless the bank specified such in the subject line. John must open the message, read it and then act accordingly.

Such direct communication techniques have several disadvantages. For example, there is no user control over information screening, personal analysis or message priority. In fact the message priority is set by the sender of a particular message rather than by the intended recipient. There is also a lack of intuitive presentation of potentially critical data. Additionally, the user is often forced to pursue a long interaction process in order to get to the "bottom line," that is, to get to the desired information or to reach desired locations of the web. Important and time critical information may be lost or delayed amidst the pile of daily mail. If the user is not present, unavailable or does not have convenient e-mail access, he may miss critical information and thereby miss the opportunity to react. Additionally current hard-decision (binary) alert schemes (i.e., yes or no) may actually act to increase the amount of unimportant information through increasing the 'false alarm' rate. Users typically are very busy, but still need the opportunity to respond to critical events in a timely and efficient way. Intelligent screening and direct presentation, as opposed to mere information brokering, may help users optimally balance the trade-off between efficiency and accuracy.

SUMMARY OF THE INVENTION The present invention is a personal web platform Service that includes various functions and features that provide advantages to its users. The Service may comprise multiple application servers and platforms supported by a communications channel for Residents (i.e. users) to access through the Internet.

The present invention provides web hosting for a web-based personalized Service, which provides full portability to a Resident who can access his personal web site ("Site") via any Internet Protocol ("IP") connected access device, including but not limited to a PC, a Wireless Application Protocol ("WAP") enabled phone or device, or any other IP enabled device, at anytime and from anywhere, through any Internet Service Provider ("ISP"). Portability is enhanced because of the secure implementation wherein personal information is not stored in the access device. All transactions involved with personal information are made through the web-based focal point or personal site of the Service and all personal information is maintained securely on the personal Site. Convenience and ease of use is enhanced because the Resident does not need to remember numerous personal details and various account information, but rather, needs only a single login via a single access code to the Service.

According to the present invention, each Resident has his own personal Site that he may customize to suit his needs. The personalized web site acts as a unique focal point and gateway to all web based services with which the Resident is or may be engaged. The Service also provides a personal focal point with the Resident possessing the sole privilege to access his own personal web site. Through his Site he may do anything that is directly related to his personal daily life and needs, including interactions, information access and communications. The Site serves as a personal assistant for daily life management and serves as a single point of control for the Resident's various existing on-line services.

The Service may be deployed, for example, from a central location (i.e., centralized deployment) or on a local basis (i.e., distributed deployment). In a centralized deployment, all of the Service and components of the system are located in a specific location. Localization of services to a Resident's particular community, region, or circumstance may be provided virtually by geo-coded database information management and specific geographical information aggregation. That is, the Resident will see services unique to his physical locality or community through database management of geo-specific information. In a distributed deployment the components of the system are distributed in various regions, countries, towns, etc. According to a first distributed deployment embodiment, the components at the various locations mirror the whole Service database by, for example, using data caching methods as are well known to those skilled in the art. Localization of services for Residents is provided similarly as in the centralized deployment, however, the distributed deployment facilitates rapid access and response for Residents virtually anywhere.

In a second distributed deployment embodiment, the physical local servers support only the database related to their geographical area. Regional servers may be networked, for example, via a Virtual Private Network (VPN) configuration, to provide global connectivity. In this case, each one of the local servers contains its local Residents' specific information, application set and data. Thus, each server has a primarily local nature and a related physical locality. The Service network is then realized via the interconnection of these disparate local servers. The following discussion refers to the second distributed deployment configuration in which each local deployment configuration contains the data only for the local area. The concepts discussed, however, are equally applicable to all other forms of distributed or centralized deployment methods.

A "Local Community Server" represents a community and aggregates local physical entities including families, businesses, and community organizations. The Local Community Server hosts its Residents for all daily life purposes including information processing, communications, local commerce and value-added services.

The Service integrates four major functionalities into one package: (i) Network, (ii) Local Community, (iii) Communications, and (iv) Productivity (time compression). The services and functionality is presented to each Resident through the Resident's personal Site.

The personal Site may be configured to include multiple distinct interactive functional "Rooms" into which services may be organized, and may include the features referred to as "Tel-URL", "Turbo Bookmark", "Dashboard", and "VIP Button".

"Tel-URL" refers to the employment of a Resident's Personal Identifier for any type of communication, defined by a unique telephone number related to the Resident. The overall communications processing and resulting

Resident directly to the 'point of interact on 'w t n the g ven we s te or serv ce.

The Dashboard feature provides one-way (web based sei ice or account to Resident) multi-state alerts for critical event notification as well as proactive personal information management and assistance. The VIP Button feature integrates both Turbo Bookmark and

Dashboard into an iconic representation of a two-way direct instant communication between the Resident and the account. The VIP Button closes the entire loop and provides full interaction assistance, proactive status monitoring, user configurable alerts, transaction management and relationship management. The Service is a seamless conduit designed to serve the desires and purposes of the Resident, allowing the Resident full control over his information flows. This is in direct contrast to legacy systems in which the Resident is treated as an appendage or terminal point connected to the edge of a vast impersonalized information network. The Internet, via the Service, becomes an effective and necessary media, more for its connectivity and ubiquity values than its globalization. BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other features and advantages of the present invention will become more apparent in light of the following detailed description of exemplary embodiments thereof, as illustrated in the accompanying drawings, where: Figure 1 is a diagram depicting a system layout according to an embodiment of the present invention.

Figure 2A is a representation of a prior art legacy information flow model. Figure 2B is a representation of an information flow model according to an embodiment of the present invention.

Figure 3 is a diagram depicting the personal platform Service of Figure 1 in more detail.

Figure 4 is a diagram depicting the nested structure and site according to one embodiment of the present invention.

Figure 5 shows a flow chart of a script programming process related to the Turbo Bookmark according to one embodiment of the present invention.

Figure 6 is a representation of functions in the message-handler part of the Local Community Server of Figure 1 according to one embodiment of the present invention. Figure 7 shows message routing nominal flow according to an embodiment of the present invention.

Figures 8A through 8C show different states of the system providing a combination and integration of online and offline communication according to one embodiment of the present invention.

Figure 9 is a logic diagram depicting an address error correction flow for communications, according to one embodiment of the present invention.

Figure 10 depicts a registration process according to one embodiment of the present invention. Figure 11 shows a logic flow diagram relating to the configuration of

Turbo Bookmarks for a Resident's Site.

Figure 12 shows the process by which the Service accesses desired web-based services as relates to the Turbo Bookmark according to one embodiment of the present invention. Figure 13 is an example of hierarchical event system related to the

Summary Lamp as part of the Dashboard, according to one embodiment of the present invention.

Figure 14 is a threshold-programming example related to a bank account presented on the Dashboard, according to one embodiment of the present invention.

Figure 15 shows a flow chart of a script programming process related to the Dashboard, according to one embodiment of the present invention.

Figure 16 shows the process by which the personal platform Service proactively gathers desired information from web-based services related to the VIP Button and Dashboard according to one embodiment of the present invention. Figure 17 is a representation of the disclosed multi-directional notification model as described under one embodiment of the present invention.

Figure 18 shows the server/client push mode message flow according to one embodiment of the present invention DETAILED DESCRIPTION OF THE INVENTION

As shown in Figure 1, an embodiment of the present invention includes Local Community Servers 131, 132, 133, 134 which are web servers that host local Residents and represent the community (or other defined region or working group) to the network 101 using the Internet 100. Access devices 121, 122, 123, 124 are presentation devices that allow access to the services provided by the Local Community Servers 131-134. The access devices 121-124 require minimal resources to establish the connection to the Service. Any type of Internet Protocol ("IP") device may be used, at any place, connected to the Internet by any means of communications. Local Community Servers 131-134 support the applications and services provided to the Residents. Network 101 is a cluster of Local Community Servers that are networked among themselves either via dedicated network means (such as WAN, extranet), or as an overlay on the Internet 100 or an Intranet. As shown in Figure 1 , the Invention may also include Name Servers 110, 111 to provide user address or user Identifier resolution functionality as will be discussed more fully below. A Local Community Server 131 is a device that provides the Service.

The Local Community Server 131 hosts personal Sites of the local Residents, as will be discussed in greater detail in reference to Figure 2B below. The Local Community Server 131 also supports and provides security required to assure secure access to applications and information according to assigned privileges, and supports community integration between the Residents. As shown in the prior art legacy information model of Figure 2A, the web user 140 subscribes to various web based services 141-146. Management of these services requires that the user manually access and poll each individual service. The user is forced to process large amounts of non-useful information in order to obtain useful information and produce the desired results.

Figure 2B shows an embodiment of the present invention where the personal platform Service and Site 150 creates a new information flow. The Service 150 gathers information from the various web-based services 151-155, and evaluates and presents it to the Resident. The Resident may access the information via a secure channel 156. The information is available through any type of web-connected device 157.

The personal Site 150 is hosted on a Local Community Server 131. The Local Community Server 131 may provide services and information that relate to the specific locality of the Resident or the "Localized Geo-content." Localized Geo- content may relate to any desired criteria, such as the Resident's ZIP code, area code, municipality, telephone number, local area exchange, school district, township or other such zone definition. One alternative is to allow the resident to specify a geographic location for which the resident desires Localized-Geo-content. Another method of creating Localized Geo-content may be achieved by geo-coding the Resident's address. For example, the Service might perform a reverse directory lookup based on the Resident's phone number, and then aggregate information that is related to the particular point on the globe and certain radius therefrom.

Personal Sites may communicate among themselves via e-mail, direct messaging, chat, message board, and other various digital medias without going outside of the personal platform Service (analogous to a local area network). Each personal Site 150 has a database that includes links, relationships, keys, and other relevant personal information related to the individual and his relationships with organizations, people and the community. This database may be provided individually or as a subset of a larger more comprehensive hierarchical structure of databases.

The personal Site 150 may be organized, personalized and customized by the Resident with the functionality and services provided by the Local Community Server 131. An exemplary method of organizing the personal Site 150 includes configuring the Site 150 into "Rooms." By way of example only, a Resident may obtain a personal Site 150 that includes a unique Personal Room, a Family Room, and a Guest Room, each Room customized for the Resident's use. The Personal Room may be for personal access and use, supporting personal or private applications, such as trading, banking, billing, messaging and communications. A contact book in the Personal Room may include personal contacts in addition to Family contacts, as may be defined in the Family Room.

The Family Room may be for Family access and use. It supports various applications that are typically shared by Family members, such as Family communications, information, publishing and collaboration.

The Guest Room may be for permitted Guest access and use. It supports various applications that may be shared with family, friends, neighbors and community, such as group communications, games, publishing, invitations, coordination and collaboration for community access and use.

Each Family member (as defined in the registration) has exclusive access to his Personal Room and shares with the other Family members equal access privileges to the Family Room. Family guests have controlled permission to access the Guest Room (i.e., time limited, application limited, limited number of visits, etc.). The personal Site 150 will typically include a default zone (which may also be customized by the Resident) automatically configured by the Service to define the household or Family's geographical area. This Town zone is an aggregation of geo-specific data and resources that are available to the local community Residents. Applications such as messaging, classifieds, transportation, local coupons, weather, traffic, local commerce, local yellow pages directory, local advertising, and other such community services are readily available within this Town zone . Access to the Town zone doesn't require special privileges. However, applications running and/or data presented in the Town zone are reflected into and from the Local Community Server that shares (among all Residents) public information, such as, for example, classifieds.

For each application within his personal site, the Resident may assign a level of security and designate a Room. The Resident may decide that access to a specific application, for example trading, requires an additional password key. The Resident may decide to duplicate a particular utility, for example billing, with his spouse, so that it may be operated from two separate Personal Rooms, via the same process. Communications may be established among different groups. For example, within the Family group, communications may be limited to the Family and may use common life metaphors for typical information staging areas, such as a mother posting a message for her children on the 'fridge door. Communication within the local community provides for communications of Residents that might, for example, be grouped according to the geographic region or township, etc. Such communication could include features as having teachers and parents communicate through a forum for posting messages (message board) or chatting. Other types of community communications can also be incorporated.

Communication within the Service network could include Residents of different Local Community Servers within the Service network. For example, a grandfather from Florida may communicate with his grandchild in New Jersey. Extra- network communications may also be established. Residents and non-Residents of the Service network could interact via the Internet. For example: Mother may send invitations to come and visit the Family's Guest Room to get directions for an upcoming birthday party, check the posted RSVP list and view the wish list posted in the Guest Room. In order to allow easy access to the Guest Room the invitation will include a built-in token or icon.

Communications capabilities implemented within the present invention include those to store & forward messages, such as e-mail; online communications, such as interactive chat or 'instant' messaging; and 'push' (defined as an asynchronous server initiated transaction or information transfer) technology and the

combinations thereof (for example, where direct messaging initiates a 'store & forward' session under certain conditions). All the communications above may include any digital media such as text, voice, audio, video, and multi-mode. In order to access his specific virtual client Site 207, the Resident invokes his Identifier and uses the provided services. An Identifier is a secure user identification means used to provide secure access for a specific Resident. The

Service 150 may not require more than minimal browser and or IP connection functionality on the part of the access device 200-204. The virtual client Site 207 actually acts as a personalized virtual IP device. The Resident only needs to identify himself once when first accessing the virtual client Site 207. All Site services, whether configured by the Resident or provided as a value added service of the Local Community Server 131 are subsequently accessed without the Resident being required to enter or remember the various individual service passwords or navigation details. This information is stored and supplied, in a secure way, to the specified web-based services 151-155 at the

Resident's command. The Resident may operate the personal Site functions by clicking a mouse, touching an active screen, talking to a voice-enabled entry device or other such data entry mechanisms as are known in the art. According to one embodiment of the present invention, every household has a pre-defined web Site. The first time a potential user registers with the

Service 150, he gains access to his Site. This Site includes default icons representing applications related to the Resident's Identifier, which, according to one embodiment, may be the telephone address or Tel-URL of the Resident's Site. As soon as the Family Site is created, the Resident may create related personal Sites for the individuals in this household.

Figure 3 illustrates the specific components of the Local Community Server 131. The Local Community Server 131 is composed of a database 205, specific applications and services 206 and Residents' Sites 207 hosted on the Local Community Server 131 as virtual client devices 207. The Resident may access his virtual client Site 207 from any place as long as he has access to IP connected access devices 200-204. The resources required on the IP connected access devices 200-204 are minimal and may be employed for presentation and Resident interface. All the Resident specific data, applications and services exist in the fully secured Local Community Server 131. Each IP connected access device 200-204 may have its own way of presenting the Resident Site 207. By way of illustration, various services and protocols may be employed, for example HTML/XML for browsers, WAP or WML protocol for smart-phones, Java for other IP connected devices and or other protocols as are known in the art.

For example, as shown in Figure 4, when user A. Smith registers as a new Resident of a Local Community Server 300, the Service 150 allocates the Family's Site 301 automatically. The hierarchical nature of the personal platform Service 150 is illustrated as the Resident adds members (J. Smith, I. Smith and B. Smith) to the Site 301. Each Resident is given a personal Site 302-305 nested within the Family Site 301. The personal Sites 302-305 are not independent, but are related in a hierarchical manner via the primary Family Site 301 Identifier or Tel-URL address. It is understood that there may be a plethora of Family Sites similar to the Smith Household Site 301 within a given Local Community Server 300. Each Household Site having its own set of associated nested Resident Sites and being uniquely configurable for each Household. Additionally there may be a plethora of Local Community Server Sites 300, 310, 320 each respectively having a plethora of Household Sites 301, 311, 321, 322. All such Sites may be linked together, via a virtual private network implementation, a WAN, a LAN, an Intranet, or other methods as are known in the art.

Figure 5 illustrates the process of establishing effective locality according to one embodiment of the present invention. As previously discussed, user A. Smith may register as a new Resident of a Local Community Server 300. As an integral part of a quick registration process, Resident A. Smith provides his household telephone number. The reception of this information initiates the Effective Locality Definition process (ELD process) 350 within the Local Community Server 300.

The first step of the ELD process is to perform a reverse look-up operation (step 351) on the submitted telephone number as is well known in the art.

Several pieces of relevant information may be obtained in this manner, such as the physical address and ZIP code associated with the submitted phone number, as well as a validity check (step 352) on the number itself.

If the submitted number is invalid, improperly formatted, unlisted with the available public directory, or already exists in the database, the Resident will be informed of the error (Step 353) and allowed to re-submit modified phone number information.

If the submitted number is valid, then Resident locality information is obtained, and the Resident may be asked to confirm or possibly modify the information (Step 354). If the Resident wishes to restart the process at this point, he may choose not to confirm the displayed information, but follow the re-submission path 353 as previously described.

If the Resident confirms the locality information, the Local Community

Server 300 will access a web-based geo-coding service (Step 355) to derive the latitude and longitude of the Resident's locality. Finally the locality information is stored within the Local Community Server database 358 and the ELD process terminates 359.

Many types of locality related information or Geo-content, such as

Yellow Pages information, maps, directions, local traffic, weather, etc., might also be obtained on behalf of the Resident. Geo-specific information may be obtained at registration, for example a map of the physical locality surrounding the Resident's address may also be provided via web-based map generation services (Step 357). Geo- content may be obtained per the Resident's specific inquiry, for example the Resident may request information on specific services, (plumber) within his geo-specific area. Geo-content may also be provided in a broadcast format, for example local weather or Traffic information. These examples are illustrative only, and it should be appreciated that numerous operations and or methods may be employed to similar effect.

Furthermore, as is also illustrated in Figure 5, the Resident's stored locality information 358 may be used to aid the Resident in accessing various web- based services. In one such example the Resident initiates a local services inquiry 360, such as a request to the Local Community Server 300 for "plumbing services" to obtain a plumber within his local physical area.

Within the Local Community Server 300, the Resident's stored geo- code data is retrieved (step 361). The Local Community Server 300 then automatically combines the stored geo-code information with the Resident's request and posts it (step 362). The results of this automatic effective locality service access are then displayed to the Resident (step 364). Thus the Resident is presented with information based on his request that is tailored by the Local Community Server 300 to the Resident's actual physical locality in a seamless and automatic fashion. Such examples are given to illustrate one specific embodiment of such an operation, and it is understood that a multitude of similar operations and or methods may be employed to beneficial effect.

According to one embodiment of the present invention, the Resident's Identifier is related to a household phone number and is referred to as the Tel-URL. The Tel-URL feature of the present invention provides a unified addressing concept that applies to the Resident's Site URL or domain 150 as well as to the Resident's personal communications and the Resident's connection to his Geo-specific information and collaborative groups . The system of the present invention, in various embodiments provides capabilities for, inter alia, (i) resolution and routing of electronic messages/notifications or URL resolution by centralized name servers which direct requests to a Local Community Server; (ii) recognition by the name servers of variations of the phone number based name to reduce possible mistakes in routing; (iii) error handling in the event that the requested name is not found by the system which will return the request to the sender; and (iv) default settings where, when a sender does not indicate a country code as part of the Identifier, the system assumes a default for in-country routing based on the URL's domain name (e.g., .com for US (1), .co.uk for the UK (44), .co.il for Israel 972)).

As an illustrative example, the Doe Family might be addressed by their telephone number as 12125551234@iradius.com (1-USA, 212-Region in NY, 555- 1234-a traditional 7 digit phone number). The Doe Family's URL will be: 12125551234.iradius.com. Resolution logic within the system will allow for variations to be recognized as the same URL or to be used as the same communications address. For example, hyphens, dashes and parenthesis may be included within the Identifier without causing failure or ambiguity. Thus, 1-212-555- 1234.iradius.com or 1(212)555-1234. iradius.com will resolve to the same address. Convenience features may be included within the Service network such that addressing someone by name and phone number only (without domain information) may be resolved by the Name Server 110, such as, entering <name>@<telephone number>. The Name Server 110 may resolve a local Resident, a remote Resident, or possibly a non-user of the Service who has an independent email. If the Service 150

2J finds an individual of <name> at the <tel-number> by, for example, reverse telephone look-up in a web based application, the Service 150 may prompt the Resident sending the message whether to proceed to an outside destination address. individual Resident John Doe of the Doe Family household will be addressed as john@12125551234.iradius.com for all types of communications and may have a hierarchical Site addressing Identifier or URL that will be john.12125551234.iradius.com. Thereby, the service provides a unified communication identifier. Other recognized URL variations may include, for example: http://iradius.com/ 12125551234/John; http://iradius.com/12125551234.John; http://iradius.com/12125551234\John; http://iradius.com l(212)555-1234.John; http://iradius.com l-212-555-1234/John; and httρ://iradius.com/(212)5551234/John.

The knowledge embedded within the Service database allows the aggregation and creation of a (virtual) local network, which provides the direct connection between the Family and local resources and community. It also provides the power of using traditional telephony behavior, when attempting to communicate with other Residents. For example, when using only seven E.164 formatted digits, the system recognizes a "local call" and automatically identifies the destination. If an area-code and seven digit number is provided, the system recognizes a "long-distance" call.

Figure 6 illustrates some components of the message handler of a Local Community Server 131, in particular those components relevant to messaging. Receiver 601 receives messages from the IP data network that utilize the related Local Community Server 131 domain name. Database 602 stores the full list of all residents related to this specific Local Community Server 131. By way of non-limiting example, Local Community Server number 1-201-973 may include all Residents that have the attributes of country code 1 (US), area code 201 and telephone exchange 973.

Router 605 transmits all messages from its Residents to others, either external or internal. Router 605 is also responsible for properly routing internal Local Community Server 131 to Local Community Server messages. Router 605 is also employed to properly route all messages sent by members of the Local Community Server 131 to other destinations in the network and over the Internet generally.

System manager 603 controls all information flow in the system, including activation of indications, alerts, statistics and more, integrity checker 604 checks the integrity of the received message against the Database 602, primarily for error recovery.

Figure 7 illustrates a nominal message receiving and routing flow according to one embodiment of the present invention. The flow will be described using the illustrative example of the specific sequence of actions performed when the Local Community Server 131 receives a message.

Upon receiving the message, according to one embodiment of the present invention, Receiver 601 checks the message's destination and determines whether the destination is the related Local Community Server 131 or a remote Community Server (e.g., 132, 133, 134). (Step 700) If the Receiver 601 determines that the related Local Community Server 131 is the destination, the Receiver 601 checks the validity of the Resident name in its related Database 602 (Step 701). If such a Resident exists, the Receiver 601 transfers the direct message to Router 605. Subsequently the message is transmitted via push mode to the destination Resident (Step 702). If the Receiver 601 determines in step 700 that the destination Local

Community Server is a remote one (in the Figure 1 example, any Local Community

Server except 131, for example Local Community Server 132), the message is transferred to Router 605 (Step 703) and the message is transmitted to remote Local Community Server 132 (Step 704) for delivery.

Figures 8A-8C show three states of a messaging service that integrates the so-called direct messaging with 'store & forward' messaging. One type of 'store & forward' messaging is, for example, e-mail. One embodiment of the present invention provides a unique combination of these two distinct forms of communications into a seamless application in that a Resident may be automatically directed to a 'store & forward' communications path due to the unavailability of the called party to respond to the request for direct communications.

In Figure 8A, John with Identifier john@2015551212.iradius.com 850 is attempting to contact Resident Sara with Identifier sara@9734442233.iradius.com 860 via the direct messaging mode of Service communications. John performs a CALL operation 851 specifying the destination Identifier sara@9734442233 which sends the CALL message 851 to Local Community Server 840. An address translation is performed as described in reference to Figure 7, and an ALERT message 861 is sent via the 'push' method to sara@9734442233.iradius.com 860. At the originating site 850, an indication, such as "Alerting . . ." is displayed in the Communications area 852. At the destination site 860, an INCOMING CALL indication ('Alert or Ring') is displayed along with an optional audible alert and the calling party identification information 861. If the direct communication call is IGNORED, has a TIMEOUT or a DND (Do Not Disturb),or is not picked-up for any reason, then the Service 150 may direct the call to the attention of the Assistant as indicated in message information field 862.

As shown in Figure 8B, the Assistant@9734442233.iradius.com 862, by way of non-limiting example, is a Service feature that automatically presents itself to the caller to convert a direct communication to a 'store & forward' communication. The Assistant 862 is one example of a method designed to smooth the transition for the caller from the direct to the 'store & forward' mode.

The Assistant@9734442233.iradius.com 863 responds to the caller john@2015551212.iradius.com 850 by sending an Answer message 864 back to the Local Community Server 840. This results in a Connected message 854 from the Assistant@9734442233.iradius.com 863 being sent back to John 850. At the destination site the Assistant 863 sends the caller any appropriate message, such as, "Hi. SARA is not available right now. May I take a message?" in the Communications area 852. If the calling party wishes to leave a 'store & forward' message, he responds to the Assistant 863 in the Communications area 852.

As shown in Figure 8C, if the caller John 850 wishes to leave a 'store & forward' message, he may enter it, in any supported media format, in the Communications area 852, to be stored for the called party 860.

Once the 'store & forward' operation is complete, the message (in this example text, though any supported media format may be used) is transferred to the Local Community Server 840. John is then disconnected from the Assistant. The Assistant 863 sends the stored message to sara@9734442233 860 as indicated by the dashed line 865. Sometime later, Sara may be notified, by a 'push' event, that there is a new 'store & forward' message waiting for her. The Assistant 863 may also pass some indication of the new stored message to Sara via, for example, the Communications area 862. Note that in this example, there is no need for John to perform two actions (i.e. one direct messaging action and one store & forward (email) messaging action - the system performs them both as an integrated end-to-end process). Figure 9 illustrates an exemplary logic flow for address error handling according to an embodiment of the present invention. At Step 900, a Name Server 110 (as referenced in Figure 1) gets a message and resolves the Tel-URL Identifier.

If the Tel-URL Identifier is not found, for example the name server 110 gets a message containing a Tel-URL (with country code and area code in compliance) that cannot be found in database 602, the system replies to the sender with an error message such as, "Unknown Destination" (Step 901).

If the Identifier Tel-URL is found in database 602, it is then determined whether there is a Resident name attached to the Identifier as a second level of addressing (Step 902). If the Resident name is specified, Receiver 601 has received a message with a correct Identifier, and verifies whether the Resident name is in database 602 (Step 903). If the Resident name is found, the message is sent to the Resident (Step 904). If the Resident's name does not exist in or comply with the database 602, the Integrity Checker 604 runs a cross-correlation function to recover from potential misspellings and generate a list of potential recipients of the messages (Step 905). An error message such as: "Family found. Unknown Resident. Do you want to send to the Household or to <list of correlated names>?" is displayed to the sender via Router 605 (Step 906). If the sender wishes to pick a name, then the request is routed to the specified Resident (Step 904). Otherwise, if the sender wishes to send to the Family (step 907) then the request is routed to the Family destination (Step 908). If the sender does not wish to send to the Family or household (step 907), then since the individual name was previously not found in the database at step 903, the reply "Unknown Address" is returned to the sender (Step 901).

If the family Identifier is found (step 900), but the Resident's name is not specified as part of the address (Step 902), then Receiver 601 determines that the message will be routed to the valid household destination (step 908).

Figure 10 describes the Tel-URL validation and registration process according to an embodiment of the present invention. A first time user will call the Service provider who provides the system of the present invention via, for example, a toll free number (Step 1001). A Voice Response Unit (VRU) will identify the user's caller ED (Step 1002), and verify that the Resident has been assigned a temporary unique Family Identifier in the Service database (Step 1003). Once this transaction is completed, an Identifier is permanently designated for the sole use of this Family (Step 1004). Each Resident in this registered Family can register himself by name and have his own password to access his private Site and messages. Any changes in registration information (for example, when a Family changes telephone number) will be handled via a maintenance process from within the Site itself.

Multi-tier Tel-URL based Identifiers may be implemented in alternative ways. For purposes of illustration, assume that Resident John Doe's personal Site hosts an application for his XYZ Bank Accounts. When the XYZ Bank sends a message to John Doe, the message will be routed to a third-tier address (first- tier may refer, for example to the Family address, second-tier to John's address within the Family, and third-tier to an entity defined within John's Private Room), predefined as "XYZ Bank Inbox". John Doe creates a related third-tier Identifier, such as XYZBank@John.12125551234.iradius.com. Any message received from the XYZ Bank will be directed to this entity. This may be achieved in alternative ways, two of which are presented here for explanatory purposes.

First, a message is directed by the originator (XYZ Bank) to a specified Identifier. Second, the Assistant 863 looks for a correlation between the simple message sent by XYZ Bank (through a cross correlation search or other such 'hash' search methods as are known in the art) and third-tier boxes. For example, if the sender address is info@XYZBank.com, the Assistant 863 is able to identify the sender from the "envelope" of the message, and resolve to send the message to John's third- tier address. Using fourth-tier addressing, it is possible to distinguish between, for example, a savings account and a checking account within the XYZ Bank. The messages can thus be routed to different boxes of the user. Fourth-tier message addressing may be implemented, for example, by running a key-word check on the "subject" or "text" of the message. The "Turbo Bookmark" feature of the Service 150 provides Resident's direct, single click, single login access to the point of interaction for their web-based services. The Turbo Bookmark feature eliminates the cumbersome experience of accessing web sites, remembering specific user-name, password, or other account information, and navigating to specific locations within a web-based service by, for example, scripting and storing a sequence of actions that can be recalled in order to access the specific point of interaction. The Turbo Bookmark script will maintain the Resident's personal and confidential account information in a secure area of the Service 150 (such as a secure portion of the Resident's personal Site) to insure the safety and integrity of the transaction. In this way, no personal information needs to be saved on the insecure access device used for the transaction. Since the script and Resident's secure information are maintained securely by the Service 150, the computer and web input device (browser), according to the present invention, can be a low resource terminal or so-called "thin client."

The Resident may choose an icon for each application the Resident wants the Service 150 to support. The Resident may also create customized icons, for example, by using publishing tools provided by the Service 150. Alternatively, the Resident may use prefabricated or so-called 'canned' icons. The Resident also may choose to protect a specific icon with an additional key or password protection.

Figure 1 1 shows three examples of how scripts or activation sequences of the Turbo Bookmark may be defined. The process of Turbo Bookmark definition begins with Step 1100. According to this embodiment, three options are presented to the Resident: (i) the self record mode, (ii) predefined service provider, and (iii) customer support assistance.

The self record mode begins with step 1101. The Resident performs a start "Record" mode action to authorize the automatic and silent detection of the sequence of steps performed by the Resident to accessing the desired application. The Service 150 observes the Resident accessing the web site (Step 1102), entering user name and password (or other registration process of a web service), and accessing the specific point of interest within the application that the Resident seeks. The Resident tells the Service when the "point of interaction" is reached and the "Record" mode is stopped (step 1103). The Resident is then prompted to choose an appropriate Icon for this Turbo Bookmark (Step 1104). The Service may provide these icons directly or from third party sources without affecting the operation of the Turbo Bookmark. The selected icon is then placed into the Resident specified category (Step 1105) within the Resident's Service Site 150. Finally the complete process is saved within the secure confines of the Local Community Server with which the Resident is registered (Step 1106).

Alternatively the Resident may select from a list of pre-defined applications. The Service may provide applications and the activation scripts for many common Internet based applications and services (e.g., on-line stores, billing services, trading services, and others). In this case the Resident will start from Step 1100 and then be presented with a range of pre-defined services and applications Step 1107. The pre-defined services and applications will guide the Resident through the required web registration process, which may be unique based on the needs and requirements of each individual service and service provider. For example, in Step 1108 the Resident is required to provide a user name and password. This is provided as an example and is not intended to preclude or include any specific service or services as is obvious to one skilled in the art. Once the required registration process is complete the Resident is taken to Step 1104. Where the Resident may accept a default icon specified by the service provider or choose another more personalized icon to represent the service. After selecting an icon, the procedure follows steps 1105 and 1106 as described above.

Furthermore the Resident may contact an on-line assistant or a customer support agent (Step 1109) who will take the Resident through a step-by-step process to establish the proper scripts (Step 1110). This method may be a collaborative effort in which both the Resident and customer support are on-line simultaneously. Once the collaborative effort is complete the Resident is again brought to the common Step 1104 and through the Placement Step 1105 and Activation Step 1106 processes. The Service according to the present invention keeps all the personalized information in the personal web Site 150 via Step 1106 and not in the Resident's IP Access Device 157. Therefore, when Secure Access 156 is gained from a foreign computer, the personal information remains secure on the personal web Site 150.

With reference to Figure 12 an example is shown of the process by which the Resident might use the Turbo Bookmark. The Resident may select a previously defined Turbo Bookmark, via an icon located within his personal Site to access a particular service (Step 1200). The Resident may activate the Turbo Bookmark (Step 1201) via, for example, a 'single-click' of an input device. This may be for example a mouse, active pointer or any other such device as is well known to one skilled in the art. Once the Resident has activated the Turbo Bookmark the predefined series of actions necessary to convey the Resident directly to the desired web service 'point-of-interaction' is executed. This may include the automatic generation of various passwords, user EDs, URLs, etc. as is obvious to one skilled in the art. The Resident is not required to re-enter any information. Saved Resident specific information is automatically sent to the desired web service (Steps 1202, 1203). The Resident is presented directly with the desired 'point of interaction' (Step 1204) following the execution of the Turbo Bookmark sequence. The "Dashboard" feature of the present invention provides a notification method and system for proactive personalized electronic alerts or "Summary Lamps." The functionality offered in the present invention includes an intuitive graphical user interface (GUI) to support critical decision processes; Resident-programmed data screening; and full portability. The Resident interfaces with the Service 150 from any EP enabled access device 157 such as a computer, pager, SmartPhone, etc. that will support Internet connectivity (as discussed in reference to Figure 2B). According to the present invention, the Resident experience is simplified by applying the Dashboard Summary Lamp method which uses hierarchical presentation of different Resident-selected categories. For example, as shown in Figure 13, the Resident may place his checking account balance 1321 as an application under the finance category 1320.

According to one embodiment of the present invention, the Dashboard Summary Lamp replaces the text rich e-mail notification of current schemes with a more intuitive graphical display. The Dashboard Summary Lamp indication scheme may use, for example, three states defined by the Resident, as his "comfort" zones. Three exemplary states may be: (i) a green lamp to indicate comfort and no action required, (ii) a yellow lamp to indicate caution which may prompt the user to evaluate account status, and (iii) a red lamp to indicate action is required.

These states are by way of example only. Their number, criteria and specific implementation may be modified and tailored for and by individual users without departing from the spirit and scope of the present invention.

A Resident will enter desired signaling criteria or thresholds for each of the defined states via an entry format such as the template portrayed (for illustration purposes only) in Figure 14, where the template is identified for programming a Checking Account 1400, and the Resident may specify account limit criteria for the various Red, Yellow, and Green Summary Lamp thresholds 1401. Additionally, the template may provide account balance information to assist the Resident in setting the threshold levels. 1402.

Figure 13 shows an embodiment of a hierarchical Dashboard event system with various exemplary categories that can be personalized by each Resident. According to thresholds established by the Resident for various categories either by template or other entry format, "top-level" category indicators or "Dashboard Summary Lamps" will inform the Resident of the current status of various subcategories of services which he uses. For example, in Figure 13, top-level Dashboard Summary Lamps of Travel 1310, Finance 1320, Education 1330 and Health 1340 are established by this fictitious Resident. Subcategories are placed by the Resident within the top-level categories. For example, under Finance, various checking accounts 1321, 1322, Savings 1323 and VISA™ 1324 categories are set.

The legend in Figure 13 shows representation for RED, YELLOW and GREEN indications within the established categories and subcategories. Using the above account balance illustration discussed with respect to Figure 14, when the account balance thresholds are triggered, the subcategory will reflect the appropriate indicator (RED, GREEN or YELLOW depending on the triggered threshold). As indicators in a subcategory rise in level of Resident specified importance, the top-level category itself will also rise in indication, to reflect the "Summary Lamp" behavior. For example, when Checking # 1 1321, Checking #2 1322, Savings 1323 and VISA™ 1324 are all GREEN, top-level category Finance 1320 will also be GREEN. When any one or more of the subcategories rises to YELLOW or RED, top-level category Finance 1320 will rise to YELLOW or RED, respectively. With reference again to the example previously given where John has a bank account with the Bank Of New York™ (BONY™), threshold values of, for example, $3,000 and $4,000 can be programmed by John for the RED (under $3,000) and GREEN (above $4,000) thresholds respectively. Other data, such as the minimum balance; monthly average credit, monthly average debit (not shown), can be provided by the bank. This data may be used by John to set his "Dashboard Summary Lamp" criteria.

With these sample threshold values, as long as the specified account has a balance over $4,000, the GREEN light is displayed. As soon as the account balance goes to any value between $3,000 and $4,000 the GREEN light goes off, and the YELLOW one goes on. As soon as the account balance goes under $3,000, the YELLOW light goes off, and the RED light goes on. These values are for illustrative purposes only and it will be understood by one skilled in the art that other values, subsequent logic and actions may be used. In the Education 1330 category, for example, John may choose to have the RED indication for a priority mail coming from his child's pre-school teacher 1331.

Various events may also be monitored by the Service 150. The Service 150 can receive e-mail notification of the availability of a Resident specified commodity or resource. This in tum can trigger a specific Dashboard Lamp or subsequent Alert notification. The Assistant may also act to trigger a Dashboard Lamp as a result of a Resident specified search or monitoring process. Additionaly many other types of communications may be processed by the Service and subsequently applied to the Summary Lamp of the Resident. In addition, the Service 150 can use "push" notification, targeted to any EP or non-EP communications device or media, to bring immediately to the attention of a Resident the occurrence of some event or condition.

In alternative embodiments of the present invention, the Resident may decide to use only YELLOW and RED indicators. In such a case, no lamp (i.e., no color indication or change) would be equivalent, for purposes of the present discussion, to a GREEN light in the previously discussed embodiment.

It should be obvious to one skilled in the art that various indications and effects may be used and substituted for the aforementioned colors and actions without departing from the spirit and intent of the present invention.

In a preferred embodiment, the Service 150 performs event analysis and translates the potentially content rich text messages into Dashboard Summary Lamp signaling for the Resident. Alternative implementations may skip the analysis part, where analysis is already done by the service provider 151, and a protocol may be used to communicate between the service provider 151 and the Service 150 in the format of, for example, SNMP (Simple Network Management Protocol) or some equally standard and effective protocol of messages.

In yet another alternative embodiment, the service provider 151 does all screening and translation and sends the signaling (using the Service 150) where Service 150 performs the role of a personalized distribution center or focal point to the Access Station 157, using for example GSM/SMS (Global Services for Mobile/Short Messaging Services) or other such applicable wireless data transmission protocol, where the Access Station 157 is required to transform the chosen protocol into the Summary Lamp presentation. Dashboard Summary Lamp updates can be implemented in several ways. In a preferred embodiment where the Service 150 is implemented, event signaling can be provided where: (1) the Service 150 can interrogate the service provider 151 at a pre-determined frequency (per Resident application), or in a real time per Resident request; or (2) the service provider 151 can employ 'push' technology to asynchronously send status changes and or alerts to the Service 150 on an event-triggered basis. Alternatively it may also cause the refresh of the information displayed by the Service 150 at predetermined time intervals.

The present invention offers solutions to the particular needs of a specific Resident. Such solutions may come in many configurations and appear as a combination of the above mentioned features and functionality, and will depend upon the specific needs of the Resident as will be appreciated by one skilled in the art.

In all cases and configurations, the Resident dictates the decision criteria, which may be updated by the Resident at any time either via the Access Station 157 or via an alternative channel, for example via a telephone VRU (Voice Response Unit) System.

In alternative embodiments, the signaling method of the present invention may provide features, functionality and/or channels to support portability, such as: paging notification; wireless messaging service (GSM/SMS, CDPD, etc.); and voice or Text-to-Speech call. Hand-held wireless devices and other types of low resource wireless devices, such as those employing the Wireless Application Protocol (WAP) may be used in the present invention to provide portability, and maintain efficient and consistent notification and communication capabilities.

In addition, the Resident defined programming/screening criteria may be expanded to incorporate parameters of other domains such as time, duration, spatial locality and other variations of physical factors and conditions.

By way of non-limiting illustrative example, if John's account is in the caution area (YELLOW lamp) for less than 8 hours, then the YELLOW lamp can blink or the prior state (GREEN lamp) will be prevented from changing to the YELLOW lamp state until the caution condition is present for more than 8 hours. Such additional domain factoring will minimize 'false' alarms and improve signal filtering and overall information quality.

The "VEP Button" feature of the present invention is a combination and enhancement of the previously described "Turbo Bookmark" and "Dashboard" features. Figure 15 shows an embodiment of the flow diagram for information and logic flow for the VEP Button functionality. As with the Turbo Bookmark, this embodiment of the VEP Button programming includes capturing a routine sequence of actions necessary to obtain access to a specific web service point of interaction.

The Residents' actions are recorded or solicited by the system, and a related script or program is created. Additionally, as shown in Figure 15 the created script 1509 is provided the capability (either through the recorded actions of the Resident or through pre-defined relationships between web-based service providers and the Service) to automatically poll and retrieve status or information, via a Server Monitoring process 1510, from the designated web-based service. As a further embodiment of the VEP Button feature the function of a

"Personal Assistant" 1506 is illustrated. This feature will comprise a set of proactive web-based functions that will actively seek out Resident specified information, content and status. In one example of such functionality the Personal Assistant may be used to proactively monitor the status of a particular information source, such as the local classifieds, for a Resident specified criteria or event, such as the availability of specific merchandise, (a 1997 Honda Civic), within a specific price range, (less than $7000). The Personal Assistant 1506 may comprise pre-determined or event- determined heuristic algorithms (so called "Turing machines") for the gathering and processing of Resident specified information. Such systems employ the Resident's chosen preferences and profile information in combination with the Resident's proxy and authorization to act in the Resident's behalf when accessing information or executing transactions on behalf of the Resident.

Furthermore, similar to the 'Dashboard' feature, a set of conditional thresholds and alert methods may be associated with each VEP Button. These thresholds and alert methods may be set in place by the actions of the Resident via, for example, interactive menus or forms, such as the described in reference to Figure 14.

The system relates each VEP Button script to a unique icon (step 1504)

which may be chosen by the Resident. This unique coupling allows smooth access from the icon to the point of interaction/execution, for example, by pointing and clicking once. The system also allows the iconic representation of the service to proactively present itself, in the form of a system-generated alert, "Dashboard Summary Lamp", message or other such proactive signaling form, so that the Resident has the option and ability to be informed of and act upon critical information in an efficient and proactive manner. Figure 16 shows an example of a program flow for the proactive notification and interaction system according to the present invention. The Personal Proactive Agent/Assistant process is invoked (Step 1600) to process a plurality of Resident defined web service signaling thresholds (Steps 1601, 1602, 1603) one or more of which may be associated with a single VEP Button. Resident defined signaling thresholds may be acquired by various means and in various formats. Resident instructions may be issued through the use of Service provided forms, as shown in Figure 14, through the interpretation of the Resident's natural language formatted instructions or as received through any other of the supported interaction media channels. The processing of a particular service threshold involves an individual Monitoring Step 1604 per set of threshold instructions. The threshold instructions may be any set of logical operations from a simple set of Boolean criteria to a complex series of 'fuzzy logic' processes designed to perform non-Boolean evaluation strategies. A single process or a multitude of processes, in parallel or serial fashion may execute these steps as is obvious to one skilled in the art. For the purpose of explanation one such Monitoring action is shown. The Monitoring Step 1604 proactively polls or otherwise receives or solicits information from the specified web service on behalf of and in the proxy of the specific Resident to whose personal site the specified web service pertains.

Monitored information may be gathered on a timed basis, at random or pseudo random intervals, at specific times during a given period or via 'push' methods. Many other methods may also be employed to gather the desired information without departing from the spirit and scope of the present invention. The information gathered is transferred in a secure and private manner.

Once the information is transferred (Step 1605), threshold processing (Step 1606) is performed on the gathered information. If the Resident specified thresholds have not been met, the processing returns to the monitoring state. If the threshold is met or triggered, for example the availability of a pair of tickets to a specific sporting event, a subsequent action is performed on behalf of the Resident to determine the preferred method or methods of notification (Step 1607) as specified by the Resident on a per service and per threshold basis. The preferred method of notification may be various and may take any form that is desired by the Resident. Various services and communication channels may be employed without departing from the spirit and scope of this invention. Upon determining the specified method or methods of notification, the proactive agent causes the notification to be sent to the Resident in the desired mode (Step 1608).

In Step 1609 the Resident receives an interactive notification. This notification may be received by various methods such as a low resource WAP compatible wireless device, or various other types of web compatible access terminals as previously described.

The generated alert allows the Resident to directly appreciate the status of the associated web-based service or information without requiring the Resident to manually access or poll for this information from the web-based source. The Resident may elect to act upon the generated alert, as is shown in Steps 1611 and 1612. Alternatively the Resident has the option of not acting, ignoring, delegating or other such reaction to the event, including cancellation of the event. All such actions, inactions or delegations are potential outcomes of the proactive notification. The flow diagram of Figure 16 is only one embodiment and is not intended to preclude other actions or responses to the proactively generated notification event.

All service parameters, including the Service as a whole, may be updated and modified at any time by the Resident. The Resident may configure the desired levels of security necessary to access and modify decision criteria and parameters. For example, a user may choose multiple levels of security for highly sensitive matters, and less security for non-sensitive matters.

With reference to Figure 17, the Service & Site 1700 of the present invention provides the Resident a personalized multi-directional focal point for information flow and transaction processing. It allows the individual complete control over the processing and routing of the events generated by his various web-based service providers. One embodiment of a feature of the present invention as depicted in Figure 17 is the Multi-directional Notification Flow model. The use of the Service & Site 1700 creates a multi-directional notification flow. The Service 1700 is actively engaged in gathering and processing information from the depicted web-based services 1701-1703. For the purposes of this specific example only, three services are depicted. It is obvious to one skilled in the art that any number of such services of any type may be so configured on the Residents' Service without departing from the spirit and scope of the present invention.

For the purposes of explanation only, three such services are shown: Electronic Billing, Presentment & Payment service (EBPP) 1501, e-Bank service 1702 and Real Time Traffic service 1703. Associated with each service is a particular information flow, as illustrated via the various line types and the attached notification key.

The three example flows of notification are, web service Monitoring 1711 (for example EBPP flow), e-mail Alerts 1712 (for example e-Bank flow) and Direct Data Feed 1713 (for example Real Time Traffic flow).

In the first example, notification flow, the Service has been instructed by the Resident to actively monitor, via web service Monitoring 1711, the status of a specific web-based EBPP service 1701. The Resident has further instructed the Service 1700 to generate notifications based on threshold criteria associated with this particular service (as described in reference to Figure 16). Notifications for this particular web-based service have been configured via the action of the Resident on his specific Service 1700 to be saved within his Personal Room.

Some later time the owner of this Site, ismith.2015551212, accesses the Service 1700 via Secure Access 1705 over the Internet. Saved notifications from the EBPP service 1701 are then presented to Mr. Smith via his current access device 1704. In this case the notification flow is via a 'store and forward' or 'time shifted' mode.

In the second example of notification flow, the Service 1700 has been instructed by the Resident to receive and evaluate standard e-mail Alerts 1712 sent by a specific web-based e-Bank service 1702. The Resident may further instruct the Service 1700 to re-direct the e-mail Alerts 1712 to the Personal Room 1509 of another trusted member of his immediate household, bsmith.2015551212 via the Service Internal Event Forwarding 1714. The notification is then saved within Ms. Smith's Personal Room until such time as Ms. Smith receives the notification via Secure Access 1710 on an access device 1708.

In this example the original recipient may transparently pass notification to the subsequent destination. It is also apparent to one skilled in the art that both parties may receive the notification or that subsequent logic may be applied to further escalate or redirect said notifications within the control of either the original or subsequent recipients.

The notification flow in this example is 'mirrored' or 'reflected' to another Service or Site as configured by the current instructions of the Resident but without his manual intervention in the process. In the third example notification flow, the Service 1700 has been instructed by the Resident to receive and parse, via Direct Data Feed 1713, web-based Real Time Traffic service alerts 1703. The Resident has, in this example, further instructed the service to direct these Traffic service alerts 1706 to his personal wireless access device or phone 1707. The notification flow is from the Traffic Service Site 1703 to a subsequent peer access device 1707. The original alert may be captured on the platform Service 1700, or optionally be merely passed through the peer device 1707.

The notification flow in this example is via the Service 1700 as a 'proxy' or 'gateway' to an alternate access device 1707. As is apparent from the diagram and the preceding explanation the

Service 1700 acts in various modes to provide a Multi-directional Focal Point for notification flow. The information is evaluated and presented to the Resident in a simple intuitive format using the disclosed methods. Furthermore, in all cases the Resident is accessing the information via a Secure Channel 1705, 1710. The notification is made available at any web-connected device 1704, 1707, 1708.

With reference to Figure 18, an embodiment of the Service 'push' data model is depicted. Other configurations of various functional blocks may be implemented in order to achieve similar functionality without departing from the spirit or scope of the present invention. Functional blocks are depicted both on the server side (i.e. above the dashed line) and the client side (i.e. below the dashed line) of the 'push' data model. The server side of the model may be implemented in the Local Community Server of the present invention. The client side of the model may be implemented within the client access device, which may be a PC or any other EP connected device. In the non-limiting example shown in Figure 18, events such as e-mail,

Dashboard, VEP notifications (as previously described) and other various communications, are gathered, on behalf of the Resident, by the Local Community Server. Within the Local Community Server the External Event Feeder 1862 is responsible for this operation. These various events are converted into standard transactions that are the basic data archetypes of the Service. Raw event transactions are sent first to the Web Server 1864 for formatting and processing. They are then transferred to the Application Server 1861. Events are transformed into 'push' type notifications 1863, if they meet the Resident criteria as indicated in the Database Server 1860. It is the responsibility of the Application Server 1861 to process the events, make the comparisons (if required) and generate the 'push' notifications.

The 'push' notifications 1863 are then sent to the Message Transport Agent (MTA) 1865 for proper transmission across the Internet 1870. Notification events are reformatted into Internet compatible 'push' events 1867 and given the proper addressing and format. They are then sent from the MTA 1865 across the Internet 1870 to the 'Push' client 1880.

The 'Push' client 1880 is a client side application, which understands how to respond and interface to the asynchronous nature of the 'push' events 1867 sent by the MTA 1865. It is also responsible for translating the events into local Online Client Application 1882 format. The Local Events 1881 are sent via a local client media to the Online Client Application 1882 where they are presented to the Resident as previously described.

The foregoing descriptions are presented to enable any person skilled in the art to make and use the described invention. Descriptions of specific applications or preferred embodiments of the features of the invention are provided only as examples. Variations and/or modifications to the preferred embodiments will be readily apparent to those skilled in the art, and the general principals defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the Invention. Thus, the unique features embodied within the present invention are not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein. Accordingly, it is not intended that the scope of the invention and unique features described above be limited by the above description but instead be determined entirely by reference to the claims that follow.

Claims

What is claimed is:

1. A method of providing an Internet based service, the method comprising the steps of: creating at least one personal site accessible to a resident through an access device; creating a unique identifier for the resident; and nesting the personal site within a family site.

2. The method according to claim 1, further including the step of: providing the family site with access to geographically relevant content.

3. The method according to claim 1 , wherein the unique identifier incorporates a telephone number.

4. The method according to claim 1, wherein the family site is automatically created when a resident registers for the Internet based service.

5. The method according to claim 3, wherein the family site has a unique identifier that incorporates the telephone number.

6. The method according to claim 5, further including the step of: creating personal sites for additional residents within the family site, wherein each additional resident has a unique identifier that incorporates the telephone number.

7. The method according to claim 5, further including the step of: providing access to each of the personal sites limited to one of the additional residents within the family site.

8. The method according to claim 7, further including the step of: providing access to the familty site to all of the additional residents.

9. The method according to claim 6, further including the step of: providing each additional resident with tools by which said additional resident may customize the personal site to which said additional resident has access with contacts, links, look and feel, and content unique to said resident's personal site.

10. The method according to claim 3, further including the steps of: providing a registration process that accepts the telephone number from the resident; and creating the family site with a family identifier incorporating the telephone number.

11. The method according to claim 10, further including the steps of:

performing a geocoding process on the telephone number to obtain geocoding information related to the telephone number; and

using the geocoding information to provide a local zone of content and services relevant to the geographic location associated with the telephone number accessible to the family site and the personal site.

12. The method according to claim 1, further including the step of:

providing access from the personal site to a third party site on the Internet.

13. The method according to claim 12, further including the steps of:

accepting resident information relating to the third party site; and

securely storing the resident information for access only by the resident.

14. The method according to claim 13, wherein the resident information includes the resident's login information for the third party site.

15. The method according to claim 13, wherein the resident information includes data from the third party site retrieved on behalf of the resident.

16. The method according to claim 13, wherein the resident information includes the point of interaction of the third party site.

17. The method according to claim 16, further including the step of:

delivering the resident to the point of interaction in response to a prompt by the user.

18. The method according to claim 17, wherein the prompt is a single click of an icon.

19. The method according to claim 13, wherein the resident information relating to the third party site is not stored on the access device.

20. The method according to claim 13, further including the step of:

providing access to the personal site only to the resident, to prevent unauthorized access to the resident information.

21. The method according to claim 14, wherein the step of providing access to the personal site includes verification of a password entered by the resident.

22. The method according to claim 12, further including the step of: providing a communication to the resident.

23. The method according to claim 22, wherein the communication to the resident is by text.

24. The method according to claim 22, wherein the communication to the resident is by voice message.

25. The method according to claim 22, wherein the communication to the resident is by rich media.

26. The method according to claim 22, wherein the step of providing communication to the resident concerning a third party site further includes the steps of:

accepting a parameter and a threshold level for the parameter relating to the third party site;

polling the third party site for the value of the parameter on the third party site;

comparing the value of the parameter with the threshold value; and

providing the result of the comparison to the resident.

27. The method according to claim 22, wherein the communication is an email from a third party.

28. The method according to claim 22, wherein the step of providing communication to the resident includes providing push notification to a device of the resident.

29. The method according to claim 28, wherein the device is a computer.

30. The method according to claim 28, wherein the device is a phone.

31. The method according to claim 28, wherein the device is an internet protocol device.

32. The method according to claim 12, wherein the Internet based service is provided independent of the access device used by the client.

33. The method according to claim 12, wherein the access device of the resident may be a thin client.

34. The method according to claim 12, further including the step of:

passing an alert from the third party site to the resident.

35. The method according to claim 12 further including the steps of:

accepting criteria from a resident; and

displaying resident information to the resident according to the criteria.

36. The method according to claim 35 wherein the criteria determines a relative importance of the resident information.

37. The method according to claim 22, wherein the step of providing a communication to the resident includes providing a combination of direct messaging and store and forward messaging.

38. An apparatus for providing Internet based services, the apparatus comprising: at least one local community server capable of hosting a plurality of residents, where each of the plurality of residents has a personal web site arranged in a hierarchy according to a criteria.

39. The apparatus according to claim 38 wherein the criteria is a family relationship.

40. The apparatus according to claim 38 wherein each of the plurality of residents has a unique resident identifier.

41. The apparatus according to claim 40 wherein the identifier is related to a telephone number.

42. The apparatus according to claim 38 wherein the hierarchy is a nested arrangement where the personal site of each resident is nested within a family site with which the resident is associated.

43. The apparatus according to claim 42, wherein the family site is nested within a community site wherein the community site relates to a geographic region and the resident is associated with the geographic region.

44. The apparatus according to claim 43 wherein the resident lives within the geographic region.

45. The apparatus according to claim 43 wherein the resident works within the geographic region.

46. The apparatus according to claim 43 wherein the resident chooses the geographic region.

47. The apparatus according to claim 43 wherein the personal web site of the resident and the family site are associated with the at least one local community server based on the geographic region.

48. The apparatus according to claim 41 wherein the resident registers for the Internet based service by entering a telephone number and the apparatus creates the resident identifier and a family site based upon the telephone number.

49. The apparatus according to claim 38 further including:

a name server for resolving internet addresses for the resident identifier.

50. The apparatus of claim 49, wherein the name server will resolve an internet address for a resident based on a variation of the resident identifier.

51. The apparatus according to claim 38 wherein the local community server provides the resident with access to third party sites.

52. The apparatus according to claim 51 wherein the local community server polls a third party site for information specified by the resident.

53. The apparatus according to claim 52 wherein the local community server provides a communication to the resident.

54. The apparatus according to claim 53 wherein the communication is an email from a third party.

55. The apparatus according to claim 53 wherein the local community server provides the information to the resident based on importance criteria supplied by the resident.

56. The apparatus according to claim 51 wherein the local community server stores a script for the resident, the script delivering the resident to a point of interaction on a third party site.

57. The apparatus according to claim 52 wherein the local community server stores threshold information provided by the resident and compares the threshold information to the information polled from the third party site.

58. The apparatus according to claim 57 wherein the local community server provides push notification to the resident based on the comparison of the threshold information to the information polled from the third party.

59. The apparatus according to claim 53 wherein the communication is a combination of direct messaging and store and forward messaging.