EP3942494A1

EP3942494A1 - Computer-aided method for the creation of contracts with employee benefits and exchanging them among users via computer networks, as well as a system of devices designed to implement this method

Info

Publication number: EP3942494A1
Application number: EP19779620.4A
Authority: EP
Inventors: Anna STREZYNSKA; Arkadiusz SZCZEBIOT
Original assignee: Mc2 Innovations Sp Z OO
Current assignee: Mc2 Innovations Sp Z OO
Priority date: 2019-03-21
Filing date: 2019-08-06
Publication date: 2022-01-26
Also published as: PL429326A1; WO2020190156A1

Abstract

Computer-aided method for the creation of contracts with employee benefits and exchanging them among users via computer networks, characterised in that the contracts consist of tokens that are dedicated digital carriers of value and the definition of benefits that can be obtained through the use of tokens, whereas the benefits can be both virtual and real.

Description

Computer-aided method for the creation of contracts with employee benefits and exchanging them among users via computer networks, as well as a system of devices designed to implement this method

The object of the invention is a computer-aided method for the creation of contracts with employee benefits and exchanging them among users, which is carried out via computer networks, as well as a system of devices intended to implement this method.

US7895058B2 discloses a computer-aided method of storing and/or processing of information on benefit provided to an employee under an employment relationship between an employee and the benefit provider established prior to, under, or in the course of the first employment relationship between the employee and the first employer, by means of storage and/or processing information to provide and/or maintain the benefit under or in the course of the second employment relationship between the employee and the second employer, receiving a request for information on the benefits, processing a request for information on the benefits through a processing device, generating a message in response to a request for information on the benefits, and forwarding the message to a communication device assigned to the employee that is the beneficiary, the second employer, and/or an entity that administrates the benefits via the Internet and/or the World Wide Web.

US2016239807 A1 discloses a method of facilitating and monitoring transactions related to the purchase of employer-sponsored benefits and/or incentives. An incentive platform processes and/or facilitates the processing of profile information related to the user of the device to determine the status of the user as an employee of the employer. The incentive platform also determines the status of the employer's request in order to enable the purchase of a benefit, item or a combination thereof from a service provider as an employer-sponsored benefit, as well as the level of user participation or a combination thereof depending on the status of the user. The incentive platform additionally initiates a request for the purchase of a benefit, item or a combination thereof on behalf of a user on the basis of the incentive policy established by the employer, the status of the request, the level of participation or a combination thereof.

US2017161688A1 discloses the method of centralised processing of an employee benefit. The method involves receiving a notification of a deposit into an account with a financial institution and then facilitates the payment from the account to the benefit provider. This method is carried out independently of the employer, even after the termination of the employee's employment by the employer, and even if the employee has a job with a different employer. A system that carries out the method is also available, as well as a storage device that contains instructions to control the processor so as to carry out the method. Centralised processing relieves employer(s) systems from such responsibility, thus reducing redundant efforts and enabling more efficient use of processing resources.

In the solutions known in the prior art there are no such solutions that would provide personalised employee benefits tailored to the needs of specific employees, in particular ones that would offer all of the following functionalities:

• defining personalised employee benefits;

• taking advantage of the market offer of External Partners providing a wide range of standard employee benefits;

• distributing benefits to employees and co-workers by superiors;

• use of benefits by the awarded owners;

• changing the ownership of a benefit or its components (transfer free of charge, exchange, sale);

• acquiring and analysing quantitative and qualitative data on the following: o motivation and loyalty level of personnel, o distribution and use of benefits, o preferences of employees, o impact of benefits on indicators of effectiveness of incentive and loyalty processes;

• providing a range of external value-added services to employers and employees in connection with defining, distributing, and using benefits.

The computer-aided method for the creation of contracts with employee benefits and exchanging them among users, which is carried out via computer networks, is according to the invention characterised in that the contracts comprise the following a) tokens that are dedicated digital carriers of value; b) definition of benefits that can be obtained via tokens that can be both virtual and real. They should represent the value that the Organisation (or an External Partner) can offer to the User; whereas tokens are assigned specific parameters such as the following: a) validity period, i.e. the date range during which the token is active, b) acceptability of exchanging the contract between users, c) acceptability of selling, i.e. acceptability of offering the contract on an external market; d) acceptability of transferring the contract to another user of the method, e) visibility, i.e. the possibility of viewing the balance of user tokens by other users,

