Method and system for key performance indicators and reward in organizations

Abstract

Systems, devices, and methods for a blockchain network based on key performance indicator (KPI) management systems to record KPI goals, track progress towards these goals, and to trigger rewards for achieving these goals within the blockchain network including generating, by a key performance indicator (KPI) creation module (120), one or more key performance indicators (KPIs) corresponding to one or more minted tokens minted through a minting module (105); generating, by a validation rule engine module (123), one or more validation rules for the one or more KPIs; submitting, by a proof submission by employee module (124), a proof of completion of the one or more validation rules; validating, by a proof validation by validator module (125), the submitted proof of completion; and transferring, by a transfer module (106), one or more tokens based on the validated proof.

Description

PATENT COOPERATION TREATY APPLICATIONTITLE: Method and System for Key Performance Indicators and Reward in OrganizationsINVENTORS: Sanjeev Azad, Piyush Jha, Raj Kumar Jha, Yevgeniy Leybzon, Jakir Hussain, and Rahul SinghCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to US Provisional Patent Application No. 63 / 521,224 filed on June 15, 2023, which is incorporated herein by reference in its entirety for all purposes.FIELD OF ENDEAVOR

[0002] The embodiments herein generally relate to the method and system for Key Performance Indicators (KPIs) and rewards in organizations.BACKGROUND

[0003] Many organizations utilize employee evaluation processes and systems, which in general are either subjective or ineffective in producing measurable results (due to perception and biased decisions), resulting in employee dissatisfaction. This results in a high employee attrition rate, which is one of the most critical management issues for many organizations.SUMMARY

[0004] An embodiment of a method disclosed herein comprises generating, by a key performance indicator (KPI) creation module, one or more key performance indicators (KPIs) corresponding to one or more minted tokens minted through a minting module; generating, by a validation rule engine module, one or more validation rules for the one or more KPIs; submitting, by a proof submission by employee module, a proof of completion of the one or more validation rules; validating, by a proof validation by validators module, the submitted proof of completion; and transferring, by a transfer module, one or more tokens based on the validated proof.

[0005] In another embodiment, the one or more KPIs may be one or more KPIs for evaluating employees of an organization, and if the proof submitted by any of theemployees is validated, the one or more tokens may be automatically transferred and disbursed to a non-custodial wallet of the employee as reward.

[0006] In another embodiment, the method may further comprise the step of mapping and assigning, by a KPI lifecycle module, the one or more KPIs to each employee of the organization.

[0007] In another embodiment, the method may further comprise the step of defining, by a KPI lifecycle module, one or more custom KPIs customized to each employee of the organization to tailor performance metrics to different roles of employees of the organization.

[0008] In another embodiment, the method may further comprise the steps of: generating a pair of identity and private key for an employee of the organization onboarding onto the system; and assigning the non-custodial wallet to the identity for the onboarded employee.

[0009] In another embodiment, the method may further comprise the step of recording information of the employee related to the steps of submitting, validating, and transferring on a distributed digital ledger of a blockchain system of the system, wherein the blockchain network may include a plurality of validator nodes, and each of the plurality of validator nodes may include the distributed digital ledger and be configured to participate in a consensus protocol to validate transaction including the submitted proof.

[0010] In another embodiment, the method may further comprise the step of receiving approval of multiple parties before the step of transferring, wherein if the proof is not validated within a stipulated time frame or does not receive the approval of multiple parties, the one or more tokens may be returned back to a central fund pool of the system (100), wherein if the proof is validated within the stipulated time frame and receives the approval of multiple parties, the one or more tokens may be transferred and disbursed to the non-custodial wallet.

[0011] An embodiment of a system disclosed herein comprises: a token framework module configured to mint, transfer, redeem, and burn one or more tokens; a key performance indicator (KPI) lifecycle module configured to create one or more master KPIs corresponding to the one or more minted tokens; and a KPI validation engine module configured to define one or more validation rules for the one or more master KPIs and validate a proof of completion of the one or more validation rules, wherein the token framework module is further configured to transfer one or more tokens based on the validated proof.

[0012] In another embodiment, the one or more KPIs may be one or more KPIs for evaluating employees of an organization, and if the proof submitted by any of the employees is validated, the one or more tokens may be automatically transferred and disbursed to a non-custodial wallet of the employee as reward.

[0013] In another embodiment, the KPI lifecycle module may be further configured to map and assign the one or more master KPIs to each employee of the organization.

[0014] In another embodiment, the KPI lifecycle module may include a custom KPI and goal creation module configured to define one or more custom KPIs customized to each employee of the organization to tailor performance metrics to different roles of employees of the organization.

[0015] In another embodiment, the KPI validation engine module may be configured to validate the submitted proof of completion of the one or more validation rules by multiple validators.

[0016] In another embodiment, the system may further comprise a smart contracts module configured to create a smart contract to disburse the one or more tokens, wherein the smart contracts module may further include a multi-signature contract module configured to create a time-locked and escrowed multi-party contract, which requires approval of multiple parties to disburse one or more tokens, wherein the KPI validation engine module may include a validation rule engine module configured to leverage an integration service module where at least one of an internal system of the organization and a third-party external system is integrated into the system to connect and fetch a result of validation of the proof, wherein the integration service module may include a Lightweight Directory Access Protocol (LDAP) and active directory module including an LDAP and a directory, wherein information of employees of the organization may be included in the directory and is used by any of the modules, to authenticate each employee of the organization through the LDAP within the system, wherein during an onboarding event of an employee of the organization onto the system on the onboarding contract module, the information of the employee of the onboarding event from the directory may be incorporated into a blockchain network of the system.

[0017] In another embodiment, the smart contracts module may include an onboarding contract module configured to create a pair of identity and private key for the onboarded employee and assign the non-custodial wallet to the identity for the onboarded employee, wherein the private key for accessing and managing the non-custodial wallet maybe encrypted, wherein the identity for the onboarded employee may be a decentralized identity in the blockchain network.

[0018] In another embodiment, the system may further comprise a decentralized application interface module and a decentralized application middleware, wherein the decentralized application interface module may include the non-custodial wallet and a web and mobile-based decentralized client interface configured to perform function calls to the blockchain network to execute actions related to the non-custodial wallet, wherein the decentralized application middleware may include a NodeJS-based Web3 JS and / or EEA client libraries configured to allow the web and mobile-based decentralized client interface to perform function calls on the blockchain network over a JSON RPC protocol.

[0019] In another embodiment, the blockchain network may include a plurality of validator nodes, and each of the plurality of validator nodes may include a distributed digital ledger and a distributed smart contract and be configured to participate in a consensus protocol to validate transaction including the submitted proof.

[0020] In another embodiment, the integration service module may include a company performance indicator engine module configured to measure performance data of the organization and provide the data to a token value generation engine module configured to calculate a final value of the one or more tokens transferred to the non-custodial wallet.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principals of the invention. Like reference numerals designate corresponding parts throughout the different views. Embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which:

[0022] FIG. 1 illustrates services and modules on a blockchain-based Key Performance Indicator (KPI) management system, according to one embodiment;

[0023] FIG. 2 illustrates different system roles and their interaction with services within a blockchain-based KPI management system, according to one embodiment;

[0024] FIG. 3 illustrates the integration service of a blockchain-based KPI management system, according to one embodiment;

[0025] FIGS. 4 illustrates a private permissioned consortium blockchain network, according to one embodiment;

[0026] FIG. 5 illustrates all possible prominent workflows of a blockchain-based KPI management system, according to one embodiment;

[0027] FIG. 6 shows a block diagram and process of an exemplary system in which an embodiment may be implemented;

[0028] FIG. 7 depicts a cloud computing environment for implementing an embodiment of the system and process disclosed herein; and

