Abstract:
An efficient and scalable real-time information distribution system and method of operation thereof are provided that build customized information collections according to individual preferences. This distribution system uses an information distribution network such as the Internet for its communications infrastructure. The system of the present invention is able to achieve high scalability and efficiency by routing information through the information distribution network. Information streams enter the information distribution network through feed processors. Feed processors, in turn, parse the information received from feed sources and create a set of “keyples.” The keyples are then passed on to a series of keyple routers. The keyple routers match the keyples to a set of destinations, thus multiplexing the keyples to only those destinations that have requested the information. A destination can consist of either another keyple router (which allows for the information distribution network to scale to a massive number of destinations) or a keyple customizer. A keyple customizer assigns incoming keyples to collections and then passes them on to a collection builder. A collection builder, in turn, constructs custom keyple collections for individual users.

Description:
CROSS-REFERENCE TO APPENDIX A 
     Appendix A, which is part of the present disclosure, contains a listing of segments of a computer program and related data, according to an embodiment of the invention. These listings of computer program contain material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the present disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. 
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates generally to information processing systems and, in particular, to information filtering and distribution systems. 
     2. Related Art 
     The Internet provides a forum for the distribution of information on a global basis. However, typically users are required to actively seek information either by specifying a given website or by performing a search of the information available on the world wide web. This model presumes that the user is already aware of the existence of the information. This model, therefore, does not provide a means for automatically distributing information to interested parties. To solve this problem several “push” technologies have been proposed by companies such as PointCast, BackWeb, and Marimba. These solutions store information in databases on servers, which are polled and queried for new information by the clients at periodic intervals. This architecture, however, has certain inherent disadvantages. First, the database-centric nature of the architecture limits system scalability because the database must repeatedly process user queries. Second, only limited customization of the information delivered to each user is provided since user queries must be kept brief and simple. Third, repeated polling results in a waste of communication bandwidth. Finally, because of delays introduced by the polling interval, these systems are not suitable for the delivery of time-sensitive information. 
     Email distribution has also been used to address this problem. However, while allowing for personalized information distribution, e-mail distribution of information does not provide fast distribution capability for time-sensitive delivery and dramatically increases the cost of distributing information over the Internet. 
     There is thus a need for a system for distributing information over the Internet that allows for both a high level of customization in the information distributed and timely delivery of time-sensitive information, without significantly impacting the cost of distributing information over the Internet. 
     SUMMARY OF THE INVENTION 
     The system and method of the present invention provide an efficient and scalable real-time information distribution system that builds customized information collections according to individual preferences. This distribution system uses an information distribution network such as the Internet for its communications infrastructure. 
     The system of the present invention is able to achieve high scalability and efficiency by routing information through the information distribution network. Information streams enter the information distribution network through feed processors. Feed processors, in turn, parse the information received from feed sources and create a set of “keyples.” The keyples are then passed on to a series of keyple routers. The keyple routers match the keyples to a set of destinations, thus multiplexing the keyples to only those destinations that have requested the information. A destination can consist of either another keyple router (which allows for the information distribution network to scale to a massive number of destinations) or a keyple customizer. A keyple customizer assigns incoming keyples to collections and then passes them on to a collection builder. A collection builder, in turn, constructs custom keyple collections for individual users. Finally, users can connect to collection servers and examine their collections, which contain only the information requested by the users. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram of a system for filtering and distributing information, in accordance to an embodiment of the invention. 
     FIG. 2A is a block diagram of a keyple, in accordance to an embodiment of the invention. 
     FIG. 2B is a block diagram of a customized keyple, in accordance to an embodiment of the invention. 
     FIG. 2C is a flow diagram of a keyple creation operation, in accordance to an embodiment of the invention. 
     FIG. 3A is a flow diagram of the operation of a feed processor of FIG.  1 . 
     FIG. 3B is a data flow diagram of the operation of a feed processor of FIG.  1 . 
     FIG. 4A is a flow diagram of the operation of a keyple router of FIG.  1 . 
     FIG. 4B is a data flow diagram of the operation of a keyple router of FIG.  1 . 
     FIG. 5A is a flow diagram of the operation of a keyple customizer within a collection processor of FIG.  1 . 
     FIG. 5B is a data flow diagram of the operation of a keyple customizer within a collection processor of FIG.  1 . 
     FIG. 6A is a flow diagram of the operation of a collection builder within a collection processor of FIG.  1 . 
     FIG. 6B is a data flow diagram of the operation of a collection builder within a collection processor of FIG.  1 . 
     FIG. 7A is a diagram of a web browser window displayed on a screen of a terminal computer of FIG.  1 . 
     FIG. 7B is a diagram of a web browser window displayed on a screen of a terminal computer of FIG. 1 in response to a user selecting a hypertext link. 
     FIG. 8 shows a web browser window displayed on a screen of terminal computer of FIG. 1 to enable a user of the terminal computer to specify customization options. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     FIG. 1 is a block diagram of a system  100  for filtering and distributing information, in accordance to the present invention. System  100  includes feed processors  110   n  (where n=A, B, C, etc.) that receive messages from feed sources  120   n  (where n=A, B, C, etc.). Messages received from feed sources  120   n  may contain an abstract of the content represented by the message, a URL pointing back to a location in which the content is stored and one or more keywords (keys) describing the content. Feed processors  110   n,  in turn, either extract keys from the messages received from feed sources  120   n  or generate keys on-the-fly, when no keys are supplied from feed sources  120   n.  Feed sources  120   n  are any source of messages known in the art, such as news agencies, websites, stock brokerage companies, information services, etc. Messages, in turn, are any kind of structured or unstructured information suitable for mass distribution such as news, stock quotations, images, sound bytes, multimedia segments, etc. 
     The messages received from feed sources  120   n  are either stored on feed sources  120   n  or transmitted and cached on remotely located computers. In some embodiments, messages are delivered via satellite, RF transmission, network broadcast or other efficient mass distribution channel to servers located at Internet Service Providers (ISPs) sites. In other embodiments, the messages are stored on servers at a central location together with feed processors  110   n.    
     Feed processors  110   n,  then, package the keys into keyples  200  (FIG.  2 A). Keyples  200  are data sets that store information about keys. Each keyple  200  includes a version number  210 , a feed ID  220 , a message ID  230 , a key ID  240 , an event count  250  and a timestamp  260 . In some embodiments, version number  210 , feed ID  220 , message ID  230 , key ID  240 , event count  250  and timestamp  260  require 4 bytes each, for a total of 24 bytes for an entire keyple  200 . Since keyples  200  are dramatically reduced in size with respect to the messages (typical size 2048 bytes) they represent, the bandwidth required to transmit keyples  200  is substantially less than the one required to transmit the corresponding messages. As a result, mass distribution of keyples  200 , unlike prior art “push” technologies, can be effected inexpensively over information distribution network  130 . 
     Keyples  200  are then transmitted from feed processors  110   n  to collection processors  140   n  (where n=A, B, C, etc.) over information distribution network  130 . Information distribution network  130 , in turn, is made up by a series of keyple routers  160   n  (where n=A, B, C, etc.) connected via a computer network. Each keyple router  160   n,  in turn, receives keyples  200  and compares feed IDs  220  and key IDs  240  of each keyple  200  to feed ID/key ID pairs stored in a keyple router table  470  (FIG. 4B) to determine whether to route the keyple  200  to a destination specified by keyple router table  470 . Destinations specified by keyple router table  470  can be either collection processors  140   n  or additional keyple routers  160   n.  Therefore, keyple routers  160   n  can be organized in a hierarchical structure to allow fast routing of massive amounts of keyples  200 . 
     If a match is found in keyple router table  470  to a destination corresponding to a collection processor  140   n,  the keyple  200  is routed to collection processor  140   n.  Collection processors  140   n,  in turn, receive keyples  200  and organize keyples  200  in customized keyple collections. Customized keyple collections are constructed in accordance to a set of preferences specified by users of system  100 . The structure of a customized keyple  270  is shown in FIG.  2 B. Customized keyple  270  is identical to keyple  200 , except that a collection ID  280  is added. 
     Terminal computers  150   n  (where n=A, B, C, etc.) are connected to collection processors  140   n  either directly or through an ISP server. In the latter case, terminal computers  150   n  are connected to the ISP servers either through network connections or through dial-up modem connections. Users of terminal computers  150   n  can access the messages represented by their customized keyple collections by connecting to the collection processors  140   n  using a web browser program or other information retrieval technique known in the art. When the user connects to collection processor  140   n,  collection processor  140   n  extracts messages associated with customized keyples  280  and transmits customized keyples  280  to terminal computers  150   n,  where customized keyples  280  are displayed in the web browser window. The user can then retrieve the content associated with the message by selecting a hypertext link embedded in the message. 
     The content associated with the message is either retrieved directly from feed servers  120   n  or from an information cache on ISP servers. For example, in some embodiments the message contains a headline and a URL pointing to a location of the complete story which represents the content associated with the message. When the user follows the link associated with the headline, the URL contained in the message is used to retrieve the content from a remote location. The content is then displayed to the user together with other information extracted from the message (e.g., timestamp, feed source, abstract, etc.). In some instances (e.g. stock quotes), however, no content is associated with the message and therefore, only the information extracted from the message is presented to the user. 
     Feed processors  110   n,  collection processors  140   n  and keyple routers  160  are any suitable computers known in the art for receiving feeds over a computer network and extracting information keys from the feeds and distributing keys over an information distribution network. In some embodiments, feed processors  110 n, collection processors  140   n  and keyple routers  160  are any Pentium® or PentiumII® based computers, available from a variety of third party manufacturers, G3 or Macintosh® computers, available from Apple Computer, Inc. of Cupertino, Calif., or high-end workstations such as UltraSparc™ workstations, available from Sun Microsystems, Inc. of Mountain View, Calif. 
     Furthermore, keyple routers  160   n  can be integrated with traditional network routers available from, for example, Cisco Systems, Inc. of San Jose, Calif. or 3COM Corporation of Santa Clara, Calif., that are part of information distribution network  130 . 
     FIG. 2C is a flow diagram of a keyple creation operation  205  used to create keyple  200  on a feed processor  110   n.  In FIG. 2C, a block in a memory of feed processor  110   n  is first allocated to store keyple  200  in stage  215 . In stage  225 , version number  210  is inserted in the memory block allocated in stage  215 . Version number  210  is generated in response to a change in the structure of keyple  200 . In stage  235 , feed ID  220  is inserted in the memory block allocated in stage  215 . Feed ID  220  identifies the feed source  120   n  from which the message represented by keyple  200  is extracted. In stage  245 , message ID  230  is inserted in the memory block allocated in stage  215 . Message ID  230  is a unique identifier assigned by feed processor  110   n  to each message received by feed processor  120   n.  In stage  255 , key ID  240  is inserted in the memory block allocated in stage  215 . Key ID  240  is a unique ID obtained by searching key table  320  for each key extracted from the message received from feed source  120   n.  Key ID  240  need not be unique across keys extracted from different feed sources  120   n.  However, each combination of key ID  240  and feed ID  220  must be unique. Since multiple keys can be extracted from a single message received from feed source  120   n,  more than one keyple  200  may be generated for each message. 
     In stage  265 , event count  250  is inserted in the memory block allocated in stage  215 . Event count  250  is a numerical value assigned by feed processor  120   n  representing the number of messages received from a particular feed source  120   n  that match key ID  240  of keyple  200 . In stage  275 , timestamp  260  is inserted in the memory block allocated in stage  215 . Time stamp  260  is a value representing the time at which the message received from feed source  120   n  originated. Finally, keyple  200  is generated in stage  285 . The order in which stages  225 - 275  of operation  205  are performed is purely illustrative in nature. In fact, stage  225 - 275  of operation  205  can be performed in any order, in accordance to the principles of the present invention. 
     FIG. 3A is a block diagram of a message processing operation  300  performed by a feed processor  110   n.  First, in stage  305 , feed processor  110   n  receives a new message from a feed source  120   n.  Each message received by feed processor  110   n  may contain one or more keys associated with the message received from feed source  120   n.  Alternatively, a wildcard key may be used to match any message received from a particular feed source  120   n.  Stage  310  determines whether any of the keys received as part of the message are unprocessed, in which case operation  300  proceeds to stage  315 . Otherwise, operation  300  proceeds to stage  330 . Stage  315  determines whether a key match is found by comparing a key received from feed source  120   n  to the entries stored in key table  320 . If a key match is found, operation  300  proceeds to stage  325 . Otherwise, operation  300  reverts back to stage  310 . If a key match is found, a keyple is generated in stage  325  and operation  300  reverts to stage  310 . Thus, if multiple key matches are found for a message received from feed source  120   n,  multiple keyples  200  are generated. Stage  330 , then determines whether any keyples were generated for the message received from feed source  120   n,  in which case operation  300  proceeds to stage  335 . Otherwise, operation  300  proceeds to stage  340  and operation  300  terminates. Finally, keyples  200  generated in stage  325  are transmitted to a keyple router  160   n  over information distribution network  130  and operation  300  terminates. 
     FIG. 3B illustrates data flow  350  through feed processor  110   n.  A feed stream received from feed source  120   n  is received by feed listener  355 . Feed listener  355  extracts a message from the feed stream, stores the message in message queue  360  and signals to feed processor  365  that a new message has been received. Feed processor  365 , in turn, extracts a message from message queue  360  and compares any keys contained in the message to the entries stored in key table  320 . If any key matches are found, as explained with respect to the flow diagram of FIG. 3A, feed processor  365  adds a keyple  200  to keyple queue  375  and signals feed transmitter  380  that keyple  200  has been added to keyple queue  375 . Finally, feed transmitter  380  periodically packages keyples  200  into keyple packets and transmits the keyple packets over information distribution network  130 . Keyple packet transmissions are triggered either by having a sufficient number of keyples  200  to fill a keyple packet in keyple queue  375  or by expiration of a preset period of time in between keyple packet transmissions. However, some keyples, known as priority keyples, are immediately transmitted regardless of whether the keyple packet is filled. Thus, priority keyples can be used to transmit time sensitive information to ensure real time distribution of information. 
     In some embodiments, feed listener  355 , feed processors  365  and feed transmitter  380  are separate threads of a C++ program executed by a Linux® (Red Hat v. 5.2) operating system running on feed processor  110   n.  Appendix A contains code segments illustrating possible implementations of feed listener  355 , feed processor  365  and feed transmitter  380 . Those skilled in the art, however, realize that feed listener  355 , feed processor  365  and feed transmitter  380  could be implemented in computer languages other than C++ and executed by operating systems other than Linux®. For instance, feed listener  355 , feed processor  365  and feed transmitter  380  could be implemented as JAVA™ bytecodes executed by any multi-threading operating system, such as versions of Unix® other than Linux®, Mac®OS, available from Apple Computer, Inc. of Cupertino, Calif., or Windows NT® 4.0, available from Microsoft Corp. Of Redmond, Wash. 
     FIG. 4A is a flow diagram of operation  400  executed by a keyple router  160   n  of FIG.  1 . Initially, a keyple  200  is received by keyple router  160   n  over information distribution network  130  in stage  405 . Stage  410  then determines whether a routing match is found by comparing feed ID  220  and key ID  240  of keyple  200  to the feed ID/key ID pairs stored in keyple router table  470 . If a routing match is found, operation  400  proceeds to stage  415 . Otherwise, keyple router  160   n  notifies the sender of keyple  200  that no routing match has been found in stage  435 . Thus, keyple processing is completed in stage  440  and operation  400  terminates. If a routing match is found, a destination list is generated in stage  415 . Thus, more than one destination can be specified for each routing match. Stage  420  determines whether a copy of keyple  200  has been sent to all destinations in the destination list generated in stage  415 , in which case keyple processing is completed in stage  440  and operation  400  terminates. Otherwise, a copy of keyple  200  is generated in stage  425  and the copy of keyple  200  is transmitted to a new destination in stage  430 . Stages  420 - 430  are then repeated until all destinations in the destination list have been processed. Keyple processing is completed in stage  440  and operation  400  terminates. 
     FIG. 4B illustrates data flow  450  through keyple router  160   n.  A keyple stream transmitted over information distribution network  130  is received by keyple router listener  455 . Keyple router listener  455  extracts a keyple  200  from the keyple stream, stores keyple  200  in keyple queue  460  and signals to keyple router processor  465  that a keyple  200  has been received. Keyple router processor  465 , in turn, extracts a keyple  200  from keyple queue  460  and compares feed ID  220  and key ID  240  contained in keyple  200  to the entries stored in keyple router table  470 . If any routing matches are found, as explained with respect to the flow diagram of FIG. 4A, keyple router processor  465  adds keyple  200  to keyple queue  475  and signals keyple router transmitter  480  that keyple  200  has been added to keyple queue  475 . Finally, keyple router transmitter  480  periodically packages keyples  200  into keyple packets and transmits the keyple packets over information distribution network  130 . Keyple packet transmissions are triggered either by having a sufficient number of keyples  200  directed to a same destination to fill a keyple packet in keyple queue  475  or by expiration of a preset period of time in between keyple packet transmissions to a destination. As explained with respect to FIG. 3B, priority keyples are transmitted immediately regardless of whether the keyple packet is full. 
     In some embodiments, keyple router listener  455 , keyple router processor  465  and keyple router transmitter  480  are separate threads of a C++ program executed by a Linux® (Red Hat v. 5.2) operating system running on keyple router  160   n.  Appendix A contains code segments illustrating possible implementations of keyple router listener  455 , keyple router processor  465  and keyple router transmitter  480 . Those skilled in the art, however, realize that keyple router listener  455 , keyple router processor  465  and keyple router transmitter  480  could be implemented in computer languages other than C++ and executed by operating systems other than Linux®. For instance, keyple router listener  455 , keyple router processor  465  and keyple router transmitter  480  could be implemented as JAVA™ bytecodes executed by any multi-threading operating system, such as versions of Unix® other than Linux®, Mac®OS, available from Apple Computer, Inc. of Cupertino, Calif., or Windows NT® 4.0, available from Microsoft Corp. Of Redmond, Wash. 
     FIG. 5A is a flow diagram of operation  500  executed by a keyple customizer of collection processor  140   n  of FIG.  1 . Initially, a keyple  200  is received by collection processor  140   n  over information distribution network  130  in stage  505 . Stage  510  then determines whether a customization match is found by comparing feed ID  220  and key ID  240  of keyple  200  to the feed ID/key ID pairs stored in customization definition table  570 . If a customization match is found, operation  500  proceeds to stage  515 . Otherwise, collection processor  140   n  notifies the sender of keyple  200  that no customization match has been found in stage  540 . Thus, keyple processing is completed in stage  545  and operation  500  terminates. If a customization match is found, a keyple collection list is generated in stage  515 . Thus, more than one keyple collection can be specified for each customization match. Stage  520  determines whether all keyple collections in the keyple collection list generated in stage  515  have been processed, in which case keyple processing is completed in stage  545  and operation  500  terminates. Otherwise, a copy of keyple  200  is generated in stage  525 . A customized keyple  270  is then generated in stage  530  by inserting collection ID  280  into the copy of keyple  200  generated in stage  525 . Customized keyple  270  is transmitted in stage  535 . Stages  520 - 535  are then repeated until all keyple collections in the keyple collection list have been processed. Thus, keyple processing is completed in stage  545  and operation  500  terminates. 
     FIG. 5B illustrates data flow  550  through a keyple customizer of collection processor  140   n.  A keyple stream transmitted over information distribution network  130  is received by customizer listener  555 . Customizer listener  555  extracts a keyple  200  from the keyple stream, stores keyple  200  in keyple queue  560  and signals to customizer processor  565  that a keyple  200  has been received. Customizer processor  565 , in turn, extracts a keyple  200  from keyple queue  560  and compares feed ID  220  and key ID  240  contained in keyple  200  to the entries stored in customization definition table  570 . If any customization matches are found, as explained with respect to the flow diagram of FIG. 5A, customizer processor  565  adds customized keyple  270  to customized keyple queue  575  and signals customizer transmitter  580  that customized keyple  270  has been added to customized keyple queue  575 . Finally, customizer transmitter  580  sends customized keyple  270  to a collection builder of collection processor  140   n.    
     In some embodiments, customizer listener  555 , customizer processor  565  and customizer transmitter  580  are separate threads of a C++ program executed by a Linux® (Red Hat v. 5.2) operating system running on collection processor  140   n.  Appendix A contains code segments illustrating possible implementations of customizer listener  555 , customizer processor  565  and customizer transmitter  580 . Those skilled in the art, however, realize that customizer listener  555 , customizer processor  565  and customizer transmitter  580  could be implemented in computer languages other than C++ and executed by operating systems other than Linux®. For instance, customizer listener  555 , customizer processor  565  and customizer transmitter  580  could be implemented as JAVA™ bytecodes executed by any multi-threading operating system, such as versions of Unix® other than Linux®, Mac®OS, available from Apple Computer, Inc. of Cupertino, Calif., or Windows NT® 4.0, available from Microsoft Corp. Of Redmond, Wash. 
     FIG. 6A is a flow diagram of operation  600  of a collection builder of collection processor  140   n.  A customized keyple  270  transmitted from a keyple customizer of collection processor  140   n  is first received by the collection builder in stage  605 . Customized keyple  270  is stored in keyple cache  615  in stage  610 . Cache  615  stores the most recently received customized keyples  270  for fast access. Customized keyples  270  are periodically flushed from keyple cache  615  or written to disk for permanent storage. Stage  620  then determines whether a user of a terminal computer  150   n  is connected to collection processor  140   n,  in which case operation  600  proceeds to stage  625 . Otherwise, keyple processing is completed in stage  640  and operation  600  terminates. A message associated with customized keyple  270  is then retrieved in stage  625 . Information is extracted from the message retrieved in stage  625  and encoded for transmission to terminal computer  150   n  in stage  630 . Depending on the type of connection between terminal computer  150   n  and collection server  140 n the type of information extracted from the message and the formatting of the information may change. For instance, if the user of terminal computer  150   n  is accessing collection server  140   n  at an ISP site using a web browser over a dial-up connection, the information would be formatted as an HTML page. Alternatively, the information could also be formatted as JAVA™ bytecodes or other format supported by terminal computer  150   n.  Thus, keyple processing in completed in stage  640  and operation  600  terminates. 
     FIG. 6B illustrates data flow  650  through a collection builder of collection processor  140   n.  A customized keyple stream transmitted from a keyple customizer of collection processor  140   n  is received by builder listener  655 . Builder listener  655  extracts a customized keyple  270  from the customized keyple stream, stores customized keyple  270  in customized keyple queue  660  and signals builder processor  665  that a customized keyple  270  has been received. Builder processor  665 , in turn, extracts a customized keyple  270  from customized keyple queue  660 , stores customized keyple  270  in keyple cache  615  and signals collection server  680  that customized keyple  270  has been added to keyple cache  615 . Finally, collection server  680  processes customized keyple  270  as described with respect to the flow diagram of FIG.  6 A. 
     In some embodiments, builder listener  655 , builder processor  665  and collection processor  680  are separate threads of a C++ program executed by a Linux® (Red Hat v. 5.2) operating system running on collection processor  140   n.  Appendix A contains code segments illustrating possible implementations of builder listener  655  and builder processor  665 . Those skilled in the art, however, realize that builder listener  655 , builder processor  665  and collection processor  680  could be implemented in computer languages other than C++ and executed by operating systems other than Linux®. For instance, builder listener  655 , builder processor  665  and collection processor  680  could be implemented as JAVA™ bytecodes executed by any multi-threading operating system, such as versions of Unix other than Linux®, Mac®OS, available from Apple Computer, Inc. of Cupertino, Calif., or Windows NT® 4.0, available from Microsoft Corp. Of Redmond, Wash. 
     FIG. 7A is a diagram of a web browser window  700  displayed on a screen of terminal computer  150   n.  . Web browser window  700  is a window displayed by any web browser program known in the art such as Internet Explorer 4.0, available from Microsoft Corporation of Redmond, Wash., or Netscape Navigator® 4.0, available from Netscape Communications, Corp. of Mountain View, Calif. Window  700  has a category selection menu  710  and multiple headlines  720   n  (where n=A, B, C, etc.). Each headline  720   n  has a timestamp  730 n corresponding to timestamp  260  of customized keyple  270 , hypertext link  740   n  and feed source  750 n. A user of terminal computer  150   n  can retrieve the information associated with headline  720   n  by clicking on hypertext link  730 n, as shown in FIG.  7 B. 
     FIG. 7B is a diagram of a web browser window  760  displayed on a screen of terminal computer  150   n  in response to a user selecting hypertext link  740 A of FIG.  7 A. Web browser window  760  is a window displayed by any web browser program known in the art such as Internet Explorer 4.0, available from Microsoft Corporation of Redmond, Wash., or Netscape Navigator® 4.0, available from Netscape Communications, Corp. of Mountain View, Calif. Web browser window  760  includes a title  765 , a feed source  770 , a timestamp  780 , an author  790  and a body  795 . 
     FIG. 8 shows a web browser window  800  displayed on a screen of terminal computer  150   n  to enable a user of terminal computer  150   n  to specify customization options to be used by the keyple customizer of collection processor  140   n.  Web browser window  800  is a window displayed by any web browser program known in the art such as Internet Explorer 4.0, available from Microsoft Corporation of Redmond, Wash., or Netscape Navigator® 4.0, available from Netscape Communications, Corp. of Mountain View, Calif. Web browser  800  includes category tabs  810   n  (where n=A, B, C, etc.). Each tab  810   n  has a feed source menu  820   n,  a subscribe button  830   n,  a get all content button  840   n,  a get sections button  850   n  and a sections list  860   n.  Windows NT is a registered trademark of Microsoft Corporation of Redmond, Wash. Pentium and Pentium II are registered trademarks of Intel Corporation of Santa Clara, Calif. Macintosh and MacOS are registered trademarks of Apple Computer, Inc. of Cupertino, Calif. UltraSparc and JAVA are trademarks of Sun Microsystems, Inc. of Mountain View, Calif. Unix is a registered trademark of American Telephone and Telegraph Company of New York, N.Y. Linux is a registered trademark of Linus Torvalds. Netscape Navigator is a registered trademarek of Netscape Communications, Corp. of Mountain View, Calif. 
     Embodiments described above illustrate but do not limit the invention. In particular, the invention is not limited to the particular hardware described herein. Those skilled in the art realize that alternative information delivery means can be employed in lieu of the ones described herein in accordance to the principles of the present invention. Furthermore, the invention is not limited to the distribution of any particular type of information. For example, the invention can be used to distribute news, advertisement, marketing materials, etc. Similarly, the invention is not limited to the particular web pages described herein. In fact, those skilled in the art realize that different web pages or even alternative information delivery techniques such as voice, paging, etc. may be used in lieu of the web pages of FIGS. 7A,  7 B and  8 . Other embodiments and variations are within the scope of the invention, as defined by the following claims.