WO2021091410A1 - Universal system for distributed secure remote voting - Google Patents

Abstract

The present technical solution as a whole relates to the field of computerized data processing, in particular to remote voting systems. An automated remote voting system comprising: a registration and primary authentication module which carries out registration and primary authentication of a user in a system for gaining access to a biometric authentication module; a biometric authentication module, which carries out biometric authentication of a user, gains access to voting and generates a user profile and user permissions in the system using biometric verification algorithms; an electronic signature module allowing use of an electronic signature by a user in the system and for identifying a user with a network connection to the system; an activity control module, which allows initiation and administration of activity by a user in the system; an activity performance module, which allows the processing and performance of activity initiated by a user; a module for integration with external systems, which interacts with external systems; a module for processing internal requests, which interprets internal requests from system modules to form requests to the module for integration with external systems; an audit module, which monitors user actions in the system and keeps a system log based on recordable information.

Description

UNIVERSAL DISTRIBUTED PROTECTED REMOTE VOTING SYSTEM

FIELD OF TECHNOLOGY

[0001] The present technical solution generally relates to the field of computational data processing, and in particular to distributed secure remote voting systems.

LEVEL OF TECHNOLOGY

[0002] Currently, voting-related activities (elections, meetings of owners, referendums, etc.) impose additional difficulties on the people taking part in them: in person, following additional instructions (for example, sending a mail message of a certain format to specific address, detachment / attachment to the polling station), etc. - as well as additional manual work on organizing, conducting and processing the received data, which is due to legislative regulations, safety requirements and other standards. All this often requires additional knowledge from a citizen of the Russian Federation in order to exercise his right (for example, organizing a general meeting of owners of an apartment building), additional activity (to come to the polling station) and opens up opportunities for fraud (filling out ballots for people who did not participate in the activity). Modern technologies make it possible to implement a system that can mitigate the requirements for a participant in an activity. [0003] Such systems are widely known from the prior art, for example, from the following patent documents: US 7237717 B1 (IP HOLDINGS INC, 03.07.2007), US 8892456 B2 (BROADRIDGE INVESTOR COMMUNICATION SOLUTIONS INC, 18.11.2014). A common drawback of existing solutions in this area is insufficient data security when implementing remote voting.

ESSENCE OF THE TECHNICAL SOLUTION

[0004] The claimed technical solution proposes a new approach in the field of distributed secure remote voting using mobile devices.

[0005] The technical problem or technical problem to be solved is to create a new platform for remote voting with a high degree of reliability and accuracy of vote counting. [0006] The main technical result achieved in solving the above technical problem is to enable secure remote voting using mobile devices.

[0007] The claimed result is achieved by an automated remote voting system, comprising:

• registration and primary authentication module, performing registration and primary user authentication in the system to gain access to the biometric authentication module;

• a biometric authentication module that performs biometric user authentication, access to voting, formation of a profile and user rights in the system using biometric verification algorithms;

• an electronic signature module that enables the use of an electronic signature by a user in the system and ensures user identification when connected to the system via a network;

• an activity control module that enables the initiation and administration of activity by a user in the system;

• a module for conducting an activity, which provides the ability to process and implement a user-initiated activity;

• module for integration with external systems, which interacts with external systems;

• module for processing internal requests, which interprets internal requests from system modules into requests to the module for integration with external systems;

• an audit module that monitors the actions of the system user and maintains the system log based on the recorded information.

[0008] In one particular embodiment, the modules are located in a single computing device and are united by a single tttin.

[0009] In another particular embodiment, at least two modules are located on different computing devices and are interconnected by data transmission channels.

[0010] In another particular embodiment, the computing device is a personal computer, server, or mainframe. DESCRIPTION OF DRAWINGS

[OOP] Features and advantages of the present invention will become apparent from the following detailed description of the invention and the accompanying drawings, in which:

[0012] FIG. 1 illustrates a general diagram of the claimed automated remote voting system.

[0013] FIG. 2 illustrates a general view of a computing device for implementing a system.

CARRYING OUT THE INVENTION