[0029] FIG. 8 depicts a high-level signal flow block diagram for an interoperable streaming device system.DETAILED DESCRIPTION

[0030] The following description is made for the purpose of illustrating the general principles of the embodiments disclosed herein and is not meant to limit the concepts disclosed herein. Further, particular features described herein can be used in combination with other described features in each of the various possible combinations and permutations. Unless otherwise specifically defined herein, all terms are to be given their broadest possible interpretation including meanings implied from the description as well as meanings understood by those skilled in the art and / or as defined in dictionaries, treatises, etc.

[0031] In one embodiment, methods and systems disclosed herein may comprise management systems based on Key Performance Indicators (KPIs) utilizing blockchain technology. An example blockchain may comprise a distributed digital ledger of transactions with growing lists of records securely linked together using cryptographic hashes. Another example blockchain may comprise a digital ledger of transactions duplicated and distributed across a network of computer systems on the blockchain.

[0032] In one embodiment, the disclosed systems and methods may utilize blockchain in an organization to record KPI goals for employees, track progress towards these goals, and trigger rewards for achieving these goals within the blockchain. In one embodiment, key information related to making reward decisions may be recorded on a blockchain ledger, in a decentralized, secure, and transparent record-keeping system. In one embodiment, the disclosed systems and methods herein may utilize decentralization and transparency to provide a clear and objective record of employee performance and rewards on a distributed digital ledger of a blockchain system of the system. In one embodiment, the disclosed systems and methods herein may allow for securing and protecting reward records through improved efficiency, whereby employee rewards and KPI systems may streamline and automate award processes, such as tracking progress toward rewards. In one implementation,an embodiment of a blockchain-based rewards and KPI method and system disclosed herein may provide employees with clear performance targets and rewards for meeting those targets, thereby increasing employee engagement and motivation.

[0033] Embodiments of the disclosed systems and methods herein may further enable integration with other enterprise systems, such as an organization directory to simplify employee onboarding into an enterprise. Embodiments of the disclosed systems and methods may allow utilizing token economics (tokenomics) and gamification in KPI management, and improve employee engagement and motivation within the workplace. Embodiments of the disclosed systems and methods herein may utilize blockchain tokens as a form of currency and rewards, to provide benefits of game-like elements and mechanics to engage and motivate employees.

[0034] Embodiments of the disclosed systems and methods herein may enable the rewarding of organization employees within a distributed technological ecosystem based on meeting and exceeding KPI targets. In one implementation, the disclosed system and method herein may adhere to Web 3.0 principles, as multi-party contracts (e.g., employees, organization administration, validators) may be established to bring transparency through blockchain-based smart contracts.

[0035] Referring now to the drawings, FIG. 1 shows a block diagram of an embodiment of a blockchain-based KPI management system 100 implementing a blockchainbased KPI management, disclosed herein. In one implementation, the system 100 may comprise services and modules including: a fund management module 102 which is configured to provide the system 100 token management service rights; a token framework module 104 service which is configured to create / mint different kinds of blockchain tokens; a token value generation module 109 which is configured to provide the system 100 with token value calculation; a smart contracts module 111 which is configured to provide management modules related to deployed smart contracts; a KPI lifecycle module 118 which is configured to perform functions which may be applied to create master KPIs, map and assign those master KPIs to each employee to define custom KPIs / goals; a KPI validation engine module 122 which is configured to facilitate the validation of a KPI using defined validation rules by multiple validators against submitted evidence / proof by employees; an integration service module 127 which may be a unified integration service for the blockchain-based KPI management system 100 and be configured to integrate the blockchain-based KPI management system 100 with internal company systems; and a pool management module 131configured to facilitate the creation of a pool of the system 100 for roles such as managers and validators.

[0036] In one embodiment, the fund management module 102 may include a fund-to- token conversion calculation engine 103, which may be executed by a user fund manager. This engine 103 may be responsible for converting available funds (in dollars) into blockchain-based tokens. The initial value of the token may be assigned a dollar value, maintaining a configured token-to-fund currency ratio (e.g., $1 = 4 Tokens). For example, a business group may allocate an annual grant of $50,000 to generate new tokens every year. This $50,000 grant may be used to distribute tokens to employees. The amount of the grant may then be converted into tokens using a l-to-4 ratio (i.e., $0.25 per token, resulting in 200,000 tokens to be distributed throughout the year). If any business groups wish to add more funds, additional tokens may be minted for the allocated amount.

[0037] To ensure these tokens appreciate over time, a small percentage of the company's profile may be allocated and distributed equally among each token. In the example above, with 200,000 tokens minted during the year and a grant value of $50,000, an additional $10,000 added for that year would increase the value of each token to $0.30 from the original value of $0.25 (current token value + additional fund value of $10,000 / 200,000 i.e., $0.05).

[0038] In another embodiment, the token framework module 104 may further comprise; a minting module 105 configured to receive requests for and execute a minting / creation token process. In some embodiments, the minting module 105 may refer to a process of turning deposited fund (for example, dollars) assets into digital ERC20 standard fungible tokens that may be stored, moved, and recorded onto the blockchain.

[0039] In another embodiment, a transfer module 106 may be included in the token framework module 104, which is configured to receive and execute requests to transfer tokens between designated locations or accounts within the blockchain-based KPI management system 100.

[0040] In some embodiments, during the token transfer process by the token transfer module 106, the value associated with the tokens may be fixed (no penalty or a tax) and only metadata related to an owner will be updated to a blockchain based immutable ledger. In another embodiment, the token transfer by the token transfer module 106 may occur directly between wallets or accounts without sending tokens to any central wallet, where no blockchain gas fee will be charged as the proposed blockchain-based KPI management system 100 is a gas-free network.

[0041] In another embodiment a redeem module 107 may be included in the token framework module 104, which is configured to receive and execute a redemption process where a token’s virtual value is converted to a legal tender value.

[0042] In another embodiment, a burn module 108 may be included in the token framework module 104. After the redemption process by the redeem module 107, the redeemed tokens may be burned by the bum module 108 and removed permanently from the token pool where a blockchain ledger may be updated. In some embodiments, although calculation formulae to calculate the actual value of tokens may be prerogative to a company, the token value may change (high / low value) based on timing when the redemption processes by the redeem module 107 are happening. For example, the calculation of the actual value of a token may take into account a company’s value trend, where if a trend is in an upward direction, the token may be redeemed at a higher tender value as opposed to if the company value is trending downward, where a token redemption may be calculated lower.

[0043] In one embodiment, factors that are associated with the calculation formulae may include company performance, business unit performance, and employee performance, where the initial value of the token assigned while minting may remain intact.

[0044] In some embodiments, the token value generation module 109 may further include a value calculation engine module 110, which is configured to handle calculation of token value, where there may be no penalty or charges occurred for the redemption process of tokens from employees. In one embodiment, during the redemption process, the actual value of the token may get calculated using components of the token value generation module 109 such as the value calculation engine module 110.

[0045] In some embodiments, the smart contracts module 111 may comprise: a token disbursement contract module 112 which is configured to create a smart contract to disburse tokens to defined blockchain accounts. In other embodiments the smart contracts module 111 may further include an onboarding contract module 113 which is configured to create a blockchain-based digital identity of system users and assign custodial wallets for them. For example, the blockchain-based digital identity may include a user’s name, job title, and start date.

[0046] In yet another embodiment, the smart contracts module 111 may further include a master KPI contract module 114. This module 114 may be configured to allow master KPI creation by a company admin. The master KPI contract module 114 may serve as a central repository for key performance indicators (KPIs) defined by the company, enabling a cohesive and standardized approach to performance measurement across the organization.

