Source: https://patents.google.com/patent/US8321506B2/en
Timestamp: 2019-07-17 13:54:27
Document Index: 471808438

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 2004222762', 'Application No. 200410090196', 'Application No. 04024964', 'Application No. 04024964', 'application No. 04024964', 'Application No. 2004222762', 'Application No. 2004', 'Application No. 2004', 'Application No. 200410090196', 'Application No. 2004131024']

US8321506B2 - Architecture for an extensible real-time collaboration system - Google Patents
US8321506B2
US8321506B2 US10/918,855 US91885504A US8321506B2 US 8321506 B2 US8321506 B2 US 8321506B2 US 91885504 A US91885504 A US 91885504A US 8321506 B2 US8321506 B2 US 8321506B2
US10/918,855
US20050091435A1 (en
2004-08-14 Application filed by Microsoft Corp filed Critical Microsoft Corp
2004-10-22 Priority claimed from RU2004131024/09A external-priority patent/RU2377640C2/en
2004-12-15 Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BOBDE, NIKHIL, HAN, MU, POTRA, ADRIAN, GANESAN, KRISHNAMURTHY
2005-04-28 Publication of US20050091435A1 publication Critical patent/US20050091435A1/en
2012-11-27 Publication of US8321506B2 publication Critical patent/US8321506B2/en
This application is a continuation of commonly assigned U.S. patent application Ser. No. 10/918,333, entitled “ARCHITECTURE FOR AN EXTENSIBLE REAL-TIME COLLABORATION SYSTEM,” filed on Aug. 13, 2004, which application is now abandoned, and claims the benefit of U.S. Provisional Application No. 60/513,790, entitled “Live-Communication V 2 API Architecture,” filed on Oct. 23, 2003, and “U.S. Provisional Application No. 60/599,807, entitled “Real-Time Collaboration Systems,” filed on Aug. 6, 2004, which applications are incorporated herein in their entireties by reference.
Various communications applications and protocols enable communications between software programs or users. As examples, real-time communications applications such as MICROSOFT WINDOWS MESSENGER and Voice over Internet Protocol (“VoIP”) enable communications between users sending each other text, video, or voice data. These applications may use various protocols, such as Session Initiation Protocol (“SIP”), Real-Time Transport Protocol (“RTP”), and Real-Time Control Protocol (“RTCP”), to establish sessions and send communications-related information. SIP is an application-layer control protocol that devices can use to discover one another and to establish, modify, and terminate sessions between devices. RTP is a protocol for delivering audio and video over the Internet, and is frequently used in streaming media systems and videoconferencing systems in conjunction with other protocols such as RTCP and H.323. RTCP is a protocol that enables a client application to monitor and control data sent or received using RTP, and is used with RTP. SIP and RTP/RTCP are Internet proposed standards. Their specifications, “RFC 3261” and “RFC 3550,” and respectively, are available on the Internet at www.ietf.org at /rfc/rfc3261.txt and www.faqs.org at /rfcs/rfc3550.html, respectively, and are incorporated herein in their entirety by reference.
An architecture for an extensible real-time collaboration system is provided. The architecture presents a unified application program interface (“API”) for writing application programs that use communications protocols. The architecture has activity objects, endpoint objects, and multiple media stacks. These objects may use various communications protocols, such as Session Initiation Protocol or Real-Time Transport Protocol to send and receive messages containing information. The activity objects, endpoint objects, and multiple media stacks may each have one or more APIs that an application developer can use to access or provide collaboration-related functionality. These objects map the API to the underlying implementation provided by other objects. Using the activity objects enables a developer to provide less application logic than would otherwise be necessary to provide complex collaboration services.
FIG. 3 is a block diagram illustrating activity objects of the extensible real-time collaboration system in an embodiment.
FIG. 5 is an architecture diagram illustrating the architecture for an extensible real-time collaboration system in an embodiment.
In an embodiment, an architecture for an extensible real-time collaboration system is provided. The architecture provides a high-level application program interface (“API”) for writing application programs that use communications protocols to provide collaboration services. An application developer can add collaboration services to an application by using the API without needing to learn complexities associated with several underlying protocols that implement the collaboration services.
Turning now to the figures, FIG. 1 is a block diagram illustrating components of an architecture for an extensible real-time collaboration system in an embodiment. The architecture for an extensible real-time collaboration system comprises a collaboration service object 102, multiple endpoint objects 104, activity objects 106, and multiple media stacks 108. One or more applications 110 may utilize the architecture by accessing various methods, properties, and events relating to the architecture. An application developer writing an application may utilize the architecture by using a unified API instead of having to learn and implement a different API for each media stack, protocol, or other component that the application or architecture may use.
Endpoint objects 104 provide a facility for signaling other objects. Signaling may be used between two endpoint objects having a session, e.g., so that an endpoint object can invite or request the other endpoint object to conduct an activity or exchange information relating to the session. As examples, an endpoint object may invite the other endpoint object of the session to an instant messaging conversation and subsequently may send text messages relating to the conversation. Endpoint objects are further described below in greater detail in relation to FIG. 2.
The architecture may support several varieties of endpoint objects, and each variety of endpoint object may be instantiated multiple times. As an example, there may be an endpoint object relating to a user's personal Internet service provider account (e.g., MSN.COM) and another endpoint object relating to the user's corporate Internet account (e.g., MICROSOFT.COM). The user may be logged in to service providers using the personal account on multiple devices (e.g., a handheld computing device and a desktop computing device) and may also be logged in using the corporate account on some of the devices (e.g., the desktop computing device). Thus, there may be two instances relating to the URI associated with the personal account. Individual instances of endpoint objects may then be uniquely identified by a combination of a uniform resource locator (“URI”) and an endpoint identifier (“EID”). As an example, an endpoint object may be identified by the URI user@MSN.COM and by the EID “1234.” As previously described, the EID may be used to particularly distinguish an instance of an endpoint object from another instance of an endpoint object that is associated with the same URI.
FIG. 4 is a flow diagram illustrating a create_server_endpoint routine in an embodiment. The routine is called by an application to create an endpoint object that connects to a server. When an endpoint is created that connects to a server, information it publishes may be available to subscribing objects even after the created endpoint is no longer operating. Thus, an endpoint connected to a server may provide “per-URI” information meaning that the information remains available after the object's lifetime.
The routine begins at block 402. At block 404, the routine creates a new endpoint object, and indicates that the endpoint is related to an application. The indicated application may be provided as a parameter to a create function that operates to create the endpoint. When creating an endpoint, a “friendly” name may be provided so that the endpoint may be referenced by the friendly name. Alternatively, the newly created endpoint may be referenced by a unique identifier associated with the endpoint. This unique identifier may be generated by the system when the object is created.
At block 406, upon creating the endpoint, the application may register the newly created endpoint object to the server to allow the server to route messages to this endpoint. Upon receiving the register request from the endpoint object, the server may issue a challenge to the endpoint. The challenge may contain a “realm” used by the server. A realm may indicate a domain name associated with the server. As an example, the server may issue a challenge with the realm “MICROSOFT.com.”
At block 408, the routine responds to the challenge by providing credentials (e.g., user id and password) associated with the application. These credentials may be supplied by a user or automatically. The server may validate the credentials that the routine supplies. The credentials may be associated with the realm. For example, if the application provides credentials that are not associated with the server's realm (“MICROSOFT.com”), the server may not authenticate the application.
In an embodiment, the server may enable an endpoint that is not successfully registered to send messages but not receive messages. Alternatively, in a weaker security model, the server may enable any endpoint to send or receive messages.
FIG. 5 is an architecture diagram illustrating the architecture for an extensible real-time collaboration system in an embodiment. The architecture comprises an activity object 502, endpoint 504, and multiple media stack objects 506. These objects have been discussed in extensive detail. The architecture diagram indicates a relationship between the activity object, endpoint object, and media stack objects in an embodiment. Specifically, the architecture diagram indicates that functionality provided by an activity object includes functionality provided by the endpoint and media stack objects.
An application can create an endpoint object by creating a new “CollaborationEndpoint.” The application can provide the following parameters: a URI relating to the endpoint object, a server associated with the endpoint object, and an indication of network credentials.
A NetworkCredential method provides the indication of network credentials. This method accepts as parameters an indication of a user account, password, and domain with which the account is associated.
1. A method performed by a computing system for providing real-time collaboration services in an application, comprising:
instantiating a first activity object, stored at a computing device, that employs a first endpoint object and a first media stack object to provide a first collaboration service, the first activity object comprising at least one of a collaboration session activity object, an application session activity object, a messaging activity object, and a videoconferencing activity object, wherein the first endpoint object supports a first signaling protocol for providing management services, and wherein the first media stack object supports a first media protocol for providing content communication services, the first activity object providing a first unified application program interface for coordinating the first signaling protocol and the first media protocol;
instantiating a second activity object, stored at the computing device, that employs a second endpoint object and a second media stack object to provide a second collaboration service, the second activity object being different from the first activity object and comprising at least one of a collaboration session activity object, an application session activity object, a messaging activity object, and a videoconferencing activity object, wherein the second endpoint object supports a second signaling protocol for providing management services, and wherein the second media stack object supports a second media protocol for providing content communication services, the second activity object providing a second unified application program interface for coordinating the second signaling protocol and the second media protocol;
invoking methods of the first unified application program interface of the first activity object at the computing device, the first unified application program interface comprising a first high-level interface of consolidated programming logic of the first signaling protocol and the first media protocol, wherein the invoked methods provide the underlying functionality of the first endpoint object and the first media stack object between applications that communicate information using the first collaboration service;
invoking methods of the second unified application program interface comprising a second high-level interface of consolidated programming logic of the second signaling protocol and the second media protocol, wherein the invoked methods provide the underlying functionality of the second endpoint object and the second media stack object between applications that communicate using the second collaboration service;
wherein the first and second signaling protocols provide negotiation for bandwidth parameters;
wherein the collaboration session activity object enables a plurality of users at different computing devices to collaborate on a shared document; and
wherein the shared document is simultaneously open for editing by the plurality of collaborating users.
2. The method of claim 1 wherein the first endpoint object uses a Session Initiation Protocol.
3. The method of claim 1 wherein the first media stack object provides the content communications services via an application program interface that the activity object employs.
4. The method of claim 3 wherein the first media stack object uses Real-Time Transport Protocol.
5. The method of claim 1 wherein the content communications services include providing media.
6. The method of claim 1 wherein a user is available when the user is online at two devices.
7. The method of claim 1 wherein a user is not available when the user was online at two devices at a first time and is online at only one of the two devices at a second time after the first time.
8. An extensible real-time collaboration system, comprising:
at least two media stack objects stored and implemented by a computing device wherein a first media stack object communicates collaboration content using a first media protocol and a second media stack object communicates collaboration content using a second media protocol that is different from the first media protocol;
an endpoint object stored and implemented by the computing device, the endpoint object for providing or receiving signaling information using a signaling protocol;
an activity object stored and implemented by the computing device to provide a collaboration service, the activity object comprising at least one of a collaboration session activity object, an application session activity object, a messaging activity object, and a videoconferencing activity the activity object having a unified application program interface, the unified application program interface comprising a high-level interface of consolidated programming logic of the first media protocol, the second media protocol, and the signaling protocol, wherein invoked methods of the unified application program interface provide the underlying functionality of the endpoint object the first media stack object, and the second media stack object between applications that communicate information using the collaboration service;
wherein the first and second media protocols provide negotiation for bandwidth parameters;
9. The extensible real-time collaboration system of claim 8 wherein the unified application program interface provides a consistent application program interface name for both the first media stack object providing a first application program interface name and the second media stack object providing a second application program interface name.
10. The extensible real-time collaboration system of claim 8 wherein one of the collaboration services is messaging.
11. The extensible real-time collaboration system of claim 8 wherein one of the collaboration services is videoconferencing.
12. The extensible real-time collaboration system of claim 8 wherein one of the collaboration services is application sharing.
13. The extensible real-time collaboration system of claim 8 wherein a new media stack object is added to the multiple media stack objects.
14. The extensible real-time collaboration system of claim 8 wherein the endpoint object comprises a profile component, a publishing and subscribing component, a signaling component, and a protocol stack component.
15. The extensible real-time collaboration system of claim 14 wherein the protocol stack component uses a Session Initiation Protocol.
16. The extensible real-time collaboration system of claim 14 wherein the protocol stack component uses a signaling protocol.
17. The extensible real-time collaboration system of claim 8 wherein one of the multiple media stack objects uses Real-Time Transport Protocol.
18. The extensible real-time collaboration system of claim 17 wherein the activity object coordinates one of the multiple media stack objects and the endpoint object under direction of the application.
19. A computer storage medium not consisting of a propagated data signal and storing computer-executable instructions that, if executed, perform a method for providing real-time collaboration services in an application, the instructions comprising:
instantiating a first activity object, at a computing device, that employs first endpoint object and a first media stack object to provide a first collaboration service, the first activity object comprising at least one of a collaboration session activity object, an application session activity object, a messaging activity object, and a videoconferencing activity object, wherein the first endpoint object supports a first signaling protocol for providing management services, and wherein the first media stack object supports a first media protocol for providing content communication services, the first activity object providing a first unified application program interface for coordinating the first signaling protocol and the first media protocol;
instantiating a second activity object, at the computing device, that employs a second endpoint object and a second media stack object to provide a second collaboration service, the second activity object being different from the first activity object and comprising at least one of a collaboration session activity object, an application session activity object, a messaging activity object, and a videoconferencing activity object, wherein the second endpoint object supports a second signaling protocol for providing management services, and wherein the second media stack object supports a second media protocol for providing content communication services, the second activity object providing a second unified application program interface for coordinating the second signaling protocol and the second media protocol;
invoking methods of the first unified application program interface of the first activity object at the computing device, the first unified application program interface comprising a first high-level interface of consolidated programming logic of the first signaling protocol and the first media protocol, wherein the invoked methods provide the underlying functionality of the first endpoint object and the first media stack object between applications that communicate information using the first collaboration service,
invoking methods of the second unified application program interface comprising a second high-level interface of consolidated programming logic of the second signaling protocol and the second media protocol, wherein the invoked methods provide the underlying functionality of the second endpoint object and the second media stack object between applications that communicate using the second collaboration service,
US10/918,855 2003-10-23 2004-08-14 Architecture for an extensible real-time collaboration system Active 2026-05-21 US8321506B2 (en)
AU2004222762A AU2004222762B2 (en) 2003-10-23 2004-10-19 Architecture for an extensible real-time collaboration system
EP04024964A EP1526695B1 (en) 2003-10-23 2004-10-20 Architecture for an extensible real-time collaboration system
AT04024964T AT369002T (en) 2003-10-23 2004-10-20 Architecture for an extensible real-time collaborative system
DE200460007864 DE602004007864T2 (en) 2003-10-23 2004-10-20 Architecture for an extensible real-time collaboration system
BRPI0404468 BRPI0404468A (en) 2003-10-23 2004-10-21 Architecture for a collaborative system in real time extensible
KR1020040084265A KR101137099B1 (en) 2003-10-23 2004-10-21 Architecture for an extensible real-time collaboration system
RU2004131024/09A RU2377640C2 (en) 2003-10-23 2004-10-22 Architecture for extensible system for real time interoperation
CA 2485763 CA2485763C (en) 2003-10-23 2004-10-22 Architecture for an extensible real-time collaboration system
CN 200410090196 CN100566335C (en) 2003-10-23 2004-10-22 Architecture for an extensible real-time collaboration system
MXPA04010559 MXPA04010559A (en) 2003-10-23 2004-10-22 Architecture for an extensible real-time collaboration system.
JP2004308917A JP2005202926A (en) 2003-10-23 2004-10-22 Architecture of extensible real-time collaboration system
US91833304A Continuation 2004-08-13 2004-08-13
US20050091435A1 US20050091435A1 (en) 2005-04-28
US8321506B2 true US8321506B2 (en) 2012-11-27
US10/918,855 Active 2026-05-21 US8321506B2 (en) 2003-10-23 2004-08-14 Architecture for an extensible real-time collaboration system
JP2003022251A (en) 2001-07-06 2003-01-24 Ibm Japan Ltd Data communication method and data communication system and its program
EP1526695B1 (en) 2003-10-23 2007-08-01 Microsoft Corporation Architecture for an extensible real-time collaboration system
Australia Notice of Acceptance mailed Feb. 23, 2010, in Application No. 2004222762 (3 pages).
Chabert, A., et al., "Java Object-Sharing in Habanero," Communications of the Association for Computing Machinery, Association for Computing Machinery, New York, vol. 41, No. 6, Jun. 1998 (pp. 69-76).
Chen et al.; "Web communication services and the PacketIN/sup ®/ application hosting environment."; Bell Labs Technical Journal, {Bell-Labs-Tech-J-USA}, 2002, vol. 7, No. 1, p. 25-40. *
Chinese Notice on Grant of Patent Right for Invention mailed Jul. 24, 2009, in Application No. 200410090196 (2 pages).
Dourish, Paul, "Using Metalevel Techniques in a Flexible Toolkit for CSCW Applications," ACM Transactions on Computer-Human Internaction, 5(2), 109-155, 1998.
European Communication mailed Feb. 9, 2006 in Application No. 04024964 (5 pages).
European Decision to Grant mailed Jul. 5, 2007, in Application No. 04024964 (2 pages).
European Search Report for application No. 04024964.1-1244, mailed on Feb. 1, 2005, 3 pages.
Examiner's First Report by Australian Patent Office, Application No. 2004222762, Sep. 16, 2009, 2 pages.
Final Rejection, U.S. Appl. No. 10/923,598, mailed on Apr. 15, 2009, 18 pages.
Final Rejection, U.S. Appl. No. 10/923,598, mailed on Mar. 17, 2010, 17 pages.
First Action German Patent Office, Application No. DE 60 2004 007 864, mailed on Apr. 17, 2008.
Japanese Final Rejection Feb. 17, 2012, in Application No. 2004-308917 (4 pages).
Japanese Notice of Rejection mailed Feb. 25, 2011, in Application No. 2004-308917 (7 pages).
Non-Final Rejection, U.S. Appl. No. 10/923,598, mailed on Oct. 13, 2010, 18 pages.
Non-Final Rejection, U.S. Appl. No. 10/923,598, mailed on Oct. 15, 2008, 15 pages.
Non-Final Rejection, U.S. Appl. No. 10/923,598, mailed on Sep. 25, 2009, 15 pages.
Notice of First Office Action by Shanghai Patent & Trademark Office, Application No. 200410090196.4, Oct. 24, 2008, 10 pages.
Office Action by Mexican Patent Office, Application No. PA/a/2004/010559, May 28, 2009, 10 pages.
Official Action by Patent Office of the Russian Federation, Application No. 2004131024, Nov. 20, 2008, 4 pages.
Rosenberg, et al. "SIP: Session Initiation Protocol," Jun. 2002, RFC 3261, pp. 1-252.
Rosoff, Matt "The disintegration of the confused instant messaging products," Directions on Microsoft, No. 17, pp. 42 to 44, Media Select, Inc., Japan, Apr. 15, 2003.
Sridhar et al. "Standard SIP-based instant messaging and presence APIs for networked devices."; Proceedings 5th IEEE International Workshop on Networked Appliances (Cat. No. 02EX635), 2002, p. 59-64. *
USPTO Amendment filed Dec. 28,2009 , in U.S. Appl. No. 10/923,598 (8 pages).
USPTO Amendment filed Jan. 13, 2011, in U.S. Appl. No. 10/923,598 (17 pages).
USPTO Amendment filed Jan. 15, 2009, in U.S. Appl. No. 10/923,598 (11 pages).
USPTO Amendment filed Jul. 15, 2009, in U.S. Appl. No. 10/923,598 (11 pages).
USPTO Amendment filed Jun. 17, 2010, in U.S. Appl. No. 10/923,598 (11 pages).
USPTO Final Rejection mailed Mar. 16, 2011, in U.S. Appl. No. 10/923,598 (18 pages).
Yamaguchi Manabu, "The new communication world created by Windows Messenger and RTC," Enterprise Servers WORLD, vol. 5, No. 6 (Serial No. 47), pp. 69 to 72, IDG Japan, Inc., Japan, Jun. 1, 2002.
EP1526695A1 (en) 2005-04-27
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HAN, MU;GANESAN, KRISHNAMURTHY;POTRA, ADRIAN;AND OTHERS;REEL/FRAME:015454/0015;SIGNING DATES FROM 20041213 TO 20041214
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HAN, MU;GANESAN, KRISHNAMURTHY;POTRA, ADRIAN;AND OTHERS;SIGNING DATES FROM 20041213 TO 20041214;REEL/FRAME:015454/0015