f) transparency, i.e. the possibility of viewing the history of transactions related to the token by users, g) durability, i.e. the possibility to keep the token after the cessation of the user's relationship with the organisation that manages the method. In the preferable variant of the invention the price of a given benefit is defined as the number of tokens required to obtain it and/or the conditions necessary to obtain the token by the user are defined.

In the preferable variant of the invention tokens can be distributed among the users of the system at various levels of use of the method: a) administrator b) manager c) user d) external partner

In the preferable variant of the invention, the user has the right to transfer the ownership of the token to another user.

In the preferable variant of the invention, the user who has the ownership right to the token can assign it to another user.

In the preferable variant of the invention, users can exchange their tokens among themselves.

In the preferable variant of the invention, the user can exchange a certain number of tokens for a specific benefit.

In a preferable variant of the invention, for each token a non-modifiable register is kept which includes the following data: a) current ownership status of the token b) dates and parties to previous transactions involving the token.

In the preferable variant of the invention, the participant can track entries in the register kept for a token.

In the preferable variant of the invention, tokens are created on the basis of products or services offered by an external partner.

In the preferable variant of the invention, token templates are used to create tokens. In the preferable variant of the invention, blockchain technology is used.

In another aspect, the object of the invention is the system of devices designed to implement the above method.

The object of the invention is shown as embodiments in figures, in which:

1) fig. 1 presents the logical structure of a token

2) fig. 2 presents the life cycle flowchart of a token

3) fig. 3 presents the flowchart of a circulating model

4) fig. 4 presents the one-time transfer model flowchart

5) fig. 5 presents the permanent model flowchart

6) fig. 6 presents the flowchart of a circulating/burnt external model

7) fig. 7 presents function blocks in a static model

The method and system according to the invention is addressed primarily to large and medium-sized enterprises (with more than 250 employees), but can be used by any organisation regardless of its size. The offered solution satisfies the needs of companies and employers related to the intensifying competition for employees due to the increase in demand for employees, and thus the increase in costs and the simultaneous decrease of employee motivation.

The method and system according to the invention are the first comprehensive tool that applies blockchain technology to Human Resources. The method according to the invention enables the creation of new ecosystems and markets thanks to functionalities such as an internal token exchange market or tools that support the creation of new token templates with regard to technical aspects and legal assistance.

The following modules must be distinguished in the method and system according to the invention:

1. A module that enables the definition and creation of personalised benefits, i.e. tokens

2. A module that enables direct transfer of tokens between users, 3. A module that enables internal exchange market, sale and purchase of tokens,

4. A module that enables employees to indicate their preferences via the benefits they use,

5. A module that supports legal assistance for the token templates created,

6. A module that provides integration with external providers of services i.e. benefits,

7. A module that supports unquestionable and verifiable connection of once granted tokens to the employee's wallet,

8. A module that provides payment for the access to a platform that carries out the method according to the invention (based on a subscription model),

9. A module that makes it possible to obtain and analyse quantitative and qualitative data on the level of motivation and loyalty of the personnel and to present the distribution and level of use of benefits and their impact on the indicators of the effectiveness of incentive and loyalty processes.

A token is a key unit that represents the form of a reward that can be received by one or more employees of an organisation. In other words, a token constitutes a business definition of a single benefit or part of it. Tokens are distributed from a token pool handled within an organisation. Fig. 1 presents the logical structure of a token.

Tokens are characterised by attributes that describe their internal logic. Tokens can also have properties assigned that determine their specific behaviour. The use of both attributes that determine the static structure of a token and its dynamic features enables the creation of a new version of the token.

Tokens are always owned by users. They constitute virtual currency of the ecosystem.

Tokens may have assigned legal documents e.g. specifying the manner of their use and confirming that such use is compliant with regulations applicable at the national, organisational, or ethical level. Legal documentation may be a proof that the applicable legal regulations have been verified with regard to the use of the token by the employer.

A token may have a status that indicates its specific version, e.g.: draft, completed.

Additional logical concepts are connected to tokens. They include, among others, balance and permit balance, which governs their distribution.