[0047] Other embodiments of the smart contracts module 111 may also include several additional components that further enhance the system 100's capabilities. In one embodiment, a KPI mapping to employee goals contract module 115 which may be configured to allow mapping of master KPIs with each employee by pre-selected managers. This module 115 may facilitate alignment of individual employee goals with broader KPIs of the company, ensuring that each employee's work contributes directly to the overall objectives of the organization. By enabling managers to assign KPIs to their team members, the KPI mapping to employee goals contract module 115 may provide a clear, measurable framework for evaluating employee performance and identifying areas for improvement.

[0048] Another embodiment of the smart contracts module 111 may also include a multi-signature contract module 116. This module 116 may be configured to create a time- locked / escrowed multi-party contract. This contract may add an extra layer of security and accountability to the system 100, as it requires the approval of multiple parties before actions may be executed. This contract may be particularly beneficial in situations where significant decisions or transactions are involved, as it minimizes the risk of unauthorized or fraudulent activities.

[0049] Lastly, other embodiments may include an employee goals life cycle contract module 117. This module 117 may be configured to manage the entire life cycle of employee goals - from creation and assignment to acceptance, proof submission, and validation. The management of life cycle of employee goals may streamline the process of goal management and ensure that each step is documented and verified within the system 100. It may also provide transparency and clarity for employees, as they can easily track the status of their goals and understand what is required for successful completion.

[0050] Referring to the KPI lifecycle module 118, some embodiments may include the KPI lifecycle module 118 which comprises a master KPI creation module 119. This module 119 may serve a critical function in the system 100 by enabling administrators to create reusable master KPI templates for the company.

[0051] The master KPI creation module 119 may be configured to provide a systematic and standardized method for defining performance indicators at the company level. These master KPIs may serve as the foundational metrics from which more specific or customized KPIs may be derived. This process may ensure alignment and consistency in performance measurement across different levels and units of the organization.

[0052] Furthermore, the master KPI creation module 119 may be configured to interact closely with other modules and contracts within the system 100. For instance, themaster KPIs created by this module 119 may be mapped to individual employee goals via the KPI mapping to employee goals contract module 117. This linkage may allow for the translation of overarching company performance metrics into actionable, individual-level goals.

[0053] For example, managers may utilize these master KPIs to create custom KPI goals that are specific to their teams or individual employees. This customization may provide the flexibility to tailor performance metrics to the unique needs and responsibilities of different roles, while still maintaining alignment with the company's overall performance objectives.

[0054] Examples of master KPIs may include broader categories such as "Certification." Custom KPIs or goals derived from these master KPIs may then be more specific, like "Cloud Certification" or "Blockchain Certification."

[0055] In other embodiments, the KPI lifecycle module 118 may further include a custom KPI / goal creation module 120. This module 120 may be configured to provide a service to managers, enabling them to define custom or new KPIs. This feature may be particularly beneficial as it allows for the creation of performance metrics that are tailored to specific roles, projects, or strategic objectives. It may empower managers to set meaningful and relevant goals for their teams, enhancing engagement and performance.

[0056] Once a custom KPI or goal is created using the custom KPI / goal creation module 120, an employee user may be tasked to fulfill and provide proof for it. This custom KPI / goal creation module 120 may create a clear, measurable framework for performance evaluation, ensuring that employees understand what is expected of them and how their performance will be assessed.

[0057] In addition, the KPI lifecycle module 118 may further include a KPI assignment module 121. This module 121 may be configured to facilitate the assignment of KPIs to employees, streamlining the process of translating company objectives into individual responsibilities. With the KPI assignment module 121, managers may easily distribute KPIs among their team members, aligning individual efforts with the broader goals of the company.

[0058] The KPI validation engine module 122 in some embodiments, may further comprise a validation rule engine module 123 which may be configured to leverage the integration service module 127 to connect and fetch validation results from the company’s internal and third-party external systems. The KPI validation engine module 122 may further include a proof submission by employees module 124 which is configured to handledocuments submitted by employees as evidence against custom goal / key performance objective (KPO) during a validation phase. The KPI validation engine module 122 may also include a proof validation by validators (manual or automatic) module 125 which is configured to verify or validate uploaded documents uploaded through the proof submission by employees module 124. The module 122 may include a multi-signature (multisig) approval module 126 which is configured to handle a workflow that occurs to get approvals from other multi-party contract stakeholders.

[0059] Referring now to the integration service module 127, this module 127 may also comprise an LDAP / Active Directory module 128. The “LDAP,” which stands for Lightweight Directory Access Protocol, may be a protocol used for accessing and managing directory information over an Internet Protocol (IP) network. The "Active Directory" may be a type of directory service developed by Microsoft that uses LDAP as the basis for its protocol.

[0060] The Active Directory may typically include information such as an organization's employee names, phone numbers, roles, and email addresses. The LDAP / Active Directory module 128 in the system 100 may be used to read or modify this information and to authenticate employees, making it an essential component for managing user access and permissions within the system 100.

[0061] The system 100 may interact with the LDAP / Active Directory module 128 in several ways. For example, the information from Active Directory may be used by other modules to assign roles, verify user identities, and manage access rights. This integration may enable a seamless flow of user data across the system 100, enhancing security and efficiency.

[0062] In addition, the blockchain-based KPI management system 100 may leverage Active Directory and LDAP systems to bring organization employees onto the blockchain system. This not only streamlines the process of user onboarding but also ensures that user data in the system 100 is accurate and up-to-date, reflecting any changes made in the Active Directory.

[0063] In other embodiments, a company performance indicator engine module 129 may also be included in the integration service module 127, which may be integrated with the blockchain-based KPI management system 100 to provide input to the token value generation engine 109. The performance indicator engine module 129 may refer to all existing systems that an organization may use to measure and validate growth and performance. The company performance indicator engine module 129’s data may be used to calculate final value of the token after transfer and / or disbursement to the employee’s wallet or account.

[0064] In other embodiments, the integration service module 127 may also include other internal / external systems 130 where external third party systems may refer to any or all systems which may be required to validate KPIs for employees. For example, the external third party systems like credly.com may be needed to validate the licensing information against any certificate that an employee has done or is claiming. Employees may share a credly.com -generated link as evidence of certificate KPI / goal they achieved.

[0065] Referring now to the pool management module 131, in some embodiments, this module 131 may be configured to provide several service functions, including the creation of manager pool 132 and validator pool 133 in other embodiments. These pools may represent groups of users within the system 100 who are assigned specific roles and responsibilities.

[0066] The creation of manager pool 132 function may be responsible for forming a collection of managers from the list of all available managers in an organization. These managers may then be assigned roles, such as the pool manager role. As pool managers, they may hold the prerogative right to define custom KPIs or goals for employees. The managers may utilize the master KPI templates, created by the master KPI creation module 119, to form these custom KPIs, ensuring alignment with the company's overarching objectives.

[0067] The creation of validator pool 133 may be responsible for establishing a group of validators. These validators may be assigned the task of verifying the evidence provided by employees in support of their KPI or goal fulfillment. This role may be integral to the employee goals life cycle contract module 117, where the validators may ensure the validity of evidence submitted for goal achievement.

[0068] The pool managers, as part of their responsibilities under the manager pool 132 function, may select validators from the validator pool 133 and associate them with each custom KPI or goal. This association may establish a clear line of responsibility for the validation process. The validators may be charged with evaluating the evidence provided by employees, determining whether the KPI or goal has been met, and endorsing the KPI or goal as part of a multi-signature approval process facilitated by the multi-signature contract module 116.

[0069] FIG. 2 presents a diagram illustrating a management system 200 including all system roles and their interactions with services within the blockchain-based KPI management system 100 of FIG. 1. The management system 200 may include: a role module 201, which may encompass different roles including all managers, users, and administrators of the blockchain-based KPI management system 100; and a service module 208, which mayrepresent the functional elements of the blockchain-based KPI management system 100 that the roles in the role module 201 interact with.

