WO2001013259A1 - Service personnel a plate-forme web et systeme - Google Patents

Service personnel a plate-forme web et systeme Download PDF

Info

Publication number
WO2001013259A1
WO2001013259A1 PCT/US2000/022369 US0022369W WO0113259A1 WO 2001013259 A1 WO2001013259 A1 WO 2001013259A1 US 0022369 W US0022369 W US 0022369W WO 0113259 A1 WO0113259 A1 WO 0113259A1
Authority
WO
WIPO (PCT)
Prior art keywords
resident
site
information
service
personal
Prior art date
Application number
PCT/US2000/022369
Other languages
English (en)
Inventor
Gideon Hazam
Joshua Peleg
Giora Eyran
Original Assignee
Iradius. Com, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Iradius. Com, Inc. filed Critical Iradius. Com, Inc.
Priority to AU69074/00A priority Critical patent/AU6907400A/en
Publication of WO2001013259A1 publication Critical patent/WO2001013259A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/954Navigation, e.g. using categorised browsing

Definitions

  • the present invention relates to online interactivity, and more particularly to a web-based personal platform service that provides customizable, personalized portable services.
  • 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'sTM 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.
  • the users' specific security prices and related alert thresholds may be monitored continuously throughout the day.
  • the service provider 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.
  • 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.
  • 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.
  • a foreign machine i.e. a machine that the user does not use on a regular basis
  • 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.
  • 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.
  • bookmarks do not provide a method to by-pass the tedious login and complex site navigation procedure.
  • Favorites and Bookmarks are stored locally on a given machine and are thus not available when the user logs in from a foreign machine.
  • John Doe who has a checking account with the Bank Of New YorkTM. John wants to know whenever his checking account balance drops 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.
  • 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.
  • John 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.
  • 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.
  • IP Internet Protocol
  • WAP Wireless Application Protocol
  • ISP Internet Service Provider
  • 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).
  • a central location i.e., centralized deployment
  • distributed 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.
  • 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.
  • 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.
  • VPN Virtual Private Network
  • each one of the local servers contains its local residents' specific information, application set and data.
  • 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”.
  • Tele-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
  • 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
  • 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.
  • 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
  • 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
  • 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.
  • FIG. 18 shows the server/client push mode message flow according to one embodiment of the present invention DETAILED DESCRIPTION OF THE INVENTION
  • 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.
  • 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.”
  • 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.
  • 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.
  • 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
  • All the communications above may include any digital media such as text, voice, audio, video, and multi-mode.
  • 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
  • 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.
  • every household has a pre-defined web Site. The first time a potential user registers with the
  • 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.
  • FIG 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.
  • 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.
  • 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.
  • FIG. 5 illustrates the process of establishing effective locality according to one embodiment of the present invention.
  • user A. Smith may register as a new Resident of a Local Community Server 300.
  • 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.
  • ELD process Effective Locality Definition process
  • 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.
  • Step 353 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.
  • 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.
  • Step 355 the latitude and longitude of the Resident's locality.
  • Step 355 the latitude and longitude of the Resident's locality.
  • the locality information is stored within the Local Community Server database 358 and the ELD process terminates 359.
  • Geo-content Many types of locality related information or Geo-content, such as
  • 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.
  • the Resident's stored locality information 358 may be used to aid the Resident in accessing various web- based services.
  • 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.
  • 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).
  • 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.
  • 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 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)).
  • domain name e.g., .com for US (1), .co.uk for the UK (44), .co.il for Israel 972
  • 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.
  • 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
  • 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.
  • the service provides a unified communication identifier.
  • 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.
  • FIG. 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.
  • 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.
  • Receiver 601 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 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,
  • Step 703 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.
  • 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.
  • the Assistant@9734442233.iradius.com 862 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.
  • 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.
  • 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.
  • Figure 9 illustrates an exemplary logic flow for address error handling according to an embodiment of the present invention.
  • a Name Server 110 gets a message and resolves the Tel-URL Identifier.
  • 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).
  • Step 902 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.
  • Step 906 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).
  • Receiver 601 determines that the message will be routed to the valid household destination (step 908).
  • FIG 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.
  • a message is directed by the originator (XYZ Bank) to a specified Identifier.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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).
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • FIG 13 shows an embodiment of a hierarchical Dashboard event system with various exemplary categories that can be personalized by each Resident.
  • 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.
  • 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 VISATM 1324 categories are set.
  • Figure 13 shows representation for RED, YELLOW and GREEN indications within the established categories and subcategories.
  • the subcategory will reflect the appropriate indicator (RED, GREEN or YELLOW depending on the triggered threshold).
  • 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 VISATM 1324 are all GREEN, top-level category Finance 1320 will also be GREEN.
  • top-level category Finance 1320 will rise to YELLOW or RED, respectively.
  • 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.
  • 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.
  • 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.
  • the Resident may decide to use only YELLOW and RED indicators.
  • no lamp i.e., no color indication or change
  • a GREEN light in the previously discussed 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.
  • SNMP Simple Network Management Protocol
  • 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.
  • 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.
  • 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.
  • VRU Voice Response Unit
  • 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.
  • WAP Wireless Application Protocol
  • 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.
  • 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.
  • 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.
  • a Server Monitoring process 1510 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.
  • 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®), 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.
  • 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)
  • FIG. 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.
  • Step 1606 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.
  • the proactive agent 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • EBPP Electronic Billing, Presentment & Payment service
  • e-Bank service 1702 e-Bank service 1702
  • EBPP Electronic Billing, Presentment & Payment service
  • e-Bank service 1702 e-Bank service 1702
  • EBPP Electronic Billing, Presentment & Payment service
  • e-Bank service 1702 e-Bank service 1702
  • 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).
  • web service Monitoring 1711 for example EBPP flow
  • e-mail Alerts 1712 for example e-Bank flow
  • Direct Data Feed 1713 for example Real Time Traffic flow
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • events such as e-mail,
  • VEP notifications (as previously described) and other various communications, are gathered, on behalf of the Resident, by 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.
  • MTA Message Transport Agent
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé et un système pour la réalisation d'un service personnel à plate-forme Web (le « Service ») (150) sous forme d'un centre de coordination multidirectionnel basé sur le Web pour les diverses communications numériques d'un utilisateur. Les utilisateurs (157) dialoguent avec le « Service » (150) à différents niveaux, par exemple, en tant qu'individu, administrateur domestique, membre d'une famille ou membre d'une communauté. Le « Service » (150) est un réseau virtuel fournissant à des individus une identification Web globale unique ('Identificateur') permettant un accès direct spécifique (156) à des ressources collectives sans recherche ou navigation sur le Web.
PCT/US2000/022369 1999-08-13 2000-08-11 Service personnel a plate-forme web et systeme WO2001013259A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU69074/00A AU6907400A (en) 1999-08-13 2000-08-11 Personal web platform service and system

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US14889399P 1999-08-13 1999-08-13
US14889499P 1999-08-13 1999-08-13
US60/148,894 1999-08-13
US60/148,893 1999-08-13
US14954999P 1999-08-18 1999-08-18
US60/149,549 1999-08-18
US15112299P 1999-08-27 1999-08-27
US60/151,122 1999-08-27

