Split ledger software license platform

Aspects of the subject disclosure may include, for example, a processing system including a processor; and a memory that stores executable instructions that, when executed by the processing system, facilitate performance of operations, including requesting a license for software from first equipment of a license holder; receiving a passed ledger associated with the license from the first equipment of the license holder, wherein the passed ledger comprises a latest block; receiving a hash value for the latest block from a software vendor of the software; calculating a hash value for the latest block; and responsive to the hash value provided by second equipment of the software vendor matching the hash value calculated for the latest block: executing the software. Other embodiments are disclosed.

FIELD OF THE DISCLOSURE

The subject disclosure relates to a Split Ledger Software Licensing Platform.

BACKGROUND

Software can be distributed under many kinds of licenses, ranging from open source freeware to pay per use, and everything in between. In large companies and business to business sales, customers often report usage without providing a software vendor with a way to verify how many copies of the software were in use over a given time period. For example, a large company might have an open-ended contract with a software vendor for a ubiquitous product. The license requires the large company to specify a quantity of licenses that were used over a given month or quarter. The quantity of licenses changes for a variety of reasons, including staffing considerations.

One of the more difficult issues is how software handles offline work, as many users are not able to connect to the network every time that they use software. This problem becomes an issue since the software continues to function even if the device gets disconnected from the network. Further, large organizations often prefer bulk contracts that allow multiple users to have access to the software. These bulk contracts should be updated as the conditions of the organization change.

DETAILED DESCRIPTION

The subject disclosure describes, among other things, illustrative embodiments for a split ledger licensing system and method. Other embodiments are described in the subject disclosure.

One or more aspects of the subject disclosure include a processing system including a processor; and a memory that stores executable instructions that, when executed by the processing system, facilitate performance of operations, including requesting a license for software from first equipment of a license holder; receiving a passed ledger associated with the license from the first equipment of the license holder, wherein the passed ledger includes a latest block; receiving a hash value for the latest block from a software vendor of the software; calculating a hash value for the latest block; and responsive to the hash value provided by second equipment of the software vendor matching the hash value calculated for the latest block: executing the software.

One or more aspects of the subject disclosure include a machine-readable medium with executable instructions recorded thereon that, when executed by a processing system including a processor, facilitate performance of operations, including: sending a license for software to first equipment of a license holder; sending a passed ledger associated with the license to the first equipment of the license holder, wherein the passed ledger indicates the software may be licensed for use; receiving a hash value of a latest block in the passed ledger from the first equipment of the license holder; verifying that the first equipment of the license holder has permission to update the hash value in a hash ledger; recording the hash value of the latest block in the hash ledger; sending the hash value of the latest block from the hash ledger to second equipment of a licensee responsive to a query for the hash value of the latest block, wherein a comparative analysis of the hash value permits execution of the software; and recording permission for the second equipment of the licensee to update the hash ledger.

One or more aspects of the subject disclosure include a method, including: requesting, by a processing system including a processor, a license for a software product from first equipment of a software vendor; receiving, by the processing system, a passed ledger associated with the license from the first equipment of the software vendor, wherein the passed ledger indicates a license available for use; receiving, by the processing system, a request from second equipment of a user to utilize the license; appending, by the processing system, a latest block to the passed ledger, wherein the latest block indicates licensed use by the second equipment of the user; calculating, by the processing system, a hash value of the latest block; sending, by the processing system, the hash value of the latest block to the first equipment of the software vendor for recording in a hash ledger; and sending, by the processing system, the passed ledger to the second equipment of the user.

FIG.2Ais a block diagram illustrating an example, non-limiting embodiment of a system for implementing software licensing using a split ledger in the communication network ofFIG.1in accordance with various aspects described herein. As shown inFIG.2A, system200comprises a communications network225, an administrator's device214, a user's device216, a split ledger comprising a passed ledger217and a hash ledger227, wherein the hash ledger227is securely stored on a software publisher's server224in communication with the communications network225.

The passed ledger217is made up of a series of blocks. Block 0 is the initial block generated by the software publisher. Block 0 records an initial sale to a license owner (licensor). Block N (blocks 1, 2, 3, and so on) represents a single transaction, such as requesting and granting of a license to a specific instance of the software or returning the license to the licensor. Each block is ended with a hash of the block, which is then shared with the hash ledger227, and used as the starting information for the next block.

The passed ledger217is passed from one entity to another. In an embodiment, the passed ledger217is passed from the software publisher's server224(at creation) to the licensor, i.e., the administrator's device214, and then onto an application program interface (API) running in the software on the user's device216. When the user is done with the program, the API sends the passed ledger217back to the administrator's device214. Thereafter, the passed ledger217is passed back and forth between the administrator's device214and the user's device216. The name and location of either party may change, such as moving a license from one machine to a new one, or if the software publisher sells the rights to the software to another vendor.