[0014] In this technical solution, terms such as "initiator", "administrator", which in general should be understood as a "user" of the system, can be used for clarity of understanding of the operation.

[0015] Automated remote voting system - a system that allows you to organize and conduct voting (including elections, decisions on certain issues, opinion polls, referendums, etc. further activity). The system implements the necessary conditions for carrying out these activities, such as: identification, anonymity, processing of results, formation of decisions, process audit, data storage, etc. - depending on the need for each specific type of activity. At the same time, the system implements this functionality using the mobile devices of the system users and the server part of the system, which allows users of the system to participate in voting or referendum without being personally present at the polling station.

[0016] The following user profiles of the platform are implemented in the system: Initiator - a person or group of persons initiating an activity in which a vote or a referendum is required. The initiator submits to the system the question / questions for which activity is required, the necessary properties of the activity, the format of the activity, initial data (lists of users with the right to access the activity, lists of candidates, in case of elections, a list of questions, etc.) and additional materials for links to activity (explanatory note on the bill, information materials for the agenda of the meeting of owners, biographies of candidates, etc.).

Administrator - a person or a group of persons responsible for the technical organization of the created activity. The administrator takes the actions necessary to implement the declared properties of activity, support users at the time conducting activity, ensures the overall safety and health of the system, is responsible for the performance of the system at the time of activity.

User is a citizen who has the right to participate in the created activity. [0017] To register in the system, the user must remotely provide the following data once: mobile device number, full name, date of birth. Then go through biometric identification to create a personal account and enrich the user profile from a trusted source. Biometric identification requires a pre-created biometric profile. For these purposes, the system connects to an external biometric system and, according to the biometric sample received from the user, requests data from the user profile in the biometric system, which are used to create a user's personal account.

[0018] After the user is identified, the system sends an OTP (one-time password) token to the user's mobile device number specified in the biometric profile to confirm registration by the second factor. If the user successfully enters the second factor, the system creates a personal account and user profile, and also prompts the user to set an authentication method for subsequent use: pin code; biometric authentication supported by the device. In the process of forming a user profile, the system saves a number of parameters obtained from the biometric profile, as well as parameters that the user can additionally enter on their own in their personal account after registration. These parameters, at the user's choice, can be displayed in the personal account, or hidden from the user and stored exclusively in the internal databases of the system. According to the data entered by the user, the system, if possible, checks their reliability; for this, requests are made to external electronic registers containing this data.

[0019] After the formation of a user profile, the system automatically verifies this profile with the activity profile, which is generated when a new activity is created in the system. If the user can take part in the activity, then the system automatically grants the user access to participate in the activity. To participate in a number of activities (in which authorization is required), the user must use an electronic digital signature (EDS), including integrated with the cloud EDS service system. In addition to the functionality of participation in voting, the user can be assigned the role of initiator of activity (including granulation to specific types activities and properties that the initiator can assign). Also, the role of initiator can be assigned not to a specific user, but to a separate account, which corresponds, for example, to a certain department.

[0020] Depending on his rights in the system, the initiator can create an activity: vote or referendum - and also select properties for the created activity. Before creating an activity, the initiator must pass biometric authorization in the system, for this he provides his biometric sample (face, fingerprint, or other). The system makes a request to an external biometric system and sends the OTP to the initiator in the form of a password in an SMS message. After the initiator enters an SMS message, he is considered authorized and gets access to the activity creation functionality, according to his rights in the system.

[0021] To create an activity, the initiator must specify the following attributes: the type of activity, the name of the activity, the time range of availability for voting on the created activity, a list of questions put to vote, additional materials for review, as well as the conditions for user access to this activity and the properties required to carry out this activity. After that, the system checks the sufficiency of the input data and, if possible, requests additional data from third systems with which there is integration.

Example: absentee voting of the owners of an apartment building. The initiator indicates the address of the house, and the system automatically generates a register of owners of residential premises of this house from the integrated state system. If it is impossible to automatically enrich the activity, the system requests additional data from the initiator.

