KR101122801B1 - Collaborative invitation system and method - Google Patents

Abstract

Architecture 300 may include a cooperative service platform 302. The cooperative service platform 302 includes contact management service 304, publishing service 306, signaling service 308, activity service 310, data sharing service 312, authentication service 314, and connectivity service 316. ) May be included. Contact management service 304 may include contact storage 318, presence storage 320, and contact location service 322. Publishing service 306 may include synchronization service 324. The signaling service 308 may include an invitation service 326. Activity service 310 may include an audiovisual (A / V) service 328. Connectivity service 316 may include a peer to peer (P2P) service 330 and a conventional transmission control protocol and Internet protocol (TCP / IP) stack 332. Each service 304, 306, 308, 310, 312, 314, 316 may include and / or be incorporated into a peer capable of sending and receiving messages implementing the service.

Collaboration Services Platform, Collaboration Application, Invitation User Interface, Invitation Send Element, Invitation Response Element, Invitation Delete Element

Description

Cooperation invitation system and method {COLLABORATIVE INVITATION SYSTEM AND METHOD}

TECHNICAL FIELD The present invention generally relates to networked computing environments and, more particularly, to collaboration that is facilitated in networked computing environments.

Networked computing environments have become a common feature of work and even homes. This environment facilitates various communication modes including e-mail, instant messaging, multimedia document servers, discussion groups, as well as streaming audio and video, and immersive interactive sensory environments. Conventional software applications have begun to use these rich communication modes, but each has limitations and / or disadvantages when considered in terms of an integrated, scalable, computerized collaboration platform.

Some conventional computer software applications provide aspects of collaborative services, but do not provide effective access to collaborators. Clumsy and / or limited access to collaborators can impede initiation of collaboration, preventing the use of other functional collaboration tools. An aspect of ineffective access to collaborators is that some conventional software applications do not effectively identify current physical and / or virtual locations. Another aspect is that some conventional software applications do not effectively identify compatibility with respect to collaborative functions.

In addition to deficiencies in the functionality of certain deployments of conventional software applications that provide aspects of collaborative services, some conventional software applications are not prepared for scalable collaborative platforms, frameworks, and / or architectures. This is by no means a minor fault. An effective architecture can take years to incorporate into a network computing environment with countless nodes. The obstacles of scalability, flexibility, maintainability and / or scalability of established architectures can be even more important than in a single software product deployment.

This section provides a simplified summary of some embodiments of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key / critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some embodiments of the invention in a simplified form as a prelude to the more detailed description that is presented later.

In embodiments of the present invention, one or more contacts may be selected as an invite user interface, such as a graphical user interface (GUI). The invitation to join the cooperative activity may be sent to the selected contact from the invitation user interface or from the cooperative application, for example from a cooperative application that facilitates the cooperative activity. Whether the invitation was sent from the invitation user interface or from the collaboration application may be a configurable option. If the invitation can be sent from the invitation user interface, the collaboration application can be launched, and then the invitation can be sent from the invitation user interface. If the invitation can be sent from the cooperative application, the cooperative application can be initiated, and then the invitation can be sent from the cooperative application.

In an embodiment of the present invention, an invitation to join a cooperative application may be received by, for example, a cooperative service platform. The user of the cooperative service platform may be presented with the ability to select one of accept, refuse and ignore in response to the invitation. The user can choose to accept, refuse or explicitly ignore the invitation, and a response can be sent to the sender of the invitation indicating the user's choice.

In an embodiment of the invention, the application programming interface for the cooperative invitation service includes an invitation element, an invitation sending element, a response to the invitation element, and an invitation deletion element. The invitation element can provide access to invitation data corresponding to an invitation to participate in a collaborative activity. The invitation sending element can be used to send a collaboration invitation to one or more contacts. The reply to invitation element can be used to respond to a collaboration invitation, and the delete invitation element can be used to delete a sent invitation.

While the appended claims illustrate features of the invention with specificity, the invention and its advantages are best understood from the following detailed description made with reference to the accompanying drawings.

1 is a schematic diagram generally illustrating an exemplary computer system that can be used to implement an embodiment of the invention.

2 is a schematic diagram illustrating an exemplary networked computing environment suitable for incorporating embodiments of the present invention.

3 is a block diagram illustrating an exemplary computer software architecture for a collaborative services platform, in accordance with an embodiment of the invention.

4 is an object modeling diagram illustrating an exemplary cooperating object model in accordance with an embodiment of the present invention.

5 is an object interface diagram illustrating an exemplary contact object in accordance with an embodiment of the invention.

FIG. 6 is an object interface diagram illustrating an example presence object in accordance with an embodiment of the present invention. FIG.

FIG. 7 is an object interface diagram illustrating an exemplary published object in accordance with an embodiment of the present invention. FIG.

FIG. 8 is an object interface diagram illustrating an example capability object in accordance with an embodiment of the present invention. FIG.

9 is an object interface diagram depicting an exemplary MeContact object, in accordance with an embodiment of the invention.

10 is an object interface diagram depicting an example conference object, in accordance with an embodiment of the invention.

11 is a flowchart illustrating exemplary steps performed by a cooperative service platform, in accordance with an embodiment of the invention.

12 is a flowchart illustrating other exemplary steps performed by a cooperative service platform, in accordance with an embodiment of the present invention.

13 is a schematic diagram illustrating an exemplary invitation scenario in accordance with an embodiment of the present invention.

14 is a schematic diagram illustrating an exemplary invitation service application programming interface in accordance with an embodiment of the present invention.

15 is a flowchart illustrating exemplary steps for sending an invitation, in accordance with an embodiment of the invention.

FIG. 16 is a flowchart illustrating exemplary steps performed by an invitation service to send an invitation, in accordance with an embodiment of the present invention. FIG.

FIG. 17 is a flowchart illustrating exemplary steps in response to an invitation from a generic invitation user interface, in accordance with an embodiment of the present invention. FIG.

FIG. 18 is a flowchart illustrating exemplary steps in response to an invitation from an application specific user interface, in accordance with an embodiment of the present invention. FIG.

FIG. 19 is a flowchart illustrating exemplary steps for participating in serverless presence publishing, in accordance with an embodiment of the present invention. FIG.

20 is a flowchart illustrating exemplary steps for subscribing to a cooperative presence subscription, in accordance with an embodiment of the present invention.

21 is a flowchart illustrating exemplary steps for accepting a cooperative presence subscription, in accordance with an embodiment of the present invention.

Before describing various embodiments of the present invention, a description is now given of a computer on which various embodiments of the present invention may be practiced. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, programs include routines, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The term "program" as used herein may encompass a single program module or multiple program modules working together. The terms "computer" and "computing device" as used herein refer to personal computers (PCs), hand-held devices, multiprocessor systems, microprocessor-based programmable consumer electronics, network PCs, minicomputers, tablet PCs, laptop computers. And any device that electronically executes one or more programs, such as consumer electronics, routers, gateways, hubs, etc., having a microprocessor or microcontroller. The invention may also be used in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, programs can be located in both local and remote memory storage devices.

Referring to FIG. 1, an example of a basic configuration of a computer 102 in which aspects of the invention described herein may be implemented is shown. In the most basic configuration, computer 102 typically includes at least one processing unit 104 and memory 106. Processing device 104 executes instructions to perform a task in accordance with various embodiments of the present invention. In performing such tasks, the processing device 104 may transmit electronic signals to other portions of the computer 102 and to devices external to the computer 102 to produce certain results. Depending on the exact configuration and type of computer 102, memory 106 may be volatile (such as RAM), nonvolatile (such as ROM or flash memory), or some combination of the two. This most basic configuration is shown by dashed line 108 in FIG. 1.

Computer 102 may also have additional features / functions. For example, computer 102 may also include additional storage devices (removable 110 and / or non-removable 112), including but not limited to magnetic or optical disks or tapes. Can be. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information including computer executable instructions, data structures, program modules or other data. Computer storage media may include RAM, ROM, EEPROM, flash memory, CD-ROM, digital versatile disk (DVD) or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or computer 102. It includes but is not limited to any other medium that can be accessed by and used to store desired information. All such computer storage devices may be part of computer 102.

Computer 102 preferably also includes a communication connection 114 that allows the device to communicate with other devices, such as remote computer (s) 116. The communication connection is an example of a communication medium. Communication media typically embody computer readable instructions, data structures, program modules or other data on modulated data signals, such as carrier waves or other transport mechanisms, and all information transfer media. It includes. By way of example, but not limitation, the term "communication medium" includes wireless media such as acoustic, RF, infrared and other wireless media. The term "computer readable medium" as used herein includes both computer storage media and communication media.

Computer 102 may also have an input device 118, such as a keyboard / keypad, mouse, pen, voice input device, touch input device, or the like. Output devices 120 such as displays, speakers, printers, etc. may also be included. All such devices are well known in the art and need not be described in detail here.

In the following description, the invention will be described with reference to symbolic representations and acts of operations performed by one or more computing devices, unless otherwise indicated. As such, it will be understood that such acts and operations, sometimes referred to as computer execution, include the manipulation by the computer's processing apparatus of electrical signals representing data in a structural form. This manipulation process transforms the data or maintains it in a location within the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner well known to those skilled in the art. The data structure in which data is maintained is the physical location of memory with specific attributes determined by the data format. However, although the invention has been described in the foregoing context, it is not intended to be limiting, as those skilled in the art will understand that various acts and operations described below may be implemented in hardware.

In an embodiment of the invention, the computer software architecture provides a collaborative platform that is scalable, flexible, maintainable and scalable. Aspects of the architecture can be incorporated into suitable networked computing environments. The architecture may enable and / or extend integration with traditional computer software applications. In particular, the architecture may provide comprehensive collaborative contact management, including current contact presence in a networked computing environment and current contact capabilities, for example with respect to available cooperative activities.