The hash ledger227is maintained by the software publisher's server224as a shared record between the administrator's device214and the user's device216. An identifier for each block written into the passed ledger217is recorded in the hash ledger227as well. The entries in the hash ledger227contain only the proof for the block, not the actual content. As such, the hash ledger227does not reveal the information stored in the block of the passed ledger217that created the hash. A reader of the hash ledger227would only be able to verify recording of a hash value, who wrote the hash value, when, and who has permission to write to the passed ledger217.

When a software publisher creates a software product, i.e., an application, the software publisher has an opportunity to create licenses for that application. Each license comprises a key, that unlocks the software. The buyer of the application provides the proper key in order to use the application. In an embodiment, the application would be able to prove that a license sold to a licensor is valid by using the unique split ledger created for the license sold.

In an embodiment, a user starting the application for the first time on the user's device216requires an Internet connection to pass messages to the licensor. The application software will begin initializing and prompt the user to request a key for the application, and in the background, the API will signal the licensor that a key is required. The licensor can respond with the passed ledger217that the API should append, provided one is available, as well as the location of the hash ledger227. Once the ledgers are created, the software publisher's server224fills in the first block pair with the information from the licensor, recording the initialization on the passed ledger217and reporting the hash to the hash ledger227.

The software publisher's server224then passes the passed ledger217to the licensor (i.e., the administrator's device214), which maintains a catalog of licenses and the users for which the software application can be used. The passed ledger217block zero from the software publisher's server224contains the information on the key, as well as the conditions of use, such as lifespan, and if the license may be shared, etc.

