US20070028000A1 - Content router processing - Google Patents

Content router processing Download PDF

Info

Publication number
US20070028000A1
US20070028000A1 US11/264,121 US26412105A US2007028000A1 US 20070028000 A1 US20070028000 A1 US 20070028000A1 US 26412105 A US26412105 A US 26412105A US 2007028000 A1 US2007028000 A1 US 2007028000A1
Authority
US
United States
Prior art keywords
content
command
node
incoming
logic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/264,121
Inventor
Bjorn Ebbesen
Szymon Smyka
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Yahoo Inc
Original Assignee
Yahoo Inc until 2017
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Yahoo Inc until 2017 filed Critical Yahoo Inc until 2017
Priority to US11/264,121 priority Critical patent/US20070028000A1/en
Assigned to YAHOO! INC. reassignment YAHOO! INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: EBBESEN, BJORN, SMYKA, SZYMON
Publication of US20070028000A1 publication Critical patent/US20070028000A1/en
Assigned to YAHOO HOLDINGS, INC. reassignment YAHOO HOLDINGS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: YAHOO! INC.
Assigned to OATH INC. reassignment OATH INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: YAHOO HOLDINGS, INC.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/56Routing software
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/302Route determination based on requested QoS
    • H04L45/306Route determination based on the nature of the carried application
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context