[0070] In one embodiment, the roles of the role module 201 may include a smart contract manager 202 who acts as an administrator of the system 100 with the authority to deploy and extend smart contracts. For instance, the smart contract manager 202 may deploy or extend contracts when the system 100 requires additional functionalities or when business rules change. The smart contract manager 202 may be created at the genesis of a blockchain network, and its public / private encryption keys may be securely stored in a database or cloud vault. A wallet may or may not be associated with the smart contract manager 202 role. After the blockchain network genesis, the smart contract manager 202 may deploy the smart contracts to the blockchain network and further extend (adding more functions) the contract if needed.

[0071] In other embodiments, the roles of the role module 201 may also include a fund manager 203, who is granted management rights by the fund management module 102. The fund manager 203 may handle token management services for the system 100, including the minting of tokens (in line with ERC20 standards) using the minting module (105, FIG. 1) of the blockchain-based token framework module 104. The fund manager 203 may oversee the creation of tokens against available funds allocated to a central pool during the minting process, which may be visualized as the fund manager 203's wallet balance. The fund manager 203 may also manage other aspects such as the token transfer process of the transfer module (106, FIG. 1), the redemption process of the redeem module (107, FIG. 1), and the burning process of the burn module (108, FIG. 1).

[0072] Additionally, the roles of the role module 201 may include a company admin 204, responsible for the allocation and distribution / disbursement of token and the creation, activation, and retirement of KPI lifecycle module (118, FIG. 2). The company admin 204 may also participate in the workflow of the multi-signature approval module (126, FIG. 1) to approve the disbursement of tokens.

[0073] The roles of the role module 201 may further include a pool manager 205 who maps KPIs to system participants, such as employees 206, with validation rules 123 and participates in the workflow of the multi-signature approval process of the multi-signature approval module (126, FIG. 1) to approve the disbursement of tokens. The employees 206, also included in the roles of the role module 201, may accumulate coins based on KPI awards, provide evidence through the proof submission by employees module (124, FIG. 1) of KPI achievements, and redeem tokens through the redeem module (107, FIG. 1).Validators 207, another category within the roles of the role module 201, may validate rules or proof validation by the validators 207 through the proof validation by validators module (125, FIG. 1) using the KPI validation engine module 122 for custom KPIs / goals based on evidence or proof submission by the employees 124.

[0074] The services module 208 may include: the smart contract module 111 facilitating deployment and extension services by the smart contract manager 202; the fund management module 102 and token framework module 104 facilitating fund-to-token conversion calculation (103, FIG. 1), token minting (105, FIG. 1), transfer (106, FIG. 1), and burning (108, FIG. 1) module services respectively to the fund manager 203; the token framework module 104 and smart contract module 111 facilitating services of token allocation and disbursement, by the master KPI creation (119, FIG. 1) and goal validation (125, FIG. 1) to the company admin 204 respectively; the smart contract module 111 which facilitates services of master KPI mapping to employee goals, goal assignment to employees, and goal validation (126, FIG. 1) for the pool manager 205; the smart contract module 111 and token framework module 104 which facilitate services of goals acceptance, proof submission (124, FIG. 1), and token redemption (107, FIG. 1) for the employee 206; and the smart contract module 111 which facilitates a service of goal validation 125 for the validator 207

[0075] In some embodiments, the pool managers 205 may be equipped with the ability to map out a KPI timeline (for example, defining a quarter of a year such as April to June), token count, and KPI criteria (such as KPI types, including weightage and distribution rules) to create new goals, such as custom KPIs / goals using the custom KPI / goal creation module 120. In the process of creating custom KPIs or goals for employees, the pool manager 205 may set specific parameters.

[0076] In some embodiments, specific parameters may include a KPI timeline, which outlines the goal completion quarter for an employee during the current KPI cycle. For instance, this KPI timeline may be a specific quarter of the year, such as April to June or July to September. A second parameter may include a token count. The pool manager 205 may determine the token count associated with each goal. The number of tokens that employees receive may be proportional to their goal achievement, or their achievement in the KPIs. For example, if they achieve the goal 100%, they earn an equivalent number of tokens as mentioned in the token count field. Another parameter may further include KPI criteria. This may allow the pool manager 205 to establish multiple criteria for a single goal, providing each company the flexibility to define their own custom criteria. For example, the poolmanager 205 may specify whether a KPI is for an individual or for a group of employees. The pool manager 205 may also categorize the goal with examples of categories such as code review, certifications, team velocity, performance, etc. Additionally, distribution rules or weights may be defined as part of the criteria for token allocation. For instance, if an employee has achieved 100% of the goal, all assigned tokens (as defined in the token count) may be disbursed. Conversely, if the goal is 50% achieved, then 50% of all allocated tokens may be disbursed. This nuanced approach may ensure that the allocation of tokens accurately reflects an employee's performance.

[0077] To create custom KPIs / goals for the employees 206, the pool manager 205 may set specific details such as the KPI timeline, which may include a set goal completion quarter for employees of current KPI cycles, the token count which determines the total tokens assigned with a custom goal, and the KPI criteria which sets the criteria for token allocation. For example, if an employee has achieved 100% of his goals, all assigned tokens may be disbursed, while if 50% of set goals are achieved, 50% of all allocated tokens may be disbursed.

[0078] For instance, during the KPI / goal validation process, there may be a need to establish a time-locked / escrowed multi-signature contract, which may be created by the multi-signature contract module (116, FIG. 1), among the company admin 204, pool manager 205, validator 207, and employee 206. These multi-sig contracts created on the module (116, FIG. 1) may follow an approval process to be settled. If the employee 206 can provide a proof of KPI fulfillment within the stipulated time frame, and the multi-signature approvers have approved it through the multi-signature approval module 126, then the token may be disbursed to the employee 206's account. In the event the employee 206 cannot provide a proof of KPI fulfillment, the multi-signature contract on the module (116, FIG. 1) may be returned to the central fund pool.

[0079] The proof of KPI fulfillment may refer to the evidence / proofs provided by the employee 206 against the KPI they are claiming to have achieved. For example, if an employee 206 is claiming to have achieved the "Blockchain Certification" goal, they may need to provide the certification license information as evidence. They may also provide URLs from third-party Digital Credential Services, such as credly.com as part of their evidence.

[0080] In one embodiment, the process of minting on the minting module (105, FIG. 1) by the fund manager 203 may occur during a fund top-up to the central fund pool if required.

[0081] An instance when a token may be burned on the bum module (108, FIG. 1) may occur when the KPI management system 100 permits the redemption on the redeem module (107, FIG. 1) of funds to the employee 206 against the tokens they possess. Another scenario could arise when a token is set to no longer be distributed in the KPI lifecycle module (118, FIG. 1). These processes may exemplify the dynamic nature of token management within the system 100, maintaining a delicate balance between token creation and destruction.

[0082] FIG. 3 illustrates an intemal / extemal integration service system 300A of the blockchain-based KPI management system 100 shown in FIG. 1, according to one embodiment. The internal / external integration service system 300A may include an integration service in FIG.1. Referring to FIG. 3, the internal / external integration service system 300 A may integrate with blockchain systems within the blockchain-based KPI management systems 100, according to one embodiment. The system 300 A may demonstrate how contracts may be created, the parties or roles involved, and the security features of system 100. For instance, during an onboarding event where an employee's information is incorporated into the system 100, the digital onboarding of company employees from the LDAP / Active directory module 128 to the blockchain-based systems 100 may occur in a structured manner, utilizing decentralized identity. An example of decentralized identity may be an Ethereum blockchain address. In this context, the system 100 may generate an employee's identity based on Ethereum address standards.

