Microsoft Technology Licensing, LLC

Jeremy Lee Dewey

Todd R Manion

Scott A Senkeresty

Brian R Lieuallen

Kevin C Ransom

Donald F Box

Ravi Rao

Shiraz Jitendra Cupala

Zhangwei Xu

Curt Andrew Steeb

Min Liu

Anthony Vincent Discolo

Martin James Gudgin

Pritam De

Kean Ee Lim

Edmund Hon-Sum Lui

Ryan B Elgram

Grant Gardner

Sandeep Singhal

Ashish Gupta

Martin D Hall

Upshur Parks

Padmini Chandrasekhar Iyer

David Ruzyski

Jason Kepner

Evelyn R Thomas

Joshua R McCammon

Stephen E Giscombe

Robert D Donner

Rohit Gupta

Noah Horton

Dana Ludwig

Pallavi Choudhury

Upshur Warren Parks, Iii

Thomas Cooper

Travis C Luke

Noel Wayne Anderson

Christian F Huitema

Alastair Wolman

John David Dunagan

David G Thaler

Igor A Kostic

Ryan Yonghee Kim

Bruce Wayne Copeland

Eliot John Flannery

Tyler M Barton

Kedar Hirve

Xiaohai Zhang

Luca Beltrami

Heather Grantham Brodie

Kanaka Komandur

John Carleton McCullough

Ramakrishna P Pamulapati

Upshur W Parks

Travis St Onge

Aaron Cardwell

Matthew Labunka

Sandeep Kishan Singhal

Kevin Charles Ransom

Examples described herein provide various devices that enable users to participate in a multiplayer session. The examples allow a user that is unable to speak, or that is incapable of speaking, to participate in an in-session voice chat by inputting text and having the text converted to speech (e.g., synthesized voice data) that can then be sent to other devices participating in the session. The user enables a text-to-speech conversion feature on his or her own device. Based on the enabled feature, functionality enabling text to be entered is activated and the entered text is converted into speech data.

Session text-to-speech conversion

Device linking is described. In one or more implementations, data is maintained at a network service that describes characteristics of a plurality of devices that are associated with a user account of the network service. A communication is formed to be received by one of the plurality of devices that includes a portion of the data that pertains to another one of the plurality of devices and that is suitable by the receiving device to discover the other one of the plurality of devices to initiate a local network connection between the devices.

Device linking

Examples described herein provide various devices that enable users to participate in a session. The examples allow a user that is unable to hear, or that is incapable of hearing, to participate in an in-session voice chat by receiving text messages that have been converted from speech to text (e.g., transcribed messages). The user enables a speech-to-text conversion feature on his or her own device. Based on the enabled feature, a notification can be sent to other devices participating in the session. Based on the notification, the other devices are tasked with capturing utterances and sending corresponding speech data to a speech-to-text conversion device so that voice communications can be converted to text messages. Subsequent to conversion, the text messages can be displayed in a chat interface presented as part of the displayed content for the session.

Session speech-to-text conversion

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

Consistency is managed among data operations by coalescing commit operations, adjusting a commit rate to optimize latency, and converging to fairness across servers. Write operations representing a change to data stored by one or more of a plurality of computing devices are received in succession by, for example, a cloud computing service. A state of a plurality of tracking objects is adjusted to indicate whether the change in data has been provided to the computing devices and whether the change in data has been acknowledged by the computing devices. Changes to the same data are coalesced such that only the most recent change is provided to the computing devices for storage. In some embodiments, the commit rate is adjustable such that the commit rate decreases quickly but increases slowly based on measured latencies.

Commit rate management with decoupled commit operations

A mesh is joined by a node, wherein the mesh includes a Distributed Routing Table (DRT) for determining addresses of nodes in the mesh. A DRT message is processed in accordance with a security mode of the DRT.

Security modes for a routing table distributed across multiple mesh nodes

A system, apparatus, method, and computer-readable medium are provided for authorizing a computing node to participate in a group of computing nodes utilizing a shared group password. According to one method described herein, an invitation to join a group is transmitted to a tentative group member node. The invitation is used to establish a connection with a group member node of the group. The tentative group member node generates a hash of a group password and transmits the hash to the group member node. When the group member node receives the hash, the group member node compares the received value to a previously stored hash of the group password. If the previously stored value is identical to the value received from the tentative group member node, then the tentative group member node is authorized as a new member of the group. Otherwise the tentative group member node is not permitted to become a member of the group.

Password-authenticated groups

The claimed system is a multicast programming model for implementation on top of a service oriented framework, specifically a service oriented messaging system. It provides application-layer multicast capability without requiring an IP multicast infrastructure. The claimed system enables service oriented applications to implement multicasting communications easily and efficiently.

Architecture for building a peer to peer messaging platform

Growing community of inventors

Redmond, WA, United States of America

Jeremy Lee Dewey