Token utilisation types are defined by four main models: (1) permanent, (2) circulating, (3) one-time transfer, (4) external. Token utilisation types are described in detail in Chapter 4. Tokens can also be defined by category tags, which refer to the matching of the token utilisation level for a user.

Tokens can be generated on the basis of token templates that constitute token definition formulas. A template defines basic behaviour classes and is intended to facilitate the introduction of tokens into circulation. Templates can be combined with document templates.

One or more token pools can be generated from a template. The edition features and settings can be used to differentiate pools in various aspects. This means that tokens created in different pools from the same template can both inherit attributes and also modify some of them.

Tokens can be generated by external suppliers (external partners) to incorporate services that can then be purchased by an organisation for the purposes of distributing them among employees. In this aspect, tokens represent a method of payment for a service.

The method according to the invention provides for five main groups of entities: administrator, manager, user, external partner, HR partner.

An administrator manages the system at the technical and business level.

A manager receives tokens from the administrator and assigns them to users in accordance with the established rules or at its own discretion. A manager is at a higher level within the organisational structure than users. A user is an entity that is awarded tokens by a manager and then uses the tokens in various ways (e.g. for its own purposes, gifts tokens to other users, or exchanges them on an internal token exchange market).

An external partner is an entity that provides services/benefits to employees, e.g. health care, sports packages, reimbursement of transport costs. An external partner can create its own tokens, issue them within the ecosystem, and offer them to other organisations.

An HR Partner is a person who represents a company that creates token templates, which are used by administrators in the process of token pool activation.

An administrator plays a key role in the implementation of the following processes:

• creation of a new token,

• activation of token based on a token template,

• granting a manager permissions to distribute tokens,

• revoking a manager's permissions to distribute tokens.

A manager plays a key role in the implementation of the following processes:

• granting rights to distribute tokens to another manager at a lower level within the organisation's structure,

• revoking rights to distribute tokens previously granted to a manager at a lower level within the organisation's structure,

• granting tokens to employees.

A user (employee) plays a key role in the implementation of the following processes:

• utilisation/use of tokens,

• transferring tokens to another user as a gift, • exchanging tokens within an internal token exchange market.

An external partner plays a key role in the implementation of the following processes:

• creation of a new token,

• defining a price list that specifies the number of tokens due for the respective services provided,

• activation of tokens for the purposes of transferring them to an administrator.

An HR partner plays a key role in the implementation of the following processes:

• creation of a new token template,

• defining a token template use price list.

Organisation members (administrator, manager, user) as well as partners (external partner and HR partner) are able to carry out the following: review token details, including token parameters and legal documents attached to the specification of a token, and to view the history of token transactions.

An administrator can create a new pool of tokens or activate it on the basis of a token template available in an organisation's template database (portfolio). An administrator enters the values of token parameters (e.g. token name, logo, total number of tokens to be distributed, expiration date) or accepts the default values of the parameters and the related legal documents. Token parameters determine the behaviour of the token in the system.

An administrator has also the right to grant to managers authorisations to grant further rights to distribute tokens to other managers or to award them to users. It should be noted that the pool of tokens indicated for granting privileges for tokens cannot be empty. After granting authorisations to grant distribution rights, tokens still remain in the organisation's database, but now are reserved and assigned to selected Managers. An administrator can revoke a manager's right to distribute tokens. It should be clarified at this point that if previously granted rights had been partially used by a manager (by means of granting further permissions to another manager or transferring tokens to end recipients, i.e. users), the administrator may only take back the right to distribute the unused part of the tokens. If a right has been used in relation to all tokens, it is not possible to revoke the distribution right.

Similarly to an administrator, a manager can grant and revoke rights to and from another manager. The entity that is the recipient of rights must be at a lower level within the organisation's structure than the granting entity.

The manager can also give tokens to users as rewards. In the course of this procedure, a manager declares the number and type of tokens and the names of the users to be awarded. The transfer is possible only if the number of tokens to be distributed in the token pool is not exceeded.