[0083] The blockchain-based KPI management system 100 may generates a pair of public identity 302 and private key 301 for each onboarded employee (206, FIG. 2). Each employee’s identity 302 is associated with the non-custodial wallet 304. The signed private keys 301 for accessing and managing the non-custodial wallet (304) may be encrypted and stored securely in a database or a vault 303, which in some embodiments may be a cloud storage solution.

[0084] The blockchain-based KPI management system 100 may create the noncustodial wallet 304 for each onboarded employee (206, FIG. 2). This approach may empower the employees (206, FIG. 2) by allowing them to maintain their tokens in their private non-custodial wallets 304. It may also enable them to transfer their tokens to colleagues, or other employees (206, FIG. 2), if they wish to do so, thereby promoting an environment of peer recognition and collaborative achievement within the organization.

[0085] In one embodiment, the employee onboarding may be done using a bulk upload feature with the system 100. During the bulk upload process, theorganizations / company’s active directory may mainly consist of the employee’s name, phone number, roles, and email where that information may be bulk uploaded to the blockchain systems 100 to generate the decentralized identity of each employee (206, FIG. 2).

[0086] The system 300 A further illustrates how the smart contract manager 202 was created at the time of the genesis of a blockchain network 300. The public key, or identity, 302 and the signed private key 301 of the smart contract manager 202 may be securely stored in the database or vault 303. It's noteworthy that in some embodiments, the non-custodial wallets 304 may or may not be associated with the smart contract manager 202 role.

[0087] The process illustrated in the integration service system 300A may also involve the integration of the company performance indicator engine 129 with the blockchain-based KPI management system 100. This integration may provide input to the token value generation engine module 109. Input parameters may include data related to company performance, the performance of the business unit to which the employee belongs, and the employee's performance for that year. Using these inputs, the token value generation engine module 109 may execute the business formula to calculate the real value of the token.

[0088] Moreover, the third-party external or internal credential systems 130 may integrate with the blockchain-based KPI management system 100 in another embodiment. This integration of the third-party external credential systems and internal credential systems may provide input to the KPI validation engine module 122 to verify proofs submitted by the employees (124, FIG. 2) against their KPIs. For example, the third-party credential systems may include external systems such as Credly, AWS, Google, and others. Internal credential systems may also provide data to validate the claimed KPI results, thus ensuring a robust and reliable validation process.

[0089] FIG. 4 illustrates a private permissioned consortium blockchain network 400 of the blockchain-based KPI management system 100 shown in FIG. 1, according to one embodiment. The components of the private permissioned consortium blockchain network 400 may include Hyperledger Besu 300 and web and mobile-based decentralized application constructs 401, 404.

[0090] The Hyperledger Besu 300 may be a blockchain network developed for private, permissioned consortiums. It may be an open-source blockchain project from the Hyperledger Foundation. This private, permissioned blockchain network may be used in the presented embodiment, but other private, permissioned consortium open-source or proprietary blockchain frameworks such as Hyperledger Fabric may also be used. In thisdocument, the terms "Blockchain Network", "Hyperledger Besu", and "Blockchain Besu" may be used interchangeably to refer to the Hyperledger Besu 300.

[0091] The decentralized application constructs 401, 404 may be a combination of modules 401 and 404. The module 401, referred to as the Decentralized Application Interface, and the module 404, referred to as the Decentralized Application Middleware, may provide a method for users to interact with the blockchain-based KPI management system (100, FIG. 1).

[0092] The module 401, the Decentralized Application Interface, may include a web and mobile-based decentralized client interface 402 and a non-custodial wallet 304.Meanwhile, the module 404, the Decentralized Application Middleware, may have two main functions. The first function may be a NodeJS-based Web3 JS and / or EEA client libraries405, which performs the function that allows the web and mobile-based decentralized client interface 402 to perform function calls 416 on the blockchain network of the Hyperledger Besu 300 over the JSON RPC protocol 417. The second function may be a program logic406, which performs the function that allows the web and mobile-based decentralized client interface 402 to save or fetch blockchain metadata from PostgreSQL relational databases 407 through simple HTTP(s) based rational DB calls 418. This setup may ensure robust and efficient interaction between the users and the KPI management system (100, FIG. 1).

[0093] In one embodiment, as depicted in FIG. 4, the blockchain-based KPI management system (100, FIG. 1) may be developed with web and / or mobile-based decentralized client interfaces 402. These interfaces 402 may perform the function calls 416 to the blockchain network of the Hyperledger Besu 300 over the JSON RPC protocol 417 through the NodeJS-based Web3 JS and / or EEA client libraries 405. Through this web and mobile-based decentralized client interface 402, employees, for instance, may execute actions related to their non-custodial wallet 304 to retrieve or modify information concerning owned tokens.

[0094] In some scenarios, the third-party non-custodial wallets 304 may also interact with the blockchain network Hyperledger Besu 300 over the JSON RPC 417 protocol through NodeJS-based web3 JS and / or EEA client libraries 405. These interactions may facilitate transactions not related to the web and mobile-based decentralized client interface 402, such as revocation or burning of tokens.

[0095] Moreover, in other embodiments, the program logic 406 may interact with a PostgreSQL relational database 407 after the function call 416. This interaction enables theretrieval or storage of information, thus adding another layer of versatility and data management to the blockchain-based KPI management system 100.

[0096] The JSON RPC calls 417, in some embodiments, may be used on EVM-based blockchain networks to define different data structures and the rules on how data structures are processed in the network. As it is transport-agnostic, it may also be used to interact with EVM-based nodes over sockets or HTTP. Some metadata of blockchain-based transactions may be saved in PostgreSQL relational databases 407 using the program logic 406 and may be fetched by the web and mobile-based decentralized client interfaces 402 through simple HTTP(s) based rational DB calls 418.

[0097] As this solution is using private permissioned consortium blockchain which may be behind the firewall of the company network, relational databases may be used to send employees (206, FIG. 2) blockchain private keys (301, FIG. 3) to safeguard it. The presented embodiments may follow web 3.0 guidelines and allow employees to use the non-custodial wallets 304 and provide full rights to them to safeguard their private key (301, FIG. 3) with themselves.

[0098] Conceptualization of the blockchain-based KPI management systems 100 may be done within the scope of a company (organization) and blockchain network infrastructure which lies behind the company firewall. In some embodiments, this approach may include having a private single party led permissioned consortium network protected behind a firewall. Blockchain networks may be developed using any private permissioned consortium open source or proprietary blockchain framework such as Hyperledger Fabric, Hyperledger BESU 300, for example.

