Source: http://www.google.com/patents/US7970918?dq=Xerox+%2B+%22centroid
Timestamp: 2016-07-30 11:35:39
Document Index: 92951541

Matched Legal Cases: ['art 602', 'art 614', 'Application No. 05855728', 'Application No. 200680001895', 'Application No. 058255728', 'Application No. 2005322969', 'Application No. 2005322970', 'Application No. 2005322833', 'Application No. 2005322959', 'Application No. 2006203872', 'Application No. 200580046093', 'Application No. 200580046094', 'Application No. 200580046095', 'Application No. 200580046101', 'Application No. 2', 'Application No. 2', 'Application No. 2', 'Application No. 2', 'Application No. 2', 'Application No. 2007', 'Application No. 2007', 'Application No. 2007', 'Application No. 2007', 'Application No. 2007', 'Application No. 200580046094', 'Application No. 200580046101', 'Application No. 200680001895', 'Application No. 200580046095', 'Application No. 200680001895']

Patent US7970918 - End-to-end publish/subscribe middleware architecture - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsMessage publish/subscribe systems are required to process high message volumes with reduced latency and performance bottlenecks. The end-to-end middleware architecture proposed by the present invention is designed for high-volume, low-latency messaging by, among other things, reducing intermediary hops...http://www.google.com/patents/US7970918?utm_source=gb-gplus-sharePatent US7970918 - End-to-end publish/subscribe middleware architectureAdvanced Patent SearchPublication numberUS7970918 B2Publication typeGrantApplication numberUS 11/316,778Publication dateJun 28, 2011Filing dateDec 23, 2005Priority dateJan 6, 2005Fee statusPaidAlso published asCA2594036A1, CA2594082A1, CA2594119A1, EP1849094A2, EP1851646A2, EP1851647A2, US8321578, US9253243, US20060149840, US20110231470, US20130166681, WO2006073969A2, WO2006073969A3, WO2006073969A9, WO2006074109A2, WO2006074109A3, WO2006074380A2, WO2006074380A3Publication number11316778, 316778, US 7970918 B2, US 7970918B2, US-B2-7970918, US7970918 B2, US7970918B2InventorsJ. Barry Thompson, Kul Singh, Pierre FravalOriginal AssigneeTervela, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (62), Non-Patent Citations (51), Referenced by (29), Classifications (34), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetEnd-to-end publish/subscribe middleware architecture
US 7970918 B2Abstract
Message publish/subscribe systems are required to process high message volumes with reduced latency and performance bottlenecks. The end-to-end middleware architecture proposed by the present invention is designed for high-volume, low-latency messaging by, among other things, reducing intermediary hops with neighbor-based routing, introducing efficient native-to-external and external-to-native protocol conversions, monitoring system performance, including latency, in real time, employing topic-based and channel-based message communications, and dynamically optimizing system interconnect configurations and message transmission protocols.
REFERENCE TO EARLIER-FILED AND RELATED APPLICATIONS
This application claims the benefit and incorporates by reference U.S. Provisional Application Ser. No. 60/641,988, filed Jan. 6, 2005, entitled “Event Router System and Method” and U.S. Provisional Application Ser. No. 60/688,983, filed Jun. 8, 2005, entitled “Hybrid Feed Handlers And Latency Measurement.” This application is related to the following applications: U.S. Ser. No. 11/317,295, filed Dec. 23, 2005, titled “Hardware-based Messaging Appliance;” U.S. Ser. No. 11/317,280, filed Dec. 23, 2005, titled “Intelligent Messaging Application Programming Interface;” U.S. Ser. No. 11/318,151, filed Dec. 23, 2005, titled “A Caching Engine in a Messaging System;” and U.S. Ser. No. 11/327,526, filed Jan. 5, 2006, titled “Provisioning and Management in a Message Publish/Subscribe System.”
The present invention relates to data messaging and more particularly to middleware architecture of publish/subscribe systems.
The increasing level of performance required by data messaging infrastructures provides a compelling rationale for advances in networking infrastructure and protocols. Fundamentally, data distribution involves various sources and destinations of data, as well as various types of interconnect architectures and modes of communications between the data sources and destinations. Examples of existing data messaging architectures include hub-and-spoke, peer-to-peer and store-and-forward.
The present invention is based, in part, on the foregoing observations and on the idea that such deficiencies can be addressed with better results using a different approach. These observations gave rise to the end-to-end message publish/subscribe architecture for high-volume and low-latency messaging. So therefore, a data distribution system with an end-to-end message publish/subscribe architecture in accordance with the principles of the present invention can advantageously route significantly higher message volumes with significantly lower latency by, among other things, reducing intermediary hops with neighbor-based routing and network disintermediation, introducing efficient native-to-external and external-to-native protocol conversions, monitoring system performance, including latency, in real time, employing topic-based and channel-based message communications, and dynamically and intelligently optimizing system interconnect configurations and message transmission protocols. In addition, such system can provide guaranteed delivery quality of service with data caching.
Before outlining the details of various embodiments in accordance with aspects and principles of the present invention the following is a brief explanation of some terms that may be used throughout this description. It is noted that this explanation is intended to merely clarify and give the reader an understanding of how such terms might be used, but without limiting these terms to the context in which they are used and without limiting the scope of the claims thereby.
The term “middleware” is used in the computer industry as a general term for any programming that mediates between two separate and often already existing programs. Typically, middleware programs provide messaging services so that different applications can communicate. The systematic tying together of disparate applications, often through the use of middleware, is known as enterprise application integration (EAI). In this context, however, “middleware” can be a broader term used in the context of messaging between source and destination and the facilities deployed to enable such messaging; and, thus, middleware architecture covers the networking and computer hardware and software components that facilitate effective data messaging, individually and in combination as will be described below. Moreover, the terms “messaging system” or “middleware system,” can be used in the context of publish/subscribe systems in which messaging servers manage the routing of messages between publishers and subscribers. Indeed, the paradigm of publish/subscribe in messaging middleware is a scalable and thus powerful model.
The term “consumer” may be used in the context of client-server applications and the like. In one instance a consumer is a system or an application that uses an application programming interface (API) to register to a middleware system, to subscribe to information, and to receive data delivered by the middleware system. An API inside the middleware architecture boundaries is a consumer; and an external consumer is any publish/subscribe system (or external data destination) that doesn't use the API and for communications with which messages go through protocol transformation (as will be later explained).
The term “external data source” may be used in the context of data distribution and message publish/subscribe systems. In one instance, an external data source is regarded as a system or application, located within or outside the enterprise private network, which publishes messages in one of the common protocols or its own message protocol. An example of an external data source is a market data exchange that publishes stock market quotes which are distributed to traders via the middleware system. Another example of an external data source is transactional data. Note that in a typical implementation of the present invention, as will be later described in more detail, the middleware architecture adopts its unique native protocol to which data from external data sources is converted once it enters the middleware system domain, thereby avoiding multiple protocol transformations typical of conventional systems.
The term “external data destination” is also used in the context of data distribution and message publish/subscribe systems. An external data destination is, for instance, a system or application, located within or outside the enterprise private network, which is subscribing to information routed via a local/global network. One example of an external data destination could be the aforementioned market data exchange that handles transaction orders published by the traders. Yet another embodiment of the external data destination is transactional data. Note that, in the foregoing middleware architecture messages directed to an external data destination are translated from the native protocol to the external protocol associated with the external data destination.
This exemplary architecture combines a number of beneficial features which include: messaging common concepts, APIs, fault tolerance, provisioning and management (P&M), quality of service (QoS—conflated, best-effort, guaranteed-while-connected, guaranteed-while-disconnected etc.), persistent caching for guaranteed delivery QoS, management of namespace and security service, a publish/subscribe ecosystem (core, ingress and egress components), transport-transparent messaging, neighbor-based messaging (a model that is a hybrid between hub-and-spoke, peer-to-peer, and store-and-forward, and which uses a subscription-based routing protocol that can propagate the subscriptions to all neighbors as necessary), late schema binding, partial publishing (publishing changed information only as opposed to the entire data) and dynamic allocation of network and system resources. As will be later explained, the publish/subscribe system advantageously incorporates a fault tolerant design of the middleware architecture. Note that the core MAs portion of the publish/subscribe ecosystem uses the aforementioned native messaging protocol (native to the middleware system) while the ingress and egress portions, the edge MAs, translate to and from this native protocol, respectively.
The edge MAs have the ability to convert any external message protocol of incoming messages to the middleware system's native message protocol; and from native to external protocol for outgoing messages. That is, an external protocol is converted to the native (e.g., Tervela™) message protocol when messages are entering the publish/subscribe network domain (ingress); and the native protocol is converted into the external protocol when messages exit the publish/subscribe network domain (egress). Another function of edge MAs is to deliver the published messages to the subscribing external data destinations.
The first communication path links an external data source to an external data destination. The published messages received from the external data source 114 1-n are translated into the native (e.g., Tervela™) message protocol and then routed by the edge MA 106 a. One way the native protocol messages can be routed from the edge MA 106 a is to an external data destination 116 n. This path is called out as communication path 1 a. In this case, the native protocol messages are converted into the external protocol messages suitable for the external data destination. Another way the native protocol messages can be routed from the edge MA 106 b is internally through a core MA 108 b. This path is called out as communication path 1 b. Along this path, the core MA 108 b routes the native messages to an edge MA 106 a. However, before the edge MA 106 a routes the native protocol messages to the external data destination 116 1, it converts them into an external message protocol suitable for this external data destination 116 1. As can be seen, this communication path doesn't require the API to route the messages from the publishers to the subscribers. Therefore, if the publish/subscribe system is used for external source-to-destination communications, the system need not include an API.
Yet another communication path, called out as communications path 3, links two applications, both using an API 110 a-b. At least one of the applications publishes messages or subscribes to messages. The delivery of published messages to (or from) subscribing (or publishing) applications is done via an API that sits on the edge of the publish/subscribe network. When applications subscribe to messages, one of the core or edge MAs routes the messages towards the API which, in turn, notifies the subscribing applications when the data is ready to be delivered to them. Messages published from an application are sent via the API to the core MA 108 c to which the API is ‘registered’.
Note that by ‘registering’ (logging in) to an MA, the API becomes logically connected to it. An API initiates the connection to the MA by sending a registration (a ‘log-in’ request) message to the MA. After registration, the API can subscribe to particular topics of interest by sending its subscription messages to the MA. Topics are used for publish/subscribe messaging to define shared access domains and the targets for a message, and therefore a subscription to one or more topics permits reception and transmission of messages with such topic notations. The P&M sends to the MAs in the network periodic entitlement updates and each MA updates its own table accordingly. Hence, if the MA find the API to be entitled to subscribe to a particular topic (the MA verifies the API's entitlements using the routing entitlements table) the MA activates the logical connection to the API. Then, if the API is properly registered with it, the core MA 108 c routes the data to the second API 110 as shown. In other instances this core MA 108 b may route the messages through additional one or more core MAs (not shown) which route the messages to the API 110 b that, in turn, delivers the messages to subscribing applications 112 1-n.
FIG. 3 illustrate in more details the channel-based messaging architecture 320. Generally, each communication path between the messaging source and destination is considered a messaging transport channel. Each channel 326 1-n, is established over a physical medium with interfaces 328 1-n between the channel source and the channel destination. Each such channel is established for a specific message protocol, such as the native (e.g., Tervela™) message protocol or others. Only edge MAs (those that manage the ingress and egress of the publish/subscribe network) use the channel message protocol (external message protocol). Based on the channel message protocol, the channel management layer 324 determines whether incoming and outgoing messages require protocol translation. In each edge MA, if the channel message protocol of incoming messages is different from the native protocol, the channel management layer 324 will perform a protocol translation by sending the message for process through the protocol translation engine (PTE) 332 before passing them along to the native message layer 330. Also, in each edge MA, if the native message protocol of outgoing messages is different from the channel message protocol (external message protocol), the channel management layer 324 will perform a protocol translation by sending the message for process through the protocol translation engine (PTE) 332 before routing them to the transport channel 326 1-n. Hence, the channel manages the interface 328 1-n with the physical medium as well as the specific network and transport logic associated with that physical medium and the message reassembly or fragmentation.
As to the native protocol, one approach uses the aforementioned native Tervela™ message protocol. Conceptually, the Tervela™ message protocol is similar to an IP-based protocol. Each message contains a message header and a message payload. The message header contains a number of fields one of which is for the topic information. As mentioned, a topic is used by consumers to subscribe to a shared domain of information.
In addition, the P&M system allows the administrator to define a message namespace associated with each of the messages routed throughout a given publish/subscribe network. Accordingly, a publish/subscribe network can be physically and/or logically divided into name-space-based sub-networks. This namespace-based topology is illustrated on FIGS. 7 a and 7 b. The namespace is unique for each publish/subscribe sub-network. Therefore, in the combined publish/subscribe network each publish/subscribe sub-network has a unique namespace assigned to it. In this example, the publish/subscribe network is composed of two publish/subscribe sub-networks, the first one with namespace ‘Namespace 1’ and the second one with namespace ‘Namespace 2’. Essentially, the namespace management feature (in items 520, 512 at FIG. 6) provides the capacity to define different administrative domains and enable topic-based message communications across these different administrative domains while avoiding topic collisions or duplications.
In one example, a publish/subscribe sub-network ‘A’ publishes news updates that are routed towards the publish/subscribe sub-network ‘B’ and sub-network ‘C’ publishes news updates that are also routed towards the sub-network ‘B’. However, if sub-networks ‘A’ and ‘C’ publish the same news updates on the same topic, sub-network ‘B’ can differentiate between the news coming from ‘A’ and those that came from ‘C’ because of their associated namespace. In many instances, these namespace domains will be different intra-organizational domains. In other instances, these domains will be different organization or legal entities domains. In other words, the namespace feature may be used by an organization to limit entitlements to its data or content to certain users in or outside the organization. For users within the organization, this is done by issuing a namespace license to these users; and for users outside the organization, this is done by issuing a namespace license to the organization provided it has an MA.
Turning now to the Messaging Appliances (MAs), FIG. 9 is a block diagram illustrating an MA configured in accordance with the principles of the present invention. In one configuration, the MA is a standalone appliance. In another configuration, the MA is an embedded component within any network physical component such as a router or a switch. In the shown embodiment of an MA, it is divided into three different functional parts. The first part 602 includes the aforementioned network management services (e.g., NTP, SNMP, syslog, telnet/SSH, HTTP/HTTPS, and the like). These services are built on top of a standard network stack, such as TCP/IP stack 604, and they may use, for instance, a dedicated Ethernet network interface card (NIC) 606. In one embodiment, the use of a dedicated NIC provides a way to physically isolate the management traffic from the data messaging traffic. The second part is defined as the messaging stack 608 with a message layer (e.g., Tervela™ message layer) 610 at the top and a transport message layer 612 below it. The messaging stack 608 handles any messaging traffic going in and out of the MA. The third part 614 includes the internal services. These services are used inside the MA, and don't have any direct external interface. Examples of these internal services include system management service such as local and remote management, logging, real-time monitoring and historic trends services. The internal services can be requested via an internal communication bus 616 with calls from any of the aforementioned first and second parts.
In the illustrated MA, the native (e.g., Tervela™) messaging layer 610 has a number of roles two of which are to route native protocol messages and to handle local administrative messages. An administrative message might be a registration request of an API, a subscription request from an API, a configuration update from the P&M system, and more. Administrative messages are typically standard messages with specific administrative topics. Therefore, the MA will have to subscribe to the specific administrative messages (to the administrative topics) before any messages can be delivered locally in the MA. The initial administrative topic subscriptions can be inserted in the routing table as ‘static’ (fixed) routes that are pre-defined in the system for the delivery of administrative messages. These so called static routes map administrative subscriptions locally to the particular MA indicating to the message routing engine that it should deliver the matching administrative messages locally.
Then, for the particular case of an edge MA, when a channel delivers an incoming message to the channel management module, the first check is to verify whether the message protocol differs from the native message protocol. If it does, the channel management module will request the protocol translation engine 618 to convert the incoming messages to the native (e.g., Tervela™) message protocol. When the message is converted, it is handed off to the (Tervela™) messaging. Layer 610. Otherwise, in the case of a core MA, when a channel handles an incoming message, the message is handed off to the native (Tervela™) messaging layer assuming that all channels are using this native message protocol and, therefore, all messages already have the native message format.
Generally, the CE is built on the same logical layers as an MA. However, its native (e.g., Tervela™) messaging layer is considerably simplified. There is no need for routing engine logic because, as opposed to being routed to another physical component in the publish/subscribe network, all the messages are handled and delivered locally at the CE to its administrative message layer 714 or to its caching layer 702. As before, the administrative messages are typically used for administrative purpose, except the retrieve requests that are forwarded to the caching layer 702. All the data messages are forwarded to the caching layer, which uses an indexing service 712 to first index the messages, and then a storage service 708 for storing the messages in the storage area 710. All data messages are stored for a predefined period of time. The indexing service 712 is responsible for ‘garbage collection’ activity and notifies the storage service 708 when expired data messages need to be discarded from the storage area.
The illustrated API 800 is a combination of an API communication engine 802 and API stubs 804 that are compiled and linked to all the applications 806 that use the API. One implementation of the communication engine could be a daemon. Communications between the API stubs and the API communication engine are done via an inter-process communication bus 808, implemented using mechanisms such as sockets or shared memory. The API stubs 804 are available in various programming languages, including C, C++, Java and .NET. In some instances, the API itself might be available in multiple languages. The API runs on various operating system platforms three examples of which are Windows™, Linux™ and Solaris™. Alternatively, the API communication engine and stubs can be merged at compile time with the application, as a monolithic API, to eliminate the need for spawning an additional process on the application server.
In some implementations, the application delivery routing engine is responsible for the late schema binding feature. As mentioned earlier, the native (e.g., Tervela™) messaging protocol provides the information in a raw and compressed format that doesn't contain the structure and definition of the underlying data. As a result, the messaging system beneficially reduces its bandwidth utilization and, in turn, allows increased message volume and throughput. When a data message is received by the API, the API binds the raw data to its schema, allowing the application to transparently access the information. The schema defines the content structure of the message by providing a mapping between field name, type of field, and its offset location in the message body. Therefore, the application can ask for a specific field name without knowing its location in the message, and the API uses the offset to locate and return that information to the application.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5321542Nov 8, 1993Jun 14, 1994International Business Machines CorporationControl method and apparatus for wireless data linkUS5557798Dec 21, 1990Sep 17, 1996Tibco, Inc.Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processesUS5870605Jan 18, 1996Feb 9, 1999Sun Microsystems, Inc.Middleware for enterprise information distributionUS5905873Jan 16, 1997May 18, 1999Advanced Micro Devices, Inc.System and method of routing communications data with multiple protocols using crossbar switchesUS6092080Nov 2, 1998Jul 18, 2000Survivors Of The Shoah Visual History FoundationDigital library systemUS6141705Jun 12, 1998Oct 31, 2000Microsoft CorporationSystem for querying a peripheral device to determine its processing capabilities and then offloading specific processing tasks from a host to the peripheral device when neededUS6189043Jun 9, 1997Feb 13, 2001At&T CorpDynamic cache replication in a internet environment through routers and servers utilizing a reverse tree generationUS6507863Jan 27, 1999Jan 14, 2003International Business Machines CorporationDynamic multicast routing facility for a distributed computing environmentUS6542588Oct 18, 2000Apr 1, 2003Anip, Inc.Method and system for global communications network management and display of market-price informationUS6628616Jan 26, 1999Sep 30, 2003AlcatelFrame relay network featuring frame relay nodes with controlled oversubscribed bandwidth trunksUS6754773Jan 29, 2002Jun 22, 2004Snap Appliance, Inc.Data engine with metadata processorUS6832297Aug 9, 2001Dec 14, 2004International Business Machines CorporationMethod and apparatus for managing data in a distributed buffer systemUS6871113Nov 26, 2002Mar 22, 2005Advanced Micro Devices, Inc.Real time dispatcher application program interfaceUS7020697Nov 3, 2000Mar 28, 2006Accenture LlpArchitectures for netcentric computing systemsUS7349980Jan 24, 2003Mar 25, 2008Blue Titan Software, Inc.Network publish/subscribe system incorporating Web services network routing architectureUS7437417Feb 17, 2004Oct 14, 2008International Business Machines CorporationMethod for publish/subscribe messagingUS20020026533Jan 12, 2001Feb 28, 2002Dutta Prabal K.System and method for distributed control of unrelated devices and programsUS20020059425Jun 22, 2001May 16, 2002Microsoft CorporationDistributed computing services platformUS20020078265Dec 15, 2000Jun 20, 2002Frazier Giles RogerMethod and apparatus for transferring data in a network data processing systemUS20020093917Jan 16, 2001Jul 18, 2002Networks Associates,Inc. D/B/A Network Associates, Inc.Method and apparatus for passively calculating latency for a network applianceUS20020120717Dec 27, 2000Aug 29, 2002Paul GiottaScaleable message systemUS20030105931Nov 30, 2001Jun 5, 2003Weber Bret S.Architecture for transparent mirroringUS20030115317Dec 14, 2001Jun 19, 2003International Business Machines CorporationSelection of communication protocol for message transfer based on quality of service requirementsUS20030177412Jul 11, 2002Sep 18, 2003International Business Machines CorporationMethods, apparatus and computer programs for monitoring and management of integrated data processing systemsUS20030225857Aug 15, 2002Dec 4, 2003Flynn Edward N.Dissemination bus interfaceUS20030226012May 30, 2002Dec 4, 2003N. AsokanSystem and method for dynamically enforcing digital rights management rulesUS20030236970Jun 21, 2002Dec 25, 2003International Business Machines CorporationMethod and system for maintaining firmware versions in a data processing systemUS20040001498Mar 28, 2003Jan 1, 2004Tsu-Wei ChenMethod and apparatus for propagating content filters for a publish-subscribe networkUS20040019645Jul 26, 2002Jan 29, 2004International Business Machines CorporationInteractive filtering electronic messages received from a publication/subscription serviceUS20040049774Sep 5, 2002Mar 11, 2004International Business Machines CorporationRemote direct memory access enabled network interface controller switchover and switchback supportUS20040076155Jul 8, 2003Apr 22, 2004Shalini YajnikCaching with selective multicasting in a publish-subscribe networkUS20040083305Jul 8, 2003Apr 29, 2004Chung-Yih WangPacket routing via payload inspection for alert servicesUS20040225554May 8, 2003Nov 11, 2004International Business Machines CorporationBusiness method for information technology services for legacy applications of a clientUS20040254993Oct 15, 2002Dec 16, 2004Evangelos MamasWireless messaging services using publish/subscribe systemsUS20050021622Feb 6, 2004Jan 27, 2005William CullenDynamic subscription and message routing on a topic between publishing nodes and subscribing nodesUS20050044197Aug 18, 2003Feb 24, 2005Sun Microsystems.Inc.Structured methodology and design patterns for web servicesUS20050251556May 7, 2004Nov 10, 2005International Business Machines CorporationContinuous feedback-controlled deployment of message transforms in a distributed messaging systemUS20050276278Sep 18, 2003Dec 15, 2005Korea Electronics Technology InstituteSystem and method for intergration processing of different network protocols and multimedia trafficsUS20060056628Jul 30, 2003Mar 16, 2006International Business Machines CorporationMethods, apparatus and computer programs for processing alerts and auditing in a publish/subscribe systemUS20060146991 *Jan 5, 2006Jul 6, 2006Tervela, Inc.Provisioning and management in a message publish/subscribe systemUS20060146999 *Dec 23, 2005Jul 6, 2006Tervela, Inc.Caching engine in a messaging systemUS20060168070 *Dec 23, 2005Jul 27, 2006Tervela, Inc.Hardware-based messaging applianceUS20060168331 *Dec 23, 2005Jul 27, 2006Terevela, Inc.Intelligent messaging application programming interfaceUS20070025351Apr 24, 2006Feb 1, 2007Merrill Lynch & Co., Inc., A Delaware CorporationSystem and method for low latency market dataUS20070088924Oct 14, 2005Apr 19, 2007International Business Machines (Ibm) CorporationEnhanced resynchronization in a storage-based mirroring system having different storage geometriesCN1432950AJan 14, 2002Jul 30, 2003英业达股份有限公司Realizing method of enterprise-to-enterprise web site commodity list purchasing modeCN1477575AJul 25, 2003Feb 25, 2004国际商业机器公司Method and system for receiving electronic message from publishing/subscribing serviceEP0996255A2Jan 29, 1999Apr 26, 2000AlcatelFrame relay network featuring frame relay nodes with controlled oversubscribed bandwidth trunksEP1000503A1Aug 28, 1998May 17, 2000Alexander MashinskyMethod and system for global communications network management and display of market-price informationEP1011236A2May 14, 1998Jun 21, 2000Citrix Systems, Inc.System and method for remotely executing an interpretive language applicationJP2002281070A Title not availableJP2003060678A Title not availableJP2004348680A Title not availableJP2006523905A Title not availableJPH0888651A Title not availableJPH08191336A Title not availableWO2000051290A2Feb 23, 2000Aug 31, 2000Alcatel Internetworking, Inc.Multi-service network switchWO2002019595A2Aug 7, 2001Mar 7, 2002Verizon Communications Inc.Simple peering in a transport network employing novel edge devicesWO2002045344A2Nov 30, 2001Jun 6, 2002Message Machines, Inc.Systems and methods for routing messages to communications devicesWO2003034255A1Oct 15, 2002Apr 24, 2003Semandex Networks, Inc.Dynamic content based multicast routing in mobile networksWO2004072800A2Feb 6, 2004Aug 26, 2004Progress Software CorporationDynamic subscription and message routing on a topic between a publishing node and subscribing nodesWO2004080030A1Feb 17, 2004Sep 16, 2004International Business Machines CorporationSystem and method for publish/subscribe messaging* Cited by examinerNon-Patent CitationsReference1Communication from European Patent Office for Application No. 05855728.1 dated Jun. 10, 2010 (1 page).2English Translation of the First Office Action from Chinese Patent Office for Application No. 200680001895.4, dated Nov. 7, 2008, 7 pgs.3European Search Report for Application No. 058255728.1 dated Dec. 12, 2009 (8 pages).4Examination Report for Australian Patent Application No. 2005322969 dated Nov. 14, 2008, 1 page.5Examination Report for Australian Patent Application No. 2005322970 dated Oct. 21 2008, 2 pgs.6Examination Report from Australian Patent Office for Application No. 2005322833 dated Dec. 3, 2008 (2 pages).7Examination Report from Australian Patent Office for Application No. 2005322959 dated Nov. 13, 2008 (1 page).8Examination Report from Australian Patent Office for Application No. 2006203872 dated Oct. 13, 2008 (2 pages).9Final Office Action issued in related U.S. Appl. No. 11/317,295, mailed Aug. 16, 2010, 35 pgs.10Final Office Action issued in related U.S. Appl. No. 11/318,151, mailed Jan. 27, 2010, 30 pgs.11Final Office Action issued in related U.S. Appl. No. 11/327,526, mailed Mar. 24, 2010, 27 pgs.12First Office Action from Chinese Patent Office for Application No. 200580046093.0 dated Sep. 25, 2009 (5 pages).13First Office Action from Chinese Patent Office for Application No. 200580046094.5 dated Jan. 16, 2009 (6 pages).14First Office Action from Chinese Patent Office for Application No. 200580046095.X dated Mar. 6, 2009 (5 pages).15First Office Action from Chinese Patent Office for Application No. 200580046101.1 dated Feb. 27, 2009 (6 pages).16International Search Report issued on Sep. 21, 2007, in related application PCT/US06/00477.17International Search Report issued on Sep. 24, 2007, in related application PCT/US05/47189.18International Search Report, PCT/US05/47216, Oct. 19, 2006, 4 pages.19International Search Report, PCT/US05/47637, dated Mar. 1, 2007, 3 pages.20International Search Report, Tervela Inc., PCT/US05/47216, dated Oct. 19, 2006, 3 pages.21International Search Report, Tervela Inc., PCT/US05/47217, dated Nov. 19, 2006, 3 pages.22Non-Final Office Action in related U.S. Appl. No. 11/317,295, mailed Apr. 12, 2011, 22 pgs.23Non-Final Office Action in related U.S. Appl. No. 11/318,151, mailed Feb. 15, 2011, 12 pgs.24Non-Final Office Action issued in related U.S. Appl. No. 11/317,280, mailed Nov. 17, 2009, 19 pgs.25Non-Final Office Action issued in related U.S. Appl. No. 11/317,295, mailed Jun. 8, 2009, 19 pgs.26Non-Final Office Action issued in related U.S. Appl. No. 11/318,151, mailed Mar. 31, 2009, 21 pgs.27Non-Final Office Action issued in related U.S. Appl. No. 11/32,526, mailed Apr. 1, 2009, 27 pgs.28Office Action for Canadian Patent Application No. 2,594,082, dated Jun. 4, 2009, 2 pages.29Office Action for Canadian Patent Application No. 2,594,119, dated Jun. 2, 2009, 4 pages.30Office Action from Canadian Patent Office for Application No. 2,594,036 dated Jun. 2, 2009 (4 pages).31Office Action from Canadian Patent Office for Application No. 2,594,267 dated Jun. 2, 2009 (14 pages).32Office Action from Canadian Patent Office for Application No. 2,594,267 dated Jun. 2, 2009 (4 pages).33Office action from Japanese Patent for Application No. 2007-550402 dated Jun. 15, 2010 (3 pages).34Office action from Japanese Patent for Application No. 2007-550403 dated Mar. 16, 2010 (2 pages).35Office action from Japanese Patent for Application No. 2007-550404 dated Dec. 8, 2009 (3 pages).36Office action from Japanese Patent for Application No. 2007-550409 dated Jun. 15, 2010 (5 pages).37Office action from Japanese Patent for Application No. 2007-550501 dated Apr. 20, 2010 (2 pages).38Restriction Requirement issued in related U.S. Appl. No. 11/317,280, mailed May 22, 2009, 7 pgs.39Restriction Requirement issued in related U.S. Appl. No. 11/317,295, mailed Jan. 12, 2010, 8 pgs.40Restriction Requirement issued in related U.S. Appl. No. 11/318,151, mailed Nov. 28, 2008, 11 pgs.41Second Office Action from Chinese Patent Office for Application No. 200580046094.5 dated Feb. 12, 2010 (7 pages).42Second Office Action from Chinese Patent Office for Application No. 200580046101.1 dated Apr. 13, 2010 (19 pages).43Second Office Action from Chinese Patent Office for Application No. 200680001895.4 dated Aug. 28, 2009 (10 pages).44Telephone Office Action from Chinese Patent Office for Application No. 200580046095.X dated Aug. 11, 2009 (2 pages).45Third Office Action from Chinese Patent Office for Application No. 200680001895.4 dated Mar. 29, 2010 (8 pages).46Written Opinion for Application No. PCT/US05/47189 dated Sep. 24, 2007 (4 pages).47Written Opinion for PCT Application No. PCT/US2006/000477, mailed Sep. 21, 2007, 6 pages.48Written Opinion of the International Searching Authority, PCT/US05/47216, Oct. 19, 2006, 7 pages.49Written Opinion of the International Searching Authority, PCT/US05/47217, dated Nov. 19, 2006, 6 pages.50Written Opinion of the International Searching Authority, PCT/US05/47637, dated Mar. 1, 2007, 8 pages.51Written Opinion of the International Searching Authority, PCT/US2005/047189, dated Oct. 23, 2007.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8321578 *Nov 27, 2012Tervela, Inc.Systems and methods for network virtualizationUS8345836Jan 1, 2013Voxer Ip LlcTelecommunication and multimedia management method and apparatusUS8484661 *May 19, 2010Jul 9, 2013At&T Mobility Ii LlcAgnostic execution cluster for an agnostic execution environmentUS8526456Nov 1, 2012Sep 3, 2013Voxer Ip LlcTelecommunication and multimedia management method and apparatusUS8532270 *May 7, 2012Sep 10, 2013Voxer Ip LlcTelecommunication and multimedia management method and apparatusUS8565149Mar 5, 2008Oct 22, 2013Voxer Ip LlcMulti-media messaging method, apparatus and applications for conducting real-time and time-shifted communicationsUS8670531May 6, 2010Mar 11, 2014Voxer Ip LlcTelecommunication and multimedia management method and apparatusUS8687779May 6, 2010Apr 1, 2014Voxer Ip LlcTelecommunication and multimedia management method and apparatusUS8693647Jul 13, 2012Apr 8, 2014Voxer Ip LlcTelecommunication and multimedia management method and apparatusUS8705714Jul 20, 2012Apr 22, 2014Voxer Ip LlcTelecommunication and multimedia management method and apparatusUS8732727Jun 11, 2013May 20, 2014At&T Mobility Ii LlcAgnostic execution cluster for an agnostic execution environmentUS8902749Feb 26, 2008Dec 2, 2014Voxer Ip LlcMulti-media messaging method, apparatus and application for conducting real-time and time-shifted communicationsUS8948354Aug 20, 2014Feb 3, 2015Voxer Ip LlcTelecommunication and multimedia management method and apparatusUS9107140Aug 13, 2010Aug 11, 2015At&T Mobility Ii LlcCarrier-driven bearer path selectionUS9154628Mar 5, 2014Oct 6, 2015Voxer Ip LlcTelecommunication and multimedia management method and apparatusUS9253243 *Nov 26, 2012Feb 2, 2016Tervela, Inc.Systems and methods for network virtualizationUS9319363Aug 7, 2015Apr 19, 2016Machine Zone, Inc.Scalable, real-time messaging systemUS9319365Oct 9, 2015Apr 19, 2016Machine Zone, Inc.Systems and methods for storing and transferring message dataUS9385976Oct 9, 2015Jul 5, 2016Machine Zone, Inc.Systems and methods for storing message dataUS20090003340 *Feb 26, 2008Jan 1, 2009Rebelvox, LlcTelecommunication and multimedia management method and apparatusUS20090003554 *Apr 25, 2008Jan 1, 2009Rebelvox, LlcTelecommunication and multimedia management method and apparatusUS20110231470 *Sep 22, 2011Thompson J BarrySystems and methods for network virtualizationUS20110231862 *May 19, 2010Sep 22, 2011At&T Mobility Ii LlcAgnostic execution cluster for an agnostic execution environmentUS20120215885 *Aug 23, 2012Samsung Electronics Co., Ltd.System and method for sharing dataUS20120219131 *Aug 30, 2012Voxer Ip LlcTelecommunication and multimedia management method and apparatusUS20130124910 *Oct 11, 2012May 16, 2013Oracle International CorporationSystem and method for signaling dynamic reconfiguration events in a middleware machine environmentUS20130166681 *Nov 26, 2012Jun 27, 2013Travela, Inc.Systems and methods for network virtualizationUS20140358997 *May 28, 2014Dec 4, 2014Dassault SystemesCommunication Middleware For Managing Multicast ChannelsUS20160098307 *Oct 6, 2014Apr 7, 2016Oracle International CorporationIntegration application building tool* Cited by examinerClassifications U.S. Classification709/230, 719/328, 719/313, 709/238International ClassificationG06F9/44, G06F15/16, G06F13/00, G06F15/173, G06F9/46, G06F3/00Cooperative ClassificationH04L67/02, H04L12/5695, H04L67/327, H04L67/26, H04L47/829, H04L47/822, H04L47/806, H04L47/801, H04L47/15, H04L47/11, H04L45/24, H04L43/0852, H04L43/06, H04L12/1859European ClassificationH04L12/56R, H04L29/08N25, H04L29/08N31Y, H04L47/11, H04L45/24, H04L47/82J, H04L47/80A, H04L47/15, H04L47/82B, H04L47/80DLegal EventsDateCodeEventDescriptionFeb 14, 2006ASAssignmentOwner name: TERVELA, INC., NEW YORKFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:THOMPSON, J. BARRY;SINGH, KUL;FRAVAL, PIERRE;REEL/FRAME:017168/0344Effective date: 20051223Dec 29, 2014FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services