[0022] After the formation of the process of conducting the activity, the system determines the circle of users who can take part in the activity by comparing the activity profile and the user profile, and also receives (if possible) additional information from third-party systems, while the system must be able to unambiguously compare user profile and additional data on this user from an external system (for example, by a unique user identifier).

[0023] After determining the circle of users who can take part in the activity, the system notifies the user about the availability of a new activity using a push notification (or SMS message, or email or otherwise).

[0024] A user who wants to take part in an activity must authenticate in the application on his device, select the desired activity and click "Participate". At this moment, the application forms a request to the system about the beginning of the activity process. The system processes the request and sends directives and data to the application according to the activity process.

[0025] The user takes part in the activity according to the process and gives his vote on this or that issue. The system processes the user's voice according to the activity process and generates the final result, which, according to the process, can also be transferred to a third-party system and / or returned to the initiator of the activity.

[0026] FIG. 1 shows a general diagram of the claimed system (100).

System (100) receives streams of information that are generated by users. The information entering the system (100) is distributed among the appropriate modules responsible for its processing in an automated mode. System (100) contains a set of interconnected data processing modules.

[0027] The registration and primary authentication module (101) is intended for registration of a new user of the system and subsequent primary authentication of the user. Basic authentication is required to be able to use the functions of the biometric authentication module (102) and the activity module (105). When the user accesses the system (100), the registration and primary authentication module (101) asks the user for the mobile device number, full name and date of birth. Having received the indicated data, the module (101) sends a message with a confirmation code to the indicated mobile device number, which must be entered by the user. Having received the correct confirmation code, module (101) registers a new user. Further, the module (101) allows the user to select options for subsequent authentication, for example, fingerprint authentication on a mobile device, pincode authentication on a mobile device, authentication using a login / password link, etc. When a registered user enters the system (100), the module (101) offers to use one of the authentication methods, for example, by a fingerprint, by a pin code, by a login + password link, or any other authentication method supported by the user's mobile device. After successful authentication, the module (101) transfers the right to access the user to the biometric authentication module (102) and the activity module (105).

[0028] The biometric authentication module (102) is intended for biometric user authentication, providing access to voting, forming a profile and user rights in the system. Module (102) interacts with the adjacent biometric authentication and identification system to implement biometric verification algorithms, with the internal database of the system (100), and with other modules that need to increase the level of trust in the user to provide access to additional functions or implement various properties of the activity. For successful authentication, the user must register once with the "Biometric Authentication Center". The biometric authentication center can be a separate special body or any other system in which it is possible for users to provide biometric samples in person and the identity of the applicants is produced. When a user contacts the biometric authentication center, a correspondence is created between the user's biometric samples and his identifying information (passport number or unique user identifier, mobile device number, full name, date of birth, etc.). Next, the module (102) asks the user for a biometric sample (face photo) and compares the received information with the sample stored in the biometric authentication center.

[0029] The formation of a user profile is carried out sequentially. After registration, the module (102) asks the user for a biometric sample - a person; in this case, the module (102) does not take photos, but independently selects a frame from the video sequence from the camera of the mobile device. Further, the system (100) receives from the module (102) contextual information about the user who is currently authenticated in the application (name, date of birth and mobile device number). The information obtained is compared with samples stored at the biometric authentication center for authentication. If the biometric samples, full name, date of birth and mobile device number match correctly, the system (100) sends an SMS message with a confirmation code to the mobile device number, which must be entered by the user in the system (100). After the user enters the confirmation code, the system (100) generates a user profile in the internal database.

[0030] The formation of user rights in the system (100) is carried out sequentially. For each activity in the system (100), a list of conditions is formed in advance that the user must meet in order to obtain rights both to the activity itself and to one or another action within the activity. When forming or changing a user profile, it is assessed for compliance with the conditions necessary to obtain these rights. System (100) grants rights to the user at the time of their request, each time analyzing the request and its context, in accordance with the level of trust to this user. [0031] Example: a user has the right to initiate a meeting of owners, but has never done so, which means that the system (100) will allow this to be done only after additional user identification.

