Microsoft Technology Licensing, LLC

Pritam De

Todd R Manion

Jeremy Lee Dewey

Scott A Senkeresty

Brian R Lieuallen

Kevin C Ransom

Sandeep Singhal

Upshur Parks

Pallavi Choudhury

Travis C Luke

Charles Alan Ludwig

Joaquin Guanter Gonzalbez

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

Secure marshaling of data via one or more intermediate processes is provided. A source process may create a named shared memory section resulting in a first handle to the shared memory section. The source process may populate the shared memory section with information. An access control list may secure the shared memory section by preventing the one or more intermediate processes from accessing content of the shared memory section, while allowing a target process to access the content. The first handle and a name of the shared memory section may be marshaled to a first intermediate process resulting in a respective new handle to the shared memory section. A last intermediate process may marshal the name to a target process, which may use the name to obtain access to the content of the shared memory section.

Efficient secure data marshaling through at least one untrusted intermediate process

Growing community of inventors

Redmond, WA, United States of America

Pritam De