When a user (on a user's device216) requests a key, the licensor verifies that a license is available for the user. The request may be denied if no license is currently available. Once the licensor has found an available license, the licensor provides the passed ledger217to the user. The user's program then appends a block to the passed ledger217and returns the completed block to the licensor, which verifies the block and updates the hash ledger227. The block recorded in the passed ledger217is in a plain text format. The block includes a hash of the previous block, header data that includes information about the creation of the block, and body data that includes information about what transaction is being recorded. Any hashing algorithm can be used provided that the amount of time required to find a collision (i.e., a block containing different information that will produce a hash value that is the same as another block) for the algorithm is much greater than the lifespan of the block, i.e.:
T_((collision))>>T_((lifetime of block))
In other words, the lifetime of a block should be much, much less than the time required to find a collision. The receiver of the block (i.e., the user of the software) performs the hashing calculation, and the licensor verifies the calculation.

In an embodiment where there is a high amount of natural trust, such as users internal to a company, there is no need to increase difficulty of the hashing algorithm. As such the hashing algorithm selected should be one that is very fast, meaning that it doesn't take long to solve a block. Further, there is no need for a nonce to obscure data in the first block, as there would be for sharing personal data.

In an embodiment where there is less inherent trust, some measures can be used to increase the complexity of the hashing algorithm. For some slower hashing algorithms there is an inherent delay, which makes the amount of time to find a collision through brute force attacks computationally prohibitive, such that the amount of time needed to determine such a block would far exceed the lifetime of the software license. The next option is a hashing algorithm having a much longer output. As generally notable, the longer the output, the lower the chance of collision. Collisions cause blockchains to run into difficulty, as technically more than one block can both be presented as the correct question to the proven answer.

Key discovery is when a fraudulent user discovers the secret key of another user. Studies have been done on the security risks and lapses that come from accounts having simple keys, and there are several papers on both bitcoin and Ethereum cases where accounts were quickly drained as soon as they were filled. This can be thought of as a rainbow table attack where a thief generates a list of private keys, determines the corresponding public keys, and then waits for the public key (account) to become active. A solution to this problem is described below for low value software. Any thief that gains access to the chain and can report a new block that indicates ownership passing to themselves would, however, only last as long as the licensor allows before a timeout. In this scenario, if the passed ledger is not returned, the chain is recycled, and a new split ledger is begun. For high value software, there could be two safeties in place: Immediate sharing of blocks to the licensor (which would be notified by the update in the hash ledger). In this scenario, the API of the user shares the block (not the rights per se) with the licensor, and at the same point they share the hash with the hash ledger. For even higher value software (such as industrial controls) the API could require that the block be shared with the licensor, who maintains all rights to update the hash ledger. Therefore, the API runs the application, requests the license, completes the block, and then waits for verification from both the passed ledger and the hash ledger before starting the software. The licensor would check credentials for the user, a serial number of the user device, and potentially a token or one time password, and then determine the likelihood for a need to create a new block.

Once the hash ledger227is updated, the API running on the user's device216can query the hash ledger227to verify that the new block has been added to the passed ledger217, thereby permitting the application run on the user's device216.

In an embodiment, the split ledger technology is based on a notion of limited trust. Cryptocurrencies were created in a way that moved trust from a central institution to a mathematical formula. This shift in trust allowed for a very secure transaction to happen between two parties who do not trust each other, to occur without requiring them to put their trust in a third party. A blockchain implementation for cryptocurrencies helped to create the system, which is described as trustless. However, most transactions involve activities that occur away from the blockchain, which means that there is still a limited amount of trust required, even for cryptocurrency transactions. For example, if a user pays for something using a cryptocurrency, the user should trust that whatever they paid for will be delivered as promised, since the cryptocurrency payment will be permanently written on the blockchain.

This limited trust system provides incentives for each participant. The seller benefits by being able to sell their asset for money, the buyer benefits by getting access to the software that they were trying to purchase, and the entity that maintains the hash ledgers benefits by providing this service, known as Keys as a Service (KaaS). KaaS is a business model that publishers and users ensure the integrity of the transactions by partnering with an entity that they can share a limited amount of trust. This partner is never given the data about what the transaction held, nor any payment details. The partner is simply provided with the next key and expected to append the next key to the hash ledger. This service can be provided at a minimal cost to maintain access to the data stored in the hash ledger and maintain the permissions as to whom can update the hash ledger next. As such, the role of KaaS, is to ensure that the chains can move forward as needed by the users. The users pay a small fee based on the smart contract decided at the creation of the chain with the KaaS. At times, potential users may request the hash ledger from the KaaS provider. Potential users would make such requests to verify the contents of the passed ledger or to identify the party who is currently owns the license. Since every asset has a unique pair of chains, the naming convention can be standardized. The information on where to find the hash ledger is encoded into the title of the passed ledger, which creates a simple path to verify the content is in fact correct.

In general, the greatest risk to the system is key loss, or key discovery. If a user loses their key while they are the owner of a blockchain, then they lose the right to update the chain with that key. A protocol to recall chains through replacement will be necessary. In such a protocol, the owner of the license (as opposed to the user), the publisher, and the KaaS provider agrees that the old chain is null and only a new chain is valid. This could be accomplished by simply deleting the hash ledger.

In an embodiment, the software publisher creates the passed ledger for the licensor and maintains control of the hash ledger. Hence, the software publisher should be an entity that both the user and the licensor can trust to accurately maintain these logs. Each participant can fully trust that the mathematical checks will be accurate. As such, the participants can “fully trust” the transactions in the same way that a traditional blockchain trusts that the miners' math will be correct.

But neither entity should trust the software publisher with sensitive data, such as payment information, personally identifying information (PII), or even the software that is being protected. In most instances, the specific software might need to be included, so that limited use ledgers cannot be mixed with full use ledgers. For internal business use cases, the relationship between user and licensor is one of trust; however, there could be other use cases where there is a lack of trust. Limited trust only works in situations where the success of the third party can be tied to the success of the other parties involved in the situation. In an example of limited trust without mutual gain, a homeowner may give a spare house key to a neighbor so that the neighbor can gain access to the house in the event of an emergency. But the homeowner may not give the neighbor a code to an alarm system for the house, so that the neighbor cannot access the house undetected. Mutual gain can be achieved if the neighbors exchange their keys.

In an embodiment, the software licensing platform can embody smart contracts, like traditional smart contracts implemented by the Ethereum network or the Hyperledger project. A smart contract can be described as an If/Then statement, where it is understood that two parties would agree on the input “If” (e.g., “If the time is between 13:00 and 21:00 GMT . . . ”) and therefore they can be assured that they agree on the output “Then” (Then user 1234 can have full access to license 9876 until 21:00 GMT), without the other party's verification.

At the completion (i.e., expiration) of a smart contract, one of two things should happen: either 1) the contract should end or 2) a continuance should be granted. If the software governed by the smart contract is going to continue to be used, the license should be updated. To update the license, the following series of events occurs: first, the software API queries the hash ledger (1) to make sure there has been no change, then the software API updates the passed ledger (2) with a request for a new key and passes the newly added block to the licensor (3). Next, the licensor alerts the software vendor (4) to the updated hash ledger. The vendor may query the passed ledger (5) and determine the validity of the request (larger organizations may have limits on the number of active accounts or which users are still valid). If the account is still valid, a new block is written to the passed ledger and the hash is recorded on the hash ledger (6). The user's API then queries the hash ledger (7) and plugs in the new key for the application. The new key will have a predefined lifespan, after which another set of blocks should be appended, if the license is to be further extended.