[0099] In some embodiments, the blockchain-based KPI management systems 100 may include a private permissioned consortium blockchain network 400 and use a reputationbased consensus algorithm such as IBFT2.0 Proof of Authority consensus protocol (POA) or Istanbul Byzantine Fault Tolerant, (IBFT(Proof of Authority) 415, where the pre-approved and limited number of validators may stake their reputation to make the network secure and trust-less. The choice of validators may be the prerogative of the company and may include company decision makers, administrators, HR, Managers, etc.

[0100] In some embodiments, the private permissioned consortium blockchain network 400 may use a private single party led permissioned consortium blockchain network, the Hyperledger Besu 300, with a plurality of validator nodes 409, 412, 413 and 414. Also, some embodiments may be developed with Ethereum virtual machine based open source Hyperledger Besu blockchain framework.

[0101] As illustrated, some embodiments of Hyperledger besu 300 may include the peers / boot and validator nodes 409, 412, 413 and 414 which may participate in the consensus protocol (POA / IBFT) 415. Each of Node 1, Node 2, Node 3, and Node 4 of the peers / boot and validator nodes 409, 412, 413 and 414 may include a distributed ledger 410 and distributed smart contract 411, respectively. The boot and validator nodes 409, 412, 413, and 414 may be responsible for the generation of new blocks. The boot and validator nodes 409, 412, 413, and 414 may only be connected to each other and to boot nodes for security and efficiency purposes. The validator nodes 409, 412, 413, and 414 may also apply the POA (IBFT2.0) 415 consensus protocol to validate the transaction, including the submitted proof from an employee, and incorporate it into a new block. The node 409 in the Blockchain network of the Hyperledger Besu 300 may also be a boot node, responsible for initially discovering the peer nodes 412, 413 and 414. The blockchain network of the Hyperledger Besu 300 may be running POA(IBFT2.0)415 consensus to get immediate finality.

[0102] FIG. 5 depicts a workflow 500 post genesis of a Blockchain network of Hyperledger Besu (300, FIG. 4). Referring to FIG. 5, the workflow 500 shows a diagram to illustrate all prominent workflows of a blockchain-based KPI management system 100 shown in FIG. 1, according to one embodiment. The workflow 500 illustrates how various components within the system 100 may interact with user roles. Each role has been designated a level (depicted on the left of workflow 500 diagram) to assist in understanding which role is responsible for which component of workflow 500.

[0103] The workflow 500 may include at a first level of the diagram, a smart contract manager 202 who may deploy all the smart contracts (111, FIG. 1) within the system (100, FIG. 1).

[0104] Subsequently, at a second level, a fund manager 203 may be at the start 502 of a process where the fund management module 102 determines how much percentage of a fund needs to be minted (step 504). After this step, the fund manager 203 may mint tokens as much as the determined percentage of the fund that needs to be minted through the minting module 105 and then determine a percentage of the minted tokens that may need to be allocated throughout the system (100, FIG. 1) (step 506). At the minting step using the minting module 105, the KPI life cycle using the KPI life cycle module (118, FIG. 1) may start where the minting step is performed against funds provided to the central fund pool for a particular KPI cycle. In some embodiments, the initial value of tokens may vary and may be directly proportional to the fund value available in the central fund pool.

[0105] At the second level, the fund manager 203 is also illustrated in the workflow 500 as being responsible for the burning of tokens using the bum module (108, FIG. 1). In some embodiments, the determination process in the steps 504 and / or 506 may include parameters such as the current inflation rate of the deposited currency.

[0106] Upon the determination of a percentage of a deposited fund, minted tokens, to be allocated (step 506), a company admin 204, at a third level, may transfer the recently minted tokens, which are minted on the minting module 105, to a company admin wallet using the transfer module 106, and the transferred tokens may be received in the company admin wallet (step 508). The KPI life cycle using the KPI life cycle module (118, FIG. 1) may start with the minting step of tokens on the minting module 105, by the fund manager 203 against funds provided to the central fund pool for a particular KPI cycle. In some embodiments, a KPI cycle may occur every year which is determined by the company admin 204.

[0107] As depicted at the second level of workflow 500, the fund manager 203 may decide the percentage to apply to the allotted funds which have to be converted or minted to tokens in the step 506. The fund manager 203 may further determine, out of the minted tokens, the percentage of minted tokens that will be distributed for a particular KPI cycle. In some embodiments, the initial value of the tokens may vary and may be directly proportional to the fund value available in the central fund pool. Subsequently, the fund manager 203 will then transfer the allocated tokens for the KPI cycle to the company admin 204’s wallet (304, FIG. 3) using the transfer module 106 in the step 508.

[0108] Referring to the third level of workflow 500, after the step 508, the company admin 204 may then ready the tokens for disbursement.

[0109] Also depicted at the third level, the company admin 204 may be responsible for the creation of master KPIs and a master KPIs library using the master KPI creation module 119 to reuse for every KPI cycle. At a next step, the company admin 204 may also decide all possible KPIs needed for the company (step 510).

[0110] In some embodiments, the company admin 204 may further be responsible for creating a manager pool 132, providing permissions to users, such as a pool manager 205 at a fourth level, for pool management functions, such as having the right to leverage the master KPIs for the creation of custom KPIs (Goals) which are assigned to employees 206 at a fifth level. The custom KPIs (Goals) may be created by the custom KPI / goal creation module 120.

[0111] In another embodiment, the company admin 204 may further create a pool of validators 133 where one validator may be mapped to one custom KPI created by the custom KPI / goal creation module 120 and lastly determine all possible KPIs needed for the company.

[0112] Continuing to the fourth level of the workflow 500, the pool manager 205 may be responsible for the manager pool 132 and map the KPIs to employee goals in a mapping module using the KPI mapping to employee goals contract module 115, which includes the determined KPIs needed for the company by the company admin 204. In one embodiment, the pool manager 205 may create custom KPI Goals using the custom KPI / goal creation module 120) to map and assign rules to a single employee 206 at the fifth level using the validation rule engine module 123.

[0113] In the fifth level, the employee 206 may have access to the created custom KPIs which were defined by the pool manager 205 for a particular quarter of year, for example. The employee 206 may also have access to validation of the assigned rules from the validation rule engine module 123 and the number of tokens that the employee 206 may receive related to the achievement of a particular goal based on distribution rules set by the pool manager 205.

[0114] In one embodiment, the employee 206 may then choose a custom KPI to accept by signing it with a private key (301, FIG. 3) (step 512). At this point of time, through the multi-signature contract module 116, a multisig contract may become established and time-locked / escrowed among the company admin 204, pool manager 205, validator 207 and employee 206. The employee 206 may then upload valid proofs through the employee module 124 as evidence against each custom goal / KPI during the validation phase using the KPI validation engine module (122, FIG. 1).

[0115] In another embodiment, the employee 206 may also receive tokens disbursed by the company admin 204 at the third level (step 509), where redemption of tokens of the non-custodial wallet 304 may be redeemed through the redeem module 107 by the company admin 204 and further burned through the burn module 108 by the fund manager 203 at the first level.

[0116] In other embodiments, after the token transfer to the non-custodial wallet 304 of the employee 206 through the transfer module 106, the fund manager 203 may burn tokens on the burn module 108. If an employee 206 cannot provide a proof of KPI fulfilment on the employee module 124 within the stipulated time frame, or the multi-party approvers has not approved it, or in any other failure conditions, on the multi-signature approval module 126, the token may be returned back to the central fund pool.

[0117] In some embodiments, the employee 206 may have a right to request to the company admin 204 for redemption of their tokens to be converted to a relevant currency where redemption may include a company reimbursing an employee.

[0118] For example, on occasion an employee 206 may leave a company, where at that time of redemption, the token value calculation engine module (110, FIG. 1) may be executed to identify a current market monitory value of tokens that needs to be redeemed.

[0119] At the sixth level, in the step 514, a validator 207 from a validator pool may validate evidence or proofs through the proof validation by validators module 125 by an assigned validator 207, or by a mapped validator from the custom KPI / goal creation module 120, either manually or automatically. In some embodiments, for automatic validation, a validation rule engine module (123, FIG. 1) may leverage the integration service module (127, FIG. 1) to connect and fetch validation results from company internal and third-party external systems.

[0120] If a validation passes (step 516) and after approval of custom goals from assigned validators (207, FIG. 2) within the KPI validation engine module 122, a multisig workflow will occur on the multi-signature approval module 126 to get approvals from the other multi-party contract (116, FIG. 1) stakeholders, company admin 204, pool manager 205 and validator 207, on the multi-signature contract module. Upon approval, the token may be disbursed (step 509), a value may be calculated through the token value calculation engine module (110, FIG. 1), and the token may be released to the employee 206’s non-custodial wallet 304. If a validation does not pass, tokens may not be assigned to the employee 206 (step 518).

[0121] In some embodiments, the token value calculation may use various parameters to calculate the token price where individual companies may define their own custom formulae. In some embodiments the token value may be determined based on factors which may include the initial value of a token where for example a formula may include:

