# US 12,225,020 B2 · Token management for asynchronous request-reply

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 12,225,020 B2
- Document ID: US12225020B2
- Status: Granted
- Kind: B2
- Application number: 17/496,627
- Filed: 2021-10-07
- Published: 2022-10-06
- Granted: 2025-02-11
- Earliest claimed: 2021-03-31
- Assignees: Microsoft Technology Licensing, LLC
- Applicants: Microsoft Technology Licensing, LLC
- Inventors: Prasham Rajeshbhai Ajmera; Izydor Gryko; Richard Jose Mejia Valencia
- Web page: https://patentgrep.com/patent/US12225020B2

## CPC

- H04L 63/108: {when the policy decisions are valid for a limited amount of time}
- H04L 9/3213: {using tickets or tokens, e.g. Kerberos (network architectures or network communication protocols for entities authentication using tickets in a packet data network H04L63/0807)}
- H04L 9/3228: {One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key}
- H04L 47/762: triggered by the network
- H04L 47/781: {Centralised allocation of resources}
- H04L 47/826: {Involving periods of time}
- H04L 63/0807: {using tickets, e.g. Kerberos (cryptographic mechanisms or cryptographic arrangements for entity authentication using tickets or tokens H04L9/3213)}
- H04L 63/0892: {by using authentication-authorization-accounting [AAA] servers or protocols}
- H04W 12/08: Access security
- H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M)
- H04W: WIRELESS COMMUNICATION NETWORKS (broadcast communication H04H; communication systems using wireless links for non-selective communication, e.g. wireless extensions H04M1/72)

## Abstract

Token expiration is managed for requests in an asynchronous request-reply pattern of communication. If a token in a request expires, an operation to be performed utilizes a new token to execute the operation. The new token is obtained from a status check sent to a different location than the initial request.

## Claims

### Claim 1

A system operable to manage execution of a request that outlasts token expiration in an asynchronous request-reply pattern, the system comprising:
at least one hardware processor;
a work process application program interface (API) executed by the at least one hardware processor to:
receive a request from a client to perform an operation, wherein the request includes a token with an expiration;
create a tracking key for the request;
post the request for processing; and
transmit a response to the client in response to accepting the request, wherein the response includes a reply-after time period, the tracking key, and a location to poll for a status of the request after expiration of the reply-after time period, wherein the location to poll for the status of the request is different from a location of the work process API; and
a status checker API executed by the at least one hardware processor to:
wait for a status check of the request from the client upon a determination that the token has expired;
receive the status check for the request from the client based on the reply-after time period and the location to poll, wherein the status check includes a new token and the tracking key;
check the status of the request using the tracking key;
extract the new token from the status check based on the new token being needed to execute the request;
requeue the request with the new token without issuing a certificate; and
send a reply to the status check with a current status of the request.

### Claim 2 (depends on 1)

The system of claim 1, further comprising:
a background request processor executed by the at least one hardware processor, the background request processor to:
determine that the token expired prior to execution of the request; and
utilize the new token to execute the request; and
a storage to store the token, the new token, the tracking key, and the current status of the request.

### Claim 3 (depends on 2)

The system of claim 2, wherein the status checker API compares the tracking key received in the status check with the tracking key stored in the storage, wherein the tracking key is initially stored in the storage responsive to receiving the request, in order to check the status of the request.

### Claim 4 (depends on 2)

The system of claim 2, wherein the background request processor updates the current status of the request in the storage.

### Claim 5 (depends on 2)

The system of claim 2, wherein to determine whether the token expired prior to execution of the request, the background request processor is to:
determine whether the token is expired; or
determine whether the token has sufficient lease to complete the request.

### Claim 6 (depends on 1)

The system of claim 1, wherein the token and the new token are validated prior to processing the request and the status check.

### Claim 7 (depends on 6)

The system of claim 6, wherein the token is validated for at least one of authentication (AuthN) and authorization (AuthZ) in an identity and access management process.

### Claim 8 (depends on 1)

The system of claim 1, wherein the request is from a tenant of a cloud provider and the request comprises an order for resources from the cloud provider.

### Claim 9 (depends on 1)

The system of claim 1, wherein the request comprises a request for the operation to be performed by an application hosted on a cloud.

### Claim 10 (depends on 1)

The system of claim 1, wherein to extract the new token from the status check based on the new token being needed to execute the request, the status checker API extracts the new token from the status check responsive to a prompt from a background request processor.

### Claim 11 (depends on 1)

The system of claim 1, wherein the location to poll for the status of the request is the location of the status checker API.

### Claim 12

A computer-implemented method to manage execution of a request that outlasts token expiration in an asynchronous request-reply pattern, the method comprising:
receiving a request from a client to perform an operation at a work process application program interface (API), wherein the request includes a token with an expiration;
creating a tracking key for the request;
posting the request for processing;
transmitting a response to the client indicating the response is accepted for processing,
the response including a reply-after time period, the tracking key, and a location to poll for a status of the request after expiration of the reply-after time period,
wherein the location to poll for the status of the request is different than a location of the work process API;
determining that the token transmitted with the request has expired;
waiting for a status check of the request from the client upon a determination that the token has expired;
receiving the status check for the request from the client at the location to poll based on the reply-after time period, wherein the status check includes a new token and the tracking key;
checking the status of the request using the tracking key;
extracting the new token from the status check based at least on the token having expired;
requeuing the request with the new token without issuing a certificate; and
transmitting, to the client, a reply to the status check with a current status of the request.

### Claim 13 (depends on 12)

The computer-implemented method of claim 12, wherein the location to poll comprises a status checker API, and the method further comprises:
determining, by the status checker API, whether the token is expired prior to execution of the request; and
in response to determining the token expired, prompting the status checker API to obtain the new token from the received status check to execute the request.

### Claim 14 (depends on 13)

The computer-implemented method of claim 13, comprising:
storing the new token and the current status of the request in a storage accessible by the status checker API;
retrieving, by the status checker API, the current status of the request to provide to the client; and
storing the tracking key in the storage responsive to receiving the request from the client at the work process API, wherein the stored tracking key facilitates subsequent checking of the status of the request.

### Claim 15 (depends on 13)

The computer-implemented method of claim 13, further comprising:
determining whether starting execution of the request is successful; and
in response to determining that the starting of the execution of the request is unsuccessful,
retrying the starting of the execution of the request unless a number of attempts for retrying the starting of the execution of the request exceeded a threshold.

### Claim 16 (depends on 15)

The computer-implemented method of claim 15, further comprising:
in response to the number of attempts for retrying the starting of the execution of the request not exceeding the threshold,
requeuing the request for execution based on the new token has sufficient lease.

### Claim 17 (depends on 12)

The computer-implemented method of claim 12, further comprising:
determining a current status of the request; and
storing the current status in a data storage that is accessible by a status checker API.

### Claim 18 (depends on 12)

The computer-implemented method of claim 12, further comprising:
retrieving the new token from a data storage accessible by a status checker API; and
queuing the request for processing by a processing endpoint using the new token.

### Claim 19 (depends on 12)

The computer-implemented method of claim 12, wherein the token comprises at least one of a token for validating authentication (AuthN) and a token for validating authorization (AuthZ) in an identity and access management process.