In an embodiment, the system provides an opportunity to track the cost of using a product, and the payment received. Additionally, the user may not always be the party bearing the cost, as advertisers may front the money in exchange for a user viewing an ad. Additional “in lieu of payment” options might include proof of good work, either for professionals utilizing software in a way which demonstrates the software's capabilities or a charitable function where users can collaborate on projects, and can apply the time worked towards the use of a software platform. All these costs and payments should be tracked; however, the details of each transaction can remain hidden from the system to maintain industry trade secrets.

In an embodiment, the API in the user's copy of the software would request the passed and hash ledgers, verify they are accurate, compute new blocks, and check the validity of the smart contract. For offline services, the smart contract sets parameters regulating the timeframe in which the license remains valid. For connected use cases, the smart contract may be stored on a cloud instance and require the software to check in periodically.

FIG.2Bdepicts an illustrative embodiment of a method of software licensing in accordance with various aspects described herein. As shown inFIG.2B, the method begins at step231, where the prospective licensor for a licensed product requests the license from a vendor. In an embodiment, the licensed product is software, and the vendor is a software publisher or a creator of the licensed product. In an embodiment, the licensor is a company that used the software.

Next in step232, the licensor receives a passed ledger from the vendor. In an embodiment, the passed ledger indicates that the licensed product is available for licensed use.

Next in step233, the licensor creates a licensing block for the licensed product and appends the block to the passed ledger. In an embodiment, the licensing block is created in response to a request from equipment of a user desirous to use the licensed product. In an embodiment, the user is a member of the company who launches the software, which in turn creates the request. In an embodiment, the licensing block identifies the user as a licensee.

Next in step234, the licensor calculates a hash value for the licensing block and sends the hash value to the vendor. In an embodiment, the vendor records the hash value in a hash ledger. In an embodiment, the hash ledger is maintained by the vendor, a third party on behalf of the vendor, or an owner of the right to grant the license.

Next in step235, the licensor sends the passed ledger, including the licensing block, to the equipment of the user. In an embodiment, sending the passed ledger to the equipment of the user is contingent upon payment via a smart contract. In an embodiment, the equipment of the user calculates a hash value for the licensing block, requests the hash value recorded for the passed ledger from the vendor, and compares the hash value received from the vendor to the hash value calculated for the licensing block. If the compared values are the same, then the equipment of the user continues to use the licensed product, e.g., continues execution of the software. In an embodiment, the equipment of the user continues execution of the software until expiration of a timer recorded in the licensing block. In another embodiment, the equipment of the user periodically sends a message to query the hash ledger and stops use when the latest value changes from that of the license block.

Next in step236, the licensor received the passed ledger back from the licensee. In an embodiment, the licensee appends a new block to the passed ledger that indicates the licensed use has ended, and that the software is available for further licensed use. In another embodiment, the licensor appends the new block to the passed ledger.

Next in step237, the licensor verifies the hash value recorded in the hash ledger by requesting the hash value from the vendor and comparing the hash value received to a hash value calculated from the passed ledger.

Referring now toFIG.3, a block diagram300is shown illustrating an example, non-limiting embodiment of a virtualized communication network in accordance with various aspects described herein. A virtualized communication network is presented that can be used to implement some or all the subsystems and functions of system100, the subsystems and functions of system200, and method230presented inFIGS.1,2A,2B and3. For example, virtualized communication network300can facilitate in whole or in part sending or receiving a passed ledger associated with a software license, requesting licenses from a license holder, or verifying or updating hash values with a software vendor of the software.

Turning now toFIG.4, there is illustrated a block diagram of a computing environment in accordance with various aspects described herein. In order to provide additional context for various embodiments of the embodiments described herein,FIG.4and the following discussion are intended to provide a brief, general description of a suitable computing environment400in which the various embodiments of the subject disclosure can be implemented. Computing environment400can be used in the implementation of network elements150,152,154,156, access terminal112, base station or access point122, switching device132, media terminal142, and/or VNEs330,332,334, etc. Each of these devices can be implemented via computer-executable instructions that can run on one or more computers, and/or in combination with other program modules and/or as a combination of hardware and software. For example, computing environment400can facilitate in whole or in part computing blocks and hash values for blocks in the passed ledger and verifying that information recorded in of the passed ledger is accurate.

The illustrated embodiments of the embodiments herein can be also practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be in both local and remote memory storage devices.

Turning now toFIG.6, an illustrative embodiment of a communication device600is shown. The communication device600can serve as an illustrative embodiment of devices such as data terminals114, mobile devices124, vehicle126, display devices144or other client devices for communication via either communications network125. For example, computing device600can facilitate in whole or in part equipment of the user, the administrator's device214, the equipment of the user (user's device216), the software publisher's server224, or elements of communications network225that enable maintenance and administration of the passed ledger217and the hash ledger227.