2 illustrates an example networked computing environment 200 suitable for embodying an embodiment of the present invention. In a networked computing environment, network 202 connects computers 204, 206, and 208 to networking hub 210 in communication. The network 202 may be a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a personal area network (PAN), or a combination thereof. Network 202 may include any suitable computer readable medium, as well as any suitable networking component such as hubs, gateways, routers, bridges, ports, and the like. For example, computers 204, 206, and 208 and networking hub 210 may each be an instance of computer 102 (FIG. 1).

Networking hub 210 may connect computers 212, 214, and 216 in communication. The networking hub 210 and the computers 212, 214, and 216 may, of course, be considered as examples of sub-networks or subnets 218, although not by way of limitation. Computers 212, 214, and 216 are said to be on the same subnet, and as a result can enjoy privileged network communication with each other. For example, even though each computer 204, 206, 208, 212, 214, and 216 can send a point-to-point type of message to another computer 204, 206, 208, 212, 214, and 216, respectively, the subnet 218 may be configured such that broadcast type messages in subnet 218 are received by these computers 212, 214, and 216 in subnet 218.

The nature of extensibility, flexibility, maintainability, and / or scalability of a collaborative platform may be defined by one or more aspects of the mode of interaction between its modular structure, its modular structure as a whole, its modular structure as a whole, and / or its interaction patterns. Can result from. 3 illustrates an example computer software architecture 300 in accordance with an embodiment of the present invention. Each aspect of architecture 300 may exist in each computer 204, 206, 208, 212, 214, and 216 (FIG. 2), but each embodiment of the present invention is not so limited. Aspects of the architecture 300 may be suitably distributed throughout any suitable subset of the networked computing environment 200, including the networked computing environment 200 as a whole. Different versions of architecture 300 may exist on different computers, and the degree to which each version of architecture 300 is compatible with each other version of architecture 300 may vary.

Architecture 300 may include a cooperative service platform 302. The cooperative service platform 302 may include contact management services 304, publishing services 306, signaling services 308, activity services 310, data sharing services 312, authentication services 314, and connectivity services ( 316). Contact management service 304 may include contact storage 318, presence storage 320, and contact location service 322. Publishing service 306 may include synchronization service 324. The signaling service 308 may include an invitation service 326. Activity service 310 may include an audiovisual (A / V) service 328. Connectivity service 316 may include a peer-to-peer (P2P) service 330, and a conventional transmission control protocol and Internet protocol (TCP / IP) stack 332. Each service 304, 306, 308, 310, 312, 314, 316 may include and / or be incorporated into a peer capable of sending and receiving messages implementing the service.

In an embodiment of the present invention, contact management service 304 provides effective access to collaborators, ie, users of collaborative service platform 302. For example, contact management service 304 may provide contact information to some or all of the users of cooperative service platform 302. Contact management service 304 may maintain a database of contacts within one or more data stores. Each contact may be a potential collaborator, ie a user of a collaborative service platform may attempt to initiate one or more collaborative activities with each contact. Contact management service 304 may, for example, present a graphical user interface (GUI) representing a contact for selection by the user and / or to allow the user to invoke a cooperative service platform 302 action on a particular contact. One or more user interfaces may be provided.

The contact storage 318 may store a contact object and a “MeContact” object (described below in more detail with respect to FIG. 4). The presence storage 320 may store a presence object (also described in more detail with respect to FIG. 4) for the contact object. In an embodiment of the present invention, the presence data is changed more frequently than the contact data so that separate data stores 318 and 320 can be optimized for different object update frequencies.

Contact location service 322 may provide one or more of a variety of location data for a given contact. Physical proximity may be an aspect of contact location, for example, one or more proxies relative to the physical location may be used to assess the physical distance of the contact from the user. Signal strength at the wireless receiver is an example of a physical distance proxy. The virtual location may be another aspect of the contact location. For example, the contactor may be active in one or more networks, such as network 202 of FIG. 2, and / or in one or more network nodes, such as computers 204, 206, 208, 212, 214, and 216. In addition, the contact may be registered but inactive, online but not found, or may have some other suitable location state. Contact location service 322 may query the appropriate registry and / or initiate a peer-to-peer search or peer-to-peer name resolution mechanism, for example, to locate a particular contact.

The publishing service 306 can provide access to the data published by the contact. In an embodiment of the present invention, an interested user can subscribe to an object published by a contactor and receive a notification whenever the published object is updated by the publishing contact. The synchronization service 324 may be responsible for maintaining a database of publication subscriptions. In particular, the publishing service 206 can provide access to the presence information issued by the contact.

The signaling service 308 may provide for the establishment and termination of cooperative meetings between contacts in the networked computing environment 200 (FIG. 2), as well as updating parameters of ongoing meetings. In an embodiment of the present invention, setting up, updating, and terminating cooperative meetings is provided according to publish / subscribe semantics. In an embodiment of the present invention, the signaling service 308 is described by SIP (Session 1999) described in "Session Initiation Protocol", Internet Engineering Task Force (IETF) Request for Comments (RFC) 2543 (March 1999) by Handley et al. initiation protocol, such as an initiation protocol).

Invitation service 326 may enable invitations and related messages to be sent to / from the contact. For example, a system user accessing the networked computing environment 200 (FIG. 2) from one computer 212 may be a contact at some other computer (s) 204, 206, 208, 212, 214 and / or 216. You can invite them to participate in collaborative activities. The invitation service 326 can include various user interfaces, such as a graphical user interface (GUI) that presents the invite details to the invitee and allows the invitee to accept, refuse, and / or explicitly ignore the invite. Exemplary invitation service 326 is described below in more detail with respect to FIG.

Activity service 310 may implement cooperative activities and / or provide support for integration of cooperative applications into cooperative service platform 302. For example, activity service 310 may provide a cooperative service platform 302 compliant application programming interface (API) to a conventional cooperative application. The compliance API may include the ability to query a specific contact or computer 204, 206, 208, 212, 214, 216 (FIG. 2) regarding activity capability and identify application-specific invitation requirements. Audiovisual service 328 is an example of cooperative activity suitable for incorporation into activity service 310.

Data sharing service 312 may enable sharing of data in any suitable format, including files, documents, streams, and objects. The data sharing service 312 may provide data transfer, data replication, and / or data synchronization. Data sharing is enabled and disabled based on contacts, participation in activities, participation in meetings, and / or any suitable access control list (ACL) entries, such as user groups in the networked computing environment 200 (FIG. 2). Can be.

Authentication service 314 may supply and verify certificates, such as certificates for contacts and certificates for other activities and meetings. Authentication service 314 may cause the contacts to be classified as trusted contacts and untrusted contacts. Authentication service 314 allows the contact to be trusted regardless of the contact location and / or in accordance with the sophisticated networked computing environment 200 (FIG. 2) presence.

In an embodiment of the invention, the connectivity service 316 may be configured to communicate between the cooperative service platform 302 service instances throughout the networked computing environment 200 (FIG. 2), for example, at the computer 212. Enable communication between the first signaling service 308 instance and the second signaling service 308 instance at the computer 208. The communication facility of the connectivity service 316 may be configured to provide an application programming interface such that other cooperative service platform 302 services 304, 306, 308, 310, 312, and 314 may communicate between instances regardless of the underlying transport mechanism. API).

Connectivity service 316 is available from the Microsoft® Developer Network (MSDN?) Library (March 2005). Windows? Windows in the Platform Software Development Kit (SDK). Microsoft? Described in the Sockets 2 section. Windows? A high level communication application programming interface such as Sockets 2 (Winsock) API and / or TCP / IP stack 332. Peer-to-peer (P2P) service 330 may provide connectivity within an overlay network of network computing environment 200. For example, peer-to-peer service 300 includes a graphing, grouping, identification manager, and peer name resolution protocol (PNRP) namespace provider application programming interface, including the Microsoft Developer Network (MSDN?) Library (2005). Microsoft in March? Windows? Windows in the Platform Software Development Kit (SDK). It can be provided according to the peer-to-peer application programming interface described in the Peer-to-Peer Networking section.

The services 304, 306, 308, 310, 312, 314, and 316 of the cooperative service platform 302 may be implemented as a set of program objects that include a cooperative object set related to each other in the cooperative object model. 4 illustrates an example cooperative object set and an example cooperative object model 400 in accordance with an embodiment of the present invention. The collaboration object model 400 includes contact objects 402, presence objects 404, MeContact objects 406 and MyPresence objects 408, endpoint objects 410, capabilities objects 412, conference objects 414. ), Activity object 416 and published object 418. Of course, the cooperative service platform 302 may include multiple instances of each type of cooperative object 402, 404, 406, 408, 410, 412, 414, 416, and 418.

The contact object 402 may include suitable attributes representing the cooperative participants and / or users of the cooperative service platform 302 (FIG. 3). In particular, the contact object 402 can refer to the cooperative presence, for example the presence of the contact, in the networked computing environment 200 (FIG. 2). In an embodiment of the invention, the contact object 402 refers to the cooperative presence by referring to an instance of the presence object 404. Exemplary contact object 402 is described below in more detail with respect to FIG. 5.

The presence object 404 is a computer 204, 206, 208, 212, 214 and / or 216 of a cooperative presence, for example, a networked computing environment 200 in which a particular cooperative service platform 302 user has been active sometime in the past. (FIG. 2) may include suitable attributes representing the set, where the "last" past may vary depending on the context of cooperation, from seconds to hours, days, or even years. The presence object 404 may reference one or more endpoint object 410 instances representing the networked computing environment 200 location. Because the endpoint object 410 may correspond to, for example, a peer in the overlay network of the networked computing environment 200, the endpoint object 410 may be associated with the computers 204, 206, 208, 212, 214, 216 of the networked computing environment 200. There is no need for a one-to-one correspondence.

Presence object 404 may include, for example, zero or more capability object 412 instances representing cooperative capabilities at one or more cooperative endpoints, and / or collective cooperative capabilities across some or all endpoints associated with presence object 404. See further. In addition, the presence object 404 may reference zero or more published object 418 instances. Exemplary presence object 404 is described in more detail below with respect to FIG. 6. Exemplary published object 418 is described below in more detail with respect to FIG. Exemplary capability object 412 is described in more detail below with respect to FIG. 8.