Publications (1)

Publication Number Publication Date
WO2001013259A1 true WO2001013259A1 (fr) 2001-02-22

Family

ID=27495839

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/022369 WO2001013259A1 (fr) 1999-08-13 2000-08-11 Service personnel a plate-forme web et systeme

Country Status (2)

Country Link
AU (1) AU6907400A (fr)
WO (1) WO2001013259A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002100120A1 (fr) * 2001-06-07 2002-12-12 Nokia Corporation Reseau d'interaction dans lequel un abonne demande des services a partir d'un serveur.
WO2003001767A1 (fr) * 2001-06-20 2003-01-03 Intel Corporation Fonction de messagerie bidirectionnelle a distance via le web
WO2005008408A2 (fr) 2003-07-09 2005-01-27 Cisco Technology, Inc. Fourniture de service de telephonie modulaire
WO2005069581A1 (fr) * 2003-12-19 2005-07-28 France Telecom Procede et dispositif d'emission de requetes vers un serveur de noms de domaine depuis une machine requerante
US7640348B2 (en) 2001-09-21 2009-12-29 Corel Corporation System and method of managing access to web services
CN102843333A (zh) * 2011-06-20 2012-12-26 中兴通讯股份有限公司 业务嵌套的实现方法及装置
CN104767614A (zh) * 2014-01-03 2015-07-08 中国移动通信集团浙江有限公司 一种信息认证方法及装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107748764A (zh) * 2017-09-27 2018-03-02 合肥博力生产力促进中心有限公司 一种用于企业服务的远程辅助指导控制系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5572643A (en) * 1995-10-19 1996-11-05 Judson; David H. Web browser with dynamic display of information objects during linking
US5793966A (en) * 1995-12-01 1998-08-11 Vermeer Technologies, Inc. Computer system and computer-implemented process for creation and maintenance of online services
US5915096A (en) * 1996-05-31 1999-06-22 Sun Microsystems, Inc. Network browsing system and method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5572643A (en) * 1995-10-19 1996-11-05 Judson; David H. Web browser with dynamic display of information objects during linking
US5793966A (en) * 1995-12-01 1998-08-11 Vermeer Technologies, Inc. Computer system and computer-implemented process for creation and maintenance of online services
US5915096A (en) * 1996-05-31 1999-06-22 Sun Microsystems, Inc. Network browsing system and method

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002100120A1 (fr) * 2001-06-07 2002-12-12 Nokia Corporation Reseau d'interaction dans lequel un abonne demande des services a partir d'un serveur.
US6941337B2 (en) 2001-06-07 2005-09-06 Nokia Corporation Interaction arrangement for a sequence of interactions providing a service to a user
WO2003001767A1 (fr) * 2001-06-20 2003-01-03 Intel Corporation Fonction de messagerie bidirectionnelle a distance via le web
US7640348B2 (en) 2001-09-21 2009-12-29 Corel Corporation System and method of managing access to web services
WO2005008408A2 (fr) 2003-07-09 2005-01-27 Cisco Technology, Inc. Fourniture de service de telephonie modulaire
EP1649393A2 (fr) * 2003-07-09 2006-04-26 Cisco Technology, Inc. Fourniture de service de telephonie modulaire
EP1649393A4 (fr) * 2003-07-09 2009-01-21 Cisco Tech Inc Fourniture de service de telephonie modulaire
WO2005069581A1 (fr) * 2003-12-19 2005-07-28 France Telecom Procede et dispositif d'emission de requetes vers un serveur de noms de domaine depuis une machine requerante
US7961852B2 (en) 2003-12-19 2011-06-14 France Telecom Method and device for transmitting requests from a requesting machine to a domain name server
CN102843333A (zh) * 2011-06-20 2012-12-26 中兴通讯股份有限公司 业务嵌套的实现方法及装置
WO2012174866A1 (fr) * 2011-06-20 2012-12-27 中兴通讯股份有限公司 Procédé et appareil pour réaliser une imbrication de services
CN104767614A (zh) * 2014-01-03 2015-07-08 中国移动通信集团浙江有限公司 一种信息认证方法及装置
CN104767614B (zh) * 2014-01-03 2019-03-05 中国移动通信集团浙江有限公司 一种信息认证方法及装置