A user has the right to use tokens present in its individual token wallet. A user may use the tokens for its own purposes, and can enjoy the benefits assigned to the tokens, e.g.: days off. If tokens are transferable, a User may transfer them to another user as a gift or exchange them for other categories of tokens within an internal token exchange market. It should be noted that there may exist non- transferable tokens, e.g. tokens that are a proof of the employee's professional skills.

An external partner can create a new token that represents the type of services provided (e.g. medical tokens, sports tokens, transport tokens). Upon the preparation of token specifications an external partner defines the price list of tokens, which determines the number of tokens required for a given type of service (e.g. 5 tokens for a visit to the dentist). An external partner issues tokens in the system and offers them to organisations for sale.

An HR partner has the right to create a new token template that will be related to the proposed details of an incentive method. Upon the preparation of token template specifications, an HR Partner defines the price of the token template, which determines the monetary value for the given template use by an administrator.

There are four ways of using tokens:

• circulating model,

• one-time transfer model,

• permanent model,

• circulating/burnt external model.

THE CIRCULATING MODEL (fig. 3) involves handing over the tokens by an administrator to a manager, who then distributes them to users (employees) as a reward. The user may use tokens or transfer them to another user (employee) for future use. Before utilising tokens, a user can request the administrator (by providing a comment with the details) for approval. The administrator can accept or reject the use of the token/tokens.

In the presented model tokens can circulate freely in the organisational ecosystem.

Example: the circulating model (a so-called recycling model) is used for tokens that represent additional days off .

THE ONE-TIME TRANSFER MODEL (fig. 4) involves handing over the tokens by an administrator to user, who are able to use them only once. Tokens cannot be transferred more than once, nor exchanged or sold.

Example: the one-time transfer model is used for voting tokens.

THE PERMANENT MODEL (fig. 5) involves handing over the tokens by an administrator to a manager, who then distributes them to selected users (employees) as a reward. As tokens are not transferable, users receive them permanently.

In the presented model, the token represents a reward that is provided to an individual user and remains associated with the user forever.

Example: the permanent model is used for reputation tokens.

THE CIRCULATING/BURNT EXTERNAL MODEL (fig. 6) involves tokens that represent a certain number of service/product units which are distributed by an external partner and can be exchanged in order to obtain the service/product. An external partner issues tokens in the ecosystem and offers them to organisations for activation. Once tokens are activated by the organisation, they are handed over by an administrator to a manager, who then distributes them to users (employees) as a reward. The user may use tokens or transfer them to another employee for future use. A token after any use may be returned to the pool of tokens issued by the external partner or may be burned— the latter will reduce the total number of tokens available for use.

Example: the external model is used for tokens that represent a medical service.

Technical safeguards of the method and system according to the invention are implemented at many levels on the basis of the following assumptions:

• Architecture level: o The platform comprises three independent layers: business logic layer based on microservice architectural pattern, data layer consisting of databases connected with the respective microservices, presentation layer consisting of a front end for end users and a front end for an Organisation Administrator with communication via API portal (see chapter 6). o The communication is carried out only via the required ports and protocols which are used to maintain communication between components of the architecture of the system according to the invention. The application does not use protocols that are considered to be dangerous, e.g. FTP or NFS. o The source code of the application does not contain any confidential information from the business logic layer, nor any secret/private keys nor other confidential data. o The access to data is restricted at the database level, not at the application level. The application does not have any administrative privileges to the database. o Each microservice has its own account, which has only rights to its database and has no database administrator rights. o The access to organisational information is restricted at the application level, not at the database level. o The interface between the application and World Wide Web is protected by a firewall.

• Authentication and authorisation level: o As a default, all participants and all resources on the platform require pre-authentication. o Authentication data fields are not automatically filled in by the application. o All user authentication is executed on the server side. o All failing authentication mechanisms fail safely to ensure that an attacker cannot log into the system. o All authentication operations, such as registration, profile update, login reminder, password reminder that recover access to the account are equipped with at least the same safeguards as the basic authentication mechanisms. o All login attempts are stored without confidential session IDs and passwords. o Passwords to accounts are stored with one-way hashing with cryptographic salt and are sufficiently sophisticated to defend against attacks and recreation of the password from its hash. o Authentication data is transmitted via an encrypted link, and all pages/functions that require the user to provide authentication data require such an encrypted link. o The password recovery mechanism does not disclose the existing passwords, and the new password is not overtly sent to the user. o The application and other components used by the application do not use default passwords (e.g. admin/password). o All authentication data used to access services external to the application is encrypted and stored at a secure location. No such data is stored nor embedded in the source code. o The password recovery function is performed by e-mailing a token with a limited duration. o The application temporarily blocks access after at least 5 incorrect passwords entry attempts. In special cases the administrator can block a user. o Keys and/or other authentication information are not stored in the source code nor in repositories of the Application code. o The administrative interface of the software that implements the method according to the invention is not accessible from non- trusted networks (e.g. from the Internet) or is protected with two- factor authentication methods.