[0122] Token Value = (dollar value assigned while minting) (+) (company performance, business unit performance, and employee performance for that year).

[0123] This information may be gathered from the company performance indicator engine module (129, FIG. 1) and other internal systems through the integration service module (127, FIG. 1). Quantification of this data to monitory value may be the prerogative of the company. Tokens may be burned through the burn module (108, FIG. 1) and removed from the central fund pool permanently and the blockchain ledger may also be updated.

[0124] FIG. 6 is a high-level block diagram 1100 showing a computing system comprising a computer system useful for implementing an embodiment of the system and process, disclosed herein. Embodiments of the system may be implemented in different computing environments. The computer system includes one or more processors 1102, and can further include an electronic display device 1104 (e.g., for displaying graphics, text, and other data), a main memory 1106 (e.g., random access memory (RAM)), storage device 1108, a removable storage device 1110 (e.g., removable storage drive, a removable memory module, a magnetic tape drive, an optical disk drive, a computer readable medium having stored therein computer software and / or data), user interface device 1111 (e.g., keyboard, touch screen, keypad, pointing device), and a communications interface 1112 (e.g., modem, a network interface (such as an Ethernet card), a communications port, or a PCMCIA slot and card). The communications interface 1112 allows software and data to be transferred between the computer system and external devices. The system further includes a communications infrastructure 1114 (e.g., a communications bus, cross-over bar, or network) to which the aforementioned devices / modules are connected as shown.

[0125] Information transferred via communications interface 1112 may be in the form of signals such as electronic, electromagnetic, optical, or other signals capable of being received by communications interface 1112, via a communication link 1116 that carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular / mobile phone link, a radio frequency (RF) link, and / or other communication channels. Computer program instructions representing the block diagram and / or flowcharts herein may be loaded onto a computer, programmable data processing apparatus, or processing devices to cause a series of operations performed thereon to produce a computer implemented process.

[0126] Embodiments have been described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments. Each block of such illustrations / diagrams, or combinations thereof, can be implemented by computer program instructions. The computer program instructions when provided to a processor produce a machine, such that the instructions, which execute via the processor, create means for implementing the functions / operations specified in the flowchart and / or block diagram. Each block in the flowchart / block diagrams may represent a hardware and / or software module or logic, implementing embodiments. In alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures, concurrently, etc.

[0127] Computer programs (i.e., computer control logic) are stored in main memory and / or secondary memory. Computer programs may also be received via a communications interface 1112. Such computer programs, when executed, enable the computer system to perform the features of the embodiments as discussed herein. In particular, the computer programs, when executed, enable the processor and / or multi-core processor to perform the features of the computer system. Such computer programs represent controllers of the computer system.

[0128] FIG. 7 shows a block diagram of an example system 1200 in which an embodiment may be implemented. The system 1200 includes one or more client devices 1201 such as consumer electronics devices, connected to one or more server computing systems 1230. A server 1230 includes a bus 1202 or other communication mechanism for communicating information, and a processor (CPU) 1204 coupled with the bus 1202 for processing information. The server 1230 also includes a main memory 1206, such as a random-access memory (RAM) or other dynamic storage device, coupled to the bus 1202 for storing information and instructions to be executed by the processor 1204. The main memory 1206 also may be used for storing temporary variables or other intermediate information during execution or instructions to be executed by the processor 1204. The server computer system 1230 further includes a read only memory (ROM) 1208 or other static storage device coupled to the bus 1202 for storing static information and instructions for the processor 1204. A storage device 1210, such as a magnetic disk or optical disk, is provided and coupled to the bus 1202 for storing information and instructions. The bus 1202 may contain, for example, thirty-two address lines for addressing video memory or main memory 1206. The bus 1202 can also include, for example, a 32-bit data bus for transferring data between and among the components, such as the CPU 1204, the main memory 1206, video memory and the storage 1210. Alternatively, multiplex data / address lines may be used instead of separate data and address lines.

[0129] The server 1230 may be coupled via the bus 1202 to a display 1212 for displaying information to a computer user. An input device 1214, including alphanumeric and other keys, is coupled to the bus 1202 for communicating information and command selections to the processor 1204. Another type or user input device comprises cursor control 1216, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to the processor 1204 and for controlling cursor movement on the display 1212.

[0130] According to one embodiment, the functions are performed by the processor 1204 executing one or more sequences of one or more instructions contained in the main memory 1206. Such instructions may be read into the main memory 1206 from another computer-readable medium, such as the storage device 1210. Execution of the sequences of instructions contained in the main memory 1206 causes the processor 1204 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in the main memory 1206. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the embodiments. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

[0131] The terms "computer program medium," "computer usable medium," "computer readable medium", and "computer program product," are used to generally refer to media such as main memory, secondary memory, removable storage drive, a hard disk installed in hard disk drive, and signals. These computer program products are means for providing software to the computer system. The computer readable medium allows the computer system to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium. The computer readable medium, for example, may include non-volatile memory, such as a floppy disk, ROM, flash memory, disk drive memory, a CD-ROM, and other permanent storage. It is useful, for example, for transporting information, such as data and computer instructions, between computer systems. Furthermore, the computer readable medium may comprise computer readable information in a transitory state medium such as a network link and / or a network interface, including a wired network or a wireless network that allow a computer to read such computer readable information. Computer programs (also called computer control logic) are stored in main memory and / or secondary memory. Computer programs may also be received via a communications interface. Such computer programs, when executed, enable the computer system to perform the features of the embodiments as discussed herein. In particular, the computer programs, when executed, enable the processor’s multi-core processor to perform the features of the computer system. Accordingly, such computer programs represent controllers of the computer system.

[0132] Generally, the term "computer-readable medium" as used herein refers to any medium that participated in providing instructions to the processor 1204 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical ormagnetic disks, such as the storage device 1210. Volatile media includes dynamic memory, such as the main memory 1206. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise the bus 1202. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0133] Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

[0134] Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to the processor 1204 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the server 1230 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to the bus 1202 can receive the data carried in the infrared signal and place the data on the bus 1202. The bus 1202 carries the data to the main memory 1206, from which the processor 1204 retrieves and executes the instructions. The instructions received from the main memory 1206 may optionally be stored on the storage device 1210 either before or after execution by the processor 1204.

[0135] The server 1230 also includes a communication interface 1218 coupled to the bus 1202. The communication interface 1218 provides a two-way data communication coupling to a network link 1220 that is connected to the world wide packet data communication network now commonly referred to as the Internet 1228. The Internet 1228 uses electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 1220 and through the communication interface 1218, which carry the digital data to and from the server 1230, are exemplary forms or carrier waves transporting the information.

[0136] In another embodiment of the server 1230, the communication interface 1218 is connected to a network 1222 via a communication link 1220. For example, the communication interface 1218 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephoneline, which can comprise part of the network link 1220. As another example, the communication interface 1218 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface 1218 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

[0137] The network link 1220 typically provides data communication through one or more networks to other data devices. For example, the network link 1220 may provide a connection through the local network 1222 to a host computer 1224 or to data equipment operated by an Internet Service Provider (ISP). The ISP in turn provides data communication services through the Internet 1228. The local network 1222 and the Internet 1228 both use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 1220 and through the communication interface 1218, which carry the digital data to and from the server 1230, are exemplary forms or carrier waves transporting the information.

[0138] The server 1230 can send / receive messages and data, including e-mail, and program code through the network via the network link 1220 and the communication interface 1218. Further, the communication interface 1218 may comprise a USB / Tuner and the network link 1220 may be an antenna or cable for connecting the server 1230 to a cable provider, satellite provider or other terrestrial transmission system for receiving messages, data and program code from another source.