MeContact object 406 may be a type of contact object 402 and may inherit the properties and behavior of contact object 402 in various forms. The MeContact object 406 can be distinguished from the contact object 402 due to the specific role that the contact information of the cooperative service platform user can play for the contact information of another user. For example, the MeContact object 406 can reference zero or more contact object objects 402 instances representing known cooperative contacts of a particular user. MeContact object 406 does not need to refer to another MeContact object 406 instance, for example. In embodiments of the present invention, unnecessary complexity is thus avoided, contributing to the scalability, flexibility, maintainability, and / or scalability of the cooperative service platform 302 (FIG. 3).

The MeContact object 406 may further reference the MyPresence object 408 instance. MyPresence object 408 may be one type of presence object 404 and may inherit the properties and behavior of presence object 404 in various forms. Again, the MyPresence object 408 can be distinguished from the presence object 404 due to the specific role the cooperative service platform user's own presence can play for the presence of other users. For example, in an embodiment of the invention, a user may explicitly update his own MyPresence object 408 instance, but not another user's presence object 404 instance.

In addition, the MeContact object 406 may refer to zero or more instances of the meeting object 414 that represent a collaboration meeting with which the user associated with the MeContact object 406 is currently and / or recently joined with other collaboration service platform users. have. The meeting object 414 may reference one or more activity object 416 instances representing the cooperative activity. In an embodiment of the invention, the conference object 414 is a type of activity object 416 and may inherit the attributes and behaviors of the activity object 416 in various forms. As a result of being a type of activity object 416, the activity object 416 instance referenced by the meeting object 414 may be a meeting object 414 instance. Exemplary MeContact object 406 is described in more detail below with respect to FIG. 9. Exemplary conference object 414 is described below in more detail with respect to FIG. 10.

Each cooperating object 402, 404, 406, 408, 410, 412, 414, 416, and 418 is a suitable lookup of attributes of the cooperating object 402, 404, 406, 408, 410, 412, 414, 416, and 418. In addition to handling operations, an application programming interface may be provided for creating and deleting instances of cooperative objects 402, 404, 406, 408, 410, 412, 414, 416, and 418. In an embodiment of the invention, the cooperative objects 402, 404, 406, 408, 410, 412, 414, 416, and 418 are different cooperative objects 402, 404, 406, 408, 410, 412, 414, 416, and 418. When described as referring to a reference object, a referenced object or a copy thereof may instead be incorporated into and / or incorporated into the referencing object. One program object may refer to another program object with any suitable program reference mechanism. Suitable program reference mechanisms include pointers, explicit references, related hash codes, and equivalents, as well as programming language features specifically designed for the purpose.

The program objects 402, 404, 406, 408, 410, 412, 414, 416 and 418 introduced above in connection with FIG. 4 are now described in more detail. Each program object 402, 404, 406, 408, 410, 412, 414, 416, and 418 may include one or more application programming interface elements. Each application programming interface element comprises a computer object 102 (FIG. 1) system component, including a cooperative service platform 302 (FIG. 3) service, with program objects 402, 404, 406, 408, 410, 412, 414, 416 and 418 may include one or more interface specifications that specify how it can configure, control, and / or interact with its program objects. As will be apparent to those skilled in the art, the interface specification may be an object property specification, a variable specification, a function call specification, a program object specification, a message specification such as a request / response message pair, and / or any other suitable programming. It may include an interface specification.

5 illustrates an example contact object 500 in accordance with an embodiment of the present invention. The contact object 500 is suitable for incorporation into the cooperative object model 400 (FIG. 4). The contact object 500 may include an application programming interface element including a name element 502, a presence element 504, a buddy flag element 506, and a proximity element 508.

The name element 502 can include a friendly name for the contact associated with the contact object 500. The friendly name can be encoded, for example, as a rich text string. Presence element 504 may include a reference to the presence object 404 (FIG. 4) instance.

The buddy flag element 506 may include an indicator that a contact associated with the contact object 500 is classified as a “buddy” class contact. Contacts classified as buddies can be privileged in several ways. For example, a buddy may be a trust contact, a buddy may be given priority, for example an invitation priority, and the buddy may be automatically included in a set of contacts to which a cooperative service platform user subscribes to, for example, presence data. . Buddy class contacts may be more computationally expensive than normal contacts, and their number may be limited, for example, to tests embedded in the buddy flag application programming interface element 506.

Proximity element 508 may include a physical proximity metric and / or a virtual proximity metric. For example, the physical proximity metric can be a measure of signal strength received at the wireless network interface. Of course, the proximity application programming interface element 508 need not be limited to a single metric in response to the proximity query. For example, the proximity query may request a raw proximity metric, a time-averaged proximity metric, a quantized proximity metric (“signal strength bar”), and / or any suitable proximity metric.

6 illustrates an example presence object 600 in accordance with an embodiment of the present invention. The presence object 600 is suitable for incorporation into the cooperative object model 400 (FIG. 4). Presence object 600 includes rich text description element 602, endpoint element 604, aggregate state element 606, aggregate capability element 608, published object element 610, invitation element to new activity 612. ), An application programming interface element including an invitation element 614 to an existing activity, a capability finding element 616 by type, a published object finding element 618 by type, and a publishing object element 620. Can be.

The rich text description element 602 may include a rich text string describing the presence of the networked computing environment 200 (FIG. 2) associated with the presence object 600. Simple examples may include "Currently in Building 9", "Playing Halo ?, Level 4", and "Unavailable". The endpoint element 604 may include a set of cooperative endpoints that are active participants, recently active participants, and / or active participants in one or more cooperative activities. Examples of suitable cooperative endpoints may include computers 204, 206, 208, 212, 214, and 216, and peers in an overlay network of networked computing environment 200.

Aggregate state element 606 may include an aggregate presence status indicator that represents the cooperative presence across the cooperative endpoint set. Each cooperative endpoint may have an associated presence state, for example ONLINE, AWAY, OUT TO LUNCH, BE RIGHT BACK, IDLE, ON THE PHONE or BUSY. The aggregate presence state associated with the end point set need not be the same as the state associated with any one of the end points in the set. The collective presence state may be different from one or more of the other endpoints, even if it is the same as at least one of the endpoints in the set.

The aggregate presence state may be determined by one or more of the various aggregate presence state algorithms. The presence state level can be ranked, and the aggregate state can be set to the highest ranking state within the endpoint set. The aggregate state may be a weighted average of the individual state values, or other suitable linear or nonlinear transformation of the individual state values. Individual state values may also be appropriately classified before conversion. The aggregate presence state algorithm used may depend on the number of individual endpoints in the set.

Aggregate capability element 608 may include a collection of aggregate capabilities associated with a cooperative presence. Each individual endpoint in the cooperative presence may associate with it a set of capabilities, eg, a cooperative activity. The aggregate capability may be a simple aggregate of each capability of each individual endpoint. On the other hand, the collection of aggregate capabilities may be limited to those capabilities that exist at each individual endpoint. Just as more sophisticated aggregate capability determination algorithms are possible, a combination of these extremes is possible. For example, the collection of aggregate capabilities may be the result of weighted average processing, or may be the result of other suitable linear or nonlinear transformations of the capabilities of individual endpoints. In addition, an aggregate capability rank or percentage may be associated with each capability in the aggregate capability collection.