[0032] For these purposes, the system (100) transmits static data about the user (for example, the geolocation of the mobile device, timestamp, etc.), as well as dynamic data that the system (100) calculates independently (statistics on the frequency of user requests , uniqueness of requests, user behavior in the system (100), etc.), on the basis of which the level of trust in a particular request is formed. In case of suspicion or a low level of trust, the system (100) can choose a way to authenticate the user and offer him additional checks to increase the level of trust. And also the system (100) can facilitate user access, in the case of a high level of trust.

[0033] The determination of the legality of the user's participation in a particular activity is carried out sequentially. As part of the creation of each activity, a list of criteria is formed by which the circle of persons allowed to participate in the activity is determined. Further, each user profile is checked against the specified criteria. If the activity is available to the user, the system (100) generates a notification about the possibility of participation and sends it to the user in the form of a push notification, SMS message, email, etc.

[0034] The electronic signature module (103) is intended for using an electronic signature by a user in the system (100) and providing user identification when connected to the system (100). Module (103) interacts with an external cloud digital signature system. Integration is carried out after the biometric registration of the user. There are two types of possible integration. The first one is integration with an existing cloud EDS account. The second is to create a new account in the cloud EDS service. As part of the integration, the module (103) transmits to the cloud EDS system the objects created as part of the activity for signing the user's personal EDS. Also, module (103) provides the user with a certificate for establishing mutual identification within a secure session (mutual TLS protocol).

[0035] The activity control module (104) is designed to initiate and administer activity by a user in the system (100). User access to the module (104) is determined by the user profile using the module (102). This module (104) also contains pre-prepared descriptions of some types of activities, including a list of conditions for initializing an activity, dynamic variables for organizing an activity and methods for obtaining them (a list questions / candidates, a list of users admitted to the activity, etc.), as well as a set of properties that the activity possesses. In module (104), a list of conditions is formed that the user profile must meet in order to obtain the rights to create a particular type of activity. Further, in module (104), a basic activity profile is formed, where a list of variables is added, the values for which must be provided to initialize the activity. For some variables, a directive can be specified for receiving values from an external source (if such a source is integrated), while these directives are executed only after the activity is initialized by the initiator.

[0036] The initiation of activity is carried out sequentially. After creation or modification, the user profile is compared with the list of conditions for each activity, and in case of a match, the function of initializing a new activity becomes available to the user. A user who wants to initialize a new activity must pass authorization, while the conditions for the "complexity" of authorization are written in the list of conditions for each activity. After authorization, the initiator must indicate the values of the activity variables (including but not limited to: the name of the activity, the time range of availability for voting on the generated activity, the list of questions put to vote, additional materials for review, etc.). If the system (100) cannot fill in the values of the variables automatically, the initiator must indicate in the activity a list of persons allowed to participate and a list of questions for discussion (or a list of candidates, etc.). The list of persons allowed to participate can be a table with specific users of the system (100) or the conditions under which the system (100) will determine the participants on its own. After that, the system (100) generates the final activity profile in accordance with the information received from the initiator, as well as the baseline profile for the initiated activity, adding activity properties.

[0037] In addition to the basic activity profiles, the system (100) provides for the creation of activity from scratch by almost any user (minimum conditions for obtaining rights), in this case, the user independently selects the activity properties and variables that will be used in the activity. Persons admitted to such activity are selected by determining the conditions for selecting user profiles. This type of activity is mainly intended for conducting surveys or social research. Each user of the system (100) in his profile can select the type of activity that will be offered to him by the system (100). The final activity profile is transmitted for execution to the activity execution module (105).

[0038] The Activity Conducting Module (105) is designed to process and implement a user initiated activity. Module (105) receives an activity profile from module (104). Further, the module (105) sequentially performs several stages of processing the activity profile.

