Source: http://www.google.com/patents/US20070033293?dq=U.S.+Patent+No.+4,528,643
Timestamp: 2017-09-26 03:13:24
Document Index: 34858886

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'art 1100', 'art 1200', 'art 1300']

Patent US20070033293 - Techniques for delivering personalized content with a real-time routing network - Google Patents
Techniques for dynamically updating a live object with personalized content for clients are provided. The techniques include receiving a first message from a source including a first identifier and a second identifier. The first identifier may be unique to a client. The second identifier may be generic...http://www.google.com/patents/US20070033293?utm_source=gb-gplus-sharePatent US20070033293 - Techniques for delivering personalized content with a real-time routing network
Publication number US20070033293 A1
Application number US 11/515,233
Also published as EP1784963A1, EP1784963B1, US7814225, US7930362, US20060041681, US20110161458, WO2006023459A1
Publication number 11515233, 515233, US 2007/0033293 A1, US 2007/033293 A1, US 20070033293 A1, US 20070033293A1, US 2007033293 A1, US 2007033293A1, US-A1-20070033293, US-A1-2007033293, US2007/0033293A1, US2007/033293A1, US20070033293 A1, US20070033293A1, US2007033293 A1, US2007033293A1
Inventors Karl Rumelhart
Original Assignee Shaw Parsing, L.L.C.
Patent Citations (60), Referenced by (17), Classifications (22), Legal Events (4)
Techniques for delivering personalized content with a real-time routing network
US 20070033293 A1
Techniques for dynamically updating a live object with personalized content for clients are provided. The techniques include receiving a first message from a source including a first identifier and a second identifier. The first identifier may be unique to a client. The second identifier may be generic across many clients. The first message includes information for updating a property of a live object associated with the second identifier. A client specific to the first identifier may be identified. A second message may then be routed through a network to the client. The second message may include the first identifier and the second identifier and also may contain information for updating a property of the live object associated with the second identifier. The client may receive the second message and may be capable of causing an update of the property of the live object associated with the second identifier.
31. A method for updating live objects using a real-time routing network, the method comprising:
transmitting personalized information for a user over a real-time routing network, wherein the personalized information is transmitted from a content source to at least one dynamically updatable live object resident on a client; and
in response to an update message directed to update the personalized information, updating the at least one live dynamically updatable object, wherein the update message comprises identification information of the at least one dynamically updatable live object and data used to update the personalized information with content personalized for the user.
32. The method of claim 31, wherein the at least one dynamically updatable live object comprises identification information associated with the user.
33. The method of claim 31, wherein the at least one dynamically updatable live object comprises generic identification information associated with a plurality of users.
34. The method of claim 31, wherein the at least one dynamically updatable live object contains both the personalized information and generic information.
35. The method of claim 31, wherein the dynamically updatable live object is included in a data representation at the client.
36. The method of claim 31, further comprising transmitting from the content source to a plurality of clients over the real-time routing network a plurality of dynamically updatable live objects containing personalized information for a plurality of users.
37. The method of claim 36, wherein transmitting comprises delivering the dynamically updatable live objects using a batch process.
38. A system for updating live objects using a real-time routing network, the system comprising:
a computer readable storage medium coupled to the processor, wherein the computer readable storage medium includes instructions stored therein for directing the processor to update dynamically updatable live objects, the instructions comprising:
code for transmitting personalized information for a user over a real-time routing network, wherein the personalized information is transmitted from a content source to at least one dynamically updatable live object resident on the client; and
code for updating the at least one live dynamically updatable object in response to an update message directed to update the personalized information, wherein the update message comprises identification information of the at least one dynamically updatable live object and data used to update the personalized information with content personalized for the user.
39. The system of claim 38, wherein the at least one dynamically updatable live object comprises identification information identifying the user.
40. The system of claim 38, wherein the at least one dynamically updatable live object comprises group identification information associated with a group of users.
41. The system of claim 38, wherein the at least one dynamically updatable live object comprises generic identification information associated with a plurality of users.
42. The system of claim 38, wherein the at least one dynamically updatable live object comprises a message pertaining to a group of users associated with the user.
43. The system of claim 38, wherein the content source comprises a plurality of content sources.
44. The system of claim 38, further comprising code for batch processing a plurality of personalized information for transmission to a plurality of users over the real-time routing network.
45. A real-time routing network for dynamically updating live objects, the network comprising:
a node configured to route personalized information pertaining to a user from a content source to a client over the real-time routing network, wherein the personalized information is used to update one or more live dynamically updatable objects resident on the client associated with the user; and
in response to an update message directed to update personalized information for the one or more live dynamically updatable objects, the node is configured to identify and route the update message to selected ones of the one or more live dynamically updatable objects, wherein the update message comprises identity information pertaining to the selected ones of the one or more live dynamically updatable objects and data used to update the personalized information with content personalized for the user.
46. The network of claim 45, wherein the one or more live dynamically updatable objects comprise at least some user identification information.
47. The network of claim 45, wherein the one or more live dynamically updatable objects comprise at least some identification information associated with a plurality of users.
48. The network of claim 45, wherein when the format of the personalized information is different between a content source format and a client format, the node transforms the format of the personalized information between the source format and the client format.
49. The network of claim 45, wherein the node is configured to extract the identification information from the update message.
50. The network of claim 45, further comprising a plurality nodes wherein at least one node maintains a list of identification information pertaining to the one or more live dynamically updatable objects and clients associated with the one or more dynamically updatable live objects.
This application claims priority from co-pending U.S. Provisional Patent Application No. 60/602,539, filed Aug. 17, 2004, entitled “TECHNIQUES FOR DELIVERING PERSONALIZED CONTENT WITH A REAL-TIME ROUTING NETWORK, MODULAR EVENT-DRIVEN ARCHITECTURE, MODULAR EVENT-DRIVEN PROCESSING AND VIEWER FAILOVER TESTING A SYSTEM MEMORY WHILE AN OPERATING SYSTEM IS ACTIVE”; and is a continuation in part of U.S. patent application Ser. No. 10/017,182, entitled “ASYNCHRONOUS MESSAGING USING A DYNAMIC ROUTING NETWORK”, filed Dec. 14, 2001, which claims priority from U.S. Provisional Application No. 60/256,613, filed Dec. 18, 2000, U.S. Provisional Application No. 60/276,847, filed Mar. 16, 2001, U.S. Provisional Application No. 60/278,303, filed Mar. 21, 2001, U.S. Provisional Application No. 60/279,608, filed Mar. 28, 2001, U.S. Provisional Application No. 60/280,627, filed Mar. 29, 2001. All of the above applications are hereby incorporated by reference, as if set forth in full in this document, for all purposes.
Embodiments of the disclosure generally relate to transferring information through networks and in particular to transferring personalized information for remotely updating content at client devices through the networks.
Users may download many different kinds of content from the World Wide Web. For example, users may download content using web pages. In some cases, users may subscribe to services that send content that the users' desire to the web pages. Content providers may need to keep track of which users registered for which content. In addition to keeping track of which users registered for which content, the service providers may also need to know how to send the content that each user registered for. This may require a large amount of resources to keep track of the users who have registered, the content each user desires, and how to route the content to the users.
FIG. 7 is a block diagram illustrating a lower-level view of the routing network according to an embodiment;
FIG. 8 is a flow chart illustrating steps performed by a node in a cluster to perform object-based routing of a message received from an input source via the gateway;
FIG. 9 depicts an example of a web page according to one embodiment;
FIG. 10 depicts a system for delivering personalized messages using routing network 110 according to one embodiment;
FIG. 11 depicts a simplified flowchart for generating a batch message according to one embodiment;
FIG. 12 depicts a simplified flowchart of a method for routing a batch message to a client according to one embodiment; and
FIG. 13 depicts a simplified flowchart for a method for processing a batch message at a client according to one embodiment.
A further understanding of the nature and the advantages of the embodiments disclosed herein may be realized by reference of the remaining portions of the specification and the attached drawings.
In one embodiment, personalized content may be provided to remote clients using a dynamic content routing network. The dynamic content routing network is described first and then delivering personalized content to clients is described.
Dynamic Content Routing Network
Preferably, the information provider 108 provides web pages or other representations of data to the server 112. The web pages contain one or more “live objects,” which are designated to be real-time dynamically updateable objects. Each live object is identified by an object identifier, or object D. Preferably, the server 112 provides the pages 118 to multiple clients 114. The clients 114 contact the routing network 110 and register for update messages for the object IDs on the web page. The routing network 110, in turn, preferably maintains a registry indicating which clients have registered for which object IDs.
The mapping and object-based routing provided by the routing network 110 allow the information provider 108 and dynamic content provider 116 to update properties of live objects at a dynamically changing cross-section of clients in real-time, without requiring the information provider or dynamic content provider to track the clients or web pages being viewed by the clients. The clients 114, in turn, do not need to have any a priori knowledge of object IDs—they “discover” which IDs they should register when they receives the pages 118 from the server 112.
Turing now to the individual entities illustrated in FIG. 1, the server 112 is preferably a conventional computer system configured to act as a web server and serves pages 118 and other data representations to clients 114. The pages 118 provided by the server 112 are associated with one or more information providers 108.
An information provider 108 is an entity providing one or more pages 118, information contained in web pages, and/or other representations of data served by the server 112. The information provider 108 preferably has a conventional computer system coupled to the Internet. In one embodiment, the server 112 is directly controlled by the information provider 108 (e.g., the server is physically located at the information provider and/or is dedicated to serving only the information provider's web pages). In this embodiment, the server 112 and information provider 108 can be treated as the same entity. In an alternative embodiment, the server 112 serves web pages from multiple information providers.
As is known in the art, the pages 118 and other content on the server 112 are specified by uniform resource locators (URLs) having the form “service://server/path/web page.” Typically, pages 118 are obtained via the hypertext transport protocol (HTTP) and thus an exemplary URL for retrieving the web page “b1.html” from the web server having the domain name “www.bangnetworks.com” is “http://www.bangnetworks.com/news/b1.html.”
As used herein, a “web page” is a block of data available from the server 112. In the simplest case, a web page is a file written in the hypertext markup language (HTML). The web page may also contain or refer to one or more other blocks of data, such as other files, text, images, applets, video, and/or audio. In addition, the web page may contain instructions for presenting the web page and its content, such as HTML tags and style sheets. The instructions may also be in the Extensible Markup Language (XML), which is related to HTML and adds semantic content to web pages or the Dynamic HTML (DHTML), which adds some dynamic content to web pages. Additionally, the instructions may take the form of one or more programs such as JAVA® applets and JAVASCRIPT® and/or DHTML scripts.
An information provider 108 or other entity preferably updates a live object at a client 114 via an update message. In general, an update message identifies the live object and, if necessary, the property of the live object, and contains data for updating the property.
In one embodiment, the data may be the actual value for the property or executable code for causing the object's property to be updated. For example, the data may be a simple numerical or textual value, e.g., “4,” to which the property should be set, and/or the data may be JAVASCRIPT® code or a call to a JAVASCRIPT® function at the client that effects the desired change to the property of the object.
The update message preferably implicitly or explicitly identifies a handler at the client 114 for use in updating the live object's property. In one embodiment, the client 114 utilizes a default handler when the message implicitly specifies the handler (e.g. when the message does not identify a specific handler). In one embodiment, if the update message specifies the actual value for the property, a default handler generates JAVASCRIPT® code for changing the property to the specified value. If the data in the update message are JAVASCRIPT® code, the default handler does not perform any processing of the code. In either case, the default handlers preferably use LiveConnect to execute the JAVASCRIPT® code in a Java Virtual Machine (JVM) 122 at the client 114 and thereby update the property of the live object.
For certain objects and/or data types, the default handlers are not appropriate. In these cases, the message preferably explicitly identifies a handler for performing the update. For example, the message may explicitly specify a function to call on the data or the message may explicitly identify the environment in which the data should be executed. For example, the data in the update message may include code for execution by a software “plug-in” such as MACROMEDIA FLASH® and the message may explicitly identify FLASH as the handler.
where “elementIdentifier” is the object ID and is preferably a string. The string can encode any information desired by the information provider 108 or other entity establishing the object ID and in one embodiment is a simple textual and/or numeric identifier. In one embodiment, the information provider 108 begins the object ID with a predefined token, such as “Bang$,” in order to distinguish live objects from other objects that happen to have defined ID attributes. For example, an object can have the object ID “Bang$elementldentifier.”
In the preferred embodiment, each information provider 108 optionally encodes a unique information provider ID in its object ID in order to prevent naming collisions between the object IDs of different information providers. In one embodiment, the information provider ID is a textual and/or numeric identifier. The information provider 108 may specify the information provider ID and the object ID as part of a hierarchical namespace. For example, in one embodiment objects are named as follows: “$namespace1$[namespace2$ . . . $namespaceN$]objectId,” where “$namespace1” is the information provider ID and the “$” operates as the name separator and defines additional optional levels of a namespace hierarchy. One embodiment of the system 100 supports typical directory services functionality. For example, two dollar sign characters appearing together, “$$,” refers to the top level of the namespace hierarchy.
Thus, the object ID for a live object is preferably formed from a combination of the predefined token, the information provider ID namespace, and a value assigned by the information provider 108. For example, the object ID for a live object representing the real time price of a stock having the symbol “BANG” might be: “Bang$$informationProviderID$equities$realtime$bang.” In this example, “Bangs” is the predefined token that signifies a live object, “$informationProviderID” is the ID identifying the information provider, “$equities$realtime$” defines levels of a namespace hierarchy, and “bang” identifies the specific object.
The client 114 is a device that retrieves pages 118 and/or other information from the server 112. In one embodiment, the client 114 is a conventional personal computer used by a person to access information on the Internet. In alternative embodiments, the client 114 is a different consumer electronic device having Internet connectivity, such as an Internet-enabled television, a cellular telephone, a personal digital assistant (PDA), a web browsing appliance, etc. The client 114 preferably, but not necessarily, has an associated display device.
The client 114 preferably executes a web browser 120, such as MICROSOFT INTERNET EXPLORER®, for retrieving web pages and displaying them on the display device. In embodiments where the client receives data representations from the server 112 other than conventional web pages, the web browser 120 does not necessarily share similarities with conventional web browsers. Preferably, the web browser 120 contains a JVM 122 for executing JAVA® applets and/or scripts. The web browser 120 also preferably contains Dynamic HTML capabilities, such as support for JAVASCRIPT® (or another scripting language, such as VBScript) and the Document Object Model (DOM), and enables communications between JAVA® and the scripting languages. In one embodiment, the web browser 120 supports the LiveConnect standard for enabling communication between JAVA® applets and scripts written in the supported scripting languages. The web browser 120 can also be extended through software plug-ins such as MACROMEDIA FLASH®, REAL NETWORKS REALPLAYER®, and/or APPLE QUICKTIME®. In alternative embodiments, the functionality of the JVM® 122 and/or other aspects of the web browser 120 are provided by one or more other functional units within the client 114. The term “module” is used herein to refer to software computer program code and/or any hardware or circuitry utilized to provide the functionality attributed to the module. The web browser 120 and JVM 122 are examples of modules in the client 114.
A page 118 provided from the server 112 to the client 114 preferably includes instructions for enabling the live objects on the web page. The instructions cause the client 114 to automatically and transparently (i.e., without user interaction) contact the routing network 110 and download an activation module 124 for activating the live objects. In one embodiment, the instructions comprise a URL specifying the location of the activation module 124 at the routing network 110. In an alternative embodiment, the client 114 obtains the activation module 124 from the server 112 or another source.
The activation module 124 preferably contains JAVA® instructions for execution by the JVM 122. However, alternative embodiments of the module 124 may encode the instructions in the page 118 and/or the activation module 124 using different languages and/or techniques. For example, the instructions and/or activation module 124 can be embedded in the web browser 120 or operating system, either as native code or as plug-ins. In these alternative embodiments, the web browser 120 does not have to download the activation module 124 from an external source.
The activation module 124 preferably registers object IDs from the page 118 downloaded by the client 114 with the routing network 110 and updates the live objects in response to update messages received from the network. The routing network 110 records the registrations in the registry 125. The client's registrations preferably remain in effect as long as the client is displaying the associated page 118, although other embodiments of the system 100 may use different criteria for determining when to terminate the client's registrations.
At some point, the input source 210 sends 224 an update message to the routing network 110 in order to change a property of a live object at the client 114. In one embodiment, the message from the input source 210 to the routing network 110 contains only a single object ID and an update to a property of the identified object. In another embodiment, the message contains multiple object IDs and the corresponding property updates. In this latter embodiment, the message may have an associated “Batch ID” that identifies the message as having multiple object IDs and updates. Preferably, the information provider 108 can include a batch ID in a page 118 in the same manner as including an object ID. Likewise, the client 114 can preferably register for a batch ID with the routing network 110 in the same manner as an object ID. In fact, the batch ID can be the same as the object ID so that the client 114 registers for both batch and non-batch messages by registering one ID. Alternatively, separate procedures can be established for registering batch messages. The client 114 preferably processes the component messages of a batch as if each message were delivered separately.
FIG. 3 is a high-level diagram graphically indicating the many-to-many mapping performed by the routing network 110. Multiple input sources (labeled 210A-C) send update messages to the routing network 110. Each update message preferably specifies at least one object ID and an update to a property of the identified object. The routing network 110, in turn, selectively routes the update messages to the clients 114 that have registered for the given object ID from the given input source 210. In FIG. 3, assume for example that clients 312A and 312B have registered for a given object ID while the other clients have not registered for the object ID. Accordingly, the routing network 110 routes the update message to clients 312A and 31213, but does not route the message to clients 312C-312H.
In another embodiment, the input source 210 utilizes a director console module 512 to access the API. Preferably, the director console module 512 presents an administrator with a graphical interface displaying the contents of the page 118. For example, the administrator may use the director console 512 to edit textual data, images, and/or any objects or properties of objects on the web page. After editing, the administrator uses a “send update” button or similar technique to cause the director console module 512 to send messages for the changed objects and properties to the routing network 110 via the API.
In another embodiment, the information provider 108 and dynamic content provider 116 work together as the input source 210 by using a content management system module 514 to access the API. Preferably, the content management system module 514 resides at the information provider 108 and receives object property updates from the dynamic content provider 116. The content management system module 514 preferably updates the properties of the live objects in the page 118 stored at the server 112 and also sends messages for the changed properties to the routing network 110. In this manner, the page 118 at the server 112 and the web page displayed at the client 114 are updated almost simultaneously. In one embodiment, the dynamic content provider 116 sends the update messages to the routing network 110 instead of to the information provider 108. Embodiments of the system 100 can also utilize any combination of the content management techniques described herein.
LiveObject score=new LiveObject(“Bang$homeScoreID”); score.setProperty(“innerText”, “2”).
In order to register object Ds, the activation module 124 preferably parses 610 the page 118 received from the server 112 and identifies the object IDs of the live objects. In an alternative embodiment, the activation module 124 identifies only a subset of the object IDs, such as the IDs of only live objects that are currently being displayed by the web browser 120. Alternatively, a list of object IDs may be pre-encoded in the web page in addition to the objects themselves, thereby enabling easy identification by the activation module 124. In yet another embodiment, a user of the client 114 selects the object IDs to register.
The activation module 124 preferably opens 612 a connection between the client 114 and the routing network 110. The activation module 124 can open 612 this connection before or after the activation module receives and/or parses the page 118. In some cases, the client 114 is located behind a firewall that puts a restriction on the types of connection requests the client can make. A firewall might, for example, block all non-HTTP traffic. For this reason, the activation module 124 preferably wraps the connection request in an HTTP header in order to get the request to the routing network 110 through the firewall.
The sequence of receiving messages 618, extracting data 620, and updating objects 622 is preferably repeated until a new page is loaded 616 or the connection with the routing network 110 is otherwise terminated. Although not shown in FIG. 6, in certain circumstances, such as when a user action with respect to the page 118 activates a new live object, the activation module 124 may register new object IDs with the routing network 110 without first downloading and parsing a new page. In one embodiment, if the newly-loaded page contains live objects, then the process of downloading the activation module 124 and updating the objects as described by FIG. 6 is repeated. In an alternative embodiment, the activation module 124 remains active at the client 114 and, therefore, the client does not re-download the activation module from the routing network 110. Instead, the already-present activation module 124 performs the live-enabling process on the new page.
FIG. 7 is a block diagram illustrating a lower-level view of the routing network 110 according to an embodiment of the present invention. Those of skill in the art will recognize that there are many alternative ways to implement the functionality of the routing network 110. FIG. 7 illustrates multiple input sources (labeled 710A-D) representative of sources providing messages to the routing network 110, such as an information provider 710A and a dynamic content provider 710B. FIG. 7 also illustrates multiple clients (labeled 712A-F) representative of the many clients in communication with the routing network 110 at any given instant.
Preferably, the routing network 110 utilizes conventional single-processor computer systems executing the Linux operating system (OS). Preferably, each component of the routing network 110 is implemented by a separate, dedicated computer system in order to enable the separate optimization of the components. The input/output (I/O) functionality of the OS is preferably enhanced through the use of a non-blocking OS package such as NBIO available from the University of California, Berkeley, Calif. Based on the assumption that connections with the nodes 728 are long-lived, the OS is preferably configured to not allocate resources toward monitoring idle connections. Instead, the well-known /dev/poll patch is preferably applied to the OS in order to provide advanced socket polling capabilities.
Delivering Personalized Content Using the Dynamic Content Routing Network
FIG. 9 depicts an example of a page 118 according to one embodiment. In one embodiment, page 118 may be a web page. In other embodiments, page 118 may be any page generated by a software application, such as a word processing document, a spreadsheet, an email, etc. As shown, page 118 includes a plurality of sections 902, such as a market data section 902-1, a news headline section 902-2, a recent trades section 902-3, and an account balances section 902-4. Although these sections are shown, it will be understood that any number of sections may be provided in page 118.
In one embodiment, page 118 may be provided by a web-based application. Routing network 110 may be used to deliver purchase prices for stocks and bonds to a large number of clients 114. Each client's page 118 may include the same sections 902, but information for a certain section 902 may be personalized (e.g., different) for each user. For example, market data section 902-1 may be the same for all the users. However, recent trades section 902-3 and account balances section 902-4 may be personalized for each user. For example, the recent trades made by a specific user and their account balances may be personal to a user, and may only be sent to the specific user. Accordingly, personalized information may be any information specific to a user. It should be understood that different users may have personalized information that may be substantially the same; however, the personalized information for each user would be specific to each user.
In one embodiment, when a trade closes for a given user, only his/her page 118 should be updated (e.g., under the recent trades section 902-3). Accordingly, personalized information should only be sent to this user.
In one embodiment, different content for section 102 may be delivered by different input sources 210. For example, an input source 210 may provide content for news headline section 902-2 and another input source 210 for market data section 902-1. In addition, real-time data may be provided by multiple input sources 210. Input source 210 may be located remotely from routing network 110 and client 114, or may be, in other embodiments, part of routing network.
The real-time information sent to page 118 may be delivered using routing network 110. In one embodiment, each stock 904 may be assigned an ID, and messages published to that ID may be delivered to every user. A live object may be then be updated. A live object may be any data that can be updated. For example, a live object may be any data included in a data representation for page 118, such as software code for displaying an element of page 118, an element being displayed on page 118, etc. In addition to the generic information, personalized information may be delivered to recent trades section 902-3 and account balances section 902-4. Further, a combination of generic and personal information may be delivered for a section. For example, generic and personal information may be delivered to news headline section 902-2.
In one embodiment, in order to deliver personalized messages to users, a batching capability of routing network 110 may be used. In this embodiment, each user may be assigned a personalized ID. The personalized ID may be unique or specific to the user. As will be discussed below, the personalized ID may also be specific to a group of users and not just one user. The personalized ID can be put anywhere in a data representation for their page 118 (such as in the body tag of software code for page 118). Live objects in the data representation may then be associated with generic IDs. The live objects may be found in a page 118 and personalized information may be displayed for the live objects. The generic IDs may be the same for a plurality of users. For example, recent trades section 902-3 of a web-based trading application may be marked with the ID “recentTradesID”. This ID may be the same for every user's page 118, even though personalized information may be displayed there for each user.
In one embodiment, input source 210 provides a batch message using the following format [personalizedID, (genericID #1, “personalized information #1”), (genericID #2, “personalized information #2”)]. PersonalizedID may be an ID personalized to a user. Generic[D #1 and genericID #2 may be an IDs generic across many users. Personalized information #1 and #2 may be any information that can be used to update a page. In one example, a message for account balances may be sent in the above batch message using the following message, [personalizedID, (accountbalancesID, “balance information”), . . . ]. This message may be used to update the account balance of a user's account with personalized information for the user.
Routing network 110 delivers the batch message to a user registered for the personalized ID. When the batch message arrives at a client 114 associated with the user, it may be treated as if the messages (genericID #1, “personalized information #1”) and (genericID #2, “personalized information #2”) were sent to client 114. The personalized ID may not be used after the message is received.
In one embodiment, the browser of client 114 evaluates a data representation for page 118 and finds the IDs of genericID # 1 and genericID #2. Live objects on page 118 may be updated with personalized information #1 and #2. An information provider does not need to know or understand the structure of the user's page 118. Also, because update messages may not include any DOM information, the message itself is simple. For example, if one of the messages may be (accountbalancesID, “balance information”), the browser of the client may update account balances section 902-4 with the information as specified by the update message (i.e., the “balance information” of the update message).
Thus, personalized information for multiple users may be sent to a generic ID that may be used to update live objects included on pages 118 for multiple users. The personalized ID may be used to send personalized information to a user using the above-referenced batch message techniques. Because the live objects may have identical IDs, an input source 210 can deliver multiple personalized messages to the same generic ID for a live object. This reduces the number of IDs that may be used.
FIG. 10 depicts a system 1000 for delivering personalized messages using routing network 110 according to one embodiment. System 1000 includes a plurality of clients 114, routing network 110, and an input source 210.
Input source 210 may be capable of sending personalized messages using the batching capability of routing network 110. As shown, three batch messages, messages #1, #2, and #3, may be sent by input source 210. Messages #1, #2, and #3 may be sent to three different personalized IDs: personalized ID #1, personalized ID #2, and personalized ID #3. A batch message includes a message sent using the generic IDs of recentTradesID and accountbalancesID. Personalized information, however, may be included in each message for the IDs of recentTradesID and accountbalancesID for different users.
The three messages may be sent from input source 210 to routing network 110. Routing network 110 determines which clients 114 have registered for the personalized IDs. As shown, a client 114-1 has registered for personalized ID #1, client 114-2 has registered for personalized ID #2, and client 114-3 has registered for personalized ID #3. Accordingly, message #1 may be sent to client 114-1 because that client 114-1 (or a user) has registered for personalized ID #1. Further, message #2 and message #3 have been sent to client 114-2 and client 114-3 because those clients 114-2 and 114-3 have registered for the corresponding personalized IDs #2 and #3, respectively. Clients 114-1, 114-2, and 114-3 can then update their pages 118 with the information provided for the IDs of recentTradesID and accountBalanceID. As shown, client 114-1 has displayed personalized trade information #1 and personalized balance information #1, client 114-2 has displayed personalized trade information #2 and personalized balance information #2, and client 114-2 has displayed personalized trade information #3 and personalized balance information #3.
Accordingly, three messages may be sent with information for the generic ID recentTradesID. However, using a batched message, the message may be sent to three different clients 114. Thus, client 114 may receive personalized information for the generic
FIG. 11 depicts a simplified flowchart 1100 for generating a batch message according to one embodiment. In step 1102, an input source 210 determines personalized information for a user.
In step 1104, a personalized ID and generic ID for the personalized information may be determined. In one embodiment, input source 210 does not need to know where or how to send the personalized information to a user. Rather, input source 210 may associate the personalized information with a generic ID and generate a batch message that may be sent to the personalized ID.
In step 1106, a batch message may be sent with the personalized ID to routing network 110. The format of the batch message may be sent as described above or through any other formats. Accordingly, input source 210 may send a batch message to the personalized ID. How or where to route the message to a user may not need to be determined by input source 210. Rather, routing network 110 may route the batch message as described below.
FIG. 12 depicts a simplified flowchart 1200 of a method for routing a batch message to a client 114 according to one embodiment. In step 1202, the batch message may be received from input source 210. In step 1204, a client 114 may be determined that may be registered for the personalized ID) found in the batch message. In one embodiment, a client 114 may download an activation module 124 and register IDs with routing network 110. This process is described in more detail above. When a batch message is received from input source 210 for the personalized ID, routing network 110 may route the batch message to client 114 using the personalized ID in step 1206.
FIG. 13 depicts simplified flowchart 1300 for a method for processing a batch message at a client 114 according to one embodiment. In step 1302, a batch message may be received from routing network 110. The batch message may be directed to a personalized ID) and routed according to preferences associated with the personalized ID. For example, the personalized ID may be associated with an IP address and the message may be received at a client 114 corresponding to that IP address.
In step 1304, a generic ID in the batch message may be determined. This generic ID may be the same ID that may be found on multiple users' pages 118.
In step 1306, personalized information for the generic ID may be determined. For example, the personalized information may be personalized information and may be specific to the client 114.
In step 1308, a live object may be updated with the personalized information using the generic ID. For example, client 114 may determine a live object on page 118 that may be associated with the generic ID. A property of a live object may be updated with the personalized information.
For example, referring to FIG. 9, a live object may be found in recent trades section 902-3 of page 118. A recentTradesID may be included in a data representation for page 118. Client 114 thus displays the personalized information corresponding to a position as referenced by the ID of recentTradesID in the data representation for page 118. Accordingly, routing network 110 or the input source 210 may not need to understand the structure or DOM of a user's page 118. Client 114 may be able to update recent trade section 902-3 as specified by the personalized information for recentTradesID.
The same generic ID may also be used in cases where some messages may be intended for a wide audience (e.g., not personal) and others may be personalized, such as in news headline section 902-2 of page 118. For example, input source 210 may send standard headlines to users, using a generic ID, such as the following message, <NewsheadlineID>, <“News headline information”>, and send personalized messages using a batch message, such as [<personalizedID>, (<NewsheadlineID>, <“Personalized news headline information”>)]. The first message may send news headline information to any users that subscribe to the ID of NewsheadlineID and the second message may send personalized news headline information to the user associated with personalizedID. Accordingly, the same generic ID may be used to send standard headlines that may be sent to all users. The generic ID may also be used as a personalized ID by sending a batch message to the personalized ID for a user. Personalized headlines may be sent to a user associated with the personalized ID. An information provider 210 may switch back and forth between standard headlines and personalized headlines for generic IDs.
The batch message may also be used to send semi-personalized messages, i.e., messages to groups rather than individuals. Just as an individual user may have a live object associated with the personalized ID somewhere on his/her page 118, members of a group can have a live object for a group personalized ID located on their pages 118. To send a group of users a message within the news headline section 902-2 of their pages 118, information provider 214 may use a batch message sent to a group personalized ID, such as [<groupPersonalizedID>, (<newsheadlineID>, <“personalized group headline information”>)]. All (and only) members of the group may receive this message because they may be associated with the group personalized ID. This technique may not require that members of the group are viewing identical pages. Rather, members of the group may display the information for newsheadlineID in whichever way they desire.
Accordingly, a batch message may be used to send personalized information that may be associated with generic IDs; however, the batch message may be sent to a personalized ID specific to a user. Accordingly, the number of IDs used by a content provider 214 may be minimized. However, the power of sending personalized messages may still be maintained using the personalized IDs.
In one embodiment, the term “and/or” may indicate that any combination of elements connected by “and/or” may be used. For example, two words or expressions in a phrase using “and/or” may mean one or the other or both. In one embodiment, the term “substantially” may mean being largely but not wholly that which may be specified, or all that may be specified. In one embodiment, the term capable of may mean configured, adapted, able, etc. For example, the term capable of performing an action may mean an element may be able to perform the action, may be configured to perform the action and/or may be adapted to perform the action.
Embodiments of the disclosure can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in one embodiment. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the disclosure.
The above description is illustrative but not restrictive. Many variations of the disclosure will become apparent to those skilled in the art upon review of the disclosure. The scope of the disclosure should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
US5699523 * Jun 5, 1996 Dec 16, 1997 Bull S.A. Method and apparatus for communication between at least one client and at least one server
US5938733 * Mar 8, 1996 Aug 17, 1999 International Business Machines Corporation Object oriented representation of network requests in a client server model
US6314459 * Aug 13, 1998 Nov 6, 2001 U.S. Philips Corporation Home-network autoconfiguration
US6366926 * Dec 31, 1998 Apr 2, 2002 Computer Associates Think, Inc. Method and apparatus for the dynamic filtering and routing of events
US6449638 * Jun 30, 1998 Sep 10, 2002 Microsoft Corporation Channel definition architecture extension
US6460036 * Dec 5, 1997 Oct 1, 2002 Pinpoint Incorporated System and method for providing customized electronic newspapers and target advertisements
US6725446 * Nov 1, 2000 Apr 20, 2004 Digital Integrator, Inc. Information distribution method and system
US7107326 * Nov 27, 2000 Sep 12, 2006 3Com Corporation Method and system for integrating IP address reservations with policy provisioning
US7139844 * May 31, 2001 Nov 21, 2006 Goldman Sachs & Co. Method and system for processing financial data objects carried on broadcast data streams and delivering information to subscribing clients
US7249197 * Oct 20, 2000 Jul 24, 2007 Nortel Networks Limited System, apparatus and method for personalising web content
US7263547 * Jun 28, 2001 Aug 28, 2007 Ianywhere Solutions, Inc. System, method, and computer program product for customizing channels, content, and data for mobile devices
US7293074 * Sep 19, 2000 Nov 6, 2007 Fusionone, Inc. Performing server actions using template with field that can be completed without obtaining information from a user
US7350213 * Jun 19, 2003 Mar 25, 2008 Sap Ag System and method for dynamic selection of stateless/stateful software components
US7412518 * Sep 7, 2000 Aug 12, 2008 Sun Microsystems, Inc. Method and apparatus for proximity discovery of services
US7516177 * Jun 28, 2004 Apr 7, 2009 Botalini Tera Ab, L.L.C. Apparatus for distributing content objects to a personalized access point of a user over a network-based environment and method
US7565359 * Jan 22, 2007 Jul 21, 2009 Yahoo! Inc. Dynamic page generator
US20010012299 * Dec 31, 1998 Aug 9, 2001 Robert L. Dahlen Method and apparatus for continuous narrowcast of individualized information over a data network
US20020010757 * Dec 1, 2000 Jan 24, 2002 Joel Granik Method and apparatus for replacement of on-line advertisements
US20020056004 * May 31, 2001 May 9, 2002 Smith Andrew J.R. Method and system for processing financial data objects carried on broadcast data streams and delivering information to subscribing clients
US20020078251 * Dec 18, 2000 Jun 20, 2002 Philips Electronics North America Corp. Self-determining command path architecture
US20020087630 * Oct 19, 2001 Jul 4, 2002 Jonathan Wu Enhanced information and presence service
US20020095399 * May 4, 2001 Jul 18, 2002 Devine Robert L.S. System and methods providing automatic distributed data retrieval, analysis and reporting services
US20030026254 * May 15, 2001 Feb 6, 2003 Sim Siew Yong Method and apparatus for large payload distribution in a network
US20040139433 * Dec 31, 2002 Jul 15, 2004 International Business Machines Corporation Programmatic response-time based workload distribution techniques
US20040148606 * Dec 19, 2003 Jul 29, 2004 Fujitsu Limited Multi-thread computer
US20040199926 * Apr 1, 2003 Oct 7, 2004 International Business Machines Corporation Enhanced staged event-driven architecture
US20050027815 * Jul 30, 2003 Feb 3, 2005 Hewlett-Packard Development Company, L.P. Establishment of network connections
US20050278726 * Aug 5, 2002 Dec 15, 2005 Cano Charles E Storing state in a dynamic content routing network
US20060031282 * Dec 14, 2001 Feb 9, 2006 Timothy Tuttle Techniques for updating live objects at clients using a dynamic routing network
US20060031283 * Mar 21, 2002 Feb 9, 2006 Timothy Tuttle Asynchronous messaging using a node specialization architecture in the dynamic routing network
US20060265488 * Feb 3, 2006 Nov 23, 2006 Timothy Tuttle Asynchronous messaging using a dynamic routing network
US20090077173 * Nov 18, 2008 Mar 19, 2009 Parallel Networks Llc Method and Apparatus for Dynamic Data Flow Control Using Prioritization of Data Requests
US8375051 * Jan 21, 2009 Feb 12, 2013 International Business Machines Corporation Apparatus for controlling subscriptions
US20080307035 * Jun 5, 2007 Dec 11, 2008 Erik John Burckart System and Method for Off-loading Online Meeting Updates Using Forward Proxy
US20090187570 * Jan 21, 2009 Jul 23, 2009 International Business Machines Corporation Apparatus for controlling subscriptions
Cooperative Classification H04L67/1008, H04L67/306, H04L67/1014, H04L67/1002, H04L67/26, H04L69/329, H04L67/1029, H04L67/02, H04L67/327, H04L45/30
European Classification H04L29/08A7, H04L29/08N1, H04L29/08N29U, H04L29/08N9A, H04L29/08N25, H04L29/08N9A1B, H04L29/08N9A1E, H04L29/08N9A7, H04L45/30, H04L29/08N31Y
Owner name: SHAW PARSING LLC, NEVADA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:RUMELHART, KARL E.;REEL/FRAME:019462/0873
Free format text: MERGER;ASSIGNOR:SHAW PARSING LLC;REEL/FRAME:037219/0324