Microsoft Technology Licensing, LLC

Lei Yu

Chowdhury Sucharit Barua

Julio Estrada

Nagalinga Raju Samuthirapandi

Vasant Kumar Tiwari

Victor Boctor

Vadim Eydelman

Matthias Adam Leibmann

Shivakumar Seetharaman

Jayteerth Narasingrao Katti

Brian Kress

Pretish Abraham

Moustafa Noureddine

Darrell Brunsch

Haibo Luo

Raju Nagalinga S

Nimeesh Patel

Email has become commonplace as a means to communicate among parties non-synchronously by exchanging email messages. Some communications, however, may be more effective in real-time or in near real-time. For instance, service providers may offer a chat feature to accommodate real-time or near real-time help or service communications with customers. However, in this case, the user is likely required to enter credentials and/or context information to transition into a different communication type with the service provider. The present systems and methods provide a continuous conversation experience for the user whereby a message recipient of one message type (e.g., email, text, etc.) may continue a conversation in a different message type (e.g., a chat session, instant message, etc.) without manually providing message context for communicating via the second message type.

Chat-enabled messaging

A message is received, that represents an action to be performed in a service. The message includes a natural language portion and an endpoint to interact with. The natural language portion is parsed to identify the action and the endpoint is interacted with to perform the action.

Natural language service interaction through an inbox

A connector surfaces a configuration user experience that allows a user to select notifications that a user wishes to receive from a service. The user's e-mail system has a URL endpoint identifier, and the service sends the selected notifications to the URL endpoint. The notifications are integrated into the user's inbox, as e-mail messages.

Service integration into electronic mail inbox

Online and on-premise applications identify trusted authentication providers. The applications are configured with a list of trusted issuers of authentication credentials. When an application receives a request requiring authentication, the application returns a 401 response that includes the trusted issuer list. The requesting application compares the trusted issuer list from the 401 response to its own list of authentication providers. If there is a match between the two lists, then the requesting application creates a self-issued token for the authentication provider. The authentication provider uses the self-issued token to generate an authentication token for the requesting application. The requesting application may also directly create a token for a target partner application, without an authentication provider, if there is a direct trust between the two applications.

Integrating server applications with multiple authentication providers

Growing community of inventors

Redmond, WA, United States of America

Lei Yu