Also Published As

Publication number Publication date
AU6907400A (en) 2001-03-13

Similar Documents

Publication Publication Date Title
US7606864B2 (en) Setting and display of communication receipt preferences by users of multiple communication devices
US9503533B2 (en) Network manager system for location-aware mobile communication devices
US8868659B2 (en) Method and apparatus for automatic notification and response
CN101694660B (zh) 即时网站系统以及网站与即时通讯平台结合的方法
US7831670B2 (en) GUI interface for subscribers to subscribe to topics of messages published by a Pub/Sub service
US9002963B2 (en) System, method and computer program for recipient controlled communications
US7436947B2 (en) Method and apparatus for automatic notification and response based on communication flow expressions
US7904554B1 (en) Supervising user interaction with online services
US20140164959A1 (en) Server-Client Interaction and Information Management System
MXPA01011504A (es) Servidor de dispositivo movil.
KR20110038605A (ko) 가상 룸 및 대상물을 갖춘 pstn 및 온라인 홈 상의 개인 데이타 포탈
KR100979073B1 (ko) 자동 통지 및 응답 방법 및 장치
WO2001013259A1 (fr) Service personnel a plate-forme web et systeme
CN101563897B (zh) 用于统一特号映射电话簿存在服务的方法和设备
WO2007067528A2 (fr) Assistant numérique personnel et système de réponse automatisée
Salsano of Deliverable: Final system architecture specification
KR20020014620A (ko) 핸드폰 번호를 이용한 도메인과 이-메일 포워딩 시스템
WO2007053782A2 (fr) Plate-forme pour services de donnees et vocaux a optimisation telephonique

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP