# US 12,217,045 B2 · Negative numbering to log web service update attempts > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 12,217,045 B2 - Document ID: US12217045B2 - Status: Granted - Kind: B2 - Application number: 18/296,288 - Filed: 2023-04-05 - Published: 2024-10-10 - Granted: 2025-02-04 - Earliest claimed: 2023-04-05 - Assignees: Microsoft Technology Licensing, LLC - Applicants: Microsoft Technology Licensing, LLC - Inventors: Dmitry Valentinovich Kholodkov; Rahul Nigam; Nidhi Verma - Web page: https://patentgrep.com/patent/US12217045B2 ## CPC - G06F 8/65: Updates (security arrangements therefor G06F21/57) - G06F 8/71: Version control (security arrangements therefor G06F21/57); Configuration management - H04L 41/082: the condition being updates or upgrades of network functionality - G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N) - H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M) ## Abstract A logging system for an orchestration system that implements a rollout service to deploy updates to a cloud service includes: an orchestrator service host computer hosting the rollout service; a service bus connecting the orchestrator service host computer with a network on which the cloud service is provided; and a database to which the rollout service records a log of a deployment of an update, the log comprising an entry for each of a number of subsets of network components supporting the cloud service. Each record in the log refers to a payload version deployed to a corresponding subset of the network components supporting the cloud service. In response to detection of an issue with the deployment of the update in a particular subset of the network components, the rollout service retains a record in the log of each payload version deployed by changing a payload version number to be negative in each record of the log prior to a restart of the deployment back to an earlier subset of the network components with a new payload version to avoid the issue. ## Claims ### Claim 1 A logging system for an orchestration system that implements a rollout service to deploy updates to a cloud service, the system comprising: an orchestrator service host computer hosting the rollout service; a service bus connecting the orchestrator service host computer with a network on which the cloud service is provided; and a database to which the rollout service records a log of a deployment of an update, the log comprising an entry for each of a number of subsets of network components supporting the cloud service; wherein each record in the log refers to a payload version deployed to a corresponding subset of the network components supporting the cloud service; and wherein, in response to detection of an issue with the deployment of the update in a particular subset of the network components, the rollout service retains a record in the log of each payload version deployed by changing a payload version number to be negative in each record of the log prior to a restart of the deployment back to an earlier subset of the network components with a new payload version to avoid the issue. ### Claim 2 (depends on 1) The logging system of claim 1, wherein each subset of network components corresponds to a stage within a ring of a userbase. ### Claim 3 (depends on 2) The logging system of claim 2, wherein the restart returns the deployment to a first ring and stage of the userbase. ### Claim 4 (depends on 2) The logging system of claim 2, wherein each record in the log comprises a stage identification and a ring identification. ### Claim 5 (depends on 1) The logging system of claim 1, wherein each subset of network components is a farm comprising a number of virtual machines. ### Claim 6 (depends on 1) The logging system of claim 1, wherein in response to detection of a subsequent issue with the deployment of the update, the rollout service continues to retain a record in the log of each payload version deployed by again restarting the deployment back to an earlier subset of the network components with a new payload version and again changing a payload version number to be negative in each record of the log prior to a current restart. ### Claim 7 (depends on 1) The logging system of claim 1, wherein each payload version comprises a difference in configuration, settings or metadata with other payload versions. ### Claim 8 (depends on 1) The logging system of claim 1, wherein, when implementing a restart, the rollout service adds one or more records to the log during a transition period before the restart in the earlier subset of the network components begins. ### Claim 9 (depends on 1) The logging system of claim 1, wherein the records in the log are organized in a table. ### Claim 10 (depends on 9) The logging system of claim 9, wherein the log comprises a second table for logging progress of an update at a farm or work item level, the second table comprising a column for work item status, each record in the second table before a restart being marked as cancelled for a corresponding work item status. ### Claim 11 A method of logging deployment of an update to a cloud service with an update system comprising: an orchestrator service host computer hosting an update rollout service; a service bus connecting the orchestrator service host computer with a network on which the cloud service is provided; and a database to which the rollout service records a log of a deployment of an update, the log comprising an entry for each of a number of subsets of network components supporting the cloud service, the method comprising: deploying the update to a next subset of components supporting the cloud service; detecting whether there is an issue with deployment of the update in that subset; in response to detecting an issue, transitioning to a restart including marking a payload version as negative in each record in a log of the deployment prior to the restart; and restarting the deployment at an earlier subset of components that had previously received a different payload version of the update. ### Claim 12 (depends on 11) The method of claim 11, wherein each subset of components corresponds to a stage within a ring of a userbase. ### Claim 13 (depends on 12) The method of claim 12, wherein restarting the deployment comprises returning the deployment to a first ring and stage of the userbase. ### Claim 14 (depends on 11) The method of claim 11, wherein each subset of components corresponds to a farm comprising a number of virtual machines. ### Claim 15 (depends on 11) The method of claim 11, further comprising: in response to detecting a subsequent issue, again transitioning to a restart including marking a payload version as negative in each record in a log of the deployment prior to a current restart; and restarting the deployment at an earlier subset of components that had previously received a different payload version of the update. ### Claim 16 (depends on 11) The method of claim 11, wherein each payload version comprises a difference in configuration, settings or metadata with other payload versions. ### Claim 17 (depends on 11) The method of claim 11, further comprising, when implementing a restart, adding one or more records to the log during a transition period before the restart in the earlier subset of the components begins. ### Claim 18 (depends on 11) The method of claim 11, further comprising including in the log records for progress of an update at a farm or work item level comprising an entry in each record for work item status, wherein each record made before a restart is marked with a cancelled work item status. ### Claim 19 A non-transitory computer readable medium, the medium comprising programming instructions that, when executed by a processor of an orchestrator service, cause the processor to log deployment of an update to a cloud service by: deploying the update to a next subset of component supporting the cloud service; detecting whether there is an issue with deployment of the update in that subset; in response to detecting an issue, transitioning to a restart including marking a payload version as negative in each record in a log of the deployment prior to the restart; and restarting the deployment at an earlier subset of components that had previously received a different payload version of the update. ### Claim 20 (depends on 19) The non-transitory computer readable medium of claim 19 further comprising programming instructions to cause the processor to log the deployment by: in response to detecting a subsequent issue, again transitioning to a restart including marking a payload version as negative in each record in a log of the deployment prior to a current restart; and restarting the deployment at an earlier subset of components that had previously received a different payload version of the update.