• Session management: o The application does not use custom session managers. Spring is used to provide security instead of a standard session manager. o Sessions are made invalid when the user logs out. o Sessions are automatically deactivated after a specified inactivity period. o Any successful authentication and re-authentication creates a new session. o The platform uses at least 128-bit secure session IDs that are random and unique within the active session database. o As the application is delivered on the basis of a SaaS model there is no need to install any software at the customer's premises. o All potentially hazardous content is removed from the message templates. o The application does not modify any data sent by users via application forms. All attached files are verified (e.g. executable files, e.g. .exe or .msi, are not allowed). However, there are no scans for viruses. o Users can only perform actions defined by their profiles.

The static model comprises three function blocks: (1) front-end applications, (2) back-end Service Mesh, and (3) external services.

Front End Apps

Description: group of applications with user interface. No application has its own back-end layer. The functionality is carried out by front-end (SPA/mobile) that calls API at the central point (API Portal).

Back-end Service Mesh

Description: a network of microservices that executes API calls.

External Services

Description: external SaaS services, run in the CS service call pipeline.

The carried out study on the level of satisfaction of users who tested the method according to the invention revealed that over 80% of the surveyed persons were satisfied with its functioning, the users noted in particular that it improves their motivation in relation to their work tasks, and increases their likelihood to continue working for the organisation (i.e. in the employer's structure). These results are significantly higher compared to other known methods of incentivising employees (even by as much as above 20%).

Claims

Patent claims

1. The computer-aided method for the creation of contracts with employee benefits and exchanging them among users, which is carried out via computer networks, characterised in that the contracts comprise the following: a) tokens that are dedicated digital carriers of value, b) definition of benefits that can be obtained via tokens that can be both virtual and real. They should represent the value that the Organisation (or an External Partner) can offer to the User, whereas tokens are assigned specific parameters such as the following: a) validity period, i.e. the date range during which the token is active; b) acceptability of exchanging the contract between users; c) acceptability of selling, i.e. acceptability of offering the contract on an external market; d) acceptability of transferring the contract to another user of the method; e) visibility, i.e. the possibility of viewing the balance of user tokens by other users; f) transparency, i.e. the possibility of viewing the history of transactions related to the token by users; g) durability, i.e. the possibility to keep the token after the cessation of the user's relationship with the organisation that manages the method.

2. A method according to claim 1, characterised in that the price of a given benefit is defined as the number of tokens required to obtain it and/or the conditions necessary to obtain the token by the user are defined.

3. A method according to claim. 1-2, characterised in that the tokens can be distributed among the users of the system at various levels of use of the method: a) administrator b) manager c) user d) external partner

4. A method according to claim. 1-3, characterised in that the user has the right distribute the right to a token to another user.

5. A method according to claim. 1-4, characterised in that the user who has the ownership right to the token can assign it to another user.

6. A method according to claim. 1-5, characterised in that the users can exchange their tokens among themselves.

7. A method according to claim. 2, characterised in that the user can exchange a certain number of tokens for a specific benefit.

8. A method according to claim. 1-7, characterised in that for each token a non-modifiable register is kept which includes the following data a) current ownership status of the token, b) dates and parties to previous transactions involving the token.

9. A method according to claim. 8, characterised in that the participant can track entries in the register kept for a token.

10. A method according to claim. 1-9, characterised in that tokens are created on the basis of products or services offered by an external partner.

11. A method according to claim. 1, characterised in that token templates are used to create tokens.

12. A method according to claim. 1-11, characterised in that blockchain technology is used.

13. A system of devices designed to implement the method specified in claims 1-12.