[0039] At the first stage, primary processing and creation of a technical base of activity are performed. A new activity object is created from the activity profile, which contains all information data: name, agenda / questions / candidates, dates of the activity, conditions for the activity, additional materials, a list of allowed users, if any, etc. Next, an access policy to the activity object is created, which determines the order and rules of access to this activity and contains the following parameters: date and time of activity availability, activity access properties, authorization criteria for accessing an activity - these conditions are formed from variables in the activity profile, properties that are specified in the activity profile, as well as from any other information specified in the activity profile. An access policy is bound to an activity object by a unique identifier and is an integral part of it. Further, the technical implementation of the activity properties is carried out (“the user has the right to take part in voting” or the activity has the property “the ability to vote without authorization”, etc.).

[0040] After creating an activity object and a policy for accessing an activity object, the module (105) generates an “activity lifecycle”, which determines the order of the activity phases (preparation, collection of votes, vote processing, vote counting, registration of results, storage of results) and the start date and the duration of these phases according to the data specified in the activity profile and preset parameters. Each phase corresponds to a part of the automated process and contains information on additional directives that must be executed to implement certain properties of the activity (in addition to the properties that are displayed in the activity access policy). Activity properties can correspond to only one of the phases of the life cycle or be distributed over several phases, depending on the specific property. The activity phase is tied to the activity object and changes in accordance with the life cycle of the activity phase. After creating all the entities, the system (100) starts working with the activity according to its life cycle, in the order of phases. [0041] The second step is processing user requests made within the activity. After creating an activity profile, the user profile is checked and the conditions for allowing the user to be active. If the user profile passes the activity admission conditions, then the system (100) notifies the user about the detection of new activity. The user for whom the activity was detected can take part in them - for this he, using the application from his mobile device, sends to the system (100) a request for additional information on the activity. System (100), receiving a request for activity from the user, checks the current phase of activity and, if the phase allows adding one more user (preparation, collecting votes), then system (100) checks the access policy associated with the activity object to provide access to the user. Then, one by one, the presence of activity properties in the access policy is checked and the user is checked against them. In case of a successful check, the system (100) sends data about the activity (name, dates and format of the event, additional materials, etc.) to the user's device.

[0042] In addition, at the preparation stage, the module (105) implements the following property (if it is active "Voice confidentiality in data processing technology"). If this property is present, the system (100), after going to the preparation stage (immediately after the creation of activity entities: activity object, access policy, and life cycle), releases asymmetric encryption keys. Also, at the preparation stage, the user can view additional information on activity, as well as edit documents on activity, if the activity suggests such an opportunity (for example, suggest edits to a document). The preparation stage lasts from the moment of initiating an activity until the moment of starting voting by activity specified in the activity profile. Further user requests to the activity object are checked in accordance with the activity access policy and routed in accordance with the directives specified for the current activity phase in accordance with the activity lifecycle.

[0043] At the stage of collecting votes, the user generates a request to the activity object to vote. If the property "Voice confidentiality in technical means of data processing" is active, the system (100) provides a public key in response to a user's request. Next, the user makes a choice in terms of activity. The process of adding a user's decision to the internal database of the system (100) is accompanied by registration, within which a time stamp is added to each vote at which the registration took place. All time stamps, in which the decisions of the users were registered are additionally stored separately from the decisions of the users. After that, in the internal database, the user's decision is recorded in the format: "Unique identifier", "Timestamp", "User", "Hash sum signed by the user's public key certificate", "User's decision (as received: encrypted or open ) ". Of the specified values, only the unique identifier, timestamp, and solution are required. At the end of the stage of collecting votes, the received decisions of users are signed using the EDS of the system (100) and are transmitted further for processing. The stage of collecting votes continues according to the data specified in the object of activity.

[0044] In the step of processing votes, the system (100) automatically prepares votes for counting. The primary processing of the received votes begins with checking the integrity of the data in the internal database of the system (100). For this, a hash of all collected data is generated and checked against the signed hash of the same dataset. If there are no differences, then the data is accepted for processing, if there are differences, then the system (100) notifies the initiator and the administrator about this. Further, the module (105) requests a list of timestamps generated earlier during the registration of votes. And for each voice it checks the added timestamp against the list of timestamps - only those voices for which matches are found are taken into account. Thus, a check is carried out for possible addition of votes by interested parties. [0045] After passing the checks, the activity property directives added in the vote processing phase are processed. If the property "Protection from" coercion "during electronic voting or not" is specified, then the data set generated after initial checks on users is analyzed. If several votes received from one user are detected, then within the framework of this property, the module (105) removes from the list of votes all the user's votes, except for the last one. If the property "Possibility of parallel voting or not" is specified, then this property implies the possibility of activity through other channels (including the traditional one with personal presence at the polling station) in parallel with the activity in the system (100).