Definitions

  • the present invention relates generally to maintaining user devices and accounts, and more particularly to synchronizing information accessible from multiple devices and networked accounts.
  • Known routers and synchronization systems do not analyze the payload data received from one node to determine whether or not to forward all or part of the data to a second node. For example, a router uses an address it receives and a routing table to determine which destination nodes will receive a copy of the incoming packet. Known routers determine routing based on the address of packet. Additionally, known routers do not contain long term memory to hold packets. Thus, a packet will not be received by the second node unless the first node sends the packet to the router while the second node is also connected to the router.
  • a synchronization system holds a master copy of a set of records it is mirroring on one or more handheld devices. After a change occurs on one device and that device forwards a changed recorded to the synchronization system, the synchronization system updates its master copy, which is then available to other devices when they synchronize to the system.
  • Known synchronization systems must keep a master copy of all synchronized records. For example, a hand held organizer may operate with a synchronization tool on a PC. Both the organizer and PC maintain a master copy of all records. Thus, a master copy may be maintained at multiple locations. Additionally, if a synchronization system is to work with devices not simultaneously connected to the synchronization system, the synchronization system will need to keep a copy of each new record. If a record represents an audio file or an image file, the synchronization system may need a substantial amount of storage.
  • an improved system for synchronizing destinations of content would be advantageous and in particular a system allowing increased flexibility, reduced complexity and/or improved performance would also be advantageous.
  • a content routing system for routing changes to information between a plurality of content nodes and a command memory
  • the content routing system comprising: store and forward logic including: processing logic for: processing an incoming command from a first content node; selecting a set of destination content nodes based on a content type of the incoming command and one or more routing parameters; and generating an outgoing command for each of the selected destination content nodes; and command memory, coupled to the processing logic, for holding the incoming command and the set of outgoing commands; and a connected data set configuration, coupled to the processing logic, for holding the one or more routing parameters.
  • Some embodiments include a gateway for translating between the first protocol and a common protocol; and a protocol adapter for translating between the common protocol to the command protocol.
  • Some embodiments include a command memory having an incoming queue for holding the incoming command and an outgoing queue for holding the set of outgoing commands.
  • Some embodiments include a database for holding the incoming command and the set of outgoing commands, wherein each command has an attribute identifying a state of the command.
  • Some embodiments include an outgoing in-transit queue state.
  • Some embodiments include an incoming in-transit queue state.
  • a content routing system comprising: store and forward logic including logic for selecting destination content nodes based on a content type of an incoming command and one or more routing parameters; modifying the incoming command to generate at least one outgoing command, wherein each outgoing command corresponds to a selected content node; and a connected data set configuration for holding the one or more routing parameters.
  • the data modulation logic may further include at least one data module operable to modify a data field of the incoming command data structure.
  • the incoming command may include an XML-tree data structure schema, for example, and the data modulation logic may modify a particular node of the XML-tree data structure.
  • the data modulation logic may operate to divide a first incoming command associated with a first a content entry into multiple outgoing commands associated with second multiple content entries. Additionally, the data modulation logic may operate to merge multiple first incoming commands associated with first content entries into a relatively smaller number of second commands associated with second content entries.
  • the content routing system may further include data consolidation logic operable to identify potential duplicate content entries within a connected community of content nodes based on comparing a hash-value of the incoming command to a list of hash-values.
  • the hash-value is determined from less than all of the incoming command or content, e.g., a predefined significant property of the content entry.
  • a method of routing changes to information between a plurality of content nodes and a command memory including receiving an incoming command from a first content node; storing the incoming command in a command memory associated with the first content node; selecting a set of destination content nodes based on a content type of the incoming command and a routing parameter associated with the destination content node and the content type; and modulating the incoming command based on capabilities of the destination content node, wherein the modulating comprises targeting a specific field of the incoming command data structure with a data module operable to modify the data structure for generation of an outgoing command.
  • a computer program product comprising program code for use in a content routing system including processing logic and a command memory, the content routing system for routing changes to information between a plurality of content nodes and the command memory, the computer program product comprising program code for receiving an incoming command from a first content node; program code for selecting a set of destination content nodes based on a content type of the incoming command and a routing parameter associated with the destination content node and the content type; program code for modulating the incoming command based on capabilities of the destination content node, wherein the program code for modulating comprises data modulation logic operable to modify the data structure of the incoming command for generation of an outgoing command; and program code for generating the outgoing command.
  • FIGS. 1A and 1B show information distribution and synchronization systems.
  • FIG. 2 illustrates a content router coupled to multiple content nodes via a network according to embodiments of the present invention.
  • FIG. 3 shows a path of propagating a change in one content node to a selected set of content nodes via a content router according to embodiments of the present invention.
  • FIG. 4 shows a user's connected email accounts and includes an example screenshot according to embodiments of the present invention.
  • FIGS. 5 and 6 illustrate the connections to and processing performed by store and forward logic according to embodiments of the present invention.
  • FIGS. 7A and 7B illustrate store and forward logic coupled to a repository according to embodiments of the present invention.
  • FIGS. 8A and 8B illustrate a process of stripping a separable segment of an exemplary email then requesting the stripped segment from a source of the email according to embodiments of the present invention.
  • FIGS. 9A to 9 F illustrate various exemplary structures of store and forward logic and data paths between processing logic and content nodes according to embodiments of the present invention.
  • FIGS. 10A to 10 D show a PUT-GET-ACK procedure from a point of view a content node and a content router according to embodiments of the present invention.
  • FIG. 11 illustrates representation of a structure of a connected data set configuration according to embodiments of the present invention.
  • FIGS. 12A to 12 E illustrate external and internal logic, which may be used to interface a content router to user devices and user accounts according to embodiments of the present invention.
  • FIGS. 13 and 14 A to 14 I show structures of various commands according to embodiments of the present invention.
  • FIGS. 15A to 15 C illustrate sequence diagrams showing signaling between a user device and store and forward logic according to embodiments of the present invention.
  • FIGS. 16A to 16 D illustrate sequence diagrams showing signaling between a user account and store and forward logic according to embodiments of the present invention.
  • FIGS. 17A-17C illustrate exemplary instructions according to one aspect of the present invention.
  • FIGS. 18A-18E illustrate exemplary data structures according to several aspects of the present invention.
  • a procedure, computer executed step, logic block, process, etc. are here conceived to be a self-consistent sequence of steps or instructions leading to a desired result.
  • the steps are those utilizing physical manipulations of physical quantities. These quantities can take the form of electrical, magnetic, or radio signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. These signals may be referred to at times as bits, values, elements, symbols, characters, terms, numbers, or the like.
  • Each step may be performed by hardware, software, firmware, or combinations thereof.
  • FIG. 1A shows a routing system.
  • a router 100 includes a routing module 101 and a routing table 102 used to route packets 120 .
  • the router 100 uses both address information appended to the packet 120 and the routing table 102 to determine which data sinks 140 - 1 to 140 - 3 will receive a forwarded copy of an incoming packet 120 .
  • the router 100 forwards the packet 120 as packets 130 - 1 to 130 - 3 .
  • Known routers do not determine routing based on the type of content included in an incoming packet 120 , but rather based on the address information appended to the packet 120 .
  • FIG. 1B shows a synchronization system including a PC 150 and multiple data holders 160 .
  • a data holder 160 may be a hand held organizer connected to the PC 150 via a cradle.
  • a user may change information, such as entering a new contact, into a first data holder 160 - 1 .
  • Periodically, the user connects the data holder 160 to the PC 150 and synchronizes each data holder 160 using a CPU 151 of the PC 150 .
  • the first data holder 160 - 1 exchanges data 170 - 1 with the CPU 151 .
  • the CPU 151 saves any updated and new information as data 171 .
  • the PC 150 accumulates a persistent copy 152 of data 171 synchronized through it.
  • the CPU 151 updates the second data holder 160 - 2 with the information saved from the first data holder 160 - 1 . Even after both data holders 160 - 1 and 160 - 2 have been synchronized, the synchronization system preserves a copy of the changed information as persistent copy 152 even though the changed information is no longer needed for synchronization.
  • Known synchronization systems keep a complete persistent copy 152 of data synchronized through the synchronization system.
  • FIG. 2 illustrates a content router 200 coupled to multiple content nodes 300 - 1 to 300 - 3 via a network 10 according to embodiments of the present invention.
  • the content router 200 facilitates synchronization of similar and dissimilar content nodes 300 - 1 to 300 - 3 attachable to the network 10 .
  • the content router 200 may be a single network component implemented in hardware and/or software. Alternatively, the content router 200 may be a system of networked components.
  • the content router 200 uses commands 400 - 1 to 400 - 3 sent across the network 10 to communicate information.
  • the network 10 connects each content node 300 - 1 to 300 - 3 with the content router 200 using commands 400 .
  • the network 10 may be a conglomeration of disparate wired and/or wireless network such as interconnected intranets, the Internet and mobile radio networks. Alternatively, the network 10 may be a single network. Additionally, the content router 200 may bridge two or more separate networks.
  • a command 400 - 1 may be communicated within a message from a content node 300 - 1 .
  • the message may be encoded as a sequence of bits using a protocol available to the content node 300 - 1 .
  • a message may contain a segment of a command, in which case multiple messages may be aggregated to form a complete command. Alternatively, a message may contain multiple commands.
  • one or more messages may represent one or more commands.
  • the content router 200 may translate between the message protocol used by a content node 300 and a command structure or protocol used internally in the content router 200 .
  • a user may use commands to enter, store, access, update, modify, and/or delete content or metadata (i.e., information about content).
  • Content may have one of various content types, such as contacts, calendar events, tasks, emails and/or library items.
  • content may have a personal information management (PIM) content type, which may include a contact, calendar event or a task.
  • PIM personal information management
  • a library item includes a media object such as a photo image, an audio file, a video clip, a movie or a document, or may be a group of such items such as album of photos or collection of home movies. Metadata includes information about such content.
  • a content node 300 may be a user's account on a server. Such a content node 300 may have access to content of a single content type.
  • a user account may be a personal email account on an email server (e.g., Yahoo!® Mail), a family photo album account on a photo server (e.g., Yahoo!® Photos), a PIM account on a PIM server (e.g., Yahoo!® Address book or Yahoo!® Notepad), or a music library account on a multimedia library server (e.g., Yahoo!® Music).
  • a content node 300 may be a user account having access to two or more content types.
  • a user account may have access to email, PIM information, calendar information and a notepad, such as with a Yahoo!® user account.
  • a content node 300 may be a user device.
  • a user device may be a wired device, such as a home personal computer, an office PC, a digital camera or a set-top box, or may be a wireless device, such as a mobile phone, a laptop, handheld PC, or a digital camera with wireless capabilities.
  • Some devices may have both wired and wireless capabilities, while other devices may have either wired or wireless capabilities.
  • Some user devices may have access to a single content type. Other user devices have access to two or more content types.
  • a content node 300 may be a user device that organizes information, including PIM devices such as a Blackberry® or a Treo®, or more dedicated mobile phones that provide more limited information management services.
  • Information management services may include, for example, PIM services such as calendar, address book, tasks, and notes.
  • a calendar typically maintains time-related organizational attributes such as events (e.g., meetings, birthdays, holidays) related to corresponding date and time ranges.
  • An address book typically maintains organizational attributes related to a person (e.g., a legal “person” such as a human or business entity, or even a pet), a place (e.g., the person's address), or other contact information attributes (e.g., telephone numbers).
  • FIG. 3 shows a path of propagating a change in one content node 300 - 1 to a selected set of content nodes 300 via a content router 200 according to embodiments of the present invention.
  • a set of content nodes 300 may include a null set of content nodes, a single content node, a subset of one or more content nodes, or all content nodes.
  • a content node 300 may act as a source of data (data source), a sink of data (data sink), or a combination of both.
  • content node 300 - 1 acts as a data source while content nodes 300 - 2 , 300 - 3 , 300 - 6 and 300 - 8 act as data sinks.
  • a change to a content node 300 - 1 may represent one of a number of events including an addition, modification or deletion of content or metadata.
  • content node 300 - 1 acts as a source of content or metadata.
  • the content node 300 - 1 may generate a command 400 - 1 including changed content, or a metadata indication of the change to content, which may be communicated to the content router 200 .
  • the content node 300 - 1 may push the command 400 - 1 to the content router 200 or it may be polled by the content router 200 for the command 400 - 1 .
  • the content router 200 examines the contents of the command 400 - 1 . Based on the contents of an incoming command 400 - 1 , the content router 200 selects which of the possible content nodes 300 - 2 to 300 - 8 will be informed of the change. In this example, the content router 200 selects content nodes 300 - 2 , 300 - 3 , 300 - 6 and 300 - 8 , then transforms the incoming command 400 - 1 into outgoing commands 400 - 2 , 400 - 3 , 400 - 6 and 400 - 8 to distribute an indication of the change.
  • the outgoing commands 400 - 2 , 400 - 3 , 400 - 6 and 400 - 8 may or may not include the same contents as the incoming command 400 - 1 . Additionally, the content router 200 does not keep a persistent copy of all content synchronized through it.
  • a content node 300 - 1 may be a user device (such as a PIM device) or a user account (such as a Yahoo! account) that contains one or more databases of content and/or metadata.
  • the change may be a new, modified, or deleted contact.
  • the content node 300 - 1 includes a calendar, the change may be a new, modified, or deleted event, such as an appointment.
  • the content node 300 - 1 includes a task list, the change may be a new, modified, or deleted task.
  • the change may be a new, modified, or deleted note.
  • the change may also be an addition, modification or deletion of a collection of information, such as a list of watched stocks, a list of bookmarked web pages, or a configuration of a home page.
  • the change may be that the email account has received new content, such as an incoming email message from the Internet, or has deleted content, such as deleting an existing email.
  • the user may have updated metadata, such as changing a message state from unread to read, marking a message as unread, or setting an importance level.
  • the change may be that it received new content, such as a new pager message or a new SMS message from a wireless network, or that the user has deleted content, such as deleting a message.
  • the change may indicate that a user has added, modified or deleted a media object, such as a photo image, an audio file, a video clip, a movie or a document, or may be a group of such items such as an album of photos or collection of home movies.
  • a media object such as a photo image, an audio file, a video clip, a movie or a document
  • the change may indicate that a user has added a caption to a photo image, or has loaded a new song.
  • Media objects are further described in related U.S. application Ser. No. 11/129,697, filed on May 13, 2005 and titled MEDIA OBJECT ORGANIZATION ACROSS INFORMATION MANAGEMENT SERVICES by inventors Marco BOERRIES et al., and incorporated by reference herein.
  • a content node 300 - 1 may send the actual new or modified content.
  • a content node 300 - 1 may instead send metadata.
  • metadata may include characteristics of the changed content, a transformed copy of the changed content, and/or a reference, such as hyperlink or address pointer, to the content in memory.
  • Sending a reference instead of the actual content allows a receiving content node 300 - 2 to access content from a sending content node 300 - 1 without requiring the content itself to pass through the content router 200 .
  • a content router 200 may facilitate routing email among several email-capable content nodes 300 , such as a user device or a user account.
  • Email received at a user's first email account e.g., a personal email account
  • the user's second account e.g., a work email account on a second content node.
  • email received at the user's second email account may be forwarded through the content router 200 to the user's first email account.
  • the user may also add a third email account, e.g., a Yahoo!® email account, and configure the content router 200 to route email messages received from the Internet at the third account to the first and second accounts.
  • FIG. 4 shows a user's connected email accounts 320 - 1 to 320 - 3 , and includes an example screenshot 20 according to embodiments of the present invention.
  • Some content nodes 320 such as an Outlook account, allow a user to set up multiple email boxes or folders. Shown are two email accounts 320 - 1 and 320 - 2 with a connected inbox and one email account 320 - 3 without a connected inbox. Connected email accounts may report information to the content router 200 and may receive information from the content router 200 .
  • a content node ( 320 - 1 , 320 - 2 or 320 - 3 ) may report a new incoming email to the content router 200 in a command ( 31 , 32 or 33 , respectively).
  • the content router 200 selects a set of destination content node (e.g., 320 - 1 and 320 - 2 , respectively) and forms an outgoing command ( 34 and 35 ) destined for an inbox of each selected content node ( 320 - 1 and 320 - 2 , respectively).
  • the screenshot 20 from a user's personal email account 320 - 1 shows an inbox 21 for holding email messages received directly from the Internet without passing through the content router 200 , and a connected inbox 22 for holding email messages received from the content router 200 .
  • the connected inbox 22 contains emails merged from each of the user's connected email accounts 320 - 1 to 320 - 3 .
  • a connected inbox 22 may thus be viewed as a window to all emails sent to a user across the user's several connected email accounts.
  • a user may also configure an email account to include a separate folder or inbox for each content node 300 that has email capabilities.
  • the screenshot 20 shows an inbox 23 for emails from a personal email content node 320 - 1 , an inbox 24 for email from a work email content node 320 - 2 , and an inbox 25 for email from a Yahoo!g email content node 320 - 3 .
  • Using separate folders allows a user to manage individual email accounts from one content node, for example, user account 320 - 1 .
  • FIGS. 5 and 6 illustrate connections with and processing performed by store and forward logic 210 according to embodiments of the present invention.
  • the store and forward logic 210 allows multiple connected content nodes 300 to communicate changes to information on one content node 300 to other content nodes 300 through the content router 200 without requiring each content node 300 to be simultaneously coupled to the content router 200 .
  • the store and forward logic 210 may be decoupled from content node specifics. That is, the store and forward logic 210 may treat each content node similarly, regardless of whether a content node is a user device or a user account, or whether the content node operates as a client or as a server. Additionally, the store and forward logic 210 may move the task of conflict detection away from the content nodes and centralize the task of conflict detection and resolution to within the store and forward logic 210 .
  • the store and forward logic 210 may be implemented in hardware, executable code or a combination of both.
  • the store and forward logic 210 may include VLSI and/or FPGA hardware.
  • the store and forward logic 210 may include a stand alone server or a network of servers.
  • the store and forward logic 210 may be implemented with a general purpose central processing unit (CPU) or may be implemented with a reduced instruction set computer (RISC).
  • the store and forward logic 210 may include on-chip or off-chip memory such as RAM, PROM, EPROM, E 2 PROM and/or the like.
  • the store and forward logic 210 may also include magnetic memory, such as a hard disk drive, and may include optical memory.
  • the executable code may be derived from scripts, software, firmware and/or machine code.
  • the content router 200 of FIG. 5 includes store and forward logic 210 coupled to a connected data set configuration 500 , and a repository 600 .
  • the store and forward logic 210 may be coupled to associated content nodes 300 - 1 to 300 - 4 .
  • FIG. 6 shows a sequence of events triggered in the store and forward logic 210 by an incoming command beginning at 1000 . Those actions include processing an incoming command at 1001 , selecting outgoing content nodes at 1002 , generating outgoing commands at 1003 , processing outgoing commands at 1004 , and sending the processed outgoing commands at 1005 . Whether a command is an incoming or outgoing is viewed from the perspective of the store and forward logic 210 .
  • the sequence of events begins when a content node 300 - 1 , having a change to report, sends a new command 400 - 1 to the store and forward logic 210 .
  • a content node 300 - 1 does not send the change (such as a command to add an included new email message) to other content nodes. Rather, the content node 300 - 1 sends the change to the store and forward logic 210 , which may or may not create a set of outgoing command to send the new email message or parts of the new email message to a corresponding set of content nodes.
  • the store and forward logic 210 processes the incoming command 400 - 1 from the content node 300 - 1 .
  • Processing incoming commands 400 - 1 may include transforming commands based on limitations or specialized capabilities of the originating content node 300 - 1 .
  • the store and forward logic 210 may use the repository 600 , which may hold one or more separable segments of a command, and the connected data set configuration 500 , which contains transforming rules used when processing a command. Transforming incoming and outgoing commands is further described with reference to FIGS. 7A, 7B , 8 A and 8 B.
  • Processing an incoming command 400 - 1 may also include detection and resolution of a conflict between the incoming command 400 - 1 and a command pending in the store and forward logic 210 .
  • the store and forward logic 210 may hold multiple pending commands in memory waiting to be acted upon.
  • a pending command may be a previously received and processed incoming command from a particular content node 300 that is waiting for further processing by the store and forward logic 210 .
  • a pending command may be a command generated by the store and forward logic 210 in response to an incoming command. These generated commands are waiting to be transmitted to a particular content node 300 as an outgoing command (e.g., 400 - 2 or 400 - 4 ).
  • Conflict resolution may include discarding the new command 400 - 1 , deleting a pending command, and/or aggregating of the new command 400 - 1 with a pending command.
  • a conflict may arise if a new incoming command 400 - 1 conflicts with a previously received incoming command pending execution.
  • a previously received incoming command may be a command to add a new email received from the Internet by the content node 300 - 1 .
  • a subsequent incoming command may be to delete that same email, for example, if a user has deleted the email from its inbox on content node 300 - 1 .
  • the command to add the new email is still pending in the store and forward logic 210 when the subsequent command to delete the same email is received, a conflict exists. In this case, the conflict is resolved by discarding both commands.
  • the store and forward logic 210 detects the duplicate commands and resolves the conflict by discarding one of the duplicate commands.
  • a conflict may also arise if a new incoming command 400 - 1 conflicts with a command previously generated as an outgoing command for a particular content node 300 .
  • the store and forward logic 210 may hold a pending outgoing command to update a contact in an address book.
  • a new incoming command may be to delete that same contact altogether.
  • the store and forward logic 210 detects and resolves this conflict by removing the pending outgoing command (update-contact) and saving the new incoming command (delete-contact).
  • the new incoming command will eventually be processed and the delete-contact action will be propagated as an outgoing command to other connected content nodes 300 .
  • the store and forward logic 210 may also aggregate an incoming command 400 - 1 with a pending command for a content node 300 .
  • a previously received incoming command 400 - 1 may be to add a new task to a task list.
  • a subsequent incoming command 400 - 1 may be to modify this task in some way.
  • the store and forward logic 210 detects and resolves this conflict by incorporating the modifications from the subsequent incoming command (modify task) into the previous incoming command (add-task).
  • the resulting aggregated command may be an add of the modified task.
  • the resulting aggregated command may replace the previous incoming command.
  • the previous incoming command may be discarded and the resulting aggregated command may be saved as a new incoming command. Detection and resolution of conflicts are further described with reference to FIGS. 9A-9C and 10 A- 10 D.
  • the store and forward logic 210 selects a set of outgoing content nodes, here content nodes 300 - 2 and 300 - 4 .
  • the store and forward logic 210 may again use the connected data set configuration 500 , which also contains routing parameters used in routing rules. Routing rules and the connected data set configuration 500 are further described with reference to FIG. 11 .
  • the store and forward logic 210 generates an outgoing command 400 - 2 and 400 - 4 for each selected content node 300 - 2 and 300 - 4 , respectively.
  • the store and forward logic 210 may alter the processed incoming command to suit the limitations or requirements of the selected destination content node. For example, depending upon limitations of a destination content node, the store and forward logic 210 may use a repository 600 to hold a separable segment of an incoming command 400 - 1 and either modify or eliminate that segment from the outgoing command.
  • the content router 200 may insert additional segments of information into an outgoing command.
  • the content router 200 may alter a command based on user defined rules, system defined rules, or known content node limitations.
  • the content router 200 may modify a command based on information found within the incoming command 400 - 1 .
  • the content router 200 may append metadata, such as location, time or other information accessible from a user's account or device, to the outgoing command.
  • the content router 200 may hold a record of how a command is modified so that it may reverse the modification if a related command is returned. In some cases, the content router 200 passes a command through without modification.
  • the store and forward logic 210 processes the outgoing commands. As with incoming commands at 1001 , the store and forward logic 210 similarly performs conflict detection and resolution between a new outgoing command and pending incoming and outgoing commands.
  • the store and forward logic 210 sends the outgoing commands 400 to the respective content nodes 300 .
  • Sending an outgoing command 400 may include signalling a notification to the content node 300 .
  • a notification is a signal where a sender does not expect a response or an acknowledgement that the notification was received.
  • a notification is self contained in that it is complete once sent.
  • a notification may be implemented in software (e.g., a semaphore, flag or software signal instruction) and/or hardware (e.g., a hardware line or a register).
  • the notification may include a content type of the outgoing command 400 .
  • the store and forward logic 210 may send an HTTP command to notify the content node that an outgoing command is pending. If the content node is a mobile phone having SMS capabilities, the store and forward logic 210 may send a notification via an SMS message.
  • a content node 300 - 1 may send content having one or more segments in a command 400 - 1 .
  • the store and forward logic 210 may replace one or more segments of a command with a corresponding one or more references that provide a link back to the original content rather than forwarding the original segments themselves.
  • the content node 300 - 1 may include one or more references to a source of the content rather than including the content itself.
  • a content node 300 - 4 receiving the reference to content may instigate a peer-to-peer transfer 450 to retrieve the content from content node 300 - 1 .
  • the content router 200 may facilitate a transfer of content between two content nodes in the form of a peer-to-peer transfer 450 while both content nodes are simultaneously connected to the network 10 .
  • the store and forward logic 210 may adapt the command by modifying, replacing or eliminating a separable segment of the command before sending it to a content node. For example, some content nodes may be unable to process, use or store some segments of a command. In some embodiments, the store and forward logic 210 may accommodate these content nodes that have limited capabilities using one of three methods described below, some of which use a repository. The store and forward logic 210 may also uses these methods for other reasons, such as memory limitations in a content node or bandwidth restrictions between the store and forward logic 210 and the content node, even though the content node is capable of handling the entire incoming command.
  • the content router 200 is configured to poll a content node 300 for new commands.
  • a content router 200 may periodically poll a content node 300 to determine whether any changes have occurred. The period of polling may be based on the type or expected cost of a connection to the network. For example, if a content node 300 is a mobile phone connected to the network via an SMS connection, polling may take place every 24 hours. If the mobile phone connected to the network via a GPRS data network connection, polling may occur every 20 minutes. If the mobile phone is placed in a docking station with a wired connection to the Internet, polling may occur every few seconds to every few minutes.
  • notifications from the store and forward logic 210 to a content node 300 may be blocked because the content node 300 is behind a firewall.
  • the content node 300 may be configured to poll the content router 200 .
  • the store and forward logic 210 may reply with one command or a batch of commands for the content node 300 to process.
  • the structure of commands 400 is further described with reference to FIGS. 13 and 14 A- 14 I.
  • the notification and exchange of commands between the store and forward logic 210 is further described with reference to FIGS. 15A-15C and 16 A- 16 D.
  • the store and forward logic 210 may accommodate a limited capability content node by stripping incompatible or undesired segments from the payload and save the stripped segments in a repository 600 .
  • the repository 600 may hold segments of commands, which will be available for future use. If those segments are later needed, the store and forward logic 210 may access them from the repository 600 . This method is described below with reference to FIGS. 7A and 7B .
  • FIGS. 7A and 7B illustrate store and forward logic 210 coupled to a repository 600 according to embodiments of the present invention.
  • the store and forward logic 210 may adapt the command by eliminating a segment of the command before sending it to the content node 300 .
  • the store and forward logic 210 may preserve a copy of the unmodified segment or the entire command in the repository 600 .
  • the repository 600 may hold one or more segments of commands, which will be available for future use.
  • a segment may also be available to remove segments, such as a file in an email, from a command.
  • a file may be removed for an incoming command as described below with reference to FIG. 8A .
  • a file may be removed for an incoming command as described below with reference to a file relay server and FIG. 12E .
  • FIG. 7A shows store and forward logic 210 using a repository 600 to hold a separable segment of an incoming command 400 - 1 from a first content node 300 - 1 .
  • the separable content may be parsed away from the command or piecewise modified.
  • a contact may include a full name (first segment 401 ), a home phone number (second segment 402 ) and a work phone number (third segment 403 ).
  • Each of these segments may be separable and distinct. That is, one or more of these segments may be removed and/or modified and/or combined, thereby forming a modified command.
  • the store and forward logic 210 may remove the work phone number (third) from an incoming command when preparing the corresponding outgoing command.
  • the store and forward logic 210 may also place the work phone number in a repository 600 for future use.
  • an incoming command may include content such as a new email message having an email body and an attached file.
  • the attached file is separable and distinct from the email body.
  • the store and forward logic 210 may generate an outgoing command 400 - 2 to add the new email to a second content node 300 - 2 .
  • the outgoing command 400 - 2 to the second content node 300 - 2 may include the email body but only a reference to the file.
  • an incoming command 400 - 1 is forwarded in part as an abridged outgoing command 400 - 2 to a second content node 300 - 2 .
  • the incoming command 400 - 1 includes an exemplary payload 441 containing three segments of content and/or metadata 401 , 402 and 403 .
  • the store and forward logic 210 stores a copy of the third segment 403 in the repository 600 and also prepares an outgoing command 400 - 2 with a payload 451 containing the first segment 401 and the second segment 402 , but leaving off the third segment 403 .
  • the content router 200 may leave off the third segment 403 , for example, due to a limitation of the destination content node 300 - 2 .
  • Such a limitation may include the content node 300 - 2 having a limited amount of allocated storage capacity, or a general transforming rule that removes all attachments that are in a predetermined format.
  • a user may add a new contact to a content node 300 - 1 .
  • the content node 300 - 1 sends an add contact command 440 containing a payload 441 , which represents the contact created at the content node 300 - 1 .
  • the payload 441 may contain three segments 401 to 403 of information.
  • the first segment 401 may be a structure holding a first and last name.
  • the second segment 402 may be a phone number.
  • the third segment 403 may be a hyperlink to a webpage. If a destination content node 300 - 2 is incapable of receiving a hyperlink, then the store and forward logic 210 may strip off the third segment 403 containing the hyperlink.
  • the payload 451 sent from the store and forward logic 210 may be different from the payload 441 received by the store and forward logic 210 .
  • the store and forward logic 210 stores the third segment 403 in the repository 600 for possible future use.
  • the store and forward logic 210 may access the repository 600 after a user changes a segment of the payload 451 and before the store and forward logic 210 forwards the change to the first content node 300 - 1 , as discussed below.
  • FIG. 7B shows store and forward logic 210 accessing segments from the repository 600 in response to an incoming command 400 - 2 A, which contains the original first segment 401 and the updated second segment 402 A, from the second content node 300 - 2 .
  • the second segment 402 may have been updated as the result of a user modifying the segment, such as an email attachment, at content node 300 - 2 .
  • the store and forward logic 210 processes the incoming command 400 - 2 A from content node 300 - 2 , it determines whether any segments previously associated with payload 451 and now associated with payload 451 A are held in the repository 600 .
  • the store and forward logic 210 determines that the third segment 403 was previously associated with payload 451 , and merges the third segment 403 from the repository 600 with the payload 451 A containing the original first segment 401 and an updated second segment 402 A to create a full data structure. If content node 300 - 1 is configured to process the content held in each segment 401 to 403 , the store and forward logic 210 prepares a payload 441 A containing the first segment 401 , the updated second segment 402 A, and the reattached third segment 403 .
  • the store and forward logic 210 may accommodate a limited capability content node 300 - 2 by modifying an incompatible or undesired segment from the payload 441 .
  • the store and forward logic 210 may save this segment in the repository 600 if it may be needed in the future.
  • This second method is similar to the first method except that, in the second method, the segment stripped in the first method is instead modified and sent to the content node. If in the future, the limited capability content node returns the modified segment in a command, the store and forward logic 210 may replace this returned segment with the original segment from the repository 600 before the store and forward logic 210 forwards the command to other content nodes.
  • the store and forward logic 210 may replace the two string structure with a single string structure containing a concatenated first and last name in the single string structure.
  • the store and forward logic 210 may store the structure including the first name string and the second name string in the repository 600 .
  • the store and forward logic 210 may replace the concatenated string in the incoming command from the second content node 300 - 2 with the copy of the two string structure from the repository 600 . In this way, missing content from one limited-ability content node 300 - 2 may be restored before it is forwarded to other content nodes.
  • store and forward logic 210 may retrieve the original segment from its source content node or from storage referenced by the source content node.
  • the content router 200 includes a data modulation component operable to manipulate or modify content and/or metadata of a payload, e.g., segments 401 , 402 , 403 as shown and described with respect to FIGS. 7A and 7B .
  • the data modulation component may include logic within store and forward logic 210 of the content router 200 (see, e.g., FIG. 5 ).
  • the data modulation component may comprise data modulation logic including one or more data modules operable to target data within a data structure of the payload (e.g., which may be structured as an eXtensible Markup Language (XML)-tree data structure schema) and perform actions on portions of the data (e.g., modifying/deleting one or more segments 401 , 402 , 403 ) to carry out various functions described herein.
  • a data structure of the payload e.g., which may be structured as an eXtensible Markup Language (XML)-tree data structure schema
  • XML eXtensible Markup Language
  • multiple data modules for targeting and acting on data within the data structure of the payloads are configured to carry out various modulations for routing to one or more content nodes, e.g., 300 - 1 , 300 - 2 , and so on.
  • payloads associated with incoming and outgoing commands are structured as XML data structures.
  • XML data structures are well known in the art and generally comprise data tree structures, wherein a sub-tree and/or single data value may be targeted for action.
  • Various data modules may be implemented to act on specific data values or fields of the data as it is routed through the system, e.g., through the content router 200 .
  • the processing logic 250 may include one or more data modules operable alone or in combination to modify certain content or metadata for specific content nodes or devices.
  • An illustrative example includes a data module operable to modify content/metadata for a PIM device or other device having different or reduced capabilities relative to other content nodes ( 300 - 1 , 300 - 2 , etc.), such as a user account.
  • One or more data modulation components may be used by the content router 200 to adapt and route content to various content nodes having disparate capabilities.
  • the data modulation component may include one or more data modules, each having a path and target within the XML-tree structure of the payload (i.e., including content and/or metadata). Multiple data modules may be combined to carry out various actions on one or more segments of the payload as they are routed to different content nodes.
  • a contact entry may include an address including separate data values for street address, city, and country.
  • a first module may be operable to remove or delete the country information from the contact entry and a second module may be operable to modify the street address to a maximum of 20 characters.
  • the modulation may be performed to “fit” the content and metadata to a particular content node, e.g., a mobile device or the like.
  • a data change (e.g., a command) sent from content router 200 to a content node (e.g., a device) is modified by the processing logic 250 to fit the receiving content node; as such, the data is manipulated as needed for the particular content node or device.
  • data sent from the device to the server fulfils payload-requirements because the data is redistributed to other content nodes/devices (i.e., the content entry is returned to its original state) by the content router as described herein. Accordingly, data may be modified when sending or receiving data from content nodes/devices without losing any portion of the payload content.
  • the payload data (e.g., segments 401 , 402 , 403 ) is structured and represented in an XML-schema (which is generally an XML-tree data structure). Before and after manipulating the XML-tree structure, the payload is represented based on the same payload schema.
  • Each node (tag/attribute) in the XML-tree structure is handled by an instruction (referred to as a “NodeInstruction”). Further, an instruction for a node may delegate handling of child nodes to child instructions.
  • NodeInstructions process the payload as an XML-tree structure using JAVA®-classes, where each NodeInstruction is represented by one instance of a JAVA®-class.
  • the data modulation logic targets the tailoring of content (removing portions of the content) not only in the payload to be sent to the device, but also in a shadow-payload, which is stored with the server, e.g., the repository 600 of content router 200 .
  • This Shadow-payload together with the incoming payload, may be used to join and restore the payload before any further content router processing is applied.
  • the shadow-payload itself is organized in the same node-structure as the original payload to ensure that each NodeInstruction gets/puts the information needed.
  • the shadow-payload is organized into two XML-trees-one to store/read device-side-information and one to store/read content router-side-information during tailoring/joining processes.
  • a content router (such as content router 200 ) may include various default data modules for the handling of payloads, where new data modules or modifications to existing data modules may be generated as new content nodes are added or removed from the system.
  • the exemplary framework for adding modules in an XML schema is particularly flexible and adaptable to various content nodes/devices that might be associated with the content router and community of connected content nodes. Additionally, data modulation within an XML schema may quickly adapt to new content nodes and content requirements.
  • NodeInstructions generally include SingleNodeInstructions and MultiNodeInstructions.
  • SingleNodeInstructions handle a single node of the XML-tree structure and its value only, whereas MultiNodeInstructions handle a subset of a node's child nodes as a unit.
  • MultiNodeInstructions may be implemented in a variety of different implementations to modulate node values.
  • MultiNodeInstructions may be generally divided into 3 subtypes: i) GenericMultiNodeInstruction, which is the root instruction and allows generically adopting specialized instructions for each child node, ii) UniformMultiNodeInstruction, which handles unique named child nodes, and iii) MultiNodeInstruction, which handles two or more targeted child nodes with specialized processes.
  • the data modulation starts with a GenericMultiNodeInstruction.
  • GenericMultiNodeInstructions are illustrated in FIG. 17A .
  • SingleNodeInstructions which may be used for manipulating values of a single node without sub nodes
  • FIG. 17B examples of SingleNodeInstructions, which may be used for manipulating values of a single node without sub nodes
  • FIG. 17C examples of UniformMultiNodeInstructions, which may be used for manipulating a single node (without value) containing many uniform (named) child nodes.
  • FIGS. 18 A-E Various aspects of exemplary Data Modulation structures (continuing with the example of the XML schema) are illustrated generally in FIGS. 18 A-E.
  • an exemplary Root tag is illustrated in FIG. 18A ; exemplary list nodes to be handled by specialized instructions is illustrated in FIG. 18B ; and an exemplary handling of a single node by cutting the string is illustrated in FIG. 18C .
  • an exemplary handling of a multi node with m:n mapping is illustrated in FIG. 18D ; and an exemplary handling of a multi node with 1:1 identification is illustrated in FIG. 18E .
  • FIGS. 18 A-E Various aspects of exemplary Data Modulation structures (continuing with the example of the XML schema) are illustrated generally in FIGS. 18 A-E.
  • an exemplary Root tag is illustrated in FIG. 18A ; exemplary list nodes to be handled by specialized instructions is illustrated in FIG. 18B ; and an exemplary handling of a single node by cutting the string is illustrated in FIG.
  • the content router includes a data modulation component operable to divide or split (and therefore referred to as a “splitter” component) certain content in a bidirectional manner.
  • the splitter component may be part of or a feature of the data modulation features described and include logic operable to carry out the functions described herein. Further, the logic operable to carry out the splitter component functions may be stored in the store and forward logic 210 and processing logic 250 of content router 200 (see, e.g., FIG. 5 ).
  • some content nodes may not be capable of or desirable for handling the content change itself, but can handle “n” separate data changes (generally of a more simple nature) derived from the original single data change.
  • a recurrence rule in an events application stored as a single record on a first content node may be “split” into “n” number of single events on a second content node; a contact entry having multiple phone numbers on a first content node may be split into “n” number of contacts with one phone number each on a second content node; and the like.
  • the splitter component manages data changes from and to weaker devices without a loss of information by processing a single data change as multiple data changes according to content node capabilities.
  • the splitter component splits or divides a change to a data record to a relatively weak content node (e.g., a remote device), referred to as the “Splitting” direction.
  • the splitter component determines the content node capabilities or preferences and splits, if necessary, one data change (from a content node via the content router) to “n” data changes to effectuate the data change.
  • An illustrative example includes a change to a recurring event, such as the time of a weekly meeting. Some content nodes may be able to store the event as a single record with a recurring attribute. Some content nodes, however, may not have the capability for recurring events and must store individual records for each event. Thus, a change to the recurring event at a first content node is split or divided into two or more data changes to effect the change to multiple event entries with the less capable, weaker content node.
  • a recurrence event may be stored on a first content node, such as a PIM application server, as: Title Meeting with Sue Time 10-11 am Start Date Friday 10 Jun. 2005 Recurrence Type Monthly End Date Saturday, 31 Dec. 2005
  • the recurrence event may be stored (and routed) on a second content node, which may be a less capable, weaker device, as two or more single event entries, the first entry as follows: Title Meeting with Sue Date 10 Sep. 2005 Time 10-11 am
  • the second entry may be stored with the content node as follows: Title Meeting with Sue Date 10 Oct. 2005 Time 10-11 am
  • the single events in the device match those in the PIM application backend because the Title and Time are the same and they match the recurrence details specified in the PIM application program (i.e., they occur on the 10 th of each month).
  • a change to the recurrence event on the first content node or a change to the single event entries on the second content node may be routed by the content router to change the corresponding entries and preserve the recurrence aspect of the events.
  • the single event entries and recurrence event entry may be split or merged depending on the direction and content capabilities, thereby improving the ability to synchronize all connected content nodes in the community despite disparate capabilities of the various content nodes.
  • Another illustrative example includes a contact having multiple phone numbers.
  • “Joe Smith” may include three phone numbers associated therewith.
  • a particular content node or device may be capable of storing only one phone number per contact.
  • the splitter component may operate to divide the contact entry of “Joe Smith” into two or more separate data entries for storage with the device, in this example, into three entries for “Joe Smith” having one phone number for each.
  • the splitter component is also operable to perform “Integration” of the record in a direction from the device to the server or other content nodes, referred to as the “Integration” direction.
  • an incoming device data change related to a former data change will result in a corresponding (server) data change.
  • server data change. For example: a phone number may be reintegrated into a full content entry; move of a single event results in reintegrated into full recurrence as an exceptional event; and the like.
  • data is aggregated to a lesser count of data with the server.
  • “n” data records are aggregated to one data record when possible.
  • the content router further stores (e.g., in repository 600 or other memory associated therewith) this information from “Aggregation” processes for subsequent “Splitting” and “Integration” processes.
  • segments are not saved to a repository.
  • the store and forward logic 210 may accommodate a limited capability content node by stripping or modifying an incompatible or undesired segment from the command payload. However, with this method, a copy of the stripped or modified segment is not preserved in a repository. If those segments are needed later, the store and forward logic 210 may request and receive the segment from the source of the original incoming command.
  • FIG. 8A illustrates a process of stripping a segment of an exemplary email according to embodiments of the present invention.
  • An incoming email 900 arrives at a first content node 300 - 1 from the Internet over an SMTP connection.
  • the email 900 includes a payload 901 , which contains an incoming email header and body 401 containing information such as date and time and to, from and reply email addresses as well as the text entered by the sender.
  • the payload 901 also includes an image file attachment 402 , such as a JPEG file, and a presentation file attachment 403 such as a PowerPoint presentation.
  • An application running on the content node 300 - 1 may convert the attachments 402 and 403 to links 402 A and 403 A, which allow a capable content node to access the attachments through the hyperlinks to the attachments.
  • the content node 300 - 1 may then create one or more messages 910 , according to an email protocol such as IMAP, forming a payload 911 including the incoming email header and body 401 , the link to the image file 402 A, and the link to the presentation file attachment 403 A.
  • the content node 300 - 1 sends the messages 910 to protocol interface logic 260 within the content router 200 .
  • the protocol interface logic 260 converts the one or more messages 910 into a command 420 containing a payload 421 including the incoming email header and body 401 , the link to the image file 402 A, and the link to the presentation file attachment 403 A extracted from payload 911 .
  • the protocol interface logic 260 allows for content nodes that use different protocols to function with the content router 200 .
  • the store and forward logic 210 receives the incoming command 420 from the protocol interface logic 260 and prepares an outgoing command 430 for content node 300 - 2 . In this example, the content node 300 - 2 is unable to a process presentation file attachment 403 or its link 402 A.
  • the store and forward logic 210 is configured to strip off any links to a presentation file attachment 403 A.
  • the store and forward logic 210 prepares the outgoing command 430 including a payload 431 containing the incoming email header and body 401 and the link to the image file 402 A, but not the link to the presentation file attachment 403 A. In this case, the store and forward logic 210 does not preserve a copy of the link 403 A in a repository 600 for later use.
  • a user at content node 300 - 2 may forward the email to an external Internet address.
  • protocol interface logic 260 may determine that the email is missing one or more segments contained in the original email. The protocol interface logic 260 may request the missing segments from an inbox at content node 300 - 1 containing the complete email. After receiving the original segments, the protocol interface logic 260 may restore the segments to the forwarded email. Next, the protocol interface logic 260 may use an email server associated with inbox at content node 300 - 1 to forward the email to the external Internet address.
  • FIG. 8B illustrates a process of restoring a stripped segment to an email if a user later forwards the email according to embodiments of the present invention.
  • a user may forward an email previously received at content node 300 - 2 .
  • the content node 300 - 2 sends a command 440 containing a payload 441 including a newly created outgoing email header and body 401 B, the original incoming email header and body 401 , and the link to the image file 402 A.
  • This incoming command 440 includes neither the presentation file attachment 403 nor its link 403 A.
  • the store and forward logic 210 generates an outgoing command 450 including a payload 451 containing the segments from payload 441 .
  • the protocol interface logic 260 receives command 450 and detects that it is a forwarded email.
  • the protocol interface logic 260 may attempt to restore the stripped segments by requesting the unabridged email from the first content node 300 - 1 .
  • the protocol interface logic 260 may request just the stripped segments 402 and 403 .
  • the first content node 300 - 1 sends the protocol interface logic 260 the stripped segments, for example, in one or more IMAP messages 960 , forming a payload 961 that includes the image file attachment 402 and the presentation file attachment 403 .
  • the protocol interface logic 260 prepares an email containing a payload 971 including the outgoing email header and body 401 B, the incoming email header and body 401 , the original image file attachment 402 , and the original presentation file attachment 403 .
  • the protocol interface logic 260 may forward the email to an email server 300 - 1 A associated with content node 300 - 1 , for example, in an SMTP message 970 including payload 971 .
  • the email server 300 - 1 A responds to the SMTP message 970 with an outgoing email 980 to the external Internet address.
  • the outgoing email 980 contains each of restored segments of the incoming email that were previously stripped off or modified by the protocol interface logic 260 .
  • the outgoing email 980 also contains the outgoing email header and body 401 B created at content node 300 - 2 . As a result, the outgoing email may appear that it was forwarded from an email containing the original attachments 402 and 403 even though the content node 300 - 2 from where the user forwarded the email had limited capabilities and received neither attachment.
  • a repository 600 may also be used for keeping an inventory of information routed among connected content nodes. Alternatively, the inventory may be kept in separate memory.
  • the inventory may include characteristics of content and/or characteristics of metadata of one or more content types routed to and from the content router.
  • the inventory may be used for summarizing characteristics of routed content residing on one or more of the connected content nodes 300 .
  • the inventory may be used to preview an item count. For example, if one or more routing parameters are changed for a particular content node 300 , the content router 200 may estimate or determine the number of additional items of a particular content type would need to be fetched from one or more other content nodes 300 to place the particular content node 300 in line with the updated routing parameters.
  • the characteristics may be used to compute a summary number of a content type residing on a content node falling within a condition based on the characteristics in the inventory.
  • the entries in the inventory may be counted to summarize a number of a particular content type reside on a content node.
  • the inventory may be used during conflict checking to identify duplicate commands.
  • the content router may collect information in an inventory from each email message routed through the content router 200 and residing on a content node. For example, for each command to add a new email message, the content router 200 may save characteristics of the email such as the existence of the email and a date the email was received by the content node. The entries in the inventory may be counted to summarize a number of email messages residing on a content node.
  • the date of each email may be used to summarize a number of email messages residing on a content node falling within a specified date range based on a date characteristic in the inventory for a plurality of email messages routed through the content router, If a user wishes to see a number of email messages that a content node would contain if the user changed a routing parameter, such as the number of days an email should reside on a content node, the content router 200 may compute the number of emails in an inventory that fall within a particular date range.
  • the inventory may also be used by a scheduler on the content router 200 to remove email messages from a content node 300 previously routed through the content router 200 to the content node 300 .
  • a scheduler on the content router 200 may periodically compare dates in the inventory of email messages previously routed through the content router 200 . For example, the schedule may compare these dates to a routing parameter indicating a number of days a user as elected to maintain routed emails on the content node.
  • the routing parameter may be to keep emails from the last three days on a user device, such as a mobile phone. New email messages may be forwarded to the user device as they arrive to the content router 200 and an inventory kept of each new email.
  • the content nodes sends email deletion commands to the content router and the inventory may be updated accordingly.
  • the scheduler may periodically (e.g., nightly) compare the dates of emails in the inventory to the routing parameter indicating that emails should only be kept on the user device for the certain number of days. If the inventory indicates that the user device contains email older that the routing parameter permits, the scheduler on the content router may generate a command to delete each email on the user device that is older than allowed by the routing parameter.
  • the routing parameter may indicate keeping a two day history of emails on the user device. Each night the scheduler may store a command to delete emails from the user device that are older than two days.
  • the inventory may be used to indicate to a user a number of emails that would need to be removed from or added to a content node if a routing parameter where changed. For example, if a routing parameter for a content node currently indicated keeping two days of emails were changed to keeping one day of email, the content router 200 may determine from the inventory data associated with the content node that a particular number of email messages would need to be deleted from the content node. Similarly, if the routing parameter were changed from two days to three days for a particular content node 300 , the content node 200 may determine, from inventory data related to the particular content node 300 and to another related content node, the number of email messages that would need to be routed from the related content node to the particular content node.
  • the inventory may be used by the content router to limit a number of one or more content types on a content node.
  • the content router may send delete commands corresponding to each add command of a content type wherein the content node already holds a predetermined number of content of a type.
  • a scheduler may be used to periodically determine if a content node has a number of content items in excess of predetermined threshold number for each content type.
  • the predetermined threshold number may be configured by the user or alternatively may be a default value for the content node type. For example, if a content node, such as a mobile phone, may have 500 or more email messages. A content node, such has a user account may have a larger predetermined threshold number, such has 5000.
  • the content router may send a corresponding delete command to remove the oldest email message from the content node.
  • a scheduler may periodically determine if a content node has more that a predetermined number of items of a particular content type and then send one or more delete commands to remove outdated content.
  • a predetermined number may be 500, which may indicate that a particular user device may have up to 500 emails. If the content router determines that the user device has more than 500 emails, it may send a number of delete commands to remove email messages in excess of 500. In some embodiments, the content router sends delete commands to remove the oldest emails messages in excess of the predetermined threshold number.
  • the inventory may be used to request the most recent 500 emails from other content nodes for forwarding to the provisioned content node. As new emails arrive, they may be added to the content node until a predetermined limit, such as 5000, is reached. Once the limit is reached, the content router may issue delete commands to remove the oldest email messages from the content node.
  • a predetermined limit such as 5000
  • the content node may have a predetermined threshold number for a maximum number of events on a content node. For each new event added to the content node, the content router may send a delete command to remove the oldest event if the predetermined threshold number would otherwise be exceeded. Alternatively, the content router may periodically review the inventory to determine a number of event-content types exist on a content node. It may then send one or more delete commands to delete the oldest events from the content node.
  • the content node may have a predetermined threshold number for a maximum number of tasks on a content node. For each new task added to the content node, the content router may send a delete command to remove the oldest task if the predetermined threshold number would otherwise be exceeded. Alternatively, the content router may periodically review the inventory to determine a number of task-content types exist on a content node. The content router may then send one or more delete commands to delete the oldest tasks from the content node. Alternatively, the content router may then send one or more delete commands to delete completed tasks until the predetermined threshold number is not exceeded.
  • the content router 200 may calculate and save a checksum of the new email.
  • the checksum may be used when determining if a command to add a new email duplicates a command in the command memory or a command previously passed through the content router.
  • FIGS. 9A to 9 C show a structure of a store and forward logic 210 and data path between processing logic 250 and content nodes 300 - 1 to 300 - n according to embodiments of the present invention.
  • FIG. 9A shows store and forward logic 210 having a command memory 220 and processing logic 250 .
  • the processing logic 250 is coupled to a connected data set configuration 500 and to the command memory 220 .
  • the command memory 220 is also shown coupled to content nodes 300 - 1 to 300 - n.
  • the command memory 220 may be configured to include both incoming memory 230 and outgoing memory 240 for each content node 300 .
  • a content node 300 may push (put) one or more commands to the incoming memory 230 .
  • a content node 300 may also pull (get) one or more commands from the outgoing memory 240 .
  • command memory 220 may be configured in a database containing commands.
  • Each command in the database may be associated with attributes.
  • an attribute associated with a command in the database may identify the command as an incoming command or an outgoing command for a particular content node 300 .
  • FIG. 9B shows a structure of the command memory in the store and forward logic 210 for a single content node 300 according to embodiments of the present invention.
  • the command memory 220 includes incoming memory 230 and outgoing memory 240 .
  • the incoming memory 230 includes an incoming queue 231 and a corresponding in-transit queue 232 .
  • the incoming queue 231 holds incoming commands received by the store and forward logic 210 from a content node 300 but have not been responded to by the processing logic 250 .
  • the corresponding incoming in-transit queue 232 holds incoming commands that the processing logic 250 is in the process of responding to.
  • processing logic 250 may discard the incoming command from the in-transit queue 232 . If the processing logic 250 was unsuccessful at processing an incoming command, for example, if a necessary resource is unavailable, the processing logic 250 may move the incoming command from the in-transit queue 232 back to the incoming queue 231 .
  • the outgoing memory 240 includes an outgoing queue 241 and a corresponding in-transit queue 242 .
  • the outgoing queue 241 holds outgoing commands generated by the processing logic 250 (in response to an incoming command) but the processing logic 250 has not initiated sending of the outgoing command to the content node 300 .
  • the corresponding outgoing in-transit queue 242 holds outgoing commands that the processing logic 250 has initiated sending to the content node 300 but a confirmation or assurance that the content node 300 has received the outgoing command has not been received by the processing logic 250 .
  • a database may be used to hold commands and that one or more attributes associated with each command may indicate that the command is in the incoming queue 231 , the corresponding incoming in-transit queue 232 , the outgoing queue 241 , or the corresponding outgoing in-transit queue 242 .
  • FIG. 9C shows incoming memory 230 - 1 used for holding an incoming command from a source content node 300 - 1 and outgoing memory 240 - 2 used for holding an outgoing command to a destination content node 300 - 2 .
  • the source content node 300 - 1 may send (put) a command or set of commands to the content router 200 .
  • the processing logic 250 may place the incoming command or set of commands the incoming queue 231 - 1 associated with the source content node 300 - 1 .
  • the processing logic 250 may respond to an incoming command held in the incoming queue 231 - 1 . As part of responding to an incoming command in the incoming queue 231 - 1 , the processing logic 250 may move the incoming command from the incoming queue 231 - 1 to the in-transit queue 232 - 1 of the incoming memory 230 - 1 . Additionally, the processing logic 250 may select a destination content node 300 - 2 for which it may generate an outgoing command. In general, the processing logic 250 may select a set of destination content nodes to include multiple destination content nodes, a single destination content node, or no destination content nodes. Next, the processing logic 250 may place the generated outgoing command in the outgoing queue 241 - 2 of a destination content node.
  • the processing logic 250 may remove the incoming command from the in-transit queue 232 - 1 in the incoming memory 230 - 1 . If the processing logic 250 is unsuccessful at either preparing or writing the outgoing command, the processing logic 250 may move the incoming command from the in-transit queue 232 - 1 back to the incoming queue 231 - 1 . In this manner, an incoming command is either successfully responded to or it is placed back into the incoming queue 231 - 1 for a future attempt at processing the incoming command.
  • the processing logic 250 may send a notification to the content node 300 - 2 to inform the content node 300 that an outgoing command is pending in the outgoing queue 241 - 1 .
  • the destination content node 300 - 2 may request (pull) the outgoing command from the outgoing queue 241 - 2 .
  • the content router 200 may push the outgoing command to the destination content node 300 - 2 .
  • the processing logic 250 may move the outgoing command from the outgoing queue 241 - 2 to the in-transit queue 242 - 2 associated with the destination content node 300 - 2 .
  • a success at sending and/or receiving may be internally determined by the processing logic 250 , determined by receipt of an instruction to remove the outgoing command, or determined by receipt of an acknowledgement (ACK) or an equivalent notification providing sufficient assurance that the outgoing command has been received by the destination content node 300 - 2 .
  • Communicating an acknowledgement may be initiated by the destination content node 300 - 2 or by an intermediary acting as a proxy for the destination content node 300 - 2 as described below with reference to FIGS. 15B, 15C , 16 B and 16 C.
  • the outgoing command residing in the in-transit queue 242 - 2 may be moved back to the outgoing queue 241 - 2 .
  • the processing logic 250 may have a future opportunity to resend the outgoing command from the outgoing queue 241 - 2 to the destination content node 300 - 2 . If the processing logic 250 determines that the failure is permanent, it may discard the command thereby avoiding a potential endless loop of transferring a command in and out of an in-transit queue 232 , 242 .
  • the act of moving commands between an incoming or outgoing queue 231 , 241 and a corresponding in-transit queue 232 , 242 helps assure that a command is only discarded after it has been properly responded to or sent. Additionally, the process of moving a command between the incoming or outgoing queue 231 , 241 and the in-transit queue 232 , 242 may occur with an actual move of data from one allocated buffer to another. Alternatively, the process of moving between queues may occur virtually by changing a state of a flag or an attribute in a database. Additionally, each time a command enters either the incoming queue 231 or the outgoing queue 241 , for example from an in-transit queue 232 or 242 after an error condition has occurred, the processing logic 250 may perform a conflict check as described below.
  • the incoming data change commands might be stored in command memory 220 twice, e.g., in incoming memory 230 - 1 and outgoing memory 240 - 2 .
  • the content router 200 processes (for each targeted content node 200 - 2 , 3 , . . . ) data change commands from “incoming” command memory 230 - 1 , depending on the content node putting the command, toward the “outgoing” command memory 240 - 2 , depending on the content node getting the command.
  • the data change command may be stored two times the number of target or connected content nodes.
  • the use of command memory 220 for storing commands may be reduced.
  • FIG. 9D One such embodiment of an exemplary content router 200 with reduced storage is illustrated in FIG. 9D .
  • incoming data change commands are processed toward other connected content nodes, such as content node 300 - 2 , without storing the incoming data change commands in incoming memory 230 - 1 of command memory 220 as described above with respect to FIG. 9C .
  • content node 300 - 1 forwards a data change command to store and forward logic 210 of content router 200 , where store and forward logic 210 attempts to immediately process and route the command to content node 300 - 2 (i.e., without first storing the command in incoming memory 230 - 1 ).
  • the change command is put from content node 300 - 1 directly to processing logic 250 of store and forward logic 210 , where processing logic 250 processes and routes the command to the outgoing memory 240 - 2 (e.g., to outgoing queue 241 - 2 and in-transit queue 242 - 2 as describe above).
  • the incoming storage e.g., incoming memory 230 - 1 ; indicated in outline in FIG. 9D
  • only outgoing storage e.g., outgoing memory 240 - 2 ) used.
  • incoming memory 230 - 1 may be used to store the command as discussed with regard to FIG. 9C , for example.
  • FIG. 9D may be used alone or in combination with other methods/systems, such as that of FIG. 9C .
  • the exemplary content router 200 of FIG. 9D may reduce storage requirements associated with the store and forward logic 210 .
  • command memory 220 instead of command memory 220 storing commands twice for each associated content node (i.e., storage within incoming memory 230 - 1 and outgoing memory 240 - 2 ; before and after processing by processing logic 250 ), command memory 220 stores a single command for each associated content node. For example, only the outgoing memory 240 - 2 is used for each targeted content node.
  • the reduction or elimination of incoming storage to facilitate processing may reduce costs and increase the speed of content router 200 (as evident by the reduced processing and storage requirements).
  • the two storages are replaced by a single storage 222 for all content nodes.
  • incoming data change commands are processed by processing logic 250 in the context of the device “put”-request immediately to a central storage, or command memory 222 of content router 200 , where the command memory 222 is content node independent (e.g., command memory 222 is not adapted for or associated with a particular content node).
  • Outgoing data change commands are then processed by processing logic 250 in the context of a content node/device “get”-request from the command memory 222 when routing to the content nodes 300 - 2 , 300 - 3 , and 300 - 4 .
  • content node 300 - 1 when content node 300 - 1 puts data, it is pre-processed by processing logic 250 prior to storage in command memory 222 .
  • various data modulation, splitter/aggregation processes, or the like may be carried out on the data command prior to getting to command memory 222 such that a normalized data change command is held therein and accessible by content router 200 .
  • the normalized command stored with command memory 222 will represent the full scope of the change available from the first content node 300 - 1 .
  • data modulation will occur (e.g., the data change command will be modulated by processing logic 250 according to the particular content node as the data change command flows to the particular content node).
  • aspects of this example may reduce storage requirements of content router 200 because the storage of data change commands may be reduced to a single entry accessible by all associated or connected content nodes (compare this single storage to previous examples that may store one or two commands per each connected or targeted content node). Additionally, the reduced storage may simplify the operation of store and forward logic 210 as shown in FIG. 9E relative to some other examples described herein; however, it is noted that the content router will generally need to store additional information such as which content node has fetched the change command, etc. Once the data change command has been fetched or received by each content node, the change command may be deleted from command memory 222 .
  • FIG. 9F illustrates another embodiment of an exemplary content router 200 , which may operate to push or directly write data change commands to certain content nodes.
  • outgoing data change commands are stored in a command memory 240 - 2 .
  • Content router 200 may notify the content nodes 300 - 2 , 300 - 3 , and 300 - 4 of an available data change command, for which the respective content nodes may thereafter request the data change commands from the content router 200 .
  • content router 200 may not need to store these data change commands in command memory 240 - 2 ; content router 200 may instead push or write the command directly through to the particular content node (sometimes referred to as “write-through”). Even highly available mobile user-devices may allow an exemplary content router system to write through directly (obviating the need for storage of the outgoing commands in memory).
  • the data change command may be processed by processing logic 250 and pushed to content node 300 - 2 (e.g., without using the outgoing command memory 240 - 2 and waiting for content node 300 - 2 to request the command).
  • these features of content router 200 may potentially reduce the storage required or associated with content router 200 relative to some of the examples described herein.
  • the data change commands for that particular content node may be stored in an outgoing memory 240 - 2 (similar or identical to that described with reference to FIG. 9C , for example) and a notification to content node 300 - 3 made.
  • content node 300 - 3 may be notified of the change command in outgoing memory 240 - 2 via a technical SMS, or the like. Thereafter, content node 300 - 3 may fetch the data change as previously described.
  • content router 200 may store states, filters, information about what content is on the various content nodes, the content node capabilities, and the like to assist in facilitating the direct write through or push to the content node(s). Such information may be stored with or accessible by processing logic 250 , connected data set configuration 500 , and/or the like.
  • store and forward logic 210 as described with respect to FIGS. 9A-9E may be used alone or in combination with other methods and systems (whether described herein or not). Additionally, various examples of store and forward logic 210 and its operation may be used as a primary process for routing data change commands with one or more other examples serving as a secondary process for routing if the primary process is unavailable (e.g., if a resource is unavailable, a content node is unavailable, or the like).
  • FIGS. 10A to 10 D show a Put-Get-Ack procedure from points of view a content node 300 and a content router 200 according to embodiments of the present invention.
  • a goal of this procedure is to resolve conflicting commands within the incoming and outgoing queues 231 , 241 .
  • content nodes 300 may be freed from the burden of resolving conflicts.
  • a content node 300 first sends (PUTs) of all commands pending in the content node 300 to the content router 200 .
  • the content router 200 resolves any conflict between an incoming command and a command already in either the incoming queue 231 or outgoing queue 241 .
  • the content node 300 receives (GETs) commands from the outgoing queue 241 .
  • an acknowledgement (ACK) is received by the content router 200 assuring that the content node 300 received the outgoing commands.
  • FIG. 10A shows a PUT-GET-ACK procedure between a content router 200 and a content node 300 from a point of view of the content node 300 .
  • a content node 300 such as a user device 310 , waits until there is a need or an ability to put a command to or get a command from the content router 200 .
  • a content node 300 receives a notification from the content router 200 that a command is pending in the outgoing queue 241 and/or the content node 300 determines that it has one or more commands to send to the content router 200 .
  • the content node 300 first determines whether there are any commands to send to the content router 200 . By requiring that the content node 300 sends commands before receiving commands, resolution of conflicts is handled in the content router 200 rather than by the content node 300 .
  • the content node 300 sends a request to PUT commands from the content node 300 to the content router 200 . If the content node 300 has one or more commands to put to the content router 200 , it may send a sequence of one or more individual requests each containing a payload including a command. Alternatively, it may send a sequence of one or more requests each containing a payload including batches of commands.
  • the content node 300 receives an acknowledgement that the commands were received by the content router 200 .
  • the content node 300 then checks again at 1102 to determine whether there are any more commands to put to the content router 200 .
  • the content node 300 next checks to determine if there are any commands to get.
  • the content router 200 includes an indication in the acknowledgement received in 1104 . The indication may inform the content node 300 that a pending command is waiting in the outgoing queue 241 . If no commands were pushed to the content router 200 , the content node 300 may determine that there may be one or more pending commands to get based on the notification received earlier.
  • the content node 300 sends a request to the content router 200 .
  • the content node 300 receives a response having a payload containing the one or more commands.
  • the content node 300 processes the commands, which may include executing the commands or may simple save the commands for future execution.
  • the content node 300 sends to the content router 200 an acknowledgement (ACK) that the commands were received and processed.
  • ACK acknowledgement
  • the content node 300 waits for a response that its acknowledgement (ACK) successfully was received by the content router 200 .
  • the content node 300 checks to see whether there are any more commands to get.
  • the content node 300 may determine whether the content router 200 has additional commands by examining the last received response received at 1110 .
  • a response may contain an indication that one or more additional commands are pending in the outgoing queue 241 .
  • a response may contain the one or more additional commands that were pending in the outgoing queue 241 .
  • the content node 300 continues by requesting and processing the commands at 1106 .
  • the response contains the one or more additional commands
  • the content node 300 continues by processing the commands at 1108 .
  • FIG. 10B shows a PUT-GET-ACK procedure between a content router 200 and a content node 300 from the point of view of the content router 200 receiving a new incoming command PUT to the content router 200 by the content node 300 .
  • a content node 300 sends a new command to the content router 200 , where the new command is destined for the incoming queue 231 .
  • the processing logic 250 determines whether any conflict exists between the new command and any command existing in either the incoming queue 231 or the outgoing queue 241 .
  • the processing logic 250 resolves the conflict by determining whether to discard the new command, aggregate the new command with the existing conflicting command, remove the existing conflicting command from the queue 231 or 241 , and/or move the new command to the incoming queue 231 .
  • the process of detecting and resolving conflicts between a new command and an existing command is further described below with reference to FIG. 10D .
  • the processing logic 250 moves the command to the incoming queue 231 .
  • the processing logic 250 begins processing commands in the incoming queue 231 as shown at 1204 .
  • the processing logic 250 may move the command from the incoming queue 231 to the in-transit queue 232 .
  • the processing logic 250 receives an acknowledgement that the command was processed, receives a negative acknowledgement that the command was not processed, or determines that due to a failure, such as a timeout, the command must be processed again.
  • the processing logic 250 receives an acknowledgement. Therefore, the processing logic 250 removes and discards the command from the in-transit queue 232 .
  • the processing logic 250 prepares to move the command from the in-transit queue 232 back to the incoming queue 231 for reprocessing at 1204 .
  • the command to be moved may be treated as a new command.
  • the processing logic 250 performs a conflict check between the command to be moved and commands in the incoming and outgoing queues 231 , 241 for the content node 300 . The process then continues as described above with reference to 1202 .
  • FIG. 10C shows a PUT-GET-ACK procedure between a content router 200 and a content node 300 from the point of view of the content router 200 generating a new outgoing command for a content node 300 to GET from the content router 200 .
  • the content router 200 may generate a new outgoing command in response to an incoming command from a different connected content node associated with the same user.
  • the processing logic 250 determines whether any conflict exists between the new command and any command existing in either the incoming queue 231 or the outgoing queue 241 .
  • the processing logic 250 resolves the conflict by determining whether to discard the new command, aggregate the new command with the existing conflicting command, remove the existing conflicting command from the queue 231 or 241 , and/or move the new command to the outgoing queue 241 .
  • the processing logic 250 moves command to the outgoing queue 241 .
  • the processing logic 250 may send a notification to the content node 300 to indicate that a new command is waiting in the outgoing queue 241 .
  • the processing logic 250 begins processing the commands in the outgoing queue 241 .
  • the processing logic 250 send a command from the outgoing queue 241 to the content node 300 .
  • the processing logic 250 may also move the command from the outgoing queue 241 to the in-transit queue 242 .
  • the processing logic 250 waits for an acknowledgement from the content node 300 indicating that the command was processed by the content node 300 .
  • a failure may occur if the processing logic 250 receives a negative acknowledgement that the command was not processed or determines that due to a failure, such as a timeout, the command must be processes again.
  • the processing logic 250 receives an acknowledgement. Therefore, the processing logic 250 removes and discards the command from the in-transit queue 242 . Alternatively at 1218 , if a timely acknowledgement is not received, the processing logic 250 prepares to move the command from the in-transit queue 242 back to the outgoing queue 241 for reprocessing. At this point, the command to be moved may be treated as a new command. At 1211 A, the processing logic 250 performs a conflict check between the command to be moved and commands in the incoming and outgoing queues 231 , 241 for the content node 300 . The process then continues as described above with reference to 1212 .
  • FIG. 10D shows a structure for detecting conflicts between a new command 400 and existing commands 401 - 407 in the incoming queue 231 and the outgoing queue 241 .
  • a new command 400 may be received from a content node 300 or generated by the processing logic 250 .
  • New commands 400 from a content node 300 are destined for the incoming queue 231 .
  • New commands 400 generated by the processing logic 250 are destined for the outgoing queue 241 .
  • the processing logic 250 determines whether a conflict exists.
  • the processing logic 250 compares the new command 400 to existing commands 401 - 407 in the incoming queue 231 and/or the outgoing queue 241 . If the new command 400 and an existing queued command contain related content or metadata, the processing logic 250 may determine that a conflict must be resolved between the new command 400 and this existing command.
  • the processing logic 250 may determine if one command supersedes the other. In the case where the existing command supersedes the new command, the processing logic 250 may discard the new command 400 . In the case where the new command supersedes the existing command, the processing logic 250 may either replace the existing command with the new command 400 in the appropriate queue 231 or 241 , or it may remove the existing command from the queue 231 or 241 and add the new command 400 as a new entry at a different location in the appropriate queue 231 or 241 .
  • the processing logic 250 may determine that the new command 400 and the command conflicting with the new command 400 should be aggregated into a single command. In the case where commands are aggregated, the processing logic 250 may either replace the existing command with an aggregated command, or it may remove the existing command from the queue 231 or 241 and add the aggregated command as a new entry in the appropriate queue 231 or 241 .
  • FIG. 11 illustrates a representation of a structure of a connected data set configuration 800 according to embodiments of the present invention.
  • a connected data set configuration database 800 includes a hierarchal configuration, e.g., 510 to 570 , for each user connected to the content router 200 .
  • a first user defines a connected data set configuration 510 using a configuration and maintenance tool.
  • the configuration and maintenance tool may be, for example, a web based graphical user interface (GUI) having access to the database 800 via SQL database calls.
  • GUI web based graphical user interface
  • Each user configuration 510 to 570 may include a configuration for user devices 511 and for user accounts 516 .
  • Each configuration for user devices 511 includes a set of configurations for each user device 512 , 513 .
  • Each configuration for user accounts 516 includes a set of configurations for each user account 517 , 518 .
  • Each user device and account configuration 512 , 513 , 517 and 518 includes a set of configurations for each configured content type.
  • connected data set configuration database 800 may be structured using one of several possible hierarchal structures.
  • user devices configuration 511 and user accounts configuration 516 may be combined into a single structure.
  • the hierarchal structure between user devices or user accounts and content type may be reversed such that a content type configuration contains a configuration for multiple user devices and/or user accounts, rather than having a user device or user account configuration containing a configuration for multiple content type.
  • a user device configuration 513 contains a configuration for each content type processed by the user device.
  • the user device B configuration 513 may contain respective configurations 513 - 1 , 513 - 2 , 513 - 3 , 513 - 4 and 513 - 5 .
  • a database ID may be allocated for each content type of a user's connected content nodes. Therefore, a database ID may have a one-to-one relationship to a particular content type on a particular connected content node for a particular user. This database ID may be used by a content node when it communicates with the content router 200 .
  • each command that is generated by a content node may include a specific database ID to identify the user, the content node and the content type as described below with reference to FIG. 13 .
  • the content router may include logic operable to detect and handle duplicate content entries, in particular, when a content node is added to the community.
  • data consolidation logic is included with the store and forward logic 210 (e.g., with the processing logic) of the content router 200 (see, e.g., FIG. 5 ).
  • the data consolidation logic is operable to generate and maintain (e.g., store) a hash-value of at least a portion of the routed payload (including the content and/or metadata).
  • the hash-value is created from at least one “significant” property of each payload, which is generally less than the entire content of the payload.
  • the significant property may include a specific data field depending on the content type, e.g., the first and last name of a contact entry, a phone number for a contact, the subject field for an event entry, or the like.
  • the hash-value may be used to detect possible duplicates whenever new data enters the community and query only these possible duplicate data candidates for inspection. Further, by being based on a portion of the payload (e.g., based on a significant property), non-exact matches may be examined for possible duplicate entries. Such features may avoid the time and cost of having to query all available data whenever new data enters the community and reduce the potential for duplicates because hash values may be relatively quickly compared with a list of hash-values of known content.
  • a list of hash-values may be created and stored (e.g., in repository 600 of content router 200 shown in FIG. 5 ) for all content entries associated with the community of connected nodes.
  • a hash-value may be determined for each data entry or payload by a similar process as for the original data.
  • potential duplicates may be identified relatively quickly compared with comparing the full data entries of old and new data.
  • a potential duplicate When a potential duplicate is identified based on the generated hash-values, various rules may be implemented to determine if the potential duplicates are in fact duplicates and should therefore be stored separately, merged, ignored, or the like.
  • Various rules to determine actual duplicates may be used, and may depend, e.g., on the content type.
  • a rule may be operable to determine an actual or potential duplicate if two content entries or records are an exact match, i.e., all data in all fields are exactly the same between two content entries or records. For example, two contact entries may both consist of an identical name and phone number.
  • a first content node may include a contact entry with a first number of data fields, n.
  • a new content entry may include a second number of data fields, n- 1 .
  • the hash-values may indicate potential duplicates based on similar significant properties (such as a name or phone number in a content entry).
  • the content entries will not have an exact match, however, because the first content entry has additional, unmatched fields. The system may nevertheless identify these as the same record and not create a duplicate entry for the new entry if, for example, all common data fields match.
  • the record which has the largest payload or number of segments/data fields may be used as a base record, whereby the other records are merged into the base record as appropriate. Additional rules may be defined and used to equate data fields of different devices and systems that do not include exact matches etc. For example, a first contact entry listing “John Smith” and a phone number, and second contact entry including “John Smith” and an email, are not exact matches, but may be merged into a single record including “John Smith” and both the email and phone number data. The merged record will be distributed to all content nodes (with some modifications or filtering possible based on content node capabilities/preference/etc.).
  • a first content node may include an event entry with a recurrence rule.
  • a new event entry may include a single event occurring just within that recurrence defined by the recurrence rule of the first content entry.
  • the hash-values may indicate potential duplicates based on similar significant properties (such as the summary of a content entry).
  • the content entries will not have an exact match, however, because the first content entry has additional recurring information and the start date does not match. The system may nevertheless identifies these as the same record in one example and does not create a duplicate entry for the new entry if the single event occurs just within the recurrence defined by the recurrence rule of the first event.
  • the record which has the largest payload or number of segments/data fields may be used as a base record.
  • the merged record, in this case the recurring event, will be distributed to all content nodes (with some modifications or filtering possible based on content node capabilities/preference/etc.).
  • the hash-value provides a relatively fast and cheap process for identifying potential duplicates (compared to storing or querying the actual content from varying content nodes). Additionally, various rules may be defined and utilized to determine actual matches and the treatment of those matches (e.g., to merge, discard, etc.).
  • a configuration 513 - 1 for contact content type of a particular content node may require a contact to include a phone number.
  • a contact may require a contact to include a phone number.
  • some mobile phones only allow a contact including a phone number.
  • a user may only want contacts with phone numbers on the user's device. If such a flag is set, all contacts without a phone number will not be routed to this content node.
  • a flag may indicate that phone numbers must be digits only without other ASCII characters.
  • a repository may be used as described below to hold an unfiltered version of a ASCII filled phone number while the content router will prepare a contact include a digit-only phone number.
  • a configuration 513 - 2 for event content type of a particular content node may allow only events occurring within the next two weeks (or other set future duration) to be routed to the content node. Therefore, if one content node sends a new event to the content router, the content router will determine if this event will occur within the predetermined future time. If the flag and duration indicate that the event falls outside the parameters, the content router will not route the event to this content node. Additionally, a content router may include an inventory as described below that may be periodically reviewed to determine if an event falls within the duration and may be retrieved from one content node and sent to this content node. Another flag may indicate that all attachments will be removed from an event before forwarding to this content node. Another flag may indicate that all notes will be removed from an event before forwarding to this content node.
  • a configuration 513 - 3 for to-do task content type of a particular content node may allow only tasks due within the next two weeks (or other set future duration) to be routed to the content node.
  • a configuration 513 - 4 for email is shown to include routing parameters used in routing rules and transformation parameters used in transformation rules.
  • Routing rules may be used by the processing logic 250 to select a set of destination content nodes.
  • the set may be a null set, whereby no content nodes are selected for receipt of an outgoing command.
  • the set may indicate one or more destination content nodes that may receive an outgoing command.
  • Routing rules include the capability of a content node to receive a particular content type, or an upper limit on a number of elements allowed on a content node. For example, a routing rule may be to bar any commands to a device that will increase the number of unread or read emails.
  • a routing parameter may be a flag indication if the content node is or is not accepting commands.
  • a routing parameter may indicate the maximum size of an acceptable input. For example, if a content node is a mobile phone with limited memory, the routing parameter may be used to block all email messages greater that a particular size (e.g., greater than 1 kilobyte).
  • a routing parameter may indicate that the content router should block all commands destined to the content node if the connection speed is below a predetermined rate or if the connection type does not provide a high transfer rate. For example, routing parameter may indicate that a content node, such as a mobile phone, will not receive email messages with attachments if the mobile phone is not connected with a wired connection.
  • the processing logic 250 may generate an outgoing command.
  • the processing logic 250 may use transformation parameters when processing transformation rules. Transformation rules may be used to determine the contents of the generated outgoing command.
  • a transformation parameter may be a maximum size value used to truncate commands to a maximum size (e.g., limiting the size to less than 1 kilobyte).
  • a transformation parameter may be a flag used to determine whether a particular content type should be cut from the command. For example, a flag may be used to indicate that the content node only accepts attachments that are image files.
  • a transformation parameter may be a flag used to block all attachments. For example, a flag may be used to indicate that the content node does not accept attachments that are document files.
  • a transformation parameter may indicate that the content router should remove all attachments if the connection speed is below a predetermined rate or if the connection type does not provide a high transfer rate.
  • transformation parameter may indicate that a content node, such as a mobile phone, accepts email messages with the attachments if the mobile phone is connected with a wired connection but indicates that the attachments may be stripped off if the mobile phone is connected with a wireless connection.
  • a transformation parameter may be a flag used to block all attachments if the content node if approaching a full state. For example, a flag may be used to indicate that the content node does not accept attachments when the content node is nearly full (e.g., 90% full). The content node may strip attachments from emails thereby preserving free memory on the content node.
  • a configuration 513 - 5 for library item content type of a particular content node may allow only images to be routed to the content node. Another flag may be used to filter audio files. Additionally, another flag may be used to filter movie files.
  • FIGS. 12A to 12 E illustrate external and internal logic, which may be used to interface a content router 200 to user devices 310 and user accounts 320 according to embodiments of the present invention.
  • a content routing system may include the store and forward logic 210 .
  • a content routing system may also translation logic such as include protocol logic 260 and/or protocol interface logic.
  • a content routing system may include a gateway such as a device gateway and/or a server gateway. Alternatively, the gateway may be external to the content routing system.
  • FIG. 12A illustrates a content router 200 coupled to an external protocol interface logic 260 and including a connected data set configuration 500 and store and forward logic 210 coupled to a command interface of protocol interface logic 260 .
  • the protocol interface logic 260 may be used to couple the store and forward logic 210 with various content nodes types such as user devices 310 - 1 to 310 - 3 and user accounts 320 - 1 to 320 - 3 using interfaces having disparate protocols.
  • the protocol interface logic 260 translates between a protocol used by a content node 310 , 320 and commands 400 processed in the store and forward logic 210 .
  • the protocol interface logic 260 receives messages 910 - 1 to 910 - 3 and 920 - 1 to 920 - 3 based on a specific content node protocol used to communicate with the content node 310 - 1 to 310 - 3 and user accounts 320 - 1 to 320 - 3 .
  • the protocol interface logic 260 converts these signals to commands 400 for the store and forward logic 210 .
  • the protocol interface logic 260 also receives commands 400 from the store and forward logic 210 and converts these commands back to messages 910 - 1 to 910 - 3 and 920 - 1 to 920 - 3 tailored for the specific content node 310 - 1 to 310 - 3 and 320 - 1 to 320 - 3 .
  • a content router 200 couples to a command interface of the protocol interface logic 260 . As described below, the content router 200 couples to a message interface of protocol interface logic 260 .
  • FIG. 12B shows a content router 200 including store and forward logic 210 and a protocol adapter 268 translating between messages 801 and commands 400 .
  • the protocol interface logic 260 including a device gateway 264 translating between messages 910 from a user device and messages from the content router 200 .
  • the device gateway 264 couples the content router 200 with user devices utilizing various protocols.
  • the various user devices and protocols may include a mobile phone running a SyncML protocol or an SMS based protocol, a JavaTM based client device running a binary protocol, a home personal computer based client running HTTP protocol, or the like.
  • the device gateway 264 performs a function of translating between various protocols used by the different user device types and a common protocol, such as a XML-RPC (extensible Markup Language-Remote Procedure Calling) protocol, used by the content router 200 .
  • a common protocol allows for easier scalability when additional gateways also using the common protocol are coupled to the content router 200 .
  • using a common protocol decouples the function of device protocol conversion from the protocol adapter 268 as well as from the store and forward logic 210 .
  • the device gateway 264 models a server to support a client-server relationship from the point of view of the user device 310 , which acts as a client.
  • the device gateway 264 also models a client to support a client-server relationship from the point of view of the store and forward logic 210 , which acts as a server.
  • the protocol adapter 268 is separate from the content router 200 .
  • the protocol adapter 268 may be part of the protocol interface logic 260 or may be standalone.
  • Some user devices 310 may include a user interface application unaware of the content router 200 .
  • the user device 310 may include a data routing driver knowledgeable of the content router 200 and which interfaces with the user interface application.
  • the data routing driver uses an available protocol to communicate with the content router 200 thereby coupling the user application with the content router 200 . Commands received over the available protocol are translated into instructions for the user application. Additionally, changes made within the application are communicated as messages sent over the available protocol to the content router 200 .
  • Some user devices 310 may include both a data routing driver and an application knowledgeable of the content router 200 .
  • Other user devices 310 such as a SyncML-enabled mobile phone, may not need a data routing driver knowledgeable of the content router 200 because of capabilities inherent in such devices.
  • a SyncML-enabled mobile phone inherently includes over-the-air SyncML synchronization routines invokeable by the content router 200 . Therefore, the content router 200 may push changes to the SyncML-enabled mobile phone without requiring content router knowledgeable software on the user device 310 .
  • FIG. 12C shows a content router 200 including store and forward logic 210 and a protocol adapter 268 translating between messages 801 and commands 400 .
  • the protocol interface logic 260 including a server gateway 266 , which translates between messages 920 from a user account and messages having a common protocol for use in the content router 200 .
  • the server gateway 266 couples the content router 200 with user accounts utilizing various protocols.
  • the server gateway 266 allows access to the content router 200 by user accounts communicating according to various server protocols such as HTTP XML, J DAV, Web DAV Exchange, IMAP, POP3, or the like.
  • the server may include a PIM server, such as a Yahoo!® PIM server, a photo server, such as a Yahoo!® Photos server, an email server, such as a PacBell email server, or the like.
  • a content node 320 may be a user's email account on an email server using an IMAP protocol to communicate to the content router 200 .
  • the server gateway 266 models a client to the store and forward logic 210 .
  • the server gateway 266 models an intermediary between two servers.
  • two servers do not communicated in a client-server relationship.
  • the server gateway 266 allows the account server to communicate with the store and forward logic 210 server, both acting as servers in a client-server relationship.
  • the server gateway 266 models a client to support a client-server relationship from the point of view of the user account 320 and models a client from the point of view of the store and forward logic 210 .
  • the protocol interface logic 260 is positioned externally from the content router 200 .
  • the content route 200 includes the protocol interface logic 260
  • FIG. 12D shows a content router 200 containing store and forward logic 210 , a protocol adapter 268 , and protocol interface logic 260 including a device gateway 264 and a server gateway 266 .
  • the device gateway 264 and a server gateway 266 translate between protocols used by devices and servers and a common protocol, such as an XML-RPC protocol.
  • the protocol adapter 268 translates between the common protocol and commands 400 used to communicate with the store and forward logic 210 .
  • Commands 400 sent between the store and forward logic 210 and the protocol adapter 268 may be in a request-response scheme such as in a JavaTM platform including a Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) technology interface.
  • RMI-IIOP Remote Method Invocation over Internet Inter-ORB Protocol
  • a Java RMI platform allows an object running on a Java enabled content node to invoke methods on an object running in a Java based store and forward logic 210 and vise versa.
  • the content router 200 may configure the device gateway 264 and/or the server gateway 266 with one or more of the routing parameters and/or one or more of the transformation parameters, such that the gateway may perform routing and transformations on commands of a content node.
  • the device gateway 264 is shown coupling the protocol adapter 268 to a mobile phone 310 - 1 running a SyncML protocol 910 - 1 and a JavaTM based client device 310 - 2 operating with a binary protocol 910 - 2 .
  • the server gateway 266 is shown coupling the protocol adapter 268 to a PIM server 320 - 1 , a photo server 320 - 2 , and an email server 320 - 3 with protocols 920 - 1 , 920 - 2 , and 920 - 3 , respectively.
  • a common protocol such as XML-RPC
  • XML-RPC allows applications running on disparate operating systems and in different environments to make remote procedure calls using HTTP as a transport layer and XML as an encoding scheme.
  • the XML-RPC protocol allows complex data structures to be transmitted from an application running on the device gateway 264 , the server gateway 266 , an XML-RPC-enabled device, or an XML-RPC-enabled server to the protocol adapter 268 and the store and forward logic 210 .
  • the protocol adapter 268 or the store and forward logic 210 may process the received data structure and return a result to the application.
  • Content nodes having the capability to communicate using the common protocol may bypass the gateway and may communicate directly with the protocol adapter 268 .
  • a Symbian device or a WinCE, Win32 or home personal computer (PC) 310 - 3 running a client application may communicate directly with the protocol adapter 268 and avoids the device gateway 264 since the PC 310 - 3 already employs the common protocol.
  • a smart phone 310 - 4 may also communicate using the common protocol and avoid the device gateway 264 .
  • user accounts may use the common protocol thereby bypassing the server gateway 266 to communicate with the protocol adapter 268 .
  • a Yahoo!® server 320 - 4 uses the common protocol thereby avoiding the server gateway 266 .
  • a content node communicates with commands 400 directly (not shown), and thus may avoid using a protocol adapter 268 .
  • the protocol adapter 268 may treat messages 801 from device gateway 264 , messages 803 from a server gateway 266 , messages 810 - 3 , 810 - 4 from user devices 310 - 3 , 310 - 4 and messages 820 - 4 from user accounts 320 - 4 similarly, thereby simplifying the design and implementation of the protocol adapter 268 . Therefore, incoming messages in the common protocol are treated similarly regardless of input path to the protocol adapter 268 . As a result, the store and forward logic 210 may treat commands from each content node similarly.
  • the content router 200 may also include a notification signal (dotted line) sent from the store and forward logic 210 to a device and/or server gateway 264 , 266 as shown in FIG. 12D .
  • the store and forward logic 210 may periodically send a notification signal (dotted lines) to the appropriate gateway 264 , 266 .
  • a notification may be send from the store and forward logic 210 to the gateway 264 , 266 using telnet, HTTP, a custom API, or the like.
  • the gateway 264 , 266 then may initiate a request for the outgoing command or commands 400 from the store and forward logic 210 .
  • the gateway 264 , 266 may receive a response including the command from the outgoing queue 241 .
  • a gateway 264 , 266 After a gateway 264 , 266 receives a notification signal and fetches an outgoing command, the gateway prepares an outgoing notification message containing the command. If the outgoing command is relatively small in size, the gateway 264 , 266 may include the command within the notification.
  • the store and forward logic 210 determines that a notification may be sent to a content node 300 to inform the content node 300 that the outgoing queue may contain an outgoing command.
  • the store and forward logic 210 generates a notification signal for a gateway 264 , 266 .
  • the gateway 264 , 266 receives a notification signal from the store and forward logic 210 .
  • the notification signal may indicate availability of an outgoing command in the outgoing queue 241 for a content node 300 .
  • the gateway 264 , 266 may request the outgoing command, for example, by a call to the protocol adapter 268 .
  • the protocol adapter 268 retrieves the command from the store and forward logic 210 , which provides it to the gateway 264 , 266 .
  • the gateway 264 , 266 receives the response containing the outgoing command.
  • the gateway 264 , 266 prepares an outgoing notification containing the outgoing command.
  • the gateway 264 , 266 may encode the outgoing command into a compact binary sequence.
  • the gateway 264 , 266 then sends the outgoing notification to the content node 300 , which may be either a user device 310 such as a mobile phone or a user account 320 such as an email account.
  • a device gateway 264 may send the outgoing notification to a mobile phone by way of an SMS gateway.
  • the gateway 264 , 266 may send an acknowledge that the outgoing notification to the store and forward logic 210 via the protocol adapter 268 .
  • FIG. 12E shows a multi-server content routing system according to embodiments of the present invention.
  • the content router 200 operates as a first server.
  • the content router 200 includes store and forward logic 210 and a protocol adapter 268 , which may communicate internally via a command based exchange, such as with RMI-IIOP, and externally via a common protocol, such as XML-RPC.
  • the content router 200 may also include a connected data set configuration 500 and/or a repository 600 and/or a file relay server 700 either internally to or externally from the content router 200 .
  • the command memory 220 , the connected data set configuration 500 , the repository 600 , and the file relay server 700 may each be formed in separate memory, combined in a common memory, or formed in a combination of separate and combined memory.
  • the command memory 220 , the connected data set configuration 500 , the repository 600 , and the file relay server 700 may each be formed in separate databases, such as separate relational databases, or two or more may be combined a combined database.
  • the content routing system also includes servers to communicate to content nodes.
  • a device gateway (server) 264 interfaces to user devices 310 using device specific protocols 910 .
  • a server gateway (server) 266 interfaces to user accounts 320 using server specific protocols 920 .
  • Some embodiments of the present inventions include or are coupled to a file relay server 700 .
  • the file relay server 700 acts as a file relay memory and may be coupled to one or more of the servers and/or content router 200 (direct connection not shown in figure) and/or one or more of the content nodes.
  • the file relay server 700 facilitates transportation of commands having separable segments among a plurality of content nodes comprising detaching the segments prior to the commands being saved to a command memory of a store and forward logic.
  • the file relay server 700 may provide an input for a content node 310 , 320 , a server 264 , 266 , or a content router 200 (a protocol adapter 268 or a store and forward logic 210 ) to store one or more files so that the files may be removed from incoming commands before the incoming command is stored in the command memory 220 of the store and forward logic 210 .
  • the command memory is capable of holding a larger number of commands and may be more agile in processing commands.
  • the file relay server 700 may also provide a mechanism for routing file from and to a content node behind a firewall.
  • Two content nodes 300 separated by a firewall may not permission to access content, such as a file, and metadata from the other. However, if both content nodes 300 are able to provide the content and/or metadata to the file relay server 700 either directly or indirectly through a server 264 , 266 , a content router 200 , a protocol adapter 268 , or a store and forward logic 210 , the content nodes 300 may, in effect, exchange the content and/or metadata.
  • a file is encrypted by the content node 310 , 320 , a server 264 , 266 , a content router 200 , a protocol adapter 268 , or a store and forward logic 210 before it is saved to the file relay server 700 .
  • a security mechanism is implemented so that a file provided by one content node are only available to other content nodes connected to the same user, for example, as configured in the connected data set configuration for that users.
  • a security mechanism may include authentication of each request for a file from the file relay server 700 , as well encryption of the received and delivered files.
  • the multi-server content routing system may use the file relay server 700 to provide a path for a content node to receive an attachment when a peer-to-peer 450 connection, as shown in FIG. 5 , is not desirable or not possible.
  • a peer-to-peer 450 connection may not be possible when one or both of the content nodes are behind firewalls that block peer-to-peer connections. Additionally, a peer-to-peer 450 connection may not be possible when each content node is not simultaneously connected to the network 10 .
  • the file relay server 700 may provide a temporary repository for attachments or other segments of a command.
  • the file relay server 700 may off load processing form the store and forward logic 210 .
  • a source content node, a device gateway or a protocol adapter may cut a detachable segment from an incoming command or message, such as a large file from an email.
  • a reference to the stored segment on the file relay server 700 may be positioned in place of the removed segment in the incoming command.
  • the content router 200 and connected content nodes 300 may process a reference to a file residing on the file relay server 700 in a similar manner as a reference back to a file residing on the source content node 300 .
  • the resulting abridged incoming command may then be sent to the store and forward logic 210 and may be significantly smaller by the removal or replacement with a reference of a large segment.
  • an outgoing command corresponding to the abridged incoming command may pass out from the store and forward logic 210 .
  • the protocol adapter, device gateway or a destination content node may detect the reference and replace the reference with the segment retrieved from the file relay server 700 . In this way, the command memory 220 may be spared the task of holding large files.
  • a stand alone file relay server 700 is used.
  • a new email including an attachment is received via the Internet by a user's corporate email account.
  • the user account communicates a change, that is, the arrival of the new email to the content router 200 .
  • the store and forward logic 210 receives an incoming command containing the email, however, the content node 300 replaced the attachment in the email with a metadata link identifying the location of the attachment on the corporate server. If the email account is behind a firewall, other connected content nodes may not be able to access a metadata link to the attachment. In this case, the store and forward logic 210 may forward the metadata link to the protocol interface logic 260 and may instruct the protocol interface logic 260 to fetch the attachment based on the metadata link.
  • the protocol interface logic 260 directs the fetched attachment to the file relay server 700 .
  • the store and forward logic 210 replaces the metadata link identifying the corporate server as the source of the attachment with a link locating the attachment on the file relay server 700 .
  • a content node receiving the outgoing command will be referred to the file relay server 700 rather than to an inaccessible server.
  • a public email server is used as the file relay server 700 .
  • a new email including an attachment is received via the Internet by a user's corporate email account.
  • the user account communicates the arrival of the new email to the store and forward logic 210 with a reference to the attachment rather than the attachment itself.
  • the store and forward logic 210 instructs the protocol interface logic 260 to fetch the attachment based on the reference.
  • the protocol interface logic 260 directs the attachment to a command destined for the public email server.
  • the store and forward logic 210 then generates commands to each of the other connected content nodes with a metadata link directing a user to the public email server rather than the corporate email server. In this way, a content node may have access to an attachment that originated on an email server inaccessible to the content node.
  • a first content node sends an incoming command including an embedded attachment to the content router 200 .
  • the gateway 264 or 266 removes the attachment from the command and saves the attachment to the file relay server 700 .
  • the gateway may remove all attachments or alternately particular attachment types.
  • the gateway may base the decision to remove one or more attachments base on one or more configuration parameters, which may be specific to a content node, a content node type and/or a user's connected data set configuration.
  • the gateway may replace the attachment with a reference, which may allow a gateway or a content node itself to retrieve the attachment from the file relay server 700 .
  • the protocol adapter 268 or the store and forward logic 210 may swap the attachment and a reference in the command and store to and/or retrieve the attachment from the file relay server 700 .
  • the content node 310 or 320 interfaces with the file relay server 700 .
  • a user account 320 may forward the email to the content router 200 as a command to add a new email containing a file.
  • the user account 320 may detach then forward the file to the file relay server 700 .
  • the content node 320 then generates and sends a command with the email having the attachment replaced with a reference to the file on the file relay server 700 .
  • the content node 310 may automatically retrieve the file from the file relay serer 700 and replace the reference with the retrieved file to restore the original email.
  • the content node 310 may allow the user to manually fetch the file by following the reference to the file relay server 700 .
  • the gateways 264 , 266 interfaces with the file relay server 700 .
  • the gateway 264 , 266 receiving the incoming command may forward the file to the file relay server 700 then substitute the file in the command with a reference to the file on the file relay server 700 .
  • the server 264 , 266 receiving command from the content router 200 may restore the email by replacing the reference with the file extracted from the file relay server 700 .
  • the protocol adapter 268 interfaces (not shown) with the file relay server 700 . For example, if the protocol adapter 268 receives an incoming command from a source content node 310 , 320 to add a new email containing a file, the protocol adapter 268 may forward the file to the file relay server 700 . The protocol adapter 268 then replaces the attached file with a reference to the file on the file relay server 700 . When a destination content node 310 , 320 requests an outgoing command that contains the reference, the protocol adapter 268 may replace the reference with the file extracted from the file relay server 700 .
  • the store and forward logic 210 interfaces (not shown) with the file relay server 700 . For example, if the store and forward logic 210 receives an incoming command from a source content node 310 , 320 to add a new email containing a file, the store and forward logic 210 may forward the file to the file relay server 700 . The store and forward logic 210 then replaces the file in the command with a reference to the file on the file relay server 700 . When the store and forward logic 210 retrieves an outgoing command that contains the reference, it may replace the reference with the file extracted from the file relay server 700 .
  • FIGS. 13 and 14 A to 14 I show structures of various commands according to embodiments of the present invention.
  • FIG. 13 shows a command associated with a primary key and database identifier according to embodiments of the present invention.
  • the term command includes notifications and messages (which need not necessarily be in a “command” format) of such changes that may be acted upon accordingly by a receiver of the notifications and messages, such as content node.
  • a command includes a primary key that is a monotonically increasing value assigned by the processing logic 250 to each incoming command.
  • the primary key is unique for all commands associated with a user.
  • the primary key may also be unique for all commands associated with all users.
  • a time stamp may be used as the primary key.
  • a command is also associated with a database identifier.
  • the database identifier may be used as an index or key into a database including commands from multiple users and multiple content nodes.
  • the database identifier may be a sequentially increasing number assigned by the database for each content node and content type being added to the database. Therefore, the database identifier may specifically identify, either indirectly or directly, a particular user, a particular content node or content node type, and a particular content type.
  • a content node identifier may include an identifier to a particular user device or user account.
  • a content type may include an indication of one of a Contact item, an Event item, a ToDo item, an Email item, or a Library item.
  • the Library item may be used to indicate one of ConnectedPhoto metadata, ConnectedDocuments metadata, or ConnectedMusic metadata.
  • a command may also be associated with a queue identifier indicating whether the command may be considered to reside in an incoming queue 231 , an incoming in-transit queue 232 , an outgoing queue 241 , or an outgoing in-transit queue 242 .
  • the command may be stored as an entry into a database, such as a SQL database, with associated attributes including the primary key, the database identifier and the queue identifier.
  • a command may contain a command type and a payload.
  • the payload may include the content itself.
  • the payload may include metadata, or may include both the content and metadata.
  • Metadata provides information concerning the quality, condition, and other characteristics of the content. Metadata may include information such as a description of the content, an indication of a change to the content, and/or a reference or link to a source of the content.
  • the command type indicates an action taken or requested.
  • the command type indicates one of a list of actions including: add, update, delete, get, get-results, query, query-result, query-end and clear.
  • the command type indicates a change that has occurred.
  • a command received with an add command type means that content was added to the content node.
  • the command type indicates a change that the content router is requesting to occur on a content node in order to keep the content node synchronized with a content node where a change was made.
  • an add command type means that the content specified in the payload should be added to the content node.
  • a command having a command type of add indicates an action of adding a content record to a content node.
  • Payload for an add-command type may include the content itself, metadata about the content and/or a reference to the content.
  • a command having a command type of delete indicates an action of deleting a content record from a content node.
  • Payload for a delete-command type may include metadata indicating which content and/or metadata about the content to delete.
  • a command having a command type of get indicates a request for getting the contents of a record from a content node.
  • Payload for a get-command type may include metadata indicating which content and/or metadata about the content to get.
  • a command having a command type of get-result is a command sent in response to a get-command type.
  • Payload for a get-result type may include the content itself, metadata about the content and/or a reference to the content.
  • a command having a command type of query indicates a request for a category of content from a content node.
  • Payload for a query-command type indicates the category of content being requested.
  • the query-command type may be used to request all content on a content node, or all content having particular characteristics.
  • a command having a command type of query-result indicates a response to a query-command type.
  • Payload for a query-result-command type includes the requested content or metadata about the content.
  • the query-result-commands may be sent by the content node 300 in multiple batches; therefore the content router 200 may need to given an indication of when the query results flow has finished.
  • the final response to a query-command type is indicated in a command having a command type of query-end.
  • the Payload for a query-end-command type may be either the final content having the particular characteristic or a null thereby indicated an empty set response. If no results are found, a query-command type results in a query-end-command type indicating a null response. If a single result is found, a query-command type results in a query-end-command type indicating a matching response. If more than one result is found, a query-command type results in one or more query-result-command types followed by a query-end-command type containing the final match.
  • a command having a command type of clear instructs a content node to remove a category of content indicated by the payload.
  • a command having a command type of refresh instructs the content router 200 to recover the sending content node.
  • recovering may be initiated by either sending the content node 300 a clear command to clear its content or a query command to import all its data.
  • the content node 300 may receive a consolidated content and metadata from one or more of the other content nodes, such that the content node 300 may be in-synch with connected content nodes.
  • the command also includes a data payload having a format dependent on the command type and data type.
  • the data payload may contain a changed record or may contain metadata such as a link or reference to the changed record located at the data source or at a file relay server.
  • FIG. 14A shows a new email to be added to a content node.
  • the data payload includes an email ID used to uniquely identify an email, a header, the first 2 kilobytes of the message and a link to the original message.
  • FIG. 14B shows a command to instruct content nodes that an email has been read.
  • FIG. 14C shows a command to delete a particular email.
  • FIG. 14D shows a command to add a new audio file.
  • FIG. 14E shows a command to delete an audio file.
  • FIG. 14F shows a command to add a new appointment.
  • FIG. 14G shows a command to add a new contact where the command contains the record.
  • FIG. 14H shows a command to update a new contact where the command also contains the record.
  • FIG. 14I shows a command to add a photo image. The photo itself is not included in the command but a reference to the original photo image may be included.
  • FIGS. 15A to 15 C illustrate sequence diagrams showing signaling between a user device 310 and store and forward logic 210 according to embodiments of the present invention.
  • FIG. 15A shows a sequence when a user device 310 pushes one or more commands to a content router 200 .
  • a user device 310 such as a mobile PC with wireless capabilities, may undergo a series of changes to content and metadata on the user device 310 .
  • An application running on the user device 310 may periodically prepare a payload indicating the changes made during the period or may send commands when it regains wireless communications. Using a protocol available to the user device 310 , the application prepares a REQUEST message to put a payload containing a list of commands. For example, a user may have received a new SMS message AAA. Therefore, the application may generate a command indicating that connected content nodes may add a new email AAA.
  • a batch of commands is limited to include only commands operating on a common command type.
  • a batch of commands may include only commands add, delete or modify email messages.
  • each REQUEST-RESPONSE is an atomic pair of commands, where both commands must occur otherwise neither is considered successful.
  • each REQUEST-RESPONSE pair according to the present invention may make progress in performing a task. For a wireless network, a long sequence of pairs of commands has a greater probability of incurring and interruption. Therefore, the single REQUEST-RESPONSE atomic pair provides optimal reliability and through put.
  • the user device 310 sends the REQUEST to put commands contained in its payload to a device gateway 264 , which models a server to the user device 310 .
  • the device gateway 264 acts on and responds to requests.
  • the device gateway 264 translates from the device protocol to the internally used protocol, and then sends to the protocol adapter 268 a REQUEST indicating a put of the commands indicated in the payload.
  • the device gateway 264 may be bypassed.
  • the protocol adapter 268 converts the payload of the REQUEST to a sequence of commands (e.g., add, delete and update) and sends (puts) the commands to the store and forward logic 210 for the store and forward logic 210 to process.
  • the store and forward logic 210 may assign a monotonically increasing primary key (e.g., 0010021, 0010022 and 0010023) to each command for internal use.
  • the store and forward logic 210 may determine a database ID, which may uniquely identify a user, a particular content node, and a content type.
  • the store and forward logic 210 may also set the queue ID for each command to indicate that the command is an incoming or outgoing command that is pending execution or pending acknowledgement of successful execution.
  • the store and forward logic 210 may perform a conflict check against each of the commands associated with the same database ID. If no conflicts are detected, the commands may be stored in the database with the assigned attributes. If a conflict is detected, the store and forward logic 210 resolves the conflict by removing a command existing in the database, discarding the incoming conflicting command, and/or aggregating the incoming command and the existing command.
  • the store and forward logic 210 In response to successful processing and entry into the incoming queue, the store and forward logic 210 returns an indication of the success to the protocol adapter 268 .
  • the protocol adapter 268 responds to the REQUEST from the device gateway 264 with a RESPONSE that indicates successful forwarding of all of the commands received in the REQUEST.
  • the successful processing of the REQUEST from the user device 310 is acknowledged with a RESPONSE indicating the success as shown.
  • a user device 310 receiving the RESPONSE indicating a success may discard the payload of commands sent earlier. If the user device 310 fails to receive this acknowledgement, it may resend the payload of commands in a subsequent REQUEST.
  • a user device 310 completes a transaction with the content router 200 with a single REQUEST-RESPONSE exchange as shown.
  • a single REQUEST-RESPONSE exchange reduces the change of an error interrupting a session as would occur if a protocol required multiple REQUEST-RESPONSE exchanges to complete a transaction.
  • Each request and response pair is designed to make progress, unlike multi-pair protocols. In a multi-pair protocol, if a failure occurs midstream all progress is lost and the entire session must be restarted from the beginning. Therefore, in accordance with embodiments of the present invention, each successful single REQUEST-RESPONSE exchange makes progress towards completing a task of synchronizing content nodes and any failure effects only the single REQUEST-RESPONSE exchange.
  • FIG. 15B shows a sequence when a user device 310 requests (pulls) commands from a content router 200 after a notification is received.
  • the store and forward logic 210 may generate a notification signal to instruct the device gateway 264 to send a notification to the user device 310 .
  • the notification may or may not include an indication of content type.
  • the device gateway 264 may collect a series of notifications destined for a content node and may periodically send the collected notifications to the user device 310 , for example, using an HTTP packet, if available, or an SMS message.
  • Notifications may be sent with little delay if a user device 310 is connected to the network 10 with a cost free channel or a channel of negligible cost, such as if it is docked to a wired internet connection. Notifications may be collected and send at frequent intervals if the user device 310 is connected with an inexpensive channel, such as with a GPRS connection. Notifications may be collected and sent infrequently if user device 310 is connected with an expensive channel, such as a SMS connection.
  • the content routing system keeps a flag updated to indicate a current connection type, thereby providing a variable the content routing system may use when determining a frequency of updating a content node.
  • the user device 310 may begin a single REQUEST-RESPONSE session to get a content type of pending commands.
  • the user device 310 sends the device gateway 264 a REQUEST to get content type of the pending commands.
  • the device gateway 264 replies with a RESPONSE to the REQUEST including an indication of the content type of the pending command.
  • the user device 310 may begin a single REQUEST-RESPONSE session to get a single command or batch of pending commands.
  • the user device 310 sends the device gateway 264 a REQUEST to get pending commands.
  • the device gateway 264 converts the REQUEST from the external protocol used by the user device 320 to a common internal protocol.
  • the device gateway 264 sends the REQUEST in the common protocol to the protocol adapter 268 .
  • the protocol adapter 268 converts the REQUEST to a call to get commands from the outgoing queue 241 .
  • the store and forward logic 210 returns a payload containing a batch of commands from the outgoing queue 241 .
  • the store and forward logic 210 may return a single command at a time, which the protocol adapter 268 may combine to form a batch of commands.
  • the protocol adapter 268 may associated an index to indicate the number of commands in the payload.
  • the protocol adapter 268 replies to the REQUEST received from the device gateway 264 with a RESPONSE containing the payload of commands to be executed by the user device 310 .
  • the protocol adapter 268 may reply with a single command at a time in each response.
  • the device gateway 264 forwards the RESPONSE as a RESPONSE to the REQUEST originally received from the user device 310 .
  • the user device 310 begins a second REQUEST-RESPONSE exchange to acknowledge successful processing of the commands.
  • the device gateway 264 forwards this acknowledgement to the protocol adapter 268 , which make a call to remove commands from the in-transit queue 242 in the store and forward logic 210 .
  • the store and forward logic 210 returns a success.
  • the protocol adapter 268 replies to the REQUEST with a RESPONSE acknowledging the success.
  • the device gateway 264 replies to the REQUEST from the user device 310 with a RESPONSE acknowledging the success.
  • FIG. 15C shows a sequence of events when a content router 200 pushes a command within a notification to a user device 310 .
  • the store and forward logic 210 includes a low priority and/or relatively small payload within a notification.
  • the fact that an email has been read may be considered a low priority and small byte sized event.
  • Such low priority events may be communicated with a notification layer without the necessity of receiving an acknowledgement typically required in a REQUEST-RESPONSE exchange.
  • the store and forward logic 210 may send a payload including a flag showing that content GGG was modified.
  • Command GGG may represent an email flag used to indicate that an email has changed from an unread state to a read state.
  • the payload may also contain an indicator used to identify the particular email.
  • FIGS. 16A to 16 D illustrate sequence diagrams showing signaling between a user account 320 and store and forward logic 210 according to embodiments of the present invention.
  • FIG. 16A shows a sequence when a content router 200 receives (gets) commands from a user account 320 .
  • a server gateway 266 may periodically poll the user account 320 with a single REQUEST-RESPONSE exchange. If not changes exist, the user account 320 may send a RESPONSE indicated such. If a change exists, the user account 320 may send a RESPONSE indicated the change (not shown). Alternatively, some user accounts 320 may initiate a REQUEST-RESPONSE exchange to indicate that a change exists. The server gateway 266 acknowledges that the REQUEST was received with a RESPONSE including an acknowledgement. In either case, once the server gateway 266 knows that one or more changes exists, the server gateway 266 sends a REQUEST requesting the changes. The user account replies in a RESPONSE with a payload containing a list commands.
  • the server gateway 266 translates from the server protocol to the common internally used protocol, and then sends to the protocol adapter 268 a REQUEST indicating a put of the commands indicated in the payload. Alternatively, if the user account 320 was enabled to communicate using the common protocol, the server gateway 266 may be bypassed.
  • the protocol adapter 268 converts the payload of the REQUEST to a sequence of commands (e.g., add, delete and update) and provides the commands to the store and forward logic 210 .
  • the store and forward logic 210 processes each command.
  • the store and forward logic 210 may assign a monotonically increasing primary key (e.g., 0030021, 0030022 and 0030023) to each command.
  • the store and forward logic 210 may determine a database ID, which may uniquely identify a user, a particular content node, and a content type.
  • the store and forward logic 210 may also set the queue ID for each command to indicate that the command is in an incoming queue state.
  • the store and forward logic 210 may perform a conflict check against each of the commands associated with the same database ID. If no conflicts are detected, the commands may be stored in the database with the assigned attributes. If a conflict is detected, the store and forward logic 210 resolves the conflict by removing a command existing in the database, discarding the incoming conflicting command, and/or aggregating the incoming command and the existing command.
  • the store and forward logic 210 In response to successful processing and entry into the incoming queue, the store and forward logic 210 returns an indication of the success to the protocol adapter 268 .
  • the protocol adapter 268 in turn responds to the REQUEST from the server gateway 266 with a RESPONSE of success. If any REQUEST-RESPONSE exchange fails, previous REQUEST-RESPONSE exchange will not need to be repeated.
  • the server gateway 266 exchanges a REQUEST-RESPONSE pair (not shown) with the user account 320 to inform the user account 320 that it may discard the previously communicated commands.
  • FIG. 16B shows a sequence when a content router 200 pushes (puts) commands to a user account 320 .
  • store and forward logic 210 When store and forward logic 210 has commands in its outgoing queue for a user account 320 , it may send a notification signal to the server gateway 266 .
  • the notification signal includes a content type.
  • the server gateway 266 captures the notifications and models a client when sending a REQUEST to get pending outgoing commands. In modeling a client, the server gateway 266 initiates request on behave of the user account for the outgoing commands.
  • the protocol adapter 268 performs a get-commands call to the store and forward logic 210 , which returns with a payload of commands.
  • the payload of commands may include adding a new email DDD, deleting a contact EEE, and modifying a title of multimedia content FFF.
  • the protocol adapter 268 may assign an index to each command and includes the commands in a RESPONSE to the previously received REQUEST.
  • the server gateway 266 then models a client and initiates a REQUEST to put commands to the user account 320 .
  • the user account 320 acknowledges receipt of the REQUEST and commands with a RESPONSE.
  • the server gateway 266 then initiates a REQUEST to acknowledge receipt of the commands by the user account 320 .
  • the protocol adapter converts the acknowledgement into a remove commands call to the store and forward logic 210 to remove commands from the in-transits queue.
  • the store and forward logic 210 returns a success, and the protocol adapter 268 acknowledges the RESPONSE received from the server gateway 266 with a RESPONSE.
  • FIG. 16C shows a sequence of events when a server gateway 266 pushes a command in a notification message to a user account 320 .
  • the store and forward logic 210 may include a low priority and/or relatively small payload with a notification.
  • the fact that an email has been read may be considered a low priority and small byte sized event.
  • Such low priority events may be communicated with the notification layer without the necessity of receiving an acknowledgement typically required in a REQUEST-RESPONSE exchange.
  • the notification signal includes a content type.
  • the server gateway 266 may model a client when sending a REQUEST to get pending outgoing commands.
  • the protocol adapter 268 performs a get-commands call to the store and forward logic 210 , which returns with a command.
  • the command GGG may include an instruction to modifying a read state of an email.
  • the protocol adapter 268 may assign an index to the command and includes the command in a RESPONSE to the previously received REQUEST.
  • the server gateway 266 then pushes the command in a notification signal to the user account 320 . Either before or after sending of the notification signal, the server gateway 266 may initiates a REQUEST to acknowledge receipt of the commands by the user account 320 .
  • the protocol adapter converts the acknowledgement into a remove command call to the store and forward logic 210 to remove the command from the in-transits queue.
  • the store and forward logic 210 returns a success, and the protocol adapter 268 acknowledges the RESPONSE received from the server gateway 266 with a RESPONSE.
  • FIG. 16D shows an embodiment of the present invention with a server gateway 266 positioned behind a firewall along with an account server having a user account 320 . If the server gateway 266 is behind a firewall, the protocol adapter 268 may be unable to initiate a REQUEST-RESPONSE exchange and a notification from the protocol adapter 268 would be blocked. In this case, the server gateway 266 may initiate each REQUEST-RESPONSE exchange.
  • the server gateway 266 may request the notification information by initiating a REQUEST-RESPONSE exchange.
  • the server gateway 266 may periodically poll for commands in the outgoing queue 241 by sending the protocol adapter 268 a REQUEST indicating a poll for outgoing commands is requested.
  • the protocol adapter 268 calls the store and forward logic 210 to check for any outgoing commands for the user account 320 .
  • the store and forward logic 210 returns an indication of whether or not any commands exist in the outgoing queue 241 .
  • the protocol adapter 268 may respond to the previous REQUEST with a RESPONSE including the returned indication of whether or not any commands exist in the outgoing queue 241 .
  • the server gateway 266 may initiate a REQUEST to get the outgoing commands as shown in FIG. 16B (with a REQUEST-RESPONSE exchange) or as shown in FIG. 16C (within a notification signal). Additionally, the server gateway 266 may poll the user account 320 for changes if the user account 320 communicates commands to the server gateway 266 , the server gateway 266 may initiate a REQUEST to put the commands to the incoming queue 231 as shown in FIG. 15A .
  • the invention can be implemented in any suitable form including hardware, software, firmware or any combination of these. Different aspects of the invention may be implemented at least partly as computer software or firmware running on one or more data processors and/or digital signal processors.
  • the invention may be implemented in a computer program product such as a machine readable medium (e.g., a memory card, ROM, RAM, PROM, EPROM, flash memory, magnetic or optical diskette, CD-ROM, DVD, and the like).
  • a machine readable medium e.g., a memory card, ROM, RAM, PROM, EPROM, flash memory, magnetic or optical diskette, CD-ROM, DVD, and the like.
  • the elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. As such, the invention may be implemented in a single unit or may be physically and functionally distributed between different units and processors.

