Microsoft Technology Licensing, LLC

Scott A Senkeresty

Todd R Manion

Jeremy Lee Dewey

Brian R Lieuallen

Kevin C Ransom

Pritam De

Ravi Rao

Sandeep Singhal

Upshur Parks

David G Thaler

Cesare John Saretto

Robert D Donner

John S Holmes

Noah Horton

Pallavi Choudhury

Upshur Warren Parks, Iii

Travis C Luke

John L Miller

Rohit Gupta

John R Selbie

Gianluigi Nusca

Eliot John Flannery

Carmen Zlateff

Michael Shappell

Robert D Donnor

Sandeep Kishan Singhal

Kevin Charles Ransom

A Distributed Routing Table (DRT) mesh can comprise two or more nodes, each of which maintains its own routing table that represents some or all of the overall routing knowledge of the DRT mesh. Each node can be comprised of modular components that can perform various defined functions such that the features and abilities of the node can be customized by an application based on which modular components are instantiated. A routing table management module can maintain individual routing tables at each node, and can ensure that only entries that are close to the node, in a network topology sense, are maintained in the routing table. In addition, a security module can verify received messages based on an agreed-upon root certificate.

Distributed routing table architecture and design

Application programming interface (API) for starting and accessing distributed routing table (DRT) functionality. The API facilitates bootstrapping into the DRT by one or more devices of a group of devices (a mesh) seeking to collaborate over a serverless connection, establishing a node of the DRT, where each node is an instance of an application that is participating in the mesh, and node participation by allowing the application to search for keys published by other nodes in the mesh, or by becoming part of the mesh by publishing a key. The API facilitates optimization of the routing table for quickly finding a root of a specific key in the mesh by finding the key directly in a cache or by asking a root node of the key that is in the local routing table that is closest numerically to the key being searched.

Distributed routing table interface

An application program interface (API) for sending and receiving endpoint registration data and peer-to-peer network cloud data has a registration call for adding endpoint data to a peer-to-peer network. The API may receive explicit data regarding address information or may be instructed to select and maintain suitable address information as the topology of the peer-to-peer network changes. Blocking and non-blocking calls are exposed for retrieving information peer-to-peer network endpoint data.

Peer name resolution protocol simple application program interface

The claimed method and system provides a method and interface for enabling an existing, single-transport P2P API to communicate with nodes of a P2P network using multiple different transport protocols.

Transport abstraction for multiparty replication

A system, apparatus, method, and computer-readable medium are provided for resolving a name to a network endpoint. According to one method, naming providers are registered with a computer system that are operative to resolve names to network endpoints for one or more domains. A provider can claim to be a primary provider or a secondary provider for a domain. A provider can also register as a wildcard provider. Once the providers have been registered, requests may be received to resolve an e-mail address into a network address of the corresponding computer system. In response to such a request, one or more of the registered providers are identified as being able to resolve names in the domain to network addresses. Requests are transmitted to the identified providers requesting that they resolve the e-mail address to a corresponding network address. The manner in which the requests are made depends upon whether authoritative results are required. Once the results of the name resolution have been returned, the results are utilized to establish a network connection to and communicate with the computer system identified by the returned network address.

Resolving names to network endpoints

Application programming interfaces and methods that provide group management in a peer-to-peer (P2P) network are provided. More specifically, new and improved P2P application programming interfaces (APIs) and methods for the creation and access of groups, the retrieval of member and group information, the addition, modification, deletion and management of records (data), the importation and exportation of group data, the direct communication between members, the addition of a security provider to a group, the setting and retrieval of presence information, the registering for event notifications, and other utility and support functions are presented. Each of these interfaces utilize various parameters that are passed in from an application program that uses these interfaces to manage and utilize groups. The interfaces return a value that indicates the success or failure of the function. For failures, the interfaces provide an indication as to the problem resulting in the failure.

Peer-to-peer grouping interfaces and methods

A computer implemented method and system enable users to share files in a server-less shared space. By providing access to such spaces via a visual presentation, the system renders content available for access by other group members. Access is sometimes provided through propagation of metadata or other uniquely identifying indicia associated with the shared space to all group members.

File sharing in P2P group shared spaces

Communication functionality is described for conducting communication among a plurality of participants in peer-to-peer fashion. The communication functionality comprises peer-to-peer overlay functionality configured to establish a peer-to-peer overlay network that includes a plurality of participants. The peer-to-peer overlay functionality relies on endpoint provider functionality for physically exchanging information among the plurality of participants in the peer-to-peer overlay network. The endpoint provider functionality exchanges information using a transport mechanism. The transport mechanism accommodates multiple different transport protocols for exchanging information among the plurality of participants, allowing different pairs of participants to communicate with each other using different respective transport protocols. Address translation functionality is employed for translating address information between a first address space used by the peer-to-peer overlay functionality and a second address space used by the endpoint provider functionality.

Peer-to-peer multicasting using multiple transport protocols

Application programming interfaces and methods that provide graph management in a peer-to-peer (P2P) network are provided. More specifically, new and improved P2P application programming interfaces (APIs) and methods for the creation and access of graphs, the retrieval of node and graph information, the addition, modification, deletion and management of records (data), the importation and exportation of graph data, the direct communication between graph nodes, the addition of a security provider to a graph, the setting and retrieval of presence information, the registering for event notifications, and other utility and support functions are presented. Each of these interfaces utilize various parameters that are passed in from an application program that uses these interfaces to manage and utilize graphs. The interfaces return a value that indicates the success or failure of the function. For failures, the interfaces provide an indication as to the problem resulting in the failure.

Peer-to peer graphing interfaces and methods

A simple record query language (SRQL) is a generic record meta-data query solution that can natively describe the information contained in a record and search each against it to find records whose meta-data matches a particular set of criteria. SRQL includes both a record data structure that includes searchable SRQL attributes that describe the record, and queries that are able to search the attributes. The attributes are an XML node that exists in the record header itself. There are two types of queries, to wit local to find records in the local data store, and distributed to find records that may be stored in a neighbor's data store. As such, SRQL finds particular applicability to peer-to-peer networks.

Growing community of inventors

Duvall, WA, United States of America

Scott A Senkeresty