[0139] The example versions of the embodiments described herein may be implemented as logical operations in a distributed processing system, such as the system 1200 including the servers 1230. The logical operations of the embodiments may be implemented as a sequence of steps executing in the server 1230, and as interconnected machine modules within the system 1200. The implementation is a matter of choice and can depend on performance of the system 1200 implementing the embodiments. As such, the logical operations constituting said example versions of the embodiments are referred to, for example, as operations, steps or modules.

[0140] Similar to a server 1230 described above, a client device 1201 may include a processor, memory, storage device, display, input device and communication interface (e.g., e-mail interface) for connecting the client device to the Internet 1228, the ISP, or LAN 1222, for communication with the servers 1230.

[0141] The system 1200 may further include computers (e.g., personal computers, computing nodes) 1205 operating in the same manner as client devices 1201, wherein a user can utilize one or more computers 1205 to manage data in the server 1230.

[0142] Referring now to FIG. 8, illustrative cloud computing environment 50 is depicted. As shown, cloud computing environment 50 comprises one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA), smartphone, smart watch, set-top box, video game system, tablet, mobile computing device, or cellular telephone 54A, desktop computer 54B, laptop computer 54C, and / or automobile computer system 54N may communicate. The nodes 10 may communicate with one another. The nodes may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment 50 to offer infrastructure, platforms and / or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of computing devices 54A-N shown in FIG. 8 are intended to be illustrative only and that computing nodes 10 and cloud computing environment 50 can communicate with any type of computerized device over any type of network and / or network addressable connection (e.g., using a web browser).

[0143] It is contemplated that various combinations and / or sub-combinations of the specific features and aspects of the above embodiments may be made and still fall within the scope of the invention. Accordingly, it should be understood that various features and aspects of the disclosed embodiments may be combined with or substituted for one another in order to form varying modes of the disclosed invention. Further, it is intended that the scope of the present invention herein disclosed by way of examples should not be limited by the particular disclosed embodiments described above.

Claims

WHAT IS CLAIMED IS:

1. A method, comprising: generating, by a key performance indicator (KPI) creation module (120), one or more key performance indicators (KPIs) corresponding to one or more minted tokens minted through a minting module (105); generating, by a validation rule engine module (123), one or more validation rules for the one or more KPIs; submitting, by a proof submission by employee module (124), a proof of completion of the one or more validation rules; validating, by a proof validation by validator module (125), the submitted proof of completion; and transferring, by a transfer module (106), one or more tokens based on the validated proof.

2. The method of claim 1, wherein the one or more KPIs is one or more KPIs for evaluating employees of an organization, and if the proof submitted by any of the employees is validated, the one or more tokens are automatically transferred and disbursed to a non-custodial wallet of the employee as reward.

3. The method of claim 2, further comprising the step of mapping and assigning, by a KPI lifecycle module (118), the one or more KPIs to each employee of the organization.

4. The system of claim 2, further comprising the step of defining, by a KPI lifecycle module (118), one or more custom KPIs customized to each employee of the organization to tailor performance metrics to different roles of employees of the organization.

5. The method of claim 2, further comprising the steps of: generating a pair of identity and private key for an employee of the organization onboarding onto the system (100); and assigning the non-custodial wallet (304) to the identity (302) for the onboarded employee.

6. The method of claim 2, further comprising the step of recording information of the employee related to the steps of submitting, validating, and transferring on a distributed digital ledger (410) of a blockchain system (300) of the system (100).

7. The method of claim 6, wherein the blockchain network (300) includes a plurality of validator nodes (409, 412, 413, 414), and each of the plurality of validator nodes includes the distributed digital ledger (410) and is configured to participate in a consensus protocol to validate transaction including the submitted proof.

8. The method of claim 2, further comprising the step of receiving approval of multiple parties before the step of transferring, wherein if the proof is not validated within a stipulated time frame or does not receive the approval of multiple parties, the one or more tokens are returned back to a central fund pool of the system (100), wherein if the proof is validated within the stipulated time frame and receives the approval of multiple parties, the one or more tokens is transferred and disbursed to the non-custodial wallet.

9. A system, comprising: a token framework module (104) configured to mint, transfer, redeem, and burn one or more tokens; a key performance indicator (KPI) lifecycle module (118) configured to create one or more master KPIs corresponding to the one or more minted tokens; and a KPI validation engine module (122) configured to define one or more validation rules for the one or more master KPIs and validate a proof of completion of the one or more validation rules, wherein the token framework module (104) is further configured to transfer one or more tokens based on the validated proof.

10. The system of claim 9, wherein the one or more KPIs is one or more KPIs for evaluating employees of an organization, and if the proof submitted by any of the employees is validated, the one or more tokens are automatically transferred and disbursed to a non-custodial wallet of the employee as reward.

11. The system of claim 10, wherein the KPI lifecycle module (118) is further configured to map and assign the one or more master KPIs to each employee of the organization.

12. The system of claim 10, wherein the KPI lifecycle module (118) includes a custom KPI and goal creation module (120) configured to define one or more custom KPIs customized to each employee of the organization to tailor performance metrics to different roles of employees of the organization.

13. The system of claim 10, wherein the KPI validation engine module (122) is configured to validate the submitted proof of completion of the one or more validation rules by multiple validators.

14. The system of claim 10, further comprising a smart contracts module (111) configured to create a smart contract to disburse the one or more tokens, wherein the smart contracts module (111) further includes a multi-signature contract module (116) configured to create a time-locked and escrowed multi-party contract, which requires approval of multiple parties to disburse one or more tokens.

15. The system of claim 14, wherein the KPI validation engine module (122) includes a validation rule engine module (123) configured to leverage an integration service module (127) where at least one of an internal system of the organization and a third-party external system is integrated into the system (100) to connect and fetch a result of validation of the proof, wherein the integration service module (127) includes a Lightweight Directory Access Protocol (LDAP) and active directory module (128) including an LDAP and a directory, wherein information of employees of the organization is included in the directory and is used by any of the modules (104, 111, 118, 122), to authenticate each employee of the organization through the LDAP within the system (100).

16. The system of claim 15, wherein during an onboarding event of an employee of the organization onto the system (100) on the onboarding contract module (113),the information of the employee of the onboarding event from the directory is incorporated into a blockchain network (300) of the system (100).

17. The system of claim 16 wherein the smart contracts module (111) includes an onboarding contract module (113) configured to create a pair of identity (302) and private key (301) for the onboarded employee and assign the non-custodial wallet (304) to the identity (302) for the onboarded employee, wherein the private key (301) for accessing and managing the non-custodial wallet (304) is encrypted, wherein the identity (302) for the onboarded employee is a decentralized identity in the blockchain network (300).

18. The system of claim 16, further comprising a decentralized application interface module (401) and a decentralized application middleware (404), wherein the decentralized application interface module (401) includes the noncustodial wallet (304) and a web and mobile-based decentralized client interface (402) configured to perform function calls (416) to the blockchain network (300) to execute actions related to the non-custodial wallet (304), wherein the decentralized application middleware (404) includes a NodeJS-based Web3 JS and / or EEA client libraries (405) configured to allow the web and mobile-based decentralized client interface (402) to perform function calls (416) on the blockchain network (300) over a JSON RPC protocol (417).

19. The system of claim 16, wherein the blockchain network (300) includes a plurality of validator nodes (409, 412, 413, 414), and each of the plurality of validator nodes includes a distributed digital ledger (410) and a distributed smart contract (411) and is configured to participate in a consensus protocol to validate transaction including the submitted proof.

20. The system of claim 15, wherein the integration service module (127) includes a company performance indicator engine module (129) configured to measure performance data of the organization and provide the data to a token value generation engine module (109) configured to calculate a final value of the one or more tokens transferred to the non-custodial wallet.

Images