Abstract

A method, apparatus, and system for routing changes to information between a plurality of content nodes and a command memory of a content router. Content nodes may be user devices (such as mobile phones) and user accounts (such as email accounts). Content nodes may hold one or more content types such as email, contacts, tasks, events and library items. A command memory centralizes conflict detection, resolution and error handling within a content routing system.

Description

    CROSS-REFERENCE TO RELATED APPLICATION
  • This application is a continuation-in-part of and claims benefit to previously filed U.S. patent application Ser. No. 11/182,287, filed Jul. 14, 2005, entitled CONTENT ROUTER, to Torsten SCHULZ et al., and is hereby incorporated by reference as if fully set forth herein. This application is further related to co-filed U.S. patent application Ser. No. ______(Attorney Docket No. 324212011000), filed Oct. 31, 2005, entitled CONTENT ROUTER CORE VARIANTS, to B. Ebbesen et al., and is hereby incorporated by reference as if fully set forth herein.
  • BACKGROUND
  • 1. Field
  • The present invention relates generally to maintaining user devices and accounts, and more particularly to synchronizing information accessible from multiple devices and networked accounts.
  • 2. Description of Related Art
  • Known routers and synchronization systems do not analyze the payload data received from one node to determine whether or not to forward all or part of the data to a second node. For example, a router uses an address it receives and a routing table to determine which destination nodes will receive a copy of the incoming packet. Known routers determine routing based on the address of packet. Additionally, known routers do not contain long term memory to hold packets. Thus, a packet will not be received by the second node unless the first node sends the packet to the router while the second node is also connected to the router.
  • A synchronization system holds a master copy of a set of records it is mirroring on one or more handheld devices. After a change occurs on one device and that device forwards a changed recorded to the synchronization system, the synchronization system updates its master copy, which is then available to other devices when they synchronize to the system. Known synchronization systems must keep a master copy of all synchronized records. For example, a hand held organizer may operate with a synchronization tool on a PC. Both the organizer and PC maintain a master copy of all records. Thus, a master copy may be maintained at multiple locations. Additionally, if a synchronization system is to work with devices not simultaneously connected to the synchronization system, the synchronization system will need to keep a copy of each new record. If a record represents an audio file or an image file, the synchronization system may need a substantial amount of storage.
  • Hence, an improved system for synchronizing destinations of content would be advantageous and in particular a system allowing increased flexibility, reduced complexity and/or improved performance would also be advantageous.
  • BRIEF SUMMARY
  • In accordance with one aspect of the invention, there is provided a content routing system for routing changes to information between a plurality of content nodes and a command memory, the content routing system comprising: store and forward logic including: processing logic for: processing an incoming command from a first content node; selecting a set of destination content nodes based on a content type of the incoming command and one or more routing parameters; and generating an outgoing command for each of the selected destination content nodes; and command memory, coupled to the processing logic, for holding the incoming command and the set of outgoing commands; and a connected data set configuration, coupled to the processing logic, for holding the one or more routing parameters.
  • Some embodiments include a gateway for translating between the first protocol and a common protocol; and a protocol adapter for translating between the common protocol to the command protocol. Some embodiments include a command memory having an incoming queue for holding the incoming command and an outgoing queue for holding the set of outgoing commands. Some embodiments include a database for holding the incoming command and the set of outgoing commands, wherein each command has an attribute identifying a state of the command. Some embodiments include an outgoing in-transit queue state. Some embodiments include an incoming in-transit queue state.
  • In accordance with another aspect of the invention, there is provided a content routing system comprising: store and forward logic including logic for selecting destination content nodes based on a content type of an incoming command and one or more routing parameters; modifying the incoming command to generate at least one outgoing command, wherein each outgoing command corresponds to a selected content node; and a connected data set configuration for holding the one or more routing parameters.
  • In some examples the data modulation logic may further include at least one data module operable to modify a data field of the incoming command data structure. The incoming command may include an XML-tree data structure schema, for example, and the data modulation logic may modify a particular node of the XML-tree data structure. In some examples, the data modulation logic may operate to divide a first incoming command associated with a first a content entry into multiple outgoing commands associated with second multiple content entries. Additionally, the data modulation logic may operate to merge multiple first incoming commands associated with first content entries into a relatively smaller number of second commands associated with second content entries.
  • In some examples, the content routing system may further include data consolidation logic operable to identify potential duplicate content entries within a connected community of content nodes based on comparing a hash-value of the incoming command to a list of hash-values. In one example, the hash-value is determined from less than all of the incoming command or content, e.g., a predefined significant property of the content entry.
  • In accordance with another aspect of the invention, there is provided a method of routing changes to information between a plurality of content nodes and a command memory, the method including receiving an incoming command from a first content node; storing the incoming command in a command memory associated with the first content node; selecting a set of destination content nodes based on a content type of the incoming command and a routing parameter associated with the destination content node and the content type; and modulating the incoming command based on capabilities of the destination content node, wherein the modulating comprises targeting a specific field of the incoming command data structure with a data module operable to modify the data structure for generation of an outgoing command.
  • In accordance with another aspect of the invention, there is provided a computer program product comprising program code for use in a content routing system including processing logic and a command memory, the content routing system for routing changes to information between a plurality of content nodes and the command memory, the computer program product comprising program code for receiving an incoming command from a first content node; program code for selecting a set of destination content nodes based on a content type of the incoming command and a routing parameter associated with the destination content node and the content type; program code for modulating the incoming command based on capabilities of the destination content node, wherein the program code for modulating comprises data modulation logic operable to modify the data structure of the incoming command for generation of an outgoing command; and program code for generating the outgoing command.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • Various aspects and examples will be described, by way of example only, with reference to the drawings, in which:
  • FIGS. 1A and 1B show information distribution and synchronization systems.
  • FIG. 2 illustrates a content router coupled to multiple content nodes via a network according to embodiments of the present invention.
  • FIG. 3 shows a path of propagating a change in one content node to a selected set of content nodes via a content router according to embodiments of the present invention.
  • FIG. 4 shows a user's connected email accounts and includes an example screenshot according to embodiments of the present invention.
  • FIGS. 5 and 6 illustrate the connections to and processing performed by store and forward logic according to embodiments of the present invention.
  • FIGS. 7A and 7B illustrate store and forward logic coupled to a repository according to embodiments of the present invention.
  • FIGS. 8A and 8B illustrate a process of stripping a separable segment of an exemplary email then requesting the stripped segment from a source of the email according to embodiments of the present invention.
  • FIGS. 9A to 9F illustrate various exemplary structures of store and forward logic and data paths between processing logic and content nodes according to embodiments of the present invention.
  • FIGS. 10A to 10D show a PUT-GET-ACK procedure from a point of view a content node and a content router according to embodiments of the present invention.
  • FIG. 11 illustrates representation of a structure of a connected data set configuration according to embodiments of the present invention.
  • FIGS. 12A to 12E illustrate external and internal logic, which may be used to interface a content router to user devices and user accounts according to embodiments of the present invention.
  • FIGS. 13 and 14A to 14I show structures of various commands according to embodiments of the present invention.
  • FIGS. 15A to 15C illustrate sequence diagrams showing signaling between a user device and store and forward logic according to embodiments of the present invention.
  • FIGS. 16A to 16D illustrate sequence diagrams showing signaling between a user account and store and forward logic according to embodiments of the present invention.
  • FIGS. 17A-17C illustrate exemplary instructions according to one aspect of the present invention.
  • FIGS. 18A-18E illustrate exemplary data structures according to several aspects of the present invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • In the following description, reference is made to the accompanying drawings which illustrate several embodiments of the present invention. It is understood that other embodiments may be utilized and mechanical, compositional, structural, electrical, and operational changes may be made without departing from the spirit and scope of the present disclosure. The following detailed description is not to be taken in a limiting sense, and the scope of the embodiments of the present invention is defined only by the claims of the issued patent.
  • Some portions of the detailed description which follows are presented in terms of procedures, steps, logic blocks, processing, and other symbolic representations of operations on data bits that can be performed on computer memory. A procedure, computer executed step, logic block, process, etc., are here conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those utilizing physical manipulations of physical quantities. These quantities can take the form of electrical, magnetic, or radio signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. These signals may be referred to at times as bits, values, elements, symbols, characters, terms, numbers, or the like. Each step may be performed by hardware, software, firmware, or combinations thereof.
  • FIG. 1A shows a routing system. A router 100 includes a routing module 101 and a routing table 102 used to route packets 120. The router 100 uses both address information appended to the packet 120 and the routing table 102 to determine which data sinks 140-1 to 140-3 will receive a forwarded copy of an incoming packet 120. The router 100 forwards the packet 120 as packets 130-1 to 130-3. Known routers do not determine routing based on the type of content included in an incoming packet 120, but rather based on the address information appended to the packet 120.
  • FIG. 1B shows a synchronization system including a PC 150 and multiple data holders 160. A data holder 160 may be a hand held organizer connected to the PC 150 via a cradle. A user may change information, such as entering a new contact, into a first data holder 160-1. Periodically, the user connects the data holder 160 to the PC 150 and synchronizes each data holder 160 using a CPU 151 of the PC 150. The first data holder 160-1 exchanges data 170-1 with the CPU 151. The CPU 151 saves any updated and new information as data 171. The PC 150 accumulates a persistent copy 152 of data 171 synchronized through it. When a second data holder 160-2 synchronizes with the PC 150, the CPU 151 updates the second data holder 160-2 with the information saved from the first data holder 160-1. Even after both data holders 160-1 and 160-2 have been synchronized, the synchronization system preserves a copy of the changed information as persistent copy 152 even though the changed information is no longer needed for synchronization. Known synchronization systems keep a complete persistent copy 152 of data synchronized through the synchronization system.
  • FIG. 2 illustrates a content router 200 coupled to multiple content nodes 300-1 to 300-3 via a network 10 according to embodiments of the present invention. The content router 200 facilitates synchronization of similar and dissimilar content nodes 300-1 to 300-3 attachable to the network 10. The content router 200 may be a single network component implemented in hardware and/or software. Alternatively, the content router 200 may be a system of networked components. The content router 200 uses commands 400-1 to 400-3 sent across the network 10 to communicate information. The network 10 connects each content node 300-1 to 300-3 with the content router 200 using commands 400. The network 10 may be a conglomeration of disparate wired and/or wireless network such as interconnected intranets, the Internet and mobile radio networks. Alternatively, the network 10 may be a single network. Additionally, the content router 200 may bridge two or more separate networks.
  • A command 400-1 may be communicated within a message from a content node 300-1. The message may be encoded as a sequence of bits using a protocol available to the content node 300-1. A message may contain a segment of a command, in which case multiple messages may be aggregated to form a complete command. Alternatively, a message may contain multiple commands. In some protocols used by a content node 300, one or more messages may represent one or more commands. The content router 200 may translate between the message protocol used by a content node 300 and a command structure or protocol used internally in the content router 200.
  • From a content node 300, a user may use commands to enter, store, access, update, modify, and/or delete content or metadata (i.e., information about content). Content may have one of various content types, such as contacts, calendar events, tasks, emails and/or library items. Furthermore, content may have a personal information management (PIM) content type, which may include a contact, calendar event or a task. A library item includes a media object such as a photo image, an audio file, a video clip, a movie or a document, or may be a group of such items such as album of photos or collection of home movies. Metadata includes information about such content.
  • A content node 300 may be a user's account on a server. Such a content node 300 may have access to content of a single content type. For example, a user account may be a personal email account on an email server (e.g., Yahoo!® Mail), a family photo album account on a photo server (e.g., Yahoo!® Photos), a PIM account on a PIM server (e.g., Yahoo!® Address book or Yahoo!® Notepad), or a music library account on a multimedia library server (e.g., Yahoo!® Music). Furthermore, a content node 300 may be a user account having access to two or more content types. For example, a user account may have access to email, PIM information, calendar information and a notepad, such as with a Yahoo!® user account.
  • A content node 300 may be a user device. Such a user device may be a wired device, such as a home personal computer, an office PC, a digital camera or a set-top box, or may be a wireless device, such as a mobile phone, a laptop, handheld PC, or a digital camera with wireless capabilities. Some devices may have both wired and wireless capabilities, while other devices may have either wired or wireless capabilities. Some user devices may have access to a single content type. Other user devices have access to two or more content types.
  • A content node 300 may be a user device that organizes information, including PIM devices such as a Blackberry® or a Treo®, or more dedicated mobile phones that provide more limited information management services. Information management services may include, for example, PIM services such as calendar, address book, tasks, and notes. A calendar typically maintains time-related organizational attributes such as events (e.g., meetings, birthdays, holidays) related to corresponding date and time ranges. An address book typically maintains organizational attributes related to a person (e.g., a legal “person” such as a human or business entity, or even a pet), a place (e.g., the person's address), or other contact information attributes (e.g., telephone numbers).
  • FIG. 3 shows a path of propagating a change in one content node 300-1 to a selected set of content nodes 300 via a content router 200 according to embodiments of the present invention. A set of content nodes 300 may include a null set of content nodes, a single content node, a subset of one or more content nodes, or all content nodes. A content node 300 may act as a source of data (data source), a sink of data (data sink), or a combination of both. In this case, content node 300-1 acts as a data source while content nodes 300-2, 300-3, 300-6 and 300-8 act as data sinks. A change to a content node 300-1 may represent one of a number of events including an addition, modification or deletion of content or metadata.
  • As shown, content node 300-1 acts as a source of content or metadata. The content node 300-1 may generate a command 400-1 including changed content, or a metadata indication of the change to content, which may be communicated to the content router 200. The content node 300-1 may push the command 400-1 to the content router 200 or it may be polled by the content router 200 for the command 400-1.
  • The content router 200 examines the contents of the command 400-1. Based on the contents of an incoming command 400-1, the content router 200 selects which of the possible content nodes 300-2 to 300-8 will be informed of the change. In this example, the content router 200 selects content nodes 300-2, 300-3, 300-6 and 300-8, then transforms the incoming command 400-1 into outgoing commands 400-2, 400-3, 400-6 and 400-8 to distribute an indication of the change. The outgoing commands 400-2, 400-3, 400-6 and 400-8 may or may not include the same contents as the incoming command 400-1. Additionally, the content router 200 does not keep a persistent copy of all content synchronized through it.
  • A content node 300-1 may be a user device (such as a PIM device) or a user account (such as a Yahoo! account) that contains one or more databases of content and/or metadata. For example, if the content node 300-1 includes an address book, the change may be a new, modified, or deleted contact. If the content node 300-1 includes a calendar, the change may be a new, modified, or deleted event, such as an appointment. If the content node 300-1 includes a task list, the change may be a new, modified, or deleted task. Similarly, if the content node 300-1 includes a note pad, the change may be a new, modified, or deleted note. The change may also be an addition, modification or deletion of a collection of information, such as a list of watched stocks, a list of bookmarked web pages, or a configuration of a home page.
  • If the content node 300-1 is an email account, the change may be that the email account has received new content, such as an incoming email message from the Internet, or has deleted content, such as deleting an existing email. The user may have updated metadata, such as changing a message state from unread to read, marking a message as unread, or setting an importance level. Similarly, if the content node 300-1 is a mobile phone, the change may be that it received new content, such as a new pager message or a new SMS message from a wireless network, or that the user has deleted content, such as deleting a message.
  • Furthermore, if the content node 300-1 is a media library, the change may indicate that a user has added, modified or deleted a media object, such as a photo image, an audio file, a video clip, a movie or a document, or may be a group of such items such as an album of photos or collection of home movies. For example, the change may indicate that a user has added a caption to a photo image, or has loaded a new song. Media objects are further described in related U.S. application Ser. No. 11/129,697, filed on May 13, 2005 and titled MEDIA OBJECT ORGANIZATION ACROSS INFORMATION MANAGEMENT SERVICES by inventors Marco BOERRIES et al., and incorporated by reference herein.
  • In describing a change, a content node 300-1 may send the actual new or modified content. In some embodiments, a content node 300-1 may instead send metadata. Such metadata may include characteristics of the changed content, a transformed copy of the changed content, and/or a reference, such as hyperlink or address pointer, to the content in memory. Sending a reference instead of the actual content allows a receiving content node 300-2 to access content from a sending content node 300-1 without requiring the content itself to pass through the content router 200.
  • A content router 200 may facilitate routing email among several email-capable content nodes 300, such as a user device or a user account. Email received at a user's first email account, e.g., a personal email account, may be forwarded via the content router 200 to the user's second account, e.g., a work email account on a second content node. Similarly, email received at the user's second email account may be forwarded through the content router 200 to the user's first email account. The user may also add a third email account, e.g., a Yahoo!® email account, and configure the content router 200 to route email messages received from the Internet at the third account to the first and second accounts.
  • FIG. 4 shows a user's connected email accounts 320-1 to 320-3, and includes an example screenshot 20 according to embodiments of the present invention. Some content nodes 320, such as an Outlook account, allow a user to set up multiple email boxes or folders. Shown are two email accounts 320-1 and 320-2 with a connected inbox and one email account 320-3 without a connected inbox. Connected email accounts may report information to the content router 200 and may receive information from the content router 200.
  • For example, a content node (320-1, 320-2 or 320-3) may report a new incoming email to the content router 200 in a command (31, 32 or 33, respectively). In response to each incoming command (31, 32 or 33), the content router 200 selects a set of destination content node (e.g., 320-1 and 320-2, respectively) and forms an outgoing command (34 and 35) destined for an inbox of each selected content node (320-1 and 320-2, respectively).
  • The screenshot 20 from a user's personal email account 320-1 shows an inbox 21 for holding email messages received directly from the Internet without passing through the content router 200, and a connected inbox 22 for holding email messages received from the content router 200. The connected inbox 22 contains emails merged from each of the user's connected email accounts 320-1 to 320-3. By viewing the connected inbox 22, a user may quickly see in one folder all email destined for the user's multiple connected email accounts. A connected inbox 22 may thus be viewed as a window to all emails sent to a user across the user's several connected email accounts.
  • A user may also configure an email account to include a separate folder or inbox for each content node 300 that has email capabilities. Here, the screenshot 20 shows an inbox 23 for emails from a personal email content node 320-1, an inbox 24 for email from a work email content node 320-2, and an inbox 25 for email from a Yahoo!g email content node 320-3. Using separate folders allows a user to manage individual email accounts from one content node, for example, user account 320-1.
  • FIGS. 5 and 6 illustrate connections with and processing performed by store and forward logic 210 according to embodiments of the present invention. The store and forward logic 210 allows multiple connected content nodes 300 to communicate changes to information on one content node 300 to other content nodes 300 through the content router 200 without requiring each content node 300 to be simultaneously coupled to the content router 200. The store and forward logic 210 may be decoupled from content node specifics. That is, the store and forward logic 210 may treat each content node similarly, regardless of whether a content node is a user device or a user account, or whether the content node operates as a client or as a server. Additionally, the store and forward logic 210 may move the task of conflict detection away from the content nodes and centralize the task of conflict detection and resolution to within the store and forward logic 210.
  • The store and forward logic 210 may be implemented in hardware, executable code or a combination of both. The store and forward logic 210 may include VLSI and/or FPGA hardware. The store and forward logic 210 may include a stand alone server or a network of servers. The store and forward logic 210 may be implemented with a general purpose central processing unit (CPU) or may be implemented with a reduced instruction set computer (RISC). The store and forward logic 210 may include on-chip or off-chip memory such as RAM, PROM, EPROM, E2PROM and/or the like. The store and forward logic 210 may also include magnetic memory, such as a hard disk drive, and may include optical memory. The executable code may be derived from scripts, software, firmware and/or machine code.
  • The content router 200 of FIG. 5 includes store and forward logic 210 coupled to a connected data set configuration 500, and a repository 600. The store and forward logic 210 may be coupled to associated content nodes 300-1 to 300-4. FIG. 6 shows a sequence of events triggered in the store and forward logic 210 by an incoming command beginning at 1000. Those actions include processing an incoming command at 1001, selecting outgoing content nodes at 1002, generating outgoing commands at 1003, processing outgoing commands at 1004, and sending the processed outgoing commands at 1005. Whether a command is an incoming or outgoing is viewed from the perspective of the store and forward logic 210.
  • At 1000, the sequence of events begins when a content node 300-1, having a change to report, sends a new command 400-1 to the store and forward logic 210. A content node 300-1 does not send the change (such as a command to add an included new email message) to other content nodes. Rather, the content node 300-1 sends the change to the store and forward logic 210, which may or may not create a set of outgoing command to send the new email message or parts of the new email message to a corresponding set of content nodes.
  • At 1001, the store and forward logic 210 processes the incoming command 400-1 from the content node 300-1. Processing incoming commands 400-1 may include transforming commands based on limitations or specialized capabilities of the originating content node 300-1. When transforming commands, the store and forward logic 210 may use the repository 600, which may hold one or more separable segments of a command, and the connected data set configuration 500, which contains transforming rules used when processing a command. Transforming incoming and outgoing commands is further described with reference to FIGS. 7A, 7B, 8A and 8B.
  • Processing an incoming command 400-1 may also include detection and resolution of a conflict between the incoming command 400-1 and a command pending in the store and forward logic 210. The store and forward logic 210 may hold multiple pending commands in memory waiting to be acted upon. A pending command may be a previously received and processed incoming command from a particular content node 300 that is waiting for further processing by the store and forward logic 210. Additionally, a pending command may be a command generated by the store and forward logic 210 in response to an incoming command. These generated commands are waiting to be transmitted to a particular content node 300 as an outgoing command (e.g., 400-2 or 400-4).
  • Conflict resolution may include discarding the new command 400-1, deleting a pending command, and/or aggregating of the new command 400-1 with a pending command. A conflict may arise if a new incoming command 400-1 conflicts with a previously received incoming command pending execution. For example, a previously received incoming command may be a command to add a new email received from the Internet by the content node 300-1. A subsequent incoming command may be to delete that same email, for example, if a user has deleted the email from its inbox on content node 300-1. If the command to add the new email is still pending in the store and forward logic 210 when the subsequent command to delete the same email is received, a conflict exists. In this case, the conflict is resolved by discarding both commands. Alternatively, if the subsequent incoming command was instead to add the same new email, the store and forward logic 210 detects the duplicate commands and resolves the conflict by discarding one of the duplicate commands.
  • A conflict may also arise if a new incoming command 400-1 conflicts with a command previously generated as an outgoing command for a particular content node 300. For example, the store and forward logic 210 may hold a pending outgoing command to update a contact in an address book. A new incoming command may be to delete that same contact altogether. The store and forward logic 210 detects and resolves this conflict by removing the pending outgoing command (update-contact) and saving the new incoming command (delete-contact). The new incoming command will eventually be processed and the delete-contact action will be propagated as an outgoing command to other connected content nodes 300.
  • The store and forward logic 210 may also aggregate an incoming command 400-1 with a pending command for a content node 300. For example, a previously received incoming command 400-1 may be to add a new task to a task list. A subsequent incoming command 400-1 may be to modify this task in some way. The store and forward logic 210 detects and resolves this conflict by incorporating the modifications from the subsequent incoming command (modify task) into the previous incoming command (add-task). The resulting aggregated command may be an add of the modified task. The resulting aggregated command may replace the previous incoming command. Alternatively, the previous incoming command may be discarded and the resulting aggregated command may be saved as a new incoming command. Detection and resolution of conflicts are further described with reference to FIGS. 9A-9C and 10A-10D.
  • At 1002, the store and forward logic 210 selects a set of outgoing content nodes, here content nodes 300-2 and 300-4. When selecting outgoing content nodes, the store and forward logic 210 may again use the connected data set configuration 500, which also contains routing parameters used in routing rules. Routing rules and the connected data set configuration 500 are further described with reference to FIG. 11.
  • At 1003, the store and forward logic 210 generates an outgoing command 400-2 and 400-4 for each selected content node 300-2 and 300-4, respectively. Depending on capabilities and a configuration of the selected content node, the store and forward logic 210 may alter the processed incoming command to suit the limitations or requirements of the selected destination content node. For example, depending upon limitations of a destination content node, the store and forward logic 210 may use a repository 600 to hold a separable segment of an incoming command 400-1 and either modify or eliminate that segment from the outgoing command. Conversely, the content router 200 may insert additional segments of information into an outgoing command.
  • The content router 200 may alter a command based on user defined rules, system defined rules, or known content node limitations. The content router 200 may modify a command based on information found within the incoming command 400-1. The content router 200 may append metadata, such as location, time or other information accessible from a user's account or device, to the outgoing command. The content router 200 may hold a record of how a command is modified so that it may reverse the modification if a related command is returned. In some cases, the content router 200 passes a command through without modification.
  • At 1004, the store and forward logic 210 processes the outgoing commands. As with incoming commands at 1001, the store and forward logic 210 similarly performs conflict detection and resolution between a new outgoing command and pending incoming and outgoing commands.
  • At 1005, the store and forward logic 210 sends the outgoing commands 400 to the respective content nodes 300. Sending an outgoing command 400 may include signalling a notification to the content node 300. Unlike a request (in a request-response protocol), a notification is a signal where a sender does not expect a response or an acknowledgement that the notification was received. In this respect, a notification is self contained in that it is complete once sent. Additionally, a notification may be implemented in software (e.g., a semaphore, flag or software signal instruction) and/or hardware (e.g., a hardware line or a register). The notification may include a content type of the outgoing command 400. If the content node is connected to the network 10 with an IP address, the store and forward logic 210 may send an HTTP command to notify the content node that an outgoing command is pending. If the content node is a mobile phone having SMS capabilities, the store and forward logic 210 may send a notification via an SMS message.
  • A content node 300-1 may send content having one or more segments in a command 400-1. To minimize the amount of data flowing out of the content router 200, the store and forward logic 210 may replace one or more segments of a command with a corresponding one or more references that provide a link back to the original content rather than forwarding the original segments themselves. Alternatively, the content node 300-1 may include one or more references to a source of the content rather than including the content itself.
  • A content node 300-4 receiving the reference to content (e.g., a reference to a new photo residing on content node 300-1) may instigate a peer-to-peer transfer 450 to retrieve the content from content node 300-1. In this manner, the content router 200 may facilitate a transfer of content between two content nodes in the form of a peer-to-peer transfer 450 while both content nodes are simultaneously connected to the network 10.
  • Due to limitations or requirements of a content node, the store and forward logic 210 may adapt the command by modifying, replacing or eliminating a separable segment of the command before sending it to a content node. For example, some content nodes may be unable to process, use or store some segments of a command. In some embodiments, the store and forward logic 210 may accommodate these content nodes that have limited capabilities using one of three methods described below, some of which use a repository. The store and forward logic 210 may also uses these methods for other reasons, such as memory limitations in a content node or bandwidth restrictions between the store and forward logic 210 and the content node, even though the content node is capable of handling the entire incoming command.
  • In some cases, the content router 200 is configured to poll a content node 300 for new commands. A content router 200 may periodically poll a content node 300 to determine whether any changes have occurred. The period of polling may be based on the type or expected cost of a connection to the network. For example, if a content node 300 is a mobile phone connected to the network via an SMS connection, polling may take place every 24 hours. If the mobile phone connected to the network via a GPRS data network connection, polling may occur every 20 minutes. If the mobile phone is placed in a docking station with a wired connection to the Internet, polling may occur every few seconds to every few minutes.
  • In some cases, notifications from the store and forward logic 210 to a content node 300 may be blocked because the content node 300 is behind a firewall. To receive commands, the content node 300 may be configured to poll the content router 200. When the content node 300 polls for pending outgoing commands 400, the store and forward logic 210 may reply with one command or a batch of commands for the content node 300 to process. The structure of commands 400 is further described with reference to FIGS. 13 and 14A-14I. The notification and exchange of commands between the store and forward logic 210 is further described with reference to FIGS. 15A-15C and 16A-16D.
  • According to a first method, the store and forward logic 210 may accommodate a limited capability content node by stripping incompatible or undesired segments from the payload and save the stripped segments in a repository 600. Thus, the repository 600 may hold segments of commands, which will be available for future use. If those segments are later needed, the store and forward logic 210 may access them from the repository 600. This method is described below with reference to FIGS. 7A and 7B.
  • FIGS. 7A and 7B illustrate store and forward logic 210 coupled to a repository 600 according to embodiments of the present invention. Due to limitations or requirements of a content node 300, the store and forward logic 210 may adapt the command by eliminating a segment of the command before sending it to the content node 300. Before adapting the command, the store and forward logic 210 may preserve a copy of the unmodified segment or the entire command in the repository 600. Thus, the repository 600 may hold one or more segments of commands, which will be available for future use. In accordance with other embodiments, a segment may also be available to remove segments, such as a file in an email, from a command. For example, a file may be removed for an incoming command as described below with reference to FIG. 8A. Alternatively, a file may be removed for an incoming command as described below with reference to a file relay server and FIG. 12E.
  • FIG. 7A shows store and forward logic 210 using a repository 600 to hold a separable segment of an incoming command 400-1 from a first content node 300-1. When commands contain content that is separable and distinct, the separable content may be parsed away from the command or piecewise modified. For example, a contact may include a full name (first segment 401), a home phone number (second segment 402) and a work phone number (third segment 403). Each of these segments may be separable and distinct. That is, one or more of these segments may be removed and/or modified and/or combined, thereby forming a modified command. For example, if a particular content node, such as a mobile phone, has a limitation that it can only handle a single phone number, the store and forward logic 210 may remove the work phone number (third) from an incoming command when preparing the corresponding outgoing command. The store and forward logic 210 may also place the work phone number in a repository 600 for future use.
  • As another example, an incoming command may include content such as a new email message having an email body and an attached file. The attached file is separable and distinct from the email body. The store and forward logic 210 may generate an outgoing command 400-2 to add the new email to a second content node 300-2. The outgoing command 400-2 to the second content node 300-2 may include the email body but only a reference to the file.
  • As shown, an incoming command 400-1 is forwarded in part as an abridged outgoing command 400-2 to a second content node 300-2. The incoming command 400-1 includes an exemplary payload 441 containing three segments of content and/or metadata 401, 402 and 403. The store and forward logic 210 stores a copy of the third segment 403 in the repository 600 and also prepares an outgoing command 400-2 with a payload 451 containing the first segment 401 and the second segment 402, but leaving off the third segment 403. The content router 200 may leave off the third segment 403, for example, due to a limitation of the destination content node 300-2. Such a limitation may include the content node 300-2 having a limited amount of allocated storage capacity, or a general transforming rule that removes all attachments that are in a predetermined format.
  • As another example, a user may add a new contact to a content node 300-1. The content node 300-1 sends an add contact command 440 containing a payload 441, which represents the contact created at the content node 300-1. The payload 441 may contain three segments 401 to 403 of information. The first segment 401 may be a structure holding a first and last name. The second segment 402 may be a phone number. The third segment 403 may be a hyperlink to a webpage. If a destination content node 300-2 is incapable of receiving a hyperlink, then the store and forward logic 210 may strip off the third segment 403 containing the hyperlink. Therefore, the payload 451 sent from the store and forward logic 210 may be different from the payload 441 received by the store and forward logic 210. The store and forward logic 210 stores the third segment 403 in the repository 600 for possible future use. For example, the store and forward logic 210 may access the repository 600 after a user changes a segment of the payload 451 and before the store and forward logic 210 forwards the change to the first content node 300-1, as discussed below.
  • FIG. 7B shows store and forward logic 210 accessing segments from the repository 600 in response to an incoming command 400-2A, which contains the original first segment 401 and the updated second segment 402A, from the second content node 300-2. The second segment 402 may have been updated as the result of a user modifying the segment, such as an email attachment, at content node 300-2. When the store and forward logic 210 processes the incoming command 400-2A from content node 300-2, it determines whether any segments previously associated with payload 451 and now associated with payload 451A are held in the repository 600. The store and forward logic 210 determines that the third segment 403 was previously associated with payload 451, and merges the third segment 403 from the repository 600 with the payload 451A containing the original first segment 401 and an updated second segment 402A to create a full data structure. If content node 300-1 is configured to process the content held in each segment 401 to 403, the store and forward logic 210 prepares a payload 441A containing the first segment 401, the updated second segment 402A, and the reattached third segment 403.
  • According to a second method, the store and forward logic 210 may accommodate a limited capability content node 300-2 by modifying an incompatible or undesired segment from the payload 441. The store and forward logic 210 may save this segment in the repository 600 if it may be needed in the future. This second method is similar to the first method except that, in the second method, the segment stripped in the first method is instead modified and sent to the content node. If in the future, the limited capability content node returns the modified segment in a command, the store and forward logic 210 may replace this returned segment with the original segment from the repository 600 before the store and forward logic 210 forwards the command to other content nodes.
  • For example, if a command 400-1 arrives from the first content node 300-1 including a first name string and a second name string, but the second content node 300-2 is only able to handle a single-string name, the store and forward logic 210 may replace the two string structure with a single string structure containing a concatenated first and last name in the single string structure. The store and forward logic 210 may store the structure including the first name string and the second name string in the repository 600. If that content is later sent (either in a modified or unmodified form) from the second content node 300-2 and a destination content node can handle two-string names, the store and forward logic 210 may replace the concatenated string in the incoming command from the second content node 300-2 with the copy of the two string structure from the repository 600. In this way, missing content from one limited-ability content node 300-2 may be restored before it is forwarded to other content nodes.
  • Instead of using the repository 600 to preserve an original segment of content that was stripped or modified, store and forward logic 210 may retrieve the original segment from its source content node or from storage referenced by the source content node.
  • In one example, the content router 200 includes a data modulation component operable to manipulate or modify content and/or metadata of a payload, e.g., segments 401, 402, 403 as shown and described with respect to FIGS. 7A and 7B. The data modulation component may include logic within store and forward logic 210 of the content router 200 (see, e.g., FIG. 5). The data modulation component may comprise data modulation logic including one or more data modules operable to target data within a data structure of the payload (e.g., which may be structured as an eXtensible Markup Language (XML)-tree data structure schema) and perform actions on portions of the data (e.g., modifying/deleting one or more segments 401, 402, 403) to carry out various functions described herein. In one example, multiple data modules for targeting and acting on data within the data structure of the payloads are configured to carry out various modulations for routing to one or more content nodes, e.g., 300-1, 300-2, and so on.
  • In one illustrative example, payloads (e.g., 441A, 451A) associated with incoming and outgoing commands are structured as XML data structures. XML data structures are well known in the art and generally comprise data tree structures, wherein a sub-tree and/or single data value may be targeted for action. Various data modules may be implemented to act on specific data values or fields of the data as it is routed through the system, e.g., through the content router 200. For example, the processing logic 250 may include one or more data modules operable alone or in combination to modify certain content or metadata for specific content nodes or devices. An illustrative example includes a data module operable to modify content/metadata for a PIM device or other device having different or reduced capabilities relative to other content nodes (300-1, 300-2, etc.), such as a user account. One or more data modulation components may be used by the content router 200 to adapt and route content to various content nodes having disparate capabilities.
  • The data modulation component may include one or more data modules, each having a path and target within the XML-tree structure of the payload (i.e., including content and/or metadata). Multiple data modules may be combined to carry out various actions on one or more segments of the payload as they are routed to different content nodes. For example, a contact entry may include an address including separate data values for street address, city, and country. A first module may be operable to remove or delete the country information from the contact entry and a second module may be operable to modify the street address to a maximum of 20 characters. The modulation may be performed to “fit” the content and metadata to a particular content node, e.g., a mobile device or the like. Thus, a data change (e.g., a command) sent from content router 200 to a content node (e.g., a device) is modified by the processing logic 250 to fit the receiving content node; as such, the data is manipulated as needed for the particular content node or device. Further, in one example, data sent from the device to the server fulfils payload-requirements because the data is redistributed to other content nodes/devices (i.e., the content entry is returned to its original state) by the content router as described herein. Accordingly, data may be modified when sending or receiving data from content nodes/devices without losing any portion of the payload content.
  • As described herein for this example, the payload data (e.g., segments 401, 402, 403) is structured and represented in an XML-schema (which is generally an XML-tree data structure). Before and after manipulating the XML-tree structure, the payload is represented based on the same payload schema. Each node (tag/attribute) in the XML-tree structure is handled by an instruction (referred to as a “NodeInstruction”). Further, an instruction for a node may delegate handling of child nodes to child instructions. Additionally, in one example, NodeInstructions process the payload as an XML-tree structure using JAVA®-classes, where each NodeInstruction is represented by one instance of a JAVA®-class.
  • The data modulation logic targets the tailoring of content (removing portions of the content) not only in the payload to be sent to the device, but also in a shadow-payload, which is stored with the server, e.g., the repository 600 of content router 200. This Shadow-payload, together with the incoming payload, may be used to join and restore the payload before any further content router processing is applied. The shadow-payload itself is organized in the same node-structure as the original payload to ensure that each NodeInstruction gets/puts the information needed. In one example, to meet the different needs of NodeInstructions that may be implemented, the shadow-payload is organized into two XML-trees-one to store/read device-side-information and one to store/read content router-side-information during tailoring/joining processes.
  • Accordingly, various modules operable to perform various tasks may be set-up as a set of tools usable to perform various data modulations as content and changes to content are routed through the content router. In one example, a content router (such as content router 200) may include various default data modules for the handling of payloads, where new data modules or modifications to existing data modules may be generated as new content nodes are added or removed from the system. The exemplary framework for adding modules in an XML schema, for example, is particularly flexible and adaptable to various content nodes/devices that might be associated with the content router and community of connected content nodes. Additionally, data modulation within an XML schema may quickly adapt to new content nodes and content requirements.
  • NodeInstructions generally include SingleNodeInstructions and MultiNodeInstructions. SingleNodeInstructions handle a single node of the XML-tree structure and its value only, whereas MultiNodeInstructions handle a subset of a node's child nodes as a unit. SingleNodeInstructions may be implemented in a variety of different implementations to modulate node values. MultiNodeInstructions may be generally divided into 3 subtypes: i) GenericMultiNodeInstruction, which is the root instruction and allows generically adopting specialized instructions for each child node, ii) UniformMultiNodeInstruction, which handles unique named child nodes, and iii) MultiNodeInstruction, which handles two or more targeted child nodes with specialized processes.
  • In one example, the data modulation starts with a GenericMultiNodeInstruction. Various examples of GenericMultiNodeInstructions are illustrated in FIG. 17A. Further, examples of SingleNodeInstructions, which may be used for manipulating values of a single node without sub nodes, are shown in FIG. 17B. Further, UniformMultiNodeInstructions, which may be used for manipulating a single node (without value) containing many uniform (named) child nodes, are illustrated in FIG. 17C.
  • Various aspects of exemplary Data Modulation structures (continuing with the example of the XML schema) are illustrated generally in FIGS. 18A-E. In particular, an exemplary Root tag is illustrated in FIG. 18A; exemplary list nodes to be handled by specialized instructions is illustrated in FIG. 18B; and an exemplary handling of a single node by cutting the string is illustrated in FIG. 18C. Further, an exemplary handling of a multi node with m:n mapping is illustrated in FIG. 18D; and an exemplary handling of a multi node with 1:1 identification is illustrated in FIG. 18E. Those of skill in the art will recognize that these examples are illustrative only and that various other examples are possible, whether within an XML schema or otherwise.
  • According to another example, the content router includes a data modulation component operable to divide or split (and therefore referred to as a “splitter” component) certain content in a bidirectional manner. The splitter component may be part of or a feature of the data modulation features described and include logic operable to carry out the functions described herein. Further, the logic operable to carry out the splitter component functions may be stored in the store and forward logic 210 and processing logic 250 of content router 200 (see, e.g., FIG. 5).
  • Typically, when routing changes to content (e.g., add/update of contacts, events, etc.) from and to weaker content nodes (i.e., having reduced or fewer capabilities for handling data), some content nodes may not be capable of or desirable for handling the content change itself, but can handle “n” separate data changes (generally of a more simple nature) derived from the original single data change. For example, a recurrence rule in an events application stored as a single record on a first content node may be “split” into “n” number of single events on a second content node; a contact entry having multiple phone numbers on a first content node may be split into “n” number of contacts with one phone number each on a second content node; and the like. As will be described, the splitter component manages data changes from and to weaker devices without a loss of information by processing a single data change as multiple data changes according to content node capabilities.
  • In one example, the splitter component splits or divides a change to a data record to a relatively weak content node (e.g., a remote device), referred to as the “Splitting” direction. In particular, the splitter component determines the content node capabilities or preferences and splits, if necessary, one data change (from a content node via the content router) to “n” data changes to effectuate the data change. An illustrative example includes a change to a recurring event, such as the time of a weekly meeting. Some content nodes may be able to store the event as a single record with a recurring attribute. Some content nodes, however, may not have the capability for recurring events and must store individual records for each event. Thus, a change to the recurring event at a first content node is split or divided into two or more data changes to effect the change to multiple event entries with the less capable, weaker content node.
  • For example, a recurrence event may be stored on a first content node, such as a PIM application server, as:
    Title Meeting with Sue
    Time 10-11 am
    Start Date Friday 10 Jun. 2005
    Recurrence Type Monthly
    End Date Saturday, 31 Dec. 2005
  • The recurrence event may be stored (and routed) on a second content node, which may be a less capable, weaker device, as two or more single event entries, the first entry as follows:
    Title Meeting with Sue
    Date
    10 Sep. 2005
    Time 10-11 am
  • Additionally, the second entry may be stored with the content node as follows:
    Title Meeting with Sue
    Date
    10 Oct. 2005
    Time 10-11 am
  • The single events in the device match those in the PIM application backend because the Title and Time are the same and they match the recurrence details specified in the PIM application program (i.e., they occur on the 10th of each month). A change to the recurrence event on the first content node or a change to the single event entries on the second content node may be routed by the content router to change the corresponding entries and preserve the recurrence aspect of the events. In particular, the single event entries and recurrence event entry may be split or merged depending on the direction and content capabilities, thereby improving the ability to synchronize all connected content nodes in the community despite disparate capabilities of the various content nodes.
  • Another illustrative example includes a contact having multiple phone numbers. For example, “Joe Smith” may include three phone numbers associated therewith. A particular content node or device may be capable of storing only one phone number per contact. Accordingly, the splitter component may operate to divide the contact entry of “Joe Smith” into two or more separate data entries for storage with the device, in this example, into three entries for “Joe Smith” having one phone number for each.
  • The splitter component is also operable to perform “Integration” of the record in a direction from the device to the server or other content nodes, referred to as the “Integration” direction. In particular, an incoming device data change related to a former data change will result in a corresponding (server) data change. For example: a phone number may be reintegrated into a full content entry; move of a single event results in reintegrated into full recurrence as an exceptional event; and the like.
  • During initial import of data from a content node, such as a device, data is aggregated to a lesser count of data with the server. In one example, “n” data records are aggregated to one data record when possible. The content router further stores (e.g., in repository 600 or other memory associated therewith) this information from “Aggregation” processes for subsequent “Splitting” and “Integration” processes.
  • According to a third method, shown generally with reference to FIGS. 8A and 8B, segments are not saved to a repository. The store and forward logic 210 may accommodate a limited capability content node by stripping or modifying an incompatible or undesired segment from the command payload. However, with this method, a copy of the stripped or modified segment is not preserved in a repository. If those segments are needed later, the store and forward logic 210 may request and receive the segment from the source of the original incoming command.
  • FIG. 8A illustrates a process of stripping a segment of an exemplary email according to embodiments of the present invention. An incoming email 900 arrives at a first content node 300-1 from the Internet over an SMTP connection. The email 900 includes a payload 901, which contains an incoming email header and body 401 containing information such as date and time and to, from and reply email addresses as well as the text entered by the sender. The payload 901 also includes an image file attachment 402, such as a JPEG file, and a presentation file attachment 403 such as a PowerPoint presentation. An application running on the content node 300-1 may convert the attachments 402 and 403 to links 402A and 403A, which allow a capable content node to access the attachments through the hyperlinks to the attachments. The content node 300-1 may then create one or more messages 910, according to an email protocol such as IMAP, forming a payload 911 including the incoming email header and body 401, the link to the image file 402A, and the link to the presentation file attachment 403A. The content node 300-1 sends the messages 910 to protocol interface logic 260 within the content router 200.
  • The protocol interface logic 260 converts the one or more messages 910 into a command 420 containing a payload 421 including the incoming email header and body 401, the link to the image file 402A, and the link to the presentation file attachment 403A extracted from payload 911. The protocol interface logic 260 allows for content nodes that use different protocols to function with the content router 200. The store and forward logic 210 receives the incoming command 420 from the protocol interface logic 260 and prepares an outgoing command 430 for content node 300-2. In this example, the content node 300-2 is unable to a process presentation file attachment 403 or its link 402A. For this content node 300-2, the store and forward logic 210 is configured to strip off any links to a presentation file attachment 403A. The store and forward logic 210 prepares the outgoing command 430 including a payload 431 containing the incoming email header and body 401 and the link to the image file 402A, but not the link to the presentation file attachment 403A. In this case, the store and forward logic 210 does not preserve a copy of the link 403A in a repository 600 for later use.
  • After the content router 200 has forwarded a stripped email to content node 300-2, a user at content node 300-2 may forward the email to an external Internet address. When protocol interface logic 260 receives the forwarded email, it may determine that the email is missing one or more segments contained in the original email. The protocol interface logic 260 may request the missing segments from an inbox at content node 300-1 containing the complete email. After receiving the original segments, the protocol interface logic 260 may restore the segments to the forwarded email. Next, the protocol interface logic 260 may use an email server associated with inbox at content node 300-1 to forward the email to the external Internet address.
  • FIG. 8B illustrates a process of restoring a stripped segment to an email if a user later forwards the email according to embodiments of the present invention. A user may forward an email previously received at content node 300-2. For example, the content node 300-2 sends a command 440 containing a payload 441 including a newly created outgoing email header and body 401B, the original incoming email header and body 401, and the link to the image file 402A. This incoming command 440 includes neither the presentation file attachment 403 nor its link 403A. In response to receiving the incoming command 440, the store and forward logic 210 generates an outgoing command 450 including a payload 451 containing the segments from payload 441.
  • The protocol interface logic 260 receives command 450 and detects that it is a forwarded email. The protocol interface logic 260 may attempt to restore the stripped segments by requesting the unabridged email from the first content node 300-1. Alternatively, the protocol interface logic 260 may request just the stripped segments 402 and 403. In response, the first content node 300-1 sends the protocol interface logic 260 the stripped segments, for example, in one or more IMAP messages 960, forming a payload 961 that includes the image file attachment 402 and the presentation file attachment 403.
  • The protocol interface logic 260 prepares an email containing a payload 971 including the outgoing email header and body 401 B, the incoming email header and body 401, the original image file attachment 402, and the original presentation file attachment 403. The protocol interface logic 260 may forward the email to an email server 300-1A associated with content node 300-1, for example, in an SMTP message 970 including payload 971.
  • The email server 300-1A responds to the SMTP message 970 with an outgoing email 980 to the external Internet address. The outgoing email 980 contains each of restored segments of the incoming email that were previously stripped off or modified by the protocol interface logic 260. The outgoing email 980 also contains the outgoing email header and body 401B created at content node 300-2. As a result, the outgoing email may appear that it was forwarded from an email containing the original attachments 402 and 403 even though the content node 300-2 from where the user forwarded the email had limited capabilities and received neither attachment.
  • A repository 600 may also be used for keeping an inventory of information routed among connected content nodes. Alternatively, the inventory may be kept in separate memory. The inventory may include characteristics of content and/or characteristics of metadata of one or more content types routed to and from the content router. The inventory may be used for summarizing characteristics of routed content residing on one or more of the connected content nodes 300. The inventory may be used to preview an item count. For example, if one or more routing parameters are changed for a particular content node 300, the content router 200 may estimate or determine the number of additional items of a particular content type would need to be fetched from one or more other content nodes 300 to place the particular content node 300 in line with the updated routing parameters. The characteristics may be used to compute a summary number of a content type residing on a content node falling within a condition based on the characteristics in the inventory. The entries in the inventory may be counted to summarize a number of a particular content type reside on a content node. In some embodiments, the inventory may be used during conflict checking to identify duplicate commands.
  • For an email content type, the content router may collect information in an inventory from each email message routed through the content router 200 and residing on a content node. For example, for each command to add a new email message, the content router 200 may save characteristics of the email such as the existence of the email and a date the email was received by the content node. The entries in the inventory may be counted to summarize a number of email messages residing on a content node. The date of each email may be used to summarize a number of email messages residing on a content node falling within a specified date range based on a date characteristic in the inventory for a plurality of email messages routed through the content router, If a user wishes to see a number of email messages that a content node would contain if the user changed a routing parameter, such as the number of days an email should reside on a content node, the content router 200 may compute the number of emails in an inventory that fall within a particular date range.
  • The inventory may also be used by a scheduler on the content router 200 to remove email messages from a content node 300 previously routed through the content router 200 to the content node 300. A scheduler on the content router 200 may periodically compare dates in the inventory of email messages previously routed through the content router 200. For example, the schedule may compare these dates to a routing parameter indicating a number of days a user as elected to maintain routed emails on the content node. The routing parameter may be to keep emails from the last three days on a user device, such as a mobile phone. New email messages may be forwarded to the user device as they arrive to the content router 200 and an inventory kept of each new email. As emails are deleted by actions of a user at one or more content nodes, the content nodes sends email deletion commands to the content router and the inventory may be updated accordingly. The scheduler may periodically (e.g., nightly) compare the dates of emails in the inventory to the routing parameter indicating that emails should only be kept on the user device for the certain number of days. If the inventory indicates that the user device contains email older that the routing parameter permits, the scheduler on the content router may generate a command to delete each email on the user device that is older than allowed by the routing parameter. For example, the routing parameter may indicate keeping a two day history of emails on the user device. Each night the scheduler may store a command to delete emails from the user device that are older than two days. Additionally, the inventory may be used to indicate to a user a number of emails that would need to be removed from or added to a content node if a routing parameter where changed. For example, if a routing parameter for a content node currently indicated keeping two days of emails were changed to keeping one day of email, the content router 200 may determine from the inventory data associated with the content node that a particular number of email messages would need to be deleted from the content node. Similarly, if the routing parameter were changed from two days to three days for a particular content node 300, the content node 200 may determine, from inventory data related to the particular content node 300 and to another related content node, the number of email messages that would need to be routed from the related content node to the particular content node.
  • Similarly, the inventory may be used by the content router to limit a number of one or more content types on a content node. The content router may send delete commands corresponding to each add command of a content type wherein the content node already holds a predetermined number of content of a type. Alternatively, a scheduler may be used to periodically determine if a content node has a number of content items in excess of predetermined threshold number for each content type. The predetermined threshold number may be configured by the user or alternatively may be a default value for the content node type. For example, if a content node, such as a mobile phone, may have 500 or more email messages. A content node, such has a user account may have a larger predetermined threshold number, such has 5000. For each new email message added to the content node, the content router may send a corresponding delete command to remove the oldest email message from the content node. Alternatively, a scheduler may periodically determine if a content node has more that a predetermined number of items of a particular content type and then send one or more delete commands to remove outdated content. For example, a predetermined number may be 500, which may indicate that a particular user device may have up to 500 emails. If the content router determines that the user device has more than 500 emails, it may send a number of delete commands to remove email messages in excess of 500. In some embodiments, the content router sends delete commands to remove the oldest emails messages in excess of the predetermined threshold number. When provisioning a content node, the inventory may be used to request the most recent 500 emails from other content nodes for forwarding to the provisioned content node. As new emails arrive, they may be added to the content node until a predetermined limit, such as 5000, is reached. Once the limit is reached, the content router may issue delete commands to remove the oldest email messages from the content node.
  • Similarly for events, the content node may have a predetermined threshold number for a maximum number of events on a content node. For each new event added to the content node, the content router may send a delete command to remove the oldest event if the predetermined threshold number would otherwise be exceeded. Alternatively, the content router may periodically review the inventory to determine a number of event-content types exist on a content node. It may then send one or more delete commands to delete the oldest events from the content node.
  • Similarly for tasks, the content node may have a predetermined threshold number for a maximum number of tasks on a content node. For each new task added to the content node, the content router may send a delete command to remove the oldest task if the predetermined threshold number would otherwise be exceeded. Alternatively, the content router may periodically review the inventory to determine a number of task-content types exist on a content node. The content router may then send one or more delete commands to delete the oldest tasks from the content node. Alternatively, the content router may then send one or more delete commands to delete completed tasks until the predetermined threshold number is not exceeded.
  • Additionally, the content router 200 may calculate and save a checksum of the new email. The checksum may be used when determining if a command to add a new email duplicates a command in the command memory or a command previously passed through the content router.
  • FIGS. 9A to 9C show a structure of a store and forward logic 210 and data path between processing logic 250 and content nodes 300-1 to 300-n according to embodiments of the present invention.
  • FIG. 9A shows store and forward logic 210 having a command memory 220 and processing logic 250. The processing logic 250 is coupled to a connected data set configuration 500 and to the command memory 220. The command memory 220 is also shown coupled to content nodes 300-1 to 300-n. The command memory 220 may be configured to include both incoming memory 230 and outgoing memory 240 for each content node 300. A content node 300 may push (put) one or more commands to the incoming memory 230. A content node 300 may also pull (get) one or more commands from the outgoing memory 240.
  • Those skilled in the art will recognize that the incoming memory 230 and outgoing memory may be formed using a database. For example, command memory 220 may be configured in a database containing commands. Each command in the database may be associated with attributes. For example, an attribute associated with a command in the database may identify the command as an incoming command or an outgoing command for a particular content node 300.
  • FIG. 9B shows a structure of the command memory in the store and forward logic 210 for a single content node 300 according to embodiments of the present invention. The command memory 220 includes incoming memory 230 and outgoing memory 240.
  • In some embodiments, the incoming memory 230 includes an incoming queue 231 and a corresponding in-transit queue 232. The incoming queue 231 holds incoming commands received by the store and forward logic 210 from a content node 300 but have not been responded to by the processing logic 250. The corresponding incoming in-transit queue 232 holds incoming commands that the processing logic 250 is in the process of responding to. Once an incoming command has been successfully responded to by the processing logic 250, processing logic 250 may discard the incoming command from the in-transit queue 232. If the processing logic 250 was unsuccessful at processing an incoming command, for example, if a necessary resource is unavailable, the processing logic 250 may move the incoming command from the in-transit queue 232 back to the incoming queue 231.
  • In some embodiments, the outgoing memory 240 includes an outgoing queue 241 and a corresponding in-transit queue 242. The outgoing queue 241 holds outgoing commands generated by the processing logic 250 (in response to an incoming command) but the processing logic 250 has not initiated sending of the outgoing command to the content node 300. The corresponding outgoing in-transit queue 242 holds outgoing commands that the processing logic 250 has initiated sending to the content node 300 but a confirmation or assurance that the content node 300 has received the outgoing command has not been received by the processing logic 250.
  • Those skilled in the art will again recognize that a database may used to hold commands and that one or more attributes associated with each command may indicate that the command is in the incoming queue 231, the corresponding incoming in-transit queue 232, the outgoing queue 241, or the corresponding outgoing in-transit queue 242.
  • FIG. 9C shows incoming memory 230-1 used for holding an incoming command from a source content node 300-1 and outgoing memory 240-2 used for holding an outgoing command to a destination content node 300-2.
  • During a period when a source content node 300-1 is coupled to the store and forward logic 210, the source content node 300-1 may send (put) a command or set of commands to the content router 200. The processing logic 250 may place the incoming command or set of commands the incoming queue 231-1 associated with the source content node 300-1.
  • At some later point in time, the processing logic 250 may respond to an incoming command held in the incoming queue 231-1. As part of responding to an incoming command in the incoming queue 231-1, the processing logic 250 may move the incoming command from the incoming queue 231-1 to the in-transit queue 232-1 of the incoming memory 230-1. Additionally, the processing logic 250 may select a destination content node 300-2 for which it may generate an outgoing command. In general, the processing logic 250 may select a set of destination content nodes to include multiple destination content nodes, a single destination content node, or no destination content nodes. Next, the processing logic 250 may place the generated outgoing command in the outgoing queue 241-2 of a destination content node.
  • After the processing logic 250 has successfully prepared and written an outgoing command to the outgoing queue 241-2, the processing logic 250 may remove the incoming command from the in-transit queue 232-1 in the incoming memory 230-1. If the processing logic 250 is unsuccessful at either preparing or writing the outgoing command, the processing logic 250 may move the incoming command from the in-transit queue 232-1 back to the incoming queue 231-1. In this manner, an incoming command is either successfully responded to or it is placed back into the incoming queue 231-1 for a future attempt at processing the incoming command.
  • The processing logic 250 may send a notification to the content node 300-2 to inform the content node 300 that an outgoing command is pending in the outgoing queue 241-1. At some later point in time, the destination content node 300-2 may request (pull) the outgoing command from the outgoing queue 241-2. Alternatively, the content router 200 may push the outgoing command to the destination content node 300-2. After the process of sending the outgoing command to the destination content node 300-2 has been initiated but before the processing logic 250 has determined that the outgoing command was successfully sent and/or received, the processing logic 250 may move the outgoing command from the outgoing queue 241-2 to the in-transit queue 242-2 associated with the destination content node 300-2.
  • A success at sending and/or receiving may be internally determined by the processing logic 250, determined by receipt of an instruction to remove the outgoing command, or determined by receipt of an acknowledgement (ACK) or an equivalent notification providing sufficient assurance that the outgoing command has been received by the destination content node 300-2. Communicating an acknowledgement may be initiated by the destination content node 300-2 or by an intermediary acting as a proxy for the destination content node 300-2 as described below with reference to FIGS. 15B, 15C, 16B and 16C.
  • If a negative acknowledgement (NACK) is received, an error is detected, a time-out has occurred, or the like, the outgoing command residing in the in-transit queue 242-2 may be moved back to the outgoing queue 241-2. As a result, if a failure is determined, for example a temporary failure, the processing logic 250 may have a future opportunity to resend the outgoing command from the outgoing queue 241-2 to the destination content node 300-2. If the processing logic 250 determines that the failure is permanent, it may discard the command thereby avoiding a potential endless loop of transferring a command in and out of an in- transit queue 232, 242.
  • In this way, it is sufficiently confirmed that an outgoing command is either received by the destination content node 300-2 or placed back into the outgoing queue 241-2 for a future attempt at sending it to the destination content node 300-2.
  • The act of moving commands between an incoming or outgoing queue 231, 241 and a corresponding in- transit queue 232, 242 helps assure that a command is only discarded after it has been properly responded to or sent. Additionally, the process of moving a command between the incoming or outgoing queue 231, 241 and the in- transit queue 232, 242 may occur with an actual move of data from one allocated buffer to another. Alternatively, the process of moving between queues may occur virtually by changing a state of a flag or an attribute in a database. Additionally, each time a command enters either the incoming queue 231 or the outgoing queue 241, for example from an in- transit queue 232 or 242 after an error condition has occurred, the processing logic 250 may perform a conflict check as described below.
  • In the examples described with respect to FIGS. 9A-9C, the incoming data change commands might be stored in command memory 220 twice, e.g., in incoming memory 230-1 and outgoing memory 240-2. In particular, the content router 200 processes (for each targeted content node 200-2, 3, . . . ) data change commands from “incoming” command memory 230-1, depending on the content node putting the command, toward the “outgoing” command memory 240-2, depending on the content node getting the command. Thus, the data change command may be stored two times the number of target or connected content nodes. In other embodiments of content router 200, as will be described with respect to FIGS. 9D-9F, the use of command memory 220 for storing commands may be reduced.
  • One such embodiment of an exemplary content router 200 with reduced storage is illustrated in FIG. 9D. In this example, incoming data change commands are processed toward other connected content nodes, such as content node 300-2, without storing the incoming data change commands in incoming memory 230-1 of command memory 220 as described above with respect to FIG. 9C. In particular, content node 300-1 forwards a data change command to store and forward logic 210 of content router 200, where store and forward logic 210 attempts to immediately process and route the command to content node 300-2 (i.e., without first storing the command in incoming memory 230-1). For example, the change command is put from content node 300-1 directly to processing logic 250 of store and forward logic 210, where processing logic 250 processes and routes the command to the outgoing memory 240-2 (e.g., to outgoing queue 241-2 and in-transit queue 242-2 as describe above). Thus, the incoming storage (e.g., incoming memory 230-1; indicated in outline in FIG. 9D) may be eliminated, or at least its use limited, and only outgoing storage (e.g., outgoing memory 240-2) used.
  • In one example, if processing logic 250 is unavailable or unsuccessful in processing an incoming command from content node 300-1 (e.g., if a resource is unavailable or the like) incoming memory 230-1 may be used to store the command as discussed with regard to FIG. 9C, for example. Thus, the example of FIG. 9D may be used alone or in combination with other methods/systems, such as that of FIG. 9C.
  • The exemplary content router 200 of FIG. 9D may reduce storage requirements associated with the store and forward logic 210. For example, instead of command memory 220 storing commands twice for each associated content node (i.e., storage within incoming memory 230-1 and outgoing memory 240-2; before and after processing by processing logic 250), command memory 220 stores a single command for each associated content node. For example, only the outgoing memory 240-2 is used for each targeted content node. The reduction or elimination of incoming storage to facilitate processing may reduce costs and increase the speed of content router 200 (as evident by the reduced processing and storage requirements).
  • In another embodiment of content router 200, illustrated generally in FIG. 9E, the two storages (e.g., incoming storage 230-1 and outgoing storage 240-2) are replaced by a single storage 222 for all content nodes. In particular, incoming data change commands are processed by processing logic 250 in the context of the device “put”-request immediately to a central storage, or command memory 222 of content router 200, where the command memory 222 is content node independent (e.g., command memory 222 is not adapted for or associated with a particular content node). Outgoing data change commands are then processed by processing logic 250 in the context of a content node/device “get”-request from the command memory 222 when routing to the content nodes 300-2, 300-3, and 300-4.
  • In particular, when content node 300-1 puts data, it is pre-processed by processing logic 250 prior to storage in command memory 222. For example, various data modulation, splitter/aggregation processes, or the like may be carried out on the data command prior to getting to command memory 222 such that a normalized data change command is held therein and accessible by content router 200. In one example, the normalized command stored with command memory 222 will represent the full scope of the change available from the first content node 300-1. As other content nodes 300-2, 300-2, 300-4 are notified and “get” the data change command, or the data change command is otherwise routed thereto, data modulation will occur (e.g., the data change command will be modulated by processing logic 250 according to the particular content node as the data change command flows to the particular content node).
  • Aspects of this example may reduce storage requirements of content router 200 because the storage of data change commands may be reduced to a single entry accessible by all associated or connected content nodes (compare this single storage to previous examples that may store one or two commands per each connected or targeted content node). Additionally, the reduced storage may simplify the operation of store and forward logic 210 as shown in FIG. 9E relative to some other examples described herein; however, it is noted that the content router will generally need to store additional information such as which content node has fetched the change command, etc. Once the data change command has been fetched or received by each content node, the change command may be deleted from command memory 222.
  • FIG. 9F illustrates another embodiment of an exemplary content router 200, which may operate to push or directly write data change commands to certain content nodes. As described in some of the examples above (e.g., with respect to FIG. 9C), outgoing data change commands are stored in a command memory 240-2. Content router 200 may notify the content nodes 300-2, 300-3, and 300-4 of an available data change command, for which the respective content nodes may thereafter request the data change commands from the content router 200. For highly capable content nodes, such as a user account associated with service provider backend (e.g., a Yahoo!® User account and associated backend or the like), content router 200 may not need to store these data change commands in command memory 240-2; content router 200 may instead push or write the command directly through to the particular content node (sometimes referred to as “write-through”). Even highly available mobile user-devices may allow an exemplary content router system to write through directly (obviating the need for storage of the outgoing commands in memory).
  • Thus, if content node 300-2 is available and capable when content router 200 receives a data change command from content node 300-1, the data change command may be processed by processing logic 250 and pushed to content node 300-2 (e.g., without using the outgoing command memory 240-2 and waiting for content node 300-2 to request the command). Thus, these features of content router 200, as shown in FIG. 9F, may potentially reduce the storage required or associated with content router 200 relative to some of the examples described herein.
  • If a particular content node, e.g., content node 300-3, is not available and/or capable to take the data change commands as described with respect to content node 300-2, the data change commands for that particular content node may be stored in an outgoing memory 240-2 (similar or identical to that described with reference to FIG. 9C, for example) and a notification to content node 300-3 made. For example, content node 300-3 may be notified of the change command in outgoing memory 240-2 via a technical SMS, or the like. Thereafter, content node 300-3 may fetch the data change as previously described.
  • Additionally, in this example content router 200 may store states, filters, information about what content is on the various content nodes, the content node capabilities, and the like to assist in facilitating the direct write through or push to the content node(s). Such information may be stored with or accessible by processing logic 250, connected data set configuration 500, and/or the like.
  • Those of ordinary skill in the art will further recognize that various examples of store and forward logic 210 as described with respect to FIGS. 9A-9E may be used alone or in combination with other methods and systems (whether described herein or not). Additionally, various examples of store and forward logic 210 and its operation may be used as a primary process for routing data change commands with one or more other examples serving as a secondary process for routing if the primary process is unavailable (e.g., if a resource is unavailable, a content node is unavailable, or the like).
  • FIGS. 10A to 10D show a Put-Get-Ack procedure from points of view a content node 300 and a content router 200 according to embodiments of the present invention. A goal of this procedure is to resolve conflicting commands within the incoming and outgoing queues 231, 241. By resolving conflicts within the incoming and outgoing queues 231, 241, content nodes 300 may be freed from the burden of resolving conflicts.
  • According to the PUT-GET-ACK procedure, a content node 300 first sends (PUTs) of all commands pending in the content node 300 to the content router 200. The content router 200 resolves any conflict between an incoming command and a command already in either the incoming queue 231 or outgoing queue 241. After the content node 300 has sent all commands to the content router 200, the content node 300 receives (GETs) commands from the outgoing queue 241. Finally, an acknowledgement (ACK) is received by the content router 200 assuring that the content node 300 received the outgoing commands.
  • FIG. 10A shows a PUT-GET-ACK procedure between a content router 200 and a content node 300 from a point of view of the content node 300. At 1100, a content node 300, such as a user device 310, waits until there is a need or an ability to put a command to or get a command from the content router 200.
  • At 1101, a content node 300 receives a notification from the content router 200 that a command is pending in the outgoing queue 241 and/or the content node 300 determines that it has one or more commands to send to the content router 200.
  • At 1102, the content node 300 first determines whether there are any commands to send to the content router 200. By requiring that the content node 300 sends commands before receiving commands, resolution of conflicts is handled in the content router 200 rather than by the content node 300.
  • At 1103, the content node 300 sends a request to PUT commands from the content node 300 to the content router 200. If the content node 300 has one or more commands to put to the content router 200, it may send a sequence of one or more individual requests each containing a payload including a command. Alternatively, it may send a sequence of one or more requests each containing a payload including batches of commands.
  • At 1104, the content node 300 receives an acknowledgement that the commands were received by the content router 200. The content node 300 then checks again at 1102 to determine whether there are any more commands to put to the content router 200.
  • At 1105, if the content node 300 does not have any pending commands to put to the content router 200, the content node 300 next checks to determine if there are any commands to get. In some embodiments, the content router 200 includes an indication in the acknowledgement received in 1104. The indication may inform the content node 300 that a pending command is waiting in the outgoing queue 241. If no commands were pushed to the content router 200, the content node 300 may determine that there may be one or more pending commands to get based on the notification received earlier.
  • If there are commands to GET from the content router 200, at 1106, the content node 300 sends a request to the content router 200. At 1107, the content node 300 then receives a response having a payload containing the one or more commands. At 1108, the content node 300 processes the commands, which may include executing the commands or may simple save the commands for future execution. At 1109, the content node 300 sends to the content router 200 an acknowledgement (ACK) that the commands were received and processed. At 1110, the content node 300 waits for a response that its acknowledgement (ACK) successfully was received by the content router 200.
  • Next, again at 1105, the content node 300 checks to see whether there are any more commands to get. The content node 300 may determine whether the content router 200 has additional commands by examining the last received response received at 1110. In some embodiments, a response may contain an indication that one or more additional commands are pending in the outgoing queue 241. In some embodiments, a response may contain the one or more additional commands that were pending in the outgoing queue 241. In cases where the response contains an indication that one or more additional commands are pending in the outgoing queue 241, the content node 300 continues by requesting and processing the commands at 1106. In cases where the response contains the one or more additional commands, the content node 300 continues by processing the commands at 1108.
  • FIG. 10B shows a PUT-GET-ACK procedure between a content router 200 and a content node 300 from the point of view of the content router 200 receiving a new incoming command PUT to the content router 200 by the content node 300. At 1200, a content node 300 sends a new command to the content router 200, where the new command is destined for the incoming queue 231.
  • At 1201, the processing logic 250 determines whether any conflict exists between the new command and any command existing in either the incoming queue 231 or the outgoing queue 241.
  • At 1209, if a conflict exists between the new command and an existing command, the processing logic 250 resolves the conflict by determining whether to discard the new command, aggregate the new command with the existing conflicting command, remove the existing conflicting command from the queue 231 or 241, and/or move the new command to the incoming queue 231. The process of detecting and resolving conflicts between a new command and an existing command is further described below with reference to FIG. 10D. At 1203, if no conflict is detected, the processing logic 250 moves the command to the incoming queue 231.
  • At a future time, the processing logic 250 begins processing commands in the incoming queue 231 as shown at 1204. At 1205, once processing has been initiated, the processing logic 250 may move the command from the incoming queue 231 to the in-transit queue 232. At 1206, the processing logic 250 receives an acknowledgement that the command was processed, receives a negative acknowledgement that the command was not processed, or determines that due to a failure, such as a timeout, the command must be processed again.
  • At 1207, the processing logic 250 receives an acknowledgement. Therefore, the processing logic 250 removes and discards the command from the in-transit queue 232. Alternatively at 1208, if a timely acknowledgement is not received, the processing logic 250 prepares to move the command from the in-transit queue 232 back to the incoming queue 231 for reprocessing at 1204. At this point, the command to be moved may be treated as a new command. At 1201A, the processing logic 250 performs a conflict check between the command to be moved and commands in the incoming and outgoing queues 231, 241 for the content node 300. The process then continues as described above with reference to 1202.
  • FIG. 10C shows a PUT-GET-ACK procedure between a content router 200 and a content node 300 from the point of view of the content router 200 generating a new outgoing command for a content node 300 to GET from the content router 200. At 1210, the content router 200 may generate a new outgoing command in response to an incoming command from a different connected content node associated with the same user.
  • At 1211, the processing logic 250 determines whether any conflict exists between the new command and any command existing in either the incoming queue 231 or the outgoing queue 241. At 1219, if a conflict exists between the new command and an existing command, the processing logic 250 resolves the conflict by determining whether to discard the new command, aggregate the new command with the existing conflicting command, remove the existing conflicting command from the queue 231 or 241, and/or move the new command to the outgoing queue 241. At 1213, if no conflict is detected, the processing logic 250 moves command to the outgoing queue 241. At 1214, the processing logic 250 may send a notification to the content node 300 to indicate that a new command is waiting in the outgoing queue 241.
  • At a future time, the processing logic 250 begins processing the commands in the outgoing queue 241. At 1215 once processing has been initiated, the processing logic 250 send a command from the outgoing queue 241 to the content node 300. The processing logic 250 may also move the command from the outgoing queue 241 to the in-transit queue 242. At 1216, the processing logic 250 waits for an acknowledgement from the content node 300 indicating that the command was processed by the content node 300. A failure may occur if the processing logic 250 receives a negative acknowledgement that the command was not processed or determines that due to a failure, such as a timeout, the command must be processes again.
  • At 1217, the processing logic 250 receives an acknowledgement. Therefore, the processing logic 250 removes and discards the command from the in-transit queue 242. Alternatively at 1218, if a timely acknowledgement is not received, the processing logic 250 prepares to move the command from the in-transit queue 242 back to the outgoing queue 241 for reprocessing. At this point, the command to be moved may be treated as a new command. At 1211 A, the processing logic 250 performs a conflict check between the command to be moved and commands in the incoming and outgoing queues 231, 241 for the content node 300. The process then continues as described above with reference to 1212.
  • FIG. 10D shows a structure for detecting conflicts between a new command 400 and existing commands 401-407 in the incoming queue 231 and the outgoing queue 241. A new command 400 may be received from a content node 300 or generated by the processing logic 250. New commands 400 from a content node 300 are destined for the incoming queue 231. New commands 400 generated by the processing logic 250 are destined for the outgoing queue 241. Before a new command 400 is saved in either the incoming queue 231 or the outgoing queue 241, the processing logic 250 determines whether a conflict exists.
  • To determine whether a conflict exists, the processing logic 250 compares the new command 400 to existing commands 401-407 in the incoming queue 231 and/or the outgoing queue 241. If the new command 400 and an existing queued command contain related content or metadata, the processing logic 250 may determine that a conflict must be resolved between the new command 400 and this existing command.
  • To resolve a detected conflict, the processing logic 250 may determine if one command supersedes the other. In the case where the existing command supersedes the new command, the processing logic 250 may discard the new command 400. In the case where the new command supersedes the existing command, the processing logic 250 may either replace the existing command with the new command 400 in the appropriate queue 231 or 241, or it may remove the existing command from the queue 231 or 241 and add the new command 400 as a new entry at a different location in the appropriate queue 231 or 241.
  • Alternatively, the processing logic 250 may determine that the new command 400 and the command conflicting with the new command 400 should be aggregated into a single command. In the case where commands are aggregated, the processing logic 250 may either replace the existing command with an aggregated command, or it may remove the existing command from the queue 231 or 241 and add the aggregated command as a new entry in the appropriate queue 231 or 241.
  • FIG. 11 illustrates a representation of a structure of a connected data set configuration 800 according to embodiments of the present invention. A connected data set configuration database 800 includes a hierarchal configuration, e.g., 510 to 570, for each user connected to the content router 200. A first user defines a connected data set configuration 510 using a configuration and maintenance tool. The configuration and maintenance tool may be, for example, a web based graphical user interface (GUI) having access to the database 800 via SQL database calls.
  • Each user configuration 510 to 570 may include a configuration for user devices 511 and for user accounts 516. Each configuration for user devices 511 includes a set of configurations for each user device 512, 513. Each configuration for user accounts 516 includes a set of configurations for each user account 517, 518. Each user device and account configuration 512, 513, 517 and 518 includes a set of configurations for each configured content type.
  • Those skilled in the art will recognize that the connected data set configuration database 800 may be structured using one of several possible hierarchal structures. For example, user devices configuration 511 and user accounts configuration 516 may be combined into a single structure. The hierarchal structure between user devices or user accounts and content type may be reversed such that a content type configuration contains a configuration for multiple user devices and/or user accounts, rather than having a user device or user account configuration containing a configuration for multiple content type.
  • As shown, a user device configuration 513 contains a configuration for each content type processed by the user device. For example, if user device B is capable of processing contacts, events, to do items (tasks), emails and library items, the user device B configuration 513 may contain respective configurations 513-1, 513-2, 513-3, 513-4 and 513-5. A database ID may be allocated for each content type of a user's connected content nodes. Therefore, a database ID may have a one-to-one relationship to a particular content type on a particular connected content node for a particular user. This database ID may be used by a content node when it communicates with the content router 200. For example, each command that is generated by a content node may include a specific database ID to identify the user, the content node and the content type as described below with reference to FIG. 13.
  • When a new content node (e.g., a user account or device) enters the connected community of content nodes, it is generally desirable to avoid a situation where content or metadata (e.g. contacts, events, etc.) associated with the new content node is duplicated with that already available in the connected community. Such a scenario may result in, for example, if two identical or nearly identical content entries exist on one or more of the content nodes. Accordingly, the content router may include logic operable to detect and handle duplicate content entries, in particular, when a content node is added to the community.
  • In one example, data consolidation logic is included with the store and forward logic 210 (e.g., with the processing logic) of the content router 200 (see, e.g., FIG. 5). The data consolidation logic is operable to generate and maintain (e.g., store) a hash-value of at least a portion of the routed payload (including the content and/or metadata). In one example, the hash-value is created from at least one “significant” property of each payload, which is generally less than the entire content of the payload. The significant property may include a specific data field depending on the content type, e.g., the first and last name of a contact entry, a phone number for a contact, the subject field for an event entry, or the like.
  • The hash-value may be used to detect possible duplicates whenever new data enters the community and query only these possible duplicate data candidates for inspection. Further, by being based on a portion of the payload (e.g., based on a significant property), non-exact matches may be examined for possible duplicate entries. Such features may avoid the time and cost of having to query all available data whenever new data enters the community and reduce the potential for duplicates because hash values may be relatively quickly compared with a list of hash-values of known content.
  • In particular, a list of hash-values may be created and stored (e.g., in repository 600 of content router 200 shown in FIG. 5) for all content entries associated with the community of connected nodes. As new data enters the community via one or more content nodes 300-1, 300-2, 300-3, etc., a hash-value may be determined for each data entry or payload by a similar process as for the original data. By comparing hash-values of two content entries, potential duplicates may be identified relatively quickly compared with comparing the full data entries of old and new data. When a potential duplicate is identified based on the generated hash-values, various rules may be implemented to determine if the potential duplicates are in fact duplicates and should therefore be stored separately, merged, ignored, or the like. Various rules to determine actual duplicates may be used, and may depend, e.g., on the content type. In one example, a rule may be operable to determine an actual or potential duplicate if two content entries or records are an exact match, i.e., all data in all fields are exactly the same between two content entries or records. For example, two contact entries may both consist of an identical name and phone number.
  • In other examples, various exceptions or modifications to an exact match rule are possible and contemplated. For example, a first content node may include a contact entry with a first number of data fields, n. A new content entry may include a second number of data fields, n-1. The hash-values may indicate potential duplicates based on similar significant properties (such as a name or phone number in a content entry). The content entries will not have an exact match, however, because the first content entry has additional, unmatched fields. The system may nevertheless identify these as the same record and not create a duplicate entry for the new entry if, for example, all common data fields match. Additionally, the record which has the largest payload or number of segments/data fields may be used as a base record, whereby the other records are merged into the base record as appropriate. Additional rules may be defined and used to equate data fields of different devices and systems that do not include exact matches etc. For example, a first contact entry listing “John Smith” and a phone number, and second contact entry including “John Smith” and an email, are not exact matches, but may be merged into a single record including “John Smith” and both the email and phone number data. The merged record will be distributed to all content nodes (with some modifications or filtering possible based on content node capabilities/preference/etc.).
  • For example, a first content node may include an event entry with a recurrence rule. A new event entry may include a single event occurring just within that recurrence defined by the recurrence rule of the first content entry. The hash-values may indicate potential duplicates based on similar significant properties (such as the summary of a content entry). The content entries will not have an exact match, however, because the first content entry has additional recurring information and the start date does not match. The system may nevertheless identifies these as the same record in one example and does not create a duplicate entry for the new entry if the single event occurs just within the recurrence defined by the recurrence rule of the first event. Additionally, the record which has the largest payload or number of segments/data fields may be used as a base record. The merged record, in this case the recurring event, will be distributed to all content nodes (with some modifications or filtering possible based on content node capabilities/preference/etc.).
  • Accordingly, the hash-value provides a relatively fast and cheap process for identifying potential duplicates (compared to storing or querying the actual content from varying content nodes). Additionally, various rules may be defined and utilized to determine actual matches and the treatment of those matches (e.g., to merge, discard, etc.).
  • With reference back to FIG. 13, a configuration 513-1 for contact content type of a particular content node (e.g., user device B 513) may require a contact to include a phone number. For example, some mobile phones only allow a contact including a phone number. Alternately, a user may only want contacts with phone numbers on the user's device. If such a flag is set, all contacts without a phone number will not be routed to this content node. A flag may indicate that phone numbers must be digits only without other ASCII characters. In this case, a repository may be used as described below to hold an unfiltered version of a ASCII filled phone number while the content router will prepare a contact include a digit-only phone number.
  • A configuration 513-2 for event content type of a particular content node may allow only events occurring within the next two weeks (or other set future duration) to be routed to the content node. Therefore, if one content node sends a new event to the content router, the content router will determine if this event will occur within the predetermined future time. If the flag and duration indicate that the event falls outside the parameters, the content router will not route the event to this content node. Additionally, a content router may include an inventory as described below that may be periodically reviewed to determine if an event falls within the duration and may be retrieved from one content node and sent to this content node. Another flag may indicate that all attachments will be removed from an event before forwarding to this content node. Another flag may indicate that all notes will be removed from an event before forwarding to this content node.
  • Similarly, a configuration 513-3 for to-do task content type of a particular content node may allow only tasks due within the next two weeks (or other set future duration) to be routed to the content node.
  • A configuration 513-4 for email is shown to include routing parameters used in routing rules and transformation parameters used in transformation rules. Routing rules may be used by the processing logic 250 to select a set of destination content nodes. The set may be a null set, whereby no content nodes are selected for receipt of an outgoing command. Alternatively, the set may indicate one or more destination content nodes that may receive an outgoing command. Routing rules include the capability of a content node to receive a particular content type, or an upper limit on a number of elements allowed on a content node. For example, a routing rule may be to bar any commands to a device that will increase the number of unread or read emails. A routing parameter may be a flag indication if the content node is or is not accepting commands. For example, if the content node's email box is full, the flag may be set to block sending of additional emails. A routing parameter may indicate the maximum size of an acceptable input. For example, if a content node is a mobile phone with limited memory, the routing parameter may be used to block all email messages greater that a particular size (e.g., greater than 1 kilobyte). A routing parameter may indicate that the content router should block all commands destined to the content node if the connection speed is below a predetermined rate or if the connection type does not provide a high transfer rate. For example, routing parameter may indicate that a content node, such as a mobile phone, will not receive email messages with attachments if the mobile phone is not connected with a wired connection.
  • For each selected destination content node, the processing logic 250 may generate an outgoing command. The processing logic 250 may use transformation parameters when processing transformation rules. Transformation rules may be used to determine the contents of the generated outgoing command. For example, a transformation parameter may be a maximum size value used to truncate commands to a maximum size (e.g., limiting the size to less than 1 kilobyte). A transformation parameter may be a flag used to determine whether a particular content type should be cut from the command. For example, a flag may be used to indicate that the content node only accepts attachments that are image files. A transformation parameter may be a flag used to block all attachments. For example, a flag may be used to indicate that the content node does not accept attachments that are document files. A transformation parameter may indicate that the content router should remove all attachments if the connection speed is below a predetermined rate or if the connection type does not provide a high transfer rate. For example, transformation parameter may indicate that a content node, such as a mobile phone, accepts email messages with the attachments if the mobile phone is connected with a wired connection but indicates that the attachments may be stripped off if the mobile phone is connected with a wireless connection. A transformation parameter may be a flag used to block all attachments if the content node if approaching a full state. For example, a flag may be used to indicate that the content node does not accept attachments when the content node is nearly full (e.g., 90% full). The content node may strip attachments from emails thereby preserving free memory on the content node.
  • A configuration 513-5 for library item content type of a particular content node may allow only images to be routed to the content node. Another flag may be used to filter audio files. Additionally, another flag may be used to filter movie files.
  • FIGS. 12A to 12E illustrate external and internal logic, which may be used to interface a content router 200 to user devices 310 and user accounts 320 according to embodiments of the present invention. A content routing system may include the store and forward logic 210. A content routing system may also translation logic such as include protocol logic 260 and/or protocol interface logic. Additionally, a content routing system may include a gateway such as a device gateway and/or a server gateway. Alternatively, the gateway may be external to the content routing system.
  • FIG. 12A illustrates a content router 200 coupled to an external protocol interface logic 260 and including a connected data set configuration 500 and store and forward logic 210 coupled to a command interface of protocol interface logic 260. The protocol interface logic 260 may be used to couple the store and forward logic 210 with various content nodes types such as user devices 310-1 to 310-3 and user accounts 320-1 to 320-3 using interfaces having disparate protocols.
  • In the embodiment shown, the protocol interface logic 260 translates between a protocol used by a content node 310, 320 and commands 400 processed in the store and forward logic 210. Specifically, the protocol interface logic 260 receives messages 910-1 to 910-3 and 920-1 to 920-3 based on a specific content node protocol used to communicate with the content node 310-1 to 310-3 and user accounts 320-1 to 320-3. The protocol interface logic 260 converts these signals to commands 400 for the store and forward logic 210. The protocol interface logic 260 also receives commands 400 from the store and forward logic 210 and converts these commands back to messages 910-1 to 910-3 and 920-1 to 920-3 tailored for the specific content node 310-1 to 310-3 and 320-1 to 320-3.
  • As described above, a content router 200 couples to a command interface of the protocol interface logic 260. As described below, the content router 200 couples to a message interface of protocol interface logic 260.
  • FIG. 12B shows a content router 200 including store and forward logic 210 and a protocol adapter 268 translating between messages 801 and commands 400. The protocol interface logic 260 including a device gateway 264 translating between messages 910 from a user device and messages from the content router 200. The device gateway 264 couples the content router 200 with user devices utilizing various protocols. The various user devices and protocols may include a mobile phone running a SyncML protocol or an SMS based protocol, a Java™ based client device running a binary protocol, a home personal computer based client running HTTP protocol, or the like.
  • The device gateway 264 performs a function of translating between various protocols used by the different user device types and a common protocol, such as a XML-RPC (extensible Markup Language-Remote Procedure Calling) protocol, used by the content router 200. A common protocol allows for easier scalability when additional gateways also using the common protocol are coupled to the content router 200. Furthermore, using a common protocol decouples the function of device protocol conversion from the protocol adapter 268 as well as from the store and forward logic 210.
  • In addition to translating protocols, the device gateway 264 models a server to support a client-server relationship from the point of view of the user device 310, which acts as a client. The device gateway 264 also models a client to support a client-server relationship from the point of view of the store and forward logic 210, which acts as a server.
  • In an alternative embodiment, the protocol adapter 268 is separate from the content router 200. The protocol adapter 268 may be part of the protocol interface logic 260 or may be standalone.
  • Some user devices 310 may include a user interface application unaware of the content router 200. For these user devices 310, the user device 310 may include a data routing driver knowledgeable of the content router 200 and which interfaces with the user interface application. The data routing driver uses an available protocol to communicate with the content router 200 thereby coupling the user application with the content router 200. Commands received over the available protocol are translated into instructions for the user application. Additionally, changes made within the application are communicated as messages sent over the available protocol to the content router 200.
  • Some user devices 310 may include both a data routing driver and an application knowledgeable of the content router 200. Other user devices 310, such as a SyncML-enabled mobile phone, may not need a data routing driver knowledgeable of the content router 200 because of capabilities inherent in such devices. For example, a SyncML-enabled mobile phone inherently includes over-the-air SyncML synchronization routines invokeable by the content router 200. Therefore, the content router 200 may push changes to the SyncML-enabled mobile phone without requiring content router knowledgeable software on the user device 310.
  • FIG. 12C shows a content router 200 including store and forward logic 210 and a protocol adapter 268 translating between messages 801 and commands 400. The protocol interface logic 260 including a server gateway 266, which translates between messages 920 from a user account and messages having a common protocol for use in the content router 200. The server gateway 266 couples the content router 200 with user accounts utilizing various protocols.
  • The server gateway 266 allows access to the content router 200 by user accounts communicating according to various server protocols such as HTTP XML, J DAV, Web DAV Exchange, IMAP, POP3, or the like. The server may include a PIM server, such as a Yahoo!® PIM server, a photo server, such as a Yahoo!® Photos server, an email server, such as a PacBell email server, or the like. For example, a content node 320 may be a user's email account on an email server using an IMAP protocol to communicate to the content router 200.
  • Similar to the device gateway 264, the server gateway 266 models a client to the store and forward logic 210. Unlike the device gateway 264, which models an intermediary between a client and a server, the server gateway 266 models an intermediary between two servers. Typically, two servers do not communicated in a client-server relationship. The server gateway 266, however, allows the account server to communicate with the store and forward logic 210 server, both acting as servers in a client-server relationship. To facilitate this communication, the server gateway 266 models a client to support a client-server relationship from the point of view of the user account 320 and models a client from the point of view of the store and forward logic 210.
  • As described above, the protocol interface logic 260 is positioned externally from the content router 200. As described below, the content route 200 includes the protocol interface logic 260
  • FIG. 12D shows a content router 200 containing store and forward logic 210, a protocol adapter 268, and protocol interface logic 260 including a device gateway 264 and a server gateway 266. As described above, the device gateway 264 and a server gateway 266 translate between protocols used by devices and servers and a common protocol, such as an XML-RPC protocol. The protocol adapter 268 translates between the common protocol and commands 400 used to communicate with the store and forward logic 210. Commands 400 sent between the store and forward logic 210 and the protocol adapter 268 may be in a request-response scheme such as in a Java™ platform including a Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) technology interface. A Java RMI platform allows an object running on a Java enabled content node to invoke methods on an object running in a Java based store and forward logic 210 and vise versa. Furthermore, the content router 200 may configure the device gateway 264 and/or the server gateway 266 with one or more of the routing parameters and/or one or more of the transformation parameters, such that the gateway may perform routing and transformations on commands of a content node.
  • The device gateway 264 is shown coupling the protocol adapter 268 to a mobile phone 310-1 running a SyncML protocol 910-1 and a Java™ based client device 310-2 operating with a binary protocol 910-2. The server gateway 266 is shown coupling the protocol adapter 268 to a PIM server 320-1, a photo server 320-2, and an email server 320-3 with protocols 920-1, 920-2, and 920-3, respectively.
  • A common protocol, such as XML-RPC, allows applications running on disparate operating systems and in different environments to make remote procedure calls using HTTP as a transport layer and XML as an encoding scheme. The XML-RPC protocol allows complex data structures to be transmitted from an application running on the device gateway 264, the server gateway 266, an XML-RPC-enabled device, or an XML-RPC-enabled server to the protocol adapter 268 and the store and forward logic 210. The protocol adapter 268 or the store and forward logic 210 may process the received data structure and return a result to the application.
  • Content nodes having the capability to communicate using the common protocol may bypass the gateway and may communicate directly with the protocol adapter 268. For example, a Symbian device or a WinCE, Win32 or home personal computer (PC) 310-3 running a client application may communicate directly with the protocol adapter 268 and avoids the device gateway 264 since the PC 310-3 already employs the common protocol. Additionally, a smart phone 310-4 may also communicate using the common protocol and avoid the device gateway 264. Similarly, user accounts may use the common protocol thereby bypassing the server gateway 266 to communicate with the protocol adapter 268. As shown, a Yahoo!® server 320-4 uses the common protocol thereby avoiding the server gateway 266. In some embodiments, a content node communicates with commands 400 directly (not shown), and thus may avoid using a protocol adapter 268.
  • By using a common protocol, the protocol adapter 268 may treat messages 801 from device gateway 264, messages 803 from a server gateway 266, messages 810-3, 810-4 from user devices 310-3, 310-4 and messages 820-4 from user accounts 320-4 similarly, thereby simplifying the design and implementation of the protocol adapter 268. Therefore, incoming messages in the common protocol are treated similarly regardless of input path to the protocol adapter 268. As a result, the store and forward logic 210 may treat commands from each content node similarly.
  • The content router 200 may also include a notification signal (dotted line) sent from the store and forward logic 210 to a device and/or server gateway 264, 266 as shown in FIG. 12D. If an outgoing command is waiting in the outgoing queue 241, the store and forward logic 210 may periodically send a notification signal (dotted lines) to the appropriate gateway 264, 266. A notification may be send from the store and forward logic 210 to the gateway 264, 266 using telnet, HTTP, a custom API, or the like. The gateway 264, 266 then may initiate a request for the outgoing command or commands 400 from the store and forward logic 210. The gateway 264, 266 may receive a response including the command from the outgoing queue 241.
  • In some embodiment, after a gateway 264, 266 receives a notification signal and fetches an outgoing command, the gateway prepares an outgoing notification message containing the command. If the outgoing command is relatively small in size, the gateway 264, 266 may include the command within the notification.
  • According to some embodiments, the store and forward logic 210 determines that a notification may be sent to a content node 300 to inform the content node 300 that the outgoing queue may contain an outgoing command. The store and forward logic 210 generates a notification signal for a gateway 264, 266. The gateway 264, 266 receives a notification signal from the store and forward logic 210. The notification signal may indicate availability of an outgoing command in the outgoing queue 241 for a content node 300. In response to receiving the notification signal, the gateway 264, 266 may request the outgoing command, for example, by a call to the protocol adapter 268. The protocol adapter 268 retrieves the command from the store and forward logic 210, which provides it to the gateway 264, 266. The gateway 264, 266 receives the response containing the outgoing command. The gateway 264, 266 prepares an outgoing notification containing the outgoing command. The gateway 264, 266 may encode the outgoing command into a compact binary sequence. The gateway 264, 266 then sends the outgoing notification to the content node 300, which may be either a user device 310 such as a mobile phone or a user account 320 such as an email account. For example, a device gateway 264 may send the outgoing notification to a mobile phone by way of an SMS gateway. The gateway 264, 266 may send an acknowledge that the outgoing notification to the store and forward logic 210 via the protocol adapter 268.
  • FIG. 12E shows a multi-server content routing system according to embodiments of the present invention. The content router 200 operates as a first server. The content router 200 includes store and forward logic 210 and a protocol adapter 268, which may communicate internally via a command based exchange, such as with RMI-IIOP, and externally via a common protocol, such as XML-RPC. The content router 200 may also include a connected data set configuration 500 and/or a repository 600 and/or a file relay server 700 either internally to or externally from the content router 200. Furthermore, the command memory 220, the connected data set configuration 500, the repository 600, and the file relay server 700 may each be formed in separate memory, combined in a common memory, or formed in a combination of separate and combined memory. For example, the command memory 220, the connected data set configuration 500, the repository 600, and the file relay server 700 may each be formed in separate databases, such as separate relational databases, or two or more may be combined a combined database.
  • The content routing system also includes servers to communicate to content nodes. A device gateway (server) 264 interfaces to user devices 310 using device specific protocols 910. A server gateway (server) 266 interfaces to user accounts 320 using server specific protocols 920.
  • Some embodiments of the present inventions include or are coupled to a file relay server 700. The file relay server 700 acts as a file relay memory and may be coupled to one or more of the servers and/or content router 200 (direct connection not shown in figure) and/or one or more of the content nodes.
  • The file relay server 700 facilitates transportation of commands having separable segments among a plurality of content nodes comprising detaching the segments prior to the commands being saved to a command memory of a store and forward logic. The file relay server 700 may provide an input for a content node 310, 320, a server 264, 266, or a content router 200 (a protocol adapter 268 or a store and forward logic 210) to store one or more files so that the files may be removed from incoming commands before the incoming command is stored in the command memory 220 of the store and forward logic 210. By removing separable segments, especially large files, the command memory is capable of holding a larger number of commands and may be more agile in processing commands. The file relay server 700 may also provide a mechanism for routing file from and to a content node behind a firewall. Two content nodes 300 separated by a firewall may not permission to access content, such as a file, and metadata from the other. However, if both content nodes 300 are able to provide the content and/or metadata to the file relay server 700 either directly or indirectly through a server 264, 266, a content router 200, a protocol adapter 268, or a store and forward logic 210, the content nodes 300 may, in effect, exchange the content and/or metadata. Additionally, in some embodiments, a file is encrypted by the content node 310,320, a server 264, 266, a content router 200, a protocol adapter 268, or a store and forward logic 210 before it is saved to the file relay server 700. In some embodiments, a security mechanism is implemented so that a file provided by one content node are only available to other content nodes connected to the same user, for example, as configured in the connected data set configuration for that users. A security mechanism may include authentication of each request for a file from the file relay server 700, as well encryption of the received and delivered files.
  • The multi-server content routing system may use the file relay server 700 to provide a path for a content node to receive an attachment when a peer-to-peer 450 connection, as shown in FIG. 5, is not desirable or not possible. A peer-to-peer 450 connection may not be possible when one or both of the content nodes are behind firewalls that block peer-to-peer connections. Additionally, a peer-to-peer 450 connection may not be possible when each content node is not simultaneously connected to the network 10. The file relay server 700 may provide a temporary repository for attachments or other segments of a command.
  • The file relay server 700 may off load processing form the store and forward logic 210. For example, a source content node, a device gateway or a protocol adapter may cut a detachable segment from an incoming command or message, such as a large file from an email. A reference to the stored segment on the file relay server 700 may be positioned in place of the removed segment in the incoming command. The content router 200 and connected content nodes 300 may process a reference to a file residing on the file relay server 700 in a similar manner as a reference back to a file residing on the source content node 300. The resulting abridged incoming command may then be sent to the store and forward logic 210 and may be significantly smaller by the removal or replacement with a reference of a large segment. At some subsequent time, an outgoing command corresponding to the abridged incoming command may pass out from the store and forward logic 210. The protocol adapter, device gateway or a destination content node may detect the reference and replace the reference with the segment retrieved from the file relay server 700. In this way, the command memory 220 may be spared the task of holding large files.
  • In a first scenario, a stand alone file relay server 700 is used. First, a new email including an attachment is received via the Internet by a user's corporate email account. The user account communicates a change, that is, the arrival of the new email to the content router 200. The store and forward logic 210 receives an incoming command containing the email, however, the content node 300 replaced the attachment in the email with a metadata link identifying the location of the attachment on the corporate server. If the email account is behind a firewall, other connected content nodes may not be able to access a metadata link to the attachment. In this case, the store and forward logic 210 may forward the metadata link to the protocol interface logic 260 and may instruct the protocol interface logic 260 to fetch the attachment based on the metadata link. The protocol interface logic 260 directs the fetched attachment to the file relay server 700. When generating outgoing commands in response to the incoming command, the store and forward logic 210 replaces the metadata link identifying the corporate server as the source of the attachment with a link locating the attachment on the file relay server 700. A content node receiving the outgoing command will be referred to the file relay server 700 rather than to an inaccessible server.
  • In a second scenario, a public email server is used as the file relay server 700. As was described above, a new email including an attachment is received via the Internet by a user's corporate email account. The user account communicates the arrival of the new email to the store and forward logic 210 with a reference to the attachment rather than the attachment itself. The store and forward logic 210 instructs the protocol interface logic 260 to fetch the attachment based on the reference. In this scenario, the protocol interface logic 260 directs the attachment to a command destined for the public email server. The store and forward logic 210 then generates commands to each of the other connected content nodes with a metadata link directing a user to the public email server rather than the corporate email server. In this way, a content node may have access to an attachment that originated on an email server inaccessible to the content node.
  • In another scenario, a first content node sends an incoming command including an embedded attachment to the content router 200. The gateway 264 or 266 removes the attachment from the command and saves the attachment to the file relay server 700. The gateway may remove all attachments or alternately particular attachment types. The gateway may base the decision to remove one or more attachments base on one or more configuration parameters, which may be specific to a content node, a content node type and/or a user's connected data set configuration. The gateway may replace the attachment with a reference, which may allow a gateway or a content node itself to retrieve the attachment from the file relay server 700. Alternatively, the protocol adapter 268 or the store and forward logic 210 may swap the attachment and a reference in the command and store to and/or retrieve the attachment from the file relay server 700.
  • In some embodiments, the content node 310 or 320 interfaces with the file relay server 700. For example, if a user account 320 receives an email with an attached file from the Internet, it may forward the email to the content router 200 as a command to add a new email containing a file. Alternatively, the user account 320 may detach then forward the file to the file relay server 700. The content node 320 then generates and sends a command with the email having the attachment replaced with a reference to the file on the file relay server 700. When a destination content node, for example, user device 310, receives an outgoing command with the reference, the content node 310 may automatically retrieve the file from the file relay serer 700 and replace the reference with the retrieved file to restore the original email. Alternatively, the content node 310 may allow the user to manually fetch the file by following the reference to the file relay server 700.
  • In some embodiments, the gateways 264, 266 interfaces with the file relay server 700. For example, if a gateway 264, 266 receives an incoming command from a source content node 310 or 320 to add a new email containing an attached file, the gateway 264, 266 receiving the incoming command may forward the file to the file relay server 700 then substitute the file in the command with a reference to the file on the file relay server 700. At some later point in time when an outgoing command that contains the reference is sent towards a destination content node, the server 264, 266 receiving command from the content router 200 may restore the email by replacing the reference with the file extracted from the file relay server 700.
  • In some embodiments, the protocol adapter 268 interfaces (not shown) with the file relay server 700. For example, if the protocol adapter 268 receives an incoming command from a source content node 310, 320 to add a new email containing a file, the protocol adapter 268 may forward the file to the file relay server 700. The protocol adapter 268 then replaces the attached file with a reference to the file on the file relay server 700. When a destination content node 310, 320 requests an outgoing command that contains the reference, the protocol adapter 268 may replace the reference with the file extracted from the file relay server 700.
  • In some embodiments, the store and forward logic 210 interfaces (not shown) with the file relay server 700. For example, if the store and forward logic 210 receives an incoming command from a source content node 310, 320 to add a new email containing a file, the store and forward logic 210 may forward the file to the file relay server 700. The store and forward logic 210 then replaces the file in the command with a reference to the file on the file relay server 700. When the store and forward logic 210 retrieves an outgoing command that contains the reference, it may replace the reference with the file extracted from the file relay server 700.
  • FIGS. 13 and 14A to 14I show structures of various commands according to embodiments of the present invention.
  • FIG. 13 shows a command associated with a primary key and database identifier according to embodiments of the present invention. The term command includes notifications and messages (which need not necessarily be in a “command” format) of such changes that may be acted upon accordingly by a receiver of the notifications and messages, such as content node. In some embodiments, a command includes a primary key that is a monotonically increasing value assigned by the processing logic 250 to each incoming command. The primary key is unique for all commands associated with a user. The primary key may also be unique for all commands associated with all users. In some embodiments, a time stamp may be used as the primary key.
  • A command is also associated with a database identifier. The database identifier may be used as an index or key into a database including commands from multiple users and multiple content nodes. The database identifier may be a sequentially increasing number assigned by the database for each content node and content type being added to the database. Therefore, the database identifier may specifically identify, either indirectly or directly, a particular user, a particular content node or content node type, and a particular content type. A content node identifier may include an identifier to a particular user device or user account. A content type may include an indication of one of a Contact item, an Event item, a ToDo item, an Email item, or a Library item. The Library item may be used to indicate one of ConnectedPhoto metadata, ConnectedDocuments metadata, or ConnectedMusic metadata.
  • A command may also be associated with a queue identifier indicating whether the command may be considered to reside in an incoming queue 231, an incoming in-transit queue 232, an outgoing queue 241, or an outgoing in-transit queue 242. The command may be stored as an entry into a database, such as a SQL database, with associated attributes including the primary key, the database identifier and the queue identifier.
  • A command may contain a command type and a payload. The payload may include the content itself. Alternatively, the payload may include metadata, or may include both the content and metadata. Metadata provides information concerning the quality, condition, and other characteristics of the content. Metadata may include information such as a description of the content, an indication of a change to the content, and/or a reference or link to a source of the content.
  • The command type indicates an action taken or requested. In some embodiments, the command type indicates one of a list of actions including: add, update, delete, get, get-results, query, query-result, query-end and clear. For incoming commands, the command type indicates a change that has occurred. For example, a command received with an add command type means that content was added to the content node. For outgoing commands, the command type indicates a change that the content router is requesting to occur on a content node in order to keep the content node synchronized with a content node where a change was made. For example, an add command type means that the content specified in the payload should be added to the content node.
  • A command having a command type of add indicates an action of adding a content record to a content node. Payload for an add-command type may include the content itself, metadata about the content and/or a reference to the content.
  • A command having a command type of delete indicates an action of deleting a content record from a content node. Payload for a delete-command type may include metadata indicating which content and/or metadata about the content to delete.
  • A command having a command type of get indicates a request for getting the contents of a record from a content node. Payload for a get-command type may include metadata indicating which content and/or metadata about the content to get. A command having a command type of get-result is a command sent in response to a get-command type. Payload for a get-result type may include the content itself, metadata about the content and/or a reference to the content.
  • A command having a command type of query indicates a request for a category of content from a content node. Payload for a query-command type indicates the category of content being requested. The query-command type may be used to request all content on a content node, or all content having particular characteristics. A command having a command type of query-result indicates a response to a query-command type. Payload for a query-result-command type includes the requested content or metadata about the content. The query-result-commands may be sent by the content node 300 in multiple batches; therefore the content router 200 may need to given an indication of when the query results flow has finished. The final response to a query-command type is indicated in a command having a command type of query-end. The Payload for a query-end-command type may be either the final content having the particular characteristic or a null thereby indicated an empty set response. If no results are found, a query-command type results in a query-end-command type indicating a null response. If a single result is found, a query-command type results in a query-end-command type indicating a matching response. If more than one result is found, a query-command type results in one or more query-result-command types followed by a query-end-command type containing the final match.
  • A command having a command type of clear instructs a content node to remove a category of content indicated by the payload. A command having a command type of refresh instructs the content router 200 to recover the sending content node. Depending on the content node capabilities and the user configuration in the connected data set configuration, recovering may be initiated by either sending the content node 300 a clear command to clear its content or a query command to import all its data. In either case, the content node 300 may receive a consolidated content and metadata from one or more of the other content nodes, such that the content node 300 may be in-synch with connected content nodes.
  • The command also includes a data payload having a format dependent on the command type and data type. The data payload may contain a changed record or may contain metadata such as a link or reference to the changed record located at the data source or at a file relay server.
  • FIG. 14A shows a new email to be added to a content node. The data payload includes an email ID used to uniquely identify an email, a header, the first 2 kilobytes of the message and a link to the original message. FIG. 14B shows a command to instruct content nodes that an email has been read. FIG. 14C shows a command to delete a particular email.
  • FIG. 14D shows a command to add a new audio file. FIG. 14E shows a command to delete an audio file. FIG. 14F shows a command to add a new appointment. FIG. 14G shows a command to add a new contact where the command contains the record. FIG. 14H shows a command to update a new contact where the command also contains the record. FIG. 14I shows a command to add a photo image. The photo itself is not included in the command but a reference to the original photo image may be included.
  • FIGS. 15A to 15C illustrate sequence diagrams showing signaling between a user device 310 and store and forward logic 210 according to embodiments of the present invention.
  • FIG. 15A shows a sequence when a user device 310 pushes one or more commands to a content router 200. A user device 310, such as a mobile PC with wireless capabilities, may undergo a series of changes to content and metadata on the user device 310. An application running on the user device 310 may periodically prepare a payload indicating the changes made during the period or may send commands when it regains wireless communications. Using a protocol available to the user device 310, the application prepares a REQUEST message to put a payload containing a list of commands. For example, a user may have received a new SMS message AAA. Therefore, the application may generate a command indicating that connected content nodes may add a new email AAA. Additionally, the user may have deleted an event BBB from a calendar and updated a contact CCC with a work phone number. In some embodiments, a batch of commands is limited to include only commands operating on a common command type. For example, a batch of commands may include only commands add, delete or modify email messages.
  • Those skilled in the art will recognize that a user device 310 may use various protocols to communication with the device gateway 264. Therefore, the REQUEST-RESPONSE protocol shown here is just one possibility. According to embodiments of the invention, each REQUEST-RESPONSE is an atomic pair of commands, where both commands must occur otherwise neither is considered successful. Unlike other protocols requiring multiple REQUEST-RESPONSE pairs, each REQUEST-RESPONSE pair according to the present invention may make progress in performing a task. For a wireless network, a long sequence of pairs of commands has a greater probability of incurring and interruption. Therefore, the single REQUEST-RESPONSE atomic pair provides optimal reliability and through put.
  • The user device 310 sends the REQUEST to put commands contained in its payload to a device gateway 264, which models a server to the user device 310. In modeling a server, the device gateway 264 acts on and responds to requests. The device gateway 264 translates from the device protocol to the internally used protocol, and then sends to the protocol adapter 268 a REQUEST indicating a put of the commands indicated in the payload. Alternatively, if the user device 310 was enabled to communicate using the internal protocol, the device gateway 264 may be bypassed.
  • The protocol adapter 268 converts the payload of the REQUEST to a sequence of commands (e.g., add, delete and update) and sends (puts) the commands to the store and forward logic 210 for the store and forward logic 210 to process. The store and forward logic 210 may assign a monotonically increasing primary key (e.g., 0010021, 0010022 and 0010023) to each command for internal use. Furthermore for each command, the store and forward logic 210 may determine a database ID, which may uniquely identify a user, a particular content node, and a content type. The store and forward logic 210 may also set the queue ID for each command to indicate that the command is an incoming or outgoing command that is pending execution or pending acknowledgement of successful execution. The store and forward logic 210 may perform a conflict check against each of the commands associated with the same database ID. If no conflicts are detected, the commands may be stored in the database with the assigned attributes. If a conflict is detected, the store and forward logic 210 resolves the conflict by removing a command existing in the database, discarding the incoming conflicting command, and/or aggregating the incoming command and the existing command.
  • In response to successful processing and entry into the incoming queue, the store and forward logic 210 returns an indication of the success to the protocol adapter 268. The protocol adapter 268 in turn responds to the REQUEST from the device gateway 264 with a RESPONSE that indicates successful forwarding of all of the commands received in the REQUEST. Likewise, the successful processing of the REQUEST from the user device 310 is acknowledged with a RESPONSE indicating the success as shown. A user device 310 receiving the RESPONSE indicating a success may discard the payload of commands sent earlier. If the user device 310 fails to receive this acknowledgement, it may resend the payload of commands in a subsequent REQUEST.
  • In accordance with embodiments of the present invention, a user device 310 completes a transaction with the content router 200 with a single REQUEST-RESPONSE exchange as shown. A single REQUEST-RESPONSE exchange reduces the change of an error interrupting a session as would occur if a protocol required multiple REQUEST-RESPONSE exchanges to complete a transaction. Each request and response pair is designed to make progress, unlike multi-pair protocols. In a multi-pair protocol, if a failure occurs midstream all progress is lost and the entire session must be restarted from the beginning. Therefore, in accordance with embodiments of the present invention, each successful single REQUEST-RESPONSE exchange makes progress towards completing a task of synchronizing content nodes and any failure effects only the single REQUEST-RESPONSE exchange.
  • FIG. 15B shows a sequence when a user device 310 requests (pulls) commands from a content router 200 after a notification is received. Once the store and forward logic 210 generates and stores a new outgoing command in the outgoing queue 24 1, the store and forward logic 210 may generate a notification signal to instruct the device gateway 264 to send a notification to the user device 310. The notification may or may not include an indication of content type. The device gateway 264 may collect a series of notifications destined for a content node and may periodically send the collected notifications to the user device 310, for example, using an HTTP packet, if available, or an SMS message. Notifications may be sent with little delay if a user device 310 is connected to the network 10 with a cost free channel or a channel of negligible cost, such as if it is docked to a wired internet connection. Notifications may be collected and send at frequent intervals if the user device 310 is connected with an inexpensive channel, such as with a GPRS connection. Notifications may be collected and sent infrequently if user device 310 is connected with an expensive channel, such as a SMS connection. In some embodiments, the content routing system keeps a flag updated to indicate a current connection type, thereby providing a variable the content routing system may use when determining a frequency of updating a content node.
  • After receiving the notification, the user device 310 may begin a single REQUEST-RESPONSE session to get a content type of pending commands. The user device 310 sends the device gateway 264 a REQUEST to get content type of the pending commands. The device gateway 264 replies with a RESPONSE to the REQUEST including an indication of the content type of the pending command.
  • After receiving the content type, the user device 310 may begin a single REQUEST-RESPONSE session to get a single command or batch of pending commands. The user device 310 sends the device gateway 264 a REQUEST to get pending commands. The device gateway 264 converts the REQUEST from the external protocol used by the user device 320 to a common internal protocol. The device gateway 264 sends the REQUEST in the common protocol to the protocol adapter 268. The protocol adapter 268 converts the REQUEST to a call to get commands from the outgoing queue 241. The store and forward logic 210 returns a payload containing a batch of commands from the outgoing queue 241. Alternatively, the store and forward logic 210 may return a single command at a time, which the protocol adapter 268 may combine to form a batch of commands. The protocol adapter 268 may associated an index to indicate the number of commands in the payload. The protocol adapter 268 replies to the REQUEST received from the device gateway 264 with a RESPONSE containing the payload of commands to be executed by the user device 310. Alternatively, the protocol adapter 268 may reply with a single command at a time in each response. The device gateway 264 forwards the RESPONSE as a RESPONSE to the REQUEST originally received from the user device 310.
  • Some time after the initial REQUEST-RESPONSE exchange, the user device 310 begins a second REQUEST-RESPONSE exchange to acknowledge successful processing of the commands. The device gateway 264 forwards this acknowledgement to the protocol adapter 268, which make a call to remove commands from the in-transit queue 242 in the store and forward logic 210. The store and forward logic 210 returns a success. The protocol adapter 268 replies to the REQUEST with a RESPONSE acknowledging the success. The device gateway 264 then replies to the REQUEST from the user device 310 with a RESPONSE acknowledging the success.
  • FIG. 15C shows a sequence of events when a content router 200 pushes a command within a notification to a user device 310. In some embodiments, the store and forward logic 210 includes a low priority and/or relatively small payload within a notification. For example, the fact that an email has been read may be considered a low priority and small byte sized event. Such low priority events may be communicated with a notification layer without the necessity of receiving an acknowledgement typically required in a REQUEST-RESPONSE exchange. For example, the store and forward logic 210 may send a payload including a flag showing that content GGG was modified. Command GGG may represent an email flag used to indicate that an email has changed from an unread state to a read state. The payload may also contain an indicator used to identify the particular email. Once the notification signal is received, the communication between the device gateway 264, the protocol adapter 268 and the store and forward logic 210 operate as described above with reference to FIG. 15B. Eventually, the device gateway 264 sends a notification including the command to the user device 310.
  • FIGS. 16A to 16D illustrate sequence diagrams showing signaling between a user account 320 and store and forward logic 210 according to embodiments of the present invention.
  • FIG. 16A shows a sequence when a content router 200 receives (gets) commands from a user account 320. A server gateway 266 may periodically poll the user account 320 with a single REQUEST-RESPONSE exchange. If not changes exist, the user account 320 may send a RESPONSE indicated such. If a change exists, the user account 320 may send a RESPONSE indicated the change (not shown). Alternatively, some user accounts 320 may initiate a REQUEST-RESPONSE exchange to indicate that a change exists. The server gateway 266 acknowledges that the REQUEST was received with a RESPONSE including an acknowledgement. In either case, once the server gateway 266 knows that one or more changes exists, the server gateway 266 sends a REQUEST requesting the changes. The user account replies in a RESPONSE with a payload containing a list commands.
  • The server gateway 266 translates from the server protocol to the common internally used protocol, and then sends to the protocol adapter 268 a REQUEST indicating a put of the commands indicated in the payload. Alternatively, if the user account 320 was enabled to communicate using the common protocol, the server gateway 266 may be bypassed.
  • The protocol adapter 268 converts the payload of the REQUEST to a sequence of commands (e.g., add, delete and update) and provides the commands to the store and forward logic 210. The store and forward logic 210 processes each command. The store and forward logic 210 may assign a monotonically increasing primary key (e.g., 0030021, 0030022 and 0030023) to each command. Furthermore for each command, the store and forward logic 210 may determine a database ID, which may uniquely identify a user, a particular content node, and a content type. The store and forward logic 210 may also set the queue ID for each command to indicate that the command is in an incoming queue state. The store and forward logic 210 may perform a conflict check against each of the commands associated with the same database ID. If no conflicts are detected, the commands may be stored in the database with the assigned attributes. If a conflict is detected, the store and forward logic 210 resolves the conflict by removing a command existing in the database, discarding the incoming conflicting command, and/or aggregating the incoming command and the existing command.
  • In response to successful processing and entry into the incoming queue, the store and forward logic 210 returns an indication of the success to the protocol adapter 268. The protocol adapter 268 in turn responds to the REQUEST from the server gateway 266 with a RESPONSE of success. If any REQUEST-RESPONSE exchange fails, previous REQUEST-RESPONSE exchange will not need to be repeated. In some embodiments, the server gateway 266 exchanges a REQUEST-RESPONSE pair (not shown) with the user account 320 to inform the user account 320 that it may discard the previously communicated commands.
  • FIG. 16B shows a sequence when a content router 200 pushes (puts) commands to a user account 320. When store and forward logic 210 has commands in its outgoing queue for a user account 320, it may send a notification signal to the server gateway 266. In some embodiments, the notification signal includes a content type. The server gateway 266 captures the notifications and models a client when sending a REQUEST to get pending outgoing commands. In modeling a client, the server gateway 266 initiates request on behave of the user account for the outgoing commands. The protocol adapter 268 performs a get-commands call to the store and forward logic 210, which returns with a payload of commands. For example, the payload of commands may include adding a new email DDD, deleting a contact EEE, and modifying a title of multimedia content FFF. The protocol adapter 268 may assign an index to each command and includes the commands in a RESPONSE to the previously received REQUEST. The server gateway 266 then models a client and initiates a REQUEST to put commands to the user account 320. The user account 320 acknowledges receipt of the REQUEST and commands with a RESPONSE. The server gateway 266 then initiates a REQUEST to acknowledge receipt of the commands by the user account 320. The protocol adapter converts the acknowledgement into a remove commands call to the store and forward logic 210 to remove commands from the in-transits queue. The store and forward logic 210 returns a success, and the protocol adapter 268 acknowledges the RESPONSE received from the server gateway 266 with a RESPONSE.
  • FIG. 16C shows a sequence of events when a server gateway 266 pushes a command in a notification message to a user account 320. In some embodiments, the store and forward logic 210 may include a low priority and/or relatively small payload with a notification. For example, the fact that an email has been read may be considered a low priority and small byte sized event. Such low priority events may be communicated with the notification layer without the necessity of receiving an acknowledgement typically required in a REQUEST-RESPONSE exchange. In some embodiments, the notification signal includes a content type. In response to receiving the initial notification signal, the server gateway 266 may model a client when sending a REQUEST to get pending outgoing commands. In response, the protocol adapter 268 performs a get-commands call to the store and forward logic 210, which returns with a command. For example, the command GGG may include an instruction to modifying a read state of an email. The protocol adapter 268 may assign an index to the command and includes the command in a RESPONSE to the previously received REQUEST. The server gateway 266 then pushes the command in a notification signal to the user account 320. Either before or after sending of the notification signal, the server gateway 266 may initiates a REQUEST to acknowledge receipt of the commands by the user account 320. The protocol adapter converts the acknowledgement into a remove command call to the store and forward logic 210 to remove the command from the in-transits queue. The store and forward logic 210 returns a success, and the protocol adapter 268 acknowledges the RESPONSE received from the server gateway 266 with a RESPONSE.
  • FIG. 16D shows an embodiment of the present invention with a server gateway 266 positioned behind a firewall along with an account server having a user account 320. If the server gateway 266 is behind a firewall, the protocol adapter 268 may be unable to initiate a REQUEST-RESPONSE exchange and a notification from the protocol adapter 268 would be blocked. In this case, the server gateway 266 may initiate each REQUEST-RESPONSE exchange.
  • Instead of receiving notifications to determine that the content router 200 has commands in its outgoing queue 241, the server gateway 266 may request the notification information by initiating a REQUEST-RESPONSE exchange. The server gateway 266 may periodically poll for commands in the outgoing queue 241 by sending the protocol adapter 268 a REQUEST indicating a poll for outgoing commands is requested. In response, the protocol adapter 268 calls the store and forward logic 210 to check for any outgoing commands for the user account 320. The store and forward logic 210 returns an indication of whether or not any commands exist in the outgoing queue 241. The protocol adapter 268 may respond to the previous REQUEST with a RESPONSE including the returned indication of whether or not any commands exist in the outgoing queue 241. If a command exists in the outgoing queue 241, the server gateway 266 may initiate a REQUEST to get the outgoing commands as shown in FIG. 16B (with a REQUEST-RESPONSE exchange) or as shown in FIG. 16C (within a notification signal). Additionally, the server gateway 266 may poll the user account 320 for changes if the user account 320 communicates commands to the server gateway 266, the server gateway 266 may initiate a REQUEST to put the commands to the incoming queue 231 as shown in FIG. 15A.
  • While the invention has been described in terms of particular embodiments and illustrative figures, those of ordinary skill in the art will recognize that the invention is not limited to the embodiments or figures described.
  • It will be appreciated that the above description for clarity has described embodiments of the invention with reference to different functional units. However, it will be apparent that any suitable distribution of functionality between different functional units may be used without detracting from the invention. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality rather than indicative of a strict logical or physical structure or organization.
  • The invention can be implemented in any suitable form including hardware, software, firmware or any combination of these. Different aspects of the invention may be implemented at least partly as computer software or firmware running on one or more data processors and/or digital signal processors. The invention may be implemented in a computer program product such as a machine readable medium (e.g., a memory card, ROM, RAM, PROM, EPROM, flash memory, magnetic or optical diskette, CD-ROM, DVD, and the like). The elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. As such, the invention may be implemented in a single unit or may be physically and functionally distributed between different units and processors.
  • Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the claims. Additionally, although a feature may appear to be described in connection with a particular embodiment, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. Moreover, aspects of the invention describe in connection with an embodiment may stand alone as an invention.
  • Moreover, it will be appreciated that various modifications and alterations may be made by those skilled in the art without departing from the spirit and scope of the invention. The invention is not to be limited by the foregoing illustrative details, but is to be defined according to the claims.

