Utilization of information "push" technology6807558Abstract An apparatus and computer-implemented method for distributing information to a plurality of client devices on a network is disclosed. The computer-implemented method includes the steps of: 1) receiving a variety of information from a plurality of sources, 2) organizing the variety of information into information categories, and 3) distributing the variety of information to the plurality of client devices based on the information categories requested by the plurality of client devices. The invention further includes the steps of: 4) accepting user input at the client device to specify information categories for retrieval from a server, 5) generating a user profile based on the information categories specified by the user input, and 6) retrieving information at predetermined intervals from the server based on the user profile. Claims We claim: Description TECHNICAL FIELD
TABLE I
Pseudocode Representation of Screen Saver Procedure
Store, indication of last information category displayed,
and for each category an indication of the last advertisement,
news story and display script used.
Do Until Screen Saver Mode is exited:
{
Select next information category (SIC).
Select next display script (SDS) from queue of display scripts
and next advertisement (SA) from queue of advertisements
for the selected information category.
Inspect selected display script to determine NN,
the number of news items to be displayed. Select
the NN next news items (SNI) from queue of
news items for the selected information category.
Update User Profile to indicate the last selected
information category, and to indicate for the
selected information category, the selected display
script, advertisement and last selected
news story.
Call Animation Engine (SDS, SA, SNI) to display for
the next 30 seconds the selected advertisement
(SA) and news items (SNI) under the direction
of the selected display script (SDS).
Call Ad Display Statistics Generator to update displayed
advertisement statistics to include the advertisement
displayed during current screen saver display period.
}
Each time the Screen Saver procedure 201 is invoked, it starts with the next information category after the last one to have been used, and starts with the next advertisement and news stories after the last ones used in that information category. The screen saver status information 219 indicating the last displayed information category and the last displayed advertisement and news items in each information category are stored in a portion of the user profile 194 not transmitted to the information server. Execution of the Screen Saver procedure 201, like other screen savers, is terminated and the subscriber's computer's display is returned to whatever was being displayed before the Screen Saver was executed, upon detection of certain types of user input. In the preferred embodiment, the user can use the profiler to select one of at least two exit modes: in a first mode, the Screen Saver procedure is terminated by hitting any key on the subscriber computer's user interface keyboard or by moving the user interface's mouse or trackball; in a second mode, the Screen Saver procedure is terminated by hitting any key on the subscriber computer's user interface keyboard, but movement of the mouse or trackball does not cause the Screen Saver procedure to terminate. Rather, in the second screen saver exit mode, the subscriber can use the mouse or trackball to point to any of the news items being displayed and upon clicking one of the mouse or trackball's buttons, the data viewer 208 is executed with the news item selected by the subscriber being displayed. When using the second screen saver exit mode, if subscriber user clicks on 16 an advertisement, the subscriber's computer is automatically connected to the an associated World Wide Web page on the Internet that Provides additional information from the advertiser. This is accomplished by World Wide Web connection and viewer procedures 211 (see FIG. 2) stored on subscriber's computer. Each advertisement is stored on both the information server and subscriber computers as a C++ data structure that includes (A) an image data array, typically representing a "GIF" format image, as well as (B) a list of static images (such as corporate logos and legends), if any, incorporated into the advertisement, and (C) a Web site address that is used by the World Wide Web connection and viewer procedures 211 to connect the subscriber to the advertiser's specified Web page when the subscriber clicks on the image of the associated advertisement. Referring to FIG. 10, the data viewer 208 is a program for viewing news 29 items that the subscriber specifically wants to read. The data viewer 208 can be executed 30 at the subscriber's explicit command, and as just described in the immediately preceding section of this document, the data viewer can also be launched from the screen saver when the subscriber indicates that he/she wants to read a news story shown in the screen saver display by "clicking" the subscriber's computer's mouse or trackball on that news story. The news stories shown in the center section 248 of the data viewer's display is selected by first selecting an information category by clicking on any of the category buttons 250 on the left margin of the display, and a subcategory button 252, if any, on the bottom margin of the display, and then clicking on the article advance backward and forward buttons 254 to scroll through the news items in the selected information category. When a news item has more than one photo image associated with it, the subscriber can click on the photo advance backward and forward buttons 256 to scroll through the photos. Each news item displayed in the center section 248 of the data viewer's display includes both the primary and secondary portions of the news item, thereby providing the subscriber in most instances with access to a fuller version of the news item than was shown by the screen saver. In the case of very short news items, the entire news item may be contained in its primary component. Furthermore, in client computers with very limited hard disk space available for storing news items, as indicated by the user profile 194 for the client computer, the secondary component of news items may not be stored in the local information database in order to conserve disk space. A portion of the data viewer screen is always occupied by an advertisement image 258. The advertisement image shown is selected on the basis of the information category associated with the news item being viewed. In a preferred embodiment, the advertisement shown in the data viewer screen is changed (A) every time the subscriber clicks on a category button 250 so as to select a different information category than the one previously selected, and (B) every 30 seconds when subscriber continues to view news items in a single information category for more than 30 seconds. The advertisements are selected in rotating order among the advertisements assigned to each information category, as described above for the screen saver procedure. When using the data viewer, if subscriber user clicks on the displayed advertisement, the subscriber's computer is automatically connected to the an associated World Wide Web page on the Internet that provides additional information from the advertiser. The Options button 260 is used to invoke dialog procedures in which the subscriber specifies general preferences, such as how quickly data scrolls in the scrolling windows, and which mode of screen-saver termination the subscriber prefers. Referring to FIGS. 11 and 12, the information server is preferably a set of computers interconnected by a local area network that each operate under a multi-tasking, multi-threading operating system such as Microsoft's Windows NT. The information server 104 has multiple "application servers" 272, which are processes run on one or more computers. Each application server 272 preferably has multiple threads, each of which can service one connection with a client computer at any one time. A primary concern with the architecture of the information server is that the information be able to handle a very large volume of connection requests from client computers. The information server may need to service thousands of connection requests per hour, and thus efficient handling of each connection request is important. In a preferred embodiment, during each connection of a subscriber computer to the information server, the information server sends a "next recommended download time" to the subscriber computer along with the other information being downloaded onto the subscriber computer. The server computer selects the next recommended download times sent to the various subscriber computers so as to spread their connection requests fairly evenly over time. In an alternate embodiment, connection requests are spread over time by having the subscriber computers randomly select connection times within the general boundaries of a specified schedule of connections (e.g., a randomly selected time anywhere within a half hour, plus or minus, of each scheduled connection time). When a client computer first initiates a connection to the information server, it sends a first message to the Internet address associated with a router process 270 in the information server. The router selects an application server 272 with at least one available thread and passes back to the client computer an Internet address associated with that application server. The client computer then sends a portion of its user profile to the assigned application server. If an administrative update is being requested, the locally accumulated advertising display statistics 218 (see FIG. 4) are also sent to the application server. Based on the time of day and the information in the transmitted user profile, the application server determines (A) what type of update is to be performed (i.e., a news item update or an administrative update), and (B) what new information needs to be downloaded to the client computer and what items in the client computer's local information database should be deleted. The application server 272 then makes calls to one or more data servers 274 to collect all the information that needs to be sent to the client computer and then sends those items to the client computer, along with instructions on what items, if any, should be deleted from the client computer's local information database. The client computer then loads the received information into its local database, and replaces software modules with received software modules, if any. It also deletes the items, if any, specified for deletion by the information server. Finally, it updates its data access tables 186 to incorporate all the changes to the information database so that the client computer is ready to display news items and advertisements in each information category. A more detailed explanation of the local database update process is provided by a pseudocode representation of that process in Table 2. In one preferred embodiment, when the "client" that is connected to the information server for an update is itself a local area network server, the client downloads all news items into its local database. In a second preferred embodiment, the client/LAN server generates a group profile that represents the union of all news category and subcategory preferences of the subscribers connected to the client computer, and news items are downloaded into the client's local data base based on that union group profile. In either embodiment, the screen saver procedures filter out news items in the LAN server's local information database that are not consistent with each subscriber's user profile, thereby showing each subscriber only the subset of news items corresponding to the subscriber's user profile. In the preferred embodiments, the subscriber level news item filtering is accomplished by setting up the subscriber's data access tables 186 to include only news items corresponding to the subscriber's user profile. In the computers of stand alone subscribers, the filtering of news stories is handled during the data download process, by only downloading news items corresponding to the subscriber's user profile. The subscriber level news item filtering function is also used to enable the information server to instruct the subscriber's computers to "black out" an advertisement, without deleting it from the local database. For example, a company may want to suspend its advertisements for a few days after a disaster involving the company. The black out function is achieved by simply removing the corresponding advertisement(s) Crom the advertisement queues in the data access tables. For this purpose, the information server and subscriber computers may temporarily define a "non-use" information category and a corresponding advertisement queue for keeping track of blacked out items.
TABLE 2
Pseudocode Representation of Database Update Procedure
Connect to Information Server
If Update Type=Administrative /* i.e., not a news story only update*/
{
Client sends display Statistics to server, and clears
display statistics upon confirmation that server
has successfully received them
/* Pool Synchronization*/
Server Sends list of items (i.e., advertisement and scripts)
that should be included in the client's advertisement
and script pools
Client deletes items in its advertisement and script pools
that are not included in the list received from the Server
Client determines what items are missing from its
advertisement and script pools
Client sends requests to Server for advertisements
and scripts determined to be missing from local pools
Server sends requested items to Client
Client stores received advertisements and scripts
in their respective disk directories
Client opens all advertisement and script files to
determine the static images referenced by those
files, but not included in the local static image pool.
Client sends requests to Server for static images determined
to be missing from local pool
Server sends requested items to Client
Client stores received static images in their assigned
disk directory
/* Software Module Synchronization*/
Client sends message indicate it is ready for software
synchronization, including date and time of last
administrative update
Server sends new software modules, if any, based on date
and time of last administrative update
}
For each Category Manager (CMx)
{
/* CMx.Fetch Procedure:*/
Client (CMx.Fetch procedure) sends profile data
for CMx to Server, including subcategory data
and filter data, if any
Server sends items consistent with profile data
Client (CMx.Fetch procedure) stores received items in data
structures and files for that category
Client (CMx.Fetch procedure) deletes items, in FIFO order,
for current category which (A) exceed data storage
limit in date, (B) exceed item count limit, or
(C) exceed specified age limit
/* Item storage limits 221 for each category are
defined in a portion of the user profile 194 (see FIG. 4) */
}
Client updates data access tables
Return
One embodiment of the present invention comprises a computer-implemented method for distributing information to a plurality of client devices on a network, the computer-implemented method comprising receiving a variety of information from a plurality of sources, organizing the variety of information into information categories, and distributing the variety of information to the plurality of client devices based on the information categories requested by the plurality of client devices. The computer-implemented method may further include accepting user input at the client device to specify information categories for retrieval from a server, generating a user profile based on the information categories specified by the user input, and retrieving information at predetermined intervals from the server based on the user profile. Another embodiment of the present invention comprises a computer-implemented method for varying information displayed on a client device, the computer-implemented method comprising maintaining a plurality of scripts on the client device, executing a first script from the plurality of scripts to display a first set of information for a first predetermined period, and executing a second script from the plurality of scripts to display a second set of information for a second predetermined period. Still another embodiment of the present invention comprises a computer-implemented method for generating and maintaining information access statistics for each piece of information stored on a client device, the computer-implemented method comprising generating tracking information indicative of a number of times each piece of information is displayed during a predetermined period, and transferring the tracking information to a server at predetermined intervals. Several improvements of note have been made with respect to PointCast's client push software and improved server with respect to the manner in which access to and display of pushed information is implemented and coordinated. These improvements are as follows: A. Dynamic Actors: Dynamic actors match content in the client to actors in an animation based on properties of the actors and the content, rather than any hard-coded reference. This ability is necessary to create and support "template" animations, such as SmartScreens, that can rotate through all content on a given user's machine-independent of what specific content is present; for example, displaying a headline from the News channel in a SmartScreen without referring to a specific news article. In the earlier versions of PointCast, the channels themselves did the mediation between data and animations. However, now that there is centralized content management in the client (see the Local Content Manager specification and description hereinafter), content providers can create compelling animations, and are allowed to do so, without client code changes, by removing the channels from this process. There is also an additional performance and memory footprint benefit to this restructuring in that the SmartScreen can now run independently of the Channel Viewer. To extricate the channels from actor creation, however, it is necessary to establish a method and syntax for content to declare what actors it can create and for each dynamic actor in an animation to declare what content it needs. For content, the ACTORS tag in the wrapper and PCN-ACTOR tags in the body (for HTML items) can be used to declare what actors it can create. For actors, the ACTORDATA tag in the initialization section of the animation can be used to declare what data it needs. LCM and special iteration code called by an animation engine (in the presence of an INITIALIZE tag) will match content to actors. Content: Declaring Dynamic Actors Actors are declared in content using the ACTORS property in the wrapper of the data item (for more information on wrappers, see the Fetching and LCM spec). The syntax for the ACTORS property is: [<content ID>=]<name>[,<name>. . . ][&<content ID>=<name>[,<name>. . . ]. . . ]. To break this down more specifically, in the case where the entire data item is to serve as the actor, then no content ID need be specified. For example, a weather map uses the following actors string: ACTORS="Map" However, through the use of the PCN-ACTOR tag, multiple actors can be declared within one HTML item, and those actors can even be grouped together to correspond to individual stories within the item using the ContentID property of the PCN_ACTOR tag. For example, a digest article with two summary articles might have the following ACTORS property (where Story1 and Story2 are the two Content IDs): ACTORS "Story1=Summary, Photo& Story2=Summary,Photo,Photo2" The syntax for the PCN_ACTOR tag is: <PCN_ACTOR ContentID= Name= [Data=URL] > [DATA] </PCN_ACTOR> where the data to associate with the PCN_ACTOR is either specified by the Data property, or if the Data property is not present, then the data between the open and close PCN_ACTOR tags is used. Note: If there is more than one PCN_ACTOR tag in a data item that uses the same ContentID and Name, then the last specified Data property will be used. In the case where no Data property is present for any of the PCN_ACTORs, then the data for all of the tags will be concatenated together and returned. The following table gives a more detailed explanation of each of the PCN_ACTOR properties.
PCN-ACTOR
Field
Name Type Default Description
CON- Value 0 ContentID is used to mark actors as
TENT- belonging to the same content item when
ID a file contains multiple content items
(i.e., a digest file) and can be any
string value. ContentID "0" is a
special case that serves as the default
ContentID for any data item. Content ID "0"
is useful when PCN_ACTORS are needed
(because actors are embedded within the
HTML), but there's only one story (content
ID) in the document.
NAME Value Summary The NAME property is used to identify data
as being of a certain type (editorial type, not
render type). An example of the usage of
NAME is if a content provider wished to
specify one section of every HTML article as
being the "Abstract," they could add
PCN_ACTOR tags that had
Name = "Abstract"
to all of their content and then create
SmartScreens that only called for Abstracts.
DATA URL A URL to the data for this actor. This field is
optional. When not present, the data between
the open and close PCN_ACTOR
tags will be used.
Animations: Initializing and Using Dynamic ActorsInitializing Dynamic Actors Dynamic actors are initialized in an animation script using the ACTORDATA tag. This tag describes the data needed by an actor and appears in the initialization section of the animation (the initialization section is demarcated by the INITIALIZE tag). In addition to the ACTORDATA tag, ACTORGROUP tags are used to specify the relationship of ACTORDATA requests to each other, as well as to impose requirements for the successful initialization of the animation. More specifically, ACTORGROUP tags can be used to specify which ACTORDATA request should come from the same category or content item, as well as specify which or how many ACTORDATA requests must be fulfilled (matched with content) before the entire 11 animation can be considered successfully initialized. An entire animation can be considered successfully initialized if the top level ACTORGROUP tag is successfully initialized. In the case where there is more than one top-level ACTORGROUP tag, there is an implied generic ACTORGROUP (see below) that encloses the entire initialization section. Following is the structure of the INITIALIZE section of an animation: <INITIALIZE> ACTORGROUPS/ACTORDATA </INITIALIZE> <ACTORGROUP> Type=Story.vertline.Category.vertline.Generic Create=A11.vertline.1.vertline.2.vertline.. . . Required=A11.vertline.1.vertline.2.vertline.. . . InitOrder=Sequential.vertline.Random [Restrictions] > ACTORGROUP.vertline.ACTORDATA </ACTORGROUP> >ACTORDATA ActorName= ID= > </ACTORDATA> Here are more in-depth descriptions of the ACTORDATA properties.
ActorData
Field
Name Type Default Description
ACTOR- Value _TITLE ACTORDATA tags are linked to
NAME PCN_ACTORs via the ACTORNAME
property. To fulfill an ACTORDATA
request, the client scans the currently
selected portion of LCM (i.e., within the
current channel and category ACTOR-
GROUP) for a data item that contains
a reference to this ACTORNAME.
Usually, the ACTORNAME is found in
the ACTORS field, however the default
ACTORNAMES have custom require-
ments for intializations (see table below).
ID Value The ID is used as an identifier for the
data that an ACTORDATA request will
return if successfully initialized. To access
this data, actors in the animation script
will have an ActorDataID property that
matches the ID of an ACTORDATA
request.
While most ACTORNAMEs need to be listed in the ACTORS field in LCM to be successfully initialized, there are some built-in ACTORNAMEs that don't need to be listed and have different requirements for initialization:
Default ActorNames
Requirement
Field for
Name initialization Description
_TITLE Non-empty The TITLE field in LCM, as text.
TITLE Especially useful for headlines.
field
_DATE Valid The date stamp of a content
CREATION.sub.-- item, as text.
TIME
field
_CATE- Defined The name of the channel, as text.
GORY- in channel
NAME
_CATE- Defined The logo for a category (i.e. the Money
GORY- in channel magazine logo in the Pathfinder channel).
LOGO
_CATE- Valid Gives the time when the current category
GORY- LAST.sub.-- was last updated, as text.
DATE UPDATED
time
The properties for the ACTORGROUP tag:
ActorGroup
Field De-
Name Type fault Description
TYPE Value Key Values: Story.vertline.Category.vertline.Generic
The Type property specifies what content
needs to be iterated through to look for
ACTORDATA when this ACTORGROUP is
initialized.
Story - Iterates through content IDs for the
current channel and category. Stories can be
either at the data item level, or the
content ID level.
Category - Iterates through all categories in
the current channel (the category list will be
returned by the channel itself -- this is the
one remaining dependence on channels
for actor creation in 2.0).
Generic - Used for grouping conditions for
successful initialization of the animation.
The Generic ACTORGROUP does not
cause any iteration itself.
CREATE Value KEY Specifies the number of child
ACTORGROUP or ACTORDATA tags to
initialize. For example, if an ACTOR-
GROUP has a Create value of 1 but has
three child ACTORGROUP tags, as soon
as one ACTORGROUP is successfully
initialized, the actor iteration code
would not even attempt to initialize
the others.
RE- Value -- Specifies the number of child tags that
QUIRED must be initialized. If the required number
of ACTORGROUPs cannot be initialized,
then the ACTORGROUP itself will fail
initialization.
INIT- Value Se- Values: Sequential.vertline.Random
ORDER quen- This property specifies what order the
tial ACTORGROUP should use in attempting to
initialize its children.
Sequential - The ACTORGROUP initializes
its children in the same order they appear
in the INITIALIZE tag.
Random - The ACTORGROUP initializes its
children randomly (but only attempts
once per child).
[Restric- -- -- Any number of properties can be specified
tions] that will serve as restrictions on LCM
tables. These restrictions further define the
set of data to be scanned looking for
ACTORDATA. See the Restrictions table
below for the set of supported
restrictions.
Restrictions
Field
Name Type Default Description
[CHAN- Num- Channel This is an implied restriction.
NEL] ber of SS In 2.0, only the channel that called
the animation (via the Smart-
Screen catalog) can be used to generate
dynamic actors for that animation.
SKIP- Bool- True If true, don't initialize content IDs or data
SHOWN ean items that have already been marked as
shown in LCM (using the
ACTORS_SHOWN property).
NEW- Num- -- Can only be applied to a Category
NESS ber ACTORGROUP, the newness value is the
number of seconds since the last time the
category was updated. The logic is: If (last
fetch time - article creation time <
newness value) then the article is new
enough to be shown.
Using Dynamic Actors And then, within the MOVIE tag itself: <ACTOR ActorDataID= . . . > </ACTORDATA>
Actor
Field De-
Name Type fault Description
ACTOR- String -- This property ties an Actor to the
DATA- ACTORDATA tag with this ID. The actor
ID will be created using the data initialized by
the ACTORDATA tag corresponding to this
ID, and will not be created at all if the
ACTORDATA tag is not successfully
initialized. If the actor already has a DATA
tag, then the actor will be created using the
file specified by the DATA tag, but only
if its associated ACTORDATA tag was
successfully initialized. This is useful for
tying graphic actors (such as bullets)
to the successful creation of dynamic
actors (such as headlines).
Smart Screens SmartScreens are the only animations in the 2.0 client that use dynamic actors. While the INITIALIZE section specifies whether or not an individual SmartScreen can be successfully initialized, there is an overall logic that determines which SmartScreen to play next: For each channel in the viewer's selected channel list, attempt to initialize each SmartScreenfor that channel. If all the SmartScreensfail to initialize, clear the ACTORS-SHOWNflags in LCMfor the current channel and then try all the SmartScreens again. If all fail yet again, then on to the next channel. If all channels fail, then play a "house" SmartScreen. Dynamic Actors in 2.0 channels Channels Channel nameactor type example (pcn_actor, actor tag, ss) ,Channel[s], PCN_ACTOR, Channel ACTORS string/inline actors, SmartScreen initialization
Channel
Name ACTORS INITIALIZE
Companies
Industries
Lifestyle
PathFinder
Boston Globe
Chicago Tribune
Globe and Mail
Hot CoCo
LA Times
Mercury Center
Miami Herald
Minneapolis
Star-Tribune
NY Times
Philadelphia
Online
Seattle Times
Tampa Tribune
Wall Street
Journal
CNN
CNNfn
One of the difficulties in the presentation of pushed information results from the fixed association of text and a photograph or an image of some kind and the strong desirability, if not absolute requirement, for displaying the associated information at the same time. In fact, because the text and photograph of an associated pair would not be as interesting or informative if displayed separately, the default for the utilization of such tightly coupled material is to display them together or not at all. This result is somewhat difficult to achieve because the associated material may not all be present when needed or it may not be associated when received by the client. These difficulties are overcome by defining PCN-Actors or data chunks in a dynamic script, where the defined actors are provided with appropriate associative tags that define the associative relationship between text and photographs or other images. In other words, a linked set of text and photograph is created. The iteration code that sequences through the dynamic script would then come across that linked set, and any others, and try to play each of them as a pair, regardless of the order of their constituent data chunks in storage. If, for some reason, the associated text and photograph can't be found, their SmartScreen is not played and the next dynamic actor in the script is displayed. In that manner, client administration is optimized by permitting all playable content, whether or not they comprise associated data chunks, to be used and displayed in the most efficient way. Referring now to FIG. 13, it can be seen that content from local storage means 1310 is accessed by the local content manager 1320, which includes an iterator function and code therefor. Hints in the form of PCN tags are placed in the content in order to aid the iteration process. That content is made available to an animation engine 1330 by the iterator code. In addition, dynamic actors 1340 (a graphic file) and 1350 (a text file) from animation file 1360 are forwarded to the local content manager 1320 for iterated feed to the animation engine 1330. The animation engine 1330 then forwards its output to the display unit 1370 of the client workstation. An example of how the iteration code serves the appropriate content for display is illustrated by FIG. 14. Assume that a first animation script file 1410 holds references to various summaries associated with particular news headlines. Alternatively, the news summary could be and often is replaced by a photograph, chart, illustration or other graphic specifically associated with a particular news headline. A second animation script file 1420 holds the news headlines. In the FIG. 14 example, the delivered content is assumed to comprise several headlines (HL I, HL2 and HL3) and at least two summaries (SUM I and SUM2). The specification for and file format of animation script files as used herein can be found in Appendix I to this specification. When animation script file I is played, it reaches a call for SUM I, accepts that information and causes it to be displayed on the client workstation display 1370. Next, animation script file 2 is played and its call for HL I is responded to causing HL I to be played in a scripted associative fashion with respect to SUM I on the client workstation display 1370. The same routine is followed for display of SUM2 and HL2. The asterisk alongside headlines HL I and HL2 indicates that these headlines have summaries or another item associated with each of them. That is not the case for HL3. When animation script file 1 is next interrogated, its non-associated status is reported, i.e.--there is no SUM3, whereupon the interrogator code causes HU to be played by itself However, had HU been an associated headline, the lack of a SUM3 in the content queue would have resulted in HU being skipped since the display of a headline without its associated summary or photograph is deemed to be undesirable. Further, if there were several dozen or more unassociated headlines present, they would all stand an equal change of being displayed depending on their order in the content queue. The versatility of this approach is to be contrasted with animation code that is embedded in an HTML page and played by a Visual Basic or Java script. The present invention is versatile and content driven while the HTML approach, even with dynamic HTML, is content limited and restricted by its "hardwired" content approach. B. Local Content Manager Content Management Better enable multi-part articles Provide client-level ability to add, delete, reorder etc. content Maintain properties on content (i.e. read or unread) Componentization Embedded third-party browser Constellation, Active Desktop, and JavaStations FIG. 15 shows a structure of a componentized client having a local content manager at its center and interacting with a smartscreen, channel viewer, and fetch engine. Summary The Local Content Manager (LCM) is responsible for serving as well as adding, removing, and modifying properties of all data in the client that is not administrative (administrative data includes software, animations, catalogs, etc.). The LCM works by keeping a record of properties for each data item on the client. These records are created and edited through the use of content wrappers. FIG. 16 shows a relationship between cache files containing data, content tables associated with the cache files, and an index of the content tables, which may be used by a local content manager to manage data in a client.
Content Tables
Content tables are the guts of LCM. Each category ID
will have its own content table, unless the
TABLE_CAT_ID field is set in the category catalog
(in order to share one table across several category IDs).
Field
Name Type Default Description
INDEX Binary Key Unique key for the data item record
(across all LCM tables). The key is
generated by the LCM.
CAT_ID L4 CAT.sub.-- The category ID of the item. This is the
ID item "content" category ID and not the fetch
was category ID (see Category Table). This
fetched value is supplied by the fetch engine if
using nothing is specified in the wrapper.
SEARCH- String8 Search- The Searchstring specifies what Search-
STRING string string, if any, was used to fetch this item.
item This field is necessary so that the client
was can select items for a specific
fetched search-sting (generating article lists
using for listboxes, deleting items after
personalization, etc.).
URL String8 -- Only used for web-fetched category Ids,
this is the absolute URL that this data
item was fetched from. (Need to keep
verified - conditional get - state
per session).
MD5 Binary -- The MD5 checksum of the data item (not
including the wrapper). Needs to be
generated by the feed (to allow for
item-based fetching). Always on the
UNCOMPRESSED data.
ARTI- Binary -- Article_IDs are a property of the data
CLE.sub.-- item and set by the feed. The MD5 check-
ID_MD5 sum (hexadecimal) of the Article ID is
used instead of the Article ID string itself
as an optimization. If just the Article ID
string is specified in the wrapper, then
the client will convert it to an MD5
before inserting in the LCM.
CHIL- Binary -- List of database keys for the children of
DREN this item (20 bytes each, no delimiter).
List is used to overwrite expires
times from parent
MIME.sub.-- String8 -- The MIME type of the data item. (Needs
TYPE to be specified in the wrapper so that
the client can decide whether to fetch
children. For example, the viewer may
not want audio clips automatically
downloaded.)
LOCALE L4 ID of the Win32 locale this category is
intended for.
CHAR- L4 ID of the charset content for this
SET category uses.
CREA- TimeT Time Can be server supplied. If not in the
TION.sub.-- of wrapper, the time at which the item was
TIME fetch inserted in the LCM will be used.
EXPIRA- TimeT Crea- Values: 0.vertline.FFFFFF.vertline.Value
TION.sub.-- tion.sub.-- The time to make A value of 0 is a
"kill,"
DATE Time + this item will be deleted. A value of
Life- FFFFFF means "archive." Unless
span the expiration date is modified, this item
will never be deleted.
SIZE L4 -- The size, in bytes, of the STORED
data item (sans wrapper).
TITLE String- The string to be used for the item in the
8 -- article listbox and for the Headline
actor in the SmartScreen
SHOW.sub.-- L4 -- A numeric value specifying what order the
ORDER sorting priority of the item is. If not
explicitly defined in the wrapper, this field
is left blank. To build an ordered list,
the channel would sort in descending order
(higher values should be higher on the list)
on Show_Order as the first key
and descending order on Creation_Date
as the second key.
ACTORS String8 This is a list of content IDs and what actor
types are available for each. Please see the
PCN_ACTORS section of this spec
for more detail.
Syntax:
<content ID>= <name>[,
<name> . . . ]
[&<content ID>= <name> [,
<name> . . . ] . . . ]
*AC- L4 Bitmask of sorted content IDs indicating
TORS.sub.-- which content IDs have been played.
SHOWN
*READ Bool- 0 A flag that marks whether the item was
ean displayed in the client. The icon for this
item in the article listbox will vary
depending on this flag.
[Reserved
Fields]
* = User-specific fields. Will eventually be moved to separate tables
(necessary for shared or networked LCM).
Using the LCM Here are the interfaces:
///////////////////////////////////////////////////////////////////////////
//
//
// PCNTable
//
#define PCNTABLE_METHODS (IPURE)
.backslash.
XPMethod (SetColumns)
.backslash.
(PPCNPropTagArray lpPropTagArray,
.backslash.
UInt32 ulFlag) IPURE;
.backslash.
XPMethod (GetRowCount)
.backslash.
(UInt32 ulFlags
.backslash.
UInt32 FAR * lpulCount) IPURE;
.backslash.
XPMethod(FindRow)
.backslash.
(LPSPCNRestriction lpRestriction,
.backslash.
UInt32 ulFlags) IPURE;
.backslash.
XPMethod(SortTable)
.backslash.
(LPSPCNSortOrderSet lpSortCriteria,
.backslash.
ULONG ulFlags) IPURE;
.backslash.
XPMethod(QueryRows)
.backslash.
(LONG lRowCount,
.backslash.
UInt32 ulFlags,
.backslash.
LPSPCNRowSet FAR * lppRows) IPURE;
class PCNTable : public XPUnknown
{
public:
PCNTABLE_METHODS (XPPURE);
};
#define LCM_CREATE 0x00000001L
///////////////////////////////////////////////////////////////////////////
//
//
// PCNCache
//
#define PCNCACHE_METHODS(IPURE)
.backslash.
XPMethod (ItemFromURL) (
.backslash.
IN UInt32 ulFlags,
.backslash. IN LPCSTR szURL,
OUT PPCNCacheItem *
ppcacheitm)
IPURE; .backslash.
XPMethod (AddItemFromFile) (
.backslash.
IN UInt32 ulFlags,
.backslash.
IN PPCNProp pProp,
.backslash.
IN LPCSTR szFile,
.backslash.
OUT PPCNCacheItem *ppcacheitm)
IPURE;
.backslash.
XpMethod (ItemFromIndex) (
.backslash.
IN UInt32 ulFlags,
.backslash.
IN UInt32 ulcatid,
.backslash.
IN REFLCMKEY puuidIndex,
.backslash.
OUT PPCNCacheItem *
ppcacheitm)
IPURE; .backslash.
XPMethod (GetTable) (
.backslash.
IN UInt32 ulcatid,
.backslash.
OUT PCNTable ** pptbl)
IPURE;
class PCNcache : public XPUnknown
{
public:
PCNCACHE_METHODS(XPPURE);
};
///////////////////////////////////////////////////////////////////////////
//
//
// PCNCacheItem
//
#define PCNCACHEITEM_METHODS(IPURE)
.backslash.
XPMethod (GetStream) (
.backslash.
IN UInt32 ulReserved,
.backslash.
IN UInt32 ulFlags,
.backslash.
IN XPIIDREF refiid,
.backslash.
OUT PPCNStream * ppstm)
IPURE;
.backslash.
XPMethod (Lock) (
.backslash.
IN UInt32 ulReserved) IPURE;
.backslash.
XPMethod (Unlock) (
.backslash.
IN UInt32 ulReserved) IPURE;
.backslash.
XPMethod (SaveChanges) (
.backslash.
IN UInt32 ulReserved) IPURE;
class PCNCacheItem : public PCNProp
{
public:
PCNCACMEITEM_METHODS(XPPURE);
};
enum { eRead, eTitle, eExpTime, eCreatTime, eSize, eURL, eMDS,
eDBIndex, eContentType, eCatId, eShowOrder,
eArtIdMDS, eChldKeys, eChnlStr1, eChnlStr2,
eChnlBin1, eChnlBin2, eChnlInt1, eChnlInt2,
eActorTypes, eFileId};
#define NUMLCMVARSIZEPROPS 8
#define LCMVARSIZEPROPS .backslash.
{ .backslash.
8 .backslash.
{ .backslash.
XPR_TITLE ,.backslash.
XPR_URL ,.backslash.
XPR_CHLD_KEYS ,.backslash.
XPR_CHANNEL_DATA_STR1 ,.backslash.
XPR_CHANNEL_DATA_STR2 ,.backslash.
XPR_CHANNEL_DATA_BIN1 ,.backslash.
XPR_CHANNEL_DATA_BIN2 ,.backslash.
XPR_ACTOR_TYPES .backslash.
} .backslash.
}
Accessing a Data Item in the LCM through the Localhost Server To enable the use of third-party browsers to render our articles, a localhost server will become part of the client. The localhost server in the 2.0 client will respond to three different request types: MD5 - The combination of category id and MD5 checksum can uniquely identify any LCM data item (actually, just the MD5 is enough to uniquely identify a data item, however the category ID is needed by LCM to select the correct table). By requesting a URL with the following syntax, any LCM item can be accessed from a browser.
address>/v1?catid=<category id>&md5=<md5
checksum>
PointCast content will use root-level URLs for child references (images, etc.) because the LCM localhost could use any port (or any IP, for that matter, in the case of a diskless workstation). For example, a PCNFILE-style image from a 1.x feed would now use the following URL.
<IMG SRC = "/v1? catid=1011&md5=1234567890ABCDF01234">
URL - While URLs are not as unique as MD5s (they're unique at any
point in time, but not over time), they are a very commonly used way
of address data. In addition, for any content that comes from the web
rather than the Data Center, MD5s won't be available. For
these reasons, LCM items can also be accessed using their URL
with the following syntax:
id>&url=<URL-encoded URL>
By using different category IDs, many different web caches can be created. The PointCast 2.0 client will have three, one for the browser, one for the corporate channel, and one for the Connections channel. The equivalent example
<IMG SRC = "/v1?catid=120&url=
http%3A%2F%2Fwww%2Epointcast%2Ecom%2Fimages%-
2Freuter%2Egif">
would retrieve the image that originally came from:
http://www.pointcast.com/images/reuter.gif
PCNEXEC - PCNEXEC commands were used in the 1.x client to force the client to perform some action based on clicking a link in the browser or animation. Because the old PCNEXEC was done at the protocol level, it needs to be modified in 2.0 to support localhost. The new syntax will be: FIG. 17 shows a block diagram a local content management system including relationships between channels, a renderer, a smartscreen, an actor table, a local host server, content tables, a category table, a fetch engine, a fetch item table, and filters. C. Fetching and the Local Content Manager
Fetch Item Table
The Fetch Item table keeps a list of items to fetch,
instructions for fetching them, and the state for each.
Items are created in the Fetch Item table through
personalization. When a viewer personalizes a channel,
what they're really doing is choosing a set of
category ID and search-string pairs that they wish
to "subscribe" to. For each unique combination of
CAT_ID and SEARCHSTRING, a new record will be
created in the Fetch Item table.
Field
Name Type Default Description
INDEX Binary Key Unique key for record
CAT_ID L4 KEY Uniquely identifies the category. This
cat.sub.--id will be used throughout the client
and
Data Center to identify content belonging
to this category.
SEARCH- String8 -- The search-string to use in requesting the
STRING item. For a LastID fetch (see Request.sub.--
Type in the Category table) this fleld can
be blank or provided by a channel based
on personalization (i.e. MSFT, if a viewer
as added Microsoft to the Companies
channel). For the Web Request_Type,
the search-string will be the URL
to update.
FETCH.sub.-- String8 LastID Values:
TYPE LastID.vertline.MD5
.vertline.ArticleID.vertline.Web.vertline.Pre-
filter.vertline.PCNItem
Describes the syntax that will be used to
update this category.
LastID - The "traditional" syntax.
See PCN_HTTP for more detail.
MD5 - A new method that allows for
requesting items individually. The syntax
is outlined in a later section.
ArticleID - A new method that allows for
requesting items individually by type. The
syntax is outlined in a later section.
Web - Used for any category that is up-
dated from a web server using
standard URLs.
Prefilter - Instantiates the Filter for the
fetch item only (no data is requested or
transmitted before the filter is called).
PCNItem - Used for backward compatabil-
ity with old-style custom fetch items
(admin items, weather, etc.)
FILTER GUID Filter to call for this fetch item. (see
Filters section)
CHAN- L4 Used to notify channel when fetching for
NEL_ID this item is completed and for knowing
where in the table to start a fetch so
that the active channel is updated first.
CATE- String8 Reserved for use by the Actor iterator
GORY code (see tbe Dynamic Actors spec).
FETCH.sub.-- L4 Reserved for use in specifying relative
ORDER fetch order of items (either inter-channel,
intra-channel, or both).
FETCH.sub.-- Sring8 Text string to show in menu bar while
MES- fetching. Needs to support variable
SAGE substitution for SearchString.
For example, the company news category
would have "<Searchstring> News" which
would turn into "Getting AAPL News_"
in the title bar.
DATA.sub.-- String8 1 An ordered list of Data Centers from
CEN- which this category can be fetched.
TER_ID Data Centers are identified to the
client through a set of *.dc files
that contain a list of IP addresses and
basic properties of a Data Center.
IN- Boolean 0 Should the registration ID be included in
CLUDE.sub.-- the syntax of requests for this category
REG_ID ID? This field only applies to the
Request_Types LastID and MD5
and not to Web. Including the registration
ID makes a request unique, loggable,
and uncacheable.
NUM.sub.-- L4 10 The number of items that the client should
ITM request for this category. Used for LastID
fetches only.
AU- String8 -- Username and encrypted password.
THEN- Needed for fetching content that uses
TICA- HTTP challenge authentication. The value
TION is stored exactly as it appears in the
HTPP header (password encrypted).
EXPIRA- String8 Number Values: Lifespan.vertline.Num_Keep
TION Lifespan - Use only the expires value to
POLICY expire content
Num_Keep - In addition to using the
expiration date, enforce the Num_Keep
value.
LIFE- L4 259200 The default lifespan for all data items
SPAN 0 fetched on this category in seconds. That
is, if the content itself does not carry an
expires time it's expires time will
default to the time it was fetched plus
this lifespan value.
NUM.sub.-- L4 25 The number of items that should be kept
KEEP in the LCM for any entry in the Fetch
Item table. This entry is used by the
LCM whenever it needs to "cleant" a
table.
LAST.sub.-- TimeT* -- The time when this item was last
UP- successfully updated (200-series
DATED response).
NEXT.sub.-- TimeT* -- The time when this item will again be
UPDATE ready for automatic updating. This value
is supplie by the Data Center.
LAST.sub.-- L4 1 The value of the highest fidotag fetched
ID for this item. The fidotag is a sequential
and incrementing database key that is
unique per data item within a category ID.
The fidotag for each data item is specified
in the data stream header (see PCN.sub.--
HTTP.doc). This field is not used for the
Web Request Type.
*TimeT is the number of seconds since Jan 1,1970 GMT.
NOTE:
For more detail on specifically how some of these fields are used in
fetching, please see Harry Collins' PCN_HTTP spec
(n:
.backslash.ped_pub.backslash.hcollins.backslash.docs.backslash.pcn_http.
doc).
Category Catalog The category catalog is a list of overrides to values in the fetch item table that is fetched from the Data Center. This Data Center-side control extends to the ability to turn category IDs off by changing their status. The catalog itself is a series of HTML like tags--one per category ID. The HTML syntax is used so that backward and forward compatibility are easy to maintain because properties can be added or deleted without affecting existing clients. All of these fields are defined in the fetch item table except for ServerCatID and Status. <CATEGORY *CatID= ServerCatID= Status= DataCenterID= NumItm= NumKeep= IncludeRegID= DefaultLifespan= ExpirationPolicy= > </CATEGORY> *=Required
Field
Name Type Default Description
SERVER.sub.-- L4 ID Specifies the category ID from which
CAT.sub.-- to fetch the item. By default, this is the
ID same as the cat_id. However, the
category catalog can redirect the client
to fetch this category from anywhere,
although the client will still treat
all data fetched from the fetch_cat_id
as though it came from the original
cat_id.
STATUS String8 -- Values: Blocked
Blocked - The client will not fetch this
category until it receives a new category
catalog that does not block this
category.
Fetching
The Process
Fetch item
Pass to filter
Returns properties of file
List of fetch commamds
Process fetch commands
[fetch item]
Insert file and set properties
Finish item
Filters Upon startup of the client, components of the client can register filters to process fetch items. Filters are called by the fetch engine to process data items after they've been fetched but before they're inserted into the content tables (or even before they're fetched, in the case of the Prefilter Fetch_Type). When a filter registers for a category ID it becomes responsible for sequencing the calls to any other filters that might be necessary and passing its results to the wrapper parser (if necessary) or inserting into the content tables. HTML--Scans for images, changes their URLs to use LCM, and adds child fetch commands for them to the wrapper. Also needs to scan for the <TITLE> tag and put it in the wrapper (unless TITLE is already specified in the wrapper). PPA--Turns PPA files into wrapper-based fetch catalogs. ANM--Adds a wrapper with fetch commands for all non-embedded image files. Content Wrapper Content wrappers allow fetched data to communicate its properties, as well as its relationship to order data items. The content wrapper is created at the feed level and is not modified by the client. In fact, the content wrapper is not removed from the file once it is stored on disk so that the LCM tables can be thrown out and rebuilt from the content itself if necessary. Because the wrappers are not removed from the content, ALL wrapped content must be accessed through the LCM. The format of the content wrapper is HTML (what else?) and is designed to be "invisible" to other browsers if the data item itself is HTML. The wrapper consists of a comment that gives the byte-offset of the "actual" data item and then a PCN_ITEM tag that may contain PCN_COMMAND tags as children.
<!--[5-digit byte offset to where content begins]--!>
<PCN_ITEM
Type = Data.vertline.catalog
Offset = [5-digit byte offset to where content begins]
[Content table properties_. (see next section)]
>
<PCN_COMMAND
Type = Child_Fetch.vertline.Force_Fetch.vertline.Set_Props
[Content table properties_. (see next section)]
</PCN_COMMAND>
</PCN_ITEM>
[Content_.]
5-digit byte offset--The byte-offset is an LCM optimization that also allows clients that don't support LCM a way to strip the wrapper without having to parse it. The five-digit number must be at bytes 5-9 of the file. There are two types of PCN_ITEMs: Data--If a PCN_ITEM tag is the Data type, its properties apply to the actual wrapped data item. Catalog--Catalog is identical to Data except that it doesn't have any content--it is just a wrapper. Catalog PCN_ITEMS can be used for catalog fetching, issuing kills, reordering data items, etc. There are three types of PCN_COMMANDs: Child_Fetch--The child_fetch type is used to force the fetch of an item that is needed by the PCN_ITEM (i.e., an image in an article). Once the item is fetched, it is then added to the Children list of the PCN_ITEM (see Content Table). The PCN_COMMAND tag for a child MUST contain the CAT_ID and either the MD5 or the ARTICLE_ID_MD5, because these values are necessary for both checking to see if the item is already present, and if not, for fetching it. Force_Fetch--Force_Fetch is identical to Child, except that the item is not added to the PCN_ITEM's list of children. Set_Props--A Set_Props PCN_COMMAND updates the properties of the specified item. If the item is not present, no action is taken. Wrapper Fetch Commands: MD5 and ArticleID fetching To enable the effective fetching of individual items (the CHILD_FETCH and FORCE_FETCH PCN_COMMAND types), two new fetch MD5 Fetching MD5 requests can be bundled into single requests. Initially, there will only be one category ID used for this style of fetching. However, this category ID is in essence a "back door" for fetching any item based on its CAT_ID and MD5. /FIDO-1/<special MD5 CatID>-1?cm+<Any CatID>_<MD5 of desired item>[+cm+<Any CatID><MD5 of desired item>_] Article ID MD5 Fetching This type of fetching works identically to MD5 fetching, however since Article IDs are not guaranteed to be unique, the service agent should always return the newest, and only the newest, item matching the request. /FIDO-1/<special Article ID MD5 CatID>-1?cm+<Any CatID>_<MD5 of the Article ID of desired item[+cm+<Any CatID>_<MD5 of the Article>_] D. Version Control Overview | ||||||