[0046] After executing the directives specified in the properties phase, the module (105) prepares a list of data for transmission to the stage of counting votes. If an algorithm of random permutations is used, then system (100) as input data to the next stage can transmit both mixed data and the initial anonymized list for additional verification on two data sets. At the stage of counting votes, system (100) implements the directives described in the properties, specified in this phase or the default directive. At the end of the vote counting stage, the generated results are signed with the system EDS (100) and stored in the internal database.

[0047] Next, the system (100) proceeds to the stage of registration of results. During this stage, the results are drawn up in a predetermined form (report, table, machine view, etc.) and transmitted to the initiator of the activity. After that, the module (105) generates the final list of data for the activity and signs it with an EDS. The list can additionally be linked to lists of users who took part in this activity, an object of activity or data from it. During the storage phase, the results and additional data are stored in a dedicated, secure database. After saving the results, the module (105) closes any access to the conducted activity.

[0048] The module for integrating with external systems (106) is designed to interact with external systems. Module (106) transmits the results of certain stages of work to external systems, interacting with module (105). It also provides other systems with access interfaces that implement the functionality of processing external requests and provide the requested data upon requests from external systems. Module (106) also implements the functional of normalizing external data received from external systems to bring these data in accordance with the schemes of the system's own databases (100). As input, the module (106) expects a request from another module of the system (100) or a request to the program interface from an external system. Upon receiving a request from another module of the system (100), the module (106) generates the necessary information for processing by the external system. After generating the necessary information, the module (106) establishes a connection with the external system according to the rules of the external system. For this, module (106) uses algorithms that are developed in advance for a specific integration.

[0049] The module for processing internal requests (107) is designed to interpret internal requests from modules of the system (100) into requests to the module for integrating with external systems (106). As input, the module (107) expects a request from another module of the system (100) (for example, from the biometric authentication and identification module (102)). The request must contain a pointer to the data type (for example, "unique user identifier"), which must be requested from the external system. If this identifier is absent, the request is rejected. If the identifier is present, the module (107) analyzes the relationship table between the internal data type of the system (100) and external systems in which you can get this data type. The table is generated and updated every time an external data source is connected. If there are no systems, then the request is rejected. If external systems in which the specified type of data can be obtained are connected to the system (100), then the module (107) analyzes the rest of the request for the presence of metadata, which is necessary for the external system to provide data of the required type. If the request contains all the metadata, then the module (107) redirects the request to the module for integrating with external systems (106). If there is no meta data, then the module (107) generates a response with the need to provide additional meta data to the module that requested the data. Further, the module (107) awaits a response from the module for integrating with external systems (106). Upon receipt of a response, the module (107) redirects the response to the module that made the request.

[0050] The audit module (108) is designed to implement algorithms for checking the actions of a user of the system (100) and maintaining a system log based on the recorded information. When filling out the final bulletin of activity on the client side (mobile device or personal computer), a data packet of the following form is generated: "Unique identifier", "Timestamp", "User", "Hash sum signed by the user's public key certificate", "User's decision ( as received: encrypted or open) "taking into account all additional properties of the activity. Next, this package is divided by module (108) into two components: a part describing the user (for example, "User", "Hash sum signed by the user's public key certificate") and the user's will (for example, "Unique identifier", "Timestamp" "User's decision"). As a result, three independent data packets are obtained: the complete set is sent via a secure communication channel with mutual identification to the side of the server side of the system (100) for further processing. The data describing the user is sent to a public non-anonymous blockchain system. Data describing the user's will is sent to the public anonymous blockchain system. [0051] After the activity, the module (108) publishes technical data: in the absence of encryption of ballots - an open anonymized table with user votes (without binding users to these votes). In the case of encryption, an impersonal table containing the cipher texts of all voices. Upon completion of the activity, the module (108) collects information received in the blockchain systems and compares these data.