Claims (35)

1. A content routing system for routing changes to information between a plurality of content nodes, the content routing system comprising:
store and forward logic comprising logic for:
selecting a set of destination content nodes based on a content type of an incoming command and one or more routing parameters;
modifying the incoming command with data modulation logic operable to generate at least one outgoing command, wherein each outgoing command corresponds to a selected content node; and
a connected data set configuration, coupled to the processing logic, for holding the one or more routing parameters.
2. The content routing system of claim 1, wherein the data modulation logic comprises at least one data module for modifying at least one data field of the incoming data field.
3. The content routing system of claim 1, wherein the incoming command comprises an XML-tree data structure schema.
4. The content routing system of claim 3, wherein the data modulation logic is operable to modify a particular node of the XML-tree data structure.
5. The content routing system of claim 1, wherein the data modulation logic is operable to divide a first incoming command associated with a first content entry into multiple outgoing commands associated with second multiple content entries.
6. The content routing system of claim 5, wherein the data modulation logic is operable to maintain integrity between the first content entry and the second multiple content entries.
7. The content routing system of claim 1, wherein the data modulation logic is operable to merge multiple first incoming commands associated with first content entries into a smaller number of second commands associated with second content entries.
8. The content routing system of claim 7, wherein the data modulation logic is operable to maintain integrity between the first content entries and the second content entries.
9. The content routing system of claim 1, further comprising data consolidation logic operable to identify potential duplicate content entries based on comparing a hash-value of the incoming command to a list of hash-values.
10. The content routing system of claim 9, wherein the list of hash-values is generated from content associated with at least one content node.
11. The content routing system of claim 9, wherein the hash-value is determined from less than all content of the incoming command.
12. The content routing system of claim 9, wherein the hash-value is determined from at least one predefined significant property of the incoming command.
13. A method of routing changes to information between a plurality of content nodes and a command memory, the method comprising, at a content router:
receiving an incoming command from a first content node;
storing the incoming command in a command memory;
selecting a set of destination content nodes based on a content type of the incoming command and a routing parameter associated with the destination content node and the content type;
modulating the incoming command based on capabilities of the destination content node, wherein the modulating comprises modifying at least one data field of the incoming command to generate of an outgoing command.
14. The method of claim 13, wherein the incoming command comprises an XML-tree data structure schema.
15. The method of claim 14, wherein the field comprises a particular node of the XML-tree data structure.
16. The method of claim 13, further comprising dividing a first incoming command associated with a first content entry into multiple outgoing commands associated with second multiple content entries.
17. The method of claim 16, wherein integrity is maintained between the first content entry and the second multiple content entries.
18. The method of claim 13, further comprising merging multiple first incoming commands associated with first content entries into a smaller number of second commands associated with second content entries.
19. The method of claim 18, wherein integrity is maintained between the first content entries and the second content entries.
20. The method of claim 13, further comprising identifying potential duplicate content entries based on comparing a hash-value of the incoming command to a list of hash-values.
21. The method of claim 20, wherein the list of hash-values is generated from content associated with at least one content node.
22. The method of claim 20, wherein the hash-value is determined from less than all content of the incoming command.
23. The method of claim 20, wherein the hash-value is determined from at least one predefined significant property of the incoming command.
24. A computer program product comprising program code for use in a content routing system comprising processing logic and a command memory, the content routing system for routing changes to information between a plurality of content nodes and the command memory, the computer program product comprising:
program code for receiving an incoming command from a first content node;
program code for selecting a set of destination content nodes based on a content type of the incoming command and a routing parameter associated with the destination content node and the content type;
program code for modifying the incoming command to generate at least one outgoing command, wherein each outgoing command corresponds to a selected content node.
25. The computer program product of claim 24, further comprising program code for at least one data module for modifying at least one data field of the incoming command.
26. The computer program product of claim 25, wherein the incoming command comprises an XML-tree data structure schema.
27. The computer program product of claim 26, wherein the data modulation logic is operable to modify a particular node of the XML-tree data structure.
28. The computer program product of claim 24, wherein program code for modifying is operable to divide a first incoming command associated with a first content entry into multiple outgoing commands associated with second multiple content entries.
29. The computer program product of claim 28, wherein integrity is maintained between the first content entry and the second multiple content entries.
30. The computer program product of claim 24, wherein the program code for modifying is operable to merge multiple first incoming commands associated with first content entries into a relatively smaller number of second commands associated with second content entries.
31. The computer program product of claim 30, wherein integrity is maintained between the first content entries and the second content entries.
32. The computer program product of claim 24, further comprising data consolidation logic operable to identify potential duplicate content entries based on comparing a hash-value of the incoming command to a list of hash-values.
33. The computer program product of claim 32, wherein the list of hash-values is generated from content associated with at least one content node.
34. The computer program product of claim 32, wherein the hash-value is determined from less than all of the incoming command.
35. The computer program product of claim 32, where the hash-value is determined from at least one predefined significant property of the incoming command.
US11/264,121 2005-07-14 2005-10-31 Content router processing Abandoned US20070028000A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/264,121 US20070028000A1 (en) 2005-07-14 2005-10-31 Content router processing

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/182,287 US7849199B2 (en) 2005-07-14 2005-07-14 Content router
US11/264,121 US20070028000A1 (en) 2005-07-14 2005-10-31 Content router processing

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/182,287 Continuation-In-Part US7849199B2 (en) 2005-07-14 2005-07-14 Content router

