Source: http://www.google.com/patents/US7912973?ie=ISO-8859-1&dq=patent:5992892
Timestamp: 2014-08-23 12:22:49
Document Index: 76467532

Matched Legal Cases: ['Application No. 05110465', 'Application No. 05110465', 'Application No. 200510118873', 'Application No. 05110465', 'Application No. 05110465', 'Application No. 200510118873']

Patent US7912973 - Message exchange protocol extension negotiation - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign in<nobr>Advanced Patent Search</nobr>PatentsA mechanism for negotiating a relatively transport agnostic communication protocol for use in accomplishing a distributed activity. The potential protocols subject to negotiation may be, for example, extensions to Web Services Coordination. In that case, when the initiator creates a transaction, the...http://www.google.com/patents/US7912973?utm_source=gb-gplus-sharePatent US7912973 - Message exchange protocol extension negotiationAdvanced Patent SearchPublication numberUS7912973 B2Publication typeGrantApplication numberUS 11/004,528Publication dateMar 22, 2011Filing dateDec 3, 2004Priority dateDec 3, 2004Also published asCN1832472A, CN1832472B, DE602005018592D1, EP1667403A2, EP1667403A3, EP1667403B1, US20060123128Publication number004528, 11004528, US 7912973 B2, US 7912973B2, US-B2-7912973, US7912973 B2, US7912973B2InventorsMax A. Feingold, David E. Langworthy, James E. Johnson, John D. Doty, Michael R. ClarkOriginal AssigneeMicrosoft CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (26), Non-Patent Citations (7), Classifications (7), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetMessage exchange protocol extension negotiationUS 7912973 B2Abstract A mechanism for negotiating a relatively transport agnostic communication protocol for use in accomplishing a distributed activity. The potential protocols subject to negotiation may be, for example, extensions to Web Services Coordination. In that case, when the initiator creates a transaction, the initiator also negotiates the desired protocol with its transaction manager. The transaction manager and any other participants in the transaction will then follow that negotiated protocol when communicating with the transaction manager. The protocol may be selected to improve performance and may be tailored to existing needs and capabilities.
1. In an environment that includes a first computing entity and a second computing entity that are capable of communicating with each other using a message exchange protocol that is extendible, a method for the first computing entity to negotiate one or more extensions to the message exchange protocol to be used in communicating using a message exchange with the second computing entity, the method comprising the following:
an act of the first computing entity constructing first one or more protocol extension-identifying data structures that identify a first set of one or more extensions that the first computing entity is capable of implementing when communicating in a message exchange pattern with the second computing entity;
an act of the first computing entity constructing a first message, the first message including the first one or more protocol extension identifying data structures;
an act of the first computing entity providing the first message to the second computing entity;
an act of the first computing entity receiving a second message from the second computing entity;
an act of the first computing entity determining whether there is second one or more protocol extension-identifying data structures included in the second message that identify a second set of one or more extensions that the second computing entity is capable of implementing when communicating in the message exchange pattern with the first computing entity;
an act of the first computing entity identifying that the message exchange pattern without extensions will be used in the message exchange protocol when there is an absence of the second one or more protocol extension-identifying data structures in the second message; and
an act of the first computing entity identifying third one or more extensions that are actually to be used in the message exchange based on the first one or more extensions and the second one or more extensions when the second one or more protocol extension-identifying data structures exists in the second message.
10. A method in accordance with claim 3, wherein the request further includes registration information normally included within a Register request as defined by the WS-Coordination protocol, and the response includes registration response information included within a RegistrationResponse message as defined by the WS-Coordination protocol.
11. A method in accordance with claim 2, wherein the message exchange protocol allows for either a two-phase prepare/commit transaction or permits delegation of decision making for committing the transaction.
12. A method in accordance with claim 11, wherein the message exchange protocol allows for a second transaction manager to indicate to a first transaction manager that the second transaction manager is in doubt as to a status of the transaction in response to the first transaction manager instructing the second transaction manager to prepare the transaction and then commit the transaction.
13. A method in accordance with claim 2, wherein the message exchange protocol permits a single replay message from a second transaction manager to identify multiple transactions for which replay is desired.
14. A method in accordance with claim 2, wherein the request is a CreateCoordinationContextResponse message as defined by the WS-Coordination protocol.
15. A method in accordance with claim 2, wherein the request is a Register request as defined by the WS-Coordination protocol.
16. A method in accordance with claim 1, wherein the message exchange protocol permits for the generation of a CoordinationContext object based on an existing transaction that implements a transaction protocol other that WS-AT.
17. In an environment that includes a first computing entity and a second computing entity that are capable of communicating with each other using a message exchange protocol that is extendible, a method for the second computing entity to negotiate one or more extensions to the message exchange protocol to be used in communicating using a message exchange with the first computing entity, the method comprising the following:
an act of the second computing entity receiving a first message from the first computing entity, the first message including first one or more protocol extension-identifying data structures that include information identifying a first set of one or more extensions that the second computing entity is capable of implementing when communicating in a message exchange pattern with the first computing entity;
an act of the second computing entity constructing second one or more protocol extension-identifying data structures that identify a second set of one or more extensions that the second computing entity is capable of implementing when communicating in the message exchange pattern with the first computing entity;
an act of the second computing entity constructing a second message including the second one or more protocol extension-identifying data structures;
an act of the second computing entity providing the second message to the first computing entity;
an act of the second computing entity reading the first one or more extension protocol identifying data structures from the first message; and
an act of the second computing entity identifying one or more extensions that are actually to be used in the message exchange based on the first one or more extensions and the second one or more extensions.
18. A computer program product for use in an environment that includes a first computing entity and a second computing entity that are capable of communicating with each other using a message exchange protocol that is extendible, the computer program product not consisting of a propagated data signal and comprising one or more computer-storage media, wherein the media does not consist of a signal, having stored thereon computer-executable instructions that, when executed by one or more processors, causes the first computing entity to perform a method for the first computing entity to negotiate one or more extensions to the message exchange protocol to be used in communicating using a message exchange with the second computing entity, the method comprising the following:
an act of the first computing entity constructing a first message, the first message including the first one or more extension identifying data structures;
identifying third one or more extensions that are actually to be used in the message exchange based on the first one or more extensions and the second one or more extensions when the second one or more protocol extension-identifying data structures exists in the second message.
19. A computer program product for use in an environment that includes a first computing entity and a second computing entity that are capable of communicating with each other using a message exchange protocol that is extendible, the computer program product not consisting of a propagated data signal and comprising one or more computer-storage media, wherein the media does not consist of a signal, having stored thereon computer-executable instructions that, when executed by one or more processors, causes the second computing entity to perform a method for the second computing entity to negotiate one or more extensions to the message exchange protocol to be used in communicating using a message exchange with the first computing entity, the method comprising the following:
an act of the second computing entity reading the first one or more protocol extension identifying data structures from the first message; and
Often network communication protocols define a pattern of message exchange that may be used to accomplish a particular activity. The message pattern may be as simple as a one way transmission of a single message, or may be quite complex involving numerous messages and numerous communication nodes. Regardless of complexity, such network communication protocols will be referred to herein as �message exchange protocols�.
Message exchange protocols expressly define rules regarding the types and forms of messages to be exchanged, the ordering of messages in the exchange, the role of a particular communication node in transmitting or receiving certain message types, and the like. Despite such rules, message exchange protocols often permit additional rules to be defined which are consistent with the basic message exchange protocol, but not expressly defined by the basic protocol. These additional rules may be referred to herein as �extensions� to the basic message exchange protocol.
Examples of a more complex message exchange protocol is Web Services Coordination (WS-Coordination) and Web Services Atomic Transactions (WS-AT), which use Simple Object Access Protocol (SOAP)_envelopes to exchange messages potentially even across transport-level barriers using what is often referred to as �SOAP-tunneling�. For example, a HyperText Transport Protocol (HTTP) computing system may transmit a SOAP envelope within an HTTP message to another HTTP computing system. Along the way, however, the SOAP envelope may be placed in other messages that follow different transport protocols, such as, for example, Message Queues (MQ), Simple Mail Transport Protocol (SMTP), CORBA/IIOP, or the like. Accordingly, SOAP message are considered relatively transport agnostic.
The initiator 401 is to initiate an activity that requires the cooperative interaction of the initiator 401, remote application 411, and their respective transaction managers 402 and 412. To do so, the initiator sends a CreateCoordinationContext message to its transaction manager TM1 as represented by arrow 421 in FIG. 4B. This message may include an endpoint reference that includes all addressing information needed for the transaction manager TM1 to properly address the requesting service at the initiator. An �endpoint reference� is defined by a Web Services protocol called WS-Addressing.
After this interaction, three coordinator/participant relationships have been created. The relationship is defined by sending and receiving a Register request. The computing entity that sends a Register request is a �participant� in the relationship, while the computing entity that receives that Register request is a �coordinator� in the relationship. Accordingly, in one relationship, the initiator 401 is a participant, and the transaction manager TM1 is the coordinator. In a second relationship, the remote application 411 is a participant, and the transaction manager TM2 is a coordinator. In a third relationship, the transaction manager TM2 is a participant, and the transaction manager TM1 is a coordinator. It is this third relationship that involves the most complex interaction and thus will be the focus of the WS-Atomic Transaction summary, which will now be provided.
WS-Atomic Transaction is used to coordinate activities having a short duration and executed within limited trust domains. They are called atomic transactions because they have an �all or nothing� property. WS-Atomic Transaction defines, among other things, a two phase commit protocol that permits a transaction to be prepared in the first phase, followed by a commit in the second phase.
BRIEF SUMMARY OF THE INVENTION The foregoing problems with the prior state of the art are overcome by the principles of the present invention, which are directed towards a mechanism for negotiating extensions to a message exchange protocol to use when engaging in a particular message exchange between two computing entities. If negotiation is not possible, then the basic message exchange protocol is used without implementing extensions. Accordingly, if effective negotiation of extensions is possible, the improved performance, efficiency, or accuracy associated with those extensions may be realized. On the other hand, if negotiation is not possible, the computing entities may still communicate using the basic message exchange protocol. In one embodiment, the potential extensions may be for the WS-Coordination or WS-AT protocols, although this is not required.
One of the two computing entities (referred to as a �first� computing entity to simply distinguish one computing entity from another) constructs one or more extension-identifying data structures that identify one or more extensions that the first computing entity is capable of implementing when communicating in a message exchange with the other computing entity (referred to as a �second computing entity). These one of more extension-identifying data structures may also be referred to herein as �first one or more extension-identifying data structures� or �first extension-identifying data structure(s)� for short. Likewise, the one or more extensions may be referred to herein as �first set of one or more extensions� or �first extension(s)�. The first computing entity then constructs a message (referred to herein as a �first message�) that includes the first extension-identifying data structure(s). The first computing system subsequently sends the first message to the second computing entity.
Upon receiving this first message, if the second computing entity supports this negotiation procedure, the second computing entity may likewise construct one or more extension-identifying data structures that identify one or more extensions that the second computing entity is capable of implementing when communicating in a message exchange with the first computing entity. These one of more extension-identifying data structures may also be referred to herein as �second one or more extension-identifying data structures� or �second extension-identifying data structure(s)� for short. Likewise, the one or more extensions may be referred to herein as �second set of one or more extensions� or �second extension(s)�. The second computing entity then constructs a second message including the second extension-identifying data structure(s), and sends the second message to the first computing entity.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The principles of the present invention relate to a mechanism for negotiating whether or not extensions (and what extensions) to a message exchange protocol are to be used in accomplishing a distributed activity. The negotiation mechanism falls back to the basic message exchange protocol should one of the parties in the message exchange not be aware of the extension negotiation mechanism. The potential message exchange protocols subject to negotiation may be, for example, extensions to Web Services Coordination (WS-Coordination) or Web Services Atomic Transaction (WS-AT). The negotiated protocol extensions may be selected to improve performance and may be tailored to existing needs and capabilities. Furthermore, the transaction manager may use different extensions for different transactions.
FIG. 2 illustrates a network environment 200 that includes an initiator computing entity 201 that initiates a distributed activity coordinated by a transport-agnostic coordination protocol, a first transaction manager 202 associated with the initiator 201, a remote application computing entity 211 that participates in the distributed activity, and a second transaction manager 212 associated with the remote application 211. This environment is particularly applicable to WS-Coordination and WS-AT, although the principles of the present invention are not limited to these particular message exchange protocols. The network environment 200 of FIG. 2 is similar to the prior art network environment 400 of FIG. 4A, which is labeled as �Prior Art�. However, FIG. 2 is not also labeled as �Prior Art� because the various computing entities 201, 202, 211 and 212 are modified to perform the principles of the present invention, and are thus not conventional computing entities.
In this description and in the claims, a �computing entity� is defined as any computing system or software component or component(s) running on the computing system. A �computing system� is defined as any hardware component or combination of hardware component that is capable of executing software. The computing system may be distributed in which case the computing system may encompass multiple computing systems that also fall within the definition of computing system as broadly defined herein. An example of a computing system has been described with respect to FIG. 1. However, the definition of a computing system as set forth herein is by no means so limited. Referring to FIG. 2, any one or combination (or even all) of computing entities may run on a single computing system. However, in one possible network environment, initiator computing entity 201 and transaction manager computing entity 202 run on one computing system, while remote application computing entity 211 and transaction manager computing entity 212 run on another computing system.
The various computing entities 201, 202, 211 and 212 shown with respect to FIG. 2 may follow conventional transport agnostic coordination and transaction protocols such as, for example, WS-Coordination and WS-AT summarized above. As used herein, the term �WS-Coordination� refers to the Web Services Coordination (WS-Coordination) specification published by Microsoft Corporation in November 2004. As used herein, the terms �WS-Atomic Transaction�, �WS-AtomicTransaction�, �WS-AT�, refer to the Web Services Atomic Transaction (WS-AtomicTransaction) specification published by Microsoft Corporation in November 2004.
FIG. 3 illustrates a flowchart of a method 300 for the initiator 201 and transaction manager 202 to negotiate extensions to a message exchange protocol in accordance with the principles of the present invention. Acts performed by the initiator 201 are listed in the left column of FIG. 3 under the heading �Initiator�. Acts performed by the transaction manager 202 are listed in the right column of FIG. 3 under the heading �Transaction Manager�. However, the principles of the present invention extend beyond the negotiation of extensions to WS-Coordination and WS-AT, but apply to the negotiation of extensions for any extensible message exchange protocol. Accordingly, to demonstrate this generality, the initiator may more generally be referred to as a �first computing entity�, and the transaction manager may instead be referred to as a �second computing entity�. As will now be described, this negotiation procedure falls back to the basic message exchange protocol without extensions should one of the computing entities be incapable of negotiating extensions. Accordingly, the distributed activity may still be accomplished even if the extensions are not used.
Following the method 300 shown in FIG. 3, the initiator 201 (also called herein a �first computing entity� for generality) first constructs one or more extension-identifying data structures (also called herein �first one or more extension-identifying data structures� or �first extension-identifying data structure(s) for short) that include information identifying one or more extensions (also called herein �first set of one or more extensions� or �first extension(s)�) that the first computing entity is capable of implementing when communicating in the message exchange pattern with the second computing entity (act 301 in FIG. 3A). A representation of the first extension identifying data structure(s) is illustrated as component 300B in FIG. 3B. The �extension-identifying� data structure is simply any data structure that includes sufficient information such that the second computing entity may (if the second computing entity is configured to negotiate extensions) interpret the extensions that the first computing entity is capable of using. This interpretation may be based on the extensions identified in the first message and/or based on information already-known to the second computing system. The precise physical structure of this data structure(s) is not important to the principles of the present invention.
If the second computing entity is capable of negotiating message exchange protocol extensions in accordance with the principles of the present invention, the second computing entity then reads the first extension-identifying data structure(s) from the first message (act 312), and may then identify one or more extensions that will actually be used in the message exchange based on the first extension(s) as well as on the extensions capable of being implemented (and willing to be offered) by the second computing entity (also referred to herein as �the second set of one or more extensions� or simply �the second extension(s)�) (act 313).
The second computing entity constructs one or more extension-identifying data structures that include information identifying extensions of the message exchange protocol supported by the second computing entity (also referred to herein as �second one or more extension-identifying data structures� or �second extension-identifying data structure(s)�) (act 314). A representation of the second extension-identifying data structure(s) is illustrated as component 300D in FIG. 3D. The �second one or more extension-identifying data structures� is simply any data structure that includes sufficient information such that the first computing system may interpret the extensions that are supported and are willing to be offered by the second computing entity. This interpretation may be based on information within the second extension-identifying data structure(s), or based on information that is already known to the first computing entity. The precise physical structure of this data structure(s) is not important to the principles of the present invention.
Extension #1 WS-Coordination specifies two round trips in order to first set up distributed activities between the initiator and its transaction manager. Specifically, the initiator sends a CreateCoordinationContext request to the transaction manager. The transaction manager then sends a CreateCoordinationContextResponse to the initiator. This first round trip accomplishes the establishment of the transaction. The initiator then sends a Register request to the transaction manager. The transaction manager then returns a RegistrationResponse to the initiator. This second round trip registers the initiator as having a certain role in the transaction. These two round trips can take significant time.
Extension #2 In a second example extension, the two round trips associated with the conventional two-phase prepare commit transaction specified by WS-AT (see message flow of FIG. 5) may instead be reduced to one round trip. Referring to FIG. 5, the transaction manager TM2 conventionally enters an in-doubt phase 505 from the time that transaction manager TM2 receives a prepare message until the time the transaction manager TM2 receives a commit message.
Extension #3 A third example extension applies when a coordinator (e.g, the first transaction manager TM1) has delegated the responsibility for deciding whether or not to commit or abort the transaction to a participant (e.g., the second transaction manager TM2) as indicated in extension #2 described above. As previously mentioned for extension #2, this may be accomplished using a SinglePhaseCommit message. In this third example extension, the participant (e.g., the second transaction manager TM2) may respond to the SinglePhaseCommit message using an InDoubt message or the like to indicate to the first transaction manager TM1 that the first transaction TM1 is in doubt as to whether or not the transaction is committed or aborted. For example, suppose the second transaction manager TM2 has further delegated the decision making for whether to commit or abort the transaction to yet another computing entity, and the second transaction manager TM2 never receives an indication from that third party on whether or not the transaction is to be committed or aborted, the second transaction manager TM2 may after some time communicate the InDoubt message to the first transaction manager TM1.
Extension #4 If the second transaction manager TM2 were to somehow lose track of state information regarding a transaction, or lose track of whether or not a transaction had been committed or aborted, the second transaction manager TM2 could follow the conventional WS-AT protocol by transmitting a Replay message to the first transaction manager TM1. The first transaction manager TM1 could then provide any state information for the transaction if the transaction was open, or could provide a determination on whether or not the transaction was committed or aborted if the transaction was not in process.
Extension #5 The fifth example extension supplements the information that may be included in the CreateCoordinationContext message. The message may be extended to include any information useful for the transaction. For example, the CreateCoordinationContext message may include human-readable information that administrators could access for information regarding the transaction. The CreateCoordinationContext may also include an isolation level parameter that represents how resource managers (such as databases) should lock resources and how the resources should react when multiple transactions access their resources concurrently.
Extension #6 Another extension permits context information within the Endpoint reference to include additional information such as, for example, an identification of the current transaction and/or an identification of other transactions in process along with information that is relevant to whether or not the transaction has been properly concluded (e.g., through being committed or aborted). The Endpoint reference is defined by the WS-Addressing specification, and is included in all of the CreateCoordinationContextResponse, Register, and RegistrationResponse message defined by the WS-Coordination protocol. This information would allow the participant or coordinator to detect �amnesia� regarding a transaction.
Extension #7 Another extension permits for the generation of a CoordinationContext by being provided an identifier to a transaction that is not currently governed by WS-AT. For example, suppose that there is an existing OleTx transaction in process. Now suppose that a participant in the transaction desires to extend the transaction using WS-AT. In order to do so, the participant needs a CoordinationContext object to pass to other desired participants. The participant may generate a request (which may optionally be a CreateCoordinationContext request) for such a CoordinationContext object. The CoordinationContext object is returned, whereupon it is passed to any remote application that is to also participate in the transaction. The other participants may then use that CoordinationContext object to register in the transaction.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5546549 *Jun 1, 1994Aug 13, 1996International Business Machines CorporationMulti-path channel (MPC) interface with user transparent, unbalanced, dynamically alterable computer input/output channelsUS5793983 *Jan 22, 1996Aug 11, 1998International Business Machines Corp.Input/output channel interface which automatically deallocates failed subchannel and re-segments data block for transmitting over a reassigned subchannelUS5870549 *Oct 6, 1997Feb 9, 1999Bobo, Ii; Charles R.Systems and methods for storing, delivering, and managing messagesUS6317777 *Apr 26, 1999Nov 13, 2001Intel CorporationMethod for web based storage and retrieval of documentsUS6615373 *May 8, 2002Sep 2, 2003International Business Machines CorporationMethod, system and program products for resolving potential deadlocksUS6671367May 16, 2000Dec 30, 2003Telefonaktiebolaget Lm EricssonCapability negotiation in a telecommunications networkUS6721333 *Mar 24, 2000Apr 13, 2004Motorola, Inc.Point to point protocol multiplexing/demultiplexing method and apparatusUS6856993 *Mar 30, 2000Feb 15, 2005Microsoft CorporationTransactional file systemUS7409716 *Feb 3, 2004Aug 5, 2008Lockheed Martin CorporationSystem for intrusion detectionUS7509651 *May 23, 2003Mar 24, 2009Hewlett-Packard Development Company, L.P.System and method for providing event notifications to information technology resource managersUS7590843 *Oct 4, 2000Sep 15, 2009Nortel Networks LimitedKey exchange for a network architectureUS20010020243 *Dec 6, 1996Sep 6, 2001Srinivasa R. KoppoluObject-oriented framework for hyperlink navigationUS20020004820 *Jan 26, 2001Jan 10, 2002Baldwin Michael ScottReally simple mail transport protocolUS20020056047 *Sep 17, 2001May 9, 2002Lehman Larry L.System and method for communicating software debug, diagostic and maintenance information between devicesUS20020057701 *Nov 30, 1999May 16, 2002William MillsDevice for Matching Dissimilar Telecommunication ProtocolsUS20030037033 *Aug 20, 2001Feb 20, 2003Kai NymanNaming distribution method for ad hoc networksUS20030112789 *Nov 1, 2001Jun 19, 2003Tomi HeinonenLocal service handoverUS20030212827 *May 8, 2002Nov 13, 2003Abheek SahaMethod and system for providing peer-to-peer exchange of terminal information over a meshed networkUS20040013118 *Jul 22, 2002Jan 22, 20043Com CorporationSystem and method for GRE heartbeatsUS20040107360 *Mar 13, 2003Jun 3, 2004Zone Labs, Inc.System and Methodology for Policy EnforcementUS20040128369Sep 4, 2003Jul 1, 2004Canon Kabushiki KaishaMethod of proposing a service via a description document of such a serviceUS20040157556 *Feb 3, 2004Aug 12, 2004General Electric CompanySystem for intrusion detectionUS20050216736 *Mar 24, 2004Sep 29, 2005Smith Ned MSystem and method for combining user and platform authentication in negotiated channel security protocolsUS20060075277 *Oct 5, 2004Apr 6, 2006Microsoft CorporationMaintaining correct transaction results when transaction management configurations changeUS20060080117 *Oct 12, 2004Apr 13, 2006International Business Machines CorporationMaintaining integrity within an adaptive value chain involving cross enterprise interactionsEP1280301A2Jul 5, 2002Jan 29, 2003Broadcom CorporationFlow based congestion control* Cited by examinerNon-Patent CitationsReference1Cabrera, Luis Felip, et al. Web Services Coordination (WS-Coordination), BEA Systems, International Business Machines Corporation, Microsoft Corporation, Nov. 2004.2Decision to Grant a European Patent, dated Dec. 3, 2009, issued in European Application No. 05110465.1, 2 pp.3European Search Report, dated May 12, 2006, issued in European Application No. 05110465.1, 8 pp.4First Office Action, dated Aug. 21, 2009, issued in Chinese Application No. 200510118873.3, 14 pp.5Office Action, dated Jan. 8, 2007, issued in European Application No. 05110465.1, 1 pp.6Response to Office Action, dated May 16, 2007, issued in European Application No. 05110465.1, 13 pp.7Second Office Action, dated Jul. 6, 2010, issued in Chinese Application No. 200510118873.3, 9 pp.Classifications U.S. Classification709/230International ClassificationG06F15/16Cooperative ClassificationH04L69/24, H04L69/329, H04L67/02European ClassificationH04L29/06P, H04L29/08A7Legal EventsDateCodeEventDescriptionMar 4, 2005ASAssignmentOwner name: MICROSOFT CORPORATION, WASHINGTONFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FEINGOLD, MAX A.;LANGWORTHY, DAVID E.;JOHNSON, JAMES E.;AND OTHERS;REEL/FRAME:015734/0682;SIGNING DATES FROM 20050214 TO 20050220Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FEINGOLD, MAX A.;LANGWORTHY, DAVID E.;JOHNSON, JAMES E.;AND OTHERS;SIGNING DATES FROM 20050214 TO 20050220;REEL/FRAME:015734/0682RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google