Microsoft Technology Licensing, LLC

Ajay Arvind Bhave

Ning Zhang

Aaron J Smith

Rahul Newaskar

Chih-Pin Benjamin Kao

Sriravi Kotagiri

Mikael P Horal

Tyron Michael Balascio

Emeron Bachhuber

Yadnyesh Joshi

Brian Stuart Perlman

Tarik Soulami

Jihad Tafas

Mark Zagorski

David Maralack

Mike Weidenbener

Chris McMillan

Shane Patton

Aditya Dhar

Matt Graves

Eric Timmreck

Tyron M Balascio

Storage access requests are received from one or more applications. Multiple servers update multiple virtual disks as directed by the storage access requests. The virtual disks store data that is write order dependent across the virtual disks. Logs are associated with the virtual disks. Information associated with each storage access request is stored in one of the logs. A cycle of log switching is performed. A write order consistent tracking coordinator coordinates the log switching with agents at the servers to maintain request ordering. Replication coordinators coordinate the application of the switched-out log files from primary storage to replica storage, creating a write-order consistent point on the replica side matching the primary side, and providing for failure resiliency regarding transfer of the logs. The replication logs may be received individually on the replica side from the servers on the primary side to enable highly scalable parallel/simultaneous transfers of the logs.

Snapshot and replication of a multi-stream application on multiple hosts at near-sync frequency

Methods and systems are disclosed in which inherited activation opens a secure communication path from the host operating system (OS) to the guest (virtual machine) OS. The license state of the software on the host is passed through this channel, and software installed in the guest uses this information to inform its own product activation process. The virtualized (guest) software may then activate without any outside communication when the license requirements for the host are met.

Inherited product activation for virtual machines

In some embodiments, an activation object used to activate a software product is stored in a directory service. The activation object may, for example, comprise a proof of purchase token and/or information about the directory service, and may be communicated from the directory service to a client computer after the directory service authenticates a request from a client computer for access to the activation object. In some embodiments, a directory service is interrogated for an activation object used to activate software on a client computer. A client computer may, for example, receive an activation object from the interrogated directory service, and use the received activation object to activate a software product on the client computer. In some embodiments, a non-transitory computer-readable medium has instructions stored thereon that, when executed by a computer, cause the computer to interrogate a directory service for an activation object used to activate software on the computer. The computer may, for example, receive the activation object from the directory service, and use the received activation object to activate a software product.

Directory service distributed product activation

Systems and methods are provided for activation of software that uses digital licenses. In some embodiments, a software vendor may securely deliver at least one digital proof-of-purchase to an OEM (e.g., to avoid piracy of software licenses). The OEM may install an associated software copy on a computer system, and store the at least one digital proof-of-purchase on it. The OEM may communicate the proof(s)-of-purchase stored on the computer system and its system identifier to the software vendor. A user of the computer system may attempt to activate the OEM pre-installed software by sending an activation request to a software vendor, who may verify whether or not the digital proof-of-purchase and system identifier in the activation request match those previously reported by the OEM, and may either grant or deny the activation request.

Software activation using digital licenses

An instance of an application hierarchy can be stored on a client computer to facilitate enforcement of software licensing by a software license component of a software protection system. The application hierarchy is a tree structure (e.g., unordered) that includes a top node, one or more product offering group(s), and, one or more selling unit(s). A computer-implemented software protection system can facilitate enforcement of software licensing on a client computer. The software protection system includes a software license component that can store and enforce software licensing rule(s). The software license component can further manipulate state data of an instance of the application hierarchy stored in a licensing data store via application program interface(s) (APIs). State data and/or property(ies) of a particular node of the instance of the application hierarchy can be accessed through the API via an assigned identifier.

Application hierarchy and state manipulation

Applications or operating system components requiring a SKU, or other indicator of an operating system, make a call to an API. The calling application passes an indicator of the most current version of an operating system known at the time of the application creation as an argument. This argument may be an indictor of the operating system version, build number, and service pack version, for example. The called API may reference a table of operating system SKUs with the indicator of the most current operating system known to the calling application. If found, the API returns the corresponding SKU to the calling application. If not found, the API returns the SKU corresponding to the closest sequential match to the passed in indicator. The calling application may then execute believing it is using the operating system corresponding to the returned SKU.

SKU determination mechanism and API

Growing community of inventors

Redmond, WA, United States of America

Ajay Arvind Bhave