Publications (1)

Publication Number Publication Date
US20070028000A1 true US20070028000A1 (en) 2007-02-01

Family

ID=37661574

Family Applications (3)

Application Number Title Priority Date Filing Date
US11/182,287 Active 2028-02-28 US7849199B2 (en) 2005-07-14 2005-07-14 Content router
US11/264,435 Abandoned US20070014278A1 (en) 2005-07-14 2005-10-31 Counter router core variants
US11/264,121 Abandoned US20070028000A1 (en) 2005-07-14 2005-10-31 Content router processing

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US11/182,287 Active 2028-02-28 US7849199B2 (en) 2005-07-14 2005-07-14 Content router
US11/264,435 Abandoned US20070014278A1 (en) 2005-07-14 2005-10-31 Counter router core variants

Country Status (6)

Country Link
US (3) US7849199B2 (en)
EP (1) EP1908256A2 (en)
JP (1) JP4881380B2 (en)
KR (1) KR101035472B1 (en)
CN (1) CN101317416A (en)
WO (1) WO2007011533A2 (en)

Cited By (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070014277A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router repository
US20070014243A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for provisioning a user device
US20070014303A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router
US20070016636A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Methods and systems for data transfer and notification mechanisms
US20070014307A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router forwarding
US20070014300A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router notification
US20070016632A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for synchronizing between a user device and a server in a communication network
US20070016676A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for servicing a user device
US20070028293A1 (en) * 2005-07-14 2007-02-01 Yahoo! Inc. Content router asynchronous exchange
US20070038703A1 (en) * 2005-07-14 2007-02-15 Yahoo! Inc. Content router gateway
US20070100856A1 (en) * 2005-10-21 2007-05-03 Yahoo! Inc. Account consolidation
US20070112880A1 (en) * 2005-11-14 2007-05-17 Lie Yang Data synchronization and device handling
US20070109592A1 (en) * 2005-11-15 2007-05-17 Parvathaneni Bhaskar A Data gateway
US20070195750A1 (en) * 2006-02-21 2007-08-23 Lehman Brothers Inc. System and method for network traffic splitting
US20070245006A1 (en) * 2006-04-18 2007-10-18 Nokia Corporation Apparatus, method and computer program product to provide ad hoc message recipient lists
US20080005263A1 (en) * 2006-06-28 2008-01-03 Nokia Corporation Method, Apparatus and Computer Program Product for Providing Automatic Delivery of Information to a Terminal
US20080034008A1 (en) * 2006-08-03 2008-02-07 Yahoo! Inc. User side database
US20080080392A1 (en) * 2006-09-29 2008-04-03 Qurio Holdings, Inc. Virtual peer for a content sharing system
US20080198422A1 (en) * 2007-02-19 2008-08-21 Tamara Lynne Casey Contextual Management of Multiple Device Capabilities in a Communication Device
US20080270629A1 (en) * 2007-04-27 2008-10-30 Yahoo! Inc. Data snychronization and device handling using sequence numbers
US20090030993A1 (en) * 2007-07-26 2009-01-29 Mxtoolbox Simultaneous synchronous split-domain email routing with conflict resolution
US20090182739A1 (en) * 2008-01-10 2009-07-16 Microsoft Corporation Using metadata to route documents
US20100153322A1 (en) * 2008-12-16 2010-06-17 Mandelbaum Yitzhak Method and apparatus for providing an adaptive parser
US7779157B2 (en) 2005-10-28 2010-08-17 Yahoo! Inc. Recovering a blade in scalable software blade architecture
US20100321999A1 (en) * 2009-06-23 2010-12-23 Samsung Electronics Co., Ltd. Nonvolatile memory device and related programming method
US7870288B2 (en) 2005-10-28 2011-01-11 Yahoo! Inc. Sharing data in scalable software blade architecture
US7873988B1 (en) 2006-09-06 2011-01-18 Qurio Holdings, Inc. System and method for rights propagation and license management in conjunction with distribution of digital content in a social network
US7873696B2 (en) 2005-10-28 2011-01-18 Yahoo! Inc. Scalable software blade architecture
US7886334B1 (en) 2006-12-11 2011-02-08 Qurio Holdings, Inc. System and method for social network trust assessment
US7925592B1 (en) 2006-09-27 2011-04-12 Qurio Holdings, Inc. System and method of using a proxy server to manage lazy content distribution in a social network
US7992171B2 (en) 2006-09-06 2011-08-02 Qurio Holdings, Inc. System and method for controlled viral distribution of digital content in a social network
US8112549B2 (en) 2005-07-14 2012-02-07 Yahoo! Inc. Alert mechanism for notifying multiple user devices sharing a connected-data-set
WO2012047885A1 (en) * 2010-10-04 2012-04-12 Openwave Systems Inc. Method and system for dynamic traffic steering
US8417782B2 (en) 2005-07-14 2013-04-09 Yahoo! Inc. Universal calendar event handling
US8533280B1 (en) * 2008-05-02 2013-09-10 BitGravity, Inc. Distributed origin content delivery network
US20140250167A1 (en) * 2013-03-04 2014-09-04 Samsung Electronics Co., Ltd. Method for managng transmission information and electronic device thereof
US9001697B2 (en) 2012-12-14 2015-04-07 Western Digital Technologies, Inc. Methods and devices for replacing and configuring a router in a network
US9143929B1 (en) 2012-12-14 2015-09-22 Western Digital Technologies, Inc. Methods and devices configured for IP address conflict detection and resolution upon assignment of WAN IP address
US9195996B1 (en) 2006-12-27 2015-11-24 Qurio Holdings, Inc. System and method for classification of communication sessions in a social network

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8880610B2 (en) * 2003-09-11 2014-11-04 International Business Machines Corporation Managing locally initiated electronic mail attached documents
US7808906B2 (en) 2004-07-23 2010-10-05 Citrix Systems, Inc. Systems and methods for communicating a lossy protocol via a lossless protocol using false acknowledgements
US9367832B2 (en) * 2006-01-04 2016-06-14 Yahoo! Inc. Synchronizing image data among applications and devices
US9880702B2 (en) * 2006-02-03 2018-01-30 Yahoo Holdings, Inc. Content structures and content navigation interfaces
US20070186177A1 (en) * 2006-02-03 2007-08-09 Yahoo! Inc. Content navigation interfaces and associated methods
US20070186173A1 (en) * 2006-02-03 2007-08-09 Yahoo! Inc. Instant messenger alerts and organization systems
US8055444B2 (en) * 2006-04-04 2011-11-08 Yahoo! Inc. Content display and navigation interface
WO2008004207A2 (en) * 2006-07-07 2008-01-10 Fringland Ltd. Identifying network entities in a peer-to-peer network
US20080208980A1 (en) * 2007-02-26 2008-08-28 Michael Ruarri Champan Email aggregation system with supplemental processing information addition/removal and related methods
AU2010202034B1 (en) 2010-04-07 2010-12-23 Limelight Networks, Inc. Partial object distribution in content delivery network
WO2010033938A2 (en) 2008-09-19 2010-03-25 Limelight Networks, Inc. Content delivery network stream server vignette distribution
AU2010276462B1 (en) 2010-12-27 2012-01-12 Limelight Networks, Inc. Partial object caching
WO2010147221A1 (en) * 2009-06-19 2010-12-23 日本技術貿易株式会社 Content managing device and content managing method
CN102035720B (en) * 2009-09-24 2012-07-04 华为技术有限公司 Data transmission method and system
US8923293B2 (en) * 2009-10-21 2014-12-30 Palo Alto Research Center Incorporated Adaptive multi-interface use for content networking
US8805925B2 (en) * 2009-11-20 2014-08-12 Nbrella, Inc. Method and apparatus for maintaining high data integrity and for providing a secure audit for fraud prevention and detection
US9264342B2 (en) * 2009-12-24 2016-02-16 Samsung Electronics Co., Ltd. Terminal device based on content name, and method for routing based on content name
NL2004765C2 (en) * 2010-05-25 2011-11-28 Arjuna Decogabat B V Energy self-sufficient datacenter for processing and storage of classified data.
US8918835B2 (en) 2010-12-16 2014-12-23 Futurewei Technologies, Inc. Method and apparatus to create and manage virtual private groups in a content oriented network
US8819152B2 (en) 2011-01-25 2014-08-26 Kristy Joi Downing Email addressee verification systems and methods for the same
US8799400B2 (en) * 2011-02-02 2014-08-05 Imvu, Inc. System and method for managing multiple queues of non-persistent messages in a networked environment
US8713269B2 (en) 2011-07-14 2014-04-29 Intellectual Ventures Fund 83 Llc Distributed image acquisition, storage, and backup system
US9927958B2 (en) * 2011-08-25 2018-03-27 Vmware, Inc. User interface for networks including virtual machines
US9602358B2 (en) 2011-08-25 2017-03-21 Vmware, Inc. Extensible infrastructure for representing networks including virtual machines
US9729669B2 (en) * 2012-03-15 2017-08-08 Alcatel Lucent Method and system for fast and large-scale longest prefix matching
US9198204B2 (en) 2012-04-11 2015-11-24 Google Inc. Apparatus and method for seamless commissioning of wireless devices
US10075334B1 (en) 2012-04-11 2018-09-11 Google Llc Systems and methods for commissioning a smart hub device
US10142122B1 (en) 2012-04-11 2018-11-27 Google Llc User interfaces, systems and methods for configuring smart devices for interoperability with a smart hub device
US10397013B1 (en) 2012-04-11 2019-08-27 Google Llc User interfaces, systems and methods for configuring smart devices for interoperability with a smart hub device
CN102831894B (en) * 2012-08-09 2014-07-09 华为终端有限公司 Command processing method, command processing device and command processing system
US10391387B2 (en) 2012-12-14 2019-08-27 Microsoft Technology Licensing, Llc Presenting digital content item with tiered functionality
US9374420B2 (en) * 2012-12-14 2016-06-21 Microsoft Technology Licensing, Llc Content source selection in a P2P network
US9922580B2 (en) 2013-04-30 2018-03-20 Google Llc Apparatus and method for the virtual demonstration of a smart phone controlled smart home using a website
CN104219125B (en) * 2013-05-31 2017-12-05 华为技术有限公司 The method, apparatus and system to be E-Packeted centered on information in network ICN
KR101545670B1 (en) 2013-07-25 2015-08-19 서울시립대학교 산학협력단 Methods and system for providing data operations
IN2013CH05044A (en) 2013-11-08 2015-05-29 Huawei Technologies India Pvt Ltd
US10088818B1 (en) 2013-12-23 2018-10-02 Google Llc Systems and methods for programming and controlling devices with sensor data and learning
US9420331B2 (en) 2014-07-07 2016-08-16 Google Inc. Method and system for categorizing detected motion events
US10601604B2 (en) 2014-11-12 2020-03-24 Google Llc Data processing systems and methods for smart hub devices
US20170371727A1 (en) * 2014-12-22 2017-12-28 Hewlett Packard Enterprise Development Lp Execution of interaction flows
US10142908B2 (en) * 2015-06-02 2018-11-27 Liveperson, Inc. Dynamic communication routing based on consistency weighting and routing rules
US10454872B2 (en) * 2015-06-22 2019-10-22 Microsoft Technology Licensing, Llc Group email management
JP2019506094A (en) * 2016-02-18 2019-02-28 ルネサスエレクトロニクス株式会社 Message handler
US10282125B2 (en) * 2017-04-17 2019-05-07 International Business Machines Corporation Distributed content deduplication using hash-trees with adaptive resource utilization in distributed file systems
WO2019126202A1 (en) * 2017-12-19 2019-06-27 Veeva Systems Inc. System and method for controlling electronic communications
US10652077B2 (en) * 2018-08-31 2020-05-12 Subcom, Llc Techniques for interfacing between web services and interface description language (IDL)-based remote procedure call (RPC) services and an optical communication system implementing same
CN110166523B (en) * 2019-04-09 2022-12-27 腾讯科技(深圳)有限公司 Content updating method, device, equipment and computer readable storage medium
US11516290B2 (en) * 2019-12-18 2022-11-29 International Business Machines Corporation Sharing tuples across independent coordination namespace systems

Citations (97)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5481668A (en) * 1992-06-09 1996-01-02 Bull S.A. System for designing information control networks for modeling all kinds of processes
US5625757A (en) * 1993-12-24 1997-04-29 Hitachi, Ltd. Printing system
US5727202A (en) * 1995-10-18 1998-03-10 Palm Computing, Inc. Method and apparatus for synchronizing information on two different computer systems
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
US5864653A (en) * 1996-12-31 1999-01-26 Compaq Computer Corporation PCI hot spare capability for failed components
US6021449A (en) * 1997-08-01 2000-02-01 International Business Machines Corporation Video FIFO overflow control method that blocks video encoder data when overflow is imminent and resumes flow when frames sizes have returned to nominal size
US6069896A (en) * 1996-10-15 2000-05-30 Motorola, Inc. Capability addressable network and method therefor
US6170065B1 (en) * 1997-11-14 2001-01-02 E-Parcel, Llc Automatic system for dynamic diagnosis and repair of computer configurations
US6192396B1 (en) * 1998-08-11 2001-02-20 Canon Kabushiki Kaisha Electronic mail with recipient-specific content
US6236991B1 (en) * 1997-11-26 2001-05-22 International Business Machines Corp. Method and system for providing access for categorized information from online internet and intranet sources
US20020016818A1 (en) * 2000-05-11 2002-02-07 Shekhar Kirani System and methodology for optimizing delivery of email attachments for disparate devices
US20020032020A1 (en) * 2000-05-12 2002-03-14 Brown Bonnie L. Local and remote email alert apparatus and methods
US20020039420A1 (en) * 2000-06-12 2002-04-04 Hovav Shacham Method and apparatus for batched network security protection server performance
US20030004884A1 (en) * 2001-06-20 2003-01-02 Naohisa Kitazato Receiving apparatus and method, information distribution method, filtering and storing program, and recording medium
US6505236B1 (en) * 1999-04-30 2003-01-07 Thinmail, Inc. Network-based mail attachment storage system and method
US6510050B1 (en) * 2000-11-21 2003-01-21 Sun Microsystems, Inc. High density packaging for multi-disk systems
US20030018922A1 (en) * 2001-07-18 2003-01-23 Litwin Louis Robert Method and system for providing emergency shutdown of a malfunctioning device
US6530083B1 (en) * 1998-06-19 2003-03-04 Gateway, Inc System for personalized settings
US20030055903A1 (en) * 2001-09-20 2003-03-20 Freed Edwin Earl System and method for preventing unnecessary message duplication in electronic mail
US6543004B1 (en) * 1999-07-29 2003-04-01 Hewlett-Packard Development Company, L.P. Method and apparatus for archiving and restoring data
US20030065717A1 (en) * 2001-10-01 2003-04-03 Kabushiki Kaisha Toshiba Data distributing method
US20030074358A1 (en) * 2001-09-24 2003-04-17 Siamak Sarbaz Integration, management and processing of network data from disparate sources
US20030084177A1 (en) * 2001-10-26 2003-05-01 Nokia Corporation Mobile client provisioning web service
US20030081557A1 (en) * 2001-10-03 2003-05-01 Riku Mettala Data synchronization
US20030097361A1 (en) * 1998-12-07 2003-05-22 Dinh Truong T Message center based desktop systems
US6571354B1 (en) * 1999-12-15 2003-05-27 Dell Products, L.P. Method and apparatus for storage unit replacement according to array priority
US20040003132A1 (en) * 2000-12-06 2004-01-01 Biosentients, Inc. Data pool architecture, system, and method for intelligent object data in heterogeneous data environments
US20040006551A1 (en) * 2002-04-17 2004-01-08 Nokia Corporation Method and network device for synchronization of database data routed through a router
US20040010569A1 (en) * 2002-07-09 2004-01-15 Adtran, Inc. System and method for provisioning network access devices
US6687716B1 (en) * 2000-09-13 2004-02-03 Radiant Data Corporation File consistency protocols and methods for carrying out the protocols
US20040021637A1 (en) * 2002-07-30 2004-02-05 Ahn Jung Hong Optical mouse and method for preventing an erroneous operation thereof
US6691243B1 (en) * 1998-02-12 2004-02-10 Siemens Aktiengesellschaft Method and configuration for replacing a faulty module, particularly a faulty module within a digital exchange installation
US20040034692A1 (en) * 2002-08-13 2004-02-19 Murata Kikai Kabushiki Kaisha Electronic mail server device and electronic mail processing method
US6697977B2 (en) * 2000-07-21 2004-02-24 Fujitsu Limited Disc recording apparatus, method for replacing sector on recording disc, and recording disc
US20040044799A1 (en) * 2002-09-03 2004-03-04 Nokia Corporation Method, device and system for synchronizing of data providing for the handling of an interrupted synchronization process
US20040049543A1 (en) * 2002-09-05 2004-03-11 International Business Machines Corporation Annotating and routing message content
US6711579B2 (en) * 2001-04-20 2004-03-23 Sree Ayyanar Spinning And Weaving Mills Limited Data storage schema independent programming for data retrieval using semantic bridge
US20040059834A1 (en) * 2002-09-19 2004-03-25 Bellsouth Intellectual Property Corporation Efficient exchange of text based protocol language information
US20040078450A1 (en) * 2002-07-08 2004-04-22 Tsu-Wei Chen Packet routing via payload inspection for digital content delivery
US6728786B2 (en) * 1997-01-30 2004-04-27 Palmsource, Inc. Method and apparatus for synchronizing a portable computer system with a desktop computer system
US20040083472A1 (en) * 2002-10-21 2004-04-29 Rao Bindu Rama System with required enhancements to syncML DM environment to support firmware updates
US20040088390A1 (en) * 2002-11-05 2004-05-06 Microsoft Method and levels of ping notification
US20040088414A1 (en) * 2002-11-06 2004-05-06 Flynn Thomas J. Reallocation of computing resources
US20040103157A1 (en) * 2002-04-17 2004-05-27 Nokia Corporation Store-and-forward server and method for storing and forwarding for instant messaging service implemented in IP multimedia core network subsystem (IMS)
US6839744B1 (en) * 1999-09-10 2005-01-04 Ianywhere Solutions, Inc. System, method, and computer program product for administering channels, content, and data for mobile devices
US6839564B2 (en) * 2001-04-25 2005-01-04 Nokia Corporation Synchronization of database data
US20050003807A1 (en) * 2003-03-20 2005-01-06 Rosenfelt Michael I. Method and system for providing backup messages to wireless devices during outages
US20050010653A1 (en) * 1999-09-03 2005-01-13 Fastforward Networks, Inc. Content distribution system for operation over an internetwork including content peering arrangements
US20050015430A1 (en) * 2003-06-25 2005-01-20 Rothman Michael A. OS agnostic resource sharing across multiple computing platforms
US6848034B2 (en) * 2002-04-04 2005-01-25 International Business Machines Corporation Dense server environment that shares an IDE drive
US6853713B1 (en) * 1999-12-17 2005-02-08 Nortel Networks Limited Client-server network for managing internet protocol voice packets
US6857123B1 (en) * 1998-12-18 2005-02-15 International Business Machines Corporation Method and apparatus for a Meta Data Service in a data processing system
US20050041652A1 (en) * 2003-08-07 2005-02-24 Teamon Systems, Inc. Communications system providing adaptive polling based upon user usage patterns and related methods
US20050043060A1 (en) * 2000-04-04 2005-02-24 Wireless Agents, Llc Method and apparatus for scheduling presentation of digital content on a personal communication device
US20050044187A1 (en) * 2003-08-21 2005-02-24 Microsoft Corporation Systems and methods for providing conflict handling for peer-to-peer synchronization of units of information manageable by a hardware/software interface system
US20050044235A1 (en) * 2003-07-30 2005-02-24 Balahura Robert Eugene System, computer product and method for enabling wireless data synchronization
US6865157B1 (en) * 2000-05-26 2005-03-08 Emc Corporation Fault tolerant shared system resource with communications passthrough providing high availability communications
US6865261B1 (en) * 1996-12-16 2005-03-08 Raman K. Rao Method for providing gastronomic information and instruction with an internet server using mobile communications or computing devices and intelligent appliances
US6865597B1 (en) * 2002-12-20 2005-03-08 Veritas Operating Corporation System and method for providing highly-available volume mount points
US20050055698A1 (en) * 2003-09-10 2005-03-10 Sap Aktiengesellschaft Server-driven data synchronization method and system
US6868444B1 (en) * 2000-05-05 2005-03-15 Interland, Inc. Server configuration management and tracking
US20050059393A1 (en) * 2003-09-16 2005-03-17 Michael Knowles Demand-based provisioning for a mobile communication device
US20050060355A1 (en) * 2001-01-24 2005-03-17 Microsoft Corporation Accounting for update notification in synchronizing data that may be represented by different data structures
US20050063543A1 (en) * 2003-07-03 2005-03-24 Mathew Kayalackakom Hardware acceleration for Diffie Hellman in a device that integrates wired and wireless L2 and L3 switching functionality
US20050063398A1 (en) * 2003-07-03 2005-03-24 Choudhury Abhijit K. Method of implementing L3 switching, network address port translation, and ALG support using a combination of hardware and firmware
US20050067482A1 (en) * 2003-09-26 2005-03-31 Wu Daniel Huong-Yu System and method for data capture and management
US20050076086A1 (en) * 2003-09-18 2005-04-07 Vulcan Portals Inc. Method and system for polling and caching emails for an electronic device
US20050080891A1 (en) * 2003-08-28 2005-04-14 Cauthron David M. Maintenance unit architecture for a scalable internet engine
US6883034B1 (en) * 1995-06-23 2005-04-19 Cisco Technology, Inc. Method of resolving conflicts in access control lists in router by comparing elements in the lists based on subsumption relations
US6892311B2 (en) * 2002-05-08 2005-05-10 Dell Usa, L.P. System and method for shutting down a host and storage enclosure if the status of the storage enclosure is in a first condition and is determined that the storage enclosure includes a critical storage volume
US20050100329A1 (en) * 2002-11-08 2005-05-12 Ich-Kien Lao Mobile and vehicle-based digital video system
US6895480B2 (en) * 2002-12-10 2005-05-17 Lsi Logic Corporation Apparatus and method for sharing boot volume among server blades
US20050108289A1 (en) * 2001-11-26 2005-05-19 East Simon J. Method of replicating data between computing devices which each use local clocks
US6898422B2 (en) * 2000-04-19 2005-05-24 Microsoft Corporation Method and system for providing mobile services
US6901429B2 (en) * 2000-10-27 2005-05-31 Eric Morgan Dowling Negotiated wireless peripheral security systems
US7020662B2 (en) * 2001-05-29 2006-03-28 Sun Microsystems, Inc. Method and system for determining a directory entry's class of service based on the value of a specifier in the entry
US7028312B1 (en) * 1998-03-23 2006-04-11 Webmethods XML remote procedure call (XML-RPC)
US7035902B1 (en) * 2000-08-11 2006-04-25 International Business Machines Corporation Method, article of manufacture and apparatus for processing an electronic mail document
US7051087B1 (en) * 2000-06-05 2006-05-23 Microsoft Corporation System and method for automatic detection and configuration of network parameters
US7051088B2 (en) * 2001-05-14 2006-05-23 Hewlett-Packard Development Company, L.P. Systems and methods for providing off-line backup of a programmable device's configuration data to users of programmable devices at a service location
US20070016636A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Methods and systems for data transfer and notification mechanisms
US20070014243A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for provisioning a user device
US20070014278A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Counter router core variants
US20070014300A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router notification
US20070014277A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router repository
US20070014244A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Alert mechanism for notifying multiple user devices sharing a connected-data-set
US20070014307A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router forwarding
US20070016632A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for synchronizing between a user device and a server in a communication network
US20070016646A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Universal calendar event handling
US20070016676A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for servicing a user device
US20070028293A1 (en) * 2005-07-14 2007-02-01 Yahoo! Inc. Content router asynchronous exchange
US20070038703A1 (en) * 2005-07-14 2007-02-15 Yahoo! Inc. Content router gateway
US20070100856A1 (en) * 2005-10-21 2007-05-03 Yahoo! Inc. Account consolidation
US20070101022A1 (en) * 2005-10-28 2007-05-03 Yahoo! Inc. Sharing data in scalable software blade architecture
US20070100975A1 (en) * 2005-10-28 2007-05-03 Yahoo! Inc. Scalable software blade architecture
US20070101021A1 (en) * 2005-10-28 2007-05-03 Yahoo! Inc. Recovering a blade in scalable software blade architecture
US7487262B2 (en) * 2001-11-16 2009-02-03 At & T Mobility Ii, Llc Methods and systems for routing messages through a communications network based on message content

Family Cites Families (148)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4270168A (en) 1978-08-31 1981-05-26 United Technologies Corporation Selective disablement in fail-operational, fail-safe multi-computer control system
DE3341605A1 (en) 1983-11-17 1985-05-30 Consortium für elektrochemische Industrie GmbH, 8000 München ALPHA-TERTIAERE DIMETHYLACETALE, THEIR PRODUCTION AND USE AS A FRAGRANCE
JP2840320B2 (en) * 1989-09-20 1998-12-24 株式会社日立製作所 Semiconductor storage device
US5436960A (en) 1991-05-20 1995-07-25 Campana, Jr.; Thomas J. Electronic mail system with RF communications to mobile processors and method of operation thereof
US5371882A (en) 1992-01-14 1994-12-06 Storage Technology Corporation Spare disk drive replacement scheduling system for a disk drive array data storage subsystem
US5371743A (en) 1992-03-06 1994-12-06 Data General Corporation On-line module replacement in a multiple module data processing system
DE69329005T2 (en) 1992-10-26 2001-03-22 Sun Microsystems Inc Remote control and pointing device
US5440719A (en) 1992-10-27 1995-08-08 Cadence Design Systems, Inc. Method simulating data traffic on network in accordance with a client/sewer paradigm
JP2699872B2 (en) 1994-06-01 1998-01-19 日本電気株式会社 Data receiving device and buffer management method
US5475813A (en) 1994-07-18 1995-12-12 International Business Machines Corporation Routing transactions in the presence of failing servers
US5684952A (en) 1994-07-25 1997-11-04 Apple Computer, Inc. Supervisory control system for networked multimedia workstations that provides reconfiguration of workstations by remotely updating the operating system
DE69521101T2 (en) 1994-10-31 2001-10-18 Ibm Shared virtual disks with application-transparent recovery
US5633484A (en) 1994-12-26 1997-05-27 Motorola, Inc. Method and apparatus for personal attribute selection and management using a preference memory
US5684990A (en) 1995-01-11 1997-11-04 Puma Technology, Inc. Synchronization of disparate databases
US5774668A (en) 1995-06-07 1998-06-30 Microsoft Corporation System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing
JP3459149B2 (en) 1995-11-06 2003-10-20 シャープ株式会社 Email transfer system
US5873084A (en) 1996-01-18 1999-02-16 Sun Microsystems, Inc. Database network connectivity product
US5815663A (en) 1996-03-15 1998-09-29 The Robert G. Uomini And Louise B. Bidwell Trust Distributed posting system using an indirect reference protocol
JP3451415B2 (en) 1996-03-29 2003-09-29 富士通株式会社 How to synchronize a database in a network management system
US5852724A (en) 1996-06-18 1998-12-22 Veritas Software Corp. System and method for "N" primary servers to fail over to "1" secondary server
US5764908A (en) 1996-07-12 1998-06-09 Sofmap Future Design, Inc. Network system containing program modules residing in different computers and executing commands without return results to calling modules
US5787437A (en) 1996-10-29 1998-07-28 Hewlett-Packard Company Method and apparatus for shared management information via a common repository
US6092169A (en) 1997-04-02 2000-07-18 Compaq Computer Corporation Apparatus and method for storage subsystem drive movement and volume addition
US6157944A (en) 1997-05-14 2000-12-05 Citrix Systems, Inc. System and method for replicating a client/server data exchange to additional client notes connecting to the server
US5937168A (en) 1997-05-30 1999-08-10 Bellsouth Corporation Routing information within an adaptive routing architecture of an information retrieval system
JP3148152B2 (en) 1997-06-27 2001-03-19 日本電気株式会社 Delivery method of broadcast mail using electronic mail system
US6073172A (en) 1997-07-14 2000-06-06 Freegate Corporation Initializing and reconfiguring a secure network interface
US6141690A (en) 1997-07-31 2000-10-31 Hewlett-Packard Company Computer network address mapping
US6134581A (en) 1997-10-06 2000-10-17 Sun Microsystems, Inc. Method and system for remotely browsing objects
KR100301825B1 (en) 1997-12-29 2001-10-27 구자홍 Mpeg video decoding system and method of processing overflow of mpeg video decoding system
JPH11212884A (en) 1998-01-22 1999-08-06 Internatl Business Mach Corp <Ibm> Electronic mail transmission device and method
US6799224B1 (en) 1998-03-10 2004-09-28 Quad Research High speed fault tolerant mass storage network information server
US6453356B1 (en) 1998-04-15 2002-09-17 Adc Telecommunications, Inc. Data exchange system and method
US6163856A (en) 1998-05-29 2000-12-19 Sun Microsystems, Inc. Method and apparatus for file system disaster recovery
US6463463B1 (en) 1998-05-29 2002-10-08 Research In Motion Limited System and method for pushing calendar event messages from a host system to a mobile data communication device
US6144999A (en) 1998-05-29 2000-11-07 Sun Microsystems, Incorporated Method and apparatus for file system disaster recovery
US6105067A (en) 1998-06-05 2000-08-15 International Business Machines Corp. Connection pool management for backend servers using common interface
US6108779A (en) 1998-07-17 2000-08-22 International Business Machines Corporation Server and computer network that permit a client to be easily introduced into the computer network
US6769124B1 (en) 1998-07-22 2004-07-27 Cisco Technology, Inc. Persistent storage of information objects
EP0986225A1 (en) 1998-09-11 2000-03-15 Visto Corporation System and method for securely synchronizing multiple copies of a workspace element in a network
US6489954B1 (en) 1998-10-13 2002-12-03 Prophet Financial Systems, Inc. System and method for permitting a software routine having restricted local access to utilize remote resources to generate locally usable data structure
US6304981B1 (en) 1998-10-19 2001-10-16 Gateway, Inc. Adaptive shutdown system and method for an information handling system
US6256676B1 (en) 1998-11-18 2001-07-03 Saga Software, Inc. Agent-adapter architecture for use in enterprise application integration systems
US6311187B1 (en) 1998-12-29 2001-10-30 Sun Microsystems, Inc. Propogating updates efficiently in hierarchically structured data under a push model
US6496941B1 (en) 1998-12-29 2002-12-17 At&T Corp. Network disaster recovery and analysis tool
JP2000209254A (en) 1999-01-11 2000-07-28 Mitsubishi Electric Corp Information service system
US6463032B1 (en) 1999-01-27 2002-10-08 Advanced Micro Devices, Inc. Network switching system having overflow bypass in internal rules checker
US6457062B1 (en) 1999-04-08 2002-09-24 Palm, Inc. System and method for synchronizing multiple calendars over wide area network
US6647260B2 (en) 1999-04-09 2003-11-11 Openwave Systems Inc. Method and system facilitating web based provisioning of two-way mobile communications devices
US6671824B1 (en) 1999-04-19 2003-12-30 Lakefield Technologies Group Cable network repair control system
US6904043B1 (en) 1999-05-21 2005-06-07 Advanced Micro Devices, Inc. Apparatus and methods for storing and processing header information in a network switch
US6477565B1 (en) 1999-06-01 2002-11-05 Yodlee.Com, Inc. Method and apparatus for restructuring of personalized data for transmission from a data network to connected and portable network appliances
US6880126B1 (en) 1999-08-03 2005-04-12 International Business Machines Corporation Controlling presentation of a GUI, using view controllers created by an application mediator, by identifying a destination to access a target to retrieve data
US6859834B1 (en) 1999-08-13 2005-02-22 Sun Microsystems, Inc. System and method for enabling application server request failover
US6477580B1 (en) 1999-08-31 2002-11-05 Accenture Llp Self-described stream in a communication services patterns environment
US6633907B1 (en) 1999-09-10 2003-10-14 Microsoft Corporation Methods and systems for provisioning online services
US6822951B1 (en) 1999-11-05 2004-11-23 Texas Instruments Incorporated Method and apparatus for routing messages in a wireless network
US7574351B2 (en) 1999-12-14 2009-08-11 Texas Instruments Incorporated Arranging CELP information of one frame in a second packet
US6766469B2 (en) 2000-01-25 2004-07-20 Hewlett-Packard Development Company, L.P. Hot-replace of memory
DE10064627B4 (en) 2000-02-02 2004-02-12 International Business Machines Corp. Method and system for processing e-mail messages in a data transmission system
GB0003604D0 (en) 2000-02-16 2000-04-05 Step Uk Limited System and method for linking information resources
GB0006055D0 (en) 2000-03-14 2000-05-03 Ibm Managing pervasive devices
AUPQ627700A0 (en) 2000-03-17 2000-04-15 Nuc-One Enterprises Pty Ltd Email alert device
US6665709B1 (en) 2000-03-27 2003-12-16 Securit-E-Doc, Inc. Method, apparatus, and system for secure data transport
JP2001344105A (en) 2000-03-31 2001-12-14 Hitachi Software Eng Co Ltd Web application developing method, development support system, and memory medium storing program related to this method
US6813770B1 (en) 2000-04-21 2004-11-02 Sun Microsystems, Inc. Abstract syntax notation to interface definition language converter framework for network management
JP3714850B2 (en) 2000-05-18 2005-11-09 松下電器産業株式会社 Gateway device, connection server device, Internet terminal, network system
US6785868B1 (en) 2000-05-31 2004-08-31 Palm Source, Inc. Method and apparatus for managing calendar information from a shared database and managing calendar information from multiple users
US6941148B2 (en) 2000-06-03 2005-09-06 International Business Machines Corporation Device registry for automatic connection and data exchange between pervasive devices and backend systems
US6751661B1 (en) 2000-06-22 2004-06-15 Applied Systems Intelligence, Inc. Method and system for providing intelligent network management
US6785680B1 (en) 2000-06-26 2004-08-31 International Business Machines Corporation Method and apparatus for providing individualized client data from a service provider to a portable digital device of a client
US6577905B1 (en) 2000-06-29 2003-06-10 International Business Machines Corporation Apparatus and method for providing a transient port
US6452809B1 (en) 2000-11-10 2002-09-17 Galactic Computing Corporation Scalable internet engine
US6944662B2 (en) 2000-08-04 2005-09-13 Vinestone Corporation System and methods providing automatic distributed data retrieval, analysis and reporting services
JPWO2002023614A1 (en) * 2000-09-18 2004-01-22 東京エレクトロン株式会社 Gate insulator film forming method, gate insulator film forming apparatus, cluster tool
US6785712B1 (en) 2000-09-21 2004-08-31 Rockwell Collins, Inc. Airborne e-mail data transfer protocol
US6611849B1 (en) 2000-09-29 2003-08-26 Palm Source, Inc. System for synchronizing databases on multiple devices utilizing a home base
JP2002198925A (en) 2000-12-25 2002-07-12 Matsushita Electric Ind Co Ltd Device and method for receiving data
NO20006683D0 (en) 2000-12-28 2000-12-28 Abb Research Ltd Procedure for time synchronization
US6931454B2 (en) 2000-12-29 2005-08-16 Intel Corporation Method and apparatus for adaptive synchronization of network devices
US20030189593A1 (en) 2001-01-05 2003-10-09 Yarvin Curtis G. Method and apparatus for dynamically updating a markup language based user interface
US20020116396A1 (en) 2001-02-22 2002-08-22 Christopher Somers System for providing electronic contact information from a central source and method for updating contact information
US7085824B2 (en) 2001-02-23 2006-08-01 Power Measurement Ltd. Systems for in the field configuration of intelligent electronic devices
US7339786B2 (en) 2001-03-05 2008-03-04 Intel Corporation Modular server architecture with Ethernet routed across a backplane utilizing an integrated Ethernet switch module
US20020133821A1 (en) 2001-03-08 2002-09-19 Koninklijke Philips Electronics N.V. Activity schedule controls personalized electronic content guide
JP2002269010A (en) 2001-03-09 2002-09-20 Pioneer Electronic Corp Electronic mail processing system and mail server
WO2002075539A2 (en) 2001-03-16 2002-09-26 Novell, Inc. Client-server model for synchronization of files
US20020138579A1 (en) 2001-03-20 2002-09-26 Bernol Goldberg Method and system for completing e-mail transmissions
CA2446961A1 (en) 2001-05-08 2002-11-14 Narad Networks, Inc. System and method for network service provisioning
US6744874B2 (en) 2001-05-15 2004-06-01 Hengning Wu Method of universal communication and devices thereof
US7089297B1 (en) 2001-05-25 2006-08-08 Oracle International Corporation Mechanism for automatically configuring a network resource
US6596941B2 (en) * 2001-06-13 2003-07-22 Salvatore M. Tripoli A.C. electrical power delivery system for a pickup truck bed utility box
US6965929B2 (en) 2001-06-29 2005-11-15 Intel Corporation Configuring a network device
US20030023690A1 (en) 2001-07-26 2003-01-30 Sunit Lohtia Method and apparatus for providing selective delivery of notifications to users of multiple devices over a network
US7093006B2 (en) 2001-07-31 2006-08-15 Motorola, Inc. Method of dynamically configuring access to services
US6596077B2 (en) 2001-07-31 2003-07-22 Illinois Institute Of Technology Controlled nucleation of protein crystals
US7089259B1 (en) 2001-08-03 2006-08-08 Mcafee, Inc. System and method for providing a framework for network appliance management in a distributed computing environment
ATE368900T1 (en) 2001-09-21 2007-08-15 Koninkl Kpn Nv COMPUTER SYSTEM, DATA TRANSMISSION NETWORK, COMPUTER PROGRAM AND DATA CARRIER, ALL FOR FILTERING MESSAGES INCLUDING CONTENT ACCORDING TO A MARKING LANGUAGE
US6875268B2 (en) * 2001-09-26 2005-04-05 Hrl Laboratories, Llc Method of improving a surface of a substrate for bonding
IL161389A0 (en) 2001-10-15 2004-09-27 Semandex Networks Inc Dynamic content based multicast routing in mobile networks
US6622192B2 (en) 2001-11-13 2003-09-16 Inventec Corporation Method of shutting down a server in safety
US7373362B2 (en) 2001-11-19 2008-05-13 Extended Systems, Inc. Coordinated synchronization
US6904482B2 (en) 2001-11-20 2005-06-07 Intel Corporation Common boot environment for a modular server system
GB2382962A (en) * 2001-12-07 2003-06-11 Altio Ltd Data routing without using an address
US8768715B2 (en) 2001-12-13 2014-07-01 Oracle America, Inc. System and method for resource management
US6670982B2 (en) 2002-01-04 2003-12-30 Hewlett-Packard Development Company, L.P. Wireless digital camera media
US20030130882A1 (en) 2002-01-09 2003-07-10 Saxon Shuttleworth System and method for synchronous peer-to-peer appointment scheduling facilitation
US20030177171A1 (en) 2002-01-22 2003-09-18 Brown Bruce Loring Electronic mail retrieval
US20030145021A1 (en) 2002-01-31 2003-07-31 Jarmo Parkkinen Method and arrangement for serially aligning database transactions
US6665179B2 (en) 2002-02-06 2003-12-16 Shin Jiuh Corp. Blade server module
US20030172138A1 (en) 2002-03-11 2003-09-11 Mccormack Jonathan I. System and method for managing two or more electronic devices
US20040039801A9 (en) 2002-03-11 2004-02-26 Venkatachary Srinivasan System and method for delivering data in a network
US20030212684A1 (en) 2002-03-11 2003-11-13 Markus Meyer System and method for adapting preferences based on device location or network topology
US20030195922A1 (en) 2002-04-10 2003-10-16 Alcatel SNMP trap and inform shaping mechanism
EP1495610B1 (en) 2002-04-15 2008-06-18 Nokia Corporation Method and device for handling synchronization related information
US20030212818A1 (en) 2002-05-08 2003-11-13 Johannes Klein Content based message dispatch
US20030212739A1 (en) 2002-05-09 2003-11-13 Antoine Boucher Store and forward architecture
US20030217125A1 (en) 2002-05-15 2003-11-20 Lucent Technologies, Inc. Intelligent end user gateway device
US7379990B2 (en) 2002-08-12 2008-05-27 Tsao Sheng Ted Tai Distributed virtual SAN
US7036902B2 (en) * 2002-08-22 2006-05-02 Canon Kabushiki Kaisha Printing apparatus
US7165224B2 (en) 2002-10-03 2007-01-16 Nokia Corporation Image browsing and downloading in mobile networks
FI114750B (en) 2002-10-29 2004-12-15 Nokia Corp Synchronizing data
US7343168B2 (en) 2002-11-08 2008-03-11 Openwave Systems Inc. Asynchronous messaging based system for publishing and accessing content and accessing applications on a network with mobile devices
US20040092273A1 (en) 2002-11-08 2004-05-13 Openwave Systems Inc. Asynchronous messaging based system for publishing and accessing content and accessing applications on a network with mobile devices
FI114245B (en) 2002-11-13 2004-09-15 Nokia Corp Organizing a synchronization session
TW200411465A (en) 2002-11-19 2004-07-01 Xepa Corp An accounting and management system for self-provisioning digital services
US7047448B2 (en) 2002-11-21 2006-05-16 Bitfone Corporation Software self-repair toolkit for electronic devices
US7409674B2 (en) 2002-12-26 2008-08-05 Research In Motion Limited System and method of creating and communicating with component based wireless applications
US20040143836A1 (en) 2003-01-21 2004-07-22 Mccormack Jonathan Ian System and method for sharing objects among two or more electronic devices
US7046668B2 (en) 2003-01-21 2006-05-16 Pettey Christopher J Method and apparatus for shared I/O in a load/store fabric
US20040230661A1 (en) 2003-01-29 2004-11-18 Gus Rashid Rules based notification system
EP1443701A1 (en) 2003-01-31 2004-08-04 Motorola Inc. Management of a communications terminal using a management platform in a different administrative domain
US20040181580A1 (en) 2003-03-11 2004-09-16 Etienne Baranshamaje Method, computer useable medium, and system for portable email messaging
US6836778B2 (en) 2003-05-01 2004-12-28 Oracle International Corporation Techniques for changing XML content in a relational database
US7275073B2 (en) 2003-05-07 2007-09-25 Good Technology, Inc. System and method for notifying mobile devices based on device type and network capabilities
US7397823B2 (en) 2003-06-04 2008-07-08 Agilent Technologies, Inc. Providing time synchronization across store-and-forward communication devices using protocol-enabled switches
US20040247090A1 (en) 2003-06-05 2004-12-09 Nurmela Wayne Denis Process for providing alert notification to communication devices
EP1639435A4 (en) 2003-06-27 2009-12-30 Hewlett Packard Development Co System and method for downloading update packages into a mobile handset in a carrier network
WO2005008998A1 (en) 2003-07-03 2005-01-27 Sinett Corporation Initialization vector generation algorithm and hardware architecture
WO2005010715A2 (en) 2003-07-21 2005-02-03 Fusionone, Inc. Device message management system
US20050021637A1 (en) 2003-07-22 2005-01-27 Red Hat, Inc. Electronic mail control system
WO2005011215A1 (en) 2003-07-28 2005-02-03 Mohamed Asif Abdul Majeed E-mail reception notification system
US7409425B2 (en) 2003-11-13 2008-08-05 International Business Machines Corporation Selective transmission of an email attachment
US20050198351A1 (en) 2004-02-20 2005-09-08 Microsoft Corporation Content-based routing
US7293006B2 (en) 2004-04-07 2007-11-06 Integrated Project Solutions Llc Computer program for storing electronic files and associated attachments in a single searchable database
US20060168225A1 (en) 2004-10-29 2006-07-27 John Gunning Network and a distributed electronic commerce system using the network
US20060259511A1 (en) 2005-05-13 2006-11-16 Yahoo! Inc. Media object organization across information management services
US8024290B2 (en) 2005-11-14 2011-09-20 Yahoo! Inc. Data synchronization and device handling

Patent Citations (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5481668A (en) * 1992-06-09 1996-01-02 Bull S.A. System for designing information control networks for modeling all kinds of processes
US5625757A (en) * 1993-12-24 1997-04-29 Hitachi, Ltd. Printing system
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
US6883034B1 (en) * 1995-06-23 2005-04-19 Cisco Technology, Inc. Method of resolving conflicts in access control lists in router by comparing elements in the lists based on subsumption relations
US5727202A (en) * 1995-10-18 1998-03-10 Palm Computing, Inc. Method and apparatus for synchronizing information on two different computer systems
US6069896A (en) * 1996-10-15 2000-05-30 Motorola, Inc. Capability addressable network and method therefor
US6865261B1 (en) * 1996-12-16 2005-03-08 Raman K. Rao Method for providing gastronomic information and instruction with an internet server using mobile communications or computing devices and intelligent appliances
US5864653A (en) * 1996-12-31 1999-01-26 Compaq Computer Corporation PCI hot spare capability for failed components
US6728786B2 (en) * 1997-01-30 2004-04-27 Palmsource, Inc. Method and apparatus for synchronizing a portable computer system with a desktop computer system
US6021449A (en) * 1997-08-01 2000-02-01 International Business Machines Corporation Video FIFO overflow control method that blocks video encoder data when overflow is imminent and resumes flow when frames sizes have returned to nominal size
US6170065B1 (en) * 1997-11-14 2001-01-02 E-Parcel, Llc Automatic system for dynamic diagnosis and repair of computer configurations
US6236991B1 (en) * 1997-11-26 2001-05-22 International Business Machines Corp. Method and system for providing access for categorized information from online internet and intranet sources
US6691243B1 (en) * 1998-02-12 2004-02-10 Siemens Aktiengesellschaft Method and configuration for replacing a faulty module, particularly a faulty module within a digital exchange installation
US7028312B1 (en) * 1998-03-23 2006-04-11 Webmethods XML remote procedure call (XML-RPC)
US6530083B1 (en) * 1998-06-19 2003-03-04 Gateway, Inc System for personalized settings
US6192396B1 (en) * 1998-08-11 2001-02-20 Canon Kabushiki Kaisha Electronic mail with recipient-specific content
US20030097361A1 (en) * 1998-12-07 2003-05-22 Dinh Truong T Message center based desktop systems
US6857123B1 (en) * 1998-12-18 2005-02-15 International Business Machines Corporation Method and apparatus for a Meta Data Service in a data processing system
US6505236B1 (en) * 1999-04-30 2003-01-07 Thinmail, Inc. Network-based mail attachment storage system and method
US6543004B1 (en) * 1999-07-29 2003-04-01 Hewlett-Packard Development Company, L.P. Method and apparatus for archiving and restoring data
US20050010653A1 (en) * 1999-09-03 2005-01-13 Fastforward Networks, Inc. Content distribution system for operation over an internetwork including content peering arrangements
US6839744B1 (en) * 1999-09-10 2005-01-04 Ianywhere Solutions, Inc. System, method, and computer program product for administering channels, content, and data for mobile devices
US7000032B2 (en) * 1999-09-10 2006-02-14 Ianywhere Solutions, Inc. System, method, and computer program product for syncing to mobile devices
US6571354B1 (en) * 1999-12-15 2003-05-27 Dell Products, L.P. Method and apparatus for storage unit replacement according to array priority
US6853713B1 (en) * 1999-12-17 2005-02-08 Nortel Networks Limited Client-server network for managing internet protocol voice packets
US20050043060A1 (en) * 2000-04-04 2005-02-24 Wireless Agents, Llc Method and apparatus for scheduling presentation of digital content on a personal communication device
US6898422B2 (en) * 2000-04-19 2005-05-24 Microsoft Corporation Method and system for providing mobile services
US6868444B1 (en) * 2000-05-05 2005-03-15 Interland, Inc. Server configuration management and tracking
US20020016818A1 (en) * 2000-05-11 2002-02-07 Shekhar Kirani System and methodology for optimizing delivery of email attachments for disparate devices
US20020032020A1 (en) * 2000-05-12 2002-03-14 Brown Bonnie L. Local and remote email alert apparatus and methods
US6865157B1 (en) * 2000-05-26 2005-03-08 Emc Corporation Fault tolerant shared system resource with communications passthrough providing high availability communications
US7051087B1 (en) * 2000-06-05 2006-05-23 Microsoft Corporation System and method for automatic detection and configuration of network parameters
US20020039420A1 (en) * 2000-06-12 2002-04-04 Hovav Shacham Method and apparatus for batched network security protection server performance
US6697977B2 (en) * 2000-07-21 2004-02-24 Fujitsu Limited Disc recording apparatus, method for replacing sector on recording disc, and recording disc
US7035902B1 (en) * 2000-08-11 2006-04-25 International Business Machines Corporation Method, article of manufacture and apparatus for processing an electronic mail document
US6687716B1 (en) * 2000-09-13 2004-02-03 Radiant Data Corporation File consistency protocols and methods for carrying out the protocols
US6901429B2 (en) * 2000-10-27 2005-05-31 Eric Morgan Dowling Negotiated wireless peripheral security systems
US6510050B1 (en) * 2000-11-21 2003-01-21 Sun Microsystems, Inc. High density packaging for multi-disk systems
US20040003132A1 (en) * 2000-12-06 2004-01-01 Biosentients, Inc. Data pool architecture, system, and method for intelligent object data in heterogeneous data environments
US20050060355A1 (en) * 2001-01-24 2005-03-17 Microsoft Corporation Accounting for update notification in synchronizing data that may be represented by different data structures
US6711579B2 (en) * 2001-04-20 2004-03-23 Sree Ayyanar Spinning And Weaving Mills Limited Data storage schema independent programming for data retrieval using semantic bridge
US6839564B2 (en) * 2001-04-25 2005-01-04 Nokia Corporation Synchronization of database data
US7051088B2 (en) * 2001-05-14 2006-05-23 Hewlett-Packard Development Company, L.P. Systems and methods for providing off-line backup of a programmable device's configuration data to users of programmable devices at a service location
US7020662B2 (en) * 2001-05-29 2006-03-28 Sun Microsystems, Inc. Method and system for determining a directory entry's class of service based on the value of a specifier in the entry
US20030004884A1 (en) * 2001-06-20 2003-01-02 Naohisa Kitazato Receiving apparatus and method, information distribution method, filtering and storing program, and recording medium
US20030018922A1 (en) * 2001-07-18 2003-01-23 Litwin Louis Robert Method and system for providing emergency shutdown of a malfunctioning device
US20030055903A1 (en) * 2001-09-20 2003-03-20 Freed Edwin Earl System and method for preventing unnecessary message duplication in electronic mail
US20030074358A1 (en) * 2001-09-24 2003-04-17 Siamak Sarbaz Integration, management and processing of network data from disparate sources
US20030065717A1 (en) * 2001-10-01 2003-04-03 Kabushiki Kaisha Toshiba Data distributing method
US20030081557A1 (en) * 2001-10-03 2003-05-01 Riku Mettala Data synchronization
US20030084177A1 (en) * 2001-10-26 2003-05-01 Nokia Corporation Mobile client provisioning web service
US7487262B2 (en) * 2001-11-16 2009-02-03 At & T Mobility Ii, Llc Methods and systems for routing messages through a communications network based on message content
US20050108289A1 (en) * 2001-11-26 2005-05-19 East Simon J. Method of replicating data between computing devices which each use local clocks
US6848034B2 (en) * 2002-04-04 2005-01-25 International Business Machines Corporation Dense server environment that shares an IDE drive
US20040006551A1 (en) * 2002-04-17 2004-01-08 Nokia Corporation Method and network device for synchronization of database data routed through a router
US20040103157A1 (en) * 2002-04-17 2004-05-27 Nokia Corporation Store-and-forward server and method for storing and forwarding for instant messaging service implemented in IP multimedia core network subsystem (IMS)
US6892311B2 (en) * 2002-05-08 2005-05-10 Dell Usa, L.P. System and method for shutting down a host and storage enclosure if the status of the storage enclosure is in a first condition and is determined that the storage enclosure includes a critical storage volume
US20040078450A1 (en) * 2002-07-08 2004-04-22 Tsu-Wei Chen Packet routing via payload inspection for digital content delivery
US20040010569A1 (en) * 2002-07-09 2004-01-15 Adtran, Inc. System and method for provisioning network access devices
US20040021637A1 (en) * 2002-07-30 2004-02-05 Ahn Jung Hong Optical mouse and method for preventing an erroneous operation thereof
US20040034692A1 (en) * 2002-08-13 2004-02-19 Murata Kikai Kabushiki Kaisha Electronic mail server device and electronic mail processing method
US20040044799A1 (en) * 2002-09-03 2004-03-04 Nokia Corporation Method, device and system for synchronizing of data providing for the handling of an interrupted synchronization process
US20040049543A1 (en) * 2002-09-05 2004-03-11 International Business Machines Corporation Annotating and routing message content
US20040059834A1 (en) * 2002-09-19 2004-03-25 Bellsouth Intellectual Property Corporation Efficient exchange of text based protocol language information
US20040083472A1 (en) * 2002-10-21 2004-04-29 Rao Bindu Rama System with required enhancements to syncML DM environment to support firmware updates
US20040088390A1 (en) * 2002-11-05 2004-05-06 Microsoft Method and levels of ping notification
US20040088414A1 (en) * 2002-11-06 2004-05-06 Flynn Thomas J. Reallocation of computing resources
US20050100329A1 (en) * 2002-11-08 2005-05-12 Ich-Kien Lao Mobile and vehicle-based digital video system
US6895480B2 (en) * 2002-12-10 2005-05-17 Lsi Logic Corporation Apparatus and method for sharing boot volume among server blades
US6865597B1 (en) * 2002-12-20 2005-03-08 Veritas Operating Corporation System and method for providing highly-available volume mount points
US20050003807A1 (en) * 2003-03-20 2005-01-06 Rosenfelt Michael I. Method and system for providing backup messages to wireless devices during outages
US20050015430A1 (en) * 2003-06-25 2005-01-20 Rothman Michael A. OS agnostic resource sharing across multiple computing platforms
US20050063398A1 (en) * 2003-07-03 2005-03-24 Choudhury Abhijit K. Method of implementing L3 switching, network address port translation, and ALG support using a combination of hardware and firmware
US20050063543A1 (en) * 2003-07-03 2005-03-24 Mathew Kayalackakom Hardware acceleration for Diffie Hellman in a device that integrates wired and wireless L2 and L3 switching functionality
US20050044235A1 (en) * 2003-07-30 2005-02-24 Balahura Robert Eugene System, computer product and method for enabling wireless data synchronization
US20050041652A1 (en) * 2003-08-07 2005-02-24 Teamon Systems, Inc. Communications system providing adaptive polling based upon user usage patterns and related methods
US20050044187A1 (en) * 2003-08-21 2005-02-24 Microsoft Corporation Systems and methods for providing conflict handling for peer-to-peer synchronization of units of information manageable by a hardware/software interface system
US20050080891A1 (en) * 2003-08-28 2005-04-14 Cauthron David M. Maintenance unit architecture for a scalable internet engine
US20050055698A1 (en) * 2003-09-10 2005-03-10 Sap Aktiengesellschaft Server-driven data synchronization method and system
US20050059393A1 (en) * 2003-09-16 2005-03-17 Michael Knowles Demand-based provisioning for a mobile communication device
US20050076086A1 (en) * 2003-09-18 2005-04-07 Vulcan Portals Inc. Method and system for polling and caching emails for an electronic device
US20050067482A1 (en) * 2003-09-26 2005-03-31 Wu Daniel Huong-Yu System and method for data capture and management
US20070014303A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router
US20070016676A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for servicing a user device
US20070014300A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router notification
US20070014243A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for provisioning a user device
US20070014277A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router repository
US20070014244A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Alert mechanism for notifying multiple user devices sharing a connected-data-set
US20070014307A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router forwarding
US20070016632A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for synchronizing between a user device and a server in a communication network
US20070016646A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Universal calendar event handling
US20070014278A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Counter router core variants
US20070028293A1 (en) * 2005-07-14 2007-02-01 Yahoo! Inc. Content router asynchronous exchange
US20070038703A1 (en) * 2005-07-14 2007-02-15 Yahoo! Inc. Content router gateway
US20070016636A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Methods and systems for data transfer and notification mechanisms
US20070100856A1 (en) * 2005-10-21 2007-05-03 Yahoo! Inc. Account consolidation
US20070101022A1 (en) * 2005-10-28 2007-05-03 Yahoo! Inc. Sharing data in scalable software blade architecture
US20070100975A1 (en) * 2005-10-28 2007-05-03 Yahoo! Inc. Scalable software blade architecture
US20070101021A1 (en) * 2005-10-28 2007-05-03 Yahoo! Inc. Recovering a blade in scalable software blade architecture

Cited By (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7631045B2 (en) * 2005-07-14 2009-12-08 Yahoo! Inc. Content router asynchronous exchange
US20070014303A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router
US7788352B2 (en) 2005-07-14 2010-08-31 Yahoo! Inc. System and method for servicing a user device
US20070016636A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Methods and systems for data transfer and notification mechanisms
US20070014307A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router forwarding
US20070014300A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router notification
US20070016632A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for synchronizing between a user device and a server in a communication network
US20070016676A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for servicing a user device
US8112549B2 (en) 2005-07-14 2012-02-07 Yahoo! Inc. Alert mechanism for notifying multiple user devices sharing a connected-data-set
US20070038703A1 (en) * 2005-07-14 2007-02-15 Yahoo! Inc. Content router gateway
US8417782B2 (en) 2005-07-14 2013-04-09 Yahoo! Inc. Universal calendar event handling
US20070014243A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. System and method for provisioning a user device
US20070028293A1 (en) * 2005-07-14 2007-02-01 Yahoo! Inc. Content router asynchronous exchange
US20090307370A1 (en) * 2005-07-14 2009-12-10 Yahoo! Inc Methods and systems for data transfer and notification mechanisms
US20070014277A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router repository
US7849199B2 (en) 2005-07-14 2010-12-07 Yahoo ! Inc. Content router
US20070100856A1 (en) * 2005-10-21 2007-05-03 Yahoo! Inc. Account consolidation
US7870288B2 (en) 2005-10-28 2011-01-11 Yahoo! Inc. Sharing data in scalable software blade architecture
US7779157B2 (en) 2005-10-28 2010-08-17 Yahoo! Inc. Recovering a blade in scalable software blade architecture
US7873696B2 (en) 2005-10-28 2011-01-18 Yahoo! Inc. Scalable software blade architecture
US20070112880A1 (en) * 2005-11-14 2007-05-17 Lie Yang Data synchronization and device handling
US8024290B2 (en) 2005-11-14 2011-09-20 Yahoo! Inc. Data synchronization and device handling
US20070109592A1 (en) * 2005-11-15 2007-05-17 Parvathaneni Bhaskar A Data gateway
US8065680B2 (en) 2005-11-15 2011-11-22 Yahoo! Inc. Data gateway for jobs management based on a persistent job table and a server table
US8531953B2 (en) * 2006-02-21 2013-09-10 Barclays Capital Inc. System and method for network traffic splitting
US20070195750A1 (en) * 2006-02-21 2007-08-23 Lehman Brothers Inc. System and method for network traffic splitting
US20070245006A1 (en) * 2006-04-18 2007-10-18 Nokia Corporation Apparatus, method and computer program product to provide ad hoc message recipient lists
US20080005263A1 (en) * 2006-06-28 2008-01-03 Nokia Corporation Method, Apparatus and Computer Program Product for Providing Automatic Delivery of Information to a Terminal
US9781071B2 (en) * 2006-06-28 2017-10-03 Nokia Technologies Oy Method, apparatus and computer program product for providing automatic delivery of information to a terminal
US20080034008A1 (en) * 2006-08-03 2008-02-07 Yahoo! Inc. User side database
US7873988B1 (en) 2006-09-06 2011-01-18 Qurio Holdings, Inc. System and method for rights propagation and license management in conjunction with distribution of digital content in a social network
US7992171B2 (en) 2006-09-06 2011-08-02 Qurio Holdings, Inc. System and method for controlled viral distribution of digital content in a social network
US7925592B1 (en) 2006-09-27 2011-04-12 Qurio Holdings, Inc. System and method of using a proxy server to manage lazy content distribution in a social network
US8554827B2 (en) * 2006-09-29 2013-10-08 Qurio Holdings, Inc. Virtual peer for a content sharing system
US20080080392A1 (en) * 2006-09-29 2008-04-03 Qurio Holdings, Inc. Virtual peer for a content sharing system
US8276207B2 (en) 2006-12-11 2012-09-25 Qurio Holdings, Inc. System and method for social network trust assessment
US7886334B1 (en) 2006-12-11 2011-02-08 Qurio Holdings, Inc. System and method for social network trust assessment
US8739296B2 (en) 2006-12-11 2014-05-27 Qurio Holdings, Inc. System and method for social network trust assessment
US9195996B1 (en) 2006-12-27 2015-11-24 Qurio Holdings, Inc. System and method for classification of communication sessions in a social network
WO2008103581A3 (en) * 2007-02-19 2008-10-09 4Dk Technologies Inc Contextural management of multiple device capabilities in a communication device
WO2008103581A2 (en) * 2007-02-19 2008-08-28 4Dk Technologies, Inc. Contextural management of multiple device capabilities in a communication device
US20080198422A1 (en) * 2007-02-19 2008-08-21 Tamara Lynne Casey Contextual Management of Multiple Device Capabilities in a Communication Device
US20080270629A1 (en) * 2007-04-27 2008-10-30 Yahoo! Inc. Data snychronization and device handling using sequence numbers
US20090030993A1 (en) * 2007-07-26 2009-01-29 Mxtoolbox Simultaneous synchronous split-domain email routing with conflict resolution
US7818384B2 (en) 2007-07-26 2010-10-19 Rachal Eric M Simultaneous synchronous split-domain email routing with conflict resolution
US20090182739A1 (en) * 2008-01-10 2009-07-16 Microsoft Corporation Using metadata to route documents
US8533280B1 (en) * 2008-05-02 2013-09-10 BitGravity, Inc. Distributed origin content delivery network
US8694448B2 (en) * 2008-12-16 2014-04-08 At&T Intellectual Property I, L.P. Method and apparatus for providing an adaptive parser
US20100153322A1 (en) * 2008-12-16 2010-06-17 Mandelbaum Yitzhak Method and apparatus for providing an adaptive parser
US8284599B2 (en) 2009-06-23 2012-10-09 Samsung Electronics Co., Ltd. Nonvolatile memory device and related programming method
US20100321999A1 (en) * 2009-06-23 2010-12-23 Samsung Electronics Co., Ltd. Nonvolatile memory device and related programming method
WO2012047885A1 (en) * 2010-10-04 2012-04-12 Openwave Systems Inc. Method and system for dynamic traffic steering
US9001697B2 (en) 2012-12-14 2015-04-07 Western Digital Technologies, Inc. Methods and devices for replacing and configuring a router in a network
US9143929B1 (en) 2012-12-14 2015-09-22 Western Digital Technologies, Inc. Methods and devices configured for IP address conflict detection and resolution upon assignment of WAN IP address
US9497078B1 (en) 2012-12-14 2016-11-15 Western Digital Technologies, Inc. Methods and devices for replacing and configuring a router in a network
US20140250167A1 (en) * 2013-03-04 2014-09-04 Samsung Electronics Co., Ltd. Method for managng transmission information and electronic device thereof

Also Published As

Publication number Publication date
WO2007011533A3 (en) 2008-04-10
JP2009510811A (en) 2009-03-12
JP4881380B2 (en) 2012-02-22
WO2007011533A2 (en) 2007-01-25
KR20080032183A (en) 2008-04-14
US20070014278A1 (en) 2007-01-18
CN101317416A (en) 2008-12-03
KR101035472B1 (en) 2011-05-18
US20070014303A1 (en) 2007-01-18
US7849199B2 (en) 2010-12-07
EP1908256A2 (en) 2008-04-09

Similar Documents

Publication Publication Date Title
US20070028000A1 (en) Content router processing
US7623515B2 (en) Content router notification
US7631045B2 (en) Content router asynchronous exchange
US20070014307A1 (en) Content router forwarding
US20070038703A1 (en) Content router gateway
US20070014277A1 (en) Content router repository
US8577982B2 (en) Method and apparatus for efficiently managing “messages sent” file and resending of messages from mobile wireless communication device
CA2589522C (en) Method and apparatus for efficiently managing &#34;messages sent&#34; file and resending of messages from mobile wireless communication device
US20030105716A1 (en) Reducing duplication of files on a network
US20010032263A1 (en) Archival database system for handling information and information transfers in a computer network
US20130007164A1 (en) Email server with proxy caching of unique identifiers
JP3990272B2 (en) Mailing list management system and e-mail transmission / reception device
EP1428363B1 (en) System and method for managing data items
US20060086799A1 (en) Email client and methods for commanding later re-delivery of messages
EP3226516B1 (en) Unified data networking across heterogeneous networks
WO2012029374A1 (en) Mail transfer system, mail gateway and data store server
US8260861B1 (en) System and method for an electronic mail attachment proxy
US20070073815A1 (en) Email server with proxy caching of message identifiers and related methods
CN110519212A (en) A kind of communication repeater system inferred based on anonymity
JP2005020706A (en) Electronic mail transmission/reception system
KR20040082485A (en) Method and apparatus for performing the process such as re-transmittance of the saved spam mail and modification of the spam rule, and computer readable medium on which program for executing the method is recorded
JP2009093314A (en) E-mail transmitting and receiving system

Legal Events

Date Code Title Description
AS Assignment

Owner name: YAHOO| INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:EBBESEN, BJORN;SMYKA, SZYMON;REEL/FRAME:017233/0644

Effective date: 20060112

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: YAHOO HOLDINGS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:YAHOO| INC.;REEL/FRAME:042963/0211

Effective date: 20170613

AS Assignment

Owner name: OATH INC., NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:YAHOO HOLDINGS, INC.;REEL/FRAME:045240/0310

Effective date: 20171231