[0052] FIG. 2 shows an example of a general view of a computing device (300) for implementing the system (100). [0053] In the General case, the computing device (300) contains one or more processors (301) united by a common bus of information exchange, memory means such as RAM (302) and ROM (303), input / output interfaces (304), devices input / output (1105), and a device for networking (306).

[0054] The processor (301) (or multiple processors, multi-core processor, etc.) can be selected from a range of devices currently widely used, for example, manufacturers such as: Intel ™, AMD ™, Apple ™, Samsung Exynos ™, MediaTEK ™, Qualcomm Snapdragon ™, etc. Under the processor or one of the processors used in the device (300), it is also necessary to take into account a graphics processor, for example, NVIDIA GPU or Graphcore, the type of which is also suitable for full or partial execution of the system (100), and can also be used for training and applying models machine learning in various information systems.

[0055] RAM (302) is a random access memory and is intended for storing machine-readable instructions executed by the processor (301) for performing the necessary operations for logical data processing. RAM (302), as a rule, contains executable instructions of the operating system and corresponding software components (applications, software modules, etc.). In this case, the available memory of the graphics card or graphics processor can act as RAM (302).

[0056] ROM (303) is one or more persistent storage devices, for example, hard disk drive (HDD), solid state data storage device (SSD), flash memory (EEPROM, NAND, etc.), optical storage media ( CD-R / RW, DVD-R / RW, BlueRay Disc, MD), etc.

[0057] Various types of I / O interfaces (304) are used to organize the operation of the components of the computing device (300) and to organize the operation of external connected devices. The choice of the appropriate interfaces depends on the specific version of the computing device, which can be, but are not limited to: PCI, AGP, PS / 2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS / Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232, etc.

[0058] To ensure user interaction with the computing device (300), various I / O means (305) are used, for example, a keyboard, display (monitor), touch display, touch pad, joystick, mouse manipulator, light pen, stylus, touchpad, trackball, speakers, microphone, augmented reality, optical sensors, tablet, light indicators, projector, camera, biometric identification (retina scanner, fingerprint scanner, voice recognition module), etc.

[0059] The networking tool (306) provides data transmission via an internal or external computer network, for example, Intranet, Internet, LAN, and the like. One or more means (306) may be used, but not limited to: Ethernet card, GSM modem, GPRS modem, LTE modem, 5G modem, satellite communication module, NFC module, Bluetooth and / or BLE module, Wi-Fi module and dr.

[0060] The presented application materials disclose preferred examples of the implementation of the technical solution and should not be construed as limiting other, particular examples of its implementation, not going beyond the scope of the claimed legal protection, which are obvious to specialists in the relevant field of technology.

Claims

FORMULA 1. An automated remote voting system containing: • registration and primary authentication module, performing registration and primary user authentication in the system to gain access to the biometric authentication module; • a biometric authentication module that performs biometric user authentication, access to voting, formation of a profile and user rights in the system using biometric verification algorithms; • an electronic signature module that enables the use of an electronic signature by a user in the system and ensures user identification when connected to the system via a network; • an activity control module that enables the initiation and administration of activity by a user in the system; • a module for conducting an activity, which provides the ability to process and implement a user-initiated activity; • module for integration with external systems, which interacts with external systems; • module for processing internal requests, which interprets internal requests from system modules into requests to the module for integration with external systems; • an audit module that monitors the actions of the system user and maintains the system log based on the recorded information. 2. The system according to claim 1, characterized in that the modules are located in a single computing device and are united by a single bus. 3. The system according to claim 1, characterized in that at least two modules are located on different computing devices and are interconnected by data transmission channels. 4. The system according to any one of paragraphs. 2-3, characterized in that the computing device is a personal computer, server or mainframe. 17 SUBSTITUTE SHEET (RULE 26)