The published object element 610 may include a collection of published objects associated with the cooperative presence. Competency object 412 (FIG. 4) may be one type of published object 418, although both are typically associated with an instance of competency object 412 that has a long lifetime (eg, days, weeks In contrast, even years, published data associated with an instance of a basic published object 418 is typically short-lived (eg, seconds, minutes or hours). This distinction can be used to optimize computer system performance.

Invite to New Activity Element 612 may enable a user of cooperative service platform 302 (FIG. 3) to invite a contact associated with the presence object 600 to join a new cooperative activity. The associated meeting that hosts the activity may not yet exist and may be created if the invitation is accepted. The invitation can be delivered to each endpoint referenced by the endpoint element 604, only for those endpoints associated with the ONLINE presence status, the invitation is determined in order, for example by the presence status associated with each endpoint in that order. In order, or in another suitable invitation delivery strategy, they may be delivered to each endpoint associated with the cooperative presence.

Invite to Existing Activity Application programming interface element 614 may be desirable when inviting a contact to attend an existing meeting and / or activity. When meetings and / or activities are already established, some collaboration parameters may or may not be negotiated, for example only within the scope determined by the collaboration parameters in use by current participants. Can be. In addition, less flexibility may limit the end point of presence that is capable of participation, and therefore, a candidate to be invited.

The capability finding element 616 by type may enable a user of the collaborative services platform 302 (FIG. 3) to query the presence associated with the presence object 600 to find capabilities related to one or more of a number of capability types. have. Examples of capability types include application types such as chat, audio, and video; Application capabilities such as audio output, audio input, video output, video input; Endpoint resources such as bandwidth, audio quality and video resolution; Or any suitable type of cooperative capability. The capability finding element 616 by type may respond to the query with the capability of the individual endpoint and / or the aggregate presence capability.

Published object finder element 618 by type allows the cooperative services platform 302 (FIG. 3) user to locate published objects associated with the presence, for example, published objects associated with published object element 610. It may be possible to query the presence associated with the object 600. The object type issued can be determined by the associated rich text string. For example, those issued object 418 (FIG. 4) instances associated with the same rich text string may be determined to be of the same type.

The publish object element 620 may enable publishing of data related to the presence. For example, the presence object set maintained by the issued object element 610 may be updated. In an embodiment of the invention, the publishing object application programming interface element 620 may be incorporated into the published object application programming interface element 610.

7 illustrates an example published object 700 according to an embodiment of the invention. The published object 700 is suitable for incorporation into the cooperative object model 400 (FIG. 4). The published object 700 may include an application programming interface element that includes an authorized subscriber element 702 and a published data element 704.

Authorized subscriber element 702 may reference one or more contactor object 402 (FIG. 4) instances associated with a contact authorized to subscribe to data associated with published object 700. Data access control can be roughly divided into, for example, permit or block, or can be finely divided, including, for example, control over data creation, read, update, and delete privileges. The published data element 704 may maintain a published data set associated with the published object 700. Any suitable data set may be published in connection with the published object 700.

8 illustrates an example capability object 800 in accordance with an embodiment of the invention. The capability object 800 is suitable for incorporation into the cooperative object model 400 (FIG. 4). The capability object 800 can include an application programming interface element that includes an associated application element 802 and an application data element 804.

The associated application element 802 may include a reference to a set of collaborative applications that implement the capability associated with the capability object 800. The application data element 804 may include data and / or data specifications needed to construct each of the cooperative application sets referenced by the associated application element 802.

9 illustrates an exemplary MeContact object 900 in accordance with an embodiment of the present invention. The MeContact object 900 is suitable for incorporation into the cooperative object model 400 (FIG. 4). MeContact object 900 includes contact element 902, buddy element 904, privileged subscriber element 906, active subscriber element 908, conferencing element 910, capability finding element 912 by type, and It may include an application programming interface element that includes a published object finder element 914 by type.

The contactor element 902 may include a reference to a set of contactor objects 402 (FIG. 4) associated with a contact known to the user of the collaboration service platform 302 (FIG. 3) associated with the MeContact object 900. The buddy element 904 is known to the user of the cooperative service platform 302 (FIG. 3) and, for example, as shown by the buddy flag element 506 (FIG. 5) of the contactor object 500, also the buddy class. It may include a reference to a set of contact object 402 (FIG. 4) associated with the contact that is the contact. A simple presence in the set of contact object 402 instances referenced by the buddy element 904 may indicate that the associated contact is a buddy class contact. The contact object 402 instance sets referenced by the contact element 902 and the buddy element 904 may overlap, but in at least one embodiment of the invention, these sets are exclusive.

Privileged subscriber element 906 may include a reference to a set of contactor objects 402 (FIG. 4) associated with contactors authorized to subscribe to published data associated with MeContact object 900, such as capability data. have. Published data access control can be broadly divided into, for example, blocking or allowing access to all published data, or creating, reading, updating and / or deleting, for example, each published object 418. Can be subdivided into privileges, or a combination thereof.

The active subscriber element 908 is a reference to a set of contactor object 402 instances associated with the contactor who will actively subscribe to data published by the user of the collaborative services platform 302 (FIG. 3) associated with the MeContact object 900. It may include. Of course, the contactor object 402 instance referenced by the active subscriber element 908 must conform to the permissions maintained by the authorized subscriber element 906.

The conferencing element 910 is a conferencing service platform 302 (FIG. 3) associated with the MeContact object 900 (FIG. 3) the meeting object 414 that the user has recently joined, and / or the meeting with which the user will soon join. (FIG. 4) may include a reference to a set of instances.

The capability finding element 912 by type may enable a user of the collaborative services platform 302 (FIG. 3) to query contacts associated with the MeContact object 900 to find capabilities associated with one or more of a number of capability types. have. For example, the capability finding element 912 by type may query the contactor element 902, the buddy element 904, and / or the contactor object 402 (FIG. 4) instance referenced by the MeContact object 900 itself. can do. The capability finding element 912 by type may respond to the query with the capabilities and / or aggregate capabilities of the individual endpoints. The published object finder element 914 by type may enable a user to query a contact associated with the MeContact object 900 to find published data. As with the capability finding element 912 by type, the published object finding element 914 by type is a publication referenced by the contactor element 902, the buddy element 904, and / or the MeContact object 900 itself. Retrieved object 418 instance.

10 illustrates an example conference object 1000 in accordance with an embodiment of the present invention. The conference object 1000 is suitable for incorporation into the cooperative object model 400 (FIG. 4). The conference object 1000 may include an application programming interface element including a session information element 1002, an activity element 1004, an administrator element 1006, an authorized member element 1008, and an initiation activity element 1010. have.

In an embodiment of the present invention, the role of a meeting, eg, a meeting associated with the meeting object 1000, is to organize, manage, and / or manage one or more collaborative activities in which one or more collaborative services platform 302 (FIG. 3) users participate. Or maintenance. Session information element 1002 may include conference level session information. Performance optimization can be achieved by collecting activity level session information at the conference level. Activity element 1004 may include a reference to one or more activity object 416 (FIG. 4) instances.

Manager element 1006 may reference one or more contactor object 402 (FIG. 4) instances associated with a contact authorized to act as a manager of the conference. Administrative privileges may include the addition and removal of authorized participants and / or activities. Privileged member element 1008 may reference one or more contactor object 402 instances associated with a contact authorized to participate in an activity related to the meeting. Authorization can be broadly divided, for example to allow or block specific contacts from participating in all meeting activities, or elaborately divided, for example, to entitle new activities or terminate existing activities. One, fully participating in an individual activity, or participating in a limited manner (eg, "observer status"), or a combination thereof.

Initiation activity element 1010 may add new activities to the meeting. Joining and leaving an activity can be managed by a meeting, by an activity, or by a combination of both. In each case, the conference object 1000 application programming interface element may enforce in accordance with the administrator element 1006 and / or the authorized member element 1008.

For example, the detailed method performed by the cooperative service platform 302 (FIG. 3) and in accordance with the cooperative object model 400 (FIG. 4) is now described. 11 illustrates exemplary steps performed by the cooperative service platform 302, in accordance with an embodiment of the present invention. At step 1102, a contactor object 402 instance may be selected. For example, a contact object 402 instance stored in contact storage 318 may be selected as the user interface of contact management service 304.

At step 1104, the selected contact object 402 (FIG. 4) instance may be queried to find the presence object 404 instance associated with it. For example, the presence element 504 (FIG. 5) of the selected contact object 500 may be used to access the associated presence object 404 instance.

In step 1106, it may be determined whether a contact associated with the selected contact object 402 (FIG. 4) instance exists in the networked computing environment 200 (FIG. 2). For example, the collective presence state of the contact may be obtained from the aggregate state element 606 of the presence object 600 retrieved in step 1104, and if the contact presence state of the contact is ONLINE, the contact is determined to be present. Can be. If it is determined that the contact exists, the procedure may proceed to step 1108. Otherwise, the procedure may end. Contact is not available for cooperation at this time.

Alternatively, steps 1104 and 1106 can be replaced by subscribing to the presence information of the selected contact and waiting for the notification that the selected contact is present before proceeding to step 1008. This alternative is indicated by dashed line 1110.

In step 1108, the selected contact object 402 (FIG. 4) may be queried to find a set of related capability object 412 instances. For example, the capability finding element 606 (FIG. 6) by the type of presence object 404 instance retrieved in step 1104 (and / or 1110) may be used to obtain an appropriate set of capabilities. . The specific set of capabilities to be examined may depend on the target cooperative activity or activities. For example, the attendance conference may confirm audio input capability. At step 1112, it may be determined whether the selected contact has the required capability. If the selected contact does not have the required capabilities, the procedure may proceed to step 1202 of FIG. Otherwise, the procedure may end. Step 1112 need not be limited to simple testing. Step 1112 may include negotiation negotiated by the signaling service 308 (FIG. 3), for example, to determine if any capability set is sufficient for the target activity or activities.

12 illustrates yet another exemplary step performed by the cooperative service platform 302, in accordance with an embodiment of the present invention. The steps of FIGS. 11 and 12 are connected by circles labeled 1114 and 1116. If the selected contact exists in the networked computing environment 200 (FIG. 2) and is able to participate in the desired collaborative activity or activities, one or more invitations may be sent to the selected contact at step 1202. For example, the invitation may be sent by the invitation service 326 (FIG. 3) at the computer 212 (FIG. 2).

At step 1204, one or more invitations may be received by the selected contact. For example, one of the invitations may be received by the invitation service 326 (FIG. 3) at the computer 208 (FIG. 2). At step 1206, the selected contact may respond to one or more invitations. For example, the selected contact may use the user interface of the invitation service 326 at the computer 208 to respond to one of the invitations.

At step 1208, it may be determined whether the invitation has been accepted. For example, the invitation service 326 at the computer 212 can receive the response sent in step 1206, and the response content can determine whether the invitation has been accepted. If the invitation is accepted, the procedure may proceed to step 1210. Otherwise, the procedure may end.

Steps 1204, 1206, and 1208 are indicated by dashed lines 1212 to highlight the possibility of procedural changes in responding to the invitation. One reason for sending multiple invitations for the same activity is that the networked computing environment 200 (FIG. 2) presence of the selected contact may include multiple endpoints. For example, a cooperative service platform 302 (FIG. 3) user can send three invitations for the same activity from computer 212 to computers 216, 206, and 208. For example, the computer 216 may be an office desktop PC of the selected contactor, the computer 206 may be a laptop of the selected contactor, and the computer 208 may be a personal digital assistant of the selected contactor. . The invitation may be displayed to the selected contact at more than one endpoint. For example, the selected contact may refuse or ignore the invitation at computer 208 (PDA in this example), but may accept the invitation at computer 206 (laptop in this example). There is a possibility that the selected contact will not respond to the invitation at all. This may result in timeouts and termination of the procedure.

Another possibility of step 1212 is that the user of the cooperative service platform 302 (FIG. 3) at the computer 212 (FIG. 2) sends an invitation to the activity to each other computer 214 and 216 in the subnet, respectively. . In this case, each contact can respond side by side.

If the invitation has been accepted, at step 1210, the selected contact may attend the relevant meeting for the cooperative activity. For example, the meeting may be hosted by the computer 212 (FIG. 2), and the selected contact may be from the computer 206 using the signaling service 308 (FIG. 3) and / or the activity service 310. Can participate in At step 1214, collaboration, including activity, may occur.

An example of an invitation service 326 (FIG. 3) is now described in more detail. In particular, the interaction between the invitation service 326, the cooperative service platform 302, and the cooperative application platform 302 (although typically referred to by that platform) is highlighted. In an embodiment of the present invention, the processing of such interactions contributes to the usability, scalability, flexibility, maintainability and / or scalability of the cooperative service platform 302, thus contributing to its suitability for large scale adoption.

Figure 13 illustrates an exemplary invitation scenario in accordance with an embodiment of the present invention. The first computer 1302 may be charged with initiating one or more cooperative activities with the second computer 1304. For example, the computers 1302 and 1304 can be any one of the computers 204, 206, 208, 212, 214, or 216 in the networked computing environment 200 of FIG. 2. Each computer 1302 and 1304 can include computer operating systems 1306 and 1308. Each computer operating system 1306 and 1308 may include cooperative service platform modules 1310 and 1312. Computer operating systems 1306 and 1308 need not be identical. The cooperative service platform modules 1310 and 1312 may be in accordance with the cooperative service platform 302 (FIG. 3).

Computer operating systems 1306 and 1308 may include invitation user interfaces (UIs) 1314 and 1316, such as graphical user interfaces (GUIs). In an embodiment of the present invention, invite user interfaces 1314 and 1316 are incorporated into cooperative service platform modules 1310 and 1312, respectively. Computers 1302 and 1304 may further include cooperative applications 1318 and 1320. Although different from the cooperative service platform modules 1310 and 1312 in this example, in an embodiment of the present invention, the cooperative application 1318 and 1320 may be incorporated into the cooperative service platform modules 1310 and 1312.

The basic collaboration invitation protocol may include three messages: a collaboration invitation message 1322, a collaboration response message 1324, and an invitation deletion message 1326.

The collaboration invitation message 1322 may include an invitation identifier, one or more capability identifiers, application data, and a message. The invitation identifier can uniquely identify the invitation. For example, the invitation identifier is Microsoft? Documented in the Developer Network (MSDN?) Library This can be a globally unique identifier (GUID) described in the Guid Structure section of the .NET Framework Class Library, version 1.1.1. Each capability identifier may reference a capability object that represents the cooperative capability required for the capability activity associated with the invitation. For example, each capability identifier may be a globally unique identifier (GUID). Application data may include and / or specify data to be sent to collaborative applications, for example, to initiate collaborative activities. The message can be a rich text string containing standard or order invitation text.

The collaboration response message 1324 may include an invitation identifier, an invitation response action, a response message, and extended response data. The invitation identifier can identify the collaboration invitation with which response message 1324 is responding. For example, the invitation identifier may be a GUID provided by the collaboration invitation message 1322. The invitation response action may indicate the type of response. For example, the invitation response can be one of trimming, accepting, ignoring and error. The response message may be a rich text string containing standard or order invitation response text. The extended response data may include any suitable additional response data regarding invitation and / or collaboration activities.

The invitation deletion message 1326 may include an invitation identifier that identifies the invitation that the deletion message 1326 is deleting. For example, a cooperative invitation message 1322 may be sent from computer 1302 to computer 1304 to invite a user of cooperative service platform 1312 to participate in a cooperative activity with a user of cooperative service platform 1310. Can be. In response, cooperative response message 1324 may be sent from computer 1304 to computer 1302 to indicate whether the invitation is accepted, for example, or refused. In an embodiment of the present invention, it is possible for a user of the cooperative service platform 1310 to delete an invitation by sending an invitation deletion message 1326 from computer 1302 to computer 1304.

Before describing the example collaboration invitation method in more detail, it will be helpful to describe an example application programming interface (API) of the invitation service 326 (FIG. 3). 14 illustrates an example application programming interface (API) 1400 of an invitation service 326 in accordance with an embodiment of the present invention. The invitation service API 1400 includes an invitation element 1402, an invitation listener generation element 1404, an invitation secure transmission element 1406, an invitation insecure transmission element 1408, an invitation deletion element 1410, and a response element to an invitation ( 1412, invitation response acquisition element 1414, capability registration / deregistration element 1416, capability enumeration element 1418, and capability information acquisition element 1420. Respective application programming interface elements 1402, 1404, 1406, 1408, 1410, 1412, 1414, 1416, 1418, and 1420 cooperate with the respective service platform modules 1310 and 1312 at each computer 1302 and 1304 (FIG. 13). Different elements of elements 1402, 1404, 1406, 1408, 1410, 1412, 1414, 1416, 1418, and 1420 may be included in the application programming interface of the invitation service 326 (FIG. 3) incorporated into the computer. It may be used by computers 1302 and 1304 depending on whether 1302, 1304 is an invitee, an invitee, or both.

The invitation element 1402 can include and provide access to some or all of the same data as the collaboration invitation message 1322. For example, the collaboration invitation message 1322 or a portion thereof may be stored in the invitation service 326 (FIG. 3) as an invitation element 1402 and / or retrieved from the invitation service.

The invite listener generation element 1404 can instantiate the invite listener at a cooperative endpoint, such as computers 1302 and 1304 (FIG. 13). Interface specification parameters may include endpoint identifiers (there may be multiple endpoints per computer 1302, 1304), such as Internet Protocol (IP) addresses or P2P peer identifiers, port identifiers (there may be multiple communication ports per endpoint), and It may include an invite listener identifier that configures or destroys the invite listener. For example, the operating system 1308 can use the invite listener creation element 1404 to create an invite listener that listens on a standard invite and / or collaborative service port. The cooperative application 1320 can use the invite listener creation element 1404 to generate an invite listener at an order invite port dedicated to listening for an invitation to cooperate with the cooperative application 1320.

The invitation secure transmission element 1406 may enable secure transmission of the invitation message 1322 (FIG. 13). The interface specification parameter will signal a reference to the contact object 402 (FIG. 4) instance, a reference to the endpoint object 410 instance, a reference to the invitation message 1322 to be sent, and a response to the invitation once received. It may include a reference to a synchronization object of an execution thread, such as an event, and a reference to an invitation identifier to be set by the invitation secure transmission element 1406. The invitation message 1322 can be sent to the contact associated with the referenced contact object 402 instance. If an endpoint object 410 instance is provided, the invitation message 1322 may be sent to the associated endpoint, or the invitation message 1322 may be sent to each endpoint in the presence of a contact associated with the referenced contact object 402 instance. Can be.

Decisions to participate in collaborative activities can have security consequences. For example, the decision to join a two-way file share can expose data to changes and / or deletions. As a result, the user of the cooperative service platform 302 (FIG. 3) can make a decision to accept the cooperative invitation only from a trust source. In an embodiment of the present invention, a secure communication connection can be established between users who have previously exchanged contact information. For example, the contact information can include a cryptographic certificate and the secure communication connection can be established with conventional secure protocols such as secure socket layer (SSL) or secure service provider (SSP) technology for the overlay network.

However, the user can also make a decision to accept an insecure invitation under certain circumstances. The invitation non-secure transmission element 1408 may be similar to the invitation secure transmission element 1406, except for example that there is no requirement that the invite sender and the recipient have contact information exchanged in advance. For example, the invitation insecure transmission element 1408 can be used to broadcast the invitation message 1322 to each computer 212, 214, and 216 (FIG. 2) on the subnet 218. Insecure invitations can promote collaboration and ad hoc cooperation in an easier social environment, such as multiplayer games.

Invitation deletion element 1410 may enable transmission of deletion message 1326 (FIG. 13). The interface specification parameter may include an invitation identifier, such as an invitation identifier of the invite non-secure transmission element 1408 set by the invite secure transmission element 1406. Response element 1412 to the invitation may enable transmission of response message 1324 (FIG. 13). The interface specification parameter may include an invitation identifier and an invitation response action.

Each of the invite secure transmission element 1406 and invite non-secure transmission element 1408 may have a synchronous and asynchronous version. For example, the asynchronous version may send an invitation message 1322 (FIG. 13) and then allow execution of additional instructions in the thread of execution before confirming the response to the invitation. In contrast, the synchronous version may wait without executing another instruction in the thread of execution until a response message 1324 is received or a timeout occurs. The invitation response obtaining element 1414 may be used to confirm and / or wait for a response to the invitation message 1322 sent asynchronously. The interface specification parameter may include an invitation identifier and reference to be set in the response message 1324 when the response message 1324 arrives. The synchronous versions of the invitation sending elements 1406 and 1408 need not include a reference to the thread synchronization object.

The invitation service 1400 may maintain a registry of endpoint capabilities. The capability registration / deregistration element 1416 may enable registration / deregistration of capabilities with the invitation service 1400. The interface specification parameter may include a reference to one or more capability object 412 (FIG. 4) instances, and an indication as to whether the capability or capabilities relate to a particular user of the endpoint or to all users of the endpoint. . Each capability object 412 instance may be associated with a capability identifier, eg, a global single identifier (GUID). In an embodiment of the present invention, each capability may be associated with a particular cooperative application 1318, 1320 (FIG. 13). The invitation service 1400 can include separate application programming interface elements for registering capabilities and deregistering capabilities.

The capability enumeration element 1418 may enable enumeration of capabilities registered with the invitation service 1400. The interface specification parameter may include an indication as to whether the enumeration should include capabilities associated with a particular user of the endpoint or capabilities associated with all users of the endpoint. In an embodiment of the invention, the enumeration includes, for example, a capability identifier instead of a reference to the capability object 412 (FIG. 4) instance. The capability object 412 instance may then be retrieved into the capability information obtaining element 1420.

An exemplary collaboration invitation method is now described in more detail. The basic situation for a collaborative invitation is whether the user interacts with a particular application to send and / or respond to an invitation (specific scenario), or the application-independent mechanism to send and / or respond to the invitation. Whether or not to interact (common scenario). Four scenarios: from general to general, from specific to general, from general to specific, and from specific to specific, are described below with respect to FIGS. 15-18.

15 illustrates exemplary steps for sending an invitation in accordance with an embodiment of the present invention. In step 1502, a generic invitation user interface (UI) may be invoked. For example, the cooperative service platform 302 (FIG. 3) can invoke the user interface of the invitation service 326. At step 1504, one or more contacts may be selected with a generic invite user interface. For example, the user interface of the invitation service 326 can interact with the contact management service 304 to display a list of known contacts of the user, or a list of buddy class contacts, for example, and the user can display those displayed. The contact set can be selected graphically from.

At step 1506, the activity may be selected with a generic invite user interface. For example, the user interface of the invitation service 326 (FIG. 3) may interact with the activity service 310 to display a list of available collaborative activities, or a list of popular or most recently used activities, for example. The user can then graphically select the collaborative activity from those displayed. In step 1508, it may be determined whether the generic invitation user interface will send the invitation, or whether the invitation will be sent from a particular collaboration application, for example. For example, the decision may depend on the configurable parameters of the invitation service 326. If the generic invitation user interface is determined to send the invitation, the procedure may proceed to step 1510. Otherwise, the procedure may proceed to step 1512.

At step 1510, a cooperative application associated with the activity selected at step 1506 may be launched. Step 1510 is indicated by dashed lines to indicate that although the application may be launched at this time, the generic inviting user interface retains control of the execution thread and may proceed to step 1514. This is in contrast to step 1516.

In step 1512, the details of the invitations collected so far, such as the contact selected in step 1504, and any configuration parameters related to the activity selected in step 1506 are stored for retrieval by the collaborative application associated with the activity. Can be. At step 1516, the cooperative application is initiated and control of the procedure is transferred by the generic invite user interface.

In step 1514, the invitation may be sent to the invitation service 1400 (FIG. 14) application programming interface, for example to the invitation secure transmission element 1406 or invitation non-secure transmission element 1408 described above. Although the same application programming interface elements 1406 and 1408 can be used to send the invitation, when the procedure proceeds from step 1510 to step 1514, the elements 1406 and 1408 are replaced by a generic invitation user interface. While being called, when the procedure proceeds from step 1516 to step 1514, elements 1406 and 1408 are called by the cooperating application. As a result, the interface specification parameters sent to elements 1406 and 1408 may be different.

The procedure beginning at step 1502 describes one of the scenarios "from general" because a generic invitation user interface is used. In contrast, step 1518 begins a scenario "from a specific". At step 1518, the cooperative application can be launched. For example, application 1318 (FIG. 13) can be initiated in a conventional manner by computer operating system 1306. Step 1518 is a prerequisite for step 1520, and in fact some time may elapse between steps 1518 and 1520.

At step 1520, one or more contacts may be selected as the user interface of the cooperative application 1318 (FIG. 13). For example, the cooperative application 1318 may interact with the contact management service 304 (FIG. 3) of the cooperative service platform 1310 to display a list of known contacts of the application user, or for example, a list of buddy class contacts. The application user can graphically select a set of contacts from those displayed. In contrast to proceeding from step 1504, the selection of cooperative activity is not necessary and the procedure may proceed to step 1514. The cooperative application 1318 may have determined cooperative activity. However, in an embodiment of the invention, the cooperative application 1318 may support a number of activities, in which case a step equivalent to step 1506 may be appropriate. In step 1514, the invitation sending element 1406 or 1408 (FIG. 14) may be called by the cooperative application 1318.

FIG. 16 illustrates exemplary steps performed by invitation service 1400 (FIG. 14) to send an invitation, in accordance with an embodiment of the invention. In step 1602, the next candidate contact is selected. For example, the candidate contact may be selected from the set selected in step 1504 or 1520 of FIG. 15.

At step 1604, it may be determined whether the endpoint of the candidate contact is known. For example, the presence object 404 (FIG. 4) referenced by the contact object 402 representing the candidate contact may be queried to find its endpoint object 410 set. If no endpoint of the candidate contact is known (eg, if the query result is an empty set), the procedure may proceed to step 1606. If the endpoint of the candidate contact is known, the procedure may proceed to step 1608. In step 1606, the location of the endpoint relative to the candidate contact may be known. For example, invitation service 326 (FIG. 3) may interact with contact location service 322 to determine a set of valid endpoints for the candidate contact.

In step 1608, the candidate endpoint may be selected from known endpoints for the candidate contact. At step 1610, the communication connection may be established with the candidate endpoint. For example, the connection may be set up with connection service 316 (FIG. 3). At step 1612, the invitation may be sent to the candidate endpoint, for example in an invitation message 1322 (FIG. 13).

In step 1614, it may be determined whether there are more candidate endpoints. If there are more candidate endpoints, the procedure may return to step 1608 to select the next candidate endpoint. Otherwise, the procedure may proceed to step 1616. At step 1616, it may be determined whether there are more candidate contacts. If there are more candidate contacts, the procedure may return to step 1602 and select the next candidate contact. Otherwise, the invitation can be considered sent.

The "from general" and "from specific" portions of the four scenarios have been described, and the "normally" and "specifically" portions are now described with reference to FIGS. 17 and 18, respectively. 17 illustrates example steps for responding to a collaboration invitation from a generic invitation user interface, in accordance with an embodiment of the invention. If a collaboration invitation has been sent to multiple endpoints, the steps shown in FIGS. 17 and / or 18 can be performed at each endpoint.

At step 1702, the collaboration invitation may be received at a standard communication port of the collaboration service platform 302 (FIG. 3). For example, invitation message 1322 (FIG. 13) may arrive at a TCP / IP port prepared for cooperative service platform 302 and monitored by invitation service 326.

In step 1704, it may be determined whether the endpoint can participate in the activity associated with the invitation. For example, the invitation service 326 (FIG. 3) can compare the capability identifier (s) in the invitation message 1322 (FIG. 13) with the capabilities registered with the invitation service 328. Alternatively, the MeContact object 406 (FIG. 4) associated with the user of the endpoint may be queried to find its associated set of capability objects 412, which may be associated with the capability identifier (s) in the invitation message 132. Can be compared. If the endpoint is determined to be able to participate in the activity associated with the invitation, the procedure may proceed to step 1706. Otherwise, the procedure may proceed to step 1708.

In step 1706, the user can accept, refuse or ignore the invitation. For example, invitation service 326 (FIG. 3) may display a generic invitation user interface with user interface elements corresponding to the decision: accept, refuse or ignore. The user can accept, refuse or ignore the invitation by selecting the corresponding user interface element. If the user accepts the invitation, the procedure may proceed to step 1710. If the user refuses to invite, the procedure may proceed to step 1708. If the user ignores the invitation, the procedure may proceed to step 1712.

At step 1708, response message 1324 (FIG. 13) may be sent to indicate that the invitation is refused. For example, response message 1324 may be sent in response to invitation element 1412 (FIG. 14) of invitation service 1400 application programming interface. Likewise, at step 1712, response message 1324 may be sent to indicate that the user is selecting to ignore the invitation. Invitation element 1412 may also be used to send this response. In an embodiment of the present invention, the ability to send an explicit ignore response increases the efficiency of the cooperative service platform 302 (FIG. 3).

At step 1710, the details of the accepted invitation may be stored for retrieval by the collaboration application 1320 (FIG. 13) associated with the collaboration activity. For example, some or all of the content of invitation message 1322 may be stored by invitation service 326 along with invitation element 1402 (FIG. 14) of the application programming interface. At step 1714, cooperative application 1320 may be initiated by invitation service 326.

In step 1716, a response message 1324 (FIG. 13) indicating acceptance of the invitation may be sent using a response to the invitation element 1412 (FIG. 14) of the invitation service 1400 application programming interface, for example. Can be. When proceeding from step 1716 to step 1718, control of execution may pass to the cooperative application 1320 initiated at step 1714. Alternatively, cooperative application 1320 may be initiated in a parallel execution thread that is a thread synchronized as needed, and the invitation service thread that receives the invitation in step 1702 may terminate after responding in step 1716. .

At step 1718, the cooperative application 1320 (FIG. 13) can read the invitation details stored at step 1710. For example, the saved invite details can result in some (re) configuration of the cooperative application 1320. At this point, the cooperative application 1320 may be ready to begin participating in the cooperative activity, and at step 1720, participation in the cooperative activity may begin.

18 illustrates example steps for responding to a collaboration invitation from a particular application user interface, in accordance with an embodiment of the invention. At step 1802, a cooperative application may be launched. For example, collaborative application 1320 (FIG. 13) can be initiated in a conventional manner by computer operating system 1304. In step 1804, the cooperative application 1320 may create an invite listener on a nonstandard, application specific cooperative communication port. For example, the cooperative application 1320 is an invitation listener generation element of the invitation service 1400 application programming interface to generate an invite listener on a TCP / IP port that is different from the port prepared for the cooperative service platform 302 (FIG. 3). 1404 (FIG. 14) can be used.

Sometime later, at step 1806, the collaboration invitation may be received at a non-standard port. For example, the invitation message 1322 (FIG. 13) sent in step 1514 (FIG. 15) may have been sent to an application specific port and / or endpoint. At step 1808, the cooperative application 1320 user can accept, refuse, or explicitly ignore the invitation. For example, the collaborative application 1320 may display a user interface having user interface elements corresponding to the decision: accept, refuse, and ignore. The user can then select the desired response by selecting the corresponding user interface element. If the user accepts the invitation, the procedure may proceed to step 1810. If the user refuses the invitation, the procedure may proceed to step 1812. If the user explicitly ignores the invitation, the procedure may proceed to step 1814.

At each step 1810, 1812 and 1814, an appropriate invitation response can be sent to the invitee. Each step 1810, 1812, and 1814, for example, invite element 1412 of invitation service 1400 (FIG. 13) to send response message 1324 (FIG. 13) as an invitation response action set to accept, refuse, or ignore, respectively. Response to FIG. 14 may be used. Since the desired collaboration application 1320 (FIG. 13) has already been initiated, once the invitation has been accepted, the collaboration activity can begin without further delay at step 1816.

An example method for issuing a cooperative presence is now described in more detail. In particular, the ability to issue serverless presence, i.e., issue cooperative presence information regardless of the need of a dedicated server computer, is advantageous in embodiments of the present invention. For example, serverless networked computing environments, peer-to-peer networks, or overlay networks may provide better scalability than networks and network applications that require dedicated server computers. Networked computing environment 200 (FIG. 2) may support a peer to peer or overlay network. Each of the computers 204, 206, 208, 212, 214, and 216 may support one or more peers of a peer to peer network. Each peer may be a cooperative endpoint and may be associated with an endpoint object 410 (FIG. 4) instance.

As discussed above, the cooperative presence may be represented by the presence object 404 (FIG. 4). Any suitable portion (including all) of the presence object 404 may be issued to a user of the cooperative service platform 302 (FIG. 3). In addition, a program object instance referenced by the presence object 404 instance may be issued, including the endpoint object 410, the capability object 412, and the more general published object 418.

However, in an embodiment of the present invention, one issue is typically not sufficient. Presence information can change. For example, the published object 418 can be updated by a collaborative application, and the aggregate state, and / or presence state associated with a particular endpoint, can change throughout the day, and the endpoint can be, for example, of a wireless network coverage area. With a networked wireless device moving in and out or turning on and off, it may be added to or removed from the presence of a particular contact, and endpoint capabilities may change when new collaborative applications are installed. Effective collaboration can require consistently updated presence information. In an embodiment of the invention, the cooperative presence information is a presence subscription and presence notification message that is distributed in a serverless networked computing environment, such as networked computing environment 200 (FIG. 2).

19 illustrates example steps for participating in serverless presence publishing, in accordance with an embodiment of the invention. In step 1902, a computer user may authenticate with an operating system (OS) of the computer. For example, a user may log in to one of the computers 204, 206, 208, 212, 214 or 216 (FIG. 2) of the networked computing environment 200. Suitable computer operating systems include computer operating systems capable of supporting a cooperative service platform 302 (FIG. 3), such as any suitable version of “MICROSOFT WINDOWS” or “UNIX” computer operating system. Authentication to the computer operating system may establish a computer-aware identification number for the computer user, and in particular may associate the computer user with an instance of MeContact object 406 (FIG. 4).

In step 1904, communication with the publishing service 306 (FIG. 3) of the cooperative service platform 302 may begin. As mentioned above, the publishing service 306 may be serverless. For example, at step 1904, a computer user can join a peer-to-peer (P2P) network that includes a publishing service 306. In step 1906, some or all of the data contained in and / or referenced by the MeContact object 406 (FIG. 4) associated with the computer user is, for example, one or more presence notification messages, for example, a publishing service ( 306 to establish a cooperative presence of the computer and the cooperative service platform 302 user.

At step 1908, communication with contact storage 318 (FIG. 3) may begin. For example, contact storage may be a conventional data store, such as a database, and initiation of communication with contact store 318 may include establishing a communication session with the data store. In step 1910, contact storage 318 may be queried to find the buddy class contact of the user. In an embodiment of the invention, the lookup of the contact store 318 is inverse of one or more references to the contact object 402 (FIG. 4) contained in the buddy element 904 (FIG. 9) of the MeContact object 406. Includes de-referencing.

In step 1912, a subscription may be applied for the presence of a buddy class contact, for example, a presence subscription message described in more detail with respect to FIGS. 20 and 21. At step 1914, in response to the subscription, a presence renewal notification may be received. For example, a presence notification message can be sent over a peer to peer network when a change in presence with an associated subscription occurs.

20 illustrates exemplary steps for subscribing to a presence subscription according to an embodiment of the present invention. For example, the step illustrated by FIG. 20 may be performed as part of step 1912 (FIG. 19). The set of buddy class contacts to whom a subscription is to be applied may be available, for example, from step 1914. In step 2002, the next candidate buddy class contactor may be selected from the set.

In step 2004, a search may be made to find a buddy class contact. For example, Peer Name Resolution Protocol (PNRP) may be used to locate an endpoint associated with a buddy class contactor in a peer to peer network. Alternatively, or else, the search may be made across a local network partition, such as subnet 218 (FIG. 2) to find a contact. Any suitable network partition can be set up for a contact and / or searched to find that contact.

The search may not be successful. For example, the buddy class contactor may not have an associated endpoint in the peer to peer network and / or local network partition. In step 2006, it may be determined whether a buddy class contactor is found. For example, the peer name resolution protocol may successfully resolve the name of the buddy class contactor for the associated cooperative endpoint in the peer-to-peer network, or the response may be an associated endpoint for the buddy class contactor (eg, TCP / IP). Address and communication port number) may be received for message broadcasts across a local network partition. If the buddy class contactor is found, the procedure may proceed to step 2008. Otherwise, for example, because the contact has been classified as a buddy, the member may be assumed to be temporary and the procedure may proceed to step 2010.

Once classified as a buddy, it may imply the assumption that the contact is typically an active collaborative participant, and in an embodiment of the present invention, periodic searches to find missing buddy class contacts, despite the increased demand for computational and network resources. And the efficiency of the cooperative service platform 302 (FIG. 3) is sufficiently enhanced to be a justifying feature. The procedure may wait at step 2010 between searches. For example, the period between searches may be 10 minutes. Step 2010 is surrounded by dashed line 2012 to indicate that waiting and possibly subsequent steps may occur in separate execution threads. After instantiating a separate execution thread for the wait phase 2010, the main execution thread may proceed to step 2014.

Once the buddy class contact has been found, at step 2008, the presence subscription message may be sent to an endpoint associated with the contact, for example, the endpoint found at step 2004. The presence subscription message may specify a subscription to some or all of the cooperative presence information associated with the contact. For example, the presence subscription message may include a rich text description element 602 (FIG. 6), an endpoint element 604, an aggregate state element 606, an aggregate capability element 608, and a publication in the presence object 600 application programming interface. Subscriptions to presence information accessible through one or more of the assigned object elements 610 may be specified. For example, a presence notification message sent in response to a subscription in step 1914 (FIG. 19) may only need to be sent when a portion of the presence change that is covered by the subscription and that may be needed includes a portion of the changed presence information. have.

In step 2014, it may be determined whether there are more buddy class contacts in the set of buddy class contacts. If there are more such contacts, the procedure may return to step 2002 to select the next contact from the set. Otherwise, the procedure may proceed to other steps, such as step 1914 (FIG. 19) and / or step 2102 of FIG. 21.

21 illustrates exemplary steps for accepting a presence subscription in accordance with an embodiment of the present invention. In step 2102, a presence subscription message may be received. For example, this may be a presence subscription message sent in step 2008 (FIG. 20). In step 2104, contact information associated with the sender of the presence subscription may be retrieved. For example, the presence subscription message may reference the contact object 402 (FIG. 4) associated with the sender. The recipient of the presence subscription message may retrieve the sender's contact information with contact management service 304 (FIG. 3).

At step 2106, it may be determined whether a subscription policy has been set for the sender of the presence subscription message. For example, contact information associated with a sender managed by contact management service 304 (FIG. 3) may include a relationship between the sender and a subscription policy for the sender. Alternatively, the subscription policy may be in place for all subscribers, or for any group of subscribers the sender is a member of.

Examples of simple subscription policies include blocking and allowing. That is, it blocks a subscription request from a contact, or allows a subscription request from a contact. In an embodiment of the present invention, a subscription policy for a sender is applied to the set of contactor object 402 (FIG. 4) instances referenced by the authorized subscriber element 906 (FIG. 9) of the MeContact object 406 associated with the receiver. Is determined by. If the contactor object 402 instance associated with the sender is in the set referenced by the authorized subscriber element 906, the sender is allowed, otherwise the sender is blocked.

In embodiments of the present invention, more sophisticated subscription policies are possible. For example, more sophisticated subscription policies may block and / or allow subscriptions to one or more subsets of the subscriber's presence information. Allowing subscriptions to the aggregate state 606 (FIG. 6) and rich text description 602 of the presence object 600 and blocking the subscription of other presence object elements 604, 608, 610 is one possible example. (Including all) of the presence object elements 602, 604, 606, 608, and 610 and / or the program objects 410, 412, 418 referenced by these presence object elements 602, 604, 606, 608, and 610. Any suitable subset may be the subject of the subscription policy and / or subscription.

If the subscription policy is in place for the sender of the subscription message, the procedure may proceed to step 2108. Otherwise, the procedure may proceed to step 2110. In step 2110, a user of the cooperative service platform 302 (FIG. 3) associated with the cooperative presence that is the subject of the subscription may be queried to find a subscription policy regarding the sender of the presence subscription message. For example, publishing service 306 may represent a user interface (eg, graphical user interface or GUI) that displays contact information associated with the sender, and subscription policy options such as blocking and allowing. The user can then select a subscription policy for the sender with the user interface.

In step 2112, the subscription policy selected by the user may be set for the sender. For example, a subscription policy may be associated with a sender through contact management service 304 (FIG. 3) of the cooperative service platform 302, or a reference to a contact object instance 402 (FIG. 4) instance associated with the sender. May be added to the reference set maintained by the authorized subscriber element 906 (FIG. 9) of the MeContact object 406 instance associated with the receiver. In step 2108, if a subscription policy for the sender has been set, it may be determined whether the subscription policy blocks the subscription. If the subscription policy is to block the subscription from the sender, the procedure may proceed to step 2114. Otherwise, the procedure may proceed to step 2116.

At step 2116, the cooperative presence subscription may be accepted. For example, the subscription specified by the presence subscription message may be associated with the MeContact object 406 associated with the recipient via contact management service 304 (FIG. 3). In an embodiment of the present invention, the subscription specified by the presence subscription message may include a contactor object 402 (FIG. 4) instance associated with the sender and an active subscriber element 908 (FIG. 9) instance of the MeContact object 406 instance associated with the receiver. Is added by adding to the set of contact object 402 instances referenced by. If the subscription is more sophisticated than allow and block, the subscription specified by the presence subscription message may be filtered about the subscription policy associated with the sender before it is accepted. For example, if a subscription is for all presence information, but the subscription policy restricts the subscription to aggregate status, the accepted subscription will only be for aggregate status. Together, steps 2108 and 2116 can ensure that the subscription is accepted according to the subscription policy.

In step 2114, it may be determined whether the sender of the presence subscription message is the recipient's buddy class contact. For example, the set of contactor object 402 (FIG. 4) instances referenced by the buddy element 904 (FIG. 9) of the MeContact object 900 associated with the receiver is the contactor object 402 associated with the sender of the presence subscription message. ) Can be examined to identify the instance. Publishing service 306 (FIG. 3) may contact contact management service 304 to determine whether the sender of the presence subscription message is the recipient's buddy class contact. If the sender of the presence subscription message is the recipient's buddy class contact, the procedure may proceed to step 2118. Otherwise, the procedure may proceed to step 2120.

If it is determined that the sender of the presence subscription message is the recipient's buddy class contactor, then at step 2118, it may be determined whether the recipient of the presence subscription message is subscribed to the presence of the current sender. For example, the publishing service 306 (FIG. 3) application programming interface may have an enumeration subscription element that enables enumeration of subscription sets subscribed by a designated contact, and the subscription set may subscribe to subscriptions subscribed to the sender's presence. Can be investigated to confirm. Alternatively, or else, contact information referenced by buddy element 904 (FIG. 9) of the MeContact object 406 (FIG. 4) instance associated with the receiver may be obtained for each buddy class contact, the presence subscription being the contactor. It may include an indication as to whether it has been accepted by.

If the recipient of the presence subscription message is determined to subscribe to the presence of the current sender, the procedure may proceed to step 2120. Otherwise, the receiver can subscribe to the sender's presence at step 2122. For example, the recipient of the presence subscription message has previously performed the step of finding the sender, described above with respect to FIG. 20, but the sender was not online and is waiting at step 2010 before the recipient retrieves again. It may be. The sender is now online, sending the presence subscription message. Rather than waiting and looking again for the sender to consume computational and network resources, in an embodiment of the present invention, the receiver may respond to a presence subscription message from a buddy class contact with a mutual presence subscription message. In step 2122, the mutual presence subscription message may be sent to the buddy class contact as described above in step 2008 (FIG. 20).

At step 2120, one or more presence notification messages may be sent to the sender of the presence subscription message according to the presence subscriptions accepted at step 2116. The initial presence notification message may include all presence information that matches the accepted subscription, or may include, for example, a set of presence differences other than the presence information known to be already owned by the recipient. After the initial presence notification message, an additional presence notification message can be sent to notify the subscriber of the cooperative presence update. For example, after one or more updates to the cooperative presence of a particular cooperative service platform 302 (FIG. 3) user, one or more presence notification messages may be sent to the publishing service 306 (FIG. 3). For each subscription to the user's presence, the publishing service 306 may determine whether one or more subsets of the presence information referenced by the presence notification message match the subscription. For each matching subscription, the publishing service 306 may deliver a presence notification message to the cooperative service platform 302 user who subscribed to the subscription.

All references, including publications, patent applications, and patents cited herein, are each incorporated by reference in their entirety and are hereby incorporated by reference to the same extent as described herein in its entirety.

The use of the terms "a", "an", "the", and the like in the context of the present invention (particularly in the context of the following claims) is not expressly disclaimed or otherwise indicated herein unless otherwise indicated. Unless, it is to be construed to include both singular and plural. The terms "comprising", "having", "including" and "containing" may be interpreted in an unlimited term (ie, meaning "including, but not limited to") unless stated otherwise. The enumeration of ranges of values herein is intended to be written in a shorthand way of individually representing each discrete value within a range, unless otherwise indicated herein, with each discrete value specified as individually listed herein. Included in All methods described herein may be performed in any suitable order unless otherwise indicated herein or otherwise expressly disclaimed in the context. The use of any and all examples, or exemplary language (eg, "such as") provided herein, is merely intended to clarify the invention more, and does not limit the scope of the invention unless otherwise claimed. It is not. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

Preferred embodiments of the invention are described herein, including the best mode known to the inventors of the invention. Modifications of those preferred embodiments will become apparent to those skilled in the art upon reading the above description. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for the invention to be practiced otherwise than as specifically described herein. Accordingly, the present invention includes all modifications and equivalents of the subject matter described in the claims appended hereto as permitted by applicable law. In addition, any combination of the foregoing elements within all possible variations of the invention is included in the invention unless otherwise indicated herein or otherwise clearly disclaimed in the context.

Claims (20)

A computer-readable storage medium containing computer-executable instructions for a collaborative invitation, the computer-executable instructions comprising: Selecting at least one contact with the invite user interface; Determining whether an invitation to be sent to the at least one contact should be initiated from the invitation user interface or directly from a collaborative application, wherein the collaborative application is distinct from the invitation user interface and initiated from an operating system. launched and associated with at least one of a capability or collaborative activity associated with an endpoint; If it is determined that the invitation to be sent should originate from the invitation user interface, then at least Instructions to launch the cooperative application; And Initiating sending the invitation to the at least one contact from the invitation user interface; And If it is determined that the invitation to be sent should be started directly from the collaboration application, then at least Instructions to launch the cooperative application; And And initiating sending the invitation to the at least one contact directly from the collaborative application. The method of claim 1, And the invite user interface is a graphical user interface of an invite service. The method of claim 1, The computer-executable instructions further comprise instructions for selecting a cooperative activity via the invitation user interface, Instructions for initiating the cooperative application include instructions for initiating a cooperative application associated with the selected cooperative activity. The method of claim 1, And instructions for storing invitation details for retrieval by the collaborative application. The method of claim 1, And the command to initiate sending the invitation comprises instructions to initiate sending the invitation by an invitation sending element of an application programming interface of the invitation service. The method of claim 5, The application programming interface of the invitation service, The invitation sending element; An invitation response element responsive to the received invitation; And Delete invitation element to delete sent invitations Computer-readable storage medium comprising. The method of claim 1, The command to start sending the invitation, for each of the at least one contact, Instructions for determining a set of a plurality of endpoints for the contact; And For each endpoint in the set of endpoints, at least Establishing a communication connection to each of the endpoints; And Send an invitation to the respective endpoint via the communication connection Computer-readable storage medium comprising. The method of claim 7, wherein Each contact's representation includes a contact program object instance referencing a set of endpoint program object instances, The command to determine a set of a plurality of endpoints for the contact, Instructions for querying the contactor program entity instance corresponding to the contactor to find the set of endpoint program entity instances; And If the set of endpoint program entity instances is empty, determining a set of a plurality of endpoints for the contact with a contact location service Computer-readable storage medium comprising. A computer-readable storage medium containing computer-executable instructions for a collaboration invitation, the computer-executable instructions comprising: Instructions for receiving an invitation to participate in a cooperative activity directly at a cooperative service platform and directly in a cooperative application, wherein the cooperative application is distinct from the cooperative service platform, initiated from an operating system, and associated with the cooperative activity, Presenting the invitation to at least one of the cooperative service platform or the cooperative application, with the ability to select one of accept, decline and ignore in response to the invitation; Instructions for receiving a selection of the user; And Instructions for sending a response to the sender of the invitation, the response including an indication of the user's selection. 10. The method of claim 9, The invitation is received at an endpoint of the cooperative service platform, And the computer-executable instructions further comprise instructions to determine if the endpoint can participate in the collaborative activity. The method of claim 10, The invitation includes a specification of a set of capabilities required to participate in the collaborative activity, The cooperative service platform includes a registry of capabilities of the endpoint, And instructions for determining if the endpoint can participate in the collaborative activity include instructions for comparing a set of capabilities specified by the invitation with registered capabilities of the endpoint. 10. The method of claim 9, The invitation is received at one of a standard communication port for the cooperative service platform and a non-standard communication port specific to the cooperative application, If the invitation is received at the standard communication port and the user chooses to accept the invitation, the computer-executable instructions are Instructions for storing some or all of the information included in the invitation for retrieval by the collaborative application; Instructions to launch the cooperative application; And Further comprising instructions for starting the cooperative activity, And if the invitation is received at the non-standard communication port and the user chooses to accept the invitation, the computer-executable instructions further comprise instructions to initiate the collaborative activity. The method of claim 12, Instructions to launch the cooperative application; And And instructions for creating an invite listener on a nonstandard communication port for the collaborative application. 10. The method of claim 9, Instructions for sending the response to the sender of the invitation include instructions for sending the response by an invitation response element of an application programming interface of the invitation service. A computer-readable storage medium containing computer-executable instructions for implementing an application programming interface for a collaborative invitation service, the computer-executable instructions comprising: operating system; A cooperative service platform included in the operating system; The cooperation invitation service included in the cooperation service platform; An invitation service application programming interface for providing access to the collaboration invitation service, the invitation service application programming interface comprising: an invitation element for providing access to invitation data corresponding to a first invitation to participate in a collaboration activity; An invitation sending element for sending the first invitation to at least one contact of a user of a collaborative service platform; An invitation response element responsive to the received invitation; And an invitation deletion element for deleting the sent invitation; And At least one cooperative application-the at least one cooperative application is distinct from the cooperative service platform, initiated from the operating system, associated with at least one of a capability or cooperative activity associated with an endpoint, and directly sending and receiving invites Configured to use the service application programming interface- Computer-readable storage medium comprising computer-executable instructions for a. The method of claim 15, The invitation data, Invitation identifier; And At least one capability identifier Computer-readable storage medium comprising. The method of claim 15, The invitation sending element comprises an invitation secure transmission element for secure transmission of the first invitation, And the invitation service application programming interface further comprises an invitation insecure transmission element for unsecured transmission of the first invitation. The method of claim 15, The invitation sending element comprises an invitation asynchronous transmission element for sending the first invitation asynchronously, And the invitation service application programming interface further comprises an invitation synchronous transmission element for sending the first invitation synchronously. The method of claim 15, And the invitation service application programming interface further comprises an invitation listener generation element for instantiating an invitation listener at the cooperative endpoint. The method of claim 15, The invitation service application programming interface, A capability registration element for registering cooperation capabilities with the cooperation invitation service; A capability deregistration element for deregistering cooperation capabilities with the cooperation invitation service; And And a capability enumeration element for enumerating capabilities registered with the cooperative invitation service.

Images